From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 13/14] ARM: STi: DT: STiH410: Add usb2 picophy dt nodes
Date: Thu, 13 Nov 2014 18:41:56 +0100 [thread overview]
Message-ID: <2401196.5cvW5dPSz2@wuerfel> (raw)
In-Reply-To: <20141113145419.GA30296@griffinp-ThinkPad-X1-Carbon-2nd>
On Thursday 13 November 2014 14:54:19 Peter Griffin wrote:
>
> >
> > It also seems that you have put the node in the wrong place, as the reg
> > property apparently refers to a different address space. Did you mean
> > to put this under the syscfg_core node?
>
> Your correct in that it refers to the syscfg_core address space.
> However I intentionaly didn't put it under the syscfg_core node.
>
> The phy is more unique than most other devices in that in this instance it
> is only controlled from two syscfg_core registers which happen to be in the same
> sysconf bank.
>
> However most other devices tend to have a combination of some memory mapped
> registers and also some sysconfig registers which does then create a conflict
> over where the dt node should live.
>
> Currently I can't find an example but there is also no guarentee that a
> device will not have some configuration bits in syscfg_core and some
> other bits in syscfg_rear/front registers. The phy for example could
> have had one register in each, which would make deciding where to put
> it difficult.
>
> So to create coherency / conformity we decided to put all the IP blocks under the soc node.
>
> Also its worth pointing if your not already aware that sysconf_core/rear/front isn't
> really a device, it's just a regmap abstraction of some memory mapped configuration
> registers where a bunch of seemingly random control bits get stuffed.
>
> Of course if you feel strongly about it I can of course change it like you suggested,
> but that is the reasoning / rationale of why it was done like this initially.
The problem is your use of the 'reg' property. If it doesn't refer to the
node's address space, it shouldn't be called 'reg'.
Please fix the binding.
Arnd
next prev parent reply other threads:[~2014-11-13 17:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 11:00 [PATCH v2 00/14] Add stih410 SoC and USB2/1.1 support Peter Griffin
2014-11-13 11:00 ` [PATCH v2 01/14] ARM: STi: DT: STiH416: Add pinctl setup for usb controllers Peter Griffin
2014-11-13 11:00 ` [PATCH v2 02/14] ARM: STi: DT: STiH416: Add DT node for the stih415/6 usb2 phy Peter Griffin
2014-11-13 11:00 ` [PATCH v2 03/14] ARM: STi: DT: STiH416: Add DT nodes for the ehci and ohci usb controllers Peter Griffin
2014-11-13 11:00 ` [PATCH v2 04/14] ARM: multi_v7_defconfig: Enable st ohci and ehci HCD drivers Peter Griffin
2014-11-13 11:00 ` [PATCH v2 05/14] ARM: multi_v7_defconfig: Enable stih415/6 usb2 phy driver Peter Griffin
2014-11-13 11:00 ` [PATCH v2 06/14] ARM: multi_v7_defconfig: Enable stih407 usb picophy Peter Griffin
2014-11-13 11:00 ` [PATCH v2 07/14] ARM: STi: DT: STiH407: Add usb2 picophy dt nodes Peter Griffin
2014-11-13 11:00 ` [PATCH v2 08/14] ARM: STi: DT: STiH410: Add defines for STiH410 DT clocks Peter Griffin
2014-11-13 11:00 ` [PATCH v2 09/14] ARM: STi: DT: STiH410: Add pinctl config for usb controllers Peter Griffin
2014-11-13 11:00 ` [PATCH v2 10/14] ARM: STi: DT: STih407: Abstract common dt nodes into shared files Peter Griffin
2014-11-13 11:00 ` [PATCH v2 11/14] ARM: STi: DT: STiH410: Add STiH410 SoC and b2120 board support Peter Griffin
2014-11-13 11:00 ` [PATCH v2 12/14] ARM: STi: DT: STih407: STih410: Add clk_ignore_unused to kernel bootargs Peter Griffin
2014-11-13 11:00 ` [PATCH v2 13/14] ARM: STi: DT: STiH410: Add usb2 picophy dt nodes Peter Griffin
2014-11-13 11:15 ` Arnd Bergmann
2014-11-13 14:54 ` Peter Griffin
2014-11-13 17:41 ` Arnd Bergmann [this message]
2014-11-14 9:56 ` Peter Griffin
2014-11-14 11:03 ` Arnd Bergmann
2014-11-14 13:34 ` Peter Griffin
2014-11-14 14:59 ` Arnd Bergmann
2014-11-13 11:00 ` [PATCH v2 14/14] ARM: STi: DT: STiH410: Add DT nodes for the ehci and ohci usb controllers Peter Griffin
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=2401196.5cvW5dPSz2@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).