From: Lee Jones <lee.jones@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
devicetree <devicetree@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x
Date: Tue, 24 Jun 2014 13:46:34 +0100 [thread overview]
Message-ID: <20140624124634.GO13803@lee--X1> (raw)
In-Reply-To: <6599289.0ZjjaMbRqj@wuerfel>
> > > > converting all addresses to to resources so drivers can easily pull
> > > > them out using platform_get_resource() and friends. Pushing the reg
> > >
> > > right. Can't we use of_address_to_resource here?
> >
> > We could, but that would be an extra layer. We'd be pulling the
> > address, putting it into a resource, then pulling it from the resource
> > for use. If we're going to be pulling addresses out manually, we're
> > probably better off using of_get_address(). But again, we're just
> > carrying out functionality which is already provided by the
> > framework.
>
> there is also of_ioremap().
Isn't this SPARK only? And doesn't it require a populated resource?
Which is what I'm saying is the issue here i.e. we don't have one.
> > > > properties down into a child node means that we have to now iterate
> > > > over the sub-nodes and pull them out manually. This will lead to a
> > >
> > > You anyway iterate while creating PHYs based on some constant. Now you have to
> > > iterate over the sub-nodes.
> > > > pretty messy implementation IMHO.
> >
> > This much is true.
> >
> > > > Can you point me in the direction of previous implementations where you
> > > > have stipulated the same set of constraints please?
> > >
> > > ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> > > this will just add to the complexity of the driver.
> >
> > =:)
> >
> > > Maybe we should ask the opinion of others?
> >
> > We could. I'll CC Arnd as he likes this PHY stuff. :)
> >
> > > [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
>
> Having sub-nodes for each individual PHY managed by a controller seems
> very reasonable to me. Making them show up as separate platform devices
> seems less useful though.
Are there any examples of other nodes with reg properties, but not
compatible strings i.e. ones that aren't probed independently and
aren't platform devices that I can use for reference. I'm having a
hard time figuring out how to _easily_ obtain indexed addresses
without adding a bunch of new code. Perhaps if we did something in
the core there would be less overhead overall?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-06-24 12:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1400766819-22286-1-git-send-email-lee.jones@linaro.org>
[not found] ` <1400766819-22286-2-git-send-email-lee.jones@linaro.org>
[not found] ` <5396E561.4020805@ti.com>
[not found] ` <20140617112353.GB4139@lee--X1>
2014-06-18 9:50 ` [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x Kishon Vijay Abraham I
2014-06-18 10:04 ` Lee Jones
2014-06-24 9:38 ` Arnd Bergmann
2014-06-24 12:46 ` Lee Jones [this message]
2014-06-24 14:08 ` Arnd Bergmann
2014-06-24 14:51 ` Lee Jones
2014-02-14 11:23 Lee Jones
2014-03-05 7:34 ` Mark Rutland
2014-03-05 8:40 ` Lee Jones
2014-03-05 9:12 ` Lee Jones
-- strict thread matches above, loose matches on Subject: below --
2014-02-12 16:03 Lee Jones
2014-02-12 16:40 ` Mark Rutland
2014-02-13 11:03 ` Lee Jones
2014-02-13 12:23 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140624124634.GO13803@lee--X1 \
--to=lee.jones@linaro.org \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sergei.shtylyov@cogentembedded.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox