linux-kernel - Re: PXA25x: GPIO driver fails probe due to resource conflict with pinctrl driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 8 Dec 2022 19:10:25 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Robert Jarzmik <robert.jarzmik@...e.fr>
Cc:     Jonathan Neuschäfer <j.neuschaefer@....net>,
        Andrew Lunn <andrew@...n.ch>,
        linux-arm-kernel@...ts.infradead.org,
        Haojian Zhuang <haojian.zhuang@...il.com>,
        Daniel Mack <daniel@...que.org>, linux-kernel@...r.kernel.org
Subject: Re: PXA25x: GPIO driver fails probe due to resource conflict with
 pinctrl driver

On Thu, Dec 08, 2022 at 07:46:26PM +0100, Robert Jarzmik wrote:
> 
> Jonathan Neuschäfer <j.neuschaefer@....net> writes:
> 
> > Without further code changes this wouldn't be sufficient, because the
> > pinctrl driver also touches the GPIO direction registers at offset
> > 0x0c-0x14.
> 
> Historically, this problem was adressed by a "hack" if I remember correctly,
> as the
> registers do overlap (on pxa27x at least, but I think on pxa25x as well) :
> - GAFR (alternate functions) and GPDR (input or output) are  "pinctrl"
> - GPSR, GPCR, GPLR are "gpio" registers
> - the memory map (physical) at 0x40e0 0000 is as Jonathan wrote :
>  - 3 u32 GPLR (gpio)
>  - 3 u32 GPDR (pinctrl)
>  - 3 u32 GPSR (gpio)
>  - 3 u32 GPCR (gpio)
> 
> The "hack" was that one driver was mapping the area _without_ claiming it
> (this
> is part from memory, I didn't check in the code today). The gpio was
> probably
> the claiming one, while the pinctrl was the "only using one".
> 
> As of today, I should have a look what was changed, but I'm pretty sure in
> all
> pxa2xx architecture there is an overlap, as for these ancient platforms the
> pinctrl wasn't yet separated from the gpio IC.
> 
> The only was out so far I can see from my head would be to declare multiple
> very small IO ranges :
> - pinctrl pxa25x : 0x40e0 000c (12 bytes), 0x40e0 0054 (32 bytes)
> - pinctrl pxa25x : 0x40e0 000c (12 bytes), 0x40e0 0054 (32 bytes),  0x40e0
> 010c (4 bytes)
> - gpio : from 0x40e0 0000 to 0x40e0 0070 included, without the  pinctrl ones
> 
> As a general guide, in gpio-pxa.c, you have the table in [1]. Think GPDR and
> GAFR as
> pinctrl, and all the other ones as gpio. Ah and yes, the GAFR ones are
> missing in this
> table.
> 
> One last think : in a pre device-tree world, when we didn't had yet the pxa
> pinctrl
> driver, the gpio driver was directly playing with the GPDR registers, fun
> old times.

>From a quick look, I think this commit is to blame:

542c25b7a209 drivers: gpio: pxa: use devm_platform_ioremap_resource()

Someone "helpfully" making this change:

-       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-       if (!res)
-               return -EINVAL;
-       gpio_reg_base = devm_ioremap(&pdev->dev, res->start,
-                                    resource_size(res));
+
+       gpio_reg_base = devm_platform_ioremap_resource(pdev, 0);

which introduces request_mem_region() to the PXA GPIO driver, resulting
in this resource clash.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!