Netdev List
 help / color / mirror / Atom feed
* Re: [RFC] longer netdev names proposal
From: Stephen Hemminger @ 2019-06-27 17:56 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: Jiri Pirko, netdev, davem, sthemmin, dsahern, mlxsw
In-Reply-To: <20190627104808.1404049a@cakuba.netronome.com>

On Thu, 27 Jun 2019 10:48:08 -0700
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:

> On Thu, 27 Jun 2019 11:43:27 +0200, Jiri Pirko wrote:
> > Hi all.
> > 
> > In the past, there was repeatedly discussed the IFNAMSIZ (16) limit for
> > netdevice name length. Now when we have PF and VF representors
> > with port names like "pfXvfY", it became quite common to hit this limit:
> > 0123456789012345
> > enp131s0f1npf0vf6
> > enp131s0f1npf0vf22
> > 
> > Since IFLA_NAME is just a string, I though it might be possible to use
> > it to carry longer names as it is. However, the userspace tools, like
> > iproute2, are doing checks before print out. So for example in output of
> > "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> > completely avoided.
> > 
> > So here is a proposal that might work:
> > 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
> >    IFNAMSIZE, say 64 bytes. The max size should be only defined in kernel,
> >    user should be prepared for any string size.
> > 2) Add a file in sysfs that would indicate that NAME_EXT is supported by
> >    the kernel.
> > 3) Udev is going to look for the sysfs indication file. In case when
> >    kernel supports long names, it will do rename to longer name, setting
> >    IFLA_NAME_EXT. If not, it does what it does now - fail.
> > 4) There are two cases that can happen during rename:
> >    A) The name is shorter than IFNAMSIZ  
> >       -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:    
> >          original IFLA_NAME     = eth0
> >          original IFLA_NAME_EXT = eth0
> >          renamed  IFLA_NAME     = enp5s0f1npf0vf1
> >          renamed  IFLA_NAME_EXT = enp5s0f1npf0vf1
> >    B) The name is longer tha IFNAMSIZ  
> >       -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would     
> >          contain the new one:
> >          original IFLA_NAME     = eth0
> >          original IFLA_NAME_EXT = eth0
> >          renamed  IFLA_NAME     = eth0
> >          renamed  IFLA_NAME_EXT = enp131s0f1npf0vf22  
> 
> I think B is the only way, A risks duplicate IFLA_NAMEs over ioctl,
> right?  And maybe there is some crazy application out there which 
> mixes netlink and ioctl.
> 
> I guess it's not worse than status quo, given that today renames 
> will fail and we will either get truncated names or eth0s..
> 
> > This would allow the old tools to work with "eth0" and the new
> > tools would work with "enp131s0f1npf0vf22". In sysfs, there would
> > be symlink from one name to another.
> >       
> > Also, there might be a warning added to kernel if someone works
> > with IFLA_NAME that the userspace tool should be upgraded.
> > 
> > Eventually, only IFLA_NAME_EXT is going to be used by everyone.
> > 
> > I'm aware there are other places where similar new attribute
> > would have to be introduced too (ip rule for example).
> > I'm not saying this is a simple work.
> > 
> > Question is what to do with the ioctl api (get ifindex etc). I would
> > probably leave it as is and push tools to use rtnetlink instead.
> > 
> > Any ideas why this would not work? Any ideas how to solve this
> > differently?  
> 
> Since we'd have to update all user space to make use of the new names
> I'd be tempted to move to a more structured device identification.
> 
> 5: enp131s0f1npf0vf6: <BROADCAST,MULTICAST> ...
> 
> vs:
> 
> 5: eth5 (parent enp131s0f1 pf 0 vf 6 peer X*): <BROADCAST,MULTICAST> ...
> 
> * ;)
> 
> And allow filtering/selection of device based on more attributes than
> just name and ifindex.  In practice in container workloads, for example,
> the names are already very much insufficient to identify the device.
> Refocusing on attributes is probably a big effort and not that practical
> for traditional CLI users?  IDK
> 
> Anyway, IMHO your scheme is strictly better than status quo.

Or Cisco style naming ;-) Ethernet0/0 

There is a better solution for human use already.
the field ifalias allows arbitrary values and hooked into SNMP.

Why not have userspace fill in this field with something by default?

^ permalink raw reply

* Re: [net-next 00/10][pull request] Intel Wired LAN Driver Updates 2019-06-26
From: David Miller @ 2019-06-27 17:49 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190626193103.2169-1-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 26 Jun 2019 12:30:53 -0700

> This series contains updates to ixgbe and i40e only.

Pulled, thanks Jeff.

^ permalink raw reply

* Re: [RFC] longer netdev names proposal
From: Jakub Kicinski @ 2019-06-27 17:48 UTC (permalink / raw)
  To: Jiri Pirko; +Cc: netdev, davem, sthemmin, dsahern, mlxsw
In-Reply-To: <20190627094327.GF2424@nanopsycho>

On Thu, 27 Jun 2019 11:43:27 +0200, Jiri Pirko wrote:
> Hi all.
> 
> In the past, there was repeatedly discussed the IFNAMSIZ (16) limit for
> netdevice name length. Now when we have PF and VF representors
> with port names like "pfXvfY", it became quite common to hit this limit:
> 0123456789012345
> enp131s0f1npf0vf6
> enp131s0f1npf0vf22
> 
> Since IFLA_NAME is just a string, I though it might be possible to use
> it to carry longer names as it is. However, the userspace tools, like
> iproute2, are doing checks before print out. So for example in output of
> "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> completely avoided.
> 
> So here is a proposal that might work:
> 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
>    IFNAMSIZE, say 64 bytes. The max size should be only defined in kernel,
>    user should be prepared for any string size.
> 2) Add a file in sysfs that would indicate that NAME_EXT is supported by
>    the kernel.
> 3) Udev is going to look for the sysfs indication file. In case when
>    kernel supports long names, it will do rename to longer name, setting
>    IFLA_NAME_EXT. If not, it does what it does now - fail.
> 4) There are two cases that can happen during rename:
>    A) The name is shorter than IFNAMSIZ
>       -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:  
>          original IFLA_NAME     = eth0
>          original IFLA_NAME_EXT = eth0
>          renamed  IFLA_NAME     = enp5s0f1npf0vf1
>          renamed  IFLA_NAME_EXT = enp5s0f1npf0vf1
>    B) The name is longer tha IFNAMSIZ
>       -> IFLA_NAME would contain the original one, IFLA_NAME_EXT would   
>          contain the new one:
>          original IFLA_NAME     = eth0
>          original IFLA_NAME_EXT = eth0
>          renamed  IFLA_NAME     = eth0
>          renamed  IFLA_NAME_EXT = enp131s0f1npf0vf22

I think B is the only way, A risks duplicate IFLA_NAMEs over ioctl,
right?  And maybe there is some crazy application out there which 
mixes netlink and ioctl.

I guess it's not worse than status quo, given that today renames 
will fail and we will either get truncated names or eth0s..

> This would allow the old tools to work with "eth0" and the new
> tools would work with "enp131s0f1npf0vf22". In sysfs, there would
> be symlink from one name to another.
>       
> Also, there might be a warning added to kernel if someone works
> with IFLA_NAME that the userspace tool should be upgraded.
> 
> Eventually, only IFLA_NAME_EXT is going to be used by everyone.
> 
> I'm aware there are other places where similar new attribute
> would have to be introduced too (ip rule for example).
> I'm not saying this is a simple work.
> 
> Question is what to do with the ioctl api (get ifindex etc). I would
> probably leave it as is and push tools to use rtnetlink instead.
> 
> Any ideas why this would not work? Any ideas how to solve this
> differently?

Since we'd have to update all user space to make use of the new names
I'd be tempted to move to a more structured device identification.

5: enp131s0f1npf0vf6: <BROADCAST,MULTICAST> ...

vs:

5: eth5 (parent enp131s0f1 pf 0 vf 6 peer X*): <BROADCAST,MULTICAST> ...

* ;)

And allow filtering/selection of device based on more attributes than
just name and ifindex.  In practice in container workloads, for example,
the names are already very much insufficient to identify the device.
Refocusing on attributes is probably a big effort and not that practical
for traditional CLI users?  IDK

Anyway, IMHO your scheme is strictly better than status quo.

^ permalink raw reply

* Re: [PATCH bpf-next 1/3] libbpf: capture value in BTF type info for BTF-defined map defs
From: Andrii Nakryiko @ 2019-06-27 17:47 UTC (permalink / raw)
  To: Song Liu
  Cc: Andrii Nakryiko, Alexei Starovoitov, daniel@iogearbox.net,
	Kernel Team, bpf@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <E28D922F-9D97-4836-B687-B4CBC3549AE1@fb.com>

On Thu, Jun 27, 2019 at 10:27 AM Song Liu <songliubraving@fb.com> wrote:
>
>
>
> > On Jun 26, 2019, at 4:21 PM, Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > Change BTF-defined map definitions to capture compile-time integer
> > values as part of BTF type definition, to avoid split of key/value type
> > information and actual type/size/flags initialization for maps.
>
> If I have an old bpf program and compiled it with new llvm, will it
> work with new libbpf?

You mean BPF programs that used previous incarnation of BTF-defined
maps? No, they won't work. But we never released them, so I think it's
ok to change them. Nothing should be using that except for selftests,
which I fixed.

>
>
> >
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---

<snip>

> > diff --git a/tools/testing/selftests/bpf/bpf_helpers.h b/tools/testing/selftests/bpf/bpf_helpers.h
> > index 1a5b1accf091..aa5ddf58c088 100644
> > --- a/tools/testing/selftests/bpf/bpf_helpers.h
> > +++ b/tools/testing/selftests/bpf/bpf_helpers.h
> > @@ -8,6 +8,9 @@
> >  */
> > #define SEC(NAME) __attribute__((section(NAME), used))
> >
> > +#define __int(name, val) int (*name)[val]
> > +#define __type(name, val) val *name
> > +
>
> I think we need these two in libbpf.

Yes, but it's another story for another set of patches. We'll need to
provide bpf_helpers as part of libbpf for inclusion into BPF programs,
but there are a bunch of problems right now with existing
bpf_heplers.h that prevents us from just copying it into libbpf. We'll
need to resolve those first.

But then again, there is no use of __int and __type for user-space
programs, so for now it's ok.

>
> Thanks,
> Song
>
> > /* helper macro to print out debug messages */
> > #define bpf_printk(fmt, ...)                          \
> > ({                                                    \
> > --
> > 2.17.1
> >
>

^ permalink raw reply

* Re: [PATCH 79/87] net: vmxnet3: remove memset after dma_alloc_coherent
From: David Miller @ 2019-06-27 17:47 UTC (permalink / raw)
  To: huangfq.daxian; +Cc: doshir, pv-drivers, netdev, linux-kernel
In-Reply-To: <20190627174509.5829-1-huangfq.daxian@gmail.com>


I'd kindly request that you separate these sets of changes into one
set per subsystem and submit them properly that way.

I'm really not going to sift through 87 patches and pull out the ones
individually that got to my tree(s).  That's your job to collect them
into appropriate groups properly.

Thank you.

^ permalink raw reply

* [PATCH 74/87] ethernet: jme.c: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
  Cc: Fuqian Huang, Guo-Fu Tseng, David S. Miller, netdev, linux-kernel

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/jme.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/ethernet/jme.c b/drivers/net/ethernet/jme.c
index 76b7b7b85e35..0b668357db4d 100644
--- a/drivers/net/ethernet/jme.c
+++ b/drivers/net/ethernet/jme.c
@@ -582,11 +582,6 @@ jme_setup_tx_resources(struct jme_adapter *jme)
 	if (unlikely(!(txring->bufinf)))
 		goto err_free_txring;
 
-	/*
-	 * Initialize Transmit Descriptors
-	 */
-	memset(txring->alloc, 0, TX_RING_ALLOC_SIZE(jme->tx_ring_size));
-
 	return 0;
 
 err_free_txring:
-- 
2.11.0


^ permalink raw reply related

* [PATCH 75/87] ethernet: marvell: remove memset after pci_alloc_consistent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
  Cc: Fuqian Huang, Mirko Lindner, Stephen Hemminger, David S. Miller,
	netdev, linux-kernel

pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/marvell/skge.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 35a92fd2cf39..9ac854c2b371 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -2558,8 +2558,6 @@ static int skge_up(struct net_device *dev)
 		goto free_pci_mem;
 	}
 
-	memset(skge->mem, 0, skge->mem_size);
-
 	err = skge_ring_alloc(&skge->rx_ring, skge->mem, skge->dma);
 	if (err)
 		goto free_pci_mem;
-- 
2.11.0


^ permalink raw reply related

* [PATCH 73/87] ethernet: freescale: Remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
  Cc: Fuqian Huang, Fugang Duan, David S. Miller, netdev, linux-kernel

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 38f10f7dcbc3..ec87b8b78d21 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3143,8 +3143,6 @@ static int fec_enet_init(struct net_device *ndev)
 		return -ENOMEM;
 	}
 
-	memset(cbd_base, 0, bd_size);
-
 	/* Get the Ethernet address */
 	fec_get_mac(ndev);
 	/* make sure MAC we just acquired is programmed into the hw */
-- 
2.11.0


^ permalink raw reply related

* [PATCH 72/87] ethernet: chelsio: remove memset after kvzalloc
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
  Cc: Fuqian Huang, Vishal Kulkarni, David S. Miller, netdev,
	linux-kernel

kvzalloc already zeroes the memory.
memset is unneeded.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/chelsio/cxgb4/sched.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c b/drivers/net/ethernet/chelsio/cxgb4/sched.c
index ba6c153ee45c..60218dc676a8 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c
@@ -207,7 +207,6 @@ static int t4_sched_queue_bind(struct port_info *pi, struct ch_sched_queue *p)
 		goto out_err;
 
 	/* Bind queue to specified class */
-	memset(qe, 0, sizeof(*qe));
 	qe->cntxt_id = qid;
 	memcpy(&qe->param, p, sizeof(qe->param));
 
-- 
2.11.0


^ permalink raw reply related

* [PATCH 76/87] wireless: quantenna: pcie: remove memset after dmam_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:46 UTC (permalink / raw)
  Cc: Fuqian Huang, Igor Mitsyanko, Avinash Patil, Sergey Matyukevich,
	Kalle Valo, David S. Miller, Andrey Shevchenko, linux-wireless,
	netdev, linux-kernel

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c | 2 --
 drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
index 3aa3714d4dfd..5ec1c9bc1612 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c
@@ -244,8 +244,6 @@ static int pearl_alloc_bd_table(struct qtnf_pcie_pearl_state *ps)
 
 	/* tx bd */
 
-	memset(vaddr, 0, len);
-
 	ps->bd_table_vaddr = vaddr;
 	ps->bd_table_paddr = paddr;
 	ps->bd_table_len = len;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
index 9a4380ed7f1b..1f91088e3dff 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pcie/topaz_pcie.c
@@ -199,8 +199,6 @@ static int topaz_alloc_bd_table(struct qtnf_pcie_topaz_state *ts,
 	if (!vaddr)
 		return -ENOMEM;
 
-	memset(vaddr, 0, len);
-
 	/* tx bd */
 
 	ts->tx_bd_vbase = vaddr;
-- 
2.11.0


^ permalink raw reply related

* Re: [PATCH net-next 00/16] mlxsw: PTP timestamping support
From: David Miller @ 2019-06-27 17:46 UTC (permalink / raw)
  To: idosch; +Cc: richardcochran, netdev, jiri, petrm, mlxsw, idosch
In-Reply-To: <20190627173525.GA16859@splinter>

From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 27 Jun 2019 20:35:25 +0300

> On Thu, Jun 27, 2019 at 09:51:34AM -0700, Richard Cochran wrote:
>> On Thu, Jun 27, 2019 at 04:52:43PM +0300, Ido Schimmel wrote:
>> > From: Ido Schimmel <idosch@mellanox.com>
>> > 
>> > This is the second patchset adding PTP support in mlxsw. Next patchset
>> > will add PTP shapers which are required to maintain accuracy under rates
>> > lower than 40Gb/s, while subsequent patchsets will add tracepoints and
>> > selftests.
>> 
>> Please add the PTP maintainer onto CC for PTP patch submissions.
> 
> No problem. To be clear, I didn't Cc you since this is all internal to
> mlxsw.

That's not the issue.

As the PTP maintainer he wants to see if your driver is using the PTP
interfaces properly and providing PTP information as intended by the
various APIs.

^ permalink raw reply

* [PATCH 77/87] wireless: broadcom: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:45 UTC (permalink / raw)
  Cc: Fuqian Huang, Arend van Spriel, Franky Lin, Hante Meuleman,
	Chi-Hsien Lin, Wright Feng, Kalle Valo, David S. Miller,
	Rafał Miłecki, Hans de Goede, Luis Chamberlain,
	linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
	netdev, linux-kernel

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 83e4938527f4..3fc08fe7c3a2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1033,8 +1033,6 @@ brcmf_pcie_init_dmabuffer_for_device(struct brcmf_pciedev_info *devinfo,
 			       address & 0xffffffff);
 	brcmf_pcie_write_tcm32(devinfo, tcm_dma_phys_addr + 4, address >> 32);
 
-	memset(ring, 0, size);
-
 	return (ring);
 }
 
-- 
2.11.0


^ permalink raw reply related

* [PATCH 78/87] wireless: ath10k: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:45 UTC (permalink / raw)
  Cc: Fuqian Huang, Kalle Valo, David S. Miller, ath10k, linux-wireless,
	netdev, linux-kernel

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/wireless/ath/ath10k/ce.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index eca87f7c5b6c..294fbc1e89ab 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1704,9 +1704,6 @@ ath10k_ce_alloc_dest_ring_64(struct ath10k *ar, unsigned int ce_id,
 	/* Correctly initialize memory to 0 to prevent garbage
 	 * data crashing system when download firmware
 	 */
-	memset(dest_ring->base_addr_owner_space_unaligned, 0,
-	       nentries * sizeof(struct ce_desc_64) + CE_DESC_RING_ALIGN);
-
 	dest_ring->base_addr_owner_space =
 			PTR_ALIGN(dest_ring->base_addr_owner_space_unaligned,
 				  CE_DESC_RING_ALIGN);
@@ -2019,8 +2016,6 @@ void ath10k_ce_alloc_rri(struct ath10k *ar)
 		value |= ar->hw_ce_regs->upd->mask;
 		ath10k_ce_write32(ar, ce_base_addr + ctrl1_regs, value);
 	}
-
-	memset(ce->vaddr_rri, 0, CE_COUNT * sizeof(u32));
 }
 EXPORT_SYMBOL(ath10k_ce_alloc_rri);
 
-- 
2.11.0


^ permalink raw reply related

* [PATCH 79/87] net: vmxnet3: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:45 UTC (permalink / raw)
  Cc: Fuqian Huang, Ronak Doshi, VMware, Inc., David S. Miller, netdev,
	linux-kernel

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/vmxnet3/vmxnet3_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 89984fcab01e..a5ba7ed07e9c 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -3429,7 +3429,6 @@ vmxnet3_probe_device(struct pci_dev *pdev,
 			err = -ENOMEM;
 			goto err_ver;
 		}
-		memset(adapter->coal_conf, 0, sizeof(*adapter->coal_conf));
 		adapter->coal_conf->coalMode = VMXNET3_COALESCE_DISABLED;
 		adapter->default_coal_mode = true;
 	}
-- 
2.11.0


^ permalink raw reply related

* [PATCH 80/87] net: hippi: remove memset after pci_alloc_consistent
From: Fuqian Huang @ 2019-06-27 17:44 UTC (permalink / raw)
  Cc: Fuqian Huang, Jes Sorensen, David S. Miller, linux-hippi, netdev,
	linux-kernel

pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/hippi/rrunner.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c
index 7b9350dbebdd..2a6ec5394966 100644
--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/rrunner.c
@@ -1196,7 +1196,6 @@ static int rr_open(struct net_device *dev)
 		goto error;
 	}
 	rrpriv->rx_ctrl_dma = dma_addr;
-	memset(rrpriv->rx_ctrl, 0, 256*sizeof(struct ring_ctrl));
 
 	rrpriv->info = pci_alloc_consistent(pdev, sizeof(struct rr_info),
 					    &dma_addr);
@@ -1205,7 +1204,6 @@ static int rr_open(struct net_device *dev)
 		goto error;
 	}
 	rrpriv->info_dma = dma_addr;
-	memset(rrpriv->info, 0, sizeof(struct rr_info));
 	wmb();
 
 	spin_lock_irqsave(&rrpriv->lock, flags);
-- 
2.11.0


^ permalink raw reply related

* [PATCH 81/87] ethernet: ti: remove memset after pci_alloc_persistent
From: Fuqian Huang @ 2019-06-27 17:44 UTC (permalink / raw)
  Cc: Fuqian Huang, Samuel Chessman, David S. Miller, netdev,
	linux-kernel

pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/ti/tlan.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/tlan.c b/drivers/net/ethernet/ti/tlan.c
index b4ab1a5f6cd0..78f0f2d59e22 100644
--- a/drivers/net/ethernet/ti/tlan.c
+++ b/drivers/net/ethernet/ti/tlan.c
@@ -855,7 +855,6 @@ static int tlan_init(struct net_device *dev)
 		       dev->name);
 		return -ENOMEM;
 	}
-	memset(priv->dma_storage, 0, dma_size);
 	priv->rx_list = (struct tlan_list *)
 		ALIGN((unsigned long)priv->dma_storage, 8);
 	priv->rx_list_dma = ALIGN(priv->dma_storage_dma, 8);
-- 
2.11.0


^ permalink raw reply related

* [PATCH 82/87] ethernet: netxen: remove memset after pci_alloc_persistent
From: Fuqian Huang @ 2019-06-27 17:44 UTC (permalink / raw)
  Cc: Fuqian Huang, Manish Chopra, Rahul Verma, GR-Linux-NIC-Dev,
	David S. Miller, netdev, linux-kernel

pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
index 433052f734ed..5e9f8ee99800 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c
@@ -442,10 +442,8 @@ nx_fw_cmd_create_tx_ctx(struct netxen_adapter *adapter)
 		goto out_free_rq;
 	}
 
-	memset(rq_addr, 0, rq_size);
 	prq = rq_addr;
 
-	memset(rsp_addr, 0, rsp_size);
 	prsp = rsp_addr;
 
 	prq->host_rsp_dma_addr = cpu_to_le64(rsp_phys_addr);
@@ -755,7 +753,6 @@ int netxen_alloc_hw_resources(struct netxen_adapter *adapter)
 		return -ENOMEM;
 	}
 
-	memset(addr, 0, sizeof(struct netxen_ring_ctx));
 	recv_ctx->hwctx = addr;
 	recv_ctx->hwctx->ctx_id = cpu_to_le32(port);
 	recv_ctx->hwctx->cmd_consumer_offset =
-- 
2.11.0


^ permalink raw reply related

* [PATCH 83/87] ethernet: neterion: remove memset after pci_alloc_persistent
From: Fuqian Huang @ 2019-06-27 17:43 UTC (permalink / raw)
  Cc: Fuqian Huang, Jon Mason, David S. Miller, netdev, linux-kernel

pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/neterion/s2io.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/neterion/s2io.c b/drivers/net/ethernet/neterion/s2io.c
index 3b2ae1a21678..e0b2bf327905 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -747,7 +747,6 @@ static int init_shared_mem(struct s2io_nic *nic)
 				return -ENOMEM;
 			}
 			mem_allocated += size;
-			memset(tmp_v_addr, 0, size);
 
 			size = sizeof(struct rxd_info) *
 				rxd_count[nic->rxd_mode];
-- 
2.11.0


^ permalink raw reply related

* [PATCH 84/87] ethernet: mellanox: mlxsw: remove memset after pci_alloc_persistent
From: Fuqian Huang @ 2019-06-27 17:43 UTC (permalink / raw)
  Cc: Fuqian Huang, Jiri Pirko, Ido Schimmel, David S. Miller, netdev,
	linux-kernel

pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/mellanox/mlxsw/pci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index b40455f8293d..be310ac0883a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -835,7 +835,6 @@ static int mlxsw_pci_queue_init(struct mlxsw_pci *mlxsw_pci, char *mbox,
 					     &mem_item->mapaddr);
 	if (!mem_item->buf)
 		return -ENOMEM;
-	memset(mem_item->buf, 0, mem_item->size);
 
 	q->elem_info = kcalloc(q->count, sizeof(*q->elem_info), GFP_KERNEL);
 	if (!q->elem_info) {
-- 
2.11.0


^ permalink raw reply related

* [PATCH 85/87] ethernet: mellanox: mlx5: remove memset after kvzalloc
From: Fuqian Huang @ 2019-06-27 17:43 UTC (permalink / raw)
  Cc: Fuqian Huang, Saeed Mahameed, Leon Romanovsky, David S. Miller,
	netdev, linux-rdma, linux-kernel

kvzalloc already zeroes the memory.
So memset is unneeded.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/eswitch.c          | 1 -
 drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index 6a921e24cd5e..587c51fa3985 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -2391,7 +2391,6 @@ int mlx5_eswitch_get_vport_stats(struct mlx5_eswitch *esw,
 	MLX5_SET(query_vport_counter_in, in, vport_number, vport->vport);
 	MLX5_SET(query_vport_counter_in, in, other_vport, 1);
 
-	memset(out, 0, outlen);
 	err = mlx5_cmd_exec(esw->dev, in, sizeof(in), out, outlen);
 	if (err)
 		goto free_out;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 47b446d30f71..ef5fe3bd95f9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -993,7 +993,6 @@ static int esw_create_offloads_fdb_tables(struct mlx5_eswitch *esw, int nvports)
 	}
 
 	/* create send-to-vport group */
-	memset(flow_group_in, 0, inlen);
 	MLX5_SET(create_flow_group_in, flow_group_in, match_criteria_enable,
 		 MLX5_MATCH_MISC_PARAMETERS);
 
@@ -1151,7 +1150,6 @@ static int esw_create_vport_rx_group(struct mlx5_eswitch *esw, int nvports)
 		return -ENOMEM;
 
 	/* create vport rx group */
-	memset(flow_group_in, 0, inlen);
 	MLX5_SET(create_flow_group_in, flow_group_in, match_criteria_enable,
 		 MLX5_MATCH_MISC_PARAMETERS);
 
-- 
2.11.0


^ permalink raw reply related

* [PATCH 86/87] ethernet: mellanox:mlx4: replace kmalloc and memset with kzalloc
From: Fuqian Huang @ 2019-06-27 17:42 UTC (permalink / raw)
  Cc: Fuqian Huang, Tariq Toukan, David S. Miller, netdev, linux-rdma,
	linux-kernel

kmalloc + memset(0) -> kzalloc

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 6c01314e87b0..f1dff5c47676 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1062,7 +1062,7 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
 	struct mlx4_qp_context *context;
 	int err = 0;
 
-	context = kmalloc(sizeof(*context), GFP_KERNEL);
+	context = kzalloc(sizeof(*context), GFP_KERNEL);
 	if (!context)
 		return -ENOMEM;
 
@@ -1073,7 +1073,6 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv *priv, int qpn,
 	}
 	qp->event = mlx4_en_sqp_event;
 
-	memset(context, 0, sizeof(*context));
 	mlx4_en_fill_qp_context(priv, ring->actual_size, ring->stride, 0, 0,
 				qpn, ring->cqn, -1, context);
 	context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
-- 
2.11.0


^ permalink raw reply related

* [PATCH 87/87] ethernet: mlx4: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:42 UTC (permalink / raw)
  Cc: Fuqian Huang, Tariq Toukan, David S. Miller, netdev, linux-rdma,
	linux-kernel

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx4/eq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index a5be27772b8e..c790a5fcea73 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -1013,8 +1013,6 @@ static int mlx4_create_eq(struct mlx4_dev *dev, int nent,
 
 		dma_list[i] = t;
 		eq->page_list[i].map = t;
-
-		memset(eq->page_list[i].buf, 0, PAGE_SIZE);
 	}
 
 	eq->eqn = mlx4_bitmap_alloc(&priv->eq_table.bitmap);
-- 
2.11.0


^ permalink raw reply related

* [PATCH 38/87] ethernet: atlx: remove memset after pci_alloc_consistent in atl2.c
From: Fuqian Huang @ 2019-06-27 17:40 UTC (permalink / raw)
  Cc: Fuqian Huang, Jay Cliburn, Chris Snook, David S. Miller,
	Colin Ian King, Yang Wei, Allison Randal, Thomas Gleixner,
	Will Deacon, Mao Wenan, netdev, linux-kernel

pci_alloc_consitent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/atheros/atlx/atl2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/atheros/atlx/atl2.c b/drivers/net/ethernet/atheros/atlx/atl2.c
index 3a3fb5ce0fee..3aba38322717 100644
--- a/drivers/net/ethernet/atheros/atlx/atl2.c
+++ b/drivers/net/ethernet/atheros/atlx/atl2.c
@@ -291,7 +291,6 @@ static s32 atl2_setup_ring_resources(struct atl2_adapter *adapter)
 		&adapter->ring_dma);
 	if (!adapter->ring_vir_addr)
 		return -ENOMEM;
-	memset(adapter->ring_vir_addr, 0, adapter->ring_size);
 
 	/* Init TXD Ring */
 	adapter->txd_dma = adapter->ring_dma ;
-- 
2.11.0


^ permalink raw reply related

* [PATCH 40/87] ethernet: cavium: replace vmalloc and memset with vzalloc
From: Fuqian Huang @ 2019-06-27 17:39 UTC (permalink / raw)
  Cc: Fuqian Huang, Derek Chickles, Satanand Burla, Felix Manlunas,
	David S. Miller, netdev, linux-kernel

vmalloc + memset(0) -> vzalloc

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 4 +---
 drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
index 43d11c38b38a..cf3835da32c8 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -719,12 +719,10 @@ static int cn23xx_setup_pf_mbox(struct octeon_device *oct)
 	for (i = 0; i < oct->sriov_info.max_vfs; i++) {
 		q_no = i * oct->sriov_info.rings_per_vf;
 
-		mbox = vmalloc(sizeof(*mbox));
+		mbox = vzalloc(sizeof(*mbox));
 		if (!mbox)
 			goto free_mbox;
 
-		memset(mbox, 0, sizeof(struct octeon_mbox));
-
 		spin_lock_init(&mbox->lock);
 
 		mbox->oct_dev = oct;
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
index fda49404968c..b3bd2767d3dd 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
@@ -279,12 +279,10 @@ static int cn23xx_setup_vf_mbox(struct octeon_device *oct)
 {
 	struct octeon_mbox *mbox = NULL;
 
-	mbox = vmalloc(sizeof(*mbox));
+	mbox = vzalloc(sizeof(*mbox));
 	if (!mbox)
 		return 1;
 
-	memset(mbox, 0, sizeof(struct octeon_mbox));
-
 	spin_lock_init(&mbox->lock);
 
 	mbox->oct_dev = oct;
-- 
2.11.0


^ permalink raw reply related

* [PATCH 39/87] ethernet: bnxt: remove memset after dma_alloc_coherent
From: Fuqian Huang @ 2019-06-27 17:39 UTC (permalink / raw)
  Cc: Fuqian Huang, Michael Chan, David S. Miller, netdev, linux-kernel

In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.

Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index f758b2e0591f..1a51edb7de37 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -2622,8 +2622,6 @@ static int bnxt_alloc_tx_rings(struct bnxt *bp)
 			mapping = txr->tx_push_mapping +
 				sizeof(struct tx_push_bd);
 			txr->data_mapping = cpu_to_le64(mapping);
-
-			memset(txr->tx_push, 0, sizeof(struct tx_push_bd));
 		}
 		qidx = bp->tc_to_qidx[j];
 		ring->queue_id = bp->q_info[qidx].queue_id;
-- 
2.11.0


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox