From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
fengguang.wu@intel.com, dcbw@redhat.com, jiri@resnulli.us
Subject: Re: [PATCH net-next 1/1 v3] drivers: net: rmnet: Initial implementation
Date: Fri, 14 Apr 2017 17:02:54 -0600 [thread overview]
Message-ID: <36dd3dd490657d214e034a9c294621db@codeaurora.org> (raw)
In-Reply-To: <20170414091030.2a657c9f@xeon-e3>
>> +https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/\
>> +dataservices/tree/rmnetctl
>
> Don't split URL better to have long line.
>> diff --git a/drivers/net/rmnet/Kconfig b/drivers/net/rmnet/Kconfig
>
> Since this is Qualcomm and Ethernet specific, maybe better to put
> in drivers/net/ethernet/qualcom/rmnet
>
>> +config RMNET_DEBUG
>
> Please use network device standard debug mechanism.
> netif_msg_XXX
>
>> + buffloc += snprintf(&buffer[buffloc], sizeof(buffer) - buffloc,
>> + " %02x", skb->data[i]);
>
> If you really have to do this. Use hex_dump_bytes API.
>
>> + skb->mac_header = 0;
>> + skb->mac_len = 0;
>> +}
>
> Why not use sbk_set_mac_header(skb, 0)?
>
>> +static inline struct rmnet_phys_ep_conf_s *_rmnet_get_phys_ep_config
>> + (struct net_device *dev)
> awkward line break.
> dev could be const
>
>> + config = (struct rmnet_phys_ep_conf_s *)
>> + rcu_dereference(dev->rx_handler_data);
>
> Please don't directly reference rx_handler. There is already functions
> like netdev_is_rx_handler_busy() to abstract that API.
>
>> + * @epconfig: endpoint configuration structure to set
>> + */
>
> You are using docbook format here, but this is not a docbook comment.
> ie.
> /**
> * function - This is a docbook comment
> * @dev: this is a param
> */
>
> Plus these are static functions so there is no point in documentating
> internal API with docbook.
>
>> + ASSERT_RTNL();
>> +
>> + if (!dev || config_id < RMNET_LOCAL_LOGICAL_ENDPOINT ||
>> + config_id >= RMNET_MAX_LOGICAL_EP)
>> + return -EINVAL;
>
> For internal API's you should validate parmeters at the external
> entry point not in each call. Otherwise you have a multitude of
> impossible error checks and dead code paths.
>
>> + .next = 0,
>> + .priority = 0
>> +};
> Don't initialize fields that are not used or should be zero.
>
Hi Stephen
I'll make these changes.
>
> Could just be:
>
> static inline int _rmnet_is_physical_endpoint_associated(const struct
> net_device *dev)
> {
> rx_handler_func_t *rx_handler
> = rcu_dereference(dev->rx_handler);
>
> return rx_handler == rmet_rx_handler;
> }
>
> But standard practice is to use ndo_ops to identify self in network
> drivers.
> I.e
> return dev->netdev_ops == &rmnet_device_ops;
>
The netdevice which is associated is the physical (real_dev). This
device
can vary based on hardware and will have its own netdev_ops associated
with it.
rmnet_device_ops applies to the rmnet devices only. I'll use the first
option you have suggested.
>> + if (!data[IFLA_RMNET_MUX_ID])
>> + return -EINVAL;
>
> So you are inventing private link netlink attributes.
> Why? Why can't you use device switch, bridge, or other master/slave
> model.
>
I would like to eventually add more configuration options for the
ingress & egress data formats as well as the endpoint configuration
(VND mode vs BRIDGE mode). I was able to re-use IFLA_VLAN_ID for
IFLA_RMNET_MUX_ID and test but it wasn't sufficient for the additional
parameters. I'll check the bridge attributes and try to reuse it.
prev parent reply other threads:[~2017-04-14 23:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-14 5:05 [PATCH net-next 0/1 v3] drivers: net: Add support for rmnet driver Subash Abhinov Kasiviswanathan
2017-04-14 5:05 ` [PATCH net-next 1/1 v3] drivers: net: rmnet: Initial implementation Subash Abhinov Kasiviswanathan
2017-04-14 9:07 ` Jiri Pirko
2017-04-14 21:57 ` Subash Abhinov Kasiviswanathan
2017-04-14 21:59 ` Stephen Hemminger
2017-08-14 23:52 ` Subash Abhinov Kasiviswanathan
2017-04-14 16:10 ` Stephen Hemminger
2017-04-14 23:02 ` Subash Abhinov Kasiviswanathan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36dd3dd490657d214e034a9c294621db@codeaurora.org \
--to=subashab@codeaurora.org \
--cc=davem@davemloft.net \
--cc=dcbw@redhat.com \
--cc=fengguang.wu@intel.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.