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:
signature.asc
Description: PGP signature
