[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VfV7actoXkMUbh9KwAXR1FKR_VZ5RAuaL-pKLSynFi-3g@mail.gmail.com>
Date: Wed, 13 Jun 2018 02:16:05 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers/of: Add devm_of_iomap()
On Wed, Jun 13, 2018 at 1:58 AM, Benjamin Herrenschmidt
<benh@...nel.crashing.org> wrote:
> On Tue, 2018-06-12 at 19:53 +0300, Andy Shevchenko wrote:
>>
>> > > It feels like a wrong approach.
>> > > Can OF graph help here? Would it be better approach?
>> >
>> > I don't quite understand what your objection is nor what "OF graph"
>> > is...
>>
>> There is no objection per se, just a doubt that this is a right thing to do.
>> I might be wrong, of course.
>>
>> OF graph nodes is a special API that allows you to access like you
>> said "different node of device-tree".
>> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/graph.txt
>
> So I had a look and this is just an example on how to use phandles to
> link ports and endpoints... I fail to see how that relates to what this
> patch does.
Because your patch does nothing except another layring of the existing APIs.
> In the driver I'm doing for example, I do use a similar technique to
> "point" to the other node. In this case, this is a coprocessor in the
> SoC and I'm linking to the node that represent its interrupt controller
> (and its not a full fledged OS running there so we don't have a full
> interrupt tree for it).
Hmm... So, you are trying to solve problem with other methods which
might be not so suitable at all?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists