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: <20220518143613.2a7alnw6vtkw7ct2@pengutronix.de>
Date:   Wed, 18 May 2022 16:36:13 +0200
From:   Marc Kleine-Budde <mkl@...gutronix.de>
To:     Oliver Hartkopp <socketcan@...tkopp.net>
Cc:     Vincent MAILHOL <mailhol.vincent@...adoo.fr>,
        Max Staudt <max@...as.org>, linux-can@...r.kernel.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and
 can_skb_headroom_valid to skb.c

On 18.05.2022 16:33:58, Oliver Hartkopp wrote:
> > > > 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.
> > 
> > Yes, the broken LED topic also popped-up last year:
> > 
> > https://lore.kernel.org/linux-can/20210906143057.zrpor5fkh67uqwi2@pengutronix.de/ > I am OK to add one patch to the series for LED removal.
> 
> Hm. We have several drivers that support LED triggers:
> 
> $ git grep led.h
> at91_can.c:#include <linux/can/led.h>
> c_can/c_can_main.c:#include <linux/can/led.h>
> ctucanfd/ctucanfd_base.c:#include <linux/can/led.h>
> dev/dev.c:#include <linux/can/led.h>
> flexcan/flexcan-core.c:#include <linux/can/led.h>
> led.c:#include <linux/can/led.h>
> m_can/m_can.h:#include <linux/can/led.h>
> rcar/rcar_can.c:#include <linux/can/led.h>
> rcar/rcar_canfd.c:#include <linux/can/led.h>
> sja1000/sja1000.c:#include <linux/can/led.h>
> spi/hi311x.c:#include <linux/can/led.h>
> spi/mcp251x.c:#include <linux/can/led.h>
> sun4i_can.c:#include <linux/can/led.h>
> ti_hecc.c:#include <linux/can/led.h>
> usb/mcba_usb.c:#include <linux/can/led.h>
> usb/usb_8dev.c:#include <linux/can/led.h>
> xilinx_can.c:#include <linux/can/led.h>
> 
> And I personally like the ability to be able to fire some LEDS (either as
> GPIO or probably in a window manager).
> 
> I would suggest to remove the Kconfig entry but not all the code inside the
> drivers, so that a volunteer can convert the LED support based on the
> existing trigger points in the drivers code later.

The generic netdev LED trigger code doesn't need any support in the
netdev driver.

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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ