Re: pinctrl-sx150x.c broken in 4.11

[Nikita Yushchenko]

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