Re: [PATCH] linux/bitmap.h: fix BITMAP_LAST_WORD_MASK

[Wei Wang]

On 08/07/2018 07:30 AM, Rasmus Villemoes wrote:

On 2018-07-26 12:15, Wei Wang wrote:

On 07/26/2018 05:37 PM, Yury Norov wrote:

On Thu, Jul 26, 2018 at 04:07:51PM +0800, Wei Wang wrote:

The existing BITMAP_LAST_WORD_MASK macro returns 0x if nbits is
0. This patch changes the macro to return 0 when there is no bit
needs to
be masked.

I think this is intentional behavour. Previous version did return ~0UL
explicitly in this case. See patch 89c1e79eb3023 (linux/bitmap.h: improve
BITMAP_{LAST,FIRST}_WORD_MASK) from Rasmus.

Yes, I saw that. But it seems confusing for the corner case that nbits=0
(no bits to mask), the macro returns with all the bits set.



Introducing conditional branch would affect performance. All existing
code checks nbits for 0 before handling last word where needed
explicitly. So I think we'd better change nothing here.

I think that didn't save the conditional branch essentially, because
it's just moved from inside this macro to the caller as you mentioned.
If callers missed the check for some reason and passed 0 to the macro,
they will get something unexpected.

Current callers like __bitmap_weight, __bitmap_equal, and others, they have

if (bits % BITS_PER_LONG)
 w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));

we could remove the "if" check by "w += hweight_long(bitmap[k] &
BITMAP_LAST_WORD_MASK(bits % BITS_PER_LONG));" the branch is the same.

Absolutely not! That would access bitmap[lim] (the final value of the k
variable) despite that word not being part of the bitmap.


Probably it's more clear to post the entire function here for a discussion:

int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
{
unsigned int k, lim = bits/BITS_PER_LONG;
int w = 0;

for (k = 0; k < lim; k++)
w += hweight_long(bitmap[k]);

if (bits % BITS_PER_LONG)
==>w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));

return w;
}

When the execution reaches "==>", isn't "k=lim"?

For example, assume bits = 70, then the point of that line is to check 
the remaining 6 bits (i.e. 70 % 64).


* BITMAP_LAST_WORD_MASK(70) is effectively the same as 
BITMAP_LAST_WORD_MASK(6).


If having doubts about the * statement above, please check below the old 
implementation (replaced by 89c1e79eb3), which has a more 
straightforward logic to understand


#define BITMAP_LAST_WORD_MASK(nbits)   \
( \
   ((nbits) % BITS_PER_LONG) ? \
   (1UL<<((nbits) % BITS_PER_LONG))-1 : ~0UL   \
)

I think having the branch in the macro would be much easier than having 
it in each caller.




More generally, look at the name of the macro: last_word_mask. It's a
mask to apply to the last word of a bitmap. If the bitmap happens to
consist of a multiple of BITS_PER_LONG bits, than that mask is and must
be ~0UL. So for nbits=64, 128, etc., that is what we want.


For nbits=64, it is correct to return ~0UL, since it just asks to check 
all the remaining 64 bits, thus keeping the entire 64 bits set.



OTOH, for nbits=0, there _is_ no last word (since there are no words at
all), so by the time you want to apply the result of
BITMAP_LAST_WORD_MASK(0) to anything, you already have a bug, probably
either having read or being about to write into bitmap[0], which you
cannot do. Please check that user-space port and see if there are bugs
of that kind.


Yes, some callers there don't check for nbits=0, that's why I think it 
is better to offload that check to the macro. The macro itself can be 
robust to handle all the cases.





So no, the existing users of BITMAP_LAST_WORD_MASK do not check for
nbits being zero, they check for whether there is a partial last word,
which is something different.


Yes, but "partial" could be "0". If the macro doesn't handle that case, 
I think that wouldn't be a robust macro.


We shouldn't assume how the callers will use this macro. Please check 
bitmap_shift_right, I think the bug is already there:


if (small_const_nbits(nbits))
*dst = (*src & BITMAP_LAST_WORD_MASK(nbits)) >> shift;

 *dst should be 0 if nbits=0, but nbits=0 will pass the 
small_const_nbits(nbits) check above, and BITMAP_LAST_WORD_MASK(0) 
returning 0x will take *src value to *dst.




And they mostly (those in lib/bitmap.c) do
that because they've already handled _all_ the full words. Then there
are some users in include/linux/bitmap.h, that check for
small_const_nbits(nbits), and in those cases, we really want ~0UL when
nbits is BITS_PER_LONG, because small_const_nbits implies there is
exactly one word. Yeah, there's an implicit assumption that the bitmap
routines are never called with a compile-time constant nbits==0 (see the
unconditional accesses to *src and *dst), but changing the semantics of
BITMAP_LAST_WORD_MASK and making it return different values for nbits=0
vs nbits=64 wouldn't fix that latent b

Re: [PATCH v2 4/4] userfaultfd: selftest: Cope if shmem doesn't support zeropage

[Mike Rapoport]

Hi,

On Fri, Aug 03, 2018 at 07:00:46PM -0300, Thiago Jung Bauermann wrote:
> If userfaultfd runs on a system that doesn't support UFFDIO_ZEROPAGE for
> shared memory, it currently ends with error code 1 which indicates test
> failure:
> 
>   # ./userfaultfd shmem 10 10
>   nr_pages: 160, nr_pages_per_cpu: 80
>   bounces: 9, mode: rnd poll, unexpected missing ioctl for anon memory
>   # echo $?
>   1
> 
> Change userfaultfd_zeropage_test() to return KSFT_SKIP to indicate that
> the test is being skipped.

I took a deeper look at what userfaultfd_zeropage_test() does and,
apparently, I've mislead you. The test checks if the range has
UFFDIO_ZEROPAGE and verifies that it works if yes; otherwise the test
verifies that EINVAL is returned.

Can you please check if the patch below works in your environment?

>From 7a34c84c0461b5073742275638c44b6535d19166 Mon Sep 17 00:00:00 2001
From: Mike Rapoport 
Date: Tue, 7 Aug 2018 09:44:19 +0300
Subject: [PATCH] userfaultfd: selftest: make supported range ioctl
 verification more robust

When userfaultfd tests runs on older kernel that does not support
UFFDIO_ZEROPAGE for shared memory it fails at the ioctl verification.

Split out the verification that supported ioctls are superset of the
expected ioctls and relax the checks for UFFDIO_ZEROPAGE for shared memory
areas.

Signed-off-by: Mike Rapoport 
---
 tools/testing/selftests/vm/userfaultfd.c | 63 +---
 1 file changed, 34 insertions(+), 29 deletions(-)

diff --git a/tools/testing/selftests/vm/userfaultfd.c 
b/tools/testing/selftests/vm/userfaultfd.c
index 7b8171e3128a..a64bc38bc0e1 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -271,6 +271,32 @@ static int my_bcmp(char *str1, char *str2, size_t n)
return 0;
 }
 
+static int verify_ioctls(unsigned long supported_ioctls)
+{
+   unsigned long expected_ioctls = uffd_test_ops->expected_ioctls;
+
+   if ((supported_ioctls & expected_ioctls) == expected_ioctls)
+   return 0;
+
+   /*
+* For older kernels shared memory may not have UFFDIO_ZEROPAGE.
+* In this case we just mask it out from the
+* expected_ioctls. The userfaultfd_zeropage_test will then
+* verify that an attempt to use UFFDIO_ZEROPAGE returns
+* EINVAL
+*/
+   if (test_type == TEST_SHMEM) {
+   expected_ioctls &= ~(1 << _UFFDIO_ZEROPAGE);
+   if ((supported_ioctls & expected_ioctls) == expected_ioctls) {
+   uffd_test_ops->expected_ioctls = expected_ioctls;
+   return 0;
+   }
+   }
+
+   fprintf(stderr, "unexpected missing ioctl\n");
+   return 1;
+}
+
 static void *locking_thread(void *arg)
 {
unsigned long cpu = (unsigned long) arg;
@@ -851,7 +877,6 @@ static int uffdio_zeropage(int ufd, unsigned long offset)
 static int userfaultfd_zeropage_test(void)
 {
struct uffdio_register uffdio_register;
-   unsigned long expected_ioctls;
 
printf("testing UFFDIO_ZEROPAGE: ");
fflush(stdout);
@@ -867,12 +892,8 @@ static int userfaultfd_zeropage_test(void)
if (ioctl(uffd, UFFDIO_REGISTER, &uffdio_register))
fprintf(stderr, "register failure\n"), exit(1);
 
-   expected_ioctls = uffd_test_ops->expected_ioctls;
-   if ((uffdio_register.ioctls & expected_ioctls) !=
-   expected_ioctls)
-   fprintf(stderr,
-   "unexpected missing ioctl for anon memory\n"),
-   exit(1);
+   if (verify_ioctls(uffdio_register.ioctls))
+   return 1;
 
if (uffdio_zeropage(uffd, 0)) {
if (my_bcmp(area_dst, zeropage, page_size))
@@ -887,7 +908,6 @@ static int userfaultfd_zeropage_test(void)
 static int userfaultfd_events_test(void)
 {
struct uffdio_register uffdio_register;
-   unsigned long expected_ioctls;
unsigned long userfaults;
pthread_t uffd_mon;
int err, features;
@@ -912,12 +932,8 @@ static int userfaultfd_events_test(void)
if (ioctl(uffd, UFFDIO_REGISTER, &uffdio_register))
fprintf(stderr, "register failure\n"), exit(1);
 
-   expected_ioctls = uffd_test_ops->expected_ioctls;
-   if ((uffdio_register.ioctls & expected_ioctls) !=
-   expected_ioctls)
-   fprintf(stderr,
-   "unexpected missing ioctl for anon memory\n"),
-   exit(1);
+   if (verify_ioctls(uffdio_register.ioctls))
+   return 1;
 
if (pthread_create(&uffd_mon, &attr, uffd_poll_thread, NULL))
perror("uffd_poll_thread create"), exit(1);
@@ -947,7 +963,6 @@ static int userfaultfd_events_test(void)
 static int userfaultfd_sig_test(void)
 {
struct uffdio_register uffdio_register;
-   unsigned long expected_ioctls;
unsigned long userfaults;
pthread_t uffd_mon;
int

[PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

[Chao Fan]

If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable
memory regions is not zero. Calculate the intersection between memory
regions from e820/efi memory table and immovable memory regions.
Or go on the old code.

Rename process_mem_region to slots_count to match slots_fetch_random,
and name new function as process_mem_region.

Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/kaslr.c | 66 ++--
 1 file changed, 55 insertions(+), 11 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 720878f967a3..9c6e24a23a2d 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -635,9 +635,9 @@ static unsigned long slots_fetch_random(void)
return 0;
 }
 
-static void process_mem_region(struct mem_vector *entry,
-  unsigned long minimum,
-  unsigned long image_size)
+static void slots_count(struct mem_vector *entry,
+   unsigned long minimum,
+   unsigned long image_size)
 {
struct mem_vector region, overlap;
struct slot_area slot_area;
@@ -714,6 +714,56 @@ static void process_mem_region(struct mem_vector *entry,
}
 }
 
+static bool process_mem_region(struct mem_vector *region,
+  unsigned long long minimum,
+  unsigned long long image_size)
+{
+#ifdef CONFIG_MEMORY_HOTREMOVE
+   /*
+* If immovable memory found, filter the intersection between
+* immovable memory and region to slots_count.
+* Otherwise, go on old code.
+*/
+   if (num_immovable_mem > 0) {
+   int i;
+
+   for (i = 0; i < num_immovable_mem; i++) {
+   struct mem_vector entry;
+   unsigned long long start, end, entry_end, region_end;
+
+   start = immovable_mem[i].start;
+   end = start + immovable_mem[i].size;
+   region_end = region->start + region->size;
+
+   entry.start = clamp(region->start, start, end);
+   entry_end = clamp(region_end, start, end);
+
+   if (entry.start + image_size < entry_end) {
+   entry.size = entry_end - entry.start;
+   slots_count(&entry, minimum, image_size);
+
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted e820/efi memmap 
scan (slot_areas full)!\n");
+   return 1;
+   }
+   }
+   }
+   return 0;
+   }
+#endif
+   /*
+* If no immovable memory found, or MEMORY_HOTREMOVE disabled,
+* walk all the regions, so use region directely.
+*/
+   slots_count(region, minimum, image_size);
+
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted e820/efi memmap scan (slot_areas 
full)!\n");
+   return 1;
+   }
+   return 0;
+}
+
 #ifdef CONFIG_EFI
 /*
  * Returns true if mirror region found (and must have been processed
@@ -779,11 +829,8 @@ process_efi_entries(unsigned long minimum, unsigned long 
image_size)
 
region.start = md->phys_addr;
region.size = md->num_pages << EFI_PAGE_SHIFT;
-   process_mem_region(®ion, minimum, image_size);
-   if (slot_area_index == MAX_SLOT_AREA) {
-   debug_putstr("Aborted EFI scan (slot_areas full)!\n");
+   if (process_mem_region(®ion, minimum, image_size))
break;
-   }
}
return true;
 }
@@ -810,11 +857,8 @@ static void process_e820_entries(unsigned long minimum,
continue;
region.start = entry->addr;
region.size = entry->size;
-   process_mem_region(®ion, minimum, image_size);
-   if (slot_area_index == MAX_SLOT_AREA) {
-   debug_putstr("Aborted e820 scan (slot_areas full)!\n");
+   if (process_mem_region(®ion, minimum, image_size))
break;
-   }
}
 }
 
-- 
2.17.1

[PATCH v5 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

[Chao Fan]

If 'CONFIG_MEMORY_HOTREMOVE' specified, walk the acpi srat memory
tables, store the immovable memory regions, so that kaslr can get
the information abouth where can be selected or not.
If 'CONFIG_MEMORY_HOTREMOVE' not specified, go on the old code.

Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/kaslr.c | 59 
 1 file changed, 59 insertions(+)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 302517929932..720878f967a3 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -31,6 +31,7 @@
 
 #include "misc.h"
 #include "error.h"
+#include "acpitb.h"
 #include "../string.h"
 
 #include 
@@ -104,6 +105,14 @@ static bool memmap_too_large;
 /* Store memory limit specified by "mem=nn[KMG]" or "memmap=nn[KMG]" */
 static unsigned long long mem_limit = ULLONG_MAX;
 
+#ifdef CONFIG_MEMORY_HOTREMOVE
+/* Store the immovable memory regions */
+static struct mem_vector immovable_mem[MAX_NUMNODES*2];
+
+/* Store the amount of immovable memory regions */
+static int num_immovable_mem;
+#endif
+
 
 enum mem_avoid_index {
MEM_AVOID_ZO_RANGE = 0,
@@ -298,6 +307,51 @@ static int handle_mem_options(void)
return 0;
 }
 
+#ifdef CONFIG_MEMORY_HOTREMOVE
+/*
+ * According to ACPI table, filter the immvoable memory regions
+ * and store them in immovable_mem[].
+ */
+static void handle_immovable_mem(void)
+{
+   char *args = (char *)get_cmd_line_ptr();
+   struct acpi_table_header *table_header;
+   struct acpi_subtable_header *table;
+   struct acpi_srat_mem_affinity *ma;
+   unsigned long table_end;
+   int i = 0;
+
+   if (!strstr(args, "movable_node"))
+   return;
+
+   table_header = get_acpi_srat_table();
+   if (!table_header)
+   return;
+
+   table_end = (unsigned long)table_header + table_header->length;
+
+   table = (struct acpi_subtable_header *)
+   ((unsigned long)table_header + sizeof(struct acpi_table_srat));
+
+   while (((unsigned long)table) + table->length < table_end) {
+   if (table->type == 1) {
+   ma = (struct acpi_srat_mem_affinity *)table;
+   if (!(ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE)) {
+   immovable_mem[i].start = ma->base_address;
+   immovable_mem[i].size = ma->length;
+   i++;
+   }
+
+   if (i >= MAX_NUMNODES*2)
+   break;
+   }
+   table = (struct acpi_subtable_header *)
+   ((unsigned long)table + table->length);
+   }
+   num_immovable_mem = i;
+}
+#endif
+
 /*
  * In theory, KASLR can put the kernel anywhere in the range of [16M, 64T).
  * The mem_avoid array is used to store the ranges that need to be avoided
@@ -421,6 +475,11 @@ static void mem_avoid_init(unsigned long input, unsigned 
long input_size,
/* Mark the memmap regions we need to avoid */
handle_mem_options();
 
+#ifdef CONFIG_MEMORY_HOTREMOVE
+   /* Mark the immovable regions we need to choose */
+   handle_immovable_mem();
+#endif
+
 #ifdef CONFIG_X86_VERBOSE_BOOTUP
/* Make sure video RAM can be used. */
add_identity_map(0, PMD_SIZE);
-- 
2.17.1

[PATCH v5 2/4] x86/boot: Add acpitb.c to parse acpi tables

[Chao Fan]

Imitate the ACPI code to parse ACPI tables. Functions are simplified
cause some operations are not needed here.
And also, this method won't influence the initialization of ACPI.

Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/Makefile |   4 +
 arch/x86/boot/compressed/acpitb.c | 272 ++
 2 files changed, 276 insertions(+)
 create mode 100644 arch/x86/boot/compressed/acpitb.c

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 169c2feda14a..a382bb50f599 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -83,6 +83,10 @@ ifdef CONFIG_X86_64
vmlinux-objs-y += $(obj)/pgtable_64.o
 endif
 
+ifdef CONFIG_MEMORY_HOTREMOVE
+vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/acpitb.o
+endif
+
 $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
 
 vmlinux-objs-$(CONFIG_EFI_STUB) += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o \
diff --git a/arch/x86/boot/compressed/acpitb.c 
b/arch/x86/boot/compressed/acpitb.c
new file mode 100644
index ..a1ec0d9313fe
--- /dev/null
+++ b/arch/x86/boot/compressed/acpitb.c
@@ -0,0 +1,272 @@
+// SPDX-License-Identifier: GPL-2.0
+#define BOOT_CTYPE_H
+#include "misc.h"
+#include "acpitb.h"
+
+#include 
+#include 
+#include 
+
+extern unsigned long get_cmd_line_ptr(void);
+
+#ifdef CONFIG_EFI
+/* Search EFI table for rsdp table. */
+static bool efi_get_rsdp_addr(acpi_physical_address *rsdp_addr)
+{
+   efi_system_table_t *systab;
+   bool find_rsdp = false;
+   bool efi_64 = false;
+   void *config_tables;
+   struct efi_info *e;
+   char *sig;
+   int size;
+   int i;
+
+   e = &boot_params->efi_info;
+   sig = (char *)&e->efi_loader_signature;
+
+   if (!strncmp(sig, EFI64_LOADER_SIGNATURE, 4))
+   efi_64 = true;
+   else if (!strncmp(sig, EFI32_LOADER_SIGNATURE, 4))
+   efi_64 = false;
+   else {
+   debug_putstr("Wrong EFI loader signature.\n");
+   return false;
+   }
+
+   /* Get systab from boot params. Based on efi_init(). */
+#ifdef CONFIG_X86_32
+   if (e->efi_systab_hi || e->efi_memmap_hi) {
+   debug_putstr("Table located above 4GB, disabling EFI.\n");
+   return false;
+   }
+   systab = (efi_system_table_t *)e->efi_systab;
+#else
+   systab = (efi_system_table_t *)(
+   e->efi_systab | ((__u64)e->efi_systab_hi<<32));
+#endif
+
+   if (systab == NULL)
+   return false;
+
+   /*
+* Get EFI tables from systab. Based on efi_config_init() and
+* efi_config_parse_tables(). Only dig the useful tables but not
+* do the initialization jobs.
+*/
+   size = efi_64 ? sizeof(efi_config_table_64_t) :
+   sizeof(efi_config_table_32_t);
+
+   for (i = 0; i < systab->nr_tables; i++) {
+   efi_guid_t guid;
+   unsigned long table;
+
+   config_tables = (void *)(systab->tables + size * i);
+   if (efi_64) {
+   efi_config_table_64_t *tmp_table;
+
+   tmp_table = (efi_config_table_64_t *)config_tables;
+   guid = tmp_table->guid;
+   table = tmp_table->table;
+#ifndef CONFIG_64BIT
+   if (table >> 32) {
+   debug_putstr("Table located above 4G, disabling 
EFI.\n");
+   return false;
+   }
+#endif
+   } else {
+   efi_config_table_32_t *tmp_table;
+
+   tmp_table = (efi_config_table_32_t *)config_tables;
+   guid = tmp_table->guid;
+   table = tmp_table->table;
+   }
+
+   /*
+* Get rsdp from EFI tables.
+* If ACPI20 table found, use it and return true.
+* If ACPI20 table not found, but ACPI table found,
+* use the ACPI table and return true.
+* If neither ACPI table nor ACPI20 table found,
+* return false.
+*/
+   if (!(efi_guidcmp(guid, ACPI_TABLE_GUID))) {
+   *rsdp_addr = (acpi_physical_address)table;
+   find_rsdp = true;
+   } else if (!(efi_guidcmp(guid, ACPI_20_TABLE_GUID))) {
+   *rsdp_addr = (acpi_physical_address)table;
+   return true;
+   }
+   }
+   return find_rsdp;
+}
+#else
+static bool efi_get_rsdp_addr(acpi_physical_address *rsdp_addr)
+{
+   return false;
+}
+#endif
+
+static u8 checksum(u8 *buffer, u32 length)
+{
+   u8 sum = 0;
+   u8 *end = buffer + length;
+
+   while (buffer < end)
+   sum = (u8)(sum + *(buffer++));
+
+   return sum;
+}
+
+/*
+ * Used to search a block of memory for the RSDP signat

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

[Chao Fan]

In order to parse ACPI tables, reuse the head file linux/acpi.h,
so that the files in 'compressed' directory can read ACPI table
by including this head file.

Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/acpitb.h | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 arch/x86/boot/compressed/acpitb.h

diff --git a/arch/x86/boot/compressed/acpitb.h 
b/arch/x86/boot/compressed/acpitb.h
new file mode 100644
index ..f8ab6e5b3e06
--- /dev/null
+++ b/arch/x86/boot/compressed/acpitb.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include 
+
+#define ACPI_MAX_TABLES128
+
+/* Function to get ACPI SRAT table pointer. */
+struct acpi_table_header *get_acpi_srat_table(void);
-- 
2.17.1

[PATCH v5 0/4] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory.

[Chao Fan]

***Background:
People reported that kaslr may randomly chooses some positions
which are located in movable memory regions. This will break memory
hotplug feature and make the memory can't be removed.

***Solutions:
There should be a method to limit kaslr to choosing immovable memory
regions, so there are 2 solutions:
1) Add a kernel parameter to specify the memory regions.
2) Get the information of memory hotremove, then kaslr will know the
   right regions.
In method 2, information about memory hot remove is in ACPI
tables, which will be parsed after 'start_kernel', kaslr can't get
the information.
In method 1, users should know the regions address and specify in
kernel parameter.

In the earliest time, I tried to dig ACPI tabls to solve this problem.
But I didn't splite the code in 'compressed/' and ACPI code, so the patch
is hard to follow so refused by community.
Somebody suggest to add a kernel parameter to specify the
immovable memory so that limit kaslr in these regions. Then I make
a patchset. After several versions, Ingo gave a suggestion:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1634024.html
Follow Ingo's suggestion, imitate the ACPI code to parse the acpi
tables, so that the kaslr can get necessary memory information in
ACPI tables.
Since I think ACPI code is independent part, so copy the codes
and functions to 'compressed/' directory, so that kaslr won't
influence the initialization of ACPI.

PATCH 1/4 Reuse the head file of linux/acpi.h, and copy a fcuntion from
  ACPI code.
PATCH 2/4 Functions to parse ACPI code.
PATCH 3/4 If 'CONFIG_MEMORY_HOTREMOVE' specified, walk all nodes and
  store the information of immovable memory regions.
PATCH 4/4 According to the immovable memory regions, filter the
  immovable regions which KASLR can choose.

***Test results:
 - I did a very simple test, and it can get the memory information in
   bios and efi KVM guest machine, and put it by early printk. But no
   more tests, so it's with RFC tag.

v1->v2:
 -  Simplify some code.
Follow Baoquan He's suggestion:
 - Reuse the head file of acpi code.

v2->v3:
 - Test in more conditions, so remove the 'RFC' tag.
 - Change some comments.

v3->v4:
Follow Thomas Gleixner's suggetsion:
 - Put the whole efi related function into #define CONFIG_EFI and return
   false in the other stub.
 - Simplify two functions in head file.

v4->v5:
Follow Dou Liyang's suggestion:
 - Add more comments about some functions based on kernel code.
 - Change some typo in comments.
 - Clean useless variable.
 - Add check for the boundary of array.
 - Add check for 'movable_node' parameter

Any comments will be welcome.


Chao Fan (4):
  x86/boot: Add acpitb.h to help parse acpi tables
  x86/boot: Add acpitb.c to parse acpi tables
  x86/boot/KASLR: Walk srat tables to filter immovable memory
  x86/boot/KASLR: Limit kaslr to choosing the immovable memory

 arch/x86/boot/compressed/Makefile |   4 +
 arch/x86/boot/compressed/acpitb.c | 272 ++
 arch/x86/boot/compressed/acpitb.h |   7 +
 arch/x86/boot/compressed/kaslr.c  | 125 --
 4 files changed, 397 insertions(+), 11 deletions(-)
 create mode 100644 arch/x86/boot/compressed/acpitb.c
 create mode 100644 arch/x86/boot/compressed/acpitb.h

-- 
2.17.1

Re: [PATCH v2 3/4] userfaultfd: selftest: Skip test if a feature isn't supported

[Mike Rapoport]

On Fri, Aug 03, 2018 at 07:00:45PM -0300, Thiago Jung Bauermann wrote:
> If userfaultfd runs on a system that doesn't support some feature it is
> trying to test, it currently ends with error code 1 which indicates
> test failure:
> 
>   # ./userfaultfd anon 10 10
>   nr_pages: 160, nr_pages_per_cpu: 80
>   bounces: 9, mode: rnd poll, userfaults: 7 59
>   bounces: 8, mode: poll, userfaults: 0 0
>   bounces: 7, mode: rnd racing ver, userfaults: 45 2
>   bounces: 6, mode: racing ver, userfaults: 3 1
>   bounces: 5, mode: rnd ver, userfaults: 55 32
>   bounces: 4, mode: ver, userfaults: 69 0
>   bounces: 3, mode: rnd racing, userfaults: 1 1
>   bounces: 2, mode: racing, userfaults: 65 0
>   bounces: 1, mode: rnd, userfaults: 44 1
>   bounces: 0, mode:, userfaults: 3 2
>   testing UFFDIO_ZEROPAGE: done.
>   testing signal delivery: UFFDIO_API
>   # echo $?
>   1
> 
> Make each test return KSFT_SKIP instead, which is more accurate since it is
> not a real test failure and try to run the other tests which may still
> work:
> 
>   # ./userfaultfd anon 10 10
>   nr_pages: 160, nr_pages_per_cpu: 80
>   bounces: 9, mode: rnd poll, userfaults: 65 27
>   bounces: 8, mode: poll, userfaults: 0 0
>   bounces: 7, mode: rnd racing ver, userfaults: 60 29
>   bounces: 6, mode: racing ver, userfaults: 58 1
>   bounces: 5, mode: rnd ver, userfaults: 69 3
>   bounces: 4, mode: ver, userfaults: 35 27
>   bounces: 3, mode: rnd racing, userfaults: 44 0
>   bounces: 2, mode: racing, userfaults: 40 25
>   bounces: 1, mode: rnd, userfaults: 2 1
>   bounces: 0, mode:, userfaults: 0 1
>   testing UFFDIO_ZEROPAGE: done.
>   testing signal delivery: UFFDIO_API: Invalid argument
>   testing events (fork, remap, remove): userfaults: 160
>   # echo $?
>   0
> 
> While at it, also improve the error message of the ioctl(UFFDIO_API) call.
> 
> Signed-off-by: Thiago Jung Bauermann 

Acked-by: Mike Rapoport 

> ---
>  tools/testing/selftests/vm/userfaultfd.c | 42 
> +++-
>  1 file changed, 30 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/testing/selftests/vm/userfaultfd.c 
> b/tools/testing/selftests/vm/userfaultfd.c
> index d728bd1cb33c..c84e44ddf314 100644
> --- a/tools/testing/selftests/vm/userfaultfd.c
> +++ b/tools/testing/selftests/vm/userfaultfd.c
> @@ -647,8 +647,11 @@ static int userfaultfd_open(int features)
>   uffdio_api.api = UFFD_API;
>   uffdio_api.features = features;
>   if (ioctl(uffd, UFFDIO_API, &uffdio_api)) {
> - fprintf(stderr, "UFFDIO_API\n");
> - return 1;
> + int errnum = errno;
> +
> + perror("UFFDIO_API");
> +
> + return errnum == EINVAL ? KSFT_SKIP : 1;
>   }
>   if (uffdio_api.api != UFFD_API) {
>   fprintf(stderr, "UFFDIO_API error %Lu\n", uffdio_api.api);
> @@ -854,6 +857,7 @@ static int userfaultfd_zeropage_test(void)
>  {
>   struct uffdio_register uffdio_register;
>   unsigned long expected_ioctls;
> + int err;
> 
>   printf("testing UFFDIO_ZEROPAGE: ");
>   fflush(stdout);
> @@ -861,8 +865,10 @@ static int userfaultfd_zeropage_test(void)
>   if (uffd_test_ops->release_pages(area_dst))
>   return 1;
> 
> - if (userfaultfd_open(0))
> - return 1;
> + err = userfaultfd_open(0);
> + if (err)
> + return err;
> +
>   uffdio_register.range.start = (unsigned long) area_dst;
>   uffdio_register.range.len = nr_pages * page_size;
>   uffdio_register.mode = UFFDIO_REGISTER_MODE_MISSING;
> @@ -904,8 +910,10 @@ static int userfaultfd_events_test(void)
> 
>   features = UFFD_FEATURE_EVENT_FORK | UFFD_FEATURE_EVENT_REMAP |
>   UFFD_FEATURE_EVENT_REMOVE;
> - if (userfaultfd_open(features))
> - return 1;
> + err = userfaultfd_open(features);
> + if (err)
> + return err;
> +
>   fcntl(uffd, F_SETFL, uffd_flags | O_NONBLOCK);
> 
>   uffdio_register.range.start = (unsigned long) area_dst;
> @@ -963,8 +971,9 @@ static int userfaultfd_sig_test(void)
>   return 1;
> 
>   features = UFFD_FEATURE_EVENT_FORK|UFFD_FEATURE_SIGBUS;
> - if (userfaultfd_open(features))
> - return 1;
> + err = userfaultfd_open(features);
> + if (err)
> + return err;
>   fcntl(uffd, F_SETFL, uffd_flags | O_NONBLOCK);
> 
>   uffdio_register.range.start = (unsigned long) area_dst;
> @@ -1029,8 +1038,9 @@ static int userfaultfd_stress(void)
>   if (!area_dst)
>   return 1;
> 
> - if (userfaultfd_open(0))
> - return 1;
> + err = userfaultfd_open(0);
> + if (err)
> + return err;
> 
>   count_verify = malloc(nr_pages * sizeof(unsigned long long));
>   if (!count_verify) {
> @@ -1201,8 +1211,16 @@ static int userfaultfd_stress(void)
>   return err;
> 
>   close(uffd);
> - return userfaultfd_zeropage_test() || userfaultfd_sig_test()
> - || userfaultfd_

Re: [PATCH v2 2/4] userfaultfd: selftest: Skip test if userfaultfd() syscall not supported

[Mike Rapoport]

On Fri, Aug 03, 2018 at 07:00:44PM -0300, Thiago Jung Bauermann wrote:
> Since there's no point in doing anything in this case, immediately exit the
> process.
> 
> And take the opportunity to improve the error message.
> 
> Before:
> 
>   # ./userfaultfd shmem 10 10
>   nr_pages: 160, nr_pages_per_cpu: 40
>   userfaultfd syscall not available in this kernel
>   # echo $?
>   1
> 
> After:
> 
>   # ./userfaultfd shmem 10 10
>   nr_pages: 160, nr_pages_per_cpu: 40
>   userfaultfd syscall not available in this kernel: Function not implemented
>   # echo $?
>   4
> 
> Suggested-by: Mike Rapoport 
> Signed-off-by: Thiago Jung Bauermann 

Acked-by: Mike Rapoport 

> ---
>  tools/testing/selftests/vm/userfaultfd.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/testing/selftests/vm/userfaultfd.c 
> b/tools/testing/selftests/vm/userfaultfd.c
> index e4099afe7557..d728bd1cb33c 100644
> --- a/tools/testing/selftests/vm/userfaultfd.c
> +++ b/tools/testing/selftests/vm/userfaultfd.c
> @@ -636,9 +636,11 @@ static int userfaultfd_open(int features)
> 
>   uffd = syscall(__NR_userfaultfd, O_CLOEXEC | O_NONBLOCK);
>   if (uffd < 0) {
> - fprintf(stderr,
> - "userfaultfd syscall not available in this kernel\n");
> - return 1;
> + int errnum = errno;
> +
> + perror("userfaultfd syscall not available in this kernel");
> +
> + exit(errnum == ENOSYS ? KSFT_SKIP : 1);
>   }
>   uffd_flags = fcntl(uffd, F_GETFD, NULL);
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 01/11] staging: fbtft: Changes udelay(n) to usleep_range(n, n + 1). - Style

[Dan Carpenter]

We need a commit message here.

On Tue, Aug 07, 2018 at 01:04:56AM -0300, Leonardo Brás wrote:
> Signed-off-by: Leonardo Brás 
> ---
>  drivers/staging/fbtft/fb_agm1264k-fl.c |  2 +-
>  drivers/staging/fbtft/fb_ra8875.c  |  4 ++--
>  drivers/staging/fbtft/fb_tinylcd.c |  2 +-
>  drivers/staging/fbtft/fb_upd161704.c   | 19 +--
>  drivers/staging/fbtft/fb_watterott.c   |  4 ++--
>  5 files changed, 15 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
> b/drivers/staging/fbtft/fb_agm1264k-fl.c
> index f6f30f5bf15a..c936950ce56d 100644
> --- a/drivers/staging/fbtft/fb_agm1264k-fl.c
> +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
> @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
>   dev_dbg(par->info->device, "%s()\n", __func__);
>  
>   gpio_set_value(par->gpio.reset, 0);
> - udelay(20);
> + usleep_range(20, 21);

Is this really the right range?  It feels tight.

>   gpio_set_value(par->gpio.reset, 1);
>   mdelay(120);

regards,
dan carpenter

Re: [PATCH v2 1/4] userfaultfd: selftest: Fix checking of userfaultfd_open() result

[Mike Rapoport]

On Fri, Aug 03, 2018 at 07:00:43PM -0300, Thiago Jung Bauermann wrote:
> If the userfaultfd test is run on a kernel with CONFIG_USERFAULTFD=n, it
> will report that the system call is not available yet go ahead and continue
> anyway:
> 
>   # ./userfaultfd anon 30 1
>   nr_pages: 480, nr_pages_per_cpu: 120
>   userfaultfd syscall not available in this kernel
>   bounces: 0, mode:, register failure
> 
> This is because userfaultfd_open() returns 0 on success and 1 on error but
> all callers assume that it returns < 0 on error.
> 
> Since the convention of the test as a whole is the one used by
> userfault_open(), fix its callers instead. Now the test behaves correctly:
> 
>   # ./userfaultfd anon 30 1
>   nr_pages: 480, nr_pages_per_cpu: 120
>   userfaultfd syscall not available in this kernel
> 
> Signed-off-by: Thiago Jung Bauermann 

Reviewed-by: Mike Rapoport 

> ---
>  tools/testing/selftests/vm/userfaultfd.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/testing/selftests/vm/userfaultfd.c 
> b/tools/testing/selftests/vm/userfaultfd.c
> index 7b8171e3128a..e4099afe7557 100644
> --- a/tools/testing/selftests/vm/userfaultfd.c
> +++ b/tools/testing/selftests/vm/userfaultfd.c
> @@ -859,7 +859,7 @@ static int userfaultfd_zeropage_test(void)
>   if (uffd_test_ops->release_pages(area_dst))
>   return 1;
> 
> - if (userfaultfd_open(0) < 0)
> + if (userfaultfd_open(0))
>   return 1;
>   uffdio_register.range.start = (unsigned long) area_dst;
>   uffdio_register.range.len = nr_pages * page_size;
> @@ -902,7 +902,7 @@ static int userfaultfd_events_test(void)
> 
>   features = UFFD_FEATURE_EVENT_FORK | UFFD_FEATURE_EVENT_REMAP |
>   UFFD_FEATURE_EVENT_REMOVE;
> - if (userfaultfd_open(features) < 0)
> + if (userfaultfd_open(features))
>   return 1;
>   fcntl(uffd, F_SETFL, uffd_flags | O_NONBLOCK);
> 
> @@ -961,7 +961,7 @@ static int userfaultfd_sig_test(void)
>   return 1;
> 
>   features = UFFD_FEATURE_EVENT_FORK|UFFD_FEATURE_SIGBUS;
> - if (userfaultfd_open(features) < 0)
> + if (userfaultfd_open(features))
>   return 1;
>   fcntl(uffd, F_SETFL, uffd_flags | O_NONBLOCK);
> 
> @@ -1027,7 +1027,7 @@ static int userfaultfd_stress(void)
>   if (!area_dst)
>   return 1;
> 
> - if (userfaultfd_open(0) < 0)
> + if (userfaultfd_open(0))
>   return 1;
> 
>   count_verify = malloc(nr_pages * sizeof(unsigned long long));

-- 
Sincerely yours,
Mike.

Re: [PATCH] arm64: clean the additional checks before calling ghes_notify_sea()

[gengdongjiu]

On 2018/8/6 22:26, Will Deacon wrote:
>> Will,
>>  This patch will be applied, right? thanks
> I haven't queued it in the arm64 tree, since it touches include/acpi/ghes.h
> and you don't have an ack from the acpi folks. I acked it so that you could
> route it via the acpi tree without me holding you up.

Thanks the explanation.
yes, this patch touches the "include/acpi/ghes.h", I will repost this patch to 
let acpi
folks review it.


> 
> Will
> 
 This cleanup is ever mentioned by Mark Rutland in [1]

Re: [PATCH v3 1/6] remoteproc: Introduce custom dump function for each remoteproc segment

[Vinod]

Hi Sibi,

On 27-07-18, 20:49, Sibi Sankar wrote:
> Introduce custom dump function per remoteproc segment. It is responsible
> for filling the device memory segment associated with coredump
> 
> Signed-off-by: Sibi Sankar 
> ---
>  drivers/remoteproc/remoteproc_core.c | 15 ++-
>  include/linux/remoteproc.h   |  3 +++
>  2 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 283b258f5e0f..ec56cd822b26 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1183,13 +1183,18 @@ static void rproc_coredump(struct rproc *rproc)
>   phdr->p_align = 0;
>  
>   ptr = rproc_da_to_va(rproc, segment->da, segment->size);
> - if (!ptr) {
> - dev_err(&rproc->dev,
> +
> + if (segment->dump) {
> + segment->dump(rproc, ptr, segment->size, data + offset);

Am not sure I follow, you are calling this w/o checking if ptr is valid,
so you maybe passing null to segment->dump() ?

> + } else {
> + if (!ptr) {
> + dev_err(&rproc->dev,
>   "invalid coredump segment (%pad, %zu)\n",
>   &segment->da, segment->size);
> - memset(data + offset, 0xff, segment->size);
> - } else {
> - memcpy(data + offset, ptr, segment->size);
> + memset(data + offset, 0xff, segment->size);
> + } else {
> + memcpy(data + offset, ptr, segment->size);
> + }

-- 
~Vinod

Re: [PATCH v3 00/13] ARM: davinci: remove duplicate aemif support

[Sekhar Nori]

Hi David,

On Monday 06 August 2018 10:05 PM, David Lechner wrote:
> On 07/10/2018 05:19 AM, Sekhar Nori wrote:
>> On Friday 06 July 2018 11:09 PM, David Lechner wrote:
>>> On 07/04/2018 01:35 AM, Sekhar Nori wrote:
 Hi David,

 On Monday 02 July 2018 09:02 PM, David Lechner wrote:
> On 07/02/2018 07:28 AM, Sekhar Nori wrote:
>> Hi David, Stephen,
>>
>> On Thursday 28 June 2018 03:27 PM, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski 
>>>
>>> This series moves all aemif/nand users to using the ti-aemif
>>> platform
>>> driver located in drivers/memory instead of the older API located in
>>> mach-davinci.
>>>
>>> First five patches add necessary changes to the clock driver. Next
>>> seven convert the board files to using the ti-aemif driver. Last
>>> patch
>>> removes now dead code.
>>
>> How do you want to handle this series? I can apply the series and
>> provide you an immutable branch on v4.18-rc1 with the clock patches
>> applied if that can work.
>
> Sounds good to me. But I'm new to this maintainer thing, so maybe
> there is something to consider that I haven't thought of?

 I don't think there is more to it. Ultimately there should not be two
 commits for the same patch. Either you can apply and share the
 commit to
 use or I can do that as well. I am equally fine either way.

 Regards,
 Sekhar

>>>
>>> I've created a branch for-sekhar at https://github.com/dlech/linux.git
>>> with the clk commits.
>>
>> Thanks. I merged commit f917ff75ac55b6d829c9d1142e83913064565d5b (top of
>> that branch) to my v4.19/soc branch. Please do let Stephen and Mike know
>> about this then when you send your stuff for v4.19.
>>
> 
> Since there have been no more clk-davinci patches for v4.19, I assume that
> it is OK to just let this go through the ARM tree via Sekhar?

Yes, that should be fine.

Thanks,
Sekhar

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

[skannan]

On 2018-08-02 14:00, skan...@codeaurora.org wrote:

On 2018-08-02 02:56, MyungJoo Ham wrote:
Many CPU architectures have caches that can scale independent of the 
CPUs.
Frequency scaling of the caches is necessary to make sure the cache 
is not
a performance bottleneck that leads to poor performance and power. 
The same

idea applies for RAM/DDR.

To achieve this, this patch adds a generic devfreq governor that 
takes the

current frequency of each CPU frequency domain and then adjusts the
frequency of the cache (or any devfreq device) based on the frequency 
of
the CPUs. It listens to CPU frequency transition notifiers to keep 
itself

up to date on the current CPU frequency.

To decide the frequency of the device, the governor does one of the
following:


This exactly has the same purpose with "passive" governor except for 
the

single part: passive governor depends on another devfreq driver, not
cpufreq driver.

If both governors have many features in common, can you merge them 
into one?
Passive governor also has "get_target_freq", which allows driver 
authors

to define the mapping.


Thanks for the review and pointing me to the passive governor. I agree
that at a high level they are both doing the same. I can certainly
stuff this CPU freq to dev freq mapping into passive governor, but I
think it'll just make one huge set of code that's harder to understand
and maintain because it trying to do different things under the hood.

There are also a bunch of complexities and optimizations that come
with the cpufreq-map governor that don't fit with the passive
governor.

1. It's not one CPU who's frequency we have to listen to. There are
multiple CPUs/policies we have to aggregate across.
2. We have to deal with big vs little having different needs/mappings.
3. Since it's always just CPUfreq, I can optimize the handling in the
transition notifiers. If I have 4 different devices that are scaled
based on CPU freq, I still use only 1 transition notifier. It becomes
a bit harder to do with the passive governor.
4. It requires that the device explicitly support the passive governor
and pick a mapping function. With cpufreq-map governor, the device
drivers don't need to make any changes. Whoever is making a
device/board can choose what devices to scale up base on CPU freq
based on their board and their needs. Even an end user can say, scale
the GPU based on my CPU based on interpolation if they choose to.
5. If a device has some other use for the private data, it can't work
with passive governor, but can work with cpufreq-map governor.
6. I also want to improve cpufreq-map governor to handle hotplug
correctly in later patches (needs more discussion) and that'll add
more complexity.

I think for these reasons we shouldn't combine these two governors.
Let me know what you think.


Friendly reminder.

Thanks,
Saravana

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

[Michal Hocko]

On Mon 06-08-18 15:19:06, Yang Shi wrote:
> 
> 
> On 8/6/18 1:52 PM, Michal Hocko wrote:
> > On Mon 06-08-18 13:48:35, Yang Shi wrote:
> > > 
> > > On 8/6/18 1:41 PM, Michal Hocko wrote:
> > > > On Mon 06-08-18 09:46:30, Yang Shi wrote:
> > > > > On 8/6/18 2:40 AM, Michal Hocko wrote:
> > > > > > On Fri 03-08-18 14:01:58, Yang Shi wrote:
> > > > > > > On 8/3/18 2:07 AM, Michal Hocko wrote:
> > > > > > > > On Fri 27-07-18 02:10:14, Yang Shi wrote:
> > > > [...]
> > > > > > > > > If the vma has VM_LOCKED | VM_HUGETLB | VM_PFNMAP or uprobe, 
> > > > > > > > > they are
> > > > > > > > > considered as special mappings. They will be dealt with 
> > > > > > > > > before zapping
> > > > > > > > > pages with write mmap_sem held. Basically, just update 
> > > > > > > > > vm_flags.
> > > > > > > > Well, I think it would be safer to simply fallback to the 
> > > > > > > > current
> > > > > > > > implementation with these mappings and deal with them on top. 
> > > > > > > > This would
> > > > > > > > make potential issues easier to bisect and partial reverts as 
> > > > > > > > well.
> > > > > > > Do you mean just call do_munmap()? It sounds ok. Although we may 
> > > > > > > waste some
> > > > > > > cycles to repeat what has done, it sounds not too bad since those 
> > > > > > > special
> > > > > > > mappings should be not very common.
> > > > > > VM_HUGETLB is quite spread. Especially for DB workloads.
> > > > > Wait a minute. In this way, it sounds we go back to my old 
> > > > > implementation
> > > > > with special handling for those mappings with write mmap_sem held, 
> > > > > right?
> > > > Yes, I would really start simple and add further enhacements on top.
> > > If updating vm_flags with read lock is safe in this case, we don't have to
> > > do this. The only reason for this special handling is about vm_flags 
> > > update.
> > Yes, maybe you are right that this is safe. I would still argue to have
> > it in a separate patch for easier review, bisectability etc...
> 
> Sorry, I'm a little bit confused. Do you mean I should have the patch
> *without* handling the special case (just like to assume it is safe to
> update vm_flags with read lock), then have the other patch on top of it,
> which simply calls do_munmap() to deal with the special cases?

Just skip those special cases in the initial implementation and handle
each special case in its own patch on top.
-- 
Michal Hocko
SUSE Labs

[LINUX PATCH v12] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface

[Naga Sureshkumar Relli]

Add driver for arm pl353 static memory controller nand interface with
HW ECC support. This controller is used in Xilinx Zynq SoC for
interfacing the NAND flash memory.

Signed-off-by: Naga Sureshkumar Relli 
---
Changes in v12:
 - Rebased the driver on top of v4.19 nand tree
 - Removed nand_scan_ident() and nand_scan_tail(), and added nand_controller_ops
   with ->attach_chip() and used nand_scan() instead.
 - Renamed pl353_nand_info structure to pl353_nand_controller
 - Renamed nand_base and nandaddr in pl353_nand_controller to 'regs' and 
'buf_addr'
 - Added new API pl353_wait_for_ecc_done() to wait for ecc done and call it from
   pl353_nand_write_page_hwecc() and pl353_nand_read_page_hwecc()
 - Defined new macro for max ECC blocks
 - Added return value check for ecc.calculate()
 - Renamed pl353_nand_cmd_function() to pl353_nand_exec_op_cmd()
 - Added x16 bus-width support
 - The dependent driver pl353-smc is already reviewed and hence dropped the
   smc driver
Changes in v11:
 - Removed Documentation patch and added the required info in driver as
   per Boris comments.
 - Removed unwanted variables from pl353_nand_info as per Miquel comments
 - Removed IO_ADDR_R/W.
 - Replaced onhot() with hweight32()
 - Defined macros for static values in function pl353_nand_correct_data()
 - Removed all unnecessary delays
 - Used nand_wait_ready() where ever is required
 - Modifed the pl353_setup_data_interface() logic as per Miquel comments.
 - Taken array instead of 7 values in pl353_setup_data_interface() and pass
   it to smc driver.
 - Added check to collect the return value of mtd_device_register().
Changes in 10:
 - Typos correction like nand to NAND and soc to SOC etc..
 - Defined macros for the values in pl353_nand_calculate_hwecc()
 - Modifed ecc_status from int to char in pl353_nand_calculate_hwecc()
 - Changed the return type form int to bool to the function
   onehot()
 - Removed udelay(1000) in pl353_cmd_function, as it is not required
 - Dropped ecc->hwctl = NULL in pl353_ecc_init()
 - Added an error message in pl353_ecc_init(), when there is no matching
   oobsize
 - Changed the variable from xnand to xnfc
 - Added logic to get mtd->name from DT, if it is specified in DT
Changes in v9:
 - Addressed the below comments given by Miquel
 - instead of using pl353_nand_write32, use directly writel_relaxed
 - Fixed check patch warnings
 - Renamed write_buf/read_buf to write_data_op/read_data_op
 - use BIT macro instead of 1 << nr
 - Use NAND_ROW_ADDR_3 flag
 - Use nand_wait_ready()
 - Removed swecc functions
 - Use address cycles as per size, instead of reading it from Parameter page
 - Instead of writing too many patterns, use optional property
Changes in v8:
 - Added exec_op() implementation
 - Fixed the below v7 review comments
 - removed mtd_info from pl353_nand_info struct
 - Corrected ecc layout offsets
 - Added on-die ecc support
Changes in v7:
 - Currently not implemented the memclk rate adjustments. I will
   look into this later and once the basic driver is accepted.
 - Fixed GPL licence ident
Changes in v6:
 - Fixed the checkpatch.pl reported warnings
 - Using the address cycles information from the onfi param page
   earlier it is hardcoded to 5 in driver
Changes in v5:
 - Configure the nand timing parameters as per the onfi spec Changes in v4:
 - Updated the driver to sync with pl353_smc driver APIs
Changes in v3:
 - implemented the proper error codes
 - further breakdown this patch to multiple sets
 - added the controller and driver details to Documentation section
 - updated the licenece to GPLv2
 - reorganized the pl353_nand_ecc_init function
Changes in v2:
 - use "depends on" rather than "select" option in kconfig
 - remove unused variable parts
---
 drivers/mtd/nand/raw/Kconfig  |8 +
 drivers/mtd/nand/raw/Makefile |1 +
 drivers/mtd/nand/raw/pl353_nand.c | 1398 +
 3 files changed, 1407 insertions(+)
 create mode 100644 drivers/mtd/nand/raw/pl353_nand.c

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index b6738ec..e87591e 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -560,4 +560,12 @@ config MTD_NAND_TEGRA
  is supported. Extra OOB bytes when using HW ECC are currently
  not supported.
 
+config MTD_NAND_PL353
+   tristate "ARM Pl353 NAND flash driver"
+   depends on MTD_NAND && ARM
+   depends on PL353_SMC
+   help
+ Enables support for PrimeCell Static Memory Controller PL353.
+
+
 endif # MTD_NAND
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index d5a5f98..dc5c332 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_MTD_NAND_BRCMNAND)   += brcmnand/
 obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o
 obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o
 obj-$(CONFIG_MTD_NAND_TEGRA)   += tegra_nand.o
+obj-$(CONFIG_MTD_NA

Re: [PATCH 4/4] s390/ftrace: add -mfentry and -mnop-mcount support

[Heiko Carstens]

On Mon, Aug 06, 2018 at 03:17:47PM +0200, Vasily Gorbik wrote:
> Utilize -mfentry and -mnop-mcount gcc options together with
> -mrecord-mcount to get compiler generated calls to the profiling functions
> as nops which are compatible with current -mhotpatch=0,3 approach.  At the
> same time -mrecord-mcount enables __mcount_loc section generation by
> the compiler which allows to avoid using scripts/recordmcount.pl script.
> 
> Signed-off-by: Vasily Gorbik 
> ---
>  arch/s390/Kconfig  |  2 ++
>  arch/s390/Makefile | 16 +---
>  arch/s390/include/asm/ftrace.h |  6 +++---
>  arch/s390/kernel/ftrace.c  |  2 +-
>  arch/s390/kernel/mcount.S  |  2 +-
>  5 files changed, 16 insertions(+), 12 deletions(-)

Do you have numbers which tell how much this reduces the compile time of
the kernel on s390? I assume this change makes quite some difference.

Reviewed-by: Heiko Carstens 

Re: [PATCH] phy: qcom-qmp: Fix dts bindings to reflect reality

[Doug Anderson]

Hi,

On Mon, Jul 23, 2018 at 4:33 PM, Rob Herring  wrote:
>> OK, I guess I will try again then and you can tell me when I get it
>> right (unless you tell me I should just change the driver to not use
>> named registers at all).  How about:
>>
>> - reg:
>>   - For "qcom,sdm845-qmp-usb3-phy":
>> - index 0: address and length of register set for PHY's common serdes
>>block.
>> - index 1: address and length of the DP_COM control block.
>
> Instead of repeating index 0 below, just say "for
> 'qcom,sdm845-qmp-usb3-phy' only" here.
>
>>   - For all others:
>> - index 0: address and length of register set for PHY's common serdes
>>block.
>> - reg-names:
>>   - For "qcom,sdm845-qmp-usb3-phy":
>> - Should be: "reg-base", "dp_com"
>>   - For all others:
>> - The reg-names property shouldn't be defined.

To close the loop, I've just posted
 AKA ("dt-bindings:
phy: qcom-qmp: Cleanup the 'reg' documentation as per review").
Hopefully that addresses everything properly but if not I'm happy to
spin it again.  Thanks for your patience in helping me understand what
you were looking for.

-Doug

[PATCH] dt-bindings: phy: qcom-qmp: Cleanup the 'reg' documentation as per review

[Douglas Anderson]

After the commit 8b1087fa3a27 ("phy: qcom-qmp: Fix dts bindings to
reflect reality") landed there was some review feedback that 'reg'
should have been documented differently.  Fix it as per review
feedback.

As per that feedback:
- Subject should have been 'dt-bindings: phy:' which this patch now
  has.
- We should leave no ambiguity in the ordering of 'reg' ranges even if
  'reg-names' are also specified.
- Normally using reg-names is discouraged unless there's a strong
  reason it's needed (like if there are optional ranges).  In this
  case reg-names wasn't needed but the driver already landed relying
  on reg-names so we'll just document it and move on.

Fixes: 8b1087fa3a27 ("phy: qcom-qmp: Fix dts bindings to reflect reality")
Suggested-by: Rob Herring 
Signed-off-by: Douglas Anderson 
---

 .../devicetree/bindings/phy/qcom-qmp-phy.txt  | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
index 0c7629e88bf3..2b161bf15d5d 100644
--- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -12,14 +12,17 @@ Required properties:
   "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
   "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845.
 
- - reg:
-   - For "qcom,sdm845-qmp-usb3-phy":
- - index 0: address and length of register set for PHY's common serdes
-   block.
- - named register "dp_com" (using reg-names): address and length of the
-   DP_COM control block.
-   - For all others:
- - offset and length of register set for PHY's common serdes block.
+- reg:
+  - index 0: address and length of register set for PHY's common
+ serdes block.
+  - index 1: address and length of the DP_COM control block (for
+ "qcom,sdm845-qmp-usb3-phy" only).
+
+- reg-names:
+  - For "qcom,sdm845-qmp-usb3-phy":
+- Should be: "reg-base", "dp_com"
+  - For all others:
+- The reg-names property shouldn't be defined.
 
  - #clock-cells: must be 1
 - Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
-- 
2.18.0.597.ga71716f1ad-goog

Re: [PATCH v4 1/9] proc/kcore: don't grab lock for kclist_add()

[Bhupesh Sharma]

Hello Omar,

On 07/26/2018 05:29 AM, Omar Sandoval wrote:

From: Omar Sandoval 

kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.

While we're here, mark kclist_add() with __init so that we'll get a
warning if it's called from non-init code.

Reviewed-by: Andrew Morton 
Signed-off-by: Omar Sandoval 
---
  fs/proc/kcore.c   | 7 +++
  include/linux/kcore.h | 2 +-
  2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 66c373230e60..b0b9a76f28d6 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -62,16 +62,15 @@ static LIST_HEAD(kclist_head);
  static DEFINE_RWLOCK(kclist_lock);
  static int kcore_need_update = 1;
  
-void

-kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
+/* This doesn't grab kclist_lock, so it should only be used at init time. */
+void __init kclist_add(struct kcore_list *new, void *addr, size_t size,
+  int type)
  {
new->addr = (unsigned long)addr;
new->size = size;
new->type = type;
  
-	write_lock(&kclist_lock);

list_add_tail(&new->list, &kclist_head);
-   write_unlock(&kclist_lock);
  }
  
  static size_t get_kcore_size(int *nphdr, size_t *elf_buflen)

diff --git a/include/linux/kcore.h b/include/linux/kcore.h
index 8de55e4b5ee9..c20f296438fb 100644
--- a/include/linux/kcore.h
+++ b/include/linux/kcore.h
@@ -35,7 +35,7 @@ struct vmcoredd_node {
  };
  
  #ifdef CONFIG_PROC_KCORE

-extern void kclist_add(struct kcore_list *, void *, size_t, int type);
+void __init kclist_add(struct kcore_list *, void *, size_t, int type);
  #else
  static inline
  void kclist_add(struct kcore_list *new, void *addr, size_t size, int type)



I have been looking at a problem on arm64 platforms where we are trying 
to get access to PHYS_OFFSET symbol (which indicates the start of 
physical RAM) in user-space for determining the start of physical RAM in 
user-space utilities like 'kexec-tools' (please see [1] and [2] for 
details).


Now, I have a 'kexec-tools' implementation available which can read the 
PHYS_OFFSET from the VMCOREINFO inside '/proc/kcore', which I plan to 
publish soon on my github tree.


I also see that 'readelf' and 'crash' can read the VMCOREINFO from the 
'/proc/kcore' properly after this patch:


# readelf -a --wide /proc/kcore

Displaying notes found at file offset 0x0778 with length 0x19b4:
  Owner Data size   Description
  CORE 0x0188   NT_PRSTATUS (prstatus structure)
  CORE 0x0088   NT_PRPSINFO (prpsinfo structure)
  CORE 0x1040   NT_TASKSTRUCT (task structure)  
  VMCOREINFO   0x0710   Unknown note type: (0x) 
<..snip..>

# crash /root/git/linux/vmlinux vmcore -d31

Elf64_Nhdr:
   n_namesz: 11 ("VMCOREINFO")
   n_descsz: 1829
 n_type: 0 (unused)
 OSRELEASE=4.18.0-rc7+
 PAGESIZE=65536
 SYMBOL(init_uts_ns)=5493078a5428
 SYMBOL(node_online_map)=54930789d1c8
 SYMBOL(swapper_pg_dir)=54930838
 SYMBOL(_stext)=549306681000
 SYMBOL(vmap_area_list)=549307944ee0
 SYMBOL(mem_section)=92047fffe400
 LENGTH(mem_section)=64
 SIZE(mem_section)=16
 OFFSET(mem_section.section_mem_map)=0
 SIZE(page)=64
 SIZE(pglist_data)=6656
 SIZE(zone)=1728
 SIZE(free_area)=88
 SIZE(list_head)=16
 SIZE(nodemask_t)=8
 OFFSET(page.flags)=0
 OFFSET(page._refcount)=52
 OFFSET(page.mapping)=24
 OFFSET(page.lru)=8
 OFFSET(page._mapcount)=48
 OFFSET(page.private)=40
 OFFSET(page.compound_dtor)=16
 OFFSET(page.compound_order)=17
 OFFSET(page.compound_head)=8
 OFFSET(pglist_data.node_zones)=0
 OFFSET(pglist_data.nr_zones)=5984
 OFFSET(pglist_data.node_start_pfn)=5992
 OFFSET(pglist_data.node_spanned_pages)=6008
 OFFSET(pglist_data.node_id)=6016
 OFFSET(zone.free_area)=192
 OFFSET(zone.vm_stat)=1536
 OFFSET(zone.spanned_pages)=96
 OFFSET(free_area.free_list)=0
 OFFSET(list_head.next)=0
 

Re: [LKP] [lkp-robot] [nfsd4] 517dc52baa: fsmark.files_per_sec 32.4% improvement

[Rong Chen]

On 08/01/2018 07:46 PM, J. Bruce Fields wrote:

On Fri, Jul 27, 2018 at 08:22:25AM +0800, Ye Xiaolong wrote:

On 07/16, Ye Xiaolong wrote:

On 07/04, Huang, Ying wrote:

"J. Bruce Fields"  writes:


Thanks!

On Wed, Jun 20, 2018 at 02:52:43PM +0800, kernel test robot wrote:

FYI, we noticed a 32.4% improvement of fsmark.files_per_sec due to commit:


commit: 517dc52baa2a508c82f68bbc7219b48169e6b29f ("nfsd4: shortern default lease 
period")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

That doesn't make any sense

OK, I think I see the problem:


in testcase: fsmark
on test machine: 48 threads Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz with 64G 
memory
with following parameters:

iterations: 1x
nr_threads: 1t
disk: 1BRD_48G
fs: f2fs
fs2: nfsv4
filesize: 4M
test_size: 40G
sync_method: fsyncBeforeClose
cpufreq_governor: performance

test-description: The fsmark is a file system benchmark to test synchronous 
write workloads, for example, mail servers workload.
test-url: https://sourceforge.net/projects/fsmark/



Details are as below:
-->


To reproduce:

 git clone https://github.com/intel/lkp-tests.git
 cd lkp-tests
 bin/lkp install job.yaml  # job file is attached in this email
 bin/lkp run job.yaml

=
compiler/cpufreq_governor/disk/filesize/fs2/fs/iterations/kconfig/nr_threads/rootfs/sync_method/tbox_group/test_size/testcase:
   
gcc-7/performance/1BRD_48G/4M/nfsv4/f2fs/1x/x86_64-rhel-7.2/1t/debian-x86_64-2016-08-31.cgz/fsyncBeforeClose/ivb44/40G/fsmark

commit:
   c2993a1d7d ("nfsd4: extend reclaim period for reclaiming clients")
   517dc52baa ("nfsd4: shortern default lease period")

c2993a1d7d6687fd 517dc52baa2a508c82f68bbc72
 --
  %stddev %change %stddev
  \  |\
  53.60   +32.4%  70.95fsmark.files_per_sec
 191.89   -24.4% 145.16fsmark.time.elapsed_time
 191.89   -24.4% 145.16fsmark.time.elapsed_time.max

So what happened is the test took about 45 seconds less.

I suspect you're starting the nfs server and then immediately running
this test.

Yes.


The problem is that if there's a grace period on startup, any open will
just hang until the grace period ends.

This patch changed the default grace period from 90 seconds to 45, so
that would explain the change.

In my testing I usually

start the nfs server
on the client:
mount the server
touch a file

When the touch returns, I know any grace period has completed, and then
I can run any tests normally.

I've modified our test to touch a file before running the actual workload, then
requeue tests for both commit 517dc52baa and its parent c2993a1d7d, but the
result seems persistent which shows a ~30% improvement of fsmark.files_per_sec.


Any suggestions?

You're sure you only start timing after the "touch" returns?
The result is normal after retesting, thank you for helping us improve 
the test.


Best Regards,
Rong, Chen



--b.

Re: [PATCH v4 0/4] seccomp trap to userspace

[Andy Lutomirski]

On Mon, Aug 6, 2018 at 8:30 PM, Christian Brauner  wrote:
> On Mon, Aug 06, 2018 at 08:44:42PM -0600, Tycho Andersen wrote:
>> Hi all,
>>
>> Dinesh Subhraveti has claimed that some part of this series might be
>> patented. While he has not furnished me with anything to confirm this
>> claim, I'll put this series on hold.
>
> Hey man,
>
> Sorry to hear that your faced with such nonsense, Tycho. This is utter
> bullsh*t of course. If you have more details at some point and feel
> comfortable doing so it would probably be good to share them here.

IANAL, but I think it would probably *not* be good to share them here.
Patent law is seriously fucked up like that.

--Andy

[PATCH 11/11] staging: fbtft: Includes parenthesis around macro parameters and avoids multiple usage of macro parameter - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft.h | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 41ac00239aa3..eb2bdc4870be 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -411,17 +411,21 @@ module_exit(fbtft_driver_module_exit)
 #define DEBUG_REQUEST_GPIOS_MATCH  BIT(30)
 #define DEBUG_VERIFY_GPIOS BIT(31)
 
-#define fbtft_init_dbg(dev, format, arg...)  \
-do { \
-   if (unlikely((dev)->platform_data && \
-   (((struct fbtft_platform_data 
*)(dev)->platform_data)->display.debug & DEBUG_DRIVER_INIT_FUNCTIONS))) \
-   dev_info(dev, format, ##arg);\
+#define fbtft_init_dbg(dev, format, arg...)\
+do {   \
+   typeof(dev) _dev = (dev);   \
+   struct fbtft_platform_data *pddev = (void *)_dev->platform_data;\
+   if (unlikely(pddev &&   \
+   (pddev->display.debug & \
+DEBUG_DRIVER_INIT_FUNCTIONS))) \
+   dev_info(_dev, (format), ##arg);\
 } while (0)
 
 #define fbtft_par_dbg(level, par, format, arg...)\
 do { \
-   if (unlikely(par->debug & level))\
-   dev_info(par->info->device, format, ##arg);  \
+   typeof(par) _par = (par);\
+   if (unlikely(_par->debug & (level)))\
+   dev_info(_par->info->device, format, ##arg);  \
 } while (0)
 
 #define fbtft_par_dbg_hex(level, par, dev, type, buf, num, format, arg...) \
-- 
2.18.0

[PATCH 10/11] staging: fbtft: Replaces (1 << n) for macro BIT(n) - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft.h | 56 +--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 3f3dcd96f9a7..41ac00239aa3 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -377,39 +377,39 @@ module_exit(fbtft_driver_module_exit)
 DEBUG_LEVEL_5)
 #define DEBUG_LEVEL_7  0x
 
-#define DEBUG_DRIVER_INIT_FUNCTIONS (1<<3)
-#define DEBUG_TIME_FIRST_UPDATE (1<<4)
-#define DEBUG_TIME_EACH_UPDATE  (1<<5)
-#define DEBUG_DEFERRED_IO   (1<<6)
-#define DEBUG_FBTFT_INIT_FUNCTIONS  (1<<7)
+#define DEBUG_DRIVER_INIT_FUNCTIONSBIT(3)
+#define DEBUG_TIME_FIRST_UPDATEBIT(4)
+#define DEBUG_TIME_EACH_UPDATE BIT(5)
+#define DEBUG_DEFERRED_IO  BIT(6)
+#define DEBUG_FBTFT_INIT_FUNCTIONS BIT(7)
 
 /* fbops */
-#define DEBUG_FB_READ   (1<<8)
-#define DEBUG_FB_WRITE  (1<<9)
-#define DEBUG_FB_FILLRECT   (1<<10)
-#define DEBUG_FB_COPYAREA   (1<<11)
-#define DEBUG_FB_IMAGEBLIT  (1<<12)
-#define DEBUG_FB_SETCOLREG  (1<<13)
-#define DEBUG_FB_BLANK  (1<<14)
+#define DEBUG_FB_READ  BIT(8)
+#define DEBUG_FB_WRITE BIT(9)
+#define DEBUG_FB_FILLRECT  BIT(10)
+#define DEBUG_FB_COPYAREA  BIT(11)
+#define DEBUG_FB_IMAGEBLIT BIT(12)
+#define DEBUG_FB_SETCOLREG BIT(13)
+#define DEBUG_FB_BLANK BIT(14)
 
-#define DEBUG_SYSFS (1<<16)
+#define DEBUG_SYSFSBIT(16)
 
 /* fbtftops */
-#define DEBUG_BACKLIGHT (1<<17)
-#define DEBUG_READ  (1<<18)
-#define DEBUG_WRITE (1<<19)
-#define DEBUG_WRITE_VMEM(1<<20)
-#define DEBUG_WRITE_REGISTER(1<<21)
-#define DEBUG_SET_ADDR_WIN  (1<<22)
-#define DEBUG_RESET (1<<23)
-#define DEBUG_MKDIRTY   (1<<24)
-#define DEBUG_UPDATE_DISPLAY(1<<25)
-#define DEBUG_INIT_DISPLAY  (1<<26)
-#define DEBUG_BLANK (1<<27)
-#define DEBUG_REQUEST_GPIOS (1<<28)
-#define DEBUG_FREE_GPIOS(1<<29)
-#define DEBUG_REQUEST_GPIOS_MATCH   (1<<30)
-#define DEBUG_VERIFY_GPIOS  (1<<31)
+#define DEBUG_BACKLIGHTBIT(17)
+#define DEBUG_READ BIT(18)
+#define DEBUG_WRITEBIT(19)
+#define DEBUG_WRITE_VMEM   BIT(20)
+#define DEBUG_WRITE_REGISTER   BIT(21)
+#define DEBUG_SET_ADDR_WIN BIT(22)
+#define DEBUG_RESETBIT(23)
+#define DEBUG_MKDIRTY  BIT(24)
+#define DEBUG_UPDATE_DISPLAY   BIT(25)
+#define DEBUG_INIT_DISPLAY BIT(26)
+#define DEBUG_BLANKBIT(27)
+#define DEBUG_REQUEST_GPIOSBIT(28)
+#define DEBUG_FREE_GPIOS   BIT(29)
+#define DEBUG_REQUEST_GPIOS_MATCH  BIT(30)
+#define DEBUG_VERIFY_GPIOS BIT(31)
 
 #define fbtft_init_dbg(dev, format, arg...)  \
 do { \
-- 
2.18.0

[PATCH 08/11] staging: fbtft: Add spaces around / - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fbtft/fbtft-core.c 
b/drivers/staging/fbtft/fbtft-core.c
index a9ee586ee6ba..4c71106d3b71 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -775,7 +775,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct 
fbtft_display *display,
fbops->fb_setcolreg =  fbtft_fb_setcolreg;
fbops->fb_blank =  fbtft_fb_blank;
 
-   fbdefio->delay =   HZ/fps;
+   fbdefio->delay =   HZ / fps;
fbdefio->deferred_io = fbtft_deferred_io;
fb_deferred_io_init(info);
 
-- 
2.18.0

[PATCH 09/11] staging: fbtft: Corrects long index line - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft-sysfs.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/fbtft/fbtft-sysfs.c 
b/drivers/staging/fbtft/fbtft-sysfs.c
index 8327f8f26ab1..99c8c9a636b5 100644
--- a/drivers/staging/fbtft/fbtft-sysfs.c
+++ b/drivers/staging/fbtft/fbtft-sysfs.c
@@ -25,6 +25,7 @@ int fbtft_gamma_parse_str(struct fbtft_par *par, u32 *curves,
unsigned long val = 0;
int ret = 0;
int curve_counter, value_counter;
+   unsigned long idx;
 
fbtft_par_dbg(DEBUG_SYSFS, par, "%s() str=\n", __func__);
 
@@ -68,7 +69,10 @@ int fbtft_gamma_parse_str(struct fbtft_par *par, u32 *curves,
ret = get_next_ulong(&curve_p, &val, " ", 16);
if (ret)
goto out;
-   curves[curve_counter * par->gamma.num_values + 
value_counter] = val;
+   idx = curve_counter
+ * par->gamma.num_values
+ + value_counter;
+   curves[idx] = val;
value_counter++;
}
if (value_counter != par->gamma.num_values) {
-- 
2.18.0

[PATCH 07/11] staging: fbtft: Includes description to mutex and spinlock - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index d8e7204a8d74..3f3dcd96f9a7 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -207,7 +207,7 @@ struct fbtft_par {
u8 *buf;
u8 startbyte;
struct fbtft_ops fbtftops;
-   spinlock_t dirty_lock;
+   spinlock_t dirty_lock; /*Protects dirty_lines_{start,end}*/
unsigned int dirty_lines_start;
unsigned int dirty_lines_end;
struct {
@@ -223,7 +223,7 @@ struct fbtft_par {
} gpio;
const s16 *init_sequence;
struct {
-   struct mutex lock;
+   struct mutex lock; /*Mutex for Gamma curve locking*/
u32 *curves;
int num_values;
int num_curves;
-- 
2.18.0

[PATCH 06/11] staging: fbtft: Fixes some defines styles - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fbtft-bus.c  | 10 ++
 drivers/staging/fbtft/fbtft-core.c |  6 --
 drivers/staging/fbtft/fbtft.h  |  4 ++--
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/fbtft/fbtft-bus.c 
b/drivers/staging/fbtft/fbtft-bus.c
index 5c768c658258..5a68802abac7 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -60,11 +60,13 @@ void func(struct fbtft_par *par, int len, ...)  
  \
 out: \
va_end(args); \
 } \
-EXPORT_SYMBOL(func);
+EXPORT_SYMBOL(func)
 
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
-define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+#define no_modf /*No modifier*/
+
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, no_modf);
+define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16);
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, no_modf);
 
 void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
 {
diff --git a/drivers/staging/fbtft/fbtft-core.c 
b/drivers/staging/fbtft/fbtft-core.c
index 4660a9f9eace..a9ee586ee6ba 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -278,6 +278,7 @@ void fbtft_unregister_backlight(struct fbtft_par *par)
par->info->bl_dev = NULL;
}
 }
+EXPORT_SYMBOL(fbtft_unregister_backlight);
 
 static const struct backlight_ops fbtft_bl_ops = {
.get_brightness = fbtft_backlight_get_brightness,
@@ -315,12 +316,13 @@ void fbtft_register_backlight(struct fbtft_par *par)
if (!par->fbtftops.unregister_backlight)
par->fbtftops.unregister_backlight = fbtft_unregister_backlight;
 }
+EXPORT_SYMBOL(fbtft_register_backlight);
 #else
 void fbtft_register_backlight(struct fbtft_par *par) { };
-void fbtft_unregister_backlight(struct fbtft_par *par) { };
-#endif
 EXPORT_SYMBOL(fbtft_register_backlight);
+void fbtft_unregister_backlight(struct fbtft_par *par) { };
 EXPORT_SYMBOL(fbtft_unregister_backlight);
+#endif
 
 static void fbtft_set_addr_win(struct fbtft_par *par, int xs, int ys, int xe,
   int ye)
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index a1411590732d..d8e7204a8d74 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -236,7 +236,7 @@ struct fbtft_par {
bool polarity;
 };
 
-#define NUMARGS(...)  (sizeof((int[]){__VA_ARGS__})/sizeof(int))
+#define NUMARGS(...)  (sizeof((int[]){__VA_ARGS__}) / sizeof(int))
 
 #define write_reg(par, ...)\
((par)->fbtftops.write_register(par, NUMARGS(__VA_ARGS__), __VA_ARGS__))
@@ -346,7 +346,7 @@ static void __exit fbtft_driver_module_exit(void)   
   \
 }  \
   \
 module_init(fbtft_driver_module_init); \
-module_exit(fbtft_driver_module_exit);
+module_exit(fbtft_driver_module_exit)
 
 /* Debug macros */
 
-- 
2.18.0

[PATCH 04/11] staging: fbtft: Adjust some empty-line problems - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fb_s6d02a1.c   | 1 -
 drivers/staging/fbtft/fb_s6d1121.c   | 1 +
 drivers/staging/fbtft/fb_ssd1289.c   | 1 +
 drivers/staging/fbtft/fbtft_device.c | 2 --
 4 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fbtft/fb_s6d02a1.c 
b/drivers/staging/fbtft/fb_s6d02a1.c
index 55513a395567..d3d6871d8c47 100644
--- a/drivers/staging/fbtft/fb_s6d02a1.c
+++ b/drivers/staging/fbtft/fb_s6d02a1.c
@@ -16,7 +16,6 @@
 #define DRVNAME "fb_s6d02a1"
 
 static const s16 default_init_sequence[] = {
-
-1, 0xf0, 0x5a, 0x5a,
 
-1, 0xfc, 0x5a, 0x5a,
diff --git a/drivers/staging/fbtft/fb_s6d1121.c 
b/drivers/staging/fbtft/fb_s6d1121.c
index c3e434d647b8..aa716f33420a 100644
--- a/drivers/staging/fbtft/fb_s6d1121.c
+++ b/drivers/staging/fbtft/fb_s6d1121.c
@@ -154,6 +154,7 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
 
return 0;
 }
+
 #undef CURVE
 
 static struct fbtft_display display = {
diff --git a/drivers/staging/fbtft/fb_ssd1289.c 
b/drivers/staging/fbtft/fb_ssd1289.c
index 67b3f8548241..c9b18b3ba4ab 100644
--- a/drivers/staging/fbtft/fb_ssd1289.c
+++ b/drivers/staging/fbtft/fb_ssd1289.c
@@ -153,6 +153,7 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
 
return 0;
 }
+
 #undef CURVE
 
 static struct fbtft_display display = {
diff --git a/drivers/staging/fbtft/fbtft_device.c 
b/drivers/staging/fbtft/fbtft_device.c
index dc424f3a0ec5..fd483e8ecd7a 100644
--- a/drivers/staging/fbtft/fbtft_device.c
+++ b/drivers/staging/fbtft/fbtft_device.c
@@ -840,7 +840,6 @@ static struct fbtft_device_display displays[] = {
}
}
}, {
-
.name = "piscreen",
.spi = &(struct spi_board_info) {
.modalias = "fb_ili9486",
@@ -1586,7 +1585,6 @@ static void __exit fbtft_device_exit(void)
 
if (p_device)
platform_device_unregister(p_device);
-
 }
 
 arch_initcall(fbtft_device_init);
-- 
2.18.0

[PATCH 03/11] staging: fbtft: Fixes some alignment and line > 80 char issues - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fb_ssd1289.c   |  6 +--
 drivers/staging/fbtft/fb_ssd1306.c   |  3 +-
 drivers/staging/fbtft/fb_ssd1331.c   |  9 -
 drivers/staging/fbtft/fb_ssd1351.c   | 43 +
 drivers/staging/fbtft/fb_st7735r.c   | 19 +++---
 drivers/staging/fbtft/fb_st7789v.c   | 13 +++
 drivers/staging/fbtft/fb_watterott.c | 17 +
 drivers/staging/fbtft/fbtft-bus.c| 21 ++
 drivers/staging/fbtft/fbtft-core.c   | 57 ++--
 drivers/staging/fbtft/fbtft-io.c | 17 +
 drivers/staging/fbtft/fbtft-sysfs.c  |  4 +-
 drivers/staging/fbtft/fbtft.h| 38 +++
 drivers/staging/fbtft/fbtft_device.c | 44 +++--
 drivers/staging/fbtft/flexfb.c   | 46 +-
 14 files changed, 214 insertions(+), 123 deletions(-)

diff --git a/drivers/staging/fbtft/fb_ssd1289.c 
b/drivers/staging/fbtft/fb_ssd1289.c
index 46116d06522c..67b3f8548241 100644
--- a/drivers/staging/fbtft/fb_ssd1289.c
+++ b/drivers/staging/fbtft/fb_ssd1289.c
@@ -38,7 +38,7 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0x0E, 0x2B00);
write_reg(par, 0x1E, 0x00B7);
write_reg(par, 0x01,
-   BIT(13) | (par->bgr << 11) | BIT(9) | (HEIGHT - 1));
+ BIT(13) | (par->bgr << 11) | BIT(9) | (HEIGHT - 1));
write_reg(par, 0x02, 0x0600);
write_reg(par, 0x10, 0x);
write_reg(par, 0x05, 0x);
@@ -98,8 +98,8 @@ static int set_var(struct fbtft_par *par)
if (par->fbtftops.init_display != init_display) {
/* don't risk messing up register 11h */
fbtft_par_dbg(DEBUG_INIT_DISPLAY, par,
-   "%s: skipping since custom init_display() is used\n",
-   __func__);
+ "%s: skipping since custom init_display() is 
used\n",
+ __func__);
return 0;
}
 
diff --git a/drivers/staging/fbtft/fb_ssd1306.c 
b/drivers/staging/fbtft/fb_ssd1306.c
index 9276be499303..f5e0ec1c01dc 100644
--- a/drivers/staging/fbtft/fb_ssd1306.c
+++ b/drivers/staging/fbtft/fb_ssd1306.c
@@ -184,7 +184,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
for (y = 0; y < yres / 8; y++) {
*buf = 0x00;
for (i = 0; i < 8; i++)
-   *buf |= (vmem16[(y * 8 + i) * xres + x] ? 1 : 
0) << i;
+   *buf |= (vmem16[(y * 8 + i) * xres + x] ?
+1 : 0) << i;
buf++;
}
}
diff --git a/drivers/staging/fbtft/fb_ssd1331.c 
b/drivers/staging/fbtft/fb_ssd1331.c
index 383e197cf56a..4c7500991a5b 100644
--- a/drivers/staging/fbtft/fb_ssd1331.c
+++ b/drivers/staging/fbtft/fb_ssd1331.c
@@ -74,7 +74,14 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
for (i = 0; i < len; i++)
buf[i] = (u8)va_arg(args, unsigned int);
va_end(args);
-   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device, 
u8, buf, len, "%s: ", __func__);
+   fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER,
+ par,
+ par->info->device,
+ u8,
+ buf,
+ len,
+ "%s: ",
+ __func__);
}
 
va_start(args, len);
diff --git a/drivers/staging/fbtft/fb_ssd1351.c 
b/drivers/staging/fbtft/fb_ssd1351.c
index 1b92691ac7cc..8abee5450ca1 100644
--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ b/drivers/staging/fbtft/fb_ssd1351.c
@@ -126,35 +126,45 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
for (i = 0; i < 63; i++) {
if (i > 0 && curves[i] < 2) {
dev_err(par->info->device,
-   "Illegal value in Grayscale Lookup Table at 
index %d. Must be greater than 1\n", i);
+   "Illegal value in Grayscale Lookup Table at 
index %d. Must be greater than 1\n",
+   i);
return -EINVAL;
}
acc += curves[i];
tmp[i] = acc;
if (acc > 180) {
dev_err(par->info->device,
-   "Illegal value(s) in Grayscale Lookup Table. At 
index=%d, the accumulated value has exceeded 180\n", i);
+   "Illegal value(s) in Grayscale Lookup Table. At 
index=%d, the accumulated value has exceeded 180\n",
+   i);
return -EINVAL;
}
}
 
write_reg(par, 0xB8,
-   tmp[0], tmp[1], tmp[2], tmp[3], 

[PATCH 02/11] staging: fbtft: Puts macro arguments in parenthesis to avoid precedence issues - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fb_hx8347d.c   |  2 +-
 drivers/staging/fbtft/fb_ili9163.c   |  2 +-
 drivers/staging/fbtft/fb_ili9320.c   |  2 +-
 drivers/staging/fbtft/fb_ili9325.c   |  2 +-
 drivers/staging/fbtft/fb_ili9341.c   |  2 +-
 drivers/staging/fbtft/fb_s6d1121.c   |  2 +-
 drivers/staging/fbtft/fb_ssd1289.c   |  2 +-
 drivers/staging/fbtft/fb_st7735r.c   |  2 +-
 drivers/staging/fbtft/fb_watterott.c | 12 +---
 drivers/staging/fbtft/fbtft.h|  9 +
 10 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/fbtft/fb_hx8347d.c 
b/drivers/staging/fbtft/fb_hx8347d.c
index 0b605303813e..3427a858d17c 100644
--- a/drivers/staging/fbtft/fb_hx8347d.c
+++ b/drivers/staging/fbtft/fb_hx8347d.c
@@ -92,7 +92,7 @@ static void set_addr_win(struct fbtft_par *par, int xs, int 
ys, int xe, int ye)
  *   VRP0 VRP1 VRP2 VRP3 VRP4 VRP5 PRP0 PRP1 PKP0 PKP1 PKP2 PKP3 PKP4 CGM
  *   VRN0 VRN1 VRN2 VRN3 VRN4 VRN5 PRN0 PRN1 PKN0 PKN1 PKN2 PKN3 PKN4 CGM
  */
-#define CURVE(num, idx)  curves[num * par->gamma.num_values + idx]
+#define CURVE(num, idx)  curves[(num) * par->gamma.num_values + (idx)]
 static int set_gamma(struct fbtft_par *par, u32 *curves)
 {
unsigned long mask[] = {
diff --git a/drivers/staging/fbtft/fb_ili9163.c 
b/drivers/staging/fbtft/fb_ili9163.c
index fd3dd671509f..86e140244aab 100644
--- a/drivers/staging/fbtft/fb_ili9163.c
+++ b/drivers/staging/fbtft/fb_ili9163.c
@@ -192,7 +192,7 @@ static int set_var(struct fbtft_par *par)
 }
 
 #ifdef GAMMA_ADJ
-#define CURVE(num, idx)  curves[num * par->gamma.num_values + idx]
+#define CURVE(num, idx)  curves[(num) * par->gamma.num_values + (idx)]
 static int gamma_adj(struct fbtft_par *par, u32 *curves)
 {
unsigned long mask[] = {
diff --git a/drivers/staging/fbtft/fb_ili9320.c 
b/drivers/staging/fbtft/fb_ili9320.c
index 501eee7dce4c..740c0acbecd8 100644
--- a/drivers/staging/fbtft/fb_ili9320.c
+++ b/drivers/staging/fbtft/fb_ili9320.c
@@ -211,7 +211,7 @@ static int set_var(struct fbtft_par *par)
  *  VRP0 VRP1 RP0 RP1 KP0 KP1 KP2 KP3 KP4 KP5
  *  VRN0 VRN1 RN0 RN1 KN0 KN1 KN2 KN3 KN4 KN5
  */
-#define CURVE(num, idx)  curves[num * par->gamma.num_values + idx]
+#define CURVE(num, idx)  curves[(num) * par->gamma.num_values + (idx)]
 static int set_gamma(struct fbtft_par *par, u32 *curves)
 {
unsigned long mask[] = {
diff --git a/drivers/staging/fbtft/fb_ili9325.c 
b/drivers/staging/fbtft/fb_ili9325.c
index d6b1d4be9ff4..2cf75f2e03e2 100644
--- a/drivers/staging/fbtft/fb_ili9325.c
+++ b/drivers/staging/fbtft/fb_ili9325.c
@@ -205,7 +205,7 @@ static int set_var(struct fbtft_par *par)
  *  VRP0 VRP1 RP0 RP1 KP0 KP1 KP2 KP3 KP4 KP5
  *  VRN0 VRN1 RN0 RN1 KN0 KN1 KN2 KN3 KN4 KN5
  */
-#define CURVE(num, idx)  curves[num * par->gamma.num_values + idx]
+#define CURVE(num, idx)  curves[(num) * par->gamma.num_values + (idx)]
 static int set_gamma(struct fbtft_par *par, u32 *curves)
 {
unsigned long mask[] = {
diff --git a/drivers/staging/fbtft/fb_ili9341.c 
b/drivers/staging/fbtft/fb_ili9341.c
index a10e8c9de438..9ccd0823c3ab 100644
--- a/drivers/staging/fbtft/fb_ili9341.c
+++ b/drivers/staging/fbtft/fb_ili9341.c
@@ -111,7 +111,7 @@ static int set_var(struct fbtft_par *par)
  *  Positive: Par1 Par2 [...] Par15
  *  Negative: Par1 Par2 [...] Par15
  */
-#define CURVE(num, idx)  curves[num * par->gamma.num_values + idx]
+#define CURVE(num, idx)  curves[(num) * par->gamma.num_values + (idx)]
 static int set_gamma(struct fbtft_par *par, u32 *curves)
 {
int i;
diff --git a/drivers/staging/fbtft/fb_s6d1121.c 
b/drivers/staging/fbtft/fb_s6d1121.c
index b90244259d43..c3e434d647b8 100644
--- a/drivers/staging/fbtft/fb_s6d1121.c
+++ b/drivers/staging/fbtft/fb_s6d1121.c
@@ -120,7 +120,7 @@ static int set_var(struct fbtft_par *par)
  * PKP0 PKP1 PKP2 PKP3 PKP4 PKP5 PKP6 PKP7 PKP8 PKP9 PKP10 PKP11 VRP0 VRP1
  * PKN0 PKN1 PKN2 PKN3 PKN4 PKN5 PKN6 PKN7 PRN8 PRN9 PRN10 PRN11 VRN0 VRN1
  */
-#define CURVE(num, idx)  curves[num * par->gamma.num_values + idx]
+#define CURVE(num, idx)  curves[(num) * par->gamma.num_values + (idx)]
 static int set_gamma(struct fbtft_par *par, u32 *curves)
 {
unsigned long mask[] = {
diff --git a/drivers/staging/fbtft/fb_ssd1289.c 
b/drivers/staging/fbtft/fb_ssd1289.c
index cbf22e1f4b61..46116d06522c 100644
--- a/drivers/staging/fbtft/fb_ssd1289.c
+++ b/drivers/staging/fbtft/fb_ssd1289.c
@@ -126,7 +126,7 @@ static int set_var(struct fbtft_par *par)
  * VRP0 VRP1 PRP0 PRP1 PKP0 PKP1 PKP2 PKP3 PKP4 PKP5
  * VRN0 VRN1 PRN0 PRN1 PKN0 PKN1 PKN2 PKN3 PKN4 PKN5
  */
-#define CURVE(num, idx)  curves[num * par->gamma.num_values + idx]
+#define CURVE(num, idx)  curves[(num) * par->gamma.num_values + (idx)]
 static int set_gamma(struct fbtft_par *par, u32 *curves)
 {
unsigned long mask[] = {
diff --git a/drivers/staging/fbtft/fb_st7735r.c 
b/drivers/staging/fbtft/fb_st7735r.c
index 631208bd3a17..e24af0a7f2de 100644
--- a/drivers/staging/fbtft/fb_st773

[PATCH 01/11] staging: fbtft: Changes udelay(n) to usleep_range(n, n + 1). - Style

[Leonardo Brás]

Signed-off-by: Leonardo Brás 
---
 drivers/staging/fbtft/fb_agm1264k-fl.c |  2 +-
 drivers/staging/fbtft/fb_ra8875.c  |  4 ++--
 drivers/staging/fbtft/fb_tinylcd.c |  2 +-
 drivers/staging/fbtft/fb_upd161704.c   | 19 +--
 drivers/staging/fbtft/fb_watterott.c   |  4 ++--
 5 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index f6f30f5bf15a..c936950ce56d 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par)
dev_dbg(par->info->device, "%s()\n", __func__);
 
gpio_set_value(par->gpio.reset, 0);
-   udelay(20);
+   usleep_range(20, 21);
gpio_set_value(par->gpio.reset, 1);
mdelay(120);
 }
diff --git a/drivers/staging/fbtft/fb_ra8875.c 
b/drivers/staging/fbtft/fb_ra8875.c
index 5d3b76ca74d8..e2a62677b65b 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -217,7 +217,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
}
len--;
 
-   udelay(100);
+   usleep_range(100, 101);
 
if (len) {
buf = (u8 *)par->buf;
@@ -238,7 +238,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, 
...)
 
/* restore user spi-speed */
par->fbtftops.write = fbtft_write_spi;
-   udelay(100);
+   usleep_range(100, 101);
 }
 
 static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c 
b/drivers/staging/fbtft/fb_tinylcd.c
index e463b0ddf16d..3b2af1becca8 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -41,7 +41,7 @@ static int init_display(struct fbtft_par *par)
 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
-   udelay(250);
+   usleep_range(250, 251);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
 
return 0;
diff --git a/drivers/staging/fbtft/fb_upd161704.c 
b/drivers/staging/fbtft/fb_upd161704.c
index acc425fdf34e..10794f81b66e 100644
--- a/drivers/staging/fbtft/fb_upd161704.c
+++ b/drivers/staging/fbtft/fb_upd161704.c
@@ -36,27 +36,26 @@ static int init_display(struct fbtft_par *par)
 
/* oscillator start */
write_reg(par, 0x003A, 0x0001); /*Oscillator 0: stop, 1: operation */
-   udelay(100);
-
+   usleep_range(100, 101);
/* y-setting */
write_reg(par, 0x0024, 0x007B); /* amplitude setting */
-   udelay(10);
+   usleep_range(10, 11);
write_reg(par, 0x0025, 0x003B); /* amplitude setting */
write_reg(par, 0x0026, 0x0034); /* amplitude setting */
-   udelay(10);
+   usleep_range(10, 11);
write_reg(par, 0x0027, 0x0004); /* amplitude setting */
write_reg(par, 0x0052, 0x0025); /* circuit setting 1 */
-   udelay(10);
+   usleep_range(10, 11);
write_reg(par, 0x0053, 0x0033); /* circuit setting 2 */
write_reg(par, 0x0061, 0x001C); /* adjustment V10 positive polarity */
-   udelay(10);
+   usleep_range(10, 11);
write_reg(par, 0x0062, 0x002C); /* adjustment V9 negative polarity */
write_reg(par, 0x0063, 0x0022); /* adjustment V34 positive polarity */
-   udelay(10);
+   usleep_range(10, 11);
write_reg(par, 0x0064, 0x0027); /* adjustment V31 negative polarity */
-   udelay(10);
+   usleep_range(10, 11);
write_reg(par, 0x0065, 0x0014); /* adjustment V61 negative polarity */
-   udelay(10);
+   usleep_range(10, 11);
write_reg(par, 0x0066, 0x0010); /* adjustment V61 negative polarity */
 
/* Basical clock for 1 line (BASECOUNT[7:0]) number specified */
@@ -64,7 +63,7 @@ static int init_display(struct fbtft_par *par)
 
/* Power supply setting */
write_reg(par, 0x0019, 0x); /* DC/DC output setting */
-   udelay(200);
+   usleep_range(200, 201);
write_reg(par, 0x001A, 0x1000); /* DC/DC frequency setting */
write_reg(par, 0x001B, 0x0023); /* DC/DC rising setting */
write_reg(par, 0x001C, 0x0C01); /* Regulator voltage setting */
diff --git a/drivers/staging/fbtft/fb_watterott.c 
b/drivers/staging/fbtft/fb_watterott.c
index bfd1527f20f7..9ad4307a50c8 100644
--- a/drivers/staging/fbtft/fb_watterott.c
+++ b/drivers/staging/fbtft/fb_watterott.c
@@ -83,7 +83,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
par->txbuf.buf, 10 + par->info->fix.line_length);
if (ret < 0)
return ret;
-   udelay(300);
+   usleep_range(300, 301);
}
 
return 0;
@@ -122,7 +122,7 @@ static int write_vmem_8bit(struct fbtft_par *par, size_t 
offset, size_t len)

[PATCH 00/11] Style Fixes on fbtft

[Leonardo Brás]

I did some style fixes on staging/fbtft using scripts/checkpatch.pl.

Please feel free to suggest any changes.


Leonardo Brás (11):
  staging: fbtft: Changes udelay(n) to usleep_range(n, n + 1). - Style
  staging: fbtft: Puts macro arguments in parenthesis to avoid
precedence issues - Style
  staging: fbtft: Fixes some alignment and line > 80 char issues - Style
  staging: fbtft: Adjust some empty-line problems - Style
  staging: fbtft: Erases some repetitive usage of function name - Style
  staging: fbtft: Fixes some defines styles - Style
  staging: fbtft: Includes description to mutex and spinlock - Style
  staging: fbtft: Add spaces around /  - Style
  staging: fbtft: Corrects long index line  - Style
  staging: fbtft: Replaces (1 << n) for macro BIT(n) - Style
  staging: fbtft: Includes parenthesis around macro parameters and
avoids multiple usage of macro parameter - Style

 drivers/staging/fbtft/fb_agm1264k-fl.c |   2 +-
 drivers/staging/fbtft/fb_hx8347d.c |   2 +-
 drivers/staging/fbtft/fb_ili9163.c |   2 +-
 drivers/staging/fbtft/fb_ili9320.c |   2 +-
 drivers/staging/fbtft/fb_ili9325.c |   2 +-
 drivers/staging/fbtft/fb_ili9341.c |   2 +-
 drivers/staging/fbtft/fb_ra8875.c  |   4 +-
 drivers/staging/fbtft/fb_s6d02a1.c |   1 -
 drivers/staging/fbtft/fb_s6d1121.c |   3 +-
 drivers/staging/fbtft/fb_sh1106.c  |   2 +-
 drivers/staging/fbtft/fb_ssd1289.c |   9 +-
 drivers/staging/fbtft/fb_ssd1306.c |   5 +-
 drivers/staging/fbtft/fb_ssd1325.c |   2 +-
 drivers/staging/fbtft/fb_ssd1331.c |  11 ++-
 drivers/staging/fbtft/fb_ssd1351.c |  43 ++---
 drivers/staging/fbtft/fb_st7735r.c |  21 ++--
 drivers/staging/fbtft/fb_st7789v.c |  13 ++-
 drivers/staging/fbtft/fb_tinylcd.c |   2 +-
 drivers/staging/fbtft/fb_uc1611.c  |   2 +-
 drivers/staging/fbtft/fb_upd161704.c   |  19 ++--
 drivers/staging/fbtft/fb_watterott.c   |  33 ---
 drivers/staging/fbtft/fbtft-bus.c  |  31 +++---
 drivers/staging/fbtft/fbtft-core.c |  65 -
 drivers/staging/fbtft/fbtft-io.c   |  17 ++--
 drivers/staging/fbtft/fbtft-sysfs.c|  10 +-
 drivers/staging/fbtft/fbtft.h  | 129 +++--
 drivers/staging/fbtft/fbtft_device.c   |  46 -
 drivers/staging/fbtft/flexfb.c |  46 +
 28 files changed, 317 insertions(+), 209 deletions(-)

-- 
2.18.0

[PATCH] nds32: add NULL entry to the end of_device_id array

[YueHaibing]

Make sure of_device_id tables are NULL terminated.
Found by coccinelle spatch "misc/of_table.cocci"

Signed-off-by: YueHaibing 
---
 arch/nds32/kernel/atl2c.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/nds32/kernel/atl2c.c b/arch/nds32/kernel/atl2c.c
index 0c6d031..0c5386e 100644
--- a/arch/nds32/kernel/atl2c.c
+++ b/arch/nds32/kernel/atl2c.c
@@ -9,7 +9,8 @@
 
 void __iomem *atl2c_base;
 static const struct of_device_id atl2c_ids[] __initconst = {
-   {.compatible = "andestech,atl2c",}
+   {.compatible = "andestech,atl2c",},
+   {}
 };
 
 static int __init atl2c_of_init(void)
-- 
2.7.0

Re: [PATCH v4 0/4] seccomp trap to userspace

[Christian Brauner]

On Mon, Aug 06, 2018 at 08:44:42PM -0600, Tycho Andersen wrote:
> Hi all,
> 
> Dinesh Subhraveti has claimed that some part of this series might be
> patented. While he has not furnished me with anything to confirm this
> claim, I'll put this series on hold.

Hey man,

Sorry to hear that your faced with such nonsense, Tycho. This is utter
bullsh*t of course. If you have more details at some point and feel
comfortable doing so it would probably be good to share them here.

Christian

> 
> Tycho
> 
> On Thu, Jun 21, 2018 at 04:04:12PM -0600, Tycho Andersen wrote:
> > Hi all,
> > 
> > Here's v4 of the seccomp trap to userspace series. v3 is here:
> > https://lkml.org/lkml/2018/5/31/527
> > 
> > I believe we've addressed the two burning questions I had about v3: 1.
> > it seems ok not to use netlink, since there's not a great way to re-use
> > the API without a lot of unnecessary code and 2. only having return
> > capability for fds seems fine with people. Or at least I haven't heard
> > any strong objections.
> > 
> > I've re-worked a bunch of things in this version based on feedback from
> > the last series. See patch notes for details. At this point I'm not
> > aware of anything that needs to be addressed, but of course that is
> > subject to change :)
> > 
> > Tycho
> > 
> > Tycho Andersen (4):
> >   seccomp: add a return code to trap to userspace
> >   seccomp: make get_nth_filter available outside of CHECKPOINT_RESTORE
> >   seccomp: add a way to get a listener fd from ptrace
> >   seccomp: add support for passing fds via USER_NOTIF
> > 
> >  .../userspace-api/seccomp_filter.rst  |  79 +++
> >  arch/Kconfig  |   7 +
> >  include/linux/seccomp.h   |  18 +-
> >  include/uapi/linux/ptrace.h   |   2 +
> >  include/uapi/linux/seccomp.h  |  23 +-
> >  kernel/ptrace.c   |   4 +
> >  kernel/seccomp.c  | 491 ++-
> >  tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +-
> >  8 files changed, 1172 insertions(+), 12 deletions(-)
> > 
> > -- 
> > 2.17.1
> > 
> ___
> Containers mailing list
> contain...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: Re: [PATCH] [PATCH] mm: disable preemption before swapcache_free

[Hugh Dickins]

On Tue, 7 Aug 2018, zhaowu...@wingtech.com wrote:
> 
> Thanks for affirming the modification of disabling preemption and 
> pointing out the incompleteness, delete_from_swap_cache() needs the same 
> protection.
> I'm curious about that why don't put swapcache_free(swap) under protection of 
> mapping->tree_lock ??

That would violate the long-established lock ordering (see not-always-
kept-up-to-date comments at the head of mm/rmap.c). In particular,
swap_lock (and its more recent descendants, such as swap_info->lock)
can be held with interrupts enabled, whereas taking tree_lock (later
called i_pages lock) involves disabling interrupts. So: there would
be quite a lot of modifications required to do swapcache_free(swap)
under mapping->tree_lock.

Generally easier would be to take tree_lock under swap lock: that fits
the establishd lock ordering, and is already done in just a few places
- or am I thinking of free_swap_and_cache() in the old days before
find_get_page() did lockless lookup? But you didn't suggest that way,
because it's more awkward in the __remove_mapping() case: I expect
that could be worked around with an initial PageSwapCache check,
taking swap locks there first (not inside swapcache_free()) -
__remove_mapping()'s BUG_ON(!PageLocked) implies that won't be racy.

But either way round, why? What would be the advantage in doing so?
A more conventional nesting of locks, easier to describe and understand,
yes. But from a performance point of view, thinking of lock contention,
nothing but disadvantage. And don't forget the get_swap_page() end:
there it would be harder to deal with both locks together (at least
in the shmem case).

Hugh

Urgent Help Needed

[Mrs. Evalyn Allyson]

Hello Beloved,

my name is Mrs. Evelyn Allyson. I was diagnosed with cancer about 2
years ago, and I am receiving treatment for it, but now the doctors
are saying I have a short time to live. I had no children of my own
with my late husband. I have decided to donate US$ 10.5M (Ten Million
Five Hundred Thousand Dollars) to you, so you can disburse to
charities, widows, orphans and less privileged.

I was doing this myself but now my health has deteriorated. I will be
going in for an operation soon, I want this last act of mine to be my
way of giving back to humanity. Please let me know if this is
something you can handle and I will provide you with more details.

Stay blessed,

Your early reply is highly welcomed.
Best Regards,
Mrs. Evelyn Allyson.

Re: [PATCH v4 0/4] seccomp trap to userspace

[Andy Lutomirski]

> On Aug 6, 2018, at 7:44 PM, Tycho Andersen  wrote:
> 
> Hi all,
> 
> Dinesh Subhraveti has claimed that some part of this series might be
> patented. While he has not furnished me with anything to confirm this
> claim, I'll put this series on hold.

That... is utterly ridiculous. Does LF have a mechanism to figure out wtf and 
deal with it by, for example, filing for ex parte review.

Every microkernel ever should strongly resemble prior art.

> 
> Tycho
> 
>> On Thu, Jun 21, 2018 at 04:04:12PM -0600, Tycho Andersen wrote:
>> Hi all,
>> 
>> Here's v4 of the seccomp trap to userspace series. v3 is here:
>> https://lkml.org/lkml/2018/5/31/527
>> 
>> I believe we've addressed the two burning questions I had about v3: 1.
>> it seems ok not to use netlink, since there's not a great way to re-use
>> the API without a lot of unnecessary code and 2. only having return
>> capability for fds seems fine with people. Or at least I haven't heard
>> any strong objections.
>> 
>> I've re-worked a bunch of things in this version based on feedback from
>> the last series. See patch notes for details. At this point I'm not
>> aware of anything that needs to be addressed, but of course that is
>> subject to change :)
>> 
>> Tycho
>> 
>> Tycho Andersen (4):
>>  seccomp: add a return code to trap to userspace
>>  seccomp: make get_nth_filter available outside of CHECKPOINT_RESTORE
>>  seccomp: add a way to get a listener fd from ptrace
>>  seccomp: add support for passing fds via USER_NOTIF
>> 
>> .../userspace-api/seccomp_filter.rst  |  79 +++
>> arch/Kconfig  |   7 +
>> include/linux/seccomp.h   |  18 +-
>> include/uapi/linux/ptrace.h   |   2 +
>> include/uapi/linux/seccomp.h  |  23 +-
>> kernel/ptrace.c   |   4 +
>> kernel/seccomp.c  | 491 ++-
>> tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +-
>> 8 files changed, 1172 insertions(+), 12 deletions(-)
>> 
>> -- 
>> 2.17.1
>> 

Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses

[Andy Lutomirski]

> On Aug 6, 2018, at 6:22 PM, Jann Horn  wrote:
> 
> There have been multiple kernel vulnerabilities that permitted userspace to
> pass completely unchecked pointers through to userspace accessors:
> 
> - the waitid() bug - commit 96ca579a1ecc ("waitid(): Add missing
>  access_ok() checks")
> - the sg/bsg read/write APIs
> - the infiniband read/write APIs
> 
> These don't happen all that often, but when they do happen, it is hard to
> test for them properly; and it is probably also hard to discover them with
> fuzzing. Even when an unmapped kernel address is supplied to such buggy
> code, it just returns -EFAULT instead of doing a proper BUG() or at least
> WARN().
> 
> This patch attempts to make such misbehaving code a bit more visible by
> WARN()ing in the pagefault handler code when a userspace accessor causes
> #PF on a kernel address and the current context isn't whitelisted.

I like this a lot, and, in fact, I once wrote a patch to do something similar. 
It was before the fancy extable code, though, so it was a mess.  Here are some 
thoughts:

- It should be three patches. One patch to add the _UA annotations, one to 
improve the info passes to the handlers, and one to change behavior.

- You should pass the vector, the error code, and the address to the handler.

- The uaccess handler should IMO WARN if the vector is anything other than #PF 
(which mainly means warning if it’s #GP). I think it should pr_emerg() and 
return false if the vector is #PF and the address is too high.

- Arguably most non-uaccess fixups should at least warn for anything other than 
#GP and #UD.

> 
> Signed-off-by: Jann Horn 
> ---
> This is a hacky, quickly thrown-together PoC to see what people think
> about the basic idea. Does it look like a sensible change? Or would it
> be better, for example, to instead expand the KASan hooks in the
> usercopy logic to also look at the "user" pointer if it points to
> kernelspace? That would have the advantage of also catching heap
> overflows properly...
> 
> I'm not really happy with all the plumbing in my patch; I wonder whether
> there's a way around introducing _ASM_EXTABLE_UA() for user accessors?
> 
> arch/x86/include/asm/asm.h  |  10 ++-
> arch/x86/include/asm/extable.h  |   3 +-
> arch/x86/include/asm/fpu/internal.h |   6 +-
> arch/x86/include/asm/futex.h|   6 +-
> arch/x86/include/asm/uaccess.h  |  22 ++---
> arch/x86/kernel/cpu/mcheck/mce.c|   2 +-
> arch/x86/kernel/kprobes/core.c  |   2 +-
> arch/x86/kernel/traps.c |   6 +-
> arch/x86/lib/checksum_32.S  |   4 +-
> arch/x86/lib/copy_user_64.S |  90 ++--
> arch/x86/lib/csum-copy_64.S |   6 +-
> arch/x86/lib/getuser.S  |  12 +--
> arch/x86/lib/putuser.S  |  10 +--
> arch/x86/lib/usercopy_32.c  | 126 ++--
> arch/x86/lib/usercopy_64.c  |   4 +-
> arch/x86/mm/extable.c   |  67 ---
> arch/x86/mm/fault.c |   2 +-
> include/linux/sched.h   |   2 +
> mm/maccess.c|   6 ++
> 19 files changed, 221 insertions(+), 165 deletions(-)
> 
> diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
> index 990770f9e76b..38f44a773adf 100644
> --- a/arch/x86/include/asm/asm.h
> +++ b/arch/x86/include/asm/asm.h
> @@ -130,6 +130,9 @@
> # define _ASM_EXTABLE(from, to)\
>   _ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
> 
> +# define _ASM_EXTABLE_UA(from, to)\
> +_ASM_EXTABLE_HANDLE(from, to, ex_handler_uaccess)
> +
> # define _ASM_EXTABLE_FAULT(from, to)\
>   _ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
> 
> @@ -165,8 +168,8 @@
>   jmp copy_user_handle_tail
>   .previous
> 
> -_ASM_EXTABLE(100b,103b)
> -_ASM_EXTABLE(101b,103b)
> +_ASM_EXTABLE_UA(100b,103b)
> +_ASM_EXTABLE_UA(101b,103b)
>   .endm
> 
> #else
> @@ -182,6 +185,9 @@
> # define _ASM_EXTABLE(from, to)\
>   _ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
> 
> +# define _ASM_EXTABLE_UA(from, to)\
> +_ASM_EXTABLE_HANDLE(from, to, ex_handler_uaccess)
> +
> # define _ASM_EXTABLE_FAULT(from, to)\
>   _ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
> 
> diff --git a/arch/x86/include/asm/extable.h b/arch/x86/include/asm/extable.h
> index f9c3a5d502f4..93c1d28f3c73 100644
> --- a/arch/x86/include/asm/extable.h
> +++ b/arch/x86/include/asm/extable.h
> @@ -29,7 +29,8 @@ struct pt_regs;
>   (b)->handler = (tmp).handler - (delta);\
>   } while (0)
> 
> -extern int fixup_exception(struct pt_regs *regs, int trapnr);
> +extern int fixup_exception(struct pt_regs *regs, int trapnr,
> +   unsigned long pf_addr);
> extern int fixup_bug(struct pt_regs *regs, int trapnr);
> extern bool ex_has_fault_handler(unsigned long ip);
> extern void early_fixup_exception(struct pt_regs *regs, int trapnr);
> diff --git a/arch/x

Re: [PATCH] arm64: dts: allwinner: a64: add csi regulator to sopine dts

[Chen-Yu Tsai]

On Wed, Aug 1, 2018 at 3:43 PM, Akash Gajjar  wrote:
> sopine board has a csi. enable supply dvdd-1v8-csi, dovdd-2v8-csi and
> avdd-2v8-csi on board to access external camera connected to it.

Unless there are other uses beyond supplying the camera module, this is not
going to be accepted. Enabling power to the camera should be in the same
patch as enabling the camera itself. And since it is a module, it should
be an overlay file.


ChenYu


> Signed-off-by: Akash Gajjar 
> ---
>  .../arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi | 21 
> +
>  1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
> index 43418bd..256229b 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi
> @@ -68,6 +68,13 @@
>
>  #include "axp803.dtsi"
>
> +®_aldo1 {
> +   regulator-always-on;
> +   regulator-min-microvolt = <280>;
> +   regulator-max-microvolt = <280>;
> +   regulator-name = "dovdd-csi";
> +};
> +
>  ®_aldo2 {
> regulator-always-on;
> regulator-min-microvolt = <180>;
> @@ -112,6 +119,13 @@
> regulator-name = "vdd-sys";
>  };
>
> +®_dldo3 {
> +   regulator-always-on;
> +   regulator-min-microvolt = <280>;
> +   regulator-max-microvolt = <280>;
> +   regulator-name = "avdd-csi";
> +};
> +
>  ®_eldo1 {
> regulator-always-on;
> regulator-min-microvolt = <180>;
> @@ -119,6 +133,13 @@
> regulator-name = "vdd-1v8-lpddr";
>  };
>
> +®_eldo3 {
> +   regulator-always-on;
> +   regulator-min-microvolt = <180>;
> +   regulator-max-microvolt = <180>;
> +   regulator-name = "vdd-csi";
> +};
> +
>  ®_fldo1 {
> regulator-min-microvolt = <120>;
> regulator-max-microvolt = <120>;
> --
> 2.7.4
>

[PATCH] pinctrl: uniphier: drop meaningless pin from SD1 pin-mux of Pro4

[Masahiro Yamada]

The pin 327 was supposed to be used as a voltage control line for the
SD card regulator, but the SD card port1 does not support UHS-I.  It
only supports 3.3V signaling, hence this pin is pointless.

Just a note about the background.  At first, hardware engineers tried
to implement the UHS for this port.  Then, they needed to shrink the
silicon die size, and gave up the UHS, but forgot to remove the pin
assignment.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c
index 24788a7..b2c1ffe 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c
@@ -1047,9 +1047,8 @@ static const unsigned nand_cs1_pins[] = {131, 132};
 static const int nand_cs1_muxvals[] = {1, 1};
 static const unsigned sd_pins[] = {150, 151, 152, 153, 154, 155, 156, 157, 
158};
 static const int sd_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
-static const unsigned sd1_pins[] = {319, 320, 321, 322, 323, 324, 325, 326,
-   327};
-static const int sd1_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};
+static const unsigned int sd1_pins[] = {319, 320, 321, 322, 323, 324, 325, 
326};
+static const int sd1_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0};
 static const unsigned system_bus_pins[] = {25, 26, 27, 28, 29, 30, 31, 32, 33,
   34, 35, 36, 37, 38};
 static const int system_bus_muxvals[] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-- 
2.7.4

do the editing

[Jason James]

Want to follow up the email sent last week.
Do you have needs for photo editing?
We can edit 400 images within 24 hours.

We are working on all kinds of ecommerce photos, jewelry photos, and the
portrait images.

We do cutting out and clipping path and others, and also we provide
retouching for your photos,

You can throw us a photo and we will do testing for you to check our
quality.

Thanks,
Jason

Re: [PATCH v4 0/4] seccomp trap to userspace

[Tycho Andersen]

Hi all,

Dinesh Subhraveti has claimed that some part of this series might be
patented. While he has not furnished me with anything to confirm this
claim, I'll put this series on hold.

Tycho

On Thu, Jun 21, 2018 at 04:04:12PM -0600, Tycho Andersen wrote:
> Hi all,
> 
> Here's v4 of the seccomp trap to userspace series. v3 is here:
> https://lkml.org/lkml/2018/5/31/527
> 
> I believe we've addressed the two burning questions I had about v3: 1.
> it seems ok not to use netlink, since there's not a great way to re-use
> the API without a lot of unnecessary code and 2. only having return
> capability for fds seems fine with people. Or at least I haven't heard
> any strong objections.
> 
> I've re-worked a bunch of things in this version based on feedback from
> the last series. See patch notes for details. At this point I'm not
> aware of anything that needs to be addressed, but of course that is
> subject to change :)
> 
> Tycho
> 
> Tycho Andersen (4):
>   seccomp: add a return code to trap to userspace
>   seccomp: make get_nth_filter available outside of CHECKPOINT_RESTORE
>   seccomp: add a way to get a listener fd from ptrace
>   seccomp: add support for passing fds via USER_NOTIF
> 
>  .../userspace-api/seccomp_filter.rst  |  79 +++
>  arch/Kconfig  |   7 +
>  include/linux/seccomp.h   |  18 +-
>  include/uapi/linux/ptrace.h   |   2 +
>  include/uapi/linux/seccomp.h  |  23 +-
>  kernel/ptrace.c   |   4 +
>  kernel/seccomp.c  | 491 ++-
>  tools/testing/selftests/seccomp/seccomp_bpf.c | 560 +-
>  8 files changed, 1172 insertions(+), 12 deletions(-)
> 
> -- 
> 2.17.1
> 

Re: [RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses

[Kees Cook]

On Mon, Aug 6, 2018 at 6:22 PM, Jann Horn  wrote:
> There have been multiple kernel vulnerabilities that permitted userspace to
> pass completely unchecked pointers through to userspace accessors:
>
>  - the waitid() bug - commit 96ca579a1ecc ("waitid(): Add missing
>access_ok() checks")
>  - the sg/bsg read/write APIs
>  - the infiniband read/write APIs
>
> These don't happen all that often, but when they do happen, it is hard to
> test for them properly; and it is probably also hard to discover them with
> fuzzing. Even when an unmapped kernel address is supplied to such buggy
> code, it just returns -EFAULT instead of doing a proper BUG() or at least
> WARN().

Yes, please! I had tried looking at this after the waitid() bug since
it was such a shallow bug and I expected that KASan would have found
it. But, as you saw as well, it doesn't because of the -EFAULT
masking.

> This patch attempts to make such misbehaving code a bit more visible by
> WARN()ing in the pagefault handler code when a userspace accessor causes
> #PF on a kernel address and the current context isn't whitelisted.

I think we absolutely should make noise like this, yes.

> Signed-off-by: Jann Horn 
> ---
> This is a hacky, quickly thrown-together PoC to see what people think

Hacky because of the okay/not-okay tracking stored in current?

> about the basic idea. Does it look like a sensible change? Or would it
> be better, for example, to instead expand the KASan hooks in the
> usercopy logic to also look at the "user" pointer if it points to
> kernelspace? That would have the advantage of also catching heap
> overflows properly...

Yes, I think there are a lot of conditions where having this WARN would be nice.

-Kees

>
> I'm not really happy with all the plumbing in my patch; I wonder whether
> there's a way around introducing _ASM_EXTABLE_UA() for user accessors?
>
> arch/x86/include/asm/asm.h  |  10 ++-
>  arch/x86/include/asm/extable.h  |   3 +-
>  arch/x86/include/asm/fpu/internal.h |   6 +-
>  arch/x86/include/asm/futex.h|   6 +-
>  arch/x86/include/asm/uaccess.h  |  22 ++---
>  arch/x86/kernel/cpu/mcheck/mce.c|   2 +-
>  arch/x86/kernel/kprobes/core.c  |   2 +-
>  arch/x86/kernel/traps.c |   6 +-
>  arch/x86/lib/checksum_32.S  |   4 +-
>  arch/x86/lib/copy_user_64.S |  90 ++--
>  arch/x86/lib/csum-copy_64.S |   6 +-
>  arch/x86/lib/getuser.S  |  12 +--
>  arch/x86/lib/putuser.S  |  10 +--
>  arch/x86/lib/usercopy_32.c  | 126 ++--
>  arch/x86/lib/usercopy_64.c  |   4 +-
>  arch/x86/mm/extable.c   |  67 ---
>  arch/x86/mm/fault.c |   2 +-
>  include/linux/sched.h   |   2 +
>  mm/maccess.c|   6 ++
>  19 files changed, 221 insertions(+), 165 deletions(-)
>
> diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
> index 990770f9e76b..38f44a773adf 100644
> --- a/arch/x86/include/asm/asm.h
> +++ b/arch/x86/include/asm/asm.h
> @@ -130,6 +130,9 @@
>  # define _ASM_EXTABLE(from, to)\
> _ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
>
> +# define _ASM_EXTABLE_UA(from, to) \
> +   _ASM_EXTABLE_HANDLE(from, to, ex_handler_uaccess)
> +
>  # define _ASM_EXTABLE_FAULT(from, to)  \
> _ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
>
> @@ -165,8 +168,8 @@
> jmp copy_user_handle_tail
> .previous
>
> -   _ASM_EXTABLE(100b,103b)
> -   _ASM_EXTABLE(101b,103b)
> +   _ASM_EXTABLE_UA(100b,103b)
> +   _ASM_EXTABLE_UA(101b,103b)
> .endm
>
>  #else
> @@ -182,6 +185,9 @@
>  # define _ASM_EXTABLE(from, to)\
> _ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
>
> +# define _ASM_EXTABLE_UA(from, to) \
> +   _ASM_EXTABLE_HANDLE(from, to, ex_handler_uaccess)
> +
>  # define _ASM_EXTABLE_FAULT(from, to)  \
> _ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
>
> diff --git a/arch/x86/include/asm/extable.h b/arch/x86/include/asm/extable.h
> index f9c3a5d502f4..93c1d28f3c73 100644
> --- a/arch/x86/include/asm/extable.h
> +++ b/arch/x86/include/asm/extable.h
> @@ -29,7 +29,8 @@ struct pt_regs;
> (b)->handler = (tmp).handler - (delta); \
> } while (0)
>
> -extern int fixup_exception(struct pt_regs *regs, int trapnr);
> +extern int fixup_exception(struct pt_regs *regs, int trapnr,
> +  unsigned long pf_addr);
>  extern int fixup_bug(struct pt_regs *regs, int trapnr);
>  extern bool ex_has_fault_handler(unsigned long ip);
>  extern void early_fixup_exception(struct pt_regs *regs, int trapnr);
> diff --git a/arch/x86/include/asm/fpu/internal.h 
> b/arch/x86/include/asm/fpu/internal.h
> index a38bf5a1e37a..640e77211

Re: [PATCH 3/4] watchdog: hpwdt: Display module parameters.

[Guenter Roeck]

On 08/06/2018 04:19 PM, Jerry Hoemann wrote:

On Sat, Aug 04, 2018 at 06:13:20PM -0700, Guenter Roeck wrote:

On 08/02/2018 02:15 PM, Jerry Hoemann wrote:

Print module parameters when the driver is loaded.

Signed-off-by: Jerry Hoemann 
---
   drivers/watchdog/hpwdt.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
index 8a85ddd..f098371 100644
--- a/drivers/watchdog/hpwdt.c
+++ b/drivers/watchdog/hpwdt.c
@@ -326,8 +326,9 @@ static int hpwdt_init_one(struct pci_dev *dev,
}
dev_info(&dev->dev, "HPE Watchdog Timer Driver: %s"
-   ", timer margin: %d seconds (nowayout=%d).\n",
-   HPWDT_VERSION, hpwdt_dev.timeout, nowayout);
+   ", timeout : %d seconds (nowayout=%d) pretimeout=%s.\n",
+   HPWDT_VERSION, hpwdt_dev.timeout, nowayout,
+   pretimeout ? "on" : "off");

When touching that, you might as well address

WARNING: quoted string split across lines



k. Think I'll split into two dev_info calls as line is too long
to fit into 80 chars w/o splitting.




Why did you add a space before ':' ? Personal preference ?


I think you're referring to "timeout : %d seconds".  Bad editting when
going from "timer margin:" to "timeout :".  I'll fix.



Yes, that is what I referred to.


If you referring to the spaces around the ternary operator, that is
in coding-style although checkpatch accepts w/o spaces around the
operators.


Nope, those spaces are desirable.

Guenter

Re: [PATCH] firmware: make sure builtin firmware is page alignment

[Zhang, Ning A]

在 2018-08-06一的 16:05 +0200，gre...@linuxfoundation.org写道：
> On Mon, Aug 06, 2018 at 01:48:44AM +, Zhang, Ning A wrote:
> > 在 2018-08-03五的 12:31 +0200，gre...@linuxfoundation.org写道：
> > > On Fri, Aug 03, 2018 at 08:42:25AM +, Zhang, Ning A wrote:
> > > > 在 2018-08-03五的 07:39 +0200，Greg KH写道：
> > > > > On Fri, Aug 03, 2018 at 09:45:21AM +0800, Zhang Ning wrote:
> > > > > > when firmware is in filesystem, request_firmware will load
> > > > > > it,
> > > > > > and copy it to vmalloc memory, that is page align memory.
> > > > > > 
> > > > > > but when firmware is builtin, it is 8 bytes or 4 bytes
> > > > > > alignment.
> > > > > > 
> > > > > > make sure builtin firmware is page algnment, that can
> > > > > > simplify
> > > > > > algorithm
> > > > > > to handle firmware.
> > > > > 
> > > > > How is it simplified?  I don't see any such change like that
> > > > > here
> > > > > :(
> > > > > 
> > > > 
> > > > Thank you for review this patch.
> > > > 
> > > > When driver handles its firmware based on  page, like below:
> > > > 
> > > > struct page *p;
> > > > p = vmalloc_to_page(fw->data);  // for filesystem
> > > > firmware
> > > > p = virt_to_page(fw->data); // for builtin firmware
> > > > 
> > > > but if builtin firmware is not page alignment, page pointer for
> > > > builtin
> > > > firmware is wrong, it contains memory not belong to firmware.
> > > > drivers
> > > > has to use additional code to handle this. 
> > > > 
> > > > if builtin firmware is also page alignment, no need additional
> > > > code
> > > > to
> > > > handle builtin firmware. simplified.
> > > 
> > > But you did not change anything like this in your code, so why
> > > would
> > > I
> > > know this?
> > 
> > I understand it is very difficult to review this patch without
> > context.
> > The driver is not opensource, I can't show the patch for driver.
> 
> Then I can not accept your patch.  Go talk to your corporate lawyers
> about changing core kernel code for a closed source driver and what
> that
> implies about that closed driver (hint, your driver can not be
> closed...) :)

It's very sad, but anyway, thank you for your review.
your review will definitely help us improve our work.

BR.
Ning.

> 
> Then come back with a proper open sourced driver, that's the only way
> Linux drivers can be written sorry.
> 
> best of luck,
> 
> greg k-h
> 

for editing the photos

[Jason James]

Want to follow up the email sent last week.
Do you have needs for photo editing?
We can edit 400 images within 24 hours.

We are working on all kinds of ecommerce photos, jewelry photos, and the
portrait images.

We do cutting out and clipping path and others, and also we provide
retouching for your photos,

You can throw us a photo and we will do testing for you to check our
quality.

Thanks,
Jason

Re: [PATCH 4/5] arm: dts: qcom: Add ipq8064-ap161.dts

[Sricharan R]

Hi Rob,

On 8/7/2018 2:05 AM, Rob Herring wrote:
> On Fri, Aug 3, 2018 at 8:10 AM Sricharan R  wrote:
>>
>> Add a new board dts for ipq8064-ap161.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  Documentation/devicetree/bindings/arm/qcom.txt | 2 ++
>>  arch/arm/boot/dts/Makefile | 1 +
>>  arch/arm/boot/dts/qcom-ipq8064-ap161.dts   | 7 +++
>>  3 files changed, 10 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/qcom-ipq8064-ap161.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom.txt 
>> b/Documentation/devicetree/bindings/arm/qcom.txt
>> index ee532e7..2325135 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom.txt
>> +++ b/Documentation/devicetree/bindings/arm/qcom.txt
>> @@ -15,6 +15,7 @@ The 'SoC' and 'board' elements are required. All other 
>> elements are optional.
>>
>>  The 'SoC' element must be one of the following strings:
>>
>> +   ipq8064
>> apq8016
>> apq8074
>> apq8084
>> @@ -30,6 +31,7 @@ The 'SoC' element must be one of the following strings:
>>
>>  The 'board' element must be one of the following strings:
>>
>> +   ap
>> cdp
>> liquid
>> dragonboard
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 37a3de7..233661a 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -772,6 +772,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
>> qcom-ipq4019-ap.dk07.1-c1.dtb \
>> qcom-ipq4019-ap.dk07.1-c2.dtb \
>> qcom-ipq8064-ap148.dtb \
>> +   qcom-ipq8064-ap161.dtb \
>> qcom-msm8660-surf.dtb \
>> qcom-msm8960-cdp.dtb \
>> qcom-msm8974-fairphone-fp2.dtb \
>> diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap161.dts 
>> b/arch/arm/boot/dts/qcom-ipq8064-ap161.dts
>> new file mode 100644
>> index 000..aab5174
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/qcom-ipq8064-ap161.dts
>> @@ -0,0 +1,7 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +#include "qcom-ipq8064-v1.0.dtsi"
>> +
>> +/ {
>> +   model = "Qualcomm Technologies, Inc. IPQ8064/AP-161";
>> +   compatible = "qcom,ipq8064-ap161";
> 
> Doesn't match what you documented above. I'm guessing the ap148 board
> didn't either...

oops. yeah, ap148 id not having it. will add that and also correct this.
would call it as 'ap161' as the name for the board part.

Regards,
 Sricharan

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

for editing the photos

[Jason James]

Want to follow up the email sent last week.
Do you have needs for photo editing?
We can edit 400 images within 24 hours.

We are working on all kinds of ecommerce photos, jewelry photos, and the
portrait images.

We do cutting out and clipping path and others, and also we provide
retouching for your photos,

You can throw us a photo and we will do testing for you to check our
quality.

Thanks,
Jason

Re: linux-next: build failure after merge of the vfs tree

[Masahiro Yamada]

2018-08-07 9:59 GMT+09:00 Stephen Rothwell :
> Hi all,
>
> On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell  
> wrote:
>>
>> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell  
>> wrote:
>> >
>> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
>> > failed like this:
>> >
>> > samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such 
>> > file or directory
>> >  #include 
>> >   ^~~~
>> >
>> > Caused by commit
>> >
>> >   90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem 
>> > information")
>> >
>> > I guess that headers_install (or whatever its called) has not bee run
>> > before the sample code is built.
>> >
>> > I have applied the following patch for today:
>> >
>> > From: Stephen Rothwell 
>> > Date: Mon, 6 Aug 2018 10:29:34 +1000
>> > Subject: [PATCH] vfs: don;t build new sample programs yet
>> >
>> > It seems that headers_install is not done before the samples
>> > are build so some needed include files are not in the right place.
>> >
>> > Signed-off-by: Stephen Rothwell 
>> > ---
>> >  samples/statx/Makefile | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/samples/statx/Makefile b/samples/statx/Makefile
>> > index 05b4d30cdd3c..0b4d01822eca 100644
>> > --- a/samples/statx/Makefile
>> > +++ b/samples/statx/Makefile
>> > @@ -1,5 +1,5 @@
>> >  # List of programs to build
>> > -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
>> > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
>> >
>> >  # Tell kbuild to always build the programs
>> >  always := $(hostprogs-y)
>>
>> It turns out that commit
>>
>>   ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
>>
>> removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
>> breaks other builds (at least allyesconfig on s390).
>
> I have added the following suggested patch (I am sorry I can't
> find/remember who pointed me to this patch) for today (I guess that it
> should be merged via the vfs tree as that is what is causing the build
> failures ... in which case a real patch should be supplied with
> appropriate SOB line).  This seems to fix the current problem.
>
> From: Masahiro Yamada 
> Date: Tue, 7 Aug 2018 10:33:43 +1000
> Subject: [PATCH] Try to get the headers installed before we build the samples
>
> Signed-off-by: Stephen Rothwell 
> ---
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Makefile b/Makefile
> index 9e71826f67d7..d224d94c14be 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1023,6 +1023,7 @@ endif
>  # Build samples along the rest of the kernel
>  ifdef CONFIG_SAMPLES
>  vmlinux-dirs += samples
> +samples: headers_install
>  endif
>
>  # The actual objects are generated when descending,
> --


OK, I will queue this up to my tree.


I suggested this in the discussion:
https://patchwork.kernel.org/patch/10552353/

I did not get response, though.




-- 
Best Regards
Masahiro Yamada

[PATCH v3 0/2] pinctrl: meson-g12a: add pinctrl driver support

[Yixun Lan]

  This patch series try to add pinctrl driver support for
the Meson-G12A SoC.

  The pinctrl driver for Meson-G12A SoC share the similar IP as
the previous Meson-AXG SoC, both use same pinmux ops (register layout).
But, a new driver is needed here due to the differences in the pins.

Changes since v2 at [2]
 - use ${FUNCTION}_${DOMAIN}_${PORT}_${PINFUNC}_${BANK}${PINNUM}
   to rename some pins
 - fix tdm groups
 - explain the similarity of pinmux between AXG and G12A - thanks Martin 
 - collect Rob's Reviewed-by

Changes since v1 at [1]
 - add Martin's Ack, Xingyu's Signed-off
 - squash patch 1,2 (documentation & header file)
 - explain pinctrl IP
 - notice GPIOE located in AO bank

[1] https://lkml.kernel.org/r/20180704224511.29350-1-yixun@amlogic.com
[2] https://lkml.kernel.org/r/20180714232754.5402-1-yixun@amlogic.com

Yixun Lan (2):
  documentation: pinctrl: Add compatibles for Amlogic Meson G12A pin
controllers
  pinctrl: meson-g12a: add pinctrl driver support

 .../bindings/pinctrl/meson,pinctrl.txt|2 +
 drivers/pinctrl/meson/Kconfig |6 +
 drivers/pinctrl/meson/Makefile|1 +
 drivers/pinctrl/meson/pinctrl-meson-g12a.c| 1404 +
 include/dt-bindings/gpio/meson-g12a-gpio.h|  114 ++
 5 files changed, 1527 insertions(+)
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson-g12a.c
 create mode 100644 include/dt-bindings/gpio/meson-g12a-gpio.h

-- 
2.18.0

[PATCH v3 2/2] pinctrl: meson-g12a: add pinctrl driver support

[Yixun Lan]

Add the pinctrl driver for Meson-G12A SoC which share the similar IP as
the previous Meson-AXG SoC, both use same pinmux ops (register layout).
A new driver is needed here due to the differences in the pins.

Starting from Meson-AXG SoC, the pinctrl controller block use 4
continues register bits to specific the pin mux function, while comparing
to old generation SoC which using variable length register bits for
the pin mux definition. The new design greatly simplify the software model.

For the detail example, one 32bit register can be divided into 8 parts,
each has 4 bits whose value start from 0 - 7, each can describe one pin,
the value 0 is always devoted to GPIO function, while 1 - 7 devoted to
the mux pin function.

Please note, the GPIOE is actually located at AO (always on) bank.

Acked-by: Martin Blumenstingl 
Signed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 drivers/pinctrl/meson/Kconfig  |6 +
 drivers/pinctrl/meson/Makefile |1 +
 drivers/pinctrl/meson/pinctrl-meson-g12a.c | 1404 
 3 files changed, 1411 insertions(+)
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson-g12a.c

diff --git a/drivers/pinctrl/meson/Kconfig b/drivers/pinctrl/meson/Kconfig
index c80951d6caff..9ab537eb78a3 100644
--- a/drivers/pinctrl/meson/Kconfig
+++ b/drivers/pinctrl/meson/Kconfig
@@ -47,4 +47,10 @@ config PINCTRL_MESON_AXG
 config PINCTRL_MESON_AXG_PMX
bool
 
+config PINCTRL_MESON_G12A
+   bool "Meson g12a Soc pinctrl driver"
+   depends on ARM64
+   select PINCTRL_MESON_AXG_PMX
+   default y
+
 endif
diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
index 3c6580c2d9d7..cf283f48f9d8 100644
--- a/drivers/pinctrl/meson/Makefile
+++ b/drivers/pinctrl/meson/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_PINCTRL_MESON_GXBB) += pinctrl-meson-gxbb.o
 obj-$(CONFIG_PINCTRL_MESON_GXL) += pinctrl-meson-gxl.o
 obj-$(CONFIG_PINCTRL_MESON_AXG_PMX) += pinctrl-meson-axg-pmx.o
 obj-$(CONFIG_PINCTRL_MESON_AXG) += pinctrl-meson-axg.o
+obj-$(CONFIG_PINCTRL_MESON_G12A) += pinctrl-meson-g12a.o
diff --git a/drivers/pinctrl/meson/pinctrl-meson-g12a.c 
b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
new file mode 100644
index ..d494492e98e9
--- /dev/null
+++ b/drivers/pinctrl/meson/pinctrl-meson-g12a.c
@@ -0,0 +1,1404 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Pin controller and GPIO driver for Amlogic Meson G12A SoC.
+ *
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ * Author: Xingyu Chen 
+ * Author: Yixun Lan 
+ */
+
+#include 
+#include "pinctrl-meson.h"
+#include "pinctrl-meson-axg-pmx.h"
+
+static const struct pinctrl_pin_desc meson_g12a_periphs_pins[] = {
+   MESON_PIN(GPIOZ_0),
+   MESON_PIN(GPIOZ_1),
+   MESON_PIN(GPIOZ_2),
+   MESON_PIN(GPIOZ_3),
+   MESON_PIN(GPIOZ_4),
+   MESON_PIN(GPIOZ_5),
+   MESON_PIN(GPIOZ_6),
+   MESON_PIN(GPIOZ_7),
+   MESON_PIN(GPIOZ_8),
+   MESON_PIN(GPIOZ_9),
+   MESON_PIN(GPIOZ_10),
+   MESON_PIN(GPIOZ_11),
+   MESON_PIN(GPIOZ_12),
+   MESON_PIN(GPIOZ_13),
+   MESON_PIN(GPIOZ_14),
+   MESON_PIN(GPIOZ_15),
+   MESON_PIN(GPIOH_0),
+   MESON_PIN(GPIOH_1),
+   MESON_PIN(GPIOH_2),
+   MESON_PIN(GPIOH_3),
+   MESON_PIN(GPIOH_4),
+   MESON_PIN(GPIOH_5),
+   MESON_PIN(GPIOH_6),
+   MESON_PIN(GPIOH_7),
+   MESON_PIN(GPIOH_8),
+   MESON_PIN(BOOT_0),
+   MESON_PIN(BOOT_1),
+   MESON_PIN(BOOT_2),
+   MESON_PIN(BOOT_3),
+   MESON_PIN(BOOT_4),
+   MESON_PIN(BOOT_5),
+   MESON_PIN(BOOT_6),
+   MESON_PIN(BOOT_7),
+   MESON_PIN(BOOT_8),
+   MESON_PIN(BOOT_9),
+   MESON_PIN(BOOT_10),
+   MESON_PIN(BOOT_11),
+   MESON_PIN(BOOT_12),
+   MESON_PIN(BOOT_13),
+   MESON_PIN(BOOT_14),
+   MESON_PIN(BOOT_15),
+   MESON_PIN(GPIOC_0),
+   MESON_PIN(GPIOC_1),
+   MESON_PIN(GPIOC_2),
+   MESON_PIN(GPIOC_3),
+   MESON_PIN(GPIOC_4),
+   MESON_PIN(GPIOC_5),
+   MESON_PIN(GPIOC_6),
+   MESON_PIN(GPIOC_7),
+   MESON_PIN(GPIOA_0),
+   MESON_PIN(GPIOA_1),
+   MESON_PIN(GPIOA_2),
+   MESON_PIN(GPIOA_3),
+   MESON_PIN(GPIOA_4),
+   MESON_PIN(GPIOA_5),
+   MESON_PIN(GPIOA_6),
+   MESON_PIN(GPIOA_7),
+   MESON_PIN(GPIOA_8),
+   MESON_PIN(GPIOA_9),
+   MESON_PIN(GPIOA_10),
+   MESON_PIN(GPIOA_11),
+   MESON_PIN(GPIOA_12),
+   MESON_PIN(GPIOA_13),
+   MESON_PIN(GPIOA_14),
+   MESON_PIN(GPIOA_15),
+   MESON_PIN(GPIOX_0),
+   MESON_PIN(GPIOX_1),
+   MESON_PIN(GPIOX_2),
+   MESON_PIN(GPIOX_3),
+   MESON_PIN(GPIOX_4),
+   MESON_PIN(GPIOX_5),
+   MESON_PIN(GPIOX_6),
+   MESON_PIN(GPIOX_7),
+   MESON_PIN(GPIOX_8),
+   MESON_PIN(GPIOX_9),
+   MESON_PIN(GPIOX_10),
+   MESON_PIN(GPIOX_11),
+   MESON_PIN(GPIOX_12),
+   MESON_PIN(GPIOX_13),
+   MESON_PIN(GPIOX_14),
+   MESON_PIN(GPIOX_15),
+  

[PATCH v3 1/2] documentation: pinctrl: Add compatibles for Amlogic Meson G12A pin controllers

[Yixun Lan]

Add new compatible name for Amlogic's Meson-G12A pin controllers,
add a dt-binding header file which document the detail pin names.

Acked-by: Martin Blumenstingl 
Reviewed-by: Rob Herring 
Signed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 .../bindings/pinctrl/meson,pinctrl.txt|   2 +
 include/dt-bindings/gpio/meson-g12a-gpio.h| 114 ++
 2 files changed, 116 insertions(+)
 create mode 100644 include/dt-bindings/gpio/meson-g12a-gpio.h

diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
index 54ecb8ab7788..82ead40311f6 100644
--- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
@@ -13,6 +13,8 @@ Required properties for the root node:
  "amlogic,meson-gxl-aobus-pinctrl"
  "amlogic,meson-axg-periphs-pinctrl"
  "amlogic,meson-axg-aobus-pinctrl"
+ "amlogic,meson-g12a-periphs-pinctrl"
+ "amlogic,meson-g12a-aobus-pinctrl"
  - reg: address and size of registers controlling irq functionality
 
 === GPIO sub-nodes ===
diff --git a/include/dt-bindings/gpio/meson-g12a-gpio.h 
b/include/dt-bindings/gpio/meson-g12a-gpio.h
new file mode 100644
index ..f7bd69350d18
--- /dev/null
+++ b/include/dt-bindings/gpio/meson-g12a-gpio.h
@@ -0,0 +1,114 @@
+/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
+/*
+ * Copyright (c) 2018 Amlogic, Inc. All rights reserved.
+ * Author: Xingyu Chen 
+ */
+
+#ifndef _DT_BINDINGS_MESON_G12A_GPIO_H
+#define _DT_BINDINGS_MESON_G12A_GPIO_H
+
+/* First GPIO chip */
+#define GPIOAO_0   0
+#define GPIOAO_1   1
+#define GPIOAO_2   2
+#define GPIOAO_3   3
+#define GPIOAO_4   4
+#define GPIOAO_5   5
+#define GPIOAO_6   6
+#define GPIOAO_7   7
+#define GPIOAO_8   8
+#define GPIOAO_9   9
+#define GPIOAO_10  10
+#define GPIOAO_11  11
+#define GPIOE_012
+#define GPIOE_113
+#define GPIOE_214
+
+/* Second GPIO chip */
+#define GPIOZ_00
+#define GPIOZ_11
+#define GPIOZ_22
+#define GPIOZ_33
+#define GPIOZ_44
+#define GPIOZ_55
+#define GPIOZ_66
+#define GPIOZ_77
+#define GPIOZ_88
+#define GPIOZ_99
+#define GPIOZ_10   10
+#define GPIOZ_11   11
+#define GPIOZ_12   12
+#define GPIOZ_13   13
+#define GPIOZ_14   14
+#define GPIOZ_15   15
+#define GPIOH_016
+#define GPIOH_117
+#define GPIOH_218
+#define GPIOH_319
+#define GPIOH_420
+#define GPIOH_521
+#define GPIOH_622
+#define GPIOH_723
+#define GPIOH_824
+#define BOOT_0 25
+#define BOOT_1 26
+#define BOOT_2 27
+#define BOOT_3 28
+#define BOOT_4 29
+#define BOOT_5 30
+#define BOOT_6 31
+#define BOOT_7 32
+#define BOOT_8 33
+#define BOOT_9 34
+#define BOOT_1035
+#define BOOT_1136
+#define BOOT_1237
+#define BOOT_1338
+#define BOOT_1439
+#define BOOT_1540
+#define GPIOC_041
+#define GPIOC_142
+#define GPIOC_243
+#define GPIOC_344
+#define GPIOC_445
+#define GPIOC_546
+#define GPIOC_647
+#define GPIOC_748
+#define GPIOA_049
+#define GPIOA_150
+#define GPIOA_251
+#define GPIOA_352
+#define GPIOA_453
+#define GPIOA_554
+#define GPIOA_655
+#define GPIOA_756
+#define GPIOA_857
+#define GPIOA_958
+#define GPIOA_10   59
+#define GPIOA_11   60
+#define GPIOA_12   61
+#define GPIOA_13   62
+#define GPIOA_14   63
+#define GPIOA_15   64
+#define GPIOX_065
+#define GPIOX_166
+#define GPIOX_267
+#define GPIOX_368
+#define GPIOX_469
+#define GPIOX_570
+#define GPIOX_671
+#define GPIOX_772
+#define GPIOX_873
+#define GPIOX_974
+#define GPIOX_10   75
+#define GPIOX_11   76
+#define GPIOX_12   77
+#define GPIOX_13   78
+#define GPIOX_14   79
+#define GPIOX_15   80
+#define GPIOX_16   81
+#define GPIOX_17   82
+#define GPIOX_18   83
+#define GPIOX_19   84
+
+#endif /* _DT_BINDINGS_MESON_G12A_GPIO_H */
-- 
2.18.0

Re: [PATCH] tracing: Partial revert of "tracing: Centralize preemptirq tracepoints and unify their usage"

[Steven Rostedt]

On Mon, 6 Aug 2018 21:54:32 -0400
Steven Rostedt  wrote:

> --- a/kernel/trace/trace_preemptirq.c
> +++ b/kernel/trace/trace_preemptirq.c
> @@ -20,40 +20,52 @@ static DEFINE_PER_CPU(int, tracing_irq_cpu);
>  void trace_hardirqs_on(void)
>  {
>   if (!this_cpu_read(tracing_irq_cpu))
> - return;
> + goto out;
>  
>   trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
>   this_cpu_write(tracing_irq_cpu, 0);
> +
> + out:
> + lockdep_hardirqs_on(CALLER_ADDR0);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_on);
>  
>  void trace_hardirqs_off(void)
>  {
>   if (this_cpu_read(tracing_irq_cpu))
> - return;
> + goto out;
>  
>   this_cpu_write(tracing_irq_cpu, 1);
>   trace_irq_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> +
> + out:
> + lockdep_hardirqs_off(CALLER_ADDR0);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_off);
>  
>  __visible void trace_hardirqs_on_caller(unsigned long caller_addr)
>  {
>   if (!this_cpu_read(tracing_irq_cpu))
> - return;
> + goto out;
>  
>   trace_irq_enable_rcuidle(CALLER_ADDR0, caller_addr);
>   this_cpu_write(tracing_irq_cpu, 0);
> +
> + out:
> + lockdep_hardirqs_on(CALLER_ADDR0);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_on_caller);
>  
>  __visible void trace_hardirqs_off_caller(unsigned long caller_addr)
>  {
>   if (this_cpu_read(tracing_irq_cpu))
> - return;
> + goto out;
>  
>   this_cpu_write(tracing_irq_cpu, 1);
>   trace_irq_disable_rcuidle(CALLER_ADDR0, caller_addr);
> +
> + out:
> + lockdep_hardirqs_off(CALLER_ADDR0);
>  }
>  EXPORT_SYMBOL(trace_hardirqs_off_caller);
>  #endif /* CONFIG_TRACE_IRQFLAGS */

Hmm, the gotos above are rather ugly. This look better?

-- Steve


diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c
index e76b78bf258e..fa656b25f427 100644
--- a/kernel/trace/trace_preemptirq.c
+++ b/kernel/trace/trace_preemptirq.c
@@ -19,41 +19,45 @@ static DEFINE_PER_CPU(int, tracing_irq_cpu);
 
 void trace_hardirqs_on(void)
 {
-   if (!this_cpu_read(tracing_irq_cpu))
-   return;
+   if (this_cpu_read(tracing_irq_cpu)) {
+   trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
+   this_cpu_write(tracing_irq_cpu, 0);
+   }
 
-   trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
-   this_cpu_write(tracing_irq_cpu, 0);
+   lockdep_hardirqs_on(CALLER_ADDR0);
 }
 EXPORT_SYMBOL(trace_hardirqs_on);
 
 void trace_hardirqs_off(void)
 {
-   if (this_cpu_read(tracing_irq_cpu))
-   return;
+   if (!this_cpu_read(tracing_irq_cpu)) {
+   this_cpu_write(tracing_irq_cpu, 1);
+   trace_irq_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
+   }
 
-   this_cpu_write(tracing_irq_cpu, 1);
-   trace_irq_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
+   lockdep_hardirqs_off(CALLER_ADDR0);
 }
 EXPORT_SYMBOL(trace_hardirqs_off);
 
 __visible void trace_hardirqs_on_caller(unsigned long caller_addr)
 {
-   if (!this_cpu_read(tracing_irq_cpu))
-   return;
+   if (this_cpu_read(tracing_irq_cpu)) {
+   trace_irq_enable_rcuidle(CALLER_ADDR0, caller_addr);
+   this_cpu_write(tracing_irq_cpu, 0);
+   }
 
-   trace_irq_enable_rcuidle(CALLER_ADDR0, caller_addr);
-   this_cpu_write(tracing_irq_cpu, 0);
+   lockdep_hardirqs_on(CALLER_ADDR0);
 }
 EXPORT_SYMBOL(trace_hardirqs_on_caller);
 
 __visible void trace_hardirqs_off_caller(unsigned long caller_addr)
 {
-   if (this_cpu_read(tracing_irq_cpu))
-   return;
+   if (!this_cpu_read(tracing_irq_cpu)) {
+   this_cpu_write(tracing_irq_cpu, 1);
+   trace_irq_disable_rcuidle(CALLER_ADDR0, caller_addr);
+   }
 
-   this_cpu_write(tracing_irq_cpu, 1);
-   trace_irq_disable_rcuidle(CALLER_ADDR0, caller_addr);
+   lockdep_hardirqs_off(CALLER_ADDR0);
 }
 EXPORT_SYMBOL(trace_hardirqs_off_caller);
 #endif /* CONFIG_TRACE_IRQFLAGS */

[PATCH] x86/boot/KASLR: Change the function type to void

[Chao Fan]

Since function "handle_mem_options" is used only once:
arch/x86/boot/compressed/kaslr.c:421
handle_mem_options();
The return value is useless, so change it to void.

And also clean a useless variable.

Suggested-by: Dou Liyang 
Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/kaslr.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 302517929932..78724caadcfb 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -244,7 +244,7 @@ static void parse_gb_huge_pages(char *param, char *val)
 }
 
 
-static int handle_mem_options(void)
+static void handle_mem_options(void)
 {
char *args = (char *)get_cmd_line_ptr();
size_t len = strlen((char *)args);
@@ -254,7 +254,7 @@ static int handle_mem_options(void)
 
if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
!strstr(args, "hugepages"))
-   return 0;
+   return;
 
tmp_cmdline = malloc(len + 1);
if (!tmp_cmdline)
@@ -272,8 +272,7 @@ static int handle_mem_options(void)
/* Stop at -- */
if (!val && strcmp(param, "--") == 0) {
warn("Only '--' specified in cmdline");
-   free(tmp_cmdline);
-   return -1;
+   goto out;
}
 
if (!strcmp(param, "memmap")) {
@@ -286,16 +285,16 @@ static int handle_mem_options(void)
if (!strcmp(p, "nopentium"))
continue;
mem_size = memparse(p, &p);
-   if (mem_size == 0) {
-   free(tmp_cmdline);
-   return -EINVAL;
-   }
+   if (mem_size == 0)
+   goto out;
+
mem_limit = mem_size;
}
}
 
+out:
free(tmp_cmdline);
-   return 0;
+   return;
 }
 
 /*
@@ -581,7 +580,6 @@ static void process_mem_region(struct mem_vector *entry,
   unsigned long image_size)
 {
struct mem_vector region, overlap;
-   struct slot_area slot_area;
unsigned long start_orig, end;
struct mem_vector cur_entry;
 
-- 
2.17.1

[PATCH] tracing: Partial revert of "tracing: Centralize preemptirq tracepoints and unify their usage"

[Steven Rostedt]

[ Peter, you OK with this patch? It just makes lockdep call its helper
  functions directly like it did before. ]

From: "Steven Rostedt (VMware)" 

Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
by lockdep and irqsoff latency tracer. It made both use tracepoints. But it
caused lockdep to trigger several false positives. We have not figured out
why yet, but removing lockdep from using the trace event hooks and just call
its helper functions directly (like it use to), makes the problem go away.

This is a partial revert of the clean up patch c3bc8fd637a9 ("tracing:
Centralize preemptirq tracepoints and unify their usage") that adds direct
calls for lockdep, but also keeps most of the clean up done to get rid of
the horrible preprocessor if statements.

Link: http://lkml.kernel.org/r/20180806155058.5ee87...@gandalf.local.home

Cc: Joel Fernandes 
Cc: Peter Zijlstra 
Fixes: c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and unify 
their usage")
Signed-off-by: Steven Rostedt (VMware) 
---
 include/linux/irqflags.h|  2 ++
 include/linux/lockdep.h |  2 --
 init/main.c |  2 --
 kernel/locking/lockdep.c| 14 ++
 kernel/trace/trace_preemptirq.c | 20 
 5 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
index 50edb9cbbd26..a93476c6c954 100644
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -19,6 +19,8 @@
 #ifdef CONFIG_PROVE_LOCKING
   extern void trace_softirqs_on(unsigned long ip);
   extern void trace_softirqs_off(unsigned long ip);
+  extern void lockdep_hardirqs_on(unsigned long ip);
+  extern void lockdep_hardirqs_off(unsigned long ip);
 #else
 # define trace_softirqs_on(ip) do { } while (0)
 # define trace_softirqs_off(ip)do { } while (0)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index a8113357ceeb..b0d0b51c4d85 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -267,7 +267,6 @@ struct held_lock {
  * Initialization, self-test and debugging-output methods:
  */
 extern void lockdep_init(void);
-extern void lockdep_init_early(void);
 extern void lockdep_reset(void);
 extern void lockdep_reset_lock(struct lockdep_map *lock);
 extern void lockdep_free_key_range(void *start, unsigned long size);
@@ -408,7 +407,6 @@ static inline void lockdep_on(void)
 # define lock_set_class(l, n, k, s, i) do { } while (0)
 # define lock_set_subclass(l, s, i)do { } while (0)
 # define lockdep_init()do { } while (0)
-# define lockdep_init_early()  do { } while (0)
 # define lockdep_init_map(lock, name, key, sub) \
do { (void)(name); (void)(key); } while (0)
 # define lockdep_set_class(lock, key)  do { (void)(key); } while (0)
diff --git a/init/main.c b/init/main.c
index 44fe43be84c1..5d42e577643a 100644
--- a/init/main.c
+++ b/init/main.c
@@ -649,8 +649,6 @@ asmlinkage __visible void __init start_kernel(void)
call_function_init();
WARN(!irqs_disabled(), "Interrupts were enabled early\n");
 
-   lockdep_init_early();
-
early_boot_irqs_disabled = false;
local_irq_enable();
 
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 03bfaeb9f4e6..e406c5fdb41e 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2840,8 +2840,7 @@ static void __trace_hardirqs_on_caller(unsigned long ip)
debug_atomic_inc(hardirqs_on_events);
 }
 
-static void lockdep_hardirqs_on(void *none, unsigned long ignore,
-   unsigned long ip)
+void lockdep_hardirqs_on(unsigned long ip)
 {
if (unlikely(!debug_locks || current->lockdep_recursion))
return;
@@ -2885,8 +2884,7 @@ static void lockdep_hardirqs_on(void *none, unsigned long 
ignore,
 /*
  * Hardirqs were disabled:
  */
-static void lockdep_hardirqs_off(void *none, unsigned long ignore,
-unsigned long ip)
+void lockdep_hardirqs_off(unsigned long ip)
 {
struct task_struct *curr = current;
 
@@ -4315,14 +4313,6 @@ void lockdep_reset_lock(struct lockdep_map *lock)
raw_local_irq_restore(flags);
 }
 
-void __init lockdep_init_early(void)
-{
-#ifdef CONFIG_PROVE_LOCKING
-   register_trace_prio_irq_disable(lockdep_hardirqs_off, NULL, INT_MAX);
-   register_trace_prio_irq_enable(lockdep_hardirqs_on, NULL, INT_MIN);
-#endif
-}
-
 void __init lockdep_init(void)
 {
printk("Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., 
Ingo Molnar\n");
diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c
index e76b78bf258e..8326adcab0dc 100644
--- a/kernel/trace/trace_preemptirq.c
+++ b/kernel/trace/trace_preemptirq.c
@@ -20,40 +20,52 @@ static DEFINE_PER_CPU(int, tracing_irq_cpu);
 void trace_hardirqs_on(void)
 {
if (!this_cpu_read(tracing_irq_cpu))
-  

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Steven Rostedt]

On Mon, 6 Aug 2018 17:43:19 -0700
Joel Fernandes  wrote:

> On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt  wrote:
> >
> > With this patch applied, I'm constantly getting lockdep errors. Instead
> > of doing a full revert of the patch, I did this, which makes all those
> > errors go away. I may apply this for now, and we can revisit having
> > lockdep use the tracepoint code. But since it's currently always
> > enabled, I'm thinking of just leaving this as is. The macros are still
> > clean from Joel's patch.
> >
> > Thoughts?  
> 
> I like your patch. Thanks a lot for doing this.. It keeps most of the
> benefits of my patch while avoiding the issues with lockdep. I agree
> we can look at the remaining lockdep issue after. There were several
> lockdep issues with this patch that I fixed over the the months, but
> there's still the one that Masami reported that I believe you're also
> seeing. Once I'm back I'll work on figuring that one out.
> 
> Could you pull in the fixes to the other issues I posted though? With
> that we should be good.
> https://lore.kernel.org/patchwork/patch/971104/
> https://lore.kernel.org/patchwork/patch/971829/
>

I already had these applied when I created this patch ;-)

Thanks, I'll add it.

-- Steve

[PATCH] lockdep: Have assert functions test for actual interrupts disabled

[Steven Rostedt]

From: Steven Rostedt (VMware) 

While working on irqs disabled tracepoints, I triggered the following
warning:

 [ cut here ]
 IRQs not disabled as expected
 WARNING: CPU: 0 PID: 0 at kernel/softirq.c:144 __local_bh_enable+0x9b/0xe0
 Modules linked in:
 CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.18.0-rc6-test+ 
#1099
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
07/14/2016
 RIP: 0010:__local_bh_enable+0x9b/0xe0
 Code: 5b d2 30 00 8b 85 98 08 00 00 85 c0 74 bf 80 3d ff eb 06 02 00 75 b6 48 
c7 c7 80 89 46 8c c6 05 ef eb 06 02 01 e8 15 4e ff ff <0f> 0b eb 9f 48 8b 7c 24 
10 e8 67 5f 09 00 eb b2 48 8b 6c 24 10 48 
 RSP: 0018:8800d3e07f50 EFLAGS: 00010082
 RAX:  RBX: 0100 RCX: 
 RDX: 0102 RSI: dc00 RDI: 8e57dc00
 RBP: 8cc1f980 R08: fbfff199f449 R09: fbfff199f448
 R10: 8800d3e2643f R11: ed001a7c4c88 R12: 0007
 R13: 0008 R14: 0007 R15: 
 FS:  () GS:8800d3e0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2:  CR3: cac14001 CR4: 001606f0
 Call Trace:
  
  __do_softirq+0x4a0/0x55a
  irq_exit+0x128/0x130
  reschedule_interrupt+0xf/0x20
  
 RIP: 0010:cpuidle_enter_state+0xcc/0x430
 Code: 63 55 ff 48 89 04 24 0f 1f 44 00 00 31 ff e8 7b 8d 55 ff 80 7c 24 10 00 
0f 85 fb 02 00 00 e8 eb a8 69 ff fb 66 0f 1f 44 00 00 <4c> 8b 3c 24 4c 2b 7c 24 
08 48 ba cf f7 53 e3 a5 9b c4 20 48 8d 7b 
 RSP: 0018:8cc07d18 EFLAGS: 0282 ORIG_RAX: ff02
 RAX: 00025140 RBX: 8800d3e34f00 RCX: 8b1cec2e
 RDX: dc00 RSI: 0001 RDI: 8cd4a868
 RBP: 8cf1b660 R08: ed001a7c43db R09: 
 R10: 8800d3e2643f R11: ed001a7c4c88 R12: 8cf1b7f8
 R13: 0004 R14: 8cf1b7e0 R15: 8cf1b820
  ? __srcu_read_unlock+0x1e/0x40
  ? cpuidle_enter_state+0xc5/0x430
  do_idle+0x28f/0x300
  ? arch_cpu_idle_exit+0x40/0x40
  ? schedule_idle+0x39/0x50
  cpu_startup_entry+0xc2/0xd0
  ? cpu_in_idle+0x20/0x20
  ? preempt_count_sub+0xaa/0x100
  ? preempt_count_add+0xaf/0xd0
  start_kernel+0x640/0x67d
  ? thread_stack_cache_init+0x6/0x6
  ? load_ucode_intel_bsp+0x5f/0xa5
  ? load_ucode_intel_bsp+0x5f/0xa5
  ? init_intel_microcode+0xb0/0xb0
  ? load_ucode_bsp+0xbb/0x156
  secondary_startup_64+0xa5/0xb0
 irq event stamp: 9229434
 hardirqs last  enabled at (9229434): [] 
trace_hardirqs_on_thunk+0x1a/0x1c
 hardirqs last disabled at (9229433): [] 
trace_hardirqs_off_thunk+0x1a/0x1c
 softirqs last  enabled at (9229416): [] irq_enter+0x7c/0x80
 softirqs last disabled at (9229417): [] irq_exit+0x128/0x130
 ---[ end trace 35ba8f92a3c06fd6 ]---
 [ cut here ]

When investigating, I found that interrupts were actually disabled, but
the bug was that lockdep was confused. As the asserts for expecting
interrupts disabled is now done by lockdep state tracking, it would be
nice to know if the bug is the interrupts not being disabled or lockdep
just thinking that they are disabled. Add a check within the WARN_ON()
to do the actual irqs_disabled() check (which only gets done when
lockdep thinks there's an error), and show that lockdep is broken if it
does not match up with the real state of interrupts.

Signed-off-by: Steven Rostedt (VMware) 

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index a8113357ceeb..c50c80eea41d 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -601,12 +601,16 @@ do {  
\
 #define lockdep_assert_irqs_enabled()  do {\
WARN_ONCE(debug_locks && !current->lockdep_recursion && \
  !current->hardirqs_enabled,   \
- "IRQs not enabled as expected\n");\
+ irqs_disabled() ? \
+ "IRQs not enabled as expected\n" :\
+ "IRQs enabled but lockdep reports they are 
disabled\n"); \
} while (0)
 
 #define lockdep_assert_irqs_disabled() do {\
WARN_ONCE(debug_locks && !current->lockdep_recursion && \
  current->hardirqs_enabled,\
+ irqs_disabled() ? \
+ "IRQs disabled but lockdep reports they are 
enabled\n" : \
  "IRQs not disabled as expected\n");   \
} while (0)
 

Re: New remoteproc driver for TI PRU

[Suman Anna]

Hi David,

On 08/06/2018 11:32 AM, David Lechner wrote:
> On 06/29/2018 07:17 PM, Suman Anna wrote:
>> Hi David,
>>
>> On 06/29/2018 12:44 PM, David Lechner wrote:
>>> On 06/29/2018 04:58 AM, Roger Quadros wrote:
 +Suman & Tero

 Hi David,

 On 24/06/18 00:08, David Lechner wrote:
>
> Date: Sat, 23 Jun 2018 15:43:59 -0500
> Subject: [PATCH 0/8] New remoteproc driver for TI PRU
>
> This series adds a new remoteproc driver for the TI Programmable
> Runtime Unit
> (PRU) that is present in some TI Sitara processors. This code has
> been tested
> working on AM1808 (LEGO MINDSTORMS EV3) and AM3358 (BeagleBone Green).

 This is great. We have been working on something similar and I think
 it would
 be great if we can collaborate to get all our needs addressed.
>>>
>>> Yes, I have used the PRU with the TI kernel on BeagleBone so I've seen
>>> the TI
>>> implementation. My primary interest is in the AM1808, which has a far
>>> simpler
>>> PRU than other SoCs. So, I was hoping I could get away with just
>>> implementing
>>> the basic stuff that I need and let TI add the more complex stuff later.
>>
>> Thanks for the series. PRUSS is present on many SoCs now, and each with
>> their own integration quirks, both in terms of SoC connections as well
>> as internal sub-modules within the subsystem. We currently support
>> AM335x, AM437x, AM57xx, Keystone 2 based 66AK2G and a newer generation
>> AM65x as well. It should be relatively straight-forward to scale this
>> for AM1808/OMAP-L138 as well. The move to the standard Common Clock and
>> Reset frameworks for clocks with the Davinci chips should make it
>> relatively straight-forward for the architecture pieces.
>>
>> I will take a look at your series in detail sometime next week, and
>> mostly post our series to the upstream lists as well within the next
>> couple of weeks so that it is easier for discussion on the upstream
>> lists.
>>
> 
> Have you had time to look at this yet? If you are too busy, I can submit
> a v2 with the interrupt controller broken out into a separate driver.

Yeah, I worked on it a bit around -rc4 time, but didn't get a chance to
complete the cleanup & testing before I had to shift to some other
tasks. If you are interested, I can share my branch. I will mostly get
back to this towards the latter half of next week. Anyway, I am
expecting 4.19-rc1 to be in a better shape w.r.t Davinci platform as the
genpd and CCF stuff comes in, and the pm_runtime usage for clocking in
my PRUSS drivers will fit well with those available.

regards
Suman

Re: [PATCH v5 05/12] PM / devfreq: Add support for policy notifiers

[Chanwoo Choi]

Hi Matthias,

On 2018년 08월 07일 09:23, Matthias Kaehlcke wrote:
> Hi Chanwoo,
> 
> On Tue, Aug 07, 2018 at 07:31:16AM +0900, Chanwoo Choi wrote:
>> Hi Matthias,
>>
>> On 2018년 08월 07일 04:21, Matthias Kaehlcke wrote:
>>> Hi Chanwoo,
>>>
>>> On Fri, Aug 03, 2018 at 09:14:46AM +0900, Chanwoo Choi wrote:
 Hi Matthias,

 On 2018년 08월 03일 08:48, Matthias Kaehlcke wrote:
> On Thu, Aug 02, 2018 at 04:13:43PM -0700, Matthias Kaehlcke wrote:
>> Hi Chanwoo,
>>
>> On Thu, Aug 02, 2018 at 10:58:59AM +0900, Chanwoo Choi wrote:
>>> Hi Matthias,
>>>
>>> On 2018년 08월 02일 02:08, Matthias Kaehlcke wrote:
 Hi Chanwoo,

 On Wed, Aug 01, 2018 at 10:22:16AM +0900, Chanwoo Choi wrote:
> On 2018년 08월 01일 04:39, Matthias Kaehlcke wrote:
>> On Mon, Jul 16, 2018 at 10:50:50AM -0700, Matthias Kaehlcke wrote:
>>> On Thu, Jul 12, 2018 at 05:44:33PM +0900, Chanwoo Choi wrote:
 Hi Matthias,

 On 2018년 07월 07일 02:53, Matthias Kaehlcke wrote:
> Hi Chanwoo,
>
> On Wed, Jul 04, 2018 at 03:41:46PM +0900, Chanwoo Choi wrote:
>
>> Firstly,
>> I'm not sure why devfreq needs the 
>> devfreq_verify_within_limits() function.
>>
>> devfreq already used the OPP interface as default. It means that
>> the outside of 'drivers/devfreq' can disable/enable the frequency
>> such as drivers/thermal/devfreq_cooling.c. Also, when some device
>> drivers disable/enable the specific frequency, the devfreq core
>> consider them.
>>
>> So, devfreq doesn't need to devfreq_verify_within_limits() 
>> because
>> already support some interface to change the minimum/maximum 
>> frequency
>> of devfreq device. 
>>
>> In case of cpufreq subsystem, cpufreq only provides 
>> 'cpufreq_verify_with_limits()'
>> to change the minimum/maximum frequency of cpu. some device 
>> driver cannot
>> change the minimum/maximum frequency through OPP interface.
>>
>> But, in case of devfreq subsystem, as I explained already, 
>> devfreq support
>> the OPP interface as default way. devfreq subsystem doesn't need 
>> to add
>> other way to change the minimum/maximum frequency.
>
> Using the OPP interface exclusively works as long as a
> enabling/disabling of OPPs is limited to a single driver
> (drivers/thermal/devfreq_cooling.c). When multiple drivers are
> involved you need a way to resolve conflicts, that's the purpose 
> of
> devfreq_verify_within_limits(). Please let me know if there are
> existing mechanisms for conflict resolution that I overlooked.
>
> Possibly drivers/thermal/devfreq_cooling.c could be migrated to 
> use
> devfreq_verify_within_limits() instead of the OPP interface if
> desired, however this seems beyond the scope of this series.

 Actually, if we uses this approach, it doesn't support the 
 multiple drivers too.
 If non throttler drivers uses devfreq_verify_within_limits(), the 
 conflict
 happen.
>>>
>>> As long as drivers limit the max freq there is no conflict, the 
>>> lowest
>>> max freq wins. I expect this to be the usual case, apparently it
>>> worked for cpufreq for 10+ years.
>>>
>>> However it is correct that there would be a conflict if a driver
>>> requests a min freq that is higher than the max freq requested by
>>> another. In this case devfreq_verify_within_limits() resolves the
>>> conflict by raising p->max to the min freq. Not sure if this is
>>> something that would ever occur in practice though.
>>>
>>> If we are really concerned about this case it would also be an 
>>> option
>>> to limit the adjustment to the max frequency.
>>>
 To resolve the conflict for multiple device driver, maybe OPP 
 interface
 have to support 'usage_count' such as clk_enable/disable().
>>>
>>> This would require supporting negative usage count values, since a 
>>> OPP
>>> should not be enabled if e.g. thermal enables it but the throttler
>>> disabled it or viceversa.
>>>
>>> Theoretically there could also be conflicts, like one driver 
>>> disabling
>>> the higher OPPs and another the lower ones, with the outcome of all
>>> OPPs being disabled, which would be a more drastic conflict 
>>> resolution
>>> th

Re: [PATCH 3/4] ARM64: dts: meson-gx: add dmcbus and canvas nodes.

[Yixun Lan]

hi Maxime:

On Sun, Aug 5, 2018 at 4:02 AM, Maxime Jourdan  wrote:
>>> +   sysctrl_DMC: system-controller@0 {
>>> +   compatible = 
>>> "amlogic,meson-gx-dmc-sysctrl", "syscon", "simple-mfd";
>>
>> we'd like to drop 'meson-' prefix, so better using "amlogic,gx-dmc-sysctrl",
>> please take a look at the discussion here [1]
>>
>> [1] https://lkml.kernel.org/r/7hk1prmg4w@baylibre.com
>>
>
> On that subject, should I remove the meson keyword from dts only, or
> from everything ?
>
remove the 'meson-' from dts is enough..

> e.g use amlogic_canvas_* symbols instead of meson_canvas_*, name the
> source file "amlogic-canvas.c", etc. ?
>
Actually, I'd suggest to keep using meson_canvas_* in the code for the
consistency,
unless Kevin or Jerome/Neil has something to say?

Yixun

[PATCH] perf ordered_events: fix crash in free_dup_event()

[Stephane Eranian]

Depending on memory allocations, it was possible to get a SEGFAULT in
free_dup_event() because the event pointer was bogus:

perf[1354]: segfault at 0006 ip 004b7fc7

Initially, I thought it was some double free. But it turns out
it looked more like a buffer overrun. Adding padding before
the union perf_event field in struct ordered_event avoided the
problem. But it was not obvious where this could be coming from
given the accesses to the struct, i.e.,  no internal array.

Then, it struck me that the following was bogus in __dup_event():

 __dup_event(struct ordered_events *oe, union perf_event *event)
{
   ...
   union perf_event *new_event;
   new_event = memdup(event, event->header.size);
   ...
}

The problem here is that header.size <= sizeof(*new_event). The code
was trying to copy only what was necessary, but then, the allocation
was also only partial. In other words if the event was not the largest
possible for the union, it would not be fully backed by memory, likely
causing troubles.

This patch fixes the problem by passing the size of the union and not
that of the actual event.

Signed-off-by: Stephane Eranian 

---
 tools/perf/util/ordered-events.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index bad9e0296e9a..a90dbe5df019 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -66,9 +66,9 @@ static union perf_event *__dup_event(struct ordered_events 
*oe,
union perf_event *new_event = NULL;
 
if (oe->cur_alloc_size < oe->max_alloc_size) {
-   new_event = memdup(event, event->header.size);
+   new_event = memdup(event, sizeof(*event));
if (new_event)
-   oe->cur_alloc_size += event->header.size;
+   oe->cur_alloc_size += sizeof(*event);
}
 
return new_event;
-- 
2.18.0.597.ga71716f1ad-goog

[RFC PATCH 1/2] x86: WARN() when uaccess helpers fault on kernel addresses

[Jann Horn]

There have been multiple kernel vulnerabilities that permitted userspace to
pass completely unchecked pointers through to userspace accessors:

 - the waitid() bug - commit 96ca579a1ecc ("waitid(): Add missing
   access_ok() checks")
 - the sg/bsg read/write APIs
 - the infiniband read/write APIs

These don't happen all that often, but when they do happen, it is hard to
test for them properly; and it is probably also hard to discover them with
fuzzing. Even when an unmapped kernel address is supplied to such buggy
code, it just returns -EFAULT instead of doing a proper BUG() or at least
WARN().

This patch attempts to make such misbehaving code a bit more visible by
WARN()ing in the pagefault handler code when a userspace accessor causes
#PF on a kernel address and the current context isn't whitelisted.

Signed-off-by: Jann Horn 
---
This is a hacky, quickly thrown-together PoC to see what people think
about the basic idea. Does it look like a sensible change? Or would it
be better, for example, to instead expand the KASan hooks in the
usercopy logic to also look at the "user" pointer if it points to
kernelspace? That would have the advantage of also catching heap
overflows properly...

I'm not really happy with all the plumbing in my patch; I wonder whether
there's a way around introducing _ASM_EXTABLE_UA() for user accessors?

arch/x86/include/asm/asm.h  |  10 ++-
 arch/x86/include/asm/extable.h  |   3 +-
 arch/x86/include/asm/fpu/internal.h |   6 +-
 arch/x86/include/asm/futex.h|   6 +-
 arch/x86/include/asm/uaccess.h  |  22 ++---
 arch/x86/kernel/cpu/mcheck/mce.c|   2 +-
 arch/x86/kernel/kprobes/core.c  |   2 +-
 arch/x86/kernel/traps.c |   6 +-
 arch/x86/lib/checksum_32.S  |   4 +-
 arch/x86/lib/copy_user_64.S |  90 ++--
 arch/x86/lib/csum-copy_64.S |   6 +-
 arch/x86/lib/getuser.S  |  12 +--
 arch/x86/lib/putuser.S  |  10 +--
 arch/x86/lib/usercopy_32.c  | 126 ++--
 arch/x86/lib/usercopy_64.c  |   4 +-
 arch/x86/mm/extable.c   |  67 ---
 arch/x86/mm/fault.c |   2 +-
 include/linux/sched.h   |   2 +
 mm/maccess.c|   6 ++
 19 files changed, 221 insertions(+), 165 deletions(-)

diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 990770f9e76b..38f44a773adf 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -130,6 +130,9 @@
 # define _ASM_EXTABLE(from, to)\
_ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
 
+# define _ASM_EXTABLE_UA(from, to) \
+   _ASM_EXTABLE_HANDLE(from, to, ex_handler_uaccess)
+
 # define _ASM_EXTABLE_FAULT(from, to)  \
_ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
 
@@ -165,8 +168,8 @@
jmp copy_user_handle_tail
.previous
 
-   _ASM_EXTABLE(100b,103b)
-   _ASM_EXTABLE(101b,103b)
+   _ASM_EXTABLE_UA(100b,103b)
+   _ASM_EXTABLE_UA(101b,103b)
.endm
 
 #else
@@ -182,6 +185,9 @@
 # define _ASM_EXTABLE(from, to)\
_ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
 
+# define _ASM_EXTABLE_UA(from, to) \
+   _ASM_EXTABLE_HANDLE(from, to, ex_handler_uaccess)
+
 # define _ASM_EXTABLE_FAULT(from, to)  \
_ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
 
diff --git a/arch/x86/include/asm/extable.h b/arch/x86/include/asm/extable.h
index f9c3a5d502f4..93c1d28f3c73 100644
--- a/arch/x86/include/asm/extable.h
+++ b/arch/x86/include/asm/extable.h
@@ -29,7 +29,8 @@ struct pt_regs;
(b)->handler = (tmp).handler - (delta); \
} while (0)
 
-extern int fixup_exception(struct pt_regs *regs, int trapnr);
+extern int fixup_exception(struct pt_regs *regs, int trapnr,
+  unsigned long pf_addr);
 extern int fixup_bug(struct pt_regs *regs, int trapnr);
 extern bool ex_has_fault_handler(unsigned long ip);
 extern void early_fixup_exception(struct pt_regs *regs, int trapnr);
diff --git a/arch/x86/include/asm/fpu/internal.h 
b/arch/x86/include/asm/fpu/internal.h
index a38bf5a1e37a..640e7721138c 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -113,7 +113,7 @@ extern void fpstate_sanitize_xstate(struct fpu *fpu);
 "3:  movl $-1,%[err]\n"\
 "jmp  2b\n"\
 ".previous\n"  \
-_ASM_EXTABLE(1b, 3b)   \
+_ASM_EXTABLE_UA(1b, 3b)\
 : [err] "=r" (err), output \
 : "0"(0), input);  

[RFC PATCH 2/2] lkdtm: test copy_to_user() on bad kernel pointer under KERNEL_DS

[Jann Horn]

Test whether the kernel WARN()s when, under KERNEL_DS, a bad kernel pointer
is used as "userspace" pointer. Test with "DIRECT" mode.

Signed-off-by: Jann Horn 
---
 drivers/misc/lkdtm/core.c |  1 +
 drivers/misc/lkdtm/lkdtm.h|  1 +
 drivers/misc/lkdtm/usercopy.c | 13 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
index 2154d1bfd18b..5a755590d3dc 100644
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@ -183,6 +183,7 @@ static const struct crashtype crashtypes[] = {
CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
CRASHTYPE(USERCOPY_STACK_BEYOND),
CRASHTYPE(USERCOPY_KERNEL),
+   CRASHTYPE(USERCOPY_KERNEL_DS),
 };
 
 
diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
index 9e513dcfd809..07db641d71d0 100644
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@ -82,5 +82,6 @@ void lkdtm_USERCOPY_STACK_FRAME_TO(void);
 void lkdtm_USERCOPY_STACK_FRAME_FROM(void);
 void lkdtm_USERCOPY_STACK_BEYOND(void);
 void lkdtm_USERCOPY_KERNEL(void);
+void lkdtm_USERCOPY_KERNEL_DS(void);
 
 #endif
diff --git a/drivers/misc/lkdtm/usercopy.c b/drivers/misc/lkdtm/usercopy.c
index 9725aed305bb..389475b25bb7 100644
--- a/drivers/misc/lkdtm/usercopy.c
+++ b/drivers/misc/lkdtm/usercopy.c
@@ -322,6 +322,19 @@ void lkdtm_USERCOPY_KERNEL(void)
vm_munmap(user_addr, PAGE_SIZE);
 }
 
+void lkdtm_USERCOPY_KERNEL_DS(void)
+{
+   char __user *user_ptr = (char __user *)ERR_PTR(-EINVAL);
+   mm_segment_t old_fs = get_fs();
+   char buf[10] = {0};
+
+   pr_info("attempting copy_to_user on unmapped kernel address\n");
+   set_fs(KERNEL_DS);
+   if (copy_to_user(user_ptr, buf, sizeof(buf)))
+   pr_info("copy_to_user un unmapped kernel address failed\n");
+   set_fs(old_fs);
+}
+
 void __init lkdtm_usercopy_init(void)
 {
/* Prepare cache that lacks SLAB_USERCOPY flag. */
-- 
2.18.0.597.ga71716f1ad-goog

linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi Al,

After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

/usr/bin/ld: /home/sfr/next/tmp/ccWnssuq.o: in function 
`dump_attr_TIMESTAMP_INFO':
test-fsinfo.c:(.text+0x5d4): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x618): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x65c): undefined reference to `pow'
/usr/bin/ld: test-fsinfo.c:(.text+0x6a0): undefined reference to `pow'

Caused by commit

  90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem information")

interacting with commit

  8377bd2b9ee1 ("kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS")

from the kbuild tree.

I have added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Tue, 7 Aug 2018 11:01:32 +1000
Subject: [PATCH] vfs: samples: fix up for HOSTLOADLIBES rename

Signed-off-by: Stephen Rothwell 
---
 samples/statx/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/samples/statx/Makefile b/samples/statx/Makefile
index 05b4d30cdd3c..6a862bbc0627 100644
--- a/samples/statx/Makefile
+++ b/samples/statx/Makefile
@@ -7,6 +7,6 @@ always := $(hostprogs-y)
 HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include
 
 HOSTCFLAGS_test-fsinfo.o += -I$(objtree)/usr/include
-HOSTLOADLIBES_test-fsinfo += -lm
+HOSTLDLIBS_test-fsinfo += -lm
 
 HOSTCFLAGS_test-fs-query.o += -I$(objtree)/usr/include
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgp_cmlOTOSr4.pgp
Description: OpenPGP digital signature

[BUG] 4.18-rcX iptables regression

[Bob Tracy]

With iptables v1.6.0 and kernel version 4.18-rc7, "iptables [-t table] -L"
produces diagnostic output to the effect of not being able to find the table.
Kernel version 4.17.0 and earlier work fine.

--Bob

Re: linux-next: build failure after merge of the vfs tree

[Stephen Rothwell]

Hi all,

On Mon, 6 Aug 2018 22:24:01 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 6 Aug 2018 10:37:38 +1000 Stephen Rothwell  
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> > 
> > samples/statx/test-fsinfo.c:26:10: fatal error: linux/fsinfo.h: No such 
> > file or directory
> >  #include 
> >   ^~~~
> > 
> > Caused by commit
> > 
> >   90b413cb970a ("vfs: syscall: Add fsinfo() to query filesystem 
> > information")
> > 
> > I guess that headers_install (or whatever its called) has not bee run
> > before the sample code is built.
> > 
> > I have applied the following patch for today:
> > 
> > From: Stephen Rothwell 
> > Date: Mon, 6 Aug 2018 10:29:34 +1000
> > Subject: [PATCH] vfs: don;t build new sample programs yet
> > 
> > It seems that headers_install is not done before the samples
> > are build so some needed include files are not in the right place.
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  samples/statx/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/samples/statx/Makefile b/samples/statx/Makefile
> > index 05b4d30cdd3c..0b4d01822eca 100644
> > --- a/samples/statx/Makefile
> > +++ b/samples/statx/Makefile
> > @@ -1,5 +1,5 @@
> >  # List of programs to build
> > -hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx test-fsinfo test-fs-query
> > +hostprogs-$(CONFIG_SAMPLE_STATX) := test-statx
> >  
> >  # Tell kbuild to always build the programs
> >  always := $(hostprogs-y)  
> 
> It turns out that commit
> 
>   ba5214f7f40c ("vfs: Implement parameter value retrieval with fsinfo()")
> 
> removed the "depends on BROKEN" from CONFIG_SAMPLE_STATX and that
> breaks other builds (at least allyesconfig on s390).

I have added the following suggested patch (I am sorry I can't
find/remember who pointed me to this patch) for today (I guess that it
should be merged via the vfs tree as that is what is causing the build
failures ... in which case a real patch should be supplied with
appropriate SOB line).  This seems to fix the current problem.

From: Masahiro Yamada 
Date: Tue, 7 Aug 2018 10:33:43 +1000
Subject: [PATCH] Try to get the headers installed before we build the samples

Signed-off-by: Stephen Rothwell 
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 9e71826f67d7..d224d94c14be 100644
--- a/Makefile
+++ b/Makefile
@@ -1023,6 +1023,7 @@ endif
 # Build samples along the rest of the kernel
 ifdef CONFIG_SAMPLES
 vmlinux-dirs += samples
+samples: headers_install
 endif
 
 # The actual objects are generated when descending,
-- 
2.18.0

-- 
Cheers,
Stephen Rothwell


pgpL_pp3DmTjt.pgp
Description: OpenPGP digital signature

[PATCH] proc: add percpu populated pages count to meminfo

[Dennis Zhou]

From: "Dennis Zhou (Facebook)" 

Currently, percpu memory only exposes allocation and utilization
information via debugfs. This more or less is only really useful for
understanding the fragmentation and allocation information at a
per-chunk level with a few global counters. This is also gated behind a
config. BPF and cgroup, for example, have seen an increase use causing
increased use of percpu memory. Let's make it easier for someone to
identify how much memory is being used.

This patch adds the PercpuPopulated stat to meminfo to more easily
look up how much percpu memory is in use. This new number includes the
cost for all backing pages and not just insight at the a unit, per
chunk level. This stat includes only pages used to back the chunks
themselves excluding metadata. I think excluding metadata is fair
because the backing memory scales with the number of cpus and can
quickly outweigh the metadata. It also makes this calculation light.

Signed-off-by: Dennis Zhou 
---
 fs/proc/meminfo.c  |  2 ++
 include/linux/percpu.h |  2 ++
 mm/percpu.c| 29 +
 3 files changed, 33 insertions(+)

diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 2fb04846ed11..ddd5249692e9 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -121,6 +122,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
   (unsigned long)VMALLOC_TOTAL >> 10);
show_val_kb(m, "VmallocUsed:", 0ul);
show_val_kb(m, "VmallocChunk:   ", 0ul);
+   show_val_kb(m, "PercpuPopulated:", pcpu_nr_populated_pages());
 
 #ifdef CONFIG_MEMORY_FAILURE
seq_printf(m, "HardwareCorrupted: %5lu kB\n",
diff --git a/include/linux/percpu.h b/include/linux/percpu.h
index 296bbe49d5d1..1c80be42822c 100644
--- a/include/linux/percpu.h
+++ b/include/linux/percpu.h
@@ -149,4 +149,6 @@ extern phys_addr_t per_cpu_ptr_to_phys(void *addr);
(typeof(type) __percpu *)__alloc_percpu(sizeof(type),   \
__alignof__(type))
 
+extern int pcpu_nr_populated_pages(void);
+
 #endif /* __LINUX_PERCPU_H */
diff --git a/mm/percpu.c b/mm/percpu.c
index 0b6480979ac7..08a4341f30c5 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -169,6 +169,14 @@ static LIST_HEAD(pcpu_map_extend_chunks);
  */
 int pcpu_nr_empty_pop_pages;
 
+/*
+ * The number of populated pages in use by the allocator, protected by
+ * pcpu_lock.  This number is kept per a unit per chunk (i.e. when a page gets
+ * allocated/deallocated, it is allocated/deallocated in all units of a chunk
+ * and increments/decrements this count by 1).
+ */
+static int pcpu_nr_populated;
+
 /*
  * Balance work is used to populate or destroy chunks asynchronously.  We
  * try to keep the number of populated free pages between
@@ -1232,6 +1240,7 @@ static void pcpu_chunk_populated(struct pcpu_chunk 
*chunk, int page_start,
 
bitmap_set(chunk->populated, page_start, nr);
chunk->nr_populated += nr;
+   pcpu_nr_populated += nr;
 
if (!for_alloc) {
chunk->nr_empty_pop_pages += nr;
@@ -1260,6 +1269,7 @@ static void pcpu_chunk_depopulated(struct pcpu_chunk 
*chunk,
chunk->nr_populated -= nr;
chunk->nr_empty_pop_pages -= nr;
pcpu_nr_empty_pop_pages -= nr;
+   pcpu_nr_populated -= nr;
 }
 
 /*
@@ -2176,6 +2186,9 @@ int __init pcpu_setup_first_chunk(const struct 
pcpu_alloc_info *ai,
pcpu_nr_empty_pop_pages = pcpu_first_chunk->nr_empty_pop_pages;
pcpu_chunk_relocate(pcpu_first_chunk, -1);
 
+   /* include all regions of the first chunk */
+   pcpu_nr_populated += PFN_DOWN(size_sum);
+
pcpu_stats_chunk_alloc();
trace_percpu_create_chunk(base_addr);
 
@@ -2745,6 +2758,22 @@ void __init setup_per_cpu_areas(void)
 
 #endif /* CONFIG_SMP */
 
+/*
+ * pcpu_nr_populated_pages - calculate total number of populated backing pages
+ *
+ * This reflects the number of pages populated to back the chunks.
+ * Metadata is excluded in the number exposed in meminfo as the number of
+ * backing pages scales with the number of cpus and can quickly outweigh the
+ * memory used for metadata.  It also keeps this calculation nice and simple.
+ *
+ * RETURNS:
+ * Total number of populated backing pages in use by the allocator.
+ */
+int pcpu_nr_populated_pages(void)
+{
+   return pcpu_nr_populated * pcpu_nr_units;
+}
+
 /*
  * Percpu allocator is initialized early during boot when neither slab or
  * workqueue is available.  Plug async management until everything is up
-- 
2.17.1

Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage

[Joel Fernandes]

On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt  wrote:
>
> With this patch applied, I'm constantly getting lockdep errors. Instead
> of doing a full revert of the patch, I did this, which makes all those
> errors go away. I may apply this for now, and we can revisit having
> lockdep use the tracepoint code. But since it's currently always
> enabled, I'm thinking of just leaving this as is. The macros are still
> clean from Joel's patch.
>
> Thoughts?

I like your patch. Thanks a lot for doing this.. It keeps most of the
benefits of my patch while avoiding the issues with lockdep. I agree
we can look at the remaining lockdep issue after. There were several
lockdep issues with this patch that I fixed over the the months, but
there's still the one that Masami reported that I believe you're also
seeing. Once I'm back I'll work on figuring that one out.

Could you pull in the fixes to the other issues I posted though? With
that we should be good.
https://lore.kernel.org/patchwork/patch/971104/
https://lore.kernel.org/patchwork/patch/971829/

thanks,

- Joel

Re: [PATCH v3 RESEND 2/2] tpm: add support for nonblocking operation

[James Bottomley]

On Mon, 2018-08-06 at 17:09 -0700, Tadeusz Struk wrote:
> On 08/06/2018 04:05 PM, James Bottomley wrote:
> > For an async interface, shouldn't I be able to queue an
> > arbitrary number of commands without blocking?
> 
> That was the approach in the v1 version of this patch, but
> Jason requested this to be changed so that only one command
> at a time can be processed.

He did?  I don't remember that.  I think he told you the TPM itself can
only process one operation at once so you didn't need an elaborate
allocation scheme.

But anyway, if you're happy to limit the interface to block after one
command is issued, how is it useful as an asynchronous interface?  I
thought the whole argument for the patch was to avoid the producer-
consumer approach which is possible with the current interface and to
use a fully event driven polling interface which can be implemented
single threaded.  If you can block in submission, this latter isn't
really possible because your interface isn't really asynchronous.

James

Your immediate response is required if you are alive

[Derek Langston]

Dear Client,

Please confirm if you are still alive because two gentle men 
walked into my office this morning to claim your inheritance 
funds with our bank. They said that you are dead and that they 
are your 
representative. I got your email from the file of your relative 
who is yet to be paid for the Contract he has executed before his 
death several years ago.You the beneficiary of this fund has 
not been in contact with the bank to claim your fund. The 
gentlemen submitted an address where they want your VISA DEBIT 
ATM CARD sent.

If you are still alive, please indicate by sending your full 
contact details within 7 day of receiving this message, faliure 
to do so, I will send the card to the address submitted by your 
representatives.


Regards

Derek

[GIT PULL] GPIO fix for v4.18

[Linus Walleij]

Hi Linus,

a single ACPI GPIO thingie that is standing out.

Please pull it in! Description in the commit log.

Yours,
Linus Walleij

The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:

  Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v4.18-3

for you to fetch changes up to ca876c7483b697b498868b1f575997191b077885:

  gpiolib-acpi: make sure we trigger edge events at least once on boot
(2018-08-01 11:45:10 +0200)


GPIO fixes for v4.18:

This is a single fix affecting X86 ACPI, and as such pretty important.
It is going to stable as well and have all the high-notch x86 platform
developers agreeing on it.


Benjamin Tissoires (1):
  gpiolib-acpi: make sure we trigger edge events at least once on boot

 drivers/gpio/gpiolib-acpi.c | 56 -
 1 file changed, 55 insertions(+), 1 deletion(-)

Re: [PATCH 0/3] introduce memory.oom.group

[Roman Gushchin]

On Mon, Aug 06, 2018 at 02:34:06PM -0700, David Rientjes wrote:
> On Wed, 1 Aug 2018, Roman Gushchin wrote:
> 
> > Ok, I think that what we'll do here:
> > 1) drop the current cgroup-aware OOM killer implementation from the mm tree
> > 2) land memory.oom.group to the mm tree (your ack will be appreciated)
> > 3) discuss and, hopefully, agree on memory.oom.policy interface
> > 4) land memory.oom.policy
> > 
> 
> Yes, I'm fine proceeding this way, there's a clear separation between the 
> policy and mechanism and they can be introduced independent of each other.  
> As I said in my patchset, we can also introduce policies independent of 
> each other and I have no objection to your design that addresses your 
> specific usecase, with your own policy decisions, with the added caveat 
> that we do so in a way that respects other usecases.
> 
> Specifically, I would ask that the following be respected:
> 
>  - Subtrees delegated to users can still operate as they do today with
>per-process selection (largest, or influenced by oom_score_adj) so
>their victim selection is not changed out from under them.  This
>requires the entire hierarchy is not locked into a specific policy,
>and also that a subtree is not locked in a specific policy.  In other
>words, if an oom condition occurs in a user-controlled subtree they
>have the ability to get the same selection criteria as they do today.
> 
>  - Policies are implemented in a way that has an extensible API so that
>we do not unnecessarily limit or prohibit ourselves from making changes
>in the future or from extending the functionality by introducing other
>policy choices that are needed in the future.
> 
> I hope that I'm not being unrealistic in assuming that you're fine with 
> these since it can still preserve your goals.
> 
> > Basically, with oom.group separated everything we need is another
> > boolean knob, which means that the memcg should be evaluated together.
> 
> In a cgroup-aware oom killer world, yes, we need the ability to specify 
> that the usage of the entire subtree should be compared as a single 
> entity with other cgroups.  That is necessary for user subtrees but may 
> not be necessary for top-level cgroups depending on how you structure your 
> unified cgroup hierarchy.  So it needs to be configurable, as you suggest, 
> and you are correct it can be different than oom.group.
> 
> That's not the only thing we need though, as I'm sure you were expecting 
> me to say :)
> 
> We need the ability to preserve existing behavior, i.e. process based and 
> not cgroup aware, for subtrees so that our users who have clear 
> expectations and tune their oom_score_adj accordingly based on how the oom 
> killer has always chosen processes for oom kill do not suddenly regress.

Isn't the combination of oom.group=0 and oom.evaluate_together=1 describing
this case? This basically means that if memcg is selected as target,
the process inside will be selected using traditional per-process approach.

> So we need to define the policy for a subtree that is oom, and I suggest 
> we do that as a characteristic of the cgroup that is oom ("process" vs 
> "cgroup", and process would be the default to preserve what currently 
> happens in a user subtree).

I'm not entirely convinced here.
I do agree, that some sub-tree may have a well tuned oom_score_adj,
and it's preferable to keep the current behavior.

At the same time I don't like the idea to look at the policy of the OOMing
cgroup. Why exceeding of one limit should be handled different to exceeding
of another? This seems to be a property of workload, not a limit.

> 
> Now, as users who rely on process selection are well aware, we have 
> oom_score_adj to influence the decision of which process to oom kill.  If 
> our oom subtree is cgroup aware, we should have the ability to likewise 
> influence that decision.  For example, we have high priority applications 
> that run at the top-level that use a lot of memory and strictly oom 
> killing them in all scenarios because they use a lot of memory isn't 
> appropriate.  We need to be able to adjust the comparison of a cgroup (or 
> subtree) when compared to other cgroups.
> 
> I've also suggested, but did not implement in my patchset because I was 
> trying to define the API and find common ground first, that we have a need 
> for priority based selection.  In other words, define the priority of a 
> subtree regardless of cgroup usage.
> 
> So with these four things, we have
> 
>  - an "oom.policy" tunable to define "cgroup" or "process" for that 
>subtree (and plans for "priority" in the future),
> 
>  - your "oom.evaluate_as_group" tunable to account the usage of the
>subtree as the cgroup's own usage for comparison with others,
> 
>  - an "oom.adj" to adjust the usage of the cgroup (local or subtree)
>to protect important applications and bias against unimportant
>applications.
> 
> This adds several tunables, wh

Re: [PATCH v5 05/12] PM / devfreq: Add support for policy notifiers

[Matthias Kaehlcke]

Hi Chanwoo,

On Tue, Aug 07, 2018 at 07:31:16AM +0900, Chanwoo Choi wrote:
> Hi Matthias,
> 
> On 2018년 08월 07일 04:21, Matthias Kaehlcke wrote:
> > Hi Chanwoo,
> > 
> > On Fri, Aug 03, 2018 at 09:14:46AM +0900, Chanwoo Choi wrote:
> >> Hi Matthias,
> >>
> >> On 2018년 08월 03일 08:48, Matthias Kaehlcke wrote:
> >>> On Thu, Aug 02, 2018 at 04:13:43PM -0700, Matthias Kaehlcke wrote:
>  Hi Chanwoo,
> 
>  On Thu, Aug 02, 2018 at 10:58:59AM +0900, Chanwoo Choi wrote:
> > Hi Matthias,
> >
> > On 2018년 08월 02일 02:08, Matthias Kaehlcke wrote:
> >> Hi Chanwoo,
> >>
> >> On Wed, Aug 01, 2018 at 10:22:16AM +0900, Chanwoo Choi wrote:
> >>> On 2018년 08월 01일 04:39, Matthias Kaehlcke wrote:
>  On Mon, Jul 16, 2018 at 10:50:50AM -0700, Matthias Kaehlcke wrote:
> > On Thu, Jul 12, 2018 at 05:44:33PM +0900, Chanwoo Choi wrote:
> >> Hi Matthias,
> >>
> >> On 2018년 07월 07일 02:53, Matthias Kaehlcke wrote:
> >>> Hi Chanwoo,
> >>>
> >>> On Wed, Jul 04, 2018 at 03:41:46PM +0900, Chanwoo Choi wrote:
> >>>
>  Firstly,
>  I'm not sure why devfreq needs the 
>  devfreq_verify_within_limits() function.
> 
>  devfreq already used the OPP interface as default. It means that
>  the outside of 'drivers/devfreq' can disable/enable the frequency
>  such as drivers/thermal/devfreq_cooling.c. Also, when some device
>  drivers disable/enable the specific frequency, the devfreq core
>  consider them.
> 
>  So, devfreq doesn't need to devfreq_verify_within_limits() 
>  because
>  already support some interface to change the minimum/maximum 
>  frequency
>  of devfreq device. 
> 
>  In case of cpufreq subsystem, cpufreq only provides 
>  'cpufreq_verify_with_limits()'
>  to change the minimum/maximum frequency of cpu. some device 
>  driver cannot
>  change the minimum/maximum frequency through OPP interface.
> 
>  But, in case of devfreq subsystem, as I explained already, 
>  devfreq support
>  the OPP interface as default way. devfreq subsystem doesn't need 
>  to add
>  other way to change the minimum/maximum frequency.
> >>>
> >>> Using the OPP interface exclusively works as long as a
> >>> enabling/disabling of OPPs is limited to a single driver
> >>> (drivers/thermal/devfreq_cooling.c). When multiple drivers are
> >>> involved you need a way to resolve conflicts, that's the purpose 
> >>> of
> >>> devfreq_verify_within_limits(). Please let me know if there are
> >>> existing mechanisms for conflict resolution that I overlooked.
> >>>
> >>> Possibly drivers/thermal/devfreq_cooling.c could be migrated to 
> >>> use
> >>> devfreq_verify_within_limits() instead of the OPP interface if
> >>> desired, however this seems beyond the scope of this series.
> >>
> >> Actually, if we uses this approach, it doesn't support the 
> >> multiple drivers too.
> >> If non throttler drivers uses devfreq_verify_within_limits(), the 
> >> conflict
> >> happen.
> >
> > As long as drivers limit the max freq there is no conflict, the 
> > lowest
> > max freq wins. I expect this to be the usual case, apparently it
> > worked for cpufreq for 10+ years.
> >
> > However it is correct that there would be a conflict if a driver
> > requests a min freq that is higher than the max freq requested by
> > another. In this case devfreq_verify_within_limits() resolves the
> > conflict by raising p->max to the min freq. Not sure if this is
> > something that would ever occur in practice though.
> >
> > If we are really concerned about this case it would also be an 
> > option
> > to limit the adjustment to the max frequency.
> >
> >> To resolve the conflict for multiple device driver, maybe OPP 
> >> interface
> >> have to support 'usage_count' such as clk_enable/disable().
> >
> > This would require supporting negative usage count values, since a 
> > OPP
> > should not be enabled if e.g. thermal enables it but the throttler
> > disabled it or viceversa.
> >
> > Theoretically there could also be conflicts, like one driver 
> > disabling
> > the higher OPPs and another the lower ones, with the outcome of all
> > OPPs being disabled, which would be a more drastic conflict 
> > resolution
> > than that of devfreq_verify_within_limits().
> >
> > Vir

Re: [PATCH v3 RESEND 2/2] tpm: add support for nonblocking operation

[Tadeusz Struk]

On 08/06/2018 04:05 PM, James Bottomley wrote:
> For an async interface, shouldn't I be able to queue an
> arbitrary number of commands without blocking?

That was the approach in the v1 version of this patch, but
Jason requested this to be changed so that only one command
at a time can be processed.
Thanks,
-- 
Tadeusz

Re: [PATCH v2] RISC-V: Don't use a global include guard for uapi/asm/syscalls.h

[Palmer Dabbelt]

On Mon, 06 Aug 2018 14:00:53 PDT (-0700), rdun...@infradead.org wrote:

On 08/06/2018 01:42 PM, Palmer Dabbelt wrote:

This file is expected to be included multiple times in the same file in
order to allow the __SYSCALL macro to generate system call tables.  With
a global include guard we end up missing __NR_riscv_flush_icache in the
syscall table, which results in icache flushes that escape the vDSO call
to not actually do anything.

The fix is to move to per-#define include guards, which allows the
system call tables to actually be populated.  Thanks to Macrus Comstedt
for finding and fixing the bug!

I also went ahead and fixed the SPDX header to use a //-style comment,
which I've been told is the canonical way to do it.

Cc: Marcus Comstedt 
Signed-off-by: Palmer Dabbelt 
---
 arch/riscv/include/asm/unistd.h|  5 +
 arch/riscv/include/uapi/asm/syscalls.h | 15 +--
 2 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/include/asm/unistd.h b/arch/riscv/include/asm/unistd.h
index 080fb28061de..508be1780323 100644
--- a/arch/riscv/include/asm/unistd.h
+++ b/arch/riscv/include/asm/unistd.h
@@ -11,6 +11,11 @@
  *   GNU General Public License for more details.
  */

+/*
+ * There is explicitly no include guard here because this file is expected to


to .. be .. included


Thanks.  I'm not going to spin a v3 unless there's more feedback, but I'll 
include it in the PR.





+ * included multiple times.  See uapi/asm/syscalls.h for more info.
+ */
+
 #define __ARCH_WANT_SYS_CLONE
 #include 
 #include 
diff --git a/arch/riscv/include/uapi/asm/syscalls.h 
b/arch/riscv/include/uapi/asm/syscalls.h
index 818655b0d535..690beb002d1d 100644
--- a/arch/riscv/include/uapi/asm/syscalls.h
+++ b/arch/riscv/include/uapi/asm/syscalls.h
@@ -1,10 +1,13 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+// SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2017 SiFive
+ * Copyright (C) 2017-2018 SiFive
  */

-#ifndef _ASM__UAPI__SYSCALLS_H
-#define _ASM__UAPI__SYSCALLS_H
+/*
+ * There is explicitly no include guard here because this file is expected to
+ * be included multiple times in order to define the syscall macros via


like that one :)


+ * __SYSCALL.
+ */

 /*
  * Allows the instruction cache to be flushed from userspace.  Despite RISC-V

Re: [PATCH] spi-nor: add support for is25wp256d

[Palmer Dabbelt]

On Mon, 06 Aug 2018 14:05:11 PDT (-0700), marek.va...@gmail.com wrote:

On 08/06/2018 10:58 PM, Palmer Dabbelt wrote:

On Sat, 04 Aug 2018 02:27:54 PDT (-0700), marek.va...@gmail.com wrote:

On 08/04/2018 03:49 AM, Palmer Dabbelt wrote:

From: "Wesley W. Terpstra" 

This is used of the HiFive Unleashed development board.

Signed-off-by: Wesley W. Terpstra 
Signed-off-by: Palmer Dabbelt 
---
 drivers/mtd/spi-nor/spi-nor.c | 47
++-
 include/linux/mtd/spi-nor.h   |  2 ++
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c
b/drivers/mtd/spi-nor/spi-nor.c
index d9c368c44194..e9a3557a3c23 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1072,6 +1072,9 @@ static const struct flash_info spi_nor_ids[] = {
 SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
 { "is25wp128",  INFO(0x9d7018, 0, 64 * 1024, 256,
 SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+    { "is25wp256d", INFO(0x9d7019, 0, 32 * 1024, 1024,


Is there a reason for the trailing 'd' in is25wp256d ? I'd drop it.


I'm honestly not sure.  There are data sheets for both of them, but I
don't see much of a difference

   http://www.issi.com/WW/pdf/IS25LP(WP)256D.pdf
   http://www.issi.com/WW/pdf/25LP-WP256.pdf

Following the pattern, I'd expect to see

   { "is25wp256",  INFO(0x9d7019, 0, 64 * 1024, 512,
   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },

versus

   { "is25wp256d", INFO(0x9d7019, 0, 32 * 1024, 1024,
   SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_4B_OPCODES)
   },


They have the same ID ? Do we support the variant without the d already?


Sorry for being a bit vague there.  There is no is25wp256 in the list already, 
but if I follow the pattern from the other similar chips I get a different 
value for is25wp256 than what was proposed in the patch for an is25wp256d.  
From my understanding the different values are just because we picked a 
different block size, which seems possible because the original version of this 
patch was written before the other is25wp devices were added to the list.


What I'm proposing is adding an is25wp256 with the same block size as the other 
similar entries in the list.  Looking at the data sheets they appear to have 
the same values for the "Read Product Identification" instruction.


The data sheets are shared with the is25lp256, which there is an entry for and 
matches my expected ID and block sizes.



So in other words: the d less sections that are larger, and also has the
4B opcodes flag set.  From the documentation in looks like the non-d
version supports 3 and 4 byte opcodes, so I guess it's just a different
physical layout?

In the data sheet for both I see

   "Pages can be erased in groups of 4Kbyte sectors, 32Kbyte blocks,
64Kbyte    blocks, and/or the entire chip"

which indicates to me that maybe we've just selected the larger section
size?  If so then I'll change it to the first one in the new patch.


+    SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ
| SPI_NOR_4B_OPCODES)
+    },

 /* Macronix */
 { "mx25l512e",   INFO(0xc22010, 0, 64 * 1024,   1, SECT_4K) },
@@ -1515,6 +1518,45 @@ static int macronix_quad_enable(struct spi_nor
*nor)
 return 0;
 }

+/**
+ * issi_unlock() - clear BP[0123] write-protection.
+ * @nor:    pointer to a 'struct spi_nor'
+ *
+ * Bits [2345] of the Status Register are BP[0123].
+ * ISSI chips use a different block protection scheme than other chips.
+ * Just disable the write-protect unilaterally.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int issi_unlock(struct spi_nor *nor)
+{
+    int ret, val;
+    u8 mask = SR_BP0 | SR_BP1 | SR_BP2 | SR_BP3;
+
+    val = read_sr(nor);
+    if (val < 0)
+    return val;
+    if (!(val & mask))
+    return 0;
+
+    write_enable(nor);
+
+    write_sr(nor, val & ~mask);
+
+    ret = spi_nor_wait_till_ready(nor);
+    if (ret)
+    return ret;
+
+    ret = read_sr(nor);
+    if (ret > 0 && !(ret & mask)) {
+    dev_info(nor->dev, "ISSI Block Protection Bits cleared\n");
+    return 0;


Is the dev_info() really needed ?


Nope.  I'll spin a v2 pending the above discussion.


+    } else {
+    dev_err(nor->dev, "ISSI Block Protection Bits not cleared\n");
+    return -EINVAL;
+    }
+}


[...]


Thanks!

Re: [PATCH v2] resource: Merge resources on a node when hot-adding memory

[Rashmica]

On 07/08/18 00:14, Mike Rapoport wrote:

> On Mon, Aug 06, 2018 at 04:52:24PM +1000, Rashmica Gupta wrote:
>> When hot-removing memory release_mem_region_adjustable() splits
>> iomem resources if they are not the exact size of the memory being
>> hot-deleted. Adding this memory back to the kernel adds a new
>> resource.
>>
>> Eg a node has memory 0x0 - 0xf. Offlining and hot-removing
>> 1GB from 0xf4000 results in the single resource 0x0-0xf being
>> split into two resources: 0x0-0xf3fff and 0xf8000-0xf.
>>
>> When we hot-add the memory back we now have three resources:
>> 0x0-0xf3fff, 0xf4000-0xf7fff, and 0xf8000-0xf.
>>
>> Now if we try to remove a section of memory that overlaps these resources,
>> like 2GB from 0xf4000, release_mem_region_adjustable() fails as it
>> expects the chunk of memory to be within the boundaries of a single
>> resource.
>>
>> This patch adds a function request_resource_and_merge(). This is called
>> instead of request_resource_conflict() when registering a resource in
>> add_memory(). It calls request_resource_conflict() and if hot-removing is
>> enabled (if it isn't we won't get resource fragmentation) we attempt to
>> merge contiguous resources on the node.
>>
>> Signed-off-by: Rashmica Gupta 
>> ---
>> v1->v2: Only attempt to merge resources if hot-remove is enabled.
>>
>>  include/linux/ioport.h |   2 +
>>  include/linux/memory_hotplug.h |   2 +-
>>  kernel/resource.c  | 116 
>> +
>>  mm/memory_hotplug.c|  22 
>>  4 files changed, 130 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>> index da0ebaec25f0..f5b93a711e86 100644
>> --- a/include/linux/ioport.h
>> +++ b/include/linux/ioport.h
>> @@ -189,6 +189,8 @@ extern int allocate_resource(struct resource *root, 
>> struct resource *new,
>> resource_size_t,
>> resource_size_t),
>>   void *alignf_data);
>> +extern struct resource *request_resource_and_merge(struct resource *parent,
>> +   struct resource *new, int 
>> nid);
>>  struct resource *lookup_resource(struct resource *root, resource_size_t 
>> start);
>>  int adjust_resource(struct resource *res, resource_size_t start,
>>  resource_size_t size);
>> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
>> index 4e9828cda7a2..9c00f97c8cc6 100644
>> --- a/include/linux/memory_hotplug.h
>> +++ b/include/linux/memory_hotplug.h
>> @@ -322,7 +322,7 @@ static inline void remove_memory(int nid, u64 start, u64 
>> size) {}
>>  extern int walk_memory_range(unsigned long start_pfn, unsigned long end_pfn,
>>  void *arg, int (*func)(struct memory_block *, void *));
>>  extern int add_memory(int nid, u64 start, u64 size);
>> -extern int add_memory_resource(int nid, struct resource *resource, bool 
>> online);
>> +extern int add_memory_resource(int nid, u64 start, u64 size, bool online);
> The add_memory_resource() function is also used by Xen balloon. It should
> be updated as well.

Thanks for spotting that.

>>  extern int arch_add_memory(int nid, u64 start, u64 size,
>>  struct vmem_altmap *altmap, bool want_memblock);
>>  extern void move_pfn_range_to_zone(struct zone *zone, unsigned long 
>> start_pfn,
>> diff --git a/kernel/resource.c b/kernel/resource.c
>> index 30e1bc68503b..5967061f9cea 100644
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
>> @@ -1621,3 +1621,119 @@ static int __init strict_iomem(char *str)
>>  }
>>
>>  __setup("iomem=", strict_iomem);
>> +
>> +#ifdef CONFIG_MEMORY_HOTPLUG
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +/*
>> + * Attempt to merge resource and it's sibling
>> + */
>> +static int merge_resources(struct resource *res)
>> +{
>> +struct resource *next;
>> +struct resource *tmp;
>> +uint64_t size;
>> +int ret = -EINVAL;
>> +
>> +next = res->sibling;
>> +
>> +/*
>> + * Not sure how to handle two different children. So only attempt
>> + * to merge two resources if neither have children, only one has a
>> + * child or if both have the same child.
>> + */
>> +if ((res->child && next->child) && (res->child != next->child))
>> +return ret;
>> +
>> +if (res->end + 1 != next->start)
>> +return ret;
>> +
>> +if (res->flags != next->flags)
>> +return ret;
>> +
>> +/* Update sibling and child of resource */
>> +res->sibling = next->sibling;
>> +tmp = res->child;
>> +if (!res->child)
>> +res->child = next->child;
>> +
>> +size = next->end - res->start + 1;
>> +ret = __adjust_resource(res, res->start, size);
>> +if (ret) {
>> +/* Failed so restore resource to original state */
>> +res->sibl

Re: [PATCH v9 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

[Mark Brown]

On Mon, Aug 06, 2018 at 03:55:53PM -0700, Doug Anderson wrote:
> On Thu, Jul 26, 2018 at 11:39 AM, Andy Gross  wrote:

> > The arm-soc guys merged the Qualcomm pull requests.  So you can just use my
> > qcom-drivers-for-4.19 tag.  That won't change at this point.

> > git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git
> > qcom-drivers-for-4.19

> Did Andy's idea of using the above tag work for you?  It appears that
> there are a few patches you don't need there, but it shouldn't hurt to
> pick them up too I think?  Here's what I see:

It does make my pull request look larger which is hard to get enthused
about.

> a3134fb09e0b drivers: soc: Add LLCC driver

Stuff like this jumped out for example.

> It seems like it's too late to land RPMh-regulator for 4.19, so I
> guess we'll have to aim for 4.20.  I'm not sure if that means you're
> going to want to wait until 4.20-rc1 comes out to use as a base before
> thinking about landing RPMh-regulator?  If so then I guess we've got

If I apply it after the merge window it's going to be based on -rc1.  If
I get to it this week I guess I'll have to pull in the drivers tag.


signature.asc
Description: PGP signature

Re: [PATCH] linux/bitmap.h: fix BITMAP_LAST_WORD_MASK

[Rasmus Villemoes]

On 2018-07-26 12:15, Wei Wang wrote:
> On 07/26/2018 05:37 PM, Yury Norov wrote:
>> On Thu, Jul 26, 2018 at 04:07:51PM +0800, Wei Wang wrote:
>>> The existing BITMAP_LAST_WORD_MASK macro returns 0x if nbits is
>>> 0. This patch changes the macro to return 0 when there is no bit
>>> needs to
>>> be masked.
>> I think this is intentional behavour. Previous version did return ~0UL
>> explicitly in this case. See patch 89c1e79eb3023 (linux/bitmap.h: improve
>> BITMAP_{LAST,FIRST}_WORD_MASK) from Rasmus.
> 
> Yes, I saw that. But it seems confusing for the corner case that nbits=0
> (no bits to mask), the macro returns with all the bits set.
> 
> 
>>
>> Introducing conditional branch would affect performance. All existing
>> code checks nbits for 0 before handling last word where needed
>> explicitly. So I think we'd better change nothing here.
> 
> I think that didn't save the conditional branch essentially, because
> it's just moved from inside this macro to the caller as you mentioned.
> If callers missed the check for some reason and passed 0 to the macro,
> they will get something unexpected.
> 
> Current callers like __bitmap_weight, __bitmap_equal, and others, they have
> 
> if (bits % BITS_PER_LONG)
>     w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));
> 
> we could remove the "if" check by "w += hweight_long(bitmap[k] &
> BITMAP_LAST_WORD_MASK(bits % BITS_PER_LONG));" the branch is the same.

Absolutely not! That would access bitmap[lim] (the final value of the k
variable) despite that word not being part of the bitmap.

More generally, look at the name of the macro: last_word_mask. It's a
mask to apply to the last word of a bitmap. If the bitmap happens to
consist of a multiple of BITS_PER_LONG bits, than that mask is and must
be ~0UL. So for nbits=64, 128, etc., that is what we want.

OTOH, for nbits=0, there _is_ no last word (since there are no words at
all), so by the time you want to apply the result of
BITMAP_LAST_WORD_MASK(0) to anything, you already have a bug, probably
either having read or being about to write into bitmap[0], which you
cannot do. Please check that user-space port and see if there are bugs
of that kind.

So no, the existing users of BITMAP_LAST_WORD_MASK do not check for
nbits being zero, they check for whether there is a partial last word,
which is something different. And they mostly (those in lib/bitmap.c) do
that because they've already handled _all_ the full words. Then there
are some users in include/linux/bitmap.h, that check for
small_const_nbits(nbits), and in those cases, we really want ~0UL when
nbits is BITS_PER_LONG, because small_const_nbits implies there is
exactly one word. Yeah, there's an implicit assumption that the bitmap
routines are never called with a compile-time constant nbits==0 (see the
unconditional accesses to *src and *dst), but changing the semantics of
BITMAP_LAST_WORD_MASK and making it return different values for nbits=0
vs nbits=64 wouldn't fix that latent bug.

Andrew, you may consider this a NAK of the v2 patch. Callers should
indeed avoid using BITMAP_LAST_WORD_MASK with nbits==0, but not because
the macro returns a wrong or unexpected value in that case, but simply
because it is meaningless to use it at all.

Rasmus

Re: [PATCH 3/4] watchdog: hpwdt: Display module parameters.

[Jerry Hoemann]

On Sat, Aug 04, 2018 at 06:13:20PM -0700, Guenter Roeck wrote:
> On 08/02/2018 02:15 PM, Jerry Hoemann wrote:
> > Print module parameters when the driver is loaded.
> > 
> > Signed-off-by: Jerry Hoemann 
> > ---
> >   drivers/watchdog/hpwdt.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
> > index 8a85ddd..f098371 100644
> > --- a/drivers/watchdog/hpwdt.c
> > +++ b/drivers/watchdog/hpwdt.c
> > @@ -326,8 +326,9 @@ static int hpwdt_init_one(struct pci_dev *dev,
> > }
> > dev_info(&dev->dev, "HPE Watchdog Timer Driver: %s"
> > -   ", timer margin: %d seconds (nowayout=%d).\n",
> > -   HPWDT_VERSION, hpwdt_dev.timeout, nowayout);
> > +   ", timeout : %d seconds (nowayout=%d) pretimeout=%s.\n",
> > +   HPWDT_VERSION, hpwdt_dev.timeout, nowayout,
> > +   pretimeout ? "on" : "off");
> When touching that, you might as well address
> 
> WARNING: quoted string split across lines


k. Think I'll split into two dev_info calls as line is too long
to fit into 80 chars w/o splitting.


> 
> Why did you add a space before ':' ? Personal preference ?

I think you're referring to "timeout : %d seconds".  Bad editting when
going from "timer margin:" to "timeout :".  I'll fix.

If you referring to the spaces around the ternary operator, that is
in coding-style although checkpatch accepts w/o spaces around the
operators.


> 
> Guenter
> 
> > if (dev->subsystem_vendor == PCI_VENDOR_ID_HP_3PAR)
> > ilo5 = true;
> > 

-- 

-
Jerry Hoemann  Software Engineer   Hewlett Packard Enterprise
-

[RFC] RISC-V: Fix !CONFIG_SMP compilation error

[Atish Patra]

Enabling both CONFIG_PERF_EVENTS without !CONFIG_SMP
generates following compilation error.

arch/riscv/include/asm/perf_event.h:80:2: error: expected
specifier-qualifier-list before 'irqreturn_t'

  irqreturn_t (*handle_irq)(int irq_num, void *dev);
  ^~~

Include interrupt.h in proper place to avoid compilation
error.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/perf_event.h | 1 +
 arch/riscv/kernel/perf_event.c  | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/perf_event.h 
b/arch/riscv/include/asm/perf_event.h
index 0e638a0c..aefbfaa6 100644
--- a/arch/riscv/include/asm/perf_event.h
+++ b/arch/riscv/include/asm/perf_event.h
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 
 #define RISCV_BASE_COUNTERS2
 
diff --git a/arch/riscv/kernel/perf_event.c b/arch/riscv/kernel/perf_event.c
index b0e10c4e..a243fae1 100644
--- a/arch/riscv/kernel/perf_event.c
+++ b/arch/riscv/kernel/perf_event.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.7.4

Re: [PATCH 0/2] x86/intel_rdt and perf/x86: Fix lack of coordination with perf

[Reinette Chatre]

Hi Peter,

On 8/6/2018 3:12 PM, Peter Zijlstra wrote:
> On Mon, Aug 06, 2018 at 12:50:50PM -0700, Reinette Chatre wrote:
>> In my previous email I provided the details of the Cache Pseudo-Locking
>> feature implemented on top of resctrl. Please let me know if you would
>> like any more details about that. I can send you more materials.
> 
> I've no yet had time to read..
> 
>> BUG: sleeping function called from invalid context at
>> kernel/locking/mutex.c:748
>>
>> I thus continued to use the API with interrupts enabled did the following:
>>
>> Two new event attributes:
>> static struct perf_event_attr l2_miss_attr = {
>> .type   = PERF_TYPE_RAW,
>> .config = (0x10ULL << 8) | 0xd1,
> 
> Please use something like:
> 
>   X86_CONFIG(.event=0xd1, .umask=0x10),
> 
> that's ever so much more readable.
> 
>> .size   = sizeof(struct perf_event_attr),
>> .pinned = 1,
>> .disabled   = 1,
>> .exclude_user   = 1
>> };
>>
>> static struct perf_event_attr l2_hit_attr = {
>> .type   = PERF_TYPE_RAW,
>> .config = (0x2ULL << 8) | 0xd1,
>> .size   = sizeof(struct perf_event_attr),
>> .pinned = 1,
>> .disabled   = 1,
>> .exclude_user   = 1
>> };
>>
>> Create the two new events using these attributes:
>> l2_miss_event = perf_event_create_kernel_counter(&l2_miss_attr, cpu,
>> NULL, NULL, NULL);
>> l2_hit_event = perf_event_create_kernel_counter(&l2_hit_attr, cpu, NULL,
>> NULL, NULL);
>>
>> Take measurements:
>> perf_event_enable(l2_miss_event);
>> perf_event_enable(l2_hit_event);
>> local_irq_disable();
>> /* Disable hardware prefetchers */
>> /* Loop through pseudo-locked memory */
>> /* Enable hardware prefetchers */
>> local_irq_enable();
>> perf_event_disable(l2_hit_event);
>> perf_event_disable(l2_miss_event);
>>
>> Read results:
>> l2_hits = perf_event_read_value(l2_hit_event, &enabled, &running);
>> l2_miss = perf_event_read_value(l2_miss_event, &enabled, &running);
>> /* Make results available in tracepoints */
> 
> switch to .disabled=0 and try this for measurement:
> 
>   local_irq_disable();
>   perf_event_read_local(l2_miss_event, &miss_val1, NULL, NULL);
>   perf_event_read_local(l2_hit_event, &hit_val1, NULL, NULL);
>   /* do your thing */
>   perf_event_read_local(l2_miss_event, &miss_val2, NULL, NULL);
>   perf_event_read_local(l2_hit_event, &hit_val2, NULL, NULL);
>   local_irq_enable();

Thank you very much for taking a look and providing your guidance.

> 
> You're running this on the CPU you created the event for, right?

Yes.

I've modified your suggestion slightly in an attempt to gain accuracy.
Now it looks like:

local_irq_disable();
/* disable hw prefetchers */
/* init local vars to loop through pseudo-locked mem */
perf_event_read_local(l2_hit_event, &l2_hits_before, NULL, NULL);
perf_event_read_local(l2_miss_event, &l2_miss_before, NULL, NULL);
/* loop through pseudo-locked mem */
perf_event_read_local(l2_hit_event, &l2_hits_after, NULL, NULL);
perf_event_read_local(l2_miss_event, &l2_miss_after, NULL, NULL);
/* enable hw prefetchers */
local_irq_enable();

With the above I do not see the impact of an interference workload
anymore but the results are not yet accurate:

pseudo_lock_mea-538   [002]    113.296084: pseudo_lock_l2: hits=4103
miss=2
pseudo_lock_mea-541   [002]    114.349343: pseudo_lock_l2: hits=4102
miss=3
pseudo_lock_mea-544   [002]    115.410206: pseudo_lock_l2: hits=4101
miss=4
pseudo_lock_mea-551   [002]    116.473912: pseudo_lock_l2: hits=4102
miss=3
pseudo_lock_mea-554   [002]    117.532446: pseudo_lock_l2: hits=4100
miss=5
pseudo_lock_mea-557   [002]    118.591121: pseudo_lock_l2: hits=4103
miss=2
pseudo_lock_mea-560   [002]    119.642467: pseudo_lock_l2: hits=4102
miss=3
pseudo_lock_mea-563   [002]    120.698562: pseudo_lock_l2: hits=4102
miss=3
pseudo_lock_mea-566   [002]    121.769348: pseudo_lock_l2: hits=4105
miss=4

In an attempt to improve the accuracy of the above I modified it to the
following:

/* create the two events as before in "enabled" state */
l2_hit_pmcnum = l2_hit_event->hw.event_base_rdpmc;
l2_miss_pmcnum = l2_miss_event->hw.event_base_rdpmc;
local_irq_disable();
/* disable hw prefetchers */
/* init local vars to loop through pseudo-locked mem */
l2_hits_before = native_read_pmc(l2_hit_pmcnum);
l2_miss_before = native_read_pmc(l2_miss_pmcnum);
/* loop through pseudo-locked mem */
l2_hits_after = native_read_pmc(l2_hit_pmcnum);
l2_miss_after = native_read_pmc(l2_miss_pmcnum);
/* enable hw prefetchers */
local_irq_enable();

With the above I seem to get the same accuracy as before:
pseudo_lock_mea-557   [002]    155.402566: pseudo_lock_l2: hits=4096
miss=0
pseudo_lock_mea-564   [002]    156.441299: pseudo_lock_l2: hits=4096
miss=0
pseudo_lock_mea-567   [002]    157.478605: pseudo_lock_l2: hits=4096
miss=0
pseud

Re: [PATCH] Input: cros_ec_keyb: Remove check before calling pm_wakeup_event.

[Ravi Chandra Sadineni]

Hi Merek,

Thanks for the info. Lemme understand what's going on. Will update the
thread once I have more info.

Thanks,
Ravi
On Mon, Aug 6, 2018 at 12:15 AM Marek Szyprowski
 wrote:
>
> Hi Dmitry
>
> On 2018-08-06 08:16, Dmitry Torokhov wrote:
> > On Sun, Aug 5, 2018 at 10:29 PM Marek Szyprowski
> >  wrote:
> >> Hi Ravi,
> >>
> >> On 2018-08-03 18:53, Ravi Chandra Sadineni wrote:
> >>> Understood. I am trying to reproduce this issue locally. Wanted to
> >>> know the version of the kernel so I can give a try. Marek, can you
> >>> please confirm the kernel version.
> >>>
> >> Yes, sorry for the missing context, I was in hurry writing the report and
> >> I wanted to send it before leaving the office. I'm testing mainline on Snow
> >> with exynos_defconfig.
> >>
> >> Suspend/resume is partially broken already with mainline, but if you 
> >> disable
> >> CPUfreq support, it works fine on Linux v4.17.
> >>
> >> I've posted CPUfreq related fixes here if you are interested:
> >> https://patchwork.kernel.org/patch/10554607/
> >> https://patchwork.kernel.org/patch/10554603/
> >>
> >> The issue with cros_ec_keyb patch appears first on Linux v4.18-rc1, which 
> >> is
> >> the first release with that patch.
> > Marek, this patch should only be in -next, I do not believe I sent it
> > to Linus just yet. If mainline is broken for you it can't be caused by
> > this patch.
>
> Aaahh. My fault then. The suspend/resume issue is cause by commit
> 38ba34a43dbc ("Input: cros_ec_keyb - mark cros_ec_keyb driver as wake
> enabled device."), which has been merged to v4.18-rc1.
>
> It looks that I've downloaded wrong patch from the patchwork to reply it
> with a a bug report. :( I'm really sorry for the noise in the wrong thread.
>
> Ravi: please let me know how can I help you to debug this issue.
>
> >
> >> Linux -next from 20180803, which has a few
> >> more patches for cros_ec_keyb suffers from the same issue.
> > Just to confirm, if you revert only this patch from -next you get
> > suspend/resume back?
> >
> > Thanks.
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>

Re: [PATCH v3 RESEND 2/2] tpm: add support for nonblocking operation

[James Bottomley]

On Mon, 2018-08-06 at 14:14 -0700, Tadeusz Struk wrote:
[...]
> +static void tpm_async_work(struct work_struct *work)
> +{
> + struct file_priv *priv =
> + container_of(work, struct file_priv,
> async_work);
> + ssize_t ret;
> +
> + ret = tpm_transmit(priv->chip, priv->space, priv-
> >data_buffer,
> +    sizeof(priv->data_buffer), 0);

Here' you assume the buffer_mutex was taken in write, which is done
(see below).  However, here, since there was no change to tpm_transmit,
you'll sleep in the context of the worker queue waiting for the command
to complete and return.

> + tpm_put_ops(priv->chip);
> + if (ret > 0) {
> + priv->data_pending = ret;
> + mod_timer(&priv->user_read_timer, jiffies + (120 *
> HZ));
> + }
> + mutex_unlock(&priv->buffer_mutex);

But you don't release buffer_mutex here until the tpm command has
completed.

> + wake_up_interruptible(&priv->async_wait);
> +}
> +

[...]
> @@ -118,25 +155,48 @@ ssize_t tpm_common_write(struct file *file,
> const char __user *buf,
>    * the char dev is held open.
>    */
>   if (tpm_try_get_ops(priv->chip)) {
> - mutex_unlock(&priv->buffer_mutex);
> - return -EPIPE;
> + ret = -EPIPE;
> + goto out;
>   }
> - out_size = tpm_transmit(priv->chip, priv->space, priv-
> >data_buffer,
> - sizeof(priv->data_buffer), 0);
>  
> - tpm_put_ops(priv->chip);
> - if (out_size < 0) {
> - mutex_unlock(&priv->buffer_mutex);
> - return out_size;
> + /*
> +  * If in nonblocking mode schedule an async job to send
> +  * the command return the size.
> +  * In case of error the err code will be returned in
> +  * the subsequent read call.
> +  */
> + if (file->f_flags & O_NONBLOCK) {
> + queue_work(tpm_dev_wq, &priv->async_work);
> + return size;

Here you return holding the buffer_mutex, waiting for tpm_async_work to
release it.

But now I've written my tpm work item and got it queued, I can't write
another one without blocking on the buffer_mutex at the top of
tpm_common_write(), and since that doesn't get released until the
previous command completed, I can only queue one command before I
block.  For an async interface, shouldn't I be able to queue an
arbitrary number of commands without blocking?

James

Re: [PATCH] perf/x86/intel: Fix unwind errors from PEBS entries (mk-II)

[Fubo Chen]

On Mon, Aug 6, 2018 at 3:30 PM Peter Zijlstra  wrote:
>
> On Mon, Aug 06, 2018 at 02:28:18PM -0700, Fubo Chen wrote:
> > Do you think the patch below is sufficient to suppress the sparse warning?
>
> Why would I want to make the code ugly to supress it?

There are many kernel developers who use sparse to verify the
correctness of endianness annotations (__be32, __le32, ...). When
compiling kernel code with sparse every warning that is reported by
sparse should be analyzed. Most kernel developers consider it annoying
having to deal with false positive warnings. So I think that is useful
to suppress false positive sparse warnings if it is possible to
suppress false positives with a reasonable effort.

Thanks,

Fubo.



-- 
Fubo.

Re: [PATCH] mm: adjust max read count in generic_file_buffered_read()

[Andrew Morton]

On Mon, 6 Aug 2018 12:22:03 +0200 Jan Kara  wrote:

> On Fri 20-07-18 16:14:29, Andrew Morton wrote:
> > On Thu, 19 Jul 2018 10:58:12 +0200 Jan Kara  wrote:
> > 
> > > On Thu 19-07-18 16:17:26, Chengguang Xu wrote:
> > > > When we try to truncate read count in generic_file_buffered_read(),
> > > > should deliver (sb->s_maxbytes - offset) as maximum count not
> > > > sb->s_maxbytes itself.
> > > > 
> > > > Signed-off-by: Chengguang Xu 
> > > 
> > > Looks good to me. You can add:
> > > 
> > > Reviewed-by: Jan Kara 
> > 
> > Yup.
> > 
> > What are the runtime effects of this bug?
> 
> Good question. I think ->readpage() could be called for index beyond
> maximum file size supported by the filesystem leading to weird filesystem
> behavior due to overflows in internal calculations.
> 

Sure.  But is it possible for userspace to trigger this behaviour? 
Possibly all callers have already sanitized the arguments by this stage
in which case the statement is arguably redundant.

I guess I'll put a cc:stable on it and send it in for 4.19-rc1, so we
get a bit more time to poke at it.  But we should have a better
understanding of the userspace impact.

Re: [PATCH v9 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

[Doug Anderson]

Mark,

On Thu, Jul 26, 2018 at 11:39 AM, Andy Gross  wrote:
> + olof
>
> On Tue, Jul 24, 2018 at 05:59:42PM +0100, Mark Brown wrote:
>> On Tue, Jul 24, 2018 at 08:43:46AM -0700, Doug Anderson wrote:
>> > On Tue, Jul 24, 2018 at 8:25 AM, Mark Brown  wrote:
>>
>> > > There was also some other thing called command DB as well which was a
>> > > separate series.  Ideally there'd be a branch I could pull as there's a
>> > > build dependency on rpmh so I can't apply until the code has landed in
>> > > my tree, don't know what command DB is exactly.
>>
>> > Yup.  That one landed in May and is already in mainline Linux.  Refer
>> > to commit 312416d9171a ("drivers: qcom: add command DB driver").
>>
>> That's good at least - the cover letter said it was still under review,
>> guess it just hadn't been updated.
>>
>> > Adding Andy to this thread (I guess he wasn't on it?).  Hopefully he
>> > can provide you with the branch.
>>
> Mark,
>
> The arm-soc guys merged the Qualcomm pull requests.  So you can just use my
> qcom-drivers-for-4.19 tag.  That won't change at this point.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git
> qcom-drivers-for-4.19

Did Andy's idea of using the above tag work for you?  It appears that
there are a few patches you don't need there, but it shouldn't hurt to
pick them up too I think?  Here's what I see:

---

$ git log --oneline linux/master..qcom-drivers-for-4.19
78ee559d7fc6 (tag: qcom-drivers-for-4.19) soc: qcom: rmtfs-mem: fix
memleak in probe error paths
4da3b0452bc6 soc: qcom: llc-slice: Add missing MODULE_LICENSE()
6c805adf17d4 drivers: qcom: rpmh: fix unwanted error check for get_tcs_of_type()
efa1c257b3fc drivers: qcom: rpmh-rsc: fix the loop index check in
get_req_from_tcs
a0b1561f8461 firmware: qcom: scm: add a dummy qcom_scm_assign_mem()
fdd102b52cfd drivers: qcom: rpmh-rsc: Check cmd_db_ready() to help children
2de4b8d33eab drivers: qcom: rpmh-rsc: allow active requests from wake TCS
c8790cb6da58 drivers: qcom: rpmh: add support for batch RPMH request
564b5e24ccd4 drivers: qcom: rpmh: allow requests to be sent asynchronously
600513dfeef3 drivers: qcom: rpmh: cache sleep/wake state requests
9a3afcfbc0cc drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS
fa460e453a83 drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS
c1038456b02b drivers: qcom: rpmh: add RPMH helper functions
fc087fe5a45e drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE
2e4690a09fca dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs
658628e7ef78 drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs
a3134fb09e0b drivers: soc: Add LLCC driver
7e5700ae64f6 dt-bindings: Documentation for qcom, llcc
0b65c59e3a54 soc: qcom: smem: Correct check for global partition

---

It seems like it's too late to land RPMh-regulator for 4.19, so I
guess we'll have to aim for 4.20.  I'm not sure if that means you're
going to want to wait until 4.20-rc1 comes out to use as a base before
thinking about landing RPMh-regulator?  If so then I guess we've got
~3 weeks before something could land and we could start landing device
tree bits using RPMh-regulator.  If that's the plan then we'll
probably just start landing things in the Chrome OS tree now and suck
up the extra work of trying to resolve differences later...

Thanks!

-Doug

Re: [PATCH rdma-next v4 2/3] test_overflow: Add shift overflow tests

[Rasmus Villemoes]

On 2018-08-01 23:25, Kees Cook wrote:
> This adds overflow tests for the new check_shift_overflow() helper to
> validate overflow, signedness glitches, storage glitches, etc.
> 

Just a few random comments, not really anything worth a v5 by itself.
IOW, I can live with this being sent upstream during next merge window.

> Co-developed-by: Rasmus Villemoes 
> Signed-off-by: Kees Cook 
> ---
> +static int __init test_overflow_shift(void)
> +{
> + int err = 0;
> +
> +/* Args are: value, shift, type, expected result, overflow expected */
> +#define TEST_ONE_SHIFT(a, s, t, expect, of) ({   
> \
> + int __failed = 0;   \
> + typeof(a) __a = (a);\
> + typeof(s) __s = (s);\
> + t __e = (expect);   \
> + t __d;  \
> + bool __of = check_shl_overflow(__a, __s, &__d); \
> + if (__of != of) {   \
> + pr_warn("expected (%s)(%s << %s) to%s overflow\n",  \
> + #t, #a, #s, of ? "" : " not");  \
> + __failed = 1;   \
> + } else if (!__of && __d != __e) {   \
> + pr_warn("expected (%s)(%s << %s) == %s\n",  \
> + #t, #a, #s, #expect);   \
> + if ((t)-1 < 0)  \
> + pr_warn("got %lld\n", (s64)__d);\
> + else\
> + pr_warn("got %llu\n", (u64)__d);\
> + __failed = 1;   \
> + }   \
> + if (!__failed)  \
> + pr_info("ok: (%s)(%s << %s) == %s\n", #t, #a, #s,   \
> + of ? "overflow" : #expect); \

Isn't that a bit much, one pr_info for every test case (especially with
the number of test cases you've done, and thanks for that btw.)? For the
others, there's just one "doing nnn tests". It's harder here because we
can only let the tests count themselves, but we could have
TEST_ONE_SHIFT do exactly that and then print a pr_info at the end (or
pr_warn if any failed).

[Or, if we're willing to do something a bit ugly, forward-declaring
file-scope statics is actually allowed, and can be combined with
__COUNTER__...

#define foo() printf("test number %d\n", __COUNTER__)

static int start;
static int end;

static int start = __COUNTER__;
void t(void)
{
printf("Will do %d tests\n", end - start);
foo();
foo();
}
static int end = __COUNTER__ - 1;

the expansion of TEST_ONE_SHIFT wouldn't have to use __COUNTER__ in any
meaningful way. This of course goes out the window if
check_shl_overflow is robustified with UNIQUE_ID. There's even a way to
work around that, but I'd better stop here.]


> + __failed;   \
> +})
> +
> + err |= TEST_ONE_SHIFT(1, 0, int, 1 << 0, false);
> + err |= TEST_ONE_SHIFT(1, 16, int, 1 << 16, false);
> + err |= TEST_ONE_SHIFT(1, 30, int, 1 << 30, false);
> + err |= TEST_ONE_SHIFT(1, 0, s32, 1 << 0, false);
> + err |= TEST_ONE_SHIFT(1, 16, s32, 1 << 16, false);
> + err |= TEST_ONE_SHIFT(1, 30, s32, 1 << 30, false);

I don't see much point in doing both int and s32 as they are AFAIK
unconditionally the same on all architectures. Similarly for unsigned
int/u32.

> +
> + /* Overflow: shifted at or beyond entire type's bit width. */
> + err |= TEST_ONE_SHIFT(0, 8, u8, 0, true);
> + err |= TEST_ONE_SHIFT(0, 9, u8, 0, true);

Hmm, seeing these I'd actually rather we didn't base the upper bound for
the shift count on sizeof(*d) but rather used a fixed 64, since that's
what we use for the temporary variable, and capping the shift count is
mostly for avoiding UB in the implementation. For any non-zero input
value, a shift count greater than 8 would still report overflow because
of the truncation.

More generally, I think that if the actual C expression

  a << s

doesn't invoke UB (i.e., a is non-negative and s is sane according to
the type of a), no bits are lots during the shift, and the result fits
in *d, we should not report overflow. Hence we should not impose
arbitrary limits on s just because the destination happens to be u8.
That some shift count/destination type combos then happen to guarantee
overflow for all but an input of 0 is just the way the math works.

> +
> + /*
> +  * Corner case: for unsigned types, we fail when we've shifted
> +  * through t

Re: [RFC PATCH v2 1/2] interconnect: qcom: Add sdm845 interconnect provider driver

[Bjorn Andersson]

On Wed 18 Jul 19:36 PDT 2018, David Dai wrote:
> diff --git a/drivers/interconnect/qcom/sdm845.c 
> b/drivers/interconnect/qcom/sdm845.c
[..]
> +DEFINE_QNODE(ipa_core_master, MASTER_IPA_CORE, 1, 8, 1, SLAVE_IPA_CORE);
[..]
> +DEFINE_QNODE(ipa_core_slave, SLAVE_IPA_CORE, 1, 8, 0);

As discussed before; while the two sides of IPA_CORE are controlled
through the "bus mechanism", they do represent the clock of the IPA
block.

I think it would make sense to make this interconnect provider also
register a clock provider and expose this as a clock, for the IPA driver
to consume.

Regards,
Bjorn

Re: [PATCH v5 05/12] PM / devfreq: Add support for policy notifiers

[Chanwoo Choi]

Hi Viresh Kumar,

I have a question about dev_pm_opp_enable() and dev_pm_opp_disable().
Two functions have 'available' field to indicate the status of specific OPP.

If different device drivers try to control the same OPP,
dev_pm_opp_enable() and dev_pm_opp_disable() will consider only last operation.
It means that OPP should be enabled/disabled by only one device driver.

For example,
opp_table of driver a(dev_a)
- 500Mhz
- 400Mhz
- 300Mhz
- 200Mhz
- 100Mhz

Driver B, opp_disable(dev_a, 500)
Driver C, opp_enable(dev_a, 500)
-> 500Mhz is enabled. But, driver B might want to enable 500Mhz at this time 
such as cooling.

I think that if OPP support the use of multiple device drivers,
dev_pm_opp_enable() and dev_pm_opp_disable() should support the usage count
such as regulator/clock.

I would like your opinion.

Regards,
Chanwoo Choi


On 2018년 08월 07일 07:31, Chanwoo Choi wrote:
> Hi Matthias,
> 
> On 2018년 08월 07일 04:21, Matthias Kaehlcke wrote:
>> Hi Chanwoo,
>>
>> On Fri, Aug 03, 2018 at 09:14:46AM +0900, Chanwoo Choi wrote:
>>> Hi Matthias,
>>>
>>> On 2018년 08월 03일 08:48, Matthias Kaehlcke wrote:
 On Thu, Aug 02, 2018 at 04:13:43PM -0700, Matthias Kaehlcke wrote:
> Hi Chanwoo,
>
> On Thu, Aug 02, 2018 at 10:58:59AM +0900, Chanwoo Choi wrote:
>> Hi Matthias,
>>
>> On 2018년 08월 02일 02:08, Matthias Kaehlcke wrote:
>>> Hi Chanwoo,
>>>
>>> On Wed, Aug 01, 2018 at 10:22:16AM +0900, Chanwoo Choi wrote:
 On 2018년 08월 01일 04:39, Matthias Kaehlcke wrote:
> On Mon, Jul 16, 2018 at 10:50:50AM -0700, Matthias Kaehlcke wrote:
>> On Thu, Jul 12, 2018 at 05:44:33PM +0900, Chanwoo Choi wrote:
>>> Hi Matthias,
>>>
>>> On 2018년 07월 07일 02:53, Matthias Kaehlcke wrote:
 Hi Chanwoo,

 On Wed, Jul 04, 2018 at 03:41:46PM +0900, Chanwoo Choi wrote:

> Firstly,
> I'm not sure why devfreq needs the devfreq_verify_within_limits() 
> function.
>
> devfreq already used the OPP interface as default. It means that
> the outside of 'drivers/devfreq' can disable/enable the frequency
> such as drivers/thermal/devfreq_cooling.c. Also, when some device
> drivers disable/enable the specific frequency, the devfreq core
> consider them.
>
> So, devfreq doesn't need to devfreq_verify_within_limits() because
> already support some interface to change the minimum/maximum 
> frequency
> of devfreq device. 
>
> In case of cpufreq subsystem, cpufreq only provides 
> 'cpufreq_verify_with_limits()'
> to change the minimum/maximum frequency of cpu. some device 
> driver cannot
> change the minimum/maximum frequency through OPP interface.
>
> But, in case of devfreq subsystem, as I explained already, 
> devfreq support
> the OPP interface as default way. devfreq subsystem doesn't need 
> to add
> other way to change the minimum/maximum frequency.

 Using the OPP interface exclusively works as long as a
 enabling/disabling of OPPs is limited to a single driver
 (drivers/thermal/devfreq_cooling.c). When multiple drivers are
 involved you need a way to resolve conflicts, that's the purpose of
 devfreq_verify_within_limits(). Please let me know if there are
 existing mechanisms for conflict resolution that I overlooked.

 Possibly drivers/thermal/devfreq_cooling.c could be migrated to use
 devfreq_verify_within_limits() instead of the OPP interface if
 desired, however this seems beyond the scope of this series.
>>>
>>> Actually, if we uses this approach, it doesn't support the multiple 
>>> drivers too.
>>> If non throttler drivers uses devfreq_verify_within_limits(), the 
>>> conflict
>>> happen.
>>
>> As long as drivers limit the max freq there is no conflict, the 
>> lowest
>> max freq wins. I expect this to be the usual case, apparently it
>> worked for cpufreq for 10+ years.
>>
>> However it is correct that there would be a conflict if a driver
>> requests a min freq that is higher than the max freq requested by
>> another. In this case devfreq_verify_within_limits() resolves the
>> conflict by raising p->max to the min freq. Not sure if this is
>> something that would ever occur in practice though.
>>
>> If we are really concerned about this case it would also be an option
>> to limit the adjustment to the max frequency.
>>
>>> To resolve the conflict for multiple device driver, maybe OPP 
>>> interfac

Re: linux-next: Signed-off-by missing for commit in the risc-v tree

[Palmer Dabbelt]

On Sun, 05 Aug 2018 14:37:05 PDT (-0700), Stephen Rothwell wrote:

Hi Palmer,

Commit

  bce17edfe6af ("fixup: ".  " in PLIC docs")

is missing a Signed-off-by from its author and committer.


Oh, sorry about that.  It should be gone, it was just meant as a review 
comment.

Re: [PATCH 6/8] input: stpmu1: add stpmu1 onkey driver

[Dmitry Torokhov]

Hi Pascal,

On Thu, Jul 05, 2018 at 03:14:24PM +, Pascal PAILLET-LME wrote:
> From: pascal paillet 
> 
> The stpmu1 pmic is able to manage an onkey button. This driver exposes
> the stpmu1 onkey as an input device. It can also be configured to
> shut-down the power supplies on a long key-press with an adjustable
> duration.
> 
> Signed-off-by: pascal paillet 
> ---
>  drivers/input/misc/Kconfig|  11 ++
>  drivers/input/misc/Makefile   |   2 +
>  drivers/input/misc/stpmu1_onkey.c | 321 
> ++
>  3 files changed, 334 insertions(+)
>  create mode 100644 drivers/input/misc/stpmu1_onkey.c
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index c25606e..d020971 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -841,4 +841,15 @@ config INPUT_RAVE_SP_PWRBUTTON
> To compile this driver as a module, choose M here: the
> module will be called rave-sp-pwrbutton.
>  
> +config INPUT_STPMU1_ONKEY
> + tristate "STPMU1 PMIC Onkey support"
> + depends on MFD_STPMU1
> + help
> +   Say Y to enable support of onkey embedded into STPMU1 PMIC. onkey
> +   can be used to wakeup from low power modes and force a shut-down on
> +   long press.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called stpmu1_onkey.
> +
>  endif
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 72cde28..cc60dc1 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -70,6 +70,7 @@ obj-$(CONFIG_INPUT_SGI_BTNS)+= sgi_btns.o
>  obj-$(CONFIG_INPUT_SIRFSOC_ONKEY)+= sirfsoc-onkey.o
>  obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY) += soc_button_array.o
>  obj-$(CONFIG_INPUT_SPARCSPKR)+= sparcspkr.o
> +obj-$(CONFIG_INPUT_STPMU1_ONKEY) += stpmu1_onkey.o
>  obj-$(CONFIG_INPUT_TPS65218_PWRBUTTON)   += tps65218-pwrbutton.o
>  obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON)+= twl4030-pwrbutton.o
>  obj-$(CONFIG_INPUT_TWL4030_VIBRA)+= twl4030-vibra.o
> @@ -80,3 +81,4 @@ obj-$(CONFIG_INPUT_WM831X_ON)   += wm831x-on.o
>  obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)  += xen-kbdfront.o
>  obj-$(CONFIG_INPUT_YEALINK)  += yealink.o
>  obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
> +
> diff --git a/drivers/input/misc/stpmu1_onkey.c 
> b/drivers/input/misc/stpmu1_onkey.c
> new file mode 100644
> index 000..084a31f
> --- /dev/null
> +++ b/drivers/input/misc/stpmu1_onkey.c
> @@ -0,0 +1,321 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
> + * Author: Philippe Peurichard ,
> + * Pascal Paillet  for STMicroelectronics.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * struct stpmu1_onkey - OnKey data
> + * @pmic:pointer to STPMU1 PMIC device
> + * @input_dev:   pointer to input device
> + * @irq_falling: irq that we are hooked on to
> + * @irq_rising:  irq that we are hooked on to
> + */
> +struct stpmu1_onkey {
> + struct stpmu1_dev *pmic;
> + struct input_dev *input_dev;
> + int irq_falling;
> + int irq_rising;
> +};
> +
> +/**
> + * struct pmic_onkey_config - configuration of pmic PONKEYn
> + * @turnoff_enabled: value to enable turnoff condition
> + * @cc_flag_clear:   value to clear CC flag in case of PowerOff
> + * trigger by longkey press
> + * @onkey_pullup_val:value of PONKEY PullUp (active or 
> inactive)
> + * @long_press_time_val: value for long press h/w shutdown event
> + */
> +struct pmic_onkey_config {
> + bool turnoff_enabled;
> + bool cc_flag_clear;
> + u8 onkey_pullup_val;
> + u8 long_press_time_val;
> +};
> +
> +/**
> + * onkey_falling_irq() - button press isr
> + * @irq: irq
> + * @pmic_onkey:  onkey device
> + *
> + * Return: IRQ_HANDLED
> + */

This is internal driver functions, I do not see the need for kernel-doc
style comments (or any comments for this one to be honest).

> +static irqreturn_t onkey_falling_irq(int irq, void *ponkey)
> +{
> + struct stpmu1_onkey *onkey = ponkey;
> + struct input_dev *input_dev = onkey->input_dev;
> +
> + input_report_key(input_dev, KEY_POWER, 1);
> + pm_wakeup_event(input_dev->dev.parent, 0);
> + input_sync(input_dev);
> +
> + dev_dbg(&input_dev->dev, "Pwr Onkey Falling Interrupt received\n");
> +
> + return IRQ_HANDLED;
> +}
> +
> +/**
> + * onkey_rising_irq() - button released isr
> + * @irq: irq
> + * @pmic_onkey:  onkey device
> + *
> + * Return: IRQ_HANDLED
> + */
> +static irqreturn_t onkey_rising_irq(int irq, void *ponkey)
> +{
> + struct stpmu1_onkey *onkey = ponkey;
> + struct input_dev *input_dev = onkey->input_dev;
> +
> + input_report_key(input_dev, KEY_POWER, 0)

[PATCH] lib/vsprintf: Do not handle %pO[^F] as %px

[Bart Van Assche]

This patch avoids that gcc reports the following when building with W=1:

lib/vsprintf.c:1941:3: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   switch (fmt[1]) {
   ^~

Fixes: ce4fecf1fe15 ("vsprintf: Add %p extension "%pOF" for device tree")
Signed-off-by: Bart Van Assche 
Cc: Pantelis Antoniou 
Cc: Joe Perches 
Cc: Rob Herring 
---
 lib/vsprintf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index a48aaa79d352..cda186230287 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1942,6 +1942,7 @@ char *pointer(const char *fmt, char *buf, char *end, void 
*ptr,
case 'F':
return device_node_string(buf, end, ptr, spec, fmt + 1);
}
+   break;
case 'x':
return pointer_string(buf, end, ptr, spec);
}
-- 
2.18.0

Re: [PATCH v5 05/12] PM / devfreq: Add support for policy notifiers

[Chanwoo Choi]

Hi Matthias,

On 2018년 08월 07일 04:21, Matthias Kaehlcke wrote:
> Hi Chanwoo,
> 
> On Fri, Aug 03, 2018 at 09:14:46AM +0900, Chanwoo Choi wrote:
>> Hi Matthias,
>>
>> On 2018년 08월 03일 08:48, Matthias Kaehlcke wrote:
>>> On Thu, Aug 02, 2018 at 04:13:43PM -0700, Matthias Kaehlcke wrote:
 Hi Chanwoo,

 On Thu, Aug 02, 2018 at 10:58:59AM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> On 2018년 08월 02일 02:08, Matthias Kaehlcke wrote:
>> Hi Chanwoo,
>>
>> On Wed, Aug 01, 2018 at 10:22:16AM +0900, Chanwoo Choi wrote:
>>> On 2018년 08월 01일 04:39, Matthias Kaehlcke wrote:
 On Mon, Jul 16, 2018 at 10:50:50AM -0700, Matthias Kaehlcke wrote:
> On Thu, Jul 12, 2018 at 05:44:33PM +0900, Chanwoo Choi wrote:
>> Hi Matthias,
>>
>> On 2018년 07월 07일 02:53, Matthias Kaehlcke wrote:
>>> Hi Chanwoo,
>>>
>>> On Wed, Jul 04, 2018 at 03:41:46PM +0900, Chanwoo Choi wrote:
>>>
 Firstly,
 I'm not sure why devfreq needs the devfreq_verify_within_limits() 
 function.

 devfreq already used the OPP interface as default. It means that
 the outside of 'drivers/devfreq' can disable/enable the frequency
 such as drivers/thermal/devfreq_cooling.c. Also, when some device
 drivers disable/enable the specific frequency, the devfreq core
 consider them.

 So, devfreq doesn't need to devfreq_verify_within_limits() because
 already support some interface to change the minimum/maximum 
 frequency
 of devfreq device. 

 In case of cpufreq subsystem, cpufreq only provides 
 'cpufreq_verify_with_limits()'
 to change the minimum/maximum frequency of cpu. some device driver 
 cannot
 change the minimum/maximum frequency through OPP interface.

 But, in case of devfreq subsystem, as I explained already, devfreq 
 support
 the OPP interface as default way. devfreq subsystem doesn't need 
 to add
 other way to change the minimum/maximum frequency.
>>>
>>> Using the OPP interface exclusively works as long as a
>>> enabling/disabling of OPPs is limited to a single driver
>>> (drivers/thermal/devfreq_cooling.c). When multiple drivers are
>>> involved you need a way to resolve conflicts, that's the purpose of
>>> devfreq_verify_within_limits(). Please let me know if there are
>>> existing mechanisms for conflict resolution that I overlooked.
>>>
>>> Possibly drivers/thermal/devfreq_cooling.c could be migrated to use
>>> devfreq_verify_within_limits() instead of the OPP interface if
>>> desired, however this seems beyond the scope of this series.
>>
>> Actually, if we uses this approach, it doesn't support the multiple 
>> drivers too.
>> If non throttler drivers uses devfreq_verify_within_limits(), the 
>> conflict
>> happen.
>
> As long as drivers limit the max freq there is no conflict, the lowest
> max freq wins. I expect this to be the usual case, apparently it
> worked for cpufreq for 10+ years.
>
> However it is correct that there would be a conflict if a driver
> requests a min freq that is higher than the max freq requested by
> another. In this case devfreq_verify_within_limits() resolves the
> conflict by raising p->max to the min freq. Not sure if this is
> something that would ever occur in practice though.
>
> If we are really concerned about this case it would also be an option
> to limit the adjustment to the max frequency.
>
>> To resolve the conflict for multiple device driver, maybe OPP 
>> interface
>> have to support 'usage_count' such as clk_enable/disable().
>
> This would require supporting negative usage count values, since a OPP
> should not be enabled if e.g. thermal enables it but the throttler
> disabled it or viceversa.
>
> Theoretically there could also be conflicts, like one driver disabling
> the higher OPPs and another the lower ones, with the outcome of all
> OPPs being disabled, which would be a more drastic conflict resolution
> than that of devfreq_verify_within_limits().
>
> Viresh, what do you think about an OPP usage count?

 Ping, can we try to reach a conclusion on this or at least keep the
 discussion going?

 Not that it matters, but my preferred solution continues to be
 devfreq_verify_within_limits(). It solves conflicts in some way (which
 could be adjusted if needed) and has proven to work in

Re: [PATCH] Input: mark expected switch fall-throughs

[Dmitry Torokhov]

On Tue, Jul 03, 2018 at 03:35:44PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Warning level 2 was used: -Wimplicit-fallthrough=2
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied, thank you.

> ---
>  drivers/input/joystick/db9.c  | 5 +
>  drivers/input/keyboard/adp5589-keys.c | 1 +
>  drivers/input/mouse/appletouch.c  | 1 +
>  drivers/input/mouse/cyapa_gen5.c  | 1 +
>  drivers/input/mouse/cyapa_gen6.c  | 1 +
>  drivers/input/mouse/elantech.c| 2 +-
>  drivers/input/mouse/sermouse.c| 4 +++-
>  drivers/input/touchscreen/elo.c   | 1 +
>  8 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/joystick/db9.c b/drivers/input/joystick/db9.c
> index de0dd47..0006da5 100644
> --- a/drivers/input/joystick/db9.c
> +++ b/drivers/input/joystick/db9.c
> @@ -263,6 +263,7 @@ static unsigned char db9_saturn_read_packet(struct 
> parport *port, unsigned char
>   db9_saturn_write_sub(port, type, 3, powered, 0);
>   return data[0] = 0xe3;
>   }
> + /* else: fall through */
>   default:
>   return data[0];
>   }
> @@ -282,11 +283,14 @@ static int db9_saturn_report(unsigned char id, unsigned 
> char data[60], struct in
>   switch (data[j]) {
>   case 0x16: /* multi controller (analog 4 axis) */
>   input_report_abs(dev, db9_abs[5], data[j + 6]);
> + /* fall through */
>   case 0x15: /* mission stick (analog 3 axis) */
>   input_report_abs(dev, db9_abs[3], data[j + 4]);
>   input_report_abs(dev, db9_abs[4], data[j + 5]);
> + /* fall through */
>   case 0x13: /* racing controller (analog 1 axis) */
>   input_report_abs(dev, db9_abs[2], data[j + 3]);
> + /* fall through */
>   case 0x34: /* saturn keyboard (udlr ZXC ASD QE Esc) */
>   case 0x02: /* digital pad (digital 2 axis + buttons) */
>   input_report_abs(dev, db9_abs[0], !(data[j + 1] & 128) 
> - !(data[j + 1] & 64));
> @@ -380,6 +384,7 @@ static void db9_timer(struct timer_list *t)
>   input_report_abs(dev2, ABS_X, (data & DB9_RIGHT ? 0 : 
> 1) - (data & DB9_LEFT ? 0 : 1));
>   input_report_abs(dev2, ABS_Y, (data & DB9_DOWN  ? 0 : 
> 1) - (data & DB9_UP   ? 0 : 1));
>   input_report_key(dev2, BTN_TRIGGER, ~data & DB9_FIRE1);
> + /* fall through */
>  
>   case DB9_MULTI_0802:
>  
> diff --git a/drivers/input/keyboard/adp5589-keys.c 
> b/drivers/input/keyboard/adp5589-keys.c
> index 32d94c6..2835fba 100644
> --- a/drivers/input/keyboard/adp5589-keys.c
> +++ b/drivers/input/keyboard/adp5589-keys.c
> @@ -885,6 +885,7 @@ static int adp5589_probe(struct i2c_client *client,
>   switch (id->driver_data) {
>   case ADP5585_02:
>   kpad->support_row5 = true;
> + /* fall through */
>   case ADP5585_01:
>   kpad->is_adp5585 = true;
>   kpad->var = &const_adp5585;
> diff --git a/drivers/input/mouse/appletouch.c 
> b/drivers/input/mouse/appletouch.c
> index 032d279..0aeed28e8 100644
> --- a/drivers/input/mouse/appletouch.c
> +++ b/drivers/input/mouse/appletouch.c
> @@ -472,6 +472,7 @@ static int atp_status_check(struct urb *urb)
>   dev->info->datalen, dev->urb->actual_length);
>   dev->overflow_warned = true;
>   }
> + /* fall through */
>   case -ECONNRESET:
>   case -ENOENT:
>   case -ESHUTDOWN:
> diff --git a/drivers/input/mouse/cyapa_gen5.c 
> b/drivers/input/mouse/cyapa_gen5.c
> index 5775d40..14239fb 100644
> --- a/drivers/input/mouse/cyapa_gen5.c
> +++ b/drivers/input/mouse/cyapa_gen5.c
> @@ -2554,6 +2554,7 @@ static int cyapa_gen5_do_operational_check(struct cyapa 
> *cyapa)
>   }
>  
>   cyapa->state = CYAPA_STATE_GEN5_APP;
> + /* fall through */
>  
>   case CYAPA_STATE_GEN5_APP:
>   /*
> diff --git a/drivers/input/mouse/cyapa_gen6.c 
> b/drivers/input/mouse/cyapa_gen6.c
> index 0163978..c1b524a 100644
> --- a/drivers/input/mouse/cyapa_gen6.c
> +++ b/drivers/input/mouse/cyapa_gen6.c
> @@ -680,6 +680,7 @@ static int cyapa_gen6_operational_check(struct cyapa 
> *cyapa)
>   }
>  
>   cyapa->state = CYAPA_STATE_GEN6_APP;
> + /* fall through */
>  
>   case CYAPA_STATE_GEN6_APP:
>   /*
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index dd85b16..44f57cf 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -340,7 +340,7 @@ static void elantech_report_absolute_v2(struct psmouse 
> *psmouse)
>

[RFC PATCH v2 04/12] mtd: rawnand: ams-delta: request data port GPIO resource

[Janusz Krzysztofik]

Data port used by the driver is actually an OMAP MPUIO device, already
under control of gpio-omap driver.  For that reason we used to not
request the memory region of the port as that would fail because the
region is already busy.  Despite that, we are still accessing the port
by just ioremapping it and performing read/write operations.  Moreover,
we are doing that without any proteciton from other users legally
manipulating the port pins over GPIO API.

The plan is to convert the driver to access the port over functions
exposed by the gpio-omap driver.  Before that happens, already prevent
from other users accessing the port pins by requesting an array of its
GPIO descriptors.

Signed-off-by: Janusz Krzysztofik 
---
 drivers/mtd/nand/raw/ams-delta.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c
index 48233d638d2a..09d6901fc94d 100644
--- a/drivers/mtd/nand/raw/ams-delta.c
+++ b/drivers/mtd/nand/raw/ams-delta.c
@@ -161,6 +161,7 @@ static int ams_delta_init(struct platform_device *pdev)
struct mtd_info *mtd;
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
void __iomem *io_base;
+   struct gpio_descs *data_gpiods;
int err = 0;
 
if (!res)
@@ -261,6 +262,13 @@ static int ams_delta_init(struct platform_device *pdev)
dev_err(&pdev->dev, "CLE GPIO request failed (%d)\n", err);
goto out_mtd;
}
+   /* Request array of data pins, initialize them as input */
+   data_gpiods = devm_gpiod_get_array(&pdev->dev, "data", GPIOD_IN);
+   if (IS_ERR(data_gpiods)) {
+   err = PTR_ERR(data_gpiods);
+   dev_err(&pdev->dev, "data GPIO request failed: %d\n", err);
+   goto out_mtd;
+   }
 
/* Scan to find existence of the device */
err = nand_scan(mtd, 1);
-- 
2.16.4

Re: [PATCH] perf/x86/intel: Fix unwind errors from PEBS entries (mk-II)

[Peter Zijlstra]

On Mon, Aug 06, 2018 at 02:28:18PM -0700, Fubo Chen wrote:
> Do you think the patch below is sufficient to suppress the sparse warning?

Why would I want to make the code ugly to supress it?

[PATCH] perf arm64: Fix include path for asm-generic/unistd.h

[Kim Phillips]

The new syscall table support for arm64 mistakenly used the system's
asm-generic/unistd.h file when processing the
tools/arch/arm64/include/uapi/asm/unistd.h file's include directive:

#include 

See "Committer notes" section of commit 2b5882435606 "perf arm64:
Generate system call table from asm/unistd.h" for more details.

This patch removes the committer's temporary workaround, and instructs
the host compiler to search the build tree's include path for the right
copy of the unistd.h file, instead of the one on the system's
/usr/include path.

It thus fixes the committer's test that cross-builds an arm64 perf
on an x86 platform running Ubuntu 14.04.5 LTS with an old toolchain:

$ tools/perf/arch/arm64/entry/syscalls/mksyscalltbl 
/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc 
gcc `pwd`/tools tools/arch/arm64/include/uapi/asm/unistd.h | grep bpf
[280] = "bpf",

Cc: Hendrik Brueckner 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Michael Ellerman 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Ravi Bangoria 
Cc: Thomas Richter 
Fixes: 2b5882435606 ("perf arm64: Generate system call table from asm/unistd.h")
Signed-off-by: Kim Phillips 
---
Hi, sorry for late response - was on vacation.  I was able to reproduce
and fix by adding this -I to the $hostcc line.  Please test, and let me
know if this is an acceptable fix.

 tools/perf/arch/arm64/Makefile| 5 +++--
 tools/perf/arch/arm64/entry/syscalls/mksyscalltbl | 6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index f013b115dc86..dbef716a1913 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -11,7 +11,8 @@ PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
 
 out:= $(OUTPUT)arch/arm64/include/generated/asm
 header := $(out)/syscalls.c
-sysdef := $(srctree)/tools/include/uapi/asm-generic/unistd.h
+incpath := $(srctree)/tools
+sysdef := $(srctree)/tools/arch/arm64/include/uapi/asm/unistd.h
 sysprf := $(srctree)/tools/perf/arch/arm64/entry/syscalls/
 systbl := $(sysprf)/mksyscalltbl
 
@@ -19,7 +20,7 @@ systbl := $(sysprf)/mksyscalltbl
 _dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)')
 
 $(header): $(sysdef) $(systbl)
-   $(Q)$(SHELL) '$(systbl)' '$(CC)' '$(HOSTCC)' $(sysdef) > $@
+   $(Q)$(SHELL) '$(systbl)' '$(CC)' '$(HOSTCC)' $(incpath) $(sysdef) > $@
 
 clean::
$(call QUIET_CLEAN, arm64) $(RM) $(header)
diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl 
b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
index 52e197317d3e..2dbb8cade048 100755
--- a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
+++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
@@ -11,7 +11,8 @@
 
 gcc=$1
 hostcc=$2
-input=$3
+incpath=$3
+input=$4
 
 if ! test -r $input; then
echo "Could not read input file" >&2
@@ -28,7 +29,6 @@ create_table_from_c()
 
cat <<-_EoHEADER
#include 
-   #define __ARCH_WANT_RENAMEAT
#include "$input"
int main(int argc, char *argv[])
{
@@ -42,7 +42,7 @@ create_table_from_c()
printf "%s\n" " printf(\"#define SYSCALLTBL_ARM64_MAX_ID %d\\n\", 
__NR_$last_sc);"
printf "}\n"
 
-   } | $hostcc -o $create_table_exe -x c -
+   } | $hostcc -I $incpath/include/uapi -o $create_table_exe -x c -
 
$create_table_exe
 
-- 
2.17.1