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
