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

[Vincent Mailhol <mailhol@kernel.org>]

On 21/09/2025 at 02:38, Oliver Hartkopp wrote:
> 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.

Yes, but I hope that to have the preparation series merged. Marc already picked
the MTU fix series:

https://lore.kernel.org/linux-can/20250918-can-fix-mtu-v1-0-0d1cada9393b@kernel.org/

Next week, I would like to merge the MTU rework:

https://lore.kernel.org/linux-can/20250918-can-fix-mtu-v1-0-471edb942295@kernel.org/

as well as the XL preparation:

https://lore.kernel.org/linux-can/20250910-canxl-netlink-prep-v2-0-f128d4083721@kernel.org/

Both are ready locally, but I first need to wait for the MTU fix to appear in
net-next before re-sending.

> With all the things that need to be looked at carefully the next merge window is
> probably the better choice.

By the way, my latest test are all green.

I updated my WIP

https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/linux.git/log/?h=b4/canxl-netlink

I may still refactor a few things and I still need to write the patch comments,
but feature wise, I now implemented all what I had in mind.

But for next week, let's focus on the preparation series first, the discussion
on the actual XL code will be for the next merge window ;)


Yours sincerely,
Vincent Mailhol