RE: Question about gpio-hog

[Bough Chen <haibo.chen@xxxxxxx>]

> -----Original Message-----
> From: Frank Li <frank.li@xxxxxxx>
> Sent: 2024年7月19日 3:53
> To: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
> Cc: Conor Dooley <conor@xxxxxxxxxx>; Bough Chen <haibo.chen@xxxxxxx>;
> Linus Walleij <linus.walleij@xxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>;
> linux-gpio@xxxxxxxxxxxxxxx; 'devicetree@xxxxxxxxxxxxxxx'
> <devicetree@xxxxxxxxxxxxxxx>; imx@xxxxxxxxxxxxxxx; Aisheng Dong
> <aisheng.dong@xxxxxxx>; Shenwei Wang <shenwei.wang@xxxxxxx>
> 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
> >