On 10/19/2017 01:14 PM, Oliver Hartkopp 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
The struct can_bittiming in defined in uapi, so we have to keep ABI compatibility in mind. >>>> 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'. If the values are not board specific, then it makes no sense to put them into the DT. > One tool, one place is IMHO still the best option. 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 |
signature.asc
Description: OpenPGP digital signature
