Re: [RFC PATCH v5 2/2] can: reject CAN FD content when disabled on CAN XL interfaces

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 18.09.25 11:18, Vincent Mailhol wrote:
> On 18/09/2025 at 06:29, Oliver Hartkopp wrote:


>> Will the user defined MTU for CAN XL survive the settings when xl is set to off
>> and then set to on again?
> 
> Unfortunately no. Or at least not without adding one additional field to save
> the old value.
> 
> But after turning FD or XL off, none on the bittiming parameters would survive
> either. So I think it is coherent to say that the user has to set everything
> again each time XL is switched on.
> 

Ok. IMO setting the CAN XL MTU lower than CANXL_MTU_MAX is a power user 
feature anyway. So setting the bitrates and the MTU in one sequence 
should be no problem.


>> To sum it up for myself:
>>
>> 1. Setting the MTU from user space is only relevant for virtual CAN interfaces
>> and CAN XL interfaces for values between CANXL_MIN_MTU and CANXL_MAX_MTU.
> 
> Ack.
> 
>> 2. Usually the MTU is set automatically by the netlink configuration process
>> when fd/xl on/off are set.
> 
> Ack.
> 
> As you will see, I found some bug because a few drivers forgot to set their
> can_change_mtu() and addressed the issue here:
> 
> https://lore.kernel.org/linux-can/20250918-can-fix-mtu-v1-0-0d1cada9393b@kernel.org/
> 
> That series is just to fix things and is meant to be back ported to stable.

Nice cleanup!

> I will send a couple more patches as an RFC which will implement the actual
> logic which we discussed here.

Fine!

I assume we will miss this merge window for the CAN XL support then.
With all the things that need to be looked at carefully the next merge 
window is probably the better choice.

Best regards,
Oliver