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

["Stefan Mätje" <Stefan.Maetje@esd.eu>]

Am Freitag, den 09.07.2021, 14:17 +0200 schrieb Vincent MAILHOL:
> On Wed. 7 Jul 2021 at 18:33, Stefan Mätje <Stefan.Maetje@esd.eu> wrote:
> > Am Dienstag, den 29.06.2021, 00:44 +0900 schrieb Vincent Mailhol:
> > > 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 <mailhol.vincent@wanadoo.fr>
> > 
> > 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