[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <543F4CF0.8080404@free-electrons.com>
Date: Thu, 16 Oct 2014 06:43:28 +0200
From: Michael Opdenacker <michael.opdenacker@...e-electrons.com>
To: Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>,
Andrew Lunn <andrew@...n.ch>
CC: dwmw2@...radead.org, computersforpeace@...il.com,
jg1.han@...sung.com, linux-mtd@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mtd: orion_nand: fix error code path in probe
Andrew, Ezequiel,
Many thanks for your review!
On 10/15/2014 11:39 PM, Ezequiel Garcia wrote:
> On 14 Oct 11:35 PM, Andrew Lunn wrote:
>
>> Hi Michael
>>
>> It is quite a common pattern to use:
>>
>> res = platform_get_resource(dev, IORESOURCE_MEM, 0);
>> c->membase = devm_ioremap_resource(&dev->dev, res);
>> if (IS_ERR(c->membase))
>> return PTR_ERR(c->membase)
>>
>> which is more compact.
I like it, thanks for the suggestion!
>>
> Be careful with this. devm_ioremap and devm_ioremap_resource are not
> the same thing, as the former requests the region as well.
>
> It can break things if the region is shared across several drivers.
> I don't think this is the case, so in fact adding the request is correct,
> but it's a more intrusive change than just "code cleanup".
Right. If I understand correctly, requesting the region should always be
done anyway, so this should be a welcome change.
What Andrew suggests also changes the return value: -ENOMEM instead of
-EIO, though it should be more standard. This could have side effects too!
I'll post a V2 right away.
Thanks again!
Cheers,
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists