netdev - [RFC RESEND v1 pinctrl-next 0/1] add blink and activity functions to SGPIO

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-next>] [day] [month] [year] [list]

Date: Tue, 11 Jul 2023 19:22:49 -0700
From: Colin Foster <colin.foster@...advantage.com>
To: linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	netdev@...r.kernel.org
Cc: Linus Walleij <linus.walleij@...aro.org>,
	UNGLinuxDriver@...rochip.com,
	Daniel Machon <daniel.machon@...rochip.com>,
	Steen Hegelund <Steen.Hegelund@...rochip.com>,
	Lars Povlsen <lars.povlsen@...rochip.com>,
	Christian Marangi <ansuelsmth@...il.com>,
	Andrew Lunn <andrew@...n.ch>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	Vladimir Oltean <vladimir.oltean@....com>
Subject: [RFC RESEND v1 pinctrl-next 0/1] add blink and activity functions to SGPIO

Preface (new for resend):

This is a resend of a patch I'd sent a couple years back. At that time,
I was told to wait for hardware-offloaded LEDS. It looks like that time
has finally come, so I've changed this from PATCH down to an RFC to make
sure this is the right approach for the framework.

Ocelot chips (VSC7511, VSC7512, VSC7513, VSC7514) have support for
hardware-offloaded LEDs based on network activity. This is currenty
managed by way of pinctrl-microchip-sgpio (and this current patch).

The purpose of this resend is two-fold. First, to come up with an idea
of how this pinctrl-microchip-sgpio module can fit in with the new
hardware-offloaded netdev triggers Christian Marangi recently added. Is
this something that should be in the pinctrl module itself? Or should
there be a drivers/net/ethernet/mscc/ocelot_leds.c module that I should
add?

The second reason is maybe there's someone out there who might also be
considering implementing this. This might be a good starting point if
someone is eager to get coding. On my priority list, this is quite low
so I'll get to it eventually, but maybe not even in this dev cycle.
That's why I'm including the original patch.

Any suggestions on how to approach this problem are welcome.

(You can probably stop reading here)

Original Header:

Expose a debugfs / devicetree interface for Microsemi SGPIO controllers.
By writing values of 2-5, the SGPIO pins can be configured for either
automatic blinking or activity.

The implementation is modeled after the code in
/drivers/pinctrl/pinctrl-ocelot.c.

I have only tested this with currently out-of-tree patches for the
VSC7512 that I hope to get in soon. They are not needed for VSC7513 /
VSC7514, SPARX5, or LUTON - but I don't have any hardware to test.

Of note: the 7512 chip has a discrepancy between the datasheet and the
registers. The datahseet claims 20Hz blink default frequency, the
registers claim 5 Hz default frequency for BMODE_0. I override the
OCELOT registers to correct for this. I don't know if that is needed for
LUTON or SPARX, but having two blink modes at the same frequency isn't
beneficial. As such, I make the blink modes match the 5Hz / 20Hz for the
two modes.

Tested with VSC7512 by way of:
echo SGPIO_O_p1b0 {blink0,blink1,activity0,activity1} > 
/sys/kernel/debug/pinctrl/pinctrl-sgpio-pinctrl-sgpio-output/pinmux-select

LEDs blink!

Colin Foster (1):
  pinctrl: microchip-sgpio: add activity and blink functionality

 drivers/pinctrl/pinctrl-microchip-sgpio.c | 135 +++++++++++++++++++++-
 1 file changed, 130 insertions(+), 5 deletions(-)

-- 
2.25.1