Hi, Marc Kleine-Budde wrote: > Hello > > wendy liang wrote: >> I am writing a CAN driver using the socketCAN framework. >> When there is an ACK error, the CAN hardware keeps resending the packet and >> keeps raising interrupts, which introduce too much overhead to the >> processor. > > This is a...IMHO..."weak" point of our current driver design. We don't > disable error interrupts even if they are coming at an incredible high > rate. Maybe it's time to discuss the problem again.
I agree. Bus-errors make trouble on low-end systems frequently. I initiated some discussion on this topic yesterday in another thread. I will start a dedicated thread right now. > If your driver uses NAPI the system would stay more responsive compared > to a standard interrupt handler. Have a look at e.g. the at91_can.c > which is already mainline. > > For a discussion: > A possible solution might be to switch of the error interrupt and poll > it e.g. with delayed work. > >> And thus, I want the driver to close itself when the interrupt handler >> detects there are too many error interrupts. > > That should be done from userspace....See below: > >> Is there anyway to ask the upper layer to close the driver from the driver >> itself such that the upper layer knows the driver is closed? > > We usually generate error frames and send them to the upper layes, i.e. > userspace. It's up to the application to react in an appropriate way. > Which depends on the design of your system. See: http://lxr.linux.no/#linux+v2.6.32/Documentation/networking/can.txt#L225 http://lxr.linux.no/#linux+v2.6.32/Documentation/networking/can.txt#L433 Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
