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 <mailhol.vincent@xxxxxxxxxx> 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? Max
