>>> Hmm maybe yeah. I don't quite follow the above the "pinctrl-0 property >>> of sx150x device tree node, is misinterpreted as hog" part though. >> >> sx150x is i2c-gpio device. It has 16 GPIO lines that are communicated >> with via i2c bus, and an interrupt line. >> >> Interrupt line is typically connected to SoC's pin. >> This pin has to be configured. >> This is done by providing appropriate subnode in SoC's pinmux node, with >> information with pin configuration, and pinctrl-0 property in sx150x's >> node with phandle to that subnode: >> >> ... >> &i2c0 { >> sx1503@20 { >> compatible = "semtech,sx1503q"; >> pinctrl-names = "default"; >> pinctrl-0 = <&pinctrl_sx1503_20>; >> ... >> }; >> }; >> ... >> &iomuxc { >> pinctrl_sx1503_20: pinctrl-sx1503-20 { >> fsl,pins = < >> VF610_PAD_PTB1__GPIO_23 0x219d >> >; >> }; >> }; >> >> This pin configuration is handled by driver core, i.e. before probe() >> for sx150x is called, core applies pin configuration. >> >> However sx150x driver is currently implemented as a pinctrl driver. >> >> When it initializes, pinctrl searches for "hog", i.e. pin config that >> should be applied at driver registration time. >> >> While doing so, core searches for any registered pinctrl_map for device >> being register. Search loop is in create_pinctrl(). >> >> In this case, this loop finds map that is defined above. >> >> This is *not* hog. This is pin setting already applied in SoC's pinmux >> controller for sx1503 device. >> >> However code in create_pinctrl() tries to apply it, and use sx1503's >> methods to do so. Which is plain wrong and errors out. > > Maybe create_pinctrl() could check if the pin controller device > for a potential hog points to the device itself and bail out > if that's not the case? Well that's exactly what patch from my first mail in this thread does. This indeed fixes my case, but I don't know if it is correct in generic case. Should I submit it? Do you ack? Nikita -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html