From: Vincent Mailhol <mailhol@kernel.org>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
Vincent Mailhol <mailhol@kernel.org>,
Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "Stéphane Grosjean" <stephane.grosjean@hms-networks.com>,
"Robert Nawrath" <mbro1689@gmail.com>,
"Minh Le" <minh.le.aj@renesas.com>,
"Duy Nguyen" <duy.nguyen.rh@renesas.com>,
linux-can@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/21] can: netlink: preparation before introduction of CAN XL step 2/2
Date: Thu, 4 Sep 2025 18:18:21 +0900 [thread overview]
Message-ID: <88d2836b-2702-481f-b504-20c6efa5cb1a@kernel.org> (raw)
In-Reply-To: <e37c9890-823f-4a38-bdcc-c170dbe67e13@hartkopp.net>
On 04/09/2025 at 15:36, Oliver Hartkopp wrote:
> On 03.09.25 11:26, Vincent Mailhol wrote:
>> On 03/09/2025 à 17:49, Vincent Mailhol wrote:
>>
>> (...)
>>
>>> The follow up series which introduces CAN XL is nearly completed but
>>> will be sent only once this one is approved: one thing at a time, I do
>>> not want to overwhelm people (including myself).
>>
>> If you want a preview of the full CAN XL, you can have a look at my work in
>> progress here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/linux.git/
>> log/?h=b4/canxl-netlink
>> https://git.kernel.org/pub/scm/linux/kernel/git/mailhol/iproute2-next.git/
>> log/?h=canxl-netlink
>>
>> The kernel part is nearly completed, but I am still playing some whack-a-mole to
>> find potential gaps in the configuration validation. I also need to rewrite or
>> fine tune the commit description.
>>
>> The iproute2 part is still under development. It has the PWM interface but I
>> have not added all the control modes yet.
>>
>
> Thanks Vincent!
>
> The repos are very helpful.
>
> With "missing" control modes you refer to CAN_CTRLMODE_XL_ERR_SIGNAL,
> CAN_CTRLMODE_XL_RRS and CAN_CTRLMODE_RESTRICTED, right?
Yes, I only added the CAN_CTRLMODE_XL_TMS so far in iproute2. The kernel has all
of the four flags (but because I did not finish testing, I highly suspect that
there are still some bugs somewhere).
Concerning the CAN_CTRLMODE_XL_RRS, I am not sure if that one is needed. I still
have it in my WIP series but I am recently considering to remove it. The reason
is that when reading ISO 11898-1 having RRS configurable looks mandatory to me.
In the logical Link control (LLC) this RRS bit is named FTYP (for Frame Type).
For example, CiA only mentions FTYP in their CAN XL knowledge page:
https://www.can-cia.org/can-knowledge/can-xl
Contrarily to CAN FD's RRS which is indeed specified as being dominant and which
is just ignored in the LLC, the CAN XL FTYP/RRS is part of the LLC interface and
is meant to be configurable.
Nothing in the standard tells us that this should be a dominant bit. I think
your intention was to add CAN_CTRLMODE_XL_RRS as a quirk for the devices which
expose this flag. But as far as I can see, it seems that a device which does not
expose it is just not compliant.
If some day a device which can not set the FTYP/RRS flag appears in the wild,
then maybe we can add a flag which would specify that RRS is not configurable
(opposite logic as what you suggested). But as long as such a device do not
exist, it is better to add nothing.
Yours sincerely,
Vincent Mailhol
next prev parent reply other threads:[~2025-09-04 9:18 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-03 8:49 [PATCH 00/21] can: netlink: preparation before introduction of CAN XL step 2/2 Vincent Mailhol
2025-09-03 8:50 ` [PATCH 01/21] can: dev: move struct data_bittiming_params to linux/can/bittiming.h Vincent Mailhol
2025-09-03 8:50 ` [PATCH 02/21] can: dev: make can_get_relative_tdco() FD agnostic and move it to bittiming.h Vincent Mailhol
2025-09-03 8:50 ` [PATCH 03/21] can: netlink: document which symbols are FD specific Vincent Mailhol
2025-09-03 8:50 ` [PATCH 04/21] can: netlink: refactor can_validate_bittiming() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 05/21] can: netlink: add can_validate_tdc() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 06/21] can: netlink: add can_validate_databittiming() Vincent Mailhol
2025-09-04 18:46 ` kernel test robot
2025-09-05 14:55 ` Vincent Mailhol
2025-09-03 8:50 ` [PATCH 07/21] can: netlink: remove comment in can_validate() Vincent Mailhol
2025-09-04 6:51 ` Oliver Hartkopp
2025-09-04 9:48 ` Vincent Mailhol
2025-09-05 10:55 ` Oliver Hartkopp
2025-09-05 15:12 ` Vincent Mailhol
2025-09-03 8:50 ` [PATCH 08/21] can: netlink: refactor CAN_CTRLMODE_TDC_{AUTO,MANUAL} flag reset logic Vincent Mailhol
2025-09-03 8:50 ` [PATCH 09/21] can: netlink: remove useless check in can_tdc_changelink() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 10/21] can: netlink: make can_tdc_changelink() FD agnostic Vincent Mailhol
2025-09-03 8:50 ` [PATCH 11/21] can: netlink: add can_dtb_changelink() Vincent Mailhol
2025-09-04 20:29 ` kernel test robot
2025-09-03 8:50 ` [PATCH 12/21] can: netlink: add can_ctrlmode_changelink() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 13/21] can: netlink: make can_tdc_get_size() FD agnostic Vincent Mailhol
2025-09-03 8:50 ` [PATCH 14/21] can: netlink: add can_data_bittiming_get_size() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 15/21] can: netlink: add can_bittiming_fill_info() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 16/21] can: netlink: add can_bittiming_const_fill_info() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 17/21] can: netlink: add can_bitrate_const_fill_info() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 18/21] can: netlink: make can_tdc_fill_info() FD agnostic Vincent Mailhol
2025-09-04 22:01 ` kernel test robot
2025-09-03 8:50 ` [PATCH 19/21] can: calc_bittiming: make can_calc_tdco() " Vincent Mailhol
2025-09-03 8:50 ` [PATCH 20/21] can: dev: add can_get_ctrlmode_str() Vincent Mailhol
2025-09-03 8:50 ` [PATCH 21/21] can: netlink: add userland error messages Vincent Mailhol
2025-09-03 9:26 ` [PATCH 00/21] can: netlink: preparation before introduction of CAN XL step 2/2 Vincent Mailhol
2025-09-04 6:36 ` Oliver Hartkopp
2025-09-04 9:18 ` Vincent Mailhol [this message]
2025-09-05 11:11 ` Oliver Hartkopp
2025-09-05 14:58 ` Vincent Mailhol
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=88d2836b-2702-481f-b504-20c6efa5cb1a@kernel.org \
--to=mailhol@kernel.org \
--cc=duy.nguyen.rh@renesas.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbro1689@gmail.com \
--cc=minh.le.aj@renesas.com \
--cc=mkl@pengutronix.de \
--cc=socketcan@hartkopp.net \
--cc=stephane.grosjean@hms-networks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox