* Re: [PATCH] bfin_mac: remove deprecated IRQF_DISABLED
From: Jingoo Han @ 2013-09-12 8:09 UTC (permalink / raw)
To: 'Michael Opdenacker', davem
Cc: richardcochran, jiri, mugunthanvnm, uclinux-dist-devel, netdev,
linux-kernel
In-Reply-To: <1378956943-3470-1-git-send-email-michael.opdenacker@free-electrons.com>
On Thursday, September 12, 2013 12:36 PM, Michael Opdenacker wrote:
>
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/adi/bfin_mac.c.
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
> ---
> drivers/net/ethernet/adi/bfin_mac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH net 2/4] bridge: Handle priority-tagged frames properly
From: Toshiaki Makita @ 2013-09-12 8:08 UTC (permalink / raw)
To: vyasevic
Cc: David S. Miller, netdev, Fernando Luis Vazquez Cao,
Patrick McHardy
In-Reply-To: <52309B01.4060607@redhat.com>
On Wed, 2013-09-11 at 12:32 -0400, Vlad Yasevich wrote:
> On 09/11/2013 03:00 AM, Toshiaki Makita wrote:
> > On Tue, 2013-09-10 at 10:03 -0400, Vlad Yasevich wrote:
> >> On 09/10/2013 06:34 AM, Toshiaki Makita wrote:
> >>> IEEE 802.1Q says that when we receive priority-tagged (VID 0) frames
> >>> use the PVID for the port as its VID.
> >>> (See IEEE 802.1Q-2005 6.7.1 and Table 9-2)
> >>>
> >>> Apply the PVID to not only untagged frames but also priority-tagged frames.
> >>>
> >>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>> ---
> >>> net/bridge/br_vlan.c | 27 ++++++++++++++++++++-------
> >>> 1 file changed, 20 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> >>> index 21b6d21..5a9c44a 100644
> >>> --- a/net/bridge/br_vlan.c
> >>> +++ b/net/bridge/br_vlan.c
> >>> @@ -189,6 +189,8 @@ out:
> >>> bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> >>> struct sk_buff *skb, u16 *vid)
> >>> {
> >>> + int err;
> >>> +
> >>> /* If VLAN filtering is disabled on the bridge, all packets are
> >>> * permitted.
> >>> */
> >>> @@ -201,20 +203,31 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> >>> if (!v)
> >>> return false;
> >>>
> >>> - if (br_vlan_get_tag(skb, vid)) {
> >>> + err = br_vlan_get_tag(skb, vid);
> >>> + if (!*vid) {
> >>> u16 pvid = br_get_pvid(v);
> >>>
> >>> - /* Frame did not have a tag. See if pvid is set
> >>> - * on this port. That tells us which vlan untagged
> >>> - * traffic belongs to.
> >>> + /* Frame had a tag with VID 0 or did not have a tag.
> >>> + * See if pvid is set on this port. That tells us which
> >>> + * vlan untagged or priority-tagged traffic belongs to.
> >>> */
> >>> if (pvid == VLAN_N_VID)
> >>> return false;
> >>>
> >>> - /* PVID is set on this port. Any untagged ingress
> >>> - * frame is considered to belong to this vlan.
> >>> + /* PVID is set on this port. Any untagged or priority-tagged
> >>> + * ingress frame is considered to belong to this vlan.
> >>> */
> >>> - __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> >>> + if (likely(err))
> >>> + /* Untagged Frame. */
> >>> + __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> >>> + else
> >>> + /* Priority-tagged Frame.
> >>> + * At this point, We know that skb->vlan_tci had
> >>> + * VLAN_TAG_PRESENT bit and its VID field was 0x000.
> >>> + * We update only VID field and preserve PCP field.
> >>> + */
> >>> + skb->vlan_tci |= pvid;
> >>> +
> >>
> >> In the case of a priority tagged frame, we should unroll the
> >> modification above and restore the VID field to 0. Otherwise, you
> >> may end up either stripping the vlan header completely or forwarding
> >> with pvid of the ingress port.
> >
> > Thank you for reviewing.
> >
> > It is my intended behavior that an incoming priority-tagged frame is
> > forwarded as a frame untagged or tagged with pvid.
> >
> > IEEE 802.1Q-2011:
> >
> > section 8.1.7 Conversion of frame formats
> >
> > NOTE - As all incoming frames, including priority-tagged frames, are
> > classified as belonging to a VLAN, the transmitting Port transmits
> > VLAN-tagged frames or untagged frames. Hence, a station sending a
> > priority-tagged frame via a Bridge will receive a response that is
> > either VLAN-tagged or untagged, as described in 8.5.
> >
> > 3. Definitions
> >
> > 3.132 Priority-tagged frame: A tagged frame whose tag header carries
> > priority information but carries no VLAN identification information.
> >
> > 3.203 VLAN-tagged frame: A VLAN-tagged frame is a tagged frame whose
> > tag header carries *both* VLAN identification and priority
> > information.
> >
> > Toshiaki Makita
> >
>
> Hmm.. The problem is that if a system attached to a port configures a
> vlan interface with vid 0 and some priority mappings, then that
> interface will not be able to properly receive traffic, as the bridge
> now will never transmit priority tagged frames.
>
> -vlad
I see. As you say, for example, if we configure vnet0.0 and attach
vnet0 to a bridge with vlan_filtering enabled, even though we are
sending priority-tagged frames from vnet0.0 and they are successfully
forwarded by the bridge to another port, we cannot receive any frame on
vnet0.0 because all incoming frames from a bridge port are not
priority-tagged and never passed to vnet0.0.
I think this might be a problem as an end station that cannot receive
incoming untagged frames and priority-tagged frames on the same
interface when vlan 0 interface is defined.
(We can receive both untagged and priority-tagged frames on the same
interface that is not configured vlan 0.)
If we assume it as a problem of vlan interface, I guess we should enable
vlan 0 interface to receive untagged frames (treat vnet0.0 as an alias
of vnet0), or add a setting of egress priority map to vnet0 so that vlan
0 interface can become unnecessary.
If it is preferable to deal with it by bridge, I don't think a
priority-tagged frame's VID field should be restored to 0 on the egress
port. If we do so, we may receive both untagged frames and
priority-tagged frames from a bridge port when another end station sends
both untagged and priority-tagged frames by mixture.
IMO, it will be resolved by adding a new per-port policy that enables us
to send priority-tagged frames instead of untagged frames, like the
"priority-tags" option of openvswitch.
This solution, however, makes the bridge not be conformed with IEEE
802.1Q, and the problem remains that we cannot receive any frames on a
vlan 0 interface such as eth0.0 when we connect eth0 to another 802.1Q
conformed switch.
I'd like to hear further comments or suggestions, everyone :)
Thanks,
Toshiaki Makita
>
> >>
> >> -vlad
> >>> return true;
> >>> }
> >>>
> >>>
> >
> >
^ permalink raw reply
* RE: [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses
From: David Laight @ 2013-09-12 8:06 UTC (permalink / raw)
To: Al Viro, Joe Perches
Cc: Tetsuo Handa, linux-kernel, kosaki.motohiro, keescook, fweisbec,
dan.carpenter, devel, gregkh, tushar.behera, lidza.louina, davem,
kuznet, jmorris, yoshfuji, kaber, courmisch, vyasevich, nhorman,
netdev, linux-sctp
In-Reply-To: <20130912001911.GO13318@ZenIV.linux.org.uk>
> On Wed, Sep 11, 2013 at 05:04:17PM -0700, Joe Perches wrote:
> > On Thu, 2013-09-12 at 08:40 +0900, Tetsuo Handa wrote:
> > > Joe Perches wrote:
> > > > - seq_printf(m, "%s%d%n", con->name, con->index, &len);
> > > > + len = seq_printf(m, "%s%d", con->name, con->index);
> > >
> > > Isn't len always 0 or -1 ?
> >
> > Right. Well you're no fun...
> >
> > These uses would seem broken anyway because the
> > seq_printf isn't itself tested for correctness.
> >
> > Hmm.
> >
> > Also, there's a large amount of code that appears
> > to do calculations with pos or len like:
> >
> > pos += seq_printf(handle, fmt. ...)
>
> ... and most of that code proceeds to ignore pos completely.
> Note that ->show() is *NOT* supposed to return the number of
> characters it has/would like to have produced. Just return
> 0 and be done with that; overflows are dealt with just fine.
> The large amount, BTW, is below 100 lines, AFAICS, in rather
> few files.
>
> > There are very few that seem to use it correctly
> > like netfilter.
>
> > Suggestions?
Change the return type of seq_printf() to void and require that
code use access functions/macros to find the length and error
status. Possibly save the length of the last call separately.
David
^ permalink raw reply
* Re: [PATCH 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-12 7:54 UTC (permalink / raw)
To: 'David Miller'; +Cc: sergei.shtylyov, netdev, 'Jingoo Han'
In-Reply-To: <20130912.033606.1689936899104585741.davem@davemloft.net>
On Thursday, September 12, 2013 4:36 PM, David Miller wrote:
> On Thu, 12 Sep 2013 14:49:56 +0900, Jingoo Han wrote:
> > On Thursday, September 12, 2013 2:25 PM, David Miller wrote:
> >> On Thu, 12 Sep 2013 09:11:01 +0900, Jingoo Han wrote:
> >> > Would you let know the reason not to add coding style fixes?
> >>
> >> They should be made seperately so that the individual changes
> >> can be reviewed more easily and without unnecessary unrelated
> >> changes mixed in.
> >
> > OK, I see. :-)
> > Thank you for your answer.
> > Then, I will send V2 patch soon.
>
> Please do not submit such a huge patch series in the future.
>
> Anything more than 16 patches at a time is not reasonable and
> overloads reviewer's capacity to look at your changes.
>
Then, in this case,
I have to split the patches into several chunks, and send them
over few weeks?
For example,
one day: 15 patches
2 weeks later: 15 patches
2 weeks later: 15 patches
2 weeks later: 7 patches
Best regards,
Jingoo Han
^ permalink raw reply
* Re: pull request: wireless 2013-09-10
From: David Miller @ 2013-09-12 7:53 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130910193845.GD1960@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 10 Sep 2013 15:38:45 -0400
> This is a pull request for a few early fixes for the 3.12 stream.
Looks good, pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: David Miller @ 2013-09-12 7:36 UTC (permalink / raw)
To: jg1.han; +Cc: sergei.shtylyov, netdev
In-Reply-To: <000601ceaf7b$e8e7b2e0$bab718a0$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Thu, 12 Sep 2013 14:49:56 +0900
> On Thursday, September 12, 2013 2:25 PM, David Miller wrote:
>> On Thu, 12 Sep 2013 09:11:01 +0900, Jingoo Han wrote:
>> > Would you let know the reason not to add coding style fixes?
>>
>> They should be made seperately so that the individual changes
>> can be reviewed more easily and without unnecessary unrelated
>> changes mixed in.
>
> OK, I see. :-)
> Thank you for your answer.
> Then, I will send V2 patch soon.
Please do not submit such a huge patch series in the future.
Anything more than 16 patches at a time is not reasonable and
overloads reviewer's capacity to look at your changes.
Thank you.
^ permalink raw reply
* Re: [Patch iproute2] vxlan: add ipv6 support
From: Cong Wang @ 2013-09-12 7:16 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Stephen Hemminger
In-Reply-To: <1378179210-1170-1-git-send-email-amwang@redhat.com>
On Tue, 2013-09-03 at 11:33 +0800, Cong Wang wrote:
> From: Cong Wang <amwang@redhat.com>
>
> The kernel already supports it, so add the support
> to iproute2 as well.
>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Cong Wang <amwang@redhat.com>
Stephen, could you take it if it looks good to you?
Thanks!
^ permalink raw reply
* bridge: Clamp forward_delay when enabling STP
From: Herbert Xu @ 2013-09-12 7:12 UTC (permalink / raw)
To: David S. Miller, Stephen Hemminger, netdev
At some point limits were added to forward_delay. However, the
limits are only enforced when STP is enabled. This created a
scenario where you could have a value outside the allowed range
while STP is disabled, which then stuck around even after STP
is enabled.
This patch fixes this by clamping the value when we enable STP.
I had to move the locking around a bit to ensure that there is
no window where someone could insert a value outside the range
while we're in the middle of enabling STP.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 598cb0b..cda8315 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -746,6 +746,7 @@ extern struct net_bridge_port *br_get_port(struct net_bridge *br,
extern void br_init_port(struct net_bridge_port *p);
extern void br_become_designated_port(struct net_bridge_port *p);
+extern void __br_set_forward_delay(struct net_bridge *br, unsigned long t);
extern int br_set_forward_delay(struct net_bridge *br, unsigned long x);
extern int br_set_hello_time(struct net_bridge *br, unsigned long x);
extern int br_set_max_age(struct net_bridge *br, unsigned long x);
diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index 1c0a50f..e651211 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
@@ -544,18 +544,27 @@ int br_set_max_age(struct net_bridge *br, unsigned long val)
}
+void __br_set_forward_delay(struct net_bridge *br, unsigned long t)
+{
+ br->bridge_forward_delay = t;
+ if (br_is_root_bridge(br))
+ br->forward_delay = br->bridge_forward_delay;
+}
+
int br_set_forward_delay(struct net_bridge *br, unsigned long val)
{
unsigned long t = clock_t_to_jiffies(val);
+ int err = -ERANGE;
+ spin_lock_bh(&br->lock);
if (br->stp_enabled != BR_NO_STP &&
(t < BR_MIN_FORWARD_DELAY || t > BR_MAX_FORWARD_DELAY))
- return -ERANGE;
+ goto unlock;
- spin_lock_bh(&br->lock);
- br->bridge_forward_delay = t;
- if (br_is_root_bridge(br))
- br->forward_delay = br->bridge_forward_delay;
+ __br_set_forward_delay(br, t);
+ err = 0;
+
+unlock:
spin_unlock_bh(&br->lock);
- return 0;
+ return err;
}
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index d45e760..108084a 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -129,6 +129,14 @@ static void br_stp_start(struct net_bridge *br)
char *envp[] = { NULL };
r = call_usermodehelper(BR_STP_PROG, argv, envp, UMH_WAIT_PROC);
+
+ spin_lock_bh(&br->lock);
+
+ if (br->bridge_forward_delay < BR_MIN_FORWARD_DELAY)
+ __br_set_forward_delay(br, BR_MIN_FORWARD_DELAY);
+ else if (br->bridge_forward_delay < BR_MAX_FORWARD_DELAY)
+ __br_set_forward_delay(br, BR_MAX_FORWARD_DELAY);
+
if (r == 0) {
br->stp_enabled = BR_USER_STP;
br_debug(br, "userspace STP started\n");
@@ -137,10 +145,10 @@ static void br_stp_start(struct net_bridge *br)
br_debug(br, "using kernel STP\n");
/* To start timers on any ports left in blocking */
- spin_lock_bh(&br->lock);
br_port_state_selection(br);
- spin_unlock_bh(&br->lock);
}
+
+ spin_unlock_bh(&br->lock);
}
static void br_stp_stop(struct net_bridge *br)
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [PATCH 2/2] net: emaclite: Code cleanup
From: Michal Simek @ 2013-09-12 7:05 UTC (permalink / raw)
To: netdev
Cc: Michal Simek, David S. Miller, Jens Renner, Libo Chen,
Greg Kroah-Hartman, linux-kernel
In-Reply-To: <196d8368eee2d45eeeab40e96e2971f78ed8a79b.1378969499.git.michal.simek@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 3106 bytes --]
No function changes (s/\ \t/\t/g)
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 28 +++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index de39098..80dd404 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -31,7 +31,7 @@
#define DRIVER_NAME "xilinx_emaclite"
/* Register offsets for the EmacLite Core */
-#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */
+#define XEL_TXBUFF_OFFSET 0x0 /* Transmit Buffer */
#define XEL_MDIOADDR_OFFSET 0x07E4 /* MDIO Address Register */
#define XEL_MDIOWR_OFFSET 0x07E8 /* MDIO Write Data Register */
#define XEL_MDIORD_OFFSET 0x07EC /* MDIO Read Data Register */
@@ -63,13 +63,13 @@
#define XEL_MDIOCTRL_MDIOEN_MASK 0x00000008 /* MDIO Enable */
/* Global Interrupt Enable Register (GIER) Bit Masks */
-#define XEL_GIER_GIE_MASK 0x80000000 /* Global Enable */
+#define XEL_GIER_GIE_MASK 0x80000000 /* Global Enable */
/* Transmit Status Register (TSR) Bit Masks */
-#define XEL_TSR_XMIT_BUSY_MASK 0x00000001 /* Tx complete */
-#define XEL_TSR_PROGRAM_MASK 0x00000002 /* Program the MAC address */
-#define XEL_TSR_XMIT_IE_MASK 0x00000008 /* Tx interrupt enable bit */
-#define XEL_TSR_XMIT_ACTIVE_MASK 0x80000000 /* Buffer is active, SW bit
+#define XEL_TSR_XMIT_BUSY_MASK 0x00000001 /* Tx complete */
+#define XEL_TSR_PROGRAM_MASK 0x00000002 /* Program the MAC address */
+#define XEL_TSR_XMIT_IE_MASK 0x00000008 /* Tx interrupt enable bit */
+#define XEL_TSR_XMIT_ACTIVE_MASK 0x80000000 /* Buffer is active, SW bit
* only. This is not documented
* in the HW spec */
@@ -77,21 +77,21 @@
#define XEL_TSR_PROG_MAC_ADDR (XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_PROGRAM_MASK)
/* Receive Status Register (RSR) */
-#define XEL_RSR_RECV_DONE_MASK 0x00000001 /* Rx complete */
-#define XEL_RSR_RECV_IE_MASK 0x00000008 /* Rx interrupt enable bit */
+#define XEL_RSR_RECV_DONE_MASK 0x00000001 /* Rx complete */
+#define XEL_RSR_RECV_IE_MASK 0x00000008 /* Rx interrupt enable bit */
/* Transmit Packet Length Register (TPLR) */
-#define XEL_TPLR_LENGTH_MASK 0x0000FFFF /* Tx packet length */
+#define XEL_TPLR_LENGTH_MASK 0x0000FFFF /* Tx packet length */
/* Receive Packet Length Register (RPLR) */
-#define XEL_RPLR_LENGTH_MASK 0x0000FFFF /* Rx packet length */
+#define XEL_RPLR_LENGTH_MASK 0x0000FFFF /* Rx packet length */
-#define XEL_HEADER_OFFSET 12 /* Offset to length field */
-#define XEL_HEADER_SHIFT 16 /* Shift value for length */
+#define XEL_HEADER_OFFSET 12 /* Offset to length field */
+#define XEL_HEADER_SHIFT 16 /* Shift value for length */
/* General Ethernet Definitions */
-#define XEL_ARP_PACKET_SIZE 28 /* Max ARP packet size */
-#define XEL_HEADER_IP_LENGTH_OFFSET 16 /* IP Length Offset */
+#define XEL_ARP_PACKET_SIZE 28 /* Max ARP packet size */
+#define XEL_HEADER_IP_LENGTH_OFFSET 16 /* IP Length Offset */
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* [PATCH 1/2] net: emaclite: Not necessary to call devm_iounmap
From: Michal Simek @ 2013-09-12 7:05 UTC (permalink / raw)
To: netdev
Cc: Michal Simek, David S. Miller, Jens Renner, Libo Chen,
Greg Kroah-Hartman, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]
devm_iounmap is called automatically.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/net/ethernet/xilinx/xilinx_emaclite.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 4c619ea..de39098 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1075,14 +1075,9 @@ static int xemaclite_send(struct sk_buff *orig_skb, struct net_device *dev)
* This function un maps the IO region of the Emaclite device and frees the net
* device.
*/
-static void xemaclite_remove_ndev(struct net_device *ndev,
- struct platform_device *pdev)
+static void xemaclite_remove_ndev(struct net_device *ndev)
{
if (ndev) {
- struct net_local *lp = netdev_priv(ndev);
-
- if (lp->base_addr)
- devm_iounmap(&pdev->dev, lp->base_addr);
free_netdev(ndev);
}
}
@@ -1214,7 +1209,7 @@ static int xemaclite_of_probe(struct platform_device *ofdev)
return 0;
error:
- xemaclite_remove_ndev(ndev, ofdev);
+ xemaclite_remove_ndev(ndev);
return rc;
}
@@ -1248,7 +1243,7 @@ static int xemaclite_of_remove(struct platform_device *of_dev)
of_node_put(lp->phy_node);
lp->phy_node = NULL;
- xemaclite_remove_ndev(ndev, of_dev);
+ xemaclite_remove_ndev(ndev);
return 0;
}
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH net 1/1] r8169: enforce RX_MULTI_EN for the 8168f.
From: David Miller @ 2013-09-12 6:40 UTC (permalink / raw)
To: romieu; +Cc: dborkman, netdev, david, fredo, hayeswang
In-Reply-To: <20130911231543.GA29725@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 12 Sep 2013 01:15:43 +0200
> David Miller <davem@davemloft.net> :
> [...]
>> Francois, if you reply to this thread with your signoff, all will
>> be well and I will apply this.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
>
> I slowly built an AMD IOMMU + 8168{e/f} problem report pattern but
> the picture got blurred:
> - Hayes has not heard of anything like this
> - the oracle suggests it could be an "AMD IOMMU + whatever" problem
> - "iommu=pt" seems quite effective (hardly surprizing :o/ )
>
> I still have a pile of iommu mailing-list messages to search through.
> Let aside the AMD-Vi error log message, I haven't done a thorough analysis.
>
> It's lame.
Understood. There were always IOMMU chips that sometimes prefetch one
cacheline too far (and thus potentially to the next page, which is
potentially unmapped) in certain circumstances. Maybe these settings
trigger that kind of thing.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: sk_buff: memset(skb,0) after alloc in skb_clone
From: Govindarajulu Varadarajan @ 2013-09-12 6:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Govindarajulu Varadarajan, davem, netdev
In-Reply-To: <1378816832.26319.75.camel@edumazet-glaptop>
On Tue, 10 Sep 2013, Eric Dumazet wrote:
> On Tue, 2013-09-10 at 10:18 +0530, Govindarajulu Varadarajan wrote:
>> The following patch memset the skb to 0 after alloc. We do this in
>> __alloc_skb_head, __alloc_skb, build_skb. We are missing this in
>> skb_clone.
>>
>> The following call to __skb_clone in skb_clone does not copy all the
>> members of sk_buff. If we donot clear the skb to 0, we will have some
>> uninitialized members in new skb.
>
> Which ones exactly ?
>
> I would rather make sure all fields are properly copied.
>
> Your patch is incomplete, because it doesn't handle the fast clone case.
Sorry, my bad. Didnt check the __copy_skb_header completely.
thanks
//govind
^ permalink raw reply
* Re: [PATCH] net: tulip: remove deprecated IRQF_DISABLED
From: Grant Grundler @ 2013-09-12 6:05 UTC (permalink / raw)
To: Michael Opdenacker
Cc: Grant Grundler, open list:TULIP NETWORK DRI..., open list
In-Reply-To: <1378959624-4123-1-git-send-email-michael.opdenacker@free-electrons.com>
On Wed, Sep 11, 2013 at 9:20 PM, Michael Opdenacker
<michael.opdenacker@free-electrons.com> wrote:
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/dec/tulip/de4x5.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
yup - that was easy to confirm.
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
thanks,
grant
> ---
> drivers/net/ethernet/dec/tulip/de4x5.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
> index 2db6c57..263b92c 100644
> --- a/drivers/net/ethernet/dec/tulip/de4x5.c
> +++ b/drivers/net/ethernet/dec/tulip/de4x5.c
> @@ -1321,7 +1321,7 @@ de4x5_open(struct net_device *dev)
> if (request_irq(dev->irq, de4x5_interrupt, IRQF_SHARED,
> lp->adapter_name, dev)) {
> printk("de4x5_open(): Requested IRQ%d is busy - attemping FAST/SHARE...", dev->irq);
> - if (request_irq(dev->irq, de4x5_interrupt, IRQF_DISABLED | IRQF_SHARED,
> + if (request_irq(dev->irq, de4x5_interrupt, IRQF_SHARED,
> lp->adapter_name, dev)) {
> printk("\n Cannot get IRQ- reconfigure your hardware.\n");
> disable_ast(dev);
> --
> 1.8.1.2
>
^ permalink raw reply
* [PATCH V2 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-12 5:57 UTC (permalink / raw)
To: 'David S. Miller'
Cc: netdev, 'Jingoo Han', 'Sergei Shtylyov'
In-Reply-To: <005e01ceaec2$23e32420$6ba96c60$%han@samsung.com>
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
Changes since v1:
- removed coding style fix.
drivers/net/ethernet/fealnx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/fealnx.c b/drivers/net/ethernet/fealnx.c
index c706b7a..4b22a95 100644
--- a/drivers/net/ethernet/fealnx.c
+++ b/drivers/net/ethernet/fealnx.c
@@ -699,7 +699,6 @@ static void fealnx_remove_one(struct pci_dev *pdev)
pci_iounmap(pdev, np->mem);
free_netdev(dev);
pci_release_regions(pdev);
- pci_set_drvdata(pdev, NULL);
} else
printk(KERN_ERR "fealnx: remove for unknown device\n");
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2013-09-12 5:49 UTC (permalink / raw)
To: 'David Miller'; +Cc: sergei.shtylyov, netdev, 'Jingoo Han'
In-Reply-To: <20130912.012443.2294235053428746280.davem@davemloft.net>
On Thursday, September 12, 2013 2:25 PM, David Miller wrote:
> On Thu, 12 Sep 2013 09:11:01 +0900, Jingoo Han wrote:
> > Would you let know the reason not to add coding style fixes?
>
> They should be made seperately so that the individual changes
> can be reviewed more easily and without unnecessary unrelated
> changes mixed in.
OK, I see. :-)
Thank you for your answer.
Then, I will send V2 patch soon.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH 20/52] net: fealnx: remove unnecessary pci_set_drvdata()
From: David Miller @ 2013-09-12 5:24 UTC (permalink / raw)
To: jg1.han; +Cc: sergei.shtylyov, netdev
In-Reply-To: <000e01ceaf4c$90cde130$b269a390$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Thu, 12 Sep 2013 09:11:01 +0900
> Would you let know the reason not to add coding style fixes?
They should be made seperately so that the individual changes
can be reviewed more easily and without unnecessary unrelated
changes mixed in.
^ permalink raw reply
* [PATCH 1/1] resubmit bridge: fix message_age_timer calculation
From: Chris Healy @ 2013-09-12 4:37 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller; +Cc: bridge, netdev, buytenh, Chris Healy
This changes the message_age_timer calculation to use the BPDU's max age as
opposed to the local bridge's max age. This is in accordance with section
8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification.
With the current implementation, when running with very large bridge
diameters, convergance will not always occur even if a root bridge is
configured to have a longer max age.
Tested successfully on bridge diameters of ~200.
Signed-off-by: Chris Healy <cphealy@gmail.com>
---
net/bridge/br_stp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
index 1c0a50f..f1887ba 100644
--- a/net/bridge/br_stp.c
+++ b/net/bridge/br_stp.c
@@ -209,7 +209,7 @@ static void br_record_config_information(struct net_bridge_port *p,
p->designated_age = jiffies - bpdu->message_age;
mod_timer(&p->message_age_timer, jiffies
- + (p->br->max_age - bpdu->message_age));
+ + (bpdu->max_age - bpdu->message_age));
}
/* called under bridge lock */
--
1.8.1.2
^ permalink raw reply related
* XGMII support
From: Rayagond K @ 2013-09-12 4:30 UTC (permalink / raw)
To: netdev
Hi All,
I was going through include/linux/phy.h file to check what all phy
interface Linux supports. The enum "phy_interface_t" has entry for
MII, GMII, TBI, SGMII, RMII etc but I didn't find entry for XGMII
interface. So my questions are following,
1. How to support XGMII using phylib ?
2. What are PHY_INTERFACE_MODE_RGMII_ID, PHY_INTERFACE_MODE_RGMII_RXID
and PHY_INTERFACE_MODE_RGMII_TXID ?
wwr
Rayagond
^ permalink raw reply
* [PATCH] net: tulip: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-12 4:20 UTC (permalink / raw)
To: grundler; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/dec/tulip/de4x5.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/dec/tulip/de4x5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
index 2db6c57..263b92c 100644
--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -1321,7 +1321,7 @@ de4x5_open(struct net_device *dev)
if (request_irq(dev->irq, de4x5_interrupt, IRQF_SHARED,
lp->adapter_name, dev)) {
printk("de4x5_open(): Requested IRQ%d is busy - attemping FAST/SHARE...", dev->irq);
- if (request_irq(dev->irq, de4x5_interrupt, IRQF_DISABLED | IRQF_SHARED,
+ if (request_irq(dev->irq, de4x5_interrupt, IRQF_SHARED,
lp->adapter_name, dev)) {
printk("\n Cannot get IRQ- reconfigure your hardware.\n");
disable_ast(dev);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
From: Greg KH @ 2013-09-12 4:17 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Tejun Heo, linux-kernel, kay, netdev, lizefan
In-Reply-To: <87eh8u4slj.fsf@xmission.com>
On Wed, Sep 11, 2013 at 08:38:32PM -0700, Eric W. Biederman wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
>
> > On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote:
> >> Hello,
> >>
> >> I'll send out multiple patchsets to separate out sysfs from driver
> >> core and kobject. The eventual goal is making sysfs modular enough so
> >> that cgroup can replace its nightmarish cgroupfs implementation which
> >> repeated and worsened all the past mistakes of sysfs. This patchset
> >> is first of the effort and separates out kobject namespace handling
> >> from sysfs.
> >>
> >> I never really understood why namespace support was added the way it
> >> was added.
> >
> > I just took the patches and didn't ask questions :)
>
> Greg you don't get to play dumb you asked questions and required most of
> the current strucuture of the code.
I did? Ok, I'll buy that, but please review this code for what it is,
nice cleanups and a sanity-check for the ns support in sysfs. It saves
100+ lines of code, what's wrong with that?
> The code is convoluted by your request.
I really asked for the existing callback chain to look like that? I did
want ns to be "minimal" in sysfs as I didn't think it was going to be a
good idea, and hoped it would go away. Much like all other kernel
maintainers did for cgroups. Turns out, we were wrong, and now Tejun is
stepping up and fixing it.
So, if I asked for this before, I apologize, I was wrong. Just like I
was wrong about containers and cgroups, and I'll probably be wrong about
something else in the future.
greg k-h
^ permalink raw reply
* [PATCH] ethernet: amd: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-12 3:52 UTC (permalink / raw)
To: davem
Cc: rusty, benh, silviupopescu1990, geert, netdev, linux-kernel,
Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/amd/sun3lance.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/amd/sun3lance.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/sun3lance.c b/drivers/net/ethernet/amd/sun3lance.c
index d6b2029..3d8c6b2 100644
--- a/drivers/net/ethernet/amd/sun3lance.c
+++ b/drivers/net/ethernet/amd/sun3lance.c
@@ -358,7 +358,7 @@ static int __init lance_probe( struct net_device *dev)
REGA(CSR0) = CSR0_STOP;
- if (request_irq(LANCE_IRQ, lance_interrupt, IRQF_DISABLED, "SUN3 Lance", dev) < 0) {
+ if (request_irq(LANCE_IRQ, lance_interrupt, 0, "SUN3 Lance", dev) < 0) {
#ifdef CONFIG_SUN3
iounmap((void __iomem *)ioaddr);
#endif
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 7/7] sysfs: @name comes before @ns
From: Tejun Heo @ 2013-09-12 3:49 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: gregkh, linux-kernel, kay, netdev, lizefan
In-Reply-To: <87a9ji4sk0.fsf@xmission.com>
Hello, Eric.
On Wed, Sep 11, 2013 at 08:39:27PM -0700, Eric W. Biederman wrote:
> @ns is more significant so it should come first.
>
> Where do we have the backwards convention of putting @name first?
Because @ns is optional and you end up with stupid stuff like
sysfs_xxx_ns(@param, @ns, @name)
sysfs_xxx(@param, @name)
You put optional params after the mandatory ones. It may be difficult
to accept for you but @ns is a *clearly* optional thing for sysfs.
--
tejun
^ permalink raw reply
* Re: [PATCHSET] sysfs: disentangle kobject namespace handling from sysfs
From: Tejun Heo @ 2013-09-12 3:47 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: gregkh, linux-kernel, kay, netdev, lizefan
In-Reply-To: <87li324sng.fsf@xmission.com>
On Wed, Sep 11, 2013 at 08:37:23PM -0700, Eric W. Biederman wrote:
> At a practical level you probably just want to copy the good parts of
> the structure of sysfs, instead of attempting to share code.
>
> Sharing code is likely to get you into all kinds of problems with short
> term hacks.
What? Are you kidding me? This is one of the most basic principles
which should be followed. The problem is not doing proper modular
design from the get-go. You have it completely backwards.
> > I never really understood why namespace support was added the way it
> > was added. Namespace information is communicated to sysfs via
> > callbacks and back-queries to upper layer, which is a very unusual and
> > weird thing to do when all the involved operations are synchronous.
> > For example, a tagged attribute creation looks like the following.
>
> Then please ask.
I asked the first time around and the answer I got was basically "I
didn't want to go around updating differnet layers and adding stuffing
it in the ops struct is more convenient". Do you have a better reason
now?
> I don't have the time or energy to review these right now, and given the
> sweeping nature of the patches, and the dismissive attitude of the
> original design there is almost at least one stupid bug if not something
> worse.
>
> So until I have the energy to review these.
>
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
No, you don't get to have a say without actually doing the review.
You sure can ask for more time to review stuff as long as it's
reasonable. Why are things like this still not clear to you? You
have been doing this long enough.
> I am sorry but I don't have time to clean up after any more people
> touching sysfs when the break something. It does look like there are so
> possibly good things going on but..
If you wanna object, do it technically through proper review. That's
how it works.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] ehea: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-09-12 3:46 UTC (permalink / raw)
To: cascardo; +Cc: netdev, linux-kernel, Michael Opdenacker
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/ibm/ehea/ehea_main.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ehea/ehea_main.c b/drivers/net/ethernet/ibm/ehea/ehea_main.c
index 35853b4..04e0ef1 100644
--- a/drivers/net/ethernet/ibm/ehea/ehea_main.c
+++ b/drivers/net/ethernet/ibm/ehea/ehea_main.c
@@ -1285,7 +1285,7 @@ static int ehea_reg_interrupts(struct net_device *dev)
ret = ibmebus_request_irq(port->qp_eq->attr.ist1,
ehea_qp_aff_irq_handler,
- IRQF_DISABLED, port->int_aff_name, port);
+ 0, port->int_aff_name, port);
if (ret) {
netdev_err(dev, "failed registering irq for qp_aff_irq_handler:ist=%X\n",
port->qp_eq->attr.ist1);
@@ -1303,8 +1303,7 @@ static int ehea_reg_interrupts(struct net_device *dev)
"%s-queue%d", dev->name, i);
ret = ibmebus_request_irq(pr->eq->attr.ist1,
ehea_recv_irq_handler,
- IRQF_DISABLED, pr->int_send_name,
- pr);
+ 0, pr->int_send_name, pr);
if (ret) {
netdev_err(dev, "failed registering irq for ehea_queue port_res_nr:%d, ist=%X\n",
i, pr->eq->attr.ist1);
@@ -3320,7 +3319,7 @@ static int ehea_probe_adapter(struct platform_device *dev)
}
ret = ibmebus_request_irq(adapter->neq->attr.ist1,
- ehea_interrupt_neq, IRQF_DISABLED,
+ ehea_interrupt_neq, 0,
"ehea_neq", adapter);
if (ret) {
dev_err(&dev->dev, "requesting NEQ IRQ failed\n");
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 7/7] sysfs: @name comes before @ns
From: Eric W. Biederman @ 2013-09-12 3:39 UTC (permalink / raw)
To: Tejun Heo; +Cc: gregkh, linux-kernel, kay, netdev, lizefan
In-Reply-To: <1378952949-7900-8-git-send-email-tj@kernel.org>
Tejun Heo <tj@kernel.org> writes:
> Some internal sysfs functions which take explicit namespace argument
> are weird in that they place the optional @ns in front of @name which
> is contrary to the established convention. This is confusing and
> error-prone especially as @ns and @name may be interchanged without
> causing compilation warning.
>
> Swap the positions of @name and @ns in the following internal
> functions.
Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
@ns is more significant so it should come first.
Where do we have the backwards convention of putting @name first?
Eric
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox