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