> > On 07/27/2017 01:47 PM, Oliver Hartkopp wrote: > > On 07/26/2017 08:29 PM, Franklin S Cooper Jr wrote: > >> > > > >> I'm fine with switching to using bitrate instead of speed. Kurk was > >> originally the one that suggested to use the term arbitration and data > >> since thats how the spec refers to it. Which I do agree with. But your > >> right that in the drivers (struct can_priv) we just use bittiming and > >> data_bittiming (CAN-FD timings). I don't think adding "fd" into the > >> property name makes sense unless we are calling it something like > >> "max-canfd-bitrate" which I would agree is the easiest to understand. > >> > >> So what is the preference if we end up sticking with two properties? > >> Option 1 or 2? > >> > >> 1) > >> max-bitrate > >> max-data-bitrate > >> > >> 2) > >> max-bitrate > >> max-canfd-bitrate > >> > >> > > > > 1 > > > >>> A CAN transceiver is limited in bandwidth. But you only have one RX and > >>> one TX line between the CAN controller and the CAN transceiver. The > >>> transceiver does not know about CAN FD - it has just a physical(!) layer > >>> with a limited bandwidth. This is ONE limitation. > >>> > >>> So I tend to specify only ONE 'max-bitrate' property for the > >>> fixed-transceiver binding. > >>> > >>> The fact whether the CAN controller is CAN FD capable or not is provided > >>> by the netlink configuration interface for CAN controllers. > >> > >> Part of the reasoning to have two properties is to indicate that you > >> don't support CAN FD while limiting the "arbitration" bit rate. > > > > ?? > > > > It's a physical layer device which only has a bandwidth limitation. > > The transceiver does not know about CAN FD. > > > >> With one > >> property you can not determine this and end up having to make some > >> assumptions that can quickly end up biting people. > > > > Despite the fact that the transceiver does not know anything about ISO > > layer 2 (CAN/CAN FD) the properties should look like > > > > max-bitrate > > canfd-capable > > > > then. > > > > But when the tranceiver is 'canfd-capable' agnostic, why provide a > > property for it? > > > > Maybe I'm wrong but I still can't follow your argumentation ideas. > The transceiver does not know about CAN FD, but CAN FD uses the different restrictions of the arbitration & data phase in the CAN frame, i.e. during arbitration, the RX must indicate the wire (dominant/recessive) within 1 bit time, during data in CAN FD, this is not necessary. So while _a_ transceiver may be spec'd to 1MBit during arbitration, CAN FD packets may IMHO exceed that speed during data phase. That was the whole point of CAN FD: exceed the limits required for correct arbitration on transceiver & wire. So I do not agree on the single bandwidth limitation. The word 'max-arbitration-bitrate' makes the difference very clear. > Your right. I spoke to our CAN transceiver team and I finally get your > points. > > So yes using "max-bitrate" alone is all we need. Sorry for the confusion > and I'll create a new rev using this approach. > > > > Regards, > > Oliver Kind regards, Kurt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
