* Re: [PATCH net-next] dpaa2-eth: Don't use netif_receive_skb_list for TCP frames
From: David Miller @ 2019-07-23 21:02 UTC (permalink / raw)
To: ruxandra.radulescu; +Cc: netdev, ioana.ciornei, vladimir.oltean
In-Reply-To: <1563902923-26178-1-git-send-email-ruxandra.radulescu@nxp.com>
From: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Date: Tue, 23 Jul 2019 20:28:43 +0300
> Using Rx skb bulking for all frames may negatively impact the
> performance in some TCP termination scenarios, as it effectively
> bypasses GRO.
"may"?
Please provide numbers so that we know exactly whether it actually
hurts performance one way or another.
Thank you.
^ permalink raw reply
* Re: [PATCH v1] hv_sock: Use consistent types for UUIDs
From: David Miller @ 2019-07-23 20:58 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: haiyangz, kys, sthemmin, sashal, linux-hyperv, netdev
In-Reply-To: <20190723163943.65991-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue, 23 Jul 2019 19:39:43 +0300
> The rest of Hyper-V code is using new types for UUID handling.
> Convert hv_sock as well.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] sky2: Disable MSI on ASUS P6T
From: David Miller @ 2019-07-23 20:55 UTC (permalink / raw)
To: tiwai; +Cc: netdev, mlindner, stephen, m.seyfarth
In-Reply-To: <20190723151525.6526-1-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
Date: Tue, 23 Jul 2019 17:15:25 +0200
> The onboard sky2 NIC on ASUS P6T WS PRO doesn't work after PM resume
> due to the infamous IRQ problem. Disabling MSI works around it, so
> let's add it to the blacklist.
>
> Unfortunately the BIOS on the machine doesn't fill the standard
> DMI_SYS_* entry, so we pick up DMI_BOARD_* entries instead.
>
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1142496
> Reported-and-tested-by: Marcus Seyfarth <m.seyfarth@gmail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/4] nfp: Offload MPLS actions
From: David Miller @ 2019-07-23 20:53 UTC (permalink / raw)
To: john.hurley; +Cc: netdev, simon.horman, jakub.kicinski, oss-drivers
In-Reply-To: <1563892442-4654-1-git-send-email-john.hurley@netronome.com>
From: John Hurley <john.hurley@netronome.com>
Date: Tue, 23 Jul 2019 15:33:58 +0100
> The module act_mpls has recently been added to the kernel. This allows the
> manipulation of MPLS headers on packets including push, pop and modify.
> Add these new actions and parameters to the intermediate representation
> API for hardware offload. Follow this by implementing the offload of these
> MPLS actions in the NFP driver.
Looks nice, clean, and straightforward.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/3] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Saeed Mahameed @ 2019-07-23 20:49 UTC (permalink / raw)
To: claudiu.manoil@nxp.com, davem@davemloft.net
Cc: linux-arm-kernel@lists.infradead.org, leoyang.li@nxp.com,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
alexandru.marginean@nxp.com, robh+dt@kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1563894955-545-2-git-send-email-claudiu.manoil@nxp.com>
On Tue, 2019-07-23 at 18:15 +0300, Claudiu Manoil wrote:
> ENETC ports can manage the MDIO bus via local register
> interface. However there's also a centralized way
> to manage the MDIO bus, via the MDIO PCIe endpoint
> device integrated by the same root complex that also
> integrates the ENETC ports (eth controllers).
>
> Depending on board design and use case, centralized
> access to MDIO may be better than using local ENETC
> port registers. For instance, on the LS1028A QDS board
> where MDIO muxing is requiered. Also, the LS1028A on-chip
> switch doesn't have a local MDIO register interface.
>
> The current patch registers the above PCIe enpoint as a
> separate MDIO bus and provides a driver for it by re-using
> the code used for local MDIO access. It also allows the
> ENETC port PHYs to be managed by this driver if the local
> "mdio" node is missing from the ENETC port node.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
> ---
> .../net/ethernet/freescale/enetc/enetc_mdio.c | 90
> +++++++++++++++++++
> .../net/ethernet/freescale/enetc/enetc_pf.c | 5 +-
> 2 files changed, 94 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> index 77b9cd10ba2b..efa8a29f463d 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_mdio.c
> @@ -197,3 +197,93 @@ void enetc_mdio_remove(struct enetc_pf *pf)
> mdiobus_free(pf->mdio);
> }
> }
> +
> +#define ENETC_MDIO_DEV_ID 0xee01
> +#define ENETC_MDIO_DEV_NAME "FSL PCIe IE Central MDIO"
> +#define ENETC_MDIO_BUS_NAME ENETC_MDIO_DEV_NAME " Bus"
> +#define ENETC_MDIO_DRV_NAME ENETC_MDIO_DEV_NAME " driver"
> +#define ENETC_MDIO_DRV_ID "fsl_enetc_mdio"
> +
> +static int enetc_pci_mdio_probe(struct pci_dev *pdev,
> + const struct pci_device_id *ent)
> +{
> + struct device *dev = &pdev->dev;
> + struct mii_bus *bus;
> + int err;
> +
> + bus = mdiobus_alloc_size(sizeof(u32 *));
> + if (!bus)
> + return -ENOMEM;
> +
> + bus->name = ENETC_MDIO_BUS_NAME;
> + bus->read = enetc_mdio_read;
> + bus->write = enetc_mdio_write;
> + bus->parent = dev;
> + snprintf(bus->id, MII_BUS_ID_SIZE, "%s", dev_name(dev));
> +
> + pcie_flr(pdev);
> + err = pci_enable_device_mem(pdev);
> + if (err) {
> + dev_err(dev, "device enable failed\n");
mdiobus_free(bus) is missing here and in every error path.
> + return err;
> + }
> +
> + err = pci_request_mem_regions(pdev, ENETC_MDIO_DRV_ID);
> + if (err) {
> + dev_err(dev, "pci_request_regions failed\n");
> + goto err_pci_mem_reg;
> + }
> +
> + bus->priv = pci_iomap_range(pdev, 0, ENETC_MDIO_REG_OFFSET, 0);
> + if (!bus->priv) {
> + err = -ENXIO;
> + dev_err(dev, "ioremap failed\n");
> + goto err_ioremap;
> + }
> +
> + err = of_mdiobus_register(bus, dev->of_node);
> + if (err)
> + goto err_mdiobus_reg;
> +
> + pci_set_drvdata(pdev, bus);
> +
> + return 0;
> +
> +err_mdiobus_reg:
> + iounmap(bus->priv);
> +err_ioremap:
> + pci_release_mem_regions(pdev);
> +err_pci_mem_reg:
> + pci_disable_device(pdev);
> +
> + return err;
> +}
> +
> +static void enetc_pci_mdio_remove(struct pci_dev *pdev)
> +{
> + struct mii_bus *bus = pci_get_drvdata(pdev);
> +
> + mdiobus_unregister(bus);
> + iounmap(bus->priv);
> + mdiobus_free(bus);
> +
this should come last to be symmetrical with probe flow.
> + pci_release_mem_regions(pdev);
> + pci_disable_device(pdev);
> +}
> +
> +static const struct pci_device_id enetc_pci_mdio_id_table[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, ENETC_MDIO_DEV_ID) },
> + { 0, } /* End of table. */
> +};
> +MODULE_DEVICE_TABLE(pci, enetc_mdio_id_table);
> +
> +static struct pci_driver enetc_pci_mdio_driver = {
> + .name = ENETC_MDIO_DRV_ID,
> + .id_table = enetc_pci_mdio_id_table,
> + .probe = enetc_pci_mdio_probe,
> + .remove = enetc_pci_mdio_remove,
> +};
> +module_pci_driver(enetc_pci_mdio_driver);
> +
> +MODULE_DESCRIPTION(ENETC_MDIO_DRV_NAME);
> +MODULE_LICENSE("Dual BSD/GPL");
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> index 258b3cb38a6f..7d6513ff8507 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
> @@ -750,6 +750,7 @@ static int enetc_of_get_phy(struct
> enetc_ndev_priv *priv)
> {
> struct enetc_pf *pf = enetc_si_priv(priv->si);
> struct device_node *np = priv->dev->of_node;
> + struct device_node *mdio_np;
> int err;
>
> if (!np) {
> @@ -773,7 +774,9 @@ static int enetc_of_get_phy(struct
> enetc_ndev_priv *priv)
> priv->phy_node = of_node_get(np);
> }
>
> - if (!of_phy_is_fixed_link(np)) {
> + mdio_np = of_get_child_by_name(np, "mdio");
> + if (mdio_np) {
> + of_node_put(mdio_np);
> err = enetc_mdio_probe(pf);
> if (err) {
> of_node_put(priv->phy_node);
^ permalink raw reply
* Re: [bpf-next 6/6] selftests/bpf: add test for bpf_tcp_gen_syncookie
From: Alexei Starovoitov @ 2019-07-23 20:46 UTC (permalink / raw)
To: Lorenz Bauer
Cc: Petar Penkov, Networking, bpf, davem, Alexei Starovoitov,
Daniel Borkmann, Eric Dumazet, Stanislav Fomichev, Petar Penkov,
yhs
In-Reply-To: <CACAyw9-qQ8KbQk6Q6dg0+A337ZbSpot-sHpH_tSxFaQmUfhLyQ@mail.gmail.com>
On Tue, Jul 23, 2019 at 10:37:29AM +0100, Lorenz Bauer wrote:
> On Tue, 23 Jul 2019 at 01:20, Petar Penkov <ppenkov.kernel@gmail.com> wrote:
> > +static __always_inline __s64 gen_syncookie(void *data_end, struct bpf_sock *sk,
> > + void *iph, __u32 ip_size,
> > + struct tcphdr *tcph)
> > +{
> > + __u32 thlen = tcph->doff * 4;
> > +
> > + if (tcph->syn && !tcph->ack) {
> > + // packet should only have an MSS option
> > + if (thlen != 24)
> > + return 0;
>
> Just for my own understanding: without this the verifier complains since
> thlen is not a known value, even though it is in bounds due to the check below?
the verifier understands only constant part of the packet pointer.
Without additional 'if' above the statement:
if ((void *)tcph + thlen > data_end)
will add variables length 'thlen' to pkt pointer which will become
another pkt pointer (with different id).
That pointer would need 'pkt + const_range > data_end' to have valid access.
We hit this issue in the past when folks wanted to use bpf_csum_diff() helper
with variable size.
It's possible to extend the verifier to support that but it's intrusive,
since variable part would need to passed around to a bunch of check* functions.
I think it's tricky, but doable. Looking forward to patches :)
> > +
> > + if ((void *)tcph + thlen > data_end)
> > + return 0;
> > +
> > + return bpf_tcp_gen_syncookie(sk, iph, ip_size, tcph, thlen);
> > + }
> > + return 0;
> > +}
> > +
>
> --
> Lorenz Bauer | Systems Engineer
> 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
>
> www.cloudflare.com
^ permalink raw reply
* Re: [PATCH net-next v2] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param
From: David Miller @ 2019-07-23 20:39 UTC (permalink / raw)
To: maximmi
Cc: arnd, ast, daniel, bpf, netdev, saeedm, leon, jakub.kicinski,
hawk, john.fastabend, tariqt
In-Reply-To: <20190723120208.27423-1-maximmi@mellanox.com>
From: Maxim Mikityanskiy <maximmi@mellanox.com>
Date: Tue, 23 Jul 2019 12:02:26 +0000
> From: Arnd Bergmann <arnd@arndb.de>
>
> The structure is too large to put on the stack, resulting in a
> warning on 32-bit ARM:
>
> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:59:5: error: stack frame size of 1344 bytes in function
> 'mlx5e_open_xsk' [-Werror,-Wframe-larger-than=]
>
> Use kvzalloc() instead.
>
> Fixes: a038e9794541 ("net/mlx5e: Add XSK zero-copy support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
> ---
> v2 changes: use kvzalloc/kvfree and fix a memory leak.
I'll apply this directly to net-next.
Thanks Maxim.
^ permalink raw reply
* Re: [PATCH] net: dsa: sja1105: sja1105_main: Add of_node_put()
From: David Miller @ 2019-07-23 20:38 UTC (permalink / raw)
To: nishkadg.linux
Cc: olteanv, andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190723104448.8125-1-nishkadg.linux@gmail.com>
From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Tue, 23 Jul 2019 16:14:48 +0530
> Each iteration of for_each_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Applied.
Again, the semantics of these looping constructs are terrible.
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: chip: Add of_node_put() before return
From: David Miller @ 2019-07-23 20:38 UTC (permalink / raw)
To: nishkadg.linux; +Cc: andrew, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20190723104307.8068-1-nishkadg.linux@gmail.com>
From: Nishka Dasgupta <nishkadg.linux@gmail.com>
Date: Tue, 23 Jul 2019 16:13:07 +0530
> Each iteration of for_each_available_child_of_node puts the previous
> node, but in the case of a return from the middle of the loop, there is
> no put, thus causing a memory leak. Hence add an of_node_put before the
> return.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Applied, but as I've repeatedly stated these OF node looping constructs
are EXTREMELY ERROR PRONE.
We must fix these kinds of interfaces so that they are easier to use
correctly.
^ permalink raw reply
* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: Saeed Mahameed @ 2019-07-23 20:34 UTC (permalink / raw)
To: davem@davemloft.net, leon@kernel.org
Cc: Jason Gunthorpe, Yishai Hadas, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, dledford@redhat.com, Edward Srouji
In-Reply-To: <20190723.130211.1967999203654051483.davem@davemloft.net>
On Tue, 2019-07-23 at 13:02 -0700, David Miller wrote:
> From: Leon Romanovsky <leon@kernel.org>
> Date: Tue, 23 Jul 2019 22:04:14 +0300
>
> > The intention was to have this patch in shared mlx5 branch, which
> > is
> > picked by RDMA too. This "Cc: stable@..." together with merge
> > through
> > RDMA will ensure that such patch will be part of stable
> > automatically.
>
> Why wouldn't it come via Saeed's usual mlx5 bug fix pull requests to
> me?
That should have been the plan in first place, i will handle this,
thanks Dave and sorry for any inconvenience.
I will apply this patch to my (mlx5) net queue, will submit to net
shortly.
Leon can merge the next -rc when this patch lands there.
meanwhile, Leon can also merge my (mlx5) net queue which is always
based on latest -rc.
https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git/log/?h=net-mlx5
^ permalink raw reply
* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: Saeed Mahameed @ 2019-07-23 20:25 UTC (permalink / raw)
To: davem@davemloft.net, leon@kernel.org
Cc: Jason Gunthorpe, Yishai Hadas, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, dledford@redhat.com, Edward Srouji
In-Reply-To: <20190723190414.GU5125@mtr-leonro.mtl.com>
On Tue, 2019-07-23 at 22:04 +0300, Leon Romanovsky wrote:
> On Tue, Jul 23, 2019 at 11:28:50AM -0700, David Miller wrote:
> > From: Leon Romanovsky <leon@kernel.org>
> > Date: Tue, 23 Jul 2019 10:12:55 +0300
> >
> > > From: Edward Srouji <edwards@mellanox.com>
> > >
> > > Fix modify_cq_in alignment to match the device specification.
> > > After this fix the 'cq_umem_valid' field will be in the right
> > > offset.
> > >
> > > Cc: <stable@vger.kernel.org> # 4.19
> > > Fixes: bd37197554eb ("net/mlx5: Update mlx5_ifc with DEVX UID
> > > bits")
> > > Signed-off-by: Edward Srouji <edwards@mellanox.com>
> > > Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> >
> > Very confusing submission on many levels.
> >
> > Coming from a Mellanox developer using a kernel.org email address.
>
> It works for us and was proven internally as the best way to have
> setup which always works.
>
> > Targetting the mlx5-next tree, yet CC:'ing stable.
>
> This patch was found by RDMA team, needed by RDMA but changes are
> located
> in code accessible by mlx5_core part. This is why mlx5-next.
>
Leon,
mlx5-next "hence the -next" is NOT meant for fixes, it is indeed
confusing what you are trying to do here, Dave's system works perfectly
for us.
> > A networking change, for which stable submissions are handled by me
> > by
> > hand and not via CC:'ing stable.
>
> The intention was to have this patch in shared mlx5 branch, which is
> picked by RDMA too. This "Cc: stable@..." together with merge through
> RDMA will ensure that such patch will be part of stable
> automatically.
>
> I can remove "Cc: ..." line if you think that it is inappropriate to
> have such line in patch in mlx5-next.
No, if this was meant to land in -stable then it should go to -rc via
net branch not to mlx5-next, let's save everybody's time and energy
here. no point in arguing..
I will take this to my net queue and submit to Dave's net branch, as we
always do for mlx5 fixes.
for next time, mlx5 fixes should always go to net branch first, then it
is just a matter of days to see the fix in -rc and queued up to
-stable.
>
> Thanks
^ permalink raw reply
* Re: [PATCH net 0/2] selftests: forwarding: GRE multipath fixes
From: David Miller @ 2019-07-23 20:07 UTC (permalink / raw)
To: idosch; +Cc: netdev, ssuryaextr, mlxsw, idosch
In-Reply-To: <20190723081926.30647-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Tue, 23 Jul 2019 11:19:24 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Patch #1 ensures IPv4 forwarding is enabled during the test.
>
> Patch #2 fixes the flower filters used to measure the distribution of
> the traffic between the two nexthops, so that the test will pass
> regardless if traffic is offloaded or not.
Series applied.
^ permalink raw reply
* [PATCH v1] net: thunderx: Use fwnode_get_mac_address()
From: Andy Shevchenko @ 2019-07-23 20:03 UTC (permalink / raw)
To: Sunil Goutham, Robert Richter, linux-arm-kernel, David S. Miller,
netdev
Cc: Andy Shevchenko
Replace the custom implementation with fwnode_get_mac_address,
which works on both DT and ACPI platforms.
While here, replace memcpy() by ether_addr_copy().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
.../net/ethernet/cavium/thunder/thunder_bgx.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index ad22554857bf..acb016834f04 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -1381,24 +1381,18 @@ static int acpi_get_mac_address(struct device *dev, struct acpi_device *adev,
u8 *dst)
{
u8 mac[ETH_ALEN];
- int ret;
+ u8 *addr;
- ret = fwnode_property_read_u8_array(acpi_fwnode_handle(adev),
- "mac-address", mac, ETH_ALEN);
- if (ret)
- goto out;
-
- if (!is_valid_ether_addr(mac)) {
+ addr = fwnode_get_mac_address(acpi_fwnode_handle(adev), mac, ETH_ALEN);
+ if (!addr) {
dev_err(dev, "MAC address invalid: %pM\n", mac);
- ret = -EINVAL;
- goto out;
+ return -EINVAL;
}
dev_info(dev, "MAC address set to: %pM\n", mac);
- memcpy(dst, mac, ETH_ALEN);
-out:
- return ret;
+ ether_addr_copy(dst, mac);
+ return 0;
}
/* Currently only sets the MAC address. */
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] fm10k: Use dev_get_drvdata
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190723141533.5803-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 22:15:33 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: jme: Use dev_get_drvdata
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96; +Cc: cooldavid, netdev, linux-kernel
In-Reply-To: <20190723141642.5968-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 22:16:42 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] igb: Use dev_get_drvdata where possible
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190723141624.5911-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 22:16:24 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] i40e: Use dev_get_drvdata
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190723141551.5857-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 22:15:51 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] e1000e: Use dev_get_drvdata where possible
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96; +Cc: jeffrey.t.kirsher, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190723141513.5749-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 22:15:13 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: broadcom: Use dev_get_drvdata
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96
Cc: rmody, GR-Linux-NIC-Dev, michael.chan, siva.kallam, prashant,
netdev, linux-kernel
In-Reply-To: <20190723131929.31987-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 21:19:29 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: atheros: Use dev_get_drvdata
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96; +Cc: jcliburn, chris.snook, netdev, linux-kernel
In-Reply-To: <20190723131856.31932-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 21:18:56 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: 3com: 3c59x: Use dev_get_drvdata
From: David Miller @ 2019-07-23 20:03 UTC (permalink / raw)
To: hslester96; +Cc: klassert, netdev, linux-kernel
In-Reply-To: <20190723131844.31878-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 21:18:44 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: Use dev_get_drvdata
From: David Miller @ 2019-07-23 20:02 UTC (permalink / raw)
To: hslester96; +Cc: 3chas3, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20190723081313.18552-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Tue, 23 Jul 2019 16:13:14 +0800
> Instead of using to_pci_dev + pci_get_drvdata,
> use dev_get_drvdata to make code simpler.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: David Miller @ 2019-07-23 20:02 UTC (permalink / raw)
To: leon; +Cc: dledford, jgg, edwards, linux-rdma, yishaih, saeedm, netdev
In-Reply-To: <20190723190414.GU5125@mtr-leonro.mtl.com>
From: Leon Romanovsky <leon@kernel.org>
Date: Tue, 23 Jul 2019 22:04:14 +0300
> The intention was to have this patch in shared mlx5 branch, which is
> picked by RDMA too. This "Cc: stable@..." together with merge through
> RDMA will ensure that such patch will be part of stable automatically.
Why wouldn't it come via Saeed's usual mlx5 bug fix pull requests to me?
^ permalink raw reply
* Re: [patch iproute2 1/2] tc: action: fix crash caused by incorrect *argv check
From: Jiri Pirko @ 2019-07-23 19:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, sthemmin, dsahern, alexanderk, mlxsw
In-Reply-To: <20190723105401.4975396d@hermes.lan>
Tue, Jul 23, 2019 at 07:54:01PM CEST, stephen@networkplumber.org wrote:
>On Tue, 23 Jul 2019 13:25:37 +0200
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> One cannot depend on *argv being null in case of no arg is left on the
>> command line. For example in batch mode, this is not always true. Check
>> argc instead to prevent crash.
>>
>> Reported-by: Alex Kushnarov <alexanderk@mellanox.com>
>> Fixes: fd8b3d2c1b9b ("actions: Add support for user cookies")
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>
>Actually makeargs does NULL terminate the last arg so what input
>to batchmode is breaking this?
Interesting, there must be another but out there then.
My input is:
filter add dev testdummy parent ffff: protocol all prio 11000 flower action drop
filter add dev testdummy parent ffff: protocol ipv4 prio 1 flower dst_mac 11:22:33:44:55:66 action drop
^ permalink raw reply
* Re: [PATCH mlx5-next] net/mlx5: Fix modify_cq_in alignment
From: Leon Romanovsky @ 2019-07-23 19:04 UTC (permalink / raw)
To: David Miller; +Cc: dledford, jgg, edwards, linux-rdma, yishaih, saeedm, netdev
In-Reply-To: <20190723.112850.610952032088764951.davem@davemloft.net>
On Tue, Jul 23, 2019 at 11:28:50AM -0700, David Miller wrote:
> From: Leon Romanovsky <leon@kernel.org>
> Date: Tue, 23 Jul 2019 10:12:55 +0300
>
> > From: Edward Srouji <edwards@mellanox.com>
> >
> > Fix modify_cq_in alignment to match the device specification.
> > After this fix the 'cq_umem_valid' field will be in the right offset.
> >
> > Cc: <stable@vger.kernel.org> # 4.19
> > Fixes: bd37197554eb ("net/mlx5: Update mlx5_ifc with DEVX UID bits")
> > Signed-off-by: Edward Srouji <edwards@mellanox.com>
> > Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
>
> Very confusing submission on many levels.
>
> Coming from a Mellanox developer using a kernel.org email address.
It works for us and was proven internally as the best way to have
setup which always works.
>
> Targetting the mlx5-next tree, yet CC:'ing stable.
This patch was found by RDMA team, needed by RDMA but changes are located
in code accessible by mlx5_core part. This is why mlx5-next.
>
> A networking change, for which stable submissions are handled by me by
> hand and not via CC:'ing stable.
The intention was to have this patch in shared mlx5 branch, which is
picked by RDMA too. This "Cc: stable@..." together with merge through
RDMA will ensure that such patch will be part of stable automatically.
I can remove "Cc: ..." line if you think that it is inappropriate to
have such line in patch in mlx5-next.
Thanks
^ 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