Re: [PATCH net-next v3 2/3] net: macb: add safeguards for jumbo frame larger than 10240

["Théo Lebrun" <theo.lebrun@bootlin.com>]

On Tue Mar 17, 2026 at 1:29 PM CET, Paolo Abeni wrote:
> On 3/16/26 7:26 PM, Charles Perry wrote:
>> On Mon, Mar 16, 2026 at 06:21:38PM +0100, Théo Lebrun wrote:
>>> Hello Charles,
>>>
>>> On Fri Mar 13, 2026 at 3:06 PM CET, Charles Perry wrote:
>>>> The RX buffers for GEM can have a maximum size of 16320 bytes
>>>> (0xff in the RXBS field of the DMACFG register means 255*64 =
>>>> 16320 bytes).
>>>>
>>>> The GEM IP has configurable maximum jumbo frame length that can go up to
>>>> 16383. The actual value for this limit can be found in the
>>>>        "jumbo_max_length" field (bits 0..13) of the DCFG2 register.
>>>> Currently, the macb driver doesn't use the DCFG2 register when
>>>> determining the max MTU, instead an hardcoded value (jumbo_max_len in
>>>> struct macb_config) is used for each platform. Right now the maximum
>>>> value for jumbo_max_len is 10240 (0x2800).
>>>
>>> If DCFG2 contains the value then we can runtime detect it. With that, we
>>> could make the macb_config->jumbo_max_len attribute optional. Then
>>> start dropping it from platforms where we know we can trust the DCFG2
>>> value.
>>>
>> 
>> Hello Théo,
>> 
>> That would be a good idea. We could use "jumbo_max_len == 0" as a way to
>> signal that the DCFG2 register should be used for determining the max MTU.
>> 
>> However, that's a new feature and it doesn't belong in this patch. All I
>> want to do in this patchset is put the real value of jumbo_max_length in
>> the PIC64-HPSC macb_config and make sure the driver doesn't overflow when
>> that's used.
>
> FWIW, I agree that is better suited for a follow-up than for the initial
> bring-up.

then:

Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>

Thanks,

--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com