On 05.06.2022 19:23:47, Max Staudt wrote: > Thanks Vincent for this cleanup! > > Since I am upstreaming a driver that may (?) not fit the proposed > structure, one question below. > > > On Sun, 5 Jun 2022 01:29:53 +0900 > Vincent Mailhol wrote: > > > * menu after this series * > > > > Network device support > > symbol: CONFIG_NETDEVICES > > | > > +-> CAN Device Drivers > > symbol: CONFIG_CAN_DEV > > | > > +-> software/virtual CAN device drivers > > | (at time of writing: slcan, vcan, vxcan) > > | > > +-> CAN device drivers with Netlink support > > symbol: CONFIG_CAN_NETLINK (matches previous CONFIG_CAN_DEV) > > | > > +-> CAN bit-timing calculation (optional for all drivers) > > | symbol: CONFIG_CAN_BITTIMING > > | > > +-> All other CAN devices not relying on RX offload > > | > > +-> CAN rx offload > > symbol: CONFIG_CAN_RX_OFFLOAD > > | > > +-> CAN devices relying on rx offload > > (at time of writing: flexcan, m_can, mcp251xfd and > > ti_hecc) > > This seemingly splits drivers into "things that speak to hardware" and > "things that don't". Except... slcan really does speak to hardware. It > just so happens to not use any of BITTIMING or RX_OFFLOAD. However, my > can327 (formerly elmcan) driver, which is an ldisc just like slcan, > *does* use RX_OFFLOAD, so where to I put it? Next to flexcan, m_can, > mcp251xfd and ti_hecc? > > Is it really just a split by features used in drivers, and no longer a > split by virtual/real? We can move RX_OFFLOAD out of the "if CAN_NETLINK". Who wants to create an incremental patch against can-next/master? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |