From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932879AbdEKQ5z (ORCPT ); Thu, 11 May 2017 12:57:55 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:38640 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751262AbdEKQ5x (ORCPT ); Thu, 11 May 2017 12:57:53 -0400 Subject: Re: pinctrl-sx150x.c broken in 4.11 To: Tony Lindgren References: <04424bd9-daba-e803-23ce-e7604bf41c71@cogentembedded.com> <20170511151647.GT3489@atomide.com> <252b379a-d3fe-8020-5209-f1de43004b08@cogentembedded.com> <20170511163615.GU3489@atomide.com> Cc: Linus Walleij , "linux-gpio@vger.kernel.org" , Andrey Smirnov , Chris Healy , Jeff White , "linux-kernel@vger.kernel.org" , Geert Uytterhoeven From: Nikita Yushchenko Message-ID: <7f79af49-2aae-2bd2-4b85-e65220cb27e8@cogentembedded.com> Date: Thu, 11 May 2017 19:57:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170511163615.GU3489@atomide.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> 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