Thank you Mariusz, you've helped me understand this driver better - I
had missed some of the logic. I agree that this is a bug.
On Sat, Feb 27, 2021 at 05:03:14AM +0100, Mariusz Madej wrote:
> I changed m_can_do_rx_poll:
>
> static int m_can_do_rx_poll(struct net_device *dev, int quota)
> {
> struct m_can_classdev *cdev = netdev_priv(dev);
> u32 pkts = 0;
> u32 rxfs;
>
> rxfs = m_can_read(cdev, M_CAN_RXF0S);
> if (!(rxfs & RXFS_FFL_MASK)) {
> netdev_dbg(dev, "no messages in fifo0\n");
> return 0;
> }
>
> while ((rxfs & RXFS_FFL_MASK) && (quota > 0)) {
> if (rxfs & RXFS_RFL) {
> netdev_warn(dev, "Rx FIFO 0 Message Lost\n");
> m_can_write(cdev, M_CAN_IR, IR_RF0L);
> }
>
> m_can_read_fifo(dev, rxfs);
>
> quota--;
> pkts++;
> rxfs = m_can_read(cdev, M_CAN_RXF0S);
> }
>
> if (pkts)
> can_led_event(dev, CAN_LED_EVENT_RX);
>
> return pkts;
> }
Your fix makes sense to me. If you submit a patch to the linux-can list,
it will probably be reviewed quickly. (Don't bother to CC Dan Murphy
though, as his address listed in MAINTAINERS bounces mail.)
--
Regards,
Torin Cooper-Bennun
Software Engineer | maxiluxsystems.com
