On Fri, Feb 05, 2010 at 11:44:42AM +0100, Wolfgang Grandegger wrote:
>
> Oliver Hartkopp wrote:
> > christian pellegrin wrote:
> >> On Fri, Feb 5, 2010 at 10:05 AM, Kurt Van Dijck <[email protected]>
> >> wrote:
> >>
> >>> I never enabled the bus-error interrupts anywhere embedded.
> >>> To research odd behaviour, the error counters were helpfull,
> >> I like this idea much. I speak from a point of view of meanness ;-) :
> >> we have paid the chip manufacturer for the REC and TEC counters that
> >> are cleverly incremented and decremented (AFAIK it's more likely they
> >> are incremented that decremented, so there is always a window in which
> >> the user space application can catch an increase in them even if not
> >> polling at an excessive rate) by the controller itself so they could
> >> be easily exported to user space. Perhaps all we need is a function
> >> for this in can_priv such do_get_err_counters. Even better if these
> >> counters are exported via sysfs so the function above is guaranteed to
> >> be called in non-atomic context.
> >>
> >
> > Trying to summarize these points, what about this:
> >
> > 1. We disable bus-error interrupts by default
>
> Fine for me, even if that changes the current behavior.
Ack
>
> > 2. They can be enabled via netlink
>
> Yep.
Ack
>
> > 3. Once they are enabled we send the (unified) rx/tx error counters inside
> > the
> > currently reserved bytes of the CAN error frame to the userspace.
>
> The problem is that some CAN controllers do not allow to read these
> counters while it's active. But in general we could add the rx/txerr to
> any error message, if possible. The information in the error message is
> hardware dependent anyway.
Ack
>
> > Would this meet the requirements in production-use and development-use ??
Yes, for me, this would meet the requirements.
>
> I leave it up to the real users. It's obvious that bus-error inspection
> is most useful for analyzing hardware problems during the development
> and testing phase.
>
> Wolfgang.
Kurt
>
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users
