[PATCH v3] scsi: NCR5380: Remove context check

2020-12-05 Thread Ahmed S. Darwish
NCR5380_poll_politely2() uses in_interrupt() and irqs_disabled() to
check if it is safe to sleep.

Such usage in drivers is phased out and Linus clearly requested that
code which changes behaviour depending on context should either be
separated, or the context be explicitly conveyed in an argument passed
by the caller.

Below is a context analysis of NCR5380_poll_politely2() uppermost
callers:

  - NCR5380_maybe_reset_bus(), task, invoked during device probe.
-> NCR5380_poll_politely()
-> do_abort()

  - NCR5380_select(), task, but can only sleep in the "release, then
re-acquire" regions of the spinlock held by its caller.
Sleeping invocations (lock released):
-> NCR5380_poll_politely2()

Atomic invocations (lock acquired):
-> NCR5380_reselect()
   -> NCR5380_poll_politely()
   -> do_abort()
   -> NCR5380_transfer_pio()

  - NCR5380_intr(), interrupt handler
-> NCR5380_dma_complete()
   -> NCR5380_transfer_pio()
  -> NCR5380_poll_politely()
-> NCR5380_reselect() (see above)

  - NCR5380_information_transfer(), task, but can only sleep in the
"release, then re-acquire" regions of the caller-held spinlock.
Sleeping invocations (lock released):
  - NCR5380_transfer_pio() -> NCR5380_poll_politely()
  - NCR5380_poll_politely()

Atomic invocations (lock acquired):
  - NCR5380_transfer_dma()
-> NCR5380_dma_recv_setup()
   => generic_NCR5380_precv() -> NCR5380_poll_politely()
   => macscsi_pread() -> NCR5380_poll_politely()

-> NCR5380_dma_send_setup()
   => generic_NCR5380_psend -> NCR5380_poll_politely2()
   => macscsi_pwrite() -> NCR5380_poll_politely()

-> NCR5380_poll_politely2()
-> NCR5380_dma_complete()
   -> NCR5380_transfer_pio()
  -> NCR5380_poll_politely()
  - NCR5380_transfer_pio() -> NCR5380_poll_politely

  - NCR5380_reselect(), atomic, always called with hostdata spinlock
held.

Since NCR5380_poll_politely2() already takes a "wait" argument in
jiffies, use it to determine if the function can sleep. Modify atomic
callers, which passed an unused wait value in terms of HZ, to pass zero.

Suggested-by: Finn Thain 
Co-developed-by: Sebastian Andrzej Siewior 
Signed-off-by: Ahmed S. Darwish 
Cc: Michael Schmitz 
Cc: 
---
 drivers/scsi/NCR5380.c   | 74 ++--
 drivers/scsi/NCR5380.h   |  3 +-
 drivers/scsi/g_NCR5380.c | 12 +++
 drivers/scsi/mac_scsi.c  | 10 +++---
 4 files changed, 53 insertions(+), 46 deletions(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index d654a6cc4162..448cd22214c0 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -132,7 +132,7 @@
 static unsigned int disconnect_mask = ~0;
 module_param(disconnect_mask, int, 0444);
 
-static int do_abort(struct Scsi_Host *);
+static int do_abort(struct Scsi_Host *, unsigned int);
 static void do_reset(struct Scsi_Host *);
 static void bus_reset_cleanup(struct Scsi_Host *);
 
@@ -197,7 +197,7 @@ static inline void set_resid_from_SCp(struct scsi_cmnd *cmd)
  * @reg2: Second 5380 register to poll
  * @bit2: Second bitmask to check
  * @val2: Second expected value
- * @wait: Time-out in jiffies
+ * @wait: Time-out in jiffies, 0 if sleeping is not allowed
  *
  * Polls the chip in a reasonably efficient manner waiting for an
  * event to occur. After a short quick poll we begin to yield the CPU
@@ -223,7 +223,7 @@ static int NCR5380_poll_politely2(struct NCR5380_hostdata 
*hostdata,
cpu_relax();
} while (n--);
 
-   if (irqs_disabled() || in_interrupt())
+   if (!wait)
return -ETIMEDOUT;
 
/* Repeatedly sleep for 1 ms until deadline */
@@ -486,7 +486,7 @@ static int NCR5380_maybe_reset_bus(struct Scsi_Host 
*instance)
break;
case 2:
shost_printk(KERN_ERR, instance, "bus busy, attempting 
abort\n");
-   do_abort(instance);
+   do_abort(instance, 1);
break;
case 4:
shost_printk(KERN_ERR, instance, "bus busy, attempting 
reset\n");
@@ -818,7 +818,7 @@ static void NCR5380_dma_complete(struct Scsi_Host *instance)
if (toPIO > 0) {
dsprintk(NDEBUG_DMA, instance,
 "Doing %d byte PIO to 0x%p\n", cnt, 
*data);
-   NCR5380_transfer_pio(instance, &p, &cnt, data);
+   NCR5380_transfer_pio(instance, &p, &cnt, data, 
0);
*count -= toPIO - cnt;
}
}
@@ -1185,7 +1185,7 @@ static bool NCR5380_select(struct Scsi_Host *instance, 
struct scsi_cmnd *cmd)
goto out;
}
if (!hostdata->selecting) {
-   do_abort(instance);
+   do_abort(insta

Re: [PATCH v2 08/17] driver core: Add fwnode link support

2020-12-05 Thread Leon Romanovsky
On Fri, Nov 20, 2020 at 06:02:23PM -0800, Saravana Kannan wrote:
> Add support for creating supplier-consumer links between fwnodes.  It is
> intended for internal use the driver core and generic firmware support
> code (eg. Device Tree, ACPI), so it is simple by design and the API
> provided is limited.
>
> Signed-off-by: Saravana Kannan 
> ---
>  drivers/base/core.c| 98 ++
>  drivers/of/dynamic.c   |  1 +
>  include/linux/fwnode.h | 14 ++
>  3 files changed, 113 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 401fa7e3505c..e2b246a44d1a 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -50,6 +50,104 @@ static LIST_HEAD(wait_for_suppliers);
>  static DEFINE_MUTEX(wfs_lock);
>  static LIST_HEAD(deferred_sync);
>  static unsigned int defer_sync_state_count = 1;
> +static DEFINE_MUTEX(fwnode_link_lock);
> +
> +/**
> + * fwnode_link_add - Create a link between two fwnode_handles.
> + * @con: Consumer end of the link.
> + * @sup: Supplier end of the link.
> + *
> + * Create a fwnode link between fwnode handles @con and @sup. The fwnode link
> + * represents the detail that the firmware lists @sup fwnode as supplying a
> + * resource to @con.
> + *
> + * The driver core will use the fwnode link to create a device link between 
> the
> + * two device objects corresponding to @con and @sup when they are created. 
> The
> + * driver core will automatically delete the fwnode link between @con and 
> @sup
> + * after doing that.
> + *
> + * Attempts to create duplicate links between the same pair of fwnode handles
> + * are ignored and there is no reference counting.

Sorry to ask, but why is that?
Isn't this a programmer error?

Thanks


[PATCH 4/8] tty: serial: jsm: Fixed file by added more spacing

2020-12-05 Thread Clement Smith
Fixed a coding style issue

Signed-off-by: Clement Smith 
---
 drivers/tty/serial/jsm/jsm_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
index 2bc5f32e59f4..45e212be64c4 100644
--- a/drivers/tty/serial/jsm/jsm_tty.c
+++ b/drivers/tty/serial/jsm/jsm_tty.c
@@ -610,7 +610,7 @@ void jsm_input(struct jsm_channel *ch)
if (*(ch->ch_equeue + tail + i) & UART_LSR_BI)
tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i),  TTY_BREAK);
else if (*(ch->ch_equeue + tail + i) & 
UART_LSR_PE)
-   tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_PARITY);
+   tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i), TTY_PARITY);
else if (*(ch->ch_equeue +tail +i) & 
UART_LSR_FE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_FRAME);
else
-- 
2.27.0



[PATCH 7/8] tty: serial: jsm: Fixed file by added more spacing

2020-12-05 Thread Clement Smith
Fixed a coding style issue

Signed-off-by: Clement Smith 
---
 drivers/tty/serial/jsm/jsm_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
index 19d2f0bc6c10..eab82fb6b384 100644
--- a/drivers/tty/serial/jsm/jsm_tty.c
+++ b/drivers/tty/serial/jsm/jsm_tty.c
@@ -614,7 +614,7 @@ void jsm_input(struct jsm_channel *ch)
else if (*(ch->ch_equeue + tail + i) & 
UART_LSR_FE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i), TTY_FRAME);
else
-   tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_NORMAL);
+   tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i), TTY_NORMAL);
}
} else {
tty_insert_flip_string(port, ch->ch_rqueue + tail, s);
-- 
2.27.0



[PATCH 8/8] tty: serial: jsm: Removed assignment in if statement

2020-12-05 Thread Clement Smith
Fixed a coding style issue

Signed-off-by: Clement Smith 
---
 drivers/tty/serial/jsm/jsm_tty.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
index eab82fb6b384..bfd4b55e6c74 100644
--- a/drivers/tty/serial/jsm/jsm_tty.c
+++ b/drivers/tty/serial/jsm/jsm_tty.c
@@ -742,7 +742,8 @@ void jsm_check_queue_flow_control(struct jsm_channel *ch)
int qleft;
 
/* Store how much space we have left in the queue */
-   if ((qleft = ch->ch_r_tail - ch->ch_r_head - 1) < 0)
+qleft = ch->ch_r_tail - ch->ch_r_head - 1;
+   if (qleft < 0)
qleft += RQUEUEMASK + 1;
 
/*
-- 
2.27.0



[PATCH 2/8] tty: serial: jsm: Fixed file by added more spacing

2020-12-05 Thread Clement Smith
Fixed a coding style issue

Signed-off-by: Clement Smith 
---
 drivers/tty/serial/jsm/jsm_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
index 512b77195e9f..202d6ba93313 100644
--- a/drivers/tty/serial/jsm/jsm_tty.c
+++ b/drivers/tty/serial/jsm/jsm_tty.c
@@ -608,7 +608,7 @@ void jsm_input(struct jsm_channel *ch)
 * format it likes.
 */
if (*(ch->ch_equeue + tail + i) & UART_LSR_BI)
-   tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i),  TTY_BREAK);
+   tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i),  TTY_BREAK);
else if (*(ch->ch_equeue +tail +i) & 
UART_LSR_PE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_PARITY);
else if (*(ch->ch_equeue +tail +i) & 
UART_LSR_FE)
-- 
2.27.0



[PATCH 6/8] tty: serial: jsm: Fixed file by added more spacing

2020-12-05 Thread Clement Smith
Fixed a coding style issue

Signed-off-by: Clement Smith 
---
 drivers/tty/serial/jsm/jsm_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
index 75c9bfa5077c..19d2f0bc6c10 100644
--- a/drivers/tty/serial/jsm/jsm_tty.c
+++ b/drivers/tty/serial/jsm/jsm_tty.c
@@ -612,7 +612,7 @@ void jsm_input(struct jsm_channel *ch)
else if (*(ch->ch_equeue + tail + i) & 
UART_LSR_PE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i), TTY_PARITY);
else if (*(ch->ch_equeue + tail + i) & 
UART_LSR_FE)
-   tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_FRAME);
+   tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i), TTY_FRAME);
else
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_NORMAL);
}
-- 
2.27.0



[PATCH 5/8] tty: serial: jsm: Fixed file by added more spacing

2020-12-05 Thread Clement Smith
Fixed a coding style issue

Signed-off-by: Clement Smith 
---
 drivers/tty/serial/jsm/jsm_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
index 45e212be64c4..75c9bfa5077c 100644
--- a/drivers/tty/serial/jsm/jsm_tty.c
+++ b/drivers/tty/serial/jsm/jsm_tty.c
@@ -611,7 +611,7 @@ void jsm_input(struct jsm_channel *ch)
tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i),  TTY_BREAK);
else if (*(ch->ch_equeue + tail + i) & 
UART_LSR_PE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i), TTY_PARITY);
-   else if (*(ch->ch_equeue +tail +i) & 
UART_LSR_FE)
+   else if (*(ch->ch_equeue + tail + i) & 
UART_LSR_FE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_FRAME);
else
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_NORMAL);
-- 
2.27.0



[PATCH 3/8] tty: serial: jsm: Fixed file by added more spacing

2020-12-05 Thread Clement Smith
Fixed a coding style issue

Signed-off-by: Clement Smith 
---
 drivers/tty/serial/jsm/jsm_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
index 202d6ba93313..2bc5f32e59f4 100644
--- a/drivers/tty/serial/jsm/jsm_tty.c
+++ b/drivers/tty/serial/jsm/jsm_tty.c
@@ -609,7 +609,7 @@ void jsm_input(struct jsm_channel *ch)
 */
if (*(ch->ch_equeue + tail + i) & UART_LSR_BI)
tty_insert_flip_char(port, 
*(ch->ch_rqueue + tail + i),  TTY_BREAK);
-   else if (*(ch->ch_equeue +tail +i) & 
UART_LSR_PE)
+   else if (*(ch->ch_equeue + tail + i) & 
UART_LSR_PE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_PARITY);
else if (*(ch->ch_equeue +tail +i) & 
UART_LSR_FE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_FRAME);
-- 
2.27.0



[PATCH 1/8] tty: serial: jsm: Fixed file by added more spacing

2020-12-05 Thread Clement Smith
Fixed a coding style issue

Signed-off-by: Clement Smith 
---
 drivers/tty/serial/jsm/jsm_tty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/jsm/jsm_tty.c b/drivers/tty/serial/jsm/jsm_tty.c
index 689774c073ca..512b77195e9f 100644
--- a/drivers/tty/serial/jsm/jsm_tty.c
+++ b/drivers/tty/serial/jsm/jsm_tty.c
@@ -607,7 +607,7 @@ void jsm_input(struct jsm_channel *ch)
 * Give the Linux ld the flags in the
 * format it likes.
 */
-   if (*(ch->ch_equeue +tail +i) & UART_LSR_BI)
+   if (*(ch->ch_equeue + tail + i) & UART_LSR_BI)
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i),  TTY_BREAK);
else if (*(ch->ch_equeue +tail +i) & 
UART_LSR_PE)
tty_insert_flip_char(port, 
*(ch->ch_rqueue +tail +i), TTY_PARITY);
-- 
2.27.0



!!!!! Ask Details For Relief

2020-12-05 Thread United Nations Covid-19 Relief Unit
You has been chosen via E-mail for the United Nations Covid-19 Relief F und, 
for more details reply to  sangior...@aclipisa.it

Best regards,
Dr. Susan Marshal


Re: [PATCH v2 07/17] driver core: Add fwnode_init()

2020-12-05 Thread Leon Romanovsky
On Fri, Nov 20, 2020 at 06:02:22PM -0800, Saravana Kannan wrote:
> There are multiple locations in the kernel where a struct fwnode_handle
> is initialized. Add fwnode_init() so that we have one way of
> initializing a fwnode_handle.
>
> Signed-off-by: Saravana Kannan 
> ---
>  drivers/acpi/property.c | 2 +-
>  drivers/acpi/scan.c | 2 +-
>  drivers/base/swnode.c   | 2 +-
>  drivers/firmware/efi/efi-init.c | 8 
>  include/linux/fwnode.h  | 6 ++
>  include/linux/of.h  | 2 +-
>  kernel/irq/irqdomain.c  | 2 +-
>  7 files changed, 15 insertions(+), 9 deletions(-)

In this series, I didn't find any extension of fwnode_init() to be it more
than simple assignment. This change looks to me like unnecessary churn and
obfuscation rather than improvement.

"...ops = &...;" is pretty standard in the kernel to initialize ops
structures.

Thanks


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

2020-12-05 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 'ca91cx42_alloc_consistent()' and
'tsi148_alloc_consistent()' GFP_KERNEL can be used because both functions
are called only from 'vme_alloc_consistent()' (vme.c). This function is
only called from the 'vme_user_probe()' probe function and no lock is
taken in the between.

When memory is allocated in 'ca91cx42_crcsr_init()' and
'tsi148_crcsr_init()' GFP_KERNEL can be used because both functions
are called only from their corresponding probe function and no lock is
taken in the between.

@@
@@
-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/vme/bridges/vme_ca91cx42.c | 13 +++--
 drivers/vme/bridges/vme_tsi148.c   | 13 +++--
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/vme/bridges/vme_ca91cx42.c 
b/drivers/vme/bridges/vme_ca91cx42.c
index ea938dc29c5e..439b0edeca08 100644
--- a/drivers/vme/bridges/vme_ca91cx42.c
+++ b/drivers/vme/bridges/vme_ca91cx42.c
@@ -1510,7 +1510,7 @@ static void *ca91cx42_alloc_consistent(struct device 
*parent, size_t size,
/* Find pci_dev container of dev */
pdev = to_pci_dev(parent);
 
-   return pci_alloc_consistent(pdev, size, dma);
+   return dma_alloc_coherent(&pdev->dev, size, dma, GFP_KERNEL);
 }
 
 static void ca91cx42_free_consistent(struct device *parent, size_t size,
@@ -1521,7 +1521,7 @@ static void ca91cx42_free_consistent(struct device 
*parent, size_t size,
/* Find pci_dev container of dev */
pdev = to_pci_dev(parent);
 
-   pci_free_consistent(pdev, size, vaddr, dma);
+   dma_free_coherent(&pdev->dev, size, vaddr, dma);
 }
 
 /*
@@ -1555,8 +1555,9 @@ static int ca91cx42_crcsr_init(struct vme_bridge 
*ca91cx42_bridge,
}
 
/* Allocate mem for CR/CSR image */
-   bridge->crcsr_kernel = pci_zalloc_consistent(pdev, VME_CRCSR_BUF_SIZE,
-&bridge->crcsr_bus);
+   bridge->crcsr_kernel = dma_alloc_coherent(&pdev->dev,
+ VME_CRCSR_BUF_SIZE,
+ &bridge->crcsr_bus, 
GFP_KERNEL);
if (!bridge->crcsr_kernel) {
dev_err(&pdev->dev, "Failed to allocate memory for CR/CSR "
"image\n");
@@ -1589,8 +1590,8 @@ static void ca91cx42_crcsr_exit(struct vme_bridge 
*ca91cx42_bridge,
/* Free image */
iowrite32(0, bridge->base + VCSR_TO);
 
-   pci_free_consistent(pdev, VME_CRCSR_BUF_SIZE, bridge->crcsr_kernel,
-   bridge->crcsr_bus);
+   dma_free_coherent(&pdev->dev, VME_CRCSR_BU

Re: [PATCH v2 0/9] Add support for Microsoft Surface System Aggregator Module

2020-12-05 Thread Leon Romanovsky
On Thu, Dec 03, 2020 at 10:26:31PM +0100, Maximilian Luz wrote:
> Hello,
>
> Here is version two of the Surface System Aggregator Module (SAM/SSAM)
> driver series, adding initial support for the embedded controller on 5th
> and later generation Microsoft Surface devices. Initial support includes
> the ACPI interface to the controller, via which battery and thermal
> information is provided on some of these devices.
>
> The previous version and cover letter detailing what this series is
> about can be found at
>
>   
> https://lore.kernel.org/platform-driver-x86/20201115192143.21571-1-luzmaximil...@gmail.com/
>
> This patch-set can also be found at the following repository and
> reference, if you prefer to look at a kernel tree instead of these
> emails:
>
>   https://github.com/linux-surface/kernel tags/s/surface-aggregator/v2
>
> Thank you all for the feedback to v1, I hope I have addressed all
> comments.


I think that it is too far fetched to attempt and expose UAPI headers
for some obscure char device that we are all know won't be around in
a couple of years from now due to the nature of how this embedded world
works.

More on that, the whole purpose of proposed interface is to debug and
not intended to be used by any user space code.

Also the idea that you are creating new bus just for this device doesn't
really sound right. I recommend you to take a look on auxiliary bus and
use it or come with very strong justifications why it is not fit yet.

I'm sorry to say, but this series is not ready to be merged yet.

NAK: Leon Romanovsky 

Thanks


Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance

2020-12-05 Thread Eli Cohen
On Fri, Dec 04, 2020 at 10:53:28AM +0800, Jason Wang wrote:
> 
> On 2020/12/3 下午8:24, Eli Cohen wrote:
> > > > It is mentioned in Parav's patchset that this will be coming in a
> > > > subsequent patch to his vdpa tool.
> > > So I think kernel has two options:
> > > - require a mac when device is created, we supply it to guest
> > Yes, the driver should always set VIRTIO_NET_F_MAC and provide a MAC -
> > either random or whatever configured using the vdpa too.
> 
> 
> A questions here, I think current mlx5 vdpa works for VF only. So I think
> the VF should have a given MAC? If yes, can we use that MAC?
> 
The MAC assigned to VF is by the NIC implementation. Both ther regular
NIC driver and the VDPA implementation can co-exist so we can't use the
NIC's MAC for VDPA. We want to steer traffic based on its destination
MAC address to either VDPA or regular NIC.


[PATCH v2 8/8] ufs/util.h: Apply new find_last_zero_bit.

2020-12-05 Thread Levi Yun
Former find_last_zero_bit in ufs makes complie error when we add
find_last_zero_bit in lib/find_bit.c
We remove former find_last_zero_bit in ufs which iterates per char,
And apply new find_last_zero_bit in lib.

Signed-off-by: Levi Yun 
---
 fs/ufs/util.h | 30 +++---
 1 file changed, 3 insertions(+), 27 deletions(-)

diff --git a/fs/ufs/util.h b/fs/ufs/util.h
index 4931bec1a01c..3024f2076feb 100644
--- a/fs/ufs/util.h
+++ b/fs/ufs/util.h
@@ -413,29 +413,6 @@ static inline unsigned _ubh_find_next_zero_bit_(
return (base << uspi->s_bpfshift) + pos - begin;
 }  
 
-static inline unsigned find_last_zero_bit (unsigned char * bitmap,
-   unsigned size, unsigned offset)
-{
-   unsigned bit, i;
-   unsigned char * mapp;
-   unsigned char map;
-
-   mapp = bitmap + (size >> 3);
-   map = *mapp--;
-   bit = 1 << (size & 7);
-   for (i = size; i > offset; i--) {
-   if ((map & bit) == 0)
-   break;
-   if ((i & 7) != 0) {
-   bit >>= 1;
-   } else {
-   map = *mapp--;
-   bit = 1 << 7;
-   }
-   }
-   return i;
-}
-
 #define ubh_find_last_zero_bit(ubh,begin,size,offset) 
_ubh_find_last_zero_bit_(uspi,ubh,begin,size,offset)
 static inline unsigned _ubh_find_last_zero_bit_(
struct ufs_sb_private_info * uspi, struct ufs_buffer_head * ubh,
@@ -453,15 +430,14 @@ static inline unsigned _ubh_find_last_zero_bit_(
size + (uspi->s_bpf - start), uspi->s_bpf)
- (uspi->s_bpf - start);
size -= count;
-   pos = find_last_zero_bit (ubh->bh[base]->b_data,
-   start, start - count);
-   if (pos > start - count || !size)
+   pos = find_last_zero_bit_le(ubh->bh[base]->b_data, start + 1);
+   if ((pos < start + 1 && pos > start - count) || !size)
break;
base--;
start = uspi->s_bpf;
}
return (base << uspi->s_bpfshift) + pos - begin;
-}  
+}
 
 #define ubh_isblockclear(ubh,begin,block) 
(!_ubh_isblockset_(uspi,ubh,begin,block))
 
-- 
2.27.0


Re: [PATCH v8 00/16] Add support for Clang LTO

2020-12-05 Thread Nathan Chancellor
On Fri, Dec 04, 2020 at 02:52:41PM -0800, Sami Tolvanen wrote:
> On Thu, Dec 3, 2020 at 2:32 PM Nick Desaulniers  
> wrote:
> >
> > So I'd recommend to Sami to simply make the Kconfig also depend on
> > clang's integrated assembler (not just llvm-nm and llvm-ar).
> 
> Sure, sounds good to me. What's the preferred way to test for this in Kconfig?
> 
> It looks like actually trying to test if we have an LLVM assembler
> (e.g. using $(as-instr,.section
> ".linker-options","e",@llvm_linker_options)) doesn't work as Kconfig
> doesn't pass -no-integrated-as to clang here. I could do something
> simple like $(success,echo $(LLVM) $(LLVM_IAS) | grep -q "1 1").
> 
> Thoughts?
> 
> Sami

I think

depends on $(success,test $(LLVM_IAS) -eq 1)

should work, at least according to my brief test.

Cheers,
Nathan


[PATCH v2 5/8] lib/find_bit_bench.c: Add find_last_zero_bit.

2020-12-05 Thread Levi Yun
Add bench test of find_last_zero_bit.

Also, this patch fix the unmatched iterations value with
find_next_bit and find_last_bit which happen when
the last bit set or not,
Let suppose, 4096 bitmap size and 4095 bit is set only.
In this case former find_next_bit returns iterations count as 0.
But find_last_bit returns it as 1.
This unmatched return value makes some confusion.
So we fix it.

Signed-off-by: Levi Yun 
---
 lib/find_bit_benchmark.c | 51 +---
 1 file changed, 37 insertions(+), 14 deletions(-)

diff --git a/lib/find_bit_benchmark.c b/lib/find_bit_benchmark.c
index 5637c5711db9..007371169008 100644
--- a/lib/find_bit_benchmark.c
+++ b/lib/find_bit_benchmark.c
@@ -35,14 +35,14 @@ static DECLARE_BITMAP(bitmap2, BITMAP_LEN) __initdata;
  */
 static int __init test_find_first_bit(void *bitmap, unsigned long len)
 {
-   unsigned long i, cnt;
+   unsigned long i = 0, cnt = 0;
ktime_t time;
 
time = ktime_get();
-   for (cnt = i = 0; i < len; cnt++) {
+   do {
i = find_first_bit(bitmap, len);
__clear_bit(i, bitmap);
-   }
+   } while (i++ < len && ++cnt);
time = ktime_get() - time;
pr_err("find_first_bit: %18llu ns, %6ld iterations\n", time, cnt);
 
@@ -51,12 +51,13 @@ static int __init test_find_first_bit(void *bitmap, 
unsigned long len)
 
 static int __init test_find_next_bit(const void *bitmap, unsigned long len)
 {
-   unsigned long i, cnt;
+   unsigned long i = 0, cnt = 0;
ktime_t time;
 
time = ktime_get();
-   for (cnt = i = 0; i < BITMAP_LEN; cnt++)
-   i = find_next_bit(bitmap, BITMAP_LEN, i) + 1;
+   do {
+   i = find_next_bit(bitmap, BITMAP_LEN, i);
+   } while (i++ < BITMAP_LEN && ++cnt);
time = ktime_get() - time;
pr_err("find_next_bit:  %18llu ns, %6ld iterations\n", time, cnt);
 
@@ -65,12 +66,13 @@ static int __init test_find_next_bit(const void *bitmap, 
unsigned long len)
 
 static int __init test_find_next_zero_bit(const void *bitmap, unsigned long 
len)
 {
-   unsigned long i, cnt;
+   unsigned long i = 0, cnt = 0;
ktime_t time;
 
time = ktime_get();
-   for (cnt = i = 0; i < BITMAP_LEN; cnt++)
-   i = find_next_zero_bit(bitmap, len, i) + 1;
+   do {
+   i = find_next_zero_bit(bitmap, len, i);
+   } while (i++ < BITMAP_LEN && ++cnt);
time = ktime_get() - time;
pr_err("find_next_zero_bit: %18llu ns, %6ld iterations\n", time, cnt);
 
@@ -84,27 +86,46 @@ static int __init test_find_last_bit(const void *bitmap, 
unsigned long len)
 
time = ktime_get();
do {
-   cnt++;
l = find_last_bit(bitmap, len);
if (l >= len)
break;
len = l;
-   } while (len);
+   } while (len >= 0 && ++cnt); /**< to find real 0 bit set. */
time = ktime_get() - time;
pr_err("find_last_bit:  %18llu ns, %6ld iterations\n", time, cnt);
 
return 0;
 }
 
+static int __init test_find_last_zero_bit(const void *bitmap, unsigned long 
len)
+{
+   unsigned long l, cnt = 0;
+   ktime_t time;
+
+   time = ktime_get();
+   do {
+   l = find_last_zero_bit(bitmap, len);
+   if (l >= len)
+   break;
+   len = l;
+   } while (len >= 0 && ++cnt); /**< to find real 0 bit set. */
+   time = ktime_get() - time;
+   pr_err("find_last_zero_bit:  %18llu ns, %6ld iterations\n", time, 
cnt);
+
+   return 0;
+}
+
+
 static int __init test_find_next_and_bit(const void *bitmap,
const void *bitmap2, unsigned long len)
 {
-   unsigned long i, cnt;
+   unsigned long i, cnt = 0;
ktime_t time;
 
time = ktime_get();
-   for (cnt = i = 0; i < BITMAP_LEN; cnt++)
-   i = find_next_and_bit(bitmap, bitmap2, BITMAP_LEN, i + 1);
+   do {
+   i = find_next_and_bit(bitmap, bitmap2, BITMAP_LEN, i);
+   } while (i++ < BITMAP_LEN && ++cnt);
time = ktime_get() - time;
pr_err("find_next_and_bit:  %18llu ns, %6ld iterations\n", time, cnt);
 
@@ -123,6 +144,7 @@ static int __init find_bit_test(void)
test_find_next_bit(bitmap, BITMAP_LEN);
test_find_next_zero_bit(bitmap, BITMAP_LEN);
test_find_last_bit(bitmap, BITMAP_LEN);
+   test_find_last_zero_bit(bitmap, BITMAP_LEN);
 
/*
 * test_find_first_bit() may take some time, so
@@ -144,6 +166,7 @@ static int __init find_bit_test(void)
test_find_next_bit(bitmap, BITMAP_LEN);
test_find_next_zero_bit(bitmap, BITMAP_LEN);
test_find_last_bit(bitmap, BITMAP_LEN);
+   test_find_last_zero_bit(bitmap, BITMAP_LEN);
test_find_first_bit(bitmap, BITMAP_LEN);
test_find_next_and_bit(bitmap, bitmap2, BITMAP_LEN);
 
-- 
2.27.0


[PATCH v2 6/8] lib/find_bit: Add test-module,find_last_zero_bit

2020-12-05 Thread Levi Yun
Add test module to test find_last_zero_bit and
find_each_*_bit_revserse.

Signed-off-by: Levi Yun 
---
 lib/Kconfig.debug|   8 ++
 lib/Makefile |   1 +
 lib/test_find_last_bit.c | 235 +++
 3 files changed, 244 insertions(+)
 create mode 100644 lib/test_find_last_bit.c

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c789b39ed527..481e366d0e82 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -2188,6 +2188,14 @@ config FIND_BIT_BENCHMARK
 
  If unsure, say N.
 
+config TEST_FIND_LAST_BIT
+   tristate "Test find_last_*_bit functions"
+   help
+ This builds the "test_find_last_bit" module that measure 
find_last_*_bit()
+ functions performance.
+
+ If unsure, say N.
+
 config TEST_FIRMWARE
tristate "Test firmware loading via userspace interface"
depends on FW_LOADER
diff --git a/lib/Makefile b/lib/Makefile
index ce45af50983a..310719df6207 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -58,6 +58,7 @@ obj-y += hexdump.o
 obj-$(CONFIG_TEST_HEXDUMP) += test_hexdump.o
 obj-y += kstrtox.o
 obj-$(CONFIG_FIND_BIT_BENCHMARK) += find_bit_benchmark.o
+obj-$(CONFIG_TEST_FIND_LAST_BIT) += test_find_last_bit.o
 obj-$(CONFIG_TEST_BPF) += test_bpf.o
 obj-$(CONFIG_TEST_FIRMWARE) += test_firmware.o
 obj-$(CONFIG_TEST_BITOPS) += test_bitops.o
diff --git a/lib/test_find_last_bit.c b/lib/test_find_last_bit.c
new file mode 100644
index ..579866c476d1
--- /dev/null
+++ b/lib/test_find_last_bit.c
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test for find_prev_*_bit functions.
+ *
+ * Copyright (c) 2020 Levi Yun.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define BITMAP_LEN (4096UL * 8 * 10)
+#define BITMAP_LAST_IDXBITMAP_LEN - 1
+
+
+static DECLARE_BITMAP(zero_bitmap, BITMAP_LEN) __initdata;
+static DECLARE_BITMAP(full_bitmap, BITMAP_LEN) __initdata;
+
+static int __init test_for_each_clear_rev(const void *bitmap, unsigned long 
len)
+{
+   unsigned long cur;
+   unsigned long expect = BITMAP_LAST_IDX;
+
+   pr_err("[%s:%d] Start test clear full iteration\n", __func__, __LINE__);
+
+   len = BITMAP_LEN;
+
+   for_each_clear_bit_reverse(cur, bitmap, len) {
+   if (cur != expect) {
+   pr_err("[%s:%d] full iteration fail!,  expect: %lu, 
cur: %lu\n",
+   __func__, __LINE__, expect, cur);
+
+   return 0;
+   }
+
+   expect--;
+   }
+
+   len = BITMAP_LEN;
+
+   cur = len / 3;
+   expect = cur;
+   pr_err("[%s:%d] Success\n", __func__, __LINE__);
+
+   pr_err("[%s:%d] Start test clear iteration with starting point\n", 
__func__, __LINE__);
+   for_each_clear_bit_from_reverse(cur, bitmap, len) {
+   if (cur != expect) {
+   pr_err("[%s:%d] full iteration fail!,  expect: %lu, 
cur: %lu\n",
+   __func__, __LINE__, expect, cur);
+
+   return 0;
+   }
+
+   expect--;
+   }
+
+   pr_err("[%s:%d] Success\n", __func__, __LINE__);
+
+   return 0;
+}
+
+static int __init test_for_each_set_rev(const void *bitmap, unsigned long len)
+{
+   unsigned long cur;
+   unsigned long expect = BITMAP_LAST_IDX;
+
+   len = BITMAP_LEN;
+   pr_err("[%s:%d] Start test set full iteration\n", __func__, __LINE__);
+   for_each_set_bit_reverse(cur, bitmap, len) {
+   if (cur != expect) {
+   pr_err("[%s:%d] full iteration fail!,  expect: %lu, 
cur: %lu\n",
+   __func__, __LINE__, expect, cur);
+
+   return 0;
+   }
+
+   expect--;
+   }
+   pr_err("[%s:%d] Success\n", __func__, __LINE__);
+
+
+   len = BITMAP_LEN;
+   cur = len / 3;
+   expect =  cur;
+
+   pr_err("[%s:%d] Start test set iteration with starting point\n", 
__func__, __LINE__);
+   for_each_set_bit_from_reverse(cur, bitmap, len) {
+   if (cur != expect) {
+   pr_err("[%s:%d] full iteration fail!,  expect: %lu, 
cur: %lu\n",
+   __func__, __LINE__, expect, cur);
+
+   return 0;
+   }
+
+   expect--;
+   }
+   pr_err("[%s:%d] Success\n", __func__, __LINE__);
+
+   return 0;
+}
+
+static int __init test_find_last_bit_clear_middle(void *bitmap)
+{
+   unsigned long idx;
+   unsigned long len = 4096;
+
+   pr_err("[%s] Start test\n", __func__);
+
+   clear_bit(1, bitmap);
+   clear_bit(65, bitmap);
+   clear_bit(136, bitmap);
+   clear_bit(4095, bitmap);
+
+   idx = find_last_zero_bit(bitmap, len);
+   if (idx != 4095) {
+   pr_err("[%s] Fail! expect: %u, idx: %lu\n", __func__,

[PATCH v2 7/8] btrfs/free-space-cache.c: Apply find_last_zero_bit

2020-12-05 Thread Levi Yun
In steal_from_bitmap_to_front function, it finds last_zero_bit from i
using for_each_clear_bit.
But this makes some overhead that it starts from the 0 bit.
By adding find_last_zero_bit, I try to remove this overhead and
improve readibility.

Signed-off-by: Levi Yun 
---
 fs/btrfs/free-space-cache.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index af0013d3df63..6d393c834fdd 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2372,7 +2372,6 @@ static bool steal_from_bitmap_to_front(struct 
btrfs_free_space_ctl *ctl,
u64 bitmap_offset;
unsigned long i;
unsigned long j;
-   unsigned long prev_j;
u64 bytes;
 
bitmap_offset = offset_to_bitmap(ctl, info->offset);
@@ -2388,20 +2387,15 @@ static bool steal_from_bitmap_to_front(struct 
btrfs_free_space_ctl *ctl,
return false;
 
i = offset_to_bit(bitmap->offset, ctl->unit, info->offset) - 1;
-   j = 0;
-   prev_j = (unsigned long)-1;
-   for_each_clear_bit_from(j, bitmap->bitmap, BITS_PER_BITMAP) {
-   if (j > i)
-   break;
-   prev_j = j;
-   }
-   if (prev_j == i)
-   return false;
+   j = find_last_zero_bit(bitmap->bitmap, i);
 
-   if (prev_j == (unsigned long)-1)
-   bytes = (i + 1) * ctl->unit;
-   else
-   bytes = (i - prev_j) * ctl->unit;
+   if (j == i) {
+   if (!test_bit(i, bitmap->bitmap))
+   return false;
+   else
+   bytes = (i + 1) * ctl->unit;
+   } else
+   bytes = (i - j) * ctl->unit;
 
info->offset -= bytes;
info->bytes += bytes;
-- 
2.27.0


[PATCH v2 4/8] bitops/le.h: Add le support for find_last_bit

2020-12-05 Thread Levi Yun
Inspired find_next_*_bit function series, add find_last_zero_bit.
These patch adds declarations for find_last_zero_bit.
This patch is for le support of find_last_bit and find_last_bit_zero.

Signed-off-by: Levi Yun 
---
 include/asm-generic/bitops/le.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/asm-generic/bitops/le.h b/include/asm-generic/bitops/le.h
index 188d3eba3ace..3d6661cc8077 100644
--- a/include/asm-generic/bitops/le.h
+++ b/include/asm-generic/bitops/le.h
@@ -27,6 +27,18 @@ static inline unsigned long find_first_zero_bit_le(const 
void *addr,
return find_first_zero_bit(addr, size);
 }
 
+static inline unsigned long find_last_bit_le(const void *addr,
+   unsigned long size)
+{
+   return find_last_bit(addr, size);
+}
+
+static inline unsigned long find_last_zero_bit_le(const void *addr,
+   unsigned long size)
+{
+   return find_last_zero_bit(addr, size);
+}
+
 #elif defined(__BIG_ENDIAN)
 
 #define BITOP_LE_SWIZZLE   ((BITS_PER_LONG-1) & ~0x7)
@@ -46,6 +58,14 @@ extern unsigned long find_next_bit_le(const void *addr,
find_next_zero_bit_le((addr), (size), 0)
 #endif
 
+#ifndef find_last_zero_bit_le
+extern unsigned long find_last_zero_bit_le(const void *addr, unsigned long 
size);
+#endif
+
+#ifndef find_last_bit_le
+extern unsigned long find_last_bit_le(const void *addr, unsigned long size);
+#endif
+
 #else
 #error "Please fix "
 #endif
-- 
2.27.0


[PATCH v2 2/8] linux/bitops.h: Add find_each_*_bit_reverse macros

2020-12-05 Thread Levi Yun
Add reverse routine for find_each_*_bit using find_last_bit and
find_last_zero_bit.
for correspondant usage wtih find_each_*_bit macros we use same
parameters,
But when we use these macro different from find_each_*_bit,
@size should be a variable NOT constants.

Signed-off-by: Levi Yun 
---
 include/linux/bitops.h | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index 5b74bdf159d6..f6ab611ca732 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -50,6 +50,31 @@ extern unsigned long __sw_hweight64(__u64 w);
 (bit) < (size);\
 (bit) = find_next_zero_bit((addr), (size), (bit) + 1))
 
+/**
+ * find_each_*_reverse's @size should be variable NOT constant.
+ */
+#define for_each_set_bit_reverse(bit, addr, size) \
+   for ((bit) = find_last_bit((addr), (size)); \
+(bit) < (size) && (size);  \
+(size) = (bit), (bit) = find_last_bit((addr), (size)))
+
+/* same as for_each_set_bit_reverse() but use bit as value to start with */
+#define for_each_set_bit_from_reverse(bit, addr, size) \
+   for ((size) = (bit + 1), (bit) = find_last_bit((addr), (size)); \
+(bit) < (size) && (size);  \
+(size) = (bit), (bit) = find_last_bit((addr), (size)))
+
+#define for_each_clear_bit_reverse(bit, addr, size) \
+   for ((bit) = find_last_zero_bit((addr), (size));\
+(bit) < (size) && (size);  \
+(size) = (bit), (bit) = find_last_zero_bit((addr), (size)))
+
+/* same as for_each_clear_bit_reverse() but use bit as value to start with */
+#define for_each_clear_bit_from_reverse(bit, addr, size) \
+   for ((size) = (bit + 1), (bit) = find_last_zero_bit((addr), (size));
\
+(bit) < (size) && (size);  \
+(size) = (bit), (bit) = find_last_zero_bit((addr), (size)))
+
 /**
  * for_each_set_clump8 - iterate over bitmap for each 8-bit clump with set bits
  * @start: bit offset to start search and to store the current iteration offset
@@ -283,17 +308,5 @@ static __always_inline void __assign_bit(long nr, volatile 
unsigned long *addr,
 })
 #endif
 
-#ifndef find_last_bit
-/**
- * find_last_bit - find the last set bit in a memory region
- * @addr: The address to start the search at
- * @size: The number of bits to search
- *
- * Returns the bit number of the last set bit, or size.
- */
-extern unsigned long find_last_bit(const unsigned long *addr,
-  unsigned long size);
-#endif
-
 #endif /* __KERNEL__ */
 #endif
-- 
2.27.0


[PATCH v2 3/8] bitops/find.h: Add declaration find_last_zero_bit

2020-12-05 Thread Levi Yun
Inspired find_next_*_bit function series, add find_last_zero_bit.
These patch adds declarations for find_last_zero_bit.
Also, I move declaration of find_last_bit to asm-generic/bitops/find.h
Because:
I think its declaration need not to in __KERNEL__ macro compared to
find_next_*_bit and find_first_*_bit.

Signed-off-by: Levi Yun 
---
 include/asm-generic/bitops/find.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/asm-generic/bitops/find.h 
b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..eeb2d6669f83 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -80,6 +80,31 @@ extern unsigned long find_first_zero_bit(const unsigned long 
*addr,
 
 #endif /* CONFIG_GENERIC_FIND_FIRST_BIT */
 
+#ifndef find_last_bit
+/**
+ * find_last_bit - find the last set bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The number of bits to search
+ *
+ * Returns the bit number of the last set bit, or size.
+ */
+extern unsigned long find_last_bit(const unsigned long *addr,
+  unsigned long size);
+#endif
+
+#ifndef find_last_zero_bit
+/**
+ * find_last_zero_bit - find the last cleared bit in a memory region
+ * @addr: The address to start the search at
+ * @size: The maximum number of bits to search
+ *
+ * Returns the bit number of the first cleared bit.
+ * If no bits are zero, returns @size.
+ */
+extern unsigned long find_last_zero_bit(const unsigned long *addr,
+unsigned long size);
+#endif
+
 /**
  * find_next_clump8 - find next 8-bit clump with set bits in a memory region
  * @clump: location to store copy of found clump
-- 
2.27.0


[PATCH v2 1/8] lib/find_bit.c: Add find_last_zero_bit

2020-12-05 Thread Levi Yun
Inspired find_next_*_bit and find_last_bit, add find_last_zero_bit
And add le support about find_last_bit and find_last_zero_bit.

Signed-off-by: Levi Yun 
---
 lib/find_bit.c | 64 --
 1 file changed, 62 insertions(+), 2 deletions(-)

diff --git a/lib/find_bit.c b/lib/find_bit.c
index 4a8751010d59..f9dda2bf7fa9 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -90,7 +90,7 @@ unsigned long find_next_zero_bit(const unsigned long *addr, 
unsigned long size,
 EXPORT_SYMBOL(find_next_zero_bit);
 #endif
 
-#if !defined(find_next_and_bit)
+#ifndef find_next_and_bit
 unsigned long find_next_and_bit(const unsigned long *addr1,
const unsigned long *addr2, unsigned long size,
unsigned long offset)
@@ -141,7 +141,7 @@ unsigned long find_last_bit(const unsigned long *addr, 
unsigned long size)
 {
if (size) {
unsigned long val = BITMAP_LAST_WORD_MASK(size);
-   unsigned long idx = (size-1) / BITS_PER_LONG;
+   unsigned long idx = (size - 1) / BITS_PER_LONG;
 
do {
val &= addr[idx];
@@ -156,6 +156,27 @@ unsigned long find_last_bit(const unsigned long *addr, 
unsigned long size)
 EXPORT_SYMBOL(find_last_bit);
 #endif
 
+#ifndef find_last_zero_bit
+unsigned long find_last_zero_bit(const unsigned long *addr, unsigned long size)
+{
+   if (size) {
+   unsigned long val = BITMAP_LAST_WORD_MASK(size);
+   unsigned long idx = (size - 1) / BITS_PER_LONG;
+
+   do {
+   val &= ~addr[idx];
+   if (val)
+   return idx * BITS_PER_LONG + __fls(val);
+
+   val = ~0ul;
+   } while (idx--);
+   }
+
+   return size;
+}
+EXPORT_SYMBOL(find_last_zero_bit);
+#endif
+
 #ifdef __BIG_ENDIAN
 
 #ifndef find_next_zero_bit_le
@@ -176,6 +197,45 @@ unsigned long find_next_bit_le(const void *addr, unsigned
 EXPORT_SYMBOL(find_next_bit_le);
 #endif
 
+static unsigned long _find_last_bit_le(const unsigned long *addr,
+   unsigned long size, unsigned long invert)
+{
+   if (size) {
+   unsigned long val = BITMAP_LAST_WORD_MASK(size);
+   unsigned long tmp;
+   unsigned long idx = (size - 1) / BITS_PER_LONG;
+
+   val = swab(val);
+
+   do {
+   tmp = swab(addr[idx]);
+   tmp ^= invert;
+   val &= tmp;
+   if (val)
+   return idx * BITS_PER_LONG + __fls(val);
+
+   val = ~0ul;
+   } while (idx--);
+   }
+   return size;
+}
+
+#ifndef find_last_zero_bit_le
+unsigned long find_last_zero_bit_le(const unsigned void *addr, unsigned long 
size)
+{
+   return _find_last_bit_le(addr, size, ~0UL);
+}
+EXPORT_SYMBOL(find_last_zero_bit_le);
+#endif
+
+#ifdef find_last_bit_le
+unsigned long find_last_bit_le(const unsigned void *addr, unsigned long size)
+{
+   return _find_last_bit_le(addr, size, 0UL);
+}
+EXPORT_SYMBOL(find_last_bit_le);
+#endif
+
 #endif /* __BIG_ENDIAN */
 
 unsigned long find_next_clump8(unsigned long *clump, const unsigned long *addr,
-- 
2.27.0


[PATCH] Debug config option for including cpu thread id in fault and signal info

2020-12-05 Thread Andrew G. Morgan
This option defaults to off.

I found this useful doing some fault isolation on an out of warranty
PC. I found one CPU core was consistently segfaulting and, together
with isolcpus=,... I was able to breathe some life back into that
machine.

Since the si_errno value is generally hard-coded as zero for most signals,
userspace generally ignores it. Indeed, where I have tried it, the
userspace programs appear to be remarkably tolerant of this re-purposing
of the si_errno value.

Signed-off-by: Andrew G. Morgan 
---
 init/Kconfig| 16 
 kernel/signal.c | 21 ++---
 2 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 02d13ae27abb..74f1202c449a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -634,6 +634,22 @@ config PSI_DEFAULT_DISABLED
 
 endmenu # "CPU/Task time and stats accounting"
 
+config SIG_ERRNO_HAS_THREAD_INFO
+   bool "Debug thread source for faults and interrupts"
+   default n
+   help
+ Select this to reveal to userspace, via siginfo_t.si_errno,
+ the HW thread number associated with a fault or signal
+ source. This feature has a number of HW debugging and
+ performance applications. For example, if a core  seems
+ to be unstable, isolcpus= at boot can help avoid using
+ it.
+
+ The legacy and default value for this is mostly 0 for faults
+ and signals, see 'man sigaction' for details. To distinguish
+ thread 0 from this legacy, when the si_errno value holds a
+ valid thread number, its uppermost bit is also set to 1.
+
 config CPU_ISOLATION
bool "CPU isolation"
depends on SMP || COMPILE_TEST
diff --git a/kernel/signal.c b/kernel/signal.c
index ef8f2a28d37c..523b93ec89f9 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1617,13 +1618,19 @@ send_sig(int sig, struct task_struct *p, int priv)
 }
 EXPORT_SYMBOL(send_sig);
 
+#ifdef CONFIG_SIG_ERRNO_HAS_THREAD_INFO
+#define ZERO_OR_THREAD_INDEX ((1<<(8*sizeof(int)-1))|task_cpu(current))
+#else
+#define ZERO_OR_THREAD_INDEX 0
+#endif
+
 void force_sig(int sig)
 {
struct kernel_siginfo info;
 
clear_siginfo(&info);
info.si_signo = sig;
-   info.si_errno = 0;
+   info.si_errno = ZERO_OR_THREAD_INDEX;
info.si_code = SI_KERNEL;
info.si_pid = 0;
info.si_uid = 0;
@@ -1659,7 +1666,7 @@ int force_sig_fault_to_task(int sig, int code, void 
__user *addr
 
clear_siginfo(&info);
info.si_signo = sig;
-   info.si_errno = 0;
+   info.si_errno = ZERO_OR_THREAD_INDEX;
info.si_code  = code;
info.si_addr  = addr;
 #ifdef __ARCH_SI_TRAPNO
@@ -1691,7 +1698,7 @@ int send_sig_fault(int sig, int code, void __user *addr
 
clear_siginfo(&info);
info.si_signo = sig;
-   info.si_errno = 0;
+   info.si_errno = ZERO_OR_THREAD_INDEX;
info.si_code  = code;
info.si_addr  = addr;
 #ifdef __ARCH_SI_TRAPNO
@@ -1712,7 +1719,7 @@ int force_sig_mceerr(int code, void __user *addr, short 
lsb)
WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
clear_siginfo(&info);
info.si_signo = SIGBUS;
-   info.si_errno = 0;
+   info.si_errno = ZERO_OR_THREAD_INDEX;
info.si_code = code;
info.si_addr = addr;
info.si_addr_lsb = lsb;
@@ -1726,7 +1733,7 @@ int send_sig_mceerr(int code, void __user *addr, short 
lsb, struct task_struct *
WARN_ON((code != BUS_MCEERR_AO) && (code != BUS_MCEERR_AR));
clear_siginfo(&info);
info.si_signo = SIGBUS;
-   info.si_errno = 0;
+   info.si_errno = ZERO_OR_THREAD_INDEX;
info.si_code = code;
info.si_addr = addr;
info.si_addr_lsb = lsb;
@@ -1740,7 +1747,7 @@ int force_sig_bnderr(void __user *addr, void __user 
*lower, void __user *upper)
 
clear_siginfo(&info);
info.si_signo = SIGSEGV;
-   info.si_errno = 0;
+   info.si_errno = ZERO_OR_THREAD_INDEX;
info.si_code  = SEGV_BNDERR;
info.si_addr  = addr;
info.si_lower = lower;
@@ -1755,7 +1762,7 @@ int force_sig_pkuerr(void __user *addr, u32 pkey)
 
clear_siginfo(&info);
info.si_signo = SIGSEGV;
-   info.si_errno = 0;
+   info.si_errno = ZERO_OR_THREAD_INDEX;
info.si_code  = SEGV_PKUERR;
info.si_addr  = addr;
info.si_pkey  = pkey;
-- 
2.26.2



Re: [PATCH 1/5] media: dt-bindings: add the required property 'additionalProperties'

2020-12-05 Thread Leizhen (ThunderTown)



On 2020/12/4 18:56, Philipp Zabel wrote:
> On Fri, 2020-12-04 at 17:38 +0800, Zhen Lei wrote:
>> When I do dt_binding_check for any YAML file, below wanring is always
>> reported:
>>
>> xxx/media/coda.yaml: 'additionalProperties' is a required property
>> xxx/media/coda.yaml: ignoring, error in schema:
>> warning: no schema found in file: xxx/media/coda.yaml
>>
>> There are three properties defined in allOf, they should be explicitly
>> declared. Otherwise, "additionalProperties: false" will prohibit them.
>>
>> Signed-off-by: Zhen Lei 
> 
> Thank you, there already is a patch to fix this:
> 
> https://lore.kernel.org/linux-media/20201117200752.4004368-1-r...@kernel.org/

OK. I found it temporarily during do a JSON conversion,I have not subscribed the
dt-binding maillist.

> 
> regards
> Philipp
> 
> .
> 



Re: [PATCH 1/1] dt-bindings: eliminate yamllint warnings

2020-12-05 Thread Leizhen (ThunderTown)



On 2020/12/5 1:41, Mark Brown wrote:
> On Fri, Dec 04, 2020 at 10:42:26AM +0800, Zhen Lei wrote:
>> All warnings are related only to "wrong indentation", except one:
>> Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: \
>> [error] missing document start "---" (document-start)
> 
> It would make life easier (and be more normal practice) to split this up
> by driver/subsystem and send a bunch of separate patches to the relevant
> maintainers, this makes it much easier to review and handle things.

Okay, I'll split this patch and send them separately. I'm not going to mark
the new patches as v2 to save trouble.

> 



Re: [PATCH v1 bpf-next 11/11] bpf: Test BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.

2020-12-05 Thread Kuniyuki Iwashima
I'm sending this mail just for logging because I failed to send mails only 
to LKML, netdev, and bpf yesterday.


From:   Martin KaFai Lau 
Date:   Fri, 4 Dec 2020 17:50:00 -0800
> On Tue, Dec 01, 2020 at 11:44:18PM +0900, Kuniyuki Iwashima wrote:
> > This patch adds a test for BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.
> > 
> > Reviewed-by: Benjamin Herrenschmidt 
> > Signed-off-by: Kuniyuki Iwashima 
> > ---
> >  .../bpf/prog_tests/migrate_reuseport.c| 164 ++
> >  .../bpf/progs/test_migrate_reuseport_kern.c   |  54 ++
> >  2 files changed, 218 insertions(+)
> >  create mode 100644 
> > tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
> >  create mode 100644 
> > tools/testing/selftests/bpf/progs/test_migrate_reuseport_kern.c
> > 
> > diff --git a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c 
> > b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
> > new file mode 100644
> > index ..87c72d9ccadd
> > --- /dev/null
> > +++ b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
> > @@ -0,0 +1,164 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Check if we can migrate child sockets.
> > + *
> > + *   1. call listen() for 5 server sockets.
> > + *   2. update a map to migrate all child socket
> > + *to the last server socket (migrate_map[cookie] = 4)
> > + *   3. call connect() for 25 client sockets.
> > + *   4. call close() for first 4 server sockets.
> > + *   5. call accept() for the last server socket.
> > + *
> > + * Author: Kuniyuki Iwashima 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define NUM_SOCKS 5
> > +#define LOCALHOST "127.0.0.1"
> > +#define err_exit(condition, message) \
> > +   do {  \
> > +   if (condition) {  \
> > +   perror("ERROR: " message " ");\
> > +   exit(1);  \
> > +   } \
> > +   } while (0)
> > +
> > +__u64 server_fds[NUM_SOCKS];
> > +int prog_fd, reuseport_map_fd, migrate_map_fd;
> > +
> > +
> > +void setup_bpf(void)
> > +{
> > +   struct bpf_object *obj;
> > +   struct bpf_program *prog;
> > +   struct bpf_map *reuseport_map, *migrate_map;
> > +   int err;
> > +
> > +   obj = bpf_object__open("test_migrate_reuseport_kern.o");
> > +   err_exit(libbpf_get_error(obj), "opening BPF object file failed");
> > +
> > +   err = bpf_object__load(obj);
> > +   err_exit(err, "loading BPF object failed");
> > +
> > +   prog = bpf_program__next(NULL, obj);
> > +   err_exit(!prog, "loading BPF program failed");
> > +
> > +   reuseport_map = bpf_object__find_map_by_name(obj, "reuseport_map");
> > +   err_exit(!reuseport_map, "loading BPF reuseport_map failed");
> > +
> > +   migrate_map = bpf_object__find_map_by_name(obj, "migrate_map");
> > +   err_exit(!migrate_map, "loading BPF migrate_map failed");
> > +
> > +   prog_fd = bpf_program__fd(prog);
> > +   reuseport_map_fd = bpf_map__fd(reuseport_map);
> > +   migrate_map_fd = bpf_map__fd(migrate_map);
> > +}
> > +
> > +void test_listen(void)
> > +{
> > +   struct sockaddr_in addr;
> > +   socklen_t addr_len = sizeof(addr);
> > +   int i, err, optval = 1, migrated_to = NUM_SOCKS - 1;
> > +   __u64 value;
> > +
> > +   addr.sin_family = AF_INET;
> > +   addr.sin_port = htons(80);
> > +   inet_pton(AF_INET, LOCALHOST, &addr.sin_addr.s_addr);
> > +
> > +   for (i = 0; i < NUM_SOCKS; i++) {
> > +   server_fds[i] = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
> > +   err_exit(server_fds[i] == -1, "socket() for listener sockets 
> > failed");
> > +
> > +   err = setsockopt(server_fds[i], SOL_SOCKET, SO_REUSEPORT,
> > +&optval, sizeof(optval));
> > +   err_exit(err == -1, "setsockopt() for SO_REUSEPORT failed");
> > +
> > +   if (i == 0) {
> > +   err = setsockopt(server_fds[i], SOL_SOCKET, 
> > SO_ATTACH_REUSEPORT_EBPF,
> > +&prog_fd, sizeof(prog_fd));
> > +   err_exit(err == -1, "setsockopt() for 
> > SO_ATTACH_REUSEPORT_EBPF failed");
> > +   }
> > +
> > +   err = bind(server_fds[i], (struct sockaddr *)&addr, addr_len);
> > +   err_exit(err == -1, "bind() failed");
> > +
> > +   err = listen(server_fds[i], 32);
> > +   err_exit(err == -1, "listen() failed");
> > +
> > +   err = bpf_map_update_elem(reuseport_map_fd, &i, &server_fds[i], 
> > BPF_NOEXIST);
> > +   err_exit(err == -1, "updating BPF reuseport_map failed");
> > +
> > +   err = bpf_map_lookup_elem(reuseport_map_fd, &i, &value);
> > +   err_exit(err == -1, "looking up BPF reuseport_map failed");
> > +
> > +   printf("fd[%d] (coo

Re: [PATCH v1 bpf-next 03/11] tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.

2020-12-05 Thread Kuniyuki Iwashima
I'm sending this mail just for logging because I failed to send mails only 
to LKML, netdev, and bpf yesterday.


From:   Martin KaFai Lau 
Date:   Fri, 4 Dec 2020 17:42:41 -0800
> On Tue, Dec 01, 2020 at 11:44:10PM +0900, Kuniyuki Iwashima wrote:
> [ ... ]
> > diff --git a/net/core/sock_reuseport.c b/net/core/sock_reuseport.c
> > index fd133516ac0e..60d7c1f28809 100644
> > --- a/net/core/sock_reuseport.c
> > +++ b/net/core/sock_reuseport.c
> > @@ -216,9 +216,11 @@ int reuseport_add_sock(struct sock *sk, struct sock 
> > *sk2, bool bind_inany)
> >  }
> >  EXPORT_SYMBOL(reuseport_add_sock);
> >  
> > -void reuseport_detach_sock(struct sock *sk)
> > +struct sock *reuseport_detach_sock(struct sock *sk)
> >  {
> > struct sock_reuseport *reuse;
> > +   struct bpf_prog *prog;
> > +   struct sock *nsk = NULL;
> > int i;
> >  
> > spin_lock_bh(&reuseport_lock);
> > @@ -242,8 +244,12 @@ void reuseport_detach_sock(struct sock *sk)
> >  
> > reuse->num_socks--;
> > reuse->socks[i] = reuse->socks[reuse->num_socks];
> > +   prog = rcu_dereference(reuse->prog);
> Is it under rcu_read_lock() here?

reuseport_lock is locked in this function, and we do not modify the prog,
but is rcu_dereference_protected() preferable?

---8<---
prog = rcu_dereference_protected(reuse->prog,
 lockdep_is_held(&reuseport_lock));
---8<---


> > if (sk->sk_protocol == IPPROTO_TCP) {
> > +   if (reuse->num_socks && !prog)
> > +   nsk = i == reuse->num_socks ? reuse->socks[i - 
> > 1] : reuse->socks[i];
> > +
> > reuse->num_closed_socks++;
> > reuse->socks[reuse->max_socks - 
> > reuse->num_closed_socks] = sk;
> > } else {
> > @@ -264,6 +270,8 @@ void reuseport_detach_sock(struct sock *sk)
> > call_rcu(&reuse->rcu, reuseport_free_rcu);
> >  out:
> > spin_unlock_bh(&reuseport_lock);
> > +
> > +   return nsk;
> >  }
> >  EXPORT_SYMBOL(reuseport_detach_sock);
> >  
> > diff --git a/net/ipv4/inet_connection_sock.c 
> > b/net/ipv4/inet_connection_sock.c
> > index 1451aa9712b0..b27241ea96bd 100644
> > --- a/net/ipv4/inet_connection_sock.c
> > +++ b/net/ipv4/inet_connection_sock.c
> > @@ -992,6 +992,36 @@ struct sock *inet_csk_reqsk_queue_add(struct sock *sk,
> >  }
> >  EXPORT_SYMBOL(inet_csk_reqsk_queue_add);
> >  
> > +void inet_csk_reqsk_queue_migrate(struct sock *sk, struct sock *nsk)
> > +{
> > +   struct request_sock_queue *old_accept_queue, *new_accept_queue;
> > +
> > +   old_accept_queue = &inet_csk(sk)->icsk_accept_queue;
> > +   new_accept_queue = &inet_csk(nsk)->icsk_accept_queue;
> > +
> > +   spin_lock(&old_accept_queue->rskq_lock);
> > +   spin_lock(&new_accept_queue->rskq_lock);
> I am also not very thrilled on this double spin_lock.
> Can this be done in (or like) inet_csk_listen_stop() instead?

It will be possible to migrate sockets in inet_csk_listen_stop(), but I
think it is better to do it just after reuseport_detach_sock() becuase we
can select a different listener (almost) every time at a lower cost by
selecting the moved socket and pass it to inet_csk_reqsk_queue_migrate()
easily.

sk_hash of the listener is 0, so we would have to generate a random number
in inet_csk_listen_stop().


Re: [PATCH v1 bpf-next 01/11] tcp: Keep TCP_CLOSE sockets in the reuseport group.

2020-12-05 Thread Kuniyuki Iwashima
I'm sending this mail just for logging because I failed to send mails only 
to LKML, netdev, and bpf yesterday.


From:   Martin KaFai Lau 
Date:   Fri, 4 Dec 2020 17:31:03 -0800
> On Tue, Dec 01, 2020 at 11:44:08PM +0900, Kuniyuki Iwashima wrote:
> > This patch is a preparation patch to migrate incoming connections in the
> > later commits and adds a field (num_closed_socks) to the struct
> > sock_reuseport to keep TCP_CLOSE sockets in the reuseport group.
> > 
> > When we close a listening socket, to migrate its connections to another
> > listener in the same reuseport group, we have to handle two kinds of child
> > sockets. One is that a listening socket has a reference to, and the other
> > is not.
> > 
> > The former is the TCP_ESTABLISHED/TCP_SYN_RECV sockets, and they are in the
> > accept queue of their listening socket. So, we can pop them out and push
> > them into another listener's queue at close() or shutdown() syscalls. On
> > the other hand, the latter, the TCP_NEW_SYN_RECV socket is during the
> > three-way handshake and not in the accept queue. Thus, we cannot access
> > such sockets at close() or shutdown() syscalls. Accordingly, we have to
> > migrate immature sockets after their listening socket has been closed.
> > 
> > Currently, if their listening socket has been closed, TCP_NEW_SYN_RECV
> > sockets are freed at receiving the final ACK or retransmitting SYN+ACKs. At
> > that time, if we could select a new listener from the same reuseport group,
> > no connection would be aborted. However, it is impossible because
> > reuseport_detach_sock() sets NULL to sk_reuseport_cb and forbids access to
> > the reuseport group from closed sockets.
> > 
> > This patch allows TCP_CLOSE sockets to remain in the reuseport group and to
> > have access to it while any child socket references to them. The point is
> > that reuseport_detach_sock() is called twice from inet_unhash() and
> > sk_destruct(). At first, it moves the socket backwards in socks[] and
> > increments num_closed_socks. Later, when all migrated connections are
> > accepted, it removes the socket from socks[], decrements num_closed_socks,
> > and sets NULL to sk_reuseport_cb.
> > 
> > By this change, closed sockets can keep sk_reuseport_cb until all child
> > requests have been freed or accepted. Consequently calling listen() after
> > shutdown() can cause EADDRINUSE or EBUSY in reuseport_add_sock() or
> > inet_csk_bind_conflict() which expect that such sockets should not have the
> > reuseport group. Therefore, this patch also loosens such validation rules
> > so that the socket can listen again if it has the same reuseport group with
> > other listening sockets.
> > 
> > Reviewed-by: Benjamin Herrenschmidt 
> > Signed-off-by: Kuniyuki Iwashima 
> > ---
> >  include/net/sock_reuseport.h|  5 ++-
> >  net/core/sock_reuseport.c   | 79 +++--
> >  net/ipv4/inet_connection_sock.c |  7 ++-
> >  3 files changed, 74 insertions(+), 17 deletions(-)
> > 
> > diff --git a/include/net/sock_reuseport.h b/include/net/sock_reuseport.h
> > index 505f1e18e9bf..0e558ca7afbf 100644
> > --- a/include/net/sock_reuseport.h
> > +++ b/include/net/sock_reuseport.h
> > @@ -13,8 +13,9 @@ extern spinlock_t reuseport_lock;
> >  struct sock_reuseport {
> > struct rcu_head rcu;
> >  
> > -   u16 max_socks;  /* length of socks */
> > -   u16 num_socks;  /* elements in socks */
> > +   u16 max_socks;  /* length of socks */
> > +   u16 num_socks;  /* elements in socks */
> > +   u16 num_closed_socks;   /* closed elements in 
> > socks */
> > /* The last synq overflow event timestamp of this
> >  * reuse->socks[] group.
> >  */
> > diff --git a/net/core/sock_reuseport.c b/net/core/sock_reuseport.c
> > index bbdd3c7b6cb5..fd133516ac0e 100644
> > --- a/net/core/sock_reuseport.c
> > +++ b/net/core/sock_reuseport.c
> > @@ -98,16 +98,21 @@ static struct sock_reuseport *reuseport_grow(struct 
> > sock_reuseport *reuse)
> > return NULL;
> >  
> > more_reuse->num_socks = reuse->num_socks;
> > +   more_reuse->num_closed_socks = reuse->num_closed_socks;
> > more_reuse->prog = reuse->prog;
> > more_reuse->reuseport_id = reuse->reuseport_id;
> > more_reuse->bind_inany = reuse->bind_inany;
> > more_reuse->has_conns = reuse->has_conns;
> > +   more_reuse->synq_overflow_ts = READ_ONCE(reuse->synq_overflow_ts);
> >  
> > memcpy(more_reuse->socks, reuse->socks,
> >reuse->num_socks * sizeof(struct sock *));
> > -   more_reuse->synq_overflow_ts = READ_ONCE(reuse->synq_overflow_ts);
> > +   memcpy(more_reuse->socks +
> > +  (more_reuse->max_socks - more_reuse->num_closed_socks),
> > +  reuse->socks + reuse->num_socks,
> > +  reuse->num_closed_socks * sizeof(struct sock *));
> >  
> > -   for (i = 0; i < reuse->num_socks; ++i)

Re: [PATCH v1 bpf-next 09/11] bpf: Support bpf_get_socket_cookie_sock() for BPF_PROG_TYPE_SK_REUSEPORT.

2020-12-05 Thread Kuniyuki Iwashima
I'm sending this mail just for logging because I failed to send mails only 
to LKML, netdev, and bpf yesterday.


From:   Martin KaFai Lau 
Date:   Fri, 4 Dec 2020 11:58:07 -0800
> On Tue, Dec 01, 2020 at 11:44:16PM +0900, Kuniyuki Iwashima wrote:
> > We will call sock_reuseport.prog for socket migration in the next commit,
> > so the eBPF program has to know which listener is closing in order to
> > select the new listener.
> > 
> > Currently, we can get a unique ID for each listener in the userspace by
> > calling bpf_map_lookup_elem() for BPF_MAP_TYPE_REUSEPORT_SOCKARRAY map.
> > 
> > This patch makes the sk pointer available in sk_reuseport_md so that we can
> > get the ID by BPF_FUNC_get_socket_cookie() in the eBPF program.
> > 
> > Link: 
> > https://lore.kernel.org/netdev/20201119001154.kapwihc2plp4f...@kafai-mbp.dhcp.thefacebook.com/
> > Suggested-by: Martin KaFai Lau 
> > Signed-off-by: Kuniyuki Iwashima 
> > ---
> >  include/uapi/linux/bpf.h   |  8 
> >  net/core/filter.c  | 12 +++-
> >  tools/include/uapi/linux/bpf.h |  8 
> >  3 files changed, 27 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index efe342bf3dbc..3e9b8bd42b4e 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -1650,6 +1650,13 @@ union bpf_attr {
> >   * A 8-byte long non-decreasing number on success, or 0 if 
> > the
> >   * socket field is missing inside *skb*.
> >   *
> > + * u64 bpf_get_socket_cookie(struct bpf_sock *sk)
> > + * Description
> > + * Equivalent to bpf_get_socket_cookie() helper that 
> > accepts
> > + * *skb*, but gets socket from **struct bpf_sock** context.
> > + * Return
> > + * A 8-byte long non-decreasing number.
> > + *
> >   * u64 bpf_get_socket_cookie(struct bpf_sock_addr *ctx)
> >   * Description
> >   * Equivalent to bpf_get_socket_cookie() helper that 
> > accepts
> > @@ -4420,6 +4427,7 @@ struct sk_reuseport_md {
> > __u32 bind_inany;   /* Is sock bound to an INANY address? */
> > __u32 hash; /* A hash of the packet 4 tuples */
> > __u8 migration; /* Migration type */
> > +   __bpf_md_ptr(struct bpf_sock *, sk); /* current listening socket */
> >  };
> >  
> >  #define BPF_TAG_SIZE   8
> > diff --git a/net/core/filter.c b/net/core/filter.c
> > index 0a0634787bb4..1059d31847ef 100644
> > --- a/net/core/filter.c
> > +++ b/net/core/filter.c
> > @@ -4628,7 +4628,7 @@ static const struct bpf_func_proto 
> > bpf_get_socket_cookie_sock_proto = {
> > .func   = bpf_get_socket_cookie_sock,
> > .gpl_only   = false,
> > .ret_type   = RET_INTEGER,
> > -   .arg1_type  = ARG_PTR_TO_CTX,
> > +   .arg1_type  = ARG_PTR_TO_SOCKET,
> This will break existing bpf prog (BPF_PROG_TYPE_CGROUP_SOCK)
> using this proto.  A new proto is needed and there is
> an on-going patch doing this [0].
> 
> [0]: https://lore.kernel.org/bpf/20201203213330.1657666-1-rev...@google.com/

Thank you for notifying me of this patch!
I will define another proto, but may drop the part if the above patch is
already merged then.


Re: [PATCH v1 bpf-next 06/11] bpf: Introduce two attach types for BPF_PROG_TYPE_SK_REUSEPORT.

2020-12-05 Thread Kuniyuki Iwashima
I'm sending this mail just for logging because I failed to send mails only
to LKML, netdev, and bpf yesterday.


From:   Martin KaFai Lau 
Date:   Thu, 3 Dec 2020 21:56:53 -0800
> On Thu, Dec 03, 2020 at 11:16:08PM +0900, Kuniyuki Iwashima wrote:
> > From:   Martin KaFai Lau 
> > Date:   Wed, 2 Dec 2020 20:24:02 -0800
> > > On Wed, Dec 02, 2020 at 11:19:02AM -0800, Martin KaFai Lau wrote:
> > > > On Tue, Dec 01, 2020 at 06:04:50PM -0800, Andrii Nakryiko wrote:
> > > > > On Tue, Dec 1, 2020 at 6:49 AM Kuniyuki Iwashima 
> > > > >  wrote:
> > > > > >
> > > > > > This commit adds new bpf_attach_type for BPF_PROG_TYPE_SK_REUSEPORT 
> > > > > > to
> > > > > > check if the attached eBPF program is capable of migrating sockets.
> > > > > >
> > > > > > When the eBPF program is attached, the kernel runs it for socket 
> > > > > > migration
> > > > > > only if the expected_attach_type is 
> > > > > > BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.
> > > > > > The kernel will change the behaviour depending on the returned 
> > > > > > value:
> > > > > >
> > > > > >   - SK_PASS with selected_sk, select it as a new listener
> > > > > >   - SK_PASS with selected_sk NULL, fall back to the random selection
> > > > > >   - SK_DROP, cancel the migration
> > > > > >
> > > > > > Link: 
> > > > > > https://lore.kernel.org/netdev/20201123003828.xjpjdtk4ygl6t...@kafai-mbp.dhcp.thefacebook.com/
> > > > > > Suggested-by: Martin KaFai Lau 
> > > > > > Signed-off-by: Kuniyuki Iwashima 
> > > > > > ---
> > > > > >  include/uapi/linux/bpf.h   | 2 ++
> > > > > >  kernel/bpf/syscall.c   | 8 
> > > > > >  tools/include/uapi/linux/bpf.h | 2 ++
> > > > > >  3 files changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > > index 85278deff439..cfc207ae7782 100644
> > > > > > --- a/include/uapi/linux/bpf.h
> > > > > > +++ b/include/uapi/linux/bpf.h
> > > > > > @@ -241,6 +241,8 @@ enum bpf_attach_type {
> > > > > > BPF_XDP_CPUMAP,
> > > > > > BPF_SK_LOOKUP,
> > > > > > BPF_XDP,
> > > > > > +   BPF_SK_REUSEPORT_SELECT,
> > > > > > +   BPF_SK_REUSEPORT_SELECT_OR_MIGRATE,
> > > > > > __MAX_BPF_ATTACH_TYPE
> > > > > >  };
> > > > > >
> > > > > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > > > > > index f3fe9f53f93c..a0796a8de5ea 100644
> > > > > > --- a/kernel/bpf/syscall.c
> > > > > > +++ b/kernel/bpf/syscall.c
> > > > > > @@ -2036,6 +2036,14 @@ bpf_prog_load_check_attach(enum 
> > > > > > bpf_prog_type prog_type,
> > > > > > if (expected_attach_type == BPF_SK_LOOKUP)
> > > > > > return 0;
> > > > > > return -EINVAL;
> > > > > > +   case BPF_PROG_TYPE_SK_REUSEPORT:
> > > > > > +   switch (expected_attach_type) {
> > > > > > +   case BPF_SK_REUSEPORT_SELECT:
> > > > > > +   case BPF_SK_REUSEPORT_SELECT_OR_MIGRATE:
> > > > > > +   return 0;
> > > > > > +   default:
> > > > > > +   return -EINVAL;
> > > > > > +   }
> > > > > 
> > > > > this is a kernel regression, previously expected_attach_type wasn't
> > > > > enforced, so user-space could have provided any number without an
> > > > > error.
> > > > I also think this change alone will break things like when the usual
> > > > attr->expected_attach_type == 0 case.  At least changes is needed in
> > > > bpf_prog_load_fixup_attach_type() which is also handling a
> > > > similar situation for BPF_PROG_TYPE_CGROUP_SOCK.
> > > > 
> > > > I now think there is no need to expose new bpf_attach_type to the UAPI.
> > > > Since the prog->expected_attach_type is not used, it can be cleared at 
> > > > load time
> > > > and then only set to BPF_SK_REUSEPORT_SELECT_OR_MIGRATE (probably 
> > > > defined
> > > > internally at filter.[c|h]) in the is_valid_access() when "migration"
> > > > is accessed.  When "migration" is accessed, the bpf prog can handle
> > > > migration (and the original not-migration) case.
> > > Scrap this internal only BPF_SK_REUSEPORT_SELECT_OR_MIGRATE idea.
> > > I think there will be cases that bpf prog wants to do both
> > > without accessing any field from sk_reuseport_md.
> > > 
> > > Lets go back to the discussion on using a similar
> > > idea as BPF_PROG_TYPE_CGROUP_SOCK in bpf_prog_load_fixup_attach_type().
> > > I am not aware there is loader setting a random number
> > > in expected_attach_type, so the chance of breaking
> > > is very low.  There was a similar discussion earlier [0].
> > > 
> > > [0]: 
> > > https://lore.kernel.org/netdev/20200126045443.f47dzxdglazzchfm@ast-mbp/
> > 
> > Thank you for the idea and reference.
> > 
> > I will remove the change in bpf_prog_load_check_attach() and set the
> > default value (BPF_SK_REUSEPORT_SELECT) in bpf_prog_load_fixup_attach_type()
> > for backward compatibility if expected_attach_type is 0.
> check_attach_type() can be kept.  You can refer to

Re: memory leak in generic_parse_monolithic [+PATCH]

2020-12-05 Thread Randy Dunlap
On 11/13/20 9:17 AM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:af5043c8 Merge tag 'acpi-5.10-rc4' of git://git.kernel.org..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13e8c90650
> kernel config:  https://syzkaller.appspot.com/x/.config?x=a3f13716fa0212fd
> dashboard link: https://syzkaller.appspot.com/bug?extid=86dc6632faaca40133ab
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=102a57dc50
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=129ca3d650
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+86dc6632faaca4013...@syzkaller.appspotmail.com
> 
> Warning: Permanently added '10.128.0.84' (ECDSA) to the list of known hosts.
> executing program
> executing program
> BUG: memory leak
> unreferenced object 0x888111f15a80 (size 32):
>   comm "syz-executor841", pid 8507, jiffies 4294942125 (age 14.070s)
>   hex dump (first 32 bytes):
> 25 5e 5d 24 5b 2b 25 5d 28 24 7b 3a 0f 6b 5b 29  %^]$[+%](${:.k[)
> 2d 3a 00 00 00 00 00 00 00 00 00 00 00 00 00 00  -:..
>   backtrace:
> [<5c6f565d>] kmemdup_nul+0x2d/0x70 mm/util.c:151
> [<54985c27>] vfs_parse_fs_string+0x6e/0xd0 fs/fs_context.c:155
> [<77ef66e4>] generic_parse_monolithic+0xe0/0x130 
> fs/fs_context.c:201
> [] do_new_mount fs/namespace.c:2871 [inline]
> [] path_mount+0xbbb/0x1170 fs/namespace.c:3205
> [] do_mount fs/namespace.c:3218 [inline]
> [] __do_sys_mount fs/namespace.c:3426 [inline]
> [] __se_sys_mount fs/namespace.c:3403 [inline]
> [] __x64_sys_mount+0x18e/0x1d0 fs/namespace.c:3403
> [] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> [<4e665669>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> 

Hi David,
Is this a false positive, maybe having to do with this comment from
fs/fsopen.c: ?

/*
 * Check the state and apply the configuration.  Note that this function is
 * allowed to 'steal' the value by setting param->xxx to NULL before returning.
 */
static int vfs_fsconfig_locked(struct fs_context *fc, int cmd,
   struct fs_parameter *param)
{


Otherwise please look at the patch below.
Thanks.

> ---
> This report 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 issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches


---
From: Randy Dunlap 

Callers to vfs_parse_fs_param() should be responsible for freeing
param.string.

Fixes: ecdab150fddb ("vfs: syscall: Add fsconfig() for configuring and managing 
a context")
Signed-off-by: Randy Dunlap 
Reported-by: syzbot+86dc6632faaca4013...@syzkaller.appspotmail.com
Cc: David Howells 
Cc: Al Viro 
---
This looks promising to me but I haven't fully tested it yet
because my build/test machine just started acting flaky,
like it is having memory or disk errors.
OTOH, it could have ramifications in other places.

 fs/fs_context.c |1 -
 fs/fsopen.c |4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

--- linux-next-20201204.orig/fs/fs_context.c
+++ linux-next-20201204/fs/fs_context.c
@@ -128,7 +128,6 @@ int vfs_parse_fs_param(struct fs_context
if (fc->source)
return invalf(fc, "VFS: Multiple sources");
fc->source = param->string;
-   param->string = NULL;
return 0;
}
 
--- linux-next-20201204.orig/fs/fsopen.c
+++ linux-next-20201204/fs/fsopen.c
@@ -262,7 +262,9 @@ static int vfs_fsconfig_locked(struct fs
fc->phase != FS_CONTEXT_RECONF_PARAMS)
return -EBUSY;
 
-   return vfs_parse_fs_param(fc, param);
+   ret = vfs_parse_fs_param(fc, param);
+   kfree(param->string);
+   return ret;
}
fc->phase = FS_CONTEXT_FAILED;
return ret;



Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages

2020-12-05 Thread Andrea Arcangeli
Hi Mel,

On Thu, Nov 26, 2020 at 10:47:20AM +, Mel Gorman wrote:
> Agreed. This thread has a lot of different directions in it at this
> point so what I'd hope for is first, a patch that initialises holes with
> zone/node linkages within a 1<<(MAX_ORDER-1) alignment. If there is a
> hole, it would be expected the pages are PageReserved. Second, a fix to
> fast_isolate that forces PFNs returned to always be within the stated
> zone boundaries.

The last two patches should resolve the struct page
initialization
https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git/ and the
VM_BUG_ON_PAGE never happened again as expected.

So I looked back to see how the "distance" logic is accurate. I added
those checks and I get negative hits:

diff --git a/mm/compaction.c b/mm/compaction.c
index cc1a7f600a86..844a90b0acdf 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1331,6 +1331,12 @@ fast_isolate_freepages(struct compact_control *cc)
low_pfn = pageblock_start_pfn(cc->free_pfn - (distance >> 2));
min_pfn = pageblock_start_pfn(cc->free_pfn - (distance >> 1));
 
+   WARN_ON_ONCE((long) low_pfn < 0);
+   WARN_ON_ONCE((long) min_pfn < 0);
+   if ((long) low_pfn < 0)
+   return cc->free_pfn;
+   if ((long) min_pfn < 0)
+   return cc->free_pfn;
if (WARN_ON_ONCE(min_pfn > low_pfn))
low_pfn = min_pfn;

Both warn-on-once triggers, so it goes negative. While it appears not
kernel crashing since pfn_valid won't succeed on negative entries and
they'll always be higher than any pfn in the freelist, is this sign
that there's further room for improvement here?

Thanks,
Andrea



Re: [PATCHSET] saner elf compat

2020-12-05 Thread Al Viro
On Thu, Dec 03, 2020 at 11:03:36PM +, Al Viro wrote:
> > >  The answer (for mainline) is that mips compat does *NOT* want
> > > COMPAT_BINFMT_ELF.  Not a problem with that series, though, so I'd
> > > retested it (seems to work, both for x86_64 and mips64, execs and
> > > coredumps for all ABIs alike), with centralization of Kconfig logics
> > > thrown in.
> > 
> > Well, the diffstat looks nice:
> > 
> > >  26 files changed, 127 insertions(+), 317 deletions(-)
> > 
> > and the patches didn't trigger anything for me, but how much did this
> > get tested? Do you actually have both kinds of 32-bit elf mips
> > binaries around and a machine to test on?
> 
> Yes (aptitude install gcc-multilib on debian mips64el/stretch sets the 
> toolchain
> and libraries just fine, and then it's just a matter of -mabi=n32 passed
> to gcc).  "Machine" is qemu-system-mips64el -machine malta -m 1024 -cpu 5KEc
> and the things appear to work; I hadn't tried that on the actual hardware.
> I do have a Loongson-2 box, but it would take a while to dig it out and
> get it up-to-date.
> 
> > Linux-mips was cc'd, but I'm adding Thomas B to the cc here explicitly
> > just so that he has a heads-up on this thing and can go and look at
> > the mailing list in case it goes to a separate mailbox for him..
> 
> I would certainly appreciate review and testing - this branch sat
> around in the "should post it someday" state since June (it was
> one of the followups grown from regset work back then), and I'm
> _not_ going to ask pulling it without an explicit OK from mips
> folks.

BTW, there's something curious going on in ELF binary recognition for
x32.  Unlike other 64bit architectures, here we have a 32bit binary
that successfully passes the native elf_check_arch().  Usually we
either have different EM_... values for 64bit and 32bit (e.g. for ppc
and sparc) or we have an explicit check for ->e_ident[EI_CLASS]
having the right value (ELFCLASS32 or ELFCLASS64 for 32bit and 64bit
binaries resp.)

For x32 that's not true - we use EM_X86_64 for ->e_machine and that's
the only thing the native elf_check_arch() is looking at.  IOW,
it looks like amd64 elf_load_binary() progresses past elf_check_arch()
for x32 binaries.  And gets to load_elf_phdrs(), which would appear
to have a check of its own that should reject the sucker:
/*
 * If the size of this structure has changed, then punt, since
 * we will be doing the wrong thing.
 */
if (elf_ex->e_phentsize != sizeof(struct elf_phdr))
goto out;
After all, ->e_phentsize is going to be 32 (sizeof(struct elf32_phdr)
rather than expected 56 (sizeof(struct elf64_phdr)) and off we bugger,
even though it happens at slightly later point than usual.  Except that
we are looking at struct elf64_hdr ->e_phentsize - in struct elf32_hdr.
I.e. at offset 54, two bytes past the end of in-file struct elf32_hdr.

Usually we won't find 0x38 0x00 in that location, so everything works,
but IMO that's too convoluted.

Peter, is there any reason not to check ->ei_ident[EI_CLASS] in
amd64 elf_check_arch()?  It's a 1-byte load from hot cacheline
(offset 4 and we'd just read the 4 bytes at offsets 0..3) +
compare + branch not taken, so performance impact is pretty much
nil.  I'm not saying it's a security problem or anything of that
sort, just that it makes the analysis more subtle than it ought
to be...

Is it about some malformed homegrown 64bit binaries with BS value
at offset 4?  Confused...


[PATCH 07/10] staging: rtl8723bs: replace RTW_IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK

2020-12-05 Thread Ross Schmidt
Replace unique macro RTW_IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK with kernel
provided IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK.  The other
IEEE80211_ADDBA_* and IEEE_DELBA_* macros are duplicates already defined
in linux/ieee80211.h, remove them.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 6 +++---
 drivers/staging/rtl8723bs/include/wifi.h  | 7 ---
 2 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 0743e56582ba..166b5369b003 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -3943,7 +3943,7 @@ void issue_action_BA(struct adapter *padapter, unsigned 
char *raddr, unsigned ch
/*  TID */
BA_para_set |= (status << 2) & 
IEEE80211_ADDBA_PARAM_TID_MASK;
/*  max buffer size is 8 MSDU */
-   BA_para_set |= (8 << 6) & 
RTW_IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK;
+   BA_para_set |= (8 << 6) & 
IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK;
} else {
BA_para_set = (0x1002 | ((status & 0xf) << 2)); 
/* immediate ack & 64 buffer size */
}
@@ -3994,8 +3994,8 @@ void issue_action_BA(struct adapter *padapter, unsigned 
char *raddr, unsigned ch
if (hal_btcoex_IsBTCoexCtrlAMPDUSize(padapter) &&
padapter->driver_rx_ampdu_factor == 0xFF) {
/*  max buffer size is 8 MSDU */
-   BA_para_set &= 
~RTW_IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK;
-   BA_para_set |= (8 << 6) & 
RTW_IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK;
+   BA_para_set &= 
~IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK;
+   BA_para_set |= (8 << 6) & 
IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK;
}
 
if (pregpriv->ampdu_amsdu == 0)/* disabled */
diff --git a/drivers/staging/rtl8723bs/include/wifi.h 
b/drivers/staging/rtl8723bs/include/wifi.h
index 2e8ca191c608..c3a4a0bad0d7 100644
--- a/drivers/staging/rtl8723bs/include/wifi.h
+++ b/drivers/staging/rtl8723bs/include/wifi.h
@@ -653,13 +653,6 @@ struct ADDBA_request {
 #define IEEE80211_HT_IE_NON_GF_STA_PRSNT   0x0004
 #define IEEE80211_HT_IE_NON_HT_STA_PRSNT   0x0010
 
-/* block-ack parameters */
-#define IEEE80211_ADDBA_PARAM_POLICY_MASK 0x0002
-#define IEEE80211_ADDBA_PARAM_TID_MASK 0x003C
-#define RTW_IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFC0
-#define IEEE80211_DELBA_PARAM_TID_MASK 0xF000
-#define IEEE80211_DELBA_PARAM_INITIATOR_MASK 0x0800
-
 /*
  * A-PMDU buffer sizes
  * According to IEEE802.11n spec size varies from 8K to 64K (in powers of 2)
-- 
2.25.1



[PATCH 02/10] staging: rtl8723bs: replace WIFI_REASON_CODE

2020-12-05 Thread Ross Schmidt
Replace unique macros and WIFI_REASON_CODE enum with the kernel provided
ieee80211_reasoncode.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c |  4 +--
 drivers/staging/rtl8723bs/include/wifi.h  | 36 ---
 2 files changed, 2 insertions(+), 38 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index ab4876507198..6dab68033941 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -1210,7 +1210,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union 
recv_frame *precv_frame)
 
pstat = rtw_get_stainfo(pstapriv, GetAddr2Ptr(pframe));
if (!pstat) {
-   status = _RSON_CLS2_;
+   status = WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA;
goto asoc_class2_error;
}
 
@@ -1226,7 +1226,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union 
recv_frame *precv_frame)
/*  check if this stat has been successfully authenticated/assocated */
if (!((pstat->state) & WIFI_FW_AUTH_SUCCESS)) {
if (!((pstat->state) & WIFI_FW_ASSOC_SUCCESS)) {
-   status = _RSON_CLS2_;
+   status = WLAN_REASON_CLASS2_FRAME_FROM_NONAUTH_STA;
goto asoc_class2_error;
} else {
pstat->state &= (~WIFI_FW_ASSOC_SUCCESS);
diff --git a/drivers/staging/rtl8723bs/include/wifi.h 
b/drivers/staging/rtl8723bs/include/wifi.h
index 8e0ec95c1339..fe9c3a4ffe7f 100644
--- a/drivers/staging/rtl8723bs/include/wifi.h
+++ b/drivers/staging/rtl8723bs/include/wifi.h
@@ -88,42 +88,6 @@ enum WIFI_FRAME_SUBTYPE {
 WIFI_QOS_DATA_NULL = (BIT(6) | WIFI_QOS_DATA_TYPE),
 };
 
-enum WIFI_REASON_CODE  {
-   _RSON_RESERVED_ = 0,
-   _RSON_UNSPECIFIED_  = 1,
-   _RSON_AUTH_NO_LONGER_VALID_ = 2,
-   _RSON_DEAUTH_STA_LEAVING_   = 3,
-   _RSON_INACTIVITY_   = 4,
-   _RSON_UNABLE_HANDLE_= 5,
-   _RSON_CLS2_ = 6,
-   _RSON_CLS3_ = 7,
-   _RSON_DISAOC_STA_LEAVING_   = 8,
-   _RSON_ASOC_NOT_AUTH_= 9,
-
-   /*  WPA reason */
-   _RSON_INVALID_IE_   = 13,
-   _RSON_MIC_FAILURE_  = 14,
-   _RSON_4WAY_HNDSHK_TIMEOUT_  = 15,
-   _RSON_GROUP_KEY_UPDATE_TIMEOUT_ = 16,
-   _RSON_DIFF_IE_  = 17,
-   _RSON_MLTCST_CIPHER_NOT_VALID_  = 18,
-   _RSON_UNICST_CIPHER_NOT_VALID_  = 19,
-   _RSON_AKMP_NOT_VALID_   = 20,
-   _RSON_UNSUPPORT_RSNE_VER_   = 21,
-   _RSON_INVALID_RSNE_CAP_ = 22,
-   _RSON_IEEE_802DOT1X_AUTH_FAIL_  = 23,
-
-   /* belowing are Realtek definition */
-   _RSON_PMK_NOT_AVAILABLE_= 24,
-   _RSON_TDLS_TEAR_TOOFAR_ = 25,
-   _RSON_TDLS_TEAR_UN_RSN_ = 26,
-};
-
-/* Reason codes (IEEE 802.11-2007, 7.3.1.7, Table 7-22) */
-/* IEEE 802.11h */
-#define WLAN_REASON_PWR_CAPABILITY_NOT_VALID 10
-#define WLAN_REASON_SUPPORTED_CHANNEL_NOT_VALID 11
-
 enum WIFI_REG_DOMAIN {
DOMAIN_FCC  = 1,
DOMAIN_IC   = 2,
-- 
2.25.1



[PATCH 09/10] staging: rtl8723bs: remove LIST_CONTAINOR

2020-12-05 Thread Ross Schmidt
Remove unnecessary macro for container_of and call it directly.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/core/rtw_ap.c   | 16 +++---
 drivers/staging/rtl8723bs/core/rtw_cmd.c  |  2 +-
 drivers/staging/rtl8723bs/core/rtw_mlme.c | 18 +++
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c |  6 ++---
 drivers/staging/rtl8723bs/core/rtw_recv.c |  4 ++--
 drivers/staging/rtl8723bs/core/rtw_sta_mgt.c  | 12 +-
 drivers/staging/rtl8723bs/core/rtw_xmit.c | 22 +--
 .../staging/rtl8723bs/hal/rtl8723bs_xmit.c|  6 ++---
 .../rtl8723bs/include/osdep_service_linux.h   |  4 
 .../staging/rtl8723bs/os_dep/ioctl_cfg80211.c |  6 ++---
 .../staging/rtl8723bs/os_dep/ioctl_linux.c| 10 -
 drivers/staging/rtl8723bs/os_dep/xmit_linux.c |  2 +-
 12 files changed, 52 insertions(+), 56 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c 
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 27446156ed34..04d5852d0d3e 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -223,7 +223,7 @@ void expire_timeout_chk(struct adapter *padapter)
}
#endif
while (phead != plist) {
-   psta = LIST_CONTAINOR(plist, struct sta_info, auth_list);
+   psta = container_of(plist, struct sta_info, auth_list);
 
plist = get_next(plist);
 
@@ -268,7 +268,7 @@ void expire_timeout_chk(struct adapter *padapter)
}
#endif
while (phead != plist) {
-   psta = LIST_CONTAINOR(plist, struct sta_info, asoc_list);
+   psta = container_of(plist, struct sta_info, asoc_list);
plist = get_next(plist);
 #ifdef CONFIG_AUTO_AP_MODE
if (psta->isrc)
@@ -1344,7 +1344,7 @@ int rtw_acl_add_sta(struct adapter *padapter, u8 *addr)
plist = get_next(phead);
 
while (phead != plist) {
-   paclnode = LIST_CONTAINOR(plist, struct rtw_wlan_acl_node, 
list);
+   paclnode = container_of(plist, struct rtw_wlan_acl_node, list);
plist = get_next(plist);
 
if (!memcmp(paclnode->addr, addr, ETH_ALEN)) {
@@ -1405,7 +1405,7 @@ void rtw_acl_remove_sta(struct adapter *padapter, u8 
*addr)
plist = get_next(phead);
 
while (phead != plist) {
-   paclnode = LIST_CONTAINOR(plist, struct rtw_wlan_acl_node, 
list);
+   paclnode = container_of(plist, struct rtw_wlan_acl_node, list);
plist = get_next(plist);
 
if (
@@ -1912,7 +1912,7 @@ void associated_clients_update(struct adapter *padapter, 
u8 updated)
 
/* check asoc_queue */
while (phead != plist) {
-   psta = LIST_CONTAINOR(plist, struct sta_info, 
asoc_list);
+   psta = container_of(plist, struct sta_info, asoc_list);
 
plist = get_next(plist);
 
@@ -2193,7 +2193,7 @@ void rtw_sta_flush(struct adapter *padapter)
 
/* free sta asoc_queue */
while (phead != plist) {
-   psta = LIST_CONTAINOR(plist, struct sta_info, asoc_list);
+   psta = container_of(plist, struct sta_info, asoc_list);
 
plist = get_next(plist);
 
@@ -2297,7 +2297,7 @@ void rtw_ap_restore_network(struct adapter *padapter)
while (phead != plist) {
int stainfo_offset;
 
-   psta = LIST_CONTAINOR(plist, struct sta_info, asoc_list);
+   psta = container_of(plist, struct sta_info, asoc_list);
plist = get_next(plist);
 
stainfo_offset = rtw_stainfo_offset(pstapriv, psta);
@@ -2402,7 +2402,7 @@ void stop_ap_mode(struct adapter *padapter)
phead = get_list_head(pacl_node_q);
plist = get_next(phead);
while (phead != plist) {
-   paclnode = LIST_CONTAINOR(plist, struct rtw_wlan_acl_node, 
list);
+   paclnode = container_of(plist, struct rtw_wlan_acl_node, list);
plist = get_next(plist);
 
if (paclnode->valid) {
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c 
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index 4e1301261a01..f6160f1cca43 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
@@ -287,7 +287,7 @@ struct  cmd_obj *_rtw_dequeue_cmd(struct __queue *queue)
if (list_empty(&(queue->queue)))
obj = NULL;
else {
-   obj = LIST_CONTAINOR(get_next(&(queue->queue)), struct cmd_obj, 
list);
+   obj = container_of(get_next(&(queue->queue)), struct cmd_obj, 
list);
list_del_init(&obj->list);
}
 
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index e20e0ce4a2c5..f05fcf9892e5 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme

[PATCH net v1 2/2] lan743x: boost performance: limit PCIe bandwidth requirement

2020-12-05 Thread Sven Van Asbroeck
From: Sven Van Asbroeck 

To support jumbo frames, each rx ring dma buffer is 9K in size.
But the chip only stores a single frame per dma buffer.

When the chip is working with the default 1500 byte MTU, a 9K
dma buffer goes from chip -> cpu per 1500 byte frame. This means
that to get 1G/s ethernet bandwidth, we need 6G/s PCIe bandwidth !

Fix by limiting the rx ring dma buffer size to the current MTU
size.

Tested with iperf3 on a freescale imx6 + lan7430, both sides
set to mtu 1500 bytes.

Before:
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-20.00  sec   483 MBytes   203 Mbits/sec0
After:
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-20.00  sec  1.15 GBytes   496 Mbits/sec0

And with both sides set to MTU 9000 bytes:
Before:
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-20.00  sec  1.87 GBytes   803 Mbits/sec   27
After:
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-20.00  sec  1.98 GBytes   849 Mbits/sec0

Tested-by: Sven Van Asbroeck  # lan7430
Signed-off-by: Sven Van Asbroeck 
---

Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git # 905b2032fa42

To: Bryan Whitehead 
To: Microchip Linux Driver Support 
To: "David S. Miller" 
To: Jakub Kicinski 
Cc: Andrew Lunn 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

 drivers/net/ethernet/microchip/lan743x_main.c | 21 ---
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan743x_main.c 
b/drivers/net/ethernet/microchip/lan743x_main.c
index ebb5e0bc516b..2bded1c46784 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -1957,11 +1957,11 @@ static int lan743x_rx_next_index(struct lan743x_rx *rx, 
int index)
 
 static struct sk_buff *lan743x_rx_allocate_skb(struct lan743x_rx *rx)
 {
-   int length = 0;
+   struct net_device *netdev = rx->adapter->netdev;
 
-   length = (LAN743X_MAX_FRAME_SIZE + ETH_HLEN + 4 + RX_HEAD_PADDING);
-   return __netdev_alloc_skb(rx->adapter->netdev,
- length, GFP_ATOMIC | GFP_DMA);
+   return __netdev_alloc_skb(netdev,
+ netdev->mtu + ETH_HLEN + 4 + RX_HEAD_PADDING,
+ GFP_ATOMIC | GFP_DMA);
 }
 
 static int lan743x_rx_init_ring_element(struct lan743x_rx *rx, int index,
@@ -1969,9 +1969,10 @@ static int lan743x_rx_init_ring_element(struct 
lan743x_rx *rx, int index,
 {
struct lan743x_rx_buffer_info *buffer_info;
struct lan743x_rx_descriptor *descriptor;
-   int length = 0;
+   struct net_device *netdev = rx->adapter->netdev;
+   int length;
 
-   length = (LAN743X_MAX_FRAME_SIZE + ETH_HLEN + 4 + RX_HEAD_PADDING);
+   length = netdev->mtu + ETH_HLEN + 4 + RX_HEAD_PADDING;
descriptor = &rx->ring_cpu_ptr[index];
buffer_info = &rx->buffer_info[index];
buffer_info->skb = skb;
@@ -2157,8 +2158,8 @@ static int lan743x_rx_process_packet(struct lan743x_rx 
*rx)
int index = first_index;
 
/* multi buffer packet not supported */
-   /* this should not happen since
-* buffers are allocated to be at least jumbo size
+   /* this should not happen since buffers are allocated
+* to be at least the mtu size configured in the mac.
 */
 
/* clean up buffers */
@@ -2632,9 +2633,13 @@ static int lan743x_netdev_change_mtu(struct net_device 
*netdev, int new_mtu)
struct lan743x_adapter *adapter = netdev_priv(netdev);
int ret = 0;
 
+   if (netif_running(netdev))
+   return -EBUSY;
+
ret = lan743x_mac_set_mtu(adapter, new_mtu);
if (!ret)
netdev->mtu = new_mtu;
+
return ret;
 }
 
-- 
2.17.1



[PATCH 04/10] staging: rtl8723bs: replace HT_CAP_AMPDU_FACTOR

2020-12-05 Thread Ross Schmidt
Replace unique HT_CAP_AMPDU_FACTOR enum with kernel provided
ieee80211_max_ampdu_length_exp enum.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/core/rtw_mlme.c |  4 ++--
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 12 ++--
 drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c |  2 +-
 drivers/staging/rtl8723bs/hal/sdio_halinit.c  |  2 +-
 drivers/staging/rtl8723bs/include/wifi.h  |  7 ---
 5 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index 001cce312f05..e20e0ce4a2c5 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -2580,7 +2580,7 @@ void rtw_build_wmm_ie_ht(struct adapter *padapter, u8 
*out_ie, uint *pout_len)
 unsigned int rtw_restructure_ht_ie(struct adapter *padapter, u8 *in_ie, u8 
*out_ie, uint in_len, uint *pout_len, u8 channel)
 {
u32 ielen, out_len;
-   enum HT_CAP_AMPDU_FACTOR max_rx_ampdu_factor;
+   enum ieee80211_max_ampdu_length_exp max_rx_ampdu_factor;
unsigned char *p, *pframe;
struct ieee80211_ht_cap ht_capie;
u8 cbw40_enable = 0, stbc_rx_enable = 0, rf_type = 0, operation_bw = 0;
@@ -2698,7 +2698,7 @@ unsigned int rtw_restructure_ht_ie(struct adapter 
*padapter, u8 *in_ie, u8 *out_
 
if (padapter->driver_rx_ampdu_factor != 0xFF)
max_rx_ampdu_factor =
- (enum HT_CAP_AMPDU_FACTOR)padapter->driver_rx_ampdu_factor;
+ (enum 
ieee80211_max_ampdu_length_exp)padapter->driver_rx_ampdu_factor;
else
rtw_hal_get_def_var(padapter, HW_VAR_MAX_RX_AMPDU_FACTOR,
&max_rx_ampdu_factor);
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 239c89ce7dc9..0743e56582ba 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -3880,7 +3880,7 @@ void issue_action_BA(struct adapter *padapter, unsigned 
char *raddr, unsigned ch
u16 reason_code;
u16 BA_timeout_value;
u16 BA_starting_seqctrl = 0;
-   enum HT_CAP_AMPDU_FACTOR max_rx_ampdu_factor;
+   enum ieee80211_max_ampdu_length_exp max_rx_ampdu_factor;
struct xmit_frame   *pmgntframe;
struct pkt_attrib   *pattrib;
u8  *pframe;
@@ -3975,18 +3975,18 @@ void issue_action_BA(struct adapter *padapter, unsigned 
char *raddr, unsigned ch
pframe = rtw_set_fixed_ie(pframe, 2, (unsigned char 
*)(&status), &(pattrib->pktlen));
if (padapter->driver_rx_ampdu_factor != 0xFF)
max_rx_ampdu_factor =
- (enum 
HT_CAP_AMPDU_FACTOR)padapter->driver_rx_ampdu_factor;
+ (enum 
ieee80211_max_ampdu_length_exp)padapter->driver_rx_ampdu_factor;
else
rtw_hal_get_def_var(padapter,
HW_VAR_MAX_RX_AMPDU_FACTOR, 
&max_rx_ampdu_factor);
 
-   if (MAX_AMPDU_FACTOR_64K == max_rx_ampdu_factor)
+   if (IEEE80211_HT_MAX_AMPDU_64K == max_rx_ampdu_factor)
BA_para_set = 
((le16_to_cpu(pmlmeinfo->ADDBA_req.BA_para_set) & 0x3f) | 0x1000); /* 64 buffer 
size */
-   else if (MAX_AMPDU_FACTOR_32K == max_rx_ampdu_factor)
+   else if (IEEE80211_HT_MAX_AMPDU_32K == 
max_rx_ampdu_factor)
BA_para_set = 
((le16_to_cpu(pmlmeinfo->ADDBA_req.BA_para_set) & 0x3f) | 0x0800); /* 32 buffer 
size */
-   else if (MAX_AMPDU_FACTOR_16K == max_rx_ampdu_factor)
+   else if (IEEE80211_HT_MAX_AMPDU_16K == 
max_rx_ampdu_factor)
BA_para_set = 
((le16_to_cpu(pmlmeinfo->ADDBA_req.BA_para_set) & 0x3f) | 0x0400); /* 16 buffer 
size */
-   else if (MAX_AMPDU_FACTOR_8K == max_rx_ampdu_factor)
+   else if (IEEE80211_HT_MAX_AMPDU_8K == 
max_rx_ampdu_factor)
BA_para_set = 
((le16_to_cpu(pmlmeinfo->ADDBA_req.BA_para_set) & 0x3f) | 0x0200); /* 8 buffer 
size */
else
BA_para_set = 
((le16_to_cpu(pmlmeinfo->ADDBA_req.BA_para_set) & 0x3f) | 0x1000); /* 64 buffer 
size */
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c 
b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
index de8caa6cd418..84e963909283 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
@@ -4373,7 +4373,7 @@ u8 GetHalDefVar8723B(struct adapter *padapter, enum 
HAL_DEF_VARIABLE variable, v
/*  Stanley@BB.SD3 suggests 16K c

[PATCH 08/10] staging: rtl8723bs: remove unused macros

2020-12-05 Thread Ross Schmidt
Remove many macros from wifi.h because they are unused.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/include/wifi.h | 33 
 1 file changed, 33 deletions(-)

diff --git a/drivers/staging/rtl8723bs/include/wifi.h 
b/drivers/staging/rtl8723bs/include/wifi.h
index c3a4a0bad0d7..41de2605c517 100644
--- a/drivers/staging/rtl8723bs/include/wifi.h
+++ b/drivers/staging/rtl8723bs/include/wifi.h
@@ -643,39 +643,6 @@ struct ADDBA_request {
 #define IEEE80211_HT_CAP_TXBF_TX_NDP   0x0010
 #define IEEE80211_HT_CAP_TXBF_EXPLICIT_COMP_STEERING_CAP   0x0400
 
-/* 802.11n HT IE masks */
-#define IEEE80211_HT_IE_CHA_SEC_OFFSET 0x03
-#define IEEE80211_HT_IE_CHA_SEC_NONE   0x00
-#define IEEE80211_HT_IE_CHA_SEC_ABOVE  0x01
-#define IEEE80211_HT_IE_CHA_SEC_BELOW  0x03
-#define IEEE80211_HT_IE_CHA_WIDTH  0x04
-#define IEEE80211_HT_IE_HT_PROTECTION  0x0003
-#define IEEE80211_HT_IE_NON_GF_STA_PRSNT   0x0004
-#define IEEE80211_HT_IE_NON_HT_STA_PRSNT   0x0010
-
-/*
- * A-PMDU buffer sizes
- * According to IEEE802.11n spec size varies from 8K to 64K (in powers of 2)
- */
-#define IEEE80211_MIN_AMPDU_BUF 0x8
-
-#define HT_INFO_HT_PARAM_SECONDARY_CHNL_OFF_MASK   ((u8) BIT(0) | BIT(1))
-#define HT_INFO_HT_PARAM_SECONDARY_CHNL_ABOVE  ((u8) BIT(0))
-#define HT_INFO_HT_PARAM_SECONDARY_CHNL_BELOW  ((u8) BIT(0) | BIT(1))
-#define HT_INFO_HT_PARAM_REC_TRANS_CHNL_WIDTH  ((u8) BIT(2))
-#define HT_INFO_HT_PARAM_RIFS_MODE ((u8) BIT(3))
-#define HT_INFO_HT_PARAM_CTRL_ACCESS_ONLY  ((u8) BIT(4))
-#define HT_INFO_HT_PARAM_SRV_INTERVAL_GRANULARITY  ((u8) BIT(5))
-
-#define HT_INFO_STBC_PARAM_DUAL_BEACON ((u16) BIT(6))
-#define HT_INFO_STBC_PARAM_DUAL_STBC_PROTECT   ((u16) BIT(7))
-#define HT_INFO_STBC_PARAM_SECONDARY_BCN   ((u16) BIT(8))
-#define HT_INFO_STBC_PARAM_LSIG_TXOP_PROTECT_ALLOWED   ((u16) BIT(9))
-#define HT_INFO_STBC_PARAM_PCO_ACTIVE  ((u16) BIT(10))
-#define HT_INFO_STBC_PARAM_PCO_PHASE   ((u16) BIT(11))
-
-
-
 /* endif */
 
 /* ===WPS Section === */
-- 
2.25.1



[PATCH 03/10] staging: rtl8723bs: replace cap_* macros

2020-12-05 Thread Ross Schmidt
Replace unique cap_* macros with kernel provided WLAN_CAPABILITY_*
macros.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/core/rtw_ap.c|  2 +-
 drivers/staging/rtl8723bs/core/rtw_ieee80211.c |  6 +++---
 drivers/staging/rtl8723bs/core/rtw_mlme.c  |  4 ++--
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c  | 12 ++--
 drivers/staging/rtl8723bs/include/ieee80211.h  |  4 
 drivers/staging/rtl8723bs/include/wifi.h   | 12 
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c |  4 ++--
 7 files changed, 14 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c 
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index a2b39ae56d89..984b9f5a83ac 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -1980,7 +1980,7 @@ void bss_cap_update_on_sta_join(struct adapter *padapter, 
struct sta_info *psta)
}
}
 
-   if (!(psta->capability & WLAN_CAPABILITY_SHORT_SLOT)) {
+   if (!(psta->capability & WLAN_CAPABILITY_SHORT_SLOT_TIME)) {
if (!psta->no_short_slot_time_set) {
psta->no_short_slot_time_set = 1;
 
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c 
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index 8d61be5bd250..e80b957f947f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -314,13 +314,13 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
/* capability info */
*(u16 *)ie = 0;
 
-   *(__le16 *)ie |= cpu_to_le16(cap_IBSS);
+   *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_IBSS);
 
if (pregistrypriv->preamble == PREAMBLE_SHORT)
-   *(__le16 *)ie |= cpu_to_le16(cap_ShortPremble);
+   *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_SHORT_PREAMBLE);
 
if (pdev_network->Privacy)
-   *(__le16 *)ie |= cpu_to_le16(cap_Privacy);
+   *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_PRIVACY);
 
sz += 2;
ie += 2;
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index 351178ab78c5..001cce312f05 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -424,8 +424,8 @@ int is_same_network(struct wlan_bssid_ex *src, struct 
wlan_bssid_ex *dst, u8 fea
((!memcmp(src->Ssid.Ssid, dst->Ssid.Ssid, 
src->Ssid.SsidLength))) &&
((s_cap & WLAN_CAPABILITY_IBSS) ==
(d_cap & WLAN_CAPABILITY_IBSS)) &&
-   ((s_cap & WLAN_CAPABILITY_BSS) ==
-   (d_cap & WLAN_CAPABILITY_BSS));
+   ((s_cap & WLAN_CAPABILITY_ESS) ==
+   (d_cap & WLAN_CAPABILITY_ESS));
 
 }
 
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 6dab68033941..239c89ce7dc9 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -4600,7 +4600,7 @@ void start_create_ibss(struct adapter *padapter)
/* update capability */
caps = rtw_get_capability((struct wlan_bssid_ex *)pnetwork);
update_capinfo(padapter, caps);
-   if (caps&cap_IBSS) {/* adhoc master */
+   if (caps&WLAN_CAPABILITY_IBSS) {/* adhoc master */
val8 = 0xcf;
rtw_hal_set_hwreg(padapter, HW_VAR_SEC_CFG, (u8 *)(&val8));
 
@@ -4655,7 +4655,7 @@ void start_clnt_join(struct adapter *padapter)
/* update capability */
caps = rtw_get_capability((struct wlan_bssid_ex *)pnetwork);
update_capinfo(padapter, caps);
-   if (caps&cap_ESS) {
+   if (caps&WLAN_CAPABILITY_ESS) {
Set_MSR(padapter, WIFI_FW_STATION_STATE);
 
val8 = (pmlmeinfo->auth_algo == dot11AuthAlgrthm_8021X) ? 0xcc 
: 0xcf;
@@ -4681,7 +4681,7 @@ void start_clnt_join(struct adapter *padapter)
(REAUTH_TO * REAUTH_LIMIT) + (REASSOC_TO*REASSOC_LIMIT) 
+ beacon_timeout);
 
pmlmeinfo->state = WIFI_FW_AUTH_NULL | WIFI_FW_STATION_STATE;
-   } else if (caps&cap_IBSS) { /* adhoc client */
+   } else if (caps&WLAN_CAPABILITY_IBSS) { /* adhoc client */
Set_MSR(padapter, WIFI_FW_ADHOC_STATE);
 
val8 = 0xcf;
@@ -5952,9 +5952,9 @@ static int rtw_auto_ap_start_beacon(struct adapter 
*adapter)
 
/* capability info */
*(u16 *)ie = 0;
-   *(u16 *)ie |= cpu_to_le16(cap_ESS);
-   *(u16 *)ie |= cpu_to_le16(cap_ShortPremble);
-   /* u16*)ie |= cpu_to_le16(cap_Privacy); */
+   *(u16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_ESS);
+   *(u16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_SHORT_PREAMBLE);
+   /* u16*)ie |= cpu_to_le16(WLAN_CAPABILITY_PRIVACY); */
sz += 2;
ie += 2;
 
diff --git a/drivers/staging/rtl8723bs/include/iee

[PATCH net v1 1/2] lan743x: improve performance: fix rx_napi_poll/interrupt ping-pong

2020-12-05 Thread Sven Van Asbroeck
From: Sven Van Asbroeck 

Even if the rx ring is completely full, and there is more rx data
waiting on the chip, the rx napi poll fn will never run more than
once - it will always immediately bail out and re-enable interrupts.
Which results in ping-pong between napi and interrupt.

This defeats the purpose of napi, and is bad for performance.

Fix by addressing two separate issues:

1. Ensure the rx napi poll fn always updates the rx ring tail
   when returning, even when not re-enabling interrupts.

2. Up to half of elements in a full rx ring are extension
   frames, which do not generate any skbs. Limit the default
   napi weight to the smallest no. of skbs that can be generated
   by a full rx ring.

Tested-by: Sven Van Asbroeck  # lan7430
Signed-off-by: Sven Van Asbroeck 
---

Tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git # 905b2032fa42

To: Bryan Whitehead 
To: Microchip Linux Driver Support 
To: "David S. Miller" 
To: Jakub Kicinski 
Cc: Andrew Lunn 
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

 drivers/net/ethernet/microchip/lan743x_main.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/microchip/lan743x_main.c 
b/drivers/net/ethernet/microchip/lan743x_main.c
index 87b6c59a1e03..ebb5e0bc516b 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -2260,10 +2260,11 @@ static int lan743x_rx_napi_poll(struct napi_struct 
*napi, int weight)
  INT_BIT_DMA_RX_(rx->channel_number));
}
 
+done:
/* update RX_TAIL */
lan743x_csr_write(adapter, RX_TAIL(rx->channel_number),
  rx_tail_flags | rx->last_tail);
-done:
+
return count;
 }
 
@@ -2405,9 +2406,15 @@ static int lan743x_rx_open(struct lan743x_rx *rx)
if (ret)
goto return_error;
 
+   /* up to half of elements in a full rx ring are
+* extension frames. these do not generate skbs.
+* to prevent napi/interrupt ping-pong, limit default
+* weight to the smallest no. of skbs that can be
+* generated by a full rx ring.
+*/
netif_napi_add(adapter->netdev,
   &rx->napi, lan743x_rx_napi_poll,
-  rx->ring_size - 1);
+  (rx->ring_size - 1) / 2);
 
lan743x_csr_write(adapter, DMAC_CMD,
  DMAC_CMD_RX_SWR_(rx->channel_number));
-- 
2.17.1



[PATCH 06/10] staging: rtl8723bs: remove WLAN_HT_CAP_SM_PS_* macros

2020-12-05 Thread Ross Schmidt
The WLAN_HT_CAP_SM_PS_* macro family is already defined in
linux/ieee80211.h, remove them.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/include/wifi.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/rtl8723bs/include/wifi.h 
b/drivers/staging/rtl8723bs/include/wifi.h
index 2fb1687ecabf..2e8ca191c608 100644
--- a/drivers/staging/rtl8723bs/include/wifi.h
+++ b/drivers/staging/rtl8723bs/include/wifi.h
@@ -666,13 +666,6 @@ struct ADDBA_request {
  */
 #define IEEE80211_MIN_AMPDU_BUF 0x8
 
-
-/* Spatial Multiplexing Power Save Modes */
-#define WLAN_HT_CAP_SM_PS_STATIC   0
-#define WLAN_HT_CAP_SM_PS_DYNAMIC  1
-#define WLAN_HT_CAP_SM_PS_INVALID  2
-#define WLAN_HT_CAP_SM_PS_DISABLED 3
-
 #define HT_INFO_HT_PARAM_SECONDARY_CHNL_OFF_MASK   ((u8) BIT(0) | BIT(1))
 #define HT_INFO_HT_PARAM_SECONDARY_CHNL_ABOVE  ((u8) BIT(0))
 #define HT_INFO_HT_PARAM_SECONDARY_CHNL_BELOW  ((u8) BIT(0) | BIT(1))
-- 
2.25.1



[PATCH 01/10] staging: rtl8723bs: replace unique macros and WIFI_STATUS_CODE

2020-12-05 Thread Ross Schmidt
Replace many unique macros and WIFI_STATUS_CODE enum with kernel
provided ieee80211_statuscode. A duplicate
WLAN_STATUS_ASSOC_DENIED_NOSHORT macro is also removed.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 54 +--
 drivers/staging/rtl8723bs/include/ieee80211.h |  3 --
 drivers/staging/rtl8723bs/include/wifi.h  | 51 --
 3 files changed, 27 insertions(+), 81 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 8c40ef43ff94..ab4876507198 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -940,13 +940,13 @@ unsigned int OnAuth(struct adapter *padapter, union 
recv_frame *precv_frame)
DBG_871X("auth rejected due to bad alg [alg =%d, auth_mib =%d] 
%02X%02X%02X%02X%02X%02X\n",
algorithm, auth_mode, sa[0], sa[1], sa[2], sa[3], 
sa[4], sa[5]);
 
-   status = _STATS_NO_SUPP_ALG_;
+   status = WLAN_STATUS_NOT_SUPPORTED_AUTH_ALG;
 
goto auth_fail;
}
 
if (rtw_access_ctrl(padapter, sa) == false) {
-   status = _STATS_UNABLE_HANDLE_STA_;
+   status = WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA;
goto auth_fail;
}
 
@@ -958,7 +958,7 @@ unsigned int OnAuth(struct adapter *padapter, union 
recv_frame *precv_frame)
pstat = rtw_alloc_stainfo(pstapriv, sa);
if (pstat == NULL) {
DBG_871X(" Exceed the upper limit of supported 
clients...\n");
-   status = _STATS_UNABLE_HANDLE_STA_;
+   status = WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA;
goto auth_fail;
}
 
@@ -999,7 +999,7 @@ unsigned int OnAuth(struct adapter *padapter, union 
recv_frame *precv_frame)
if ((pstat->auth_seq + 1) != seq) {
DBG_871X("(1)auth rejected because out of seq [rx_seq =%d, 
exp_seq =%d]!\n",
seq, pstat->auth_seq+1);
-   status = _STATS_OUT_OF_AUTH_SEQ_;
+   status = WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION;
goto auth_fail;
}
 
@@ -1012,7 +1012,7 @@ unsigned int OnAuth(struct adapter *padapter, union 
recv_frame *precv_frame)
} else {
DBG_871X("(2)auth rejected because out of seq [rx_seq 
=%d, exp_seq =%d]!\n",
seq, pstat->auth_seq+1);
-   status = _STATS_OUT_OF_AUTH_SEQ_;
+   status = WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION;
goto auth_fail;
}
} else { /*  shared system or auto authentication */
@@ -1033,7 +1033,7 @@ unsigned int OnAuth(struct adapter *padapter, union 
recv_frame *precv_frame)
 
if ((p == NULL) || (ie_len <= 0)) {
DBG_871X("auth rejected because challenge 
failure!(1)\n");
-   status = _STATS_CHALLENGE_FAIL_;
+   status = WLAN_STATUS_CHALLENGE_FAIL;
goto auth_fail;
}
 
@@ -1044,13 +1044,13 @@ unsigned int OnAuth(struct adapter *padapter, union 
recv_frame *precv_frame)
pstat->expire_to =  pstapriv->assoc_to;
} else {
DBG_871X("auth rejected because challenge 
failure!\n");
-   status = _STATS_CHALLENGE_FAIL_;
+   status = WLAN_STATUS_CHALLENGE_FAIL;
goto auth_fail;
}
} else {
DBG_871X("(3)auth rejected because out of seq [rx_seq 
=%d, exp_seq =%d]!\n",
seq, pstat->auth_seq+1);
-   status = _STATS_OUT_OF_AUTH_SEQ_;
+   status = WLAN_STATUS_UNKNOWN_AUTH_TRANSACTION;
goto auth_fail;
}
}
@@ -1059,7 +1059,7 @@ unsigned int OnAuth(struct adapter *padapter, union 
recv_frame *precv_frame)
/*  Now, we are going to issue_auth... */
pstat->auth_seq = seq + 1;
 
-   issue_auth(padapter, pstat, (unsigned short)(_STATS_SUCCESSFUL_));
+   issue_auth(padapter, pstat, (unsigned short)(WLAN_STATUS_SUCCESS));
 
if (pstat->state & WIFI_FW_AUTH_SUCCESS)
pstat->auth_seq = 0;
@@ -1178,7 +1178,7 @@ unsigned int OnAssocReq(struct adapter *padapter, union 
recv_frame *precv_frame)
int i, ie_len, wpa_ie_len, left;
unsigned char   supportRate[16];
int supportRateNum;
-   unsigned short  status = _STATS_SUCCESSFUL_;
+   unsigned short  status = WLAN_STATUS_SUCCESS;
unsigned sho

[PATCH 10/10] staging: rtl8723bs: replace unique macros and ELEMENT_ID

2020-12-05 Thread Ross Schmidt
Replace unique macros and ELEMENT_ID with kernel provided ieee80211_eid
enum.

In a several cases multiple macros or constants are replaced by one
constant.

WLAN_EID_HT_CAP, _HT_CAPABILITY_IE_, and EID_HTCapability are replace by
WLAN_EID_HT_CAPABILITY.

_WPA2_IE_ID_, EID_WPA2, and _RSN_IE_2_ are replaced by WLAN_EID_RSN.

_HT_EXTRA_INFO_IE_ and _HT_ADD_INFO_IE_ are replaced by
WLAN_EID_HT_OPERATION.

WLAN_EID_GENERIC, _WPA_IE_ID_, _SSN_IE_1_, and _VENDOR_SPECIFIC_IE_ are
replaced by WLAN_EID_VENDOR_SPECIFIC.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/core/rtw_ap.c   |  62 
 drivers/staging/rtl8723bs/core/rtw_cmd.c  |   4 +-
 .../staging/rtl8723bs/core/rtw_ieee80211.c|  44 +++---
 drivers/staging/rtl8723bs/core/rtw_mlme.c |  26 ++--
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 146 +-
 drivers/staging/rtl8723bs/core/rtw_recv.c |   4 +-
 drivers/staging/rtl8723bs/core/rtw_security.c |   2 +-
 .../staging/rtl8723bs/core/rtw_wlan_util.c|  26 ++--
 drivers/staging/rtl8723bs/core/rtw_xmit.c |  12 +-
 drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c  |  20 +--
 drivers/staging/rtl8723bs/include/ieee80211.h |   8 -
 .../staging/rtl8723bs/include/rtw_security.h  |   3 -
 drivers/staging/rtl8723bs/include/wifi.h  | 108 -
 .../staging/rtl8723bs/os_dep/ioctl_cfg80211.c |   4 +-
 .../staging/rtl8723bs/os_dep/ioctl_linux.c|  14 +-
 drivers/staging/rtl8723bs/os_dep/mlme_linux.c |   2 +-
 16 files changed, 183 insertions(+), 302 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c 
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 04d5852d0d3e..b6f944b37b08 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -76,7 +76,7 @@ static void update_BCNTIM(struct adapter *padapter)
 
p = rtw_get_ie(
pie + _FIXED_IE_LENGTH_,
-   _TIM_IE_,
+   WLAN_EID_TIM,
&tim_ielen,
pnetwork_mlmeext->IELength - _FIXED_IE_LENGTH_
);
@@ -100,7 +100,7 @@ static void update_BCNTIM(struct adapter *padapter)
/* get ssid_ie len */
p = rtw_get_ie(
pie + _BEACON_IE_OFFSET_,
-   _SSID_IE_,
+   WLAN_EID_SSID,
&tmp_len,
(pnetwork_mlmeext->IELength - 
_BEACON_IE_OFFSET_)
);
@@ -110,7 +110,7 @@ static void update_BCNTIM(struct adapter *padapter)
/*  get supported rates len */
p = rtw_get_ie(
pie + _BEACON_IE_OFFSET_,
-   _SUPPORTEDRATES_IE_, &tmp_len,
+   WLAN_EID_SUPP_RATES, &tmp_len,
(pnetwork_mlmeext->IELength - 
_BEACON_IE_OFFSET_)
);
if (p)
@@ -133,7 +133,7 @@ static void update_BCNTIM(struct adapter *padapter)
memcpy(pbackup_remainder_ie, premainder_ie, 
remainder_ielen);
}
 
-   *dst_ie++ = _TIM_IE_;
+   *dst_ie++ = WLAN_EID_TIM;
 
if ((pstapriv->tim_bitmap & 0xff00) && (pstapriv->tim_bitmap & 
0x00fe))
tim_ielen = 5;
@@ -301,7 +301,7 @@ void expire_timeout_chk(struct adapter *padapter)
 
/* to update bcn with tim_bitmap for 
this station */
pstapriv->tim_bitmap |= BIT(psta->aid);
-   update_beacon(padapter, _TIM_IE_, NULL, 
true);
+   update_beacon(padapter, WLAN_EID_TIM, 
NULL, true);
 
if (!pmlmeext->active_keep_alive_check)
continue;
@@ -855,7 +855,7 @@ void start_bss_network(struct adapter *padapter, u8 *pbuf)
/* set channel, bwmode */
p = rtw_get_ie(
(pnetwork->IEs + sizeof(struct ndis_802_11_fix_ie)),
-   _HT_ADD_INFO_IE_,
+   WLAN_EID_HT_OPERATION,
&ie_len,
(pnetwork->IELength - sizeof(struct ndis_802_11_fix_ie))
);
@@ -922,7 +922,7 @@ void start_bss_network(struct adapter *padapter, u8 *pbuf)
);
 
if (pmlmeext->bstart_bss) {
-   update_beacon(padapter, _TIM_IE_, NULL, true);
+   update_beacon(padapter, WLAN_EID_TIM, NULL, true);
 
 #ifndef CONFIG_INTERRUPT_BASED_TXBCN /* other case will  tx beacon when bcn 
interrupt coming in. */
/* issue beacon frame */
@@ -1004,7 +1004,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 
*pbuf,  int len)
/* SSID */
p = rtw_get_ie(
ie + _BEACON_IE_OFFS

Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-12-05 Thread Nicholas Piggin
Excerpts from Andy Lutomirski's message of December 6, 2020 10:36 am:
> On Sat, Dec 5, 2020 at 3:15 PM Nicholas Piggin  wrote:
>>
>> Excerpts from Andy Lutomirski's message of December 6, 2020 2:11 am:
>> >
> 
>> If an mm was lazy tlb for a kernel thread and then it becomes unlazy,
>> and if switch_mm is serialising but return to user is not, then you
>> need a serialising instruction somewhere before return to user. unlazy
>> is the logical place to add that, because the lazy tlb mm (i.e.,
>> switching to a kernel thread and back without switching mm) is what
>> opens the hole.
> 
> The issue here is that unlazying on x86 sometimes serializes and
> sometimes doesn't.

That's additional state that x86 keeps around though, which is
fine. It can optimise that case if it knows it's already
serialised.

> It's straightforward to add logic to the x86 code
> to serialize specifically in the case where membarrier core sync is
> registered and unlazying would otherwise not serialize, but trying to
> define sensible semantics for this in a call to core code seems
> complicated.

It's not though, it's a call from core code (to arch code).

> (Specifically, the x86 code only sometimes sends IPIs to
> lazy CPUs for TLB flushes.  If an IPI is skipped, then unlazying will
> flush the TLB, and that operation is serializing.
> 
> The whole lazy thing is IMO a red herring for membarrier().  The
> membarrier() logic requires that switching *logical* mms
> (rq->curr->mm) serializes before user mode if the new mm is registered
> for core sync.

It's not a red herring, the reason the IPI gets skipped is because
we go to a kernel thread -- that's all core code and core lazy tlb
handling.

That x86 might do some additional ops serialise during un-lazy in
some cases doesn't make that a red herring, it just means that you
can take advantage of it and avoid doing an extra serialising op.

> AFAICT the only architecture on which this isn't
> automatic is x86, and somehow the logic turned into "actually changing
> rq->curr->mm serializes, but unlazying only sometimes serializes, so
> we need to do an extra serialization step on unlazying operations"
> instead of "tell x86 to make sure it always serializes when it
> switches logical mms".  The latter is easy to specify and easy to
> implement.
> 
>>
>> How do you mean? exit_lazy_tlb is the opposite, core scheduler notifying
>> arch code about when an mm becomes not-lazy, and nothing to do with
>> membarrier at all even. It's a convenient hook to do your un-lazying.
>> I guess you can do it also checking things in switch_mm and keeping state
>> in arch code, I don't think that's necessarily the best place to put it.
> 
> I'm confused.  I just re-read your patches, and it looks like you have
> arch code calling exit_lazy_tlb().

More for code-comment / consistency than anything else. They are
entirely arch hooks.

> On x86, if we do a TLB shootdown
> IPI to a lazy CPU, the IPI handler will unlazy that CPU (by switching
> to init_mm for real), and we have no way to notify the core scheduler
> about this, so we don't.  The result is that the core scheduler state
> and the x86 state gets out of sync.  If the core scheduler
> subsequently switches us back to the mm that it thinks we were still
> using lazily them, from the x86 code's perspective, we're not
> unlazying -- we're just doing a regular switch from init_mm to some
> other mm.  This is why x86's switch_mm_irqs_off() totally ignores its
> 'prev' argument.

You actually do now have such a way to do that now that we've
(hopefully) closed races, and I think should use it, which might make 
things simpler for you. See patch 6 do_shoot_lazy_tlb().

> I'm honestly a bit surprised that other architectures don't do the
> same thing.  I suppose that some architectures don't use shootdown
> IPIs at all, in which case there doesn't seem to be any good reason to
> aggressively unlazy.

powerpc/radix does (in some cases) since a few years ago. It just 
doesn't fully exploit that for the final TLB shootdown to always clean 
them all up and avoid the subsequent shoot-lazies IPI, but it could be 
more aggressive there.

The powerpc virtualised hash architecture is the traditional one and 
isn't conducive to this (translation management is done via hcalls, and
the hypervisor maintains the TLB) so I suspect that's why it wasn't
done earlier there. That will continue to rely on shoot-lazies.

> (Oddly, despite the fact that, since Ivy Bridge, x86 has a "just flush
> the TLB" instruction, that instruction is considerably slower than the
> old "switch mm and flush" operation.  So the operation "switch to
> init_mm" is only ever any slower than "flush and stay lazy" if we get
> lucky and unlazy to the same mm before we get a second TLB shootdown
> *and* if unlazying to the same mm would not have needed to flush.  I
> spend quite a bit of time tuning this stuff and being quite surprised
> at the bizarre performance properties of Intel's TLB management
> 

Re: [PATCH v3 6/7] input: atc260x: Add onkey driver for ATC260x PMICs

2020-12-05 Thread Dmitry Torokhov
On Sun, Dec 06, 2020 at 03:27:06AM +0200, Cristian Ciocaltea wrote:
> The Actions Semi ATC260x PMICs are able to manage an onkey button.
> This driver exposes the ATC260x onkey as an input device. It can also
> be configured to force a system reset on a long key-press with an
> adjustable duration.
> 
> The currently supported chip variants are ATC2603C and ATC2609A.
> 
> Signed-off-by: Cristian Ciocaltea 
> ---
> Changes in v3: 
>  - Integrated Dmitry's review:
>* Dropped the logic around the check for 'pdev->dev.of_node'
>* Renamed 'ret' variable in 'atc260x_onkey_probe()' to 'error'
>* Used 'dev_dbg' instead of 'dev_info' on status KEY_RESET_DISABLED
>* Dropped 'input_dev->evbit[0] = BIT_MASK(EV_KEY);'
>* Removed IRQF_TRIGGER_HIGH flag on 'devm_request_threaded_irq()'
>* Implemented open/close to mitigate the racing issue in
>  'atc260x_onkey_remove()' which has been dropped now
>  - Removed the unnecessary driver compatibles
>  - Used 'reset-time-sec' property of the parent device instead of
>'actions,reset-time-sec' of now obsolete and removed 'onkey' DT node

Acked-by: Dmitry Torokhov 

Please merge with the rest through MFD I suppose.

Thanks.

-- 
Dmitry


[PATCH V2 net-next 2/3] net: hns3: add priv flags support to switch limit promisc mode

2020-12-05 Thread Huazhong Tan
From: Jian Shen 

Currently, the tx unicast promisc is always enabled when promisc
mode on. If tx unicast promisc on, a function will receive all
unicast packet from other functions belong to the same port.
Add a ethtool private flag to control whether enable tx
unicast promisc. Then the function is able to filter the
unknown unicast packets from other function.

Signed-off-by: Jian Shen 
---
 drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h|  1 +
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|  8 ++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c|  3 +
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 86 ++
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c|  8 +-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c |  7 ++
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  |  7 ++
 7 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h 
b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
index 1ffe8fa..fb5e884 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
@@ -110,6 +110,7 @@ struct hclge_vf_to_pf_msg {
u8 en_bc;
u8 en_uc;
u8 en_mc;
+   u8 en_limit_promisc;
};
struct {
u8 vector_id;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 78b4886..1a09b1f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -719,6 +719,11 @@ struct hnae3_roce_private_info {
 #define HNAE3_UPE  (HNAE3_USER_UPE | HNAE3_OVERFLOW_UPE)
 #define HNAE3_MPE  (HNAE3_USER_MPE | HNAE3_OVERFLOW_MPE)
 
+enum hnae3_pflag {
+   HNAE3_PFLAG_LIMIT_PROMISC,
+   HNAE3_PFLAG_MAX
+};
+
 struct hnae3_handle {
struct hnae3_client *client;
struct pci_dev *pdev;
@@ -741,6 +746,9 @@ struct hnae3_handle {
 
/* Network interface message level enabled bits */
u32 msg_enable;
+
+   unsigned long supported_pflags;
+   unsigned long priv_flags;
 };
 
 #define hnae3_set_field(origin, mask, shift, val) \
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 1798c0a..69ae15b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -4226,6 +4226,9 @@ static int hns3_client_init(struct hnae3_handle *handle)
 
set_bit(HNS3_NIC_STATE_INITED, &priv->state);
 
+   if (ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V3)
+   set_bit(HNAE3_PFLAG_LIMIT_PROMISC, &handle->supported_pflags);
+
if (netif_msg_drv(handle))
hns3_info_show(priv);
 
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 3cca3c1..e2fc443 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -18,6 +18,11 @@ struct hns3_sfp_type {
u8 ext_type;
 };
 
+struct hns3_pflag_desc {
+   char name[ETH_GSTRING_LEN];
+   void (*handler)(struct net_device *netdev, bool enable);
+};
+
 /* tqp related stats */
 #define HNS3_TQP_STAT(_string, _member){   \
.stats_string = _string,\
@@ -60,6 +65,8 @@ static const struct hns3_stats hns3_rxq_stats[] = {
HNS3_TQP_STAT("non_reuse_pg", non_reuse_pg),
 };
 
+#define HNS3_PRIV_FLAGS_LEN ARRAY_SIZE(hns3_priv_flags)
+
 #define HNS3_RXQ_STATS_COUNT ARRAY_SIZE(hns3_rxq_stats)
 
 #define HNS3_TQP_STATS_COUNT (HNS3_TXQ_STATS_COUNT + HNS3_RXQ_STATS_COUNT)
@@ -395,6 +402,23 @@ static void hns3_self_test(struct net_device *ndev,
netif_dbg(h, drv, ndev, "self test end\n");
 }
 
+static void hns3_update_limit_promisc_mode(struct net_device *netdev,
+  bool enable)
+{
+   struct hnae3_handle *handle = hns3_get_handle(netdev);
+
+   if (enable)
+   set_bit(HNAE3_PFLAG_LIMIT_PROMISC, &handle->priv_flags);
+   else
+   clear_bit(HNAE3_PFLAG_LIMIT_PROMISC, &handle->priv_flags);
+
+   hns3_request_update_promisc_mode(handle);
+}
+
+static const struct hns3_pflag_desc hns3_priv_flags[HNAE3_PFLAG_MAX] = {
+   { "limit_promisc",  hns3_update_limit_promisc_mode }
+};
+
 static int hns3_get_sset_count(struct net_device *netdev, int stringset)
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
@@ -411,6 +435,9 @@ static int hns3_get_sset_count(struct net_device *netdev, 
int stringset)
case ETH_SS_TEST:
return ops->get_sset_count(h, stringset);
 
+   case ETH_SS_PRIV_FLAGS:
+   return HNAE3_PFLAG_MAX;
+
default:
return -EOPNOTSUPP;
}
@@ -

[PATCH 05/10] staging: rtl8723bs: replace OP_MODE_* and HT_INFO_OPERATION_MODE_* macros

2020-12-05 Thread Ross Schmidt
Replace unique OP_MODE_* and HT_INFO_OPERATION_MODE_* macro families
with kernel provided IEEE80211_HT_OP_MODE_* macros.

Signed-off-by: Ross Schmidt 
---
 drivers/staging/rtl8723bs/core/rtw_ap.c  | 30 
 drivers/staging/rtl8723bs/include/wifi.h | 13 --
 2 files changed, 15 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c 
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 984b9f5a83ac..27446156ed34 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -1842,28 +1842,28 @@ static int rtw_ht_operation_update(struct adapter 
*padapter)
DBG_871X("%s current operation mode = 0x%X\n",
   __func__, pmlmepriv->ht_op_mode);
 
-   if (!(pmlmepriv->ht_op_mode & 
HT_INFO_OPERATION_MODE_NON_GF_DEVS_PRESENT)
+   if (!(pmlmepriv->ht_op_mode & IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT)
&& pmlmepriv->num_sta_ht_no_gf) {
pmlmepriv->ht_op_mode |=
-   HT_INFO_OPERATION_MODE_NON_GF_DEVS_PRESENT;
+   IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT;
op_mode_changes++;
} else if ((pmlmepriv->ht_op_mode &
-   HT_INFO_OPERATION_MODE_NON_GF_DEVS_PRESENT) &&
+   IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT) &&
   pmlmepriv->num_sta_ht_no_gf == 0) {
pmlmepriv->ht_op_mode &=
-   ~HT_INFO_OPERATION_MODE_NON_GF_DEVS_PRESENT;
+   ~IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT;
op_mode_changes++;
}
 
-   if (!(pmlmepriv->ht_op_mode & 
HT_INFO_OPERATION_MODE_NON_HT_STA_PRESENT) &&
+   if (!(pmlmepriv->ht_op_mode & IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT) &&
(pmlmepriv->num_sta_no_ht || pmlmepriv->olbc_ht)) {
-   pmlmepriv->ht_op_mode |= 
HT_INFO_OPERATION_MODE_NON_HT_STA_PRESENT;
+   pmlmepriv->ht_op_mode |= IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT;
op_mode_changes++;
} else if ((pmlmepriv->ht_op_mode &
-   HT_INFO_OPERATION_MODE_NON_HT_STA_PRESENT) &&
+   IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT) &&
   (pmlmepriv->num_sta_no_ht == 0 && !pmlmepriv->olbc_ht)) {
pmlmepriv->ht_op_mode &=
-   ~HT_INFO_OPERATION_MODE_NON_HT_STA_PRESENT;
+   ~IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT;
op_mode_changes++;
}
 
@@ -1873,20 +1873,20 @@ static int rtw_ht_operation_update(struct adapter 
*padapter)
 */
new_op_mode = 0;
if (pmlmepriv->num_sta_no_ht ||
-   (pmlmepriv->ht_op_mode & 
HT_INFO_OPERATION_MODE_NON_GF_DEVS_PRESENT))
-   new_op_mode = OP_MODE_MIXED;
+   (pmlmepriv->ht_op_mode & IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT))
+   new_op_mode = IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED;
else if (
(le16_to_cpu(phtpriv_ap->ht_cap.cap_info) & 
IEEE80211_HT_CAP_SUP_WIDTH)
&& pmlmepriv->num_sta_ht_20mhz)
-   new_op_mode = OP_MODE_20MHZ_HT_STA_ASSOCED;
+   new_op_mode = IEEE80211_HT_OP_MODE_PROTECTION_20MHZ;
else if (pmlmepriv->olbc_ht)
-   new_op_mode = OP_MODE_MAY_BE_LEGACY_STAS;
+   new_op_mode = IEEE80211_HT_OP_MODE_PROTECTION_NONMEMBER;
else
-   new_op_mode = OP_MODE_PURE;
+   new_op_mode = IEEE80211_HT_OP_MODE_PROTECTION_NONE;
 
-   cur_op_mode = pmlmepriv->ht_op_mode & 
HT_INFO_OPERATION_MODE_OP_MODE_MASK;
+   cur_op_mode = pmlmepriv->ht_op_mode & IEEE80211_HT_OP_MODE_PROTECTION;
if (cur_op_mode != new_op_mode) {
-   pmlmepriv->ht_op_mode &= ~HT_INFO_OPERATION_MODE_OP_MODE_MASK;
+   pmlmepriv->ht_op_mode &= ~IEEE80211_HT_OP_MODE_PROTECTION;
pmlmepriv->ht_op_mode |= new_op_mode;
op_mode_changes++;
}
diff --git a/drivers/staging/rtl8723bs/include/wifi.h 
b/drivers/staging/rtl8723bs/include/wifi.h
index 9c92b5020fbc..2fb1687ecabf 100644
--- a/drivers/staging/rtl8723bs/include/wifi.h
+++ b/drivers/staging/rtl8723bs/include/wifi.h
@@ -673,12 +673,6 @@ struct ADDBA_request {
 #define WLAN_HT_CAP_SM_PS_INVALID  2
 #define WLAN_HT_CAP_SM_PS_DISABLED 3
 
-
-#define OP_MODE_PURE0
-#define OP_MODE_MAY_BE_LEGACY_STAS  1
-#define OP_MODE_20MHZ_HT_STA_ASSOCED2
-#define OP_MODE_MIXED   3
-
 #define HT_INFO_HT_PARAM_SECONDARY_CHNL_OFF_MASK   ((u8) BIT(0) | BIT(1))
 #define HT_INFO_HT_PARAM_SECONDARY_CHNL_ABOVE  ((u8) BIT(0))
 #define HT_INFO_HT_PARAM_SECONDARY_CHNL_BELOW  ((u8) BIT(0) | BIT(1))
@@ -687,13 +681,6 @@ struct ADDBA_request {
 #define HT_INFO_HT_PARAM_CTRL_ACCESS_ONLY  ((u8) BIT(4))
 #define HT_INFO_HT_PARAM_SRV_INTERVAL_GRANULARITY  ((u8) BIT(5))
 
-#define HT_INFO_OPERATION_MODE_OP_MODE_MASK 

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

2020-12-05 Thread syzbot
syzbot has found a reproducer for the following issue on:

HEAD commit:b3298500 Merge tag 'for-5.10/dm-fixes' of git://git.kernel..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1003173d50
kernel config:  https://syzkaller.appspot.com/x/.config?x=b3a044ccf5b03ac4
dashboard link: https://syzkaller.appspot.com/bug?extid=a296f64433c9cfd55cc8
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11ace3f750
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16f0d2ef50

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

==
BUG: KASAN: use-after-free in squashfs_get_id+0x1ae/0x1d0 fs/squashfs/id.c:38
Read of size 8 at addr 88801e52f0d8 by task syz-executor067/8471

CPU: 1 PID: 8471 Comm: syz-executor067 Not tainted 5.10.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:385
 __kasan_report mm/kasan/report.c:545 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562
 squashfs_get_id+0x1ae/0x1d0 fs/squashfs/id.c:38
 squashfs_new_inode fs/squashfs/inode.c:51 [inline]
 squashfs_read_inode+0x1b4/0x1b40 fs/squashfs/inode.c:120
 squashfs_fill_super+0x1140/0x23b0 fs/squashfs/super.c:310
 get_tree_bdev+0x421/0x740 fs/super.c:1344
 vfs_get_tree+0x89/0x2f0 fs/super.c:1549
 do_new_mount fs/namespace.c:2875 [inline]
 path_mount+0x13ad/0x20c0 fs/namespace.c:3205
 do_mount fs/namespace.c:3218 [inline]
 __do_sys_mount fs/namespace.c:3426 [inline]
 __se_sys_mount fs/namespace.c:3403 [inline]
 __x64_sys_mount+0x27f/0x300 fs/namespace.c:3403
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d1a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 
84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 
da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:7ffc9fb56f38 EFLAGS: 0293 ORIG_RAX: 00a5
RAX: ffda RBX: 7ffc9fb56f90 RCX: 00446d1a
RDX: 2000 RSI: 2100 RDI: 7ffc9fb56f50
RBP: 7ffc9fb56f50 R08: 7ffc9fb56f90 R09: 7ffc0015
R10:  R11: 0293 R12: 0001
R13: 0004 R14: 0003 R15: 0003

Allocated by task 8471:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
 kasan_set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
 __do_kmalloc mm/slab.c:3657 [inline]
 __kmalloc+0x23d/0x490 mm/slab.c:3666
 kmalloc_array include/linux/slab.h:592 [inline]
 kcalloc include/linux/slab.h:603 [inline]
 squashfs_read_table+0xbb/0x1e0 fs/squashfs/cache.c:417
 squashfs_read_id_index_table+0xab/0x120 fs/squashfs/id.c:77
 squashfs_fill_super+0xdd0/0x23b0 fs/squashfs/super.c:238
 get_tree_bdev+0x421/0x740 fs/super.c:1344
 vfs_get_tree+0x89/0x2f0 fs/super.c:1549
 do_new_mount fs/namespace.c:2875 [inline]
 path_mount+0x13ad/0x20c0 fs/namespace.c:3205
 do_mount fs/namespace.c:3218 [inline]
 __do_sys_mount fs/namespace.c:3426 [inline]
 __se_sys_mount fs/namespace.c:3403 [inline]
 __x64_sys_mount+0x27f/0x300 fs/namespace.c:3403
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 8471:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
 __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422
 __cache_free mm/slab.c:3420 [inline]
 kfree+0xe8/0x240 mm/slab.c:3758
 squashfs_read_table+0x189/0x1e0 fs/squashfs/cache.c:435
 squashfs_read_id_index_table+0xab/0x120 fs/squashfs/id.c:77
 squashfs_fill_super+0xdd0/0x23b0 fs/squashfs/super.c:238
 get_tree_bdev+0x421/0x740 fs/super.c:1344
 vfs_get_tree+0x89/0x2f0 fs/super.c:1549
 do_new_mount fs/namespace.c:2875 [inline]
 path_mount+0x13ad/0x20c0 fs/namespace.c:3205
 do_mount fs/namespace.c:3218 [inline]
 __do_sys_mount fs/namespace.c:3426 [inline]
 __se_sys_mount fs/namespace.c:3403 [inline]
 __x64_sys_mount+0x27f/0x300 fs/namespace.c:3403
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

The buggy address belongs to the object at 88801e52f0c0
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 24 bytes inside of
 32-byte region [88801e52f0c0, 88801e52f0e0)
The buggy address belongs to the page:
page:9f69cbb3 refcount:1 mapcount:0 mapping: 
index:0x88801e52ffc1 pfn:0x1e52f
flags: 0xfff200(slab)
raw: 00fff200 ea53f4c8 888010041250 ff

[PATCH V2 net-next 3/3] net: hns3: refine the VLAN tag handle for port based VLAN

2020-12-05 Thread Huazhong Tan
From: Guojia Liao 

For DEVICE_VERSION_V2, the hardware only supports max two layer
VLAN tags, including port based tag inserted by hardware, tag in
tx buffer descriptor(get from skb->tci) and tag in packet.

For transmit packet:
If port based VLAN disabled, and vf driver gets a VLAN tag from
skb, the VLAN tag must be filled to the Outer_VLAN_TAG field
(tag near to DMAC) of tx buffer descriptor, otherwise it may
be inserted after the tag in packet.

If port based VLAN enabled, and vf driver gets a VLAN tag from
skb, the VLAN tag must be filled to the VLAN_TAG field (tag
far to DMAC) of tx buffer descriptor, otherwise it may be
conflicted with port based VLAN, and raise a hardware error.

For receive packet:
The hardware will strip the VLAN tags and fill them in the rx
buffer descriptor, no matter port based VLAN enable or not.
Because port based VLAN tag is useless for stack, so vf driver
needs to discard the port based VLAN tag get from rx buffer
descriptor when port based VLAN enabled.

So vf must know about the port based VLAN state.

For DEVICE_VERSION_V3, the hardware provides some new
configuration to improve it.

For transmit packet:
When enable tag shift mode, hardware will handle the VLAN tag
in outer_VLAN_TAG field as VLAN_TAG, so it won't conflict with
port based VLAN. And hardware also make sure the tag before
the tag in packet. So vf driver doesn't need to specify the tag
position according to the port based VLAN state anymore.

For receive packet:
When enable discard mode, hardware will strip and discard the
port based VLAN tag, so vf driver doesn't need to identify it
from rx buffer descriptor.

So modify the port based VLAN configuration, simplify the process
for vf handling the VLAN tag.

Signed-off-by: Guojia Liao 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c|  8 +++-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h |  3 ++
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 46 +-
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 13 +++---
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 11 +-
 5 files changed, 64 insertions(+), 17 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 69ae15b..4c2fb86 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1006,6 +1006,7 @@ static int hns3_handle_vtags(struct hns3_enet_ring 
*tx_ring,
 struct sk_buff *skb)
 {
struct hnae3_handle *handle = tx_ring->tqp->handle;
+   struct hnae3_ae_dev *ae_dev;
struct vlan_ethhdr *vhdr;
int rc;
 
@@ -1013,10 +1014,13 @@ static int hns3_handle_vtags(struct hns3_enet_ring 
*tx_ring,
  skb_vlan_tag_present(skb)))
return 0;
 
-   /* Since HW limitation, if port based insert VLAN enabled, only one VLAN
-* header is allowed in skb, otherwise it will cause RAS error.
+   /* For HW limitation on HNAE3_DEVICE_VERSION_V2, if port based insert
+* VLAN enabled, only one VLAN header is allowed in skb, otherwise it
+* will cause RAS error.
 */
+   ae_dev = pci_get_drvdata(handle->pdev);
if (unlikely(skb_vlan_tagged_multi(skb) &&
+ae_dev->dev_version <= HNAE3_DEVICE_VERSION_V2 &&
 handle->port_base_vlan_state ==
 HNAE3_PORT_BASE_VLAN_ENABLE))
return -EINVAL;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 7ce8be1..52a6f9b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -825,6 +825,7 @@ enum hclge_mac_vlan_cfg_sel {
 #define HCLGE_CFG_NIC_ROCE_SEL_B   4
 #define HCLGE_ACCEPT_TAG2_B5
 #define HCLGE_ACCEPT_UNTAG2_B  6
+#define HCLGE_TAG_SHIFT_MODE_EN_B  7
 #define HCLGE_VF_NUM_PER_BYTE  8
 
 struct hclge_vport_vtag_tx_cfg_cmd {
@@ -841,6 +842,8 @@ struct hclge_vport_vtag_tx_cfg_cmd {
 #define HCLGE_REM_TAG2_EN_B1
 #define HCLGE_SHOW_TAG1_EN_B   2
 #define HCLGE_SHOW_TAG2_EN_B   3
+#define HCLGE_DISCARD_TAG1_EN_B5
+#define HCLGE_DISCARD_TAG2_EN_B6
 struct hclge_vport_vtag_rx_cfg_cmd {
u8 vport_vlan_cfg;
u8 vf_offset;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index d83fcde..a70f44d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -8617,6 +8617,8 @@ static int hclge_set_vlan_tx_offload_cfg(struct 
hclge_vport *vport)
  vcfg->insert_tag1_en ? 1 : 0);
hnae3_set_bit(req->vport_vlan_cfg, HCLGE_PORT_INS_TAG2_EN_B,
  vcf

[PATCH V2 net-next 0/3] net: hns3: updates for -next

2020-12-05 Thread Huazhong Tan
There are some updates for the HNS3 ethernet driver.

#1 supports an extended promiscuous command which makes
promiscuous configuration more flexible, #2 adds ethtool
private flags to control whether enable tx unicast promisc.
#3 refine the vlan tag handling for port based vlan.

change log:
V2: modifies #2 suggested by Jakub Kicinski.
fixes some spelling mistake in #3.

previous version:
https://patchwork.kernel.org/project/netdevbpf/cover/1606997936-22166-1-git-send-email-tanhuazh...@huawei.com/

Guojia Liao (2):
  net: hns3: add support for extended promiscuous command
  net: hns3: refine the VLAN tag handle for port based VLAN

Jian Shen (1):
  net: hns3: add priv flags support to switch limit promisc mode

 drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h|   1 +
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|   8 ++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c|  11 +-
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c |  86 
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h |  34 ---
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 111 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|  13 ++-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c |  18 +++-
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  |   7 ++
 9 files changed, 223 insertions(+), 66 deletions(-)

-- 
2.7.4



Re: [tip: x86/urgent] x86/uprobes: Do not use prefixes.nbytes when looping over prefixes.bytes

2020-12-05 Thread Masami Hiramatsu
On Sat, 5 Dec 2020 11:17:04 +0100
Borislav Petkov  wrote:

> On Sat, Dec 05, 2020 at 09:12:56AM +0900, Masami Hiramatsu wrote:
> > This may break tools/objtool build. Please keep "inat.h".
> 
> How? Please elaborate.
> 
> Build tests are fine here.

Oops, sorry, it was for perf build.

Please refer commit 00a263902ac3 ("perf intel-pt: Use shared x86 insn decoder").

Thank you,

-- 
Masami Hiramatsu 


Re: [PATCH] kbuild: avoid static_assert for genksyms

2020-12-05 Thread Masahiro Yamada
On Fri, Dec 4, 2020 at 8:10 AM Arnd Bergmann  wrote:
>
> From: Arnd Bergmann 
>
> genksyms does not know or care about the _Static_assert() built-in,
> and sometimes falls back to ignoring the later symbols, which causes
> undefined behavior such as
>
> WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] 
> version generation failed, symbol will not be versioned.
> ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against 
> `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared 
> object
> net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: 
> unsupported relocation
>
> Redefine static_assert for genksyms to avoid that.


Please tell the CONFIG options needed to reproduce this.
I do not see it.


>
> Cc: sta...@vger.kernel.org
> Suggested-by: Ard Biesheuvel 
> Signed-off-by: Arnd Bergmann 
> ---
>  include/linux/build_bug.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
> index e3a0be2c90ad..7bb66e15b481 100644
> --- a/include/linux/build_bug.h
> +++ b/include/linux/build_bug.h
> @@ -77,4 +77,9 @@
>  #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
>  #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>
> +#ifdef __GENKSYMS__
> +/* genksyms gets confused by _Static_assert */
> +#define _Static_assert(expr, ...)
> +#endif
> +
>  #endif /* _LINUX_BUILD_BUG_H */
> --
> 2.27.0
>


-- 
Best Regards
Masahiro Yamada


[PATCH V2 net-next 1/3] net: hns3: add support for extended promiscuous command

2020-12-05 Thread Huazhong Tan
From: Guojia Liao 

For DEVICE_VERSION_V2, the hardware supports enable tx and rx
promiscuous separately. But tx or rx promiscuous is active for
unicast, multicast and broadcast promiscuous simultaneously.
To support traffics between functions belong to the same port,
we always enable tx promiscuous for broadcast promiscuous, so
tx promiscuous for unicast and multicast promiscuous is also
enabled.

For DEVICE_VERSION_V3, the hardware decouples the above
relationship. Tx unicast promiscuous, rx unicast promiscuous,
tx multicast promiscuous, rx multicast promiscuous, tx broadcast
promiscuous and rx broadcast promiscuous can be enabled separately.

So add support for the new promiscuous command.

Signed-off-by: Guojia Liao 
Signed-off-by: Huazhong Tan 
---
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 31 +++-
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 59 +-
 2 files changed, 41 insertions(+), 49 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index 49cbd95..7ce8be1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -583,23 +583,26 @@ struct hclge_link_status_cmd {
u8 rsv[23];
 };
 
-struct hclge_promisc_param {
-   u8 vf_id;
-   u8 enable;
-};
+/* for DEVICE_VERSION_V1/2, reference to promisc cmd byte8 */
+#define HCLGE_PROMISC_EN_UC1
+#define HCLGE_PROMISC_EN_MC2
+#define HCLGE_PROMISC_EN_BC3
+#define HCLGE_PROMISC_TX_EN4
+#define HCLGE_PROMISC_RX_EN5
+
+/* for DEVICE_VERSION_V3, reference to promisc cmd byte10 */
+#define HCLGE_PROMISC_UC_RX_EN 2
+#define HCLGE_PROMISC_MC_RX_EN 3
+#define HCLGE_PROMISC_BC_RX_EN 4
+#define HCLGE_PROMISC_UC_TX_EN 5
+#define HCLGE_PROMISC_MC_TX_EN 6
+#define HCLGE_PROMISC_BC_TX_EN 7
 
-#define HCLGE_PROMISC_TX_EN_B  BIT(4)
-#define HCLGE_PROMISC_RX_EN_B  BIT(5)
-#define HCLGE_PROMISC_EN_B 1
-#define HCLGE_PROMISC_EN_ALL   0x7
-#define HCLGE_PROMISC_EN_UC0x1
-#define HCLGE_PROMISC_EN_MC0x2
-#define HCLGE_PROMISC_EN_BC0x4
 struct hclge_promisc_cfg_cmd {
-   u8 flag;
+   u8 promisc;
u8 vf_id;
-   __le16 rsv0;
-   u8 rsv1[20];
+   u8 extend_promisc;
+   u8 rsv0[21];
 };
 
 enum hclge_promisc_type {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index ca668a4..f4859ad 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -4826,61 +4826,50 @@ static int hclge_unmap_ring_frm_vector(struct 
hnae3_handle *handle, int vector,
return ret;
 }
 
-static int hclge_cmd_set_promisc_mode(struct hclge_dev *hdev,
- struct hclge_promisc_param *param)
+static int hclge_cmd_set_promisc_mode(struct hclge_dev *hdev, u8 vf_id,
+ bool en_uc, bool en_mc, bool en_bc)
 {
struct hclge_promisc_cfg_cmd *req;
struct hclge_desc desc;
+   u8 promisc_cfg = 0;
int ret;
 
hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_CFG_PROMISC_MODE, false);
 
req = (struct hclge_promisc_cfg_cmd *)desc.data;
-   req->vf_id = param->vf_id;
+   req->vf_id = vf_id;
 
-   /* HCLGE_PROMISC_TX_EN_B and HCLGE_PROMISC_RX_EN_B are not supported on
-* pdev revision(0x20), new revision support them. The
-* value of this two fields will not return error when driver
-* send command to fireware in revision(0x20).
-*/
-   req->flag = (param->enable << HCLGE_PROMISC_EN_B) |
-   HCLGE_PROMISC_TX_EN_B | HCLGE_PROMISC_RX_EN_B;
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_UC_RX_EN, en_uc ? 1 : 0);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_MC_RX_EN, en_mc ? 1 : 0);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_BC_RX_EN, en_bc ? 1 : 0);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_UC_TX_EN, en_uc ? 1 : 0);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_MC_TX_EN, en_mc ? 1 : 0);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_BC_TX_EN, en_bc ? 1 : 0);
+   req->extend_promisc = promisc_cfg;
+
+   /* to be compatible with DEVICE_VERSION_V1/2 */
+   promisc_cfg = 0;
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_EN_UC, en_uc ? 1 : 0);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_EN_MC, en_mc ? 1 : 0);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_EN_BC, en_bc ? 1 : 0);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_TX_EN, 1);
+   hnae3_set_bit(promisc_cfg, HCLGE_PROMISC_RX_EN, 1);
+   req->promisc = promisc_cfg;
 
ret = hclge_cmd_send(&hdev->hw, &desc, 1);
if (ret)
dev_err(&hdev->pdev->dev,
-   "failed to set vport %d promisc mode, ret = %d.\n",
-   param->vf_id, ret);
+   "faile

Re: [PATCH net-next 3/3] net: hns3: refine the VLAN tag handle for port based VLAN

2020-12-05 Thread tanhuazhong




On 2020/12/5 10:22, Jakub Kicinski wrote:

On Thu, 3 Dec 2020 20:18:56 +0800 Huazhong Tan wrote:

tranmist


Please spell check the commit messages and comments.



will fix spelling mistakes, thanks


.





Re: [PATCH net-next 2/3] net: hns3: add priv flags support to switch limit promisc mode

2020-12-05 Thread tanhuazhong




On 2020/12/5 10:24, Jakub Kicinski wrote:

On Thu, 3 Dec 2020 20:18:55 +0800 Huazhong Tan wrote:

@@ -224,6 +224,7 @@ static int hclge_map_unmap_ring_to_vf_vector(struct 
hclge_vport *vport, bool en,
  static int hclge_set_vf_promisc_mode(struct hclge_vport *vport,
 struct hclge_mbx_vf_to_pf_cmd *req)
  {
+   struct hnae3_handle *handle = &vport->nic;
bool en_bc = req->msg.en_bc ? true : false;
bool en_uc = req->msg.en_uc ? true : false;
bool en_mc = req->msg.en_mc ? true : false;


Please order variable lines longest to shortest.


will fix it, thanks.




@@ -1154,6 +1158,8 @@ static int hclgevf_cmd_set_promisc_mode(struct 
hclgevf_dev *hdev,
send_msg.en_bc = en_bc_pmc ? 1 : 0;
send_msg.en_uc = en_uc_pmc ? 1 : 0;
send_msg.en_mc = en_mc_pmc ? 1 : 0;
+   send_msg.en_limit_promisc =
+   test_bit(HNAE3_PFLAG_LIMIT_PROMISC_ENABLE, &handle->priv_flags) ? 1 : 0;


The continuation line should be indented more than the first line.


yes, will fix it.



I suggest you rename HNAE3_PFLAG_LIMIT_PROMISC_ENABLE to
HNAE3_PFLAG_LIMIT_PROMISC, the _ENABLE doesn't add much
to the meaning. That way the lines will get shorter.



ok, thanks.


.





[GIT PULL] ARM: at91: DT for 5.11 #2

2020-12-05 Thread Alexandre Belloni
Arnd, Olof,

Here is a second round of DT updates, Some are following patches series
that made it in other subsystems and it would be nice to have them in
the same release. Other are fixes worth having in v5.11.

The following changes since commit e1062fa7292f1e3744db0a487c4ac0109e09b03d:

  ARM: dts: at91: sama5d3_xplained: add pincontrol for USB Host (2020-11-24 
12:11:27 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-dt-5.11-2

for you to fetch changes up to 85b8350ae99d1300eb6dc072459246c2649a8e50:

  ARM: dts: at91: sama5d2: fix CAN message ram offset and size (2020-12-03 
21:44:36 +0100)


AT91 DT for 5.11 #2:

 - switch to new TCB PWM bindings
 - rework ADC bindings
 - fix sama5d2 securam and can1


Alexandre Belloni (4):
  ARM: dts: at91: kizbox: switch to new pwm-atmel-tcb binding
  ARM: dts: at91: sama5d3: use proper ADC compatible
  ARM: dts: at91: at91sam9rl: fix ADC triggers
  ARM: dts: at91: remove deprecated ADC properties

Claudiu Beznea (2):
  ARM: dts: at91: sam9x60ek: remove bypass property
  ARM: dts: at91: sama5d2: map securam as device

Nicolas Ferre (1):
  ARM: dts: at91: sama5d2: fix CAN message ram offset and size

 arch/arm/boot/dts/at91-kizbox.dts| 45 
 arch/arm/boot/dts/at91-sam9x60ek.dts |  4 
 arch/arm/boot/dts/at91sam9260.dtsi   | 25 
 arch/arm/boot/dts/at91sam9g45.dtsi   | 27 --
 arch/arm/boot/dts/at91sam9rl.dtsi| 25 
 arch/arm/boot/dts/at91sam9x5.dtsi| 28 --
 arch/arm/boot/dts/sama5d2.dtsi   |  7 +++---
 arch/arm/boot/dts/sama5d3.dtsi   | 26 +
 arch/arm/boot/dts/sama5d4.dtsi   | 22 --
 9 files changed, 35 insertions(+), 174 deletions(-)

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


[PATCH v3 7/7] MAINTAINERS: Add entry for ATC260x PMIC

2020-12-05 Thread Cristian Ciocaltea
From: Manivannan Sadhasivam 

Add MAINTAINERS entry for ATC260x PMIC.

Signed-off-by: Manivannan Sadhasivam 
[cristian: change binding doc file path, add file patterns for onkey and
   poweroff drivers, fix ordering, add myself as co-maintainer]
Signed-off-by: Cristian Ciocaltea 
---
Changes in v3: 
 - Restored the authorship of the patch to Mani

 MAINTAINERS | 12 
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index bfb92005eb3c..740134ce8449 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2875,6 +2875,18 @@ W:   http://www.openaoe.org/
 F: Documentation/admin-guide/aoe/
 F: drivers/block/aoe/
 
+ATC260X PMIC MFD DRIVER
+M: Manivannan Sadhasivam 
+M: Cristian Ciocaltea 
+L: linux-acti...@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/actions,atc260x.yaml
+F: drivers/input/misc/atc260x-onkey.c
+F: drivers/mfd/atc260*
+F: drivers/power/reset/atc260x-poweroff.c
+F: drivers/regulator/atc260x-regulator.c
+F: include/linux/mfd/atc260x/*
+
 ATHEROS 71XX/9XXX GPIO DRIVER
 M: Alban Bedel 
 S: Maintained
-- 
2.29.2



[PATCH v3 6/7] input: atc260x: Add onkey driver for ATC260x PMICs

2020-12-05 Thread Cristian Ciocaltea
The Actions Semi ATC260x PMICs are able to manage an onkey button.
This driver exposes the ATC260x onkey as an input device. It can also
be configured to force a system reset on a long key-press with an
adjustable duration.

The currently supported chip variants are ATC2603C and ATC2609A.

Signed-off-by: Cristian Ciocaltea 
---
Changes in v3: 
 - Integrated Dmitry's review:
   * Dropped the logic around the check for 'pdev->dev.of_node'
   * Renamed 'ret' variable in 'atc260x_onkey_probe()' to 'error'
   * Used 'dev_dbg' instead of 'dev_info' on status KEY_RESET_DISABLED
   * Dropped 'input_dev->evbit[0] = BIT_MASK(EV_KEY);'
   * Removed IRQF_TRIGGER_HIGH flag on 'devm_request_threaded_irq()'
   * Implemented open/close to mitigate the racing issue in
 'atc260x_onkey_remove()' which has been dropped now
 - Removed the unnecessary driver compatibles
 - Used 'reset-time-sec' property of the parent device instead of
   'actions,reset-time-sec' of now obsolete and removed 'onkey' DT node

 drivers/input/misc/Kconfig |  11 ++
 drivers/input/misc/Makefile|   2 +-
 drivers/input/misc/atc260x-onkey.c | 305 +
 3 files changed, 317 insertions(+), 1 deletion(-)
 create mode 100644 drivers/input/misc/atc260x-onkey.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 362e8a01980c..9e297ebdea57 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -83,6 +83,17 @@ config INPUT_ARIZONA_HAPTICS
  To compile this driver as a module, choose M here: the
  module will be called arizona-haptics.
 
+config INPUT_ATC260X_ONKEY
+   tristate "Actions Semi ATC260x PMIC ONKEY"
+   depends on MFD_ATC260X
+   help
+ Support the ONKEY of ATC260x PMICs as an input device reporting
+ power button status. ONKEY can be used to wakeup from low power
+ modes and force a reset on long press.
+
+ To compile this driver as a module, choose M here: the
+ module will be called atc260x-onkey.
+
 config INPUT_ATMEL_CAPTOUCH
tristate "Atmel Capacitive Touch Button Driver"
depends on OF || COMPILE_TEST
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index a48e5f2d859d..7f854c6ecefa 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_INPUT_ADXL34X_I2C)   += adxl34x-i2c.o
 obj-$(CONFIG_INPUT_ADXL34X_SPI)+= adxl34x-spi.o
 obj-$(CONFIG_INPUT_APANEL) += apanel.o
 obj-$(CONFIG_INPUT_ARIZONA_HAPTICS)+= arizona-haptics.o
+obj-$(CONFIG_INPUT_ATC260X_ONKEY)  += atc260x-onkey.o
 obj-$(CONFIG_INPUT_ATI_REMOTE2)+= ati_remote2.o
 obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
 obj-$(CONFIG_INPUT_ATMEL_CAPTOUCH) += atmel_captouch.o
@@ -84,4 +85,3 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
 obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
 obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
 obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR)   += ideapad_slidebar.o
-
diff --git a/drivers/input/misc/atc260x-onkey.c 
b/drivers/input/misc/atc260x-onkey.c
new file mode 100644
index ..999aabf9dcbd
--- /dev/null
+++ b/drivers/input/misc/atc260x-onkey.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Onkey driver for Actions Semi ATC260x PMICs.
+ *
+ * Copyright (c) 2020 Cristian Ciocaltea 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* <2s for short press, >2s for long press */
+#define KEY_PRESS_TIME_SEC 2
+
+/* Driver internals */
+enum atc260x_onkey_reset_status {
+   KEY_RESET_HW_DEFAULT,
+   KEY_RESET_DISABLED,
+   KEY_RESET_USER_SEL,
+};
+
+struct atc260x_onkey_params {
+   u32 reg_int_ctl;
+   u32 kdwn_state_bm;
+   u32 long_int_pnd_bm;
+   u32 short_int_pnd_bm;
+   u32 kdwn_int_pnd_bm;
+   u32 press_int_en_bm;
+   u32 kdwn_int_en_bm;
+   u32 press_time_bm;
+   u32 reset_en_bm;
+   u32 reset_time_bm;
+};
+
+struct atc260x_onkey {
+   struct atc260x *atc260x;
+   const struct atc260x_onkey_params *params;
+   struct input_dev *input_dev;
+   struct delayed_work work;
+   int irq;
+};
+
+static const struct atc260x_onkey_params atc2603c_onkey_params = {
+   .reg_int_ctl= ATC2603C_PMU_SYS_CTL2,
+   .long_int_pnd_bm= ATC2603C_PMU_SYS_CTL2_ONOFF_LONG_PRESS,
+   .short_int_pnd_bm   = ATC2603C_PMU_SYS_CTL2_ONOFF_SHORT_PRESS,
+   .kdwn_int_pnd_bm= ATC2603C_PMU_SYS_CTL2_ONOFF_PRESS_PD,
+   .press_int_en_bm= ATC2603C_PMU_SYS_CTL2_ONOFF_INT_EN,
+   .kdwn_int_en_bm = ATC2603C_PMU_SYS_CTL2_ONOFF_PRESS_INT_EN,
+   .kdwn_state_bm  = ATC2603C_PMU_SYS_CTL2_ONOFF_PRESS,
+   .press_time_bm  = ATC2603C_PMU_SYS_CTL2_ONOFF_PRESS_TIME,
+   .reset_en_bm= ATC2603C_PMU_SYS_CTL2_ONOFF_PR

[PATCH v3 5/7] power: reset: Add poweroff driver for ATC260x PMICs

2020-12-05 Thread Cristian Ciocaltea
This driver provides poweroff and reboot support for a system through
the ATC2603C and ATC2609A chip variants of the Actions Semi ATC260x
family of PMICs.

Signed-off-by: Cristian Ciocaltea 
---
Changes in v3:
 - Removed the unnecessary driver compatibles

 drivers/power/reset/Kconfig|   8 +-
 drivers/power/reset/Makefile   |   1 +
 drivers/power/reset/atc260x-poweroff.c | 263 +
 3 files changed, 271 insertions(+), 1 deletion(-)
 create mode 100644 drivers/power/reset/atc260x-poweroff.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index d55b3727e00e..87cc1a4f43b8 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -39,6 +39,13 @@ config POWER_RESET_AT91_SAMA5D2_SHDWC
  This driver supports the alternate shutdown controller for some Atmel
  SAMA5 SoCs. It is present for example on SAMA5D2 SoC.
 
+config POWER_RESET_ATC260X
+   tristate "Actions Semi ATC260x PMIC power-off driver"
+   depends on MFD_ATC260X
+   help
+ This driver provides power-off and restart support for a system
+ through Actions Semi ATC260x series PMICs.
+
 config POWER_RESET_AXXIA
bool "LSI Axxia reset driver"
depends on ARCH_AXXIA
@@ -285,4 +292,3 @@ config NVMEM_REBOOT_MODE
  action according to the mode.
 
 endif
-
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index c51eceba9ea3..829df1157540 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
 obj-$(CONFIG_POWER_RESET_AT91_POWEROFF) += at91-poweroff.o
 obj-$(CONFIG_POWER_RESET_AT91_RESET) += at91-reset.o
 obj-$(CONFIG_POWER_RESET_AT91_SAMA5D2_SHDWC) += at91-sama5d2_shdwc.o
+obj-$(CONFIG_POWER_RESET_ATC260X) += atc260x-poweroff.o
 obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
 obj-$(CONFIG_POWER_RESET_BRCMKONA) += brcm-kona-reset.o
 obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
diff --git a/drivers/power/reset/atc260x-poweroff.c 
b/drivers/power/reset/atc260x-poweroff.c
new file mode 100644
index ..81b050f99302
--- /dev/null
+++ b/drivers/power/reset/atc260x-poweroff.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Poweroff & reset driver for Actions Semi ATC260x PMICs
+ *
+ * Copyright (c) 2020 Cristian Ciocaltea 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct atc260x_pwrc {
+   struct device *dev;
+   struct regmap *regmap;
+   struct notifier_block restart_nb;
+   int (*do_poweroff)(const struct atc260x_pwrc *pwrc, bool restart);
+};
+
+/* Global variable needed only for pm_power_off */
+static struct atc260x_pwrc *atc260x_pwrc_data;
+
+static int atc2603c_do_poweroff(const struct atc260x_pwrc *pwrc, bool restart)
+{
+   int ret, deep_sleep = 0;
+   uint reg_mask, reg_val;
+
+   /* S4-Deep Sleep Mode is NOT available for WALL/USB power */
+   if (!restart && !power_supply_is_system_supplied()) {
+   deep_sleep = 1;
+   dev_info(pwrc->dev, "Enabling S4-Deep Sleep Mode");
+   }
+
+   /* Update wakeup sources */
+   reg_val = ATC2603C_PMU_SYS_CTL0_ONOFF_LONG_WK_EN |
+ (restart ? ATC2603C_PMU_SYS_CTL0_RESET_WK_EN
+  : ATC2603C_PMU_SYS_CTL0_ONOFF_SHORT_WK_EN);
+
+   ret = regmap_update_bits(pwrc->regmap, ATC2603C_PMU_SYS_CTL0,
+ATC2603C_PMU_SYS_CTL0_WK_ALL, reg_val);
+   if (ret)
+   dev_warn(pwrc->dev, "failed to write SYS_CTL0: %d\n", ret);
+
+   /* Update power mode */
+   reg_mask = ATC2603C_PMU_SYS_CTL3_EN_S2 | ATC2603C_PMU_SYS_CTL3_EN_S3;
+
+   ret = regmap_update_bits(pwrc->regmap, ATC2603C_PMU_SYS_CTL3, reg_mask,
+deep_sleep ? 0 : ATC2603C_PMU_SYS_CTL3_EN_S3);
+   if (ret) {
+   dev_err(pwrc->dev, "failed to write SYS_CTL3: %d\n", ret);
+   return ret;
+   }
+
+   /* Trigger poweroff / restart sequence */
+   reg_mask = restart ? ATC2603C_PMU_SYS_CTL0_RESTART_EN
+  : ATC2603C_PMU_SYS_CTL1_EN_S1;
+   reg_val = restart ? ATC2603C_PMU_SYS_CTL0_RESTART_EN : 0;
+
+   ret = regmap_update_bits(pwrc->regmap,
+restart ? ATC2603C_PMU_SYS_CTL0 : 
ATC2603C_PMU_SYS_CTL1,
+reg_mask, reg_val);
+   if (ret) {
+   dev_err(pwrc->dev, "failed to write SYS_CTL%d: %d\n",
+   restart ? 0 : 1, ret);
+   return ret;
+   }
+
+   /* Wait for trigger completion */
+   mdelay(200);
+
+   return 0;
+}
+
+static int atc2609a_do_poweroff(const struct atc260x_pwrc *pwrc, bool restart)
+{
+   int ret, deep_sleep = 0;
+   uint reg_mask, reg_val;
+
+   /* S4-Deep Sleep Mode is NOT available for WALL/USB power */
+   if (!r

[PATCH v3 3/7] mfd: Add MFD driver for ATC260x PMICs

2020-12-05 Thread Cristian Ciocaltea
Add initial support for the Actions Semi ATC260x PMICs. ATC260x series
PMICs integrates Audio Codec, Power management, Clock generation and
GPIO controller blocks.

For the moment this driver only supports Regulator, Poweroff and Onkey
functionalities for the ATC2603C and ATC2609A chip variants.

Since the PMICs can be accessed using both I2C and SPI buses, the
following driver structure has been adopted:

   -> atc260x-core.c (Implements core functionalities)
  /
ATC260x > atc260x-i2c.c (Implements I2C interface)
  \
   -> atc260x-spi.c (Implements SPI interface - TODO)

Co-developed-by: Manivannan Sadhasivam 
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Cristian Ciocaltea 
---
Changes in v3:
 - Fixed the issues reported by Lee's kernel test robot:
   WARNING: modpost: missing MODULE_LICENSE() in drivers/mfd/atc260x-core.o
   >> FATAL: modpost: drivers/mfd/atc260x-i2c: sizeof(struct i2c_device_id)=24 
is
  not a modulo of the size of section 
__mod_i2c___device_table=588.
   >> Fix definition of struct i2c_device_id in mod_devicetable.h
 - Dropped the usage of '.of_compatible' fields in 
{atc2603c,atc2609a}_mfd_cells[]
 - Added 'Co-developed-by' tag in commit message and dropped [cristian: ...] 
line

 drivers/mfd/Kconfig  |  18 ++
 drivers/mfd/Makefile |   3 +
 drivers/mfd/atc260x-core.c   | 290 +
 drivers/mfd/atc260x-i2c.c|  73 +++
 include/linux/mfd/atc260x/atc2603c.h | 281 
 include/linux/mfd/atc260x/atc2609a.h | 308 +++
 include/linux/mfd/atc260x/core.h |  86 
 7 files changed, 1059 insertions(+)
 create mode 100644 drivers/mfd/atc260x-core.c
 create mode 100644 drivers/mfd/atc260x-i2c.c
 create mode 100644 include/linux/mfd/atc260x/atc2603c.h
 create mode 100644 include/linux/mfd/atc260x/atc2609a.h
 create mode 100644 include/linux/mfd/atc260x/core.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8b99a13669bf..5556182af41c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2076,6 +2076,24 @@ config MFD_WCD934X
  This driver provides common support WCD934x audio codec and its
  associated Pin Controller, Soundwire Controller and Audio codec.
 
+config MFD_ATC260X
+   tristate
+   select MFD_CORE
+   select REGMAP
+   select REGMAP_IRQ
+
+config MFD_ATC260X_I2C
+   tristate "Actions Semi ATC260x PMICs with I2C"
+   select MFD_ATC260X
+   select REGMAP_I2C
+   depends on I2C
+   help
+ Support for the Actions Semi ATC260x PMICs controlled via I2C.
+
+ This driver provides common support for accessing the ATC2603C
+ and ATC2609A chip variants, additional drivers must be enabled
+ in order to use the functionality of the device.
+
 config MFD_KHADAS_MCU
tristate "Support for Khadas System control Microcontroller"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 1780019d2474..d10362670ac3 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -267,3 +267,6 @@ obj-$(CONFIG_MFD_KHADAS_MCU)+= khadas-mcu.o
 obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
 obj-$(CONFIG_MFD_SIMPLE_MFD_I2C)   += simple-mfd-i2c.o
 obj-$(CONFIG_MFD_INTEL_M10_BMC)   += intel-m10-bmc.o
+
+obj-$(CONFIG_MFD_ATC260X)  += atc260x-core.o
+obj-$(CONFIG_MFD_ATC260X_I2C)  += atc260x-i2c.o
diff --git a/drivers/mfd/atc260x-core.c b/drivers/mfd/atc260x-core.c
new file mode 100644
index ..fd3a43b4030d
--- /dev/null
+++ b/drivers/mfd/atc260x-core.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Core MFD support for ATC260x PMICs
+ *
+ * Copyright (C) 2019 Manivannan Sadhasivam 
+ * Copyright (C) 2020 Cristian Ciocaltea 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void regmap_lock_mutex(void *__mutex)
+{
+   struct mutex *mutex = __mutex;
+
+   /*
+* Using regmap within an atomic context (e.g. accessing a PMIC when
+* powering system down) is normally allowed only if the regmap type
+* is MMIO and the regcache type is either REGCACHE_NONE or
+* REGCACHE_FLAT. For slow buses like I2C and SPI, the regmap is
+* internally protected by a mutex which is acquired non-atomically.
+*
+* Let's improve this by using a customized locking scheme inspired
+* from I2C atomic transfer. See i2c_in_atomic_xfer_mode() for a
+* starting point.
+*/
+   if (system_state > SYSTEM_RUNNING && irqs_disabled())
+   mutex_trylock(mutex);
+   else
+   mutex_lock(mutex);
+}
+
+static void regmap_unlock_mutex(void *__mutex)
+{
+   struct mutex *mutex = __mutex;
+
+   mutex_unlock(mutex);
+}
+
+static const struct regmap_config atc2603c_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 16,
+ 

[PATCH v3 2/7] dt-bindings: mfd: Add Actions Semi ATC260x PMIC binding

2020-12-05 Thread Cristian Ciocaltea
Add devicetree binding for Actions Semi ATC260x PMICs.

Signed-off-by: Cristian Ciocaltea 
---
Changes in v3 (according to Rob's review):
 - Dropped the 'pwrc' and 'onkey' nodes
 - Used a common 'reset-time-sec' property

 .../bindings/mfd/actions,atc260x.yaml | 181 ++
 1 file changed, 181 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/actions,atc260x.yaml

diff --git a/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml 
b/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml
new file mode 100644
index ..86aab77ba688
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/actions,atc260x.yaml
@@ -0,0 +1,181 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/actions,atc260x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi ATC260x Power Management IC bindings
+
+maintainers:
+  - Manivannan Sadhasivam 
+  - Cristian Ciocaltea 
+
+description: |
+  ATC260x series PMICs integrates Audio Codec, Power Management, RTC, IR
+  and GPIO controller blocks. Currently only the PM related functionalities
+  (i.e. regulators and system power-off/reboot) for the ATC2603C and ATC2609A
+  chip variants are supported.
+  ATC2603C includes 3 programmable DC-DC converters and 9 LDO regulators.
+  ATC2609A includes 5 programmable DC-DC converters and 10 LDO regulators.
+
+allOf:
+  - $ref: ../input/input.yaml
+
+properties:
+  compatible:
+enum:
+  - actions,atc2603c
+  - actions,atc2609a
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  reset-time-sec:
+description: |
+  Duration in seconds which the key should be kept pressed for device
+  to reset automatically. The hardware default is 8. Use 0 to disable
+  this functionality.
+enum: [0, 6, 8, 10, 12]
+
+  regulators:
+type: object
+description: |
+  List of child nodes specifying the regulators, depending on chip variant:
+  * ATC2603C: dcdc[1-3], ldo[1-3,5-8,11], switchldo1
+  * ATC2609A: dcdc[0-4], ldo[0-9]
+
+properties:
+  compatible:
+enum:
+  - actions,atc2603c-regulator
+  - actions,atc2609a-regulator
+
+  switchldo1:
+type: object
+$ref: ../regulator/regulator.yaml
+
+properties:
+  regulator-name: true
+  regulator-boot-on: true
+  regulator-always-on: true
+  regulator-min-microvolt: true
+  regulator-max-microvolt: true
+  regulator-allow-bypass: true
+  regulator-active-discharge: true
+
+additionalProperties: false
+
+patternProperties:
+  "^(dcdc[0-4]|ldo[0-9]|ldo11|switchldo1)-supply$":
+description: ATC260x voltage regulators supplies
+
+  "^(dcdc[0-4]|ldo[0-9]|ldo11)$":
+type: object
+$ref: ../regulator/regulator.yaml
+
+properties:
+  regulator-name: true
+  regulator-boot-on: true
+  regulator-always-on: true
+  regulator-min-microvolt: true
+  regulator-max-microvolt: true
+  regulator-allow-bypass: true
+
+additionalProperties: false
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: actions,atc2603c-regulator
+then:
+  patternProperties:
+"^(dcdc[0,4]|ldo[0,4,9])(-supply)?$": false
+
+"^(ldo|dcdc)":
+  properties:
+regulator-allow-bypass: false
+  - if:
+  properties:
+compatible:
+  contains:
+const: actions,atc2609a-regulator
+then:
+  patternProperties:
+"^(ldo11|switchldo1)(-supply)?$": false
+
+"^(dcdc|ldo[3-9])":
+  properties:
+regulator-allow-bypass: false
+
+required:
+  - compatible
+
+additionalProperties: false
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+examples:
+  - |
+#include 
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+pmic@65 {
+compatible = "actions,atc2603c";
+reg = <0x65>;
+interrupt-parent = <&sirq>;
+interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+
+reset-time-sec = <6>;
+
+regulators {
+compatible = "actions,atc2603c-regulator";
+
+dcdc1-supply = <®_5v0>;
+dcdc3-supply = <®_5v0>;
+ldo5-supply = <®_5v0>;
+switchldo1-supply = <&vcc>;
+
+vdd_cpu: dcdc1 {
+regulator-name = "VDD_CPU";
+regulator-min-microvolt = <70>;
+regulator-max-microvolt = <140>;
+regulator-always-on;
+};
+
+vcc: dcdc3 {
+regulator-name = "VCC";
+   

[PATCH v3 4/7] regulator: Add regulator driver for ATC260x PMICs

2020-12-05 Thread Cristian Ciocaltea
Add support for the DC-DC converters and LDO regulators found in
the ATC2603C and ATC2609A chip variants of the Actions Semi ATC260x
family of PMICs.

Co-developed-by: Manivannan Sadhasivam 
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Cristian Ciocaltea 
---
Changes in v3:
 - Dropped 'last_dcdc_reg_id' from 'atc260x_regulator_data' and, instead,
   provided separate ops for DCDCs and LDOs, as recommended by Mark
 - Removed the unnecessary compatibles, per Mark's review
 - Added 'Co-developed-by' tag in commit message and dropped [cristian: ...] 
line

 drivers/regulator/Kconfig |   8 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/atc260x-regulator.c | 524 ++
 3 files changed, 533 insertions(+)
 create mode 100644 drivers/regulator/atc260x-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 020a00d6696b..50505de6be70 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -170,6 +170,14 @@ config REGULATOR_AS3722
  AS3722 PMIC. This will enable support for all the software
  controllable DCDC/LDO regulators.
 
+config REGULATOR_ATC260X
+   tristate "Actions Semi ATC260x PMIC Regulators"
+   depends on MFD_ATC260X
+   help
+ This driver provides support for the voltage regulators on the
+ ATC260x PMICs. This will enable support for all the software
+ controllable DCDC/LDO regulators.
+
 config REGULATOR_AXP20X
tristate "X-POWERS AXP20X PMIC Regulators"
depends on MFD_AXP20X
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6ebae516258e..673ff5895aae 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_REGULATOR_ARIZONA_LDO1) += arizona-ldo1.o
 obj-$(CONFIG_REGULATOR_ARIZONA_MICSUPP) += arizona-micsupp.o
 obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
 obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
+obj-$(CONFIG_REGULATOR_ATC260X) += atc260x-regulator.o
 obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
 obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
 obj-$(CONFIG_REGULATOR_BD70528) += bd70528-regulator.o
diff --git a/drivers/regulator/atc260x-regulator.c 
b/drivers/regulator/atc260x-regulator.c
new file mode 100644
index ..8bdfc8643886
--- /dev/null
+++ b/drivers/regulator/atc260x-regulator.c
@@ -0,0 +1,524 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Regulator driver for ATC260x PMICs
+//
+// Copyright (C) 2019 Manivannan Sadhasivam 
+// Copyright (C) 2020 Cristian Ciocaltea 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct atc260x_regulator_data {
+   int voltage_time_dcdc;
+   int voltage_time_ldo;
+};
+
+static const struct linear_range atc2603c_dcdc_voltage_ranges[] = {
+   REGULATOR_LINEAR_RANGE(130, 0, 13, 5),
+   REGULATOR_LINEAR_RANGE(195, 14, 15, 10),
+};
+
+static const struct linear_range atc2609a_dcdc_voltage_ranges[] = {
+   REGULATOR_LINEAR_RANGE(60, 0, 127, 6250),
+   REGULATOR_LINEAR_RANGE(140, 128, 232, 25000),
+};
+
+static const struct linear_range atc2609a_ldo_voltage_ranges0[] = {
+   REGULATOR_LINEAR_RANGE(70, 0, 15, 10),
+   REGULATOR_LINEAR_RANGE(210, 16, 28, 10),
+};
+
+static const struct linear_range atc2609a_ldo_voltage_ranges1[] = {
+   REGULATOR_LINEAR_RANGE(85, 0, 15, 10),
+   REGULATOR_LINEAR_RANGE(210, 16, 27, 10),
+};
+
+static const unsigned int atc260x_ldo_voltage_range_sel[] = {
+   0x0, 0x1,
+};
+
+static int atc260x_dcdc_set_voltage_time_sel(struct regulator_dev *rdev,
+unsigned int old_selector,
+unsigned int new_selector)
+{
+   struct atc260x_regulator_data *data = rdev_get_drvdata(rdev);
+
+   if (new_selector > old_selector)
+   return data->voltage_time_dcdc;
+
+   return 0;
+}
+
+static int atc260x_ldo_set_voltage_time_sel(struct regulator_dev *rdev,
+   unsigned int old_selector,
+   unsigned int new_selector)
+{
+   struct atc260x_regulator_data *data = rdev_get_drvdata(rdev);
+
+   if (new_selector > old_selector)
+   return data->voltage_time_ldo;
+
+   return 0;
+}
+
+static const struct regulator_ops atc260x_dcdc_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+   .list_voltage = regulator_list_voltage_linear,
+   .set_voltage_sel = regulator_set_voltage_sel_regmap,
+   .get_voltage_sel = regulator_get_voltage_sel_regmap,
+   .set_voltage_time_sel = atc260x_dcdc_set_voltage_time_sel,
+};
+
+static const struct regulator_ops atc260x_ldo_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = regulator_disa

[PATCH v3 1/7] dt-bindings: input: Add reset-time-sec common property

2020-12-05 Thread Cristian Ciocaltea
Add a new common property 'reset-time-sec' to be used in conjunction
with the devices supporting the key pressed reset feature.

Signed-off-by: Cristian Ciocaltea 
---
Changes in v3:
 - This patch was not present in v2

 Documentation/devicetree/bindings/input/input.yaml | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/input.yaml 
b/Documentation/devicetree/bindings/input/input.yaml
index ab407f266bef..caba93209ae7 100644
--- a/Documentation/devicetree/bindings/input/input.yaml
+++ b/Documentation/devicetree/bindings/input/input.yaml
@@ -34,4 +34,11 @@ properties:
   specify this property.
 $ref: /schemas/types.yaml#/definitions/uint32
 
+  reset-time-sec:
+description:
+  Duration in seconds which the key should be kept pressed for device to
+  reset automatically. Device with key pressed reset feature can specify
+  this property.
+$ref: /schemas/types.yaml#/definitions/uint32
+
 additionalProperties: true
-- 
2.29.2



[PATCH v3 0/7] Add initial support for ATC260x PMICs

2020-12-05 Thread Cristian Ciocaltea
The ATC260x family of PMICs integrates Audio Codec, Power management,
Clock generation and GPIO controller blocks. There are currently 3
variants: ATC2603A, ATC2603C and ATC2609A.

This is re-spin of the v1 patch series submitted some time ago by
Mani, who provided the MFD and regulator drivers for ATC2609A:
https://lore.kernel.org/lkml/20190617155011.15376-1-manivannan.sadhasi...@linaro.org/

Since v2, I added support for ATC2603C, together with some new
functionalities for both chips: power controller and onkey input.
The ATC2603A chip type remains unsupported for the moment.

This has been tested on RoseapplePi, a SBC based on the Action Semi S500
SoC, which integrates the ATC2603C variant of the PMIC.

Note that enabling the ATC260x PMICs on compatible Actions Semi Owl SoC
based boards depends on:

* the Actions Semi SIRQ driver (for PMIC DTS setup), merged in v5.10:
  
https://lore.kernel.org/lkml/cover.1600114378.git.cristian.ciocal...@gmail.com/

* the atomic transfers in Owl I2C driver (for power controller), queued for 
v5.11:
  
https://lore.kernel.org/lkml/cover.1602190168.git.cristian.ciocal...@gmail.com/

Additionally, please note that I have taken the authorship for the MFD
and regulator drivers patches, considering the original code has been
modified to a large extent.

Thanks,
Cristi

Changes in v3:
- Integrated feedback from Mani, Rob, Mark, Sebastian, Dmitry
- Fixed issues reported by Lee's kernel test robot
- Added new patch for 'reset-time-sec' DT binding property
- Rebased patchset on v5.10-rc6

Changes in v2:
- Reworked MFD core & I2C driver
  * Integrated Lee's feedback
  * Added support for using the regmap within atomic contexts
  * Added support for ATC2603C chip variant
  * Reorganized KConfig entries
- Improved regulator driver
  * Added support for ATC2603C variant
  * Used helper macros for more compact specification of regulator_desc items
  * Added more regulator capabilities
- Added power controller driver
  * Provides system poweroff/reboot functionalities
  * Depends on atomic transfers in the Owl I2C driver
- Added onkey driver: exposes the power button as an input device
- Added yaml binding doc
- Rebased patchset on kernel v5.9-rc1

Cristian Ciocaltea (6):
  dt-bindings: input: Add reset-time-sec common property
  dt-bindings: mfd: Add Actions Semi ATC260x PMIC binding
  mfd: Add MFD driver for ATC260x PMICs
  regulator: Add regulator driver for ATC260x PMICs
  power: reset: Add poweroff driver for ATC260x PMICs
  input: atc260x: Add onkey driver for ATC260x PMICs

Manivannan Sadhasivam (1):
  MAINTAINERS: Add entry for ATC260x PMIC

 .../devicetree/bindings/input/input.yaml  |   7 +
 .../bindings/mfd/actions,atc260x.yaml | 181 ++
 MAINTAINERS   |  12 +
 drivers/input/misc/Kconfig|  11 +
 drivers/input/misc/Makefile   |   2 +-
 drivers/input/misc/atc260x-onkey.c| 305 ++
 drivers/mfd/Kconfig   |  18 +
 drivers/mfd/Makefile  |   3 +
 drivers/mfd/atc260x-core.c| 290 ++
 drivers/mfd/atc260x-i2c.c |  73 +++
 drivers/power/reset/Kconfig   |   8 +-
 drivers/power/reset/Makefile  |   1 +
 drivers/power/reset/atc260x-poweroff.c| 263 +
 drivers/regulator/Kconfig |   8 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/atc260x-regulator.c | 524 ++
 include/linux/mfd/atc260x/atc2603c.h  | 281 ++
 include/linux/mfd/atc260x/atc2609a.h  | 308 ++
 include/linux/mfd/atc260x/core.h  |  86 +++
 19 files changed, 2380 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/actions,atc260x.yaml
 create mode 100644 drivers/input/misc/atc260x-onkey.c
 create mode 100644 drivers/mfd/atc260x-core.c
 create mode 100644 drivers/mfd/atc260x-i2c.c
 create mode 100644 drivers/power/reset/atc260x-poweroff.c
 create mode 100644 drivers/regulator/atc260x-regulator.c
 create mode 100644 include/linux/mfd/atc260x/atc2603c.h
 create mode 100644 include/linux/mfd/atc260x/atc2609a.h
 create mode 100644 include/linux/mfd/atc260x/core.h

-- 
2.29.2



Re: [PATCH v4 11/19] sched/core: Make migrate disable and CPU hotplug cooperative

2020-12-05 Thread Qian Cai
On Sat, 2020-12-05 at 18:37 +, Valentin Schneider wrote:
> From there I see:
> 
> [20798.166987][  T650] CPU127 nr_running=2
> [20798.171185][  T650]  p=migration/127
> [20798.175161][  T650]  p=kworker/127:1
> 
> so this might be another workqueue hurdle. This should be prevented by:
> 
>   06249738a41a ("workqueue: Manually break affinity on hotplug")

Well, since it was reproduced on the latest linux-next which has already
included the commit.

> Note that much earlier in your log, you have a softlockup on CPU127:
> 
> [   74.278367][  C127] watchdog: BUG: soft lockup - CPU#127 stuck for 23s!
> [swapper/0:1]

That's something separate. It was there all the time.

https://lore.kernel.org/linux-acpi/20200929183444.25079-1-...@redhat.com/



[tip:master] BUILD SUCCESS 414b3bbad29bf609f6c5a37c6b96e8a371e3e10f

2020-12-05 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  master
branch HEAD: 414b3bbad29bf609f6c5a37c6b96e8a371e3e10f  Merge branch 'core/mm'

elapsed time: 723m

configs tested: 106
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
armshmobile_defconfig
um   x86_64_defconfig
ia64  tiger_defconfig
arm mv78xx0_defconfig
ia64zx1_defconfig
arm lpc18xx_defconfig
powerpc tqm5200_defconfig
mips allyesconfig
shtitan_defconfig
mips tb0226_defconfig
sh kfr2r09-romimage_defconfig
mips   capcella_defconfig
x86_64  defconfig
mips   rbtx49xx_defconfig
arm  ixp4xx_defconfig
mipsbcm63xx_defconfig
nios2allyesconfig
pariscgeneric-64bit_defconfig
powerpc sbc8548_defconfig
powerpc skiroot_defconfig
sh  lboxre2_defconfig
powerpc mpc8272_ads_defconfig
sh espt_defconfig
arm vf610m4_defconfig
armmulti_v5_defconfig
arm nhk8815_defconfig
arm   sama5_defconfig
powerpc mpc8560_ads_defconfig
ia64generic_defconfig
arm   omap1_defconfig
armmini2440_defconfig
s390defconfig
m68kq40_defconfig
mips   jazz_defconfig
sparc64 defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a005-20201205
i386 randconfig-a004-20201205
i386 randconfig-a001-20201205
i386 randconfig-a002-20201205
i386 randconfig-a006-20201205
i386 randconfig-a003-20201205
x86_64   randconfig-a016-20201205
x86_64   randconfig-a012-20201205
x86_64   randconfig-a014-20201205
x86_64   randconfig-a013-20201205
x86_64   randconfig-a015-20201205
x86_64   randconfig-a011-20201205
i386 randconfig-a014-20201205
i386 randconfig-a013-20201205
i386 randconfig-a011-20201205
i386 randconfig-a015-20201205
i386 randconfig-a012-20201205
i386 randconfig-a016-20201205
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   

Re: [PATCH] kasan: fix slab double free when cpu-hotplug

2020-12-05 Thread Andrew Morton
On Sun, 6 Dec 2020 00:17:15 +0800 Kuan-Ying Lee  
wrote:

> On Fri, 2020-12-04 at 17:25 -0800, Andrew Morton wrote:
> > On Fri, 4 Dec 2020 20:01:35 +0800 Kuan-Ying Lee 
> >  wrote:
> > 
> > > > diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
> > > > index d98b516f372f..55783125a767 100644
> > > > --- a/mm/kasan/quarantine.c
> > > > +++ b/mm/kasan/quarantine.c
> > > > @@ -194,7 +194,6 @@ bool quarantine_put(struct kmem_cache *cache, void 
> > > > *object)
> > > >  
> > > > q = this_cpu_ptr(&cpu_quarantine);
> > > > if (q->offline) {
> > > > -   qlink_free(&meta->quarantine_link, cache);
> > > > local_irq_restore(flags);
> > > > return false;
> 
> Hi Andrew,
> 
> Return false will cause slab allocator to free the object.
> Thus, we do not need to qlink_free here to free object twice.
> 
> The return value is introduced from Andrey's patch.
> "kasan: sanitize objects when metadata doesn't fit"
> 
> 
> > > > }
> > > 
> > > Hi Qiang,
> > > 
> > > Thanks for fixing this.
> > > Due to that issue, my commit has been removed by Stephen from
> > > linux-next.
> > > 
> > > 
> > > Hi Stephen, Andrew,
> > > 
> > > Should I directly upload the v4 or Stephen can pick the commit which 
> > > has been removed back to the linux-next.
> > 
> > I took care of it.  Restored the original patch and added this one as a
> > -fix.
> 
> Thanks for taking care of it.
> 
> I think there are some problem in the patch you just restored.
> I saw the restored patch is not based on Andrey's patch and Stephen's
> fix conflict patch.
> 
> But the issue Qiang fixed need to be based on the Andrey's patch and
> Stephen's fix conflict patch.
> "kasan: sanitize objects when metadata doesn't fit"
> "kasan-rename-get_alloc-free_info-fix"
> 
> If the restored patch is not based on that, it may cause some problems
> and conflicts.
> 
> I think I can prepare a patch v4 based on Andrey's patch, fix the
> conflict and include the Qiang's modification.

I'm not sure what you mean here.  When appying this fix, yes, I had to
replace "meta" with "info", of course.

So the combined patch, which I'd like to send to Linus next week is as
below.  Is there something wrong with it?


From: Kuan-Ying Lee 
Subject: kasan: fix object remaining in offline per-cpu quarantine

We hit this issue in our internal test.  When enabling generic kasan, a
kfree()'d object is put into per-cpu quarantine first.  If the cpu goes
offline, object still remains in the per-cpu quarantine.  If we call
kmem_cache_destroy() now, slub will report "Objects remaining" error.

[   74.982625] 
=
[   74.983380] BUG test_module_slab (Not tainted): Objects remaining in 
test_module_slab on __kmem_cache_shutdown()
[   74.984145] 
-
[   74.984145]
[   74.984883] Disabling lock debugging due to kernel taint
[   74.985561] INFO: Slab 0x(ptrval) objects=34 used=1 
fp=0x(ptrval) flags=0x20010200
[   74.986638] CPU: 3 PID: 176 Comm: cat Tainted: GB 
5.10.0-rc1-7-g4525c8781ec0-dirty #10
[   74.987262] Hardware name: linux,dummy-virt (DT)
[   74.987606] Call trace:
[   74.987924]  dump_backtrace+0x0/0x2b0
[   74.988296]  show_stack+0x18/0x68
[   74.988698]  dump_stack+0xfc/0x168
[   74.989030]  slab_err+0xac/0xd4
[   74.989346]  __kmem_cache_shutdown+0x1e4/0x3c8
[   74.989779]  kmem_cache_destroy+0x68/0x130
[   74.990176]  test_version_show+0x84/0xf0
[   74.990679]  module_attr_show+0x40/0x60
[   74.991218]  sysfs_kf_seq_show+0x128/0x1c0
[   74.991656]  kernfs_seq_show+0xa0/0xb8
[   74.992059]  seq_read+0x1f0/0x7e8
[   74.992415]  kernfs_fop_read+0x70/0x338
[   74.993051]  vfs_read+0xe4/0x250
[   74.993498]  ksys_read+0xc8/0x180
[   74.993825]  __arm64_sys_read+0x44/0x58
[   74.994203]  el0_svc_common.constprop.0+0xac/0x228
[   74.994708]  do_el0_svc+0x38/0xa0
[   74.995088]  el0_sync_handler+0x170/0x178
[   74.995497]  el0_sync+0x174/0x180
[   74.996050] INFO: Object 0x(ptrval) @offset=15848
[   74.996752] INFO: Allocated in test_version_show+0x98/0xf0 age=8188 cpu=6 
pid=172
[   75.000802]  stack_trace_save+0x9c/0xd0
[   75.002420]  set_track+0x64/0xf0
[   75.002770]  alloc_debug_processing+0x104/0x1a0
[   75.003171]  ___slab_alloc+0x628/0x648
[   75.004213]  __slab_alloc.isra.0+0x2c/0x58
[   75.004757]  kmem_cache_alloc+0x560/0x588
[   75.005376]  test_version_show+0x98/0xf0
[   75.005756]  module_attr_show+0x40/0x60
[   75.007035]  sysfs_kf_seq_show+0x128/0x1c0
[   75.007433]  kernfs_seq_show+0xa0/0xb8
[   75.007800]  seq_read+0x1f0/0x7e8
[   75.008128]  kernfs_fop_read+0x70/0x338
[   75.008507]  vfs_read+0xe4/0x250
[   75.008990]  ksys_read+0xc8/0x180
[   75.009462]  __arm64_sys_read+0x44/0x58
[   75.010085]  el0_svc_common.constprop.0+0xac/0x228
[   75.011006] kmem_cache_destroy test_module_slab: Slab cache still has ob

Re: [PATCH v2 bpf-next 0/3] bpf: support module BTF in BTF display helpers

2020-12-05 Thread Alan Maguire


On Sat, 5 Dec 2020, Yonghong Song wrote:

> 
> 
> __builtin_btf_type_id() is really only supported in llvm12
> and 64bit return value support is pushed to llvm12 trunk
> a while back. The builtin is introduced in llvm11 but has a
> corner bug, so llvm12 is recommended. So if people use the builtin,
> you can assume 64bit return value. libbpf support is required
> here. So in my opinion, there is no need to do feature detection.
> 
> Andrii has a patch to support 64bit return value for
> __builtin_btf_type_id() and I assume that one should
> be landed before or together with your patch.
> 
> Just for your info. The following is an example you could
> use to determine whether __builtin_btf_type_id()
> supports btf object id at llvm level.
> 
> -bash-4.4$ cat t.c
> int test(int arg) {
>   return __builtin_btf_type_id(arg, 1);
> }
> 
> Compile to generate assembly code with latest llvm12 trunk:
>   clang -target bpf -O2 -S -g -mcpu=v3 t.c
> In the asm code, you should see one line with
>   r0 = 1 ll
> 
> Or you can generate obj code:
>   clang -target bpf -O2 -c -g -mcpu=v3 t.c
> and then you disassemble the obj file
>   llvm-objdump -d --no-show-raw-insn --no-leading-addr t.o
> You should see below in the output
>   r0 = 1 ll
> 
> Use earlier version of llvm12 trunk, the builtin has
> 32bit return value, you will see
>   r0 = 1
> which is a 32bit imm to r0, while "r0 = 1 ll" is
> 64bit imm to r0.
>

Thanks for this Yonghong!  I'm thinking the way I'll tackle it
is to simply verify that the upper 32 bits specifying the
veth module object id are non-zero; if they are zero, we'll skip
the test (I think a skip probably makes sense as not everyone will
have llvm12). Does that seem reasonable?

With the additional few minor changes on top of Andrii's patch,
the use of __builtin_btf_type_id() worked perfectly. Thanks!

Alan


Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-12-05 Thread Andy Lutomirski
On Sat, Dec 5, 2020 at 3:15 PM Nicholas Piggin  wrote:
>
> Excerpts from Andy Lutomirski's message of December 6, 2020 2:11 am:
> >

> If an mm was lazy tlb for a kernel thread and then it becomes unlazy,
> and if switch_mm is serialising but return to user is not, then you
> need a serialising instruction somewhere before return to user. unlazy
> is the logical place to add that, because the lazy tlb mm (i.e.,
> switching to a kernel thread and back without switching mm) is what
> opens the hole.

The issue here is that unlazying on x86 sometimes serializes and
sometimes doesn't.  It's straightforward to add logic to the x86 code
to serialize specifically in the case where membarrier core sync is
registered and unlazying would otherwise not serialize, but trying to
define sensible semantics for this in a call to core code seems
complicated.  (Specifically, the x86 code only sometimes sends IPIs to
lazy CPUs for TLB flushes.  If an IPI is skipped, then unlazying will
flush the TLB, and that operation is serializing.

The whole lazy thing is IMO a red herring for membarrier().  The
membarrier() logic requires that switching *logical* mms
(rq->curr->mm) serializes before user mode if the new mm is registered
for core sync.  AFAICT the only architecture on which this isn't
automatic is x86, and somehow the logic turned into "actually changing
rq->curr->mm serializes, but unlazying only sometimes serializes, so
we need to do an extra serialization step on unlazying operations"
instead of "tell x86 to make sure it always serializes when it
switches logical mms".  The latter is easy to specify and easy to
implement.

>
> How do you mean? exit_lazy_tlb is the opposite, core scheduler notifying
> arch code about when an mm becomes not-lazy, and nothing to do with
> membarrier at all even. It's a convenient hook to do your un-lazying.
> I guess you can do it also checking things in switch_mm and keeping state
> in arch code, I don't think that's necessarily the best place to put it.

I'm confused.  I just re-read your patches, and it looks like you have
arch code calling exit_lazy_tlb().  On x86, if we do a TLB shootdown
IPI to a lazy CPU, the IPI handler will unlazy that CPU (by switching
to init_mm for real), and we have no way to notify the core scheduler
about this, so we don't.  The result is that the core scheduler state
and the x86 state gets out of sync.  If the core scheduler
subsequently switches us back to the mm that it thinks we were still
using lazily them, from the x86 code's perspective, we're not
unlazying -- we're just doing a regular switch from init_mm to some
other mm.  This is why x86's switch_mm_irqs_off() totally ignores its
'prev' argument.

I'm honestly a bit surprised that other architectures don't do the
same thing.  I suppose that some architectures don't use shootdown
IPIs at all, in which case there doesn't seem to be any good reason to
aggressively unlazy.

(Oddly, despite the fact that, since Ivy Bridge, x86 has a "just flush
the TLB" instruction, that instruction is considerably slower than the
old "switch mm and flush" operation.  So the operation "switch to
init_mm" is only ever any slower than "flush and stay lazy" if we get
lucky and unlazy to the same mm before we get a second TLB shootdown
*and* if unlazying to the same mm would not have needed to flush.  I
spend quite a bit of time tuning this stuff and being quite surprised
at the bizarre performance properties of Intel's TLB management
instructions.)

>
> So membarrier code is unchanged (it cares that the serialise is done at
> un-lazy time), core code is simpler (no knowledge of this membarrier
> quirk and it already knows about lazy-tlb so the calls actually improve
> the documentation), and x86 code I would argue becomes nicer (or no real
> difference at worst) because you can move some exit lazy tlb handling to
> that specific call rather than decipher it from switch_mm.

As above, I can't move the exit-lazy handling because the scheduler
doesn't know when I'm unlazying.

>
> >
> > I’m currently trying to document how membarrier actually works, and
> > hopefully this will result in untangling membarrier from mmdrop() and
> > such.
>
> That would be nice.

It's still a work in progress.  I haven't actually convinced myself
that the non-IPI case in membarrier() is correct, nor have I convinced
myself that it's incorrect.

Anyway, I think that my patch is a bit incorrect and I either need a
barrier somewhere (which may already exist) or a store-release to
lazy_mm to make sure that all accesses to the lazy mm are done before
lazy_mm is freed.  On x86, even aside from the fact that all stores
are releases, this isn't needed -- stopping using an mm is itself a
full barrier.  Will this be a performance issue on power?

>
> >
> > A silly part of this is that x86 already has a high quality
> > implementation of most of membarrier(): flush_tlb_mm().  If you flush
> > an mm’s TLB, we carefully propagate the flush to all threads, 

Re: [resend/standalone PATCH v4] Add auxiliary bus support

2020-12-05 Thread Dan Williams
On Sat, Dec 5, 2020 at 4:24 PM David Ahern  wrote:
>
> On 12/2/20 5:54 PM, Dan Williams wrote:
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index 8d7001712062..040be48ce046 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -1,6 +1,9 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  menu "Generic Driver Options"
> >
> > +config AUXILIARY_BUS
> > + bool
> > +
> >  config UEVENT_HELPER
> >   bool "Support for uevent helper"
> >   help
>
> Missing a description and without it does not appear in menuconfig or in
> the config file.
>
> Could use a blurb in the help as well.

It doesn't have a description or help because it is a select-only
symbol, but a comment to that effect and a pointer to the
documentation would help.


[PATCH 2/2] regulator: pf8x00: add support of nxp pf8x00 regulator

2020-12-05 Thread Adrien Grassein
NXP pf8100 and pf8200 are 12-channel
PMIC for high performance applications.

This driver introduces the support of the 12
regulators available on the PMIC.

Imported from Boundary Devices kernel
with some modifications.

This driver was teste using a Boundary Nitrogen 8M Mini
board that features this PMIC.

Signed-off-by: Adrien Grassein 
---
 MAINTAINERS  |   1 +
 drivers/regulator/Kconfig|  12 +
 drivers/regulator/Makefile   |   1 +
 drivers/regulator/pf8x00-regulator.c | 870 +++
 4 files changed, 884 insertions(+)
 create mode 100644 drivers/regulator/pf8x00-regulator.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4e266f1e9a2f..72522a7fd329 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13735,6 +13735,7 @@ M:  Adrien Grassein 
 L: linux-kernel@vger.kernel.org
 S: Maintained
 F: Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
+F: drivers/regulator/pf8x00-regulator.c
 
 PHOENIX RC FLIGHT CONTROLLER ADAPTER
 M: Marcus Folkesson 
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 020a00d6696b..d2aba4b487f4 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -791,6 +791,18 @@ config REGULATOR_PCF50633
 Say Y here to support the voltage regulators and converters
 on PCF50633
 
+config REGULATOR_PF8X00
+   tristate "NXP PF8x00 regulator driver"
+   depends on I2C
+   select REGMAP_I2C
+   help
+Say y here to support the regulators found on the NXP
+PF8100/PF8200 PMIC
+
+Say M here if you want to include support for tte regulators found
+on the NXP PF8100/PF8200 PMIC. The module will be named
+"pf8x00-regulator".
+
 config REGULATOR_PFUZE100
tristate "Freescale PFUZE100/200/3000/3001 regulator driver"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6ebae516258e..a9fb449a0dc8 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PCA9450) += pca9450-regulator.o
+obj-$(CONFIG_REGULATOR_PF8X00) += pf8x00-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
 obj-$(CONFIG_REGULATOR_PV88080) += pv88080-regulator.o
diff --git a/drivers/regulator/pf8x00-regulator.c 
b/drivers/regulator/pf8x00-regulator.c
new file mode 100644
index ..84a1f2ddbf74
--- /dev/null
+++ b/drivers/regulator/pf8x00-regulator.c
@@ -0,0 +1,870 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+// Copyright 2017 NXP
+// Copyright 2019 Boundary Devices
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PF8X00_DEVICEID0x00
+#define PF8X00_REVID   0x01
+#define PF8X00_EMREV   0x02
+#define PF8X00_PROGID  0x03
+
+#define PF8X00_IMS_INT 0x04
+#define PF8X00_IMS_THERM   0x07
+#define PF8X00_SW_MODE_INT 0x0a
+#define PF8X00_SW_MODE_MASK0x0b
+
+#define IMS_INT0
+#define IMS_STATUS 0
+#define IMS_MASK   1
+#define IMS_SENSE  2
+
+#define PF8X00_IMS_SW_ILIM 0x12
+#define PF8X00_IMS_LDO_ILIM0x15
+#define PF8X00_IMS_SW_UV   0x18
+#define PF8X00_IMS_SW_OV   0x1b
+#define PF8X00_IMS_LDO_UV  0x1e
+#define PF8X00_IMS_LDO_OV  0x21
+#define PF8X00_IMS_PWRON   0x24
+#define PF8X00_SYS_INT 0x27
+
+#define PF8X00_HARD_FAULT  0x29
+#define PF8X00_FSOB_FLAGS  0x2a
+#define PF8X00_FSOB_SELECT 0x2b
+#define PF8X00_ABIST_OV1   0x2c
+#define PF8X00_ABIST_OV2   0x2d
+#define PF8X00_ABIST_UV1   0x2e
+#define PF8X00_ABIST_UV2   0x2f
+#define PF8X00_TEST_FLAGS  0x30
+#define PF8X00_ABIST_RUN   0x31
+
+#define PF8X00_RANDOM_GEN  0x33
+#define PF8X00_RANDOM_CHK  0x34
+#define PF8X00_VMONEN1 0x35
+#define PF8X00_VMONEN2 0x36
+#define PF8X00_CTRL1   0x37
+#define PF8X00_CTRL2   0x38
+#define PF8X00_CTRL3   0x39
+#define PF8X00_PWRUP_CTRL  0x3a
+
+#define PF8X00_RESETBMCU   0x3c
+#define PF8X00_PGOOD   0x3d
+#define PF8X00_PWRDN_DLY1  0x3e
+#define PF8X00_PWRDN_DLY2  0x3f
+#define PF8X00_FREQ_CTRL   0x40
+#define PF8X00_COINCELL_CTRL   0x41
+#define PF8X00_PWRON   0x42
+#define PF8X00_WD_CONFIG   0x43
+#define PF8X00_WD_CLEAR0x44
+#define PF8X00_WD_EXPIRE   0x45
+#define PF8X00_WD_COUNTER  0x46
+#define PF8X00_FAULT_COUNTER   0x47
+#define PF8X00_FSAFE_COUNTER   0x48
+#define PF8X00_FAULT_TIMER 0x49

Re: [resend/standalone PATCH v4] Add auxiliary bus support

2020-12-05 Thread David Ahern
On 12/2/20 5:54 PM, Dan Williams wrote:
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 8d7001712062..040be48ce046 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -1,6 +1,9 @@
>  # SPDX-License-Identifier: GPL-2.0
>  menu "Generic Driver Options"
>  
> +config AUXILIARY_BUS
> + bool
> +
>  config UEVENT_HELPER
>   bool "Support for uevent helper"
>   help

Missing a description and without it does not appear in menuconfig or in
the config file.

Could use a blurb in the help as well.


[PATCH 1/2] dt-bindings: regulator: Add pf8x00 regulator

2020-12-05 Thread Adrien Grassein
Add dt-bindings for the pf8x00 driver.

Signed-off-by: Adrien Grassein 
---
 .../regulator/nxp,pf8x00-regulator.yaml   | 223 ++
 MAINTAINERS   |   6 +
 2 files changed, 229 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml

diff --git 
a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
new file mode 100644
index ..f4e4f545c5a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml
@@ -0,0 +1,223 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/nxp,pf8x00-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PF8x00 Power Management Integrated Circuit regulators
+
+maintainers:
+  - Adrien Grassein 
+
+description: |
+  pf8x00 are a 12-chanel regulator PMIC family. Regulators nodes should
+  be named to ldo<>, sw<> and vnss. The definition for each of these nodes
+  is defined using the standard binding for regulators at
+  Documentation/devicetree/bindings/regulator/regulator.txt.
+  Datasheet is available at 
https://www.nxp.com/docs/en/data-sheet/PF8100_PF8200.pdf
+
+properties:
+  compatible:
+enum:
+  - nxp,pf8x00
+
+  reg:
+maxItems: 1
+
+  regulators:
+type: object
+description: |
+  list of regulators provided by this controller
+
+patternProperties:
+  "^ldo[1-4]$":
+type: object
+$ref: regulator.yaml#
+description: |
+  Properties for single LDO regulator.
+
+properties:
+  regulator-name:
+pattern: "^ldo[1-4]$"
+description: |
+  should be ldo1", ..., "ldo4"
+
+  nxp,hw-en:
+$ref: /schemas/types.yaml#definitions/flag
+description: |
+  Only available for ldo2. Used to enable or disable ld02.
+
+  nxp,vselect-en:
+$ref: /schemas/types.yaml#definitions/flag
+description: |
+  Only available for ldo2. When specified, use the VSELECT pin
+  of the chip to control the output voltage of the ldo02 regulator.
+
+unevaluatedProperties: false
+
+  "^sw[1-7]$":
+type: object
+$ref: regulator.yaml#
+description: |
+  Properties for single SW regulator.
+
+properties:
+  regulator-name:
+pattern: "^sw[1-7]$"
+description: |
+  should be sw1", ..., "sw7"
+
+  nxp,ilim-ma:
+$ref: /schemas/types.yaml#definitions/uint32
+minimum: 2100
+maximum: 4500
+default: 2100
+enum: [ 2100, 2600, 3000, 4500 ]
+description: |
+  Defines the maximum current delivered by the regulator (in mA).
+
+  nxp,phase:
+$ref: /schemas/types.yaml#definitions/uint32
+minimum: 0
+maximum: 315
+default: 0
+enum: [ 0, 45, 90, 135, 180, 225, 270, 315 ]
+description: |
+   This controls the phase shift of the switching frequency.
+
+  nxp,fsl,fast-slew:
+$ref: /schemas/types.yaml#definitions/flag
+description: |
+  Controls the DVS ramp of the regulator.
+
+  nxp,quad-phase:
+$ref: /schemas/types.yaml#definitions/flag
+description: |
+  This allow regulators  sw1 and sw2, or sw3 and sw4 or sw4 and sw5
+  to work together to deliver a maximum 10A current.
+
+  nxp,dual-phase:
+$ref: /schemas/types.yaml#definitions/flag
+description: |
+  This allow regulators  sw1, sw2, sw3 and sw4 to work together
+  to deliver a maximum 5A current.
+
+unevaluatedProperties: false
+
+  "^vsnvs$":
+type: object
+$ref: regulator.yaml#
+description: |
+  Properties for vsnvs regulator.
+
+unevaluatedProperties: false
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - regulators
+
+additionalProperties: false
+
+examples:
+  - |
+i2c {
+  #address-cells = <1>;
+  #size-cells = <0>;
+  pmic: pf8100@8 {
+compatible = "nxp,pf8x00";
+reg = <0x08>;
+
+regulators {
+reg_ldo1: ldo1 {
+  regulator-always-on;
+  regulator-boot-on;
+  regulator-max-microvolt = <500>;
+  regulator-min-microvolt = <150>;
+};
+
+reg_ldo2: ldo2 {
+  regulator-always-on;
+  regulator-boot-on;
+  regulator-max-microvolt = <500>;
+  regulator-min-microvolt = <150>;
+};
+
+reg_ldo3: ldo3 {
+  regulator-always-on;
+   

Re: [git pull] Input updates for v5.10-rc6

2020-12-05 Thread pr-tracker-bot
The pull request you sent on Sat, 5 Dec 2020 15:59:36 -0800:

> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7059c2c00a2196865c2139083cbef47cd18109b6

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


Re: sparse annotation for error types?

2020-12-05 Thread Luc Van Oostenryck
On Sat, Dec 05, 2020 at 03:10:15PM -0800, Linus Torvalds wrote:
> On Sat, Dec 5, 2020 at 2:34 PM Jakub Kicinski  wrote:
> >
> > Am I the only one who thinks this would be a good idea?
> 
> err = third_step(obj, 0);
> 
>err_undo_2s:
> second_undo(obj);
>err_undo_1s:
> first_undo(obj);
> return err;
> 
> iow, the "undo" parts are often done even for the success cases. This
> is particularly true when those first steps are locking-related, and
> the code always wants to unlock.
> 
> Sparse also doesn't really do any value analysis, so I suspect it
> wouldn't be trivial to implement in sparse anyway.

Yes but ... (see here under).
 
> Having some kind of smarter compile-time assert could be useful in
> general, but as mentioned, sparse doesn't really do value range
> propagation right now, so..
> 
> Luc, any reactions?

I agree but the code Jakub showed is very constrained:
   * only 2 return points
   * one of them being 0, the other is to be checked.
and I think this should be checkable easily, something like:
   * identify the highest point that can't reach the 'return 0'
   * check that the only way to reach this point is via a zero/non-zero
 test of the 'err' variable/returned value (which is a very
 limited kind of value analysis after all).
But sure, these are rather strict constraints but maybe it's
common for net drivers?

Otherwise, yes, it's probably better to annotate the function itself
or the point of interest (via some kind of assertion) than the
variable.

I've not much idea how much this would be useful, though.

-- Luc


Re: [PATCH v2] x86: Fix x32 System V message queue syscalls

2020-12-05 Thread Jessica Clarke
On 16 Nov 2020, at 00:55, Jessica Clarke  wrote:
> 
> On 1 Nov 2020, at 21:01, Rich Felker  wrote:
>> 
>> On Sun, Nov 01, 2020 at 06:27:10PM +, Jessica Clarke wrote:
>>> On 1 Nov 2020, at 18:15, Jessica Clarke  wrote:
 
 On 1 Nov 2020, at 18:07, Andy Lutomirski  wrote:
> 
> On Sat, Oct 31, 2020 at 6:50 PM Rich Felker  wrote:
>> 
>> On Sun, Nov 01, 2020 at 01:27:35AM +, Jessica Clarke wrote:
>>> On 1 Nov 2020, at 01:22, Rich Felker  wrote:
 On Sat, Oct 31, 2020 at 04:30:44PM -0700, Andy Lutomirski wrote:
> cc: some libc folks
> 
> On Mon, Oct 12, 2020 at 6:45 AM Jessica Clarke  
> wrote:
>> 
>> POSIX specifies that the first field of the supplied msgp, namely 
>> mtype,
>> is a long, not a __kernel_long_t, and it's a user-defined struct due 
>> to
>> the variable-length mtext field so we can't even bend the spec and 
>> make
>> it a __kernel_long_t even if we wanted to. Thus we must use the 
>> compat
>> syscalls on x32 to avoid buffer overreads and overflows in msgsnd and
>> msgrcv respectively.
> 
> This is a mess.
> 
> include/uapi/linux/msg.h has:
> 
> /* message buffer for msgsnd and msgrcv calls */
> struct msgbuf {
>__kernel_long_t mtype;  /* type of message */
>char mtext[1];  /* message text */
> };
> 
> Your test has:
> 
> struct msg_long {
> long mtype;
> char mtext[8];
> };
> 
> struct msg_long_ext {
> struct msg_long msg_long;
> char mext[4];
> };
> 
> and I'm unclear as to exactly what you're trying to do there with the
> "mext" part.
> 
> POSIX says:
> 
>   The application shall ensure that the argument msgp points to  a  
> user-
>   defined  buffer that contains first a field of type long specifying 
> the
>   type of the message, and then a data portion that holds the data  
> bytes
>   of the message. The structure below is an example of what this 
> user-de‐
>   fined buffer might look like:
> 
>   struct mymsg {
>   long   mtype;   /* Message type. */
>   char   mtext[1];/* Message text. */
>   }
> 
> NTP has this delightful piece of code:
> 
> 44 typedef union {
> 45   struct msgbuf msgp;
> 46   struct {
> 47 long mtype;
> 48 int code;
> 49 struct timeval tv;
> 50   } msgb;
> 51 } MsgBuf;
> 
> bluefish has:
> 
> struct small_msgbuf {
> long mtype;
> char mtext[MSQ_QUEUE_SMALL_SIZE];
> } small_msgp;
> 
> 
> My laptop has nothing at all in /dev/mqueue.
> 
> So I don't really know what the right thing to do is.  Certainly if
> we're going to apply this patch, we should also fix the header.  I
> almost think we should *delete* struct msgbuf from the headers, since
> it's all kinds of busted, but that will break the NTP build.  Ideally
> we would go back in time and remove it from the headers.
> 
> Libc people, any insight?  We can probably fix the bug without
> annoying anyone given how lightly x32 is used and how lightly POSIX
> message queues are used.
 
 If it's that outright wrong and always has been, I feel like the old
 syscall numbers should just be deprecated and new ones assigned.
 Otherwise, there's no way for userspace to be safe against data
 corruption when run on older kernels. If there's a new syscall number,
 libc can just use the new one unconditionally (giving ENOSYS on
 kernels where it would be broken) or have a x32-specific
 implementation that makes the old syscall and performs translation if
 the new one fails with ENOSYS.
>>> 
>>> That doesn't really help broken code continue to work reliably, as
>>> upgrading libc will just pull in the new syscall for a binary that's
>>> expecting the broken behaviour, unless you do symbol versioning, but
>>> then it'll just break when you next recompile the code, and there's no
>>> way for that to be diagnosed given the *application* has to define the
>>> type. But given it's application-defined I really struggle to see how
>>> any code out there is actually expecting the current x32 behaviour as
>>> you'd have to go really out of your way to find out that x32 is broken
>>> and needs __kernel_long_t. I don't think there's any way around just
>>> technically breaking ABI whilst likely really fixing ABI in 99.9

[git pull] Input updates for v5.10-rc6

2020-12-05 Thread Dmitry Torokhov
Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. You will get a fix for
"RETRIGEN" handling in Atmel touch controllers that was causing lost
interrupts on systems using edge-triggered interrupts, a quirk for i8042
driver, and a couple more fixes.

Changelog:
-

Dmitry Torokhov (1):
  Input: soc_button_array - add missing include

Linus Walleij (1):
  Input: atmel_mxt_ts - fix lost interrupts

Luo Meng (1):
  Input: i8042 - fix error return code in i8042_setup_aux()

Po-Hsu Lin (1):
  Input: i8042 - add ByteSpeed touchpad to noloop table

Sanjay Govind (1):
  Input: xpad - support Ardwiino Controllers

Diffstat:


 drivers/input/joystick/xpad.c| 2 ++
 drivers/input/misc/soc_button_array.c| 1 +
 drivers/input/serio/i8042-x86ia64io.h| 4 
 drivers/input/serio/i8042.c  | 3 ++-
 drivers/input/touchscreen/atmel_mxt_ts.c | 4 ++--
 5 files changed, 11 insertions(+), 3 deletions(-)

Thanks.


-- 
Dmitry


Re: [PATCH v3 0/7] Improve s0ix flows for systems i219LM

2020-12-05 Thread Jakub Kicinski
On Fri, 4 Dec 2020 14:38:03 -0800 Alexander Duyck wrote:
> > > The patches look good to me. Just need to address the minor issue that
> > > seems to have been present prior to the introduction of this patch
> > > set.
> > >
> > > Reviewed-by: Alexander Duyck   
> >
> > Thanks for your review.  Just some operational questions - since this 
> > previously
> > existed do you want me to re-spin the series to a v4 for this, or should it 
> > be
> > a follow up after the series?
> >
> > If I respin it, would you prefer that change to occur at the start or end
> > of the series?  
> 
> I don't need a respin, but if you are going to fix it you should
> probably put out the patch as something like a 8/7. If you respin it
> should happen near the start of the series as it is a bug you are
> addressing.

Don't we need that patch to be before this series so it can be
back ported easily? Or is it not really a bug?


[PATCH net] bonding: reduce rtnl lock contention in mii monitor thread

2020-12-05 Thread Jarod Wilson
I'm seeing a system get stuck unable to bring a downed interface back up
when it's got an updelay value set, behavior which ceased when logging
spew was removed from bond_miimon_inspect(). I'm monitoring logs on this
system over another network connection, and it seems that the act of
spewing logs at all there increases rtnl lock contention, because
instrumented code showed bond_mii_monitor() never able to succeed in it's
attempts to call rtnl_trylock() to actually commit link state changes,
leaving the downed link stuck in BOND_LINK_DOWN. The system in question
appears to be fine with the log spew being moved to
bond_commit_link_state(), which is called after the successful
rtnl_trylock(). I'm actually wondering if perhaps we ultimately need/want
some bond-specific lock here to prevent racing with bond_close() instead
of using rtnl, but this shift of the output appears to work. I believe
this started happening when de77ecd4ef02 ("bonding: improve link-status
update in mii-monitoring") went in, but I'm not 100% on that.

The addition of a case BOND_LINK_BACK in bond_miimon_inspect() is somewhat
separate from the fix for the actual hang, but it eliminates a constant
"invalid new link 3 on slave" message seen related to this issue, and it's
not actually an invalid state here, so we shouldn't be reporting it as an
error.

CC: Mahesh Bandewar 
CC: Jay Vosburgh 
CC: Veaceslav Falico 
CC: Andy Gospodarek 
CC: "David S. Miller" 
CC: Jakub Kicinski 
CC: Thomas Davis 
CC: net...@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
 drivers/net/bonding/bond_main.c | 26 ++
 include/net/bonding.h   | 38 +
 2 files changed, 44 insertions(+), 20 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 47afc5938c26..cdb6c64f16b6 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2292,23 +2292,13 @@ static int bond_miimon_inspect(struct bonding *bond)
bond_propose_link_state(slave, BOND_LINK_FAIL);
commit++;
slave->delay = bond->params.downdelay;
-   if (slave->delay) {
-   slave_info(bond->dev, slave->dev, "link status 
down for %sinterface, disabling it in %d ms\n",
-  (BOND_MODE(bond) ==
-   BOND_MODE_ACTIVEBACKUP) ?
-   (bond_is_active_slave(slave) ?
-"active " : "backup ") : "",
-  bond->params.downdelay * 
bond->params.miimon);
-   }
+
fallthrough;
case BOND_LINK_FAIL:
if (link_state) {
/* recovered before downdelay expired */
bond_propose_link_state(slave, BOND_LINK_UP);
slave->last_link_up = jiffies;
-   slave_info(bond->dev, slave->dev, "link status 
up again after %d ms\n",
-  (bond->params.downdelay - 
slave->delay) *
-  bond->params.miimon);
commit++;
continue;
}
@@ -2330,19 +2320,10 @@ static int bond_miimon_inspect(struct bonding *bond)
commit++;
slave->delay = bond->params.updelay;
 
-   if (slave->delay) {
-   slave_info(bond->dev, slave->dev, "link status 
up, enabling it in %d ms\n",
-  ignore_updelay ? 0 :
-  bond->params.updelay *
-  bond->params.miimon);
-   }
fallthrough;
case BOND_LINK_BACK:
if (!link_state) {
bond_propose_link_state(slave, BOND_LINK_DOWN);
-   slave_info(bond->dev, slave->dev, "link status 
down again after %d ms\n",
-  (bond->params.updelay - 
slave->delay) *
-  bond->params.miimon);
commit++;
continue;
}
@@ -2456,6 +2437,11 @@ static void bond_miimon_commit(struct bonding *bond)
 
continue;
 
+   case BOND_LINK_BACK:
+   bond_propose_link_state(slave, BOND_LINK_NOCHANGE);
+
+   continue;
+
default:
slave_err(bond->dev, slave->dev, "invalid new link %d 
on slave\n",
  slave->link_new_state);
diff --g

Re: BUG: KCSAN: data-race in tick_nohz_next_event / tick_nohz_stop_tick

2020-12-05 Thread Thomas Gleixner
On Sat, Dec 05 2020 at 19:18, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 20:53, Marco Elver wrote:
> It might be useful to find the actual variable, data member or whatever
> which is involved in the various reports and if there is a match then
> the reports could be aggregated. The 3 patterns here are not even the
> complete possible picture.
>
> So if you sum them up: 58 + 148 + 205 instances then their weight
> becomes more significant as well.

I just looked into the moderation queue and picked stuff which I'm
familiar with from the subject line.

There are quite some reports which have a different trigger scenario,
but are all related to the same issue.

  https://syzkaller.appspot.com/bug?id=f5a5ed5b2b6c3e92bc1a9dadc934c44ee3ba4ec5
  https://syzkaller.appspot.com/bug?id=36fc4ad4cac8b8fc8a40713f38818488faa9e9f4

are just variations of the same problem timer_base->running_timer being
set to NULL without holding the base lock. Safe, but insanely hard to
explain why :)

Next:

  https://syzkaller.appspot.com/bug?id=e613fc2458de1c8a544738baf46286a99e8e7460
  https://syzkaller.appspot.com/bug?id=55bc81ed3b2f620f64fa6209000f40ace4469bc0
  https://syzkaller.appspot.com/bug?id=972894de81731fc8f62b8220e7cd5153d3e0d383
  .

That's just the ones which caught my eye and all are related to
task->flags usage. There are tons more judging from the subject
lines.

So you really want to look at them as classes of problems and not as
individual scenarios.

Thanks,

tglx




[PATCH] Input: gtco - remove driver

2020-12-05 Thread Dmitry Torokhov
The driver has its own HID descriptor parsing code, that had and still
has several issues discovered by syzbot and other tools. Ideally we
should move the driver over to the HID subsystem, so that it uses proven
parsing code.  However the devices in question are EOL, and GTCO is not
willing to extend resources for that, so let's simply remove the driver.

Note that our HID support has greatly improved over the last 10 years,
we may also consider reverting 6f8d9e26e7de ("hid-core.c: Adds all GTCO
CalComp Digitizers and InterWrite School Products to blacklist") and see
if GTCO devices actually work with normal HID drivers.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/tablet/Kconfig  |   12 -
 drivers/input/tablet/Makefile |1 -
 drivers/input/tablet/gtco.c   | 1043 -
 kernel/configs/android-recommended.config |1 -
 4 files changed, 1057 deletions(-)

diff --git a/drivers/input/tablet/Kconfig b/drivers/input/tablet/Kconfig
index 51c339182017..ec27eff6ae37 100644
--- a/drivers/input/tablet/Kconfig
+++ b/drivers/input/tablet/Kconfig
@@ -38,18 +38,6 @@ config TABLET_USB_AIPTEK
  To compile this driver as a module, choose M here: the
  module will be called aiptek.
 
-config TABLET_USB_GTCO
-   tristate "GTCO CalComp/InterWrite USB Support"
-   depends on USB && INPUT
-   help
- Say Y here if you want to use the USB version of the GTCO
- CalComp/InterWrite Tablet.  Make sure to say Y to "Mouse support"
- (CONFIG_INPUT_MOUSEDEV) and/or "Event interface support"
- (CONFIG_INPUT_EVDEV) as well.
-
- To compile this driver as a module, choose M here: the
- module will be called gtco.
-
 config TABLET_USB_HANWANG
tristate "Hanwang Art Master III tablet support (USB)"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/input/tablet/Makefile b/drivers/input/tablet/Makefile
index 8279ccc18b0a..adb636430717 100644
--- a/drivers/input/tablet/Makefile
+++ b/drivers/input/tablet/Makefile
@@ -6,7 +6,6 @@
 
 obj-$(CONFIG_TABLET_USB_ACECAD)+= acecad.o
 obj-$(CONFIG_TABLET_USB_AIPTEK)+= aiptek.o
-obj-$(CONFIG_TABLET_USB_GTCO)  += gtco.o
 obj-$(CONFIG_TABLET_USB_HANWANG) += hanwang.o
 obj-$(CONFIG_TABLET_USB_KBTAB) += kbtab.o
 obj-$(CONFIG_TABLET_USB_PEGASUS) += pegasus_notetaker.o
diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
deleted file mode 100644
index 44bb1f69b4b2..
--- a/drivers/input/tablet/gtco.c
+++ /dev/null
@@ -1,1043 +0,0 @@
-/*-*- linux-c -*-
-
-GTCO digitizer USB driver
-
-TO CHECK:  Is pressure done right on report 5?
-
-Copyright (C) 2006  GTCO CalComp
-
-This program is free software; you can redistribute it and/or
-modify it under the terms of the GNU General Public License
-as published by the Free Software Foundation; version 2
-of the License.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
-
-Permission to use, copy, modify, distribute, and sell this software and its
-documentation for any purpose is hereby granted without fee, provided that
-the above copyright notice appear in all copies and that both that
-copyright notice and this permission notice appear in supporting
-documentation, and that the name of GTCO-CalComp not be used in advertising
-or publicity pertaining to distribution of the software without specific,
-written prior permission. GTCO-CalComp makes no representations about the
-suitability of this software for any purpose.  It is provided "as is"
-without express or implied warranty.
-
-GTCO-CALCOMP DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
-INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
-EVENT SHALL GTCO-CALCOMP BE LIABLE FOR ANY SPECIAL, INDIRECT OR
-CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
-DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
-TORTIOUS ACTIONS, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-PERFORMANCE OF THIS SOFTWARE.
-
-GTCO CalComp, Inc.
-7125 Riverwood Drive
-Columbia, MD 21046
-
-Jeremy Roberson jrober...@gtcocalcomp.com
-Scott Hill sh...@gtcocalcomp.com
-*/
-
-
-
-/*#define DEBUG*/
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-/* Version with a Major number of 2 is for kernel inclusion only. */
-#define  GTCO_VERSION   "2.00.0006"
-
-
-/*   MACROS  */
-
-#define VENDOR_ID_GTCO   0x078C
-#define PID_400   0x400
-#define PID_401   0x401
-#define PID_1000  

Re: [PULL REQUEST] i2c for 5.10

2020-12-05 Thread pr-tracker-bot
The pull request you sent on Sat, 5 Dec 2020 23:11:43 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/33256ce194110874d4bc90078b577c59f9076c59

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


Re: [PATCH v5 0/9] "Task_isolation" mode

2020-12-05 Thread Thomas Gleixner
Pavel,

On Sat, Dec 05 2020 at 21:40, Pavel Machek wrote:
> So... what kind of guarantees does this aim to provide / what tasks it
> is useful for?
>
> For real time response, we have other approaches.

Depends on your requirements. Some problems are actually better solved
with busy polling. See below.

> If you want to guarantee performnace of the "isolated" task... I don't
> see how that works. Other tasks on the system still compete for DRAM
> bandwidth, caches, etc...

Applications which want to run as undisturbed as possible. There is
quite a range of those:

  - Hardware in the loop simulation is today often done with that crude
approach of "offlining" a CPU and then instead of playing dead
jumping to a preloaded bare metal executable. That's a horrible hack
and impossible to debug, but gives them the results they need to
achieve. These applications are well optimized vs. cache and memory
foot print, so they don't worry about these things too much and they
surely don't run on SMI and BIOS value add inflicted machines.

Don't even think about waiting for an interrupt to achieve what
these folks are doing. So no, there are problems which a general
purpose realtime OS cannot solve ever.

  - HPC computations on large data sets. While the memory foot print is
large the access patterns are cache optimized. 

The problem there is that any unnecessary IPI, tick interrupt or
whatever nuisance is disturbing the carefully optimized cache usage
and alone getting rid of the timer interrupt gained them measurable
performance. Even very low single digit percentage of runtime saving
is valuable for these folks because the compute time on such beasts
is expensive.

  - Realtime guests in KVM. With posted interrupts and a fully populated
host side page table there is no point in running host side
interrupts or IPIs for random accounting or whatever purposes as
they affect the latency in the guest. With all the side effects
mitigated and a properly set up guest and host it is possible to get
to a zero exit situation after the bootup phase which means pretty
much matching bare metal behaviour.

Yes, you can do that with e.g. Jailhouse as well, but you lose lots
of the fancy things KVM provides. And people care about these not
just because they are fancy. They care because their application
scenario needs them.

There are more reasons why people want to be able to get as much
isolation from the OS as possible but at the same time have a sane
execution environment, debugging, performance monitoring and the OS
provided protection mechanisms instead of horrible hacks.

Isolation makes sense for a range of applications and there is no reason
why Linux should not support them. 

Thanks,

tglx


Re: [PATCH] ch_ktls: fix build warning for ipv4-only config

2020-12-05 Thread Jakub Kicinski
On Sun, 6 Dec 2020 00:18:44 +0100 Arnd Bergmann wrote:
> > This is for evrey clang build or just W=1+? Would be annoying if clang
> > produced this on every build with 5.10 (we need to decide fix vs -next).  
> 
> The -Wsometimes-uninitialized is enabled unconditionally for clang,
> but this only happens for IPv4-only configurations with IPv6 disabled,
> so most real configurations should not observe it, but the fix should still
> go into v5.10.

Great, I guessed correctly :)


Re: [PATCH] net: fix spelling mistake "wil" -> "will" in Kconfig

2020-12-05 Thread patchwork-bot+netdevbpf
Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Fri,  4 Dec 2020 19:45:49 + you wrote:
> From: Colin Ian King 
> 
> There is a spelling mistake in the Kconfig help text. Fix it.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/net/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Here is the summary with links:
  - net: fix spelling mistake "wil" -> "will" in Kconfig
https://git.kernel.org/netdev/net-next/c/00649542f1ba

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




Re: [PATCH] ch_ktls: fix build warning for ipv4-only config

2020-12-05 Thread Arnd Bergmann
On Sat, Dec 5, 2020 at 2:57 AM Jakub Kicinski  wrote:
>
> On Thu,  3 Dec 2020 23:26:16 +0100 Arnd Bergmann wrote:
> > From: Arnd Bergmann 
> >
> > When CONFIG_IPV6 is disabled, clang complains that a variable
> > is uninitialized for non-IPv4 data:
> >
> > drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c:1046:6: 
> > error: variable 'cntrl1' is used uninitialized whenever 'if' condition is 
> > false [-Werror,-Wsometimes-uninitialized]
> > if (tx_info->ip_family == AF_INET) {
> > ^
> > drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c:1059:2: 
> > note: uninitialized use occurs here
> > cntrl1 |= T6_TXPKT_ETHHDR_LEN_V(maclen - ETH_HLEN) |
> > ^~
> >
> > Replace the preprocessor conditional with the corresponding C version,
> > and make the ipv4 case unconditional in this configuration to improve
> > readability and avoid the warning.
> >
> > Fixes: 86716b51d14f ("ch_ktls: Update cheksum information")
> > Signed-off-by: Arnd Bergmann 
>
> This is for evrey clang build or just W=1+? Would be annoying if clang
> produced this on every build with 5.10 (we need to decide fix vs -next).

The -Wsometimes-uninitialized is enabled unconditionally for clang,
but this only happens for IPv4-only configurations with IPv6 disabled,
so most real configurations should not observe it, but the fix should still
go into v5.10.

  Arnd


[PATCH] rtc: fix RTC removal

2020-12-05 Thread Alexandre Belloni
Since the rtc_register_device, removing an RTC device will end with a
refcount_t: underflow; use-after-free warning since put_device is called
twice in the device tear down path.

Fixes: fdcfd854333b ("rtc: rework rtc_register_device() resource management")
Signed-off-by: Alexandre Belloni 
---
 drivers/rtc/class.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/rtc/class.c b/drivers/rtc/class.c
index e6b44b7c4ad3..5c6748dfa55d 100644
--- a/drivers/rtc/class.c
+++ b/drivers/rtc/class.c
@@ -335,7 +335,6 @@ static void devm_rtc_unregister_device(void *data)
cdev_device_del(&rtc->char_dev, &rtc->dev);
rtc->ops = NULL;
mutex_unlock(&rtc->ops_lock);
-   put_device(&rtc->dev);
 }
 
 static void devm_rtc_release_device(void *res)
-- 
2.28.0



Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-12-05 Thread Nicholas Piggin
Excerpts from Andy Lutomirski's message of December 6, 2020 2:11 am:
> 
>> On Dec 5, 2020, at 12:00 AM, Nicholas Piggin  wrote:
>> 
>> 
>> I disagree. Until now nobody following it noticed that the mm gets
>> un-lazied in other cases, because that was not too clear from the
>> code (only indirectly using non-standard terminology in the arch
>> support document).
> 
>> In other words, membarrier needs a special sync to deal with the case 
>> when a kthread takes the mm.
> 
> I don’t think this is actually true. Somehow the x86 oddities about 
> CR3 writes leaked too much into the membarrier core code and comments. 
> (I doubt this is x86 specific.  The actual x86 specific part seems to 
> be that we can return to user mode without syncing the instruction 
> stream.)
> 
> As far as I can tell, membarrier doesn’t care at all about laziness. 
> Membarrier cares about rq->curr->mm.  The fact that a cpu can switch 
> its actual loaded mm without scheduling at all (on x86 at least) is 
> entirely beside the point except insofar as it has an effect on 
> whether a subsequent switch_mm() call serializes.

Core membarrier itself doesn't care about laziness, which is why the
membarrier flush should go in exit_lazy_tlb() or other x86 specific
code (at least until more architectures did the same thing and we moved
it into generic code). I just meant this non-serialising return as 
documented in the membarrier arch enablement doc specifies the lazy tlb
requirement.

If an mm was lazy tlb for a kernel thread and then it becomes unlazy,
and if switch_mm is serialising but return to user is not, then you
need a serialising instruction somewhere before return to user. unlazy
is the logical place to add that, because the lazy tlb mm (i.e., 
switching to a kernel thread and back without switching mm) is what 
opens the hole.

> If we notify 
> membarrier about x86’s asynchronous CR3 writes, then membarrier needs 
> to understand what to do with them, which results in an unmaintainable 
> mess in membarrier *and* in the x86 code.

How do you mean? exit_lazy_tlb is the opposite, core scheduler notifying
arch code about when an mm becomes not-lazy, and nothing to do with
membarrier at all even. It's a convenient hook to do your un-lazying.
I guess you can do it also checking things in switch_mm and keeping state
in arch code, I don't think that's necessarily the best place to put it.

So membarrier code is unchanged (it cares that the serialise is done at
un-lazy time), core code is simpler (no knowledge of this membarrier 
quirk and it already knows about lazy-tlb so the calls actually improve 
the documentation), and x86 code I would argue becomes nicer (or no real
difference at worst) because you can move some exit lazy tlb handling to
that specific call rather than decipher it from switch_mm.

> 
> I’m currently trying to document how membarrier actually works, and 
> hopefully this will result in untangling membarrier from mmdrop() and 
> such.

That would be nice.

> 
> A silly part of this is that x86 already has a high quality 
> implementation of most of membarrier(): flush_tlb_mm().  If you flush 
> an mm’s TLB, we carefully propagate the flush to all threads, with 
> attention to memory ordering.  We can’t use this directly as an 
> arch-specific implementation of membarrier because it has the annoying 
> side affect of flushing the TLB and because upcoming hardware might be 
> able to flush without guaranteeing a core sync.  (Upcoming means Zen 
> 3, but the Zen 3 implementation is sadly not usable by Linux.)
> 

A hardware broadcast TLB flush, you mean? What makes it unusable by 
Linux out of curiosity?


Re: sparse annotation for error types?

2020-12-05 Thread Linus Torvalds
On Sat, Dec 5, 2020 at 2:34 PM Jakub Kicinski  wrote:
>
> Am I the only one who thinks this would be a good idea?

I don't think it's likely to be very useful, because a very common
pattern is to not have that separate "return 0" in the middle, but
more along the lines of

err = first_step(obj, 1);
if (err)
return err;

if (some_check(obj)) {
err = -EINVAL; /* need explicit error set! */
goto err_undo_1s;
}

err = second_step(obj, param);
if (err)
goto err_undo_1s;

err = third_step(obj, 0);

   err_undo_2s:
second_undo(obj);
   err_undo_1s:
first_undo(obj);
return err;

iow, the "undo" parts are often done even for the success cases. This
is particularly true when those first steps are locking-related, and
the code always wants to unlock.

Sparse also doesn't really do any value analysis, so I suspect it
wouldn't be trivial to implement in sparse anyway.

Syntactically, I also think it's wrong to annotate the variable - I
think the place to annotate would be the return statement, and say
"must be negative" there. Kind of similar to having function arguments
annotated as "must not be NULL" (which sparse also doesn't do, but
some other checking tools do, and sparse can at least _parse_
"__nonnull" even if it ends up being ignored).

It's a bit similar to gcc's has a "returns_nonnull" function
attribute, but that one is not "per return", it's a global "this
function cannot return NULL" thing so that callers can then be
optimized and NULL checks removed. So it's very similar to the
"argument is non-null" in that it's for warnings at the *caller*, not
the function itself.

So if we want sparse support for this, I'd suggest something more akin
to a smarter compile-time assert, IOW more like having a

compile_time_assert(err < 0);
return err;

and then sparse (or any other checker) could warn when there's a path
that results in "err" not being negative.

Having some kind of smarter compile-time assert could be useful in
general, but as mentioned, sparse doesn't really do value range
propagation right now, so..

Luc, any reactions?

  Linus


Re: [RFC PATCH v1 07/12] efi: Replace strstarts() by str_has_prefix().

2020-12-05 Thread James Bottomley
On Sat, 2020-12-05 at 22:20 +0100, Ard Biesheuvel wrote:
> On Sat, 5 Dec 2020 at 22:15, James Bottomley
>  wrote:
> > [Rostedt added because this is all his fault]
> > On Sat, 2020-12-05 at 21:57 +0100, Ard Biesheuvel wrote:
> > > On Sat, 5 Dec 2020 at 21:24, James Bottomley
> > >  wrote:
> > [...]
> > > > > So I don't object to using str_has_prefix() in new code in
> > > > > this way, but I really don't see the point of touching
> > > > > existing code.
> > > > 
> > > > That's your prerogative as a Maintainer ... I was just
> > > > explaining what the original author had in mind when
> > > > str_has_prefix() was created.
> > > > 
> > > 
> > > Sure, I fully understand you are not the one proposing these
> > > changes.
> > > 
> > > But if the pattern in question is so common, couldn't we go one
> > > step further and define something like
> > > 
> > > static inline const u8 *skip_prefix_or_null(const u8 *str, const
> > > u8 *prefix)
> > > {
> > > }
> > > 
> > > which returns a pointer into the original string, or NULL if the
> > > prefix is not present.
> > > 
> > > The current patch as proposed has no benefit whatsoever, but even
> > > the meaningful alternative you are proposing is not actually an
> > > improvement, given that it is not self-explanatory from the name
> > > 'str_has_prefix' what it returns, and so the code becomes more
> > > difficult to understand.
> > 
> > Ah, so this is the kernel maintainer's syndrome: you see an API
> > which isn't quite right for your use case, so you update or change
> > it.  Then you see other use cases for it and suddenly to you it
> > becomes the best thing since sliced bread and with a one ring to
> > rule them all mentality you exhort everyone to use this new API
> > everywhere.  See this comment in the merge commit (495d714ad1400)
> > which comes from the merge cover letter:
> > 
> > > - Addition of str_has_prefix() and a few use cases. There
> > >   currently is a similar function strstart() that is used in
> > > a
> > >   few places, but only returns a bool and not a length. These
> > >   instances will be removed in the future to use
> > >   str_has_prefix() instead.
> > 
> > Then you forget about it until someone else acts on your somewhat
> > ill considered instruction and actually tries the
> > replacement.  Once someone takes up your cause, the API shows up in
> > dozens of emails and the actual debate about whether or not this is
> > such a good API really begins, with the poor person who picked it
> > up caught in the crossfire.
> > 
> > As maintainers we really should learn to put the cart before the 

s/to put/not to put/

> > horse.
> > 
> 
> I am not disagreeing with any of this, but I simply don't see a point
> in merging patches that apparently result in the exact same machine
> code to be generated, and don't substantially make the code itself
> any better.


Well, I think the pattern

if (strstarts(option, )) {
   ...
   option += strlen();

is a bad one because one day  may get updated but not .  And if  is too far away in the code it might not
even show up in the diff, leading to reviewers not noticing either.  So
I think eliminating the pattern is a definite improvement.

Now whether the improvement is enough that we should churn the code
base to fix it is another question.

James




Re: [PATCH v6 4/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC

2020-12-05 Thread Linus Walleij
On Thu, Dec 3, 2020 at 8:10 AM Zulkifli, Muhammad Husaini
 wrote:

> >Yeah it has to be called from somewhere, if you want an abstraction to make
> >the driver neutral to any machine, then use a selector regulator. It can be
> >placed anywhere in the kernel as long as you can reference it.
>
> Sorry. I am not really aware of selector regulator. Can you point me to any 
> references
> for this?

It is part of the regulator subsystem and the standard framework
there to handle regulators with an enumerable number of
specific voltage levels.

> IMHO, we do not need to overengineered it to add custom selector
> regulator just to suit this Keem Bay HW design.

That can be said about a lot of things we model with vqmmc.
Using standard abstractions makes things easier for maintainers.
We mostly design abstractions for maintenance not for the simplest way
to set bits in registers.

Yours,
Linus Walleij


Re: [PATCH] [v2] enetc: fix build warning

2020-12-05 Thread patchwork-bot+netdevbpf
Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Fri,  4 Dec 2020 20:28:59 +0100 you wrote:
> From: Arnd Bergmann 
> 
> When CONFIG_OF is disabled, there is a harmless warning about
> an unused variable:
> 
> enetc_pf.c: In function 'enetc_phylink_create':
> enetc_pf.c:981:17: error: unused variable 'dev' [-Werror=unused-variable]
> 
> [...]

Here is the summary with links:
  - [v2] enetc: fix build warning
https://git.kernel.org/netdev/net-next/c/4560b2a3ecdd

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




Re: [PATCH] octeontx2-pf: Add RSS multi group support

2020-12-05 Thread Jakub Kicinski
On Fri,  4 Dec 2020 14:54:51 +0530 Geetha sowjanya wrote:
> Hardware supports 8 RSS groups per interface. Currently we are using
> only group '0'. This patch allows user to create new RSS groups/contexts
> and use the same as destination for flow steering rules.
> 
> usage:
> To steer the traffic to RQ 2,3
> 
> ethtool -X eth0 weight 0 0 1 1 context new
> (It will print the allocated context id number)
> New RSS context is 1
> 
> ethtool -N eth0 flow-type tcp4 dst-port 80 context 1 loc 1
> 
> To delete the context
> ethtool -X eth0 context 1 delete
> 
> When an RSS context is removed, the active classification
> rules using this context are also removed.
> 
> Signed-off-by: Sunil Kovvuri Goutham 
> Signed-off-by: Geetha sowjanya 

Looks good, minor coding nits below.

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c 
> b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> index 73fb94d..0c84dcf 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
> @@ -270,14 +270,17 @@ int otx2_set_flowkey_cfg(struct otx2_nic *pfvf)
>   return err;
>  }
>  
> -int otx2_set_rss_table(struct otx2_nic *pfvf)
> +int otx2_set_rss_table(struct otx2_nic *pfvf, int ctx_id)
>  {
>   struct otx2_rss_info *rss = &pfvf->hw.rss_info;
> + int index = rss->rss_size * ctx_id;

const?

>   struct mbox *mbox = &pfvf->mbox;
> + struct otx2_rss_ctx *rss_ctx;
>   struct nix_aq_enq_req *aq;
>   int idx, err;
>  
>   mutex_lock(&mbox->lock);
> + rss_ctx = rss->rss_ctx[ctx_id];
>   /* Get memory to put this msg */
>   for (idx = 0; idx < rss->rss_size; idx++) {
>   aq = otx2_mbox_alloc_msg_nix_aq_enq(mbox);

> +/* RSS context configuration */
> +static int otx2_set_rxfh_context(struct net_device *dev, const u32 *indir,
> +  const u8 *hkey, const u8 hfunc,
> +  u32 *rss_context, bool delete)
> +{
>   struct otx2_nic *pfvf = netdev_priv(dev);
> + struct otx2_rss_ctx *rss_ctx;
> + struct otx2_rss_info *rss;
> + int ret, idx;
> +
> + if (hfunc != ETH_RSS_HASH_NO_CHANGE && hfunc != ETH_RSS_HASH_TOP)
> + return -EOPNOTSUPP;
> +
> + rss = &pfvf->hw.rss_info;
>  
> - return pfvf->hw.rss_info.rss_size;
> + if (!rss->enable) {
> + netdev_err(dev, "RSS is disabled, cannot change settings\n");
> + return -EIO;
> + }
> +
> + if (hkey) {
> + memcpy(rss->key, hkey, sizeof(rss->key));
> + otx2_set_rss_key(pfvf);
> + }
> + if (delete)
> + return otx2_rss_ctx_delete(pfvf, *rss_context);
> +
> + if (*rss_context == ETH_RXFH_CONTEXT_ALLOC) {
> + ret = otx2_rss_ctx_create(pfvf, rss_context);
> + if (ret)
> + return ret;
> + }
> + if (indir) {
> + rss_ctx = rss->rss_ctx[*rss_context];
> + for (idx = 0; idx < rss->rss_size; idx++)
> + rss_ctx->ind_tbl[idx] = indir[idx];
> + }
> + otx2_set_rss_table(pfvf, *rss_context);
> +
> + return 0;
> +}
> +
> +static int otx2_get_rxfh_context(struct net_device *dev, u32 *indir,
> +  u8 *hkey, u8 *hfunc, u32 rss_context)
> +{
> + struct otx2_nic *pfvf = netdev_priv(dev);
> + struct otx2_rss_ctx *rss_ctx;
> + struct otx2_rss_info *rss;
> + int idx;
> +
> + rss = &pfvf->hw.rss_info;
> +
> + if (!rss->enable) {
> + netdev_err(dev, "RSS is disabled\n");
> + return -EIO;
> + }
> + if (rss_context >= MAX_RSS_GROUPS)
> + return -EINVAL;
> +
> + rss_ctx = rss->rss_ctx[rss_context];
> + if (!rss_ctx)
> + return -EINVAL;
> +
> + if (indir) {
> + for (idx = 0; idx < rss->rss_size; idx++)
> + indir[idx] = rss_ctx->ind_tbl[idx];
> + }
> + if (hkey)
> + memcpy(hkey, rss->key, sizeof(rss->key));
> +
> + if (hfunc)
> + *hfunc = ETH_RSS_HASH_TOP;
> +
> + return 0;
>  }

Can the old callbacks not be converted to something like:

static int otx2_get_rxfh(...)
{
return otx2_get_rxfh_context(..., DEFAULT_RSS_CONTEXT_GROUP);
}

?

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c 
> b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c
> index be8ccfc..e5f6b4a 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c
> @@ -17,6 +17,7 @@ struct otx2_flow {
>   u16 entry;
>   bool is_vf;
>   int vf;
> + u8 rss_ctx_id;

If you put it next to the bool it will make the structure smaller (less
padding).

>  };
>  
>  int otx2_alloc_mcam_entries(struct otx2_nic *pfvf)

> @@ -521,7 +523,6 @@ static int otx2_add_flow_msg(struct otx2_nic *pfvf, 
> struct otx2_flow *flow)
>   mutex_unlock(&

Re: [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller

2020-12-05 Thread Linus Walleij
On Wed, Dec 2, 2020 at 4:52 PM Maxime Ripard  wrote:

> There's a bunch of issues with wrapped lines alignment reported by
> checkpatch --patch.
>
> Once fixed,
> Acked-by: Maxime Ripard 

Andre, if you resend just the two pinctrl patches with the collected
ACKs I can apply them.

No DT binding changes needed?

Yours,
Linus Walleij


Re: [RESEND PATCH v6 2/2] pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver

2020-12-05 Thread Linus Walleij
On Wed, Dec 2, 2020 at 5:35 PM Srinivas Kandagatla
 wrote:

> Add initial pinctrl driver to support pin configuration for
> LPASS (Low Power Audio SubSystem) LPI (Low Power Island) pinctrl
> on SM8250.

Patch applied!

> +config PINCTRL_LPASS_LPI
> +   tristate "Qualcomm Technologies Inc LPASS LPI pin controller driver"
> +   depends on GPIOLIB

I added:

select PINMUX
select PINCONF
select GENERIC_PINCONF

When applying. You need these I think, your code is working because
other drivers are selecting these for you, right? The build robot would
hack this to pieces though.

Yours,
Linus Walleij


Re: [PATCH net] net: marvell: prestera: Fix error return code in prestera_port_create()

2020-12-05 Thread Jakub Kicinski
On Fri, 4 Dec 2020 16:49:42 +0800 Zhang Changzhong wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> 
> Fixes: 501ef3066c89 ("net: marvell: prestera: Add driver for Prestera family 
> ASIC devices")
> Reported-by: Hulk Robot 
> Signed-off-by: Zhang Changzhong 

Applied, thanks!


sparse annotation for error types?

2020-12-05 Thread Jakub Kicinski
Hi!

Recently we've been getting a steady stream of patches from Changzhong
to fix missing assignment to error variables before jumping to error
cases.

I wonder if for new code it'd make sense to add an annotation for a type
which has to be returned non-zero?

What I have in mind is the following common flow:

int do_a_thing(struct my_obj *obj, int param)
{
int err;

err = first_step(obj, 1);
if (err)
return err;

if (some_check(obj)) {
err = -EINVAL; /* need explicit error set! */
goto err_undo_1s;
}

err = second_step(obj, param);
if (err)
goto err_undo_1s;

err = third_step(obj, 0);
if (err)
goto err_undo_2s;

return 0;

err_undo_2s:
second_undo(obj);
err_undo_1s:
first_undo(obj);
return err;
}


The variable err should never be returned when it's equal to 0.
So if we annotate it, let's say as:

int __nzret err;

could sparse then warn if we forgot to assign it after
"if (some_check(obj))"? 

Am I the only one who thinks this would be a good idea?


  1   2   3   4   5   >