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 <[email protected]> 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
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 <[email protected]> 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 |