Re: [PATCH 3/3] arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC

[Jisheng Zhang]

Hi Rob,

On Fri, 20 Jul 2018 09:21:17 -0600 Rob Herring wrote:

> On Fri, Jul 13, 2018 at 05:26:26PM +0800, Jisheng Zhang wrote:
> > Add initial dtsi file to support Synaptics AS370 SoC with quad
> > Cortex-A53 CPUs.
> > 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  arch/arm64/boot/dts/synaptics/as370.dtsi | 177 +++
> >  1 file changed, 177 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/synaptics/as370.dtsi 
> > b/arch/arm64/boot/dts/synaptics/as370.dtsi
> > new file mode 100644
> > index ..20f3d658c566
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/synaptics/as370.dtsi
> > @@ -0,0 +1,177 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright (C) 2018 Synaptics Incorporated
> > + *
> > + * Author: Jisheng Zhang 
> > + */
> > +
> > +#include 
> > +
> > +/ {
> > +   compatible = "syna,as370";
> > +   interrupt-parent = <>;
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   aliases {
> > +   serial0 =   
> 
> This normally goes in the board file. All boards will use this?

Yes. AFAIK, all boards will use uart0 as the serial console. But I could
move it to the board file.

> 
> > +   };
> > +
> > +   psci {
> > +   compatible = "arm,psci-1.0";
> > +   method = "smc";
> > +   };
> > +
> > +   cpus {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   cpu0: cpu@0 {
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   device_type = "cpu";
> > +   reg = <0x0>;
> > +   enable-method = "psci";
> > +   next-level-cache = <>;
> > +   cpu-idle-states = <_SLEEP_0>;
> > +   };
> > +
> > +   cpu1: cpu@1 {
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   device_type = "cpu";
> > +   reg = <0x1>;
> > +   enable-method = "psci";
> > +   next-level-cache = <>;
> > +   cpu-idle-states = <_SLEEP_0>;
> > +   };
> > +
> > +   cpu2: cpu@2 {
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   device_type = "cpu";
> > +   reg = <0x2>;
> > +   enable-method = "psci";
> > +   next-level-cache = <>;
> > +   cpu-idle-states = <_SLEEP_0>;
> > +   };
> > +
> > +   cpu3: cpu@3 {
> > +   compatible = "arm,cortex-a53", "arm,armv8";
> > +   device_type = "cpu";
> > +   reg = <0x3>;
> > +   enable-method = "psci";
> > +   next-level-cache = <>;
> > +   cpu-idle-states = <_SLEEP_0>;
> > +   };
> > +
> > +   l2: cache {
> > +   compatible = "cache";  
> 
> Why do you need this node? Doesn't define 

If the l2 node is missing, I will get below warning:

[1.364795] Unable to detect cache hierarchy for CPU 0

reported by drivers/base/cacheinfo.c


> 
> > +   };
> > +
> > +   idle-states {
> > +   entry-method = "psci";
> > +   CPU_SLEEP_0: cpu-sleep-0 {
> > +   compatible = "arm,idle-state";
> > +   local-timer-stop;
> > +   arm,psci-suspend-param = <0x001>;
> > +   entry-latency-us = <75>;
> > +   exit-latency-us = <155>;
> > +   min-residency-us = <1000>;
> > +   };
> > +   };
> > +   };
> > +
> > +   osc: osc {
> > +   compatible = "fixed-clock";
> > +   #clock-cells = <0>;
> > +   clock-frequency = <2500>;
> > +   };
> > +
> > +   pmu {
> > +   compatible = "arm,cortex-a53-pmu";
> > +   interrupts = ,
> > +,
> > +,
> > +;
> > +   interrupt-affinity = <>,
> > +<>,
> > +<>,
> > +<>;
> > +   };
> > +
> > +   timer {
> > +   compatible = "arm,armv8-timer";
> > +   interrupts =  > IRQ_TYPE_LEVEL_LOW)>,
> > + > IRQ_TYPE_LEVEL_LOW)>,
> > + > IRQ_TYPE_LEVEL_LOW)>,
> > + > IRQ_TYPE_LEVEL_LOW)>;
> > +   };
> > +
> > +   soc@f700 {
> > +   compatible = "simple-bus";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges = <0 0 0xf700 0x100>;
> > +
> > +   gic: interrupt-controller@901000 {
> > +   compatible = "arm,gic-400";
> > +   #interrupt-cells = <3>;
> > +   interrupt-controller;
> > +   reg = 

Re: Linux 4.18-rc6

[Martin Schwidefsky]

On Mon, 23 Jul 2018 16:17:22 -0700
Linus Torvalds  wrote:

> On Mon, Jul 23, 2018 at 2:23 PM Guenter Roeck  wrote:
> >  
> > >
> > > Martin - can we just remove the
> > >
> > >  select HAVE_GCC_PLUGINS
> > >
> > > from the s390 Kconfig file (or perhaps add "if BROKEN" or something to
> > > disable it).
> > >
> > > Because if it's not getting fixed, it shouldn't be exposed.
> > >  
> > The problem only affects 4.18 - the code has been rearranged in -next.
> > Only, in my builders, I can't disable a flag for individual releases,
> > so I just disabled it completely for s390.  
> 
> Well, I'm not going to release a 4.18 with a known problem, so in 4.18
> this *will* be disabled if it's not fixed.
> 
> The fact that it might be fixed in linux-next is entirely immaterial
> to the release of 4.18.

Ok, if gcc with the plugins and an allmodconfig is considered to be
important enough to warrant a fix, it can be pulled from here:

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

Martin Schwidefsky (1):
  s390: disable gcc plugins

Once that is in I will create another patch to undo this one and place
it after the early boot rework.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH v2 2/2] PCI: NVMe device specific reset quirk

[Christoph Hellwig]

> As all NVMe devices make use of this standard interface and the NVMe
> specification also requires PCIe FLR support, we can apply this quirk
> to all devices with matching class code.

But not all NVMe devices require this quirk.  So please only quirk
devices that actually require it.

Re: [PATCH v10 4/7] Bluetooth: hci_qca: Add wrapper functions for setting UART speed

[Balakrishna Godavarthi]

Hi Matthias,

On 2018-07-23 23:26, Matthias Kaehlcke wrote:

On Fri, Jul 20, 2018 at 07:02:40PM +0530, Balakrishna Godavarthi wrote:
In function qca_setup, we set initial and operating speeds for 
Qualcomm

Bluetooth SoC's. This block of code is common across different
Qualcomm Bluetooth SoC's. Instead of duplicating the code, created
a wrapper function to set the speeds. So that future coming SoC's
can use these wrapper functions to set speeds.

Signed-off-by: Balakrishna Godavarthi 
Reviewed-by: Matthias Kaehlcke 
---
 drivers/bluetooth/hci_qca.c | 93 
-

 1 file changed, 70 insertions(+), 23 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 5f1c0a8fd5cd..5f8a74d65bec 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -119,6 +119,11 @@ struct qca_data {
u64 votes_off;
 };

+enum qca_speed_type {
+   QCA_INIT_SPEED = 1,
+   QCA_OPER_SPEED
+};
+
 struct qca_serdev {
struct hci_uart  serdev_hu;
struct gpio_desc *bt_en;
@@ -923,6 +928,61 @@ static inline void host_set_baudrate(struct 
hci_uart *hu, unsigned int speed)

hci_uart_set_baudrate(hu, speed);
 }

+static unsigned int qca_get_speed(struct hci_uart *hu,
+ enum qca_speed_type speed_type)
+{
+   unsigned int speed = 0;
+
+   if (speed_type == QCA_INIT_SPEED) {
+   if (hu->init_speed)
+   speed = hu->init_speed;
+   else if (hu->proto->init_speed)
+   speed = hu->proto->init_speed;
+   } else {
+   if (hu->oper_speed)
+   speed = hu->oper_speed;
+   else if (hu->proto->oper_speed)
+   speed = hu->proto->oper_speed;
+   }
+
+   return speed;
+}
+
+static int qca_check_speeds(struct hci_uart *hu)
+{
+   if (!qca_get_speed(hu, QCA_INIT_SPEED) ||
+   !qca_get_speed(hu, QCA_OPER_SPEED))
+   return -EINVAL;


You changed this from:

/* One or the other speeds should be non zero. */
if (!qca_get_speed(hu, QCA_INIT_SPEED) &&
!qca_get_speed(hu, QCA_OPER_SPEED))
return -EINVAL;

There is no entry in the change log. What is the reason for this
change?


[Bala] : My bad i missed to add the log,as the above  if for ROME chip, 
having INIT or OPER speed is fine.


--
Regards
Balakrishna.

linux-next: Tree for Jul 24

[Stephen Rothwell]

Hi all,

Changes since 20180723:

Dropped trees: xarray, ida (complex conflicts)

The arm64 tree gained a conflict against Linus' tree.

The xarray tree still had its complex conflicts against the nvdimm tree
so I have dropped it again for today (along with the ida tree that is
built on top of it).

The akpm-current tree still had its build failure for which I reverted
a commit.

Non-merge commits (relative to Linus' tree): 7783
 7205 files changed, 37 insertions(+), 144333 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 65 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (d72e90f33aa4 Linux 4.18-rc6)
Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild)
Merging kbuild-current/fixes (9d3cce1e8b85 Linux 4.18-rc5)
Merging arc-current/for-curr (af1fc5baa724 ARCv2: [plat-hsdk]: Save accl reg 
pair by default)
Merging arm-current/fixes (b4c7e2bd2eb4 ARM: 8780/1: ftrace: Only set kernel 
memory back to read-only after boot)
Merging arm64-fixes/for-next/fixes (2fd8eb4ad871 arm64: neon: Fix function 
may_use_simd() return error status)
Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for 
platform devices)
Merging powerpc-fixes/fixes (b03897cf318d powerpc/powernv: Fix save/restore of 
SPRG3 on entry/exit from stop (idle))
Merging sparc/master (1aaccb5fa0ea Merge tag 'rtc-4.18' of 
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (1a4f14bab186 Merge branch 'tcp-robust-ooo')
Merging bpf/master (1a4f14bab186 Merge branch 'tcp-robust-ooo')
Merging ipsec/master (7284fdf39a91 esp6: fix memleak on error path in 
esp6_input)
Merging netfilter/master (6613b6173dee netfilter: conntrack: dccp: treat 
SYNC/SYNCACK as invalid if no prior state)
Merging ipvs/master (0026129c8629 rhashtable: add restart routine in 
rhashtable_free_and_destroy())
Merging wireless-drivers/master (248c690a2dc8 Merge tag 
'wireless-drivers-for-davem-2018-07-03' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers)
Merging mac80211/master (5cf3006cc81d nl80211: Add a missing break in 
parse_station_flags)
Merging rdma-fixes/for-rc (d63c46734c54 RDMA/mlx5: Fix memory leak in 
mlx5_ib_create_srq() error path)
Merging sound-current/for-linus (dfef01e15082 ALSA: memalloc: Don't exceed over 
the requested size)
Merging sound-asoc-fixes/for-linus (9357cbb5ae8a Merge branch 'asoc-4.18' into 
asoc-linus)
Merging regmap-fixes/for-linus (d72e90f33aa4 Linux 4.18-rc6)
Merging regulator-fixes/for-linus (34d50e73100f Merge branch 'regulator-4.18' 
into regulator-linus)
Merging spi-fixes/for-linus (f1e620ba2e79 Merge branch 'spi-4.18' into 
spi-linus)
Merging pci-current/for-linus (270ed733e689 PCI: v3-semi: Fix I/O space page 
leak)
Merging driver-core.current/driver-core-linus (722e5f2b1eec driver core: 
Partially revert "driver core: correct device's shutdown order")
Merging tty.current/tty-linus (021c91791a5e Linux 4.18-rc3)
Merging usb.current/usb-linus (249a32b7eeb3 usb: core: handle hub 
C_PORT_OVER_CURRENT condition)
Merging usb-gadget-fixes/fixes (eec24f2a0d4d usb: gadget: f_uac2: fix 
endianness of 'struct 

Re: [PATCH v2 2/4] i2c: imx: Fix race condition in dma read

[Uwe Kleine-König]

On Mon, Jul 09, 2018 at 11:43:02AM +0200, Esben Haabendal wrote:
> From: Esben Haabendal 
> 
> This fixes a race condition, where the DMAEN bit ends up being set after
> I2C slave has transmitted a byte following the dummy read.  When that
> happens, an interrupt is generated instead, and no DMA request is generated
> to kickstart the DMA read, and a timeout happens after DMA_TIMEOUT (1 sec).
> 
> Fixed by setting the DMAEN bit before the dummy read.
> 
> Signed-off-by: Esben Haabendal 
> ---
>  drivers/i2c/busses/i2c-imx.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 39cfd98c7b23..d86f152176a4 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -668,9 +668,6 @@ static int i2c_imx_dma_read(struct imx_i2c_struct 
> *i2c_imx,
>   struct imx_i2c_dma *dma = i2c_imx->dma;
>   struct device *dev = _imx->adapter.dev;
>  
> - temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> - temp |= I2CR_DMAEN;
> - imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
>  
>   dma->chan_using = dma->chan_rx;
>   dma->dma_transfer_dir = DMA_DEV_TO_MEM;
> @@ -810,6 +807,11 @@ static int i2c_imx_read(struct imx_i2c_struct *i2c_imx, 
> struct i2c_msg *msgs, bo
>   if ((msgs->len - 1) || block_data)
>   temp &= ~I2CR_TXAK;
>   imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> + if (i2c_imx->dma && msgs->len >= DMA_THRESHOLD && !block_data) {
> + temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> + temp |= I2CR_DMAEN;
> + imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> + }

Does this need to be a separate write to the I2CR register? Just before
the if there is temp written to this register, so probably this can be
changed to just:

if (i2c_imx->dma && msgs->len >= DMA_THRESHOLD && !block_data)
temp |= I2CR_DMAEN;

when moved before up one line.

I don't find documentation for the LS processors where this
register is described though (and the imx family doesn't seem to support
DMA for i2c).

Other than that this looks reasonable and warrants a

Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c 
driver")

.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re:Re: [PATCH RESEND] KVM: Add coalesced PIO support

[peng.hao2]

>>You've just stripped the authorship information and his/her
>>signed-off-by even from Cc!

>Will do in next version, I just help to make progress. 
I've tried to push the patch serveral times before but didn't make it and 
almost gave up .And Wanpeng told me that he wanted to make progress for the 
patch.I agreed.
After that, I was busy with my work without paying attention to the progress of 
this matter. There could be some mistake. Also thanks for Wanpeng's effort for 
the patch. 
>Regards,
>Wanpeng Li

Re: linux-next: build warning after merge of the arm64 tree

[Arnd Bergmann]

On Tue, Jul 24, 2018 at 2:26 AM, AKASHI Takahiro
 wrote:
> On Tue, Jul 24, 2018 at 09:05:45AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the arm64 tree, today's linux-next build (x86_64
>> allmodconfig) produced this warning:
>
> Where can I find this specific branch?
>
>> drivers/acpi/Kconfig:6:error: recursive dependency detected!
>> drivers/acpi/Kconfig:6:   symbol ACPI depends on EFI
>
> My patch created an additional dependency like:
>   menu ACPI
> ...
> depends on IA64 || X86 || (ARM64 && EFI)
>
>> arch/x86/Kconfig:1920:symbol EFI depends on ACPI
>
> So I don't understand why this change makes a warning on x86_64 build.
> Is this a real recursive dependency?

On x86, we have

config EFI
bool "EFI runtime service support"
depends on ACPI

Kconfig cannot know that CONFIG_ARM64 is never set on x86, while
X86 is always set. So to Kconfig it it appears like a recursive
dependency.

The best workaround I can see is to have an intermediate symbol
on ARM64 that is invisible to Kconfig on x86, like

config ARCH_SUPPORTS_ACPI
def_bool EFI

and then have ACPI depend on that.

   Arnd

Re: [PATCH RESEND] kthread, tracing: Don't expose half-written comm when creating kthreads

[Snild Dolkow]

On 07/23/2018 06:41 PM, Steven Rostedt wrote:
> On Mon, 23 Jul 2018 17:49:36 +0200
> Snild Dolkow  wrote:
>> Any issues with the commit message? Reading it back again now, it doesn't
>> seem quite as clear as when I wrote it.
> 
> Yeah, I think it does need some updates:
> 
>> There was a window for racing when task->comm was being written. The
> 
> It would be nice to explain this race window in more detail.
> 
I hope the following is more clear:

kthread, tracing: Don't expose half-written comm when creating kthreads

There is a window for racing when printing directly to task->comm,
allowing other threads to see a non-terminated string. The vsnprintf
function fills the buffer, counts the truncated chars, then finally
writes the \0 at the end.

creator other
vsnprintf:
  fill (not terminated)
  count the restread/use comm
  write \0

The consequences depend on how 'other' uses the string. In our case,
it was copied into the tracing system's saved cmdlines, a buffer of
adjacent TASK_COMM_LEN-byte buffers (note the 'n' where 0 should be):

crash-arm64> x/1024s savedcmd->saved_cmdlines | grep 'evenk'
0xffd5b3818640: "irq/497-pwr_evenkworker/u16:12"

...and a strcpy out of there would cause stack corruption:

[224761.522292] Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: ff9bf9783c78

crash-arm64> kbt | grep 'comm\|trace_print_context'
#6  0xff9bf9783c78 in trace_print_context+0x18c(+396)
  comm (char [16]) =  "irq/497-pwr_even"

crash-arm64> rd 0xffd4d0e17d14 8
ffd4d0e17d14:  2f717269 5f7277702d373934   irq/497-pwr_
ffd4d0e17d24:  726f776b6e657665 3a3631752f72656b   evenkworker/u16:
ffd4d0e17d34:  f9780248ff003231 cede60e0ff9b   12..H.x..`..
ffd4d0e17d44:  cede60c8ffd4 0fd4   .`..

The workaround in e09e28671 (use strlcpy in __trace_find_cmdline) was
likely needed because of this same bug.

Solved by vsnprintf:ing to a local buffer, then using set_task_comm().
This way, there won't be a window where comm is not terminated.


//Snild

[PATCH v1 08/15] drm/mediatek: add RGB color format support for RDMA

[Stu Hsieh]

This patch add RGB color format support for RDMA,
including RGB565, RGB888, RGBA and ARGB.

Signed-off-by: Stu Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 41 
 1 file changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 4ad0715c8341..5b7dadc21016 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -36,6 +36,8 @@
 #define DISP_REG_RDMA_SIZE_CON_0   0x0014
 #define DISP_REG_RDMA_SIZE_CON_1   0x0018
 #define DISP_REG_RDMA_TARGET_LINE  0x001c
+#define DISP_RDMA_MEM_CON  0x0024
+#define MEM_MODE_INPUT_SWAPBIT(8)
 #define DISP_RDMA_MEM_SRC_PITCH0x002c
 #define DISP_RDMA_MEM_GMC_SETTING_00x0030
 #define DISP_REG_RDMA_FIFO_CON 0x0040
@@ -48,6 +50,11 @@
 #define MATRIX_INT_MTX_SEL_DEFAULT 0xb0
 #define RDMA_MEM_GMC   0x40402020
 
+#define MEM_MODE_INPUT_FORMAT_RGB565   0x0
+#define MEM_MODE_INPUT_FORMAT_RGB888   (0x001 << 4)
+#define MEM_MODE_INPUT_FORMAT_RGBA (0x002 << 4)
+#define MEM_MODE_INPUT_FORMAT_ARGB (0x003 << 4)
+
 struct mtk_disp_rdma_data {
unsigned int fifo_size;
 };
@@ -156,16 +163,50 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
unsigned int width,
writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
 }
 
+static unsigned int rdma_fmt_convert(struct mtk_disp_rdma *rdma,
+unsigned int fmt)
+{
+   switch (fmt) {
+   default:
+   case DRM_FORMAT_RGB565:
+   return MEM_MODE_INPUT_FORMAT_RGB565;
+   case DRM_FORMAT_BGR565:
+   return MEM_MODE_INPUT_FORMAT_RGB565 | MEM_MODE_INPUT_SWAP;
+   case DRM_FORMAT_RGB888:
+   return MEM_MODE_INPUT_FORMAT_RGB888;
+   case DRM_FORMAT_BGR888:
+   return MEM_MODE_INPUT_FORMAT_RGB888 | MEM_MODE_INPUT_SWAP;
+   case DRM_FORMAT_RGBX:
+   case DRM_FORMAT_RGBA:
+   return MEM_MODE_INPUT_FORMAT_ARGB;
+   case DRM_FORMAT_BGRX:
+   case DRM_FORMAT_BGRA:
+   return MEM_MODE_INPUT_FORMAT_ARGB | MEM_MODE_INPUT_SWAP;
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   return MEM_MODE_INPUT_FORMAT_RGBA;
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ABGR:
+   return MEM_MODE_INPUT_FORMAT_RGBA | MEM_MODE_INPUT_SWAP;
+   }
+}
+
 static void mtk_rdma_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
  struct mtk_plane_state *state)
 {
+   struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
struct mtk_plane_pending_state *pending = >pending;
unsigned int addr = pending->addr;
unsigned int pitch = pending->pitch & 0x;
+   unsigned int fmt = pending->format;
+   unsigned int con;
 
if (pending->height == 0u || pending->width == 0u)
return;
 
+   con = rdma_fmt_convert(rdma, fmt);
+   writel_relaxed(con, comp->regs + DISP_RDMA_MEM_CON);
+
writel_relaxed(addr, comp->regs + DISP_RDMA_MEM_START_ADDR);
writel_relaxed(pitch, comp->regs + DISP_RDMA_MEM_SRC_PITCH);
writel(RDMA_MEM_GMC, comp->regs + DISP_RDMA_MEM_GMC_SETTING_0);
-- 
2.12.5

Re: [PATCH 1/4] sched/topology: SD_ASYM_CPUCAPACITY flag detection

[Morten Rasmussen]

On Mon, Jul 23, 2018 at 05:07:50PM +0100, Qais Yousef wrote:
> On 23/07/18 16:27, Morten Rasmussen wrote:
> >It does increase the cost of things like hotplug slightly and
> >repartitioning of root_domains a slightly but I don't see how we can
> >avoid it if we want generic code to set this flag. If the costs are not
> >acceptable I think the only option is to make the detection architecture
> >specific.
> 
> I think hotplug is already expensive and this overhead would be small in
> comparison. But this could be called when frequency changes if I understood
> correctly - this is the one I wasn't sure how 'hot' it could be. I wouldn't
> expect frequency changes at a very high rate because it's relatively
> expensive too..

A frequency change shouldn't lead to a flag change or a rebuild of the
sched_domain hierarhcy. The situations where the hierarchy should be
rebuild to update the flag is during boot as we only know the amount of
asymmetry once cpufreq has been initialized, when cpus are hotplugged
in/out, and when root_domains change due to cpuset reconfiguration. So
it should be a relatively rare event.

Re: [PATCH 2/2] cpufreq: Fix a circular lock dependency problem

[Rafael J. Wysocki]

On Mon, Jul 23, 2018 at 9:27 PM, Waiman Long  wrote:
> On 07/23/2018 03:16 PM, Peter Zijlstra wrote:
>> On Mon, Jul 23, 2018 at 01:49:39PM -0400, Waiman Long wrote:
>>>  drivers/cpufreq/cpufreq.c | 16 +++-
>>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>>> index b0dfd32..9cf02d7 100644
>>> --- a/drivers/cpufreq/cpufreq.c
>>> +++ b/drivers/cpufreq/cpufreq.c
>>> @@ -922,8 +922,22 @@ static ssize_t store(struct kobject *kobj, struct 
>>> attribute *attr,
>>>  struct cpufreq_policy *policy = to_policy(kobj);
>>>  struct freq_attr *fattr = to_attr(attr);
>>>  ssize_t ret = -EINVAL;
>>> +int retries = 3;
>>>
>>> -cpus_read_lock();
>>> +/*
>>> + * cpus_read_trylock() is used here to work around a circular lock
>>> + * dependency problem with respect to the cpufreq_register_driver().
>>> + * With a simple retry loop, the chance of not able to get the
>>> + * read lock is extremely small.
>>> + */
>>> +while (!cpus_read_trylock()) {
>>> +if (retries-- <= 0)
>>> +return -EBUSY;
>>> +/*
>>> + * Sleep for about 50ms and retry again.
>>> + */
>>> +msleep(50);
>>> +}
>> That's atrocious.
>>
>>
> I had thought about just returning an error if the trylock fails as CPU
> hotplug rarely happened. I can revert to that simple case if others have
> no objection.

Yes, you can return -EBUSY or -EAGAIN right away from here if the
cpus_read_trylock() is not successful.  There is not much reason for
the sysfs operation to continue in that case.

Re: linux-next: build warning after merge of the fsi tree

[Benjamin Herrenschmidt]

On Tue, 2018-07-24 at 16:03 +1000, Stephen Rothwell wrote:
> Hi Benjamin,
> 
> After merging the fsi tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:

Ah thanks. It's a pair of missing "z" qualifiers in those dev_dbg.

This normally won't show as this driver can only be enabled on 32-bit
ARM, but COMPILE_TEST will allow you to build it on x86_64 thus
triggering the warning.

I've pushed a fix in the fsi tree.

Greg, do you want a new signed tag with the fix or that can wait
for my next pull request ? I have a last bunch of chardev conversions
and object lifetime fixes being reviewed that I was thinking of sending
later this week.

Cheers,
Ben.

> 
> In file included from include/linux/printk.h:336:0,
>  from include/linux/kernel.h:14,
>  from include/linux/delay.h:22,
>  from drivers/fsi/fsi-master-ast-cf.c:8:
> drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_read':
> drivers/fsi/fsi-master-ast-cf.c:609:23: warning: format '%u' expects argument 
> of type 'unsigned int', but argument 6 has type 'size_t {aka long unsigned 
> int}' [-Wformat=]
>   dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
>^
> include/linux/dynamic_debug.h:135:39: note: in definition of macro 
> 'dynamic_dev_dbg'
>__dynamic_dev_dbg(, dev, fmt, \
>^~~
> include/linux/device.h:1428:23: note: in expansion of macro 'dev_fmt'
>   dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
>^~~
> drivers/fsi/fsi-master-ast-cf.c:609:2: note: in expansion of macro 'dev_dbg'
>   dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
>   ^~~
> drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_write':
> drivers/fsi/fsi-master-ast-cf.c:634:23: warning: format '%u' expects argument 
> of type 'unsigned int', but argument 6 has type 'size_t {aka long unsigned 
> int}' [-Wformat=]
>   dev_dbg(master->dev, "write id %d addr %x size %ud raw_data: %08x\n",
>^
> include/linux/dynamic_debug.h:135:39: note: in definition of macro 
> 'dynamic_dev_dbg'
>__dynamic_dev_dbg(, dev, fmt, \
>^~~
> include/linux/device.h:1428:23: note: in expansion of macro 'dev_fmt'
>   dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
>^~~
> drivers/fsi/fsi-master-ast-cf.c:634:2: note: in expansion of macro 'dev_dbg'
>   dev_dbg(master->dev, "write id %d addr %x size %ud raw_data: %08x\n",
>   ^~~
> 
> Introduced by commit
> 
>   6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed 
> ColdFire")
> 

Re: WARNING in port_delete

[Takashi Iwai]

On Tue, 24 Jul 2018 05:59:56 +0200,
DaeRyong Jeong wrote:
> 
> I just realized that the crash has been spotted by Syzkaller a few days 
> before.
> (https://syzkaller.appspot.com/bug?id=3490860a465e6b39227c6906f0ef2d40ad4d5bb1)
> 
> I'm CC'ing Syzkaller's mailing list.

It's very likely a false-positive sanity check, and if so, nothing
serious at all.  We may simply remove two snd_BUG_ON() lines.

But I'd love to have a C reproducer to confirm my understanding is
correct...


thanks,

Takashi

---
--- a/sound/core/seq/seq_ports.c
+++ b/sound/core/seq/seq_ports.c
@@ -272,9 +272,6 @@ static int port_delete(struct snd_seq_client *client,
if (port->private_free)
port->private_free(port->private_data);
 
-   snd_BUG_ON(port->c_src.count != 0);
-   snd_BUG_ON(port->c_dest.count != 0);
-
kfree(port);
return 0;
 }

[PATCH] m68k/mac: Rework patch "use time64_t in RTC handling"

[Finn Thain]

This addresses the issues arising from commit 324caa29cd04
("m68k: mac: use time64_t in RTC handling").

Adopt __u32 for the union in via_read_time(), consistent with changes
to via_write_time().

Use low_32_bits() in via_write_time(), consistent with changes to
pmu_write_time() and cuda_write_time().

Have via_read_time() return a time64_t, consistent with changes to
pmu_read_time and cuda_read_time().

Drop the pointless wraparound conditional in via_read_time().

Cc: Arnd Bergmann 
Signed-off-by: Finn Thain 
---
 arch/m68k/mac/misc.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
index bdc83eac6c61..19e9d8eef1f2 100644
--- a/arch/m68k/mac/misc.c
+++ b/arch/m68k/mac/misc.c
@@ -251,11 +251,11 @@ static void via_write_pram(int offset, __u8 data)
  * is basically any machine with Mac II-style ADB.
  */
 
-static long via_read_time(void)
+static time64_t via_read_time(void)
 {
union {
__u8 cdata[4];
-   long idata;
+   __u32 idata;
} result, last_result;
int count = 1;
 
@@ -275,12 +275,8 @@ static long via_read_time(void)
via_pram_command(0x89, [1]);
via_pram_command(0x8D, [0]);
 
-   if (result.idata == last_result.idata) {
-   if (result.idata < RTC_OFFSET)
-   result.idata += 0x1ull;
-
-   return result.idata - RTC_OFFSET;
-   }
+   if (result.idata == last_result.idata)
+   return (time64_t)result.idata - RTC_OFFSET;
 
if (++count > 10)
break;
@@ -288,8 +284,8 @@ static long via_read_time(void)
last_result.idata = result.idata;
}
 
-   pr_err("via_read_time: failed to read a stable value; got 0x%08lx then 
0x%08lx\n",
-  last_result.idata, result.idata);
+   pr_err("%s: failed to read a stable value; got 0x%08x then 0x%08x\n",
+  __func__, last_result.idata, result.idata);
 
return 0;
 }
@@ -314,7 +310,7 @@ static void via_write_time(time64_t time)
temp = 0x55;
via_pram_command(0x35, );
 
-   data.idata = time + RTC_OFFSET;
+   data.idata = lower_32_bits(time + RTC_OFFSET);
via_pram_command(0x01, [3]);
via_pram_command(0x05, [2]);
via_pram_command(0x09, [1]);
-- 
2.16.4

Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps

[Michal Hocko]

On Mon 23-07-18 19:20:43, David Hildenbrand wrote:
> On 23.07.2018 14:30, Michal Hocko wrote:
> > On Mon 23-07-18 13:45:18, Vlastimil Babka wrote:
> >> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
> >>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
> >>> So reserved pages might be access by dump tools although nobody except
> >>> the owner should touch them.
> >>
> >> Are you sure about that? Or maybe I understand wrong. Maybe it changed
> >> recently, but IIRC pages that are backing memmap (struct pages) are also
> >> PG_reserved. And you definitely do want those in the dump.
> > 
> > You are right. reserve_bootmem_region will make all early bootmem
> > allocations (including those backing memmaps) PageReserved. I have asked
> > several times but I haven't seen a satisfactory answer yet. Why do we
> > even care for kdump about those. If they are reserved the nobody should
> > really look at those specific struct pages and manipulate them. Kdump
> > tools are using a kernel interface to read the content. If the specific
> > content is backed by a non-existing memory then they should simply not
> > return anything.
> > 
> 
> "new kernel" provides an interface to read memory from "old kernel".
> 
> The new kernel has no idea about
> - which memory was added/online in the old kernel
> - where struct pages of the old kernel are and what their content is
> - which memory is save to touch and which not
> 
> Dump tools figure all that out by interpreting the VMCORE. They e.g.
> identify "struct pages" and see if they should be dumped. The "new
> kernel" only allows to read that memory. It cannot hinder to crash the
> system (e.g. if a dump tool would try to read a hwpoison page).
> 
> So how should the "new kernel" know if a page can be touched or not?

I am sorry I am not familiar with kdump much. But from what I remember
it reads from /proc/vmcore and implementation of this interface should
simply return EINVAL or alike when you try to dump inaccessible memory
range.
 
> The *only* way would be to have an interface to the hypervisor where we
> "sense" if a memory location is safe to touch. I remember that xen or
> hyper-v does that - they fake a zero page in that case, after querying
> the hypervisor. But this does not sound like a clean approach to me,
> especially es we need yet another hypervisor interface to sense for
> memory provided via "some" device.
> 
> If we can find a way to just tag pages as "don't touch", it would be the
> easiest and cleanest solution in my opinion.

If only we could have much more spare room in struct pages...
-- 
Michal Hocko
SUSE Labs

general protection fault in cpuacct_charge

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:8ae71e76cf1f Merge branch 'bpf-offload-sharing'
git tree:   bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1645f97840
kernel config:  https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
dashboard link: https://syzkaller.appspot.com/bug?extid=a22ee0b9ff4d252439f4
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

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

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
CPU: 1 PID: 0 Comm: �G+�
���0x�� Not tainted 4.18.0-rc3+ #58
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:task_css include/linux/cgroup.h:477 [inline]
RIP: 0010:task_ca kernel/sched/cpuacct.c:43 [inline]
RIP: 0010:cpuacct_charge+0x1b8/0x5d0 kernel/sched/cpuacct.c:349
Code: 68 ff ff ff 85 c0 74 0d 80 3d 45 31 3c 08 00 0f 84 04 02 00 00 48 b8  
00 00 00 00 00 fc ff df 49 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f  
85 65 03 00 00 4d 8b 65 10 4d 85 e4 0f 84 0a 01 00

RSP: 0018:8801daf072b0 EFLAGS: 00010006
RAX: dc00 RBX: 8801c72b40c0 RCX: 
RDX: 09f3 RSI: 8801 RDI: 4f99
RBP: 8801daf07348 R08:  R09: 
R10: 780baf52484d R11:  R12: 11003b5e0e5c
R13: 4f89 R14: dc00 R15: 11003b5e0e58
FS:  7f4ba8413700() GS:8801daf0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2340 CR3: 0001cf0ac000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 
 cgroup_account_cputime include/linux/cgroup.h:724 [inline]
 update_curr+0x389/0xc00 kernel/sched/fair.c:832
 enqueue_entity+0x40d/0x2130 kernel/sched/fair.c:4195
 enqueue_task_fair+0x22d/0x910 kernel/sched/fair.c:5408
 enqueue_task kernel/sched/core.c:751 [inline]
 activate_task+0x123/0x2e0 kernel/sched/core.c:770
 ttwu_activate kernel/sched/core.c:1659 [inline]
 ttwu_do_activate+0xd5/0x1f0 kernel/sched/core.c:1718
 ttwu_queue kernel/sched/core.c:1863 [inline]
 try_to_wake_up+0x948/0x12b0 kernel/sched/core.c:2076
 wake_up_process+0x10/0x20 kernel/sched/core.c:2149
 hrtimer_wakeup+0x48/0x60 kernel/time/hrtimer.c:1647
 __run_hrtimer kernel/time/hrtimer.c:1398 [inline]
 __hrtimer_run_queues+0x3eb/0x10c0 kernel/time/hrtimer.c:1460
 hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
 smp_apic_timer_interrupt+0x165/0x730 arch/x86/kernel/apic/apic.c:1050
 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
 
Modules linked in:
Dumping ftrace buffer:
   (ftrace buffer empty)
---[ end trace 63a513d0f55cc290 ]---
RIP: 0010:task_css include/linux/cgroup.h:477 [inline]
RIP: 0010:task_ca kernel/sched/cpuacct.c:43 [inline]
RIP: 0010:cpuacct_charge+0x1b8/0x5d0 kernel/sched/cpuacct.c:349
Code: 68 ff ff ff 85 c0 74 0d 80 3d 45 31 3c 08 00 0f 84 04 02 00 00 48 b8  
00 00 00 00 00 fc ff df 49 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f  
85 65 03 00 00 4d 8b 65 10 4d 85 e4 0f 84 0a 01 00

RSP: 0018:8801daf072b0 EFLAGS: 00010006
RAX: dc00 RBX: 8801c72b40c0 RCX: 
RDX: 09f3 RSI: 8801 RDI: 4f99
RBP: 8801daf07348 R08:  R09: 
R10: 780baf52484d R11:  R12: 11003b5e0e5c
R13: 4f89 R14: dc00 R15: 11003b5e0e58
FS:  7f4ba8413700() GS:8801daf0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2340 CR3: 0001cf0ac000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

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

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven 
---
To be merged with "m68k/defconfig: Update defconfigs for v4.18-rc1"
---
 arch/m68k/configs/amiga_defconfig| 4 +---
 arch/m68k/configs/apollo_defconfig   | 4 +---
 arch/m68k/configs/atari_defconfig| 4 +---
 arch/m68k/configs/bvme6000_defconfig | 4 +---
 arch/m68k/configs/hp300_defconfig| 4 +---
 arch/m68k/configs/mac_defconfig  | 4 +---
 arch/m68k/configs/multi_defconfig| 4 +---
 arch/m68k/configs/mvme147_defconfig  | 4 +---
 arch/m68k/configs/mvme16x_defconfig  | 4 +---
 arch/m68k/configs/q40_defconfig  | 4 +---
 arch/m68k/configs/sun3_defconfig | 4 +---
 arch/m68k/configs/sun3x_defconfig| 4 +---
 12 files changed, 12 insertions(+), 36 deletions(-)

diff --git a/arch/m68k/configs/amiga_defconfig 
b/arch/m68k/configs/amiga_defconfig
index 6c4ba2cc94ddb14f..1d5483f6e457b0a0 100644
--- a/arch/m68k/configs/amiga_defconfig
+++ b/arch/m68k/configs/amiga_defconfig
@@ -99,14 +99,12 @@ CONFIG_NF_CONNTRACK_SANE=m
 CONFIG_NF_CONNTRACK_SIP=m
 CONFIG_NF_CONNTRACK_TFTP=m
 CONFIG_NF_TABLES=m
+CONFIG_NF_TABLES_SET=m
 CONFIG_NF_TABLES_INET=y
 CONFIG_NF_TABLES_NETDEV=y
 CONFIG_NFT_NUMGEN=m
 CONFIG_NFT_CT=m
 CONFIG_NFT_FLOW_OFFLOAD=m
-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
diff --git a/arch/m68k/configs/apollo_defconfig 
b/arch/m68k/configs/apollo_defconfig
index b8b40042d8516a32..52a0af127951f5f0 100644
--- a/arch/m68k/configs/apollo_defconfig
+++ b/arch/m68k/configs/apollo_defconfig
@@ -97,14 +97,12 @@ CONFIG_NF_CONNTRACK_SANE=m
 CONFIG_NF_CONNTRACK_SIP=m
 CONFIG_NF_CONNTRACK_TFTP=m
 CONFIG_NF_TABLES=m
+CONFIG_NF_TABLES_SET=m
 CONFIG_NF_TABLES_INET=y
 CONFIG_NF_TABLES_NETDEV=y
 CONFIG_NFT_NUMGEN=m
 CONFIG_NFT_CT=m
 CONFIG_NFT_FLOW_OFFLOAD=m
-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
diff --git a/arch/m68k/configs/atari_defconfig 
b/arch/m68k/configs/atari_defconfig
index 2de40b307a0ba624..b9473c6e7dbaaf5e 100644
--- a/arch/m68k/configs/atari_defconfig
+++ b/arch/m68k/configs/atari_defconfig
@@ -97,14 +97,12 @@ CONFIG_NF_CONNTRACK_SANE=m
 CONFIG_NF_CONNTRACK_SIP=m
 CONFIG_NF_CONNTRACK_TFTP=m
 CONFIG_NF_TABLES=m
+CONFIG_NF_TABLES_SET=m
 CONFIG_NF_TABLES_INET=y
 CONFIG_NF_TABLES_NETDEV=y
 CONFIG_NFT_NUMGEN=m
 CONFIG_NFT_CT=m
 CONFIG_NFT_FLOW_OFFLOAD=m
-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
diff --git a/arch/m68k/configs/bvme6000_defconfig 
b/arch/m68k/configs/bvme6000_defconfig
index dc9163eb49170f3e..fb7d651a4cabe203 100644
--- a/arch/m68k/configs/bvme6000_defconfig
+++ b/arch/m68k/configs/bvme6000_defconfig
@@ -95,14 +95,12 @@ CONFIG_NF_CONNTRACK_SANE=m
 CONFIG_NF_CONNTRACK_SIP=m
 CONFIG_NF_CONNTRACK_TFTP=m
 CONFIG_NF_TABLES=m
+CONFIG_NF_TABLES_SET=m
 CONFIG_NF_TABLES_INET=y
 CONFIG_NF_TABLES_NETDEV=y
 CONFIG_NFT_NUMGEN=m
 CONFIG_NFT_CT=m
 CONFIG_NFT_FLOW_OFFLOAD=m
-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
diff --git a/arch/m68k/configs/hp300_defconfig 
b/arch/m68k/configs/hp300_defconfig
index 24685d6021e777d1..6b37f5537c3905c5 100644
--- a/arch/m68k/configs/hp300_defconfig
+++ b/arch/m68k/configs/hp300_defconfig
@@ -97,14 +97,12 @@ CONFIG_NF_CONNTRACK_SANE=m
 CONFIG_NF_CONNTRACK_SIP=m
 CONFIG_NF_CONNTRACK_TFTP=m
 CONFIG_NF_TABLES=m
+CONFIG_NF_TABLES_SET=m
 CONFIG_NF_TABLES_INET=y
 CONFIG_NF_TABLES_NETDEV=y
 CONFIG_NFT_NUMGEN=m
 CONFIG_NFT_CT=m
 CONFIG_NFT_FLOW_OFFLOAD=m
-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
diff --git a/arch/m68k/configs/mac_defconfig b/arch/m68k/configs/mac_defconfig
index 9175d9a705545b3e..c717bf8794492114 100644
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -96,14 +96,12 @@ CONFIG_NF_CONNTRACK_SANE=m
 CONFIG_NF_CONNTRACK_SIP=m
 CONFIG_NF_CONNTRACK_TFTP=m
 CONFIG_NF_TABLES=m
+CONFIG_NF_TABLES_SET=m
 CONFIG_NF_TABLES_INET=y
 CONFIG_NF_TABLES_NETDEV=y
 CONFIG_NFT_NUMGEN=m
 CONFIG_NFT_CT=m
 CONFIG_NFT_FLOW_OFFLOAD=m
-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
diff --git a/arch/m68k/configs/multi_defconfig 
b/arch/m68k/configs/multi_defconfig
index 90d40974d6482d7a..226c994ce794f6ac 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -106,14 +106,12 @@ CONFIG_NF_CONNTRACK_SANE=m
 CONFIG_NF_CONNTRACK_SIP=m
 CONFIG_NF_CONNTRACK_TFTP=m
 CONFIG_NF_TABLES=m
+CONFIG_NF_TABLES_SET=m
 CONFIG_NF_TABLES_INET=y
 CONFIG_NF_TABLES_NETDEV=y
 CONFIG_NFT_NUMGEN=m
 CONFIG_NFT_CT=m
 CONFIG_NFT_FLOW_OFFLOAD=m
-CONFIG_NFT_SET_RBTREE=m
-CONFIG_NFT_SET_HASH=m
-CONFIG_NFT_SET_BITMAP=m
 CONFIG_NFT_COUNTER=m
 

Re: [PATCH v2 3/4] i2c: imx: Simplify stopped state tracking

[Uwe Kleine-König]

On Mon, Jul 09, 2018 at 11:43:03AM +0200, Esben Haabendal wrote:
> From: Esben Haabendal 
> 
> Always update the stopped state when busy status have been checked.
> This is identical to what was done before, with the exception of error
> handling.
> Without this change, some errors cause the stopped state to be left in
> incorrect state in i2c_imx_stop(), i2c_imx_dma_read(), i2c_imx_read() and
> i2c_imx_xfer().
> 
> Signed-off-by: Esben Haabendal 
> ---
>  drivers/i2c/busses/i2c-imx.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index d86f152176a4..1db8e6790afc 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -421,10 +421,14 @@ static int i2c_imx_bus_busy(struct imx_i2c_struct 
> *i2c_imx, int for_busy)
>   return -EAGAIN;
>   }
>  
> - if (for_busy && (temp & I2SR_IBB))
> + if (for_busy && (temp & I2SR_IBB)) {
> + i2c_imx->stopped = 0;
>   break;
> - if (!for_busy && !(temp & I2SR_IBB))
> + }
> + if (!for_busy && !(temp & I2SR_IBB)) {
> + i2c_imx->stopped = 1;
>   break;
> + }

Would it make sense to assign to ->stopped independent of for_busy?

>   if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
>   dev_dbg(_imx->adapter.dev,
>   "<%s> I2C bus is busy\n", __func__);
> @@ -538,7 +542,6 @@ static int i2c_imx_start(struct imx_i2c_struct *i2c_imx)
>   result = i2c_imx_bus_busy(i2c_imx, 1);
>   if (result)
>   return result;
> - i2c_imx->stopped = 0;
>  
>   temp |= I2CR_IIEN | I2CR_MTX | I2CR_TXAK;
>   temp &= ~I2CR_DMAEN;
> @@ -569,7 +572,6 @@ static void i2c_imx_stop(struct imx_i2c_struct *i2c_imx)
>  
>   if (!i2c_imx->stopped) {
>   i2c_imx_bus_busy(i2c_imx, 0);
> - i2c_imx->stopped = 1;
>   }

The braces can go away here.
>  
>   /* Disable I2C controller */

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH 2/2] cpufreq: Fix a circular lock dependency problem

[Rafael J. Wysocki]

On Mon, Jul 23, 2018 at 9:16 PM, Peter Zijlstra  wrote:
> On Mon, Jul 23, 2018 at 01:49:39PM -0400, Waiman Long wrote:
>>  drivers/cpufreq/cpufreq.c | 16 +++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index b0dfd32..9cf02d7 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -922,8 +922,22 @@ static ssize_t store(struct kobject *kobj, struct 
>> attribute *attr,
>>   struct cpufreq_policy *policy = to_policy(kobj);
>>   struct freq_attr *fattr = to_attr(attr);
>>   ssize_t ret = -EINVAL;
>> + int retries = 3;
>>
>> - cpus_read_lock();
>> + /*
>> +  * cpus_read_trylock() is used here to work around a circular lock
>> +  * dependency problem with respect to the cpufreq_register_driver().
>> +  * With a simple retry loop, the chance of not able to get the
>> +  * read lock is extremely small.
>> +  */
>> + while (!cpus_read_trylock()) {
>> + if (retries-- <= 0)
>> + return -EBUSY;
>> + /*
>> +  * Sleep for about 50ms and retry again.
>> +  */
>> + msleep(50);
>> + }
>
> That's atrocious.

Agreed.

Re: [PATCH v4 1/4] x86/boot: Add acpitb.h to help parse acpi tables

[Baoquan He]

Hi chao,

On 07/23/18 at 05:29pm, Chao Fan wrote:
> In order to parse ACPI tables, reuse the head file linux/acpi.h,
> so that the files in 'compressed' directory can read ACPI table
> by including this head file.
> 
> Signed-off-by: Chao Fan 
> ---
>  arch/x86/boot/compressed/acpitb.h | 7 +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 arch/x86/boot/compressed/acpitb.h
> 
> diff --git a/arch/x86/boot/compressed/acpitb.h 
> b/arch/x86/boot/compressed/acpitb.h
> new file mode 100644
> index ..f8ab6e5b3e06
> --- /dev/null
> +++ b/arch/x86/boot/compressed/acpitb.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#include 
> +
> +#define ACPI_MAX_TABLES128
> +
> +/* Function to get ACPI SRAT table pointer. */
> +struct acpi_table_header *get_acpi_srat_table(void);

Since acpitb.h includes so few lines of code, not sure if we can move
them into .c files directly.

By the way, you might need to rebase this patchset on top of
tip/x86/boot.

Thanks
Baoquan

linux-next: build warning after merge of the fsi tree

[Stephen Rothwell]

Hi Benjamin,

After merging the fsi tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:

In file included from include/linux/printk.h:336:0,
 from include/linux/kernel.h:14,
 from include/linux/delay.h:22,
 from drivers/fsi/fsi-master-ast-cf.c:8:
drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_read':
drivers/fsi/fsi-master-ast-cf.c:609:23: warning: format '%u' expects argument 
of type 'unsigned int', but argument 6 has type 'size_t {aka long unsigned 
int}' [-Wformat=]
  dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
   ^
include/linux/dynamic_debug.h:135:39: note: in definition of macro 
'dynamic_dev_dbg'
   __dynamic_dev_dbg(, dev, fmt, \
   ^~~
include/linux/device.h:1428:23: note: in expansion of macro 'dev_fmt'
  dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
   ^~~
drivers/fsi/fsi-master-ast-cf.c:609:2: note: in expansion of macro 'dev_dbg'
  dev_dbg(master->dev, "read id %d addr %x size %ud\n", id, addr, size);
  ^~~
drivers/fsi/fsi-master-ast-cf.c: In function 'fsi_master_acf_write':
drivers/fsi/fsi-master-ast-cf.c:634:23: warning: format '%u' expects argument 
of type 'unsigned int', but argument 6 has type 'size_t {aka long unsigned 
int}' [-Wformat=]
  dev_dbg(master->dev, "write id %d addr %x size %ud raw_data: %08x\n",
   ^
include/linux/dynamic_debug.h:135:39: note: in definition of macro 
'dynamic_dev_dbg'
   __dynamic_dev_dbg(, dev, fmt, \
   ^~~
include/linux/device.h:1428:23: note: in expansion of macro 'dev_fmt'
  dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
   ^~~
drivers/fsi/fsi-master-ast-cf.c:634:2: note: in expansion of macro 'dev_dbg'
  dev_dbg(master->dev, "write id %d addr %x size %ud raw_data: %08x\n",
  ^~~

Introduced by commit

  6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire")

-- 
Cheers,
Stephen Rothwell


pgpIJ1N0jI0j9.pgp
Description: OpenPGP digital signature

[PATCH] perf c2c report: Fix crash for empty browser

[Jiri Olsa]

Do not try to display entry details if there's
not any. Currently this ends up in crash:
  $ perf c2c report
  perf: Segmentation fault

Reported-by: ro...@autistici.org
Link: http://lkml.kernel.org/n/tip-3d7qjz9x49ay9ncerford...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/builtin-c2c.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index f2ea85ee573f..f3aa9d02a5ab 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -2349,6 +2349,9 @@ static int perf_c2c__browse_cacheline(struct hist_entry 
*he)
" s Toggle full length of symbol and source line columns \n"
" q Return back to cacheline list \n";
 
+   if (!he)
+   return 0;
+
/* Display compact version first. */
c2c.symbol_full = false;
 
-- 
2.17.1

Re: [PATCH] stop_machine: Disable preemption after queueing stopper threads

[Sebastian Andrzej Siewior]

On 2018-07-23 18:13:48 [-0700], isa...@codeaurora.org wrote:
> Hi all,
Hi,

> Are there any comments about this patch?

I haven't look in detail at this but your new preempt_disable() makes
things unbalanced for the err != 0 case.

> Thanks,
> Isaac Manjarres

Sebastian

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

[Minchan Kim]

On Tue, Jul 24, 2018 at 11:53:30AM +0900, Sergey Senozhatsky wrote:
> On (07/24/18 10:03), Minchan Kim wrote:
> > On Mon, Jul 23, 2018 at 02:29:32PM +0200, Tino Lehnig wrote:
> > > Hello,
> > > 
> > > after enabling the writeback feature in zram, I encountered the kernel bug
> > > below with heavy swap utilization. There is one specific workload that
> > > triggers the bug reliably and that is running Windows in KVM while
> > > overcommitting memory. The Windows VMs would fill all allocated memory 
> > > with
> > > zero pages while booting. A few seconds after the host hits zram swap, the
> > > console on the host is flooded with the bug message. A few more seconds
> > > later I also encountered filesystem errors on the host causing the root
> > > filesystem to be mounted read-only. The filesystem errors do not occur 
> > > when
> > > leaving RAM available for the host OS by limiting physical memory of the
> > > QEMU processes via cgroups.
> > > 
> > > I started three KVM instances with the following commands in my tests. Any
> > > Windows ISO or disk image can be used. Less instances and smaller 
> > > allocated
> > > memory will also trigger the bug as long as swapping occurs. The type of
> > > writeback device does not seem to matter. I have tried a SATA SSD and an
> > > NVMe Optane drive so far. My test machine has 256 GB of RAM and one CPU. I
> > > saw the same behavior on another machine with two CPUs and 128 GB of RAM.
> > > 
> > > The bug does not occur when using zram as swap without "backing_dev" being
> > > set, but I had even more severe problems when running the same test on
> > > Ubuntu Kernels 4.15 and 4.17. Regardless of the writeback feature being 
> > > used
> > > or not, the host would eventually lock up entirely when swap is in use on
> > > zram. The lockups may not be related directly to zram though and were
> > > apparently fixed in 4.18. I had absolutely no problems on Ubuntu Kernel 
> > > 4.13
> > > either, before the writeback feature was introduced.
> > 
> > We didn't release v4.18 yet. Could you say what kernel tree/what version
> > you used?
> > 
> > Now I don't have enough time to dig in.
> > 
> > Sergey, I really appreciate if you could have availabe time to look into.
> > Anyway, I could try to see it asap if Sergey is not available.
> > No worry.
> 
> Interesting case.
> 
> Will take me several days to get to it.
> Sorry, quite busy at the moment.

I look though v4.18-rcX very quick what are changed for zsmalloc.
struct page fields were totally reordered. It could be a regression related to
that. Ccing Matthew

Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps

[Michal Hocko]

On Mon 23-07-18 19:12:58, David Hildenbrand wrote:
> On 23.07.2018 13:45, Vlastimil Babka wrote:
> > On 07/20/2018 02:34 PM, David Hildenbrand wrote:
> >> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
> >> So reserved pages might be access by dump tools although nobody except
> >> the owner should touch them.
> > 
> > Are you sure about that? Or maybe I understand wrong. Maybe it changed
> > recently, but IIRC pages that are backing memmap (struct pages) are also
> > PG_reserved. And you definitely do want those in the dump.
> 
> I proposed a new flag/value to mask pages that are logically offline but
> Michal wanted me to go into this direction.
> 
> While we can special case struct pages in dump tools ("we have to
> read/interpret them either way, so we can also dump them"), it smells
> like my original attempt was cleaner. Michal?

But we do not have many page flags spare and even if we have one or two
this doesn't look like the use for them. So I still think we should try
the PageReserved way.

-- 
Michal Hocko
SUSE Labs

Re: WARNING in port_delete

[Takashi Iwai]

On Tue, 24 Jul 2018 09:14:14 +0200,
DaeRyong Jeong wrote:
> 
> I agree with that having a C reproducer would be much better.
> Now I'm working on it.
> I will immediately let you know once I get the C reproducer.

That's great, thanks!


Takashi

> 
> 
> Thank you.
> 
> Best regards,
> DaeRyong Jeong
> On 24 Jul 2018, 4:00 PM +0900, Takashi Iwai , wrote:
> > On Tue, 24 Jul 2018 05:59:56 +0200,
> > DaeRyong Jeong wrote:
> > >
> > > I just realized that the crash has been spotted by Syzkaller a few days 
> > > before.
> > > (https://syzkaller.appspot.com/bug?id=3490860a465e6b39227c6906f0ef2d40ad4d5bb1)
> > >
> > > I'm CC'ing Syzkaller's mailing list.
> >
> > It's very likely a false-positive sanity check, and if so, nothing
> > serious at all. We may simply remove two snd_BUG_ON() lines.
> >
> > But I'd love to have a C reproducer to confirm my understanding is
> > correct...
> >
> >
> > thanks,
> >
> > Takashi
> >
> > ---
> > --- a/sound/core/seq/seq_ports.c
> > +++ b/sound/core/seq/seq_ports.c
> > @@ -272,9 +272,6 @@ static int port_delete(struct snd_seq_client *client,
> > if (port->private_free)
> > port->private_free(port->private_data);
> >
> > - snd_BUG_ON(port->c_src.count != 0);
> > - snd_BUG_ON(port->c_dest.count != 0);
> > -
> > kfree(port);
> > return 0;
> > }
> [2  ]
> 

Re: Linux 4.18-rc6

[Martin Schwidefsky]

On Tue, 24 Jul 2018 09:15:58 +0200
Christian Borntraeger  wrote:

> On 07/24/2018 08:18 AM, Martin Schwidefsky wrote:
> > On Mon, 23 Jul 2018 16:17:22 -0700
> > Linus Torvalds  wrote:
> >   
> >> On Mon, Jul 23, 2018 at 2:23 PM Guenter Roeck  wrote:  
> >>>
> 
>  Martin - can we just remove the
> 
>   select HAVE_GCC_PLUGINS
> 
>  from the s390 Kconfig file (or perhaps add "if BROKEN" or something to
>  disable it).
> 
>  Because if it's not getting fixed, it shouldn't be exposed.
> 
> >>> The problem only affects 4.18 - the code has been rearranged in -next.
> >>> Only, in my builders, I can't disable a flag for individual releases,
> >>> so I just disabled it completely for s390.
> >>
> >> Well, I'm not going to release a 4.18 with a known problem, so in 4.18
> >> this *will* be disabled if it's not fixed.
> >>
> >> The fact that it might be fixed in linux-next is entirely immaterial
> >> to the release of 4.18.  
> > 
> > Ok, if gcc with the plugins and an allmodconfig is considered to be
> > important enough to warrant a fix, it can be pulled from here:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
> > 
> > Martin Schwidefsky (1):
> >   s390: disable gcc plugins
> > 
> > Once that is in I will create another patch to undo this one and place
> > it after the early boot rework.  
> 
> On the list a different fix was proposed about 2 weeks ago,
> 
> something like
> 
> CFLAGS_als.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
> 
> and I prefer that. Because your patch disables all gcc plugins.

This change would cause trouble with patch dependencies as als.c is moved
to a different directory. I would prefer to disable all gcc plugins for
4.18.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: Zram writeback feature unstable with heavy swap utilization - BUG: Bad page state in process...

[Tino Lehnig]

Hi,

The first build I used was from the master branch of the mainline 
kernel, somewhere between rc5 and rc6. I have just reproduced the bug 
with 4.17.9 and 4.18-rc6. Kernel messages below.


The bug does not appear on 4.14.57. I can test more versions if it helps.

On 07/24/2018 03:03 AM, Minchan Kim wrote:

We didn't release v4.18 yet. Could you say what kernel tree/what version
you used?


--

[  804.485321] BUG: Bad page state in process qemu-system-x86  pfn:1c4b08e
[  804.485403] page:e809312c2380 count:0 mapcount:0 
mapping: index:0x1

[  804.485483] flags: 0x17fffc8(uptodate)
[  804.485554] raw: 017fffc8  0001 

[  804.485632] raw: dead0100 dead0200  


[  804.485709] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
[  804.485782] bad because of flags: 0x8(uptodate)
[  804.485852] Modules linked in: lz4 lz4_compress zram zsmalloc 
intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel pcb
c aesni_intel aes_x86_64 crypto_simd cryptd iTCO_wdt glue_helper 
iTCO_vendor_support intel_cstate binfmt_misc intel_uncore 
intel_rapl_perf pcspkr mei_me lpc_ich joydev sg mfd_core mei ioatdma 
shpchp wmi evdev ipmi_si ipmi_devintf ipmi_msgh
andler acpi_power_meter acpi_pad button ip_tables x_tables autofs4 ext4 
crc32c_generic crc16 mbcache jbd2 fscrypto hid_generic usbhid hid sd_mod 
ahci libahci xhci_pci ehci_pci libata igb xhci_hcd ehci_hcd crc32c_intel 
i2c_algo_bit scsi_mod

 i2c_i801 dca usbcore
[  804.485890] CPU: 17 PID: 1165 Comm: qemu-system-x86 Not tainted 4.17.9 #1
[  804.485891] Hardware name: Supermicro Super Server/X10SRL-F, BIOS 
2.0b 05/02/2017

[  804.485891] Call Trace:
[  804.485899]  dump_stack+0x5c/0x7b
[  804.485902]  bad_page+0xba/0x120
[  804.485905]  get_page_from_freelist+0x1016/0x1250
[  804.485908]  __alloc_pages_nodemask+0xfa/0x250
[  804.485911]  alloc_pages_vma+0x7c/0x1c0
[  804.485915]  __handle_mm_fault+0xcf6/0x1110
[  804.485918]  handle_mm_fault+0xfc/0x1f0
[  804.485921]  __get_user_pages+0x12f/0x670
[  804.485923]  get_user_pages_unlocked+0x148/0x1f0
[  804.485945]  __gfn_to_pfn_memslot+0xff/0x390 [kvm]
[  804.485959]  try_async_pf+0x67/0x200 [kvm]
[  804.485971]  tdp_page_fault+0x132/0x290 [kvm]
[  804.485975]  ? vmexit_fill_RSB+0xc/0x30 [kvm_intel]
[  804.485987]  kvm_mmu_page_fault+0x59/0x140 [kvm]
[  804.485999]  kvm_arch_vcpu_ioctl_run+0x9b3/0x1990 [kvm]
[  804.486003]  ? futex_wake+0x94/0x170
[  804.486012]  ? kvm_vcpu_ioctl+0x388/0x5d0 [kvm]
[  804.486021]  kvm_vcpu_ioctl+0x388/0x5d0 [kvm]
[  804.486024]  ? __switch_to+0x395/0x450
[  804.486026]  ? __switch_to+0x395/0x450
[  804.486029]  do_vfs_ioctl+0xa2/0x620
[  804.486030]  ? __x64_sys_futex+0x88/0x180
[  804.486032]  ksys_ioctl+0x70/0x80
[  804.486034]  __x64_sys_ioctl+0x16/0x20
[  804.486037]  do_syscall_64+0x55/0x100
[  804.486039]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  804.486041] RIP: 0033:0x7f82db677dd7
[  804.486042] RSP: 002b:7f82c1ffa8b8 EFLAGS: 0246 ORIG_RAX: 
0010
[  804.486044] RAX: ffda RBX: ae80 RCX: 
7f82db677dd7
[  804.486044] RDX:  RSI: ae80 RDI: 
0014
[  804.486045] RBP: 55b592a1ddf0 R08: 55b5914bb3d0 R09: 

[  804.486046] R10: 7f82c1ffa670 R11: 0246 R12: 

[  804.486047] R13: 7f82e0cc6000 R14:  R15: 
55b592a1ddf0

[  804.486048] Disabling lock debugging due to kernel taint

--

[  170.707761] BUG: Bad page state in process qemu-system-x86  pfn:1901199
[  170.707842] page:e453e4046640 count:0 mapcount:0 
mapping: index:0x1

[  170.707923] flags: 0x17fffc8(uptodate)
[  170.707996] raw: 017fffc8 dead0100 dead0200 

[  170.708074] raw: 0001   


[  170.708151] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
[  170.708225] bad because of flags: 0x8(uptodate)
[  170.708295] Modules linked in: lz4 lz4_compress zram zsmalloc 
intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp 
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel iTCO_wdt iTCO_vendor_support binfmt_misc pcbc 
aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate 
mei_me intel_uncore lpc_ich intel_rapl_perf pcspkr joydev sg mfd_core 
mei ioatdma wmi evdev ipmi_si ipmi_devintf ipmi_msghandler 
acpi_power_meter acpi_pad pcc_cpufreq button ip_tables x_tables autofs4 
ext4 crc32c_generic crc16 mbcache jbd2 fscrypto hid_generic usbhid hid 
sd_mod ahci libahci libata xhci_pci ehci_pci crc32c_intel xhci_hcd 
ehci_hcd scsi_mod i2c_i801 igb i2c_algo_bit dca usbcore
[  170.708344] CPU: 8 PID: 1031 Comm: qemu-system-x86 Not tainted 
4.18.0-rc6 #1
[  170.708345] Hardware name: 

Re: [PATCH 4.14 00/44] 4.14.58-stable review

[Naresh Kamboju]

On 23 July 2018 at 17:54, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.14.58 release.
> There are 44 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 Jul 25 12:24:22 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.14.58-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.14.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.14.58-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 07f27c4ed0e788c43a061c8aedff0ee003b51075
git describe: v4.14.57-45-g07f27c4ed0e7
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.57-45-g07f27c4ed0e7

No regressions (compared to build v4.14.56-93-gec86d5e19e14)


Ran 16387 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-filecaps-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-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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

VM boot failure on nodes not having DMA32 zone

[Liang C]

Hi,

We have a situation where our qemu processes need to be launched under
cgroup cpuset.mems control. This introduces an similar issue that was
discussed a few years ago. The difference here is that for our case,
not being able to allocate from DMA32 zone is a result a cgroup
restriction not mempolicy enforcement. Here is the steps to reproduce
the failure,

mkdir /sys/fs/cgroup/cpuset/nodeX (where X is a node not having DMA32 zone)
echo X > /sys/fs/cgroup/cpuset/nodeX/cpuset.mems
echo X > /sys/fs/cgroup/cpuset/nodeX/cpuset.cpus
echo 1 > /sys/fs/cgroup/cpuset/node0/cpuset.mem_hardwall
echo $$ > /sys/fs/cgroup/cpuset/nodeX/tasks

#launch a virtual machine
kvm_init_vcpu failed: Cannot allocate memory

There are workarounds, like always putting qemu processes onto the
node with DMA32 zone or not restricting qemu processes memory
allocation until that DMA32 alloc finishes (difficult to be precise).
But we would like to find a way to address the root cause.

Considering the fact that the pae_root shadow should not be needed
when ept is in use, which is indeed our case - ept is always available
for us (guessing this is the same case for most of other users), we
made a patch roughly like this,

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index d594690..1d1b61e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -5052,7 +5052,7 @@ int kvm_mmu_create(struct kvm_vcpu *vcpu)
vcpu->arch.mmu.translate_gpa = translate_gpa;
vcpu->arch.nested_mmu.translate_gpa = translate_nested_gpa;

-   return alloc_mmu_pages(vcpu);
+   return tdp_enabled ? 0 : alloc_mmu_pages(vcpu);
 }

 void kvm_mmu_setup(struct kvm_vcpu *vcpu)


It works through our test cases. But we would really like to have your
insight on this patch before applying it in production environment and
contributing it back to the community. Thanks in advance for any help
you may provide!

Thanks,
Liang Chen

Re: [PATCH v2 4/4] arm: dts: ls1021a: Enable I2C DMA support

[Uwe Kleine-König]

Hello,

expanding Cc a bit to include Shawn and the kernel teams of Pengutronix
and NXP.

On Mon, Jul 09, 2018 at 11:43:04AM +0200, Esben Haabendal wrote:
> From: Esben Haabendal 
> 
> Gives substantial performance improvement for transfers larger than 16
> bytes (DMA_THRESHOLD).  Smaller transfers are unaffected.
> 
> Signed-off-by: Esben Haabendal 
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index c55d479971cc..1e5640701c65 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -363,6 +363,8 @@
>   interrupts = ;
>   clock-names = "i2c";
>   clocks = < 4 1>;
> + dma-names = "tx", "rx";
> + dmas = < 1 39>, < 1 38>;
>   status = "disabled";
>   };
>  
> @@ -374,6 +376,8 @@
>   interrupts = ;
>   clock-names = "i2c";
>   clocks = < 4 1>;
> + dma-names = "tx", "rx";
> + dmas = < 1 37>, < 1 36>;
>   status = "disabled";
>   };
>  
> @@ -385,6 +389,8 @@
>   interrupts = ;
>   clock-names = "i2c";
>   clocks = < 4 1>;
> + dma-names = "tx", "rx";
> + dmas = < 1 35>, < 1 34>;
>   status = "disabled";
>   };

This is a bit orthogonal to the other changes in this series and needs
at least an ack from Shawn. Looks ok in my eyes.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH v4 1/4] x86/boot: Add acpitb.h to help parse acpi tables

[Chao Fan]

On Tue, Jul 24, 2018 at 02:02:57PM +0800, Baoquan He wrote:
>Hi chao,
>
>On 07/23/18 at 05:29pm, Chao Fan wrote:
>> In order to parse ACPI tables, reuse the head file linux/acpi.h,
>> so that the files in 'compressed' directory can read ACPI table
>> by including this head file.
>> 
>> Signed-off-by: Chao Fan 
>> ---
>>  arch/x86/boot/compressed/acpitb.h | 7 +++
>>  1 file changed, 7 insertions(+)
>>  create mode 100644 arch/x86/boot/compressed/acpitb.h
>> 
>> diff --git a/arch/x86/boot/compressed/acpitb.h 
>> b/arch/x86/boot/compressed/acpitb.h
>> new file mode 100644
>> index ..f8ab6e5b3e06
>> --- /dev/null
>> +++ b/arch/x86/boot/compressed/acpitb.h
>> @@ -0,0 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#include 
>> +
>> +#define ACPI_MAX_TABLES128
>> +
>> +/* Function to get ACPI SRAT table pointer. */
>> +struct acpi_table_header *get_acpi_srat_table(void);
>
>Since acpitb.h includes so few lines of code, not sure if we can move
>them into .c files directly.

Both acpitb.c and kaslr.c in my PATCH will use this head file.
And also eboot.h is also simple, so I put this code alone.

>
>By the way, you might need to rebase this patchset on top of
>tip/x86/boot.

OK, now it is based on master of tip.
Will do it in next version.

Thanks,
Chao Fan

>
>Thanks
>Baoquan
>
>

KASAN: stack-out-of-bounds Read in vma_interval_tree_insert (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:8ae71e76cf1f Merge branch 'bpf-offload-sharing'
git tree:   bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17fca5d040
kernel config:  https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
dashboard link: https://syzkaller.appspot.com/bug?extid=e64265a0e24946cf1c0d
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

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

skbuff: bad partial csum: csum=256/65280 len=851
==
BUG: KASAN: stack-out-of-bounds in vma_interval_tree_insert+0x23e/0x2a0  
mm/interval_tree.c:24

[ cut here ]
Read of size 8 at addr 8801cf1778d8 by task blkid/6772
do_IRQ(): syz-executor2 has overflown the kernel stack  
(cur:8801cf19,sp:8801ce38e2d8,irq stk  
top-bottom:8801daf00080-8801daf08000,exception stk  
top-bottom:fe038080-fe042000,ip:__x86_indirect_thunk_rax+0x10/0x20)


WARNING: CPU: 1 PID: 6760 at arch/x86/kernel/irq_64.c:63  
stack_overflow_check arch/x86/kernel/irq_64.c:60 [inline]
WARNING: CPU: 1 PID: 6760 at arch/x86/kernel/irq_64.c:63  
handle_irq+0x1fb/0x2e7 arch/x86/kernel/irq_64.c:72

CPU: 0 PID: 6772 Comm: blkid Not tainted 4.18.0-rc3+ #58
Kernel panic - not syncing: panic_on_warn set ...

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
 print_address_description+0x6c/0x20b mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
 vma_interval_tree_insert+0x23e/0x2a0 mm/interval_tree.c:24
 __vma_link_file+0xe4/0x1b0 mm/mmap.c:599
 vma_link+0xcd/0x170 mm/mmap.c:625
 mmap_region+0xe69/0x1890 mm/mmap.c:1785
 do_mmap+0xa06/0x1320 mm/mmap.c:1535
 do_mmap_pgoff include/linux/mm.h:2287 [inline]
 vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
 ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
 __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
 __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f5b200f43ea
Code:
blkid: Corrupted page table at address 7f5b200f43c0
PGD 1cf3f8067 P4D 1cf3f8067 PUD 1ce8fb067 PMD 41b58ab3
Bad pagetable: 0009 [#1] SMP KASAN
CPU: 0 PID: 6772 Comm: blkid Not tainted 4.18.0-rc3+ #58
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:copy_user_enhanced_fast_string+0xe/0x20  
arch/x86/lib/copy_user_64.S:180
Code: 89 d1 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 31 c0 0f 1f 00 c3 0f 1f  
80 00 00 00 00 0f 1f 00 83 fa 40 0f 82 70 ff ff ff 89 d1  a4 31 c0 0f  
1f 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 83

RSP: 0018:8801a92af4f0 EFLAGS: 00010046
RAX:  RBX: 8801a92af530 RCX: 0040
RDX: 0040 RSI: 7f5b200f43c0 RDI: 8801a92af530
RBP: 8801a92af520 R08: 8801cae44480 R09: ed0035255ea6
R10: ed0035255ead R11: 8801a92af56f R12: 0040
R13: 7000 R14: 7f5b200f43c0 R15: 8801cae44480
FS:  () GS:8801dae0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f5b200f43c0 CR3: 0001caa5c000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 show_opcodes+0x44/0xbe arch/x86/kernel/dumpstack.c:104
 show_ip+0x35/0x3a arch/x86/kernel/dumpstack.c:125
 show_iret_regs+0x14/0x38 arch/x86/kernel/dumpstack.c:130
 __show_regs+0x1c/0x60 arch/x86/kernel/process_64.c:72
 show_regs_if_on_stack.constprop.10+0x36/0x39  
arch/x86/kernel/dumpstack.c:148

 show_trace_log_lvl+0x25d/0x28c arch/x86/kernel/dumpstack.c:273
 show_stack+0x38/0x3a arch/x86/kernel/dumpstack.c:292
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
 print_address_description+0x6c/0x20b mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
 vma_interval_tree_insert+0x23e/0x2a0 mm/interval_tree.c:24
 __vma_link_file+0xe4/0x1b0 mm/mmap.c:599
 vma_link+0xcd/0x170 mm/mmap.c:625
 mmap_region+0xe69/0x1890 mm/mmap.c:1785
 do_mmap+0xa06/0x1320 mm/mmap.c:1535
 do_mmap_pgoff include/linux/mm.h:2287 [inline]
 vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
 ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
 __do_sys_mmap 

Re: [PATCH] mm: memcg: fix use after free in mem_cgroup_iter()

[Michal Hocko]

On Mon 23-07-18 09:17:28, Shakeel Butt wrote:
> On Sun, Jul 22, 2018 at 11:44 PM Michal Hocko  wrote:
> >
> > On Thu 19-07-18 09:23:10, Shakeel Butt wrote:
> > > On Thu, Jul 19, 2018 at 3:43 AM Michal Hocko  wrote:
> > > >
> > > > [CC Andrew]
> > > >
> > > > On Thu 19-07-18 18:06:47, Jing Xia wrote:
> > > > > It was reported that a kernel crash happened in mem_cgroup_iter(),
> > > > > which can be triggered if the legacy cgroup-v1 non-hierarchical
> > > > > mode is used.
> > > > >
> > > > > Unable to handle kernel paging request at virtual address 
> > > > > 6b6b6b6b6b6b8f
> > > > > ..
> > > > > Call trace:
> > > > >   mem_cgroup_iter+0x2e0/0x6d4
> > > > >   shrink_zone+0x8c/0x324
> > > > >   balance_pgdat+0x450/0x640
> > > > >   kswapd+0x130/0x4b8
> > > > >   kthread+0xe8/0xfc
> > > > >   ret_from_fork+0x10/0x20
> > > > >
> > > > >   mem_cgroup_iter():
> > > > >   ..
> > > > >   if (css_tryget(css))<-- crash here
> > > > >   break;
> > > > >   ..
> > > > >
> > > > > The crashing reason is that mem_cgroup_iter() uses the memcg object
> > > > > whose pointer is stored in iter->position, which has been freed before
> > > > > and filled with POISON_FREE(0x6b).
> > > > >
> > > > > And the root cause of the use-after-free issue is that
> > > > > invalidate_reclaim_iterators() fails to reset the value of
> > > > > iter->position to NULL when the css of the memcg is released in non-
> > > > > hierarchical mode.
> > > >
> > > > Well, spotted!
> > > >
> > > > I suspect
> > > > Fixes: 6df38689e0e9 ("mm: memcontrol: fix possible memcg leak due to 
> > > > interrupted reclaim")
> > > >
> > > > but maybe it goes further into past. I also suggest
> > > > Cc: stable
> > > >
> > > > even though the non-hierarchical mode is strongly discouraged.
> > >
> > > Why not set root_mem_cgroup's use_hierarchy to true by default on
> > > init? If someone wants non-hierarchical mode, they can explicitly set
> > > it to false.
> >
> > We do not change defaults under users feet usually.
> 
> Then how non-hierarchical mode is being discouraged currently? I don't
> see any comments in the docs.

css_create warns about non-hierarchical hierarchies. We've been running
with a similar warning in (even older) SLES kernels for years now and
quite some tools have been updated because they simply didn't know they
are doing something wrong.
-- 
Michal Hocko
SUSE Labs

Re: Linux 4.18-rc6

[Christian Borntraeger]

On 07/24/2018 09:24 AM, Martin Schwidefsky wrote:
> On Tue, 24 Jul 2018 09:15:58 +0200
> Christian Borntraeger  wrote:
> 
>> On 07/24/2018 08:18 AM, Martin Schwidefsky wrote:
>>> On Mon, 23 Jul 2018 16:17:22 -0700
>>> Linus Torvalds  wrote:
>>>   
 On Mon, Jul 23, 2018 at 2:23 PM Guenter Roeck  wrote:  
>
>>
>> Martin - can we just remove the
>>
>>  select HAVE_GCC_PLUGINS
>>
>> from the s390 Kconfig file (or perhaps add "if BROKEN" or something to
>> disable it).
>>
>> Because if it's not getting fixed, it shouldn't be exposed.
>>
> The problem only affects 4.18 - the code has been rearranged in -next.
> Only, in my builders, I can't disable a flag for individual releases,
> so I just disabled it completely for s390.

 Well, I'm not going to release a 4.18 with a known problem, so in 4.18
 this *will* be disabled if it's not fixed.

 The fact that it might be fixed in linux-next is entirely immaterial
 to the release of 4.18.  
>>>
>>> Ok, if gcc with the plugins and an allmodconfig is considered to be
>>> important enough to warrant a fix, it can be pulled from here:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
>>>
>>> Martin Schwidefsky (1):
>>>   s390: disable gcc plugins
>>>
>>> Once that is in I will create another patch to undo this one and place
>>> it after the early boot rework.  
>>
>> On the list a different fix was proposed about 2 weeks ago,
>>
>> something like
>>
>> CFLAGS_als.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
>>
>> and I prefer that. Because your patch disables all gcc plugins.
> 
> This change would cause trouble with patch dependencies as als.c is moved
> to a different directory. I would prefer to disable all gcc plugins for
> 4.18.

ok.

Re: [PATCH 4.17 00/63] 4.17.10-stable review

[Naresh Kamboju]

On 23 July 2018 at 17:54, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.17.10 release.
> There are 63 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 Jul 25 12:24: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.17.10-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.17.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.17.10-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.17.y
git commit: 2ef7dcee1485aefb44ba4fdd7ed149147c542501
git describe: v4.17.9-64-g2ef7dcee1485
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.17-oe/build/v4.17.9-64-g2ef7dcee1485

No regressions (compared to build v4.17.8-102-g8055764ff6b0)


Ran 16282 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-filecaps-tests
* ltp-fs_bind-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-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-fs-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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

Re: [PATCH 4.9 00/28] 4.9.115-stable review

[Naresh Kamboju]

On 23 July 2018 at 17:55, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.9.115 release.
> There are 28 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 Jul 25 12:24:13 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.9.115-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.9.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.9.115-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: e318b12e62e640f5d4bf996b28097812d10ec02c
git describe: v4.9.114-29-ge318b12e62e6
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.114-29-ge318b12e62e6

No regressions (compared to build v4.9.113-67-g97637db053bf)

Ran 16395 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-filecaps-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-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

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

[PATCH] KVM/MMU: Combine flushing remote tlb in mmu_set_spte()

[Tianyu Lan]

mmu_set_spte() flushes remote tlbs for drop_parent_pte/drop_spte()
and set_spte() separately. This may introduce redundant flush. This
patch is to combine these flushes and check flush request after
calling set_spte().

Signed-off-by: Lan Tianyu 
---
 arch/x86/kvm/mmu.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 22a7984..8f21632 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2901,6 +2901,7 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 
*sptep, unsigned pte_access,
int rmap_count;
int set_spte_ret;
int ret = RET_PF_RETRY;
+   bool flush = false;
 
pgprintk("%s: spte %llx write_fault %d gfn %llx\n", __func__,
 *sptep, write_fault, gfn);
@@ -2917,12 +2918,12 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 
*sptep, unsigned pte_access,
 
child = page_header(pte & PT64_BASE_ADDR_MASK);
drop_parent_pte(child, sptep);
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   flush = true;
} else if (pfn != spte_to_pfn(*sptep)) {
pgprintk("hfn old %llx new %llx\n",
 spte_to_pfn(*sptep), pfn);
drop_spte(vcpu->kvm, sptep);
-   kvm_flush_remote_tlbs(vcpu->kvm);
+   flush = true;
} else
was_rmapped = 1;
}
@@ -2934,7 +2935,7 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, u64 
*sptep, unsigned pte_access,
ret = RET_PF_EMULATE;
kvm_make_request(KVM_REQ_TLB_FLUSH, vcpu);
}
-   if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH)
+   if (set_spte_ret & SET_SPTE_NEED_REMOTE_TLB_FLUSH || flush)
kvm_flush_remote_tlbs(vcpu->kvm);
 
if (unlikely(is_mmio_spte(*sptep)))
-- 
2.7.4

Re: [PATCH v1 09/10] Input: atmel_mxt_ts - tool type is ignored when slot is closed

[Benjamin Tissoires]

On Tue, Jul 24, 2018 at 12:34 AM Dmitry Torokhov
 wrote:
>
> On Fri, Jul 20, 2018 at 10:51:21PM +0100, Nick Dyer wrote:
> > From: Nick Dyer 
> >
> > input_mt_report_slot_state() ignores the tool when the slot is closed.
> > Remove the tool type from these function calls, which has caused a bit of
> > confusion.
>
> Hmm, maybe we could introduce MT_TOOL_NONE or MT_TOOL_INACTIVE and get
> rid of the 3rd parameter? It will require a bit of macro trickery for a
> release or 2...

I am not sure what would be the benefit of adding those new tools, if
the input_mt code discards them. Do you want to forward them to the
userspace with the release?
This reminds me the discussion we had recently with the touchscreens
releasing the slots with a MT_TOOL_PALM.

Anyway, better include Peter as he will be using this new MT_TOOL.

Cheers,
Benjamin

>
> >
> > Signed-off-by: Nick Dyer 
> > ---
> >  drivers/input/touchscreen/atmel_mxt_ts.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
> > b/drivers/input/touchscreen/atmel_mxt_ts.c
> > index d7023d261458..c31af790ef84 100644
> > --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> > @@ -838,8 +838,7 @@ static void mxt_proc_t9_message(struct mxt_data *data, 
> > u8 *message)
> >* have happened.
> >*/
> >   if (status & MXT_T9_RELEASE) {
> > - input_mt_report_slot_state(input_dev,
> > -MT_TOOL_FINGER, 0);
> > + input_mt_report_slot_state(input_dev, 0, 0);
> >   mxt_input_sync(data);
> >   }
> >
> > @@ -855,7 +854,7 @@ static void mxt_proc_t9_message(struct mxt_data *data, 
> > u8 *message)
> >   input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, area);
> >   } else {
> >   /* Touch no longer active, close out slot */
> > - input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, 0);
> > + input_mt_report_slot_state(input_dev, 0, 0);
> >   }
> >
> >   data->update_input = true;
> > --
> > 2.17.1
> >
>
> --
> Dmitry

Re: linux-next-20180723: battery status funny after bootup

[Rafael J. Wysocki]

On Mon, Jul 23, 2018 at 11:49 PM, Pavel Machek  wrote:
>
> pavel@amd:~$ cat /proc/acpi/battery/BAT0/state
> present: yes
> capacity state:  ok
> charging state:  charged
> present rate:0 mW
> remaining capacity:  0 mWh
> present voltage: 0 mV
> pavel@amd:~$ uname -a
> Linux amd 4.18.0-rc6-next-20180723+ #141 SMP Mon Jul 23 22:11:47 CEST
> 2018 i686 GNU/Linux
>
> It will correct itself if I unplug/replug the AC adapter, I
> believe. Gnome2 battery monitor also looks confused.

There are two battery changes in linux-next now that are not present
in the mainline

2a2aad34362b ACPI: battery: remove redundant old_present check on insertion
706ac4aa536f ACPI: battery: use cache_time as cache "enabled"

Does reverting any of them help?  Or is the problem present in the mainline too?

Re: [PATCH v4 1/4] x86/boot: Add acpitb.h to help parse acpi tables

[Chao Fan]

On Tue, Jul 24, 2018 at 02:02:57PM +0800, Baoquan He wrote:
>Hi chao,
>
>On 07/23/18 at 05:29pm, Chao Fan wrote:
>> In order to parse ACPI tables, reuse the head file linux/acpi.h,
>> so that the files in 'compressed' directory can read ACPI table
>> by including this head file.
>> 
>> Signed-off-by: Chao Fan 
>> ---
>>  arch/x86/boot/compressed/acpitb.h | 7 +++
>>  1 file changed, 7 insertions(+)
>>  create mode 100644 arch/x86/boot/compressed/acpitb.h
>> 
>> diff --git a/arch/x86/boot/compressed/acpitb.h 
>> b/arch/x86/boot/compressed/acpitb.h
>> new file mode 100644
>> index ..f8ab6e5b3e06
>> --- /dev/null
>> +++ b/arch/x86/boot/compressed/acpitb.h
>> @@ -0,0 +1,7 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#include 
>> +
>> +#define ACPI_MAX_TABLES128
>> +
>> +/* Function to get ACPI SRAT table pointer. */
>> +struct acpi_table_header *get_acpi_srat_table(void);
>
>Since acpitb.h includes so few lines of code, not sure if we can move
>them into .c files directly.
>
>By the way, you might need to rebase this patchset on top of
>tip/x86/boot.

Sorry Baoquan,

I tried to add this patcheset to the tip/x86/boot branch using both 'patch'
command and 'git am'. I found no problem and no offset.
So is there some problems when you use them?

Thanks,
Chao Fan

>
>Thanks
>Baoquan
>
>

Re: [GIT PULL] FSI updates round 3 for 4.19

[Greg Kroah-Hartman]

On Tue, Jul 24, 2018 at 02:13:16PM +1000, Benjamin Herrenschmidt wrote:
> Hi Greg !
> 
> This adds support for offloading the FSI low level bitbanging to the
> ColdFire coprocessor of the Aspeed SoCs. All the pre-requisites have
> already been merged, this is the final piece in the puzzle.
> 
> This branch also pull gpio/ib-aspeed which is a topic branch already
> in gpio/for-next (and thus in next) whic contains pre-requisites.
> 
> Finally, there's also a bug fix to the sbefifo driver for some
> inconsistent use of a mutex in the error handling code.
> 
> Note: The oddball "origin" commit of that pull request comes from
> the fact that Linus Walleij gpio/ib-aspeed tree is ahead of mine,
> so pulling his branch pulled a bunch of already upstream other things
> in. As such, i had to base this pull request off a local merge. This
> shouldn't affect you at all, and allows the diffstat below to be
> correct.
> 
> The bindings updates have been acked by Rob and the corresponding
> device-tree updates will be merged by Joel via the ARM SoC tree.
> 
> Thanks !
> Ben.
> 
> The following changes since commit d5e748ff2b996d83489ac76c072e8b99f9ecef13:
> 
>   Merge remote-tracking branch 'gpio/ib-aspeed' into upstream-ready 
> (2018-07-23 15:21:39 +1000)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git 
> tags/fsi-updates-2018-07-24

Now pulled in and pushed out, thanks.

greg k-h

Re: [PATCH v10 3/7] Bluetooth: btqca: Redefine qca_uart_setup() to generic function.

[Balakrishna Godavarthi]

Hi Matthias,

On 2018-07-23 23:10, Matthias Kaehlcke wrote:

On Fri, Jul 20, 2018 at 07:02:39PM +0530, Balakrishna Godavarthi wrote:

Redefinition of qca_uart_setup will help future Qualcomm Bluetooth
SoC, to use the same function instead of duplicating the function.
Added new arguments soc_type and soc_ver to the functions.

These arguments will help to decide type of firmware files
to be loaded into Bluetooth chip.
soc_type holds the Bluetooth chip connected to APPS processor.
soc_ver holds the Bluetooth chip version.

Signed-off-by: Balakrishna Godavarthi 
Reviewed-by: Matthias Kaehlcke 
---
 drivers/bluetooth/btqca.c   | 20 +++-
 drivers/bluetooth/btqca.h   | 13 +++--
 drivers/bluetooth/hci_qca.c | 10 +-
 3 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index c5cf9cab438a..b556710ee1bd 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -85,6 +85,9 @@ int qca_read_soc_version(struct hci_dev *hdev, u32 
*soc_version)

 out:
kfree_skb(skb);

+   if (err < 0 || *soc_version == 0)
+   bt_dev_err(hdev, "QCA Failed to get version (%d)", err);


You also have to set 'err' if soc_version is 0, so the caller can skip
the check for soc_version == 0

I'd suggest:

  // directly after setting soc_version
  if (*soc_version == 0)
err = -EILSEQ; // or should it be a different error code?

  ...

  if (err)
bt_dev_err(hdev, "QCA Failed to get version (%d)", err);

You could also limit the error log to the 'if (*soc_version == 0)'
branch, for all other errors there will already be a more specific log
entry.



[Bala]: will update.

if(!err && *soc_version == 0)
err = -EINVAL; // as soc_version zero is invalid.

   if (err)
  bt_dev_err(hdev, "QCA Failed to get version (%d)", err);


+
return err;
 }


Cheers

Matthias

--
Regards
Balakrishna.

Re: WARNING in port_delete

[DaeRyong Jeong]

I agree with that having a C reproducer would be much better.
Now I'm working on it.
I will immediately let you know once I get the C reproducer.


Thank you.

Best regards,
DaeRyong Jeong
On 24 Jul 2018, 4:00 PM +0900, Takashi Iwai , wrote:
> On Tue, 24 Jul 2018 05:59:56 +0200,
> DaeRyong Jeong wrote:
> >
> > I just realized that the crash has been spotted by Syzkaller a few days 
> > before.
> > (https://syzkaller.appspot.com/bug?id=3490860a465e6b39227c6906f0ef2d40ad4d5bb1)
> >
> > I'm CC'ing Syzkaller's mailing list.
>
> It's very likely a false-positive sanity check, and if so, nothing
> serious at all. We may simply remove two snd_BUG_ON() lines.
>
> But I'd love to have a C reproducer to confirm my understanding is
> correct...
>
>
> thanks,
>
> Takashi
>
> ---
> --- a/sound/core/seq/seq_ports.c
> +++ b/sound/core/seq/seq_ports.c
> @@ -272,9 +272,6 @@ static int port_delete(struct snd_seq_client *client,
> if (port->private_free)
> port->private_free(port->private_data);
>
> - snd_BUG_ON(port->c_src.count != 0);
> - snd_BUG_ON(port->c_dest.count != 0);
> -
> kfree(port);
> return 0;
> }

Re: [PATCHv4 01/12] atomic/tty: Fix up atomic abuse in ldsem

[Ingo Molnar]

* Mark Rutland  wrote:

> From: Peter Zijlstra 
> 
> Mark found ldsem_cmpxchg() needed an (atomic_long_t *) cast to keep
> working after making the atomic_long interface type safe.
> 
> Needing casts is bad form, which made me look at the code. There are no
> ld_semaphore::count users outside of these functions so there is no
> reason why it can not be an atomic_long_t in the first place, obviating
> the need for this cast.
> 
> That also ensures the loads use atomic_long_read(), which implies (at
> least) READ_ONCE() in order to guarantee single-copy-atomic loads.
> 
> When using atomic_long_try_cmpxchg() the ldsem_cmpxchg() wrapper gets
> very thin (the only difference is not changing *old on success, which
> most callers don't seem to care about).
> 
> So rework the whole thing to use atomic_long_t and its accessors
> directly.
> 
> While there, fixup all the horrible comment styles.
> 
> Cc: Peter Hurley 
> Acked-by: Will Deacon 
> Reported-by: Mark Rutland 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Peter Zijlstra (Intel) 
> Signed-off-by: Mark Rutland 
> Cc: Ingo Molnar 
> ---
>  drivers/tty/tty_ldsem.c   | 82 
> ---
>  include/linux/tty_ldisc.h |  4 +--
>  2 files changed, 37 insertions(+), 49 deletions(-)
> 
> Note: Greg has queued this via the in the tty tree for v4.19, which can be 
> seen at: 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/commit/?h=tty-next=5fd691afdf929061c391d897fa627822c3b2fd5a

Can this patch be skipped, or do the others depend on it?

Thanks,

Ingo

Re: Linux 4.18-rc6

[Christian Borntraeger]

On 07/24/2018 08:18 AM, Martin Schwidefsky wrote:
> On Mon, 23 Jul 2018 16:17:22 -0700
> Linus Torvalds  wrote:
> 
>> On Mon, Jul 23, 2018 at 2:23 PM Guenter Roeck  wrote:
>>>  

 Martin - can we just remove the

  select HAVE_GCC_PLUGINS

 from the s390 Kconfig file (or perhaps add "if BROKEN" or something to
 disable it).

 Because if it's not getting fixed, it shouldn't be exposed.
  
>>> The problem only affects 4.18 - the code has been rearranged in -next.
>>> Only, in my builders, I can't disable a flag for individual releases,
>>> so I just disabled it completely for s390.  
>>
>> Well, I'm not going to release a 4.18 with a known problem, so in 4.18
>> this *will* be disabled if it's not fixed.
>>
>> The fact that it might be fixed in linux-next is entirely immaterial
>> to the release of 4.18.
> 
> Ok, if gcc with the plugins and an allmodconfig is considered to be
> important enough to warrant a fix, it can be pulled from here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
> 
> Martin Schwidefsky (1):
>   s390: disable gcc plugins
> 
> Once that is in I will create another patch to undo this one and place
> it after the early boot rework.

On the list a different fix was proposed about 2 weeks ago,

something like

CFLAGS_als.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)

and I prefer that. Because your patch disables all gcc plugins.

[GIT PULL] PHY: for 4.19

[Kishon Vijay Abraham I]

Hi Greg,

Please find the pull request for 4.19 merge window below. It contains
addition of 2 new PCIe PHY drivers for Broadcom's Stingray and Renesas
R-Car SoCs, switches to SPDX identifier in a few PHY drivers and enables
battery charging in Mediatek T-PHY driver.

Consider merging it for the next merge window and let me know if I have
to make any changes.

Thanks
Kishon

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
tags/phy-for-4.19

for you to fetch changes up to ec14b83a1ee40a9a72d84f0af356eccc948b24c4:

  phy: mvebu-cp110-comphy: switch to SPDX identifier (2018-07-24 11:12:15 +0530)


phy: for 4.19

 *) Add new PHY driver for GEN3 PCIe PHY on Renesas R-Car
 *) Add new PHY driver for PCIe PHY on Broadcom's Stingray SoC
 *) Enable battery charging in Mediatek T-PHY
 *) Switch to SPDX identifier in Marvell PHY drivers
 *) Fix compilation warning in phy-qcom-usb-hs.c

Signed-off-by: Kishon Vijay Abraham I 


Antoine Tenart (1):
  phy: mvebu-cp110-comphy: switch to SPDX identifier

Chunfeng Yun (5):
  phy: phy-mtk-tphy: use SPDX license tag
  dt-bindings: phy-mtk-tphy: add optional properties for u2phy
  phy: phy-mtk-tphy: add properties for eye diagram test
  phy: phy-mtk-tphy: add property for BC12
  MAINTAINERS: update files of MediaTek USB3 PHYs

Douglas Anderson (1):
  phy: qcom-qmp: Fix dts bindings to reflect reality

Gustavo A. R. Silva (1):
  phy: qcom-usb-hs: Mark expected switch fall-through

Jisheng Zhang (1):
  phy: berlin: switch to SPDX license identifier

Ray Jui (2):
  dt-bindings: phy: Add binding doc for Stingray PCIe PHY
  phy: bcm-sr-pcie: Add Stingray PCIe PHY driver

Sergei Shtylyov (2):
  dt-bindings: phy: Renesas R-Car Gen3 PCIe PHY bindings
  phy: Renesas R-Car gen3 PCIe PHY driver

Yoshihiro Shimoda (1):
  dt-bindings: rcar-gen3-phy-usb2: Add bindings for r8a77990

 Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.txt   |  41 
+++
 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt   |   6 +++
 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt   |  14 ++-
 Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt |  24 +++
 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |   2 +
 MAINTAINERS  |   3 +-
 drivers/phy/broadcom/Kconfig |  10 +
 drivers/phy/broadcom/Makefile|   2 +
 drivers/phy/broadcom/phy-bcm-sr-pcie.c   | 305 

 drivers/phy/marvell/phy-berlin-sata.c|   5 +--
 drivers/phy/marvell/phy-berlin-usb.c |   5 +--
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c |   5 +--
 drivers/phy/mediatek/Makefile|   1 +
 drivers/phy/mediatek/phy-mtk-tphy.c  |  85 
++
 drivers/phy/qualcomm/phy-qcom-usb-hs.c   |   1 +
 drivers/phy/renesas/Kconfig  |   7 
 drivers/phy/renesas/Makefile |   1 +
 drivers/phy/renesas/phy-rcar-gen3-pcie.c | 151 
+++
 18 files changed, 644 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/brcm,sr-pcie-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt
 create mode 100644 drivers/phy/broadcom/phy-bcm-sr-pcie.c
 create mode 100644 drivers/phy/renesas/phy-rcar-gen3-pcie.c

Re: [PATCH 3/4] perf tools: Fix check-headers.sh output file variables

[Alexander Kapshuk]

On Mon, Jul 23, 2018, 08:01 Jiri Olsa  wrote:

> On Fri, Jul 20, 2018 at 06:22:49PM +0300, Alexander Kapshuk wrote:
> > On Fri, Jul 20, 2018 at 6:16 PM Jiri Olsa  wrote:
> > >
> > > On Fri, Jul 20, 2018 at 11:57:45AM -0300, Arnaldo Carvalho de Melo
> wrote:
> > > > Em Fri, Jul 20, 2018 at 01:00:35PM +0200, Jiri Olsa escreveu:
> > > > > The warning message in check_w function uses wrongly
> > > > > the $file variable instead of $file1 and $file2.
> > > >
> > > > Humm,
> > > >
> > > > Before:
> > > >
> > > > Warning: Kernel ABI header at
> 'tools/arch/powerpc/include/uapi/asm/unistd.h' differs from latest version
> at 'arch/powerpc/include/uapi/asm/unistd.h'
> > > >
> > > > After:
> > > >
> > > > Warning: Kernel ABI header at
> '../arch/powerpc/include/uapi/asm/unistd.h' differs from latest version at
> '../../arch/powerpc/include/uapi/asm/unistd.h'
> > > >
> > > >
> > > > The previous version is better, I can then just use:
> > > >
> > > > diff -u tools/arch/powerpc/include/uapi/asm/unistd.h
> arch/powerpc/include/uapi/asm/unistd.h
> > > >
> > > > and get what changed, with your change I have to go to tools/perf
> before
> > > > doing that diff, which is an unnecessary extra step in at least my
> > > > workflow.
> > >
> > > so all paths output based in kernel tree root then, will change
> > >
> > > jirka
> >
> > I was going to ask about this in a separate email initially, but then
> > thought I'd use this email exchange instead, as my question is about
> > the code in question. Hope you don't mind.
> >
> > If I'm reading this right, the intended behavoir of the block of code
> > below is to test file2 for existance, and if it exists, to evaluate $cmd.
> > If file1 and file2 are found to differ, print the warning.
> >
> > test -f $file2 &&
> >   eval $cmd || echo "Warning: Kernel ABI header at 'tools/$file'
> > differs from latest version at '$file'" >&2
> >
> > The '||' path of execution is however also taken if file2 doesn't exist,
> > which is probably very unlikely to happen. See below.
> >
> > % file1=file1; file2=file2
> > % cmd="echo diff $file1 $file2"
> > % test -f $file2 &&
> > eval $cmd || echo "Warning: Kernel ABI header at 'tools/$file1'
> > differs from latest version at '$file2'" >&2
> > Warning: Kernel ABI header at 'tools/file1' differs from latest
> > version at 'file2'
> >
> > Is this something you would rather leave as is, or perhaps use something
> > along the lines of the code below instead:
> >
> > test -f $file2 && {
> > eval $cmd ||
> > echo "Warning: Kernel ABI header at 'tools/$file' differs from latest
> > version at '$file'" >&2
> > }
>
> hi,
> yea, probably..  please feel free to post a patch.. just make sure all
> the displayed files paths are based on the kernel root
>
> thanks,
> jirka
>

I'm away traveling till August 10th, and I may not be able to send the
patch in until I get back. Is that OK?
Thanks.

Re: KASAN: stack-out-of-bounds Read in vma_interval_tree_insert (2)

[Dmitry Vyukov]

On Tue, Jul 24, 2018 at 9:28 AM, syzbot
 wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:8ae71e76cf1f Merge branch 'bpf-offload-sharing'
> git tree:   bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=17fca5d040
> kernel config:  https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
> dashboard link: https://syzkaller.appspot.com/bug?extid=e64265a0e24946cf1c0d
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e64265a0e24946cf1...@syzkaller.appspotmail.com

#syz fix: bpf: sockhash, disallow bpf_tcp_close and update in parallel

> skbuff: bad partial csum: csum=256/65280 len=851
> ==
> BUG: KASAN: stack-out-of-bounds in vma_interval_tree_insert+0x23e/0x2a0
> mm/interval_tree.c:24
> [ cut here ]
> Read of size 8 at addr 8801cf1778d8 by task blkid/6772
> do_IRQ(): syz-executor2 has overflown the kernel stack
> (cur:8801cf19,sp:8801ce38e2d8,irq stk
> top-bottom:8801daf00080-8801daf08000,exception stk
> top-bottom:fe038080-fe042000,ip:__x86_indirect_thunk_rax+0x10/0x20)
>
> WARNING: CPU: 1 PID: 6760 at arch/x86/kernel/irq_64.c:63
> stack_overflow_check arch/x86/kernel/irq_64.c:60 [inline]
> WARNING: CPU: 1 PID: 6760 at arch/x86/kernel/irq_64.c:63
> handle_irq+0x1fb/0x2e7 arch/x86/kernel/irq_64.c:72
> CPU: 0 PID: 6772 Comm: blkid Not tainted 4.18.0-rc3+ #58
> Kernel panic - not syncing: panic_on_warn set ...
>
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
>  print_address_description+0x6c/0x20b mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>  vma_interval_tree_insert+0x23e/0x2a0 mm/interval_tree.c:24
>  __vma_link_file+0xe4/0x1b0 mm/mmap.c:599
>  vma_link+0xcd/0x170 mm/mmap.c:625
>  mmap_region+0xe69/0x1890 mm/mmap.c:1785
>  do_mmap+0xa06/0x1320 mm/mmap.c:1535
>  do_mmap_pgoff include/linux/mm.h:2287 [inline]
>  vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
>  ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
>  __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>  __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
>  __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
>  do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x7f5b200f43ea
> Code:
> blkid: Corrupted page table at address 7f5b200f43c0
> PGD 1cf3f8067 P4D 1cf3f8067 PUD 1ce8fb067 PMD 41b58ab3
> Bad pagetable: 0009 [#1] SMP KASAN
> CPU: 0 PID: 6772 Comm: blkid Not tainted 4.18.0-rc3+ #58
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:copy_user_enhanced_fast_string+0xe/0x20
> arch/x86/lib/copy_user_64.S:180
> Code: 89 d1 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 31 c0 0f 1f 00 c3 0f 1f
> 80 00 00 00 00 0f 1f 00 83 fa 40 0f 82 70 ff ff ff 89 d1  a4 31 c0 0f 1f
> 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 83
> RSP: 0018:8801a92af4f0 EFLAGS: 00010046
> RAX:  RBX: 8801a92af530 RCX: 0040
> RDX: 0040 RSI: 7f5b200f43c0 RDI: 8801a92af530
> RBP: 8801a92af520 R08: 8801cae44480 R09: ed0035255ea6
> R10: ed0035255ead R11: 8801a92af56f R12: 0040
> R13: 7000 R14: 7f5b200f43c0 R15: 8801cae44480
> FS:  () GS:8801dae0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f5b200f43c0 CR3: 0001caa5c000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  show_opcodes+0x44/0xbe arch/x86/kernel/dumpstack.c:104
>  show_ip+0x35/0x3a arch/x86/kernel/dumpstack.c:125
>  show_iret_regs+0x14/0x38 arch/x86/kernel/dumpstack.c:130
>  __show_regs+0x1c/0x60 arch/x86/kernel/process_64.c:72
>  show_regs_if_on_stack.constprop.10+0x36/0x39
> arch/x86/kernel/dumpstack.c:148
>  show_trace_log_lvl+0x25d/0x28c arch/x86/kernel/dumpstack.c:273
>  show_stack+0x38/0x3a arch/x86/kernel/dumpstack.c:292
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
>  print_address_description+0x6c/0x20b mm/kasan/report.c:256
>  kasan_report_error mm/kasan/report.c:354 [inline]
>  kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>  vma_interval_tree_insert+0x23e/0x2a0 mm/interval_tree.c:24
>  __vma_link_file+0xe4/0x1b0 mm/mmap.c:599
>  

Re: general protection fault in cpuacct_charge

[Dmitry Vyukov]

On Tue, Jul 24, 2018 at 9:27 AM, syzbot
 wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:8ae71e76cf1f Merge branch 'bpf-offload-sharing'
> git tree:   bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1645f97840
> kernel config:  https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
> dashboard link: https://syzkaller.appspot.com/bug?extid=a22ee0b9ff4d252439f4
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a22ee0b9ff4d25243...@syzkaller.appspotmail.com

#syz fix: bpf: sockhash, disallow bpf_tcp_close and update in parallel

> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> CPU: 1 PID: 0 Comm: �G+� ���0x�� Not tainted 4.18.0-rc3+ #58
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:task_css include/linux/cgroup.h:477 [inline]
> RIP: 0010:task_ca kernel/sched/cpuacct.c:43 [inline]
> RIP: 0010:cpuacct_charge+0x1b8/0x5d0 kernel/sched/cpuacct.c:349
> Code: 68 ff ff ff 85 c0 74 0d 80 3d 45 31 3c 08 00 0f 84 04 02 00 00 48 b8
> 00 00 00 00 00 fc ff df 49 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85
> 65 03 00 00 4d 8b 65 10 4d 85 e4 0f 84 0a 01 00
> RSP: 0018:8801daf072b0 EFLAGS: 00010006
> RAX: dc00 RBX: 8801c72b40c0 RCX: 
> RDX: 09f3 RSI: 8801 RDI: 4f99
> RBP: 8801daf07348 R08:  R09: 
> R10: 780baf52484d R11:  R12: 11003b5e0e5c
> R13: 4f89 R14: dc00 R15: 11003b5e0e58
> FS:  7f4ba8413700() GS:8801daf0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2340 CR3: 0001cf0ac000 CR4: 001406e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  
>  cgroup_account_cputime include/linux/cgroup.h:724 [inline]
>  update_curr+0x389/0xc00 kernel/sched/fair.c:832
>  enqueue_entity+0x40d/0x2130 kernel/sched/fair.c:4195
>  enqueue_task_fair+0x22d/0x910 kernel/sched/fair.c:5408
>  enqueue_task kernel/sched/core.c:751 [inline]
>  activate_task+0x123/0x2e0 kernel/sched/core.c:770
>  ttwu_activate kernel/sched/core.c:1659 [inline]
>  ttwu_do_activate+0xd5/0x1f0 kernel/sched/core.c:1718
>  ttwu_queue kernel/sched/core.c:1863 [inline]
>  try_to_wake_up+0x948/0x12b0 kernel/sched/core.c:2076
>  wake_up_process+0x10/0x20 kernel/sched/core.c:2149
>  hrtimer_wakeup+0x48/0x60 kernel/time/hrtimer.c:1647
>  __run_hrtimer kernel/time/hrtimer.c:1398 [inline]
>  __hrtimer_run_queues+0x3eb/0x10c0 kernel/time/hrtimer.c:1460
>  hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
>  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
>  smp_apic_timer_interrupt+0x165/0x730 arch/x86/kernel/apic/apic.c:1050
>  apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
>  
> Modules linked in:
> Dumping ftrace buffer:
>(ftrace buffer empty)
> ---[ end trace 63a513d0f55cc290 ]---
> RIP: 0010:task_css include/linux/cgroup.h:477 [inline]
> RIP: 0010:task_ca kernel/sched/cpuacct.c:43 [inline]
> RIP: 0010:cpuacct_charge+0x1b8/0x5d0 kernel/sched/cpuacct.c:349
> Code: 68 ff ff ff 85 c0 74 0d 80 3d 45 31 3c 08 00 0f 84 04 02 00 00 48 b8
> 00 00 00 00 00 fc ff df 49 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85
> 65 03 00 00 4d 8b 65 10 4d 85 e4 0f 84 0a 01 00
> RSP: 0018:8801daf072b0 EFLAGS: 00010006
> RAX: dc00 RBX: 8801c72b40c0 RCX: 
> RDX: 09f3 RSI: 8801 RDI: 4f99
> RBP: 8801daf07348 R08:  R09: 
> R10: 780baf52484d R11:  R12: 11003b5e0e5c
> R13: 4f89 R14: dc00 R15: 11003b5e0e58
> FS:  7f4ba8413700() GS:8801daf0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2340 CR3: 0001cf0ac000 CR4: 001406e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: [PATCH v5] x86: Avoid pr_cont() in show_opcodes().

[Ingo Molnar]

* Tetsuo Handa  wrote:

> On 2018/07/18 20:57, Ingo Molnar wrote:
> > 
> > * Tetsuo Handa  wrote:
> > 
> >> Since syzbot is confused by concurrent printk() messages [1],
> >> this patch changes show_opcodes() to use %ph format string.
> >>
> >> When we start adding prefix to each line of printk() output,
> >> we will be able to handle concurrent printk() messages.
> >>
> >> [1] https://syzkaller.appspot.com/text?tag=CrashReport=139d342c40
> >>
> >> Signed-off-by: Tetsuo Handa 
> >> Signed-off-by: Rasmus Villemoes 
> > 
> > Wasn't that variant of the patch written by Rasmus?
> 
> Rasmus Villemoes taught me that we can use "%*ph" format string and pass
> length as arguments for "*" part. Then, since Joe Perches suggested me to
> use #define for length variable, I updated to use "#define length immediate"
> and replaced "%*ph" with "%" __strigify(length) "ph" and removed length from
> arguments. That is v5 patch.
> 
> > 
> > If so then the changelog should start with:
> > 
> >  From: Rasmus Villemoes 
> 
> OK. I posted v6 patch with From: line updated.

Please do that only if it was mainly written by him - otherwise just tell me 
that 
it's yours and I'll apply it as such.

Thanks,

Ingo

Re: linux-next: build warning after merge of the fsi tree

[Greg KH]

On Tue, Jul 24, 2018 at 04:39:19PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2018-07-24 at 16:03 +1000, Stephen Rothwell wrote:
> > Hi Benjamin,
> > 
> > After merging the fsi tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> 
> Ah thanks. It's a pair of missing "z" qualifiers in those dev_dbg.
> 
> This normally won't show as this driver can only be enabled on 32-bit
> ARM, but COMPILE_TEST will allow you to build it on x86_64 thus
> triggering the warning.
> 
> I've pushed a fix in the fsi tree.
> 
> Greg, do you want a new signed tag with the fix or that can wait
> for my next pull request ? I have a last bunch of chardev conversions
> and object lifetime fixes being reviewed that I was thinking of sending
> later this week.

Later this week is fine.

thanks,

greg k-h

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

[Rafael J. Wysocki]

On Mon, Jul 23, 2018 at 10:22 PM,   wrote:
> On 2018-07-23 04:17, Rafael J. Wysocki wrote:
>>
>> On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar
>>  wrote:
>>>
>>> Drivers that are registered at an initcall level may have to
>>> wait until late_init before the probe deferral mechanism can
>>> retry their probe functions. It is possible that their
>>> dependencies were resolved much earlier, in some cases even
>>> before the next initcall level. Invoke one probe retry cycle
>>> at every _sync initcall level, allowing these drivers to be
>>> probed earlier.
>>
>>
>> Can you please say something about the actual use case this is
>> expected to address?
>
> We have a display driver that depends 3 other devices to be
> probed so that it can bring-up the display. Because of dependencies
> not being met the deferral mechanism defers the probes for a later time,
> even though the dependencies might be met earlier. With this change
> display can be brought up much earlier.

OK

What runlevel brings up the display after the change?

Thanks,
Rafael

Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps

[David Hildenbrand]

On 24.07.2018 09:25, Michal Hocko wrote:
> On Mon 23-07-18 19:20:43, David Hildenbrand wrote:
>> On 23.07.2018 14:30, Michal Hocko wrote:
>>> On Mon 23-07-18 13:45:18, Vlastimil Babka wrote:
 On 07/20/2018 02:34 PM, David Hildenbrand wrote:
> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
> So reserved pages might be access by dump tools although nobody except
> the owner should touch them.

 Are you sure about that? Or maybe I understand wrong. Maybe it changed
 recently, but IIRC pages that are backing memmap (struct pages) are also
 PG_reserved. And you definitely do want those in the dump.
>>>
>>> You are right. reserve_bootmem_region will make all early bootmem
>>> allocations (including those backing memmaps) PageReserved. I have asked
>>> several times but I haven't seen a satisfactory answer yet. Why do we
>>> even care for kdump about those. If they are reserved the nobody should
>>> really look at those specific struct pages and manipulate them. Kdump
>>> tools are using a kernel interface to read the content. If the specific
>>> content is backed by a non-existing memory then they should simply not
>>> return anything.
>>>
>>
>> "new kernel" provides an interface to read memory from "old kernel".
>>
>> The new kernel has no idea about
>> - which memory was added/online in the old kernel
>> - where struct pages of the old kernel are and what their content is
>> - which memory is save to touch and which not
>>
>> Dump tools figure all that out by interpreting the VMCORE. They e.g.
>> identify "struct pages" and see if they should be dumped. The "new
>> kernel" only allows to read that memory. It cannot hinder to crash the
>> system (e.g. if a dump tool would try to read a hwpoison page).
>>
>> So how should the "new kernel" know if a page can be touched or not?
> 
> I am sorry I am not familiar with kdump much. But from what I remember
> it reads from /proc/vmcore and implementation of this interface should
> simply return EINVAL or alike when you try to dump inaccessible memory
> range.

I assume the main problem with this approach is that we would always
have to fallback to reading old memory from vmcore page by page. e.g.
makedumpfile will always try to read bigger bunches. I also assume the
reason HWPOISON is handled in dump tools instead of in the kernel using
the mechanism you describe is the case.

One way to avoid this would be to silently "read zero". Although not
nice, it avoids having to touch dump tools.

E.g. fs/proc/vmcore.c:read_from_oldmem() has a hook called
"pfn_is_ram()". This is the hook for XEN I mentioned previously.

-> register_oldmem_pfn_is_ram()

However this callback right now assumes that there is a "global
hypervisor implemented way of checking whether a page is accessible". We
don't want anything like that in KVM.

I could imagine extending this register mechanism in a way that
- we can have multiple callbacks
- we can return something like "Yes" / "No" / "Don't know"

So we could have multiple devices (controlling a memory area) register
there and when called, they could see if they are responsible for that
area and query the hypervisor (e.g. using virtio).

Might be complicated but the last resort.

-- 

Thanks,

David / dhildenb

[PATCH 4/5] filesystem-dax: Do not request a pointer kaddr when not required

[Huaisheng Ye]

From: Huaisheng Ye 

Some functions within fs/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run
in the background elide requests for pointer kaddr when not required.

Signed-off-by: Huaisheng Ye 
---
 fs/dax.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index aaec72de..abdb9e2 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -870,7 +870,6 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, 
size_t size,
 {
const sector_t sector = dax_iomap_sector(iomap, pos);
pgoff_t pgoff;
-   void *kaddr;
int id, rc;
long length;
 
@@ -879,7 +878,7 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, 
size_t size,
return rc;
id = dax_read_lock();
length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
-  , pfnp);
+  NULL, pfnp);
if (length < 0) {
rc = length;
goto out;
-- 
1.8.3.1

Re: [PATCH] ACPI / LPSS: Avoid PM quirks on suspend and resume from S3

[Kai Heng Feng]

Hi Rafael,


On Jun 13, 2018, at 7:17 PM, Rafael J. Wysocki  wrote:

From: Rafael J. Wysocki 

It is reported that commit a192aa923b66a (ACPI / LPSS: Consolidate
runtime PM and system sleep handling) introduced a system suspend
regression on some machines, but the only functional change made by
it was to cause the PM quirks in the LPSS to also be used during
system suspend and resume.  While that should always work for
suspend-to-idle, it turns out to be problematic for S3
(suspend-to-RAM).

To address that issue restore the previous S3 suspend and resume
behavior of the LPSS to avoid applying PM quirks then.


The users reported that this patch does fix the S3 issue, but the S4 still  
fails.


Please refer to [1] for more for user's testing result.

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950/comments/60

Kai-Heng



Fixes: a192aa923b66a (ACPI / LPSS: Consolidate runtime PM and system  
sleep handling)

Link: https://bugs.launchpad.net/bugs/1774950
Reported-by: Kai-Heng Feng 
Tested-by: Kai-Heng Feng 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/acpi_lpss.c |   18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/acpi/acpi_lpss.c
===
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "internal.h"
@@ -940,9 +941,10 @@ static void lpss_iosf_exit_d3_state(void
mutex_unlock(_iosf_mutex);
 }

-static int acpi_lpss_suspend(struct device *dev, bool wakeup)
+static int acpi_lpss_suspend(struct device *dev, bool runtime)
 {
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
+   bool wakeup = runtime || device_may_wakeup(dev);
int ret;

if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
@@ -955,13 +957,14 @@ static int acpi_lpss_suspend(struct devi
 * wrong status for devices being about to be powered off. See
 * lpss_iosf_enter_d3_state() for further information.
 */
-   if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+   if ((runtime || !pm_suspend_via_firmware()) &&
+   lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_enter_d3_state();

return ret;
 }

-static int acpi_lpss_resume(struct device *dev)
+static int acpi_lpss_resume(struct device *dev, bool runtime)
 {
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
@@ -970,7 +973,8 @@ static int acpi_lpss_resume(struct devic
 * This call is kept first to be in symmetry with
 * acpi_lpss_runtime_suspend() one.
 */
-   if (lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
+   if ((runtime || !pm_resume_via_firmware()) &&
+   lpss_quirks & LPSS_QUIRK_ALWAYS_POWER_ON && iosf_mbi_available())
lpss_iosf_exit_d3_state();

ret = acpi_dev_resume(dev);
@@ -994,12 +998,12 @@ static int acpi_lpss_suspend_late(struct
return 0;

ret = pm_generic_suspend_late(dev);
-   return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
+   return ret ? ret : acpi_lpss_suspend(dev, false);
 }

 static int acpi_lpss_resume_early(struct device *dev)
 {
-   int ret = acpi_lpss_resume(dev);
+   int ret = acpi_lpss_resume(dev, false);

return ret ? ret : pm_generic_resume_early(dev);
 }
@@ -1014,7 +1018,7 @@ static int acpi_lpss_runtime_suspend(str

 static int acpi_lpss_runtime_resume(struct device *dev)
 {
-   int ret = acpi_lpss_resume(dev);
+   int ret = acpi_lpss_resume(dev, true);

return ret ? ret : pm_generic_runtime_resume(dev);
 }

Re: [PATCH v3 3/3] clk: qcom: Add display clock controller driver for SDM845

[Stephen Boyd]

Quoting spa...@codeaurora.org (2018-07-13 01:25:49)
> On 2018-07-13 01:11, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-07-12 10:21:33)
> >> ++ Display driver team,
> >> 
> >> On 7/9/2018 8:36 PM, Stephen Boyd wrote:
> >> > Quoting Taniya Das (2018-07-09 02:34:07)
> >> >>
> >> >>
> >> >> On 7/9/2018 1:07 PM, Stephen Boyd wrote:
> >> >>> Quoting Taniya Das (2018-07-09 00:07:21)
> >> 
> >> 
> >>  On 7/9/2018 11:46 AM, Stephen Boyd wrote:
> >> >>
> >> >> > Why is the nocache flag needed? Applies to all clks in this 
> >> >> file.
> >> >> >
> >> >>
> >> >> This flag is required for all RCGs whose PLLs are controlled 
> >> >> outside the
> >> >> clock controller. The display code would require the recalculated 
> >> >> rate
> >> >> always.
> >> >
> >> > Right. Why is the PLL controlled outside of the clock controller? The
> >> > rate should propagate upward to the PLL from here, so who's going
> >> > outside of that?
> >> >
> >>  The DSI0/1 PLL are not part of the display clock controller, but in 
> >>  the
> >>  display subsystem which are managed by the DRM drivers. When DRM 
> >>  drivers
> >>  query for the rate clock driver should always return the non cached 
> >>  rates.
> >> >>>
> >> >>> Why? Is the DSI PLL changing rate all the time, randomly, without going
> >> >>> through the clk APIs to do so?
> >> >>>
> >> >>
> >> >> Hmm, I am afraid I do not have an answer for this, but this was the
> >> >> requirement to always return the non cached rates from the clock driver.
> >> >>
> >> >
> >> > Ok. Who knows about this requirement? Can we add someone from the
> >> > display driver to understand more?
> >> >
> >> As per my discussions offline with the display teams,
> >> 
> >> There is a use-case where the clock framework is unaware of the PLL 
> >> VCO
> >> frequency change and thus the drivers would query to get the actual HW
> >> frequency rather than the cached one.
> >> 
> >> Do you think keeping these flags would have any impact other than 
> >> always
> >> getting the non-cached rates?
> >> 
> > 
> > The flag will make it so clk_get_rate() works in spite of something
> > changing the frequency behind the framework's back, but I want to
> > understand what and why it's changing without framework involvement. We
> > shouldn't need the flag here, because this flag is typically for clks
> > that are controlled by some other entity that the kernel doesn't have
> > control over. In this case, it seems like we have full control of the
> > clk tree for the display PLL down to this clk, so it should be 
> > perfectly
> > fine to not have this flag. The presence of the flag means that the
> > display driver is doing something wrong.
> 
> These clocks are sourced from DSI PLL. In dsi command mode there is an 
> idle use case when there
> is no activity on display, we switch of the source DSI PLL to save power 
> by calling clk_disable_unprepare().
> In this scenario if some client queries the clk_get_rate(), then if 
> NO_CACHE flag is used the clk
> driver will return the cached rate which is some non-zero value set when 
> we last called clk_set_rate(),
> before enabling the clock, whereas actually in HW this clk is disabled. 

If the clk is disabled in hardware it doesn't mean clk_get_rate() should
return 0 Hz. The frequency of the clk is set to something, so we should
return what that frequency is by reading the hardware.

> So we used the NO_CACHE flag
> for the call to land in clk_recalc_rate and we return zero if the PLL is 
> disabled.

This is super wrong. If the PLL is disabled it still has some frequency
configured.

[PATCH v3 1/2] clk: qcom: Add qspi (Quad SPI) clock defines for sdm845 to header

[Douglas Anderson]

These clocks will need to be defined in the clock driver and
referenced in device tree files.

Signed-off-by: Douglas Anderson 
---

Changes in v3: None
Changes in v2: None

 include/dt-bindings/clock/qcom,gcc-sdm845.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h 
b/include/dt-bindings/clock/qcom,gcc-sdm845.h
index f96fc2dbf60e..b8eae5a76503 100644
--- a/include/dt-bindings/clock/qcom,gcc-sdm845.h
+++ b/include/dt-bindings/clock/qcom,gcc-sdm845.h
@@ -194,6 +194,9 @@
 #define GPLL4  184
 #define GCC_CPUSS_DVM_BUS_CLK  185
 #define GCC_CPUSS_GNOC_CLK 186
+#define GCC_QSPI_CORE_CLK_SRC  187
+#define GCC_QSPI_CORE_CLK  188
+#define GCC_QSPI_CNOC_PERIPH_AHB_CLK   189
 
 /* GCC Resets */
 #define GCC_MMSS_BCR   0
-- 
2.18.0.233.g985f88cf7e-goog

[PATCH v3 2/2] clk: qcom: Add qspi (Quad SPI) clocks for sdm845

[Douglas Anderson]

Add both the interface and core clock.

Signed-off-by: Douglas Anderson 
(am from https://lore.kernel.org/patchwork/patch/966680/mbox)

---

Changes in v3:
- Removed gcc_parent_names_9 which I had left in (doh!).

Changes in v2:
- Only 19.2, 100, 150, and 300 MHz now.
- All clocks come from MAIN rather than EVEN.
- Use parent map 0 instead of new parent map 9.

 drivers/clk/qcom/gcc-sdm845.c | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index 0f694ed4238a..fc1c6658ad82 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -358,6 +358,28 @@ static struct clk_rcg2 gcc_pcie_phy_refgen_clk_src = {
},
 };
 
+static const struct freq_tbl ftbl_gcc_qspi_core_clk_src[] = {
+   F(1920, P_BI_TCXO, 1, 0, 0),
+   F(1, P_GPLL0_OUT_MAIN, 6, 0, 0),
+   F(15000, P_GPLL0_OUT_MAIN, 4, 0, 0),
+   F(3, P_GPLL0_OUT_MAIN, 2, 0, 0),
+   { }
+};
+
+static struct clk_rcg2 gcc_qspi_core_clk_src = {
+   .cmd_rcgr = 0x4b008,
+   .mnd_width = 0,
+   .hid_width = 5,
+   .parent_map = gcc_parent_map_0,
+   .freq_tbl = ftbl_gcc_qspi_core_clk_src,
+   .clkr.hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_core_clk_src",
+   .parent_names = gcc_parent_names_0,
+   .num_parents = 4,
+   .ops = _rcg2_floor_ops,
+   },
+};
+
 static const struct freq_tbl ftbl_gcc_pdm2_clk_src[] = {
F(960, P_BI_TCXO, 2, 0, 0),
F(1920, P_BI_TCXO, 1, 0, 0),
@@ -1935,6 +1957,37 @@ static struct clk_branch gcc_qmip_video_ahb_clk = {
},
 };
 
+static struct clk_branch gcc_qspi_cnoc_periph_ahb_clk = {
+   .halt_reg = 0x4b000,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x4b000,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_cnoc_periph_ahb_clk",
+   .ops = _branch2_ops,
+   },
+   },
+};
+
+static struct clk_branch gcc_qspi_core_clk = {
+   .halt_reg = 0x4b004,
+   .halt_check = BRANCH_HALT,
+   .clkr = {
+   .enable_reg = 0x4b004,
+   .enable_mask = BIT(0),
+   .hw.init = &(struct clk_init_data){
+   .name = "gcc_qspi_core_clk",
+   .parent_names = (const char *[]){
+   "gcc_qspi_core_clk_src",
+   },
+   .num_parents = 1,
+   .flags = CLK_SET_RATE_PARENT,
+   .ops = _branch2_ops,
+   },
+   },
+};
+
 static struct clk_branch gcc_qupv3_wrap0_s0_clk = {
.halt_reg = 0x17030,
.halt_check = BRANCH_HALT_VOTED,
@@ -3383,6 +3436,9 @@ static struct clk_regmap *gcc_sdm845_clocks[] = {
[GPLL4] = ,
[GCC_CPUSS_DVM_BUS_CLK] = _cpuss_dvm_bus_clk.clkr,
[GCC_CPUSS_GNOC_CLK] = _cpuss_gnoc_clk.clkr,
+   [GCC_QSPI_CORE_CLK_SRC] = _qspi_core_clk_src.clkr,
+   [GCC_QSPI_CORE_CLK] = _qspi_core_clk.clkr,
+   [GCC_QSPI_CNOC_PERIPH_AHB_CLK] = _qspi_cnoc_periph_ahb_clk.clkr,
 };
 
 static const struct qcom_reset_map gcc_sdm845_resets[] = {
-- 
2.18.0.233.g985f88cf7e-goog

[PATCH v3 0/2] clk: qcom: Quad SPI (qspi) clock support for sdm845

[Douglas Anderson]

This two-series patch adds the needed clock bits to use the Quad SPI
(qspi) part on sdm845.  It's expected that the bindings part of this
patch could land in the clock tree with an immutable git hash and then
be pulled into the Qualcomm tree so it could be used by dts files.

>From the reply to my v1, the clock plan for this clock is:
- MinSVS@19.2
- LowSVS@75
- SVS@150
- Nominal@300
...and intermediate frequencies can be used at frequences less than
300.  I didn't see a need for 75 MHz and it was unclear from previous
replies if this should come from MAIN or EVEN so I left it out.  I
have added 100 MHz here since it is useful (/ 4 = 25 MHz is a useful
clock for SPI flash)

OTHER NOTES:
- From probing lines, it appears that the Quad SPI block has a divide
  by 4 somewhere inside it (probably so it can oversample the lines,
  or possibly so it can generate phase-offset clocks).  Thus we need
  the core to go 4 times faster than we'd expect to run the SPI bus.
- SPI devices usually specify the MAX frequency they should be clocked
  at, so it's important that we use the clk_rcg2_floor_ops here rather
  than the clk_rcg2_ops

Changes in v3:
- Removed gcc_parent_names_9 which I had left in (doh!).

Changes in v2:
- Only 19.2, 100, 150, and 300 MHz now.
- All clocks come from MAIN rather than EVEN.
- Use parent map 0 instead of new parent map 9.

Douglas Anderson (2):
  clk: qcom: Add qspi (Quad SPI) clock defines for sdm845 to header
  clk: qcom: Add qspi (Quad SPI) clocks for sdm845

 drivers/clk/qcom/gcc-sdm845.c   | 56 +
 include/dt-bindings/clock/qcom,gcc-sdm845.h |  3 ++
 2 files changed, 59 insertions(+)

-- 
2.18.0.233.g985f88cf7e-goog

Re: [PATCH v6 1/9] Makefile: Prepare for using macros for inline asm

[Nadav Amit]

at 4:14 AM, Ingo Molnar  wrote:

> 
> * Masahiro Yamada  wrote:
> 
>> 2018-06-23 2:22 GMT+09:00 Nadav Amit :
>>> Using macros for inline assembly improves both readability and
>>> compilation decisions that are distorted by big assembly blocks that use
>>> alternative sections. Compile macros.S and use it to assemble all C
>>> files. Currently, only x86 will use it.
>>> 
>>> Cc: Sam Ravnborg 
>>> Cc: Masahiro Yamada 
>>> Cc: Michal Marek 
>>> Cc: Thomas Gleixner 
>>> Cc: Ingo Molnar 
>>> Cc: "H. Peter Anvin" 
>>> Cc: x...@kernel.org
>>> Cc: linux-kbu...@vger.kernel.org
>>> Acked-by: Peter Zijlstra (Intel) 
>>> Signed-off-by: Nadav Amit 
>>> ---
>> 
>> 
>> 
>> Acked-by: Masahiro Yamada 
>> 
>> 
>> 
>> 
>>> Makefile |  9 +++--
>>> arch/x86/Makefile| 11 +--
>>> arch/x86/kernel/macros.S |  7 +++
>>> scripts/Kbuild.include   |  4 +++-
>>> scripts/mod/Makefile |  2 ++
>>> 5 files changed, 28 insertions(+), 5 deletions(-)
>>> create mode 100644 arch/x86/kernel/macros.S
> 
> So this patch appears to break the xtensa cross-build on my system, with an 
> older 
> version of crosstools:
> 
>  MODPOST vmlinux.o
> /home/mingo/crosstool-korg/bin//gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-ld:./arch/xtensa/kernel/vmlinux.lds:430:
>  
> syntax error
> /home/mingo/tip/Makefile:1010: recipe for target 'vmlinux' failed
> make[1]: *** [vmlinux] Error 1
> make[1]: Leaving directory '/dev/shm/tip/build'
> Makefile:146: recipe for target 'sub-make’ failed

This one is due to a missing -DLINKER_SCRIPT in the Makefile of xtensa. I’ll
send the patch to fix it after I deal with the boot failure (for which I
wait for your config file).

Thanks,
Nadav

RE: [PATCH v10 00/10] drivers: Introduce firmware dnd clock river for ZynqMP core

[Jolly Shah]

Hi Michal,

> -Original Message-
> From: Michal Simek [mailto:michal.si...@xilinx.com]
> Sent: Thursday, July 19, 2018 3:33 AM
> To: Jolly Shah ; ard.biesheu...@linaro.org;
> mi...@kernel.org; gre...@linuxfoundation.org; m...@codeblueprint.co.uk;
> sudeep.ho...@arm.com; hkallwe...@gmail.com; keesc...@chromium.org;
> dmitry.torok...@gmail.com; mturque...@baylibre.com;
> sb...@codeaurora.org; Michal Simek ;
> robh...@kernel.org; mark.rutl...@arm.com; linux-...@vger.kernel.org
> Cc: Rajan Vaja ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Jolly Shah
> 
> Subject: Re: [PATCH v10 00/10] drivers: Introduce firmware dnd clock river for
> ZynqMP core
> 
> On 17.7.2018 21:58, Jolly Shah wrote:
> > This patchset is adding communication layer with firmware and clock
> > driver who uses those APIs to communicate with PMU.
> > Firmware driver provides an interface to firmware APIs.Interface APIs
> > can be used by any driver to communicate to PMUFW(Platform Management
> Unit). All requests go through ATF.
> > This patchset adds CCF compliant clock driver for ZynqMP.Clock driver
> > queries supported clock information from firmware and regiters pll and 
> > output
> clocks with CCF.
> > v10:
> >  - Incorporated code review comments from v9 patch series. Discussed below:
> > https://patchwork.kernel.org/patch/10478575/
> > https://patchwork.kernel.org/patch/10478457/
> > https://patchwork.kernel.org/patch/10478461/
> > https://patchwork.kernel.org/patch/10478463/
> >
> > v9:
> >  - Fixed minor typo comments
> >
> > v8:
> >  - Corrected typo in clk Kconfig
> >
> > v7:
> >  - Removed xilinx specific clock debugfs API support
> >  - Added reviewed-by tags for FW and clock bindings
> >  - Updated clock node name to clock-controller
> >
> > v6:
> >  - Broke patch series to have base FW driver and Clock driver user
> >  - Incorporated code review comments from last FW and Clock driver patch
> series. Discussed below:
> > https://patchwork.kernel.org/patch/10230759/
> > https://patchwork.kernel.org/patch/10250047/
> >
> > v5:
> >  - Added ATF version check support
> >  - Updated some functions to be static
> >  - Minor function name corrections
> >
> > v4:
> >  - Changed clock setrate/getrate API prototype to support 64 bit rate
> >  - Defined macros for get_node_status return values
> >  - Moved DT node as a child of firmware
> >  - Changed debugfs APIs to return data to debugfs buffer instead of
> > dumping to kernel log
> >  - Minor changes to incorporate other review comments from v3 patch
> > series
> >
> > v3:
> >  - added some fixes to firmware-ggs.c
> >  - updated pinmux get/set function argument names to specify function
> > id instead of node id
> >  - added new pinctrl query macros
> >  - incorporated review comments from v2 patch series
> >
> > v2:
> >  - change SPDX-License-Identifier license text style
> >  - split patch into multiple patches
> >  - Updated copyrights
> >  - Added ABI documentation
> >  - incorporated logical review comments from previuos patch. Discussed
> below:
> > https://patchwork.kernel.org/patch/10150665/
> >
> > Jolly Shah (1):
> >   drivers: clk: Add ZynqMP clock driver
> >
> > Rajan Vaja (9):
> >   dt-bindings: firmware: Add bindings for ZynqMP firmware
> >   firmware: xilinx: Add Zynqmp firmware driver
> >   firmware: xilinx: Add zynqmp IOCTL API for device control
> >   firmware: xilinx: Add query data API
> >   firmware: xilinx: Add clock APIs
> >   firmware: xilinx: Add debugfs interface
> >   firmware: xilinx: Add debugfs for IOCTL API
> >   firmware: xilinx: Add debugfs for query data API
> >   dt-bindings: clock: Add bindings for ZynqMP clock driver
> >
> >  .../firmware/xilinx/xlnx,zynqmp-firmware.txt   |  82 +++
> >  arch/arm64/Kconfig.platforms   |   1 +
> >  drivers/clk/Kconfig|   1 +
> >  drivers/clk/Makefile   |   1 +
> >  drivers/clk/zynqmp/Kconfig |  10 +
> >  drivers/clk/zynqmp/Makefile|   4 +
> >  drivers/clk/zynqmp/clk-gate-zynqmp.c   | 144 +
> >  drivers/clk/zynqmp/clk-mux-zynqmp.c| 141 
> >  drivers/clk/zynqmp/clk-zynqmp.h|  68 ++
> >  drivers/clk/zynqmp/clkc.c  | 719 
> > +
> >  drivers/clk/zynqmp/divider.c   | 217 +++
> >  drivers/clk/zynqmp/pll.c   | 335 ++
> >  drivers/firmware/Kconfig   |   1 +
> >  drivers/firmware/Makefile  |   1 +
> >  drivers/firmware/xilinx/Kconfig|  23 +
> >  drivers/firmware/xilinx/Makefile   |   5 +
> >  drivers/firmware/xilinx/zynqmp-debug.c | 249 +++
> >  drivers/firmware/xilinx/zynqmp-debug.h |  22 +
> >  drivers/firmware/xilinx/zynqmp.c  

[PATCH v2 3/3] MAINTAINERS: Add entry for mcp3911 ADC driver

[Marcus Folkesson]

Add an entry for mcp3911 ADC driver and add myself and
Kent Gustavsson as maintainers of this driver.

Signed-off-by: Marcus Folkesson 
Signed-off-by: Kent Gustavsson 
---

Notes:
v2:
- no changes

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

diff --git a/MAINTAINERS b/MAINTAINERS
index 79bb02ff812f..9276da915d9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9271,6 +9271,14 @@ L:   net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/microchip/lan743x_*
 
+MICROCHIP / ATMEL MCP3911 ADC DRIVER
+M: Marcus Folkesson 
+M: Kent Gustavsson 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/iio/adc/mcp3911.c
+F: Documentation/devicetree/bindings/iio/adc/mcp3911.txt
+
 MICROCHIP USB251XB DRIVER
 M: Richard Leitner 
 L: linux-...@vger.kernel.org
-- 
2.11.0.rc2

[PATCH v2 1/3] iio: adc: add support for mcp3911

[Marcus Folkesson]

MCP3911 is a dual channel Analog Front End (AFE) containing two
synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).

Signed-off-by: Marcus Folkesson 
Signed-off-by: Kent Gustavsson 
---

Notes:
v2:
- cleanups and bugfixes (thanks Peter Meerwald-Stadler)
- drop hardware gain
- use the presence or lack of regulator to indicate if we go for 
internal or external voltage reference
- do not store device node in private struct
- drop support to set width in devicetree
- use the presence or lack of clock to indicate if we go for internal 
or external clock

 drivers/iio/adc/Kconfig   |  10 ++
 drivers/iio/adc/Makefile  |   1 +
 drivers/iio/adc/mcp3911.c | 366 ++
 3 files changed, 377 insertions(+)
 create mode 100644 drivers/iio/adc/mcp3911.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 15606f237480..f9a41fa96fcc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -501,6 +501,16 @@ config MCP3422
  This driver can also be built as a module. If so, the module will be
  called mcp3422.
 
+config MCP3911
+   tristate "Microchip Technology MCP3911 driver"
+   depends on SPI
+   help
+ Say yes here to build support for Microchip Technology's MCP3911
+ analog to digital converter.
+
+ This driver can also be built as a module. If so, the module will be
+ called mcp3911.
+
 config MEDIATEK_MT6577_AUXADC
 tristate "MediaTek AUXADC driver"
 depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 28a9423997f3..3cfebfff7d26 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_MAX9611) += max9611.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
+obj-$(CONFIG_MCP3911) += mcp3911.o
 obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
 obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
new file mode 100644
index ..29aa39930ead
--- /dev/null
+++ b/drivers/iio/adc/mcp3911.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Microchip MCP3911, Two-channel Analog Front End
+ *
+ * Copyright (C) 2018 Marcus Folkesson 
+ * Copyright (C) 2018 Kent Gustavsson 
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCP3911_REG_CHANNEL0   0x00
+#define MCP3911_REG_CHANNEL1   0x03
+#define MCP3911_REG_MOD0x06
+#define MCP3911_REG_PHASE  0x07
+#define MCP3911_REG_GAIN   0x09
+
+#define MCP3911_REG_STATUSCOM  0x0a
+#define MCP3911_STATUSCOM_CH1_24WIDTH  BIT(4)
+#define MCP3911_STATUSCOM_CH0_24WIDTH  BIT(3)
+#define MCP3911_STATUSCOM_EN_OFFCALBIT(2)
+#define MCP3911_STATUSCOM_EN_GAINCAL   BIT(1)
+
+#define MCP3911_REG_CONFIG 0x0c
+#define MCP3911_CONFIG_CLKEXT  BIT(1)
+#define MCP3911_CONFIG_VREFEXT BIT(2)
+
+#define MCP3911_REG_OFFCAL_CH0 0x0e
+#define MCP3911_REG_GAINCAL_CH00x11
+#define MCP3911_REG_OFFCAL_CH1 0x14
+#define MCP3911_REG_GAINCAL_CH10x17
+#define MCP3911_REG_VREFCAL0x1a
+
+#define MCP3911_CHANNEL(x) (MCP3911_REG_CHANNEL0 + x * 3)
+#define MCP3911_OFFCAL(x)  (MCP3911_REG_OFFCAL_CH0 + x * 6)
+
+/* Internal voltage reference in uV */
+#define MCP3911_INT_VREF_UV120
+
+#define MCP3911_REG_READ(reg, id)  reg) << 1) | ((id) << 5) | (1 << 
0)) & 0xff)
+#define MCP3911_REG_WRITE(reg, id) reg) << 1) | ((id) << 5) | (0 << 
0)) & 0xff)
+
+#define MCP3911_NUM_CHANNELS   2
+
+struct mcp3911 {
+   struct spi_device *spi;
+   struct mutex lock;
+   struct regulator *vref;
+   struct clk *adc_clk;
+   u32 dev_addr;
+};
+
+static int mcp3911_read(struct mcp3911 *adc, u8 reg, u32 *val, u8 len)
+{
+   int ret;
+
+   reg = MCP3911_REG_READ(reg, adc->dev_addr);
+   ret = spi_write_then_read(adc->spi, , 1, val, len);
+   if (ret < 0)
+   return ret;
+
+   be32_to_cpus(val);
+   *val >>= ((4 - len) * 8);
+   dev_dbg(>spi->dev, "reading 0x%x from register 0x%x\n", *val,
+   reg>>1);
+   return ret;
+}
+
+static int mcp3911_write(struct mcp3911 *adc, u8 reg, u32 val, u8 len)
+{
+   dev_dbg(>spi->dev, "writing 0x%x to register 0x%x\n", val, reg);
+
+   val <<= (3 - len) * 8;
+   cpu_to_be32s();
+   val |= MCP3911_REG_WRITE(reg, adc->dev_addr);
+
+   return spi_write(adc->spi, , len+1);
+}
+
+static int mcp3911_update(struct mcp3911 *adc, u8 reg, u32 mask,
+   u32 val, u8 len)
+{
+   u32 tmp;
+   int ret;
+
+   ret = 

[PATCH v2 2/3] dt-bindings: iio: adc: add bindings for mcp3911

[Marcus Folkesson]

MCP3911 is a dual channel Analog Front End (AFE) containing two
synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).

Signed-off-by: Marcus Folkesson 
Signed-off-by: Kent Gustavsson 
---

Notes:
v2:
- drop channel width
- drop `external_vref`
- replace `external-clock` with proper clock bindings

 .../devicetree/bindings/iio/adc/mcp3911.txt| 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/mcp3911.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3911.txt 
b/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
new file mode 100644
index ..af5472f51a84
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
@@ -0,0 +1,28 @@
+* Microchip MCP3911 Dual channel analog front end (ADC)
+
+Required properties:
+ - compatible: Should be "microchip,mcp3911"
+ - reg: SPI chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+Documentation/devicetree/bindings/spi/spi-bus.txt.
+Max frequency for this chip is 20MHz.
+
+Optional properties:
+ - device-addr: Device address when multiple MCP3911 chips are present on the
+   same SPI bus. Valid values are 0-3. Defaults to 0.
+ - vref-supply: Phandle to the external reference voltage supply.
+ - clocks: Phandle and clock identifier (see clock-names)
+ - clock-names: "adc_clk" for the ADC (sampling) clock
+
+Example:
+adc@0 {
+   compatible = "microchip,mcp3911";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   device-addr = <0>;
+   vref-supply = <_reg>;
+   clocks = <>;
+   clock-names = "adc_clk";
+};
-- 
2.11.0.rc2

[PATCH v3] locking/rwsem: Exit read lock slowpath if queue empty & no writer

[Waiman Long]

It was discovered that a constant stream of readers with occassional
writers pounding on a rwsem may cause many of the readers to enter the
slowpath unnecessarily thus increasing latency and lowering performance.

In the current code, a reader entering the slowpath critical section
will unconditionally set the WAITING_BIAS, if not set yet, and clear
its active count even if no one is in the wait queue and no writer
is present. This causes some incoming readers to observe the presence
of waiters in the wait queue and hence have to go into the slowpath
themselves.

With sufficient numbers of readers and a relatively short lock hold time,
the WAITING_BIAS may be repeatedly turned on and off and a substantial
portion of the readers will go into the slowpath sustaining a rather
long queue in the wait queue spinlock and repeated WAITING_BIAS on/off
cycle until the logjam is broken opportunistically.

To avoid this situation from happening, an additional check is added to
detect the special case that the reader in the critical section is the
only one in the wait queue and no writer is present. When that happens,
it can just exit the slowpath and return immediately as its active count
has already been set in the lock.  Other incoming readers won't observe
the presence of waiters and so will not be forced into the slowpath.

The issue was found in a customer site where they had an application
that pounded on the pread64 syscalls heavily on an XFS filesystem. The
application was run in a recent 4-socket boxes with a lot of CPUs. They
saw significant spinlock contention in the rwsem_down_read_failed() call.
With this patch applied, the system CPU usage went down from 85% to 57%,
and the spinlock contention in the pread64 syscalls was gone.

v3: Revise the commit log and comment again.
v2: Add customer testing results and remove wording that may cause
confusion.

Signed-off-by: Waiman Long 
---
 kernel/locking/rwsem-xadd.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 3064c50..01fcb80 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -233,8 +233,19 @@ static void __rwsem_mark_wake(struct rw_semaphore *sem,
waiter.type = RWSEM_WAITING_FOR_READ;
 
raw_spin_lock_irq(>wait_lock);
-   if (list_empty(>wait_list))
+   if (list_empty(>wait_list)) {
+   /*
+* In case the wait queue is empty and the lock isn't owned
+* by a writer, this reader can exit the slowpath and return
+* immediately as its RWSEM_ACTIVE_READ_BIAS has already
+* been set in the count.
+*/
+   if (atomic_long_read(>count) >= 0) {
+   raw_spin_unlock_irq(>wait_lock);
+   return sem;
+   }
adjustment += RWSEM_WAITING_BIAS;
+   }
list_add_tail(, >wait_list);
 
/* we're now waiting on the lock, but no longer actively locking */
-- 
1.8.3.1

Re: [RFT v2 00/10] pinctrl: samsung: Remove ugly hack for sharing eint_wakeup_mask

[Krzysztof Kozlowski]

On Tue, Jul 24, 2018 at 11:18:13AM +0200, Marek Szyprowski wrote:
> Hi Krzysztof,
> 
> On 2018-07-23 19:52, Krzysztof Kozlowski wrote:
> > Hi All,
> >
> > Changes since v1
> > 
> > 1. Add Tomasz's ack.
> > 2. Reword description in patch 6/10.
> >
> >
> > Tests
> > =
> > This is both request for comments and requests for tests. Only basic
> > tests were done, including suspend to RAM on Odroid U3 (Exynos4412)
> > with max7768 RTC wakeup. Please kindly test it with devices capable of
> > suspending and resuming. I am mostly thinking about S5Pv210-based (Aria),
> > Trats, Trats2 and TM2 (Exynos5433). Existing platforms should not be
> > broken however changing external interrupt wakeup mask was not done
> > on Exynos5433.
> 
> Works fine on Exynos5433 TM2 with some additional patches related to
> suspend/resume handling of the PMU. It handles only EINT0..EINT31 pins
> for now. Exynos5433 has more external interrupt wakeup lines: EINT32-63
> located at banks GPF1[0..7], GPF2[0..3], GPF3[0..3], GPF4[0..7] and
> GPF5[0..7]. They can be configured as wakeup sources in
> EXYNOS5433_EINT_WAKEUP_MASK1 (0x062C) PMU register. Handling of them
> can be added later when it will be really needed.
> 
> Tested-by: Marek Szyprowski 

Thanks for comments and testing. Indeed support for Exynos5433 has to be
improved.

I would like to push 1-6 (which are needed for the rest) through current
cycle so I applied them to samsung-pinctrl tree.

Since anyway suspend to RAM is mostly broken nowadays... nothing more
should pop up.


Best regards,
Krzysztof

Re: [PATCH 20/20] signal: Don't restart fork when signals come in.

[Eric W. Biederman]

Linus Torvalds  writes:

> On Tue, Jul 24, 2018 at 10:58 AM Eric W. Biederman
>  wrote:
>>
>> Yes you are quite right.   Easy enough to fix, but it definitely needs
>> to be fixed.
>>
>> I will respin.
>
> Would you mind trying a slightly different approach for this?
>
> How about moving the "copy_signal()" and "copy_sighandler()" cases up
> to fairly early in the "copy_process()" function (and clean up late,
> obviously).
>
> Then, instead of that "struct multiprocess_signals" thing, just add a
> "struct hlist_node node" to "struct signal" itself, and add it to the
> multiprocess hlist there.
>
> And then you can just remove it in bad_fork_cleanup_signal.
>
> Does this make "struct signal" a bit larger? Yes, but it's not a huge
> deal. We *could* make is some union with existing fields if we cared.
>
> But I think it would make the code *much* more understandable, and it
> would allow us to not have that "sigpending" copy, because you can
> just populate the final "signal->shared_pending" directly.
>
> Hmm?

I don't like it.

What I hear you asking is  moving up copy_signal copy_sighand copy_creds
and alloc_pid, and anything else that signal delivery might depend on.

Then in send_signal running __send_signal in a loop first for the
forking process and then for every process that is currently in the
middle of fork.

It feels like this gets us much later in fork, and there is a lot more
code to move and review.   Which to some extent makes us more
susceptible to periodic signals, as more work will be thrown away and
have to be redone.  Plus it makes the whole thing susceptible to signal
delivery growing some additional dependency (perhaps cgroups?) and that
getting missed and never noticed until someone manages to time a sending
a signal just right.

I really want something very simple and straight forward because I don't
see us testing or hitting this code path much in practice.  Moving this
into the middle of fork and adding more depedencies does not seem like
it will be that kind of straight forward.

Eric

[PATCH v2] i2c: aspeed: Handle master/slave combined irq events properly

[Jae Hyun Yoo]

In most of cases, interrupt bits are set one by one but there are
also a lot of other cases that Aspeed I2C IP sends multiple
interrupt bits with combining master and slave events using a
single interrupt call. It happens much more in multi-master
environment than single-master. For an example, when master is
waiting for a NORMAL_STOP interrupt in its MASTER_STOP state,
SLAVE_MATCH and RX_DONE interrupts could come along with the
NORMAL_STOP in case of an another master immediately sends data
just after acquiring the bus. In this case, the NORMAL_STOP
interrupt should be handled by master_irq and the SLAVE_MATCH and
RX_DONE interrupts should be handled by slave_irq. This commit
modifies irq hadling logic to handle the master/slave combined
events properly.

Changes since v1:
- Fixed a grammer issue in commit message.
- Added a missing line feed character into a message printing.

Signed-off-by: Jae Hyun Yoo 
---
 drivers/i2c/busses/i2c-aspeed.c | 135 ++--
 1 file changed, 75 insertions(+), 60 deletions(-)

diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
index efb89422d496..75431e305073 100644
--- a/drivers/i2c/busses/i2c-aspeed.c
+++ b/drivers/i2c/busses/i2c-aspeed.c
@@ -82,6 +82,11 @@
 #define ASPEED_I2CD_INTR_RX_DONE   BIT(2)
 #define ASPEED_I2CD_INTR_TX_NAKBIT(1)
 #define ASPEED_I2CD_INTR_TX_ACKBIT(0)
+#define ASPEED_I2CD_INTR_ERRORS
   \
+   (ASPEED_I2CD_INTR_SDA_DL_TIMEOUT | \
+ASPEED_I2CD_INTR_SCL_TIMEOUT |\
+ASPEED_I2CD_INTR_ABNORMAL |   \
+ASPEED_I2CD_INTR_ARBIT_LOSS)
 #define ASPEED_I2CD_INTR_ALL  \
(ASPEED_I2CD_INTR_SDA_DL_TIMEOUT | \
 ASPEED_I2CD_INTR_BUS_RECOVER_DONE |   \
@@ -150,6 +155,7 @@ struct aspeed_i2c_bus {
int cmd_err;
/* Protected only by i2c_lock_bus */
int master_xfer_result;
+   u32 irq_status;
 #if IS_ENABLED(CONFIG_I2C_SLAVE)
struct i2c_client   *slave;
enum aspeed_i2c_slave_state slave_state;
@@ -229,36 +235,30 @@ static int aspeed_i2c_recover_bus(struct aspeed_i2c_bus 
*bus)
 #if IS_ENABLED(CONFIG_I2C_SLAVE)
 static bool aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus)
 {
-   u32 command, irq_status, status_ack = 0;
+   u32 command, status_ack = 0;
struct i2c_client *slave = bus->slave;
-   bool irq_handled = true;
u8 value;
 
-   if (!slave) {
-   irq_handled = false;
-   goto out;
-   }
+   if (!slave)
+   return false;
 
command = readl(bus->base + ASPEED_I2C_CMD_REG);
-   irq_status = readl(bus->base + ASPEED_I2C_INTR_STS_REG);
 
/* Slave was requested, restart state machine. */
-   if (irq_status & ASPEED_I2CD_INTR_SLAVE_MATCH) {
+   if (bus->irq_status & ASPEED_I2CD_INTR_SLAVE_MATCH) {
status_ack |= ASPEED_I2CD_INTR_SLAVE_MATCH;
bus->slave_state = ASPEED_I2C_SLAVE_START;
}
 
/* Slave is not currently active, irq was for someone else. */
-   if (bus->slave_state == ASPEED_I2C_SLAVE_STOP) {
-   irq_handled = false;
-   goto out;
-   }
+   if (bus->slave_state == ASPEED_I2C_SLAVE_STOP)
+   return false;
 
dev_dbg(bus->dev, "slave irq status 0x%08x, cmd 0x%08x\n",
-   irq_status, command);
+   bus->irq_status, command);
 
/* Slave was sent something. */
-   if (irq_status & ASPEED_I2CD_INTR_RX_DONE) {
+   if (bus->irq_status & ASPEED_I2CD_INTR_RX_DONE) {
value = readl(bus->base + ASPEED_I2C_BYTE_BUF_REG) >> 8;
/* Handle address frame. */
if (bus->slave_state == ASPEED_I2C_SLAVE_START) {
@@ -273,28 +273,29 @@ static bool aspeed_i2c_slave_irq(struct aspeed_i2c_bus 
*bus)
}
 
/* Slave was asked to stop. */
-   if (irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
+   if (bus->irq_status & ASPEED_I2CD_INTR_NORMAL_STOP) {
status_ack |= ASPEED_I2CD_INTR_NORMAL_STOP;
bus->slave_state = ASPEED_I2C_SLAVE_STOP;
}
-   if (irq_status & ASPEED_I2CD_INTR_TX_NAK) {
+   if (bus->irq_status & ASPEED_I2CD_INTR_TX_NAK) {
status_ack |= ASPEED_I2CD_INTR_TX_NAK;
bus->slave_state = ASPEED_I2C_SLAVE_STOP;
}
+   if (bus->irq_status & ASPEED_I2CD_INTR_TX_ACK) {
+   status_ack |= ASPEED_I2CD_INTR_TX_ACK;
+   }
 
switch (bus->slave_state) {
case 

Re: m68k allmodconfig build errors

[Andreas Schwab]

On Jul 23 2018, Randy Dunlap  wrote:

> I don't see that all of these string compare fields are null-terminated.

That gcc has converted the strncmp calls to strcmp is a pretty strong
evidence that they are.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCHv3 0/3] Fix crash due to vma_is_anonymous() false-positives

[Linus Torvalds]

On Tue, Jul 24, 2018 at 5:11 AM Kirill A. Shutemov
 wrote:
>
> Fix crash found by syzkaller.
>
> Build on top of Linus' changes in 4.18-rc6.
>
> Andrew, could you please drop mm-drop-unneeded-vm_ops-checks-v2.patch for
> now. Infiniband drivers have to be fixed first.

Ack, these look good to me.

We still need to have the rdma people fix up their vma mis-use, but
that's a related, but independent issue.

 Linus

Re: [PATCH v6 0/2] Input: Add Cypress Gen5 Touchscreen driver

[Dmitry Torokhov]

Hi Mylène,

On Tue, Jul 24, 2018 at 03:00:46PM +0200, Mylène Josserand wrote:
> Hello Dmitry,
> 
> On Wed, 4 Jul 2018 16:21:58 +
> Dmitry Torokhov  wrote:
> 
> > Hi Mylène,
> > 
> > On Tue, Jul 03, 2018 at 11:43:07AM +0200, Mylène Josserand wrote:
> > > Hello,
> > > 
> > > Here is a V6 series to add the driver of the touchscreen Cypress,
> > > TrueTouch Generation 5.
> > > Based on v4.18-rc3.
> > > 
> > > This patch series has already been posted in several iterations:
> > > - v1: Sent on 2017/05/29
> > > - v2: Sent on 2017/08/18
> > > - v3: Sent on 2017/09/27
> > > - v4: Sent on 2017/12/01
> > > - v5: Sent on 2017/12/20
> > > 
> > > I did not have any comments the last 4 versions.
> > > And no reviews on my v5 during 6 months. Could I have any updates
> > > or feedback on my series to know why it is not merged (to be able to
> > > correct what is wrong)?  
> > 
> > Sorry, I must have missed the v5, sorry about that.
> > 
> > I probably asked this question before, but just to make sure - I see
> > references to HID in the patch - the device is really not HID
> > compatible? Is there any hope it could be made work with i2c-hid +
> > hid-multitouch?
> > 
> > Thanks.
> > 
> 
> I have checked and, for what I have seen, all the HID descriptor stuff
> is HID compliant. We could definitely use i2c-hid and hid-multitouch
> (there is the "hid-cypress" driver that exists also).
> 
> The only problem is that this touchscreen has two modes: a bootloader
> mode and an application mode (which is the one where we can send
> HID commands). After a power-on-reset, it is always in "bootloader"
> mode so we need to send some commands (called "bootloader commands") to
> switch to application mode.

Is this a documented or observed behavior? In my practice devices (I am
talking in general, not about Cypress) that have proper configuration
loaded and that were brought up with appropriate power up sequence and
timings automatically switch to application mode. They only end up in
bootloader mode when proper power up sequence is not respected and they
are unhappy.

> These commands are not HID-compliant as the
> datasheet indicates:
> 
> "Bootloader commands are not HID-over-I2C compliant."

Any chance you could share the datasheet?

> 
> I think that if the touchscreen would start directly in "application"
> mode, we could directly use i2c-hid and hid-cypress drivers.
> Unfortunately, this is not the case.
> 
> In bootloader mode, the ProductID is 0xc101 and in application mode, it
> is 0xc001 (already available in hid-ids.h:
> USB_DEVICE_ID_CYPRESS_TRUETOUCH but not handled)
> 
> What would be the better approach here?
> Should I add a new product ID to detect the bootloader mode in
> hid-cypress driver and send non-HID commands to switch to
> "application" mode in this driver?
> Anyway, I guess that I will drop this cyttsp5 driver and update the
> existing one, right?

So it still accessible through HID, even when in bootloader mode? OK,
then I guess there are 2 options:

- if device is documented to always start in bootloader mode, you could
  have a small stub driver that switches it into application mode in its
  probe() code. The "bootloader" device will disappear and
  "application" device will appear, and standard driver (hid-multitouch)
  will bind to it.

- if device supposed to come up in application mode unless configuration
  is damaged: I'd recommend doing what we do on Chrome OS and have some
  userspace software that runs on boot (or whenever device is
  discovered) and check if it has the latest firmware/configuration, and
  repair device if needed.

Thanks.

-- 
Dmitry

Re: [RFC v5 PATCH 2/2] mm: mmap: zap pages with read mmap_sem in munmap

[Yang Shi]

+static int vm_munmap_zap_rlock(unsigned long start, size_t len)
+{
+    int ret;
+    struct mm_struct *mm = current->mm;
+    LIST_HEAD(uf);
+
+    ret = do_munmap_zap_rlock(mm, start, len, );
+    userfaultfd_unmap_complete(mm, );
+    return ret;
+}
+
   int vm_munmap(unsigned long start, size_t len)
   {
   int ret;

A stupid question, since the overhead of vm_munmap_zap_rlock() compared to
vm_munmap() is not significant, why not putting that in vm_munmap() instead of
introducing a new vm_munmap_zap_rlock() ?

Since vm_munmap() is called in other paths too, i.e. drm driver, kvm, etc. I'm
not quite sure if those paths are safe enough to this optimization. And, it
looks they are not the main sources of the latency, so here I introduced
vm_munmap_zap_rlock() for munmap() only.

For my information, what could be unsafe for these paths ?


I'm just not sure if they are safe enough nor not, because I'm not 
knowledgeable enough to kvm and drm drivers. They might be safe, but I 
don't know how to prove that.


So, since they might be not the main sources of latency (I haven't seen 
any hung report due to them), so it sounds safe to not touch them for now.





If someone reports or we see they are the sources of latency too, and the
optimization is proved safe to them, we can definitely extend this to all
vm_munmap() calls

Thanks,
Yang


@@ -2855,10 +2939,9 @@ int vm_munmap(unsigned long start, size_t len)
   SYSCALL_DEFINE2(munmap, unsigned long, addr, size_t, len)
   {
   profile_munmap(addr);
-    return vm_munmap(addr, len);
+    return vm_munmap_zap_rlock(addr, len);
   }

-
   /*
    * Emulation of deprecated remap_file_pages() syscall.
    */
@@ -3146,7 +3229,7 @@ void exit_mmap(struct mm_struct *mm)
   tlb_gather_mmu(, mm, 0, -1);
   /* update_hiwater_rss(mm) here? but nobody should be looking */
   /* Use -1 here to ensure all VMAs in the mm are unmapped */
-    unmap_vmas(, vma, 0, -1);
+    unmap_vmas(, vma, 0, -1, false);
   free_pgtables(, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
   tlb_finish_mmu(, 0, -1);

[PATCH] delayacct: Fix crash in delayacct_blkio_end() after delayacct init failure

[Tejun Heo]

While forking, if delayacct init fails due to memory shortage, it
continues expecting all delayacct users to check task->delays pointer
against NULL before dereferencing it, which all of them used to do.

c96f5471ce7d ("delayacct: Account blkio completion on the correct
task"), while updating delayacct_blkio_end() to take the target task
instead of always using %current, made the function test NULL on
%current->delays and then continue to operated on @p->delays.  If
%current succeeded init while @p didn't, it leads to the following
crash.

 BUG: unable to handle kernel NULL pointer dereference at 0004
 IP: __delayacct_blkio_end+0xc/0x40
 PGD 801fd07e1067 P4D 801fd07e1067 PUD 1fcffbb067 PMD 0 
 Oops:  [#1] SMP PTI
 CPU: 4 PID: 25774 Comm: QIOThread0 Not tainted 
4.16.0-9_fbk1_rc2_1180_g6b593215b4d7 #9
 Hardware name: Quanta Leopard ORv2-DDR4/Leopard ORv2-DDR4, BIOS F06_3B12 
08/17/2017
 RIP: 0010:__delayacct_blkio_end+0xc/0x40
 RSP: :881fff703bf8 EFLAGS: 00010086
 RAX: 881f1ec8b800 RBX: 8804f735cd54 RCX: 881fff703cb0
 RDX: 0002 RSI: 0003 RDI: 
 RBP:  R08:  R09: 881fff703cc0
 R10: 1000 R11: 881fd3f73d00 R12: 8804f735c600
 R13:  R14: 001d R15: 881fff703cb0
 FS:  7f5003f7d700() GS:881fff70() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 0004 CR3: 001f401a6006 CR4: 003606e0
 DR0:  DR1:  DR2: 
 DR3:  DR6: fffe0ff0 DR7: 0400
 Call Trace:
  
  try_to_wake_up+0x2c0/0x600
  autoremove_wake_function+0xe/0x30
  __wake_up_common+0x74/0x120
  wake_up_page_bit+0x9c/0xe0
  mpage_end_io+0x27/0x70
  blk_update_request+0x78/0x2c0
  scsi_end_request+0x2c/0x1e0
  scsi_io_completion+0x20b/0x5f0
  blk_mq_complete_request+0xa2/0x100
  ata_scsi_qc_complete+0x79/0x400
  ata_qc_complete_multiple+0x86/0xd0
  ahci_handle_port_interrupt+0xc9/0x5c0
  ahci_handle_port_intr+0x54/0xb0
  ahci_single_level_irq_intr+0x3b/0x60
  __handle_irq_event_percpu+0x43/0x190
  handle_irq_event_percpu+0x20/0x50
  handle_irq_event+0x2a/0x50
  handle_edge_irq+0x80/0x1c0
  handle_irq+0xaf/0x120
  do_IRQ+0x41/0xc0
  common_interrupt+0xf/0xf
  

Fix it by updating delayacct_blkio_end() check @p->delays instead.

Signed-off-by: Tejun Heo 
Reported-and-debugged-by: Dave Jones 
Cc: Josh Snyder 
Fixes: c96f5471ce7d ("delayacct: Account blkio completion on the correct task")
Cc: sta...@vger.kernel.org # v4.15+
---
 include/linux/delayacct.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/delayacct.h b/include/linux/delayacct.h
index e6c0448ebcc7..31c865d1842e 100644
--- a/include/linux/delayacct.h
+++ b/include/linux/delayacct.h
@@ -124,7 +124,7 @@ static inline void delayacct_blkio_start(void)
 
 static inline void delayacct_blkio_end(struct task_struct *p)
 {
-   if (current->delays)
+   if (p->delays)
__delayacct_blkio_end(p);
delayacct_clear_flag(DELAYACCT_PF_BLKIO);
 }

[PATCH 02/10] um: cleanup Kconfig files

[Christoph Hellwig]

We can handle all not architecture specific UM configuration directly in
the newly added arch/um/Kconfig.  Do so by merging the Kconfig.common,
Kconfig.rest and Kconfig.um files into arch/um/Kconfig, and move the main
UML menu as well.

Signed-off-by: Christoph Hellwig 
Acked-by: Richard Weinberger 
---
 arch/um/Kconfig| 210 +
 arch/um/Kconfig.common |  60 
 arch/um/Kconfig.rest   |  22 -
 arch/um/Kconfig.um | 124 
 arch/x86/um/Kconfig|  10 --
 5 files changed, 210 insertions(+), 216 deletions(-)
 delete mode 100644 arch/um/Kconfig.common
 delete mode 100644 arch/um/Kconfig.rest
 delete mode 100644 arch/um/Kconfig.um

diff --git a/arch/um/Kconfig b/arch/um/Kconfig
index 24607af202dc..1f605a7281cc 100644
--- a/arch/um/Kconfig
+++ b/arch/um/Kconfig
@@ -1,3 +1,213 @@
 # SPDX-License-Identifier: GPL-2.0
 
+menu "UML-specific options"
+
+config UML
+   bool
+   default y
+   select ARCH_HAS_KCOV
+   select HAVE_ARCH_AUDITSYSCALL
+   select HAVE_ARCH_SECCOMP_FILTER
+   select HAVE_UID16
+   select HAVE_FUTEX_CMPXCHG if FUTEX
+   select HAVE_DEBUG_KMEMLEAK
+   select GENERIC_IRQ_SHOW
+   select GENERIC_CPU_DEVICES
+   select GENERIC_CLOCKEVENTS
+   select HAVE_GCC_PLUGINS
+   select TTY # Needed for line.c
+
+config MMU
+   bool
+   default y
+
+config NO_IOMEM
+   def_bool y
+
+config ISA
+   bool
+
+config SBUS
+   bool
+
+config PCI
+   bool
+
+config PCMCIA
+   bool
+
+config TRACE_IRQFLAGS_SUPPORT
+   bool
+   default y
+
+config LOCKDEP_SUPPORT
+   bool
+   default y
+
+config STACKTRACE_SUPPORT
+   bool
+   default y
+   select STACKTRACE
+
+config GENERIC_CALIBRATE_DELAY
+   bool
+   default y
+
+config HZ
+   int
+   default 100
+
+config NR_CPUS
+   int
+   range 1 1
+   default 1
+
 source "arch/$(SUBARCH)/um/Kconfig"
+
+config STATIC_LINK
+   bool "Force a static link"
+   default n
+   help
+ This option gives you the ability to force a static link of UML.
+ Normally, UML is linked as a shared binary.  This is inconvenient for
+ use in a chroot jail.  So, if you intend to run UML inside a chroot,
+ you probably want to say Y here.
+ Additionally, this option enables using higher memory spaces (up to
+ 2.75G) for UML.
+
+source "mm/Kconfig"
+
+config LD_SCRIPT_STATIC
+   bool
+   default y
+   depends on STATIC_LINK
+
+config LD_SCRIPT_DYN
+   bool
+   default y
+   depends on !LD_SCRIPT_STATIC
+select MODULE_REL_CRCS if MODVERSIONS
+
+source "fs/Kconfig.binfmt"
+
+config HOSTFS
+   tristate "Host filesystem"
+   help
+  While the User-Mode Linux port uses its own root file system for
+  booting and normal file access, this module lets the UML user
+  access files stored on the host.  It does not require any
+  network connection between the Host and UML.  An example use of
+  this might be:
+
+  mount none /tmp/fromhost -t hostfs -o /tmp/umlshare
+
+  where /tmp/fromhost is an empty directory inside UML and
+  /tmp/umlshare is a directory on the host with files the UML user
+  wishes to access.
+
+  For more information, see
+  .
+
+  If you'd like to be able to work with files stored on the host,
+  say Y or M here; otherwise say N.
+
+config MCONSOLE
+   bool "Management console"
+   depends on PROC_FS
+   default y
+   help
+  The user mode linux management console is a low-level interface to
+  the kernel, somewhat like the i386 SysRq interface.  Since there is
+  a full-blown operating system running under every user mode linux
+  instance, there is much greater flexibility possible than with the
+  SysRq mechanism.
+
+  If you answer 'Y' to this option, to use this feature, you need the
+  mconsole client (called uml_mconsole) which is present in CVS in
+  2.4.5-9um and later (path /tools/mconsole), and is also in the
+  distribution RPM package in 2.4.6 and later.
+
+  It is safe to say 'Y' here.
+
+config MAGIC_SYSRQ
+   bool "Magic SysRq key"
+   depends on MCONSOLE
+   help
+ If you say Y here, you will have some control over the system even
+ if the system crashes for example during kernel debugging (e.g., you
+ will be able to flush the buffer cache to disk, reboot the system
+ immediately or dump some status information). A key for each of the
+ possible requests is provided.
+
+ This is the feature normally accomplished by pressing a key
+ while holding SysRq (Alt+PrintScreen).
+
+ On UML, this is accomplished by sending a "sysrq" command 

[PATCH 01/10] um: stop abusing KBUILD_KCONFIG

[Christoph Hellwig]

Instead create a arch/um/Kconfig file that just includes the actual
per-arch Kconfig file.

Signed-off-by: Christoph Hellwig 
Acked-by: Richard Weinberger 
---
 arch/um/Kconfig | 3 +++
 arch/um/Makefile| 2 --
 arch/x86/um/Kconfig | 5 -
 3 files changed, 3 insertions(+), 7 deletions(-)
 create mode 100644 arch/um/Kconfig

diff --git a/arch/um/Kconfig b/arch/um/Kconfig
new file mode 100644
index ..24607af202dc
--- /dev/null
+++ b/arch/um/Kconfig
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+source "arch/$(SUBARCH)/um/Kconfig"
diff --git a/arch/um/Makefile b/arch/um/Makefile
index e54dda8a0363..0207f6316d71 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -113,8 +113,6 @@ define archhelp
   echo '  find in the kernel root.'
 endef
 
-KBUILD_KCONFIG := $(HOST_DIR)/um/Kconfig
-
 archheaders:
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-generic \
kbuild-file=$(HOST_DIR)/include/asm/Kbuild \
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index 9d529f22fd9d..7e509c83d80d 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -1,9 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
-mainmenu "User Mode Linux/$(SUBARCH) $(KERNELVERSION) Kernel Configuration"
-
-comment "Compiler: $(CC_VERSION_TEXT)"
-
-source "scripts/Kconfig.include"
 
 source "arch/um/Kconfig.common"
 
-- 
2.18.0

Re: VM boot failure on nodes not having DMA32 zone

[Paolo Bonzini]

On 24/07/2018 09:53, Liang C wrote:
> Hi,
> 
> We have a situation where our qemu processes need to be launched under
> cgroup cpuset.mems control. This introduces an similar issue that was
> discussed a few years ago. The difference here is that for our case,
> not being able to allocate from DMA32 zone is a result a cgroup
> restriction not mempolicy enforcement. Here is the steps to reproduce
> the failure,
> 
> mkdir /sys/fs/cgroup/cpuset/nodeX (where X is a node not having DMA32 zone)
> echo X > /sys/fs/cgroup/cpuset/nodeX/cpuset.mems
> echo X > /sys/fs/cgroup/cpuset/nodeX/cpuset.cpus
> echo 1 > /sys/fs/cgroup/cpuset/node0/cpuset.mem_hardwall
> echo $$ > /sys/fs/cgroup/cpuset/nodeX/tasks
> 
> #launch a virtual machine
> kvm_init_vcpu failed: Cannot allocate memory
> 
> There are workarounds, like always putting qemu processes onto the
> node with DMA32 zone or not restricting qemu processes memory
> allocation until that DMA32 alloc finishes (difficult to be precise).
> But we would like to find a way to address the root cause.
> 
> Considering the fact that the pae_root shadow should not be needed
> when ept is in use, which is indeed our case - ept is always available
> for us (guessing this is the same case for most of other users), we
> made a patch roughly like this,
> 
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index d594690..1d1b61e 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -5052,7 +5052,7 @@ int kvm_mmu_create(struct kvm_vcpu *vcpu)
> vcpu->arch.mmu.translate_gpa = translate_gpa;
> vcpu->arch.nested_mmu.translate_gpa = translate_nested_gpa;
> 
> -   return alloc_mmu_pages(vcpu);
> +   return tdp_enabled ? 0 : alloc_mmu_pages(vcpu);
>  }
> 
>  void kvm_mmu_setup(struct kvm_vcpu *vcpu)
> 
> 
> It works through our test cases. But we would really like to have your
> insight on this patch before applying it in production environment and
> contributing it back to the community. Thanks in advance for any help
> you may provide!

Yes, this looks good.  However, I'd place the "if" in alloc_mmu_pages
itself.

Thanks,

Paolo

Re: [PATCH] input: pxrc - do not store USB device in private struct

[Marcus Folkesson]

Hello Dmitry,

On Tue, Jul 24, 2018 at 02:38:04AM +, Dmitry Torokhov wrote:
> Hi Marcus,
> 
> On Mon, Jul 16, 2018 at 04:40:14PM +0200, Marcus Folkesson wrote:
> > The USB device is only needed during setup, so put it back after
> > initialization and do not store it in our private struct.
> > 
> > Also, the USB device is a parent of USB interface so our driver
> > model rules ensure that USB device should not disappear while
> > interface device is still there.
> > So not keep a refcount on the device is safe.
> > 
> > Reported-by: Alexey Khoroshilov 
> > Signed-off-by: Marcus Folkesson 
> > ---
> >  drivers/input/joystick/pxrc.c | 22 --
> >  1 file changed, 12 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/input/joystick/pxrc.c b/drivers/input/joystick/pxrc.c
> > index 07a0dbd3ced2..46a7acb747bf 100644
> > --- a/drivers/input/joystick/pxrc.c
> > +++ b/drivers/input/joystick/pxrc.c
> ...
> 
> > @@ -204,23 +204,25 @@ static int pxrc_probe(struct usb_interface *intf,
> > return -ENOMEM;
> >  
> > mutex_init(>pm_mutex);
> > -   pxrc->udev = usb_get_dev(interface_to_usbdev(intf));
> > +   udev = usb_get_dev(interface_to_usbdev(intf));
> 
> There is really no need to "get" device for the probe duration, or in
> general, when you are not storing the reference to it.
> 
> I posted series with an updated version of this patch plus couple more
> cleanups/fixes, and would appreciate if you could give it a spin.

Thank you for doing this.

I have reviewed the patchset and tested on real hardware, and it looks good
to me.

For what it's worth:

Reviewed-by: Marcus Folkesson 
Tested-by: Marcus Folkesson  

On the whole patchset.

> 
> Thanks.
> 
> -- 
> Dmitry

Best regards
Marcus Folkesson


signature.asc
Description: PGP signature

Re: [PATCH] ARM: dma-mapping: always clear allocated buffers

[Christoph Hellwig]

On Tue, Jul 24, 2018 at 10:04:35PM +0800, YueHaibing wrote:
> Sean Wang report dma_zalloc_coherent doesn't work as expect on his
> armv7,the allocated mem is not zeroed.The reason is __alloc_from_pool
> doesn't honor __GFP_ZERO.

Please explain the "why" a little more.  All the explanations are in
the referenced arm64 commit and should be mentioned here as well.

Re: + mm-proc-pid-maps-remove-is_pid-and-related-wrappers.patch added to -mm tree

[Alexey Dobriyan]

On Mon, Jul 23, 2018 at 04:55:40PM -0700, a...@linux-foundation.org wrote:
> 
> The patch titled
>  Subject: mm: /proc/pid/*maps remove is_pid and related wrappers
> has been added to the -mm tree.  Its filename is
>  mm-proc-pid-maps-remove-is_pid-and-related-wrappers.patch

Reviewed-by: Alexey Dobriyan 

Re: [PATCH v2 4/8] NTB: ntb_pingpong: Choose doorbells based on port number

[Logan Gunthorpe]

On 24/07/18 12:12 PM, Allen Hubbe wrote:
> On Tue, Jul 24, 2018 at 1:37 PM Logan Gunthorpe  wrote:
>> Not really. Given that we know there are only two peers, we always use
>> the other side's doorbell register. You'd only use the nearby doorbell
>> register if you wanted to trigger your own interrupt -- that would be
>> weird and we don't really have the API sophistication to do that.
>>
>> If we wanted to support multiple peers with some number in crosslink
>> then we'd need to revamp things _significantly_. In this case we'd have
>> multiple doorbell registers which each apply to a different subset of
>> peers. This gets _very_ complicated and hurts my head.
> 
> ...huh, looks like peer index was omitted from ntb_peer_db_set and
> friends.  Adding peer index there would make the interface consistent
> with other ntb_peer functions.  Peer index would allow the hw driver
> to select which doorbell register to use for each peer.  Adding a
> ntb_peer_db_valid_bits to that would allow a subset of bits in the
> shared register to be associated with each peer.

The way the switch hardware works (switchtec and I assume IDT) is that
there is only one doorbell register for all peers which can trigger any
peer that doesn't have the corresponding bit masked. So the way it was
designed without the index maxes sense except when we start to add
multi-peer crosslink insanity. I don't think adding a peer index would
be sufficient as the clients would need to know which peers share which
doorbells.

If I were to attempt something like this, I'd probably look at
introducing a segment index to the entire API. So that each switch in a
crosslink topology is it's own segment with it's own set of peers, peer
index space, doorbell registers, etc. But that's all very complicated
and messy and probably something I wouldn't even look at until we have
finished with traditional multi-host setups.

> I thought for sure ntb_peer_db_set already had peer index, and I was
> wrong.  Go ahead with the change as in your patch, I won't force the
> issue or that you to do that extra work and touch all the drivers
> again for this.  It can be addressed when there is renued interest in
> making things work more than one peer.
> 
> This patch, and the others in this series:
> Acked-by: Allen Hubbe 

Thanks!

Logan

Re: [PATCH] EDAC, sb_edac: Fix out of bound in PCI multi segment env

[Masayoshi Mizuma]

Hi Tony,

Thank you for your review!

On 07/24/2018 01:01 PM, Tony Luck wrote:
> On Thu, Jul 19, 2018 at 7:07 AM, Masayoshi Mizuma  
> wrote:
>> From: Masayoshi Mizuma 
>>
>> KASAN reported the following slab-out-of-bounds when sb_edac
>> module was loaded on Broadwell machine which has two PCI segments.
> 
> Although you found this with KASAN as an out of bounds array reference,
> the real problem is that the sb_edac.c driver didn't know about systems
> with segmented PCI busses.
> 
> So the Subject: for the e-mail (and thus the commit message) should
> be:
> 
> [PATCH] EDAC, sb_edac: Add support for systems with segmented PCI busses

You are right. I will modify the subject and commit message, and resend it.

> 
> Otherwise this looks fine.
> 
> Reviewed-by: Tony Luck 

Thanks!
Masa

> 
> -Tony
> 

[PATCH] Input: stop telling users to snail-mail Vojtech

[Dmitry Torokhov]

I do not think Vojtech wants snail mail these days, even if the
address were correct (I do not know if it is), so let's remove
snail-mail instructions from the sources.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/evbug.c  | 4 
 drivers/input/gameport/emu10k1-gp.c| 4 
 drivers/input/gameport/lightning.c | 4 
 drivers/input/gameport/ns558.c | 4 
 drivers/input/joystick/a3d.c   | 4 
 drivers/input/joystick/adi.c   | 4 
 drivers/input/joystick/amijoy.c| 4 
 drivers/input/joystick/analog.c| 4 
 drivers/input/joystick/cobra.c | 4 
 drivers/input/joystick/db9.c   | 4 
 drivers/input/joystick/gamecon.c   | 4 
 drivers/input/joystick/gf2k.c  | 4 
 drivers/input/joystick/grip.c  | 4 
 drivers/input/joystick/guillemot.c | 4 
 drivers/input/joystick/iforce/iforce-ff.c  | 4 
 drivers/input/joystick/iforce/iforce-main.c| 4 
 drivers/input/joystick/iforce/iforce-packets.c | 4 
 drivers/input/joystick/iforce/iforce-serio.c   | 4 
 drivers/input/joystick/iforce/iforce-usb.c | 4 
 drivers/input/joystick/iforce/iforce.h | 4 
 drivers/input/joystick/interact.c  | 4 
 drivers/input/joystick/joydump.c   | 4 
 drivers/input/joystick/magellan.c  | 4 
 drivers/input/joystick/sidewinder.c| 4 
 drivers/input/joystick/spaceball.c | 4 
 drivers/input/joystick/spaceorb.c  | 4 
 drivers/input/joystick/stinger.c   | 4 
 drivers/input/joystick/tmdc.c  | 4 
 drivers/input/joystick/turbografx.c| 4 
 drivers/input/joystick/warrior.c   | 4 
 drivers/input/keyboard/amikbd.c| 4 
 drivers/input/keyboard/atakbd.c| 4 
 drivers/input/keyboard/newtonkbd.c | 4 
 drivers/input/keyboard/stowaway.c  | 4 
 drivers/input/keyboard/sunkbd.c| 4 
 drivers/input/keyboard/xtkbd.c | 4 
 drivers/input/mouse/inport.c   | 4 
 drivers/input/mouse/logibm.c   | 4 
 drivers/input/mouse/pc110pad.c | 4 
 drivers/input/mouse/sermouse.c | 4 
 drivers/input/serio/ct82c710.c | 4 
 drivers/input/serio/q40kbd.c   | 4 
 drivers/input/serio/rpckbd.c   | 4 
 drivers/input/serio/serio.c| 4 
 drivers/input/touchscreen/gunze.c  | 4 
 include/linux/joystick.h   | 4 
 include/uapi/linux/joystick.h  | 4 
 47 files changed, 188 deletions(-)

diff --git a/drivers/input/evbug.c b/drivers/input/evbug.c
index cd4e6679d61a..5419c1c1f621 100644
--- a/drivers/input/evbug.c
+++ b/drivers/input/evbug.c
@@ -20,10 +20,6 @@
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- * Should you need to contact me, the author, you can do so either by
- * e-mail - mail your message to , or by paper mail:
- * Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
diff --git a/drivers/input/gameport/emu10k1-gp.c 
b/drivers/input/gameport/emu10k1-gp.c
index 2909e9561cf3..afdc20ca0e24 100644
--- a/drivers/input/gameport/emu10k1-gp.c
+++ b/drivers/input/gameport/emu10k1-gp.c
@@ -20,10 +20,6 @@
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- * Should you need to contact me, the author, you can do so either by
- * e-mail - mail your message to , or by paper mail:
- * Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
  */
 
 #include 
diff --git a/drivers/input/gameport/lightning.c 
b/drivers/input/gameport/lightning.c
index 85d6ee09f11f..c6e74c7945cb 100644
--- a/drivers/input/gameport/lightning.c
+++ b/drivers/input/gameport/lightning.c
@@ -20,10 +20,6 @@
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- * Should you need to contact me, the author, you can do so either by
- * e-mail - mail your message to , or by paper mail:
- * Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
  */
 
 #include 
diff --git a/drivers/input/gameport/ns558.c b/drivers/input/gameport/ns558.c
index 7c217848613e..6437645858f9 100644
--- 

Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

[Brian Norris]

Hi Boris,

On Tue, Jul 24, 2018 at 01:18:11AM +0200, Boris Brezillon wrote:
> On Mon, 23 Jul 2018 15:06:43 -0700
> Brian Norris  wrote:
> > On Mon, Jul 23, 2018 at 1:10 PM, Boris Brezillon
> >  wrote:
> > > but it still seems to improve things. Of course, that means the
> > > user should try to re-route all HW reset sources to SW ones (RESET input
> > > pin muxed to the GPIO controller, watchdog generating an interrupt
> > > instead of directly asserting the RESET output pin), which is not always
> > > possible, but even when it's not, isn't it better to have a setup that
> > > works fine 99% of the time instead of 50% of the time?  
> > 
> > Perhaps, but not at the expense of future development. And
> > realistically, no one is doing that if they have this hack. Most
> > people won't even know that this hack is protecting them at all (so
> > again, they won't try to mitigate the problem any further).
> 
> Unless we add a huge backtrace at probe time which forces them to look
> closer at what they did wrong (like you seem to suggest below).

Sure, if we can force a huge backtrace, then maybe that's an acceptable
situation. I just predict that someday, somebody will argue that the
warning should be downgraded, since there's nothing the average user can
do about it. (Well, except not buying from that manufacturer in the
future.)

> > Or even better: put this hack behind a DT flag, so that one has to
> > admit that their board design is broken before it will even do
> > anything. Proposal: "linux,badly-designed-flash-reset".
> 
> I think we can remove the "linux," prefix. If it's badly designed, it
> applies to all OSes, don't you think?

Sure.

Shall I send a patch?

Brian

Re: [tip:x86/timers] sched/clock: Enable sched clock early

[Guenter Roeck]

Hi,

On Thu, Jul 19, 2018 at 03:33:21PM -0700, tip-bot for Pavel Tatashin wrote:
> Commit-ID:  857baa87b6422bcfb84ed3631d6839920cb5b09d
> Gitweb: 
> https://git.kernel.org/tip/857baa87b6422bcfb84ed3631d6839920cb5b09d
> Author: Pavel Tatashin 
> AuthorDate: Thu, 19 Jul 2018 16:55:42 -0400
> Committer:  Thomas Gleixner 
> CommitDate: Fri, 20 Jul 2018 00:02:43 +0200
> 
> sched/clock: Enable sched clock early
> 
> Allow sched_clock() to be used before schec_clock_init() is called.  This
> provides a way to get early boot timestamps on machines with unstable
> clocks.
> 

This patch causes a regression when running a qemu emulation with
arm:integratorcp.

...
Console: colour dummy device 80x30
[ cut here ]
WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:180
sched_clock_register+0x44/0x278
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc6-next-20180724 #1
Hardware name: ARM Integrator/CP (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x18)
[] (show_stack) from [] (dump_stack+0x18/0x24)
[] (dump_stack) from [] (__warn+0xc8/0xf0)
[] (__warn) from [] (warn_slowpath_null+0x3c/0x4c)
[] (warn_slowpath_null) from [] 
(sched_clock_register+0x44/0x278)
[] (sched_clock_register) from [] 
(generic_sched_clock_init+0x28/0x88)
[] (generic_sched_clock_init) from [] 
(sched_clock_init+0x54/0x74)
[] (sched_clock_init) from [] (start_kernel+0x310/0x3e4)
[] (start_kernel) from [<>] (  (null))
---[ end trace 08080eb81afa002c ]---
sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every 
2147483647500ns
...

A complete boot log is available at
http://kerneltests.org/builders/qemu-arm-next/builds/979/steps/qemubuildcommand/logs/stdio

Unfortunately, reverting the patch results in conflicts, so I am unable
to confirm that it is the only culprit.

>From the context and from looking into the patch, it appears that this
can happen in any system if CONFIG_HAVE_UNSTABLE_SCHED_CLOCK is not
enabled.

Bisect log is attached.

Guenter

---
# bad: [3946cd385042069ec57d3f04240def53b4eed7e5] Add linux-next specific files 
for 20180724
# good: [d72e90f33aa4709ebecc5005562f52335e106a60] Linux 4.18-rc6
git bisect start 'HEAD' 'v4.18-rc6'
# good: [f5fa891e325acf096c0f79e1d1b922002e251e5a] Merge remote-tracking branch 
'crypto/master'
git bisect good f5fa891e325acf096c0f79e1d1b922002e251e5a
# good: [cb6471f6bcfdacbeef9c23ba9dac00e67bd3c3a4] Merge remote-tracking branch 
'spi/for-next'
git bisect good cb6471f6bcfdacbeef9c23ba9dac00e67bd3c3a4
# bad: [6b5bfa57bf4553d051be65d85d021465041406d8] Merge remote-tracking branch 
'char-misc/char-misc-next'
git bisect bad 6b5bfa57bf4553d051be65d85d021465041406d8
# bad: [675a67e9ef3c041999f412cb75418d2b0def3854] Merge remote-tracking branch 
'rcu/rcu/next'
git bisect bad 675a67e9ef3c041999f412cb75418d2b0def3854
# good: [e78b01a51131f25fc2d881bc43001575c129069c] Merge branch 'perf/core'
git bisect good e78b01a51131f25fc2d881bc43001575c129069c
# good: [4e581bce514f4107ce84525f0f75f89c92b4140e] Merge branch 'x86/cpu'
git bisect good 4e581bce514f4107ce84525f0f75f89c92b4140e
# good: [20fa22e90e54e2d21cace7ba083598531670f7cf] Merge branch 'x86/pti'
git bisect good 20fa22e90e54e2d21cace7ba083598531670f7cf
# good: [4763f03d3d186ce8a1125844790152d76804ad60] x86/tsc: Use TSC as sched 
clock early
git bisect good 4763f03d3d186ce8a1125844790152d76804ad60
# good: [5f9ef44c7d1c59d0eda1d86e31d981bdffe2a725] tools/memory-model: Rename 
litmus tests to comply to norm7
git bisect good 5f9ef44c7d1c59d0eda1d86e31d981bdffe2a725
# bad: [fc3d25e1c8f6a9232530db02a1072033e22e0fe3] Merge branch 'x86/timers'
git bisect bad fc3d25e1c8f6a9232530db02a1072033e22e0fe3
# bad: [46457ea464f5341d1f9dad8dd213805d45f7f117] sched/clock: Use static key 
for sched_clock_running
git bisect bad 46457ea464f5341d1f9dad8dd213805d45f7f117
# bad: [857baa87b6422bcfb84ed3631d6839920cb5b09d] sched/clock: Enable sched 
clock early
git bisect bad 857baa87b6422bcfb84ed3631d6839920cb5b09d
# good: [5d2a4e91a541cb04d20d11602f0f9340291322ac] sched/clock: Move sched 
clock initialization and merge with generic clock
git bisect good 5d2a4e91a541cb04d20d11602f0f9340291322ac
# first bad commit: [857baa87b6422bcfb84ed3631d6839920cb5b09d] sched/clock: 
Enable sched clock early

Re: [PATCH] dt-bindings: thermal: samsung: Add SPDX license identifier

[Krzysztof Kozlowski]

On Tue, Jul 24, 2018 at 06:46:35PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Wednesday, July 18, 2018 10:02:50 PM Krzysztof Kozlowski wrote:
> > Replace GPL license statement with SPDX license identifier (GPL-2.0+).
> > 
> > Signed-off-by: Krzysztof Kozlowski 
> > ---
> >  include/dt-bindings/thermal/thermal_exynos.h | 12 +---
> >  1 file changed, 1 insertion(+), 11 deletions(-)
> > 
> > diff --git a/include/dt-bindings/thermal/thermal_exynos.h 
> > b/include/dt-bindings/thermal/thermal_exynos.h
> > index 0646500bca69..642e4e7f4084 100644
> > --- a/include/dt-bindings/thermal/thermal_exynos.h
> > +++ b/include/dt-bindings/thermal/thermal_exynos.h
> > @@ -1,19 +1,9 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> 
> This code should be GPL-2.0 only, original license statement is most
> likely result of using wrong file as the source of copy-paste. So I
> would like to have the license fixed first before doing conversion to
> SPDX.

If you think that's the case, then it makes sense and please go ahead.
As fair as I remember this required signed-off from all contributors...
so probably just Lukasz and Eduardo?

Best regards,
Krzysztof

Re: [PATCHv3 1/3] mm: Introduce vma_init()

[Andrew Morton]

On Tue, 24 Jul 2018 15:11:37 +0300 "Kirill A. Shutemov" 
 wrote:

> Not all VMAs allocated with vm_area_alloc(). Some of them allocated on
> stack or in data segment.
> 
> The new helper can be use to initialize VMA properly regardless where
> it was allocated.
> 
> ...
>
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -452,6 +452,12 @@ struct vm_operations_struct {
> unsigned long addr);
>  };
>  
> +static inline void vma_init(struct vm_area_struct *vma, struct mm_struct *mm)
> +{
> + vma->vm_mm = mm;
> + INIT_LIST_HEAD(>anon_vma_chain);
> +}
> +
>  struct mmu_gather;
>  struct inode;
>  
> diff --git a/kernel/fork.c b/kernel/fork.c
> index a191c05e757d..1b27babc4c78 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -312,10 +312,8 @@ struct vm_area_struct *vm_area_alloc(struct mm_struct 
> *mm)
>  {
>   struct vm_area_struct *vma = kmem_cache_zalloc(vm_area_cachep, 
> GFP_KERNEL);

I'd sleep better if this became a kmem_cache_alloc() and the memset
was moved into vma_init().  A bunch of the vma_init() callers are
already doing the memset and the others risk leaving uninitialized
stack fields in the vma.

>  
> - if (vma) {
> - vma->vm_mm = mm;
> - INIT_LIST_HEAD(>anon_vma_chain);
> - }
> + if (vma)
> + vma_init(vma, mm);
>   return vma;
>  }

[PATCH] tracefs: Annotate tracefs_ops with __ro_after_init

[Zubin Mithra]

tracefs_ops is initialized inside tracefs_create_instance_dir and not
modified after. tracefs_create_instance_dir allows for initialization
only once, and is called from create_trace_instances(marked __init),
which is called from tracer_init_tracefs(marked __init).

Signed-off-by: Zubin Mithra 
Reviewed-by: Kees Cook 
---
 fs/tracefs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index bea8ad876bf9..20e965873f27 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -53,7 +53,7 @@ static const struct file_operations tracefs_file_operations = 
{
 static struct tracefs_dir_ops {
int (*mkdir)(const char *name);
int (*rmdir)(const char *name);
-} tracefs_ops;
+} tracefs_ops __ro_after_init;
 
 static char *get_dname(struct dentry *dentry)
 {
-- 
2.18.0.233.g985f88cf7e-goog

Re: [PATCH v2 09/10] coresight: perf: Remove set_buffer call back

[Mathieu Poirier]

On Mon, 23 Jul 2018 at 16:27, Suzuki K Poulose  wrote:
>
> Mathieu,
>
> On 07/23/2018 07:22 PM, Mathieu Poirier wrote:
> > On Fri, 20 Jul 2018 at 03:04, Suzuki K Poulose  
> > wrote:
> >>
> >> Mathieu,
> >>
> >> On 19/07/18 21:36, Mathieu Poirier wrote:
> >>> On Tue, Jul 17, 2018 at 06:11:40PM +0100, Suzuki K Poulose wrote:
>  In coresight perf mode, we need to prepare the sink before
>  starting a session, which is done via set_buffer call back.
>  We then proceed to enable the tracing. If we fail to start
>  the session successfully, we leave the sink configuration
>  unchanged. This was fine for the existing backends as they
>  don't have any state associated with the buffers. But with
>  ETR, we need to keep track of the buffer details and need
>  to be cleaned up if we fail. In order to make the operation
>  atomic and to avoid yet another call back, we get rid of
>  the "set_buffer" call back and pass the buffer details
>  via enable() call back to the sink.
> >>>
> >>> Suzuki,
> >>>
> >>> I'm not sure I understand the problem you're trying to fix there.  From 
> >>> the
> >>> implementation of tmc_enable_etr_sink_perf() in the next patch, wouldn't 
> >>> the
> >>> same result been achievable using a callback?
> >>
> >> We can definitely achieve the results using "set_buffer". But for ETR,
> >> we track the "perf_buf" in drvdata->perf_data when we do "set_buffer".
> >> But if we failed to enable_path(), we leave the drvdata->perf_data
> >> and doesn't clean it up. Now when another session is about to set_buf,
> >> we check if perf_data is empty and WARNs otherwise.
> >> Because we can't be sure if it belongs to an abandoned session or
> >> another active session and we completely messed somewhere in the driver.
> >> So, we need a clear_buffer call back if the enable fails, something
> >> not really worth. Anyways, there is no point in separating set_buffer
> >> and enabling the sink, as the error handling becomes cumbersome as 
> >> explained
> >> above.
> >>
> >>>
> >>> I'm fine with this patch and supportive of getting rid of callbacks if we 
> >>> can, I
> >>> just need to understand the exact problem you're after.  From looking a 
> >>> your
> >>> code (and the current implementation), if we succeed in setting the 
> >>> memory for
> >>> the sink but fail in any of the subsequent steps i.e, enabling the rest 
> >>> of the
> >>> compoment on the path or the source, the sink is left unchanged.
> >>
> >> Yes, thats right. And we should WARN (which I missed in this version) if
> >> there is a perf_data already for a disabled ETR. Please see my response to 
> >> the
> >> next patch.
> >
> > The changelog for this patch states the following: "But with ETR, we
> > need to keep track of the buffer details and need to be cleaned up if
> > we fail."
> >
> > I did a deep dive in the code and in the current implementation if the
> > source fails to be enabled in etm_event_start() the path and the sink
> > remains unchanged.  With your patchset this get fixed because a goto
> > was added to disable the path when such condition occur.  As such each
> > component in the path will see its ->disable() callback invoked.  In
> > tmc_disable_etr_sink(), drvdata->perf_data is set to NULL in
> > tmc_etr_disable_hw(), so the cleanup on error condition is done
> > properly.  As such we wouldn't need a clean_buffer() callback.
>
> All of this is right. But we still have a case. e.g, if the ETR is
> enabled in sysfs mode, coresight_enable_path() will fail after we
> have set the buffer. And since we don't try to disable the path
> when we fail at SINK (which is the right thing to do, as we could
> be potentially disabling the ETR operated in sysfs mode), we leave
> the perf_data around. And the next session finds a non-empty data.

We are in total agreement :o)

All I hoping for is to see the sentence "But with ETR, we need to keep
track of the buffer details and need to be cleaned up if we fail."
removed from the changelog.  To me that sounds like you're adding
cleanup work in enable() which isn't the case.  On the flip side you
are making the sink configuration atomic and that is the important
part.

>
> >
> > As I said I'm in favour of removing the set_buffer() callback but I
> > wouldn't associated it with ETR state cleanup.  If the code can be
> > rearranged in a way that code can be removed then that alone is enough
> > to justify the change.
> >
> >>
>  diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
>  b/drivers/hwtracing/coresight/coresight-etm-perf.c
>  index 3cc4a0b..12a247d 100644
>  --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
>  +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
>  @@ -269,16 +269,11 @@ static void etm_event_start(struct perf_event 
>  *event, int flags)
>    path = etm_event_cpu_path(event_data, cpu);
>    /* We need a sink, no need to continue without one */
>    

Re: [RFC v5 PATCH 2/2] mm: mmap: zap pages with read mmap_sem in munmap

[Laurent Dufour]

On 24/07/2018 19:26, Yang Shi wrote:
> 
> 
> On 7/24/18 10:18 AM, Laurent Dufour wrote:
>> On 19/07/2018 01:21, Yang Shi wrote:
>>> When running some mmap/munmap scalability tests with large memory (i.e.
 300GB), the below hung task issue may happen occasionally.
>>> INFO: task ps:14018 blocked for more than 120 seconds.
>>>     Tainted: G    E 4.9.79-009.ali3000.alios7.x86_64 #1
>>>   "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
>>> message.
>>>   ps  D    0 14018  1 0x0004
>>>    885582f84000 885e8682f000 880972943000 885ebf499bc0
>>>    8828ee12 c900349bfca8 817154d0 0040
>>>    00ff812f872a 885ebf499bc0 024000d000948300 880972943000
>>>   Call Trace:
>>>    [] ? __schedule+0x250/0x730
>>>    [] schedule+0x36/0x80
>>>    [] rwsem_down_read_failed+0xf0/0x150
>>>    [] call_rwsem_down_read_failed+0x18/0x30
>>>    [] down_read+0x20/0x40
>>>    [] proc_pid_cmdline_read+0xd9/0x4e0
>>>    [] ? do_filp_open+0xa5/0x100
>>>    [] __vfs_read+0x37/0x150
>>>    [] ? security_file_permission+0x9b/0xc0
>>>    [] vfs_read+0x96/0x130
>>>    [] SyS_read+0x55/0xc0
>>>    [] entry_SYSCALL_64_fastpath+0x1a/0xc5
>>>
>>> It is because munmap holds mmap_sem exclusively from very beginning to
>>> all the way down to the end, and doesn't release it in the middle. When
>>> unmapping large mapping, it may take long time (take ~18 seconds to
>>> unmap 320GB mapping with every single page mapped on an idle machine).
>>>
>>> Zapping pages is the most time consuming part, according to the
>>> suggestion from Michal Hocko [1], zapping pages can be done with holding
>>> read mmap_sem, like what MADV_DONTNEED does. Then re-acquire write
>>> mmap_sem to cleanup vmas.
>>>
>>> But, some part may need write mmap_sem, for example, vma splitting. So,
>>> the design is as follows:
>>>  acquire write mmap_sem
>>>  lookup vmas (find and split vmas)
>>> detach vmas
>>>  deal with special mappings
>>>  downgrade_write
>>>
>>>  zap pages
>>> free page tables
>>>  release mmap_sem
>>>
>>> The vm events with read mmap_sem may come in during page zapping, but
>>> since vmas have been detached before, they, i.e. page fault, gup, etc,
>>> will not be able to find valid vma, then just return SIGSEGV or -EFAULT
>>> as expected.
>>>
>>> If the vma has VM_LOCKED | VM_HUGETLB | VM_PFNMAP or uprobe, they are
>>> considered as special mappings. They will be dealt with before zapping
>>> pages with write mmap_sem held. Basically, just update vm_flags.
>>>
>>> And, since they are also manipulated by unmap_single_vma() which is
>>> called by unmap_vma() with read mmap_sem held in this case, to
>>> prevent from updating vm_flags in read critical section, a new
>>> parameter, called "skip_flags" is added to unmap_region(), unmap_vmas()
>>> and unmap_single_vma(). If it is true, then just skip unmap those
>>> special mappings. Currently, the only place which pass true to this
>>> parameter is us.
>>>
>>> With this approach we don't have to re-acquire mmap_sem again to clean
>>> up vmas to avoid race window which might get the address space changed.
>>>
>>> And, since the lock acquire/release cost is managed to the minimum and
>>> almost as same as before, the optimization could be extended to any size
>>> of mapping without incuring significan penalty to small mappings.
>>   ^   ^
>>   incurring significant
> 
> Thanks for catching the typo.
> 
>>> For the time being, just do this in munmap syscall path. Other
>>> vm_munmap() or do_munmap() call sites (i.e mmap, mremap, etc) remain
>>> intact for stability reason.
>>>
>>> With the patches, exclusive mmap_sem hold time when munmap a 80GB
>>> address space on a machine with 32 cores of E5-2680 @ 2.70GHz dropped to
>>> us level from second.
>>>
>>> munmap_test-15002 [008]   594.380138: funcgraph_entry: | 
>>> vm_munmap_zap_rlock() {
>>> munmap_test-15002 [008]   594.380146: funcgraph_entry:  !2485684 us |   
>>> unmap_region();
>>> munmap_test-15002 [008]   596.865836: funcgraph_exit:   !2485692 us |  }
>>>
>>> Here the excution time of unmap_region() is used to evaluate the time of
>>> holding read mmap_sem, then the remaining time is used with holding
>>> exclusive lock.
>>>
>>> [1] https://lwn.net/Articles/753269/
>>>
>>> Suggested-by: Michal Hocko 
>>> Suggested-by: Kirill A. Shutemov 
>>> Cc: Matthew Wilcox 
>>> Cc: Laurent Dufour 
>>> Cc: Andrew Morton 
>>> Signed-off-by: Yang Shi 
>>> ---
>>>   include/linux/mm.h |  2 +-
>>>   mm/memory.c    | 35 +--
>>>   mm/mmap.c  | 99
>>> +-
>>>   3 files changed, 117 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index a0fbb9f..95a4e97 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -1321,7 

[PATCH v3 1/4] dt-bindings: PCI: dra7xx: Add bindings for unaligned access in host mode

[Vignesh R]

Update device tree binding documentation of TI's dra7xx PCI controller
for enabling unaligned mem access as applicable not just in EP mode but
in host mode as well.

Signed-off-by: Vignesh R 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 7f7af3044016..452fe48c4fdd 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -26,6 +26,11 @@ HOST MODE
ranges,
interrupt-map-mask,
interrupt-map : as specified in ../designware-pcie.txt
+ - ti,syscon-unaligned-access: phandle to the syscon DT node. The 1st argument
+  should contain the register offset within syscon
+  and the 2nd argument should contain the bit field
+  for setting the bit to enable unaligned
+  access.
 
 DEVICE MODE
 ===
-- 
2.18.0

Re: [PATCH] mips: use asm-generic version of msi.h

[Paul Burton]

Hi Thomas,

On Tue, Jul 24, 2018 at 01:52:08PM +0200, Thomas Petazzoni wrote:
> This is necessary to be able to include  when
> CONFIG_GENERIC_MSI_IRQ_DOMAIN is enabled. Without this, a build with
> CONFIG_GENERIC_MSI_IRQ_DOMAIN fails with:
> 
>In file included from include/linux/kvm_host.h:20:0,
> from arch/mips/kernel/asm-offsets.c:24:
> >> include/linux/msi.h:197:10: fatal error: asm/msi.h: No such file or 
> >> directory
> #include 
>  ^~~
>compilation terminated.
>make[2]: *** [arch/mips/kernel/asm-offsets.s] Error 1
>make[2]: Target '__build' not remade because of errors.
>make[1]: *** [prepare0] Error 2
>make[1]: Target 'prepare' not remade because of errors.
>make: *** [sub-make] Error 2
> 
> Signed-off-by: Thomas Petazzoni 
> ---
>  arch/mips/include/asm/Kbuild | 1 +
>  1 file changed, 1 insertion(+)

Thanks, applied to mips-next for 4.19.

BTW it looks like a bunch of other architectures might need this too - a
grep suggests more architectures lack asm/msi.h (17) than have it.

Paul

Re: [PATCH 20/20] signal: Don't restart fork when signals come in.

[Eric W. Biederman]

Linus Torvalds  writes:

> This is completely broken.
>
> On Mon, Jul 23, 2018 at 8:27 PM Eric W. Biederman  
> wrote:
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 6c358846a8b8..6ee5822f0085 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -1602,6 +1603,24 @@ static __latent_entropy struct task_struct 
>> *copy_process(
>>  {
>> int retval;
>> struct task_struct *p;
>> +   struct multiprocess_signals delayed;
>> +
>> +   /*
>> +* Force any signals received before this point to be delivered
>> +* before the fork happens.  Collect up signals sent to multiple
>> +* processes that happen during the fork and delay them so that
>> +* they appear to happen after the fork.
>> +*/
>> +   sigemptyset();
>> +   INIT_HLIST_NODE();
>> +
>> +   spin_lock_irq(>sighand->siglock);
>> +   if (!(clone_flags & CLONE_THREAD))
>> +   hlist_add_head(, 
>> >signal->multiprocess);
>
> Here you add the entry to the multiprocess list.
>
>> +   recalc_sigpending();
>> +   spin_unlock_irq(>sighand->siglock);
>> +   if (signal_pending(current))
>> +   return ERR_PTR(restart_syscall());
>
> .. and here you return with the list entry still there, pointing to
> the stack that you now no longer use.
>
> The same is true of *all* the error cases, because the only point you
> remove it is for the success case:

Yes you are quite right.   Easy enough to fix, but it definitely needs
to be fixed.

I will respin.

Eric


>> @@ -1979,6 +1982,8 @@ static __latent_entropy struct task_struct 
>> *copy_process(
>> attach_pid(p, PIDTYPE_TGID);
>> attach_pid(p, PIDTYPE_PGID);
>> attach_pid(p, PIDTYPE_SID);
>> +   p->signal->shared_pending.signal = delayed.signal;
>> +   hlist_del();
>
> So for all the error cases, you leave a dangling pointer to the
> current stack in that signal handler, and then return an error.
>
> Guaranteed stack and list corruption.
>
>  Linus

[PATCH v2 0/2] cpufreq: Fix a circular lock dependency problem

[Waiman Long]

 v2:
  - Remove the retry loop in the store method.

This patchset works around a circular lock dependency issue in the
cpufreq driver reported by lockdep. The two locks involved are the
cpu_hotplup_lock and the reference count of a sysfs file.

The cpufreq_register_driver() function uses the lock sequence:

  cpus_read_lock --> kn->count

Whereas the cpufreq sysfs store method uses the sequence:

  kn->count --> cpus_read_lock

This is not really an issue as a shared lock is used on the
cpu_hotplup_lock. However, the lockdep code isn't able to handle
shared locking. So one way to work around this is to define a
cpus_read_trylock() function and uses it in the store method instead.

Waiman Long (2):
  cpu/hotplug: Add a cpus_read_trylock() function
  cpufreq: Fix a circular lock dependency problem

 drivers/cpufreq/cpufreq.c | 7 ++-
 include/linux/cpu.h   | 2 ++
 kernel/cpu.c  | 6 ++
 3 files changed, 14 insertions(+), 1 deletion(-)

-- 
1.8.3.1

[PATCH v2 2/2] cpufreq: Fix a circular lock dependency problem

[Waiman Long]

With lockdep turned on, the following circular lock dependency problem
was reported:

[   57.470040] ==
[   57.502900] WARNING: possible circular locking dependency detected
[   57.535208] 4.18.0-0.rc3.1.el8+7.x86_64+debug #1 Tainted: G
[   57.577761] --
[   57.609714] tuned/1505 is trying to acquire lock:
[   57.633808] 559deec5 (cpu_hotplug_lock.rw_sem){}, at: 
store+0x27/0x120
[   57.672880]
[   57.672880] but task is already holding lock:
[   57.702184] 2136ca64 (kn->count#118){}, at: 
kernfs_fop_write+0x1d0/0x410
[   57.742176]
[   57.742176] which lock already depends on the new lock.
[   57.742176]
[   57.785220]
[   57.785220] the existing dependency chain (in reverse order) is:
:
[   58.932512] other info that might help us debug this:
[   58.932512]
[   58.973344] Chain exists of:
[   58.973344]   cpu_hotplug_lock.rw_sem --> subsys mutex#5 --> kn->count#118
[   58.973344]
[   59.030795]  Possible unsafe locking scenario:
[   59.030795]
[   59.061248]CPU0CPU1
[   59.085377]
[   59.108160]   lock(kn->count#118);
[   59.124935]lock(subsys mutex#5);
[   59.156330]lock(kn->count#118);
[   59.186088]   lock(cpu_hotplug_lock.rw_sem);
[   59.208541]
[   59.208541]  *** DEADLOCK ***

In the cpufreq_register_driver() function, the lock sequence is:

  cpus_read_lock --> kn->count

For the cpufreq sysfs store method, the lock sequence is:

  kn->count --> cpus_read_lock

These sequences are actually safe as they are taking a share lock on
cpu_hotplug_lock. However, the current lockdep code doesn't check for
share locking when detecting circular lock dependency.  Fixing that
could be a substantial effort.

Instead, we can work around this problem by using cpus_read_trylock()
in the store method which is much simpler. The chance of not getting
the read lock is very small. If that happens, the userspace application
that writes the sysfs file will get an error.

Signed-off-by: Waiman Long 
---
 drivers/cpufreq/cpufreq.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b0dfd32..1ddb5ce 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -923,7 +923,12 @@ static ssize_t store(struct kobject *kobj, struct 
attribute *attr,
struct freq_attr *fattr = to_attr(attr);
ssize_t ret = -EINVAL;
 
-   cpus_read_lock();
+   /*
+* cpus_read_trylock() is used here to work around a circular lock
+* dependency problem with respect to the cpufreq_register_driver().
+*/
+   if (!cpus_read_trylock())
+   return -EBUSY;
 
if (cpu_online(policy->cpu)) {
down_write(>rwsem);
-- 
1.8.3.1

[PATCH v2 1/2] cpu/hotplug: Add a cpus_read_trylock() function

[Waiman Long]

There are use cases where it can be useful to have a cpus_read_trylock()
function to work around circular lock dependency problem involving
the cpu_hotplug_lock.

Signed-off-by: Waiman Long 
---
 include/linux/cpu.h | 2 ++
 kernel/cpu.c| 6 ++
 2 files changed, 8 insertions(+)

diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index a97a63e..e850bfe 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -103,6 +103,7 @@ static inline void cpu_maps_update_done(void)
 extern void cpus_write_unlock(void);
 extern void cpus_read_lock(void);
 extern void cpus_read_unlock(void);
+extern int  cpus_read_trylock(void);
 extern void lockdep_assert_cpus_held(void);
 extern void cpu_hotplug_disable(void);
 extern void cpu_hotplug_enable(void);
@@ -115,6 +116,7 @@ static inline void cpus_write_lock(void) { }
 static inline void cpus_write_unlock(void) { }
 static inline void cpus_read_lock(void) { }
 static inline void cpus_read_unlock(void) { }
+static inline int  cpus_read_trylock(void) { return true; }
 static inline void lockdep_assert_cpus_held(void) { }
 static inline void cpu_hotplug_disable(void) { }
 static inline void cpu_hotplug_enable(void) { }
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 0db8938..307486b 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -290,6 +290,12 @@ void cpus_read_lock(void)
 }
 EXPORT_SYMBOL_GPL(cpus_read_lock);
 
+int cpus_read_trylock(void)
+{
+   return percpu_down_read_trylock(_hotplug_lock);
+}
+EXPORT_SYMBOL_GPL(cpus_read_trylock);
+
 void cpus_read_unlock(void)
 {
percpu_up_read(_hotplug_lock);
-- 
1.8.3.1

Re: [PATCH v3 2/2] fpga: zynq-fpga: Add support for readback

[Alan Tull]

On Tue, Jul 24, 2018 at 1:31 PM, Appana Durga Kedareswara Rao
 wrote:
> Hi Moritz,
>
> Thanks for the review...
>
> 
>> Can you please make the commit message such that you have full sentences?
>>
>> "Add support for readback of FPGA configuration data and registers" of
>> example.
>
> Sure will fix in v4.
>
>>
>> >
>> > Usage:
>> > Readback of PL configuration registers
>> > cat /sys/kernel/debug/fpga/fpga0/image
>> > Readback of PL configuration data
>> > echo 1 > /sys/module/zynqmp_fpga/parameters/readback_type
>>
>> The patch below is for Zynq if I'm not mistaken, not ZynqMP?
>
> Yes it is for Zynq not ZynqMP by mistake I have kept zynqmp here, thanks for 
> pointing  will fix in v4...
>
> 
>> > +static bool readback_type;
>> > +module_param(readback_type, bool, 0644);
>> > +MODULE_PARM_DESC(readback_type,
>> > +   "readback_type 0-configuration register read "
>> > +   "1- configuration data read (default: 0)");
>>
>> Not sure a module param is the best solution here.
>
> Need to provide flexibility to the user to switch between reading of FPGA 
> registers and configuration data.

I suggested calling the attribute 'image' because I thought it would
always be a read back of the FPGA image information.  I don't think
that a sysfs attribute's function should change. :)

> One other option is sysfs. Do you want me to implement sysfs path???
> Any other suggestions???

You could implement another sysfs attribute for reading FPGA registers
with a separate ops callback.   Please clarify what it is doing (not
all FPGAs have this function) and what that will look like when the
user reads the from the sysfs

Alan

Re: [PATCHv3 2/2] mtd: m25p80: restore the status of SPI flash when exiting

[Brian Norris]

Hi,

On Tue, Jul 24, 2018 at 11:51:49AM +1000, NeilBrown wrote:
> On Tue, Jul 24 2018, Boris Brezillon wrote:
> > On Tue, 24 Jul 2018 08:46:33 +1000
> > NeilBrown  wrote:
> >> One possibility that occurred to me when I was exploring this issue is
> >> to revert to 3-byte mode whenever 4-byte was not actively in use.
> >> So any access beyond 16Meg is:
> >>  switch-to-4-byte ; perform IO ; switch to 3-byte
> >> or similar.  On my hardware it would be more efficient to
> >> use the 4-byte opcode to perform the IO, then reset the cached
> >> 4th address byte that the NOR chip transparently remembered.

Do these chips cache the last 4th-byte used? I don't recall reading
that, but that would be interesting. It also sounds like that would make
things even more difficult to do robustly.

> >> This adds a little overhead, but should be fairly robust.
> >> It doesn't help if something goes terribly wrong while IO is happening,
> >> but I don't think any other software solution does either.
> >> 
> >> How would you see that approach?
> >
> > I think the problem stands: people that have proper HW mitigation for
> > this problem (NOR chip is reset when the Processor is reset) don't want
> > to pay the overhead. So, even if we go for this approach, we probably
> > want to only do that for broken HW.

If it actually saves bytes on the wire to stay in 3-byte mode more
often, then that could be helpful to all systems. But otherwise, yes, it
doesn't really belong on a properly-designed system.

> I agree that a "my-hardware-is-suboptimal" flag is appropriate.
> I was addressing the suggestion that the current approach doesn't handle
> all corner cases and was suggesting a different approach that might
> handle more corner-cases.  I should have been more explicit about that.

If you want to talk about optimizing the broken-hardware hack, then
fine. That's not my interest at all.

Brian

Re: [RFT v2 01/10] pinctrl: samsung: Define suspend and resume callbacks for all banks and SoCs

[Krzysztof Kozlowski]

On Mon, Jul 23, 2018 at 07:52:53PM +0200, Krzysztof Kozlowski wrote:
> Suspend and resume callbacks in Exynos/S5Pv210 pin controller drivers,
> save and restore state of registers.  This operations should be done for
> all banks which have external interrupts (as denoted by using
> EXYNOS_PIN_BANK_EINTG/EINTW macros).
> 
> Add all banks of Exynos5260 and Exynos5420.  This is necessary step for
> supporting suspend to RAM on these SoCs.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Cc: Tomasz Figa 
> Cc: Sylwester Nawrocki 
> Acked-by: Tomasz Figa 
> ---
>  drivers/pinctrl/samsung/pinctrl-exynos-arm.c | 16 
>  1 file changed, 16 insertions(+)

Thanks, applied.

Best regards,
Krzysztof