static int hns3_alloc_buffer(struct hns3_enet_ring *ring, diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h index 16f778887e14..9b3ab11e19c8 100644 --- a/include/linux/netdev_features.h +++ b/include/linux/netdev_features.h @@ -101,12 +101,12 @@ enum { typedef struct { DECLARE_BITMAP(bits, NETDEV_FEATURE_COUNT); -} netdev_features_t; +} netdev_features_t;
That hunk looks odd.
Yes, but it can be return directly, so we don't have to change the prototype of functions which return netdev_features_t, like ndo_features_check.
-static inline void netdev_feature_zero(netdev_features_t *dst) +static inline void netdev_features_zero(netdev_features_t *dst) { bitmap_zero(dst->bits, NETDEV_FEATURE_COUNT); } -static inline void netdev_feature_fill(netdev_features_t *dst) +static inline void netdev_features_fill(netdev_features_t *dst) { bitmap_fill(dst->bits, NETDEV_FEATURE_COUNT); }
I'm wondering that the value here is? What do we gain by added the s. These changes cause a lot of churn in the users of these functions.
This function is used to expression like below:
"lowerdev_features &= (features | ~NETIF_F_LRO);" in drivers/net/macvlan.c
O.K, now i know what is confusing me. This is not a patch on top of clean net-next/master. It does not have netdev_features_t as a bitmap, it does not have netdev_feature_fill().
You already have some other changes applied to your tree, and this patch is on top of that?
I think we generally agree about the direction you are going. What we probably want to see is a patchset against net-next/master which converts the core and one driver to this new API. That allows us to review the new API, which is the important thing here.
I prefered to rename the netdev field active_features .
O.K.
Andrew