Hello,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
...
Attached is the patch and it works fine. The key function
rtcan_sja_enable_bus_err() is called from sendmsg():
void rtcan_sja_enable_bus_err(struct rtcan_device *dev)
{
struct rtcan_sja1000 *chip = (struct rtcan_sja1000 *)dev->priv;
if (chip->bus_err_on < 2) {
if (chip->bus_err_on < 1)
chip->read_reg(dev, SJA_ECC);
chip->bus_err_on = 2;
}
}
And I do also do not see a real problem with multiple readers. I would
commit this solution. I'm just unsure if we should select it silently or
if the user should have the choice.
I would say no to user-selectability unless someone comes up with a
serious downside of this approach.
Are there any other error interrupt sources we should treat the same
way? Or all? Just to make the behaviour as regular as reasonable. I have
no opinion yet, I only want to make sure we have considered this as well
before we set the change API in stone.
Nice work!
OK, I have just commited the following changes:
2007-04-02 Wolfgang Grandegger <[EMAIL PROTECTED]>
* ksrc/drivers/can/*: The option CONFIG_XENO_DRIVERS_CAN_BUS_ERR now
enables bus error interrupts when an application is calling a receive
function on a socket listening on bus errors. After one bus error has
occured, the interrupt will be disabled to allow the application time
for error processing and to efficiently avoid bus error interrupt
flooding. This option is automatically selected for CAN controllers
supporting bus error interrupts like the SJA1000.
* include/rtdm/rtcan.h: Add some doc on bus-off and bus-error error
conditions and the restart policy.
* src/utils/can/rtcanconfig.c: Controller mode settings and doc
has been corrected.
Wolfgang.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
