Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1639898
| From | Nikita Yushchenko <nikita.yoush@cogentembedded.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: pinctrl-sx150x.c broken in 4.11 |
| Date | 2017-05-11 19:00 +0200 |
| Message-ID | <tFZBv-s6-1@gated-at.bofh.it> (permalink) |
| References | <tFFCO-4HE-25@gated-at.bofh.it> <tFQHT-3k5-1@gated-at.bofh.it> <tFY2L-81A-39@gated-at.bofh.it> <tFZ8u-dN-31@gated-at.bofh.it> <tFZi9-ha-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
>>> 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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
pinctrl-sx150x.c broken in 4.11 Nikita Yushchenko <nikita.yoush@cogentembedded.com> - 2017-05-10 21:40 +0200
Re: pinctrl-sx150x.c broken in 4.11 Linus Walleij <linus.walleij@linaro.org> - 2017-05-11 09:30 +0200
Re: pinctrl-sx150x.c broken in 4.11 Tony Lindgren <tony@atomide.com> - 2017-05-11 17:20 +0200
Re: pinctrl-sx150x.c broken in 4.11 Nikita Yushchenko <nikita.yoush@cogentembedded.com> - 2017-05-11 18:30 +0200
Re: pinctrl-sx150x.c broken in 4.11 Tony Lindgren <tony@atomide.com> - 2017-05-11 18:40 +0200
Re: pinctrl-sx150x.c broken in 4.11 Nikita Yushchenko <nikita.yoush@cogentembedded.com> - 2017-05-11 19:00 +0200
Re: pinctrl-sx150x.c broken in 4.11 Tony Lindgren <tony@atomide.com> - 2017-05-11 20:00 +0200
Re: pinctrl-sx150x.c broken in 4.11 Nikita Yushchenko <nikita.yoush@cogentembedded.com> - 2017-05-11 21:20 +0200
Re: pinctrl-sx150x.c broken in 4.11 Linus Walleij <linus.walleij@linaro.org> - 2017-05-12 11:40 +0200
csiph-web