netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Cc: Stefan Roese <sr@denx.de>,
	netdev@vger.kernel.org, Viresh Kumar <viresh.kumar@st.com>,
	devicetree-discuss@ozlabs.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] stmmac: Add device-tree support
Date: Mon, 12 Mar 2012 15:07:26 -0500	[thread overview]
Message-ID: <4F5E577E.7090808@gmail.com> (raw)
In-Reply-To: <4F5E2858.4000708@st.com>

On 03/12/2012 11:46 AM, Giuseppe CAVALLARO wrote:
> On 3/12/2012 5:23 PM, Stefan Roese wrote:
>> On Monday 12 March 2012 16:30:37 Giuseppe CAVALLARO wrote:
>>>>>> +Required properties:
>>>>>> +- compatible: Should be "stm,gmac"
>>>>>
>>>>> This is too generic. This should be 1 string per version of h/w.
>>>>
>>>> Viresh, Giuseppe, can you please suggest a proper string for the SPEAr600
>>>> STMMAC core, including version?
>>>>
>>>>> 'stm' should be 'st' according to vendor-prefixes.txt.
>>>
>>> I'm not familiar with devicetree; maybe we should have:
>>>
>>> "stmicro,mac100"
>>> "stmicro,gmac"
>>>
>>> or: st instead of stmicro if you prefer.
>>>
>>> in fact, stmmac is for mac100 and gmac devices.
>>
>> How about "st,spear600-gmac" for SPEAr600 then?
> 
> IIUC, as final result we should have something like this... that sounds
> quite good to me.
> 
> ST/ARM SPEAr
> "st,spear600-gmac"
> "st,spear1310-gmac"
>   ...
> 
> ST/SH
> 
> "st,stx7108-gmac"
> "st,stx7106-gmac"
> "st,stx7109-mac"    ->>> mac10/100
> ...
> 
> MIPS
> "st,Loongson1B"
> 

This seems fine to me.

Rob

>>  
>>>> Okay.
>>>>
>>>>>> +- reg: Address and length of the register set for the device
>>>>>> +- interrupt-parent: Should be the phandle for the interrupt controller
>>>>>> +  that services interrupts for this device
>>>>>> +- interrupts: Should contain the STMMAC interrupts
>>>>>> +- interrupt-names: Should contain the interrupt names "macirq"
>>>>>> +  "eth_wake_irq" if this interrupt is supported in the "interrupts"
>>>>>> +  property
>>>>>
>>>>> You should be able to tell this from the compatible string and number of
>>>>> interrupts.
>>>>
>>>> Yes. Currently the driver uses platform_get_irq_byname() to register the
>>>> irq's. That's why I added these properties. Is there something wrong with
>>>> using it this way?
>>>>
>>>>>> +- phy-mode: String, operation mode of the PHY interface.
>>>>>> +  Supported values are: "mii", "rmii", "gmii", "rgmii".
>>>>>> +- phy-addr: MDIO address of the PHY
>>>>>
>>>>> This is normally probed or the mdio bus is a sub-node of the MAC node.
>>>>> See arch/powerpc/boot/dts/mpc8377_mds.dts for an example.
>>>>
>>>> Okay, I'll rework this.
>>>>
>>>>>> +
>>>>>> +Optional properties:
>>>>>> +- stm,prog-burst-len: Specify the burst length
>>>>>> +- stm,has-gmac: Indicates that the controller supports 1000Mbps
>>>>>> +- stm,has-pmt: Indicates that the controller supports power management
>>>>>
>>>>> I think these should all be encoded by the compatible string.
>>>
>>> and should we have all the other flags e.g. tx_coe etc?
>>> (see stmmac.txt)
>>
>> As Rob suggested, some of these flags/parameters are implicitly defined by the 
>> compatible string. If this is not the case, then sure, those flags/parameters 
>> need to be provided via the device-tree as well. I just don't need "tx_coe" 
>> etc. for my platform (SPEAr600) as far as I know. I suggest to add support for 
>> them once they are really needed/used by other platforms.
> 
> Ok, but on SPEAr indeed some of these are not used at all.
> If you agree, we can go head with these and then we will add new ones
> next time. In the meantime, I will try to be more familiar with
> devicetree and provide further patches
> 
> peppe
> 
>>
>> Thanks,
>> Stefan
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

  reply	other threads:[~2012-03-12 20:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-12 14:05 [PATCH] stmmac: Add device-tree support Stefan Roese
2012-03-12 14:34 ` Rob Herring
2012-03-12 15:06   ` Stefan Roese
2012-03-12 15:14     ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 15:30     ` Giuseppe CAVALLARO
2012-03-12 16:23       ` Stefan Roese
2012-03-12 16:46         ` Giuseppe CAVALLARO
2012-03-12 20:07           ` Rob Herring [this message]
2012-03-12 17:02       ` Jean-Christophe PLAGNIOL-VILLARD
     [not found] ` <1331561157-3820-1-git-send-email-sr-ynQEQJNshbs@public.gmane.org>
2012-03-12 14:38   ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 15:25     ` Stefan Roese
2012-03-12 15:17       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-14 11:38     ` Giuseppe CAVALLARO
2012-03-14 13:07       ` Arnd Bergmann
2012-03-14 13:16         ` Giuseppe CAVALLARO
2012-03-14 13:37           ` Stefan Roese
2012-03-14 16:26       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-15  8:45         ` Giuseppe CAVALLARO

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=4F5E577E.7090808@gmail.com \
    --to=robherring2@gmail.com \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    --cc=sr@denx.de \
    --cc=viresh.kumar@st.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;
as well as URLs for NNTP newsgroup(s).