From: "Ira W. Snyder" <iws@ovro.caltech.edu>
To: linux-can@vger.kernel.org
Subject: Questions about janz-ican3 and CAN_RAW_RECV_OWN_MSGS
Date: Tue, 3 Jul 2012 16:23:28 -0700 [thread overview]
Message-ID: <20120703232328.GD6616@ovro.caltech.edu> (raw)
Hello everyone,
I'm finally implementing SocketCAN support in our internal codebase, and
have run across some issues. We previously used a character driver provided
by the vendor.
I myself implemented the driver for the Janz ICAN3 card. It has been in
mainline Linux since 2.6.35.
The hardware is an SJA1000 chip plus a microcontroller and some RAM. All
messages go through the microcontroller firmware.
This firmware has the following features:
- it does have hardware-supported local loopback
- it does NOT have any sort of "tx-complete" notification or interrupt
- it does NOT have any indication that a frame went through the
hardware-supported local loopback
To work around the lack of "tx-complete" interrupts, I used the hardware
local loopback feature. Every frame has hardware loopback set, which causes
the ican3_napi() routine to be called for each frame sent. This works fine,
except that sockets created with the default options (loopback on,
can_raw_recv_own_msgs off) do receive their own messages. This seems wrong.
QUESTION 1:
The functions can_(get|put)_echo_skb() are not used at all. Is this wrong?
QUESTION 2:
The socketcan test tst-rcv-own-msgs says:
Starting PF_CAN frame flow test.
checking socket default settings ... failure!
If I understand the code correctly, this means that the sending socket
received an echo frame when it should not have received one.
This matches what I expect the code to do.
How can I fix this?
OBSERVATION 1:
The following patch drops the relevant calls to netif_stop_queue() and
netif_wake_queue(), as well as the hardware-supported local loopback.
The tst-rcv-own-msgs test passes.
Is dropping these API calls a reasonable thing to do?
Thanks,
Ira
diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
index 08c893c..b8bf972 100644
--- a/drivers/net/can/janz-ican3.c
+++ b/drivers/net/can/janz-ican3.c
@@ -845,7 +845,9 @@ static void can_frame_to_ican3(struct ican3_dev *mod,
/* we always use the extended format, with the ECHO flag set */
desc->command = ICAN3_CAN_TYPE_EFF;
desc->data[0] |= cf->can_dlc;
+#if 0
desc->data[1] |= ICAN3_ECHO;
+#endif
if (cf->can_id & CAN_RTR_FLAG)
desc->data[0] |= ICAN3_EFF_RTR;
@@ -1206,9 +1208,11 @@ static int ican3_napi(struct napi_struct *napi, int budget)
spin_lock_irqsave(&mod->lock, flags);
+#if 0
/* Wake up the transmit queue if necessary */
if (netif_queue_stopped(mod->ndev) && ican3_txok(mod))
netif_wake_queue(mod->ndev);
+#endif
spin_unlock_irqrestore(&mod->lock, flags);
@@ -1426,8 +1430,10 @@ static int ican3_xmit(struct sk_buff *skb, struct net_device *ndev)
/* check that we can actually transmit */
if (!ican3_txok(mod)) {
+#if 0
dev_err(mod->dev, "no free descriptors, stopping queue\n");
netif_stop_queue(ndev);
+#endif
spin_unlock_irqrestore(&mod->lock, flags);
return NETDEV_TX_BUSY;
}
@@ -1471,9 +1477,11 @@ static int ican3_xmit(struct sk_buff *skb, struct net_device *ndev)
* It will be woken when the ECHO skb for the current packet is recv'd.
*/
+#if 0
/* copy the control bits of the descriptor */
if (!ican3_txok(mod))
netif_stop_queue(ndev);
+#endif
spin_unlock_irqrestore(&mod->lock, flags);
return NETDEV_TX_OK;
@@ -1678,7 +1686,9 @@ static int __devinit ican3_probe(struct platform_device *pdev)
mod->free_page = DPM_FREE_START;
ndev->netdev_ops = &ican3_netdev_ops;
+#if 0
ndev->flags |= IFF_ECHO;
+#endif
SET_NETDEV_DEV(ndev, &pdev->dev);
mod->can.clock.freq = ICAN3_CAN_CLOCK;
next reply other threads:[~2012-07-03 23:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 23:23 Ira W. Snyder [this message]
2012-07-04 9:18 ` Questions about janz-ican3 and CAN_RAW_RECV_OWN_MSGS Wolfgang Grandegger
2012-07-04 12:07 ` Kurt Van Dijck
2012-07-04 16:23 ` Oliver Hartkopp
2012-07-04 19:07 ` Ira W. Snyder
2012-07-05 9:48 ` Oliver Hartkopp
2012-07-10 10:20 ` Marc Kleine-Budde
2012-07-10 19:01 ` Oliver Hartkopp
2012-07-04 16:34 ` Ira W. Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120703232328.GD6616@ovro.caltech.edu \
--to=iws@ovro.caltech.edu \
--cc=linux-can@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).