Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Wed, 18 May 2022 15:28:11 +0200
From:   Marc Kleine-Budde <mkl@pengutronix.de>
To:     Oliver Hartkopp <socketcan@hartkopp.net>
Cc:     Vincent MAILHOL <mailhol.vincent@wanadoo.fr>,
        Max Staudt <max@enpas.org>, linux-can@vger.kernel.org,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and
 can_skb_headroom_valid to skb.c
Message-ID: <20220518132811.xfmwms2cu3bfxgrp@pengutronix.de>
References: <20220517060821.akuqbqxro34tj7x6@pengutronix.de>
 <CAMZ6RqJ3sXYUOpw7hEfDzj14H-vXK_i+eYojBk2Lq=h=7cm7Jg@mail.gmail.com>
 <20220517104545.eslountqjppvcnz2@pengutronix.de>
 <e054f6d4-7ed1-98ac-8364-425f4ef0f760@hartkopp.net>
 <20220517141404.578d188a.max@enpas.org>
 <20220517122153.4r6n6kkbdslsa2hv@pengutronix.de>
 <20220517143921.08458f2c.max@enpas.org>
 <0b505b1f-1ee4-5a2c-3bbf-6e9822f78817@hartkopp.net>
 <CAMZ6RqJ0iCsHT-D5VuYQ9fk42ZEjHStU1yW0RfX1zuJpk5rVtQ@mail.gmail.com>
 <43768ff7-71f8-a6c3-18f8-28609e49eedd@hartkopp.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="43mv6ogbut5bwzf7"
Content-Disposition: inline
In-Reply-To: <43768ff7-71f8-a6c3-18f8-28609e49eedd@hartkopp.net>
Precedence: bulk


--43mv6ogbut5bwzf7
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 18.05.2022 15:10:44, Oliver Hartkopp wrote:
> On 18.05.22 14:03, Vincent MAILHOL wrote:
> > I didn't think this would trigger such a passionate discussion!
>=20
> :-D
>
> Maybe your change was the drop that let the bucket run over ;-)

It's so trivial that everybody feels the urge to say something. :D

> > > But e.g. the people that are running Linux instances in a cloud only
> > > using vcan and vxcan would not need to carry the entire infrastructure
> > > of CAN hardware support and rx-offload.
> >=20
> > Are there really some people running custom builds of the Linux kernel
> > in a cloud environment? The benefit of saving a few kilobytes by not
> > having to carry the entire CAN hardware infrastructure is blown away
> > by the cost of having to maintain a custom build.
>=20
> When looking to the current Kconfig and Makefile content in
> drivers/net/can(/dev) there is also some CONFIG_CAN_LEDS which "depends on
> BROKEN" and builds a leds.o from a non existing leds.c ?!?
>=20
> Oh leds.c is in drivers/net/can/leds.c but not in drivers/net/can/dev/led=
s.c
> where it could build ... ?
>=20
> So what I would suggest is that we always build a can-dev.ko when a CAN
> driver is needed.
>=20
> Then we have different options that may be built-in:
>=20
> 1. netlink hw config interface
> 2. bitrate calculation
> 3. rx-offload
> 4. leds
>=20
> E.g. having the netlink interface without bitrate calculation does not ma=
ke
> sense to me too.

ACK

> > I perfectly follow the idea to split rx-offload. Integrators building
> > some custom firmware for an embedded device might want to strip out
> > any unneeded piece. But I am not convinced by this same argument when
> > applied to v(x)can.
>=20
> It does. I've seen CAN setups (really more than one or two!) in VMs and
> container environments that are fed by Ethernet tunnels - sometimes also =
in
> embedded devices.
>=20
> > A two level split (with or without rx-offload) is what makes the most
> > sense to me.
> >=20
> > Regardless, having the three level split is not harmful. And because
> > there seems to be a consensus on that, I am fine to continue in this
> > direction.
>=20
> Thanks!
>=20
> Should we remove the extra option for the bitrate calculation then?

+1

> And what about the LEDS support depending on BROKEN?
> That was introduced by commit 30f3b42147ba6f ("can: mark led trigger as
> broken") from Uwe as it seems there were some changes in 2018.

There's a proper generic LED trigger now for network devices. So remove
LED triggers, too.

Marc

--=20
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 |

--43mv6ogbut5bwzf7
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEBsvAIBsPu6mG7thcrX5LkNig010FAmKE9GgACgkQrX5LkNig
013/Rgf9Eov4y1zksOqRf5lhd3kxutLaOL3d+BBBq7uExlRmSMhiFPOetpn22wWy
jHYM1Pouoq8/Vpznk3EMv2AKlitfeoNtwYHJDAAWwgrhnB4ok0L9/YjDJWwy+e/F
t01PYBs3tXMkII8nGI3wZhiY7rkmtcrcI5IMHoiSC6abpCxOcqp3R6vqyIytC0tH
2hUg5j69Y1Z4+ZtDGuV1oHcizJZ2nVFpzXwguszU+2x2rYZtXSevUzcuSqWhpUHK
XTUlzW+IH/pjL2d4aYSZAkE7ZBhzrY33BMk8Vqk5W5Ko4zjVx4Rn7fDVo4S7UrL2
SEsZnDXDsGJ/iZBie/JoGTe5Z5sfRg==
=51BL
-----END PGP SIGNATURE-----

--43mv6ogbut5bwzf7--