Oliver Hartkopp wrote: > Marc Kleine-Budde wrote: >> Wolfgang Grandegger wrote: >>> Marc Kleine-Budde wrote: >>>> Sebastian Smolorz wrote: >>>>> Oliver Hartkopp: >>>>>> The problem is to define what a dlc > 8 provided by the CAN controller >>>>>> (which IS a BUG inside the CAN controller!) should mean to the rest of >>>>>> the data inside the registers containing the received CAN frame: >>>>>> >>>>>> - do we assume the rest to be a valid CAN frame? >>>>>> - should we drop the frame ? >>>>> The Bosch CAN specification revison 2.0 part B says that a reaction to a >>>>> DLC >>>>>> 8 is not defined but the reference CAN model defines as de-facto >>>>>> standard >>>>> the assumption that if DLC > 8 then DLC := 8. >>>> So we limit to 8 and do not drop the frame and just handle it like it's >>>> a totally valid frame with dlc == 8. >>> Yes. >>> >>>> The question remains, do we want to print out an error message or maybe >>>> a can error frame? >>> If it's allowed to happen (legal), we do *not* print an error message. >>> Otherwise it's just a source of trouble. >> okay, then the at91_can does it alright :) \o/ > > Congrats :-) > > Indeed your > > cf->can_dlc = min_t(__u8, (reg_msr >> 16) & 0xf, 8); > > looks nice.
min() is fine if the type does already match. > Wolfgang, should i update the drivers in the SVN and send a patch to netdev? Yes, of course. Please also check for useless "dlc > 8" checks in the start_xmit function. Thanks. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
