Re: [PATCH] arm: dts: r7s72100: Add support for GR-Peach

[Simon Horman]

On Wed, May 24, 2017 at 09:07:02AM +0200, jmondi wrote:
> Hello Simon,
> 
> On Tue, May 23, 2017 at 09:25:40PM +0200, Geert Uytterhoeven wrote:
> > On Tue, May 23, 2017 at 9:20 PM, Jacopo Mondi  
> > wrote:
> > > Add device tree source for Renesas GR-Peach board.
> > > GR-Peach is an RZ/A1H based board with 10MB of on-chip SRAM and 8MB
> > > QSPI flash storage.
> > > Add support for the board, and create a 2MB partition to use as rootfs.
> > >
> > > Signed-off-by: Jacopo Mondi 
> >
> > Reviewed-by: Geert Uytterhoeven 
> 
> I forgot to change subject to "PATCH v2".
> Could you please take this one, or would you like me to resend with
> Geert's reviewed-by ?

No need to repost, I've queued-up this version for v4.13.

Re: [PATCH 1/1] futex: remove duplicated code

[Thomas Gleixner]

On Thu, 25 May 2017, Will Deacon wrote:
> On Mon, May 22, 2017 at 11:11:33PM +0200, Thomas Gleixner wrote:
> > On Mon, 15 May 2017, Will Deacon wrote:
> > > On Mon, May 15, 2017 at 03:07:42PM +0200, Jiri Slaby wrote:
> > > > There is code duplicated over all architecture's headers for
> > > > futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> > > > and comparison of the result.
> > > > 
> > > > Remove this duplication and leave up to the arches only the needed
> > > > assembly which is now in arch_futex_atomic_op_inuser.
> > > > 
> > > > Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
> > > > remove pointless access_ok() checks") as access_ok there returns true.
> > > > We introduce it back to the helper for the sake of simplicity (it gets
> > > > optimized away anyway).
> > > 
> > > Whilst I think this is a good idea, the code in question actually results
> > > in undefined behaviour per the C spec and is reported by UBSAN. See my
> > > patch fixing arm64 here (which I'd forgotten about):
> > > 
> > > https://www.spinics.net/lists/linux-arch/msg38564.html
> > > 
> > > But, as stated in the thread above, I think we should go a step further
> > > and remove FUTEX_OP_{OR,ANDN,XOR,OPARG_SHIFT} altogether. They don't
> > > appear to be used by userspace, and this whole thing is a total mess.
> > 
> > You wish. The constants are not used, but FUTEX_WAKE_OP _IS_ used by
> > glibc. They only have one argument it seems:
> > 
> >#define FUTEX_OP_CLEAR_WAKE_IF_GT_ONE  ((4 << 24) | 1)
> > 
> > but I'm pretty sure that there is enough (probably horrible) code (think
> > java) out there using FUTEX_WAKE_OP for whatever (non)sensical reasons in
> > any available combination.
> 
> Indeed, and I'm not proposing to get rid of that. It's the grossly
> over-engineered array of operations and the FUTEX_OP_OPARG_SHIFT modifier
> that I think we should kill. The latter likely behaves differently across
> different architectures and potentially depending on the toolchain you used
> to build the kernel.
> 
> Does anybody know the history behind the interface design?

Which design?

4732efbeb997 ("[PATCH] FUTEX_WAKE_OP: pthread_cond_signal() speedup")

Thanks,

tglx

Re: [PATCH 7/7] DWARF: add the config option

[Jiri Slaby]

On 05/19/2017, 11:35 PM, Josh Poimboeuf wrote:
>   
> https://github.com/jpoimboe/linux/blob/undwarf/arch/x86/kernel/unwind_undwarf.c

JFYI, it crashes in sha1_transform_avx due to crypto changes. You
perhaps missed that this beast uses ebp (not rbp) register for
computations. I had to do:

--- a/arch/x86/crypto/sha1_ssse3_asm.S
+++ b/arch/x86/crypto/sha1_ssse3_asm.S
@@ -37,7 +37,7 @@
 #define REG_A  %ecx
 #define REG_B  %esi
 #define REG_C  %edi
-#define REG_D  %ebp
+#define REG_D  %r12d
 #define REG_E  %edx

 #define REG_T1 %eax
@@ -74,6 +74,7 @@
SYM_FUNC_START(\name)

push%rbx
+   push%r12
push%rbp

mov %rsp, %rbp
@@ -99,6 +100,7 @@
rep stosq

leaveq  # deallocate workspace
+   pop %r12
pop %rbx
ret


I am afraid there are more of these, e.g. in aesni-intel_asm.S.

thanks,
-- 
js
suse labs

Re: [PATCH 01/15] liblockdep: Fix undefined symbol prandom_u32

[Ingo Molnar]

* Levin, Alexander (Sasha Levin)  wrote:

> On Wed, May 24, 2017 at 09:53:37AM +0200, Ingo Molnar wrote:
> > 
> > So I'm not sure how you sent these patches, but probably due to the lack of 
> > a 
> > boilerplate message, the order was all mixed up. I got the patch order 
> > right on 
> > the third attempt.
> > 
> > But then I encountered this build failure (when applied to Linus's latest 
> > tree):
> > 
> > triton:~/tip/tools/lib/lockdep> make
> >   CC   common.o
> >   CC   lockdep.o
> > In file included from lockdep.c:25:0:
> > ../../../kernel/locking/lockdep.c:33:28: fatal error: linux/sched/mm.h: No 
> > such 
> > file or directory
> >  #include 
> > ^
> 
> Heh, apparently a bunch of stuff changed between the point when I sent my
> original pull request and now... I'll resend with additional fixes.

Yeah, and also note that this is v4.13 material at best - liblockdep broke a 
long 
time ago so it falls under 'development', not 'regression fixes'.

Thanks,

Ingo

Re: [PATCH 00/21] liblockdep fixes for v4.12

[Ingo Molnar]

* Levin, Alexander (Sasha Levin)  wrote:

>  MAINTAINERS|   2 +-
>  tools/Makefile |   8 +++--
>  tools/include/linux/bitops.h   |  10 ++
>  tools/include/linux/err.h  |   5 +++
>  tools/include/linux/jhash.h| 175 
> +++
>  tools/include/linux/sched/clock.h  |   0
>  tools/include/linux/sched/mm.h |   0
>  tools/include/linux/sched/task.h   |   0
>  tools/include/linux/unaligned/packed_struct.h  |  46 
> +++
>  tools/lib/lockdep/Makefile |   9 +++---
>  tools/lib/lockdep/lockdep.c|  17 ++
>  tools/lib/lockdep/preload.c|   3 +-
>  tools/lib/lockdep/run_tests.sh |   8 ++---
>  tools/lib/lockdep/uinclude/linux/bitops.h  |   3 --
>  tools/lib/lockdep/uinclude/linux/compiler.h|   2 ++
>  tools/lib/lockdep/uinclude/linux/debug_locks.h |   2 +-
>  tools/lib/lockdep/uinclude/linux/irqflags.h|   8 ++---
>  tools/lib/lockdep/uinclude/linux/kallsyms.h|   3 +-
>  tools/lib/lockdep/uinclude/linux/kernel.h  |  20 ++--
>  tools/lib/lockdep/uinclude/linux/lockdep.h |  26 
>  tools/lib/lockdep/uinclude/linux/module.h  |   5 +++
>  tools/lib/lockdep/uinclude/linux/rcu.h |   2 ++
>  22 files changed, 317 insertions(+), 37 deletions(-)
>  create mode 100644 tools/include/linux/jhash.h
>  create mode 100644 tools/include/linux/sched/clock.h
>  create mode 100644 tools/include/linux/sched/mm.h
>  create mode 100644 tools/include/linux/sched/task.h
>  create mode 100644 tools/include/linux/unaligned/packed_struct.h
>  delete mode 100644 tools/lib/lockdep/uinclude/linux/bitops.h

Yeah, so what needs to be fixed as well is for liblockdep to exclusively use 
tools/include/ (and extend those headers where required).

perf already uses that method and it works well.

liblockdep already uses tools/include/ in part, but even after I apply all your 
patches, there's still lib/lockdep/uinclude/ which appears to duplicate a 
number 
of headers.

I did a quick check - for example WARN_ON() et al is duplicated in 
tools/lib/lockdep/uinclude/linux/kernel.h.

Thanks,

Ingo

Re: [PATCH v2] PCI: Add ATS-disable quirk for AMD Stoney GPUs

[Samuel Sieb]

On 05/24/2017 05:56 AM, Deucher, Alexander wrote:

-Original Message-
From: Joerg Roedel [mailto:jroe...@suse.de]
Sent: Wednesday, May 24, 2017 4:45 AM
To: Deucher, Alexander
Cc: 'David Woodhouse'; 'Joerg Roedel'; Bjorn Helgaas; linux-
p...@vger.kernel.org; linux-kernel@vger.kernel.org; Daniel Drake; Samuel
Sieb
Subject: Re: [PATCH v2] PCI: Add ATS-disable quirk for AMD Stoney GPUs

Hi Alexander,

On Tue, May 23, 2017 at 07:54:12PM +, Deucher, Alexander wrote:

I finally got an answer from the hw team and we validated ATS on
stoney as well so in theory this patch shouldn’t actually be needed.
I think we may actually be papering over some other issue.  The
following patch seems to also fix this issue (and other issues):
https://www.spinics.net/lists/stable/msg172631.html


Yeah, but it still looks to me like that the hardware got into some
weird state with the storm of ATS invalidations sent to it.

The Completion-Wait loop timeouts seen in the original bug report
indicate that the IOMMU is waiting for a response that never comes. And
this is probably the ATS flush completion response from the GPU, as
disabling ATS on the GPU makes the issue disappear.


Yeah, it's weird.  My ack on the patch still stands.  Just adding some 
additional data.



I just tested this patch without the previous ATS disabling patch (I 
verified that ATS was enabled).  Doing a stress-test kernel build while 
running a 3D graphical application caused no disk corruption.  That was 
running for several hours.  If it's not the solution, it sure hides the 
problem really well.

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

[Daniel Vetter]

On Fri, May 26, 2017 at 7:52 AM, Christoph Hellwig  wrote:
> On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote:
>> Hi sean,
>>
>> On 05/25/2017 11:30 PM, Sean Paul wrote:
>> > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
>> > > The system would crash when trying to alloc zero sized gem buffer:
>> > > [6.712435] Unable to handle kernel NULL pointer dereference at 
>> > > virtual address 0010 <--ZERO_SIZE_PTR
>> > > ...
>> > > [6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec
>> >
>> > It's unfortunate that you didn't include the entire stack trace. From code
>> > inspection, it seems like the 0 size comes from the fb_probe path? Is there
>> > somewhere in the helpers that you could check the mode is sane so all 
>> > drivers
>> > can benefit?
>>
>> hmm, sorry, i was testing it on chromeos 4.4 kernel, it turns out that we
>> have a custom ioctl for userspace to create gem buffer(the same as exynos
>> drm), which might get the the 0 size.
>>
>> but on upstream kernel, it could only be called by dump_create, and the
>> drm_mode_create_dumb_ioctl already did the size check.
>>
>> will resent this patch, and rewrite the commit message, thanx.
>
> That suggests that this patch isn't needed at all.

Yes, not needed for upstream. But next time around pls include the
entire backtrace (or at least the relevant parts), not just the last
line, so that we can figure this out directly.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

RE: [PATCH] pinctrl/amd: Use regular interrupt instead of chained

[Thomas Gleixner]

Nehal,

On Fri, 26 May 2017, Shah, Nehal-bakulchandra wrote:
> Thanks for the patch. However, we have received this issue from multiple
> people and different disro but it occurs only on Gigabyte hardware. With
> reference AM4 ryzen board we are not facing this issue.  We are in
> discussion with gigabyte to check the BIOS part. Once we have clarity on
> that, we can consider driver part. Also, this code is running on multiple
> platform of different customers so changing directly at this point of
> time may be risky in my point of view. Requesting you to hold this patch
> till we get clarity on bios end.

It does not matter at all whether this is a problem only on GB
hardware. Fact is, that this happened and it will happen again.

The patch does not change any functionality of the driver, it merily makes
it more robust and spares users the bloody annoying experience of a non
booting machine and the tedious task of figuring out why.

The main objective of the kernel is robustness and not pleasing the ego of
silicon vendors. We can't prevent the stupidity of BIOS people, we merily
can deal with it.

That patch should go into mainline ASAP and backported to stable in order
to help those people who bought wreckaged hardware.

Thanks,

tglx

[PATCH] iio: adc: xilinx: Handle return value of clk_prepare_enable

[Arvind Yadav]

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
 drivers/iio/adc/xilinx-xadc-core.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/xilinx-xadc-core.c 
b/drivers/iio/adc/xilinx-xadc-core.c
index 56cf590..4a60497 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -1204,7 +1204,10 @@ static int xadc_probe(struct platform_device *pdev)
ret = PTR_ERR(xadc->clk);
goto err_free_samplerate_trigger;
}
-   clk_prepare_enable(xadc->clk);
+
+   ret = clk_prepare_enable(xadc->clk);
+   if (ret)
+   goto err_free_samplerate_trigger;
 
ret = xadc->ops->setup(pdev, indio_dev, irq);
if (ret)
-- 
1.9.1

[PATCH 6/6] arm64: defconfig: enable hi6421v530 MFD and regulator

[Guodong Xu]

Enable configs for hi6421v530 mfd and regulator driver

Signed-off-by: Guodong Xu 
---
 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ce07285..287e943 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -305,6 +305,7 @@ CONFIG_S3C2410_WATCHDOG=y
 CONFIG_MESON_GXBB_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=m
 CONFIG_MFD_EXYNOS_LPASS=m
+CONFIG_MFD_HI6421V530_PMIC=y
 CONFIG_MFD_MAX77620=y
 CONFIG_MFD_RK808=y
 CONFIG_MFD_SPMI_PMIC=y
@@ -315,6 +316,7 @@ CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_I2C=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_GPIO=y
+CONFIG_REGULATOR_HI6421V530=y
 CONFIG_REGULATOR_HI655X=y
 CONFIG_REGULATOR_MAX77620=y
 CONFIG_REGULATOR_PWM=y
-- 
2.10.2

[PATCH 4/6] regulator: hi6421v530: add driver for hi6421v530 voltage regulator

[Guodong Xu]

From: Wang Xiaoyin 

add the driver for hi6421v530 voltage regulator

Signed-off-by: Wang Xiaoyin 
Signed-off-by: Guodong Xu 
---
 drivers/regulator/Kconfig|  10 +
 drivers/regulator/Makefile   |   1 +
 drivers/regulator/hi6421v530-regulator.c | 355 +++
 3 files changed, 366 insertions(+)
 create mode 100644 drivers/regulator/hi6421v530-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 48db87d..c389ce8 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -296,6 +296,16 @@ config REGULATOR_HI6421
  21 general purpose LDOs, 3 dedicated LDOs, and 5 BUCKs. All
  of them come with support to either ECO (idle) or sleep mode.
 
+config REGULATOR_HI6421V530
+   tristate "HiSilicon Hi6421v530 PMIC voltage regulator support"
+   depends on MFD_HI6421V530_PMIC && OF
+   help
+ This driver provides support for the voltage regulators on
+ HiSilicon Hi6421v530 PMU / Codec IC.
+ Hi6421v530 is a multi-function device which, on regulator part,
+ provides 5 general purpose LDOs, and all of them come with support
+ to either ECO (idle) or sleep mode.
+
 config REGULATOR_HI655X
tristate "Hisilicon HI655X PMIC regulators support"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index dc3503f..36e2b75 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
 obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
 obj-$(CONFIG_REGULATOR_GPIO) += gpio-regulator.o
 obj-$(CONFIG_REGULATOR_HI6421) += hi6421-regulator.o
+obj-$(CONFIG_REGULATOR_HI6421V530) += hi6421v530-regulator.o
 obj-$(CONFIG_REGULATOR_HI655X) += hi655x-regulator.o
 obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
 obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
diff --git a/drivers/regulator/hi6421v530-regulator.c 
b/drivers/regulator/hi6421v530-regulator.c
new file mode 100644
index 000..82854d0
--- /dev/null
+++ b/drivers/regulator/hi6421v530-regulator.c
@@ -0,0 +1,355 @@
+/*
+ * Device driver for regulators in Hi6421V530 IC
+ *
+ * Copyright (c) <2017> HiSilicon Technologies Co., Ltd.
+ *  http://www.hisilicon.com
+ * Copyright (c) <2017> Linaro Ltd.
+ *  http://www.linaro.org
+ *
+ * Author: Wang Xiaoyin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * struct hi6421c530_regulator_pdata - Hi6421V530 regulator data
+ * of platform device.
+ * @lock: mutex to serialize regulator enable
+ */
+struct hi6421v530_regulator_pdata {
+   struct mutex lock;
+};
+
+/*
+ * struct hi6421v530_regulator_info - hi6421v530 regulator information
+ * @desc: regulator description
+ * @mode_mask: ECO mode bitmask of LDOs; for BUCKs, this masks sleep
+ * @eco_microamp: eco mode load upper limit (in uA), valid for LDOs only
+ */
+struct hi6421v530_regulator_info {
+   struct regulator_desc   desc;
+   u8  mode_mask;
+   u32 eco_microamp;
+};
+
+/* HI6421v530 regulators */
+enum hi6421v530_regulator_id {
+   HI6421V530_LDO3,
+   HI6421V530_LDO9,
+   HI6421V530_LDO11,
+   HI6421V530_LDO15,
+   HI6421V530_LDO16,
+   HI6421V530_NUM_REGULATORS,
+};
+
+#define HI6421V530_REGULATOR_OF_MATCH(_name, id)   \
+{  \
+   .name = #_name, \
+   .driver_data = (void *) HI6421V530_##id,\
+}
+
+static struct of_regulator_match hi6421v530_regulator_match[] = {
+   HI6421V530_REGULATOR_OF_MATCH(hi6421v530_ldo3, LDO3),
+   HI6421V530_REGULATOR_OF_MATCH(hi6421v530_ldo9, LDO9),
+   HI6421V530_REGULATOR_OF_MATCH(hi6421v530_ldo11, LDO11),
+   HI6421V530_REGULATOR_OF_MATCH(hi6421v530_ldo15, LDO15),
+   HI6421V530_REGULATOR_OF_MATCH(hi6421v530_ldo16, LDO16),
+};
+
+static const unsigned int ldo_3_voltages[] = {
+   180, 1825000, 185, 1875000,
+   190, 1925000, 195, 1975000,
+   200, 2025000, 205, 2075000,
+   210, 2125000, 215, 220,
+};
+
+static const unsigned int ldo_9_11_voltages[] = {
+   175, 180, 1825000, 280,
+   285, 295, 300, 330,
+};
+
+static const unsigned int ldo_15_16_voltages[] = {
+   175, 180, 240, 260,
+   270, 285, 295, 300,
+};
+
+static const struct regulator_ops hi6421v530_ldo_ops;
+
+#define HI6421V530_LDO_ENABLE_TIME (350)
+
+/*
+ * _id - LDO id name string
+ * v_table - voltage table
+ * vreg - voltage select register
+ * vma

[PATCH 5/6] arm64: dts: hikey960: add device node for pmic and regulators

[Guodong Xu]

From: Wang Xiaoyin 

add device node for hi6421 pmic core and hi6421v530
voltage regulator,include LDO(1,3,9,11,15,16)

Signed-off-by: Wang Xiaoyin 
Signed-off-by: Guodong Xu 
---
 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts 
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index ca448f0..b7a404a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -97,6 +97,66 @@
default-state = "off";
};
};
+
+   pmic: pmic@fff34000 {
+   compatible = "hisilicon,hi6421v530-pmic";
+   reg = <0x0 0xfff34000 0x0 0x1000>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   regulators {
+   ldo1: LDO1 {
+   regulator-compatible = "hi6421v530_ldo1";
+   regulator-name = "LDO1";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <150>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo3: LDO3 {
+   regulator-compatible = "hi6421v530_ldo3";
+   regulator-name = "LDO3";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <220>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo9: LDO9 {
+   regulator-compatible = "hi6421v530_ldo9";
+   regulator-name = "LDO9";
+   regulator-min-microvolt = <175>;
+   regulator-max-microvolt = <330>;
+   regulator-enable-ramp-delay = <240>;
+   };
+
+   ldo11: LDO11 {
+   regulator-compatible = "hi6421v530_ldo11";
+   regulator-name = "LDO11";
+   regulator-min-microvolt = <175>;
+   regulator-max-microvolt = <330>;
+   regulator-enable-ramp-delay = <240>;
+   };
+
+   ldo15: LDO15 {
+   regulator-compatible = "hi6421v530_ldo15";
+   regulator-name = "LDO15";
+   regulator-min-microvolt = <175>;
+   regulator-max-microvolt = <300>;
+   regulator-always-on;
+   regulator-enable-ramp-delay = <120>;
+   };
+
+   ldo16: LDO16 {
+   regulator-compatible = "hi6421v530_ldo16";
+   regulator-name = "LDO16";
+   regulator-min-microvolt = <175>;
+   regulator-max-microvolt = <300>;
+   regulator-enable-ramp-delay = <360>;
+   };
+   };
+   };
 };
 
 &i2c0 {
-- 
2.10.2

[PATCH 0/6] MFD: add driver for HiSilicon Hi6421v530 PMIC

[Guodong Xu]

This patchset adds driver for HiSilicon Hi6421v530 PMIC.

Mainline kernel already has driver support to a similar chip, Hi6421.
Hi6421 and Hi6421v530 are both from the same vendor, HiSilicon, but
they are at different revisions. They both use the same Memory-mapped
I/O method to communicate with Main SoC. However, they differ quite a
lot in their regulator designs. Eg. they have completely different LDO
voltage points.

In order to enable future extension of Hi6421v530 functionality, a new
mfd driver and regulator driver are added in this patchset. Only header
file hi6421-pmic.h is reused between them. Patch 2 is for just this
purpose.

Patch 3 and 4 adds mfd and regulator driver respectively.
Patch 5 is dts change, it depends and can be applied on hi3660/hikey960
patchset [1].
Patch 6 enables the relevant config items.

[1], http://www.spinics.net/lists/devicetree/msg178303.html

Guodong Xu (4):
  dt-bindings: mfd: Add hi6421v530 bindings
  mfd: hi6421-pmic: move hi6421_regmap_config definition to header file
  mfd: hi6421v530: add support for HiSilicon Hi6421v530
  arm64: defconfig: enable hi6421v530 MFD and regulator

Wang Xiaoyin (2):
  regulator: hi6421v530: add driver for hi6421v530 voltage regulator
  arm64: dts: hikey960: add device node for pmic and regulators

 .../bindings/mfd/hisilicon,hi6421v530.txt  |  25 ++
 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts  |  60 
 arch/arm64/configs/defconfig   |   2 +
 drivers/mfd/Kconfig|   9 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/hi6421-pmic-core.c |   7 -
 drivers/mfd/hi6421v530-pmic.c  |  92 ++
 drivers/regulator/Kconfig  |  10 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/hi6421v530-regulator.c   | 355 +
 include/linux/mfd/hi6421-pmic.h|   6 +
 11 files changed, 561 insertions(+), 7 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/mfd/hisilicon,hi6421v530.txt
 create mode 100644 drivers/mfd/hi6421v530-pmic.c
 create mode 100644 drivers/regulator/hi6421v530-regulator.c

-- 
2.10.2

[PATCH 3/6] mfd: hi6421v530: add support for HiSilicon Hi6421v530

[Guodong Xu]

Add support for HiSilicon Hi6421v530 PMIC. Hi6421v530 communicates with
main SoC via memory-mapped I/O.

Hi6421v530 and Hi6421 are PMIC chips from the same vendor, HiSilicon, but
at different revisions. They share the same memory-mapped I/O design. They
differ in regulator details, eg. LDO voltage points.

Signed-off-by: Guodong Xu 
Signed-off-by: Wang Xiaoyin 
---
 drivers/mfd/Kconfig   |  9 +
 drivers/mfd/Makefile  |  1 +
 drivers/mfd/hi6421v530-pmic.c | 92 +++
 3 files changed, 102 insertions(+)
 create mode 100644 drivers/mfd/hi6421v530-pmic.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3eb5c93..bdc8304 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -388,6 +388,15 @@ config MFD_HI6421_PMIC
  menus in order to enable them.
  We communicate with the Hi6421 via memory-mapped I/O.
 
+config MFD_HI6421V530_PMIC
+   tristate "HiSilicon Hi6421v530 PMU/Codec IC"
+   depends on OF
+   select MFD_CORE
+   select REGMAP_MMIO
+   help
+ Add support for HiSilicon Hi6421v530 PMIC. Hi6421v530 communicates
+ with main SoC via memory-mapped I/O.
+
 config MFD_HI655X_PMIC
tristate "HiSilicon Hi655X series PMU/Codec IC"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c16bf1e..cde62fc 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -206,6 +206,7 @@ obj-$(CONFIG_MFD_STW481X)   += stw481x.o
 obj-$(CONFIG_MFD_IPAQ_MICRO)   += ipaq-micro.o
 obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)  += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_HI6421V530_PMIC)  += hi6421v530-pmic.o
 obj-$(CONFIG_MFD_HI655X_PMIC)   += hi655x-pmic.o
 obj-$(CONFIG_MFD_DLN2) += dln2.o
 obj-$(CONFIG_MFD_RT5033)   += rt5033.o
diff --git a/drivers/mfd/hi6421v530-pmic.c b/drivers/mfd/hi6421v530-pmic.c
new file mode 100644
index 000..651659a
--- /dev/null
+++ b/drivers/mfd/hi6421v530-pmic.c
@@ -0,0 +1,92 @@
+/*
+ * Device driver for Hi6421 IC
+ *
+ * Copyright (c) <2017> HiSilicon Technologies Co., Ltd.
+ *  http://www.hisilicon.com
+ * Copyright (c) <2017> Linaro Ltd.
+ *  http://www.linaro.org
+ *
+ * Author: Wang Xiaoyin 
+ * Guodong Xu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell hi6421v530_devs[] = {
+   { .name = "hi6421v530-regulator", },
+};
+
+static int hi6421v530_pmic_probe(struct platform_device *pdev)
+{
+   struct hi6421_pmic *pmic;
+   struct resource *res;
+   void __iomem *base;
+   int ret;
+
+   pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
+   if (!pmic)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   pmic->regmap = devm_regmap_init_mmio_clk(&pdev->dev, NULL, base,
+&hi6421_regmap_config);
+   if (IS_ERR(pmic->regmap)) {
+   dev_err(&pdev->dev,
+   "regmap init failed: %ld\n", PTR_ERR(pmic->regmap));
+   return PTR_ERR(pmic->regmap);
+   }
+
+   platform_set_drvdata(pdev, pmic);
+
+   ret = devm_mfd_add_devices(&pdev->dev, 0, hi6421v530_devs,
+  ARRAY_SIZE(hi6421v530_devs), NULL, 0, NULL);
+   if (ret) {
+   dev_err(&pdev->dev, "add mfd devices failed: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct of_device_id of_hi6421v530_pmic_match_tbl[] = {
+   { .compatible = "hisilicon,hi6421v530-pmic", },
+   { },
+};
+MODULE_DEVICE_TABLE(of, of_hi6421v530_pmic_match_tbl);
+
+static struct platform_driver hi6421v530_pmic_driver = {
+   .driver = {
+   .name   = "hi6421v530_pmic",
+   .of_match_table = of_hi6421v530_pmic_match_tbl,
+   },
+   .probe  = hi6421v530_pmic_probe,
+};
+module_platform_driver(hi6421v530_pmic_driver);
+
+MODULE_AUTHOR("Guodong Xu ");
+MODULE_DESCRIPTION("Hi6421v530 PMIC driver");
+MODULE_LICENSE("GPL v2");
-- 
2.10.2

[PATCH 1/6] dt-bindings: mfd: Add hi6421v530 bindings

[Guodong Xu]

DT bindings for hisilicon HI655x PMIC chip.

Signed-off-by: Guodong Xu 
---
 .../bindings/mfd/hisilicon,hi6421v530.txt  | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mfd/hisilicon,hi6421v530.txt

diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421v530.txt 
b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421v530.txt
new file mode 100644
index 000..6ffe6f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421v530.txt
@@ -0,0 +1,25 @@
+Hisilicon Hi6421v530 Power Management Integrated Circuit (PMIC)
+
+The hardware layout for access PMIC Hi6421v530 from AP SoC Hi3660.
+Between PMIC Hi6421v530 and Hi3660, the physical signal channel is SSI.
+We can use memory-mapped I/O to communicate.
+
+++ +-+
+|| | |
+|Hi3660  |   SSI bus   |  Hi6421v530 |
+||-| |
+||(REGMAP_MMIO)| |
+++ +-+
+
+Required properties:
+- compatible:   Should be "hisilicon,hi6421v530-pmic".
+- reg:  Base address of PMIC on Hi3660 SoC.
+- interrupt-controller: Hi6421v530 has internal IRQs (has own IRQ domain).
+
+Example:
+   pmic: pmic@fff34000 {
+   compatible = "hisilicon,hi6421v530-pmic";
+   reg = <0x0 0xfff34000 0x0 0x1000>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   }
-- 
2.10.2

[PATCH 2/6] mfd: hi6421-pmic: move hi6421_regmap_config definition to header file

[Guodong Xu]

Move hi6421_regmap_config definition from c code to common header:
 - include/linux/mfd/hi6421-pmic.h

This is to improve code re-use for upcoming hi6421 series of MFD driver.

Signed-off-by: Guodong Xu 
---
 drivers/mfd/hi6421-pmic-core.c  | 7 ---
 include/linux/mfd/hi6421-pmic.h | 6 ++
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/hi6421-pmic-core.c b/drivers/mfd/hi6421-pmic-core.c
index 3fd703f..dc1b5cf 100644
--- a/drivers/mfd/hi6421-pmic-core.c
+++ b/drivers/mfd/hi6421-pmic-core.c
@@ -35,13 +35,6 @@ static const struct mfd_cell hi6421_devs[] = {
{ .name = "hi6421-regulator", },
 };
 
-static const struct regmap_config hi6421_regmap_config = {
-   .reg_bits = 32,
-   .reg_stride = 4,
-   .val_bits = 8,
-   .max_register = HI6421_REG_TO_BUS_ADDR(HI6421_REG_MAX),
-};
-
 static int hi6421_pmic_probe(struct platform_device *pdev)
 {
struct hi6421_pmic *pmic;
diff --git a/include/linux/mfd/hi6421-pmic.h b/include/linux/mfd/hi6421-pmic.h
index 587273e..f4674ff 100644
--- a/include/linux/mfd/hi6421-pmic.h
+++ b/include/linux/mfd/hi6421-pmic.h
@@ -38,4 +38,10 @@ struct hi6421_pmic {
struct regmap   *regmap;
 };
 
+static const struct regmap_config hi6421_regmap_config = {
+   .reg_bits = 32,
+   .reg_stride = 4,
+   .val_bits = 8,
+   .max_register = HI6421_REG_TO_BUS_ADDR(HI6421_REG_MAX),
+};
 #endif /* __HI6421_PMIC_H */
-- 
2.10.2

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

[Rob Landley]

On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
> Hi Michael,
> 
> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman  
> wrote:
>>
>> It'll be:
>>
>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>
> And Andrew has asked me to drop that patch from linux-next which will
> happen today.

What approach do the kernel developers suggest I take here?

I would have thought letting it soak in linux-next for a release so
people could fix userspace bugs would be the next step, but this sounds
like that's not an option?

Is the behavior the patch implements wrong?

Rob

Re: [PATCH 0/2] nohz: Deal with clock reprogram skipping issues v3

[Ingo Molnar]

* Frederic Weisbecker  wrote:

> On Wed, May 24, 2017 at 09:16:28AM +0200, Ingo Molnar wrote:
> > So the interdiff between your two patches and the 3 commits already queued 
> > up is:
> > 
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index e3043873fcdc..30253ed0380b 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -150,12 +150,6 @@ static void tick_sched_handle(struct tick_sched *ts, 
> > struct pt_regs *regs)
> > touch_softlockup_watchdog_sched();
> > if (is_idle_task(current))
> > ts->idle_jiffies++;
> > -   /*
> > -* In case the current tick fired too early past its expected
> > -* expiration, make sure we don't bypass the next clock 
> > reprogramming
> > -* to the same deadline.
> > -*/
> > -   ts->next_tick = 0;
> > }
> >  #endif
> > update_process_times(user_mode(regs));
> > @@ -1103,8 +1097,15 @@ static void tick_nohz_handler(struct 
> > clock_event_device *dev)
> > tick_sched_handle(ts, regs);
> >  
> > /* No need to reprogram if we are running tickless  */
> > -   if (unlikely(ts->tick_stopped))
> > +   if (unlikely(ts->tick_stopped)) {
> > +   /*
> > +* In case the current tick fired too early past its expected
> > +* expiration, make sure we don't bypass the next clock 
> > reprogramming
> > +* to the same deadline.
> > +*/
> > +   ts->next_tick = 0;
> > return;
> > +   }
> >  
> > hrtimer_forward(&ts->sched_timer, now, tick_period);
> > tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);
> > @@ -1202,12 +1203,17 @@ static enum hrtimer_restart tick_sched_timer(struct 
> > hrtimer *timer)
> >  */
> > if (regs)
> > tick_sched_handle(ts, regs);
> > -   else
> > -   ts->next_tick = 0;
> >  
> > /* No need to reprogram if we are in idle or full dynticks mode */
> > -   if (unlikely(ts->tick_stopped))
> > +   if (unlikely(ts->tick_stopped)) {
> > +   /*
> > +* In case the current tick fired too early past its expected
> > +* expiration, make sure we don't bypass the next clock 
> > reprogramming
> > +* to the same deadline.
> > +*/
> > +   ts->next_tick = 0;
> > return HRTIMER_NORESTART;
> > +   }
> >  
> > hrtimer_forward(timer, now, tick_period);
> >  
> > 
> > ... so the two are not the same - I'd rather not rebase it, I'd like to 
> > keep what 
> > is working, we had problems with these changes before ...
> > 
> > If you'd like the changes in this interdiff to be applied as well, please 
> > add a 
> > changelog to it and post it as a fourth patch.
> > 
> > Thanks,
> > 
> > Ingo
> 
> So if you like, you can replace the top patch with the following. It's exactly
> the same code, I've only added a comment and a changelog:
> 
> ---
> From 72956bf08c3b2e506a5ce5ec4faac9fd6b097307 Mon Sep 17 00:00:00 2001
> From: Frederic Weisbecker 
> Date: Mon, 15 May 2017 14:56:50 +0200
> Subject: [PATCH] nohz: Reset next_tick cache even when the timer has no regs
> 
> The tick IRQ regs can be NULL if hrtimer_interrupt() is called from
> non-interrupt contexts (ex: hotplug CPU down). For such very special
> path we forget to clean the cached next tick deadline. If we are in
> dynticks mode and the actual timer deadline is ahead of us, we might
> perform a buggy bypass of the next clock reprogramming.
> 
> In fact since CPU down is the only user I'm aware of, this fix is likely
> unnecessary as dying CPUs already clean their tick deadline cache. But
> given how hard it is to debug such timer cache related issue, we should
> never be short on paranoid measures.
> 
> Signed-off-by: Frederic Weisbecker 
> Cc: Linus Torvalds 
> Cc: Peter Zijlstra 
> Cc: Thomas Gleixner 
> Signed-off-by: Ingo Molnar 
> ---
>  kernel/time/tick-sched.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index 764d290..ed18ca5 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -1200,8 +1200,17 @@ static enum hrtimer_restart tick_sched_timer(struct 
> hrtimer *timer)
>* Do not call, when we are not in irq context and have
>* no valid regs pointer
>*/
> - if (regs)
> + if (regs) {
>   tick_sched_handle(ts, regs);
> + } else {
> + /*
> +  * IRQ regs are NULL if hrtimer_interrupt() is called from
> +  * non-interrupt contexts (ex: hotplug cpu down). Make sure to
> +  * clean the cached next tick deadline to avoid buggy bypass of
> +  * clock reprog.
> +  */
> + ts->next_tick = 0;
> + }
>  
>   /* No need to reprogram if we are in idle or full dynticks mode */
>   if (unlikely(ts->tick_stopped))

We

Re: [RFC PATCH tip/master] kprobes: Use synchronize_rcu_tasks() for optprobe wit CONFIG_PREEMPT

[Ingo Molnar]

* Paul E. McKenney  wrote:

> How about the following (untested) patch?

Looks good to me!

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [RESEND: PATCH v4 4/4] remoteproc: qcom: Add support for mss boot on msm8996

[Bjorn Andersson]

On Tue 16 May 11:02 PDT 2017, Avaneesh Kumar Dwivedi wrote:

> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt 
> b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> index 92347fe..f9dfb6c 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> @@ -9,8 +9,8 @@ on the Qualcomm Hexagon core.
>   Definition: must be one of:
>   "qcom,q6v5-pil",
>   "qcom,msm8916-mss-pil",
> - "qcom,msm8974-mss-pil"
> -
> + "qcom,msm8974-mss-pil",
> + "qcom,msm8996-mss-pil"

Indentation please.

>  - reg:
>   Usage: required
>   Value type: 
> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
> b/drivers/remoteproc/qcom_q6v5_pil.c
[..]
> +/* QDSP6v56 parameters */
> +#define QDSP6v56_LDO_BYP BIT(25)
> +#define QDSP6v56_BHS_ON  BIT(24)
> +#define QDSP6v56_CLAMP_WLBIT(21)
> +#define QDSP6v56_CLAMP_QMC_MEM   BIT(22)
> +#define HALT_CHECK_MAX_LOOPS 200
> +#define QDSP6SS_XO_CBCR  0x0038
> +#define QDSP6SS_ACC_OVERRIDE_VAL 0x20

Please keep the blank line between the defines and the struct
definition.

>  struct reg_info {
>   struct regulator *reg;
>   int uV;
[..]
>  
> +static const struct rproc_hexagon_res msm8996_mss = {
> + .hexagon_mba_image = "mba.mbn",
> + .proxy_supply = (struct qcom_mss_reg_res[]) {
> + {}
> + },
> + .active_supply = (struct qcom_mss_reg_res[]) {
> + {},
> + {}
> + },

It's possible to just leave .proxy_supply and .active_supply out (i.e.
leaving them as NULL), as I made q6v5_regulator_init() handle this
gracefully a while back.

Regards,
Bjorn

Re: [RESEND: PATCH v4 1/4] firmware: scm: Add new SCM call for switching memory ownership

[Bjorn Andersson]

On Tue 16 May 11:01 PDT 2017, Avaneesh Kumar Dwivedi wrote:

> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
> index 93e3b96..4eb7d59 100644
> --- a/drivers/firmware/qcom_scm-32.c
> +++ b/drivers/firmware/qcom_scm-32.c
> @@ -596,3 +596,9 @@ int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, 
> u64 addr, u32 size,
>  {
>   return -ENODEV;
>  }
> +int __qcom_scm_assign_mem(struct device *dev, phys_addr_t mem_addr,
> + size_t mem_sz, phys_addr_t srcVm, size_t srcVm_sz,
> + phys_addr_t destVm, size_t destVm_sz)
> +{
> +return -ENODEV;

Indentation please.

> +}
[..]
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index bb16510..a2363e2 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -40,6 +40,24 @@ struct qcom_scm {
>   struct reset_controller_dev reset;
>  };
>  
> +struct qcom_scm_current_perm_info {
> + __le32 destVm;

__le32 vmid;

> + __le32 destVmPerm;

__le32 perm;

> + __le64 ctx;
> + __le32 ctx_size;
> +};
> +
> +struct qcom_scm_mem_map_info {
> + __le64 mem_addr;
> + __le64 mem_size;
> +};
> +
> +struct qcom_scm_hyp_map_info {
> + __le32 srcVm[2];
> + struct qcom_scm_mem_map_info mem_region;
> + struct qcom_scm_current_perm_info destVm[2];
> +};

As described below, both arrays in this struct should be dynamic size,
so I recommend dropping the struct and just do the offset math yourself
in the function.

> +
>  static struct qcom_scm *__scm;
>  
>  static int qcom_scm_clk_enable(void)
> @@ -292,6 +310,63 @@ int qcom_scm_pas_shutdown(u32 peripheral)
>  }
>  EXPORT_SYMBOL(qcom_scm_pas_shutdown);
>  
> +/**
> + * qcom_scm_assign_mem() - Provide interface to request to map a memory
> + * region into intermediate physical address table as well map
> + * access permissions for any other proc on SOC. So that when other proc
> + * applies the same intermediate physical address passed by requesting
> + * processor in this case apps proc, on memory bus it can access the
> + * region without fault.

The first line should be a short description of the function.

> + * @mem_addr: Start pointer of region which need to be mapped.
> + * @mem_sz: Size of the region.
> + * @srcVm: Detail of current owners, each set bit in flag indicate id of
> + * shared owners.
> + * @newVm: Details of new owners and permission flags for each of them.
> + * @newVm_sz: Size of array pointed by newVm.

If necessary (appropriate in your case) a longer description should go
here - with blank lines before and after.

> + * Return 0 on success.

For more info on the format, please see:

https://www.kernel.org/doc/Documentation/kernel-doc-nano-HOWTO.txt

> + */
> +int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, int srcVm,
> + struct qcom_scm_destVmPerm *newVm, size_t newVm_sz)

It's more idiomatic to pass the number of elements in an array than the
size of the array, so make newVm_sz be the number of items.

And please refrain from using camelCase in the Linux kernel.

> +{
> + unsigned long dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
> + struct qcom_scm_hyp_map_info *hmi;

Skip this struct and just store the base address in a void *, then have
one pointer for each of the substructures (to help fill them in).

> + phys_addr_t addr[3];
> + size_t size[3];

Please give these 6 variables names.

> + int ret;
> + int i;
> +
> + hmi = dma_alloc_attrs(__scm->dev, sizeof(*hmi),
> + &addr[1], GFP_KERNEL, dma_attrs);

This function should handle arbitrary number of src and destination vms;
so start by calculating the hweight of the source, allocate the
appropriate amount of srcVM and dstVM space and then calculate the
offsets within that block for each entry.


Check and handle !hmi

> + hmi->mem_region.mem_addr = cpu_to_le64(mem_addr);
> + hmi->mem_region.mem_size = cpu_to_le64(mem_sz);
> +
> + addr[0] = addr[1] + sizeof(hmi->srcVm);
> + size[0] = sizeof(hmi->mem_region);
> +
> + ret = hweight_long(srcVm);
> + for (i = 0; i < ret; i++) {
> + hmi->srcVm[i] = cpu_to_le32(ffs(srcVm) - 0x1);

Subtract 1, rather than 0x1

> + srcVm ^= 1 << (ffs(srcVm) - 0x1);

Make this easier to read with:

for (...) {
vmid = ffs(srcVm) - 1;

hmi->srcVm[i] = cpu_to_le32(vmid);
srcVm &= ~BIT(vmid);
}

> + }
> + size[1] = ret * sizeof(srcVm);
> +
> + ret = newVm_sz/sizeof(struct qcom_scm_destVmPerm);
> + for (i = 0; i < ret; i++) {
> + hmi->destVm[i].destVm = cpu_to_le32(newVm[i].destVm);
> + hmi->destVm[i].destVmPerm = cpu_to_le32(newVm[i].destVmPerm);
> + hmi->destVm[i].ctx = 0;
> + hmi->destVm[i].ctx_size = 0;
> + }
> + addr[2] = addr[0] + sizeof(hmi->mem_region);
> + size[2] = ret * sizeof(struct qcom_scm_current_perm_info);
> +
> + ret = __qcom_

[PATCH v2 net-next 2/3] samples/bpf: add samples for more perf event types

[Alexei Starovoitov]

From: Teng Qin 

This commit adds test code to attach BPF to HW_CACHE and RAW type events
and updates clean-up logic to disable the perf events before closing pmu_fd.

This commit also adds test code to read SOFTWARE, HW_CACHE, RAW and dynamic
pmu events from BPF program using bpf_perf_event_read(). Refactored the
existing sample to fork individual task on each CPU, attach kprobe to
more controllable function, and more accurately check if each read on
every CPU returned with good value.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/bpf_helpers.h  |   3 +-
 samples/bpf/trace_event_user.c |  46 ++-
 samples/bpf/tracex6_kern.c |  28 +--
 samples/bpf/tracex6_user.c | 176 -
 4 files changed, 204 insertions(+), 49 deletions(-)

diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index 9a9c95f2c9fb..51e567bc70fc 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -31,7 +31,8 @@ static unsigned long long (*bpf_get_current_uid_gid)(void) =
(void *) BPF_FUNC_get_current_uid_gid;
 static int (*bpf_get_current_comm)(void *buf, int buf_size) =
(void *) BPF_FUNC_get_current_comm;
-static int (*bpf_perf_event_read)(void *map, int index) =
+static unsigned long long (*bpf_perf_event_read)(void *map,
+unsigned long long flags) =
(void *) BPF_FUNC_perf_event_read;
 static int (*bpf_clone_redirect)(void *ctx, int ifindex, int flags) =
(void *) BPF_FUNC_clone_redirect;
diff --git a/samples/bpf/trace_event_user.c b/samples/bpf/trace_event_user.c
index fa4336423da5..666761773fda 100644
--- a/samples/bpf/trace_event_user.c
+++ b/samples/bpf/trace_event_user.c
@@ -122,13 +122,14 @@ static void test_perf_event_all_cpu(struct 
perf_event_attr *attr)
 {
int nr_cpus = sysconf(_SC_NPROCESSORS_CONF);
int *pmu_fd = malloc(nr_cpus * sizeof(int));
-   int i;
+   int i, error = 0;
 
/* open perf_event on all cpus */
for (i = 0; i < nr_cpus; i++) {
pmu_fd[i] = sys_perf_event_open(attr, -1, i, -1, 0);
if (pmu_fd[i] < 0) {
printf("sys_perf_event_open failed\n");
+   error = 1;
goto all_cpu_err;
}
assert(ioctl(pmu_fd[i], PERF_EVENT_IOC_SET_BPF, prog_fd[0]) == 
0);
@@ -137,9 +138,13 @@ static void test_perf_event_all_cpu(struct perf_event_attr 
*attr)
system("dd if=/dev/zero of=/dev/null count=5000k");
print_stacks();
 all_cpu_err:
-   for (i--; i >= 0; i--)
+   for (i--; i >= 0; i--) {
+   ioctl(pmu_fd[i], PERF_EVENT_IOC_DISABLE, 0);
close(pmu_fd[i]);
+   }
free(pmu_fd);
+   if (error)
+   int_exit(0);
 }
 
 static void test_perf_event_task(struct perf_event_attr *attr)
@@ -150,7 +155,7 @@ static void test_perf_event_task(struct perf_event_attr 
*attr)
pmu_fd = sys_perf_event_open(attr, 0, -1, -1, 0);
if (pmu_fd < 0) {
printf("sys_perf_event_open failed\n");
-   return;
+   int_exit(0);
}
assert(ioctl(pmu_fd, PERF_EVENT_IOC_SET_BPF, prog_fd[0]) == 0);
assert(ioctl(pmu_fd, PERF_EVENT_IOC_ENABLE, 0) == 0);
@@ -175,11 +180,45 @@ static void test_bpf_perf_event(void)
.config = PERF_COUNT_SW_CPU_CLOCK,
.inherit = 1,
};
+   struct perf_event_attr attr_hw_cache_l1d = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_HW_CACHE,
+   .config =
+   PERF_COUNT_HW_CACHE_L1D |
+   (PERF_COUNT_HW_CACHE_OP_READ << 8) |
+   (PERF_COUNT_HW_CACHE_RESULT_ACCESS << 16),
+   .inherit = 1,
+   };
+   struct perf_event_attr attr_hw_cache_branch_miss = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_HW_CACHE,
+   .config =
+   PERF_COUNT_HW_CACHE_BPU |
+   (PERF_COUNT_HW_CACHE_OP_READ << 8) |
+   (PERF_COUNT_HW_CACHE_RESULT_MISS << 16),
+   .inherit = 1,
+   };
+   struct perf_event_attr attr_type_raw = {
+   .sample_freq = SAMPLE_FREQ,
+   .freq = 1,
+   .type = PERF_TYPE_RAW,
+   /* Intel Instruction Retired */
+   .config = 0xc0,
+   .inherit = 1,
+   };
 
test_perf_event_all_cpu(&attr_type_hw);
test_perf_event_task(&attr_type_hw);
test_perf_event_all_cpu(&attr_type_sw);
test_perf_event_task(&attr_type_sw);
+   test_perf_event_all_cpu(&attr_hw_cache_l1d);
+   test_perf_event_task(&attr_hw_cache_l1d);
+   test_perf_event_all_cpu(&attr_hw_cache_branch_miss);
+   test_perf_ev

[PATCH v2 net-next 0/3] bpf: Add BPF support to all perf_event

[Alexei Starovoitov]

v1->v2: address Peter's feedback. Refactor patch 1 to allow attaching
bpf programs to all event types and reading counters from all of them as well
patch 2 - more tests
patch 3 - address Dave's feedback and document bpf_perf_event_read()
and bpf_perf_event_output() properly

Teng Qin (3):
  perf, bpf: Add BPF support to all perf_event types
  samples/bpf: add samples for more perf event types
  bpf: update perf event helper functions documentation

 include/uapi/linux/bpf.h   |  11 ++-
 kernel/bpf/arraymap.c  |  26 +++---
 kernel/events/core.c   |   6 +-
 kernel/trace/bpf_trace.c   |   4 +-
 samples/bpf/bpf_helpers.h  |   3 +-
 samples/bpf/trace_event_user.c |  46 ++-
 samples/bpf/tracex6_kern.c |  28 +--
 samples/bpf/tracex6_user.c | 176 -
 tools/include/uapi/linux/bpf.h |  11 ++-
 9 files changed, 232 insertions(+), 79 deletions(-)

-- 
2.9.3

[PATCH v2 net-next 1/3] perf, bpf: Add BPF support to all perf_event types

[Alexei Starovoitov]

From: Teng Qin 

Allow BPF program to attach to all perf_event types supported
by the current bpf and perf code logic, including HW_CACHE, RAW,
and dynamic pmu events.

Also add support for reading these event counters using
bpf_perf_event_read() helper.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 kernel/bpf/arraymap.c| 26 +++---
 kernel/events/core.c |  6 +-
 kernel/trace/bpf_trace.c |  4 ++--
 3 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 5e00b2333c26..55ffa9949128 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -462,26 +462,22 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map 
*map,
 
event = perf_file->private_data;
ee = ERR_PTR(-EINVAL);
+   /* Per-task events are not supported */
+   if (event->attach_state & PERF_ATTACH_TASK)
+   goto err_out;
 
attr = perf_event_attrs(event);
if (IS_ERR(attr) || attr->inherit)
goto err_out;
+   /* TRACEPOINT and BREAKPOINT not supported in perf_event_read_local */
+   if (attr->type == PERF_TYPE_TRACEPOINT ||
+   attr->type == PERF_TYPE_BREAKPOINT)
+   goto err_out;
 
-   switch (attr->type) {
-   case PERF_TYPE_SOFTWARE:
-   if (attr->config != PERF_COUNT_SW_BPF_OUTPUT)
-   goto err_out;
-   /* fall-through */
-   case PERF_TYPE_RAW:
-   case PERF_TYPE_HARDWARE:
-   ee = bpf_event_entry_gen(perf_file, map_file);
-   if (ee)
-   return ee;
-   ee = ERR_PTR(-ENOMEM);
-   /* fall-through */
-   default:
-   break;
-   }
+   ee = bpf_event_entry_gen(perf_file, map_file);
+   if (ee)
+   return ee;
+   ee = ERR_PTR(-ENOMEM);
 
 err_out:
fput(perf_file);
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 6e75a5c9412d..52f667046599 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8037,12 +8037,8 @@ static int perf_event_set_bpf_prog(struct perf_event 
*event, u32 prog_fd)
bool is_kprobe, is_tracepoint;
struct bpf_prog *prog;
 
-   if (event->attr.type == PERF_TYPE_HARDWARE ||
-   event->attr.type == PERF_TYPE_SOFTWARE)
-   return perf_event_set_bpf_handler(event, prog_fd);
-
if (event->attr.type != PERF_TYPE_TRACEPOINT)
-   return -EINVAL;
+   return perf_event_set_bpf_handler(event, prog_fd);
 
if (event->tp_event->prog)
return -EEXIST;
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 460a031c77e5..8425bf193f39 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -248,8 +248,8 @@ BPF_CALL_2(bpf_perf_event_read, struct bpf_map *, map, u64, 
flags)
return -ENOENT;
 
event = ee->event;
-   if (unlikely(event->attr.type != PERF_TYPE_HARDWARE &&
-event->attr.type != PERF_TYPE_RAW))
+   if (unlikely(event->attr.type == PERF_TYPE_SOFTWARE &&
+event->attr.config == PERF_COUNT_SW_BPF_OUTPUT))
return -EINVAL;
 
/* make sure event is local and doesn't have pmu::count */
-- 
2.9.3

[PATCH v2 net-next 3/3] bpf: update perf event helper functions documentation

[Alexei Starovoitov]

From: Teng Qin 

This commit updates documentation of the bpf_perf_event_output and
bpf_perf_event_read helpers to match their implementation.

Signed-off-by: Teng Qin 
Signed-off-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h   | 11 +++
 tools/include/uapi/linux/bpf.h | 11 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 94dfa9def355..e78aece03628 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -313,8 +313,11 @@ union bpf_attr {
  * @flags: room for future extensions
  * Return: 0 on success or negative error
  *
- * u64 bpf_perf_event_read(&map, index)
- * Return: Number events read or error code
+ * u64 bpf_perf_event_read(map, flags)
+ * read perf event counter value
+ * @map: pointer to perf_event_array map
+ * @flags: index of event in the map or bitmask flags
+ * Return: value of perf event counter read or error code
  *
  * int bpf_redirect(ifindex, flags)
  * redirect to another netdev
@@ -328,11 +331,11 @@ union bpf_attr {
  * @skb: pointer to skb
  * Return: realm if != 0
  *
- * int bpf_perf_event_output(ctx, map, index, data, size)
+ * int bpf_perf_event_output(ctx, map, flags, data, size)
  * output perf raw sample
  * @ctx: struct pt_regs*
  * @map: pointer to perf_event_array map
- * @index: index of event in the map
+ * @flags: index of event in the map or bitmask flags
  * @data: data on stack to be output as raw data
  * @size: size of data
  * Return: 0 on success or negative error
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 94dfa9def355..e78aece03628 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -313,8 +313,11 @@ union bpf_attr {
  * @flags: room for future extensions
  * Return: 0 on success or negative error
  *
- * u64 bpf_perf_event_read(&map, index)
- * Return: Number events read or error code
+ * u64 bpf_perf_event_read(map, flags)
+ * read perf event counter value
+ * @map: pointer to perf_event_array map
+ * @flags: index of event in the map or bitmask flags
+ * Return: value of perf event counter read or error code
  *
  * int bpf_redirect(ifindex, flags)
  * redirect to another netdev
@@ -328,11 +331,11 @@ union bpf_attr {
  * @skb: pointer to skb
  * Return: realm if != 0
  *
- * int bpf_perf_event_output(ctx, map, index, data, size)
+ * int bpf_perf_event_output(ctx, map, flags, data, size)
  * output perf raw sample
  * @ctx: struct pt_regs*
  * @map: pointer to perf_event_array map
- * @index: index of event in the map
+ * @flags: index of event in the map or bitmask flags
  * @data: data on stack to be output as raw data
  * @size: size of data
  * Return: 0 on success or negative error
-- 
2.9.3

Re: [PATCH net-next v3 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[Florian Fainelli]

On May 24, 2017 4:17:39 AM PDT, "Andrey Jr. Melnikov"  
wrote:
>In gmane.linux.kernel sean.w...@mediatek.com wrote:
>> From: Sean Wang 
>
>> MT7530 is a 7-ports Gigabit Ethernet Switch that could be found on
>> Mediatek router platforms such as MT7623A or MT7623N platform which
>> includes 7-port Gigabit Ethernet MAC and 5-port Gigabit Ethernet PHY.
>> Among these ports, The port from 0 to 4 are the user ports connecting
>> with the remote devices while the port 5 and 6 are the CPU ports
>> connecting into Mediatek Ethernet GMAC.
>
>> For port 6, it can communicate with the CPU via Mediatek Ethernet
>GMAC
>> through either the TRGMII or RGMII which could be controlled by
>phy-mode
>> in the dt-bindings to specify which mode is preferred to use. And for
>> port 5, only RGMII can be specified. However, currently, only port 6
>is
>> being supported in this DSA driver.
>
>> The driver is made with the reference to qca8k and other existing DSA
>> driver. The most of the essential callbacks of the DSA are already
>> support in the driver, including tag insert for user port
>distinguishing,
>> port control, bridge offloading, STP setup and ethtool operation to
>allow
>> DSA to model each user port into a standalone netdevice as the other
>DSA
>> driver had done.
>
>What about JUMBO frames and large MTU support? devlink support?

We don't have a ndo_change_mtu callback implemented for DSA network devices but 
that is probably how we should do it. Regarding devlink, Andrew added basic 
support for it but unlike mlxsw it is currently of mild interest. Do you have 
something specific in mind with devlink?

-- 
Florian

[PATCH] ARM: dts: rockchip:add sd card support

[Eddie Cai]

firefly reload board not support sd card yet. so support it.

Signed-off-by: Eddie Cai 
---
 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi 
b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
index 413b61f..2f41209 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
@@ -57,6 +57,17 @@
clock-output-names = "ext_gmac";
};
 
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio7 RK_PB3 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc_pwr>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   startup-delay-us = <10>;
+   vin-supply = <&vcc_io>;
+   };
 
vcc_flash: flash-regulator {
compatible = "regulator-fixed";
@@ -281,6 +292,26 @@
rockchip,pins = <4 8 RK_FUNC_GPIO &pcfg_output_high>;
};
};
+
+   sdmmc {
+   sdmmc_pwr: sdmmc-pwr {
+   rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+   };
+};
+
+&sdmmc {
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   card-detect-delay = <200>;
+   disable-wp;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sdmmc_clk>, <&sdmmc_cmd>, <&sdmmc_cd>, <&sdmmc_bus4>;
+   vmmc-supply = <&vcc_sd>;
+   vqmmc-supply = <&vccio_sd>;
+   status = "okay";
 };
 
 &tsadc {
-- 
1.9.1

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

[Christoph Hellwig]

On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote:
> Hi sean,
> 
> On 05/25/2017 11:30 PM, Sean Paul wrote:
> > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:
> > > The system would crash when trying to alloc zero sized gem buffer:
> > > [6.712435] Unable to handle kernel NULL pointer dereference at 
> > > virtual address 0010 <--ZERO_SIZE_PTR
> > > ...
> > > [6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec
> > 
> > It's unfortunate that you didn't include the entire stack trace. From code
> > inspection, it seems like the 0 size comes from the fb_probe path? Is there
> > somewhere in the helpers that you could check the mode is sane so all 
> > drivers
> > can benefit?
> 
> hmm, sorry, i was testing it on chromeos 4.4 kernel, it turns out that we
> have a custom ioctl for userspace to create gem buffer(the same as exynos
> drm), which might get the the 0 size.
> 
> but on upstream kernel, it could only be called by dump_create, and the
> drm_mode_create_dumb_ioctl already did the size check.
> 
> will resent this patch, and rewrite the commit message, thanx.

That suggests that this patch isn't needed at all.

Re: [PATCH v2] PCI/msi: fix the pci_alloc_irq_vectors_affinity stub

[Christoph Hellwig]

Bjorn,

can you take this regression fix and sent it to Linux before -rc3?
I had hope we could get it into -rc2 but already missed that, and
I haven't heard a comment since..

On Sat, May 20, 2017 at 06:59:54PM +0200, Christoph Hellwig wrote:
> We need to return an error for any call that asks for MSI / MSI-X
> vectors only, so that non-trivial fallback logic can work properly.
> 
> Also valid dev->irq and use the "correct" errno value based on feedback
> from Linus.
> 
> Signed-off-by: Christoph Hellwig 
> Reported-by: Steven Rostedt 
> Fixes: aff17164 ("PCI: Provide sensible IRQ vector alloc/free routines")
> ---
> 
> Changes from V1:
>  - use == comparism
>  - return -ENOSPC
>  - verify dev->irq
> 
>  include/linux/pci.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 33c2b0b77429..fc2e832d7b9c 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1342,9 +1342,9 @@ pci_alloc_irq_vectors_affinity(struct pci_dev *dev, 
> unsigned int min_vecs,
>  unsigned int max_vecs, unsigned int flags,
>  const struct irq_affinity *aff_desc)
>  {
> - if (min_vecs > 1)
> - return -EINVAL;
> - return 1;
> + if ((flags & PCI_IRQ_LEGACY) && min_vecs == 1 && dev->irq)
> + return 1;
> + return -ENOSPC;
>  }
>  
>  static inline void pci_free_irq_vectors(struct pci_dev *dev)
> -- 
> 2.11.0
---end quoted text---

Re: [PATCH V2 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Michael Bringmann  writes:

> Removing or adding memory via the PowerPC hotplug interface shows
> anomalies in the association between memory and nodes.

What anomalies? Please describe the actual problem you're seeing, with
details, and why you think this is the correct fix.

This is a revert of 3af229f2071f ("powerpc/numa: Reset node_possible_map
to only node_online_map"), so please explain why all the things
mentioned in the change log for that commit are either wrong or no
longer true.

cheers

[PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch fixes a OOPs originally introduced by:

   commit bb048357dad6d604520c91586334c9c230366a14
   Author: Nicholas Bellinger 
   Date:   Thu Sep 5 14:54:04 2013 -0700

   iscsi-target: Add sk->sk_state_change to cleanup after TCP failure

which would trigger a NULL pointer dereference when a TCP connection
was closed asynchronously via iscsi_target_sk_state_change(), but only
when the initial PDU processing in iscsi_target_do_login() from iscsi_np
process context was blocked waiting for backend I/O to complete.

To address this issue, this patch makes the following changes.

First, it introduces some common helper functions used for checking
socket closing state, checking login_flags, and atomically checking
socket closing state + setting login_flags.

Second, it introduces a LOGIN_FLAGS_INITIAL_PDU bit to know when a TCP
connection has dropped via iscsi_target_sk_state_change(), but the
initial PDU processing within iscsi_target_do_login() in iscsi_np
context is still running.  For this case, it sets LOGIN_FLAGS_CLOSED,
but doesn't invoke schedule_delayed_work().

The original NULL pointer dereference case reported by MNC is now handled
by iscsi_target_do_login() doing a iscsi_target_sk_check_close() before
transitioning to FFP to determine when the socket has already closed,
or iscsi_target_start_negotiation() if the login needs to exchange
more PDUs (eg: iscsi_target_do_login returned 0) but the socket has
closed.  For both of these cases, the cleanup up of remaining connection
resources will occur in iscsi_target_start_negotiation() from iscsi_np
process context once the failure is detected.

Finally, to handle to case where iscsi_target_sk_state_change() is
called after the initial PDU procesing is complete, it now invokes
conn->login_work -> iscsi_target_do_login_rx() to perform cleanup once
existing iscsi_target_sk_check_close() checks detect connection failure.
For this case, the cleanup of remaining connection resources will occur
in iscsi_target_do_login_rx() from delayed workqueue process context
once the failure is detected.

Reported-by: Mike Christie 
Cc: Mike Christie 
Reported-by: Hannes Reinecke 
Cc: Hannes Reinecke 
Cc: Sagi Grimberg 
Cc: Varun Prakash 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/iscsi/iscsi_target_nego.c | 194 +--
 include/target/iscsi/iscsi_target_core.h |   1 +
 2 files changed, 133 insertions(+), 62 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target_nego.c 
b/drivers/target/iscsi/iscsi_target_nego.c
index 7ccc9c1..6f88b31 100644
--- a/drivers/target/iscsi/iscsi_target_nego.c
+++ b/drivers/target/iscsi/iscsi_target_nego.c
@@ -493,14 +493,60 @@ static void iscsi_target_restore_sock_callbacks(struct 
iscsi_conn *conn)
 
 static int iscsi_target_do_login(struct iscsi_conn *, struct iscsi_login *);
 
-static bool iscsi_target_sk_state_check(struct sock *sk)
+static bool __iscsi_target_sk_check_close(struct sock *sk)
 {
if (sk->sk_state == TCP_CLOSE_WAIT || sk->sk_state == TCP_CLOSE) {
-   pr_debug("iscsi_target_sk_state_check: 
TCP_CLOSE_WAIT|TCP_CLOSE,"
+   pr_debug("__iscsi_target_sk_check_close: 
TCP_CLOSE_WAIT|TCP_CLOSE,"
"returning FALSE\n");
-   return false;
+   return true;
}
-   return true;
+   return false;
+}
+
+static bool iscsi_target_sk_check_close(struct iscsi_conn *conn)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   read_lock_bh(&sk->sk_callback_lock);
+   state = (__iscsi_target_sk_check_close(sk) ||
+test_bit(LOGIN_FLAGS_CLOSED, &conn->login_flags));
+   read_unlock_bh(&sk->sk_callback_lock);
+   }
+   return state;
+}
+
+static bool iscsi_target_sk_check_flag(struct iscsi_conn *conn, unsigned int 
flag)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   read_lock_bh(&sk->sk_callback_lock);
+   state = test_bit(flag, &conn->login_flags);
+   read_unlock_bh(&sk->sk_callback_lock);
+   }
+   return state;
+}
+
+static bool iscsi_target_sk_check_and_clear(struct iscsi_conn *conn, unsigned 
int flag)
+{
+   bool state = false;
+
+   if (conn->sock) {
+   struct sock *sk = conn->sock->sk;
+
+   write_lock_bh(&sk->sk_callback_lock);
+   state = (__iscsi_target_sk_check_close(sk) ||
+test_bit(LOGIN_FLAGS_CLOSED, &conn->login_flags));
+   if (!state)
+   clear_bit(flag, &conn->login_flags);
+   write_unlock_bh(&sk->sk_callback_lock);
+   }
+   return state;
 }
 
 static void iscsi_target_login_drop(struct iscsi_conn *conn, struct 
iscsi_login *login)
@@ -540,6 +586,20 @@ static void iscsi_target_do_login_rx(struct work_struct 
*

[PATCH] Input: mousedev - fix implicit conversion warning

[Nick Desaulniers]

Clang warns:

drivers/input/mousedev.c:653:63: error: implicit conversion from 'int'
to 'signed char' changes value from 200 to -56
[-Wconstant-conversion]
  client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
~ ^~~

As far as I can tell, from

http://www.computer-engineering.org/ps2mouse/

Under "Command Set" > "0xE9 (Status Request)"

the value 200 is a valid sample rate. An explicit cast silences this
warning.

Signed-off-by: Nick Desaulniers 
---
 drivers/input/mousedev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index 0e0ff84088fd..816e2431bba8 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -650,7 +650,9 @@ static void mousedev_generate_response(struct 
mousedev_client *client,
break;
 
case 0xe9: /* Get info */
-   client->ps2[1] = 0x60; client->ps2[2] = 3; client->ps2[3] = 200;
+   client->ps2[1] = 0x60;
+   client->ps2[2] = 3;
+   client->ps2[3] = (char) 200;
client->bufsiz = 4;
break;
 
-- 
2.11.0

Ich brauche deine Hilfe!

[Hubert Guillaud]

Lieber Freund,

Ich bin Frau Dionisia Denis Perman aus Island, verheiratet mit Late Engineer
Denis Perman {PhD}, der mit MULTINATIONAL OIL COMPANY EXXON AS A gearbeitet hat
DRILLING RIG SUPPLIER in Kuwait seit 19 Jahren, bevor er auf der
22. August 2009. Wir waren seit vierundzwanzig Jahren verheiratet
Kind. Er starb nach einer kurzen Krankheit, die nur vier Tage dauerte.
Vor seinem Tod hat er die Summe von USD 10.142.728,00 Dollar
Mit einer Kurierfirma in Indien und dieser Fonds ist derzeit mit dem Kurier 
warten auf meine
Auszahlung als Begünstigter und nächste Angehörige der Mittel. Kürzlich, meine
Doktor sagte mir, dass ich nicht für die nächsten acht Monate dauern würde
Krebsproblem Nachdem ich meinen Zustand gekannt habe, habe ich beschlossen, 
dies zu spenden
Fonds für eine Kirche, Organisation oder gute Person, die dies nutzen wird
Geld in gutem Glauben.

Ich habe diese Entscheidung getroffen, weil ich kein Kind habe, das erben wird
dieses Geld. Ich hielt diese Kaution bis heute; Deshalb bin ich
Diese Entscheidung treffen Ich glaube nicht, dass ich ein Telefon brauchen werde
Kommunikation in dieser Hinsicht wegen der Vertraulichkeit dieser
Transaktion. Nach deiner Antwort werde ich dir den Kontakt des Kuriers geben. 
ich
Wird auch ein Genehmigungsschreiben an den Kurier ausstellen, der beweisen wird
Sie der gegenwärtige Begünstigte dieses Geldes. So solltest du mir deine 
Adresse, deinen Namen, dein Land und deine Hand schicken.

Erwarten Sie Ihre Antworten und Gott segnen Sie.
Frau Dionisia Denis Perman

[PATCH linux-next v3 1/1] spi: imx: dynamic burst length adjust for PIO mode

[jiada_wang]

From: Jiada Wang 

previously burst length (BURST_LENGTH) is always set to equal
to bits_per_word, causes a 10us gap between each word in
transfer, which significantly affects performance.

This patch uses 32 bits transfer to simulate lower bits transfer,
and adjusts burst length runtimely to use biggeest burst length
as possible to reduce the gaps in transfer for PIO mode.

Signed-off-by: Jiada Wang 
---

Changes in v2:
* used cpu_to_* functions to ensure this patch works for both
  little & big endian kernel.

Changes in v3:
* Only allow dynamic burst in PIO mode
* Avoid direct manipulation of tx_buf & rx_buf

 drivers/spi/spi-imx.c | 156 +++---
 1 file changed, 148 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b402530..54f7c31 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -56,9 +56,11 @@
 
 /* The maximum  bytes that a sdma BD can transfer.*/
 #define MAX_SDMA_BD_BYTES  (1 << 15)
+#define MX51_ECSPI_CTRL_MAX_BURST  512
 struct spi_imx_config {
unsigned int speed_hz;
unsigned int bpw;
+   unsigned int len;
 };
 
 enum spi_imx_devtype {
@@ -97,12 +99,14 @@ struct spi_imx_data {
unsigned int bytes_per_word;
unsigned int spi_drctl;
 
-   unsigned int count;
+   unsigned int count, count_index;
void (*tx)(struct spi_imx_data *);
void (*rx)(struct spi_imx_data *);
void *rx_buf;
const void *tx_buf;
unsigned int txfifo; /* number of words pushed in tx FIFO */
+   unsigned int dynamic_burst, bpw_rx;
+   unsigned int bpw_w;
 
/* DMA */
bool usedma;
@@ -238,6 +242,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
return false;
 
spi_imx->wml = i;
+   spi_imx->dynamic_burst = 0;
 
return true;
 }
@@ -252,6 +257,7 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_CTRL_PREDIV_OFFSET  12
 #define MX51_ECSPI_CTRL_CS(cs) ((cs) << 18)
 #define MX51_ECSPI_CTRL_BL_OFFSET  20
+#define MX51_ECSPI_CTRL_BL_MASK(0xfff << 20)
 
 #define MX51_ECSPI_CONFIG  0x0c
 #define MX51_ECSPI_CONFIG_SCLKPHA(cs)  (1 << ((cs) +  0))
@@ -279,6 +285,95 @@ static bool spi_imx_can_dma(struct spi_master *master, 
struct spi_device *spi,
 #define MX51_ECSPI_TESTREG 0x20
 #define MX51_ECSPI_TESTREG_LBC BIT(31)
 
+static u32 spi_imx_u32_swap_u16(u32 val)
+{
+   u32 data = val;
+   u16 *temp = (u16 *)&data;
+
+   *temp = cpu_to_be16(*temp);
+   *(temp + 1) = cpu_to_be16(*(temp + 1));
+
+   data = cpu_to_be32(data);
+
+   return data;
+}
+
+static void spi_imx_buf_rx_swap_u32(struct spi_imx_data *spi_imx)
+{
+   unsigned int val = readl(spi_imx->base + MXC_CSPIRXDATA);
+
+   if (spi_imx->rx_buf) {
+   if (spi_imx->bpw_w == 1)
+   val = cpu_to_be32(val);
+   else if (spi_imx->bpw_w == 2)
+   val = spi_imx_u32_swap_u16(val);
+
+   *(u32 *)spi_imx->rx_buf = val;
+   spi_imx->rx_buf += sizeof(u32);
+   }
+}
+
+static void spi_imx_buf_rx_swap(struct spi_imx_data *spi_imx)
+{
+   if (!spi_imx->bpw_rx) {
+   spi_imx_buf_rx_swap_u32(spi_imx);
+   return;
+   }
+
+   if (spi_imx->bpw_w == 1)
+   spi_imx_buf_rx_u8(spi_imx);
+   else if (spi_imx->bpw_w == 2)
+   spi_imx_buf_rx_u16(spi_imx);
+}
+
+static void spi_imx_buf_tx_swap_u32(struct spi_imx_data *spi_imx)
+{
+   u32 val = 0;
+
+   if (spi_imx->tx_buf) {
+   val = *(u32 *)spi_imx->tx_buf;
+   spi_imx->tx_buf += sizeof(u32);
+   }
+
+   spi_imx->count -= sizeof(u32);
+   if (spi_imx->bpw_w == 1)
+   val = cpu_to_be32(val);
+   else if (spi_imx->bpw_w == 2)
+   val = spi_imx_u32_swap_u16(val);
+
+   writel(val, spi_imx->base + MXC_CSPITXDATA);
+}
+
+static void spi_imx_buf_tx_swap(struct spi_imx_data *spi_imx)
+{
+   u32 ctrl, val;
+
+   if (spi_imx->count == spi_imx->count_index) {
+   spi_imx->count_index = spi_imx->count > sizeof(u32) ?
+   spi_imx->count % sizeof(u32) : 0;
+   ctrl = readl(spi_imx->base + MX51_ECSPI_CTRL);
+   ctrl &= ~MX51_ECSPI_CTRL_BL_MASK;
+   if (spi_imx->count >= sizeof(u32)) {
+   val = spi_imx->count - spi_imx->count_index;
+   } else {
+   val = spi_imx->bpw_w;
+   spi_imx->bpw_rx = 1;
+   }
+   ctrl |= ((val * 8 - 1) << MX51_ECSPI_CTRL_BL_OFFSET);
+   writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
+   }
+
+   if (spi_imx->count >= sizeof(u32)) {
+   spi_imx_buf_tx_swap_u32(spi_imx);
+   return;
+   }
+
+   i

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

[Xunlei Pang]

On 05/26/2017 at 10:49 AM, Dave Young wrote:
> Ccing Xunlei he is reading the patches see what need to be done for
> kdump. There should still be several places to handle to make kdump work.
>
> On 05/18/17 at 07:01pm, Borislav Petkov wrote:
>> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
>>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can
>>> determine if SME is active.
>> But why do user-space tools need to know that?
>>
>> I mean, when we load the kdump kernel, we do it with the first kernel,
>> with the kexec_load() syscall, AFAICT. And that code does a lot of
>> things during that init, like machine_kexec_prepare()->init_pgtable() to
>> prepare the ident mapping of the second kernel, for example.
>>
>> What I'm aiming at is that the first kernel knows *exactly* whether SME
>> is enabled or not and doesn't need to tell the second one through some
>> sysfs entries - it can do that during loading.
>>
>> So I don't think we need any userspace things at all...
> If kdump kernel can get the SME status from hardware register then this
> should be not necessary and this patch can be dropped.

Yes, I also agree with dropping this one.

Regards,
Xunlei

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

[Sricharan R]

Hi Bjorn,

On 5/26/2017 12:33 AM, Bjorn Andersson wrote:
> On Mon 22 May 06:26 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:
>> On 5/22/2017 4:07 PM, Sricharan R wrote:
>>> Hi,
>>>
>>> On 5/22/2017 3:03 PM, Dwivedi, Avaneesh Kumar (avani) wrote:

 On 5/20/2017 8:25 AM, Sricharan R wrote:
> Hi Bjorn/Avaneesh,
>
> On 5/16/2017 11:32 PM, Avaneesh Kumar Dwivedi wrote:
> [..]
>> -
>> -size = readl(qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
>> -if (!size) {
>> -boot_addr = relocate ? qproc->mpss_phys : min_addr;
>> -writel(boot_addr, qproc->rmb_base + RMB_PMI_CODE_START_REG);
>> -writel(RMB_CMD_LOAD_READY, qproc->rmb_base + 
>> RMB_MBA_COMMAND_REG);
>> -}
>> -
>>size += phdr->p_memsz;
>> -writel(size, qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
>>}
> So while moving this down, can we use qcom_mdt_load instead for
> the mpss image loading part above ?
 qcom_mdt_load() can not be used to load segments for mpss, as MPSS
 blobs are self authenticated.  while qcom_mdt_load() is used in
 cases where authentication of loaded blobs is done by trustzone.
 for that qcom_mdt_load() does extra steps to send pas_id to
 trustzone and mem_setup() etc.
>>> Right, so my intention of asking this was if the code which does the
>>> calculation and loads the segments in qcom_mdt_load can somehow be
>>> abstracted out, so that future self authenticating rproc (even mpss
>>> in this case) can use them to load mdt ?
>> As i understand, you want to replace the piece of code which does
>> parse mdt and load individual firmware blobs in a separate routine.
>> So that it can be called by any one without again doing parsing and
>> loading for self authentication.?  Till now only MPSS does rely on
>> self authentication, all other subsystems use qcom_mdt_load().  I
>> think this is reason why the qcom_mdt_load() equivalent routine has
>> not been used.  Bjorn may further add in this.
> 
> I have not been able to come up with a clean way to provide a useful
> mdt-loader abstraction that works for the SCM PILs, the
> self-authenticated PILs and the non-PIL SCM users.
> 
> Further more with the upcoming ramdump support we will need to extract
> segment information from the mdt header, so we will have to revisit this
> topic.
> 
> 
> Regardless, I would prefer that we follow up with such refactoring after
> getting this series sorted out.
> 

ok, agree.  While trying to add Q6 support for ipq8074, which is again
a self-authenticating PIL with mdt, i can try this.

>>>
>> +/* Transfer ownership of modem region with modem fw */
>> +boot_addr = relocate ? qproc->mpss_phys : min_addr;
>> +writel(boot_addr, qproc->rmb_base + RMB_PMI_CODE_START_REG);
>> +writel(RMB_CMD_LOAD_READY, qproc->rmb_base + RMB_MBA_COMMAND_REG);
>> +writel(size, qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
> For ipq8074 [1], wcnss core has an Q6V5 version of the ip for
> which the initialization/boot sequence is pretty much the same
> as that has been added for msm8996 in this series. So wanted to
> understand if its better to use this remoteproc itself by
> keeping the Q6 and mpss parts separately (or) add a new
> remoteproc ?
 Bjorn can better answer this query, but i believe this remoteproc
 can be extended to load mpss part by adding private initialization
 for the IP.
>>> ya, the mpss part can be separated out, so that this can be a Q6 +
>>> MPSS (or) Q6 + WCNSS remoteproc. Was asking this to get the right
>>> way for adding the Q6 + WCNSS remoteproc, as the Q6 part is same
>>> what you have added for msm8996.
>> Again, i believe yes but leave Bjorn to make final comment.
> 
> It definitely sounds like there's room for reuse here, how much of the
> initialization and authentication sequences are common between the two?

The initialization sequence is exactly the same as what was done for
msm8996(Q6) one added in this series. So for reusing this driver for Q6,
the Q6 + MPSS has to be decoupled and driver has to look common for
Q6 + any, (ie) Q6 + mpss (or) Q6 + wcnss. Incase if that's not neat,
atleast the Q6 initialization sequence can be reused.

Regards,
 Sricharan

> 
> Regards,
> Bjorn
> 

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

Re: [PATCH V4 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

[Viresh Kumar]

On 26-04-17, 11:41, Lukasz Luba wrote:
> Hi Viresh,
> 
> I went through the v4 code and it looks good to me.
> Feel free to add for the v4 series
> Reviewed-by: Lukasz Luba 

@Eduardo: You missed adding this to the patches.

-- 
viresh

RE: [PATCH] pinctrl/amd: Use regular interrupt instead of chained

[Shah, Nehal-bakulchandra]

Hi Thomas,

Thanks for the patch. However, we have received this issue from multiple people 
and different disro but it occurs only on Gigabyte hardware. With reference AM4 
ryzen board we are not facing this issue.
We are in discussion with gigabyte to check the BIOS part. Once we have clarity 
on that, we can consider driver part. Also, this code is running on multiple 
platform of different customers so changing directly at this point of time may 
be risky in my point of view. Requesting you to hold this patch till we get 
clarity on bios end.

Thanks for your understanding.

Regards

Nehal

-Original Message-
From: linux-gpio-ow...@vger.kernel.org 
[mailto:linux-gpio-ow...@vger.kernel.org] On Behalf Of Thomas Gleixner
Sent: Wednesday, May 24, 2017 2:54 AM
To: LKML 
Cc: Linus Walleij ; linux-g...@vger.kernel.org; 
Borislav Petkov ; Xue, Ken 
Subject: [PATCH] pinctrl/amd: Use regular interrupt instead of chained

The AMD pinctrl driver uses a chained interrupt to demultiplex the GPIO 
interrupts. Kevin Vandeventer reported, that his new AMD Ryzen locks up hard on 
boot when the AMD pinctrl driver is initialized. The reason is an interrupt 
storm. It's not clear whether that's caused by hardware or firmware or both.

Using chained interrupts on X86 is a dangerous endavour. If a system is 
misconfigured or the hardware buggy there is no safety net to catch an 
interrupt storm.

Convert the driver to use a regular interrupt for the demultiplex handler. This 
allows the interrupt storm detector to catch the malfunction and lets the 
system boot up.

This should be backported to stable because it's likely that more users run 
into this problem as the AMD Ryzen machines are spreading.

Reported-by: Kevin Vandeventer
Link: https://bugzilla.suse.com/show_bug.cgi?id=1034261
Signed-off-by: Thomas Gleixner 
---
 drivers/pinctrl/pinctrl-amd.c |   91 ++
 1 file changed, 41 insertions(+), 50 deletions(-)

--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -495,64 +495,54 @@ static struct irq_chip amd_gpio_irqchip
.flags= IRQCHIP_SKIP_SET_WAKE,
 };
 
-static void amd_gpio_irq_handler(struct irq_desc *desc)
+#define PIN_IRQ_PENDING(BIT(INTERRUPT_STS_OFF) | BIT(WAKE_STS_OFF))
+
+static irqreturn_t amd_gpio_irq_handler(int irq, void *dev_id)
 {
-   u32 i;
-   u32 off;
-   u32 reg;
-   u32 pin_reg;
-   u64 reg64;
-   int handled = 0;
-   unsigned int irq;
+   struct amd_gpio *gpio_dev = dev_id;
+   struct gpio_chip *gc = &gpio_dev->gc;
+   irqreturn_t ret = IRQ_NONE;
+   unsigned int i, irqnr;
unsigned long flags;
-   struct irq_chip *chip = irq_desc_get_chip(desc);
-   struct gpio_chip *gc = irq_desc_get_handler_data(desc);
-   struct amd_gpio *gpio_dev = gpiochip_get_data(gc);
+   u32 *regs, regval;
+   u64 status, mask;
 
-   chained_irq_enter(chip, desc);
-   /*enable GPIO interrupt again*/
+   /* Read the wake status */
raw_spin_lock_irqsave(&gpio_dev->lock, flags);
-   reg = readl(gpio_dev->base + WAKE_INT_STATUS_REG1);
-   reg64 = reg;
-   reg64 = reg64 << 32;
-
-   reg = readl(gpio_dev->base + WAKE_INT_STATUS_REG0);
-   reg64 |= reg;
+   status = readl(gpio_dev->base + WAKE_INT_STATUS_REG1);
+   status <<= 32;
+   status |= readl(gpio_dev->base + WAKE_INT_STATUS_REG0);
raw_spin_unlock_irqrestore(&gpio_dev->lock, flags);
 
-   /*
-* first 46 bits indicates interrupt status.
-* one bit represents four interrupt sources.
-   */
-   for (off = 0; off < 46 ; off++) {
-   if (reg64 & BIT(off)) {
-   for (i = 0; i < 4; i++) {
-   pin_reg = readl(gpio_dev->base +
-   (off * 4 + i) * 4);
-   if ((pin_reg & BIT(INTERRUPT_STS_OFF)) ||
-   (pin_reg & BIT(WAKE_STS_OFF))) {
-   irq = irq_find_mapping(gc->irqdomain,
-   off * 4 + i);
-   generic_handle_irq(irq);
-   writel(pin_reg,
-   gpio_dev->base
-   + (off * 4 + i) * 4);
-   handled++;
-   }
-   }
+   /* Bit 0-45 contain the relevant status bits */
+   status &= (1ULL << 46) - 1;
+   regs = gpio_dev->base;
+   for (mask = 1, irqnr = 0; status; mask <<= 1, regs += 4, irqnr += 4) {
+   if (!(status & mask))
+   continue;
+   status &= ~mask;
+
+   /* Each status bit covers four pins */
+   for (i = 0; i < 4; i++) {
+   regval

[PATCH] selftests/ftrace: Add a testcase for many kprobe events

[Masami Hiramatsu]

Add a testcase to test kprobes via ftrace interface
with many concurrent kprobe events.

This tries to add many kprobe events (up to 256) on
kernel functions. To avoid making ftrace-based
kprobes (kprobes on fentry), it skips first N bytes
(on x86 N=5, on ppc or arm N=4) of function entry.
After that, it enables all those events, disable it,
and remove it.

Since the unoptimization buffer reclaiming will
be delayed, after removing events, it will wait
enough time.

Signed-off-by: Masami Hiramatsu 
Suggested-by: Steven Rostedt 
---
 This ensures following bug is fixed and no regression.

 https://lkml.org/lkml/2017/5/25/218
---
 .../ftrace/test.d/kprobe/multiple_kprobes.tc   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc

diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
new file mode 100644
index 000..f4d1ff7
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/multiple_kprobes.tc
@@ -0,0 +1,21 @@
+#!/bin/sh
+# description: Register/unregister many kprobe events
+
+# ftrace fentry skip size depends on the machine architecture.
+# Currently HAVE_KPROBES_ON_FTRACE defined on x86 and powerpc
+case `uname -m` in
+  x86_64|i[3456]86) OFFS=5;;
+  ppc*) OFFS=4;;
+  *) OFFS=0;;
+esac
+
+echo "Setup up to 256 kprobes"
+grep t /proc/kallsyms | cut -f3 -d" " | grep -v .*\\..* | \
+head -n 256 | while read i; do echo p ${i}+${OFFS} ; done > kprobe_events ||:
+
+echo 1 > events/kprobes/enable
+echo 0 > events/kprobes/enable
+echo > kprobe_events
+echo "Waiting for unoptimizing & freeing"
+sleep 5
+echo "Done"

Re: [Patch v2] mm/vmscan: fix unsequenced modification and access warning

[Nick Desaulniers]

On Tue, May 16, 2017 at 10:27:46AM +0200, Michal Hocko wrote:
> I guess it is worth reporting this to clang bugzilla. Could you take
> care of that Nick?

>From https://bugs.llvm.org//show_bug.cgi?id=33065#c5
it seems that this is indeed a sequence bug in the previous version of
this code and not a compiler bug.  You can read that response for the
properly-cited wording but my TL;DR/understanding is for the given code:

struct foo bar = {
  .a = (c = 0),
  .b = c,
};

That the compiler is allowed to reorder the initializations of bar.a and
bar.b, so what the value of c here might not be what you expect.

[git pull] drm fixes for v4.12-rc3

[Dave Airlie]

Hi Linus,

Not a whole lot happening here, a set of amdgpu fixes and one core
deadlock fix, and some misc drivers fixes.

Dave.


The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:

  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc3

for you to fetch changes up to bc1f0e04da20473d6feab0cd9ac638a348d5:

  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-05-26
11:51:55 +1000)


misc and amdgpu fixes


Alex Deucher (4):
  drm/amdgpu/ci: disable mclk switching for high refresh rates (v2)
  drm/radeon/ci: disable mclk switching for high refresh rates (v2)
  drm/amd/powerplay/smu7: add vblank check for mclk switching (v2)
  drm/amd/powerplay/smu7: disable mclk switching for high refresh rates

Christian König (1):
  drm/amdgpu: fix fundamental suspend/resume issue

Chunming Zhou (1):
  drm/amdgpu: fix NULL pointer panic of emit_gds_switch

Dan Carpenter (1):
  drm/amd/powerplay: fix a signedness bugs

Daniel Vetter (1):
  drm: Fix deadlock retry loop in page_flip_ioctl

Dave Airlie (2):
  Merge tag 'drm-misc-fixes-2017-05-25' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Gabriel Krisman Bertazi (1):
  drm: qxl: Delay entering atomic context during cursor update

Lukas Wunner (1):
  drm/radeon: Fix oops upon driver load on PowerXpress laptops

Lyude (1):
  drm/radeon: Unbreak HPD handling for r600+

Patrik Jakobsson (1):
  drm/gma500/psb: Actually use VBT mode when it is found

Rex Zhu (1):
  drm/amdgpu: fix null point error when rmmod amdgpu.

 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  7 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 24 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  1 +
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  6 
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  | 15 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  | 16 ++-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 32 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  2 +-
 drivers/gpu/drm/drm_plane.c|  5 ++--
 drivers/gpu/drm/gma500/psb_intel_lvds.c| 18 +++-
 drivers/gpu/drm/qxl/qxl_display.c  |  4 +--
 drivers/gpu/drm/radeon/ci_dpm.c|  6 
 drivers/gpu/drm/radeon/cik.c   |  4 +--
 drivers/gpu/drm/radeon/evergreen.c |  4 +--
 drivers/gpu/drm/radeon/r600.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_kms.c|  2 +-
 drivers/gpu/drm/radeon/si.c|  4 +--
 19 files changed, 102 insertions(+), 80 deletions(-)

Re: [PATCH v5 06/10] drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback

[Archit Taneja]

On 05/25/2017 07:49 PM, Jose Abreu wrote:

Now that we have a callback to check if bridge supports a given mode
we can use it in Analogix bridge so that we restrict the number of
probbed modes to the ones we can actually display.

Also, there is no need to use mode_fixup() callback as mode_valid()
will handle the mode validation.



Reviewed-by: Archit Taneja 


NOTE: Only compile tested.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Daniel Vetter 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: David Airlie 
---
 drivers/gpu/drm/bridge/analogix-anx78xx.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index a2a8236..cf69a1c 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -1061,18 +1061,17 @@ static int anx78xx_bridge_attach(struct drm_bridge 
*bridge)
return 0;
 }

-static bool anx78xx_bridge_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+enum drm_mode_status anx78xx_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode 
*mode)
 {
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
-   return false;
+   return MODE_NO_INTERLACE;

/* Max 1200p at 5.4 Ghz, one lane */
if (mode->clock > 154000)
-   return false;
+   return MODE_CLOCK_HIGH;

-   return true;
+   return MODE_OK;
 }

 static void anx78xx_bridge_disable(struct drm_bridge *bridge)
@@ -1129,7 +1128,7 @@ static void anx78xx_bridge_enable(struct drm_bridge 
*bridge)

 static const struct drm_bridge_funcs anx78xx_bridge_funcs = {
.attach = anx78xx_bridge_attach,
-   .mode_fixup = anx78xx_bridge_mode_fixup,
+   .mode_valid = anx78xx_bridge_mode_valid,
.disable = anx78xx_bridge_disable,
.mode_set = anx78xx_bridge_mode_set,
.enable = anx78xx_bridge_enable,



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

Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

[Kevin Easton]

On Thu, May 25, 2017 at 05:40:16PM -0700, Andy Lutomirski wrote:
> On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
>  wrote:
> > On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> >  wrote:
> >> Here' my first attempt to bring boot-time between 4- and 5-level paging.
> >> It looks not too terrible to me. I've expected it to be worse.
> >
> > If I read this right, you just made it a global on/off thing.
> >
> > May I suggest possibly a different model entirely? Can you make it a
> > per-mm flag instead?
> >
> > And then we
> >
> >  (a) make all kthreads use the 4-level page tables
> >
> >  (b) which means that all the init code uses the 4-level page tables
> >
> >  (c) which means that all those checks for "start_secondary" etc can
> > just go away, because those all run with 4-level page tables.
> >
> > Or is it just much too expensive to switch between 4-level and 5-level
> > paging at run-time?
> >
> 
> Even ignoring expensiveness, I'm not convinced it's practical.  AFAICT
> you can't atomically switch the paging mode and CR3, so either you
> need some magic page table with trampoline that works in both modes
> (which is presumably doable with some trickery) or you need to flip
> paging off.  Good luck if an NMI hits in the mean time.  There was
> code like that once upon a time for EFI mixed mode, but it got deleted
> due to triple-faults.

According to Intel's documentation you pretty much have to disable
paging anyway:

"The processor allows software to modify CR4.LA57 only outside of IA-32e
mode. In IA-32e mode, an attempt to modify CR4.LA57 using the MOV CR
instruction causes a general-protection exception (#GP)."

(If it weren't for that, maybe you could point the last entry in the PML4
at the PML4 itself, so it also works as a PML5 for accessing kernel
addresses? And of course make sure nothing gets loaded above 
0xff80).

- Kevin

Re: [PATCH v5 02/10] drm: Introduce drm_bridge_mode_valid()

[Archit Taneja]

On 05/25/2017 07:49 PM, Jose Abreu wrote:

Introduce a new helper function which calls mode_valid() callback
for all bridges in an encoder chain.



Reviewed-by: Archit Taneja 


Signed-off-by: Jose Abreu 
Reviewed-by: Daniel Vetter 
Cc: Carlos Palminha 
Cc: Ville Syrjälä 
Cc: Dave Airlie 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/drm_bridge.c | 33 +
 include/drm/drm_bridge.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 86a7637..dc8cdfe 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -206,6 +206,39 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
 EXPORT_SYMBOL(drm_bridge_mode_fixup);

 /**
+ * drm_bridge_mode_valid - validate the mode against all bridges in the
+ *encoder chain.
+ * @bridge: bridge control structure
+ * @mode: desired mode to be validated
+ *
+ * Calls &drm_bridge_funcs.mode_valid for all the bridges in the encoder
+ * chain, starting from the first bridge to the last. If at least one bridge
+ * does not accept the mode the function returns the error code.
+ *
+ * Note: the bridge passed should be the one closest to the encoder.
+ *
+ * RETURNS:
+ * MODE_OK on success, drm_mode_status Enum error code on failure
+ */
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode)
+{
+   enum drm_mode_status ret = MODE_OK;
+
+   if (!bridge)
+   return ret;
+
+   if (bridge->funcs->mode_valid)
+   ret = bridge->funcs->mode_valid(bridge, mode);
+
+   if (ret != MODE_OK)
+   return ret;
+
+   return drm_bridge_mode_valid(bridge->next, mode);
+}
+EXPORT_SYMBOL(drm_bridge_mode_valid);
+
+/**
  * drm_bridge_disable - disables all bridges in the encoder chain
  * @bridge: bridge control structure
  *
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 00c6c36..8358eb3 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -233,6 +233,8 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+enum drm_mode_status drm_bridge_mode_valid(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode);
 void drm_bridge_disable(struct drm_bridge *bridge);
 void drm_bridge_post_disable(struct drm_bridge *bridge);
 void drm_bridge_mode_set(struct drm_bridge *bridge,



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

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Archit Taneja]

On 05/26/2017 09:46 AM, Archit Taneja wrote:

Hi,

On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:


Hi Mark
Cc: DRM maintainer


ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.


As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me


I'll pick it up for drm-misc-next.


Ah, I just saw the dependence on the previous patches.

Mark,

Please feel free to pull this to the asoc tree. You can add my Ack:

Acked-by: Archit Taneja 

Thanks,
Archit



Thanks,
Archit



Best regards
---
Kuninori Morimoto





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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Xunlei Pang]

On 04/19/2017 at 05:21 AM, Tom Lendacky wrote:
> Provide support so that kexec can be used to boot a kernel when SME is
> enabled.
>
> Support is needed to allocate pages for kexec without encryption.  This
> is needed in order to be able to reboot in the kernel in the same manner
> as originally booted.

Hi Tom,

Looks like kdump will break, I didn't see the similar handling for kdump cases, 
see kernel:
kimage_alloc_crash_control_pages(), kimage_load_crash_segment(), etc.

We need to support kdump with SME, kdump 
kernel/initramfs/purgatory/elfcorehdr/etc
are all loaded into the reserved memory(see crashkernel=X) by userspace 
kexec-tools.
I think a straightforward way would be to mark the whole reserved memory range 
without
encryption before loading all the kexec segments for kdump, I guess we can 
handle this
easily in arch_kexec_unprotect_crashkres().

Moreover, now that "elfcorehdr=X" is left as decrypted, it needs to be remapped 
to the
encrypted data.

Regards,
Xunlei

>
> Additionally, when shutting down all of the CPUs we need to be sure to
> flush the caches and then halt. This is needed when booting from a state
> where SME was not active into a state where SME is active (or vice-versa).
> Without these steps, it is possible for cache lines to exist for the same
> physical location but tagged both with and without the encryption bit. This
> can cause random memory corruption when caches are flushed depending on
> which cacheline is written last.
>
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/init.h  |1 +
>  arch/x86/include/asm/irqflags.h  |5 +
>  arch/x86/include/asm/kexec.h |8 
>  arch/x86/include/asm/pgtable_types.h |1 +
>  arch/x86/kernel/machine_kexec_64.c   |   35 
> +-
>  arch/x86/kernel/process.c|   26 +++--
>  arch/x86/mm/ident_map.c  |   11 +++
>  include/linux/kexec.h|   14 ++
>  kernel/kexec_core.c  |7 +++
>  9 files changed, 101 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
> index 737da62..b2ec511 100644
> --- a/arch/x86/include/asm/init.h
> +++ b/arch/x86/include/asm/init.h
> @@ -6,6 +6,7 @@ struct x86_mapping_info {
>   void *context;   /* context for alloc_pgt_page */
>   unsigned long pmd_flag;  /* page flag for PMD entry */
>   unsigned long offset;/* ident mapping offset */
> + unsigned long kernpg_flag;   /* kernel pagetable flag override */
>  };
>  
>  int kernel_ident_mapping_init(struct x86_mapping_info *info, pgd_t *pgd_page,
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index ac7692d..38b5920 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -58,6 +58,11 @@ static inline __cpuidle void native_halt(void)
>   asm volatile("hlt": : :"memory");
>  }
>  
> +static inline __cpuidle void native_wbinvd_halt(void)
> +{
> + asm volatile("wbinvd; hlt" : : : "memory");
> +}
> +
>  #endif
>  
>  #ifdef CONFIG_PARAVIRT
> diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
> index 70ef205..e8183ac 100644
> --- a/arch/x86/include/asm/kexec.h
> +++ b/arch/x86/include/asm/kexec.h
> @@ -207,6 +207,14 @@ struct kexec_entry64_regs {
>   uint64_t r15;
>   uint64_t rip;
>  };
> +
> +extern int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages,
> +gfp_t gfp);
> +#define arch_kexec_post_alloc_pages arch_kexec_post_alloc_pages
> +
> +extern void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages);
> +#define arch_kexec_pre_free_pages arch_kexec_pre_free_pages
> +
>  #endif
>  
>  typedef void crash_vmclear_fn(void);
> diff --git a/arch/x86/include/asm/pgtable_types.h 
> b/arch/x86/include/asm/pgtable_types.h
> index ce8cb1c..0f326f4 100644
> --- a/arch/x86/include/asm/pgtable_types.h
> +++ b/arch/x86/include/asm/pgtable_types.h
> @@ -213,6 +213,7 @@ enum page_cache_mode {
>  #define PAGE_KERNEL  __pgprot(__PAGE_KERNEL | _PAGE_ENC)
>  #define PAGE_KERNEL_RO   __pgprot(__PAGE_KERNEL_RO | _PAGE_ENC)
>  #define PAGE_KERNEL_EXEC __pgprot(__PAGE_KERNEL_EXEC | _PAGE_ENC)
> +#define PAGE_KERNEL_EXEC_NOENC   __pgprot(__PAGE_KERNEL_EXEC)
>  #define PAGE_KERNEL_RX   __pgprot(__PAGE_KERNEL_RX | _PAGE_ENC)
>  #define PAGE_KERNEL_NOCACHE  __pgprot(__PAGE_KERNEL_NOCACHE | _PAGE_ENC)
>  #define PAGE_KERNEL_LARGE__pgprot(__PAGE_KERNEL_LARGE | _PAGE_ENC)
> diff --git a/arch/x86/kernel/machine_kexec_64.c 
> b/arch/x86/kernel/machine_kexec_64.c
> index 085c3b3..11c0ca9 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -86,7 +86,7 @@ static int init_transition_pgtable(struct kimage *image, 
> pgd_t *pgd)
>   set_pmd(pmd, __pmd(__pa(

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

[Archit Taneja]

Hi,

On 05/25/2017 05:04 AM, Kuninori Morimoto wrote:


Hi Mark
Cc: DRM maintainer


ALSA SoC needs to know connected DAI ID for probing.
It is not a big problem if device/driver was only for sound,
but getting DAI ID will be difficult if device includes both
Video/Sound, like HDMI.


As far as I understand what's going on with the graph code this seems to
make sense to me.  How do we want to go about handling the patch?


This is comment to me ? or DRM maintainer ?

If to me, any case (pickup by Mark, or by DRM maintainer) is OK for me


I'll pick it up for drm-misc-next.

Thanks,
Archit



Best regards
---
Kuninori Morimoto



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

Re: [PATCH] mm/zsmalloc: fix -Wunneeded-internal-declaration warning

[Nick Desaulniers]

On Wed, May 24, 2017 at 05:16:18PM +0900, Sergey Senozhatsky wrote:
> On (05/23/17 22:38), Nick Desaulniers wrote:
> > Fixes the following warning, found with Clang:
> well, no objections from my side. MM seems to be getting more and
> more `__maybe_unused' annotations because of clang.

Indeed, but does find bugs when this warning pops up unexpected (unlike
in this particular instance). See:

https://patchwork.kernel.org/patch/9738897/
https://www.spinics.net/lists/intel-gfx/msg128737.html

TL;DR
>>> You have actually uncovered a bug here where the call is not
>>> supposed to be optional in the first place.

Re: [PATCH] KVM: x86: dynamically allocate large struct in em_fxrstor

[Nick Desaulniers]

On Thu, May 25, 2017 at 04:07:08PM +0200, Paolo Bonzini wrote:
> I think we should do the fixup backwards.
> 
> That is:
> 
> - first do get_fpu
> 
> - if the fixup is necessary, i.e. ctxt->mode < X86EMUL_MODE_PROT64, do
> fxsave into &fxstate.
> 
> - then do segmented_read_std with the correct size, which is
>   - offsetof(struct fxregs_state, xmm_space[16]), i.e. 416
> if ctxt->mode == X86EMUL_MODE_PROT64
>   - offsetof(struct fxregs_state, xmm_space[8]), i.e. 288
> if ctxt->mode < X86EMUL_MODE_PROT64 and CR4.OSFXSR=1
>   - offsetof(struct fxregs_state, xmm_space[0]), i.e. 160
> if ctxt->mode < X86EMUL_MODE_PROT64 and CR4.OSFXSR=0

but we still want to do a segmented_read_std with size 512 otherwise,
correct?

> - then check fx_state.mxcsr
> 
> - then do fxrstor

This sounds like we conditionally do the fxsave, but then always do the
fxrstor.  Is that ok? I guess the original code kind of does that as
well.

> - finally do put_fpu

Sounds straight forward.  I can see how fxsave and CR4.OSFXSR are
accessed in fxstor_fixup.  Is it ok to skip those memcpy's that would
otherwise occur when calling fxrstor_fixup() (which after these changes,
we would not be)?

Re: [PATCH net] sky2: Do not deadlock on sky2_hw_down

[David Miller]

From: Stephen Hemminger 
Date: Thu, 25 May 2017 15:05:02 -0700

> Ok, the issue is that lockdep is being stupid and thinking that
> seqcount's behave like locks.

Well.. they do.  That's why they have that annotation.

Re: [linux-sunxi] [PATCH 1/3] arm64: allwinner: a64: Add initial Orangepi Win/WinPlus support

[Chen-Yu Tsai]

On Fri, May 26, 2017 at 6:30 AM, André Przywara  wrote:
> On 25/05/17 20:26, Jagan Teki wrote:
>> From: Jagan Teki 
>>
>> Orangepi Win/WinPlus is an open-source single-board computer
>> using the Allwinner A64 SOC.
>>
>> A64 Orangepi Win/WinPlus has
>> - A64 Quad-core Cortex-A53 64bit
>> - 1GB(Win)/2GB(Win Plus) DDR3 SDRAM
>> - Debug TTL UART
>> - Four USB 2.0
>
> I take it those are connected to a hub chip, and the micro-USB socket is
> connected as a true OTG socket?
> So you should enable the usb_otg node, but without the host mode
> override we use for the Pine64.

Agreed. Unless OTG needs PMIC support.

>
>> - HDMI
>> - LCD
>> - Audio and MIC
>> - Wifi + BT
>
> It looks like Wifi + BT are soldered on the board, so you should at
> least enable the proper UART connected to the Bluetooth chip, probably
> also MMC1 (which is surely connected to the WiFi chip) should be
> described as an SDIO node.

Those probably need regulator support. Having them enabled together
might be better.

>
>> - IR receiver
>> - 5V DC power supply
>
> I guess the board uses the AXP803 as well? You might want to coordinate
> with Icenowy what to do to describe this as well, given that her patches
> might go in before.

Still waiting for NMI driver/bindings to be merged before I merge the dts
file changes. The mfd and regulator driver changes are already in -next.

>
> Cheers,
> Andre.
>
>> http://www.orangepi.org/OrangePiWin_WinPlus/

The URL is not going to be helpful if it goes offline.

Can someone provide schematics for this board? Without it there's really
no verification for what the device tree describes.

>>
>> Signed-off-by: Jagan Teki 
>> ---
>>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>>  .../boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 102 
>> +
>>  2 files changed, 103 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
>> b/arch/arm64/boot/dts/allwinner/Makefile
>> index 244e8b7..4120ce9 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -1,5 +1,6 @@
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>>
>>  always   := $(dtb-y)
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts 
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>> new file mode 100644
>> index 000..b16e606
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
>> @@ -0,0 +1,102 @@
>> +/*
>> + * Copyright (C) 2017 Jagan Teki 
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64.dtsi"
>> +
>> +#include 
>> +
>> +/ {

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Reza Arbab  writes:

> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
>>The commit message for 3af229f2071f says:
>>
>>In practice, we never see a system with 256 NUMA nodes, and in fact, we
>>do not support node hotplug on power in the first place, so the nodes
>>^^^
>>that are online when we come up are the nodes that will be present for
>>the lifetime of this kernel.
>>
>>Is that no longer true?
>
> I don't know what the reasoning behind that statement was at the time, 
> but as far as I can tell, the only thing missing for node hotplug now is 
> Balbir's patchset [1]. He fixes the resource issue which motivated 
> 3af229f2071f and reverts it.
>
> With that set, I can instantiate a new numa node just by doing 
> add_memory(nid, ...) where nid doesn't currently exist.

But does that actually happen on any real system?

cheers

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Balbir Singh]

On Thu, 25 May 2017 10:10:11 -0500
Reza Arbab  wrote:

> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote:
> >The commit message for 3af229f2071f says:
> >
> >In practice, we never see a system with 256 NUMA nodes, and in fact, we
> >do not support node hotplug on power in the first place, so the nodes
> >^^^
> >that are online when we come up are the nodes that will be present for
> >the lifetime of this kernel.
> >
> >Is that no longer true?  
> 
> I don't know what the reasoning behind that statement was at the time, 
> but as far as I can tell, the only thing missing for node hotplug now is 
> Balbir's patchset [1]. He fixes the resource issue which motivated 
> 3af229f2071f and reverts it.
> 
> With that set, I can instantiate a new numa node just by doing 
> add_memory(nid, ...) where nid doesn't currently exist.
> 
> [1] 
> https://lkml.kernel.org/r/1479253501-26261-1-git-send-email-bsinghar...@gmail.com
> 

I guess I should try and revive that patchset. One of the suggestions of
then was to limit maximum possible nodes in firmware, but I'm double checking
to see if we can do that in a well defined manner.

Balbir Singh

Re: [PATCH v4 6/6] Documentation/dev-tools: Add kselftest_harness documentation

[Kees Cook]

On Thu, May 25, 2017 at 5:20 PM, Mickaël Salaün  wrote:
> Add metadata to kselftest_harness.h to be able to include the comments
> in the Sphinx documentation.
>
> Changes since v3:
> * document macros as actual functions (suggested by Jonathan Corbet)
> * remove the TEST_API() wrapper to expose the underlying macro arguments
>   to the documentation tools
> * move and cleanup comments

To aid review, can you actually split this into 2 patches with the
renaming after the removal of TEST_API() in the first and the addition
of the ReST docs in the second? Regardless, it looks good. Thanks!

-Kees

>
> Changes since v2:
> * add reference to the full documentation in the header file (suggested
>   by Kees Cook)
>
> Signed-off-by: Mickaël Salaün 
> Acked-by: Kees Cook 
> Cc: Andy Lutomirski 
> Cc: Jonathan Corbet 
> Cc: Shuah Khan 
> Cc: Will Drewry 
> ---
>  Documentation/dev-tools/kselftest.rst   |  34 ++
>  tools/testing/selftests/kselftest_harness.h | 678 
> ++--
>  2 files changed, 468 insertions(+), 244 deletions(-)
>
> diff --git a/Documentation/dev-tools/kselftest.rst 
> b/Documentation/dev-tools/kselftest.rst
> index 9232ce94612c..a92fa181b6cf 100644
> --- a/Documentation/dev-tools/kselftest.rst
> +++ b/Documentation/dev-tools/kselftest.rst
> @@ -120,3 +120,37 @@ Contributing new tests (details)
> executable which is not tested by default.
> TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
> test.
> +
> +Test Harness
> +
> +
> +The kselftest_harness.h file contains useful helpers to build tests.  The 
> tests
> +from tools/testing/selftests/seccomp/seccomp_bpf.c can be used as example.
> +
> +Example
> +---
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:doc: example
> +
> +
> +Helpers
> +---
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:functions: TH_LOG TEST TEST_SIGNAL FIXTURE FIXTURE_DATA FIXTURE_SETUP
> +FIXTURE_TEARDOWN TEST_F TEST_HARNESS_MAIN
> +
> +Operators
> +-
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:doc: operators
> +
> +.. kernel-doc:: tools/testing/selftests/kselftest_harness.h
> +:functions: ASSERT_EQ ASSERT_NE ASSERT_LT ASSERT_LE ASSERT_GT ASSERT_GE
> +ASSERT_NULL ASSERT_TRUE ASSERT_NULL ASSERT_TRUE ASSERT_FALSE
> +ASSERT_STREQ ASSERT_STRNE EXPECT_EQ EXPECT_NE EXPECT_LT
> +EXPECT_LE EXPECT_GT EXPECT_GE EXPECT_NULL EXPECT_TRUE
> +EXPECT_FALSE EXPECT_STREQ EXPECT_STRNE
> +
> diff --git a/tools/testing/selftests/kselftest_harness.h 
> b/tools/testing/selftests/kselftest_harness.h
> index 171e70aead9c..8f623a4e1889 100644
> --- a/tools/testing/selftests/kselftest_harness.h
> +++ b/tools/testing/selftests/kselftest_harness.h
> @@ -4,41 +4,49 @@
>   *
>   * kselftest_harness.h: simple C unit test helper.
>   *
> - * Usage:
> - *   #include "../kselftest_harness.h"
> - *   TEST(standalone_test) {
> - * do_some_stuff;
> - * EXPECT_GT(10, stuff) {
> - *stuff_state_t state;
> - *enumerate_stuff_state(&state);
> - *TH_LOG("expectation failed with state: %s", state.msg);
> - * }
> - * more_stuff;
> - * ASSERT_NE(some_stuff, NULL) TH_LOG("how did it happen?!");
> - * last_stuff;
> - * EXPECT_EQ(0, last_stuff);
> - *   }
> - *
> - *   FIXTURE(my_fixture) {
> - * mytype_t *data;
> - * int awesomeness_level;
> - *   };
> - *   FIXTURE_SETUP(my_fixture) {
> - * self->data = mytype_new();
> - * ASSERT_NE(NULL, self->data);
> - *   }
> - *   FIXTURE_TEARDOWN(my_fixture) {
> - * mytype_free(self->data);
> - *   }
> - *   TEST_F(my_fixture, data_is_good) {
> - * EXPECT_EQ(1, is_my_data_good(self->data));
> - *   }
> - *
> - *   TEST_HARNESS_MAIN
> + * See documentation in Documentation/dev-tools/kselftest.rst
>   *
>   * API inspired by code.google.com/p/googletest
>   */
>
> +/**
> + * DOC: example
> + *
> + * .. code-block:: c
> + *
> + *#include "../kselftest_harness.h"
> + *
> + *TEST(standalone_test) {
> + *  do_some_stuff;
> + *  EXPECT_GT(10, stuff) {
> + * stuff_state_t state;
> + * enumerate_stuff_state(&state);
> + * TH_LOG("expectation failed with state: %s", state.msg);
> + *  }
> + *  more_stuff;
> + *  ASSERT_NE(some_stuff, NULL) TH_LOG("how did it happen?!");
> + *  last_stuff;
> + *  EXPECT_EQ(0, last_stuff);
> + *}
> + *
> + *FIXTURE(my_fixture) {
> + *  mytype_t *data;
> + *  int awesomeness_level;
> + *};
> + *FIXTURE_SETUP(my_fixture) {
> + *  self->data = mytype_new();
> + *  ASSERT_NE(NULL, self->data);
> + *}
> + *FIXTURE_TEARDOWN(my_fixture) {
> + *  mytype_free(self->data);
> + *}
> + *TEST_F(my_fixture, data_is_good) {
> + *  EXPECT_EQ(1, is_my_data_good(self->data));
> + *}
> + *
> + *TEST_HARNESS_MAIN
> + */
> +
>  #ifndef __KSELF

Re: [PATCH v3] add the option of fortified string.h functions

[Kees Cook]

On Mon, May 22, 2017 at 4:10 PM, Daniel Micay  wrote:
> diff --git a/arch/x86/include/asm/string_64.h 
> b/arch/x86/include/asm/string_64.h
> index 733bae07fb29..3c5b26e07b85 100644
> --- a/arch/x86/include/asm/string_64.h
> +++ b/arch/x86/include/asm/string_64.h
> @@ -77,6 +77,11 @@ int strcmp(const char *cs, const char *ct);
>  #define memcpy(dst, src, len) __memcpy(dst, src, len)
>  #define memmove(dst, src, len) __memmove(dst, src, len)
>  #define memset(s, c, n) __memset(s, c, n)
> +
> +#ifndef __NO_FORTIFY
> +#define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
> +#endif
> +
>  #endif
>
>  #define __HAVE_ARCH_MEMCPY_MCSAFE 1

Ah-ha, this same KASAN exclusion is missing for string_32.h, which is
what I think akpm tripped over in build tests.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 2/4] pinctrl: rockchip: Add iomux-route switching support for rk3228

[David.Wu]

Hi Heiko,

在 2017/5/26 5:12, Heiko Stuebner 写道:

Requiring developers to calculate this pin-bit-value for each bank
is cumbersome and error-prone. With the routes-struct known in
the driver (see above and below), you can keep the the value element
in rockchip_pin_bank, but calculate the per-bank value dynamically
when the bank gets created.

For example in rockchip_pinctrl_get_soc_data just parse the route-struct
and calculate that value when the driver probes.

This reduces possible errors and also spares us the clutter of all the
additional PIN_BANK_* defines.


It is good to calculate the per-bank value dynamically, Thanks.☺

Re: [PATCH 02/20] ipc: merge ipc_rcu and kern_ipc_perm

[Kees Cook]

On Thu, May 25, 2017 at 12:34 PM, Kees Cook  wrote:
> On Thu, May 25, 2017 at 11:50 AM, Manfred Spraul
>  wrote:
>> ipc has two management structures that exist for every id:
>> - struct kern_ipc_perm, it contains e.g. the permissions.
>> - struct ipc_rcu, it contains the rcu head for rcu handling and
>>   the refcount.
>>
>> The patch merges both structures.
>> As a bonus, we may save one cacheline, because both structures are
>> cacheline aligned.
>> In addition, it reduces the number of casts, instead most codepaths can
>> use container_of.
>>
>> To simplify code, the ipc_rcu_alloc initializes the allocation to 0.
>
> I don't see this change in the code, only the removal of sem's
> memset(..., 0, ...)?
>
>> diff --git a/ipc/sem.c b/ipc/sem.c
>> index fff8337..bdff6d9 100644
>> --- a/ipc/sem.c
>> +++ b/ipc/sem.c
>> @@ -469,20 +469,20 @@ static int newary(struct ipc_namespace *ns, struct 
>> ipc_params *params)
>> if (ns->used_sems + nsems > ns->sc_semmns)
>> return -ENOSPC;
>>
>> +   BUILD_BUG_ON(offsetof(struct sem_array, sem_perm) != 0);
>> +
>> size = sizeof(*sma) + nsems * sizeof(sma->sems[0]);
>> -   sma = ipc_rcu_alloc(size);
>> +   sma = container_of(ipc_rcu_alloc(size), struct sem_array, sem_perm);
>> if (!sma)
>> return -ENOMEM;
>>
>> -   memset(sma, 0, size);
>> -
>> sma->sem_perm.mode = (semflg & S_IRWXUGO);
>> sma->sem_perm.key = key;
>>
>> sma->sem_perm.security = NULL;
>> retval = security_sem_alloc(sma);
>> if (retval) {
>> -   ipc_rcu_putref(sma, ipc_rcu_free);
>> +   ipc_rcu_putref(&sma->sem_perm, ipc_rcu_free);
>> return retval;
>> }
>>
>> [...]
>> diff --git a/ipc/util.c b/ipc/util.c
>> index caec7b1..9dcc08b 100644
>> --- a/ipc/util.c
>> +++ b/ipc/util.c
>> @@ -418,46 +418,43 @@ void ipc_free(void *ptr)
>>  }
>>
>>  /**
>> - * ipc_rcu_alloc - allocate ipc and rcu space
>> + * ipc_rcu_alloc - allocate ipc space
>>   * @size: size desired
>>   *
>> - * Allocate memory for the rcu header structure +  the object.
>> - * Returns the pointer to the object or NULL upon failure.
>> + * Allocate memory for an ipc object.
>> + * The first member must be struct kern_ipc_perm.
>>   */
>> -void *ipc_rcu_alloc(int size)
>> +struct kern_ipc_perm *ipc_rcu_alloc(int size)
>>  {
>> /*
>>  * We prepend the allocation with the rcu struct
>>  */
>> -   struct ipc_rcu *out = ipc_alloc(sizeof(struct ipc_rcu) + size);
>> +   struct kern_ipc_perm *out = ipc_alloc(size);
>> if (unlikely(!out))
>> return NULL;
>> atomic_set(&out->refcount, 1);
>> -   return out + 1;
>> +   return out;
>>  }

See above:

- newary() loses memset()
- ipc_rcu_alloc() does not gain it
- changelog says "To simplify code, the ipc_rcu_alloc initializes the
allocation to 0." This is what's wanted but the patch doesn't do it.

The actual change that (temporarily) adds memset to ipc_rcu_alloc() is
one of the following patches, but it should be here or bisection may
cause unexpected results for semaphores.

It's a minor issue, since these will likely all land at the same time,
but it's probably still worth fixing.

-Kees

-- 
Kees Cook
Pixel Security

[PATCH 0/2] reset: Basic reset controller

[Joel Stanley]

Hello,

In the Aspeed SoCs we have some reset registers spread out in various parts of
the soc: in the system controller IP, as well as other peripherals. I need to be
able to deassert those resets before other drivers work.

In writing a driver to do this I realised it was very generic. So instead I've
sent a generic driver that can be used by the device tree to clear reset lines
described by single bits in a register.

Let me know what you think of the idea. I've tested this driver on our SoC to
release the UART reset.

Joel Stanley (2):
  dt-bindings: reset: Add bindings for basic reset controller
  reset: Add basic single-register reset driver

 .../devicetree/bindings/reset/reset-basic.txt  |  31 ++
 drivers/reset/Kconfig  |   6 ++
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-basic.c| 109 +
 4 files changed, 147 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/reset-basic.txt
 create mode 100644 drivers/reset/reset-basic.c

-- 
2.11.0

[PATCH 2/2] reset: Add basic single-register reset driver

[Joel Stanley]

This driver is a basic single-register reset controller driver that
supports clearing a single bit in a register.

Signed-off-by: Joel Stanley 
---
 drivers/reset/Kconfig   |   6 +++
 drivers/reset/Makefile  |   1 +
 drivers/reset/reset-basic.c | 109 
 3 files changed, 116 insertions(+)
 create mode 100644 drivers/reset/reset-basic.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index d21c07ccc94e..980cda887dfe 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -28,6 +28,12 @@ config RESET_ATH79
  This enables the ATH79 reset controller driver that supports the
  AR71xx SoC reset controller.
 
+config RESET_BASIC
+   bool "Basic Reset Driver"
+   help
+ This enables a basic single-register reset controller driver that
+ supports clearing a single bit in a register.
+
 config RESET_BERLIN
bool "Berlin Reset Driver" if COMPILE_TEST
default ARCH_BERLIN
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 02a74db94339..e8e8869e098d 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_TEGRA) += tegra/
 obj-$(CONFIG_RESET_A10SR) += reset-a10sr.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_BASIC) += reset-basic.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_IMX7) += reset-imx7.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
diff --git a/drivers/reset/reset-basic.c b/drivers/reset/reset-basic.c
new file mode 100644
index ..62a676de9f62
--- /dev/null
+++ b/drivers/reset/reset-basic.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright 2017 IBM Corperation
+ *
+ * Joel Stanley 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define to_basic_reset_priv(p) \
+   container_of((p), struct basic_reset_priv, rcdev)
+
+struct basic_reset_priv {
+   struct regmap *regmap;
+   struct reset_controller_dev rcdev;
+   u32 reg;
+};
+
+static int basic_reset_assert(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+
+   regmap_update_bits(priv->regmap, priv->reg, mask, mask);
+
+   return 0;
+}
+
+static int basic_reset_deassert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+
+   regmap_update_bits(priv->regmap, priv->reg, mask, 0);
+
+   return 0;
+}
+
+static int basic_reset_status(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct basic_reset_priv *priv = to_basic_reset_priv(rcdev);
+   u32 mask = BIT(id);
+   u32 val;
+
+   regmap_read(priv->regmap, priv->reg, &val);
+
+   return !!(val & mask);
+}
+
+static const struct reset_control_ops basic_reset_ops = {
+   .assert = basic_reset_assert,
+   .deassert = basic_reset_deassert,
+   .status = basic_reset_status,
+};
+
+static int basic_reset_probe(struct platform_device *pdev)
+{
+   struct device_node *parent_np = of_get_parent(pdev->dev.of_node);
+   struct basic_reset_priv *priv;
+   int ret;
+
+   priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   priv->regmap = syscon_node_to_regmap(parent_np);
+   of_node_put(parent_np);
+   if (IS_ERR(priv->regmap))
+   return PTR_ERR(priv->regmap);
+
+   ret = of_property_read_u32(pdev->dev.of_node, "reg", &priv->reg);
+   if (ret)
+   return ret;
+
+   priv->rcdev.owner = THIS_MODULE;
+   priv->rcdev.ops = &basic_reset_ops;
+   priv->rcdev.of_node = pdev->dev.of_node;
+   priv->rcdev.nr_resets = 32;
+
+   return reset_controller_register(&priv->rcdev);
+}
+
+static const struct of_device_id basic_reset_dt_match[] = {
+   { .compatible = "reset-basic" },
+   { },
+};
+
+static struct platform_driver basic_reset_driver = {
+   .probe  = basic_reset_probe,
+   .driver = {
+   .name = "basic-reset",
+   .of_match_table = basic_reset_dt_match,
+   },
+};
+builtin_platform_driver(basic_reset_driver);
-- 
2.11.0

[PATCH 1/2] dt-bindings: reset: Add bindings for basic reset controller

[Joel Stanley]

This adds the bindings documentation for a basic single-register reset
controller.

The bindings describe a single 32-bit register that contains up to 32
reset lines, each deasserted by clearing the appropriate bit in the
register.

Signed-off-by: Joel Stanley 
---
 .../devicetree/bindings/reset/reset-basic.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/reset-basic.txt

diff --git a/Documentation/devicetree/bindings/reset/reset-basic.txt 
b/Documentation/devicetree/bindings/reset/reset-basic.txt
new file mode 100644
index ..7341e04e7904
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset-basic.txt
@@ -0,0 +1,31 @@
+Basic single-register reset controller
+==
+
+This describes a generic reset controller where the reset lines are controlled
+by single bits within a 32-bit memory location. The memory location is assumed
+to be part of a syscon regmap.
+
+Reset controller required properties:
+ - compatible: should be "reset-basic"
+ - #reset-cells: must be set to 1
+ - reg: reset register location within regmap
+
+Device node required properties:
+ - resets phandle
+ - bit number, counting from zero, for the desired reset line. Max is 31.
+
+Example:
+
+syscon {
+   compatible = "syscon";
+
+   uart_rest: rest@0c {
+   compatible = "reset-basic";
+   #reset-cells = <1>;
+   reg = <0x0c>;
+   };
+}
+
+&uart {
+   resets = <&uart_rest 0x04>;
+}
-- 
2.11.0

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

[Christoph Lameter]

On Thu, 25 May 2017, Marcelo Tosatti wrote:

> Argument? We're showing you the data that this is causing a latency
> problem for us.

Sorry I am not sure where the data shows a latency problem. There are
interrupts and scheduler ticks. But what does this have to do with vmstat?

Show me your dpdk code running and trace the tick on / off events  as well
as the vmstat invocations. Also show all system calls occurring on the cpu
that runs dpdk. That is necessary to see what triggers vmstat and how the
system reacts to the changes to the differentials.

Then please rerun the test by setting the vmstat_interval to 60.

Do another run with your modifications and show the difference.

> > Something that crossed my mind was to add a new tunable to set
> > the vmstat_interval for each CPU, this way we could essentially
> > disable it to the CPUs where DPDK is running. What's the implications
> > of doing this besides not getting up to date stats in /proc/vmstat
> > (which I still have to confirm would be OK)? Can this break anything
> > in the kernel for example?
>
> Well, you get incorrect statistics.

The statistics are never completely accurate. You will get less accurate
statistics but they will be correct. The differentials may not be
reflected in the counts shown via /proc but there is a cap on how
inaccurate those can becore.

Re: [PATCH V2 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Balbir Singh]

On Thu, 25 May 2017 12:37:40 -0500
Michael Bringmann  wrote:

> Removing or adding memory via the PowerPC hotplug interface shows
> anomalies in the association between memory and nodes.  The code
> was updated to ensure that all nodes found at boot are still available
> to subsequent DLPAR hotplug-memory operations, even if they are not
> needed at boot time.
> 
> Signed-off-by: Michael Bringmann 
> ---
> Changes in V2:
>   -- Simplify patches to ensure more nodes in possible map, removing
>  code from PowerPC numa.c that constrained possible map to size
>  of online map.
> ---
>  arch/powerpc/mm/numa.c |7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 15c2dd5..18f3038 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -907,13 +907,6 @@ void __init initmem_init(void)
>  
>   memblock_dump_all();
>  
> - /*
> -  * Reduce the possible NUMA nodes to the online NUMA nodes,
> -  * since we do not support node hotplug. This ensures that  we
> -  * lower the maximum NUMA node ID to what is actually present.
> -  */
> - nodes_and(node_possible_map, node_possible_map, node_online_map);
> -

There is an overhead with turning this off if you have too many cgroups
with the memory controller. I think this fix was added for a pathological
test case. On my system I see 84 cgroups with 1 node, so the probable
overhead is 84*255*sizeof(struct mem_cgroup_tree_per_node).

I tried some patches to reduce the overhead, but those need more overhauling
and rework.

Balbir Singh.

Re: [PATCH] reset: hisilicon: Fix hi6220 module license

[Chen Feng]

looks good to me.

On 2017/5/25 17:22, Andreas Färber wrote:
> The hi6220_reset driver fails to load:
>
>   [   10.423640] hi6220_reset: module license 'unspecified' taints kernel.
>   [   10.423644] Disabling lock debugging due to kernel taint
>   [   10.423735] hi6220_reset: Unknown symbol regmap_write (err 0)
>   [   10.423747] hi6220_reset: Unknown symbol devm_kmalloc (err 0)
>   [   10.423759] hi6220_reset: Unknown symbol syscon_node_to_regmap (err 0)
>   [   10.423768] hi6220_reset: Unknown symbol reset_controller_register (err 
> 0)
>   [   10.423784] hi6220_reset: Unknown symbol __platform_driver_register (err 
> 0)
>
> Add a MODULE_LICENSE() to fix this.
>
> Fixes: 70b3590f639f ("reset: hi6220: fix modular build")
> Cc: Arnd Bergmann 
> Cc: Chen Feng 
> Signed-off-by: Andreas Färber 
> ---
>  drivers/reset/hisilicon/hi6220_reset.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/reset/hisilicon/hi6220_reset.c 
> b/drivers/reset/hisilicon/hi6220_reset.c
> index 35ce53edabf9..d5e5229308f2 100644
> --- a/drivers/reset/hisilicon/hi6220_reset.c
> +++ b/drivers/reset/hisilicon/hi6220_reset.c
> @@ -155,3 +155,5 @@ static int __init hi6220_reset_init(void)
>  }
>  
>  postcore_initcall(hi6220_reset_init);
> +
> +MODULE_LICENSE("GPL v2");

Re: [PATCH v9 6/7] LPC: Add the ACPI LPC support

[kbuild test robot]

Hi zhichang.yuan,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2 next-20170525]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gabriele-Paoloni/LPC-legacy-ISA-I-O-support/20170526-033719
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `lpc_host_io_setup':
>> hisi_lpc.c:(.text+0x252): undefined reference to 
>> `acpi_set_logic_pio_resource'
   drivers/built-in.o: In function `acpi_scan_init':
   (.init.text+0x6742): undefined reference to `acpi_indirectio_scan_init'

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


.config.gz
Description: application/gzip

linux-next: Tree for May 26

[Stephen Rothwell]

Hi all,

Changes since 20170525:

New tree: realtek

Non-merge commits (relative to Linus' tree): 2775
 3084 files changed, 111008 insertions(+), 61381 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 and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) 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.

Below is a summary of the state of the merge.

I am currently merging 261 trees (counting Linus' and 40 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 (be941bf2e6a3 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (05d8cba4a1e8 kbuild: skip install/check of 
headers right under uapi directories)
Merging arc-current/for-curr (2ea659a9ef48 Linux 4.12-rc1)
Merging arm-current/fixes (2ea659a9ef48 Linux 4.12-rc1)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (a4700a261072 powerpc: Add PPC_FEATURE userspace 
bits for SCV and DARN instructions)
Merging sparc/master (be941bf2e6a3 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (797a93647a48 bonding: Don't update slave->link until ready 
to commit)
Merging ipsec/master (a486cd23661c xfrm: fix state migration copy replay 
sequence numbers)
Merging netfilter/master (fefa92679dbe netfilter: ctnetlink: fix incorrect 
nf_ct_put during hash resize)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (6d18c732b95c bridge: start hello_timer when 
enabling KERNEL_STP in br_stp_start)
Merging mac80211/master (1b57b6210f4e cfg80211: make 
cfg80211_sched_scan_results() work from atomic context)
Merging sound-current/for-linus (1fc2e41f7af4 ALSA: hda - apply 
STAC_9200_DELL_M22 quirk for Dell Latitude D430)
Merging pci-current/for-linus (4d071c323898 PCI/PM: Add needs_resume flag to 
avoid suspend complete optimization)
Merging driver-core.current/driver-core-linus (08332893e37a Linux 4.12-rc2)
Merging tty.current/tty-linus (59fe2cc8b1c3 serial: altera_uart: call iounmap() 
at driver remove)
Merging usb.current/usb-linus (8b77b0cfa99e Merge tag 'usb-ci-v4.12-rc2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus)
Merging usb-gadget-fixes/fixes (a351e9b9fc24 Linux 4.11)
Merging usb-serial-fixes/usb-linus (08332893e37a Linux 4.12-rc2)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (a380b78b799b phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (3d51b9562673 staging: ccree: add CRYPTO 
dependency)
Merging char-misc.current/char-misc-linus (cdc1daca1b9b MAINTAINERS: Change 
maintainer of genwqe driver)
Merging input-current/for-linus (a04f144059ac Input: elan_i2c - ignore signals 
when finishing updating firmware)
Merging crypto-current/master (f3ad587070d6 crypto: gcm - wait for crypto op 
not signal safe)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (2ea659a9

[PATCH 3/4] test: firmwware: add signature test to driver_data loader test

[AKASHI Takahiro]

Add the following tests:
No.15 - verify loaded data witha signature
No.16 - verify loaded data witha signature under signature enforcing

For each test, there are several test cases:
* no signature provided
* valid signature provided
* invalid signature provided

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 lib/test_driver_data.c  |  56 -
 tools/testing/selftests/firmware/driver_data.sh | 265 +++-
 2 files changed, 315 insertions(+), 6 deletions(-)

diff --git a/lib/test_driver_data.c b/lib/test_driver_data.c
index 422ea6289396..660cf9ff9ac0 100644
--- a/lib/test_driver_data.c
+++ b/lib/test_driver_data.c
@@ -85,6 +85,9 @@ int num_test_devs;
  * @api_min: API min version to use for the test.
  * @api_max: API max version to use for the test.
  * @api_name_postfix: API name postfix
+ * @no_sig_check: whether or not we wish to verify the driver_data with its
+ *  signature. If CONFIG_FIRMWARE_SIG_ENFORCE, passing the verification
+ *  is mandatory.
  * @test_result: a test may use this to collect the result from the call
  * of the driver_data_request_async() or driver_data_request_sync() calls
  * used in their tests. Note that for async calls this typically will be a
@@ -125,6 +128,7 @@ struct test_config {
u8 api_min;
u8 api_max;
char *api_name_postfix;
+   bool no_sig_check;
 
int test_result;
 };
@@ -345,6 +349,9 @@ static ssize_t config_show(struct device *dev,
len += snprintf(buf+len, PAGE_SIZE,
"keep:\t\t%s\n",
config->keep ? "true" : "false");
+   len += snprintf(buf+len, PAGE_SIZE,
+   "no_sig_check:\t%s\n",
+   config->no_sig_check ? "true" : "false");
 
mutex_unlock(&test_dev->config_mutex);
 
@@ -443,6 +450,9 @@ static int config_sync_req_cb(void *context,
 {
struct driver_data_test_device *test_dev = context;
 
+   if (unused_error)
+   return unused_error;
+
return config_load_data(test_dev, driver_data);
 }
 
@@ -455,14 +465,19 @@ static int trigger_config_sync(struct 
driver_data_test_device *test_dev)
  (config->optional ?
   DRIVER_DATA_REQ_OPTIONAL : 0) |
  (config->keep ?
-  DRIVER_DATA_REQ_KEEP : 0)),
+  DRIVER_DATA_REQ_KEEP : 0) |
+ (config->no_sig_check ?
+  DRIVER_DATA_REQ_NO_SIG_CHECK :
+  0)),
};
const struct driver_data_req_params req_params_opt_cb = {
DRIVER_DATA_DEFAULT_SYNC(config_sync_req_cb, test_dev),
DRIVER_DATA_SYNC_OPT_CB(config_sync_req_default_cb,
 test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params *req_params;
 
@@ -528,20 +543,26 @@ static int trigger_config_async(struct 
driver_data_test_device *test_dev)
const struct driver_data_req_params req_params_default = {
DRIVER_DATA_DEFAULT_ASYNC(config_async_req_cb, test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params req_params_opt_cb = {
DRIVER_DATA_DEFAULT_ASYNC(config_async_req_cb, test_dev),
DRIVER_DATA_ASYNC_OPT_CB(config_async_req_default_cb, test_dev),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
-   (config->keep ? DRIVER_DATA_REQ_KEEP : 0),
+   (config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
+   (config->no_sig_check ? DRIVER_DATA_REQ_NO_SIG_CHECK :
+   0),
};
const struct driver_data_req_params req_params_api = {
DRIVER_DATA_API_CB(config_async_req_api_cb, test_dev),
DRIVER_DATA_API(config->api_min, config->api_max, 
config->api_name_postfix),
.reqs = (config->optional ? DRIVER_DATA_REQ_OPTIONAL : 0) |
(config->keep ? DRIVER_DATA_REQ_KEEP : 0) |
- 

[PATCH 4/4] firmware: document signature verification for driver data

[AKASHI Takahiro]

add descriptions and usage about firmware signing in driver data APIs.

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 Documentation/driver-api/firmware/driver_data.rst  |  6 ++
 .../driver-api/firmware/fallback-mechanisms.rst|  5 +-
 Documentation/driver-api/firmware/signing.rst  | 81 ++
 3 files changed, 90 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/signing.rst

diff --git a/Documentation/driver-api/firmware/driver_data.rst 
b/Documentation/driver-api/firmware/driver_data.rst
index be7c7ff99151..cdc47144a8b2 100644
--- a/Documentation/driver-api/firmware/driver_data.rst
+++ b/Documentation/driver-api/firmware/driver_data.rst
@@ -94,6 +94,12 @@ in these callbacks it frees it for you by default after 
callback handlers
 are issued. If you wish to keep the driver data around after your callbacks
 you must specify this through the driver data request parameter data structure.
 
+Signature verification
+==
+
+  * `data signing`_
+.. _`data signing`: ./signing.rst
+
 Driver data private internal functionality
 ==
 
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index d19354794e67..e557d6630330 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -81,11 +81,12 @@ and a file upload firmware into:
 
   * /sys/$DEVPATH/loading
   * /sys/$DEVPATH/data
+  * /sys/$DEVPATH/sig_data
 
 To upload firmware you will echo 1 onto the loading file to indicate
 you are loading firmware. You then cat the firmware into the data file,
-and you notify the kernel the firmware is ready by echo'ing 0 onto
-the loading file.
+optionally its signature file, and you notify the kernel the firmware is
+ready by echo'ing 0 onto the loading file.
 
 The firmware device used to help load firmware using sysfs is only created if
 direct firmware loading fails and if the fallback mechanism is enabled for your
diff --git a/Documentation/driver-api/firmware/signing.rst 
b/Documentation/driver-api/firmware/signing.rst
new file mode 100644
index ..2dbee104700e
--- /dev/null
+++ b/Documentation/driver-api/firmware/signing.rst
@@ -0,0 +1,81 @@
+
+Kernel firmware signing facility
+
+
+Overview
+
+
+The kernel firmware signing facility enables to cryptographically sign
+firmware files on a system using the same keys used for module signing.
+Firmware files's signatures consist of PKCS#7 messages of the respective
+firmware file. A firmware file named foo.bin, would have its respective
+signature on the filesystem as foo.bin.p7s. When firmware signature
+checking is enabled (FIRMWARE_SIG) and when one of the above APIs is used
+against foo.bin, the file foo.bin.p7s will also be looked for. If
+FIRMWARE_SIG_FORCE is enabled the foo.bin file will only be allowed to
+be returned to callers of the above APIs if and only if the foo.bin.p7s
+file is confirmed to be a valid signature of the foo.bin file. If
+FIRMWARE_SIG_FORCE is not enabled and only FIRMWARE_SIG is enabled the
+kernel will be permissive and enabled unsigned firmware files, or firmware
+files with incorrect signatures. If FIRMWARE_SIG is not enabled the
+signature file is ignored completely.
+
+Firmware signing increases security by making it harder to load a malicious
+firmware into the kernel.  The firmware signature checking is done by the
+kernel so that it is not necessary to have trusted userspace bits.
+
+Configuring firmware signing
+
+
+The firmware signing facility is enabled by going to the section::
+
+  -> Device Drivers
+-> Generic Driver Options
+  -> Userspace firmware loading support (FW_LOADER [=y])
+-> Firmware signature verification (FIRMWARE_SIG [=y])
+
+If you want to not allow unsigned firmware to be loaded you should
+enable::
+
+-> Require all firmware to be validly signed (FIRMWARE_SIG_FORCE [=y])
+
+under the same menu.
+
+Using signing keys
+==
+
+The same key types used for module signing can be used for firmware
+signing. For details on that refer to `Kernel module signing`_.
+
+.. _`Kernel module signing`: /admin-guide/module-signing.rst
+
+You will need:
+
+  A) A DER-encoded X.509 certificate containing the public key.
+  B) A DER-encoded PKCS#7 message containing the signatures, these are
+ the .p7s files.
+  C) A binary blob that is the detached data for the PKCS#7 message, this
+ is the firmware files
+
+A) is must be made available to the kernel. One way to do this is to provide a
+DER-encoded in the source directory as .x509 when you build the kernel.
+
+Signing firmware files
+==
+
+To generate a DER-encoded PKCS#7 signature message for each firmware file
+you can use the

[PATCH 2/4] scripts: sign-file: add firmware-signing option

[AKASHI Takahiro]

This new option (-f) allows us to create a signature file (*.p7s) for
firmware binary.

Signed-off-by: AKASHI Takahiro 
Cc: Luis R. Rodriguez 
---
 scripts/sign-file.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/sign-file.c b/scripts/sign-file.c
index fbd34b8e8f57..211f6531fd7e 100644
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@ -242,8 +242,11 @@ int main(int argc, char **argv)
 #endif
 
do {
-   opt = getopt(argc, argv, "sdpk");
+   opt = getopt(argc, argv, "fsdpk");
switch (opt) {
+   case 'f':
+ use_signed_attrs = 0;
+ sign_only = true; save_sig = true; break;
case 's': raw_sig = true; break;
case 'p': save_sig = true; break;
case 'd': sign_only = true; save_sig = true; break;
-- 
2.11.1

[PATCH 1/4] firmware: add firmware signing

[AKASHI Takahiro]

Systems that have module signing currently enabled may
wish to extend vetting of firmware passed to the kernel
as well. We can re-use most of the code for module signing
for firmware signature verification and signing. This will
also later enable re-use of this same code for subsystems
that wish to provide their own cryptographic verification
requirements on userspace data needed.

Contrary to module signing, the signature files are expected
to be completely detached for practical and licensing puposes.
If you have foo.bin, you'll need foo.bin.p7s file present
for firmware signing.

Firmware signing is per-data per device and if this feature is
enabled permissively (by default), both valid and invalid firmware,
which can be unsigned, signed by non-trusted key, or even one
with invalid digest, will be loaded, just leaving a warning message
in the kernel log.

On the othe hand, in enforcing mode, which is enabled by either
a kernel configuration (CONFIG_FIRMWARE_SIG_FORCE) or a module
parameter (fw_sig_enforce), only the verified firmware are
allowed to be loaded.

There is one driver data option, DRIVER_DATA_REQ_NO_SIG_CHECK,
which will skip signature verification check at load time
even in enforcing mode.
This option is solely for non security-sensitive data.
Please also note any firmware loaded with request_firmware()
will not be affected by firmware signing.

Contrary to module signing, we do not taint the kernel in
the permissive fw signing mode due to restrictions on the
firmware_class API, extensions to enable this are expected
however in the future.

Cc: Rusty Russell 
Cc: David Howells 
Cc: Ming Lei 
Cc: Seth Forshee 
Cc: Kyle McMartin 
Cc: David Woodhouse 
Signed-off-by: Luis R. Rodriguez 
[akashi:migrated to driver data APIs]
Signed-off-by: AKASHI Takahiro 
---
 drivers/base/Kconfig  |  25 +
 drivers/base/firmware_class.c | 211 +++---
 include/linux/driver_data.h   |   5 +
 3 files changed, 229 insertions(+), 12 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 74779ee3d3b1..4c9600437396 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -79,6 +79,31 @@ config FW_LOADER
  require userspace firmware loading support, but a module built
  out-of-tree does.
 
+config FIRMWARE_SIG
+   bool "Firmware signature verification"
+   depends on FW_LOADER
+   select SYSTEM_DATA_VERIFICATION
+   help
+ Check firmware files for valid signatures upon load: if the firmware
+ was called foo.bin, a respective foo.bin.p7s is expected to be
+ present as the signature in the same directory.
+
+ This configuration only affects drivers with driver_data APIs,
+ disabling DRIVER_DATA_REQ_NO_SIG_CHECK.
+
+ For more information see Documentation/driver-api/firmware/signing.rst
+
+config FIRMWARE_SIG_FORCE
+   bool "Require all firmware to be validly signed"
+   depends on FIRMWARE_SIG
+   help
+ Reject unsigned files or signed files for which we don't have
+ a trusted key. Without this, you'll only get a record on kernel
+ log and yet the firmware will be loaded.
+
+ This configuration only affects drivers with driver_data APIs,
+ disabling DRIVER_DATA_REQ_NO_SIG_CHECK.
+
 config FIRMWARE_IN_KERNEL
bool "Include in-kernel firmware blobs in kernel binary"
depends on FW_LOADER
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index e87e91bcd8f8..590a2a834fec 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -146,6 +147,9 @@ struct driver_data_params {
  * o request_firmware_nowait():__DATA_REQ_FIRMWARE_NOWAIT()
  */
 #define __DATA_REQ_FIRMWARE()  \
+   .req_params = { \
+   .reqs = DRIVER_DATA_REQ_NO_SIG_CHECK,   \
+   },  \
.priv_params = {\
.priv_reqs = DRIVER_DATA_PRIV_REQ_FALLBACK |\
 DRIVER_DATA_PRIV_REQ_FALLBACK_UEVENT,  \
@@ -153,7 +157,8 @@ struct driver_data_params {
 
 #define __DATA_REQ_FIRMWARE_DIRECT()   \
.req_params = { \
-   .reqs = DRIVER_DATA_REQ_OPTIONAL,   \
+   .reqs = DRIVER_DATA_REQ_OPTIONAL |  \
+   DRIVER_DATA_REQ_NO_SIG_CHECK,   \
},  \
.priv_params = {\
.priv_reqs = DRIVER_DATA_PRIV_REQ_FALLBACK |\
@@

[PATCH 0/4] firmware: signature verification

[AKASHI Takahiro]

This is my first version of patch series for adding signature
verification to firmware loading.

The original idea and code came from the work by Luis some time ago,
and I migrated it with some improvements to new driver data APIs,
leaving request_firmware() intact.

For details about how it works, please see the commit message of
patch#1 and the document under Documentation/driver-api/firmware.

Please note that patch#3, test script, is still a bit rough-edged,
especially that we have to prepare some data files in advance.
I will try to improve it for better automation.

For you convenience, the patch is available:
https://git.linaro.org/people/takahiro.akashi/linux-aarch64.git
firmware/signature

AKASHI Takahiro (4):
  firmware: add firmware signing
  scripts: sign-file: add firmware-signing option
  test: firmwware: add signature test to driver_data loader test
  firmware: document signature verification for driver data

 Documentation/driver-api/firmware/driver_data.rst  |   6 +
 .../driver-api/firmware/fallback-mechanisms.rst|   5 +-
 Documentation/driver-api/firmware/signing.rst  |  81 +++
 drivers/base/Kconfig   |  25 ++
 drivers/base/firmware_class.c  | 211 +++-
 include/linux/driver_data.h|   5 +
 lib/test_driver_data.c |  56 -
 scripts/sign-file.c|   5 +-
 tools/testing/selftests/firmware/driver_data.sh| 265 -
 9 files changed, 638 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/signing.rst

-- 
2.11.1

[PATCH] staging: lustre: Replace printk_ratelimited with pr_warn_ratelimited

[Konrad Malkowski]

This patch fixes the checkpoint.pl warning:

WARNING: Prefer printk_ratelimited or pr__ratelimited to
printk_ratelimit

Signed-off-by: Konrad Malkowski 
---
 drivers/staging/lustre/lnet/libcfs/tracefile.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/lustre/lnet/libcfs/tracefile.c 
b/drivers/staging/lustre/lnet/libcfs/tracefile.c
index 9599b74..a0efea4 100644
--- a/drivers/staging/lustre/lnet/libcfs/tracefile.c
+++ b/drivers/staging/lustre/lnet/libcfs/tracefile.c
@@ -191,10 +191,9 @@ cfs_trace_get_tage_try(struct cfs_trace_cpu_data *tcd, 
unsigned long len)
} else {
tage = cfs_tage_alloc(GFP_ATOMIC);
if (unlikely(!tage)) {
-   if ((!memory_pressure_get() ||
-in_interrupt()) && printk_ratelimit())
-   pr_warn("cannot allocate a tage 
(%ld)\n",
-   tcd->tcd_cur_pages);
+   if (!memory_pressure_get() || in_interrupt())
+   pr_warn_ratelimited("cannot allocate a 
tage (%ld)\n",
+   tcd->tcd_cur_pages);
return NULL;
}
}
@@ -229,9 +228,8 @@ static void cfs_tcd_shrink(struct cfs_trace_cpu_data *tcd)
 * from here: this will lead to infinite recursion.
 */
 
-   if (printk_ratelimit())
-   pr_warn("debug daemon buffer overflowed; discarding 10%% of 
pages (%d of %ld)\n",
-   pgcount + 1, tcd->tcd_cur_pages);
+   pr_warn_ratelimited("debug daemon buffer overflowed; discarding 10%% of 
pages (%d of %ld)\n",
+   pgcount + 1, tcd->tcd_cur_pages);
 
INIT_LIST_HEAD(&pc.pc_pages);
 
-- 
2.7.4

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

[Dave Young]

Ccing Xunlei he is reading the patches see what need to be done for
kdump. There should still be several places to handle to make kdump work.

On 05/18/17 at 07:01pm, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:22:12PM -0500, Tom Lendacky wrote:
> > Add sysfs support for SME so that user-space utilities (kdump, etc.) can
> > determine if SME is active.
> 
> But why do user-space tools need to know that?
> 
> I mean, when we load the kdump kernel, we do it with the first kernel,
> with the kexec_load() syscall, AFAICT. And that code does a lot of
> things during that init, like machine_kexec_prepare()->init_pgtable() to
> prepare the ident mapping of the second kernel, for example.
> 
> What I'm aiming at is that the first kernel knows *exactly* whether SME
> is enabled or not and doesn't need to tell the second one through some
> sysfs entries - it can do that during loading.
> 
> So I don't think we need any userspace things at all...

If kdump kernel can get the SME status from hardware register then this
should be not necessary and this patch can be dropped.

Thanks
Dave

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

fs/jfs/jfs_metapage.c: In function 'force_metapage':
fs/jfs/jfs_metapage.c:714:2: warning: ignoring return value of 
'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
  write_one_page(page);
  ^
fs/jfs/jfs_metapage.c: In function 'release_metapage':
fs/jfs/jfs_metapage.c:759:4: warning: ignoring return value of 
'write_one_page', declared with attribute warn_unused_result [-Wunused-result]
write_one_page(page);
^

Introduced by commit

  f8652aebee02 ("mm: drop "wait" parameter from write_one_page()")

These call sites were updated for the droppping of the argument, but
not for the addition of __must_check :-(

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

[jeffy]

Hi sean,

On 05/25/2017 11:30 PM, Sean Paul wrote:

On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote:

The system would crash when trying to alloc zero sized gem buffer:
[6.712435] Unable to handle kernel NULL pointer dereference at virtual address 
0010 <--ZERO_SIZE_PTR
...
[6.757502] PC is at sg_alloc_table_from_pages+0x170/0x1ec


It's unfortunate that you didn't include the entire stack trace. From code
inspection, it seems like the 0 size comes from the fb_probe path? Is there
somewhere in the helpers that you could check the mode is sane so all drivers
can benefit?


hmm, sorry, i was testing it on chromeos 4.4 kernel, it turns out that 
we have a custom ioctl for userspace to create gem buffer(the same as 
exynos drm), which might get the the 0 size.


but on upstream kernel, it could only be called by dump_create, and the 
drm_mode_create_dumb_ioctl already did the size check.


will resent this patch, and rewrite the commit message, thanx.



Sean



Signed-off-by: Jeffy Chen 
---

  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..8917922 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -315,6 +315,11 @@ struct rockchip_gem_object *
struct drm_gem_object *obj;
int ret;

+   if (!size) {
+   DRM_ERROR("gem buffer size is zero\n");
+   return ERR_PTR(-EINVAL);
+   }
+
size = round_up(size, PAGE_SIZE);

rk_obj = kzalloc(sizeof(*rk_obj), GFP_KERNEL);
--
2.1.4

Re: [PATCH 5/5] MIPS: Add support for eBPF JIT.

[Alexei Starovoitov]

On Thu, May 25, 2017 at 05:38:26PM -0700, David Daney wrote:
> Since the eBPF machine has 64-bit registers, we only support this in
> 64-bit kernels.  As of the writing of this commit log test-bpf is showing:
> 
>   test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
> 
> All current test cases are successfully compiled.
> 
> Signed-off-by: David Daney 
> ---
>  arch/mips/Kconfig   |1 +
>  arch/mips/net/bpf_jit.c | 1627 
> ++-
>  arch/mips/net/bpf_jit.h |7 +
>  3 files changed, 1633 insertions(+), 2 deletions(-)

Great stuff. I wonder what is the performance difference
interpreter vs JIT

> + * eBPF stack frame will be something like:
> + *
> + *  Entry $sp -->   ++
> + *  |   $ra  (optional)  |
> + *  ++
> + *  |   $s0  (optional)  |
> + *  ++
> + *  |   $s1  (optional)  |
> + *  ++
> + *  |   $s2  (optional)  |
> + *  ++
> + *  |   $s3  (optional)  |
> + *  ++
> + *  |   tmp-storage  (if $ra saved)  |
> + * $sp + tmp_offset --> ++ <--BPF_REG_10
> + *  |   BPF_REG_10 relative storage  |
> + *  |MAX_BPF_STACK (optional)|
> + *  |  . |
> + *  |  . |
> + *  |  . |
> + * $sp >++
> + *
> + * If BPF_REG_10 is never referenced, then the MAX_BPF_STACK sized
> + * area is not allocated.
> + */

It's especially great to see that you've put the tmp storage
above program stack and made the stack allocation optional.
At the moment I'm working on reducing bpf program stack size,
so that JIT and interpreter can use only the stack they need.
Looking at this JIT code only minimal changes will be needed.

[PATCH v2] drm/rockchip: Don't allow zero sized gem buffer

[Jeffy Chen]

Currently we only call this from dumb_create, which would guarantee the
size is non-zero.

But it would be harmless to add a sanity check for it for further
extension.

This is much the same as:
1a5dff5 drm/msm: Don't allow zero sized buffer objects

v2: Rewrite commit message.

Signed-off-by: Jeffy Chen 
---

Changes in v2:
Rewrite commit message.

 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..8917922 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -315,6 +315,11 @@ struct rockchip_gem_object *
struct drm_gem_object *obj;
int ret;
 
+   if (!size) {
+   DRM_ERROR("gem buffer size is zero\n");
+   return ERR_PTR(-EINVAL);
+   }
+
size = round_up(size, PAGE_SIZE);
 
rk_obj = kzalloc(sizeof(*rk_obj), GFP_KERNEL);
-- 
2.1.4

Re: [RESEND: PATCH v4 3/4] remoteproc: qcom: Make secure world call for mem ownership switch

[Bjorn Andersson]

On Tue 16 May 11:02 PDT 2017, Avaneesh Kumar Dwivedi wrote:

> +static int q6v5_assign_mem_to_subsys(struct q6v5 *qproc,
> + phys_addr_t addr, size_t size)
> +{
> + struct qcom_scm_destVmPerm next[] = {{ QCOM_SCM_VMID_MSS_MSA,
> + (QCOM_SCM_PERM_READ | QCOM_SCM_PERM_WRITE)} };

struct qcom_scm_destVmPerm next = {
.vmid = QCOM_SCM_VMID_MSS_MSA,
.perm = QCOM_SCM_PERM_RW
};

> + int ret;
> +
> + size = ALIGN(size, SZ_4K);

I believe it will be cleaner if you just put this alignment directly in
the function call below.

> + if (!qproc->need_mem_protection)
> + return 0;

Put a blank line here, to give separation between the sections of the
function.

> + ret = qcom_scm_assign_mem(addr, size,
> + BIT(QCOM_SCM_VMID_HLOS), next, sizeof(next));

qcom_scm_assign_mem(addr, ALIGN(size, SZ_4K),
BIT(QCOM_SCM_VMID_HLOS), &next, 1);

> + if (ret)
> + pr_err("%s: Failed to assign memory access, ret = %d\n",
> + __func__, ret);

There's no point in printing an error here and in the calling function,
but as it makes sense to have the error message to include which memory
region we operated on (mba vs mpss) I think you should remove the print
here and keep it in the callers.

So just return qcom-scm_assign_mem().

> + return ret;
> +}
> +
> +static int q6v5_assign_mem_to_linux(struct q6v5 *qproc,
> + phys_addr_t addr, size_t size)
> +{
> + struct qcom_scm_destVmPerm next[] = { { QCOM_SCM_VMID_HLOS,
> + (QCOM_SCM_PERM_READ | QCOM_SCM_PERM_WRITE | QCOM_SCM_PERM_EXEC)}
> + };

struct qcom_scm_destVmPerm next = {
.vmid = QCOM_SCM_VMID_HLOS,
.perm = QCOM_SCM_PERM_RWX,
};

(And add RWX to the list of defines in patch 1)

[..]
> @@ -471,6 +517,11 @@ static int q6v5_mpss_init_image(struct q6v5 *qproc, 
> const struct firmware *fw)
>   dev_err(qproc->dev,
>   "metadata authentication failed: %d\n", ret);
>  
> + /* Metadata authentication done, remove modem access */
> + ret = q6v5_assign_mem_to_linux(qproc, phys, fw->size);
> + if (ret)
> + dev_err(qproc->dev,
> + "Failed to reclaim metadata memory, ret - %d\n", ret);

If this assignment fails (for any reason) we can't return the memory to
the free pool in Linux, because at some point in the future these pages
will be allocated to someone else resulting in a memory access violation
scenario that will be just terrible to debug.

I do however not have a better idea at the moment than just leaking the
memory.

>   dma_free_attrs(qproc->dev, fw->size, ptr, phys, dma_attrs);
>  
>   return ret < 0 ? ret : 0;
[..]
> @@ -656,16 +719,21 @@ static int q6v5_start(struct rproc *rproc)
>  
>   ret = q6v5_mpss_load(qproc);
>   if (ret)
> - goto halt_axi_ports;
> + goto reclaim_mem;

This doesn't allow us to distinguish between failures before or after
the memory assignment in mpss_load(), so although you're duplicating the
reclaim code, mpss_load() must be responsible of restoring the state on
failure.

The timeout below still has to reclaim the memory.

>  
>   ret = wait_for_completion_timeout(&qproc->start_done,
> msecs_to_jiffies(5000));
>   if (ret == 0) {
>   dev_err(qproc->dev, "start timed out\n");
>   ret = -ETIMEDOUT;
> - goto halt_axi_ports;
> + goto reclaim_mem;
>   }
>  
> + ret = q6v5_assign_mem_to_linux(qproc,
> + qproc->mba_phys, qproc->mba_size);
> + if (ret)
> + dev_err(qproc->dev,
> + "Failed to reclaim mba memory, ret - %d\n", ret);

I think it's okay for symmetrical purposes to keep the memory assigned
to the remote until we call stop().

Although this shows that we should be able to release the mba allocation
here.

>   qproc->running = true;
>  
>   q6v5_clk_disable(qproc->dev, qproc->proxy_clks,
> @@ -675,12 +743,19 @@ static int q6v5_start(struct rproc *rproc)
>  
>   return 0;
>  
> +reclaim_mem:
> + assign_mem_result =
> + q6v5_assign_mem_to_linux(qproc,
> + qproc->mpss_phys, qproc->mpss_size);

If this fails we're screwed. We have no way to fail in a way that will
not free the memory at any later point in time.

So I do believe you should have a BUG_ON(assign_mem_result); here. With
a clear comment in the lines of:

/*
 * Failed to reclaim memory, any future access to these pages will cause
 * security violations and a seemingly random crash
 */

>  halt_axi_ports:
>   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
>   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
>   q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_nc);
>   q6v5_clk_disable(qproc->dev, qproc->active_clks,
> 

Re: [PATCH 0/2] nohz: Deal with clock reprogram skipping issues v3

[Frederic Weisbecker]

On Wed, May 24, 2017 at 09:16:28AM +0200, Ingo Molnar wrote:
> So the interdiff between your two patches and the 3 commits already queued up 
> is:
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index e3043873fcdc..30253ed0380b 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -150,12 +150,6 @@ static void tick_sched_handle(struct tick_sched *ts, 
> struct pt_regs *regs)
>   touch_softlockup_watchdog_sched();
>   if (is_idle_task(current))
>   ts->idle_jiffies++;
> - /*
> -  * In case the current tick fired too early past its expected
> -  * expiration, make sure we don't bypass the next clock 
> reprogramming
> -  * to the same deadline.
> -  */
> - ts->next_tick = 0;
>   }
>  #endif
>   update_process_times(user_mode(regs));
> @@ -1103,8 +1097,15 @@ static void tick_nohz_handler(struct 
> clock_event_device *dev)
>   tick_sched_handle(ts, regs);
>  
>   /* No need to reprogram if we are running tickless  */
> - if (unlikely(ts->tick_stopped))
> + if (unlikely(ts->tick_stopped)) {
> + /*
> +  * In case the current tick fired too early past its expected
> +  * expiration, make sure we don't bypass the next clock 
> reprogramming
> +  * to the same deadline.
> +  */
> + ts->next_tick = 0;
>   return;
> + }
>  
>   hrtimer_forward(&ts->sched_timer, now, tick_period);
>   tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);
> @@ -1202,12 +1203,17 @@ static enum hrtimer_restart tick_sched_timer(struct 
> hrtimer *timer)
>*/
>   if (regs)
>   tick_sched_handle(ts, regs);
> - else
> - ts->next_tick = 0;
>  
>   /* No need to reprogram if we are in idle or full dynticks mode */
> - if (unlikely(ts->tick_stopped))
> + if (unlikely(ts->tick_stopped)) {
> + /*
> +  * In case the current tick fired too early past its expected
> +  * expiration, make sure we don't bypass the next clock 
> reprogramming
> +  * to the same deadline.
> +  */
> + ts->next_tick = 0;
>   return HRTIMER_NORESTART;
> + }
>  
>   hrtimer_forward(timer, now, tick_period);
>  
> 
> ... so the two are not the same - I'd rather not rebase it, I'd like to keep 
> what 
> is working, we had problems with these changes before ...
> 
> If you'd like the changes in this interdiff to be applied as well, please add 
> a 
> changelog to it and post it as a fourth patch.
> 
> Thanks,
> 
>   Ingo

So if you like, you can replace the top patch with the following. It's exactly
the same code, I've only added a comment and a changelog:

---
>From 72956bf08c3b2e506a5ce5ec4faac9fd6b097307 Mon Sep 17 00:00:00 2001
From: Frederic Weisbecker 
Date: Mon, 15 May 2017 14:56:50 +0200
Subject: [PATCH] nohz: Reset next_tick cache even when the timer has no regs

The tick IRQ regs can be NULL if hrtimer_interrupt() is called from
non-interrupt contexts (ex: hotplug CPU down). For such very special
path we forget to clean the cached next tick deadline. If we are in
dynticks mode and the actual timer deadline is ahead of us, we might
perform a buggy bypass of the next clock reprogramming.

In fact since CPU down is the only user I'm aware of, this fix is likely
unnecessary as dying CPUs already clean their tick deadline cache. But
given how hard it is to debug such timer cache related issue, we should
never be short on paranoid measures.

Signed-off-by: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
---
 kernel/time/tick-sched.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 764d290..ed18ca5 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -1200,8 +1200,17 @@ static enum hrtimer_restart tick_sched_timer(struct 
hrtimer *timer)
 * Do not call, when we are not in irq context and have
 * no valid regs pointer
 */
-   if (regs)
+   if (regs) {
tick_sched_handle(ts, regs);
+   } else {
+   /*
+* IRQ regs are NULL if hrtimer_interrupt() is called from
+* non-interrupt contexts (ex: hotplug cpu down). Make sure to
+* clean the cached next tick deadline to avoid buggy bypass of
+* clock reprog.
+*/
+   ts->next_tick = 0;
+   }
 
/* No need to reprogram if we are in idle or full dynticks mode */
if (unlikely(ts->tick_stopped))
-- 
2.7.4

Re: [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area()

[zhong jiang]

On 2017/5/26 9:36, Wei Yang wrote:
> On Thu, May 25, 2017 at 11:04:44AM +0800, zhong jiang wrote:
>> I hit the overlap issue, but it  is hard to reproduced. if you think it is 
>> safe. and the situation
>> is not happen. AFAIC, it is no need to add the code.
>>
>> if you insist on the point. Maybe VM_WARN_ON is a choice.
>>
> Do you have some log to show the overlap happens?
 Hi  wei

cat /proc/vmallocinfo
0xf158-0xf160  524288 raw_dump_mem_write+0x10c/0x188 phys=8b901000 
ioremap
0xf1638000-0xf163a0008192 mcss_pou_queue_init+0xa0/0x13c [mcss] 
phys=fc614000 ioremap
0xf528e000-0xf5292000   16384 n_tty_open+0x10/0xd0 pages=3 vmalloc
0xf500-0xf9001000 67112960 devm_ioremap+0x38/0x70 phys=4000 ioremap
0xfe001000-0xfe0020004096 iotable_init+0x0/0xc phys=20001000 ioremap
0xfe20-0xfe2010004096 iotable_init+0x0/0xc phys=1a00 ioremap
0xff10-0xff1010004096 iotable_init+0x0/0xc phys=2000a000 ioremap

I hit the above issue, but the log no more useful info. it just is found by 
accident.
and it is hard to reprodeced. no more info can be supported for further 
investigation.
therefore, it is no idea for me. 

Thanks
zhongjinag

Re: [PATCH v3 2/8] x86/mm: Change the leave_mm() condition for local TLB flushes

[Andy Lutomirski]

On Thu, May 25, 2017 at 6:39 PM, Rik van Riel  wrote:
> On Thu, 2017-05-25 at 17:47 -0700, Andy Lutomirski wrote:
>>
>> +++ b/arch/x86/mm/tlb.c
>> @@ -311,7 +311,7 @@ void flush_tlb_mm_range(struct mm_struct *mm,
>> unsigned long start,
>>   goto out;
>>   }
>>
>> - if (!current->mm) {
>> + if (this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK) {
>>   leave_mm(smp_processor_id());
>
> Unless -mm changed leave_mm (I did not check), this
> is not quite correct yet.
>
> The reason is leave_mm (at least in the latest Linus
> tree) ignores the cpu argument for one of its checks.
>
> You should probably fix that in an earlier patch,
> assuming you haven't already done so in -mm.
>
> void leave_mm(int cpu)
> {
> struct mm_struct *active_mm =
> this_cpu_read(cpu_tlbstate.active_mm);
> if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
> BUG();
> if (cpumask_test_cpu(cpu, mm_cpumask(active_mm))) {
> cpumask_clear_cpu(cpu, mm_cpumask(active_mm));
> load_cr3(swapper_pg_dir);

I agree it's odd, but what's the bug?  Both before and after, leave_mm
needed to be called with cpu == smp_processor_id(), and
smp_processor_id() warns if it's called in a preemptible context.

[PATCH v8 0/4] add PCIe driver for Kirin PCIe

[Xiaowei Song]

Before Version Patches
==
patch V7
https://www.spinics.net/lists/linux-pci/msg61664.html
patch V6
https://www.spinics.net/lists/linux-pci/msg61610.html

patch V4
https://www.spinics.net/lists/linux-pci/msg61406.html

patch V3
https://www.spinics.net/lists/linux-pci/msg61399.html


Changes between V8 and V7
=
1. Replace 'reset-gpios' of 'reset-gpio' in Documentation.

Changes between V7 and V6
=
1. add enumeration log Based on Hikey960 Board with these patches.
2. fix issues as fellows:
   (1) delete reduntant blankets in macro defination,
   (2) add blank line in  kirin_pcie_clk_ctrl function.
   (3) Fix compitable property in DT with the SoC name,
   for example "hisilicon,kirin960-pcie".

Changes between V6 and V4
=
1. seperate Document from .dtsi patch.
2. fix issues according to review comments
   from Bjorn Helgaas and Rob Herring: annotation stype, DT node,
   patch post method and so on.

Enumeration log
===
These test logs come from patches running on Hikey960 Board
(1) Connect with Atheros Communications WIFI
OF: PCI: host bridge /soc/kirin_pcie_rc@f400 ranges:
OF: PCI:   MEM 0xf600..0xf7ff -> 0x
kirin-pcie f400.kirin_pcie_rc: PCI host bridge to bus :00
pci_bus :00: root bus resource [bus 00-01]
pci_bus :00: root bus resource [mem 0xf600-0xf7ff] (bus 
address [0x-0x01ff])
pci :00:00.0: [19e5:3660] type 01 class 0x060400
pci :00:00.0: reg 0x10: [mem 0xf600-0xf6ff]
pci :00:00.0: supports D1 D2
pci :00:00.0: PME# supported from D0 D1 D2 D3hot
pci :01:00.0: [168c:002a] type 00 class 0x028000
pci :01:00.0: reg 0x10: [mem 0xf600-0xf600 64bit]
pci :01:00.0: supports D1
pci :01:00.0: PME# supported from D0 D1 D3hot
pci :01:00.0: disabling ASPM on pre-1.1 PCIe device.  You can 
enable it with 'pcie_aspm=force'
pci :00:00.0: BAR 0: assigned [mem 0xf600-0xf6ff]
pci :00:00.0: BAR 14: assigned [mem 0xf700-0xf70f]
pci :01:00.0: BAR 0: assigned [mem 0xf700-0xf700 64bit]
pci :00:00.0: PCI bridge to [bus 01]
pci :00:00.0:   bridge window [mem 0xf700-0xf70f]
pcieport :00:00.0: Signaling PME with IRQ 276
pcieport :00:00.0: AER enabled with IRQ 276 

(2) Connect with Sandisk SSD
OF: PCI: host bridge /soc/kirin_pcie_rc@f400 ranges:
OF: PCI:   MEM 0xf600..0xf7ff -> 0x
kirin-pcie f400.kirin_pcie_rc: PCI host bridge to bus :00
pci_bus :00: root bus resource [bus 00-01]
pci_bus :00: root bus resource [mem 0xf600-0xf7ff] (bus 
address [0x-0x01ff])
pci :00:00.0: [19e5:3660] type 01 class 0x060400
pci :00:00.0: reg 0x10: [mem 0xf600-0xf6ff]
pci :00:00.0: supports D1 D2
pci :00:00.0: PME# supported from D0 D1 D2 D3hot
pci :01:00.0: [1b4b:1093] type 00 class 0x010802
pci :01:00.0: reg 0x10: [mem 0xf600-0xf6003fff 64bit]
pci :01:00.0: reg 0x30: [mem 0xf600-0xf600 pref]
pci :00:00.0: BAR 0: assigned [mem 0xf600-0xf6ff]
pci :00:00.0: BAR 14: assigned [mem 0xf700-0xf70f]
pci :00:00.0: BAR 15: assigned [mem 0xf710-0xf71f pref]
pci :01:00.0: BAR 6: assigned [mem 0xf710-0xf710 pref]
pci :01:00.0: BAR 0: assigned [mem 0xf700-0xf7003fff 64bit]
pci :00:00.0: PCI bridge to [bus 01]
pci :00:00.0:   bridge window [mem 0xf700-0xf70f]
pci :00:00.0:   bridge window [mem 0xf710-0xf71f pref]
pcieport :00:00.0: Signaling PME with IRQ 276
pcieport :00:00.0: AER enabled with IRQ 276

Patches list

Xiaowei Song (4):
  PCI: hisi: Add DT binding for PCIe of Kirin SoC series
  arm64: dts: hisi: add kirin pcie node
  PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC
  defconfig: PCI: Enable  Kirin PCIe defconfig

 .../devicetree/bindings/pci/kirin-pcie.txt |  49 ++
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi  |  31 ++
 arch/arm64/configs/defconfig   |   1 +
 drivers/pci/dwc/Kconfig|  10 +
 drivers/pci/dwc/Makefile   |   1 +
 drivers/pci/dwc/pcie-kirin.c   | 513 +
 6 files changed, 605 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/kirin-pcie.txt
 create mode 100644 drivers/pci/dwc/pcie-kirin.c

-- 
2.11.GIT

[PATCH v8 3/4] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC

[Xiaowei Song]

Hisilicon PCIe Driver shares the common functions for PCIe dw-host

The poweron functions is developed on hi3660 SoC,
while Others Functions are common for Kirin series SoCs.

Low power mode(L1 sub-state and Suspend/Resume), hotplug
and MSI feature are not supported currently.

Cc: Guodong Xu 
Signed-off-by: Xiaowei Song 
---
 drivers/pci/dwc/Kconfig  |  10 +
 drivers/pci/dwc/Makefile |   1 +
 drivers/pci/dwc/pcie-kirin.c | 513 +++
 3 files changed, 524 insertions(+)
 create mode 100644 drivers/pci/dwc/pcie-kirin.c

diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
index d2d2ba5b8a68..13e617b78430 100644
--- a/drivers/pci/dwc/Kconfig
+++ b/drivers/pci/dwc/Kconfig
@@ -130,4 +130,14 @@ config PCIE_ARTPEC6
  Say Y here to enable PCIe controller support on Axis ARTPEC-6
  SoCs.  This PCIe controller uses the DesignWare core.
 
+config PCIE_KIRIN
+   depends on OF && ARM64
+   bool "HiSilicon Kirin series SoCs PCIe controllers"
+   depends on PCI
+   select PCIEPORTBUS
+   select PCIE_DW_HOST
+   help
+ Say Y here if you want PCIe controller support on HiSilicon Kirin 
series SoCs
+ kirin960 SoC
+
 endmenu
diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
index a2df13c28798..4bd69bacd4ab 100644
--- a/drivers/pci/dwc/Makefile
+++ b/drivers/pci/dwc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
 obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
 obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
+obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
 
 # The following drivers are for devices that use the generic ACPI
 # pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
new file mode 100644
index ..2fe3b226957b
--- /dev/null
+++ b/drivers/pci/dwc/pcie-kirin.c
@@ -0,0 +1,513 @@
+/*
+ * PCIe host controller driver for Kirin Phone SoCs
+ *
+ * Copyright (C) 2017 Hilisicon Electronics Co., Ltd.
+ * http://www.huawei.com
+ *
+ * Author: Xiaowei Song 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pcie-designware.h"
+
+#define to_kirin_pcie(x) dev_get_drvdata((x)->dev)
+
+#define REF_CLK_FREQ 1
+
+/* PCIe ELBI registers */
+#define SOC_PCIECTRL_CTRL0_ADDR 0x000
+#define SOC_PCIECTRL_CTRL1_ADDR 0x004
+#define SOC_PCIEPHY_CTRL2_ADDR 0x008
+#define SOC_PCIEPHY_CTRL3_ADDR 0x00c
+#define PCIE_ELBI_SLV_DBI_ENABLE   (0x1 << 21)
+
+#define PCIE_APP_LTSSM_ENABLE  0x01c
+#define PCIE_APB_PHY_CTRL0 0x0
+#define PCIE_APB_PHY_CTRL1 0x4
+#define PCIE_APB_PHY_STATUS0   0x400
+#define PCIE_LINKUP_ENABLE (0x8020)
+#define PCIE_LTSSM_ENABLE_BIT(0x1 << 11)
+#define PIPE_CLK_STABLE(0x1 << 19)
+#define PIPE_CLK_MAX_TRY_TIMES 10
+#define PHY_REF_PAD_BIT(0x1 << 8)
+#define PHY_PWR_DOWN_BIT   (0x1 << 22)
+#define PHY_RST_ACK_BIT(0x1 << 16)
+
+/* info lacated in sysctrl */
+#define SCTRL_PCIE_CMOS_OFFSET 0x60
+#define SCTRL_PCIE_CMOS_BIT0x10
+#define SCTRL_PCIE_ISO_OFFSET  0x44
+#define SCTRL_PCIE_ISO_BIT 0x30
+#define SCTRL_PCIE_HPCLK_OFFSET0x190
+#define SCTRL_PCIE_HPCLK_BIT   0x184000
+#define SCTRL_PCIE_OE_OFFSET   0x14a
+#define PCIE_DEBOUNCE_PARAM0xF0F400
+#define PCIE_OE_BYPASS (0x3 << 28)
+
+/* peri_crg ctrl */
+#define CRGCTRL_PCIE_ASSERT_OFFSET 0x88
+#define CRGCTRL_PCIE_ASSERT_BIT0x8c00
+
+/* Time for delay */
+#define REF_2_PERST_MIN2
+#define REF_2_PERST_MAX25000
+#define PERST_2_ACCESS_MIN 1
+#define PERST_2_ACCESS_MAX 12000
+#define LINK_WAIT_MIN  900
+#define LINK_WAIT_MAX  1000
+#define PIPE_CLK_WAIT_MIN  550
+#define PIPE_CLK_WAIT_MAX  600
+
+struct kirin_pcie {
+   struct dw_pcie  *pci;
+   void __iomem*apb_base;
+   void __iomem*phy_base;
+   struct regmap *crgctrl;
+   struct regmap *sysctrl;
+   struct clk  *apb_sys_clk;
+   struct clk  *apb_phy_clk;
+   struct clk  *phy_ref_clk;
+   struct clk  *pcie_aclk;
+   struct clk  *pcie_aux_clk;
+   int gpio_id_reset;
+};
+
+static inline void kirin_apb_ctrl_writel(struct kirin_pcie *kirin_pcie,
+   u32 val, u32 reg)
+{
+   writel(val, kirin_pcie->apb

[PATCH v8 4/4] defconfig: PCI: Enable Kirin PCIe defconfig

[Xiaowei Song]

Cc: Guodong Xu 
Signed-off-by: Xiaowei Song 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 7c48028ec64a..d56d8f1062ab 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -71,6 +71,7 @@ CONFIG_PCI_XGENE=y
 CONFIG_PCI_LAYERSCAPE=y
 CONFIG_PCI_HISI=y
 CONFIG_PCIE_QCOM=y
+CONFIG_PCIE_KIRIN=y
 CONFIG_PCIE_ARMADA_8K=y
 CONFIG_ARM64_VA_BITS_48=y
 CONFIG_SCHED_MC=y
-- 
2.11.GIT

[PATCH v8 1/4] PCI: hisi: Add DT binding for PCIe of Kirin SoC series

[Xiaowei Song]

Signed-off-by: Xiaowei Song 
---
 .../devicetree/bindings/pci/kirin-pcie.txt | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/kirin-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/kirin-pcie.txt 
b/Documentation/devicetree/bindings/pci/kirin-pcie.txt
new file mode 100644
index ..2dd0e7a368ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/kirin-pcie.txt
@@ -0,0 +1,49 @@
+HiSilicon Kirin SoCs PCIe host DT description
+
+Kirin PCIe host controller is based on Designware PCI core.
+It shares common functions with PCIe Designware core driver
+and inherits common properties defined in
+Documentation/devicetree/bindings/pci/designware-pci.txt.
+
+Additional properties are described here:
+
+Required properties
+- compatible:
+   "hisilicon,kirin960-pcie" for PCIe of Kirin960 SoC
+- reg: Should contain rc_dbi, apb, phy, config registers location and length.
+- reg-names: Must include the following entries:
+  "dbi": controller configuration registers;
+  "apb": apb Ctrl register defined by Kirin;
+  "phy": apb PHY register defined by Kirin;
+  "config": PCIe configuration space registers.
+- reset-gpios: The gpio to generate PCIe perst assert and deassert signal.
+
+Optional properties:
+
+Example based on kirin960:
+
+pcie@f400 {
+compatible = "hisilicon,kirin-pcie";
+reg =  <0x0 0xf400 0x0 0x1000>, <0x0 0xff3fe000 
0x0 0x1000>,
+ <0x0 0xf3f2 0x0 0x4>, <0x0 0xF400 
0 0x2000>;
+reg-names = "dbi","apb","phy", "config";
+bus-range = <0x0  0x1>;
+#address-cells = <3>;
+#size-cells = <2>;
+device_type = "pci";
+ranges = <0x0200 0x0 0x 0x0 0xf500 0x0 
0x200>;
+num-lanes = <1>;
+#interrupt-cells = <1>;
+interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <0x0 0 0 2 &gic 0 0 0  283 4>,
+<0x0 0 0 3 &gic 0 0 0  284 4>,
+<0x0 0 0 4 &gic 0 0 0  285 4>;
+clocks = <&crg_ctrl HI3660_PCIEPHY_REF>,
+<&crg_ctrl HI3660_CLK_GATE_PCIEAUX>,
+<&crg_ctrl HI3660_PCLK_GATE_PCIE_PHY>,
+<&crg_ctrl HI3660_PCLK_GATE_PCIE_SYS>,
+<&crg_ctrl HI3660_ACLK_GATE_PCIE>;
+clock-names = "pcie_phy_ref", "pcie_aux",
+"pcie_apb_phy", "pcie_apb_sys", "pcie_aclk";
+reset-gpios = <&gpio11 1 0 >;
+};
-- 
2.11.GIT

Re: [PATCH 0/20 V3] Misc cleanups for ipc

[Manfred Spraul]

Hi Kees,

On 05/25/2017 09:45 PM, Kees Cook wrote:

On Thu, May 25, 2017 at 11:50 AM, Manfred Spraul
 wrote:

Hi all,

Updated series. The series got longer, because I merged all patches
from Kees.

Main changes are:
- sems[] instead of sem[0].
- Immediately use BUILD_BUG_ON()
- Immediately move the memset() to avoid crashing with SEM_UNDO.
- Use rcu for every security_xx_free(), even if ipc_addid() was not
   successful

This all looks great (excepting the accidental hunk migration). I like
the change to use call_rcu(), though I still think it's overkill. ;)

I still don't see the hunk migration.

What I wanted to do was to merge a fix for the wrong memset into
"[PATCH 02/20] ipc: merge ipc_rcu and kern_ipc_perm"

--
Manfred

[PATCH v2] serial: 8250_of: Add reset support

[Joel Stanley]

This adds the hooks for an optional reset controller in the 8250 device
tree node.

Signed-off-by: Joel Stanley 

---
v2:
 Address Philipp's comments. Thanks for the review!
 - use _shared variant
 - remove unnecessary error handling

 Documentation/devicetree/bindings/serial/8250.txt |  1 +
 drivers/tty/serial/8250/8250_of.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/8250.txt 
b/Documentation/devicetree/bindings/serial/8250.txt
index 10276a46ecef..63e32393f82b 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -45,6 +45,7 @@ Optional properties:
   property.
 - tx-threshold: Specify the TX FIFO low water indication for parts with
   programmable TX FIFO thresholds.
+- resets : phandle + reset specifier pairs
 
 Note:
 * fsl,ns16550:
diff --git a/drivers/tty/serial/8250/8250_of.c 
b/drivers/tty/serial/8250/8250_of.c
index 1cbadafc6889..e95cc9698c32 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -19,11 +19,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "8250.h"
 
 struct of_serial_info {
struct clk *clk;
+   struct reset_control *rst;
int type;
int line;
 };
@@ -132,6 +134,13 @@ static int of_platform_serial_setup(struct platform_device 
*ofdev,
}
}
 
+   info->rst = devm_reset_control_get_optional_shared(&ofdev->dev, NULL);
+   if (IS_ERR(info->rst))
+   goto out;
+   ret = reset_control_deassert(info->rst);
+   if (ret)
+   goto out;
+
port->type = type;
port->uartclk = clk;
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
@@ -231,6 +240,7 @@ static int of_platform_serial_remove(struct platform_device 
*ofdev)
 
if (info->clk)
clk_disable_unprepare(info->clk);
+   reset_control_assert(info->rst);
kfree(info);
return 0;
 }
-- 
2.11.0

Re: [PATCH] serial: 8250_of: Add reset support

[Joel Stanley]

On Wed, May 24, 2017 at 6:18 PM, Philipp Zabel  wrote:
> Hi Joel,
>
> On Wed, 2017-05-24 at 14:53 +1000, Joel Stanley wrote:
>> @@ -132,6 +134,18 @@ static int of_platform_serial_setup(struct 
>> platform_device *ofdev,
>>   }
>>   }
>>
>> + info->rst = devm_reset_control_get_optional(&ofdev->dev, NULL);
>
> Please use devm_reset_control_get_optional_shared instead.
>
> This looks like shared (clock-like) reset use, where you just have to
> make sure that the reset is deasserted while the module is in use, but
> you don't care whether it is actually asserted all the time otherwise.

Thanks for the review. The new reset API is much nicer, and it worked
for me once I realised the changes came in for 4.11 (my test setup is
based on 4.10).

Cheers,

Joel

[PATCH v8 2/4] arm64: dts: hisi: add kirin pcie node

[Xiaowei Song]

Add PCIe node for hi3660, and add binding documentation.

Cc: Guodong Xu 
Signed-off-by: Xiaowei Song 
---
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 3983086bd67b..09ffb4becb65 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -156,5 +156,36 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+   pcie@f400 {
+   compatible = "hisilicon,kirin960-pcie";
+   reg =  <0x0 0xf400 0x0 0x1000>,
+   <0x0 0xff3fe000 0x0 0x1000>,
+   <0x0 0xf3f2 0x0 0x4>,
+   <0x0 0xF500 0x0 0x2000>;
+   reg-names = "dbi", "apb", "phy", "config";
+   bus-range = <0x0  0x1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   ranges = <0x0200 0x0 0x 0x0
+   0xf600 0x0 0x200>;
+   num-lanes = <1>;
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0xf800 0 0 7>;
+   interrupt-map = <0x0 0 0 1 &gic 0 0 0 282 4>,
+   <0x0 0 0 2 &gic 0 0 0  283 4>,
+   <0x0 0 0 3 &gic 0 0 0  284 4>,
+   <0x0 0 0 4 &gic 0 0 0  285 4>;
+   clocks = <&crg_ctrl HI3660_PCIEPHY_REF>,
+   <&crg_ctrl HI3660_CLK_GATE_PCIEAUX>,
+   <&crg_ctrl HI3660_PCLK_GATE_PCIE_PHY>,
+   <&crg_ctrl HI3660_PCLK_GATE_PCIE_SYS>,
+   <&crg_ctrl HI3660_ACLK_GATE_PCIE>;
+   clock-names = "pcie_phy_ref", "pcie_aux",
+   "pcie_apb_phy", "pcie_apb_sys", "pcie_aclk";
+   reset-gpios = <&gpio11 1 0 >;
+   status = "ok";
+   };
};
 };
-- 
2.11.GIT

RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

[Cheng, Collins]

Hi Alex W,

I don't need the kernel patch anymore. However it looks the kernel could be 
improved to handle this more gracefully when PCI resource allocation fail. Do 
you have a plan to improve it in kernel PCI code?

-Collins Cheng


-Original Message-
From: Cheng, Collins 
Sent: Wednesday, May 24, 2017 4:56 PM
To: 'Alex Williamson' 
Cc: Alexander Duyck ; Bjorn Helgaas 
; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 
Deucher, Alexander ; Zytaruk, Kelly 
; Yinghai Lu 
Subject: RE: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV 
incapable platform

Hi Alex W, Alex D,

I just tried two options, one is enable "Above 4G Decoding" in BIOS setup menu, 
the other is add "pci=realloc=off" in grub. Both can fix this issue. Please see 
the attached log files.

Previously I thought "Above 4G Decoding" is enabled, but it is off when I 
looked CMOS setup today.

For now I think we have a solution. For the system that supports "Above 4G 
Decoding", user should enable it when use a SR-IOV supported device. For the 
system that doesn't support "Above 4G Decoding", user needs to add 
"pci=realloc=off" in grub.

Potentially I think kernel still needs to find a way to avoid this issue 
happen, like keeps the resource as the BIOS assigned value if there is a 
failure on device's resource reallocation.


-Collins Cheng


-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com] 
Sent: Wednesday, May 24, 2017 2:20 AM
To: Cheng, Collins 
Cc: Alexander Duyck ; Bjorn Helgaas 
; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 
Deucher, Alexander ; Zytaruk, Kelly 
; Yinghai Lu 
Subject: Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV 
incapable platform

On Tue, 23 May 2017 03:41:21 +
"Cheng, Collins"  wrote:

> Hi Alex,
> 
> I owe you a dmesg log. Attachment are two log files. 1.txt is without 
> "pci=earlydump", 2.txt is with "pci=earlydump". The platform is an ASUS 
> Z170-A motherboard that doesn't support SR-IOV. The graphics card is AMD 
> FirePro S7150 card which enabled SR-IOV. 
> 
> You could find the error info like below in both logs. From the log, kernel 
> failed to reallocate resource for BAR0 which is PF's Frame Buffer BAR (256MB 
> needed), but kernel reallocated resource for BAR9 which is for VF. You are 
> right, the real bug that is something goes wrong with the reallocation 
> leaving the PF without resources.
> 
> [0.992976] pci :01:00.0: BAR 0: no space for [mem size 0x1000 
> 64bit pref]
> [0.992976] pci :01:00.0: BAR 0: failed to assign [mem size 0x1000 
> 64bit pref]
> [0.992977] pci :01:00.0: BAR 7: no space for [mem size 0x4000 
> 64bit pref]
> [0.992978] pci :01:00.0: BAR 7: failed to assign [mem size 0x4000 
> 64bit pref]
> [0.992979] pci :01:00.0: BAR 9: assigned [mem 0x88c0-0x8abf 
> 64bit pref]
> [0.992986] pci :01:00.0: BAR 12: no space for [mem size 0x0200]
> [0.992986] pci :01:00.0: BAR 12: failed to assign [mem size 
> 0x0200]
> [0.992988] pci :01:00.0: BAR 2: assigned [mem 0x8ac0-0x8adf 
> 64bit pref]
> [0.992994] pci :01:00.0: BAR 5: no space for [mem size 0x0004]
> [0.992995] pci :01:00.0: BAR 5: failed to assign [mem size 0x0004]
> [0.992996] pci :01:00.0: BAR 6: no space for [mem size 0x0002 
> pref]
> [0.992997] pci :01:00.0: BAR 6: failed to assign [mem size 0x0002 
> pref]

I've tried to extract more of the relevant resizing efforts below, perhaps 
Yinghai or others can make more out of it.  In particular this system offers no 
64-bit MMIO and we'll never manage to allocate the necessary SR-IOV resources 
without it.  AIUI, the PCI core won't try to use anything outside the ACPI _CRS 
data without the option pci=nocrs.
This might present a second alternative in addition to the pci=realloc=off, 
which is actually suggested by the kernel below.  So I think we have at least 
two potential workarounds in the code as it exists today, one leaving SR-IOV 
disabled, the other (hopefully) enabling it using 64bit MMIO not described by 
the system BIOS.
Certainly an improvement would still be detecting the impossible reallocation 
problem without nocrs and abandoning the process and of course to revert the 
process before leaving more BARs unprogrammed than we started with.  Thanks,

Alex

[0.891319] pci_bus :00: root bus resource [io  0x-0x0cf7 window]
[0.891321] pci_bus :00: root bus resource [io  0x0d00-0x window]
[0.891322] pci_bus :00: root bus resource [mem 0x000a-0x000b 
window]
[0.891323] pci_bus :00: root bus resource [mem 0x8880-0xdfff 
window]
[0.891324] pci_bus :00: root bus resource [mem 0xfd00-0xfe7f 
window]
[0.891325] pci_bus :00: root bus resource [bus 00-fe]
...
[0.896481] pci :01:00.0: [1002:6929] type 00 class 0x03
[0.896496] pci :01:00.0: reg 0x1

[PATCH -next] mtd: nand: Add support for Toshiba BENAND (Built-in ECC NAND)

[KOBAYASHI Yoshitake]

This patch enables support for Toshiba BENAND. It was originally posted on
  https://lkml.org/lkml/2015/7/24/571

This patch is rewrote to adapt the recent mtd "separate vendor specific code
from core" cleanup process.

Signed-off-by: KOBAYASHI Yoshitake 
---
 drivers/mtd/nand/Kconfig|  17 ++
 drivers/mtd/nand/nand_base.c|  15 ++
 drivers/mtd/nand/nand_toshiba.c | 112 +++-
 include/linux/mtd/nand.h|   1 +
 4 files changed, 143 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 0bd2319..6634d4b 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -36,6 +36,23 @@ config MTD_NAND_ECC_BCH
  ECC codes. They are used with NAND devices requiring more than 1 bit
  of error correction.
 
+config MTD_NAND_BENAND
+   bool "Support for Toshiba BENAND (Built-in ECC NAND)"
+   default n
+   help
+ This enables support for Toshiba BENAND.
+ Toshiba BENAND is a SLC NAND solution that automatically
+ generates ECC inside NAND chip.
+
+config MTD_NAND_BENAND_ECC_STATUS
+   bool "Enable ECC Status Read Command(0x7A)"
+   depends on MTD_NAND_BENAND
+   default n
+   help
+ This enables support for ECC Status Read Command(0x7A) of BENAND.
+ When this enables, report the real number of bitflips.
+ In other cases, report the assumud number.
+
 config MTD_SM_COMMON
tristate
default n
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 43722a8..ab8652e 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4186,6 +4186,7 @@ static const char * const nand_ecc_modes[] = {
[NAND_ECC_HW_SYNDROME]  = "hw_syndrome",
[NAND_ECC_HW_OOB_FIRST] = "hw_oob_first",
[NAND_ECC_ON_DIE]   = "on-die",
+   [NAND_ECC_BENAND]   = "benand",
 };
 
 static int of_get_nand_ecc_mode(struct device_node *np)
@@ -4751,6 +4752,19 @@ int nand_scan_tail(struct mtd_info *mtd)
ecc->write_oob = nand_write_oob_std;
break;
 
+   case NAND_ECC_BENAND:
+   if (!ecc->read_page || !ecc->read_subpage) {
+   WARN(1, "No ECC functions supplied; benand ECC not 
possible\n");
+   ret = -EINVAL;
+   goto err_free;
+   }
+   ecc->write_page = nand_write_page_raw;
+   ecc->read_page_raw = nand_read_page_raw;
+   ecc->write_page_raw = nand_write_page_raw;
+   ecc->read_oob = nand_read_oob_std;
+   ecc->write_oob = nand_write_oob_std;
+   break;
+
case NAND_ECC_NONE:
pr_warn("NAND_ECC_NONE selected by board driver. This is not 
recommended!\n");
ecc->read_page = nand_read_page_raw;
@@ -4831,6 +4845,7 @@ int nand_scan_tail(struct mtd_info *mtd)
/* Large page NAND with SOFT_ECC should support subpage reads */
switch (ecc->mode) {
case NAND_ECC_SOFT:
+   case NAND_ECC_BENAND:
if (chip->page_shift > 9)
chip->options |= NAND_SUBPAGE_READ;
break;
diff --git a/drivers/mtd/nand/nand_toshiba.c b/drivers/mtd/nand/nand_toshiba.c
index fa787ba..bb3c852 100644
--- a/drivers/mtd/nand/nand_toshiba.c
+++ b/drivers/mtd/nand/nand_toshiba.c
@@ -17,6 +17,97 @@
 
 #include 
 
+/* ECC Status Read Command for BENAND */
+#define NAND_CMD_ECC_STATUS0x7A
+
+/* Recommended to rewrite for BENAND */
+#define NAND_STATUS_RECOM_REWRT0x08
+
+
+static int toshiba_nand_benand_status_chk(struct mtd_info *mtd,
+   struct nand_chip *chip)
+{
+   unsigned int max_bitflips = 0;
+   u8 status;
+
+   /* Check Read Status */
+   chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+   status = chip->read_byte(mtd);
+
+   /* timeout */
+   if (!(status & NAND_STATUS_READY)) {
+   pr_debug("BENAND : Time Out!\n");
+   return -EIO;
+   }
+
+   /* uncorrectable */
+   else if (status & NAND_STATUS_FAIL)
+   mtd->ecc_stats.failed++;
+
+   /* correctable */
+   else if (status & NAND_STATUS_RECOM_REWRT) {
+   if (chip->cmd_ctrl &&
+   IS_ENABLED(CONFIG_MTD_NAND_BENAND_ECC_STATUS)) {
+
+   int i;
+   u8 ecc_status;
+   unsigned int bitflips;
+
+   /* Check Read ECC Status */
+   chip->cmd_ctrl(mtd, NAND_CMD_ECC_STATUS,
+   NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
+   /* Get bitflips info per 512Byte */
+   for (i = 0; i < mtd->writesize >> 9; i++) {
+   ecc_status = chip->read_byte(mtd);
+   bitflips = ecc_status & 0x0f;
+

Re: [PATCH v3 2/8] x86/mm: Change the leave_mm() condition for local TLB flushes

[Nadav Amit]

> On May 25, 2017, at 5:47 PM, Andy Lutomirski  wrote:
> 
> On a remote TLB flush, we leave_mm() if we're TLBSTATE_LAZY.  For a
> local flush_tlb_mm_range(), we leave_mm() if !current->mm.  These
> are approximately the same condition -- the scheduler sets lazy TLB
> mode when switching to a thread with no mm.
> 
> I'm about to merge the local and remote flush code, but for ease of
> verifying and bisecting the patch, I want the local and remote flush
> behavior to match first.  This patch changes the local code to match
> the remote code.
> 
> Cc: Rik van Riel 
> Cc: Dave Hansen 
> Cc: Nadav Amit 
> Cc: Michal Hocko 
> Cc: Arjan van de Ven 
> Signed-off-by: Andy Lutomirski 
> ---
> arch/x86/mm/tlb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 776469cc54e0..3143c9a180e5 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -311,7 +311,7 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned 
> long start,
>   goto out;
>   }
> 
> - if (!current->mm) {
> + if (this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK) {
>   leave_mm(smp_processor_id());

Maybe it is an overkill, but you may want to have two variants: leave_mm()
and leave_mm_irq_off(). Currently, leave_mm() does not disable IRQs, but
in patch 6 it does. Here you indeed need to disable IRQs, but the cases
in prior to this patch - you do not.

Re: [GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12

[Masahiro Yamada]

Hi Olof,

2017-05-26 8:59 GMT+09:00 Olof Johansson :
> On Mon, May 22, 2017 at 11:03:49AM +0900, Masahiro Yamada wrote:
>> Hi Arnd, Olof,
>>
>> Last week, I thought I found a problem in my pull request,
>> but it turned out my misunderstanding.
>>
>> So, my pull request I sent is OK.
>> I am re-sending this request mail for clarification.
>>
>> Here are some ARM UniPhier SoC fixes for v4.12.
>> Due to the eMMC driver update, PHY parameters must be specified
>> via DT to make the eMMC controller work again.
>
> That's not good, that's a regression in behavior. The driver should
> have a fallback when the properties are not present to avoid regressions
> like these.

Right.  The care for old DT is missing from the driver change.
Theoretically, it is a regression if Linux 4.12 kernel image is used with
DT from Linux 4.11 tree.

However, all our customer products are based on Linux 4.4 (or older)
so I am sure there is no practical problem.
Because the eMMC driver was not upstreamed at that time,
products kernels are locally patched as needed.

I am upstreaming patches to create a better code base for future products, but
Linux 4.11 and 4.12 are not LTS, so never used at least on socionext products.


> Please work with the driver maintainer to either get them to revert
> their change that regresses you, or promptly fix it appropriately with
> fallback values.

You are right, but this is a different issue.


If you are unhappy with pulling this as a fix
(because it is not DT but the driver that should be fixed),
I can include the DT changes in usual PRs for v4.13-rc1.


As I said above, I admit this is not fatal for us
because socionext kernel developers are co-located
and know the upstream status.



> Also, the driver changes were commited back in March, with plenty of time
> to land DT changes well before the merge window. Waiting until the merge
> window is closed is not appropriate -- this should have come in earlier.

You are right.
But, v4.11-rc4 had already passed and I had already sent the pull request
before the driver change was merged.

I generally try to send my PRs around -rc4
because "sorry, this is too late" is scary.
I should have sent the second pull request.
If you do not mind some after -rc4, I will do late PRs next time.


So, what should I do about this?

If you do not want to pull this, I will move the patches
to for-v4.13 branch, which will be sent around -rc4.

-- 
Best Regards
Masahiro Yamada

答复: 答复: [Patch v3 1/3] arm64: dts: hi3660: add pcie node

[songxiaowei]

-邮件原件-
发件人: Rob Herring [mailto:r...@kernel.org] 
发送时间: 2017年5月25日 20:39
收件人: songxiaowei
抄送: Wangzhou (B); Gabriele Paoloni; bhelg...@google.com; mark.rutl...@arm.com; 
xuwei (O); catalin.mari...@arm.com; will.dea...@arm.com; 
linux-...@vger.kernel.org; devicet...@vger.kernel.org; 
linux-kernel@vger.kernel.org; Chenfeng (puck); guodong...@linaro.org; 
Wangbinghui; Suzhuangluan
主题: Re: 答复: [Patch v3 1/3] arm64: dts: hi3660: add pcie node

On Tue, May 23, 2017 at 8:39 PM, songxiaowei  wrote:
> -邮件原件-
> 发件人: Rob Herring [mailto:r...@kernel.org]
> 发送时间: 2017年5月23日 22:17
> 收件人: songxiaowei
> 抄送: Wangzhou (B); Gabriele Paoloni; bhelg...@google.com; 
> mark.rutl...@arm.com; xuwei (O); catalin.mari...@arm.com; 
> will.dea...@arm.com; linux-...@vger.kernel.org; devicet...@vger.kernel.org; 
> linux-kernel@vger.kernel.org; Chenfeng (puck); guodong...@linaro.org; 
> Wangbinghui; Suzhuangluan
> 主题: Re: [Patch v3 1/3] arm64: dts: hi3660: add pcie node
>
> On Thu, May 18, 2017 at 03:49:46PM +0800, Song Xiaowei wrote:
>> Add PCIe node for hi3660, and add binding documentation.
>>
>> Cc: Guodong Xu 
>> Signed-off-by: Song Xiaowei 
>> ---
>>  .../devicetree/bindings/pci/hisilicon-pcie.txt | 52 
>> ++
>>  arch/arm64/boot/dts/hisilicon/hi3660.dtsi  | 31 +

[...]

>> +  "config": PCIe configuration space registers.
>> +- reset-gpio: perst assert/deassert gpio
>
> reset-gpios
> [songxiaowei] rest-gpio is used to signal 'pcie perst': high level refers to 
> deassert
>  and low level refers to assert. So, I think ' reset-gpio: 
> creates perst assert/deassert signal '
> would be a better choice.

What I was saying is the name should be reset-gpios, not reset-gpio.

[songxiaowei] Ok, I'll fix it. In fact, perst signal only use one line, so 
reset-gpios contains only one gpio.
Rob

Re: [PATCH v3 2/8] x86/mm: Change the leave_mm() condition for local TLB flushes

[Rik van Riel]

On Thu, 2017-05-25 at 17:47 -0700, Andy Lutomirski wrote:
> 
> +++ b/arch/x86/mm/tlb.c
> @@ -311,7 +311,7 @@ void flush_tlb_mm_range(struct mm_struct *mm,
> unsigned long start,
>   goto out;
>   }
>  
> - if (!current->mm) {
> + if (this_cpu_read(cpu_tlbstate.state) != TLBSTATE_OK) {
>   leave_mm(smp_processor_id());

Unless -mm changed leave_mm (I did not check), this
is not quite correct yet.

The reason is leave_mm (at least in the latest Linus
tree) ignores the cpu argument for one of its checks.

You should probably fix that in an earlier patch,
assuming you haven't already done so in -mm.

void leave_mm(int cpu)
{
struct mm_struct *active_mm =
this_cpu_read(cpu_tlbstate.active_mm);
if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
BUG();
if (cpumask_test_cpu(cpu, mm_cpumask(active_mm))) {
cpumask_clear_cpu(cpu, mm_cpumask(active_mm));
load_cr3(swapper_pg_dir);

Re: [PATCH] mm/vmalloc: a slight change of compare target in __insert_vmap_area()

[Wei Yang]

On Thu, May 25, 2017 at 11:04:44AM +0800, zhong jiang wrote:
>I hit the overlap issue, but it  is hard to reproduced. if you think it is 
>safe. and the situation
>is not happen. AFAIC, it is no need to add the code.
>
>if you insist on the point. Maybe VM_WARN_ON is a choice.
>

Do you have some log to show the overlap happens?


signature.asc
Description: PGP signature

Re: [PATCH] x86/ftrace: Make sure that ftrace trampolines are not RWX

[Masami Hiramatsu]

On Thu, 25 May 2017 11:18:02 -0400
Steven Rostedt  wrote:

> On Thu, 25 May 2017 19:34:43 +0900
> Masami Hiramatsu  wrote:
> 
> 
> > OK, I've ensured that following command hits same BUG.
> > 
> > grep t /proc/kallsyms  | cut -f3 -d" " | grep -v .*\\..* | \
> > head -n 256 | while read i; do echo p $i+5 ; done >
> > tracing/kprobe_events
> > 
> > echo 1 > tracing/events/kprobes/enable 
> > echo 0 > tracing/events/kprobes/enable
> > echo > tracing/kprobe_events
> > sleep 5
> 
> Hi Masami,
> 
> Can you add a selftest that checks this too?

Yes, however, it should be included after my fix is
accepted, or it can cause a kernel panic...

Thanks,



-- 
Masami Hiramatsu 

Re: [RFC PATCH tip/master] kprobes: Use synchronize_rcu_tasks() for optprobe wit CONFIG_PREEMPT

[Masami Hiramatsu]

On Thu, 25 May 2017 08:14:01 -0700
"Paul E. McKenney"  wrote:

> On Thu, May 25, 2017 at 08:15:55AM +0200, Ingo Molnar wrote:
> > 
> > * Masami Hiramatsu  wrote:
> > 
> > > --- a/kernel/kprobes.c
> > > +++ b/kernel/kprobes.c
> > > @@ -377,6 +377,23 @@ static inline void copy_kprobe(struct kprobe *ap, 
> > > struct kprobe *p)
> > >  static bool kprobes_allow_optimization;
> > >  
> > >  /*
> > > + * Synchronizing wait on trampline code for interrupted tasks/threads.
> > > + * Since the threads running on dynamically allocated trampline code
> > > + * can be interrupted, kprobes has to wait for those tasks back on
> > > + * track and scheduled. If the kernel is preemptive, the thread can be
> > > + * preempted by other tasks on the trampoline too. For such case, this
> > > + * calls synchronize_rcu_tasks() to wait for those tasks back on track.
> > > + */
> > > +static void synchronize_on_trampoline(void)
> > > +{
> > > +#ifdef CONFIG_PREEMPT
> > > + synchronize_rcu_tasks();
> > > +#else
> > > + synchronize_sched();
> > > +#endif
> > > +}
> > 
> > So that's really unacceptably ugly.
> > 
> > Paul, I still question the need to have tasks-RCU as a Kconfig distinction, 
> > _especially_ if its API usage results in such ugly secondary #ifdefs...
> > 
> > Why isn't there a single synchronize_rcu_tasks() API function, which does 
> > what is 
> > expected, where the _RCU_ code figures out how to implement it?
> > 
> > I.e.:
> > 
> >  - There should be no user configurable TASKS_RCU Kconfig setting - at most 
> > a
> >helper Kconfig that is automatically selected by the RCU code itself.
> > 
> >  - Both ftrace andkprobes would use a simple synchronize_rcu_tasks() call.
> > 
> > Thanks,
> 
> How about the following (untested) patch?

This patch is good to me for kprobes at least.

Reviewed-by: Masami Hiramatsu 

Steve, how about ftrace usage?

Thank you,

> 
> This is against -rcu's rcu/dev branch, FWIW.
> 
> And I am also queuing patches with other cleanups, including do_exit(),
> enabled by this approach.
> 
>   Thanx, Paul
> 
> 
> 
> commit 9ab47fba45cea06e223e524d392621b64c174720
> Author: Paul E. McKenney 
> Date:   Thu May 25 08:05:00 2017 -0700
> 
> rcu: Drive TASKS_RCU directly off of PREEMPT
> 
> The actual use of TASKS_RCU is only when PREEMPT, otherwise RCU-sched
> is used instead.  This commit therefore makes synchronize_rcu_tasks()
> and call_rcu_tasks() available always, but mapped to synchronize_sched()
> and call_rcu_sched(), respectively, when !PREEMPT.  This approach also
> allows some #ifdefs to be removed from rcutorture.
> 
> Reported-by: Ingo Molnar 
> Signed-off-by: Paul E. McKenney 
> 
> ---
> 
>  include/linux/rcupdate.h |6 --
>  kernel/rcu/Kconfig   |3 +--
>  kernel/rcu/rcutorture.c  |   17 +
>  3 files changed, 6 insertions(+), 20 deletions(-)
> 
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index f816fc72b51e..c3f380befdd7 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -58,8 +58,6 @@ void call_rcu(struct rcu_head *head, rcu_callback_t func);
>  void call_rcu_bh(struct rcu_head *head, rcu_callback_t func);
>  void call_rcu_sched(struct rcu_head *head, rcu_callback_t func);
>  void synchronize_sched(void);
> -void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func);
> -void synchronize_rcu_tasks(void);
>  void rcu_barrier_tasks(void);
>  
>  #ifdef CONFIG_PREEMPT_RCU
> @@ -176,10 +174,14 @@ extern struct srcu_struct tasks_rcu_exit_srcu;
>   rcu_all_qs(); \
>   rcu_note_voluntary_context_switch_lite(t); \
>   } while (0)
> +void call_rcu_tasks(struct rcu_head *head, rcu_callback_t func);
> +void synchronize_rcu_tasks(void);
>  #else /* #ifdef CONFIG_TASKS_RCU */
>  #define TASKS_RCU(x) do { } while (0)
>  #define rcu_note_voluntary_context_switch_lite(t)do { } while (0)
>  #define rcu_note_voluntary_context_switch(t) rcu_all_qs()
> +#define call_rcu_tasks call_rcu_sched
> +#define synchronize_rcu_tasks synchronize_sched
>  #endif /* #else #ifdef CONFIG_TASKS_RCU */
>  
>  /**
> diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
> index be90c945063f..9210379c0353 100644
> --- a/kernel/rcu/Kconfig
> +++ b/kernel/rcu/Kconfig
> @@ -69,8 +69,7 @@ config TREE_SRCU
> This option selects the full-fledged version of SRCU.
>  
>  config TASKS_RCU
> - bool
> - default n
> + def_bool PREEMPT
>   select SRCU
>   help
> This option enables a task-based RCU implementation that uses
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index aedc8f2ad955..273032dc8f2d 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -659,8 +659,6 @@ static struct rcu_torture_ops sched_ops = {
>   .name   = "sched"
>  };
>  
> -#ifdef CONFIG

Re: [PATCH] staging: iio: light: Replace snprintf calls with scnprintf

[harinath Nampally]

Greg,

Sure, I will fix it and resend a fresh patch.

Thanks,
Hari

Re: [PATCH] clocksource: moxart: Add AST2500 compatible string

[Andrew Jeffery]

On Thu, 2017-05-25 at 22:28 +0200, Daniel Lezcano wrote:
> On Tue, May 16, 2017 at 03:58:40PM +0800, Andrew Jeffery wrote:
> > Also clean up space-before-tab issues in the documentation.
> 
> Andrew,
> 
> I reworked the patch to apply to the changes Linus did recently to convert to
> the fttrm010 driver.
> 
> Please have a look at:
> 
> https://git.linaro.org/people/daniel.lezcano/linux.git/commit/?h=clockevents/4.13&id=3ca904162ffdd72f4fad3ab731fc94a12c50f682
> 

I think we're going to run into trouble here:

https://git.linaro.org/people/daniel.lezcano/linux.git/tree/drivers/clocksource/timer-fttmr010.c?h=clockevents/4.13&id=3ca904162ffdd72f4fad3ab731fc94a12c50f682#n260

As it stands if a aspeed,ast2500-timer compatible is provided we'll
take the else branch and hit the issues Joel found with Linus' original
series counting up on the Aspeed hardware.

My change was somewhat cosmetic - Ben (now Cc'ed) didn't seemed too
concerned about using the the aspeed,ast2400-timer compatible string
for ast2500 dts. My motivation for the patch was that by describing the
aspeed,ast2500-timer compatible it signals that someone had taken a
look and judged it so. However, my point is maybe one solution is
simply to drop the patch and continue to use aspeed,ast2400-timer
compatible where we need.

Another is to rework your change to switch to
of_device_compatible_match() in drivers/clocksource/timer-fttmr010.c
and also check against aspeed,ast2500-timer.

What direction should we go?

> Shouldn't the compatible string be:
> 
>   "aspeed,ast2400-timer", "faraday,fttmr010"
>   "aspeed,ast2500-timer", "faraday,fttmr010"
> 

Does it makes sense in the face of the Aspeed quirks? If so it seems
reasonable, but falling back to the faraday,fttmr010 compatible could
lead to failures (if the compatible driver counted up).

Cheers,

Andrew

> 
>   -- Daniel
> 

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 2/5] kmod: reduce atomic operations on kmod_concurrent

[Dmitry Torokhov]

On Thu, May 25, 2017 at 05:16:27PM -0700, Luis R. Rodriguez wrote:
> When checking if we want to allow a kmod thread to kick off we increment,
> then read to see if we should enable a thread. If we were over the allowed
> limit limit we decrement. Splitting the increment far apart from decrement
> means there could be a time where two increments happen potentially
> giving a false failure on a thread which should have been allowed.
> 
> CPU1  CPU2
> atomic_inc()
>   atomic_inc()
> atomic_read()
>   atomic_read()
> atomic_dec()
>   atomic_dec()
> 
> In this case a read on CPU1 gets the atomic_inc()'s and we could negate
> it from getting a kmod thread. We could try to prevent this with a lock
> or preemption but that is overkill. We can fix by reducing the number of
> atomic operations. We do this by inverting the logic of of the enabler,
> instead of incrementing kmod_concurrent as we get new kmod users, define the
> variable kmod_concurrent_max as the max number of currently allowed kmod
> users and as we get new kmod users just decrement it if its still positive.
> This combines the dec and read in one atomic operation.
> 
> In this case we no longer get the same false failure:
> 
> CPU1  CPU2
> atomic_dec_if_positive()
>   atomic_dec_if_positive()
> atomic_inc()
>   atomic_inc()
> 
> Suggested-by: Petr Mladek 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  include/linux/kmod.h |  2 ++
>  init/main.c  |  1 +
>  kernel/kmod.c| 44 +---
>  3 files changed, 28 insertions(+), 19 deletions(-)
> 
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> index c4e441e00db5..8e2f302b214a 100644
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -38,10 +38,12 @@ int __request_module(bool wait, const char *name, ...);
>  #define request_module_nowait(mod...) __request_module(false, mod)
>  #define try_then_request_module(x, mod...) \
>   ((x) ?: (__request_module(true, mod), (x)))
> +void init_kmod_umh(void);
>  #else
>  static inline int request_module(const char *name, ...) { return -ENOSYS; }
>  static inline int request_module_nowait(const char *name, ...) { return 
> -ENOSYS; }
>  #define try_then_request_module(x, mod...) (x)
> +static inline void init_kmod_umh(void) { }
>  #endif
>  
>  
> diff --git a/init/main.c b/init/main.c
> index 9ec09ff8a930..9b20be716cf7 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -650,6 +650,7 @@ asmlinkage __visible void __init start_kernel(void)
>   thread_stack_cache_init();
>   cred_init();
>   fork_init();
> + init_kmod_umh();
>   proc_caches_init();
>   buffer_init();
>   key_init();
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 563f97e2be36..cafd27b92d19 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -46,6 +46,7 @@
>  #include 
>  
>  extern int max_threads;
> +unsigned int max_modprobes;
>  
>  #define CAP_BSET (void *)1
>  #define CAP_PI   (void *)2
> @@ -56,6 +57,8 @@ static DEFINE_SPINLOCK(umh_sysctl_lock);
>  static DECLARE_RWSEM(umhelper_sem);
>  
>  #ifdef CONFIG_MODULES
> +static atomic_t kmod_concurrent_max = ATOMIC_INIT(0);
> +#define MAX_KMOD_CONCURRENT 50   /* Completely arbitrary value - KAO */
>  
>  /*
>   modprobe_path is set via /proc/sys.
> @@ -127,10 +130,7 @@ int __request_module(bool wait, const char *fmt, ...)
>  {
>   va_list args;
>   char module_name[MODULE_NAME_LEN];
> - unsigned int max_modprobes;
>   int ret;
> - static atomic_t kmod_concurrent = ATOMIC_INIT(0);
> -#define MAX_KMOD_CONCURRENT 50   /* Completely arbitrary value - KAO */
>   static int kmod_loop_msg;
>  
>   /*
> @@ -154,21 +154,7 @@ int __request_module(bool wait, const char *fmt, ...)
>   if (ret)
>   return ret;
>  
> - /* If modprobe needs a service that is in a module, we get a recursive
> -  * loop.  Limit the number of running kmod threads to max_threads/2 or
> -  * MAX_KMOD_CONCURRENT, whichever is the smaller.  A cleaner method
> -  * would be to run the parents of this process, counting how many times
> -  * kmod was invoked.  That would mean accessing the internals of the
> -  * process tables to get the command line, proc_pid_cmdline is static
> -  * and it is not worth changing the proc code just to handle this case. 
> -  * KAO.
> -  *
> -  * "trace the ppid" is simple, but will fail if someone's
> -  * parent exits.  I think this is as good as it gets. --RR
> -  */
> - max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
> - atomic_inc(&kmod_concurrent);
> - if (atomic_read(&kmod_concurrent) > max_modprobes) {
> + if (atomic_dec_if_positive(&kmod_concurrent_max) < 0) {
>   /* We may be blaming an innocent here, but unlikely */
>   if (kmod_loop_msg < 5) {