All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: can-next rebase?
Date: Mon, 14 Jan 2013 19:49:28 +0100	[thread overview]
Message-ID: <50F45338.9060301@hartkopp.net> (raw)

Hello Marc,

it looks like that my request to Dave to revert a patch failed:

http://marc.info/?t=135799864800001&r=1&w=2

To prevent the routing of CAN frames back to the originating device i wanted
to use skb->skb_iif (incoming interface index).

But skb->skb_iif is now *always* set in netif_receive_skb(), so it get's
destroyed when going down to the CAN netdev and up again :-(

As we can not used the control buffer cb[] too (net/sched qdiscs are using
the cb[] in the tx path), i was thinking about putting this information into
the skb payload (into skb headroom).

This looks like this then:

 
+struct can_skb_priv {
+	int rx_ifindex;
+	struct can_frame cf[0];
+};
+


diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 8233e5e..8233944 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -500,14 +500,21 @@ static void can_setup(struct net_device *dev)
 struct sk_buff *alloc_can_skb(struct net_device *dev, struct can_frame **cf)
 {
 	struct sk_buff *skb;
+	struct can_skb_priv *cskbp;
 
-	skb = netdev_alloc_skb(dev, sizeof(struct can_frame));
+	skb = netdev_alloc_skb(dev, sizeof(struct can_skb_priv) +
+			       sizeof(struct can_frame));
 	if (unlikely(!skb))
 		return NULL;
 
 	skb->protocol = htons(ETH_P_CAN);
 	skb->pkt_type = PACKET_BROADCAST;
 	skb->ip_summed = CHECKSUM_UNNECESSARY;
+
+	skb_reserve(skb, sizeof(struct can_skb_priv));
+	cskbp = (struct can_skb_priv *)skb->head;
+	cskbp->rx_ifindex = dev->ifindex;
+
 	*cf = (struct can_frame *)skb_put(skb, sizeof(struct can_frame));
 	memset(*cf, 0, sizeof(struct can_frame));
 

(..)
 
+	/* is sending the skb back to the incoming interface allowed? */
+	if (!(gwj->flags & CGW_FLAGS_CAN_IIF_TX_OK) &&
+	    skb_headroom(skb) == sizeof(struct can_skb_priv)) {
+		struct can_skb_priv *cskbp = (struct can_skb_priv *)skb->head;
+
+		if (cskbp->rx_ifindex == gwj->dst.dev->ifindex)
+			return;
+	}
+


All the other handling with skb->data and skb->len remains stable with this
approach.

But coming back to the mail topic:

I think i would need at least three patches for this change.

When trying to rebase linux-can-next the automatic merge fails ...

$ git rebase        
First, rewinding head to replay your work on top of it...
Applying: can: add tx/rx LED trigger support
Applying: can: flexcan: add LED trigger support
Applying: can: add tx/rx LED trigger support
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: can: flexcan: add LED trigger support
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: can: c_can: Add device tree support to Bosch C_CAN/D_CAN controller
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/can/c_can/c_can_platform.c
CONFLICT (content): Merge conflict in drivers/net/can/c_can/c_can_platform.c
Auto-merging Documentation/devicetree/bindings/net/can/c_can.txt
CONFLICT (add/add): Merge conflict in Documentation/devicetree/bindings/net/can/c_can.txt
Failed to merge in the changes.
Patch failed at 0005 can: c_can: Add device tree support to Bosch C_CAN/D_CAN controller

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".


Any idea?
 
Regards,
Oliver


             reply	other threads:[~2013-01-14 18:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-14 18:49 Oliver Hartkopp [this message]
2013-01-15  9:35 ` can-next rebase? Marc Kleine-Budde

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=50F45338.9060301@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.