linux-kernel - Re: [PATCH] gpiolib: Avoid side effects in gpio_is

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]

Date:   Mon, 29 May 2023 11:19:02 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Kent Gibson <warthog618@...il.com>,
        "brgl@...ev.pl" <brgl@...ev.pl>,
        "johan@...nel.org" <johan@...nel.org>,
        "maz@...nel.org" <maz@...nel.org>,
        Ben Brown <Ben.Brown@...iedtelesis.co.nz>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sebastian Reichel <sre@...nel.org>,
        Andrew Lunn <andrew@...n.ch>
Subject: Re: [PATCH] gpiolib: Avoid side effects in gpio_is_visible()

On Wed, May 17, 2023 at 11:30 PM Chris Packham
<Chris.Packham@...iedtelesis.co.nz> wrote:

> > Why does the MCU have no in-kernel driver?
>
> There isn't any PoE PSE infrastructure in the kernel. I'm not really
> sure what it'd look like either as the hardware designs are all highly
> customized and often have very specialized requirements. Even the vendor
> reference boards tend to use the i2c userspace interface and punt
> everything to a specialist application.
>
> Of course if anyone is thinking about adding PoE PSE support in-kernel
> I'd be very keen to be involved.
(...)
> > I'm a bit lost. What your app is doing and how that is related to the
> > (userspace) drivers?
>
> Probably one of the primary things it's doing is bringing the chip out
> of reset by driving the GPIO (we don't want the PoE PSE supplying power
> if nothing is monitoring the temperature of the system). There's also
> some corner cases involving not resetting the PoE chipset on a hot restart.

This sounds like solid 100% kernelspace territory, and while I do see
that it can be a bit intimidating to extend the existing frameworks, there
are some really helpful people in the netdev community.

For example Andrew Lunn and Sebastian Reichel working on netdev and
the power supply subsystems can most certainly figure out where this
thing goes and what is already available.

There is: drivers/pwm/pwm-raspberrypi-poe.c
referring to this hardware:
https://www.raspberrypi.com/products/poe-hat/
which is a bit odd: I think this PWM controls the fan on the PoE
board only, so it is probably not a good example.

Yours,
Linus Walleij