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