Re: [PATCH 20/20] staging:rtl8192u: Rename OWN - Style

[Greg KH]

On Sat, Sep 01, 2018 at 12:02:50AM +0100, John Whitmore wrote:
> Rename the member variable 'OWN' to 'own', this is to comply with the
> coding standard, where variables are named in lowercase.
> 
> This is a simple coding style change which should have no impact on
> runtime code execution.
> 
> Signed-off-by: John Whitmore 
> ---
>  drivers/staging/rtl8192u/r8192U.h  | 2 +-
>  drivers/staging/rtl8192u/r8192U_core.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r8192U.h 
> b/drivers/staging/rtl8192u/r8192U.h
> index 68e82b32a88e..f963b664e221 100644
> --- a/drivers/staging/rtl8192u/r8192U.h
> +++ b/drivers/staging/rtl8192u/r8192U.h
> @@ -165,7 +165,7 @@ struct tx_desc_819x_usb {
>   u8  last_seg:1;
>   u8  first_seg:1;
>   u8  linip:1;
> - u8  OWN:1;
> + u8  own:1;
>  
>   /* DWORD 1 */
>   u8  TxFWInfoSize;
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
> index 911d0214b48a..4d0f70ec31ac 100644
> --- a/drivers/staging/rtl8192u/r8192U_core.c
> +++ b/drivers/staging/rtl8192u/r8192U_core.c
> @@ -1558,7 +1558,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
> *skb)
>   /* DWORD 0 */
>   tx_desc->first_seg = 1;
>   tx_desc->last_seg = 1;
> - tx_desc->OWN = 1;
> + tx_desc->own = 1;

Is this another case of a variable being set once and then never used?

If so, just delete it.

thanks,

greg k-h

Re: [PATCH 1/2] tools: include: Add PTR_ERR_OR_ZERO to err.h

[Arnaldo Carvalho de Melo]

Em Fri, Sep 07, 2018 at 09:34:41AM +0800, Ding Xiang escreveu:
> Add PTR_ERR_OR_ZERO, and tools can use it.

Thanks, applied the two patches.

- Arnaldo

Re: [PATCH 01/21] staging:rtl8192u: Rename AdvCoding - Style

[Greg KH]

On Wed, Aug 29, 2018 at 09:35:27PM +0100, John Whitmore wrote:
> Rename the bit field element AdvCoding, as it causes a checkpatch issue
> with CamelCase naming. As the element is not actually used in code it
> has been renamed to 'not_used_adv_coding'.
> 
> The single line of code which initialises the bit has been removed,
> as the  field is unused.
> 
> This is a purely coding style change which should have no impact
> on runtime code execution.
> 
> Signed-off-by: John Whitmore 
> ---
>  drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 2 +-
>  drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
> b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> index 64d5359cf7e2..66a0274077d3 100644
> --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> @@ -39,7 +39,7 @@ enum ht_extension_chan_offset {
>  
>  struct ht_capability_ele {
>   //HT capability info
> - u8  AdvCoding:1;
> + u8  not_used_adv_coding:1;
>   u8  ChlWidth:1;
>   u8  MimoPwrSave:2;
>   u8  GreenField:1;
> diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c 
> b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
> index 9bf52cebe4cd..d7f73a5831da 100644
> --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
> +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
> @@ -550,7 +550,6 @@ void HTConstructCapabilityElement(struct ieee80211_device 
> *ieee, u8 *posHTCap, u
>   }
>  
>   //HT capability info
> - pCapELE->AdvCoding  = 0; // This feature is not supported 
> now!!
>   if (ieee->GetHalfNmodeSupportByAPsHandler(ieee->dev))
>   pCapELE->ChlWidth = 0;
>   else

If a structure like this, which is not read/written to hardware
directly, has fields that are not really used at all, just delete them.
That's much easier than having to apply this patch, and a later patch
which deletes the usage.

thanks,

greg k-h

[PATCH v3 7/9] powerpc: enable building all dtbs

[Rob Herring]

Enable the 'dtbs' target for powerpc. This allows building all the dts
files in arch/powerpc/boot/dts/ when COMPILE_TEST and OF_ALL_DTBS are
enabled.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Rob Herring 
---
 arch/powerpc/boot/dts/Makefile | 5 +
 arch/powerpc/boot/dts/fsl/Makefile | 4 
 2 files changed, 9 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/fsl/Makefile

diff --git a/arch/powerpc/boot/dts/Makefile b/arch/powerpc/boot/dts/Makefile
index f66554cd5c45..fb335d05aae8 100644
--- a/arch/powerpc/boot/dts/Makefile
+++ b/arch/powerpc/boot/dts/Makefile
@@ -1 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
+
+subdir-y += fsl
+
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
diff --git a/arch/powerpc/boot/dts/fsl/Makefile 
b/arch/powerpc/boot/dts/fsl/Makefile
new file mode 100644
index ..3bae982641e9
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
-- 
2.17.1

[PATCH v3 0/9] Devicetree build consolidation

[Rob Herring]

This series addresses a couple of issues I have with building dts files.

First, the ability to build all the dts files in the tree. This has been
supported on most arches for some time with powerpc being the main
exception. The reason powerpc wasn't supported was it needed a change
in the location built dtb files are put.

Secondly, it's a pain to acquire all the cross-compilers needed to build
dtbs for each arch. There's no reason to build with the cross compiler and
the host compiler is perfectly fine as we only need the pre-processor.

I started addressing just those 2 problems, but kept finding small
differences such as target dependencies and dtbs_install support across
architectures. Instead of trying to align all these, I've consolidated the
build targets moving them out of the arch makefiles.

I'd like to take the series via the DT tree.

Rob

v3:
 - Rework dtc dependency to avoid 2 entry paths to scripts/dtc/. Essentially,
   I copied 'scripts_basic'.
 - Add missing scripts_basic dependency for dtc and missing PHONY tag.
 - Drop the '|' order only from dependencies
 - Drop %.dtb.S and %.dtb.o as top-level targets
 - PPC: remove duplicate mpc5200 dtbs from image-y targets

v2:
 - Fix $arch/boot/dts path check for out of tree builds
 - Fix dtc dependency for building built-in dtbs
 - Fix microblaze built-in dtb building
 - Add dtbs target for microblaze

Rob Herring (9):
  powerpc: build .dtb files in dts directory
  nios2: build .dtb files in dts directory
  nios2: use common rules to build built-in dtb
  nios2: fix building all dtbs
  c6x: use common built-in dtb support
  kbuild: consolidate Devicetree dtb build rules
  powerpc: enable building all dtbs
  c6x: enable building all dtbs
  microblaze: enable building all dtbs

 Makefile   | 35 ++-
 arch/arc/Makefile  |  6 
 arch/arm/Makefile  | 20 +--
 arch/arm64/Makefile| 17 +
 arch/c6x/Makefile  |  2 --
 arch/c6x/boot/dts/Makefile | 17 -
 arch/c6x/boot/dts/linked_dtb.S |  2 --
 arch/c6x/include/asm/sections.h|  1 -
 arch/c6x/kernel/setup.c|  4 +--
 arch/c6x/kernel/vmlinux.lds.S  | 10 --
 arch/h8300/Makefile| 11 +-
 arch/microblaze/Makefile   |  4 +--
 arch/microblaze/boot/dts/Makefile  |  4 +++
 arch/mips/Makefile | 15 +---
 arch/nds32/Makefile|  2 +-
 arch/nios2/Makefile| 11 +-
 arch/nios2/boot/Makefile   | 22 
 arch/nios2/boot/dts/Makefile   |  6 
 arch/nios2/boot/linked_dtb.S   | 19 ---
 arch/powerpc/Makefile  |  3 --
 arch/powerpc/boot/Makefile | 55 ++
 arch/powerpc/boot/dts/Makefile |  6 
 arch/powerpc/boot/dts/fsl/Makefile |  4 +++
 arch/xtensa/Makefile   | 12 +--
 scripts/Makefile   |  3 +-
 scripts/Makefile.lib   |  2 +-
 scripts/dtc/Makefile   |  2 +-
 27 files changed, 100 insertions(+), 195 deletions(-)
 delete mode 100644 arch/c6x/boot/dts/linked_dtb.S
 create mode 100644 arch/nios2/boot/dts/Makefile
 delete mode 100644 arch/nios2/boot/linked_dtb.S
 create mode 100644 arch/powerpc/boot/dts/Makefile
 create mode 100644 arch/powerpc/boot/dts/fsl/Makefile

--
2.17.1

[PATCH v3 3/9] nios2: use common rules to build built-in dtb

[Rob Herring]

Using the common build support for built-in dtb files just requires
adding a .dtb.o target to obj-y.

This has the side effect that CONFIG_NIOS2_DTB_SOURCE should now be just
the dts filename in arch/nios2/boot/dts/ directory. Before any path was
supported, but if you want to build in your dtb to the kernel, it should
be in the kernel tree.

Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
Signed-off-by: Rob Herring 
---
 arch/nios2/Makefile  |  6 ++
 arch/nios2/boot/Makefile | 14 --
 arch/nios2/boot/dts/Makefile |  2 ++
 arch/nios2/boot/linked_dtb.S | 19 ---
 4 files changed, 4 insertions(+), 37 deletions(-)
 delete mode 100644 arch/nios2/boot/linked_dtb.S

diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
index 50eece1c6adb..db2e78fe65c7 100644
--- a/arch/nios2/Makefile
+++ b/arch/nios2/Makefile
@@ -49,16 +49,14 @@ BOOT_TARGETS = vmImage zImage
 PHONY += $(BOOT_TARGETS) install
 KBUILD_IMAGE := $(nios2-boot)/vmImage
 
-ifneq ($(CONFIG_NIOS2_DTB_SOURCE),"")
-   core-y  += $(nios2-boot)/
-endif
+core-y += $(nios2-boot)/dts/
 
 all: vmImage
 
 archclean:
$(Q)$(MAKE) $(clean)=$(nios2-boot)
 
-%.dtb: | scripts
+%.dtb %.dtb.S %.dtb.o: | scripts
$(Q)$(MAKE) $(build)=$(nios2-boot)/dts $(nios2-boot)/dts/$@
 
 dtbs:
diff --git a/arch/nios2/boot/Makefile b/arch/nios2/boot/Makefile
index 007586094dde..0b48f1bf086d 100644
--- a/arch/nios2/boot/Makefile
+++ b/arch/nios2/boot/Makefile
@@ -31,20 +31,6 @@ $(obj)/zImage: $(obj)/compressed/vmlinux FORCE
 $(obj)/compressed/vmlinux: $(obj)/vmlinux.gz FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed $@
 
-# Rule to build device tree blobs
-DTB_SRC := $(patsubst "%",%,$(CONFIG_NIOS2_DTB_SOURCE))
-
-# Make sure the generated dtb gets removed during clean
-extra-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += system.dtb
-
-$(obj)/system.dtb: $(DTB_SRC) FORCE
-   $(call cmd,dtc)
-
-# Ensure system.dtb exists
-$(obj)/linked_dtb.o: $(obj)/system.dtb
-
-obj-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += linked_dtb.o
-
 targets += $(dtb-y)
 
 $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
diff --git a/arch/nios2/boot/dts/Makefile b/arch/nios2/boot/dts/Makefile
index f66554cd5c45..f6358e395b25 100644
--- a/arch/nios2/boot/dts/Makefile
+++ b/arch/nios2/boot/dts/Makefile
@@ -1 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
+
+obj-y := $(patsubst "%.dts",%.dtb.o,$(CONFIG_NIOS2_DTB_SOURCE))
diff --git a/arch/nios2/boot/linked_dtb.S b/arch/nios2/boot/linked_dtb.S
deleted file mode 100644
index 071f922db338..
--- a/arch/nios2/boot/linked_dtb.S
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * Copyright (C) 2011 Thomas Chou 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
- *
- */
-.section .dtb.init.rodata,"a"
-.incbin "arch/nios2/boot/system.dtb"
-- 
2.17.1

Re: [PATCH v6 3/3] staging: mt7621-mmc: Fix debug macro IRQ_MSG and its usages

[Greg Kroah-Hartman]

On Sat, Sep 01, 2018 at 03:51:10AM +0530, Nishad Kamdar wrote:
> Replace all usages of IRQ_MSG with with dev_ without __func__
> or __LINE__ or current->comm and current->pid. Remove the do {}
> while(0) loop for the single statement macro. Drop IRQ_MSG from dbg.h.
> Issue found by checkpatch.
> 
> Signed-off-by: Nishad Kamdar 
> ---
> Changes in v6:
>   - No change
> Changes in v5:
>   - No change
> ---
>  drivers/staging/mt7621-mmc/dbg.h | 12 ---
>  drivers/staging/mt7621-mmc/sd.c  | 36 
>  2 files changed, 27 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/staging/mt7621-mmc/dbg.h 
> b/drivers/staging/mt7621-mmc/dbg.h
> index 79914d98c573..4ab9f10dccc2 100644
> --- a/drivers/staging/mt7621-mmc/dbg.h
> +++ b/drivers/staging/mt7621-mmc/dbg.h
> @@ -102,18 +102,6 @@ do { \
>  } while (0)
>  #endif /* end of +++ */
>  
> -#if 1
> -//defined CONFIG_MTK_MMC_CD_POLL
> -#define IRQ_MSG(fmt, args...)

So right now this define does nothing, yet:

> -#else
> -/* PID in ISR in not corrent */
> -#define IRQ_MSG(fmt, args...) \
> -do { \
> - printk(KERN_ERR TAG"%d -> "fmt" <- %s() : L<%d>\n", \
> -host->id,  ##args, __FUNCTION__, __LINE__);  \
> -} while (0);
> -#endif
> -
>  void msdc_debug_proc_init(void);
>  
>  #if 0 /* --- chhung */
> diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
> index 7474f9ed7b5b..f3ae19fe0f76 100644
> --- a/drivers/staging/mt7621-mmc/sd.c
> +++ b/drivers/staging/mt7621-mmc/sd.c
> @@ -279,7 +279,9 @@ static void msdc_tasklet_card(struct work_struct *work)
>   mmc_detect_change(host->mmc, msecs_to_jiffies(20));
>   }
>  
> - IRQ_MSG("card found<%s>", inserted ? "inserted" : "removed");
> + dev_err(mmc_dev(host->mmc),
> + "%d -> card found<%s>\n",
> + host->id, inserted ? "inserted" : "removed");

You are now printing out lots of "errors" that really are not errors.

As these messages are not being printed at all right now, why not just
delete these as well?

Your first 2 patches do look good, I've queued them up now.

thanks,

greg k-h

[PATCH v3 8/9] c6x: enable building all dtbs

[Rob Herring]

Enable the 'dtbs' target for c6x. This allows building all the dts
files in arch/c6x/boot/dts/ for enabled platforms or when
COMPILE_TEST and OF_ALL_DTBS are enabled.

Cc: Mark Salter 
Cc: Aurelien Jacquiot 
Cc: linux-c6x-...@linux-c6x.org
Signed-off-by: Rob Herring 
---
 arch/c6x/boot/dts/Makefile | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/c6x/boot/dts/Makefile b/arch/c6x/boot/dts/Makefile
index fd937f781d16..f438285c3640 100644
--- a/arch/c6x/boot/dts/Makefile
+++ b/arch/c6x/boot/dts/Makefile
@@ -5,6 +5,12 @@
 
 DTC_FLAGS ?= -p 1024
 
+dtb-$(CONFIG_SOC_TMS320C6455) += dsk6455.dtb
+dtb-$(CONFIG_SOC_TMS320C6457) += evmc6457.dtb
+dtb-$(CONFIG_SOC_TMS320C6472) += evmc6472.dtb
+dtb-$(CONFIG_SOC_TMS320C6474) += evmc6474.dtb
+dtb-$(CONFIG_SOC_TMS320C6678) += evmc6678.dtb
+
 ifneq ($(DTB),)
 obj-y += $(DTB).dtb.o
 endif
-- 
2.17.1

[PATCH v3 9/9] microblaze: enable building all dtbs

[Rob Herring]

Enable the 'dtbs' target for microblaze. As microblaze only has one dts
file, always enable it.

Cc: Michal Simek 
Signed-off-by: Rob Herring 
---
 arch/microblaze/boot/dts/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/microblaze/boot/dts/Makefile 
b/arch/microblaze/boot/dts/Makefile
index fe9af267f598..c7324e74f9ef 100644
--- a/arch/microblaze/boot/dts/Makefile
+++ b/arch/microblaze/boot/dts/Makefile
@@ -1,6 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 #
 
+dtb-y := system.dtb
+
 ifneq ($(DTB),)
 obj-y += linked_dtb.o
 
-- 
2.17.1

[PATCH v3 5/9] c6x: use common built-in dtb support

[Rob Herring]

Using the common build support for built-in dtb files just requires
adding a .dtb.o target to obj-y.

The dtb now needs to be copied when unflattened because an init section
is used now.

Cc: Mark Salter 
Cc: Aurelien Jacquiot 
Cc: linux-c6x-...@linux-c6x.org
Signed-off-by: Rob Herring 
---
 arch/c6x/boot/dts/Makefile  | 11 +--
 arch/c6x/boot/dts/linked_dtb.S  |  2 --
 arch/c6x/include/asm/sections.h |  1 -
 arch/c6x/kernel/setup.c |  4 ++--
 arch/c6x/kernel/vmlinux.lds.S   | 10 --
 5 files changed, 3 insertions(+), 25 deletions(-)
 delete mode 100644 arch/c6x/boot/dts/linked_dtb.S

diff --git a/arch/c6x/boot/dts/Makefile b/arch/c6x/boot/dts/Makefile
index b212d278ebc4..fd937f781d16 100644
--- a/arch/c6x/boot/dts/Makefile
+++ b/arch/c6x/boot/dts/Makefile
@@ -6,14 +6,5 @@
 DTC_FLAGS ?= -p 1024
 
 ifneq ($(DTB),)
-obj-y += linked_dtb.o
+obj-y += $(DTB).dtb.o
 endif
-
-quiet_cmd_cp = CP  $< $@$2
-   cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false)
-
-# Generate builtin.dtb from $(DTB).dtb
-$(obj)/builtin.dtb: $(obj)/$(DTB).dtb
-   $(call if_changed,cp)
-
-$(obj)/linked_dtb.o: $(obj)/builtin.dtb
diff --git a/arch/c6x/boot/dts/linked_dtb.S b/arch/c6x/boot/dts/linked_dtb.S
deleted file mode 100644
index cf347f1d16ce..
--- a/arch/c6x/boot/dts/linked_dtb.S
+++ /dev/null
@@ -1,2 +0,0 @@
-.section __fdt_blob,"a"
-.incbin "arch/c6x/boot/dts/builtin.dtb"
diff --git a/arch/c6x/include/asm/sections.h b/arch/c6x/include/asm/sections.h
index d6c591ab5b7e..dc2f15eb3bde 100644
--- a/arch/c6x/include/asm/sections.h
+++ b/arch/c6x/include/asm/sections.h
@@ -8,6 +8,5 @@ extern char _vectors_start[];
 extern char _vectors_end[];
 
 extern char _data_lma[];
-extern char _fdt_start[], _fdt_end[];
 
 #endif /* _ASM_C6X_SECTIONS_H */
diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c
index 786e36e2f61d..509c5f086496 100644
--- a/arch/c6x/kernel/setup.c
+++ b/arch/c6x/kernel/setup.c
@@ -270,7 +270,7 @@ int __init c6x_add_memory(phys_addr_t start, unsigned long 
size)
 notrace void __init machine_init(unsigned long dt_ptr)
 {
void *dtb = __va(dt_ptr);
-   void *fdt = _fdt_start;
+   void *fdt = __dtb_start;
 
/* interrupts must be masked */
set_creg(IER, 2);
@@ -363,7 +363,7 @@ void __init setup_arch(char **cmdline_p)
 memory_end >> PAGE_SHIFT);
memblock_reserve(memory_start, bootmap_size);
 
-   unflatten_device_tree();
+   unflatten_and_copy_device_tree();
 
c6x_cache_init();
 
diff --git a/arch/c6x/kernel/vmlinux.lds.S b/arch/c6x/kernel/vmlinux.lds.S
index 1fba5b421eee..584bab2bace6 100644
--- a/arch/c6x/kernel/vmlinux.lds.S
+++ b/arch/c6x/kernel/vmlinux.lds.S
@@ -90,16 +90,6 @@ SECTIONS
*(.switch)
}
 
-   . = ALIGN (8) ;
-   __fdt_blob : AT(ADDR(__fdt_blob) - LOAD_OFFSET)
-   {
-   _fdt_start = . ;/* place for fdt blob */
-   *(__fdt_blob) ; /* Any link-placed DTB */
-   BYTE(0);/* section always has contents */
-   . = _fdt_start + 0x4000;/* Pad up to 16kbyte */
-   _fdt_end = . ;
-   }
-
_etext = .;
 
/*
-- 
2.17.1

[PATCH v3 4/9] nios2: fix building all dtbs

[Rob Herring]

nios2 has a 'dtbs' target, but nothing is added to 'dtb-*' targets and
no dtbs were getting built. This enables building all the dts files in
arch/nios2/boot/dts/ when COMPILE_TEST and OF_ALL_DTBS are enabled.

Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
Signed-off-by: Rob Herring 
---
 arch/nios2/boot/dts/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/nios2/boot/dts/Makefile b/arch/nios2/boot/dts/Makefile
index f6358e395b25..a91a0b09be63 100644
--- a/arch/nios2/boot/dts/Makefile
+++ b/arch/nios2/boot/dts/Makefile
@@ -1,3 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-y := $(patsubst "%.dts",%.dtb.o,$(CONFIG_NIOS2_DTB_SOURCE))
+
+dtstree:= $(srctree)/$(src)
+dtb-$(CONFIG_OF_ALL_DTBS) := $(patsubst $(dtstree)/%.dts,%.dtb, $(wildcard 
$(dtstree)/*.dts))
-- 
2.17.1

[PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules

[Rob Herring]

There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler preprocessor is perfectly fine for building dtbs. Move the
build rules to a common location and remove the arch specific ones. This
is done in a single step to avoid warnings about overriding rules.

The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
These pull in several dependencies some of which need a target compiler
(specifically devicetable-offsets.h) and aren't needed to build dtbs.
All that is really needed is dtc, so adjust the dependencies to only be
dtc.

This change enables support 'dtbs_install' on some arches which were
missing the target.

Acked-by: Will Deacon 
Acked-by: Paul Burton 
Acked-by: Ley Foon Tan 
Cc: Masahiro Yamada 
Cc: Michal Marek 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Yoshinori Sato 
Cc: Michal Simek 
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: linux-kbu...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: linux-m...@linux-mips.org
Cc: nios2-...@lists.rocketboards.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Signed-off-by: Rob Herring 
---
 Makefile  | 35 ++-
 arch/arc/Makefile |  6 --
 arch/arm/Makefile | 20 +-
 arch/arm64/Makefile   | 17 +--
 arch/c6x/Makefile |  2 --
 arch/h8300/Makefile   | 11 +-
 arch/microblaze/Makefile  |  4 +---
 arch/microblaze/boot/dts/Makefile |  2 ++
 arch/mips/Makefile| 15 +
 arch/nds32/Makefile   |  2 +-
 arch/nios2/Makefile   |  7 ---
 arch/nios2/boot/Makefile  |  4 
 arch/powerpc/Makefile |  3 ---
 arch/xtensa/Makefile  | 12 +--
 scripts/Makefile  |  3 +--
 scripts/Makefile.lib  |  2 +-
 scripts/dtc/Makefile  |  2 +-
 17 files changed, 46 insertions(+), 101 deletions(-)

diff --git a/Makefile b/Makefile
index 19948e556941..c43859eba70f 100644
--- a/Makefile
+++ b/Makefile
@@ -1071,7 +1071,7 @@ include/config/kernel.release: $(srctree)/Makefile FORCE
 # Carefully list dependencies so we do not try to build scripts twice
 # in parallel
 PHONY += scripts
-scripts: scripts_basic asm-generic gcc-plugins $(autoksyms_h)
+scripts: scripts_basic scripts_dtc asm-generic gcc-plugins $(autoksyms_h)
$(Q)$(MAKE) $(build)=$(@)
 
 # Things we need to do before we recursively start building the kernel
@@ -1215,6 +1215,33 @@ kselftest-merge:
$(srctree)/tools/testing/selftests/*/config
+$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
 
+# ---
+# Devicetree files
+
+ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
+dtstree := arch/$(SRCARCH)/boot/dts
+endif
+
+ifdef CONFIG_OF_EARLY_FLATTREE
+
+%.dtb : scripts_dtc
+   $(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
+
+PHONY += dtbs dtbs_install
+dtbs: scripts_dtc
+   $(Q)$(MAKE) $(build)=$(dtstree)
+
+dtbs_install: dtbs
+   $(Q)$(MAKE) $(dtbinst)=$(dtstree)
+
+all: dtbs
+
+endif
+
+PHONY += scripts_dtc
+scripts_dtc: scripts_basic
+   $(Q)$(MAKE) $(build)=scripts/dtc
+
 # ---
 # Modules
 
@@ -1424,6 +1451,12 @@ help:
@echo  '  kselftest-merge - Merge all the config dependencies of 
kselftest to existing'
@echo  '.config.'
@echo  ''
+   @$(if $(dtstree), \
+   echo 'Devicetree:'; \
+   echo '* dtbs- Build device tree blobs for enabled 
boards'; \
+   echo '  dtbs_install- Install dtbs to 
$(INSTALL_DTBS_PATH)'; \
+   echo '')
+
@echo 'Userspace tools targets:'
@echo '  use "make tools/help"'
@echo '  or  "cd tools; make help"'
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index fb026196aaab..5c7bc6d62f43 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -132,11 +132,5 @@ boot_targets += uImage uImage.bin uImage.gz
 $(boot_targets): vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
-%.dtb %.dtb.S %.dtb.o: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts $(boot)/dts/$@
-
-dtbs: scripts
-   $(Q)$(MAKE) $(build)=$(boot)/dts
-
 archclean:
$(Q)$(MAKE) $(clean)=$(boot)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d1516f85f25d..161c2df6567e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -307,

[PATCH v3 2/9] nios2: build .dtb files in dts directory

[Rob Herring]

Align nios2 with other architectures which build the dtb files in the
same directory as the dts files. This is also in line with most other
build targets which are located in the same directory as the source.
This move will help enable the 'dtbs' target which builds all the dtbs
regardless of kernel config.

This transition could break some scripts if they expect dtb files in
the old location.

Cc: Ley Foon Tan 
Cc: nios2-...@lists.rocketboards.org
Signed-off-by: Rob Herring 
---
 arch/nios2/Makefile  | 4 ++--
 arch/nios2/boot/Makefile | 4 
 arch/nios2/boot/dts/Makefile | 1 +
 3 files changed, 3 insertions(+), 6 deletions(-)
 create mode 100644 arch/nios2/boot/dts/Makefile

diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
index 8673a79dca9c..50eece1c6adb 100644
--- a/arch/nios2/Makefile
+++ b/arch/nios2/Makefile
@@ -59,10 +59,10 @@ archclean:
$(Q)$(MAKE) $(clean)=$(nios2-boot)
 
 %.dtb: | scripts
-   $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
+   $(Q)$(MAKE) $(build)=$(nios2-boot)/dts $(nios2-boot)/dts/$@
 
 dtbs:
-   $(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
+   $(Q)$(MAKE) $(build)=$(nios2-boot)/dts
 
 $(BOOT_TARGETS): vmlinux
$(Q)$(MAKE) $(build)=$(nios2-boot) $(nios2-boot)/$@
diff --git a/arch/nios2/boot/Makefile b/arch/nios2/boot/Makefile
index 2ba23a679732..007586094dde 100644
--- a/arch/nios2/boot/Makefile
+++ b/arch/nios2/boot/Makefile
@@ -47,10 +47,6 @@ obj-$(CONFIG_NIOS2_DTB_SOURCE_BOOL) += linked_dtb.o
 
 targets += $(dtb-y)
 
-# Rule to build device tree blobs with make command
-$(obj)/%.dtb: $(src)/dts/%.dts FORCE
-   $(call if_changed_dep,dtc)
-
 $(obj)/dtbs: $(addprefix $(obj)/, $(dtb-y))
 
 install:
diff --git a/arch/nios2/boot/dts/Makefile b/arch/nios2/boot/dts/Makefile
new file mode 100644
index ..f66554cd5c45
--- /dev/null
+++ b/arch/nios2/boot/dts/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0
-- 
2.17.1

Re: [PATCH 4.9 00/63] 4.9.126-stable review

[Shuah Khan]

On 09/07/2018 03:09 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.126 release.
> There are 63 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Sep  9 21:09:58 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.126-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH v2] mfd: arizona: Correct calling of runtime_put_sync

[Lee Jones]

On Tue, 21 Aug 2018, sapthagiri.bara...@gmail.com wrote:

> From: Sapthagiri Baratam 
> 
> Don't call runtime_put_sync when clk32k_ref is ARIZONA_32KZ_MCLK2
> as there is no corresponding runtime_get_sync call.
> 
> MCLK1 is not in the AoD power domain so if it is used as 32kHz clock
> source we need to hold a runtime PM reference to keep the device from
> going into low power mode.
> 
> fixes: cdd8da8cc66b ("mfd: arizona: Add gating of external MCLKn clocks")
> Signed-off-by: Sapthagiri Baratam 
> ---
> Changes in v2:
> - changed signed-off in commit message to full name
> 
>  drivers/mfd/arizona-core.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Applied, thanks.

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

Re: [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer

[Hans de Goede]

Hi,

On 10-09-18 16:57, Petr Mladek wrote:

On Fri 2018-09-07 13:21:32, Sergey Senozhatsky wrote:

On (09/06/18 16:28), Petr Mladek wrote:

On Thu 2018-09-06 16:29:40, Sergey Senozhatsky wrote:

On (09/05/18 13:02), Petr Mladek wrote:

Note that the first registered console prints all messages
even without this flag.


Hmm, OK, interesting point.

I assumed that the first console usually has CON_PRINTBUFFER bit set.
Or even a CON_PRINTBUFFER | CON_ANYTIME combo. E.g. 8250. It sort of
makes sense to have CON_PRINTBUFFER for the first console. Any later
consoles [e.g. fbcon, netcon] don't necessarily have CON_PRINTBUFFER.

And the first console has CON_PRINTBUFFER bit set. Well, just because
it sounds reasonable. Those were the main assumptions behind my code
snippet. Was any of those assumptions wrong?


This assumption makes sense. In fact, I was wrong. I thought that
console_seq/console_idx were not updated until the first console
was registered. But it is not the case.

It means that the hack with exclusive_console might be usable.


Yeah, it is a hack. But not as dirty as it might appear, I think. In some
sense it's aligned with what we do for exlusive_consoles - we treat exclusive
consoles specially. So specially that even if the system panics while we
re-flush logbuf messages to a new exclusive console, we flush_on_panic() only
to that exclusive console, ignoring the rest of them.


I consider this a bug. Another bug is that other consoles might miss
messages that appear while the older messages are being
replayed on exclusive_console.

AFAIK, nobody complains about it. But I not comfortable with reusing
this racy pattern even more ;-)



Not sure if it's totally right. There can be a netcon, for instance,
available, which will not see panic flush() because of a exclusive
console:


Good catch.


---

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c036f128cdc3..ede29a7ba6db 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2545,6 +2545,7 @@ void console_flush_on_panic(void)
 * ensure may_schedule is cleared.
 */
console_trylock();
+   exclusive_console = NULL;


This is not be enough. It would cause replying old messages
on all consoles.

Most problems should probably be solved when we store console_seq
before setting exclusive_console. Then we could clear
exclusive_console when reaching the stored sequence number.

Can this be that simple? ;-)



I prefer the revert for now.


OK, agreed.
IIRC I didn't see any upstream code which would have been fixed
by the commit in question.


My proposal for 4.19:


 From 46ceb577021c8899edd1977a52929b309a5ebf85 Mon Sep 17 00:00:00 2001
From: Petr Mladek 
Date: Mon, 10 Sep 2018 15:52:06 +0200
Subject: [PATCH] Revert "printk: make sure to print log on console."

This reverts commit 375899cddcbb26881b03cb3fbdcfd600e4e67f4a.

The visibility of early messages did not longer take into account
"quiet", "debug", and "loglevel" early parameters.

It would be possible to invalidate and recompute LOG_NOCONS flag
for the affected messages. But it would be hairy.

Instead this patch just reverts the problematic commit. We could
come up with a better solution for the original problem. For example,
we could simplify the logic and just mark messages that should always
be visible or always invisible on the console.

Also this patch does not put back the unused LOG_NOCONS flag.

Reported-by: Hans de Goede 
Signed-off-by: Petr Mladek 


Sounds like a good solution to me:

Acked-by: Hans de Goede 

Regards,

Hans




---
  kernel/printk/printk.c | 11 ---
  1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index fd6f8ed28e01..5fae295fcb75 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -351,7 +351,6 @@ static int console_msg_format = MSG_FORMAT_DEFAULT;
   */
  
  enum log_flags {

-   LOG_NOCONS  = 1,/* suppress print, do not print to console */
LOG_NEWLINE = 2,/* text ended with a newline */
LOG_PREFIX  = 4,/* text started with a prefix */
LOG_CONT= 8,/* text is a fragment of a continuation line */
@@ -1881,9 +1880,6 @@ int vprintk_store(int facility, int level,
if (dict)
lflags |= LOG_PREFIX|LOG_NEWLINE;
  
-	if (suppress_message_printing(level))

-   lflags |= LOG_NOCONS;
-
return log_output(facility, level, lflags,
  dict, dictlen, text, text_len);
  }
@@ -2368,10 +2364,11 @@ void console_unlock(void)
break;
  
  		msg = log_from_idx(console_idx);

-   if (msg->flags & LOG_NOCONS) {
+   if (suppress_message_printing(msg->level)) {
/*
-* Skip record if !ignore_loglevel, and
-* record has level above the console loglevel.
+* Skip record we have buffered an

Re: [PATCH 4.4 00/47] 4.4.155-stable review

[Shuah Khan]

On 09/07/2018 03:09 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.155 release.
> There are 47 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Sep  9 21:08:44 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.155-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH] locking/rwsem: Make owner store task pointer of last owning reader

[Waiman Long]

On 09/10/2018 05:31 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 04:18:34PM -0400, Waiman Long wrote:
>> Currently, when a reader acquires a lock, it only sets the
>> RWSEM_READER_OWNED bit in the owner field. The other bits are simply
>> not used. When debugging hanging cases involving rwsems and readers,
>> the owner value does not provide much useful information at all.
>>
>> This patch modifies the current behavior to always store the task_struct
>> pointer of the last rwsem-acquiring reader in a reader-owned rwsem. This
>> may be useful in debugging rwsem hanging cases especially if only one
>> reader is involved. However, the task in the owner field may not the
>> real owner or one of the real owners at all when the owner value is
>> examined, for example, in a crash dump. So it is just an additional
>> hint about the past history.
>>
>> If CONFIG_DEBUG_RWSEMS is enabled, the owner field will be checked at
>> unlock time too to make sure the task pointer value is valid. That does
>> have a slight performance cost and so is only enabled as part of that
>> debug option.
>>
>> From the performance point of view, it is expected that the changes
>> shouldn't have any noticeable performance impact. A rwsem microbenchmark
>> (with 48 worker threads and 1:1 reader/writer ratio) was ran on a
>> 2-socket 24-core 48-thread Haswell system.  The locking rates on a
>> 4.19-rc1 based kernel were as follows:
>>
>>   1) Unpatched kernel:   543.3 kops/s
>>   2) Patched kernel: 549.2 kops/s
>>   3) Patched kernel (CONFIG_DEBUG_RWSEMS on):546.6 kops/s
>>
>> There was actually a slight increase in performance (1.1%) in this
>> particular case. Maybe it was caused by the elimination of a branch or
>> just a testing noise. Turning on the CONFIG_DEBUG_RWSEMS option also
>> had less than the expected impact on performance.
>>
>> The least significant 2 bits of the owner value are now used to designate
>> the rwsem is readers owned and the owners are anonymous.
> So no immediate objection; but I'm still hoping to some day rewrite the
> whole rwsem thing along the lines we did mutex and merge the 'count' and
> 'owner' fields into one.
>
> [ RT has something along those lines, and I have half a patch that
>   starts doing that too, but I never found enough time to really work on
>   it :-( ]
>
> Anyway, when we do something like that, this goes out the window of
> course.

That may not be the case. I have also thought about merging owner and
count. For writer, it can write its owner value to the combined
count/owner. For readers, I think we will need to keep a reader count
and so cannot store its owner value there. In that case, we could have a
debug-only field for the reader-owner value.

One major issue with a combined count/owner is that we may have to use
cmpxchg for reader lock which will certainly impact reader-heavy
workloads. I have also thought about ways to compress the task pointer
address so that it can use fewer bits and leave the rests for reader
count. It is probably doable on 64-bit systems, but likely not on 32-bit
system given that there are less bits to play around.

I would certainly like to hear your thought on how to handle these
dilemmas as I may be able to find time to work on that. I had a reader
optimistic spinning patch that was sent out a while ago. I know it won't
get serious time for review until we can resolve this combine
owner/count issue first.

Cheers,
Longman

[RFC PATCH linux-next] btrfs: btrfs_run_delayed_refs_for_head() can be static

[kbuild test robot]

Fixes: ac75a14eb672 ("btrfs: Factor out loop processing all refs of a head")
Signed-off-by: kbuild test robot 
---
 extent-tree.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index b0882b6..719f1bb 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2537,9 +2537,9 @@ struct btrfs_delayed_ref_head *btrfs_obtain_ref_head(
 }
 
 STATIC
-int btrfs_run_delayed_refs_for_head(struct btrfs_trans_handle *trans,
-   struct btrfs_delayed_ref_head *locked_ref,
-   unsigned long *run_refs)
+static int btrfs_run_delayed_refs_for_head(struct btrfs_trans_handle *trans,
+  struct btrfs_delayed_ref_head 
*locked_ref,
+  unsigned long *run_refs)
 {
struct btrfs_fs_info *fs_info = trans->fs_info;
struct btrfs_delayed_ref_root *delayed_refs;

Re: [PATCH 3.18 00/29] 3.18.122-stable review

[Shuah Khan]

On 09/07/2018 03:10 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.122 release.
> There are 29 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Sep  9 21:08:52 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.122-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.19 regression fix] printk: For early boot messages check loglevel when flushing the buffer

[Petr Mladek]

On Fri 2018-09-07 13:21:32, Sergey Senozhatsky wrote:
> On (09/06/18 16:28), Petr Mladek wrote:
> > On Thu 2018-09-06 16:29:40, Sergey Senozhatsky wrote:
> > > On (09/05/18 13:02), Petr Mladek wrote:
> > > > Note that the first registered console prints all messages
> > > > even without this flag.
> > > 
> > > Hmm, OK, interesting point.
> > > 
> > > I assumed that the first console usually has CON_PRINTBUFFER bit set.
> > > Or even a CON_PRINTBUFFER | CON_ANYTIME combo. E.g. 8250. It sort of
> > > makes sense to have CON_PRINTBUFFER for the first console. Any later
> > > consoles [e.g. fbcon, netcon] don't necessarily have CON_PRINTBUFFER.
> > > 
> > > And the first console has CON_PRINTBUFFER bit set. Well, just because
> > > it sounds reasonable. Those were the main assumptions behind my code
> > > snippet. Was any of those assumptions wrong?
> > 
> > This assumption makes sense. In fact, I was wrong. I thought that
> > console_seq/console_idx were not updated until the first console
> > was registered. But it is not the case.
> > 
> > It means that the hack with exclusive_console might be usable.
> 
> Yeah, it is a hack. But not as dirty as it might appear, I think. In some
> sense it's aligned with what we do for exlusive_consoles - we treat exclusive
> consoles specially. So specially that even if the system panics while we
> re-flush logbuf messages to a new exclusive console, we flush_on_panic() only
> to that exclusive console, ignoring the rest of them.

I consider this a bug. Another bug is that other consoles might miss
messages that appear while the older messages are being
replayed on exclusive_console.

AFAIK, nobody complains about it. But I not comfortable with reusing
this racy pattern even more ;-)


> Not sure if it's totally right. There can be a netcon, for instance,
> available, which will not see panic flush() because of a exclusive
> console:

Good catch.

> ---
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index c036f128cdc3..ede29a7ba6db 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2545,6 +2545,7 @@ void console_flush_on_panic(void)
>* ensure may_schedule is cleared.
>*/
>   console_trylock();
> + exclusive_console = NULL;

This is not be enough. It would cause replying old messages
on all consoles.

Most problems should probably be solved when we store console_seq
before setting exclusive_console. Then we could clear
exclusive_console when reaching the stored sequence number.

Can this be that simple? ;-)


> > I prefer the revert for now.
> 
> OK, agreed.
> IIRC I didn't see any upstream code which would have been fixed
> by the commit in question.

My proposal for 4.19:


>From 46ceb577021c8899edd1977a52929b309a5ebf85 Mon Sep 17 00:00:00 2001
From: Petr Mladek 
Date: Mon, 10 Sep 2018 15:52:06 +0200
Subject: [PATCH] Revert "printk: make sure to print log on console."

This reverts commit 375899cddcbb26881b03cb3fbdcfd600e4e67f4a.

The visibility of early messages did not longer take into account
"quiet", "debug", and "loglevel" early parameters.

It would be possible to invalidate and recompute LOG_NOCONS flag
for the affected messages. But it would be hairy.

Instead this patch just reverts the problematic commit. We could
come up with a better solution for the original problem. For example,
we could simplify the logic and just mark messages that should always
be visible or always invisible on the console.

Also this patch does not put back the unused LOG_NOCONS flag.

Reported-by: Hans de Goede 
Signed-off-by: Petr Mladek 
---
 kernel/printk/printk.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index fd6f8ed28e01..5fae295fcb75 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -351,7 +351,6 @@ static int console_msg_format = MSG_FORMAT_DEFAULT;
  */
 
 enum log_flags {
-   LOG_NOCONS  = 1,/* suppress print, do not print to console */
LOG_NEWLINE = 2,/* text ended with a newline */
LOG_PREFIX  = 4,/* text started with a prefix */
LOG_CONT= 8,/* text is a fragment of a continuation line */
@@ -1881,9 +1880,6 @@ int vprintk_store(int facility, int level,
if (dict)
lflags |= LOG_PREFIX|LOG_NEWLINE;
 
-   if (suppress_message_printing(level))
-   lflags |= LOG_NOCONS;
-
return log_output(facility, level, lflags,
  dict, dictlen, text, text_len);
 }
@@ -2368,10 +2364,11 @@ void console_unlock(void)
break;
 
msg = log_from_idx(console_idx);
-   if (msg->flags & LOG_NOCONS) {
+   if (suppress_message_printing(msg->level)) {
/*
-* Skip record if !ignore_loglevel, and
-* record has level above the console loglevel.
+* Skip 

Re: [PATCH 08/21] microblaze: get cpu node with of_get_cpu_node

[Michal Simek]

On 5.9.2018 21:37, Rob Herring wrote:
> "device_type" use is deprecated for FDT though it has continued to be used
> for nodes like cpu nodes. Use of_get_cpu_node() instead which works using
> node names by default. This will allow the eventually removal of cpu
> device_type properties.
> 
> Also, fix a leaked reference by adding a missing of_node_put.
> 
> Cc: Michal Simek 
> Signed-off-by: Rob Herring 
> ---
> Please ack and I will take via the DT tree. This is dependent on the
> first 2 patches.

I have tested it and it is align with the spec and all dtses generated
before 2015 will work without any issue.
In 2015 new device tree generator was introduced and it is not adding
reg property to cpu node which is required by this change.
This will be fixed but that means that all generated dtses from 2015 are
affected.

That's why will be great if you can also change that pr_err message to
mentioned to also check reg property to give users a chance to fix it
properly. Error log below.

Anyway here is my
Tested-by: Michal Simek 

Thanks,
Michal


[0.00] Ramdisk addr 0x,
[0.00] Compiled-in FDT at (ptrval)
[0.00] Linux version 4.19.0-rc2-00010-gf9a96b0ac503
(monstr@monstr-desktop2) (gcc version 4.9.2 (crosstool-NG 1.20.0)) #4
Mon Sep 10 16:31:14 CEST 2018
[0.00] setup_memory: max_mapnr: 0x4
[0.00] setup_memory: min_low_pfn: 0x8
[0.00] setup_memory: max_low_pfn: 0xb
[0.00] setup_memory: max_pfn: 0xc
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x8000-0xafff]
[0.00]   Normal   empty
[0.00]   HighMem  [mem 0xb000-0xbfff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x8000-0xbfff]
[0.00] Initmem setup node 0 [mem
0x8000-0xbfff]
[0.00] earlycon: ns16550a0 at MMIO 0x44a01000 (options '')
[0.00] bootconsole [ns16550a0] enabled
[0.00] You don't have cpu!!!
[0.00] setup_cpuinfo: initialising
[0.00] setup_cpuinfo: Using full CPU PVR support
[0.00] ERROR: Microblaze BARREL, MSR, PCMP or DIV-different for
PVR and DTS
[0.00] ERROR: Microblaze HW_MUL-different for PVR and DTS
[0.00] wt_msr_noirq
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260608
[0.00] Kernel command line: console=ttyS0,115200 earlycon
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Memory: 1027496K/1048576K available (4270K kernel code,
153K rwdata, 1256K rodata, 4989K init, 561K bss, 21080K reserved, 0K
cma-reserved, 262144K highmem)
[0.00] Kernel virtual memory layout:
[0.00]   * 0xfffea000..0xf000  : fixmap
[0.00]   * 0xff80..0xffc0  : highmem PTEs
[0.00]   * 0xff7ff000..0xff80  : early ioremap
[0.00]   * 0xf000..0xff7ff000  : vmalloc & ioremap
[0.00] NR_IRQS: 33
[0.00] irq-xilinx: /amba_pl/interrupt-controller@4120:
num_irq=6, edge=0x0
[0.00] Oops: kernel access of bad area, sig: 11
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
4.19.0-rc2-00010-gf9a96b0ac503 #4
[0.00]  Registers dump: mode=80571E90
[0.00]  r1=C028BD54, r2=C056FAB6, r3=, r4=0010
[0.00]  r5=, r6=C0495348, r7=C0495350, r8=
[0.00]  r9=C0571F44, r10=EF002400, r11=0030, r12=
[0.00]  r13=410C2FC0, r14=C0496688, r15=C02831F0, r16=
[0.00]  r17=C02831EC, r18=, r19=C05BABE0, r20=BFFEC168
[0.00]  r21=BFFEC168, r22=EF7F9A80, r23=, r24=
[0.00]  r25=BFE6B84C, r26=8000, r27=0001, r28=9040
[0.00]  r29=0100, r30=0380, r31=C05782E8, rPC=C02831EC
[0.00]  msr=46A0, ear=000C, esr=1A72, fsr=65A0
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill
the idle task! ]---

Re: [PATCH v8 0/3]: perf: reduce data loss when profiling highly parallel CPU bound workloads

[Alexey Budankov]

Hi Ingo,

On 10.09.2018 15:06, Ingo Molnar wrote:
> 
> * Alexey Budankov  wrote:
> 
>> Hi Ingo,
>>
>> On 10.09.2018 12:18, Ingo Molnar wrote:
>>>
>>> * Alexey Budankov  wrote:
>>>

 Currently in record mode the tool implements trace writing serially. 
 The algorithm loops over mapped per-cpu data buffers and stores 
 ready data chunks into a trace file using write() system call.

 At some circumstances the kernel may lack free space in a buffer 
 because the other buffer's half is not yet written to disk due to 
 some other buffer's data writing by the tool at the moment.

 Thus serial trace writing implementation may cause the kernel 
 to loose profiling data and that is what observed when profiling 
 highly parallel CPU bound workloads on machines with big number 
 of cores.
>>>
>>> Yay! I saw this frequently on a 120-CPU box (hw is broken now).
>>>
 Data loss metrics is the ratio lost_time/elapsed_time where 
 lost_time is the sum of time intervals containing PERF_RECORD_LOST 
 records and elapsed_time is the elapsed application run time 
 under profiling.

 Applying asynchronous trace streaming thru Posix AIO API
 (http://man7.org/linux/man-pages/man7/aio.7.html) 
 lowers data loss metrics value providing 2x improvement -
 lowering 98% loss to almost 0%.
>>>
>>> Hm, instead of AIO why don't we use explicit threads instead? I think Posix 
>>> AIO will fall back 
>>> to threads anyway when there's no kernel AIO support (which there probably 
>>> isn't for perf 
>>> events).
>>
>> Explicit threading is surely an option but having more threads 
>> in the tool that stream performance data is a considerable 
>> design complication.
>>
>> Luckily, glibc AIO implementation is already based on pthreads, 
>> but having a writing thread for every distinct fd only.
> 
> My argument is, we don't want to rely on glibc's choices here. They might
> use a different threading design in the future, or it might differ between
> libc versions.> 
> The basic flow of tracing/profiling data is something we should control 
> explicitly,
> via explicit threading.

It may sound too optimistic but glibc API is expected to be backward compatible 
and for POSIX AIO API part too. Internal implementation also tends to evolve to 
better option overtime, more probably basing on modern kernel capabilities 
mentioned here: http://man7.org/linux/man-pages/man2/io_submit.2.html

Well, explicit threading in the tool for AIO, in the simplest case, means 
incorporating some POSIX API implementation into the tool, avoiding 
code reuse in the first place. That tends to be error prone and costly.

Regards,
Alexey

> 
> BTW., the usecase I was primarily concentrating on was a simpler one: 'perf 
> record -a', not 
> inherited workflow tracing. For system-wide profiling the ideal tracing setup 
> is clean per-CPU 
> separation, i.e. per CPU event fds, per CPU threads that read and then write 
> into separate 
> per-CPU files.
> 
> Thanks,
> 
>   Ingo
> 

Re: [PATCH v3] backlight: pwm_bl: switch to using "atomic" PWM API

[Lee Jones]

On Tue, 14 Aug 2018, Enric Balletbo i Serra wrote:

> The "atomic" API allows us to configure PWM period and duty_cycle and
> enable it in one call.
> 
> The patch also moves the pwm_init_state just before any use of the
> pwm_state struct, this fixes a potential bug where pwm_get_state
> can be called before pwm_init_state.
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
> Changes in v3:
> - Get rid of duty_cycle variable from pwm_backlight_update_status.
> - Get rid of pb->enabled and use only the status.enabled variable.
> - Make power_on match power_off.
> - Do not share status between ...update_status and ...power_on
> 
> Changes in v2:
> - Do not force the PWM be off in the first call to pwm_apply_state.
> - Delayed applying the state until we know what the period is.
> - Removed pb->period as after the conversion is not needed.
> 
>  drivers/video/backlight/pwm_bl.c | 81 +---
>  1 file changed, 42 insertions(+), 39 deletions(-)

Applied, thanks.

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

[RESEND] [PATCH] perf/x86/intel/uncore: Use boot_cpu_data.phys_proc_id instead of hardcorded phy id 0

[Masayoshi Mizuma]

From: Masayoshi Mizuma 

Physical package id 0 is not always exists. We should use
boot_cpu_data.phys_proc_id here.

Signed-off-by: Masayoshi Mizuma 
---
 arch/x86/events/intel/uncore_snbep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/uncore_snbep.c 
b/arch/x86/events/intel/uncore_snbep.c
index 51d7c11..53b981d 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -3061,7 +3061,7 @@ static struct event_constraint 
bdx_uncore_pcu_constraints[] = {
 
 void bdx_uncore_cpu_init(void)
 {
-   int pkg = topology_phys_to_logical_pkg(0);
+   int pkg = topology_phys_to_logical_pkg(boot_cpu_data.phys_proc_id);
 
if (bdx_uncore_cbox.num_boxes > boot_cpu_data.x86_max_cores)
bdx_uncore_cbox.num_boxes = boot_cpu_data.x86_max_cores;
-- 
2.18.0

Re: [PATCH] Revert "x86/tsc: Consolidate init code"

[Borislav Petkov]

On Mon, Sep 10, 2018 at 05:07:10PM +0300, Ville Syrjälä wrote:
> You're reading way too much into this. The revert is just a point to
> start the conversion. I've found that it's the best way to get the
> attention of the relevant developers. Other kind of regression
> reports have an unfortunate habit of disappearing into /dev/null.

That's some strange "logic".

You're sending a patch which has "[PATCH]" in the subject but now you
say it is not really a patch but only a way to get people's attention?!?

And nothing in it says so anywhere - it looks like an actual patch and
all.

If you do that a couple of times I'm afraid the opposite might happen -
such "patches" would get ignored completely.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 0/8] Introduce the for_each_set_clump macro

[Andy Shevchenko]

On Mon, Sep 10, 2018 at 09:54:47AM +0200, Linus Walleij wrote:
> On Wed, Sep 5, 2018 at 5:04 PM William Breathitt Gray
>  wrote:
> > On Wed, May 16, 2018 at 04:03:51PM +0200, Linus Walleij wrote:
> > >On Tue, May 15, 2018 at 6:22 PM, William Breathitt Gray
> > > wrote:
> > >
> > >> For example, suppose you would like to iterate over a 16-bit integer 4
> > >> bits at a time, skipping over 4-bit groups with no set bit, where 
> > >> represents the current 4-bit group:
> > >>
> > >> Example:1011 1110  
> > >> First loop: 1011 1110  
> > >> Second loop:1011   
> > >> Third loop:  1110  
> > >>
> > >> Each iteration of the loop returns the next 4-bit group that has at
> > >> least one set bit.
> > >>
> > >> The for_each_set_clump macro has six parameters:
> > >>
> > >> * clump: set to current clump index for the iteration
> > >> * index: set to current bitmap word index for the iteration
> > >> * offset: bits offset of the found clump in the bitmap word
> > >> * bits: bitmap to search within
> > >> * size: bitmap size in number of clumps
> > >> * clump_size: clump size in number of bits
> > >>
> > >> The clump_size argument can be an arbitrary number of bits and is not
> > >> required to be a multiple of 2.
> > >
> > >I must say I'm impressed. Very nice arithmetics going on there.
> > >
> > >If I can get some ACK for the bitops patch I'd be happy to merge
> > >it all through the GPIO tree. The users are pretty clear cut.
> > >
> > >BTW: if I could, I would pull out Donald Knuth's "The Art of Computer
> > >Programming vol 4A" chapter 7.1.3 "Bitwise Tricks and Techniques"
> > >to see what he has to say about the subject, but I don't have
> > >that book as it turns out.
> > >
> > >Yours,
> > >Linus Walleij
> >
> > Hi Linus,
> >
> > I'd like to get this patchset merged, but I'm aware that we haven't yet
> > received additional ACKs in the past couple months. Are there any
> > changes you would like made, or should I resubmit this patchset with
> > additional CCs in the hopes of some ACKs for the bitops patch?
> 
> It seems Andy wanted some time and he had ~4 months now
> so either he forgot it or has way too much to do.

Sorry, indeed, it got piled under huge backlog I have.

> 
> I would say send this patch to Andrew Morton (the bitops patches)
> so he can decide on it. He has the right bird's eye view on this
> kind of things.

Agreed, and please add Rasmus as well.


-- 
With Best Regards,
Andy Shevchenko

Re: [RFC][PATCH 8/8] really consolidate INIT_C_CC definitions

[Al Viro]

On Mon, Sep 10, 2018 at 03:33:45AM -1000, Linus Torvalds wrote:
> On Sun, Sep 9, 2018 at 6:52 PM Al Viro  wrote:
> >
> >  */
> > +#ifndef INIT_C_CC_VDISCARD
> > +#define INIT_C_CC_VDISCARD 'O'-0x40
> > +#endif
> 
> Just change everybody to do the same, nobody cares about VDISCARD.
> 
> We can change the value of VDISCARD because it doesn't actually have
> anything connected to it, so don't worry about "we used to have odd
> different values for it".

Point...  The following added and pushed:

commit 96202e4673cfd686b9812e5ab0790f907cd0
Author: Al Viro 
Date:   Mon Sep 10 10:42:59 2018 -0400

... and switch alpha/ppc/sparc to ^O for discard

it's
1) common for all other architectures
2) historical default for that thing and
3) ignored by the tty layer anyway.

Signed-off-by: Al Viro 

diff --git a/arch/alpha/include/asm/termios_internal.h 
b/arch/alpha/include/asm/termios_internal.h
index 07d5c1a6cdf6..c73cc96f96a3 100644
--- a/arch/alpha/include/asm/termios_internal.h
+++ b/arch/alpha/include/asm/termios_internal.h
@@ -2,8 +2,6 @@
 #ifndef _ALPHA_TERMIOS_H
 #define _ALPHA_TERMIOS_H
 
-#define INIT_C_CC_VDISCARD 'U'-0x40
-
 /*
  * Translate a "termio" structure into a "termios". Ugh.
  */
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b1402b1f1685..db0b6eebbfa5 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -223,7 +223,6 @@ config PPC
select HAVE_VIRT_CPU_ACCOUNTING
select HAVE_IRQ_TIME_ACCOUNTING
select HAVE_RSEQ
-   select HAS_TERMIOS_INTERNAL
select IOMMU_HELPER if PPC64
select IRQ_DOMAIN
select IRQ_FORCED_THREADING
diff --git a/arch/powerpc/include/asm/termios_internal.h 
b/arch/powerpc/include/asm/termios_internal.h
deleted file mode 100644
index 116b138ea232..
--- a/arch/powerpc/include/asm/termios_internal.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/*
- * Liberally adapted from alpha/termios.h.  In particular, the c_cc[]
- * fields have been reordered so that termio & termios share the
- * common subset in the same order (for brain dead programs that don't
- * know or care about the differences).
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-#ifndef _ASM_POWERPC_TERMIOS_H
-#define _ASM_POWERPC_TERMIOS_H
-
-#define INIT_C_CC_VDISCARD 'U'-0x40
-
-#endif /* _ASM_POWERPC_TERMIOS_H */
diff --git a/arch/sparc/include/asm/termios_internal.h 
b/arch/sparc/include/asm/termios_internal.h
index 1649a0cecda9..9d14a4bc40cf 100644
--- a/arch/sparc/include/asm/termios_internal.h
+++ b/arch/sparc/include/asm/termios_internal.h
@@ -13,8 +13,6 @@
 #define _VMIN  4
 #define _VTIME 5
 
-#define INIT_C_CC_VDISCARD 'U'-0x40
-
 /*
  * Translate a "termios" structure into a "termio". Ugh.
  *
diff --git a/include/linux/termios_internal.h b/include/linux/termios_internal.h
index 549715b18d22..f0bc26812548 100644
--- a/include/linux/termios_internal.h
+++ b/include/linux/termios_internal.h
@@ -11,14 +11,9 @@
 /* intr=^C quit=^\ erase=del   kill=^U
eof=^D  vtime=\0vmin=\1 sxtc=\0
start=^Qstop=^S susp=^Z eol=\0
-   reprint=^R  discard=^U  werase=^W   lnext=^V
+   reprint=^R  discard=^O  werase=^W   lnext=^V
eol2=\0
-   ... except that discard is actually ^O on most of them.
 */
-#ifndef INIT_C_CC_VDISCARD
-#define INIT_C_CC_VDISCARD 'O'-0x40
-#endif
-
 #ifdef VDSUSP
 #define INIT_C_CC_VDSUSP_EXTRA [VDSUSP] = 'Y'-0x40,
 #else
@@ -36,7 +31,7 @@
[VSTOP] = 'S'-0x40, \
[VSUSP] = 'Z'-0x40, \
[VREPRINT] = 'R'-0x40,  \
-   [VDISCARD] = INIT_C_CC_VDISCARD,\
+   [VDISCARD] = 'O'-0x40,  \
[VWERASE] = 'W'-0x40,   \
[VLNEXT] = 'V'-0x40,\
INIT_C_CC_VDSUSP_EXTRA  \

[PATCH] iio: proximity: Add driver support for ST's VL53L0X ToF ranging sensor.

[Song Qiang]

This driver was originally written by ST in 2016 as a misc input device,
and hasn't been maintained for a long time. I grabbed some code from
it's API and reformed it to a iio proximity device driver.
This version of driver uses i2c bus to talk to the sensor and
polling for measuring completes, so no irq line is needed.
This version of driver supports only one-shot mode, and it can be
tested with reading from
/sys/bus/iio/devices/iio:deviceX/in_distance_raw

Signed-off-by: Song Qiang 
---
 .../bindings/iio/proximity/vl53l0x.txt|  12 +
 drivers/iio/proximity/Kconfig |  13 +
 drivers/iio/proximity/Makefile|   2 +
 drivers/iio/proximity/vl53l0x-i2c.c   | 295 ++
 4 files changed, 322 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
 create mode 100644 drivers/iio/proximity/vl53l0x-i2c.c

diff --git a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt 
b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
new file mode 100644
index ..64b69442f08e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
@@ -0,0 +1,12 @@
+ST's VL53L0X ToF ranging sensor
+
+Required properties:
+   - compatible: must be "st,vl53l0x-i2c"
+   - reg: i2c address where to find the device
+
+Example:
+
+vl53l0x@29 {
+   compatible = "st,vl53l0x-i2c";
+   reg = <0x29>;
+};
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index f726f9427602..1563a5f9144d 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -79,4 +79,17 @@ config SRF08
  To compile this driver as a module, choose M here: the
  module will be called srf08.
 
+config VL53L0X_I2C
+   tristate "STMicroelectronics VL53L0X ToF ranger sensor (I2C)"
+   select IIO_BUFFER
+   select IIO_TRIGGERED_BUFFER
+   depends on I2C
+   help
+ Say Y here to build a driver for STMicroelectronics VL53L0X
+ ToF ranger sensors with i2c interface.
+ This driver can be used to measure the distance of objects.
+
+ To compile this driver as a module, choose M here: the
+ module will be called vl53l0x-i2c.
+
 endmenu
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 4f4ed45e87ef..7cb771665c8b 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_RFD77402)+= rfd77402.o
 obj-$(CONFIG_SRF04)+= srf04.o
 obj-$(CONFIG_SRF08)+= srf08.o
 obj-$(CONFIG_SX9500)   += sx9500.o
+obj-$(CONFIG_VL53L0X_I2C)  += vl53l0x-i2c.o
+
diff --git a/drivers/iio/proximity/vl53l0x-i2c.c 
b/drivers/iio/proximity/vl53l0x-i2c.c
new file mode 100644
index ..c00713041d30
--- /dev/null
+++ b/drivers/iio/proximity/vl53l0x-i2c.c
@@ -0,0 +1,295 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  vl53l0x-i2c.c - Support for STM VL53L0X FlightSense TOF
+ * Ranger Sensor on a i2c bus.
+ *
+ *  Copyright (C) 2016 STMicroelectronics Imaging Division.
+ *  Copyright (C) 2018 Song Qiang 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VL53L0X_DRV_NAME   "vl53l0x"
+
+/* Device register map */
+#define VL_REG_SYSRANGE_START  0x000
+#define VL_REG_SYSRANGE_MODE_MASK  0x0F
+#define VL_REG_SYSRANGE_MODE_START_STOP0x01
+#define VL_REG_SYSRANGE_MODE_SINGLESHOT0x00
+#define VL_REG_SYSRANGE_MODE_BACKTOBACK0x02
+#define VL_REG_SYSRANGE_MODE_TIMED 0x04
+#define VL_REG_SYSRANGE_MODE_HISTOGRAM 0x08
+
+#define VL_REG_SYS_THRESH_HIGH 0x000C
+#define VL_REG_SYS_THRESH_LOW  0x000E
+
+#define VL_REG_SYS_SEQUENCE_CFG0x0001
+#define VL_REG_SYS_RANGE_CFG   0x0009
+#define VL_REG_SYS_INTERMEASUREMENT_PERIOD 0x0004
+
+#define VL_REG_SYS_INT_CFG_GPIO0x000A
+#define VL_REG_SYS_INT_GPIO_DISABLED   0x00
+#define VL_REG_SYS_INT_GPIO_LEVEL_LOW  0x01
+#define VL_REG_SYS_INT_GPIO_LEVEL_HIGH 0x02
+#define VL_REG_SYS_INT_GPIO_OUT_OF_WINDOW  0x03
+#define VL_REG_SYS_INT_GPIO_NEW_SAMPLE_READY   0x04
+#define VL_REG_GPIO_HV_MUX_ACTIVE_HIGH 0x0084
+#define VL_REG_SYS_INT_CLEAR   0x000B
+
+/* Result registers */
+#define VL_REG_RESULT_INT_STATUS   0x0013
+#define VL_REG_RESULT_RANGE_STATUS 0x0014
+
+#define VL_REG_RESULT_CORE_PAGE  1
+#define VL_REG_RESULT_CORE_AMBIENT_WINDOW_EVENTS_RTN   0x00BC
+#define VL_RE

Re: [PATCH v5 07/12] PCI/MSI: enable PCI_MSI_IRQ_DOMAIN support for MIPS

[Jim Quinlan]

On Thu, Sep 6, 2018 at 5:46 PM Paul Burton  wrote:
>
> Hi Jim,
>
> On Thu, Sep 06, 2018 at 04:42:56PM -0400, Jim Quinlan wrote:
> > Add MIPS as an arch that supports PCI_MSI_IRQ_DOMAIN and add
> > generation of msi.h in the MIPS arch.
>
> I guess the second part of this probably became untrue after rebasing
> atop something including commit 34a4399f196c ("mips: use asm-generic
> version of msi.h"), and ought to be removed.
Hi Paul,

Yes, the second clause of this commit message will be removed.

Thanks,
Jim

>
> > Signed-off-by: Jim Quinlan 
> > ---
> >  drivers/pci/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Otherwise this looks fine:
>
> Acked-by: Paul Burton 
>
> Thanks,
> Paul

[PATCH v2] sched/fair: fix 1 task per CPU

[Vincent Guittot]

When CPUs have different capacity because of RT/DL tasks or
micro-architecture or max frequency differences, there are situation where
the imbalance is not correctly set to migrate waiting task on the idle CPU.

The UC uses the force_balance case :
if (env->idle != CPU_NOT_IDLE && group_has_capacity(env, local) &&
busiest->group_no_capacity)
goto force_balance;

But calculate_imbalance fails to set the right amount of load to migrate
a task because of the special condition:
  busiest->avg_load <= sds->avg_load || local->avg_load >= sds->avg_load)

Add in fix_small_imbalance, this special case that triggered the force
balance in order to make sure that the amount of load to migrate will be
enough.

Signed-off-by: Vincent Guittot 
---
 kernel/sched/fair.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 309c93f..72bc5e8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8048,6 +8048,20 @@ void fix_small_imbalance(struct lb_env *env, struct 
sd_lb_stats *sds)
local = &sds->local_stat;
busiest = &sds->busiest_stat;
 
+   /*
+* There is available capacity in local group and busiest group is
+* overloaded but calculate_imbalance can't compute the amount of load
+* to migrate because load_avg became meaningless due to asymetric
+* capacity between groups. In such case, we only want to migrate at
+* least one tasks of the busiest group and rely of the average load
+* per task to ensure the migration.
+*/
+   if (env->idle != CPU_NOT_IDLE && group_has_capacity(env, local) &&
+   busiest->group_no_capacity) {
+   env->imbalance = busiest->load_per_task;
+   return;
+   }
+
if (!local->sum_nr_running)
local->load_per_task = cpu_avg_load_per_task(env->dst_cpu);
else if (busiest->load_per_task > local->load_per_task)
-- 
2.7.4

Re: [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary

[Michal Hocko]

On Mon 10-09-18 14:32:16, Pavel Tatashin wrote:
> On Mon, Sep 10, 2018 at 10:19 AM Michal Hocko  wrote:
> >
> > On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> > > Hi Michal,
> > >
> > > It is tricky, but probably can be done. Either change
> > > memmap_init_zone() or its caller to also cover the ends and starts of
> > > unaligned sections to initialize and reserve pages.
> > >
> > > The same thing would also need to be done in deferred_init_memmap() to
> > > cover the deferred init case.
> >
> > Well, I am not sure TBH. I have to think about that much more. Maybe it
> > would be much more simple to make sure that we will never add incomplete
> > memblocks and simply refuse them during the discovery. At least for now.
> 
> On x86 memblocks can be upto 2G on machines with over 64G of RAM.

sorry I meant pageblock_nr_pages rather than memblocks.

> Also, memory size is way to easy too change via qemu arguments when VM
> starts. If we simply disable unaligned trailing memblocks, I am sure
> we would get tons of noise of missing memory.
> 
> I think, adding check_hotplug_memory_range() would work to fix the
> immediate problem. But, we do need to figure out  a better solution.
> 
> memblock design is based on archaic assumption that hotplug units are
> physical dimms. VMs and hypervisors changed all of that, and we can
> have much finer hotplug requests on machines with huge DIMMs. Yet, we
> do not want to pollute sysfs with millions of tiny memory devices. I
> am not sure what a long term proper solution for this problem should
> be, but I see that linux hotplug/hotremove subsystems must be
> redesigned based on the new requirements.

Not an easy task though. Anyway, sparse memory modely is highly based on
memory sections so it makes some sense to have hotplug section based as
well. Memblocks as a higher logical unit on top of that is kinda hack.
The userspace API has never been properly thought through I am afraid.
-- 
Michal Hocko
SUSE Labs

loop device: print_req_error - blk_update_request I/O error

[Egerváry Gergely]

Hi,

I'm mounting an ext4 filesystem residing on an AHCI SATA disk via loop:
  losetup -o 64424509440 --sizelimit 34359738368 /dev/loop0 /dev/sda
  mount -t ext4 /dev/loop0 /mnt

Works perfectly on <= 4.4.155 (latest version on 4.4.x longterm branch)

On 4.9.126 (longterm branch) I get these errors:
  blk_update_request: I/O error, /dev/loop0, sector 23778144
  blk_update_request: I/O error, /dev/loop0, sector 23789056
  blk_update_request: I/O error, /dev/loop0, sector 23791038
  ...

On 4.14.69 (longterm branch):
  print_req_error: I/O error, /dev/loop0, sector 22685550
  print_req_error: I/O error, /dev/loop0, sector 22696582
  print_req_error: I/O error, /dev/loop0, sector 22675034
  ...

and even on the latest stable 4.18.7:
  print_req_error: I/O error, /dev/loop0, sector 21044836
  print_req_error: I/O error, /dev/loop0, sector 22058444
  print_req_error: I/O error, /dev/loop0, sector 22858336
  ...

That's 100% reproducible on all my computers. They are amd64 desktop PCs
running unpatched vanilla kernels from kernel.org.

Any ideas?

I can provide more details if requested (.config, dmesg, etc.)
Thanks in advance.
--
Gergely EGERVARY

Re: mfd: cros_ec: Check for mkbp events on resume only if supported.

[Lee Jones]

On Mon, 20 Aug 2018, RaviChandra Sadineni wrote:

> Currently on every resume we check for mkbp events and notify the
> clients. This helps in identifying the wakeup sources. But on devices
> that do not support mkbp protocol, we might end up querying key state of
> the keyboard in a loop which blocks the resume. Instead check for events
> only if mkbp is supported.
> 
> Signed-off-by: RaviChandra Sadineni 
> ---
> 
>  Note: This patch fixes the suspend/resume issue on Snow and Peach-Pit
>  Chromebooks, both on vanilla v4.18 as well as linux-next from 20 August 
>  2018. Further info at: https://lkml.org/lkml/2018/6/5/1076
>  
>  drivers/mfd/cros_ec.c | 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: [PATCH v5 08/12] MIPS: BMIPS: add PCI bindings for 7425, 7435

[Jim Quinlan]

On Thu, Sep 6, 2018 at 5:50 PM Paul Burton  wrote:
>
> Hi Jim,
>
> On Thu, Sep 06, 2018 at 04:42:57PM -0400, Jim Quinlan wrote:
> > Adds the PCIe nodes for the Broadcom STB PCIe root complex.
> >
> > Signed-off-by: Jim Quinlan 
> > ---
> >  arch/mips/boot/dts/brcm/bcm7425.dtsi | 28 
> >  arch/mips/boot/dts/brcm/bcm7435.dtsi | 28 
> >  arch/mips/boot/dts/brcm/bcm97425svmb.dts |  4 
> >  arch/mips/boot/dts/brcm/bcm97435svmb.dts |  4 
> >  4 files changed, 64 insertions(+)
>
> Do you have a preference for how this gets merged? If it goes via the
> PCI tree then for patches 8 & 9:
>
> Acked-by: Paul Burton 
>
Hi Paul,

I hope that the 12 commits  go together and will go through the PCI
tree.  I'm inclined to think I will have to do a V6, and in the cover
leter I will mention this request.

Thanks!
Jim

> Still looking at patch 6.
>
> Thanks,
> Paul

Re: [PATCH v6 1/2] dt-bindings: leds: Add bindings for lm3697 driver

[Dan Murphy]

Jacek

On 09/08/2018 02:53 PM, Jacek Anaszewski wrote:
> Dan,
> 
> On 09/07/2018 03:52 PM, Dan Murphy wrote:
> [...]
>>>
 And I think Jacek pointed out that the bindings references in this bindings
 don't even exist.

 I am thinking we need to deprecate this MFD driver and consolidate these 
 drivers
 in the LED directory as we indicated before.  I did not find any ti-lmu 
 support
 code.

 ti-lmu common core code and then the LED children appending the feature 
 differentiation.
>>>
 Need some maintainer weigh in here.
>>>
>>> Hehe. I'm maintnainer. Fun.
>>
>> I know.  I want to see if there was any other opinion.  Especially for the 
>> LED driver.
>>
> [...]
> 
> I have a question - is this lm3697 LED controller a cell of some MFD
> device? Or is it a self-contained chip?
> 

This is a self contained chip.  And the LM3697 only function is a LED driver.
It does not have any other special functions like the LM363X drivers for GPIO 
and Regulator support.


Dan

-- 
--
Dan Murphy

Re: [PATCH V2] perf tools: Fix maps__find_symbol_by_name()

[Arnaldo Carvalho de Melo]

Em Fri, Sep 07, 2018 at 11:51:16AM +0300, Adrian Hunter escreveu:
> Commit 1c5aae7710bb ("perf machine: Create maps for x86 PTI entry
> trampolines") revealed a problem with maps__find_symbol_by_name() that

Can we have this with a Fixes: 1c5aae7710bb?

So that that, combined with the CC: stable, tells which stable kernels
should get that fix, I think there are scripts harvesting Fixes: tags to
help stable maintainers :-)

- Arnaldo

> resulted in probes not being found e.g.
> 
>   $ sudo perf probe xsk_mmap
>   xsk_mmap is out of .text, skip it.
>   Probe point 'xsk_mmap' not found.
>  Error: Failed to add events.
> 
> maps__find_symbol_by_name() can optionally return the map of the found
> symbol. It can get the map wrong because, in fact, the symbol is found
> on the map's dso, not allowing for the possibility that the dso has more
> than one map. Fix by always checking the map contains the symbol.
> 
> Reported-by: Björn Töpel 
> Tested-by: Björn Töpel 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Adrian Hunter 
> ---
> 
> 
> Changes in V2:
> 
>   Expanded commit message
>   Corrected email address
> 
> 
>  tools/perf/util/map.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index 3f07a587c8e6..354e54550d2b 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -574,6 +574,13 @@ struct symbol *map_groups__find_symbol(struct map_groups 
> *mg,
>   return NULL;
>  }
>  
> +static bool map__contains_symbol(struct map *map, struct symbol *sym)
> +{
> + u64 ip = map->unmap_ip(map, sym->start);
> +
> + return ip >= map->start && ip < map->end;
> +}
> +
>  struct symbol *maps__find_symbol_by_name(struct maps *maps, const char *name,
>struct map **mapp)
>  {
> @@ -589,6 +596,10 @@ struct symbol *maps__find_symbol_by_name(struct maps 
> *maps, const char *name,
>  
>   if (sym == NULL)
>   continue;
> + if (!map__contains_symbol(pos, sym)) {
> + sym = NULL;
> + continue;
> + }
>   if (mapp != NULL)
>   *mapp = pos;
>   goto out;
> -- 
> 2.17.1

Re: [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary

[Pasha Tatashin]

On Mon, Sep 10, 2018 at 10:19 AM Michal Hocko  wrote:
>
> On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> > Hi Michal,
> >
> > It is tricky, but probably can be done. Either change
> > memmap_init_zone() or its caller to also cover the ends and starts of
> > unaligned sections to initialize and reserve pages.
> >
> > The same thing would also need to be done in deferred_init_memmap() to
> > cover the deferred init case.
>
> Well, I am not sure TBH. I have to think about that much more. Maybe it
> would be much more simple to make sure that we will never add incomplete
> memblocks and simply refuse them during the discovery. At least for now.

On x86 memblocks can be upto 2G on machines with over 64G of RAM.
Also, memory size is way to easy too change via qemu arguments when VM
starts. If we simply disable unaligned trailing memblocks, I am sure
we would get tons of noise of missing memory.

I think, adding check_hotplug_memory_range() would work to fix the
immediate problem. But, we do need to figure out  a better solution.

memblock design is based on archaic assumption that hotplug units are
physical dimms. VMs and hypervisors changed all of that, and we can
have much finer hotplug requests on machines with huge DIMMs. Yet, we
do not want to pollute sysfs with millions of tiny memory devices. I
am not sure what a long term proper solution for this problem should
be, but I see that linux hotplug/hotremove subsystems must be
redesigned based on the new requirements.

Pavel

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

[Anup Patel]

On Mon, Sep 10, 2018 at 7:19 PM, Christoph Hellwig  wrote:
> On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
>> > He has an irqchip that is called from the RISC-V exception handler
>> > when the interrupt flag is set in scause and then dispatches to one
>> > of:  IPI, timer, actual irqchip.
>>
>> So the per cpu timer is the only per cpu interrupt and that thing is used
>> unconditionally, right?
>
> Yes.  external is chained and IPI is still handled explicitly.

On riscv64, there are 64 local interrupts (i.e. per-CPU interrupts).

Three of these local interrupts have clearly defined use:
1. Software interrupt (inter-processor interrupt)
2. External interrupt (interrupt from PLIC)
3. Timer interrupt (interrupt from per-CPU timer)

Other local interrupts are available for future use.

Taking inspiration from ARM world, I had give quite a few
examples how these RISC-V local interrupts can be used
for other purposes:
1. per-CPU interrupt for per-HART performance monitoring unit
2. interrupt controller virtualizaton extension can use per-CPU
interrupts for managing resources (just like ARM GICv2/v3 virt
extensions)
3. bus errors can be reported as per-CPU interrupts

Considering above, it is better to have a distinct irqchip and
irq_domain for all local interrupts (just like this patch).

Regards,
Anup

Re: [PATCH] mm: Use BUG_ON directly instead of a if condition followed by BUG

[Michal Hocko]

On Mon 10-09-18 22:03:17, zhong jiang wrote:
> The if condition can be removed if we use BUG_ON directly.
> The issule is detected with the help of Coccinelle.

typo here

Is this really worth changing? If anything I would really love to see
the BUG_ON going away rather than make a cosmetic changes to it.

> Signed-off-by: zhong jiang 
> ---
>  mm/memory_hotplug.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 38d94b7..280b26c 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1888,8 +1888,7 @@ void __ref remove_memory(int nid, u64 start, u64 size)
>*/
>   ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL,
>   check_memblock_offlined_cb);
> - if (ret)
> - BUG();
> + BUG(ret);
>  
>   /* remove memmap entry */
>   firmware_map_remove(start, start + size, "System RAM");
> -- 
> 1.7.12.4
> 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH V3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[dkota]

On 2018-09-10 16:56, Mark Brown wrote:

On Mon, Sep 10, 2018 at 09:27:09AM +0530, dk...@codeaurora.org wrote:


> The thing is, we want it to be 100% reliable, not 99.9% reliable.  Is
> it somehow wrong to add the spinlock?  ...or are you noticing
> performance problems with the spinlock there?  It's just nice not to
> have to think about it.


As I said, timeout will be handled after the calculated time as per 
data
size and speed. Enough time is given for interrupt, there is no chance 
of
interrupt occurrence during the handle_fifo_timeout(). So there is no 
need

of spinlock.


Assuming nothing goes wrong - the system isn't under unusually heavy
load for example, there's some oversight in the code, there's no impact
from power management causing things to run more slowly than you were
expecting, someone uses the driver on a new bit of hardware where there
are extra considerations or whatever else might go wrong.  Like Doug
says unless we're in some performance critical situation where it's
worth thinking *really* hard about how things really are actually safe
even though they might not look it it's both easier and more
maintainable to just write software that's obviously safe to 
inspection.


Agree with this perspective. There wont be any performance impact with 
spinlock. I will include the spinlock in the code.

Re: [PATCH] sched/fair: fix 1 task per CPU

[Vincent Guittot]

On Sat, 8 Sep 2018 at 22:17, Valentin Schneider
 wrote:
>
> Hi Vincent,
>
> On 07/09/18 08:40, Vincent Guittot wrote:
> > When CPUs have different capacity because of RT/DL tasks or
> > micro-architecture or max frequency differences, there are situation where
> > the imbalance is not correctly set to migrate waiting task on the idle CPU.
> >
>
> This is essentially always for down migrations (high capacity src CPU to lower
> capacity dst CPU), right?

At least for the UC that I have created

>
> For instance, I've often seen that issue on HiKey960 (4x4 big.LITTLE) where
> if you spawn 8 CPU-hogs you can end up with 5 on the bigs and 3 on the
> LITTLES, but since avg_load scales with the inverse of group_capacity it's
> seen as balanced. I don't recall seeing this problem for low capacity ->
> big capacity migration, especially with the misfit logic that makes this a
> non-problem.
>
> Also, a nit on the commit header: although we've called it "1 task per CPU"
> in the past, it might be more explicit to call it "1 long running task per
> CPU", if just for the sake of clarity for people not directly involved in
> our previous discussions.

In fact it's not only long running task, I can reproduce the problem
with 1 task with a load of 30%

The problem comes from busiest->avg_load <= sds->avg_load ||
local->avg_load >= sds->avg_load

>
> > The UC uses the force_balance case :
> >   if (env->idle != CPU_NOT_IDLE && group_has_capacity(env, local) &&
> >   busiest->group_no_capacity)
> >   goto force_balance;
> >
> > But calculate_imbalance fails to set the right amount of load to migrate
> > a task because of the special condition:
> >   busiest->avg_load <= sds->avg_load || local->avg_load >= sds->avg_load)
> >
> > Add in fix_small_imbalance, this special case that triggered the force
> > balance in order to make sure that the amount of load to migrate will be
> > enough.
> >
> > Signed-off-by: Vincent Guittot 
> > ---
>
> So we happen to have come up with a (relatively) similar patch for Android
> (see [1]) which also stemmed from the 1 always running task per CPU issue. It
> only applies to SD_ASYM_CPUCAPACITY sched domains though, and targets
> down-migrations (local->group_capacity < busiest->group_capacity).
>
> I'd argue that we should make it so this kind of imbalance gets detected way
> before we hit fix_small_imbalance(), but until we get there I think we do want
> an extra condition like this.
>
> >  kernel/sched/fair.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 309c93f..57b4d83 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -8048,6 +8048,20 @@ void fix_small_imbalance(struct lb_env *env, struct 
> > sd_lb_stats *sds)
> >   local = &sds->local_stat;
> >   busiest = &sds->busiest_stat;
> >
> > + /*
> > +  * There is available capacity in local group and busiest group is
> > +  * overloaded but calculate_imbalance can't compute the amount of load
> > +  * to migrate because they became meaningless because asymetric
>
> What do you mean by 'they'?

The loads

>
> Also, s/because/due to/ on the second "because".

ok

>
> > +  * capacity between group. In such case, we only want to migrate at
> > +  * least one tasks of the busiest group and rely of the average load
> > +  * per task to ensure the migration.
> > +  */
> > + if (env->idle != CPU_NOT_IDLE && group_has_capacity(env, local) &&
> > + busiest->group_no_capacity) {
> > + env->imbalance = busiest->load_per_task;
> > + return;
> > + }
> > +
>
> The condition is an exact copy of the one in that goto force_balance
> path you mention (in find_busiest_group()), is that just a coincidence? If

it's not a coincidence, it's to catch what have been missed by
calculate_imbalance

> not you might want to mention it in the comment.
>
> >   if (!local->sum_nr_running)
> >   local->load_per_task = cpu_avg_load_per_task(env->dst_cpu);
> >   else if (busiest->load_per_task > local->load_per_task)
> >
>
> [1]: 
> https://android.googlesource.com/kernel/common/+/9fae72e924961f3b32816193fcb56d19c1f644c2%5E%21/#F0

Re: [PATCH 1/13] KVM: Add tlb_remote_flush_with_range callback in kvm_x86_ops

[Sean Christopherson]

On Mon, 2018-09-10 at 08:38 +, Tianyu Lan wrote:
> Add flush range call back in the kvm_x86_ops and platform can use it
> to register its associated function. The parameter "kvm_tlb_range"
> accepts a single range and flush list which contains a list of ranges.
> 
> Signed-off-by: Lan Tianyu 
> ---
>  arch/x86/include/asm/kvm_host.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index e12916e7c2fb..dcdf8cc16388 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -402,6 +402,12 @@ struct kvm_mmu {
>   u64 pdptrs[4]; /* pae */
>  };
>  
> +struct kvm_tlb_range {
> + u64 start_gfn;
> + u64 end_gfn;

IMO this struct and all functions should pass around the number of pages
instead of end_gfn to avoid confusion as to whether end_gfn is inclusive
or exlusive.

> + struct list_head *flush_list;
> +};
> +
>  enum pmc_type {
>   KVM_PMC_GP = 0,
>   KVM_PMC_FIXED,
> @@ -991,6 +997,8 @@ struct kvm_x86_ops {
>  
>   void (*tlb_flush)(struct kvm_vcpu *vcpu, bool invalidate_gpa);
>   int  (*tlb_remote_flush)(struct kvm *kvm);
> + int  (*tlb_remote_flush_with_range)(struct kvm *kvm,
> + struct kvm_tlb_range *range);
>  
>   /*
>    * Flush any TLB entries associated with the given GVA.

Re: [PATCH 1/2] sound: q6core: Use kmemdup to replace kzalloc + memcpy

[Mark Brown]

On Sat, Sep 08, 2018 at 04:36:19PM +0800, zhong jiang wrote:
> kmemdup has implemented the function that kzalloc() + memcpy() will
> do. and we prefer to use the kmemdup rather than the open coded 
> implementation.

Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.  Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.


signature.asc
Description: PGP signature

Re: [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary

[Michal Hocko]

On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> Hi Michal,
> 
> It is tricky, but probably can be done. Either change
> memmap_init_zone() or its caller to also cover the ends and starts of
> unaligned sections to initialize and reserve pages.
> 
> The same thing would also need to be done in deferred_init_memmap() to
> cover the deferred init case.

Well, I am not sure TBH. I have to think about that much more. Maybe it
would be much more simple to make sure that we will never add incomplete
memblocks and simply refuse them during the discovery. At least for now.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 06/10] OPP: Add dev_pm_opp_{set|put}_required_device() helper

[Ulf Hansson]

On 29 June 2018 at 08:19, Viresh Kumar  wrote:
> Multiple generic power domains for a device are supported with the help
> of virtual devices, which are created for each device-genpd pair. These

What "device-genpd" pair are you referring to?

> are the device structures which are attached to the power domain and are
> required by the OPP core to set the performance state of the genpd.
>
> The helpers added by this commit are required to be called once for each
> genpd of a device. These are required only if multiple domains are
> present for a device, otherwise the actual device structure will be used
> instead by the OPP core.
>
> This commit also updates the genpd core to automatically call the new
> helper to set the required devices with the OPP layer, whenever the
> virtual devices are created for multiple genpd. The prototype of
> __genpd_dev_pm_attach() is slightly updated for this.
>
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/base/power/domain.c | 31 ++---
>  drivers/opp/core.c  | 69 +
>  drivers/opp/of.c| 12 +++
>  drivers/opp/opp.h   |  2 ++
>  include/linux/pm_opp.h  |  8 +
>  5 files changed, 118 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index c298de8a8308..e9c85c96580c 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2219,8 +2219,14 @@ static void genpd_dev_pm_detach(struct device *dev, 
> bool power_off)
> genpd_queue_power_off_work(pd);
>
> /* Unregister the device if it was created by genpd. */
> -   if (dev->bus == &genpd_bus_type)
> +   if (dev->bus == &genpd_bus_type) {
> +   struct opp_table *opp_table = dev_get_drvdata(dev);

This feels wrong, to me. Genpd is not a driver, but rather a
subsystem, hence I think it's a bad idea to "abuse" the driver data
pointer like this.

Instead, in genpd we store device specific data, through the
dev->power.subsys_data.

Seems like a better option is to extend the subsys_data, to also
include data needed to be shared for opp/performance states.

In that way, we might not even need to call into the opp library
(dev_pm_opp_set_required_device()) API, but rather the opp library can
itself check what is in the subsys_data for the device that is being
targeted. Would that work?

[...]

Kind regards
Uffe

Re: [PATCH] perf test: Add watchpoint test

[Arnaldo Carvalho de Melo]

Em Mon, Sep 10, 2018 at 10:47:54AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Sep 10, 2018 at 12:31:54PM +0200, Jiri Olsa escreveu:
> > On Mon, Sep 10, 2018 at 03:28:11PM +0530, Ravi Bangoria wrote:
> > > We don't have perf test available to test watchpoint functionality.
> > > Add simple set of tests: 
> > >  - Read only watchpoint
> > >  - Write only watchpoint
> > >  - Read / Write watchpoint
> > >  - Runtime watchpoint modification
> > > 
> > > Ex on powerpc:
> > >   $ sudo ./perf test 22
> > >   22: Watchpoint:
> > >   22.1: Read Only Watchpoint: Ok
> > >   22.2: Write Only Watchpoint   : Ok
> > >   22.3: Read / Write Watchpoint : Ok
> > >   22.4: Modify Watchpoint   : Ok
> > 
> > cool, thanks!
> > 
> > Acked-by: Jiri Olsa 
> 
> Thanks, applied.

While testing, I got curious, as a 'perf test' user, why one of the
tests had the "Skip" result:

[root@seventh ~]# perf test watchpoint
22: Watchpoint:
22.1: Read Only Watchpoint: Skip
22.2: Write Only Watchpoint   : Ok
22.3: Read / Write Watchpoint : Ok
22.4: Modify Watchpoint   : Ok
[root@seventh ~]#

I tried with 'perf test -v watchpoint' but that didn't help, perhaps you
could add some message after the "Skip" telling why it skipped that
test? I.e. hardware doesn't have that capability, kernel driver not yet
supporting that, something else?

- Arnaldo

Re: [PATCH v7] Add udmabuf misc device

[Gert Wollny]

Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
> > > 
> > > By default qemu doesn't use memfd for backing storage, you have
> > > to
> > > explicitly configure qemu that way (see qemu commit log of the
> > > test
> > > branch):
> > > 
> > > qemu-system-x86_64 -m 2G
> > > -object memory-backend-memfd,id=ram,size=2G
> > > -numa node,memdev=ram"
> > 
> > Thanks, but that doesn't seem to help.
> 
> Note the memory is specified twice, once with -m, once for the
> memory-backend-memfd object.  The two must match of course (or, to be
> exact, the sum of all memory backends must match the total memory,
> but unless you want create a virtual numa machine there is no reason
> to have multiple memory-backends).
Qemu actually complained when it was not the same. 

> 
> > Are there any host kernel configuration parameters or features that
> > I should set (apart from enabling udmabuf)? 
> 
> I'm not aware of any unusual parameters required.  My config is based
> on rhel-7, then stripped down with localmodconfig, then enabled the
> bits I want in my test kernel.
I use Gentoo and my kernel is rather stripped down ... 

> 
> Oh, wait, CONFIG_MEMFD_CREATE could be the one.  I guess I should add
> a Kconfig dependency.  
This was enabled, so not sure what else could be missing, I guess I'll
have to add some logging to get an idea.

Best, 
Gert  

Re: next-20180910: boots on thinkpad x60 (32bit machine) but has problems during suspend

[Pavel Machek]

Hi!

> > Next -0910 seems to boot ok... but when I hit the power button to
> > suspend the machine...  Full dmesg is in the attachment.
> 
> Is this a next only issue or is this happening on Linus tree as well?

I believe this only happens in next. I'm pretty sure v4.19-rc1 was
ok. Let me check v4.19-rc3... that one is ok.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH] mm: Use BUG_ON directly instead of a if condition followed by BUG

[zhong jiang]

The if condition can be removed if we use BUG_ON directly.
The issule is detected with the help of Coccinelle.

Signed-off-by: zhong jiang 
---
 mm/memory_hotplug.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 38d94b7..280b26c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1888,8 +1888,7 @@ void __ref remove_memory(int nid, u64 start, u64 size)
 */
ret = walk_memory_range(PFN_DOWN(start), PFN_UP(start + size - 1), NULL,
check_memblock_offlined_cb);
-   if (ret)
-   BUG();
+   BUG(ret);
 
/* remove memmap entry */
firmware_map_remove(start, start + size, "System RAM");
-- 
1.7.12.4

Re: [PATCH AUTOSEL 4.14 49/89] ARM: 8783/1: NOMMU: Extend check for VBAR support

[Sasha Levin]

On Mon, Sep 10, 2018 at 10:42:05AM +0100, Vladimir Murzin wrote:
>On 02/09/18 14:07, Sasha Levin wrote:
>> From: Vladimir Murzin 
>>
>> [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ]
>>
>> ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed
>> Sec_frac (bits [23:20]):
>>
>> Security fractional field. When the Security field is , determines
>> the support for features from the ARMv7 Security Extensions. Permitted
>> values are:
>>
>>  No features from the ARMv7 Security Extensions are implemented.
>>  This value is not supported in ARMv8 if ID_PFR1 bits [7:4] are zero.
>>
>> 0001 The implementation includes the VBAR, and the TCR.PD0 and TCR.PD1
>>  bits.
>>
>> 0010 As for 0001, plus the ability to access Secure or Non-secure
>>  physical memory is supported.
>>
>> All other values are reserved.
>>
>> This field is only valid when ID_PFR1[7:4] == 0, otherwise it holds
>> the value .
>>
>> Signed-off-by: Vladimir Murzin 
>> Signed-off-by: Russell King 
>> Signed-off-by: Sasha Levin 
>> ---
>>  arch/arm/mm/nommu.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
>> index 91537d90f5f5..08794bb0cada 100644
>> --- a/arch/arm/mm/nommu.c
>> +++ b/arch/arm/mm/nommu.c
>> @@ -305,7 +305,8 @@ static inline bool security_extensions_enabled(void)
>>  {
>>  /* Check CPUID Identification Scheme before ID_PFR1 read */
>>  if ((read_cpuid_id() & 0x000f) == 0x000f)
>> -return !!cpuid_feature_extract(CPUID_EXT_PFR1, 4);
>> +return cpuid_feature_extract(CPUID_EXT_PFR1, 4) ||
>> +cpuid_feature_extract(CPUID_EXT_PFR1, 20);
>>  return 0;
>>  }
>>
>>
>
>NAK - it is not stable material.

Dropped from all trees. Thank you.

Re: [PATCH] sched/fair: Disable LB_BIAS by default

[Peter Zijlstra]

On Thu, Aug 09, 2018 at 02:57:53PM +0100, Dietmar Eggemann wrote:
> LB_BIAS allows the adjustment on how conservative load should be
> balanced.

> It is very likely that LB_BIAS' influence on load balancing can be
> neglected (see test results below). This is further supported by:
> 
> (1) Weighted CPU load today is by itself a decayed average value (PELT)
> (cfs_rq->avg->runnable_load_avg) and not the instantaneous load
> (rq->load.weight) it was when LB_BIAS was introduced.
> 
> (2) Sd imbalance_pct is used for CPU_NEWLY_IDLE and CPU_NOT_IDLE (relate
> to sd's newidle and busy idx) in find_busiest_group() when comparing
> busiest and local avg load to make load balancing even more
> conservative.
> 
> (3) The sd forkexec and newidle idx are always set to 0 so there is no
> adjustment on how conservatively load balancing is done here.
> 
> (4) Affine wakeup based on weight (wake_affine_weight()) will not be
> impacted since the sd wake idx is always set to 0.
> 
> Let's disable LB_BIAS by default for a few kernel releases to make sure
> that no workload and no scheduler topology is affected. The benefit of
> being able to remove the LB_BIAS dependency from source_load() and
> target_load() is that the entire rq->cpu_load[idx] code could be removed
> in this case.

Certainly worth a try; as I've written somewhere in a comment; it would
be very nice to get rid of that load tracking crud.

And it is trivial to revert if something does show up.

Ingo, what do you think?

> Signed-off-by: Dietmar Eggemann 
> ---
>  kernel/sched/features.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/features.h b/kernel/sched/features.h
> index 85ae8488039c..858589b83377 100644
> --- a/kernel/sched/features.h
> +++ b/kernel/sched/features.h
> @@ -39,7 +39,7 @@ SCHED_FEAT(WAKEUP_PREEMPTION, true)
>  
>  SCHED_FEAT(HRTICK, false)
>  SCHED_FEAT(DOUBLE_TICK, false)
> -SCHED_FEAT(LB_BIAS, true)
> +SCHED_FEAT(LB_BIAS, false)
>  
>  /*
>   * Decrement CPU capacity based on time not spent running tasks
> -- 
> 2.11.0
> 

Re: [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary

[Pasha Tatashin]

Hi Michal,

It is tricky, but probably can be done. Either change
memmap_init_zone() or its caller to also cover the ends and starts of
unaligned sections to initialize and reserve pages.

The same thing would also need to be done in deferred_init_memmap() to
cover the deferred init case.

For hotplugged memory we do not need to worry, as that one is always
section aligned.

Do you think this would be a better approach?

Thank you,
Pavel
On Mon, Sep 10, 2018 at 10:00 AM Michal Hocko  wrote:
>
> On Mon 10-09-18 13:46:45, Pavel Tatashin wrote:
> >
> >
> > On 9/10/18 9:17 AM, Michal Hocko wrote:
> > > [Cc Pavel]
> > >
> > > On Mon 10-09-18 14:35:27, Mikhail Zaslonko wrote:
> > >> If memory end is not aligned with the linux memory section boundary, such
> > >> a section is only partly initialized. This may lead to VM_BUG_ON due to
> > >> uninitialized struct pages access from is_mem_section_removable() or
> > >> test_pages_in_a_zone() function.
> > >>
> > >> Here is one of the panic examples:
> > >>  CONFIG_DEBUG_VM_PGFLAGS=y
> > >>  kernel parameter mem=3075M
> > >
> > > OK, so the last memory section is not full and we have a partial memory
> > > block right?
> > >
> > >>  page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
> > >
> > > OK, this means that the struct page is not fully initialized. Do you
> > > have a specific place which has triggered this assert?
> > >
> > >>  [ cut here ]
> > >>  Call Trace:
> > >>  ([<0039b8a4>] is_mem_section_removable+0xcc/0x1c0)
> > >>   [<009558ba>] show_mem_removable+0xda/0xe0
> > >>   [<009325fc>] dev_attr_show+0x3c/0x80
> > >>   [<0047e7ea>] sysfs_kf_seq_show+0xda/0x160
> > >>   [<003fc4e0>] seq_read+0x208/0x4c8
> > >>   [<003cb80e>] __vfs_read+0x46/0x180
> > >>   [<003cb9ce>] vfs_read+0x86/0x148
> > >>   [<003cc06a>] ksys_read+0x62/0xc0
> > >>   [<00c001c0>] system_call+0xdc/0x2d8
> > >>
> > >> This fix checks if the page lies within the zone boundaries before
> > >> accessing the struct page data. The check is added to both functions.
> > >> Actually similar check has already been present in
> > >> is_pageblock_removable_nolock() function but only after the struct page
> > >> is accessed.
> > >>
> > >
> > > Well, I am afraid this is not the proper solution. We are relying on the
> > > full pageblock worth of initialized struct pages at many other place. We
> > > used to do that in the past because we have initialized the full
> > > section but this has been changed recently. Pavel, do you have any ideas
> > > how to deal with this partial mem sections now?
> >
> > We have:
> >
> > remove_memory()
> >   BUG_ON(check_hotplug_memory_range(start, size))
> >
> > That supposed to safely check for this condition: if [start, start +
> > size) not block size aligned (and we know block size is section
> > aligned), hot remove is not allowed. The problem is this check is late,
> > and only happens when invalid range has already passed through previous
> > checks.
> >
> > We could add check_hotplug_memory_range() to is_mem_section_removable():
> >
> > is_mem_section_removable(start_pfn, nr_pages)
> >  if (check_hotplug_memory_range(PFN_PHYS(start_pfn), PFN_PHYS(nr_pages)))
> >   return false;
> >
> > I think it should work.
>
> I do not think we want to sprinkle these tests over all pfn walkers. Can
> we simply initialize those uninitialized holes as well and make them
> reserved without handing them over to the page allocator? That would be
> much more robust approach IMHO.
> --
> Michal Hocko
> SUSE Labs
>

Re: [PATCH] Revert "x86/tsc: Consolidate init code"

[Ville Syrjälä]

On Mon, Sep 10, 2018 at 02:48:45PM +0200, Thomas Gleixner wrote:
> Ville,
> 
> On Mon, 10 Sep 2018, Ville Syrjala wrote:
> 
> > From: Ville Syrjälä 
> > 
> > This reverts commit 608008a45798fe9e2aee04f99b5270ea57c1376f.
> > 
> > It breaks wifi on my pentium 3 Fujitsu-Siemens Lifebook S6010
> > laptop. Scanning for APs doesn't seem to work most of the time,
> > and, even when it manages to find some APs it never manages to
> > authenticate successfully. dmesg is just littered with:
> > "wlan0: send auth to ... (try 1/3)
> >  wlan0: send auth to ... (try 2/3)
> >  wlan0: send auth to ... (try 3/3)
> >  wlan0: authentication with ... timed out"
> 
> I asked for that before and I really do not understand why you do not even
> make an attempt to report an issue first and allow the developers to work
> with you to figure out what exactly is the problem. All you do is to send
> an revert patch with a changelog which describes symptoms and probably
> breaks more than it cures. Not really helpful, really.

You're reading way too much into this. The revert is just a point to
start the conversion. I've found that it's the best way to get the
attention of the relevant developers. Other kind of regression
reports have an unfortunate habit of disappearing into /dev/null.

> 
> It's surely helpful to know that you bisected it to that commit and
> reverting it helps. Can you please provide more detailes information like
> dmesg of an good and a bad boot?

I think the only real difference (apart from the USB noise) is:
- clocksource: tsc-early: mask: 0x max_cycles: 0x1cbd01c4e18, 
max_idle_ns: 881590491211 ns
- Calibrating delay loop (skipped), value calculated using timer frequency.. 
1718674.70 BogoMIPS (lpj=2863311530)
+ clocksource: tsc-early: mask: 0x max_cycles: 0x1cbc55fe3af, 
max_idle_ns: 881590592998 ns
+ Calibrating delay loop (skipped), value calculated using timer frequency.. 
859455.59 BogoMIPS (lpj=1431852151)

Full logs attached.

-- 
Ville Syrjälä
Intel
[0.00] Linux version 4.18.0-rc5-alm-bisect-00312-g608008a45798 
(vsyrjala@stinkpad) (gcc version 7.3.0 (Gentoo 7.3.0-r3 p1.4)) #14 PREEMPT Sun 
Sep 9 20:44:16 EEST 2018
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x3f6d] usable
[0.00] BIOS-e820: [mem 0x3f6e-0x3f6efbff] ACPI data
[0.00] BIOS-e820: [mem 0x3f6efc00-0x3f6e] ACPI NVS
[0.00] BIOS-e820: [mem 0x3f6f-0x3f6f] reserved
[0.00] BIOS-e820: [mem 0x3f70-0x3f77] usable
[0.00] BIOS-e820: [mem 0x3f78-0x3fff] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] SMBIOS 2.3 present.
[0.00] DMI: FUJITSU SIEMENS LIFEBOOK S6010/FJNB159, BIOS Version 1.07  
10/28/2002
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 996.769 MHz processor
[0.006770] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.006778] e820: remove [mem 0x000a-0x000f] usable
[0.006795] last_pfn = 0x3f780 max_arch_pfn = 0x100
[0.006810] MTRR default type: uncachable
[0.006812] MTRR fixed ranges enabled:
[0.006816]   0-9 write-back
[0.006819]   A-B uncachable
[0.006821]   C-C7FFF write-protect
[0.006825]   C8000-E uncachable
[0.006827]   F-F write-protect
[0.006829] MTRR variable ranges enabled:
[0.006834]   0 base 0 mask FC000 write-back
[0.006837]   1 base 03FF8 mask 8 uncachable
[0.006839]   2 disabled
[0.006841]   3 disabled
[0.006842]   4 disabled
[0.006844]   5 disabled
[0.006846]   6 disabled
[0.006847]   7 disabled
[0.007342] x86/PAT: PAT not supported by CPU.
[0.007825] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
[0.007842] Warning only 889MB will be used.
[0.007846] Use a HIGHMEM enabled kernel.
[0.007939] Scanning 1 areas for low memory corruption
[0.007945] initial memory mapped: [mem 0x-0x01bf]
[0.007956] Base memory trampoline at [(ptrval)] 9b000 size 16384
[0.008059] BRK [0x0179f000, 0x0179] PGTABLE
[0.008092] BRK [0x017a, 0x017a0fff] PGTABLE
[0.008101] RAMDISK: [mem 0x37b18000-0x37fe]
[0.008109] Allocated new RAMDISK: [mem 0x37526000-0x379fd7ff]
[0.030953] Move RAMDISK from [mem 0x37b18000-0x37fef7ff] to [mem 
0x37526000-0x379fd7ff]
[0.030995] ACPI: Early table checksum verification disabled
[0.

Re: [PATCH] Drivers: hv: vmbus: include header for get_irq_regs()

[Sebastian Andrzej Siewior]

On 2018-08-30 09:55:03 [+0200], To K. Y. Srinivasan wrote:
> On !RT the header file get_irq_regs() gets pulled in via other header files. 
> On
> RT it does not and the build fails:
> 
> drivers/hv/vmbus_drv.c:975 implicit declaration of function 
> ‘get_irq_regs’ [-Werror=implicit-function-declaration]
> drivers/hv/hv.c:115 implicit declaration of function ‘get_irq_regs’ 
> [-Werror=implicit-function-declaration]
> 
> Add the header file for get_irq_regs() in a common header so it used by
> vmbus_drv.c by hv.c for their get_irq_regs() usage.
> 
> Reported-by: Bernhard Landauer 
> Reported-by: Ralf Ramsauer 
> Signed-off-by: Sebastian Andrzej Siewior 

ping

> ---
>  drivers/hv/hyperv_vmbus.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 72eaba3d50fc2..797f07918197c 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "hv_trace.h"
>  
> -- 
> 2.18.0
> 

Re: [RESEND PATCH] mfd: stmpe: honor gpio interrupt probe deferral

[Lee Jones]

On Tue, 14 Aug 2018, Marcel Ziswiler wrote:

> From: Marcel Ziswiler 
> 
> Actually honor probe deferral in trying to get the GPIO interrupt as
> of_get_named_gpio_flags() in stmpe_of_probe() may as well just do so.
> 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 
>  drivers/mfd/stmpe.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
> index 566caca4efd8..4d6ffd3ef398 100644
> --- a/drivers/mfd/stmpe.c
> +++ b/drivers/mfd/stmpe.c
> @@ -1331,6 +1331,8 @@ int stmpe_probe(struct stmpe_client_info *ci, enum 
> stmpe_partnum partnum)
>   return -ENOMEM;
>  
>   stmpe_of_probe(pdata, np);
> + if (-EPROBE_DEFER == pdata->irq_gpio)
> + return -EPROBE_DEFER;

EPROBE_DEFER usually means "stop what you're doing and return", rather
than "do a few more things, then return".  With that in mind, I would
rather you convert stmpe_of_probe() to return and int containing the
appropriate error as soon as it is detected.

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

Re: [PATCH] mfd: omap-usb-host: Fix dts probe of children

[Tony Lindgren]

* Lee Jones  [180910 11:18]:
> On Thu, 30 Aug 2018, Tony Lindgren wrote:
> 
> > Lee,
> > 
> > * Tony Lindgren  [180425 07:31]:
> > > It currently only works if the parent bus uses "simple-bus". We
> > > currently try to probe children with non-existing compatible values.
> > > And we're missing .probe.
> > > 
> > > I noticed this while testing devices configured to probe using ti-sysc
> > > interconnect target module driver. For that we also may want to rebind
> > > the driver, so let's remove __init and __exit.
> > > 
> > > Cc: Roger Quadros 
> > > Signed-off-by: Tony Lindgren 
> > > ---
> > > 
> > > This is OK to wait for v4.18 merge window as the related dts node has
> > > not yet been updated to probe via ti-sysc interconnect target driver.
> > 
> > Sorry I just noticed this is still pending, it should be
> > applied as a fix for the -rc series.
> > 
> > Do you want me to resend the patch?
> 
> Just back from vacation.

Welcome back :)

> No thanks, I'll get to it.

OK thanks!

Tony

Re: [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary

[Michal Hocko]

On Mon 10-09-18 13:46:45, Pavel Tatashin wrote:
> 
> 
> On 9/10/18 9:17 AM, Michal Hocko wrote:
> > [Cc Pavel]
> > 
> > On Mon 10-09-18 14:35:27, Mikhail Zaslonko wrote:
> >> If memory end is not aligned with the linux memory section boundary, such
> >> a section is only partly initialized. This may lead to VM_BUG_ON due to
> >> uninitialized struct pages access from is_mem_section_removable() or
> >> test_pages_in_a_zone() function.
> >>
> >> Here is one of the panic examples:
> >>  CONFIG_DEBUG_VM_PGFLAGS=y
> >>  kernel parameter mem=3075M
> > 
> > OK, so the last memory section is not full and we have a partial memory
> > block right?
> > 
> >>  page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
> > 
> > OK, this means that the struct page is not fully initialized. Do you
> > have a specific place which has triggered this assert?
> > 
> >>  [ cut here ]
> >>  Call Trace:
> >>  ([<0039b8a4>] is_mem_section_removable+0xcc/0x1c0)
> >>   [<009558ba>] show_mem_removable+0xda/0xe0
> >>   [<009325fc>] dev_attr_show+0x3c/0x80
> >>   [<0047e7ea>] sysfs_kf_seq_show+0xda/0x160
> >>   [<003fc4e0>] seq_read+0x208/0x4c8
> >>   [<003cb80e>] __vfs_read+0x46/0x180
> >>   [<003cb9ce>] vfs_read+0x86/0x148
> >>   [<003cc06a>] ksys_read+0x62/0xc0
> >>   [<00c001c0>] system_call+0xdc/0x2d8
> >>
> >> This fix checks if the page lies within the zone boundaries before
> >> accessing the struct page data. The check is added to both functions.
> >> Actually similar check has already been present in
> >> is_pageblock_removable_nolock() function but only after the struct page
> >> is accessed.
> >>
> > 
> > Well, I am afraid this is not the proper solution. We are relying on the
> > full pageblock worth of initialized struct pages at many other place. We
> > used to do that in the past because we have initialized the full
> > section but this has been changed recently. Pavel, do you have any ideas
> > how to deal with this partial mem sections now?
> 
> We have:
> 
> remove_memory()
>   BUG_ON(check_hotplug_memory_range(start, size))
> 
> That supposed to safely check for this condition: if [start, start +
> size) not block size aligned (and we know block size is section
> aligned), hot remove is not allowed. The problem is this check is late,
> and only happens when invalid range has already passed through previous
> checks.
> 
> We could add check_hotplug_memory_range() to is_mem_section_removable():
> 
> is_mem_section_removable(start_pfn, nr_pages)
>  if (check_hotplug_memory_range(PFN_PHYS(start_pfn), PFN_PHYS(nr_pages)))
>   return false;
> 
> I think it should work.

I do not think we want to sprinkle these tests over all pfn walkers. Can
we simply initialize those uninitialized holes as well and make them
reserved without handing them over to the page allocator? That would be
much more robust approach IMHO.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v8 0/3]: perf: reduce data loss when profiling highly parallel CPU bound workloads

[Arnaldo Carvalho de Melo]

Em Mon, Sep 10, 2018 at 02:06:43PM +0200, Ingo Molnar escreveu:
> * Alexey Budankov  wrote:
> > On 10.09.2018 12:18, Ingo Molnar wrote:
> > > * Alexey Budankov  wrote:
> > >> Currently in record mode the tool implements trace writing serially. 
> > >> The algorithm loops over mapped per-cpu data buffers and stores 
> > >> ready data chunks into a trace file using write() system call.
> > >>
> > >> At some circumstances the kernel may lack free space in a buffer 
> > >> because the other buffer's half is not yet written to disk due to 
> > >> some other buffer's data writing by the tool at the moment.
> > >>
> > >> Thus serial trace writing implementation may cause the kernel 
> > >> to loose profiling data and that is what observed when profiling 
> > >> highly parallel CPU bound workloads on machines with big number 
> > >> of cores.
> > > 
> > > Yay! I saw this frequently on a 120-CPU box (hw is broken now).
> > > 
> > >> Data loss metrics is the ratio lost_time/elapsed_time where 
> > >> lost_time is the sum of time intervals containing PERF_RECORD_LOST 
> > >> records and elapsed_time is the elapsed application run time 
> > >> under profiling.
> > >>
> > >> Applying asynchronous trace streaming thru Posix AIO API
> > >> (http://man7.org/linux/man-pages/man7/aio.7.html) 
> > >> lowers data loss metrics value providing 2x improvement -
> > >> lowering 98% loss to almost 0%.
> > > 
> > > Hm, instead of AIO why don't we use explicit threads instead? I think 
> > > Posix AIO will fall back 
> > > to threads anyway when there's no kernel AIO support (which there 
> > > probably isn't for perf 
> > > events).
> > 
> > Explicit threading is surely an option but having more threads 
> > in the tool that stream performance data is a considerable 
> > design complication.
> > 
> > Luckily, glibc AIO implementation is already based on pthreads, 
> > but having a writing thread for every distinct fd only.
> 
> My argument is, we don't want to rely on glibc's choices here. They might
> use a different threading design in the future, or it might differ between
> libc versions.
> 
> The basic flow of tracing/profiling data is something we should control 
> explicitly,
> via explicit threading.
> 
> BTW., the usecase I was primarily concentrating on was a simpler one: 'perf 
> record -a', not 
> inherited workflow tracing. For system-wide profiling the ideal tracing setup 
> is clean per-CPU 
> separation, i.e. per CPU event fds, per CPU threads that read and then write 
> into separate 
> per-CPU files.

My main request here is that we think about the 'perf top' and 'perf
trace' workflows as well when working on this, i.e. that we don't take
for granted that we'll have the perf.data files to work with.

I.e. N threads, that periodically use that FINISHED_ROUND event to order
events and go on consuming. All of the objects already have refcounts
and locking to allow for things like decaying of samples to take care of
trowing away no longer needed objects (struct map, thread, dso, symbol
tables, etc) to trim memory usage.

- Arnaldo

Re: [PATCH 7/7] drivers: mfd: adp5520: Update MODULE AUTHOR email address

[Lee Jones]

On Tue, 14 Aug 2018, michael.henner...@analog.com wrote:

> From: Michael Hennerich 
> 
> no functional changes
> 
> Signed-off-by: Michael Hennerich 
> ---
>  drivers/mfd/adp5520.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] arm64: dts: rockchip: add i2s and spdif endpoint of rk3328

[Heiko Stuebner]

Hi,

Am Donnerstag, 6. September 2018, 18:39:56 CEST schrieb Katsuhiro Suzuki:
> This patch adds port and endpoint of i2s and spdif nodes for rk3328.
> Because to use modern sound card interface such as audio-graph-card.
> 
> Signed-off-by: Katsuhiro Suzuki 
> ---
>  arch/arm64/boot/dts/rockchip/rk3328.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index d3ef6566325e..41f0a20b73ed 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -179,7 +179,13 @@
>   clock-names = "i2s_clk", "i2s_hclk";
>   dmas = <&dmac 11>, <&dmac 12>;
>   dma-names = "tx", "rx";
> + #sound-dai-cells = <0>;
>   status = "disabled";
> +
> + i2s0_p0: port@0 {

there is only one port per device, so this should probably be
i2s0_p0: port {
without the address. Same for all others.
The of-graph framework should work just fine then as well.

Heiko

Re: [PATCH V2] kernel: locking: rtmutex: Fix a possible sleep-in-atomic-context bug in rt_mutex_handle_deadlock()

[Peter Zijlstra]

On Sat, Aug 11, 2018 at 11:00:37AM +0800, Jia-Ju Bai wrote:

You forgot to Cc the person who wrote this code...

>  kernel/locking/rtmutex.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index 2823d4163a37..8f25a289abe8 100644
> --- a/kernel/locking/rtmutex.c
> +++ b/kernel/locking/rtmutex.c
> @@ -1205,7 +1205,7 @@ __rt_mutex_slowlock(struct rt_mutex *lock, int state,
>  }
>  
>  static void rt_mutex_handle_deadlock(int res, int detect_deadlock,
> -  struct rt_mutex_waiter *w)
> +  struct rt_mutex_waiter *w, struct rt_mutex 
> *lock)
>  {
>   /*
>* If the result is not -EDEADLOCK or the caller requested
> @@ -1218,6 +1218,8 @@ static void rt_mutex_handle_deadlock(int res, int 
> detect_deadlock,
>* Yell lowdly and stop the task right here.
>*/
>   rt_mutex_print_deadlock(w);
> + /* We're not going anywhere, release the wait_lock */
> + raw_spin_unlock_irq(&lock->wait_lock);
>   while (1) {
>   set_current_state(TASK_INTERRUPTIBLE);
>   schedule();
> @@ -1269,7 +1271,7 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
>   if (unlikely(ret)) {
>   __set_current_state(TASK_RUNNING);
>   remove_waiter(lock, &waiter);
> - rt_mutex_handle_deadlock(ret, chwalk, &waiter);
> + rt_mutex_handle_deadlock(ret, chwalk, &waiter, lock);
>   }

The patch is correct; but I can't find myself liking it very much. This
dinly little single use function is growing a lot of arguments.

The alternative is something like the below; not sure myself though.
Thomas?


diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 2823d4163a37..a44d4034e232 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1204,18 +1204,10 @@ __rt_mutex_slowlock(struct rt_mutex *lock, int state,
return ret;
 }
 
-static void rt_mutex_handle_deadlock(int res, int detect_deadlock,
-struct rt_mutex_waiter *w)
+static void rt_mutex_handle_deadlock(struct rt_mutex_waiter *w)
 {
/*
-* If the result is not -EDEADLOCK or the caller requested
-* deadlock detection, nothing to do here.
-*/
-   if (res != -EDEADLOCK || detect_deadlock)
-   return;
-
-   /*
-* Yell lowdly and stop the task right here.
+* Yell loudly and stop the task right here.
 */
rt_mutex_print_deadlock(w);
while (1) {
@@ -1269,7 +1261,10 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
if (unlikely(ret)) {
__set_current_state(TASK_RUNNING);
remove_waiter(lock, &waiter);
-   rt_mutex_handle_deadlock(ret, chwalk, &waiter);
+   if (chwalk == RT_MUTEX_MIN_CHAINWALK && ret == -EDEADLOCK) {
+   raw_spin_unlock_irqrestore(&lock->wait_lock, flags);
+   rt_mutex_handle_deadlock(&waiter);
+   }
}
 
/*

[PATCH] rcu: Use cpus_read_lock() while looking at cpu_online_mask

[Sebastian Andrzej Siewior]

It was possible that sync_rcu_exp_select_cpus() enqueued something on
CPU0 while CPU0 was offline. Such a work item wouldn't be processed
until CPU0 gets back online. This problem was addressed in commit
fcc6354365015 ("rcu: Make expedited GPs handle CPU 0 being offline"). I
don't think the issue fully addressed.

Assume grplo = 0 and grphi = 7 and sync_rcu_exp_select_cpus() is invoked
on CPU1. The preempt_disable() section on CPU1 won't ensure that CPU0
remains online between looking at cpu_online_mask and invoking
queue_work_on() on CPU1.

Use cpus_read_lock() to ensure that `cpu' is not going down between
looking at cpu_online_mask at invoking queue_work_on() and waiting for
its completion. It is added around the loop + flush_work() which is
similar to work_on_cpu_safe() (and we can have multiple jobs running on
NUMA systems).

Fixes: fcc6354365015 ("rcu: Make expedited GPs handle CPU 0 being
  offline")
Signed-off-by: Sebastian Andrzej Siewior 
---
 kernel/rcu/tree_exp.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index 01b6ddeb4f050..a104cf91e6b90 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -479,6 +479,7 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
sync_exp_reset_tree(rsp);
trace_rcu_exp_grace_period(rsp->name, rcu_exp_gp_seq_endval(rsp), 
TPS("select"));
 
+   cpus_read_lock();
/* Schedule work for each leaf rcu_node structure. */
rcu_for_each_leaf_node(rsp, rnp) {
rnp->exp_need_flush = false;
@@ -493,13 +494,11 @@ static void sync_rcu_exp_select_cpus(struct rcu_state 
*rsp,
continue;
}
INIT_WORK(&rnp->rew.rew_work, sync_rcu_exp_select_node_cpus);
-   preempt_disable();
cpu = cpumask_next(rnp->grplo - 1, cpu_online_mask);
/* If all offline, queue the work on an unbound CPU. */
if (unlikely(cpu > rnp->grphi))
cpu = WORK_CPU_UNBOUND;
queue_work_on(cpu, rcu_par_gp_wq, &rnp->rew.rew_work);
-   preempt_enable();
rnp->exp_need_flush = true;
}
 
@@ -507,6 +506,7 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
rcu_for_each_leaf_node(rsp, rnp)
if (rnp->exp_need_flush)
flush_work(&rnp->rew.rew_work);
+   cpus_read_unlock();
 }
 
 static void synchronize_sched_expedited_wait(struct rcu_state *rsp)
-- 
2.19.0.rc2

Re: [PATCH] irqchip: Convert to using %pOFn instead of device_node.name

[Rob Herring]

On Sat, Sep 8, 2018 at 7:15 AM Thomas Gleixner  wrote:
>
> On Mon, 27 Aug 2018, Rob Herring wrote:
>
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > Cc: Thomas Gleixner 
> > Cc: Jason Cooper 
> > Cc: Marc Zyngier 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: Rob Herring 
>
> Should I take it or do you want to take it with others? If the latter,
> acked-by-me.

Please take it. There's no dependency.

Rob

Re: [PATCH 14/21] riscv: use for_each_of_cpu_node iterator

[Rob Herring]

On Mon, Sep 10, 2018 at 8:38 AM Christoph Hellwig  wrote:
>
> On Wed, Sep 05, 2018 at 02:37:31PM -0500, Rob Herring wrote:
> > Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This
> > has the side effect of defaulting to iterating using "cpu" node names in
> > preference to the deprecated (for FDT) device_type == "cpu".
> >
> > Cc: Palmer Dabbelt 
> > Cc: Albert Ou 
> > Cc: linux-ri...@lists.infradead.org
> > Signed-off-by: Rob Herring 
> > ---
> > Please ack and I will take via the DT tree. This is dependent on the
> > first 2 patches.
>
> We have a few pending patches in this area that look like they might
> conflict.  It might be worth to delay this one and apply it post -rc1
> to avoid dependencies if that isn't a problem for you.

Sure. That's fine.

Rob

RE: [PATCH] x86/mce: Fix set_mce_nospec() to avoid #GP fault

[David Laight]

From: Linus Torvalds
> ...
> You could literally do something like
> 
> /* Make it canonical in case we flipped the high bit */
> addr = (long)(addr<<1)>>1;

Isn't it safer to use a mask and let the compiler decide if two
shifts are a good implementation?

addr &= ~HIGH_MAGIC_BIT;

ISTR fixing a bug in gld where it had (foo << 16) >> 16 instead
of foo & 0x. Didn't work well on 64bit.

(I may need to recompile that old gcc/gld again.
Failed miserably last time I tried.)

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH] iio: remove unnecessary condition judgment in am2315_trigger_handler

[zhong jiang]

On 2018/9/8 22:17, Jonathan Cameron wrote:
> On Sat, 8 Sep 2018 17:59:13 +0530
> Himanshu Jha  wrote:
>
>> On Sat, Sep 08, 2018 at 06:57:36PM +0800, zhong jiang wrote:
>>> The iterator in for_each_set_bit is never null, therefore, remove
>>> the redundant conditional judgment.
>>>
>>> Signed-off-by: zhong jiang 
>>> ---
>>>  drivers/iio/humidity/am2315.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
>>> index 7d8669d..dc12e37 100644
>>> --- a/drivers/iio/humidity/am2315.c
>>> +++ b/drivers/iio/humidity/am2315.c
>>> @@ -176,8 +176,7 @@ static irqreturn_t am2315_trigger_handler(int irq, void 
>>> *p)
>>> i = 0;
>>> for_each_set_bit(bit, indio_dev->active_scan_mask,
>>>  indio_dev->masklength) {
>>> -   data->buffer[i] = (bit ? sensor_data.temp_data :
>>> -sensor_data.hum_data);
>>> +   data->buffer[i] = sensor_data.temp_data;  
>> No, this seems wrong!
>>
>> We have buffer support to either take both readings(temp & humid)
>> simultaneously, or only single channel using specified scan mask.
> Key think is that bit most definitely can be 0 if the 0th bit is set.
> This isn't a null check at all.
>
> I'm curious, was this a by inspection case or did some script throw
> this one up?
 Hi,  Jonathan

 bit is a iterator that find the non-zero bit in indio_dev->active_scan_mask. 
if  all bit is
 zero ,  it should return the masklength.

 Yep.  I find the issue with the help of Coccinelle.

 Thanks
zhong jiang
> Thanks,
>
> Jonathan
>
>> Patch title should be:
>>
>> "iio: humidity: am2315:  .. "
>>
>>
>> Thanks
>
> .
>

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

[Christoph Hellwig]

On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
> > He has an irqchip that is called from the RISC-V exception handler
> > when the interrupt flag is set in scause and then dispatches to one
> > of:  IPI, timer, actual irqchip.
> 
> So the per cpu timer is the only per cpu interrupt and that thing is used
> unconditionally, right?

Yes.  external is chained and IPI is still handled explicitly.

Re: [PATCH] arm64: add NUMA emulation support

[Michal Hocko]

On Fri 07-09-18 16:30:59, Shuah Khan wrote:
> On 09/07/2018 02:34 AM, Michal Hocko wrote:
> > On Thu 06-09-18 15:53:34, Shuah Khan wrote:
> > [...]
> >> A few critical allocations could be satisfied and root cgroup prevails. It 
> >> is not the
> >> intent to have exclusivity at the expense of the kernel.
> > 
> > Well, it is not "few critical allocations". It can be a lot of
> > memory. Basically any GFP_KERNEL allocation. So how exactly you expect
> > this to work when you cannot estimate how much
> > memory will kernel eat?
> > 
> >>
> >> This feature will allow a way to configure cpusets on non-NUMA for 
> >> workloads that can
> >> benefit from the reservation and isolation that is available within the 
> >> constraints of
> >> exclusive cpuset policies.
> > 
> > AFAIR this was the first approach Google took for the memory isolation
> > and they moved over to memory cgroups. 
> 
> In addition to isolation, being able to reserve a block instead is one of the
> issues I am looking to address. Unfortunately memory cgroups won't address 
> that
> issue.

Could you be more specific why you need reservations other than
isolation.

> I would recommend to talk to
> > those guys bebfore you introduce potentially a lot of code that will not
> > really work for the workload you indend it for.
> > 
> 
> Will you be able to point me to a good contact at Goggle and/or some pointers
> on finding discussion on the memory isolation. My searches on lkml came up
> short,

Well, Ying Han who used to work on memcg early days is working on a
different project. So I am not really sure.
https://lwn.net/Articles/459585/ might tell you more.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] perf test: Add watchpoint test

[Arnaldo Carvalho de Melo]

Em Mon, Sep 10, 2018 at 12:31:54PM +0200, Jiri Olsa escreveu:
> On Mon, Sep 10, 2018 at 03:28:11PM +0530, Ravi Bangoria wrote:
> > We don't have perf test available to test watchpoint functionality.
> > Add simple set of tests: 
> >  - Read only watchpoint
> >  - Write only watchpoint
> >  - Read / Write watchpoint
> >  - Runtime watchpoint modification
> > 
> > Ex on powerpc:
> >   $ sudo ./perf test 22
> >   22: Watchpoint:
> >   22.1: Read Only Watchpoint: Ok
> >   22.2: Write Only Watchpoint   : Ok
> >   22.3: Read / Write Watchpoint : Ok
> >   22.4: Modify Watchpoint   : Ok
> 
> cool, thanks!
> 
> Acked-by: Jiri Olsa 

Thanks, applied.

- Arnaldo

Re: [PATCH 2/2] mfd: cros_ec: Fix and improve kerneldoc comments.

[Lee Jones]

On Mon, 10 Sep 2018, Benson Leung wrote:

> On Mon, Sep 10, 2018 at 5:12 PM Lee Jones  wrote:
> >
> > On Fri, 07 Sep 2018, Benson Leung wrote:
> >
> > > Hi Enric,
> > >
> > > On Wed, Jul 18, 2018 at 06:09:56PM +0200, Enric Balletbo i Serra wrote:
> > > > cros-ec includes inside the MFD subsystem, specially the file
> > > > cros_ec_commands.h, has been modified several times and it has grown a
> > > > lot, unfortunately, we didn't have care too much about the 
> > > > documentation.
> > > > This patch tries to improve the documentation and also fixes all the
> > > > issues reported by kerneldoc script.
> > > >
> > > > Signed-off-by: Enric Balletbo i Serra 
> > >
> > > Applied, thanks.
> >
> > If applying patches from other subsystems, you need to wait for an
> > appropriate Ack before applying.  Please send me a succinct
> > pull-request for this patch, so that we might avoid potential conflict
> > at merge time.
> 
> Ok Lee, sorry about that.  Actually this hasn't landed in my for-next
> branch yet so no conflict has happened yet. I  will send you a PR
> shortly.

No worries, it happens.

The PR is to avoid merge conflicts at "merge time" i.e. when Linus
merges everything into Mainline during the merge window.

Appreciate your help.

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

Re: [PATCH v2] of: __of_update_property_sysfs only call __of_sysfs_remove_bin_file if of_node_is_attached

[Rob Herring]

On Mon, Sep 10, 2018 at 4:51 AM Andre Kalb  wrote:
>
> Hi Frank,
>
> > -Ursprüngliche Nachricht-
> > Von: Frank Rowand [mailto:frowand.l...@gmail.com]
> > Gesendet: Freitag, 7. September 2018 22:01
> > An: Andre Kalb; robh...@kernel.org; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Betreff: Re: [PATCH v2] of: __of_update_property_sysfs only call
> > __of_sysfs_remove_bin_file if of_node_is_attached
> >
> > Hi Andred,
> >
> > On 09/04/18 08:51, Andre Kalb wrote:
> > > To prevent warning "kernfs: can not remove '(null)', no directory" if an 
> > > overlay
> > isn't applied to the active devicetree.
> > >
> > > Using of_remove_property and then of_add_property doesn't show the
> > warning.

[...]

> > What is the calling path that results in the warning?
> >
> > -Frank
>
> There is the callstack of the warning.
>
> [   10.782830] [ cut here ]
> [   10.830357] WARNING: CPU: 0 PID: 170 at /linux-4.x/fs/kernfs/dir.c:1276 
> kernfs_remove_by_name_ns+0x30/0x80()
> [   10.928997] kernfs: can not remove '(null)', no directory
> [   10.993107] Modules linked in: module_capemgr(+)
> [   11.045750] CPU: 0 PID: 170 Comm: systemd-udevd Not tainted 
> 4.4.143-00158-g8e5ca65ec7ee-dirty #114

158 patches on top of an almost 3 year old kernel...

> [   12.011373] [] (module_capemgr_slot_scan [module_capemgr]) from 
> [] (module_capemgr_probe+0x3c/0x58 [module_capemgr])

And a driver that's not upstream.

Not saying the fix isn't valid, but please reproduce on recent
mainline. Add a unittest if you have to.

Rob

Re: [PATCH] RISC-V: Show IPI stats

[Christoph Hellwig]

On Fri, Sep 07, 2018 at 06:14:29PM +0530, Anup Patel wrote:
> This patch provides arch_show_interrupts() implementation to
> show IPI stats via /proc/interrupts.
> 
> Now the contents of /proc/interrupts" will look like below:
>CPU0   CPU1   CPU2   CPU3
>   8: 17  7  6 14  SiFive PLIC   8  virtio0
>  10: 10 10  9 11  SiFive PLIC  10  ttyS0
> IPI0:   170673251 79  Rescheduling interrupts
> IPI1: 1 12 27  1  Function call interrupts
> IPI2: 0  0  0  0  CPU wake-up interrupts
> 
> Signed-off-by: Anup Patel 

Thanks, this looks pretty sensible to me.  Maybe we want to also show
timer interrupts if we do this?

> --- a/arch/riscv/kernel/irq.c
> +++ b/arch/riscv/kernel/irq.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Possible interrupt causes:
> @@ -24,6 +25,14 @@
>   */
>  #define INTERRUPT_CAUSE_FLAG (1UL << (__riscv_xlen - 1))
>  
> +int arch_show_interrupts(struct seq_file *p, int prec)
> +{
> +#ifdef CONFIG_SMP
> + show_ipi_stats(p, prec);
> +#endif
> + return 0;
> +}

If we don't also add timer stats I'd just move arch_show_interrupts
to smp.c and make it conditional.  If we don't this split might make
more sense.

> +static const char *ipi_names[IPI_MAX] = {
> + [IPI_RESCHEDULE] = "Rescheduling interrupts",
> + [IPI_CALL_FUNC] = "Function call interrupts",
> + [IPI_CALL_WAKEUP] = "CPU wake-up interrupts",
> +};

No need for the explicit array size.  Also please use a few tabs to
align this nicely:

static const char *ipi_names[] = {
[IPI_RESCHEDULE]= "Rescheduling interrupts",
[IPI_CALL_FUNC] = "Function call interrupts",
[IPI_CALL_WAKEUP]   = "CPU wake-up interrupts",
};

Re: [PATCH] memory_hotplug: fix the panic when memory end is not on the section boundary

[Pasha Tatashin]

On 9/10/18 9:17 AM, Michal Hocko wrote:
> [Cc Pavel]
> 
> On Mon 10-09-18 14:35:27, Mikhail Zaslonko wrote:
>> If memory end is not aligned with the linux memory section boundary, such
>> a section is only partly initialized. This may lead to VM_BUG_ON due to
>> uninitialized struct pages access from is_mem_section_removable() or
>> test_pages_in_a_zone() function.
>>
>> Here is one of the panic examples:
>>  CONFIG_DEBUG_VM_PGFLAGS=y
>>  kernel parameter mem=3075M
> 
> OK, so the last memory section is not full and we have a partial memory
> block right?
> 
>>  page dumped because: VM_BUG_ON_PAGE(PagePoisoned(p))
> 
> OK, this means that the struct page is not fully initialized. Do you
> have a specific place which has triggered this assert?
> 
>>  [ cut here ]
>>  Call Trace:
>>  ([<0039b8a4>] is_mem_section_removable+0xcc/0x1c0)
>>   [<009558ba>] show_mem_removable+0xda/0xe0
>>   [<009325fc>] dev_attr_show+0x3c/0x80
>>   [<0047e7ea>] sysfs_kf_seq_show+0xda/0x160
>>   [<003fc4e0>] seq_read+0x208/0x4c8
>>   [<003cb80e>] __vfs_read+0x46/0x180
>>   [<003cb9ce>] vfs_read+0x86/0x148
>>   [<003cc06a>] ksys_read+0x62/0xc0
>>   [<00c001c0>] system_call+0xdc/0x2d8
>>
>> This fix checks if the page lies within the zone boundaries before
>> accessing the struct page data. The check is added to both functions.
>> Actually similar check has already been present in
>> is_pageblock_removable_nolock() function but only after the struct page
>> is accessed.
>>
> 
> Well, I am afraid this is not the proper solution. We are relying on the
> full pageblock worth of initialized struct pages at many other place. We
> used to do that in the past because we have initialized the full
> section but this has been changed recently. Pavel, do you have any ideas
> how to deal with this partial mem sections now?

We have:

remove_memory()
BUG_ON(check_hotplug_memory_range(start, size))

That supposed to safely check for this condition: if [start, start +
size) not block size aligned (and we know block size is section
aligned), hot remove is not allowed. The problem is this check is late,
and only happens when invalid range has already passed through previous
checks.

We could add check_hotplug_memory_range() to is_mem_section_removable():

is_mem_section_removable(start_pfn, nr_pages)
 if (check_hotplug_memory_range(PFN_PHYS(start_pfn), PFN_PHYS(nr_pages)))
  return false;

I think it should work.

Pavel

> 
>> Signed-off-by: Mikhail Zaslonko 
>> Reviewed-by: Gerald Schaefer 
>> Cc: 
>> ---
>>  mm/memory_hotplug.c | 20 +++-
>>  1 file changed, 11 insertions(+), 9 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 9eea6e809a4e..8e20e8fcc3b0 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1229,9 +1229,8 @@ static struct page *next_active_pageblock(struct page 
>> *page)
>>  return page + pageblock_nr_pages;
>>  }
>>  
>> -static bool is_pageblock_removable_nolock(struct page *page)
>> +static bool is_pageblock_removable_nolock(struct page *page, struct zone 
>> **zone)
>>  {
>> -struct zone *zone;
>>  unsigned long pfn;
>>  
>>  /*
>> @@ -1241,15 +1240,14 @@ static bool is_pageblock_removable_nolock(struct 
>> page *page)
>>   * We have to take care about the node as well. If the node is offline
>>   * its NODE_DATA will be NULL - see page_zone.
>>   */
>> -if (!node_online(page_to_nid(page)))
>> -return false;
>> -
>> -zone = page_zone(page);
>>  pfn = page_to_pfn(page);
>> -if (!zone_spans_pfn(zone, pfn))
>> +if (*zone && !zone_spans_pfn(*zone, pfn))
>>  return false;
>> +if (!node_online(page_to_nid(page)))
>> +return false;
>> +*zone = page_zone(page);
>>  
>> -return !has_unmovable_pages(zone, page, 0, MIGRATE_MOVABLE, true);
>> +return !has_unmovable_pages(*zone, page, 0, MIGRATE_MOVABLE, true);
>>  }
>>  
>>  /* Checks if this range of memory is likely to be hot-removable. */
>> @@ -1257,10 +1255,11 @@ bool is_mem_section_removable(unsigned long 
>> start_pfn, unsigned long nr_pages)
>>  {
>>  struct page *page = pfn_to_page(start_pfn);
>>  struct page *end_page = page + nr_pages;
>> +struct zone *zone = NULL;
>>  
>>  /* Check the starting page of each pageblock within the range */
>>  for (; page < end_page; page = next_active_pageblock(page)) {
>> -if (!is_pageblock_removable_nolock(page))
>> +if (!is_pageblock_removable_nolock(page, &zone))
>>  return false;
>>  cond_resched();
>>  }
>> @@ -1296,6 +1295,9 @@ int test_pages_in_a_zone(unsigned long start_pfn, 
>> unsigned long end_pfn,
>>  i++;
>>  if (i == MAX_ORDER_NR_PAGES || pfn + i >= end_pfn)
>>  continue;
>> +/* Check if we g

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

[Thomas Gleixner]

On Mon, 10 Sep 2018, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote:
> > > > Just a few weeks ago you said the contrary:
> > > > 
> > > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> > > 
> > > Sigh. Yes. Now that you remind me. 
> > 
> > Just for clarification. I had the impression that Anup was trying to wire
> > up more than just the timer interrupt, but that doesn't seem to be the
> > case.
> 
> He has an irqchip that is called from the RISC-V exception handler
> when the interrupt flag is set in scause and then dispatches to one
> of:  IPI, timer, actual irqchip.

So the per cpu timer is the only per cpu interrupt and that thing is used
unconditionally, right?

Thanks,

tglx

Re: [PATCH v12 0/6] Driver for at91 usart in spi mode

[Lee Jones]

On Mon, 10 Sep 2018, Nicolas Ferre wrote:

> Hi Lee,
> 
> On 10/09/2018 at 11:48, Lee Jones wrote:
> > On Tue, 04 Sep 2018, Radu Pirea wrote:
> > > Well, this is the 12th version of this patch series.
> > > In this version I fixed a warning from kbuild-robot and I have no idea
> > > how I forgot to add static in declaration of that functions. Also I
> > > fixed the example for the SPI driver in bindings.
> > 
> > Okay great.  So which patches still require Acks?
> 
> None I would say: everything's ready to be integrated into your MFD tree as
> you proposed some time ago.
> 
> We are looking forward seeing this series integrated in linux-next as soon
> as possible.

Very well.

I'm just catching up after an extended vacation - only 300 mails to go!

Please bear with me.

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

Re: [PATCH v2 3/3] mm: Add build time sanity chcek for struct page size

[kbuild test robot]

Hi Baoquan,

I love your patch! Yet something to improve:

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.19-rc2 next-20180906]
[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/Baoquan-He/x86-mm-KASLR-Fix-the-wrong-calculation-of-kalsr-region-initial-size/20180910-205421
config: i386-randconfig-x077-201836 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:5:0,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from mm/page_alloc.c:18:
   mm/page_alloc.c: In function 'free_area_init_nodes':
   include/linux/kernel.h:845:29: warning: comparison of distinct pointer types 
lacks a cast
  (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
^
   include/linux/compiler.h:335:18: note: in definition of macro 
'__compiletime_assert'
  int __cond = !(condition);\
 ^
   include/linux/compiler.h:358:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/build_bug.h:45:37: note: in expansion of macro 
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/build_bug.h:69:2: note: in expansion of macro 
'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
>> mm/page_alloc.c:6852:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON(sizeof(struct page) < min(SZ_1K, PAGE_SIZE/4));
 ^~~~
   include/linux/kernel.h:859:4: note: in expansion of macro '__typecheck'
  (__typecheck(x, y) && __no_side_effects(x, y))
   ^~~
   include/linux/kernel.h:869:24: note: in expansion of macro '__safe_cmp'
 __builtin_choose_expr(__safe_cmp(x, y), \
   ^~
   include/linux/kernel.h:878:19: note: in expansion of macro '__careful_cmp'
#define min(x, y) __careful_cmp(x, y, <)
  ^
>> mm/page_alloc.c:6852:37: note: in expansion of macro 'min'
 BUILD_BUG_ON(sizeof(struct page) < min(SZ_1K, PAGE_SIZE/4));
^~~
>> include/linux/compiler.h:358:38: error: call to '__compiletime_assert_6852' 
>> declared with attribute error: BUILD_BUG_ON failed: sizeof(struct page) < 
>> min(SZ_1K, PAGE_SIZE/4)
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:338:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:358:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/build_bug.h:45:37: note: in expansion of macro 
'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/build_bug.h:69:2: note: in expansion of macro 
'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
>> mm/page_alloc.c:6852:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON(sizeof(struct page) < min(SZ_1K, PAGE_SIZE/4));
 ^~~~

vim +/__compiletime_assert_6852 +358 include/linux/compiler.h

9a8ab1c3 Daniel Santos 2013-02-21  344  
9a8ab1c3 Daniel Santos 2013-02-21  345  #define _compiletime_assert(condition, 
msg, prefix, suffix) \
9a8ab1c3 Daniel Santos 2013-02-21  346  __compiletime_assert(condition, 
msg, prefix, suffix)
9a8ab1c3 Daniel Santos 2013-02-21  347  
9a8ab1c3 Daniel Santos 2013-02-21  348  /**
9a8ab1c3 Daniel Santos 2013-02-21  349   * compiletime_assert - break build and 
emit msg if condition is false
9a8ab1c3 Daniel Santos 2013-02-21  350   * @condition: a compile-time constant 
condition to check
9a8ab1c3 Daniel Santos 2013-02-21  351   * @msg:   a message to emit if 
condition is false
9a8ab1c3 Daniel Santos 2013-02-21  352   *
9a8ab1c3 Daniel Santos 2013-02-21  353   * In tradition of POSIX assert, this 
macro will break the build if the
9a8ab1c3 Daniel Santos 2

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

[Christoph Hellwig]

On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote:
> > > Just a few weeks ago you said the contrary:
> > > 
> > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> > 
> > Sigh. Yes. Now that you remind me. 
> 
> Just for clarification. I had the impression that Anup was trying to wire
> up more than just the timer interrupt, but that doesn't seem to be the
> case.

He has an irqchip that is called from the RISC-V exception handler
when the interrupt flag is set in scause and then dispatches to one
of:  IPI, timer, actual irqchip.

Re: [PATCH v9 09/22] s390: vfio-ap: register matrix device with VFIO mdev framework

[Tony Krowiak]

On 09/06/2018 04:49 AM, Pierre Morel wrote:

On 13/08/2018 23:48, Tony Krowiak wrote:

From: Tony Krowiak 

Registers the matrix device created by the VFIO AP device
driver with the VFIO mediated device framework.
Registering the matrix device will create the sysfs
structures needed to create mediated matrix devices
each of which will be used to configure the AP matrix
for a guest and connect it to the VFIO AP device driver.

Registering the matrix device with the VFIO mediated device
framework will create the following sysfs structures:

/sys/devices/vfio_ap/matrix/
.. [mdev_supported_types]
. [vfio_ap-passthrough]
 create

To create a mediated device for the AP matrix device, write a UUID
to the create file:

uuidgen > create

A symbolic link to the mediated device's directory will be created in 
the

devices subdirectory named after the generated $uuid:

/sys/devices/vfio_ap/matrix/
.. [mdev_supported_types]
. [vfio_ap-passthrough]
 [devices]
... [$uuid]

A symbolic link to the mediated device will also be created
in the vfio_ap matrix's directory:

/sys/devices/vfio_ap/matrix/[$uuid]

Signed-off-by: Tony Krowiak 
Reviewed-by: Halil Pasic 
Tested-by: Michael Mueller 
Tested-by: Farhan Ali 
Signed-off-by: Christian Borntraeger 
---
  MAINTAINERS   |1 +
  drivers/s390/crypto/Makefile  |2 +-
  drivers/s390/crypto/vfio_ap_drv.c |   23 ++
  drivers/s390/crypto/vfio_ap_ops.c |  124 
+

  drivers/s390/crypto/vfio_ap_private.h |   45 
  include/uapi/linux/vfio.h |1 +
  6 files changed, 195 insertions(+), 1 deletions(-)
  create mode 100644 drivers/s390/crypto/vfio_ap_ops.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e84c559..f60dd56 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12427,6 +12427,7 @@ W: 
http://www.ibm.com/developerworks/linux/linux390/

  S:Supported
  F:drivers/s390/crypto/vfio_ap_drv.c
  F:drivers/s390/crypto/vfio_ap_private.h
+F:drivers/s390/crypto/vfio_ap_ops.c

  S390 ZFCP DRIVER
  M:Steffen Maier 
diff --git a/drivers/s390/crypto/Makefile b/drivers/s390/crypto/Makefile
index 48e466e..8d36b05 100644
--- a/drivers/s390/crypto/Makefile
+++ b/drivers/s390/crypto/Makefile
@@ -17,5 +17,5 @@ pkey-objs := pkey_api.o
  obj-$(CONFIG_PKEY) += pkey.o

  # adjunct processor matrix
-vfio_ap-objs := vfio_ap_drv.o
+vfio_ap-objs := vfio_ap_drv.o vfio_ap_ops.o
  obj-$(CONFIG_VFIO_AP) += vfio_ap.o
diff --git a/drivers/s390/crypto/vfio_ap_drv.c 
b/drivers/s390/crypto/vfio_ap_drv.c

index 5069580..fa04c5a 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include "vfio_ap_private.h"

  #define VFIO_AP_ROOT_NAME "vfio_ap"
@@ -65,6 +66,19 @@ static int vfio_ap_matrix_dev_init(void)
  return ret;
  }

+mutex_init(&matrix_dev.lock);
+INIT_LIST_HEAD(&matrix_dev.mdev_list);
+
+/* Test if PQAP(QCI) instruction is available */
+if (test_facility(12)) {
+ret = ap_qci(&matrix_dev.info);
+if (ret) {
+root_device_unregister(root_device);
+return ret;
+}
+}
+
+atomic_set(&matrix_dev.available_instances, MAX_ZDEV_ENTRIES_EXT);
  matrix_dev.device.type = &vfio_ap_dev_type;
  dev_set_name(&matrix_dev.device, "%s", VFIO_AP_DEV_NAME);
  matrix_dev.device.type = &vfio_ap_dev_type;
@@ -105,11 +119,20 @@ int __init vfio_ap_init(void)
  return ret;
  }

+ret = vfio_ap_mdev_register();
+if (ret) {
+ap_driver_unregister(&vfio_ap_drv);
+vfio_ap_matrix_dev_destroy();
+
+return ret;
+}
+
  return 0;
  }

  void __exit vfio_ap_exit(void)
  {
+vfio_ap_mdev_unregister();
  ap_driver_unregister(&vfio_ap_drv);
  vfio_ap_matrix_dev_destroy();
  }
diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
b/drivers/s390/crypto/vfio_ap_ops.c

new file mode 100644
index 000..8018c2d
--- /dev/null
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Adjunct processor matrix VFIO device driver callbacks.
+ *
+ * Copyright IBM Corp. 2018
+ *
+ * Author(s): Tony Krowiak 
+ *  Halil Pasic 
+ *  Pierre Morel 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vfio_ap_private.h"
+
+#define VFIO_AP_MDEV_TYPE_HWVIRT "passthrough"
+#define VFIO_AP_MDEV_NAME_HWVIRT "VFIO AP Passthrough Device"
+
+static void vfio_ap_matrix_init(struct ap_config_info *info,
+struct ap_matrix *matrix)
+{
+matrix->apm_max = info->apxa ? info->Na : 63;
+matrix->aqm_max = info->apxa ? info->Nd : 15;
+matrix->adm_max = info->apxa ? info->Nd : 15;
+}
+
+static int vfio_ap_mdev_create(struct kobject *kobj, struct 
mdev_device *mdev)

+{
+struct ap_matrix_mdev *matrix_mdev;
+
+matrix_mdev = kzalloc(sizeof(*matri

Re: [PATCH v2 0/3] powerpc/pseries: use H_BLOCK_REMOVE

[Laurent Dufour]

Hi Michael,

Do you plan to pull it for 4.20 ?

Cheers,
Laurent.

On 20/08/2018 16:29, Laurent Dufour wrote:
> On very large system we could see soft lockup fired when a process is
> exiting
> 
> watchdog: BUG: soft lockup - CPU#851 stuck for 21s! [forkoff:215523]
> Modules linked in: pseries_rng rng_core xfs raid10 vmx_crypto btrfs libcrc32c 
> xor zstd_decompress zstd_compress xxhash lzo_compress raid6_pq crc32c_vpmsum 
> lpfc crc_t10dif crct10dif_generic crct10dif_common dm_multipath scsi_dh_rdac 
> scsi_dh_alua autofs4
> CPU: 851 PID: 215523 Comm: forkoff Not tainted 4.17.0 #1
> NIP:  c00b995c LR: c00b8f64 CTR: aa18
> REGS: c6b0645b7610 TRAP: 0901   Not tainted  (4.17.0)
> MSR:  80010280b033   CR: 22042082  
> XER: 
> CFAR: 006cf8f0 SOFTE: 0 
> GPR00: 0010 c6b0645b7890 c0f99200  
> GPR04: 8e01a5a4de58 400249cf1bfd5480 8e01a5a4de50 400249cf1bfd5480 
> GPR08: 8e01a5a4de48 400249cf1bfd5480 8e01a5a4de40 400249cf1bfd5480 
> GPR12:  c0001e690800 
> NIP [c00b995c] plpar_hcall9+0x44/0x7c
> LR [c00b8f64] pSeries_lpar_flush_hash_range+0x324/0x3d0
> Call Trace:
> [c6b0645b7890] [8e01a5a4dd20] 0x8e01a5a4dd20 (unreliable)
> [c6b0645b7a00] [c006d5b0] flush_hash_range+0x60/0x110
> [c6b0645b7a50] [c0072a2c] __flush_tlb_pending+0x4c/0xd0
> [c6b0645b7a80] [c02eaf44] unmap_page_range+0x984/0xbd0
> [c6b0645b7bc0] [c02eb594] unmap_vmas+0x84/0x100
> [c6b0645b7c10] [c02f8afc] exit_mmap+0xac/0x1f0
> [c6b0645b7cd0] [c00f2638] mmput+0x98/0x1b0
> [c6b0645b7d00] [c00fc9d0] do_exit+0x330/0xc00
> [c6b0645b7dc0] [c00fd384] do_group_exit+0x64/0x100
> [c6b0645b7e00] [c00fd44c] sys_exit_group+0x2c/0x30
> [c6b0645b7e30] [c000b960] system_call+0x58/0x6c
> Instruction dump:
> 6000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378 
> e9410060 e9610068 e9810070 4422 <7d806378> e9810028 f88c f8ac0008
> 
> This happens when removing the PTE by calling the hypervisor using the
> H_BULK_REMOVE call. This call is processing up to 4 PTEs but is doing a
> tlbie for each PTE it is processing. This could lead to long time spent in
> the hypervisor (sometimes up to 4s) and soft lockup being raised because
> the scheduler is not called in zap_pte_range().
> 
> Since the Power7's time, the hypervisor is providing a new hcall
> H_BLOCK_REMOVE allowing processing up to 8 PTEs with one call to
> tlbie. By limiting the amount of tlbie generated, this reduces the time
> spent invalidating the PTEs.
> 
> This hcall requires that the pages are "all within the same naturally
> aligned 8 page virtual address block".
> 
> With this patch series applied, I couldn't see any soft lockup raised on
> the victim LPAR I was running the test one.
> 
> Changes since V1:
> - Remove a call to BUG_ON() in call_block_remove() since this one can be
>   handled gently.
> - Remove uneeded of current_vpgb to 0 when retrying entries in
>   hugepage_block_invalidate() and do_block_remove().
> 
> Laurent Dufour (3):
>   powerpc/pseries/mm: Introducing FW_FEATURE_BLOCK_REMOVE
>   powerpc/pseries/mm: factorize PTE slot computation
>   powerpc/pseries/mm: call H_BLOCK_REMOVE
> 
>  arch/powerpc/include/asm/firmware.h   |   3 +-
>  arch/powerpc/include/asm/hvcall.h |   1 +
>  arch/powerpc/platforms/pseries/firmware.c |   1 +
>  arch/powerpc/platforms/pseries/lpar.c | 241 
> --
>  4 files changed, 230 insertions(+), 16 deletions(-)
> 

Re: [PATCH 14/21] riscv: use for_each_of_cpu_node iterator

[Christoph Hellwig]

On Wed, Sep 05, 2018 at 02:37:31PM -0500, Rob Herring wrote:
> Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This
> has the side effect of defaulting to iterating using "cpu" node names in
> preference to the deprecated (for FDT) device_type == "cpu".
> 
> Cc: Palmer Dabbelt 
> Cc: Albert Ou 
> Cc: linux-ri...@lists.infradead.org
> Signed-off-by: Rob Herring 
> ---
> Please ack and I will take via the DT tree. This is dependent on the
> first 2 patches.

We have a few pending patches in this area that look like they might
conflict.  It might be worth to delay this one and apply it post -rc1
to avoid dependencies if that isn't a problem for you.

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

[Thomas Gleixner]

On Mon, 10 Sep 2018, Thomas Gleixner wrote:
> On Mon, 10 Sep 2018, Christoph Hellwig wrote:
> > On Sat, Sep 08, 2018 at 12:46:35PM +0200, Thomas Gleixner wrote:
> > > On Thu, 6 Sep 2018, Christoph Hellwig wrote:
> > > 
> > > > Just as before:  NAK to entirely pointless abstractions.  Please stop
> > > > beating the dead horse.
> > > 
> > > I disagree. These interrupts very well fit into the percpu interupt
> > > mechanics and that allows them to be handled by all the generic mechanisms
> > > as any other interrupt.
> > 
> > Just a few weeks ago you said the contrary:
> > 
> > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> 
> Sigh. Yes. Now that you remind me. 

Just for clarification. I had the impression that Anup was trying to wire
up more than just the timer interrupt, but that doesn't seem to be the
case.

Re: [RFC PATCH 4/5] irqchip: RISC-V Local Interrupt Controller Driver

[Christoph Hellwig]

On Thu, Sep 06, 2018 at 05:23:07PM +0530, Anup Patel wrote:
> > And we reject that driver approach for good reason and are now
> > doing the architectualy low-level irq handling in common code
> > without any need whatsover to duplicate information in the
> > privileged spec in DT.
> 
> In other words, the whole idea of separate RISCV local interrupt
> controller driver was dropped due duplicate information in privilege
> spec DT ??

No.  We came to the conflusion that a few registers on a cpu
that allow enabling/disabling local vs external vs timer intterupts
aren't worth writing an irqchip (or DT entries) for.

Re: [RFC][PATCH 8/8] really consolidate INIT_C_CC definitions

[Linus Torvalds]

On Sun, Sep 9, 2018 at 6:52 PM Al Viro  wrote:
>
>  */
> +#ifndef INIT_C_CC_VDISCARD
> +#define INIT_C_CC_VDISCARD 'O'-0x40
> +#endif

Just change everybody to do the same, nobody cares about VDISCARD.

We can change the value of VDISCARD because it doesn't actually have
anything connected to it, so don't worry about "we used to have odd
different values for it".

Linus

Re: [RFC PATCH 1/5] RISC-V: Make IPI triggering flexible

[Christoph Hellwig]

On Thu, Sep 06, 2018 at 04:15:14PM +0530, Anup Patel wrote:
> This patch is doing two things:
> 1. Allow IRQCHIP driver to provide IPI trigger mechanism

And the big questions is why do we want that?  The last thing we
want is for people to "innovate" on how they deliver IPIs.  RISC-V
has defined an SBI interface for it to hide all the details, and
we should not try to handle systems that are not SBI compliant.

Eventuall we might want to revisit the SBI to improve on shortcomings
if there are any, but we should not allow random irqchip drivers to
override this.

> 2. Have more generic IPI handler in arch/riscv so that IRQCHIP driver
> can call it

And that is rather irrelevant without 1) above.

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

[Thomas Gleixner]

On Mon, 10 Sep 2018, Christoph Hellwig wrote:
> On Sat, Sep 08, 2018 at 12:46:35PM +0200, Thomas Gleixner wrote:
> > On Thu, 6 Sep 2018, Christoph Hellwig wrote:
> > 
> > > Just as before:  NAK to entirely pointless abstractions.  Please stop
> > > beating the dead horse.
> > 
> > I disagree. These interrupts very well fit into the percpu interupt
> > mechanics and that allows them to be handled by all the generic mechanisms
> > as any other interrupt.
> 
> Just a few weeks ago you said the contrary:
> 
> http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html

Sigh. Yes. Now that you remind me. 

Re: [PATCH v7] Add udmabuf misc device

[Gerd Hoffmann]

On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
> > 
> > By default qemu doesn't use memfd for backing storage, you have to
> > explicitly configure qemu that way (see qemu commit log of the test
> > branch):
> > 
> > qemu-system-x86_64 -m 2G
> > -object memory-backend-memfd,id=ram,size=2G
> > -numa node,memdev=ram"
> 
> Thanks, but that doesn't seem to help.

Note the memory is specified twice, once with -m, once for the
memory-backend-memfd object.  The two must match of course (or, to be
exact, the sum of all memory backends must match the total memory, but
unless you want create a virtual numa machine there is no reason to have
multiple memory-backends).

> Are there any host kernel
> configuration parameters or features that I should set (apart from
> enabling udmabuf)? 

I'm not aware of any unusual parameters required.  My config is based on
rhel-7, then stripped down with localmodconfig, then enabled the bits I
want in my test kernel.

Oh, wait, CONFIG_MEMFD_CREATE could be the one.  I guess I should add a
Kconfig dependency.  Even though udmabuf will build just fine without
that (because memfd is basically shmem with some features on top) it
doesn't buy you much if the memfd_create syscall is not available ...

cheers,
  Gerd

Re: [PATCH v6 4/5] x86/kvm: use __decrypted attribute in shared variables

[Thomas Gleixner]

On Mon, 10 Sep 2018, Sean Christopherson wrote:

> On Mon, 2018-09-10 at 14:04 +0200, Borislav Petkov wrote:
> > On Fri, Sep 07, 2018 at 12:57:29PM -0500, Brijesh Singh wrote:
> > > 
> > > Commit: 368a540e0232 (x86/kvmclock: Remove memblock dependency)
> > > caused SEV guest regression.
> > When mentioning a commit in the commit message, put it on a separate
> > line, like this:
> > 
> > "Commit
> > 
> >   368a540e0232 (x86/kvmclock: Remove memblock dependency)
> > 
> > caused a SEV guest regression."
> 
> Heh, that was the original formatting until I asked him to change it:
> https://lkml.org/lkml/2018/8/29/809.  Checkpatch throws an error if
> there's a newline after 'Commit'.  Though looking at this again, there
> shouldn't be a colon after 'Commit' and there should be quotes inside
> the parentheses, e.g. this satisfies checkpatch:
> 
> Commit 368a540e0232 ("x86/kvmclock: Remove memblock dependency")

The whole 5 lines of 'commit bla broke' are bogus to me. They convey not
really useful information and the commit line will repeat itself in the
Fixes: tag. So something like:

  The recent removal of the memblock dependency caused a SEV guest
  regression because bla


  Fixes: 368a540e0232 ("x86/kvmclock: Remove memblock dependency")

Is much more useful than the above independent of its formatting.

Thanks,

tglx

Re: [PATCH v2 3/5] irqchip: RISC-V Local Interrupt Controller Driver

[Christoph Hellwig]

On Sat, Sep 08, 2018 at 12:46:35PM +0200, Thomas Gleixner wrote:
> On Thu, 6 Sep 2018, Christoph Hellwig wrote:
> 
> > Just as before:  NAK to entirely pointless abstractions.  Please stop
> > beating the dead horse.
> 
> I disagree. These interrupts very well fit into the percpu interupt
> mechanics and that allows them to be handled by all the generic mechanisms
> as any other interrupt.

Just a few weeks ago you said the contrary:

http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html

Re: [PATCH v6 5/5] x86/kvm: Avoid dynamic allocation of pvclock data when SEV is active

[Sean Christopherson]

On Mon, 2018-09-10 at 08:15 -0500, Brijesh Singh wrote:
> 
> On 9/10/18 7:27 AM, Borislav Petkov wrote:
> > 
> > On Fri, Sep 07, 2018 at 12:57:30PM -0500, Brijesh Singh wrote:
> > > 
> > > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> > > index 376fd3a..6086b56 100644
> > > --- a/arch/x86/kernel/kvmclock.c
> > > +++ b/arch/x86/kernel/kvmclock.c
> > > @@ -65,6 +65,15 @@ static struct pvclock_vsyscall_time_info
> > >  static struct pvclock_wall_clock wall_clock __decrypted;
> > >  static DEFINE_PER_CPU(struct pvclock_vsyscall_time_info *, 
> > > hv_clock_per_cpu);
> > >  
> > > +#ifdef CONFIG_AMD_MEM_ENCRYPT
> > > +/*
> > > + * The auxiliary array will be used when SEV is active. In non-SEV case,
> > > + * it will be freed by free_decrypted_mem().
> > > + */
> > > +static struct pvclock_vsyscall_time_info
> > > + hv_clock_aux[NR_CPUS] __decrypted_aux;
> > Hmm, so worst case that's 64 4K pages:
> > 
> > (8192*32)/4096 = 64 4K pages.
> We can minimize the worst case memory usage. The number of VCPUs
> supported by KVM maybe less than NR_CPUS. e.g Currently KVM_MAX_VCPUS is
> set to 288

KVM_MAX_VCPUS is a property of the host, whereas this code runs in the
guest, e.g. KVM_MAX_VCPUS could be 2048 in the host for all we know.

> (288 * 64)/4096 = 4 4K pages.
> 
> (pvclock_vsyscall_time_info is cache aligned so it will be 64 bytes)

Ah, I was wondering why my calculations were always different than
yours.  I was looking at struct pvclock_vcpu_time_info, which is 32
bytes.

> #if NR_CPUS > KVM_MAX_VCPUS
> #define HV_AUX_ARRAY_SIZE  KVM_MAX_VCPUS
> #else
> #define HV_AUX_ARRAY_SIZE NR_CPUS
> #endif
> 
> static struct pvclock_vsyscall_time_info
>                         hv_clock_aux[HV_AUX_ARRAY_SIZE] __decrypted_aux;

Re: linux-next: build warnings from the build of Linus' tree

[Peter Oberparleiter]

On 08.09.2018 05:57, Masami Hiramatsu wrote:
> On Fri, 7 Sep 2018 14:50:59 +0200
> Peter Oberparleiter  wrote:
> 
>> On 06.09.2018 18:42, Masami Hiramatsu wrote:
>>> Peter Oberparleiter  wrote:
 I've attached a quick fix that should address both problems. I'd
 appreciate if this patch could get some testing before I post proper fix
 patches.
>>>
>>> Hmm, I'm still not able to reproduce it on powerpc cross build even with
>>> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y ... So, sorry I couldn't test this 
>>> patch.
>>
>> Maybe this is related to the compiler/binutils versions used. I'm using
>> Fedora 28's gcc-powerpc64 and binutils-powerpc64 packages:
>>
>> powerpc64-linux-gnu-gcc (GCC) 7.1.1 20170622 (Red Hat Cross 7.1.1-3)
>> GNU ld version 2.29.1-4.fc28
>>
>> For reference I'm also attaching the config that I used to reproduce the
>> problem on kernel v4.18.
>>
 diff --git a/arch/arm/kernel/vmlinux.lds.h b/arch/arm/kernel/vmlinux.lds.h
 index ae5fdff18406..2ca33277a28b 100644
 --- a/arch/arm/kernel/vmlinux.lds.h
 +++ b/arch/arm/kernel/vmlinux.lds.h
 @@ -48,6 +48,7 @@

  #define ARM_DISCARD   
 \
*(.ARM.exidx.exit.text) \
 +  *(.ARM.exidx.text.exit) \
>>>
>>> BTW, why would we need this?
>>
>> That's necessary to fix one of the two ARM linker failures reported via
>> https://lkml.org/lkml/2018/8/24/345
>>
> `.text.exit' referenced in section `.ARM.exidx.text.exit' of
> kernel/trace/trace_clock.o: defined in discarded section `.text.exit'
> of kernel/trace/trace_clock.o
>>
>> Section ".ARM.exidx.text.exit" refers to ".text.exit" which was
>> discarded. With the change above, the extraneous section
>> ".ARM.exidx.text.exit" is also discarded, resolving the linker failure.
> 
> OK, so your patch fixes following issue too?
> 
> https://patchwork.kernel.org/patch/10584685/

Yes it does, by discarding the text.exit section unconditionally. I
don't think we need to keep any exit-related section introduced by GCOV
profiling. It is my understanding that the code contained in such a
section is only relevant for user-space profiling, to process profiling
data when a program ends.

Also discarding .ARM.exidx.text.exit seems to be more consistent to how
.ARM.exidx.exit.text is handled.

> In that case, we should drop above patch.

Yes, I agree.

-- 
Peter Oberparleiter
Linux on Z Development - IBM Germany

Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains

[Tony Krowiak]

On 08/27/2018 09:51 AM, Cornelia Huck wrote:

On Mon, 27 Aug 2018 09:47:58 -0400
Tony Krowiak  wrote:


On 08/27/2018 04:33 AM, Cornelia Huck wrote:

On Thu, 23 Aug 2018 10:16:59 -0400
Tony Krowiak  wrote:
  

On 08/23/2018 06:25 AM, Cornelia Huck wrote:

On Wed, 22 Aug 2018 15:16:19 -0400
Tony Krowiak  wrote:
 

One of the things I suggested in a private conversation with Christian
earlier
today was to provide an additional rw sysfs attribute - a boolean - that
indicates
whether all usage domains should also be control domains. The default
could be
true. This would allow one to configure guests with usage-only domains
as well
as satisfy the convention.

Would this additional attribute then control "add usage domains to the
list of control domains automatically", or "don't allow to add a usage
domain if it has not already been added as a control domain"?

It was just a proposal that wasn't really discussed at all, but this
attribute would add usage domains to the list of control domains
automatically if set to one. That would be the default behavior which
would be turned off by manually setting it to zero.

If we want to do something like that, having it add the usage domains
automatically sounds like the more workable alternative. What I like
about this is that we make it explicit that we change the masks beyond
what the admin explicitly configured, and provide a knob to turn off
that behaviour.

So, are you saying I should go ahead and implement this?

I'm just saying that it does not sound like a bad idea :)

If you agree that it's a good idea and if others also like it... I'd
certainly not mind you going ahead :)


This was discussed with out crypto team and hardware architects and it
was decided that configuring all usage domains as control domains also
is not the right thing to do, so only domains assigned as control
domains will be set in the ADM field of the the guest's CRYCB.

[PATCH v6 16/16] cpupower, x86: Add Hygon Dhyana support

[Pu Wen]

Tool cpupower is useful to get CPU frequency information and monitor
power stats on Hygon Dhyana platforms. So add Hygon Dhyana support to
it by checking vendor and family to share the code path of AMD family
17h.

Signed-off-by: Pu Wen 
---
 tools/power/cpupower/utils/cpufreq-info.c   | 6 --
 tools/power/cpupower/utils/helpers/amd.c| 4 ++--
 tools/power/cpupower/utils/helpers/cpuid.c  | 8 +---
 tools/power/cpupower/utils/helpers/helpers.h| 2 +-
 tools/power/cpupower/utils/helpers/misc.c   | 2 +-
 tools/power/cpupower/utils/idle_monitor/mperf_monitor.c | 3 ++-
 6 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/tools/power/cpupower/utils/cpufreq-info.c 
b/tools/power/cpupower/utils/cpufreq-info.c
index df43cd4..56e54ea 100644
--- a/tools/power/cpupower/utils/cpufreq-info.c
+++ b/tools/power/cpupower/utils/cpufreq-info.c
@@ -170,6 +170,7 @@ static int get_boost_mode(unsigned int cpu)
unsigned long pstates[MAX_HW_PSTATES] = {0,};
 
if (cpupower_cpu_info.vendor != X86_VENDOR_AMD &&
+   cpupower_cpu_info.vendor != X86_VENDOR_HYGON &&
cpupower_cpu_info.vendor != X86_VENDOR_INTEL)
return 0;
 
@@ -190,8 +191,9 @@ static int get_boost_mode(unsigned int cpu)
printf(_("Supported: %s\n"), support ? _("yes") : _("no"));
printf(_("Active: %s\n"), active ? _("yes") : _("no"));
 
-   if (cpupower_cpu_info.vendor == X86_VENDOR_AMD &&
-   cpupower_cpu_info.family >= 0x10) {
+   if ((cpupower_cpu_info.vendor == X86_VENDOR_AMD &&
+cpupower_cpu_info.family >= 0x10) ||
+cpupower_cpu_info.vendor == X86_VENDOR_HYGON) {
ret = decode_pstates(cpu, cpupower_cpu_info.family, b_states,
 pstates, &pstate_no);
if (ret)
diff --git a/tools/power/cpupower/utils/helpers/amd.c 
b/tools/power/cpupower/utils/helpers/amd.c
index bb41cdd..65beaee 100644
--- a/tools/power/cpupower/utils/helpers/amd.c
+++ b/tools/power/cpupower/utils/helpers/amd.c
@@ -45,7 +45,7 @@ static int get_did(int family, union msr_pstate pstate)
 
if (family == 0x12)
t = pstate.val & 0xf;
-   else if (family == 0x17)
+   else if (family == 0x17 || family == 0x18)
t = pstate.fam17h_bits.did;
else
t = pstate.bits.did;
@@ -59,7 +59,7 @@ static int get_cof(int family, union msr_pstate pstate)
int fid, did, cof;
 
did = get_did(family, pstate);
-   if (family == 0x17) {
+   if (family == 0x17 || family == 0x18) {
fid = pstate.fam17h_bits.fid;
cof = 200 * fid / did;
} else {
diff --git a/tools/power/cpupower/utils/helpers/cpuid.c 
b/tools/power/cpupower/utils/helpers/cpuid.c
index 732b0b4..5cc39d4 100644
--- a/tools/power/cpupower/utils/helpers/cpuid.c
+++ b/tools/power/cpupower/utils/helpers/cpuid.c
@@ -8,7 +8,7 @@
 #include "helpers/helpers.h"
 
 static const char *cpu_vendor_table[X86_VENDOR_MAX] = {
-   "Unknown", "GenuineIntel", "AuthenticAMD",
+   "Unknown", "GenuineIntel", "AuthenticAMD", "HygonGenuine",
 };
 
 #if defined(__i386__) || defined(__x86_64__)
@@ -109,6 +109,7 @@ int get_cpu_info(struct cpupower_cpu_info *cpu_info)
fclose(fp);
/* Get some useful CPU capabilities from cpuid */
if (cpu_info->vendor != X86_VENDOR_AMD &&
+   cpu_info->vendor != X86_VENDOR_HYGON &&
cpu_info->vendor != X86_VENDOR_INTEL)
return ret;
 
@@ -124,8 +125,9 @@ int get_cpu_info(struct cpupower_cpu_info *cpu_info)
if (cpuid_level >= 6 && (cpuid_ecx(6) & 0x1))
cpu_info->caps |= CPUPOWER_CAP_APERF;
 
-   /* AMD Boost state enable/disable register */
-   if (cpu_info->vendor == X86_VENDOR_AMD) {
+   /* AMD or Hygon Boost state enable/disable register */
+   if (cpu_info->vendor == X86_VENDOR_AMD ||
+   cpu_info->vendor == X86_VENDOR_HYGON) {
if (ext_cpuid_level >= 0x8007 &&
(cpuid_edx(0x8007) & (1 << 9)))
cpu_info->caps |= CPUPOWER_CAP_AMD_CBP;
diff --git a/tools/power/cpupower/utils/helpers/helpers.h 
b/tools/power/cpupower/utils/helpers/helpers.h
index 41da392..9021396 100644
--- a/tools/power/cpupower/utils/helpers/helpers.h
+++ b/tools/power/cpupower/utils/helpers/helpers.h
@@ -61,7 +61,7 @@ extern int be_verbose;
 
 /* cpuid and cpuinfo helpers  **/
 enum cpupower_cpu_vendor {X86_VENDOR_UNKNOWN = 0, X86_VENDOR_INTEL,
- X86_VENDOR_AMD, X86_VENDOR_MAX};
+ X86_VENDOR_AMD, X86_VENDOR_HYGON, X86_VENDOR_MAX};
 
 #define CPUPOWER_CAP_INV_TSC   0x0001
 #define CPUPOWER_CAP_APERF 0x0002
diff --git a/tools/power/cpupower/utils/helpers/misc.c 
b/tools/power/cpupower/utils/helpers/misc.c
index 80fdf55..f406adc 100644
--- a/t

[PATCH v6 13/16] ACPI, x86: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana CPU has NONSTOP TSC feature, so enable the ACPI
driver support to it.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Pu Wen 
---
 drivers/acpi/acpi_pad.c   | 1 +
 drivers/acpi/processor_idle.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index 552c1f7..a47676a 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -70,6 +70,7 @@ static void power_saving_mwait_init(void)
 
 #if defined(CONFIG_X86)
switch (boot_cpu_data.x86_vendor) {
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
/*
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index abb559c..b2131c4 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -205,6 +205,7 @@ static void lapic_timer_state_broadcast(struct 
acpi_processor *pr,
 static void tsc_check_state(int state)
 {
switch (boot_cpu_data.x86_vendor) {
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
case X86_VENDOR_CENTAUR:
-- 
2.7.4

[PATCH v6 15/16] EDAC, amd64: Add Hygon Dhyana support

[Pu Wen]

To make AMD64 EDAC and MCE drivers working on Hygon platforms, add
support for Hygon Dhyana CPU by using the code path of AMD family
17h.

Signed-off-by: Pu Wen 
---
 drivers/edac/amd64_edac.c | 8 +++-
 drivers/edac/mce_amd.c| 4 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 18aeabb..bf3314b 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -211,7 +211,7 @@ static int __set_scrub_rate(struct amd64_pvt *pvt, u32 
new_bw, u32 min_rate)
 
scrubval = scrubrates[i].scrubval;
 
-   if (pvt->fam == 0x17) {
+   if (pvt->fam == 0x17 || pvt->fam == 0x18) {
__f17h_set_scrubval(pvt, scrubval);
} else if (pvt->fam == 0x15 && pvt->model == 0x60) {
f15h_select_dct(pvt, 0);
@@ -264,6 +264,7 @@ static int get_scrub_rate(struct mem_ctl_info *mci)
break;
 
case 0x17:
+   case 0x18:
amd64_read_pci_cfg(pvt->F6, F17H_SCR_BASE_ADDR, &scrubval);
if (scrubval & BIT(0)) {
amd64_read_pci_cfg(pvt->F6, F17H_SCR_LIMIT_ADDR, 
&scrubval);
@@ -1044,6 +1045,7 @@ static void determine_memory_type(struct amd64_pvt *pvt)
goto ddr3;
 
case 0x17:
+   case 0x18:
if ((pvt->umc[0].dimm_cfg | pvt->umc[1].dimm_cfg) & BIT(5))
pvt->dram_type = MEM_LRDDR4;
else if ((pvt->umc[0].dimm_cfg | pvt->umc[1].dimm_cfg) & BIT(4))
@@ -3188,8 +3190,11 @@ static struct amd64_family_type *per_family_init(struct 
amd64_pvt *pvt)
break;
 
case 0x17:
+   case 0x18:
fam_type= &family_types[F17_CPUS];
pvt->ops= &family_types[F17_CPUS].ops;
+   if (pvt->fam == 0x18)
+   family_types[F17_CPUS].ctl_name = "F18h";
break;
 
default:
@@ -3428,6 +3433,7 @@ static const struct x86_cpu_id amd64_cpuids[] = {
{ X86_VENDOR_AMD, 0x15, X86_MODEL_ANY,  X86_FEATURE_ANY, 0 },
{ X86_VENDOR_AMD, 0x16, X86_MODEL_ANY,  X86_FEATURE_ANY, 0 },
{ X86_VENDOR_AMD, 0x17, X86_MODEL_ANY,  X86_FEATURE_ANY, 0 },
+   { X86_VENDOR_HYGON, 0x18, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
{ }
 };
 MODULE_DEVICE_TABLE(x86cpu, amd64_cpuids);
diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
index 2ab4d61..c605089 100644
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -1059,7 +1059,8 @@ static int __init mce_amd_init(void)
 {
struct cpuinfo_x86 *c = &boot_cpu_data;
 
-   if (c->x86_vendor != X86_VENDOR_AMD)
+   if (c->x86_vendor != X86_VENDOR_AMD &&
+   c->x86_vendor != X86_VENDOR_HYGON)
return -ENODEV;
 
fam_ops = kzalloc(sizeof(struct amd_decoder_ops), GFP_KERNEL);
@@ -1113,6 +1114,7 @@ static int __init mce_amd_init(void)
break;
 
case 0x17:
+   case 0x18:
xec_mask = 0x3f;
if (!boot_cpu_has(X86_FEATURE_SMCA)) {
printk(KERN_WARNING "Decoding supported only on 
Scalable MCA processors.\n");
-- 
2.7.4

[PATCH v6 14/16] cpufreq, x86: Add Hygon Dhyana support

[Pu Wen]

As the Hygon Dhyana CPU support ACPI P-States feature, and there is
SMBus device(PCI device ID 0x790b) on Hygon platform, so add Hygon
Dhyana support to the cpufreq driver by using the code path of AMD
family 17h.

Acked-by: Rafael J. Wysocki 
Signed-off-by: Pu Wen 
---
 drivers/cpufreq/acpi-cpufreq.c | 5 +
 drivers/cpufreq/amd_freq_sensitivity.c | 9 +++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b61f4ec..d62fd37 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -61,6 +61,7 @@ enum {
 
 #define INTEL_MSR_RANGE(0x)
 #define AMD_MSR_RANGE  (0x7)
+#define HYGON_MSR_RANGE(0x7)
 
 #define MSR_K7_HWCR_CPB_DIS(1ULL << 25)
 
@@ -95,6 +96,7 @@ static bool boost_state(unsigned int cpu)
rdmsr_on_cpu(cpu, MSR_IA32_MISC_ENABLE, &lo, &hi);
msr = lo | ((u64)hi << 32);
return !(msr & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
rdmsr_on_cpu(cpu, MSR_K7_HWCR, &lo, &hi);
msr = lo | ((u64)hi << 32);
@@ -113,6 +115,7 @@ static int boost_set_msr(bool enable)
msr_addr = MSR_IA32_MISC_ENABLE;
msr_mask = MSR_IA32_MISC_ENABLE_TURBO_DISABLE;
break;
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
msr_addr = MSR_K7_HWCR;
msr_mask = MSR_K7_HWCR_CPB_DIS;
@@ -225,6 +228,8 @@ static unsigned extract_msr(struct cpufreq_policy *policy, 
u32 msr)
 
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
msr &= AMD_MSR_RANGE;
+   else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+   msr &= HYGON_MSR_RANGE;
else
msr &= INTEL_MSR_RANGE;
 
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index be926d9..4ac7c3c 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -111,11 +111,16 @@ static int __init amd_freq_sensitivity_init(void)
 {
u64 val;
struct pci_dev *pcidev;
+   unsigned int pci_vendor;
 
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   pci_vendor = PCI_VENDOR_ID_AMD;
+   else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+   pci_vendor = PCI_VENDOR_ID_HYGON;
+   else
return -ENODEV;
 
-   pcidev = pci_get_device(PCI_VENDOR_ID_AMD,
+   pcidev = pci_get_device(pci_vendor,
PCI_DEVICE_ID_AMD_KERNCZ_SMBUS, NULL);
 
if (!pcidev) {
-- 
2.7.4

Re: [PATCH v4 2/2] tty/serial: atmel: add ISO7816 support

[Richard Genoud]

Hi, Ludovic,

On 06/09/2018 15:42, Ludovic Desroches wrote:
> From: Nicolas Ferre 
> 
> When mode is set in atmel_config_iso7816() we backup last RS232 mode
> for coming back to this mode if requested.
> Also allow setup of T=0 and T=1 parameter and basic support in set_termios
> function as well.
> 
> Signed-off-by: Nicolas Ferre 
> [ludovic.desroc...@microchip.com: rebase, add check on fidi ratio, checkpatch 
> fixes]
> Signed-off-by: Ludovic Desroches 

This seems ok for me.

Acked-by: Richard Genoud 

Thanks !

Re: [PATCH] Revert "x86/tsc: Consolidate init code"

[Pasha Tatashin]

Hi Ville,


The failure is surprising, because the commit is tiny, and almost does
not change the code logic.

From looking through the commit, the only functional difference this
commit makes is:

static_branch_enable(&__use_tsc) was called unconditionally from
tsc_init(), but after the commit only when tsc_khz == 0.

I wonder if on p3 static_branch_enable(&__use_tsc) fails to enable
early, when it supposed to? But, I would first try to make that
unconditional call again, and see if this fixes the problem, and then
figure out why it was not enabled when it was supposed to.

So, in tsc_init(void)

First try to add this one line back:

cyc2ns_init_secondary_cpus();
-   static_branch_enable(&__use_tsc);


See if it fixes everything, and lets work from there.

Thank you,
Pavel

On 9/10/18 8:48 AM, Thomas Gleixner wrote:
> Ville,
> 
> On Mon, 10 Sep 2018, Ville Syrjala wrote:
> 
>> From: Ville Syrjälä 
>>
>> This reverts commit 608008a45798fe9e2aee04f99b5270ea57c1376f.
>>
>> It breaks wifi on my pentium 3 Fujitsu-Siemens Lifebook S6010
>> laptop. Scanning for APs doesn't seem to work most of the time,
>> and, even when it manages to find some APs it never manages to
>> authenticate successfully. dmesg is just littered with:
>> "wlan0: send auth to ... (try 1/3)
>>  wlan0: send auth to ... (try 2/3)
>>  wlan0: send auth to ... (try 3/3)
>>  wlan0: authentication with ... timed out"
> 
> I asked for that before and I really do not understand why you do not even
> make an attempt to report an issue first and allow the developers to work
> with you to figure out what exactly is the problem. All you do is to send
> an revert patch with a changelog which describes symptoms and probably
> breaks more than it cures. Not really helpful, really.
> 
> It's surely helpful to know that you bisected it to that commit and
> reverting it helps. Can you please provide more detailes information like
> dmesg of an good and a bad boot?
> 
> Thanks,
> 
>   tglx
> 
> 
> 

[PATCH v6 10/16] x86/mce: Add Hygon Dhyana support to MCE infrastructure

[Pu Wen]

The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. To make MCE working on Hygon platforms, add vendor
checking for Hygon Dhyana to share the code path of AMD family 17h.

Signed-off-by: Pu Wen 
---
 arch/x86/include/asm/mce.h|  2 ++
 arch/x86/kernel/cpu/mcheck/mce-severity.c |  3 ++-
 arch/x86/kernel/cpu/mcheck/mce.c  | 20 +++-
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 3a17107..550f2c9 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -214,6 +214,8 @@ static inline void mce_amd_feature_init(struct cpuinfo_x86 
*c) { }
 static inline int umc_normaddr_to_sysaddr(u64 norm_addr, u16 nid, u8 umc, u64 
*sys_addr) { return -EINVAL; };
 #endif
 
+static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return 
mce_amd_feature_init(c); }
+
 int mce_available(struct cpuinfo_x86 *c);
 bool mce_is_memory_error(struct mce *m);
 
diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c 
b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index f34d89c..44396d5 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -336,7 +336,8 @@ int (*mce_severity)(struct mce *m, int tolerant, char 
**msg, bool is_excp) =
 
 void __init mcheck_vendor_init_severity(void)
 {
-   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+   boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
mce_severity = mce_severity_amd;
 }
 
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 953b3ce..909f1d7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -270,7 +270,7 @@ static void print_mce(struct mce *m)
 {
__print_mce(m);
 
-   if (m->cpuvendor != X86_VENDOR_AMD)
+   if (m->cpuvendor != X86_VENDOR_AMD && m->cpuvendor != X86_VENDOR_HYGON)
pr_emerg_ratelimited(HW_ERR "Run the above through 'mcelog 
--ascii'\n");
 }
 
@@ -508,9 +508,9 @@ static int mce_usable_address(struct mce *m)
 
 bool mce_is_memory_error(struct mce *m)
 {
-   if (m->cpuvendor == X86_VENDOR_AMD) {
+   if (m->cpuvendor == X86_VENDOR_AMD ||
+   m->cpuvendor == X86_VENDOR_HYGON) {
return amd_mce_is_memory_error(m);
-
} else if (m->cpuvendor == X86_VENDOR_INTEL) {
/*
 * Intel SDM Volume 3B - 15.9.2 Compound Error Codes
@@ -539,6 +539,9 @@ static bool mce_is_correctable(struct mce *m)
if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED)
return false;
 
+   if (m->cpuvendor == X86_VENDOR_HYGON && m->status & MCI_STATUS_DEFERRED)
+   return false;
+
if (m->status & MCI_STATUS_UC)
return false;
 
@@ -1705,7 +1708,7 @@ static int __mcheck_cpu_ancient_init(struct cpuinfo_x86 
*c)
  */
 static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
 {
-   if (c->x86_vendor == X86_VENDOR_AMD) {
+   if (c->x86_vendor == X86_VENDOR_AMD || c->x86_vendor == 
X86_VENDOR_HYGON) {
mce_flags.overflow_recov = !!cpu_has(c, 
X86_FEATURE_OVERFLOW_RECOV);
mce_flags.succor = !!cpu_has(c, X86_FEATURE_SUCCOR);
mce_flags.smca   = !!cpu_has(c, X86_FEATURE_SMCA);
@@ -1746,6 +1749,11 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
mce_amd_feature_init(c);
break;
}
+
+   case X86_VENDOR_HYGON:
+   mce_hygon_feature_init(c);
+   break;
+
case X86_VENDOR_CENTAUR:
mce_centaur_feature_init(c);
break;
@@ -1971,12 +1979,14 @@ static void mce_disable_error_reporting(void)
 static void vendor_disable_error_reporting(void)
 {
/*
-* Don't clear on Intel or AMD CPUs. Some of these MSRs are socket-wide.
+* Don't clear on Intel or AMD or Hygon CPUs. Some of these MSRs
+* are socket-wide.
 * Disabling them for just a single offlined CPU is bad, since it will
 * inhibit reporting for all shared resources on the socket like the
 * last level cache (LLC), the integrated memory controller (iMC), etc.
 */
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
+   boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ||
boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
return;
 
-- 
2.7.4

[PATCH v6 11/16] x86/kvm: Add Hygon Dhyana support to KVM infrastructure

[Pu Wen]

The Hygon Dhyana CPU has the SVM feature as AMD family 17h does.
So enable the KVM infrastructure support to it.

Reviewed-by: Borislav Petkov 
Signed-off-by: Pu Wen 
---
 arch/x86/include/asm/kvm_emulate.h |  4 
 arch/x86/include/asm/virtext.h |  5 +++--
 arch/x86/kvm/emulate.c | 11 ++-
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/kvm_emulate.h 
b/arch/x86/include/asm/kvm_emulate.h
index 0f82cd9..93c4bf5 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -364,6 +364,10 @@ struct x86_emulate_ctxt {
 #define X86EMUL_CPUID_VENDOR_AMDisbetterI_ecx 0x21726574
 #define X86EMUL_CPUID_VENDOR_AMDisbetterI_edx 0x74656273
 
+#define X86EMUL_CPUID_VENDOR_HygonGenuine_ebx 0x6f677948
+#define X86EMUL_CPUID_VENDOR_HygonGenuine_ecx 0x656e6975
+#define X86EMUL_CPUID_VENDOR_HygonGenuine_edx 0x6e65476e
+
 #define X86EMUL_CPUID_VENDOR_GenuineIntel_ebx 0x756e6547
 #define X86EMUL_CPUID_VENDOR_GenuineIntel_ecx 0x6c65746e
 #define X86EMUL_CPUID_VENDOR_GenuineIntel_edx 0x49656e69
diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index 0116b2e..e05e0d3 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -83,9 +83,10 @@ static inline void cpu_emergency_vmxoff(void)
  */
 static inline int cpu_has_svm(const char **msg)
 {
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) {
+   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) {
if (msg)
-   *msg = "not amd";
+   *msg = "not amd or hygon";
return 0;
}
 
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 106482d..34edf19 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2711,7 +2711,16 @@ static bool em_syscall_is_enabled(struct 
x86_emulate_ctxt *ctxt)
edx == X86EMUL_CPUID_VENDOR_AMDisbetterI_edx)
return true;
 
-   /* default: (not Intel, not AMD), apply Intel's stricter rules... */
+   /* Hygon ("HygonGenuine") */
+   if (ebx == X86EMUL_CPUID_VENDOR_HygonGenuine_ebx &&
+   ecx == X86EMUL_CPUID_VENDOR_HygonGenuine_ecx &&
+   edx == X86EMUL_CPUID_VENDOR_HygonGenuine_edx)
+   return true;
+
+   /*
+* default: (not Intel, not AMD, not Hygon), apply Intel's
+* stricter rules...
+*/
return false;
 }
 
-- 
2.7.4