Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Guenter Roeck <groeck7@gmail.com>
Message-ID: <b1d8f851-4e87-333c-229c-b9dc37ea3c40@roeck-us.net>
Date:   Wed, 31 May 2023 12:16:39 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Content-Language: en-US
To:     "Hawkins, Nick" <nick.hawkins@hpe.com>
Cc:     "Verdun, Jean-Marie" <verdun@hpe.com>,
        "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
        "brgl@bgdev.pl" <brgl@bgdev.pl>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "krzysztof.kozlowski+dt@linaro.org" 
        <krzysztof.kozlowski+dt@linaro.org>,
        "jdelvare@suse.com" <jdelvare@suse.com>,
        "andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>
References: <20230531151918.105223-1-nick.hawkins@hpe.com>
 <20230531151918.105223-5-nick.hawkins@hpe.com>
 <07b2a2f7-5ddc-0f10-6b1f-184dc21fa580@roeck-us.net>
 <DM4PR84MB19274F575858CBCB2FA5C23E88489@DM4PR84MB1927.NAMPRD84.PROD.OUTLOOK.COM>
From:   Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v2 4/5] hwmon: (gxp_fan_ctrl) Provide fan info via gpio
In-Reply-To: <DM4PR84MB19274F575858CBCB2FA5C23E88489@DM4PR84MB1927.NAMPRD84.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/31/23 11:17, Hawkins, Nick wrote:
>> 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

I don't think so.

> monitor for change.
> 

If the host wants to own the fan status from gpio pins, it has to live up to
it and own it entirely. The kernel hwmon driver does not have access in that
case.

In a more "normal" world, the hwmon driver would "own" the gpio pin(s)
and user space would listen to associated hwmon attribute events (presumably
fan_enable and fan_fault), either by listening for sysfs attribute events
or via udev or both. Again, if you don't want to do that, and want user space
to have access to the raw gpio pins, you'll have to live with the consequences.
I don't see the need to bypass existing mechanisms just because user space
programmers want direct access to gpio pins.

> 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.
> 

I neither think this is a good idea nor that it is really necessary.
Again, the desire to have direct user space access to gpio pins is
something you _want_, not something that is really needed.

Guenter