| Message ID | 201401180405.07859.sergei.shtylyov@cogentembedded.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Fri, Jan 17, 2014 at 7:05 PM, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > This patch is an attempt to gather the Ethernet related bindings in one file, > like it's done in the MMC and some other subsystems. It should save the trouble > of documenting several properties over and over in each binding document. > > I have used the Embedded Power Architecture(TM) Platform Requirements (ePAPR) > standard as a base for the properties description, also documenting some ad-hoc > properties that have been introduced over time despite having direct analogs in > ePAPR. > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > > --- > The patch is against DaveM's 'net-next.git' repo and the DaVinci EMAC bindings > fix I've posted yesterday: > > http://patchwork.ozlabs.org/patch/311854/ > > Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt | 5 -- > Documentation/devicetree/bindings/net/arc_emac.txt | 12 ------ > Documentation/devicetree/bindings/net/cavium-mix.txt | 7 --- > Documentation/devicetree/bindings/net/cavium-pip.txt | 7 --- > Documentation/devicetree/bindings/net/cdns-emac.txt | 5 -- > Documentation/devicetree/bindings/net/cpsw.txt | 3 - > Documentation/devicetree/bindings/net/davicom-dm9000.txt | 2 - > Documentation/devicetree/bindings/net/davinci_emac.txt | 4 -- > Documentation/devicetree/bindings/net/ethernet.txt | 20 ++++++++++ > Documentation/devicetree/bindings/net/fsl-fec.txt | 4 -- > Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 11 +---- > Documentation/devicetree/bindings/net/lpc-eth.txt | 4 -- > Documentation/devicetree/bindings/net/macb.txt | 5 -- > Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 4 -- > Documentation/devicetree/bindings/net/marvell-orion-net.txt | 3 - > Documentation/devicetree/bindings/net/micrel-ks8851.txt | 3 - > Documentation/devicetree/bindings/net/smsc-lan91c111.txt | 1 > Documentation/devicetree/bindings/net/smsc911x.txt | 4 -- > Documentation/devicetree/bindings/net/stmmac.txt | 5 -- > 19 files changed, 25 insertions(+), 84 deletions(-) > > Index: net-next/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt > +++ net-next/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt > @@ -4,13 +4,8 @@ Required properties: > - compatible: should be "allwinner,sun4i-emac". > - reg: address and length of the register set for the device. > - interrupts: interrupt for the device > -- phy: A phandle to a phy node defining the PHY address (as the reg > - property, a single integer). > - clocks: A phandle to the reference clock for this device > > -Optional properties: > -- (local-)mac-address: mac address to be used by this driver > - You should reference that this binding uses the common ethernet binding doc. > Example: > > emac: ethernet@01c0b000 { > Index: net-next/Documentation/devicetree/bindings/net/arc_emac.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/arc_emac.txt > +++ net-next/Documentation/devicetree/bindings/net/arc_emac.txt > @@ -6,18 +6,6 @@ Required properties: > - interrupts: Should contain the EMAC interrupts > - clock-frequency: CPU frequency. It is needed to calculate and set polling > period of EMAC. > -- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations > -bandwidth of external memory controller might be a limiting factor. That's why > -it's required to specify which data-rate is supported on current SoC or FPGA. > -For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is > -supported (100BASE-TX) set "100". > -- phy: PHY device attached to the EMAC via MDIO bus > - > -Child nodes of the driver are the individual PHY devices connected to the > -MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus. > - > -Optional properties: > -- mac-address: 6 bytes, mac address > > Examples: > > Index: net-next/Documentation/devicetree/bindings/net/cavium-mix.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/cavium-mix.txt > +++ net-next/Documentation/devicetree/bindings/net/cavium-mix.txt > @@ -18,13 +18,6 @@ Properties: > - interrupts: Two interrupt specifiers. The first is the MIX > interrupt routing and the second the routing for the AGL interrupts. > > -- mac-address: Optional, the MAC address to assign to the device. > - > -- local-mac-address: Optional, the MAC address to assign to the device > - if mac-address is not specified. > - > -- phy-handle: Optional, a phandle for the PHY device connected to this device. > - > Example: > ethernet@1070000100800 { > compatible = "cavium,octeon-5750-mix"; > Index: net-next/Documentation/devicetree/bindings/net/cavium-pip.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/cavium-pip.txt > +++ net-next/Documentation/devicetree/bindings/net/cavium-pip.txt > @@ -35,13 +35,6 @@ Properties for PIP port which is a child > > - reg: The port number within the interface group. > > -- mac-address: Optional, the MAC address to assign to the device. > - > -- local-mac-address: Optional, the MAC address to assign to the device > - if mac-address is not specified. > - > -- phy-handle: Optional, a phandle for the PHY device connected to this device. > - > Example: > > pip@11800a0000000 { > Index: net-next/Documentation/devicetree/bindings/net/cdns-emac.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/cdns-emac.txt > +++ net-next/Documentation/devicetree/bindings/net/cdns-emac.txt > @@ -6,11 +6,6 @@ Required properties: > or the generic form: "cdns,emac". > - reg: Address and length of the register set for the device > - interrupts: Should contain macb interrupt > -- phy-mode: String, operation mode of the PHY interface. > - Supported values are: "mii", "rmii". > - > -Optional properties: > -- local-mac-address: 6 bytes, mac address > > Examples: > > Index: net-next/Documentation/devicetree/bindings/net/cpsw.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/cpsw.txt > +++ net-next/Documentation/devicetree/bindings/net/cpsw.txt > @@ -28,9 +28,6 @@ Optional properties: > Slave Properties: > Required properties: > - phy_id : Specifies slave phy id > -- phy-mode : The interface between the SoC and the PHY (a string > - that of_get_phy_mode() can understand) > -- mac-address : Specifies slave MAC address > > Optional properties: > - dual_emac_res_vlan : Specifies VID to be used to segregate the ports > Index: net-next/Documentation/devicetree/bindings/net/davicom-dm9000.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/davicom-dm9000.txt > +++ net-next/Documentation/devicetree/bindings/net/davicom-dm9000.txt > @@ -9,8 +9,6 @@ Required properties: > - interrupts : interrupt specifier specific to interrupt controller > > Optional properties: > -- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address > - to use (from firmware or bootloader) > - davicom,no-eeprom : Configuration EEPROM is not available > - davicom,ext-phy : Use external PHY > > Index: net-next/Documentation/devicetree/bindings/net/davinci_emac.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/davinci_emac.txt > +++ net-next/Documentation/devicetree/bindings/net/davinci_emac.txt > @@ -19,9 +19,7 @@ Required properties: > Miscellaneous Interrupt> > > Optional properties: > -- phy-handle: Contains a phandle to an Ethernet PHY. > - If absent, davinci_emac driver defaults to 100/FULL. > -- local-mac-address : 6 bytes, mac address > +- phy-handle: If absent, davinci_emac driver defaults to 100/FULL. > > Example (enbw_cmc board): > eth0: emac@1e20000 { > Index: net-next/Documentation/devicetree/bindings/net/ethernet.txt > =================================================================== > --- /dev/null > +++ net-next/Documentation/devicetree/bindings/net/ethernet.txt > @@ -0,0 +1,20 @@ > +The following properties are common to the Ethernet controllers: > + > +- local-mac-address: array of 6 bytes, specifies the MAC address that was > + assigned to the network device; > +- mac-address: array of 6 bytes, specifies the MAC address that was last used by > + the boot program; should be used in cases where the MAC address assigned to > + the device by the boot program is different from the "local-mac-address" > + property; > +- max-speed: number, specifies maximum speed in Mbit/s supported by the device; > +- phy-mode: string, operation mode of the PHY interface; supported values are > + "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", > + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; Mark this as deprecated in favor of phy-connection-type so it's use does not spread. > +- phy-connection-type: the same as "phy-mode" property (but described in ePAPR); > +- phy-handle: phandle, specifies a reference to a node representing a PHY > + device (this property is described in ePAPR); > +- phy: the same as "phy-handle" property (but actually ad-hoc one). Mark this as deprecated in favor of phy-handle. > + > +Child nodes of the Ethernet controller are typically the individual PHY devices > +connected via the MDIO bus (sometimes the MDIO bus controller is separate). > +They are described in the phy.txt file in this same directory. > Index: net-next/Documentation/devicetree/bindings/net/fsl-fec.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/fsl-fec.txt > +++ net-next/Documentation/devicetree/bindings/net/fsl-fec.txt > @@ -4,12 +4,8 @@ Required properties: > - compatible : Should be "fsl,<soc>-fec" > - reg : Address and length of the register set for the device > - interrupts : Should contain fec interrupt > -- phy-mode : String, operation mode of the PHY interface. > - Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii", > - "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii". > > Optional properties: > -- local-mac-address : 6 bytes, mac address > - phy-reset-gpios : Should specify the gpio for phy reset > - phy-reset-duration : Reset duration in milliseconds. Should present > only if property "phy-reset-gpios" is available. Missing the property > Index: net-next/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt > +++ net-next/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt > @@ -38,22 +38,15 @@ Properties: > - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" > - compatible : Should be "gianfar" > - reg : Offset and length of the register set for the device > - - local-mac-address : List of bytes representing the ethernet address of > - this controller > - interrupts : For FEC devices, the first interrupt is the device's > interrupt. For TSEC and eTSEC devices, the first interrupt is > transmit, the second is receive, and the third is error. > - - phy-handle : The phandle for the PHY connected to this ethernet > - controller. > - fixed-link : <a b c d e> where a is emulated phy id - choose any, > but unique to the all specified fixed-links, b is duplex - 0 half, > 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no > pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. > - - phy-connection-type : a string naming the controller/PHY interface type, > - i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", > - "tbi", or "rtbi". This property is only really needed if the connection > - is of type "rgmii-id", as all other connection types are detected by > - hardware. > + - phy-connection-type : only really needed if the connection is of type > + "rgmii-id", as all other connection types are detected by hardware. > - fsl,magic-packet : If present, indicates that the hardware supports > waking up via magic packet. > - bd-stash : If present, indicates that the hardware supports stashing > Index: net-next/Documentation/devicetree/bindings/net/lpc-eth.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/lpc-eth.txt > +++ net-next/Documentation/devicetree/bindings/net/lpc-eth.txt > @@ -6,10 +6,8 @@ Required properties: > - interrupts: Should contain ethernet controller interrupt > > Optional properties: > -- phy-mode: String, operation mode of the PHY interface. > - Supported values are: "mii", "rmii" (default) > +- phy-mode: if absent, "rmii" is assumed. > - use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering > -- local-mac-address : 6 bytes, mac address > > Example: > > Index: net-next/Documentation/devicetree/bindings/net/macb.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/macb.txt > +++ net-next/Documentation/devicetree/bindings/net/macb.txt > @@ -8,11 +8,6 @@ Required properties: > the Cadence GEM, or the generic form: "cdns,gem". > - reg: Address and length of the register set for the device > - interrupts: Should contain macb interrupt > -- phy-mode: String, operation mode of the PHY interface. > - Supported values are: "mii", "rmii", "gmii", "rgmii". > - > -Optional properties: > -- local-mac-address: 6 bytes, mac address > > Examples: > > Index: net-next/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt > +++ net-next/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt > @@ -4,10 +4,6 @@ Required properties: > - compatible: should be "marvell,armada-370-neta". > - reg: address and length of the register set for the device. > - interrupts: interrupt for the device > -- phy: A phandle to a phy node defining the PHY address (as the reg > - property, a single integer). > -- phy-mode: The interface between the SoC and the PHY (a string that > - of_get_phy_mode() can understand) > - clocks: a pointer to the reference clock for this device. > > Example: > Index: net-next/Documentation/devicetree/bindings/net/marvell-orion-net.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/marvell-orion-net.txt > +++ net-next/Documentation/devicetree/bindings/net/marvell-orion-net.txt > @@ -37,7 +37,6 @@ Required port properties: > "marvell,kirkwood-eth-port". > - reg: port number relative to ethernet controller, shall be 0, 1, or 2. > - interrupts: port interrupt. > - - local-mac-address: 6 bytes MAC address. > > Optional port properties: > - marvell,tx-queue-size: size of the transmit ring buffer. > @@ -49,7 +48,7 @@ Optional port properties: > > and > > - - phy-handle: phandle reference to ethernet PHY. > + - phy-handle: if a PHY is connected. > > or > > Index: net-next/Documentation/devicetree/bindings/net/micrel-ks8851.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/micrel-ks8851.txt > +++ net-next/Documentation/devicetree/bindings/net/micrel-ks8851.txt > @@ -4,6 +4,3 @@ Required properties: > - compatible = "micrel,ks8851-ml" of parallel interface > - reg : 2 physical address and size of registers for data and command > - interrupts : interrupt connection > - > -Optional properties: > -- local-mac-address : Ethernet mac address to use > Index: net-next/Documentation/devicetree/bindings/net/smsc-lan91c111.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/smsc-lan91c111.txt > +++ net-next/Documentation/devicetree/bindings/net/smsc-lan91c111.txt > @@ -7,7 +7,6 @@ Required properties: > > Optional properties: > - phy-device : phandle to Ethernet phy > -- local-mac-address : Ethernet mac address to use > - reg-io-width : Mask of sizes (in bytes) of the IO accesses that > are supported on the device. Valid value for SMSC LAN91c111 are > 1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning > Index: net-next/Documentation/devicetree/bindings/net/smsc911x.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/smsc911x.txt > +++ net-next/Documentation/devicetree/bindings/net/smsc911x.txt > @@ -6,9 +6,6 @@ Required properties: > - interrupts : Should contain SMSC LAN interrupt line > - interrupt-parent : Should be the phandle for the interrupt controller > that services interrupts for this device > -- phy-mode : String, operation mode of the PHY interface. > - Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii", > - "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii". > > Optional properties: > - reg-shift : Specify the quantity to shift the register offsets by > @@ -23,7 +20,6 @@ Optional properties: > external PHY > - smsc,save-mac-address : Indicates that mac address needs to be saved > before resetting the controller > -- local-mac-address : 6 bytes, mac address > > Examples: > > Index: net-next/Documentation/devicetree/bindings/net/stmmac.txt > =================================================================== > --- net-next.orig/Documentation/devicetree/bindings/net/stmmac.txt > +++ net-next/Documentation/devicetree/bindings/net/stmmac.txt > @@ -10,8 +10,6 @@ Required properties: > - interrupt-names: Should contain the interrupt names "macirq" > "eth_wake_irq" if this interrupt is supported in the "interrupts" > property > -- phy-mode: String, operation mode of the PHY interface. > - Supported values are: "mii", "rmii", "gmii", "rgmii". > - snps,phy-addr phy address to connect to. > - snps,reset-gpio gpio number for phy reset. > - snps,reset-active-low boolean flag to indicate if phy reset is active low. > @@ -28,9 +26,6 @@ Required properties: > mode for both tx and rx. This flag is > ignored if force_thresh_dma_mode is set. > > -Optional properties: > -- mac-address: 6 bytes, mac address > - > Examples: > > gmac0: ethernet@e0800000 { -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 20, 2014 at 3:45 PM, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > On 01/20/2014 05:06 PM, Rob Herring wrote: > >>> This patch is an attempt to gather the Ethernet related bindings in one >>> file, >>> like it's done in the MMC and some other subsystems. It should save the >>> trouble >>> of documenting several properties over and over in each binding document. > > >>> I have used the Embedded Power Architecture(TM) Platform Requirements >>> (ePAPR) >>> standard as a base for the properties description, also documenting some >>> ad-hoc >>> properties that have been introduced over time despite having direct >>> analogs in >>> ePAPR. > > >>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > > >>> --- >>> The patch is against DaveM's 'net-next.git' repo and the DaVinci EMAC >>> bindings >>> fix I've posted yesterday: > > >>> http://patchwork.ozlabs.org/patch/311854/ > > > [...] >>> Index: net-next/Documentation/devicetree/bindings/net/ethernet.txt >>> =================================================================== >>> --- /dev/null >>> +++ net-next/Documentation/devicetree/bindings/net/ethernet.txt >>> @@ -0,0 +1,20 @@ >>> +The following properties are common to the Ethernet controllers: >>> + >>> +- local-mac-address: array of 6 bytes, specifies the MAC address that >>> was >>> + assigned to the network device; >>> +- mac-address: array of 6 bytes, specifies the MAC address that was last >>> used by >>> + the boot program; should be used in cases where the MAC address >>> assigned to >>> + the device by the boot program is different from the >>> "local-mac-address" >>> + property; >>> +- max-speed: number, specifies maximum speed in Mbit/s supported by the >>> device; >>> +- phy-mode: string, operation mode of the PHY interface; supported >>> values are >>> + "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", >>> + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; > > >> Mark this as deprecated > > > That's kind of wishful thinking at this point, as that's what the > majority of drivers use. I'm unsure of the reasons why that was done, > probably people just didn't read the proper specs... Or the spec was defined after those bindings. Deprecating does not matter for existing bindings. It's only defining new ones that are affected. I was more concerned with giving people guidance on which one to use for new bindings. >> in favor of phy-connection-type > > > That one is only used by the oldish PowerPC 'gianfar' driver. > > >> so it's use does not spread. > > > I'm afraid that's too late, it has spread very far, so that > of_get_phy_mode() handles that property, not "phy-connection-type". Uggg, I guess this is a case of a defacto standard then if the kernel doesn't even support it. >>> +- phy-connection-type: the same as "phy-mode" property (but described in >>> ePAPR); >>> +- phy-handle: phandle, specifies a reference to a node representing a >>> PHY >>> + device (this property is described in ePAPR); >>> +- phy: the same as "phy-handle" property (but actually ad-hoc one). > > >> Mark this as deprecated in favor of phy-handle. > > > Here situation is more optimistic. Quite many drivers still use > "phy-handle", though some use even more exotic props I didn't document here. Perhaps flagging as "Not recommended for new bindings" would be nicer wording... Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/20/2014 05:06 PM, Rob Herring wrote: >> This patch is an attempt to gather the Ethernet related bindings in one file, >> like it's done in the MMC and some other subsystems. It should save the trouble >> of documenting several properties over and over in each binding document. >> I have used the Embedded Power Architecture(TM) Platform Requirements (ePAPR) >> standard as a base for the properties description, also documenting some ad-hoc >> properties that have been introduced over time despite having direct analogs in >> ePAPR. >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> >> --- >> The patch is against DaveM's 'net-next.git' repo and the DaVinci EMAC bindings >> fix I've posted yesterday: >> http://patchwork.ozlabs.org/patch/311854/ [...] >> Index: net-next/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt >> =================================================================== >> --- net-next.orig/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt >> +++ net-next/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt >> @@ -4,13 +4,8 @@ Required properties: >> - compatible: should be "allwinner,sun4i-emac". >> - reg: address and length of the register set for the device. >> - interrupts: interrupt for the device >> -- phy: A phandle to a phy node defining the PHY address (as the reg >> - property, a single integer). >> - clocks: A phandle to the reference clock for this device >> -Optional properties: >> -- (local-)mac-address: mac address to be used by this driver >> - > You should reference that this binding uses the common ethernet binding doc. Oh, I was hoping to avoid that like MMC subsys mostly managed to do (most MMC specific properties are only described once, without outside references to mmc.txt). OTOH, the MMC bindings handling is mostly centralized in the core code, while the Ethernet one is not, so you're probably right here... >> Index: net-next/Documentation/devicetree/bindings/net/ethernet.txt >> =================================================================== >> --- /dev/null >> +++ net-next/Documentation/devicetree/bindings/net/ethernet.txt >> @@ -0,0 +1,20 @@ >> +The following properties are common to the Ethernet controllers: >> + >> +- local-mac-address: array of 6 bytes, specifies the MAC address that was >> + assigned to the network device; >> +- mac-address: array of 6 bytes, specifies the MAC address that was last used by >> + the boot program; should be used in cases where the MAC address assigned to >> + the device by the boot program is different from the "local-mac-address" >> + property; >> +- max-speed: number, specifies maximum speed in Mbit/s supported by the device; >> +- phy-mode: string, operation mode of the PHY interface; supported values are >> + "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", >> + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; > Mark this as deprecated That's kind of wishful thinking at this point, as that's what the majority of drivers use. I'm unsure of the reasons why that was done, probably people just didn't read the proper specs... > in favor of phy-connection-type That one is only used by the oldish PowerPC 'gianfar' driver. > so it's use does not spread. I'm afraid that's too late, it has spread very far, so that of_get_phy_mode() handles that property, not "phy-connection-type". >> +- phy-connection-type: the same as "phy-mode" property (but described in ePAPR); >> +- phy-handle: phandle, specifies a reference to a node representing a PHY >> + device (this property is described in ePAPR); >> +- phy: the same as "phy-handle" property (but actually ad-hoc one). > Mark this as deprecated in favor of phy-handle. Here situation is more optimistic. Quite many drivers still use "phy-handle", though some use even more exotic props I didn't document here. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/21/2014 12:20 AM, Rob Herring wrote: >>>> This patch is an attempt to gather the Ethernet related bindings in one >>>> file, >>>> like it's done in the MMC and some other subsystems. It should save the >>>> trouble >>>> of documenting several properties over and over in each binding document. >>>> I have used the Embedded Power Architecture(TM) Platform Requirements >>>> (ePAPR) >>>> standard as a base for the properties description, also documenting some >>>> ad-hoc >>>> properties that have been introduced over time despite having direct >>>> analogs in >>>> ePAPR. >>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> >>>> --- >>>> The patch is against DaveM's 'net-next.git' repo and the DaVinci EMAC >>>> bindings >>>> fix I've posted yesterday: >>>> http://patchwork.ozlabs.org/patch/311854/ >> [...] >>>> Index: net-next/Documentation/devicetree/bindings/net/ethernet.txt >>>> =================================================================== >>>> --- /dev/null >>>> +++ net-next/Documentation/devicetree/bindings/net/ethernet.txt >>>> @@ -0,0 +1,20 @@ >>>> +The following properties are common to the Ethernet controllers: >>>> + >>>> +- local-mac-address: array of 6 bytes, specifies the MAC address that >>>> was >>>> + assigned to the network device; >>>> +- mac-address: array of 6 bytes, specifies the MAC address that was last >>>> used by >>>> + the boot program; should be used in cases where the MAC address >>>> assigned to >>>> + the device by the boot program is different from the >>>> "local-mac-address" >>>> + property; >>>> +- max-speed: number, specifies maximum speed in Mbit/s supported by the >>>> device; >>>> +- phy-mode: string, operation mode of the PHY interface; supported >>>> values are >>>> + "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", >>>> + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; >>> Mark this as deprecated >> That's kind of wishful thinking at this point, as that's what the >> majority of drivers use. I'm unsure of the reasons why that was done, >> probably people just didn't read the proper specs... > Or the spec was defined after those bindings. No, that's not likely as "phy-connection-type" prop seems very old, most probably predating ePAPR. ePAPR exists since 2008, kernel support for "phy-mode" prop dates back only to 2011. > Deprecating does not > matter for existing bindings. It's only defining new ones that are > affected. I was more concerned with giving people guidance on which > one to use for new bindings. If "phy-connection-type" is to be used, it makes sense to modify of_get_phy_mode() to also look for that prop, right? >>> in favor of phy-connection-type >> That one is only used by the oldish PowerPC 'gianfar' driver. >>> so it's use does not spread. >> I'm afraid that's too late, it has spread very far, so that >> of_get_phy_mode() handles that property, not "phy-connection-type". > Uggg, I guess this is a case of a defacto standard then if the kernel > doesn't even support it. What's your guess on what to do on these 2 props then? Still deprecate "phy-mode"? >>>> +- phy-connection-type: the same as "phy-mode" property (but described in >>>> ePAPR); >>>> +- phy-handle: phandle, specifies a reference to a node representing a >>>> PHY >>>> + device (this property is described in ePAPR); >>>> +- phy: the same as "phy-handle" property (but actually ad-hoc one). >>> Mark this as deprecated in favor of phy-handle. >> Here situation is more optimistic. Quite many drivers still use >> "phy-handle", though some use even more exotic props I didn't document here. > Perhaps flagging as "Not recommended for new bindings" would be nicer wording... Perhaps. > Rob WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2014/1/20 Rob Herring <robherring2@gmail.com>: > On Mon, Jan 20, 2014 at 3:45 PM, Sergei Shtylyov > <sergei.shtylyov@cogentembedded.com> wrote: >> On 01/20/2014 05:06 PM, Rob Herring wrote: >> >>>> This patch is an attempt to gather the Ethernet related bindings in one >>>> file, >>>> like it's done in the MMC and some other subsystems. It should save the >>>> trouble >>>> of documenting several properties over and over in each binding document. >> >> >>>> I have used the Embedded Power Architecture(TM) Platform Requirements >>>> (ePAPR) >>>> standard as a base for the properties description, also documenting some >>>> ad-hoc >>>> properties that have been introduced over time despite having direct >>>> analogs in >>>> ePAPR. >> >> >>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> >> >> >>>> --- >>>> The patch is against DaveM's 'net-next.git' repo and the DaVinci EMAC >>>> bindings >>>> fix I've posted yesterday: >> >> >>>> http://patchwork.ozlabs.org/patch/311854/ >> >> >> [...] > >>>> Index: net-next/Documentation/devicetree/bindings/net/ethernet.txt >>>> =================================================================== >>>> --- /dev/null >>>> +++ net-next/Documentation/devicetree/bindings/net/ethernet.txt >>>> @@ -0,0 +1,20 @@ >>>> +The following properties are common to the Ethernet controllers: >>>> + >>>> +- local-mac-address: array of 6 bytes, specifies the MAC address that >>>> was >>>> + assigned to the network device; >>>> +- mac-address: array of 6 bytes, specifies the MAC address that was last >>>> used by >>>> + the boot program; should be used in cases where the MAC address >>>> assigned to >>>> + the device by the boot program is different from the >>>> "local-mac-address" >>>> + property; >>>> +- max-speed: number, specifies maximum speed in Mbit/s supported by the >>>> device; >>>> +- phy-mode: string, operation mode of the PHY interface; supported >>>> values are >>>> + "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", >>>> + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; >> >> >>> Mark this as deprecated >> >> >> That's kind of wishful thinking at this point, as that's what the >> majority of drivers use. I'm unsure of the reasons why that was done, >> probably people just didn't read the proper specs... > > Or the spec was defined after those bindings. Deprecating does not > matter for existing bindings. It's only defining new ones that are > affected. I was more concerned with giving people guidance on which > one to use for new bindings. > >>> in favor of phy-connection-type >> >> >> That one is only used by the oldish PowerPC 'gianfar' driver. >> >> >>> so it's use does not spread. >> >> >> I'm afraid that's too late, it has spread very far, so that >> of_get_phy_mode() handles that property, not "phy-connection-type". > > Uggg, I guess this is a case of a defacto standard then if the kernel > doesn't even support it. Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a while ago for of_get_phy_mode() to look for both "phy-mode" and "phy-connection-type" since the former has been a Linux invention, but the latter is ePAPR specified. > >>>> +- phy-connection-type: the same as "phy-mode" property (but described in >>>> ePAPR); >>>> +- phy-handle: phandle, specifies a reference to a node representing a >>>> PHY >>>> + device (this property is described in ePAPR); >>>> +- phy: the same as "phy-handle" property (but actually ad-hoc one). >> >> >>> Mark this as deprecated in favor of phy-handle. >> >> >> Here situation is more optimistic. Quite many drivers still use >> "phy-handle", though some use even more exotic props I didn't document here. > > Perhaps flagging as "Not recommended for new bindings" would be nicer wording... Ok, so what's the deal here, can't we use phy-handle? There is currently no infrastructure in drivers/net/ or drivers/of/ to look for the "phy-handle" nor "phy" properties as phandles to fetch an Ethernet PHY device tree node. If we are to provide one common place where we want to do this, we will have to look for both properties, why can't we mandate the use of "phy-handle" since this is the ePAPR compliant one? > > Rob > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
2014/1/21 Florian Fainelli <f.fainelli@gmail.com>: >>> I'm afraid that's too late, it has spread very far, so that >>> of_get_phy_mode() handles that property, not "phy-connection-type". >> >> Uggg, I guess this is a case of a defacto standard then if the kernel >> doesn't even support it. > > Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a > while ago for of_get_phy_mode() to look for both "phy-mode" and > "phy-connection-type" since the former has been a Linux invention, but > the latter is ePAPR specified. Here is a link to the actual patch in question, not sure which tree Grant applied it to though: http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html > >> >>>>> +- phy-connection-type: the same as "phy-mode" property (but described in >>>>> ePAPR); >>>>> +- phy-handle: phandle, specifies a reference to a node representing a >>>>> PHY >>>>> + device (this property is described in ePAPR); >>>>> +- phy: the same as "phy-handle" property (but actually ad-hoc one). >>> >>> >>>> Mark this as deprecated in favor of phy-handle. >>> >>> >>> Here situation is more optimistic. Quite many drivers still use >>> "phy-handle", though some use even more exotic props I didn't document here. >> >> Perhaps flagging as "Not recommended for new bindings" would be nicer wording... > > Ok, so what's the deal here, can't we use phy-handle? There is > currently no infrastructure in drivers/net/ or drivers/of/ to look for > the "phy-handle" nor "phy" properties as phandles to fetch an Ethernet > PHY device tree node. If we are to provide one common place where we > want to do this, we will have to look for both properties, why can't > we mandate the use of "phy-handle" since this is the ePAPR compliant > one? > >> >> Rob >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Florian
Hello. On 01/21/2014 11:05 PM, Florian Fainelli wrote: >>>> I'm afraid that's too late, it has spread very far, so that >>>> of_get_phy_mode() handles that property, not "phy-connection-type". >>> Uggg, I guess this is a case of a defacto standard then if the kernel >>> doesn't even support it. >> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a >> while ago for of_get_phy_mode() to look for both "phy-mode" and >> "phy-connection-type" since the former has been a Linux invention, but >> the latter is ePAPR specified. > Here is a link to the actual patch in question, not sure which tree > Grant applied it to though: > http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html It's not the patch mail, it's Grant's "applied" reply, patch is mangled in this reply, and I couldn't follow the thread. Here's the actual patch mail: http://marc.info/?l=devicetree&m=138449662807254 WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 21, 2014 at 1:56 PM, Florian Fainelli <f.fainelli@gmail.com> wrote: > 2014/1/20 Rob Herring <robherring2@gmail.com>: >> On Mon, Jan 20, 2014 at 3:45 PM, Sergei Shtylyov >> <sergei.shtylyov@cogentembedded.com> wrote: >>> On 01/20/2014 05:06 PM, Rob Herring wrote: [snip] >>>>> +- phy-connection-type: the same as "phy-mode" property (but described in >>>>> ePAPR); >>>>> +- phy-handle: phandle, specifies a reference to a node representing a >>>>> PHY >>>>> + device (this property is described in ePAPR); >>>>> +- phy: the same as "phy-handle" property (but actually ad-hoc one). >>> >>> >>>> Mark this as deprecated in favor of phy-handle. >>> >>> >>> Here situation is more optimistic. Quite many drivers still use >>> "phy-handle", though some use even more exotic props I didn't document here. >> >> Perhaps flagging as "Not recommended for new bindings" would be nicer wording... > > Ok, so what's the deal here, can't we use phy-handle? There is > currently no infrastructure in drivers/net/ or drivers/of/ to look for > the "phy-handle" nor "phy" properties as phandles to fetch an Ethernet > PHY device tree node. If we are to provide one common place where we > want to do this, we will have to look for both properties, why can't > we mandate the use of "phy-handle" since this is the ePAPR compliant > one? My count is 3 using "phy" and 11 using "phy-handle". Even if we mandate phy-handle, we still have to support both properties to maintain compatibility with existing DTs. But nothing new should use "phy". I'm not sure that something common really helps here. Drivers using "phy" can continue to and new ones use "phy-handle". After a quick scan, there doesn't appear to be any multi-line pattern in the drivers we could factor out. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 01/22/2014 12:19 AM, Sergei Shtylyov wrote: >>>>> I'm afraid that's too late, it has spread very far, so that >>>>> of_get_phy_mode() handles that property, not "phy-connection-type". >>>> Uggg, I guess this is a case of a defacto standard then if the kernel >>>> doesn't even support it. >>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a >>> while ago for of_get_phy_mode() to look for both "phy-mode" and >>> "phy-connection-type" since the former has been a Linux invention, but >>> the latter is ePAPR specified. >> Here is a link to the actual patch in question, not sure which tree >> Grant applied it to though: >> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html > It's not the patch mail, it's Grant's "applied" reply, patch is mangled in > this reply, and I couldn't follow the thread. Here's the actual patch mail: > http://marc.info/?l=devicetree&m=138449662807254 Florian, I didn't find this patch in Grant's official tree, so maybe you should ask him where is the patch already? WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 30 Jan 2014 02:04:26 +0300, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > Hello. > > On 01/22/2014 12:19 AM, Sergei Shtylyov wrote: > > >>>>> I'm afraid that's too late, it has spread very far, so that > >>>>> of_get_phy_mode() handles that property, not "phy-connection-type". > > >>>> Uggg, I guess this is a case of a defacto standard then if the kernel > >>>> doesn't even support it. > > >>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a > >>> while ago for of_get_phy_mode() to look for both "phy-mode" and > >>> "phy-connection-type" since the former has been a Linux invention, but > >>> the latter is ePAPR specified. > > >> Here is a link to the actual patch in question, not sure which tree > >> Grant applied it to though: > > >> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html > > > It's not the patch mail, it's Grant's "applied" reply, patch is mangled in > > this reply, and I couldn't follow the thread. Here's the actual patch mail: > > > http://marc.info/?l=devicetree&m=138449662807254 > > Florian, I didn't find this patch in Grant's official tree, so maybe you > should ask him where is the patch already? Sorry, I accidentally dropped it. It will be in the next merge window. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 02/04/2014 08:26 PM, Grant Likely wrote: >>>>>>> I'm afraid that's too late, it has spread very far, so that >>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type". >>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel >>>>>> doesn't even support it. >>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a >>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and >>>>> "phy-connection-type" since the former has been a Linux invention, but >>>>> the latter is ePAPR specified. >>>> Here is a link to the actual patch in question, not sure which tree >>>> Grant applied it to though: >>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html >>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in >>> this reply, and I couldn't follow the thread. Here's the actual patch mail: >>> http://marc.info/?l=devicetree&m=138449662807254 >> Florian, I didn't find this patch in Grant's official tree, so maybe you >> should ask him where is the patch already? > Sorry, I accidentally dropped it. It will be in the next merge window. Already saw it, thanks. Would that it was in 3.14 instead of course, so that I could use "phy-connection-type" in my binding... > g. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 04 Feb 2014 21:40:16 +0300, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > Hello. > > On 02/04/2014 08:26 PM, Grant Likely wrote: > > >>>>>>> I'm afraid that's too late, it has spread very far, so that > >>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type". > > >>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel > >>>>>> doesn't even support it. > > >>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a > >>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and > >>>>> "phy-connection-type" since the former has been a Linux invention, but > >>>>> the latter is ePAPR specified. > > >>>> Here is a link to the actual patch in question, not sure which tree > >>>> Grant applied it to though: > > >>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html > > >>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in > >>> this reply, and I couldn't follow the thread. Here's the actual patch mail: > > >>> http://marc.info/?l=devicetree&m=138449662807254 > > >> Florian, I didn't find this patch in Grant's official tree, so maybe you > >> should ask him where is the patch already? > > > Sorry, I accidentally dropped it. It will be in the next merge window. > > Already saw it, thanks. Would that it was in 3.14 instead of course, so > that I could use "phy-connection-type" in my binding... Is 3.14 broken because of missing the patch? If so I'll get it merged as a bug fix. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 02/05/2014 03:08 PM, Grant Likely wrote: >>>>>>>>> I'm afraid that's too late, it has spread very far, so that >>>>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type". >>>>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel >>>>>>>> doesn't even support it. >>>>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a >>>>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and >>>>>>> "phy-connection-type" since the former has been a Linux invention, but >>>>>>> the latter is ePAPR specified. >>>>>> Here is a link to the actual patch in question, not sure which tree >>>>>> Grant applied it to though: >>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html >>>>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in >>>>> this reply, and I couldn't follow the thread. Here's the actual patch mail: >>>>> http://marc.info/?l=devicetree&m=138449662807254 >>>> Florian, I didn't find this patch in Grant's official tree, so maybe you >>>> should ask him where is the patch already? >>> Sorry, I accidentally dropped it. It will be in the next merge window. >> Already saw it, thanks. Would that it was in 3.14 instead of course, so >> that I could use "phy-connection-type" in my binding... > Is 3.14 broken because of missing the patch? If so I'll get it merged as > a bug fix. No, it's not. I could have used "phy-connection-type" in my binding destined for 3.15 and document it as a preferred property as well. > g. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 05 Feb 2014 18:36:03 +0300, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > Hello. > > On 02/05/2014 03:08 PM, Grant Likely wrote: > > >>>>>>>>> I'm afraid that's too late, it has spread very far, so that > >>>>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type". > > >>>>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel > >>>>>>>> doesn't even support it. > > >>>>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a > >>>>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and > >>>>>>> "phy-connection-type" since the former has been a Linux invention, but > >>>>>>> the latter is ePAPR specified. > > >>>>>> Here is a link to the actual patch in question, not sure which tree > >>>>>> Grant applied it to though: > > >>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html > > >>>>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in > >>>>> this reply, and I couldn't follow the thread. Here's the actual patch mail: > > >>>>> http://marc.info/?l=devicetree&m=138449662807254 > > >>>> Florian, I didn't find this patch in Grant's official tree, so maybe you > >>>> should ask him where is the patch already? > > >>> Sorry, I accidentally dropped it. It will be in the next merge window. > > >> Already saw it, thanks. Would that it was in 3.14 instead of course, so > >> that I could use "phy-connection-type" in my binding... > > > Is 3.14 broken because of missing the patch? If so I'll get it merged as > > a bug fix. > > No, it's not. I could have used "phy-connection-type" in my binding > destined for 3.15 and document it as a preferred property as well. You still can. We just need to make sure that your patch is applied on top of the phy-connection-type patch. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 06-02-2014 13:43, Grant Likely wrote: >>>>>>>>>>> I'm afraid that's too late, it has spread very far, so that >>>>>>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type". >>>>>>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel >>>>>>>>>> doesn't even support it. >>>>>>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a >>>>>>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and >>>>>>>>> "phy-connection-type" since the former has been a Linux invention, but >>>>>>>>> the latter is ePAPR specified. >>>>>>>> Here is a link to the actual patch in question, not sure which tree >>>>>>>> Grant applied it to though: >>>>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html >>>>>>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in >>>>>>> this reply, and I couldn't follow the thread. Here's the actual patch mail: >>>>>>> http://marc.info/?l=devicetree&m=138449662807254 >>>>>> Florian, I didn't find this patch in Grant's official tree, so maybe you >>>>>> should ask him where is the patch already? >>>>> Sorry, I accidentally dropped it. It will be in the next merge window. >>>> Already saw it, thanks. Would that it was in 3.14 instead of course, so >>>> that I could use "phy-connection-type" in my binding... >>> Is 3.14 broken because of missing the patch? If so I'll get it merged as >> > a bug fix. >> No, it's not. I could have used "phy-connection-type" in my binding >> destined for 3.15 and document it as a preferred property as well. > You still can. We just need to make sure that your patch is applied on Patches. > top of the phy-connection-type patch. I'm not sure this trick is possible if the patches are merged via the different trees... > g. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 06 Feb 2014 18:06:22 +0400, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > Hello. > > On 06-02-2014 13:43, Grant Likely wrote: > > >>>>>>>>>>> I'm afraid that's too late, it has spread very far, so that > >>>>>>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type". > > >>>>>>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel > >>>>>>>>>> doesn't even support it. > > >>>>>>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a > >>>>>>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and > >>>>>>>>> "phy-connection-type" since the former has been a Linux invention, but > >>>>>>>>> the latter is ePAPR specified. > > >>>>>>>> Here is a link to the actual patch in question, not sure which tree > >>>>>>>> Grant applied it to though: > > >>>>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html > > >>>>>>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in > >>>>>>> this reply, and I couldn't follow the thread. Here's the actual patch mail: > > >>>>>>> http://marc.info/?l=devicetree&m=138449662807254 > > >>>>>> Florian, I didn't find this patch in Grant's official tree, so maybe you > >>>>>> should ask him where is the patch already? > > >>>>> Sorry, I accidentally dropped it. It will be in the next merge window. > > >>>> Already saw it, thanks. Would that it was in 3.14 instead of course, so > >>>> that I could use "phy-connection-type" in my binding... > > >>> Is 3.14 broken because of missing the patch? If so I'll get it merged as > >> > a bug fix. > > >> No, it's not. I could have used "phy-connection-type" in my binding > >> destined for 3.15 and document it as a preferred property as well. > > > You still can. We just need to make sure that your patch is applied on > > Patches. > > > top of the phy-connection-type patch. > > I'm not sure this trick is possible if the patches are merged via the > different trees... There are two ways to do it. A) by having a common merge commit containing that patch and merged into both branches, or B) just merging the patch in the same tree. Normally I'd suggest B), but I've already picked up the patch and I try very hard not to rebase my commit tree. However, since the branch is stable, you can ask for my branch to be merged into the net branch before applying the dependant patches. The relevant commit id is cf4c9eb5a4, and it is in my devicetree/next branch on git://git.secretlab.ca/git/linux g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. On 02/11/2014 01:05 AM, Grant Likely wrote: >>>>>>>>>>>>> I'm afraid that's too late, it has spread very far, so that >>>>>>>>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type". >>>>>>>>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel >>>>>>>>>>>> doesn't even support it. >>>>>>>>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a >>>>>>>>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and >>>>>>>>>>> "phy-connection-type" since the former has been a Linux invention, but >>>>>>>>>>> the latter is ePAPR specified. >>>>>>>>>> Here is a link to the actual patch in question, not sure which tree >>>>>>>>>> Grant applied it to though: >>>>>>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html >>>>>>>>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in >>>>>>>>> this reply, and I couldn't follow the thread. Here's the actual patch mail: >>>>>>>>> http://marc.info/?l=devicetree&m=138449662807254 >>>>>>>> Florian, I didn't find this patch in Grant's official tree, so maybe you >>>>>>>> should ask him where is the patch already? >>>>>>> Sorry, I accidentally dropped it. It will be in the next merge window. >>>>>> Already saw it, thanks. Would that it was in 3.14 instead of course, so >>>>>> that I could use "phy-connection-type" in my binding... >>>>> Is 3.14 broken because of missing the patch? If so I'll get it merged as >>>>> a bug fix. >>>> No, it's not. I could have used "phy-connection-type" in my binding >>>> destined for 3.15 and document it as a preferred property as well. >>> You still can. We just need to make sure that your patch is applied on >> Patches. >>> top of the phy-connection-type patch. >> I'm not sure this trick is possible if the patches are merged via the >> different trees... > There are two ways to do it. A) by having a common merge commit > containing that patch and merged into both branches, or B) just merging > the patch in the same tree. > Normally I'd suggest B), but I've already picked up the patch and I try > very hard not to rebase my commit tree. However, since the branch is > stable, you can ask for my branch to be merged into the net branch > before applying the dependant patches. The relevant commit id is > cf4c9eb5a4, and it is in my devicetree/next branch on > git://git.secretlab.ca/git/linux David, would it be possible for you to merge this into net-next? > g. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: net-next/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt +++ net-next/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt @@ -4,13 +4,8 @@ Required properties: - compatible: should be "allwinner,sun4i-emac". - reg: address and length of the register set for the device. - interrupts: interrupt for the device -- phy: A phandle to a phy node defining the PHY address (as the reg - property, a single integer). - clocks: A phandle to the reference clock for this device -Optional properties: -- (local-)mac-address: mac address to be used by this driver - Example: emac: ethernet@01c0b000 { Index: net-next/Documentation/devicetree/bindings/net/arc_emac.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/arc_emac.txt +++ net-next/Documentation/devicetree/bindings/net/arc_emac.txt @@ -6,18 +6,6 @@ Required properties: - interrupts: Should contain the EMAC interrupts - clock-frequency: CPU frequency. It is needed to calculate and set polling period of EMAC. -- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations -bandwidth of external memory controller might be a limiting factor. That's why -it's required to specify which data-rate is supported on current SoC or FPGA. -For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is -supported (100BASE-TX) set "100". -- phy: PHY device attached to the EMAC via MDIO bus - -Child nodes of the driver are the individual PHY devices connected to the -MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus. - -Optional properties: -- mac-address: 6 bytes, mac address Examples: Index: net-next/Documentation/devicetree/bindings/net/cavium-mix.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/cavium-mix.txt +++ net-next/Documentation/devicetree/bindings/net/cavium-mix.txt @@ -18,13 +18,6 @@ Properties: - interrupts: Two interrupt specifiers. The first is the MIX interrupt routing and the second the routing for the AGL interrupts. -- mac-address: Optional, the MAC address to assign to the device. - -- local-mac-address: Optional, the MAC address to assign to the device - if mac-address is not specified. - -- phy-handle: Optional, a phandle for the PHY device connected to this device. - Example: ethernet@1070000100800 { compatible = "cavium,octeon-5750-mix"; Index: net-next/Documentation/devicetree/bindings/net/cavium-pip.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/cavium-pip.txt +++ net-next/Documentation/devicetree/bindings/net/cavium-pip.txt @@ -35,13 +35,6 @@ Properties for PIP port which is a child - reg: The port number within the interface group. -- mac-address: Optional, the MAC address to assign to the device. - -- local-mac-address: Optional, the MAC address to assign to the device - if mac-address is not specified. - -- phy-handle: Optional, a phandle for the PHY device connected to this device. - Example: pip@11800a0000000 { Index: net-next/Documentation/devicetree/bindings/net/cdns-emac.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/cdns-emac.txt +++ net-next/Documentation/devicetree/bindings/net/cdns-emac.txt @@ -6,11 +6,6 @@ Required properties: or the generic form: "cdns,emac". - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii". - -Optional properties: -- local-mac-address: 6 bytes, mac address Examples: Index: net-next/Documentation/devicetree/bindings/net/cpsw.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/cpsw.txt +++ net-next/Documentation/devicetree/bindings/net/cpsw.txt @@ -28,9 +28,6 @@ Optional properties: Slave Properties: Required properties: - phy_id : Specifies slave phy id -- phy-mode : The interface between the SoC and the PHY (a string - that of_get_phy_mode() can understand) -- mac-address : Specifies slave MAC address Optional properties: - dual_emac_res_vlan : Specifies VID to be used to segregate the ports Index: net-next/Documentation/devicetree/bindings/net/davicom-dm9000.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/davicom-dm9000.txt +++ net-next/Documentation/devicetree/bindings/net/davicom-dm9000.txt @@ -9,8 +9,6 @@ Required properties: - interrupts : interrupt specifier specific to interrupt controller Optional properties: -- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address - to use (from firmware or bootloader) - davicom,no-eeprom : Configuration EEPROM is not available - davicom,ext-phy : Use external PHY Index: net-next/Documentation/devicetree/bindings/net/davinci_emac.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/davinci_emac.txt +++ net-next/Documentation/devicetree/bindings/net/davinci_emac.txt @@ -19,9 +19,7 @@ Required properties: Miscellaneous Interrupt> Optional properties: -- phy-handle: Contains a phandle to an Ethernet PHY. - If absent, davinci_emac driver defaults to 100/FULL. -- local-mac-address : 6 bytes, mac address +- phy-handle: If absent, davinci_emac driver defaults to 100/FULL. Example (enbw_cmc board): eth0: emac@1e20000 { Index: net-next/Documentation/devicetree/bindings/net/ethernet.txt =================================================================== --- /dev/null +++ net-next/Documentation/devicetree/bindings/net/ethernet.txt @@ -0,0 +1,20 @@ +The following properties are common to the Ethernet controllers: + +- local-mac-address: array of 6 bytes, specifies the MAC address that was + assigned to the network device; +- mac-address: array of 6 bytes, specifies the MAC address that was last used by + the boot program; should be used in cases where the MAC address assigned to + the device by the boot program is different from the "local-mac-address" + property; +- max-speed: number, specifies maximum speed in Mbit/s supported by the device; +- phy-mode: string, operation mode of the PHY interface; supported values are + "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; +- phy-connection-type: the same as "phy-mode" property (but described in ePAPR); +- phy-handle: phandle, specifies a reference to a node representing a PHY + device (this property is described in ePAPR); +- phy: the same as "phy-handle" property (but actually ad-hoc one). + +Child nodes of the Ethernet controller are typically the individual PHY devices +connected via the MDIO bus (sometimes the MDIO bus controller is separate). +They are described in the phy.txt file in this same directory. Index: net-next/Documentation/devicetree/bindings/net/fsl-fec.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/fsl-fec.txt +++ net-next/Documentation/devicetree/bindings/net/fsl-fec.txt @@ -4,12 +4,8 @@ Required properties: - compatible : Should be "fsl,<soc>-fec" - reg : Address and length of the register set for the device - interrupts : Should contain fec interrupt -- phy-mode : String, operation mode of the PHY interface. - Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii", - "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii". Optional properties: -- local-mac-address : 6 bytes, mac address - phy-reset-gpios : Should specify the gpio for phy reset - phy-reset-duration : Reset duration in milliseconds. Should present only if property "phy-reset-gpios" is available. Missing the property Index: net-next/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ net-next/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt @@ -38,22 +38,15 @@ Properties: - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" - compatible : Should be "gianfar" - reg : Offset and length of the register set for the device - - local-mac-address : List of bytes representing the ethernet address of - this controller - interrupts : For FEC devices, the first interrupt is the device's interrupt. For TSEC and eTSEC devices, the first interrupt is transmit, the second is receive, and the third is error. - - phy-handle : The phandle for the PHY connected to this ethernet - controller. - fixed-link : <a b c d e> where a is emulated phy id - choose any, but unique to the all specified fixed-links, b is duplex - 0 half, 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. - - phy-connection-type : a string naming the controller/PHY interface type, - i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", - "tbi", or "rtbi". This property is only really needed if the connection - is of type "rgmii-id", as all other connection types are detected by - hardware. + - phy-connection-type : only really needed if the connection is of type + "rgmii-id", as all other connection types are detected by hardware. - fsl,magic-packet : If present, indicates that the hardware supports waking up via magic packet. - bd-stash : If present, indicates that the hardware supports stashing Index: net-next/Documentation/devicetree/bindings/net/lpc-eth.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/lpc-eth.txt +++ net-next/Documentation/devicetree/bindings/net/lpc-eth.txt @@ -6,10 +6,8 @@ Required properties: - interrupts: Should contain ethernet controller interrupt Optional properties: -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii" (default) +- phy-mode: if absent, "rmii" is assumed. - use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering -- local-mac-address : 6 bytes, mac address Example: Index: net-next/Documentation/devicetree/bindings/net/macb.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/macb.txt +++ net-next/Documentation/devicetree/bindings/net/macb.txt @@ -8,11 +8,6 @@ Required properties: the Cadence GEM, or the generic form: "cdns,gem". - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii", "gmii", "rgmii". - -Optional properties: -- local-mac-address: 6 bytes, mac address Examples: Index: net-next/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt +++ net-next/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt @@ -4,10 +4,6 @@ Required properties: - compatible: should be "marvell,armada-370-neta". - reg: address and length of the register set for the device. - interrupts: interrupt for the device -- phy: A phandle to a phy node defining the PHY address (as the reg - property, a single integer). -- phy-mode: The interface between the SoC and the PHY (a string that - of_get_phy_mode() can understand) - clocks: a pointer to the reference clock for this device. Example: Index: net-next/Documentation/devicetree/bindings/net/marvell-orion-net.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/marvell-orion-net.txt +++ net-next/Documentation/devicetree/bindings/net/marvell-orion-net.txt @@ -37,7 +37,6 @@ Required port properties: "marvell,kirkwood-eth-port". - reg: port number relative to ethernet controller, shall be 0, 1, or 2. - interrupts: port interrupt. - - local-mac-address: 6 bytes MAC address. Optional port properties: - marvell,tx-queue-size: size of the transmit ring buffer. @@ -49,7 +48,7 @@ Optional port properties: and - - phy-handle: phandle reference to ethernet PHY. + - phy-handle: if a PHY is connected. or Index: net-next/Documentation/devicetree/bindings/net/micrel-ks8851.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/micrel-ks8851.txt +++ net-next/Documentation/devicetree/bindings/net/micrel-ks8851.txt @@ -4,6 +4,3 @@ Required properties: - compatible = "micrel,ks8851-ml" of parallel interface - reg : 2 physical address and size of registers for data and command - interrupts : interrupt connection - -Optional properties: -- local-mac-address : Ethernet mac address to use Index: net-next/Documentation/devicetree/bindings/net/smsc-lan91c111.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/smsc-lan91c111.txt +++ net-next/Documentation/devicetree/bindings/net/smsc-lan91c111.txt @@ -7,7 +7,6 @@ Required properties: Optional properties: - phy-device : phandle to Ethernet phy -- local-mac-address : Ethernet mac address to use - reg-io-width : Mask of sizes (in bytes) of the IO accesses that are supported on the device. Valid value for SMSC LAN91c111 are 1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning Index: net-next/Documentation/devicetree/bindings/net/smsc911x.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/smsc911x.txt +++ net-next/Documentation/devicetree/bindings/net/smsc911x.txt @@ -6,9 +6,6 @@ Required properties: - interrupts : Should contain SMSC LAN interrupt line - interrupt-parent : Should be the phandle for the interrupt controller that services interrupts for this device -- phy-mode : String, operation mode of the PHY interface. - Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii", - "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii". Optional properties: - reg-shift : Specify the quantity to shift the register offsets by @@ -23,7 +20,6 @@ Optional properties: external PHY - smsc,save-mac-address : Indicates that mac address needs to be saved before resetting the controller -- local-mac-address : 6 bytes, mac address Examples: Index: net-next/Documentation/devicetree/bindings/net/stmmac.txt =================================================================== --- net-next.orig/Documentation/devicetree/bindings/net/stmmac.txt +++ net-next/Documentation/devicetree/bindings/net/stmmac.txt @@ -10,8 +10,6 @@ Required properties: - interrupt-names: Should contain the interrupt names "macirq" "eth_wake_irq" if this interrupt is supported in the "interrupts" property -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii", "gmii", "rgmii". - snps,phy-addr phy address to connect to. - snps,reset-gpio gpio number for phy reset. - snps,reset-active-low boolean flag to indicate if phy reset is active low. @@ -28,9 +26,6 @@ Required properties: mode for both tx and rx. This flag is ignored if force_thresh_dma_mode is set. -Optional properties: -- mac-address: 6 bytes, mac address - Examples: gmac0: ethernet@e0800000 {
This patch is an attempt to gather the Ethernet related bindings in one file, like it's done in the MMC and some other subsystems. It should save the trouble of documenting several properties over and over in each binding document. I have used the Embedded Power Architecture(TM) Platform Requirements (ePAPR) standard as a base for the properties description, also documenting some ad-hoc properties that have been introduced over time despite having direct analogs in ePAPR. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> --- The patch is against DaveM's 'net-next.git' repo and the DaVinci EMAC bindings fix I've posted yesterday: http://patchwork.ozlabs.org/patch/311854/ Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt | 5 -- Documentation/devicetree/bindings/net/arc_emac.txt | 12 ------ Documentation/devicetree/bindings/net/cavium-mix.txt | 7 --- Documentation/devicetree/bindings/net/cavium-pip.txt | 7 --- Documentation/devicetree/bindings/net/cdns-emac.txt | 5 -- Documentation/devicetree/bindings/net/cpsw.txt | 3 - Documentation/devicetree/bindings/net/davicom-dm9000.txt | 2 - Documentation/devicetree/bindings/net/davinci_emac.txt | 4 -- Documentation/devicetree/bindings/net/ethernet.txt | 20 ++++++++++ Documentation/devicetree/bindings/net/fsl-fec.txt | 4 -- Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 11 +---- Documentation/devicetree/bindings/net/lpc-eth.txt | 4 -- Documentation/devicetree/bindings/net/macb.txt | 5 -- Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 4 -- Documentation/devicetree/bindings/net/marvell-orion-net.txt | 3 - Documentation/devicetree/bindings/net/micrel-ks8851.txt | 3 - Documentation/devicetree/bindings/net/smsc-lan91c111.txt | 1 Documentation/devicetree/bindings/net/smsc911x.txt | 4 -- Documentation/devicetree/bindings/net/stmmac.txt | 5 -- 19 files changed, 25 insertions(+), 84 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html