* [net-next PATCH v2 1/5] stmmac: let remove/resume/suspend functions take device pointer
From: Joachim Eastwood @ 2016-05-01 20:58 UTC (permalink / raw)
To: davem
Cc: Joachim Eastwood, marex, dinguyen, peppe.cavallaro,
alexandre.torgue, netdev
In-Reply-To: <1462136303-16825-1-git-send-email-manabian@gmail.com>
Change stmmac_remove/resume/suspend to take a device pointer so
they can be used directly by drivers that doesn't need to perform
anything device specific.
This lets us remove the PCI pm functions and later simplifiy the
platform drivers.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Tested-by: Marek Vasut <marex@denx.de>
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 6 +++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 ++++++++------
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 24 ++--------------------
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 6 +++---
4 files changed, 17 insertions(+), 34 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index ff67506..59ae608 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -148,9 +148,9 @@ void stmmac_set_ethtool_ops(struct net_device *netdev);
int stmmac_ptp_register(struct stmmac_priv *priv);
void stmmac_ptp_unregister(struct stmmac_priv *priv);
-int stmmac_resume(struct net_device *ndev);
-int stmmac_suspend(struct net_device *ndev);
-int stmmac_dvr_remove(struct net_device *ndev);
+int stmmac_resume(struct device *dev);
+int stmmac_suspend(struct device *dev);
+int stmmac_dvr_remove(struct device *dev);
int stmmac_dvr_probe(struct device *device,
struct plat_stmmacenet_data *plat_dat,
struct stmmac_resources *res);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b87edb7..fd5ab7b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3350,12 +3350,13 @@ EXPORT_SYMBOL_GPL(stmmac_dvr_probe);
/**
* stmmac_dvr_remove
- * @ndev: net device pointer
+ * @dev: device pointer
* Description: this function resets the TX/RX processes, disables the MAC RX/TX
* changes the link status, releases the DMA descriptor rings.
*/
-int stmmac_dvr_remove(struct net_device *ndev)
+int stmmac_dvr_remove(struct device *dev)
{
+ struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
pr_info("%s:\n\tremoving driver", __func__);
@@ -3381,13 +3382,14 @@ EXPORT_SYMBOL_GPL(stmmac_dvr_remove);
/**
* stmmac_suspend - suspend callback
- * @ndev: net device pointer
+ * @dev: device pointer
* Description: this is the function to suspend the device and it is called
* by the platform driver to stop the network queue, release the resources,
* program the PMT register (for WoL), clean and release driver resources.
*/
-int stmmac_suspend(struct net_device *ndev)
+int stmmac_suspend(struct device *dev)
{
+ struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned long flags;
@@ -3430,12 +3432,13 @@ EXPORT_SYMBOL_GPL(stmmac_suspend);
/**
* stmmac_resume - resume callback
- * @ndev: net device pointer
+ * @dev: device pointer
* Description: when resume this function is invoked to setup the DMA and CORE
* in a usable state.
*/
-int stmmac_resume(struct net_device *ndev)
+int stmmac_resume(struct device *dev)
{
+ struct net_device *ndev = dev_get_drvdata(dev);
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned long flags;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index ae43887..56c8a23 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -231,30 +231,10 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
*/
static void stmmac_pci_remove(struct pci_dev *pdev)
{
- struct net_device *ndev = pci_get_drvdata(pdev);
-
- stmmac_dvr_remove(ndev);
-}
-
-#ifdef CONFIG_PM_SLEEP
-static int stmmac_pci_suspend(struct device *dev)
-{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *ndev = pci_get_drvdata(pdev);
-
- return stmmac_suspend(ndev);
-}
-
-static int stmmac_pci_resume(struct device *dev)
-{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct net_device *ndev = pci_get_drvdata(pdev);
-
- return stmmac_resume(ndev);
+ stmmac_dvr_remove(&pdev->dev);
}
-#endif
-static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_pci_suspend, stmmac_pci_resume);
+static SIMPLE_DEV_PM_OPS(stmmac_pm_ops, stmmac_suspend, stmmac_resume);
#define STMMAC_VENDOR_ID 0x700
#define STMMAC_QUARK_ID 0x0937
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index effaa4f..409db91 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -386,7 +386,7 @@ int stmmac_pltfr_remove(struct platform_device *pdev)
{
struct net_device *ndev = platform_get_drvdata(pdev);
struct stmmac_priv *priv = netdev_priv(ndev);
- int ret = stmmac_dvr_remove(ndev);
+ int ret = stmmac_dvr_remove(&pdev->dev);
if (priv->plat->exit)
priv->plat->exit(pdev, priv->plat->bsp_priv);
@@ -410,7 +410,7 @@ static int stmmac_pltfr_suspend(struct device *dev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct platform_device *pdev = to_platform_device(dev);
- ret = stmmac_suspend(ndev);
+ ret = stmmac_suspend(dev);
if (priv->plat->exit)
priv->plat->exit(pdev, priv->plat->bsp_priv);
@@ -433,7 +433,7 @@ static int stmmac_pltfr_resume(struct device *dev)
if (priv->plat->init)
priv->plat->init(pdev, priv->plat->bsp_priv);
- return stmmac_resume(ndev);
+ return stmmac_resume(dev);
}
#endif /* CONFIG_PM_SLEEP */
--
2.8.0
^ permalink raw reply related
* [net-next PATCH v2 0/5] stmmac: dwmac-socfpga refactor+cleanup
From: Joachim Eastwood @ 2016-05-01 20:58 UTC (permalink / raw)
To: davem
Cc: Joachim Eastwood, marex, dinguyen, peppe.cavallaro,
alexandre.torgue, netdev
This patch aims to remove the init/exit callbacks from the dwmac-
socfpga driver and instead use standard PM callbacks. Doing this
will also allow us to cleanup the driver.
Eventually the init/exit callbacks will be deprecated and removed
from all drivers dwmac-* except for dwmac-generic. Drivers will be
refactored to use standard PM and remove callbacks.
This patch set should not change the behavior of the driver itself,
it only moves code around. The only exception to this is patch
number 4 which restores the resume callback behavior which was
changed in the "net: stmmac: socfpga: Remove re-registration of
reset controller" patch. I belive calling phy_resume() only
from the resume callback and not probe is the right thing to do.
Changes from v1:
- Rebase on net-next
One heads-up here:
The first patch changes the prototype of a couple of
functions used in Alexandre's "add Ethernet glue logic for
stm32 chip" patch [1] and will cause build failures for
dwmac-stm32.c if not fixed up!
If Alexandre's patch set is applied first I will gladly
rebase my patch set to account for his driver as well.
[1] https://patchwork.ozlabs.org/patch/614405/
Dave: To avoid the build failure mentioned above you can
apply the changes below to the stm32 driver or
Alexandre can use it if he creates a new version
of his patch set.
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -133,7 +133,7 @@ static int stm32_dwmac_remove(struct platform_device *pdev)
{
struct net_device *ndev = platform_get_drvdata(pdev);
struct stmmac_priv *priv = netdev_priv(ndev);
- int ret = stmmac_dvr_remove(ndev);
+ int ret = stmmac_dvr_remove(&pdev->dev);
stm32_dwmac_clk_disable(priv->plat->bsp_priv);
@@ -147,7 +147,7 @@ static int stm32_dwmac_suspend(struct device *dev)
struct stmmac_priv *priv = netdev_priv(ndev);
int ret;
- ret = stmmac_suspend(ndev);
+ ret = stmmac_suspend(dev);
stm32_dwmac_clk_disable(priv->plat->bsp_priv);
return ret;
@@ -163,7 +163,7 @@ static int stm32_dwmac_resume(struct device *dev)
if (ret)
return ret;
- ret = stmmac_resume(ndev);
+ ret = stmmac_resume(dev);
return ret;
}
Joachim Eastwood (5):
stmmac: let remove/resume/suspend functions take device pointer
stmmac: dwmac-socfpga: add PM ops and resume function
stmmac: dwmac-socfpga: keep a copy of stmmac_rst in driver priv data
stmmac: dwmac-socfpga: call phy_resume() only in resume callback
stmmac: dwmac-socfpga: kill init() and rename setup() to set_phy_mode()
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 106 +++++++++++----------
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 6 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 15 +--
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 24 +----
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 6 +-
5 files changed, 71 insertions(+), 86 deletions(-)
--
2.8.0
^ permalink raw reply
* Re: Q: How to disable vlan strip in Intel igb driver ?
From: Peter Palúch @ 2016-05-01 20:51 UTC (permalink / raw)
To: Ran Shalit; +Cc: netdev, alexander.duyck
In-Reply-To: <CAJ2oMhJp9M93QujnPYmp5CQkt-tx8P-uRCveiMEkDRLrcZmNhg@mail.gmail.com>
Hi Ran,
> Alex,
> I don't see rx-vlan-offload option in my ethtool. strange, maybe it is
> not available in all ethtool versions ?
According to my manpage for ethtool v4.5, the relevant -K option is
"rxvlan".
> Hi Peter,
> Yes, I'm using AF_PACKET (I can't validate it now for 100%, but I
> quite sure about it).
Okay - but I assume that you are writing a userspace application, not a
kernelspace driver or module, right?
> I'm accessing the ethernet header, and it always gives me non extended
> ethernet header (without vlan information).
It seems that this behavior has been around for a long time, and is
intentional. See the following thread for more information:
http://www.spinics.net/lists/netdev/msg244668.html
The only legit way of accessing VLAN tag info on an AF_PACKET socket I
know about is by setting the PACKET_AUXDATA socket option, and reading
the auxiliary data as a struct tpacket_auxdata using recvmsg().
In addition, however, there seems to be a bug in the kernel in that the
tp_vlan_tci member of the struct tpacket_auxdata is filled in only if
the AF_PACKET socket is bound to htons(ETH_P_ALL). If the socket is
bound to any other specific protocol, the tp_vlan_tci is set to 0. I
have raised this issue recently in the following thread(s) but have not
received a response yet:
http://www.spinics.net/lists/netdev/msg372830.html
http://www.spinics.net/lists/netdev/msg373112.html
> I can see the vlan tag in vlan_tci field in sk_buff, but this is not
> exactly what I need, I need the header AS-IS with the original
> (extended) ethernet header.
How are you accessing the vlan_tci field from your software?
In any case, with AF_PACKET sockets, I am afraid you don't have much
choice. Even libpcap reconstructs VLAN-tagged frames by reading the VLAN
tag from an auxiliary structure and then re-inserting it into the frame,
because the frame delivered through an AF_PACKET socket does not have
the VLAN tag present anymore.
Best regards,
Peter
^ permalink raw reply
* Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload
From: Or Gerlitz @ 2016-05-01 20:35 UTC (permalink / raw)
To: Alexander Duyck
Cc: talal@mellanox.com, Linux Netdev List, michael.chan, David Miller,
Gal Pressman, Or Gerlitz, Eran Ben Elisha
In-Reply-To: <20160429224333.12418.13862.stgit@ahduyck-xeon-server>
On Sat, Apr 30, 2016 at 1:43 AM, Alexander Duyck <aduyck@mirantis.com> wrote:
> This patch assumes that the mlx4 hardware will ignore existing IPv4/v6
> header fields for length and checksum as well as the length and checksum
> fields for outer UDP headers.
Hi Alex,
I see now the above text appearing in bunch of similar commit of
yours, specifically to Intel drivers and mlx5... could you please
elaborate a bit more what you mean here and what are the practical
consequences of that characteristics?
I got that right NETIF_F_GSO_UDP_TUNNEL_CSUM means that the HW can do
segmentation for TCP packets encapsulated by UDP tunnel e.g VXLAN
where the outer checksum is not zero. AFAIK, any other outer checksum
value can't correctly be a constant... are you assuming here RCO or
LCO?
Or.
^ permalink raw reply
* Re: [net-next PATCH v2 1/9] net: Disable segmentation if checksumming is not supported
From: Or Gerlitz @ 2016-05-01 20:30 UTC (permalink / raw)
To: Alexander Duyck
Cc: talal@mellanox.com, Linux Netdev List, michael.chan, David Miller,
Or Gerlitz, Eran Ben Elisha, Tariq Toukan
In-Reply-To: <20160429224308.12418.51424.stgit@ahduyck-xeon-server>
On Sat, Apr 30, 2016 at 1:43 AM, Alexander Duyck <aduyck@mirantis.com> wrote:
> In the case of the mlx4 and mlx5 driver they do not support IPv6 checksum
> offload for tunnels.
Alex,
To clarify, when you say "not support IPv6 checksum for tunnels", you
refer to the offloading of the outer or inner checksum?
Still (me and I think also Tariq from our driver team) catching up on
the series, the primitives and conventions you are introducing using
and how this applies on mlx5. I saw that Saeed acked the the mlx5e
patches (7 and 8).
Specifically, the mlx4 patches are practically fixes so if they don't
land in 4.7 via net-next we can get them there through net, lets give
us the few more days needed to catch up from our side.
Or.
^ permalink raw reply
* Re: [PATCH] pxa168_eth: fix mdiobus_scan() error check
From: Sergei Shtylyov @ 2016-05-01 20:30 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: arnd
In-Reply-To: <57266638.6030704@cogentembedded.com>
On 05/01/2016 11:25 PM, Sergei Shtylyov wrote:
>>> Since mdiobus_scan() returns either an error code or NULL on error, the
>>> driver should check for both, not only for NULL, otherwise a crash is
>>> imminent...
>>>
>>> Reported-by: Arnd Bergmann <arnd@arndb.de>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>
>>> ---
>>> The patch is against DaveM's 'net.git' repo.
>>>
>>> drivers/net/ethernet/marvell/pxa168_eth.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> Index: net/drivers/net/ethernet/marvell/pxa168_eth.c
>>> ===================================================================
>>> --- net.orig/drivers/net/ethernet/marvell/pxa168_eth.c
>>> +++ net/drivers/net/ethernet/marvell/pxa168_eth.c
>>> @@ -979,6 +979,8 @@ static int pxa168_init_phy(struct net_de
>>> return 0;
>>>
>>> pep->phy = mdiobus_scan(pep->smi_bus, pep->phy_addr);
>>> + if (IS_ERR(pep->phy))
>>> + return PTR_ERR(pep->phy);
>>> if (!pep->phy)
>>> return -ENODEV;
>>
>> Should not this check be removed too and
>
> That's my next move -- for now I'm fixing the existing bug in this driver
> only.
In fact, it can't be removed yet as mdiobus_scan() may return NULL on
other error path. There's certainly a space for improvements yet...
[...]
MBR, Sergei
^ permalink raw reply
* Re: [net-next PATCH v2 5/9] mlx4: Add support for UDP tunnel segmentation with outer checksum offload
From: Saeed Mahameed @ 2016-05-01 20:28 UTC (permalink / raw)
To: Alexander Duyck
Cc: Tal Alon, Linux Netdev List, michael.chan, David S. Miller,
Gal Pressman, Or Gerlitz, Eran Ben Elisha
In-Reply-To: <20160429224333.12418.13862.stgit@ahduyck-xeon-server>
On Sat, Apr 30, 2016 at 1:43 AM, Alexander Duyck <aduyck@mirantis.com> wrote:
> This patch assumes that the mlx4 hardware will ignore existing IPv4/v6
> header fields for length and checksum as well as the length and checksum
> fields for outer UDP headers.
>
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 8bd143dda95d..bce37cbfde24 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -2358,7 +2358,9 @@ out:
>
> /* set offloads */
> priv->dev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> - NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL;
> + NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL |
> + NETIF_F_GSO_UDP_TUNNEL_CSUM |
> + NETIF_F_GSO_PARTIAL;
> }
>
> static void mlx4_en_del_vxlan_offloads(struct work_struct *work)
> @@ -2368,7 +2370,9 @@ static void mlx4_en_del_vxlan_offloads(struct work_struct *work)
> vxlan_del_task);
> /* unset offloads */
> priv->dev->hw_enc_features &= ~(NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> - NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL);
> + NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL |
> + NETIF_F_GSO_UDP_TUNNEL_CSUM |
> + NETIF_F_GSO_PARTIAL);
I know it is not related to your patch, but is it ok to dynamically
modify priv->dev->hw_enc_features every vxlan add/del_port request ?
especially on a deferred work !
Shouldn't we at least notify the stack ?
^ permalink raw reply
* Re: [PATCH] pxa168_eth: fix mdiobus_scan() error check
From: Sergei Shtylyov @ 2016-05-01 20:25 UTC (permalink / raw)
To: Florian Fainelli, netdev; +Cc: arnd
In-Reply-To: <57262956.3060206@gmail.com>
Hello.
On 05/01/2016 07:05 PM, Florian Fainelli wrote:
>> Since mdiobus_scan() returns either an error code or NULL on error, the
>> driver should check for both, not only for NULL, otherwise a crash is
>> imminent...
>>
>> Reported-by: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> ---
>> The patch is against DaveM's 'net.git' repo.
>>
>> drivers/net/ethernet/marvell/pxa168_eth.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> Index: net/drivers/net/ethernet/marvell/pxa168_eth.c
>> ===================================================================
>> --- net.orig/drivers/net/ethernet/marvell/pxa168_eth.c
>> +++ net/drivers/net/ethernet/marvell/pxa168_eth.c
>> @@ -979,6 +979,8 @@ static int pxa168_init_phy(struct net_de
>> return 0;
>>
>> pep->phy = mdiobus_scan(pep->smi_bus, pep->phy_addr);
>> + if (IS_ERR(pep->phy))
>> + return PTR_ERR(pep->phy);
>> if (!pep->phy)
>> return -ENODEV;
>
> Should not this check be removed too and
That's my next move -- for now I'm fixing the existing bug in this driver
only.
> converted to a PTR_ERR(pep->phy) != -ENODEV?
I don't see what that would achieve, IMO it's enough to just drop this
*if* altogether.
MBR, Sergei
^ permalink raw reply
* Re: [net-next PATCH v2 6/9] mlx4: Add support for inner IPv6 checksum offloads and TSO
From: Saeed Mahameed @ 2016-05-01 20:21 UTC (permalink / raw)
To: Alexander Duyck
Cc: Tal Alon, Linux Netdev List, michael.chan, David S. Miller,
Gal Pressman, Or Gerlitz, Eran Ben Elisha
In-Reply-To: <20160429224339.12418.53462.stgit@ahduyck-xeon-server>
On Sat, Apr 30, 2016 at 1:43 AM, Alexander Duyck <aduyck@mirantis.com> wrote:
> >From what I can tell the ConnectX-3 will support an inner IPv6 checksum and
> segmentation offload, however it cannot support outer IPv6 headers. This
> assumption is based on the fact that I could see the checksum being
> offloaded for inner header on IPv4 tunnels, but not on IPv6 tunnels.
>
> For this reason I am adding the feature to the hw_enc_features and adding
> an extra check to the features_check call that will disable GSO and
> checksum offload in the case that the encapsulated frame has an outer IP
> version of that is not 4. The check in mlx4_en_features_check could be
> removed if at some point in the future a fix is found that allows the
> hardware to offload segmentation/checksum on tunnels with an outer IPv6
> header.
>
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [PATCH v1 net] net/mlx4: Avoid wrong virtual mappings
From: Sinan Kaya @ 2016-05-01 20:12 UTC (permalink / raw)
To: David Miller
Cc: hagaya-VPRAkNaXOzVWk0Htik3J/w, dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
timur-sgV2jX0FEOL9JmXXK+q4OQ, eli-VPRAkNaXOzVWk0Htik3J/w,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w, eranbe-VPRAkNaXOzVWk0Htik3J/w,
yishaih-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
saeedm-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <20160501.160720.1356913722642000889.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 5/1/2016 4:07 PM, David Miller wrote:
> From: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Date: Sun, 1 May 2016 11:43:54 -0400
>
>> Can we get this queued for 4.7? Mellanox with arm64 has been broken over 1.5 years.
>
> Can you not quote an entire huge patch just to say something like
> this?
>
> I'm waiting for the people involved all to give feedback.
>
> If it's been broken for more than a year, waiting for a few more
> days to get the fix right is not going to be the end of the world.
>
Sure, I thought there is a common consensus. The original patch posted was from Christoph Hellwig.
This patch does the same thing like Christoph Hellwig proposed + a fallback approach for the
infiniband case where fragmented buffers are still supported.
The patch is actually a copy/paste from the MLX5 driver into MLX4.
I'm OK with waiitng for a few more days. I just wanted to make sure that this patch
is moving in the right direction.
If not, let's list the open issues.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
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
* Re: [net-next PATCH v2 8/9] mlx5e: Fix IPv6 tunnel checksum offload
From: Saeed Mahameed @ 2016-05-01 20:09 UTC (permalink / raw)
To: Alexander Duyck
Cc: Tal Alon, Linux Netdev List, michael.chan, David S. Miller,
Gal Pressman, Or Gerlitz, Eran Ben Elisha
In-Reply-To: <20160429224352.12418.68373.stgit@ahduyck-xeon-server>
On Sat, Apr 30, 2016 at 1:43 AM, Alexander Duyck <aduyck@mirantis.com> wrote:
> The mlx5 driver exposes support for TSO6 but not IPv6 csum for hardware
> encapsulated tunnels. This leads to issues as it triggers warnings in
> skb_checksum_help as it ends up being called as we report supporting the
> segmentation but not the checksumming for IPv6 frames.
>
> This patch corrects that and drops 2 features that don't actually need to
> be supported in hw_enc_features since they are Rx features and don't
> actually impact anything by being present in hw_enc_features.
>
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [net-next PATCH v2 7/9] mlx5e: Add support for UDP tunnel segmentation with outer checksum offload
From: Saeed Mahameed @ 2016-05-01 20:08 UTC (permalink / raw)
To: Alexander Duyck
Cc: Tal Alon, Linux Netdev List, michael.chan, David S. Miller,
Gal Pressman, Or Gerlitz, Eran Ben Elisha
In-Reply-To: <20160429224345.12418.88876.stgit@ahduyck-xeon-server>
On Sat, Apr 30, 2016 at 1:43 AM, Alexander Duyck <aduyck@mirantis.com> wrote:
> This patch assumes that the mlx5 hardware will ignore existing IPv4/v6
> header fields for length and checksum as well as the length and checksum
> fields for outer UDP headers.
>
> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
^ permalink raw reply
* Re: [PATCH v1 net] net/mlx4: Avoid wrong virtual mappings
From: David Miller @ 2016-05-01 20:07 UTC (permalink / raw)
To: okaya-sgV2jX0FEOL9JmXXK+q4OQ
Cc: hagaya-VPRAkNaXOzVWk0Htik3J/w, dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
timur-sgV2jX0FEOL9JmXXK+q4OQ, eli-VPRAkNaXOzVWk0Htik3J/w,
ogerlitz-VPRAkNaXOzVWk0Htik3J/w, eranbe-VPRAkNaXOzVWk0Htik3J/w,
yishaih-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
saeedm-VPRAkNaXOzVWk0Htik3J/w
In-Reply-To: <5726243A.9070109-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
From: Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Date: Sun, 1 May 2016 11:43:54 -0400
> Can we get this queued for 4.7? Mellanox with arm64 has been broken over 1.5 years.
Can you not quote an entire huge patch just to say something like
this?
I'm waiting for the people involved all to give feedback.
If it's been broken for more than a year, waiting for a few more
days to get the fix right is not going to be the end of the world.
--
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
* [PATCH net 2/4] net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue
From: Saeed Mahameed @ 2016-05-01 19:59 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Matthew Finlay,
Saeed Mahameed
In-Reply-To: <1462132797-22853-1-git-send-email-saeedm@mellanox.com>
From: Matthew Finlay <matt@mellanox.com>
When MLX5_EN=y MLX5_CORE=y and VXLAN=m there is a linker error for
vxlan_get_rx_port() due to the fact that VXLAN is a module. Change Kconfig
to select VXLAN when MLX5_CORE=y. When MLX5_CORE=m there is no dependency
on the value of VXLAN.
Fixes: b3f63c3d5e2c ('net/mlx5e: Add netdev support for VXLAN tunneling')
Signed-off-by: Matthew Finlay <matt@mellanox.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index 1cf722e..559d11a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -14,6 +14,7 @@ config MLX5_CORE_EN
bool "Mellanox Technologies ConnectX-4 Ethernet support"
depends on NETDEVICES && ETHERNET && PCI && MLX5_CORE
select PTP_1588_CLOCK
+ select VXLAN if MLX5_CORE=y
default n
---help---
Ethernet support in Mellanox Technologies ConnectX-4 NIC.
--
2.8.0
^ permalink raw reply related
* [PATCH net 3/4] net/mlx5e: Implement a mlx5e workqueue
From: Saeed Mahameed @ 2016-05-01 19:59 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Matthew Finlay,
Saeed Mahameed
In-Reply-To: <1462132797-22853-1-git-send-email-saeedm@mellanox.com>
From: Matthew Finlay <matt@mellanox.com>
Implement a mlx5e workqueue to handle all mlx5e specific tasks. Move
all tasks currently using the system workqueue to the new workqueue.
This is in preparation for vxlan using the mlx5e workqueue in order to
schedule port add/remove operations.
Signed-off-by: Matthew Finlay <matt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 30 ++++++++++++++---------
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index e80ce94..3881dce 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -567,6 +567,7 @@ struct mlx5e_priv {
struct mlx5e_vxlan_db vxlan;
struct mlx5e_params params;
+ struct workqueue_struct *wq;
struct work_struct update_carrier_work;
struct work_struct set_rx_mode_work;
struct delayed_work update_stats_work;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 67d548b..9ab0841 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -262,9 +262,8 @@ static void mlx5e_update_stats_work(struct work_struct *work)
mutex_lock(&priv->state_lock);
if (test_bit(MLX5E_STATE_OPENED, &priv->state)) {
mlx5e_update_stats(priv);
- schedule_delayed_work(dwork,
- msecs_to_jiffies(
- MLX5E_UPDATE_STATS_INTERVAL));
+ queue_delayed_work(priv->wq, dwork,
+ msecs_to_jiffies(MLX5E_UPDATE_STATS_INTERVAL));
}
mutex_unlock(&priv->state_lock);
}
@@ -280,7 +279,7 @@ static void mlx5e_async_event(struct mlx5_core_dev *mdev, void *vpriv,
switch (event) {
case MLX5_DEV_EVENT_PORT_UP:
case MLX5_DEV_EVENT_PORT_DOWN:
- schedule_work(&priv->update_carrier_work);
+ queue_work(priv->wq, &priv->update_carrier_work);
break;
default:
@@ -1505,7 +1504,7 @@ int mlx5e_open_locked(struct net_device *netdev)
mlx5e_update_carrier(priv);
mlx5e_timestamp_init(priv);
- schedule_delayed_work(&priv->update_stats_work, 0);
+ queue_delayed_work(priv->wq, &priv->update_stats_work, 0);
return 0;
@@ -1961,7 +1960,7 @@ static void mlx5e_set_rx_mode(struct net_device *dev)
{
struct mlx5e_priv *priv = netdev_priv(dev);
- schedule_work(&priv->set_rx_mode_work);
+ queue_work(priv->wq, &priv->set_rx_mode_work);
}
static int mlx5e_set_mac(struct net_device *netdev, void *addr)
@@ -1976,7 +1975,7 @@ static int mlx5e_set_mac(struct net_device *netdev, void *addr)
ether_addr_copy(netdev->dev_addr, saddr->sa_data);
netif_addr_unlock_bh(netdev);
- schedule_work(&priv->set_rx_mode_work);
+ queue_work(priv->wq, &priv->set_rx_mode_work);
return 0;
}
@@ -2498,10 +2497,14 @@ static void *mlx5e_create_netdev(struct mlx5_core_dev *mdev)
priv = netdev_priv(netdev);
+ priv->wq = create_singlethread_workqueue("mlx5e");
+ if (!priv->wq)
+ goto err_free_netdev;
+
err = mlx5_alloc_map_uar(mdev, &priv->cq_uar, false);
if (err) {
mlx5_core_err(mdev, "alloc_map uar failed, %d\n", err);
- goto err_free_netdev;
+ goto err_destroy_wq;
}
err = mlx5_core_alloc_pd(mdev, &priv->pdn);
@@ -2580,7 +2583,7 @@ static void *mlx5e_create_netdev(struct mlx5_core_dev *mdev)
vxlan_get_rx_port(netdev);
mlx5e_enable_async_events(priv);
- schedule_work(&priv->set_rx_mode_work);
+ queue_work(priv->wq, &priv->set_rx_mode_work);
return priv;
@@ -2617,6 +2620,9 @@ err_dealloc_pd:
err_unmap_free_uar:
mlx5_unmap_free_uar(mdev, &priv->cq_uar);
+err_destroy_wq:
+ destroy_workqueue(priv->wq);
+
err_free_netdev:
free_netdev(netdev);
@@ -2630,9 +2636,9 @@ static void mlx5e_destroy_netdev(struct mlx5_core_dev *mdev, void *vpriv)
set_bit(MLX5E_STATE_DESTROYING, &priv->state);
- schedule_work(&priv->set_rx_mode_work);
+ queue_work(priv->wq, &priv->set_rx_mode_work);
mlx5e_disable_async_events(priv);
- flush_scheduled_work();
+ flush_workqueue(priv->wq);
if (test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &mdev->intf_state)) {
netif_device_detach(netdev);
mutex_lock(&priv->state_lock);
@@ -2655,6 +2661,8 @@ static void mlx5e_destroy_netdev(struct mlx5_core_dev *mdev, void *vpriv)
mlx5_core_dealloc_transport_domain(priv->mdev, priv->tdn);
mlx5_core_dealloc_pd(priv->mdev, priv->pdn);
mlx5_unmap_free_uar(priv->mdev, &priv->cq_uar);
+ cancel_delayed_work_sync(&priv->update_stats_work);
+ destroy_workqueue(priv->wq);
if (!test_bit(MLX5_INTERFACE_STATE_SHUTDOWN, &mdev->intf_state))
free_netdev(netdev);
--
2.8.0
^ permalink raw reply related
* [PATCH net 4/4] net/mlx5e: Use workqueue for vxlan ops
From: Saeed Mahameed @ 2016-05-01 19:59 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Matthew Finlay,
Saeed Mahameed
In-Reply-To: <1462132797-22853-1-git-send-email-saeedm@mellanox.com>
From: Matthew Finlay <matt@mellanox.com>
The vxlan add/delete port NDOs are called under rcu lock.
The current mlx5e implementation can potentially block in these
calls, which is not allowed. Move to using the mlx5e workqueue
to handle these NDOs.
Fixes: b3f63c3d5e2c ('net/mlx5e: Add netdev support for VXLAN tunneling')
Signed-off-by: Matthew Finlay <matt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/vxlan.c | 50 +++++++++++++++++------
drivers/net/ethernet/mellanox/mlx5/core/vxlan.h | 11 ++++-
3 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 9ab0841..d4dfc5c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -2157,7 +2157,7 @@ static void mlx5e_add_vxlan_port(struct net_device *netdev,
if (!mlx5e_vxlan_allowed(priv->mdev))
return;
- mlx5e_vxlan_add_port(priv, be16_to_cpu(port));
+ mlx5e_vxlan_queue_work(priv, sa_family, be16_to_cpu(port), 1);
}
static void mlx5e_del_vxlan_port(struct net_device *netdev,
@@ -2168,7 +2168,7 @@ static void mlx5e_del_vxlan_port(struct net_device *netdev,
if (!mlx5e_vxlan_allowed(priv->mdev))
return;
- mlx5e_vxlan_del_port(priv, be16_to_cpu(port));
+ mlx5e_vxlan_queue_work(priv, sa_family, be16_to_cpu(port), 0);
}
static netdev_features_t mlx5e_vxlan_features_check(struct mlx5e_priv *priv,
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vxlan.c b/drivers/net/ethernet/mellanox/mlx5/core/vxlan.c
index 9f10df2..f2fd1ef 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vxlan.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vxlan.c
@@ -95,21 +95,22 @@ struct mlx5e_vxlan *mlx5e_vxlan_lookup_port(struct mlx5e_priv *priv, u16 port)
return vxlan;
}
-int mlx5e_vxlan_add_port(struct mlx5e_priv *priv, u16 port)
+static void mlx5e_vxlan_add_port(struct work_struct *work)
{
+ struct mlx5e_vxlan_work *vxlan_work =
+ container_of(work, struct mlx5e_vxlan_work, work);
+ struct mlx5e_priv *priv = vxlan_work->priv;
struct mlx5e_vxlan_db *vxlan_db = &priv->vxlan;
+ u16 port = vxlan_work->port;
struct mlx5e_vxlan *vxlan;
int err;
- err = mlx5e_vxlan_core_add_port_cmd(priv->mdev, port);
- if (err)
- return err;
+ if (mlx5e_vxlan_core_add_port_cmd(priv->mdev, port))
+ goto free_work;
vxlan = kzalloc(sizeof(*vxlan), GFP_KERNEL);
- if (!vxlan) {
- err = -ENOMEM;
+ if (!vxlan)
goto err_delete_port;
- }
vxlan->udp_port = port;
@@ -119,13 +120,14 @@ int mlx5e_vxlan_add_port(struct mlx5e_priv *priv, u16 port)
if (err)
goto err_free;
- return 0;
+ goto free_work;
err_free:
kfree(vxlan);
err_delete_port:
mlx5e_vxlan_core_del_port_cmd(priv->mdev, port);
- return err;
+free_work:
+ kfree(vxlan_work);
}
static void __mlx5e_vxlan_core_del_port(struct mlx5e_priv *priv, u16 port)
@@ -145,12 +147,36 @@ static void __mlx5e_vxlan_core_del_port(struct mlx5e_priv *priv, u16 port)
kfree(vxlan);
}
-void mlx5e_vxlan_del_port(struct mlx5e_priv *priv, u16 port)
+static void mlx5e_vxlan_del_port(struct work_struct *work)
{
- if (!mlx5e_vxlan_lookup_port(priv, port))
- return;
+ struct mlx5e_vxlan_work *vxlan_work =
+ container_of(work, struct mlx5e_vxlan_work, work);
+ struct mlx5e_priv *priv = vxlan_work->priv;
+ u16 port = vxlan_work->port;
__mlx5e_vxlan_core_del_port(priv, port);
+
+ kfree(vxlan_work);
+}
+
+void mlx5e_vxlan_queue_work(struct mlx5e_priv *priv, sa_family_t sa_family,
+ u16 port, int add)
+{
+ struct mlx5e_vxlan_work *vxlan_work;
+
+ vxlan_work = kmalloc(sizeof(*vxlan_work), GFP_ATOMIC);
+ if (!vxlan_work)
+ return;
+
+ if (add)
+ INIT_WORK(&vxlan_work->work, mlx5e_vxlan_add_port);
+ else
+ INIT_WORK(&vxlan_work->work, mlx5e_vxlan_del_port);
+
+ vxlan_work->priv = priv;
+ vxlan_work->port = port;
+ vxlan_work->sa_family = sa_family;
+ queue_work(priv->wq, &vxlan_work->work);
}
void mlx5e_vxlan_cleanup(struct mlx5e_priv *priv)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vxlan.h b/drivers/net/ethernet/mellanox/mlx5/core/vxlan.h
index a016850..129f352 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vxlan.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vxlan.h
@@ -39,6 +39,13 @@ struct mlx5e_vxlan {
u16 udp_port;
};
+struct mlx5e_vxlan_work {
+ struct work_struct work;
+ struct mlx5e_priv *priv;
+ sa_family_t sa_family;
+ u16 port;
+};
+
static inline bool mlx5e_vxlan_allowed(struct mlx5_core_dev *mdev)
{
return (MLX5_CAP_ETH(mdev, tunnel_stateless_vxlan) &&
@@ -46,8 +53,8 @@ static inline bool mlx5e_vxlan_allowed(struct mlx5_core_dev *mdev)
}
void mlx5e_vxlan_init(struct mlx5e_priv *priv);
-int mlx5e_vxlan_add_port(struct mlx5e_priv *priv, u16 port);
-void mlx5e_vxlan_del_port(struct mlx5e_priv *priv, u16 port);
+void mlx5e_vxlan_queue_work(struct mlx5e_priv *priv, sa_family_t sa_family,
+ u16 port, int add);
struct mlx5e_vxlan *mlx5e_vxlan_lookup_port(struct mlx5e_priv *priv, u16 port);
void mlx5e_vxlan_cleanup(struct mlx5e_priv *priv);
--
2.8.0
^ permalink raw reply related
* [PATCH net 1/4] net/mlx5: Unmap only the relevant IO memory mapping
From: Saeed Mahameed @ 2016-05-01 19:59 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Gal Pressman,
Saeed Mahameed
In-Reply-To: <1462132797-22853-1-git-send-email-saeedm@mellanox.com>
From: Gal Pressman <galp@mellanox.com>
When freeing UAR the driver tries to unmap uar->map and uar->bf_map
which are mutually exclusive thus always unmapping a NULL pointer.
Make sure we only call iounmap() once, for the actual mapping.
Fixes: 0ba422410bbf ('net/mlx5: Fix global UAR mapping')
Signed-off-by: Gal Pressman <galp@mellanox.com>
Reported-by: Doron Tsur <doront@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/uar.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/uar.c b/drivers/net/ethernet/mellanox/mlx5/core/uar.c
index 8ba080e..5ff8af4 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/uar.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/uar.c
@@ -269,8 +269,10 @@ EXPORT_SYMBOL(mlx5_alloc_map_uar);
void mlx5_unmap_free_uar(struct mlx5_core_dev *mdev, struct mlx5_uar *uar)
{
- iounmap(uar->map);
- iounmap(uar->bf_map);
+ if (uar->map)
+ iounmap(uar->map);
+ else
+ iounmap(uar->bf_map);
mlx5_cmd_free_uar(mdev, uar->index);
}
EXPORT_SYMBOL(mlx5_unmap_free_uar);
--
2.8.0
^ permalink raw reply related
* [PATCH net 0/4] Mellanox 100G mlx5 fixes for 4.6-rc
From: Saeed Mahameed @ 2016-05-01 19:59 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Or Gerlitz, Tal Alon, Eran Ben Elisha, Saeed Mahameed
Hi Dave,
This small series provides some bug fixes for mlx5 driver.
A small bug fix for iounmap of a null pointer, which dumps a warning on some archs.
One patch to fix the VXLAN/MLX5_EN dependency issue reported by Arnd.
Two patches to fix the scheduling while atomic issue for ndo_add/del_vxlan_port
NDOs. The first will add an internal mlx5e workqueue and the second will
delegate vxlan ports add/del requests to that workqueue.
Note: ('net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue') is only needed for net
and not net-next as the issue was globally fixed for all device drivers by:
b7aade15485a ('vxlan: break dependency with netdev drivers') in net-next.
Applied on top: f27337e16f2d ('ip_tunnel: fix preempt warning in ip tunnel creation/updating')
Gal Pressman (1):
net/mlx5: Unmap only the relevant IO memory mapping
Matthew Finlay (3):
net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue
net/mlx5e: Implement a mlx5e workqueue
net/mlx5e: Use workqueue for vxlan ops
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 34 +++++++++------
drivers/net/ethernet/mellanox/mlx5/core/uar.c | 6 ++-
drivers/net/ethernet/mellanox/mlx5/core/vxlan.c | 50 +++++++++++++++++------
drivers/net/ethernet/mellanox/mlx5/core/vxlan.h | 11 ++++-
6 files changed, 74 insertions(+), 29 deletions(-)
--
2.8.0
^ permalink raw reply
* [PATCH] rtlwifi: rtl818x: constify rtl_intf_ops structures
From: Julia Lawall @ 2016-05-01 19:57 UTC (permalink / raw)
To: Larry Finger
Cc: kernel-janitors, Chaoming Li, Kalle Valo, linux-wireless, netdev,
linux-kernel
The rtl_intf_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/pci.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/usb.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 1ac41b8..66030ea 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -2456,7 +2456,7 @@ int rtl_pci_resume(struct device *dev)
EXPORT_SYMBOL(rtl_pci_resume);
#endif /* CONFIG_PM_SLEEP */
-struct rtl_intf_ops rtl_pci_ops = {
+const struct rtl_intf_ops rtl_pci_ops = {
.read_efuse_byte = read_efuse_byte,
.adapter_start = rtl_pci_start,
.adapter_stop = rtl_pci_stop,
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.h b/drivers/net/wireless/realtek/rtlwifi/pci.h
index 5da6703..b951eba 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.h
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.h
@@ -286,7 +286,7 @@ struct rtl_pci_priv {
int rtl_pci_reset_trx_ring(struct ieee80211_hw *hw);
-extern struct rtl_intf_ops rtl_pci_ops;
+extern const struct rtl_intf_ops rtl_pci_ops;
int rtl_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *id);
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index aac1ed3..41617b7 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -1049,7 +1049,7 @@ static void rtl_fill_h2c_cmd_work_callback(struct work_struct *work)
rtlpriv->cfg->ops->fill_h2c_cmd(hw, H2C_RA_MASK, 5, rtlpriv->rate_mask);
}
-static struct rtl_intf_ops rtl_usb_ops = {
+static const struct rtl_intf_ops rtl_usb_ops = {
.adapter_start = rtl_usb_start,
.adapter_stop = rtl_usb_stop,
.adapter_tx = rtl_usb_tx,
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 11d9c23..4e0ab4d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2593,7 +2593,7 @@ struct rtl_priv {
*intf_ops : for diff interrface usb/pcie
*/
struct rtl_hal_cfg *cfg;
- struct rtl_intf_ops *intf_ops;
+ const struct rtl_intf_ops *intf_ops;
/*this var will be set by set_bit,
and was used to indicate status of
^ permalink raw reply related
* Re: [PATCH net-next] drivers/net: add 6WIND SHULTI support
From: Jiri Pirko @ 2016-05-01 19:53 UTC (permalink / raw)
To: David Miller; +Cc: nicolas.dichtel, fw, netdev
In-Reply-To: <20160428.115419.1831238411921569629.davem@davemloft.net>
Thu, Apr 28, 2016 at 05:54:19PM CEST, davem@davemloft.net wrote:
>From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>Date: Thu, 28 Apr 2016 13:59:34 +0200
>
>> Le 27/04/2016 18:55, David Miller a écrit :
>>> From: Jiri Pirko <jiri@resnulli.us>
>> [snip]
>>>> The difference is that it this tries to allow userspace crap to mirror
>>>> setting user does for bridge/ovs. Basically this looks to me like an
>>>> attempt to enable userspace SDKs and such.
>>>
>>> +1
>> I don't think so because a userspace can receive all the bridge/ovs settings by
>> mean of netlink mirror, without the need for this driver at all.
>
>You can say whatever you want, but the facilities you are adding to
>this driver enables proprietary userland SDK components.
>
>And this is precisely what we are trying to avoid by having a clean,
>fully featured switch device model in the kernel.
>
>It is against your interestes of upstreaming your driver to continue
>denying what your changes facilitate.
+1
Nicolas, your driver is big a step back. Just do what you need to do,
properly, in kernel. There's a lot of people to help you with that
around.
^ permalink raw reply
* Re: Cannot use NFS with linux-next 20160429
From: Chuck Lever @ 2016-05-01 19:52 UTC (permalink / raw)
To: Fabio Estevam
Cc: Trond Myklebust, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux NFS Mailing List
In-Reply-To: <CAOMZO5D9dTFRbT0CMOdM3aGb1cLd+n8udQQH0K=onZ7Z-4onmw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Fabio-
> On Apr 29, 2016, at 7:18 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hi,
>
> NFS is not working on a imx6q-sabresd board running linux-next 20160429:
>
> [ 15.753317] #0: wm8962-audio
> [ 15.759437] Root-NFS: no NFS server address
At a glance, that looks like the NFSROOT mount options are
invalid? First, confirm what is specified on the kernel
cmdline.
I'm not aware of any recent changes to NFSROOT. Often
these NFSROOT problems turn out to be related to churn in
the underlying Ethernet drivers or the generic code that
handles mounting the root filesystem at boot time.
Thus a second suggestion would be to use "git bisect".
> [ 15.763649] VFS: Unable to mount root fs via NFS, trying floppy.
> [ 15.774223] VFS: Cannot open root device "nfs" or
> unknown-block(2,0): error -6
> [ 15.781540] Please append a correct "root=" boot option; here are
> the available partitions:
> [ 15.790145] 0100 65536 ram0 (driver?)
> [ 15.794837] 0101 65536 ram1 (driver?)
> [ 15.799576] 0102 65536 ram2 (driver?)
> [ 15.804262] 0103 65536 ram3 (driver?)
> [ 15.809023] 0104 65536 ram4 (driver?)
> [ 15.813710] 0105 65536 ram5 (driver?)
> [ 15.818392] 0106 65536 ram6 (driver?)
> [ 15.823121] 0107 65536 ram7 (driver?)
> [ 15.827804] 0108 65536 ram8 (driver?)
> [ 15.832531] 0109 65536 ram9 (driver?)
> [ 15.837213] 010a 65536 ram10 (driver?)
> [ 15.841989] 010b 65536 ram11 (driver?)
> [ 15.846729] 010c 65536 ram12 (driver?)
> [ 15.851491] 010d 65536 ram13 (driver?)
> [ 15.856228] 010e 65536 ram14 (driver?)
> [ 15.860992] 010f 65536 ram15 (driver?)
> [ 15.865742] 1f00 4096 mtdblock0 (driver?)
> [ 15.870853] b300 3872256 mmcblk1 driver: mmcblk
> [ 15.876199] b308 7757824 mmcblk2 driver: mmcblk
> [ 15.881570] b320 128 mmcblk2rpmb (driver?)
> [ 15.886830] b318 1024 mmcblk2boot1 (driver?)
> [ 15.892201] b310 1024 mmcblk2boot0 (driver?)
> [ 15.897541] Kernel panic - not syncing: VFS: Unable to mount root
> fs on unknown-block(2,0)
> [ 15.905978] CPU0: stopping
> [ 15.908704] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 4.6.0-rc5-next-20160429 #349
> [ 15.916284] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 15.922818] Backtrace:
> [ 15.925316] [<c010b6f8>] (dump_backtrace) from [<c010b894>]
> (show_stack+0x18/0x1c)
> [ 15.932893] r6:60000193 r5:ffffffff r4:00000000 r3:00000000
> [ 15.938649] [<c010b87c>] (show_stack) from [<c03df190>]
> (dump_stack+0xb0/0xe8)
> [ 15.945889] [<c03df0e0>] (dump_stack) from [<c010edec>]
> (handle_IPI+0x174/0x1a4)
> [ 15.953292] r8:c0d01f08 r7:c0c746ec r6:00000000 r5:c0d02b10
> r4:00000000 r3:c0d05e80
> [ 15.961147] [<c010ec78>] (handle_IPI) from [<c0101618>]
> (gic_handle_irq+0x8c/0x9c)
> [ 15.968722] r8:c0d21f80 r7:c0d02c58 r6:c0d01f08 r5:f400010c
> r4:f4000100 r3:00000c04
> [ 15.976573] [<c010158c>] (gic_handle_irq) from [<c010c4b8>]
> (__irq_svc+0x58/0x78)
> [ 15.984065] Exception stack(0xc0d01f08 to 0xc0d01f50)
> [ 15.989129] 1f00: 00000001 00000001 00000000
> c011b920 00000000 c0d02984
> [ 15.997318] 1f20: 00000000 00000000 c0c757b8 c0d029d8 c0d029d0
> c0d01f64 c0d01f28 c0d01f58
> [ 16.005505] 1f40: c016d120 c01089e0 20000013 ffffffff
> [ 16.010563] r10:c0d029d0 r9:c0d029d8 r8:c0c757b8 r7:c0d01f3c
> r6:ffffffff r5:20000013
> [ 16.018495] r4:c01089e0 r3:c0d05e80
> [ 16.022130] [<c01089b8>] (arch_cpu_idle) from [<c01661a0>]
> (default_idle_call+0x28/0x38)
> [ 16.030236] [<c0166178>] (default_idle_call) from [<c0166378>]
> (cpu_startup_entry+0x1c8/0x24c)
> [ 16.038864] [<c01661b0>] (cpu_startup_entry) from [<c08edd78>]
> (rest_init+0x12c/0x16c)
> [ 16.046788] r7:c0c5da48 r3:00000000
> [ 16.050417] [<c08edc4c>] (rest_init) from [<c0c00cbc>]
> (start_kernel+0x340/0x3b0)
> [ 16.057906] r5:ffffffff r4:c0d6e050
> [ 16.061532] [<c0c0097c>] (start_kernel) from [<1000807c>] (0x1000807c)
> [ 16.068067] r10:00000000 r8:1000406a r7:c0d0780c r6:c0c5da44
> r5:c0d0296c r4:c0d6e294
> [ 16.076002] CPU2: stopping
> [ 16.078725] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
> 4.6.0-rc5-next-20160429 #349
> [ 16.086302] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 16.092836] Backtrace:
> [ 16.095320] [<c010b6f8>] (dump_backtrace) from [<c010b894>]
> (show_stack+0x18/0x1c)
> [ 16.102897] r6:60000193 r5:ffffffff r4:00000000 r3:00000000
> [ 16.108646] [<c010b87c>] (show_stack) from [<c03df190>]
> (dump_stack+0xb0/0xe8)
> [ 16.115883] [<c03df0e0>] (dump_stack) from [<c010edec>]
> (handle_IPI+0x174/0x1a4)
> [ 16.123286] r8:ef0a5f58 r7:c0c746ec r6:00000000 r5:c0d02b10
> r4:00000002 r3:ef0a8000
> [ 16.131138] [<c010ec78>] (handle_IPI) from [<c0101618>]
> (gic_handle_irq+0x8c/0x9c)
> [ 16.138713] r8:c0d21f80 r7:c0d02c58 r6:ef0a5f58 r5:f400010c
> r4:f4000100 r3:00000c04
> [ 16.146562] [<c010158c>] (gic_handle_irq) from [<c010c4b8>]
> (__irq_svc+0x58/0x78)
> [ 16.154052] Exception stack(0xef0a5f58 to 0xef0a5fa0)
> [ 16.159112] 5f40:
> 00000001 00000001
> [ 16.167301] 5f60: 00000000 c011b920 00000000 c0d02984 00000000
> 00000000 c0c757b8 c0d029d8
> [ 16.175489] 5f80: c0d029d0 ef0a5fb4 ef0a5f78 ef0a5fa8 c016d120
> c01089e0 20000013 ffffffff
> [ 16.183672] r10:c0d029d0 r9:c0d029d8 r8:c0c757b8 r7:ef0a5f8c
> r6:ffffffff r5:20000013
> [ 16.191601] r4:c01089e0 r3:ef0a8000
> [ 16.195230] [<c01089b8>] (arch_cpu_idle) from [<c01661a0>]
> (default_idle_call+0x28/0x38)
> [ 16.203334] [<c0166178>] (default_idle_call) from [<c0166378>]
> (cpu_startup_entry+0x1c8/0x24c)
> [ 16.211959] [<c01661b0>] (cpu_startup_entry) from [<c010ea14>]
> (secondary_start_kernel+0x130/0x154)
> [ 16.221010] r7:c0d6e388 r3:00000004
> [ 16.224633] [<c010e8e4>] (secondary_start_kernel) from [<101016cc>]
> (0x101016cc)
> [ 16.232035] r5:00000051 r4:3f08806a
> [ 16.235656] CPU1: stopping
> [ 16.238378] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
> 4.6.0-rc5-next-20160429 #349
> [ 16.245954] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 16.252487] Backtrace:
> [ 16.254970] [<c010b6f8>] (dump_backtrace) from [<c010b894>]
> (show_stack+0x18/0x1c)
> [ 16.262545] r6:60000193 r5:ffffffff r4:00000000 r3:00000000
> [ 16.268291] [<c010b87c>] (show_stack) from [<c03df190>]
> (dump_stack+0xb0/0xe8)
> [ 16.275529] [<c03df0e0>] (dump_stack) from [<c010edec>]
> (handle_IPI+0x174/0x1a4)
> [ 16.282931] r8:ef0a3f58 r7:c0c746ec r6:00000000 r5:c0d02b10
> r4:00000001 r3:ef076c00
> [ 16.290777] [<c010ec78>] (handle_IPI) from [<c0101618>]
> (gic_handle_irq+0x8c/0x9c)
> [ 16.298353] r8:c0d21f80 r7:c0d02c58 r6:ef0a3f58 r5:f400010c
> r4:f4000100 r3:00000c04
> [ 16.306199] [<c010158c>] (gic_handle_irq) from [<c010c4b8>]
> (__irq_svc+0x58/0x78)
> [ 16.313688] Exception stack(0xef0a3f58 to 0xef0a3fa0)
> [ 16.318747] 3f40:
> 00000001 00000001
> [ 16.326935] 3f60: 00000000 c011b920 00000000 c0d02984 00000000
> 00000000 c0c757b8 c0d029d8
> [ 16.335123] 3f80: c0d029d0 ef0a3fb4 ef0a3f78 ef0a3fa8 c016d120
> c01089e0 20000013 ffffffff
> [ 16.343304] r10:c0d029d0 r9:c0d029d8 r8:c0c757b8 r7:ef0a3f8c
> r6:ffffffff r5:20000013
> [ 16.351230] r4:c01089e0 r3:ef076c00
> [ 16.354856] [<c01089b8>] (arch_cpu_idle) from [<c01661a0>]
> (default_idle_call+0x28/0x38)
> [ 16.362961] [<c0166178>] (default_idle_call) from [<c0166378>]
> (cpu_startup_entry+0x1c8/0x24c)
> [ 16.371585] [<c01661b0>] (cpu_startup_entry) from [<c010ea14>]
> (secondary_start_kernel+0x130/0x154)
> [ 16.380635] r7:c0d6e388 r3:00000002
> [ 16.384256] [<c010e8e4>] (secondary_start_kernel) from [<101016cc>]
> (0x101016cc)
> [ 16.391657] r5:00000051 r4:3f08806a
> [ 16.395300] ---[ end Kernel panic - not syncing: VFS: Unable to
> mount root fs on unknown-block(2,0)
>
> Any ideas? Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: Q: How to disable vlan strip in Intel igb driver ?
From: Ran Shalit @ 2016-05-01 18:48 UTC (permalink / raw)
To: Peter Palúch; +Cc: netdev, alexander.duyck
In-Reply-To: <afa69dcb-0905-a556-0208-49a2363ae818@fri.uniza.sk>
>> Ran
>
> You should be able to turn off the offload by setting
> "rx-vlan-offload" to "off" via "ethtool -K".
>
> - Alex
Alex,
I don't see rx-vlan-offload option in my ethtool. strange, maybe it is
not available in all ethtool versions ?
On Sun, May 1, 2016 at 9:22 PM, Peter Palúch <Peter.Paluch@fri.uniza.sk> wrote:
> Ran,
>
> How are you accessing the VLAN tag information - and how do you know that
> the VLAN tag is not being passed through? Are you using AF_PACKET socket in
> your application?
>
> Best regards,
> Peter
>
>
Hi Peter,
Yes, I'm using AF_PACKET (I can't validate it now for 100%, but I
quite sure about it).
I'm accessing the ethernet header, and it always gives me non extended
ethernet header (without vlan information).
I can see the vlan tag in vlan_tci field in sk_buff, but this is not
exactly what I need, I need the header AS-IS with the original
(extended) ethernet header.
Thanks.
Ran
>
> On 01.05.2016 15:13, Ran Shalit wrote:
>>
>> Hello,
>>
>>
>> I am using intel igb driver in Linux.
>>
>> The driver strip the packet from vlan inofmation. But we need this
>> information in the packet.
>>
>> We tried to change build flag, or see if there is any feature with
>> ethtool that can disable this feature, but nothing helps.
>>
>>
>> Is there any way to achive this ?
>>
>> Regards,
>>
>> Ran
>
>
^ permalink raw reply
* Re: Q: How to disable vlan strip in Intel igb driver ?
From: Peter Palúch @ 2016-05-01 18:22 UTC (permalink / raw)
To: Ran Shalit, netdev
In-Reply-To: <CAJ2oMhKyMbgLZiGSGQxRGVdbGARvMHeO3=vpgO0uOzOBqvf79Q@mail.gmail.com>
Ran,
How are you accessing the VLAN tag information - and how do you know
that the VLAN tag is not being passed through? Are you using AF_PACKET
socket in your application?
Best regards,
Peter
On 01.05.2016 15:13, Ran Shalit wrote:
> Hello,
>
>
> I am using intel igb driver in Linux.
>
> The driver strip the packet from vlan inofmation. But we need this
> information in the packet.
>
> We tried to change build flag, or see if there is any feature with
> ethtool that can disable this feature, but nothing helps.
>
>
> Is there any way to achive this ?
>
> Regards,
>
> Ran
^ permalink raw reply
* Re: Q: How to disable vlan strip in Intel igb driver ?
From: Alexander Duyck @ 2016-05-01 17:08 UTC (permalink / raw)
To: Ran Shalit, e1000-devel@lists.sourceforge.net; +Cc: Netdev
In-Reply-To: <CAJ2oMhKyMbgLZiGSGQxRGVdbGARvMHeO3=vpgO0uOzOBqvf79Q@mail.gmail.com>
On Sun, May 1, 2016 at 6:13 AM, Ran Shalit <ranshalit@gmail.com> wrote:
> Hello,
>
>
> I am using intel igb driver in Linux.
>
> The driver strip the packet from vlan inofmation. But we need this
> information in the packet.
>
> We tried to change build flag, or see if there is any feature with
> ethtool that can disable this feature, but nothing helps.
>
>
> Is there any way to achive this ?
>
> Regards,
>
> Ran
You should be able to turn off the offload by setting
"rx-vlan-offload" to "off" via "ethtool -K".
- Alex
^ permalink raw reply
* Re: [PATCH] pxa168_eth: fix mdiobus_scan() error check
From: Florian Fainelli @ 2016-05-01 16:05 UTC (permalink / raw)
To: Sergei Shtylyov, netdev; +Cc: arnd
In-Reply-To: <6024241.YxM8l6DPJo@wasted.cogentembedded.com>
Le 30/04/2016 13:35, Sergei Shtylyov a écrit :
> Since mdiobus_scan() returns either an error code or NULL on error, the
> driver should check for both, not only for NULL, otherwise a crash is
> imminent...
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against DaveM's 'net.git' repo.
>
> drivers/net/ethernet/marvell/pxa168_eth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: net/drivers/net/ethernet/marvell/pxa168_eth.c
> ===================================================================
> --- net.orig/drivers/net/ethernet/marvell/pxa168_eth.c
> +++ net/drivers/net/ethernet/marvell/pxa168_eth.c
> @@ -979,6 +979,8 @@ static int pxa168_init_phy(struct net_de
> return 0;
>
> pep->phy = mdiobus_scan(pep->smi_bus, pep->phy_addr);
> + if (IS_ERR(pep->phy))
> + return PTR_ERR(pep->phy);
> if (!pep->phy)
> return -ENODEV;
Should not this check be removed too and converted to a
PTR_ERR(pep->phy) != -ENODEV?
--
Florian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox