Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild
From: Marc Kleine-Budde
Date: Sun Jun 05 2022 - 14:06:54 EST
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 <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?
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 |
Attachment:
signature.asc
Description: PGP signature