On Wed. 20 Jul. 2022 at 16:20, Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > On 19.07.2022 23:35:38, Vincent Mailhol wrote: > > This series is a collection of patches targeting the CAN error > > counter. The series is split in three blocks (with small relation to > > each other). > > > > Several drivers uses the data[6] and data[7] fields (both of type u8) > > of the CAN error frame to report those values. However, the maximum > > size an u8 can hold is 255 and the error counter can exceed this value > > if bus-off status occurs. As such, the first nine patches of this > > series make sure that no drivers try to report txerr or rxerr through > > the CAN error frame when bus-off status is reached. > > > > can_frame::data[5..7] are defined as being "controller > > specific". Controller specific behaviors are not something desirable > > (portability issue...) The tenth patch of this series specifies how > > can_frame::data[5..7] should be use and remove any "controller > > specific" freedom. The eleventh patch adds a flag to notify though > > can_frame::can_id that data[6..7] were populated (in order to be > > consistent with other fields). > > > > Finally, the twelfth and last patch add three macro values to specify > > the different error counter threshold with so far was hard-coded as > > magic numbers in the drivers. > > > > N.B.: > > * patches 1 to 10 are for net (stable). > > * patches 11 and 12 are for net-next (but depends on patches 1 to 10). > > IMHO the patches 1..10 are not so critical that they need to go upstream > via net. Especially that we're already at -rc7. I'll take all via > can-next, OK? Absolutely OK. Nothing critical here.
