date:20190612

On Sun, Jun 9, 2019 at 4:55 PM Masahiro Yamada
 wrote:

> The iterator is initialized in list_for_each_entry().
>
> Signed-off-by: Masahiro Yamada 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] pinctrl: remove unused pin_is_valid()

On Sun, Jun 9, 2019 at 5:10 PM Masahiro Yamada
 wrote:

> This function was used by pin_request() to pointlessly double-check
> the pin validity, and it was the only user ever.
>
> Since commit d2f6a1c6fb0e ("pinctrl: remove double pin validity
> check."), no one has ever used it.
>
> Signed-off-by: Masahiro Yamada 

Good catch!
Patch applied.

Yours,
Linus Walleij

Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ

2019-06-12 Thread Thomas Gleixner

On Mon, 10 Jun 2019, Leonard Crestez wrote:
> On 6/10/2019 5:08 PM, Marc Zyngier wrote:
> > Nobody is talking about performance here. It is strictly about
> > correctness, and what I read about this system is that it cannot
> > reliably use cpuidle.
> My argument was that it's fine if PPIs and LPIs are broken as long as 
> they're not used:
> 
>   * PPIs are only used for local timer which is not used for wakeup.

Huch? The timer has to bring the CPU out of idle as any other interrupt. 

Thanks,

tglx

Re: [PATCH] Input: alps: Drop unlikely before IS_ERR(_OR_NULL)

2019-06-12 Thread Pali Rohár

On Tuesday 11 June 2019 17:59:13 Dmitry Torokhov wrote:
> Hi Joe,
> 
> On Wed, Jun 05, 2019 at 07:28:53PM -0700, Joe Perches wrote:
> > On Thu, 2019-06-06 at 09:08 +0800, Kefeng Wang wrote:
> > > On 2019/6/5 22:42, Pali Rohár wrote:
> > > > On Wednesday 05 June 2019 22:24:28 Kefeng Wang wrote:
> > > > > IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag,
> > > > > so no need to do that again from its callers. Drop it.
> > > > Hi! I already reviewed this patch and rejected it, see:
> > > > https://patchwork.kernel.org/patch/10817475/
> > > OK, please ignore it.
> > 
> > I think the stated reason of better readability isn't
> > particularly sensible as the object code produced is
> > actually slightly larger.
> > 
> > x86-64 defconfig (gcc 8.3.0)
> > 
> > $ size drivers/input/mouse/alps.o*
> >textdata bss dec hex filename
> >   29416  56   0   294727320 drivers/input/mouse/alps.o.new
> >   29432  56   0   294887330 drivers/input/mouse/alps.o.old
> 
> If gcc produces worse code for double unlikely, you should probably
> report it to gcc folks, no? Or double unlikely turns into likely?

Is measured size of stripped or unstripped binary? Plus with or without
debug symbols? Double unlikely version should have more debug symbols
and therefore also larger size.

But if unstripped version with double unlikely is larger then it is for
sure compiler bug.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [linux-sunxi] [PATCH v2 03/11] pinctrl: sunxi: v3s: introduce support for V3

2019-06-12 Thread Paul Kocialkowski

Hi,

On Tue, 2019-06-11 at 22:09 +0800, Icenowy Zheng wrote:
> Introduce the GPIO pins that is only available on V3 (not on V3s) to the
> V3s pinctrl driver.

Looks like my comments from v1 still apply here and some of the
functions are not properly described (e.g. LCD is usually 0x2 and LVDS
0x3 while the path has both at 0x2).

Could you look into them for the next revision?

Thanks and cheers!

Paul

> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
> - Dropped the driver rename patch and apply the changes directly on V3s
>   driver.
> 
>  drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c | 265 +-
>  drivers/pinctrl/sunxi/pinctrl-sunxi.h |   2 +
>  2 files changed, 262 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c 
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
> index 6704ce8e5e3d..9e82fd38cf21 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c
> @@ -1,5 +1,5 @@
>  /*
> - * Allwinner V3s SoCs pinctrl driver.
> + * Allwinner V3/V3s SoCs pinctrl driver.
>   *
>   * Copyright (C) 2016 Icenowy Zheng 
>   *
> @@ -77,6 +77,30 @@ static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
> SUNXI_FUNCTION(0x2, "i2c1"),  /* SCK */
> SUNXI_FUNCTION(0x3, "uart0"), /* RX */
> SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),  /* PB_EINT9 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 10),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "jtag"),  /* MS */
> +   SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)), /* PB_EINT10 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 11),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "jtag"),  /* CK */
> +   SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)), /* PB_EINT11 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 12),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "jtag"),  /* DO */
> +   SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 12)), /* PB_EINT12 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(B, 13),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "jtag"),  /* DI */
> +   SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 13)), /* PB_EINT13 */
>   /* Hole */
>   SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> SUNXI_FUNCTION(0x0, "gpio_in"),
> @@ -98,6 +122,180 @@ static const struct sunxi_desc_pin sun8i_v3s_pins[] = {
> SUNXI_FUNCTION(0x1, "gpio_out"),
> SUNXI_FUNCTION(0x2, "mmc2"),  /* D0 */
> SUNXI_FUNCTION(0x3, "spi0")), /* MOSI */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 4),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "mmc2")), /* D1 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 5),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "mmc2")), /* D2 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 6),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "mmc2")), /* D3 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 7),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "mmc2")), /* D4 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 8),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "mmc2")), /* D5 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 9),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "mmc2")), /* D6 */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(C, 10),
> +   PINCTRL_SUN8I_V3,
> +   SUNXI_FUNCTION(0x0, "gpio_in"),
> +   SUNXI_FUNCTION(0x1, "gpio_out"),
> +   SUNXI_FUNCTION(0x2, "mmc2")), /* D7 */
> + /* Hole */
> + SUNXI_PIN_VARIANT(SUNXI_PINCTRL_PIN(D, 0),
> +   PINCTRL_SUN8I_V3,
> +   SUNX

[PATCH v3 2/2] dt/bindings: drm/komeda: Adds SMMU support for D71 devicetree

2019-06-12 Thread Lowry Li (Arm Technology China)

From: "Lowry Li (Arm Technology China)" 

Updates the device-tree doc about how to enable SMMU by devicetree.

Signed-off-by: Lowry Li (Arm Technology China) 
Reviewed-by: Liviu Dudau 
Reviewed-by: James Qian Wang (Arm Technology China) 
---
 Documentation/devicetree/bindings/display/arm,komeda.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/arm,komeda.txt 
b/Documentation/devicetree/bindings/display/arm,komeda.txt
index 02b2265..b12c045 100644
--- a/Documentation/devicetree/bindings/display/arm,komeda.txt
+++ b/Documentation/devicetree/bindings/display/arm,komeda.txt
@@ -11,6 +11,10 @@ Required properties:
   - "pclk": for the APB interface clock
 - #address-cells: Must be 1
 - #size-cells: Must be 0
+- iommus: configure the stream id to IOMMU, Must be configured if want to
+enable iommu in display. for how to configure this node please reference
+devicetree/bindings/iommu/arm,smmu-v3.txt,
+devicetree/bindings/iommu/iommu.txt
 
 Required properties for sub-node: pipeline@nq
 Each device contains one or two pipeline sub-nodes (at least one), each
@@ -44,6 +48,9 @@ Example:
interrupts = <0 168 4>;
clocks = <&dpu_mclk>, <&dpu_aclk>;
clock-names = "mclk", "pclk";
+   iommus = <&smmu 0>, <&smmu 1>, <&smmu 2>, <&smmu 3>,
+   <&smmu 4>, <&smmu 5>, <&smmu 6>, <&smmu 7>,
+   <&smmu 8>, <&smmu 9>;
 
dp0_pipe0: pipeline@0 {
clocks = <&fpgaosc2>, <&dpu_aclk>;
-- 
1.9.1

Re: [PATCH] futex: Fix futex lock the wrong page

2019-06-12 Thread Greg KH

On Wed, Jun 12, 2019 at 09:50:25AM +0800, zhangxiaoxu (A) wrote:
> This patch is for stable branch linux-4.4-y.
> 
> On 2019/6/12 9:54, ZhangXiaoxu wrote:
> > The upstram commit 65d8fc777f6d ("futex: Remove requirement
> > for lock_page() in get_futex_key()") use variable 'page' as
> > the page head, when merge it to stable branch, the variable
> > `page_head` is page head.
> > 
> > In the stable branch, the variable `page` not means the page
> > head, when lock the page head, we should lock 'page_head',
> > rather than 'page'.
> > 
> > It maybe lead a hung task problem.
> > 
> > Signed-off-by: ZhangXiaoxu 
> > Cc: sta...@vger.kernel.org
> > ---
> >   kernel/futex.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)

I do not understand.

Please read
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to submit a patch to the stable trees properly.

If the commit is not in Linus's tree, then we can not take it, unless
something is _very_ broken and it is the only way it can be resolved.

thanks,

greg k-h

[PATCH v3 2/4] firmware/qcom_scm: Add scm call to handle smmu errata

2019-06-12 Thread Vivek Gautam

Qcom's smmu-500 needs to toggle wait-for-safe logic to
handle TLB invalidations.
Few firmwares allow doing that through SCM interface.
Add API to toggle wait for safe from firmware through a
SCM call.

Signed-off-by: Vivek Gautam 
Reviewed-by: Bjorn Andersson 
---
 drivers/firmware/qcom_scm-32.c |  5 +
 drivers/firmware/qcom_scm-64.c | 13 +
 drivers/firmware/qcom_scm.c|  6 ++
 drivers/firmware/qcom_scm.h|  5 +
 include/linux/qcom_scm.h   |  2 ++
 5 files changed, 31 insertions(+)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 215061c581e1..bee8729525ec 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -614,3 +614,8 @@ int __qcom_scm_io_writel(struct device *dev, phys_addr_t 
addr, unsigned int val)
return qcom_scm_call_atomic2(QCOM_SCM_SVC_IO, QCOM_SCM_IO_WRITE,
 addr, val);
 }
+
+int __qcom_scm_qsmmu500_wait_safe_toggle(struct device *dev, bool enable)
+{
+   return -ENODEV;
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index b6dca32c5ac4..23de54b75cd7 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -550,3 +550,16 @@ int __qcom_scm_io_writel(struct device *dev, phys_addr_t 
addr, unsigned int val)
return qcom_scm_call(dev, QCOM_SCM_SVC_IO, QCOM_SCM_IO_WRITE,
 &desc, &res);
 }
+
+int __qcom_scm_qsmmu500_wait_safe_toggle(struct device *dev, bool en)
+{
+   struct qcom_scm_desc desc = {0};
+   struct arm_smccc_res res;
+
+   desc.args[0] = QCOM_SCM_CONFIG_SAFE_EN_CLIENT_ALL;
+   desc.args[1] = en;
+   desc.arginfo = QCOM_SCM_ARGS(2);
+
+   return qcom_scm_call_atomic(dev, QCOM_SCM_SVC_SMMU_PROGRAM,
+   QCOM_SCM_CONFIG_SAFE_EN, &desc, &res);
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 2ddc118dba1b..2b3b7a8c4270 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -344,6 +344,12 @@ int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, 
u32 spare)
 }
 EXPORT_SYMBOL(qcom_scm_iommu_secure_ptbl_init);
 
+int qcom_scm_qsmmu500_wait_safe_toggle(bool en)
+{
+   return __qcom_scm_qsmmu500_wait_safe_toggle(__scm->dev, en);
+}
+EXPORT_SYMBOL(qcom_scm_qsmmu500_wait_safe_toggle);
+
 int qcom_scm_io_readl(phys_addr_t addr, unsigned int *val)
 {
return __qcom_scm_io_readl(__scm->dev, addr, val);
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 99506bd873c0..0b63ded89b41 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -91,10 +91,15 @@ extern int __qcom_scm_restore_sec_cfg(struct device *dev, 
u32 device_id,
  u32 spare);
 #define QCOM_SCM_IOMMU_SECURE_PTBL_SIZE3
 #define QCOM_SCM_IOMMU_SECURE_PTBL_INIT4
+#define QCOM_SCM_SVC_SMMU_PROGRAM  0x15
+#define QCOM_SCM_CONFIG_SAFE_EN0x3
+#define QCOM_SCM_CONFIG_SAFE_EN_CLIENT_ALL 0x2
 extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
 size_t *size);
 extern int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr,
 u32 size, u32 spare);
+extern int __qcom_scm_qsmmu500_wait_safe_toggle(struct device *dev,
+   bool enable);
 #define QCOM_MEM_PROT_ASSIGN_ID0x16
 extern int  __qcom_scm_assign_mem(struct device *dev,
  phys_addr_t mem_region, size_t mem_sz,
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 3f12cc77fb58..aee3d8580d89 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -57,6 +57,7 @@ extern int qcom_scm_set_remote_state(u32 state, u32 id);
 extern int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare);
 extern int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size);
 extern int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare);
+extern int qcom_scm_qsmmu500_wait_safe_toggle(bool en);
 extern int qcom_scm_io_readl(phys_addr_t addr, unsigned int *val);
 extern int qcom_scm_io_writel(phys_addr_t addr, unsigned int val);
 #else
@@ -96,6 +97,7 @@ qcom_scm_set_remote_state(u32 state,u32 id) { return -ENODEV; 
}
 static inline int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare) { return 
-ENODEV; }
 static inline int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size) { 
return -ENODEV; }
 static inline int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 
spare) { return -ENODEV; }
+static inline int qcom_scm_qsmmu500_wait_safe_toggle(bool en) { return 
-ENODEV; }
 static inline int qcom_scm_io_readl(phys_addr_t addr, unsigned int *val) { 
return -ENODEV; }
 static inline int qcom_scm_io_writel(phys_addr_t addr, unsigned int val) { 
return -ENODEV; }
 #endif
-- 
QUALCOMM INDIA, on behal

[PATCH v3 0/4] Qcom smmu-500 wait-for-safe handling for sdm845

2019-06-12 Thread Vivek Gautam

Subject changed, older subject was -
Qcom smmu-500 TLB invalidation errata for sdm845.
Previous version of the patches are at [1]:

Qcom's implementation of smmu-500 on sdm845 adds a hardware logic called
wait-for-safe. This logic helps in meeting the invalidation requirements
from 'real-time clients', such as display and camera. This wait-for-safe
logic ensures that the invalidations happen after getting an ack from these
devices.
In this patch-series we are disabling this wait-for-safe logic from the
arm-smmu driver's probe as with this enabled the hardware tries to
throttle invalidations from 'non-real-time clients', such as USB and UFS.

For detailed information please refer to patch [3/4] in this series.
I have included the device tree patch too in this series for someone who
would like to test out this. Here's a branch [2] that gets display on MTP
SDM845 device.

This patch series is inspired from downstream work to handle under-performance
issues on real-time clients on sdm845. In downstream we add separate page table
ops to handle TLB maintenance and toggle wait-for-safe in tlb_sync call so that
achieve required performance for display and camera [3, 4].

Changes since v2:
* Dropped the patch to add atomic io_read/write scm API.
* Removed support for any separate page table ops to handle wait-for-safe.
Currently just disabling this wait-for-safe logic from
arm_smmu_device_probe()
to achieve performance on USB/UFS on sdm845.
* Added a device tree patch to add smmu option for fw-implemented support
for SCM call to take care of SAFE toggling.

Changes since v1:
* Addressed Will and Robin's comments:
- Dropped the patch[4] that forked out __arm_smmu_tlb_inv_range_nosync(),
and __arm_smmu_tlb_sync().
- Cleaned up the errata patch further to use downstream polling mechanism
for tlb sync.
* No change in SCM call patches - patches 1 to 3.

[1] https://lore.kernel.org/patchwork/cover/983913/
[2] https://github.com/vivekgautam1/linux/tree/v5.2-rc4/sdm845-display-working
[3]
https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/drivers/iommu/arm-smmu.c?h=CogSystems-msm-49/msm-4.9&id=da765c6c75266b38191b38ef086274943f353ea7
[4]
https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/drivers/iommu/arm-smmu.c?h=CogSystems-msm-49/msm-4.9&id=8696005aaaf745de68f57793c1a534a34345c30a

Vivek Gautam (4):
firmware: qcom_scm-64: Add atomic version of qcom_scm_call
firmware/qcom_scm: Add scm call to handle smmu errata
iommu/arm-smmu: Add support to handle Qcom's wait-for-safe logic
arm64: dts/sdm845: Enable FW implemented safe sequence handler on MTP

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

Re: [PATCH net-next] defconfigs: remove obsolete CONFIG_INET_XFRM_MODE_* and CONFIG_INET6_XFRM_MODE_*

2019-06-12 Thread Yuehaibing

Pls ignore this, will fix and resend.

On 2019/6/12 15:06, YueHaibing wrote:
> These Kconfig options has been removed in
> commit 4c145dce2601 ("xfrm: make xfrm modes builtin")
> So there is no point to keep it in defconfigs any longer.
> 
> Signed-off-by: YueHaibing 
> ---
>  arch/arc/configs/axs101_defconfig   | 3 ---
>  arch/arc/configs/axs103_defconfig   | 3 ---
>  arch/arc/configs/axs103_smp_defconfig   | 3 ---
>  arch/arc/configs/haps_hs_defconfig  | 3 ---
>  arch/arc/configs/haps_hs_smp_defconfig  | 3 ---
>  arch/arc/configs/nps_defconfig  | 3 ---
>  arch/arc/configs/nsimosci_hs_smp_defconfig  | 3 ---
>  arch/arc/configs/tb10x_defconfig| 3 ---
>  arch/arm/configs/acs5k_tiny_defconfig   | 3 ---
>  arch/arm/configs/am200epdkit_defconfig  | 3 ---
>  arch/arm/configs/aspeed_g4_defconfig| 6 --
>  arch/arm/configs/aspeed_g5_defconfig| 6 --
>  arch/arm/configs/at91_dt_defconfig  | 6 --
>  arch/arm/configs/cm_x300_defconfig  | 3 ---
>  arch/arm/configs/efm32_defconfig| 3 ---
>  arch/arm/configs/ep93xx_defconfig   | 3 ---
>  arch/arm/configs/ezx_defconfig  | 3 ---
>  arch/arm/configs/h5000_defconfig| 3 ---
>  arch/arm/configs/imote2_defconfig   | 3 ---
>  arch/arm/configs/imx_v4_v5_defconfig| 3 ---
>  arch/arm/configs/imx_v6_v7_defconfig| 3 ---
>  arch/arm/configs/iop13xx_defconfig  | 3 ---
>  arch/arm/configs/iop32x_defconfig   | 3 ---
>  arch/arm/configs/iop33x_defconfig   | 3 ---
>  arch/arm/configs/keystone_defconfig | 3 ---
>  arch/arm/configs/lpc18xx_defconfig  | 3 ---
>  arch/arm/configs/lpc32xx_defconfig  | 3 ---
>  arch/arm/configs/lpd270_defconfig   | 3 ---
>  arch/arm/configs/magician_defconfig | 3 ---
>  arch/arm/configs/mini2440_defconfig | 3 ---
>  arch/arm/configs/moxart_defconfig   | 3 ---
>  arch/arm/configs/mps2_defconfig | 3 ---
>  arch/arm/configs/mxs_defconfig  | 3 ---
>  arch/arm/configs/omap1_defconfig| 3 ---
>  arch/arm/configs/palmz72_defconfig  | 3 ---
>  arch/arm/configs/pcm027_defconfig   | 3 ---
>  arch/arm/configs/pxa3xx_defconfig   | 3 ---
>  arch/arm/configs/qcom_defconfig | 3 ---
>  arch/arm/configs/rpc_defconfig  | 6 --
>  arch/arm/configs/s3c2410_defconfig  | 1 -
>  arch/arm/configs/sama5_defconfig| 6 --
>  arch/arm/configs/sunxi_defconfig| 3 ---
>  arch/arm/configs/tango4_defconfig   | 3 ---
>  arch/arm/configs/tegra_defconfig| 2 --
>  arch/arm/configs/xcep_defconfig | 3 ---
>  arch/hexagon/configs/comet_defconfig| 3 ---
>  arch/m68k/configs/amcore_defconfig  | 3 ---
>  arch/m68k/configs/m5208evb_defconfig| 3 ---
>  arch/m68k/configs/m5249evb_defconfig| 3 ---
>  arch/m68k/configs/m5272c3_defconfig | 3 ---
>  arch/m68k/configs/m5275evb_defconfig| 3 ---
>  arch/m68k/configs/m5307c3_defconfig | 3 ---
>  arch/m68k/configs/m5407c3_defconfig | 3 ---
>  arch/mips/configs/ar7_defconfig | 3 ---
>  arch/mips/configs/ath25_defconfig   | 3 ---
>  arch/mips/configs/ath79_defconfig   | 3 ---
>  arch/mips/configs/bcm63xx_defconfig | 3 ---
>  arch/mips/configs/bigsur_defconfig  | 3 ---
>  arch/mips/configs/bmips_be_defconfig| 3 ---
>  arch/mips/configs/bmips_stb_defconfig   | 3 ---
>  arch/mips/configs/capcella_defconfig| 3 ---
>  arch/mips/configs/ci20_defconfig| 3 ---
>  arch/mips/configs/db1xxx_defconfig  | 1 -
>  arch/mips/configs/decstation_64_defconfig   | 4 
>  arch/mips/configs/decstation_defconfig  | 4 
>  arch/mips/configs/decstation_r4k_defconfig  | 4 
>  arch/mips/configs/fuloong2e_defconfig   | 2 --
>  arch/mips/configs/gpr_defconfig | 3 ---
>  arch/mips/configs/ip22_defconfig| 4 
>  arch/mips/configs/ip27_defconfig| 7 ---
>  arch/mips/configs/ip28_defconfig| 3 ---
>  arch/mips/configs/jazz_defconfig| 2 --
>  arch/mips/configs/jmr3927_defconfig | 3 ---
>  arch/mips/configs/lasat_defconfig   | 3 ---
>  arch/mips/configs/lemote2f_defconfig| 3 ---
>  arch/mips/configs/loongson1b_defconfig  | 3 ---
>  arch/mips/configs/loongson1c_defconfig  | 3 ---
>  arch/mips/configs/malta_defconfig   | 2 --
>  arch/mips/configs/malta_kvm_defconfig   | 2 --
>  arch/mips/configs/malta_kvm_guest_defconfig

Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …

2019-06-12 Thread Rolf Eike Beer

Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH:
> On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote:
> > On Thu, Jun 6, 2019 at 5:29 PM Greg KH  wrote:
> > > And if you want this, you should look at how the backports to 4.14.y
> > > worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use
> > > feature checks instead of version checks"), as that gets really messy...
> > 
> > I am confused -- I interpreted Rolf's message as reporting that he
> > already successfully built 4.9 by applying a6e60d84989f
> > ("include/linux/module.h: copy __init/__exit attrs to
> > init/cleanup_module") and manually fixing it up. But maybe I am
> > completely wrong... :-)
> 
> "manually fixing it up" means "hacked it to pieces" to me, I have no
> idea what the end result really was :)
> 
> If someone wants to send me some patches I can actually apply, that
> would be best...

Hi all,

the patch I actually used was this:

diff --git a/include/linux/module.h b/include/linux/module.h
index 8fa38d3e7538..f5bc4c046461 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -129,13 +129,13 @@ extern void cleanup_module(void);
 #define module_init(initfn)\
static inline initcall_t __maybe_unused __inittest(void)
\
{ return initfn; }  \
-   int init_module(void) __attribute__((alias(#initfn)));
+   int init_module(void) __attribute__((__copy__(initfn))) 
__attribute__((alias(#initfn)));
 
 /* This is only required if you want to be unloadable. */
 #define module_exit(exitfn)\
static inline exitcall_t __maybe_unused __exittest(void)
\
{ return exitfn; }  \
-   void cleanup_module(void) __attribute__((alias(#exitfn)));
+   void cleanup_module(void) __attribute__((__copy__(exitfn))) 
__attribute__((alias(#exitfn)));
 
 #endif
 

So the final question is: do we want 4.9.x to be buildable with gcc 9.x? If
yes then we can probably get this patches into shape.

Eike
-- 
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055

emlix - smart embedded open source

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

Re: [PATCH v3 4/8] pinctrl: qcom: sdm845: Provide ACPI support

On Tue, Jun 11, 2019 at 8:39 PM Bjorn Andersson
 wrote:

> Last time we discussed this the _only_ offender was the loop issuing a
> get_direction() on all descs towards the end of
> gpiochip_add_data_with_key()

I think that is still the only offender.

We were a bit back and forth: adding that code, removing it
and then adding it back again.

In a way it is good that we detect it so users do not crash their
kernels by asking for these GPIOs at runtime from userspace
instead.

It makes a lot of sense for us to ask for the initial direction for
all pins, as they get registered as GPIOs, which by definition
makes them available as such and we should be able to inspect
them.

"GPIOs" reserved by ACPI arguably are not GPIOs anymore
since ACPI have dedicated them to a special purpose
(no more "general purpose").

Yours,
Linus Walleij

[PATCH net-next] defconfigs: remove obsolete CONFIG_INET_XFRM_MODE_* and CONFIG_INET6_XFRM_MODE_*

2019-06-12 Thread YueHaibing

These Kconfig options has been removed in
commit 4c145dce2601 ("xfrm: make xfrm modes builtin")
So there is no point to keep it in defconfigs any longer.

Signed-off-by: YueHaibing 
---
 arch/arc/configs/axs101_defconfig   | 3 ---
 arch/arc/configs/axs103_defconfig   | 3 ---
 arch/arc/configs/axs103_smp_defconfig   | 3 ---
 arch/arc/configs/haps_hs_defconfig  | 3 ---
 arch/arc/configs/haps_hs_smp_defconfig  | 3 ---
 arch/arc/configs/nps_defconfig  | 3 ---
 arch/arc/configs/nsimosci_hs_smp_defconfig  | 3 ---
 arch/arc/configs/tb10x_defconfig| 3 ---
 arch/arm/configs/acs5k_tiny_defconfig   | 3 ---
 arch/arm/configs/am200epdkit_defconfig  | 3 ---
 arch/arm/configs/aspeed_g4_defconfig| 6 --
 arch/arm/configs/aspeed_g5_defconfig| 6 --
 arch/arm/configs/at91_dt_defconfig  | 6 --
 arch/arm/configs/cm_x300_defconfig  | 3 ---
 arch/arm/configs/efm32_defconfig| 3 ---
 arch/arm/configs/ep93xx_defconfig   | 3 ---
 arch/arm/configs/ezx_defconfig  | 3 ---
 arch/arm/configs/h5000_defconfig| 3 ---
 arch/arm/configs/imote2_defconfig   | 3 ---
 arch/arm/configs/imx_v4_v5_defconfig| 3 ---
 arch/arm/configs/imx_v6_v7_defconfig| 3 ---
 arch/arm/configs/iop13xx_defconfig  | 3 ---
 arch/arm/configs/iop32x_defconfig   | 3 ---
 arch/arm/configs/iop33x_defconfig   | 3 ---
 arch/arm/configs/keystone_defconfig | 3 ---
 arch/arm/configs/lpc18xx_defconfig  | 3 ---
 arch/arm/configs/lpc32xx_defconfig  | 3 ---
 arch/arm/configs/lpd270_defconfig   | 3 ---
 arch/arm/configs/magician_defconfig | 3 ---
 arch/arm/configs/mini2440_defconfig | 3 ---
 arch/arm/configs/moxart_defconfig   | 3 ---
 arch/arm/configs/mps2_defconfig | 3 ---
 arch/arm/configs/mxs_defconfig  | 3 ---
 arch/arm/configs/omap1_defconfig| 3 ---
 arch/arm/configs/palmz72_defconfig  | 3 ---
 arch/arm/configs/pcm027_defconfig   | 3 ---
 arch/arm/configs/pxa3xx_defconfig   | 3 ---
 arch/arm/configs/qcom_defconfig | 3 ---
 arch/arm/configs/rpc_defconfig  | 6 --
 arch/arm/configs/s3c2410_defconfig  | 1 -
 arch/arm/configs/sama5_defconfig| 6 --
 arch/arm/configs/sunxi_defconfig| 3 ---
 arch/arm/configs/tango4_defconfig   | 3 ---
 arch/arm/configs/tegra_defconfig| 2 --
 arch/arm/configs/xcep_defconfig | 3 ---
 arch/hexagon/configs/comet_defconfig| 3 ---
 arch/m68k/configs/amcore_defconfig  | 3 ---
 arch/m68k/configs/m5208evb_defconfig| 3 ---
 arch/m68k/configs/m5249evb_defconfig| 3 ---
 arch/m68k/configs/m5272c3_defconfig | 3 ---
 arch/m68k/configs/m5275evb_defconfig| 3 ---
 arch/m68k/configs/m5307c3_defconfig | 3 ---
 arch/m68k/configs/m5407c3_defconfig | 3 ---
 arch/mips/configs/ar7_defconfig | 3 ---
 arch/mips/configs/ath25_defconfig   | 3 ---
 arch/mips/configs/ath79_defconfig   | 3 ---
 arch/mips/configs/bcm63xx_defconfig | 3 ---
 arch/mips/configs/bigsur_defconfig  | 3 ---
 arch/mips/configs/bmips_be_defconfig| 3 ---
 arch/mips/configs/bmips_stb_defconfig   | 3 ---
 arch/mips/configs/capcella_defconfig| 3 ---
 arch/mips/configs/ci20_defconfig| 3 ---
 arch/mips/configs/db1xxx_defconfig  | 1 -
 arch/mips/configs/decstation_64_defconfig   | 4 
 arch/mips/configs/decstation_defconfig  | 4 
 arch/mips/configs/decstation_r4k_defconfig  | 4 
 arch/mips/configs/fuloong2e_defconfig   | 2 --
 arch/mips/configs/gpr_defconfig | 3 ---
 arch/mips/configs/ip22_defconfig| 4 
 arch/mips/configs/ip27_defconfig| 7 ---
 arch/mips/configs/ip28_defconfig| 3 ---
 arch/mips/configs/jazz_defconfig| 2 --
 arch/mips/configs/jmr3927_defconfig | 3 ---
 arch/mips/configs/lasat_defconfig   | 3 ---
 arch/mips/configs/lemote2f_defconfig| 3 ---
 arch/mips/configs/loongson1b_defconfig  | 3 ---
 arch/mips/configs/loongson1c_defconfig  | 3 ---
 arch/mips/configs/malta_defconfig   | 2 --
 arch/mips/configs/malta_kvm_defconfig   | 2 --
 arch/mips/configs/malta_kvm_guest_defconfig | 2 --
 arch/mips/configs/maltaup_xpa_defconfig | 2 --
 arch/mips/configs/markeins_defconfig| 4 
 arch/mips/configs/mpc30x_defconfig  | 3 ---
 arch/mips/configs/mtx1_defconfig| 4 
 arch/mips/

Re: [PATCH v4 4/7] i2c: core: Make i2c_acpi_get_irq available to the rest of the I2C core

2019-06-12 Thread Mika Westerberg

On Tue, Jun 11, 2019 at 01:30:58PM +0100, Charles Keepax wrote:
> In preparation for more refactoring make i2c_acpi_get_irq available
> outside i2c-core-acpi.c.
> 
> Signed-off-by: Charles Keepax 

Reviewed-by: Mika Westerberg

Re: [PATCH v4] KVM: x86: Add Intel CPUID.1F cpuid emulation support

2019-06-12 Thread kbuild test robot

Hi Like,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on kvm/linux-next]
[also build test WARNING on v5.2-rc4 next-20190611]
[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/Like-Xu/KVM-x86-Add-Intel-CPUID-1F-cpuid-emulation-support/20190606-094225
base:   https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 


sparse warnings: (new ones prefixed by >>)

>> arch/x86/kvm/cpuid.c:430:30: sparse: sparse: incompatible types in 
>> comparison expression (different signedness):
>> arch/x86/kvm/cpuid.c:430:30: sparse:unsigned int *
>> arch/x86/kvm/cpuid.c:430:30: sparse:int *

vim +430 arch/x86/kvm/cpuid.c

   318  
   319  static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 
function,
   320   u32 index, int *nent, int maxnent)
   321  {
   322  int r;
   323  unsigned f_nx = is_efer_nx() ? F(NX) : 0;
   324  #ifdef CONFIG_X86_64
   325  unsigned f_gbpages = (kvm_x86_ops->get_lpage_level() == 
PT_PDPE_LEVEL)
   326  ? F(GBPAGES) : 0;
   327  unsigned f_lm = F(LM);
   328  #else
   329  unsigned f_gbpages = 0;
   330  unsigned f_lm = 0;
   331  #endif
   332  unsigned f_rdtscp = kvm_x86_ops->rdtscp_supported() ? F(RDTSCP) 
: 0;
   333  unsigned f_invpcid = kvm_x86_ops->invpcid_supported() ? 
F(INVPCID) : 0;
   334  unsigned f_mpx = kvm_mpx_supported() ? F(MPX) : 0;
   335  unsigned f_xsaves = kvm_x86_ops->xsaves_supported() ? F(XSAVES) 
: 0;
   336  unsigned f_umip = kvm_x86_ops->umip_emulated() ? F(UMIP) : 0;
   337  unsigned f_intel_pt = kvm_x86_ops->pt_supported() ? F(INTEL_PT) 
: 0;
   338  unsigned f_la57 = 0;
   339  
   340  /* cpuid 1.edx */
   341  const u32 kvm_cpuid_1_edx_x86_features =
   342  F(FPU) | F(VME) | F(DE) | F(PSE) |
   343  F(TSC) | F(MSR) | F(PAE) | F(MCE) |
   344  F(CX8) | F(APIC) | 0 /* Reserved */ | F(SEP) |
   345  F(MTRR) | F(PGE) | F(MCA) | F(CMOV) |
   346  F(PAT) | F(PSE36) | 0 /* PSN */ | F(CLFLUSH) |
   347  0 /* Reserved, DS, ACPI */ | F(MMX) |
   348  F(FXSR) | F(XMM) | F(XMM2) | F(SELFSNOOP) |
   349  0 /* HTT, TM, Reserved, PBE */;
   350  /* cpuid 0x8001.edx */
   351  const u32 kvm_cpuid_8000_0001_edx_x86_features =
   352  F(FPU) | F(VME) | F(DE) | F(PSE) |
   353  F(TSC) | F(MSR) | F(PAE) | F(MCE) |
   354  F(CX8) | F(APIC) | 0 /* Reserved */ | F(SYSCALL) |
   355  F(MTRR) | F(PGE) | F(MCA) | F(CMOV) |
   356  F(PAT) | F(PSE36) | 0 /* Reserved */ |
   357  f_nx | 0 /* Reserved */ | F(MMXEXT) | F(MMX) |
   358  F(FXSR) | F(FXSR_OPT) | f_gbpages | f_rdtscp |
   359  0 /* Reserved */ | f_lm | F(3DNOWEXT) | F(3DNOW);
   360  /* cpuid 1.ecx */
   361  const u32 kvm_cpuid_1_ecx_x86_features =
   362  /* NOTE: MONITOR (and MWAIT) are emulated as NOP,
   363   * but *not* advertised to guests via CPUID ! */
   364  F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ |
   365  0 /* DS-CPL, VMX, SMX, EST */ |
   366  0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /* 
Reserved */ |
   367  F(FMA) | F(CX16) | 0 /* xTPR Update, PDCM */ |
   368  F(PCID) | 0 /* Reserved, DCA */ | F(XMM4_1) |
   369  F(XMM4_2) | F(X2APIC) | F(MOVBE) | F(POPCNT) |
   370  0 /* Reserved*/ | F(AES) | F(XSAVE) | 0 /* OSXSAVE */ | 
F(AVX) |
   371  F(F16C) | F(RDRAND);
   372  /* cpuid 0x8001.ecx */
   373  const u32 kvm_cpuid_8000_0001_ecx_x86_features =
   374  F(LAHF_LM) | F(CMP_LEGACY) | 0 /*SVM*/ | 0 /* 
ExtApicSpace */ |
   375  F(CR8_LEGACY) | F(ABM) | F(SSE4A) | F(MISALIGNSSE) |
   376  F(3DNOWPREFETCH) | F(OSVW) | 0 /* IBS */ | F(XOP) |
   377  0 /* SKINIT, WDT, LWP */ | F(FMA4) | F(TBM) |
   378  F(TOPOEXT) | F(PERFCTR_CORE);
   379  
   380  /* cpuid 0x8008.ebx */
   381  const u32 kvm_cpuid_8000_0008_ebx_x86_features =
   382  F(WBNOINVD) | F(AMD_IBPB) | F(AMD_IBRS) | F(AMD_SSBD) | 
F(VIRT_SSBD) |
   383  F(AMD_SSB_NO) | F(AMD_STIBP);
   384  
   385  /* cpuid 0xC001.edx */

Re: [PATCH v2 1/2] mm: soft-offline: return -EBUSY if set_hwpoison_free_buddy_page() fails

2019-06-12 Thread Naoya Horiguchi

On Tue, Jun 11, 2019 at 01:44:46PM +0530, Anshuman Khandual wrote:
> 
> 
> On 06/11/2019 06:27 AM, Naoya Horiguchi wrote:
> > On Mon, Jun 10, 2019 at 05:19:45PM -0700, Mike Kravetz wrote:
> >> On 6/10/19 1:18 AM, Naoya Horiguchi wrote:
> >>> The pass/fail of soft offline should be judged by checking whether the
> >>> raw error page was finally contained or not (i.e. the result of
> >>> set_hwpoison_free_buddy_page()), but current code do not work like that.
> >>> So this patch is suggesting to fix it.
> >>>
> >>> Signed-off-by: Naoya Horiguchi 
> >>> Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
> >>> Cc:  # v4.19+
> >>
> >> Reviewed-by: Mike Kravetz 
> > 
> > Thank you, Mike.
> > 
> >>
> >> To follow-up on Andrew's comment/question about user visible effects.  
> >> Without
> >> this fix, there are cases where madvise(MADV_SOFT_OFFLINE) may not offline 
> >> the
> >> original page and will not return an error.
> > 
> > Yes, that's right.
> 
> Then should this be included in the commit message as well ?

Right, I'll clarify the point in the description.

Thanks,
- Naoya

Re: [PATCH v3 3/8] pinctrl: msm: Add ability for drivers to supply a reserved GPIO list

On Mon, Jun 10, 2019 at 10:42 AM Lee Jones  wrote:

> When booting MSM based platforms with Device Tree or some ACPI
> implementations, it is possible to provide a list of reserved pins
> via the 'gpio-reserved-ranges' and 'gpios' properties respectively.
> However some ACPI tables are not populated with this information,
> thus it has to come from a knowledgable device driver instead.
>
> Here we provide the MSM common driver with additional support to
> parse this informtion and correctly populate the widely used
> 'valid_mask'.
>
> Signed-off-by: Lee Jones 
> Reviewed-by: Bjorn Andersson 

I have queued patches 3 and 4 in the pin control tree on an
immutable branch with Bjorn's ACKs:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
ib-qcom-acpi

I have also merge this to pinctrl's devel branch for next.

Yours,
Linus Walleij

[PATCH 2/3] iio: adc: stm32-adc: add analog switches supply control

On stm32h7 and stm32mp1, the ADC inputs are multiplexed with analog
switches which have reduced performances when their supply is below 2.7V
(vdda by default):
- vdd supply can be selected if above 2.7V by setting ANASWVDD syscfg bit
  (STM32MP1 only).
- Voltage booster can be used, to get full ADC performances by setting
  BOOSTE/EN_BOOSTER syscfg bit (increases power consumption).

Make this optional, since this is a trade-off between analog performance
and power consumption.

Note: STM32H7 syscfg has a set and clear register for "BOOSTE" control.
STM32MP1 has separate set and clear registers pair to control EN_BOOSTER
and ANASWVDD bits.

Signed-off-by: Fabrice Gasnier 
---
 drivers/iio/adc/stm32-adc-core.c | 232 ++-
 1 file changed, 230 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
index 2327ec1..9d41b16 100644
--- a/drivers/iio/adc/stm32-adc-core.c
+++ b/drivers/iio/adc/stm32-adc-core.c
@@ -14,9 +14,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -51,6 +53,20 @@
 
 #define STM32_ADC_CORE_SLEEP_DELAY_MS  2000
 
+/* SYSCFG registers */
+#define STM32H7_SYSCFG_PMCR0x04
+#define STM32MP1_SYSCFG_PMCSETR0x04
+#define STM32MP1_SYSCFG_PMCCLRR0x44
+
+/* SYSCFG bit fields */
+#define STM32H7_SYSCFG_BOOSTE_MASK BIT(8)
+#define STM32MP1_SYSCFG_ANASWVDD_MASK  BIT(9)
+
+/* SYSCFG capability flags */
+#define HAS_VBOOSTER   BIT(0)
+#define HAS_ANASWVDD   BIT(1)
+#define HAS_CLEAR_REG  BIT(2)
+
 /**
  * stm32_adc_common_regs - stm32 common registers, compatible dependent data
  * @csr:   common status register offset
@@ -58,6 +74,11 @@
  * @eoc1:  adc1 end of conversion flag in @csr
  * @eoc2:  adc2 end of conversion flag in @csr
  * @eoc3:  adc3 end of conversion flag in @csr
+ * @has_syscfg: SYSCFG capability flags
+ * @pmcr:  SYSCFG_PMCSETR/SYSCFG_PMCR register offset
+ * @pmcc:  SYSCFG_PMCCLRR clear register offset
+ * @booste_msk:SYSCFG BOOSTE / EN_BOOSTER bitmask in PMCR & PMCCLRR
+ * @anaswvdd_msk: SYSCFG ANASWVDD bitmask in PMCR & PMCCLRR
  */
 struct stm32_adc_common_regs {
u32 csr;
@@ -65,6 +86,11 @@ struct stm32_adc_common_regs {
u32 eoc1_msk;
u32 eoc2_msk;
u32 eoc3_msk;
+   unsigned int has_syscfg;
+   u32 pmcr;
+   u32 pmcc;
+   u32 booste_msk;
+   u32 anaswvdd_msk;
 };
 
 struct stm32_adc_priv;
@@ -87,20 +113,26 @@ struct stm32_adc_priv_cfg {
  * @domain:irq domain reference
  * @aclk:  clock reference for the analog circuitry
  * @bclk:  bus clock common for all ADCs, depends on part used
+ * @vdd:   vdd supply reference
+ * @vdda:  vdda supply reference
  * @vref:  regulator reference
  * @cfg:   compatible configuration data
  * @common:common data for all ADC instances
  * @ccr_bak:   backup CCR in low power mode
+ * @syscfg:reference to syscon, system control registers
  */
 struct stm32_adc_priv {
int irq[STM32_ADC_MAX_ADCS];
struct irq_domain   *domain;
struct clk  *aclk;
struct clk  *bclk;
+   struct regulator*vdd;
+   struct regulator*vdda;
struct regulator*vref;
const struct stm32_adc_priv_cfg *cfg;
struct stm32_adc_common common;
u32 ccr_bak;
+   struct regmap   *syscfg;
 };
 
 static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
@@ -284,6 +316,22 @@ static const struct stm32_adc_common_regs 
stm32h7_adc_common_regs = {
.ccr = STM32H7_ADC_CCR,
.eoc1_msk = STM32H7_EOC_MST,
.eoc2_msk = STM32H7_EOC_SLV,
+   .has_syscfg = HAS_VBOOSTER,
+   .pmcr = STM32H7_SYSCFG_PMCR,
+   .booste_msk = STM32H7_SYSCFG_BOOSTE_MASK,
+};
+
+/* STM32MP1 common registers definitions */
+static const struct stm32_adc_common_regs stm32mp1_adc_common_regs = {
+   .csr = STM32H7_ADC_CSR,
+   .ccr = STM32H7_ADC_CCR,
+   .eoc1_msk = STM32H7_EOC_MST,
+   .eoc2_msk = STM32H7_EOC_SLV,
+   .has_syscfg =  HAS_VBOOSTER | HAS_ANASWVDD | HAS_CLEAR_REG,
+   .pmcr = STM32MP1_SYSCFG_PMCSETR,
+   .pmcc = STM32MP1_SYSCFG_PMCCLRR,
+   .booste_msk = STM32H7_SYSCFG_BOOSTE_MASK,
+   .anaswvdd_msk = STM32MP1_SYSCFG_ANASWVDD_MASK,
 };
 
 /* ADC common interrupt for all instances */
@@ -388,16 +436,145 @@ static void stm32_adc_irq_remove(struct platform_device 
*pdev,
}
 }
 
+static int stm32_adc_core_switches_supply_en(struct device *dev)
+{
+   struct stm32_adc_common *common = dev_get_drvdata(dev);
+   struct stm32_adc_priv *priv = to_stm32_a

Re: [PATCH v2 2/2] mm: hugetlb: soft-offline: dissolve_free_huge_page() return zero on !PageHuge

2019-06-12 Thread Naoya Horiguchi

On Tue, Jun 11, 2019 at 10:16:03AM -0700, Mike Kravetz wrote:
> On 6/10/19 1:18 AM, Naoya Horiguchi wrote:
> > madvise(MADV_SOFT_OFFLINE) often returns -EBUSY when calling soft offline
> > for hugepages with overcommitting enabled. That was caused by the suboptimal
> > code in current soft-offline code. See the following part:
> > 
> > ret = migrate_pages(&pagelist, new_page, NULL, MPOL_MF_MOVE_ALL,
> > MIGRATE_SYNC, MR_MEMORY_FAILURE);
> > if (ret) {
> > ...
> > } else {
> > /*
> >  * We set PG_hwpoison only when the migration source hugepage
> >  * was successfully dissolved, because otherwise hwpoisoned
> >  * hugepage remains on free hugepage list, then userspace will
> >  * find it as SIGBUS by allocation failure. That's not expected
> >  * in soft-offlining.
> >  */
> > ret = dissolve_free_huge_page(page);
> > if (!ret) {
> > if (set_hwpoison_free_buddy_page(page))
> > num_poisoned_pages_inc();
> > }
> > }
> > return ret;
> > 
> > Here dissolve_free_huge_page() returns -EBUSY if the migration source page
> > was freed into buddy in migrate_pages(), but even in that case we actually
> > has a chance that set_hwpoison_free_buddy_page() succeeds. So that means
> > current code gives up offlining too early now.
> > 
> > dissolve_free_huge_page() checks that a given hugepage is suitable for
> > dissolving, where we should return success for !PageHuge() case because
> > the given hugepage is considered as already dissolved.
> > 
> > This change also affects other callers of dissolve_free_huge_page(),
> > which are cleaned up together.
> > 
> > Reported-by: Chen, Jerry T 
> > Tested-by: Chen, Jerry T 
> > Signed-off-by: Naoya Horiguchi 
> > Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
> > Cc:  # v4.19+
> > ---
> >  mm/hugetlb.c| 15 +--
> >  mm/memory-failure.c |  5 +
> >  2 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git v5.2-rc3/mm/hugetlb.c v5.2-rc3_patched/mm/hugetlb.c
> > index ac843d3..048d071 100644
> > --- v5.2-rc3/mm/hugetlb.c
> > +++ v5.2-rc3_patched/mm/hugetlb.c
> > @@ -1519,7 +1519,12 @@ int dissolve_free_huge_page(struct page *page)
> 
> Please update the function description for dissolve_free_huge_page() as
> well.  It currently says, "Returns -EBUSY if the dissolution fails because
> a give page is not a free hugepage" which is no longer true as a result of
> this change.

Thanks for pointing out, I completely missed that.

> 
> > int rc = -EBUSY;
> >  
> > spin_lock(&hugetlb_lock);
> > -   if (PageHuge(page) && !page_count(page)) {
> > +   if (!PageHuge(page)) {
> > +   rc = 0;
> > +   goto out;
> > +   }
> > +
> > +   if (!page_count(page)) {
> > struct page *head = compound_head(page);
> > struct hstate *h = page_hstate(head);
> > int nid = page_to_nid(head);
> > @@ -1564,11 +1569,9 @@ int dissolve_free_huge_pages(unsigned long 
> > start_pfn, unsigned long end_pfn)
> >  
> > for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) {
> > page = pfn_to_page(pfn);
> > -   if (PageHuge(page) && !page_count(page)) {
> > -   rc = dissolve_free_huge_page(page);
> > -   if (rc)
> > -   break;
> > -   }
> 
> We may want to consider keeping at least the PageHuge(page) check before
> calling dissolve_free_huge_page().  dissolve_free_huge_pages is called as
> part of memory offline processing.  We do not know if the memory to be 
> offlined
> contains huge pages or not.  With your changes, we are taking hugetlb_lock
> on each call to dissolve_free_huge_page just to discover that the page is
> not a huge page.
> 
> You 'could' add a PageHuge(page) check to dissolve_free_huge_page before
> taking the lock.  However, you would need to check again after taking the
> lock.

Right, I'll do this.

What was in my mind when writing this was that I actually don't like
PageHuge because it's slow (not inlined) and called anywhere in mm code,
so I like to reduce it if possible.
But I now see that dissolve_free_huge_page() are relatively rare event
rather than hugepage allocation/free, so dissolve_free_huge_page should take
burden to precheck PageHuge instead of speculatively taking hugetlb_lock
and disrupting the hot path.

Thanks,
- Naoya

[PATCH 3/3] ARM: dts: stm32: add ADC analog switches syscfg on stm32mp157c

On stm32mp157c, the ADC inputs are multiplexed with analog switches which
have reduced performances when their supply is below 2.7V (vdda by
default).
Add syscfg registers that can be used on stm32mp157c, to get full ADC
analog performances.

Signed-off-by: Fabrice Gasnier 
---
 arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi 
b/arch/arm/boot/dts/stm32mp157c.dtsi
index 2afeee6..64d71c9 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -856,6 +856,7 @@
clocks = <&rcc ADC12>, <&rcc ADC12_K>;
clock-names = "bus", "adc";
interrupt-controller;
+   st,syscfg = <&syscfg>;
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
-- 
2.7.4

[PATCH 0/3] STM32 ADC analog switches supply control

This series adds support for SYSCFG bits that control ADC analog switches
supply on STM32MP1 and STM32H7.

The ADC inputs are multiplexed with analog switches which have reduced
performances when their supply is below 2.7V. Analog switches supply
can be controlled using SYSCFG bits, to reach full ADC performance.

Fabrice Gasnier (3):
  dt-bindings: iio: adc: stm32: add analog switches supply control
  iio: adc: stm32-adc: add analog switches supply control
  ARM: dts: stm32: add ADC analog switches syscfg on stm32mp157c

 .../devicetree/bindings/iio/adc/st,stm32-adc.txt   |   6 +
 arch/arm/boot/dts/stm32mp157c.dtsi |   1 +
 drivers/iio/adc/stm32-adc-core.c   | 232 -
 3 files changed, 237 insertions(+), 2 deletions(-)

-- 
2.7.4

Re: [PATCH v2 2/2] mm: hugetlb: soft-offline: dissolve_free_huge_page() return zero on !PageHuge

2019-06-12 Thread Naoya Horiguchi

On Tue, Jun 11, 2019 at 03:20:26PM +0530, Anshuman Khandual wrote:
> 
> On 06/10/2019 01:48 PM, Naoya Horiguchi wrote:
> > madvise(MADV_SOFT_OFFLINE) often returns -EBUSY when calling soft offline
> > for hugepages with overcommitting enabled. That was caused by the suboptimal
> > code in current soft-offline code. See the following part:
> > 
> > ret = migrate_pages(&pagelist, new_page, NULL, MPOL_MF_MOVE_ALL,
> > MIGRATE_SYNC, MR_MEMORY_FAILURE);
> > if (ret) {
> > ...
> > } else {
> > /*
> >  * We set PG_hwpoison only when the migration source hugepage
> >  * was successfully dissolved, because otherwise hwpoisoned
> >  * hugepage remains on free hugepage list, then userspace will
> >  * find it as SIGBUS by allocation failure. That's not expected
> >  * in soft-offlining.
> >  */
> > ret = dissolve_free_huge_page(page);
> > if (!ret) {
> > if (set_hwpoison_free_buddy_page(page))
> > num_poisoned_pages_inc();
> > }
> > }
> > return ret;
> > 
> > Here dissolve_free_huge_page() returns -EBUSY if the migration source page
> > was freed into buddy in migrate_pages(), but even in that case we actually
> 
> Over committed source pages will be released into buddy and the normal ones
> will not be ? dissolve_free_huge_page() returns -EBUSY because PageHuge()
> return negative on already released pages ? 

The answers for both questions here are yes.

> How dissolve_free_huge_page()
> will behave differently with over committed pages. I might be missing some
> recent developments here.

This dissolve_free_huge_page() should see a (free or reused) 4kB page when
overcommitting, and should see a (free or reused) huge page for non
overcommitting case.

> 
> > has a chance that set_hwpoison_free_buddy_page() succeeds. So that means
> > current code gives up offlining too early now.
> 
> Hmm. It gives up early as the return value from dissolve_free_huge_page(EBUSY)
> gets back as the return code for soft_offline_huge_page() without attempting
> set_hwpoison_free_buddy_page() which still has a chance to succeed for freed
> normal buddy pages.

Exactly.

> 
> > 
> > dissolve_free_huge_page() checks that a given hugepage is suitable for
> > dissolving, where we should return success for !PageHuge() case because
> > the given hugepage is considered as already dissolved.
> 
> Right. It should return 0 (as a success) for freed normal buddy pages. Should
> not it then check explicitly for PageBuddy() as well ?

in new semantics, dissolve_free_huge_page() returns:

  0: successfully dissolved free hugepages or the page is already dissolved
  EBUSY: failed to dissolved free hugepages or the hugepage is in-use.

so for any types of non hugepages, the return value is 0.

Thanks,
- Naoya 

> > 
> > This change also affects other callers of dissolve_free_huge_page(),
> > which are cleaned up together.
> > 
> > Reported-by: Chen, Jerry T 
> > Tested-by: Chen, Jerry T 
> > Signed-off-by: Naoya Horiguchi 
> > Fixes: 6bc9b56433b76 ("mm: fix race on soft-offlining")
> > Cc:  # v4.19+
> > ---
> >  mm/hugetlb.c| 15 +--
> >  mm/memory-failure.c |  5 +
> >  2 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git v5.2-rc3/mm/hugetlb.c v5.2-rc3_patched/mm/hugetlb.c
> > index ac843d3..048d071 100644
> > --- v5.2-rc3/mm/hugetlb.c
> > +++ v5.2-rc3_patched/mm/hugetlb.c
> > @@ -1519,7 +1519,12 @@ int dissolve_free_huge_page(struct page *page)
> > int rc = -EBUSY;
> >  
> > spin_lock(&hugetlb_lock);
> > -   if (PageHuge(page) && !page_count(page)) {
> > +   if (!PageHuge(page)) {
> > +   rc = 0;
> > +   goto out;
> > +   }
> 
> With this early bail out it maintains the functionality when called from
> soft_offline_free_page() for normal pages. For huge page, it continues
> on the previous path.
> 
> > +
> > +   if (!page_count(page)) {
> > struct page *head = compound_head(page);
> > struct hstate *h = page_hstate(head);
> > int nid = page_to_nid(head);
> > @@ -1564,11 +1569,9 @@ int dissolve_free_huge_pages(unsigned long 
> > start_pfn, unsigned long end_pfn)
> >  
> > for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) {
> > page = pfn_to_page(pfn);
> > -   if (PageHuge(page) && !page_count(page)) {
> 
> Right. These checks are now redundant.
>

[PATCH 1/3] dt-bindings: iio: adc: stm32: add analog switches supply control

On stm32h7 and stm32mp1, the ADC inputs are multiplexed with analog
switches which have reduced performances when their supply is below 2.7V
(vdda by default).

Add documentation for optional vdda-supply & vdd-supply that can be used
to supply analog circuitry (controlled by syscfg bits).

Signed-off-by: Fabrice Gasnier 
---
 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
index 8346bcb..3af48b9 100644
--- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
@@ -46,6 +46,12 @@ Required properties:
 Optional properties:
 - A pinctrl state named "default" for each ADC channel may be defined to set
   inX ADC pins in mode of operation for analog input on external pin.
+- vdda-supply: Phandle to the vdda input voltage. It can be used to supply ADC
+  analog inputs switches on stm32h7 and stm32mp1.
+- vdd-supply: Phandle to the vdd input voltage. It can be used to supply ADC
+  analog inputs switches on stm32mp1.
+- st,syscfg: Phandle to system configuration controller. It can be used to
+  control the analog circuitry on stm32h7 and stm32mp1.
 
 Contents of a stm32 adc child node:
 ---
-- 
2.7.4

Re: [PATCH V4 3/3] ocfs2: add first lock wait time in locking_state

2019-06-12 Thread Gang He

Hello Joseph,

>>> On 6/12/2019 at  3:03 pm, in message
, Joseph Qi
 wrote:
> Hi Gang,
> 
> On 19/6/11 09:54, Gang He wrote:
>> ocfs2 file system uses locking_state file under debugfs to dump
>> each ocfs2 file system's dlm lock resources, but the users ever
>> encountered some hang(deadlock) problems in ocfs2 file system.
>> I'd like to add first lock wait time in locking_state file, which
>> can help the upper scripts detect these deadlock problems via
>> comparing the first lock wait time with the current time.
>> 
>> Signed-off-by: Gang He 
>> ---
>>  fs/ocfs2/dlmglue.c | 32 +---
>>  fs/ocfs2/ocfs2.h   |  1 +
>>  2 files changed, 30 insertions(+), 3 deletions(-)
>> 
>> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
>> index d4caa6d117c6..8ce4b76f81ee 100644
>> --- a/fs/ocfs2/dlmglue.c
>> +++ b/fs/ocfs2/dlmglue.c
>> @@ -440,6 +440,7 @@ static void ocfs2_remove_lockres_tracking(struct 
> ocfs2_lock_res *res)
>>  static void ocfs2_init_lock_stats(struct ocfs2_lock_res *res)
>>  {
>>  res->l_lock_refresh = 0;
>> +res->l_lock_wait = 0;
>>  memset(&res->l_lock_prmode, 0, sizeof(struct ocfs2_lock_stats));
>>  memset(&res->l_lock_exmode, 0, sizeof(struct ocfs2_lock_stats));
>>  }
>> @@ -483,6 +484,21 @@ static inline void ocfs2_track_lock_refresh(struct 
> ocfs2_lock_res *lockres)
>>  lockres->l_lock_refresh++;
>>  }
>>  
>> +static inline void ocfs2_track_lock_wait(struct ocfs2_lock_res *lockres)
>> +{
>> +struct ocfs2_mask_waiter *mw;
>> +
>> +if (list_empty(&lockres->l_mask_waiters)) {
>> +lockres->l_lock_wait = 0;
>> +return;
>> +}
>> +
>> +mw = list_first_entry(&lockres->l_mask_waiters,
>> +struct ocfs2_mask_waiter, mw_item);
>> +lockres->l_lock_wait =
>> +ktime_to_us(ktime_mono_to_real(mw->mw_lock_start));
> 
> I wonder why ktime_mono_to_real() here?
The new item l_lock_wait is a statistic (or debugging) related, which will be 
dumping to the user-space via debugfs file locking_state for the further 
analysis if need.
As the last comments from Wengang, the dumping is from different nodes in the 
cluster, it is better to use wall time (instead of mono or boot time) to 
display the related absolute times.
Of course, the existing delta time (use mono time) will not affected.

Thanks
Gang

> 
> Thanks,
> Joseph
> 
>> +}
>> +
>>  static inline void ocfs2_init_start_time(struct ocfs2_mask_waiter *mw)
>>  {
>>  mw->mw_lock_start = ktime_get();
>> @@ -498,6 +514,9 @@ static inline void ocfs2_update_lock_stats(struct 
> ocfs2_lock_res *res,
>>  static inline void ocfs2_track_lock_refresh(struct ocfs2_lock_res *lockres)
>>  {
>>  }
>> +static inline void ocfs2_track_lock_wait(struct ocfs2_lock_res *lockres)
>> +{
>> +}
>>  static inline void ocfs2_init_start_time(struct ocfs2_mask_waiter *mw)
>>  {
>>  }
>> @@ -891,6 +910,7 @@ static void lockres_set_flags(struct ocfs2_lock_res 
> *lockres,
>>  list_del_init(&mw->mw_item);
>>  mw->mw_status = 0;
>>  complete(&mw->mw_complete);
>> +ocfs2_track_lock_wait(lockres);
>>  }
>>  }
>>  static void lockres_or_flags(struct ocfs2_lock_res *lockres, unsigned long 
> or)
>> @@ -1402,6 +1422,7 @@ static void lockres_add_mask_waiter(struct 
> ocfs2_lock_res *lockres,
>>  list_add_tail(&mw->mw_item, &lockres->l_mask_waiters);
>>  mw->mw_mask = mask;
>>  mw->mw_goal = goal;
>> +ocfs2_track_lock_wait(lockres);
>>  }
>>  
>>  /* returns 0 if the mw that was removed was already satisfied, -EBUSY
>> @@ -1418,6 +1439,7 @@ static int __lockres_remove_mask_waiter(struct 
> ocfs2_lock_res *lockres,
>>  
>>  list_del_init(&mw->mw_item);
>>  init_completion(&mw->mw_complete);
>> +ocfs2_track_lock_wait(lockres);
>>  }
>>  
>>  return ret;
>> @@ -3098,7 +3120,7 @@ static void *ocfs2_dlm_seq_next(struct seq_file *m, 
> void *v, loff_t *pos)
>>   * New in version 3
>>   *  - Max time in lock stats is in usecs (instead of nsecs)
>>   * New in version 4
>> - *  - Add last pr/ex unlock times in usecs
>> + *  - Add last pr/ex unlock times and first lock wait time in usecs
>>   */
>>  #define OCFS2_DLM_DEBUG_STR_VERSION 4
>>  static int ocfs2_dlm_seq_show(struct seq_file *m, void *v)
>> @@ -3116,7 +3138,7 @@ static int ocfs2_dlm_seq_show(struct seq_file *m, void 
> *v)
>>  return -EINVAL;
>>  
>>  #ifdef CONFIG_OCFS2_FS_STATS
>> -if (dlm_debug->d_filter_secs) {
>> +if (!lockres->l_lock_wait && dlm_debug->d_filter_secs) {
>>  now = ktime_to_us(ktime_get_real());
>>  if (lockres->l_lock_prmode.ls_last >
>>  lockres->l_lock_exmode.ls_last)
>> @@ -3177,6 +3199,7 @@ static int ocfs2_dlm_seq_show(struct seq_file *m, void 
> *v)
>>  # define lock_refresh(_l)   ((_l)->l_lock_refresh)
>>  # define lock_last_prmode(_l)   ((_l)->l_lock_prmode.ls_last)
>>  # define lock_last_

Re: [PATCH 1/2 RESEND] perf/x86/amd/uncore: Do not set ThreadMask and SliceMask for non-L3 PMCs

2019-06-12 Thread Peter Zijlstra




Your emails are base64 encoded and my scripts don't like that.

Re: [PATCH] futex: Fix futex lock the wrong page

2019-06-12 Thread Thomas Gleixner

On Wed, 12 Jun 2019, Greg KH wrote:
> On Wed, Jun 12, 2019 at 09:50:25AM +0800, zhangxiaoxu (A) wrote:
> > This patch is for stable branch linux-4.4-y.
> > 
> > On 2019/6/12 9:54, ZhangXiaoxu wrote:
> > > The upstram commit 65d8fc777f6d ("futex: Remove requirement
> > > for lock_page() in get_futex_key()") use variable 'page' as
> > > the page head, when merge it to stable branch, the variable
> > > `page_head` is page head.
> > > 
> > > In the stable branch, the variable `page` not means the page
> > > head, when lock the page head, we should lock 'page_head',
> > > rather than 'page'.
> > > 
> > > It maybe lead a hung task problem.
> > > 
> > > Signed-off-by: ZhangXiaoxu 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >   kernel/futex.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> I do not understand.
> 
> Please read
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to submit a patch to the stable trees properly.
> 
> If the commit is not in Linus's tree, then we can not take it, unless
> something is _very_ broken and it is the only way it can be resolved.

There is something _very_ broken. Upstream is correct but the 4.4. backport
of the above commit is broken (93dcb09e29bb24a86aa7b7eff65e424f7dc98af2) in
the way Zhang described. So it's a 4.4. only issue.

Thanks,

tglx

Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ

2019-06-12 Thread Marc Zyngier

On Wed, 12 Jun 2019 08:14:16 +0100,
Thomas Gleixner  wrote:
> On Mon, 10 Jun 2019, Leonard Crestez wrote:
> > On 6/10/2019 5:08 PM, Marc Zyngier wrote:
> > > Nobody is talking about performance here. It is strictly about
> > > correctness, and what I read about this system is that it cannot
> > > reliably use cpuidle.
> > My argument was that it's fine if PPIs and LPIs are broken as long as 
> > they're not used:
> > 
> >   * PPIs are only used for local timer which is not used for wakeup.
> 
> Huch? The timer has to bring the CPU out of idle as any other
> interrupt.

They use a separate hack for that, pretending that the timer is
stopped during idle (it isn't), and setup a broadcast timer when
entering idle. That timer uses an interrupt that can wake-up the
target CPU, and all is well in the world. Sort of.

Of course, this breaks as PPIs are not only used by the timer, but
also by a number of other HW bits (PMU, GIC, guest and hypervisor
timers), and they don't have corresponding hacks to back them up.

Thanks,

M.

-- 
Jazz is not dead, it just smells funny.

Open syzbot reports by kernel subsystem

2019-06-12 Thread Eric Biggers

To make some sense of the huge number of open syzbot reports against the kernel
(https://syzkaller.appspot.com/upstream), I assigned a tentative kernel
subsystem(s) to most reports.  I also wrote a script that assigns the reports
priorities based on some heuristics -- e.g. how recently it occurred, type of
reproducer, whether it happened in mainline, keywords in crash signature.

I personally find this really useful for my own use already.  But in case it's
useful for other people too, I've listed all open bug reports below in order
from highest to lowest heuristic priority within each subsystem.

Ideally this sort of thing would be natively supported by syzbot itself, so
people don't have to dig through 500 bugs to find the ones in "their" subsystem,
or to find the ones to focus on fixing first.

I think that some kernel maintainers would also find reminders by subsystem
really helpful.  For now I might send some out manually myself...

Just some ideas...

Subsystem(s) ReproLast seen  MainlineTitle
--

android/ashmem   C49 days agoyes WARNING in 
__vm_enough_memory

android/binder   syz  10 days agoyes WARNING in 
binder_transaction_buffer_release

blockC10 days agoyes KASAN: use-after-free 
Read in debugfs_remove (3)
blockC1 days ago yes WARNING in 
blk_mq_sched_free_requests
blockC1 days ago yes WARNING in 
generic_make_request_checks
blockC4 days ago yes WARNING in md_ioctl
block 1 days ago yes KASAN: use-after-free 
Read in relay_switch_subbuf
blockC188 days ago   yes KMSAN: kernel-infoleak 
in copy_page_to_iter (2)
block 96 days agoyes KASAN: use-after-free 
Read in disk_map_sector_rcu
block 58 days agoyes general protection 
fault in debugfs_remove
block 47 days agoyes general protection 
fault in relay_close_buf
block 138 days ago   yes general protection 
fault in relay_switch_subbuf

bluetoothC2 days ago yes KASAN: use-after-free 
Read in kfree_skb (3)
bluetoothC1 days ago yes WARNING: refcount bug 
in kobject_get
bluetoothC2 days ago yes general protection 
fault in skb_put
bluetoothC1 days ago yes BUG: 
MAX_LOCKDEP_CHAIN_HLOCKS too low!
bluetoothC1 days ago yes WARNING in 
tty_set_termios
bluetoothC5 days ago yes general protection 
fault in kernfs_add_one
bluetoothC1 days ago yes WARNING in kernfs_get
bluetoothC10 days agoyes memory leak in 
get_device_parent
bluetoothC18 days agoyes memory leak in 
bcsp_recv
bluetoothC158 days ago   yes KASAN: use-after-free 
Write in hci_sock_release
bluetoothC41 days agoyes KASAN: 
slab-out-of-bounds Read in bacpy
bluetoothC34 days agoyes WARNING: ODEBUG bug in 
rfcomm_dlc_free
bluetoothC82 days agoyes BUG: unable to handle 
kernel NULL pointer dereference in hci_uart_set_flow_control
bluetoothC45 days agoyes KMSAN: uninit-value in 
hci_event_packet
bluetooth 4 days ago yes KASAN: use-after-free 
Read in rfcomm_dlc_exists
bluetoothC120 days ago   yes general protection 
fault in qca_setup
bluetoothC155 days ago   yes KASAN: 
slab-out-of-bounds Read in hci_event_packet
bluetooth 39 days agoyes KASAN: use-after-free 
Read in hci_cmd_timeout
bluetooth 22 days agoKASAN: use-after-free 
Read in rfcomm_dlc_open (2)
bluetooth 175 days ago   yes KASAN: use-after-free 
Read in kernfs_put
bluetooth 40 days agogeneral protection 
fault in rfcomm_dlc_open
bluetooth 40 days agogeneral protection 
fault in rfcomm_dlc_exists
bluetooth 57 days agoyes WARNING in 
kernfs_activate
bluetooth 54 days agoyes INFO: trying to 
register non-static key in hci_uart_send_frame
bluetooth 86 days agoyes WARNING in 
lockdep_register_key
bluetooth 115 days ago   yes WARNING: ODEBUG bug in 
hci_uart_tty_close
bluetooth 119 days ago   ge

Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ

2019-06-12 Thread Thomas Gleixner

On Wed, 12 Jun 2019, Marc Zyngier wrote:
> On Wed, 12 Jun 2019 08:14:16 +0100,
> Thomas Gleixner  wrote:
> > On Mon, 10 Jun 2019, Leonard Crestez wrote:
> > > On 6/10/2019 5:08 PM, Marc Zyngier wrote:
> > > > Nobody is talking about performance here. It is strictly about
> > > > correctness, and what I read about this system is that it cannot
> > > > reliably use cpuidle.
> > > My argument was that it's fine if PPIs and LPIs are broken as long as 
> > > they're not used:
> > > 
> > >   * PPIs are only used for local timer which is not used for wakeup.
> > 
> > Huch? The timer has to bring the CPU out of idle as any other
> > interrupt.
> 
> They use a separate hack for that, pretending that the timer is
> stopped during idle (it isn't), and setup a broadcast timer when
> entering idle. That timer uses an interrupt that can wake-up the
> target CPU, and all is well in the world. Sort of.
> 
> Of course, this breaks as PPIs are not only used by the timer, but
> also by a number of other HW bits (PMU, GIC, guest and hypervisor
> timers), and they don't have corresponding hacks to back them up.

Eew.

Re: [PATCH 1/2] staging: kpc2000: improve label names in kp2000_pcie_probe

2019-06-12 Thread Dan Carpenter

Thanks!

Reviewed-by: Dan Carpenter 

Not related to your patch (IOW ignore if you want to) the error handling
is slightly more complicated than required:

drivers/staging/kpc2000/kpc2000/core.c
   356   * Step 4: Setup the Register BAR
   357   */
   358  reg_bar_phys_addr = pci_resource_start(pcard->pdev, REG_BAR);
   359  reg_bar_phys_len = pci_resource_len(pcard->pdev, REG_BAR);
   360  
   361  pcard->regs_bar_base = ioremap_nocache(reg_bar_phys_addr, 
PAGE_SIZE);
   362  if (!pcard->regs_bar_base) {
   363  dev_err(&pcard->pdev->dev,
   364  "probe: REG_BAR could not remap memory to 
virtual space\n");
   365  err = -ENODEV;
   366  goto err_disable_device;
   367  }
   368  dev_dbg(&pcard->pdev->dev,
   369  "probe: REG_BAR virt hardware address start [%p]\n",
   370  pcard->regs_bar_base);
   371  
   372  err = pci_request_region(pcard->pdev, REG_BAR, 
KP_DRIVER_NAME_KP2000);
   373  if (err) {
   374  iounmap(pcard->regs_bar_base);

We could move this to the bottom of the function.  We would need to
re-order it slightly to free things in the mirror of how they are
allocated.  (Always just free the most recent allocation).

   375  dev_err(&pcard->pdev->dev,
   376  "probe: failed to acquire PCI region (%d)\n",
   377  err);
   378  err = -ENODEV;
   379  goto err_disable_device;
   380  }
   381  
   382  pcard->regs_base_resource.start = reg_bar_phys_addr;
   383  pcard->regs_base_resource.end   = reg_bar_phys_addr +
   384reg_bar_phys_len - 1;
   385  pcard->regs_base_resource.flags = IORESOURCE_MEM;
   386  
   387  /*
   388   * Step 5: Setup the DMA BAR
   389   */
   390  dma_bar_phys_addr = pci_resource_start(pcard->pdev, DMA_BAR);
   391  dma_bar_phys_len = pci_resource_len(pcard->pdev, DMA_BAR);
   392  
   393  pcard->dma_bar_base = ioremap_nocache(dma_bar_phys_addr,
   394dma_bar_phys_len);
   395  if (!pcard->dma_bar_base) {
   396  dev_err(&pcard->pdev->dev,
   397  "probe: DMA_BAR could not remap memory to 
virtual space\n");
   398  err = -ENODEV;
   399  goto err_unmap_regs;
   400  }
   401  dev_dbg(&pcard->pdev->dev,
   402  "probe: DMA_BAR virt hardware address start [%p]\n",
   403  pcard->dma_bar_base);
   404  
   405  pcard->dma_common_regs = pcard->dma_bar_base + 
KPC_DMA_COMMON_OFFSET;
   406  
   407  err = pci_request_region(pcard->pdev, DMA_BAR, "kp2000_pcie");
   408  if (err) {
   409  iounmap(pcard->dma_bar_base);

Same.

   410  dev_err(&pcard->pdev->dev,
   411  "probe: failed to acquire PCI region (%d)\n", 
err);
   412  err = -ENODEV;
   413  goto err_unmap_regs;
   414  }
   415  
   416  pcard->dma_base_resource.start = dma_bar_phys_addr;

[ snip ]

   509  dev_dbg(&pcard->pdev->dev, "%s() complete!\n", __func__);
   510  mutex_unlock(&pcard->sem);
   511  return 0;
   512  
   513  err_remove_sysfs:
   514  sysfs_remove_files(&pdev->dev.kobj, kp_attr_list);
   515  err_free_irq:
   516  free_irq(pcard->pdev->irq, pcard);
   517  err_disable_msi:
   518  pci_disable_msi(pcard->pdev);
   519  err_unmap_dma:
   520  iounmap(pcard->dma_bar_base);
   521  pci_release_region(pdev, DMA_BAR);
   522  pcard->dma_bar_base = NULL;
   523  err_unmap_regs:
   524  iounmap(pcard->regs_bar_base);
   525  pci_release_region(pdev, REG_BAR);
   526  pcard->regs_bar_base = NULL;

err_release_dma:
pci_release_region(pdev, DMA_BAR);
err_unmap_dma:
iounmap(pcard->dma_bar_base);
err_release_reg:
pci_release_region(pdev, REG_BAR);
err_unmap_reg:
iounmap(pcard->regs_bar_base);

I moved swapped the pci_release_region() and the iounmap() order.  There
is no need to set "pcard->regs_bar_base = NULL;" so just remove that.

   527  err_disable_device:
   528  pci_disable_device(pcard->pdev);
   529  err_remove_ida:
   530  mutex_unlock(&pcard->sem);
   531  ida_simple_remove(&card_num_ida, pcard->card_num);
   532  err_free_pcard:
   533  kfree(pcard);
   534  return err;
   535  }

regards,
dan carpenter

Re: [PATCH 2/2] staging: kpc2000: remove unnecessary comments in kp2000_pcie_probe

2019-06-12 Thread Dan Carpenter

On Mon, Jun 10, 2019 at 10:05:35PM +0200, Simon Sandström wrote:
> @@ -349,9 +340,7 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
>   goto err_remove_ida;
>   }
>  
> - /*
> -  * Step 4: Setup the Register BAR
> -  */
> + // Setup the Register BAR

Greg, are we moving the C++ style comments?  Linus is fine with them.  I
don't like them but whatever...

>   reg_bar_phys_addr = pci_resource_start(pcard->pdev, REG_BAR);
>   reg_bar_phys_len = pci_resource_len(pcard->pdev, REG_BAR);
>  

regards,
dan carpenter

[PATCH v2] regulator: wm831x: Convert to use GPIO descriptors

This converts the Wolfson Micro WM831x DCDC converter to use
a GPIO descriptor for the GPIO driving the DVS pin.

There is just one (non-DT) machine in the kernel using this, and
that is the Wolfson Micro (now Cirrus) Cragganmore 6410 so we
patch this board to pass a descriptor table and fix up the driver
accordingly.

Cc: Charles Keepax 
Cc: Richard Fitzgerald 
Cc: patc...@opensource.cirrus.com
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Use device name "wm831x-buckv.11" as described by Charles
- Use devm_gpiod_get() rather than the optional variant
---
 arch/arm/mach-s3c64xx/mach-crag6410.c | 21 ++-
 drivers/regulator/wm831x-dcdc.c   | 29 ---
 include/linux/mfd/wm831x/pdata.h  |  1 -
 3 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c 
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 379424d72ae7..8ec6a4f5eb05 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -398,7 +399,6 @@ static struct pca953x_platform_data crag6410_pca_data = {
 /* VDDARM is controlled by DVS1 connected to GPK(0) */
 static struct wm831x_buckv_pdata vddarm_pdata = {
.dvs_control_src = 1,
-   .dvs_gpio = S3C64XX_GPK(0),
 };
 
 static struct regulator_consumer_supply vddarm_consumers[] = {
@@ -596,6 +596,24 @@ static struct wm831x_pdata crag_pmic_pdata = {
.touch = &touch_pdata,
 };
 
+/*
+ * VDDARM is eventually ending up as a regulator hanging on the MFD cell device
+ * "wm831x-buckv.1" spawn from drivers/mfd/wm831x-core.c.
+ *
+ * From the note on the platform data we can see that this is clearly DVS1
+ * and assigned as dcdc1 resource to the MFD core which sets .id of the cell
+ * spawning the DVS1 platform device to 1, then the cell platform device
+ * name is calculated from 10*instance + id resulting in the device name
+ * "wm831x-buckv.11"
+ */
+static struct gpiod_lookup_table crag_pmic_gpiod_table = {
+   .dev_id = "wm831x-buckv.11",
+   .table = {
+   GPIO_LOOKUP("GPIOK", 0, "dvs", GPIO_ACTIVE_HIGH),
+   { },
+   },
+};
+
 static struct i2c_board_info i2c_devs0[] = {
{ I2C_BOARD_INFO("24c08", 0x50), },
{ I2C_BOARD_INFO("tca6408", 0x20),
@@ -836,6 +854,7 @@ static void __init crag6410_machine_init(void)
s3c_fb_set_platdata(&crag6410_lcd_pdata);
dwc2_hsotg_set_platdata(&crag6410_hsotg_pdata);
 
+   gpiod_add_lookup_table(&crag_pmic_gpiod_table);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
 
diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c
index b422eef97b77..018dbbd96771 100644
--- a/drivers/regulator/wm831x-dcdc.c
+++ b/drivers/regulator/wm831x-dcdc.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -50,7 +50,7 @@ struct wm831x_dcdc {
int base;
struct wm831x *wm831x;
struct regulator_dev *regulator;
-   int dvs_gpio;
+   struct gpio_desc *dvs_gpiod;
int dvs_gpio_state;
int on_vsel;
int dvs_vsel;
@@ -217,7 +217,7 @@ static int wm831x_buckv_set_dvs(struct regulator_dev *rdev, 
int state)
return 0;
 
dcdc->dvs_gpio_state = state;
-   gpio_set_value(dcdc->dvs_gpio, state);
+   gpiod_set_value(dcdc->dvs_gpiod, state);
 
/* Should wait for DVS state change to be asserted if we have
 * a GPIO for it, for now assume the device is configured
@@ -237,10 +237,10 @@ static int wm831x_buckv_set_voltage_sel(struct 
regulator_dev *rdev,
int ret;
 
/* If this value is already set then do a GPIO update if we can */
-   if (dcdc->dvs_gpio && dcdc->on_vsel == vsel)
+   if (dcdc->dvs_gpiod && dcdc->on_vsel == vsel)
return wm831x_buckv_set_dvs(rdev, 0);
 
-   if (dcdc->dvs_gpio && dcdc->dvs_vsel == vsel)
+   if (dcdc->dvs_gpiod && dcdc->dvs_vsel == vsel)
return wm831x_buckv_set_dvs(rdev, 1);
 
/* Always set the ON status to the minimum voltage */
@@ -249,7 +249,7 @@ static int wm831x_buckv_set_voltage_sel(struct 
regulator_dev *rdev,
return ret;
dcdc->on_vsel = vsel;
 
-   if (!dcdc->dvs_gpio)
+   if (!dcdc->dvs_gpiod)
return ret;
 
/* Kick the voltage transition now */
@@ -296,7 +296,7 @@ static int wm831x_buckv_get_voltage_sel(struct 
regulator_dev *rdev)
 {
struct wm831x_dcdc *dcdc = rdev_get_drvdata(rdev);
 
-   if (dcdc->dvs_gpio && dcdc->dvs_gpio_state)
+   if (dcdc->dvs_gpiod && dcdc->dvs_gpio_state)
return dcdc->dvs_vsel;
else
return dcdc->on_vsel;
@@ -337,7 +337,7 @@ static void wm831x_buckv_dvs_init(struct platform_device 
*pdev,
int re

Re: [PATCH v4] page cache: Store only head pages in i_pages

2019-06-12 Thread Chris Wilson

Quoting Kirill A. Shutemov (2019-06-12 02:46:34)
> On Sun, Jun 02, 2019 at 10:47:35PM +0100, Chris Wilson wrote:
> > Quoting Matthew Wilcox (2019-03-07 15:30:51)
> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > index 404acdcd0455..aaf88f85d492 100644
> > > --- a/mm/huge_memory.c
> > > +++ b/mm/huge_memory.c
> > > @@ -2456,6 +2456,9 @@ static void __split_huge_page(struct page *page, 
> > > struct list_head *list,
> > > if (IS_ENABLED(CONFIG_SHMEM) && 
> > > PageSwapBacked(head))
> > > shmem_uncharge(head->mapping->host, 1);
> > > put_page(head + i);
> > > +   } else if (!PageAnon(page)) {
> > > +   __xa_store(&head->mapping->i_pages, head[i].index,
> > > +   head + i, 0);
> > 
> > Forgiving the ignorant copy'n'paste, this is required:
> > 
> > +   } else if (PageSwapCache(page)) {
> > +   swp_entry_t entry = { .val = page_private(head + i) 
> > };
> > +   __xa_store(&swap_address_space(entry)->i_pages,
> > +  swp_offset(entry),
> > +  head + i, 0);
> > }
> > }
> >  
> > The locking is definitely wrong.
> 
> Does it help with the problem, or it's just a possible lead?

It definitely solves the problem we encountered of the bad VM_PAGE
leading to RCU stalls in khugepaged. The locking is definitely wrong
though :)
-Chris

Re: [PATCH v2 3/7] drm/bridge: extract some Analogix I2C DP common code

2019-06-12 Thread Andrzej Hajda

On 04.06.2019 14:22, Torsten Duwe wrote:
> From: Icenowy Zheng 
>
> Some code can be shared within different DP bridges by Analogix.
> Extract them to analogix_dp.
>
> Signed-off-by: Icenowy Zheng 
> Signed-off-by: Vasily Khoruzhick 
> Signed-off-by: Torsten Duwe 
> ---
>  drivers/gpu/drm/bridge/analogix/Makefile   |   2 +-
>  drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +
>  .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c| 173 
> +
>  .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h|   3 +
>  4 files changed, 178 insertions(+), 146 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 6fcbfd3ee560..7623b9b80167 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,4 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> -analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> +analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
>  obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index c09aaf93ae1b..f36ae51c641d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> @@ -45,8 +45,6 @@
>  #define I2C_IDX_RX_P14
>  
>  #define XTAL_CLK 270 /* 27M */
> -#define AUX_CH_BUFFER_SIZE   16
> -#define AUX_WAIT_TIMEOUT_MS  15
>  
>  static const u8 anx78xx_i2c_addresses[] = {
>   [I2C_IDX_TX_P0] = TX_P0,
> @@ -109,153 +107,11 @@ static int anx78xx_clear_bits(struct regmap *map, u8 
> reg, u8 mask)
>   return regmap_update_bits(map, reg, mask, 0);
>  }
>  
> -static bool anx78xx_aux_op_finished(struct anx78xx *anx78xx)
> -{
> - unsigned int value;
> - int err;
> -
> - err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_DP_AUX_CH_CTRL2_REG,
> -   &value);
> - if (err < 0)
> - return false;
> -
> - return (value & SP_AUX_EN) == 0;
> -}
> -
> -static int anx78xx_aux_wait(struct anx78xx *anx78xx)
> -{
> - unsigned long timeout;
> - unsigned int status;
> - int err;
> -
> - timeout = jiffies + msecs_to_jiffies(AUX_WAIT_TIMEOUT_MS) + 1;
> -
> - while (!anx78xx_aux_op_finished(anx78xx)) {
> - if (time_after(jiffies, timeout)) {
> - if (!anx78xx_aux_op_finished(anx78xx)) {
> - DRM_ERROR("Timed out waiting AUX to finish\n");
> - return -ETIMEDOUT;
> - }
> -
> - break;
> - }
> -
> - usleep_range(1000, 2000);
> - }
> -
> - /* Read the AUX channel access status */
> - err = regmap_read(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_CH_STATUS_REG,
> -   &status);
> - if (err < 0) {
> - DRM_ERROR("Failed to read from AUX channel: %d\n", err);
> - return err;
> - }
> -
> - if (status & SP_AUX_STATUS) {
> - DRM_ERROR("Failed to wait for AUX channel (status: %02x)\n",
> -   status);
> - return -ETIMEDOUT;
> - }
> -
> - return 0;
> -}
> -
> -static int anx78xx_aux_address(struct anx78xx *anx78xx, unsigned int addr)
> -{
> - int err;
> -
> - err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_7_0_REG,
> -addr & 0xff);
> - if (err)
> - return err;
> -
> - err = regmap_write(anx78xx->map[I2C_IDX_TX_P0], SP_AUX_ADDR_15_8_REG,
> -(addr & 0xff00) >> 8);
> - if (err)
> - return err;
> -
> - /*
> -  * DP AUX CH Address Register #2, only update bits[3:0]
> -  * [7:4] RESERVED
> -  * [3:0] AUX_ADDR[19:16], Register control AUX CH address.
> -  */
> - err = regmap_update_bits(anx78xx->map[I2C_IDX_TX_P0],
> -  SP_AUX_ADDR_19_16_REG,
> -  SP_AUX_ADDR_19_16_MASK,
> -  (addr & 0xf) >> 16);
> -
> - if (err)
> - return err;
> -
> - return 0;
> -}
> -
>  static ssize_t anx78xx_aux_transfer(struct drm_dp_aux *aux,
>   struct drm_dp_aux_msg *msg)
>  {
>   struct anx78xx *anx78xx = container_of(aux, struct anx78xx, aux);
> - u8 ctrl1 = msg->request;
> - u8 ctrl2 = SP_AUX_EN;
> - u8 *buffer = msg->buffer;
> - int err;
> -
> - /* The DP AUX transmit and receive buffer has 16 bytes. */
> - if (WARN_ON(msg->size > AUX_CH_BUFFER_SIZE))
> - return -E2BIG;
> -
> - /* Zero-sized messages specify address-only transactions. */
> - if (msg->size < 1)
> -

Re: [PATCH] media: ttpci: Fix build error without RC_CORE

2019-06-12 Thread Sean Young

On Wed, Jun 12, 2019 at 11:43:10AM +0800, YueHaibing wrote:
> If RC_CORE is not set, building fails:
> 
> drivers/media/pci/ttpci/av7110_ir.o: In function `av7110_ir_init':
> av7110_ir.c:(.text+0x1b0): undefined reference to `rc_allocate_device'
> av7110_ir.c:(.text+0x2c1): undefined reference to `rc_register_device'
> av7110_ir.c:(.text+0x2dc): undefined reference to `rc_free_device'
> 
> Reported-by: Hulk Robot 
> Fixes: 71f49a8bf5c5 ("media: ttpci: use rc-core for the IR receiver")
> Signed-off-by: YueHaibing 

Thank you for spotting this and writing a patch.

> ---
>  drivers/media/pci/ttpci/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/pci/ttpci/Kconfig b/drivers/media/pci/ttpci/Kconfig
> index d96d4fa..b705631 100644
> --- a/drivers/media/pci/ttpci/Kconfig
> +++ b/drivers/media/pci/ttpci/Kconfig
> @@ -7,7 +7,7 @@ config DVB_AV7110
>   depends on DVB_CORE && PCI && I2C
>   select TTPCI_EEPROM
>   select VIDEO_SAA7146_VV
> - select DVB_AV7110_IR if INPUT_EVDEV=y || INPUT_EVDEV=DVB_AV7110

This says if
 - select DVB_AV7110_IR if INPUT_EVDEV and DVB_AV7110 are both y or m
 - select DVB_AV7110_IR if INPUT_EVDEV=y
   This exists for the case when INPUT_EVDEV=y and DVB_AV7110=m, which is fine

> + select DVB_AV7110_IR if RC_CORE=DVB_AV7110 && (INPUT_EVDEV=y || 
> INPUT_EVDEV=DVB_AV7110)

That's not exactly the same. For one thing it should not longer depend on
INPUT_EVDEV=y.

Now if DVB_AV7110=m and RC_CORE=y is not allowed which should be (this is
the case in Fedora default kernel config for example).

>   depends on VIDEO_DEV# dependencies of VIDEO_SAA7146_VV
>   select DVB_VES1820 if MEDIA_SUBDRV_AUTOSELECT
>   select DVB_VES1X93 if MEDIA_SUBDRV_AUTOSELECT
> -- 
> 2.7.4
> 

Thanks,

Sean

Re: [RFC v2 01/11] OPP: Don't overwrite rounded clk rate

2019-06-12 Thread Rajendra Nayak




On 6/11/2019 4:24 PM, Viresh Kumar wrote:

On 20-03-19, 15:19, Rajendra Nayak wrote:

From: Stephen Boyd 

Doing this allows us to call this API with any rate requested and have
it not need to match in the OPP table. Instead, we'll round the rate up
to the nearest OPP that we see so that we can get the voltage or level
that's required for that OPP. This supports users of OPP that want to
specify the 'fmax' tables of a device instead of every single frequency
that they need. And for devices that required the exact frequency, we
can rely on the clk framework to round the rate to the nearest supported
frequency instead of the OPP framework to do so.

Note that this may affect drivers that don't want the clk framework to
do rounding, but instead want the OPP table to do the rounding for them.
Do we have that case? Should we add some flag to the OPP table to
indicate this and then not have that flag set when there isn't an OPP
table for the device and also introduce a property like 'opp-use-clk' to
tell the table that it should use the clk APIs to round rates instead of
OPP?

Signed-off-by: Stephen Boyd 
Signed-off-by: Rajendra Nayak 
---


[]...



I see a logical problem with this patch.

Suppose the clock driver supports following frequencies: 500M, 800M,
1G, 1.2G and the OPP table contains following list: 500M, 1G, 1.2G
(i.e. missing 800M).

Now 800M should never get programmed as it isn't part of the OPP
table. But if you pass 600M to opp-set-rate, then it will end up
selecting 800M as clock driver will round up to the closest value.


correct



Even if no one is doing this right now, it is a sensible usecase,
specially during testing of patches and I don't think we should avoid
it.

What exactly is the use case for which we need this patch ? 

Like the changelog says 'This supports users of OPP that want to
specify the 'fmax' tables of a device instead of every single frequency
that they need'

so the 'fmax' tables basically say what the max frequency the device can
operate at for a given performance state/voltage level.

so in your example it would be for instance

500M, Perf state = 2
1G, Perf state = 3
1.2G, Perf state = 4

Now when the device wants to operate at say 800Mhz, you need to set the
Perf state to 3, so this patch basically avoids you having to put those 
additional
OPPs in the table which would otherwise look something like this

500M, Perf state = 2
800M, Perf state = 3 <-- redundant OPP
1G, Perf state = 3
1.2G, Perf state = 4

Your example had just 1 missing entry in the 'fmax' tables in reality its a lot 
more,
atleast on all qualcomm platforms.


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

Re: [PATCH 06/20] clk: renesas: r8a77965: Add CMM clocks

2019-06-12 Thread Geert Uytterhoeven

On Thu, Jun 6, 2019 at 4:22 PM Jacopo Mondi  wrote:
> Add clock definitions for CMM units on Renesas R-Car Gen3 M3-N.
>
> Signed-off-by: Jacopo Mondi 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in clk-renesas-for-v5.3.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2 4/7] perf diff: Use hists to manage basic blocks per symbol

2019-06-12 Thread Jiri Olsa

On Wed, Jun 12, 2019 at 02:11:44PM +0800, Jin, Yao wrote:
> 
> 
> On 6/11/2019 4:56 PM, Jiri Olsa wrote:
> > On Sat, Jun 08, 2019 at 07:41:47PM +0800, Jin, Yao wrote:
> > > 
> > > 
> > > On 6/5/2019 7:44 PM, Jiri Olsa wrote:
> > > > On Mon, Jun 03, 2019 at 10:36:14PM +0800, Jin Yao wrote:
> > > > 
> > > > SNIP
> > > > 
> > > > > diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
> > > > > index 43623fa..d1641da 100644
> > > > > --- a/tools/perf/util/sort.h
> > > > > +++ b/tools/perf/util/sort.h
> > > > > @@ -79,6 +79,9 @@ struct hist_entry_diff {
> > > > >   /* HISTC_WEIGHTED_DIFF */
> > > > >   s64 wdiff;
> > > > > +
> > > > > + /* PERF_HPP_DIFF__CYCLES */
> > > > > + s64 cycles;
> > > > >   };
> > > > >};
> > > > > @@ -143,6 +146,9 @@ struct hist_entry {
> > > > >   struct branch_info  *branch_info;
> > > > >   longtime;
> > > > >   struct hists*hists;
> > > > > + void*block_hists;
> > > > > + int block_idx;
> > > > > + int block_num;
> > > > >   struct mem_info *mem_info;
> > > > >   struct block_info   *block_info;
> > > > 
> > > > could you please not add the new block* stuff in here,
> > > > and instead use the "c2c model" and use yourr own struct
> > > > on top of hist_entry? we are trying to librarize this
> > > > stuff and keep only necessary things in here..
> > > > 
> > > > you're already using hist_entry_ops, so should be easy
> > > > 
> > > > something like:
> > > > 
> > > > struct block_hist_entry {
> > > > void*block_hists;
> > > > int block_idx;
> > > > int block_num;
> > > > struct block_info   *block_info;
> > > > 
> > > > struct hist_entry   he;
> > > > };
> > > > 
> > > > 
> > > > 
> > > > jirka
> > > > 
> > > 
> > > Hi Jiri,
> > > 
> > > After more considerations, maybe I can't move these stuffs from hist_entry
> > > to block_hist_entry.
> > 
> > why?
> > 
> > > 
> > > Actually we use 2 kinds of hist_entry in this patch series. On kind of
> > > hist_entry is for symbol/function. The other kind of hist_entry is for 
> > > basic
> > > block.
> > 
> > correct
> > 
> > so the way I see it the processing goes like this:
> > 
> > 
> > 1) there's standard hist_entry processing ending up
> > with evsel->hists->rb_root full of hist entries
> > 
> > 2) then you process every hist_entry and create
> > new 'struct hists' for each and fill it with
> > symbol counts data
> > 
> > 
> > 
> > you could add 'struct hist_entry_ops' for the 1) processing
> > that adds the 'struct hists' object for each hist_entry
> > 
> > and add another 'struct hist_entry_ops' for 2) processing
> > to carry the block data for each hist_entry
> > 
> > jirka
> > 
> 
> Hi Jiri,
> 
> Yes, I can use two hist_entry_ops but one thing is still difficult to handle
> that is the printing of blocks.
> 
> One function may contain multiple blocks so I add 'block_num' in 'struct
> hist_entry' to record the number of blocks.
> 
> In patch "perf diff: Print the basic block cycles diff", I reuse most of
> current code to print the blocks. The major change is:
> 
>  static int hist_entry__fprintf(struct hist_entry *he, size_t size,
>char *bf, size_t bfsz, FILE *fp,
>bool ignore_callchains) {
> 
> +   if (he->block_hists)
> +   return hist_entry__block_fprintf(he, bf, size, fp);
> +


you could do it the way we do hierarchy and have
something like 'symbol_conf.report_block'

if (symbol_conf.report_hierarchy)
return hist_entry__hierarchy_fprintf(he, &hpp, hists, fp);

and in hist_entry__block_fprintf you cast the hist_entry
to your struct.. so you'll have all the data

jirka

> hist_entry__snprintf(he, &hpp);
> }
> 
> +static int hist_entry__block_fprintf(struct hist_entry *he,
> +char *bf, size_t size,
> +FILE *fp)
> +{
> +   int ret = 0;
> +
> +   for (int i = 0; i < he->block_num; i++) {
> +   struct perf_hpp hpp = {
> +   .buf= bf,
> +   .size   = size,
> +   .skip   = false,
> +   };
> +
> +   he->block_idx = i;
> +   hist_entry__snprintf(he, &hpp);
> +
> +   if (!hpp.skip)
> +   ret += fprintf(fp, "%s\n", bf);
> +   }
> +
> +   return ret;
> +}
> +
> 
> So it looks at least I need to add 'block_num' to 'struct hist_entry',
> otherwise I can't reuse most of codes.
> 
> Any idea for 'block_num'?
> 
> Thanks
> Jin Yao

Re: [PATCH V4 3/3] ocfs2: add first lock wait time in locking_state

2019-06-12 Thread Joseph Qi




On 19/6/12 15:29, Gang He wrote:
> Hello Joseph,
> 
 On 6/12/2019 at  3:03 pm, in message
> , Joseph Qi
>  wrote:
>> Hi Gang,
>>
>> On 19/6/11 09:54, Gang He wrote:
>>> ocfs2 file system uses locking_state file under debugfs to dump
>>> each ocfs2 file system's dlm lock resources, but the users ever
>>> encountered some hang(deadlock) problems in ocfs2 file system.
>>> I'd like to add first lock wait time in locking_state file, which
>>> can help the upper scripts detect these deadlock problems via
>>> comparing the first lock wait time with the current time.
>>>
>>> Signed-off-by: Gang He 
>>> ---
>>>  fs/ocfs2/dlmglue.c | 32 +---
>>>  fs/ocfs2/ocfs2.h   |  1 +
>>>  2 files changed, 30 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
>>> index d4caa6d117c6..8ce4b76f81ee 100644
>>> --- a/fs/ocfs2/dlmglue.c
>>> +++ b/fs/ocfs2/dlmglue.c
>>> @@ -440,6 +440,7 @@ static void ocfs2_remove_lockres_tracking(struct 
>> ocfs2_lock_res *res)
>>>  static void ocfs2_init_lock_stats(struct ocfs2_lock_res *res)
>>>  {
>>> res->l_lock_refresh = 0;
>>> +   res->l_lock_wait = 0;
>>> memset(&res->l_lock_prmode, 0, sizeof(struct ocfs2_lock_stats));
>>> memset(&res->l_lock_exmode, 0, sizeof(struct ocfs2_lock_stats));
>>>  }
>>> @@ -483,6 +484,21 @@ static inline void ocfs2_track_lock_refresh(struct 
>> ocfs2_lock_res *lockres)
>>> lockres->l_lock_refresh++;
>>>  }
>>>  
>>> +static inline void ocfs2_track_lock_wait(struct ocfs2_lock_res *lockres)
>>> +{
>>> +   struct ocfs2_mask_waiter *mw;
>>> +
>>> +   if (list_empty(&lockres->l_mask_waiters)) {
>>> +   lockres->l_lock_wait = 0;
>>> +   return;
>>> +   }
>>> +
>>> +   mw = list_first_entry(&lockres->l_mask_waiters,
>>> +   struct ocfs2_mask_waiter, mw_item);
>>> +   lockres->l_lock_wait =
>>> +   ktime_to_us(ktime_mono_to_real(mw->mw_lock_start));
>>
>> I wonder why ktime_mono_to_real() here?
> The new item l_lock_wait is a statistic (or debugging) related, which will be 
> dumping to the user-space via debugfs file locking_state for the further 
> analysis if need.
> As the last comments from Wengang, the dumping is from different nodes in the 
> cluster, it is better to use wall time (instead of mono or boot time) to 
> display the related absolute times.
> Of course, the existing delta time (use mono time) will not affected.
> 
> Thanks
> Gang
> 
Got it,

Reviewed-by: Joseph Qi 

>>
>> Thanks,
>> Joseph
>>
>>> +}
>>> +
>>>  static inline void ocfs2_init_start_time(struct ocfs2_mask_waiter *mw)
>>>  {
>>> mw->mw_lock_start = ktime_get();
>>> @@ -498,6 +514,9 @@ static inline void ocfs2_update_lock_stats(struct 
>> ocfs2_lock_res *res,
>>>  static inline void ocfs2_track_lock_refresh(struct ocfs2_lock_res *lockres)
>>>  {
>>>  }
>>> +static inline void ocfs2_track_lock_wait(struct ocfs2_lock_res *lockres)
>>> +{
>>> +}
>>>  static inline void ocfs2_init_start_time(struct ocfs2_mask_waiter *mw)
>>>  {
>>>  }
>>> @@ -891,6 +910,7 @@ static void lockres_set_flags(struct ocfs2_lock_res 
>> *lockres,
>>> list_del_init(&mw->mw_item);
>>> mw->mw_status = 0;
>>> complete(&mw->mw_complete);
>>> +   ocfs2_track_lock_wait(lockres);
>>> }
>>>  }
>>>  static void lockres_or_flags(struct ocfs2_lock_res *lockres, unsigned long 
>> or)
>>> @@ -1402,6 +1422,7 @@ static void lockres_add_mask_waiter(struct 
>> ocfs2_lock_res *lockres,
>>> list_add_tail(&mw->mw_item, &lockres->l_mask_waiters);
>>> mw->mw_mask = mask;
>>> mw->mw_goal = goal;
>>> +   ocfs2_track_lock_wait(lockres);
>>>  }
>>>  
>>>  /* returns 0 if the mw that was removed was already satisfied, -EBUSY
>>> @@ -1418,6 +1439,7 @@ static int __lockres_remove_mask_waiter(struct 
>> ocfs2_lock_res *lockres,
>>>  
>>> list_del_init(&mw->mw_item);
>>> init_completion(&mw->mw_complete);
>>> +   ocfs2_track_lock_wait(lockres);
>>> }
>>>  
>>> return ret;
>>> @@ -3098,7 +3120,7 @@ static void *ocfs2_dlm_seq_next(struct seq_file *m, 
>> void *v, loff_t *pos)
>>>   * New in version 3
>>>   * - Max time in lock stats is in usecs (instead of nsecs)
>>>   * New in version 4
>>> - * - Add last pr/ex unlock times in usecs
>>> + * - Add last pr/ex unlock times and first lock wait time in usecs
>>>   */
>>>  #define OCFS2_DLM_DEBUG_STR_VERSION 4
>>>  static int ocfs2_dlm_seq_show(struct seq_file *m, void *v)
>>> @@ -3116,7 +3138,7 @@ static int ocfs2_dlm_seq_show(struct seq_file *m, 
>>> void 
>> *v)
>>> return -EINVAL;
>>>  
>>>  #ifdef CONFIG_OCFS2_FS_STATS
>>> -   if (dlm_debug->d_filter_secs) {
>>> +   if (!lockres->l_lock_wait && dlm_debug->d_filter_secs) {
>>> now = ktime_to_us(ktime_get_real());
>>> if (lockres->l_lock_prmode.ls_last >
>>> lockres->l_lock_exmode.ls_last)
>>> @@ -3177,6 +3199,7 @@ static int ocfs2_dlm_seq_show(struct seq_file

Re: [PATCH 2/2] staging: kpc2000: remove unnecessary comments in kp2000_pcie_probe

2019-06-12 Thread Greg KH

On Wed, Jun 12, 2019 at 10:39:36AM +0300, Dan Carpenter wrote:
> On Mon, Jun 10, 2019 at 10:05:35PM +0200, Simon Sandström wrote:
> > @@ -349,9 +340,7 @@ static int kp2000_pcie_probe(struct pci_dev *pdev,
> > goto err_remove_ida;
> > }
> >  
> > -   /*
> > -* Step 4: Setup the Register BAR
> > -*/
> > +   // Setup the Register BAR
> 
> Greg, are we moving the C++ style comments?  Linus is fine with them.  I
> don't like them but whatever...

I don't like them either.  I'm only "ok" with them on the very first
line of the file.  Linus chose // to make it "stand out" from the normal
flow of the file, which is fine for an SPDX line.  So putting these in
here like this is not ok to me.

thanks,

greg k-h

Re: [PATCH v3 2/4] dt-bindings: arm: stm32: Convert STM32 SoC bindings to DT schema

Hi Rob,

On Mon, Jun 10, 2019 at 03:57:43PM -0600, Rob Herring wrote:
> On Fri, May 31, 2019 at 12:39 AM Manivannan Sadhasivam
>  wrote:
> >
> > This commit converts STM32 SoC bindings to DT schema using jsonschema.
> >
> > Signed-off-by: Manivannan Sadhasivam 
> > ---
> >  .../devicetree/bindings/arm/stm32/stm32.yaml  | 29 +++
> >  1 file changed, 29 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.yaml
> 
> Converting implies removal of something. The schema looks fine though.
> 

Ah, sorry. I forgot to delete the .txt file. Will do it in next revision.

Thanks,
Mani

> >
> > diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml 
> > b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
> > new file mode 100644
> > index ..f53dc0f2d7b3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
> > @@ -0,0 +1,29 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/arm/stm32/stm32.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: STMicroelectronics STM32 Platforms Device Tree Bindings
> > +
> > +maintainers:
> > +  - Alexandre Torgue 
> > +
> > +properties:
> > +  compatible:
> > +oneOf:
> > +  - items:
> > +  - const: st,stm32f429
> > +
> > +  - items:
> > +  - const: st,stm32f469
> > +
> > +  - items:
> > +  - const: st,stm32f746
> > +
> > +  - items:
> > +  - const: st,stm32h743
> > +
> > +  - items:
> > +  - const: st,stm32mp157
> > +...
> > --
> > 2.17.1
> >

Re: [PATCH 0/1] gpio: of: prepare for switching stmmac to GPIO descriptors

On Mon, Jun 10, 2019 at 7:05 PM Martin Blumenstingl
 wrote:

> This is a preparation patch which is needed before we can switch stmmac
> to GPIO descriptors. stmmac has a custom "snps,reset-active-low"
> property because it has ignored the GPIO flags including the polarity.
>
> Add the parsing to gpiolib-of so we can port stmmac over to GPIO
> descriptors.
>
> This patch is split from my series at [0].
>
> Linus W.: please create an immutable branch as discussed so I can send
> the stmmac patches to the net-next tree (which will then have to pull
> in your immutable branch).

Thanks Martin!
I have applied the patch and created an immutable branch:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
ib-snps-reset-gpio

https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=ib-snps-reset-gpio

Please refer to this so the network maintainer can pull it in.

It is based on v5.2-rc1

Yours,
Linus Walleij

[PATCH v5] KVM: x86: Add Intel CPUID.1F cpuid emulation support

2019-06-12 Thread Like Xu

Add support to expose Intel V2 Extended Topology Enumeration Leaf for
some new systems with multiple software-visible die within each package.

Because unimplemented and unexposed leaves should be explicitly reported
as zero, there is no need to limit cpuid.0.eax to the maximum value of
feature configuration but limit it to the highest leaf implemented in
the current code. A single clamping seems sufficient and cheaper.

Reported-by: kbuild test robot 
Co-developed-by: Xiaoyao Li 
Signed-off-by: Xiaoyao Li 
Signed-off-by: Like Xu 

---

==changelog==

v5:
- Fixed sparse warnings: ncompatible types in comparison expression

v4: https://lkml.org/lkml/2019/6/5/1029
- Limited cpuid.0.eax to the highest leaf implemented in KVM

v3: https://lkml.org/lkml/2019/5/26/64
- Refine commit message and comment

v2: https://lkml.org/lkml/2019/4/25/1246

- Apply cpuid.1f check rule on Intel SDM page 3-222 Vol.2A
- Add comment to handle 0x1f anf 0xb in common code
- Reduce check time in a descending-break style

v1: https://lkml.org/lkml/2019/4/22/28

---
 arch/x86/kvm/cpuid.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index e18a9f9f65b5..d0dafaecf05b 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -426,7 +426,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
 
switch (function) {
case 0:
-   entry->eax = min(entry->eax, (u32)(f_intel_pt ? 0x14 : 0xd));
+   /* Limited to the highest leaf implemented in KVM. */
+   entry->eax = min(entry->eax, (u32)0x1f);
break;
case 1:
entry->edx &= kvm_cpuid_1_edx_x86_features;
@@ -546,7 +547,11 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
entry->edx = edx.full;
break;
}
-   /* function 0xb has additional index. */
+   /*
+* Per Intel's SDM, the 0x1f is a superset of 0xb,
+* thus they can be handled by common code.
+*/
+   case 0x1f:
case 0xb: {
int i, level_type;
 
-- 
2.21.0

Re: Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …

2019-06-12 Thread Greg KH

On Wed, Jun 12, 2019 at 09:19:15AM +0200, Rolf Eike Beer wrote:
> Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH:
> > On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote:
> > > On Thu, Jun 6, 2019 at 5:29 PM Greg KH  wrote:
> > > > And if you want this, you should look at how the backports to 4.14.y
> > > > worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use
> > > > feature checks instead of version checks"), as that gets really messy...
> > > 
> > > I am confused -- I interpreted Rolf's message as reporting that he
> > > already successfully built 4.9 by applying a6e60d84989f
> > > ("include/linux/module.h: copy __init/__exit attrs to
> > > init/cleanup_module") and manually fixing it up. But maybe I am
> > > completely wrong... :-)
> > 
> > "manually fixing it up" means "hacked it to pieces" to me, I have no
> > idea what the end result really was :)
> > 
> > If someone wants to send me some patches I can actually apply, that
> > would be best...
> 
> Hi all,
> 
> the patch I actually used was this:
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 8fa38d3e7538..f5bc4c046461 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -129,13 +129,13 @@ extern void cleanup_module(void);
>  #define module_init(initfn)  \
>   static inline initcall_t __maybe_unused __inittest(void)
> \
>   { return initfn; }  \
> - int init_module(void) __attribute__((alias(#initfn)));
> + int init_module(void) __attribute__((__copy__(initfn))) 
> __attribute__((alias(#initfn)));
>  
>  /* This is only required if you want to be unloadable. */
>  #define module_exit(exitfn)  \
>   static inline exitcall_t __maybe_unused __exittest(void)
> \
>   { return exitfn; }  \
> - void cleanup_module(void) __attribute__((alias(#exitfn)));
> + void cleanup_module(void) __attribute__((__copy__(exitfn))) 
> __attribute__((alias(#exitfn)));
>  
>  #endif
>  
> 
> So the final question is: do we want 4.9.x to be buildable with gcc 9.x? If
> yes then we can probably get this patches into shape.

Eventually, yes, we (or at least I) will want to build 4.9.x with gcc
9.x.  We went through this same process for gcc 8.x as all of my builder
test machines switched their default version of gcc...

thanks,

greg k-h

[PATCH v4 0/4] Add Avenger96 board support

Hello,

This patchset adds Avenger96 board support. This board is one of the
Consumer Edition boards of the 96Boards family from Arrow Electronics
featuring STM32MP157A MPU and has the following features:

SoC: STM32MP157AAC
PMIC: STPMIC1A
RAM: 1024 Mbyte @ 533MHz
Storage: eMMC v4.51: 8 Gbyte
 microSD Socket: UHS-1 v3.01
Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
  Bluetooth®v4.2 (BR/EDR/BLE)
USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
LED: 4x User LED, 1x WiFi LED, 1x BT LED

More information about this board can be found in 96Boards website:
https://www.96boards.org/product/avenger96/

Thanks,
Mani

Changes in v4

* Deleted the old stm32.txt binding
* Added Rob's Reviewed-by tag

Changes in v3:

* Converted STM32 platform bindings to DT schema

Changes in v2:

As per Alex's review:

* Fixed I2C2 pinctrl node
* Sorted the avenger96 dtb in alphabetical order
* Added device-type property to memory node

Manivannan Sadhasivam (4):
  ARM: dts: stm32mp157: Add missing pinctrl definitions
  dt-bindings: arm: stm32: Convert STM32 SoC bindings to DT schema
  dt-bindings: arm: stm32: Document Avenger96 devicetree binding
  ARM: dts: Add Avenger96 devicetree support based on STM32MP157A

 .../devicetree/bindings/arm/stm32/stm32.txt   |  10 -
 .../devicetree/bindings/arm/stm32/stm32.yaml  |  31 ++
 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/stm32mp157-pinctrl.dtsi |  75 
 arch/arm/boot/dts/stm32mp157a-avenger96.dts   | 321 ++
 5 files changed, 428 insertions(+), 10 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.txt
 create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.yaml
 create mode 100644 arch/arm/boot/dts/stm32mp157a-avenger96.dts

-- 
2.17.1

Re: [PATCH-next 01/20] gpio: gpio-omap: ensure irq is enabled before wakeup

On Mon, Jun 10, 2019 at 7:11 PM Grygorii Strashko
 wrote:

> From: Russell King 
>
> Documentation states:
>
>   NOTE: There must be a correlation between the wake-up enable and
>   interrupt-enable registers. If a GPIO pin has a wake-up configured
>   on it, it must also have the corresponding interrupt enabled (on
>   one of the two interrupt lines).
>
> Ensure that this condition is always satisfied by enabling the detection
> events after enabling the interrupt, and disabling the detection before
> disabling the interrupt.  This ensures interrupt/wakeup events can not
> happen until both the wakeup and interrupt enables correlate.
>
> If we do any clearing, clear between the interrupt enable/disable and
> trigger setting.
>
> Signed-off-by: Russell King 
> Signed-off-by: Grygorii Strashko 

Patch applied.

Yours,
Linus Walleij

[PATCH v4 4/4] ARM: dts: Add Avenger96 devicetree support based on STM32MP157A

Add devicetree support for Avenger96 board based on STM32MP157A MPU
from ST Micro. This board is one of the 96Boards Consumer Edition board
from Arrow Electronics and has the following features:

SoC: STM32MP157AAC
PMIC: STPMIC1A
RAM: 1024 Mbyte @ 533MHz
Storage: eMMC v4.51: 8 Gbyte
 microSD Socket: UHS-1 v3.01
Ethernet Port: 10/100/1000 Mbit/s, IEEE 802.3 Compliant
Wireless: WiFi 5 GHz & 2.4GHz IEEE 802.11a/b/g/n/ac
  Bluetooth®v4.2 (BR/EDR/BLE)
USB: 2x Type A (USB 2.0) Host and 1x Micro B (USB 2.0) OTG
Display: HDMI: WXGA (1366x768)@ 60 fps, HDMI 1.4
LED: 4x User LED, 1x WiFi LED, 1x BT LED

More information about this board can be found in 96Boards website:
https://www.96boards.org/product/avenger96/

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/stm32mp157a-avenger96.dts | 321 
 2 files changed, 322 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32mp157a-avenger96.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index dab2914fa293..918c85c227b5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -975,6 +975,7 @@ dtb-$(CONFIG_ARCH_STM32) += \
stm32746g-eval.dtb \
stm32h743i-eval.dtb \
stm32h743i-disco.dtb \
+   stm32mp157a-avenger96.dtb \
stm32mp157a-dk1.dtb \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
diff --git a/arch/arm/boot/dts/stm32mp157a-avenger96.dts 
b/arch/arm/boot/dts/stm32mp157a-avenger96.dts
new file mode 100644
index ..9d00be78010f
--- /dev/null
+++ b/arch/arm/boot/dts/stm32mp157a-avenger96.dts
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
+ * Author: Manivannan Sadhasivam 
+ */
+
+/dts-v1/;
+
+#include "stm32mp157c.dtsi"
+#include "stm32mp157-pinctrl.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Arrow Electronics STM32MP157A Avenger96 board";
+   compatible = "arrow,stm32mp157a-avenger96", "st,stm32mp157";
+
+   aliases {
+   ethernet0 = ðernet0;
+   mmc0 = &sdmmc1;
+   serial0 = &uart4;
+   serial1 = &uart7;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@c000 {
+   device_type = "memory";
+   reg = <0xc000 0x4000>;
+   };
+
+   led {
+   compatible = "gpio-leds";
+   led1 {
+   label = "green:user1";
+   gpios = <&gpioz 7 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   default-state = "off";
+   };
+
+   led2 {
+   label = "green:user2";
+   gpios = <&gpiof 3 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc0";
+   default-state = "off";
+   };
+
+   led3 {
+   label = "green:user3";
+   gpios = <&gpiog 0 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc1";
+   default-state = "off";
+   };
+
+   led4 {
+   label = "green:user3";
+   gpios = <&gpiog 1 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "none";
+   default-state = "off";
+   panic-indicator;
+   };
+
+   led5 {
+   label = "yellow:wifi";
+   gpios = <&gpioz 3 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "phy0tx";
+   default-state = "off";
+   };
+
+   led6 {
+   label = "blue:bt";
+   gpios = <&gpioz 6 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "bluetooth-power";
+   default-state = "off";
+   };
+   };
+};
+
+ðernet0 {
+   status = "okay";
+   pinctrl-0 = <ðernet0_rgmii_pins_a>;
+   pinctrl-1 = <ðernet0_rgmii_pins_sleep_a>;
+   pinctrl-names = "default", "sleep";
+   phy-mode = "rgmii";
+   max-speed = <1000>;
+   phy-handle = <&phy0>;
+
+   mdio0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "snps,dwmac-mdio";
+   phy0: ethernet-phy@7 {
+   reg = <7>;
+   };
+   };
+};
+
+&i2c1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c1_pins_b>;
+   i2c-scl-rising-time-ns = <185>;
+   i2c-scl-falling-time-ns = <20>;
+   status = "okay";
+   /delete-property/dmas;
+   /delete-property/dma-names;
+};
+
+&i2c2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c2_pins_b1 &i2c2_pins_b2>;
+   i2c-scl-rising-time-

[PATCH v4 1/4] ARM: dts: stm32mp157: Add missing pinctrl definitions

Add missing pinctrl definitions for STM32MP157 MPU.

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 75 +++
 1 file changed, 75 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi 
b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index 85c417d9983b..5efae4b4b37f 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -241,6 +241,23 @@
};
};
 
+   i2c1_pins_b: i2c1-2 {
+   pins {
+   pinmux = , 
/* I2C1_SCL */
+; 
/* I2C1_SDA */
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <0>;
+   };
+   };
+
+   i2c1_pins_sleep_b: i2c1-3 {
+   pins {
+   pinmux = , /* I2C1_SCL */
+; /* I2C1_SDA */
+   };
+   };
+
i2c2_pins_a: i2c2-0 {
pins {
pinmux = , 
/* I2C2_SCL */
@@ -258,6 +275,21 @@
};
};
 
+   i2c2_pins_b1: i2c2-2 {
+   pins {
+   pinmux = ; 
/* I2C2_SDA */
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <0>;
+   };
+   };
+
+   i2c2_pins_sleep_b1: i2c2-3 {
+   pins {
+   pinmux = ; /* I2C2_SDA */
+   };
+   };
+
i2c5_pins_a: i2c5-0 {
pins {
pinmux = , 
/* I2C5_SCL */
@@ -599,6 +631,34 @@
bias-disable;
};
};
+
+   uart4_pins_b: uart4-1 {
+   pins1 {
+   pinmux = ; 
/* UART4_TX */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = ; 
/* UART4_RX */
+   bias-disable;
+   };
+   };
+
+   uart7_pins_a: uart7-0 {
+   pins1 {
+   pinmux = ; 
/* UART4_TX */
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <0>;
+   };
+   pins2 {
+   pinmux = , 
/* UART4_RX */
+, 
/* UART4_CTS */
+; 
/* UART4_RTS */
+   bias-disable;
+   };
+   };
};
 
pinctrl_z: pin-controller-z@54004000 {
@@ -623,6 +683,21 @@
gpio-ranges = <&pinctrl_z 0 400 8>;
};
 
+   i2c2_pins_b2: i2c2-0 {
+   pins {
+   pinmux = ; 
/* I2C2_SCL */
+   bias-disable;
+   drive-open-drain;
+   slew-rate = <0>;
+   };
+   };
+
+   i2c2_pins_sleep_b2: i2c2-1 {
+   pins {
+   pinmux = ; /* I2C2_SCL */
+   };
+   };
+
i2c4_pins_a: i2c4-0 {
pins {
pinmux = , 
/* I2C4_SCL */
-- 
2.17.1

Re: [PATCH][next] video: fbdev: atmel_lcdfb: remove redundant initialization to variable ret

2019-06-12 Thread Nicolas.Ferre

On 11/06/2019 at 19:09, Colin King wrote:
> External E-Mail
> 
> 
> From: Colin Ian King 
> 
> Currently variable ret is being initialized with -ENOENT however that
> value is never read and ret is being re-assigned later on. Hence this
> assignment is redundant and can be removed.
> 
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Indeed:
Acked-by: Nicolas Ferre 

Thanks, best regards,
   Nicolas


> ---
>   drivers/video/fbdev/atmel_lcdfb.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
> b/drivers/video/fbdev/atmel_lcdfb.c
> index fb117ccbeab3..930cc3f92e01 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -950,7 +950,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
> *sinfo)
>   struct fb_videomode fb_vm;
>   struct gpio_desc *gpiod;
>   struct videomode vm;
> - int ret = -ENOENT;
> + int ret;
>   int i;
>   
>   sinfo->config = (struct atmel_lcdfb_config*)
> 


-- 
Nicolas Ferre

[PATCH v4 3/4] dt-bindings: arm: stm32: Document Avenger96 devicetree binding

This commit documents Avenger96 devicetree binding based on
STM32MP157 SoC.

Reviewed-by: Rob Herring 
Signed-off-by: Manivannan Sadhasivam 
---
 Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml 
b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
index f53dc0f2d7b3..4d194f1eb03a 100644
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -25,5 +25,7 @@ properties:
   - const: st,stm32h743
 
   - items:
+  - enum:
+  - arrow,stm32mp157a-avenger96 # Avenger96
   - const: st,stm32mp157
 ...
-- 
2.17.1

[PATCH v4 2/4] dt-bindings: arm: stm32: Convert STM32 SoC bindings to DT schema

This commit converts STM32 SoC bindings to DT schema using jsonschema.

Signed-off-by: Manivannan Sadhasivam 
---
 .../devicetree/bindings/arm/stm32/stm32.txt   | 10 ---
 .../devicetree/bindings/arm/stm32/stm32.yaml  | 29 +++
 2 files changed, 29 insertions(+), 10 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.txt
 create mode 100644 Documentation/devicetree/bindings/arm/stm32/stm32.yaml

diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.txt 
b/Documentation/devicetree/bindings/arm/stm32/stm32.txt
deleted file mode 100644
index 6808ed9ddfd5..
--- a/Documentation/devicetree/bindings/arm/stm32/stm32.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-STMicroelectronics STM32 Platforms Device Tree Bindings
-
-Each device tree must specify which STM32 SoC it uses,
-using one of the following compatible strings:
-
-  st,stm32f429
-  st,stm32f469
-  st,stm32f746
-  st,stm32h743
-  st,stm32mp157
diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml 
b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
new file mode 100644
index ..f53dc0f2d7b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/stm32/stm32.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STM32 Platforms Device Tree Bindings
+
+maintainers:
+  - Alexandre Torgue 
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - const: st,stm32f429
+
+  - items:
+  - const: st,stm32f469
+
+  - items:
+  - const: st,stm32f746
+
+  - items:
+  - const: st,stm32h743
+
+  - items:
+  - const: st,stm32mp157
+...
-- 
2.17.1

Re: [PATCH-next 02/20] gpio: gpio-omap: fix lack of irqstatus_raw0 for OMAP4

On Mon, Jun 10, 2019 at 7:11 PM Grygorii Strashko
 wrote:

> From: Russell King 
>
> Commit 384ebe1c2849 ("gpio/omap: Add DT support to GPIO driver") added
> the register definition tables to the gpio-omap driver. Subsequently to
> that commit, commit 4e962e8998cc ("gpio/omap: remove cpu_is_omap()
> checks from *_runtime_resume()") added definitions for irqstatus_raw*
> registers to the legacy OMAP4 definitions, but missed the DT
> definitions.
>
> This causes an unintentional change of behaviour for the 1.101 errata
> workaround on OMAP4 platforms. Fix this oversight.
>
> Fixes: 4e962e8998cc ("gpio/omap: remove cpu_is_omap() checks from 
> *_runtime_resume()")
> Signed-off-by: Russell King 
> Signed-off-by: Grygorii Strashko 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] vsprintf: fix data type of variable in string_nocheck()

2019-06-12 Thread Petr Mladek

On Mon 2019-06-10 17:16:54, Sergey Senozhatsky wrote:
> On (06/10/19 16:47), 남영민 wrote:
> > This patch fixes data type of precision with int.
> > The precision is declared as signed int in struct printf_spec.
> > 
> > Signed-off-by: Youngmin Nam 
> 
> Looks OK to me.
> 
> FWIW
> Reviewed-by: Sergey Senozhatsky 

The patch has been committed into printk.git, branch for-5.3.

Best Regards,
Petr

Re: [PATCH-next 03/20] gpio: gpio-omap: remove remainder of list management

On Mon, Jun 10, 2019 at 7:11 PM Grygorii Strashko
 wrote:

> From: Russell King 
>
> Commit c4791bc6e3a6 ("gpio: omap: drop omap_gpio_list") removed the
> list head and addition to the list head of each gpio bank, but failed
> to remove the list_del() call and the node inside struct gpio_bank.
> Remove these too.
>
> Fixes: c4791bc6e3a6 ("gpio: omap: drop omap_gpio_list")
> Signed-off-by: Russell King 
> Signed-off-by: Grygorii Strashko 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH-next 04/20] gpio: gpio-omap: clean up edge interrupt handling

On Mon, Jun 10, 2019 at 7:11 PM Grygorii Strashko
 wrote:

> From: Russell King 
>
> The edge interrupt handling was effectively:
>
> isr = ISR_reg & enabled;
> if (bank->level_mask)
> level_mask = bank->level_mask & enabled;
> else
> level_mask = 0;
>
> edge = isr & ~level_mask;
>
> When bank->level_mask is zero, level_mask will be computed as zero
> anyway, so the if() statement is redundant.  We are then left with:
>
> isr = ISR_reg & enabled;
> level_mask = bank->level_mask & enabled;
> edge = isr & ~level_mask;
>
> This can be simplified further to:
>
> isr = ISR_reg & enabled;
> edge = isr & ~bank->level_mask;
>
> since the second mask with 'enabled' is redundant.
>
> Improve the associated comment as well.
>
> Signed-off-by: Russell King 
> Signed-off-by: Grygorii Strashko 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] kprobes: Fix to init kprobes in subsys_initcall

2019-06-12 Thread Masami Hiramatsu

Hi Steve,

Could you pick this to your ftrace/core branch?

Thank you,


On Mon,  3 Jun 2019 22:04:42 +0900
Masami Hiramatsu  wrote:

> Since arm64 kernel initializes breakpoint trap vector in arch_initcall(),
> initializing kprobe (and run smoke test) in postcore_initcall() causes
> a kernel panic.
> 
> To fix this issue, move the kprobe initialization in subsys_initcall()
> (which is called right afer the arch_initcall).
> 
> In-kernel kprobe users (ftrace and bpf) are using fs_initcall() which is
> called after subsys_initcall(), so this shouldn't cause more problem.
> 
> Reported-by: Anders Roxell 
> Fixes: b5f8b32c93b2 ("kprobes: Initialize kprobes at postcore_initcall")
> Signed-off-by: Masami Hiramatsu 
> ---
>  kernel/kprobes.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 54d00a47..5471efbeb937 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -2289,7 +2289,7 @@ static int __init init_kprobes(void)
>   init_test_probes();
>   return err;
>  }
> -postcore_initcall(init_kprobes);
> +subsys_initcall(init_kprobes);
>  
>  #ifdef CONFIG_DEBUG_FS
>  static void report_probe(struct seq_file *pi, struct kprobe *p,
> 


-- 
Masami Hiramatsu

Re: How to inject fwnode/oftree/acpi data by platform driver ?

2019-06-12 Thread Heikki Krogerus

Hi,

On Tue, Jun 11, 2019 at 09:44:23PM +0300, Andy Shevchenko wrote:
> +Cc: Heikki.
> Heikki, can you help here with swnodes?
> 
> On Sat, Jun 1, 2019 at 5:17 PM Enrico Weigelt, metux IT consult
>  wrote:
> >
> > Hi folks,
> >
> >
> > I'm looking for a way to inject fwnode data from a platform driver,
> > in order to initialize generic drivers w/ board specific configuration.
> > The idea is getting rid of passing driver specific pdata structs
> > (which, IIRC, seem to be deprecated).
> >
> > An example usecase is the APUv2/3 board, which have things like gpios
> > wired to buttons and LEDs. The board can only be detected via DMI
> > string, no way to probe the platform devices - have to be initialized
> > explicitly (that's how I'm already doing it now).
> >
> > The nicest way, IMHO, would be if I could just write some piece of DTS
> > and some fancy magic all the rest under the hood. Such thing doesn't
> > seem to exist yet. Does it make sense to implement that ? How could
> > we do it ?
> >
> > Which other options do we have ?
> >
> > Or should we just leave everything as it is and stick w/ pdata structs ?

The software nodes (drivers/base/swnode.c) were designed to supply
fwnodes that describe devices in the same way DT does. The goal I had
with the software nodes was exaclty to get rid of pdata, so they do
sound like the thing you are looking for. If you check Rafael's latest
linux-next branch [1], drivers/platform/x86/intel_cht_int33fe.c can be
used as an example how to use the software nodes.

I think it's time to add documentation for the software nodes to the
kernel, but I'll list here the features the software nodes have:

- The software nodes are created independently from device entries.
- Software nodes support hierarchy. Every software node has a pointer
  to a parent software node.
- Software nodes can have device properties.
- Software nodes can have reference pointers to other software nodes
  (outside of the hierarchy).

Creating the software nodes from static description (struct
software_node - available from Linux kernel v5.3 onwards) is
straightforward. Once you have them, when you create your device
entries (struct device), you can associate a software node with a
device just like like any other fwnode:

device_initialize(&my_dev);
my_dev.parent = parent;
my_dev.fwnode = software_node_fwnode(&my_node);
...
device_add(&my_device);

After that, you can access all the information the software nodes
supply to the device by using fwnode_* APIs from your driver, just
like with ACPI or DT. Basically the entire fwnode_* API is now
supported with softwarw nodes, except the device graph (fwnode_graph*)
API.

One final note. The hardware description must always primarily come
from the system firmware. You only use software nodes if it's too
late to influence what goes to the ACPI tables, or if using DTS is not
an option.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next

thanks,

-- 
heikki

[PATCH v2] drivers: net: dsa: fix warning same module names

When building with CONFIG_NET_DSA_REALTEK_SMI and CONFIG_REALTEK_PHY
enabled as loadable modules, we see the following warning:

warning: same module names found:
  drivers/net/phy/realtek.ko
  drivers/net/dsa/realtek.ko

Rework so the driver name is rtl8366 instead of realtek.

Signed-off-by: Anders Roxell 
---
 drivers/net/dsa/Makefile| 4 ++--
 drivers/net/dsa/{rtl8366.c => rtl8366-common.c} | 0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename drivers/net/dsa/{rtl8366.c => rtl8366-common.c} (100%)

diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index fefb6aaa82ba..d7a282eb2ff9 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -9,8 +9,8 @@ obj-$(CONFIG_NET_DSA_LANTIQ_GSWIP) += lantiq_gswip.o
 obj-$(CONFIG_NET_DSA_MT7530)   += mt7530.o
 obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
 obj-$(CONFIG_NET_DSA_QCA8K)+= qca8k.o
-obj-$(CONFIG_NET_DSA_REALTEK_SMI) += realtek.o
-realtek-objs   := realtek-smi.o rtl8366.o rtl8366rb.o
+obj-$(CONFIG_NET_DSA_REALTEK_SMI) += rtl8366.o
+rtl8366-objs   := realtek-smi.o rtl8366-common.o rtl8366rb.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
 obj-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
diff --git a/drivers/net/dsa/rtl8366.c b/drivers/net/dsa/rtl8366-common.c
similarity index 100%
rename from drivers/net/dsa/rtl8366.c
rename to drivers/net/dsa/rtl8366-common.c
-- 
2.20.1

[PATCH v2 1/3] drivers: media: i2c: fix warning same module names

When building with CONFIG_VIDEO_ADV7511 and CONFIG_DRM_I2C_ADV7511
enabled as loadable modules, we see the following warning:

warning: same module names found:
  drivers/gpu/drm/bridge/adv7511/adv7511.ko
  drivers/media/i2c/adv7511.ko

Rework so the names matches the config fragment.

Signed-off-by: Anders Roxell 
---
 drivers/media/i2c/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index d8ad9dad495d..b71a427a89fd 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -35,7 +35,8 @@ obj-$(CONFIG_VIDEO_ADV748X) += adv748x/
 obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
 obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o
 obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
-obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o
+obj-$(CONFIG_VIDEO_ADV7511) += video-adv7511.o
+video-adv7511-objs  := adv7511.o
 obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
 obj-$(CONFIG_VIDEO_VS6624)  += vs6624.o
 obj-$(CONFIG_VIDEO_BT819) += bt819.o
-- 
2.20.1

[PATCH v2] drivers: mfd: 88pm800: fix warning same module names

When building with CONFIG_MFD_88PM800 and CONFIG_REGULATOR_88PM800
enabled as loadable modules, we see the following warning:

warning: same module names found:
  drivers/regulator/88pm800.ko
  drivers/mfd/88pm800.ko

Rework so the names matches the config fragment.

Signed-off-by: Anders Roxell 
---
 drivers/mfd/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 52b1a90ff515..5e870eef6a20 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -5,8 +5,11 @@
 
 88pm860x-objs  := 88pm860x-core.o 88pm860x-i2c.o
 obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
-obj-$(CONFIG_MFD_88PM800)  += 88pm800.o 88pm80x.o
-obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
+obj-$(CONFIG_MFD_88PM800)  += mfd-88pm800.o mfd-88pm80x.o
+mfd-88pm800-objs   := 88pm800.o
+obj-$(CONFIG_MFD_88PM805)  += mfd-88pm805.o mfd-88pm80x.o
+mfd-88pm805-objs   := 88pm805.o
+mfd-88pm80x-objs   := 88pm80x.o
 obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
-- 
2.20.1

[PATCH v2] drivers: regulator: 88pm800: fix warning same module names

When building with CONFIG_MFD_88PM800 and CONFIG_REGULATOR_88PM800
enabled as loadable modules, we see the following warning:

warning: same module names found:
  drivers/regulator/88pm800.ko
  drivers/mfd/88pm800.ko

Rework so that the file is named 88pm800-regulator.

Signed-off-by: Anders Roxell 
---
 drivers/regulator/{88pm800.c => 88pm800-regulator.c} | 0
 drivers/regulator/Makefile   | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/regulator/{88pm800.c => 88pm800-regulator.c} (100%)

diff --git a/drivers/regulator/88pm800.c b/drivers/regulator/88pm800-regulator.c
similarity index 100%
rename from drivers/regulator/88pm800.c
rename to drivers/regulator/88pm800-regulator.c
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 76e78fa449a2..c15b0b613766 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
 obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
 
 obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o
-obj-$(CONFIG_REGULATOR_88PM800) += 88pm800.o
+obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o
 obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o
 obj-$(CONFIG_REGULATOR_CPCAP) += cpcap-regulator.o
 obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o
-- 
2.20.1

Re: [PATCH v1 1/4] dt-bindings: ASoC: Add TDA7802 amplifier

2019-06-12 Thread Charles Keepax

On Tue, Jun 11, 2019 at 06:49:06PM +0100, Thomas Preston wrote:
> Signed-off-by: Thomas Preston 
> Cc: Patrick Glaser 
> Cc: Rob Duncan 
> Cc: Nate Case 
> ---
>  .../devicetree/bindings/sound/tda7802.txt  | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/tda7802.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/tda7802.txt 
> b/Documentation/devicetree/bindings/sound/tda7802.txt
> new file mode 100644
> index ..f80aaf4f1ba0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/tda7802.txt
> @@ -0,0 +1,26 @@
> +ST TDA7802 audio processor
> +
> +This device supports I2C only.
> +
> +Required properties:
> +
> +- compatible : "st,tda7802"
> +- reg : the I2C address of the device
> +- enable-supply : a regulator spec for the PLLen pin
> +
> +Optional properties:
> +
> +- st,gain-ch13 : gain for channels 1 and 3 (range: 1-4)
> +- st,gain-ch24 : gain for channels 2 and 3 (range: 1-4)

Does it make sense to have the gains in device tree? Are these
expected to be fixed by the system design, normally the gain
would be controlled through an ALSA control.

Thanks,
Charles

Re: [PATCH v4 1/3] stacktrace: Remove weak version of save_stack_trace_tsk_reliable()

2019-06-12 Thread Petr Mladek

On Tue 2019-06-11 16:13:18, Miroslav Benes wrote:
> Recent rework of stack trace infrastructure introduced a new set of
> helpers for common stack trace operations (commit e9b98e162aa5
> ("stacktrace: Provide helpers for common stack trace operations") and
> related). As a result, save_stack_trace_tsk_reliable() is not directly
> called anywhere. Livepatch, currently the only user of the reliable
> stack trace feature, now calls stack_trace_save_tsk_reliable().
> 
> When CONFIG_HAVE_RELIABLE_STACKTRACE is set and depending on
> CONFIG_ARCH_STACKWALK, stack_trace_save_tsk_reliable() calls either
> arch_stack_walk_reliable() or mentioned save_stack_trace_tsk_reliable().
> x86_64 defines the former, ppc64le the latter. All other architectures
> do not have HAVE_RELIABLE_STACKTRACE and include/linux/stacktrace.h
> defines -ENOSYS returning version for them.
> 
> In short, stack_trace_save_tsk_reliable() returning -ENOSYS defined in
> include/linux/stacktrace.h serves the same purpose as the old weak
> version of save_stack_trace_tsk_reliable() which is therefore no longer
> needed.
> 
> Cc: Thomas Gleixner 
> Signed-off-by: Miroslav Benes 

Reviewed-by: Petr Mladek 

Best Regards,
Petr

Re: [PATCH 2/2 v5] tty/serial/8250: use mctrl_gpio helpers

2019-06-12 Thread Stefan Roese


On 11.06.19 16:48, Andy Shevchenko wrote:

On Tue, Jun 11, 2019 at 04:02:54PM +0200, Stefan Roese wrote:

On 11.06.19 14:44, Andy Shevchenko wrote:

On Tue, Jun 11, 2019 at 12:56:03PM +0200, Stefan Roese wrote:



   static inline void serial8250_out_MCR(struct uart_8250_port *up, int value)
   {
serial_out(up, UART_MCR, value);
+
+   if (up->gpios) {
+   int mctrl_gpio = 0;
+
+   if (value & UART_MCR_RTS)
+   mctrl_gpio |= TIOCM_RTS;
+   if (value & UART_MCR_DTR)
+   mctrl_gpio |= TIOCM_DTR;
+
+   mctrl_gpio_set(up->gpios, mctrl_gpio);
+   }
   }



   static inline int serial8250_in_MCR(struct uart_8250_port *up)
   {
-   return serial_in(up, UART_MCR);
+   int mctrl;
+
+   mctrl = serial_in(up, UART_MCR);
+
+   if (up->gpios) {
+   int mctrl_gpio = 0;
+
+   /* save current MCR values */
+   if (mctrl & UART_MCR_RTS)
+   mctrl_gpio |= TIOCM_RTS;
+   if (mctrl & UART_MCR_DTR)
+   mctrl_gpio |= TIOCM_DTR;
+
+   mctrl_gpio = mctrl_gpio_get_outputs(up->gpios, &mctrl_gpio);
+   if (mctrl_gpio & TIOCM_RTS)
+   mctrl |= UART_MCR_RTS;
+   else
+   mctrl &= ~UART_MCR_RTS;
+
+   if (mctrl_gpio & TIOCM_DTR)
+   mctrl |= UART_MCR_DTR;
+   else
+   mctrl &= ~UART_MCR_DTR;
+   }
+
+   return mctrl;
   }


These are using OR logic with potentially volatile data. Shouldn't we mask
unused bits in UART_MCR in case of up->gpios != NULL?


Sorry, I don't see, which bits you are referring to? Could you please be
a bit more specific with the variable / macro meant (example)?


I meant that we double write values in the out() which might have some
consequences, though I hope nothing wrong with it happens.


Where is the double write to a register? Sorry, I fail to spot it.
 

In the in() we read the all bits in the register.

As now I look at the implementation of mctrl_gpio_get_outputs(),
I think we rather get helpers for conversion between TIOCM and UART_MCR values,
so, they can be used in get_mctrl() / set_mctrl() and above.


Do you something like this in mind?

diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index dc9354e34b60..f44561fcb941 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1954,19 +1954,12 @@ unsigned int serial8250_do_get_mctrl(struct uart_port 
*port)
status = serial8250_modem_status(up);
serial8250_rpm_put(up);
 
-   ret = 0;

-
if (up->gpios)
return mctrl_gpio_get(up->gpios, &ret);
 
-   if (status & UART_MSR_DCD)

-   ret |= TIOCM_CAR;
-   if (status & UART_MSR_RI)
-   ret |= TIOCM_RNG;
-   if (status & UART_MSR_DSR)
-   ret |= TIOCM_DSR;
-   if (status & UART_MSR_CTS)
-   ret |= TIOCM_CTS;
+   ret = UART_MSR_TO_TIOCM_DCD(status) | UART_MSR_TO_TIOCM_RI(status) |
+   UART_MSR_TO_TIOCM_DSR(status) | UART_MSR_TO_TIOCM_CTS(status);
+
return ret;
 }
 EXPORT_SYMBOL_GPL(serial8250_do_get_mctrl);
@@ -1983,16 +1976,9 @@ void serial8250_do_set_mctrl(struct uart_port *port, 
unsigned int mctrl)
struct uart_8250_port *up = up_to_u8250p(port);
unsigned char mcr = 0;
 
-   if (mctrl & TIOCM_RTS)

-   mcr |= UART_MCR_RTS;
-   if (mctrl & TIOCM_DTR)
-   mcr |= UART_MCR_DTR;
-   if (mctrl & TIOCM_OUT1)
-   mcr |= UART_MCR_OUT1;
-   if (mctrl & TIOCM_OUT2)
-   mcr |= UART_MCR_OUT2;
-   if (mctrl & TIOCM_LOOP)
-   mcr |= UART_MCR_LOOP;
+   mcr = TIOCM_TO_UART_MCR_RTS(mctrl) | TIOCM_TO_UART_MCR_DTR(mctrl) |
+   TIOCM_TO_UART_MCR_OUT1(mctrl) | TIOCM_TO_UART_MCR_OUT2(mctrl) |
+   TIOCM_TO_UART_MCR_LOOP(mctrl);
 
mcr = (mcr & up->mcr_mask) | up->mcr_force | up->mcr;
 
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h

index be07b5470f4b..bda905a1b765 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -376,5 +376,22 @@
 #define UART_ALTR_EN_TXFIFO_LW 0x01/* Enable the TX FIFO Low Watermark */
 #define UART_ALTR_TX_LOW   0x41/* Tx FIFO Low Watermark */
 
+#define UART_MSR_TO_TIOCM_DCD(val) ((val & UART_MSR_DCD) ? TIOCM_CAR : 0)

+#define UART_MSR_TO_TIOCM_RI(val)  ((val & UART_MSR_RI) ? TIOCM_RNG : 0)
+#define UART_MSR_TO_TIOCM_DSR(val) ((val & UART_MSR_DSR) ? TIOCM_DSR : 0)
+#define UART_MSR_TO_TIOCM_CTS(val) ((val & UART_MSR_CTS) ? TIOCM_CTS : 0)
+#define UART_MSR_TO_TIOCM_RTS(val) ((val & UART_MSR_RTS) ? TIOCM_RTS : 0)
+#define UART_MSR_TO_TIOCM_DTR(val) ((val & UART_MSR_DTR) ? TIOCM_DTR : 0)
+
+#define TIOCM_TO_UART_MCR_DCD(val)

Re: [PATCH v2] regulator: wm831x: Convert to use GPIO descriptors

2019-06-12 Thread Charles Keepax

On Wed, Jun 12, 2019 at 09:42:22AM +0200, Linus Walleij wrote:
> This converts the Wolfson Micro WM831x DCDC converter to use
> a GPIO descriptor for the GPIO driving the DVS pin.
> 
> There is just one (non-DT) machine in the kernel using this, and
> that is the Wolfson Micro (now Cirrus) Cragganmore 6410 so we
> patch this board to pass a descriptor table and fix up the driver
> accordingly.
> 
> Cc: Charles Keepax 
> Cc: Richard Fitzgerald 
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Use device name "wm831x-buckv.11" as described by Charles
> - Use devm_gpiod_get() rather than the optional variant
> ---

Acked-by: Charles Keepax 

Thanks,
Charles

Re: [PATCH v4 2/3] Revert "livepatch: Remove reliable stacktrace check in klp_try_switch_task()"

2019-06-12 Thread Petr Mladek

On Tue 2019-06-11 16:13:19, Miroslav Benes wrote:
> This reverts commit 1d98a69e5cef3aeb68bcefab0e67e342d6bb4dad. Commit
> 31adf2308f33 ("livepatch: Convert error about unsupported reliable
> stacktrace into a warning") weakened the enforcement for architectures
> to have reliable stack traces support. The system only warns now about
> it.
> 
> It only makes sense to reintroduce the compile time checking in
> klp_try_switch_task() again and bail out early.
> 
> Signed-off-by: Miroslav Benes 

Reviewed-by: Petr Mladek 

Best Regards,
Petr

[PATCH v2 2/3] drivers: media: i2c: don't enable if CONFIG_DRM_I2C_ADV7511=n

CONFIG_DRM_I2C_ADV7511 and CONFIG_VIDEO_ADV7511 bind to the same
platform device, so whichever driver gets loaded first will be used on
the device. So they shouldn't be enabled at the same time.

Rework so that VIDEO_ADV7511 and VIDEO_COBALT depends on
DRM_I2C_ADV7511=n or COMPILE_TEST.

Sugested-by: Hans Verkuil 
Signed-off-by: Anders Roxell 
---
 drivers/media/i2c/Kconfig| 1 +
 drivers/media/pci/cobalt/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 95d42730745c..79ce9ec6fc1b 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -511,6 +511,7 @@ config VIDEO_ADV7393
 config VIDEO_ADV7511
tristate "Analog Devices ADV7511 encoder"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   depends on DRM_I2C_ADV7511=n || COMPILE_TEST
select HDMI
help
  Support for the Analog Devices ADV7511 video encoder.
diff --git a/drivers/media/pci/cobalt/Kconfig b/drivers/media/pci/cobalt/Kconfig
index 6c6c60abe9b1..e0e7df460a92 100644
--- a/drivers/media/pci/cobalt/Kconfig
+++ b/drivers/media/pci/cobalt/Kconfig
@@ -3,7 +3,7 @@ config VIDEO_COBALT
tristate "Cisco Cobalt support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
depends on PCI_MSI && MTD_COMPLEX_MAPPINGS
-   depends on GPIOLIB || COMPILE_TEST
+   depends on (GPIOLIB && DRM_I2C_ADV7511=n) || COMPILE_TEST
depends on SND
depends on MTD
select I2C_ALGOBIT
-- 
2.20.1

[PATCH v2 3/3] drivers: media: coda: fix warning same module names

When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as
loadable modules, we see the following warning:

warning: same module names found:
  fs/coda/coda.ko
  drivers/media/platform/coda/coda.ko

Rework so media/platform/coda is named coda-vpu. Leaving CODA_FS as is
since that's a well known module.

Signed-off-by: Anders Roxell 
---
 drivers/media/platform/coda/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/Makefile 
b/drivers/media/platform/coda/Makefile
index 54e9a73a92ab..5fd5efa35159 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
-coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-mpeg2.o 
coda-mpeg4.o coda-jpeg.o
+coda-vpu-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-mpeg2.o 
coda-mpeg4.o coda-jpeg.o
 
-obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_CODA) += coda-vpu.o
 obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
-- 
2.20.1

Re: [PATCH v2 8/8] habanalabs: enable 64-bit DMA mask in POWER9

2019-06-12 Thread Benjamin Herrenschmidt

On Wed, 2019-06-12 at 15:45 +1000, Oliver O'Halloran wrote:
> 
> Also, are you sure about the MSI thing? The IODA3 spec says the only
> important bits for a 64bit MSI are bits 61:60 (to hit the window) and
> the lower bits that determine what IVE to use. Everything in between
> is ignored so ORing in bit 59 shouldn't break anything.

On IODA3... could be different on another system. My point is you can't
just have a fixed setting for all top bits for DMA & MSIs.

> > This will only work as long as all of the system memory can be
> > addressed at an offset from that fixed address that itself fits your
> > device addressing capabilities (50 bits in this case). It may or may
> > not be the case but there's no way to check since the DMA mask logic
> > won't really apply.
> > 
> > You might want to consider fixing your HW in the next iteration... This
> > is going to bite you when x86 increases the max physical memory for
> > example, or on other architectures.
> 
> Yes, do this. The easiest way to avoid this sort of wierd hack is to
> just design the PCIe interface to the spec in the first place.

Ben.

Re: [PATCH v2 8/8] habanalabs: enable 64-bit DMA mask in POWER9

2019-06-12 Thread Benjamin Herrenschmidt

On Wed, 2019-06-12 at 09:25 +0300, Oded Gabbay wrote:
> 
> > You can't. Your device is broken. Devices that don't support DMAing to
> > the full 64-bit deserve to be added to the trash pile.
> > 
> 
> Hmm... right know they are added to customers data-centers but what do I know 
> ;)

Well, some customers don't know they are being sold a lemon :)

> > As a result, getting it to work will require hacks. Some GPUs have
> > similar issues and require similar hacks, it's unfortunate.
> > 
> > Added a couple of guys on CC who might be able to help get those hacks
> > right.
> 
> Thanks :)
> > 
> > It's still very fishy .. the idea is to detect the case where setting a
> > 64-bit mask will give your system memory mapped at a fixed high address
> > (1 << 59 in our case) and program that in your chip in the "Fixed high
> > bits" register that you seem to have (also make sure it doesn't affect
> > MSIs or it will break them).
> 
> MSI-X are working. The set of bit 59 doesn't apply to MSI-X
> transactions (AFAICS from the PCIe controller spec we have).

Ok.

> > This will only work as long as all of the system memory can be
> > addressed at an offset from that fixed address that itself fits your
> > device addressing capabilities (50 bits in this case). It may or may
> > not be the case but there's no way to check since the DMA mask logic
> > won't really apply.
> 
> Understood. In the specific system we are integrated to, that is the
> case - we have less then 48 bits. But, as you pointed out, it is not a
> generic solution but with my H/W I can't give a generic fit-all
> solution for POWER9. I'll settle for the best that I can do.
> 
> > 
> > You might want to consider fixing your HW in the next iteration... This
> > is going to bite you when x86 increases the max physical memory for
> > example, or on other architectures.
> 
> Understood and taken care of.

Cheers,
Ben.

> > 
> > Cheers,
> > Ben.
> > 
> > 
> > 
> >

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

2019-06-12 Thread Wolfram Sang

On Tue, Jun 11, 2019 at 10:25:28AM +1000, Stephen Rothwell wrote:
> Hi Wolfram,
> 
> After merging the i2c tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> drivers/media/dvb-frontends/tua6100.c: In function 'tua6100_set_params':
> drivers/media/dvb-frontends/tua6100.c:71: warning: "_P" redefined
>  #define _P 32
>  
> In file included from include/acpi/platform/aclinux.h:54,
>  from include/acpi/platform/acenv.h:152,
>  from include/acpi/acpi.h:22,
>  from include/linux/acpi.h:21,
>  from include/linux/i2c.h:17,
>  from drivers/media/dvb-frontends/tua6100.h:22,
>  from drivers/media/dvb-frontends/tua6100.c:24:
> include/linux/ctype.h:14: note: this is the location of the previous 
> definition
>  #define _P 0x10 /* punct */
> 
> Exposed by commit
> 
>   5213d7efc8ec ("i2c: acpi: export i2c_acpi_find_adapter_by_handle")
> 
> Since that included  from 
> 
> Originally introduced by commit
> 
>   00be2e7c6415 ("V4L/DVB (4606): Add driver for TUA6100")
> 
> The _P in  has existed since before git.

I suggest to fix the driver by adding a TUA6100_ prefix to the defines.
I can cook up a patch for that.



signature.asc
Description: PGP signature

Re: Strange regression in hid_llogitech_dj (was: Re: Linux 5.2-rc4)

2019-06-12 Thread Rafael J. Wysocki

On Wednesday, June 12, 2019 12:02:21 AM CEST Jiri Kosina wrote:
> On Tue, 11 Jun 2019, Rafael J. Wysocki wrote:
> 
> > I noticed that the cordless mouse used by me with one of the machines here
> > stopped to work in 5.2-rc (up to and including the -rc4).
> > 
> > Bisection turned up commit 74808f9115ce ("HID: logitech-dj: add support for 
> > non
> > unifying receivers").
> > 
> > Of course, that commit does not revert cleanly from 5.2-rc4, but I have 
> > reverted
> > the changes made by it in hid/hid-ids.h and I took the version of 
> > hid/hid-logitech-dj.c
> > from commit b6aeeddef68d ("HID: logitech-dj: add 
> > logi_dj_recv_queue_unknown_work
> > helper"), which is the parent of commit 74808f9115ce, and that made the 
> > mouse
> > work again for me.
> > 
> > Here's the output of "dmesg | grep -i logitech" from 5.2-rc4 with the above 
> > changes:
> > 
> > [4.288905] usb 1-2: Manufacturer: Logitech
> > [5.444621] input: Logitech USB Receiver as 
> > /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C52F.0002/input/input23
> > [5.446960] hid-generic 0003:046D:C52F.0002: input,hidraw1: USB HID 
> > v1.11 Mouse [Logitech USB Receiver] on usb-:00:14.0-2/input0
> > [5.451265] input: Logitech USB Receiver Consumer Control as 
> > /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/0003:046D:C52F.0003/input/input24
> > [5.507545] hid-generic 0003:046D:C52F.0003: input,hiddev96,hidraw2: USB 
> > HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-2/input1
> 
> Hi Rafael,
> 
> 0x046d/0xc52f is known to have issues in 5.2-rcX. There is a patch queued 
> [1] that is believed to fix all this; my plan is to send it to Linus in 
> the coming 1-2 days. If you could report whether it fixes the issues 
> you've been seeing yourself as well, it'd be helpful.
> 
> Thanks.
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h=for-5.2/fixes&id=3ed224e273ac5880eeab4c3043a6b06b0478dd56

It kind of helps, but there is a catch.

hid-logitech-dj is not loaded after a fresh boot, so I need to modprobe it 
manually and that
appears to be blocking (apparently indefinitely) until terminated with ^C.  But 
then it turns
out that hid-logitech-dj is there in the list of modules and it is in use (by 
usbhid) and the
mouse works.

I guess I need to update the mkinitrd configuration, but even so that is not 
exactly
straightforward IMO. :-)

Cheers!

Re: [PATCH v2 3/3] drivers: media: coda: fix warning same module names

2019-06-12 Thread Philipp Zabel

On Wed, 2019-06-12 at 10:15 +0200, Anders Roxell wrote:
> When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as
> loadable modules, we see the following warning:
> 
> warning: same module names found:
>   fs/coda/coda.ko
>   drivers/media/platform/coda/coda.ko
> 
> Rework so media/platform/coda is named coda-vpu. Leaving CODA_FS as is
> since that's a well known module.
> 
> Signed-off-by: Anders Roxell 
> ---
>  drivers/media/platform/coda/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/coda/Makefile 
> b/drivers/media/platform/coda/Makefile
> index 54e9a73a92ab..5fd5efa35159 100644
> --- a/drivers/media/platform/coda/Makefile
> +++ b/drivers/media/platform/coda/Makefile
> @@ -1,6 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  
> -coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-mpeg2.o 
> coda-mpeg4.o coda-jpeg.o
> +coda-vpu-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o 
> coda-mpeg2.o coda-mpeg4.o coda-jpeg.o
>  
> -obj-$(CONFIG_VIDEO_CODA) += coda.o
> +obj-$(CONFIG_VIDEO_CODA) += coda-vpu.o

Thanks,
Reviewed-by: Philipp Zabel 

regards
Philipp

Re: [PATCH 2/2] mt76: mt7615: update peer's bssid when state transition changes

2019-06-12 Thread Lorenzo Bianconi

> Driver should update peer's bssid and bss information when
> state transition changes.
> 
> Signed-off-by: Ryder Lee 
> ---
>  .../net/wireless/mediatek/mt76/mt7615/main.c  |  5 +-
>  .../net/wireless/mediatek/mt76/mt7615/mcu.c   | 49 ++-
>  2 files changed, 27 insertions(+), 27 deletions(-)
> 

[...]

> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
> b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> index e82086eb8aa4..8fc12cd37906 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> @@ -741,17 +741,6 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>   u8 *buf, *data, tx_wlan_idx = 0;
>   struct req_hdr *hdr;
>  
> - if (en) {
> - len += sizeof(struct bss_info_omac);
> - features |= BIT(BSS_INFO_OMAC);
> - if (mvif->omac_idx > EXT_BSSID_START) {
> - len += sizeof(struct bss_info_ext_bss);
> - features |= BIT(BSS_INFO_EXT_BSS);
> - ntlv++;
> - }
> - ntlv++;
> - }
> -
>   switch (vif->type) {
>   case NL80211_IFTYPE_AP:
>   case NL80211_IFTYPE_MESH_POINT:
> @@ -759,22 +748,23 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>   conn_type = CONNECTION_INFRA_AP;
>   break;
>   case NL80211_IFTYPE_STATION: {
> - struct ieee80211_sta *sta;
> - struct mt7615_sta *msta;
> -
> - rcu_read_lock();
> -
> - sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
> - if (!sta) {
> + /* TODO: enable BSS_INFO_UAPSD & BSS_INFO_PM */
> + if (en) {
> + struct ieee80211_sta *sta;
> + struct mt7615_sta *msta;
> +
> + rcu_read_lock();
> + sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
> + if (!sta) {
> + rcu_read_unlock();
> + return -EINVAL;
> + }
> +
> + msta = (struct mt7615_sta *)sta->drv_priv;
> + tx_wlan_idx = msta->wcid.idx;
>   rcu_read_unlock();
> - return -EINVAL;
>   }
> -
> - msta = (struct mt7615_sta *)sta->drv_priv;
> - tx_wlan_idx = msta->wcid.idx;
>   conn_type = CONNECTION_INFRA_STA;
> -
> - rcu_read_unlock();
>   break;
>   }
>   default:
> @@ -782,6 +772,17 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>   break;
>   }
>  
> + if (en) {
> + len += sizeof(struct bss_info_omac);
> + features |= BIT(BSS_INFO_OMAC);
> + if (mvif->omac_idx > EXT_BSSID_START) {
> + len += sizeof(struct bss_info_ext_bss);
> + features |= BIT(BSS_INFO_EXT_BSS);
> + ntlv++;
> + }
> + ntlv++;
> + }

What did you move this chunk down?

Regards,
Lorenzo

> +
>   buf = kzalloc(len, GFP_KERNEL);
>   if (!buf)
>   return -ENOMEM;
> -- 
> 2.18.0
> 


signature.asc
Description: PGP signature

Re: [PATCH 2/2] edac: add support for Amazon's Annapurna Labs EDAC

2019-06-12 Thread Benjamin Herrenschmidt

On Wed, 2019-06-12 at 05:48 +0200, Borislav Petkov wrote:
> On Wed, Jun 12, 2019 at 08:25:52AM +1000, Benjamin Herrenschmidt wrote:
> > Yes, we would be in a world of pain already if tracepoints couldn't
> > handle concurrency :-)
> 
> Right, lockless buffer and the whole shebang :)

Yup.

> > Sort-of... I still don't see a race in what we propose but I might be
> > missing something subtle. We are talking about two drivers for two
> > different IP blocks updating different counters etc...
> 
> If you do only *that* you should be fine. That should technically be ok.

Yes, that' the point.

> I still think, though, that the sensible thing to do is have one
> platform driver which concentrates all RAS functionality. 

I tend to disagree here. We've been down that rabbit hole in the past
and we (Linux in general) are trying to move away from that sort of
"platform" overarching driver as much as possible.

> It is the
> more sensible design and takes care of potential EDAC shortcomings and
> the need to communicate between the different logging functionality,
> as in, for example, "I had so many errors, lemme go and increase DRAM
> scrubber frequency." For example. And all the other advantages of having
> everything in a single driver.

This is a policy. It should either belong to userspace, or be in some
generic RAS code in the kernel, there's no reason why these can't be
abstracted. Also in your specific example, it could be entirely local
to the MC EDAC / DRAM controller path, we could have a generic way for
EDAC to advertise that a given memory channel is giving lots of errors
and have memory controller drivers listen to it but usually the EDAC MC
driver *is* the only thing that looks like a MC driver to begin with,
so again, pretty much no overlap with L1/L2 caches RAS or PCIe RAS
etc...

> And x86 already does that - we even have a single driver for all AMD
> platforms - amd64_edac. Intel has a couple but there's still a lot of
> sharing.

Unless I'm mistaken, that amd64 EDAC is just an MC one... but I only
had a cursory glance at the code.

> But apparently ARM folks want to have one driver per IP block. And we
> have this discussion each time a new vendor decides to upstream its
> driver. And there's no shortage of vendors in ARM-land trying to do
> that.

For good reasons :-)

> James and I have tried to come up with a nice scheme to make that work
> on ARM and he has an example prototype here:
> 
> http://www.linux-arm.org/git?p=linux-jm.git;a=shortlog;h=refs/heads/edac_dummy/v1
>
> to show how it could look like.
> 
> But I'm slowly growing a serious aversion against having this very same
> discussion each time an ARM vendor sends a driver. And that happens
> pretty often nowadays.

Maybe because what you are promoting might not be the right path
here... seriously, there's a reason why all vendors want to go down
that path and in this case I don't think they are wrong.

This isn't about just another ARM vendor, in fact I'm rather new to the
whole ARM thing, I used to maintain arch/powerpc :-) The point is what
you are trying to push for goes against everything we've been trying to
do in Linux when it comes to splitting drivers to individual IP blocks.

Yes, in *some* cases coordination will be needed in which case there
are ways to do that that don't necessarily involve matching a driver to
the root of the DT, and a pseudo-device is in fact a very reasonable
way to do it, it was a common practice in IEEE1275 before I invented
the FDT, and we do that for a number of other things already.

Cheers,
Ben.

Re: [PATCH v2 1/6] clocksource/drivers/tegra: Restore timer rate on Tegra210

2019-06-12 Thread Jon Hunter



On 10/06/2019 17:43, Dmitry Osipenko wrote:
> The clocksource rate is initialized only for the first per-CPU clocksource
> and then that rate shall be replicated for the rest of clocksource's
> because they are initialized manually in the code.
> 
> Fixes: 3be2a85a0b61 ("Support per-CPU timers on all Tegra's")
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/clocksource/timer-tegra.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/clocksource/timer-tegra.c 
> b/drivers/clocksource/timer-tegra.c
> index 9406855781ff..830c66e2d927 100644
> --- a/drivers/clocksource/timer-tegra.c
> +++ b/drivers/clocksource/timer-tegra.c
> @@ -277,6 +277,8 @@ static int __init tegra_init_timer(struct device_node 
> *np, bool tegra20,
>*/
>   if (tegra20)
>   cpu_to->of_clk.rate = 100;
> + else
> + cpu_to->of_clk.rate = timer_of_rate(to);
>  
>   cpu_to = per_cpu_ptr(&tegra_to, cpu);
>   cpu_to->of_base.base = timer_reg_base + base;

Thanks. This fixes a boot regression we are seeing on -next with
Tegra210 (introduced by the commit referenced above). So ...

Acked-by: Jon Hunter 
Tested-by: Jon Hunter 

Cheers
Jon

-- 
nvpublic

Re: [PATCH v2 00/17] net: introduce Qualcomm IPA driver

2019-06-12 Thread Arnd Bergmann

On Tue, Jun 11, 2019 at 7:23 PM Dan Williams  wrote:
> On Tue, 2019-06-11 at 10:52 -0600, Subash Abhinov Kasiviswanathan wrote:
>
> rmnet should handle muxing the QMAP, QoS, and aggregation and pass the
> resulting packet to the lower layer. That lower layer could be IPA or
> qmi_wwan, which in turn passes that QMAP packet to USB or GSI or
> whatever. This is typically how Linux handles clean abstractions
> between different protocol layers in drivers.
>
> Similar to some WiFi drivers (drivers/net/wireless/marvell/libertas for
> example) where the same firmware interface can be accessed via PCI,
> SDIO, USB, SPI, etc. The bus-specific code is self-contained and does
> not creep into the upper more generic parts.

Yes, I think that is a good model. In case of libertas, we have multiple
layers inheritence from the basic device (slightly different in the
implementation,
but that is how it should be):

struct if_cs_card { /* pcmcia specific */
 struct lbs_private {  /* libertas specific */
   struct wireless_dev { /* 802.11 specific */
  struct net_device {
struct device {
  ...
};
...
  };
  ...
   };
   ...
  };
  ...
};

The outer structure gets allocated when probing the hardware specific
driver, and everything below it is implemented as direct function calls
into the more generic code, or as function pointers into the more specific
code.

The current rmnet model is different in that by design the upper layer
(rmnet) and the lower layer (qmi_wwan, ipa, ...) are kept independent in
both directions, i.e. ipa has (almost) no knowledge of rmnet, and just
has pointers to the other net_device:

   ipa_device
   net_device

   rmnet_port
   net_device

I understand that the rmnet model was intended to provide a cleaner
abstraction, but it's not how we normally structure subsystems in
Linux, and moving to a model more like how wireless_dev works
would improve both readability and performance, as you describe
it, it would be more like (ignoring for now the need for multiple
connections):

   ipa_dev
rmnet_dev
   wwan_dev
  net_device

Where each layer is a specialization of the next. Note: this is a
common change when moving from proprietary code to upstream
code. If a driver module is designed to live out of tree, there
is a strong incentive to limit the number of interfaces it uses,
but when it gets merged, it becomes much more flexible, as
an internal interface between wwan_dev and the hardware driver(s)
can be easily changed by modifying all drivers at once.

   Arnd

[v4,1/1] hwmon: (nct7904) Add extra sysfs support for fan, voltage and temperature.

2019-06-12 Thread Amy.Shih

From: "amy.shih" 

NCT-7904D also supports reading of channel limitation registers
and SMI status registers for fan, voltage and temperature monitoring,
and also supports reading of temperature sensor type which is thermal diode,
thermistor, AMD SB-TSI or Intel PECI, thus add below sysfs nodes:

-fan[1-*]_min
-fan[1-*]_alarm
-in[1-*]_min
-in[1-*]_max
-in[1-*]_alarm
-temp[1-*]_max
-temp[1-*]_max_hyst
-temp[1-*]_crit
-temp[1-*]_crit_hyst
-temp[1-*]_alarm
-temp[1-*]_type

Signed-off-by: amy.shih 
---
 drivers/hwmon/nct7904.c | 496 +++-
 1 file changed, 444 insertions(+), 52 deletions(-)

diff --git a/drivers/hwmon/nct7904.c b/drivers/hwmon/nct7904.c
index 5708171197e7..1e6b81f12ecb 100644
--- a/drivers/hwmon/nct7904.c
+++ b/drivers/hwmon/nct7904.c
@@ -46,10 +46,33 @@
 #define DTS_T_CTRL1_REG0x27
 #define VT_ADC_MD_REG  0x2E
 
+#define VSEN1_HV_LL_REG0x02/* Bank 1; 2 regs (HV/LV) per 
sensor */
+#define VSEN1_LV_LL_REG0x03/* Bank 1; 2 regs (HV/LV) per 
sensor */
+#define VSEN1_HV_HL_REG0x00/* Bank 1; 2 regs (HV/LV) per 
sensor */
+#define VSEN1_LV_HL_REG0x01/* Bank 1; 2 regs (HV/LV) per 
sensor */
+#define SMI_STS1_REG   0xC1/* Bank 0; SMI Status Register */
+#define SMI_STS5_REG   0xC5/* Bank 0; SMI Status Register */
+#define SMI_STS7_REG   0xC7/* Bank 0; SMI Status Register */
+#define SMI_STS8_REG   0xC8/* Bank 0; SMI Status Register */
+
 #define VSEN1_HV_REG   0x40/* Bank 0; 2 regs (HV/LV) per sensor */
 #define TEMP_CH1_HV_REG0x42/* Bank 0; same as VSEN2_HV */
 #define LTD_HV_REG 0x62/* Bank 0; 2 regs in VSEN range */
+#define LTD_HV_HL_REG  0x44/* Bank 1; 1 reg for LTD */
+#define LTD_LV_HL_REG  0x45/* Bank 1; 1 reg for LTD */
+#define LTD_HV_LL_REG  0x46/* Bank 1; 1 reg for LTD */
+#define LTD_LV_LL_REG  0x47/* Bank 1; 1 reg for LTD */
+#define TEMP_CH1_CH_REG0x05/* Bank 1; 1 reg for LTD */
+#define TEMP_CH1_W_REG 0x06/* Bank 1; 1 reg for LTD */
+#define TEMP_CH1_WH_REG0x07/* Bank 1; 1 reg for LTD */
+#define TEMP_CH1_C_REG 0x04/* Bank 1; 1 reg per sensor */
+#define DTS_T_CPU1_C_REG   0x90/* Bank 1; 1 reg per sensor */
+#define DTS_T_CPU1_CH_REG  0x91/* Bank 1; 1 reg per sensor */
+#define DTS_T_CPU1_W_REG   0x92/* Bank 1; 1 reg per sensor */
+#define DTS_T_CPU1_WH_REG  0x93/* Bank 1; 1 reg per sensor */
 #define FANIN1_HV_REG  0x80/* Bank 0; 2 regs (HV/LV) per sensor */
+#define FANIN1_HV_HL_REG   0x60/* Bank 1; 2 regs (HV/LV) per sensor */
+#define FANIN1_LV_HL_REG   0x61/* Bank 1; 2 regs (HV/LV) per sensor */
 #define T_CPU1_HV_REG  0xA0/* Bank 0; 2 regs (HV/LV) per sensor */
 
 #define PRTS_REG   0x03/* Bank 2 */
@@ -58,6 +81,8 @@
 #define FANCTL1_FMR_REG0x00/* Bank 3; 1 reg per channel */
 #define FANCTL1_OUT_REG0x10/* Bank 3; 1 reg per channel */
 
+#define ENABLE_TSI BIT(1)
+
 static const unsigned short normal_i2c[] = {
0x2d, 0x2e, I2C_CLIENT_END
 };
@@ -72,6 +97,7 @@ struct nct7904_data {
u8 fan_mode[FANCTL_MAX];
u8 enable_dts;
u8 has_dts;
+   u8 temp_mode; /* 0: TR mode, 1: TD mode */
 };
 
 /* Access functions */
@@ -170,6 +196,25 @@ static int nct7904_read_fan(struct device *dev, u32 attr, 
int channel,
rpm = 135 / cnt;
*val = rpm;
return 0;
+   case hwmon_fan_min:
+   ret = nct7904_read_reg16(data, BANK_1,
+FANIN1_HV_HL_REG + channel * 2);
+   if (ret < 0)
+   return ret;
+   cnt = ((ret & 0xff00) >> 3) | (ret & 0x1f);
+   if (cnt == 0x1fff)
+   rpm = 0;
+   else
+   rpm = 135 / cnt;
+   *val = rpm;
+   return 0;
+   case hwmon_fan_alarm:
+   ret = nct7904_read_reg(data, BANK_0,
+  SMI_STS7_REG + (channel >> 3));
+   if (ret < 0)
+   return ret;
+   *val = (ret >> (channel & 0x07)) & 1;
+   return 0;
default:
return -EOPNOTSUPP;
}
@@ -179,8 +224,20 @@ static umode_t nct7904_fan_is_visible(const void *_data, 
u32 attr, int channel)
 {
const struct nct7904_data *data = _data;
 
-   if (attr == hwmon_fan_input && data->fanin_mask & (1 << channel))
-   return 0444;
+   switch (attr) {
+   case hwmon_fan_input:
+   case hwmon_fan_alarm:
+   if (data->fanin_mask & (1 << channel))
+   return 0444;
+   break;
+   case hwmo

Re: [PATCH 3/4] mfd: madera: Fix potential uninitialised use of variable

On Mon, 20 May 2019, Charles Keepax wrote:

> From: Stuart Henderson 
> 
> regmap_read won't set val to anything if an ACKed bus fails.
> 
> Signed-off-by: Stuart Henderson 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/madera-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/4 RESEND] mfd: arizona: fix undefined behavior

On Mon, 20 May 2019, Charles Keepax wrote:

> From: Arnd Bergmann 
> 
> When the driver is used with a subdevice that is disabled in the
> kernel configuration, clang gets a little confused about the
> control flow and fails to notice that n_subdevs is only
> uninitialized when subdevs is NULL, and we check for that,
> leading to a false-positive warning:
> 
> drivers/mfd/arizona-core.c:1423:19: error: variable 'n_subdevs' is 
> uninitialized when used here
>   [-Werror,-Wuninitialized]
>   subdevs, n_subdevs, NULL, 0, NULL);
>^
> drivers/mfd/arizona-core.c:999:15: note: initialize the variable 'n_subdevs' 
> to silence this warning
> int n_subdevs, ret, i;
>  ^
>   = 0
> 
> Ideally, we would rearrange the code to avoid all those early
> initializations and have an explicit exit in each disabled case,
> but it's much easier to chicken out and add one more initialization
> here to shut up the warning.
> 
> Signed-off-by: Arnd Bergmann 
> Reviewed-by: Nathan Chancellor 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/arizona-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 2/4 RESEND] mfd: madera: Fix bad reference to pinctrl.txt file

On Mon, 20 May 2019, Charles Keepax wrote:

> From: Otto Sabart 
> 
> The pinctrl.txt file was converted into reStructuredText and moved into
> driver-api folder. This patch updates the broken reference.
> 
> Fixes: 5a9b73832e9e ("pinctrl.txt: move it to the driver-api book")
> Signed-off-by: Otto Sabart 
> Signed-off-by: Charles Keepax 
> ---
>  include/linux/mfd/madera/pdata.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: Strange regression in hid_llogitech_dj (was: Re: Linux 5.2-rc4)

2019-06-12 Thread Jiri Kosina

On Wed, 12 Jun 2019, Rafael J. Wysocki wrote:

> It kind of helps, but there is a catch.
> 
> hid-logitech-dj is not loaded after a fresh boot, so I need to modprobe it 
> manually and that
> appears to be blocking (apparently indefinitely) until terminated with ^C.  
> But then it turns
> out that hid-logitech-dj is there in the list of modules and it is in use (by 
> usbhid) and the
> mouse works.

My bad, I should've asked you to test with the complete 'for-5.2/fixes' 
branch which contains two reverts [1] [2] that should fix this issue as 
well.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h=for-5.2/fixes&id=e0b7f9bc0246bc642d1de2ff3ff133730584c956
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h=for-5.2/fixes&id=f9482dabfd1686987cc6044e06ae0e4c05915518

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 4/4] mfd: madera: Add supply mapping for MICVDD

On Mon, 20 May 2019, Charles Keepax wrote:

> Currently we are relying on the exact match of the regulator name to
> find MICVDD, we should add an explicit supply mapping to allow this to
> be found more reliably.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/madera-core.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2 2/3] HID: apple-ib-tb: Add driver for the Touch Bar on MacBook Pro's.

This driver enables basic touch bar functionality: enabling it, switching
between modes on FN key press, and dimming and turning the display
off/on when idle/active.

Signed-off-by: Ronald Tschalär 
---
 drivers/hid/Kconfig   |   10 +
 drivers/hid/Makefile  |1 +
 drivers/hid/apple-ib-tb.c | 1389 +
 3 files changed, 1400 insertions(+)
 create mode 100644 drivers/hid/apple-ib-tb.c

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 545d3691fc1c..7621c2500d71 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -149,6 +149,16 @@ config HID_APPLE_IBRIDGE
  To compile this driver as a module, choose M here: the
  module will be called apple-ibridge.
 
+config HID_APPLE_IBRIDGE_TB
+   tristate "Apple iBridge Touch Bar"
+   depends on HID_APPLE_IBRIDGE
+   ---help---
+   Say Y here if you want support for the Touch Bar on recent
+   MacBook Pros.
+
+   To compile this driver as a module, choose M here: the
+   module will be called apple-ib-tb.
+
 config HID_APPLEIR
tristate "Apple infrared receiver"
depends on (USB_HID)
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index a4da5663a541..0c46e5f70db1 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_HID_ALPS)+= hid-alps.o
 obj-$(CONFIG_HID_ACRUX)+= hid-axff.o
 obj-$(CONFIG_HID_APPLE)+= hid-apple.o
 obj-$(CONFIG_HID_APPLE_IBRIDGE)+= apple-ibridge.o
+obj-$(CONFIG_HID_APPLE_IBRIDGE_TB) += apple-ib-tb.o
 obj-$(CONFIG_HID_APPLEIR)  += hid-appleir.o
 obj-$(CONFIG_HID_ASUS) += hid-asus.o
 obj-$(CONFIG_HID_AUREAL)   += hid-aureal.o
diff --git a/drivers/hid/apple-ib-tb.c b/drivers/hid/apple-ib-tb.c
new file mode 100644
index ..6daee80060ce
--- /dev/null
+++ b/drivers/hid/apple-ib-tb.c
@@ -0,0 +1,1389 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Apple Touch Bar Driver
+ *
+ * Copyright (c) 2017-2018 Ronald Tschalär
+ */
+
+/*
+ * Recent MacBookPro models (13,[23] and 14,[23]) have a touch bar, which
+ * is exposed via several USB interfaces. MacOS supports a fancy mode
+ * where arbitrary buttons can be defined; this driver currently only
+ * supports the simple mode that consists of 3 predefined layouts
+ * (escape-only, esc + special keys, and esc + function keys).
+ *
+ * The first USB HID interface supports two reports, an input report that
+ * is used to report the key presses, and an output report which can be
+ * used to set the touch bar "mode": touch bar off (in which case no touches
+ * are reported at all), escape key only, escape + 12 function keys, and
+ * escape + several special keys (including brightness, audio volume,
+ * etc). The second interface supports several, complex reports, most of
+ * which are unknown at this time, but one of which has been determined to
+ * allow for controlling of the touch bar's brightness: off (though touches
+ * are still reported), dimmed, and full brightness. This driver makes
+ * use of these two reports.
+ */
+
+#define dev_fmt(fmt) "tb: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HID_UP_APPLE   0xff12
+#define HID_USAGE_MODE (HID_UP_CUSTOM | 0x0004)
+#define HID_USAGE_APPLE_APP(HID_UP_APPLE  | 0x0001)
+#define HID_USAGE_DISP (HID_UP_APPLE  | 0x0021)
+#define HID_USAGE_DISP_AUX1(HID_UP_APPLE  | 0x0020)
+
+#define APPLETB_MAX_TB_KEYS13  /* ESC, F1-F12 */
+
+#define APPLETB_CMD_MODE_ESC   0
+#define APPLETB_CMD_MODE_FN1
+#define APPLETB_CMD_MODE_SPCL  2
+#define APPLETB_CMD_MODE_OFF   3
+#define APPLETB_CMD_MODE_UPD   254
+#define APPLETB_CMD_MODE_NONE  255
+
+#define APPLETB_CMD_DISP_ON1
+#define APPLETB_CMD_DISP_DIM   2
+#define APPLETB_CMD_DISP_OFF   4
+#define APPLETB_CMD_DISP_UPD   254
+#define APPLETB_CMD_DISP_NONE  255
+
+#define APPLETB_FN_MODE_FKEYS  0
+#define APPLETB_FN_MODE_NORM   1
+#define APPLETB_FN_MODE_INV2
+#define APPLETB_FN_MODE_SPCL   3
+#define APPLETB_FN_MODE_MAXAPPLETB_FN_MODE_SPCL
+
+#define APPLETB_DEVID_KEYBOARD 1
+#define APPLETB_DEVID_TOUCHPAD 2
+
+#define APPLETB_MAX_DIM_TIME   30
+
+static int appletb_tb_def_idle_timeout = 5 * 60;
+module_param_named(idle_timeout, appletb_tb_def_idle_timeout, int, 0444);
+MODULE_PARM_DESC(idle_timeout, "Default touch bar idle timeout:\n"
+  ">0 - turn touch bar display off after no 
keyboard, trackpad, or touch bar input has been received for this many 
seconds;\n"
+  " the display will be turned back on as 
soon as new input is received\n"
+  " 0 - turn touch bar display off (input does 
not turn it on again)\n"
+  "-1 - turn touch bar display on (does not 
turn off automaticall

[PATCH v2 0/3] Apple iBridge support

2016 and 2017 MacBook Pro's have a T1 chip that drives the Touch Bar,
ambient light sensor, webcam, and fingerprint sensor; this shows up
as an iBridge USB device in the system. These patches provide initial
support for the Touch Bar and ALS - the webcam is already handled by
existing drivers, and no information is currently known on how to access
the fingerprint sensor (other than it's apparently via one of the extra
interfaces available in the OS X USB configuration).

One thing of note here is that both the ALS and (some of) the Touch Bar
functionality are exposed via the same USB interface (and hence same
hid_device), so both drivers need to share this device. This is solved
by having the iBridge driver create multiple virtual HID devices for
each real HID device to which the Touch Bar and ALS drivers attach, and 
then forwarding the calls between the real and virtual HID devices, so
we end up with a structure like this:

iBridge (HID) driverSub drivers

   --  vhdev0  --   (unbound)
  /
   hdev1  ---  vhdev1  ---  tb-drv
 /
   --  vhdev2  --
  /
   hdev2  ---  vhdev3  ---  als-drv


Changes in v2:
  - Changed iBridge driver from an MFD driver to a HID driver. Instead
of creating virtual HID drivers and (de)multiplexing their calls,
this now create virtual HID devices and (de)multiplexing the
operations on them. This is from the feedback by Benjamin Tissoires.
  - Applied all feedback on ALS driver from Jonathan Cameron
  - Applied all feedback on Touch Bar driver from Jonathan Cameron
and Peter Meerwald-Stadler
  - various smaller cleanups

Ronald Tschalär (3):
  HID: apple-ibridge: Add Apple iBridge HID driver.
  HID: apple-ib-tb: Add driver for the Touch Bar on MacBook Pro's.
  iio: light: apple-ib-als: Add driver for ALS on iBridge chip.

 drivers/hid/Kconfig  |   24 +
 drivers/hid/Makefile |2 +
 drivers/hid/apple-ib-tb.c| 1389 ++
 drivers/hid/apple-ibridge.c  |  588 +
 drivers/hid/hid-ids.h|1 +
 drivers/iio/light/Kconfig|   12 +
 drivers/iio/light/Makefile   |1 +
 drivers/iio/light/apple-ib-als.c |  607 +
 include/linux/apple-ibridge.h|   23 +
 9 files changed, 2647 insertions(+)
 create mode 100644 drivers/hid/apple-ib-tb.c
 create mode 100644 drivers/hid/apple-ibridge.c
 create mode 100644 drivers/iio/light/apple-ib-als.c
 create mode 100644 include/linux/apple-ibridge.h

-- 
2.21.0

[PATCH v2 1/3] HID: apple-ibridge: Add Apple iBridge HID driver.

The iBridge device provides access to several devices, including:
- the Touch Bar
- the iSight webcam
- the light sensor
- the fingerprint sensor

This driver provides the core support for managing the iBridge device
and the access to the underlying devices. In particular, since the
functionality for the touch bar and light sensor is exposed via USB HID
interfaces, and the same HID device is used for multiple functions, this
driver creates virtual HID devices, one per real HID device and
sub-driver pair (for a total of 4 virtual HID devices). The sub-drivers
then bind to these virtual HID devices.

This way the Touch Bar and ALS drivers can be kept in their own modules,
while at the same time making them look very much like as if they were
connected to the real HID devices; e.g. in particular the Touch Bar
driver is aware of the fact that it is dealing with two HID devices that
need to managed differently.

Signed-off-by: Ronald Tschalär 
---
 drivers/hid/Kconfig   |  14 +
 drivers/hid/Makefile  |   1 +
 drivers/hid/apple-ibridge.c   | 585 ++
 drivers/hid/hid-ids.h |   1 +
 include/linux/apple-ibridge.h |  23 ++
 5 files changed, 624 insertions(+)
 create mode 100644 drivers/hid/apple-ibridge.c
 create mode 100644 include/linux/apple-ibridge.h

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 4ca0cdfa6b33..545d3691fc1c 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -135,6 +135,20 @@ config HID_APPLE
Say Y here if you want support for keyboards of Apple iBooks, 
PowerBooks,
MacBooks, MacBook Pros and Apple Aluminum.
 
+config HID_APPLE_IBRIDGE
+   tristate "Apple iBridge"
+   depends on ACPI
+   depends on USB_HID
+   depends on X86 || COMPILE_TEST
+   help
+ This module provides the core support for the Apple T1 chip found
+ on recent MacBookPro's, also known as the iBridge. The drivers for
+ the Touch Bar (apple-ib-tb) and light sensor (apple-ib-als) need to
+ be enabled separately.
+
+ To compile this driver as a module, choose M here: the
+ module will be called apple-ibridge.
+
 config HID_APPLEIR
tristate "Apple infrared receiver"
depends on (USB_HID)
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 170163b41303..a4da5663a541 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_HID_ACCUTOUCH)   += hid-accutouch.o
 obj-$(CONFIG_HID_ALPS) += hid-alps.o
 obj-$(CONFIG_HID_ACRUX)+= hid-axff.o
 obj-$(CONFIG_HID_APPLE)+= hid-apple.o
+obj-$(CONFIG_HID_APPLE_IBRIDGE)+= apple-ibridge.o
 obj-$(CONFIG_HID_APPLEIR)  += hid-appleir.o
 obj-$(CONFIG_HID_ASUS) += hid-asus.o
 obj-$(CONFIG_HID_AUREAL)   += hid-aureal.o
diff --git a/drivers/hid/apple-ibridge.c b/drivers/hid/apple-ibridge.c
new file mode 100644
index ..565f080a38d6
--- /dev/null
+++ b/drivers/hid/apple-ibridge.c
@@ -0,0 +1,585 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Apple iBridge Driver
+ *
+ * Copyright (c) 2018 Ronald Tschalär
+ */
+
+/**
+ * DOC: Overview
+ *
+ * MacBookPro models with a Touch Bar (13,[23] and 14,[23]) have an Apple
+ * iBridge chip (also known as T1 chip) which exposes the touch bar,
+ * built-in webcam (iSight), ambient light sensor, and Secure Enclave
+ * Processor (SEP) for TouchID. It shows up in the system as a USB device
+ * with 3 configurations: 'Default iBridge Interfaces', 'Default iBridge
+ * Interfaces(OS X)', and 'Default iBridge Interfaces(Recovery)'. While
+ * the second one is used by MacOS to provide the fancy touch bar
+ * functionality with custom buttons etc, this driver just uses the first.
+ *
+ * In the first (default after boot) configuration, 4 usb interfaces are
+ * exposed: 2 related to the webcam, and 2 USB HID interfaces representing
+ * the touch bar and the ambient light sensor. The webcam interfaces are
+ * already handled by the uvcvideo driver; furthermore, the handling of the
+ * input reports when "keys" on the touch bar are pressed is already handled
+ * properly by the generic USB HID core. This leaves the management of the
+ * touch bar modes (e.g. switching between function and special keys when the
+ * FN key is pressed), the touch bar display (dimming and turning off), the
+ * key-remapping when the FN key is pressed, and handling of the light sensor.
+ *
+ * This driver is implemented as a HID driver that creates virtual HID devices
+ * for the ALS and touch bar functionality, and the ALS and touch bar drivers
+ * are HID drivers which in turn attach to these virtual HID devices. This
+ * driver then relays the calls on the real HID devices to the virtual ones,
+ * and visa versa.
+ *
+ * Lastly, this driver also takes care of the power-management for the
+ * iBridge when suspending and resuming.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include

[PATCH v2 3/3] iio: light: apple-ib-als: Add driver for ALS on iBridge chip.