All of lore.kernel.org
 help / color / mirror / Atom feed
From: sr@denx.de (Stefan Roese)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] stmmac: Add device-tree support
Date: Mon, 12 Mar 2012 17:23:38 +0100	[thread overview]
Message-ID: <201203121723.38411.sr@denx.de> (raw)
In-Reply-To: <4F5E169D.3070508@st.com>

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?
 
> > 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.

Thanks,
Stefan

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Roese <sr@denx.de>
To: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Cc: Rob Herring <robherring2@gmail.com>,
	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 17:23:38 +0100	[thread overview]
Message-ID: <201203121723.38411.sr@denx.de> (raw)
In-Reply-To: <4F5E169D.3070508@st.com>

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?
 
> > 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.

Thanks,
Stefan

  reply	other threads:[~2012-03-12 16:23 UTC|newest]

Thread overview: 36+ 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:05 ` Stefan Roese
2012-03-12 14:34 ` Rob Herring
2012-03-12 14:34   ` Rob Herring
2012-03-12 15:06   ` Stefan Roese
2012-03-12 15:06     ` Stefan Roese
2012-03-12 15:14     ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 15:14       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 15:30     ` Giuseppe CAVALLARO
2012-03-12 15:30       ` Giuseppe CAVALLARO
2012-03-12 16:23       ` Stefan Roese [this message]
2012-03-12 16:23         ` Stefan Roese
2012-03-12 16:46         ` Giuseppe CAVALLARO
2012-03-12 16:46           ` Giuseppe CAVALLARO
2012-03-12 20:07           ` Rob Herring
2012-03-12 20:07             ` Rob Herring
2012-03-12 17:02       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 17:02         ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 14:38 ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 14:38   ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 15:25   ` Stefan Roese
2012-03-12 15:25     ` Stefan Roese
2012-03-12 15:17     ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-12 15:17       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-14 11:38   ` Giuseppe CAVALLARO
2012-03-14 11:38     ` Giuseppe CAVALLARO
2012-03-14 13:07     ` Arnd Bergmann
2012-03-14 13:07       ` Arnd Bergmann
2012-03-14 13:16       ` Giuseppe CAVALLARO
2012-03-14 13:16         ` Giuseppe CAVALLARO
2012-03-14 13:37         ` Stefan Roese
2012-03-14 13:37           ` Stefan Roese
2012-03-14 16:26     ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-14 16:26       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-15  8:45       ` Giuseppe CAVALLARO
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=201203121723.38411.sr@denx.de \
    --to=sr@denx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.