Re: [PATCH 08/17] clk: imx: convert to devm_platform_ioremap_resource

From: Thierry Reding <thierry.reding@gmail.com>
To: Leonard Crestez <leonard.crestez@nxp.com>
Cc: "kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
	"pgaikwad@nvidia.com" <pgaikwad@nvidia.com>,
	"heiko@sntech.de" <heiko@sntech.de>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"chunhui.dai@mediatek.com" <chunhui.dai@mediatek.com>,
	Yangtao Li <tiny.windzz@gmail.com>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"palmer@sifive.com" <palmer@sifive.com>,
	"nsekhar@ti.com" <nsekhar@ti.com>,
	"tomasz.figa@gmail.com" <tomasz.figa@gmail.com>,
	"rfontana@redhat.com" <rfontana@redhat.com>,
	"weiyongjun1@huawei.com" <weiyongjun1@huawei.com>,
	"s.nawrocki@samsung.com" <s.nawrocki@samsung.com>,
	"manivannan.sadhasivam@linaro.org"
	<manivannan.sadhasivam@linaro.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"festevam@gmail.com" <festevam@gmail.com>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"john@phrozen.org" <john@p>
Subject: Re: [PATCH 08/17] clk: imx: convert to devm_platform_ioremap_resource
Date: Tue, 10 Dec 2019 14:21:46 +0100	[thread overview]
Message-ID: <20191210132146.GF2703785@ulmo> (raw)
In-Reply-To: <VI1PR04MB7023BD6E46B6DEEBBB762060EE580@VI1PR04MB7023.eurprd04.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 3074 bytes --]

On Mon, Dec 09, 2019 at 08:44:39PM +0000, Leonard Crestez wrote:
> On 09.12.2019 21:58, Yangtao Li wrote:
> > Use devm_platform_ioremap_resource() to simplify code.
> > 
> > Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
> > ---
> >   drivers/clk/imx/clk-imx8qxp-lpcg.c | 6 +-----
> >   1 file changed, 1 insertion(+), 5 deletions(-)
> > 
> > diff --git a/drivers/clk/imx/clk-imx8qxp-lpcg.c b/drivers/clk/imx/clk-imx8qxp-lpcg.c
> > index c0aff7ca6374..10ae712447c6 100644
> > --- a/drivers/clk/imx/clk-imx8qxp-lpcg.c
> > +++ b/drivers/clk/imx/clk-imx8qxp-lpcg.c
> > @@ -164,7 +164,6 @@ static int imx8qxp_lpcg_clk_probe(struct platform_device *pdev)
> >   	struct clk_hw_onecell_data *clk_data;
> >   	const struct imx8qxp_ss_lpcg *ss_lpcg;
> >   	const struct imx8qxp_lpcg_data *lpcg;
> > -	struct resource *res;
> >   	struct clk_hw **clks;
> >   	void __iomem *base;
> >   	int i;
> > @@ -173,10 +172,7 @@ static int imx8qxp_lpcg_clk_probe(struct platform_device *pdev)
> >   	if (!ss_lpcg)
> >   		return -ENODEV;
> >   
> > -	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > -	if (!res)
> > -		return -EINVAL;
> > -	base = devm_ioremap(dev, res->start, resource_size(res));
> > +	base = devm_platform_ioremap_resource(pdev, 0);
> >   	if (!base)
> >   		return -ENOMEM;
> 
> This breaks imx8qxp-mek boot by causing most peripherals (like uart) to 
> fail to probe.
> 
> The old and new paths are not equivalent: devm_platform_ioremap_resource
> calls devm_ioremap_resource which differs from devm_ioremap by also 
> calling devm_request_mem_region.
> 
> This prevents other mappings in the area and imx8qxp-lpcg nodes map 
> whole hardware "subsystems" and overlap most peripherals. For example:
> 
>                   adma_lpcg: clock-controller@59000000 {
>                           compatible = "fsl,imx8qxp-lpcg-adma";
>                           reg = <0x59000000 0x2000000>;
>                           #clock-cells = <1>;
> 		};
> 
>                  adma_lpuart0: serial@5a060000 {
> 			reg = <0x5a060000 0x1000>;
> 			...
> 		};

The whole point of doing a request_mem_region() is to avoid having
multiple drivers trample on each others' mappings. What you do above
doesn't look right. Why does that clock controller need access to 32
MiB of I/O memory space?

That said, there are legitimate reasons for sharing mappings across
drivers, so I agree that automated conversions like this should be done
very carefully. The difficulty is that there are cases where drivers
simply omitted that request_mem_region() by mistake and where the
conversion can be correct (and in fact an improvement), but we can't
make the assumption blindly.

Thierry

> I don't know if this issue affects any other platforms (imx8 lpcg 
> bindings are unusual) but if you found this with an automated tool 
> perhaps it should be adjusted?
> 
> By my count it's the 4th time this incorrect cleanup was posted.
> 
> Previously: https://lkml.org/lkml/2019/12/4/487
> 
> --
> Regards,
> Leonard

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]