Question about gpio-hog

[Bough Chen <haibo.chen@xxxxxxx>]

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