Question about gpio-hog

Question about gpio-hog

[Bough Chen]

Hi All,

I have a question of ‘gpio-hog’, the property gpio-hog seems to be used in GPIO node rather than in users device node, so we can’t use the device-link feature.
(sorry for resend, I use text/plain messages this time)

e.g.

pcal6524: gpio@22 { 
      …
　　　/* usdhc3 and QSPI share the same pin, here select SD3 pins */
　　　usdhc3-qspi-sel-hog {
　　　　　　gpio-hog;
　　　　　　gpios = <16 GPIO_ACTIVE_HIGH>;
　　　　　　output-high;
　　　};
　　　…
};

&usdhc3 {
     …
}

The board share the pins of usdhc3 and QSPI, a MUX use one GPIO pad from one I2C GPIO expander to control the selection.
So before usdhc3 probe, need to make sure the gpio-hog is configed. Which means usdhc3 need to depend on usdhc3-qspi-sel-hog.

To achieve that, I can add a fake GPIO properties like below:
&usdhc3{
     …
     hog-gpio = <&pcal6524 16 GPIO_ACTIVE_HIGH>;
}

Usdhc driver do not handle the hog-gpio, just use this fake hog-gpio to let the usdhc3 depends on pcal6524 IO expander. Make sure when usdhc driver probe, already select the usdhc3 pads on board.

But this will trigger the DT check warning if related device binding has ““additionalProperties: false”  or  “unevaluatedProperties: false”.

Can this be acceptable? Any thoughts for this case? I think this might be common user case for gpio-hog.


Best Regards
Bough Chen


Best Regards
Bough Chen

Mobile: +86 18550524348

Re: Question about gpio-hog

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

On Thu, Jul 18, 2024 at 03:40:49AM +0000, Bough Chen wrote:
> Hi All,
> 
> I have a question of ‘gpio-hog’, the property gpio-hog seems to be used in GPIO node rather than in users device node, so we can’t use the device-link feature.
> (sorry for resend, I use text/plain messages this time)
> 
> e.g.
> 
> pcal6524: gpio@22 { 
>       …
> 　　　/* usdhc3 and QSPI share the same pin, here select SD3 pins */
> 　　　usdhc3-qspi-sel-hog {
> 　　　　　　gpio-hog;
> 　　　　　　gpios = <16 GPIO_ACTIVE_HIGH>;
> 　　　　　　output-high;
> 　　　};
> 　　　…
> };
> 
> &usdhc3 {
>      …
> }
> 
> The board share the pins of usdhc3 and QSPI, a MUX use one GPIO pad from one I2C GPIO expander to control the selection.
> So before usdhc3 probe, need to make sure the gpio-hog is configed. Which means usdhc3 need to depend on usdhc3-qspi-sel-hog.
> 
> To achieve that, I can add a fake GPIO properties like below:
> &usdhc3{
>      …
>      hog-gpio = <&pcal6524 16 GPIO_ACTIVE_HIGH>;
> }
> 
> Usdhc driver do not handle the hog-gpio, just use this fake hog-gpio to let the usdhc3 depends on pcal6524 IO expander. Make sure when usdhc driver probe, already select the usdhc3 pads on board.
> 
> But this will trigger the DT check warning if related device binding has ““additionalProperties: false”  or  “unevaluatedProperties: false”.
> 
> Can this be acceptable? Any thoughts for this case? I think this might be common user case for gpio-hog.

I've got no idea what this device you're talking about is - but it seems
to me like the "hog-gpio" property is what you should be doing (although
probably called something like "enable-gpios" instead.
What you would do is send a patch for the dt-binding for this device,
adding a property, in which case the *Properties: false will stop
warning.

> 
> 
> Best Regards
> Bough Chen
> 
> 
> Best Regards
> Bough Chen
> 
> Mobile: 

btw, you might want to remove your phone number from the footer when
sending to public mailing lists.

Cheers,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Question about gpio-hog

[Krzysztof Kozlowski]

On 18/07/2024 16:47, Conor Dooley wrote:
> On Thu, Jul 18, 2024 at 03:40:49AM +0000, Bough Chen wrote:
>> Hi All,
>>
>> I have a question of ‘gpio-hog’, the property gpio-hog seems to be used in GPIO node rather than in users device node, so we can’t use the device-link feature.
>> (sorry for resend, I use text/plain messages this time)
>>
>> e.g.
>>
>> pcal6524: gpio@22 { 
>>       …
>> 　　　/* usdhc3 and QSPI share the same pin, here select SD3 pins */
>> 　　　usdhc3-qspi-sel-hog {
>> 　　　　　　gpio-hog;
>> 　　　　　　gpios = <16 GPIO_ACTIVE_HIGH>;
>> 　　　　　　output-high;
>> 　　　};
>> 　　　…
>> };
>>
>> &usdhc3 {
>>      …
>> }
>>
>> The board share the pins of usdhc3 and QSPI, a MUX use one GPIO pad from one I2C GPIO expander to control the selection.
>> So before usdhc3 probe, need to make sure the gpio-hog is configed. Which means usdhc3 need to depend on usdhc3-qspi-sel-hog.
>>
>> To achieve that, I can add a fake GPIO properties like below:
>> &usdhc3{
>>      …
>>      hog-gpio = <&pcal6524 16 GPIO_ACTIVE_HIGH>;
>> }
>>
>> Usdhc driver do not handle the hog-gpio, just use this fake hog-gpio to let the usdhc3 depends on pcal6524 IO expander. Make sure when usdhc driver probe, already select the usdhc3 pads on board.
>>
>> But this will trigger the DT check warning if related device binding has ““additionalProperties: false”  or  “unevaluatedProperties: false”.
>>
>> Can this be acceptable? Any thoughts for this case? I think this might be common user case for gpio-hog.
> 
> I've got no idea what this device you're talking about is - but it seems
> to me like the "hog-gpio" property is what you should be doing (although
> probably called something like "enable-gpios" instead.
> What you would do is send a patch for the dt-binding for this device,
> adding a property, in which case the *Properties: false will stop
> warning.

If there is device dependency on the hog, I would say by definition of a
hog that's not a hog. Hogs are for controller to initialize, but here
your device driver needs it. This sounds like simple pin configuration
for device.

Best regards,
Krzysztof

Re: Question about gpio-hog

[Frank Li]

On Thu, Jul 18, 2024 at 05:13:22PM +0200, Krzysztof Kozlowski wrote:
> On 18/07/2024 16:47, Conor Dooley wrote:
> > On Thu, Jul 18, 2024 at 03:40:49AM +0000, Bough Chen wrote:
> >> Hi All,
> >>
> >> I have a question of ‘gpio-hog’, the property gpio-hog seems to be used in GPIO node rather than in users device node, so we can’t use the device-link feature.
> >> (sorry for resend, I use text/plain messages this time)
> >>
> >> e.g.
> >>
> >> pcal6524: gpio@22 { 
> >>       …
> >> 　　　/* usdhc3 and QSPI share the same pin, here select SD3 pins */
> >> 　　　usdhc3-qspi-sel-hog {
> >> 　　　　　　gpio-hog;
> >> 　　　　　　gpios = <16 GPIO_ACTIVE_HIGH>;
> >> 　　　　　　output-high;
> >> 　　　};
> >> 　　　…
> >> };
> >>
> >> &usdhc3 {
> >>      …
> >> }
> >>
> >> The board share the pins of usdhc3 and QSPI, a MUX use one GPIO pad from one I2C GPIO expander to control the selection.
> >> So before usdhc3 probe, need to make sure the gpio-hog is configed. Which means usdhc3 need to depend on usdhc3-qspi-sel-hog.
> >>
> >> To achieve that, I can add a fake GPIO properties like below:
> >> &usdhc3{
> >>      …
> >>      hog-gpio = <&pcal6524 16 GPIO_ACTIVE_HIGH>;
> >> }
> >>
> >> Usdhc driver do not handle the hog-gpio, just use this fake hog-gpio to let the usdhc3 depends on pcal6524 IO expander. Make sure when usdhc driver probe, already select the usdhc3 pads on board.
> >>
> >> But this will trigger the DT check warning if related device binding has ““additionalProperties: false”  or  “unevaluatedProperties: false”.
> >>
> >> Can this be acceptable? Any thoughts for this case? I think this might be common user case for gpio-hog.
> > 
> > I've got no idea what this device you're talking about is - but it seems
> > to me like the "hog-gpio" property is what you should be doing (although
> > probably called something like "enable-gpios" instead.
> > What you would do is send a patch for the dt-binding for this device,
> > adding a property, in which case the *Properties: false will stop
> > warning.
> 
> If there is device dependency on the hog, I would say by definition of a
> hog that's not a hog. Hogs are for controller to initialize, but here
> your device driver needs it. This sounds like simple pin configuration
> for device.

┌──────┐                                
│      │      ┌─────┐P0  ┌─────────────┐
│      │      │     ├────► Device 1    │
│      │      │ EXT │    └─────────────┘
│ SOC  ├─────►│     │                   
│      │      │ MUX │P1  ┌─────────────┐
│      │      │     ├────► Device 2    │
│      │      │     │    └─────────────┘
│      │      └──▲──┘                   
│      │         │                      
│      │         │                      
└──────┘   GPIO ─┘                      

I think a typical case as above. There are external pinmux chip which
controller by some GPIO pins(maybe i2x gpio expendor). 

If device1 work,  gpio need set to 0.
If device2 work,  gpio need set to 1.

When dts descript device1 

device1{
	compatible="abc"
	pinctrl = <soc pin mux>; 
}

Need a place to set GPIO to 0. If it put to hog,  hog may probe later
than device1's driver probe, then devcie 1 failure to work.

How to to handle this case to make device depend on gpio. device1 always
probe after correct gpio to 0.

And, is it possible like.

mux
{
	compatible= "gpio-mux";
	port1{
  		phandle device1;
	}

	port2{
		phandle device2;
	}
}

"gpio-mux" driver export a sys entry,  when echo 0> sys,  device 1 probe
device 2 remove, 

when echo 1> /sys, device 2 probe,  device 1 remove from system.

Frank

> 
> Best regards,
> Krzysztof
> 

RE: Question about gpio-hog

[Bough Chen]

> -----Original Message-----
> From: Frank Li <frank.li@nxp.com>
> Sent: 2024年7月19日 3:53
> To: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Conor Dooley <conor@kernel.org>; Bough Chen <haibo.chen@nxp.com>;
> Linus Walleij <linus.walleij@linaro.org>; Rob Herring <robh@kernel.org>;
> linux-gpio@vger.kernel.org; 'devicetree@vger.kernel.org'
> <devicetree@vger.kernel.org>; imx@lists.linux.dev; Aisheng Dong
> <aisheng.dong@nxp.com>; Shenwei Wang <shenwei.wang@nxp.com>
> Subject: Re: Question about gpio-hog
> 
> On Thu, Jul 18, 2024 at 05:13:22PM +0200, Krzysztof Kozlowski wrote:
> > On 18/07/2024 16:47, Conor Dooley wrote:
> > > On Thu, Jul 18, 2024 at 03:40:49AM +0000, Bough Chen wrote:
> > >> Hi All,
> > >>
> > >> I have a question of ‘gpio-hog’, the property gpio-hog seems to be used in
> GPIO node rather than in users device node, so we can’t use the device-link
> feature.
> > >> (sorry for resend, I use text/plain messages this time)
> > >>
> > >> e.g.
> > >>
> > >> pcal6524: gpio@22 {
> > >>       …
> > >> 　　　/* usdhc3 and QSPI share the same pin, here select SD3 pins */
> > >> 　　　usdhc3-qspi-sel-hog {
> > >> 　　　　　　gpio-hog;
> > >> 　　　　　　gpios = <16 GPIO_ACTIVE_HIGH>;
> > >> 　　　　　　output-high;
> > >> 　　　};
> > >> 　　　…
> > >> };
> > >>
> > >> &usdhc3 {
> > >>      …
> > >> }
> > >>
> > >> The board share the pins of usdhc3 and QSPI, a MUX use one GPIO pad
> from one I2C GPIO expander to control the selection.
> > >> So before usdhc3 probe, need to make sure the gpio-hog is configed. Which
> means usdhc3 need to depend on usdhc3-qspi-sel-hog.
> > >>
> > >> To achieve that, I can add a fake GPIO properties like below:
> > >> &usdhc3{
> > >>      …
> > >>      hog-gpio = <&pcal6524 16 GPIO_ACTIVE_HIGH>; }
> > >>
> > >> Usdhc driver do not handle the hog-gpio, just use this fake hog-gpio to let
> the usdhc3 depends on pcal6524 IO expander. Make sure when usdhc driver
> probe, already select the usdhc3 pads on board.
> > >>
> > >> But this will trigger the DT check warning if related device binding has
> ““additionalProperties: false”  or  “unevaluatedProperties: false”.
> > >>
> > >> Can this be acceptable? Any thoughts for this case? I think this might be
> common user case for gpio-hog.
> > >
> > > I've got no idea what this device you're talking about is - but it
> > > seems to me like the "hog-gpio" property is what you should be doing
> > > (although probably called something like "enable-gpios" instead.
> > > What you would do is send a patch for the dt-binding for this
> > > device, adding a property, in which case the *Properties: false will
> > > stop warning.
> >
> > If there is device dependency on the hog, I would say by definition of
> > a hog that's not a hog. Hogs are for controller to initialize, but
> > here your device driver needs it. This sounds like simple pin
> > configuration for device.
> 
> ┌──────┐
> │      │      ┌─────┐P0  ┌─────────────┐
> │      │      │     ├────► Device 1    │
> │      │      │ EXT │    └─────────────┘
> │ SOC  ├─────►│     │
> │      │      │ MUX │P1  ┌─────────────┐
> │      │      │     ├────► Device 2    │
> │      │      │     │    └─────────────┘
> │      │      └──▲──┘
> │      │         │
> │      │         │
> └──────┘   GPIO ─┘
> 
> I think a typical case as above. There are external pinmux chip which controller
> by some GPIO pins(maybe i2x gpio expendor).
> 
> If device1 work,  gpio need set to 0.
> If device2 work,  gpio need set to 1.
> 
> When dts descript device1
> 
> device1{
> 	compatible="abc"
> 	pinctrl = <soc pin mux>;
> }
> 
> Need a place to set GPIO to 0. If it put to hog,  hog may probe later than
> device1's driver probe, then devcie 1 failure to work.
> 
> How to to handle this case to make device depend on gpio. device1 always
> probe after correct gpio to 0.
> 
> And, is it possible like.
> 
> mux
> {
> 	compatible= "gpio-mux";
> 	port1{
>   		phandle device1;
> 	}
> 
> 	port2{
> 		phandle device2;
> 	}
> }
> 
> "gpio-mux" driver export a sys entry,  when echo 0> sys,  device 1 probe
> device 2 remove,
> 
> when echo 1> /sys, device 2 probe,  device 1 remove from system.

This seems not the typical usage of gpio-mux. Usually gpio-mux will not contain sub node, instead, other node will refer this gpio-mux.

+Shawn and Fabio.

Just like Frank's diagram shows，it is the special board design which involve the mux, so logically, all things related to the mux should be transparent to device1/2 from the device driver side. So gpio-hog seems to be more suitable here. But from the board level side, there did has a dependency between the mux and device1/2. 
The situation here seems more like a pinctrl mux through gpio.

Best Regards
Haibo Chen

> 
> Frank
> 
> >
> > Best regards,
> > Krzysztof
> >