From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: rob.herring@calxeda.com, pawel.moll@arm.com,
mark.rutland@arm.com, ian.campbell@citrix.com,
grant.likely@linaro.org, devicetree@vger.kernel.org,
linux-sh@vger.kernel.org, nobuhiro.iwamatsu.yj@renesas.com,
rob@landley.net, linux-doc@vger.kernel.org
Subject: Re: [PATCH v2 2/2] sh_eth: add device tree support
Date: Tue, 10 Sep 2013 18:39:54 +0400 [thread overview]
Message-ID: <522F2F3A.5070406@cogentembedded.com> (raw)
In-Reply-To: <522E3770.9020305@wwwdotorg.org>
Hello.
On 10-09-2013 1:02, Stephen Warren wrote:
>> Add support of the device tree probing for the Renesas SH-Mobile SoCs
>> documenting the device tree binding as necessary.
>> This work is loosely based on an original patch by Nobuhiro Iwamatsu
>> <nobuhiro.iwamatsu.yj@renesas.com>.
>> Index: net-next/Documentation/devicetree/bindings/net/sh_eth.txt
>> +- reg: offset and length of (1) the E-DMAC/feLic register block (required),
>> + (2) the TSU register block (optional).
> There's an argument that you should specify reg-names entries to allow
> arbitrary ordering or entries within reg, if there's more than one
> entry. But, I don't think it's mandatory, just something to consider at
> present.
I also don't think it's needed, the driver has happily worked without
resource names so far.
>> +- interrupts: interrupt specifier for the sole interrupt.
>> +- phy-mode: string, operation mode of the PHY interface (a string that
>> + of_get_phy_mode() can understand).
> DT bindings should be OS-agnostic. of_get_phy_mode() is Linux-specific.
> Please spell out the complete list of supported values here, without
> reference to Linux-specific code or documentation.
I don't think listing the numerous values of this standrd property in
every file describing an Ethernet device is practical. How about I create file
ethernet.txt in the same directory (don't know why I'm the first to do it
despite many other driver using this property)?
>> +- phy-handle: phandle of the PHY device (there should be a PHY device subnode).
> Is this a custom property, or part of some generic PHY subsystem
> binding?
The latter.
> If the latter, please reference the DT binding document for
> that subsystem.
Unfortunately, phy.txt in the same directory describes only properties of
the "ethernet-phy" nodes. I think the new ethernet.txt would be more fitting
for the purpose.
> If it's custom, what kinds of nodes can this phandle
> point at; what kind of interface must the referenced DT node provide (is
> a #phy-cells property required, must its compatible value be one of a
> specific set of values).
This is described by the phy.txt in the same directory.
>> +- #address-cells: number of address cells for the MDIO bus, must be equal to 1.
>> +- #size-cells: number of size cells on the MDIO bus, must be equal to 0.
> If this node is expected to contain child nodes, you need to specify
> details of those child nodes.
They are specified in phy.txt (this file is somewhat obsolete though).
> Can you reference the filename of a generic MDIO binding?
OK.
> What do the address values mean (perhaps that'd be
> covered by the MDIO binding already, if it's applicable).
>> +Optional properties:
>> +- interrupt-parent: the phandle for the interrupt controller that services
>> + interrupts for this device.
>> +- local-mac-address: 6 bytes, MAC address.
>> +- renesas,no-ether-link: boolean, specify when a board does not provide a proper
>> + Ether LINK signal.
>> +- renesas,ether-link-active-low: boolean, specify when the Ether LINK signal is
>> + active-low instead of normal active-high.
> Presumably the link signal is some dedicated signal in the Ethernet MAC
> HW block, and not a generic GPIO?
Indeed.
> Do you need any clocks properties, IP block reset signals, power domains?
Currently not.
WBR, Sergei
next prev parent reply other threads:[~2013-09-10 14:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 23:43 [PATCH v2 2/2] sh_eth: add device tree support Sergei Shtylyov
2013-09-09 21:02 ` Stephen Warren
2013-09-10 14:39 ` Sergei Shtylyov [this message]
2013-09-10 15:15 ` Stephen Warren
2013-09-10 18:01 ` Sergei Shtylyov
2013-09-10 20:07 ` Stephen Warren
2013-09-10 21:48 ` Sergei Shtylyov
2013-09-10 22:21 ` Stephen Warren
2013-10-16 22:41 ` Sergei Shtylyov
2013-10-17 16:41 ` 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=522F2F3A.5070406@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=ian.campbell@citrix.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=nobuhiro.iwamatsu.yj@renesas.com \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=swarren@wwwdotorg.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).