[PATCH 19/28] dma-mapping: replace DMA_ATTR_NON_CONSISTENT with dma_{alloc,free}_pages

2020-08-19 Thread Christoph Hellwig
Add a new API to allocate and free pages that are guaranteed to be
addressable by a device, but otherwise behave like pages allocated by
alloc_pages.  The intended APIs to sync them for use with the device
and cpu are dma_sync_single_for_{device,cpu} that are also used for
streaming mappings.

Switch all drivers over to this new API, but keep the usage of the
crufty dma_cache_sync API for now, which will be cleaned up on a driver
by driver basis.

Signed-off-by: Christoph Hellwig 
---
 Documentation/core-api/dma-api.rst| 68 +++
 Documentation/core-api/dma-attributes.rst |  8 ---
 arch/alpha/kernel/pci_iommu.c |  2 +
 arch/arm/mm/dma-mapping-nommu.c   |  2 +
 arch/arm/mm/dma-mapping.c |  4 ++
 arch/ia64/hp/common/sba_iommu.c   |  2 +
 arch/mips/jazz/jazzdma.c  |  7 +--
 arch/powerpc/kernel/dma-iommu.c   |  2 +
 arch/powerpc/platforms/ps3/system-bus.c   |  4 ++
 arch/powerpc/platforms/pseries/vio.c  |  2 +
 arch/s390/pci/pci_dma.c   |  2 +
 arch/x86/kernel/amd_gart_64.c |  2 +
 drivers/iommu/dma-iommu.c |  2 +
 drivers/iommu/intel/iommu.c   |  4 ++
 drivers/net/ethernet/i825xx/lasi_82596.c  | 13 ++---
 drivers/net/ethernet/seeq/sgiseeq.c   | 12 ++--
 drivers/parisc/ccio-dma.c |  2 +
 drivers/parisc/sba_iommu.c|  2 +
 drivers/scsi/53c700.c |  8 +--
 drivers/scsi/sgiwd93.c| 12 ++--
 drivers/xen/swiotlb-xen.c |  2 +
 include/linux/dma-direct.h|  5 ++
 include/linux/dma-mapping.h   | 29 --
 include/linux/dma-noncoherent.h   |  3 -
 kernel/dma/direct.c   | 51 -
 kernel/dma/mapping.c  | 43 +-
 kernel/dma/ops_helpers.c  | 35 
 kernel/dma/virt.c |  2 +
 sound/mips/hal2.c | 20 +++
 29 files changed, 254 insertions(+), 96 deletions(-)

diff --git a/Documentation/core-api/dma-api.rst 
b/Documentation/core-api/dma-api.rst
index 90239348b30f6f..047fcfffa0e5cf 100644
--- a/Documentation/core-api/dma-api.rst
+++ b/Documentation/core-api/dma-api.rst
@@ -516,48 +516,53 @@ routines, e.g.:::
}
 
 
-Part II - Advanced dma usage
-
+Part II - Non-coherent DMA allocations
+--
 
-Warning: These pieces of the DMA API should not be used in the
-majority of cases, since they cater for unlikely corner cases that
-don't belong in usual drivers.
+These APIs allow to allocate pages that can be used like normal pages
+in the kernel direct mapping, but are guaranteed to be DMA addressable.
 
 If you don't understand how cache line coherency works between a
 processor and an I/O device, you should not be using this part of the
-API at all.
+API.
 
 ::
 
void *
-   dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
-   gfp_t flag, unsigned long attrs)
+   dma_alloc_pages(struct device *dev, size_t size, dma_addr_t *dma_handle,
+   enum dma_data_direction dir, gfp_t gfp)
+
+This routine allocates a region of  bytes of consistent memory.  It
+returns a pointer to the allocated region (in the processor's virtual address
+space) or NULL if the allocation failed. The returned memory is guanteed to
+behave like memory allocated using alloc_pages.
+
+It also returns a  which may be cast to an unsigned integer the
+same width as the bus and given to the device as the DMA address base of
+the region.
 
-Identical to dma_alloc_coherent() except that when the
-DMA_ATTR_NON_CONSISTENT flags is passed in the attrs argument, the
-platform will choose to return either consistent or non-consistent memory
-as it sees fit.  By using this API, you are guaranteeing to the platform
-that you have all the correct and necessary sync points for this memory
-in the driver should it choose to return non-consistent memory.
+The dir parameter specified if data is read and/or written by the device,
+see dma_map_single() for details.
 
-Note: where the platform can return consistent memory, it will
-guarantee that the sync points become nops.
+The gfp parameter allows the caller to specify the ``GFP_`` flags (see
+kmalloc()) for the allocation, but rejects flags used to specify a memory
+zone such as GFP_DMA or GFP_HIGHMEM.
 
-Warning:  Handling non-consistent memory is a real pain.  You should
-only use this API if you positively know your driver will be
-required to work on one of the rare (usually non-PCI) architectures
-that simply cannot make consistent memory.
+Before giving the memory to the device, dma_sync_single_for_device() needs
+to be called, and before reading memory written by the device,
+dma_sync_single_for_cpu(), just like for streaming DMA mappings that are
+reused.
 
 ::
 

[PATCH 20/28] sgiwd93: convert from dma_cache_sync to dma_sync_single_for_device

2020-08-19 Thread Christoph Hellwig
Use the proper modern API to transfer cache ownership for incoherent DMA.
This also means we can allocate the memory as DMA_TO_DEVICE instead
of bidirectional.

Signed-off-by: Christoph Hellwig 
---
 drivers/scsi/sgiwd93.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
index 133adcf99e9340..1538f65307f22f 100644
--- a/drivers/scsi/sgiwd93.c
+++ b/drivers/scsi/sgiwd93.c
@@ -95,7 +95,7 @@ void fill_hpc_entries(struct ip22_hostdata *hd, struct 
scsi_cmnd *cmd, int din)
 */
hcp->desc.pbuf = 0;
hcp->desc.cntinfo = HPCDMA_EOX;
-   dma_cache_sync(hd->dev, hd->cpu,
+   dma_sync_single_for_device(hd->dev, hd->dma,
   (unsigned long)(hcp + 1) - (unsigned long)hd->cpu,
   DMA_TO_DEVICE);
 }
@@ -235,7 +235,7 @@ static int sgiwd93_probe(struct platform_device *pdev)
hdata = host_to_hostdata(host);
hdata->dev = &pdev->dev;
hdata->cpu = dma_alloc_pages(&pdev->dev, HPC_DMA_SIZE, &hdata->dma,
-DMA_BIDIRECTIONAL, GFP_KERNEL);
+DMA_TO_DEVICE, GFP_KERNEL);
if (!hdata->cpu) {
printk(KERN_WARNING "sgiwd93: Could not allocate memory for "
   "host %d buffer.\n", unit);
@@ -275,7 +275,7 @@ static int sgiwd93_probe(struct platform_device *pdev)
free_irq(irq, host);
 out_free:
dma_free_pages(&pdev->dev, HPC_DMA_SIZE, hdata->cpu, hdata->dma,
-   DMA_BIDIRECTIONAL);
+   DMA_TO_DEVICE);
 out_put:
scsi_host_put(host);
 out:
@@ -292,7 +292,7 @@ static int sgiwd93_remove(struct platform_device *pdev)
scsi_remove_host(host);
free_irq(pd->irq, host);
dma_free_pages(&pdev->dev, HPC_DMA_SIZE, hdata->cpu, hdata->dma,
-   DMA_BIDIRECTIONAL);
+   DMA_TO_DEVICE);
scsi_host_put(host);
return 0;
 }
-- 
2.28.0



[PATCH] mwifiex: switch from 'pci_' to 'dma_' API

2020-08-19 Thread Christophe JAILLET
The wrappers in include/linux/pci-dma-compat.h should go away.

The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.

When memory is allocated in 'mwifiex_pcie_alloc_buffers()' (see details in
the call chain below) GFP_KERNEL can be used because both
'mwifiex_register()' and 'mwifiex_reinit_sw()' already use GFP_KERNEL.
(for 'mwifiex_reinit_sw()', it is hidden in a call to 'alloc_workqueue()')

The call chain is:
  mwifiex_register
--> mwifiex_init_pcie(.init_if function, see mwifiex_if_ops)
   [ or ]
  mwifiex_reinit_sw
-->mwifiex_pcie_up_dev   (.up_dev function, see mwifiex_if_ops)

[ then in both case ]
  -->mwifiex_pcie_alloc_buffers
--> mwifiex_pcie_create_txbd_ring
--> mwifiex_pcie_create_rxbd_ring
--> mwifiex_pcie_create_evtbd_ring
--> mwifiex_pcie_alloc_sleep_cookie_buf

@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL

@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE

@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE

@@
@@
-PCI_DMA_NONE
+DMA_NONE

@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)

@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(&e1->dev, e2, e3, GFP_)

@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(&e1->dev, e2, e3, e4, e5)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(&e1->dev, e2, e3, e4)

@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(&e1->dev, e2)

@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(&e1->dev, e2)

@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(&e1->dev, e2)

Signed-off-by: Christophe JAILLET 
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
   https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 153 ++--
 1 file changed, 78 insertions(+), 75 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 87b4ccca4b9a..94fe121bc45f 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -58,8 +58,8 @@ mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, 
struct sk_buff *skb,
struct pcie_service_card *card = adapter->card;
struct mwifiex_dma_mapping mapping;
 
-   mapping.addr = pci_map_single(card->dev, skb->data, size, flags);
-   if (pci_dma_mapping_error(card->dev, mapping.addr)) {
+   mapping.addr = dma_map_single(&card->dev->dev, skb->data, size, flags);
+   if (dma_mapping_error(&card->dev->dev, mapping.addr)) {
mwifiex_dbg(adapter, ERROR, "failed to map pci memory!\n");
return -1;
}
@@ -75,7 +75,7 @@ static void mwifiex_unmap_pci_memory(struct mwifiex_adapter 
*adapter,
struct mwifiex_dma_mapping mapping;
 
mwifiex_get_mapping(skb, &mapping);
-   pci_unmap_single(card->dev, mapping.addr, mapping.len, flags);
+   dma_unmap_single(&card->dev->dev, mapping.addr, mapping.len, flags);
 }
 
 /*
@@ -461,10 +461,9 @@ static void mwifiex_delay_for_sleep_cookie(struct 
mwifiex_adapter *adapter,
struct sk_buff *cmdrsp = card->cmdrsp_buf;
 
for (count = 0; count < max_delay_loop_cnt; count++) {
-   pci_dma_sync_single_for_cpu(card->dev,
-   MWIFIEX_SKB_DMA_ADDR(cmdrsp),
-   sizeof(sleep_cookie),
-   PCI_DMA_FROMDEVICE);
+   dma_sync_single_for_cpu(&card->dev->dev,

[PATCH 21/28] hal2: convert from dma_cache_sync to dma_sync_single_for_device

2020-08-19 Thread Christoph Hellwig
Use the proper modern API to transfer cache ownership for incoherent DMA.
This also means we can allocate the buffer memory with the proper
direction instead of bidirectional.

Signed-off-by: Christoph Hellwig 
---
 sound/mips/hal2.c | 44 
 1 file changed, 20 insertions(+), 24 deletions(-)

diff --git a/sound/mips/hal2.c b/sound/mips/hal2.c
index 746c410bd9bf11..c8e429a5f48f85 100644
--- a/sound/mips/hal2.c
+++ b/sound/mips/hal2.c
@@ -441,7 +441,8 @@ static inline void hal2_stop_adc(struct snd_hal2 *hal2)
hal2->adc.pbus.pbus->pbdma_ctrl = HPC3_PDMACTRL_LD;
 }
 
-static int hal2_alloc_dmabuf(struct snd_hal2 *hal2, struct hal2_codec *codec)
+static int hal2_alloc_dmabuf(struct snd_hal2 *hal2, struct hal2_codec *codec,
+   enum dma_data_direction buffer_dir)
 {
struct device *dev = hal2->card->dev;
struct hal2_desc *desc;
@@ -450,14 +451,14 @@ static int hal2_alloc_dmabuf(struct snd_hal2 *hal2, 
struct hal2_codec *codec)
int i;
 
codec->buffer = dma_alloc_pages(dev, H2_BUF_SIZE, &buffer_dma,
-   DMA_BIDIRECTIONAL, GFP_KERNEL);
+   buffer_dir, GFP_KERNEL);
if (!codec->buffer)
return -ENOMEM;
desc = dma_alloc_pages(dev, count * sizeof(struct hal2_desc), &desc_dma,
   DMA_BIDIRECTIONAL, GFP_KERNEL);
if (!desc) {
dma_free_pages(dev, H2_BUF_SIZE, codec->buffer, buffer_dma,
-   DMA_BIDIRECTIONAL);
+   buffer_dir);
return -ENOMEM;
}
codec->buffer_dma = buffer_dma;
@@ -470,20 +471,22 @@ static int hal2_alloc_dmabuf(struct snd_hal2 *hal2, 
struct hal2_codec *codec)
  desc_dma : desc_dma + (i + 1) * sizeof(struct hal2_desc);
desc++;
}
-   dma_cache_sync(dev, codec->desc, count * sizeof(struct hal2_desc),
-  DMA_TO_DEVICE);
+   dma_sync_single_for_device(dev, codec->desc_dma,
+  count * sizeof(struct hal2_desc),
+  DMA_BIDIRECTIONAL);
codec->desc_count = count;
return 0;
 }
 
-static void hal2_free_dmabuf(struct snd_hal2 *hal2, struct hal2_codec *codec)
+static void hal2_free_dmabuf(struct snd_hal2 *hal2, struct hal2_codec *codec,
+   enum dma_data_direction buffer_dir)
 {
struct device *dev = hal2->card->dev;
 
dma_free_pages(dev, codec->desc_count * sizeof(struct hal2_desc),
   codec->desc, codec->desc_dma, DMA_BIDIRECTIONAL);
dma_free_pages(dev, H2_BUF_SIZE, codec->buffer, codec->buffer_dma,
-   DMA_BIDIRECTIONAL);
+   buffer_dir);
 }
 
 static const struct snd_pcm_hardware hal2_pcm_hw = {
@@ -509,21 +512,16 @@ static int hal2_playback_open(struct snd_pcm_substream 
*substream)
 {
struct snd_pcm_runtime *runtime = substream->runtime;
struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
-   int err;
 
runtime->hw = hal2_pcm_hw;
-
-   err = hal2_alloc_dmabuf(hal2, &hal2->dac);
-   if (err)
-   return err;
-   return 0;
+   return hal2_alloc_dmabuf(hal2, &hal2->dac, DMA_TO_DEVICE);
 }
 
 static int hal2_playback_close(struct snd_pcm_substream *substream)
 {
struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
 
-   hal2_free_dmabuf(hal2, &hal2->dac);
+   hal2_free_dmabuf(hal2, &hal2->dac, DMA_TO_DEVICE);
return 0;
 }
 
@@ -579,7 +577,9 @@ static void hal2_playback_transfer(struct snd_pcm_substream 
*substream,
unsigned char *buf = hal2->dac.buffer + rec->hw_data;
 
memcpy(buf, substream->runtime->dma_area + rec->sw_data, bytes);
-   dma_cache_sync(hal2->card->dev, buf, bytes, DMA_TO_DEVICE);
+   dma_sync_single_for_device(hal2->card->dev,
+   hal2->dac.buffer_dma + rec->hw_data, bytes,
+   DMA_TO_DEVICE);
 
 }
 
@@ -597,22 +597,16 @@ static int hal2_capture_open(struct snd_pcm_substream 
*substream)
 {
struct snd_pcm_runtime *runtime = substream->runtime;
struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
-   struct hal2_codec *adc = &hal2->adc;
-   int err;
 
runtime->hw = hal2_pcm_hw;
-
-   err = hal2_alloc_dmabuf(hal2, adc);
-   if (err)
-   return err;
-   return 0;
+   return hal2_alloc_dmabuf(hal2, &hal2->adc, DMA_FROM_DEVICE);
 }
 
 static int hal2_capture_close(struct snd_pcm_substream *substream)
 {
struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
 
-   hal2_free_dmabuf(hal2, &hal2->adc);
+   hal2_free_dmabuf(hal2, &hal2->adc, DMA_FROM_DEVICE);
return 0;
 }
 
@@ -667,7 +661,9 @@ static void hal2_capture_transfer(struct snd_pcm_substream 
*substream,
struct snd_hal2 *hal2 = 

[PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

2020-08-19 Thread Christoph Hellwig
Use the proper modern API to transfer cache ownership for incoherent DMA.

Signed-off-by: Christoph Hellwig 
---
 drivers/net/ethernet/seeq/sgiseeq.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/seeq/sgiseeq.c 
b/drivers/net/ethernet/seeq/sgiseeq.c
index 39599bbb5d45b6..f91dae16d69a19 100644
--- a/drivers/net/ethernet/seeq/sgiseeq.c
+++ b/drivers/net/ethernet/seeq/sgiseeq.c
@@ -112,14 +112,18 @@ struct sgiseeq_private {
 
 static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
 {
-   dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
-  DMA_FROM_DEVICE);
+   struct sgiseeq_private *sp = netdev_priv(dev);
+
+   dma_sync_single_for_cpu(dev->dev.parent, VIRT_TO_DMA(sp, addr),
+   sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
 }
 
 static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
 {
-   dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
-  DMA_TO_DEVICE);
+   struct sgiseeq_private *sp = netdev_priv(dev);
+
+   dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
+   sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
 }
 
 static inline void hpc3_eth_reset(struct hpc3_ethregs *hregs)
-- 
2.28.0



[PATCH 15/28] dma-direct: remove __dma_to_phys

2020-08-19 Thread Christoph Hellwig
There is no harm in just always clearing the SME encryption bit, while
significantly simplifying the interface.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/include/asm/dma-direct.h  |  2 +-
 arch/mips/bmips/dma.c  |  2 +-
 arch/mips/cavium-octeon/dma-octeon.c   |  2 +-
 arch/mips/include/asm/dma-direct.h |  2 +-
 arch/mips/loongson2ef/fuloong-2e/dma.c |  2 +-
 arch/mips/loongson2ef/lemote-2f/dma.c  |  2 +-
 arch/mips/loongson64/dma.c |  2 +-
 arch/mips/pci/pci-ar2315.c |  2 +-
 arch/mips/pci/pci-xtalk-bridge.c   |  2 +-
 arch/mips/sgi-ip32/ip32-dma.c  |  2 +-
 arch/powerpc/include/asm/dma-direct.h  |  2 +-
 include/linux/dma-direct.h | 21 +++--
 kernel/dma/direct.c|  6 +-
 13 files changed, 23 insertions(+), 26 deletions(-)

diff --git a/arch/arm/include/asm/dma-direct.h 
b/arch/arm/include/asm/dma-direct.h
index 7c3001a6a775bf..a8cee87a93e8ab 100644
--- a/arch/arm/include/asm/dma-direct.h
+++ b/arch/arm/include/asm/dma-direct.h
@@ -8,7 +8,7 @@ static inline dma_addr_t __phys_to_dma(struct device *dev, 
phys_addr_t paddr)
return pfn_to_dma(dev, __phys_to_pfn(paddr)) + offset;
 }
 
-static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t 
dev_addr)
+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
 {
unsigned int offset = dev_addr & ~PAGE_MASK;
return __pfn_to_phys(dma_to_pfn(dev, dev_addr)) + offset;
diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
index df56bf4179e347..ba2a5d33dfd3fa 100644
--- a/arch/mips/bmips/dma.c
+++ b/arch/mips/bmips/dma.c
@@ -52,7 +52,7 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pa)
return pa;
 }
 
-phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dma_addr)
+phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
 {
struct bmips_dma_range *r;
 
diff --git a/arch/mips/cavium-octeon/dma-octeon.c 
b/arch/mips/cavium-octeon/dma-octeon.c
index 14ea680d180e07..388b13ba2558c2 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -177,7 +177,7 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t 
paddr)
return paddr;
 }
 
-phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr)
+phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
 {
 #ifdef CONFIG_PCI
if (dev && dev_is_pci(dev))
diff --git a/arch/mips/include/asm/dma-direct.h 
b/arch/mips/include/asm/dma-direct.h
index 14e352651ce946..8e178651c638c2 100644
--- a/arch/mips/include/asm/dma-direct.h
+++ b/arch/mips/include/asm/dma-direct.h
@@ -3,6 +3,6 @@
 #define _MIPS_DMA_DIRECT_H 1
 
 dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr);
-phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr);
+phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr);
 
 #endif /* _MIPS_DMA_DIRECT_H */
diff --git a/arch/mips/loongson2ef/fuloong-2e/dma.c 
b/arch/mips/loongson2ef/fuloong-2e/dma.c
index e122292bf6660a..83fadeb3fd7d56 100644
--- a/arch/mips/loongson2ef/fuloong-2e/dma.c
+++ b/arch/mips/loongson2ef/fuloong-2e/dma.c
@@ -6,7 +6,7 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
return paddr | 0x8000;
 }
 
-phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dma_addr)
+phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
 {
return dma_addr & 0x7fff;
 }
diff --git a/arch/mips/loongson2ef/lemote-2f/dma.c 
b/arch/mips/loongson2ef/lemote-2f/dma.c
index abf0e39d7e4696..302b43a14eee74 100644
--- a/arch/mips/loongson2ef/lemote-2f/dma.c
+++ b/arch/mips/loongson2ef/lemote-2f/dma.c
@@ -6,7 +6,7 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
return paddr | 0x8000;
 }
 
-phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dma_addr)
+phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
 {
if (dma_addr > 0x8fff)
return dma_addr;
diff --git a/arch/mips/loongson64/dma.c b/arch/mips/loongson64/dma.c
index dbfe6e82fddd1c..b3dc5d0bd2b113 100644
--- a/arch/mips/loongson64/dma.c
+++ b/arch/mips/loongson64/dma.c
@@ -13,7 +13,7 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t 
paddr)
return ((nid << 44) ^ paddr) | (nid << node_id_offset);
 }
 
-phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr)
+phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
 {
/* We extract 2bit node id (bit 44~47, only bit 44~45 used now) from
 * Loongson-3's 48bit address space and embed it into 40bit */
diff --git a/arch/mips/pci/pci-ar2315.c b/arch/mips/pci/pci-ar2315.c
index 490953f515282a..d88395684f487d 100644
--- a/arch/mips/pci/pci-ar2315.c
+++ b/arch/mips/pci/pci-ar2315.c
@@ -175,7 +175,7 @@ dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t 
paddr)
return paddr + ar2315_dev_offset(dev);
 }
 
-phys_addr_t __dma_to_phys(struct device *dev

[PATCH 14/28] dma-direct: use phys_to_dma_direct in dma_direct_alloc

2020-08-19 Thread Christoph Hellwig
Replace the currently open code copy.

Signed-off-by: Christoph Hellwig 
---
 kernel/dma/direct.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 01120510968fa1..2e280b9c063449 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -235,10 +235,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
goto out_encrypt_pages;
}
 done:
-   if (force_dma_unencrypted(dev))
-   *dma_handle = __phys_to_dma(dev, page_to_phys(page));
-   else
-   *dma_handle = phys_to_dma(dev, page_to_phys(page));
+   *dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
return ret;
 
 out_encrypt_pages:
-- 
2.28.0



[PATCH 16/28] dma-direct: rename and cleanup __phys_to_dma

2020-08-19 Thread Christoph Hellwig
The __phys_to_dma vs phys_to_dma distinction isn't exactly obvious.  Try
to improve the situation by renaming __phys_to_dma to
phys_to_dma_unencryped, and not forcing architectures that want to
override phys_to_dma to actually provide __phys_to_dma.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/include/asm/dma-direct.h  |  2 +-
 arch/mips/bmips/dma.c  |  2 +-
 arch/mips/cavium-octeon/dma-octeon.c   |  2 +-
 arch/mips/include/asm/dma-direct.h |  2 +-
 arch/mips/loongson2ef/fuloong-2e/dma.c |  2 +-
 arch/mips/loongson2ef/lemote-2f/dma.c  |  2 +-
 arch/mips/loongson64/dma.c |  2 +-
 arch/mips/pci/pci-ar2315.c |  2 +-
 arch/mips/pci/pci-xtalk-bridge.c   |  2 +-
 arch/mips/sgi-ip32/ip32-dma.c  |  2 +-
 arch/powerpc/include/asm/dma-direct.h  |  2 +-
 drivers/iommu/intel/iommu.c|  2 +-
 include/linux/dma-direct.h | 28 +++---
 kernel/dma/direct.c|  8 
 kernel/dma/swiotlb.c   |  4 ++--
 15 files changed, 34 insertions(+), 30 deletions(-)

diff --git a/arch/arm/include/asm/dma-direct.h 
b/arch/arm/include/asm/dma-direct.h
index a8cee87a93e8ab..bca0de56753439 100644
--- a/arch/arm/include/asm/dma-direct.h
+++ b/arch/arm/include/asm/dma-direct.h
@@ -2,7 +2,7 @@
 #ifndef ASM_ARM_DMA_DIRECT_H
 #define ASM_ARM_DMA_DIRECT_H 1
 
-static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
unsigned int offset = paddr & ~PAGE_MASK;
return pfn_to_dma(dev, __phys_to_pfn(paddr)) + offset;
diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
index ba2a5d33dfd3fa..49061b870680b9 100644
--- a/arch/mips/bmips/dma.c
+++ b/arch/mips/bmips/dma.c
@@ -40,7 +40,7 @@ static struct bmips_dma_range *bmips_dma_ranges;
 
 #define FLUSH_RAC  0x100
 
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pa)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t pa)
 {
struct bmips_dma_range *r;
 
diff --git a/arch/mips/cavium-octeon/dma-octeon.c 
b/arch/mips/cavium-octeon/dma-octeon.c
index 388b13ba2558c2..232fa1017b1ec9 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -168,7 +168,7 @@ void __init octeon_pci_dma_init(void)
 }
 #endif /* CONFIG_PCI */
 
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
 #ifdef CONFIG_PCI
if (dev && dev_is_pci(dev))
diff --git a/arch/mips/include/asm/dma-direct.h 
b/arch/mips/include/asm/dma-direct.h
index 8e178651c638c2..9a640118316c9d 100644
--- a/arch/mips/include/asm/dma-direct.h
+++ b/arch/mips/include/asm/dma-direct.h
@@ -2,7 +2,7 @@
 #ifndef _MIPS_DMA_DIRECT_H
 #define _MIPS_DMA_DIRECT_H 1
 
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr);
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr);
 phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr);
 
 #endif /* _MIPS_DMA_DIRECT_H */
diff --git a/arch/mips/loongson2ef/fuloong-2e/dma.c 
b/arch/mips/loongson2ef/fuloong-2e/dma.c
index 83fadeb3fd7d56..cea167d8aba8db 100644
--- a/arch/mips/loongson2ef/fuloong-2e/dma.c
+++ b/arch/mips/loongson2ef/fuloong-2e/dma.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
return paddr | 0x8000;
 }
diff --git a/arch/mips/loongson2ef/lemote-2f/dma.c 
b/arch/mips/loongson2ef/lemote-2f/dma.c
index 302b43a14eee74..3c9e994563578c 100644
--- a/arch/mips/loongson2ef/lemote-2f/dma.c
+++ b/arch/mips/loongson2ef/lemote-2f/dma.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
return paddr | 0x8000;
 }
diff --git a/arch/mips/loongson64/dma.c b/arch/mips/loongson64/dma.c
index b3dc5d0bd2b113..364f2f27c8723f 100644
--- a/arch/mips/loongson64/dma.c
+++ b/arch/mips/loongson64/dma.c
@@ -4,7 +4,7 @@
 #include 
 #include 
 
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
/* We extract 2bit node id (bit 44~47, only bit 44~45 used now) from
 * Loongson-3's 48bit address space and embed it into 40bit */
diff --git a/arch/mips/pci/pci-ar2315.c b/arch/mips/pci/pci-ar2315.c
index d88395684f487d..cef4a47ab06311 100644
--- a/arch/mips/pci/pci-ar2315.c
+++ b/arch/mips/pci/pci-ar2315.c
@@ -170,7 +170,7 @@ static inline dma_addr_t ar2315_dev_offset(struct device 
*dev)
return 0;
 }
 
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
return paddr + ar2315_dev_offset(dev);
 }
diff --git a/arc

[PATCH 11/28] dma-mapping: add (back) arch_dma_mark_clean for ia64

2020-08-19 Thread Christoph Hellwig
Add back a hook to optimize dcache flushing after reading executable
code using DMA.  This gets ia64 out of the business of pretending to
be dma incoherent just for this optimization.

Signed-off-by: Christoph Hellwig 
---
 arch/ia64/Kconfig   |  3 +--
 arch/ia64/kernel/dma-mapping.c  | 14 +-
 arch/ia64/mm/init.c |  3 +--
 include/linux/dma-direct.h  |  3 +++
 include/linux/dma-noncoherent.h |  8 
 kernel/dma/Kconfig  |  6 ++
 kernel/dma/direct.c |  3 +++
 7 files changed, 23 insertions(+), 17 deletions(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 5b4ec80bf5863a..513ba0c5d33610 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -8,6 +8,7 @@ menu "Processor type and features"
 
 config IA64
bool
+   select ARCH_HAS_DMA_MARK_CLEAN
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select ACPI
@@ -32,8 +33,6 @@ config IA64
select TTY
select HAVE_ARCH_TRACEHOOK
select HAVE_VIRT_CPU_ACCOUNTING
-   select DMA_NONCOHERENT_MMAP
-   select ARCH_HAS_SYNC_DMA_FOR_CPU
select VIRT_TO_BUS
select GENERIC_IRQ_PROBE
select GENERIC_PENDING_IRQ if SMP
diff --git a/arch/ia64/kernel/dma-mapping.c b/arch/ia64/kernel/dma-mapping.c
index 09ef9ce9988d1f..f640ed6fe1d576 100644
--- a/arch/ia64/kernel/dma-mapping.c
+++ b/arch/ia64/kernel/dma-mapping.c
@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
-#include 
+#include 
 #include 
 
 /* Set this to 1 if there is a HW IOMMU in the system */
@@ -7,15 +7,3 @@ int iommu_detected __read_mostly;
 
 const struct dma_map_ops *dma_ops;
 EXPORT_SYMBOL(dma_ops);
-
-void *arch_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
-{
-   return dma_direct_alloc_pages(dev, size, dma_handle, gfp, attrs);
-}
-
-void arch_dma_free(struct device *dev, size_t size, void *cpu_addr,
-   dma_addr_t dma_addr, unsigned long attrs)
-{
-   dma_direct_free_pages(dev, size, cpu_addr, dma_addr, attrs);
-}
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 0b3fb4c7af2920..02e5aa08294ee0 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -73,8 +73,7 @@ __ia64_sync_icache_dcache (pte_t pte)
  * DMA can be marked as "clean" so that lazy_mmu_prot_update() doesn't have to
  * flush them when they get mapped into an executable vm-area.
  */
-void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
-   enum dma_data_direction dir)
+void arch_dma_mark_clean(phys_addr_t paddr, size_t size)
 {
unsigned long pfn = PHYS_PFN(paddr);
 
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 5a3ce2a2479437..738485b3578062 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -153,6 +153,9 @@ static inline void dma_direct_sync_single_for_cpu(struct 
device *dev,
 
if (unlikely(is_swiotlb_buffer(paddr)))
swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU);
+
+   if (dir == DMA_FROM_DEVICE)
+   arch_dma_mark_clean(paddr, size);
 }
 
 static inline dma_addr_t dma_direct_map_page(struct device *dev,
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
index ca09a4e07d2d3d..b9bc6c557ea46f 100644
--- a/include/linux/dma-noncoherent.h
+++ b/include/linux/dma-noncoherent.h
@@ -108,6 +108,14 @@ static inline void arch_dma_prep_coherent(struct page 
*page, size_t size)
 }
 #endif /* CONFIG_ARCH_HAS_DMA_PREP_COHERENT */
 
+#ifdef CONFIG_ARCH_HAS_DMA_MARK_CLEAN
+void arch_dma_mark_clean(phys_addr_t paddr, size_t size);
+#else
+static inline void arch_dma_mark_clean(phys_addr_t paddr, size_t size)
+{
+}
+#endif /* ARCH_HAS_DMA_MARK_CLEAN */
+
 void *arch_dma_set_uncached(void *addr, size_t size);
 void arch_dma_clear_uncached(void *addr, size_t size);
 
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 847a9d1fa6343d..6cf7f7947ae797 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -43,6 +43,12 @@ config ARCH_HAS_DMA_SET_MASK
 config ARCH_HAS_DMA_WRITE_COMBINE
bool
 
+#
+# Select if the architectures provides the arch_dma_mark_clean hook
+#
+config ARCH_HAS_DMA_MARK_CLEAN
+   bool
+
 config DMA_DECLARE_COHERENT
bool
 
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index bb0041e9965975..1123e767f4315f 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -340,6 +340,9 @@ void dma_direct_sync_sg_for_cpu(struct device *dev,
if (unlikely(is_swiotlb_buffer(paddr)))
swiotlb_tbl_sync_single(dev, paddr, sg->length, dir,
SYNC_FOR_CPU);
+
+   if (dir == DMA_FROM_DEVICE)
+   arch_dma_mark_clean(paddr, sg->length);
}
 
if (!dev_is_dma_coherent(dev))
-- 
2.28.0



[PATCH 08/28] MIPS: make dma_sync_*_for_cpu a little less overzealous

2020-08-19 Thread Christoph Hellwig
When transferring DMA ownership back to the CPU there should never
be any writeback from the cache, as the buffer was owned by the
device until now.  Instead it should just be invalidated for the
mapping directions where the device could have written data.
Note that the changes rely on the fact that kmap_atomic is stubbed
out for the !HIGHMEM case to simplify the code a bit.

Signed-off-by: Christoph Hellwig 
---
 arch/mips/mm/dma-noncoherent.c | 44 +-
 1 file changed, 28 insertions(+), 16 deletions(-)

diff --git a/arch/mips/mm/dma-noncoherent.c b/arch/mips/mm/dma-noncoherent.c
index 563c2c0d0c8193..97a14adbafc99c 100644
--- a/arch/mips/mm/dma-noncoherent.c
+++ b/arch/mips/mm/dma-noncoherent.c
@@ -55,22 +55,34 @@ void *arch_dma_set_uncached(void *addr, size_t size)
return (void *)(__pa(addr) + UNCAC_BASE);
 }
 
-static inline void dma_sync_virt(void *addr, size_t size,
+static inline void dma_sync_virt_for_device(void *addr, size_t size,
enum dma_data_direction dir)
 {
switch (dir) {
case DMA_TO_DEVICE:
dma_cache_wback((unsigned long)addr, size);
break;
-
case DMA_FROM_DEVICE:
dma_cache_inv((unsigned long)addr, size);
break;
-
case DMA_BIDIRECTIONAL:
dma_cache_wback_inv((unsigned long)addr, size);
break;
+   default:
+   BUG();
+   }
+}
 
+static inline void dma_sync_virt_for_cpu(void *addr, size_t size,
+   enum dma_data_direction dir)
+{
+   switch (dir) {
+   case DMA_TO_DEVICE:
+   break;
+   case DMA_FROM_DEVICE:
+   case DMA_BIDIRECTIONAL:
+   dma_cache_inv((unsigned long)addr, size);
+   break;
default:
BUG();
}
@@ -82,7 +94,7 @@ static inline void dma_sync_virt(void *addr, size_t size,
  * configured then the bulk of this loop gets optimized out.
  */
 static inline void dma_sync_phys(phys_addr_t paddr, size_t size,
-   enum dma_data_direction dir)
+   enum dma_data_direction dir, bool for_device)
 {
struct page *page = pfn_to_page(paddr >> PAGE_SHIFT);
unsigned long offset = paddr & ~PAGE_MASK;
@@ -90,18 +102,20 @@ static inline void dma_sync_phys(phys_addr_t paddr, size_t 
size,
 
do {
size_t len = left;
+   void *addr;
 
if (PageHighMem(page)) {
-   void *addr;
-
if (offset + len > PAGE_SIZE)
len = PAGE_SIZE - offset;
+   }
+
+   addr = kmap_atomic(page);
+   if (for_device)
+   dma_sync_virt_for_device(addr + offset, len, dir);
+   else
+   dma_sync_virt_for_cpu(addr + offset, len, dir);
+   kunmap_atomic(addr);
 
-   addr = kmap_atomic(page);
-   dma_sync_virt(addr + offset, len, dir);
-   kunmap_atomic(addr);
-   } else
-   dma_sync_virt(page_address(page) + offset, size, dir);
offset = 0;
page++;
left -= len;
@@ -111,7 +125,7 @@ static inline void dma_sync_phys(phys_addr_t paddr, size_t 
size,
 void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
 {
-   dma_sync_phys(paddr, size, dir);
+   dma_sync_phys(paddr, size, dir, true);
 }
 
 #ifdef CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU
@@ -119,16 +133,14 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
enum dma_data_direction dir)
 {
if (cpu_needs_post_dma_flush())
-   dma_sync_phys(paddr, size, dir);
+   dma_sync_phys(paddr, size, dir, false);
 }
 #endif
 
 void arch_dma_cache_sync(struct device *dev, void *vaddr, size_t size,
enum dma_data_direction direction)
 {
-   BUG_ON(direction == DMA_NONE);
-
-   dma_sync_virt(vaddr, size, direction);
+   dma_sync_virt_for_device(vaddr, size, direction);
 }
 
 #ifdef CONFIG_DMA_PERDEV_COHERENT
-- 
2.28.0



[PATCH 13/28] dma-direct: lift gfp_t manipulation out of__dma_direct_alloc_pages

2020-08-19 Thread Christoph Hellwig
Move the detailed gfp_t setup from __dma_direct_alloc_pages into the
caller to clean things up a little.

Signed-off-by: Christoph Hellwig 
---
 kernel/dma/direct.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 8da9a62dd9a72c..01120510968fa1 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -108,7 +108,7 @@ static inline bool dma_should_free_from_pool(struct device 
*dev,
 }
 
 static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
-   gfp_t gfp, unsigned long attrs)
+   gfp_t gfp)
 {
int node = dev_to_node(dev);
struct page *page = NULL;
@@ -116,11 +116,6 @@ static struct page *__dma_direct_alloc_pages(struct device 
*dev, size_t size,
 
WARN_ON_ONCE(!PAGE_ALIGNED(size));
 
-   if (attrs & DMA_ATTR_NO_WARN)
-   gfp |= __GFP_NOWARN;
-
-   /* we always manually zero the memory once we are done: */
-   gfp &= ~__GFP_ZERO;
gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
   &phys_limit);
page = dma_alloc_contiguous(dev, size, gfp);
@@ -164,6 +159,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
 
size = PAGE_ALIGN(size);
+   if (attrs & DMA_ATTR_NO_WARN)
+   gfp |= __GFP_NOWARN;
 
if (dma_should_alloc_from_pool(dev, gfp, attrs)) {
ret = dma_alloc_from_pool(dev, size, &page, gfp);
@@ -172,7 +169,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
goto done;
}
 
-   page = __dma_direct_alloc_pages(dev, size, gfp, attrs);
+   /* we always manually zero the memory once we are done */
+   page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
if (!page)
return NULL;
 
-- 
2.28.0



[PATCH 07/28] 53c700: improve non-coherent DMA handling

2020-08-19 Thread Christoph Hellwig
Switch the 53c700 driver to only use non-coherent descriptor memory if it
really has to because dma_alloc_coherent fails.  This doesn't matter for
any of the platforms it runs on currently, but that will change soon.

To help with this two new helpers to transfer ownership to and from the
device are added that abstract the syncing of the non-coherent memory.
The two current bidirectional cases are mapped to transfers to the
device, as that appears to what they are used for.  Note that for parisc,
which is the only architecture this driver needs to use non-coherent
memory on, the direction argument of dma_cache_sync is ignored, so this
will not change behavior in any way.

Signed-off-by: Christoph Hellwig 
---
 drivers/scsi/53c700.c | 113 +++---
 drivers/scsi/53c700.h |   9 ++--
 2 files changed, 68 insertions(+), 54 deletions(-)

diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index 461b3babb601ef..b197ed9399e2e0 100644
--- a/drivers/scsi/53c700.c
+++ b/drivers/scsi/53c700.c
@@ -269,6 +269,20 @@ NCR_700_get_SXFER(struct scsi_device *SDp)
  spi_period(SDp->sdev_target));
 }
 
+static inline void dma_sync_to_dev(struct NCR_700_Host_Parameters *h,
+   void *addr, size_t size)
+{
+   if (h->noncoherent)
+   dma_cache_sync(h->dev, addr, size, DMA_TO_DEVICE);
+}
+
+static inline void dma_sync_from_dev(struct NCR_700_Host_Parameters *h,
+   void *addr, size_t size)
+{
+   if (h->noncoherent)
+   dma_cache_sync(h->dev, addr, size, DMA_FROM_DEVICE);
+}
+
 struct Scsi_Host *
 NCR_700_detect(struct scsi_host_template *tpnt,
   struct NCR_700_Host_Parameters *hostdata, struct device *dev)
@@ -283,9 +297,13 @@ NCR_700_detect(struct scsi_host_template *tpnt,
if(tpnt->sdev_attrs == NULL)
tpnt->sdev_attrs = NCR_700_dev_attrs;
 
-   memory = dma_alloc_attrs(dev, TOTAL_MEM_SIZE, &pScript,
-GFP_KERNEL, DMA_ATTR_NON_CONSISTENT);
-   if(memory == NULL) {
+   memory = dma_alloc_coherent(dev, TOTAL_MEM_SIZE, &pScript, GFP_KERNEL);
+   if (!memory) {
+   hostdata->noncoherent = 1;
+   memory = dma_alloc_attrs(dev, TOTAL_MEM_SIZE, &pScript,
+GFP_KERNEL, DMA_ATTR_NON_CONSISTENT);
+   }
+   if (!memory) {
printk(KERN_ERR "53c700: Failed to allocate memory for driver, 
detaching\n");
return NULL;
}
@@ -339,11 +357,11 @@ NCR_700_detect(struct scsi_host_template *tpnt,
for (j = 0; j < PATCHES; j++)
script[LABELPATCHES[j]] = bS_to_host(pScript + 
SCRIPT[LABELPATCHES[j]]);
/* now patch up fixed addresses. */
-   script_patch_32(hostdata->dev, script, MessageLocation,
+   script_patch_32(hostdata, script, MessageLocation,
pScript + MSGOUT_OFFSET);
-   script_patch_32(hostdata->dev, script, StatusAddress,
+   script_patch_32(hostdata, script, StatusAddress,
pScript + STATUS_OFFSET);
-   script_patch_32(hostdata->dev, script, ReceiveMsgAddress,
+   script_patch_32(hostdata, script, ReceiveMsgAddress,
pScript + MSGIN_OFFSET);
 
hostdata->script = script;
@@ -395,8 +413,12 @@ NCR_700_release(struct Scsi_Host *host)
struct NCR_700_Host_Parameters *hostdata = 
(struct NCR_700_Host_Parameters *)host->hostdata[0];
 
-   dma_free_attrs(hostdata->dev, TOTAL_MEM_SIZE, hostdata->script,
-  hostdata->pScript, DMA_ATTR_NON_CONSISTENT);
+   if (hostdata->noncoherent)
+   dma_free_attrs(hostdata->dev, TOTAL_MEM_SIZE, hostdata->script,
+  hostdata->pScript, DMA_ATTR_NON_CONSISTENT);
+   else
+   dma_free_coherent(hostdata->dev, TOTAL_MEM_SIZE,
+ hostdata->script, hostdata->pScript);
return 1;
 }
 
@@ -804,8 +826,8 @@ process_extended_message(struct Scsi_Host *host,
shost_printk(KERN_WARNING, host,
"Unexpected SDTR msg\n");
hostdata->msgout[0] = A_REJECT_MSG;
-   dma_cache_sync(hostdata->dev, hostdata->msgout, 1, 
DMA_TO_DEVICE);
-   script_patch_16(hostdata->dev, hostdata->script,
+   dma_sync_to_dev(hostdata, hostdata->msgout, 1);
+   script_patch_16(hostdata, hostdata->script,
MessageCount, 1);
/* SendMsgOut returns, so set up the return
 * address */
@@ -817,9 +839,8 @@ process_extended_message(struct Scsi_Host *host,
printk(KERN_INFO "scsi%d: (%d:%d), Unsolicited WDTR after CMD, 
Rejecting\n",
   host->host_no, pun, lun);
hostdata->msgout[0] 

[PATCH 02/28] drm/exynos: stop setting DMA_ATTR_NON_CONSISTENT

2020-08-19 Thread Christoph Hellwig
DMA_ATTR_NON_CONSISTENT is a no-op except on PARISC and some mips
configs, so don't set it in this ARM specific driver.

Signed-off-by: Christoph Hellwig 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index efa476858db54b..07073222b8f691 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -42,8 +42,6 @@ static int exynos_drm_alloc_buf(struct exynos_drm_gem 
*exynos_gem, bool kvmap)
if (exynos_gem->flags & EXYNOS_BO_WC ||
!(exynos_gem->flags & EXYNOS_BO_CACHABLE))
attr |= DMA_ATTR_WRITE_COMBINE;
-   else
-   attr |= DMA_ATTR_NON_CONSISTENT;
 
/* FBDev emulation requires kernel mapping */
if (!kvmap)
-- 
2.28.0



[PATCH 04/28] net/au1000-eth: stop using DMA_ATTR_NON_CONSISTENT

2020-08-19 Thread Christoph Hellwig
The au1000-eth driver contains none of the manual cache synchronization
required for using DMA_ATTR_NON_CONSISTENT.  From what I can tell it
can be used on both dma coherent and non-coherent DMA platforms, but
I suspect it has been buggy on the non-coherent platforms all along.

Signed-off-by: Christoph Hellwig 
---
 drivers/net/ethernet/amd/au1000_eth.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/amd/au1000_eth.c 
b/drivers/net/ethernet/amd/au1000_eth.c
index 75dbd221dc594b..19e195420e2434 100644
--- a/drivers/net/ethernet/amd/au1000_eth.c
+++ b/drivers/net/ethernet/amd/au1000_eth.c
@@ -1131,10 +1131,9 @@ static int au1000_probe(struct platform_device *pdev)
/* Allocate the data buffers
 * Snooping works fine with eth on all au1xxx
 */
-   aup->vaddr = (u32)dma_alloc_attrs(&pdev->dev, MAX_BUF_SIZE *
+   aup->vaddr = (u32)dma_alloc_coherent(&pdev->dev, MAX_BUF_SIZE *
  (NUM_TX_BUFFS + NUM_RX_BUFFS),
- &aup->dma_addr, 0,
- DMA_ATTR_NON_CONSISTENT);
+ &aup->dma_addr, 0);
if (!aup->vaddr) {
dev_err(&pdev->dev, "failed to allocate data buffers\n");
err = -ENOMEM;
@@ -1310,9 +1309,8 @@ static int au1000_probe(struct platform_device *pdev)
 err_remap2:
iounmap(aup->mac);
 err_remap1:
-   dma_free_attrs(&pdev->dev, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
-   (void *)aup->vaddr, aup->dma_addr,
-   DMA_ATTR_NON_CONSISTENT);
+   dma_free_coherent(&pdev->dev, MAX_BUF_SIZE * (NUM_TX_BUFFS + 
NUM_RX_BUFFS),
+   (void *)aup->vaddr, aup->dma_addr);
 err_vaddr:
free_netdev(dev);
 err_alloc:
@@ -1344,9 +1342,8 @@ static int au1000_remove(struct platform_device *pdev)
if (aup->tx_db_inuse[i])
au1000_ReleaseDB(aup, aup->tx_db_inuse[i]);
 
-   dma_free_attrs(&pdev->dev, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
-   (void *)aup->vaddr, aup->dma_addr,
-   DMA_ATTR_NON_CONSISTENT);
+   dma_free_coherent(&pdev->dev, MAX_BUF_SIZE * (NUM_TX_BUFFS + 
NUM_RX_BUFFS),
+   (void *)aup->vaddr, aup->dma_addr);
 
iounmap(aup->macdma);
iounmap(aup->mac);
-- 
2.28.0



[PATCH 10/28] MIPS/jazzdma: decouple from dma-direct

2020-08-19 Thread Christoph Hellwig
The jazzdma ops implement support for a very basic IOMMU.  Thus we really
should not use the dma-direct code that takes physical address limits
into account.  This survived through the great MIPS DMA ops cleanup mostly
because I was lazy, but now it is time to fully split the implementations.

Signed-off-by: Christoph Hellwig 
---
 arch/mips/jazz/jazzdma.c | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/arch/mips/jazz/jazzdma.c b/arch/mips/jazz/jazzdma.c
index fe40dbed04c1d6..d0b5a2ba2b1a8a 100644
--- a/arch/mips/jazz/jazzdma.c
+++ b/arch/mips/jazz/jazzdma.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -492,26 +491,38 @@ int vdma_get_enable(int channel)
 static void *jazz_dma_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
+   struct page *page;
void *ret;
 
-   ret = dma_direct_alloc_pages(dev, size, dma_handle, gfp, attrs);
-   if (!ret)
-   return NULL;
+   if (attrs & DMA_ATTR_NO_WARN)
+   gfp |= __GFP_NOWARN;
 
-   *dma_handle = vdma_alloc(virt_to_phys(ret), size);
-   if (*dma_handle == DMA_MAPPING_ERROR) {
-   dma_direct_free_pages(dev, size, ret, *dma_handle, attrs);
+   size = PAGE_ALIGN(size);
+   page = alloc_pages(gfp, get_order(size));
+   if (!page)
return NULL;
-   }
+   ret = page_address(page);
+   *dma_handle = vdma_alloc(virt_to_phys(ret), size);
+   if (*dma_handle == DMA_MAPPING_ERROR)
+   goto out_free_pages;
+
+   if (attrs & DMA_ATTR_NON_CONSISTENT)
+   return ret;
+   arch_dma_prep_coherent(page, size);
+   return (void *)(UNCAC_BASE + __pa(ret));
 
-   return ret;
+out_free_pages:
+   __free_pages(page, get_order(size));
+   return NULL;
 }
 
 static void jazz_dma_free(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle, unsigned long attrs)
 {
vdma_free(dma_handle);
-   dma_direct_free_pages(dev, size, vaddr, dma_handle, attrs);
+   if (!(attrs & DMA_ATTR_NON_CONSISTENT))
+   vaddr = __va(vaddr - UNCAC_BASE);
+   __free_pages(virt_to_page(vaddr), get_order(size));
 }
 
 static dma_addr_t jazz_dma_map_page(struct device *dev, struct page *page,
@@ -608,7 +619,6 @@ const struct dma_map_ops jazz_dma_ops = {
.sync_single_for_device = jazz_dma_sync_single_for_device,
.sync_sg_for_cpu= jazz_dma_sync_sg_for_cpu,
.sync_sg_for_device = jazz_dma_sync_sg_for_device,
-   .dma_supported  = dma_direct_supported,
.cache_sync = arch_dma_cache_sync,
.mmap   = dma_common_mmap,
.get_sgtable= dma_common_get_sgtable,
-- 
2.28.0



[PATCH 03/28] drm/nouveau/gk20a: stop setting DMA_ATTR_NON_CONSISTENT

2020-08-19 Thread Christoph Hellwig
DMA_ATTR_NON_CONSISTENT is a no-op except on PARISC and some mips
configs, so don't set it in this ARM specific driver part.

Signed-off-by: Christoph Hellwig 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index 985f2990ab0dda..13d4d7ac0697b4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -594,8 +594,7 @@ gk20a_instmem_new(struct nvkm_device *device, int index,
 
nvkm_info(&imem->base.subdev, "using IOMMU\n");
} else {
-   imem->attrs = DMA_ATTR_NON_CONSISTENT |
- DMA_ATTR_WEAK_ORDERING |
+   imem->attrs = DMA_ATTR_WEAK_ORDERING |
  DMA_ATTR_WRITE_COMBINE;
 
nvkm_info(&imem->base.subdev, "using DMA API\n");
-- 
2.28.0



[PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

2020-08-19 Thread Christoph Hellwig
The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, and causes
weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is
unimplemented except on PARISC and some MIPS configs, and about to be
removed.

Signed-off-by: Christoph Hellwig 
---
 .../userspace-api/media/v4l/buffer.rst| 17 -
 .../media/v4l/vidioc-reqbufs.rst  |  1 -
 .../media/common/videobuf2/videobuf2-core.c   | 36 +--
 .../common/videobuf2/videobuf2-dma-contig.c   | 19 --
 .../media/common/videobuf2/videobuf2-dma-sg.c |  3 +-
 .../media/common/videobuf2/videobuf2-v4l2.c   | 12 ---
 include/media/videobuf2-core.h|  3 +-
 include/uapi/linux/videodev2.h|  2 --
 8 files changed, 3 insertions(+), 90 deletions(-)

diff --git a/Documentation/userspace-api/media/v4l/buffer.rst 
b/Documentation/userspace-api/media/v4l/buffer.rst
index 57e752aaf414a7..2044ed13cd9d7d 100644
--- a/Documentation/userspace-api/media/v4l/buffer.rst
+++ b/Documentation/userspace-api/media/v4l/buffer.rst
@@ -701,23 +701,6 @@ Memory Consistency Flags
 :stub-columns: 0
 :widths:   3 1 4
 
-* .. _`V4L2-FLAG-MEMORY-NON-CONSISTENT`:
-
-  - ``V4L2_FLAG_MEMORY_NON_CONSISTENT``
-  - 0x0001
-  - A buffer is allocated either in consistent (it will be automatically
-   coherent between the CPU and the bus) or non-consistent memory. The
-   latter can provide performance gains, for instance the CPU cache
-   sync/flush operations can be avoided if the buffer is accessed by the
-   corresponding device only and the CPU does not read/write to/from that
-   buffer. However, this requires extra care from the driver -- it must
-   guarantee memory consistency by issuing a cache flush/sync when
-   consistency is needed. If this flag is set V4L2 will attempt to
-   allocate the buffer in non-consistent memory. The flag takes effect
-   only if the buffer is used for :ref:`memory mapping ` I/O and the
-   queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
-   ` capability.
-
 .. c:type:: v4l2_memory
 
 enum v4l2_memory
diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst 
b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
index 75d894d9c36c42..3180c111d368ee 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
@@ -169,7 +169,6 @@ aborting or finishing any DMA in progress, an implicit
   - This capability is set by the driver to indicate that the queue 
supports
 cache and memory management hints. However, it's only valid when the
 queue is used for :ref:`memory mapping ` streaming I/O. See
-:ref:`V4L2_FLAG_MEMORY_NON_CONSISTENT 
`,
 :ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 
` and
 :ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN `.
 
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index f544d3393e9d6b..66a41cef33c1b1 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -721,39 +721,14 @@ int vb2_verify_memory_type(struct vb2_queue *q,
 }
 EXPORT_SYMBOL(vb2_verify_memory_type);
 
-static void set_queue_consistency(struct vb2_queue *q, bool consistent_mem)
-{
-   q->dma_attrs &= ~DMA_ATTR_NON_CONSISTENT;
-
-   if (!vb2_queue_allows_cache_hints(q))
-   return;
-   if (!consistent_mem)
-   q->dma_attrs |= DMA_ATTR_NON_CONSISTENT;
-}
-
-static bool verify_consistency_attr(struct vb2_queue *q, bool consistent_mem)
-{
-   bool queue_is_consistent = !(q->dma_attrs & DMA_ATTR_NON_CONSISTENT);
-
-   if (consistent_mem != queue_is_consistent) {
-   dprintk(q, 1, "memory consistency model mismatch\n");
-   return false;
-   }
-   return true;
-}
-
 int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
 unsigned int flags, unsigned int *count)
 {
unsigned int num_buffers, allocated_buffers, num_planes = 0;
unsigned plane_sizes[VB2_MAX_PLANES] = { };
-   bool consistent_mem = true;
unsigned int i;
int ret;
 
-   if (flags & V4L2_FLAG_MEMORY_NON_CONSISTENT)
-   consistent_mem = false;
-
if (q->streaming) {
dprintk(q, 1, "streaming active\n");
return -EBUSY;
@@ -765,8 +740,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
memory,
}
 
if (*count == 0 || q->num_buffers != 0 ||
-   (q->memory != VB2_MEMORY_UNKNOWN && q->memory != memory) ||
-   !verify_consistency_attr(q, consistent_mem)) {
+   (q->memory != VB2_MEMORY_UNKNOWN && q->memory != memory)) {
/*
 * We already have buffers allocated, so first check if they
 * are not in use and can be freed.
@@ -803,7 +777,6 @@ i

Re: [PATCH net v6] net: xdp: account for layer 3 packets in generic skb handler

2020-08-19 Thread Jesper Dangaard Brouer
On Sat, 15 Aug 2020 09:41:02 +0200
"Jason A. Donenfeld"  wrote:

> A user reported that packets from wireguard were possibly ignored by XDP
> [1]. Another user reported that modifying packets from layer 3
> interfaces results in impossible to diagnose drops.
> 
> Apparently, the generic skb xdp handler path seems to assume that
> packets will always have an ethernet header, which really isn't always
> the case for layer 3 packets, which are produced by multiple drivers.
> This patch fixes the oversight. If the mac_len is 0 and so is
> hard_header_len, then we know that the skb is a layer 3 packet, and in
> that case prepend a pseudo ethhdr to the packet whose h_proto is copied
> from skb->protocol, which will have the appropriate v4 or v6 ethertype.
> This allows us to keep XDP programs' assumption correct about packets
> always having that ethernet header, so that existing code doesn't break,
> while still allowing layer 3 devices to use the generic XDP handler.
> 
> We push on the ethernet header and then pull it right off and set
> mac_len to the ethernet header size, so that the rest of the XDP code
> does not need any changes. That is, it makes it so that the skb has its
> ethernet header just before the data pointer, of size ETH_HLEN.
> 
> Previous discussions have included the point that maybe XDP should just
> be intentionally broken on layer 3 interfaces, by design, and that layer
> 3 people should be using cls_bpf. However, I think there are good
> grounds to reconsider this perspective:
> 
> - Complicated deployments wind up applying XDP modifications to a
>   variety of different devices on a given host, some of which are using
>   specialized ethernet cards and other ones using virtual layer 3
>   interfaces, such as WireGuard. Being able to apply one codebase to
>   each of these winds up being essential.
> 
> - cls_bpf does not support the same feature set as XDP, and operates at
>   a slightly different stage in the networking stack. You may reply,
>   "then add all the features you want to cls_bpf", but that seems to be
>   missing the point, and would still result in there being two ways to
>   do everything, which is not desirable for anyone actually _using_ this
>   code.
> 
> - While XDP was originally made for hardware offloading, and while many
>   look disdainfully upon the generic mode, it nevertheless remains a
>   highly useful and popular way of adding bespoke packet
>   transformations, and from that perspective, a difference between layer
>   2 and layer 3 packets is immaterial if the user is primarily concerned
>   with transformations to layer 3 and beyond.
> 
> - It's not impossible to imagine layer 3 hardware (e.g. a WireGuard PCIe
>   card) including eBPF/XDP functionality built-in. In that case, why
>   limit XDP as a technology to only layer 2? Then, having generic XDP
>   work for layer 3 would naturally fit as well.
> 
> [1] https://lore.kernel.org/wireguard/m5wzvk5--...@tuta.io/
> 
> Reported-by: Thomas Ptacek 
> Reported-by: Adhipati Blambangan 
> Cc: David Ahern 
> Cc: Toke Høiland-Jørgensen 
> Cc: Jakub Kicinski 
> Cc: Alexei Starovoitov 
> Cc: Jesper Dangaard Brouer 
> Cc: John Fastabend 
> Cc: Daniel Borkmann 
> Cc: David S. Miller 
> Signed-off-by: Jason A. Donenfeld 
> ---
> 
> I had originally dropped this patch, but the issue kept coming up in
> user reports, so here's a v4 of it. Testing of it is still rather slim,
> but hopefully that will change in the coming days.
> 
> Changes v5->v6:
> - The fix to the skb->protocol changing case is now in a separate
>   stand-alone patch, and removed from this one, so that it can be
>   evaluated separately.
> 
> Changes v4->v5:
> - Rather than tracking in a messy manner whether the skb is l3, we just
>   do the check once, and then adjust the skb geometry to be identical to
>   the l2 case. This simplifies the code quite a bit.
> - Fix a preexisting bug where the l2 header remained attached if
>   skb->protocol was updated.
> 
> Changes v3->v4:
> - We now preserve the same logic for XDP_TX/XDP_REDIRECT as before.
> - hard_header_len is checked in addition to mac_len.
> 
>  net/core/dev.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 151f1651439f..79c15f4244e6 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4630,6 +4630,18 @@ static u32 netif_receive_generic_xdp(struct sk_buff 
> *skb,
>* header.
>*/
>   mac_len = skb->data - skb_mac_header(skb);
> + if (!mac_len && !skb->dev->hard_header_len) {
> + /* For l3 packets, we push on a fake mac header, and then
> +  * pull it off again, so that it has the same skb geometry
> +  * as for the l2 case.
> +  */
> + eth = skb_push(skb, ETH_HLEN);
> + eth_zero_addr(eth->h_source);
> + eth_zero_addr(eth->h_dest);
> + eth->h_proto = skb->protocol;
> + __skb_pull(skb, ETH_HLEN)

Re: 答复: [Intel-wired-lan] [PATCH 0/2] intel/xdp fixes for fliping rx buffer

2020-08-19 Thread Björn Töpel

On 2020-08-19 03:37, Li,Rongqing wrote:
[...]
> Hi:
>
> Thanks for your explanation.
>
> But we can reproduce this bug
>
> We use ebpf to redirect only-Vxlan packets to non-zerocopy AF_XDP, 
First we see panic on tcp stack, in tcp_collapse: BUG_ON(offset < 0); it 
is very hard to reproduce.

>
> Then we use the scp to do test, and has lots of vxlan packet at the 
same time, scp will be broken frequently.

>

Ok! Just so that I'm certain of your setup. You receive packets to an
i40e netdev where there's an XDP program. The program does XDP_PASS or
XDP_REDIRECT to e.g. devmap for non-vxlan packets. However, vxlan
packets are redirected to AF_XDP socket(s) in *copy-mode*. Am I
understanding that correct?

I'm assuming this is an x86-64 with 4k page size, right? :-) The page
flipping is a bit different if the PAGE_SIZE is not 4k.

> With this fixes, scp has not been broken again, and kernel is not 
panic again

>

Let's dig into your scenario.

Are you saying the following:

Page A:
+
| "first skb" > Rx HW ring entry X
+
| "second skb"> Rx HW ring entry X+1 (or X+n)
+

This is a scenario that shouldn't be allowed, because there are now
two users of the page. If that's the case, the refcounting is
broken. Is that the case?

Check out i40e_can_reuse_rx_page(). The idea with page flipping/reuse
is that the page is only reused if there is only one user.

> Seem your explanation is unable to solve my analysis:
>
> 1. first skb is not for xsk, and forwarded to another device
>or socket queue

The data for the "first skb" resides on a page:
A:
+
| "first skb"
+
| to be reused
+
refcount >>1

> 2. seconds skb is for xsk, copy data to xsk memory, and page
>of skb->data is released

Note that page B != page A.

B:
+
| to be reused/or used by the stack
+
| "second skb for xsk"
+
refcount >>1

data is copied to socket, page_frag_free() is called, and the page
count is decreased. The driver will then check if the page can be
reused. If not, it's freed to the page allocator.

> 3. rx_buff is reusable since only first skb is in it, but
>*_rx_buffer_flip will make that page_offset is set to
>first skb data

I'm having trouble grasping how this is possible. More than one user
implies that it wont be reused. If this is possible, the
recounting/reuse mechanism is broken, and that is what should be
fixed.

The AF_XDP redirect should not have semantics different from, say,
devmap redirect. It's just that the page_frag_free() is called earlier
for AF_XDP, instead of from i40e_clean_tx_irq() as the case for
devmap/XDP_TX.

> 4. then reuse rx buffer, first skb which still is living
>will be corrupted.
>
>
> The root cause is difference you said upper, so I only fixes for 
non-zerocopy AF_XDP

>

I have only addressed non-zerocopy, so we're on the same page (pun
intended) here!


Björn

> -Li


[PATCH 01/28] mm: turn alloc_pages into an inline function

2020-08-19 Thread Christoph Hellwig
To prevent a compiler error when a method call alloc_pages is
added (which I plan to for the dma_map_ops).

Signed-off-by: Christoph Hellwig 
---
 include/linux/gfp.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 67a0774e080b98..dd2577c5407112 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -550,8 +550,10 @@ extern struct page *alloc_pages_vma(gfp_t gfp_mask, int 
order,
 #define alloc_hugepage_vma(gfp_mask, vma, addr, order) \
alloc_pages_vma(gfp_mask, order, vma, addr, numa_node_id(), true)
 #else
-#define alloc_pages(gfp_mask, order) \
-   alloc_pages_node(numa_node_id(), gfp_mask, order)
+static inline struct page *alloc_pages(gfp_t gfp_mask, unsigned int order)
+{
+   return alloc_pages_node(numa_node_id(), gfp_mask, order);
+}
 #define alloc_pages_vma(gfp_mask, order, vma, addr, node, false)\
alloc_pages(gfp_mask, order)
 #define alloc_hugepage_vma(gfp_mask, vma, addr, order) \
-- 
2.28.0



[PATCH] mwifiex: Clean up some err and dbg messages

2020-08-19 Thread Christophe JAILLET
The error message if 'pci_set_consistent_dma_mask()' fails is misleading.
The function call uses 32 bits, but the error message reports 64.

Moreover, according to the comment above 'dma_set_mask_and_coherent()'
definition, such an error can never happen.

So, simplify code, axe the misleading message and use
'dma_set_mask_and_coherent()' instead of 'dma_set_mask()' +
'dma_set_coherent_mask()'

While at it, make some clean-up:
   - add # when reporting allocated length to be consistent between
 functions
   - s/consistent/coherent/
   - s/unsigned int/u32/ to be consistent between functions
   - align some code

Signed-off-by: Christophe JAILLET 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 25 +
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 94fe121bc45f..cc6289aaf6c0 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -850,13 +850,14 @@ static int mwifiex_pcie_create_txbd_ring(struct 
mwifiex_adapter *adapter)
   GFP_KERNEL);
if (!card->txbd_ring_vbase) {
mwifiex_dbg(adapter, ERROR,
-   "allocate consistent memory (%d bytes) failed!\n",
+   "allocate coherent memory (%d bytes) failed!\n",
card->txbd_ring_size);
return -ENOMEM;
}
+
mwifiex_dbg(adapter, DATA,
-   "info: txbd_ring - base: %p, pbase: %#x:%x, len: %x\n",
-   card->txbd_ring_vbase, (unsigned int)card->txbd_ring_pbase,
+   "info: txbd_ring - base: %p, pbase: %#x:%x, len: %#x\n",
+   card->txbd_ring_vbase, (u32)card->txbd_ring_pbase,
(u32)((u64)card->txbd_ring_pbase >> 32),
card->txbd_ring_size);
 
@@ -915,7 +916,7 @@ static int mwifiex_pcie_create_rxbd_ring(struct 
mwifiex_adapter *adapter)
   GFP_KERNEL);
if (!card->rxbd_ring_vbase) {
mwifiex_dbg(adapter, ERROR,
-   "allocate consistent memory (%d bytes) failed!\n",
+   "allocate coherent memory (%d bytes) failed!\n",
card->rxbd_ring_size);
return -ENOMEM;
}
@@ -973,14 +974,14 @@ static int mwifiex_pcie_create_evtbd_ring(struct 
mwifiex_adapter *adapter)
 
mwifiex_dbg(adapter, INFO,
"info: evtbd_ring: Allocating %d bytes\n",
-   card->evtbd_ring_size);
+   card->evtbd_ring_size);
card->evtbd_ring_vbase = dma_alloc_coherent(&card->dev->dev,
card->evtbd_ring_size,
&card->evtbd_ring_pbase,
GFP_KERNEL);
if (!card->evtbd_ring_vbase) {
mwifiex_dbg(adapter, ERROR,
-   "allocate consistent memory (%d bytes) failed!\n",
+   "allocate coherent memory (%d bytes) failed!\n",
card->evtbd_ring_size);
return -ENOMEM;
}
@@ -1086,7 +1087,7 @@ static int mwifiex_pcie_alloc_sleep_cookie_buf(struct 
mwifiex_adapter *adapter)
  GFP_KERNEL);
if (!card->sleep_cookie_vbase) {
mwifiex_dbg(adapter, ERROR,
-   "pci_alloc_consistent failed!\n");
+   "dma_alloc_coherent failed!\n");
return -ENOMEM;
}
/* Init val of Sleep Cookie */
@@ -2928,15 +2929,9 @@ static int mwifiex_init_pcie(struct mwifiex_adapter 
*adapter)
 
pci_set_master(pdev);
 
-   ret = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
-   if (ret) {
-   pr_err("set_dma_mask(32) failed: %d\n", ret);
-   goto err_set_dma_mask;
-   }
-
-   ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+   ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (ret) {
-   pr_err("set_consistent_dma_mask(64) failed\n");
+   pr_err("dma_set_mask(32) failed: %d\n", ret);
goto err_set_dma_mask;
}
 
-- 
2.25.1



[PATCH 03/28] wireless: rsi_91x_core: File header should not be kernel-doc

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/rsi/rsi_91x_core.c:23: warning: Incorrect use of 
kernel-doc format:  * rsi_determine_min_weight_queue() - This function 
determines the queue with
 drivers/net/wireless/rsi/rsi_91x_core.c:30: warning: Function parameter or 
member 'common' not described in 'rsi_determine_min_weight_queue'

Cc: Amitkumar Karwar 
Cc: Siva Rebbagondla 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/rsi/rsi_91x_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c 
b/drivers/net/wireless/rsi/rsi_91x_core.c
index 3644d7d994638..2d49c5b5eefb4 100644
--- a/drivers/net/wireless/rsi/rsi_91x_core.c
+++ b/drivers/net/wireless/rsi/rsi_91x_core.c
@@ -1,4 +1,4 @@
-/**
+/*
  * Copyright (c) 2014 Redpine Signals Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
-- 
2.25.1



[PATCH 00/28] Rid W=1 warnings in Wireless

2020-08-19 Thread Lee Jones
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.

There are quite a few W=1 warnings in the Wireless.  My plan
is to work through all of them over the next few weeks.
Hopefully it won't be too long before drivers/net/wireless
builds clean with W=1 enabled.

This set brings the total number of (arm, arm64, x86, mips and
ppc *combined* i.e. some duplicated) warnings down from 6154
to 4983.

Lee Jones (28):
  wireless: intersil: hostap: Mark 'freq_list' as __maybe_unused
  wireless: rsi_91x_main: Fix some kernel-doc issues
  wireless: rsi_91x_core: File header should not be kernel-doc
  wireless: marvell: libertas_tf: Demote non-conformant kernel-doc
headers
  wireless: intel: dvm: Demote non-compliant kernel-doc headers
  wireless: ti: wlcore: cmd: Fix some parameter description disparities
  wireless: marvell: libertas_tf: Fix a bunch of function doc formatting
issues
  wireless: intel: iwlwifi: rs: Demote non-compliant kernel-doc headers
  wireless: intel: iwlegacy: debug: Demote seemingly unintentional
kerneldoc header
  wireless: intel: iwlwifi: dvm: tx: Demote non-compliant kernel-doc
headers
  wireless: intersil: hostap: hostap_ap: Mark 'txt' as __always_unused
  wireless: intel: iwlwifi: dvm: lib: Demote non-compliant kernel-doc
headers
  wireless: st: cw1200: wsm: Remove 'dummy' variables
  wireless: marvell: libertas: Fix 'timer_list' stored private data
related dot-rot
  wireless: mediatek: mt7601u: phy: Fix misnaming when documented
function parameter 'dac'
  wireless: marvell: mwifiex: init: Move 'tos_to_tid_inv' to where it's
used
  wireless: rsi: rsi_91x_main: Fix misnamed function parameter 'rx_pkt'
  wireless: rsi: rsi_91x_mac80211: Fix a few kerneldoc misdemeanours
  wireless: intel: iwlwifi: calib: Demote seemingly unintentional
kerneldoc header
  wireless: rsi: rsi_91x_mgmt: Fix a myriad of documentation issues
  wireless: ath: wil6210: debugfs: Fix a couple of formatting issues in
'wil6210_debugfs_init'
  wireless: intel: iwlwifi: dvm: sta: Demote a bunch of nonconformant
kernel-doc headers
  wireless: rsi: rsi_91x_hal: File header comments should not be
kernel-doc
  wireless: intel: iwlegacy: 4965: Demote a bunch of nonconformant
kernel-doc headers
  wireless: broadcom: brcmfmac: p2p: Deal with set but unused variables
  wireless: marvell: libertas: firmware: Fix misnaming for function
param 'device'
  wireless: marvell: libertas_tf: if_usb: Fix function documentation
formatting errors
  wireless: intersil: hostap_ioctl: Remove set but unused variable
'hostscan'

 drivers/net/wireless/ath/wil6210/debugfs.c|  8 ++--
 .../broadcom/brcm80211/brcmfmac/p2p.c |  6 +--
 drivers/net/wireless/intel/iwlegacy/4965.c| 25 ++---
 drivers/net/wireless/intel/iwlegacy/debug.c   |  3 +-
 .../net/wireless/intel/iwlwifi/dvm/calib.c|  2 +-
 drivers/net/wireless/intel/iwlwifi/dvm/lib.c  |  4 +-
 drivers/net/wireless/intel/iwlwifi/dvm/main.c | 11 +++---
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c   | 12 +++---
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c  | 22 +--
 drivers/net/wireless/intel/iwlwifi/dvm/tx.c   |  4 +-
 drivers/net/wireless/intersil/hostap/hostap.h |  6 ++-
 .../net/wireless/intersil/hostap/hostap_ap.c  |  2 +-
 .../wireless/intersil/hostap/hostap_ioctl.c   |  3 +-
 .../net/wireless/marvell/libertas/firmware.c  |  4 +-
 drivers/net/wireless/marvell/libertas/main.c  |  6 +--
 .../net/wireless/marvell/libertas_tf/cmd.c| 22 +--
 .../net/wireless/marvell/libertas_tf/if_usb.c | 37 ++-
 .../net/wireless/marvell/libertas_tf/main.c   |  6 +--
 drivers/net/wireless/marvell/mwifiex/init.c   | 16 
 drivers/net/wireless/marvell/mwifiex/tdls.c   | 16 
 drivers/net/wireless/marvell/mwifiex/wmm.h| 15 
 drivers/net/wireless/mediatek/mt7601u/phy.c   |  2 +-
 drivers/net/wireless/rsi/rsi_91x_core.c   |  2 +-
 drivers/net/wireless/rsi/rsi_91x_hal.c|  2 +-
 drivers/net/wireless/rsi/rsi_91x_mac80211.c   |  9 +++--
 drivers/net/wireless/rsi/rsi_91x_main.c   |  5 ++-
 drivers/net/wireless/rsi/rsi_91x_mgmt.c   | 30 ++-
 drivers/net/wireless/st/cw1200/wsm.c  |  6 +--
 drivers/net/wireless/ti/wlcore/cmd.c  |  5 ++-
 29 files changed, 157 insertions(+), 134 deletions(-)

-- 
2.25.1



[PATCH 14/28] wireless: marvell: libertas: Fix 'timer_list' stored private data related dot-rot

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/marvell/libertas/main.c:727: warning: Function parameter 
or member 't' not described in 'lbs_cmd_timeout_handler'
 drivers/net/wireless/marvell/libertas/main.c:727: warning: Excess function 
parameter 'data' description in 'lbs_cmd_timeout_handler'
 drivers/net/wireless/marvell/libertas/main.c:761: warning: Function parameter 
or member 't' not described in 'lbs_tx_lockup_handler'
 drivers/net/wireless/marvell/libertas/main.c:761: warning: Excess function 
parameter 'data' description in 'lbs_tx_lockup_handler'
 drivers/net/wireless/marvell/libertas/main.c:784: warning: Function parameter 
or member 't' not described in 'auto_deepsleep_timer_fn'
 drivers/net/wireless/marvell/libertas/main.c:784: warning: Excess function 
parameter 'data' description in 'auto_deepsleep_timer_fn'

Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: libertas-...@lists.infradead.org
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/marvell/libertas/main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas/main.c 
b/drivers/net/wireless/marvell/libertas/main.c
index 2233b59cdf444..ee4cf3437e28a 100644
--- a/drivers/net/wireless/marvell/libertas/main.c
+++ b/drivers/net/wireless/marvell/libertas/main.c
@@ -721,7 +721,7 @@ EXPORT_SYMBOL_GPL(lbs_resume);
  * lbs_cmd_timeout_handler - handles the timeout of command sending.
  * It will re-send the same command again.
  *
- * @data: &struct lbs_private pointer
+ * @t: Context from which to retrieve a &struct lbs_private pointer
  */
 static void lbs_cmd_timeout_handler(struct timer_list *t)
 {
@@ -755,7 +755,7 @@ static void lbs_cmd_timeout_handler(struct timer_list *t)
  * to the hardware. This is known to frequently happen with SD8686 when
  * waking up after a Wake-on-WLAN-triggered resume.
  *
- * @data: &struct lbs_private pointer
+ * @t: Context from which to retrieve a &struct lbs_private pointer
  */
 static void lbs_tx_lockup_handler(struct timer_list *t)
 {
@@ -777,7 +777,7 @@ static void lbs_tx_lockup_handler(struct timer_list *t)
 /**
  * auto_deepsleep_timer_fn - put the device back to deep sleep mode when
  * timer expires and no activity (command, event, data etc.) is detected.
- * @data:  &struct lbs_private pointer
+ * @t: Context from which to retrieve a &struct lbs_private pointer
  * returns:N/A
  */
 static void auto_deepsleep_timer_fn(struct timer_list *t)
-- 
2.25.1



[PATCH 13/28] wireless: st: cw1200: wsm: Remove 'dummy' variables

2020-08-19 Thread Lee Jones
They're never read, so there is no reason for them to exist.

They just cause the compiler to complain.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/st/cw1200/wsm.c: In function ‘wsm_ba_timeout_indication’:
 drivers/net/wireless/st/cw1200/wsm.c:1033:5: warning: variable ‘dummy2’ set 
but not used [-Wunused-but-set-variable]
 drivers/net/wireless/st/cw1200/wsm.c:1031:6: warning: variable ‘dummy’ set but 
not used [-Wunused-but-set-variable]

Cc: Solomon Peachy 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Dmitry Tarnyagin 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/st/cw1200/wsm.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/st/cw1200/wsm.c 
b/drivers/net/wireless/st/cw1200/wsm.c
index c86f31dcc9817..d9b6147bbb528 100644
--- a/drivers/net/wireless/st/cw1200/wsm.c
+++ b/drivers/net/wireless/st/cw1200/wsm.c
@@ -1028,14 +1028,12 @@ static int wsm_find_complete_indication(struct 
cw1200_common *priv,
 static int wsm_ba_timeout_indication(struct cw1200_common *priv,
 struct wsm_buf *buf)
 {
-   u32 dummy;
u8 tid;
-   u8 dummy2;
u8 addr[ETH_ALEN];
 
-   dummy = WSM_GET32(buf);
+   WSM_GET32(buf);
tid = WSM_GET8(buf);
-   dummy2 = WSM_GET8(buf);
+   WSM_GET8(buf);
WSM_GET(buf, addr, ETH_ALEN);
 
pr_info("BlockACK timeout, tid %d, addr %pM\n",
-- 
2.25.1



[PATCH 11/28] wireless: intersil: hostap: hostap_ap: Mark 'txt' as __always_unused

2020-08-19 Thread Lee Jones
Keeping this around to act as documentation, since its use is
currently #if'ed out at the end of the function.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intersil/hostap/hostap_ap.c: In function ‘handle_assoc’:
 drivers/net/wireless/intersil/hostap/hostap_ap.c:1507:8: warning: variable 
‘txt’ set but not used [-Wunused-but-set-variable]

Cc: Jouni Malinen 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Nathan Chancellor 
Cc: Nick Desaulniers 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intersil/hostap/hostap_ap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ap.c 
b/drivers/net/wireless/intersil/hostap/hostap_ap.c
index 3ec46f48cfde1..8bcc1cdcb75b0 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ap.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ap.c
@@ -1504,7 +1504,7 @@ static void handle_assoc(local_info_t *local, struct 
sk_buff *skb,
u16 resp = WLAN_STATUS_SUCCESS;
struct sta_info *sta = NULL;
int send_deauth = 0;
-   char *txt = "";
+   char __always_unused *txt = "";
u8 prev_ap[ETH_ALEN];
 
left = len = skb->len - IEEE80211_MGMT_HDR_LEN;
-- 
2.25.1



[PATCH 06/28] wireless: ti: wlcore: cmd: Fix some parameter description disparities

2020-08-19 Thread Lee Jones
Firstly a rename, then a split (there are 2 'len's that need documenting).

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/ti/wlcore/cmd.c:832: warning: Function parameter or 
member 'buf_len' not described in 'wl1271_cmd_test'
 drivers/net/wireless/ti/wlcore/cmd.c:832: warning: Excess function parameter 
'len' description in 'wl1271_cmd_test'
 drivers/net/wireless/ti/wlcore/cmd.c:862: warning: Function parameter or 
member 'cmd_len' not described in 'wl1271_cmd_interrogate'
 drivers/net/wireless/ti/wlcore/cmd.c:862: warning: Function parameter or 
member 'res_len' not described in 'wl1271_cmd_interrogate'
 drivers/net/wireless/ti/wlcore/cmd.c:862: warning: Excess function parameter 
'len' description in 'wl1271_cmd_interrogate'

Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Hari Nagalla 
Cc: Guy Mishol 
Cc: Maital Hahn 
Cc: Luciano Coelho 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/ti/wlcore/cmd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/cmd.c 
b/drivers/net/wireless/ti/wlcore/cmd.c
index 6ef8fc9ae6271..745101633a3f1 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -825,7 +825,7 @@ int wl12xx_cmd_role_start_ibss(struct wl1271 *wl, struct 
wl12xx_vif *wlvif)
  *
  * @wl: wl struct
  * @buf: buffer containing the command, with all headers, must work with dma
- * @len: length of the buffer
+ * @buf_len: length of the buffer
  * @answer: is answer needed
  */
 int wl1271_cmd_test(struct wl1271 *wl, void *buf, size_t buf_len, u8 answer)
@@ -855,7 +855,8 @@ EXPORT_SYMBOL_GPL(wl1271_cmd_test);
  * @wl: wl struct
  * @id: acx id
  * @buf: buffer for the response, including all headers, must work with dma
- * @len: length of buf
+ * @cmd_len: length of command
+ * @res_len: length of payload
  */
 int wl1271_cmd_interrogate(struct wl1271 *wl, u16 id, void *buf,
   size_t cmd_len, size_t res_len)
-- 
2.25.1



[PATCH 07/28] wireless: marvell: libertas_tf: Fix a bunch of function doc formatting issues

2020-08-19 Thread Lee Jones
Kerneldoc expects attributes/parameters to be in '@*.: ' format and
gets confused if the variable does not follow the type/attribute
definitions.

Also demote one stray non-kernel-doc header.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/marvell/libertas_tf/cmd.c:44: warning: Function parameter 
or member 'priv' not described in 'lbtf_cmd_copyback'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:44: warning: Function parameter 
or member 'extra' not described in 'lbtf_cmd_copyback'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:44: warning: Function parameter 
or member 'resp' not described in 'lbtf_cmd_copyback'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:80: warning: Function parameter 
or member 'priv' not described in 'lbtf_update_hw_spec'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:150: warning: Function 
parameter or member 'priv' not described in 'lbtf_set_channel'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:150: warning: Function 
parameter or member 'channel' not described in 'lbtf_set_channel'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:277: warning: Function 
parameter or member 'priv' not described in '__lbtf_cleanup_and_insert_cmd'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:277: warning: Function 
parameter or member 'cmdnode' not described in '__lbtf_cleanup_and_insert_cmd'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:442: warning: Function 
parameter or member 'priv' not described in 'lbtf_allocate_cmd_buffer'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:490: warning: Function 
parameter or member 'priv' not described in 'lbtf_free_cmd_buffer'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:527: warning: Function 
parameter or member 'priv' not described in 'lbtf_get_cmd_ctrl_node'
 drivers/net/wireless/marvell/libertas_tf/cmd.c:561: warning: Function 
parameter or member 'priv' not described in 'lbtf_execute_next_command'

Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 .../net/wireless/marvell/libertas_tf/cmd.c| 22 +--
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas_tf/cmd.c 
b/drivers/net/wireless/marvell/libertas_tf/cmd.c
index a0b4c9debc11f..efb98304555ad 100644
--- a/drivers/net/wireless/marvell/libertas_tf/cmd.c
+++ b/drivers/net/wireless/marvell/libertas_tf/cmd.c
@@ -32,10 +32,10 @@ static struct cmd_ctrl_node *lbtf_get_cmd_ctrl_node(struct 
lbtf_private *priv);
 /**
  *  lbtf_cmd_copyback - Simple callback that copies response back into command
  *
- *  @priv  A pointer to struct lbtf_private structure
- *  @extra A pointer to the original command structure for which
+ *  @priv: A pointer to struct lbtf_private structure
+ *  @extra:A pointer to the original command structure for which
  * 'resp' is a response
- *  @resp  A pointer to the command response
+ *  @resp: A pointer to the command response
  *
  *  Returns: 0 on success, error on failure
  */
@@ -72,7 +72,7 @@ static void lbtf_geo_init(struct lbtf_private *priv)
 /**
  *  lbtf_update_hw_spec: Updates the hardware details.
  *
- *  @priv  A pointer to struct lbtf_private structure
+ *  @priv: A pointer to struct lbtf_private structure
  *
  *  Returns: 0 on success, error on failure
  */
@@ -141,8 +141,8 @@ int lbtf_update_hw_spec(struct lbtf_private *priv)
 /**
  *  lbtf_set_channel: Set the radio channel
  *
- *  @priv  A pointer to struct lbtf_private structure
- *  @channel   The desired channel, or 0 to clear a locked channel
+ *  @priv: A pointer to struct lbtf_private structure
+ *  @channel:  The desired channel, or 0 to clear a locked channel
  *
  *  Returns: 0 on success, error on failure
  */
@@ -268,7 +268,7 @@ static void lbtf_submit_command(struct lbtf_private *priv,
lbtf_deb_leave(LBTF_DEB_HOST);
 }
 
-/**
+/*
  *  This function inserts command node to cmdfreeq
  *  after cleans it. Requires priv->driver_lock held.
  */
@@ -434,7 +434,7 @@ void lbtf_set_mac_control(struct lbtf_private *priv)
 /**
  *  lbtf_allocate_cmd_buffer - Allocates cmd buffer, links it to free cmd queue
  *
- *  @priv  A pointer to struct lbtf_private structure
+ *  @priv: A pointer to struct lbtf_private structure
  *
  *  Returns: 0 on success.
  */
@@ -482,7 +482,7 @@ int lbtf_allocate_cmd_buffer(struct lbtf_private *priv)
 /**
  *  lbtf_free_cmd_buffer - Frees the cmd buffer.
  *
- *  @priv  A pointer to struct lbtf_private structure
+ *  @priv: A pointer to struct lbtf_private structure
  *
  *  Returns: 0
  */
@@ -519,7 +519,7 @@ int lbtf_free_cmd_buffer(struct lbtf_private *priv)
 /**
  *  lbtf_get_cmd_ctrl_node - Gets free cmd node from free cmd queue.
  *
- *  @priv  A pointer to struct lbtf_private structure
+ *  @priv: A pointer to struct lbtf_private structure
  *
  *  Returns: pointer to a stru

[PATCH 12/28] wireless: intel: iwlwifi: dvm: lib: Demote non-compliant kernel-doc headers

2020-08-19 Thread Lee Jones
Neither of these headers attempt to document any function parameters.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intel/iwlwifi/dvm/lib.c:121: warning: Function parameter 
or member 'priv' not described in 'iwlagn_txfifo_flush'
 drivers/net/wireless/intel/iwlwifi/dvm/lib.c:121: warning: Function parameter 
or member 'scd_q_msk' not described in 'iwlagn_txfifo_flush'
 drivers/net/wireless/intel/iwlwifi/dvm/lib.c:779: warning: Function parameter 
or member 'priv' not described in 'iwlagn_set_rxon_chain'
 drivers/net/wireless/intel/iwlwifi/dvm/lib.c:779: warning: Function parameter 
or member 'ctx' not described in 'iwlagn_set_rxon_chain'

Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intel/iwlwifi/dvm/lib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/lib.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/lib.c
index eab94d2f46b1e..3b937a7dd4032 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/lib.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/lib.c
@@ -110,7 +110,7 @@ int iwlagn_manage_ibss_station(struct iwl_priv *priv,
  vif->bss_conf.bssid);
 }
 
-/**
+/*
  * iwlagn_txfifo_flush: send REPLY_TXFIFO_FLUSH command to uCode
  *
  * pre-requirements:
@@ -769,7 +769,7 @@ static u8 iwl_count_chain_bitmap(u32 chain_bitmap)
return res;
 }
 
-/**
+/*
  * iwlagn_set_rxon_chain - Set up Rx chain usage in "staging" RXON image
  *
  * Selects how many and which Rx receivers/antennas/chains to use.
-- 
2.25.1



[PATCH 15/28] wireless: mediatek: mt7601u: phy: Fix misnaming when documented function parameter 'dac'

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/mediatek/mt7601u/phy.c:1216: warning: Function parameter 
or member 'dac' not described in 'mt7601u_set_tx_dac'
 drivers/net/wireless/mediatek/mt7601u/phy.c:1216: warning: Excess function 
parameter 'path' description in 'mt7601u_set_tx_dac'

Cc: Jakub Kicinski 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Matthias Brugger 
Cc: Felix Fietkau 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/mediatek/mt7601u/phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt7601u/phy.c 
b/drivers/net/wireless/mediatek/mt7601u/phy.c
index d863ab4a66c96..3c4462487ab5c 100644
--- a/drivers/net/wireless/mediatek/mt7601u/phy.c
+++ b/drivers/net/wireless/mediatek/mt7601u/phy.c
@@ -1210,7 +1210,7 @@ void mt7601u_set_rx_path(struct mt7601u_dev *dev, u8 path)
 /**
  * mt7601u_set_tx_dac - set which tx DAC to use
  * @dev:   pointer to adapter structure
- * @path:  DAC index, values are 0-based
+ * @dac:   DAC index, values are 0-based
  */
 void mt7601u_set_tx_dac(struct mt7601u_dev *dev, u8 dac)
 {
-- 
2.25.1



[PATCH 27/28] wireless: marvell: libertas_tf: if_usb: Fix function documentation formatting errors

2020-08-19 Thread Lee Jones
Kerneldoc expects attributes/parameters to be in '@*.: ' format and
gets confused if the variable does not follow the type/attribute
definitions.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/marvell/libertas_tf/if_usb.c:56: warning: Function 
parameter or member 'urb' not described in 'if_usb_write_bulk_callback'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:73: warning: Function 
parameter or member 'cardp' not described in 'if_usb_free'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:146: warning: Function 
parameter or member 'intf' not described in 'if_usb_probe'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:146: warning: Function 
parameter or member 'id' not described in 'if_usb_probe'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:244: warning: Function 
parameter or member 'intf' not described in 'if_usb_disconnect'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:272: warning: Function 
parameter or member 'cardp' not described in 'if_usb_send_fw_pkt'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:372: warning: Function 
parameter or member 'cardp' not described in 'usb_tx_block'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:372: warning: Function 
parameter or member 'payload' not described in 'usb_tx_block'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:372: warning: Function 
parameter or member 'nb' not described in 'usb_tx_block'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:372: warning: Function 
parameter or member 'data' not described in 'usb_tx_block'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:625: warning: Function 
parameter or member 'urb' not described in 'if_usb_receive'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:714: warning: Function 
parameter or member 'priv' not described in 'if_usb_host_to_card'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:714: warning: Function 
parameter or member 'type' not described in 'if_usb_host_to_card'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:714: warning: Function 
parameter or member 'payload' not described in 'if_usb_host_to_card'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:714: warning: Function 
parameter or member 'nb' not described in 'if_usb_host_to_card'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:742: warning: Function 
parameter or member 'cardp' not described in 'if_usb_issue_boot_command'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:742: warning: Function 
parameter or member 'ivalue' not described in 'if_usb_issue_boot_command'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:766: warning: Function 
parameter or member 'data' not described in 'check_fwfile_format'
 drivers/net/wireless/marvell/libertas_tf/if_usb.c:766: warning: Function 
parameter or member 'totlen' not described in 'check_fwfile_format'

Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Colin Ian King 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 .../net/wireless/marvell/libertas_tf/if_usb.c | 37 ++-
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c 
b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
index bedc092150884..a92916dc81a96 100644
--- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
@@ -50,7 +50,7 @@ static int if_usb_reset_device(struct lbtf_private *priv);
 /**
  *  if_usb_wrike_bulk_callback -  call back to handle URB status
  *
- *  @param urb pointer to urb structure
+ *  @urb:  pointer to urb structure
  */
 static void if_usb_write_bulk_callback(struct urb *urb)
 {
@@ -67,7 +67,7 @@ static void if_usb_write_bulk_callback(struct urb *urb)
 /**
  *  if_usb_free - free tx/rx urb, skb and rx buffer
  *
- *  @param cardp   pointer if_usb_card
+ *  @cardp:pointer if_usb_card
  */
 static void if_usb_free(struct if_usb_card *cardp)
 {
@@ -136,8 +136,8 @@ static const struct lbtf_ops if_usb_ops = {
 /**
  *  if_usb_probe - sets the configuration values
  *
- *  @ifnum interface number
- *  @idpointer to usb_device_id
+ *  @intf: USB interface structure
+ *  @id:   pointer to usb_device_id
  *
  *  Returns: 0 on success, error code on failure
  */
@@ -238,7 +238,7 @@ lbtf_deb_leave(LBTF_DEB_MAIN);
 /**
  *  if_usb_disconnect -  free resource and cleanup
  *
- *  @intf  USB interface structure
+ *  @intf: USB interface structure
  */
 static void if_usb_disconnect(struct usb_interface *intf)
 {
@@ -264,7 +264,7 @@ static void if_usb_disconnect(struct usb_interface *intf)
 /**
  *  if_usb_send_fw_pkt -  This function downloads the FW
  *
- *  @priv  pointer to struct lbtf_private
+ *  @cardp:pointer if_usb_card
  *
  *  Returns: 0
  */
@@ -360,10 +360,10 @@ static int if_usb_reset_device(struct lbtf_private *priv)
 /**
  *  usb_tx_block - transfer data to the device
  *
- *  @p

[PATCH 19/28] wireless: intel: iwlwifi: calib: Demote seemingly unintentional kerneldoc header

2020-08-19 Thread Lee Jones
This is the only use of kerneldoc in the sourcefile and no
descriptions are provided.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intel/iwlwifi/dvm/calib.c:770: warning: Function 
parameter or member 'priv' not described in 'iwl_find_disconn_antenna'
 drivers/net/wireless/intel/iwlwifi/dvm/calib.c:770: warning: Function 
parameter or member 'average_sig' not described in 'iwl_find_disconn_antenna'
 drivers/net/wireless/intel/iwlwifi/dvm/calib.c:770: warning: Function 
parameter or member 'data' not described in 'iwl_find_disconn_antenna'

Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intel/iwlwifi/dvm/calib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
index 588b15697710d..974e1c324ca7c 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
@@ -761,7 +761,7 @@ static inline u8 find_first_chain(u8 mask)
return CHAIN_C;
 }
 
-/**
+/*
  * Run disconnected antenna algorithm to find out which antennas are
  * disconnected.
  */
-- 
2.25.1



[PATCH 23/28] wireless: rsi: rsi_91x_hal: File header comments should not be kernel-doc

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/rsi/rsi_91x_hal.c:25: warning: cannot understand function 
prototype: 'struct ta_metadata metadata_flash_content[] = '

Cc: Amitkumar Karwar 
Cc: Siva Rebbagondla 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/rsi/rsi_91x_hal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c 
b/drivers/net/wireless/rsi/rsi_91x_hal.c
index 6f8d5f9a9f7e6..3f7e3cfb6f00d 100644
--- a/drivers/net/wireless/rsi/rsi_91x_hal.c
+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
@@ -1,4 +1,4 @@
-/**
+/*
  * Copyright (c) 2014 Redpine Signals Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
-- 
2.25.1



[PATCH 20/28] wireless: rsi: rsi_91x_mgmt: Fix a myriad of documentation issues

2020-08-19 Thread Lee Jones
Too many, not enough, misnamed and formatting problems, all resolved.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/rsi/rsi_91x_mgmt.c:24: warning: cannot understand 
function prototype: 'struct bootup_params boot_params_20 = '
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:487: warning: Excess function 
parameter 'type' description in 'rsi_mgmt_pkt_to_core'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:538: warning: Function parameter or 
member 'sta_id' not described in 'rsi_hal_send_sta_notify_frame'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:538: warning: Function parameter or 
member 'vif' not described in 'rsi_hal_send_sta_notify_frame'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:615: warning: Function parameter or 
member 'sta_id' not described in 'rsi_send_aggregation_params_frame'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Function parameter or 
member 'mode' not described in 'rsi_set_vap_capabilities'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Function parameter or 
member 'mac_addr' not described in 'rsi_set_vap_capabilities'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Function parameter or 
member 'vap_id' not described in 'rsi_set_vap_capabilities'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Function parameter or 
member 'vap_status' not described in 'rsi_set_vap_capabilities'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:711: warning: Excess function 
parameter 'opmode' description in 'rsi_set_vap_capabilities'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:794: warning: Function parameter or 
member 'sta_id' not described in 'rsi_hal_load_key'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:794: warning: Function parameter or 
member 'vif' not described in 'rsi_hal_load_key'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1053: warning: Function parameter or 
member 'curchan' not described in 'rsi_band_check'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1173: warning: Excess function 
parameter 'channel' description in 'rsi_send_radio_params_update'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1299: warning: Function parameter or 
member 'sta' not described in 'rsi_send_auto_rate_request'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1299: warning: Function parameter or 
member 'sta_id' not described in 'rsi_send_auto_rate_request'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1299: warning: Function parameter or 
member 'vif' not described in 'rsi_send_auto_rate_request'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or 
member 'opmode' not described in 'rsi_inform_bss_status'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or 
member 'addr' not described in 'rsi_inform_bss_status'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or 
member 'sta' not described in 'rsi_inform_bss_status'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or 
member 'sta_id' not described in 'rsi_inform_bss_status'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or 
member 'assoc_cap' not described in 'rsi_inform_bss_status'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Function parameter or 
member 'vif' not described in 'rsi_inform_bss_status'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1459: warning: Excess function 
parameter 'bssid' description in 'rsi_inform_bss_status'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1543: warning: Function parameter or 
member 'common' not described in 'rsi_send_block_unblock_frame'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1543: warning: Function parameter or 
member 'block_event' not described in 'rsi_send_block_unblock_frame'
 drivers/net/wireless/rsi/rsi_91x_mgmt.c:1587: warning: Excess function 
parameter 'Return' description in 'rsi_send_rx_filter_frame'

Cc: Amitkumar Karwar 
Cc: Siva Rebbagondla 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/rsi/rsi_91x_mgmt.c | 30 +
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c 
b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 9cc8a335d519d..c331084bdc170 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -1,4 +1,4 @@
-/**
+/*
  * Copyright (c) 2014 Redpine Signals Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -477,7 +477,6 @@ static int rsi_load_radio_caps(struct rsi_common *common)
  * @common: Pointer to the driver private structure.
  * @msg: Pointer to received packet.
  * @msg_len: Length of the received packet.
- * @type: Type of received packet.
  *
  * Return: 0 on success, -1 on failure.
  */
@@ -528,6 +527,8 @@ static int rsi_mgmt_pkt_to_core(struct rsi_common *common,
  * @bssid: bssid.
  * @qos_enable: Qos is enabled.
  * @aid: Aid (unique for all STA).
+ * @sta_id: station i

[PATCH 28/28] wireless: intersil: hostap_ioctl: Remove set but unused variable 'hostscan'

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intersil/hostap/hostap_ioctl.c: In function 
‘prism2_translate_scan’:
 drivers/net/wireless/intersil/hostap/hostap_ioctl.c:1958:13: warning: variable 
‘hostscan’ set but not used [-Wunused-but-set-variable]

Cc: Jouni Malinen 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intersil/hostap/hostap_ioctl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c 
b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
index 1ca9731d9b14b..514c7b01dbf6f 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_ioctl.c
@@ -1955,7 +1955,7 @@ static inline int prism2_translate_scan(local_info_t 
*local,
char *buffer, int buflen)
 {
struct hfa384x_hostscan_result *scan;
-   int entry, hostscan;
+   int entry;
char *current_ev = buffer;
char *end_buf = buffer + buflen;
struct list_head *ptr;
@@ -1968,7 +1968,6 @@ static inline int prism2_translate_scan(local_info_t 
*local,
bss->included = 0;
}
 
-   hostscan = local->last_scan_type == PRISM2_HOSTSCAN;
for (entry = 0; entry < local->last_scan_results_count; entry++) {
int found = 0;
scan = &local->last_scan_results[entry];
-- 
2.25.1



[PATCH 24/28] wireless: intel: iwlegacy: 4965: Demote a bunch of nonconformant kernel-doc headers

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intel/iwlegacy/4965.c:35: warning: Function parameter or 
member 'il' not described in 'il4965_verify_inst_sparse'
 drivers/net/wireless/intel/iwlegacy/4965.c:35: warning: Function parameter or 
member 'image' not described in 'il4965_verify_inst_sparse'
 drivers/net/wireless/intel/iwlegacy/4965.c:35: warning: Function parameter or 
member 'len' not described in 'il4965_verify_inst_sparse'
 drivers/net/wireless/intel/iwlegacy/4965.c:66: warning: Function parameter or 
member 'il' not described in 'il4965_verify_inst_full'
 drivers/net/wireless/intel/iwlegacy/4965.c:66: warning: Function parameter or 
member 'image' not described in 'il4965_verify_inst_full'
 drivers/net/wireless/intel/iwlegacy/4965.c:66: warning: Function parameter or 
member 'len' not described in 'il4965_verify_inst_full'
 drivers/net/wireless/intel/iwlegacy/4965.c:105: warning: Function parameter or 
member 'il' not described in 'il4965_verify_ucode'
 drivers/net/wireless/intel/iwlegacy/4965.c:329: warning: Function parameter or 
member 'il' not described in 'il4965_load_bsm'
 drivers/net/wireless/intel/iwlegacy/4965.c:416: warning: Function parameter or 
member 'il' not described in 'il4965_set_ucode_ptrs'
 drivers/net/wireless/intel/iwlegacy/4965.c:451: warning: Function parameter or 
member 'il' not described in 'il4965_init_alive_start'
 drivers/net/wireless/intel/iwlegacy/4965.c:583: warning: Function parameter or 
member 'eeprom_voltage' not described in 'il4965_get_voltage_compensation'
 drivers/net/wireless/intel/iwlegacy/4965.c:583: warning: Function parameter or 
member 'current_voltage' not described in 'il4965_get_voltage_compensation'
 drivers/net/wireless/intel/iwlegacy/4965.c:668: warning: Function parameter or 
member 'il' not described in 'il4965_interpolate_chan'
 drivers/net/wireless/intel/iwlegacy/4965.c:668: warning: Function parameter or 
member 'channel' not described in 'il4965_interpolate_chan'
 drivers/net/wireless/intel/iwlegacy/4965.c:668: warning: Function parameter or 
member 'chan_info' not described in 'il4965_interpolate_chan'
 drivers/net/wireless/intel/iwlegacy/4965.c:1242: warning: Function parameter 
or member 'il' not described in 'il4965_send_tx_power'
 drivers/net/wireless/intel/iwlegacy/4965.c:1537: warning: Function parameter 
or member 'il' not described in 'il4965_txq_update_byte_cnt_tbl'
 drivers/net/wireless/intel/iwlegacy/4965.c:1537: warning: Function parameter 
or member 'txq' not described in 'il4965_txq_update_byte_cnt_tbl'
 drivers/net/wireless/intel/iwlegacy/4965.c:1537: warning: Function parameter 
or member 'byte_cnt' not described in 'il4965_txq_update_byte_cnt_tbl'
 drivers/net/wireless/intel/iwlegacy/4965.c:1564: warning: Function parameter 
or member 'il' not described in 'il4965_hw_get_temperature'
 drivers/net/wireless/intel/iwlegacy/4965.c:1564: warning: Excess function 
parameter 'stats' description in 'il4965_hw_get_temperature'
 drivers/net/wireless/intel/iwlegacy/4965.c:1633: warning: Function parameter 
or member 'il' not described in 'il4965_is_temp_calib_needed'

Cc: Stanislaw Gruszka 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Linux Wireless 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intel/iwlegacy/4965.c | 25 +++---
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/4965.c 
b/drivers/net/wireless/intel/iwlegacy/4965.c
index fc8fa5818de7e..9fa556486511c 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965.c
@@ -25,7 +25,7 @@
 #include "common.h"
 #include "4965.h"
 
-/**
+/*
  * il_verify_inst_sparse - verify runtime uCode image in card vs. host,
  *   using sample data 100 bytes apart.  If these sample points are good,
  *   it's a pretty good bet that everything between them is good, too.
@@ -57,7 +57,7 @@ il4965_verify_inst_sparse(struct il_priv *il, __le32 * image, 
u32 len)
return ret;
 }
 
-/**
+/*
  * il4965_verify_inst_full - verify runtime uCode image in card vs. host,
  * looking at all data.
  */
@@ -96,7 +96,7 @@ il4965_verify_inst_full(struct il_priv *il, __le32 * image, 
u32 len)
return ret;
 }
 
-/**
+/*
  * il4965_verify_ucode - determine which instruction image is in SRAM,
  *and verify its contents
  */
@@ -292,7 +292,7 @@ il4965_verify_bsm(struct il_priv *il)
return 0;
 }
 
-/**
+/*
  * il4965_load_bsm - Load bootstrap instructions
  *
  * BSM operation:
@@ -402,7 +402,7 @@ il4965_load_bsm(struct il_priv *il)
return 0;
 }
 
-/**
+/*
  * il4965_set_ucode_ptrs - Set uCode address location
  *
  * Tell initialization uCode where to find runtime uCode.
@@ -435,7 +435,7 @@ il4965_set_ucode_ptrs(struct il_priv *il)
return 0;
 }
 
-/**
+/*
  * il4965_init_alive_start - Called after N_ALIVE notification received
  *
  * Called after N_

[PATCH 26/28] wireless: marvell: libertas: firmware: Fix misnaming for function param 'device'

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/marvell/libertas/firmware.c:134: warning: Function 
parameter or member 'device' not described in 'lbs_get_firmware_async'
 drivers/net/wireless/marvell/libertas/firmware.c:134: warning: Excess function 
parameter 'dev' description in 'lbs_get_firmware_async'

Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: libertas-...@lists.infradead.org
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/marvell/libertas/firmware.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas/firmware.c 
b/drivers/net/wireless/marvell/libertas/firmware.c
index 69029c59a2726..f124110944b7e 100644
--- a/drivers/net/wireless/marvell/libertas/firmware.c
+++ b/drivers/net/wireless/marvell/libertas/firmware.c
@@ -121,12 +121,12 @@ void lbs_wait_for_firmware_load(struct lbs_private *priv)
  *  either a helper firmware and a main firmware (2-stage), or just the helper.
  *
  *  @priv:  Pointer to lbs_private instance
- *  @dev:  A pointer to &device structure
+ *  @device:   A pointer to &device structure
  *  @card_model: Bus-specific card model ID used to filter firmware table
  * elements
  *  @fw_table: Table of firmware file names and device model numbers
  * terminated by an entry with a NULL helper name
- * @callback: User callback to invoke when firmware load succeeds or fails.
+ *  @callback: User callback to invoke when firmware load succeeds or fails.
  */
 int lbs_get_firmware_async(struct lbs_private *priv, struct device *device,
u32 card_model, const struct lbs_fw_table *fw_table,
-- 
2.25.1



[PATCH 25/28] wireless: broadcom: brcmfmac: p2p: Deal with set but unused variables

2020-08-19 Thread Lee Jones
'vif' is a function parameter which is oddly overwritten within the
function, but never read back.  'timeout' is set, but never checked.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function 
‘brcmf_p2p_scan_prep’:
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:894:31: warning: 
parameter ‘vif’ set but not used [-Wunused-but-set-parameter]
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c: In function 
‘brcmf_p2p_tx_action_frame’:
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:1549:6: warning: 
variable ‘timeout’ set but not used [-Wunused-but-set-variable]

Cc: Arend van Spriel 
Cc: Franky Lin 
Cc: Hante Meuleman 
Cc: Chi-Hsien Lin 
Cc: Wright Feng 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: brcm80211-dev-list@broadcom.com
Cc: brcm80211-dev-l...@cypress.com
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index debd887e159e1..7f681a25ab525 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -913,8 +913,6 @@ int brcmf_p2p_scan_prep(struct wiphy *wiphy,
if (err)
return err;
 
-   vif = p2p->bss_idx[P2PAPI_BSSCFG_DEVICE].vif;
-
/* override .run_escan() callback. */
cfg->escan_info.run = brcmf_p2p_run_escan;
}
@@ -1546,7 +1544,6 @@ static s32 brcmf_p2p_tx_action_frame(struct 
brcmf_p2p_info *p2p,
struct brcmf_cfg80211_vif *vif;
struct brcmf_p2p_action_frame *p2p_af;
s32 err = 0;
-   s32 timeout = 0;
 
brcmf_dbg(TRACE, "Enter\n");
 
@@ -1582,8 +1579,7 @@ static s32 brcmf_p2p_tx_action_frame(struct 
brcmf_p2p_info *p2p,
  (p2p->wait_for_offchan_complete) ?
   "off-channel" : "on-channel");
 
-   timeout = wait_for_completion_timeout(&p2p->send_af_done,
- P2P_AF_MAX_WAIT_TIME);
+   wait_for_completion_timeout(&p2p->send_af_done, P2P_AF_MAX_WAIT_TIME);
 
if (test_bit(BRCMF_P2P_STATUS_ACTION_TX_COMPLETED, &p2p->status)) {
brcmf_dbg(TRACE, "TX action frame operation is success\n");
-- 
2.25.1



[PATCH 22/28] wireless: intel: iwlwifi: dvm: sta: Demote a bunch of nonconformant kernel-doc headers

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:244: warning: Function parameter 
or member 'priv' not described in 'iwl_prep_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:244: warning: Function parameter 
or member 'ctx' not described in 'iwl_prep_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:244: warning: Function parameter 
or member 'addr' not described in 'iwl_prep_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:244: warning: Function parameter 
or member 'is_ap' not described in 'iwl_prep_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:244: warning: Function parameter 
or member 'sta' not described in 'iwl_prep_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:332: warning: Function parameter 
or member 'priv' not described in 'iwl_add_station_common'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:332: warning: Function parameter 
or member 'ctx' not described in 'iwl_add_station_common'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:332: warning: Function parameter 
or member 'addr' not described in 'iwl_add_station_common'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:332: warning: Function parameter 
or member 'is_ap' not described in 'iwl_add_station_common'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:332: warning: Function parameter 
or member 'sta' not described in 'iwl_add_station_common'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:332: warning: Function parameter 
or member 'sta_id_r' not described in 'iwl_add_station_common'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:390: warning: Function parameter 
or member 'priv' not described in 'iwl_sta_ucode_deactivate'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:390: warning: Function parameter 
or member 'sta_id' not described in 'iwl_sta_ucode_deactivate'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:459: warning: Function parameter 
or member 'priv' not described in 'iwl_remove_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:459: warning: Function parameter 
or member 'sta_id' not described in 'iwl_remove_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:459: warning: Function parameter 
or member 'addr' not described in 'iwl_remove_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:614: warning: Function parameter 
or member 'priv' not described in 'iwl_clear_ucode_stations'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:614: warning: Function parameter 
or member 'ctx' not described in 'iwl_clear_ucode_stations'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:648: warning: Function parameter 
or member 'priv' not described in 'iwl_restore_stations'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:648: warning: Function parameter 
or member 'ctx' not described in 'iwl_restore_stations'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:790: warning: Function parameter 
or member 'priv' not described in 'is_lq_table_valid'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:790: warning: Function parameter 
or member 'ctx' not described in 'is_lq_table_valid'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:790: warning: Function parameter 
or member 'lq' not described in 'is_lq_table_valid'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:822: warning: Function parameter 
or member 'priv' not described in 'iwl_send_lq_cmd'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:822: warning: Function parameter 
or member 'ctx' not described in 'iwl_send_lq_cmd'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:822: warning: Function parameter 
or member 'lq' not described in 'iwl_send_lq_cmd'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:822: warning: Function parameter 
or member 'flags' not described in 'iwl_send_lq_cmd'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1270: warning: Function parameter 
or member 'priv' not described in 'iwlagn_alloc_bcast_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1270: warning: Function parameter 
or member 'ctx' not described in 'iwlagn_alloc_bcast_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1309: warning: Function parameter 
or member 'priv' not described in 'iwl_update_bcast_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1309: warning: Function parameter 
or member 'ctx' not described in 'iwl_update_bcast_station'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1348: warning: Function parameter 
or member 'priv' not described in 'iwl_sta_tx_modify_enable_tid'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1348: warning: Function parameter 
or member 'sta_id' not described in 'iwl_sta_tx_modify_enable_tid'
 drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1348: warning: Function parameter 
or member 'tid' not described in 'iwl_sta_tx_modify_enable_tid'

Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intel/iwlw

[PATCH 17/28] wireless: rsi: rsi_91x_main: Fix misnamed function parameter 'rx_pkt'

2020-08-19 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/rsi/rsi_91x_main.c:157: warning: Function parameter or 
member 'rx_pkt' not described in 'rsi_read_pkt'
 drivers/net/wireless/rsi/rsi_91x_main.c:157: warning: Excess function 
parameter 'rcv_pkt' description in 'rsi_read_pkt'

Cc: Amitkumar Karwar 
Cc: Siva Rebbagondla 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/rsi/rsi_91x_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c 
b/drivers/net/wireless/rsi/rsi_91x_main.c
index 576f51f9b4a7e..9a3d2439a8e7a 100644
--- a/drivers/net/wireless/rsi/rsi_91x_main.c
+++ b/drivers/net/wireless/rsi/rsi_91x_main.c
@@ -148,7 +148,7 @@ static struct sk_buff *rsi_prepare_skb(struct rsi_common 
*common,
 /**
  * rsi_read_pkt() - This function reads frames from the card.
  * @common: Pointer to the driver private structure.
- * @rcv_pkt: Received pkt.
+ * @rx_pkt: Received pkt.
  * @rcv_pkt_len: Received pkt length. In case of USB it is 0.
  *
  * Return: 0 on success, -1 on failure.
-- 
2.25.1



[PATCH 21/28] wireless: ath: wil6210: debugfs: Fix a couple of formatting issues in 'wil6210_debugfs_init'

2020-08-19 Thread Lee Jones
Kerneldoc expects attributes/parameters to be in '@*.: ' format and
gets confused if the variable does not follow the type/attribute
definitions.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/ath/wil6210/debugfs.c:456: warning: Function parameter or 
member 'wil' not described in 'wil6210_debugfs_init_offset'
 drivers/net/wireless/ath/wil6210/debugfs.c:456: warning: Function parameter or 
member 'dbg' not described in 'wil6210_debugfs_init_offset'
 drivers/net/wireless/ath/wil6210/debugfs.c:456: warning: Function parameter or 
member 'base' not described in 'wil6210_debugfs_init_offset'
 drivers/net/wireless/ath/wil6210/debugfs.c:456: warning: Function parameter or 
member 'tbl' not described in 'wil6210_debugfs_init_offset'

Cc: Maya Erez 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: wil6...@qti.qualcomm.com
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/ath/wil6210/debugfs.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c 
b/drivers/net/wireless/ath/wil6210/debugfs.c
index 11d0c79e90562..2d618f90afa7b 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -443,10 +443,10 @@ DEFINE_DEBUGFS_ATTRIBUTE(wil_fops_ulong, 
wil_debugfs_ulong_get,
 
 /**
  * wil6210_debugfs_init_offset - create set of debugfs files
- * @wil - driver's context, used for printing
- * @dbg - directory on the debugfs, where files will be created
- * @base - base address used in address calculation
- * @tbl - table with file descriptions. Should be terminated with empty 
element.
+ * @wil: driver's context, used for printing
+ * @dbg: directory on the debugfs, where files will be created
+ * @base: base address used in address calculation
+ * @tbl: table with file descriptions. Should be terminated with empty element.
  *
  * Creates files accordingly to the @tbl.
  */
-- 
2.25.1



[PATCH 10/28] wireless: intel: iwlwifi: dvm: tx: Demote non-compliant kernel-doc headers

2020-08-19 Thread Lee Jones
None of these headers attempt to document any function parameters.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intel/iwlwifi/dvm/tx.c:811: warning: Function parameter 
or member 'priv' not described in 'iwlagn_hwrate_to_tx_control'
 drivers/net/wireless/intel/iwlwifi/dvm/tx.c:811: warning: Function parameter 
or member 'rate_n_flags' not described in 'iwlagn_hwrate_to_tx_control'
 drivers/net/wireless/intel/iwlwifi/dvm/tx.c:811: warning: Function parameter 
or member 'info' not described in 'iwlagn_hwrate_to_tx_control'
 drivers/net/wireless/intel/iwlwifi/dvm/tx.c:1267: warning: Function parameter 
or member 'priv' not described in 'iwlagn_rx_reply_compressed_ba'
 drivers/net/wireless/intel/iwlwifi/dvm/tx.c:1267: warning: Function parameter 
or member 'rxb' not described in 'iwlagn_rx_reply_compressed_ba'

Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intel/iwlwifi/dvm/tx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
index fd454836adbed..e3962bb523289 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
@@ -803,7 +803,7 @@ static void iwlagn_non_agg_tx_status(struct iwl_priv *priv,
rcu_read_unlock();
 }
 
-/**
+/*
  * translate ucode response to mac80211 tx status control values
  */
 static void iwlagn_hwrate_to_tx_control(struct iwl_priv *priv, u32 
rate_n_flags,
@@ -1256,7 +1256,7 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv, struct 
iwl_rx_cmd_buffer *rxb)
}
 }
 
-/**
+/*
  * iwlagn_rx_reply_compressed_ba - Handler for REPLY_COMPRESSED_BA
  *
  * Handles block-acknowledge notification from device, which reports success
-- 
2.25.1



[PATCH 16/28] wireless: marvell: mwifiex: init: Move 'tos_to_tid_inv' to where it's used

2020-08-19 Thread Lee Jones
'tos_to_tid_inv' is only used in 2 of 17 files it's current being
included into.

Fixes the following W=1 kernel build warning(s):

 In file included from drivers/net/wireless/marvell/mwifiex/main.c:23:
 In file included from drivers/net/wireless/marvell/mwifiex/cmdevt.c:26:
 In file included from drivers/net/wireless/marvell/mwifiex/util.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/txrx.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/11n.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/wmm.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/11n_aggr.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/join.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/sta_cmd.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/sta_ioctl.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/sta_event.c:25:
 In file included from drivers/net/wireless/marvell/mwifiex/uap_txrx.c:23:
 In file included from drivers/net/wireless/marvell/mwifiex/sdio.c:27:
 In file included from drivers/net/wireless/marvell/mwifiex/sta_tx.c:25:
 drivers/net/wireless/marvell/mwifiex/wmm.h:41:17: warning: ‘tos_to_tid_inv’ 
defined but not used [-Wunused-const-variable=]
 41 | static const u8 tos_to_tid_inv[] = {

 NB: Snipped for brevity

Cc: Amitkumar Karwar 
Cc: Ganapathi Bhat 
Cc: Xinming Hu 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/marvell/mwifiex/init.c | 16 
 drivers/net/wireless/marvell/mwifiex/tdls.c | 16 
 drivers/net/wireless/marvell/mwifiex/wmm.h  | 15 ---
 3 files changed, 32 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index 82d69bc3aaaf4..7ffc78b258317 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -25,6 +25,22 @@
 #include "wmm.h"
 #include "11n.h"
 
+/*
+ * This table inverses the tos_to_tid operation to get a priority
+ * which is in sequential order, and can be compared.
+ * Use this to compare the priority of two different TIDs.
+ */
+static const u8 tos_to_tid_inv[] = {
+   0x02,  /* from tos_to_tid[2] = 0 */
+   0x00,  /* from tos_to_tid[0] = 1 */
+   0x01,  /* from tos_to_tid[1] = 2 */
+   0x03,
+   0x04,
+   0x05,
+   0x06,
+   0x07
+};
+
 /*
  * This function adds a BSS priority table to the table list.
  *
diff --git a/drivers/net/wireless/marvell/mwifiex/tdls.c 
b/drivers/net/wireless/marvell/mwifiex/tdls.c
index 97bb87c3676bb..35c02b149820d 100644
--- a/drivers/net/wireless/marvell/mwifiex/tdls.c
+++ b/drivers/net/wireless/marvell/mwifiex/tdls.c
@@ -27,6 +27,22 @@
 #define TDLS_CONFIRM_FIX_LEN  6
 #define MWIFIEX_TDLS_WMM_INFO_SIZE 7
 
+/*
+ * This table inverses the tos_to_tid operation to get a priority
+ * which is in sequential order, and can be compared.
+ * Use this to compare the priority of two different TIDs.
+ */
+static const u8 tos_to_tid_inv[] = {
+   0x02,  /* from tos_to_tid[2] = 0 */
+   0x00,  /* from tos_to_tid[0] = 1 */
+   0x01,  /* from tos_to_tid[1] = 2 */
+   0x03,
+   0x04,
+   0x05,
+   0x06,
+   0x07
+};
+
 static void mwifiex_restore_tdls_packets(struct mwifiex_private *priv,
 const u8 *mac, u8 status)
 {
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.h 
b/drivers/net/wireless/marvell/mwifiex/wmm.h
index 04d7da95e3078..60bdbb82277a3 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.h
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.h
@@ -33,21 +33,6 @@ enum ieee_types_wmm_ecw_bitmasks {
 
 static const u16 mwifiex_1d_to_wmm_queue[8] = { 1, 0, 0, 1, 2, 2, 3, 3 };
 
-/*
- * This table inverses the tos_to_tid operation to get a priority
- * which is in sequential order, and can be compared.
- * Use this to compare the priority of two different TIDs.
- */
-static const u8 tos_to_tid_inv[] = {
-   0x02,  /* from tos_to_tid[2] = 0 */
-   0x00,  /* from tos_to_tid[0] = 1 */
-   0x01,  /* from tos_to_tid[1] = 2 */
-   0x03,
-   0x04,
-   0x05,
-   0x06,
-   0x07};
-
 /*
  * This function retrieves the TID of the given RA list.
  */
-- 
2.25.1



[PATCH 08/28] wireless: intel: iwlwifi: rs: Demote non-compliant kernel-doc headers

2020-08-19 Thread Lee Jones
None of these headers attempt to document any function parameters.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:165: warning: cannot understand 
function prototype: 'const u16 expected_tpt_legacy[IWL_RATE_COUNT] = '
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:329: warning: Function parameter 
or member 'priv' not described in 'rs_program_fix_rate'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:329: warning: Function parameter 
or member 'lq_sta' not described in 'rs_program_fix_rate'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:452: warning: Function parameter 
or member 'tbl' not described in 'rs_collect_tx_data'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:452: warning: Function parameter 
or member 'scale_index' not described in 'rs_collect_tx_data'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:452: warning: Function parameter 
or member 'attempts' not described in 'rs_collect_tx_data'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:452: warning: Function parameter 
or member 'successes' not described in 'rs_collect_tx_data'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:681: warning: Function parameter 
or member 'sta' not described in 'rs_use_green'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:702: warning: Function parameter 
or member 'lq_sta' not described in 'rs_get_supported_rates'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:702: warning: Function parameter 
or member 'hdr' not described in 'rs_get_supported_rates'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:702: warning: Function parameter 
or member 'rate_type' not described in 'rs_get_supported_rates'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2628: warning: duplicate section 
name 'NOTE'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2632: warning: Function parameter 
or member 'priv' not described in 'rs_initialize_lq'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2632: warning: Function parameter 
or member 'sta' not described in 'rs_initialize_lq'
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c:2632: warning: Function parameter 
or member 'lq_sta' not described in 'rs_initialize_lq'

Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
index 4fa4eab2d7f38..548540dd0c0f7 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c
@@ -151,7 +151,7 @@ static void rs_dbgfs_set_mcs(struct iwl_lq_sta *lq_sta,
 {}
 #endif
 
-/**
+/*
  * The following tables contain the expected throughput metrics for all rates
  *
  * 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54, 60 MBits
@@ -318,7 +318,7 @@ static u8 rs_tl_add_packet(struct iwl_lq_sta *lq_data,
 }
 
 #ifdef CONFIG_MAC80211_DEBUGFS
-/**
+/*
  * Program the device to use fixed rate for frame transmit
  * This is for debugging/testing only
  * once the device start use fixed rate, we need to reload the module
@@ -440,7 +440,7 @@ static s32 get_expected_tpt(struct iwl_scale_tbl_info *tbl, 
int rs_index)
return 0;
 }
 
-/**
+/*
  * rs_collect_tx_data - Update the success/failure sliding window
  *
  * We keep a sliding window of the last 62 packets transmitted
@@ -673,7 +673,7 @@ static int rs_toggle_antenna(u32 valid_ant, u32 
*rate_n_flags,
return 1;
 }
 
-/**
+/*
  * Green-field mode is valid if the station supports it and
  * there are no non-GF stations present in the BSS.
  */
@@ -689,7 +689,7 @@ static bool rs_use_green(struct ieee80211_sta *sta)
return false;
 }
 
-/**
+/*
  * rs_get_supported_rates - get the available rates
  *
  * if management frame or broadcast frame only return
@@ -2612,7 +2612,7 @@ static void rs_rate_scale_perform(struct iwl_priv *priv,
lq_sta->last_txrate_idx = index;
 }
 
-/**
+/*
  * rs_initialize_lq - Initialize a station's hardware rate table
  *
  * The uCode's station table contains a table of fallback rates
-- 
2.25.1



[PATCH 18/28] wireless: rsi: rsi_91x_mac80211: Fix a few kerneldoc misdemeanours

2020-08-19 Thread Lee Jones
 - File headers should not be kernel-doc
 - Misnaming issues
 - Missing function parameter documentation

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/rsi/rsi_91x_mac80211.c:24: warning: cannot understand 
function prototype: 'const struct ieee80211_channel rsi_2ghz_channels[] = '
 drivers/net/wireless/rsi/rsi_91x_mac80211.c:739: warning: Function parameter 
or member 'vif' not described in 'rsi_get_connected_channel'
 drivers/net/wireless/rsi/rsi_91x_mac80211.c:739: warning: Excess function 
parameter 'adapter' description in 'rsi_get_connected_channel'
 drivers/net/wireless/rsi/rsi_91x_mac80211.c:868: warning: Function parameter 
or member 'changed_flags' not described in 'rsi_mac80211_conf_filter'
 drivers/net/wireless/rsi/rsi_91x_mac80211.c:868: warning: Excess function 
parameter 'changed' description in 'rsi_mac80211_conf_filter'
 drivers/net/wireless/rsi/rsi_91x_mac80211.c:946: warning: Function parameter 
or member 'sta' not described in 'rsi_hal_key_config'
 drivers/net/wireless/rsi/rsi_91x_mac80211.c:1245: warning: Function parameter 
or member 'vif' not described in 'rsi_perform_cqm'

Cc: Amitkumar Karwar 
Cc: Siva Rebbagondla 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/rsi/rsi_91x_mac80211.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c 
b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 5c0adb0efc5d6..ce223e680cba6 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -1,4 +1,4 @@
-/**
+/*
  * Copyright (c) 2014 Redpine Signals Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -731,7 +731,7 @@ static int rsi_mac80211_config(struct ieee80211_hw *hw,
 /**
  * rsi_get_connected_channel() - This function is used to get the current
  *  connected channel number.
- * @adapter: Pointer to the adapter structure.
+ * @vif: Pointer to the ieee80211_vif structure.
  *
  * Return: Current connected AP's channel number is returned.
  */
@@ -855,7 +855,7 @@ static void rsi_mac80211_bss_info_changed(struct 
ieee80211_hw *hw,
 /**
  * rsi_mac80211_conf_filter() - This function configure the device's RX filter.
  * @hw: Pointer to the ieee80211_hw structure.
- * @changed: Changed flags set.
+ * @changed_flags: Changed flags set.
  * @total_flags: Total initial flags set.
  * @multicast: Multicast.
  *
@@ -936,6 +936,7 @@ static int rsi_mac80211_conf_tx(struct ieee80211_hw *hw,
  * @hw: Pointer to the ieee80211_hw structure.
  * @vif: Pointer to the ieee80211_vif structure.
  * @key: Pointer to the ieee80211_key_conf structure.
+ * @sta: Pointer to the ieee80211_sta structure.
  *
  * Return: status: 0 on success, negative error codes on failure.
  */
@@ -1008,7 +1009,6 @@ static int rsi_hal_key_config(struct ieee80211_hw *hw,
  * @hw: Pointer to the ieee80211_hw structure.
  * @cmd: enum set_key_cmd.
  * @vif: Pointer to the ieee80211_vif structure.
- * @sta: Pointer to the ieee80211_sta structure.
  * @key: Pointer to the ieee80211_key_conf structure.
  *
  * Return: status: 0 on success, negative error code on failure.
@@ -1237,6 +1237,7 @@ static int rsi_mac80211_set_rate_mask(struct ieee80211_hw 
*hw,
  * @common: Pointer to the driver private structure.
  * @bssid: pointer to the bssid.
  * @rssi: RSSI value.
+ * @vif: Pointer to the ieee80211_vif structure.
  */
 static void rsi_perform_cqm(struct rsi_common *common,
u8 *bssid,
-- 
2.25.1



[PATCH 05/28] wireless: intel: dvm: Demote non-compliant kernel-doc headers

2020-08-19 Thread Lee Jones
None of these headers attempt to document any function parameters.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intel/iwlwifi/dvm/main.c:388: warning: Function parameter 
or member 't' not described in 'iwl_bg_statistics_periodic'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:545: warning: Function parameter 
or member 't' not described in 'iwl_bg_ucode_trace'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:771: warning: Function parameter 
or member 'priv' not described in 'iwl_alive_start'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function 
parameter or member 'priv' not described in 'iwl_print_event_log'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function 
parameter or member 'start_idx' not described in 'iwl_print_event_log'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function 
parameter or member 'num_events' not described in 'iwl_print_event_log'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function 
parameter or member 'mode' not described in 'iwl_print_event_log'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function 
parameter or member 'pos' not described in 'iwl_print_event_log'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function 
parameter or member 'buf' not described in 'iwl_print_event_log'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1692: warning: Function 
parameter or member 'bufsz' not described in 'iwl_print_event_log'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'priv' not described in 'iwl_print_last_event_logs'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'capacity' not described in 'iwl_print_last_event_logs'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'num_wraps' not described in 'iwl_print_last_event_logs'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'next_entry' not described in 'iwl_print_last_event_logs'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'size' not described in 'iwl_print_last_event_logs'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'mode' not described in 'iwl_print_last_event_logs'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'pos' not described in 'iwl_print_last_event_logs'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'buf' not described in 'iwl_print_last_event_logs'
 drivers/net/wireless/intel/iwlwifi/dvm/main.c:1772: warning: Function 
parameter or member 'bufsz' not described in 'iwl_print_last_event_logs'

Cc: Johannes Berg 
Cc: Emmanuel Grumbach 
Cc: Luca Coelho 
Cc: Intel Linux Wireless 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intel/iwlwifi/dvm/main.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/main.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
index b882705ff66df..461af58311561 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/main.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
@@ -374,7 +374,7 @@ int iwl_send_statistics_request(struct iwl_priv *priv, u8 
flags, bool clear)
&statistics_cmd);
 }
 
-/**
+/*
  * iwl_bg_statistics_periodic - Timer callback to queue statistics
  *
  * This callback is provided in order to send a statistics request.
@@ -533,7 +533,7 @@ static void iwl_continuous_event_trace(struct iwl_priv 
*priv)
priv->event_log.next_entry = next_entry;
 }
 
-/**
+/*
  * iwl_bg_ucode_trace - Timer callback to log ucode event
  *
  * The timer is continually set to execute every
@@ -762,7 +762,7 @@ static void iwl_send_bt_config(struct iwl_priv *priv)
IWL_ERR(priv, "failed to send BT Coex Config\n");
 }
 
-/**
+/*
  * iwl_alive_start - called after REPLY_ALIVE notification received
  *   from protocol/runtime uCode (initialization uCode's
  *   Alive gets handled by iwl_init_alive_start()).
@@ -1682,9 +1682,8 @@ static void iwl_dump_nic_error_log(struct iwl_priv *priv)
 
 #define EVENT_START_OFFSET  (4 * sizeof(u32))
 
-/**
+/*
  * iwl_print_event_log - Dump error event log to syslog
- *
  */
 static int iwl_print_event_log(struct iwl_priv *priv, u32 start_idx,
   u32 num_events, u32 mode,
@@ -1762,7 +1761,7 @@ static int iwl_print_event_log(struct iwl_priv *priv, u32 
start_idx,
return pos;
 }
 
-/**
+/*
  * iwl_print_last_event_logs - Dump the newest # of event log to syslog
  */
 static int iwl_print_last_event_logs(struct iwl_priv *priv, u32 capacity,
-- 
2.25.1



[PATCH 09/28] wireless: intel: iwlegacy: debug: Demote seemingly unintentional kerneldoc header

2020-08-19 Thread Lee Jones
This is the only use of kerneldoc in the sourcefile and no
descriptions are provided.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/intel/iwlegacy/debug.c:1373: warning: Function parameter 
or member 'il' not described in 'il_dbgfs_unregister'

Cc: Stanislaw Gruszka 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: Linux Wireless 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intel/iwlegacy/debug.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/debug.c 
b/drivers/net/wireless/intel/iwlegacy/debug.c
index 4f741b305d964..d998a3f1b0566 100644
--- a/drivers/net/wireless/intel/iwlegacy/debug.c
+++ b/drivers/net/wireless/intel/iwlegacy/debug.c
@@ -1364,9 +1364,8 @@ il_dbgfs_register(struct il_priv *il, const char *name)
 }
 EXPORT_SYMBOL(il_dbgfs_register);
 
-/**
+/*
  * Remove the debugfs files and directories
- *
  */
 void
 il_dbgfs_unregister(struct il_priv *il)
-- 
2.25.1



[PATCH 04/28] wireless: marvell: libertas_tf: Demote non-conformant kernel-doc headers

2020-08-19 Thread Lee Jones
There are only 2 kernel-doc headers in this file and both are
incorrect.  The first one does not attempt to document the function at
all and the second one is suffering from severe doc-rot; the format is
wrong and only 1 out of 3 parameters are being documented.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/marvell/libertas_tf/main.c:129: warning: Function 
parameter or member 't' not described in 'command_timer_fn'
 drivers/net/wireless/marvell/libertas_tf/main.c:554: warning: Function 
parameter or member 'card' not described in 'lbtf_add_card'
 drivers/net/wireless/marvell/libertas_tf/main.c:554: warning: Function 
parameter or member 'dmdev' not described in 'lbtf_add_card'
 drivers/net/wireless/marvell/libertas_tf/main.c:554: warning: Function 
parameter or member 'ops' not described in 'lbtf_add_card'

Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/marvell/libertas_tf/main.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas_tf/main.c 
b/drivers/net/wireless/marvell/libertas_tf/main.c
index 02bd7c99b3588..5937b645a5334 100644
--- a/drivers/net/wireless/marvell/libertas_tf/main.c
+++ b/drivers/net/wireless/marvell/libertas_tf/main.c
@@ -121,7 +121,7 @@ static void lbtf_cmd_work(struct work_struct *work)
lbtf_deb_leave(LBTF_DEB_CMD);
 }
 
-/**
+/*
  *  This function handles the timeout of command sending.
  *  It will re-send the same command again.
  */
@@ -542,11 +542,9 @@ int lbtf_rx(struct lbtf_private *priv, struct sk_buff *skb)
 }
 EXPORT_SYMBOL_GPL(lbtf_rx);
 
-/**
+/*
  * lbtf_add_card: Add and initialize the card.
  *
- *  @cardA pointer to card
- *
  *  Returns: pointer to struct lbtf_priv.
  */
 struct lbtf_private *lbtf_add_card(void *card, struct device *dmdev,
-- 
2.25.1



[PATCH 02/28] wireless: rsi_91x_main: Fix some kernel-doc issues

2020-08-19 Thread Lee Jones
The file header should not be kernel-doc.  Add missing 'rec_pkt'
description.  Update 'rsi_91x_init()'s parameter description.

Fixes the following W=1 kernel build warning(s):

 drivers/net/wireless/rsi/rsi_91x_main.c:17: warning: Function parameter or 
member 'fmt' not described in 'pr_fmt'
 drivers/net/wireless/rsi/rsi_91x_main.c:156: warning: Function parameter or 
member 'rx_pkt' not described in 'rsi_read_pkt'
 drivers/net/wireless/rsi/rsi_91x_main.c:287: warning: Function parameter or 
member 'oper_mode' not described in 'rsi_91x_init'
 drivers/net/wireless/rsi/rsi_91x_main.c:287: warning: Excess function 
parameter 'void' description in 'rsi_91x_init'

Cc: Amitkumar Karwar 
Cc: Siva Rebbagondla 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/rsi/rsi_91x_main.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c 
b/drivers/net/wireless/rsi/rsi_91x_main.c
index 29d83049c5f56..576f51f9b4a7e 100644
--- a/drivers/net/wireless/rsi/rsi_91x_main.c
+++ b/drivers/net/wireless/rsi/rsi_91x_main.c
@@ -1,4 +1,4 @@
-/**
+/*
  * Copyright (c) 2014 Redpine Signals Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -148,6 +148,7 @@ static struct sk_buff *rsi_prepare_skb(struct rsi_common 
*common,
 /**
  * rsi_read_pkt() - This function reads frames from the card.
  * @common: Pointer to the driver private structure.
+ * @rcv_pkt: Received pkt.
  * @rcv_pkt_len: Received pkt length. In case of USB it is 0.
  *
  * Return: 0 on success, -1 on failure.
@@ -279,7 +280,7 @@ void rsi_set_bt_context(void *priv, void *bt_context)
 
 /**
  * rsi_91x_init() - This function initializes os interface operations.
- * @void: Void.
+ * @oper_mode: One of DEV_OPMODE_*.
  *
  * Return: Pointer to the adapter structure on success, NULL on failure .
  */
-- 
2.25.1



[PATCH 01/28] wireless: intersil: hostap: Mark 'freq_list' as __maybe_unused

2020-08-19 Thread Lee Jones
'freq_list' is used in some source files which include hostap.h, but
not all.  The compiler complains about the times it's not used.  Mark
it as __maybe_used to tell the compiler that this is not only okay,
it's expected.

Fixes the following W=1 kernel build warning(s):

 In file included from drivers/net/wireless/intersil/hostap/hostap_80211_tx.c:9:
 drivers/net/wireless/intersil/hostap/hostap.h:11:19: warning: ‘freq_list’ 
defined but not used [-Wunused-const-variable=]
 In file included from drivers/net/wireless/intersil/hostap/hostap_main.c:31:
 drivers/net/wireless/intersil/hostap/hostap.h:11:19: warning: ‘freq_list’ 
defined but not used [-Wunused-const-variable=]
 In file included from drivers/net/wireless/intersil/hostap/hostap_proc.c:10:
 drivers/net/wireless/intersil/hostap/hostap.h:11:19: warning: ‘freq_list’ 
defined but not used [-Wunused-const-variable=]
 In file included from drivers/net/wireless/intersil/hostap/hostap_hw.c:50,
 from drivers/net/wireless/intersil/hostap/hostap_cs.c:196:
 At top level:
 drivers/net/wireless/intersil/hostap/hostap.h:11:19: warning: ‘freq_list’ 
defined but not used [-Wunused-const-variable=]
 In file included from drivers/net/wireless/intersil/hostap/hostap_hw.c:50,
 from drivers/net/wireless/intersil/hostap/hostap_pci.c:221:
 At top level:
 drivers/net/wireless/intersil/hostap/hostap.h:11:19: warning: ‘freq_list’ 
defined but not used [-Wunused-const-variable=]
 In file included from drivers/net/wireless/intersil/hostap/hostap_hw.c:50,
 from drivers/net/wireless/intersil/hostap/hostap_plx.c:264:
 At top level:
 drivers/net/wireless/intersil/hostap/hostap.h:11:19: warning: ‘freq_list’ 
defined but not used [-Wunused-const-variable=]

Cc: Jouni Malinen 
Cc: Kalle Valo 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones 
---
 drivers/net/wireless/intersil/hostap/hostap.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap.h 
b/drivers/net/wireless/intersil/hostap/hostap.h
index 8130d29c7989c..c4b81ff7d7e47 100644
--- a/drivers/net/wireless/intersil/hostap/hostap.h
+++ b/drivers/net/wireless/intersil/hostap/hostap.h
@@ -8,8 +8,10 @@
 #include "hostap_wlan.h"
 #include "hostap_ap.h"
 
-static const long freq_list[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442,
- 2447, 2452, 2457, 2462, 2467, 2472, 2484 };
+static const long __maybe_unused freq_list[] = {
+   2412, 2417, 2422, 2427, 2432, 2437, 2442,
+   2447, 2452, 2457, 2462, 2467, 2472, 2484
+};
 #define FREQ_COUNT ARRAY_SIZE(freq_list)
 
 /* hostap.c */
-- 
2.25.1



Re: [PATCH] libceph: Convert to use the preferred fallthrough macro

2020-08-19 Thread Ilya Dryomov
On Tue, Aug 18, 2020 at 9:56 PM Jeff Layton  wrote:
>
> On Tue, 2020-08-18 at 08:26 -0400, Miaohe Lin wrote:
> > Convert the uses of fallthrough comments to fallthrough macro.
> >
> > Signed-off-by: Miaohe Lin 
> > ---
> >  net/ceph/ceph_hash.c| 20 ++--
> >  net/ceph/crush/mapper.c |  2 +-
> >  net/ceph/messenger.c|  4 ++--
> >  net/ceph/mon_client.c   |  2 +-
> >  net/ceph/osd_client.c   |  4 ++--
> >  5 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/net/ceph/ceph_hash.c b/net/ceph/ceph_hash.c
> > index 81e1e006c540..16a47c0eef37 100644
> > --- a/net/ceph/ceph_hash.c
> > +++ b/net/ceph/ceph_hash.c
> > @@ -50,35 +50,35 @@ unsigned int ceph_str_hash_rjenkins(const char *str, 
> > unsigned int length)
> >   switch (len) {
> >   case 11:
> >   c = c + ((__u32)k[10] << 24);
> > - /* fall through */
> > + fallthrough;
> >   case 10:
> >   c = c + ((__u32)k[9] << 16);
> > - /* fall through */
> > + fallthrough;
> >   case 9:
> >   c = c + ((__u32)k[8] << 8);
> >   /* the first byte of c is reserved for the length */
> > - /* fall through */
> > + fallthrough;
> >   case 8:
> >   b = b + ((__u32)k[7] << 24);
> > - /* fall through */
> > + fallthrough;
> >   case 7:
> >   b = b + ((__u32)k[6] << 16);
> > - /* fall through */
> > + fallthrough;
> >   case 6:
> >   b = b + ((__u32)k[5] << 8);
> > - /* fall through */
> > + fallthrough;
> >   case 5:
> >   b = b + k[4];
> > - /* fall through */
> > + fallthrough;
> >   case 4:
> >   a = a + ((__u32)k[3] << 24);
> > - /* fall through */
> > + fallthrough;
> >   case 3:
> >   a = a + ((__u32)k[2] << 16);
> > - /* fall through */
> > + fallthrough;
> >   case 2:
> >   a = a + ((__u32)k[1] << 8);
> > - /* fall through */
> > + fallthrough;
> >   case 1:
> >   a = a + k[0];
> >   /* case 0: nothing left to add */
> > diff --git a/net/ceph/crush/mapper.c b/net/ceph/crush/mapper.c
> > index 07e5614eb3f1..7057f8db4f99 100644
> > --- a/net/ceph/crush/mapper.c
> > +++ b/net/ceph/crush/mapper.c
> > @@ -987,7 +987,7 @@ int crush_do_rule(const struct crush_map *map,
> >   case CRUSH_RULE_CHOOSELEAF_FIRSTN:
> >   case CRUSH_RULE_CHOOSE_FIRSTN:
> >   firstn = 1;
> > - /* fall through */
> > + fallthrough;
> >   case CRUSH_RULE_CHOOSELEAF_INDEP:
> >   case CRUSH_RULE_CHOOSE_INDEP:
> >   if (wsize == 0)
> > diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
> > index 27d6ab11f9ee..bdfd66ba3843 100644
> > --- a/net/ceph/messenger.c
> > +++ b/net/ceph/messenger.c
> > @@ -412,7 +412,7 @@ static void ceph_sock_state_change(struct sock *sk)
> >   switch (sk->sk_state) {
> >   case TCP_CLOSE:
> >   dout("%s TCP_CLOSE\n", __func__);
> > - /* fall through */
> > + fallthrough;
> >   case TCP_CLOSE_WAIT:
> >   dout("%s TCP_CLOSE_WAIT\n", __func__);
> >   con_sock_state_closing(con);
> > @@ -2751,7 +2751,7 @@ static int try_read(struct ceph_connection *con)
> >   switch (ret) {
> >   case -EBADMSG:
> >   con->error_msg = "bad crc/signature";
> > - /* fall through */
> > + fallthrough;
> >   case -EBADE:
> >   ret = -EIO;
> >   break;
> > diff --git a/net/ceph/mon_client.c b/net/ceph/mon_client.c
> > index 3d8c8015e976..d633a0aeaa55 100644
> > --- a/net/ceph/mon_client.c
> > +++ b/net/ceph/mon_client.c
> > @@ -1307,7 +1307,7 @@ static struct ceph_msg *mon_alloc_msg(struct 
> > ceph_connection *con,
> >* request had a non-zero tid.  Work around this weirdness
> >* by allocating a new message.
> >*/
> > - /* fall through */
> > + fallthrough;
> >   case CEPH_MSG_MON_MAP:
> >   case CEPH_MSG_MDS_MAP:
> >   case CEPH_MSG_OSD_MAP:
> > diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> > index e4fbcad6e7d8..7901ab6c79fd 100644
> > --- a/net/ceph/osd_client.c
> > +++ b/net/ceph/osd_client.c
> > @@ -3854,7 +3854,7 @@ static void scan_requests(struct ceph_osd *osd,
> >   if (!force_resend && !force_resend_writes)
> >   break;
> >
> > - /* fall through */
> > + fallthrough;
> >   case CALC_TARGET_NEED_RESEND:
> >  

Is netif_rx_ni safe from interrupt context? (Re: [PATCH] batman-adv: bla: use netif_rx_ni when not in interrupt context)

2020-08-19 Thread Jussi Kivilinna
Hello,

+CC netdev mailing-list

On 18.8.2020 23.12, Antonio Quartulli wrote:
> Hi,
> 
> On 18/08/2020 16:46, Jussi Kivilinna wrote:
>> batadv_bla_send_claim() gets called from worker thread context through
>> batadv_bla_periodic_work(), thus netif_rx_ni needs to be used in that
>> case. This fixes "NOHZ: local_softirq_pending 08" log messages seen
>> when batman-adv is enabled.
>>
>> Signed-off-by: Jussi Kivilinna 
>> ---
>>  net/batman-adv/bridge_loop_avoidance.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/batman-adv/bridge_loop_avoidance.c 
>> b/net/batman-adv/bridge_loop_avoidance.c
>> index 5c41cc52bc53..ab6cec3c7586 100644
>> --- a/net/batman-adv/bridge_loop_avoidance.c
>> +++ b/net/batman-adv/bridge_loop_avoidance.c
>> @@ -437,7 +437,10 @@ static void batadv_bla_send_claim(struct batadv_priv 
>> *bat_priv, u8 *mac,
>>  batadv_add_counter(bat_priv, BATADV_CNT_RX_BYTES,
>> skb->len + ETH_HLEN);
>>  
>> -netif_rx(skb);
>> +if (in_interrupt())
>> +netif_rx(skb);
>> +else
>> +netif_rx_ni(skb);
> 
> What's the downside in calling netif_rx_ni() all the times?
> Is there any possible side effect?
> (consider this call is not along the fast path)

Good question. I tried to find answer for this but found documentation being 
lacking 
on the issue, so I looked for examples and used 
'in_interrupt/netif_rx/netif_rx_ni' 
bit that appears in few other places: 
 https://elixir.bootlin.com/linux/v5.8/source/drivers/net/caif/caif_hsi.c#L469
 
https://elixir.bootlin.com/linux/v5.8/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c#L425
 
https://elixir.bootlin.com/linux/v5.8/source/drivers/net/wireless/marvell/libertas/rx.c#L153
 
https://elixir.bootlin.com/linux/v5.8/source/drivers/net/wireless/marvell/mwifiex/uap_txrx.c#L356
 https://elixir.bootlin.com/linux/v5.8/source/net/caif/chnl_net.c#L121

Maybe someone on netdev mailing-list could give hint on this matter - should 
'in_interrupt()?netif_rx(skb):netif_rx_ni(skb)' be used if context is not known 
or 
is just using 'netif_rx_ni(skb)' ok? 

> 
> On top of that, I just checked the definition of in_interrupt() and I
> got this comment:
> 
>  * Note: due to the BH disabled confusion: in_softirq(),in_interrupt()
> really
>  *   should not be used in new code.
> 
> 
> Check
> https://elixir.bootlin.com/linux/latest/source/include/linux/preempt.h#L85
> 
> Is that something we should consider or is the comment bogus?

It very well be that the existing code that I looked at may not be the best 
for reuse today.

-Jussi


Re: [PATCH net-next v2 0/7] net-next: dsa: mt7530: add support for MT7531

2020-08-19 Thread Landen Chao
Hi DENG,

MT7531 mirror port has been fixed by new definition of register base in 
header file. The logic of mirror port setting in 7530.c is reused.

@@ -41,6 +42,33 @@  enum mt753x_id {
 #define  MIRROR_PORT(x)((x) & 0x7)
 #define  MIRROR_MASK   0x7
 
+/* Registers for CPU forward control */
+#define MT7531_CFC 0x4
+#define  MT7531_MIRROR_EN  BIT(19)
+#define  MT7531_MIRROR_MASK(MIRROR_MASK << 16)
+#define  MT7531_MIRROR_PORT_GET(x) (((x) >> 16) & MIRROR_MASK)
+#define  MT7531_MIRROR_PORT_SET(x) (((x) & MIRROR_MASK) << 16)
+#define  MT7531_CPU_PMAP_MASK  GENMASK(7, 0)
+
+#define MT753X_MIRROR_REG(id)  (((id) == ID_MT7531) ? \
+MT7531_CFC : MT7530_MFC)
+#define MT753X_MIRROR_EN(id)   (((id) == ID_MT7531) ? \
+MT7531_MIRROR_EN : MIRROR_EN)
+#define MT753X_MIRROR_MASK(id) (((id) == ID_MT7531) ? \
+MT7531_MIRROR_MASK : MIRROR_MASK)


On Wed, 2020-08-19 at 11:49 +0800, DENG Qingfang wrote:
> Hi,
> 
> Is port mirroring working? Port mirroring registers on MT7531 have
> moved, according to bpi's MT7531 reference manual.
> Please fix that as well.



[PATCH][next] ath11k: fix spelling mistake "moniter" -> "monitor"

2020-08-19 Thread Colin King
From: Colin Ian King 

There is a spelling mistake in an ath11k_warn warning message. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/ath/ath11k/debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/debug.c 
b/drivers/net/wireless/ath/ath11k/debug.c
index 0a3cfa716390..0ba234ad99b2 100644
--- a/drivers/net/wireless/ath/ath11k/debug.c
+++ b/drivers/net/wireless/ath/ath11k/debug.c
@@ -1097,7 +1097,7 @@ static ssize_t ath11k_write_pktlog_filter(struct file 
*file,
   DP_RX_BUFFER_SIZE, 
&tlv_filter);
 
if (ret) {
-   ath11k_warn(ab, "failed to set rx filter for moniter 
status ring\n");
+   ath11k_warn(ab, "failed to set rx filter for monitor 
status ring\n");
goto out;
}
}
-- 
2.27.0



Re: [PATCH net-next v2 7/7] arm64: dts: mt7622: add mt7531 dsa to bananapi-bpi-r64 board

2020-08-19 Thread Landen Chao
On Wed, 2020-08-19 at 00:24 +0800, Vladimir Oltean wrote:
> On Tue, Aug 18, 2020 at 03:14:12PM +0800, Landen Chao wrote:
> > Add mt7531 dsa to bananapi-bpi-r64 board for 5 giga Ethernet ports support.
> > 
> > Signed-off-by: Landen Chao 
> > ---
> >  .../dts/mediatek/mt7622-bananapi-bpi-r64.dts  | 44 +++
> >  1 file changed, 44 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts 
> > b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> > index d174ad214857..c57b2571165f 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> > @@ -143,6 +143,50 @@
> > mdio: mdio-bus {
> > #address-cells = <1>;
> > #size-cells = <0>;
> > +
> > +   switch@0 {
> > +   compatible = "mediatek,mt7531";
> > +
[snip]
> > +   port@6 {
> > +   reg = <6>;
> > +   label = "cpu";
> > +   ethernet = <&gmac0>;
> > +   phy-mode = "2500base-x";
> > +   };
> 
> Is there any reason why you're not specifying a fixed-link node here?
I got the below feedback in v1, so I follow the DSA common design in v2.
v2 can work with fixed-link node or without fixed-link node in CPU port
node.

  "This fixed-link should not be needed. The DSA driver is supposed to
   configure the CPU port to its fastest speed by default. 2500 is
   the fastest speed a 2500Base-X link can do..."
> > +   };
> > +   };
> > +
> > };
> >  };
> >  
> > -- 
> > 2.17.1
> 
> Thanks,
> -Vladimir



答复: 答复: [Intel-wired-lan] [PATCH 0/2] intel/xdp fixes for fliping rx buffer

2020-08-19 Thread Li,Rongqing


> -邮件原件-
> 发件人: Björn Töpel [mailto:bjorn.to...@intel.com]
> 发送时间: 2020年8月19日 14:45
> 收件人: Li,Rongqing ; Björn Töpel
> 
> 抄送: Netdev ; intel-wired-lan
> ; Karlsson, Magnus
> ; bpf ; Maciej Fijalkowski
> ; Piotr ; Maciej
> 
> 主题: Re: 答复: [Intel-wired-lan] [PATCH 0/2] intel/xdp fixes for fliping rx 
> buffer
> 
> On 2020-08-19 03:37, Li,Rongqing wrote:
> [...]
>  > Hi:
>  >
>  > Thanks for your explanation.
>  >
>  > But we can reproduce this bug
>  >
>  > We use ebpf to redirect only-Vxlan packets to non-zerocopy AF_XDP, First we
> see panic on tcp stack, in tcp_collapse: BUG_ON(offset < 0); it is very hard 
> to
> reproduce.
>  >
>  > Then we use the scp to do test, and has lots of vxlan packet at the same
> time, scp will be broken frequently.
>  >
> 
> Ok! Just so that I'm certain of your setup. You receive packets to an i40e 
> netdev
> where there's an XDP program. The program does XDP_PASS or XDP_REDIRECT
> to e.g. devmap for non-vxlan packets. However, vxlan packets are redirected to
> AF_XDP socket(s) in *copy-mode*. Am I understanding that correct?
> 
Similar as your description, 

but the xdp program only redirects vxlan packets to af_xdp socket, other 
packets will go to Linux kernel networking stack, like scp/ssh packets


> I'm assuming this is an x86-64 with 4k page size, right? :-) The page 
> flipping is a
> bit different if the PAGE_SIZE is not 4k.
> 

We use 4k page size, page flipping is 4k, we did not change the i40e drivers, 
4.19 stable kernel

>  > With this fixes, scp has not been broken again, and kernel is not panic
> again  >
> 
> Let's dig into your scenario.
> 
> Are you saying the following:
> 
> Page A:
> +
> | "first skb" > Rx HW ring entry X 
> +
> | "second skb"> Rx HW ring entry X+1 (or X+n)
> +
> 

Like:

First skb will be into tcp socket rx queue

Seconds skb is vxlan packet, will be copy to af_xdp socket, and released.

> This is a scenario that shouldn't be allowed, because there are now two users
> of the page. If that's the case, the refcounting is broken. Is that the case?
> 

True, it is broken for copy mode xsk

-Li

> Check out i40e_can_reuse_rx_page(). The idea with page flipping/reuse is that
> the page is only reused if there is only one user.
> 
>  > Seem your explanation is unable to solve my analysis:
>  >
>  > 1. first skb is not for xsk, and forwarded to another device
>  >or socket queue
> 
> The data for the "first skb" resides on a page:
> A:
> +
> | "first skb"
> +
> | to be reused
> +
> refcount >>1
> 
>  > 2. seconds skb is for xsk, copy data to xsk memory, and page
>  >of skb->data is released
> 
> Note that page B != page A.
> 
> B:
> +
> | to be reused/or used by the stack
> +
> | "second skb for xsk"
> +
> refcount >>1
> 
> data is copied to socket, page_frag_free() is called, and the page count is
> decreased. The driver will then check if the page can be reused. If not, it's 
> freed
> to the page allocator.
> 
>  > 3. rx_buff is reusable since only first skb is in it, but
>  >*_rx_buffer_flip will make that page_offset is set to
>  >first skb data
> 
> I'm having trouble grasping how this is possible. More than one user implies
> that it wont be reused. If this is possible, the recounting/reuse mechanism is
> broken, and that is what should be fixed.
> 
> The AF_XDP redirect should not have semantics different from, say, devmap
> redirect. It's just that the page_frag_free() is called earlier for AF_XDP, 
> instead
> of from i40e_clean_tx_irq() as the case for devmap/XDP_TX.
> 
>  > 4. then reuse rx buffer, first skb which still is living
>  >will be corrupted.
>  >
>  >
>  > The root cause is difference you said upper, so I only fixes for 
> non-zerocopy
> AF_XDP  >
> 
> I have only addressed non-zerocopy, so we're on the same page (pun
> intended) here!
> 
> 
> Björn
> 
>  > -Li


RE: Use of genradix in sctp

2020-08-19 Thread David Laight
From:'Marcelo Ricardo Leitner
> Sent: 18 August 2020 22:38
> 
> On Tue, Aug 18, 2020 at 03:38:09PM +, David Laight wrote:
> > A few years ago (for 5.1) the 'arrays' that sctp uses for
> > info about data streams was changed to use the 'genradix'
> > functions.
> >
> > I'm not sure of the reason for the change, but I don't
> > thing anyone looked at the performance implications.
> 
> I don't have something like a CI for it, but I do run some performance
> benchmarks every now and then and it didn't trigger anything
> noticeable in my tests.

We have some customers who we think are sending 1+ short
SCTP data chunks a second.
They are probably sending SMS messages, so that is 5000+ text
messages a second!
It is hard to stop those being sent with more than one
data chunk in each ethernet frame!

> Yet, can it be improved? Certainly. Patches welcomed. :-)

I'll apply some of my copious free time to it...
Actually some simple changes would help:

1) Change SCTP_SO()->x to so=SCTP_SO(); so->x in places
   where there are multiple references to the same stream.

2) Optimise the genradix lookup for the case where there
   is a single page - it can be completely inlined.

3) Defer the allocation until the stream is used.
   for outbound streams this could remove the extra buffer.

> > The code contains lots of SCTP_SI(stream, i) with the
> > probable expectation that the expansion is basically
> > stream->foo[i] (a pointer to a big memory array).
> >
> > However the genradix functions are far more complicated.
> > Basically it is a list of pointers to pages, each of
> > which is split into the maximum number of items.
> > (With the page pointers being in a tree of pages
> > for large numbers of large items.)
> >
> > So every SCTP_S[IO]() has inline code to calculate
> > the byte offset:
> > idx / objs_per_page * PAGE_SIZE + idx % objs_per_page * obj_size
> > (objs_per_page and obj_size are compile time constants)
> > and then calls a function to do the actual lookup.
> >
> > This is all rather horrid when the array isn't even sparse.
> >
> > I also doubt it really helps if anyone is trying to allow
> > a lot of streams. For 64k streams you might be trying to
> > allocate ~700 pages in atomic context.
> 
> Yes, and kvrealloc as you suggested on another email is not a
> solution, because it can't fallback to vmalloc in atomic contexts.
> 
> Genradix here allows it to use several non-contiguous pages, which is
> a win if compared to a simple kmalloc(..., GFP_ATOMIC) it had before
> flex_arrays, and anything that we could implement around such scheme
> would be just re-implementing genradix/flex_arrays again. After all,
> it does need 64k elements allocated.
> 
> How soon it needs them? Well, it already deferred some allocation with
> the usage of sctp_stream_out_ext (which is only allocated when the
> stream is actually used, but added another pointer deref), leaving
> just stuff couldn't be (easily) initialized later, there.
> 
> >
> > For example look at the object code for sctp_stream_clear()
> > (__genradix_ptr() is in lib/generic-radix-tree.c).
> 
> sctp_stream_clear() is rarely called.
> 
> Caller graph:
> sctp_stream_clear
>   sctp_assoc_update
> SCTP_CMD_UPDATE_ASSOC
>   sctp_sf_do_dupcook_b
>   sctp_sf_do_dupcook_a
> 
> So, well, I'm not worried about it.

I wasn't considering the loop.
It was just a place where the object code can be looked at.

But there are quite a few places where the same stream
is looked for lots of times in succession.
Even saving the pointer is probably noticeable.

> Specs say 64k streams, so we should support that and preferrably
> without major regressions. Traversing 64k elements each time to find
> an entry is very not performant.
> 
> For a more standard use case, with something like you were saying, 17
> streams, genradix here doesn't use too much memory. I'm afraid a
> couple of integer calculations to get an offset is minimal overhead if
> compared to the rest of the code.

It is probably nearer 40 including a function call - which
is likely to cause register spills.

> For example, the stream scheduler
> operations, accessed via struct sctp_sched_ops (due to retpoline), is
> probably more interesting fixing than genradix effects here.

Hmmm... the most scheduling M3UA/M2PA (etc) want is (probably)
to send stream 0 first.
But even the use of stream 0 (for non-data messages) is a
misunderstanding (of my understanding) of what SCTP streams are.
IIRC there is only one flow control window.
I thought that tx data just got added to a single tx queue,
and the multiple streams just allowed some messages to passed
on to the receiving application while waiting for retransmissions
(head of line blocking).

OTOH M2PA seems to wand stream 0 to have the semantics of
ISO transport 'expedited data' - which can be sent even when
the main flow is blocked because it has its own credit (of 1).

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton 

Re: 答复: 答复: [Intel-wired-lan] [PATCH 0/2] intel/xdp fixes for fliping rx buffer

2020-08-19 Thread Björn Töpel

On 2020-08-19 10:17, Li,Rongqing wrote:




-邮件原件-
发件人: Björn Töpel [mailto:bjorn.to...@intel.com]
发送时间: 2020年8月19日 14:45
收件人: Li,Rongqing ; Björn Töpel

抄送: Netdev ; intel-wired-lan
; Karlsson, Magnus
; bpf ; Maciej Fijalkowski
; Piotr ; Maciej

主题: Re: 答复: [Intel-wired-lan] [PATCH 0/2] intel/xdp fixes for fliping rx buffer

On 2020-08-19 03:37, Li,Rongqing wrote:
[...]
  > Hi:
  >
  > Thanks for your explanation.
  >
  > But we can reproduce this bug
  >
  > We use ebpf to redirect only-Vxlan packets to non-zerocopy AF_XDP, First we
see panic on tcp stack, in tcp_collapse: BUG_ON(offset < 0); it is very hard to
reproduce.
  >
  > Then we use the scp to do test, and has lots of vxlan packet at the same
time, scp will be broken frequently.
  >

Ok! Just so that I'm certain of your setup. You receive packets to an i40e 
netdev
where there's an XDP program. The program does XDP_PASS or XDP_REDIRECT
to e.g. devmap for non-vxlan packets. However, vxlan packets are redirected to
AF_XDP socket(s) in *copy-mode*. Am I understanding that correct?


Similar as your description,

but the xdp program only redirects vxlan packets to af_xdp socket, other 
packets will go to Linux kernel networking stack, like scp/ssh packets



I'm assuming this is an x86-64 with 4k page size, right? :-) The page flipping 
is a
bit different if the PAGE_SIZE is not 4k.



We use 4k page size, page flipping is 4k, we did not change the i40e drivers, 
4.19 stable kernel



Would you mind testing on a newer kernel? Say the latest stable 5.8.2?



  > With this fixes, scp has not been broken again, and kernel is not panic
again  >

Let's dig into your scenario.

Are you saying the following:

Page A:
+
| "first skb" > Rx HW ring entry X
+
| "second skb"> Rx HW ring entry X+1 (or X+n)
+



Like:

First skb will be into tcp socket rx queue

Seconds skb is vxlan packet, will be copy to af_xdp socket, and released.


This is a scenario that shouldn't be allowed, because there are now two users
of the page. If that's the case, the refcounting is broken. Is that the case?



True, it is broken for copy mode xsk



Ok. However, the fix is not avoiding the page_frag_free, but finding and 
fixing the refcount bug. I'll have a deeper look.


But please, try to reproduce with a newer kernel.


Thanks,
Björn


[PATCH v2] net: Stop warning about SO_BSDCOMPAT usage

2020-08-19 Thread Miaohe Lin
We've been warning about SO_BSDCOMPAT usage for many years. We may remove
this code completely now.

Suggested-by: David S. Miller 
Signed-off-by: Miaohe Lin 
---
 net/core/sock.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index e4f40b175acb..64d2aec5ed45 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -413,18 +413,6 @@ static int sock_set_timeout(long *timeo_p, sockptr_t 
optval, int optlen,
return 0;
 }
 
-static void sock_warn_obsolete_bsdism(const char *name)
-{
-   static int warned;
-   static char warncomm[TASK_COMM_LEN];
-   if (strcmp(warncomm, current->comm) && warned < 5) {
-   strcpy(warncomm,  current->comm);
-   pr_warn("process `%s' is using obsolete %s SO_BSDCOMPAT\n",
-   warncomm, name);
-   warned++;
-   }
-}
-
 static bool sock_needs_netstamp(const struct sock *sk)
 {
switch (sk->sk_family) {
@@ -984,7 +972,6 @@ int sock_setsockopt(struct socket *sock, int level, int 
optname,
break;
 
case SO_BSDCOMPAT:
-   sock_warn_obsolete_bsdism("setsockopt");
break;
 
case SO_PASSCRED:
@@ -1387,7 +1374,6 @@ int sock_getsockopt(struct socket *sock, int level, int 
optname,
break;
 
case SO_BSDCOMPAT:
-   sock_warn_obsolete_bsdism("getsockopt");
break;
 
case SO_TIMESTAMP_OLD:
-- 
2.19.1



Re: [PATCH] cfg80211: switch from WARN() to pr_warn() in is_user_regdom_saved()

2020-08-19 Thread Johannes Berg
On Tue, 2020-08-04 at 14:05 -0700, Rustam Kovhaev wrote:
> this warning can be triggered by userspace, so it should not cause a
> panic if panic_on_warn is set

This is incorrect, it just addresses a particular symptom. I'll make a
proper fix.

johannes



Re: [PATCH net-next v2 7/7] arm64: dts: mt7622: add mt7531 dsa to bananapi-bpi-r64 board

2020-08-19 Thread Vladimir Oltean
On Wed, Aug 19, 2020 at 04:15:01PM +0800, Landen Chao wrote:
> On Wed, 2020-08-19 at 00:24 +0800, Vladimir Oltean wrote:
> > On Tue, Aug 18, 2020 at 03:14:12PM +0800, Landen Chao wrote:
> > > Add mt7531 dsa to bananapi-bpi-r64 board for 5 giga Ethernet ports 
> > > support.
> > > 
> > > Signed-off-by: Landen Chao 
> > > ---
> > >  .../dts/mediatek/mt7622-bananapi-bpi-r64.dts  | 44 +++
> > >  1 file changed, 44 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts 
> > > b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> > > index d174ad214857..c57b2571165f 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> > > +++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts
> > > @@ -143,6 +143,50 @@
> > >   mdio: mdio-bus {
> > >   #address-cells = <1>;
> > >   #size-cells = <0>;
> > > +
> > > + switch@0 {
> > > + compatible = "mediatek,mt7531";
> > > +
> [snip]
> > > + port@6 {
> > > + reg = <6>;
> > > + label = "cpu";
> > > + ethernet = <&gmac0>;
> > > + phy-mode = "2500base-x";
> > > + };
> > 
> > Is there any reason why you're not specifying a fixed-link node here?
> I got the below feedback in v1, so I follow the DSA common design in v2.
> v2 can work with fixed-link node or without fixed-link node in CPU port
> node.
> 
>   "This fixed-link should not be needed. The DSA driver is supposed to
>configure the CPU port to its fastest speed by default. 2500 is
>the fastest speed a 2500Base-X link can do..."

See this discussion and the replies to it:

https://www.spinics.net/lists/netdev/msg630102.html

I think if mt7530 is using phylink for non-netdev ports (and it is), it
would be good to have standard bindings that phylink can parse. For
example, in lack of a "pause" specifier, will the CPU port use flow
control or won't it? Why? I think there's simply no good reason why
you'd omit 3 more lines now.

> > > + };
> > > + };
> > > +
> > >   };
> > >  };
> > >  
> > > -- 
> > > 2.17.1
> > 
> > Thanks,
> > -Vladimir
> 

-Vladimir


Re: 答复: 答复: [Intel-wired-lan] [PATCH 0/2] intel/xdp fixes for fliping rx buffer

2020-08-19 Thread Björn Töpel

On 2020-08-19 10:31, Björn Töpel wrote:
[...]


But please, try to reproduce with a newer kernel.



Also, you are *sure* that you're touching stale data? Have you tried 
running with CONFIG_DEBUG_PAGEALLOC and CONFIG_PAGE_POISONING?



Björn


Re: WARNING: suspicious RCU usage in tipc_l2_send_msg

2020-08-19 Thread Xin Long
On Sat, Jun 27, 2020 at 1:25 AM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:b835a71e usbnet: smsc95xx: Fix use-after-free after removal
> git tree:   net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1095a51d10
> kernel config:  https://syzkaller.appspot.com/x/.config?x=dcc6334acae363d4
> dashboard link: https://syzkaller.appspot.com/bug?extid=47bbc6b678d317cccbe0
> compiler:   gcc (GCC) 10.1.0-syz 20200507
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+47bbc6b678d317ccc...@syzkaller.appspotmail.com
>
> =
> WARNING: suspicious RCU usage
> 5.8.0-rc1-syzkaller #0 Not tainted
> -
> net/tipc/bearer.c:466 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 1
> 2 locks held by kworker/0:16/19143:
>  #0: 8880a6901d38 ((wq_completion)cryptd){+.+.}-{0:0}, at: 
> arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
>  #0: 8880a6901d38 ((wq_completion)cryptd){+.+.}-{0:0}, at: atomic64_set 
> include/asm-generic/atomic-instrumented.h:856 [inline]
>  #0: 8880a6901d38 ((wq_completion)cryptd){+.+.}-{0:0}, at: 
> atomic_long_set include/asm-generic/atomic-long.h:41 [inline]
>  #0: 8880a6901d38 ((wq_completion)cryptd){+.+.}-{0:0}, at: set_work_data 
> kernel/workqueue.c:616 [inline]
>  #0: 8880a6901d38 ((wq_completion)cryptd){+.+.}-{0:0}, at: 
> set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
>  #0: 8880a6901d38 ((wq_completion)cryptd){+.+.}-{0:0}, at: 
> process_one_work+0x82b/0x1670 kernel/workqueue.c:2240
>  #1: c90006f9fda8 ((work_completion)(&cpu_queue->work)){+.+.}-{0:0}, at: 
> process_one_work+0x85f/0x1670 kernel/workqueue.c:2244
>
> stack backtrace:
> CPU: 0 PID: 19143 Comm: kworker/0:16 Not tainted 5.8.0-rc1-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Workqueue: cryptd cryptd_queue_worker
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x18f/0x20d lib/dump_stack.c:118
>  tipc_l2_send_msg+0x354/0x420 net/tipc/bearer.c:466
>  tipc_aead_encrypt_done+0x204/0x3a0 net/tipc/crypto.c:761
>  cryptd_aead_crypt+0xe8/0x1d0 crypto/cryptd.c:739
>  cryptd_queue_worker+0x118/0x1b0 crypto/cryptd.c:181
>  process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
>  worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
>  kthread+0x3b5/0x4a0 kernel/kthread.c:291
>  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
>
Like in bearer.c, rcu_read_lock() is needed before calling
b->media->send_msg() in tipc_aead_encrypt_done():

@@ -757,10 +757,12 @@ static void tipc_aead_encrypt_done(struct
crypto_async_request *base, int err)
switch (err) {
case 0:
this_cpu_inc(tx->stats->stat[STAT_ASYNC_OK]);
+   rcu_read_lock();
if (likely(test_bit(0, &b->up)))
b->media->send_msg(net, skb, b, &tx_ctx->dst);
else
kfree_skb(skb);
+   rcu_read_unlock();
break;
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.


Re: [PATCH net-next] Documentation/networking: update l2tp docs

2020-08-19 Thread James Chapman
On 18/08/2020 19:57, Jakub Kicinski wrote:
> On Tue, 18 Aug 2020 16:11:35 +0100 jchap...@katalix.com wrote:
>> From: James Chapman 
>>
>> Kernel documentation of L2TP has not been kept up to date and lacks
>> coverage of some L2TP APIs. While addressing this, refactor to improve
>> readability, separating the parts which focus on user APIs and
>> internal implementation into sections.
>>
>> Signed-off-by: James Chapman 
> Hi James, checkpatch --strict notices some trailing whitespace here:
>
> ERROR: trailing whitespace
> #301: FILE: Documentation/networking/l2tp.rst:177:
> +PW_TYPEYSets the pseudowire type. $
>
> ERROR: trailing whitespace
> #348: FILE: Documentation/networking/l2tp.rst:224:
> +CONN_IDNIdentifies the tunnel id to be queried. Ignored 
> for DUMP requests.$
>
> total: 2 errors, 0 warnings, 0 checks, 927 lines checked
>
> Could you clean these up?

Ugh, I should have checked this. I'll spin a v2.




[PATCH V2 net 0/3] Bug fixes for ENA ethernet driver

2020-08-19 Thread Shay Agroskin
This series adds the following:
- Fix undesired call to ena_restore after returning from suspend
- Fix condition inside a WARN_ON
- Fix overriding previous value when updating missed_tx statistic

v1->v2:
- fix bug when calling reset routine after device resources are freed (Jakub)

Shay Agroskin (3):
  net: ena: Prevent reset after device destruction
  net: ena: Change WARN_ON expression in ena_del_napi_in_range()
  net: ena: Make missed_tx stat incremental

 drivers/net/ethernet/amazon/ena/ena_netdev.c | 35 ++--
 1 file changed, 18 insertions(+), 17 deletions(-)

-- 
2.17.1



[PATCH V2 net 3/3] net: ena: Make missed_tx stat incremental

2020-08-19 Thread Shay Agroskin
Most statistics in ena driver are incremented, meaning that a stat's
value is a sum of all increases done to it since driver/queue
initialization.

This patch makes all statistics this way, effectively making missed_tx
statistic incremental.
Also added a comment regarding rx_drops and tx_drops to make it
clearer how these counters are calculated.

Fixes: 11095fdb712b ("net: ena: add statistics for missed tx packets")
Signed-off-by: Shay Agroskin 
---
 drivers/net/ethernet/amazon/ena/ena_netdev.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c 
b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 233db15c970d..a3a8edf9a734 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -3687,7 +3687,7 @@ static int check_missing_comp_in_tx_queue(struct 
ena_adapter *adapter,
}
 
u64_stats_update_begin(&tx_ring->syncp);
-   tx_ring->tx_stats.missed_tx = missed_tx;
+   tx_ring->tx_stats.missed_tx += missed_tx;
u64_stats_update_end(&tx_ring->syncp);
 
return rc;
@@ -4556,6 +4556,9 @@ static void ena_keep_alive_wd(void *adapter_data,
tx_drops = ((u64)desc->tx_drops_high << 32) | desc->tx_drops_low;
 
u64_stats_update_begin(&adapter->syncp);
+   /* These stats are accumulated by the device, so the counters indicate
+* all drops since last reset.
+*/
adapter->dev_stats.rx_drops = rx_drops;
adapter->dev_stats.tx_drops = tx_drops;
u64_stats_update_end(&adapter->syncp);
-- 
2.17.1



[PATCH V2 net 2/3] net: ena: Change WARN_ON expression in ena_del_napi_in_range()

2020-08-19 Thread Shay Agroskin
The ena_del_napi_in_range() function unregisters the napi handler for
rings in a given range.
This function had the following WARN_ON macro:

WARN_ON(ENA_IS_XDP_INDEX(adapter, i) &&
adapter->ena_napi[i].xdp_ring);

This macro prints the call stack if the expression inside of it is
true [1], but the expression inside of it is the wanted situation.
The expression checks whether the ring has an XDP queue and its index
corresponds to a XDP one.

This patch changes the expression to
!ENA_IS_XDP_INDEX(adapter, i) && adapter->ena_napi[i].xdp_ring
which indicates an unwanted situation.

Also, change the structure of the function. The napi handler is
unregistered for all rings, and so there's no need to check whether the
index is an XDP index or not. By removing this check the code becomes
much more readable.

Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action")
Signed-off-by: Shay Agroskin 
---
 drivers/net/ethernet/amazon/ena/ena_netdev.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c 
b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 44aeace196f0..233db15c970d 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -2180,13 +2180,10 @@ static void ena_del_napi_in_range(struct ena_adapter 
*adapter,
int i;
 
for (i = first_index; i < first_index + count; i++) {
-   /* Check if napi was initialized before */
-   if (!ENA_IS_XDP_INDEX(adapter, i) ||
-   adapter->ena_napi[i].xdp_ring)
-   netif_napi_del(&adapter->ena_napi[i].napi);
-   else
-   WARN_ON(ENA_IS_XDP_INDEX(adapter, i) &&
-   adapter->ena_napi[i].xdp_ring);
+   netif_napi_del(&adapter->ena_napi[i].napi);
+
+   WARN_ON(!ENA_IS_XDP_INDEX(adapter, i) &&
+   adapter->ena_napi[i].xdp_ring);
}
 }
 
-- 
2.17.1



[PATCH V2 net 1/3] net: ena: Prevent reset after device destruction

2020-08-19 Thread Shay Agroskin
The reset work is scheduled by the timer routine whenever it
detects that a device reset is required (e.g. when a keep_alive signal
is missing).
When releasing device resources in ena_destroy_device() the driver cancels the
scheduling of the timer routine without destroying the reset
work explicitly.

This creates the following bug:
The driver is suspended and the ena_suspend() function is called
-> This function calls ena_destroy_device() to free the net device
   resources
-> The driver waits for the timer routine to finish
its execution and then cancels it, thus preventing from it
to be called again.

If, in its final execution, the timer routine schedules a reset,
the reset routine might be called afterwards, and a redundant call to
ena_restore_device() would be made.

By changing the reset routine we allow it to read the device's state
accurately.
This is achieved by checking whether ENA_FLAG_TRIGGER_RESET flag is set
before resetting the device and making both the destruction function and
the flag check are under rtnl lock.
The ENA_FLAG_TRIGGER_RESET is cleared at the end of the destruction
routine. Also surround the flag check with 'likely' because
we expect that the reset routine would be called only when
ENA_FLAG_TRIGGER_RESET flag is set.

The destruction of the timer and reset services in __ena_shutoff() have to
stay, even though the timer routine is destroyed in ena_destroy_device().
This is to avoid a case in which the reset routine is scheduled after
free_netdev() in __ena_shutoff(), which would create an access to freed
memory in adapter->flags.

Fixes: 84a629e ("[New feature] ena_netdev: Add hibernation support")
Signed-off-by: Shay Agroskin 
---
 drivers/net/ethernet/amazon/ena/ena_netdev.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c 
b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index 2a6c9725e092..44aeace196f0 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -3601,16 +3601,14 @@ static void ena_fw_reset_device(struct work_struct 
*work)
 {
struct ena_adapter *adapter =
container_of(work, struct ena_adapter, reset_task);
-   struct pci_dev *pdev = adapter->pdev;
 
-   if (unlikely(!test_bit(ENA_FLAG_TRIGGER_RESET, &adapter->flags))) {
-   dev_err(&pdev->dev,
-   "device reset schedule while reset bit is off\n");
-   return;
-   }
rtnl_lock();
-   ena_destroy_device(adapter, false);
-   ena_restore_device(adapter);
+
+   if (likely(test_bit(ENA_FLAG_TRIGGER_RESET, &adapter->flags))) {
+   ena_destroy_device(adapter, false);
+   ena_restore_device(adapter);
+   }
+
rtnl_unlock();
 }
 
@@ -4389,8 +4387,11 @@ static void __ena_shutoff(struct pci_dev *pdev, bool 
shutdown)
netdev->rx_cpu_rmap = NULL;
}
 #endif /* CONFIG_RFS_ACCEL */
-   del_timer_sync(&adapter->timer_service);
 
+   /* Make sure timer and reset routine won't be called after
+* freeing device resources.
+*/
+   del_timer_sync(&adapter->timer_service);
cancel_work_sync(&adapter->reset_task);
 
rtnl_lock(); /* lock released inside the below if-else block */
-- 
2.17.1



[PATCH net-next v2] Documentation/networking: update l2tp docs

2020-08-19 Thread jchapman
From: James Chapman 

Kernel documentation of L2TP has not been kept up to date and lacks
coverage of some L2TP APIs. While addressing this, refactor to improve
readability, separating the parts which focus on user APIs and
internal implementation into sections.

Changes in v2:

 - fix checkpatch warnings about trailing whitespace and long lines

Signed-off-by: James Chapman 
---
 Documentation/networking/l2tp.rst | 922 --
 1 file changed, 625 insertions(+), 297 deletions(-)

diff --git a/Documentation/networking/l2tp.rst 
b/Documentation/networking/l2tp.rst
index a48238a2ec09..693ea0e3ec26 100644
--- a/Documentation/networking/l2tp.rst
+++ b/Documentation/networking/l2tp.rst
@@ -4,124 +4,364 @@
 L2TP
 
 
-This document describes how to use the kernel's L2TP drivers to
-provide L2TP functionality. L2TP is a protocol that tunnels one or
-more sessions over an IP tunnel. It is commonly used for VPNs
-(L2TP/IPSec) and by ISPs to tunnel subscriber PPP sessions over an IP
-network infrastructure. With L2TPv3, it is also useful as a Layer-2
-tunneling infrastructure.
-
-Features
+Layer 2 Tunneling Protocol (L2TP) allows L2 frames to be tunneled over
+an IP network.
+
+This document covers the kernel's L2TP subsystem. It documents kernel
+APIs for application developers who want to use the L2TP subsystem and
+it provides some technical details about the internal implementation
+which may be useful to kernel developers and maintainers.
+
+Overview
 
 
-L2TPv2 (PPP over L2TP (UDP tunnels)).
-L2TPv3 ethernet pseudowires.
-L2TPv3 PPP pseudowires.
-L2TPv3 IP encapsulation.
-Netlink sockets for L2TPv3 configuration management.
-
-History
-===
-
-The original pppol2tp driver was introduced in 2.6.23 and provided
-L2TPv2 functionality (rfc2661). L2TPv2 is used to tunnel one or more PPP
-sessions over a UDP tunnel.
-
-L2TPv3 (rfc3931) changes the protocol to allow different frame types
-to be passed over an L2TP tunnel by moving the PPP-specific parts of
-the protocol out of the core L2TP packet headers. Each frame type is
-known as a pseudowire type. Ethernet, PPP, HDLC, Frame Relay and ATM
-pseudowires for L2TP are defined in separate RFC standards. Another
-change for L2TPv3 is that it can be carried directly over IP with no
-UDP header (UDP is optional). It is also possible to create static
-unmanaged L2TPv3 tunnels manually without a control protocol
-(userspace daemon) to manage them.
-
-To support L2TPv3, the original pppol2tp driver was split up to
-separate the L2TP and PPP functionality. Existing L2TPv2 userspace
-apps should be unaffected as the original pppol2tp sockets API is
-retained. L2TPv3, however, uses netlink to manage L2TPv3 tunnels and
-sessions.
-
-Design
-==
-
-The L2TP protocol separates control and data frames.  The L2TP kernel
-drivers handle only L2TP data frames; control frames are always
-handled by userspace. L2TP control frames carry messages between L2TP
-clients/servers and are used to setup / teardown tunnels and
-sessions. An L2TP client or server is implemented in userspace.
-
-Each L2TP tunnel is implemented using a UDP or L2TPIP socket; L2TPIP
-provides L2TPv3 IP encapsulation (no UDP) and is implemented using a
-new l2tpip socket family. The tunnel socket is typically created by
-userspace, though for unmanaged L2TPv3 tunnels, the socket can also be
-created by the kernel. Each L2TP session (pseudowire) gets a network
-interface instance. In the case of PPP, these interfaces are created
-indirectly by pppd using a pppol2tp socket. In the case of ethernet,
-the netdevice is created upon a netlink request to create an L2TPv3
-ethernet pseudowire.
-
-For PPP, the PPPoL2TP driver, net/l2tp/l2tp_ppp.c, provides a
-mechanism by which PPP frames carried through an L2TP session are
-passed through the kernel's PPP subsystem. The standard PPP daemon,
-pppd, handles all PPP interaction with the peer. PPP network
-interfaces are created for each local PPP endpoint. The kernel's PPP
-subsystem arranges for PPP control frames to be delivered to pppd,
-while data frames are forwarded as usual.
-
-For ethernet, the L2TPETH driver, net/l2tp/l2tp_eth.c, implements a
-netdevice driver, managing virtual ethernet devices, one per
-pseudowire. These interfaces can be managed using standard Linux tools
-such as "ip" and "ifconfig". If only IP frames are passed over the
-tunnel, the interface can be given an IP addresses of itself and its
-peer. If non-IP frames are to be passed over the tunnel, the interface
-can be added to a bridge using brctl. All L2TP datapath protocol
-functions are handled by the L2TP core driver.
-
-Each tunnel and session within a tunnel is assigned a unique tunnel_id
-and session_id. These ids are carried in the L2TP header of every
-control and data packet. (Actually, in L2TPv3, the tunnel_id isn't
-present in data frames - it is inferred from the IP connection on
-which the packet was received.) The L2TP driver uses the ids to lo

[PATCH bpf-next] tools/resolve_btfids: Fix sections with wrong alignment

2020-08-19 Thread Jiri Olsa
The data of compressed section should be aligned to 4
(for 32bit) or 8 (for 64 bit) bytes.

The binutils ld sets sh_addralign to 1, which makes libelf
fail with misaligned section error during the update as
reported by Jesper:

   FAILED elf_update(WRITE): invalid section alignment

While waiting for ld fix, we can fix compressed sections
sh_addralign value manually.

Adding warning in -vv mode when the fix is triggered:

  $ ./tools/bpf/resolve_btfids/resolve_btfids -vv vmlinux
  ...
  section(36) .comment, size 44, link 0, flags 30, type=1
  section(37) .debug_aranges, size 45684, link 0, flags 800, type=1
   - fixing wrong alignment sh_addralign 16, expected 8
  section(38) .debug_info, size 129104957, link 0, flags 800, type=1
   - fixing wrong alignment sh_addralign 1, expected 8
  section(39) .debug_abbrev, size 1152583, link 0, flags 800, type=1
   - fixing wrong alignment sh_addralign 1, expected 8
  section(40) .debug_line, size 7374522, link 0, flags 800, type=1
   - fixing wrong alignment sh_addralign 1, expected 8
  section(41) .debug_frame, size 702463, link 0, flags 800, type=1
  section(42) .debug_str, size 1017571, link 0, flags 830, type=1
   - fixing wrong alignment sh_addralign 1, expected 8
  section(43) .debug_loc, size 3019453, link 0, flags 800, type=1
   - fixing wrong alignment sh_addralign 1, expected 8
  section(44) .debug_ranges, size 1744583, link 0, flags 800, type=1
   - fixing wrong alignment sh_addralign 16, expected 8
  section(45) .symtab, size 2955888, link 46, flags 0, type=2
  section(46) .strtab, size 2613072, link 0, flags 0, type=3
  ...
  update ok for vmlinux

Another workaround is to disable compressed debug info data
CONFIG_DEBUG_INFO_COMPRESSED kernel option.

Fixes: fbbb68de80a4 ("bpf: Add resolve_btfids tool to resolve BTF IDs in ELF 
object")
Cc: Mark Wielaard 
Cc: Nick Clifton 
Reported-by: Jesper Dangaard Brouer 
Signed-off-by: Jiri Olsa 
---
 tools/bpf/resolve_btfids/main.c | 36 +
 1 file changed, 36 insertions(+)

diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
index 4d9ecb975862..0def0bb1f783 100644
--- a/tools/bpf/resolve_btfids/main.c
+++ b/tools/bpf/resolve_btfids/main.c
@@ -233,6 +233,39 @@ static struct btf_id *add_symbol(struct rb_root *root, 
char *name, size_t size)
return btf_id__add(root, id, false);
 }
 
+/*
+ * The data of compressed section should be aligned to 4
+ * (for 32bit) or 8 (for 64 bit) bytes. The binutils ld
+ * sets sh_addralign to 1, which makes libelf fail with
+ * misaligned section error during the update:
+ *FAILED elf_update(WRITE): invalid section alignment
+ *
+ * While waiting for ld fix, we fix the compressed sections
+ * sh_addralign value manualy.
+ */
+static int compressed_section_fix(Elf *elf, Elf_Scn *scn, GElf_Shdr *sh)
+{
+   int expected = gelf_getclass(elf) == ELFCLASS32 ? 4 : 8;
+
+   if (!(sh->sh_flags & SHF_COMPRESSED))
+   return 0;
+
+   if (sh->sh_addralign == expected)
+   return 0;
+
+   pr_debug2(" - fixing wrong alignment sh_addralign %u, expected %u\n",
+ sh->sh_addralign, expected);
+
+   sh->sh_addralign = expected;
+
+   if (gelf_update_shdr(scn, sh) == 0) {
+   printf("FAILED cannot update section header: %s\n",
+   elf_errmsg(-1));
+   return -1;
+   }
+   return 0;
+}
+
 static int elf_collect(struct object *obj)
 {
Elf_Scn *scn = NULL;
@@ -309,6 +342,9 @@ static int elf_collect(struct object *obj)
obj->efile.idlist_shndx = idx;
obj->efile.idlist_addr  = sh.sh_addr;
}
+
+   if (compressed_section_fix(elf, scn, &sh))
+   return -1;
}
 
return 0;
-- 
2.25.4



xdp generic default option

2020-08-19 Thread Lorenzo Bianconi
Hi Andrii,

working on xdp multi-buff I figured out now xdp generic is the default choice
if not specified by userspace. In particular after commit 7f0a838254bd
("bpf, xdp: Maintain info on attached XDP BPF programs in net_device"), running
the command below, XDP will run in generic mode even if the underlay driver
support XDP in native mode:

$ip link set dev eth0 xdp obj prog.o
$ip link show dev eth0
2: eth0:  mtu 1500 xdpgeneric qdisc mq state 
UP mode DEFAULT
   group default qlen 1024
   link/ether f0:ad:4e:09:6b:57 brd ff:ff:ff:ff:ff:ff
   prog/xdp id 1 tag 3b185187f1855c4c jited 

Is it better to use xdpdrv as default choice if not specified by userspace?
doing something like:

diff --git a/net/core/dev.c b/net/core/dev.c
index a00aa737ce29..1f85880ee412 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8747,9 +8747,9 @@ static enum bpf_xdp_mode dev_xdp_mode(u32 flags)
 {
if (flags & XDP_FLAGS_HW_MODE)
return XDP_MODE_HW;
-   if (flags & XDP_FLAGS_DRV_MODE)
-   return XDP_MODE_DRV;
-   return XDP_MODE_SKB;
+   if (flags & XDP_FLAGS_SKB_MODE)
+   return XDP_MODE_SKB;
+   return XDP_MODE_DRV;
 }
 
 static bpf_op_t dev_xdp_bpf_op(struct net_device *dev, enum bpf_xdp_mode mode)

Regards,
Lorenzo


signature.asc
Description: PGP signature


[PATCH bpf-next 0/6] Allow updating sockmap / sockhash from BPF

2020-08-19 Thread Lorenz Bauer
We're currently building a control plane for our BPF socket dispatch
work. As part of that, we have a need to create a copy of an existing
sockhash, to allow us to change the keys. I previously proposed allowing
privileged userspace to look up sockets, which doesn't work due to
security concerns (see [1]).

In follow up discussions during BPF office hours we identified bpf_iter
as a possible solution: instead of accessing sockets from user space
we can iterate the source sockhash, and insert the values into a new
map. Enabling this requires two pieces: the ability to iterate
sockmap and sockhash, as well as being able to call map_update_elem
from BPF.

This patch set implements the latter: it's now possible to update
sockmap from BPF context. As a next step, we can implement bpf_iter
for sockmap.

The patches are organised as follows:
* Patches 1-3 are cleanups and simplifications, to make reasoning
  about the subsequent patches easier.
* Patch 4 makes map_update_elem return a PTR_TO_SOCKET_OR_NULL for
  sockmap / sockhash lookups.
* Patch 5 enables map_update_elem from BPF. There is some locking
  here that I'm not entirely sure about. Feedback much appreciated.
* Patch 6 adds a selftest.

1: https://lore.kernel.org/bpf/20200310174711.7490-1-...@cloudflare.com/

Lorenz Bauer (6):
  net: sk_msg: simplify sk_psock initialization
  bpf: sockmap: merge sockmap and sockhash update functions
  bpf: sockmap: call sock_map_update_elem directly
  bpf: override the meaning of ARG_PTR_TO_MAP_VALUE for sockmap and
sockhash
  bpf: sockmap: allow update from BPF
  selftests: bpf: test sockmap update from BPF

 include/linux/bpf.h   |   7 +
 include/linux/skmsg.h |  17 ---
 kernel/bpf/syscall.c  |   5 +-
 kernel/bpf/verifier.c |  46 +-
 net/core/skmsg.c  |  34 -
 net/core/sock_map.c   | 137 --
 net/ipv4/tcp_bpf.c|  13 +-
 net/ipv4/udp_bpf.c|   9 +-
 .../selftests/bpf/prog_tests/sockmap_basic.c  |  76 ++
 .../selftests/bpf/progs/test_sockmap_copy.c   |  48 ++
 10 files changed, 274 insertions(+), 118 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/test_sockmap_copy.c

-- 
2.25.1



[PATCH bpf-next 1/6] net: sk_msg: simplify sk_psock initialization

2020-08-19 Thread Lorenz Bauer
Initializing psock->sk_proto and other saved callbacks is only
done in sk_psock_update_proto, after sk_psock_init has returned.
The logic for this is difficult to follow, and needlessly complex.

Instead, initialize psock->sk_proto whenever we allocate a new
psock. Additionally, assert the following invariants:

* The SK has no ULP: ULP does it's own finagling of sk->sk_prot
* sk_user_data is unused: we need it to store sk_psock

Protect our access to sk_user_data with sk_callback_lock, which
is what other users like reuseport arrays, etc. do.

The result is that an sk_psock is always fully initialized, and
that psock->sk_proto is always the "original" struct proto.
The latter allows us to use psock->sk_proto when initializing
IPv6 TCP / UDP callbacks for sockmap.

Signed-off-by: Lorenz Bauer 
---
 include/linux/skmsg.h | 17 -
 net/core/skmsg.c  | 34 --
 net/core/sock_map.c   | 14 --
 net/ipv4/tcp_bpf.c| 13 +
 net/ipv4/udp_bpf.c|  9 -
 5 files changed, 41 insertions(+), 46 deletions(-)

diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h
index 1e9ed840b9fc..3119928fc103 100644
--- a/include/linux/skmsg.h
+++ b/include/linux/skmsg.h
@@ -340,23 +340,6 @@ static inline void sk_psock_update_proto(struct sock *sk,
 struct sk_psock *psock,
 struct proto *ops)
 {
-   /* Initialize saved callbacks and original proto only once, since this
-* function may be called multiple times for a psock, e.g. when
-* psock->progs.msg_parser is updated.
-*
-* Since we've not installed the new proto, psock is not yet in use and
-* we can initialize it without synchronization.
-*/
-   if (!psock->sk_proto) {
-   struct proto *orig = READ_ONCE(sk->sk_prot);
-
-   psock->saved_unhash = orig->unhash;
-   psock->saved_close = orig->close;
-   psock->saved_write_space = sk->sk_write_space;
-
-   psock->sk_proto = orig;
-   }
-
/* Pairs with lockless read in sk_clone_lock() */
WRITE_ONCE(sk->sk_prot, ops);
 }
diff --git a/net/core/skmsg.c b/net/core/skmsg.c
index 6a32a1fd34f8..1c81caf9630f 100644
--- a/net/core/skmsg.c
+++ b/net/core/skmsg.c
@@ -494,14 +494,34 @@ static void sk_psock_backlog(struct work_struct *work)
 
 struct sk_psock *sk_psock_init(struct sock *sk, int node)
 {
-   struct sk_psock *psock = kzalloc_node(sizeof(*psock),
- GFP_ATOMIC | __GFP_NOWARN,
- node);
-   if (!psock)
-   return NULL;
+   struct sk_psock *psock;
+   struct proto *prot;
 
+   write_lock_bh(&sk->sk_callback_lock);
+
+   if (inet_csk_has_ulp(sk)) {
+   psock = ERR_PTR(-EINVAL);
+   goto out;
+   }
+
+   if (sk->sk_user_data) {
+   psock = ERR_PTR(-EBUSY);
+   goto out;
+   }
+
+   psock = kzalloc_node(sizeof(*psock), GFP_ATOMIC | __GFP_NOWARN, node);
+   if (!psock) {
+   psock = ERR_PTR(-ENOMEM);
+   goto out;
+   }
+
+   prot = READ_ONCE(sk->sk_prot);
psock->sk = sk;
-   psock->eval =  __SK_NONE;
+   psock->eval = __SK_NONE;
+   psock->sk_proto = prot;
+   psock->saved_unhash = prot->unhash;
+   psock->saved_close = prot->close;
+   psock->saved_write_space = sk->sk_write_space;
 
INIT_LIST_HEAD(&psock->link);
spin_lock_init(&psock->link_lock);
@@ -516,6 +536,8 @@ struct sk_psock *sk_psock_init(struct sock *sk, int node)
rcu_assign_sk_user_data_nocopy(sk, psock);
sock_hold(sk);
 
+out:
+   write_unlock_bh(&sk->sk_callback_lock);
return psock;
 }
 EXPORT_SYMBOL_GPL(sk_psock_init);
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 119f52a99dc1..abe4bac40db9 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -184,8 +184,6 @@ static int sock_map_init_proto(struct sock *sk, struct 
sk_psock *psock)
 {
struct proto *prot;
 
-   sock_owned_by_me(sk);
-
switch (sk->sk_type) {
case SOCK_STREAM:
prot = tcp_bpf_get_proto(sk, psock);
@@ -272,8 +270,8 @@ static int sock_map_link(struct bpf_map *map, struct 
sk_psock_progs *progs,
}
} else {
psock = sk_psock_init(sk, map->numa_node);
-   if (!psock) {
-   ret = -ENOMEM;
+   if (IS_ERR(psock)) {
+   ret = PTR_ERR(psock);
goto out_progs;
}
}
@@ -322,8 +320,8 @@ static int sock_map_link_no_progs(struct bpf_map *map, 
struct sock *sk)
 
if (!psock) {
psock = sk_psock_init(sk, map->numa_node);
-   if (!psock)
-   return -ENOMEM;
+   i

[PATCH bpf-next 5/6] bpf: sockmap: allow update from BPF

2020-08-19 Thread Lorenz Bauer
Allow calling bpf_map_update_elem on sockmap and sockhash from a BPF
context. The synchronization required for this is a bit fiddly: we
need to prevent the socket from changing it's state while we add it
to the sockmap, since we rely on getting a callback via
sk_prot->unhash. However, we can't just lock_sock like in
sock_map_sk_acquire because that might sleep. So instead we disable
softirq processing and use bh_lock_sock to prevent further
modification.

Signed-off-by: Lorenz Bauer 
---
 kernel/bpf/verifier.c |  6 --
 net/core/sock_map.c   | 24 
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 47f9b94bb9d4..421fccf18dea 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -4254,7 +4254,8 @@ static int check_map_func_compatibility(struct 
bpf_verifier_env *env,
func_id != BPF_FUNC_map_delete_elem &&
func_id != BPF_FUNC_msg_redirect_map &&
func_id != BPF_FUNC_sk_select_reuseport &&
-   func_id != BPF_FUNC_map_lookup_elem)
+   func_id != BPF_FUNC_map_lookup_elem &&
+   func_id != BPF_FUNC_map_update_elem)
goto error;
break;
case BPF_MAP_TYPE_SOCKHASH:
@@ -4263,7 +4264,8 @@ static int check_map_func_compatibility(struct 
bpf_verifier_env *env,
func_id != BPF_FUNC_map_delete_elem &&
func_id != BPF_FUNC_msg_redirect_hash &&
func_id != BPF_FUNC_sk_select_reuseport &&
-   func_id != BPF_FUNC_map_lookup_elem)
+   func_id != BPF_FUNC_map_lookup_elem &&
+   func_id != BPF_FUNC_map_update_elem)
goto error;
break;
case BPF_MAP_TYPE_REUSEPORT_SOCKARRAY:
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 018367fb889f..b2c886c34566 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -603,6 +603,28 @@ int sock_map_update_elem_sys(struct bpf_map *map, void 
*key,
return ret;
 }
 
+static int sock_map_update_elem(struct bpf_map *map, void *key,
+   void *value, u64 flags)
+{
+   struct sock *sk = (struct sock *)value;
+   int ret;
+
+   if (!sock_map_sk_is_suitable(sk))
+   return -EOPNOTSUPP;
+
+   local_bh_disable();
+   bh_lock_sock(sk);
+   if (!sock_map_sk_state_allowed(sk))
+   ret = -EOPNOTSUPP;
+   else if (map->map_type == BPF_MAP_TYPE_SOCKMAP)
+   ret = sock_map_update_common(map, *(u32 *)key, sk, flags);
+   else
+   ret = sock_hash_update_common(map, key, sk, flags);
+   bh_unlock_sock(sk);
+   local_bh_enable();
+   return ret;
+}
+
 BPF_CALL_4(bpf_sock_map_update, struct bpf_sock_ops_kern *, sops,
   struct bpf_map *, map, void *, key, u64, flags)
 {
@@ -687,6 +709,7 @@ const struct bpf_map_ops sock_map_ops = {
.map_free   = sock_map_free,
.map_get_next_key   = sock_map_get_next_key,
.map_lookup_elem_sys_only = sock_map_lookup_sys,
+   .map_update_elem= sock_map_update_elem,
.map_delete_elem= sock_map_delete_elem,
.map_lookup_elem= sock_map_lookup,
.map_release_uref   = sock_map_release_progs,
@@ -1180,6 +1203,7 @@ const struct bpf_map_ops sock_hash_ops = {
.map_alloc  = sock_hash_alloc,
.map_free   = sock_hash_free,
.map_get_next_key   = sock_hash_get_next_key,
+   .map_update_elem= sock_map_update_elem,
.map_delete_elem= sock_hash_delete_elem,
.map_lookup_elem= sock_hash_lookup,
.map_lookup_elem_sys_only = sock_hash_lookup_sys,
-- 
2.25.1



[PATCH bpf-next 3/6] bpf: sockmap: call sock_map_update_elem directly

2020-08-19 Thread Lorenz Bauer
Don't go via map->ops to call sock_map_update_elem, since we know
what function to call in bpf_map_update_value. Since
check_map_func_compatibility doesn't allow calling
BPF_FUNC_map_update_elem from BPF context, we can remove
ops->map_update_elem and rename the function to
sock_map_update_elem_sys.

Signed-off-by: Lorenz Bauer 
---
 include/linux/bpf.h  | 7 +++
 kernel/bpf/syscall.c | 5 +++--
 net/core/sock_map.c  | 6 ++
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index cef4ef0d2b4e..cf3416d1b8c2 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1635,6 +1635,7 @@ int sock_map_prog_update(struct bpf_map *map, struct 
bpf_prog *prog,
 struct bpf_prog *old, u32 which);
 int sock_map_get_from_fd(const union bpf_attr *attr, struct bpf_prog *prog);
 int sock_map_prog_detach(const union bpf_attr *attr, enum bpf_prog_type ptype);
+int sock_map_update_elem_sys(struct bpf_map *map, void *key, void *value, u64 
flags);
 void sock_map_unhash(struct sock *sk);
 void sock_map_close(struct sock *sk, long timeout);
 #else
@@ -1656,6 +1657,12 @@ static inline int sock_map_prog_detach(const union 
bpf_attr *attr,
 {
return -EOPNOTSUPP;
 }
+
+static inline int sock_map_update_elem_sys(struct bpf_map *map, void *key, 
void *value,
+  u64 flags)
+{
+   return -EOPNOTSUPP;
+}
 #endif /* CONFIG_BPF_STREAM_PARSER */
 
 #if defined(CONFIG_INET) && defined(CONFIG_BPF_SYSCALL)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 2f343ce15747..5867cf615a3c 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -157,10 +157,11 @@ static int bpf_map_update_value(struct bpf_map *map, 
struct fd f, void *key,
if (bpf_map_is_dev_bound(map)) {
return bpf_map_offload_update_elem(map, key, value, flags);
} else if (map->map_type == BPF_MAP_TYPE_CPUMAP ||
-  map->map_type == BPF_MAP_TYPE_SOCKHASH ||
-  map->map_type == BPF_MAP_TYPE_SOCKMAP ||
   map->map_type == BPF_MAP_TYPE_STRUCT_OPS) {
return map->ops->map_update_elem(map, key, value, flags);
+   } else if (map->map_type == BPF_MAP_TYPE_SOCKHASH ||
+  map->map_type == BPF_MAP_TYPE_SOCKMAP) {
+   return sock_map_update_elem_sys(map, key, value, flags);
} else if (IS_FD_PROG_ARRAY(map)) {
return bpf_fd_array_map_update_elem(map, f.file, key, value,
flags);
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index f464a0ebc871..018367fb889f 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -562,8 +562,8 @@ static bool sock_map_sk_state_allowed(const struct sock *sk)
 static int sock_hash_update_common(struct bpf_map *map, void *key,
   struct sock *sk, u64 flags);
 
-int sock_map_update_elem(struct bpf_map *map, void *key,
-void *value, u64 flags)
+int sock_map_update_elem_sys(struct bpf_map *map, void *key,
+void *value, u64 flags)
 {
struct socket *sock;
struct sock *sk;
@@ -687,7 +687,6 @@ const struct bpf_map_ops sock_map_ops = {
.map_free   = sock_map_free,
.map_get_next_key   = sock_map_get_next_key,
.map_lookup_elem_sys_only = sock_map_lookup_sys,
-   .map_update_elem= sock_map_update_elem,
.map_delete_elem= sock_map_delete_elem,
.map_lookup_elem= sock_map_lookup,
.map_release_uref   = sock_map_release_progs,
@@ -1181,7 +1180,6 @@ const struct bpf_map_ops sock_hash_ops = {
.map_alloc  = sock_hash_alloc,
.map_free   = sock_hash_free,
.map_get_next_key   = sock_hash_get_next_key,
-   .map_update_elem= sock_map_update_elem,
.map_delete_elem= sock_hash_delete_elem,
.map_lookup_elem= sock_hash_lookup,
.map_lookup_elem_sys_only = sock_hash_lookup_sys,
-- 
2.25.1



[PATCH bpf-next 6/6] selftests: bpf: test sockmap update from BPF

2020-08-19 Thread Lorenz Bauer
Add a test which copies a socket from a sockmap into another sockmap
or sockhash. This excercises bpf_map_update_elem support from BPF
context. Compare the socket cookies from source and destination to
ensure that the copy succeeded.

Signed-off-by: Lorenz Bauer 
---
 .../selftests/bpf/prog_tests/sockmap_basic.c  | 76 +++
 .../selftests/bpf/progs/test_sockmap_copy.c   | 48 
 2 files changed, 124 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/progs/test_sockmap_copy.c

diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c 
b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
index 96e7b7f84c65..d30cabc00e9e 100644
--- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
@@ -4,6 +4,7 @@
 
 #include "test_progs.h"
 #include "test_skmsg_load_helpers.skel.h"
+#include "test_sockmap_copy.skel.h"
 
 #define TCP_REPAIR 19  /* TCP sock is under repair right now */
 
@@ -101,6 +102,77 @@ static void test_skmsg_helpers(enum bpf_map_type map_type)
test_skmsg_load_helpers__destroy(skel);
 }
 
+static void test_sockmap_copy(enum bpf_map_type map_type)
+{
+   struct bpf_prog_test_run_attr attr;
+   struct test_sockmap_copy *skel;
+   __u64 src_cookie, dst_cookie;
+   int err, prog, s, src, dst;
+   const __u32 zero = 0;
+   char dummy[14] = {0};
+
+   s = connected_socket_v4();
+   if (CHECK_FAIL(s == -1))
+   return;
+
+   skel = test_sockmap_copy__open_and_load();
+   if (CHECK_FAIL(!skel)) {
+   close(s);
+   perror("test_sockmap_copy__open_and_load");
+   return;
+   }
+
+   prog = bpf_program__fd(skel->progs.copy_sock_map);
+   src = bpf_map__fd(skel->maps.src);
+   if (map_type == BPF_MAP_TYPE_SOCKMAP)
+   dst = bpf_map__fd(skel->maps.dst_sock_map);
+   else
+   dst = bpf_map__fd(skel->maps.dst_sock_hash);
+
+   err = bpf_map_update_elem(src, &zero, &s, BPF_NOEXIST);
+   if (CHECK_FAIL(err)) {
+   perror("bpf_map_update");
+   goto out;
+   }
+
+   err = bpf_map_lookup_elem(src, &zero, &src_cookie);
+   if (CHECK_FAIL(err)) {
+   perror("bpf_map_lookup_elem(src)");
+   goto out;
+   }
+
+   attr = (struct bpf_prog_test_run_attr){
+   .prog_fd = prog,
+   .repeat = 1,
+   .data_in = dummy,
+   .data_size_in = sizeof(dummy),
+   };
+
+   err = bpf_prog_test_run_xattr(&attr);
+   if (err) {
+   test__fail();
+   perror("bpf_prog_test_run");
+   goto out;
+   } else if (!attr.retval) {
+   PRINT_FAIL("bpf_prog_test_run: program returned %u\n",
+  attr.retval);
+   goto out;
+   }
+
+   err = bpf_map_lookup_elem(dst, &zero, &dst_cookie);
+   if (CHECK_FAIL(err)) {
+   perror("bpf_map_lookup_elem(dst)");
+   goto out;
+   }
+
+   if (dst_cookie != src_cookie)
+   PRINT_FAIL("cookie %llu != %llu\n", dst_cookie, src_cookie);
+
+out:
+   close(s);
+   test_sockmap_copy__destroy(skel);
+}
+
 void test_sockmap_basic(void)
 {
if (test__start_subtest("sockmap create_update_free"))
@@ -111,4 +183,8 @@ void test_sockmap_basic(void)
test_skmsg_helpers(BPF_MAP_TYPE_SOCKMAP);
if (test__start_subtest("sockhash sk_msg load helpers"))
test_skmsg_helpers(BPF_MAP_TYPE_SOCKHASH);
+   if (test__start_subtest("sockmap copy"))
+   test_sockmap_copy(BPF_MAP_TYPE_SOCKMAP);
+   if (test__start_subtest("sockhash copy"))
+   test_sockmap_copy(BPF_MAP_TYPE_SOCKHASH);
 }
diff --git a/tools/testing/selftests/bpf/progs/test_sockmap_copy.c 
b/tools/testing/selftests/bpf/progs/test_sockmap_copy.c
new file mode 100644
index ..9d0c9f28cab2
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/test_sockmap_copy.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020 Cloudflare
+#include "vmlinux.h"
+#include 
+
+struct {
+   __uint(type, BPF_MAP_TYPE_SOCKMAP);
+   __uint(max_entries, 1);
+   __type(key, __u32);
+   __type(value, __u64);
+} src SEC(".maps");
+
+struct {
+   __uint(type, BPF_MAP_TYPE_SOCKMAP);
+   __uint(max_entries, 1);
+   __type(key, __u32);
+   __type(value, __u64);
+} dst_sock_map SEC(".maps");
+
+struct {
+   __uint(type, BPF_MAP_TYPE_SOCKHASH);
+   __uint(max_entries, 1);
+   __type(key, __u32);
+   __type(value, __u64);
+} dst_sock_hash SEC(".maps");
+
+SEC("classifier/copy_sock_map")
+int copy_sock_map(void *ctx)
+{
+   struct bpf_sock *sk;
+   bool failed = false;
+   __u32 key = 0;
+
+   sk = bpf_map_lookup_elem(&src, &key);
+   if (!sk)
+   return SK_DROP;
+
+   if (bpf_map_

[PATCH bpf-next 2/6] bpf: sockmap: merge sockmap and sockhash update functions

2020-08-19 Thread Lorenz Bauer
Merge the two very similar functions sock_map_update_elem and
sock_hash_update_elem into one.

Signed-off-by: Lorenz Bauer 
---
 net/core/sock_map.c | 53 -
 1 file changed, 9 insertions(+), 44 deletions(-)

diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index abe4bac40db9..f464a0ebc871 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -559,10 +559,12 @@ static bool sock_map_sk_state_allowed(const struct sock 
*sk)
return false;
 }
 
-static int sock_map_update_elem(struct bpf_map *map, void *key,
-   void *value, u64 flags)
+static int sock_hash_update_common(struct bpf_map *map, void *key,
+  struct sock *sk, u64 flags);
+
+int sock_map_update_elem(struct bpf_map *map, void *key,
+void *value, u64 flags)
 {
-   u32 idx = *(u32 *)key;
struct socket *sock;
struct sock *sk;
int ret;
@@ -591,8 +593,10 @@ static int sock_map_update_elem(struct bpf_map *map, void 
*key,
sock_map_sk_acquire(sk);
if (!sock_map_sk_state_allowed(sk))
ret = -EOPNOTSUPP;
+   else if (map->map_type == BPF_MAP_TYPE_SOCKMAP)
+   ret = sock_map_update_common(map, *(u32 *)key, sk, flags);
else
-   ret = sock_map_update_common(map, idx, sk, flags);
+   ret = sock_hash_update_common(map, key, sk, flags);
sock_map_sk_release(sk);
 out:
fput(sock->file);
@@ -909,45 +913,6 @@ static int sock_hash_update_common(struct bpf_map *map, 
void *key,
return ret;
 }
 
-static int sock_hash_update_elem(struct bpf_map *map, void *key,
-void *value, u64 flags)
-{
-   struct socket *sock;
-   struct sock *sk;
-   int ret;
-   u64 ufd;
-
-   if (map->value_size == sizeof(u64))
-   ufd = *(u64 *)value;
-   else
-   ufd = *(u32 *)value;
-   if (ufd > S32_MAX)
-   return -EINVAL;
-
-   sock = sockfd_lookup(ufd, &ret);
-   if (!sock)
-   return ret;
-   sk = sock->sk;
-   if (!sk) {
-   ret = -EINVAL;
-   goto out;
-   }
-   if (!sock_map_sk_is_suitable(sk)) {
-   ret = -EOPNOTSUPP;
-   goto out;
-   }
-
-   sock_map_sk_acquire(sk);
-   if (!sock_map_sk_state_allowed(sk))
-   ret = -EOPNOTSUPP;
-   else
-   ret = sock_hash_update_common(map, key, sk, flags);
-   sock_map_sk_release(sk);
-out:
-   fput(sock->file);
-   return ret;
-}
-
 static int sock_hash_get_next_key(struct bpf_map *map, void *key,
  void *key_next)
 {
@@ -1216,7 +1181,7 @@ const struct bpf_map_ops sock_hash_ops = {
.map_alloc  = sock_hash_alloc,
.map_free   = sock_hash_free,
.map_get_next_key   = sock_hash_get_next_key,
-   .map_update_elem= sock_hash_update_elem,
+   .map_update_elem= sock_map_update_elem,
.map_delete_elem= sock_hash_delete_elem,
.map_lookup_elem= sock_hash_lookup,
.map_lookup_elem_sys_only = sock_hash_lookup_sys,
-- 
2.25.1



[PATCH bpf-next 4/6] bpf: override the meaning of ARG_PTR_TO_MAP_VALUE for sockmap and sockhash

2020-08-19 Thread Lorenz Bauer
The verifier assumes that map values are simple blobs of memory, and
therefore treats ARG_PTR_TO_MAP_VALUE, etc. as such. However, there are
map types where this isn't true. For example, sockmap and sockhash store
sockets. In general this isn't a big problem: we can just
write helpers that explicitly requests PTR_TO_SOCKET instead of
ARG_PTR_TO_MAP_VALUE.

The one exception are the standard map helpers like map_update_elem,
map_lookup_elem, etc. Here it would be nice we could overload the
function prototype for different kinds of maps. Unfortunately, this
isn't entirely straight forward:
We only know the type of the map once we have resolved meta->map_ptr
in check_func_arg. This means we can't swap out the prototype
in check_helper_call until we're half way through the function.

Instead, modify check_func_arg to treat ARG_PTR_TO_MAP_VALUE* to
mean "the native type for the map" instead of "pointer to memory"
for sockmap and sockhash. This means we don't have to modify the
function prototype at all

Signed-off-by: Lorenz Bauer 
---
 kernel/bpf/verifier.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index b6ccfce3bf4c..47f9b94bb9d4 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3872,6 +3872,38 @@ static int int_ptr_type_to_size(enum bpf_arg_type type)
return -EINVAL;
 }
 
+static int override_map_arg_type(struct bpf_verifier_env *env,
+const struct bpf_call_arg_meta *meta,
+enum bpf_arg_type *arg_type)
+{
+   if (!meta->map_ptr) {
+   /* kernel subsystem misconfigured verifier */
+   verbose(env, "invalid map_ptr to access map->type\n");
+   return -EACCES;
+   }
+
+   switch (meta->map_ptr->map_type) {
+   case BPF_MAP_TYPE_SOCKMAP:
+   case BPF_MAP_TYPE_SOCKHASH:
+   switch (*arg_type) {
+   case ARG_PTR_TO_MAP_VALUE:
+   *arg_type = ARG_PTR_TO_SOCKET;
+   break;
+   case ARG_PTR_TO_MAP_VALUE_OR_NULL:
+   *arg_type = ARG_PTR_TO_SOCKET_OR_NULL;
+   break;
+   default:
+   verbose(env, "invalid arg_type for sockmap/sockhash\n");
+   return -EINVAL;
+   }
+   break;
+
+   default:
+   break;
+   }
+   return 0;
+}
+
 static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
  struct bpf_call_arg_meta *meta,
  const struct bpf_func_proto *fn)
@@ -3904,6 +3936,14 @@ static int check_func_arg(struct bpf_verifier_env *env, 
u32 arg,
return -EACCES;
}
 
+   if (arg_type == ARG_PTR_TO_MAP_VALUE ||
+   arg_type == ARG_PTR_TO_UNINIT_MAP_VALUE ||
+   arg_type == ARG_PTR_TO_MAP_VALUE_OR_NULL) {
+   err = override_map_arg_type(env, meta, &arg_type);
+   if (err)
+   return err;
+   }
+
if (arg_type == ARG_PTR_TO_MAP_KEY ||
arg_type == ARG_PTR_TO_MAP_VALUE ||
arg_type == ARG_PTR_TO_UNINIT_MAP_VALUE ||
-- 
2.25.1



Re: [PATCH net-next 1/1] net/sched: Introduce skb hash classifier

2020-08-19 Thread Jamal Hadi Salim

On 2020-08-17 3:47 p.m., Cong Wang wrote:

On Mon, Aug 17, 2020 at 4:19 AM Jamal Hadi Salim  wrote:




[..]

There is no ambiguity of intent in the fw case, there is only one field.
In the case of having multiple fields it is ambigious if you
unconditionally look.

Example: policy says to match skb mark of 5 and hash of 3.
If packet arrives with skb->mark is 5 and skb->hash is 3
very clearly matched the intent of the policy.
If packet arrives withj skb->mark 7 and hash 3 it clearly
did not match the intent. etc.


This example clearly shows no ambiguous, right? ;)



Ambigious only from the perspective of relational AND vs OR
(your original pseudo code had it in OR relation).






But if filters were put in a global hashtable, the above would be
much harder to implement.



Ok, yes. My assumption has been you will have some global shared
structure where all filters will be installed on.


Sure, if not hashtable, we could simply put them in a list:

list_for_each_filter {
   if (filter_parameter_has_hash) {
 match skb->hash with cls->param_hash
   }
   if (filter_parameter_has_mark) {
 match skb->mark with cls->param_mark
   }
}



Yes, that would work - but iteration is linear.





I think i may have misunderstood all along what you were saying
which is:

a) add the rules so they are each _independent with different
 priorities_ in a chain.


Yes, because this gives users freedom to pick a different prio
from its value (hash or mark).



ok.





b)  when i do lookup for packet arrival, i will only see a filter
   that matches "match mark 5 and hash 3" (meaning there is no
   ambiguity on intent). If packet data doesnt match policy then
   i will iterate to another filter on the chain list with lower
   priority.


Right. Multiple values mean AND, not OR, so if you specify
mark 5 and hash 3, it will match skb->mark==5 && skb->hash==3.
If not matched, it will continue the iteration until the end.



That would remove the ambiguity (assuming iteration with "continue"
to create the AND effect).



Am i correct in my understanding?

If i am - then we still have a problem with lookup scale in presence
of a large number of filters since essentially this approach
is linear lookup (similar problem iptables has). I am afraid
a hash table or something with similar principle goals is needed.


Yeah, this is why I asked you whether we have to put them in a
hashtable in previous emails, as hashtable organizes them with
a key, it is hard to combine multiple fields in one key and allow
to extend easily in the future. But other people smarter than me
may have better ideas here.


To achieve reasonable performance (with many filters) I dont think
there is escape from having something that is centralized
(per priority) - sort of what fw, u32 or flower do. A hash table is
the most common approach; i was hoping that IDR maybe useful since the
skb->hash maps nicely to "32 bit key" but Vlad was saying at the
tc workshop that he was seeing bottlenecks with IDR.

I will test a few hash algorithms (including common one like jenkins)
for this use case.
Problem right now is we have that rcu-inspired upper bucket limit
(which exists) in fw as well: If i have 1M entries which can only be
spread to 256 buckets perfectly then i have ~4K entries per bucket
which are a linked list. So we are still not doing so well. Do you have
time to make that better for fw (since you are an rcu maestro).

cheers,
jamal


Re: [PATCH net-next v2 5/7] net: dsa: mt7530: Add the support of MT7531 switch

2020-08-19 Thread Landen Chao
Hi Jakub,

These 2 function are used in the same file only.
I'll fix warnings by making 2 functions 'static' in v3.

Landen
On Tue, 2020-08-18 at 23:23 +0800, Jakub Kicinski wrote:
[snip]
> Please fix these W=1 warnings:
> 
> ../drivers/net/dsa/mt7530.c:1976:1: warning: no previous prototype for 
> ‘mt7531_sgmii_link_up_force’ [-Wmissing-prototypes]
>  1976 | mt7531_sgmii_link_up_force(struct dsa_switch *ds, int port,
>   | ^~
> ../drivers/net/dsa/mt7530.c:2081:6: warning: no previous prototype for 
> ‘mt7531_sgmii_restart_an’ [-Wmissing-prototypes]
>  2081 | void mt7531_sgmii_restart_an(struct dsa_switch *ds, int port)
>   |  ^~~
> ../drivers/net/dsa/mt7530.c:1976:1: warning: symbol 
> 'mt7531_sgmii_link_up_force' was not declared. Should it be static?
> ../drivers/net/dsa/mt7530.c:2081:6: warning: symbol 'mt7531_sgmii_restart_an' 
> was not declared. Should it be static?



[no subject]

2020-08-19 Thread robert
* Внимание: бенефициар *

* Сообщите, что мы получили утвержденный файл оплаты от FEDERAL
МИНИСТЕРСТВО ФИНАНСОВ совместно с Международным валютным фондом (МВФ)
компенсация жертвам мошенничества и ваш адрес электронной почты входит в список
жертвы. *

* Я пишу, чтобы сообщить вам, что мы будем отправлять вам $ 5000.00USD
ежедневно с
наш офис здесь, так как мы получили мандат на передачу вашего полного
компенсационный платеж в размере 800 000 долларов США Международным
валютным фондом
(МВФ) и Федеральное министерство финансов. Ваш личный идентификационный номер
предоставлено командой I.M.F CPP0920TG. *

* Вот информация об оплате, которую мы будем использовать для пересылки вашего
ежедневный перевод. *

* Имя отправителя: Синтия Иден *
* Вопрос: Оплата *
* Ответ: Да *
* Сумма: 5 000,00 долларов США *
* Город: Ломе *
* Страна: Того *

* ПРИМЕЧАНИЕ: MTCN будет отправлен вам после вашего ответа и подтверждения
Информация о вашем получателе, чтобы избежать неправильной передачи. *

* Мы ждем вашего срочного ответа по этому адресу
(misscynthiaede...@gmail.com ), чтобы позволить нам
продолжить оплату. *

*Искренне ваш,*

*Руководитель филиала:*
* Мисс Синтия Иден *


Re: Flaw in "random32: update the net random state on interrupt and activity"

2020-08-19 Thread Sedat Dilek
On Wed, Aug 12, 2020 at 6:38 PM Sedat Dilek  wrote:
>
> On Wed, Aug 12, 2020 at 6:25 PM Eric Dumazet  wrote:
> >
> > On Wed, Aug 12, 2020 at 9:20 AM Sedat Dilek  wrote:
> > >
> > > On Wed, Aug 12, 2020 at 5:16 PM Eric Dumazet  
> > > wrote:
> > > >
> > > >
> > > >
> > > > On 8/11/20 11:03 PM, Sedat Dilek wrote:
> > > > > [ CC netdev ]
> > > > > [ Please CC me I am not subscribed to this mailing-list ]
> > > > >
> > > > > Hi Eric,
> > > > >
> > > > > I have added your diffs from [0] and have some troubles to display the
> > > > > prandom_32 trace-events (I mostly followed [1]):
> > > > >
> > > > > I did:
> > > > >
> > > > > echo prandom_u32 >> /sys/kernel/debug/tracing/set_event
> > > > > echo traceon > 
> > > > > /sys/kernel/debug/tracing/events/random/prandom_u32/trigger
> > > > > echo 1 > /sys/kernel/debug/tracing/events/enable
> > > > >
> > > > > cat /sys/kernel/debug/tracing/set_event | grep prandom
> > > > > random:prandom_u32
> > > > > cat /sys/kernel/debug/tracing/events/random/prandom_u32/trigger
> > > > > traceon:unlimited
> > > > > cat /sys/kernel/debug/tracing/events/enable
> > > > > X
> > > > >
> > > > > Following [2] and [3] I wanted to use perf:
> > > > >
> > > > > # /home/dileks/bin/perf list | grep prandom
> > > > >   random:prandom_u32 [Tracepoint 
> > > > > event]
> > > > >
> > > > > Following the example in [4]:
> > > > >
> > > > > # /home/dileks/bin/perf probe --add tcp_sendmsg
> > > > > # /home/dileks/bin/perf record -e probe:tcp_sendmsg -a -g -- sleep 10
> > > > > # /home/dileks/bin/perf report --stdio
> > > > >
> > > > > That gives me a report.
> > > > >
> > > > > Adapting:
> > > > >
> > > > > # /home/dileks/bin/perf probe --add tcp_conn_request
> > > > >
> > > > > # /home/dileks/bin/perf list | grep probe:
> > > > >   probe:tcp_conn_request [Tracepoint 
> > > > > event]
> > > > >   probe:tcp_sendmsg  [Tracepoint 
> > > > > event]
> > > > >
> > > > > # home/dileks/bin/perf record -e probe:tcp_conn_request -a -g -- 
> > > > > sleep 10
> > > > >
> > > > > # /home/dileks/bin/perf report --stdio
> > > > > Error:
> > > > > The perf.data data has no samples!
> > > > > # To display the perf.data header info, please use
> > > > > --header/--header-only options.
> > > > > #
> > > > >
> > > > > # /home/dileks/bin/perf report --stdio --header-only
> > > > > # 
> > > > > # captured on: Wed Aug 12 07:39:42 2020
> > > > > # header version : 1
> > > > > # data offset: 440
> > > > > # data size  : 2123144
> > > > > # feat offset: 2123584
> > > > > # hostname : iniza
> > > > > # os release : 5.8.1-2-amd64-llvm11-ias
> > > > > # perf version : 5.8.1
> > > > > # arch : x86_64
> > > > > # nrcpus online : 4
> > > > > # nrcpus avail : 4
> > > > > # cpudesc : Intel(R) Core(TM) i5-2467M CPU @ 1.60GHz
> > > > > # cpuid : GenuineIntel,6,42,7
> > > > > # total memory : 8046012 kB
> > > > > # cmdline : /home/dileks/bin/perf record -e probe:tcp_conn_request -a
> > > > > -g -- sleep 10
> > > > > # event : name = probe:tcp_conn_request, , id = { 304, 305, 306, 307
> > > > > }, type = 2, size = 120, config = 0x866, { sample_period, sample_freq
> > > > > } = 1, sample_type = IP|TID|TIME|CALLCHAIN|CPU|PERIO>
> > > > > # event : name = dummy:HG, , id = { 308, 309, 310, 311 }, type = 1,
> > > > > size = 120, config = 0x9, { sample_period, sample_freq } = 4000,
> > > > > sample_type = IP|TID|TIME|CALLCHAIN|CPU|PERIOD|IDENTIFIER,>
> > > > > # CPU_TOPOLOGY info available, use -I to display
> > > > > # NUMA_TOPOLOGY info available, use -I to display
> > > > > # pmu mappings: software = 1, power = 14, uprobe = 7, cpu = 4,
> > > > > cstate_core = 12, breakpoint = 5, uncore_cbox_0 = 9, tracepoint = 2,
> > > > > cstate_pkg = 13, uncore_arb = 11, kprobe = 6, i915 = 15, ms>
> > > > > # CACHE info available, use -I to display
> > > > > # time of first sample : 0.00
> > > > > # time of last sample : 0.00
> > > > > # sample duration :  0.000 ms
> > > > > # MEM_TOPOLOGY info available, use -I to display
> > > > > # bpf_prog_info 3: bpf_prog_6deef7357e7b4530 addr 0xc01d7834 
> > > > > size 66
> > > > > # bpf_prog_info 4: bpf_prog_6deef7357e7b4530 addr 0xc01df7e8 
> > > > > size 66
> > > > > # bpf_prog_info 5: bpf_prog_6deef7357e7b4530 addr 0xc041ca18 
> > > > > size 66
> > > > > # bpf_prog_info 6: bpf_prog_6deef7357e7b4530 addr 0xc041eb58 
> > > > > size 66
> > > > > # bpf_prog_info 7: bpf_prog_6deef7357e7b4530 addr 0xc1061dc0 
> > > > > size 66
> > > > > # bpf_prog_info 8: bpf_prog_6deef7357e7b4530 addr 0xc1063388 
> > > > > size 66
> > > > > # bpf_prog_info 12: bpf_prog_6deef7357e7b4530 addr 0xc129c244 
> > > > > size 66
> > > > > # bpf_prog_info 13: bpf_prog_6deef7357e7b4530 addr 0xc129e8c0 
> > > > > size 66
> > > > > # cpu pmu capabilities: branches=16, max_precise=2, 
> > > > > pmu_name=sandybridge
> > > > > # missing features: BRANCH_STAC

Re: [PATCH net-next v2 5/7] net: dsa: mt7530: Add the support of MT7531 switch

2020-08-19 Thread Landen Chao
On Wed, 2020-08-19 at 00:09 +0800, Andrew Lunn wrote:
> On Tue, Aug 18, 2020 at 03:14:10PM +0800, Landen Chao wrote:
> > Add new support for MT7531:
> > 
> > MT7531 is the next generation of MT7530. It is also a 7-ports switch with
> > 5 giga embedded phys, 2 cpu ports, and the same MAC logic of MT7530. Cpu
> > port 6 only supports SGMII interface. Cpu port 5 supports either RGMII
> > or SGMII in different HW sku. Due to SGMII interface support, pll, and
> > pad setting are different from MT7530. This patch adds different initial
> > setting, and SGMII phylink handlers of MT7531.
> > 
> > MT7531 SGMII interface can be configured in following mode:
> > - 'SGMII AN mode' with in-band negotiation capability
> > which is compatible with PHY_INTERFACE_MODE_SGMII.
> > - 'SGMII force mode' without in-bnad negotiation
> 
> band
Sorry, I'll fix it.
> 
> > which is compatible with 10B/8B encoding of
> > PHY_INTERFACE_MODE_1000BASEX with fixed full-duplex and fixed pause.
> > - 2.5 times faster clocked 'SGMII force mode' without in-bnad negotiation
> 
> band
Sorry, I'll fix it.
> 
> > +static int mt7531_rgmii_setup(struct mt7530_priv *priv, u32 port,
> > + phy_interface_t interface)
> > +{
> > +   u32 val;
> > +
> > +   if (!mt7531_is_rgmii_port(priv, port)) {
> > +   dev_err(priv->dev, "RGMII mode is not available for port %d\n",
> > +   port);
> > +   return -EINVAL;
> > +   }
> > +
> > +   val = mt7530_read(priv, MT7531_CLKGEN_CTRL);
> > +   val |= GP_CLK_EN;
> > +   val &= ~GP_MODE_MASK;
> > +   val |= GP_MODE(MT7531_GP_MODE_RGMII);
> > +   val &= ~(TXCLK_NO_REVERSE | RXCLK_NO_DELAY);
> > +   switch (interface) {
> > +   case PHY_INTERFACE_MODE_RGMII:
> > +   val |= TXCLK_NO_REVERSE;
> > +   val |= RXCLK_NO_DELAY;
> > +   break;
> > +   case PHY_INTERFACE_MODE_RGMII_RXID:
> > +   val |= TXCLK_NO_REVERSE;
> > +   break;
> > +   case PHY_INTERFACE_MODE_RGMII_TXID:
> > +   val |= RXCLK_NO_DELAY;
> > +   break;
> > +   case PHY_INTERFACE_MODE_RGMII_ID:
> > +   break;
> > +   default:
> > +   return -EINVAL;
> > +   }
> 
> You need to be careful here. If the MAC is doing the RGMII delays, you
> need to ensure the PHY is not. What interface mode is passed to the
> PHY?
Hi Andrew,

mt7531 RGMII port is a MAC-only port, it can be connected to CPU MAC or
external phy. In bpi-r64 board, mt7531 RGMII is connected to CPU MAC, so
I tend to implement RGMII logic for use case of bpi-r64.

In general, according to phy.rst, RGMII delay should be done by phy, but
some MoCA product need RGMII delay in MAC. These two requirements
conflict. Is there any suggestion to solve the conflict?

If mt7531 RGMII implementation needs to satisfy either phy.rst or
special MoCA product, I would like to satisfy phy.rst and remove MAC
RGMII delay in v3. For special product needs MAC RGMII delay, this patch
can be used in its local codebase.

Landen
> 
>   Andrew



[PATCH] netlink: fix state reallocation in policy export

2020-08-19 Thread Johannes Berg
From: Johannes Berg 

Evidently, when I did this previously, we didn't have more than
10 policies and didn't run into the reallocation path, because
it's missing a memset() for the unused policies. Fix that.

Fixes: d07dcf9aadd6 ("netlink: add infrastructure to expose policies to 
userspace")
Signed-off-by: Johannes Berg 
---
 net/netlink/policy.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/netlink/policy.c b/net/netlink/policy.c
index f6491853c797..3f3b421fd70c 100644
--- a/net/netlink/policy.c
+++ b/net/netlink/policy.c
@@ -51,6 +51,9 @@ static int add_policy(struct nl_policy_dump **statep,
if (!state)
return -ENOMEM;
 
+   memset(&state->policies[state->n_alloc], 0,
+  sizeof(state->policies[0]) * (n_alloc - state->n_alloc));
+
state->policies[state->n_alloc].policy = policy;
state->policies[state->n_alloc].maxtype = maxtype;
state->n_alloc = n_alloc;
-- 
2.26.2



[PATCH 2/2] genl: ctrl: support dumping netlink policy

2020-08-19 Thread Johannes Berg
Support dumping the netlink policy of a given generic netlink
family, the policy (with any sub-policies if appropriate) is
exported by the kernel in a general fashion.

Signed-off-by: Johannes Berg 
---
 genl/ctrl.c | 91 +
 1 file changed, 85 insertions(+), 6 deletions(-)

diff --git a/genl/ctrl.c b/genl/ctrl.c
index 0fb464b01cfb..7767fffe63ea 100644
--- a/genl/ctrl.c
+++ b/genl/ctrl.c
@@ -28,13 +28,15 @@
 static int usage(void)
 {
fprintf(stderr,"Usage: ctrl \n" \
-  "CMD   := get  | list | monitor\n" \
+  "CMD   := get  | list | monitor | policy 
\n" \
   "PARMS := name  | id \n" \
   "Examples:\n" \
   "\tctrl ls\n" \
   "\tctrl monitor\n" \
   "\tctrl get name foobar\n" \
-  "\tctrl get id 0xF\n");
+  "\tctrl get id 0xF\n"
+  "\tctrl policy name foobar\n"
+  "\tctrl policy id 0xF\n");
return -1;
 }
 
@@ -100,6 +102,30 @@ static int print_ctrl_grp(FILE *fp, struct rtattr *arg, 
__u32 ctrl_ver)
 
 }
 
+static const char *get_nla_type_str(unsigned int attr)
+{
+   switch (attr) {
+#define C(x) case NL_ATTR_TYPE_ ## x: return #x
+   C(U8);
+   C(U16);
+   C(U32);
+   C(U64);
+   C(STRING);
+   C(FLAG);
+   C(NESTED);
+   C(NESTED_ARRAY);
+   C(NUL_STRING);
+   C(BINARY);
+   C(S8);
+   C(S16);
+   C(S32);
+   C(S64);
+   C(BITFIELD32);
+   default:
+   return "unknown";
+   }
+}
+
 /*
  * The controller sends one nlmsg per family
 */
@@ -123,7 +149,8 @@ static int print_ctrl(struct rtnl_ctrl_data *ctrl,
ghdr->cmd != CTRL_CMD_DELFAMILY &&
ghdr->cmd != CTRL_CMD_NEWFAMILY &&
ghdr->cmd != CTRL_CMD_NEWMCAST_GRP &&
-   ghdr->cmd != CTRL_CMD_DELMCAST_GRP) {
+   ghdr->cmd != CTRL_CMD_DELMCAST_GRP &&
+   ghdr->cmd != CTRL_CMD_GETPOLICY) {
fprintf(stderr, "Unknown controller command %d\n", ghdr->cmd);
return 0;
}
@@ -136,7 +163,7 @@ static int print_ctrl(struct rtnl_ctrl_data *ctrl,
}
 
attrs = (struct rtattr *) ((char *) ghdr + GENL_HDRLEN);
-   parse_rtattr(tb, CTRL_ATTR_MAX, attrs, len);
+   parse_rtattr_flags(tb, CTRL_ATTR_MAX, attrs, len, NLA_F_NESTED);
 
if (tb[CTRL_ATTR_FAMILY_NAME]) {
char *name = RTA_DATA(tb[CTRL_ATTR_FAMILY_NAME]);
@@ -159,6 +186,52 @@ static int print_ctrl(struct rtnl_ctrl_data *ctrl,
__u32 *ma = RTA_DATA(tb[CTRL_ATTR_MAXATTR]);
fprintf(fp, " max attribs: %d ",*ma);
}
+   if (tb[CTRL_ATTR_POLICY]) {
+   const struct rtattr *pos;
+
+   rtattr_for_each_nested(pos, tb[CTRL_ATTR_POLICY]) {
+   const struct rtattr *attr;
+
+   fprintf(fp, " policy[%u]:", pos->rta_type & 
~NLA_F_NESTED);
+
+   rtattr_for_each_nested(attr, pos) {
+   struct rtattr *tp[NL_POLICY_TYPE_ATTR_MAX + 1];
+
+   parse_rtattr_nested(tp, ARRAY_SIZE(tp) - 1, 
attr);
+
+   if (tp[NL_POLICY_TYPE_ATTR_TYPE])
+   fprintf(fp, "attr[%u]: type=%s",
+   attr->rta_type & ~NLA_F_NESTED,
+   
get_nla_type_str(rta_getattr_u32(tp[NL_POLICY_TYPE_ATTR_TYPE])));
+
+   if (tp[NL_POLICY_TYPE_ATTR_POLICY_IDX])
+   fprintf(fp, " policy:%u",
+   
rta_getattr_u32(tp[NL_POLICY_TYPE_ATTR_POLICY_IDX]));
+
+   if (tp[NL_POLICY_TYPE_ATTR_POLICY_MAXTYPE])
+   fprintf(fp, " maxattr:%u",
+   
rta_getattr_u32(tp[NL_POLICY_TYPE_ATTR_POLICY_MAXTYPE]));
+
+   if (tp[NL_POLICY_TYPE_ATTR_MIN_VALUE_S] && 
tp[NL_POLICY_TYPE_ATTR_MAX_VALUE_S])
+   fprintf(fp, " range:[%lld,%lld]",
+   (signed long 
long)rta_getattr_u64(tp[NL_POLICY_TYPE_ATTR_MIN_VALUE_S]),
+   (signed long 
long)rta_getattr_u64(tp[NL_POLICY_TYPE_ATTR_MAX_VALUE_S]));
+
+   if (tp[NL_POLICY_TYPE_ATTR_MIN_VALUE_U] && 
tp[NL_POLICY_TYPE_ATTR_MAX_VALUE_U])
+   fprintf(fp, " range:[%llu,%llu]",
+   (unsigned long 
long)rta_getattr_u64(tp[NL_POLICY_TYPE_ATTR_MIN_VALUE_U]),
+   (unsigned long 
long)rta_getattr_u64(tp[NL_POLICY_TYPE_ATTR_MAX_VALUE_U]));
+

[PATCH 1/2] libnetlink: add rtattr_for_each_nested() iteration macro

2020-08-19 Thread Johannes Berg
This is useful for iterating elements in a nested attribute,
if they're not parsed with a strict length limit or such.

Signed-off-by: Johannes Berg 
---
 include/libnetlink.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/libnetlink.h b/include/libnetlink.h
index e27516f7648f..0d4a9f29afbd 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -284,4 +284,9 @@ int rtnl_from_file(FILE *, rtnl_listen_filter_t handler,
  * messages from dump file */
 #define NLMSG_TSTAMP   15
 
+#define rtattr_for_each_nested(attr, nest) \
+   for ((attr) = (void *)RTA_DATA(nest); \
+RTA_OK(attr, RTA_PAYLOAD(nest) - ((char *)(attr) - (char 
*)RTA_DATA((nest; \
+(attr) = RTA_TAIL((attr)))
+
 #endif /* __LIBNETLINK_H__ */
-- 
2.26.2



Re: ethernet/sfc/ warnings with 32-bit dma_addr_t

2020-08-19 Thread Edward Cree
On 19/08/2020 01:28, Randy Dunlap wrote:
> Hi,
>
> Does the drivers/net/ethernet/sfc/sfc driver require (expect)
> dma_addr_t to be 64 bits (as opposed to 32 bits)?
>
> I see that several #defines in ef100_regs.h are 64...
>
> When used with DMA_BIT_MASK(64), does the value just need to be
> truncated to 32 bits?  Will that work?
As far as I can tell, truncation to 32 bits is harmless — the
 called function (efx_init_io) already tries every mask from the
 passed one down to 32 bits in case of PCIe hardware limitations.

The ef10 and siena versions also truncate like this (their
 #defines are 48 and 46 respectively), but because they are
 handled indirectly through efx_nic_type, the compiler isn't able
 to determine this statically as it can with ef100.
> When I build this driver on i386 with 32-bit dma_addr_t, I see
> the following build warnings:
Could you test whether explicitly casting to dma_addr_t suppresses
 the warnings?  I.e.

    efx_init_io(efx, bar,
                (dma_addr_t)DMA_BIT_MASK(ESF_GZ_TX_SEND_ADDR_WIDTH),
                pci_resource_len(efx->pci_dev, bar));

-ed


Re: [PATCH] block: convert tasklets to use new tasklet_setup() API

2020-08-19 Thread Allen
> > > > > > > >
> > > > > > > > In preparation for unconditionally passing the
> > > > > > > > struct tasklet_struct pointer to all tasklet
> > > > > > > > callbacks, switch to using the new tasklet_setup()
> > > > > > > > and from_tasklet() to pass the tasklet pointer explicitly.
> > > > > > >
> > > > > > > Who came up with the idea to add a macro 'from_tasklet' that
> > > > > > > is just container_of? container_of in the code would be
> > > > > > > _much_ more readable, and not leave anyone guessing wtf
> > > > > > > from_tasklet is doing.
> > > > > > >
> > > > > > > I'd fix that up now before everything else goes in...
> > > > > >
> > > > > > As I mentioned in the other thread, I think this makes things
> > > > > > much more readable. It's the same thing that the timer_struct
> > > > > > conversion did (added a container_of wrapper) to avoid the
> > > > > > ever-repeating use of typeof(), long lines, etc.
> > > > >
> > > > > But then it should use a generic name, instead of each sub-system
> > > > > using some random name that makes people look up exactly what it
> > > > > does. I'm not huge fan of the container_of() redundancy, but
> > > > > adding private variants of this doesn't seem like the best way
> > > > > forward. Let's have a generic helper that does this, and use it
> > > > > everywhere.
> > > >
> > > > I'm open to suggestions, but as things stand, these kinds of
> > > > treewide
> > >
> > > On naming? Implementation is just as it stands, from_tasklet() is
> > > totally generic which is why I objected to it. from_member()? Not
> > > great with naming... But I can see this going further and then we'll
> > > suddenly have tons of these. It's not good for readability.
> >
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> >
> > #define cast_out(ptr, container, member) \
> >   container_of(ptr, typeof(*container), member)
> >
> > It does what you want, the argument order is the same as container_of
> > with the only difference being you name the containing structure
> > instead of having to specify its type.
>
> I like this! Shall I send this to Linus to see if this can land in -rc2
> for use going forward?
>

Cool, I shall wait for it to be accepted and then spin out V2 with cast_out()

-- 
   - Allen


[PATCH][next] ath11k: fix error check on return from call to ath11k_core_firmware_request

2020-08-19 Thread Colin King
From: Colin Ian King 

The call to ath11k_core_firmware_request is returning a pointer that
can be set to an error code, however, this is not being checked.
Instead ret is being incorrecly checked for the error return. Fix the
error checking.

Addresses-Coverity: ("Logically dead code")
Fixes: 7b57b2ddec21 ("ath11k: create a common function to request all firmware 
files")
Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/ath/ath11k/qmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/qmi.c 
b/drivers/net/wireless/ath/ath11k/qmi.c
index 91134510364c..4792857678b9 100644
--- a/drivers/net/wireless/ath/ath11k/qmi.c
+++ b/drivers/net/wireless/ath/ath11k/qmi.c
@@ -1886,7 +1886,7 @@ ath11k_qmi_prepare_bdf_download(struct ath11k_base *ab, 
int type,
break;
case ATH11K_QMI_FILE_TYPE_CALDATA:
fw_entry = ath11k_core_firmware_request(ab, 
ATH11K_DEFAULT_CAL_FILE);
-   if (ret) {
+   if (PTR_ERR(fw_entry)) {
ath11k_warn(ab, "failed to load %s: %d\n",
ATH11K_DEFAULT_CAL_FILE, ret);
goto out;
-- 
2.27.0



[PATCH net-next 0/2] r8169: use napi_complete_done return value

2020-08-19 Thread Heiner Kallweit
Consider the return value of napi_complete_done(), this allows users to
use the gro_flush_timeout sysfs attribute as an alternative to classic
interrupt coalescing.

Heiner Kallweit (2):
  r8169: use napi_complete_done return value
  r8169: remove member irq_enabled from struct rtl8169_private

 drivers/net/ethernet/realtek/r8169_main.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

-- 
2.28.0



[PATCH net-next 1/2] r8169: use napi_complete_done return value

2020-08-19 Thread Heiner Kallweit
Consider the return value of napi_complete_done(), this allows users to
use the gro_flush_timeout sysfs attribute as an alternative to classic
interrupt coalescing.

Signed-off-by: Heiner Kallweit 
---
 drivers/net/ethernet/realtek/r8169_main.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c 
b/drivers/net/ethernet/realtek/r8169_main.c
index d1da92ac7..dbc324c53 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4596,10 +4596,8 @@ static int rtl8169_poll(struct napi_struct *napi, int 
budget)
 
rtl_tx(dev, tp, budget);
 
-   if (work_done < budget) {
-   napi_complete_done(napi, work_done);
+   if (work_done < budget && napi_complete_done(napi, work_done))
rtl_irq_enable(tp);
-   }
 
return work_done;
 }
-- 
2.28.0




[PATCH net-next 2/2] r8169: remove member irq_enabled from struct rtl8169_private

2020-08-19 Thread Heiner Kallweit
After making use of the gro_flush_timeout attribute I once got a
tx timeout due to an interrupt that wasn't handled. Seems using
irq_enabled can be racy, and it's not needed any longer anyway,
so remove it. I've never seen a report about such a race before,
therefore treat the change as an improvement.

There's just one small drawback: If a legacy PCI interrupt is used,
and if this interrupt is shared with a device with high interrupt
rate, then we may handle interrupts even if NAPI disabled them,
and we may see a certain performance decrease under high network load.

Signed-off-by: Heiner Kallweit 
---
 drivers/net/ethernet/realtek/r8169_main.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c 
b/drivers/net/ethernet/realtek/r8169_main.c
index dbc324c53..c427865d5 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -617,7 +617,6 @@ struct rtl8169_private {
struct work_struct work;
} wk;
 
-   unsigned irq_enabled:1;
unsigned supports_gmii:1;
unsigned aspm_manageable:1;
dma_addr_t counters_phys_addr;
@@ -1280,12 +1279,10 @@ static void rtl_irq_disable(struct rtl8169_private *tp)
RTL_W32(tp, IntrMask_8125, 0);
else
RTL_W16(tp, IntrMask, 0);
-   tp->irq_enabled = 0;
 }
 
 static void rtl_irq_enable(struct rtl8169_private *tp)
 {
-   tp->irq_enabled = 1;
if (rtl_is_8125(tp))
RTL_W32(tp, IntrMask_8125, tp->irq_mask);
else
@@ -4541,8 +4538,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void 
*dev_instance)
struct rtl8169_private *tp = dev_instance;
u32 status = rtl_get_events(tp);
 
-   if (!tp->irq_enabled || (status & 0x) == 0x ||
-   !(status & tp->irq_mask))
+   if ((status & 0x) == 0x || !(status & tp->irq_mask))
return IRQ_NONE;
 
if (unlikely(status & SYSErr)) {
-- 
2.28.0




re: ath11k: initialize wmi config based on hw_params

2020-08-19 Thread Colin Ian King
Hi,

static analysis with Coverity has detected a duplicated assignment issue
with the following commit:

commit 2d4bcbed5b7d53e19fc158885e7340b464b64507
Author: Carl Huang 
Date:   Mon Aug 17 13:31:51 2020 +0300

ath11k: initialize wmi config based on hw_params

The analysis is as follows:


 74config->beacon_tx_offload_max_vdev = 0x2;
 75config->num_multicast_filter_entries = 0x20;
 76config->num_wow_filters = 0x16;

Unused value (UNUSED_VALUE)
assigned_value: Assigning value 1U to config->num_keep_alive_pattern
here, but that stored value is overwritten before it can be used.
 77config->num_keep_alive_pattern = 0x1;

value_overwrite: Overwriting previous write to
config->num_keep_alive_pattern with value 0U.

 78config->num_keep_alive_pattern = 0;


I'm not sure if one of these assignments is redundant, or perhaps one of
the assignments is meant to be setting a different structure element.

Colin


[PATCH bpf] libbpf: fix map index used in error message

2020-08-19 Thread Toke Høiland-Jørgensen
The error message emitted by bpf_object__init_user_btf_maps() was using the
wrong section ID.

Signed-off-by: Toke Høiland-Jørgensen 
---
 tools/lib/bpf/libbpf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 5d20b2da4427..0ad0b0491e1f 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2264,7 +2264,7 @@ static int bpf_object__init_user_btf_maps(struct 
bpf_object *obj, bool strict,
data = elf_getdata(scn, NULL);
if (!scn || !data) {
pr_warn("failed to get Elf_Data from map section %d (%s)\n",
-   obj->efile.maps_shndx, MAPS_ELF_SEC);
+   obj->efile.btf_maps_shndx, MAPS_ELF_SEC);
return -EINVAL;
}
 
-- 
2.28.0



[PATCH][next] ath11k: fix missing error check on call to ath11k_pci_get_user_msi_assignment

2020-08-19 Thread Colin King
From: Colin Ian King 

The return error check on the call to ath11k_pci_get_user_msi_assignment is
missing.  If an error does occur, num_vectors is still set to zero and
later on a division by zero can occur when variable vector is being
calculated.  Fix this by adding an error check after the call.

Addresses-Coverity: ("Division or modulo by zero")
Fixes: d4ecb90b3857 ("ath11k: enable DP interrupt setup for QCA6390")
Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/ath/ath11k/pci.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/pci.c 
b/drivers/net/wireless/ath/ath11k/pci.c
index ca7012d46c3f..058885776a3a 100644
--- a/drivers/net/wireless/ath/ath11k/pci.c
+++ b/drivers/net/wireless/ath/ath11k/pci.c
@@ -648,9 +648,12 @@ static int ath11k_pci_ext_irq_config(struct ath11k_base 
*ab)
int i, j, ret, num_vectors = 0;
u32 user_base_data = 0, base_vector = 0;
 
-   ath11k_pci_get_user_msi_assignment(ath11k_pci_priv(ab), "DP",
-  &num_vectors, &user_base_data,
-  &base_vector);
+   ret = ath11k_pci_get_user_msi_assignment(ath11k_pci_priv(ab), "DP",
+&num_vectors,
+&user_base_data,
+&base_vector);
+   if (ret < 0)
+   return ret;
 
for (i = 0; i < ATH11K_EXT_IRQ_GRP_NUM_MAX; i++) {
struct ath11k_ext_irq_grp *irq_grp = &ab->ext_irq_grp[i];
-- 
2.27.0



Re: [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

2020-08-19 Thread Tomasz Figa
Hi Christoph,

On Wed, Aug 19, 2020 at 8:56 AM Christoph Hellwig  wrote:
>
> The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused,

Could you explain what makes you think it's unused? It's a feature of
the UAPI generally supported by the videobuf2 framework and relied on
by Chromium OS to get any kind of reasonable performance when
accessing V4L2 buffers in the userspace.

> and causes
> weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is
> unimplemented except on PARISC and some MIPS configs, and about to be
> removed.

It is implemented by the generic DMA mapping layer [1], which is used
by a number of architectures including ARM64 and supposed to be used
by new architectures going forward.

[1] https://elixir.bootlin.com/linux/v5.9-rc1/source/kernel/dma/mapping.c#L341

When removing features from generic kernel code, I'd suggest first
providing viable alternatives for its users, rather than killing the
users altogether.

Given the above, I'm afraid I have to NAK this.

Best regards,
Tomasz

>
> Signed-off-by: Christoph Hellwig 
> ---
>  .../userspace-api/media/v4l/buffer.rst| 17 -
>  .../media/v4l/vidioc-reqbufs.rst  |  1 -
>  .../media/common/videobuf2/videobuf2-core.c   | 36 +--
>  .../common/videobuf2/videobuf2-dma-contig.c   | 19 --
>  .../media/common/videobuf2/videobuf2-dma-sg.c |  3 +-
>  .../media/common/videobuf2/videobuf2-v4l2.c   | 12 ---
>  include/media/videobuf2-core.h|  3 +-
>  include/uapi/linux/videodev2.h|  2 --
>  8 files changed, 3 insertions(+), 90 deletions(-)
>
> diff --git a/Documentation/userspace-api/media/v4l/buffer.rst 
> b/Documentation/userspace-api/media/v4l/buffer.rst
> index 57e752aaf414a7..2044ed13cd9d7d 100644
> --- a/Documentation/userspace-api/media/v4l/buffer.rst
> +++ b/Documentation/userspace-api/media/v4l/buffer.rst
> @@ -701,23 +701,6 @@ Memory Consistency Flags
>  :stub-columns: 0
>  :widths:   3 1 4
>
> -* .. _`V4L2-FLAG-MEMORY-NON-CONSISTENT`:
> -
> -  - ``V4L2_FLAG_MEMORY_NON_CONSISTENT``
> -  - 0x0001
> -  - A buffer is allocated either in consistent (it will be automatically
> -   coherent between the CPU and the bus) or non-consistent memory. The
> -   latter can provide performance gains, for instance the CPU cache
> -   sync/flush operations can be avoided if the buffer is accessed by the
> -   corresponding device only and the CPU does not read/write to/from that
> -   buffer. However, this requires extra care from the driver -- it must
> -   guarantee memory consistency by issuing a cache flush/sync when
> -   consistency is needed. If this flag is set V4L2 will attempt to
> -   allocate the buffer in non-consistent memory. The flag takes effect
> -   only if the buffer is used for :ref:`memory mapping ` I/O and 
> the
> -   queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
> -   ` capability.
> -
>  .. c:type:: v4l2_memory
>
>  enum v4l2_memory
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst 
> b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> index 75d894d9c36c42..3180c111d368ee 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> @@ -169,7 +169,6 @@ aborting or finishing any DMA in progress, an implicit
>- This capability is set by the driver to indicate that the queue 
> supports
>  cache and memory management hints. However, it's only valid when the
>  queue is used for :ref:`memory mapping ` streaming I/O. See
> -:ref:`V4L2_FLAG_MEMORY_NON_CONSISTENT 
> `,
>  :ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 
> ` and
>  :ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN `.
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index f544d3393e9d6b..66a41cef33c1b1 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -721,39 +721,14 @@ int vb2_verify_memory_type(struct vb2_queue *q,
>  }
>  EXPORT_SYMBOL(vb2_verify_memory_type);
>
> -static void set_queue_consistency(struct vb2_queue *q, bool consistent_mem)
> -{
> -   q->dma_attrs &= ~DMA_ATTR_NON_CONSISTENT;
> -
> -   if (!vb2_queue_allows_cache_hints(q))
> -   return;
> -   if (!consistent_mem)
> -   q->dma_attrs |= DMA_ATTR_NON_CONSISTENT;
> -}
> -
> -static bool verify_consistency_attr(struct vb2_queue *q, bool consistent_mem)
> -{
> -   bool queue_is_consistent = !(q->dma_attrs & DMA_ATTR_NON_CONSISTENT);
> -
> -   if (consistent_mem != queue_is_consistent) {
> -   dprintk(q, 1, "memory consistency model mismatch\n");
> -   return false;
> -   }
> -   return true;
> -}
> -
>  int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
>

Re: KASAN: use-after-free Read in rtl_fw_do_work

2020-08-19 Thread syzbot
syzbot has found a reproducer for the following issue on:

HEAD commit:28157b8c USB: Better name for __check_usb_generic()
git tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=1064697a90
kernel config:  https://syzkaller.appspot.com/x/.config?x=ccafc70ac3d5f49c
dashboard link: https://syzkaller.appspot.com/bug?extid=ff4b26b0bfbff2dc7960
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10f0a00e90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=162bc28990

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ff4b26b0bfbff2dc7...@syzkaller.appspotmail.com

usb 6-1: Direct firmware load for rtlwifi/rtl8192cufw_TMSC.bin failed with 
error -2
usb 6-1: Direct firmware load for rtlwifi/rtl8192cufw.bin failed with error -2
==
BUG: KASAN: use-after-free in rtl_fw_do_work+0x407/0x430 
drivers/net/wireless/realtek/rtlwifi/core.c:87
Read of size 8 at addr 8881ca9aff38 by task kworker/0:1/328

CPU: 0 PID: 328 Comm: kworker/0:1 Not tainted 5.9.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: events request_firmware_work_func
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xf6/0x16e lib/dump_stack.c:118
 print_address_description.constprop.0+0x1c/0x210 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report.cold+0x37/0x7c mm/kasan/report.c:530
 rtl_fw_do_work+0x407/0x430 drivers/net/wireless/realtek/rtlwifi/core.c:87
 request_firmware_work_func+0x126/0x250 drivers/base/firmware_loader/main.c:1001
 process_one_work+0x94c/0x15f0 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x392/0x470 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

The buggy address belongs to the page:
page:fcdef481 refcount:0 mapcount:0 mapping: index:0x0 
pfn:0x1ca9af
flags: 0x200()
raw: 0200  ea00072a6bc8 
raw:    
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 8881ca9afe00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 8881ca9afe80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>8881ca9aff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
 8881ca9aff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 8881ca9b: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==



NETDEV WATCHDOG: WARNING: at net/sched/sch_generic.c:442 dev_watchdog

2020-08-19 Thread Naresh Kamboju
kernel warning noticed on x86_64 while running LTP tracing ftrace-stress-test
case. started noticing on the stable-rc linux-5.8.y branch.

This device booted with KASAN config and DYNAMIC tracing configs and more.
This reported issue is not easily reproducible.

metadata:
  git branch: linux-5.8.y
  git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
  git commit: ad8c735b1497520df959f675718f39dca8cb8019
  git describe: v5.8.2
  make_kernelversion: 5.8.2
  kernel-config:
https://builds.tuxbuild.com/bOz0eAwkcraRiWALTW9D3Q/kernel.config


[   88.139387] Scheduler tracepoints stat_sleep, stat_iowait,
stat_blocked and stat_runtime require the kernel parameter
schedstats=enable or kernel.sched_schedstats=1
[   88.139387] Scheduler tracepoints stat_sleep, stat_iowait,
stat_blocked and stat_runtime require the kernel parameter
schedstats=enable or kernel.sched_schedstats=1
[  107.507991] [ cut here ]
[  107.513103] NETDEV WATCHDOG: eth0 (igb): transmit queue 2 timed out
[  107.519973] WARNING: CPU: 1 PID: 331 at net/sched/sch_generic.c:442
dev_watchdog+0x4c7/0x4d0
[  107.528907] Modules linked in: x86_pkg_temp_thermal
[  107.534541] CPU: 1 PID: 331 Comm: systemd-journal Not tainted 5.8.2 #1
[  107.541480] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[  107.549314] RIP: 0010:dev_watchdog+0x4c7/0x4d0
[  107.554226] Code: ff ff 48 8b 5d c8 c6 05 6d f7 94 01 01 48 89 df
e8 9e b4 f8 ff 44 89 e9 48 89 de 48 c7 c7 20 49 51 9c 48 89 c2 e8 91
7e e9 fe <0f> 0b e9 03 ff ff ff 66 90 e8 9b 23 db fe 55 48 89 e5 41 57
41 56
[  107.573476] RSP: 0018:888230889d88 EFLAGS: 00010286
[  107.579264] RAX:  RBX: 88822bbb RCX: dc00
[  107.586928] RDX: 111046114c99 RSI: 9a7e4dbe RDI: 9b7a6da7
[  107.594473] RBP: 888230889de0 R08: 9a7e4dd3 R09: ed1044de2529
[  107.602101] R10: 888226f12943 R11: ed1044de2528 R12: 88822bbb0440
[  107.609648] R13: 0002 R14: 88822bbb0388 R15: 88822bbb0380
[  107.617197] FS:  7f8b471bb480() GS:88823088()
knlGS:
[  107.625698] CS:  0010 DS:  ES:  CR0: 80050033
[  107.631944] CR2: 0008 CR3: 000226a64001 CR4: 003606e0
[  107.639496] DR0:  DR1:  DR2: 
[  107.647092] DR3:  DR6: fffe0ff0 DR7: 0400
[  107.654661] Call Trace:
[  107.657735]  
[  107.663155]  ? ftrace_graph_caller+0xc0/0xc0
[  107.667929]  call_timer_fn+0x3b/0x1b0
[  107.672238]  ? netif_carrier_off+0x70/0x70
[  107.61]  ? netif_carrier_off+0x70/0x70
[  107.682656]  ? ftrace_graph_caller+0xc0/0xc0
[  107.687379]  run_timer_softirq+0x3e8/0xa10
[  107.694653]  ? call_timer_fn+0x1b0/0x1b0
[  107.699382]  ? trace_event_raw_event_softirq+0xdd/0x150
[  107.706768]  ? ring_buffer_unlock_commit+0xf5/0x210
[  107.712213]  ? call_timer_fn+0x1b0/0x1b0
[  107.716625]  ? __do_softirq+0x155/0x467
Aug 22 04:21:44 intel-corei7-64 [  107.721972]  ? run_timer_softirq+0x5/0xa10
user.warn kernel[  107.727997]  ? asm_call_on_stack+0x12/0x20
: [  107.507991] [ c[  107.735546]  ? ftrace_graph_caller+0xc0/0xc0
ut here ]---[  107.740453]  __do_softirq+0x160/0x467
-
[  107.745737]  ? hrtimer_interrupt+0x5/0x340
[  107.753961]  asm_call_on_stack+0x12/0x20
[  107.758672]  
[  107.761555]  do_softirq_own_stack+0x3f/0x50
[  107.766521]  ? ftrace_graph_caller+0xc0/0xc0
[  107.771246]  irq_exit_rcu+0xff/0x110
[  107.776116]  ? ftrace_graph_caller+0xc0/0xc0
[  107.780808]  sysvec_apic_timer_interrupt+0x38/0x90
[  107.786971]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[  107.792598] RIP: 0010:profile_graph_return+0x111/0x1d0
[  107.798204] Code: 75 e1 48 8b 45 d0 f6 c4 02 75 16 50 9d e8 f7 ff
02 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 c3 fb 02 00 ff
75 d0 9d <48> 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8d 7b 20 e8
77 78
[  107.817416] RSP: 0018:8882269b73a0 EFLAGS: 0286
[  107.823201] RAX: 8882269b73d8 RBX: 8882269b7428 RCX: dc00
[  107.830785] RDX: dc00 RSI: 9a7e4dbe RDI: 9a7a955d
[  107.838411] RBP: 8882269b73d8 R08: 9a7e4dd3 R09: ed1044de2529
[  107.846072] R10: 888226f12943 R11: ed1044de2528 R12: 8882308a67c0
[  107.853621] R13: 888226f12930 R14: 8882308a67c8 R15: 88822c7e4000
[  107.863449]  ? ftrace_return_to_handler+0x1a3/0x230
Aug 22 04:21:44 [  107.869545]  ? ftrace_return_to_handler+0x18e/0x230
intel-corei7-64 [  107.875178]  ? profile_graph_return+0x10d/0x1d0
user.info kernel: [  107.513103][  107.882521]  ? unwind_dump+0x100/0x100
 NETDEV WATCHDOG: eth0 (igb): tr[  107.889054]  ?
unwind_next_frame.part.0+0xe0/0x360
ansmit queue 2 t[  107.895638]  ftrace_return_to_handler+0x18e/0x230
imed out
[  107.902594]  ? function_graph_enter+0x2d0/0x2d0
[  107.907616]  ? unwind_next_frame+0x23/0x30
[  107.9126

[PATCH 00/49] DRM driver for Hikey 970

2020-08-19 Thread Mauro Carvalho Chehab
This patch series port the out-of-tree driver for Hikey 970 (which
should also support Hikey 960) from the official 96boards tree:

   https://github.com/96boards-hikey/linux/tree/hikey970-v4.9

Based on his history, this driver seems to be originally written
for Kernel 4.4, and was later ported to Kernel 4.9. The original
driver used to depend on ION (from Kernel 4.4) and had its own
implementation for FB dev API.

As I need to preserve the original history (with has patches from
both HiSilicon and from Linaro),  I'm starting from the original
patch applied there. The remaining patches are incremental,
and port this driver to work with upstream Kernel.

This driver doesn't depend on any firmware or on any special
userspace code. It works as-is with both X11 and Wayland.

Yet, I'm submitting it via staging due to the following reasons:

- It depends on the LDO3 power supply, which is provided by
  a regulator driver that it is currently on staging;
- Due to legal reasons, I need to preserve the authorship of
  each one responsbile for each patch. So, I need to start from
  the original patch from Kernel 4.4;
- There are still some problems I need to figure out how to solve:
   - The adv7535 can't get EDID data. Maybe it is a timing issue,
 but it requires more research to be sure about how to solve it;
   - The driver only accept resolutions on a defined list, as there's
 a known bug that this driver may have troubles with random
 resolutions. Probably due to a bug at the pixel clock settings;
   - Sometimes (at least with 1080p), it generates LDI underflow
 errors, which in turn causes the DRM to stop working. That
 happens for example when using gdm on Wayland and
 gnome on X11;
   - Probably related to the previous issue, when the monitor
 suspends due to DPMS, it doesn't return back to life.

So, IMO, the best is to keep it on staging for a while, until those
remaining bugs gets solved.

I added this series, together with the regulator driver and
a few other patches (including a hack to fix a Kernel 5.8 
regression at WiFi ) at:

https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master


Chen Feng (1):
  staging: hikey9xx: Add hisilicon DRM driver for hikey960/970

John Stultz (1):
  staging: hikey9xx/gpu: port it to work with Kernel v4.9

Liwei Cai (2):
  staging: hikey9xx/gpu: solve tearing issue of display
  staging: hikey9xx/gpu: resolve the performance issue by interrupt
mechanism

Mauro Carvalho Chehab (38):
  staging: hikey9xx/gpu: get rid of adv7535 fork
  staging: hikey9xx/gpu: rename the Kirin9xx namespace
  staging: hikey9xx/gpu: get rid of kirin9xx_fbdev.c
  staging: hikey9xx/gpu: get rid of some ifdefs
  staging: hikey9xx/gpu: rename the config option for Kirin970
  staging: hikey9xx/gpu: change the includes to reflect upstream
  staging: hikey9xx/gpu: port driver to upstream kAPIs
  staging: hikey9xx/gpu: add a copy of set_reg() function there
  staging: hikey9xx/gpu: get rid of ION headers
  staging: hikey9xx/gpu: add support for using a reserved CMA memory
  staging: hikey9xx/gpu: cleanup encoder attach logic
  staging: hikey9xx/gpu: Change the logic which sets the burst mode
  staging: hikey9xx/gpu: fix the DRM setting logic
  staging: hikey9xx/gpu: do some code cleanups
  staging: hikey9xx/gpu: use default GEM_CMA fops
  staging: hikey9xx/gpu: place vblank enable/disable at the right place
  staging: hikey9xx/gpu: remove an uneeded hack
  staging: hikey9xx/gpu: add a possible implementation for
atomic_disable
  staging: hikey9xx/gpu: register connector
  staging: hikey9xx/gpu: fix driver name
  staging: hikey9xx/gpu: get rid of iommu_format
  staging: hikey9xx/gpu: re-work the mode validation code
  staging: hikey9xx/gpu: add support for enable/disable ldo3 regulator
  staging: hikey9xx/gpu: add SPMI headers
  staging: hikey9xx/gpu: solve most coding style issues
  staging: hikey9xx/gpu: don't use iommu code
  staging: hikey9xx/gpu: add kirin9xx driver to the building system
  staging: hikey9xx/gpu: get rid of typedefs
  staging: hikey9xx/gpu: get rid of input/output macros
  staging: hikey9xx/gpu: get rid of some unused data
  staging: hikey9xx/gpu: place common definitions at kirin9xx_dpe.h
  staging: hikey9xx/gpu: get rid of DRM_HISI_KIRIN970
  dts: hisilicon: hi3670.dtsi: add I2C settings
  dts: hikey970-pinctrl.dtsi: add missing pinctrl settings
  dt: hisilicon: add support for the PMIC found on Hikey 970
  dts: add support for Hikey 970 DRM
  staging: hikey9xx/gpu: drop kirin9xx_pwm
  dt: display: Add binds for the DPE and DSI controller for Kirin
960/970

Xiubin Zhang (7):
  staging: hikey9xx/gpu: add support to hikey970 HDMI and panel
  staging: hikey9xx/gpu: Solve SR Cannot Display Problems.
  staging: hikey9xx/gpu: Solve HDMI compatibility Problem.
  staging: hikey9xx/gpu: Support MIPI DSI 3 lanes for hikey970.
  staging: hikey9xx/gpu: Solve SR test reset problem for hikey970.
  staging: hikey9xx/gpu: add debug 

[PATCH] staging: wilc1000: Fix memleak in wilc_sdio_probe

2020-08-19 Thread Dinghao Liu
When devm_clk_get() returns -EPROBE_DEFER, sdio_priv
should be freed just like when wilc_cfg80211_init()
fails.

Fixes: 8692b047e86cf ("staging: wilc1000: look for rtc_clk clock")
Signed-off-by: Dinghao Liu 
---
 drivers/net/wireless/microchip/wilc1000/sdio.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/microchip/wilc1000/sdio.c 
b/drivers/net/wireless/microchip/wilc1000/sdio.c
index 3ece7b0b0392..351ff909ab1c 100644
--- a/drivers/net/wireless/microchip/wilc1000/sdio.c
+++ b/drivers/net/wireless/microchip/wilc1000/sdio.c
@@ -149,9 +149,10 @@ static int wilc_sdio_probe(struct sdio_func *func,
wilc->dev = &func->dev;
 
wilc->rtc_clk = devm_clk_get(&func->card->dev, "rtc");
-   if (PTR_ERR_OR_ZERO(wilc->rtc_clk) == -EPROBE_DEFER)
+   if (PTR_ERR_OR_ZERO(wilc->rtc_clk) == -EPROBE_DEFER) {
+   kfree(sdio_priv);
return -EPROBE_DEFER;
-   else if (!IS_ERR(wilc->rtc_clk))
+   } else if (!IS_ERR(wilc->rtc_clk))
clk_prepare_enable(wilc->rtc_clk);
 
dev_info(&func->dev, "Driver Initializing success\n");
-- 
2.17.1



  1   2   3   4   >