Netdev List
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: Vince Bridgers <vbridgers2013@gmail.com>
Cc: <devicetree@vger.kernel.org>, <netdev@vger.kernel.org>,
	<peppe.cavallaro@st.com>, <robh+dt@kernel.org>,
	<pawel.moll@arm.com>, <mark.rutland@arm.com>,
	<ijc+devicetree@hellion.org.uk>, <galak@codeaurora.org>,
	<dinguyen@altera.com>, <rayagond@vayavyalabs.com>
Subject: Re: [PATCH net-next v4 1/2] dts: Add a binding for Synopsys emac max-frame-size
Date: Thu, 16 Jan 2014 17:50:01 +0000	[thread overview]
Message-ID: <1389894601.11912.54.camel@bwh-desktop.uk.level5networks.com> (raw)
In-Reply-To: <1389881155-9758-2-git-send-email-vbridgers2013@gmail.com>

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@gmail.com>
> ---
> 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.

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

  reply	other threads:[~2014-01-16 17:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-16 14:05 [PATCH net-next v4 0/2] stmmac: fix kernel crashes for jumbo frames Vince Bridgers
2014-01-16 14:05 ` [PATCH net-next v4 1/2] dts: Add a binding for Synopsys emac max-frame-size Vince Bridgers
2014-01-16 17:50   ` Ben Hutchings [this message]
2014-01-16 18:48     ` Vince Bridgers
2014-01-16 19:00       ` Ben Hutchings
2014-01-16 19:29       ` Rob Herring
2014-01-16 19:45         ` Ben Hutchings
2014-01-16 14:05 ` [PATCH net-next v4 2/2] stmmac: Fix kernel crashes for jumbo frames Vince Bridgers

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=1389894601.11912.54.camel@bwh-desktop.uk.level5networks.com \
    --to=bhutchings@solarflare.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dinguyen@altera.com \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=pawel.moll@arm.com \
    --cc=peppe.cavallaro@st.com \
    --cc=rayagond@vayavyalabs.com \
    --cc=robh+dt@kernel.org \
    --cc=vbridgers2013@gmail.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