linux-kernel - Re: [PATCH v4] can: xilinx CAN controller support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Feb 2014 14:15:27 +0100
From:	Marc Kleine-Budde <mkl@...gutronix.de>
To:	Appana Durga Kedareswara Rao <appana.durga.rao@...inx.com>,
	"wg@...ndegger.com" <wg@...ndegger.com>,
	Michal Simek <michals@...inx.com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"linux-can@...r.kernel.org" <linux-can@...r.kernel.org>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v4] can: xilinx CAN controller support.

On 02/28/2014 02:07 PM, Appana Durga Kedareswara Rao wrote:
>>>> What happens if the interrupt handler is delayed? For example in a RT
>>>> enabled system the interrupt handler runs as a thread. There might be
>>>> other threads with higher priority. The hardware will probably send
>>>> all CAN frames in the FIFO, so you want to reduce the overhead and
>>>> loop in the tx complete handler.
>>>>
>>> Yes I agree with your comment.
>>> It will be good to have a loop in the Tx interrupt handler I am
>>> modifying the Tx interrupt handler like below.
>>>
>>> static void xcan_tx_interrupt(struct net_device *ndev, u32 isr) {
>>>         struct xcan_priv *priv = netdev_priv(ndev);
>>>         struct net_device_stats *stats = &ndev->stats;
>>>
>>>         while (priv->tx_head - priv->tx_tail > 0) {
>>>                 if (!(isr & XCAN_IXR_TXOK_MASK)) {
>>>                         break;
>>>                 }
>>>                 can_get_echo_skb(ndev, priv->tx_tail %
>>>                                         priv->xcan_echo_skb_max_tx);
>>>                 priv->tx_tail++;
>>>                 stats->tx_packets++;
>>>                 can_led_event(ndev, CAN_LED_EVENT_TX);

Probably first clear the interrupt, because you've just handled it, then
check if it's still present. The question is, do you have to clear the
IRQ for each transmitted frame, or does one clean of the interrupt clear
the bit for more then one transmitted frame?

>>>                 isr = priv->read_reg(priv, XCAN_ISR_OFFSET);
>             --> clear Tx OK interrupt.

> 
>>>         }
>>>         netif_wake_queue(ndev);
>>> }
>>>
>>> Are you Ok with this?

Were getting there :)

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


Download attachment "signature.asc" of type "application/pgp-signature" (243 bytes)