From: Vincent Mailhol <mailhol@kernel.org>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
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: Fri, 5 Sep 2025 23:58:50 +0900 [thread overview]
Message-ID: <6799c8a7-cc0e-4df0-aa08-10b948b58c4d@kernel.org> (raw)
In-Reply-To: <32fc8ebf-1cf5-41b0-b843-1af4821a8ddb@hartkopp.net>
On 05/09/2025 at 20:11, Oliver Hartkopp wrote:
> On 04.09.25 11:18, Vincent Mailhol wrote:
>
>> 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.
>
> I double checked my XCANB CAN XL controller spec and indeed the RRS bit is part
> of every RX/TX FIFO element and the figures see it as configurable element too.
>
>> 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.
>
> Let's see if we will find CAN XL IP cores where the engineers have a different
> view on this. I currently have a discussion on this RRS bit with the Vector
> support because the RRS bit is not visible in the CANalyser 19 GUI.
>
>> 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.
>
> ACK. After this discussion I would also vote to omit my glorious patch which
> added the CAN_CTRLMODE_XL_RRS flag. Let's see if we find a CAN XL controller
> that does not support the variable RRS bit in reading and writing. And if it
> shows up we can add this flag to handle it (similar to the fd-non-iso feature).
OK. Good that we reached out to the same conclusion :)
Because I already implemented all the logic, I will save the current RRS patch
somewhere in case we need to resurrect it some days.
Yours sincerely,
Vincent Mailhol
prev parent reply other threads:[~2025-09-05 14:58 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
2025-09-05 11:11 ` Oliver Hartkopp
2025-09-05 14:58 ` Vincent Mailhol [this message]
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=6799c8a7-cc0e-4df0-aa08-10b948b58c4d@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.