On 14.07.2023 07:26:01, Kumari Pallavi wrote:
> > On 07.07.2023 05:38:09, Kumari Pallavi wrote:
> > > > > if (netif_queue_stopped(dev) &&
> > > > > !m_can_tx_fifo_full(cdev))
> > > > > netif_wake_queue(dev);
> > > > > @@ -1787,6 +1787,7 @@ static netdev_tx_t m_can_start_xmit(struct
> > > > > sk_buff
> > > > *skb,
> > > > > }
> > > > > } else {
> > > > > cdev->tx_skb = skb;
> > > > > + m_can_write(cdev, M_CAN_IE, IR_ALL_INT & (IR_TEFN));
> > > >
> > > > - What's the purpose of "()" around IR_TEFN?
> > > > - "IR_ALL_INT & (IR_TEFN)" is equal to IR_TEFN, isn't it?
> > > > - This basically disables all other interrupts, is this what you want to
> > > > do?
> > > > - What happens if the bus is busy with high prio CAN frames and you want
> > > > to send low prio ones? You will not get any RX-IRQ, this doesn't look
> > > > correct to me.
> > > >
> > >
> > > Even though the RX interrupt is disabled (in IE), if there is an TX
> > > interrupt and the RF0N bit is set (in IR), the RX packet will still be
> > > serviced because the TX and RX share the same IRQ handler.
> >
> > If the bus is busy with high prio CAN frames and the m_can wants to send a low
> > prio frame, the m_can will not be able to send it's CAN frame, there will be not
> > TX interrupt. If there are enough high prio CAN frames the RX buffer will
> > overflow.
>
> Sorry for late reply, I agree let me see if I can try to simulate this
> scenario using CAN analyzer. I already stressed the current solution
> for more than 10 days and didn't observe any issue. However, I will
> try to incorporate this scenario for stress as well and come back.
From my point of view, this is a conceptional problem of this
workaround.
To test this issue, saturate the bus with CAN frames ID 0x0. Then on the
m_can send CAN frames with ID=0x7ff.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |