On 06/18/2010 11:59 AM, Marc Kleine-Budde wrote: > Wolfgang Grandegger wrote: >> On 06/17/2010 08:40 PM, Marc Kleine-Budde wrote: >>> Wolfgang Grandegger wrote: >>>> On 06/17/2010 08:19 PM, Marc Kleine-Budde wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> On 06/17/2010 06:54 PM, Marc Kleine-Budde wrote: >>>>>>> Wolfgang Grandegger wrote: >>>>>>>>> Now I try to use more current version (rev 1181) of SocketCAN, >>>>>>>>> because we >>>>>>>>> need netlink CAN control API. Here I see one problem - no error >>>>>>>>> active is >>>>>>>>> indicated. The CAN_ERR_CRTL_UNSPEC error control messages are missed. >>>>>>>>> I observe this problem with both sysfs and netlink variants. >>>>>>>>> >>>>>>>>> >>>>>>>>> Is it known and wanted behavior, to not indicate CAN_ERR_CRTL_UNSPEC >>>>>>>>> any more? >>>>>>>> Yes, this is the current (known) behavior and it has been discussed >>>>>>>> before. We only report "increasing" state changes >>>>>>>> active->warning->passive->bus-off. I think it's not what we really >>>>>>>> want. >>>>>>>> It should be fixed. >>>>>>> Have a look at the statemachine in the at91_can driver[1]. I started to >>>>>>> make it more generic in order to be usable as a generic component. >>>>>>> >>>>>>> Cheers, Marc >>>>>>> >>>>>>> [1] http://lxr.linux.no/#linux+v2.6.34/drivers/net/can/at91_can.c#L757 >>>>>> I see, we don't have a #define for state changes to error active. I tend >>>>>> to rename CAN_ERR_CRTL_UNSPEC to CAN_ERR_CRTL_ACTIVE. But this needs >>>>>> some more thoughts and discussion. "CAN_ERR_CTRL" stands for controller >>>>>> *problems* and that's what we have implemented. I will have a closer >>>>>> look tomorrow. >>>>> ACK, I see the need for discussion, too. However, if your time permits, >>>>> have a look at the above mentioned state machine. Don't look to close at >>>>> the individual bits that are send in the states, they can be discussed >>>>> seperately. >>>> The AT91 driver uses CAN_ERR_PROT_ACTIVE to signal state changes to >>>> error active in a special way. I think it should be handled in a generic >>> ACK, if we've defined what to signal, it's easy to implement. >>> >>>> way like any other state change, e.g. active->warning, passive->warning, >>>> etc. We need to fix all other drivers anyway. >>> But I wass talking about the state machine in general. Does it make >>> sense to use it in other drivers aswell. >> >> A similar state machine is used for other CAN controllers as well. The >> only difference I see is setting CAN_ERR_PROT_ACTIVE if the error active >> state is entered. Have I missed something? > > yes similar, but does it make sense so implement a somewhat different > state machine in all drivers again?
We need a similar state machine for *all* drivers. Instead of handling just increasing error state changes, I would like to support *all* changes, which would make your special CAN_ERR_PROT_ACTIVE obsolete. Does that make sense, also for the real users? Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
