Re: [PATCH] irqchip/gic-v3-its: Fix misplaced __iomem annotations

[Marc Zyngier]

On 16/02/18 16:57, Robin Murphy wrote:
> Save 26 lines worth of Sparse complaints by fixing up this minor
> mishap. The pointee lies in the __iomem space; the pointer does not.
> 
> Signed-off-by: Robin Murphy 
> ---
>  drivers/irqchip/irq-gic-v3-its.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
> b/drivers/irqchip/irq-gic-v3-its.c
> index 06f025fd5726..3a38b4e8685e 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -2495,7 +2495,7 @@ static int its_vpe_set_affinity(struct irq_data *d,
>  
>  static void its_vpe_schedule(struct its_vpe *vpe)
>  {
> - void * __iomem vlpi_base = gic_data_rdist_vlpi_base();
> + void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
>   u64 val;
>  
>   /* Schedule the VPE */
> @@ -2527,7 +2527,7 @@ static void its_vpe_schedule(struct its_vpe *vpe)
>  
>  static void its_vpe_deschedule(struct its_vpe *vpe)
>  {
> - void * __iomem vlpi_base = gic_data_rdist_vlpi_base();
> + void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
>   u32 count = 100;/* 1s! */
>   bool clean;
>   u64 val;
> 

Ah! Too bad you missed the pull request by a few hours... I'll stash
that for -rc3.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] irqchip/gic-v3-its: Fix misplaced __iomem annotations

[Marc Zyngier]

On 16/02/18 16:57, Robin Murphy wrote:
> Save 26 lines worth of Sparse complaints by fixing up this minor
> mishap. The pointee lies in the __iomem space; the pointer does not.
> 
> Signed-off-by: Robin Murphy 
> ---
>  drivers/irqchip/irq-gic-v3-its.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
> b/drivers/irqchip/irq-gic-v3-its.c
> index 06f025fd5726..3a38b4e8685e 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -2495,7 +2495,7 @@ static int its_vpe_set_affinity(struct irq_data *d,
>  
>  static void its_vpe_schedule(struct its_vpe *vpe)
>  {
> - void * __iomem vlpi_base = gic_data_rdist_vlpi_base();
> + void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
>   u64 val;
>  
>   /* Schedule the VPE */
> @@ -2527,7 +2527,7 @@ static void its_vpe_schedule(struct its_vpe *vpe)
>  
>  static void its_vpe_deschedule(struct its_vpe *vpe)
>  {
> - void * __iomem vlpi_base = gic_data_rdist_vlpi_base();
> + void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
>   u32 count = 100;/* 1s! */
>   bool clean;
>   u64 val;
> 

Ah! Too bad you missed the pull request by a few hours... I'll stash
that for -rc3.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

[PATCH] irqchip/gic-v3-its: Fix misplaced __iomem annotations

[Robin Murphy]

Save 26 lines worth of Sparse complaints by fixing up this minor
mishap. The pointee lies in the __iomem space; the pointer does not.

Signed-off-by: Robin Murphy 
---
 drivers/irqchip/irq-gic-v3-its.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 06f025fd5726..3a38b4e8685e 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2495,7 +2495,7 @@ static int its_vpe_set_affinity(struct irq_data *d,
 
 static void its_vpe_schedule(struct its_vpe *vpe)
 {
-   void * __iomem vlpi_base = gic_data_rdist_vlpi_base();
+   void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
u64 val;
 
/* Schedule the VPE */
@@ -2527,7 +2527,7 @@ static void its_vpe_schedule(struct its_vpe *vpe)
 
 static void its_vpe_deschedule(struct its_vpe *vpe)
 {
-   void * __iomem vlpi_base = gic_data_rdist_vlpi_base();
+   void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
u32 count = 100;/* 1s! */
bool clean;
u64 val;
-- 
2.16.1.dirty

[PATCH] irqchip/gic-v3-its: Fix misplaced __iomem annotations

[Robin Murphy]

Save 26 lines worth of Sparse complaints by fixing up this minor
mishap. The pointee lies in the __iomem space; the pointer does not.

Signed-off-by: Robin Murphy 
---
 drivers/irqchip/irq-gic-v3-its.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 06f025fd5726..3a38b4e8685e 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2495,7 +2495,7 @@ static int its_vpe_set_affinity(struct irq_data *d,
 
 static void its_vpe_schedule(struct its_vpe *vpe)
 {
-   void * __iomem vlpi_base = gic_data_rdist_vlpi_base();
+   void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
u64 val;
 
/* Schedule the VPE */
@@ -2527,7 +2527,7 @@ static void its_vpe_schedule(struct its_vpe *vpe)
 
 static void its_vpe_deschedule(struct its_vpe *vpe)
 {
-   void * __iomem vlpi_base = gic_data_rdist_vlpi_base();
+   void __iomem *vlpi_base = gic_data_rdist_vlpi_base();
u32 count = 100;/* 1s! */
bool clean;
u64 val;
-- 
2.16.1.dirty

Re: TCP and BBR: reproducibly low cwnd and bandwidth

[Neal Cardwell]

On Fri, Feb 16, 2018 at 11:26 AM, Holger Hoffstätte
 wrote:
>
> BBR in general will run with lower cwnd than e.g. Cubic or others.
> That's a feature and necessary for WAN transfers.

Please note that there's no general rule about whether BBR will run
with a lower or higher cwnd than CUBIC, Reno, or other loss-based
congestion control algorithms. Whether BBR's cwnd will be lower or
higher depends on the BDP of the path, the amount of buffering in the
bottleneck, and the number of flows. BBR tries to match the amount of
in-flight data to the BDP based on the available bandwidth and the
two-way propagation delay. This will usually produce an amount of data
in flight that is smaller than CUBIC/Reno (yielding lower latency) if
the path has deep buffers (bufferbloat), but can be larger than
CUBIC/Reno (yielding higher throughput) if the buffers are shallow and
the traffic is suffering burst losses.

>
>>> If using real HW (1 Gbps LAN, laptop and server), BBR limits the throughput
>>> to ~100 Mbps (verifiable not only by iperf3, but also by scp while
>>> transferring some files between hosts).
>
> Something seems really wrong with your setup. I get completely
> expected throughput on wired 1Gb between two hosts:
>
> Connecting to host tux, port 5201
> [  5] local 192.168.100.223 port 48718 connected to 192.168.100.222 port 5201
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.00   sec   113 MBytes   948 Mbits/sec0204 KBytes
> [  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec0204 KBytes
> [  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec0204 KBytes
> [...]
>
> Running it locally gives the more or less expected results as well:
>
> Connecting to host ragnarok, port 5201
> [  5] local 192.168.100.223 port 54090 connected to 192.168.100.223 port 5201
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.00   sec  8.09 GBytes  69.5 Gbits/sec0512 KBytes
> [  5]   1.00-2.00   sec  8.14 GBytes  69.9 Gbits/sec0512 KBytes
> [  5]   2.00-3.00   sec  8.43 GBytes  72.4 Gbits/sec0512 KBytes
> [...]
>
> Both hosts running 4.14.x with bbr and fq_codel (default qdisc everywhere).

Can you please clarify if this is over bare metal or between VM
guests? It sounds like Oleksandr's initial report was between KVM VMs,
so the virtualization may be an ingredient here.

thanks,
neal

Re: TCP and BBR: reproducibly low cwnd and bandwidth

[Neal Cardwell]

On Fri, Feb 16, 2018 at 11:26 AM, Holger Hoffstätte
 wrote:
>
> BBR in general will run with lower cwnd than e.g. Cubic or others.
> That's a feature and necessary for WAN transfers.

Please note that there's no general rule about whether BBR will run
with a lower or higher cwnd than CUBIC, Reno, or other loss-based
congestion control algorithms. Whether BBR's cwnd will be lower or
higher depends on the BDP of the path, the amount of buffering in the
bottleneck, and the number of flows. BBR tries to match the amount of
in-flight data to the BDP based on the available bandwidth and the
two-way propagation delay. This will usually produce an amount of data
in flight that is smaller than CUBIC/Reno (yielding lower latency) if
the path has deep buffers (bufferbloat), but can be larger than
CUBIC/Reno (yielding higher throughput) if the buffers are shallow and
the traffic is suffering burst losses.

>
>>> If using real HW (1 Gbps LAN, laptop and server), BBR limits the throughput
>>> to ~100 Mbps (verifiable not only by iperf3, but also by scp while
>>> transferring some files between hosts).
>
> Something seems really wrong with your setup. I get completely
> expected throughput on wired 1Gb between two hosts:
>
> Connecting to host tux, port 5201
> [  5] local 192.168.100.223 port 48718 connected to 192.168.100.222 port 5201
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.00   sec   113 MBytes   948 Mbits/sec0204 KBytes
> [  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec0204 KBytes
> [  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec0204 KBytes
> [...]
>
> Running it locally gives the more or less expected results as well:
>
> Connecting to host ragnarok, port 5201
> [  5] local 192.168.100.223 port 54090 connected to 192.168.100.223 port 5201
> [ ID] Interval   Transfer Bitrate Retr  Cwnd
> [  5]   0.00-1.00   sec  8.09 GBytes  69.5 Gbits/sec0512 KBytes
> [  5]   1.00-2.00   sec  8.14 GBytes  69.9 Gbits/sec0512 KBytes
> [  5]   2.00-3.00   sec  8.43 GBytes  72.4 Gbits/sec0512 KBytes
> [...]
>
> Both hosts running 4.14.x with bbr and fq_codel (default qdisc everywhere).

Can you please clarify if this is over bare metal or between VM
guests? It sounds like Oleksandr's initial report was between KVM VMs,
so the virtualization may be an ingredient here.

thanks,
neal

Re: [PATCH v3] rtc: isl12026: Add driver.

[Andy Shevchenko]

On Thu, Feb 15, 2018 at 9:54 PM, David Daney  wrote:
> The ISL12026 is a combination RTC and EEPROM device with I2C
> interface.  The standard RTC driver interface is provided.  The EEPROM
> is accessed via the NVMEM interface via the "eeprom0" directory in the
> sysfs entry for the device.
>

Couple of nitpicks below, though in any case, FWIW,
Reviewed-by: Andy Shevchenko 

> Signed-off-by: David Daney 
> ---
> Changes from v2:
>
> o More code cleanups suggested by reviewers.
>
> Changes from v1:
>
> o Fixed device tree bindings document example.
>
> o Use RTC_NVMEM facility for eeprom support.
>
> o Small code cleanups suggested by reviewers.
>
> .../devicetree/bindings/rtc/isil,isl12026.txt  |  28 ++
>  drivers/rtc/Kconfig|   9 +
>  drivers/rtc/Makefile   |   1 +
>  drivers/rtc/rtc-isl12026.c | 529 
> +
>  4 files changed, 567 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.txt
>  create mode 100644 drivers/rtc/rtc-isl12026.c
>
> diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.txt 
> b/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
> new file mode 100644
> index ..2e0be45193bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
> @@ -0,0 +1,28 @@
> +ISL12026 I2C RTC/EEPROM
> +
> +ISL12026 is an I2C RTC/EEPROM combination device.  The RTC and control
> +registers respond at bus address 0x6f, and the EEPROM array responds
> +at bus address 0x57.  The canonical "reg" value will be for the RTC portion.
> +
> +Required properties supported by the device:
> +
> + - "compatible": must be "isil,isl12026"
> + - "reg": I2C bus address of the device (always 0x6f)
> +
> +Optional properties:
> +
> + - "isil,pwr-bsw": If present PWR.BSW bit must be set to the specified
> +   value for proper operation.
> +
> + - "isil,pwr-sbib": If present PWR.SBIB bit must be set to the specified
> +value for proper operation.
> +
> +
> +Example:
> +
> +   rtc@6f {
> +   compatible = "isil,isl12026";
> +   reg = <0x6f>;
> +   isil,pwr-bsw = <0>;
> +   isil,pwr-sbib = <1>;
> +   }
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 8ab5f0a5d323..85171e9e3ada 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -407,6 +407,15 @@ config RTC_DRV_ISL12022
>   This driver can also be built as a module. If so, the module
>   will be called rtc-isl12022.
>
> +config RTC_DRV_ISL12026
> +   tristate "Intersil ISL12026"
> +   help
> + If you say yes here you get support for the
> + Intersil ISL12026 RTC chip.
> +
> + This driver can also be built as a module. If so, the module
> + will be called rtc-isl12026.
> +
>  config RTC_DRV_X1205
> tristate "Xicor/Intersil X1205"
> help
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 4fbf87e45a7c..f481661a6eae 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += 
> rtc-hid-sensor-time.o
>  obj-$(CONFIG_RTC_DRV_HYM8563)  += rtc-hym8563.o
>  obj-$(CONFIG_RTC_DRV_IMXDI)+= rtc-imxdi.o
>  obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
> +obj-$(CONFIG_RTC_DRV_ISL12026) += rtc-isl12026.o
>  obj-$(CONFIG_RTC_DRV_ISL1208)  += rtc-isl1208.o
>  obj-$(CONFIG_RTC_DRV_JZ4740)   += rtc-jz4740.o
>  obj-$(CONFIG_RTC_DRV_LP8788)   += rtc-lp8788.o
> diff --git a/drivers/rtc/rtc-isl12026.c b/drivers/rtc/rtc-isl12026.c
> new file mode 100644
> index ..1cb111e4c442
> --- /dev/null
> +++ b/drivers/rtc/rtc-isl12026.c
> @@ -0,0 +1,529 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * An I2C driver for the Intersil ISL 12026
> + *
> + * Copyright (c) 2018 Cavium, Inc.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* register offsets */
> +#define ISL12026_REG_PWR   0x14
> +# define ISL12026_REG_PWR_BSW  BIT(6)
> +# define ISL12026_REG_PWR_SBIB BIT(7)
> +#define ISL12026_REG_SC0x30
> +#define ISL12026_REG_HR0x32
> +# define ISL12026_REG_HR_MIL   BIT(7)  /* military or 24 hour time */
> +#define ISL12026_REG_SR0x3f
> +# define ISL12026_REG_SR_RTCF  BIT(0)
> +# define ISL12026_REG_SR_WEL   BIT(1)
> +# define ISL12026_REG_SR_RWEL  BIT(2)
> +# define ISL12026_REG_SR_MBZ   BIT(3)
> +# define ISL12026_REG_SR_OSCF  BIT(4)
> +
> +/* The EEPROM array responds at i2c address 0x57 */
> +#define ISL12026_EEPROM_ADDR   0x57
> +
> +#define ISL12026_PAGESIZE 16
> +#define ISL12026_NVMEM_WRITE_TIME 20
> +
> +struct isl12026 {
> +   struct rtc_device *rtc;
> +   struct i2c_client *nvm_client;
> +   

Re: [PATCH v3] rtc: isl12026: Add driver.

[Andy Shevchenko]

On Thu, Feb 15, 2018 at 9:54 PM, David Daney  wrote:
> The ISL12026 is a combination RTC and EEPROM device with I2C
> interface.  The standard RTC driver interface is provided.  The EEPROM
> is accessed via the NVMEM interface via the "eeprom0" directory in the
> sysfs entry for the device.
>

Couple of nitpicks below, though in any case, FWIW,
Reviewed-by: Andy Shevchenko 

> Signed-off-by: David Daney 
> ---
> Changes from v2:
>
> o More code cleanups suggested by reviewers.
>
> Changes from v1:
>
> o Fixed device tree bindings document example.
>
> o Use RTC_NVMEM facility for eeprom support.
>
> o Small code cleanups suggested by reviewers.
>
> .../devicetree/bindings/rtc/isil,isl12026.txt  |  28 ++
>  drivers/rtc/Kconfig|   9 +
>  drivers/rtc/Makefile   |   1 +
>  drivers/rtc/rtc-isl12026.c | 529 
> +
>  4 files changed, 567 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rtc/isil,isl12026.txt
>  create mode 100644 drivers/rtc/rtc-isl12026.c
>
> diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12026.txt 
> b/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
> new file mode 100644
> index ..2e0be45193bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/isil,isl12026.txt
> @@ -0,0 +1,28 @@
> +ISL12026 I2C RTC/EEPROM
> +
> +ISL12026 is an I2C RTC/EEPROM combination device.  The RTC and control
> +registers respond at bus address 0x6f, and the EEPROM array responds
> +at bus address 0x57.  The canonical "reg" value will be for the RTC portion.
> +
> +Required properties supported by the device:
> +
> + - "compatible": must be "isil,isl12026"
> + - "reg": I2C bus address of the device (always 0x6f)
> +
> +Optional properties:
> +
> + - "isil,pwr-bsw": If present PWR.BSW bit must be set to the specified
> +   value for proper operation.
> +
> + - "isil,pwr-sbib": If present PWR.SBIB bit must be set to the specified
> +value for proper operation.
> +
> +
> +Example:
> +
> +   rtc@6f {
> +   compatible = "isil,isl12026";
> +   reg = <0x6f>;
> +   isil,pwr-bsw = <0>;
> +   isil,pwr-sbib = <1>;
> +   }
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 8ab5f0a5d323..85171e9e3ada 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -407,6 +407,15 @@ config RTC_DRV_ISL12022
>   This driver can also be built as a module. If so, the module
>   will be called rtc-isl12022.
>
> +config RTC_DRV_ISL12026
> +   tristate "Intersil ISL12026"
> +   help
> + If you say yes here you get support for the
> + Intersil ISL12026 RTC chip.
> +
> + This driver can also be built as a module. If so, the module
> + will be called rtc-isl12026.
> +
>  config RTC_DRV_X1205
> tristate "Xicor/Intersil X1205"
> help
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 4fbf87e45a7c..f481661a6eae 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += 
> rtc-hid-sensor-time.o
>  obj-$(CONFIG_RTC_DRV_HYM8563)  += rtc-hym8563.o
>  obj-$(CONFIG_RTC_DRV_IMXDI)+= rtc-imxdi.o
>  obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
> +obj-$(CONFIG_RTC_DRV_ISL12026) += rtc-isl12026.o
>  obj-$(CONFIG_RTC_DRV_ISL1208)  += rtc-isl1208.o
>  obj-$(CONFIG_RTC_DRV_JZ4740)   += rtc-jz4740.o
>  obj-$(CONFIG_RTC_DRV_LP8788)   += rtc-lp8788.o
> diff --git a/drivers/rtc/rtc-isl12026.c b/drivers/rtc/rtc-isl12026.c
> new file mode 100644
> index ..1cb111e4c442
> --- /dev/null
> +++ b/drivers/rtc/rtc-isl12026.c
> @@ -0,0 +1,529 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * An I2C driver for the Intersil ISL 12026
> + *
> + * Copyright (c) 2018 Cavium, Inc.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* register offsets */
> +#define ISL12026_REG_PWR   0x14
> +# define ISL12026_REG_PWR_BSW  BIT(6)
> +# define ISL12026_REG_PWR_SBIB BIT(7)
> +#define ISL12026_REG_SC0x30
> +#define ISL12026_REG_HR0x32
> +# define ISL12026_REG_HR_MIL   BIT(7)  /* military or 24 hour time */
> +#define ISL12026_REG_SR0x3f
> +# define ISL12026_REG_SR_RTCF  BIT(0)
> +# define ISL12026_REG_SR_WEL   BIT(1)
> +# define ISL12026_REG_SR_RWEL  BIT(2)
> +# define ISL12026_REG_SR_MBZ   BIT(3)
> +# define ISL12026_REG_SR_OSCF  BIT(4)
> +
> +/* The EEPROM array responds at i2c address 0x57 */
> +#define ISL12026_EEPROM_ADDR   0x57
> +
> +#define ISL12026_PAGESIZE 16
> +#define ISL12026_NVMEM_WRITE_TIME 20
> +
> +struct isl12026 {
> +   struct rtc_device *rtc;
> +   struct i2c_client *nvm_client;
> +   struct nvmem_config nvm_cfg;
> +   /*
> +* RTC write operations 

Re: [PATCH 4.9 43/92] x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown

[Nick Lowe]

Hi,

This should use boot_cpu_has_bug(X86_BUG_CPU_MELTDOWN)) - I am
preparing patches.

Best,

Nick

Re: [PATCH 4.9 43/92] x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown

[Nick Lowe]

Hi,

This should use boot_cpu_has_bug(X86_BUG_CPU_MELTDOWN)) - I am
preparing patches.

Best,

Nick

Re: [PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

[Jason Baron]

On 02/16/2018 11:31 AM, Josh Poimboeuf wrote:
> After initmem has been freed, any jump label entries in __init code are
> prevented from being written to by the kernel_text_address() check in
> __jump_label_update().  However, this check is quite broad.  If
> kernel_text_address() were to return false for any other reason, the
> jump label write would fail silently with no warning.
> 
> For jump label entrieds in module init code, entry->code is set to zero
> to indicate that the entry is disabled.  Do the same thing for core
> kernel init code.  This makes the behavior more consistent, and will
> also make it more straightforward to detect non-init jump label write
> failures in the next patch.
> 
> Signed-off-by: Josh Poimboeuf 
> ---
>  include/linux/jump_label.h |  3 +++
>  init/main.c|  2 ++
>  kernel/jump_label.c| 18 --
>  3 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index b6a29c126cc4..2168cc6b8b30 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -151,6 +151,7 @@ extern struct jump_entry __start___jump_table[];
>  extern struct jump_entry __stop___jump_table[];
>  
>  extern void jump_label_init(void);
> +extern void jump_label_invalidate_init(void);
>  extern void jump_label_lock(void);
>  extern void jump_label_unlock(void);
>  extern void arch_jump_label_transform(struct jump_entry *entry,
> @@ -198,6 +199,8 @@ static __always_inline void jump_label_init(void)
>   static_key_initialized = true;
>  }
>  
> +static inline void jump_label_invalidate_init(void) {}
> +
>  static __always_inline bool static_key_false(struct static_key *key)
>  {
>   if (unlikely(static_key_count(key) > 0))
> diff --git a/init/main.c b/init/main.c
> index a8100b954839..969eaf140ef0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -89,6 +89,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1000,6 +1001,7 @@ static int __ref kernel_init(void *unused)
>   /* need to finish all async __init code before freeing the memory */
>   async_synchronize_full();
>   ftrace_free_init_mem();
> + jump_label_invalidate_init();
>   free_initmem();
>   mark_readonly();
>   system_state = SYSTEM_RUNNING;
> diff --git a/kernel/jump_label.c b/kernel/jump_label.c
> index b4517095db6a..96274c6d3511 100644
> --- a/kernel/jump_label.c
> +++ b/kernel/jump_label.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef HAVE_JUMP_LABEL
>  
> @@ -633,16 +634,29 @@ static void jump_label_del_module(struct module *mod)
>   }
>  }
>  
> +/* Disable any jump label entries in __init code */
> +void __init jump_label_invalidate_init(void)
> +{
> + struct jump_entry *iter_start = __start___jump_table;
> + struct jump_entry *iter_stop = __stop___jump_table;
> + struct jump_entry *iter;
> +
> + for (iter = iter_start; iter < iter_stop; iter++)
> + if (iter->code >= (unsigned long)_sinittext &&
> + iter->code < (unsigned long)_einittext)
> + iter->code = 0;
> +}

Seems like this wants to use init_kernel_text() but i see its marked
'static', perhaps it can be moved to a header?

Thanks,

-Jason

> +
> +/* Disable any jump label entries in module init code */
>  static void jump_label_invalidate_module_init(struct module *mod)
>  {
>   struct jump_entry *iter_start = mod->jump_entries;
>   struct jump_entry *iter_stop = iter_start + mod->num_jump_entries;
>   struct jump_entry *iter;
>  
> - for (iter = iter_start; iter < iter_stop; iter++) {
> + for (iter = iter_start; iter < iter_stop; iter++)
>   if (within_module_init(iter->code, mod))
>   iter->code = 0;
> - }
>  }
>  
>  static int
> 

Re: [PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

[Jason Baron]

On 02/16/2018 11:31 AM, Josh Poimboeuf wrote:
> After initmem has been freed, any jump label entries in __init code are
> prevented from being written to by the kernel_text_address() check in
> __jump_label_update().  However, this check is quite broad.  If
> kernel_text_address() were to return false for any other reason, the
> jump label write would fail silently with no warning.
> 
> For jump label entrieds in module init code, entry->code is set to zero
> to indicate that the entry is disabled.  Do the same thing for core
> kernel init code.  This makes the behavior more consistent, and will
> also make it more straightforward to detect non-init jump label write
> failures in the next patch.
> 
> Signed-off-by: Josh Poimboeuf 
> ---
>  include/linux/jump_label.h |  3 +++
>  init/main.c|  2 ++
>  kernel/jump_label.c| 18 --
>  3 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index b6a29c126cc4..2168cc6b8b30 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -151,6 +151,7 @@ extern struct jump_entry __start___jump_table[];
>  extern struct jump_entry __stop___jump_table[];
>  
>  extern void jump_label_init(void);
> +extern void jump_label_invalidate_init(void);
>  extern void jump_label_lock(void);
>  extern void jump_label_unlock(void);
>  extern void arch_jump_label_transform(struct jump_entry *entry,
> @@ -198,6 +199,8 @@ static __always_inline void jump_label_init(void)
>   static_key_initialized = true;
>  }
>  
> +static inline void jump_label_invalidate_init(void) {}
> +
>  static __always_inline bool static_key_false(struct static_key *key)
>  {
>   if (unlikely(static_key_count(key) > 0))
> diff --git a/init/main.c b/init/main.c
> index a8100b954839..969eaf140ef0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -89,6 +89,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -1000,6 +1001,7 @@ static int __ref kernel_init(void *unused)
>   /* need to finish all async __init code before freeing the memory */
>   async_synchronize_full();
>   ftrace_free_init_mem();
> + jump_label_invalidate_init();
>   free_initmem();
>   mark_readonly();
>   system_state = SYSTEM_RUNNING;
> diff --git a/kernel/jump_label.c b/kernel/jump_label.c
> index b4517095db6a..96274c6d3511 100644
> --- a/kernel/jump_label.c
> +++ b/kernel/jump_label.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef HAVE_JUMP_LABEL
>  
> @@ -633,16 +634,29 @@ static void jump_label_del_module(struct module *mod)
>   }
>  }
>  
> +/* Disable any jump label entries in __init code */
> +void __init jump_label_invalidate_init(void)
> +{
> + struct jump_entry *iter_start = __start___jump_table;
> + struct jump_entry *iter_stop = __stop___jump_table;
> + struct jump_entry *iter;
> +
> + for (iter = iter_start; iter < iter_stop; iter++)
> + if (iter->code >= (unsigned long)_sinittext &&
> + iter->code < (unsigned long)_einittext)
> + iter->code = 0;
> +}

Seems like this wants to use init_kernel_text() but i see its marked
'static', perhaps it can be moved to a header?

Thanks,

-Jason

> +
> +/* Disable any jump label entries in module init code */
>  static void jump_label_invalidate_module_init(struct module *mod)
>  {
>   struct jump_entry *iter_start = mod->jump_entries;
>   struct jump_entry *iter_stop = iter_start + mod->num_jump_entries;
>   struct jump_entry *iter;
>  
> - for (iter = iter_start; iter < iter_stop; iter++) {
> + for (iter = iter_start; iter < iter_stop; iter++)
>   if (within_module_init(iter->code, mod))
>   iter->code = 0;
> - }
>  }
>  
>  static int
> 

Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

[Arnaldo Carvalho de Melo]

Em Fri, Feb 16, 2018 at 01:52:45PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Jan 29, 2018 at 02:04:15PM +0530, Ravi Bangoria escreveu:
> > Will be used for generating the syscall id/string translation table.
> > 
> > Signed-off-by: Ravi Bangoria 
> > ---
> >  tools/arch/powerpc/include/uapi/asm/unistd.h | 399 
> > +++
> >  tools/perf/check-headers.sh  |   1 +
> >  2 files changed, 400 insertions(+)
> >  create mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h
> 
> Not building on a cross-compiling environment (ubuntu 16.04), I'm checking...

BTW, details about that environment:

  4629.83 ubuntu:16.04-x-powerpc: FAIL powerpc-linux-gnu-gcc 
(Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

 
>   CC   /tmp/build/perf/util/syscalltbl.o
> util/syscalltbl.c: In function 'syscalltbl__init_native':
> util/syscalltbl.c:64:19: error: 'syscalltbl_native_max_id' undeclared (first 
> use in this function)
>   for (i = 0; i <= syscalltbl_native_max_id; ++i)
>^
> util/syscalltbl.c:64:19: note: each undeclared identifier is reported only 
> once for each function it appears in
> util/syscalltbl.c:65:7: error: 'syscalltbl_native' undeclared (first use in 
> this function)
>if (syscalltbl_native[i])
>^
> util/syscalltbl.c: In function 'syscalltbl__name':
> util/syscalltbl.c:105:15: error: 'syscalltbl_native_max_id' undeclared (first 
> use in this function)
>   return id <= syscalltbl_native_max_id ? syscalltbl_native[id]: NULL;
>^
> util/syscalltbl.c:105:42: error: 'syscalltbl_native' undeclared (first use in 
> this function)
>   return id <= syscalltbl_native_max_id ? syscalltbl_native[id]: NULL;
>   ^
> util/syscalltbl.c:106:1: error: control reaches end of non-void function 
> [-Werror=return-type]
>  }
>  ^
> cc1: all warnings being treated as errors
> mv: cannot stat '/tmp/build/perf/util/.syscalltbl.o.tmp': No such file or 
> directory
> /git/linux/tools/build/Makefile.build:96: recipe for target 
> '/tmp/build/perf/util/syscalltbl.o' failed
> make[4]: *** [/tmp/build/perf/util/syscalltbl.o] Error 1
> make[4]: *** Waiting for unfinished jobs
>   CC   /tmp/build/perf/tests/sample-parsing.o
>   CC   /tmp/build/perf/tests/parse-no-sample-id-all.o
>   CC   /tmp/build/perf/tests/kmod-path.o
>   CC   /tmp/build/perf/tests/thread-map.o
>   CC   /tmp/build/perf/tests/llvm.o
>   CC   /tmp/build/perf/tests/bpf.o
>   CC   /tmp/build/perf/tests/topology.o
>   CC   /tmp/build/perf/tests/mem.o
>   CC   /tmp/build/perf/tests/cpumap.o
>   CC   /tmp/build/perf/tests/stat.o
> /git/linux/tools/build/Makefile.build:139: recipe for target 'util' failed
> make[3]: *** [util] Error 2
> Makefile.perf:629: recipe for target '/tmp/build/perf/libperf-in.o' failed
> make[2]: *** [/tmp/build/perf/libperf-in.o] Error 2
> make[2]: *** Waiting for unfinished jobs
>   CC   /tmp/build/perf/tests/event_update.o

Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

[Arnaldo Carvalho de Melo]

Em Fri, Feb 16, 2018 at 01:52:45PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Jan 29, 2018 at 02:04:15PM +0530, Ravi Bangoria escreveu:
> > Will be used for generating the syscall id/string translation table.
> > 
> > Signed-off-by: Ravi Bangoria 
> > ---
> >  tools/arch/powerpc/include/uapi/asm/unistd.h | 399 
> > +++
> >  tools/perf/check-headers.sh  |   1 +
> >  2 files changed, 400 insertions(+)
> >  create mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h
> 
> Not building on a cross-compiling environment (ubuntu 16.04), I'm checking...

BTW, details about that environment:

  4629.83 ubuntu:16.04-x-powerpc: FAIL powerpc-linux-gnu-gcc 
(Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

 
>   CC   /tmp/build/perf/util/syscalltbl.o
> util/syscalltbl.c: In function 'syscalltbl__init_native':
> util/syscalltbl.c:64:19: error: 'syscalltbl_native_max_id' undeclared (first 
> use in this function)
>   for (i = 0; i <= syscalltbl_native_max_id; ++i)
>^
> util/syscalltbl.c:64:19: note: each undeclared identifier is reported only 
> once for each function it appears in
> util/syscalltbl.c:65:7: error: 'syscalltbl_native' undeclared (first use in 
> this function)
>if (syscalltbl_native[i])
>^
> util/syscalltbl.c: In function 'syscalltbl__name':
> util/syscalltbl.c:105:15: error: 'syscalltbl_native_max_id' undeclared (first 
> use in this function)
>   return id <= syscalltbl_native_max_id ? syscalltbl_native[id]: NULL;
>^
> util/syscalltbl.c:105:42: error: 'syscalltbl_native' undeclared (first use in 
> this function)
>   return id <= syscalltbl_native_max_id ? syscalltbl_native[id]: NULL;
>   ^
> util/syscalltbl.c:106:1: error: control reaches end of non-void function 
> [-Werror=return-type]
>  }
>  ^
> cc1: all warnings being treated as errors
> mv: cannot stat '/tmp/build/perf/util/.syscalltbl.o.tmp': No such file or 
> directory
> /git/linux/tools/build/Makefile.build:96: recipe for target 
> '/tmp/build/perf/util/syscalltbl.o' failed
> make[4]: *** [/tmp/build/perf/util/syscalltbl.o] Error 1
> make[4]: *** Waiting for unfinished jobs
>   CC   /tmp/build/perf/tests/sample-parsing.o
>   CC   /tmp/build/perf/tests/parse-no-sample-id-all.o
>   CC   /tmp/build/perf/tests/kmod-path.o
>   CC   /tmp/build/perf/tests/thread-map.o
>   CC   /tmp/build/perf/tests/llvm.o
>   CC   /tmp/build/perf/tests/bpf.o
>   CC   /tmp/build/perf/tests/topology.o
>   CC   /tmp/build/perf/tests/mem.o
>   CC   /tmp/build/perf/tests/cpumap.o
>   CC   /tmp/build/perf/tests/stat.o
> /git/linux/tools/build/Makefile.build:139: recipe for target 'util' failed
> make[3]: *** [util] Error 2
> Makefile.perf:629: recipe for target '/tmp/build/perf/libperf-in.o' failed
> make[2]: *** [/tmp/build/perf/libperf-in.o] Error 2
> make[2]: *** Waiting for unfinished jobs
>   CC   /tmp/build/perf/tests/event_update.o

Re: [PATCH 1/4] perf record: Provide detailed information on s390 CPU

[Arnaldo Carvalho de Melo]

Em Tue, Feb 13, 2018 at 04:14:16PM +0100, Thomas Richter escreveu:
> When perf record ... is setup to record data, the s390
> cpu information was a fixed string "IBM/S390".
> 
> Replace this string with one containing more information
> about the machine. The information included in the cpuid is
> a comma separated list:
>manufacturer,type,model-capacity,model[,version,authorization]
> with
> 
> - manufacturer: up to 16 byte name of the manufacturer (IBM).
> - type: a four digit number refering to the machine
>   generation.
> - model-capacitiy: up to 16 characters describing number
>   of cpus etc.
> - model: up to 16 characters describing model.
> - version: the CPU-MF counter facility version number,
>   available on LPARs only, omitted on z/VM guests.
> - authorization: the CPU-MF counter facility authorization level,
>   available on LPARs only, omitted on z/VM guests.
> 
> Before:
> [root@s8360047 perf]# ./perf record -- sleep 1
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.001 MB perf.data (4 samples) ]
> [root@s8360047 perf]# ./perf report --header | fgrep cpuid
>  # cpuid : IBM/S390
> [root@s8360047 perf]#


  4938.13 ubuntu:16.04-x-s390   : FAIL s390x-linux-gnu-gcc (Ubuntu 
5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609


Humm, this seems to be the one causing this:

  LINK /tmp/build/perf/plugin_hrtimer.so
  LINK /tmp/build/perf/plugin_kmem.so
In file included from /usr/s390x-linux-gnu/include/string.h:635:0,
 from arch/s390/util/header.c:16:
In function 'strncat',
inlined from 'get_cpuid' at arch/s390/util/header.c:65:5:
/usr/s390x-linux-gnu/include/bits/string3.h:156:10: error: call to 
__builtin___strncat_chk might overflow destination buffer [-Werror]
   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
  ^
In function 'strncat',
inlined from 'get_cpuid' at arch/s390/util/header.c:72:5:
/usr/s390x-linux-gnu/include/bits/string3.h:156:10: error: call to 
__builtin___strncat_chk might overflow destination buffer [-Werror]
   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
  ^
In function 'strncat',
inlined from 'get_cpuid' at arch/s390/util/header.c:111:5:
/usr/s390x-linux-gnu/include/bits/string3.h:156:10: error: call to 
__builtin___strncat_chk might overflow destination buffer [-Werror]
   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
  ^
In function 'strncat',
inlined from 'get_cpuid' at arch/s390/util/header.c:117:5:
/usr/s390x-linux-gnu/include/bits/string3.h:156:10: error: call to 
__builtin___strncat_chk might overflow destination buffer [-Werror]
   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
  ^
  LINK /tmp/build/perf/plugin_kvm.so
  MKDIR/tmp/build/perf/arch/s390/util/
  LINK /tmp/build/perf/plugin_mac80211.so
  CC   /tmp/build/perf/arch/s390/util/kvm-stat.o
  LINK /tmp/build/perf/plugin_sched_switch.so
cc1: all warnings being treated as errors
mv: cannot stat '/tmp/build/perf/arch/s390/util/.header.o.tmp': No such file or 
directory
/git/linux/tools/build/Makefile.build:96: recipe for target 
'/tmp/build/perf/arch/s390/util/header.o' failed
make[6]: *** [/tmp/build/perf/arch/s390/util/header.o] Error 1
make[6]: *** Waiting for unfinished jobs
  LINK /tmp/build/perf/plugin_function.so

 
> After:
> [root@s35lp76 perf]# ./perf report --header|fgrep cpuid
>  # cpuid : IBM,3906,704,M03,3.5,002f
> [root@s35lp76 perf]#
> 
> Signed-off-by: Thomas Richter 
> Reviewed-by: Hendrik Brueckner 
> ---
>  tools/perf/arch/s390/util/header.c | 126 
> +++--
>  1 file changed, 121 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/perf/arch/s390/util/header.c 
> b/tools/perf/arch/s390/util/header.c
> index 9fa6c3e5782c..3d29ba47edce 100644
> --- a/tools/perf/arch/s390/util/header.c
> +++ b/tools/perf/arch/s390/util/header.c
> @@ -1,8 +1,9 @@
>  /*
>   * Implementation of get_cpuid().
>   *
> - * Copyright 2014 IBM Corp.
> + * Copyright IBM Corp. 2014, 2018
>   * Author(s): Alexander Yarygin 
> + * Thomas Richter 
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License (version 2 only)
> @@ -13,16 +14,131 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "../../util/header.h"
> +#include "../../util/util.h"
> +
> +#define SYSINFO_MANU "Manufacturer:"
> +#define SYSINFO_TYPE "Type:"
> +#define SYSINFO_MODEL"Model:"
> +#define SRVLVL_CPUMF "CPU-MF:"
> +#define SRVLVL_VERSION   "version="
> +#define SRVLVL_AUTHORIZATION "authorization="
> +#define SYSINFO  "/proc/sysinfo"
> +#define SRVLVL   "/proc/service_levels"
>  
>  int get_cpuid(char *buffer, size_t sz)
>  {
> -   

Re: [PATCH 1/4] perf record: Provide detailed information on s390 CPU

[Arnaldo Carvalho de Melo]

Em Tue, Feb 13, 2018 at 04:14:16PM +0100, Thomas Richter escreveu:
> When perf record ... is setup to record data, the s390
> cpu information was a fixed string "IBM/S390".
> 
> Replace this string with one containing more information
> about the machine. The information included in the cpuid is
> a comma separated list:
>manufacturer,type,model-capacity,model[,version,authorization]
> with
> 
> - manufacturer: up to 16 byte name of the manufacturer (IBM).
> - type: a four digit number refering to the machine
>   generation.
> - model-capacitiy: up to 16 characters describing number
>   of cpus etc.
> - model: up to 16 characters describing model.
> - version: the CPU-MF counter facility version number,
>   available on LPARs only, omitted on z/VM guests.
> - authorization: the CPU-MF counter facility authorization level,
>   available on LPARs only, omitted on z/VM guests.
> 
> Before:
> [root@s8360047 perf]# ./perf record -- sleep 1
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.001 MB perf.data (4 samples) ]
> [root@s8360047 perf]# ./perf report --header | fgrep cpuid
>  # cpuid : IBM/S390
> [root@s8360047 perf]#


  4938.13 ubuntu:16.04-x-s390   : FAIL s390x-linux-gnu-gcc (Ubuntu 
5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609


Humm, this seems to be the one causing this:

  LINK /tmp/build/perf/plugin_hrtimer.so
  LINK /tmp/build/perf/plugin_kmem.so
In file included from /usr/s390x-linux-gnu/include/string.h:635:0,
 from arch/s390/util/header.c:16:
In function 'strncat',
inlined from 'get_cpuid' at arch/s390/util/header.c:65:5:
/usr/s390x-linux-gnu/include/bits/string3.h:156:10: error: call to 
__builtin___strncat_chk might overflow destination buffer [-Werror]
   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
  ^
In function 'strncat',
inlined from 'get_cpuid' at arch/s390/util/header.c:72:5:
/usr/s390x-linux-gnu/include/bits/string3.h:156:10: error: call to 
__builtin___strncat_chk might overflow destination buffer [-Werror]
   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
  ^
In function 'strncat',
inlined from 'get_cpuid' at arch/s390/util/header.c:111:5:
/usr/s390x-linux-gnu/include/bits/string3.h:156:10: error: call to 
__builtin___strncat_chk might overflow destination buffer [-Werror]
   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
  ^
In function 'strncat',
inlined from 'get_cpuid' at arch/s390/util/header.c:117:5:
/usr/s390x-linux-gnu/include/bits/string3.h:156:10: error: call to 
__builtin___strncat_chk might overflow destination buffer [-Werror]
   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
  ^
  LINK /tmp/build/perf/plugin_kvm.so
  MKDIR/tmp/build/perf/arch/s390/util/
  LINK /tmp/build/perf/plugin_mac80211.so
  CC   /tmp/build/perf/arch/s390/util/kvm-stat.o
  LINK /tmp/build/perf/plugin_sched_switch.so
cc1: all warnings being treated as errors
mv: cannot stat '/tmp/build/perf/arch/s390/util/.header.o.tmp': No such file or 
directory
/git/linux/tools/build/Makefile.build:96: recipe for target 
'/tmp/build/perf/arch/s390/util/header.o' failed
make[6]: *** [/tmp/build/perf/arch/s390/util/header.o] Error 1
make[6]: *** Waiting for unfinished jobs
  LINK /tmp/build/perf/plugin_function.so

 
> After:
> [root@s35lp76 perf]# ./perf report --header|fgrep cpuid
>  # cpuid : IBM,3906,704,M03,3.5,002f
> [root@s35lp76 perf]#
> 
> Signed-off-by: Thomas Richter 
> Reviewed-by: Hendrik Brueckner 
> ---
>  tools/perf/arch/s390/util/header.c | 126 
> +++--
>  1 file changed, 121 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/perf/arch/s390/util/header.c 
> b/tools/perf/arch/s390/util/header.c
> index 9fa6c3e5782c..3d29ba47edce 100644
> --- a/tools/perf/arch/s390/util/header.c
> +++ b/tools/perf/arch/s390/util/header.c
> @@ -1,8 +1,9 @@
>  /*
>   * Implementation of get_cpuid().
>   *
> - * Copyright 2014 IBM Corp.
> + * Copyright IBM Corp. 2014, 2018
>   * Author(s): Alexander Yarygin 
> + * Thomas Richter 
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License (version 2 only)
> @@ -13,16 +14,131 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "../../util/header.h"
> +#include "../../util/util.h"
> +
> +#define SYSINFO_MANU "Manufacturer:"
> +#define SYSINFO_TYPE "Type:"
> +#define SYSINFO_MODEL"Model:"
> +#define SRVLVL_CPUMF "CPU-MF:"
> +#define SRVLVL_VERSION   "version="
> +#define SRVLVL_AUTHORIZATION "authorization="
> +#define SYSINFO  "/proc/sysinfo"
> +#define SRVLVL   "/proc/service_levels"
>  
>  int get_cpuid(char *buffer, size_t sz)
>  {
> - const char *cpuid = "IBM/S390";
> + char *cp, *line = NULL, *line2;
> + char type[8], model[33], 

[PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

[Colin King]

From: Colin Ian King 

The shifting of timehi by 16 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an u64. If the top bit
of timehi is set then all then all the upper bits of ns end up as also
being set because of the sign-extension. Fix this by making timehi and
timelo u64.  Also move the declaration of ns.

Detected by CoverityScan, CID#1465288 ("Unintended sign extension")

Fixes: c6fe0ad2c349 ("net: dsa: mv88e6xxx: add rx/tx timestamping support")
Signed-off-by: Colin Ian King 
---
 drivers/net/dsa/mv88e6xxx/hwtstamp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/hwtstamp.c 
b/drivers/net/dsa/mv88e6xxx/hwtstamp.c
index b251d534b70d..2149d332dea0 100644
--- a/drivers/net/dsa/mv88e6xxx/hwtstamp.c
+++ b/drivers/net/dsa/mv88e6xxx/hwtstamp.c
@@ -293,7 +293,8 @@ static void mv88e6xxx_get_rxts(struct mv88e6xxx_chip *chip,
   struct sk_buff *skb, u16 reg,
   struct sk_buff_head *rxq)
 {
-   u16 buf[4] = { 0 }, status, timelo, timehi, seq_id;
+   u16 buf[4] = { 0 }, status, seq_id;
+   u64 ns, timelo, timehi;
struct skb_shared_hwtstamps *shwt;
int err;
 
@@ -321,7 +322,7 @@ static void mv88e6xxx_get_rxts(struct mv88e6xxx_chip *chip,
 */
for ( ; skb; skb = skb_dequeue(rxq)) {
if (mv88e6xxx_ts_valid(status) && seq_match(skb, seq_id)) {
-   u64 ns = timehi << 16 | timelo;
+   ns = timehi << 16 | timelo;
 
mutex_lock(>reg_lock);
ns = timecounter_cyc2time(>tstamp_tc, ns);
-- 
2.15.1

[PATCH][V2] net: dsa: mv88e6xxx: avoid unintended sign extension on a 16 bit shift

[Colin King]

From: Colin Ian King 

The shifting of timehi by 16 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an u64. If the top bit
of timehi is set then all then all the upper bits of ns end up as also
being set because of the sign-extension. Fix this by making timehi and
timelo u64.  Also move the declaration of ns.

Detected by CoverityScan, CID#1465288 ("Unintended sign extension")

Fixes: c6fe0ad2c349 ("net: dsa: mv88e6xxx: add rx/tx timestamping support")
Signed-off-by: Colin Ian King 
---
 drivers/net/dsa/mv88e6xxx/hwtstamp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/hwtstamp.c 
b/drivers/net/dsa/mv88e6xxx/hwtstamp.c
index b251d534b70d..2149d332dea0 100644
--- a/drivers/net/dsa/mv88e6xxx/hwtstamp.c
+++ b/drivers/net/dsa/mv88e6xxx/hwtstamp.c
@@ -293,7 +293,8 @@ static void mv88e6xxx_get_rxts(struct mv88e6xxx_chip *chip,
   struct sk_buff *skb, u16 reg,
   struct sk_buff_head *rxq)
 {
-   u16 buf[4] = { 0 }, status, timelo, timehi, seq_id;
+   u16 buf[4] = { 0 }, status, seq_id;
+   u64 ns, timelo, timehi;
struct skb_shared_hwtstamps *shwt;
int err;
 
@@ -321,7 +322,7 @@ static void mv88e6xxx_get_rxts(struct mv88e6xxx_chip *chip,
 */
for ( ; skb; skb = skb_dequeue(rxq)) {
if (mv88e6xxx_ts_valid(status) && seq_match(skb, seq_id)) {
-   u64 ns = timehi << 16 | timelo;
+   ns = timehi << 16 | timelo;
 
mutex_lock(>reg_lock);
ns = timecounter_cyc2time(>tstamp_tc, ns);
-- 
2.15.1

Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

[Tony Lindgren]

* Andy Shevchenko  [180216 10:40]:
> Sorry, I was thinking that Tony may test it first to see if it does
> what he wants.

Well using dev_name() for the wakeirq name might still conflict
with the device IO interrupt. But yeah I'll give it a try.

Regards,

Tony

Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

[Tony Lindgren]

* Andy Shevchenko  [180216 10:40]:
> Sorry, I was thinking that Tony may test it first to see if it does
> what he wants.

Well using dev_name() for the wakeirq name might still conflict
with the device IO interrupt. But yeah I'll give it a try.

Regards,

Tony

Re: arm64/v4.16-rc1: KASAN: use-after-free Read in finish_task_switch

[Mark Rutland]

Hi,

On Thu, Feb 15, 2018 at 10:08:56PM +, Mathieu Desnoyers wrote:
> My current theory: do_exit() gets preempted after having set current->mm
> to NULL, and after having issued mmput(), which brings the mm_count down
> to 0.
>
> Unfortunately, if the scheduler switches from a userspace thread
> to a kernel thread, context_switch() loads prev->active_mm which still
> points to the now-freed mm, mmgrab the mm, and eventually does mmdrop
> in finish_task_switch().

For this to happen, we need to get to the mmput() in exit_mm() with:

  mm->mm_count == 1
  mm->mm_users == 1
  mm == active_mm

... but AFAICT, this cannot happen.

If there's no context_switch between clearing current->mm and the
mmput(), then mm->mm_count >= 2, thanks to the prior mmgrab() and the
active_mm reference (in mm_count) that context_switch+finish_task_switch
manage.

If there is a context_switch between the two, then AFAICT, either:

a) The task re-inherits its old mm as active_mm, and mm_count >= 2. In
   context_switch we mmgrab() the active_mm to inherit it, and in
   finish_task_switch() we drop the oldmm, balancing the mmgrab() with
   an mmput().

   e.g we go task -> kernel_task -> task

b) At some point, another user task is scheduled, and we switch to its
   mm. We don't mmgrab() the active_mm, but we mmdrop() the oldmm, which
   means mm_count >= 1. Since we witched to a new mm, if we switch back
   to the first task, it cannot have its own mm as active_mm.

   e.g. we go task -> other_task -> task

I suspect we have a bogus mmdrop or mmput elsewhere, and do_exit() and
finish_task_switch() aren't to blame.

Thanks,
Mark.

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

[Colin Ian King]

On 16/02/18 16:51, Andy Shevchenko wrote:
> On Thu, Feb 15, 2018 at 9:42 PM, Colin King  wrote:
>> From: Colin Ian King 
>>
>> The checks to see if key->dst.s6_addr and key->src.s6_addr are null
>> pointers are redundant because these are constant size arrays and
>> so the checks always return true.  Fix this by removing the redundant
>> checks.
> 
>> +   for (i = 0; i < 4; i++)
> 
>> +   filter->f.mask.tcp_spec.dst_ip[i] |=
>> 
>> cpu_to_be32(0x);
> 
> Can it be one line then?

I re-adjusted the text because checkpatch was complaining.

> 
>> +   memcpy(>f.data.tcp_spec.dst_ip,
>> +  >dst.s6_addr32,
> 
> Ditto.
> 
>> +  sizeof(filter->f.data.tcp_spec.dst_ip));
>> +
>> +   for (i = 0; i < 4; i++)
> 
>> +   filter->f.mask.tcp_spec.src_ip[i] |=
>> 
>> cpu_to_be32(0x);
> 
> Ditto.
> 
>> +   memcpy(>f.data.tcp_spec.src_ip,
>> +  >src.s6_addr32,
> 
> Ditto.
> 
>> +  sizeof(filter->f.data.tcp_spec.src_ip));
> 

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

[Colin Ian King]

On 16/02/18 16:51, Andy Shevchenko wrote:
> On Thu, Feb 15, 2018 at 9:42 PM, Colin King  wrote:
>> From: Colin Ian King 
>>
>> The checks to see if key->dst.s6_addr and key->src.s6_addr are null
>> pointers are redundant because these are constant size arrays and
>> so the checks always return true.  Fix this by removing the redundant
>> checks.
> 
>> +   for (i = 0; i < 4; i++)
> 
>> +   filter->f.mask.tcp_spec.dst_ip[i] |=
>> 
>> cpu_to_be32(0x);
> 
> Can it be one line then?

I re-adjusted the text because checkpatch was complaining.

> 
>> +   memcpy(>f.data.tcp_spec.dst_ip,
>> +  >dst.s6_addr32,
> 
> Ditto.
> 
>> +  sizeof(filter->f.data.tcp_spec.dst_ip));
>> +
>> +   for (i = 0; i < 4; i++)
> 
>> +   filter->f.mask.tcp_spec.src_ip[i] |=
>> 
>> cpu_to_be32(0x);
> 
> Ditto.
> 
>> +   memcpy(>f.data.tcp_spec.src_ip,
>> +  >src.s6_addr32,
> 
> Ditto.
> 
>> +  sizeof(filter->f.data.tcp_spec.src_ip));
> 

Re: arm64/v4.16-rc1: KASAN: use-after-free Read in finish_task_switch

[Mark Rutland]

Hi,

On Thu, Feb 15, 2018 at 10:08:56PM +, Mathieu Desnoyers wrote:
> My current theory: do_exit() gets preempted after having set current->mm
> to NULL, and after having issued mmput(), which brings the mm_count down
> to 0.
>
> Unfortunately, if the scheduler switches from a userspace thread
> to a kernel thread, context_switch() loads prev->active_mm which still
> points to the now-freed mm, mmgrab the mm, and eventually does mmdrop
> in finish_task_switch().

For this to happen, we need to get to the mmput() in exit_mm() with:

  mm->mm_count == 1
  mm->mm_users == 1
  mm == active_mm

... but AFAICT, this cannot happen.

If there's no context_switch between clearing current->mm and the
mmput(), then mm->mm_count >= 2, thanks to the prior mmgrab() and the
active_mm reference (in mm_count) that context_switch+finish_task_switch
manage.

If there is a context_switch between the two, then AFAICT, either:

a) The task re-inherits its old mm as active_mm, and mm_count >= 2. In
   context_switch we mmgrab() the active_mm to inherit it, and in
   finish_task_switch() we drop the oldmm, balancing the mmgrab() with
   an mmput().

   e.g we go task -> kernel_task -> task

b) At some point, another user task is scheduled, and we switch to its
   mm. We don't mmgrab() the active_mm, but we mmdrop() the oldmm, which
   means mm_count >= 1. Since we witched to a new mm, if we switch back
   to the first task, it cannot have its own mm as active_mm.

   e.g. we go task -> other_task -> task

I suspect we have a bogus mmdrop or mmput elsewhere, and do_exit() and
finish_task_switch() aren't to blame.

Thanks,
Mark.

Re: Trial of conflict resolution of Alan's patch

[Paul E. McKenney]

On Fri, Feb 16, 2018 at 04:47:04PM +0100, Andrea Parri wrote:
> On Fri, Feb 16, 2018 at 10:18:34AM -0500, Alan Stern wrote:
> > On Fri, 16 Feb 2018, Akira Yokosawa wrote:
> > 
> > > Hi,
> > > 
> > > My forward-port patch doesn't apply to the "lkmm" branch.
> > > It looks like "linux-kernel-hardware.cat" is intentionally omitted there.
> > > Am I guessing right?
> > > 
> > > If this is the case, I can prepare a patch to be applied to "lkmm".
> > > But I can't compose a proper change log. So I'd like Alan to post
> > > a patch with my SOB appended. Does this approach sound reasonable?
> > 
> > The patch is not yet ready to be merged.  At the very least, I need to
> > include an update to explanation.txt along with it.  When it is all 
> > ready, I will rebase it on Paul's repository and post it.
> > 
> > Which reminds me: Now that the material has been accepted into the 
> > kernel, do we need to keep the github repository?  It has the 
> > linux-kernel-hardware.cat file, but otherwise it seems to be redundant.
> 
> If you mean "to keep up-to-date", I'd say "No, we don't..."  ;-)
> 
> My plan/hope is to add such a disclaimer together with a pointer
> to Linus's tree ASAP...

I agree that the github repository is useful as a historical reference
but that we should not try to keep it up to date.  The -rc1 release
came out last Sunday, so in 7-8 weeks we will hopefully have this in
the Linux kernel.  Fingers firmly crossed and all that...

Thanx, Paul

Re: Trial of conflict resolution of Alan's patch

[Paul E. McKenney]

On Fri, Feb 16, 2018 at 04:47:04PM +0100, Andrea Parri wrote:
> On Fri, Feb 16, 2018 at 10:18:34AM -0500, Alan Stern wrote:
> > On Fri, 16 Feb 2018, Akira Yokosawa wrote:
> > 
> > > Hi,
> > > 
> > > My forward-port patch doesn't apply to the "lkmm" branch.
> > > It looks like "linux-kernel-hardware.cat" is intentionally omitted there.
> > > Am I guessing right?
> > > 
> > > If this is the case, I can prepare a patch to be applied to "lkmm".
> > > But I can't compose a proper change log. So I'd like Alan to post
> > > a patch with my SOB appended. Does this approach sound reasonable?
> > 
> > The patch is not yet ready to be merged.  At the very least, I need to
> > include an update to explanation.txt along with it.  When it is all 
> > ready, I will rebase it on Paul's repository and post it.
> > 
> > Which reminds me: Now that the material has been accepted into the 
> > kernel, do we need to keep the github repository?  It has the 
> > linux-kernel-hardware.cat file, but otherwise it seems to be redundant.
> 
> If you mean "to keep up-to-date", I'd say "No, we don't..."  ;-)
> 
> My plan/hope is to add such a disclaimer together with a pointer
> to Linus's tree ASAP...

I agree that the github repository is useful as a historical reference
but that we should not try to keep it up to date.  The -rc1 release
came out last Sunday, so in 7-8 weeks we will hopefully have this in
the Linux kernel.  Fingers firmly crossed and all that...

Thanx, Paul

Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

[Arnaldo Carvalho de Melo]

Em Mon, Jan 29, 2018 at 02:04:15PM +0530, Ravi Bangoria escreveu:
> Will be used for generating the syscall id/string translation table.
> 
> Signed-off-by: Ravi Bangoria 
> ---
>  tools/arch/powerpc/include/uapi/asm/unistd.h | 399 
> +++
>  tools/perf/check-headers.sh  |   1 +
>  2 files changed, 400 insertions(+)
>  create mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h

Not building on a cross-compiling environment (ubuntu 16.04), I'm checking...

  CC   /tmp/build/perf/util/syscalltbl.o
util/syscalltbl.c: In function 'syscalltbl__init_native':
util/syscalltbl.c:64:19: error: 'syscalltbl_native_max_id' undeclared (first 
use in this function)
  for (i = 0; i <= syscalltbl_native_max_id; ++i)
   ^
util/syscalltbl.c:64:19: note: each undeclared identifier is reported only once 
for each function it appears in
util/syscalltbl.c:65:7: error: 'syscalltbl_native' undeclared (first use in 
this function)
   if (syscalltbl_native[i])
   ^
util/syscalltbl.c: In function 'syscalltbl__name':
util/syscalltbl.c:105:15: error: 'syscalltbl_native_max_id' undeclared (first 
use in this function)
  return id <= syscalltbl_native_max_id ? syscalltbl_native[id]: NULL;
   ^
util/syscalltbl.c:105:42: error: 'syscalltbl_native' undeclared (first use in 
this function)
  return id <= syscalltbl_native_max_id ? syscalltbl_native[id]: NULL;
  ^
util/syscalltbl.c:106:1: error: control reaches end of non-void function 
[-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
mv: cannot stat '/tmp/build/perf/util/.syscalltbl.o.tmp': No such file or 
directory
/git/linux/tools/build/Makefile.build:96: recipe for target 
'/tmp/build/perf/util/syscalltbl.o' failed
make[4]: *** [/tmp/build/perf/util/syscalltbl.o] Error 1
make[4]: *** Waiting for unfinished jobs
  CC   /tmp/build/perf/tests/sample-parsing.o
  CC   /tmp/build/perf/tests/parse-no-sample-id-all.o
  CC   /tmp/build/perf/tests/kmod-path.o
  CC   /tmp/build/perf/tests/thread-map.o
  CC   /tmp/build/perf/tests/llvm.o
  CC   /tmp/build/perf/tests/bpf.o
  CC   /tmp/build/perf/tests/topology.o
  CC   /tmp/build/perf/tests/mem.o
  CC   /tmp/build/perf/tests/cpumap.o
  CC   /tmp/build/perf/tests/stat.o
/git/linux/tools/build/Makefile.build:139: recipe for target 'util' failed
make[3]: *** [util] Error 2
Makefile.perf:629: recipe for target '/tmp/build/perf/libperf-in.o' failed
make[2]: *** [/tmp/build/perf/libperf-in.o] Error 2
make[2]: *** Waiting for unfinished jobs
  CC   /tmp/build/perf/tests/event_update.o

Re: [PATCH 1/3] tools include powerpc: Grab a copy of arch/powerpc/include/uapi/asm/unistd.h

[Arnaldo Carvalho de Melo]

Em Mon, Jan 29, 2018 at 02:04:15PM +0530, Ravi Bangoria escreveu:
> Will be used for generating the syscall id/string translation table.
> 
> Signed-off-by: Ravi Bangoria 
> ---
>  tools/arch/powerpc/include/uapi/asm/unistd.h | 399 
> +++
>  tools/perf/check-headers.sh  |   1 +
>  2 files changed, 400 insertions(+)
>  create mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h

Not building on a cross-compiling environment (ubuntu 16.04), I'm checking...

  CC   /tmp/build/perf/util/syscalltbl.o
util/syscalltbl.c: In function 'syscalltbl__init_native':
util/syscalltbl.c:64:19: error: 'syscalltbl_native_max_id' undeclared (first 
use in this function)
  for (i = 0; i <= syscalltbl_native_max_id; ++i)
   ^
util/syscalltbl.c:64:19: note: each undeclared identifier is reported only once 
for each function it appears in
util/syscalltbl.c:65:7: error: 'syscalltbl_native' undeclared (first use in 
this function)
   if (syscalltbl_native[i])
   ^
util/syscalltbl.c: In function 'syscalltbl__name':
util/syscalltbl.c:105:15: error: 'syscalltbl_native_max_id' undeclared (first 
use in this function)
  return id <= syscalltbl_native_max_id ? syscalltbl_native[id]: NULL;
   ^
util/syscalltbl.c:105:42: error: 'syscalltbl_native' undeclared (first use in 
this function)
  return id <= syscalltbl_native_max_id ? syscalltbl_native[id]: NULL;
  ^
util/syscalltbl.c:106:1: error: control reaches end of non-void function 
[-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
mv: cannot stat '/tmp/build/perf/util/.syscalltbl.o.tmp': No such file or 
directory
/git/linux/tools/build/Makefile.build:96: recipe for target 
'/tmp/build/perf/util/syscalltbl.o' failed
make[4]: *** [/tmp/build/perf/util/syscalltbl.o] Error 1
make[4]: *** Waiting for unfinished jobs
  CC   /tmp/build/perf/tests/sample-parsing.o
  CC   /tmp/build/perf/tests/parse-no-sample-id-all.o
  CC   /tmp/build/perf/tests/kmod-path.o
  CC   /tmp/build/perf/tests/thread-map.o
  CC   /tmp/build/perf/tests/llvm.o
  CC   /tmp/build/perf/tests/bpf.o
  CC   /tmp/build/perf/tests/topology.o
  CC   /tmp/build/perf/tests/mem.o
  CC   /tmp/build/perf/tests/cpumap.o
  CC   /tmp/build/perf/tests/stat.o
/git/linux/tools/build/Makefile.build:139: recipe for target 'util' failed
make[3]: *** [util] Error 2
Makefile.perf:629: recipe for target '/tmp/build/perf/libperf-in.o' failed
make[2]: *** [/tmp/build/perf/libperf-in.o] Error 2
make[2]: *** Waiting for unfinished jobs
  CC   /tmp/build/perf/tests/event_update.o

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

[Andy Shevchenko]

On Thu, Feb 15, 2018 at 9:42 PM, Colin King  wrote:
> From: Colin Ian King 
>
> The checks to see if key->dst.s6_addr and key->src.s6_addr are null
> pointers are redundant because these are constant size arrays and
> so the checks always return true.  Fix this by removing the redundant
> checks.

> +   for (i = 0; i < 4; i++)

> +   filter->f.mask.tcp_spec.dst_ip[i] |=
> 
> cpu_to_be32(0x);

Can it be one line then?

> +   memcpy(>f.data.tcp_spec.dst_ip,
> +  >dst.s6_addr32,

Ditto.

> +  sizeof(filter->f.data.tcp_spec.dst_ip));
> +
> +   for (i = 0; i < 4; i++)

> +   filter->f.mask.tcp_spec.src_ip[i] |=
> 
> cpu_to_be32(0x);

Ditto.

> +   memcpy(>f.data.tcp_spec.src_ip,
> +  >src.s6_addr32,

Ditto.

> +  sizeof(filter->f.data.tcp_spec.src_ip));

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] i40evf: remove redundant array comparisons to 0 checks

[Andy Shevchenko]

On Thu, Feb 15, 2018 at 9:42 PM, Colin King  wrote:
> From: Colin Ian King 
>
> The checks to see if key->dst.s6_addr and key->src.s6_addr are null
> pointers are redundant because these are constant size arrays and
> so the checks always return true.  Fix this by removing the redundant
> checks.

> +   for (i = 0; i < 4; i++)

> +   filter->f.mask.tcp_spec.dst_ip[i] |=
> 
> cpu_to_be32(0x);

Can it be one line then?

> +   memcpy(>f.data.tcp_spec.dst_ip,
> +  >dst.s6_addr32,

Ditto.

> +  sizeof(filter->f.data.tcp_spec.dst_ip));
> +
> +   for (i = 0; i < 4; i++)

> +   filter->f.mask.tcp_spec.src_ip[i] |=
> 
> cpu_to_be32(0x);

Ditto.

> +   memcpy(>f.data.tcp_spec.src_ip,
> +  >src.s6_addr32,

Ditto.

> +  sizeof(filter->f.data.tcp_spec.src_ip));

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/7] sched: Add static_key for asymmetric cpu capacity optimizations

[Peter Zijlstra]

On Fri, Feb 16, 2018 at 03:41:01PM +, Morten Rasmussen wrote:
> On Fri, Feb 16, 2018 at 02:47:04PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 15, 2018 at 04:20:48PM +, Morten Rasmussen wrote:
> > > +static void update_asym_cpucapacity(int cpu)
> > > +{
> > > + if (!static_branch_unlikely(_asym_cpucapacity) &&
> > > + lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY))
> > > + static_branch_enable(_asym_cpucapacity);
> > > +}
> > 
> > That looks odd, why not just:
> > 
> > if (lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY))
> > static_branch_enable(_asym_cpucapacity);
> 
> I actually had that initially and then I misread the implementation of
> static_key_enable() as if it trigger the WARN_ON_ONCE() condition if I
> enable an already enabled static key. But I see now that it should be
> safe to do. 

Right, that WARN is there for when we use enable/disable on a key with a
value outside of [0,1].

> > ? possibly with:
> > 
> > else
> > static_branch_disable(_asym_cpucapacity);
> > 
> > if you want to play funny games :-)
> 
> I thought about that too. It could make certain hotplug scenarios even
> more expensive. I think we want the sched_asym_cpucapacity code to behave
> even if SD_ASYM_CPUCAPACITY isn't set anywhere, so the static key would
> be permanently from the point we detect asymmetry and leave it set. This
> would be in line with how the smt static key works.

Fair enough..

Re: [PATCH 1/7] sched: Add static_key for asymmetric cpu capacity optimizations

[Peter Zijlstra]

On Fri, Feb 16, 2018 at 03:41:01PM +, Morten Rasmussen wrote:
> On Fri, Feb 16, 2018 at 02:47:04PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 15, 2018 at 04:20:48PM +, Morten Rasmussen wrote:
> > > +static void update_asym_cpucapacity(int cpu)
> > > +{
> > > + if (!static_branch_unlikely(_asym_cpucapacity) &&
> > > + lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY))
> > > + static_branch_enable(_asym_cpucapacity);
> > > +}
> > 
> > That looks odd, why not just:
> > 
> > if (lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY))
> > static_branch_enable(_asym_cpucapacity);
> 
> I actually had that initially and then I misread the implementation of
> static_key_enable() as if it trigger the WARN_ON_ONCE() condition if I
> enable an already enabled static key. But I see now that it should be
> safe to do. 

Right, that WARN is there for when we use enable/disable on a key with a
value outside of [0,1].

> > ? possibly with:
> > 
> > else
> > static_branch_disable(_asym_cpucapacity);
> > 
> > if you want to play funny games :-)
> 
> I thought about that too. It could make certain hotplug scenarios even
> more expensive. I think we want the sched_asym_cpucapacity code to behave
> even if SD_ASYM_CPUCAPACITY isn't set anywhere, so the static key would
> be permanently from the point we detect asymmetry and leave it set. This
> would be in line with how the smt static key works.

Fair enough..

Re: udev USB autosupend whitelist (was Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version)

[Brian Norris]

+ Benson (and there are probably others that know better answers)

Hi,

On Fri, Feb 16, 2018 at 09:26:37AM +0100, Hans de Goede wrote:
> Going a bit off-topic here, so changed the subject.
> I will reply on topic in another mail.
> 
> On 16-02-18 03:27, Brian Norris wrote:
> > I use a set of udev rules that manually whitelist devices for
> > autosuspend. You can see it here:
> > 
> > https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
> > 
> > You'll find at least one Rome chip in there.
> 
> Oh, that is a very interesting link for the work I've been doing to
> improve Linux power-consumption in general:
> 
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> 
> I was actually planning on at least doing such a list for WWAN modems,
> for btusb my approach has been to just enable it everywhere
> (except for QCA devices as I got bugreports for those).
> 
> Note that I plan to eventually submit this whitelist to the
> udev rules which are part of systemd upstream, so if chromeos
> is using systemd too, this is something to be aware of for you.

Chrome OS does not currently use systemd, but thanks for the heads up.

> Question, is the white-listing of the root and rate-limiting
> hubs really necessary? I thought these have this enabled by default?

This list is old and maintained by several of my team, originating from
quite a ways back (i.e., much older kernels). It's quite possible that
some of it is redundant today.

> Also any caveats here I should be aware of?

That it's only maintained for the express purpose of Chrome{device}s?
There's no guarantee that there aren't platform issues with other
systems, for instance :)

I'm not really aware of any particular caveats otherwise.

Brian

Re: udev USB autosupend whitelist (was Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version)

[Brian Norris]

+ Benson (and there are probably others that know better answers)

Hi,

On Fri, Feb 16, 2018 at 09:26:37AM +0100, Hans de Goede wrote:
> Going a bit off-topic here, so changed the subject.
> I will reply on topic in another mail.
> 
> On 16-02-18 03:27, Brian Norris wrote:
> > I use a set of udev rules that manually whitelist devices for
> > autosuspend. You can see it here:
> > 
> > https://chromium.googlesource.com/chromiumos/platform2/+/43728a93f6de137006c6b92fbb2a7cc4f353c9bf/power_manager/udev/gen_autosuspend_rules.py#83
> > 
> > You'll find at least one Rome chip in there.
> 
> Oh, that is a very interesting link for the work I've been doing to
> improve Linux power-consumption in general:
> 
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> 
> I was actually planning on at least doing such a list for WWAN modems,
> for btusb my approach has been to just enable it everywhere
> (except for QCA devices as I got bugreports for those).
> 
> Note that I plan to eventually submit this whitelist to the
> udev rules which are part of systemd upstream, so if chromeos
> is using systemd too, this is something to be aware of for you.

Chrome OS does not currently use systemd, but thanks for the heads up.

> Question, is the white-listing of the root and rate-limiting
> hubs really necessary? I thought these have this enabled by default?

This list is old and maintained by several of my team, originating from
quite a ways back (i.e., much older kernels). It's quite possible that
some of it is redundant today.

> Also any caveats here I should be aware of?

That it's only maintained for the express purpose of Chrome{device}s?
There's no guarantee that there aren't platform issues with other
systems, for instance :)

I'm not really aware of any particular caveats otherwise.

Brian

[PATCH 2/6] ARM: davinci: update the nand driver names

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Since commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock
lookup table") we can no longer correctly lookup the nand clock when
booting in legacy mode. Said commit added a dev_id to the nand clock
which must match and it doesn't correspond with the device name which
is "davinci_nand" instead of "davinci-nand".

The driver name has been changed. Update the board files.

Fixes: d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup 
table")
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/board-da830-evm.c | 2 +-
 arch/arm/mach-davinci/board-da850-evm.c | 2 +-
 arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c | 2 +-
 arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c| 2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c| 2 +-
 arch/arm/mach-davinci/board-mityomapl138.c  | 2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c   | 2 +-
 arch/arm/mach-davinci/board-sffsdr.c| 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index f673cd7a6766..f8838c7b174b 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -348,7 +348,7 @@ static struct resource da830_evm_nand_resources[] = {
 };
 
 static struct platform_device da830_evm_nand_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 1,
.dev= {
.platform_data  = _evm_nand_pdata,
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index d898a94f6eae..828194045a2b 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -266,7 +266,7 @@ static struct resource da850_evm_nandflash_resource[] = {
 };
 
 static struct platform_device da850_evm_nandflash_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 1,
.dev= {
.platform_data  = _evm_nandflash_data,
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index e457f299cd44..58ca7f56e112 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -98,7 +98,7 @@ static struct resource davinci_nand_resources[] = {
 };
 
 static struct platform_device davinci_nand_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
 
.num_resources  = ARRAY_SIZE(davinci_nand_resources),
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c 
b/arch/arm/mach-davinci/board-dm355-leopard.c
index be997243447b..196238117f9a 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -93,7 +93,7 @@ static struct resource davinci_nand_resources[] = {
 };
 
 static struct platform_device davinci_nand_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
 
.num_resources  = ARRAY_SIZE(davinci_nand_resources),
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index e75741fb2c1d..563d66df480b 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -159,7 +159,7 @@ static struct resource davinci_nand_resources[] = {
 };
 
 static struct platform_device davinci_nand_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
.num_resources  = ARRAY_SIZE(davinci_nand_resources),
.resource   = davinci_nand_resources,
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 85e6fb33b1ee..e42ae2163c75 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -173,7 +173,7 @@ static struct resource davinci_evm_nandflash_resource[] = {
 };
 
 static struct platform_device davinci_evm_nandflash_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
.dev= {
.platform_data  = _evm_nandflash_data,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index cb0a41e83582..614dd211e6fc 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -108,7 +108,7 @@ static struct resource davinci_nand_resources[] = {
 };
 
 static struct platform_device 

[PATCH 2/6] ARM: davinci: update the nand driver names

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Since commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock
lookup table") we can no longer correctly lookup the nand clock when
booting in legacy mode. Said commit added a dev_id to the nand clock
which must match and it doesn't correspond with the device name which
is "davinci_nand" instead of "davinci-nand".

The driver name has been changed. Update the board files.

Fixes: d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup 
table")
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/board-da830-evm.c | 2 +-
 arch/arm/mach-davinci/board-da850-evm.c | 2 +-
 arch/arm/mach-davinci/board-dm355-evm.c | 2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c | 2 +-
 arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c| 2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c| 2 +-
 arch/arm/mach-davinci/board-mityomapl138.c  | 2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c   | 2 +-
 arch/arm/mach-davinci/board-sffsdr.c| 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index f673cd7a6766..f8838c7b174b 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -348,7 +348,7 @@ static struct resource da830_evm_nand_resources[] = {
 };
 
 static struct platform_device da830_evm_nand_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 1,
.dev= {
.platform_data  = _evm_nand_pdata,
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index d898a94f6eae..828194045a2b 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -266,7 +266,7 @@ static struct resource da850_evm_nandflash_resource[] = {
 };
 
 static struct platform_device da850_evm_nandflash_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 1,
.dev= {
.platform_data  = _evm_nandflash_data,
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index e457f299cd44..58ca7f56e112 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -98,7 +98,7 @@ static struct resource davinci_nand_resources[] = {
 };
 
 static struct platform_device davinci_nand_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
 
.num_resources  = ARRAY_SIZE(davinci_nand_resources),
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c 
b/arch/arm/mach-davinci/board-dm355-leopard.c
index be997243447b..196238117f9a 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -93,7 +93,7 @@ static struct resource davinci_nand_resources[] = {
 };
 
 static struct platform_device davinci_nand_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
 
.num_resources  = ARRAY_SIZE(davinci_nand_resources),
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index e75741fb2c1d..563d66df480b 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -159,7 +159,7 @@ static struct resource davinci_nand_resources[] = {
 };
 
 static struct platform_device davinci_nand_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
.num_resources  = ARRAY_SIZE(davinci_nand_resources),
.resource   = davinci_nand_resources,
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 85e6fb33b1ee..e42ae2163c75 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -173,7 +173,7 @@ static struct resource davinci_evm_nandflash_resource[] = {
 };
 
 static struct platform_device davinci_evm_nandflash_device = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.id = 0,
.dev= {
.platform_data  = _evm_nandflash_data,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index cb0a41e83582..614dd211e6fc 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -108,7 +108,7 @@ static struct resource davinci_nand_resources[] = {
 };
 
 static struct platform_device davinci_nand_device = {
-   .name   = 

[PATCH 3/6] memory: aemif: don't rely on kbuild for driver's name

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We want to use aemif from board files. Use a static name in the
driver's code.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/memory/ti-aemif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index 2744b1b91b57..588e58d40d1b 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -422,7 +422,7 @@ static struct platform_driver aemif_driver = {
.probe = aemif_probe,
.remove = aemif_remove,
.driver = {
-   .name = KBUILD_MODNAME,
+   .name = "ti-aemif",
.of_match_table = of_match_ptr(aemif_of_match),
},
 };
-- 
2.16.1

[PATCH 3/6] memory: aemif: don't rely on kbuild for driver's name

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We want to use aemif from board files. Use a static name in the
driver's code.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/memory/ti-aemif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index 2744b1b91b57..588e58d40d1b 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -422,7 +422,7 @@ static struct platform_driver aemif_driver = {
.probe = aemif_probe,
.remove = aemif_remove,
.driver = {
-   .name = KBUILD_MODNAME,
+   .name = "ti-aemif",
.of_match_table = of_match_ptr(aemif_of_match),
},
 };
-- 
2.16.1

[PATCH 6/6] ARM: davinci: use aemif platform driver in legacy mode for da850-evm

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We now support board files in aemif. Use the platform driver instead
of the handcrafted API in da850-evm.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/board-da850-evm.c | 93 ++---
 1 file changed, 51 insertions(+), 42 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 828194045a2b..88e1d00a1f56 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -185,16 +186,6 @@ static struct resource da850_evm_norflash_resource[] = {
},
 };
 
-static struct platform_device da850_evm_norflash_device = {
-   .name   = "physmap-flash",
-   .id = 0,
-   .dev= {
-   .platform_data  = _evm_norflash_data,
-   },
-   .num_resources  = 1,
-   .resource   = da850_evm_norflash_resource,
-};
-
 /* DA850/OMAP-L138 EVM includes a 512 MByte large-page NAND flash
  * (128K blocks). It may be used instead of the (default) SPI flash
  * to boot, using TI's tools to install the secondary boot loader
@@ -265,37 +256,58 @@ static struct resource da850_evm_nandflash_resource[] = {
},
 };
 
-static struct platform_device da850_evm_nandflash_device = {
-   .name   = "davinci-nand",
-   .id = 1,
-   .dev= {
-   .platform_data  = _evm_nandflash_data,
-   },
-   .num_resources  = ARRAY_SIZE(da850_evm_nandflash_resource),
-   .resource   = da850_evm_nandflash_resource,
+static struct resource da850_evm_aemif_resource[] = {
+   {
+   .start  = DA8XX_AEMIF_CTL_BASE,
+   .end= DA8XX_AEMIF_CTL_BASE + SZ_32K,
+   .flags  = IORESOURCE_MEM,
+   }
 };
 
-static struct platform_device *da850_evm_devices[] = {
-   _evm_nandflash_device,
-   _evm_norflash_device,
+static struct aemif_abus_data da850_evm_aemif_abus_data[] = {
+   {
+   .cs = 3,
+   }
 };
 
-#define DA8XX_AEMIF_CE2CFG_OFFSET  0x10
-#define DA8XX_AEMIF_ASIZE_16BIT0x1
-
-static void __init da850_evm_init_nor(void)
-{
-   void __iomem *aemif_addr;
-
-   aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
+static struct platform_device da850_evm_aemif_devices[] = {
+   {
+   .name   = "davinci-nand",
+   .id = 1,
+   .dev= {
+   .platform_data  = _evm_nandflash_data,
+   },
+   .num_resources  = ARRAY_SIZE(da850_evm_nandflash_resource),
+   .resource   = da850_evm_nandflash_resource,
+   },
+   {
+   .name   = "physmap-flash",
+   .id = 0,
+   .dev= {
+   .platform_data  = _evm_norflash_data,
+   },
+   .num_resources  = 1,
+   .resource   = da850_evm_norflash_resource,
+   }
+};
 
-   /* Configure data bus width of CS2 to 16 bit */
-   writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
-   DA8XX_AEMIF_ASIZE_16BIT,
-   aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
+static struct aemif_platform_data da850_evm_aemif_pdata = {
+   .cs_offset = 2,
+   .abus_data = da850_evm_aemif_abus_data,
+   .num_abus_data = ARRAY_SIZE(da850_evm_aemif_abus_data),
+   .sub_devices = da850_evm_aemif_devices,
+   .num_sub_devices = ARRAY_SIZE(da850_evm_aemif_devices),
+};
 
-   iounmap(aemif_addr);
-}
+static struct platform_device da850_evm_aemif_device = {
+   .name   = "ti-aemif",
+   .dev = {
+   .platform_data  = _evm_aemif_pdata,
+   },
+   .resource   = da850_evm_aemif_resource,
+   .num_resources  = ARRAY_SIZE(da850_evm_aemif_resource),
+   .id = -1,
+};
 
 static const short da850_evm_nand_pins[] = {
DA850_EMA_D_0, DA850_EMA_D_1, DA850_EMA_D_2, DA850_EMA_D_3,
@@ -338,13 +350,10 @@ static inline void da850_evm_setup_nor_nand(void)
pr_warn("%s: NOR mux setup failed: %d\n",
__func__, ret);
 
-   da850_evm_init_nor();
-
-   platform_add_devices(da850_evm_devices,
-   ARRAY_SIZE(da850_evm_devices));
-
-   if (davinci_aemif_setup(_evm_nandflash_device))
-   pr_warn("%s: Cannot configure AEMIF.\n", __func__);
+   ret = platform_device_register(_evm_aemif_device);
+   if (ret)
+   pr_warn("%s: registering aemif failed: %d\n",
+   __func__, ret);
}
 }
 
-- 
2.16.1

[PATCH 6/6] ARM: davinci: use aemif platform driver in legacy mode for da850-evm

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We now support board files in aemif. Use the platform driver instead
of the handcrafted API in da850-evm.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/board-da850-evm.c | 93 ++---
 1 file changed, 51 insertions(+), 42 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 828194045a2b..88e1d00a1f56 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -185,16 +186,6 @@ static struct resource da850_evm_norflash_resource[] = {
},
 };
 
-static struct platform_device da850_evm_norflash_device = {
-   .name   = "physmap-flash",
-   .id = 0,
-   .dev= {
-   .platform_data  = _evm_norflash_data,
-   },
-   .num_resources  = 1,
-   .resource   = da850_evm_norflash_resource,
-};
-
 /* DA850/OMAP-L138 EVM includes a 512 MByte large-page NAND flash
  * (128K blocks). It may be used instead of the (default) SPI flash
  * to boot, using TI's tools to install the secondary boot loader
@@ -265,37 +256,58 @@ static struct resource da850_evm_nandflash_resource[] = {
},
 };
 
-static struct platform_device da850_evm_nandflash_device = {
-   .name   = "davinci-nand",
-   .id = 1,
-   .dev= {
-   .platform_data  = _evm_nandflash_data,
-   },
-   .num_resources  = ARRAY_SIZE(da850_evm_nandflash_resource),
-   .resource   = da850_evm_nandflash_resource,
+static struct resource da850_evm_aemif_resource[] = {
+   {
+   .start  = DA8XX_AEMIF_CTL_BASE,
+   .end= DA8XX_AEMIF_CTL_BASE + SZ_32K,
+   .flags  = IORESOURCE_MEM,
+   }
 };
 
-static struct platform_device *da850_evm_devices[] = {
-   _evm_nandflash_device,
-   _evm_norflash_device,
+static struct aemif_abus_data da850_evm_aemif_abus_data[] = {
+   {
+   .cs = 3,
+   }
 };
 
-#define DA8XX_AEMIF_CE2CFG_OFFSET  0x10
-#define DA8XX_AEMIF_ASIZE_16BIT0x1
-
-static void __init da850_evm_init_nor(void)
-{
-   void __iomem *aemif_addr;
-
-   aemif_addr = ioremap(DA8XX_AEMIF_CTL_BASE, SZ_32K);
+static struct platform_device da850_evm_aemif_devices[] = {
+   {
+   .name   = "davinci-nand",
+   .id = 1,
+   .dev= {
+   .platform_data  = _evm_nandflash_data,
+   },
+   .num_resources  = ARRAY_SIZE(da850_evm_nandflash_resource),
+   .resource   = da850_evm_nandflash_resource,
+   },
+   {
+   .name   = "physmap-flash",
+   .id = 0,
+   .dev= {
+   .platform_data  = _evm_norflash_data,
+   },
+   .num_resources  = 1,
+   .resource   = da850_evm_norflash_resource,
+   }
+};
 
-   /* Configure data bus width of CS2 to 16 bit */
-   writel(readl(aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET) |
-   DA8XX_AEMIF_ASIZE_16BIT,
-   aemif_addr + DA8XX_AEMIF_CE2CFG_OFFSET);
+static struct aemif_platform_data da850_evm_aemif_pdata = {
+   .cs_offset = 2,
+   .abus_data = da850_evm_aemif_abus_data,
+   .num_abus_data = ARRAY_SIZE(da850_evm_aemif_abus_data),
+   .sub_devices = da850_evm_aemif_devices,
+   .num_sub_devices = ARRAY_SIZE(da850_evm_aemif_devices),
+};
 
-   iounmap(aemif_addr);
-}
+static struct platform_device da850_evm_aemif_device = {
+   .name   = "ti-aemif",
+   .dev = {
+   .platform_data  = _evm_aemif_pdata,
+   },
+   .resource   = da850_evm_aemif_resource,
+   .num_resources  = ARRAY_SIZE(da850_evm_aemif_resource),
+   .id = -1,
+};
 
 static const short da850_evm_nand_pins[] = {
DA850_EMA_D_0, DA850_EMA_D_1, DA850_EMA_D_2, DA850_EMA_D_3,
@@ -338,13 +350,10 @@ static inline void da850_evm_setup_nor_nand(void)
pr_warn("%s: NOR mux setup failed: %d\n",
__func__, ret);
 
-   da850_evm_init_nor();
-
-   platform_add_devices(da850_evm_devices,
-   ARRAY_SIZE(da850_evm_devices));
-
-   if (davinci_aemif_setup(_evm_nandflash_device))
-   pr_warn("%s: Cannot configure AEMIF.\n", __func__);
+   ret = platform_device_register(_evm_aemif_device);
+   if (ret)
+   pr_warn("%s: registering aemif failed: %d\n",
+   __func__, ret);
}
 }
 
-- 
2.16.1

[PATCH 5/6] ARM: davinci: add aemif & nand support to da850-lcdk in legacy mode

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We now have support for aemif & nand from board files. As an example
add support for nand to da850-lcdk in legacy mode.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/board-omapl138-hawk.c | 132 
 1 file changed, 132 insertions(+)

diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c 
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a3e78074be70..6a4f2c1d460d 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -16,6 +16,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 #include 
@@ -162,6 +167,129 @@ static __init void omapl138_hawk_mmc_init(void)
gpiod_remove_lookup_table(_gpios_table);
 }
 
+static struct mtd_partition omapl138_hawk_nandflash_partition[] = {
+   {
+   .name   = "u-boot env",
+   .offset = 0,
+   .size   = SZ_128K,
+   .mask_flags = MTD_WRITEABLE,
+},
+   {
+   .name   = "u-boot",
+   .offset = MTDPART_OFS_APPEND,
+   .size   = SZ_128K,
+   .mask_flags = MTD_WRITEABLE,
+   },
+   {
+   .name   = "free space",
+   .offset = MTDPART_OFS_APPEND,
+   .size   = MTDPART_SIZ_FULL,
+   .mask_flags = 0,
+   },
+};
+
+static struct davinci_aemif_timing omapl138_hawk_nandflash_timing = {
+   .wsetup = 24,
+   .wstrobe= 21,
+   .whold  = 14,
+   .rsetup = 19,
+   .rstrobe= 50,
+   .rhold  = 0,
+   .ta = 20,
+};
+
+static struct davinci_nand_pdata omapl138_hawk_nandflash_data = {
+   .parts  = omapl138_hawk_nandflash_partition,
+   .nr_parts   = ARRAY_SIZE(omapl138_hawk_nandflash_partition),
+   .ecc_mode   = NAND_ECC_HW,
+   .ecc_bits   = 4,
+   .bbt_options= NAND_BBT_USE_FLASH,
+   .options= NAND_BUSWIDTH_16,
+   .timing = _hawk_nandflash_timing,
+   .mask_chipsel   = 0,
+   .mask_ale   = 0,
+   .mask_cle   = 0,
+};
+
+static struct resource omapl138_hawk_nandflash_resource[] = {
+   {
+   .start  = DA8XX_AEMIF_CS3_BASE,
+   .end= DA8XX_AEMIF_CS3_BASE + SZ_32M,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = DA8XX_AEMIF_CTL_BASE,
+   .end= DA8XX_AEMIF_CTL_BASE + SZ_32K,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct resource omapl138_hawk_aemif_resource[] = {
+   {
+   .start  = DA8XX_AEMIF_CTL_BASE,
+   .end= DA8XX_AEMIF_CTL_BASE + SZ_32K,
+   .flags  = IORESOURCE_MEM,
+   }
+};
+
+static struct aemif_abus_data omapl138_hawk_aemif_abus_data[] = {
+   {
+   .cs = 3,
+   }
+};
+
+static struct platform_device omapl138_hawk_aemif_devices[] = {
+   {
+   .name   = "davinci-nand",
+   .id = 1,
+   .dev= {
+   .platform_data  = _hawk_nandflash_data,
+   },
+   .resource   = omapl138_hawk_nandflash_resource,
+   .num_resources  = ARRAY_SIZE(omapl138_hawk_nandflash_resource),
+   .id = 0,
+   }
+};
+
+static struct aemif_platform_data omapl138_hawk_aemif_pdata = {
+   .cs_offset = 2,
+   .abus_data = omapl138_hawk_aemif_abus_data,
+   .num_abus_data = ARRAY_SIZE(omapl138_hawk_aemif_abus_data),
+   .sub_devices = omapl138_hawk_aemif_devices,
+   .num_sub_devices = ARRAY_SIZE(omapl138_hawk_aemif_devices),
+};
+
+static struct platform_device omapl138_hawk_aemif_device = {
+   .name   = "ti-aemif",
+   .dev = {
+   .platform_data  = _hawk_aemif_pdata,
+   },
+   .resource   = omapl138_hawk_aemif_resource,
+   .num_resources  = ARRAY_SIZE(omapl138_hawk_aemif_resource),
+   .id = -1,
+};
+
+static const short omapl138_hawk_nand_pins[] = {
+   DA850_EMA_WAIT_1, DA850_NEMA_OE, DA850_NEMA_WE, DA850_NEMA_CS_3,
+   DA850_EMA_D_0, DA850_EMA_D_1, DA850_EMA_D_2, DA850_EMA_D_3,
+   DA850_EMA_D_4, DA850_EMA_D_5, DA850_EMA_D_6, DA850_EMA_D_7,
+   DA850_EMA_D_8, DA850_EMA_D_9, DA850_EMA_D_10, DA850_EMA_D_11,
+   DA850_EMA_D_12, DA850_EMA_D_13, DA850_EMA_D_14, DA850_EMA_D_15,
+   DA850_EMA_A_1, DA850_EMA_A_2,
+   -1
+};
+
+static int omapl138_hawk_register_aemif(void)
+{
+   int ret;
+
+   ret = davinci_cfg_reg_list(omapl138_hawk_nand_pins);
+   if (ret)
+   pr_warn("%s: NAND mux setup failed: %d\n", __func__, ret);
+
+   return 

[PATCH 5/6] ARM: davinci: add aemif & nand support to da850-lcdk in legacy mode

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

We now have support for aemif & nand from board files. As an example
add support for nand to da850-lcdk in legacy mode.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/board-omapl138-hawk.c | 132 
 1 file changed, 132 insertions(+)

diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c 
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a3e78074be70..6a4f2c1d460d 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -16,6 +16,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 
 #include 
@@ -162,6 +167,129 @@ static __init void omapl138_hawk_mmc_init(void)
gpiod_remove_lookup_table(_gpios_table);
 }
 
+static struct mtd_partition omapl138_hawk_nandflash_partition[] = {
+   {
+   .name   = "u-boot env",
+   .offset = 0,
+   .size   = SZ_128K,
+   .mask_flags = MTD_WRITEABLE,
+},
+   {
+   .name   = "u-boot",
+   .offset = MTDPART_OFS_APPEND,
+   .size   = SZ_128K,
+   .mask_flags = MTD_WRITEABLE,
+   },
+   {
+   .name   = "free space",
+   .offset = MTDPART_OFS_APPEND,
+   .size   = MTDPART_SIZ_FULL,
+   .mask_flags = 0,
+   },
+};
+
+static struct davinci_aemif_timing omapl138_hawk_nandflash_timing = {
+   .wsetup = 24,
+   .wstrobe= 21,
+   .whold  = 14,
+   .rsetup = 19,
+   .rstrobe= 50,
+   .rhold  = 0,
+   .ta = 20,
+};
+
+static struct davinci_nand_pdata omapl138_hawk_nandflash_data = {
+   .parts  = omapl138_hawk_nandflash_partition,
+   .nr_parts   = ARRAY_SIZE(omapl138_hawk_nandflash_partition),
+   .ecc_mode   = NAND_ECC_HW,
+   .ecc_bits   = 4,
+   .bbt_options= NAND_BBT_USE_FLASH,
+   .options= NAND_BUSWIDTH_16,
+   .timing = _hawk_nandflash_timing,
+   .mask_chipsel   = 0,
+   .mask_ale   = 0,
+   .mask_cle   = 0,
+};
+
+static struct resource omapl138_hawk_nandflash_resource[] = {
+   {
+   .start  = DA8XX_AEMIF_CS3_BASE,
+   .end= DA8XX_AEMIF_CS3_BASE + SZ_32M,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = DA8XX_AEMIF_CTL_BASE,
+   .end= DA8XX_AEMIF_CTL_BASE + SZ_32K,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct resource omapl138_hawk_aemif_resource[] = {
+   {
+   .start  = DA8XX_AEMIF_CTL_BASE,
+   .end= DA8XX_AEMIF_CTL_BASE + SZ_32K,
+   .flags  = IORESOURCE_MEM,
+   }
+};
+
+static struct aemif_abus_data omapl138_hawk_aemif_abus_data[] = {
+   {
+   .cs = 3,
+   }
+};
+
+static struct platform_device omapl138_hawk_aemif_devices[] = {
+   {
+   .name   = "davinci-nand",
+   .id = 1,
+   .dev= {
+   .platform_data  = _hawk_nandflash_data,
+   },
+   .resource   = omapl138_hawk_nandflash_resource,
+   .num_resources  = ARRAY_SIZE(omapl138_hawk_nandflash_resource),
+   .id = 0,
+   }
+};
+
+static struct aemif_platform_data omapl138_hawk_aemif_pdata = {
+   .cs_offset = 2,
+   .abus_data = omapl138_hawk_aemif_abus_data,
+   .num_abus_data = ARRAY_SIZE(omapl138_hawk_aemif_abus_data),
+   .sub_devices = omapl138_hawk_aemif_devices,
+   .num_sub_devices = ARRAY_SIZE(omapl138_hawk_aemif_devices),
+};
+
+static struct platform_device omapl138_hawk_aemif_device = {
+   .name   = "ti-aemif",
+   .dev = {
+   .platform_data  = _hawk_aemif_pdata,
+   },
+   .resource   = omapl138_hawk_aemif_resource,
+   .num_resources  = ARRAY_SIZE(omapl138_hawk_aemif_resource),
+   .id = -1,
+};
+
+static const short omapl138_hawk_nand_pins[] = {
+   DA850_EMA_WAIT_1, DA850_NEMA_OE, DA850_NEMA_WE, DA850_NEMA_CS_3,
+   DA850_EMA_D_0, DA850_EMA_D_1, DA850_EMA_D_2, DA850_EMA_D_3,
+   DA850_EMA_D_4, DA850_EMA_D_5, DA850_EMA_D_6, DA850_EMA_D_7,
+   DA850_EMA_D_8, DA850_EMA_D_9, DA850_EMA_D_10, DA850_EMA_D_11,
+   DA850_EMA_D_12, DA850_EMA_D_13, DA850_EMA_D_14, DA850_EMA_D_15,
+   DA850_EMA_A_1, DA850_EMA_A_2,
+   -1
+};
+
+static int omapl138_hawk_register_aemif(void)
+{
+   int ret;
+
+   ret = davinci_cfg_reg_list(omapl138_hawk_nand_pins);
+   if (ret)
+   pr_warn("%s: NAND mux setup failed: %d\n", __func__, ret);
+
+   return platform_device_register(_hawk_aemif_device);
+}
+
 static irqreturn_t 

Re: [PATCH v2] ASoC: dmic: Add optional wakeup delay

[Matthias Kaehlcke]

El Thu, Feb 15, 2018 at 06:47:29PM -0800 Brian Norris ha dit:

> Hi,
> 
> On Thu, Feb 15, 2018 at 06:24:16PM -0800, Matthias Kaehlcke wrote:
> > On some systems a delay is needed after switching on the clocks, to allow
> > the output to stabilize and avoid a popping noise at the beginning of
> > the recording. Add the optional device tree property 'wakeup-delay-ms'
> > and apply the specified delay after enabling the mic. A blocking delay
> > can't be applied in dmic_daiops_trigger() since the function is called
> > in atomic context. Instead use a DAPM event handler to set the enable
> > GPIO and apply the delay in the handler.
> > 
> > Signed-off-by: Matthias Kaehlcke 
> > ---
> > Changes in v2:
> > - use DAPM event handler instead of _prepare() and get rid of
> >   _trigger()
> > - skip error check for optional 'wakeup-delay-ms' property
> > - updated commit message
> 
> Looks good to me in general:
> 
> Brian Norris 
> 
> But I don't know much about the audio subsystem. One comment below.
> 
> > 
> >  .../devicetree/bindings/sound/dmic.txt|  2 +
> >  sound/soc/codecs/dmic.c   | 63 ++-
> >  2 files changed, 37 insertions(+), 28 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/sound/dmic.txt 
> > b/Documentation/devicetree/bindings/sound/dmic.txt
> > index f7bf65611453..e957b4136716 100644
> > --- a/Documentation/devicetree/bindings/sound/dmic.txt
> > +++ b/Documentation/devicetree/bindings/sound/dmic.txt
> > @@ -8,6 +8,7 @@ Required properties:
> >  Optional properties:
> > - dmicen-gpios: GPIO specifier for dmic to control start and stop
> > - num-channels: Number of microphones on this DAI
> > +   - wakeup-delay-ms: Delay (in ms) after enabling the DMIC
> >  
> >  Example node:
> >  
> > @@ -15,4 +16,5 @@ Example node:
> > compatible = "dmic-codec";
> > dmicen-gpios = < 3 GPIO_ACTIVE_HIGH>;
> > num-channels = <1>;
> > +   wakeup-delay-ms <50>;
> > };
> > diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
> > index cf83c423394d..b5f60ac22ace 100644
> > --- a/sound/soc/codecs/dmic.c
> > +++ b/sound/soc/codecs/dmic.c
> [...]
> 
> >  static const struct snd_soc_dapm_widget dmic_dapm_widgets[] = {
> > -   SND_SOC_DAPM_AIF_OUT("DMIC AIF", "Capture", 0,
> > -SND_SOC_NOPM, 0, 0),
> > +   SND_SOC_DAPM_AIF_OUT_E("DMIC AIF", "Capture", 0,
> > +  SND_SOC_NOPM, 0, 0, dmic_aif_event,
> > +  SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
> 
> Any good reason both are _POST_? It seems like you'd want them to be
> inverses (e.g., power-power-up, and pre-power-down).

Post-power-up is needed to avoid a popping noise when the clock is
enabled (see 3a6f9dce6116 ("ASoC: rk3399_gru_sound: fix recording pop
at first attempt") and disabling the mic before switching off the
clock (pre-power-down) could cause noise at the end of the recording.

Re: [PATCH v2] ASoC: dmic: Add optional wakeup delay

[Matthias Kaehlcke]

El Thu, Feb 15, 2018 at 06:47:29PM -0800 Brian Norris ha dit:

> Hi,
> 
> On Thu, Feb 15, 2018 at 06:24:16PM -0800, Matthias Kaehlcke wrote:
> > On some systems a delay is needed after switching on the clocks, to allow
> > the output to stabilize and avoid a popping noise at the beginning of
> > the recording. Add the optional device tree property 'wakeup-delay-ms'
> > and apply the specified delay after enabling the mic. A blocking delay
> > can't be applied in dmic_daiops_trigger() since the function is called
> > in atomic context. Instead use a DAPM event handler to set the enable
> > GPIO and apply the delay in the handler.
> > 
> > Signed-off-by: Matthias Kaehlcke 
> > ---
> > Changes in v2:
> > - use DAPM event handler instead of _prepare() and get rid of
> >   _trigger()
> > - skip error check for optional 'wakeup-delay-ms' property
> > - updated commit message
> 
> Looks good to me in general:
> 
> Brian Norris 
> 
> But I don't know much about the audio subsystem. One comment below.
> 
> > 
> >  .../devicetree/bindings/sound/dmic.txt|  2 +
> >  sound/soc/codecs/dmic.c   | 63 ++-
> >  2 files changed, 37 insertions(+), 28 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/sound/dmic.txt 
> > b/Documentation/devicetree/bindings/sound/dmic.txt
> > index f7bf65611453..e957b4136716 100644
> > --- a/Documentation/devicetree/bindings/sound/dmic.txt
> > +++ b/Documentation/devicetree/bindings/sound/dmic.txt
> > @@ -8,6 +8,7 @@ Required properties:
> >  Optional properties:
> > - dmicen-gpios: GPIO specifier for dmic to control start and stop
> > - num-channels: Number of microphones on this DAI
> > +   - wakeup-delay-ms: Delay (in ms) after enabling the DMIC
> >  
> >  Example node:
> >  
> > @@ -15,4 +16,5 @@ Example node:
> > compatible = "dmic-codec";
> > dmicen-gpios = < 3 GPIO_ACTIVE_HIGH>;
> > num-channels = <1>;
> > +   wakeup-delay-ms <50>;
> > };
> > diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
> > index cf83c423394d..b5f60ac22ace 100644
> > --- a/sound/soc/codecs/dmic.c
> > +++ b/sound/soc/codecs/dmic.c
> [...]
> 
> >  static const struct snd_soc_dapm_widget dmic_dapm_widgets[] = {
> > -   SND_SOC_DAPM_AIF_OUT("DMIC AIF", "Capture", 0,
> > -SND_SOC_NOPM, 0, 0),
> > +   SND_SOC_DAPM_AIF_OUT_E("DMIC AIF", "Capture", 0,
> > +  SND_SOC_NOPM, 0, 0, dmic_aif_event,
> > +  SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
> 
> Any good reason both are _POST_? It seems like you'd want them to be
> inverses (e.g., power-power-up, and pre-power-down).

Post-power-up is needed to avoid a popping noise when the clock is
enabled (see 3a6f9dce6116 ("ASoC: rk3399_gru_sound: fix recording pop
at first attempt") and disabling the mic before switching off the
clock (pre-power-down) could cause noise at the end of the recording.

[PATCH 4/6] memory: aemif: add support for board files

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Currently aemif is supported in two places separately. By the platform
driver in drivers/memory and by a hand crafted driver in mach-davinci.

We want to drop the latter but also keep the legacy mode. Add support
for board files to the aemif driver.

The new structure in platform data currently only contains the chip
select number, since currently existing users don't require anything
else, but it can be extended in the future.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/memory/ti-aemif.c  | 57 ++
 include/linux/platform_data/ti-aemif.h |  9 ++
 2 files changed, 46 insertions(+), 20 deletions(-)

diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index 588e58d40d1b..27d2b076f465 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -339,9 +339,6 @@ static int aemif_probe(struct platform_device *pdev)
struct aemif_platform_data *pdata;
struct of_dev_auxdata *dev_lookup;
 
-   if (np == NULL)
-   return 0;
-
aemif = devm_kzalloc(dev, sizeof(*aemif), GFP_KERNEL);
if (!aemif)
return -ENOMEM;
@@ -363,8 +360,10 @@ static int aemif_probe(struct platform_device *pdev)
 
aemif->clk_rate = clk_get_rate(aemif->clk) / MSEC_PER_SEC;
 
-   if (of_device_is_compatible(np, "ti,da850-aemif"))
+   if (np && of_device_is_compatible(np, "ti,da850-aemif"))
aemif->cs_offset = 2;
+   else if (pdata)
+   aemif->cs_offset = pdata->cs_offset;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
aemif->base = devm_ioremap_resource(dev, res);
@@ -373,15 +372,23 @@ static int aemif_probe(struct platform_device *pdev)
goto error;
}
 
-   /*
-* For every controller device node, there is a cs device node that
-* describe the bus configuration parameters. This functions iterate
-* over these nodes and update the cs data array.
-*/
-   for_each_available_child_of_node(np, child_np) {
-   ret = of_aemif_parse_abus_config(pdev, child_np);
-   if (ret < 0)
-   goto error;
+   if (np) {
+   /*
+* For every controller device node, there is a cs device node
+* that describe the bus configuration parameters. This
+* functions iterate over these nodes and update the cs data
+* array.
+*/
+   for_each_available_child_of_node(np, child_np) {
+   ret = of_aemif_parse_abus_config(pdev, child_np);
+   if (ret < 0)
+   goto error;
+   }
+   } else if (pdata && pdata->num_abus_data > 0) {
+   for (i = 0; i < pdata->num_abus_data; i++, aemif->num_cs++) {
+   aemif->cs_data[i].cs = pdata->abus_data->cs;
+   aemif_get_hw_params(pdev, i);
+   }
}
 
for (i = 0; i < aemif->num_cs; i++) {
@@ -394,14 +401,24 @@ static int aemif_probe(struct platform_device *pdev)
}
 
/*
-* Create a child devices explicitly from here to
-* guarantee that the child will be probed after the AEMIF timing
-* parameters are set.
+* Create a child devices explicitly from here to guarantee that the
+* child will be probed after the AEMIF timing parameters are set.
 */
-   for_each_available_child_of_node(np, child_np) {
-   ret = of_platform_populate(child_np, NULL, dev_lookup, dev);
-   if (ret < 0)
-   goto error;
+   if (np) {
+   for_each_available_child_of_node(np, child_np) {
+   ret = of_platform_populate(child_np, NULL,
+  dev_lookup, dev);
+   if (ret < 0)
+   goto error;
+   }
+   } else {
+   for (i = 0; i < pdata->num_sub_devices; i++) {
+   ret = platform_device_register(>sub_devices[i]);
+   if (ret) {
+   dev_warn(dev, "Error register sub device %s\n",
+pdata->sub_devices[i].name);
+   }
+   }
}
 
return 0;
diff --git a/include/linux/platform_data/ti-aemif.h 
b/include/linux/platform_data/ti-aemif.h
index ac72e115093c..dfe8901128c9 100644
--- a/include/linux/platform_data/ti-aemif.h
+++ b/include/linux/platform_data/ti-aemif.h
@@ -16,8 +16,17 @@
 
 #include 
 
+struct aemif_abus_data {
+   u32 cs;
+};
+
 struct aemif_platform_data {
struct of_dev_auxdata *dev_lookup;
+   u32 cs_offset;
+   struct aemif_abus_data *abus_data;
+   size_t num_abus_data;
+   

[PATCH 4/6] memory: aemif: add support for board files

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Currently aemif is supported in two places separately. By the platform
driver in drivers/memory and by a hand crafted driver in mach-davinci.

We want to drop the latter but also keep the legacy mode. Add support
for board files to the aemif driver.

The new structure in platform data currently only contains the chip
select number, since currently existing users don't require anything
else, but it can be extended in the future.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/memory/ti-aemif.c  | 57 ++
 include/linux/platform_data/ti-aemif.h |  9 ++
 2 files changed, 46 insertions(+), 20 deletions(-)

diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index 588e58d40d1b..27d2b076f465 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -339,9 +339,6 @@ static int aemif_probe(struct platform_device *pdev)
struct aemif_platform_data *pdata;
struct of_dev_auxdata *dev_lookup;
 
-   if (np == NULL)
-   return 0;
-
aemif = devm_kzalloc(dev, sizeof(*aemif), GFP_KERNEL);
if (!aemif)
return -ENOMEM;
@@ -363,8 +360,10 @@ static int aemif_probe(struct platform_device *pdev)
 
aemif->clk_rate = clk_get_rate(aemif->clk) / MSEC_PER_SEC;
 
-   if (of_device_is_compatible(np, "ti,da850-aemif"))
+   if (np && of_device_is_compatible(np, "ti,da850-aemif"))
aemif->cs_offset = 2;
+   else if (pdata)
+   aemif->cs_offset = pdata->cs_offset;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
aemif->base = devm_ioremap_resource(dev, res);
@@ -373,15 +372,23 @@ static int aemif_probe(struct platform_device *pdev)
goto error;
}
 
-   /*
-* For every controller device node, there is a cs device node that
-* describe the bus configuration parameters. This functions iterate
-* over these nodes and update the cs data array.
-*/
-   for_each_available_child_of_node(np, child_np) {
-   ret = of_aemif_parse_abus_config(pdev, child_np);
-   if (ret < 0)
-   goto error;
+   if (np) {
+   /*
+* For every controller device node, there is a cs device node
+* that describe the bus configuration parameters. This
+* functions iterate over these nodes and update the cs data
+* array.
+*/
+   for_each_available_child_of_node(np, child_np) {
+   ret = of_aemif_parse_abus_config(pdev, child_np);
+   if (ret < 0)
+   goto error;
+   }
+   } else if (pdata && pdata->num_abus_data > 0) {
+   for (i = 0; i < pdata->num_abus_data; i++, aemif->num_cs++) {
+   aemif->cs_data[i].cs = pdata->abus_data->cs;
+   aemif_get_hw_params(pdev, i);
+   }
}
 
for (i = 0; i < aemif->num_cs; i++) {
@@ -394,14 +401,24 @@ static int aemif_probe(struct platform_device *pdev)
}
 
/*
-* Create a child devices explicitly from here to
-* guarantee that the child will be probed after the AEMIF timing
-* parameters are set.
+* Create a child devices explicitly from here to guarantee that the
+* child will be probed after the AEMIF timing parameters are set.
 */
-   for_each_available_child_of_node(np, child_np) {
-   ret = of_platform_populate(child_np, NULL, dev_lookup, dev);
-   if (ret < 0)
-   goto error;
+   if (np) {
+   for_each_available_child_of_node(np, child_np) {
+   ret = of_platform_populate(child_np, NULL,
+  dev_lookup, dev);
+   if (ret < 0)
+   goto error;
+   }
+   } else {
+   for (i = 0; i < pdata->num_sub_devices; i++) {
+   ret = platform_device_register(>sub_devices[i]);
+   if (ret) {
+   dev_warn(dev, "Error register sub device %s\n",
+pdata->sub_devices[i].name);
+   }
+   }
}
 
return 0;
diff --git a/include/linux/platform_data/ti-aemif.h 
b/include/linux/platform_data/ti-aemif.h
index ac72e115093c..dfe8901128c9 100644
--- a/include/linux/platform_data/ti-aemif.h
+++ b/include/linux/platform_data/ti-aemif.h
@@ -16,8 +16,17 @@
 
 #include 
 
+struct aemif_abus_data {
+   u32 cs;
+};
+
 struct aemif_platform_data {
struct of_dev_auxdata *dev_lookup;
+   u32 cs_offset;
+   struct aemif_abus_data *abus_data;
+   size_t num_abus_data;
+   struct platform_device *sub_devices;
+   size_t 

Re: [PATCH] objtool/x86: Replace Non-standard Range Expression in Case

[Peter Zijlstra]

On Fri, Feb 16, 2018 at 08:35:11AM -0600, Josh Poimboeuf wrote:
> On Fri, Feb 16, 2018 at 07:55:13PM +0530, Progyan Bhattacharya wrote:
> > Replace range expressions with seperate individual cases, i.e. convert case 
> > 1...3: to case 1: case 2: case 3
> > Range expression within case statements are non-standard C code and can 
> > create issues over compiler and platform variety.
> > 
> > While compiling with gcc 4.8 (RHEL) I encountered this error on range 
> > expression in case statements:
> > error: range expressions in switch statements are non-standard 
> > [-Werror=pedantic]
> > 
> > Signed-off-by: Progyan Bhattacharya 
> 
> Hi Progyan,
> 
> Thank you for the patch.
> 
> I think this makes the code unnecessarily verbose and less readable.  We
> rely on many such GCC extensions, and we don't aim to comply with
> standard C.  And AFAIK, we don't use -Werror=pedantic in the kernel.

Agreed, it makes the code actively worse. Just don't use error=pedantic.

Re: [PATCH] objtool/x86: Replace Non-standard Range Expression in Case

[Peter Zijlstra]

On Fri, Feb 16, 2018 at 08:35:11AM -0600, Josh Poimboeuf wrote:
> On Fri, Feb 16, 2018 at 07:55:13PM +0530, Progyan Bhattacharya wrote:
> > Replace range expressions with seperate individual cases, i.e. convert case 
> > 1...3: to case 1: case 2: case 3
> > Range expression within case statements are non-standard C code and can 
> > create issues over compiler and platform variety.
> > 
> > While compiling with gcc 4.8 (RHEL) I encountered this error on range 
> > expression in case statements:
> > error: range expressions in switch statements are non-standard 
> > [-Werror=pedantic]
> > 
> > Signed-off-by: Progyan Bhattacharya 
> 
> Hi Progyan,
> 
> Thank you for the patch.
> 
> I think this makes the code unnecessarily verbose and less readable.  We
> rely on many such GCC extensions, and we don't aim to comply with
> standard C.  And AFAIK, we don't use -Werror=pedantic in the kernel.

Agreed, it makes the code actively worse. Just don't use error=pedantic.

[PATCH 0/6] ARM: davinci: remove the mach-specific aemif driver - part 1

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Hi Sekhar,

while waiting for David's updated series I prepared the first part of
changes required to remove duplicate aemif support from mach-davinci.

I actually noticed that one of my previous changes from 2017 broke nand
in legacy mode - the clock lookup no longer works. This series addresses
it as well.

The first two patches fix the issue introduced in commit d8e22fb4ccac
("ARM: da850: add the nand dev_id to the clock lookup table").

Next two add support for board files to the aemif driver.

Last two add nand support to da850-lcdk in legacy mode and make
da850-evm use the platform driver instead of the mach-specific one.

If this series gets accepted, I'll prepere a follow-up moving all
other boards to the new platform driver.

Bartosz Golaszewski (6):
  nand: davinci: rename the platform driver
  ARM: davinci: update the nand driver names
  memory: aemif: don't rely on kbuild for driver's name
  memory: aemif: add support for board files
  ARM: davinci: add aemif & nand support to da850-lcdk in legacy mode
  ARM: davinci: use aemif platform driver in legacy mode for da850-evm

 arch/arm/mach-davinci/board-da830-evm.c |   2 +-
 arch/arm/mach-davinci/board-da850-evm.c |  93 +++-
 arch/arm/mach-davinci/board-dm355-evm.c |   2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c |   2 +-
 arch/arm/mach-davinci/board-dm365-evm.c |   2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c|   2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c|   2 +-
 arch/arm/mach-davinci/board-mityomapl138.c  |   2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c   |   2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c | 132 
 arch/arm/mach-davinci/board-sffsdr.c|   2 +-
 drivers/memory/ti-aemif.c   |  59 -
 drivers/mtd/nand/davinci_nand.c |   2 +-
 include/linux/platform_data/ti-aemif.h  |   9 ++
 14 files changed, 240 insertions(+), 73 deletions(-)

-- 
2.16.1

[PATCH 0/6] ARM: davinci: remove the mach-specific aemif driver - part 1

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Hi Sekhar,

while waiting for David's updated series I prepared the first part of
changes required to remove duplicate aemif support from mach-davinci.

I actually noticed that one of my previous changes from 2017 broke nand
in legacy mode - the clock lookup no longer works. This series addresses
it as well.

The first two patches fix the issue introduced in commit d8e22fb4ccac
("ARM: da850: add the nand dev_id to the clock lookup table").

Next two add support for board files to the aemif driver.

Last two add nand support to da850-lcdk in legacy mode and make
da850-evm use the platform driver instead of the mach-specific one.

If this series gets accepted, I'll prepere a follow-up moving all
other boards to the new platform driver.

Bartosz Golaszewski (6):
  nand: davinci: rename the platform driver
  ARM: davinci: update the nand driver names
  memory: aemif: don't rely on kbuild for driver's name
  memory: aemif: add support for board files
  ARM: davinci: add aemif & nand support to da850-lcdk in legacy mode
  ARM: davinci: use aemif platform driver in legacy mode for da850-evm

 arch/arm/mach-davinci/board-da830-evm.c |   2 +-
 arch/arm/mach-davinci/board-da850-evm.c |  93 +++-
 arch/arm/mach-davinci/board-dm355-evm.c |   2 +-
 arch/arm/mach-davinci/board-dm355-leopard.c |   2 +-
 arch/arm/mach-davinci/board-dm365-evm.c |   2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c|   2 +-
 arch/arm/mach-davinci/board-dm646x-evm.c|   2 +-
 arch/arm/mach-davinci/board-mityomapl138.c  |   2 +-
 arch/arm/mach-davinci/board-neuros-osd2.c   |   2 +-
 arch/arm/mach-davinci/board-omapl138-hawk.c | 132 
 arch/arm/mach-davinci/board-sffsdr.c|   2 +-
 drivers/memory/ti-aemif.c   |  59 -
 drivers/mtd/nand/davinci_nand.c |   2 +-
 include/linux/platform_data/ti-aemif.h  |   9 ++
 14 files changed, 240 insertions(+), 73 deletions(-)

-- 
2.16.1

[PATCH 1/6] nand: davinci: rename the platform driver

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock
lookup table") broke the nand support in board file mode for
da850-based boards. Instead of reverting it and breaking the DT users
in the process (due to clock lookup), rename the driver to match the
clock table before renaming the users.

Fixes: d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup 
table")
Signed-off-by: Bartosz Golaszewski 
---
 drivers/mtd/nand/davinci_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index ccc8c43abcff..4fb143bf1872 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -865,7 +865,7 @@ static struct platform_driver nand_davinci_driver = {
.probe  = nand_davinci_probe,
.remove = nand_davinci_remove,
.driver = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.of_match_table = of_match_ptr(davinci_nand_of_match),
},
 };
-- 
2.16.1

[PATCH 1/6] nand: davinci: rename the platform driver

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock
lookup table") broke the nand support in board file mode for
da850-based boards. Instead of reverting it and breaking the DT users
in the process (due to clock lookup), rename the driver to match the
clock table before renaming the users.

Fixes: d8e22fb4ccac ("ARM: da850: add the nand dev_id to the clock lookup 
table")
Signed-off-by: Bartosz Golaszewski 
---
 drivers/mtd/nand/davinci_nand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index ccc8c43abcff..4fb143bf1872 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -865,7 +865,7 @@ static struct platform_driver nand_davinci_driver = {
.probe  = nand_davinci_probe,
.remove = nand_davinci_remove,
.driver = {
-   .name   = "davinci_nand",
+   .name   = "davinci-nand",
.of_match_table = of_match_ptr(davinci_nand_of_match),
},
 };
-- 
2.16.1

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

[Christian Gmeiner]

2018-02-06 2:20 GMT+01:00 Dmitry Torokhov :
> On Mon, Feb 05, 2018 at 11:07:08AM +0100, Christian Gmeiner wrote:
>> Hi all.
>>
>> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger 
>> :
>> > The device could as well be in command mode, in which this driver cannot
>> > handle the device. When opening the device, let's make sure the device
>> > will be in the mode we expect it to be for this driver.
>> >
>>
>> I run into issues caused by this change. It turns out that the device
>> is non-functional
>> after some warm-reboots and as a result I am not able to use xorg's
>> evdev driver.
>> So I have some questions about this change:
>>
>> * Should we enable irq before calling i2c_master_send(..) as the chip raises 
>> an
>>   irq if the command was processed?
>
> Well, we do not care about the response... However, what is your
> interrupt trigger settings? Are you using edge by chance? If so, please
> try switching to level.
>

We may should take care of the response. I have seen strange responses
after the third open of the device.

 {
   ar1021@4d {
   compatible = "microchip,ar1021-i2c";
   reg = <0x4d>;
   interrupt-parent = <>;
   interrupts = <26 IRQ_TYPE_EDGE_RISING>;
   };
};

I am not sure if this is really the cause of the problem! As without this commit
my device survives one week of a automated touch-press-test done with some
mechanical gear and with the help of an SPS.

>>
>> * Would it be enough to send this command only once during driver
>> lifetime? I can
>>   see that on my system open gets called 3 times during boot-up.
>>
>> * What are the circumstances the touch device would be in an other state? In 
>> the
>>   official kernel driver the userspace can send commands via sysfs.
>> Also the driver
>>   does set the touch enable mode as this patch does.
>
> What is "the official kernel driver"?
>

http://ww1.microchip.com/downloads/en/DeviceDoc/AR1020-AR1021-LINUX-SPI-I2C-V102.tar.gz

As it is release time at my company I had to stop finding the root
cause but will look into the issue
again in 2-3 weeks.


-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

[Christian Gmeiner]

2018-02-06 2:20 GMT+01:00 Dmitry Torokhov :
> On Mon, Feb 05, 2018 at 11:07:08AM +0100, Christian Gmeiner wrote:
>> Hi all.
>>
>> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger 
>> :
>> > The device could as well be in command mode, in which this driver cannot
>> > handle the device. When opening the device, let's make sure the device
>> > will be in the mode we expect it to be for this driver.
>> >
>>
>> I run into issues caused by this change. It turns out that the device
>> is non-functional
>> after some warm-reboots and as a result I am not able to use xorg's
>> evdev driver.
>> So I have some questions about this change:
>>
>> * Should we enable irq before calling i2c_master_send(..) as the chip raises 
>> an
>>   irq if the command was processed?
>
> Well, we do not care about the response... However, what is your
> interrupt trigger settings? Are you using edge by chance? If so, please
> try switching to level.
>

We may should take care of the response. I have seen strange responses
after the third open of the device.

 {
   ar1021@4d {
   compatible = "microchip,ar1021-i2c";
   reg = <0x4d>;
   interrupt-parent = <>;
   interrupts = <26 IRQ_TYPE_EDGE_RISING>;
   };
};

I am not sure if this is really the cause of the problem! As without this commit
my device survives one week of a automated touch-press-test done with some
mechanical gear and with the help of an SPS.

>>
>> * Would it be enough to send this command only once during driver
>> lifetime? I can
>>   see that on my system open gets called 3 times during boot-up.
>>
>> * What are the circumstances the touch device would be in an other state? In 
>> the
>>   official kernel driver the userspace can send commands via sysfs.
>> Also the driver
>>   does set the touch enable mode as this patch does.
>
> What is "the official kernel driver"?
>

http://ww1.microchip.com/downloads/en/DeviceDoc/AR1020-AR1021-LINUX-SPI-I2C-V102.tar.gz

As it is release time at my company I had to stop finding the root
cause but will look into the issue
again in 2-3 weeks.


-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info

Re: [PATCH] Staging: wlan-ng: Fix Alignment should match open paranthesis in prism2mgmt.c

[Joe Perches]

On Fri, 2018-02-16 at 15:36 +0100, Greg KH wrote:
> On Fri, Feb 16, 2018 at 12:18:36AM +0530, Yash Omer wrote:
> > This is patch fixes up a matching paranthesis alignment issue found by 
> > checkpatch.pl script.
[]
> > diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
> > b/drivers/staging/wlan-ng/prism2mgmt.c
[]
> > @@ -264,8 +264,8 @@ int prism2mgmt_scan(struct wlandevice *wlandev, void 
> > *msgp)
> > goto exit;
> > }
> > /* ibss options */
> > -   result = hfa384x_drvr_setconfig16(hw,
> > -   HFA384x_RID_CREATEIBSS,
> > +   result = hfa384x_drvr_setconfig16
> > +   (hw, HFA384x_RID_CREATEIBSS,
> 
> The original code is just fine, why is checkpatch complaining about
> this?

lack of argument alignment to parentheses.

Maybe wlan-ng should be marked obsolete in MAINTAINERS.

Re: [PATCH] Staging: wlan-ng: Fix Alignment should match open paranthesis in prism2mgmt.c

[Joe Perches]

On Fri, 2018-02-16 at 15:36 +0100, Greg KH wrote:
> On Fri, Feb 16, 2018 at 12:18:36AM +0530, Yash Omer wrote:
> > This is patch fixes up a matching paranthesis alignment issue found by 
> > checkpatch.pl script.
[]
> > diff --git a/drivers/staging/wlan-ng/prism2mgmt.c 
> > b/drivers/staging/wlan-ng/prism2mgmt.c
[]
> > @@ -264,8 +264,8 @@ int prism2mgmt_scan(struct wlandevice *wlandev, void 
> > *msgp)
> > goto exit;
> > }
> > /* ibss options */
> > -   result = hfa384x_drvr_setconfig16(hw,
> > -   HFA384x_RID_CREATEIBSS,
> > +   result = hfa384x_drvr_setconfig16
> > +   (hw, HFA384x_RID_CREATEIBSS,
> 
> The original code is just fine, why is checkpatch complaining about
> this?

lack of argument alignment to parentheses.

Maybe wlan-ng should be marked obsolete in MAINTAINERS.

Re: eeepc-wmi loaded on Asus desktop board

[Andy Shevchenko]

+Cc: Darren (for sure)

On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel
 wrote:
> Dear Linux folks,
>
>
> Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with
> Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an input device
> is created.
>
> ```
> Feb 15 18:49:01 asusf2a85mpro kernel: calling  eeepc_wmi_init+0x0/0x1000
> [eeepc_wmi] @ 285
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Initialization: 0x0
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: BIOS WMI version: 0.9
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: SFUN value: 0x0
> Feb 15 18:49:01 asusf2a85mpro kernel: input: Eee PC WMI hotkeys as
> /devices/platform/eeepc-wmi/input/input7
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Number of fans: 1
> Feb 15 18:49:01 asusf2a85mpro kernel: initcall eeepc_wmi_init+0x0/0x1000
> [eeepc_wmi] returned 0 after 12130 usecs
> ```
>
> Please find the full log attached.
>
> Is that expected, or should the module not load at all on desktop boards?
>
>
>
> Kind regards,
>
> Paul



-- 
With Best Regards,
Andy Shevchenko

Re: eeepc-wmi loaded on Asus desktop board

[Andy Shevchenko]

+Cc: Darren (for sure)

On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel
 wrote:
> Dear Linux folks,
>
>
> Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with
> Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an input device
> is created.
>
> ```
> Feb 15 18:49:01 asusf2a85mpro kernel: calling  eeepc_wmi_init+0x0/0x1000
> [eeepc_wmi] @ 285
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Initialization: 0x0
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: BIOS WMI version: 0.9
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: SFUN value: 0x0
> Feb 15 18:49:01 asusf2a85mpro kernel: input: Eee PC WMI hotkeys as
> /devices/platform/eeepc-wmi/input/input7
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Number of fans: 1
> Feb 15 18:49:01 asusf2a85mpro kernel: initcall eeepc_wmi_init+0x0/0x1000
> [eeepc_wmi] returned 0 after 12130 usecs
> ```
>
> Please find the full log attached.
>
> Is that expected, or should the module not load at all on desktop boards?
>
>
>
> Kind regards,
>
> Paul



-- 
With Best Regards,
Andy Shevchenko

Re: eeepc-wmi loaded on Asus desktop board

[Andy Shevchenko]

+Cc: Darren.

On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel
 wrote:
> Dear Linux folks,
>
>
> Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with
> Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an input device
> is created.
>
> ```
> Feb 15 18:49:01 asusf2a85mpro kernel: calling  eeepc_wmi_init+0x0/0x1000
> [eeepc_wmi] @ 285
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Initialization: 0x0
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: BIOS WMI version: 0.9
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: SFUN value: 0x0
> Feb 15 18:49:01 asusf2a85mpro kernel: input: Eee PC WMI hotkeys as
> /devices/platform/eeepc-wmi/input/input7
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Number of fans: 1
> Feb 15 18:49:01 asusf2a85mpro kernel: initcall eeepc_wmi_init+0x0/0x1000
> [eeepc_wmi] returned 0 after 12130 usecs
> ```
>
> Please find the full log attached.
>
> Is that expected, or should the module not load at all on desktop boards?
>
>
>
> Kind regards,
>
> Paul



-- 
With Best Regards,
Andy Shevchenko

Re: eeepc-wmi loaded on Asus desktop board

[Andy Shevchenko]

+Cc: Darren.

On Fri, Feb 16, 2018 at 12:42 AM, Paul Menzel
 wrote:
> Dear Linux folks,
>
>
> Debugging an ACPI suspend problem on the desktop board Asus F285-M PRO with
> Linux 4.14, I noticed, the module *eeepc_wmi* is loaded, and an input device
> is created.
>
> ```
> Feb 15 18:49:01 asusf2a85mpro kernel: calling  eeepc_wmi_init+0x0/0x1000
> [eeepc_wmi] @ 285
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Initialization: 0x0
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: BIOS WMI version: 0.9
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: SFUN value: 0x0
> Feb 15 18:49:01 asusf2a85mpro kernel: input: Eee PC WMI hotkeys as
> /devices/platform/eeepc-wmi/input/input7
> Feb 15 18:49:01 asusf2a85mpro kernel: asus_wmi: Number of fans: 1
> Feb 15 18:49:01 asusf2a85mpro kernel: initcall eeepc_wmi_init+0x0/0x1000
> [eeepc_wmi] returned 0 after 12130 usecs
> ```
>
> Please find the full log attached.
>
> Is that expected, or should the module not load at all on desktop boards?
>
>
>
> Kind regards,
>
> Paul



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

[Tony Lindgren]

* Rafael J. Wysocki  [180216 09:42]:
> On Fri, Feb 9, 2018 at 5:14 PM, Tony Lindgren  wrote:
> > This makes it easy to grep :wakeup /proc/interrupts.
> > diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c
> > --- a/drivers/base/power/wakeirq.c
> > +++ b/drivers/base/power/wakeirq.c
> > @@ -112,6 +112,7 @@ void dev_pm_clear_wake_irq(struct device *dev)
> > free_irq(wirq->irq, wirq);
> > wirq->status &= ~WAKE_IRQ_DEDICATED_MASK;
> > }
> > +   kfree(wirq->name);
> > kfree(wirq);
> >  }
> >  EXPORT_SYMBOL_GPL(dev_pm_clear_wake_irq);
> > @@ -175,7 +176,8 @@ static irqreturn_t handle_threaded_wake_irq(int irq, 
> > void *_wirq)
> >  int dev_pm_set_dedicated_wake_irq(struct device *dev, int irq)
> >  {
> > struct wake_irq *wirq;
> > -   int err;
> > +   int err, namelen;
> > +   const char *postfix = ":wakeup";
> >
> > if (irq < 0)
> > return -EINVAL;
> > @@ -184,6 +186,14 @@ int dev_pm_set_dedicated_wake_irq(struct device *dev, 
> > int irq)
> > if (!wirq)
> > return -ENOMEM;
> >
> > +   namelen = strlen(dev_name(dev)) + strlen(postfix) + 1;
> > +   wirq->name = kzalloc(namelen, GFP_KERNEL);
> > +   if (!wirq->name) {
> > +   err = -ENOMEM;
> > +   goto err_free;
> > +   }
> > +
> > +   snprintf(wirq->name, namelen, "%s%s", dev_name(dev), postfix);
> 
> As Andy said you can do
> 
> wirq->name = kasprintf(GFP_KERNEL, "%s:wakeup", dev_name(dev));
> if (!wirq->name) {
> err = -ENOMEM;
> goto err_free;
> }
> 
> here and it will allocate the buffer for you.

Yeah great, will update and repost next week. I'll also
give Andy's patch a try, sounds like we may want to do
both though.

Regards,

Tony

Re: [PATCH] PM / wakeirq: Add wakeup name to dedicated wake irqs

[Tony Lindgren]

* Rafael J. Wysocki  [180216 09:42]:
> On Fri, Feb 9, 2018 at 5:14 PM, Tony Lindgren  wrote:
> > This makes it easy to grep :wakeup /proc/interrupts.
> > diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c
> > --- a/drivers/base/power/wakeirq.c
> > +++ b/drivers/base/power/wakeirq.c
> > @@ -112,6 +112,7 @@ void dev_pm_clear_wake_irq(struct device *dev)
> > free_irq(wirq->irq, wirq);
> > wirq->status &= ~WAKE_IRQ_DEDICATED_MASK;
> > }
> > +   kfree(wirq->name);
> > kfree(wirq);
> >  }
> >  EXPORT_SYMBOL_GPL(dev_pm_clear_wake_irq);
> > @@ -175,7 +176,8 @@ static irqreturn_t handle_threaded_wake_irq(int irq, 
> > void *_wirq)
> >  int dev_pm_set_dedicated_wake_irq(struct device *dev, int irq)
> >  {
> > struct wake_irq *wirq;
> > -   int err;
> > +   int err, namelen;
> > +   const char *postfix = ":wakeup";
> >
> > if (irq < 0)
> > return -EINVAL;
> > @@ -184,6 +186,14 @@ int dev_pm_set_dedicated_wake_irq(struct device *dev, 
> > int irq)
> > if (!wirq)
> > return -ENOMEM;
> >
> > +   namelen = strlen(dev_name(dev)) + strlen(postfix) + 1;
> > +   wirq->name = kzalloc(namelen, GFP_KERNEL);
> > +   if (!wirq->name) {
> > +   err = -ENOMEM;
> > +   goto err_free;
> > +   }
> > +
> > +   snprintf(wirq->name, namelen, "%s%s", dev_name(dev), postfix);
> 
> As Andy said you can do
> 
> wirq->name = kasprintf(GFP_KERNEL, "%s:wakeup", dev_name(dev));
> if (!wirq->name) {
> err = -ENOMEM;
> goto err_free;
> }
> 
> here and it will allocate the buffer for you.

Yeah great, will update and repost next week. I'll also
give Andy's patch a try, sounds like we may want to do
both though.

Regards,

Tony

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

[Christian Gmeiner]

2018-02-05 11:40 GMT+01:00 Martin Kepplinger :
>
>
>
>
> Martin Kepplinger | Entwicklung Software
>
> GINZINGER ELECTRONIC SYSTEMS GMBH
>
> Tel.: +43 7723 5422 157
> Mail: martin.kepplin...@ginzinger.com
> Web: www.ginzinger.com
>
>
>
>
> On 2018-02-05 11:07, Christian Gmeiner wrote:
>> Hi all.
>>
>> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger 
>> :
>>> The device could as well be in command mode, in which this driver cannot
>>> handle the device. When opening the device, let's make sure the device
>>> will be in the mode we expect it to be for this driver.
>>>
>>
>> I run into issues caused by this change. It turns out that the device
>> is non-functional
>> after some warm-reboots and as a result I am not able to use xorg's
>> evdev driver.
>> So I have some questions about this change:
>>
>> * Should we enable irq before calling i2c_master_send(..) as the chip raises 
>> an
>>   irq if the command was processed?
>>
>> * Would it be enough to send this command only once during driver
>> lifetime? I can
>>   see that on my system open gets called 3 times during boot-up.
>
> It would. See below for my thought on this change.
>
>>
>> * What are the circumstances the touch device would be in an other state? In 
>> the
>>   official kernel driver the userspace can send commands via sysfs.
>> Also the driver
>>   does set the touch enable mode as this patch does.
>
> I did this change as the device was once non-functional unexpectedly
> because it wasn't in touch mode. We can set touch mode during open() or
> probe() but I figured during open() would keep the driver working even
> when others would use the device in command mode.
>
> Does your problem go away when you revert this change or put it into
> probe()?

I needed to postprone further research and reverted this commit locally as
a new software release gets releases soon. The good this that I have
an automated way to run a test to trigger this issue quite easily.

Will have a deeper look after release time.

-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

[Christian Gmeiner]

2018-02-05 11:40 GMT+01:00 Martin Kepplinger :
>
>
>
>
> Martin Kepplinger | Entwicklung Software
>
> GINZINGER ELECTRONIC SYSTEMS GMBH
>
> Tel.: +43 7723 5422 157
> Mail: martin.kepplin...@ginzinger.com
> Web: www.ginzinger.com
>
>
>
>
> On 2018-02-05 11:07, Christian Gmeiner wrote:
>> Hi all.
>>
>> 2017-04-27 14:22 GMT+02:00 Martin Kepplinger 
>> :
>>> The device could as well be in command mode, in which this driver cannot
>>> handle the device. When opening the device, let's make sure the device
>>> will be in the mode we expect it to be for this driver.
>>>
>>
>> I run into issues caused by this change. It turns out that the device
>> is non-functional
>> after some warm-reboots and as a result I am not able to use xorg's
>> evdev driver.
>> So I have some questions about this change:
>>
>> * Should we enable irq before calling i2c_master_send(..) as the chip raises 
>> an
>>   irq if the command was processed?
>>
>> * Would it be enough to send this command only once during driver
>> lifetime? I can
>>   see that on my system open gets called 3 times during boot-up.
>
> It would. See below for my thought on this change.
>
>>
>> * What are the circumstances the touch device would be in an other state? In 
>> the
>>   official kernel driver the userspace can send commands via sysfs.
>> Also the driver
>>   does set the touch enable mode as this patch does.
>
> I did this change as the device was once non-functional unexpectedly
> because it wasn't in touch mode. We can set touch mode during open() or
> probe() but I figured during open() would keep the driver working even
> when others would use the device in command mode.
>
> Does your problem go away when you revert this change or put it into
> probe()?

I needed to postprone further research and reverted this commit locally as
a new software release gets releases soon. The good this that I have
an automated way to run a test to trigger this issue quite easily.

Will have a deeper look after release time.

-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info

Re: [PATCH] scripts: kernel_doc: fixup reporting of function identifiers

[Markus Heiser]

> Am 16.02.2018 um 15:56 schrieb Jonathan Corbet :
> 
> On Tue, 13 Feb 2018 13:31:46 +0200
> Mike Rapoport  wrote:
> 
>> When function description includes brackets after the function name as
>> suggested by Documentation/doc-guide/kernel-doc, the kernel-doc script
>> omits the function name from "Scanning doc for" report.
>> Extending match for identifier name with optional brackets fixes this
>> issue.
> 
> So let me channel akpm here and ask: what are the user-visible effects of
> this problem?  I ask because applying it doesn't make any difference in
> the "make htmldocs" output here.  So I don't understand why you're
> wanting to make this change.

Use kernel-doc -v and take a look on the info-messages.

In Documentation/doc-guide/kernel-doc we recommend to use

/**
 * foo() - lorem ipsum

to tag functions, but if you do so, the info message is broken,
the function name is missed at the end of the message:

 ../test123.c:2: info: Scanning doc for  

Here is the similar patch to kernel-doc python version:

 
https://github.com/return42/linuxdoc/commit/84d665df34cc3c9908a4b8ce0fdf193165a1ffa4

@Mike: thanks!

--Markus--

Re: [PATCH] scripts: kernel_doc: fixup reporting of function identifiers

[Markus Heiser]

> Am 16.02.2018 um 15:56 schrieb Jonathan Corbet :
> 
> On Tue, 13 Feb 2018 13:31:46 +0200
> Mike Rapoport  wrote:
> 
>> When function description includes brackets after the function name as
>> suggested by Documentation/doc-guide/kernel-doc, the kernel-doc script
>> omits the function name from "Scanning doc for" report.
>> Extending match for identifier name with optional brackets fixes this
>> issue.
> 
> So let me channel akpm here and ask: what are the user-visible effects of
> this problem?  I ask because applying it doesn't make any difference in
> the "make htmldocs" output here.  So I don't understand why you're
> wanting to make this change.

Use kernel-doc -v and take a look on the info-messages.

In Documentation/doc-guide/kernel-doc we recommend to use

/**
 * foo() - lorem ipsum

to tag functions, but if you do so, the info message is broken,
the function name is missed at the end of the message:

 ../test123.c:2: info: Scanning doc for  

Here is the similar patch to kernel-doc python version:

 
https://github.com/return42/linuxdoc/commit/84d665df34cc3c9908a4b8ce0fdf193165a1ffa4

@Mike: thanks!

--Markus--

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

[David Woodhouse]

On Fri, 2018-02-16 at 08:29 -0800, Jim Mattson wrote:
> On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini  wrote:
> 
> > Uhm, taking contents from the hardware is wrong (guess why---live
> > migration).  I'll send a revert of those two lines.
> 
> Hardware seems like a reasonable place to get the default value (cf.
> the VMX capability MSRs). Should these two lines just be moved to
> vmx_create_cpu?

They're already in vmx_create_cpu(). (Well, in vmx_cpu_setup() which is
a static function called only once, from vmx_create_cpu().)

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

[David Woodhouse]

On Fri, 2018-02-16 at 08:29 -0800, Jim Mattson wrote:
> On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini  wrote:
> 
> > Uhm, taking contents from the hardware is wrong (guess why---live
> > migration).  I'll send a revert of those two lines.
> 
> Hardware seems like a reasonable place to get the default value (cf.
> the VMX capability MSRs). Should these two lines just be moved to
> vmx_create_cpu?

They're already in vmx_create_cpu(). (Well, in vmx_cpu_setup() which is
a static function called only once, from vmx_create_cpu().)

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] staging: ashmem: Fix lockdep issue during llseek

[Greg Kroah-Hartman]

On Mon, Feb 12, 2018 at 05:01:25PM -0800, Joel Fernandes wrote:
> ashmem_mutex create a chain of dependencies like so:
> 
> (1)
> mmap syscall ->
>   mmap_sem ->  (acquired)
>   ashmem_mmap
>   ashmem_mutex (try to acquire)
>   (block)
> 
> (2)
> llseek syscall ->
>   ashmem_llseek ->
>   ashmem_mutex ->  (acquired)
>   inode_lock ->
>   inode->i_rwsem (try to acquire)
>   (block)
> 
> (3)
> getdents ->
>   iterate_dir ->
>   inode_lock ->
>   inode->i_rwsem   (acquired)
>   copy_to_user ->
>   mmap_sem (try to acquire)
> 
> There is a lock ordering created between mmap_sem and inode->i_rwsem
> causing a lockdep splat [2] during a syzcaller test, this patch fixes
> the issue by unlocking the mutex earlier. Functionally that's Ok since
> we don't need to protect vfs_llseek.
> 
> [1] https://patchwork.kernel.org/patch/10185031/
> [2] https://lkml.org/lkml/2018/1/10/48
> 
> Cc: Todd Kjos 
> Cc: Arve Hjonnevag 
> Cc: Greg Hackmann 
> Cc: Greg Kroah-Hartman 
> Cc: sta...@vger.kernel.org
> Reported-by: syzbot+8ec30bb7bf1a981a2...@syzkaller.appspotmail.com
> Signed-off-by: Joel Fernandes 
> ---
>  drivers/staging/android/ashmem.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)

Please always properly version your patches, and put what changed below
the --- line, so I have a hint as to which patch to apply.
Documentation/SubmittingPatches has the full details of how to do this.

Can you resend me the "latest" version of this patch, so I have a chance
of getting it right?  :)

thanks,

greg k-h

Re: [PATCH] staging: ashmem: Fix lockdep issue during llseek

[Greg Kroah-Hartman]

On Mon, Feb 12, 2018 at 05:01:25PM -0800, Joel Fernandes wrote:
> ashmem_mutex create a chain of dependencies like so:
> 
> (1)
> mmap syscall ->
>   mmap_sem ->  (acquired)
>   ashmem_mmap
>   ashmem_mutex (try to acquire)
>   (block)
> 
> (2)
> llseek syscall ->
>   ashmem_llseek ->
>   ashmem_mutex ->  (acquired)
>   inode_lock ->
>   inode->i_rwsem (try to acquire)
>   (block)
> 
> (3)
> getdents ->
>   iterate_dir ->
>   inode_lock ->
>   inode->i_rwsem   (acquired)
>   copy_to_user ->
>   mmap_sem (try to acquire)
> 
> There is a lock ordering created between mmap_sem and inode->i_rwsem
> causing a lockdep splat [2] during a syzcaller test, this patch fixes
> the issue by unlocking the mutex earlier. Functionally that's Ok since
> we don't need to protect vfs_llseek.
> 
> [1] https://patchwork.kernel.org/patch/10185031/
> [2] https://lkml.org/lkml/2018/1/10/48
> 
> Cc: Todd Kjos 
> Cc: Arve Hjonnevag 
> Cc: Greg Hackmann 
> Cc: Greg Kroah-Hartman 
> Cc: sta...@vger.kernel.org
> Reported-by: syzbot+8ec30bb7bf1a981a2...@syzkaller.appspotmail.com
> Signed-off-by: Joel Fernandes 
> ---
>  drivers/staging/android/ashmem.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)

Please always properly version your patches, and put what changed below
the --- line, so I have a hint as to which patch to apply.
Documentation/SubmittingPatches has the full details of how to do this.

Can you resend me the "latest" version of this patch, so I have a chance
of getting it right?  :)

thanks,

greg k-h

Re: [PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group

[Andy Shevchenko]

On Fri, Feb 16, 2018 at 5:08 PM, tedheadster  wrote:
> On Fri, Feb 16, 2018 at 9:17 AM, Andy Shevchenko
>  wrote:
>> On Thu, Feb 15, 2018 at 6:54 PM, Matthew Whitehead
>>  wrote:
>>> Several i586-class cpus supporting this instruction are missing from
>>> the X86_CMPXCHG64 config group.
>>
>> What about Intel Quark? MinuteIA core which is currently set as M586TSC.

> I am unsure what you are asking here. I do not see any option for
> Intel Quark processor types in arch/x86/Kconfig.cpu. Are you saying
> there should be one?

> Or perhaps you are saying that Intel Quark is currently set for
> M586TSC and it lacks the CMPXCHG64 instruction?

This is a good question.
The CPUID tells us family 5, model 9.

> If so, I would change
> my config option from M586TSC to M586.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group

[Andy Shevchenko]

On Fri, Feb 16, 2018 at 5:08 PM, tedheadster  wrote:
> On Fri, Feb 16, 2018 at 9:17 AM, Andy Shevchenko
>  wrote:
>> On Thu, Feb 15, 2018 at 6:54 PM, Matthew Whitehead
>>  wrote:
>>> Several i586-class cpus supporting this instruction are missing from
>>> the X86_CMPXCHG64 config group.
>>
>> What about Intel Quark? MinuteIA core which is currently set as M586TSC.

> I am unsure what you are asking here. I do not see any option for
> Intel Quark processor types in arch/x86/Kconfig.cpu. Are you saying
> there should be one?

> Or perhaps you are saying that Intel Quark is currently set for
> M586TSC and it lacks the CMPXCHG64 instruction?

This is a good question.
The CPUID tells us family 5, model 9.

> If so, I would change
> my config option from M586TSC to M586.


-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 0/2] jump_label: Robustify jump label patching

[Josh Poimboeuf]

v2:
- Refine the warning so that it doesn't warn about __init entries
- (Do so by explicitly disabling __init entries)
- Drop v1 patches which removed __init tracepoints

Josh Poimboeuf (2):
  jump_label: Explicitly disable jump labels in __init code
  jump_label: Warn on failed jump_label patch

 include/linux/jump_label.h |  3 +++
 init/main.c|  2 ++
 kernel/jump_label.c| 31 ---
 3 files changed, 29 insertions(+), 7 deletions(-)

-- 
2.14.3

[PATCH v2 0/2] jump_label: Robustify jump label patching

[Josh Poimboeuf]

v2:
- Refine the warning so that it doesn't warn about __init entries
- (Do so by explicitly disabling __init entries)
- Drop v1 patches which removed __init tracepoints

Josh Poimboeuf (2):
  jump_label: Explicitly disable jump labels in __init code
  jump_label: Warn on failed jump_label patch

 include/linux/jump_label.h |  3 +++
 init/main.c|  2 ++
 kernel/jump_label.c| 31 ---
 3 files changed, 29 insertions(+), 7 deletions(-)

-- 
2.14.3

[PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

[Josh Poimboeuf]

After initmem has been freed, any jump label entries in __init code are
prevented from being written to by the kernel_text_address() check in
__jump_label_update().  However, this check is quite broad.  If
kernel_text_address() were to return false for any other reason, the
jump label write would fail silently with no warning.

For jump label entrieds in module init code, entry->code is set to zero
to indicate that the entry is disabled.  Do the same thing for core
kernel init code.  This makes the behavior more consistent, and will
also make it more straightforward to detect non-init jump label write
failures in the next patch.

Signed-off-by: Josh Poimboeuf 
---
 include/linux/jump_label.h |  3 +++
 init/main.c|  2 ++
 kernel/jump_label.c| 18 --
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index b6a29c126cc4..2168cc6b8b30 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -151,6 +151,7 @@ extern struct jump_entry __start___jump_table[];
 extern struct jump_entry __stop___jump_table[];
 
 extern void jump_label_init(void);
+extern void jump_label_invalidate_init(void);
 extern void jump_label_lock(void);
 extern void jump_label_unlock(void);
 extern void arch_jump_label_transform(struct jump_entry *entry,
@@ -198,6 +199,8 @@ static __always_inline void jump_label_init(void)
static_key_initialized = true;
 }
 
+static inline void jump_label_invalidate_init(void) {}
+
 static __always_inline bool static_key_false(struct static_key *key)
 {
if (unlikely(static_key_count(key) > 0))
diff --git a/init/main.c b/init/main.c
index a8100b954839..969eaf140ef0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -89,6 +89,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1000,6 +1001,7 @@ static int __ref kernel_init(void *unused)
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
ftrace_free_init_mem();
+   jump_label_invalidate_init();
free_initmem();
mark_readonly();
system_state = SYSTEM_RUNNING;
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index b4517095db6a..96274c6d3511 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef HAVE_JUMP_LABEL
 
@@ -633,16 +634,29 @@ static void jump_label_del_module(struct module *mod)
}
 }
 
+/* Disable any jump label entries in __init code */
+void __init jump_label_invalidate_init(void)
+{
+   struct jump_entry *iter_start = __start___jump_table;
+   struct jump_entry *iter_stop = __stop___jump_table;
+   struct jump_entry *iter;
+
+   for (iter = iter_start; iter < iter_stop; iter++)
+   if (iter->code >= (unsigned long)_sinittext &&
+   iter->code < (unsigned long)_einittext)
+   iter->code = 0;
+}
+
+/* Disable any jump label entries in module init code */
 static void jump_label_invalidate_module_init(struct module *mod)
 {
struct jump_entry *iter_start = mod->jump_entries;
struct jump_entry *iter_stop = iter_start + mod->num_jump_entries;
struct jump_entry *iter;
 
-   for (iter = iter_start; iter < iter_stop; iter++) {
+   for (iter = iter_start; iter < iter_stop; iter++)
if (within_module_init(iter->code, mod))
iter->code = 0;
-   }
 }
 
 static int
-- 
2.14.3

[PATCH v2 1/2] jump_label: Explicitly disable jump labels in __init code

[Josh Poimboeuf]

After initmem has been freed, any jump label entries in __init code are
prevented from being written to by the kernel_text_address() check in
__jump_label_update().  However, this check is quite broad.  If
kernel_text_address() were to return false for any other reason, the
jump label write would fail silently with no warning.

For jump label entrieds in module init code, entry->code is set to zero
to indicate that the entry is disabled.  Do the same thing for core
kernel init code.  This makes the behavior more consistent, and will
also make it more straightforward to detect non-init jump label write
failures in the next patch.

Signed-off-by: Josh Poimboeuf 
---
 include/linux/jump_label.h |  3 +++
 init/main.c|  2 ++
 kernel/jump_label.c| 18 --
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index b6a29c126cc4..2168cc6b8b30 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -151,6 +151,7 @@ extern struct jump_entry __start___jump_table[];
 extern struct jump_entry __stop___jump_table[];
 
 extern void jump_label_init(void);
+extern void jump_label_invalidate_init(void);
 extern void jump_label_lock(void);
 extern void jump_label_unlock(void);
 extern void arch_jump_label_transform(struct jump_entry *entry,
@@ -198,6 +199,8 @@ static __always_inline void jump_label_init(void)
static_key_initialized = true;
 }
 
+static inline void jump_label_invalidate_init(void) {}
+
 static __always_inline bool static_key_false(struct static_key *key)
 {
if (unlikely(static_key_count(key) > 0))
diff --git a/init/main.c b/init/main.c
index a8100b954839..969eaf140ef0 100644
--- a/init/main.c
+++ b/init/main.c
@@ -89,6 +89,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1000,6 +1001,7 @@ static int __ref kernel_init(void *unused)
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
ftrace_free_init_mem();
+   jump_label_invalidate_init();
free_initmem();
mark_readonly();
system_state = SYSTEM_RUNNING;
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index b4517095db6a..96274c6d3511 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef HAVE_JUMP_LABEL
 
@@ -633,16 +634,29 @@ static void jump_label_del_module(struct module *mod)
}
 }
 
+/* Disable any jump label entries in __init code */
+void __init jump_label_invalidate_init(void)
+{
+   struct jump_entry *iter_start = __start___jump_table;
+   struct jump_entry *iter_stop = __stop___jump_table;
+   struct jump_entry *iter;
+
+   for (iter = iter_start; iter < iter_stop; iter++)
+   if (iter->code >= (unsigned long)_sinittext &&
+   iter->code < (unsigned long)_einittext)
+   iter->code = 0;
+}
+
+/* Disable any jump label entries in module init code */
 static void jump_label_invalidate_module_init(struct module *mod)
 {
struct jump_entry *iter_start = mod->jump_entries;
struct jump_entry *iter_stop = iter_start + mod->num_jump_entries;
struct jump_entry *iter;
 
-   for (iter = iter_start; iter < iter_stop; iter++) {
+   for (iter = iter_start; iter < iter_stop; iter++)
if (within_module_init(iter->code, mod))
iter->code = 0;
-   }
 }
 
 static int
-- 
2.14.3

[PATCH v2 2/2] jump_label: Warn on failed jump_label patch

[Josh Poimboeuf]

When the jump label code encounters an address which isn't recognized by
kernel_text_address(), it just silently fails.

This can be dangerous because jump labels are used in a variety of
places, and are generally expected to work.  Convert the silent failure
to a warning.

This won't warn about attempted writes to tracepoints in __init code
after initmem has been freed, as those are already guarded by the
entry->code check.

Signed-off-by: Josh Poimboeuf 
---
 kernel/jump_label.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 96274c6d3511..08a02ae54997 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -367,12 +367,15 @@ static void __jump_label_update(struct static_key *key,
 {
for (; (entry < stop) && (jump_entry_key(entry) == key); entry++) {
/*
-* entry->code set to 0 invalidates module init text sections
-* kernel_text_address() verifies we are not in core kernel
-* init code, see jump_label_invalidate_module_init().
+* An entry->code of 0 indicates an entry which has been
+* disabled because it was in an init text area.
 */
-   if (entry->code && kernel_text_address(entry->code))
-   arch_jump_label_transform(entry, 
jump_label_type(entry));
+   if (entry->code) {
+   if (kernel_text_address(entry->code))
+   arch_jump_label_transform(entry, 
jump_label_type(entry));
+   else
+   WARN_ONCE(1, "can't patch jump_label at %pS", 
(void *)entry->code);
+   }
}
 }
 
-- 
2.14.3

[PATCH v2 2/2] jump_label: Warn on failed jump_label patch

[Josh Poimboeuf]

When the jump label code encounters an address which isn't recognized by
kernel_text_address(), it just silently fails.

This can be dangerous because jump labels are used in a variety of
places, and are generally expected to work.  Convert the silent failure
to a warning.

This won't warn about attempted writes to tracepoints in __init code
after initmem has been freed, as those are already guarded by the
entry->code check.

Signed-off-by: Josh Poimboeuf 
---
 kernel/jump_label.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 96274c6d3511..08a02ae54997 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -367,12 +367,15 @@ static void __jump_label_update(struct static_key *key,
 {
for (; (entry < stop) && (jump_entry_key(entry) == key); entry++) {
/*
-* entry->code set to 0 invalidates module init text sections
-* kernel_text_address() verifies we are not in core kernel
-* init code, see jump_label_invalidate_module_init().
+* An entry->code of 0 indicates an entry which has been
+* disabled because it was in an init text area.
 */
-   if (entry->code && kernel_text_address(entry->code))
-   arch_jump_label_transform(entry, 
jump_label_type(entry));
+   if (entry->code) {
+   if (kernel_text_address(entry->code))
+   arch_jump_label_transform(entry, 
jump_label_type(entry));
+   else
+   WARN_ONCE(1, "can't patch jump_label at %pS", 
(void *)entry->code);
+   }
}
 }
 
-- 
2.14.3

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

[Jim Mattson]

On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini  wrote:

> Uhm, taking contents from the hardware is wrong (guess why---live
> migration).  I'll send a revert of those two lines.

Hardware seems like a reasonable place to get the default value (cf.
the VMX capability MSRs). Should these two lines just be moved to
vmx_create_cpu?

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

[Jim Mattson]

On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini  wrote:

> Uhm, taking contents from the hardware is wrong (guess why---live
> migration).  I'll send a revert of those two lines.

Hardware seems like a reasonable place to get the default value (cf.
the VMX capability MSRs). Should these two lines just be moved to
vmx_create_cpu?

Re: [PATCH v2 5/9] staging: android: ion: Remove lable debugfs_done

[Greg KH]

On Mon, Feb 12, 2018 at 06:43:10PM +0800, Yisheng Xie wrote:
> When failed to create debug_root, we will go on initail other part of
> ion, so we can just info this message to user and do not need a lable
> to jump.
> 
> Acked-by: Laura Abbott 
> Signed-off-by: Yisheng Xie 
> ---
>  drivers/staging/android/ion/ion.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 4b69372..461b193 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -595,12 +595,9 @@ static int ion_device_create(void)
>   }
>  
>   idev->debug_root = debugfs_create_dir("ion", NULL);
> - if (!idev->debug_root) {
> + if (!idev->debug_root)
>   pr_err("ion: failed to create debugfs root directory.\n");
> - goto debugfs_done;
> - }

Again, does not matter to check the return value of any debugfs call.

thanks,

greg k-h

Re: [PATCH v2 5/9] staging: android: ion: Remove lable debugfs_done

[Greg KH]

On Mon, Feb 12, 2018 at 06:43:10PM +0800, Yisheng Xie wrote:
> When failed to create debug_root, we will go on initail other part of
> ion, so we can just info this message to user and do not need a lable
> to jump.
> 
> Acked-by: Laura Abbott 
> Signed-off-by: Yisheng Xie 
> ---
>  drivers/staging/android/ion/ion.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 4b69372..461b193 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -595,12 +595,9 @@ static int ion_device_create(void)
>   }
>  
>   idev->debug_root = debugfs_create_dir("ion", NULL);
> - if (!idev->debug_root) {
> + if (!idev->debug_root)
>   pr_err("ion: failed to create debugfs root directory.\n");
> - goto debugfs_done;
> - }

Again, does not matter to check the return value of any debugfs call.

thanks,

greg k-h

Re: [PATCH v2 4/9] staging: android: ion: Avoid NULL point in error path

[Greg KH]

On Mon, Feb 12, 2018 at 06:43:09PM +0800, Yisheng Xie wrote:
> If we failed to create debugfs for ion at ion_device_create, the
> debug_root of ion_device will be NULL, and then when try to create debug
> file for shrinker of heap it will be create on the top of debugfs. If we
> also failed to create this the debug file, it call dentry_path to found
> the path of debug_root, then a NULL point will occur.
> 
> Fix this by avoiding call dentry_path, but show the debug name only when
> failed to create debug file for shrinker.
> 
> Acked-by: Laura Abbott 
> Signed-off-by: Yisheng Xie 
> ---
>  drivers/staging/android/ion/ion.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 57e0d80..4b69372 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -564,13 +564,9 @@ void ion_device_add_heap(struct ion_heap *heap)
>   debug_file = debugfs_create_file(debug_name,
>0644, dev->debug_root, heap,
>_shrink_fops);
> - if (!debug_file) {
> - char buf[256], *path;
> -
> - path = dentry_path(dev->debug_root, buf, 256);
> - pr_err("Failed to create heap shrinker debugfs at 
> %s/%s\n",
> -path, debug_name);
> - }
> + if (!debug_file)
> + pr_err("Failed to create ion heap shrinker debugfs at 
> %s\n",
> +debug_name);

Really we can just remove this, there's no need to check the return
value of this debugfs call at all, it doesn't matter.

thanks,

greg k-h

Re: [PATCH v2 4/9] staging: android: ion: Avoid NULL point in error path

[Greg KH]

On Mon, Feb 12, 2018 at 06:43:09PM +0800, Yisheng Xie wrote:
> If we failed to create debugfs for ion at ion_device_create, the
> debug_root of ion_device will be NULL, and then when try to create debug
> file for shrinker of heap it will be create on the top of debugfs. If we
> also failed to create this the debug file, it call dentry_path to found
> the path of debug_root, then a NULL point will occur.
> 
> Fix this by avoiding call dentry_path, but show the debug name only when
> failed to create debug file for shrinker.
> 
> Acked-by: Laura Abbott 
> Signed-off-by: Yisheng Xie 
> ---
>  drivers/staging/android/ion/ion.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 57e0d80..4b69372 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -564,13 +564,9 @@ void ion_device_add_heap(struct ion_heap *heap)
>   debug_file = debugfs_create_file(debug_name,
>0644, dev->debug_root, heap,
>_shrink_fops);
> - if (!debug_file) {
> - char buf[256], *path;
> -
> - path = dentry_path(dev->debug_root, buf, 256);
> - pr_err("Failed to create heap shrinker debugfs at 
> %s/%s\n",
> -path, debug_name);
> - }
> + if (!debug_file)
> + pr_err("Failed to create ion heap shrinker debugfs at 
> %s\n",
> +debug_name);

Really we can just remove this, there's no need to check the return
value of this debugfs call at all, it doesn't matter.

thanks,

greg k-h

Re: TCP and BBR: reproducibly low cwnd and bandwidth

[Holger Hoffstätte]

On 02/16/18 16:15, Oleksandr Natalenko wrote:
> Hi, David, Eric, Neal et al.
> 
> On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote:
>> I've faced an issue with a limited TCP bandwidth between my laptop and a
>> server in my 1 Gbps LAN while using BBR as a congestion control mechanism.
>> To verify my observations, I've set up 2 KVM VMs with the following
>> parameters:
>>
>> 1) Linux v4.15.3
>> 2) virtio NICs
>> 3) 128 MiB of RAM
>> 4) 2 vCPUs
>> 5) tested on both non-PREEMPT/100 Hz and PREEMPT/1000 Hz

These are very odd configurations. :)
Non-preempt/100 might well be too slow, whereas PREEMPT/1000 might simply
have too much overhead.

>> The VMs are interconnected via host bridge (-netdev bridge). I was running
>> iperf3 in the default and reverse mode. Here are the results:
>>
>> 1) BBR on both VMs
>>
>> upload: 3.42 Gbits/sec, cwnd ~ 320 KBytes
>> download: 3.39 Gbits/sec, cwnd ~ 320 KBytes
>>
>> 2) Reno on both VMs
>>
>> upload: 5.50 Gbits/sec, cwnd = 976 KBytes (constant)
>> download: 5.22 Gbits/sec, cwnd = 1.20 MBytes (constant)
>>
>> 3) Reno on client, BBR on server
>>
>> upload: 5.29 Gbits/sec, cwnd = 952 KBytes (constant)
>> download: 3.45 Gbits/sec, cwnd ~ 320 KBytes
>>
>> 4) BBR on client, Reno on server
>>
>> upload: 3.36 Gbits/sec, cwnd ~ 370 KBytes
>> download: 5.21 Gbits/sec, cwnd = 887 KBytes (constant)
>>
>> So, as you may see, when BBR is in use, upload rate is bad and cwnd is low.

BBR in general will run with lower cwnd than e.g. Cubic or others.
That's a feature and necessary for WAN transfers.

>> If using real HW (1 Gbps LAN, laptop and server), BBR limits the throughput
>> to ~100 Mbps (verifiable not only by iperf3, but also by scp while
>> transferring some files between hosts).

Something seems really wrong with your setup. I get completely
expected throughput on wired 1Gb between two hosts:

Connecting to host tux, port 5201
[  5] local 192.168.100.223 port 48718 connected to 192.168.100.222 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   948 Mbits/sec0204 KBytes   
[  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec0204 KBytes   
[  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec0204 KBytes   
[...]

Running it locally gives the more or less expected results as well:

Connecting to host ragnarok, port 5201
[  5] local 192.168.100.223 port 54090 connected to 192.168.100.223 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec  8.09 GBytes  69.5 Gbits/sec0512 KBytes   
[  5]   1.00-2.00   sec  8.14 GBytes  69.9 Gbits/sec0512 KBytes   
[  5]   2.00-3.00   sec  8.43 GBytes  72.4 Gbits/sec0512 KBytes   
[...]

Both hosts running 4.14.x with bbr and fq_codel (default qdisc everywhere).
In the past I only used BBR briefly for testing since at 1Gb speeds on my
LAN it was actually slightly slower than Cubic (some of those bugs were
recently addressed) and made no difference otherwise, even for uploads -
which are capped by my 50/10 DSL anyway.

Please note that BBR was developed to address the case of WAN transfers
(or more precisely high BDP paths) which often suffer from TCP throughput
collapse due to single packet loss events. While it might "work" in other
scenarios as well, strictly speaking delay-based anything is increasingly
less likely to work when there is no meaningful notion of delay - such
as on a LAN. (yes, this is very simplified..)

The BBR mailing list has several nice reports why the current BBR
implementation (dubbed v1) has a few - sometimes severe - problems.
These are being addressed as we speak.

(let me know if you want some of those tech reports by email. :)

>> Also, I've tried to use YeAH instead of Reno, and it gives me the same
>> results as Reno (IOW, YeAH works fine too).
>>
>> Questions:
>>
>> 1) is this expected?
>> 2) or am I missing some extra BBR tuneable?

No, it should work out of the box.

>> 3) if it is not a regression (I don't have any previous data to compare
>> with), how can I fix this?
>> 4) if it is a bug in BBR, what else should I provide or check for a proper
>> investigation?
> 
> I've played with BBR a little bit more and managed to narrow the issue down 
> to 
> the changes between v4.12 and v4.13. Here are my observations:
> 
> v4.12 + BBR + fq_codel == OK
> v4.12 + BBR + fq   == OK
> v4.13 + BBR + fq_codel == Not OK
> v4.13 + BBR + fq   == OK
> 
> I think this has something to do with an internal TCP implementation for 
> pacing, that was introduced in v4.13 (commit 218af599fa63) specifically to 
> allow using BBR together with non-fq qdiscs. Once BBR relies on fq, the 
> throughput is high and saturates the link, but if another qdisc is in use, 
> for 
> instance, fq_codel, the throughput drops. Just to be sure, I've also tried 
> pfifo_fast instead of fq_codel with the same outcome resulting in the low 
> throughput.

I'm 

Re: TCP and BBR: reproducibly low cwnd and bandwidth

[Holger Hoffstätte]

On 02/16/18 16:15, Oleksandr Natalenko wrote:
> Hi, David, Eric, Neal et al.
> 
> On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote:
>> I've faced an issue with a limited TCP bandwidth between my laptop and a
>> server in my 1 Gbps LAN while using BBR as a congestion control mechanism.
>> To verify my observations, I've set up 2 KVM VMs with the following
>> parameters:
>>
>> 1) Linux v4.15.3
>> 2) virtio NICs
>> 3) 128 MiB of RAM
>> 4) 2 vCPUs
>> 5) tested on both non-PREEMPT/100 Hz and PREEMPT/1000 Hz

These are very odd configurations. :)
Non-preempt/100 might well be too slow, whereas PREEMPT/1000 might simply
have too much overhead.

>> The VMs are interconnected via host bridge (-netdev bridge). I was running
>> iperf3 in the default and reverse mode. Here are the results:
>>
>> 1) BBR on both VMs
>>
>> upload: 3.42 Gbits/sec, cwnd ~ 320 KBytes
>> download: 3.39 Gbits/sec, cwnd ~ 320 KBytes
>>
>> 2) Reno on both VMs
>>
>> upload: 5.50 Gbits/sec, cwnd = 976 KBytes (constant)
>> download: 5.22 Gbits/sec, cwnd = 1.20 MBytes (constant)
>>
>> 3) Reno on client, BBR on server
>>
>> upload: 5.29 Gbits/sec, cwnd = 952 KBytes (constant)
>> download: 3.45 Gbits/sec, cwnd ~ 320 KBytes
>>
>> 4) BBR on client, Reno on server
>>
>> upload: 3.36 Gbits/sec, cwnd ~ 370 KBytes
>> download: 5.21 Gbits/sec, cwnd = 887 KBytes (constant)
>>
>> So, as you may see, when BBR is in use, upload rate is bad and cwnd is low.

BBR in general will run with lower cwnd than e.g. Cubic or others.
That's a feature and necessary for WAN transfers.

>> If using real HW (1 Gbps LAN, laptop and server), BBR limits the throughput
>> to ~100 Mbps (verifiable not only by iperf3, but also by scp while
>> transferring some files between hosts).

Something seems really wrong with your setup. I get completely
expected throughput on wired 1Gb between two hosts:

Connecting to host tux, port 5201
[  5] local 192.168.100.223 port 48718 connected to 192.168.100.222 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec   113 MBytes   948 Mbits/sec0204 KBytes   
[  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec0204 KBytes   
[  5]   2.00-3.00   sec   112 MBytes   941 Mbits/sec0204 KBytes   
[...]

Running it locally gives the more or less expected results as well:

Connecting to host ragnarok, port 5201
[  5] local 192.168.100.223 port 54090 connected to 192.168.100.223 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec  8.09 GBytes  69.5 Gbits/sec0512 KBytes   
[  5]   1.00-2.00   sec  8.14 GBytes  69.9 Gbits/sec0512 KBytes   
[  5]   2.00-3.00   sec  8.43 GBytes  72.4 Gbits/sec0512 KBytes   
[...]

Both hosts running 4.14.x with bbr and fq_codel (default qdisc everywhere).
In the past I only used BBR briefly for testing since at 1Gb speeds on my
LAN it was actually slightly slower than Cubic (some of those bugs were
recently addressed) and made no difference otherwise, even for uploads -
which are capped by my 50/10 DSL anyway.

Please note that BBR was developed to address the case of WAN transfers
(or more precisely high BDP paths) which often suffer from TCP throughput
collapse due to single packet loss events. While it might "work" in other
scenarios as well, strictly speaking delay-based anything is increasingly
less likely to work when there is no meaningful notion of delay - such
as on a LAN. (yes, this is very simplified..)

The BBR mailing list has several nice reports why the current BBR
implementation (dubbed v1) has a few - sometimes severe - problems.
These are being addressed as we speak.

(let me know if you want some of those tech reports by email. :)

>> Also, I've tried to use YeAH instead of Reno, and it gives me the same
>> results as Reno (IOW, YeAH works fine too).
>>
>> Questions:
>>
>> 1) is this expected?
>> 2) or am I missing some extra BBR tuneable?

No, it should work out of the box.

>> 3) if it is not a regression (I don't have any previous data to compare
>> with), how can I fix this?
>> 4) if it is a bug in BBR, what else should I provide or check for a proper
>> investigation?
> 
> I've played with BBR a little bit more and managed to narrow the issue down 
> to 
> the changes between v4.12 and v4.13. Here are my observations:
> 
> v4.12 + BBR + fq_codel == OK
> v4.12 + BBR + fq   == OK
> v4.13 + BBR + fq_codel == Not OK
> v4.13 + BBR + fq   == OK
> 
> I think this has something to do with an internal TCP implementation for 
> pacing, that was introduced in v4.13 (commit 218af599fa63) specifically to 
> allow using BBR together with non-fq qdiscs. Once BBR relies on fq, the 
> throughput is high and saturates the link, but if another qdisc is in use, 
> for 
> instance, fq_codel, the throughput drops. Just to be sure, I've also tried 
> pfifo_fast instead of fq_codel with the same outcome resulting in the low 
> throughput.

I'm 

Re: TCP and BBR: reproducibly low cwnd and bandwidth

[Eric Dumazet]

On Fri, Feb 16, 2018 at 7:15 AM, Oleksandr Natalenko
 wrote:
> Hi, David, Eric, Neal et al.
>
> On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote:
>> I've faced an issue with a limited TCP bandwidth between my laptop and a
>> server in my 1 Gbps LAN while using BBR as a congestion control mechanism.
>> To verify my observations, I've set up 2 KVM VMs with the following
>> parameters:
>>
>> 1) Linux v4.15.3
>> 2) virtio NICs
>> 3) 128 MiB of RAM
>> 4) 2 vCPUs
>> 5) tested on both non-PREEMPT/100 Hz and PREEMPT/1000 Hz
>>
>> The VMs are interconnected via host bridge (-netdev bridge). I was running
>> iperf3 in the default and reverse mode. Here are the results:
>>
>> 1) BBR on both VMs
>>
>> upload: 3.42 Gbits/sec, cwnd ~ 320 KBytes
>> download: 3.39 Gbits/sec, cwnd ~ 320 KBytes
>>
>> 2) Reno on both VMs
>>
>> upload: 5.50 Gbits/sec, cwnd = 976 KBytes (constant)
>> download: 5.22 Gbits/sec, cwnd = 1.20 MBytes (constant)
>>
>> 3) Reno on client, BBR on server
>>
>> upload: 5.29 Gbits/sec, cwnd = 952 KBytes (constant)
>> download: 3.45 Gbits/sec, cwnd ~ 320 KBytes
>>
>> 4) BBR on client, Reno on server
>>
>> upload: 3.36 Gbits/sec, cwnd ~ 370 KBytes
>> download: 5.21 Gbits/sec, cwnd = 887 KBytes (constant)
>>
>> So, as you may see, when BBR is in use, upload rate is bad and cwnd is low.
>> If using real HW (1 Gbps LAN, laptop and server), BBR limits the throughput
>> to ~100 Mbps (verifiable not only by iperf3, but also by scp while
>> transferring some files between hosts).
>>
>> Also, I've tried to use YeAH instead of Reno, and it gives me the same
>> results as Reno (IOW, YeAH works fine too).
>>
>> Questions:
>>
>> 1) is this expected?
>> 2) or am I missing some extra BBR tuneable?
>> 3) if it is not a regression (I don't have any previous data to compare
>> with), how can I fix this?
>> 4) if it is a bug in BBR, what else should I provide or check for a proper
>> investigation?
>
> I've played with BBR a little bit more and managed to narrow the issue down to
> the changes between v4.12 and v4.13. Here are my observations:
>
> v4.12 + BBR + fq_codel == OK
> v4.12 + BBR + fq   == OK
> v4.13 + BBR + fq_codel == Not OK
> v4.13 + BBR + fq   == OK
>
> I think this has something to do with an internal TCP implementation for
> pacing, that was introduced in v4.13 (commit 218af599fa63) specifically to
> allow using BBR together with non-fq qdiscs. Once BBR relies on fq, the
> throughput is high and saturates the link, but if another qdisc is in use, for
> instance, fq_codel, the throughput drops. Just to be sure, I've also tried
> pfifo_fast instead of fq_codel with the same outcome resulting in the low
> throughput.
>
> Unfortunately, I do not know if this is something expected or should be
> considered as a regression. Thus, asking for an advice.
>
> Ideas?

The way TCP pacing works, it defaults to internal pacing using a hint
stored in the socket.

If you change the qdisc while flow is alive, result could be unexpected.

(TCP socket remembers that one FQ was supposed to handle the pacing)

What results do you have if you use standard pfifo_fast ?

I am asking because TCP pacing relies on High resolution timers, and
that might be weak on your VM.

Re: TCP and BBR: reproducibly low cwnd and bandwidth

[Eric Dumazet]

On Fri, Feb 16, 2018 at 7:15 AM, Oleksandr Natalenko
 wrote:
> Hi, David, Eric, Neal et al.
>
> On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote:
>> I've faced an issue with a limited TCP bandwidth between my laptop and a
>> server in my 1 Gbps LAN while using BBR as a congestion control mechanism.
>> To verify my observations, I've set up 2 KVM VMs with the following
>> parameters:
>>
>> 1) Linux v4.15.3
>> 2) virtio NICs
>> 3) 128 MiB of RAM
>> 4) 2 vCPUs
>> 5) tested on both non-PREEMPT/100 Hz and PREEMPT/1000 Hz
>>
>> The VMs are interconnected via host bridge (-netdev bridge). I was running
>> iperf3 in the default and reverse mode. Here are the results:
>>
>> 1) BBR on both VMs
>>
>> upload: 3.42 Gbits/sec, cwnd ~ 320 KBytes
>> download: 3.39 Gbits/sec, cwnd ~ 320 KBytes
>>
>> 2) Reno on both VMs
>>
>> upload: 5.50 Gbits/sec, cwnd = 976 KBytes (constant)
>> download: 5.22 Gbits/sec, cwnd = 1.20 MBytes (constant)
>>
>> 3) Reno on client, BBR on server
>>
>> upload: 5.29 Gbits/sec, cwnd = 952 KBytes (constant)
>> download: 3.45 Gbits/sec, cwnd ~ 320 KBytes
>>
>> 4) BBR on client, Reno on server
>>
>> upload: 3.36 Gbits/sec, cwnd ~ 370 KBytes
>> download: 5.21 Gbits/sec, cwnd = 887 KBytes (constant)
>>
>> So, as you may see, when BBR is in use, upload rate is bad and cwnd is low.
>> If using real HW (1 Gbps LAN, laptop and server), BBR limits the throughput
>> to ~100 Mbps (verifiable not only by iperf3, but also by scp while
>> transferring some files between hosts).
>>
>> Also, I've tried to use YeAH instead of Reno, and it gives me the same
>> results as Reno (IOW, YeAH works fine too).
>>
>> Questions:
>>
>> 1) is this expected?
>> 2) or am I missing some extra BBR tuneable?
>> 3) if it is not a regression (I don't have any previous data to compare
>> with), how can I fix this?
>> 4) if it is a bug in BBR, what else should I provide or check for a proper
>> investigation?
>
> I've played with BBR a little bit more and managed to narrow the issue down to
> the changes between v4.12 and v4.13. Here are my observations:
>
> v4.12 + BBR + fq_codel == OK
> v4.12 + BBR + fq   == OK
> v4.13 + BBR + fq_codel == Not OK
> v4.13 + BBR + fq   == OK
>
> I think this has something to do with an internal TCP implementation for
> pacing, that was introduced in v4.13 (commit 218af599fa63) specifically to
> allow using BBR together with non-fq qdiscs. Once BBR relies on fq, the
> throughput is high and saturates the link, but if another qdisc is in use, for
> instance, fq_codel, the throughput drops. Just to be sure, I've also tried
> pfifo_fast instead of fq_codel with the same outcome resulting in the low
> throughput.
>
> Unfortunately, I do not know if this is something expected or should be
> considered as a regression. Thus, asking for an advice.
>
> Ideas?

The way TCP pacing works, it defaults to internal pacing using a hint
stored in the socket.

If you change the qdisc while flow is alive, result could be unexpected.

(TCP socket remembers that one FQ was supposed to handle the pacing)

What results do you have if you use standard pfifo_fast ?

I am asking because TCP pacing relies on High resolution timers, and
that might be weak on your VM.

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

[Dmitry Safonov]

2018-02-15 20:02 GMT+00:00 Andy Lutomirski :
> On Thu, Feb 15, 2018 at 4:36 PM, Nadav Amit  wrote:
>> Based on the understanding that there should be no way for userspace to
>> address the kernel-space from compatibility mode, disable it while
>> running in compatibility mode as long as the 64-bit code segment of the
>> user is not used.
>>
>> Reenabling PTI is performed by restoring NX-bits to the userspace
>> mappings, flushing the TLBs, and notifying all the CPUs that use the
>> affected mm to disable PTI. Each core responds by removing the present
>> bit for the 64-bit code-segment, and marking that PTI is disabled on
>> that core.
>>
>
> I dislike this patch because it's conflating two things.  The patch
> claims to merely disable PTI for compat tasks, whatever those are.
> But it's also introducing a much stronger concept of what a compat
> task is.  The kernel currently mostly doesn't care whether a task is
> "compat" or not, and I think that most remaining code paths that do
> care are buggy and should be removed.

Yes, please, don't do a stronger concept..
Speaking from CRIU side, it C/R ia32 tasks with x86_64 binaries.

-- 
 Dmitry

Re: [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode

[Dmitry Safonov]

2018-02-15 20:02 GMT+00:00 Andy Lutomirski :
> On Thu, Feb 15, 2018 at 4:36 PM, Nadav Amit  wrote:
>> Based on the understanding that there should be no way for userspace to
>> address the kernel-space from compatibility mode, disable it while
>> running in compatibility mode as long as the 64-bit code segment of the
>> user is not used.
>>
>> Reenabling PTI is performed by restoring NX-bits to the userspace
>> mappings, flushing the TLBs, and notifying all the CPUs that use the
>> affected mm to disable PTI. Each core responds by removing the present
>> bit for the 64-bit code-segment, and marking that PTI is disabled on
>> that core.
>>
>
> I dislike this patch because it's conflating two things.  The patch
> claims to merely disable PTI for compat tasks, whatever those are.
> But it's also introducing a much stronger concept of what a compat
> task is.  The kernel currently mostly doesn't care whether a task is
> "compat" or not, and I think that most remaining code paths that do
> care are buggy and should be removed.

Yes, please, don't do a stronger concept..
Speaking from CRIU side, it C/R ia32 tasks with x86_64 binaries.

-- 
 Dmitry

Re: [PATCH] staging: android: ion: Initialize dma_address of new sg list

[Greg KH]

On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> Fix the dup_sg_table function to initialize the dma_address of the new
> sg list entries instead of the source dma_address entries.
> 
> Fixes: 17fd283f3870 ("staging: android: ion: Duplicate sg_table")

So this should be sent to the stable trees as well, right?

Please add that when you resend...

thanks,

greg k-h

Re: [PATCH] staging: android: ion: Initialize dma_address of new sg list

[Greg KH]

On Fri, Feb 09, 2018 at 10:16:56PM -0800, Liam Mark wrote:
> Fix the dup_sg_table function to initialize the dma_address of the new
> sg list entries instead of the source dma_address entries.
> 
> Fixes: 17fd283f3870 ("staging: android: ion: Duplicate sg_table")

So this should be sent to the stable trees as well, right?

Please add that when you resend...

thanks,

greg k-h

Re: [PATCH] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump

[kbuild test robot]

Hi AKASHI,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.16-rc1 next-20180216]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/AKASHI-Takahiro/arm64-acpi-efi-fix-alignment-fault-in-accessing-ACPI-tables-at-kdump/20180203-174725
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   arch/arm64/kernel/acpi.o: In function `__acpi_get_mem_attribute':
>> acpi.c:(.text+0x60): undefined reference to `efi_mem_attributes'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump

[kbuild test robot]

Hi AKASHI,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.16-rc1 next-20180216]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/AKASHI-Takahiro/arm64-acpi-efi-fix-alignment-fault-in-accessing-ACPI-tables-at-kdump/20180203-174725
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git 
for-next/core
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   arch/arm64/kernel/acpi.o: In function `__acpi_get_mem_attribute':
>> acpi.c:(.text+0x60): undefined reference to `efi_mem_attributes'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] proc: move /proc/sysvipc creation to where it belongs

[Alexey Dobriyan]

Signed-off-by: Alexey Dobriyan 
---

 fs/proc/root.c |4 
 ipc/util.c |1 +
 2 files changed, 1 insertion(+), 4 deletions(-)

--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -136,10 +136,6 @@ void __init proc_root_init(void)
proc_symlink("mounts", NULL, "self/mounts");
 
proc_net_init();
-
-#ifdef CONFIG_SYSVIPC
-   proc_mkdir("sysvipc", NULL);
-#endif
proc_mkdir("fs", NULL);
proc_mkdir("driver", NULL);
proc_create_mount_point("fs/nfsd"); /* somewhere for the nfsd 
filesystem to be mounted */
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -89,6 +89,7 @@ static int __init ipc_init(void)
 {
int err_sem, err_msg;
 
+   proc_mkdir("sysvipc", NULL);
err_sem = sem_init();
WARN(err_sem, "ipc: sysv sem_init failed: %d\n", err_sem);
err_msg = msg_init();

[PATCH] proc: move /proc/sysvipc creation to where it belongs

[Alexey Dobriyan]

Signed-off-by: Alexey Dobriyan 
---

 fs/proc/root.c |4 
 ipc/util.c |1 +
 2 files changed, 1 insertion(+), 4 deletions(-)

--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -136,10 +136,6 @@ void __init proc_root_init(void)
proc_symlink("mounts", NULL, "self/mounts");
 
proc_net_init();
-
-#ifdef CONFIG_SYSVIPC
-   proc_mkdir("sysvipc", NULL);
-#endif
proc_mkdir("fs", NULL);
proc_mkdir("driver", NULL);
proc_create_mount_point("fs/nfsd"); /* somewhere for the nfsd 
filesystem to be mounted */
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -89,6 +89,7 @@ static int __init ipc_init(void)
 {
int err_sem, err_msg;
 
+   proc_mkdir("sysvipc", NULL);
err_sem = sem_init();
WARN(err_sem, "ipc: sysv sem_init failed: %d\n", err_sem);
err_msg = msg_init();

Re: [PATCH 4/6] scripts: kernel-doc: support in-line comments on nested structs/unions

[Markus Heiser]

> Am 16.02.2018 um 15:56 schrieb Mauro Carvalho Chehab 
> :
> 
> Em Fri, 16 Feb 2018 15:52:33 +0100
> Markus Heiser  escreveu:
> 
>>> Am 16.02.2018 um 14:48 schrieb Mauro Carvalho Chehab 
>>> :
>>> 
>>> The parser at kernel-doc rejects names with dots in the middle.
>>> Fix it, in order to support nested structs/unions.
>>> 
>>> Tested-by: Jani Nikula 
>>> Signed-off-by: Mauro Carvalho Chehab 
>>> ---
>>> scripts/kernel-doc | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
>>> index fee8952037b1..06d7f3f2c094 100755
>>> --- a/scripts/kernel-doc
>>> +++ b/scripts/kernel-doc
>>> @@ -363,7 +363,7 @@ my $doc_sect = $doc_com .
>>> my $doc_content = $doc_com_body . '(.*)';
>>> my $doc_block = $doc_com . 'DOC:\s*(.*)?';
>>> my $doc_inline_start = '^\s*/\*\*\s*$';
>>> -my $doc_inline_sect = '\s*\*\s*(@[\w\s]+):(.*)';
>>> +my $doc_inline_sect = '\s*\*\s*(@\s*[\w][\w\.]*\s*):(.*)';  
>> 
>> Thanks!
>> 
>> FWIW: added similar patch to python variant of kernel-doc:
>> 
>> https://github.com/return42/linuxdoc/commit/5c5da9a
>> 
>> rendered example:
>> 
>>  
>> https://return42.github.io/linuxdoc/linuxdoc-howto/all-in-a-tumble.html#struct-my-long-struct
> 
> On a quick look, on your example, bar2.barbar description looks different
> than what we get from the perl version.
> 
> There, it generates it as:
> 
> ``bar2.barbar``
>  Description for **barbar** inside **foo.bar2**

very attentive, thanks a lot!

When I implemented support for nested data types, I missed
to fix the highlighting pattern of those.

  https://github.com/return42/linuxdoc/commit/4b43f419

rendered: 
https://return42.github.io/linuxdoc/linuxdoc-howto/all-in-a-tumble.html#struct-my-long-struct

-- Markus --

Re: [PATCH 4/6] scripts: kernel-doc: support in-line comments on nested structs/unions

[Markus Heiser]

> Am 16.02.2018 um 15:56 schrieb Mauro Carvalho Chehab 
> :
> 
> Em Fri, 16 Feb 2018 15:52:33 +0100
> Markus Heiser  escreveu:
> 
>>> Am 16.02.2018 um 14:48 schrieb Mauro Carvalho Chehab 
>>> :
>>> 
>>> The parser at kernel-doc rejects names with dots in the middle.
>>> Fix it, in order to support nested structs/unions.
>>> 
>>> Tested-by: Jani Nikula 
>>> Signed-off-by: Mauro Carvalho Chehab 
>>> ---
>>> scripts/kernel-doc | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
>>> index fee8952037b1..06d7f3f2c094 100755
>>> --- a/scripts/kernel-doc
>>> +++ b/scripts/kernel-doc
>>> @@ -363,7 +363,7 @@ my $doc_sect = $doc_com .
>>> my $doc_content = $doc_com_body . '(.*)';
>>> my $doc_block = $doc_com . 'DOC:\s*(.*)?';
>>> my $doc_inline_start = '^\s*/\*\*\s*$';
>>> -my $doc_inline_sect = '\s*\*\s*(@[\w\s]+):(.*)';
>>> +my $doc_inline_sect = '\s*\*\s*(@\s*[\w][\w\.]*\s*):(.*)';  
>> 
>> Thanks!
>> 
>> FWIW: added similar patch to python variant of kernel-doc:
>> 
>> https://github.com/return42/linuxdoc/commit/5c5da9a
>> 
>> rendered example:
>> 
>>  
>> https://return42.github.io/linuxdoc/linuxdoc-howto/all-in-a-tumble.html#struct-my-long-struct
> 
> On a quick look, on your example, bar2.barbar description looks different
> than what we get from the perl version.
> 
> There, it generates it as:
> 
> ``bar2.barbar``
>  Description for **barbar** inside **foo.bar2**

very attentive, thanks a lot!

When I implemented support for nested data types, I missed
to fix the highlighting pattern of those.

  https://github.com/return42/linuxdoc/commit/4b43f419

rendered: 
https://return42.github.io/linuxdoc/linuxdoc-howto/all-in-a-tumble.html#struct-my-long-struct

-- Markus --

Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent

[Christopher Lameter]

On Fri, 16 Feb 2018, Matthew Wilcox wrote:

> On Fri, Feb 16, 2018 at 09:44:25AM -0600, Christopher Lameter wrote:
> > On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> > > What I was proposing was an intermediate page allocator where slab would
> > > request 2MB for its own uses all at once, then allocate pages from that to
> > > individual slabs, so allocating a kmalloc-32 object and a dentry object
> > > would result in 510 pages of memory still being available for any slab
> > > that needed it.
> >
> > Well thats not really going to work since you would be mixing objects of
> > different sizes which may present more fragmentation problems within the
> > 2M later if they are freed and more objects are allocated.
>
> I don't understand this response.  I'm not suggesting mixing objects
> of different sizes within the same page.  The vast majority of slabs
> use order-0 pages, a few use order-1 pages and larger sizes are almost
> unheard of.  I'm suggesting the slab have it's own private arena of pages
> that it uses for allocating pages to slabs; when an entire page comes
> free in a slab, it is returned to the arena.  When the arena is empty,
> slab requests another arena from the page allocator.

This just shifts the fragmentation problem because the 2M page cannot be
released until all 4k or 8k pages within that 2M page are freed. How is
that different from the page allocator which cannot coalesce an 2M page
until all fragments have been released?

The kernelcore already does something similar by limiting the
general unmovable allocs to a section of memory.

> If you're concerned about order-0 allocations fragmenting the arena
> for order-1 slabs, then we could have separate arenas for order-0 and
> order-1.  But there should be no more fragmentation caused by sticking
> within an arena for page allocations than there would be by spreading
> slab allocations across all memory.

We avoid large frames at this point but they are beneficial to pack
objects tighter and also increase performance.

Maybe what we should do is raise the lowest allocation size instead and
allocate 2^x groups of pages to certain purposes?

I.e. have a base allocation size of 16k and if the alloc was a page cache
page then use the remainder for the neigboring pages.

Similar things could be done for the page allocator.

Raising the minimum allocation size may allow us to reduce the sizes
necessary to be allocated at the price of loosing some memory. On large
systems this may not matter much.

Re: [patch 1/2] mm, page_alloc: extend kernelcore and movablecore for percent

[Christopher Lameter]

On Fri, 16 Feb 2018, Matthew Wilcox wrote:

> On Fri, Feb 16, 2018 at 09:44:25AM -0600, Christopher Lameter wrote:
> > On Thu, 15 Feb 2018, Matthew Wilcox wrote:
> > > What I was proposing was an intermediate page allocator where slab would
> > > request 2MB for its own uses all at once, then allocate pages from that to
> > > individual slabs, so allocating a kmalloc-32 object and a dentry object
> > > would result in 510 pages of memory still being available for any slab
> > > that needed it.
> >
> > Well thats not really going to work since you would be mixing objects of
> > different sizes which may present more fragmentation problems within the
> > 2M later if they are freed and more objects are allocated.
>
> I don't understand this response.  I'm not suggesting mixing objects
> of different sizes within the same page.  The vast majority of slabs
> use order-0 pages, a few use order-1 pages and larger sizes are almost
> unheard of.  I'm suggesting the slab have it's own private arena of pages
> that it uses for allocating pages to slabs; when an entire page comes
> free in a slab, it is returned to the arena.  When the arena is empty,
> slab requests another arena from the page allocator.

This just shifts the fragmentation problem because the 2M page cannot be
released until all 4k or 8k pages within that 2M page are freed. How is
that different from the page allocator which cannot coalesce an 2M page
until all fragments have been released?

The kernelcore already does something similar by limiting the
general unmovable allocs to a section of memory.

> If you're concerned about order-0 allocations fragmenting the arena
> for order-1 slabs, then we could have separate arenas for order-0 and
> order-1.  But there should be no more fragmentation caused by sticking
> within an arena for page allocations than there would be by spreading
> slab allocations across all memory.

We avoid large frames at this point but they are beneficial to pack
objects tighter and also increase performance.

Maybe what we should do is raise the lowest allocation size instead and
allocate 2^x groups of pages to certain purposes?

I.e. have a base allocation size of 16k and if the alloc was a page cache
page then use the remainder for the neigboring pages.

Similar things could be done for the page allocator.

Raising the minimum allocation size may allow us to reduce the sizes
necessary to be allocated at the price of loosing some memory. On large
systems this may not matter much.