The TDCO calculation was done using the currently applied data bittiming,
instead of the newly computed data bittiming, which means that the TDCO
had an invalid value unless setting the same data bittiming twice.
Fixes: d99755f71a80 ("can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)")
Signed-off-by: Maxime Jayat <[email protected]>
---
drivers/net/can/dev/netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/dev/netlink.c b/drivers/net/can/dev/netlink.c
index 036d85ef07f5..dfdc039d92a6 100644
--- a/drivers/net/can/dev/netlink.c
+++ b/drivers/net/can/dev/netlink.c
@@ -346,7 +346,7 @@ static int can_changelink(struct net_device *dev, struct nlattr *tb[],
/* Neither of TDC parameters nor TDC flags are
* provided: do calculation
*/
- can_calc_tdco(&priv->tdc, priv->tdc_const, &priv->data_bittiming,
+ can_calc_tdco(&priv->tdc, priv->tdc_const, &dbt,
&priv->ctrlmode, priv->ctrlmode_supported);
} /* else: both CAN_CTRLMODE_TDC_{AUTO,MANUAL} are explicitly
* turned off. TDC is disabled: do nothing
--
2.34.1
On Tue. 7 Nov. 2023 at 03:02, Maxime Jayat
<[email protected]> wrote:
> The TDCO calculation was done using the currently applied data bittiming,
> instead of the newly computed data bittiming, which means that the TDCO
> had an invalid value unless setting the same data bittiming twice.
Nice catch!
Moving the can_calc_tdco() before the memcpy(&priv->data_bittiming,
&dbt, sizeof(dbt)) was one of the last changes I made. And the last
batch of tests did not catch that. Thanks for the patch!
> Fixes: d99755f71a80 ("can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)")
> Signed-off-by: Maxime Jayat <[email protected]>
Reviewed-by: Vincent Mailhol <[email protected]>
> ---
> drivers/net/can/dev/netlink.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/dev/netlink.c b/drivers/net/can/dev/netlink.c
> index 036d85ef07f5..dfdc039d92a6 100644
> --- a/drivers/net/can/dev/netlink.c
> +++ b/drivers/net/can/dev/netlink.c
> @@ -346,7 +346,7 @@ static int can_changelink(struct net_device *dev, struct nlattr *tb[],
> /* Neither of TDC parameters nor TDC flags are
> * provided: do calculation
> */
> - can_calc_tdco(&priv->tdc, priv->tdc_const, &priv->data_bittiming,
> + can_calc_tdco(&priv->tdc, priv->tdc_const, &dbt,
> &priv->ctrlmode, priv->ctrlmode_supported);
> } /* else: both CAN_CTRLMODE_TDC_{AUTO,MANUAL} are explicitly
> * turned off. TDC is disabled: do nothing
> --
> 2.34.1
>
Hi all,
I have an old PCAN USB adapter (Classical CAN) which uses the pcan_usb
driver and wanted to set a 50kbit/s bitrate:
ip link set can0 up txqueuelen 500 type can bitrate 50000 sjw 4
First it complained about the SJW having a higher value than some
phase-seg value which was 2.
Error: sjw: 4 greater than phase-seg2: 2.
I always thought the driver automatically adapts the SJW value to the
highest possible and SJW=4 could always be set. Did this change at a
certain point?
Anyway, then I reduced the given SJW value and the ip command did not
give any error message.
But finally there was not CAN traffic possible with my "always working
setup".
I'm running 6.8.0-rc4-00433-g92a355464776 from Linus' tree.
Reverting this patch fixed my issue.
Best regards,
Oliver
On 07.11.23 03:26, Vincent MAILHOL wrote:
> On Tue. 7 Nov. 2023 at 03:02, Maxime Jayat
> <[email protected]> wrote:
>> The TDCO calculation was done using the currently applied data bittiming,
>> instead of the newly computed data bittiming, which means that the TDCO
>> had an invalid value unless setting the same data bittiming twice.
>
> Nice catch!
>
> Moving the can_calc_tdco() before the memcpy(&priv->data_bittiming,
> &dbt, sizeof(dbt)) was one of the last changes I made. And the last
> batch of tests did not catch that. Thanks for the patch!
>
>> Fixes: d99755f71a80 ("can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)")
>> Signed-off-by: Maxime Jayat <[email protected]>
>
> Reviewed-by: Vincent Mailhol <[email protected]>
>
>> ---
>> drivers/net/can/dev/netlink.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/can/dev/netlink.c b/drivers/net/can/dev/netlink.c
>> index 036d85ef07f5..dfdc039d92a6 100644
>> --- a/drivers/net/can/dev/netlink.c
>> +++ b/drivers/net/can/dev/netlink.c
>> @@ -346,7 +346,7 @@ static int can_changelink(struct net_device *dev, struct nlattr *tb[],
>> /* Neither of TDC parameters nor TDC flags are
>> * provided: do calculation
>> */
>> - can_calc_tdco(&priv->tdc, priv->tdc_const, &priv->data_bittiming,
>> + can_calc_tdco(&priv->tdc, priv->tdc_const, &dbt,
>> &priv->ctrlmode, priv->ctrlmode_supported);
>> } /* else: both CAN_CTRLMODE_TDC_{AUTO,MANUAL} are explicitly
>> * turned off. TDC is disabled: do nothing
>> --
>> 2.34.1
>>
>
On 21.02.2024 15:14:02, Oliver Hartkopp wrote:
> I have an old PCAN USB adapter (Classical CAN) which uses the pcan_usb
> driver and wanted to set a 50kbit/s bitrate:
>
> ip link set can0 up txqueuelen 500 type can bitrate 50000 sjw 4
>
> First it complained about the SJW having a higher value than some phase-seg
> value which was 2.
>
> Error: sjw: 4 greater than phase-seg2: 2.
>
> I always thought the driver automatically adapts the SJW value to the
> highest possible and SJW=4 could always be set. Did this change at a certain
> point?
Yes, that changed with b5a3d0864ee7 ("can: bittiming: can_sjw_check():
check that SJW is not longer than either Phase Buffer Segment")
See discussion in https://lore.kernel.org/all/[email protected]/
> Anyway, then I reduced the given SJW value and the ip command did not give
> any error message.
>
> But finally there was not CAN traffic possible with my "always working
> setup".
>
> I'm running 6.8.0-rc4-00433-g92a355464776 from Linus' tree.
>
> Reverting this patch fixed my issue.
But what has the tdco calculation to do with non CAN-FD controllers?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
Hello Marc,
On 21.02.24 15:24, Marc Kleine-Budde wrote:
> On 21.02.2024 15:14:02, Oliver Hartkopp wrote:
>> I have an old PCAN USB adapter (Classical CAN) which uses the pcan_usb
>> driver and wanted to set a 50kbit/s bitrate:
>>
>> ip link set can0 up txqueuelen 500 type can bitrate 50000 sjw 4
>>
>> First it complained about the SJW having a higher value than some phase-seg
>> value which was 2.
>>
>> Error: sjw: 4 greater than phase-seg2: 2.
>>
>> I always thought the driver automatically adapts the SJW value to the
>> highest possible and SJW=4 could always be set. Did this change at a certain
>> point?
>
> Yes, that changed with b5a3d0864ee7 ("can: bittiming: can_sjw_check():
> check that SJW is not longer than either Phase Buffer Segment")
>
> See discussion in https://lore.kernel.org/all/[email protected]/
Ok, thanks.
>> Anyway, then I reduced the given SJW value and the ip command did not give
>> any error message.
>>
>> But finally there was not CAN traffic possible with my "always working
>> setup".
>>
>> I'm running 6.8.0-rc4-00433-g92a355464776 from Linus' tree.
>>
>> Reverting this patch fixed my issue.
>
> But what has the tdco calculation to do with non CAN-FD controllers?
Hm, I was using a Debian 6.1 kernel in between, which worked.
Then I booted my 6.8.0-rc4-00433-g92a355464776 again, reverted the patch
and loaded the changed can-dev module by hand - which then also worked.
To double check now I was unloading the patched version and using the
can-dev from /lib/modules again, also works ¯\_(ツ)_/¯
So, I'll have to make more investigations what really went wrong here.
I also was astonished about such CAN FD dependency.
Will come back with more info about my experienced issue.
So far please drop my blame for this patch.
Best regards,
Oliver