Hi Loic, > Yes, I guess it's all about timings... At least, I care now... :) > I've recently worked on the mhi_net driver, which is basically the > netdev driver for Qualcomm PCIe modems. MHI being similar to IOSM > (exposing logical channels over PCI). Like QCOM USB variants, data can > be transferred in QMAP format (I guess what you call QMI), via the > `rmnet` link type (setup via iproute2). Right. (I know nothing about the formats, so if I said anything about 'QMI' just ignore and think 'qualcomm stuff') > > This a legitimate point, but it's not too late to do the 'right' > thing, + It should not be too much change in the IOSM driver. Agree. Though I looked at it now in the last couple of hours, and it's actually not easy to do. I came up with these patches for now: https://p.sipsolutions.net/d8d8897c3f43cb85.txt (on top of 5.13-rc3 + the patchset we're discussing here) The key problem is that rtnetlink ops are meant to be for a single device family, and don't really generalize well. For example: +static void wwan_rtnl_setup(struct net_device *dev) +{ + /* FIXME - how do we implement this? we dont have any data + * at this point ..., i.e. we can't look up the context yet? + * We'd need data[IFLA_WWAN_DEV_NAME], see wwan_rtnl_newlink(). + */ +} or +static struct rtnl_link_ops wwan_rtnl_link_ops __read_mostly = { [...] + .priv_size = WWAN_MAX_NETDEV_PRIV, are both rather annoying. Making this more generic should of course be possible, but would require fairly large changes all over the kernel - passing the tb/data to all the handlers involved here, etc. That seems awkward? What do you think? The alternative I could see is doing what wifi did and create a completely new (generic) netlink family, but that's also awkward to some extend and requires writing more code to handle stuff that rtnetlink already does ... Please take a look. I suppose we could change rtnetlink to make it possible to have this behind it ... but that might even be tricky, because setup() is called in the context of alloc_netdev_mqs(), and that also has no private data to pass through. So would we have to extend rtnetlink ops with a "get_setup()" method that actually *returns* a pointer to the setup method, so that it can be per-user (such as IOSM)? Tricky stuff. > Regarding Qualcomm, I think it should be possible to fit QCOM Modem > drivers into that solution. It would consist of creating a simple > wrapper in QMAP/rmnet so that the rmnet link can (also) be created > from the kernel side (e.g. from mhi_net driver): > wwan_new_link() => wwan->add_intf_cb() => mhi_net_add_intf() => rmnet_newlink() > > That way mhi_net driver would comply with the new hw agnostic wwan link > API, without breaking backward compatibility if someone wants to > explicitly create a rmnet link. Moreover, it could also be applicable > to USB modems based on MBIM and their VLAN link types. Maybe. It'd just need some incentive, and there's none now that the Qualcomm stuff is already there :) johannes
