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. Best regards, Krzysztof