linux-kernel - RE: [PATCH v2 4/5] hwmon: (gxp_fan

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: <DM4PR84MB19274F575858CBCB2FA5C23E88489@DM4PR84MB1927.NAMPRD84.PROD.OUTLOOK.COM>
Date:   Wed, 31 May 2023 18:17:29 +0000
From:   "Hawkins, Nick" <nick.hawkins@....com>
To:     Guenter Roeck <linux@...ck-us.net>
CC:     "Verdun, Jean-Marie" <verdun@....com>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "brgl@...ev.pl" <brgl@...ev.pl>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "jdelvare@...e.com" <jdelvare@...e.com>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>
Subject: RE: [PATCH v2 4/5] hwmon: (gxp_fan_ctrl) Provide fan info via gpio

> This is not acceptable. It is way too generic for a global variable, and it
> does not use the gpio API. Besides, the variables would have to be declared
> in an include file associated with the code introducing them.

> If you want to use gpio pins in the hwmon driver, use the gpio API
> ([devm_]gpiod_get() and associated functions). There are lots of examples
> in the kernel showing how to do that.

Hi Guenter,

Thank you for the feedback. I did try and create a driver for both the fan
and the psu but I had an issue where the host and linux driver both
need to monitor and access it.

I made a brief query about it here to the mailing list.
(Apologies if this is the incorrect way to share a link)
https://lore.kernel.org/all/DM4PR84MB19274817C2D8A751E3218F4888759@DM4PR84MB1927.NAMPRD84.PROD.OUTLOOK.COM/

I am open for trying a different approach, I am just not sure what is
the correct way to proceed.

Is there a way for the driver to temporarily take the GPIO away from the
Host and return it? The host is wanting to hold the GPIO all the time to
monitor for change.

Another thought I had was perhaps having some duplicate I/Os where
there is one for the host consumption and the other for linux kernel
driver consumption.

Thank you for the assistance,

-Nick Hawkins