* Re: [net-next PATCH V6 0/2] qdisc: bulk dequeue support
From: Eric Dumazet @ 2014-10-03 20:57 UTC (permalink / raw)
To: David Miller
Cc: brouer, netdev, therbert, hannes, fw, dborkman, jhs,
alexander.duyck, john.r.fastabend, dave.taht, toke
In-Reply-To: <20141003.123806.183331913071081861.davem@davemloft.net>
On Fri, 2014-10-03 at 12:38 -0700, David Miller wrote:
> From: Jesper Dangaard Brouer <brouer@redhat.com>
> Date: Wed, 01 Oct 2014 22:35:31 +0200
>
> > This patchset uses DaveM's recent API changes to dev_hard_start_xmit(),
> > from the qdisc layer, to implement dequeue bulking.
>
> Series applied, thanks for all of your hard work!
I thinks its possible to make all validate_xmit_skb() calls outside of
qdisc lock. GSO segmentation of TX checksuming should not prevent other
cpus from queueing other skbs in the qdisc.
I will spend some time on this.
^ permalink raw reply
* Re: [net-next PATCH] veth: don't assign a qdisc to veth
From: Eric Dumazet @ 2014-10-03 20:51 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Cong Wang, netdev, David S. Miller, Jiri Pirko, mpatel
In-Reply-To: <20141003223816.6c56e6d8@redhat.com>
On Fri, 2014-10-03 at 22:38 +0200, Jesper Dangaard Brouer wrote:
> On Fri, 3 Oct 2014 09:53:16 -0700
> Cong Wang <cwang@twopensource.com> wrote:
>
> > On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer
> > <brouer@redhat.com> wrote:
> > > The veth driver is a virtual device, and should not have assigned
> > > the default qdisc. Verified (ndo_start_xmit) veth_xmit can only
> > > return NETDEV_TX_OK, thus this should be safe to bypass qdisc.
> > >
> > > Not assigning a qdisc is subtly done by setting tx_queue_len to zero.
> > >
> >
> > Huh?? Maybe your $subject is too misleading, but we do use HTB
> > on veth, this will break our code since we will have to set tx_queue_len
> > after your patch, no?
>
> No, you HTB setup should still work.
Unfortunately no....
Default htb classes are pfifo, and this uses device txqueuelen as
default limit.
So your change should have been done years ago.
Now its too late as it can break existing user scripts.
^ permalink raw reply
* Re: [net-next PATCH] veth: don't assign a qdisc to veth
From: Cong Wang @ 2014-10-03 20:48 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, David S. Miller, Jiri Pirko, mpatel
In-Reply-To: <20141003223816.6c56e6d8@redhat.com>
On Fri, Oct 3, 2014 at 1:38 PM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Fri, 3 Oct 2014 09:53:16 -0700
> Cong Wang <cwang@twopensource.com> wrote:
>
>> On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer
>> <brouer@redhat.com> wrote:
>> > The veth driver is a virtual device, and should not have assigned
>> > the default qdisc. Verified (ndo_start_xmit) veth_xmit can only
>> > return NETDEV_TX_OK, thus this should be safe to bypass qdisc.
>> >
>> > Not assigning a qdisc is subtly done by setting tx_queue_len to zero.
>> >
>>
>> Huh?? Maybe your $subject is too misleading, but we do use HTB
>> on veth, this will break our code since we will have to set tx_queue_len
>> after your patch, no?
>
> No, you HTB setup should still work.
I wish you are right, but this really worries me...
http://marc.info/?l=linux-netdev&m=137516888117465&w=2
^ permalink raw reply
* Re: [PATCH] drivers:ethernet:davinci_emac.c:Fixes flaw in mac address handling.
From: Michael Welling @ 2014-10-03 20:43 UTC (permalink / raw)
To: David Miller; +Cc: tony, netdev, linux-kernel
In-Reply-To: <20141003.130305.2216770567363258603.davem@davemloft.net>
On Fri, Oct 03, 2014 at 01:03:05PM -0700, David Miller wrote:
> From: Michael Welling <mwelling@ieee.org>
> Date: Wed, 1 Oct 2014 21:32:05 -0500
>
> > The code currently checks the mac_addr variable that is clearly
> > zero'd out during allocation.
> >
> > Further code is added to bring the mac_addr from the partial pdata.
> >
> > Signed-off-by: Michael Welling <mwelling@ieee.org>
>
> I don't see anyone specifying a MAC address in the partial pdata,
> so better to just delete that field.
>
> Even if people did, I am not so sure that the partial pdata should
> unconditionally trump an OF provided MAC address.
So should I just leave the code for handling the mac_addr field from the
partial pdata out or make it such that the mac_addr field is overriden
if specified from the devicetree?
^ permalink raw reply
* Re: [net-next PATCH] veth: don't assign a qdisc to veth
From: Jesper Dangaard Brouer @ 2014-10-03 20:38 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller, Jiri Pirko, mpatel, brouer
In-Reply-To: <CAHA+R7PMkNefxottnNOq+xhRVW_n+SXQxZYFXoNY1b_xEjWm5g@mail.gmail.com>
On Fri, 3 Oct 2014 09:53:16 -0700
Cong Wang <cwang@twopensource.com> wrote:
> On Fri, Oct 3, 2014 at 3:48 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > The veth driver is a virtual device, and should not have assigned
> > the default qdisc. Verified (ndo_start_xmit) veth_xmit can only
> > return NETDEV_TX_OK, thus this should be safe to bypass qdisc.
> >
> > Not assigning a qdisc is subtly done by setting tx_queue_len to zero.
> >
>
> Huh?? Maybe your $subject is too misleading, but we do use HTB
> on veth, this will break our code since we will have to set tx_queue_len
> after your patch, no?
No, you HTB setup should still work.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v2 net-next] r8169:add support for RTL8168EP
From: Francois Romieu @ 2014-10-03 20:32 UTC (permalink / raw)
To: Chun-Hao Lin; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1412328052-8480-1-git-send-email-hau@realtek.com>
Chun-Hao Lin <hau@realtek.com> :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 54476ba..3efdf4d 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -1276,6 +1273,52 @@ static void rtl_w0w1_eri(struct rtl8169_private *tp, int addr, u32 mask, u32 p,
> rtl_eri_write(tp, addr, mask, (val & ~m) | p, type);
> }
>
> +static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
> +{
> + void __iomem *ioaddr = tp->mmio_addr;
> +
> + switch (tp->mac_version) {
> + case RTL_GIGA_MAC_VER_27:
> + case RTL_GIGA_MAC_VER_28:
> + case RTL_GIGA_MAC_VER_31:
> + RTL_W32(OCPAR, ((u32)mask & 0x0f) << 12 | (reg & 0x0fff));
> + return rtl_udelay_loop_wait_high(tp, &rtl_ocpar_cond, 100, 20)
> + ? RTL_R32(OCPDR) : ~0;
'?' should be on the previous line. There isn't more room than needed but
it's still ok.
[...]
> +static void rtl8168ep_2_hw_phy_config(struct rtl8169_private *tp)
> +{
[...]
> + rtl_w0w1_phy(tp, 0x14, 0x7C00, ~0x7Cff);
Nit: rtl_w0w1_phy(tp, 0x14, 0x7c00, ~0x7cff);
[...]
+ rtl_writephy(tp, 0x1f, 0x0bC8);
Nit: rtl_writephy(tp, 0x1f, 0x0bc8);
Tangent: please find feature wise identical code below without moves.
I have avoided introducing more helpers that may have kept the code
more balanced for 8168dp vs 8168ep as it wasn't the point and it is
still possible to change the code from there.
It provides a different review experience. Feel free to give it a thought.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 54476ba..54cd116 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -155,6 +155,9 @@ enum mac_version {
RTL_GIGA_MAC_VER_46,
RTL_GIGA_MAC_VER_47,
RTL_GIGA_MAC_VER_48,
+ RTL_GIGA_MAC_VER_49,
+ RTL_GIGA_MAC_VER_50,
+ RTL_GIGA_MAC_VER_51,
RTL_GIGA_MAC_NONE = 0xff,
};
@@ -302,6 +305,15 @@ static const struct {
[RTL_GIGA_MAC_VER_48] =
_R("RTL8107e", RTL_TD_1, FIRMWARE_8107E_2,
JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_49] =
+ _R("RTL8168ep/8111ep", RTL_TD_1, NULL,
+ JUMBO_9K, false),
+ [RTL_GIGA_MAC_VER_50] =
+ _R("RTL8168ep/8111ep", RTL_TD_1, NULL,
+ JUMBO_9K, false),
+ [RTL_GIGA_MAC_VER_51] =
+ _R("RTL8168ep/8111ep", RTL_TD_1, NULL,
+ JUMBO_9K, false),
};
#undef _R
@@ -400,6 +412,10 @@ enum rtl_registers {
FuncEvent = 0xf0,
FuncEventMask = 0xf4,
FuncPresetState = 0xf8,
+ IBCR0 = 0xf8,
+ IBCR2 = 0xf9,
+ IBIMR0 = 0xfa,
+ IBISR0 = 0xfb,
FuncForceEvent = 0xfc,
};
@@ -467,6 +483,7 @@ enum rtl8168_registers {
#define ERIAR_EXGMAC (0x00 << ERIAR_TYPE_SHIFT)
#define ERIAR_MSIX (0x01 << ERIAR_TYPE_SHIFT)
#define ERIAR_ASF (0x02 << ERIAR_TYPE_SHIFT)
+#define ERIAR_OOB (0x02 << ERIAR_TYPE_SHIFT)
#define ERIAR_MASK_SHIFT 12
#define ERIAR_MASK_0001 (0x1 << ERIAR_MASK_SHIFT)
#define ERIAR_MASK_0011 (0x3 << ERIAR_MASK_SHIFT)
@@ -942,7 +959,7 @@ DECLARE_RTL_COND(rtl_ocpar_cond)
return RTL_R32(OCPAR) & OCPAR_FLAG;
}
-static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
+static u32 r8168dp_ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -952,7 +969,8 @@ static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
RTL_R32(OCPDR) : ~0;
}
-static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data)
+static void r8168dp_ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg,
+ u32 data)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -1276,6 +1294,43 @@ static void rtl_w0w1_eri(struct rtl8169_private *tp, int addr, u32 mask, u32 p,
rtl_eri_write(tp, addr, mask, (val & ~m) | p, type);
}
+static u32 ocp_read(struct rtl8169_private *tp, u8 mask, u16 reg)
+{
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
+ return r8168dp_ocp_read(tp, mask, reg);
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
+ return rtl_eri_read(tp, reg, ERIAR_OOB);
+ default:
+ BUG();
+ return ~0;
+ }
+}
+
+static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data)
+{
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
+ r8168dp_ocp_write(tp, mask, reg, data);
+ break;
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
+ rtl_eri_write(tp, reg, ((u32)mask & 0x0f) << ERIAR_MASK_SHIFT,
+ data, ERIAR_OOB);
+ break;
+ default:
+ BUG();
+ break;
+ }
+}
+
static void rtl8168_oob_notify(struct rtl8169_private *tp, u8 cmd)
{
rtl_eri_write(tp, 0xe8, ERIAR_MASK_0001, cmd, ERIAR_EXGMAC);
@@ -1301,25 +1356,96 @@ DECLARE_RTL_COND(rtl_ocp_read_cond)
return ocp_read(tp, 0x0f, reg) & 0x00000800;
}
-static void rtl8168_driver_start(struct rtl8169_private *tp)
+static void rtl8168dp_driver_start(struct rtl8169_private *tp)
{
rtl8168_oob_notify(tp, OOB_CMD_DRIVER_START);
rtl_msleep_loop_wait_high(tp, &rtl_ocp_read_cond, 10, 10);
}
-static void rtl8168_driver_stop(struct rtl8169_private *tp)
+DECLARE_RTL_COND(rtl_ep_ocp_read_cond)
+{
+ return ocp_read(tp, 0x0f, 0x124) & 0x00000001;
+}
+
+DECLARE_RTL_COND(rtl_ocp_tx_cond)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ return RTL_R8(IBISR0) & 0x02;
+}
+
+static void rtl8168_driver_start(struct rtl8169_private *tp)
+{
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
+ rtl8168dp_driver_start(tp);
+ break;
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
+ ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_START);
+ ocp_write(tp, 0x01, 0x30, ocp_read(tp, 0x01, 0x30) | 0x01);
+ rtl_msleep_loop_wait_high(tp, &rtl_ep_ocp_read_cond, 10, 10);
+ break;
+ default:
+ BUG();
+ break;
+ }
+}
+
+static void rtl8168dp_driver_stop(struct rtl8169_private *tp)
{
rtl8168_oob_notify(tp, OOB_CMD_DRIVER_STOP);
rtl_msleep_loop_wait_low(tp, &rtl_ocp_read_cond, 10, 10);
}
+static void rtl8168_driver_stop(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
+ rtl8168dp_driver_stop(tp);
+ break;
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
+ RTL_W8(IBCR2, RTL_R8(IBCR2) & ~0x01);
+ rtl_msleep_loop_wait_low(tp, &rtl_ocp_tx_cond, 50, 2000);
+ RTL_W8(IBISR0, RTL_R8(IBISR0) | 0x20);
+ RTL_W8(IBCR0, RTL_R8(IBCR0) & ~0x01);
+ ocp_write(tp, 0x01, 0x180, OOB_CMD_DRIVER_STOP);
+ ocp_write(tp, 0x01, 0x30, ocp_read(tp, 0x01, 0x30) | 0x01);
+ rtl_msleep_loop_wait_low(tp, &rtl_ep_ocp_read_cond, 10, 10);
+ break;
+ default:
+ BUG();
+ break;
+ }
+}
+
static int r8168_check_dash(struct rtl8169_private *tp)
{
u16 reg = rtl8168_get_ocp_reg(tp);
- return (ocp_read(tp, 0x0f, reg) & 0x00008000) ? 1 : 0;
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
+ return (ocp_read(tp, 0x0f, reg) & 0x00008000) ? 1 : 0;
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
+ return (ocp_read(tp, 0x0f, 0x128) & 0x00000001) ? 1 : 0;
+ default:
+ return 0;
+ }
}
struct exgmac_reg {
@@ -1553,6 +1679,9 @@ static u32 __rtl8169_get_wol(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
if (rtl_eri_read(tp, 0xdc, ERIAR_EXGMAC) & MagicPacket_v2)
wolopts |= WAKE_MAGIC;
break;
@@ -1620,6 +1749,9 @@ static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
tmp = ARRAY_SIZE(cfg) - 1;
if (wolopts & WAKE_MAGIC)
rtl_w0w1_eri(tp,
@@ -2126,6 +2258,11 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
u32 val;
int mac_version;
} mac_info[] = {
+ /* 8168EP family. */
+ { 0x7cf00000, 0x50200000, RTL_GIGA_MAC_VER_51 },
+ { 0x7cf00000, 0x50100000, RTL_GIGA_MAC_VER_50 },
+ { 0x7cf00000, 0x50000000, RTL_GIGA_MAC_VER_49 },
+
/* 8168H family. */
{ 0x7cf00000, 0x54100000, RTL_GIGA_MAC_VER_46 },
{ 0x7cf00000, 0x54000000, RTL_GIGA_MAC_VER_45 },
@@ -3741,6 +3878,139 @@ static void rtl8168h_2_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0000);
}
+static void rtl8168ep_1_hw_phy_config(struct rtl8169_private *tp)
+{
+ /* Enable PHY auto speed down */
+ rtl_writephy(tp, 0x1f, 0x0a44);
+ rtl_w0w1_phy(tp, 0x11, 0x000c, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* patch 10M & ALDPS */
+ rtl_writephy(tp, 0x1f, 0x0bcc);
+ rtl_w0w1_phy(tp, 0x14, 0x0000, 0x0100);
+ rtl_writephy(tp, 0x1f, 0x0a44);
+ rtl_w0w1_phy(tp, 0x11, 0x00c0, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ rtl_writephy(tp, 0x13, 0x8084);
+ rtl_w0w1_phy(tp, 0x14, 0x0000, 0x6000);
+ rtl_w0w1_phy(tp, 0x10, 0x1003, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* Enable EEE auto-fallback function */
+ rtl_writephy(tp, 0x1f, 0x0a4b);
+ rtl_w0w1_phy(tp, 0x11, 0x0004, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* Enable UC LPF tune function */
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ rtl_writephy(tp, 0x13, 0x8012);
+ rtl_w0w1_phy(tp, 0x14, 0x8000, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* set rg_sel_sdm_rate */
+ rtl_writephy(tp, 0x1f, 0x0c42);
+ rtl_w0w1_phy(tp, 0x11, 0x4000, 0x2000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* Check ALDPS bit, disable it if enabled */
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ if (rtl_readphy(tp, 0x10) & 0x0004)
+ rtl_w0w1_phy(tp, 0x10, 0x0000, 0x0004);
+
+ rtl_writephy(tp, 0x1f, 0x0000);
+}
+
+static void rtl8168ep_2_hw_phy_config(struct rtl8169_private *tp)
+{
+ /* patch 10M & ALDPS */
+ rtl_writephy(tp, 0x1f, 0x0bcc);
+ rtl_w0w1_phy(tp, 0x14, 0x0000, 0x0100);
+ rtl_writephy(tp, 0x1f, 0x0a44);
+ rtl_w0w1_phy(tp, 0x11, 0x00c0, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ rtl_writephy(tp, 0x13, 0x8084);
+ rtl_w0w1_phy(tp, 0x14, 0x0000, 0x6000);
+ rtl_w0w1_phy(tp, 0x10, 0x1003, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* Enable UC LPF tune function */
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ rtl_writephy(tp, 0x13, 0x8012);
+ rtl_w0w1_phy(tp, 0x14, 0x8000, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* Set rg_sel_sdm_rate */
+ rtl_writephy(tp, 0x1f, 0x0c42);
+ rtl_w0w1_phy(tp, 0x11, 0x4000, 0x2000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* Channel estimation parameters */
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ rtl_writephy(tp, 0x13, 0x80f3);
+ rtl_w0w1_phy(tp, 0x14, 0x8b00, ~0x8bff);
+ rtl_writephy(tp, 0x13, 0x80f0);
+ rtl_w0w1_phy(tp, 0x14, 0x3a00, ~0x3aff);
+ rtl_writephy(tp, 0x13, 0x80ef);
+ rtl_w0w1_phy(tp, 0x14, 0x0500, ~0x05ff);
+ rtl_writephy(tp, 0x13, 0x80f6);
+ rtl_w0w1_phy(tp, 0x14, 0x6e00, ~0x6eff);
+ rtl_writephy(tp, 0x13, 0x80ec);
+ rtl_w0w1_phy(tp, 0x14, 0x6800, ~0x68ff);
+ rtl_writephy(tp, 0x13, 0x80ed);
+ rtl_w0w1_phy(tp, 0x14, 0x7c00, ~0x7cff);
+ rtl_writephy(tp, 0x13, 0x80f2);
+ rtl_w0w1_phy(tp, 0x14, 0xf400, ~0xf4ff);
+ rtl_writephy(tp, 0x13, 0x80f4);
+ rtl_w0w1_phy(tp, 0x14, 0x8500, ~0x85ff);
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ rtl_writephy(tp, 0x13, 0x8110);
+ rtl_w0w1_phy(tp, 0x14, 0xa800, ~0xa8ff);
+ rtl_writephy(tp, 0x13, 0x810f);
+ rtl_w0w1_phy(tp, 0x14, 0x1d00, ~0x1dff);
+ rtl_writephy(tp, 0x13, 0x8111);
+ rtl_w0w1_phy(tp, 0x14, 0xf500, ~0xf5ff);
+ rtl_writephy(tp, 0x13, 0x8113);
+ rtl_w0w1_phy(tp, 0x14, 0x6100, ~0x61ff);
+ rtl_writephy(tp, 0x13, 0x8115);
+ rtl_w0w1_phy(tp, 0x14, 0x9200, ~0x92ff);
+ rtl_writephy(tp, 0x13, 0x810e);
+ rtl_w0w1_phy(tp, 0x14, 0x0400, ~0x04ff);
+ rtl_writephy(tp, 0x13, 0x810c);
+ rtl_w0w1_phy(tp, 0x14, 0x7c00, ~0x7cff);
+ rtl_writephy(tp, 0x13, 0x810b);
+ rtl_w0w1_phy(tp, 0x14, 0x5a00, ~0x5aff);
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ rtl_writephy(tp, 0x13, 0x80d1);
+ rtl_w0w1_phy(tp, 0x14, 0xff00, ~0xffff);
+ rtl_writephy(tp, 0x13, 0x80cd);
+ rtl_w0w1_phy(tp, 0x14, 0x9e00, ~0x9eff);
+ rtl_writephy(tp, 0x13, 0x80d3);
+ rtl_w0w1_phy(tp, 0x14, 0x0e00, ~0x0eff);
+ rtl_writephy(tp, 0x13, 0x80d5);
+ rtl_w0w1_phy(tp, 0x14, 0xca00, ~0xcaff);
+ rtl_writephy(tp, 0x13, 0x80d7);
+ rtl_w0w1_phy(tp, 0x14, 0x8400, ~0x84ff);
+
+ /* Force PWM-mode */
+ rtl_writephy(tp, 0x1f, 0x0bcd);
+ rtl_writephy(tp, 0x14, 0x5065);
+ rtl_writephy(tp, 0x14, 0xd065);
+ rtl_writephy(tp, 0x1f, 0x0bc8);
+ rtl_writephy(tp, 0x12, 0x00ed);
+ rtl_writephy(tp, 0x1f, 0x0bcd);
+ rtl_writephy(tp, 0x14, 0x1065);
+ rtl_writephy(tp, 0x14, 0x9065);
+ rtl_writephy(tp, 0x14, 0x1065);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* Check ALDPS bit, disable it if enabled */
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ if (rtl_readphy(tp, 0x10) & 0x0004)
+ rtl_w0w1_phy(tp, 0x10, 0x0000, 0x0004);
+
+ rtl_writephy(tp, 0x1f, 0x0000);
+}
+
static void rtl8102e_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -3940,6 +4210,14 @@ static void rtl_hw_phy_config(struct net_device *dev)
rtl8168h_2_hw_phy_config(tp);
break;
+ case RTL_GIGA_MAC_VER_49:
+ rtl8168ep_1_hw_phy_config(tp);
+ break;
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
+ rtl8168ep_2_hw_phy_config(tp);
+ break;
+
case RTL_GIGA_MAC_VER_41:
default:
break;
@@ -4154,6 +4432,9 @@ static void rtl_init_mdio_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
ops->write = r8168g_mdio_write;
ops->read = r8168g_mdio_read;
break;
@@ -4212,6 +4493,9 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
RTL_W32(RxConfig, RTL_R32(RxConfig) |
AcceptBroadcast | AcceptMulticast | AcceptMyPhys);
break;
@@ -4356,7 +4640,10 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
if ((tp->mac_version == RTL_GIGA_MAC_VER_27 ||
tp->mac_version == RTL_GIGA_MAC_VER_28 ||
- tp->mac_version == RTL_GIGA_MAC_VER_31) &&
+ tp->mac_version == RTL_GIGA_MAC_VER_31 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_49 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_50 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_51) &&
r8168_check_dash(tp)) {
return;
}
@@ -4387,10 +4674,13 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_44:
case RTL_GIGA_MAC_VER_45:
case RTL_GIGA_MAC_VER_46:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
break;
case RTL_GIGA_MAC_VER_40:
case RTL_GIGA_MAC_VER_41:
+ case RTL_GIGA_MAC_VER_49:
rtl_w0w1_eri(tp, 0x1a8, ERIAR_MASK_1111, 0x00000000,
0xfc000000, ERIAR_EXGMAC);
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
@@ -4415,10 +4705,13 @@ static void r8168_pll_power_up(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_44:
case RTL_GIGA_MAC_VER_45:
case RTL_GIGA_MAC_VER_46:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
RTL_W8(PMCH, RTL_R8(PMCH) | 0xc0);
break;
case RTL_GIGA_MAC_VER_40:
case RTL_GIGA_MAC_VER_41:
+ case RTL_GIGA_MAC_VER_49:
RTL_W8(PMCH, RTL_R8(PMCH) | 0xc0);
rtl_w0w1_eri(tp, 0x1a8, ERIAR_MASK_1111, 0xfc000000,
0x00000000, ERIAR_EXGMAC);
@@ -4493,6 +4786,9 @@ static void rtl_init_pll_power_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_44:
case RTL_GIGA_MAC_VER_45:
case RTL_GIGA_MAC_VER_46:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
ops->down = r8168_pll_power_down;
ops->up = r8168_pll_power_up;
break;
@@ -4547,6 +4843,9 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
RTL_W32(RxConfig, RX128_INT_EN | RX_DMA_BURST | RX_EARLY_OFF);
break;
default:
@@ -4712,6 +5011,9 @@ static void rtl_init_jumbo_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
default:
ops->disable = NULL;
ops->enable = NULL;
@@ -4828,7 +5130,10 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
tp->mac_version == RTL_GIGA_MAC_VER_45 ||
tp->mac_version == RTL_GIGA_MAC_VER_46 ||
tp->mac_version == RTL_GIGA_MAC_VER_47 ||
- tp->mac_version == RTL_GIGA_MAC_VER_48) {
+ tp->mac_version == RTL_GIGA_MAC_VER_48 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_49 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_50 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_51) {
RTL_W8(ChipCmd, RTL_R8(ChipCmd) | StopReq);
rtl_udelay_loop_wait_high(tp, &rtl_txcfg_empty_cond, 100, 666);
} else {
@@ -5754,6 +6059,120 @@ static void rtl_hw_start_8168h_1(struct rtl8169_private *tp)
r8168_mac_ocp_write(tp, 0xc09e, 0x0000);
}
+static void rtl_hw_start_8168ep(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ struct pci_dev *pdev = tp->pci_dev;
+
+ RTL_W32(TxConfig, RTL_R32(TxConfig) | TXCFG_AUTO_FIFO);
+
+ rtl_eri_write(tp, 0xc8, ERIAR_MASK_0101, 0x00080002, ERIAR_EXGMAC);
+ rtl_eri_write(tp, 0xcc, ERIAR_MASK_0001, 0x2f, ERIAR_EXGMAC);
+ rtl_eri_write(tp, 0xd0, ERIAR_MASK_0001, 0x5f, ERIAR_EXGMAC);
+ rtl_eri_write(tp, 0xe8, ERIAR_MASK_1111, 0x00100006, ERIAR_EXGMAC);
+
+ rtl_csi_access_enable_1(tp);
+
+ rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
+
+ rtl_w0w1_eri(tp, 0xdc, ERIAR_MASK_0001, 0x00, 0x01, ERIAR_EXGMAC);
+ rtl_w0w1_eri(tp, 0xdc, ERIAR_MASK_0001, 0x01, 0x00, ERIAR_EXGMAC);
+
+ rtl_w0w1_eri(tp, 0xd4, ERIAR_MASK_1111, 0x1f80, 0x00, ERIAR_EXGMAC);
+
+ rtl_eri_write(tp, 0x5f0, ERIAR_MASK_0011, 0x4f87, ERIAR_EXGMAC);
+
+ RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
+ RTL_W32(MISC, RTL_R32(MISC) & ~RXDV_GATED_EN);
+ RTL_W8(MaxTxPacketSize, EarlySize);
+
+ rtl_eri_write(tp, 0xc0, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
+ rtl_eri_write(tp, 0xb8, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
+
+ /* Adjust EEE LED frequency */
+ RTL_W8(EEE_LED, RTL_R8(EEE_LED) & ~0x07);
+
+ rtl_w0w1_eri(tp, 0x2fc, ERIAR_MASK_0001, 0x01, 0x06, ERIAR_EXGMAC);
+
+ RTL_W8(DLLPR, RTL_R8(DLLPR) & ~TX_10M_PS_EN);
+
+ rtl_pcie_state_l2l3_enable(tp, false);
+}
+
+static void rtl_hw_start_8168ep_1(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct ephy_info e_info_8168ep_1[] = {
+ { 0x00, 0xffff, 0x10ab },
+ { 0x06, 0xffff, 0xf030 },
+ { 0x08, 0xffff, 0x2006 },
+ { 0x0d, 0xffff, 0x1666 },
+ { 0x0c, 0x3ff0, 0x0000 }
+ };
+
+ /* disable aspm and clock request before access ephy */
+ RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
+ RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
+ rtl_ephy_init(tp, e_info_8168ep_1, ARRAY_SIZE(e_info_8168ep_1));
+
+ rtl_hw_start_8168ep(tp);
+}
+
+static void rtl_hw_start_8168ep_2(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct ephy_info e_info_8168ep_2[] = {
+ { 0x00, 0xffff, 0x10a3 },
+ { 0x19, 0xffff, 0xfc00 },
+ { 0x1e, 0xffff, 0x20ea }
+ };
+
+ /* disable aspm and clock request before access ephy */
+ RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
+ RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
+ rtl_ephy_init(tp, e_info_8168ep_2, ARRAY_SIZE(e_info_8168ep_2));
+
+ rtl_hw_start_8168ep(tp);
+
+ RTL_W8(DLLPR, RTL_R8(DLLPR) & ~PFM_EN);
+ RTL_W8(DLLPR, RTL_R8(MISC_1) & ~PFM_D3COLD_EN);
+}
+
+static void rtl_hw_start_8168ep_3(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ u32 data;
+ static const struct ephy_info e_info_8168ep_3[] = {
+ { 0x00, 0xffff, 0x10a3 },
+ { 0x19, 0xffff, 0x7c00 },
+ { 0x1e, 0xffff, 0x20eb },
+ { 0x0d, 0xffff, 0x1666 }
+ };
+
+ /* disable aspm and clock request before access ephy */
+ RTL_W8(Config2, RTL_R8(Config2) & ~ClkReqEn);
+ RTL_W8(Config5, RTL_R8(Config5) & ~ASPM_en);
+ rtl_ephy_init(tp, e_info_8168ep_3, ARRAY_SIZE(e_info_8168ep_3));
+
+ rtl_hw_start_8168ep(tp);
+
+ RTL_W8(DLLPR, RTL_R8(DLLPR) & ~PFM_EN);
+ RTL_W8(DLLPR, RTL_R8(MISC_1) & ~PFM_D3COLD_EN);
+
+ data = r8168_mac_ocp_read(tp, 0xd3e2);
+ data &= 0xf000;
+ data |= 0x0271;
+ r8168_mac_ocp_write(tp, 0xd3e2, data);
+
+ data = r8168_mac_ocp_read(tp, 0xd3e4);
+ data &= 0xff00;
+ r8168_mac_ocp_write(tp, 0xd3e4, data);
+
+ data = r8168_mac_ocp_read(tp, 0xe860);
+ data |= 0x0080;
+ r8168_mac_ocp_write(tp, 0xe860, data);
+}
+
static void rtl_hw_start_8168(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -5869,6 +6288,18 @@ static void rtl_hw_start_8168(struct net_device *dev)
rtl_hw_start_8168h_1(tp);
break;
+ case RTL_GIGA_MAC_VER_49:
+ rtl_hw_start_8168ep_1(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_50:
+ rtl_hw_start_8168ep_2(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_51:
+ rtl_hw_start_8168ep_3(tp);
+ break;
+
default:
printk(KERN_ERR PFX "%s: unknown chipset (mac_version = %d).\n",
dev->name, tp->mac_version);
@@ -7399,7 +7830,10 @@ static void rtl_remove_one(struct pci_dev *pdev)
if ((tp->mac_version == RTL_GIGA_MAC_VER_27 ||
tp->mac_version == RTL_GIGA_MAC_VER_28 ||
- tp->mac_version == RTL_GIGA_MAC_VER_31) &&
+ tp->mac_version == RTL_GIGA_MAC_VER_31 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_49 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_50 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_51) &&
r8168_check_dash(tp)) {
rtl8168_driver_stop(tp);
}
@@ -7556,6 +7990,9 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
rtl_hw_init_8168g(tp);
break;
@@ -7708,6 +8145,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
case RTL_GIGA_MAC_VER_46:
case RTL_GIGA_MAC_VER_47:
case RTL_GIGA_MAC_VER_48:
+ case RTL_GIGA_MAC_VER_49:
+ case RTL_GIGA_MAC_VER_50:
+ case RTL_GIGA_MAC_VER_51:
if (rtl_eri_read(tp, 0xdc, ERIAR_EXGMAC) & MagicPacket_v2)
tp->features |= RTL_FEATURE_WOL;
if ((RTL_R8(Config3) & LinkUp) != 0)
@@ -7756,7 +8196,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->mac_version == RTL_GIGA_MAC_VER_45 ||
tp->mac_version == RTL_GIGA_MAC_VER_46 ||
tp->mac_version == RTL_GIGA_MAC_VER_47 ||
- tp->mac_version == RTL_GIGA_MAC_VER_48) {
+ tp->mac_version == RTL_GIGA_MAC_VER_48 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_49 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_50 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_51) {
u16 mac_addr[3];
*(u32 *)&mac_addr[0] = rtl_eri_read(tp, 0xe0, ERIAR_EXGMAC);
@@ -7835,7 +8278,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if ((tp->mac_version == RTL_GIGA_MAC_VER_27 ||
tp->mac_version == RTL_GIGA_MAC_VER_28 ||
- tp->mac_version == RTL_GIGA_MAC_VER_31) &&
+ tp->mac_version == RTL_GIGA_MAC_VER_31 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_49 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_50 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_51) &&
r8168_check_dash(tp)) {
rtl8168_driver_start(tp);
}
^ permalink raw reply related
* [net-next] fm10k: Add CONFIG_FM10K_VXLAN configuration option
From: Andy Zhou @ 2014-10-03 21:05 UTC (permalink / raw)
To: davem; +Cc: alexander.h.duyck, netdev, Andy Zhou
Compiling with CONFIG_FM10K=y and VXLAN=m resulting in linking error:
drivers/built-in.o: In function `fm10k_open':
(.text+0x1f9d7a): undefined reference to `vxlan_get_rx_port'
make: *** [vmlinux] Error 1
The fix follows the same strategy as I40E.
Signed-off-by: Andy Zhou <azhou@nicira.com>
---
drivers/net/ethernet/intel/Kconfig | 11 +++++++++++
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 6 +++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
index 6a6d5ee..3308881 100644
--- a/drivers/net/ethernet/intel/Kconfig
+++ b/drivers/net/ethernet/intel/Kconfig
@@ -319,4 +319,15 @@ config FM10K
To compile this driver as a module, choose M here. The module
will be called fm10k. MSI-X interrupt support is required
+config FM10K_VXLAN
+ bool "Virtual eXtensible Local Area Network Support"
+ default n
+ depends on FM10K && VXLAN && !(FM10K=y && VXLAN=m)
+ ---help---
+ This allows one to create VXLAN virtual interfaces that provide
+ Layer 2 Networks over Layer 3 Networks. VXLAN is often used
+ to tunnel virtual network infrastructure in virtualized environments.
+ Say Y here if you want to use Virtual eXtensible Local Area Network
+ (VXLAN) in the driver.
+
endif # NET_VENDOR_INTEL
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
index dcec000..9d46333 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_netdev.c
@@ -20,9 +20,9 @@
#include "fm10k.h"
#include <linux/vmalloc.h>
-#if IS_ENABLED(CONFIG_VXLAN)
+#if IS_ENABLED(CONFIG_FM10K_VXLAN)
#include <net/vxlan.h>
-#endif /* CONFIG_VXLAN */
+#endif /* CONFIG_FM10K_VXLAN */
/**
* fm10k_setup_tx_resources - allocate Tx resources (Descriptors)
@@ -552,7 +552,7 @@ int fm10k_open(struct net_device *netdev)
if (err)
goto err_set_queues;
-#if IS_ENABLED(CONFIG_VXLAN)
+#if IS_ENABLED(CONFIG_FM10K_VXLAN)
/* update VXLAN port configuration */
vxlan_get_rx_port(netdev);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 0/4] net: Generic UDP Encapsulation
From: David Miller @ 2014-10-03 20:18 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <20141003.131029.1598012589716466958.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 03 Oct 2014 13:10:29 -0700 (PDT)
> From: Tom Herbert <therbert@google.com>
> Date: Wed, 1 Oct 2014 21:46:35 -0700
>
>> Generic UDP Encapsulation (GUE) is UDP encapsulation protocol that
>> encapsulates packets of various IP protocols. The GUE protocol is
>> described in http://tools.ietf.org/html/draft-herbert-gue-01.
>
> Series applied, thanks Tom.
I had to revert, forgot to 'git add' this file?
net/ipv4/ip_tunnel.c:59:21: fatal error: net/gue.h: No such file or directory
^ permalink raw reply
* Re: [PATCH net-next 1/1] net: fec: fix build error at m68k platform
From: Zhi Li @ 2014-10-03 20:14 UTC (permalink / raw)
To: Fabio Estevam
Cc: Frank Li, David S. Miller, netdev@vger.kernel.org,
Duan Fugang-B38611
In-Reply-To: <CAOMZO5B=cgVT1gr5VJ78x_Aj5ssvrsTOq4t0DrrLK4kz7vNMjQ@mail.gmail.com>
On Fri, Oct 3, 2014 at 3:07 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Oct 3, 2014 at 4:00 PM, Frank Li <Frank.Li@freescale.com> wrote:
>> reproduce:
>> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout 1b7bde6d659d30f171259cc2dfba8e5dab34e735
>> # save the attached .config to linux build tree
>
> There is no attached config ;-)
It is copy from kbuild report.
Can I change to
config: m68k-m5275evb_defconfig (attached as .config)
>
>> make.cross ARCH=m68k
>>
>> All error/warnings:
>>
>> drivers/net/ethernet/freescale/fec_main.c: In function 'fec_enet_rx_queue':
>>>> drivers/net/ethernet/freescale/fec_main.c:1470:3: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
>> prefetch(skb->data - NET_IP_ALIGN);
>> ^
>> cc1: some warnings being treated as errors
>>
>> missed included prefetch.h
>>
>> Signed-off-by: Frank Li <Frank.Li@freescale.com>
>
> It seems you missed the Reported-by: kbuild test robot
> <fengguang.wu@intel.com> tag.
Okay I can add it.
^ permalink raw reply
* Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support
From: Luis R. Rodriguez @ 2014-10-03 20:11 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: gregkh, dmitry.torokhov, tiwai, tj, arjan, teg, rmilasan, werner,
oleg, hare, bpoirier, santosh, pmladek, dbueso, linux-kernel,
Tetsuo Handa, Joseph Salisbury, Kay Sievers, One Thousand Gnomes,
Tim Gardner, Pierre Fersing, Andrew Morton, Nagalakshmi Nandigama,
Praveen Krishnamoorthy, Sreekanth Reddy, Abhijit Mahajan,
Casey Leedom, Hariprasad S <haripra
In-Reply-To: <1411768637-6809-6-git-send-email-mcgrof@do-not-panic.com>
On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote:
> + queue_work(system_unbound_wq, &priv->attach_work->work);
Tejun,
based on my testing so far using system_highpri_wq instead of
system_unbound_wq yields close to par / better boot times
than synchronous probe support for all modules. How set are
you on using system_unbound_wq? About to punt out a new
series which also addresses built-in.
Luis
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: Generic UDP Encapsulation
From: David Miller @ 2014-10-03 20:10 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <1412225199-24942-1-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 1 Oct 2014 21:46:35 -0700
> Generic UDP Encapsulation (GUE) is UDP encapsulation protocol that
> encapsulates packets of various IP protocols. The GUE protocol is
> described in http://tools.ietf.org/html/draft-herbert-gue-01.
Series applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH net-next 1/1] net: fec: fix build error at m68k platform
From: Fabio Estevam @ 2014-10-03 20:07 UTC (permalink / raw)
To: Frank Li
Cc: David S. Miller, 李智, netdev@vger.kernel.org,
Duan Fugang-B38611
In-Reply-To: <1412362831-59318-1-git-send-email-Frank.Li@freescale.com>
On Fri, Oct 3, 2014 at 4:00 PM, Frank Li <Frank.Li@freescale.com> wrote:
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 1b7bde6d659d30f171259cc2dfba8e5dab34e735
> # save the attached .config to linux build tree
There is no attached config ;-)
> make.cross ARCH=m68k
>
> All error/warnings:
>
> drivers/net/ethernet/freescale/fec_main.c: In function 'fec_enet_rx_queue':
>>> drivers/net/ethernet/freescale/fec_main.c:1470:3: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
> prefetch(skb->data - NET_IP_ALIGN);
> ^
> cc1: some warnings being treated as errors
>
> missed included prefetch.h
>
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
It seems you missed the Reported-by: kbuild test robot
<fengguang.wu@intel.com> tag.
^ permalink raw reply
* Re: [PATCH] drivers:ethernet:davinci_emac.c:Fixes flaw in mac address handling.
From: David Miller @ 2014-10-03 20:03 UTC (permalink / raw)
To: mwelling; +Cc: tony, netdev, linux-kernel
In-Reply-To: <1412217125-11057-1-git-send-email-mwelling@ieee.org>
From: Michael Welling <mwelling@ieee.org>
Date: Wed, 1 Oct 2014 21:32:05 -0500
> The code currently checks the mac_addr variable that is clearly
> zero'd out during allocation.
>
> Further code is added to bring the mac_addr from the partial pdata.
>
> Signed-off-by: Michael Welling <mwelling@ieee.org>
I don't see anyone specifying a MAC address in the partial pdata,
so better to just delete that field.
Even if people did, I am not so sure that the partial pdata should
unconditionally trump an OF provided MAC address.
^ permalink raw reply
* Re: Small fixes/changes for RDS
From: David Miller @ 2014-10-03 19:52 UTC (permalink / raw)
To: herton; +Cc: chien.yen, rds-devel, netdev, linux-kernel, rmanes, dledford
In-Reply-To: <1412200194-28902-1-git-send-email-herton@redhat.com>
From: "Herton R. Krzesinski" <herton@redhat.com>
Date: Wed, 1 Oct 2014 18:49:51 -0300
> I got a report of one issue within RDS (after investigation it was a double
> free), and I'm sending the fix (patch 3/3) which reporter said it works (no more
> WARNING triggered on a specially instrumented kernel). The report/test was done
> on a very old kernel (RHEL 5, 2.6.18 based with backports), but the problem the
> patch handles still exists and should not change. Besides that, while
> reviewing some of the code but being unable to reproduce with rds_tcp, I
> noticed two small improvements/fixes which are in patches 1 and 2.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: adjust fixed_phy_register() return value
From: David Miller @ 2014-10-03 19:47 UTC (permalink / raw)
To: f.fainelli; +Cc: pgynther, netdev, thomas.petazzoni
In-Reply-To: <542C9D50.9050301@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 01 Oct 2014 17:33:20 -0700
> I let Thomas comment on whether he likes this or not.
I'm still waiting to see Thomas's feedback.
^ permalink raw reply
* Re: [net-next 1/6] net: Add Geneve tunneling protocol driver
From: Andy Zhou @ 2014-10-03 19:45 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: David Miller, netdev@vger.kernel.org, Jesse Gross
In-Reply-To: <542EA847.4000904@6wind.com>
>
> Do you plan too add the full support (ie being able to configure a
> geneve netdev interface with iproute2)?
>
According to the following email thread, John Linville is looking at adding it.
http://lists.openwall.net/netdev/2014/07/22/198
> Another small comment below.
>
>> +config GENEVE
>> + tristate "Generic Network Virtualization Encapsulation (Geneve)"
>> + depends on INET
>> + select NET_IP_TUNNEL
>> + select NET_UDP_TUNNEL
>> + ---help---
>
> Use tabs instead of spaces for the baove lines.
Sure, I will fix this.
^ permalink raw reply
* Re: HW bridging support using notifiers?
From: Benjamin LaHaise @ 2014-10-03 19:42 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, davem, jiri, stephen, andy, tgraf, nbd, john.r.fastabend,
edumazet, vyasevic, buytenh, sfeldma, Jamal Hadi Salim
In-Reply-To: <542EF3C4.3050201@gmail.com>
On Fri, Oct 03, 2014 at 12:06:44PM -0700, Florian Fainelli wrote:
> Hi Benjamin,
>
> On 10/03/2014 07:22 AM, Benjamin LaHaise wrote:
> > Hi Florian et al,
> >
> > On Thu, Oct 02, 2014 at 06:48:57PM -0700, Florian Fainelli wrote:
> >> Hi all,
> >>
> >> I am taking a look at adding HW bridging support to DSA, in way that's
> >> usable outside of DSA.
> >
> > I've been working on support for the RTL8366S switch, and our work is
> > directly overlapping here. I actually have something that is working at
> > configuring port and tag based vlans on the RTL8366S. I'll try to clean
> > up the code to post something for discussion over the next couple of days.
>
> Cool, please do!
>
> >
> >> Lennert's approach in 2008 [1] looks conceptually good to me,as he
> >> noted, it uses a bunch of new ndo's which is not only limiting to one
> >> ndo implementer per struct net_device, but also is mostly consuming the
> >> information from the bridge layer, while the ndo is an action
> >
> > I think having ndo implementer methods for hardware switch offloads makes
> > more sense. Such a scheme is needed in order to implement the stacking of
> > devices that is required in order to transparently handle configuration of
> > vlans on switch ports where the 8021q device has to pass on the vlan tag
> > to the switch device. The ndo methods do perform an action of causing the
> > switch to be configured to match the bridge config. Additionally, they
> > can be used to veto changes that cannot be offloaded to hardware -- this
> > (configurable) behaviour is desired by some users of these APIs who wish
> > to be made aware when a particuarly configuration is not supported by the
> > underlying hardware.
>
> Humm, that's a fair point, so not only would we want new NDOs, but we'd
> also need to specify the return values (invalid, no space etc...).
>
> As far as bridging alone is concerned (not including VLANs for now), I
> don't think there are restrictions in terms of what the hardware can do,
> since we mostly tell it to "group" N-ports together.
>
> For VLANs, there should be a way for the switch driver to tell whether
> that's supported or not.
What the hardware can support varies widely. For example, the RTL8366S
happens to support a total of 8 FDBs in hardware, which, given how the Linux
bridge works, implies a total of at most 8 VLANs. However, it can use more
VLANs if they share overlapping FDBs (which Linux doesn't support). There
are also features like VLAN remapping, q-in-q support... We're going to
have to do a fair amount of work to learn about all these quirks of hardware
features that need to be identified and reported.
> >
> >> So here's what I am up to now:
> >>
> >> - use the NETDEV_JOIN notifier to discover when a bridge port is added
> >> - use the NETDEV_LEAVE notifier, still need to verify this does not
> >> break netconsole as indicated in net/bridge/br_if.c
> >> - use the NETDEV_CHANGEINFODATA notifier to notify about STP state changes
> >
> > To me, notifiers are the wrong model for join and leave. Implementing
> > stacking on top of notifiers is somewhat more complicated. Here are the
> > ndo methods I've implemented so far which are sufficient for basic config
> > of the RTL8366S. They're fairly similar to those in [1].
> >
> > + int (*ndo_join_bridge)(struct net_bridge *bridge,
> > + struct net_device *dev,
> > + int *switch_nr,
> > + int *switch_port_nr,
> > + int vlan);
> > + int (*ndo_leave_bridge)(struct net_bridge *bridge,
> > + struct net_device *dev,
> > + int switch_nr,
> > + int switch_port_nr,
> > + int vlan);
> > + int (*ndo_flood_xmit)(struct switch_info *dev,
> > + struct sk_buff *skb,
> > + u64 port_mask);
>
> I don't think the switch_port_nr belongs here, this is something that
> should be resolved within the implementer of these ndo's, whether that
> is DSA, or Jiri's switchdev, since the net_device argument should be
> linked to both the switch port number, and the switch number.
The switch_port_nr is absolutely required for flood offloading. (more below)
> >
> > There are a couple of important points here. In the case of joining and
> > leaving a bridge, the bridge needs to be provided with information it can
> > use to identify switch ports. This is needed in order to offload the
> > flooding of packets to multiple ports, as otherwise the Linux bridge code
> > doesn't have any way to figure out which packets can be merged into a
> > single transmit via the ndo_flood_xmit() method.
>
> I am not exactly sure yet how ndo_flood_xmit() fits in the picture here,
> but it might be optional based on how the switch has been configured I
> presume?
ndo_flood_xmit() is a method that sends a single packet to a bitmask of
the ports attached to the switch. This is quite useful for saving bandwidth
on the CPU port of a switch when sending out broadcast packets, and, more
importantly, multicast packets. The bits in that bitmask correspond to
the switch_port_nr reported ny ndo_join_bridge(), and I modified the Linux
bridge code to group ports attached to the same switch together and use the
switch_nr to identify that ports are on the same switch and collapse flooding
to multiple ports into a single call of ndo_flood_xmit(). The RTL8366S has
support for this feature (that's why I implemented it), and I'm pretty sure
other switches do as well -- at the very least I know one of the Marvell
switches I was exposed to in the past that had this capability, but I don't
recall the precise details of the interface since I wasn't directly involved
in the coding for that driver.
I'm sure there are other hardware features we'll have to come up with a
model for. Cheers,
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [PATCH] team: add rescheduling jiffy delay on !rtnl_trylock
From: Joe Lawrence @ 2014-10-03 19:37 UTC (permalink / raw)
To: paulmck; +Cc: Tejun Heo, netdev, Jiri Pirko
In-Reply-To: <20141002064308.GN5015@linux.vnet.ibm.com>
On Wed, 1 Oct 2014 23:43:08 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> On Mon, Sep 29, 2014 at 12:06:01PM -0400, Tejun Heo wrote:
> > (cc'ing Paul and quoting the whole body)
> >
> > Paul, this is a fix for RCU sched stall observed w/ a work item
> > requeueing itself waiting for the RCU grace period. As the self
> > requeueing work item ends up being executed by the same kworker, the
> > worker task never stops running in the absence of a higher priority
> > task and it seems to delay RCU grace period for a very long time on
> > !PREEMPT kernels. As each work item denotes a boundary which no
> > synchronization construct stretches across, I wonder whether it'd be a
> > good idea to add a notification for the end of RCU critical section
> > between executions of work items.
>
> It sounds like a great idea to me! I suggest invoking
> rcu_note_context_switch() between executions of work items.
>
> Thanx, Paul
I gave this a spin, probably inserting the call in the wrong place:
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 5dbe22a..77f128e 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2045,7 +2045,8 @@ __acquires(&pool->lock)
* indefinitely requeue itself while all other CPUs are trapped in
* stop_machine.
*/
- cond_resched();
+ if (!cond_resched())
+ rcu_note_context_switch(raw_smp_processor_id());
spin_lock_irq(&pool->lock);
this results in RCU grace periods progressing (dyntick remains
fixed) as advertised, even with the test-module from [1] loaded:
Fri Oct 3 14:37:14 2014
4 c=9635 g=9636 pq=1 qp=0 dt=51693/140000000000000/0 df=163 of=0 ql=0/1 qs=...D b=10 ci=0 nci=34184 co=0 ca=0
Fri Oct 3 14:50:24 2014
4 c=13072 g=13073 pq=1 qp=0 dt=51693/140000000000000/0 df=163 of=0 ql=0/1 qs=...D b=10 ci=0 nci=34191 co=0 ca=0
I'll leave it up to Tejun to determine where/how that call should be
made.
Thanks!
-- Joe
[1] http://marc.info/?l=linux-kernel&m=141192244232345
^ permalink raw reply related
* Re: [net-next PATCH V6 0/2] qdisc: bulk dequeue support
From: David Miller @ 2014-10-03 19:38 UTC (permalink / raw)
To: brouer
Cc: netdev, therbert, eric.dumazet, hannes, fw, dborkman, jhs,
alexander.duyck, john.r.fastabend, dave.taht, toke
In-Reply-To: <20141001203345.3321.99675.stgit@dragon>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Wed, 01 Oct 2014 22:35:31 +0200
> This patchset uses DaveM's recent API changes to dev_hard_start_xmit(),
> from the qdisc layer, to implement dequeue bulking.
Series applied, thanks for all of your hard work!
^ permalink raw reply
* Re: [PATCH net-next 1/2] pgtable: Add API to query if write combining is available
From: David Miller @ 2014-10-03 19:31 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, amirv, jackm, moshel, talal, yevgenyp
In-Reply-To: <1412175282-25212-2-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 1 Oct 2014 17:54:41 +0300
> +#define writecombine_available writecombine_available
> +static inline int writecombine_available(void)
> +{
> + return 1;
> +}
> +
Please use 'bool' and 'true'/'false'.
^ permalink raw reply
* Re: [PATCH net-next] et131x: Add PCIe gigabit ethernet driver et131x to drivers/net
From: David Miller @ 2014-10-03 19:25 UTC (permalink / raw)
To: mark.einon; +Cc: gregkh, linux-kernel, netdev
In-Reply-To: <1412112586-2194-1-git-send-email-mark.einon@gmail.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next] net: bcmgenet: improve bcmgenet_mii_setup()
From: Petri Gynther @ 2014-10-03 19:25 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
bcmgenet_mii_setup() is called from the PHY state machine every 1-2 seconds
when the PHYs are in PHY_POLL mode.
Improve bcmgenet_mii_setup() so that it touches the MAC registers only when
the link is up and there was a change to link, speed, duplex, or pause status.
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 3 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 3 +-
drivers/net/ethernet/broadcom/genet/bcmmii.c | 73 ++++++++++++++++----------
3 files changed, 48 insertions(+), 31 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index d51729c..e0a6238 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -2162,9 +2162,10 @@ static void bcmgenet_netif_stop(struct net_device *dev)
*/
cancel_work_sync(&priv->bcmgenet_irq_work);
- priv->old_pause = -1;
priv->old_link = -1;
+ priv->old_speed = -1;
priv->old_duplex = -1;
+ priv->old_pause = -1;
}
static int bcmgenet_close(struct net_device *dev)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index ad95fe5..321b1db 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -548,8 +548,9 @@ struct bcmgenet_priv {
u16 gphy_rev;
/* PHY device variables */
- int old_duplex;
int old_link;
+ int old_speed;
+ int old_duplex;
int old_pause;
phy_interface_t phy_interface;
int phy_addr;
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 75b26cba..9ff799a 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -82,24 +82,33 @@ static void bcmgenet_mii_setup(struct net_device *dev)
struct bcmgenet_priv *priv = netdev_priv(dev);
struct phy_device *phydev = priv->phydev;
u32 reg, cmd_bits = 0;
- unsigned int status_changed = 0;
+ bool status_changed = false;
if (priv->old_link != phydev->link) {
- status_changed = 1;
+ status_changed = true;
priv->old_link = phydev->link;
}
if (phydev->link) {
- /* program UMAC and RGMII block based on established link
- * speed, pause, and duplex.
- * the speed set in umac->cmd tell RGMII block which clock
- * 25MHz(100Mbps)/125MHz(1Gbps) to use for transmit.
- * receive clock is provided by PHY.
- */
- reg = bcmgenet_ext_readl(priv, EXT_RGMII_OOB_CTRL);
- reg &= ~OOB_DISABLE;
- reg |= RGMII_LINK;
- bcmgenet_ext_writel(priv, reg, EXT_RGMII_OOB_CTRL);
+ /* check speed/duplex/pause changes */
+ if (priv->old_speed != phydev->speed) {
+ status_changed = true;
+ priv->old_speed = phydev->speed;
+ }
+
+ if (priv->old_duplex != phydev->duplex) {
+ status_changed = true;
+ priv->old_duplex = phydev->duplex;
+ }
+
+ if (priv->old_pause != phydev->pause) {
+ status_changed = true;
+ priv->old_pause = phydev->pause;
+ }
+
+ /* done if nothing has changed */
+ if (!status_changed)
+ return;
/* speed */
if (phydev->speed == SPEED_1000)
@@ -110,36 +119,39 @@ static void bcmgenet_mii_setup(struct net_device *dev)
cmd_bits = UMAC_SPEED_10;
cmd_bits <<= CMD_SPEED_SHIFT;
- if (priv->old_duplex != phydev->duplex) {
- status_changed = 1;
- priv->old_duplex = phydev->duplex;
- }
-
/* duplex */
if (phydev->duplex != DUPLEX_FULL)
cmd_bits |= CMD_HD_EN;
- if (priv->old_pause != phydev->pause) {
- status_changed = 1;
- priv->old_pause = phydev->pause;
- }
-
/* pause capability */
if (!phydev->pause)
cmd_bits |= CMD_RX_PAUSE_IGNORE | CMD_TX_PAUSE_IGNORE;
- }
- if (!status_changed)
- return;
+ /*
+ * Program UMAC and RGMII block based on established
+ * link speed, duplex, and pause. The speed set in
+ * umac->cmd tell RGMII block which clock to use for
+ * transmit -- 25MHz(100Mbps) or 125MHz(1Gbps).
+ * Receive clock is provided by the PHY.
+ */
+ reg = bcmgenet_ext_readl(priv, EXT_RGMII_OOB_CTRL);
+ reg &= ~OOB_DISABLE;
+ reg |= RGMII_LINK;
+ bcmgenet_ext_writel(priv, reg, EXT_RGMII_OOB_CTRL);
- if (phydev->link) {
reg = bcmgenet_umac_readl(priv, UMAC_CMD);
reg &= ~((CMD_SPEED_MASK << CMD_SPEED_SHIFT) |
CMD_HD_EN |
CMD_RX_PAUSE_IGNORE | CMD_TX_PAUSE_IGNORE);
reg |= cmd_bits;
bcmgenet_umac_writel(priv, reg, UMAC_CMD);
+ } else {
+ /* done if nothing has changed */
+ if (!status_changed)
+ return;
+ /* needed for MoCA fixed PHY to reflect correct link status */
+ netif_carrier_off(dev);
}
phy_print_status(phydev);
@@ -318,6 +330,12 @@ static int bcmgenet_mii_probe(struct net_device *dev)
/* Communicate the integrated PHY revision */
phy_flags = priv->gphy_rev;
+ /* Initialize link state variables that bcmgenet_mii_setup() uses */
+ priv->old_link = -1;
+ priv->old_speed = -1;
+ priv->old_duplex = -1;
+ priv->old_pause = -1;
+
phydev = of_phy_connect(dev, priv->phy_dn, bcmgenet_mii_setup,
phy_flags, priv->phy_interface);
if (!phydev) {
@@ -325,9 +343,6 @@ static int bcmgenet_mii_probe(struct net_device *dev)
return -ENODEV;
}
- priv->old_link = -1;
- priv->old_duplex = -1;
- priv->old_pause = -1;
priv->phydev = phydev;
/* Configure port multiplexer based on what the probed PHY device since
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: HW bridging support using notifiers?
From: Florian Fainelli @ 2014-10-03 19:06 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: netdev, davem, jiri, stephen, andy, tgraf, nbd, john.r.fastabend,
edumazet, vyasevic, buytenh, sfeldma, Jamal Hadi Salim
In-Reply-To: <20141003142215.GR17057@kvack.org>
Hi Benjamin,
On 10/03/2014 07:22 AM, Benjamin LaHaise wrote:
> Hi Florian et al,
>
> On Thu, Oct 02, 2014 at 06:48:57PM -0700, Florian Fainelli wrote:
>> Hi all,
>>
>> I am taking a look at adding HW bridging support to DSA, in way that's
>> usable outside of DSA.
>
> I've been working on support for the RTL8366S switch, and our work is
> directly overlapping here. I actually have something that is working at
> configuring port and tag based vlans on the RTL8366S. I'll try to clean
> up the code to post something for discussion over the next couple of days.
Cool, please do!
>
>> Lennert's approach in 2008 [1] looks conceptually good to me,as he
>> noted, it uses a bunch of new ndo's which is not only limiting to one
>> ndo implementer per struct net_device, but also is mostly consuming the
>> information from the bridge layer, while the ndo is an action
>
> I think having ndo implementer methods for hardware switch offloads makes
> more sense. Such a scheme is needed in order to implement the stacking of
> devices that is required in order to transparently handle configuration of
> vlans on switch ports where the 8021q device has to pass on the vlan tag
> to the switch device. The ndo methods do perform an action of causing the
> switch to be configured to match the bridge config. Additionally, they
> can be used to veto changes that cannot be offloaded to hardware -- this
> (configurable) behaviour is desired by some users of these APIs who wish
> to be made aware when a particuarly configuration is not supported by the
> underlying hardware.
Humm, that's a fair point, so not only would we want new NDOs, but we'd
also need to specify the return values (invalid, no space etc...).
As far as bridging alone is concerned (not including VLANs for now), I
don't think there are restrictions in terms of what the hardware can do,
since we mostly tell it to "group" N-ports together.
For VLANs, there should be a way for the switch driver to tell whether
that's supported or not.
>
>> So here's what I am up to now:
>>
>> - use the NETDEV_JOIN notifier to discover when a bridge port is added
>> - use the NETDEV_LEAVE notifier, still need to verify this does not
>> break netconsole as indicated in net/bridge/br_if.c
>> - use the NETDEV_CHANGEINFODATA notifier to notify about STP state changes
>
> To me, notifiers are the wrong model for join and leave. Implementing
> stacking on top of notifiers is somewhat more complicated. Here are the
> ndo methods I've implemented so far which are sufficient for basic config
> of the RTL8366S. They're fairly similar to those in [1].
>
> + int (*ndo_join_bridge)(struct net_bridge *bridge,
> + struct net_device *dev,
> + int *switch_nr,
> + int *switch_port_nr,
> + int vlan);
> + int (*ndo_leave_bridge)(struct net_bridge *bridge,
> + struct net_device *dev,
> + int switch_nr,
> + int switch_port_nr,
> + int vlan);
> + int (*ndo_flood_xmit)(struct switch_info *dev,
> + struct sk_buff *skb,
> + u64 port_mask);
I don't think the switch_port_nr belongs here, this is something that
should be resolved within the implementer of these ndo's, whether that
is DSA, or Jiri's switchdev, since the net_device argument should be
linked to both the switch port number, and the switch number.
>
> There are a couple of important points here. In the case of joining and
> leaving a bridge, the bridge needs to be provided with information it can
> use to identify switch ports. This is needed in order to offload the
> flooding of packets to multiple ports, as otherwise the Linux bridge code
> doesn't have any way to figure out which packets can be merged into a
> single transmit via the ndo_flood_xmit() method.
I am not exactly sure yet how ndo_flood_xmit() fits in the picture here,
but it might be optional based on how the switch has been configured I
presume?
>
>> Now, this raises a bunch of questions:
>>
>> - we would need a getter to return the stp state of a given network
>> device when called with NETDEV_CHANGEINFODATA, is that acceptable? This
>> would be the first function exported by the bridge layer to expose
>> internal data
>
> I have yet to dig into STP, so I'll refrain from commenting on these parts
> for now.
The idea is to use the Linux STP result and apply the results to the
bridge port/switch ports members directly, since switches (at least
those from Marvell and Broadcom) have that semantic built into their
hardware logic.
>
>> NB: this also raises the question of the race condition and locking
>> within br_set_stp_state() and when the network devices notifier callback
>> runs
> U
>> - or do we need a new network device notifier accepting an opaque
>> pointer which could provide us with the data we what, something like
>> this: call_netdevices_notifier_data(NETDEV_CHANGEINFODATA, dev, info),
>> where info would be a structure/union telling what's this data about
>>
>> Let me know what you think, thanks!
>>
>> [1]: http://patchwork.ozlabs.org/patch/16578/
>
> Thanks for the pointer to this. Cheers!
>
> -ben
>
>> --
>> Florian
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] sunvnet: Packet processing in non-interrupt context.
From: David Miller @ 2014-10-03 19:08 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: raghuram.kothakota, netdev
In-Reply-To: <20141003144024.GA12448@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Fri, 3 Oct 2014 10:40:24 -0400
> On (10/02/14 13:43), David Miller wrote:
>> For example, you can now move everything into software IRQ context,
>> just disable the VIO interrupt and unconditionally go into NAPI
>> context from the VIO event.
>> No more irqsave/irqrestore.
>> Then the TX path even can run mostly lockless, it just needs
>> to hold the VIO lock for a minute period of time. The caller
>> holds the xmit_lock of the network device to prevent re-entry
>> into the ->ndo_start_xmit() path.
>>
>
> let me check into this and get back. I think the xmit path
> may also need to have some kind of locking for the dring access
> and ldc_write? I think you are suggesting that I should also
> move the control-packet processing to vnet_event_napi(), which
> I have not done in my patch. I will examine where that leads.
I think you should be able to get rid of all of the in-driver
locking in the fast paths.
NAPI ->poll() is non-reentrant, so all RX processing occurs
strictly in a serialized environment.
Once you do TX reclaim in NAPI context, then all you have to do is
take the generic netdev TX queue lock during the evaluation of whether
to wakeup the TX queue or not. Worst case you need to hold the
TX netdev queue lock across the whole TX reclaim operation.
The VIO lock really ought to be entirely superfluous in the data
paths.
^ permalink raw reply
* [PATCH net-next 1/1] net: fec: fix build error at m68k platform
From: Frank Li @ 2014-10-03 19:00 UTC (permalink / raw)
To: davem, lznuaa; +Cc: netdev, b38611, Frank Li
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1b7bde6d659d30f171259cc2dfba8e5dab34e735
# save the attached .config to linux build tree
make.cross ARCH=m68k
All error/warnings:
drivers/net/ethernet/freescale/fec_main.c: In function 'fec_enet_rx_queue':
>> drivers/net/ethernet/freescale/fec_main.c:1470:3: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
prefetch(skb->data - NET_IP_ALIGN);
^
cc1: some warnings being treated as errors
missed included prefetch.h
Signed-off-by: Frank Li <Frank.Li@freescale.com>
---
drivers/net/ethernet/freescale/fec_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 1f07db8..e190eb0 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -57,6 +57,7 @@
#include <linux/regulator/consumer.h>
#include <linux/if_vlan.h>
#include <linux/pinctrl/consumer.h>
+#include <linux/prefetch.h>
#include <asm/cacheflush.h>
--
1.9.1
^ permalink raw reply related
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