netdev - Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220605180641.tfqyxhkkauzoz2z4@pengutronix.de>
Date:   Sun, 5 Jun 2022 20:06:41 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Max Staudt <max@...as.org>
Cc:     Vincent Mailhol <mailhol.vincent@...adoo.fr>,
        linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
        Oliver Hartkopp <socketcan@...tkopp.net>,
        netdev@...r.kernel.org
Subject: Re: [PATCH v5 0/7] can: refactoring of can-dev module and of Kbuild

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@...adoo.fr> 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 |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)