On 08/09/2018 09:04 AM, "André Hartmann" wrote:
>>> +
>>> + result = can_get_bittiming(name,&bitTiming);
>>> + if (result == -1)
>>> + return result;
>>
>> Why do you get the bittiming from the kernel here?
>>
>>> +
>>> + // Kernel wants to recalc, remove bitrate to avoid EINVAL in can_get_bittiming
>>> + bitTiming.bitrate = 0;
>>> +
>>> + struct req_info req_info = {
>>> + .bittiming = &bitTiming,
>>
>> and why do you set it?
>
> Because we have two functions to set the (arbitration) bitrate and
> the data bitrate, but set_link() will set both at once. So if you set
> the data bitrate, just must ensure that the previous set arbitration
> bitrate stays.
You're right. The kernel expects you to set bitrate and data_bitrate at
the same time to keep the interface in a consistent state.
> The question arises, if a similar behaviour would be needed in can_set_bitrate also?
> (to set a new arbitration bitrate, but keeping the existing data bitrate)
Or we need a function to set the bitrate and data_bitrate at the same
time, just like the kernel expects it.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Attachment:
signature.asc
Description: OpenPGP digital signature
