Re: [PATCH net-next v2 10/10] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY

[Andrew Lunn]

> > Does the standard say anything about this? It seems like something
> > which could be moved into the core.
> 
> The comment is a mistake on my part, as it doesn't clearly describe why we
> have to pad the skb. It's a case of a MAC device which doesn't pad a frame to
> a minimum size when the host wants to transmit less than 64 bytes. I'll update
> it in v3 to say:
> 
> /* The MAC doesn't automatically pad the frame to a 64 byte minimum size in
>  * case the host sent a shorter skb, so we have to do it in the driver. The FCS
>  * will be added by the MAC.
>  */

Just an FYI: the 64 bytes includes the FCS. So if the MAC is adding
the FCS, you should pad to 60, not 64.

> As for what the OA TC6 standard says, this is the relevant section
> (7.3 - Data Transaction Protocol for Ethernet Frames)
> 
> "Ethernet frames are typically transferred from the SPI host to the MAC-PHY without
> any padding or frame check sequence (FCS). The MAC will automatically pad the Ethernet
> frame to the minimum frame size of 64 bytes and append a computed FCS. However, the
> Ethernet specification allows for the SPI host to optionally perform the frame padding and
> FCS computation prior to transfer to the MAC-PHY. Similarly, the MAC-PHY will typically
> strip the FCS from received Ethernet frames prior to transfer to the SPI host. However,
> the Ethernet specification allows the option for the Ethernet frame to be transferred to the
> MAC client with the FCS.
> 
> The IEEE Ethernet standard [2] defines the behavior of the MAC and therefore is beyond
> the scope of this specification. As a result, support for allowing the SPI host to perform frame
> padding and FCS computation, or passing the FCS to the SPI host is optional. When supported,
> the method for configuring the MAC-PHY to enable these modes of frame transfer is
> implementation specific."
> 
> As I understand, from the TC6 standard point of view, the padding and FCS offload is optional.
> So, I think this shouldn't go into the core. 

Thanks for the quotes from the standard. I personally think this was a
bad decision by the authors of the standard, leaving it ambiguous.

In the end, putting it in the driver seems like a good first
approach. Maybe as we get more devices following the standard, we see
it is common to need padding, and we move it into the core controlled
by a quirk. But that can come later.

   Andrew