On Thu, Jul 18, 2024 at 05:13:22PM +0200, Krzysztof Kozlowski wrote:
> 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.
┌──────┐
│ │ ┌─────┐P0 ┌─────────────┐
│ │ │ ├────► Device 1 │
│ │ │ EXT │ └─────────────┘
│ SOC ├─────►│ │
│ │ │ MUX │P1 ┌─────────────┐
│ │ │ ├────► Device 2 │
│ │ │ │ └─────────────┘
│ │ └──▲──┘
│ │ │
│ │ │
└──────┘ GPIO ─┘
I think a typical case as above. There are external pinmux chip which
controller by some GPIO pins(maybe i2x gpio expendor).
If device1 work, gpio need set to 0.
If device2 work, gpio need set to 1.
When dts descript device1
device1{
compatible="abc"
pinctrl = <soc pin mux>;
}
Need a place to set GPIO to 0. If it put to hog, hog may probe later
than device1's driver probe, then devcie 1 failure to work.
How to to handle this case to make device depend on gpio. device1 always
probe after correct gpio to 0.
And, is it possible like.
mux
{
compatible= "gpio-mux";
port1{
phandle device1;
}
port2{
phandle device2;
}
}
"gpio-mux" driver export a sys entry, when echo 0> sys, device 1 probe
device 2 remove,
when echo 1> /sys, device 2 probe, device 1 remove from system.
Frank
>
> Best regards,
> Krzysztof
>
