Re: [RFC PATCH v4 3/4] iplink_can: print brp and dbrp bittiming variables

Am Freitag, den 09.07.2021, 14:17 +0200 schrieb Vincent MAILHOL:

On Wed. 7 Jul 2021 at 18:33, Stefan Mätje [off-list ref] wrote:

quoted

Am Dienstag, den 29.06.2021, 00:44 +0900 schrieb Vincent Mailhol:

quoted

Report the value of the bit-rate prescaler (brp) for both the nominal
and the data bittiming.

Currently, only the constant brp values (brp_{min,max,inc}) are being
reported. Also, brp is the only member of struct can_bittiming not
being reported.

Although brp is not used as an input for bittiming calculation, it
makes sense to output it.

Signed-off-by: Vincent Mailhol <redacted>

I think it is a good idea to display both brp and dbrp values because it makes
the displayed bitrate settings complete. Even if it could be calculated from the
displayed clock and tq values.

Your remark is true. I also realized that BRP can be calculated
from the other parameters but because I am lazy, I like to have
it reported so I wrote this patch. I will add a note in the patch
comments to reflect that this value could be calculated by hand.

A late comment on this ...

I didn't mean in any way that the BRP value should not be shown because it 
could be calculated from the other displayed values.

But I'm happy with this change because the CAN clock, BRP, prop seg and 
tsegX values are the input parameters for the CAN bitrate configuration.
These are the "real" parameters.

The tq length and bitrate are only "derived" or calculated values. These
values underlie rounding and truncation effects and are therefore less
"worth" for the description of the bitrate configuration.

Therefore its my opinion its better to have the "real" input values be
shown from where all other values can be derived.

Best regards,
    Stefan