Re: pinctrl-sx150x.c broken in 4.11

[Tony Lindgren <tony@xxxxxxxxxxx>]

* Nikita Yushchenko <nikita.yoush@xxxxxxxxxxxxxxxxxx> [170511 09:27]:
> > 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?

> > But at least with updating the probe to use pinctrl_register_and_init()
> > and pinctrl_enable() the driver can do something before the hogs are
> > claimed. I just don't know what the driver would here as I don't
> > understand the "misinterpreted as hog" part :)
> 
> Tried to explain above :)

Yup OK based on that this seems like a pinctrl core issue.

Regards,

Tony
--
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