date:20180619

Commit-ID:  0fe2795516b9e1c59b58b02bdf8658698117ec4e
Gitweb: https://git.kernel.org/tip/0fe2795516b9e1c59b58b02bdf8658698117ec4e
Author: Arnd Bergmann 
AuthorDate: Mon, 18 Jun 2018 16:07:59 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 19 Jun 2018 09:23:19 +0200

posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIME

Commit b5793b0d92c9 added support for building the nanosleep compat system
call on 32-bit architectures, but missed one change in nanosleep_copyout(),
which would trigger a BUG() as soon as any architecture is switched over to
use it.

Use the proper config symbol to enable the code path.

Fixes: Commit b5793b0d92c9 ("posix-timers: Make compat syscalls depend on 
CONFIG_COMPAT_32BIT_TIME")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Thomas Gleixner 
Cc: y2...@lists.linaro.org
Cc: Anna-Maria Gleixner 
Cc: Deepa Dinamani 
Cc: "Rafael J. Wysocki" 
Link: https://lkml.kernel.org/r/20180618140811.2998503-1-a...@arndb.de

---
 kernel/time/hrtimer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 055a4a728c00..3e93c54bd3a1 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1659,7 +1659,7 @@ EXPORT_SYMBOL_GPL(hrtimer_init_sleeper);
 int nanosleep_copyout(struct restart_block *restart, struct timespec64 *ts)
 {
switch(restart->nanosleep.type) {
-#ifdef CONFIG_COMPAT
+#ifdef CONFIG_COMPAT_32BIT_TIME
case TT_COMPAT:
if (compat_put_timespec64(ts, restart->nanosleep.compat_rmtp))
return -EFAULT;

Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller

2018-06-19 Thread Boris Brezillon

Hi Yogesh,

Could you please use a mailer that is quoting things correctly. I have
a hard time differentiating your replies from mine.

On Tue, 19 Jun 2018 07:10:37 +
Yogesh Narayan Gaur  wrote:

> Let us take below layout of memory address space map.
> QuadSPI Controller can access range from 0x2000_ - 0x2FFF_ i.e. 256 
> MB address space reserved and it is having 4 slave devices connected.
> These slave devices[of size 64MB, 64MB, 32MB and 64MB ] are connected at 
> below address
> 0x2000_, 0x2400_, 0x2A00_, 0x2C00_
> i.e. there is gap of 32MB from 0x2800_ to 0x29FF_.

Okay, I'm fine with pre-reserving 32MB per chip select.

> 
> As per my understanding of the controller, flash XX top address, register 
> should have below values:
>   QUADSPI_SFA1AD - 0x0
>   QUADSPI_SFA2AD - 0x400_
>   QUADSPI_SFB1AD - 0xA00_
>   QUADSPI_SFB2AD - 0xC00_
> And Register QUADSPI_SFAR should point to the range for the flash in which 
> operation is happening.

Wait, I thought it was supposed to be an absolute address, not one
relative to the 0x2000 offset.

> 
> Please check Table10-32, page 1657, in [1] for more details on flash address 
> assignment.

Yes, I still don't see where it says that having one of the range with
a zero size is forbidden, or anything mentioning a required alignment.

> 
> But say if I assign address to register QUADSPI_SFA2AD as "0 + 2 * 
> ->ahb_buf_size" then this address value is not correct as per the value range 
> explained in above mentioned table.

Why? If the SFA1AD is set to zero, that should not, right?

Re: [PATCH v2 6/7] mm, proc: add KReclaimable to /proc/meminfo

2018-06-19 Thread Vlastimil Babka

On 06/18/2018 11:33 PM, Andrew Morton wrote:
> On Mon, 18 Jun 2018 11:18:07 +0200 Vlastimil Babka  wrote:
> 
>> The vmstat NR_KERNEL_MISC_RECLAIMABLE counter is for kernel non-slab
>> allocations that can be reclaimed via shrinker. In /proc/meminfo, we can show
>> the sum of all reclaimable kernel allocations (including slab) as
>> "KReclaimable". Add the same counter also to per-node meminfo under /sys
> 
> Why do you consider this useful enough to justify adding it to
> /pro/meminfo?  How will people use it, what benefit will they see, etc?

Let's add this:

With this counter, users will have more complete information about
kernel memory usage. Non-slab reclaimable pages (currently just the ION
allocator) will not be missing from /proc/meminfo, making users wonder
where part of their memory went. More precisely, they already appear in
MemAvailable, but without the new counter, it's not obvious why the
value in MemAvailable doesn't fully correspond with the sum of other
counters participating in it.

> Maybe you've undersold this whole patchset, but I'm struggling a bit to
> see what the end-user benefits are.  What would be wrong with just
> sticking with what we have now?

Fair enough, I will add more info in reply to the cover letter.

Re: [PATCH 2/2] rcutorture: Fix rcu_barrier successes counter

2018-06-19 Thread Joel Fernandes

On Mon, Jun 18, 2018 at 11:22:15PM -0700, Joel Fernandes wrote:
> From: "Joel Fernandes (Google)" 
> 
> rcutorture currently increments both successes and error counters for
> the rcu_barrier test incase of errors. It should only increment the
> error counter incase of errors so make it do so.
> 
> Test: Introduced rcu_barrier errors by returning from the barrier
> callback without incrementing the callback counter.

Hi Paul,
Think some more about this counter, I think you mean 'successes' as in
'successful attempts' than 'successful test' ? If so, then perhaps you can
drop this patch. It wasn't clear to me what the 'successes' meant so I may
have been a bit misled into changing its meaning. If on the other hand, it
means 'successful test', then yes this patch would be Ok then. thanks! -Joel

[PATCH 2/2] ARM: dts: imx6ul: Add DTS for ConnectCore 6UL SBC Express

2018-06-19 Thread Alex Gonzalez

The ConnectCore 6UL Single Board Computer (SBC) Express contains the
ConnectCore 6UL System-On-Module.

Its hardware specifications are:

* 256MB DDR3 memory
* 256MB NAND flash
* Single Ethernet
* USB Host and USB-OTG
* MicroSD external storage
* Groove connectors and Raspberry Pi Hat compatible expansion header

Signed-off-by: Alex Gonzalez 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts | 205 
 2 files changed, 206 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 37a3de760d40..6135d3dc381c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -533,6 +533,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-udoo-neo-full.dtb
 dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
+   imx6ul-ccimx6ulsbcexpress.dtb \
imx6ul-geam.dtb \
imx6ul-isiot-emmc.dtb \
imx6ul-isiot-nand.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts 
b/arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts
new file mode 100644
index ..1e3c4200b924
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Digi International's ConnectCore6UL SBC Express board device tree source
+ *
+ * Copyright 2018 Digi International, Inc.
+ *
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include "imx6ul.dtsi"
+#include "imx6ul-ccimx6ulsom.dtsi"
+
+/ {
+   model = "Digi International ConnectCore 6UL SBC Express.";
+   compatible = "digi,ccimx6ulsbcexpress", "digi,ccimx6ulsom",
+"fsl,imx6ul";
+};
+
+&adc1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_adc1>;
+   adc-ch-list = <4>;
+   status = "okay";
+};
+
+&ecspi3 {
+   fsl,spi-num-chipselects = <1>;
+   cs-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_ecspi3_master>;
+   status = "okay";
+};
+
+&fec1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_enet1>;
+   phy-mode = "rmii";
+   phy-handle = <ðphy0>;
+   status = "okay";
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethphy0: ethernet-phy@0 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   smsc,disable-energy-detect;
+   reg = <0>;
+   };
+   };
+};
+
+&can1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_flexcan1>;
+   xceiver-supply = <&ext_3v3>;
+   status = "okay";
+};
+
+&i2c2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c2>;
+   status = "okay";
+};
+
+&pwm1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_pwm1>;
+   status = "okay";
+};
+
+&uart4 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart4>;
+   status = "okay";
+};
+
+&uart5 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart5>;
+   status = "okay";
+};
+
+&usbotg1 {
+   dr_mode = "host";
+   disable-over-current;
+   status = "okay";
+};
+
+&usbotg2 {
+   dr_mode = "host";
+   disable-over-current;
+   status = "okay";
+};
+
+&usdhc2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usdhc2>;
+   broken-cd;  /* no carrier detect line (use polling) */
+   no-1-8-v;
+   status = "okay";
+};
+
+&iomuxc {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_hog>;
+
+   imx6ul-ccimx6ul {
+   pinctrl_adc1: adc1grp {
+   fsl,pins = <
+   /* GPIO1_4/ADC1_IN4 (pin 7 of the expansion 
header) */
+   MX6UL_PAD_GPIO1_IO04__GPIO1_IO040xb0
+   >;
+   };
+
+   pinctrl_ecspi3_master: ecspi3grp1 {
+   fsl,pins = <
+   MX6UL_PAD_UART2_RX_DATA__ECSPI3_SCLK0x10b0
+   MX6UL_PAD_UART2_CTS_B__ECSPI3_MOSI  0x10b0
+   MX6UL_PAD_UART2_RTS_B__ECSPI3_MISO  0x10b0
+   MX6UL_PAD_UART2_TX_DATA__GPIO1_IO20 0x10b0 
/* Chip Select */
+   >;
+   };
+
+   pinctrl_ecspi3_slave: ecspi3grp2 {
+   fsl,pins = <
+   MX6UL_PAD_UART2_RX_DATA__ECSPI3_SCLK0x10b0
+   MX6UL_PAD_UART2_CTS_B__ECSPI3_MOSI  0x10b0
+   MX6UL_PAD_UART2_RTS_B__ECSPI3_MISO  0x10b0
+   MX6UL_PAD_UART2_TX_DATA__ECSPI3_SS0 0x10b0 
/* Chip Select */
+   >;
+   };
+
+   pinctrl_enet1: enet1grp {
+   fsl

[PATCH 1/2] ARM: dts: imx6ul: Add DTS for ConnectCore 6UL System-On-Module (SOM)

2018-06-19 Thread Alex Gonzalez

The ConnectCore 6UL System-On-Module has the following hardware
specification:

* Based on a NXP i.MX6UL SoC
* Industrial temperature ranges (-40ºC to +85ºC)
* Up to 1GB DDR3 memory
* Up to 2GB NAND flash
* Dual Ethernet
* On module 802.11 WiFi and Bluetooth 4.2 (QCA6564)
* On module NXP Kinetis KL03
* On module Microchip ATECC508A crypto element

Signed-off-by: Alex Gonzalez 
---
 arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi | 199 ++
 1 file changed, 199 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi

diff --git a/arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi 
b/arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi
new file mode 100644
index ..23484a48f6e0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Digi International's ConnectCore 6UL System-On-Module device tree source
+ *
+ * Copyright 2018 Digi International, Inc.
+ *
+ */
+
+/ {
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   linux,cma {
+   compatible = "shared-dma-pool";
+   reusable;
+   size = <0x400>;
+   linux,cma-default;
+   };
+   };
+};
+
+&adc1 {
+   vref-supply = <&vdda_adc_3v3>;
+   max-channel = <9>;
+};
+
+&gpmi {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_gpmi_nand>;
+   status = "okay";
+};
+
+&i2c1 {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c1>;
+   status = "okay";
+
+   pmic: pfuze3000@8 {
+   compatible = "fsl,pfuze3000";
+   reg = <0x08>;
+
+   regulators {
+   int_3v3: sw1a {
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <330>;
+   regulator-ramp-delay = <6250>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
+   };
+
+   vdd_arm_soc_in: sw1b {
+   regulator-min-microvolt = <70>;
+   regulator-max-microvolt = <1475000>;
+   regulator-ramp-delay = <6250>;
+   regulator-boot-on;
+   regulator-always-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   regulator-suspend-microvolt = <925000>;
+   };
+   };
+
+   ext_3v3: sw2 {
+   regulator-min-microvolt = <250>;
+   regulator-max-microvolt = <330>;
+   regulator-ramp-delay = <6250>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-state-mem {
+   regulator-off-in-suspend;
+   };
+   };
+
+   vcc_ddr3: sw3 {
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <165>;
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-state-mem {
+   regulator-on-in-suspend;
+   regulator-suspend-microvolt = <130>;
+   };
+   };
+
+   swbst_reg: swbst {
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <515>;
+   };
+
+   vdd_snvs_3v3: vsnvs {
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vrefddr: vrefddr {
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vdda_adc_3v3: vldo1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vref-adc-3v3";
+   regulator-min-microvolt = <330>;
+

[PATCH 0/2] Add support for the ConnectCore 6UL SOM and SBC Express

2018-06-19 Thread Alex Gonzalez

This patchset adds a device tree include for the ConnectCore 6UL
System-On-Module and a device tree for the ConnectCore 6UL SBC Express board
that includes it.

Not all the SOM hardware is supported in this initial patchset, specifically
the 802.11 WiFi and BT chipset and the extended functionality provided by
the on module NXP Kinetis KL03 are not supported.

The SOM is based on NXP's i.MX6UL SoC, and the patchset is tested against
v4.18-rc1.

More information about the hardware can be found at:

ConnectCore 6UL SOM:
https://www.digi.com/products/embedded-systems/system-on-modules/connectcore-for-i-mx6ul

ConnectCore 6UL SBC Express board:
https://www.digi.com/products/embedded-systems/single-board-computers/connectcore-for-i-mx6ul-sbc-express

Alex Gonzalez (2):
  ARM: dts: imx6ul: Add DTS for ConnectCore 6UL System-On-Module (SOM)
  ARM: dts: imx6ul: Add DTS for ConnectCore 6UL SBC Express

 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts | 205 
 arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi   | 199 +++
 3 files changed, 405 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts
 create mode 100644 arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi

Re: [PATCH] staging: board: drop refcount in success case

2018-06-19 Thread Dan Carpenter

On Mon, Jun 18, 2018 at 08:53:19PM +0200, Nicholas Mc Guire wrote:
>  The call to of_find_compatible_node() returns irqc_node with refcount
> incremented thus it must be explicitly decremented here after it was
> checked for non-NULL.
> 
> Signed-off-by: Nicholas Mc Guire 
> Fixes: commit 72ee8626eeb1 ("staging: board: Add support for translating 
> hwirq to virq numbers")
> ---
> 
> Problem located with an experimental coccinelle script
> 
> Patch was compile-tested with: x86_64_defconfig + STAGING=y, STAGING_BOARD=y
> 
> Patch is against 4.18-rc1 (localversion-next is next-20180618)
> 
>  drivers/staging/board/board.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/board/board.c b/drivers/staging/board/board.c
> index cb6feb3..8ee48e5 100644
> --- a/drivers/staging/board/board.c
> +++ b/drivers/staging/board/board.c
> @@ -64,12 +64,13 @@ int __init board_staging_gic_setup_xlate(const char 
> *gic_match,
>   irqc_node = of_find_compatible_node(NULL, NULL, gic_match);
>  
>   WARN_ON(!irqc_node);
>   if (!irqc_node)
>   return -ENOENT;
>  
> + of_node_put(irqc_node);

I don't feel like this is the right thing...  We should keep the
reference until we're done with it.  Which apparently is never?

But I don't know the code at all so I could be wrong.

regards,
dan carpenter

[PATCH v6 09/29] drm/mediatek: add component DSI3

2018-06-19 Thread Stu Hsieh

This patch add the component DSI3

Signed-off-by: Stu Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 071f9f5aefea..17b681686471 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -228,6 +228,7 @@ static const struct mtk_ddp_comp_match 
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_DSI0]= { MTK_DSI,0, NULL },
[DDP_COMPONENT_DSI1]= { MTK_DSI,1, NULL },
[DDP_COMPONENT_DSI2]= { MTK_DSI,2, NULL },
+   [DDP_COMPONENT_DSI3]= { MTK_DSI,3, NULL },
[DDP_COMPONENT_GAMMA]   = { MTK_DISP_GAMMA, 0, &ddp_gamma },
[DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, &ddp_od },
[DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, &ddp_od },
@@ -280,6 +281,7 @@ int mtk_ddp_comp_init(struct device *dev, struct 
device_node *node,
comp_id == DDP_COMPONENT_DPI1 ||
comp_id == DDP_COMPONENT_DSI0 ||
comp_id == DDP_COMPONENT_DSI2 ||
+   comp_id == DDP_COMPONENT_DSI3 ||
comp_id == DDP_COMPONENT_PWM0) {
comp->regs = NULL;
comp->clk = NULL;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 8d152b337f15..7413ffeb3c9d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -51,6 +51,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_DSI0,
DDP_COMPONENT_DSI1,
DDP_COMPONENT_DSI2,
+   DDP_COMPONENT_DSI3,
DDP_COMPONENT_GAMMA,
DDP_COMPONENT_OD0,
DDP_COMPONENT_OD1,
-- 
2.12.5

Re: your mail

2018-06-19 Thread Dan Carpenter

Thanks for this.  This is a lot of work.

On Wed, Jun 13, 2018 at 08:31:28PM +0300, Anton Vasilyev wrote:
> diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
> index 70e0b8623110..69e6abe14abf 100644
> --- a/drivers/staging/rts5208/rtsx.c
> +++ b/drivers/staging/rts5208/rtsx.c
> @@ -857,7 +857,7 @@ static int rtsx_probe(struct pci_dev *pci,
>   dev->chip = kzalloc(sizeof(*dev->chip), GFP_KERNEL);
>   if (!dev->chip) {
>   err = -ENOMEM;
> - goto errout;
> + goto chip_alloc_fail;

The most recent successful allocation is scsi_host_alloc().  I was
really hoping this would say something like "goto err_free_host;" or
something.  The naming style here is a "come from" label which doesn't
say if it's going to free the scsi host or not...  It turns out we don't
free the the host, but we should:

err_put_host:
scsi_host_put(host);

The kzalloc() has it's own error message built in, and all the other
error paths as well so the dev_err() is not super important to me...

Killing the threads seems actually really complicated so maybe we should
just have a separate error paths for that.  I'm not sure...

regards,
dan carpenter

Re: [PATCH 4.16 000/279] 4.16.17-stable review

2018-06-19 Thread Naresh Kamboju

On 18 June 2018 at 13:39, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.16.17 release.
> There are 279 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jun 20 08:05:28 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.17-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.16.17-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.16.y
git commit: 957de898f0f3aac469028d303d1384bc0a975e93
git describe: v4.16.16-279-g957de898f0f3
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.16-279-g957de898f0f3

No regressions (compared to build v4.16.16-280-g893364ab48d9)

Ran 11514 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-filecaps-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation

2018-06-19 Thread Ard Biesheuvel

On 19 June 2018 at 07:07, Guenter Roeck  wrote:
> Modern assemblers may take the ISA into account when resolving local
> symbols. This can result in bad address calculations when using badr
> in the wrong location since the offset + 1 may be added twice, resulting
> in an even address target for THUMB instructions. This in turn results
> in an exception at (destination address + 2).
>
> Unhandled exception: IPSR = 0006 LR = fff1
> CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
> Hardware name: MPS2 (Device Tree Support)
> PC is at ret_fast_syscall+0x2/0x58
> LR is at tty_ioctl+0x2a5/0x528
> pc : [<21009002>]lr : [<210d1535>]psr: 400b
> sp : 21825fa8  ip : 001c  fp : 21a95892
> r10:   r9 : 21824000  r8 : 210091c0
> r7 : 0036  r6 : 21ae1ee0  r5 :   r4 : 21ae1f3c
> r3 :   r2 : 3d9adc25  r1 :   r0 : 
> xPSR: 400b
> CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
> Hardware name: MPS2 (Device Tree Support)
> [<2100bd8d>] (unwind_backtrace) from [<2100b13b>] (show_stack+0xb/0xc)
> [<2100b13b>] (show_stack) from [<2100b87b>] (__invalid_entry+0x4b/0x4c)
>
> Fix the problem by using a logical or instead of an addition. This is
> less efficient but guaranteed to work.
>
> Signed-off-by: Guenter Roeck 
> ---
> RFC: I don't really like this, but my ARM assembler knowledge is quite
> limited. Just dropping the "+ 1" from badr doesn't work because some
> other code needs it (the image hangs completely if I try that).
> Ultimately I don't even know if the invoke_syscall macro should just
> have used adr instead of badr (but then how did this ever work ?).
>
> Seen with various toolchains based on gcc 7.x and binutils 2.30 when
> building and testing MPS2 images.
>

Hello Guenter,

This issue has been discussed before. It appears the binutils people
suddenly started caring about the thumb annotation of local function
symbols, resulting in behavior that is not backwards compatible.

https://marc.info/?l=linux-arm-kernel&m=151143776213636&w=2
https://sourceware.org/bugzilla/show_bug.cgi?id=21458

Can you try the fix below please?

>  arch/arm/include/asm/assembler.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/assembler.h 
> b/arch/arm/include/asm/assembler.h
> index 0cd4dccbae78..24c87ff2060f 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -195,7 +195,8 @@
> .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
> .macro  badr\c, rd, sym
>  #ifdef CONFIG_THUMB2_KERNEL
> -   adr\c   \rd, \sym + 1
> +   adr\c   \rd, \sym
> +   orr \rd, #1
>  #else
> adr\c   \rd, \sym
>  #endif
> --
> 2.7.4

--8<
From: Ard Biesheuvel 
Date: Tue, 16 Jan 2018 12:12:45 +
Subject: [PATCH] ARM: assembler: prevent ADR from setting the Thumb bit twice

To work around recent issues where ADR references to Thumb function
symbols may or may not have the Thumb bit set already when they are
resolved by GAS, reference the symbol indirectly via a local symbol
typed as 'object', stripping the ARM/Thumb annotation.

Signed-off-by: Ard Biesheuvel 

diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 6ae42ad29518..dd2ff94ad90b 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -195,13 +195,19 @@
.irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro  badr\c, rd, sym
 #ifdef CONFIG_THUMB2_KERNEL
-   adr\c   \rd, \sym + 1
+   __badr  \c, \rd, \sym
 #else
adr\c   \rd, \sym
 #endif
.endm
.endr

+   /* this needs to be a separate macro or \@ does not work correctly */
+   .macro  __badr, c, rd, sym
+   .eqv.Lsym\@, \sym
+   adr\c   \rd, .Lsym\@ + 1
+   .endm
+
 /*
  * Get current thread_info.
  */

Re: [PATCH] staging: board: drop refcount in success case

2018-06-19 Thread Geert Uytterhoeven

On Tue, Jun 19, 2018 at 9:37 AM Dan Carpenter  wrote:
> On Mon, Jun 18, 2018 at 08:53:19PM +0200, Nicholas Mc Guire wrote:
> >  The call to of_find_compatible_node() returns irqc_node with refcount
> > incremented thus it must be explicitly decremented here after it was
> > checked for non-NULL.
> >
> > Signed-off-by: Nicholas Mc Guire 
> > Fixes: commit 72ee8626eeb1 ("staging: board: Add support for translating 
> > hwirq to virq numbers")
> > ---
> >
> > Problem located with an experimental coccinelle script
> >
> > Patch was compile-tested with: x86_64_defconfig + STAGING=y, STAGING_BOARD=y
> >
> > Patch is against 4.18-rc1 (localversion-next is next-20180618)
> >
> >  drivers/staging/board/board.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/staging/board/board.c b/drivers/staging/board/board.c
> > index cb6feb3..8ee48e5 100644
> > --- a/drivers/staging/board/board.c
> > +++ b/drivers/staging/board/board.c
> > @@ -64,12 +64,13 @@ int __init board_staging_gic_setup_xlate(const char 
> > *gic_match,
> >   irqc_node = of_find_compatible_node(NULL, NULL, gic_match);
> >
> >   WARN_ON(!irqc_node);
> >   if (!irqc_node)
> >   return -ENOENT;
> >
> > + of_node_put(irqc_node);
>
> I don't feel like this is the right thing...  We should keep the
> reference until we're done with it.  Which apparently is never?

Indeed. The reference must not be released in this function, as it's stored in
a global variable, and used later.

As all users are __init, it could be released when the init section is freeed,
in theory, but there's no callback for that.

Hence:
NAKed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation

2018-06-19 Thread Ard Biesheuvel

On 19 June 2018 at 09:48, Ard Biesheuvel  wrote:
> On 19 June 2018 at 07:07, Guenter Roeck  wrote:
>> Modern assemblers may take the ISA into account when resolving local
>> symbols. This can result in bad address calculations when using badr
>> in the wrong location since the offset + 1 may be added twice, resulting
>> in an even address target for THUMB instructions. This in turn results
>> in an exception at (destination address + 2).
>>
>> Unhandled exception: IPSR = 0006 LR = fff1
>> CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
>> Hardware name: MPS2 (Device Tree Support)
>> PC is at ret_fast_syscall+0x2/0x58
>> LR is at tty_ioctl+0x2a5/0x528
>> pc : [<21009002>]lr : [<210d1535>]psr: 400b
>> sp : 21825fa8  ip : 001c  fp : 21a95892
>> r10:   r9 : 21824000  r8 : 210091c0
>> r7 : 0036  r6 : 21ae1ee0  r5 :   r4 : 21ae1f3c
>> r3 :   r2 : 3d9adc25  r1 :   r0 : 
>> xPSR: 400b
>> CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
>> Hardware name: MPS2 (Device Tree Support)
>> [<2100bd8d>] (unwind_backtrace) from [<2100b13b>] (show_stack+0xb/0xc)
>> [<2100b13b>] (show_stack) from [<2100b87b>] (__invalid_entry+0x4b/0x4c)
>>
>> Fix the problem by using a logical or instead of an addition. This is
>> less efficient but guaranteed to work.
>>
>> Signed-off-by: Guenter Roeck 
>> ---
>> RFC: I don't really like this, but my ARM assembler knowledge is quite
>> limited. Just dropping the "+ 1" from badr doesn't work because some
>> other code needs it (the image hangs completely if I try that).
>> Ultimately I don't even know if the invoke_syscall macro should just
>> have used adr instead of badr (but then how did this ever work ?).
>>
>> Seen with various toolchains based on gcc 7.x and binutils 2.30 when
>> building and testing MPS2 images.
>>
>
> Hello Guenter,
>
> This issue has been discussed before. It appears the binutils people
> suddenly started caring about the thumb annotation of local function
> symbols, resulting in behavior that is not backwards compatible.
>
> https://marc.info/?l=linux-arm-kernel&m=151143776213636&w=2
> https://sourceware.org/bugzilla/show_bug.cgi?id=21458
>
> Can you try the fix below please?
>
>>  arch/arm/include/asm/assembler.h | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/asm/assembler.h 
>> b/arch/arm/include/asm/assembler.h
>> index 0cd4dccbae78..24c87ff2060f 100644
>> --- a/arch/arm/include/asm/assembler.h
>> +++ b/arch/arm/include/asm/assembler.h
>> @@ -195,7 +195,8 @@
>> .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
>> .macro  badr\c, rd, sym
>>  #ifdef CONFIG_THUMB2_KERNEL
>> -   adr\c   \rd, \sym + 1
>> +   adr\c   \rd, \sym
>> +   orr \rd, #1
>>  #else
>> adr\c   \rd, \sym
>>  #endif
>> --
>> 2.7.4
>
> --8<
> From: Ard Biesheuvel 
> Date: Tue, 16 Jan 2018 12:12:45 +
> Subject: [PATCH] ARM: assembler: prevent ADR from setting the Thumb bit twice
>
> To work around recent issues where ADR references to Thumb function
> symbols may or may not have the Thumb bit set already when they are
> resolved by GAS, reference the symbol indirectly via a local symbol
> typed as 'object', stripping the ARM/Thumb annotation.
>
> Signed-off-by: Ard Biesheuvel 
>
> diff --git a/arch/arm/include/asm/assembler.h 
> b/arch/arm/include/asm/assembler.h
> index 6ae42ad29518..dd2ff94ad90b 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -195,13 +195,19 @@
> .irpc,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
> .macro  badr\c, rd, sym
>  #ifdef CONFIG_THUMB2_KERNEL
> -   adr\c   \rd, \sym + 1
> +   __badr  \c, \rd, \sym
>  #else
> adr\c   \rd, \sym
>  #endif
> .endm
> .endr
>
> +   /* this needs to be a separate macro or \@ does not work correctly */
> +   .macro  __badr, c, rd, sym
> +   .eqv.Lsym\@, \sym
> +   adr\c   \rd, .Lsym\@ + 1
> +   .endm
> +
>  /*
>   * Get current thread_info.
>   */

Never mind - it doesn't work. (I tested it locally but with the wrong kernel)

Re: [PATCH] printk/nmi: Prevent deadlock when serializing NMI backtraces

2018-06-19 Thread Petr Mladek

On Mon 2018-06-18 19:07:18, Sergey Senozhatsky wrote:
> On (06/18/18 11:39), Petr Mladek wrote:
> [..]
> > > >  extern void printk_nmi_enter(void);
> > > >  extern void printk_nmi_exit(void);
> > > > +extern void printk_nmi_direct_enter(void);
> > > > +extern void printk_nmi_direct_exit(void);
> > > >  #else
> > > >  static inline void printk_nmi_enter(void) { }
> > > >  static inline void printk_nmi_exit(void) { }
> > > > +static void printk_nmi_direct_enter(void) { }
> > > > +static void printk_nmi_direct_exit(void) { }
> > > 
> > > Can we have better names may be? Since direct printk_nmi is not
> > > in fact always `direct'.
> > 
> > What about printk_chatty_nmi_enter(), printk_large_nmi_enter()
> > or something similar?
> 
> Hmm. Can't answer right now :)

Please, let me know what name you would like ;-)


> > > > +#ifdef CONFIG_PRINTK_NMI
> > > > +__printf(1, 0) int vprintk_nmi(const char *fmt, va_list args);
> > > > +#else
> > > > +__printf(1, 0) int vprintk_nmi(const char *fmt, va_list args) { return 
> > > > 0; }
> > > > +#endif
> > > 
> > > Hmm, printk_safe.c knows about printk.c, printk.c knows about
> > > printk_safe.c.
> 
> Just wanted to suggest to keep printk_safe/printk_nmi stuff in printk_safe.c.
> We already have everything we need there, so let's just add the vprintk_nmi()
> fallback, avoiding spreading printk_safe/printk_nmi logic and details across
> printk.c and printk_safe.c

This won't be needed in v2 where the decision will be made in vprintk_func().


> > > OK... Can we do this in vprintk_func()? The race window should be super
> > > tiny [if matters at all], but in exchange we don't have to mix nmi, 
> > > printk,
> > > printk_mni, etc.
> > 
> > You are right that it would still solve the main risk (NMI comes
> > inside logbuf_lock critical section).
> > 
> > In fact, the only real risk would be another lock serializing NMIs
> > and printk() called with that lock. This patch removes one in
> > nmi_backtrace() and I am not aware of any other.
> > 
> > The less hairy code really might be worth the rather theoretical risk.
> 
> Does this mean that we agreed to handle the printk_nmi per-CPU buffer
> fallback in printk_safe.c?

Yes, I feel persuaded.

Best Regards,
Petr

Re: [PATCH v4 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings

2018-06-19 Thread Taniya Das





On 6/18/2018 2:51 PM, Sudeep Holla wrote:



On 15/06/18 18:40, Taniya Das wrote:



On 6/15/2018 5:29 PM, Amit Kucheria wrote:


[...]


A future version of the HW engine, or more likely, a firmware
revision, will make more functionality available. Say, this needs
access to another register or two. This will require changing the DT
bindings. Instead, if you map the entire address space, you can just
add offsets to the new registers.

So in this case, I think you should define the following addresses
(size 0x1400) for the two frequency domains

0x17d43000, 0x1400 (power cluster)
0x17d45800, 0x1400 (perf cluster)

And in the driver simply add offsets as follows:

#define ENABLE_OFFSET   0x0
#define LUT_OFFSET  0x110
#define PERF_DESIRED_OFFSET 0x920



The offsets could vary across versions of this IP and that is the reason
to provide them through the DT and not define any such offsets.



Just get compatibles to identify the version of the hardware if it can't
be probed and detected. Please don't use DT to get the addresses of each
register you use in the driver. That's neither scalable nor nice
solution to the problem.
Hello Sudeep and Amit,


Thanks for the comments, I am consolidating the understanding from the 
other emails in a single one.


I understand that you are looking for this IP to map the full region and 
define offsets according to access them.


But I still not sure how do you want this common driver to scale in the 
cases where the offsets could vary across version change.


 DT

  freq-node {
reg = < X x_size>;   Where X is the start of the IP address.
  }

Driver code (The below representation is just for example).
=

V1
#define ENABLE  0x0
#define LUT_V1  0x110
#define PERF_V1 0x920

V2
#define LUT_V2  0x150
#define PERF_V2 0x980

V3
#define LUT_V3  0x120


Do you want me to use "compatible" flag to

if (compatible == v1)
 enable =  readl_relaxed(X + LUT_V1);
else if (compatible == v2)
 enable = readl_relaxed(X + LUT_V2);
else if (compatible == v3)
 enable = readl_relaxed(X + LUT_V2);

With the current design I do not need such compatible checks and unmap 
the ones which are not required after probe. Please let me know your 
comments.


--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

Re: [PATCH v2 0/7] kmalloc-reclaimable caches

2018-06-19 Thread Vlastimil Babka

On 06/18/2018 11:18 AM, Vlastimil Babka wrote:
> v2 changes:
> - shorten cache names to kmalloc-rcl-
> - last patch shortens  for all kmalloc caches to e.g. "1k", "4M"
> - include dma caches to the 2D kmalloc_caches[] array to avoid a branch
> - vmstat counter nr_indirectly_reclaimable_bytes renamed to
>   nr_kernel_misc_reclaimable, doesn't include kmalloc-rcl-*
> - /proc/meminfo counter renamed to KReclaimable, includes kmalloc-rcl*
>   and nr_kernel_misc_reclaimable
> 
> Hi,
> 
> as discussed at LSF/MM [1] here's a patchset that introduces
> kmalloc-reclaimable caches (more details in the second patch) and uses them 
> for
> SLAB freelists and dcache external names. The latter allows us to repurpose 
> the
> NR_INDIRECTLY_RECLAIMABLE_BYTES counter later in the series.

More info about user benefits of the patchset:

With patch 4, dcache external names are allocated from kmalloc-rcl-*
caches, eliminating the need for manual accounting. More importantly, it
also ensures the reclaimable kmalloc allocations are grouped in pages
separate from the regular kmalloc allocations. The need for proper
accounting of dcache external names has shown it's easy for misbehaving
process to allocate lots of them, causing premature OOMs. Without the
added grouping, it's likely that similar workload can interleave the
dcache external names allocations with regular kmalloc allocations
(note: I haven't searched myself for an example of such regular kmalloc
allocation, but I would be very surprised if there wasn't some). A
pathological case would be e.g. one 64byte regular allocations with 63
external dcache names in a page (64x64=4096), which means the page is
not freed even after reclaiming after all dcache names, and the process
can thus steal the whole page with single 64byte allocation.

If there other kmalloc users similar to dcache external names become
identified, they can also benefit from the new functionality simply by
adding __GFP_RECLAIMABLE to the kmalloc calls.

Side benefits of the patchset (that could be also merged separately)
include removed branch for detecting __GFP_DMA kmalloc(), and shortening
kmalloc cache names in /proc/slabinfo output. The latter is potentially
an ABI break in case there are tools parsing the names and expecting the
values to be in bytes.

Re: [RFC PATCH v3 09/10] sched/fair: Select an energy-efficient CPU on task wake-up

2018-06-19 Thread Quentin Perret

Hi Pavan,

On Tuesday 19 Jun 2018 at 10:36:01 (+0530), Pavan Kondeti wrote:
> On Mon, May 21, 2018 at 03:25:04PM +0100, Quentin Perret wrote:
> 
> 
> 
> > +   if (cpumask_test_cpu(prev_cpu, &p->cpus_allowed))
> > +   prev_energy = best_energy = compute_energy(p, prev_cpu);
> > +   else
> > +   prev_energy = best_energy = ULONG_MAX;
> > +
> > +   for_each_freq_domain(sfd) {
> > +   unsigned long spare_cap, max_spare_cap = 0;
> > +   int max_spare_cap_cpu = -1;
> > +   unsigned long util;
> > +
> > +   /* Find the CPU with the max spare cap in the freq. dom. */
> > +   for_each_cpu_and(cpu, freq_domain_span(sfd), 
> > sched_domain_span(sd)) {
> > +   if (!cpumask_test_cpu(cpu, &p->cpus_allowed))
> > +   continue;
> > +
> > +   if (cpu == prev_cpu)
> > +   continue;
> > +
> > +   /* Skip CPUs that will be overutilized */
> > +   util = cpu_util_wake(cpu, p) + task_util;
> > +   cpu_cap = capacity_of(cpu);
> > +   if (cpu_cap * 1024 < util * capacity_margin)
> > +   continue;
> > +
> > +   spare_cap = cpu_cap - util;
> > +   if (spare_cap > max_spare_cap) {
> > +   max_spare_cap = spare_cap;
> > +   max_spare_cap_cpu = cpu;
> > +   }
> > +   }
> > +
> > +   /* Evaluate the energy impact of using this CPU. */
> > +   if (max_spare_cap_cpu >= 0) {
> > +   cur_energy = compute_energy(p, max_spare_cap_cpu);
> > +   if (cur_energy < best_energy) {
> > +   best_energy = cur_energy;
> > +   best_energy_cpu = max_spare_cap_cpu;
> > +   }
> > +   }
> > +   }
> > +
> > +   /*
> > +* We pick the best CPU only if it saves at least 1.5% of the
> > +* energy used by prev_cpu.
> > +*/
> > +   if ((prev_energy - best_energy) > (prev_energy >> 6))
> > +   return best_energy_cpu;
> > +
> > +   return prev_cpu;
> > +}
> 
> We are comparing the best_energy_cpu against prev_cpu even when prev_cpu
> can't accommodate the waking task. Is this intentional? Should not we
> discard the prev_cpu if it can't accommodate the task.
> 
> This can potentially make a BIG task run on a lower capacity CPU until
> load balancer kicks in and corrects the situation.

We shouldn't enter find_energy_efficient_cpu() in the first place if the
system is overutilized, so that shouldn't too much of an issue in
general.

But yeah, there is one small corner case where prev_cpu is overutilized
and the system has not been flagged as such yet (when the tasks wakes-up
shortly before the tick for ex). I think it's possible to cover this case
by extending the "if (cpumask_test_cpu(prev_cpu, &p->cpus_allowed))"
condition at the top of the function with a check on capacity_margin.

I'll change that in v4.

Thanks !
Quentin

Re: [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433

2018-06-19 Thread Krzysztof Kozlowski

On 19 June 2018 at 09:26, Marek Szyprowski  wrote:
> Hi Krzysztof,
>
> On 2018-06-18 19:42, Krzysztof Kozlowski wrote:
>> The decon, decon_tv and dsi nodes have only one child port so
>> address/size mappings are not necessary.  This fixes DTC warnings like:
>>
>>  Warning (graph_child_address): /soc/decon@1380/ports:
>>  graph node has single child node 'port@0', 
>> #address-cells/#size-cells are not necessary
>>
>> Signed-off-by: Krzysztof Kozlowski 
>
> Works fine with current Exynos DRM Decon/MIC/DSI drivers.
>
> Tested-by: Marek Szyprowski 

Thanks for review and testing!

Best regards,
Krzysztof

Re: [PATCH] proc: Make inline name size calculation automatic

2018-06-19 Thread David Howells

Andrew Morton  wrote:

> Please cc Alexey on /proc patches.

If Alexey is responsible for procfs he should declare this in MAINTAINERS.

> What are the user-visible runtime effects of this change?

Memory usage only.

David

Re: [PATCH v8] powercap/drivers/idle_injection: Add an idle injection framework

2018-06-19 Thread Daniel Lezcano

On 19/06/2018 08:22, Viresh Kumar wrote:
> On 19-06-18, 07:58, Daniel Lezcano wrote:
>> +++ b/drivers/powercap/idle_injection.c
>> @@ -0,0 +1,375 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright 2018 Linaro Limited
>> + *
>> + * Author: Daniel Lezcano 
>> + *
>> + * The idle injection framework proposes a way to force a cpu to enter
>> + * an idle state during a specified amount of time for a specified
>> + * period.
>> + *
>> + * It relies on the smpboot kthreads which handles, via its main loop,
>> + * the common code for hotplugging and [un]parking.
>> + *
>> + * At init time, all the kthreads are created.
>> + *
>> + * A cpumask is specified as parameter for the idle injection
>> + * registering function. The kthreads will be synchronized regarding
>> + * this cpumask.
>> + *
>> + * The idle + run duration is specified via the helpers and then the
>> + * idle injection can be started at this point.
>> + *
>> + * A kthread will call play_idle() with the specified idle duration
>> + * from above.
>> + *
>> + * A timer is set after waking up all the tasks, to the next idle
>> + * injection cycle.
>> + *
>> + * The task handling the timer interrupt will wakeup all the kthreads
>> + * belonging to the cpumask.
>> + *
>> + * Stopping the idle injection is synchonuous, when the function
> 
>  synchronous
> 
>> + * returns, there is the guarantee there is no more idle injection
>> + * kthread in activity.
>> + *
>> + * It is up to the user of this framework to provide a lock at an
>> + * upper level to prevent stupid things to happen, like starting while
>> + * we are unregistering.
>> + */
> 
>> +static void idle_injection_wakeup(struct idle_injection_device *ii_dev)
>> +{
>> +struct idle_injection_thread *iit;
>> +unsigned int cpu;
>> +
>> +for_each_cpu_and(cpu, to_cpumask(ii_dev->cpumask), cpu_online_mask) {
>> +iit = per_cpu_ptr(&idle_injection_thread, cpu);
>> +iit->should_run = 1;
>> +wake_up_process(iit->tsk);
>> +}
>> +}
> 
> Thread AThread B
> 
> CPU3 hotplug out
> -> idle_injection_park()
>   iit(of-CPU3)->should_run = 
> 0;
> 
> idle_injection_wakeup()
>  for_each_cpu_and(online)..
>CPU3-selected
> clear CPU3 from cpu-online 
> mask.
> 
> 
>iit(of-CPU3)->should_run = 1;
>wake_up_process()
> 
> With the above sequence of events, is it possible that the iit->should_run
> variable is set to 1 while the CPU is offlined ? And so the crash we discussed
> in the previous version may still exist ? Sorry I am not able to take my mind
> away from thinking about these stupid races :(

If I refer to previous Peter's comment about a similar race, I think it
is possible.

I guess setting the should_run flag to zero in the unpark() must fix the
issue also.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[tip:timers/core] timekeeping: Use ktime_get_real_ts64() instead of getnstimeofday64()

Commit-ID:  d30faff900e666f9a6395a159fdd353c02f5bed0
Gitweb: https://git.kernel.org/tip/d30faff900e666f9a6395a159fdd353c02f5bed0
Author: Arnd Bergmann 
AuthorDate: Mon, 18 Jun 2018 16:08:01 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 19 Jun 2018 09:56:26 +0200

timekeeping: Use ktime_get_real_ts64() instead of getnstimeofday64()

The two do the same, this moves all users to the newer name for consistency.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Thomas Gleixner 
Cc: John Stultz 
Cc: y2...@lists.linaro.org
Cc: Stephen Boyd 
Cc: Miroslav Lichvar 
Link: https://lkml.kernel.org/r/20180618140811.2998503-3-a...@arndb.de

---
 kernel/time/ntp.c | 6 +++---
 kernel/time/timekeeping.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index a09ded765f6c..10a79053e82f 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -502,7 +502,7 @@ static void sched_sync_hw_clock(struct timespec64 now,
 {
struct timespec64 next;
 
-   getnstimeofday64(&next);
+   ktime_get_real_ts64(&next);
if (!fail)
next.tv_sec = 659;
else {
@@ -537,7 +537,7 @@ static void sync_rtc_clock(void)
if (!IS_ENABLED(CONFIG_RTC_SYSTOHC))
return;
 
-   getnstimeofday64(&now);
+   ktime_get_real_ts64(&now);
 
adjust = now;
if (persistent_clock_is_local)
@@ -591,7 +591,7 @@ static bool sync_cmos_clock(void)
 * Architectures are strongly encouraged to use rtclib and not
 * implement this legacy API.
 */
-   getnstimeofday64(&now);
+   ktime_get_real_ts64(&now);
if (rtc_tv_nsec_ok(-1 * target_nsec, &adjust, &now)) {
if (persistent_clock_is_local)
adjust.tv_sec -= (sys_tz.tz_minuteswest * 60);
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4786df904c22..77c436a0070b 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2310,7 +2310,7 @@ int do_adjtimex(struct timex *txc)
return ret;
}
 
-   getnstimeofday64(&ts);
+   ktime_get_real_ts64(&ts);
 
raw_spin_lock_irqsave(&timekeeper_lock, flags);
write_seqcount_begin(&tk_core.seq);

[tip:timers/core] time: Use ktime_get_real_seconds() in time syscall

Commit-ID:  f5a89295e2f566d8e9f1d4f3d524d8d3c966958c
Gitweb: https://git.kernel.org/tip/f5a89295e2f566d8e9f1d4f3d524d8d3c966958c
Author: Arnd Bergmann 
AuthorDate: Mon, 18 Jun 2018 16:08:00 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 19 Jun 2018 09:56:26 +0200

time: Use ktime_get_real_seconds() in time syscall

Both get_seconds() and do_gettimeofday() are deprecated. Change the time()
implementation to use the replacement function instead.

Obviously the system call will still overflow in 2038, but this gets us
closer to removing the old helper functions.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Thomas Gleixner 
Cc: John Stultz 
Cc: y2...@lists.linaro.org
Cc: Stephen Boyd 
Cc: Deepa Dinamani 
Cc: Al Viro 
Link: https://lkml.kernel.org/r/20180618140811.2998503-2-a...@arndb.de

---
 kernel/time/time.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/time/time.c b/kernel/time/time.c
index 6fa99213fc72..b1225db61eb2 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -63,7 +63,7 @@ EXPORT_SYMBOL(sys_tz);
  */
 SYSCALL_DEFINE1(time, time_t __user *, tloc)
 {
-   time_t i = get_seconds();
+   time_t i = (time_t)ktime_get_real_seconds();
 
if (tloc) {
if (put_user(i,tloc))
@@ -106,11 +106,9 @@ SYSCALL_DEFINE1(stime, time_t __user *, tptr)
 /* compat_time_t is a 32 bit "long" and needs to get converted. */
 COMPAT_SYSCALL_DEFINE1(time, compat_time_t __user *, tloc)
 {
-   struct timeval tv;
compat_time_t i;
 
-   do_gettimeofday(&tv);
-   i = tv.tv_sec;
+   i = (compat_time_t)ktime_get_real_seconds();
 
if (tloc) {
if (put_user(i,tloc))

[tip:timers/core] sysinfo: Remove get_monotonic_boottime()

Commit-ID:  dc1b7b6ca9d5fa905c164a667086d8a3d8605875
Gitweb: https://git.kernel.org/tip/dc1b7b6ca9d5fa905c164a667086d8a3d8605875
Author: Arnd Bergmann 
AuthorDate: Mon, 18 Jun 2018 17:00:38 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 19 Jun 2018 09:56:27 +0200

sysinfo: Remove get_monotonic_boottime()

get_monotonic_boottime() is deprecated because it uses the old 'timespec'
structure. This replaces one of the last callers with a call to
ktime_get_boottime.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Cyrill Gorcunov 
Cc: Andrew Morton 
Cc: y2...@lists.linaro.org
Cc: Dominik Brodowski 
Cc: Cyrill Gorcunov 
Link: https://lkml.kernel.org/r/20180618150114.849216-1-a...@arndb.de

---
 kernel/sys.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sys.c b/kernel/sys.c
index 38509dc1f77b..e27b51d3facd 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2512,11 +2512,11 @@ static int do_sysinfo(struct sysinfo *info)
 {
unsigned long mem_total, sav_total;
unsigned int mem_unit, bitcount;
-   struct timespec tp;
+   struct timespec64 tp;
 
memset(info, 0, sizeof(struct sysinfo));
 
-   get_monotonic_boottime(&tp);
+   ktime_get_boottime_ts64(&tp);
info->uptime = tp.tv_sec + (tp.tv_nsec ? 1 : 0);
 
get_avenrun(info->loads, 0, SI_LOAD_SHIFT - FSHIFT);

[tip:timers/core] posix-timers: Use new ktime_get_*_ts64() helpers

Commit-ID:  58a10456d7175fa674b951f1fd7ead3d9a550db4
Gitweb: https://git.kernel.org/tip/58a10456d7175fa674b951f1fd7ead3d9a550db4
Author: Arnd Bergmann 
AuthorDate: Mon, 18 Jun 2018 16:32:24 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 19 Jun 2018 09:56:27 +0200

posix-timers: Use new ktime_get_*_ts64() helpers

Some of the oddly named time accessor functions now have a more consistent
naming, which should be used from now on so the aliases can be removed.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Thomas Gleixner 
Cc: y2...@lists.linaro.org
Cc: Deepa Dinamani 
Cc: "Eric W. Biederman" 
Link: https://lkml.kernel.org/r/20180618143246.3865099-1-a...@arndb.de

---
 kernel/time/posix-stubs.c  |  2 +-
 kernel/time/posix-timers.c | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c
index 26aa9569e24a..2c6847d5d69b 100644
--- a/kernel/time/posix-stubs.c
+++ b/kernel/time/posix-stubs.c
@@ -81,7 +81,7 @@ int do_clock_gettime(clockid_t which_clock, struct timespec64 
*tp)
ktime_get_ts64(tp);
break;
case CLOCK_BOOTTIME:
-   get_monotonic_boottime64(tp);
+   ktime_get_boottime_ts64(tp);
break;
default:
return -EINVAL;
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index e08ce3f27447..fcf90a10c43a 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -228,21 +228,21 @@ static int posix_ktime_get_ts(clockid_t which_clock, 
struct timespec64 *tp)
  */
 static int posix_get_monotonic_raw(clockid_t which_clock, struct timespec64 
*tp)
 {
-   getrawmonotonic64(tp);
+   ktime_get_raw_ts64(tp);
return 0;
 }
 
 
 static int posix_get_realtime_coarse(clockid_t which_clock, struct timespec64 
*tp)
 {
-   *tp = current_kernel_time64();
+   ktime_get_coarse_real_ts64(tp);
return 0;
 }
 
 static int posix_get_monotonic_coarse(clockid_t which_clock,
struct timespec64 *tp)
 {
-   *tp = get_monotonic_coarse64();
+   ktime_get_coarse_ts64(tp);
return 0;
 }
 
@@ -254,13 +254,13 @@ static int posix_get_coarse_res(const clockid_t 
which_clock, struct timespec64 *
 
 static int posix_get_boottime(const clockid_t which_clock, struct timespec64 
*tp)
 {
-   get_monotonic_boottime64(tp);
+   ktime_get_boottime_ts64(tp);
return 0;
 }
 
 static int posix_get_tai(clockid_t which_clock, struct timespec64 *tp)
 {
-   timekeeping_clocktai64(tp);
+   ktime_get_clocktai_ts64(tp);
return 0;
 }

[tip:x86/pti] x86/pti: Don't report XenPV as vulnerable

2018-06-19 Thread tip-bot for Jiri Kosina

Commit-ID:  66aa6b5cbc359331fc054e96bb49e9502bc0b1d9
Gitweb: https://git.kernel.org/tip/66aa6b5cbc359331fc054e96bb49e9502bc0b1d9
Author: Jiri Kosina 
AuthorDate: Mon, 18 Jun 2018 09:59:54 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 19 Jun 2018 09:58:22 +0200

x86/pti: Don't report XenPV as vulnerable

Xen PV domain kernel is not by design affected by meltdown as it's
enforcing split CR3 itself. Let's not report such systems as "Vulnerable"
in sysfs (we're also already forcing PTI to off in X86_HYPER_XEN_PV cases);
the security of the system ultimately depends on presence of mitigation in
the Hypervisor, which can't be easily detected from DomU; let's report
that.

Reported-and-tested-by: Mike Latimer 
Signed-off-by: Jiri Kosina 
Signed-off-by: Thomas Gleixner 
Acked-by: Juergen Gross 
Cc: Borislav Petkov 
Link: https://lkml.kernel.org/r/nycvar.yfh.7.76.1806180959080.6...@cbobk.fhfr.pm

---
 arch/x86/kernel/cpu/bugs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index cd0fda1fff6d..57638396a254 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void __init spectre_v2_select_mitigation(void);
 static void __init ssb_select_mitigation(void);
@@ -664,6 +665,10 @@ static ssize_t cpu_show_common(struct device *dev, struct 
device_attribute *attr
if (boot_cpu_has(X86_FEATURE_PTI))
return sprintf(buf, "Mitigation: PTI\n");
 
+   if (hypervisor_is_type(X86_HYPER_XEN_PV))
+   return sprintf(buf, "Unknown (XEN PV detected, 
hypervisor "
+   "mitigation required)\n");
+
break;
 
case X86_BUG_SPECTRE_V1:

Re: possible deadlock in console_unlock

2018-06-19 Thread Petr Mladek

On Fri 2018-06-15 17:38:04, Sergey Senozhatsky wrote:
> On (06/08/18 10:18), Petr Mladek wrote:
> [..]
> > > Could be.
> > > The good thing about printk_safe is that printk_safe sections can nest.
> > > I suspect there might be locks/printk_safe sections nesting at some
> > > point. In any case, switching to a new flavor of printk_safe will be
> > > pretty easy - just replace printk_safe_enter() with printk_foo_enter()
> > > and the same for printk_save_exit().
> > 
> > We could allow nesting. It is just a matter of how many bits we
> > reserve for it in printk_context variable.
> [..]
> > In each case, I would like to keep the printk_safe context usage
> > at minimum. It has its own problems caused by limited per-cpu buffers
> > and the need to flush them.
> 
> May be. Every new printk_safe flavour comes with increasing memory
> usage.

This must be a misunderstanding. My intention was to introduce
printk_deferred() context. Where any printk() called in this
context would behave like printk_deferred(). It does not need
any extra buffers.

IMHO, this problem is similar to the problems that we solve
in scheduler and timer code. The cure might be the same.
I just suggest to introduce a context to make our life easier.


> > It is basically needed only to prevent deadlocks related to logbuf_lock.
> 
> I wouldn't say that we need printk_safe for logbuf_lock only.
> printk_safe helps us to avoid deadlocks on:
> 
> - logbuf_lock spin_lock

logbuf_lock is already guarded by printk_safe context everywhere.


> - console_sem ->lock spin_lock
> - console_owner spin_lock
> - scheduler ->pi_lock spin_lock
> - and probably something else.

printk_deferred should be enough for others. Or do I miss anything?

Best Regards,
Petr

Re: [PATCH] devfreq: rk3399_dmc: Fix duplicated opp table on reload.

2018-06-19 Thread Enric Balletbo i Serra

Hi Chanwoo,

On 19/06/18 06:18, Chanwoo Choi wrote:
> Hi Enric,
> 
> On 2018년 06월 18일 18:10, Enric Balletbo Serra wrote:
>> Hi Chanwoo,
>>
>> Missatge de Chanwoo Choi  del dia dg., 17 de juny
>> 2018 a les 5:23:
>>>
>>> Hi Enric,
>>>
>>> 2018-06-16 0:12 GMT+09:00 Enric Balletbo i Serra 
>>> :
 The opp table is not removed when the driver is unloaded neither when
 there is an error within probe, so if the driver is reloaded the opp
 core shows the following warning:

   rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
2, volt: 90, enabled: 1. New: freq: 2,
volt: 90, enabled: 1
   rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
4, volt: 90, enabled: 1. New: freq: 4,
volt: 90, enabled: 1
   rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
66600, volt: 90, enabled: 1. New: freq: 66600,
volt: 90, enabled: 1
   rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
8, volt: 90, enabled: 1. New: freq: 8,
volt: 90, enabled: 1
   rk3399-dmc-freq dmc: _opp_add: duplicate OPPs detected. Existing: freq:
92800, volt: 90, enabled: 1. New: freq: 92800,
volt: 90, enabled: 1

 This patch fixes the error path in the probe function and adds a .remove
 function to properly cleanup the opp table on unloading.

 Fixes: 5a893e31a636c (PM / devfreq: rockchip: add devfreq driver for 
 rk3399 dmc)
 Signed-off-by: Enric Balletbo i Serra 
 ---

  drivers/devfreq/rk3399_dmc.c | 31 +++
  1 file changed, 27 insertions(+), 4 deletions(-)

 diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
 index d5c03e5abe13..e795ad2b3f6b 100644
 --- a/drivers/devfreq/rk3399_dmc.c
 +++ b/drivers/devfreq/rk3399_dmc.c
 @@ -375,8 +375,10 @@ static int rk3399_dmcfreq_probe(struct 
 platform_device *pdev)
 data->rate = clk_get_rate(data->dmc_clk);

 opp = devfreq_recommended_opp(dev, &data->rate, 0);
 -   if (IS_ERR(opp))
 -   return PTR_ERR(opp);
 +   if (IS_ERR(opp)) {
 +   ret = PTR_ERR(opp);
 +   goto err_free_opp;
 +   }

 data->rate = dev_pm_opp_get_freq(opp);
 data->volt = dev_pm_opp_get_voltage(opp);
 @@ -388,13 +390,33 @@ static int rk3399_dmcfreq_probe(struct 
 platform_device *pdev)
&rk3399_devfreq_dmc_profile,
DEVFREQ_GOV_SIMPLE_ONDEMAND,
&data->ondemand_data);
 -   if (IS_ERR(data->devfreq))
 -   return PTR_ERR(data->devfreq);
 +   if (IS_ERR(data->devfreq)) {
 +   ret = PTR_ERR(data->devfreq);
 +   goto err_free_opp;
 +   }
 +
 devm_devfreq_register_opp_notifier(dev, data->devfreq);

 data->dev = dev;
 platform_set_drvdata(pdev, data);

 +   return 0;
>>>
>>> It looks strange. Because rk3399_dmcfreq_probe() already include
>>> 'return 0' when success.
>>> What is the base commit of this patch?
>>>
>>
>> Sorry, I am not sure I understand your question, If I am not answering
>> below could you rephrase?
> 
> When I check the rk3399_dmcfreq_probe()[1], as I commented,
> rk3399_dmcfreq_probe() already 'return 0' after platform_set_drvdata().
> You can check it on link[1].
> [1] 
> https://elixir.bootlin.com/linux/v4.18-rc1/source/drivers/devfreq/rk3399_dmc.c#L443
> 
> But, this patch add new '+   return 0;' line again in 
> rk3399_dmcfreq_probe().
> So, just I asked what is base commit of this patch.
> 

I think that this is just how git did the diff and if you only look at the diff
is a bit confusing, if you apply the patch on top of mainline you will see that
there is only one return 0 in the probe function.

+   return 0; (this new return ...)
+
+err_free_opp:
+   dev_pm_opp_of_remove_table(&pdev->dev);
+   return ret;
+}
+
+static int rk3399_dmcfreq_remove(struct platform_device *pdev)
+{
+   struct rk3399_dmcfreq *dmcfreq = dev_get_drvdata(&pdev->dev);
+
+   /*
+* Before remove the opp table we need to unregister the opp notifier.
+*/
+   devm_devfreq_unregister_opp_notifier(dmcfreq->dev, dmcfreq->devfreq);
+   dev_pm_opp_of_remove_table(dmcfreq->dev);
+
return 0; (was this before the patch, but now is in another function)

Cheers,
 Enric

>>
>> So, once the opp table is added we need an error path to free it if an
>> error occurs later. When the pro

Re: possible deadlock in console_unlock

2018-06-19 Thread Sergey Senozhatsky

On (06/19/18 10:04), Petr Mladek wrote:
> > > 
> > > We could allow nesting. It is just a matter of how many bits we
> > > reserve for it in printk_context variable.
> > [..]
> > > In each case, I would like to keep the printk_safe context usage
> > > at minimum. It has its own problems caused by limited per-cpu buffers
> > > and the need to flush them.
> > 
> > May be. Every new printk_safe flavour comes with increasing memory
> > usage.
> 
> This must be a misunderstanding. My intention was to introduce
> printk_deferred() context. Where any printk() called in this
> context would behave like printk_deferred(). It does not need
> any extra buffers.

Ah, got it. Yes, this can work.

-ss

Re: [PATCH v3 1/3] mtd: rawnand: denali_dt: add more clocks based on IP datasheet

2018-06-19 Thread Masahiro Yamada

Hi Boris,


2018-06-18 16:46 GMT+09:00 Boris Brezillon :
> On Mon, 18 Jun 2018 09:09:02 +0200
> Richard Weinberger  wrote:
>
>> Am Freitag, 15. Juni 2018, 03:18:50 CEST schrieb Masahiro Yamada:
>> > According to the Denali User's Guide, this IP needs three clocks:
>> >
>> >  - clk: controller core clock
>> >
>> >  - clk_x: bus interface clock
>> >
>> >  - ecc_clk: clock at which ECC circuitry is run
>> >
>> > Currently, denali_dt.c requires a single anonymous clock and its
>> > frequency.  However, the driver needs to get the frequency of "clk_x"
>> > not "clk".  This is confusing because people tend to assume the
>> > anonymous clock means the core clock.  In fact, I got a report of
>> > SOCFPGA breakage because the timing parameters are calculated based
>> > on a wrong frequency.
>> >
>> > Instead of the cheesy implementation, the clocks in the real hardware
>> > should be represented in the driver and the DT-binding.
>> >
>> > However, adding new clocks would break the existing platforms.  For the
>> > backward compatibility, the driver still accepts a single clock just as
>> > before.  If clk_x is missing, clk_x_rate is set to a hardcoded value.
>> > This is fine for existing DT of Socionext UniPhier, and also fixes the
>> > issue of Altera (Intel) SOCFPGA because both platforms use 200 MHz for
>> > the bus interface clock.
>> >
>> > Fixes: 1bb88666775e ("mtd: nand: denali: handle timing parameters by 
>> > setup_data_interface()")
>> > Cc: linux-stable  #4.14+
>> > Reported-by: Richard Weinberger 
>> > Signed-off-by: Masahiro Yamada 
>>
>> Reviewed-by: Richard Weinberger 
>
> Maybe a
>
> Tested-by: Richard Weinberger 
>
> ?
>
>> Reported-by: Philipp Rosenberger 
>
> Should I replace your Reported-by by this one or simply add it?


I think it is good to have Reported-by
both from Philipp and Richard.


Thanks.



-- 
Best Regards
Masahiro Yamada

Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks

2018-06-19 Thread Peter Zijlstra

On Mon, Jun 18, 2018 at 02:38:18PM +0100, Alan Cox wrote:
> Given printk nowdays is already somewhat unreliable with all the perf
> related changes,

printk is a steaming pile of @#$#@, unreliable doesn't even begin to
cover it.

> and we have other good debug tools

What other good debug tools do you have? The only thing I have that
actually works is earlyser/8250_early -- and I route everything printk
into that.

Re: [RFC PATCH v2 1/6] serial: uartps: Do not initialize field to zero again

2018-06-19 Thread Michal Simek

On 6.6.2018 14:41, Michal Simek wrote:
> Writing zero and NULLs to already initialized fields is not needed.
> Remove this additional writes.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:
> - new patch - it can be sent separately too
> 
>  drivers/tty/serial/xilinx_uartps.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/xilinx_uartps.c 
> b/drivers/tty/serial/xilinx_uartps.c
> index 8a3e34234e98..5f116f3ecd4a 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -1510,15 +1510,12 @@ static int cdns_uart_probe(struct platform_device 
> *pdev)
>  
>   /* At this point, we've got an empty uart_port struct, initialize it */
>   spin_lock_init(&port->lock);
> - port->membase   = NULL;
> - port->irq   = 0;
>   port->type  = PORT_UNKNOWN;
>   port->iotype= UPIO_MEM32;
>   port->flags = UPF_BOOT_AUTOCONF;
>   port->ops   = &cdns_uart_ops;
>   port->fifosize  = CDNS_UART_FIFO_SIZE;
>   port->line  = id;
> - port->dev   = NULL;
>  
>   /*
>* Register the port.
> 

Alan, Rob, Greg: Any comment about this RFC?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs

Re: [PATCH] staging: board: drop refcount in success case

2018-06-19 Thread Nicholas Mc Guire

On Tue, Jun 19, 2018 at 09:51:44AM +0200, Geert Uytterhoeven wrote:
> On Tue, Jun 19, 2018 at 9:37 AM Dan Carpenter  
> wrote:
> > On Mon, Jun 18, 2018 at 08:53:19PM +0200, Nicholas Mc Guire wrote:
> > >  The call to of_find_compatible_node() returns irqc_node with refcount
> > > incremented thus it must be explicitly decremented here after it was
> > > checked for non-NULL.
> > >
> > > Signed-off-by: Nicholas Mc Guire 
> > > Fixes: commit 72ee8626eeb1 ("staging: board: Add support for translating 
> > > hwirq to virq numbers")
> > > ---
> > >
> > > Problem located with an experimental coccinelle script
> > >
> > > Patch was compile-tested with: x86_64_defconfig + STAGING=y, 
> > > STAGING_BOARD=y
> > >
> > > Patch is against 4.18-rc1 (localversion-next is next-20180618)
> > >
> > >  drivers/staging/board/board.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/staging/board/board.c b/drivers/staging/board/board.c
> > > index cb6feb3..8ee48e5 100644
> > > --- a/drivers/staging/board/board.c
> > > +++ b/drivers/staging/board/board.c
> > > @@ -64,12 +64,13 @@ int __init board_staging_gic_setup_xlate(const char 
> > > *gic_match,
> > >   irqc_node = of_find_compatible_node(NULL, NULL, gic_match);
> > >
> > >   WARN_ON(!irqc_node);
> > >   if (!irqc_node)
> > >   return -ENOENT;
> > >
> > > + of_node_put(irqc_node);
> >
> > I don't feel like this is the right thing...  We should keep the
> > reference until we're done with it.  Which apparently is never?
> 
> Indeed. The reference must not be released in this function, as it's stored in
> a global variable, and used later.

yup -  I had simply interpreted this incorrectly as checking only and
overlooked that this was a global variable.

> 
> As all users are __init, it could be released when the init section is freeed,
> in theory, but there's no callback for that.
> 
> Hence:
> NAKed-by: Geert Uytterhoeven 
>
thanks for the clarification - sorry for the noise.

thx
hofrat

Re: [PATCH v2 6/7] mm, proc: add KReclaimable to /proc/meminfo

2018-06-19 Thread Minchan Kim

On Tue, Jun 19, 2018 at 09:30:03AM +0200, Vlastimil Babka wrote:
> On 06/18/2018 11:33 PM, Andrew Morton wrote:
> > On Mon, 18 Jun 2018 11:18:07 +0200 Vlastimil Babka  wrote:
> > 
> >> The vmstat NR_KERNEL_MISC_RECLAIMABLE counter is for kernel non-slab
> >> allocations that can be reclaimed via shrinker. In /proc/meminfo, we can 
> >> show
> >> the sum of all reclaimable kernel allocations (including slab) as
> >> "KReclaimable". Add the same counter also to per-node meminfo under /sys
> > 
> > Why do you consider this useful enough to justify adding it to
> > /pro/meminfo?  How will people use it, what benefit will they see, etc?
> 
> Let's add this:
> 
> With this counter, users will have more complete information about
> kernel memory usage. Non-slab reclaimable pages (currently just the ION
> allocator) will not be missing from /proc/meminfo, making users wonder
> where part of their memory went. More precisely, they already appear in
> MemAvailable, but without the new counter, it's not obvious why the
> value in MemAvailable doesn't fully correspond with the sum of other
> counters participating in it.

Hmm, if we could get MemAvailable with sum of other counters participating
in it, MemAvailable wouldn't be meaninful. IMO, MemAvailable don't need to
be matched with other counters.

The benefit of ION KReclaimable in real field is there are some sluggish
problem bugreport under memory pressure and found ION page pool is too
much without shrinking. In that case, that meminfo would be useful to
know something was broken in the system.

In that point of view, a concern to me is if we put more KReclaimable
pages(e.g., binder is candidate), it ends up we couldn't identify what
caches are too much among them. That means we needs KReclaimableInfo(like
slabinfo) to show each type's KReclaimable pages in future.

Anyway, it's good for first step.

> 
> > Maybe you've undersold this whole patchset, but I'm struggling a bit to
> > see what the end-user benefits are.  What would be wrong with just
> > sticking with what we have now?
> 
> Fair enough, I will add more info in reply to the cover letter.
>

Re: [PATCH] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.

2018-06-19 Thread Enric Balletbo i Serra

Hi Chanwoo,

On 18/06/18 11:02, Enric Balletbo Serra wrote:
> Hi Chanwoo,
> Missatge de Chanwoo Choi  del dia dg., 17 de juny
> 2018 a les 5:50:
>>
>> Hi Enric,
>>
>> This issue will happen on the position to use find_devfreq_governor()
>> as following:
>> - devfreq_add_governora() and governor_store()
>>
>> If device driver with module type after loaded want to change the
>> scaling governor,
>> new governor might be not yet loaded. So, devfreq bettero to consider this 
>> case
>> in the find_devfreq_governor().
>>
> Ok, I'll move there and send a v2.
> 

I tried your suggestion but I found one problem, if I move the code in
find_devfreq_governor it end up with a deadlock. The reason is the following 
calls.

devfreq_add_device
  find_devfreq_governor (!!!)
request_module
   devfreq_simple_ondemand_init
  devfreq_add_governor
 find_devfreq_governor (DEADLOCK)

So I am wondering if shouldn't be more easy fix the issue in both places,
devfreq_add_device and governor_store.

To devfreq_add_device

devfreq_add_device
  governor = find_devfreq_governor
  if (IS_ERR(governor) {
 request_module
 governor = find_devfreq_governor
 if (IS_ERR(governor)
   return ERR_PTR(governor)
  }

And the same for governor_store

governor_store
  governor = find_devfreq_governor
  if (IS_ERR(governor) {
 request_module
 governor = find_devfreq_governor
 if (IS_ERR(governor)
   return ERR_PTR(governor)
  }

Maybe all  can go in a new function try_find_devfreq_governor_then_request

Other suggestions?

- Enric

> Thanks
>  Enric.
> 
> 
>> 2018-06-15 19:04 GMT+09:00 Enric Balletbo i Serra
>> :
>>> When the devfreq driver and the governor driver are built as modules,
>>> the call to devfreq_add_device() fails because the governor driver is
>>> not loaded at the time the devfreq driver loads. The devfreq driver has
>>> a build dependency on the governor but also should have a runtime
>>> dependency. We need to make sure that the governor driver is loaded
>>> before the devfreq driver.
>>>
>>> This patch fixes this bug in devfreq_add_device(). First tries to find
>>> the governor, and then, if was not found, it requests the module and
>>> tries again.
>>>
>>> Fixes: 1b5c1be2c88e (PM / devfreq: map devfreq drivers to governor using 
>>> name)
>>> Signed-off-by: Enric Balletbo i Serra 
>>> ---
>>>
>>>  drivers/devfreq/devfreq.c | 36 +++-
>>>  1 file changed, 31 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index fe2af6aa88fc..1d917f043e30 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>> @@ -11,6 +11,7 @@
>>>   */
>>>
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -648,10 +649,35 @@ struct devfreq *devfreq_add_device(struct device *dev,
>>>
>>> governor = find_devfreq_governor(devfreq->governor_name);
>>> if (IS_ERR(governor)) {
>>> -   dev_err(dev, "%s: Unable to find governor for the device\n",
>>> -   __func__);
>>> -   err = PTR_ERR(governor);
>>> -   goto err_init;
>>> +   list_del(&devfreq->node);
>>> +   mutex_unlock(&devfreq_list_lock);
>>> +
>>> +   /*
>>> +* If the governor is not found, then request the module and
>>> +* try again. This can happen when both drivers (the 
>>> governor
>>> +* driver and the driver that calls devfreq_add_device) are
>>> +* built as modules.
>>> +*/
>>> +   if (!strncmp(devfreq->governor_name,
>>> +DEVFREQ_GOV_SIMPLE_ONDEMAND, DEVFREQ_NAME_LEN))
>>> +   err = request_module("governor_%s", 
>>> "simpleondemand");
>>> +   else
>>> +   err = request_module("governor_%s",
>>> +devfreq->governor_name);
>>> +   if (err)
>>> +   goto err_unregister;
>>> +
>>> +   mutex_lock(&devfreq_list_lock);
>>> +   list_add(&devfreq->node, &devfreq_list);
>>> +
>>> +   governor = find_devfreq_governor(devfreq->governor_name);
>>> +   if (IS_ERR(governor)) {
>>> +   dev_err(dev,
>>> +   "%s: Unable to find governor for the 
>>> device\n",
>>> +   __func__);
>>> +   err = PTR_ERR(governor);
>>> +   goto err_init;
>>> +   }
>>> }
>>>
>>> devfreq->governor = governor;
>>> @@ -669,7 +695,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>>>  err_init:
>>> list_del(&devfreq->node);
>>> mutex_unlock(&devfreq_list_lock);
>>> -
>>> +err_unregister:
>>> device_unregister(&devfreq->dev);
>>>  err_dev:
>>> if (devfreq)
>>> --
>>>

[PATCH] coredump: Remove unsued trace event includes

2018-06-19 Thread Dietmar Eggemann

Coredump does not use any task or task scheduler trace events.

Commit 10c28d937e2c ("coredump: move core dump functionality into its
own file") moved coredump from fs/exec.c in which task and task
scheduler trace events are used.

Signed-off-by: Dietmar Eggemann 
---
 fs/coredump.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/fs/coredump.c b/fs/coredump.c
index 1e2c87acac9b..5859666150f1 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -46,11 +46,8 @@
 #include 
 #include 
 
-#include 
 #include "internal.h"
 
-#include 
-
 int core_uses_pid;
 unsigned int core_pipe_limit;
 char core_pattern[CORENAME_MAX_SIZE] = "core";
-- 
2.11.0

Re: [PATCH] printk/nmi: Prevent deadlock when serializing NMI backtraces

2018-06-19 Thread Sergey Senozhatsky

On (06/19/18 09:52), Petr Mladek wrote:
> On Mon 2018-06-18 19:07:18, Sergey Senozhatsky wrote:
> > On (06/18/18 11:39), Petr Mladek wrote:
> > [..]
> > 
> > Hmm. Can't answer right now :)
> 
> Please, let me know what name you would like ;-)

:) Wow, it's hard. Maybe we can derive some bits from the ftrace_dump()
function name? Dunno... Does printk_dump_nmi_enter() sound terrible?

Maybe Steven has some opinions on this?

-ss

Re: [REGRESSION] 4.17 failed to probe ACPI PnP

2018-06-19 Thread Rafael J. Wysocki

On Tue, Jun 19, 2018 at 8:12 AM, Takashi Iwai  wrote:
> Hi,
>
> there seems a regression regarding the probe of ACPI PnP devices.
> The detailed logs are found in openSUSE bugzilla:
>   https://bugzilla.opensuse.org/show_bug.cgi?id=1098074

But that's on this particular machine, not in general, right?

At least I don't see this on any of the systems in my office.

> In short, since 4.17, the laptop keyboard is lost on ASUS K501UW.
> Comparing the kernel messages and other logs indicates that the
> complete lost of ACPI PnP devices:
>
> On 4.16:
> [0.390244] pnp: PnP ACPI: found 9 devices
>
> On 4.17:
> [0.263266] pnp: PnP ACPI: found 0 devices
>
> ... and this leads to the failure of PS/2 keyboard detection due to
> the missing PNP030b entry as a result.
>
> Any hints for debugging this are appreciated.

It looks like this may be related to the ACPICA changes that went in
during the 4.17 cycle.

I would try 4.18-rc1 as there is an ACPICA fix in it that may be
related to this in theory.  If that doesn't help, I'd focus on the
ACPICA changes.

Thanks,
Rafael

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-19 Thread Jan Kara

On Mon 18-06-18 14:36:44, John Hubbard wrote:
> On 06/18/2018 12:21 PM, Dan Williams wrote:
> > On Mon, Jun 18, 2018 at 11:14 AM, John Hubbard  wrote:
> >> On 06/18/2018 10:56 AM, Dan Williams wrote:
> >>> On Mon, Jun 18, 2018 at 10:50 AM, John Hubbard  
> >>> wrote:
>  On 06/18/2018 01:12 AM, Christoph Hellwig wrote:
> > On Sun, Jun 17, 2018 at 01:28:18PM -0700, John Hubbard wrote:
> >> Yes. However, my thinking was: get_user_pages() can become a way to 
> >> indicate that
> >> these pages are going to be treated specially. In particular, the 
> >> caller
> >> does not really want or need to support certain file operations, while 
> >> the
> >> page is flagged this way.
> >>
> >> If necessary, we could add a new API call.
> >
> > That API call is called get_user_pages_longterm.
> 
>  OK...I had the impression that this was just semi-temporary API for dax, 
>  but
>  given that it's an exported symbol, I guess it really is here to stay.
> >>>
> >>> The plan is to go back and provide api changes that bypass
> >>> get_user_page_longterm() for RDMA. However, for VFIO and others, it's
> >>> not clear what we could do. In the VFIO case the guest would need to
> >>> be prepared handle the revocation.
> >>
> >> OK, let's see if I understand that plan correctly:
> >>
> >> 1. Change RDMA users (this could be done entirely in the various device 
> >> drivers'
> >> code, unless I'm overlooking something) to use mmu notifiers, and to do 
> >> their
> >> DMA to/from non-pinned pages.
> > 
> > The problem with this approach is surprising the RDMA drivers with
> > notifications of teardowns. It's the RDMA userspace applications that
> > need the notification, and it likely needs to be explicit opt-in, at
> > least for the non-ODP drivers.
> > 
> >> 2. Return early from get_user_pages_longterm, if the memory is...marked for
> >> RDMA? (How? Same sort of page flag that I'm floating here, or something 
> >> else?)
> >> That would avoid the problem with pinned pages getting their buffer heads
> >> removed--by disallowing the pinning. Makes sense.
> > 
> > Well, right now the RDMA workaround is DAX specific and it seems we
> > need to generalize it for the page-cache case. One thought is to have
> > try_to_unmap() take it's own reference and wait for the page reference
> > count to drop to one so that the truncate path knows the page is
> > dma-idle and disconnected from the page cache, but I have not looked
> > at the details.
> > 
> >> Also, is there anything I can help with here, so that things can happen 
> >> sooner?
> > 
> > I do think we should explore a page flag for pages that are "long
> > term" pinned. Michal asked for something along these lines at LSF / MM
> > so that the core-mm can give up on pages that the kernel has lost
> > lifetime control. Michal, did I capture your ask correctly?
> 
> 
> OK, that "refcount == 1" approach sounds promising:
> 
>-- still use a page flag, but narrow the scope to 
> get_user_pages_longterm() pages
>-- just wait in try_to_unmap, instead of giving up

But this would fix only the RDMA use case, isn't it? Direct IO (and other
get_user_pages_fast() users) would be still problematic.

And for record, the problem with page cache pages is not only that
try_to_unmap() may unmap them. It is also that page_mkclean() can
write-protect them. And once PTEs are write-protected filesystems may end
up doing bad things if DMA then modifies the page contents (DIF/DIX
failures, data corruption, oopses). As such I don't think that solutions
based on page reference count have a big chance of dealing with the
problem.

And your page flag approach would also need to take page_mkclean() into
account. And there the issue is that until the flag is cleared (i.e., we
are sure there are no writers using references from GUP) you cannot
writeback the page safely which does not work well with your idea of
clearing the flag only once the page is evicted from page cache (hint, page
cache page cannot get evicted until it is written back).

So as sad as it is, I don't see an easy solution here.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks

2018-06-19 Thread Petr Mladek

On Tue 2018-06-19 09:53:08, Sergey Senozhatsky wrote:
> Thanks for taking a look!
> 
> On (06/18/18 14:38), Alan Cox wrote:
> > > It doesn't come as a surprise that recursive printk() calls are not the
> > > only way for us to deadlock in printk() and we still have a whole bunch
> > > of other printk() deadlock scenarios. For instance, those that involve
> > > TTY port->lock spin_lock and UART port->lock spin_lock.
> > 
> > The tty layer code there is not re-entrant. Nor is it supposed to be

It is re-entrant via printk(). I mean that any printk() called inside
the locked sections might cause recursion if the same lock is needed
also by con->write() callbacks.

> Could be.
> 
> But at least we have circular locking dependency in tty,
> see [1] for more details:
> 
>   tty_port->lock  => uart_port->lock
> 
>CPU0
>tty
> spin_lock(&tty_port->lock)
>  printk()
>   call_console_drivers()
>foo_console_write()
> spin_lock(&uart_port->lock)
> 
> Whereas we normally have
> 
>   uart_port->lock => tty_port->lock
> 
>CPU1
>IRQ
> foo_console_handle_IRQ()
>  spin_lock(&uart_port->lock)
>   tty
>spin_lock(&tty_port->lock)

This is even more complicated situation because printk() allowed
an ABBA lock scenario.

> If we switch to printk_safe when we take tty_port->lock then we
> remove the printk->uart_port chain from the picture.
> 
> > > So the idea of this patch set is to take tty_port->lock and
> > > uart_port->lock from printk_safe context and to eliminate some
> > > of non-recursive printk() deadlocks - the ones that don't start
> > > in printk(), but involve console related locks and thus eventually
> > > deadlock us in printk(). For this purpose the patch set introduces
> > > several helper macros:
> > 
> > I don't see how this helps - if you recurse into the uart code you are
> > still hitting the paths that are unsafe when re-entered. All you've done
> > is messed up a pile of locking code on critical performance paths.
> > 
> > As it stands I think it's a bad idea.
> 
> The only new thing is that we inc/dec per-CPU printk context
> variable when we lock/unlock tty/uart port lock:
> 
>   printk_safe_enter() -> this_cpu_inc(printk_context);
>   printk_safe_exit() -> this_cpu_dec(printk_context);

To make it clear. This patch set adds yet another spin_lock API.
It behaves exactly as spin_lock_irqsafe()/spin_unlock_irqrestore()
but in addition it sets printk_context.

Where printk_context defines what printk implementation is safe. We
basically have four possibilities:

  1. normal   (store in logbuf, try to handle consoles)
  2. deferred (store in logbuf, deffer consoles)
  3. safe (store in per-CPU buffer, deffer everything)
  4. safe_nmi (store in another per-CPU buffer, deffer everything)

This patchset forces safe context around TTY and UART locks.
In fact, the deferred context would be enough to prevent
all the mentioned deadlocks.

IMHO, the only question is if people might get familiar with
yet another spin_lock API.

Best Regards,
Petr

[PATCH] nvme-pci: not invoke nvme_remove_dead_ctrl when change state fails

2018-06-19 Thread Jianchao Wang

There is race between nvme_remove and nvme_reset_work that can
lead to io hang.

nvme_removenvme_reset_work
-> change state to DELETING
   -> fail to change state to LIVE
   -> nvme_remove_dead_ctrl
 -> nvme_dev_disable
   -> quiesce request_queue
 -> queue remove_work
-> cancel_work_sync reset_work
-> nvme_remove_namespaces
  -> splice ctrl->namespaces
   nvme_remove_dead_ctrl_work
   -> nvme_kill_queues
  -> nvme_ns_remove   do nothing
-> blk_cleanup_queue
  -> blk_freeze_queue
Finally, the request_queue is quiesced state when wait freeze,
we will get io hang here.

In fact, when fails to change state in nvme_reset_work, the only
reason is someone has changed state to DELETING. So it is not
necessary to invoke nvme_remove_dead_ctrl in that case.

Signed-off-by: Jianchao Wang 
---
 drivers/nvme/host/pci.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index fc33804..fc56e63 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2318,7 +2318,7 @@ static void nvme_reset_work(struct work_struct *work)
if (!nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_CONNECTING)) {
dev_warn(dev->ctrl.device,
"failed to mark controller CONNECTING\n");
-   goto out;
+   goto fail_state;
}
 
result = nvme_pci_enable(dev);
@@ -2390,13 +2390,22 @@ static void nvme_reset_work(struct work_struct *work)
if (!nvme_change_ctrl_state(&dev->ctrl, new_state)) {
dev_warn(dev->ctrl.device,
"failed to mark controller state %d\n", new_state);
-   goto out;
+   goto fail_state;
}
 
nvme_start_ctrl(&dev->ctrl);
return;
 
- out:
+fail_state:
+   /*
+* The only possible state here is DELETING, there must be someone
+* removing the ctrl right now, so needn't invoke nvme_remove_dead_ctrl.
+* The queues may have been quiesced, start them to avoid io hang.
+*/
+   WARN_ON(dev->ctrl.state != NVME_CTRL_DELETING);
+   nvme_start_queues(&dev->ctrl);
+   return;
+out:
nvme_remove_dead_ctrl(dev, result);
 }
 
-- 
2.7.4

RE: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller

2018-06-19 Thread Yogesh Narayan Gaur

Hi Boris,

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Tuesday, June 19, 2018 12:59 PM
> To: Yogesh Narayan Gaur ;
> marek.va...@gmail.com; Frieder Schrempf ;
> broo...@kernel.org
> Cc: Fabio Estevam ; David Wolfe
> ; dw...@infradead.org; rich...@nod.at; Prabhakar
> Kushwaha ; Han Xu ; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> m...@lists.infradead.org; miquel.ray...@bootlin.com;
> computersforpe...@gmail.com
> Subject: Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI
> controller
> 
> Hi Yogesh,
> 
> Could you please use a mailer that is quoting things correctly. I have a hard 
> time
> differentiating your replies from mine.

Sorry for this, have changed my mailer settings.

> 
> On Tue, 19 Jun 2018 07:10:37 +
> Yogesh Narayan Gaur  wrote:
> 
> > Let us take below layout of memory address space map.
> > QuadSPI Controller can access range from 0x2000_ - 0x2FFF_ i.e. 256
> MB address space reserved and it is having 4 slave devices connected.
> > These slave devices[of size 64MB, 64MB, 32MB and 64MB ] are connected
> > at below address 0x2000_, 0x2400_, 0x2A00_, 0x2C00_
> > i.e. there is gap of 32MB from 0x2800_ to 0x29FF_.
> 
> Okay, I'm fine with pre-reserving 32MB per chip select.
> 
> >
> > As per my understanding of the controller, flash XX top address, register 
> > should
> have below values:
> >   QUADSPI_SFA1AD - 0x0
> >   QUADSPI_SFA2AD - 0x400_
> >   QUADSPI_SFB1AD - 0xA00_
> >   QUADSPI_SFB2AD - 0xC00_
> > And Register QUADSPI_SFAR should point to the range for the flash in which
> operation is happening.

My mistake values of these register would be for said case are:
QUADSPI_SFA1AD - 0x400_
QUADSPI_SFA2AD - 0x800_
QUADSPI_SFB1AD - 0xC00_
QUADSPI_SFB2AD - 0x1000_

i.e. as per controller each register is having the Top address for serial flash 
connected at A1/A2/B1/B2 respectively.

> 
> Wait, I thought it was supposed to be an absolute address, not one relative to
> the 0x2000 offset.
> 
> >
> > Please check Table10-32, page 1657, in [1] for more details on flash address
> assignment.
> 
> Yes, I still don't see where it says that having one of the range with a zero 
> size is
> forbidden, or anything mentioning a required alignment.
> 
> >
> > But say if I assign address to register QUADSPI_SFA2AD as "0 + 2 * -
> >ahb_buf_size" then this address value is not correct as per the value range
> explained in above mentioned table.
> 
> Why? If the SFA1AD is set to zero, that should not, right?
What this table says that for TOP_ADDR_MEMA1 defines the top address for flash 
connected at A1 and any address space between TOP_ADDR_MEMA1 and QSPI_AMBA_BASE 
will be routed to Serial Flash A1.
In my example case TOP_ADDR_MEMA1 is 0x400_
If assign value to SFAR register is "0 + 2 * ->ahb_buf_size", then this would 
lie in access range of Serial Flash A1 and access happens to A1 flash whereas 
we want access to A2 flash.

For access of serial flash A2, any address space access between TOP_ADDR_MEMA2 
and TOP_ADDR_MEMA1 would be routed to serial flash A2.
Thus to access A2 flash, SFAR would be in range from 0x400_ and 0x800_

--
Regards
Yogesh Gaur

Re: [patch] mm, oom: fix unnecessary killing of additional processes

2018-06-19 Thread Michal Hocko

On Fri 15-06-18 16:15:39, David Rientjes wrote:
[...]
> I'd be happy to make the this timeout configurable, however, and default 
> it to perhaps one second as the blockable mmu notifier timeout in your own 
> code does.  I find it somewhat sad that we'd need a sysctl for this, but 
> if that will appease you and it will help to move this into -mm then we 
> can do that.

No. This has been nacked in the past and I do not see anything different
from back than.

> > Other than that I've already pointed to a more robust solution. If you
> > are reluctant to try it out I will do, but introducing a timeout is just
> > papering over the real problem. Maybe we will not reach the state that
> > _all_ the memory is reapable but we definitely should try to make as
> > much as possible to be reapable and I do not see any fundamental
> > problems in that direction.
> 
> You introduced the timeout already, I'm sure you realized yourself that 
> the oom reaper sets MMF_OOM_SKIP much too early.  Trying to grab 
> mm->mmap_sem 10 times in a row with HZ/10 sleeps in between is a timeout.  

Yes, it is. And it is a timeout based some some feedback. The lock is
held, let's retry later but do not retry for ever. We can do the same
with blockable mmu notifiers. We are currently giving up right away. I
was proposing to add can_sleep parameter to mmu_notifier_invalidate_range_start
and return it EAGAIN if it would block. This would allow to simply retry
on EAGAIN like we do for the mmap_sem.

[...]

> The reproducer on powerpc is very simple.  Do an mmap() and mlock() the 
> length.  Fork one 120MB process that does that and two 60MB processes that 
> do that in a 128MB memcg.

And again, to solve this we just need to teach oom_reaper to handle
mlocked memory. There shouldn't be any fundamental reason why this would
be impossible AFAICS. Timeout is not a solution!

[...]

> It's inappropriate to merge code that oom kills many processes 
> unnecessarily when one happens to be mlocked or have blockable mmu 
> notifiers or when mm->mmap_sem can't be grabbed fast enough but forward 
> progress is actually being made.  It's a regression, and it impacts real 
> users.  Insisting that we fix the problem you introduced by making all mmu 
> notifiers unblockable and mlocked memory can always be reaped and 
> mm->mmap_sem can always be grabbed within a second is irresponsible.

Well, a lack of real world bug reports doesn't really back your story
here. I have asked about non-artificial workloads suffering and your
responsive were quite nonspecific to say the least.

And I do insist to come with a reasonable solution rather than random
hacks. Jeez the oom killer was full of these.

As I've said, if you are not willing to work on a proper solution, I
will, but my nack holds for this patch until we see no other way around
existing and real world problems.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] arm64: zynqmp: Add support for Avnet Ultra96 rev1 board

2018-06-19 Thread Michal Simek

Hi,

On 2.5.2018 13:53, Michal Simek wrote:
> Avnet Ultra96 rev1 board is commercialized Xilinx zcu100 revC/D
> internal board. The patch is reusing zcu100 revC files but changing
> model description and compatible strings which are used for example by
> libmraa.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> I choose this option because there are houndreds of zcu100 boards
> created and this will enable support both versions.
> 
> Record avnet prefix was sent by separate patch.
> ---
>  arch/arm64/boot/dts/xilinx/Makefile   |  1 +
>  .../boot/dts/xilinx/avnet-ultra96-rev1.dts| 19 +++
>  2 files changed, 20 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/xilinx/avnet-ultra96-rev1.dts
> 
> diff --git a/arch/arm64/boot/dts/xilinx/Makefile 
> b/arch/arm64/boot/dts/xilinx/Makefile
> index d452f80e7601..60f5443f3ef4 100644
> --- a/arch/arm64/boot/dts/xilinx/Makefile
> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> @@ -1,4 +1,5 @@
>  # SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_ZYNQMP) += avnet-ultra96-rev1.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1232-revA.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1254-revA.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zc1275-revA.dtb
> diff --git a/arch/arm64/boot/dts/xilinx/avnet-ultra96-rev1.dts 
> b/arch/arm64/boot/dts/xilinx/avnet-ultra96-rev1.dts
> new file mode 100644
> index ..88aa06fa78a8
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/avnet-ultra96-rev1.dts
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Avnet Ultra96 rev1
> + *
> + * (C) Copyright 2018, Xilinx, Inc.
> + *
> + * Michal Simek 
> + */
> +
> +/dts-v1/;
> +
> +#include "zynqmp-zcu100-revC.dts"
> +
> +/ {
> + model = "Avnet Ultra96 Rev1";
> + compatible = "avnet,ultra96-rev1", "avnet,ultra96",
> +  "xlnx,zynqmp-zcu100-revC", "xlnx,zynqmp-zcu100",
> +  "xlnx,zynqmp";
> +};
> 

Rob/Mark: Do you see any issue with this patch?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




signature.asc
Description: OpenPGP digital signature

[PATCH v7 2/4] phy: General struct and field cleanup

Move MSM8996 specific PHY vreg list struct name to a genernal one as it is
used by all PHYs. Add a specific field to handle dual lane situation.

Signed-off-by: Can Guo 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index ccb8578..9be9754 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -649,6 +649,8 @@ struct qmp_phy_cfg {
 
/* true, if PHY has a separate DP_COM control block */
bool has_phy_dp_com_ctrl;
+   /* true, if PHY has secondary tx/rx lanes to be configured */
+   bool is_dual_lane_phy;
/* Register offset of secondary tx/rx lanes for USB DP combo PHY */
unsigned int tx_b_lane_offset;
unsigned int rx_b_lane_offset;
@@ -758,7 +760,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
 };
 
 /* list of regulators */
-static const char * const msm8996_phy_vreg_l[] = {
+static const char * const qmp_phy_vreg_l[] = {
"vdda-phy", "vdda-pll",
 };
 
@@ -778,8 +780,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(msm8996_phy_clk_l),
.reset_list = msm8996_pciephy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_pciephy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = pciephy_regs_layout,
 
.start_ctrl = PCS_START | PLL_READY_GATE_EN,
@@ -809,8 +811,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(msm8996_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -870,8 +872,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(qmp_v3_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = qmp_v3_usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -883,6 +885,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.pwrdn_delay_max= POWER_DOWN_DELAY_US_MAX,
 
.has_phy_dp_com_ctrl= true,
+   .is_dual_lane_phy   = true,
.tx_b_lane_offset   = 0x400,
.rx_b_lane_offset   = 0x400,
 };
@@ -903,8 +906,8 @@ static inline void qphy_clrbits(void __iomem *base, u32 
offset, u32 val)
.num_clks   = ARRAY_SIZE(qmp_v3_phy_clk_l),
.reset_list = msm8996_usb3phy_reset_l,
.num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
-   .vreg_list  = msm8996_phy_vreg_l,
-   .num_vregs  = ARRAY_SIZE(msm8996_phy_vreg_l),
+   .vreg_list  = qmp_phy_vreg_l,
+   .num_vregs  = ARRAY_SIZE(qmp_phy_vreg_l),
.regs   = qmp_v3_usb3phy_regs_layout,
 
.start_ctrl = SERDES_START | PCS_START,
@@ -1116,12 +1119,12 @@ static int qcom_qmp_phy_init(struct phy *phy)
/* Tx, Rx, and PCS configurations */
qcom_qmp_phy_configure(tx, cfg->regs, cfg->tx_tbl, cfg->tx_tbl_num);
/* Configuration for other LANE for USB-DP combo PHY */
-   if (cfg->has_phy_dp_com_ctrl)
+   if (cfg->is_dual_lane_phy)
qcom_qmp_phy_configure(tx + cfg->tx_b_lane_offset, cfg->regs,
   cfg->tx_tbl, cfg->tx_tbl_num);
 
qcom_qmp_phy_configure(rx, cfg->regs, cfg->rx_tbl, cfg->rx_tbl_num);
-   if (cfg->has_phy_dp_com_ctrl)
+   if (cfg->is_dual_lane_phy)
qcom_qmp_phy_configure(rx + cfg->rx_b_lane_offset, cfg->regs,
   cfg->rx_tbl, cfg->rx_tbl_num);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 0/4] Support for Qualcomm UFS QMP PHY on SDM845

This patch series adds support for UFS QMP PHY on SDM845 and the
compatible string for it. This patch series depends on the current
proposed QMP V3 USB3 UNI PHY support for sdm845 driver [1], on
the DT bindings for the QMP V3 USB3 PHYs based dirver [2], and also
rebased on updated pipe_clk initialization sequence [3]. This series
can only be merged once the dependent patches do.
[1]
http://lists-archives.com/linux-kernel/29071659-dt-bindings-phy-qcom-qmp-update-bindings-for-sdm845.html
[2]
http://lists-archives.com/linux-kernel/29071660-phy-qcom-qmp-add-qmp-v3-usb3-uni-phy-support-for-sdm845.html
[3] https://patchwork.kernel.org/patch/10376551/

Changes since v6:
- Add one new change to clean up some structs and field
- Updates the PHY power control sequence.
- Incorporated review comments from Vivek and Manu.

Changes since v5:
- Updates the PHY power control sequence.
- Updates UFS PHY power on condition check.

Changes since v4:
- Adds 'ref_aux' clock back to SDM845 UFS PHY clock list.
- Power on PHY before serdes configuration starts.
- Updates the UFS PHY initialization sequence.
- Updates a few UFS PHY registers.
- Incorporated review comments from Vivek and Manu.

Changes since v3:
- Incorporated review comments from Vivek and Rob.

Changes since v2:
- Incorporated review comments from Vivek and Rob.
- Remove "ref_aux" from sdm845 ufs phy clock list structure.

Changes since v1:
- Incorporated review comments from Vivek and Manu.
- Update the commit title of patch 2.

Can Guo (4):
phy: Update PHY power control sequence
phy: General struct and field cleanup
phy: Add QMP phy based UFS phy support for sdm845
dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845

.../devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +-
drivers/phy/qualcomm/phy-qcom-qmp.c| 217 +++--
drivers/phy/qualcomm/phy-qcom-qmp.h| 15 ++
3 files changed, 216 insertions(+), 20 deletions(-)

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 4/4] dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845

Update the compatible string for UFS QMP PHY on SDM845.

Signed-off-by: Can Guo 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index cef8765..930d94c 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -11,7 +11,8 @@ Required properties:
   "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
   "qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy,
   "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
-  "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845.
+  "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845,
+  "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845.
 
  - reg: offset and length of register set for PHY's common serdes block.
 
@@ -29,6 +30,7 @@ Required properties:
"aux" for phy aux clock,
"ref" for 19.2 MHz ref clk,
"com_aux" for phy common block aux clock,
+   "ref_aux" for phy reference aux clock,
For "qcom,msm8996-qmp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref".
For "qcom,msm8996-qmp-usb3-phy" must contain:
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v7 3/4] phy: Add QMP phy based UFS phy support for sdm845

Add UFS PHY support to make SDM845 UFS work with common PHY framework.

Signed-off-by: Can Guo 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 173 +++-
 drivers/phy/qualcomm/phy-qcom-qmp.h |  15 
 2 files changed, 187 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 9be9754..852792d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -156,6 +156,11 @@ enum qphy_reg_layout {
[QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x170,
 };
 
+static const unsigned int sdm845_ufsphy_regs_layout[] = {
+   [QPHY_START_CTRL]   = 0x00,
+   [QPHY_PCS_READY_STATUS] = 0x160,
+};
+
 static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
@@ -601,6 +606,83 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V3_PCS_REFGEN_REQ_CONFIG2, 0x60),
 };
 
+static const struct qmp_phy_init_tbl sdm845_ufsphy_serdes_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0xd5),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL, 0x20),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_CTRL, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x05),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL1, 0xff),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL2, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xda),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0xff),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x0c),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE1, 0x98),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE1, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE1, 0x16),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE1, 0x36),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE1, 0x3f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE1, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE1, 0xc1),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE1, 0x00),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE1, 0x32),
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE1, 0x0f),
+
+   /* Rate B */
+   QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x44),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_tx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_LANE_MODE_1, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_RX, 0x07),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_rx_tbl[] = {
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_LVL, 0x24),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_CNTRL, 0x0f),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_DEGLITCH_CNTRL, 0x1e),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_INTERFACE_MODE, 0x40),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_FO_GAIN, 0x0b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_TERM_BW, 0x5b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL2, 0x06),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_HALF, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_QUARTER, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN, 0x04),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x4b),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_PI_CONTROLS, 0x81),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_COUNT_LOW, 0x80),
+   QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_MODE_00, 0x59),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_pcs_tbl[] = {
+   QMP_PHY_INIT_CFG(QPHY_V3_PCS_R

Re: [REGRESSION] 4.17 failed to probe ACPI PnP

2018-06-19 Thread Takashi Iwai

On Tue, 19 Jun 2018 10:28:42 +0200,
Rafael J. Wysocki wrote:
> 
> On Tue, Jun 19, 2018 at 8:12 AM, Takashi Iwai  wrote:
> > Hi,
> >
> > there seems a regression regarding the probe of ACPI PnP devices.
> > The detailed logs are found in openSUSE bugzilla:
> >   https://bugzilla.opensuse.org/show_bug.cgi?id=1098074
> 
> But that's on this particular machine, not in general, right?
> 
> At least I don't see this on any of the systems in my office.

Yes, it looks so.  4.17 and later works on my several machines, too.

> 
> > In short, since 4.17, the laptop keyboard is lost on ASUS K501UW.
> > Comparing the kernel messages and other logs indicates that the
> > complete lost of ACPI PnP devices:
> >
> > On 4.16:
> > [0.390244] pnp: PnP ACPI: found 9 devices
> >
> > On 4.17:
> > [0.263266] pnp: PnP ACPI: found 0 devices
> >
> > ... and this leads to the failure of PS/2 keyboard detection due to
> > the missing PNP030b entry as a result.
> >
> > Any hints for debugging this are appreciated.
> 
> It looks like this may be related to the ACPICA changes that went in
> during the 4.17 cycle.
> 
> I would try 4.18-rc1 as there is an ACPICA fix in it that may be
> related to this in theory.  If that doesn't help, I'd focus on the
> ACPICA changes.

OK, Noah, could you test later the kernel in OBS Kernel:HEAD repo?
Now 4.18-rc1 kernel is being built there, and hopefully will finish
soon later.


thanks,

Takashi

[PATCH v7 1/4] phy: Update PHY power control sequence

All PHYs should be powered on before register configuration starts. And
only PCIe PHYs need an extra power control before deasserts reset state.

Signed-off-by: Can Guo 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 97ef942..ccb8578 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -935,10 +935,12 @@ static void qcom_qmp_phy_configure(void __iomem *base,
}
 }
 
-static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
+static int qcom_qmp_phy_com_init(struct qmp_phy *qphy)
 {
+   struct qcom_qmp *qmp = qphy->qmp;
const struct qmp_phy_cfg *cfg = qmp->cfg;
void __iomem *serdes = qmp->serdes;
+   void __iomem *pcs = qphy->pcs;
void __iomem *dp_com = qmp->dp_com;
int ret, i;
 
@@ -979,10 +981,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
goto err_rst;
}
 
-   if (cfg->has_phy_com_ctrl)
-   qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
-SW_PWRDN);
-
if (cfg->has_phy_dp_com_ctrl) {
qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
 SW_PWRDN);
@@ -1000,6 +998,12 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
}
 
+   if (cfg->has_phy_com_ctrl)
+   qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
+SW_PWRDN);
+   else
+   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+
/* Serdes configuration */
qcom_qmp_phy_configure(serdes, cfg->regs, cfg->serdes_tbl,
   cfg->serdes_tbl_num);
@@ -1090,7 +1094,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
 
dev_vdbg(qmp->dev, "Initializing QMP phy\n");
 
-   ret = qcom_qmp_phy_com_init(qmp);
+   ret = qcom_qmp_phy_com_init(qphy);
if (ret)
return ret;
 
@@ -1127,7 +1131,8 @@ static int qcom_qmp_phy_init(struct phy *phy)
 * Pull out PHY from POWER DOWN state.
 * This is active low enable signal to power-down PHY.
 */
-   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+   if(cfg->type == PHY_TYPE_PCIE)
+   qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
 
if (cfg->has_pwrdn_delay)
usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: linux-next: manual merge of the vfs tree with the overlayfs tree

2018-06-19 Thread David Howells

Stephen Rothwell  wrote:

>  /* These sb flags are internal to the kernel */
>  #define MS_SUBMOUNT (1<<26)
> -#define MS_NOREMOTELOCK  (1<<27)
>  #define MS_NOSEC (1<<28)
>  #define MS_BORN  (1<<29)
>  #define MS_ACTIVE(1<<30)

Ummm...  Can MS_NOREMOTELOCK be removed?  I know it's listed in the internal
flags section, but all of these have been exposed to userspace for over a
year.  Ideally, I'd remove all of these from UAPI, but can anyone guarantee
that no pieces of userspace refer to them?

David

Re: [PATCH v3 12/12] mfd: cros_ec: Add throttler sub-device

2018-06-19 Thread Enric Balletbo Serra

Hi Matthias,

I am also interested on the answer of Brian comments :). One small comment.

Missatge de Brian Norris  del dia dt., 19 de
juny 2018 a les 1:22:
>
> Hi,
>
> On Thu, Jun 14, 2018 at 12:47:12PM -0700, Matthias Kaehlcke wrote:
> > Instantiate the CrOS EC throttler if it is enabled in the kernel
> > configuration.
> >
> > Signed-off-by: Matthias Kaehlcke 
> > ---
> > Changes in v3:
> > - patch added to series
> >
> >  drivers/mfd/cros_ec.c | 16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> > index 36156a41499c..5f52b6e2c21a 100644
> > --- a/drivers/mfd/cros_ec.c
> > +++ b/drivers/mfd/cros_ec.c
> > @@ -91,6 +91,10 @@ static int cros_ec_sleep_event(struct cros_ec_device 
> > *ec_dev, u8 sleep_event)
> >   return cros_ec_cmd_xfer(ec_dev, &buf.msg);
> >  }
> >
> > +static const struct mfd_cell ec_throttler_cell = {
> > + { .name = "cros-ec-throttler" }
> > +};
> > +

As Brian said I think that this should go in cros_ec_dev?

Even when only there is one cell we tend to use the array format (see
i.e the cros-ec-rtc and the others in cros_ec_dev).

+static const struct mfd_cell ec_throttler_cells[] = {
+ { .name = "cros-ec-throttler" }
+};

> >  int cros_ec_register(struct cros_ec_device *ec_dev)
> >  {
> >   struct device *dev = ec_dev->dev;
> > @@ -153,6 +157,18 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
> >   }
> >   }
> >
> > + if (IS_ENABLED(CONFIG_CROS_EC_THROTTLER)) {
> > + err = mfd_add_devices(ec_dev->dev, PLATFORM_DEVID_AUTO,
> > +   &ec_throttler_cell, 1, NULL, 
> > ec_dev->irq,

ARRAY_SIZE(ec_throttler_cells)

> > +   NULL);
>
> Most of this similar sub-device registration seems to have moved to
> cros_ec_dev.c, in ec_device_probe(). Should this do the same?
>
> And on a similar note: is there a way to determine EC support for this
> feature (e.g., EC_FEATURE_*)? Or do we just have to listen for
> appropriate throttling events that may never come?
>
> Also, is this very useful on non-DT systems? Does this fail gracefully?
>
> Brian
>
> > + if (err) {
> > + dev_err(dev,
> > + "Failed to register throttler subdevice %d\n",
> > + err);
> > + return err;
> > + }
> > + }
> > +
> >   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> >   err = devm_of_platform_populate(dev);
> >   if (err) {
> > --
> > 2.18.0.rc1.242.g61856ae69a-goog
> >

Cheers,
 Enric

Re: [PATCH v6 18/29] drm/mediatek: add connection from RDMA1 to DSI2

2018-06-19 Thread CK Hu

On Tue, 2018-06-19 at 15:34 +0800, Stu Hsieh wrote:
> This patch add the connection from RDMA1 to DSI2
> 

Reviewed-by: CK Hu 

> Signed-off-by: Stu Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 90228cad051a..9cf2fcb4932a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -28,6 +28,7 @@
>  #define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN0x050
>  #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN   0x084
>  #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN   0x088
> +#define DISP_REG_CONFIG_DSIE_SEL_IN  0x0a4
>  #define DISP_REG_CONFIG_DSIO_SEL_IN  0x0a8
>  #define DISP_REG_CONFIG_DPI_SEL_IN   0x0ac
>  #define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN   0x0c4
> @@ -88,9 +89,11 @@
>  #define RDMA1_SOUT_DPI0  0x2
>  #define RDMA1_SOUT_DPI1  0x3
>  #define RDMA1_SOUT_DSI1  0x1
> +#define RDMA1_SOUT_DSI2  0x4
>  #define DPI0_SEL_IN_RDMA10x1
>  #define DPI1_SEL_IN_RDMA1(0x1 << 8)
>  #define DSI1_SEL_IN_RDMA10x1
> +#define DSI2_SEL_IN_RDMA1(0x1 << 16)
>  #define COLOR1_SEL_IN_OVL1   0x1
>  
>  #define OVL_MOUT_EN_RDMA 0x1
> @@ -176,6 +179,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id 
> cur,
>   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
>   *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
>   value = RDMA1_SOUT_DSI1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DSI2;
>   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
>   *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
>   value = RDMA1_SOUT_DPI0;
> @@ -207,6 +213,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
> cur,
>   } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
>   *addr = DISP_REG_CONFIG_DSIO_SEL_IN;
>   value = DSI1_SEL_IN_RDMA1;
> + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
> + *addr = DISP_REG_CONFIG_DSIE_SEL_IN;
> + value = DSI2_SEL_IN_RDMA1;
>   } else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
>   *addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
>   value = COLOR1_SEL_IN_OVL1;

Re: [RFC PATCH v3 09/10] sched/fair: Select an energy-efficient CPU on task wake-up

2018-06-19 Thread Pavan Kondeti

On Tue, Jun 19, 2018 at 08:57:23AM +0100, Quentin Perret wrote:
> Hi Pavan,
> 
> On Tuesday 19 Jun 2018 at 10:36:01 (+0530), Pavan Kondeti wrote:
> > On Mon, May 21, 2018 at 03:25:04PM +0100, Quentin Perret wrote:
> > 
> > 
> > 
> > > + if (cpumask_test_cpu(prev_cpu, &p->cpus_allowed))
> > > + prev_energy = best_energy = compute_energy(p, prev_cpu);
> > > + else
> > > + prev_energy = best_energy = ULONG_MAX;
> > > +
> > > + for_each_freq_domain(sfd) {
> > > + unsigned long spare_cap, max_spare_cap = 0;
> > > + int max_spare_cap_cpu = -1;
> > > + unsigned long util;
> > > +
> > > + /* Find the CPU with the max spare cap in the freq. dom. */
> > > + for_each_cpu_and(cpu, freq_domain_span(sfd), 
> > > sched_domain_span(sd)) {
> > > + if (!cpumask_test_cpu(cpu, &p->cpus_allowed))
> > > + continue;
> > > +
> > > + if (cpu == prev_cpu)
> > > + continue;
> > > +
> > > + /* Skip CPUs that will be overutilized */
> > > + util = cpu_util_wake(cpu, p) + task_util;
> > > + cpu_cap = capacity_of(cpu);
> > > + if (cpu_cap * 1024 < util * capacity_margin)
> > > + continue;
> > > +
> > > + spare_cap = cpu_cap - util;
> > > + if (spare_cap > max_spare_cap) {
> > > + max_spare_cap = spare_cap;
> > > + max_spare_cap_cpu = cpu;
> > > + }
> > > + }
> > > +
> > > + /* Evaluate the energy impact of using this CPU. */
> > > + if (max_spare_cap_cpu >= 0) {
> > > + cur_energy = compute_energy(p, max_spare_cap_cpu);
> > > + if (cur_energy < best_energy) {
> > > + best_energy = cur_energy;
> > > + best_energy_cpu = max_spare_cap_cpu;
> > > + }
> > > + }
> > > + }
> > > +
> > > + /*
> > > +  * We pick the best CPU only if it saves at least 1.5% of the
> > > +  * energy used by prev_cpu.
> > > +  */
> > > + if ((prev_energy - best_energy) > (prev_energy >> 6))
> > > + return best_energy_cpu;
> > > +
> > > + return prev_cpu;
> > > +}
> > 
> > We are comparing the best_energy_cpu against prev_cpu even when prev_cpu
> > can't accommodate the waking task. Is this intentional? Should not we
> > discard the prev_cpu if it can't accommodate the task.
> > 
> > This can potentially make a BIG task run on a lower capacity CPU until
> > load balancer kicks in and corrects the situation.
> 
> We shouldn't enter find_energy_efficient_cpu() in the first place if the
> system is overutilized, so that shouldn't too much of an issue in
> general.
> 

With UTIL_EST enabled, the overutilization condtion may get turned off when
that 1 BIG task goes to sleep. When it wakes up again, we may place it on
the previous CPU due to the above mentioned issue.

It is not just an existing overutilization condition. By placing this task
on the prev_cpu, we may enter overutilization state.

> But yeah, there is one small corner case where prev_cpu is overutilized
> and the system has not been flagged as such yet (when the tasks wakes-up
> shortly before the tick for ex). I think it's possible to cover this case
> by extending the "if (cpumask_test_cpu(prev_cpu, &p->cpus_allowed))"
> condition at the top of the function with a check on capacity_margin.
> 

LGTM.

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: ThinkPad T480s & LED_MUTE, LED_MICMUTE

2018-06-19 Thread Takashi Iwai

On Tue, 19 Jun 2018 10:37:12 +0200,
Pali Rohár wrote:
> 
> On Monday 18 June 2018 13:21:21 Pali Rohár wrote:
> > On Monday 18 June 2018 12:36:31 Takashi Iwai wrote:
> > > On Mon, 18 Jun 2018 12:28:06 +0200,
> > > Pali Rohár wrote:
> > > > 
> > > > On Saturday 16 June 2018 18:02:14 Takashi Iwai wrote:
> > > > > On Sat, 16 Jun 2018 17:43:09 +0200,
> > > > > Pali Rohár wrote:
> > > > > > 
> > > > > > On Saturday 16 June 2018 09:05:41 Takashi Iwai wrote:
> > > > > > > On Fri, 15 Jun 2018 21:09:59 +0200,
> > > > > > > Pali Rohár wrote:
> > > > > > > > 
> > > > > > > > On Friday 15 June 2018 14:51:47 Takashi Iwai wrote:
> > > > > > > > > On Fri, 08 Jun 2018 13:10:57 +0200,
> > > > > > > > > Pali Rohár wrote:
> > > > > > > > > > 
> > > > > > > > > > Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad 
> > > > > > > > > > T480s I'm seeing
> > > > > > > > > > a strange behavior of LEDs which are integrated into mic 
> > > > > > > > > > mute (Fn+F4)
> > > > > > > > > > and mute (Fn+F1) keys.
> > > > > > > > > > 
> > > > > > > > > > When thinkpad_acpi.ko is not loaded, then mute key is 
> > > > > > > > > > working fine. When
> > > > > > > > > > pressed, it correctly generates KEY_MUTE on AT Translated 
> > > > > > > > > > Set 2 keyboard
> > > > > > > > > > input device and also turn on/of mute led. But when micmute 
> > > > > > > > > > key is
> > > > > > > > > > pressed then, nothing happen. No key event is reported and 
> > > > > > > > > > also led is
> > > > > > > > > > not turned on/off.
> > > > > > > > > > 
> > > > > > > > > > On the other hand, when thinkpad_acpi.ko is loaded, then 
> > > > > > > > > > both buttons
> > > > > > > > > > mute and micmute correctly generates input events; mute via 
> > > > > > > > > > AT keyboard
> > > > > > > > > > and micmute via ThinkPad Extra Buttons. But led is not 
> > > > > > > > > > changed. When
> > > > > > > > > > thinkpad_acpi.ko is loaded it turn off both leds (mute and 
> > > > > > > > > > micmute) and
> > > > > > > > > > leds after pressing any of those buttons, leds are not 
> > > > > > > > > > turned on again.
> > > > > > > > > > 
> > > > > > > > > > When thinkpad_acpi.ko is unloaded, then pressing mute 
> > > > > > > > > > button again start
> > > > > > > > > > switching led on/off.
> > > > > > > > > > 
> > > > > > > > > > So it seems that some init sequence of thinkpad_acpi.ko 
> > > > > > > > > > breaks mute led.
> > > > > > > > > > And fini sequence of thinkpad_acpi.ko makes mute led 
> > > > > > > > > > working again.
> > > > > > > > > 
> > > > > > > > > Usually the mute LED on Thinkpad is triggered from HD-audio 
> > > > > > > > > driver
> > > > > > > > > (sound/pci/hda/thinkpad_helper.c), and it's a soft-bound via
> > > > > > > > > symbol_request(tpacpi_led_set).  I thought thinkpad_acpi is
> > > > > > > > > auto-loaded when the module gets bound.
> > > > > > > > > 
> > > > > > > > > A possible explanation would be that TPT480s has neither 
> > > > > > > > > IBM0068,
> > > > > > > > > LEN0068 nor LEN0268 ACPI HIDs, hence the driver is not 
> > > > > > > > > auto-loaded.
> > > > > > > > 
> > > > > > > > I have Debian Stretch kernel (4.9) which does not have LEN0268 
> > > > > > > > alias for
> > > > > > > > thinkpad_acpi.ko. So thinkpad_acpi.ko is not loaded 
> > > > > > > > automatically. But I
> > > > > > > > have put thinkpad_acpi into /etc/modules and it is now 
> > > > > > > > automatically
> > > > > > > > loaded at boot.
> > > > > > > 
> > > > > > > That's odd.  It's exposed via
> > > > > > >   MODULE_DEVICE_TABLE(acpi, ibm_htk_device_ids);
> > > > > > > 
> > > > > > > It's been already in 4.9.  At this point, something is fishy.
> > > > > > 
> > > > > > $ /sbin/modinfo thinkpad_acpi | grep alias
> > > > > > alias:  dmi:bvnIBM:bvrI[MU]ET??WW*
> > > > > > alias:  tpacpi
> > > > > > alias:  acpi*:LEN0068:*
> > > > > > alias:  acpi*:IBM0068:*
> > > > > > 
> > > > > > No there is no LEN0268 on 4.9.
> > > > > 
> > > > > OK, that's the cause.  It's really old.
> > > > > 
> > > > > The commit a3c42a467a25 ("platform/x86: thinkpad_acpi: Adding new
> > > > > hotkey ID for Lenovo thinkpad") has to be backported.
> > > > 
> > > > This commit just autoloads thinkpad_acpi driver, right? So manual
> > > > modprobe (for now) is OK too?
> > > 
> > > Well, the manual modprobe is superfluous if it's properly bound with
> > > HD-audio driver.  The HD-audio driver calls symbol_request(), so it
> > > should do modprobe by itself.
> > > 
> > > > > Also, in the HD-audio side, the commit 2ecb704a1290 ("ALSA: hda - add
> > > > > a new condition to check if it is thinkpad") is needed, too.
> > > > 
> > > > This commit was introduced in 4.9 and Debian kernel has it. I looked
> > > > into Debian source code and there is check for LEN0268 in file
> > > > sound/pci/hda/thinkpad_helper.c
> > > 
> > > Then check whether the function gets really called.
> > 
> > Checked, no it is not called.
> > 
> > Now I see that snd_hda_codec_generic is visible in l

[PATCH v1]: perf tests: check that complex event name is parsed correctly

2018-06-19 Thread Alexey Budankov



Extend regression testing to cover case of complex event names enabled 
by the patch "perf record: enable arbitrary event names thru name= modifier".

tools/perf/perf test
 1: vmlinux symtab matches kallsyms   : Skip
 2: Detect openat syscall event   : Ok
 3: Detect openat syscall event on all cpus   : Ok
 4: Read samples using the mmap interface : Ok
 5: Test data source output   : Ok
 6: Parse event definition strings: Ok  <===!
 7: Simple expression parser  : Ok
...

Signed-off-by: Alexey Budankov 
---
 tools/perf/tests/parse-events.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index b9ebe15afb13..706b574f9747 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -1317,6 +1317,14 @@ static int test__intel_pt(struct perf_evlist *evlist)
return 0;
 }
 
+static int test__checkevent_complex_name(struct perf_evlist *evlist)
+{
+   struct perf_evsel *evsel = perf_evlist__first(evlist);
+
+   TEST_ASSERT_VAL("wrong complex name parsing", strcmp(evsel->name, 
"COMPLEX_CYCLES_NAME:orig=cycles,desc=chip-clock-ticks") == 0);
+   return 0;
+}
+
 static int count_tracepoints(void)
 {
struct dirent *events_ent;
@@ -1651,6 +1659,11 @@ static struct evlist_test test__events[] = {
.check = test__intel_pt,
.id= 52,
},
+   {
+   .name  = 
"cycles/name='COMPLEX_CYCLES_NAME:orig=cycles,desc=chip-clock-ticks'/Duk",
+   .check = test__checkevent_complex_name,
+   .id= 53
+   }
 };
 
 static struct evlist_test test__events_pmu[] = {
@@ -1669,6 +1682,11 @@ static struct evlist_test test__events_pmu[] = {
.check = test__checkevent_pmu_partial_time_callgraph,
.id= 2,
},
+   {
+   .name  = 
"cpu/name='COMPLEX_CYCLES_NAME:orig=cycles,desc=chip-clock-ticks',period=0x1,event=0x2,umask=0x3/ukp",
+   .check = test__checkevent_complex_name,
+   .id= 3,
+   }
 };
 
 struct terms_test {

Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller

2018-06-19 Thread Boris Brezillon

On Tue, 19 Jun 2018 08:31:25 +
Yogesh Narayan Gaur  wrote:

> > 
> > Could you please use a mailer that is quoting things correctly. I
> > have a hard time differentiating your replies from mine.  
> 
> Sorry for this, have changed my mailer settings.

Thanks for doing. It's still not perfect, but it's definitely better.

> 
> > 
> > On Tue, 19 Jun 2018 07:10:37 +
> > Yogesh Narayan Gaur  wrote:
> >   
> > > Let us take below layout of memory address space map.
> > > QuadSPI Controller can access range from 0x2000_ -
> > > 0x2FFF_ i.e. 256  
> > MB address space reserved and it is having 4 slave devices
> > connected.  
> > > These slave devices[of size 64MB, 64MB, 32MB and 64MB ] are
> > > connected at below address 0x2000_, 0x2400_, 0x2A00_,
> > > 0x2C00_ i.e. there is gap of 32MB from 0x2800_ to
> > > 0x29FF_.  
> > 
> > Okay, I'm fine with pre-reserving 32MB per chip select.
> >   
> > >
> > > As per my understanding of the controller, flash XX top address,
> > > register should  
> > have below values:  
> > >   QUADSPI_SFA1AD - 0x0
> > >   QUADSPI_SFA2AD - 0x400_
> > >   QUADSPI_SFB1AD - 0xA00_
> > >   QUADSPI_SFB2AD - 0xC00_
> > > And Register QUADSPI_SFAR should point to the range for the flash
> > > in which  
> > operation is happening.  
> 
> My mistake values of these register would be for said case are:
> QUADSPI_SFA1AD - 0x400_
> QUADSPI_SFA2AD - 0x800_
> QUADSPI_SFB1AD - 0xC00_
> QUADSPI_SFB2AD - 0x1000_
> 
> i.e. as per controller each register is having the Top address for
> serial flash connected at A1/A2/B1/B2 respectively.

This is still wrong ;-). I guess you mean:

QUADSPI_SFA1AD - 0x2400_
QUADSPI_SFA2AD - 0x2800_
QUADSPI_SFB1AD - 0x2C00_
QUADSPI_SFB2AD - 0x3000_

> 
> > 
> > Wait, I thought it was supposed to be an absolute address, not one
> > relative to the 0x2000 offset.
> >   
> > >
> > > Please check Table10-32, page 1657, in [1] for more details on
> > > flash address  
> > assignment.
> > 
> > Yes, I still don't see where it says that having one of the range
> > with a zero size is forbidden, or anything mentioning a required
> > alignment. 
> > >
> > > But say if I assign address to register QUADSPI_SFA2AD as "0 + 2
> > > * -
> > >ahb_buf_size" then this address value is not correct as per the
> > >value range  
> > explained in above mentioned table.
> > 
> > Why? If the SFA1AD is set to zero, that should not, right?  
> What this table says that for TOP_ADDR_MEMA1 defines the top address
> for flash connected at A1 and any address space between
> TOP_ADDR_MEMA1 and QSPI_AMBA_BASE will be routed to Serial Flash A1.
> In my example case TOP_ADDR_MEMA1 is 0x400_ If assign value to
> SFAR register is "0 + 2 * ->ahb_buf_size", then this would lie in
> access range of Serial Flash A1 and access happens to A1 flash
> whereas we want access to A2 flash.

No, not if SFA1AD is 0x2000, because then the address range for CS0
would be 0x2000 -> 0x2000.

If you look at the code, you'll see that I adjust the CS mapping
dynamically, making the one being access use the range
0x2000 -> (0x2000 + 2 * ->ahb_buf_size) and assigning a 0-size
range for the other ones (either 0x2000 -> 0x2000 or
(0x2000 + 2 * ->ahb_buf_size) -> (0x2000 + 2 * ->ahb_buf_size))

> 
> For access of serial flash A2, any address space access between
> TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1 would be routed to serial flash A2.
> Thus to access A2 flash, SFAR would be in range from 0x400_ and
> 0x800_

I understand what you're explaining, what I don't get is why the QSPI
IP doesn't cope with a 0-size range. If you have SFA1AD set to
0x2000 and SFA2AD set so 0x2800, I would except any access to
the 0x2000 -> 0x2800 range to be routed to CS1 not CS0. But
apparently it's not working like that.

Re: [PATCH] ASoC: qcom: add sdm845 sound card support

2018-06-19 Thread Srinivas Kandagatla


Thanks Rohit for the patch!

On 18/06/18 12:16, Rohit kumar wrote:

This patch adds sdm845 audio machine driver support.

Signed-off-by: Rohit kumar 
---
  .../devicetree/bindings/sound/qcom,sdm845.txt  |  87 
  sound/soc/qcom/Kconfig |   9 +
  sound/soc/qcom/Makefile|   2 +
  sound/soc/qcom/sdm845.c| 539 +
  4 files changed, 637 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/sound/qcom,sdm845.txt


Split the bindings into a separate patch!


  create mode 100644 sound/soc/qcom/sdm845.c

diff --git a/Documentation/devicetree/bindings/sound/qcom,sdm845.txt 
b/Documentation/devicetree/bindings/sound/qcom,sdm845.txt
new file mode 100644
index 000..fc0e98c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,sdm845.txt
@@ -0,0 +1,87 @@
+* Qualcomm Technologies Inc. SDM845 ASoC sound card driver
+
+This binding describes the SDM845 sound card, which uses qdsp for audio.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,sdm845-sndcard"
+
+- qcom,audio-routing:
+   Usage: Optional
+   Value type: 
+   Definition:  A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names could be power supplies, MicBias
+ of codec and the jacks on the board.
+
+- cdc-vdd-supply:
+   Usage: Optional
+   Value type: 
+   Definition: phandle of regulator supply required for codec vdd.
+
+= dailinks
+Each subnode of sndcard represents either a dailink, and subnodes of each
+dailinks would be cpu/codec/platform dais.
+
+- link-name:
+   Usage: required
+   Value type: 
+   Definition: User friendly name for dai link
+
+= CPU, PLATFORM, CODEC dais subnodes
+- cpu:
+   Usage: required
+   Value type: 
+   Definition: cpu dai sub-node
+
+- codec:
+   Usage: required
+   Value type: 
+   Definition: codec dai sub-node
+
+- platform:
+   Usage: opional


Optional

+   Value type: 
+   Definition: platform dai sub-node
+
+- sound-dai:
+   Usage: required
+   Value type: 
+   Definition: dai phandle/s and port of CPU/CODEC/PLATFORM node.
+
+Example:
+
+audio {
+   compatible = "qcom,sdm845-sndcard";
+   qcom,model = "sdm845-snd-card";
+   pinctrl-names = "pri_active", "pri_sleep";
+   pinctrl-0 = <&pri_mi2s_active &pri_mi2s_ws_active>;
+   pinctrl-1 = <&pri_mi2s_sleep &pri_mi2s_ws_sleep>;
+
+   qcom,audio-routing = "PRI_MI2S_RX Audio Mixer", "Pri-mi2s-gpio";
+
+   cdc-vdd-supply = <&pm8998_l14>;
+
+   fe@1 {

Lets not use fe or be reference here, its just a link.


+   link-name = "MultiMedia1";
+   cpu {
+   sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
+   };
+   platform {
+   sound-dai = <&q6asmdai>;
+   };
asmdai has sound-cell specifier as 1, so this will dtc will throw 
warning for this.


have a look at how 8996 is done.


+   };
+
+   be@1 {
+   link-name = "PRI MI2S Playback";
+   cpu {
+   sound-dai = <&q6afedai PRIMARY_MI2S_RX>;
+   };
+
+   platform {
+   sound-dai = <&q6routing>;
+   };
+   };
+};
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 87838fa..09de50d 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -90,3 +90,12 @@ config SND_SOC_MSM8996
Support for Qualcomm Technologies LPASS audio block in
APQ8096 SoC-based systems.
Say Y if you want to use audio device on this SoCs
+
+config SND_SOC_SDM845
+   tristate "SoC Machine driver for SDM845 boards"
+   depends on QCOM_APR
+   select SND_SOC_QDSP6
+   help
+ To add support for audio on Qualcomm Technologies Inc.
+ SDM845 SoC-based systems.
+  Say Y if you want to use audio device on this SoCs
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index 206945b..ac9609e 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -14,10 +14,12 @@ obj-$(CONFIG_SND_SOC_LPASS_APQ8016) += 
snd-soc-lpass-apq8016.o
  snd-soc-storm-objs := storm.o
  snd-soc-apq8016-sbc-objs := apq8016_sbc.o
  snd-soc-apq8096-objs := apq8096.o
+snd-soc-sdm845-objs := sdm845.o
  
  obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o

  obj-$(CONFIG_SND_SOC_APQ8016_SBC) += snd-soc-apq8016-sbc.o
  obj-$(CONFIG_SND_SOC_MSM8996) += snd-soc-apq8096.o
++obj-$(CONFIG_SND_SOC_SDM845) += snd-soc-sdm845.o


?? looks like typo here.

  
  #DSP lib

  obj-$(CONFIG_SND_SOC_QDSP6) += qdsp6/
diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c
new file mode 100644
index 00

Re: [RFC PATCH 6/8] x86/lib_direct_store.h: Add APIs for direct store instructions

On Fri, 15 Jun 2018, Fenghua Yu wrote:
> +static inline bool movdiri_supported(void)
> +{
> + int eax, ebx, ecx, edx;
> + bool ret;
> +
> + /*
> +  * If movdiri has been enumerated before, return cached movdiri
> +  * support info.
> +  */
> + if (_movdiri_enumerated)
> + return _movdiri_supported;
> +
> + /* Otherwise, enumerate movdiri from CPUID. */
> + asm volatile("mov $7, %%eax\t\n"
> +  "mov $0, %%ecx\t\n"
> +  "cpuid\t\n"
> +  : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx));

Why on earth do we need yet another machinery to figure out whether
something is enumerated in CPUID? We have feature bits and the whole set of
functions around it, including those which are run time patched.

Aside of that adding static booleans to every compilation unit which
includes that header file is just broken.

Thanks,

tglx

[PATCH] m68k/defconfig: Update defconfigs for v4.18-rc1

2018-06-19 Thread Geert Uytterhoeven

Signed-off-by: Geert Uytterhoeven 
---
For easier review:

$ git show | grep ^[-+][^-+] | sort | uniq -c
 12 -CONFIG_AUTOFS4_FS=m
 12 +CONFIG_AUTOFS_FS=m
 12 +# CONFIG_BATMAN_ADV_BATMAN_V is not set
 12 +CONFIG_CRYPTO_AEGIS128L=m
 12 +CONFIG_CRYPTO_AEGIS128=m
 12 +CONFIG_CRYPTO_AEGIS256=m
 12 +CONFIG_CRYPTO_MORUS1280=m
 12 +CONFIG_CRYPTO_MORUS640=m
 12 +CONFIG_CRYPTO_ZSTD=m
 12 +CONFIG_DM_WRITECACHE=m
 12 +# CONFIG_HID_REDRAGON is not set
 11 -# CONFIG_NET_CADENCE is not set
 11 +# CONFIG_NET_CADENCE is not set
 12 +# CONFIG_NET_VENDOR_MICROSEMI is not set
 12 -# CONFIG_NET_VENDOR_SYNOPSYS is not set
 12 +# CONFIG_NET_VENDOR_SYNOPSYS is not set
 12 -CONFIG_NF_SOCKET_IPV4=m
 12 -CONFIG_NF_SOCKET_IPV6=m
 12 -CONFIG_NFT_BRIDGE_META=m
 12 +CONFIG_NFT_CONNLIMIT=m
 12 -CONFIG_NFT_EXTHDR=m
 12 -CONFIG_NFT_META=m
 12 -CONFIG_NFT_RT=m
 12 +CONFIG_NFT_SOCKET=m
  2 +CONFIG_SCSI_ZORRO_ESP=y
 12 +CONFIG_TEST_OVERFLOW=m
 12 +CONFIG_XDP_SOCKETS=y
  2 +CONFIG_XSURF100=y
---
 arch/m68k/configs/amiga_defconfig| 28 +++-
 arch/m68k/configs/apollo_defconfig   | 26 +-
 arch/m68k/configs/atari_defconfig| 26 +-
 arch/m68k/configs/bvme6000_defconfig | 26 +-
 arch/m68k/configs/hp300_defconfig| 26 +-
 arch/m68k/configs/mac_defconfig  | 26 +-
 arch/m68k/configs/multi_defconfig| 28 +++-
 arch/m68k/configs/mvme147_defconfig  | 26 +-
 arch/m68k/configs/mvme16x_defconfig  | 26 +-
 arch/m68k/configs/q40_defconfig  | 26 +-
 arch/m68k/configs/sun3_defconfig | 24 
 arch/m68k/configs/sun3x_defconfig| 26 +-
 12 files changed, 207 insertions(+), 107 deletions(-)

diff --git a/arch/m68k/configs/amiga_defconfig 
b/arch/m68k/configs/amiga_defconfig
index a874e54404d10c94..6c4ba2cc94ddb14f 100644
--- a/arch/m68k/configs/amiga_defconfig
+++ b/arch/m68k/configs/amiga_defconfig
@@ -52,6 +52,7 @@ CONFIG_UNIX_DIAG=m
 CONFIG_TLS=m
 CONFIG_XFRM_MIGRATE=y
 CONFIG_NET_KEY=y
+CONFIG_XDP_SOCKETS=y
 CONFIG_INET=y
 CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
@@ -100,9 +101,6 @@ CONFIG_NF_CONNTRACK_TFTP=m
 CONFIG_NF_TABLES=m
 CONFIG_NF_TABLES_INET=y
 CONFIG_NF_TABLES_NETDEV=y
-CONFIG_NFT_EXTHDR=m
-CONFIG_NFT_META=m
-CONFIG_NFT_RT=m
 CONFIG_NFT_NUMGEN=m
 CONFIG_NFT_CT=m
 CONFIG_NFT_FLOW_OFFLOAD=m
@@ -110,6 +108,7 @@ CONFIG_NFT_SET_RBTREE=m
 CONFIG_NFT_SET_HASH=m
 CONFIG_NFT_SET_BITMAP=m
 CONFIG_NFT_COUNTER=m
+CONFIG_NFT_CONNLIMIT=m
 CONFIG_NFT_LOG=m
 CONFIG_NFT_LIMIT=m
 CONFIG_NFT_MASQ=m
@@ -122,6 +121,7 @@ CONFIG_NFT_REJECT=m
 CONFIG_NFT_COMPAT=m
 CONFIG_NFT_HASH=m
 CONFIG_NFT_FIB_INET=m
+CONFIG_NFT_SOCKET=m
 CONFIG_NFT_DUP_NETDEV=m
 CONFIG_NFT_FWD_NETDEV=m
 CONFIG_NFT_FIB_NETDEV=m
@@ -200,7 +200,6 @@ CONFIG_IP_SET_HASH_NETPORT=m
 CONFIG_IP_SET_HASH_NETIFACE=m
 CONFIG_IP_SET_LIST_SET=m
 CONFIG_NF_CONNTRACK_IPV4=m
-CONFIG_NF_SOCKET_IPV4=m
 CONFIG_NFT_CHAIN_ROUTE_IPV4=m
 CONFIG_NFT_DUP_IPV4=m
 CONFIG_NFT_FIB_IPV4=m
@@ -231,7 +230,6 @@ CONFIG_IP_NF_ARPTABLES=m
 CONFIG_IP_NF_ARPFILTER=m
 CONFIG_IP_NF_ARP_MANGLE=m
 CONFIG_NF_CONNTRACK_IPV6=m
-CONFIG_NF_SOCKET_IPV6=m
 CONFIG_NFT_CHAIN_ROUTE_IPV6=m
 CONFIG_NFT_CHAIN_NAT_IPV6=m
 CONFIG_NFT_MASQ_IPV6=m
@@ -260,7 +258,6 @@ CONFIG_IP6_NF_NAT=m
 CONFIG_IP6_NF_TARGET_MASQUERADE=m
 CONFIG_IP6_NF_TARGET_NPT=m
 CONFIG_NF_TABLES_BRIDGE=y
-CONFIG_NFT_BRIDGE_META=m
 CONFIG_NFT_BRIDGE_REJECT=m
 CONFIG_NF_LOG_BRIDGE=m
 CONFIG_BRIDGE_NF_EBTABLES=m
@@ -301,6 +298,7 @@ CONFIG_6LOWPAN_GHC_EXT_HDR_FRAG=m
 CONFIG_6LOWPAN_GHC_EXT_HDR_ROUTE=m
 CONFIG_DNS_RESOLVER=y
 CONFIG_BATMAN_ADV=m
+# CONFIG_BATMAN_ADV_BATMAN_V is not set
 CONFIG_BATMAN_ADV_DAT=y
 CONFIG_BATMAN_ADV_NC=y
 CONFIG_BATMAN_ADV_MCAST=y
@@ -356,6 +354,7 @@ CONFIG_A2091_SCSI=y
 CONFIG_GVP11_SCSI=y
 CONFIG_SCSI_A4000T=y
 CONFIG_SCSI_ZORRO7XX=y
+CONFIG_SCSI_ZORRO_ESP=y
 CONFIG_MD=y
 CONFIG_MD_LINEAR=m
 CONFIG_BLK_DEV_DM=m
@@ -363,6 +362,7 @@ CONFIG_DM_UNSTRIPED=m
 CONFIG_DM_CRYPT=m
 CONFIG_DM_SNAPSHOT=m
 CONFIG_DM_THIN_PROVISIONING=m
+CONFIG_DM_WRITECACHE=m
 CONFIG_DM_ERA=m
 CONFIG_DM_MIRROR=m
 CONFIG_DM_RAID=m
@@ -402,8 +402,8 @@ CONFIG_A2065=y
 CONFIG_ARIADNE=y
 # CONFIG_NET_VENDOR_AQUANTIA is not set
 # CONFIG_NET_VENDOR_ARC is not set
-# CONFIG_NET_CADENCE is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_CADENCE is not set
 # CONFIG_NET_VENDOR_CIRRUS is not set
 # CONFIG_NET_VENDOR_CORTINA is not set
 # CONFIG_NET_VENDOR_EZCHIP is not set
@@ -412,8 +412,10 @@ CONFIG_ARIADNE=y
 # CONFIG_NET_VENDOR_INTEL is not set
 # CONFIG_NET_VENDOR_MARVELL is not set
 # CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROSEMI is not set
 # CONFIG_NET_VENDOR_NETRONOME is not set
 # CONFIG_NET_VENDOR_NI is not set
+CONFIG_XSURF100=y
 CONFIG_HYDRA=y

Re: [patch] mm, oom: fix unnecessary killing of additional processes

2018-06-19 Thread Michal Hocko

On Mon 18-06-18 17:27:33, Andrew Morton wrote:
> On Thu, 14 Jun 2018 13:42:59 -0700 (PDT) David Rientjes  
> wrote:
> 
> > The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> > it cannot reap an mm.  This can happen for a variety of reasons,
> > including:
> > 
> >  - the inability to grab mm->mmap_sem in a sufficient amount of time,
> > 
> >  - when the mm has blockable mmu notifiers that could cause the oom reaper
> >to stall indefinitely,
> 
> Maybe we should have more than one oom reaper thread?  I assume the
> probability of the oom reaper thread blocking on an mmu notifier is
> small, so perhaps just dive in and hope for the best.  If the oom
> reaper gets stuck then there's another thread ready to take over.  And
> revisit the decision to use a kernel thread instead of workqueues.

Well, I think that having more threads would be wasteful for a rare
event like the oom. Creating one on demand could be tricky because we
are under strong memory pressure at the time and a new thread costs some
resoures.

> > but we can also add a third when the oom reaper can "reap" an mm but doing
> > so is unlikely to free any amount of memory:
> > 
> >  - when the mm's memory is fully mlocked.
> > 
> > When all memory is mlocked, the oom reaper will not be able to free any
> > substantial amount of memory.  It sets MMF_OOM_SKIP before the victim can
> > unmap and free its memory in exit_mmap() and subsequent oom victims are
> > chosen unnecessarily.  This is trivial to reproduce if all eligible
> > processes on the system have mlocked their memory: the oom killer calls
> > panic() even though forward progress can be made.
> > 
> > This is the same issue where the exit path sets MMF_OOM_SKIP before
> > unmapping memory and additional processes can be chosen unnecessarily
> > because the oom killer is racing with exit_mmap().
> 
> So what's actually happening here.  A process has a large amount of
> mlocked memory, it has been oom-killed and it is in the process of
> releasing its memory and exiting, yes?
> 
> If so, why does this task set MMF_OOM_SKIP on itself?  Why aren't we
> just patiently waiting for its attempt to release meory?

Because the oom victim has no guarantee to proceed to exit and release
its own memory. OOM reaper jumps in and skip over mlocked ranges because
they require lock page and that egain cannot be taken from the oom
reaper path (the lock might be held and doing an allocation). This in
turn means that the oom_reaper doesn't free mlocked memory before it
sets MMF_OOM_SKIP which will allow a new oom victim to be selected.
At the time we merged the oom reaper this hasn't been seen as a major
issue because tasks usually do not consume a lot of mlocked memory and
there is always some other memory to tear down and help to relief the
memory pressure. mlockall oom victim were deemed unlikely because they
need a large rlimit and as such it should be trusted and therefore quite
safe from runaways. But there was definitely a plan to make mlocked
memory reapable. So time to do it finally.

> > We can't simply defer setting MMF_OOM_SKIP, however, because if there is
> > a true oom livelock in progress, it never gets set and no additional
> > killing is possible.
> 
> I guess that's my answer.  What causes this livelock?  Process looping
> in alloc_pages while holding a lock the oom victim wants?

Yes.

> > To fix this, this patch introduces a per-mm reaping timeout, initially set
> > at 10s.  It requires that the oom reaper's list becomes a properly linked
> > list so that other mm's may be reaped while waiting for an mm's timeout to
> > expire.
> > 
> > This replaces the current timeouts in the oom reaper: (1) when trying to
> > grab mm->mmap_sem 10 times in a row with HZ/10 sleeps in between and (2)
> > a HZ sleep if there are blockable mmu notifiers.  It extends it with
> > timeout to allow an oom victim to reach exit_mmap() before choosing
> > additional processes unnecessarily.
> > 
> > The exit path will now set MMF_OOM_SKIP only after all memory has been
> > freed, so additional oom killing is justified,
> 
> That seems sensible, but why set MMF_OOM_SKIP at all?

MMF_OOM_SKIP is a way to say that the task should be skipped from OOM
victims evaluation.

> > and rely on MMF_UNSTABLE to
> > determine when it can race with the oom reaper.
> > 
> > The oom reaper will now set MMF_OOM_SKIP only after the reap timeout has
> > lapsed because it can no longer guarantee forward progress.
> > 
> > The reaping timeout is intentionally set for a substantial amount of time
> > since oom livelock is a very rare occurrence and it's better to optimize
> > for preventing additional (unnecessary) oom killing than a scenario that
> > is much more unlikely.
> 
> What happened to the old idea of permitting the task which is blocking
> the oom victim to access additional reserves?

How do you find such a task?

> Come to that, what happened to the really really old Andreaidea of not
> looping i

Re: [PATCH v8] powercap/drivers/idle_injection: Add an idle injection framework

2018-06-19 Thread Viresh Kumar

On 19-06-18, 10:00, Daniel Lezcano wrote:
> On 19/06/2018 08:22, Viresh Kumar wrote:
> > On 19-06-18, 07:58, Daniel Lezcano wrote:
> >> +++ b/drivers/powercap/idle_injection.c
> >> @@ -0,0 +1,375 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright 2018 Linaro Limited
> >> + *
> >> + * Author: Daniel Lezcano 
> >> + *
> >> + * The idle injection framework proposes a way to force a cpu to enter
> >> + * an idle state during a specified amount of time for a specified
> >> + * period.
> >> + *
> >> + * It relies on the smpboot kthreads which handles, via its main loop,
> >> + * the common code for hotplugging and [un]parking.
> >> + *
> >> + * At init time, all the kthreads are created.
> >> + *
> >> + * A cpumask is specified as parameter for the idle injection
> >> + * registering function. The kthreads will be synchronized regarding
> >> + * this cpumask.
> >> + *
> >> + * The idle + run duration is specified via the helpers and then the
> >> + * idle injection can be started at this point.
> >> + *
> >> + * A kthread will call play_idle() with the specified idle duration
> >> + * from above.
> >> + *
> >> + * A timer is set after waking up all the tasks, to the next idle
> >> + * injection cycle.
> >> + *
> >> + * The task handling the timer interrupt will wakeup all the kthreads
> >> + * belonging to the cpumask.
> >> + *
> >> + * Stopping the idle injection is synchonuous, when the function
> > 
> >  synchronous
> > 
> >> + * returns, there is the guarantee there is no more idle injection
> >> + * kthread in activity.
> >> + *
> >> + * It is up to the user of this framework to provide a lock at an
> >> + * upper level to prevent stupid things to happen, like starting while
> >> + * we are unregistering.
> >> + */
> > 
> >> +static void idle_injection_wakeup(struct idle_injection_device *ii_dev)
> >> +{
> >> +  struct idle_injection_thread *iit;
> >> +  unsigned int cpu;
> >> +
> >> +  for_each_cpu_and(cpu, to_cpumask(ii_dev->cpumask), cpu_online_mask) {
> >> +  iit = per_cpu_ptr(&idle_injection_thread, cpu);
> >> +  iit->should_run = 1;
> >> +  wake_up_process(iit->tsk);
> >> +  }
> >> +}
> > 
> > Thread AThread B
> > 
> > CPU3 hotplug out
> > -> idle_injection_park()
> >   iit(of-CPU3)->should_run 
> > = 0;
> > 
> > idle_injection_wakeup()
> >  for_each_cpu_and(online)..
> >CPU3-selected
> > clear CPU3 from cpu-online 
> > mask.
> > 
> > 
> >iit(of-CPU3)->should_run = 1;
> >wake_up_process()
> > 
> > With the above sequence of events, is it possible that the iit->should_run
> > variable is set to 1 while the CPU is offlined ? And so the crash we 
> > discussed
> > in the previous version may still exist ? Sorry I am not able to take my 
> > mind
> > away from thinking about these stupid races :(
> 
> If I refer to previous Peter's comment about a similar race, I think it
> is possible.
> 
> I guess setting the should_run flag to zero in the unpark() must fix the
> issue also.

Right. But since you are already taking the hotplug lock in stop-idle-injection,
you can iterate over all CPUs of a mask instead of the online ones. That would
be one callback less to run at every unpark (though there wouldn't be so many of
them I believe).

-- 
viresh

Re: [PATCH] MIPS: implement smp_cond_load_acquire() for Loongson-3

2018-06-19 Thread Will Deacon

Hi all,

On Tue, Jun 19, 2018 at 09:17:10AM +0200, Peter Zijlstra wrote:
> On Mon, Jun 18, 2018 at 11:51:41AM -0700, Paul Burton wrote:
> > On Fri, Jun 15, 2018 at 02:07:38PM +0800, Huacai Chen wrote:
> > > After commit 7f56b58a92aaf2c ("locking/mcs: Use smp_cond_load_acquire()
> > > in MCS spin loop") Loongson-3 fails to boot. This is because Loongson-3
> > > has SFB (Store Fill Buffer) and READ_ONCE() may get an old value in a
> > > tight loop. So in smp_cond_load_acquire() we need a __smp_mb() after
> > > every READ_ONCE().
> > 
> > Thanks - modifying smp_cond_load_acquire() is a step better than
> > modifying arch_mcs_spin_lock_contended() to avoid it, but I'm still not
> > sure we've reached the root of the problem. 
> 
> Agreed, this looks entirely dodgy.
> 
> > If tight loops using
> > READ_ONCE() are at fault then what's special about
> > smp_cond_load_acquire()? Could other such loops not hit the same
> > problem?
> 
> Right again, Linux has a number of places where it relies on loops like
> this.
> 
>   for (;;) {
>   if (READ_ONCE(*ptr))
>   break;
> 
>   cpu_relax();
>   }
> 
> That is assumed to terminate -- provided the store to make *ptr != 0
> happens of course.
> 
> And this has nothing to do with store buffers per se, sure store-buffers
> might delay the store from being visible for a (little) while, but we
> very much assume store buffers will not indefinitely hold on to data.

We had an issue 8 years ago with the 11MPCore CPU where reads were
prioritised over writes, so code doing something like:

  WRITE_ONCE(*foo, 1);
  while (!READ_ONCE(*bar));

might never make the store to foo visible to other CPUs. This caused a
livelock in KGDB, where two CPUs were doing this on opposite variables
(i.e. the "SB" litmus test, but with the reads looping until they read
1).

See 534be1d5a2da ("ARM: 6194/1: change definition of cpu_relax() for
ARM11MPCore") for the ugly fix, assuming that the "Store Fill Buffer"
suffers from the same disease.

Will

Re: Regression in 4.18-rc1 caused by regulator: arizona-ldo1: Look up a descriptor and pass to the core

2018-06-19 Thread Charles Keepax

On Mon, Jun 18, 2018 at 07:14:10PM +0200, Matthias Reichl wrote:
> Commit e1739e86f0cb9c48e8745a610e6981a4e24cadad breaks reading
> the wlf,ldoena property from device tree. This causes ldo1 to
> stay off and thus arizona device detection to fail:
> 
> [4.495958] of_get_named_gpiod_flags: parsed 'wlf,reset' property of node 
> '/s
> oc/spi@7e204000/wm5102@1[0]' - status (0)
> [4.509756] arizona-ldo1 arizona-ldo1: GPIO lookup for consumer wlf,ldoena
> [4.511339] arizona-ldo1 arizona-ldo1: using lookup tables for GPIO lookup
> [4.511351] arizona-ldo1 arizona-ldo1: No GPIO consumer wlf,ldoena found
> [4.511413] LDO1: supplied by RPi-Cirrus 1v8
> [4.549164] arizona spi0.1: Unknown device ID: 0
> 
> With this commit reverted the ldoena GPIO is properly found and
> asserted high and the arizona device type is read successfully:
> 
> [4.630445] of_get_named_gpiod_flags: parsed 'wlf,reset' property of node 
> '/s
> oc/spi@7e204000/wm5102@1[0]' - status (0)
> [4.647622] of_get_named_gpiod_flags: parsed 'wlf,ldoena' property of node 
> '/soc/spi@7e204000/wm5102@1[0]' - status (0)
> [4.666100] arizona spi0.1: WM5102 revision C
> 
> I've tested this on a Raspberry Pi 3 with upstream 4.18-rc1,
> the Cirrus Logic Audio Card from Element 14 (using a WM5102
> connected via SPI) and the downstream card driver added as
> a module.
> 
> Both wlf,reset and wlf,ldoena properties are defined in
> the wm5102 devicetree node:
> 
> wm5102@1{
>   compatible = "wlf,wm5102";
>   reg = <1>;
>   ...
>   wlf,reset = <&gpio 17 0>;
>   wlf,ldoena = <&gpio 22 0>;
>   ...
> };
> 
> If I understand the code correctly the cuplrit seems to be that
> with this patch the gpio is looked up from the arizona-ldo1 dev,
> which has a NULL of_node:
> 
> config.ena_gpiod = devm_gpiod_get_optional(&pdev->dev, "wlf,ldoena", ...
> 
> The old version did an of lookup in the parent (arizona) dev, which
> contains the of_node with wlf,ldoena:
> 
> arizona_ldo1_common_init:
>   struct device *parent_dev = pdev->dev.parent;
>   struct regulator_config config = { };
>   ...
>   config.dev = parent_dev;
>   ...
>   arizona_ldo1_of_get_pdata(pdata, config, ...
> 
> arizona_ldo1_of_get_pdata:
>   struct device_node *np = config->dev->of_node;
>   ...
>   pdata->ldoena = of_get_named_gpio(np, "wlf,ldoena", 0);
> 

Urgh.. sorry about that. I did test that patch but it seems I
messed it up. On our boards the LDOENA defaults to on so I missed
that it wasn't getting configured anymore.

I think we just need to not use the devm version of the
get_optional and pass the correct device. I will get a patch
ready this morning and ping it through for testing.

Thanks,
Charles

Re: [PATCH 2/2] cpufreq: qcom-fw: Add support for QCOM cpufreq FW driver

2018-06-19 Thread Viresh Kumar

Sorry for being late..

On 07-06-18, 12:48, Taniya Das wrote:
> On 6/6/2018 11:31 AM, Viresh Kumar wrote:
> > On 04-06-18, 16:16, Taniya Das wrote:

> > > +static struct cpufreq_driver cpufreq_qcom_fw_driver = {
> > > + .flags  = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
> > > +   CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
> > > + .verify = cpufreq_generic_frequency_table_verify,
> > > + .target_index   = qcom_cpufreq_fw_target_index,
> > > + .get= qcom_cpufreq_fw_get,
> > > + .init   = qcom_cpufreq_fw_cpu_init,
> > 
> > What about CPU hotplug ? We can still do that, right ? So what will happen 
> > if
> > all CPUs of a freq-domain are removed (hence cpufreq policy is removed) and 
> > then
> > someone calls qcom_cpufreq_fw_get() ? You should really work on 
> > cpufreq_policy
> > there to get 'c'.
> > 
> 
> You want the _get to do something as below.
> Please correct me if my understanding is wrong.
> 
> 
>  policy = cpufreq_cpu_get_raw(cpu);
>  if (!policy)
> return 0;
> 
>  c = policy->driver_data;
> 
>  index = readl_relaxed(c->perf_base);
>  index = min(index, LUT_MAX_ENTRIES - 1);
> 
>  return c->table[index].frequency;
> 
> 

Right.

> > > +static int qcom_read_lut(struct platform_device *pdev,
> > > +  struct cpufreq_qcom *c)
> > > +{
> > > + struct device *dev = &pdev->dev;
> > > + u32 data, src, lval, i, core_count, prev_cc, prev_freq, cur_freq;
> > > +
> > > + c->table = devm_kcalloc(dev, LUT_MAX_ENTRIES + 1,
> > > + sizeof(*c->table), GFP_KERNEL);
> > > + if (!c->table)
> > > + return -ENOMEM;
> > > +
> > > + for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> > > + data = readl_relaxed(c->lut_base + i * LUT_ROW_SIZE);
> > > + src = ((data & GENMASK(31, 30)) >> 30);
> > > + lval = (data & GENMASK(7, 0));
> > > + core_count = CORE_COUNT_VAL(data);
> > > +
> > > + if (!src)
> > > + c->table[i].frequency = INIT_RATE / 1000;
> > > + else
> > > + c->table[i].frequency = XO_RATE * lval / 1000;
> > > +
> > > + cur_freq = c->table[i].frequency;
> > > +
> > > + dev_dbg(dev, "index=%d freq=%d, core_count %d\n",
> > > + i, c->table[i].frequency, core_count);
> > > +
> > > + if (core_count != c->max_cores)
> > > + cur_freq = CPUFREQ_ENTRY_INVALID;
> > > +
> > > + /*
> > > +  * Two of the same frequencies with the same core counts means
> > > +  * end of table.
> > > +  */
> > > + if (i > 0 && c->table[i - 1].frequency ==
> > > +c->table[i].frequency && prev_cc == core_count) {
> > > + struct cpufreq_frequency_table *prev = &c->table[i - 1];
> > > +
> > > + if (prev_freq == CPUFREQ_ENTRY_INVALID)
> > > + prev->flags = CPUFREQ_BOOST_FREQ;
> > > + break;
> > > + }
> > > + prev_cc = core_count;
> > > + prev_freq = cur_freq;
> > > + }
> > > +
> > > + c->table[i].frequency = CPUFREQ_TABLE_END;
> > > +
> > > + return 0;
> > > +}
> > 
> > Looks like there are many problems here.
> > - You are assigning prev_freq with cur_freq (which may be uninitialized 
> > local
> >variable here).
> > - In this version, you never write CPUFREQ_ENTRY_INVALID to 
> > table[i].frequency,
> >which looks wrong as well.
> > 
> 
> - The code to detect boost, would only enter for i > 0 and the prev_freq
> would be initialized with the cur_freq.
> - In the case where the core_count != max_cores, the cur_freq is marked
> INVALID, and when both prev_freq == cur_freq && prev_cc && cur_cc match,
> that is the time the prev table flags need to be updated. Marking the
> table[i].frequency as INVALID is not required as cur_freq is already marked
> with the same. Please correct me if you think otherwise.

Yeah but the value of cur_freq isn't written to the table entries now. This
wasn't the case in the earlier version. Have a look at that one.

-- 
viresh

Re: [RFC PATCH 1/8] x86/cpufeatures: Enumerate MOVDIRI instruction

On Fri, 15 Jun 2018, Fenghua Yu wrote:

> MOVDIRI moves doubleword or quadword from register to memory through
> direct store which is implemented by using write combining (WC) for
> writing data directly into memory without caching the data.

And that is useful for what?

Thanks,

tglx

[PATCH v5 0/7] add virt-dma support for imx-sdma

The legacy sdma driver has below limitations or drawbacks:
  1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
 one page size for one channel regardless of only few BDs needed
 most time. But in few cases, the max PAGE_SIZE maybe not enough.
  2. One SDMA channel can't stop immediatley once channel disabled which
 means SDMA interrupt may come in after this channel terminated.There
 are some patches for this corner case such as commit "2746e2c389f9",
 but not cover non-cyclic.

The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.

Change from v4:
  1. identify lockdep issue which caused by allocate memory with
 'GFP_KERNEL', change to 'GFP_NOWAIT' instead so that lockdep
 ignore check. That also make sense since Audio/uart driver may
 call dma function after spin_lock_irqsave()...
  2. use dma pool instead for bd description allocated,since audio
 driver may call dma_terminate_all in irq. Please refer to 7/7.
  3. remove 7/7 serial patch in v4, since lockdep issued fixed by No.1 

Change from v3:
  1. add two uart patches which impacted by this patchset.
  2. unlock 'vc.lock' before cyclic dma callback and lock again after
 it because some driver such as uart will call dmaengine_tx_status
 which will acquire 'vc.lock' again and dead lock comes out.
  3. remove 'Revert commit' stuff since that patch is not wrong and
 combine two patch into one patch as Sascha's comment.

Change from v2:
  1. include Sascha's patch to make the main patch easier to review.
 Thanks Sacha.
  2. remove useless 'desc'/'chan' in struct sdma_channe.

Change from v1:
  1. split v1 patch into 5 patches.
  2. remove some unnecessary condition check.
  3. remove unnecessary 'pending' list.

Robin Gong (6):
  tty: serial: imx: correct dma cookie status
  dmaengine: imx-sdma: add virt-dma support
  dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct
sdma_channel'
  dmaengine: imx-sdma: remove the maximum limitation for bd numbers
  dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
  dmaengine: imx-sdma: alloclate bd memory from dma pool

Sascha Hauer (1):
  dmaengine: imx-sdma: factor out a struct sdma_desc from struct
sdma_channel

 drivers/dma/Kconfig  |   1 +
 drivers/dma/imx-sdma.c   | 400 +++
 drivers/tty/serial/imx.c |   2 +-
 3 files changed, 235 insertions(+), 168 deletions(-)

-- 
2.7.4

[PATCH v5 4/7] dmaengine: imx-sdma: remove useless 'lock' and 'enabled' in 'struct sdma_channel'

Since 'sdmac->vc.lock' and 'sdmac->desc' can be used as 'lock' and
'enabled' in 'struct sdma_channel sdmac', remove them.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 86fa799..d1d3494 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -342,10 +342,8 @@ struct sdma_channel {
unsigned long   event_mask[2];
unsigned long   watermark_level;
u32 shp_addr, per_addr;
-   spinlock_t  lock;
enum dma_status status;
struct imx_dma_data data;
-   boolenabled;
 };
 
 #define IMX_DMA_SG_LOOPBIT(0)
@@ -606,14 +604,7 @@ static int sdma_config_ownership(struct sdma_channel 
*sdmac,
 
 static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
 {
-   unsigned long flags;
-   struct sdma_channel *sdmac = &sdma->channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
-   spin_lock_irqsave(&sdmac->lock, flags);
-   sdmac->enabled = true;
-   spin_unlock_irqrestore(&sdmac->lock, flags);
 }
 
 /*
@@ -731,14 +722,6 @@ static void sdma_update_channel_loop(struct sdma_channel 
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
-   unsigned long flags;
-
-   spin_lock_irqsave(&sdmac->lock, flags);
-   if (!sdmac->enabled) {
-   spin_unlock_irqrestore(&sdmac->lock, flags);
-   return;
-   }
-   spin_unlock_irqrestore(&sdmac->lock, flags);
 
/*
 * loop mode. Iterate over descriptors, re-setup them and
@@ -1000,15 +983,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
-   unsigned long flags;
 
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
 
-   spin_lock_irqsave(&sdmac->lock, flags);
-   sdmac->enabled = false;
-   spin_unlock_irqrestore(&sdmac->lock, flags);
-
return 0;
 }
 
@@ -1922,7 +1900,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = &sdma->channel[i];
 
sdmac->sdma = sdma;
-   spin_lock_init(&sdmac->lock);
 
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
-- 
2.7.4

[PATCH v5 6/7] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap

There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 83 ++
 1 file changed, 37 insertions(+), 46 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 9f1a462..f8becaf 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1248,6 +1248,40 @@ static void sdma_free_chan_resources(struct dma_chan 
*chan)
clk_disable(sdma->clk_ahb);
 }
 
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+   enum dma_transfer_direction direction, u32 bds)
+{
+   struct sdma_desc *desc;
+
+   desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
+   if (!desc)
+   goto err_out;
+
+   sdmac->status = DMA_IN_PROGRESS;
+   sdmac->direction = direction;
+   sdmac->flags = 0;
+
+   desc->chn_count = 0;
+   desc->chn_real_count = 0;
+   desc->buf_tail = 0;
+   desc->buf_ptail = 0;
+   desc->sdmac = sdmac;
+   desc->num_bd = bds;
+
+   if (sdma_alloc_bd(desc))
+   goto err_desc_out;
+
+   if (sdma_load_context(sdmac))
+   goto err_desc_out;
+
+   return desc;
+
+err_desc_out:
+   kfree(desc);
+err_out:
+   return NULL;
+}
+
 static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1260,36 +1294,13 @@ static struct dma_async_tx_descriptor 
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
 
-   if (sdmac->status == DMA_IN_PROGRESS)
-   return NULL;
-   sdmac->status = DMA_IN_PROGRESS;
-
-   sdmac->flags = 0;
-
-   desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
+   desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
 
-   desc->buf_tail = 0;
-   desc->buf_ptail = 0;
-   desc->sdmac = sdmac;
-   desc->num_bd = sg_len;
-   desc->chn_real_count = 0;
-
-   if (sdma_alloc_bd(desc)) {
-   kfree(desc);
-   goto err_out;
-   }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
 
-   sdmac->direction = direction;
-   ret = sdma_load_context(sdmac);
-   if (ret)
-   goto err_bd_out;
-
-   desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
@@ -1365,38 +1376,18 @@ static struct dma_async_tx_descriptor 
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
-   int ret, i = 0, buf = 0;
+   int i = 0, buf = 0;
struct sdma_desc *desc;
 
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
 
-   if (sdmac->status == DMA_IN_PROGRESS)
-   return NULL;
-
-   sdmac->status = DMA_IN_PROGRESS;
-
-   desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
+   desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
 
-   desc->buf_tail = 0;
-   desc->buf_ptail = 0;
-   desc->sdmac = sdmac;
-   desc->num_bd = num_periods;
-   desc->chn_real_count = 0;
desc->period_len = period_len;
 
sdmac->flags |= IMX_DMA_SG_LOOP;
-   sdmac->direction = direction;
-
-   if (sdma_alloc_bd(desc)) {
-   kfree(desc);
-   goto err_bd_out;
-   }
-
-   ret = sdma_load_context(sdmac);
-   if (ret)
-   goto err_bd_out;
 
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size 
exceeded: %zu > %d\n",
-- 
2.7.4

[PATCH v5 7/7] dmaengine: imx-sdma: alloclate bd memory from dma pool

dma_terminate_all maybe called in interrupt context which means
WARN_ON() will be triggered as below when bd memory freed. Allocat
bd memory from dma pool instead.

[   29.161079] WARNING: CPU: 1 PID: 533 at ./include/linux/dma-mapping.h:541 
sdma_free_bd+0xa4/0xb4
[   29.169883] Modules linked in:
[   29.172990] CPU: 1 PID: 533 Comm: mpegaudioparse0 Not tainted 
4.18.0-rc1-next-20180618-9-gf79f22c #20
[   29.182597] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[   29.189163] Backtrace:
[   29.191685] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
[   29.199306]  r7: r6:600f0093 r5: r4:c107db7c
[   29.205029] [] (show_stack) from [] 
(dump_stack+0xb4/0xe8)
[   29.212312] [] (dump_stack) from [] (__warn+0x104/0x130)
[   29.219411]  r9:ec3e817c r8:021d r7:0009 r6:c0d1d440 r5: 
r4:
[   29.227204] [] (__warn) from [] 
(warn_slowpath_null+0x44/0x50)
[   29.234821]  r8:ed129dc4 r7:c0b01978 r6:c04d4e90 r5:021d r4:c0d1d440
[   29.241574] [] (warn_slowpath_null) from [] 
(sdma_free_bd+0xa4/0xb4)
[   29.249706]  r6:4c001000 r5:f082e000 r4:0024
[   29.254376] [] (sdma_free_bd) from [] 
(sdma_desc_free+0x14/0x20)
[   29.262163]  r7:ec3e8110 r6:0100 r5:0200 r4:ecf89a00
[   29.267873] [] (sdma_desc_free) from [] 
(vchan_dma_desc_free_list+0xa4/0xac)
[   29.276697]  r5:0200 r4:ed129d9c
[   29.280326] [] (vchan_dma_desc_free_list) from [] 
(sdma_disable_channel_with_delay+0x14c/0x188)
[   29.290808]  r9:ecae560c r8:ec3e815c r7: r6:c1008908 r5:ed129dc4 
r4:ec3e8110
[   29.298605] [] (sdma_disable_channel_with_delay) from [] 
(snd_dmaengine_pcm_trigger+0x90/0x1b0)
[   29.309087]  r8:ecae5000 r7:ec940800 r6:ed31bd80 r5:ecadb200 r4:ec26a700
[   29.315855] [] (snd_dmaengine_pcm_trigger) from [] 
(soc_pcm_trigger+0xb4/0x130)
[   29.324953]  r8:ecae5000 r7:ec940800 r6: r5:ecadb200 r4:ec26a700
[   29.331716] [] (soc_pcm_trigger) from [] 
(snd_pcm_do_stop+0x58/0x5c)
[   29.339859]  r9:ecaed5a8 r8:ed31bdc0 r7: r6:0001 r5:ecadb200 
r4:c0b9c4d0
[   29.347652] [] (snd_pcm_do_stop) from [] 
(snd_pcm_action_single+0x40/0x80)
[   29.356315] [] (snd_pcm_action_single) from [] 
(snd_pcm_action+0xf4/0xfc)
[   29.364883]  r7:0001 r6:c0b9c4d0 r5:ecadb2d4 r4:ecadb200
[   29.370593] [] (snd_pcm_action) from [] 
(snd_pcm_drop+0x58/0x9c)

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f8becaf..7dab7e9 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -343,6 +344,7 @@ struct sdma_channel {
u32 shp_addr, per_addr;
enum dma_status status;
struct imx_dma_data data;
+   struct dma_pool *bd_pool;
 };
 
 #define IMX_DMA_SG_LOOPBIT(0)
@@ -1153,11 +1155,10 @@ static int sdma_request_channel0(struct sdma_engine 
*sdma)
 
 static int sdma_alloc_bd(struct sdma_desc *desc)
 {
-   u32 bd_size = desc->num_bd * sizeof(struct sdma_buffer_descriptor);
int ret = 0;
 
-   desc->bd = dma_zalloc_coherent(NULL, bd_size, &desc->bd_phys,
-   GFP_ATOMIC);
+   desc->bd = dma_pool_alloc(desc->sdmac->bd_pool, GFP_ATOMIC,
+   &desc->bd_phys);
if (!desc->bd) {
ret = -ENOMEM;
goto out;
@@ -1168,9 +1169,7 @@ static int sdma_alloc_bd(struct sdma_desc *desc)
 
 static void sdma_free_bd(struct sdma_desc *desc)
 {
-   u32 bd_size = desc->num_bd * sizeof(struct sdma_buffer_descriptor);
-
-   dma_free_coherent(NULL, bd_size, desc->bd, desc->bd_phys);
+   dma_pool_free(desc->sdmac->bd_pool, desc->bd, desc->bd_phys);
 }
 
 static void sdma_desc_free(struct virt_dma_desc *vd)
@@ -1218,6 +1217,10 @@ static int sdma_alloc_chan_resources(struct dma_chan 
*chan)
if (ret)
goto disable_clk_ahb;
 
+   sdmac->bd_pool = dma_pool_create("bd_pool", chan->device->dev,
+   sizeof(struct sdma_buffer_descriptor),
+   32, 0);
+
return 0;
 
 disable_clk_ahb:
@@ -1246,6 +1249,9 @@ static void sdma_free_chan_resources(struct dma_chan 
*chan)
 
clk_disable(sdma->clk_ipg);
clk_disable(sdma->clk_ahb);
+
+   dma_pool_destroy(sdmac->bd_pool);
+   sdmac->bd_pool = NULL;
 }
 
 static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
-- 
2.7.4

[PATCH v5 5/7] dmaengine: imx-sdma: remove the maximum limitation for bd numbers

No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.

Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d1d3494..9f1a462 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -285,7 +285,6 @@ struct sdma_context_data {
u32  scratch7;
 } __attribute__ ((packed));
 
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
 
 struct sdma_engine;
 
@@ -1290,13 +1289,6 @@ static struct dma_async_tx_descriptor 
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
 
-   if (sg_len > NUM_BD) {
-   dev_err(sdma->dev, "SDMA channel %d: maximum number of sg 
exceeded: %d > %d\n",
-   channel, sg_len, NUM_BD);
-   ret = -EINVAL;
-   goto err_bd_out;
-   }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
@@ -1406,12 +1398,6 @@ static struct dma_async_tx_descriptor 
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
 
-   if (num_periods > NUM_BD) {
-   dev_err(sdma->dev, "SDMA channel %d: maximum number of sg 
exceeded: %d > %d\n",
-   channel, num_periods, NUM_BD);
-   goto err_bd_out;
-   }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size 
exceeded: %zu > %d\n",
channel, period_len, 0x);
-- 
2.7.4

Re: [RFC][PATCH 0/6] Use printk_safe context for TTY and UART port locks

2018-06-19 Thread Sergey Senozhatsky

On (06/19/18 10:30), Petr Mladek wrote:
> It is re-entrant via printk(). I mean that any printk() called inside
> the locked sections might cause recursion if the same lock is needed
> also by con->write() callbacks.

Perhaps Alan meant that we cannot return back to tty once we passed
the control from tty to printk -> uart serial console. So tty is
probably (but I didn't check) not re-entrant, but uart definitely is
re-entrant: IRQ -> uart console -> tty -> printk -> uart console.

The patch set attempts to address several issues, and re-entrant uart
is just one of them.

[..]
> This patchset forces safe context around TTY and UART locks.

Right.

> In fact, the deferred context would be enough to prevent
> all the mentioned deadlocks.

Agree.
But we can leave it as a printk_safe implementation detail and
change it later, outside of this patch, to avoid further confusion.

> IMHO, the only question is if people might get familiar with
> yet another spin_lock API.

Right. That's why I thought about renaming uart_port and tty_port
->lock to ->lock. So the naming will suggest [hopefully] that
those locks are not meant to be used directly [anymore] and instead
people should use uart_port_lock/tty_port_lock API.

-ss

[PATCH v5 2/7] dmaengine: imx-sdma: factor out a struct sdma_desc from struct sdma_channel

From: Sascha Hauer 

This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel
there and add a pointer from the former to the latter. For now we
allocate the data statically in struct sdma_channel, but with
virt-dma support it will be dynamically allocated.

Signed-off-by: Sascha Hauer 
Signed-off-by: Robin Gong 
---
 drivers/dma/imx-sdma.c | 137 ++---
 1 file changed, 83 insertions(+), 54 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f0779926..19c351f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -289,6 +289,30 @@ struct sdma_context_data {
 struct sdma_engine;
 
 /**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail   ID of the buffer that was processed
+ * @buf_ptail  ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count  the transfer count setuped
+ * @sdmac  sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+   unsigned intnum_bd;
+   dma_addr_t  bd_phys;
+   unsigned intbuf_tail;
+   unsigned intbuf_ptail;
+   unsigned intperiod_len;
+   unsigned intchn_real_count;
+   unsigned intchn_count;
+   struct sdma_channel *sdmac;
+   struct sdma_buffer_descriptor *bd;
+};
+
+/**
  * struct sdma_channel - housekeeping for a SDMA channel
  *
  * @sdma   pointer to the SDMA engine for this channel
@@ -298,11 +322,10 @@ struct sdma_engine;
  * @event_id0  aka dma request line
  * @event_id1  for channels that use 2 events
  * @word_size  peripheral access size
- * @buf_tail   ID of the buffer that was processed
- * @buf_ptail  ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
  */
 struct sdma_channel {
+   struct sdma_desc*desc;
+   struct sdma_desc_desc;
struct sdma_engine  *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -310,12 +333,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
-   unsigned intbuf_tail;
-   unsigned intbuf_ptail;
-   unsigned intnum_bd;
-   unsigned intperiod_len;
-   struct sdma_buffer_descriptor   *bd;
-   dma_addr_t  bd_phys;
unsigned intpc_from_device, pc_to_device;
unsigned intdevice_to_device;
unsigned long   flags;
@@ -325,10 +342,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t  lock;
-   struct dma_async_tx_descriptor  desc;
+   struct dma_async_tx_descriptor  txdesc;
enum dma_status status;
-   unsigned intchn_count;
-   unsigned intchn_real_count;
struct tasklet_struct   tasklet;
struct imx_dma_data data;
boolenabled;
@@ -391,6 +406,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned intirq;
+   dma_addr_t  bd0_phys;
+   struct sdma_buffer_descriptor   *bd0;
 };
 
 static struct sdma_driver_data sdma_imx31 = {
@@ -625,7 +642,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
 static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
 {
-   struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+   struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -700,7 +717,9 @@ static void sdma_update_channel_loop(struct sdma_channel 
*sdmac)
 * call callback function.
 */
while (1) {
-   bd = &sdmac->bd[sdmac->buf_tail];
+   struct sdma_desc *desc = sdmac->desc;
+
+   bd = &desc->bd[desc->buf_tail];
 
if (bd->mode.status & BD_DONE)
break;
@@ -716,11 +735,11 @@ static void sdma_update_channel_loop(struct sdma_channel

[PATCH v5 3/7] dmaengine: imx-sdma: add virt-dma support

The legacy sdma driver has below limitations or drawbacks:
  1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
 one page size for one channel regardless of only few BDs needed
 most time. But in few cases, the max PAGE_SIZE maybe not enough.
  2. One SDMA channel can't stop immediatley once channel disabled which
 means SDMA interrupt may come in after this channel terminated.There
 are some patches for this corner case such as commit "2746e2c389f9",
 but not cover non-cyclic.

The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.

Signed-off-by: Robin Gong 
---
 drivers/dma/Kconfig|   1 +
 drivers/dma/imx-sdma.c | 263 -
 2 files changed, 171 insertions(+), 93 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index ca1680a..d4a4230 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -250,6 +250,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
help
  Support the i.MX SDMA engine. This engine is integrated into
  Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 19c351f..86fa799 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -41,6 +41,7 @@
 #include 
 
 #include "dmaengine.h"
+#include "virt-dma.h"
 
 /* SDMA registers */
 #define SDMA_H_C0PTR   0x000
@@ -301,6 +302,7 @@ struct sdma_engine;
  * @bd pointer of alloced bd
  */
 struct sdma_desc {
+   struct virt_dma_descvd;
unsigned intnum_bd;
dma_addr_t  bd_phys;
unsigned intbuf_tail;
@@ -324,8 +326,8 @@ struct sdma_desc {
  * @word_size  peripheral access size
  */
 struct sdma_channel {
+   struct virt_dma_chanvc;
struct sdma_desc*desc;
-   struct sdma_desc_desc;
struct sdma_engine  *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -340,11 +342,8 @@ struct sdma_channel {
unsigned long   event_mask[2];
unsigned long   watermark_level;
u32 shp_addr, per_addr;
-   struct dma_chan chan;
spinlock_t  lock;
-   struct dma_async_tx_descriptor  txdesc;
enum dma_status status;
-   struct tasklet_struct   tasklet;
struct imx_dma_data data;
boolenabled;
 };
@@ -698,6 +697,35 @@ static void sdma_event_disable(struct sdma_channel *sdmac, 
unsigned int event)
writel_relaxed(val, sdma->regs + chnenbl);
 }
 
+static struct sdma_desc *to_sdma_desc(struct dma_async_tx_descriptor *t)
+{
+   return container_of(t, struct sdma_desc, vd.tx);
+}
+
+static void sdma_start_desc(struct sdma_channel *sdmac)
+{
+   struct virt_dma_desc *vd = vchan_next_desc(&sdmac->vc);
+   struct sdma_desc *desc;
+   struct sdma_engine *sdma = sdmac->sdma;
+   int channel = sdmac->channel;
+
+   if (!vd) {
+   sdmac->desc = NULL;
+   return;
+   }
+   sdmac->desc = desc = to_sdma_desc(&vd->tx);
+   /*
+* Do not delete the node in desc_issued list in cyclic mode, otherwise
+* the desc alloced will never be freed in vchan_dma_desc_free_list
+*/
+   if (!(sdmac->flags & IMX_DMA_SG_LOOP))
+   list_del(&vd->node);
+
+   sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+   sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
+   sdma_enable_channel(sdma, sdmac->channel);
+}
+
 static void sdma_update_channel_loop(struct sdma_channel *sdmac)
 {
struct sdma_buffer_descriptor *bd;
@@ -716,7 +744,7 @@ static void sdma_update_channel_loop(struct sdma_channel 
*sdmac)
 * loop mode. Iterate over descriptors, re-setup them and
 * call callback function.
 */
-   while (1) {
+   while (sdmac->desc) {
struct sdma_desc *desc = sdmac->desc;
 
bd = &desc->bd[desc->buf_tail];
@@ -747,15 +775,16 @@ static void sdma_update_channel_loop(struct sdma_channel 
*sdmac)
 * SDMA transaction status by the time the client tasklet is
 * executed.
 */
-
-   dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
+

Re: [RFC PATCH v2 5/6] mtd: rawnand: micron: add ONFI_FEATURE_ON_DIE_ECC to supported features

2018-06-19 Thread Miquel Raynal



> On Tue, 19 Jun 2018 17:31:24 +1200
> Chris Packham  wrote:
> 
> > Add ONFI_FEATURE_ON_DIE_ECC to the set/get features list for Micron
> > NAND flash.
> >  
> 
> Fixes: 789157e41a06 ("mtd: rawnand: allow vendors to declare (un)supported 
> features")
> Cc: 
> 
> No need to send a new version, I'll add that when queuing the patch.
> 
> Miquel, if you're okay, I'm gonna take this patch in the mtd/fixes branch
> and let you deal with other patches in this series.
> 
> > Signed-off-by: Chris Packham 

Reviewed-by: Miquel Raynal 

Thanks,
Miquèl

[PATCH v5 1/7] tty: serial: imx: correct dma cookie status

Correct to check the right rx dma cookie status in spit of it
works because only one cookie is running in the current sdma.
But it will not once sdma driver support multi cookies
running based on virt-dma.

Signed-off-by: Robin Gong 
---
 drivers/tty/serial/imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 4e85357..2879407 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1051,7 +1051,7 @@ static void imx_uart_dma_rx_callback(void *data)
unsigned int r_bytes;
unsigned int bd_size;
 
-   status = dmaengine_tx_status(chan, (dma_cookie_t)0, &state);
+   status = dmaengine_tx_status(chan, sport->rx_cookie, &state);
 
if (status == DMA_ERROR) {
imx_uart_clear_rx_errors(sport);
-- 
2.7.4

Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-06-19 Thread Matthew Wilcox

On Tue, Jun 19, 2018 at 10:29:49AM +0200, Jan Kara wrote:
> And for record, the problem with page cache pages is not only that
> try_to_unmap() may unmap them. It is also that page_mkclean() can
> write-protect them. And once PTEs are write-protected filesystems may end
> up doing bad things if DMA then modifies the page contents (DIF/DIX
> failures, data corruption, oopses). As such I don't think that solutions
> based on page reference count have a big chance of dealing with the
> problem.
> 
> And your page flag approach would also need to take page_mkclean() into
> account. And there the issue is that until the flag is cleared (i.e., we
> are sure there are no writers using references from GUP) you cannot
> writeback the page safely which does not work well with your idea of
> clearing the flag only once the page is evicted from page cache (hint, page
> cache page cannot get evicted until it is written back).
> 
> So as sad as it is, I don't see an easy solution here.

Pages which are "got" don't need to be on the LRU list.  They'll be
marked dirty when they're put, so we can use page->lru for fun things
like a "got" refcount.  If we use bit 1 of page->lru for PageGot, we've
got 30/62 bits in the first word and a full 64 bits in the second word.

Re: [RFC PATCH 4/8] cpuidle: Set up maximum umwait time and umwait states

On Fri, 15 Jun 2018, Fenghua Yu wrote:
> By default C0.2 is enabled so user wait can save more power but wakeup
> time is slower. In some cases e.g. real time, user wants to disable C0.2
> so that user wait saves less power but wakeup time is faster.

Why is this default enabled?

> A new "/sys/devices/system/cpu/cpuidle/umwait_disable_c0_2" file is
> created to allow user to check if C0.2 is enabled or disabled and also
> allow user to enable or disable C0.2. Value "1" in the file means C0.2 is
> disabled. Value "0" means C0.2 is enabled.

Can we please use straight forward positive logic and have a enable file?

> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * umwait.c - control user wait

Please remove these pointless file references. They get stale before its merged.

> + *
> + * Copyright (c) 2018, Intel Corporation.
> + * Fenghua Yu 
> + */
> +/*
> + * umwait.c adds control of user wait states that user enters through user 
> wait
> + * instructions umwait or tpause.

umwait.c adds something?

> + */
> +#include 
> +#include 
> +
> +static int umwait_disable_c0_2;
> +static DEFINE_MUTEX(umwait_lock);
> +
> +static ssize_t umwait_disable_c0_2_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%d\n", umwait_disable_c0_2);
> +}
> +
> +static ssize_t umwait_disable_c0_2_store(struct device *dev,
> +  struct device_attribute *attr,
> +  const char *buf, size_t count)
> +{
> + int disable_c0_2, cpu, ret;
> + u32 msr_val;
> +
> + ret = kstrtou32(buf, 10, &disable_c0_2);
> + if (ret)
> + return ret;
> + if (disable_c0_2 != 1 && disable_c0_2 != 0)
> + return -EINVAL;
> +
> + mutex_lock(&umwait_lock);
> + umwait_disable_c0_2 = disable_c0_2;
> + /*
> +  * No global umwait maximum time limit (0 in bits 31-0).
> +  * Enable or disable C0.2 based on global setting (bit 0) on all CPUs.
> +  */
> + msr_val = umwait_disable_c0_2 & UMWAIT_CONTROL_C02_MASK;

That mask is there because the variable can only have 0 and 1 as content

> + for_each_online_cpu(cpu)
> + wrmsr_on_cpu(cpu, MSR_IA32_UMWAIT_CONTROL, msr_val, 0);

This lacks protection against CPU hotplug.

> + mutex_unlock(&umwait_lock);
> +
> + return count;

Thanks,

tglx

Re: [PATCH v2 3/8] mfd: cros_ec: Add or fix SPDX-License-Identifier in all files.

2018-06-19 Thread Enric Balletbo i Serra

Hi Lee,

On 18/06/18 08:37, Lee Jones wrote:
> On Tue, 05 Jun 2018, Enric Balletbo i Serra wrote:
> 
>> And get rid of the license text that is no longer necessary. Also fix
>> the license as sometimes doesn't match what the header with the value in
>> the MODULE_LICENSE macro. Assuming that the desired license is GPL-2.0+,
>> all the files are updated to this license version.
>>
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v2: None
>>
>>  drivers/mfd/cros_ec.c| 26 --
>>  drivers/mfd/cros_ec_dev.c| 23 +--
>>  drivers/mfd/cros_ec_dev.h| 16 ++--
>>  drivers/mfd/cros_ec_i2c.c| 18 --
>>  drivers/mfd/cros_ec_spi.c| 20 +---
>>  include/linux/mfd/cros_ec.h  | 10 +-
>>  include/linux/mfd/cros_ec_commands.h | 10 +-
>>  include/linux/mfd/cros_ec_lpc_mec.h  | 14 +++---
>>  include/linux/mfd/cros_ec_lpc_reg.h  | 14 +++---
>>  9 files changed, 32 insertions(+), 119 deletions(-)
>>
>> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
>> index 58e05069163e..5b6a1c541543 100644
>> --- a/drivers/mfd/cros_ec.c
>> +++ b/drivers/mfd/cros_ec.c
>> @@ -1,21 +1,11 @@
>> -/*
>> - * ChromeOS EC multi-function device
>> - *
>> - * Copyright (C) 2012 Google, Inc
>> - *
>> - * This software is licensed under the terms of the GNU General Public
>> - * License version 2, as published by the Free Software Foundation, and
>> - * may be copied, distributed, and modified under those terms.
>> - *
>> - * This program is distributed in the hope that it will be useful,
>> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> - * GNU General Public License for more details.
>> - *
>> - * The ChromeOS EC multi function device is used to mux all the requests
>> - * to the EC device for its multiple features: keyboard controller,
>> - * battery charging and regulator control, firmware update.
>> - */
>> +// SPDX-License-Identifier: GPL-2.0+
>> +// ChromeOS EC multi-function device.
>> +//
>> +// Copyright (C) 2012 Google, Inc
>> +//
>> +// The ChromeOS EC multi function device is used to mux all the requests
>> +// to the EC device for its multiple features: keyboard controller,
>> +// battery charging and regulator control, firmware update.
> 
> I must admit I haven't seen a great many patches like this.  Is C++
> comments for the SPDX header *and* the Copyright text the done thing
> now then?
> 

There is a bit of mess here, as per documentation, it is clear that the SPDX tag
for .c files should go in C++ style, but for the copyright notice is not clear
and there are differences between subsystems.

Seems that putting everything as // is Linus Torvalds' preferred style [1] but
other maintainers want the copyright in c-style. If you see current status in
the kernel both styles are present.

[1] https://lkml.org/lkml/2017/11/25/133

Best regards,
 Enric

Re: [PATCH] serial: mps2-uart: Initialize early console

2018-06-19 Thread Vladimir Murzin

Hi Guenter,

On 19/06/18 05:54, Guenter Roeck wrote:
> The early console code for mps2-uart assumes that the serial hardware is
> enabled for transmit when the system boots. However, this is not the case
> after reset. This results in a hang in mps2_early_putchar() if the serial
> transmitter is not enabled by a boot loader or ROM monitor.

I was under impression that for earlycon there is an assumption/requirement
that the serial port must already be setup and configured. For instance, I 
see such requirement for pl011. So it looks like boot code's fault not to
enable serial (for mps2 it needs to setup BAUDDIV as well).

I'm not against the patch per se, but I'd like to hear if my understanding of
earlycon requirements is correct or not.

Cheers
Vladimir

> 
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/tty/serial/mps2-uart.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
> index 9f8f63719126..0743a0551ce1 100644
> --- a/drivers/tty/serial/mps2-uart.c
> +++ b/drivers/tty/serial/mps2-uart.c
> @@ -448,6 +448,14 @@ static struct console mps2_uart_console = {
>  
>  #define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
>  
> +static void mps2_early_init(struct uart_port *port)
> +{
> + u8 control = readb(port->membase + UARTn_CTRL);
> +
> + control |= UARTn_CTRL_TX_ENABLE;
> + writeb(control, port->membase + UARTn_CTRL);
> +}
> +
>  static void mps2_early_putchar(struct uart_port *port, int ch)
>  {
>   while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
> @@ -469,6 +477,7 @@ static int __init mps2_early_console_setup(struct 
> earlycon_device *device,
>   if (!device->port.membase)
>   return -ENODEV;
>  
> + mps2_early_init(&device->port);
>   device->con->write = mps2_early_write;
>  
>   return 0;
>

Re: [PATCH v3] mtd: rawnand: mxc: set spare area size register explicitly

2018-06-19 Thread Miquel Raynal

On Mon, 18 Jun 2018 22:41:03 +0200, Martin Kaiser 
wrote:

> The v21 version of the NAND flash controller contains a Spare Area Size
> Register (SPAS) at offset 0x10. Its setting defaults to the maximum
> spare area size of 218 bytes. The size that is set in this register is
> used by the controller when it calculates the ECC bytes internally in
> hardware.
> 
> Usually, this register is updated from settings in the IIM fuses when
> the system is booting from NAND flash. For other boot media, however,
> the SPAS register remains at the default setting, which may not work for
> the particular flash chip on the board. The same goes for flash chips
> whose configuration cannot be set in the IIM fuses (e.g. chips with 2k
> sector size and 128 bytes spare area size can't be configured in the IIM
> fuses on imx25 systems).
> 
> Set the SPAS register explicitly during the preset operation. Derive the
> register value from mtd->oobsize that was detected during probe by
> decoding the flash chip's ID bytes.
> 
> While at it, rename the define for the spare area register's offset to
> NFC_V21_RSLTSPARE_AREA. The register at offset 0x10 on v1 controllers is
> different from the register on v21 controllers.
> 
> Signed-off-by: Martin Kaiser 
> Cc: sta...@vger.kernel.org
> Fixes: d484018 ("mtd: mxc_nand: set NFC registers after reset")

Reviewed-by: Miquel Raynal 

Thanks,
Miquèl

Re: [RFC PATCH 5/8] x86/umwait.c: Add sysfs interface to show tsc_khz

On Fri, 15 Jun 2018, Fenghua Yu wrote:

> +static ssize_t tsc_khz_show(struct device *dev, struct device_attribute 
> *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%d\n", tsc_khz);
> +}
> +
>  static DEVICE_ATTR_RW(umwait_disable_c0_2);
> +static DEVICE_ATTR_RO(tsc_khz);

The right place to expose that information is the VDSO and a helper
function which allows to convert from nsec to TSC.

>  static struct attribute *umwait_attrs[] = {
>   &dev_attr_umwait_disable_c0_2.attr,
> @@ -92,6 +100,15 @@ static int __init umwait_init(void)
>   if (ret)
>   return ret;
>  
> + /* Only add the tsc_khz interface when the value is known. */

Why so? The only reason why you don't want to expose TSC frequency is when
it's not constant frequency.

> + if (boot_cpu_has(X86_FEATURE_TSC_KNOWN_FREQ)) {

Thanks,

tglx

Re: [RFC PATCH 7/8] x86/lib_user_wait.h: Add APIs for user wait instructions