Hi Simon, On Tue, Mar 19, 2024 at 12:06:25PM +0000, Simon Horman wrote: > On Wed, Mar 13, 2024 at 11:34:31PM +0100, Francesco Valla wrote: > > Document basic concepts, APIs and behaviour of the CAN ISO-TP (ISO > > 15765-2) stack. > > > > Signed-off-by: Francesco Valla <valla.francesco@xxxxxxxxx> > > Hi Francesco, > > As it looks like there will be a v2 of this patchset > please consider running checkpatch.pl --codespell > and addressing the warnings it reports. > Will do before v2, thanks for the suggestion. > ... > > > +Transport protocol and associated frame types > > +--------------------------------------------- > > + > > +When transmitting data using the ISO-TP protocol, the payload can either fit > > +inside one single CAN message or not, also considering the overhead the protocol > > +is generating and the optional extended addressing. In the first case, the data > > +is transmitted at once using a so-called Single Frame (SF). In the second case, > > +ISO-TP defines a multi-frame protocol, in which the sender asks (through a First > > +Frame - FF) to the receiver the maximum supported size of a macro data block > > +(``blocksize``) and the minimum time time between the single CAN messages > > +composing such block (``stmin``). Once these informations have been received, > > nit: Once this information has I never grasped the usage of "information" in English, which is not my first language. I'll make this correction here. > > > +the sender starts to send frames containing fragments of the data payload > > +(called Consecutive Frames - CF), stopping after every ``blocksize``-sized block > > +to wait confirmation from the receiver (which should then send a Flow Control > > +frame - FC - to inform the sender about its availability to receive more data). > > + > > ... Thanks for the review! Regards, Francesco
