Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

[Oliver Hartkopp]

On 10/19/2017 11:13 AM, Marc Kleine-Budde wrote:
> On 10/19/2017 07:07 AM, Sekhar Nori wrote:


> > > > Since we have a netlink socket interface to configure sample point, I
> > > > wonder if that should be extended to configure SSP too (or at least the
> > > > offset part of SSP)?

+1 too

> > > Sekhar is right that ideally the user should be able to set the SSP at
> > > runtime. However, my issue is that based on my experience CAN users
> > > expect the driver to just work the majority of times. For unique use
> > > cases where the driver calculated values don't work then the user should
> > > be able to override it. This should only be done for a very small
> > > percentage of CAN users. Unless you allow DT to provide a default SSP
> > > many users of MCAN may find that the default SSP doesn't work and must
> > > always use runtime overrides to get anything to work. I don't think that
> > > is a good user experience which is why I don't like the idea.
> >
> > Fair enough. But not quite sure if CAN users expect CAN-FD to "just
> > work" without doing any bittiming related setup.
>
>  From my point of view I'd rather buy a board from a HW vendor where
> CAN-FD works, rather than a board where I have to tweak the bit-timing
> for a simple CAN-FD test setup.
>
> As far as I see for the m_can driver it's a single tuple: "bitrate > 2.5
> MBit/s -> 50%". Do we need an array of tuples in general?
>
> If good default values are transceiver and board specific, they can go
> into the DT. We need a generic (this means driver agnostic) binding for
> this. If this table needs to be tweaked for special purpose, then we can
> add a netlink interface for this as well. >
> Comments?

By now we calculate reasonable default values (e.g. for SP and SJW), you 
can override by setting alternative values via netlink configuration.

I would tend to stay on this approach and not hide these things in DTs - 
just because of someone wants to initialize his specific interface 'easier'.

One tool, one place is IMHO still the best option.

Regards,
Oliver