[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161212180021.3791c986@bbrezillon>
Date: Mon, 12 Dec 2016 18:00:21 +0100
From: Boris Brezillon <boris.brezillon@...e-electrons.com>
To: Robert Jarzmik <robert.jarzmik@...e.fr>
Cc: arvind Yadav <arvind.yadav.cs@...il.com>, dwmw2@...radead.org,
computersforpeace@...il.com, marek.vasut@...il.com, richard@....at,
cyrille.pitchen@...el.com, linux-mtd@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [V2] mtd: devices: docg3:- Handle return value of devm_ioremap.
On Mon, 12 Dec 2016 17:32:58 +0100
Robert Jarzmik <robert.jarzmik@...e.fr> wrote:
> arvind Yadav <arvind.yadav.cs@...il.com> writes:
>
> > There is problem, if you will use devm_ioremap_resource instead of devm_ioremap,
> > than devm_ioremap_resource will call request_mem_region().
> > request_mem_region() allows to tell the kernel that this driver is going to use
> > this range of I/O addresses, which will prevent other drivers to make an
> > overlapping call to request_mem_region If other driver want to use same address
> > space to access then it will not allow. Means we can not share same address
> > space
> > between two driver.
>
> Hi,
>
> You're right Arvind, and still, it's worth noticing that the docg3 access
> semantics imply a "reserved" resource path (see how doc_register_readb() does a
> write and how this cannot be shared with another driver).
>
> Therefore I'll be willing to ack a mix of your both patches, the
> devm_ioremap_resource() from Boris and the error message from your patch.
devm_ioremap_resource() already prints different error messages
depending on the error type [1], no need to duplicate it.
[1]http://lxr.free-electrons.com/source/lib/devres.c#L134
Powered by blists - more mailing lists