* Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree
From: Greg Kroah-Hartman @ 2017-09-06 12:17 UTC (permalink / raw)
To: Jonas Gorski
Cc: MIPS Mailing List, linux-arm-kernel@lists.infradead.org,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
Network Development, Rob Herring, Mark Rutland, Ralf Baechle,
Florian Fainelli, bcm-kernel-feedback-list, Kevin Cernekee,
Jiri Slaby, David S. Miller, Russell King
In-Reply-To: <CAOiHx=mC=GfX0VvuRWR-AmXYfVOEkuruwGHooS08WrL_z-60UA@mail.gmail.com>
On Wed, Sep 06, 2017 at 01:01:32PM +0200, Jonas Gorski wrote:
> Hi Greg,
>
> On 2 August 2017 at 11:34, Jonas Gorski <jonas.gorski@gmail.com> wrote:
> > Codify using a named clock for the refclk of the uart. This makes it
> > easier if we might need to add a gating clock (like present on the
> > BCM6345).
> >
> > Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
>
> Could I please get a (N)Ack so Ralf can add this patch to his tree?
>
>
> Regards
> Jonas
>
>
> > ---
> > Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt | 6 ++++++
> > drivers/tty/serial/bcm63xx_uart.c | 6 ++++--
> > 2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt
> > index 5c52e5eef16d..8b2b0460259a 100644
> > --- a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt
> > +++ b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt
> > @@ -11,6 +11,11 @@ Required properties:
> > - clocks: Clock driving the hardware; used to figure out the baud rate
> > divisor.
> >
> > +
> > +Optional properties:
> > +
> > +- clock-names: Should be "refclk".
> > +
> > Example:
> >
> > uart0: serial@14e00520 {
> > @@ -19,6 +24,7 @@ Example:
> > interrupt-parent = <&periph_intc>;
> > interrupts = <2>;
> > clocks = <&periph_clk>;
> > + clock-names = "refclk";
> > };
> >
> > clocks {
I don't ack devtree changes :)
> > diff --git a/drivers/tty/serial/bcm63xx_uart.c b/drivers/tty/serial/bcm63xx_uart.c
> > index a2b9376ec861..f227eff28d3a 100644
> > --- a/drivers/tty/serial/bcm63xx_uart.c
> > +++ b/drivers/tty/serial/bcm63xx_uart.c
> > @@ -841,8 +841,10 @@ static int bcm_uart_probe(struct platform_device *pdev)
> > if (!res_irq)
> > return -ENODEV;
> >
> > - clk = pdev->dev.of_node ? of_clk_get(pdev->dev.of_node, 0) :
> > - clk_get(&pdev->dev, "refclk");
> > + clk = clk_get(&pdev->dev, "refclk");
> > + if (IS_ERR(clk) && pdev->dev.of_node)
> > + clk = of_clk_get(pdev->dev.of_node, 0);
> > +
> > if (IS_ERR(clk))
> > return -ENODEV;
> >
This part is fine with me:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* hung task in mac80211
From: Matteo Croce @ 2017-09-06 11:57 UTC (permalink / raw)
To: linux-wireless, netdev, linux-kernel
Hi,
I have an hung task on vanilla 4.13 kernel which I haven't on 4.12.
The problem is present both on my AP and on my notebook,
so it seems it affects AP and STA mode as well.
The generated messages are:
INFO: task kworker/u16:6:120 blocked for more than 120 seconds.
Not tainted 4.13.0 #57
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u16:6 D 0 120 2 0x00000000
Workqueue: phy0 ieee80211_ba_session_work [mac80211]
Call Trace:
? __schedule+0x174/0x5b0
? schedule+0x31/0x80
? schedule_preempt_disabled+0x9/0x10
? __mutex_lock.isra.2+0x163/0x480
? select_task_rq_fair+0xb9f/0xc60
? __ieee80211_start_rx_ba_session+0x135/0x4d0 [mac80211]
? __ieee80211_start_rx_ba_session+0x135/0x4d0 [mac80211]
? try_to_wake_up+0x1f1/0x340
? update_curr+0x88/0xd0
? ieee80211_ba_session_work+0x148/0x230 [mac80211]
? process_one_work+0x1a5/0x330
? worker_thread+0x42/0x3c0
? create_worker+0x170/0x170
? kthread+0x10d/0x130
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x22/0x30
I did a bisect and the offending commit is:
commit 699cb58c8a52ff39bf659bff7971893ebe111bf2
Author: Johannes Berg <johannes.berg@intel.com>
Date: Tue May 30 16:34:46 2017 +0200
mac80211: manage RX BA session offload without SKB queue
Instead of using the SKB queue with the fake pkt_type for the
offloaded RX BA session management, also handle this with the
normal aggregation state machine worker. This also makes the
use of this more reliable since it gets rid of the allocation
of the fake skb.
Combined with the previous patch, this finally allows us to
get rid of the pkt_type hack entirely, so do that as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Regards,
--
Matteo Croce
per aspera ad upstream
^ permalink raw reply
* [patch net] net: sched: fix memleak for chain zero
From: Jiri Pirko @ 2017-09-06 11:14 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, kubakici, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
There's a memleak happening for chain 0. The thing is, chain 0 needs to
be always present, not created on demand. Therefore tcf_block_get upon
creation of block calls the tcf_chain_create function directly. The
chain is created with refcnt == 1, which is not correct in this case and
causes the memleak. So move the refcnt increment into tcf_chain_get
function even for the case when chain needs to be created.
Reported-by: Jakub Kicinski <kubakici@wp.pl>
Fixes: 5bc1701881e3 ("net: sched: introduce multichain support for filters")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/cls_api.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 6c5ea84..30ef466 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -197,7 +197,7 @@ static struct tcf_chain *tcf_chain_create(struct tcf_block *block,
list_add_tail(&chain->list, &block->chain_list);
chain->block = block;
chain->index = chain_index;
- chain->refcnt = 1;
+ chain->refcnt = 0;
return chain;
}
@@ -232,15 +232,15 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 chain_index,
struct tcf_chain *chain;
list_for_each_entry(chain, &block->chain_list, list) {
- if (chain->index == chain_index) {
- chain->refcnt++;
- return chain;
- }
+ if (chain->index == chain_index)
+ goto incref;
}
- if (create)
- return tcf_chain_create(block, chain_index);
- else
- return NULL;
+ chain = create ? tcf_chain_create(block, chain_index) : NULL;
+
+incref:
+ if (chain)
+ chain->refcnt++;
+ return chain;
}
EXPORT_SYMBOL(tcf_chain_get);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Yang, Yi @ 2017-09-06 11:03 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, e@erig.me
In-Reply-To: <87o9qo9ru6.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
On Wed, Sep 06, 2017 at 04:03:29PM +0800, Hannes Frederic Sowa wrote:
> "Yang, Yi" <yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes:
> >>
> >> > If you check GENEVE implementation, tun_metadata* can be set or matched
> >> > as any other match field.
> >>
> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata
> >> is not in tun_metadata as well?
> >
> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is
> > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a
> > lot of rework on tun_metadata to make it shared between GENEVE and NSH,
> > I don't think this can happen in near term. So tun_metadata isn't option
> > for this now.
>
> Sorry, I couldn't follow you. Why can't you store the context headers in
> tun_metadata exactly?
tun_metadata can work only if in_port and out_port are GENEVE tunnel
port, it is designed specially for GENEVE, Eth+NSH can work without
any tunnel port involved, context headers for NSH are not tunnel
metadata, they aren't tunnel-specific, you can't treat them as same
thing. In addtition, tun_metadata also can be matched and set, they have
the same issue as you concern.
>
> [...]
>
> Bye,
> Hannes
^ permalink raw reply
* Re: [PATCH 4/8] tty/bcm63xx_uart: allow naming clock in device tree
From: Jonas Gorski @ 2017-09-06 11:01 UTC (permalink / raw)
To: MIPS Mailing List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Ralf Baechle,
Florian Fainelli, bcm-kernel-feedback-list, Kevin Cernekee,
Jiri Slaby, David S. Miller, Russell King
In-Reply-To: <20170802093429.12572-5-jonas.gorski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Greg,
On 2 August 2017 at 11:34, Jonas Gorski <jonas.gorski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Codify using a named clock for the refclk of the uart. This makes it
> easier if we might need to add a gating clock (like present on the
> BCM6345).
>
> Signed-off-by: Jonas Gorski <jonas.gorski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Could I please get a (N)Ack so Ralf can add this patch to his tree?
Regards
Jonas
> ---
> Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt | 6 ++++++
> drivers/tty/serial/bcm63xx_uart.c | 6 ++++--
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt
> index 5c52e5eef16d..8b2b0460259a 100644
> --- a/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt
> +++ b/Documentation/devicetree/bindings/serial/brcm,bcm6345-uart.txt
> @@ -11,6 +11,11 @@ Required properties:
> - clocks: Clock driving the hardware; used to figure out the baud rate
> divisor.
>
> +
> +Optional properties:
> +
> +- clock-names: Should be "refclk".
> +
> Example:
>
> uart0: serial@14e00520 {
> @@ -19,6 +24,7 @@ Example:
> interrupt-parent = <&periph_intc>;
> interrupts = <2>;
> clocks = <&periph_clk>;
> + clock-names = "refclk";
> };
>
> clocks {
> diff --git a/drivers/tty/serial/bcm63xx_uart.c b/drivers/tty/serial/bcm63xx_uart.c
> index a2b9376ec861..f227eff28d3a 100644
> --- a/drivers/tty/serial/bcm63xx_uart.c
> +++ b/drivers/tty/serial/bcm63xx_uart.c
> @@ -841,8 +841,10 @@ static int bcm_uart_probe(struct platform_device *pdev)
> if (!res_irq)
> return -ENODEV;
>
> - clk = pdev->dev.of_node ? of_clk_get(pdev->dev.of_node, 0) :
> - clk_get(&pdev->dev, "refclk");
> + clk = clk_get(&pdev->dev, "refclk");
> + if (IS_ERR(clk) && pdev->dev.of_node)
> + clk = of_clk_get(pdev->dev.of_node, 0);
> +
> if (IS_ERR(clk))
> return -ENODEV;
>
> --
> 2.13.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/8] bcm63xx_enet: just use "enet" as the clock name
From: Jonas Gorski @ 2017-09-06 11:00 UTC (permalink / raw)
To: MIPS Mailing List, linux-arm-kernel@lists.infradead.org,
linux-serial@vger.kernel.org, devicetree@vger.kernel.org,
Network Development
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Ralf Baechle,
Florian Fainelli, bcm-kernel-feedback-list, Kevin Cernekee,
Jiri Slaby, David S. Miller, Russell King
In-Reply-To: <20170802093429.12572-7-jonas.gorski@gmail.com>
Hi David,
On 2 August 2017 at 11:34, Jonas Gorski <jonas.gorski@gmail.com> wrote:
> Now that we have the individual clocks available as "enet" we
> don't need to rely on the device id for them anymore.
>
> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Could I please get a (N)Ack so Ralf can add this patch to his tree?
Regards
Jonas
> ---
> drivers/net/ethernet/broadcom/bcm63xx_enet.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
> index 61a88b64bd39..d6844923a1c0 100644
> --- a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
> +++ b/drivers/net/ethernet/broadcom/bcm63xx_enet.c
> @@ -1718,7 +1718,6 @@ static int bcm_enet_probe(struct platform_device *pdev)
> struct bcm63xx_enet_platform_data *pd;
> struct resource *res_mem, *res_irq, *res_irq_rx, *res_irq_tx;
> struct mii_bus *bus;
> - const char *clk_name;
> int i, ret;
>
> /* stop if shared driver failed, assume driver->probe will be
> @@ -1761,14 +1760,12 @@ static int bcm_enet_probe(struct platform_device *pdev)
> if (priv->mac_id == 0) {
> priv->rx_chan = 0;
> priv->tx_chan = 1;
> - clk_name = "enet0";
> } else {
> priv->rx_chan = 2;
> priv->tx_chan = 3;
> - clk_name = "enet1";
> }
>
> - priv->mac_clk = clk_get(&pdev->dev, clk_name);
> + priv->mac_clk = clk_get(&pdev->dev, "enet");
> if (IS_ERR(priv->mac_clk)) {
> ret = PTR_ERR(priv->mac_clk);
> goto out;
> --
> 2.13.2
>
^ permalink raw reply
* Re: [net 0/2][pull request] Intel Wired LAN Driver Updates 2017-09-05
From: Stefano Brivio @ 2017-09-06 10:55 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20170906010418.39007-1-jeffrey.t.kirsher@intel.com>
On Tue, 5 Sep 2017 18:04:16 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> This series contains fixes for i40e only.
>
> These two patches fix an issue where our nvmupdate tool does not work on RHEL 7.4
> and newer kernels, in fact, the use of the nvmupdate tool on newer kernels can
> cause the cards to be non-functional unless these patches are applied.
>
> Anjali reworks the locking around accessing the NVM so that NVM acquire timeouts
> do not occur which was causing the failed firmware updates.
>
> Jake correctly updates the wb_desc when reading the NVM through the AdminQ.
>
> The following are changes since commit 6d9c153a0b84392406bc77600aa7d3ea365de041:
> net: dsa: loop: Do not unregister invalid fixed PHY
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue 40GbE
>
> Anjali Singhai Jain (1):
> i40e: avoid NVM acquire deadlock during NVM update
>
> Jacob Keller (1):
> i40e: point wb_desc at the nvm_wb_desc during i40e_read_nvm_aq
I think this should go to -stable too (4.12+), as cards completely
stop working after a firmware upgrade.
^ permalink raw reply
* [PATCH net 3/4] lan78xx: Fix for eeprom read/write when device autosuspend
From: Nisar.Sayed @ 2017-09-06 10:51 UTC (permalink / raw)
To: davem, UNGLinuxDriver; +Cc: netdev
From: Nisar Sayed <Nisar.Sayed@microchip.com>
Fix for eeprom read/write when device autosuspend
Signed-off-by: Nisar Sayed <Nisar.Sayed@microchip.com>
---
drivers/net/usb/lan78xx.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 6242cb7..e04ec23 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1278,30 +1278,48 @@ static int lan78xx_ethtool_get_eeprom(struct net_device *netdev,
struct ethtool_eeprom *ee, u8 *data)
{
struct lan78xx_net *dev = netdev_priv(netdev);
+ int ret = -EINVAL;
+
+ if (usb_autopm_get_interface(dev->intf) < 0)
+ return ret;
ee->magic = LAN78XX_EEPROM_MAGIC;
- return lan78xx_read_raw_eeprom(dev, ee->offset, ee->len, data);
+ ret = lan78xx_read_raw_eeprom(dev, ee->offset, ee->len, data);
+
+ usb_autopm_put_interface(dev->intf);
+
+ return ret;
}
static int lan78xx_ethtool_set_eeprom(struct net_device *netdev,
struct ethtool_eeprom *ee, u8 *data)
{
struct lan78xx_net *dev = netdev_priv(netdev);
+ int ret = -EINVAL;
+
+ if (usb_autopm_get_interface(dev->intf) < 0)
+ return ret;
/* Allow entire eeprom update only */
if ((ee->magic == LAN78XX_EEPROM_MAGIC) &&
(ee->offset == 0) &&
(ee->len == 512) &&
(data[0] == EEPROM_INDICATOR))
- return lan78xx_write_raw_eeprom(dev, ee->offset, ee->len, data);
+ ret = lan78xx_write_raw_eeprom(dev, ee->offset, ee->len, data);
else if ((ee->magic == LAN78XX_OTP_MAGIC) &&
(ee->offset == 0) &&
(ee->len == 512) &&
(data[0] == OTP_INDICATOR_1))
- return lan78xx_write_raw_otp(dev, ee->offset, ee->len, data);
+ ret = lan78xx_write_raw_otp(dev, ee->offset, ee->len, data);
+ else if ((ee->magic == LAN78XX_EEPROM_MAGIC) &&
+ (ee->offset >= 0 && ee->offset < MAX_EEPROM_SIZE) &&
+ (ee->len > 0 && (ee->offset + ee->len) <= MAX_EEPROM_SIZE))
+ ret = lan78xx_write_raw_eeprom(dev, ee->offset, ee->len, data);
- return -EINVAL;
+ usb_autopm_put_interface(dev->intf);
+
+ return ret;
}
static void lan78xx_get_strings(struct net_device *netdev, u32 stringset,
--
1.9.1
^ permalink raw reply related
* [PATCH net 4/4] lan78xx: Use default value loaded from EEPROM/OTP when resetting the chip
From: Nisar.Sayed @ 2017-09-06 10:52 UTC (permalink / raw)
To: davem, UNGLinuxDriver; +Cc: netdev
From: Nisar Sayed <Nisar.Sayed@microchip.com>
Use default value loaded from EEPROM/OTP when resetting
the chip
Signed-off-by: Nisar Sayed <Nisar.Sayed@microchip.com>
---
drivers/net/usb/lan78xx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index e04ec23..84491e7 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2497,7 +2497,6 @@ static int lan78xx_reset(struct lan78xx_net *dev)
/* LAN7801 only has RGMII mode */
if (dev->chipid == ID_REV_CHIP_ID_7801_)
buf &= ~MAC_CR_GMII_EN_;
- buf |= MAC_CR_AUTO_DUPLEX_ | MAC_CR_AUTO_SPEED_;
ret = lan78xx_write_reg(dev, MAC_CR, buf);
ret = lan78xx_read_reg(dev, MAC_TX, &buf);
--
1.9.1
^ permalink raw reply related
* [PATCH net 1/4] lan78xx: Fix for crash associated with System suspend
From: Nisar.Sayed @ 2017-09-06 10:51 UTC (permalink / raw)
To: davem, UNGLinuxDriver; +Cc: netdev
From: Nisar Sayed <Nisar.Sayed@microchip.com>
Fix for crash associated with System suspend
Since ndo_stop removes phydev which makes phydev NULL.
Whenever system suspend is initiated or after "ifconfig <interface> down",
if set_wol or get_wol is triggered phydev is NULL leads system crash.
Hence phy_start/phy_stop for ndo_start/ndo_stop fixes the issues
instead of adding/removing phydevice
Signed-off-by: Nisar Sayed <Nisar.Sayed@microchip.com>
---
drivers/net/usb/lan78xx.c | 44 ++++++++++++++++++++++++++++----------------
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index b99a7fb..955ab3b 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -2024,6 +2024,8 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
lan8835_fixup);
if (ret < 0) {
netdev_err(dev->net, "fail to register fixup\n");
+ phy_unregister_fixup_for_uid(PHY_KSZ9031RNX,
+ 0xfffffff0);
return ret;
}
/* add more external PHY fixup here if needed */
@@ -2031,8 +2033,7 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
phydev->is_internal = false;
} else {
netdev_err(dev->net, "unknown ID found\n");
- ret = -EIO;
- goto error;
+ return -EIO;
}
/* if phyirq is not set, use polling mode in phylib */
@@ -2051,7 +2052,10 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
if (ret) {
netdev_err(dev->net, "can't attach PHY to %s\n",
dev->mdiobus->id);
- return -EIO;
+ ret = -EIO;
+ if (dev->chipid == ID_REV_CHIP_ID_7801_)
+ goto error;
+ return ret;
}
/* MAC doesn't support 1000T Half */
@@ -2067,8 +2071,6 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
dev->fc_autoneg = phydev->autoneg;
- phy_start(phydev);
-
netif_dbg(dev, ifup, dev->net, "phy initialised successfully");
return 0;
@@ -2497,9 +2499,9 @@ static int lan78xx_open(struct net_device *net)
if (ret < 0)
goto done;
- ret = lan78xx_phy_init(dev);
- if (ret < 0)
- goto done;
+ if (dev->domain_data.phyirq > 0)
+ phy_start_interrupts(dev->net->phydev);
+ phy_start(dev->net->phydev);
/* for Link Check */
if (dev->urb_intr) {
@@ -2560,13 +2562,11 @@ static int lan78xx_stop(struct net_device *net)
if (timer_pending(&dev->stat_monitor))
del_timer_sync(&dev->stat_monitor);
- phy_unregister_fixup_for_uid(PHY_KSZ9031RNX, 0xfffffff0);
- phy_unregister_fixup_for_uid(PHY_LAN8835, 0xfffffff0);
-
- phy_stop(net->phydev);
- phy_disconnect(net->phydev);
-
- net->phydev = NULL;
+ if (net->phydev) {
+ if (dev->domain_data.phyirq > 0)
+ phy_stop_interrupts(net->phydev);
+ phy_stop(net->phydev);
+ }
clear_bit(EVENT_DEV_OPEN, &dev->flags);
netif_stop_queue(net);
@@ -3464,6 +3464,12 @@ static void lan78xx_disconnect(struct usb_interface *intf)
udev = interface_to_usbdev(intf);
net = dev->net;
+ if (dev->chipid == ID_REV_CHIP_ID_7801_) {
+ phy_unregister_fixup_for_uid(PHY_KSZ9031RNX, 0xfffffff0);
+ phy_unregister_fixup_for_uid(PHY_LAN8835, 0xfffffff0);
+ }
+ phy_disconnect(net->phydev);
+ net->phydev = NULL;
unregister_netdev(net);
cancel_delayed_work_sync(&dev->wq);
@@ -3613,6 +3619,10 @@ static int lan78xx_probe(struct usb_interface *intf,
goto out3;
}
+ ret = lan78xx_phy_init(dev);
+ if (ret < 0)
+ goto out3;
+
usb_set_intfdata(intf, dev);
ret = device_set_wakeup_enable(&udev->dev, true);
@@ -3972,7 +3982,9 @@ static int lan78xx_reset_resume(struct usb_interface *intf)
lan78xx_reset(dev);
- lan78xx_phy_init(dev);
+ if (dev->domain_data.phyirq > 0)
+ phy_start_interrupts(dev->net->phydev);
+ phy_start(dev->net->phydev);
return lan78xx_resume(intf);
}
--
1.9.1
^ permalink raw reply related
* [PATCH net 2/4] lan78xx: Add fixed_phy device support for LAN7801 device
From: Nisar.Sayed @ 2017-09-06 10:51 UTC (permalink / raw)
To: davem, UNGLinuxDriver; +Cc: netdev
From: Nisar Sayed <Nisar.Sayed@microchip.com>
Add fixed_phy device support for LAN7801 device
When LAN7801 device connected to PHY Device which does not have
MDIO/MDC access, fixex_phy device will be added.
Signed-off-by: Nisar Sayed <Nisar.Sayed@microchip.com>
---
drivers/net/usb/Kconfig | 10 ++++++++
drivers/net/usb/lan78xx.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index f28bd74..34ef670 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -123,6 +123,16 @@ config USB_LAN78XX
To compile this driver as a module, choose M here: the
module will be called lan78xx.
+ if USB_LAN78XX
+ config LAN7801_NO_MDIO_DEVICE
+ bool "NO MDIO Device Support"
+ select FIXED_PHY
+ ---help---
+ If LAN7801 connected to a PHY device which does not
+ have MDIO/MDC access this option adds support to LAN7801
+ with fixed_phy support
+ endif
+
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
select MII
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 955ab3b..6242cb7 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -30,6 +30,7 @@
#include <linux/ipv6.h>
#include <linux/mdio.h>
#include <linux/phy.h>
+#include <linux/phy_fixed.h>
#include <net/ip6_checksum.h>
#include <linux/interrupt.h>
#include <linux/irqdomain.h>
@@ -42,7 +43,7 @@
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
#define DRIVER_DESC "LAN78XX USB 3.0 Gigabit Ethernet Devices"
#define DRIVER_NAME "lan78xx"
-#define DRIVER_VERSION "1.0.6"
+#define DRIVER_VERSION "1.0.7"
#define TX_TIMEOUT_JIFFIES (5 * HZ)
#define THROTTLE_JIFFIES (HZ / 8)
@@ -335,6 +336,7 @@ struct statstage {
struct lan78xx_statstage64 curr_stat;
};
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
struct irq_domain_data {
struct irq_domain *irqdomain;
unsigned int phyirq;
@@ -343,6 +345,7 @@ struct irq_domain_data {
u32 irqenable;
struct mutex irq_lock; /* for irq bus access */
};
+#endif
struct lan78xx_net {
struct net_device *net;
@@ -401,7 +404,9 @@ struct lan78xx_net {
int delta;
struct statstage stats;
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
struct irq_domain_data domain_data;
+#endif
};
/* define external phy id */
@@ -1169,6 +1174,9 @@ static int lan78xx_link_reset(struct lan78xx_net *dev)
ret = lan78xx_write_reg(dev, MAC_CR, buf);
if (unlikely(ret < 0))
return -EIO;
+#ifdef CONFIG_LAN7801_NO_MDIO_DEVICE
+ phy_mac_interrupt(phydev, 0);
+#endif
del_timer(&dev->stat_monitor);
} else if (phydev->link && !dev->link_on) {
@@ -1209,6 +1217,9 @@ static int lan78xx_link_reset(struct lan78xx_net *dev)
ret = lan78xx_update_flowcontrol(dev, ecmd.base.duplex, ladv,
radv);
+#ifdef CONFIG_LAN7801_NO_MDIO_DEVICE
+ phy_mac_interrupt(phydev, 1);
+#endif
if (!timer_pending(&dev->stat_monitor)) {
dev->delta = 1;
@@ -1249,8 +1260,10 @@ static void lan78xx_status(struct lan78xx_net *dev, struct urb *urb)
netif_dbg(dev, link, dev->net, "PHY INTR: 0x%08x\n", intdata);
lan78xx_defer_kevent(dev, EVENT_LINK_RESET);
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
if (dev->domain_data.phyirq > 0)
generic_handle_irq(dev->domain_data.phyirq);
+#endif
} else
netdev_warn(dev->net,
"unexpected interrupt: 0x%08x\n", intdata);
@@ -1825,6 +1838,7 @@ static void lan78xx_link_status_change(struct net_device *net)
}
}
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
static int irq_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hwirq)
{
@@ -1945,6 +1959,7 @@ static void lan78xx_remove_irq_domain(struct lan78xx_net *dev)
dev->domain_data.phyirq = 0;
dev->domain_data.irqdomain = NULL;
}
+#endif
static int lan8835_fixup(struct phy_device *phydev)
{
@@ -1987,12 +2002,37 @@ static int ksz9031rnx_fixup(struct phy_device *phydev)
return 1;
}
+#ifdef CONFIG_LAN7801_NO_MDIO_DEVICE
+static struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+};
+#endif
+
static int lan78xx_phy_init(struct lan78xx_net *dev)
{
int ret;
u32 mii_adv;
struct phy_device *phydev = dev->net->phydev;
+#ifdef CONFIG_LAN7801_NO_MDIO_DEVICE
+ if (dev->chipid != ID_REV_CHIP_ID_7801_) {
+ netdev_err(dev->net, "Invalid chip id : %x\n", dev->chipid);
+ return -EIO;
+ }
+ phydev = fixed_phy_register(PHY_POLL, &fphy_status,
+ -1, NULL);
+ if (IS_ERR(phydev)) {
+ netdev_err(dev->net, "LAN7801 Fixed PHY register failed\n");
+ return -EIO;
+ }
+ netdev_info(dev->net, "LAN7801 fixed PHY registered\n");
+
+ dev->interface = PHY_INTERFACE_MODE_RGMII;
+
+ phydev->irq = PHY_IGNORE_INTERRUPT;
+#else
phydev = phy_find_first(dev->mdiobus);
if (!phydev) {
netdev_err(dev->net, "no PHY found\n");
@@ -2041,6 +2081,7 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
phydev->irq = dev->domain_data.phyirq;
else
phydev->irq = 0;
+#endif
netdev_dbg(dev->net, "phydev->irq = %d\n", phydev->irq);
/* set to AUTOMDIX */
@@ -2053,8 +2094,10 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
netdev_err(dev->net, "can't attach PHY to %s\n",
dev->mdiobus->id);
ret = -EIO;
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
if (dev->chipid == ID_REV_CHIP_ID_7801_)
goto error;
+#endif
return ret;
}
@@ -2499,8 +2542,10 @@ static int lan78xx_open(struct net_device *net)
if (ret < 0)
goto done;
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
if (dev->domain_data.phyirq > 0)
phy_start_interrupts(dev->net->phydev);
+#endif
phy_start(dev->net->phydev);
/* for Link Check */
@@ -2563,8 +2608,10 @@ static int lan78xx_stop(struct net_device *net)
del_timer_sync(&dev->stat_monitor);
if (net->phydev) {
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
if (dev->domain_data.phyirq > 0)
phy_stop_interrupts(net->phydev);
+#endif
phy_stop(net->phydev);
}
@@ -2844,6 +2891,7 @@ static int lan78xx_bind(struct lan78xx_net *dev, struct usb_interface *intf)
dev->net->hw_features = dev->net->features;
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
ret = lan78xx_setup_irq_domain(dev);
if (ret < 0) {
netdev_warn(dev->net,
@@ -2851,6 +2899,7 @@ static int lan78xx_bind(struct lan78xx_net *dev, struct usb_interface *intf)
kfree(pdata);
return ret;
}
+#endif
dev->net->hard_header_len += TX_OVERHEAD;
dev->hard_mtu = dev->net->mtu + dev->net->hard_header_len;
@@ -2871,8 +2920,10 @@ static void lan78xx_unbind(struct lan78xx_net *dev, struct usb_interface *intf)
{
struct lan78xx_priv *pdata = (struct lan78xx_priv *)(dev->data[0]);
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
lan78xx_remove_irq_domain(dev);
+#endif
lan78xx_remove_mdio(dev);
if (pdata) {
@@ -3464,11 +3515,15 @@ static void lan78xx_disconnect(struct usb_interface *intf)
udev = interface_to_usbdev(intf);
net = dev->net;
+#ifdef CONFIG_LAN7801_NO_MDIO_DEVICE
+ fixed_phy_unregister(net->phydev);
+#else
if (dev->chipid == ID_REV_CHIP_ID_7801_) {
phy_unregister_fixup_for_uid(PHY_KSZ9031RNX, 0xfffffff0);
phy_unregister_fixup_for_uid(PHY_LAN8835, 0xfffffff0);
}
phy_disconnect(net->phydev);
+#endif
net->phydev = NULL;
unregister_netdev(net);
@@ -3982,8 +4037,10 @@ static int lan78xx_reset_resume(struct usb_interface *intf)
lan78xx_reset(dev);
+#ifndef CONFIG_LAN7801_NO_MDIO_DEVICE
if (dev->domain_data.phyirq > 0)
phy_start_interrupts(dev->net->phydev);
+#endif
phy_start(dev->net->phydev);
return lan78xx_resume(intf);
--
1.9.1
^ permalink raw reply related
* [PATCH net 0/4] lan78xx: Fixes and Enhancements to lan78xx driver
From: Nisar.Sayed @ 2017-09-06 10:49 UTC (permalink / raw)
To: davem, UNGLinuxDriver; +Cc: netdev
From: Nisar Sayed <Nisar.Sayed@microchip.com>
This series of patches are for lan78xx driver.
These patches supports fixes and enhancements to lan78xx driver
Nisar Sayed (4):
Fix for crash associated with System suspend
Add fixed_phy device support for LAN7801 device
Fix for eeprom read/write when device autosuspend
Use default value loaded from EEPROM/OTP when resetting the chip
drivers/net/usb/Kconfig | 10 ++++
drivers/net/usb/lan78xx.c | 130 ++++++++++++++++++++++++++++++++++++++--------
2 files changed, 118 insertions(+), 22 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: ipset losing entries on its own
From: Denys Fedoryshchenko @ 2017-09-06 10:37 UTC (permalink / raw)
To: Akshat Kakkar; +Cc: netdev, netdev-owner
In-Reply-To: <CAA5aLPhEseXhOqSK=6K=5J2q-zn+8FpxhqOBV5NqCPNMAJqhow@mail.gmail.com>
On 2017-09-06 13:08, Akshat Kakkar wrote:
> I am having ipset 6.32
>
> The hash type is hash:ip
>
> I am adding/deleting IP addresses to it dynamically using scripts.
>
> However, it has been observed that at times few IPs (3-4 out of 4000)
> are not found in the set though it was added. Also, logs show there
> was not request for deletion of that IP from IPSet.
>
> Is it a bug?
I think you should try to make script to create at least reproducible
scenario
And sure post more info about your setup (kernel version, vanilla or
distro)
^ permalink raw reply
* Re: ipset losing entries on its own
From: Akshat Kakkar @ 2017-09-06 10:31 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAA5aLPhEseXhOqSK=6K=5J2q-zn+8FpxhqOBV5NqCPNMAJqhow@mail.gmail.com>
output of ipset -L -t
Name: STORE
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 50480
References: 1
^ permalink raw reply
* Re: [RFC net-next] net: sch_clsact: add support for global per-netns classifier mode
From: Nikolay Aleksandrov @ 2017-09-06 10:14 UTC (permalink / raw)
To: Daniel Borkmann, Roopa Prabhu, Cong Wang
Cc: Linux Kernel Network Developers, David Ahern, Jiri Pirko,
Jamal Hadi Salim
In-Reply-To: <59AF291E.90508@iogearbox.net>
On 06/09/17 01:45, Daniel Borkmann wrote:
> On 09/06/2017 12:01 AM, Roopa Prabhu wrote:
>> On Tue, Sep 5, 2017 at 11:18 AM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> On Tue, Sep 5, 2017 at 5:48 AM, Nikolay Aleksandrov
>>> <nikolay@cumulusnetworks.com> wrote:
>>>> Hi all,
>>>> This RFC adds a new mode for clsact which designates a device's egress
>>>> classifier as global per netns. The packets that are not classified for
>>>> a particular device will be classified using the global classifier.
>>>> We have needed a global classifier for some time now for various
>>>> purposes and setting the single bridge or loopback/vrf device as the
>
> Can you elaborate a bit more on the ... "we have needed a global
> classifier for some time now for various purposes".
>
>>>> global classifier device is acceptable for us. Doing it this way avoids
>>>> the act/cls device and queue dependencies.
>>>>
>>>> This is strictly an RFC patch just to show the intent, if we agree on
>>>> the details the proposed patch will have support for both ingress and
>>>> egress, and will be using a static key to avoid the fast path test when no
>>>> global classifier has been configured.
>>>>
>>>> Example (need a modified tc that adds TCA_OPTIONS when using q_clsact):
>>>> $ tc qdisc add dev lo clsact global
>>>> $ tc filter add dev lo egress protocol ip u32 match ip dst 4.3.2.1/32 action drop
>>>>
>>>> the last filter will be global for all devices that don't have a
>>>> specific egress_cl_list (i.e. have clsact configured).
>>>
>>> Sorry this is too ugly.
>
> +1
>
>>> netdevice is still implied in your command line even if you treat it
>>> as global. It is essentially hard to bypass netdevice layer since
>>> netdevice is the core of L2 and also where everything begins.
>>>
>>> Maybe the best we can do here is make tc filters standalone
>>> as tc actions so that filters can exist before qdisc's and netdevices.
>>> But this probably requires significant works to make it working
>>> with both existing non-standalone and bindings standalones
>>> with qdisc's.
>>
>> yes, like Nikolay says we have been discussing this as well. Nikolay's
>> patch is a cleaver and most importantly non-invasive
>> way today given the anchor point for tc rules is a netdev. we have
>> also considered a separate implicit tc anchor device.
>
> Seems ugly just as well. :( Hmm, why not just having the two list
> pointers (ingress, egress list) in the netns struct and when
> something configures them to be effectively non-zero, then devices
> in that netns could automatically get a clsact and inherit the
> lists from there such that sch_handle_ingress() and sch_handle_egress()
> require exactly zero changes in fast-path. You could then go and
> say that either you would make changes to clsact for individual
> devices immutable when they use the 'shared' list pointers, or then
> duplicate the configs when being altered from the global one. Would
> push the complexity to control path only at least. Just a brief
> thought.
Sure, this is a nice refinement, if we decide to continue with the idea of a global
clsact filter I'll push it all to the control path.
Thanks,
Nik
^ permalink raw reply
* ipset losing entries on its own
From: Akshat Kakkar @ 2017-09-06 10:08 UTC (permalink / raw)
To: netdev
I am having ipset 6.32
The hash type is hash:ip
I am adding/deleting IP addresses to it dynamically using scripts.
However, it has been observed that at times few IPs (3-4 out of 4000)
are not found in the set though it was added. Also, logs show there
was not request for deletion of that IP from IPSet.
Is it a bug?
^ permalink raw reply
* Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Hannes Frederic Sowa @ 2017-09-06 10:02 UTC (permalink / raw)
To: Jan Scheurich
Cc: Yang, Yi, netdev@vger.kernel.org, dev@openvswitch.org,
jbenc@redhat.com, e@erig.me, blp@ovn.org
In-Reply-To: <CFF8EF42F1132E4CBE2BF0AB6C21C58D787F5ECB@ESESSMB107.ericsson.se>
Jan Scheurich <jan.scheurich@ericsson.com> writes:
>> > There is no way we can re-use the existing TLV tunnel metadata
>> > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We
>> > will need to introduce a new (perhaps similar) scheme for modelling
>> > generic TLV match registers in OVS that are assigned to protocol TLVs
>> > by the controller. This is FFS.
>>
>> This is what I don't understand.
>>
>> Why can't you just reuse the space in the struct sw_flow_key where
>> geneve would put in their metadata. There are 255 empty bytes at the
>> beginning if you don't have other tunnel metadata anyway.
>>
>> If you receive packets over vxlan(gpe), tun_opts gets populated with an
>> ip_tunnel_key. Couldn't you use the options space in there after the
>> ip_tunnel_key to store the NSH context just for the sake of storing them
>> somewhere instead of adding 16 bytes to sw_flow_key?
>
> There is a significant conceptual difference between tunnel metadata
> (copied from a popped tunnel header) and packed match fields extracted
> during parsing of the packets. If we'd store them in the same space in
> the sw_flow_key struct, we are calling for trouble.
>
> NSH is transport agnostic, it should work over Ethernet, VXLAN(GPE)
> and other transport tunnels. Think about an NSH packet arriving on an
> Geneve tunnel port. Any Geneve tunnel options have already been stored
> in the tun_opts metadata bytes. Now the datapath parses the NSH header
> and overwrites the tun_opts metadata with the NSH metadata. This would
> break the OVS semantics.
Obviously you would use key->tun_opts_len and start appending there and
not simply overwrite. Otherwise that would be rather silly.
> I absolutely understand your concern about efficient space utilization
> in the flow struct for TLV match fields and it will be part of the
> design challenge for MD2 TLV support to find a good balance between
> memory and run-time efficiency. But that is FFS. For the four fixed
> size MD1 headers the decision has been to include them as additional
> attributes in the flow key.
Okay, then.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Jan Scheurich @ 2017-09-06 9:54 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, e@erig.me
In-Reply-To: <87bmmo9ngt.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
> > There is no way we can re-use the existing TLV tunnel metadata
> > infrastructure in OVS for matching and setting NSH MD2 TLV headers. We
> > will need to introduce a new (perhaps similar) scheme for modelling
> > generic TLV match registers in OVS that are assigned to protocol TLVs
> > by the controller. This is FFS.
>
> This is what I don't understand.
>
> Why can't you just reuse the space in the struct sw_flow_key where
> geneve would put in their metadata. There are 255 empty bytes at the
> beginning if you don't have other tunnel metadata anyway.
>
> If you receive packets over vxlan(gpe), tun_opts gets populated with an
> ip_tunnel_key. Couldn't you use the options space in there after the
> ip_tunnel_key to store the NSH context just for the sake of storing them
> somewhere instead of adding 16 bytes to sw_flow_key?
There is a significant conceptual difference between tunnel metadata (copied from a popped tunnel header) and packed match fields extracted during parsing of the packets. If we'd store them in the same space in the sw_flow_key struct, we are calling for trouble.
NSH is transport agnostic, it should work over Ethernet, VXLAN(GPE) and other transport tunnels. Think about an NSH packet arriving on an Geneve tunnel port. Any Geneve tunnel options have already been stored in the tun_opts metadata bytes. Now the datapath parses the NSH header and overwrites the tun_opts metadata with the NSH metadata. This would break the OVS semantics.
I absolutely understand your concern about efficient space utilization in the flow struct for TLV match fields and it will be part of the design challenge for MD2 TLV support to find a good balance between memory and run-time efficiency. But that is FFS. For the four fixed size MD1 headers the decision has been to include them as additional attributes in the flow key.
BR, Jan
^ permalink raw reply
* Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic
From: Nikolay Aleksandrov @ 2017-09-06 9:52 UTC (permalink / raw)
To: Stephen Hemminger, Andrew Lunn
Cc: netdev, jiri, Florian Fainelli, Vivien Didelot
In-Reply-To: <20170905171141.7040519b@xeon-e3>
On 06/09/17 03:11, Stephen Hemminger wrote:
> On Wed, 6 Sep 2017 01:35:02 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
>
>> After the very useful feedback from Nikolay, i threw away what i had,
>> and started again. To recap:
>>
>> The linux bridge supports IGMP snooping. It will listen to IGMP
>> reports on bridge ports and keep track of which groups have been
>> joined on an interface. It will then forward multicast based on this
>> group membership.
>>
>> When the bridge adds or removed groups from an interface, it uses
>> switchdev to request the hardware add an mdb to a port, so the
>> hardware can perform the selective forwarding between ports.
>>
>> What is not covered by the current bridge code, is IGMP joins/leaves
>> from the host on the brX interface. These are not reported via
>> switchdev so that hardware knows the local host is interested in the
>> multicast frames.
>>
>> Luckily, the bridge does track joins/leaves on the brX interface. The
>> code is obfusticated, which is why i missed it with my first attempt.
>> So the first patch tries to remove this obfustication. Currently,
>> there is no notifications sent when the bridge interface joins a
>> group. The second patch adds them. bridge monitor then shows
>> joins/leaves in the same way as for other ports of the bridge.
>>
>> Then starts the work passing down to the hardware that the host has
>> joined/left a group. The existing switchdev mdb object cannot be used,
>> since the semantics are different. The existing
>> SWITCHDEV_OBJ_ID_PORT_MDB is used to indicate a specific multicast
>> group should be forwarded out that port of the switch. However here we
>> require the exact opposite. We want multicast frames for the group
>> received on the port to the forwarded to the host. Hence add a new
>> object SWITCHDEV_OBJ_ID_HOST_MDB, a multicast database entry to
>> forward to the host. This new object is then propagated through the
>> DSA layers. No DSA driver changes should be needed, this should just
>> work...
>>
>> Getting the frames to the bridge as requested turned up an issue or
>> three. The offload_fwd_mark is not being set by DSA, so the bridge
>> floods the received frames back to the switch ports, resulting in
>> duplication since the hardware has already flooded the packet. Fixing
>> that turned up an issue with the meaning of
>> SWITCHDEV_ATTR_ID_PORT_PARENT_ID in DSA. A DSA fabric of three
>> switches needs to look to the software bridge as a single
>> switch. Otherwise the offload_fwd_mark does not work, and we get
>> duplication on the non-ingress switch. But each switch returned a
>> different value. And they were not unique.
>>
>> The third and last issue will be explained in a followup email.
>>
>> Open questions:
>>
>> Is sending notifications going to break userspace?
>> Is this new switchdev object O.K. for the few non-DSA switches that exist?
>> Is the SWITCHDEV_ATTR_ID_PORT_PARENT_ID change acceptable?
>>
>> Andrew
>>
>> Andrew Lunn (8):
>> net: bridge: Rename mglist to host_joined
>> net: bridge: Send notification when host join/leaves a group
>> net: bridge: Add/del switchdev object on host join/leave
>> net: dsa: slave: Handle switchdev host mdb add/del
>> net: dsa: switch: handle host mdb add/remove
>> net: dsa: switch: Don't add CPU port to an mdb by default
>> net: dsa: set offload_fwd_mark on received packets
>> net: dsa: Fix SWITCHDEV_ATTR_ID_PORT_PARENT_ID
>>
>> include/net/switchdev.h | 1 +
>> net/bridge/br_input.c | 2 +-
>> net/bridge/br_mdb.c | 50 +++++++++++++++++++++++++++++---
>> net/bridge/br_multicast.c | 18 +++++++-----
>> net/bridge/br_private.h | 2 +-
>> net/dsa/dsa.c | 1 +
>> net/dsa/dsa_priv.h | 7 +++++
>> net/dsa/port.c | 26 +++++++++++++++++
>> net/dsa/slave.c | 16 ++++++++---
>> net/dsa/switch.c | 72 +++++++++++++++++++++++++++++++++++++++--------
>> net/switchdev/switchdev.c | 2 ++
>> 11 files changed, 168 insertions(+), 29 deletions(-)
>>
>
> This looks much cleaner. I don't have DSA hardware or infrastructure to look deeper.
>
+1
This version looks great!
^ permalink raw reply
* Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Hannes Frederic Sowa @ 2017-09-06 9:37 UTC (permalink / raw)
To: Jan Scheurich
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, e@erig.me
In-Reply-To: <CFF8EF42F1132E4CBE2BF0AB6C21C58D787F5D2E-hqolJogE5njKJFWPz4pdheaU1rCVNFv4@public.gmane.org>
Jan Scheurich <jan.scheurich-IzeFyvvaP7pWk0Htik3J/w@public.gmane.org> writes:
>> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata
>> >> is not in tun_metadata as well?
>> >
>> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is
>> > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a
>> > lot of rework on tun_metadata to make it shared between GENEVE and NSH,
>> > I don't think this can happen in near term. So tun_metadata isn't option
>> > for this now.
>>
>> Sorry, I couldn't follow you. Why can't you store the context headers in
>> tun_metadata exactly?
>>
>
> I think we mixing things. Let me try to clarify:
>
> 1. NSH context metadata has end-to-end significance for the SFP. They
> must be part of the NSH header and cannot be transported as tunnel
> metadata, because transport tunnels (e.g. Geneve) only connect pairs
> of SFFs in the path.
No questions asked. I am not talking about a design choice of the
protocol but an implementation detail of the patch.
> So we need OVS to be able to match on and set NSH context header
> fields, also for MD2 TLVs in the future.
So be it.
> 2. OVS today has support for matching on TLV tunnel metadata after
> termination of a Geneve tunnel. This infrastructure is only usable for
> OVS tunnel ports (like Geneve) but not for matching on TLV headers of
> the NSH protocol, which is not modelled as an OVS tunnel port but
> handled in the OpenFlow pipeline (with generic encp/decap actions to
> enter/terminate an NSH SFP). This was a strategic decision by the OVS
> community two years ago.
I am talking about the tun_opts field in the sw_flow_keys structure for
the kernel dp only.
> There is no way we can re-use the existing TLV tunnel metadata
> infrastructure in OVS for matching and setting NSH MD2 TLV headers. We
> will need to introduce a new (perhaps similar) scheme for modelling
> generic TLV match registers in OVS that are assigned to protocol TLVs
> by the controller. This is FFS.
This is what I don't understand.
Why can't you just reuse the space in the struct sw_flow_key where
geneve would put in their metadata. There are 255 empty bytes at the
beginning if you don't have other tunnel metadata anyway.
If you receive packets over vxlan(gpe), tun_opts gets populated with an
ip_tunnel_key. Couldn't you use the options space in there after the
ip_tunnel_key to store the NSH context just for the sake of storing them
somewhere instead of adding 16 bytes to sw_flow_key?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next RFC 1/2] tun: enable NAPI for TUN/TAP driver
From: Willem de Bruijn @ 2017-09-06 9:18 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Petar Penkov, Network Development, Eric Dumazet, Mahesh Bandewar,
Willem de Bruijn, David Miller, ppenkov
In-Reply-To: <20170905155127.0bd08fb0@xeon-e3>
On Wed, Sep 6, 2017 at 12:51 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Tue, 5 Sep 2017 15:35:50 -0700
> Petar Penkov <ppenkov@google.com> wrote:
>
>> Changes TUN driver to use napi_gro_receive() upon receiving packets
>> rather than netif_rx_ni(). Adds flag CONFIG_TUN_NAPI that enables
>> these changes and operation is not affected if the flag is disabled.
>> SKBs are constructed upon packet arrival and are queued to be
>> processed later.
>>
>> The new path was evaluated with a benchmark with the following setup:
>> Open two tap devices and a receiver thread that reads in a loop for
>> each device. Start one sender thread and pin all threads to different
>> CPUs. Send 1M minimum UDP packets to each device and measure sending
>> time for each of the sending methods:
>> napi_gro_receive(): 4.90s
>> netif_rx_ni(): 4.90s
>> netif_receive_skb(): 7.20s
>>
>> Signed-off-by: Petar Penkov <ppenkov@google.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: Mahesh Bandewar <maheshb@google.com>
>> Cc: Willem de Bruijn <willemb@google.com>
>> Cc: davem@davemloft.net
>> Cc: ppenkov@stanford.edu
>
> Why is this optional? It adds two code paths both of which need
> to be tested.
If the napi_gro_receive path is no more expensive than netif_receive_skb,
as the evaluation indicates, then it is a good candidate to replace that.
The napi_gro_frags path is purely for code coverage. There is no benefit
to applications to treat data copied from userspace as if it consists of raw
pages of data.
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: Maxim Uvarov @ 2017-09-06 9:14 UTC (permalink / raw)
To: Tristram.Ha
Cc: Pavel Machek, Woojung.Huh, Nathan Conrad, Vivien Didelot,
Florian Fainelli, netdev, linux-kernel, Andrew Lunn
In-Reply-To: <93AF473E2DA327428DE3D46B72B1E9FD4111FA48@CHN-SV-EXMX02.mchp-main.com>
2017-08-31 0:32 GMT+03:00 <Tristram.Ha@microchip.com>:
>> On Mon 2017-08-28 16:09:27, Andrew Lunn wrote:
>> > > I may be confused here, but AFAICT:
>> > >
>> > > 1) Yes, it has standard layout when accessed over MDIO.
>> >
>> >
>> > Section 4.8 of the datasheet says:
>> >
>> > All the registers defined in this section can be also accessed
>> > via the SPI interface.
>> >
>> > Meaning all PHY registers can be access via the SPI interface. So you
>> > should be able to make a standard Linux MDIO bus driver which performs
>> > SPI reads.
>>
>> As far as I can tell (and their driver confirms) -- yes, all those registers can be
>> accessed over the SPI, they are just shuffled around... hence MDIO
>> emulation code. I copied it from their code (see the copyrights) so no, I don't
>> believe there's nicer solution.
>>
>> Best regards,
>>
>> Pavel
>
> Can you hold on your developing work on KSZ8895 driver? I am afraid your effort may be in vain. We at Microchip are planning to release DSA drivers for all KSZ switches, starting at KSZ8795, then KSZ8895, and KSZ8863.
>
> The driver files all follow the structures of the current KSZ9477 DSA driver, and the file tag_ksz.c will be updated to handle the tail tag of different chips, which requires including the ksz_priv.h header. That is required nevertheless to support using the offload_fwd_mark indication.
>
> The KSZ8795 driver will be submitted after Labor Day (9/4) if testing reveals no problem. The KSZ8895 driver will be submitted right after that. You should have no problem using the driver right away.
>
Hello Tristram, is there any update for that driver?
Maxim.
> Tristram Ha
> Principal Software Engineer
> Microchip Technology Inc.
>
--
Best regards,
Maxim Uvarov
^ permalink raw reply
* [PATCH v13 3/5] net: e100: Replace PCI pool old API
From: Romain Perier @ 2017-09-06 9:08 UTC (permalink / raw)
To: Dan Williams, Doug Ledford, Sean Hefty, Hal Rosenstock,
jeffrey.t.kirsher, David S. Miller, stas.yakovlev, Aviad Krawczyk
Cc: linux-rdma, netdev, linux-kernel, Greg Kroah-Hartman,
Romain Perier
In-Reply-To: <20170906090857.14846-1-romain.perier@collabora.com>
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Acked-by: Peter Senna Tschudin <peter.senna@collabora.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Peter Senna Tschudin <peter.senna@collabora.com>
---
drivers/net/ethernet/intel/e100.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
index 4d10270ddf8f..d1470d30351c 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -607,7 +607,7 @@ struct nic {
struct mem *mem;
dma_addr_t dma_addr;
- struct pci_pool *cbs_pool;
+ struct dma_pool *cbs_pool;
dma_addr_t cbs_dma_addr;
u8 adaptive_ifs;
u8 tx_threshold;
@@ -1892,7 +1892,7 @@ static void e100_clean_cbs(struct nic *nic)
nic->cb_to_clean = nic->cb_to_clean->next;
nic->cbs_avail++;
}
- pci_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
+ dma_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
nic->cbs = NULL;
nic->cbs_avail = 0;
}
@@ -1910,7 +1910,7 @@ static int e100_alloc_cbs(struct nic *nic)
nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = NULL;
nic->cbs_avail = 0;
- nic->cbs = pci_pool_alloc(nic->cbs_pool, GFP_KERNEL,
+ nic->cbs = dma_pool_alloc(nic->cbs_pool, GFP_KERNEL,
&nic->cbs_dma_addr);
if (!nic->cbs)
return -ENOMEM;
@@ -2961,8 +2961,8 @@ static int e100_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
netif_err(nic, probe, nic->netdev, "Cannot register net device, aborting\n");
goto err_out_free;
}
- nic->cbs_pool = pci_pool_create(netdev->name,
- nic->pdev,
+ nic->cbs_pool = dma_pool_create(netdev->name,
+ &nic->pdev->dev,
nic->params.cbs.max * sizeof(struct cb),
sizeof(u32),
0);
@@ -3002,7 +3002,7 @@ static void e100_remove(struct pci_dev *pdev)
unregister_netdev(netdev);
e100_free(nic);
pci_iounmap(pdev, nic->csr);
- pci_pool_destroy(nic->cbs_pool);
+ dma_pool_destroy(nic->cbs_pool);
free_netdev(netdev);
pci_release_regions(pdev);
pci_disable_device(pdev);
--
2.11.0
^ permalink raw reply related
* [PATCH v13 5/5] PCI: Remove PCI pool macro functions
From: Romain Perier @ 2017-09-06 9:08 UTC (permalink / raw)
To: Dan Williams, Doug Ledford, Sean Hefty, Hal Rosenstock,
jeffrey.t.kirsher, David S. Miller, stas.yakovlev, Aviad Krawczyk
Cc: linux-rdma, netdev, linux-kernel, Greg Kroah-Hartman,
Romain Perier
In-Reply-To: <20170906090857.14846-1-romain.perier@collabora.com>
Now that all the drivers use dma pool API, we can remove the macro
functions for PCI pool.
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Reviewed-by: Peter Senna Tschudin <peter.senna@collabora.com>
---
include/linux/pci.h | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index f68c58a93dd0..89dfc277a6c6 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1322,15 +1322,6 @@ int pci_set_vga_state(struct pci_dev *pdev, bool decode,
#include <linux/pci-dma.h>
#include <linux/dmapool.h>
-#define pci_pool dma_pool
-#define pci_pool_create(name, pdev, size, align, allocation) \
- dma_pool_create(name, &pdev->dev, size, align, allocation)
-#define pci_pool_destroy(pool) dma_pool_destroy(pool)
-#define pci_pool_alloc(pool, flags, handle) dma_pool_alloc(pool, flags, handle)
-#define pci_pool_zalloc(pool, flags, handle) \
- dma_pool_zalloc(pool, flags, handle)
-#define pci_pool_free(pool, vaddr, addr) dma_pool_free(pool, vaddr, addr)
-
struct msix_entry {
u32 vector; /* kernel uses to write allocated vector */
u16 entry; /* driver uses to specify entry, OS writes */
--
2.11.0
^ permalink raw reply related
* [PATCH v13 4/5] hinic: Replace PCI pool old API
From: Romain Perier @ 2017-09-06 9:08 UTC (permalink / raw)
To: Dan Williams, Doug Ledford, Sean Hefty, Hal Rosenstock,
jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w, David S. Miller,
stas.yakovlev-Re5JQEeQqe8AvxtiuMwx3w, Aviad Krawczyk
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Romain Perier
In-Reply-To: <20170906090857.14846-1-romain.perier-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.
Signed-off-by: Romain Perier <romain.perier-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---
drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c | 10 +++++-----
drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.h | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
index 7d95f0866fb0..28a81ac97af5 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c
@@ -143,7 +143,7 @@ int hinic_alloc_cmdq_buf(struct hinic_cmdqs *cmdqs,
struct hinic_hwif *hwif = cmdqs->hwif;
struct pci_dev *pdev = hwif->pdev;
- cmdq_buf->buf = pci_pool_alloc(cmdqs->cmdq_buf_pool, GFP_KERNEL,
+ cmdq_buf->buf = dma_pool_alloc(cmdqs->cmdq_buf_pool, GFP_KERNEL,
&cmdq_buf->dma_addr);
if (!cmdq_buf->buf) {
dev_err(&pdev->dev, "Failed to allocate cmd from the pool\n");
@@ -161,7 +161,7 @@ int hinic_alloc_cmdq_buf(struct hinic_cmdqs *cmdqs,
void hinic_free_cmdq_buf(struct hinic_cmdqs *cmdqs,
struct hinic_cmdq_buf *cmdq_buf)
{
- pci_pool_free(cmdqs->cmdq_buf_pool, cmdq_buf->buf, cmdq_buf->dma_addr);
+ dma_pool_free(cmdqs->cmdq_buf_pool, cmdq_buf->buf, cmdq_buf->dma_addr);
}
static unsigned int cmdq_wqe_size_from_bdlen(enum bufdesc_len len)
@@ -875,7 +875,7 @@ int hinic_init_cmdqs(struct hinic_cmdqs *cmdqs, struct hinic_hwif *hwif,
int err;
cmdqs->hwif = hwif;
- cmdqs->cmdq_buf_pool = pci_pool_create("hinic_cmdq", pdev,
+ cmdqs->cmdq_buf_pool = dma_pool_create("hinic_cmdq", &pdev->dev,
HINIC_CMDQ_BUF_SIZE,
HINIC_CMDQ_BUF_SIZE, 0);
if (!cmdqs->cmdq_buf_pool)
@@ -916,7 +916,7 @@ int hinic_init_cmdqs(struct hinic_cmdqs *cmdqs, struct hinic_hwif *hwif,
devm_kfree(&pdev->dev, cmdqs->saved_wqs);
err_saved_wqs:
- pci_pool_destroy(cmdqs->cmdq_buf_pool);
+ dma_pool_destroy(cmdqs->cmdq_buf_pool);
return err;
}
@@ -942,5 +942,5 @@ void hinic_free_cmdqs(struct hinic_cmdqs *cmdqs)
devm_kfree(&pdev->dev, cmdqs->saved_wqs);
- pci_pool_destroy(cmdqs->cmdq_buf_pool);
+ dma_pool_destroy(cmdqs->cmdq_buf_pool);
}
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.h b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.h
index b35583400cb6..23f8d39eab68 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.h
@@ -157,7 +157,7 @@ struct hinic_cmdq {
struct hinic_cmdqs {
struct hinic_hwif *hwif;
- struct pci_pool *cmdq_buf_pool;
+ struct dma_pool *cmdq_buf_pool;
struct hinic_wq *saved_wqs;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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