netdev - Re: [PATCH net-next v4 1/2] dts: Add a binding for Synopsys emac max-frame-size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Jan 2014 13:29:18 -0600
From:	Rob Herring <robherring2@...il.com>
To:	Vince Bridgers <vbridgers2013@...il.com>
Cc:	Ben Hutchings <bhutchings@...arflare.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	netdev@...r.kernel.org,
	Giuseppe CAVALLARO <peppe.cavallaro@...com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Dinh Nguyen <dinguyen@...era.com>,
	Rayagond Kokatanur <rayagond@...avyalabs.com>
Subject: Re: [PATCH net-next v4 1/2] dts: Add a binding for Synopsys emac max-frame-size

On Thu, Jan 16, 2014 at 12:48 PM, Vince Bridgers
<vbridgers2013@...il.com> wrote:
> On Thu, Jan 16, 2014 at 11:50 AM, Ben Hutchings
> <bhutchings@...arflare.com> 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@...il.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.
>
> 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".

Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html