* [PATCH v3 net-next 0/4] macb: Introduce phy-handle DT functionality
From: Brad Mouring @ 2018-03-12 17:09 UTC (permalink / raw)
To: Nicolas Ferre, Rob Herring, David S . Miller, Michael Grzeschik,
Andrew Lunn
Cc: Mark Rutland, netdev, Julia Cartwright, devicetree
In-Reply-To: <20180310161718.GC29174@lunn.ch>
Consider the situation where a macb netdev is connected through
a phydev that sits on a mii bus other than the one provided to
this particular netdev. This situation is what this patchset aims
to accomplish through the existing phy-handle optional binding.
This optional binding (as described in the ethernet DT bindings doc)
directs the netdev to the phydev to use. This is precisely the
situation this patchset aims to solve, so it makes sense to introduce
the functionality to this driver (where the physical layout discussed
was encountered).
The devicetree snippet would look something like this:
...
ethernet@feedf00d {
...
phy-handle = <&phy0> // the first netdev is physically wired to phy0
...
phy0: phy@0 {
...
reg = <0x0> // MDIO address 0
...
}
phy1: phy@1 {
...
reg = <0x1> // MDIO address 1
...
}
...
}
ethernet@deadbeef {
...
phy-handle = <&phy1> // tells the driver to use phy1 on the
// first mac's mdio bus (it's wired thusly)
...
}
...
The work done to add the phy_node in the first place (dacdbb4dfc1a1:
"net: macb: add fixed-link node support") will consume the
device_node (if found).
v2: Reorganization of mii probe/init functions, suggested by Andrew Lunn
v3: Moved some of the bus init code back into init (erroneously moved to probe)
some style issues, and an unintialized variable warning addressed.
^ permalink raw reply
* [PATCH v3 net-next 1/4] net: macb: Reorganize macb_mii bringup
From: Brad Mouring @ 2018-03-12 17:09 UTC (permalink / raw)
To: Nicolas Ferre, Rob Herring, David S . Miller, Michael Grzeschik,
Andrew Lunn
Cc: Mark Rutland, netdev, Julia Cartwright, devicetree, Brad Mouring
In-Reply-To: <20180312171001.129209-1-brad.mouring@ni.com>
The macb mii setup (mii_probe() and mii_init()) previously was
somewhat interspersed, likely a result of organic growth and hacking.
This change moves mii bus registration into mii_init and probing the
bus for devices into mii_probe.
Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/ethernet/cadence/macb_main.c | 79 +++++++++++++++++---------------
1 file changed, 41 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index e84afcf1ecb5..9b6195fbbf8e 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -472,8 +472,42 @@ static int macb_mii_probe(struct net_device *dev)
struct macb *bp = netdev_priv(dev);
struct macb_platform_data *pdata;
struct phy_device *phydev;
- int phy_irq;
- int ret;
+ struct device_node *np;
+ int phy_irq, ret, i;
+
+ pdata = dev_get_platdata(&bp->pdev->dev);
+ np = bp->pdev->dev.of_node;
+ ret = 0;
+
+ if (np) {
+ if (of_phy_is_fixed_link(np)) {
+ if (of_phy_register_fixed_link(np) < 0) {
+ dev_err(&bp->pdev->dev,
+ "broken fixed-link specification\n");
+ return -ENODEV;
+ }
+ bp->phy_node = of_node_get(np);
+ } else {
+ /* fallback to standard phy registration if no phy were
+ * found during dt phy registration
+ */
+ if (!phy_find_first(bp->mii_bus)) {
+ for (i = 0; i < PHY_MAX_ADDR; i++) {
+ struct phy_device *phydev;
+
+ phydev = mdiobus_scan(bp->mii_bus, i);
+ if (IS_ERR(phydev) &&
+ PTR_ERR(phydev) != -ENODEV) {
+ ret = PTR_ERR(phydev);
+ break;
+ }
+ }
+
+ if (ret)
+ return -ENODEV;
+ }
+ }
+ }
if (bp->phy_node) {
phydev = of_phy_connect(dev, bp->phy_node,
@@ -488,7 +522,6 @@ static int macb_mii_probe(struct net_device *dev)
return -ENXIO;
}
- pdata = dev_get_platdata(&bp->pdev->dev);
if (pdata) {
if (gpio_is_valid(pdata->phy_irq_pin)) {
ret = devm_gpio_request(&bp->pdev->dev,
@@ -533,7 +566,7 @@ static int macb_mii_init(struct macb *bp)
{
struct macb_platform_data *pdata;
struct device_node *np;
- int err = -ENXIO, i;
+ int err;
/* Enable management port */
macb_writel(bp, NCR, MACB_BIT(MPE));
@@ -556,39 +589,9 @@ static int macb_mii_init(struct macb *bp)
dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
np = bp->pdev->dev.of_node;
- if (np) {
- if (of_phy_is_fixed_link(np)) {
- if (of_phy_register_fixed_link(np) < 0) {
- dev_err(&bp->pdev->dev,
- "broken fixed-link specification\n");
- goto err_out_unregister_bus;
- }
- bp->phy_node = of_node_get(np);
-
- err = mdiobus_register(bp->mii_bus);
- } else {
- /* try dt phy registration */
- err = of_mdiobus_register(bp->mii_bus, np);
-
- /* fallback to standard phy registration if no phy were
- * found during dt phy registration
- */
- if (!err && !phy_find_first(bp->mii_bus)) {
- for (i = 0; i < PHY_MAX_ADDR; i++) {
- struct phy_device *phydev;
-
- phydev = mdiobus_scan(bp->mii_bus, i);
- if (IS_ERR(phydev) &&
- PTR_ERR(phydev) != -ENODEV) {
- err = PTR_ERR(phydev);
- break;
- }
- }
- if (err)
- goto err_out_unregister_bus;
- }
- }
+ if (np) {
+ err = of_mdiobus_register(bp->mii_bus, np);
} else {
for (i = 0; i < PHY_MAX_ADDR; i++)
bp->mii_bus->irq[i] = PHY_POLL;
@@ -610,10 +613,10 @@ static int macb_mii_init(struct macb *bp)
err_out_unregister_bus:
mdiobus_unregister(bp->mii_bus);
-err_out_free_mdiobus:
- of_node_put(bp->phy_node);
if (np && of_phy_is_fixed_link(np))
of_phy_deregister_fixed_link(np);
+err_out_free_mdiobus:
+ of_node_put(bp->phy_node);
mdiobus_free(bp->mii_bus);
err_out:
return err;
--
2.16.2
^ permalink raw reply related
* [PATCH v3 net-next 3/4] net: macb: Add phy-handle DT support
From: Brad Mouring @ 2018-03-12 17:10 UTC (permalink / raw)
To: Nicolas Ferre, Rob Herring, David S . Miller, Michael Grzeschik,
Andrew Lunn
Cc: Mark Rutland, netdev, Julia Cartwright, devicetree, Brad Mouring
In-Reply-To: <20180312171001.129209-1-brad.mouring@ni.com>
This optional binding (as described in the ethernet DT bindings doc)
directs the netdev to the phydev to use. This is useful for a phy
chip that has >1 phy in it, and two netdevs are using the same phy
chip (i.e. the second mac's phy lives on the first mac's MDIO bus)
The devicetree snippet would look something like this:
ethernet@feedf00d {
...
phy-handle = <&phy0> // the first netdev is physically wired to phy0
...
phy0: phy@0 {
...
reg = <0x0> // MDIO address 0
...
}
phy1: phy@1 {
...
reg = <0x1> // MDIO address 1
...
}
...
}
ethernet@deadbeef {
...
phy-handle = <&phy1> // tells the driver to use phy1 on the
// first mac's mdio bus (it's wired thusly)
...
}
The work done to add the phy_node in the first place (dacdbb4dfc1a1:
"net: macb: add fixed-link node support") will consume the
device_node (if found).
Signed-off-by: Brad Mouring <brad.mouring@ni.com>
---
drivers/net/ethernet/cadence/macb_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index db1dc301bed3..b0700a531f3e 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -488,6 +488,9 @@ static int macb_mii_probe(struct net_device *dev)
}
bp->phy_node = of_node_get(np);
} else {
+ /* attempt to find a phy-handle */
+ bp->phy_node = of_parse_phandle(np, "phy-handle", 0);
+
/* fallback to standard phy registration if no phy were
* found during dt phy registration
*/
--
2.16.2
^ permalink raw reply related
* [PATCH v3 net-next 4/4] Documentation: macb: Document phy-handle binding
From: Brad Mouring @ 2018-03-12 17:10 UTC (permalink / raw)
To: Nicolas Ferre, Rob Herring, David S . Miller, Michael Grzeschik,
Andrew Lunn
Cc: Mark Rutland, netdev, Julia Cartwright, devicetree, Brad Mouring
In-Reply-To: <20180312171001.129209-1-brad.mouring@ni.com>
Document the existance of the optional binding, directing to the
general ethernet document that describes this binding.
Signed-off-by: Brad Mouring <brad.mouring@ni.com>
---
Documentation/devicetree/bindings/net/macb.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 27966ae741e0..457d5ae16f23 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -29,6 +29,7 @@ Optional properties for PHY child node:
- reset-gpios : Should specify the gpio for phy reset
- magic-packet : If present, indicates that the hardware supports waking
up via magic packet.
+- phy-handle : see ethernet.txt file in the same directory
Examples:
--
2.16.2
^ permalink raw reply related
* [PATCH v3 net-next 2/4] net: macb: Remove redundant poll irq assignment
From: Brad Mouring @ 2018-03-12 17:09 UTC (permalink / raw)
To: Nicolas Ferre, Rob Herring, David S . Miller, Michael Grzeschik,
Andrew Lunn
Cc: Mark Rutland, netdev, Julia Cartwright, devicetree, Brad Mouring
In-Reply-To: <20180312171001.129209-1-brad.mouring@ni.com>
In phy_device's general probe, this device will already be set for
phy register polling, rendering this code redundant.
Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/ethernet/cadence/macb_main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 9b6195fbbf8e..db1dc301bed3 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -593,9 +593,6 @@ static int macb_mii_init(struct macb *bp)
if (np) {
err = of_mdiobus_register(bp->mii_bus, np);
} else {
- for (i = 0; i < PHY_MAX_ADDR; i++)
- bp->mii_bus->irq[i] = PHY_POLL;
-
if (pdata)
bp->mii_bus->phy_mask = pdata->phy_mask;
--
2.16.2
^ permalink raw reply related
* Re: [PATCH net v2 2/2] l2tp: fix races with ipv4-mapped ipv6 addresses
From: Guillaume Nault @ 2018-03-12 17:11 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, James Chapman, Wei Wang, David Ahern
In-Reply-To: <1520844798.2585.13.camel@redhat.com>
On Mon, Mar 12, 2018 at 09:53:18AM +0100, Paolo Abeni wrote:
> On Fri, 2018-03-09 at 19:26 +0100, Guillaume Nault wrote:
> > On Fri, Mar 09, 2018 at 06:58:00PM +0100, Paolo Abeni wrote:
> > > The single threaded reproducer does not trigger anymore after 1/2,
> > > _but_ if ask syzbot to test 1/2 that will trigger another splat,
> > > because syzbot will do also multi threaded tests and we will hit the
> > > race between connect(tunnel->fd) and l2tp_tunnel_create(),
> > >
> >
> > Ok, and this case is handled by the sk_state test in l2tp_xmit_skb(),
> > right?
>
> We need both such test and checking for v4mapped address in
> l2tp_xmit_skb()
>
> > I just want to be sure that I didn't miss anything and that patch 1/2
> > combined with the socket state check in l2tp_xmit_skb() are enough to
> > fix the bug. And that overriding ->inet_*addr can be removed entirely
> > (and safely!).
>
> I tested the above in vs the repro and in some real use case, but any
> additinal pair of eyes are welcome!
>
It looks good to me too. I think everything is cleared up now.
Nice work!
^ permalink raw reply
* Re: [PATCH net v3 0/2] l2tp: fix races with ipv4-mapped ipv6 addresses
From: Guillaume Nault @ 2018-03-12 17:14 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, James Chapman, Wei Wang, David Ahern
In-Reply-To: <cover.1520861342.git.pabeni@redhat.com>
On Mon, Mar 12, 2018 at 02:54:22PM +0100, Paolo Abeni wrote:
> The syzbot reported an l2tp oops that uncovered some races in the l2tp xmit
> path and a partially related issue in the generic ipv6 code.
>
> We need to address them separately.
>
Thanks a lot Paolo!
For the whole series:
Reviewed-by: Guillaume Nault <g.nault@alphalink.fr>
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-testing: updated gact tests with batch test cases
From: Roman Mashak @ 2018-03-12 17:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <20180312.124255.1786337931041686412.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Roman Mashak <mrv@mojatatu.com>
> Date: Mon, 12 Mar 2018 12:39:57 -0400
>
>> David Miller <davem@davemloft.net> writes:
>>
>>> From: Roman Mashak <mrv@mojatatu.com>
>>> Date: Fri, 9 Mar 2018 17:16:12 -0500
>>>
>>>> Add test cases to exercise code paths responsible for adding or deleting
>>>> batch of TC actions.
>>>>
>>>> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
>>>
>>> You submitted this patch twice.
>>>
>>> You didn't indicate if this is a new version of the patch or something
>>> like this.
>>>
>>
>> Sorry for that glitch, I've just resent the patch.
>>
>>> Please resubmit your tc-testing changes, all of them, with this
>>> sorted out.
>
> I said "all of your tc-testing changes" not just this one.
On March 9th I submitted two tc-testing patches:
- "add TC vlan action tests"
- "updated gact tests with batch test cases" (which I resent)
Do you want to have those submitted as series?
^ permalink raw reply
* Re: [PATCH v3 net-next 1/4] net: macb: Reorganize macb_mii bringup
From: Florian Fainelli @ 2018-03-12 17:17 UTC (permalink / raw)
To: Brad Mouring, Nicolas Ferre, Rob Herring, David S . Miller,
Michael Grzeschik, Andrew Lunn
Cc: Mark Rutland, netdev, Julia Cartwright, devicetree
In-Reply-To: <20180312171001.129209-2-brad.mouring@ni.com>
On 03/12/2018 10:09 AM, Brad Mouring wrote:
> The macb mii setup (mii_probe() and mii_init()) previously was
> somewhat interspersed, likely a result of organic growth and hacking.
>
> This change moves mii bus registration into mii_init and probing the
> bus for devices into mii_probe.
>
> Signed-off-by: Brad Mouring <brad.mouring@ni.com>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 79 +++++++++++++++++---------------
> 1 file changed, 41 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index e84afcf1ecb5..9b6195fbbf8e 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -472,8 +472,42 @@ static int macb_mii_probe(struct net_device *dev)
> struct macb *bp = netdev_priv(dev);
> struct macb_platform_data *pdata;
> struct phy_device *phydev;
> - int phy_irq;
> - int ret;
> + struct device_node *np;
> + int phy_irq, ret, i;
> +
> + pdata = dev_get_platdata(&bp->pdev->dev);
> + np = bp->pdev->dev.of_node;
> + ret = 0;
> +
> + if (np) {
Nit: a future cleanup (not this patch series) should consider doing an
early check on np to reduce the indentation.
--
Florian
^ permalink raw reply
* Re: [PATCH v3 net-next 2/4] net: macb: Remove redundant poll irq assignment
From: Florian Fainelli @ 2018-03-12 17:17 UTC (permalink / raw)
To: Brad Mouring, Nicolas Ferre, Rob Herring, David S . Miller,
Michael Grzeschik, Andrew Lunn
Cc: Mark Rutland, netdev, Julia Cartwright, devicetree
In-Reply-To: <20180312171001.129209-3-brad.mouring@ni.com>
On 03/12/2018 10:09 AM, Brad Mouring wrote:
> In phy_device's general probe, this device will already be set for
> phy register polling, rendering this code redundant.
>
> Signed-off-by: Brad Mouring <brad.mouring@ni.com>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 net-next 4/4] Documentation: macb: Document phy-handle binding
From: Florian Fainelli @ 2018-03-12 17:18 UTC (permalink / raw)
To: Brad Mouring, Nicolas Ferre, Rob Herring, David S . Miller,
Michael Grzeschik, Andrew Lunn
Cc: Mark Rutland, netdev, Julia Cartwright, devicetree
In-Reply-To: <20180312171001.129209-5-brad.mouring@ni.com>
On 03/12/2018 10:10 AM, Brad Mouring wrote:
> Document the existance of the optional binding, directing to the
> general ethernet document that describes this binding.
>
> Signed-off-by: Brad Mouring <brad.mouring@ni.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [pci PATCH v5 0/4] Series short description
From: Alexander Duyck @ 2018-03-12 17:20 UTC (permalink / raw)
To: bhelgaas, alexander.h.duyck, linux-pci
Cc: virtio-dev, kvm, netdev, dan.daly, linux-kernel, linux-nvme,
keith.busch, netanel, mheyne, liang-min.wang, mark.d.rustad,
dwmw2, hch, dwmw
This series is meant to add support for SR-IOV on devices when the VFs are
not managed by the kernel. Examples of recent patches attempting to do this
include:
virto - https://patchwork.kernel.org/patch/10241225/
pci-stub - https://patchwork.kernel.org/patch/10109935/
vfio - https://patchwork.kernel.org/patch/10103353/
uio - https://patchwork.kernel.org/patch/9974031/
Since this is quickly blowing up into a multi-driver problem it is probably
best to implement this solution as generically as possible.
This series is an attempt to do that. What we do with this patch set is
provide a generic framework to enable SR-IOV in the case that the PF driver
doesn't support managing the VFs itself.
I based my patch set originally on the patch by Mark Rustad but there isn't
much left after going through and cleaning out the bits that were no longer
needed, and after incorporating the feedback from David Miller. At this point
the only items to be fully reused was his patch description which is now
present in patch 3 of the set.
This solution is limited in scope to just adding support for devices that
provide no functionality for SR-IOV other than allocating the VFs by
calling pci_enable_sriov. Previous sets had included patches for VFIO, but
for now I am dropping that as the scope of that work is larger then I
think I can take on at this time.
v2: Reduced scope back to just virtio_pci and vfio-pci
Broke into 3 patch set from single patch
Changed autoprobe behavior to always set when num_vfs is set non-zero
v3: Updated Documentation to clarify when sriov_unmanaged_autoprobe is used
Wrapped vfio_pci_sriov_configure to fix build errors w/o SR-IOV in kernel
v4: Dropped vfio-pci patch
Added ena and nvme to drivers now using pci_sriov_configure_unmanaged
Dropped pci_disable_sriov call in virtio_pci to be consistent with ena
v5: Dropped sriov_unmanaged_autoprobe and pci_sriov_conifgure_unmanaged
Added new patch that enables pci_sriov_configure_simple
Updated drivers to use pci_sriov_configure_simple
Cc: Mark Rustad <mark.d.rustad@intel.com>
Cc: Maximilian Heyne <mheyne@amazon.de>
Cc: Liang-Min Wang <liang-min.wang@intel.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
---
Alexander Duyck (4):
pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
ena: Migrate over to unmanaged SR-IOV support
nvme: Migrate over to unmanaged SR-IOV support
drivers/net/ethernet/amazon/ena/ena_netdev.c | 30 ++----------------------
drivers/nvme/host/pci.c | 22 ++----------------
drivers/pci/iov.c | 32 ++++++++++++++++++++++++++
drivers/virtio/virtio_pci_common.c | 3 ++
include/linux/pci.h | 1 +
5 files changed, 42 insertions(+), 46 deletions(-)
--
^ permalink raw reply
* [pci PATCH v5 1/4] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
From: Alexander Duyck @ 2018-03-12 17:21 UTC (permalink / raw)
To: bhelgaas, alexander.h.duyck, linux-pci
Cc: virtio-dev, kvm, netdev, dan.daly, linux-kernel, linux-nvme,
keith.busch, netanel, mheyne, liang-min.wang, mark.d.rustad,
dwmw2, hch, dwmw
In-Reply-To: <20180312171813.3487.94803.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch adds a common configuration function called
pci_sriov_configure_simple that will allow for managing VFs on devices
where the PF is not capable of managing VF resources.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v5: New patch replacing pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
Dropped bits related to autoprobe changes
drivers/pci/iov.c | 32 ++++++++++++++++++++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 33 insertions(+)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 677924ae0350..bd7021491fdb 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -807,3 +807,35 @@ int pci_sriov_get_totalvfs(struct pci_dev *dev)
return dev->sriov->total_VFs;
}
EXPORT_SYMBOL_GPL(pci_sriov_get_totalvfs);
+
+/**
+ * pci_sriov_configure_simple - helper to configure unmanaged SR-IOV
+ * @dev: the PCI device
+ * @nr_virtfn: number of virtual functions to enable, 0 to disable
+ *
+ * Used to provide generic enable/disable SR-IOV option for devices
+ * that do not manage the VFs generated by their driver
+ */
+int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn)
+{
+ int err = -EINVAL;
+
+ might_sleep();
+
+ if (!dev->is_physfn)
+ return -ENODEV;
+
+ if (pci_vfs_assigned(dev)) {
+ pci_warn(dev,
+ "Cannot modify SR-IOV while VFs are assigned\n");
+ err = -EPERM;
+ } else if (!nr_virtfn) {
+ sriov_disable(dev);
+ err = 0;
+ } else if (!dev->sriov->num_VFs) {
+ err = sriov_enable(dev, nr_virtfn);
+ }
+
+ return err ? err : nr_virtfn;
+}
+EXPORT_SYMBOL_GPL(pci_sriov_configure_simple);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 024a1beda008..9cab9d0d51dc 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1953,6 +1953,7 @@ static inline void pci_mmcfg_late_init(void) { }
int pci_vfs_assigned(struct pci_dev *dev);
int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs);
int pci_sriov_get_totalvfs(struct pci_dev *dev);
+int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn);
resource_size_t pci_iov_resource_size(struct pci_dev *dev, int resno);
void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe);
#else
^ permalink raw reply related
* Re: [PATCH net-next] modules: allow modprobe load regular elf binaries
From: Alexei Starovoitov @ 2018-03-12 17:22 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jessica Yu, Linus Torvalds, Mimi Zohar, Djalal Harouni,
David Miller, Andy Lutomirski, Kees Cook, Alexei Starovoitov,
Al Viro, Daniel Borkmann, Greg Kroah-Hartman, Network Development,
Linux Kernel Mailing List, kernel-team, Linux API
In-Reply-To: <20180310153431.GW4449@wotan.suse.de>
On 3/10/18 7:34 AM, Luis R. Rodriguez wrote:
> Also,
>
> Alexei you never answered my questions out aliases with the umh modules.
> Long term this important to consider.
aliases always felt like a crutch to me.
I can see an argument when they're used as 'alias pci:* foo'
but the way it's used in networking with ip_set_* and nf-* is
something I prefer not to ever do again.
Definitely no aliases for bpfilter umh.
^ permalink raw reply
* [pci PATCH v5 2/4] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices
From: Alexander Duyck @ 2018-03-12 17:23 UTC (permalink / raw)
To: bhelgaas, alexander.h.duyck, linux-pci
Cc: virtio-dev, kvm, netdev, dan.daly, linux-kernel, linux-nvme,
keith.busch, netanel, mheyne, liang-min.wang, mark.d.rustad,
dwmw2, hch, dwmw
In-Reply-To: <20180312171813.3487.94803.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Hardware-realized virtio_pci devices can implement SR-IOV, so this
patch enables its use. The device in question is an upcoming Intel
NIC that implements both a virtio_net PF and virtio_net VFs. These
are hardware realizations of what has been up to now been a software
interface.
The device in question has the following 4-part PCI IDs:
PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe
VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe
The patch currently needs no check for device ID, because the callback
will never be made for devices that do not assert the capability or
when run on a platform incapable of SR-IOV.
One reason for this patch is because the hardware requires the
vendor ID of a VF to be the same as the vendor ID of the PF that
created it. So it seemed logical to simply have a fully-functioning
virtio_net PF create the VFs. This patch makes that possible.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
drivers/virtio/virtio_pci_common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
index 48d4d1cf1cb6..41938d36b0cb 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -596,6 +596,9 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)
#ifdef CONFIG_PM_SLEEP
.driver.pm = &virtio_pci_pm_ops,
#endif
+#ifdef CONFIG_PCI_IOV
+ .sriov_configure = pci_sriov_configure_simple,
+#endif
};
module_pci_driver(virtio_pci_driver);
^ permalink raw reply related
* [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support
From: Alexander Duyck @ 2018-03-12 17:23 UTC (permalink / raw)
To: bhelgaas, alexander.h.duyck, linux-pci
Cc: virtio-dev, kvm, netdev, dan.daly, linux-kernel, linux-nvme,
keith.busch, netanel, mheyne, liang-min.wang, mark.d.rustad,
dwmw2, hch, dwmw
In-Reply-To: <20180312171813.3487.94803.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Instead of implementing our own version of a SR-IOV configuration stub in
the ena driver we can just reuse the existing
pci_sriov_configure_simple function.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
drivers/net/ethernet/amazon/ena/ena_netdev.c | 30 +++-----------------------
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 6975150d144e..868069363bdd 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -3385,32 +3385,6 @@ static int ena_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
}
/*****************************************************************************/
-static int ena_sriov_configure(struct pci_dev *dev, int numvfs)
-{
- int rc;
-
- if (numvfs > 0) {
- rc = pci_enable_sriov(dev, numvfs);
- if (rc != 0) {
- dev_err(&dev->dev,
- "pci_enable_sriov failed to enable: %d vfs with the error: %d\n",
- numvfs, rc);
- return rc;
- }
-
- return numvfs;
- }
-
- if (numvfs == 0) {
- pci_disable_sriov(dev);
- return 0;
- }
-
- return -EINVAL;
-}
-
-/*****************************************************************************/
-/*****************************************************************************/
/* ena_remove - Device Removal Routine
* @pdev: PCI device information struct
@@ -3525,7 +3499,9 @@ static int ena_resume(struct pci_dev *pdev)
.suspend = ena_suspend,
.resume = ena_resume,
#endif
- .sriov_configure = ena_sriov_configure,
+#ifdef CONFIG_PCI_IOV
+ .sriov_configure = pci_sriov_configure_simple,
+#endif
};
static int __init ena_init(void)
^ permalink raw reply related
* [pci PATCH v5 4/4] nvme: Migrate over to unmanaged SR-IOV support
From: Alexander Duyck @ 2018-03-12 17:23 UTC (permalink / raw)
To: bhelgaas, alexander.h.duyck, linux-pci
Cc: virtio-dev, kvm, netdev, dan.daly, linux-kernel, linux-nvme,
keith.busch, netanel, mheyne, liang-min.wang, mark.d.rustad,
dwmw2, hch, dwmw
In-Reply-To: <20180312171813.3487.94803.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Instead of implementing our own version of a SR-IOV configuration stub in
the nvme driver we can just reuse the existing
pci_sriov_configure_simple function.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v5: Replaced call to pci_sriov_configure_unmanaged with
pci_sriov_configure_simple
drivers/nvme/host/pci.c | 22 +++-------------------
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 5933a5c732e8..3b582f9f8cac 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2580,24 +2580,6 @@ static void nvme_remove(struct pci_dev *pdev)
nvme_put_ctrl(&dev->ctrl);
}
-static int nvme_pci_sriov_configure(struct pci_dev *pdev, int numvfs)
-{
- int ret = 0;
-
- if (numvfs == 0) {
- if (pci_vfs_assigned(pdev)) {
- dev_warn(&pdev->dev,
- "Cannot disable SR-IOV VFs while assigned\n");
- return -EPERM;
- }
- pci_disable_sriov(pdev);
- return 0;
- }
-
- ret = pci_enable_sriov(pdev, numvfs);
- return ret ? ret : numvfs;
-}
-
#ifdef CONFIG_PM_SLEEP
static int nvme_suspend(struct device *dev)
{
@@ -2716,7 +2698,9 @@ static void nvme_error_resume(struct pci_dev *pdev)
.driver = {
.pm = &nvme_dev_pm_ops,
},
- .sriov_configure = nvme_pci_sriov_configure,
+#ifdef CONFIG_PCI_IOV
+ .sriov_configure = pci_sriov_configure_simple,
+#endif
.err_handler = &nvme_err_handler,
};
^ permalink raw reply related
* [PATCH] rxrpc: remove redundant initialization of variable 'len'
From: Colin King @ 2018-03-12 17:25 UTC (permalink / raw)
To: David Howells, David S . Miller, linux-afs, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The variable 'len' is being initialized with a value that is never
read and it is re-assigned later, hence the initialization is redundant
and can be removed.
Cleans up clang warning:
net/rxrpc/recvmsg.c:275:15: warning: Value stored to 'len' during its
initialization is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/rxrpc/recvmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index 9d45d8b56744..7bff716e911e 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -272,7 +272,7 @@ static int rxrpc_locate_data(struct rxrpc_call *call, struct sk_buff *skb,
unsigned int *_offset, unsigned int *_len)
{
unsigned int offset = sizeof(struct rxrpc_wire_header);
- unsigned int len = *_len;
+ unsigned int len;
int ret;
u8 annotation = *_annotation;
--
2.15.1
^ permalink raw reply related
* Re: [pci PATCH v5 0/4] Add support for unmanaged SR-IOV (was: Series short description)
From: Alexander Duyck @ 2018-03-12 17:25 UTC (permalink / raw)
To: Bjorn Helgaas, Duyck, Alexander H, linux-pci
Cc: virtio-dev, kvm, Netdev, Daly, Dan, LKML, linux-nvme, keith.busch,
netanel, Maximilian Heyne, Wang, Liang-min, Rustad, Mark D,
David Woodhouse, Christoph Hellwig, dwmw
On Mon, Mar 12, 2018 at 10:20 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> This series is meant to add support for SR-IOV on devices when the VFs are
> not managed by the kernel. Examples of recent patches attempting to do this
> include:
> virto - https://patchwork.kernel.org/patch/10241225/
> pci-stub - https://patchwork.kernel.org/patch/10109935/
> vfio - https://patchwork.kernel.org/patch/10103353/
> uio - https://patchwork.kernel.org/patch/9974031/
>
> Since this is quickly blowing up into a multi-driver problem it is probably
> best to implement this solution as generically as possible.
>
> This series is an attempt to do that. What we do with this patch set is
> provide a generic framework to enable SR-IOV in the case that the PF driver
> doesn't support managing the VFs itself.
>
> I based my patch set originally on the patch by Mark Rustad but there isn't
> much left after going through and cleaning out the bits that were no longer
> needed, and after incorporating the feedback from David Miller. At this point
> the only items to be fully reused was his patch description which is now
> present in patch 3 of the set.
>
> This solution is limited in scope to just adding support for devices that
> provide no functionality for SR-IOV other than allocating the VFs by
> calling pci_enable_sriov. Previous sets had included patches for VFIO, but
> for now I am dropping that as the scope of that work is larger then I
> think I can take on at this time.
>
> v2: Reduced scope back to just virtio_pci and vfio-pci
> Broke into 3 patch set from single patch
> Changed autoprobe behavior to always set when num_vfs is set non-zero
> v3: Updated Documentation to clarify when sriov_unmanaged_autoprobe is used
> Wrapped vfio_pci_sriov_configure to fix build errors w/o SR-IOV in kernel
> v4: Dropped vfio-pci patch
> Added ena and nvme to drivers now using pci_sriov_configure_unmanaged
> Dropped pci_disable_sriov call in virtio_pci to be consistent with ena
> v5: Dropped sriov_unmanaged_autoprobe and pci_sriov_conifgure_unmanaged
> Added new patch that enables pci_sriov_configure_simple
> Updated drivers to use pci_sriov_configure_simple
>
> Cc: Mark Rustad <mark.d.rustad@intel.com>
> Cc: Maximilian Heyne <mheyne@amazon.de>
> Cc: Liang-Min Wang <liang-min.wang@intel.com>
> Cc: David Woodhouse <dwmw@amazon.co.uk>
Ugh. Just realized I forgot to post the correct subject line in the cover page.
I needed I can resubmit the series, will just leave it for now in case
there are any other review comments.
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCH] net: hns: use put_device() if device_register fail
From: Richard Weinberger @ 2018-03-12 17:29 UTC (permalink / raw)
To: arvindY
Cc: David Miller, yisen.zhuang, salil.mehta, linyunsheng, LKML,
netdev, linux-mtd
In-Reply-To: <5AA6AA84.6040001@gmail.com>
On Mon, Mar 12, 2018 at 5:27 PM, arvindY <arvind.yadav.cs@gmail.com> wrote:
>
>
> On Monday 12 March 2018 08:13 PM, David Miller wrote:
>>
>> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> Date: Fri, 9 Mar 2018 16:11:17 +0530
>>
>>> if device_register() returned an error! Always use put_device()
>>> to give up the reference initialized.
>>>
>>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>>
>> I do not see anything giving cls_dev an initial non-zero reference
>> count before this device_register() call.
>
> Yes, you are correct there is nothing to release (hnae_release).
Wait, this is not what DaveM said.
Since you sent also patches to MTD I care about this too.
Do we have to call put_device() in any case after a failure of
device_register() or not?
In this case the release function is empty, so nothing is going to released.
But technically a put_device() is needed and correct according to your
change log.
I have to admit I don't know all details of the driver core, maybe you
can help me.
device_register() calls device_initialize() followed by device_add().
device_initialize() does a kobject_init() which again sets the
reference counter to 1 via kref_init().
In the next step device_add() does a get_device() --> reference
counter goes up to 2.
But in the exit path of the function a put_device() is done, also in
case of an error.
So device_register() always returns with reference count 1.
If I understand this correctly a put_device() is mandatory.
Also in this driver.
Can you please enlighten me? :-)
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH net-next] sctp: fix error return code in sctp_sendmsg_new_asoc()
From: Xin Long @ 2018-03-12 17:34 UTC (permalink / raw)
To: David Miller
Cc: Wei Yongjun, Vlad Yasevich, Neil Horman, linux-sctp, network dev,
kernel-janitors
In-Reply-To: <20180312.111903.1047457001442236332.davem@davemloft.net>
On Mon, Mar 12, 2018 at 11:19 PM, David Miller <davem@davemloft.net> wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
> Date: Mon, 12 Mar 2018 12:16:04 +0000
>
>> Return error code -EINVAL in the address len check error handling
>> case since 'err' can be overwrite to 0 by 'err = sctp_verify_addr()'
>> in the for loop.
>>
>> Fixes: 2c0dbaa0c43d ("sctp: add support for SCTP_DSTADDRV4/6 Information for sendmsg")
>> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
>
> Xin, I do not want to have a bug fix like this blocked because of that
> SCTP options merge nightmare which is of no fault of our own.
Okay, sorry, I was over worried recently, thank you.
^ permalink raw reply
* Re: [pci PATCH v5 1/4] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
From: Keith Busch @ 2018-03-12 17:40 UTC (permalink / raw)
To: Alexander Duyck
Cc: bhelgaas, alexander.h.duyck, linux-pci, virtio-dev, kvm, netdev,
dan.daly, linux-kernel, linux-nvme, netanel, mheyne,
liang-min.wang, mark.d.rustad, dwmw2, hch, dwmw
In-Reply-To: <20180312172031.3487.20651.stgit@localhost.localdomain>
On Mon, Mar 12, 2018 at 10:21:29AM -0700, Alexander Duyck wrote:
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 024a1beda008..9cab9d0d51dc 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1953,6 +1953,7 @@ static inline void pci_mmcfg_late_init(void) { }
> int pci_vfs_assigned(struct pci_dev *dev);
> int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs);
> int pci_sriov_get_totalvfs(struct pci_dev *dev);
> +int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn);
> resource_size_t pci_iov_resource_size(struct pci_dev *dev, int resno);
> void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe);
> #else
I recommend stubbing 'pci_sriov_configure_simple' or defining it to
NULL in the '#else' section here so you don't need to repeat the "#ifdef
CONFIG_PCI_IOV" in each driver wishing to use this function. Otherwise
looks fine to me.
^ permalink raw reply
* Re: [PATCH net-next] modules: allow modprobe load regular elf binaries
From: Alexei Starovoitov @ 2018-03-12 17:49 UTC (permalink / raw)
To: Edward Cree, Linus Torvalds, Kees Cook
Cc: David Miller, Andy Lutomirski, Alexei Starovoitov, Djalal Harouni,
Al Viro, Daniel Borkmann, Greg KH, Luis R. Rodriguez,
Network Development, LKML, kernel-team, Linux API
In-Reply-To: <30db1e8e-8eb4-5072-8360-6cafe26db113@solarflare.com>
On 3/12/18 5:02 AM, Edward Cree wrote:
> On 09/03/18 18:58, Alexei Starovoitov wrote:
>> It's not waiting for the whole thing, because once bpfilter starts it
>> stays running/sleeping because it's stateful.
> So, this has been bugging me a bit.
> If bpfilter takes a signal and crashes, all that state goes away.
> Does that mean your iptables/netfilter config just got forgotten and next
> time you run iptables it disappears, so you have to re-apply it all again?
>> It needs normal
>> malloc-ed memory to keep the state of iptable->bpf translation that
>> it will use later during subsequent translation calls.
>> Theoretically it can use bpf maps pinned in kernel memory to keep
>> this state, but then it's non-swappable. It's better to keep bpfilter
>> state in its own user memory.
> Perhaps the state should live in swappable kernel memory (e.g. a tmpfs
> thing, which bpfilter could access through a mount). It'd be read-only
> to userspace, listing the existing rules (in untranslated form), and be
> updated to reflect the new rule after bpfilter has supplied the updated
> translation.
> Then bpfilter can cache things if it wants, but the kernel remains the
> ultimate arbiter of the state and maintains it over a bpfilter crash.
seems like overkill.
I consider crashing bpfilter same severity as kernel bug.
Whatever firewall rules already installed will continue to work,
but new ones won't be able to load and current set cannot be queried.
Control plane crashed, dataplane continues to work.
Still a ton better than whole system crash.
We have plenty of work ahead of us without worrying about restarting
that umh and reloading its state from tmpfs.
Something to consider for later phases of the project.
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 0/6] cm_id, cq, mr, and pd resource tracking
From: David Ahern @ 2018-03-12 17:53 UTC (permalink / raw)
To: Steve Wise, stephen; +Cc: leon, netdev, linux-rdma
In-Reply-To: <0b9901d3ba15$1ac4a1d0$504de570$@opengridcomputing.com>
On 3/12/18 8:16 AM, Steve Wise wrote:
> Hey all,
>
> The kernel side of this series has been merged for rdma-next [1]. Let me
> know if this iproute2 series can be merged, of if it needs more changes.
>
The problem is that iproute2 headers are synced to kernel headers from
DaveM's tree (net-next mainly). I take it this series will not appear in
Dave's tree until after a merge through Linus' tree. Correct?
^ permalink raw reply
* Re: [PATCH v2] KEYS: DNS: limit the length of option strings
From: Eric Biggers @ 2018-03-12 17:57 UTC (permalink / raw)
To: David Howells; +Cc: keyrings, netdev, Mark Rutland, Eric Biggers
In-Reply-To: <31292.1520438077@warthog.procyon.org.uk>
On Wed, Mar 07, 2018 at 03:54:37PM +0000, David Howells wrote:
> Eric Biggers <ebiggers3@gmail.com> wrote:
>
> > Fix it by limiting option strings (combined name + value) to a much more
> > reasonable 128 bytes. The exact limit is arbitrary, but currently the
> > only recognized option is formatted as "dnserror=%lu" which fits well
> > within this limit.
>
> There will be more options coming ("ipv4", "ipv6") but they shouldn't overrun
> this limit and we can always extend the limit if need be.
>
> David
David (Howells) do you want to take this patch through the keyrings tree or
should I ask David Miller to take it through net-next?
Eric
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox