On Thu, 2014-01-16 at 13:29 -0600, Rob Herring wrote: > On Thu, Jan 16, 2014 at 12:48 PM, Vince Bridgers > <vbridgers2013@xxxxxxxxx> wrote: > > On Thu, Jan 16, 2014 at 11:50 AM, Ben Hutchings > > <bhutchings@xxxxxxxxxxxxxx> wrote: > >> On Thu, 2014-01-16 at 08:05 -0600, Vince Bridgers wrote: > >>> This change adds a parameter for the Synopsys 10/100/1000 > >>> stmmac Ethernet driver to configure the maximum frame > >>> size supported by the EMAC driver. Synopsys allows the FIFO > >>> sizes to be configured when the cores are built for a particular > >>> device, but do not provide a way for the driver to read > >>> information from the device about the maximum MTU size > >>> supported as limited by the device's FIFO size. > >>> > >>> Signed-off-by: Vince Bridgers <vbridgers2013@xxxxxxxxx> > >>> --- > >>> V4: add comments to explain use of max-frame-size with respect > >>> to inconsistent definition and use in the ePAPR v1.1 spec > >> > >> Well, ePAPR does not seem to be consistent with itself. :-) > >> > >>> V3: change snps,max-frame-size to max-frame-size > >>> V2: change snps,max-mtu to snps,max-frame-size > >>> --- > >>> Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++++++- > >>> 1 file changed, 12 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt > >>> index eba0e5e..d553be2 100644 > >>> --- a/Documentation/devicetree/bindings/net/stmmac.txt > >>> +++ b/Documentation/devicetree/bindings/net/stmmac.txt > >>> @@ -29,7 +29,17 @@ Required properties: > >>> ignored if force_thresh_dma_mode is set. > >>> > >>> Optional properties: > >>> -- mac-address: 6 bytes, mac address > >>> +- mac-address: 6 bytes, mac address > >>> +- max-frame-size: Maximum frame size permitted. This parameter is useful > >>> + since different implementations of the Synopsys MAC may > >>> + have different FIFO sizes depending on the selections > >>> + made in Synopsys Core Consultant. Note that the usage > >>> + is inconsistent with the definition in the ePAPR v1.1 > >>> + specification, as it defines max-frame-size inclusive > >>> + of the MAC DA, SA, Ethertype and CRC while usage is > >>> + consistent with the IEEE definition of MAC Client > >>> + Data, which is sans the MAC DA, SA, Ethertype and > >>> + CRC. > >> [...] > >> > >> While this is very precise, I fear that it is now so verbose that it > >> actually becomes confusing. Can this not be condensed to 'the maximum > >> MTU and MRU, rather than the maximum Ethernet frame size'? > >> > >> Ben. > > > > Sure, I'll cut this down and resubmit as V5. How about > > > > "The Maximum Transfer Unit (IEEE defined MTU), rather than the maximum > > frame size." > > If you are not following the ePAPR definition, then call the property > something else rather than relying on the documentation to explain the > different meaning. Why can't the driver adjust the size from the ePAPR > definition? Otherwise, I would go back to the v2 name of > "snps,max-mtu". ePAPR *doesn't have* a clear definition: http://article.gmane.org/gmane.linux.network/300098 Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
