On Mon, Mar 09, 2020 at 11:25:50AM +0100, Marc Kleine-Budde wrote: > On 3/7/20 6:13 AM, David Miller wrote: > > From: Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> > > Date: Fri, 6 Mar 2020 15:12:48 +0100 > > > >> On 3/2/20 8:12 PM, David Miller wrote: > >>> From: Oliver Hartkopp <socketcan@xxxxxxxxxxxx> > >>> Date: Mon, 2 Mar 2020 09:45:41 +0100 > >>> > >>>> I don't know yet whether it makes sense to have CAN bonding/team > >>>> devices. But if so we would need some more investigation. For now > >>>> disabling CAN interfaces for bonding/team devices seems to be > >>>> reasonable. > >>> > >>> Every single interesting device that falls into a special use case > >>> like CAN is going to be tempted to add a similar check. > >>> > >>> I don't want to set this precedence. > >>> > >>> Check that the devices you get passed are actually CAN devices, it's > >>> easy, just compare the netdev_ops and make sure they equal the CAN > >>> ones. > >> > >> Sorry, I'm not really sure how to implement this check. > > > > Like this: > > > > if (netdev->ops != &can_netdev_ops) > > return; > > There is no single can_netdev_ops. The netdev_ops are per CAN-network > driver. But the ml_priv is used in the generic CAN code. ping, are there any other ways or ideas how to solve this issue? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
