Re: [PATCH 1/3] driver: mailbox: add support for Hi3660

[Leo Yan]

Hi Jassi,

On Sat, Sep 02, 2017 at 01:07:50PM +0530, Jassi Brar wrote:

[...]

> > +#define MBOX_CHAN_MAX  32
> > +
> > +#define MBOX_TX0x1
> > +
> > +/* Mailbox message length: 2 words */
> > +#define MBOX_MSG_LEN   2
> > +
> > +#define MBOX_OFF(m)(0x40 * (m))
> > +#define MBOX_SRC_REG(m)MBOX_OFF(m)
> > +#define MBOX_DST_REG(m)(MBOX_OFF(m) + 0x04)
> > +#define MBOX_DCLR_REG(m)   (MBOX_OFF(m) + 0x08)
> > +#define MBOX_DSTAT_REG(m)  (MBOX_OFF(m) + 0x0C)
> > +#define MBOX_MODE_REG(m)   (MBOX_OFF(m) + 0x10)
> > +#define MBOX_IMASK_REG(m)  (MBOX_OFF(m) + 0x14)
> > +#define MBOX_ICLR_REG(m)   (MBOX_OFF(m) + 0x18)
> > +#define MBOX_SEND_REG(m)   (MBOX_OFF(m) + 0x1C)
> > +#define MBOX_DATA_REG(m, i)(MBOX_OFF(m) + 0x20 + ((i) << 2))
> > +
> > +#define MBOX_CPU_IMASK(cpu)(((cpu) << 3) + 0x800)
> > +#define MBOX_CPU_IRST(cpu) (((cpu) << 3) + 0x804)
> > +#define MBOX_IPC_LOCK  (0xA00)
> > +
>
> How is this controller different than the PL320?

Sorry for the late replying, I am starting to work on this patch set.

I compared Hi3660 mailbox hardware design with PL320 IPC driver
drivers/mailbox/pl320-ipc.c, below are summary for the difference
between them:

- The register offset is similiar, PL320 IPC driver has one more
  register IPCMxMSTATUS but Hi3660 doesn't have it;

- Hi3660 introduces the ipc lock with offset 0xA00 but PL320 doesn't
  have it;

- They have some conflicts for mailbox channel usage:

  Hi3660 introduces two extra operations:
  Unlocking (so have permission to access the channel)
  Occupying (so can exclusivly access the channel)

  Hi3660 introduces "MBOX_AUTO_ACK" mode, with this mode the kernel
  doesn't wait for acknowledge from remote and directly return back;
  as the first version for this patch I am planning to support this
  mode for CPU clock.

- PL320 registers have different semantics and usage with Hi3660's:

  PL320 register IPCMxMODE (offset 0x10) and Hi3660 register
  MBOX_MODE_REG (offset 0x10) have different semantics; PL320 doesn't
  use IPCMxMODE, but Hi3660 uses MBOX_MODE_REG to set the channel
  working mode (e.g. set "MBOX_AUTO_ACK" mode).

  PL320 register IPCMxMSET (offset 0x14) and Hi3660 register
  MBOX_IMASK_REG (offset 0x14) have different semantics; PL320
  IPCMxMSET is used to set the channel's source and destination,
  Hi3660 MBOX_IMASK_REG is used to mask interrupts for source and
  destination and only clear bit for which master need receive
  interrupt.

Though Hi3660 register definition is close to PL320 driver, but it's
seems hard to combine Hi3660 mailbox driver into PL320 driver
according to the register usage and flow. So I prefer to write one
dedicated Hi3660 mailbox driver.

Jassi, how about you think for this?

Thanks,
Leo Yan

Re: [PATCH 1/3] driver: mailbox: add support for Hi3660

[Leo Yan]

Hi Jassi,

On Sat, Sep 02, 2017 at 01:07:50PM +0530, Jassi Brar wrote:

[...]

> > +#define MBOX_CHAN_MAX  32
> > +
> > +#define MBOX_TX0x1
> > +
> > +/* Mailbox message length: 2 words */
> > +#define MBOX_MSG_LEN   2
> > +
> > +#define MBOX_OFF(m)(0x40 * (m))
> > +#define MBOX_SRC_REG(m)MBOX_OFF(m)
> > +#define MBOX_DST_REG(m)(MBOX_OFF(m) + 0x04)
> > +#define MBOX_DCLR_REG(m)   (MBOX_OFF(m) + 0x08)
> > +#define MBOX_DSTAT_REG(m)  (MBOX_OFF(m) + 0x0C)
> > +#define MBOX_MODE_REG(m)   (MBOX_OFF(m) + 0x10)
> > +#define MBOX_IMASK_REG(m)  (MBOX_OFF(m) + 0x14)
> > +#define MBOX_ICLR_REG(m)   (MBOX_OFF(m) + 0x18)
> > +#define MBOX_SEND_REG(m)   (MBOX_OFF(m) + 0x1C)
> > +#define MBOX_DATA_REG(m, i)(MBOX_OFF(m) + 0x20 + ((i) << 2))
> > +
> > +#define MBOX_CPU_IMASK(cpu)(((cpu) << 3) + 0x800)
> > +#define MBOX_CPU_IRST(cpu) (((cpu) << 3) + 0x804)
> > +#define MBOX_IPC_LOCK  (0xA00)
> > +
>
> How is this controller different than the PL320?

Sorry for the late replying, I am starting to work on this patch set.

I compared Hi3660 mailbox hardware design with PL320 IPC driver
drivers/mailbox/pl320-ipc.c, below are summary for the difference
between them:

- The register offset is similiar, PL320 IPC driver has one more
  register IPCMxMSTATUS but Hi3660 doesn't have it;

- Hi3660 introduces the ipc lock with offset 0xA00 but PL320 doesn't
  have it;

- They have some conflicts for mailbox channel usage:

  Hi3660 introduces two extra operations:
  Unlocking (so have permission to access the channel)
  Occupying (so can exclusivly access the channel)

  Hi3660 introduces "MBOX_AUTO_ACK" mode, with this mode the kernel
  doesn't wait for acknowledge from remote and directly return back;
  as the first version for this patch I am planning to support this
  mode for CPU clock.

- PL320 registers have different semantics and usage with Hi3660's:

  PL320 register IPCMxMODE (offset 0x10) and Hi3660 register
  MBOX_MODE_REG (offset 0x10) have different semantics; PL320 doesn't
  use IPCMxMODE, but Hi3660 uses MBOX_MODE_REG to set the channel
  working mode (e.g. set "MBOX_AUTO_ACK" mode).

  PL320 register IPCMxMSET (offset 0x14) and Hi3660 register
  MBOX_IMASK_REG (offset 0x14) have different semantics; PL320
  IPCMxMSET is used to set the channel's source and destination,
  Hi3660 MBOX_IMASK_REG is used to mask interrupts for source and
  destination and only clear bit for which master need receive
  interrupt.

Though Hi3660 register definition is close to PL320 driver, but it's
seems hard to combine Hi3660 mailbox driver into PL320 driver
according to the register usage and flow. So I prefer to write one
dedicated Hi3660 mailbox driver.

Jassi, how about you think for this?

Thanks,
Leo Yan

[PATCH V3] selftests/vm: Add tests validating mremap mirror functionality

[Anshuman Khandual]

This adds two tests to validate mirror functionality with mremap()
system call on shared and private anon mappings. After the commit
dba58d3b8c5 ("mm/mremap: fail map duplication attempts for private
mappings"), any attempt to mirror private anon mapping will fail.

Suggested-by: Mike Kravetz 
Signed-off-by: Anshuman Khandual 
---

Changes in V3:

- Fail any attempts to mirror an existing anon private mapping
- Updated run_vmtests to include these new mremap tests
- Updated the commit message

Changes in V2: (https://patchwork.kernel.org/patch/9861259/)

- Added a test for private anon mappings
- Used sysconf(_SC_PAGESIZE) instead of hard coding page size
- Used MREMAP_MAYMOVE instead of hard coding the flag value 1

Original V1: (https://patchwork.kernel.org/patch/9854415/)

 tools/testing/selftests/vm/Makefile|  2 +
 .../selftests/vm/mremap_mirror_private_anon.c  | 41 +++
 .../selftests/vm/mremap_mirror_shared_anon.c   | 58 ++
 tools/testing/selftests/vm/run_vmtests | 22 
 4 files changed, 123 insertions(+)
 create mode 100644 tools/testing/selftests/vm/mremap_mirror_private_anon.c
 create mode 100644 tools/testing/selftests/vm/mremap_mirror_shared_anon.c

diff --git a/tools/testing/selftests/vm/Makefile 
b/tools/testing/selftests/vm/Makefile
index cbb29e4..6401f91 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -17,6 +17,8 @@ TEST_GEN_FILES += transhuge-stress
 TEST_GEN_FILES += userfaultfd
 TEST_GEN_FILES += mlock-random-test
 TEST_GEN_FILES += virtual_address_range
+TEST_GEN_FILES += mremap_mirror_shared_anon
+TEST_GEN_FILES += mremap_mirror_private_anon
 
 TEST_PROGS := run_vmtests
 
diff --git a/tools/testing/selftests/vm/mremap_mirror_private_anon.c 
b/tools/testing/selftests/vm/mremap_mirror_private_anon.c
new file mode 100644
index 000..e4fa85b
--- /dev/null
+++ b/tools/testing/selftests/vm/mremap_mirror_private_anon.c
@@ -0,0 +1,41 @@
+/*
+ * Test to verify mirror functionality with mremap() system
+ * call for private anon mappings. Any attempt to create a
+ * mirror mapping for an anon private one should fail.
+ *
+ * Copyright (C) 2017 Anshuman Khandual, IBM Corporation
+ *
+ * Licensed under GPL V2
+ */
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PATTERN0xbe
+#define NR_PAGES   10
+
+int main(int argc, char *argv[])
+{
+   unsigned long alloc_size;
+   char *ptr, *mirror_ptr;
+
+   alloc_size = sysconf(_SC_PAGESIZE) * NR_PAGES;
+   ptr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+   if (ptr == MAP_FAILED) {
+   perror("map() failed");
+   return -1;
+   }
+   memset(ptr, PATTERN, alloc_size);
+
+   mirror_ptr =  (char *) mremap(ptr, 0, alloc_size, MREMAP_MAYMOVE);
+   if (mirror_ptr == MAP_FAILED)
+   return 0;
+
+   printf("Mirror attempt on private anon mapping should have failed\n");
+   return 1;
+}
diff --git a/tools/testing/selftests/vm/mremap_mirror_shared_anon.c 
b/tools/testing/selftests/vm/mremap_mirror_shared_anon.c
new file mode 100644
index 000..1d5c838
--- /dev/null
+++ b/tools/testing/selftests/vm/mremap_mirror_shared_anon.c
@@ -0,0 +1,58 @@
+/*
+ * Test to verify mirror functionality with mremap() system
+ * call for shared anon mappings. The 'mirrored' buffer will
+ * match element to element with that of the original one.
+ *
+ * Copyright (C) 2017 Anshuman Khandual, IBM Corporation
+ *
+ * Licensed under GPL V2
+ */
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PATTERN0xbe
+#define NR_PAGES   10
+
+int test_mirror(char *old, char *new, unsigned long size)
+{
+   unsigned long i;
+
+   for (i = 0; i < size; i++) {
+   if (new[i] != old[i]) {
+   printf("Mismatch at new[%lu] expected \
+   %d received %d\n", i, old[i], new[i]);
+   return 1;
+   }
+   }
+   return 0;
+}
+
+int main(int argc, char *argv[])
+{
+   unsigned long alloc_size;
+   char *ptr, *mirror_ptr;
+
+   alloc_size = sysconf(_SC_PAGESIZE) * NR_PAGES;
+   ptr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
+   MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+   if (ptr == MAP_FAILED) {
+   perror("map() failed");
+   return -1;
+   }
+   memset(ptr, PATTERN, alloc_size);
+
+   mirror_ptr =  (char *) mremap(ptr, 0, alloc_size, MREMAP_MAYMOVE);
+   if (mirror_ptr == MAP_FAILED) {
+   perror("mremap() failed");
+   return -1;
+   }
+
+   if (test_mirror(ptr, mirror_ptr, alloc_size))
+   return 1;
+   return 0;
+}
diff --git 

[PATCH V3] selftests/vm: Add tests validating mremap mirror functionality

[Anshuman Khandual]

This adds two tests to validate mirror functionality with mremap()
system call on shared and private anon mappings. After the commit
dba58d3b8c5 ("mm/mremap: fail map duplication attempts for private
mappings"), any attempt to mirror private anon mapping will fail.

Suggested-by: Mike Kravetz 
Signed-off-by: Anshuman Khandual 
---

Changes in V3:

- Fail any attempts to mirror an existing anon private mapping
- Updated run_vmtests to include these new mremap tests
- Updated the commit message

Changes in V2: (https://patchwork.kernel.org/patch/9861259/)

- Added a test for private anon mappings
- Used sysconf(_SC_PAGESIZE) instead of hard coding page size
- Used MREMAP_MAYMOVE instead of hard coding the flag value 1

Original V1: (https://patchwork.kernel.org/patch/9854415/)

 tools/testing/selftests/vm/Makefile|  2 +
 .../selftests/vm/mremap_mirror_private_anon.c  | 41 +++
 .../selftests/vm/mremap_mirror_shared_anon.c   | 58 ++
 tools/testing/selftests/vm/run_vmtests | 22 
 4 files changed, 123 insertions(+)
 create mode 100644 tools/testing/selftests/vm/mremap_mirror_private_anon.c
 create mode 100644 tools/testing/selftests/vm/mremap_mirror_shared_anon.c

diff --git a/tools/testing/selftests/vm/Makefile 
b/tools/testing/selftests/vm/Makefile
index cbb29e4..6401f91 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -17,6 +17,8 @@ TEST_GEN_FILES += transhuge-stress
 TEST_GEN_FILES += userfaultfd
 TEST_GEN_FILES += mlock-random-test
 TEST_GEN_FILES += virtual_address_range
+TEST_GEN_FILES += mremap_mirror_shared_anon
+TEST_GEN_FILES += mremap_mirror_private_anon
 
 TEST_PROGS := run_vmtests
 
diff --git a/tools/testing/selftests/vm/mremap_mirror_private_anon.c 
b/tools/testing/selftests/vm/mremap_mirror_private_anon.c
new file mode 100644
index 000..e4fa85b
--- /dev/null
+++ b/tools/testing/selftests/vm/mremap_mirror_private_anon.c
@@ -0,0 +1,41 @@
+/*
+ * Test to verify mirror functionality with mremap() system
+ * call for private anon mappings. Any attempt to create a
+ * mirror mapping for an anon private one should fail.
+ *
+ * Copyright (C) 2017 Anshuman Khandual, IBM Corporation
+ *
+ * Licensed under GPL V2
+ */
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PATTERN0xbe
+#define NR_PAGES   10
+
+int main(int argc, char *argv[])
+{
+   unsigned long alloc_size;
+   char *ptr, *mirror_ptr;
+
+   alloc_size = sysconf(_SC_PAGESIZE) * NR_PAGES;
+   ptr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+   if (ptr == MAP_FAILED) {
+   perror("map() failed");
+   return -1;
+   }
+   memset(ptr, PATTERN, alloc_size);
+
+   mirror_ptr =  (char *) mremap(ptr, 0, alloc_size, MREMAP_MAYMOVE);
+   if (mirror_ptr == MAP_FAILED)
+   return 0;
+
+   printf("Mirror attempt on private anon mapping should have failed\n");
+   return 1;
+}
diff --git a/tools/testing/selftests/vm/mremap_mirror_shared_anon.c 
b/tools/testing/selftests/vm/mremap_mirror_shared_anon.c
new file mode 100644
index 000..1d5c838
--- /dev/null
+++ b/tools/testing/selftests/vm/mremap_mirror_shared_anon.c
@@ -0,0 +1,58 @@
+/*
+ * Test to verify mirror functionality with mremap() system
+ * call for shared anon mappings. The 'mirrored' buffer will
+ * match element to element with that of the original one.
+ *
+ * Copyright (C) 2017 Anshuman Khandual, IBM Corporation
+ *
+ * Licensed under GPL V2
+ */
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PATTERN0xbe
+#define NR_PAGES   10
+
+int test_mirror(char *old, char *new, unsigned long size)
+{
+   unsigned long i;
+
+   for (i = 0; i < size; i++) {
+   if (new[i] != old[i]) {
+   printf("Mismatch at new[%lu] expected \
+   %d received %d\n", i, old[i], new[i]);
+   return 1;
+   }
+   }
+   return 0;
+}
+
+int main(int argc, char *argv[])
+{
+   unsigned long alloc_size;
+   char *ptr, *mirror_ptr;
+
+   alloc_size = sysconf(_SC_PAGESIZE) * NR_PAGES;
+   ptr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
+   MAP_SHARED | MAP_ANONYMOUS, -1, 0);
+   if (ptr == MAP_FAILED) {
+   perror("map() failed");
+   return -1;
+   }
+   memset(ptr, PATTERN, alloc_size);
+
+   mirror_ptr =  (char *) mremap(ptr, 0, alloc_size, MREMAP_MAYMOVE);
+   if (mirror_ptr == MAP_FAILED) {
+   perror("mremap() failed");
+   return -1;
+   }
+
+   if (test_mirror(ptr, mirror_ptr, alloc_size))
+   return 1;
+   return 0;
+}
diff --git a/tools/testing/selftests/vm/run_vmtests 

[PATCH] driver core: Make sure device detached from driver before deleting it

[Jeffy Chen]

There are cases we call device_del() without detaching it from the
driver(e.g. spi core del children devices).

Signed-off-by: Jeffy Chen 
---

 drivers/base/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 12ebd055724c..717efc3020af 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1951,6 +1951,8 @@ void device_del(struct device *dev)
struct kobject *glue_dir = NULL;
struct class_interface *class_intf;
 
+   device_release_driver(dev);
+
/* Notify clients of device removal.  This call must come
 * before dpm_sysfs_remove().
 */
-- 
2.11.0

[PATCH] driver core: Make sure device detached from driver before deleting it

[Jeffy Chen]

There are cases we call device_del() without detaching it from the
driver(e.g. spi core del children devices).

Signed-off-by: Jeffy Chen 
---

 drivers/base/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 12ebd055724c..717efc3020af 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1951,6 +1951,8 @@ void device_del(struct device *dev)
struct kobject *glue_dir = NULL;
struct class_interface *class_intf;
 
+   device_release_driver(dev);
+
/* Notify clients of device removal.  This call must come
 * before dpm_sysfs_remove().
 */
-- 
2.11.0

Re: [PATCH v4 pci 0/2] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

[Khuong Dinh]

Hi Lorenzo,

On Tue, Oct 17, 2017 at 6:38 AM, Lorenzo Pieralisi
 wrote:
> Hi Khuong,
>
> On Mon, Oct 16, 2017 at 02:19:50PM -0700, Khuong Dinh wrote:
>> Hi Lorenzo,
>>   Do you have any comments for this patch?
>
> I'd have some comments but given that there are related issues with ACPI
> probe ordering that Marc is trying to solve on his side - I will work
> with him to see if we can accommodate changes that can solve this issue
> too.
>
> Again - I recognize it is a complex problem (that is not even
> contemplated by the current ACPI specs), we have to try to make
> the solution as generic as we can to prevent reinventing the wheel
> anytime a sligthly different issue (related to ACPI probe ordering)
> comes up.
>
> Leave it to me (us) and I will get back to you on this.

Thanks for helping to take care of the generic ACPI probe ordering issue.
Given that the patch 'PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI
boot for X-Gene v1" adds only the ACPI ID, can you pull in this patch
independently from the ACPI probe ordering issue?

Best regards,
Khuong Dinh

> Thanks,
> Lorenzo
>
>> Best regards,
>> Khuong Dinh
>>
>> On Tue, Sep 26, 2017 at 10:49 AM, Khuong Dinh  wrote:
>> > This patch set enables ACPI MSI support for X-Gene PCIe v1 hardware
>> > and provides the proper MSI driver initialization ordering.
>> >
>> > Signed-off-by: Khuong Dinh 
>> > ---
>> > v4:
>> >  - Remove Marc Zyngier ACK in v2
>> >  - Use acpi_bus_scan on MSI controller handle when MSI device is found
>> >  - Register ACPI MSI driver when MSI device is found instead of using
>> >  subsys_initcall
>> >  - Split ACPI MSI driver support into two patches - one to enable MSI
>> > support for X-Gene PCIe v1 hardware, one to enforce MSI driver loaded
>> > before PCIe controller driver in ACPI boot mode
>> > v3:
>> >  - Input X-Gene MSI base address for irq_domain_alloc_fwnode
>> >  - Add a hook to enforce X-Gene MSI be probed prior acpi_bus_scan happens
>> > v2:
>> >  - Verify with BIOS version 3.06.25 and 3.07.09
>> > v1:
>> >  - Initial version
>> > ---
>> >
>> > Khuong Dinh (2):
>> >   PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1
>> >   PCI/MSI: Enforce MSI driver loaded before PCIe in ACPI boot
>> >
>> >  drivers/acpi/Makefile|2 +-
>> >  drivers/acpi/acpi_msi.c  |   86 
>> > ++
>> >  drivers/acpi/acpi_platform.c |3 +-
>> >  drivers/acpi/internal.h  |1 +
>> >  drivers/acpi/scan.c  |1 +
>> >  drivers/pci/host/pci-xgene-msi.c |   60 --
>> >  include/linux/acpi_msi.h |   37 
>> >  7 files changed, 183 insertions(+), 7 deletions(-)
>> >  create mode 100644 drivers/acpi/acpi_msi.c
>> >  create mode 100644 include/linux/acpi_msi.h
>> >

Re: [PATCH v4 pci 0/2] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

[Khuong Dinh]

Hi Lorenzo,

On Tue, Oct 17, 2017 at 6:38 AM, Lorenzo Pieralisi
 wrote:
> Hi Khuong,
>
> On Mon, Oct 16, 2017 at 02:19:50PM -0700, Khuong Dinh wrote:
>> Hi Lorenzo,
>>   Do you have any comments for this patch?
>
> I'd have some comments but given that there are related issues with ACPI
> probe ordering that Marc is trying to solve on his side - I will work
> with him to see if we can accommodate changes that can solve this issue
> too.
>
> Again - I recognize it is a complex problem (that is not even
> contemplated by the current ACPI specs), we have to try to make
> the solution as generic as we can to prevent reinventing the wheel
> anytime a sligthly different issue (related to ACPI probe ordering)
> comes up.
>
> Leave it to me (us) and I will get back to you on this.

Thanks for helping to take care of the generic ACPI probe ordering issue.
Given that the patch 'PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI
boot for X-Gene v1" adds only the ACPI ID, can you pull in this patch
independently from the ACPI probe ordering issue?

Best regards,
Khuong Dinh

> Thanks,
> Lorenzo
>
>> Best regards,
>> Khuong Dinh
>>
>> On Tue, Sep 26, 2017 at 10:49 AM, Khuong Dinh  wrote:
>> > This patch set enables ACPI MSI support for X-Gene PCIe v1 hardware
>> > and provides the proper MSI driver initialization ordering.
>> >
>> > Signed-off-by: Khuong Dinh 
>> > ---
>> > v4:
>> >  - Remove Marc Zyngier ACK in v2
>> >  - Use acpi_bus_scan on MSI controller handle when MSI device is found
>> >  - Register ACPI MSI driver when MSI device is found instead of using
>> >  subsys_initcall
>> >  - Split ACPI MSI driver support into two patches - one to enable MSI
>> > support for X-Gene PCIe v1 hardware, one to enforce MSI driver loaded
>> > before PCIe controller driver in ACPI boot mode
>> > v3:
>> >  - Input X-Gene MSI base address for irq_domain_alloc_fwnode
>> >  - Add a hook to enforce X-Gene MSI be probed prior acpi_bus_scan happens
>> > v2:
>> >  - Verify with BIOS version 3.06.25 and 3.07.09
>> > v1:
>> >  - Initial version
>> > ---
>> >
>> > Khuong Dinh (2):
>> >   PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1
>> >   PCI/MSI: Enforce MSI driver loaded before PCIe in ACPI boot
>> >
>> >  drivers/acpi/Makefile|2 +-
>> >  drivers/acpi/acpi_msi.c  |   86 
>> > ++
>> >  drivers/acpi/acpi_platform.c |3 +-
>> >  drivers/acpi/internal.h  |1 +
>> >  drivers/acpi/scan.c  |1 +
>> >  drivers/pci/host/pci-xgene-msi.c |   60 --
>> >  include/linux/acpi_msi.h |   37 
>> >  7 files changed, 183 insertions(+), 7 deletions(-)
>> >  create mode 100644 drivers/acpi/acpi_msi.c
>> >  create mode 100644 include/linux/acpi_msi.h
>> >

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

[Michael Ellerman]

Mathieu Desnoyers  writes:

> - On Oct 17, 2017, at 6:36 AM, Michael Ellerman m...@ellerman.id.au wrote:
>
>> Mathieu Desnoyers  writes:
>> 
>>> Hi Michael,
>>>
>>> With your changes integrated, both rseq and cpu-opv selftests fail to
>>> build if I pass e.g. -j32 to make.
>>>
>>> cd tools/testing/selftests/cpu-opv
>>>
>>> efficios@compudjdev:~/git/linux-percpu-dev/tools/testing/selftests/cpu-opv$ 
>>> make
>>> clean; make
>>> rm -f -r
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test
>>> gcc -O2 -Wall -g -I./ -I../../../../usr/include/basic_cpu_opv_test.c
>>> cpu-op.c cpu-op.h   -o basic_cpu_opv_test
>>>
>>> efficios@compudjdev:~/git/linux-percpu-dev/tools/testing/selftests/cpu-opv$ 
>>> make
>>> clean; make -j32
>>> rm -f -r
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test
>>> gcc -O2 -Wall -g -I./ -I../../../../usr/include/basic_cpu_opv_test.c
>>> cpu-op.c cpu-op.h   -o basic_cpu_opv_test
>>> gcc -O2 -Wall -g -I./ -I../../../../usr/include/basic_cpu_opv_test.c  -o
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test
>>> /tmp/ccDthnqM.o: In function `test_memcpy_op':
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test.c:364:
>>> undefined reference to `cpu_op_get_current_cpu'
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test.c:365:
>>> undefined reference to `cpu_opv'
>> ...
>>> make: ***
>>> [/home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test]
>>> Error 1
>>> make: *** Waiting for unfinished jobs
>>>
>>> Any idea what is going on here ?
>> 
>> Ugh sorry, yes.
>> 
>> New patch below should fix it. Tested with -j:
>
> Perfect, folding it into my series.

Thanks.

> I see that the "all" target was redundant here.

Yeah.

Unfortunately lib.mk has grown a bit more complicated than I would like,
including defining the all target.

It does make for nice short Makefiles for individual test directories,
but it's not all that easy to use if you're not familiar with it [or
even if you are, as I demostrated here :)]

cheers

Re: [RFC PATCH for 4.15 14/14] Restartable sequences: Provide self-tests

[Michael Ellerman]

Mathieu Desnoyers  writes:

> - On Oct 17, 2017, at 6:36 AM, Michael Ellerman m...@ellerman.id.au wrote:
>
>> Mathieu Desnoyers  writes:
>> 
>>> Hi Michael,
>>>
>>> With your changes integrated, both rseq and cpu-opv selftests fail to
>>> build if I pass e.g. -j32 to make.
>>>
>>> cd tools/testing/selftests/cpu-opv
>>>
>>> efficios@compudjdev:~/git/linux-percpu-dev/tools/testing/selftests/cpu-opv$ 
>>> make
>>> clean; make
>>> rm -f -r
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test
>>> gcc -O2 -Wall -g -I./ -I../../../../usr/include/basic_cpu_opv_test.c
>>> cpu-op.c cpu-op.h   -o basic_cpu_opv_test
>>>
>>> efficios@compudjdev:~/git/linux-percpu-dev/tools/testing/selftests/cpu-opv$ 
>>> make
>>> clean; make -j32
>>> rm -f -r
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test
>>> gcc -O2 -Wall -g -I./ -I../../../../usr/include/basic_cpu_opv_test.c
>>> cpu-op.c cpu-op.h   -o basic_cpu_opv_test
>>> gcc -O2 -Wall -g -I./ -I../../../../usr/include/basic_cpu_opv_test.c  -o
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test
>>> /tmp/ccDthnqM.o: In function `test_memcpy_op':
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test.c:364:
>>> undefined reference to `cpu_op_get_current_cpu'
>>> /home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test.c:365:
>>> undefined reference to `cpu_opv'
>> ...
>>> make: ***
>>> [/home/efficios/git/linux-percpu-dev/tools/testing/selftests/cpu-opv/basic_cpu_opv_test]
>>> Error 1
>>> make: *** Waiting for unfinished jobs
>>>
>>> Any idea what is going on here ?
>> 
>> Ugh sorry, yes.
>> 
>> New patch below should fix it. Tested with -j:
>
> Perfect, folding it into my series.

Thanks.

> I see that the "all" target was redundant here.

Yeah.

Unfortunately lib.mk has grown a bit more complicated than I would like,
including defining the all target.

It does make for nice short Makefiles for individual test directories,
but it's not all that easy to use if you're not familiar with it [or
even if you are, as I demostrated here :)]

cheers

Re: [PATCH 00/58] networking: Convert timers to use timer_setup()

[Kalle Valo]

Kees Cook  writes:

> On Tue, Oct 17, 2017 at 7:18 AM, Kalle Valo  wrote:
>> + linux-wireless
>>
>> Hi Kees,
>>
>> Kees Cook  writes:
>>
>>> This is the current set of outstanding networking patches to perform
>>> conversions to the new timer interface (rebased to -next). This is not
>>> all expected conversions, but it contains everything needed in networking
>>> to eliminate init_timer(), and all the non-standard setup_*_timer() uses.
>>
>> So this also includes patches which I had queued for
>> wireless-drivers-next:
>>
>> https://patchwork.kernel.org/patch/9986253/
>> https://patchwork.kernel.org/patch/9986245/
>>
>> And looking at patchwork[1] I have even more timer_setup() related
>> patches from you. It would be really helpful if you could clearly
>> document to which tree you want the patches to be applied. I don't care
>
> Hi! Sorry about that. It's been a bit tricky to juggle everything.

Yeah, I understand.

>> if it's net-next or wireless-drivers-next as long as it's not the both
>> (meaning that both Dave and me apply the same patch, which would be
>> bad). The thing is that I really do not have time to figure out for
>> every patch via which tree it's supposed to go.
>
> Which split is preferred? I had been trying to separate wireless from
> the rest of net (but missed some cases).

So what we try to follow is that I apply all patches for
drivers/net/wireless to my wireless-drivers trees, with exception of
Johannes taking mac80211_hwsim.c patches to his mac80211 trees. And
Johannes of course takes all patches for net/wireless and net/mac80211.

So in general I prefer that I take all drivers/net/wireless patches and
make it obvious for Dave that he can ignore those patches (not mix
wireless-drivers and net patches into same set etc). But like I said,
it's ok to push API changes like these via Dave's net trees as well if
you want (and if Dave is ok with that). The chances of conflicts is low,
and if there are be any those would be easy to fix either by me or Dave.

>> For now I'll just drop all your timer_setup() related patches from my
>> queue and I'll assume Dave will take those. Ok?
>>
>> [1] https://patchwork.kernel.org/project/linux-wireless/list/
>
> I guess I'll wait to see what Dave says.

Ok, I don't drop the patches from my queue quite yet then.

-- 
Kalle Valo

Re: [PATCH 00/58] networking: Convert timers to use timer_setup()

[Kalle Valo]

Kees Cook  writes:

> On Tue, Oct 17, 2017 at 7:18 AM, Kalle Valo  wrote:
>> + linux-wireless
>>
>> Hi Kees,
>>
>> Kees Cook  writes:
>>
>>> This is the current set of outstanding networking patches to perform
>>> conversions to the new timer interface (rebased to -next). This is not
>>> all expected conversions, but it contains everything needed in networking
>>> to eliminate init_timer(), and all the non-standard setup_*_timer() uses.
>>
>> So this also includes patches which I had queued for
>> wireless-drivers-next:
>>
>> https://patchwork.kernel.org/patch/9986253/
>> https://patchwork.kernel.org/patch/9986245/
>>
>> And looking at patchwork[1] I have even more timer_setup() related
>> patches from you. It would be really helpful if you could clearly
>> document to which tree you want the patches to be applied. I don't care
>
> Hi! Sorry about that. It's been a bit tricky to juggle everything.

Yeah, I understand.

>> if it's net-next or wireless-drivers-next as long as it's not the both
>> (meaning that both Dave and me apply the same patch, which would be
>> bad). The thing is that I really do not have time to figure out for
>> every patch via which tree it's supposed to go.
>
> Which split is preferred? I had been trying to separate wireless from
> the rest of net (but missed some cases).

So what we try to follow is that I apply all patches for
drivers/net/wireless to my wireless-drivers trees, with exception of
Johannes taking mac80211_hwsim.c patches to his mac80211 trees. And
Johannes of course takes all patches for net/wireless and net/mac80211.

So in general I prefer that I take all drivers/net/wireless patches and
make it obvious for Dave that he can ignore those patches (not mix
wireless-drivers and net patches into same set etc). But like I said,
it's ok to push API changes like these via Dave's net trees as well if
you want (and if Dave is ok with that). The chances of conflicts is low,
and if there are be any those would be easy to fix either by me or Dave.

>> For now I'll just drop all your timer_setup() related patches from my
>> queue and I'll assume Dave will take those. Ok?
>>
>> [1] https://patchwork.kernel.org/project/linux-wireless/list/
>
> I guess I'll wait to see what Dave says.

Ok, I don't drop the patches from my queue quite yet then.

-- 
Kalle Valo

Re: [PATCH v4] printk: hash addresses printed with %p

[Sergey Senozhatsky]

On (10/18/17 15:21), Tobin C. Harding wrote:
[..]
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 86c3385b9eb3..4609738cd2cd 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -33,6 +33,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #ifdef CONFIG_BLOCK
>  #include 
>  #endif
> @@ -1591,6 +1593,70 @@ char *device_node_string(char *buf, char *end, struct 
> device_node *dn,
>   return widen_string(buf, buf - buf_start, end, spec);
>  }
>  
> +/* protects ptr_secret and have_key */
> +DEFINE_SPINLOCK(key_lock);
> +static siphash_key_t ptr_secret __read_mostly;
> +static atomic_t have_key = ATOMIC_INIT(0);
> +
> +static int initialize_ptr_secret(void)
> +{
> + spin_lock(_lock);
> + if (atomic_read(_key) == 1)
> + goto unlock;
> +
> + get_random_bytes(_secret, sizeof(ptr_secret));
> + atomic_set(_key, 1);
> +
> +unlock:
> + spin_unlock(_lock);
> + return 0;
> +}

is this spinlock legal? what happens if we are getting interrupted by NMI?

printk()
 vprintk_emit()
  vscnprintf()
   pointer()
ptr_to_id()
 initialize_ptr_secret()
  spin_lock(_lock)

> NMI

  printk()
   printk_safe_log_store()
vscnprintf()
 pointer()
  ptr_to_id()
   initialize_ptr_secret()
spin_lock(_lock)   


or am I completely misreading the patch? sorry if so.

-ss

Re: [PATCH v9 00/20] simplify crypto wait for async op

[Gilad Ben-Yossef]

On Tue, Oct 17, 2017 at 5:06 PM, Russell King - ARM Linux
 wrote:
> On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
>> Many users of kernel async. crypto services have a pattern of
>> starting an async. crypto op and than using a completion
>> to wait for it to end.
>>
>> This patch set simplifies this common use case in two ways:
>>
>> First, by separating the return codes of the case where a
>> request is queued to a backlog due to the provider being
>> busy (-EBUSY) from the case the request has failed due
>> to the provider being busy and backlogging is not enabled
>> (-EAGAIN).
>>
>> Next, this change is than built on to create a generic API
>> to wait for a async. crypto operation to complete.
>>
>> The end result is a smaller code base and an API that is
>> easier to use and more difficult to get wrong.
>>
>> The patch set was boot tested on x86_64 and arm64 which
>> at the very least tests the crypto users via testmgr and
>> tcrypt but I do note that I do not have access to some
>> of the HW whose drivers are modified nor do I claim I was
>> able to test all of the corner cases.
>>
>> The patch set is based upon linux-next release tagged
>> next-20171013.
>
> Has there been any performance impact analysis of these changes?  I
> ended up with patches for one of the crypto drivers which converted
> its interrupt handling to threaded interrupts being reverted because
> it caused a performance degredation.
>
> Moving code to latest APIs to simplify it is not always beneficial.

I agree with the sentiment but I believe this one is justified.

This patch set basically does 3 things:

1.  Replace one immediate value (-EBUSY) by another (-EAGAIN). Mostly it's just
s/EBUSY/EAGAIN/g. In very few places this resulted very trivial code
changes. I don't
foresee this having any effect on performance.

2. Removal of some conditions and/or conditional jumps that were used to discern
between two different cases which are now now easily tested for by the
different return
value. If at all, this will be an increase in performance, although I
don't expect it to be
noticeable.

3. Replacing a whole bunch of open coded code and data structures
which were pretty much
cut and pasted from the Documentation and therefore identical, with a
single copy thereof.

Every place that I found that deviated slightly from the identical
pattern, it turned out to be
a bug of some sorts and patches for those were sent and accepted already.

So, we might be losing a few inline optimization opportunities but
we're gaining better
cache utilization. Again, I don't expect any of this to have a
noticeable effect to either
direction.

I did run the changed code as best I could and did not notice any
performance changes and
none of the testers and maintainers that ACKed mentioned any.

Having said that, it's a big change that touches many places,
sub-systems and drivers. I do
not claim to have thoroughly tested for performance all the changes in
person. In some cases,
I don't even have access to the specialized hardware. I did get a
reasonable amount of review
and testers I believe - would always love to see more :-)

Many thanks,
Gilad




-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH v4] printk: hash addresses printed with %p

[Sergey Senozhatsky]

On (10/18/17 15:21), Tobin C. Harding wrote:
[..]
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 86c3385b9eb3..4609738cd2cd 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -33,6 +33,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #ifdef CONFIG_BLOCK
>  #include 
>  #endif
> @@ -1591,6 +1593,70 @@ char *device_node_string(char *buf, char *end, struct 
> device_node *dn,
>   return widen_string(buf, buf - buf_start, end, spec);
>  }
>  
> +/* protects ptr_secret and have_key */
> +DEFINE_SPINLOCK(key_lock);
> +static siphash_key_t ptr_secret __read_mostly;
> +static atomic_t have_key = ATOMIC_INIT(0);
> +
> +static int initialize_ptr_secret(void)
> +{
> + spin_lock(_lock);
> + if (atomic_read(_key) == 1)
> + goto unlock;
> +
> + get_random_bytes(_secret, sizeof(ptr_secret));
> + atomic_set(_key, 1);
> +
> +unlock:
> + spin_unlock(_lock);
> + return 0;
> +}

is this spinlock legal? what happens if we are getting interrupted by NMI?

printk()
 vprintk_emit()
  vscnprintf()
   pointer()
ptr_to_id()
 initialize_ptr_secret()
  spin_lock(_lock)

> NMI

  printk()
   printk_safe_log_store()
vscnprintf()
 pointer()
  ptr_to_id()
   initialize_ptr_secret()
spin_lock(_lock)   


or am I completely misreading the patch? sorry if so.

-ss

Re: [PATCH v9 00/20] simplify crypto wait for async op

[Gilad Ben-Yossef]

On Tue, Oct 17, 2017 at 5:06 PM, Russell King - ARM Linux
 wrote:
> On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
>> Many users of kernel async. crypto services have a pattern of
>> starting an async. crypto op and than using a completion
>> to wait for it to end.
>>
>> This patch set simplifies this common use case in two ways:
>>
>> First, by separating the return codes of the case where a
>> request is queued to a backlog due to the provider being
>> busy (-EBUSY) from the case the request has failed due
>> to the provider being busy and backlogging is not enabled
>> (-EAGAIN).
>>
>> Next, this change is than built on to create a generic API
>> to wait for a async. crypto operation to complete.
>>
>> The end result is a smaller code base and an API that is
>> easier to use and more difficult to get wrong.
>>
>> The patch set was boot tested on x86_64 and arm64 which
>> at the very least tests the crypto users via testmgr and
>> tcrypt but I do note that I do not have access to some
>> of the HW whose drivers are modified nor do I claim I was
>> able to test all of the corner cases.
>>
>> The patch set is based upon linux-next release tagged
>> next-20171013.
>
> Has there been any performance impact analysis of these changes?  I
> ended up with patches for one of the crypto drivers which converted
> its interrupt handling to threaded interrupts being reverted because
> it caused a performance degredation.
>
> Moving code to latest APIs to simplify it is not always beneficial.

I agree with the sentiment but I believe this one is justified.

This patch set basically does 3 things:

1.  Replace one immediate value (-EBUSY) by another (-EAGAIN). Mostly it's just
s/EBUSY/EAGAIN/g. In very few places this resulted very trivial code
changes. I don't
foresee this having any effect on performance.

2. Removal of some conditions and/or conditional jumps that were used to discern
between two different cases which are now now easily tested for by the
different return
value. If at all, this will be an increase in performance, although I
don't expect it to be
noticeable.

3. Replacing a whole bunch of open coded code and data structures
which were pretty much
cut and pasted from the Documentation and therefore identical, with a
single copy thereof.

Every place that I found that deviated slightly from the identical
pattern, it turned out to be
a bug of some sorts and patches for those were sent and accepted already.

So, we might be losing a few inline optimization opportunities but
we're gaining better
cache utilization. Again, I don't expect any of this to have a
noticeable effect to either
direction.

I did run the changed code as best I could and did not notice any
performance changes and
none of the testers and maintainers that ACKed mentioned any.

Having said that, it's a big change that touches many places,
sub-systems and drivers. I do
not claim to have thoroughly tested for performance all the changes in
person. In some cases,
I don't even have access to the specialized hardware. I did get a
reasonable amount of review
and testers I believe - would always love to see more :-)

Many thanks,
Gilad




-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table parsing

[Tomasz Nowicki]

Hi,

On 17.10.2017 17:22, Jeremy Linton wrote:

Hi,

On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:

Hi Jeremy,

I did second round of review and have some more comments, please see 
below:


On 12.10.2017 21:48, Jeremy Linton wrote:

ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and describe the properties
of the caches in relation to other caches and processing units.

Add the code to parse the cache hierarchy and report the total
number of levels of cache for a given core using
acpi_find_last_cache_level() as well as fill out the individual
cores cache information with cache_setup_acpi() once the
cpu_cacheinfo structure has been populated by the arch specific
code.

Further, report peers in the topology using setup_acpi_cpu_topology()
to report a unique ID for each processing unit at a given level
in the tree. These unique id's can then be used to match related
processing units which exist as threads, COD (clusters
on die), within a given package, etc.

Signed-off-by: Jeremy Linton 
---
  drivers/acpi/pptt.c | 485 


  1 file changed, 485 insertions(+)
  create mode 100644 drivers/acpi/pptt.c

diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
new file mode 100644
index ..c86715fed4a7
--- /dev/null
+++ b/drivers/acpi/pptt.c
@@ -0,1 +1,485 @@
+/*
+ * Copyright (C) 2017, ARM
+ *
+ * This program is free software; you can redistribute it and/or 
modify it

+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but 
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of 
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
License for

+ * more details.
+ *
+ * This file implements parsing of Processor Properties Topology 
Table (PPTT)
+ * which is optionally used to describe the processor and cache 
topology.

+ * Due to the relative pointers used throughout the table, this doesn't
+ * leverage the existing subtable parsing in the kernel.
+ */
+#define pr_fmt(fmt) "ACPI PPTT: " fmt
+
+#include 
+#include 
+#include 
+
+/*
+ * Given the PPTT table, find and verify that the subtable entry
+ * is located within the table
+ */
+static struct acpi_subtable_header *fetch_pptt_subtable(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    struct acpi_subtable_header *entry;
+
+    /* there isn't a subtable at reference 0 */
+    if (!pptt_ref)
+    return NULL;
+
+    if (pptt_ref + sizeof(struct acpi_subtable_header) > 
table_hdr->length)

+    return NULL;
+
+    entry = (struct acpi_subtable_header *)((u8 *)table_hdr + 
pptt_ref);

+
+    if (pptt_ref + entry->length > table_hdr->length)
+    return NULL;
+
+    return entry;
+}
+
+static struct acpi_pptt_processor *fetch_pptt_node(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    return (struct acpi_pptt_processor 
*)fetch_pptt_subtable(table_hdr, pptt_ref);

+}
+
+static struct acpi_pptt_cache *fetch_pptt_cache(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, 
pptt_ref);

+}
+
+static struct acpi_subtable_header *acpi_get_pptt_resource(
+    struct acpi_table_header *table_hdr,
+    struct acpi_pptt_processor *node, int resource)
+{
+    u32 ref;
+
+    if (resource >= node->number_of_priv_resources)
+    return NULL;
+
+    ref = *(u32 *)((u8 *)node + sizeof(struct acpi_pptt_processor) +
+  sizeof(u32) * resource);
+
+    return fetch_pptt_subtable(table_hdr, ref);
+}
+
+/*
+ * given a pptt resource, verify that it is a cache node, then walk
+ * down each level of caches, counting how many levels are found
+ * as well as checking the cache type (icache, dcache, unified). If a
+ * level & type match, then we set found, and continue the search.
+ * Once the entire cache branch has been walked return its max
+ * depth.
+ */
+static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr,
+    int local_level,
+    struct acpi_subtable_header *res,
+    struct acpi_pptt_cache **found,
+    int level, int type)
+{
+    struct acpi_pptt_cache *cache;
+
+    if (res->type != ACPI_PPTT_TYPE_CACHE)
+    return 0;
+
+    cache = (struct acpi_pptt_cache *) res;
+    while (cache) {
+    local_level++;
+
+    if ((local_level == level) &&
+    (cache->flags & ACPI_PPTT_CACHE_TYPE_VALID) &&
+    ((cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) == 
type)) {


Attributes have to be shifted:

(cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) >> 2


Hmmm, I'm not sure that is true, the top level function in this routine 
convert the "linux" constant to the ACPI version of that 

Re: [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table parsing

[Tomasz Nowicki]

Hi,

On 17.10.2017 17:22, Jeremy Linton wrote:

Hi,

On 10/17/2017 08:25 AM, Tomasz Nowicki wrote:

Hi Jeremy,

I did second round of review and have some more comments, please see 
below:


On 12.10.2017 21:48, Jeremy Linton wrote:

ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and describe the properties
of the caches in relation to other caches and processing units.

Add the code to parse the cache hierarchy and report the total
number of levels of cache for a given core using
acpi_find_last_cache_level() as well as fill out the individual
cores cache information with cache_setup_acpi() once the
cpu_cacheinfo structure has been populated by the arch specific
code.

Further, report peers in the topology using setup_acpi_cpu_topology()
to report a unique ID for each processing unit at a given level
in the tree. These unique id's can then be used to match related
processing units which exist as threads, COD (clusters
on die), within a given package, etc.

Signed-off-by: Jeremy Linton 
---
  drivers/acpi/pptt.c | 485 


  1 file changed, 485 insertions(+)
  create mode 100644 drivers/acpi/pptt.c

diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
new file mode 100644
index ..c86715fed4a7
--- /dev/null
+++ b/drivers/acpi/pptt.c
@@ -0,1 +1,485 @@
+/*
+ * Copyright (C) 2017, ARM
+ *
+ * This program is free software; you can redistribute it and/or 
modify it

+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but 
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of 
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
License for

+ * more details.
+ *
+ * This file implements parsing of Processor Properties Topology 
Table (PPTT)
+ * which is optionally used to describe the processor and cache 
topology.

+ * Due to the relative pointers used throughout the table, this doesn't
+ * leverage the existing subtable parsing in the kernel.
+ */
+#define pr_fmt(fmt) "ACPI PPTT: " fmt
+
+#include 
+#include 
+#include 
+
+/*
+ * Given the PPTT table, find and verify that the subtable entry
+ * is located within the table
+ */
+static struct acpi_subtable_header *fetch_pptt_subtable(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    struct acpi_subtable_header *entry;
+
+    /* there isn't a subtable at reference 0 */
+    if (!pptt_ref)
+    return NULL;
+
+    if (pptt_ref + sizeof(struct acpi_subtable_header) > 
table_hdr->length)

+    return NULL;
+
+    entry = (struct acpi_subtable_header *)((u8 *)table_hdr + 
pptt_ref);

+
+    if (pptt_ref + entry->length > table_hdr->length)
+    return NULL;
+
+    return entry;
+}
+
+static struct acpi_pptt_processor *fetch_pptt_node(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    return (struct acpi_pptt_processor 
*)fetch_pptt_subtable(table_hdr, pptt_ref);

+}
+
+static struct acpi_pptt_cache *fetch_pptt_cache(
+    struct acpi_table_header *table_hdr, u32 pptt_ref)
+{
+    return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, 
pptt_ref);

+}
+
+static struct acpi_subtable_header *acpi_get_pptt_resource(
+    struct acpi_table_header *table_hdr,
+    struct acpi_pptt_processor *node, int resource)
+{
+    u32 ref;
+
+    if (resource >= node->number_of_priv_resources)
+    return NULL;
+
+    ref = *(u32 *)((u8 *)node + sizeof(struct acpi_pptt_processor) +
+  sizeof(u32) * resource);
+
+    return fetch_pptt_subtable(table_hdr, ref);
+}
+
+/*
+ * given a pptt resource, verify that it is a cache node, then walk
+ * down each level of caches, counting how many levels are found
+ * as well as checking the cache type (icache, dcache, unified). If a
+ * level & type match, then we set found, and continue the search.
+ * Once the entire cache branch has been walked return its max
+ * depth.
+ */
+static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr,
+    int local_level,
+    struct acpi_subtable_header *res,
+    struct acpi_pptt_cache **found,
+    int level, int type)
+{
+    struct acpi_pptt_cache *cache;
+
+    if (res->type != ACPI_PPTT_TYPE_CACHE)
+    return 0;
+
+    cache = (struct acpi_pptt_cache *) res;
+    while (cache) {
+    local_level++;
+
+    if ((local_level == level) &&
+    (cache->flags & ACPI_PPTT_CACHE_TYPE_VALID) &&
+    ((cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) == 
type)) {


Attributes have to be shifted:

(cache->attributes & ACPI_PPTT_MASK_CACHE_TYPE) >> 2


Hmmm, I'm not sure that is true, the top level function in this routine 
convert the "linux" constant to the ACPI version of that constant. In 
that case the 

Re: [Intel-wired-lan] [PATCH] [v2] i40e: avoid 64-bit division where possible

[Nambiar, Amritha]

On 10/17/2017 10:33 AM, Alexander Duyck wrote:
> On Tue, Oct 17, 2017 at 8:49 AM, Arnd Bergmann  wrote:
>> The new bandwidth calculation caused a link error on 32-bit
>> architectures, like
>>
>> ERROR: "__aeabi_uldivmod" [drivers/net/ethernet/intel/i40e/i40e.ko] 
>> undefined!
>>
>> The problem is the max_tx_rate calculation that uses 64-bit integers.
>> This is not really necessary since the numbers are in MBit/s so
>> they won't be higher than 4 for the highest support rate, and
>> are guaranteed to not exceed 2^32 in future generations either.
>>
>> Another patch from Alan Brady fixed the link error by adding
>> many calls to do_div(), which makes the code less efficent and
>> less readable than necessary.
>>
>> This changes the representation to 'u32' when dealing with MBit/s
>> and uses div_u64() to convert from u64 numbers in byte/s, reverting
>> parts of Alan's earlier fix that have become obsolete now.
>>

This patch breaks the functionality while converting the rates in
bytes/s provided by tc-layer into the Mbit/s in the driver.
I40E_BW_MBPS_DIVISOR defined in Alan's patch should be used for the
conversion, and not I40E_BW_CREDIT_DIVISOR which does the incorrect
math. I40E_BW_CREDIT_DIVISOR is in place because the device uses credit
rates in values of 50Mbps.

>> Fixes: 2027d4deacb1 ("i40e: Add support setting TC max bandwidth rates")
>> Fixes: 73983b5ae011 ("i40e: fix u64 division usage")
>> Cc: Alan Brady 
>> Signed-off-by: Arnd Bergmann 
> 
> So this patch looks good to me, we just need to test it to verify it
> doesn't break existing functionality. In the meantime if Alan's patch
> has gone through testing we should probably push "i40e: fix u64
> division usage" to Dave so that we can at least fix the linking issues
> on ARM and i386.
> 
> Reviewed-by: Alexander Duyck 
> 
>> ---
>>  drivers/net/ethernet/intel/i40e/i40e.h  |  4 +-
>>  drivers/net/ethernet/intel/i40e/i40e_main.c | 70 
>> +++--
>>  2 files changed, 27 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e.h 
>> b/drivers/net/ethernet/intel/i40e/i40e.h
>> index c3f13120f3ce..c7aa0c982273 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e.h
>> +++ b/drivers/net/ethernet/intel/i40e/i40e.h
>> @@ -407,7 +407,7 @@ struct i40e_channel {
>> u8 enabled_tc;
>> struct i40e_aqc_vsi_properties_data info;
>>
>> -   u64 max_tx_rate;
>> +   u32 max_tx_rate; /* in Mbits/s */
>>
>> /* track this channel belongs to which VSI */
>> struct i40e_vsi *parent_vsi;
>> @@ -1101,5 +1101,5 @@ static inline bool i40e_enabled_xdp_vsi(struct 
>> i40e_vsi *vsi)
>>  }
>>
>>  int i40e_create_queue_channel(struct i40e_vsi *vsi, struct i40e_channel 
>> *ch);
>> -int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate);
>> +int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u32 max_tx_rate);
>>  #endif /* _I40E_H_ */
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
>> b/drivers/net/ethernet/intel/i40e/i40e_main.c
>> index 3ceda140170d..57682cc78508 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
>> @@ -5448,17 +5448,16 @@ int i40e_get_link_speed(struct i40e_vsi *vsi)
>>   *
>>   * Helper function to set BW limit for a given VSI
>>   **/
>> -int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate)
>> +int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u32 max_tx_rate)
>>  {
>> struct i40e_pf *pf = vsi->back;
>> -   u64 credits = 0;
>> int speed = 0;
>> int ret = 0;
>>
>> speed = i40e_get_link_speed(vsi);
>> if (max_tx_rate > speed) {
>> dev_err(>pdev->dev,
>> -   "Invalid max tx rate %llu specified for VSI seid 
>> %d.",
>> +   "Invalid max tx rate %u specified for VSI seid %d.",
>> max_tx_rate, seid);
>> return -EINVAL;
>> }
>> @@ -5469,13 +5468,12 @@ int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 
>> seid, u64 max_tx_rate)
>> }
>>
>> /* Tx rate credits are in values of 50Mbps, 0 is disabled */
>> -   credits = max_tx_rate;
>> -   do_div(credits, I40E_BW_CREDIT_DIVISOR);
>> -   ret = i40e_aq_config_vsi_bw_limit(>hw, seid, credits,
>> +   ret = i40e_aq_config_vsi_bw_limit(>hw, seid,
>> + max_tx_rate / 
>> I40E_BW_CREDIT_DIVISOR,
>>   I40E_MAX_BW_INACTIVE_ACCUM, NULL);
>> if (ret)
>> dev_err(>pdev->dev,
>> -   "Failed set tx rate (%llu Mbps) for vsi->seid %u, 
>> err %s aq_err %s\n",
>> +   "Failed set tx rate (%u Mbps) for vsi->seid %u, err 
>> %s aq_err %s\n",
>> max_tx_rate, seid, i40e_stat_str(>hw, ret),
>>  

Re: [Intel-wired-lan] [PATCH] [v2] i40e: avoid 64-bit division where possible

[Nambiar, Amritha]

On 10/17/2017 10:33 AM, Alexander Duyck wrote:
> On Tue, Oct 17, 2017 at 8:49 AM, Arnd Bergmann  wrote:
>> The new bandwidth calculation caused a link error on 32-bit
>> architectures, like
>>
>> ERROR: "__aeabi_uldivmod" [drivers/net/ethernet/intel/i40e/i40e.ko] 
>> undefined!
>>
>> The problem is the max_tx_rate calculation that uses 64-bit integers.
>> This is not really necessary since the numbers are in MBit/s so
>> they won't be higher than 4 for the highest support rate, and
>> are guaranteed to not exceed 2^32 in future generations either.
>>
>> Another patch from Alan Brady fixed the link error by adding
>> many calls to do_div(), which makes the code less efficent and
>> less readable than necessary.
>>
>> This changes the representation to 'u32' when dealing with MBit/s
>> and uses div_u64() to convert from u64 numbers in byte/s, reverting
>> parts of Alan's earlier fix that have become obsolete now.
>>

This patch breaks the functionality while converting the rates in
bytes/s provided by tc-layer into the Mbit/s in the driver.
I40E_BW_MBPS_DIVISOR defined in Alan's patch should be used for the
conversion, and not I40E_BW_CREDIT_DIVISOR which does the incorrect
math. I40E_BW_CREDIT_DIVISOR is in place because the device uses credit
rates in values of 50Mbps.

>> Fixes: 2027d4deacb1 ("i40e: Add support setting TC max bandwidth rates")
>> Fixes: 73983b5ae011 ("i40e: fix u64 division usage")
>> Cc: Alan Brady 
>> Signed-off-by: Arnd Bergmann 
> 
> So this patch looks good to me, we just need to test it to verify it
> doesn't break existing functionality. In the meantime if Alan's patch
> has gone through testing we should probably push "i40e: fix u64
> division usage" to Dave so that we can at least fix the linking issues
> on ARM and i386.
> 
> Reviewed-by: Alexander Duyck 
> 
>> ---
>>  drivers/net/ethernet/intel/i40e/i40e.h  |  4 +-
>>  drivers/net/ethernet/intel/i40e/i40e_main.c | 70 
>> +++--
>>  2 files changed, 27 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e.h 
>> b/drivers/net/ethernet/intel/i40e/i40e.h
>> index c3f13120f3ce..c7aa0c982273 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e.h
>> +++ b/drivers/net/ethernet/intel/i40e/i40e.h
>> @@ -407,7 +407,7 @@ struct i40e_channel {
>> u8 enabled_tc;
>> struct i40e_aqc_vsi_properties_data info;
>>
>> -   u64 max_tx_rate;
>> +   u32 max_tx_rate; /* in Mbits/s */
>>
>> /* track this channel belongs to which VSI */
>> struct i40e_vsi *parent_vsi;
>> @@ -1101,5 +1101,5 @@ static inline bool i40e_enabled_xdp_vsi(struct 
>> i40e_vsi *vsi)
>>  }
>>
>>  int i40e_create_queue_channel(struct i40e_vsi *vsi, struct i40e_channel 
>> *ch);
>> -int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate);
>> +int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u32 max_tx_rate);
>>  #endif /* _I40E_H_ */
>> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c 
>> b/drivers/net/ethernet/intel/i40e/i40e_main.c
>> index 3ceda140170d..57682cc78508 100644
>> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
>> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
>> @@ -5448,17 +5448,16 @@ int i40e_get_link_speed(struct i40e_vsi *vsi)
>>   *
>>   * Helper function to set BW limit for a given VSI
>>   **/
>> -int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u64 max_tx_rate)
>> +int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 seid, u32 max_tx_rate)
>>  {
>> struct i40e_pf *pf = vsi->back;
>> -   u64 credits = 0;
>> int speed = 0;
>> int ret = 0;
>>
>> speed = i40e_get_link_speed(vsi);
>> if (max_tx_rate > speed) {
>> dev_err(>pdev->dev,
>> -   "Invalid max tx rate %llu specified for VSI seid 
>> %d.",
>> +   "Invalid max tx rate %u specified for VSI seid %d.",
>> max_tx_rate, seid);
>> return -EINVAL;
>> }
>> @@ -5469,13 +5468,12 @@ int i40e_set_bw_limit(struct i40e_vsi *vsi, u16 
>> seid, u64 max_tx_rate)
>> }
>>
>> /* Tx rate credits are in values of 50Mbps, 0 is disabled */
>> -   credits = max_tx_rate;
>> -   do_div(credits, I40E_BW_CREDIT_DIVISOR);
>> -   ret = i40e_aq_config_vsi_bw_limit(>hw, seid, credits,
>> +   ret = i40e_aq_config_vsi_bw_limit(>hw, seid,
>> + max_tx_rate / 
>> I40E_BW_CREDIT_DIVISOR,
>>   I40E_MAX_BW_INACTIVE_ACCUM, NULL);
>> if (ret)
>> dev_err(>pdev->dev,
>> -   "Failed set tx rate (%llu Mbps) for vsi->seid %u, 
>> err %s aq_err %s\n",
>> +   "Failed set tx rate (%u Mbps) for vsi->seid %u, err 
>> %s aq_err %s\n",
>> max_tx_rate, seid, i40e_stat_str(>hw, ret),
>> i40e_aq_str(>hw, pf->hw.aq.asq_last_status));
>> return ret;
>> @@ 

Re: [PATCH] Support resetting WARN*_ONCE

[Michael Ellerman]

Andi Kleen  writes:

> From: Andi Kleen 
>
> I like _ONCE warnings because it's guaranteed that they don't
> flood the log.
>
> During testing I find it useful to reset the state of the once warnings,
> so that I can rerun tests and see if they trigger again, or can
> guarantee that a test run always hits the same warnings.
>
> This patch adds a debugfs interface to reset all the _ONCE
> warnings so that they appear again:
>
> echo 1 > /sys/kernel/debug/clear_warn_once
>
> This is implemented by putting all the warning booleans into
> a special section, and clearing it.

That won't work for arches that do the ONCE logic with a flag will it?
ie. arm64, parisc, powerpc, s390, sh, x86.

They use the version of WARN_ON_ONCE at line ~64 of bug.h

#define __WARN_ONCE_TAINT(taint)
__WARN_FLAGS(BUGFLAG_ONCE|BUGFLAG_TAINT(taint))

#define WARN_ON_ONCE(condition) ({  \
int __ret_warn_on = !!(condition);  \
if (unlikely(__ret_warn_on))\
__WARN_ONCE_TAINT(TAINT_WARN);  \
unlikely(__ret_warn_on);\
})


cheers

> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 87191357d303..68c2f08b7914 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -129,7 +129,7 @@ void __warn(const char *file, int line, void *caller, 
> unsigned taint,
>  
>  #ifndef WARN_ON_ONCE
>  #define WARN_ON_ONCE(condition)  ({  \
> - static bool __section(.data.unlikely) __warned; \
> + static bool __section(.data.once) __warned; \
>   int __ret_warn_once = !!(condition);\
>   \
>   if (unlikely(__ret_warn_once && !__warned)) {   \
> @@ -141,7 +141,7 @@ void __warn(const char *file, int line, void *caller, 
> unsigned taint,
>  #endif
>  
>  #define WARN_ONCE(condition, format...)  ({  \
> - static bool __section(.data.unlikely) __warned; \
> + static bool __section(.data.once) __warned; \
>   int __ret_warn_once = !!(condition);\
>   \
>   if (unlikely(__ret_warn_once && !__warned)) {   \
> @@ -152,7 +152,7 @@ void __warn(const char *file, int line, void *caller, 
> unsigned taint,
>  })
>  
>  #define WARN_TAINT_ONCE(condition, taint, format...) ({  \
> - static bool __section(.data.unlikely) __warned; \
> + static bool __section(.data.once) __warned; \
>   int __ret_warn_once = !!(condition);\
>   \
>   if (unlikely(__ret_warn_once && !__warned)) {   \

Re: [PATCH] Support resetting WARN*_ONCE

[Michael Ellerman]

Andi Kleen  writes:

> From: Andi Kleen 
>
> I like _ONCE warnings because it's guaranteed that they don't
> flood the log.
>
> During testing I find it useful to reset the state of the once warnings,
> so that I can rerun tests and see if they trigger again, or can
> guarantee that a test run always hits the same warnings.
>
> This patch adds a debugfs interface to reset all the _ONCE
> warnings so that they appear again:
>
> echo 1 > /sys/kernel/debug/clear_warn_once
>
> This is implemented by putting all the warning booleans into
> a special section, and clearing it.

That won't work for arches that do the ONCE logic with a flag will it?
ie. arm64, parisc, powerpc, s390, sh, x86.

They use the version of WARN_ON_ONCE at line ~64 of bug.h

#define __WARN_ONCE_TAINT(taint)
__WARN_FLAGS(BUGFLAG_ONCE|BUGFLAG_TAINT(taint))

#define WARN_ON_ONCE(condition) ({  \
int __ret_warn_on = !!(condition);  \
if (unlikely(__ret_warn_on))\
__WARN_ONCE_TAINT(TAINT_WARN);  \
unlikely(__ret_warn_on);\
})


cheers

> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 87191357d303..68c2f08b7914 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -129,7 +129,7 @@ void __warn(const char *file, int line, void *caller, 
> unsigned taint,
>  
>  #ifndef WARN_ON_ONCE
>  #define WARN_ON_ONCE(condition)  ({  \
> - static bool __section(.data.unlikely) __warned; \
> + static bool __section(.data.once) __warned; \
>   int __ret_warn_once = !!(condition);\
>   \
>   if (unlikely(__ret_warn_once && !__warned)) {   \
> @@ -141,7 +141,7 @@ void __warn(const char *file, int line, void *caller, 
> unsigned taint,
>  #endif
>  
>  #define WARN_ONCE(condition, format...)  ({  \
> - static bool __section(.data.unlikely) __warned; \
> + static bool __section(.data.once) __warned; \
>   int __ret_warn_once = !!(condition);\
>   \
>   if (unlikely(__ret_warn_once && !__warned)) {   \
> @@ -152,7 +152,7 @@ void __warn(const char *file, int line, void *caller, 
> unsigned taint,
>  })
>  
>  #define WARN_TAINT_ONCE(condition, taint, format...) ({  \
> - static bool __section(.data.unlikely) __warned; \
> + static bool __section(.data.once) __warned; \
>   int __ret_warn_once = !!(condition);\
>   \
>   if (unlikely(__ret_warn_once && !__warned)) {   \

Re: [tip:locking/urgent] locking/lockdep: Disable cross-release features for now

[Byungchul Park]

On Tue, Oct 17, 2017 at 09:12:02AM +0200, Ingo Molnar wrote:
> > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > > index 2689b7c..e270584 100644
> > > --- a/lib/Kconfig.debug
> > > +++ b/lib/Kconfig.debug
> > > @@ -1092,8 +1092,8 @@ config PROVE_LOCKING
> > >   select DEBUG_MUTEXES
> > >   select DEBUG_RT_MUTEXES if RT_MUTEXES
> > >   select DEBUG_LOCK_ALLOC
> > > - select LOCKDEP_CROSSRELEASE
> > > - select LOCKDEP_COMPLETIONS
> > > + select LOCKDEP_CROSSRELEASE if BROKEN
> > > + select LOCKDEP_COMPLETIONS if BROKEN
> > 
> > I agree with disabling crossrelease as default, becasue of regression,
> > as I originally did.
> > 
> > However, it's expected to spend more time once it's enabled. Is the
> > following acceptable?
> 
> No, please fix performance.

OK. I will fx the performance problem by making the unwinding optional.

Re: [tip:locking/urgent] locking/lockdep: Disable cross-release features for now

[Byungchul Park]

On Tue, Oct 17, 2017 at 09:12:02AM +0200, Ingo Molnar wrote:
> > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > > index 2689b7c..e270584 100644
> > > --- a/lib/Kconfig.debug
> > > +++ b/lib/Kconfig.debug
> > > @@ -1092,8 +1092,8 @@ config PROVE_LOCKING
> > >   select DEBUG_MUTEXES
> > >   select DEBUG_RT_MUTEXES if RT_MUTEXES
> > >   select DEBUG_LOCK_ALLOC
> > > - select LOCKDEP_CROSSRELEASE
> > > - select LOCKDEP_COMPLETIONS
> > > + select LOCKDEP_CROSSRELEASE if BROKEN
> > > + select LOCKDEP_COMPLETIONS if BROKEN
> > 
> > I agree with disabling crossrelease as default, becasue of regression,
> > as I originally did.
> > 
> > However, it's expected to spend more time once it's enabled. Is the
> > following acceptable?
> 
> No, please fix performance.

OK. I will fx the performance problem by making the unwinding optional.

Re: [PATCH 2/3] powernv/pci: Use common code in pnv_ioda_pick_m64_pe()

[Alexey Kardashevskiy]

On 18/10/17 02:39, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 17 Oct 2017 17:07:54 +0200
> 
> Add a jump target so that a bit of code can be better reused
> at the end of this function.


Rather than moving bits around, I'd rather allocate pe_alloc on stack and
ditch kfree() at all. I'll make a patch for this.

> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 17c0330bb059..98d9435240f4 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -364,21 +364,20 @@ static struct pnv_ioda_pe *pnv_ioda_pick_m64_pe(struct 
> pci_bus *bus, bool all)
>   /* Figure out reserved PE numbers by the PE */
>   pnv_ioda_reserve_m64_pe(bus, pe_alloc, all);
>  
> + master_pe = NULL;
> +
>   /*
>* the current bus might not own M64 window and that's all
>* contributed by its child buses. For the case, we needn't
>* pick M64 dependent PE#.
>*/
> - if (bitmap_empty(pe_alloc, phb->ioda.total_pe_num)) {
> - kfree(pe_alloc);
> - return NULL;
> - }
> + if (bitmap_empty(pe_alloc, phb->ioda.total_pe_num))
> + goto free_pe;
>  
>   /*
>* Figure out the master PE and put all slave PEs to master
>* PE's list to form compound PE.
>*/
> - master_pe = NULL;
>   i = -1;
>   while ((i = find_next_bit(pe_alloc, phb->ioda.total_pe_num, i + 1)) <
>   phb->ioda.total_pe_num) {
> @@ -416,6 +415,7 @@ static struct pnv_ioda_pe *pnv_ioda_pick_m64_pe(struct 
> pci_bus *bus, bool all)
>   }
>   }
>  
> +free_pe:
>   kfree(pe_alloc);
>   return master_pe;
>  }
> 



-- 
Alexey

Re: [PATCH 2/3] powernv/pci: Use common code in pnv_ioda_pick_m64_pe()

[Alexey Kardashevskiy]

On 18/10/17 02:39, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 17 Oct 2017 17:07:54 +0200
> 
> Add a jump target so that a bit of code can be better reused
> at the end of this function.


Rather than moving bits around, I'd rather allocate pe_alloc on stack and
ditch kfree() at all. I'll make a patch for this.

> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 17c0330bb059..98d9435240f4 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -364,21 +364,20 @@ static struct pnv_ioda_pe *pnv_ioda_pick_m64_pe(struct 
> pci_bus *bus, bool all)
>   /* Figure out reserved PE numbers by the PE */
>   pnv_ioda_reserve_m64_pe(bus, pe_alloc, all);
>  
> + master_pe = NULL;
> +
>   /*
>* the current bus might not own M64 window and that's all
>* contributed by its child buses. For the case, we needn't
>* pick M64 dependent PE#.
>*/
> - if (bitmap_empty(pe_alloc, phb->ioda.total_pe_num)) {
> - kfree(pe_alloc);
> - return NULL;
> - }
> + if (bitmap_empty(pe_alloc, phb->ioda.total_pe_num))
> + goto free_pe;
>  
>   /*
>* Figure out the master PE and put all slave PEs to master
>* PE's list to form compound PE.
>*/
> - master_pe = NULL;
>   i = -1;
>   while ((i = find_next_bit(pe_alloc, phb->ioda.total_pe_num, i + 1)) <
>   phb->ioda.total_pe_num) {
> @@ -416,6 +415,7 @@ static struct pnv_ioda_pe *pnv_ioda_pick_m64_pe(struct 
> pci_bus *bus, bool all)
>   }
>   }
>  
> +free_pe:
>   kfree(pe_alloc);
>   return master_pe;
>  }
> 



-- 
Alexey

Re: [PATCH 3/3] powernv/pci: Improve a size determination in pnv_pci_init_ioda_phb()

[Alexey Kardashevskiy]

On 18/10/17 02:40, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 17 Oct 2017 17:18:10 +0200
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 98d9435240f4..2febdf06a237 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -3802,7 +3802,7 @@ static void __init pnv_pci_init_ioda_phb(struct 
> device_node *np,
>   phb_id = be64_to_cpup(prop64);
>   pr_debug("  PHB-ID  : 0x%016llx\n", phb_id);
>  
> - phb = memblock_virt_alloc(sizeof(struct pnv_phb), 0);
> + phb = memblock_virt_alloc(sizeof(*phb), 0);
>  
>   /* Allocate PCI controller */
>   phb->hose = hose = pcibios_alloc_controller(np);
> 

Reviewed-by: Alexey Kardashevskiy 



-- 
Alexey

Re: [PATCH 3/3] powernv/pci: Improve a size determination in pnv_pci_init_ioda_phb()

[Alexey Kardashevskiy]

On 18/10/17 02:40, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 17 Oct 2017 17:18:10 +0200
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 98d9435240f4..2febdf06a237 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -3802,7 +3802,7 @@ static void __init pnv_pci_init_ioda_phb(struct 
> device_node *np,
>   phb_id = be64_to_cpup(prop64);
>   pr_debug("  PHB-ID  : 0x%016llx\n", phb_id);
>  
> - phb = memblock_virt_alloc(sizeof(struct pnv_phb), 0);
> + phb = memblock_virt_alloc(sizeof(*phb), 0);
>  
>   /* Allocate PCI controller */
>   phb->hose = hose = pcibios_alloc_controller(np);
> 

Reviewed-by: Alexey Kardashevskiy 



-- 
Alexey

Re: [PATCH 1/3] powernv/pci: Delete an error message for a failed memory allocation in pnv_ioda_pick_m64_pe()

[Alexey Kardashevskiy]

On 18/10/17 02:37, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 17 Oct 2017 16:52:43 +0200
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index fb5cd7511189..17c0330bb059 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -358,11 +358,8 @@ static struct pnv_ioda_pe *pnv_ioda_pick_m64_pe(struct 
> pci_bus *bus, bool all)
>   /* Allocate bitmap */
>   size = _ALIGN_UP(phb->ioda.total_pe_num / 8, sizeof(unsigned long));
>   pe_alloc = kzalloc(size, GFP_KERNEL);
> - if (!pe_alloc) {
> - pr_warn("%s: Out of memory !\n",
> - __func__);
> + if (!pe_alloc)
>   return NULL;
> - }
>  
>   /* Figure out reserved PE numbers by the PE */
>   pnv_ioda_reserve_m64_pe(bus, pe_alloc, all);
> 

Reviewed-by: Alexey Kardashevskiy 



-- 
Alexey

Re: [PATCH 1/3] powernv/pci: Delete an error message for a failed memory allocation in pnv_ioda_pick_m64_pe()

[Alexey Kardashevskiy]

On 18/10/17 02:37, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Tue, 17 Oct 2017 16:52:43 +0200
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  arch/powerpc/platforms/powernv/pci-ioda.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index fb5cd7511189..17c0330bb059 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -358,11 +358,8 @@ static struct pnv_ioda_pe *pnv_ioda_pick_m64_pe(struct 
> pci_bus *bus, bool all)
>   /* Allocate bitmap */
>   size = _ALIGN_UP(phb->ioda.total_pe_num / 8, sizeof(unsigned long));
>   pe_alloc = kzalloc(size, GFP_KERNEL);
> - if (!pe_alloc) {
> - pr_warn("%s: Out of memory !\n",
> - __func__);
> + if (!pe_alloc)
>   return NULL;
> - }
>  
>   /* Figure out reserved PE numbers by the PE */
>   pnv_ioda_reserve_m64_pe(bus, pe_alloc, all);
> 

Reviewed-by: Alexey Kardashevskiy 



-- 
Alexey

Re: [PATCH] input: touchscreen: ti_am335x_tsc: Fix incorrect step config for 5 wire touchscreen

[Michael Nazzareno Trimarchi]

Hi

On Tue, Sep 19, 2017 at 8:29 AM, Vignesh R  wrote:
> From: Jeff Lance 
>
> Step config setting for 5 wire touchscreen is incorrect for Y coordinates.
> It was broken while we moved to DT. If you look close at the offending
> commit bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made
> configurable"), the change was:
>
> - STEPCONFIG_XNP | STEPCONFIG_YPN;
> + ts_dev->bit_xn | ts_dev->bit_yp;
>
> while bit_xn = STEPCONFIG_XNN and bit_yp = STEPCONFIG_YNN. Not quite the
> same.
>
> Fixes: bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made 
> configurable")
> Signed-off-by: Jeff Lance 
> [vigne...@ti.com: Rebase to v4.14-rc1]
> Signed-off-by: Vignesh R 
> ---
>
> Tested on AM335x EVM with 5 wire tsc module. Also sanity tested
> on a 4 wire tsc as well.
>
>  drivers/input/touchscreen/ti_am335x_tsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
> b/drivers/input/touchscreen/ti_am335x_tsc.c
> index 7953381d939a..f1043ae71dcc 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -161,7 +161,7 @@ static void titsc_step_config(struct titsc *ts_dev)
> break;
> case 5:
> config |= ts_dev->bit_xp | STEPCONFIG_INP_AN4 |
> -   ts_dev->bit_xn | ts_dev->bit_yp;
> +   STEPCONFIG_XNP | STEPCONFIG_YPN;
> break;
> case 8:
> config |= ts_dev->bit_yp | STEPCONFIG_INP(ts_dev->inp_xp);
> --

Looks sane to me.

Michael

> 2.14.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] input: touchscreen: ti_am335x_tsc: Fix incorrect step config for 5 wire touchscreen

[Michael Nazzareno Trimarchi]

Hi

On Tue, Sep 19, 2017 at 8:29 AM, Vignesh R  wrote:
> From: Jeff Lance 
>
> Step config setting for 5 wire touchscreen is incorrect for Y coordinates.
> It was broken while we moved to DT. If you look close at the offending
> commit bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made
> configurable"), the change was:
>
> - STEPCONFIG_XNP | STEPCONFIG_YPN;
> + ts_dev->bit_xn | ts_dev->bit_yp;
>
> while bit_xn = STEPCONFIG_XNN and bit_yp = STEPCONFIG_YNN. Not quite the
> same.
>
> Fixes: bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made 
> configurable")
> Signed-off-by: Jeff Lance 
> [vigne...@ti.com: Rebase to v4.14-rc1]
> Signed-off-by: Vignesh R 
> ---
>
> Tested on AM335x EVM with 5 wire tsc module. Also sanity tested
> on a 4 wire tsc as well.
>
>  drivers/input/touchscreen/ti_am335x_tsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
> b/drivers/input/touchscreen/ti_am335x_tsc.c
> index 7953381d939a..f1043ae71dcc 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -161,7 +161,7 @@ static void titsc_step_config(struct titsc *ts_dev)
> break;
> case 5:
> config |= ts_dev->bit_xp | STEPCONFIG_INP_AN4 |
> -   ts_dev->bit_xn | ts_dev->bit_yp;
> +   STEPCONFIG_XNP | STEPCONFIG_YPN;
> break;
> case 8:
> config |= ts_dev->bit_yp | STEPCONFIG_INP(ts_dev->inp_xp);
> --

Looks sane to me.

Michael

> 2.14.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms

[jeffy]

Hi guys,

On 10/18/2017 03:05 AM, Mark Brown wrote:

On Tue, Oct 17, 2017 at 11:53:01AM -0700, Brian Norris wrote:

On Tue, Oct 17, 2017 at 07:46:03PM +0100, Mark Brown wrote:



I would expect we can get a long way in the DT by doing a pass over the
tree and adding links between device nodes in cases where phandle
references exist.  There is a potential issue with circular links which
I'm just going to handwave away right now but I'd expect that to help
otherwise.



But I didn't think FDTs encoded type info. So you don't really know
whether a phandle is a phandle -- it's just an int (which happens to
have a corresponding property in some other node). Are we trusting our
DT bindings well enough to say that, for example, we know that in any
given device node, a property like 'pwms' must be a phandle to a PWM
provider? OK, maybe 'pwms' is a bad example (it's unlikely to get
reused, and it has a companion '#pwm-cells' property), but grepping the
DT bindings directory shows a ton of one-off properties that contain
phandles.


If we're going with the 90% thing we can probably get a long way with a
whitelist of properties, and we'll be able to take that a lot further
with the validatable schemas if they ever happen.



so it looks like we are going to use device link in common code to fix 
this issue(and also other dependency issue), then i will drop this patch 
and the followed rockchip drm device link patch in next version :)



also the reason why i try to use dummy chip instead is that:

currently we have these devices: rockchip spi device(master) -> 
cros_ec_spi device(child) -> cros_ec_pwm(spi based pwm) -> pwm_bl


i added device link to cros_ec_pwm and pwm_bl, that works well for 
unbind/bind cros_ec_pwm device case, but there's a warning when i try to 
unbind cros_ec_spi:



static void device_links_purge(struct device *dev)
{
...
list_for_each_entry_safe_reverse(link, ln, 
>links.consumers, s_node) {

WARN_ON(link->status != DL_STATE_DORMANT &&
link->status != DL_STATE_NONE);<--- hit 
warning here!

__device_link_del(link);
}


but i checked again, that could due to the way spi core unregester 
children devices. maybe it need to call device_release_driver

Re: [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms

[jeffy]

Hi guys,

On 10/18/2017 03:05 AM, Mark Brown wrote:

On Tue, Oct 17, 2017 at 11:53:01AM -0700, Brian Norris wrote:

On Tue, Oct 17, 2017 at 07:46:03PM +0100, Mark Brown wrote:



I would expect we can get a long way in the DT by doing a pass over the
tree and adding links between device nodes in cases where phandle
references exist.  There is a potential issue with circular links which
I'm just going to handwave away right now but I'd expect that to help
otherwise.



But I didn't think FDTs encoded type info. So you don't really know
whether a phandle is a phandle -- it's just an int (which happens to
have a corresponding property in some other node). Are we trusting our
DT bindings well enough to say that, for example, we know that in any
given device node, a property like 'pwms' must be a phandle to a PWM
provider? OK, maybe 'pwms' is a bad example (it's unlikely to get
reused, and it has a companion '#pwm-cells' property), but grepping the
DT bindings directory shows a ton of one-off properties that contain
phandles.


If we're going with the 90% thing we can probably get a long way with a
whitelist of properties, and we'll be able to take that a lot further
with the validatable schemas if they ever happen.



so it looks like we are going to use device link in common code to fix 
this issue(and also other dependency issue), then i will drop this patch 
and the followed rockchip drm device link patch in next version :)



also the reason why i try to use dummy chip instead is that:

currently we have these devices: rockchip spi device(master) -> 
cros_ec_spi device(child) -> cros_ec_pwm(spi based pwm) -> pwm_bl


i added device link to cros_ec_pwm and pwm_bl, that works well for 
unbind/bind cros_ec_pwm device case, but there's a warning when i try to 
unbind cros_ec_spi:



static void device_links_purge(struct device *dev)
{
...
list_for_each_entry_safe_reverse(link, ln, 
>links.consumers, s_node) {

WARN_ON(link->status != DL_STATE_DORMANT &&
link->status != DL_STATE_NONE);<--- hit 
warning here!

__device_link_del(link);
}


but i checked again, that could due to the way spi core unregester 
children devices. maybe it need to call device_release_driver

Re: [RESEND PATCH] irq_work: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Wed, May 31, 2017 at 04:04:17PM +0200, Frederic Weisbecker wrote:
> On Tue, May 30, 2017 at 02:29:20PM +0900, Byungchul Park wrote:
> > On Fri, May 12, 2017 at 09:45:35AM +0900, Byungchul Park wrote:
> > > Although llist provides proper APIs, they are not used. Make them used.
> > 
> > +to pet...@infradead.org
> > +to mi...@kernel.org
> > +to rost...@goodmis.org
> > 
> > I am not sure whom should I send this patch to..
> > Could you check this if you are right person?
> 
> I'll take it.

Hello Frederic,

Any problem to take this?

Thanks,
Byungchul

Re: [RESEND PATCH] irq_work: Don't reinvent the wheel but use existing llist API

[Byungchul Park]

On Wed, May 31, 2017 at 04:04:17PM +0200, Frederic Weisbecker wrote:
> On Tue, May 30, 2017 at 02:29:20PM +0900, Byungchul Park wrote:
> > On Fri, May 12, 2017 at 09:45:35AM +0900, Byungchul Park wrote:
> > > Although llist provides proper APIs, they are not used. Make them used.
> > 
> > +to pet...@infradead.org
> > +to mi...@kernel.org
> > +to rost...@goodmis.org
> > 
> > I am not sure whom should I send this patch to..
> > Could you check this if you are right person?
> 
> I'll take it.

Hello Frederic,

Any problem to take this?

Thanks,
Byungchul

Re: [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8

[gengdongjiu]

Hi Borislav,

On 2017/10/18 1:06, Borislav Petkov wrote:
> On Tue, Oct 17, 2017 at 04:02:21PM +0800, Dongjiu Geng wrote:
>> ARMv8.2 requires implementation of the RAS extension, in
>> this extension it adds SEI(SError Interrupt) notification
>> type, this patch adds new GHES error source SEI handling
>> functions. Because this error source parsing and handling
>> methods are similar with the SEA. So share some SEA handling
>> functions with the SEI
>>
>> Expose one API ghes_notify_abort() to external users. External
>> modules can call this exposed API to parse and handle the
>> SEA or SEI.
>>
>> Note: For the SEI(SError Interrupt), it is asynchronous external
>> abort, the error address recorded by firmware may be not accurate.
>> If not accurate, EL3 firmware needs to identify the address to a
>> invalid value.
>>
>> Cc: Borislav Petkov 
>> Cc: James Morse 
>> Signed-off-by: Dongjiu Geng 
>> Tested-by: Tyler Baicar 
>> Tested-by: Dongjiu Geng 
>> ---
>>  arch/arm64/mm/fault.c |  4 +--
>>  drivers/acpi/apei/Kconfig | 15 ++
>>  drivers/acpi/apei/ghes.c  | 71 
>> ++-
>>  include/acpi/ghes.h   |  2 +-
>>  4 files changed, 70 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 2509e4f..c98c1b3 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -585,7 +585,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
>> struct pt_regs *regs)
>>  if (interrupts_enabled(regs))
>>  nmi_enter();
>>  
>> -ret = ghes_notify_sea();
>> +ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
>>  
>>  if (interrupts_enabled(regs))
>>  nmi_exit();
>> @@ -682,7 +682,7 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
>>  int ret = -ENOENT;
>>  
>>  if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
>> -ret = ghes_notify_sea();
>> +ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
>>  
>>  return ret;
>>  }
>> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
>> index de14d49..47fcb0c 100644
>> --- a/drivers/acpi/apei/Kconfig
>> +++ b/drivers/acpi/apei/Kconfig
>> @@ -54,6 +54,21 @@ config ACPI_APEI_SEA
>>option allows the OS to look for such hardware error record, and
>>take appropriate action.
>>  
>> +config ACPI_APEI_SEI
>> +bool "APEI Asynchronous SError Interrupt logging/recovering support"
> 
> What is "SError" ?
SError is System Error, which is a asynchronous exception in the Internal CPU.

In the ARM RAS Extension, there are mainly two type abort for CPU:
SEA(Synchronous External Abort)
SEI(SError Interrupt)

> 
>> +depends on ARM64 && ACPI_APEI_GHES
>> +default y
>> +help
>> +  This option should be enabled if the system supports
>> +  firmware first handling of SEI (asynchronous SError interrupt).
>> +
>> +  SEI happens with asynchronous external abort for errors on device
>> +  memory reads on ARMv8 systems. If a system supports firmware first
>> +  handling of SEI, the platform analyzes and handles hardware error
>> +  notifications from SEI, and it may then form a HW error record for
>> +  the OS to parse and handle. This option allows the OS to look for
>> +  such hardware error record, and take appropriate action.
>> +
>>  config ACPI_APEI_MEMORY_FAILURE
>>  bool "APEI memory error recovering support"
>>  depends on ACPI_APEI && MEMORY_FAILURE
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 3eee30a..24b4233 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -815,43 +815,67 @@ static struct notifier_block ghes_notifier_hed = {
>>  
>>  #ifdef CONFIG_ACPI_APEI_SEA
>>  static LIST_HEAD(ghes_sea);
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI_APEI_SEI
>> +static LIST_HEAD(ghes_sei);
>> +#endif
>>  
>> +#if defined(CONFIG_ACPI_APEI_SEA) || defined(CONFIG_ACPI_APEI_SEI)
>>  /*
>> - * Return 0 only if one of the SEA error sources successfully reported an 
>> error
>> - * record sent from the firmware.
>> + * Return 0 only if one of the SEA or SEI error sources successfully
>> + * reported an error record sent from the firmware.
>>   */
>> -int ghes_notify_sea(void)
>> +int ghes_notify_abort(u8 type)
> 
> Adding "abort" everywhere makes it worse: what does this function now
> do, notify or abort or both?
This function is used to notify APEI driver to parse APEI table and do some
recovery, such as calling memrory_failure() to identify the address to a
poisoned memory and deliver SIGBUS to related application.

> 
> Ditto for the remaining ones. Please think of a better name.
Ok, thanks for your good suggestion, I will consider to use a better name.

> 
> 
> ghes_notify_sei() sounds much better to me, for example. And then you
> 

Re: [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8

[gengdongjiu]

Hi Borislav,

On 2017/10/18 1:06, Borislav Petkov wrote:
> On Tue, Oct 17, 2017 at 04:02:21PM +0800, Dongjiu Geng wrote:
>> ARMv8.2 requires implementation of the RAS extension, in
>> this extension it adds SEI(SError Interrupt) notification
>> type, this patch adds new GHES error source SEI handling
>> functions. Because this error source parsing and handling
>> methods are similar with the SEA. So share some SEA handling
>> functions with the SEI
>>
>> Expose one API ghes_notify_abort() to external users. External
>> modules can call this exposed API to parse and handle the
>> SEA or SEI.
>>
>> Note: For the SEI(SError Interrupt), it is asynchronous external
>> abort, the error address recorded by firmware may be not accurate.
>> If not accurate, EL3 firmware needs to identify the address to a
>> invalid value.
>>
>> Cc: Borislav Petkov 
>> Cc: James Morse 
>> Signed-off-by: Dongjiu Geng 
>> Tested-by: Tyler Baicar 
>> Tested-by: Dongjiu Geng 
>> ---
>>  arch/arm64/mm/fault.c |  4 +--
>>  drivers/acpi/apei/Kconfig | 15 ++
>>  drivers/acpi/apei/ghes.c  | 71 
>> ++-
>>  include/acpi/ghes.h   |  2 +-
>>  4 files changed, 70 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 2509e4f..c98c1b3 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -585,7 +585,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
>> struct pt_regs *regs)
>>  if (interrupts_enabled(regs))
>>  nmi_enter();
>>  
>> -ret = ghes_notify_sea();
>> +ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
>>  
>>  if (interrupts_enabled(regs))
>>  nmi_exit();
>> @@ -682,7 +682,7 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
>>  int ret = -ENOENT;
>>  
>>  if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
>> -ret = ghes_notify_sea();
>> +ret = ghes_notify_abort(ACPI_HEST_NOTIFY_SEA);
>>  
>>  return ret;
>>  }
>> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
>> index de14d49..47fcb0c 100644
>> --- a/drivers/acpi/apei/Kconfig
>> +++ b/drivers/acpi/apei/Kconfig
>> @@ -54,6 +54,21 @@ config ACPI_APEI_SEA
>>option allows the OS to look for such hardware error record, and
>>take appropriate action.
>>  
>> +config ACPI_APEI_SEI
>> +bool "APEI Asynchronous SError Interrupt logging/recovering support"
> 
> What is "SError" ?
SError is System Error, which is a asynchronous exception in the Internal CPU.

In the ARM RAS Extension, there are mainly two type abort for CPU:
SEA(Synchronous External Abort)
SEI(SError Interrupt)

> 
>> +depends on ARM64 && ACPI_APEI_GHES
>> +default y
>> +help
>> +  This option should be enabled if the system supports
>> +  firmware first handling of SEI (asynchronous SError interrupt).
>> +
>> +  SEI happens with asynchronous external abort for errors on device
>> +  memory reads on ARMv8 systems. If a system supports firmware first
>> +  handling of SEI, the platform analyzes and handles hardware error
>> +  notifications from SEI, and it may then form a HW error record for
>> +  the OS to parse and handle. This option allows the OS to look for
>> +  such hardware error record, and take appropriate action.
>> +
>>  config ACPI_APEI_MEMORY_FAILURE
>>  bool "APEI memory error recovering support"
>>  depends on ACPI_APEI && MEMORY_FAILURE
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 3eee30a..24b4233 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -815,43 +815,67 @@ static struct notifier_block ghes_notifier_hed = {
>>  
>>  #ifdef CONFIG_ACPI_APEI_SEA
>>  static LIST_HEAD(ghes_sea);
>> +#endif
>> +
>> +#ifdef CONFIG_ACPI_APEI_SEI
>> +static LIST_HEAD(ghes_sei);
>> +#endif
>>  
>> +#if defined(CONFIG_ACPI_APEI_SEA) || defined(CONFIG_ACPI_APEI_SEI)
>>  /*
>> - * Return 0 only if one of the SEA error sources successfully reported an 
>> error
>> - * record sent from the firmware.
>> + * Return 0 only if one of the SEA or SEI error sources successfully
>> + * reported an error record sent from the firmware.
>>   */
>> -int ghes_notify_sea(void)
>> +int ghes_notify_abort(u8 type)
> 
> Adding "abort" everywhere makes it worse: what does this function now
> do, notify or abort or both?
This function is used to notify APEI driver to parse APEI table and do some
recovery, such as calling memrory_failure() to identify the address to a
poisoned memory and deliver SIGBUS to related application.

> 
> Ditto for the remaining ones. Please think of a better name.
Ok, thanks for your good suggestion, I will consider to use a better name.

> 
> 
> ghes_notify_sei() sounds much better to me, for example. And then you
> can add a whole set of *_sei() functions similar to the *_sea() ones and
> then you don't have to do all that 

[PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

[Jeffy Chen]

The zImage file size should be aligned.

Fixes: e4bae4d0b5f3 ("arm/efi: Split zImage code and data into separate PE/COFF 
sections")
Signed-off-by: Jeffy Chen 
---

 arch/arm/boot/compressed/vmlinux.lds.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/compressed/vmlinux.lds.S 
b/arch/arm/boot/compressed/vmlinux.lds.S
index b38dcef90756..1636fa259577 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -70,10 +70,6 @@ SECTIONS
   .got : { *(.got) }
   _got_end = .;
 
-  /* ensure the zImage file size is always a multiple of 64 bits */
-  /* (without a dummy byte, ld just ignores the empty section) */
-  .pad : { BYTE(0); . = ALIGN(8); }
-
 #ifdef CONFIG_EFI_STUB
   .data : ALIGN(4096) {
 __pecoff_data_start = .;
@@ -93,6 +89,10 @@ SECTIONS
   __pecoff_data_rawsize = . - ADDR(.data);
 #endif
 
+  /* ensure the zImage file size is always a multiple of 64 bits */
+  /* (without a dummy byte, ld just ignores the empty section) */
+  .pad : { BYTE(0); . = ALIGN(8); }
+
   _edata = .;
 
   _magic_sig = ZIMAGE_MAGIC(0x016f2818);
-- 
2.11.0

[PATCH] ARM: Fix zImage file size not aligned with CONFIG_EFI_STUB enabled

[Jeffy Chen]

The zImage file size should be aligned.

Fixes: e4bae4d0b5f3 ("arm/efi: Split zImage code and data into separate PE/COFF 
sections")
Signed-off-by: Jeffy Chen 
---

 arch/arm/boot/compressed/vmlinux.lds.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/compressed/vmlinux.lds.S 
b/arch/arm/boot/compressed/vmlinux.lds.S
index b38dcef90756..1636fa259577 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.S
+++ b/arch/arm/boot/compressed/vmlinux.lds.S
@@ -70,10 +70,6 @@ SECTIONS
   .got : { *(.got) }
   _got_end = .;
 
-  /* ensure the zImage file size is always a multiple of 64 bits */
-  /* (without a dummy byte, ld just ignores the empty section) */
-  .pad : { BYTE(0); . = ALIGN(8); }
-
 #ifdef CONFIG_EFI_STUB
   .data : ALIGN(4096) {
 __pecoff_data_start = .;
@@ -93,6 +89,10 @@ SECTIONS
   __pecoff_data_rawsize = . - ADDR(.data);
 #endif
 
+  /* ensure the zImage file size is always a multiple of 64 bits */
+  /* (without a dummy byte, ld just ignores the empty section) */
+  .pad : { BYTE(0); . = ALIGN(8); }
+
   _edata = .;
 
   _magic_sig = ZIMAGE_MAGIC(0x016f2818);
-- 
2.11.0

Re: [RFC PATCH v4 6/8] drm/bridge/analogix: Do not use device's drvdata

[Archit Taneja]

Hi,

On 10/18/2017 05:13 AM, Jingoo Han wrote:

On Tuesday, October 17, 2017 6:16 AM, Jeffy Chen wrote:


From: Tomasz Figa 

The driver that instantiates the bridge should own the drvdata, as all
driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
owned by its driver struct. Moreover, storing two different pointer
types in driver data depending on driver initialization status is barely
a good practice and in fact has led to many bugs in this driver.

Let's clean up this mess and change Analogix entry points to simply
accept some opaque struct pointer, adjusting their users at the same
time to avoid breaking the compilation.

Signed-off-by: Tomasz Figa 
Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 




This depends on previous patches of the series. I guess it would be easier
to queue this to drm-misc as a part of the eDP support series. For that:

Acked-by: Archit Taneja 


Acked-by: Jingoo Han 

Best regards,
Jingoo Han


---

Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 +
-
  drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 47

+++---

--
  include/drm/bridge/analogix_dp.h   | 19 
  4 files changed, 73 insertions(+), 69 deletions(-)




___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



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

Re: [RFC PATCH v4 6/8] drm/bridge/analogix: Do not use device's drvdata

[Archit Taneja]

Hi,

On 10/18/2017 05:13 AM, Jingoo Han wrote:

On Tuesday, October 17, 2017 6:16 AM, Jeffy Chen wrote:


From: Tomasz Figa 

The driver that instantiates the bridge should own the drvdata, as all
driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
owned by its driver struct. Moreover, storing two different pointer
types in driver data depending on driver initialization status is barely
a good practice and in fact has led to many bugs in this driver.

Let's clean up this mess and change Analogix entry points to simply
accept some opaque struct pointer, adjusting their users at the same
time to avoid breaking the compilation.

Signed-off-by: Tomasz Figa 
Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 




This depends on previous patches of the series. I guess it would be easier
to queue this to drm-misc as a part of the eDP support series. For that:

Acked-by: Archit Taneja 


Acked-by: Jingoo Han 

Best regards,
Jingoo Han


---

Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 +
-
  drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 47

+++---

--
  include/drm/bridge/analogix_dp.h   | 19 
  4 files changed, 73 insertions(+), 69 deletions(-)




___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



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

[ANNOUNCE] Call for Papers - linux.conf.au Kernel Miniconf, Sydney, 22 January 2018

[Andrew Donnellan]

Greetings,

*

TL;DR

- LCA Kernel Miniconf, Sydney, Australia, 22 Jan 2018

- Submissions by 30 November 2017, 23:59 (AEDT/UTC+11)

- Wanted: anything interesting to kernel hackers! Speakers from
  diverse backgrounds encouraged!

- Form: https://rego.linux.conf.au/proposals/submit/kernel-miniconf/

*

linux.conf.au 2018 will be held at the University of Technology Sydney 
from 22-26 January 2018.


The Kernel Miniconf is returning once again and the CFP is now open!


What is the Kernel Miniconf?


LCA's miniconfs are one-day special interest streams that allow in depth 
discussion of particular topics.


The Kernel Miniconf will feature a variety of talks and discussions on 
kernel and systems programming topics, including technical talks on 
current kernel developments and kernel community/process. Past Kernel 
Miniconfs have included talks on various aspects of the kernel such as 
networking, filesystems, power management, and so on, as well as 
community issues such as licensing.


The focus of the miniconf will primarily be on the Linux kernel, however 
interesting submissions about other Free Software kernels are welcome 
and encouraged. It's anticipated that most talks will be aimed at people 
with existing kernel and low-level programming experience, however 
anyone is welcome no matter what their level of experience. There will 
be a lightning talks/open discussion session at the end of the day.



Who can attend?
---

Anyone with an LCA ticket can attend. A limited number of miniconf-only 
day tickets may be available - contact me for further details.



Who can speak?
--

Anyone with something interesting and kernel-related to say! You will 
need to have an LCA ticket though - unfortunately miniconf speakers 
don't qualify for speakers' tickets. (Please contact me if that's a 
problem for you and we may be able to find some options.)


We strongly encourage both first-time and seasoned speakers from all 
backgrounds, ages, genders, nationalities, ethnicities, religions and 
abilities. Like the main LCA conference itself, we respect and encourage 
diversity at our miniconf. If you would like any assistance with 
creating a proposal, don't hesitate to ask!



Submission process
--

To submit a proposal, go to 
https://rego.linux.conf.au/proposals/submit/kernel-miniconf/.


Talks should be 25 minutes or 45 minutes. Please indicate your preferred 
timeslot length in your submission.



Dates and deadlines
---

* Right Now - CFP opens

* 30 November 2017, 23:59 (AEDT/UTC+11) - CFP closes

* by 7 December 2017 - Confirmation

* 22 January 2018 - conference!

Please indicate in your submission if you require earlier confirmation 
to assist in arranging travel/funding.



Questions?
--

If you've got any other questions about the Kernel Miniconf that I 
haven't covered here, ping me at andrew.donnel...@au1.ibm.com.


For general LCA questions, ask t...@lca2018.org or @linuxconfau on Twitter.


- Andrew

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

[ANNOUNCE] Call for Papers - linux.conf.au Kernel Miniconf, Sydney, 22 January 2018

[Andrew Donnellan]

Greetings,

*

TL;DR

- LCA Kernel Miniconf, Sydney, Australia, 22 Jan 2018

- Submissions by 30 November 2017, 23:59 (AEDT/UTC+11)

- Wanted: anything interesting to kernel hackers! Speakers from
  diverse backgrounds encouraged!

- Form: https://rego.linux.conf.au/proposals/submit/kernel-miniconf/

*

linux.conf.au 2018 will be held at the University of Technology Sydney 
from 22-26 January 2018.


The Kernel Miniconf is returning once again and the CFP is now open!


What is the Kernel Miniconf?


LCA's miniconfs are one-day special interest streams that allow in depth 
discussion of particular topics.


The Kernel Miniconf will feature a variety of talks and discussions on 
kernel and systems programming topics, including technical talks on 
current kernel developments and kernel community/process. Past Kernel 
Miniconfs have included talks on various aspects of the kernel such as 
networking, filesystems, power management, and so on, as well as 
community issues such as licensing.


The focus of the miniconf will primarily be on the Linux kernel, however 
interesting submissions about other Free Software kernels are welcome 
and encouraged. It's anticipated that most talks will be aimed at people 
with existing kernel and low-level programming experience, however 
anyone is welcome no matter what their level of experience. There will 
be a lightning talks/open discussion session at the end of the day.



Who can attend?
---

Anyone with an LCA ticket can attend. A limited number of miniconf-only 
day tickets may be available - contact me for further details.



Who can speak?
--

Anyone with something interesting and kernel-related to say! You will 
need to have an LCA ticket though - unfortunately miniconf speakers 
don't qualify for speakers' tickets. (Please contact me if that's a 
problem for you and we may be able to find some options.)


We strongly encourage both first-time and seasoned speakers from all 
backgrounds, ages, genders, nationalities, ethnicities, religions and 
abilities. Like the main LCA conference itself, we respect and encourage 
diversity at our miniconf. If you would like any assistance with 
creating a proposal, don't hesitate to ask!



Submission process
--

To submit a proposal, go to 
https://rego.linux.conf.au/proposals/submit/kernel-miniconf/.


Talks should be 25 minutes or 45 minutes. Please indicate your preferred 
timeslot length in your submission.



Dates and deadlines
---

* Right Now - CFP opens

* 30 November 2017, 23:59 (AEDT/UTC+11) - CFP closes

* by 7 December 2017 - Confirmation

* 22 January 2018 - conference!

Please indicate in your submission if you require earlier confirmation 
to assist in arranging travel/funding.



Questions?
--

If you've got any other questions about the Kernel Miniconf that I 
haven't covered here, ping me at andrew.donnel...@au1.ibm.com.


For general LCA questions, ask t...@lca2018.org or @linuxconfau on Twitter.


- Andrew

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

[PATCH 1/6] ARM: dts: uniphier: add GPIO controller nodes

[Masahiro Yamada]

The GPIO controller also acts as an interrupt controller and the
interrupt lines are connected to the AIDET block.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ld4.dtsi  | 14 ++
 arch/arm/boot/dts/uniphier-pro4.dtsi | 14 ++
 arch/arm/boot/dts/uniphier-pro5.dtsi | 14 ++
 arch/arm/boot/dts/uniphier-pxs2.dtsi | 17 +
 arch/arm/boot/dts/uniphier-sld8.dtsi | 18 ++
 5 files changed, 77 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi 
b/arch/arm/boot/dts/uniphier-ld4.dtsi
index 79183db..b0151c4 100644
--- a/arch/arm/boot/dts/uniphier-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
@@ -103,6 +103,20 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>;
+   gpio-ranges-group-names = "gpio_range";
+   ngpios = <136>;
+   socionext,interrupt-ranges = <0 48 13>, <14 62 2>;
+   };
+
i2c0: i2c@5840 {
compatible = "socionext,uniphier-i2c";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-pro4.dtsi 
b/arch/arm/boot/dts/uniphier-pro4.dtsi
index b3dbbd9b..2921729 100644
--- a/arch/arm/boot/dts/uniphier-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
@@ -111,6 +111,20 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>;
+   gpio-ranges-group-names = "gpio_range";
+   ngpios = <248>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi 
b/arch/arm/boot/dts/uniphier-pro5.dtsi
index b026bcd..c5d9501 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -198,6 +198,20 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>;
+   gpio-ranges-group-names = "gpio_range";
+   ngpios = <248>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi 
b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 90b020c..4d83001 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -173,6 +173,23 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>,
+ < 96 0 0>;
+   gpio-ranges-group-names = "gpio_range0",
+ "gpio_range1";
+   ngpios = <232>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>,
+<21 217 3>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-sld8.dtsi 

[PATCH 5/6] ARM: dts: uniphier: add GPIO hog definition

[Masahiro Yamada]

Interrupt lines from on-board devices are connected to the GPIO
controller.  Add GPIO hogging so that the corresponding GPIO line
is automatically requested.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ld4-ref.dts  | 8 
 arch/arm/boot/dts/uniphier-ld6b-ref.dts | 8 
 arch/arm/boot/dts/uniphier-pro4-ref.dts | 8 
 arch/arm/boot/dts/uniphier-sld8-ref.dts | 8 
 4 files changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-ld4-ref.dts 
b/arch/arm/boot/dts/uniphier-ld4-ref.dts
index 148e7bb..0056852 100644
--- a/arch/arm/boot/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld4-ref.dts
@@ -53,6 +53,14 @@
status = "okay";
 };
 
+ {
+   xirq1 {
+   gpio-hog;
+   gpios = <121 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/uniphier-ld6b-ref.dts 
b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
index ec2a098..0e510a7 100644
--- a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
@@ -55,6 +55,14 @@
status = "okay";
 };
 
+ {
+   xirq4 {
+   gpio-hog;
+   gpios = <124 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/uniphier-pro4-ref.dts 
b/arch/arm/boot/dts/uniphier-pro4-ref.dts
index 7316cc6..be99467 100644
--- a/arch/arm/boot/dts/uniphier-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-pro4-ref.dts
@@ -55,6 +55,14 @@
status = "okay";
 };
 
+ {
+   xirq2 {
+   gpio-hog;
+   gpios = <122 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/uniphier-sld8-ref.dts 
b/arch/arm/boot/dts/uniphier-sld8-ref.dts
index 4ec48a1..1c0e707 100644
--- a/arch/arm/boot/dts/uniphier-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-sld8-ref.dts
@@ -53,6 +53,14 @@
status = "okay";
 };
 
+ {
+   xirq0 {
+   gpio-hog;
+   gpios = <120 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

[PATCH 1/6] ARM: dts: uniphier: add GPIO controller nodes

[Masahiro Yamada]

The GPIO controller also acts as an interrupt controller and the
interrupt lines are connected to the AIDET block.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ld4.dtsi  | 14 ++
 arch/arm/boot/dts/uniphier-pro4.dtsi | 14 ++
 arch/arm/boot/dts/uniphier-pro5.dtsi | 14 ++
 arch/arm/boot/dts/uniphier-pxs2.dtsi | 17 +
 arch/arm/boot/dts/uniphier-sld8.dtsi | 18 ++
 5 files changed, 77 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi 
b/arch/arm/boot/dts/uniphier-ld4.dtsi
index 79183db..b0151c4 100644
--- a/arch/arm/boot/dts/uniphier-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
@@ -103,6 +103,20 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>;
+   gpio-ranges-group-names = "gpio_range";
+   ngpios = <136>;
+   socionext,interrupt-ranges = <0 48 13>, <14 62 2>;
+   };
+
i2c0: i2c@5840 {
compatible = "socionext,uniphier-i2c";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-pro4.dtsi 
b/arch/arm/boot/dts/uniphier-pro4.dtsi
index b3dbbd9b..2921729 100644
--- a/arch/arm/boot/dts/uniphier-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
@@ -111,6 +111,20 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>;
+   gpio-ranges-group-names = "gpio_range";
+   ngpios = <248>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-pro5.dtsi 
b/arch/arm/boot/dts/uniphier-pro5.dtsi
index b026bcd..c5d9501 100644
--- a/arch/arm/boot/dts/uniphier-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
@@ -198,6 +198,20 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>;
+   gpio-ranges-group-names = "gpio_range";
+   ngpios = <248>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-pxs2.dtsi 
b/arch/arm/boot/dts/uniphier-pxs2.dtsi
index 90b020c..4d83001 100644
--- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
@@ -173,6 +173,23 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>,
+ < 96 0 0>;
+   gpio-ranges-group-names = "gpio_range0",
+ "gpio_range1";
+   ngpios = <232>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>,
+<21 217 3>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-sld8.dtsi 

[PATCH 5/6] ARM: dts: uniphier: add GPIO hog definition

[Masahiro Yamada]

Interrupt lines from on-board devices are connected to the GPIO
controller.  Add GPIO hogging so that the corresponding GPIO line
is automatically requested.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ld4-ref.dts  | 8 
 arch/arm/boot/dts/uniphier-ld6b-ref.dts | 8 
 arch/arm/boot/dts/uniphier-pro4-ref.dts | 8 
 arch/arm/boot/dts/uniphier-sld8-ref.dts | 8 
 4 files changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-ld4-ref.dts 
b/arch/arm/boot/dts/uniphier-ld4-ref.dts
index 148e7bb..0056852 100644
--- a/arch/arm/boot/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld4-ref.dts
@@ -53,6 +53,14 @@
status = "okay";
 };
 
+ {
+   xirq1 {
+   gpio-hog;
+   gpios = <121 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/uniphier-ld6b-ref.dts 
b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
index ec2a098..0e510a7 100644
--- a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
@@ -55,6 +55,14 @@
status = "okay";
 };
 
+ {
+   xirq4 {
+   gpio-hog;
+   gpios = <124 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/uniphier-pro4-ref.dts 
b/arch/arm/boot/dts/uniphier-pro4-ref.dts
index 7316cc6..be99467 100644
--- a/arch/arm/boot/dts/uniphier-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-pro4-ref.dts
@@ -55,6 +55,14 @@
status = "okay";
 };
 
+ {
+   xirq2 {
+   gpio-hog;
+   gpios = <122 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/uniphier-sld8-ref.dts 
b/arch/arm/boot/dts/uniphier-sld8-ref.dts
index 4ec48a1..1c0e707 100644
--- a/arch/arm/boot/dts/uniphier-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-sld8-ref.dts
@@ -53,6 +53,14 @@
status = "okay";
 };
 
+ {
+   xirq0 {
+   gpio-hog;
+   gpios = <120 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

[PATCH 0/6] ARM: dts: uniphier: add GPIO nodes and related properties

[Masahiro Yamada]

Masahiro Yamada (6):
  ARM: dts: uniphier: add GPIO controller nodes
  arm64: dts: uniphier: add GPIO controller nodes
  ARM: dts: uniphier: route on-board device IRQ to GPIO controller
  arm64: dts: uniphier: route on-board device IRQ to GPIO controller
  ARM: dts: uniphier: add GPIO hog definition
  arm64: dts: uniphier: add GPIO hog definition

 arch/arm/boot/dts/uniphier-ld4-ref.dts | 10 -
 arch/arm/boot/dts/uniphier-ld4.dtsi| 14 
 arch/arm/boot/dts/uniphier-ld6b-ref.dts| 10 -
 arch/arm/boot/dts/uniphier-pro4-ref.dts| 10 -
 arch/arm/boot/dts/uniphier-pro4.dtsi   | 14 
 arch/arm/boot/dts/uniphier-pro5.dtsi   | 14 
 arch/arm/boot/dts/uniphier-pxs2.dtsi   | 17 +++
 arch/arm/boot/dts/uniphier-sld8-ref.dts| 10 -
 arch/arm/boot/dts/uniphier-sld8.dtsi   | 18 
 arch/arm/boot/dts/uniphier-support-card.dtsi   |  1 +
 .../arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 11 +-
 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi   | 25 ++
 .../arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 11 +-
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 19 
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi   | 19 
 15 files changed, 197 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH 6/6] arm64: dts: uniphier: add GPIO hog definition

[Masahiro Yamada]

Interrupt lines from on-board devices are connected to the GPIO
controller.  Add GPIO hogging so that the corresponding GPIO line
is automatically requested.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 8 
 arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 8 
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
index 77f50fd..dd7193a 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
@@ -48,6 +48,14 @@
status = "okay";
 };
 
+ {
+   xirq0 {
+   gpio-hog;
+   gpios = <120 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
index 1f55fe1..d99e373 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
@@ -48,6 +48,14 @@
status = "okay";
 };
 
+ {
+   xirq0 {
+   gpio-hog;
+   gpios = <120 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

[PATCH 3/6] ARM: dts: uniphier: route on-board device IRQ to GPIO controller

[Masahiro Yamada]

Interrupt lines from on-board devices are connected to the GPIO
controller.  Handle this correctly.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ld4-ref.dts   | 2 +-
 arch/arm/boot/dts/uniphier-ld6b-ref.dts  | 2 +-
 arch/arm/boot/dts/uniphier-pro4-ref.dts  | 2 +-
 arch/arm/boot/dts/uniphier-sld8-ref.dts  | 2 +-
 arch/arm/boot/dts/uniphier-support-card.dtsi | 1 +
 5 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ld4-ref.dts 
b/arch/arm/boot/dts/uniphier-ld4-ref.dts
index b3aaab3..148e7bb 100644
--- a/arch/arm/boot/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld4-ref.dts
@@ -38,7 +38,7 @@
 };
 
  {
-   interrupts = <0 49 4>;
+   interrupts = <1 8>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-ld6b-ref.dts 
b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
index 2188d11..ec2a098 100644
--- a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
@@ -40,7 +40,7 @@
 };
 
  {
-   interrupts = <0 52 4>;
+   interrupts = <4 8>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-pro4-ref.dts 
b/arch/arm/boot/dts/uniphier-pro4-ref.dts
index 903df63..7316cc6 100644
--- a/arch/arm/boot/dts/uniphier-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-pro4-ref.dts
@@ -40,7 +40,7 @@
 };
 
  {
-   interrupts = <0 50 4>;
+   interrupts = <2 8>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-sld8-ref.dts 
b/arch/arm/boot/dts/uniphier-sld8-ref.dts
index 5accd3c..4ec48a1 100644
--- a/arch/arm/boot/dts/uniphier-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-sld8-ref.dts
@@ -38,7 +38,7 @@
 };
 
  {
-   interrupts = <0 48 4>;
+   interrupts = <0 8>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-support-card.dtsi 
b/arch/arm/boot/dts/uniphier-support-card.dtsi
index 6c825f1..c6d99c4 100644
--- a/arch/arm/boot/dts/uniphier-support-card.dtsi
+++ b/arch/arm/boot/dts/uniphier-support-card.dtsi
@@ -16,6 +16,7 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x 1 0x01f0 0x0010>;
+   interrupt-parent = <>;
 
ethsc: ethernet@0 {
compatible = "smsc,lan9118", "smsc,lan9115";
-- 
2.7.4

[PATCH 4/6] arm64: dts: uniphier: route on-board device IRQ to GPIO controller

[Masahiro Yamada]

Interrupt lines from on-board devices are connected to the GPIO
controller.  Handle this correctly.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 3 ++-
 arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
index ffb473a..77f50fd 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
@@ -40,7 +40,8 @@
 };
 
  {
-   interrupts = <0 48 4>;
+   interrupt-parent = <>;
+   interrupts = <0 8>;
 };
 
  {
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
index 1ca0c86..1f55fe1 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
@@ -40,7 +40,8 @@
 };
 
  {
-   interrupts = <0 48 4>;
+   interrupt-parent = <>;
+   interrupts = <0 8>;
 };
 
  {
-- 
2.7.4

[PATCH 2/6] arm64: dts: uniphier: add GPIO controller nodes

[Masahiro Yamada]

The GPIO controller also acts as an interrupt controller and the
interrupt lines are connected to the AIDET block.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 25 
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 19 ++
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 19 ++
 3 files changed, 63 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index ee4aff5..99f14cc 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -161,6 +161,31 @@
};
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>,
+ < 43 0 0>,
+ < 51 0 0>,
+ < 96 0 0>,
+ < 160 0 0>,
+ < 184 0 0>;
+   gpio-ranges-group-names = "gpio_range0",
+ "gpio_range1",
+ "gpio_range2",
+ "gpio_range3",
+ "gpio_range4",
+ "gpio_range5";
+   ngpios = <200>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>,
+<21 217 3>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a29c279..17c1c92 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -230,6 +230,25 @@
};
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>,
+ < 96 0 0>,
+ < 160 0 0>;
+   gpio-ranges-group-names = "gpio_range0",
+ "gpio_range1",
+ "gpio_range2";
+   ngpios = <205>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>,
+<21 217 3>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
index 384729f..87cb290 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
@@ -178,6 +178,25 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>,
+ < 96 0 0>,
+ < 160 0 0>;
+   gpio-ranges-group-names = "gpio_range0",
+ "gpio_range1",
+ "gpio_range2";
+   ngpios = <286>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>,
+<21 217 3>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
-- 
2.7.4

[PATCH 3/6] ARM: dts: uniphier: route on-board device IRQ to GPIO controller

[Masahiro Yamada]

Interrupt lines from on-board devices are connected to the GPIO
controller.  Handle this correctly.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-ld4-ref.dts   | 2 +-
 arch/arm/boot/dts/uniphier-ld6b-ref.dts  | 2 +-
 arch/arm/boot/dts/uniphier-pro4-ref.dts  | 2 +-
 arch/arm/boot/dts/uniphier-sld8-ref.dts  | 2 +-
 arch/arm/boot/dts/uniphier-support-card.dtsi | 1 +
 5 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ld4-ref.dts 
b/arch/arm/boot/dts/uniphier-ld4-ref.dts
index b3aaab3..148e7bb 100644
--- a/arch/arm/boot/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld4-ref.dts
@@ -38,7 +38,7 @@
 };
 
  {
-   interrupts = <0 49 4>;
+   interrupts = <1 8>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-ld6b-ref.dts 
b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
index 2188d11..ec2a098 100644
--- a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
@@ -40,7 +40,7 @@
 };
 
  {
-   interrupts = <0 52 4>;
+   interrupts = <4 8>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-pro4-ref.dts 
b/arch/arm/boot/dts/uniphier-pro4-ref.dts
index 903df63..7316cc6 100644
--- a/arch/arm/boot/dts/uniphier-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-pro4-ref.dts
@@ -40,7 +40,7 @@
 };
 
  {
-   interrupts = <0 50 4>;
+   interrupts = <2 8>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-sld8-ref.dts 
b/arch/arm/boot/dts/uniphier-sld8-ref.dts
index 5accd3c..4ec48a1 100644
--- a/arch/arm/boot/dts/uniphier-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-sld8-ref.dts
@@ -38,7 +38,7 @@
 };
 
  {
-   interrupts = <0 48 4>;
+   interrupts = <0 8>;
 };
 
  {
diff --git a/arch/arm/boot/dts/uniphier-support-card.dtsi 
b/arch/arm/boot/dts/uniphier-support-card.dtsi
index 6c825f1..c6d99c4 100644
--- a/arch/arm/boot/dts/uniphier-support-card.dtsi
+++ b/arch/arm/boot/dts/uniphier-support-card.dtsi
@@ -16,6 +16,7 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x 1 0x01f0 0x0010>;
+   interrupt-parent = <>;
 
ethsc: ethernet@0 {
compatible = "smsc,lan9118", "smsc,lan9115";
-- 
2.7.4

[PATCH 4/6] arm64: dts: uniphier: route on-board device IRQ to GPIO controller

[Masahiro Yamada]

Interrupt lines from on-board devices are connected to the GPIO
controller.  Handle this correctly.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 3 ++-
 arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
index ffb473a..77f50fd 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
@@ -40,7 +40,8 @@
 };
 
  {
-   interrupts = <0 48 4>;
+   interrupt-parent = <>;
+   interrupts = <0 8>;
 };
 
  {
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
index 1ca0c86..1f55fe1 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
@@ -40,7 +40,8 @@
 };
 
  {
-   interrupts = <0 48 4>;
+   interrupt-parent = <>;
+   interrupts = <0 8>;
 };
 
  {
-- 
2.7.4

[PATCH 2/6] arm64: dts: uniphier: add GPIO controller nodes

[Masahiro Yamada]

The GPIO controller also acts as an interrupt controller and the
interrupt lines are connected to the AIDET block.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 25 
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 19 ++
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 19 ++
 3 files changed, 63 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index ee4aff5..99f14cc 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -161,6 +161,31 @@
};
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>,
+ < 43 0 0>,
+ < 51 0 0>,
+ < 96 0 0>,
+ < 160 0 0>,
+ < 184 0 0>;
+   gpio-ranges-group-names = "gpio_range0",
+ "gpio_range1",
+ "gpio_range2",
+ "gpio_range3",
+ "gpio_range4",
+ "gpio_range5";
+   ngpios = <200>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>,
+<21 217 3>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index a29c279..17c1c92 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -230,6 +230,25 @@
};
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>,
+ < 96 0 0>,
+ < 160 0 0>;
+   gpio-ranges-group-names = "gpio_range0",
+ "gpio_range1",
+ "gpio_range2";
+   ngpios = <205>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>,
+<21 217 3>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi 
b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
index 384729f..87cb290 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
@@ -178,6 +178,25 @@
clocks = <_clk 3>;
};
 
+   gpio: gpio@5500 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5500 0x200>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio-ranges = < 0 0 0>,
+ < 96 0 0>,
+ < 160 0 0>;
+   gpio-ranges-group-names = "gpio_range0",
+ "gpio_range1",
+ "gpio_range2";
+   ngpios = <286>;
+   socionext,interrupt-ranges = <0 48 16>, <16 154 5>,
+<21 217 3>;
+   };
+
i2c0: i2c@5878 {
compatible = "socionext,uniphier-fi2c";
status = "disabled";
-- 
2.7.4

[PATCH 0/6] ARM: dts: uniphier: add GPIO nodes and related properties

[Masahiro Yamada]

Masahiro Yamada (6):
  ARM: dts: uniphier: add GPIO controller nodes
  arm64: dts: uniphier: add GPIO controller nodes
  ARM: dts: uniphier: route on-board device IRQ to GPIO controller
  arm64: dts: uniphier: route on-board device IRQ to GPIO controller
  ARM: dts: uniphier: add GPIO hog definition
  arm64: dts: uniphier: add GPIO hog definition

 arch/arm/boot/dts/uniphier-ld4-ref.dts | 10 -
 arch/arm/boot/dts/uniphier-ld4.dtsi| 14 
 arch/arm/boot/dts/uniphier-ld6b-ref.dts| 10 -
 arch/arm/boot/dts/uniphier-pro4-ref.dts| 10 -
 arch/arm/boot/dts/uniphier-pro4.dtsi   | 14 
 arch/arm/boot/dts/uniphier-pro5.dtsi   | 14 
 arch/arm/boot/dts/uniphier-pxs2.dtsi   | 17 +++
 arch/arm/boot/dts/uniphier-sld8-ref.dts| 10 -
 arch/arm/boot/dts/uniphier-sld8.dtsi   | 18 
 arch/arm/boot/dts/uniphier-support-card.dtsi   |  1 +
 .../arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 11 +-
 arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi   | 25 ++
 .../arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 11 +-
 arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi   | 19 
 arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi   | 19 
 15 files changed, 197 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH 6/6] arm64: dts: uniphier: add GPIO hog definition

[Masahiro Yamada]

Interrupt lines from on-board devices are connected to the GPIO
controller.  Add GPIO hogging so that the corresponding GPIO line
is automatically requested.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts | 8 
 arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts | 8 
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
index 77f50fd..dd7193a 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-ref.dts
@@ -48,6 +48,14 @@
status = "okay";
 };
 
+ {
+   xirq0 {
+   gpio-hog;
+   gpios = <120 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts 
b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
index 1f55fe1..d99e373 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
@@ -48,6 +48,14 @@
status = "okay";
 };
 
+ {
+   xirq0 {
+   gpio-hog;
+   gpios = <120 0>;
+   input;
+   };
+};
+
  {
status = "okay";
 };
-- 
2.7.4

[PATCH v4] printk: hash addresses printed with %p

[Tobin C. Harding]

Currently there are many places in the kernel where addresses are being
printed using an unadorned %p. Kernel pointers should be printed using
%pK allowing some control via the kptr_restrict sysctl. Exposing addresses
gives attackers sensitive information about the kernel layout in memory.

We can reduce the attack surface by hashing all addresses printed with
%p. This will of course break some users, forcing code printing needed
addresses to be updated.

For what it's worth, usage of unadorned %p can be broken down as
follows (thanks to Joe Perches).

$ git grep -E '%p[^A-Za-z0-9]' | cut -f1 -d"/" | sort | uniq -c
   1084 arch
 20 block
 10 crypto
 32 Documentation
   8121 drivers
   1221 fs
143 include
101 kernel
 69 lib
100 mm
   1510 net
 40 samples
  7 scripts
 11 security
166 sound
152 tools
  2 virt

Add function ptr_to_id() to map an address to a 32 bit unique identifier.

Signed-off-by: Tobin C. Harding 
---

V4:
 - Remove changes to siphash.{ch}
 - Do word size check, and return value cast, directly in ptr_to_id().
 - Use add_ready_random_callback() to guard call to get_random_bytes()

V3:
 - Use atomic_xchg() to guard setting [random] key.
 - Remove erroneous white space change.

V2:
 - Use SipHash to do the hashing.

The discussion related to this patch has been fragmented. There are
three threads associated with this patch. Email threads by subject:

[PATCH] printk: hash addresses printed with %p
[PATCH 0/3] add %pX specifier
[kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

 lib/vsprintf.c | 74 +++---
 1 file changed, 71 insertions(+), 3 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 86c3385b9eb3..4609738cd2cd 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #ifdef CONFIG_BLOCK
 #include 
 #endif
@@ -1591,6 +1593,70 @@ char *device_node_string(char *buf, char *end, struct 
device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
 }
 
+/* protects ptr_secret and have_key */
+DEFINE_SPINLOCK(key_lock);
+static siphash_key_t ptr_secret __read_mostly;
+static atomic_t have_key = ATOMIC_INIT(0);
+
+static int initialize_ptr_secret(void)
+{
+   spin_lock(_lock);
+   if (atomic_read(_key) == 1)
+   goto unlock;
+
+   get_random_bytes(_secret, sizeof(ptr_secret));
+   atomic_set(_key, 1);
+
+unlock:
+   spin_unlock(_lock);
+   return 0;
+}
+
+static void schedule_async_key_init(struct random_ready_callback *rdy)
+{
+   initialize_ptr_secret();
+}
+
+/* Maps a pointer to a 32 bit unique identifier. */
+static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec 
spec)
+{
+   static struct random_ready_callback random_ready;
+   unsigned int hashval;
+   int err;
+
+   if (atomic_read(_key) == 0) {
+   random_ready.owner = NULL;
+   random_ready.func = schedule_async_key_init;
+
+   err = add_random_ready_callback(_ready);
+
+   switch (err) {
+   case 0:
+   return "(pointer value)";
+
+   case -EALREADY:
+   initialize_ptr_secret();
+   break;
+
+   default:
+   /* shouldn't get here */
+   return "(ptr_to_id() error)";
+   }
+   }
+
+#ifdef CONFIG_64BIT
+   hashval = (unsigned int)siphash_1u64((u64)ptr, _secret);
+#else
+   hashval = (unsigned int)siphash_1u32((u32)ptr, _secret);
+#endif
+
+   spec.field_width = 2 + 2 * sizeof(unsigned int); /* 0x + hex */
+   spec.flags = SPECIAL | SMALL | ZEROPAD;
+   spec.base = 16;
+
+   return number(buf, end, hashval, spec);
+}
+
 int kptr_restrict __read_mostly;
 
 /*
@@ -1703,6 +1769,9 @@ int kptr_restrict __read_mostly;
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a
  * pointer to the real address.
+ *
+ * Default behaviour (unadorned %p) is to hash the address, rendering it useful
+ * as a unique identifier.
  */
 static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1858,14 +1927,13 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,
return device_node_string(buf, end, ptr, spec, fmt + 1);
}
}
-   spec.flags |= SMALL;
+
if (spec.field_width == -1) {
spec.field_width = default_width;
spec.flags |= ZEROPAD;
}
-   spec.base = 16;
 
-   return number(buf, end, (unsigned long) ptr, spec);
+   return ptr_to_id(buf, end, ptr, spec);
 }
 
 /*
-- 
2.7.4

[PATCH v4] printk: hash addresses printed with %p

[Tobin C. Harding]

Currently there are many places in the kernel where addresses are being
printed using an unadorned %p. Kernel pointers should be printed using
%pK allowing some control via the kptr_restrict sysctl. Exposing addresses
gives attackers sensitive information about the kernel layout in memory.

We can reduce the attack surface by hashing all addresses printed with
%p. This will of course break some users, forcing code printing needed
addresses to be updated.

For what it's worth, usage of unadorned %p can be broken down as
follows (thanks to Joe Perches).

$ git grep -E '%p[^A-Za-z0-9]' | cut -f1 -d"/" | sort | uniq -c
   1084 arch
 20 block
 10 crypto
 32 Documentation
   8121 drivers
   1221 fs
143 include
101 kernel
 69 lib
100 mm
   1510 net
 40 samples
  7 scripts
 11 security
166 sound
152 tools
  2 virt

Add function ptr_to_id() to map an address to a 32 bit unique identifier.

Signed-off-by: Tobin C. Harding 
---

V4:
 - Remove changes to siphash.{ch}
 - Do word size check, and return value cast, directly in ptr_to_id().
 - Use add_ready_random_callback() to guard call to get_random_bytes()

V3:
 - Use atomic_xchg() to guard setting [random] key.
 - Remove erroneous white space change.

V2:
 - Use SipHash to do the hashing.

The discussion related to this patch has been fragmented. There are
three threads associated with this patch. Email threads by subject:

[PATCH] printk: hash addresses printed with %p
[PATCH 0/3] add %pX specifier
[kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

 lib/vsprintf.c | 74 +++---
 1 file changed, 71 insertions(+), 3 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 86c3385b9eb3..4609738cd2cd 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #ifdef CONFIG_BLOCK
 #include 
 #endif
@@ -1591,6 +1593,70 @@ char *device_node_string(char *buf, char *end, struct 
device_node *dn,
return widen_string(buf, buf - buf_start, end, spec);
 }
 
+/* protects ptr_secret and have_key */
+DEFINE_SPINLOCK(key_lock);
+static siphash_key_t ptr_secret __read_mostly;
+static atomic_t have_key = ATOMIC_INIT(0);
+
+static int initialize_ptr_secret(void)
+{
+   spin_lock(_lock);
+   if (atomic_read(_key) == 1)
+   goto unlock;
+
+   get_random_bytes(_secret, sizeof(ptr_secret));
+   atomic_set(_key, 1);
+
+unlock:
+   spin_unlock(_lock);
+   return 0;
+}
+
+static void schedule_async_key_init(struct random_ready_callback *rdy)
+{
+   initialize_ptr_secret();
+}
+
+/* Maps a pointer to a 32 bit unique identifier. */
+static char *ptr_to_id(char *buf, char *end, void *ptr, struct printf_spec 
spec)
+{
+   static struct random_ready_callback random_ready;
+   unsigned int hashval;
+   int err;
+
+   if (atomic_read(_key) == 0) {
+   random_ready.owner = NULL;
+   random_ready.func = schedule_async_key_init;
+
+   err = add_random_ready_callback(_ready);
+
+   switch (err) {
+   case 0:
+   return "(pointer value)";
+
+   case -EALREADY:
+   initialize_ptr_secret();
+   break;
+
+   default:
+   /* shouldn't get here */
+   return "(ptr_to_id() error)";
+   }
+   }
+
+#ifdef CONFIG_64BIT
+   hashval = (unsigned int)siphash_1u64((u64)ptr, _secret);
+#else
+   hashval = (unsigned int)siphash_1u32((u32)ptr, _secret);
+#endif
+
+   spec.field_width = 2 + 2 * sizeof(unsigned int); /* 0x + hex */
+   spec.flags = SPECIAL | SMALL | ZEROPAD;
+   spec.base = 16;
+
+   return number(buf, end, hashval, spec);
+}
+
 int kptr_restrict __read_mostly;
 
 /*
@@ -1703,6 +1769,9 @@ int kptr_restrict __read_mostly;
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a
  * pointer to the real address.
+ *
+ * Default behaviour (unadorned %p) is to hash the address, rendering it useful
+ * as a unique identifier.
  */
 static noinline_for_stack
 char *pointer(const char *fmt, char *buf, char *end, void *ptr,
@@ -1858,14 +1927,13 @@ char *pointer(const char *fmt, char *buf, char *end, 
void *ptr,
return device_node_string(buf, end, ptr, spec, fmt + 1);
}
}
-   spec.flags |= SMALL;
+
if (spec.field_width == -1) {
spec.field_width = default_width;
spec.flags |= ZEROPAD;
}
-   spec.base = 16;
 
-   return number(buf, end, (unsigned long) ptr, spec);
+   return ptr_to_id(buf, end, ptr, spec);
 }
 
 /*
-- 
2.7.4

Re: [PATCH] hfs/hfsplus: Clean up unused variables in bnode.c

[Ernesto A . Fernández]

On Sat, Oct 14, 2017 at 11:32:26AM +0100, Christos Gkekas wrote:
> Delete variables 'tree' and 'sb', which are set but never used.
> 
> Signed-off-by: Christos Gkekas 

Looks good. If it helps you can add:

Reviewed-by: Ernesto A. Fernández 

> ---
>  fs/hfs/bnode.c | 4 
>  fs/hfsplus/bnode.c | 4 
>  2 files changed, 8 deletions(-)
> 
> diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c
> index d77d844..8d618c9 100644
> --- a/fs/hfs/bnode.c
> +++ b/fs/hfs/bnode.c
> @@ -97,13 +97,11 @@ void hfs_bnode_clear(struct hfs_bnode *node, int off, int 
> len)
>  void hfs_bnode_copy(struct hfs_bnode *dst_node, int dst,
>   struct hfs_bnode *src_node, int src, int len)
>  {
> - struct hfs_btree *tree;
>   struct page *src_page, *dst_page;
>  
>   hfs_dbg(BNODE_MOD, "copybytes: %u,%u,%u\n", dst, src, len);
>   if (!len)
>   return;
> - tree = src_node->tree;
>   src += src_node->page_offset;
>   dst += dst_node->page_offset;
>   src_page = src_node->page[0];
> @@ -236,7 +234,6 @@ struct hfs_bnode *hfs_bnode_findhash(struct hfs_btree 
> *tree, u32 cnid)
>  
>  static struct hfs_bnode *__hfs_bnode_create(struct hfs_btree *tree, u32 cnid)
>  {
> - struct super_block *sb;
>   struct hfs_bnode *node, *node2;
>   struct address_space *mapping;
>   struct page *page;
> @@ -248,7 +245,6 @@ static struct hfs_bnode *__hfs_bnode_create(struct 
> hfs_btree *tree, u32 cnid)
>   return NULL;
>   }
>  
> - sb = tree->inode->i_sb;
>   size = sizeof(struct hfs_bnode) + tree->pages_per_bnode *
>   sizeof(struct page *);
>   node = kzalloc(size, GFP_KERNEL);
> diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c
> index ce014ce..9cd8b42 100644
> --- a/fs/hfsplus/bnode.c
> +++ b/fs/hfsplus/bnode.c
> @@ -126,14 +126,12 @@ void hfs_bnode_clear(struct hfs_bnode *node, int off, 
> int len)
>  void hfs_bnode_copy(struct hfs_bnode *dst_node, int dst,
>   struct hfs_bnode *src_node, int src, int len)
>  {
> - struct hfs_btree *tree;
>   struct page **src_page, **dst_page;
>   int l;
>  
>   hfs_dbg(BNODE_MOD, "copybytes: %u,%u,%u\n", dst, src, len);
>   if (!len)
>   return;
> - tree = src_node->tree;
>   src += src_node->page_offset;
>   dst += dst_node->page_offset;
>   src_page = src_node->page + (src >> PAGE_SHIFT);
> @@ -400,7 +398,6 @@ struct hfs_bnode *hfs_bnode_findhash(struct hfs_btree 
> *tree, u32 cnid)
>  
>  static struct hfs_bnode *__hfs_bnode_create(struct hfs_btree *tree, u32 cnid)
>  {
> - struct super_block *sb;
>   struct hfs_bnode *node, *node2;
>   struct address_space *mapping;
>   struct page *page;
> @@ -413,7 +410,6 @@ static struct hfs_bnode *__hfs_bnode_create(struct 
> hfs_btree *tree, u32 cnid)
>   return NULL;
>   }
>  
> - sb = tree->inode->i_sb;
>   size = sizeof(struct hfs_bnode) + tree->pages_per_bnode *
>   sizeof(struct page *);
>   node = kzalloc(size, GFP_KERNEL);
> -- 
> 2.7.4
> 

Re: [PATCH] hfs/hfsplus: Clean up unused variables in bnode.c

[Ernesto A . Fernández]

On Sat, Oct 14, 2017 at 11:32:26AM +0100, Christos Gkekas wrote:
> Delete variables 'tree' and 'sb', which are set but never used.
> 
> Signed-off-by: Christos Gkekas 

Looks good. If it helps you can add:

Reviewed-by: Ernesto A. Fernández 

> ---
>  fs/hfs/bnode.c | 4 
>  fs/hfsplus/bnode.c | 4 
>  2 files changed, 8 deletions(-)
> 
> diff --git a/fs/hfs/bnode.c b/fs/hfs/bnode.c
> index d77d844..8d618c9 100644
> --- a/fs/hfs/bnode.c
> +++ b/fs/hfs/bnode.c
> @@ -97,13 +97,11 @@ void hfs_bnode_clear(struct hfs_bnode *node, int off, int 
> len)
>  void hfs_bnode_copy(struct hfs_bnode *dst_node, int dst,
>   struct hfs_bnode *src_node, int src, int len)
>  {
> - struct hfs_btree *tree;
>   struct page *src_page, *dst_page;
>  
>   hfs_dbg(BNODE_MOD, "copybytes: %u,%u,%u\n", dst, src, len);
>   if (!len)
>   return;
> - tree = src_node->tree;
>   src += src_node->page_offset;
>   dst += dst_node->page_offset;
>   src_page = src_node->page[0];
> @@ -236,7 +234,6 @@ struct hfs_bnode *hfs_bnode_findhash(struct hfs_btree 
> *tree, u32 cnid)
>  
>  static struct hfs_bnode *__hfs_bnode_create(struct hfs_btree *tree, u32 cnid)
>  {
> - struct super_block *sb;
>   struct hfs_bnode *node, *node2;
>   struct address_space *mapping;
>   struct page *page;
> @@ -248,7 +245,6 @@ static struct hfs_bnode *__hfs_bnode_create(struct 
> hfs_btree *tree, u32 cnid)
>   return NULL;
>   }
>  
> - sb = tree->inode->i_sb;
>   size = sizeof(struct hfs_bnode) + tree->pages_per_bnode *
>   sizeof(struct page *);
>   node = kzalloc(size, GFP_KERNEL);
> diff --git a/fs/hfsplus/bnode.c b/fs/hfsplus/bnode.c
> index ce014ce..9cd8b42 100644
> --- a/fs/hfsplus/bnode.c
> +++ b/fs/hfsplus/bnode.c
> @@ -126,14 +126,12 @@ void hfs_bnode_clear(struct hfs_bnode *node, int off, 
> int len)
>  void hfs_bnode_copy(struct hfs_bnode *dst_node, int dst,
>   struct hfs_bnode *src_node, int src, int len)
>  {
> - struct hfs_btree *tree;
>   struct page **src_page, **dst_page;
>   int l;
>  
>   hfs_dbg(BNODE_MOD, "copybytes: %u,%u,%u\n", dst, src, len);
>   if (!len)
>   return;
> - tree = src_node->tree;
>   src += src_node->page_offset;
>   dst += dst_node->page_offset;
>   src_page = src_node->page + (src >> PAGE_SHIFT);
> @@ -400,7 +398,6 @@ struct hfs_bnode *hfs_bnode_findhash(struct hfs_btree 
> *tree, u32 cnid)
>  
>  static struct hfs_bnode *__hfs_bnode_create(struct hfs_btree *tree, u32 cnid)
>  {
> - struct super_block *sb;
>   struct hfs_bnode *node, *node2;
>   struct address_space *mapping;
>   struct page *page;
> @@ -413,7 +410,6 @@ static struct hfs_bnode *__hfs_bnode_create(struct 
> hfs_btree *tree, u32 cnid)
>   return NULL;
>   }
>  
> - sb = tree->inode->i_sb;
>   size = sizeof(struct hfs_bnode) + tree->pages_per_bnode *
>   sizeof(struct page *);
>   node = kzalloc(size, GFP_KERNEL);
> -- 
> 2.7.4
> 

Re: [PATCH] fat: remove redundant assignment of 0 to slots

[OGAWA Hirofumi]

Colin King  writes:

> From: Colin Ian King 
>
> The variable slots is being assigned a value of zero that is never
> read, slots is being updated again a few lines later. Remove this
> redundant assignment.
> Cleans clang warning: Value stored to 'slots' is never read
>
> Signed-off-by: Colin Ian King 

Looks like good (if old gcc didn't have false positive warning).

Acked-by: OGAWA Hirofumi 

> ---
>  fs/fat/dir.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/fs/fat/dir.c b/fs/fat/dir.c
> index 81cecbe6d7cf..b833ffeee1e1 100644
> --- a/fs/fat/dir.c
> +++ b/fs/fat/dir.c
> @@ -291,7 +291,6 @@ static int fat_parse_long(struct inode *dir, loff_t *pos,
>   }
>   }
>  parse_long:
> - slots = 0;
>   ds = (struct msdos_dir_slot *)*de;
>   id = ds->id;
>   if (!(id & 0x40))

-- 
OGAWA Hirofumi 

Re: [PATCH] fat: remove redundant assignment of 0 to slots

[OGAWA Hirofumi]

Colin King  writes:

> From: Colin Ian King 
>
> The variable slots is being assigned a value of zero that is never
> read, slots is being updated again a few lines later. Remove this
> redundant assignment.
> Cleans clang warning: Value stored to 'slots' is never read
>
> Signed-off-by: Colin Ian King 

Looks like good (if old gcc didn't have false positive warning).

Acked-by: OGAWA Hirofumi 

> ---
>  fs/fat/dir.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/fs/fat/dir.c b/fs/fat/dir.c
> index 81cecbe6d7cf..b833ffeee1e1 100644
> --- a/fs/fat/dir.c
> +++ b/fs/fat/dir.c
> @@ -291,7 +291,6 @@ static int fat_parse_long(struct inode *dir, loff_t *pos,
>   }
>   }
>  parse_long:
> - slots = 0;
>   ds = (struct msdos_dir_slot *)*de;
>   id = ds->id;
>   if (!(id & 0x40))

-- 
OGAWA Hirofumi 

Re: [PATCH] input: touchscreen: ti_am335x_tsc: Fix incorrect step config for 5 wire touchscreen

[Vignesh R]

On Tuesday 19 September 2017 11:59 AM, Vignesh R wrote:
> From: Jeff Lance 
> 
> Step config setting for 5 wire touchscreen is incorrect for Y coordinates.
> It was broken while we moved to DT. If you look close at the offending
> commit bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made
> configurable"), the change was:
> 
> - STEPCONFIG_XNP | STEPCONFIG_YPN;
> + ts_dev->bit_xn | ts_dev->bit_yp;
> 
> while bit_xn = STEPCONFIG_XNN and bit_yp = STEPCONFIG_YNN. Not quite the
> same.
> 
> Fixes: bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made 
> configurable")
> Signed-off-by: Jeff Lance 
> [vigne...@ti.com: Rebase to v4.14-rc1]
> Signed-off-by: Vignesh R 
> ---
> 

Gentle ping...


> Tested on AM335x EVM with 5 wire tsc module. Also sanity tested
> on a 4 wire tsc as well.
> 
>  drivers/input/touchscreen/ti_am335x_tsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
> b/drivers/input/touchscreen/ti_am335x_tsc.c
> index 7953381d939a..f1043ae71dcc 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -161,7 +161,7 @@ static void titsc_step_config(struct titsc *ts_dev)
>   break;
>   case 5:
>   config |= ts_dev->bit_xp | STEPCONFIG_INP_AN4 |
> - ts_dev->bit_xn | ts_dev->bit_yp;
> + STEPCONFIG_XNP | STEPCONFIG_YPN;
>   break;
>   case 8:
>   config |= ts_dev->bit_yp | STEPCONFIG_INP(ts_dev->inp_xp);
> 

-- 
Regards
Vignesh

Re: [PATCH] input: touchscreen: ti_am335x_tsc: Fix incorrect step config for 5 wire touchscreen

[Vignesh R]

On Tuesday 19 September 2017 11:59 AM, Vignesh R wrote:
> From: Jeff Lance 
> 
> Step config setting for 5 wire touchscreen is incorrect for Y coordinates.
> It was broken while we moved to DT. If you look close at the offending
> commit bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made
> configurable"), the change was:
> 
> - STEPCONFIG_XNP | STEPCONFIG_YPN;
> + ts_dev->bit_xn | ts_dev->bit_yp;
> 
> while bit_xn = STEPCONFIG_XNN and bit_yp = STEPCONFIG_YNN. Not quite the
> same.
> 
> Fixes: bb76dc09ddfc ("input: ti_am33x_tsc: Order of TSC wires, made 
> configurable")
> Signed-off-by: Jeff Lance 
> [vigne...@ti.com: Rebase to v4.14-rc1]
> Signed-off-by: Vignesh R 
> ---
> 

Gentle ping...


> Tested on AM335x EVM with 5 wire tsc module. Also sanity tested
> on a 4 wire tsc as well.
> 
>  drivers/input/touchscreen/ti_am335x_tsc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c 
> b/drivers/input/touchscreen/ti_am335x_tsc.c
> index 7953381d939a..f1043ae71dcc 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -161,7 +161,7 @@ static void titsc_step_config(struct titsc *ts_dev)
>   break;
>   case 5:
>   config |= ts_dev->bit_xp | STEPCONFIG_INP_AN4 |
> - ts_dev->bit_xn | ts_dev->bit_yp;
> + STEPCONFIG_XNP | STEPCONFIG_YPN;
>   break;
>   case 8:
>   config |= ts_dev->bit_yp | STEPCONFIG_INP(ts_dev->inp_xp);
> 

-- 
Regards
Vignesh

Re: [PATCH 1/2] CLK: SPEAr: make structure field and function argument as const

[Viresh Kumar]

On 17-10-17, 16:42, Julia Lawall wrote:
> 
> 
> On Tue, 17 Oct 2017, Bhumika Goyal wrote:
> 
> > Make the masks field of clk_aux structure const as it do not modify the
> > fields of the aux_clk_masks structure it points to.
> >
> > Make the struct aux_clk_masks *aux argument of the function
> > clk_register_aux as const as the argument is only stored in the masks
> > field of a clk_aux structure which is now made const.
> >
> > Signed-off-by: Bhumika Goyal 
> > ---
> >  drivers/clk/spear/clk-aux-synth.c | 2 +-
> >  drivers/clk/spear/clk.h   | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/clk/spear/clk-aux-synth.c 
> > b/drivers/clk/spear/clk-aux-synth.c
> > index f271c35..8bea5df 100644
> > --- a/drivers/clk/spear/clk-aux-synth.c
> > +++ b/drivers/clk/spear/clk-aux-synth.c
> > @@ -136,7 +136,7 @@ static int clk_aux_set_rate(struct clk_hw *hw, unsigned 
> > long drate,
> >
> >  struct clk *clk_register_aux(const char *aux_name, const char *gate_name,
> > const char *parent_name, unsigned long flags, void __iomem *reg,
> > -   struct aux_clk_masks *masks, struct aux_rate_tbl *rtbl,
> > +   const struct aux_clk_masks *masks, struct aux_rate_tbl *rtbl,
> > u8 rtbl_cnt, spinlock_t *lock, struct clk **gate_clk)
> >  {
> > struct clk_aux *aux;
> > diff --git a/drivers/clk/spear/clk.h b/drivers/clk/spear/clk.h
> > index 9834944..b9d28b3 100644
> > --- a/drivers/clk/spear/clk.h
> > +++ b/drivers/clk/spear/clk.h
> > @@ -49,7 +49,7 @@ struct aux_rate_tbl {
> >  struct clk_aux {
> > struct  clk_hw hw;
> > void __iomem*reg;
> > -   struct aux_clk_masks*masks;
> > +const struct aux_clk_masks *masks;
> 
> There are spaces before const here.

Fix that and add my:

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 1/2] CLK: SPEAr: make structure field and function argument as const

[Viresh Kumar]

On 17-10-17, 16:42, Julia Lawall wrote:
> 
> 
> On Tue, 17 Oct 2017, Bhumika Goyal wrote:
> 
> > Make the masks field of clk_aux structure const as it do not modify the
> > fields of the aux_clk_masks structure it points to.
> >
> > Make the struct aux_clk_masks *aux argument of the function
> > clk_register_aux as const as the argument is only stored in the masks
> > field of a clk_aux structure which is now made const.
> >
> > Signed-off-by: Bhumika Goyal 
> > ---
> >  drivers/clk/spear/clk-aux-synth.c | 2 +-
> >  drivers/clk/spear/clk.h   | 4 ++--
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/clk/spear/clk-aux-synth.c 
> > b/drivers/clk/spear/clk-aux-synth.c
> > index f271c35..8bea5df 100644
> > --- a/drivers/clk/spear/clk-aux-synth.c
> > +++ b/drivers/clk/spear/clk-aux-synth.c
> > @@ -136,7 +136,7 @@ static int clk_aux_set_rate(struct clk_hw *hw, unsigned 
> > long drate,
> >
> >  struct clk *clk_register_aux(const char *aux_name, const char *gate_name,
> > const char *parent_name, unsigned long flags, void __iomem *reg,
> > -   struct aux_clk_masks *masks, struct aux_rate_tbl *rtbl,
> > +   const struct aux_clk_masks *masks, struct aux_rate_tbl *rtbl,
> > u8 rtbl_cnt, spinlock_t *lock, struct clk **gate_clk)
> >  {
> > struct clk_aux *aux;
> > diff --git a/drivers/clk/spear/clk.h b/drivers/clk/spear/clk.h
> > index 9834944..b9d28b3 100644
> > --- a/drivers/clk/spear/clk.h
> > +++ b/drivers/clk/spear/clk.h
> > @@ -49,7 +49,7 @@ struct aux_rate_tbl {
> >  struct clk_aux {
> > struct  clk_hw hw;
> > void __iomem*reg;
> > -   struct aux_clk_masks*masks;
> > +const struct aux_clk_masks *masks;
> 
> There are spaces before const here.

Fix that and add my:

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v4 3/3] livepatch: add atomic replace

[Jason Baron]

On 10/17/2017 10:18 AM, Petr Mladek wrote:
> On Thu 2017-10-12 17:12:29, Jason Baron wrote:
>> Sometimes we would like to revert a particular fix. This is currently
>> This is not easy because we want to keep all other fixes active and we
>> could revert only the last applied patch.
>>
>> One solution would be to apply new patch that implemented all
>> the reverted functions like in the original code. It would work
>> as expected but there will be unnecessary redirections. In addition,
>> it would also require knowing which functions need to be reverted at
>> build time.
>>
>> A better solution would be to say that a new patch replaces
>> an older one. This might be complicated if we want to replace
>> a particular patch. But it is rather easy when a new cummulative
>> patch replaces all others.
>>
>> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
>> index f53eed5..d1c7a06 100644
>> --- a/kernel/livepatch/core.c
>> +++ b/kernel/livepatch/core.c
>> @@ -283,8 +301,21 @@ static int klp_write_object_relocations(struct module 
>> *pmod,
>>  return ret;
>>  }
>>  
>> +atomic_t klp_nop_release_count;
>> +static DECLARE_WAIT_QUEUE_HEAD(klp_nop_release_wait);
>> +
>>  static void klp_kobj_release_object(struct kobject *kobj)
>>  {
>> +struct klp_object *obj;
>> +
>> +obj = container_of(kobj, struct klp_object, kobj);
>> +/* Free dynamically allocated object */
>> +if (!obj->funcs) {
>> +kfree(obj->name);
>> +kfree(obj);
>> +atomic_dec(_nop_release_count);
>> +wake_up(_nop_release_wait);
> 
> I would slightly optimize this by
> 
>   if (atomic_dec_and_test((_nop_release_count))
>   wake_up(_nop_release_wait);
> 
>> +}
>>  }
>>  
>>  static struct kobj_type klp_ktype_object = {
>> @@ -294,6 +325,16 @@ static struct kobj_type klp_ktype_object = {
>>  
>>  static void klp_kobj_release_func(struct kobject *kobj)
>>  {
>> +struct klp_func *func;
>> +
>> +func = container_of(kobj, struct klp_func, kobj);
>> +/* Free dynamically allocated functions */
>> +if (!func->new_func) {
>> +kfree(func->old_name);
>> +kfree(func);
>> +atomic_dec(_nop_release_count);
>> +wake_up(_nop_release_wait);
> 
> Same here
> 
>   if (atomic_dec_and_test((_nop_release_count))
>   wake_up(_nop_release_wait);
> 
> 
>> +}
>>  }
>>  
>>  static struct kobj_type klp_ktype_func = {
>> @@ -436,8 +480,14 @@ static int klp_init_object(struct klp_patch *patch, 
>> struct klp_object *obj)
>>  if (ret)
>>  return ret;
>>  
>> -klp_for_each_func(obj, func) {
>> -ret = klp_init_func(obj, func);
>> +list_add(>obj_entry, >obj_list);
>> +INIT_LIST_HEAD(>func_list);
>> +
>> +if (nop)
>> +return 0;
> 
> Ah, this is something that I wanted to avoid. It makes the code
> very hard to read and maintain. It forces us to duplicate
> some code in klp_alloc_nop_func(). I think that I complained
> about this in v2 already.
> 
> I understand that you actually kept it because of me.
> It is related to the possibility to re-enable released
> patches :-(

hmmm, I actually think that it is not necessary - although I didn't try
removing it. I was concerned that we would call klp_init_func() for
functions that were already initialized. However, this only called right
after creating a brand new object, so there are no associated functions,
and thus I think the above early return is not necessary. I can try
removing it.

> 
> The klp_init_*() stuff is called from __klp_enable_patch()
> for the "nop" functions now. And it has already been called
> for the statically defined structures in klp_register_patch().
> Therefore we need to avoid calling it twice for the static
> structures.
> 
> One solution would be to do these operations for the statically
> defined structures in __klp_enable_patch() as well. But this
> would mean a big redesign of the code.
> 
> Another solution would be to give up on the idea that the replaced
> patches might be re-enabled without re-loading. I am afraid
> that this the only reasonable approach. It will help to avoid
> also the extra klp_replaced_patches list. All this will help to
> make the code much easier.
> 

It seems like the consensus is to abandon re-enable and go back to
rmmod/insmod for revert. I do like the rmmod/insmod revert path in that
it keeps module list smaller. However, there are cases where that is not
possible, but it sounds like in the interest of keeping the code simpler
for the common case, revert would not be possible in those cases, and we
would simply have to add a new livepatch module in those cases to fix
things.

Thanks,

-Jason

Re: [PATCH 2/2] CLK: SPEAr: make aux_clk_masks structures const

[Viresh Kumar]

On 17-10-17, 16:38, Bhumika Goyal wrote:
> Make these const as they are either stored in the masks 'const' field
> of a clk_aux structure or passed to the function clk_register_aux 
> having the argument as const.
> 
> Signed-off-by: Bhumika Goyal 
> ---
>  drivers/clk/spear/clk-aux-synth.c   | 2 +-
>  drivers/clk/spear/spear1310_clock.c | 2 +-
>  drivers/clk/spear/spear1340_clock.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/spear/clk-aux-synth.c 
> b/drivers/clk/spear/clk-aux-synth.c
> index 8bea5df..2f145e3 100644
> --- a/drivers/clk/spear/clk-aux-synth.c
> +++ b/drivers/clk/spear/clk-aux-synth.c
> @@ -29,7 +29,7 @@
>  
>  #define to_clk_aux(_hw) container_of(_hw, struct clk_aux, hw)
>  
> -static struct aux_clk_masks default_aux_masks = {
> +static const  struct aux_clk_masks default_aux_masks = {
>   .eq_sel_mask = AUX_EQ_SEL_MASK,
>   .eq_sel_shift = AUX_EQ_SEL_SHIFT,
>   .eq1_mask = AUX_EQ1_SEL,
> diff --git a/drivers/clk/spear/spear1310_clock.c 
> b/drivers/clk/spear/spear1310_clock.c
> index 2f86e3f..591248c 100644
> --- a/drivers/clk/spear/spear1310_clock.c
> +++ b/drivers/clk/spear/spear1310_clock.c
> @@ -284,7 +284,7 @@
>  };
>  
>  /* i2s prescaler1 masks */
> -static struct aux_clk_masks i2s_prs1_masks = {
> +static const struct aux_clk_masks i2s_prs1_masks = {
>   .eq_sel_mask = AUX_EQ_SEL_MASK,
>   .eq_sel_shift = SPEAR1310_I2S_PRS1_EQ_SEL_SHIFT,
>   .eq1_mask = AUX_EQ1_SEL,
> diff --git a/drivers/clk/spear/spear1340_clock.c 
> b/drivers/clk/spear/spear1340_clock.c
> index cbb19a9..e5bc8c8 100644
> --- a/drivers/clk/spear/spear1340_clock.c
> +++ b/drivers/clk/spear/spear1340_clock.c
> @@ -323,7 +323,7 @@
>  };
>  
>  /* i2s prescaler1 masks */
> -static struct aux_clk_masks i2s_prs1_masks = {
> +static const struct aux_clk_masks i2s_prs1_masks = {
>   .eq_sel_mask = AUX_EQ_SEL_MASK,
>   .eq_sel_shift = SPEAR1340_I2S_PRS1_EQ_SEL_SHIFT,
>   .eq1_mask = AUX_EQ1_SEL,

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v4 3/3] livepatch: add atomic replace

[Jason Baron]

On 10/17/2017 10:18 AM, Petr Mladek wrote:
> On Thu 2017-10-12 17:12:29, Jason Baron wrote:
>> Sometimes we would like to revert a particular fix. This is currently
>> This is not easy because we want to keep all other fixes active and we
>> could revert only the last applied patch.
>>
>> One solution would be to apply new patch that implemented all
>> the reverted functions like in the original code. It would work
>> as expected but there will be unnecessary redirections. In addition,
>> it would also require knowing which functions need to be reverted at
>> build time.
>>
>> A better solution would be to say that a new patch replaces
>> an older one. This might be complicated if we want to replace
>> a particular patch. But it is rather easy when a new cummulative
>> patch replaces all others.
>>
>> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
>> index f53eed5..d1c7a06 100644
>> --- a/kernel/livepatch/core.c
>> +++ b/kernel/livepatch/core.c
>> @@ -283,8 +301,21 @@ static int klp_write_object_relocations(struct module 
>> *pmod,
>>  return ret;
>>  }
>>  
>> +atomic_t klp_nop_release_count;
>> +static DECLARE_WAIT_QUEUE_HEAD(klp_nop_release_wait);
>> +
>>  static void klp_kobj_release_object(struct kobject *kobj)
>>  {
>> +struct klp_object *obj;
>> +
>> +obj = container_of(kobj, struct klp_object, kobj);
>> +/* Free dynamically allocated object */
>> +if (!obj->funcs) {
>> +kfree(obj->name);
>> +kfree(obj);
>> +atomic_dec(_nop_release_count);
>> +wake_up(_nop_release_wait);
> 
> I would slightly optimize this by
> 
>   if (atomic_dec_and_test((_nop_release_count))
>   wake_up(_nop_release_wait);
> 
>> +}
>>  }
>>  
>>  static struct kobj_type klp_ktype_object = {
>> @@ -294,6 +325,16 @@ static struct kobj_type klp_ktype_object = {
>>  
>>  static void klp_kobj_release_func(struct kobject *kobj)
>>  {
>> +struct klp_func *func;
>> +
>> +func = container_of(kobj, struct klp_func, kobj);
>> +/* Free dynamically allocated functions */
>> +if (!func->new_func) {
>> +kfree(func->old_name);
>> +kfree(func);
>> +atomic_dec(_nop_release_count);
>> +wake_up(_nop_release_wait);
> 
> Same here
> 
>   if (atomic_dec_and_test((_nop_release_count))
>   wake_up(_nop_release_wait);
> 
> 
>> +}
>>  }
>>  
>>  static struct kobj_type klp_ktype_func = {
>> @@ -436,8 +480,14 @@ static int klp_init_object(struct klp_patch *patch, 
>> struct klp_object *obj)
>>  if (ret)
>>  return ret;
>>  
>> -klp_for_each_func(obj, func) {
>> -ret = klp_init_func(obj, func);
>> +list_add(>obj_entry, >obj_list);
>> +INIT_LIST_HEAD(>func_list);
>> +
>> +if (nop)
>> +return 0;
> 
> Ah, this is something that I wanted to avoid. It makes the code
> very hard to read and maintain. It forces us to duplicate
> some code in klp_alloc_nop_func(). I think that I complained
> about this in v2 already.
> 
> I understand that you actually kept it because of me.
> It is related to the possibility to re-enable released
> patches :-(

hmmm, I actually think that it is not necessary - although I didn't try
removing it. I was concerned that we would call klp_init_func() for
functions that were already initialized. However, this only called right
after creating a brand new object, so there are no associated functions,
and thus I think the above early return is not necessary. I can try
removing it.

> 
> The klp_init_*() stuff is called from __klp_enable_patch()
> for the "nop" functions now. And it has already been called
> for the statically defined structures in klp_register_patch().
> Therefore we need to avoid calling it twice for the static
> structures.
> 
> One solution would be to do these operations for the statically
> defined structures in __klp_enable_patch() as well. But this
> would mean a big redesign of the code.
> 
> Another solution would be to give up on the idea that the replaced
> patches might be re-enabled without re-loading. I am afraid
> that this the only reasonable approach. It will help to avoid
> also the extra klp_replaced_patches list. All this will help to
> make the code much easier.
> 

It seems like the consensus is to abandon re-enable and go back to
rmmod/insmod for revert. I do like the rmmod/insmod revert path in that
it keeps module list smaller. However, there are cases where that is not
possible, but it sounds like in the interest of keeping the code simpler
for the common case, revert would not be possible in those cases, and we
would simply have to add a new livepatch module in those cases to fix
things.

Thanks,

-Jason

Re: [PATCH 2/2] CLK: SPEAr: make aux_clk_masks structures const

[Viresh Kumar]

On 17-10-17, 16:38, Bhumika Goyal wrote:
> Make these const as they are either stored in the masks 'const' field
> of a clk_aux structure or passed to the function clk_register_aux 
> having the argument as const.
> 
> Signed-off-by: Bhumika Goyal 
> ---
>  drivers/clk/spear/clk-aux-synth.c   | 2 +-
>  drivers/clk/spear/spear1310_clock.c | 2 +-
>  drivers/clk/spear/spear1340_clock.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/spear/clk-aux-synth.c 
> b/drivers/clk/spear/clk-aux-synth.c
> index 8bea5df..2f145e3 100644
> --- a/drivers/clk/spear/clk-aux-synth.c
> +++ b/drivers/clk/spear/clk-aux-synth.c
> @@ -29,7 +29,7 @@
>  
>  #define to_clk_aux(_hw) container_of(_hw, struct clk_aux, hw)
>  
> -static struct aux_clk_masks default_aux_masks = {
> +static const  struct aux_clk_masks default_aux_masks = {
>   .eq_sel_mask = AUX_EQ_SEL_MASK,
>   .eq_sel_shift = AUX_EQ_SEL_SHIFT,
>   .eq1_mask = AUX_EQ1_SEL,
> diff --git a/drivers/clk/spear/spear1310_clock.c 
> b/drivers/clk/spear/spear1310_clock.c
> index 2f86e3f..591248c 100644
> --- a/drivers/clk/spear/spear1310_clock.c
> +++ b/drivers/clk/spear/spear1310_clock.c
> @@ -284,7 +284,7 @@
>  };
>  
>  /* i2s prescaler1 masks */
> -static struct aux_clk_masks i2s_prs1_masks = {
> +static const struct aux_clk_masks i2s_prs1_masks = {
>   .eq_sel_mask = AUX_EQ_SEL_MASK,
>   .eq_sel_shift = SPEAR1310_I2S_PRS1_EQ_SEL_SHIFT,
>   .eq1_mask = AUX_EQ1_SEL,
> diff --git a/drivers/clk/spear/spear1340_clock.c 
> b/drivers/clk/spear/spear1340_clock.c
> index cbb19a9..e5bc8c8 100644
> --- a/drivers/clk/spear/spear1340_clock.c
> +++ b/drivers/clk/spear/spear1340_clock.c
> @@ -323,7 +323,7 @@
>  };
>  
>  /* i2s prescaler1 masks */
> -static struct aux_clk_masks i2s_prs1_masks = {
> +static const struct aux_clk_masks i2s_prs1_masks = {
>   .eq_sel_mask = AUX_EQ_SEL_MASK,
>   .eq_sel_shift = SPEAR1340_I2S_PRS1_EQ_SEL_SHIFT,
>   .eq1_mask = AUX_EQ1_SEL,

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 18/20] staging: lustre: osc: mark expected switch fall-through

[Dilger, Andreas]

On Oct 12, 2017, at 10:17, Gustavo A. R. Silva  wrote:
> 
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Addresses-Coverity-ID: 1077598
> Signed-off-by: Gustavo A. R. Silva 

Reviewed-by: Andreas Dilger 

> ---
> drivers/staging/lustre/lustre/osc/osc_cache.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c 
> b/drivers/staging/lustre/lustre/osc/osc_cache.c
> index e1207c2..eab7759 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_cache.c
> +++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
> @@ -227,6 +227,7 @@ static int osc_extent_sanity_check0(struct osc_extent 
> *ext,
>   rc = 65;
>   goto out;
>   }
> + /* fall through */
>   default:
>   if (atomic_read(>oe_users) > 0) {
>   rc = 70;
> -- 
> 2.7.4
> 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH 18/20] staging: lustre: osc: mark expected switch fall-through

[Dilger, Andreas]

On Oct 12, 2017, at 10:17, Gustavo A. R. Silva  wrote:
> 
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Addresses-Coverity-ID: 1077598
> Signed-off-by: Gustavo A. R. Silva 

Reviewed-by: Andreas Dilger 

> ---
> drivers/staging/lustre/lustre/osc/osc_cache.c | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c 
> b/drivers/staging/lustre/lustre/osc/osc_cache.c
> index e1207c2..eab7759 100644
> --- a/drivers/staging/lustre/lustre/osc/osc_cache.c
> +++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
> @@ -227,6 +227,7 @@ static int osc_extent_sanity_check0(struct osc_extent 
> *ext,
>   rc = 65;
>   goto out;
>   }
> + /* fall through */
>   default:
>   if (atomic_read(>oe_users) > 0) {
>   rc = 70;
> -- 
> 2.7.4
> 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH v3 2/2] livepatch: add atomic replace

[Jason Baron]

On 10/17/2017 09:50 AM, Miroslav Benes wrote:
> On Tue, 17 Oct 2017, Miroslav Benes wrote:
> 
>> On Tue, 10 Oct 2017, Jason Baron wrote:
>>
>>>
>>>
>>> On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
 On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
> Since 'atomic replace' has completely replaced all previous livepatch
> modules, it explicitly disables all previous livepatch modules. However,
> previous livepatch modules that have been replaced, can be re-enabled
> if they have the 'replace' flag set. In this case the set of 'nop'
> functions is re-calculated, such that it replaces all others.
>
> For example, if kpatch-a.ko and kpatch-b.ko have the 'replace' flag set
> then:
>
> # insmod kpatch-a.ko
> # insmod kpatch-b.ko
>
> At this point we have:
>
> # cat /sys/kernel/livepatch/kpatch-a/enabled
> 0
>
> # cat /sys/kernel/livepatch/kpatch-b/enabled
> 1
>
> To revert to the kpatch-a state we can do:
>
> echo 1 > /sys/kernel/livepatch/kpatch-a/enabled
>
> And now we have:
>
> # cat /sys/kernel/livepatch/kpatch-a/enabled
> 1
>
> # cat /sys/kernel/livepatch/kpatch-b/enabled
> 0

 I don't really like allowing a previously replaced patch to replace the
 current patch.  It's just more unnecessary complexity.  If the user
 wants to atomically revert back to kpatch-a, they should be able to:

   rmmod kpatch-a
   insmod kpatch-a.ko

>>
>> I agree.
>>  
>>> Right - that's how I sent v1 (using rmmod/insmod to revert), but it
>>> didn't account for the fact the patch or some functions may be marked
>>> 'immediate' and thus its not possible to just do 'rmmod'. Thus, since in
>>> some cases 'rmmod' was not feasible, I thought it would be simpler from
>>> an operational pov to just say we always revert by re-enabling a
>>> previously replaced patch as opposed to rmmod/insmod.
>>>
>>>
> Note that it may be possible to unload (rmmod) replaced patches in some
> cases based on the consistency model, when we know that all the functions
> that are contained in the patch may no longer be in used, however its
> left as future work, if this functionality is desired.

 If you don't allow a previously replaced patch to be enabled again, I
 think it would be trivial to let it be unloaded.

>>>
>>> The concern is around being replaced by 'immediate' functions and thus
>>> not knowing if the code is still in use.
>>
>> Hm. Would it make sense to remove immediate and rely only on the 
>> consistency model? At least for the architectures where the model is 
>> implemented (x86_64)?
>>
>> If not, then I'd keep such modules there without a possibility to remove 
>> them ever. If its functionality was required again, it would of course 
>> mean to insmod a new module with it.
> 
> Petr pointed out (offline) that immediate could still be useful. So let me 
> describe how I envision the whole atomic replace semantics.
> 
> Let's have three functions - a, b, c. Patch 1 is immediate and patches 
> a().
> 
> func  a   b   c
> patches   1i
> 
> Patch 2 is not immediate and patches b()
> 
> func  a   b   c
> patches   1i
>   2
> 
> Patch 3 is atomic replace, which patches a() and c().
> 
> func  a   b   c
> patches   1i
>   2
>   3r  3r
> 
> With 3 applied, 3versions of a() and c() are called, original b() is
> called. 2 can be rmmoded. 1 cannot, because it is immediate. 1 and 2
> cannot be reenabled.

Yes, if we change back to allowing the 'atomic replace' patch to drop
the module reference on previous modules when possible, then yes 2 can
be rmmoded. I originally started off with that model of being able to do
'revert' via rmmod and insmod of previous modules, but then we moved to
a re-enable model in v4 based on the fact that in some cases we can not
do the rmmod and insmod thing. For example if patch 3 was an immediate
patch, then we would replace function b 'immediately' and thus not know
when it was safe to rmmod patch 2. And in fact, in your example i think
its safe to rmmod patch 1 as well, since in the transition to patch 3 we
would have checked the func stack for the immediately preceding function
for function a which would have been 1i, and thus since we know its not
running we can rmmod patch 1 as well.

I'm happy to go back to rmmod/insmod for revert which seems to be the
consensus here - it certainly helps clean up and avoid large stacks of
modules (in most cases), which is nice.

> 
> 3 can be disabled. Original a() and c() will be called in such case. If
> one wants to have a() from patch 1 there, he would need to apply patch
> 4.
> 
> func  a   b   c
> patches   1i
>   2
>   3r  3r
>   4i
> 
> Does 

Re: [PATCH v3 2/2] livepatch: add atomic replace

[Jason Baron]

On 10/17/2017 09:50 AM, Miroslav Benes wrote:
> On Tue, 17 Oct 2017, Miroslav Benes wrote:
> 
>> On Tue, 10 Oct 2017, Jason Baron wrote:
>>
>>>
>>>
>>> On 10/06/2017 06:32 PM, Josh Poimboeuf wrote:
 On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote:
> Since 'atomic replace' has completely replaced all previous livepatch
> modules, it explicitly disables all previous livepatch modules. However,
> previous livepatch modules that have been replaced, can be re-enabled
> if they have the 'replace' flag set. In this case the set of 'nop'
> functions is re-calculated, such that it replaces all others.
>
> For example, if kpatch-a.ko and kpatch-b.ko have the 'replace' flag set
> then:
>
> # insmod kpatch-a.ko
> # insmod kpatch-b.ko
>
> At this point we have:
>
> # cat /sys/kernel/livepatch/kpatch-a/enabled
> 0
>
> # cat /sys/kernel/livepatch/kpatch-b/enabled
> 1
>
> To revert to the kpatch-a state we can do:
>
> echo 1 > /sys/kernel/livepatch/kpatch-a/enabled
>
> And now we have:
>
> # cat /sys/kernel/livepatch/kpatch-a/enabled
> 1
>
> # cat /sys/kernel/livepatch/kpatch-b/enabled
> 0

 I don't really like allowing a previously replaced patch to replace the
 current patch.  It's just more unnecessary complexity.  If the user
 wants to atomically revert back to kpatch-a, they should be able to:

   rmmod kpatch-a
   insmod kpatch-a.ko

>>
>> I agree.
>>  
>>> Right - that's how I sent v1 (using rmmod/insmod to revert), but it
>>> didn't account for the fact the patch or some functions may be marked
>>> 'immediate' and thus its not possible to just do 'rmmod'. Thus, since in
>>> some cases 'rmmod' was not feasible, I thought it would be simpler from
>>> an operational pov to just say we always revert by re-enabling a
>>> previously replaced patch as opposed to rmmod/insmod.
>>>
>>>
> Note that it may be possible to unload (rmmod) replaced patches in some
> cases based on the consistency model, when we know that all the functions
> that are contained in the patch may no longer be in used, however its
> left as future work, if this functionality is desired.

 If you don't allow a previously replaced patch to be enabled again, I
 think it would be trivial to let it be unloaded.

>>>
>>> The concern is around being replaced by 'immediate' functions and thus
>>> not knowing if the code is still in use.
>>
>> Hm. Would it make sense to remove immediate and rely only on the 
>> consistency model? At least for the architectures where the model is 
>> implemented (x86_64)?
>>
>> If not, then I'd keep such modules there without a possibility to remove 
>> them ever. If its functionality was required again, it would of course 
>> mean to insmod a new module with it.
> 
> Petr pointed out (offline) that immediate could still be useful. So let me 
> describe how I envision the whole atomic replace semantics.
> 
> Let's have three functions - a, b, c. Patch 1 is immediate and patches 
> a().
> 
> func  a   b   c
> patches   1i
> 
> Patch 2 is not immediate and patches b()
> 
> func  a   b   c
> patches   1i
>   2
> 
> Patch 3 is atomic replace, which patches a() and c().
> 
> func  a   b   c
> patches   1i
>   2
>   3r  3r
> 
> With 3 applied, 3versions of a() and c() are called, original b() is
> called. 2 can be rmmoded. 1 cannot, because it is immediate. 1 and 2
> cannot be reenabled.

Yes, if we change back to allowing the 'atomic replace' patch to drop
the module reference on previous modules when possible, then yes 2 can
be rmmoded. I originally started off with that model of being able to do
'revert' via rmmod and insmod of previous modules, but then we moved to
a re-enable model in v4 based on the fact that in some cases we can not
do the rmmod and insmod thing. For example if patch 3 was an immediate
patch, then we would replace function b 'immediately' and thus not know
when it was safe to rmmod patch 2. And in fact, in your example i think
its safe to rmmod patch 1 as well, since in the transition to patch 3 we
would have checked the func stack for the immediately preceding function
for function a which would have been 1i, and thus since we know its not
running we can rmmod patch 1 as well.

I'm happy to go back to rmmod/insmod for revert which seems to be the
consensus here - it certainly helps clean up and avoid large stacks of
modules (in most cases), which is nice.

> 
> 3 can be disabled. Original a() and c() will be called in such case. If
> one wants to have a() from patch 1 there, he would need to apply patch
> 4.
> 
> func  a   b   c
> patches   1i
>   2
>   3r  3r
>   4i
> 
> Does 

Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same core id

[Shu Wang]

> From: "Guenter Roeck" 
> To: shuw...@redhat.com
> Cc: "fenghua yu" , jdelv...@suse.com, 
> linux-hw...@vger.kernel.org,
> linux-kernel@vger.kernel.org, ch...@redhat.com, yiz...@redhat.com
> Sent: Tuesday, October 17, 2017 11:25:50 PM
> Subject: Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same 
> core id
> 
> On Tue, Oct 17, 2017 at 04:44:50PM +0800, shuw...@redhat.com wrote:
> > From: Shu Wang 
> > 
> > Fix kernel warning on my 4cpus 2core_id system. The cpu0 and cpu1 have
> > same core_id 0, so both cpu0 and cpu1 will try to create file temp2_label
> > when it's online.
> > 
> What system/cpu is that ?
> 
> Normally I would assume that each CPU (package) instantiates
> a separate instance of the driver.

The system is ThinkPad X1 Carbon 3rd laptop, model 20BTS1N70F.

> 
> > - coretemp_cpu_online(cpu=0)
> >   - create_core_data(cpu=0, attr_no=2)
> >- create_core_attrs(attr_no=2)
> > - coretemp_cpu_online(cpu=1)
> >   - create_core_data(cpu=1, attr_no=2)
> >- create_core_attrs(attr_no=2)
> > 
> > $ grep -e processor -e 'core id' /proc/cpuinfo
> > processor   : 0
> > core id : 0
> > processor   : 1
> > core id : 0
> > processor   : 2
> > core id : 1
> > processor   : 3
> > core id : 1
> 
> Complete output of /proc/cpuinfo might be helpful.

$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
stepping: 4
microcode   : 0x25
cpu MHz : 2593.949
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt 
dtherm ida arat pln pts
bugs:
bogomips: 5187.89
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
stepping: 4
microcode   : 0x25
cpu MHz : 2593.949
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt 
dtherm ida arat pln pts
bugs:
bogomips: 5209.02
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
stepping: 4
microcode   : 0x25
cpu MHz : 2593.949
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt 
dtherm ida arat pln pts
bugs:

Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same core id

[Shu Wang]

> From: "Guenter Roeck" 
> To: shuw...@redhat.com
> Cc: "fenghua yu" , jdelv...@suse.com, 
> linux-hw...@vger.kernel.org,
> linux-kernel@vger.kernel.org, ch...@redhat.com, yiz...@redhat.com
> Sent: Tuesday, October 17, 2017 11:25:50 PM
> Subject: Re: [PATCH] hwmon: (coretemp) remove duplicated coretemp for same 
> core id
> 
> On Tue, Oct 17, 2017 at 04:44:50PM +0800, shuw...@redhat.com wrote:
> > From: Shu Wang 
> > 
> > Fix kernel warning on my 4cpus 2core_id system. The cpu0 and cpu1 have
> > same core_id 0, so both cpu0 and cpu1 will try to create file temp2_label
> > when it's online.
> > 
> What system/cpu is that ?
> 
> Normally I would assume that each CPU (package) instantiates
> a separate instance of the driver.

The system is ThinkPad X1 Carbon 3rd laptop, model 20BTS1N70F.

> 
> > - coretemp_cpu_online(cpu=0)
> >   - create_core_data(cpu=0, attr_no=2)
> >- create_core_attrs(attr_no=2)
> > - coretemp_cpu_online(cpu=1)
> >   - create_core_data(cpu=1, attr_no=2)
> >- create_core_attrs(attr_no=2)
> > 
> > $ grep -e processor -e 'core id' /proc/cpuinfo
> > processor   : 0
> > core id : 0
> > processor   : 1
> > core id : 0
> > processor   : 2
> > core id : 1
> > processor   : 3
> > core id : 1
> 
> Complete output of /proc/cpuinfo might be helpful.

$ cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
stepping: 4
microcode   : 0x25
cpu MHz : 2593.949
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt 
dtherm ida arat pln pts
bugs:
bogomips: 5187.89
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
stepping: 4
microcode   : 0x25
cpu MHz : 2593.949
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt 
dtherm ida arat pln pts
bugs:
bogomips: 5209.02
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
stepping: 4
microcode   : 0x25
cpu MHz : 2593.949
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt 
dtherm ida arat pln pts
bugs:
bogomips: 5201.77
clflush size: 64
cache_alignment : 

[PATCH 2/3] arm64: dts: hisilicon: add pinctrl nodes for hi3798cv200-poplar board

[Jiancheng Xue]

From: Younian Wang 

Add pinctrl nodes for hi3798cv200-poplar board

Signed-off-by: Younian Wang 
Signed-off-by: Jiancheng Xue 
---
 .../boot/dts/hisilicon/hi3798cv200-poplar.dts  |   1 +
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi |  71 +++
 arch/arm64/boot/dts/hisilicon/poplar-pinctrl.dtsi  | 651 +
 3 files changed, 723 insertions(+)
 create mode 100644 arch/arm64/boot/dts/hisilicon/poplar-pinctrl.dtsi

diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
index b914287..6a0b7e9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
@@ -11,6 +11,7 @@
 
 #include 
 #include "hi3798cv200.dtsi"
+#include "poplar-pinctrl.dtsi"
 
 / {
model = "HiSilicon Poplar Development Board";
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 0d11dc7..5a73c68 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -106,6 +106,54 @@
#reset-cells = <2>;
};
 
+   pmx0: pinconf@8a21000 {
+   compatible = "pinconf-single";
+   reg = <0x8a21000 0x180>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <7>;
+   pinctrl-single,gpio-range = <
+0  8 2  /* GPIO 0 */
+8  1 0  /* GPIO 1 */
+9  4 2
+13 1 0
+14 1 1
+15 1 0
+16 5 0  /* GPIO 2 */
+21 3 1
+24 4 1  /* GPIO 3 */
+28 2 2
+86 1 1
+87 1 0
+30 4 2  /* GPIO 4 */
+34 3 0
+37 1 2
+38 3 2  /* GPIO 6 */
+41 5 0
+46 8 1  /* GPIO 7 */
+54 8 1  /* GPIO 8 */
+64 7 1  /* GPIO 9 */
+71 1 0
+72 6 1  /* GPIO 10 */
+78 1 0
+79 1 1
+80 6 1  /* GPIO 11 */
+70 2 1
+88 8 0  /* GPIO 12 */
+   >;
+
+   range: gpio-range {
+   #pinctrl-single,gpio-range-cells = <3>;
+   };
+   };
+
+   pmx1: pinconf@844 {
+   compatible = "pinctrl-single";
+   reg = <0x844 4>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <1>;
+   pinctrl-single,bit-per-mux;
+   };
+
uart0: serial@8b0 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x8b0 0x1000>;
@@ -209,6 +257,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+   gpio-ranges = < 0 0 8>;
clocks = < HISTB_APB_CLK>;
clock-names = "apb_pclk";
status = "disabled";
@@ -222,6 +271,13 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+   gpio-ranges = <
+0 8 1
+1 9 4
+5 13 1
+6 14 1
+7 15 1
+   >;
clocks = < HISTB_APB_CLK>;
clock-names = "apb_pclk";
status = "disabled";
@@ -235,6 +291,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+   gpio-ranges = < 0 16 5  5 21 3>;
clocks = < HISTB_APB_CLK>;
clock-names = "apb_pclk";
status = "disabled";
@@ -248,6 +305,12 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+   

[PATCH 2/3] arm64: dts: hisilicon: add pinctrl nodes for hi3798cv200-poplar board

[Jiancheng Xue]

From: Younian Wang 

Add pinctrl nodes for hi3798cv200-poplar board

Signed-off-by: Younian Wang 
Signed-off-by: Jiancheng Xue 
---
 .../boot/dts/hisilicon/hi3798cv200-poplar.dts  |   1 +
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi |  71 +++
 arch/arm64/boot/dts/hisilicon/poplar-pinctrl.dtsi  | 651 +
 3 files changed, 723 insertions(+)
 create mode 100644 arch/arm64/boot/dts/hisilicon/poplar-pinctrl.dtsi

diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
index b914287..6a0b7e9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
@@ -11,6 +11,7 @@
 
 #include 
 #include "hi3798cv200.dtsi"
+#include "poplar-pinctrl.dtsi"
 
 / {
model = "HiSilicon Poplar Development Board";
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 0d11dc7..5a73c68 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -106,6 +106,54 @@
#reset-cells = <2>;
};
 
+   pmx0: pinconf@8a21000 {
+   compatible = "pinconf-single";
+   reg = <0x8a21000 0x180>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <7>;
+   pinctrl-single,gpio-range = <
+0  8 2  /* GPIO 0 */
+8  1 0  /* GPIO 1 */
+9  4 2
+13 1 0
+14 1 1
+15 1 0
+16 5 0  /* GPIO 2 */
+21 3 1
+24 4 1  /* GPIO 3 */
+28 2 2
+86 1 1
+87 1 0
+30 4 2  /* GPIO 4 */
+34 3 0
+37 1 2
+38 3 2  /* GPIO 6 */
+41 5 0
+46 8 1  /* GPIO 7 */
+54 8 1  /* GPIO 8 */
+64 7 1  /* GPIO 9 */
+71 1 0
+72 6 1  /* GPIO 10 */
+78 1 0
+79 1 1
+80 6 1  /* GPIO 11 */
+70 2 1
+88 8 0  /* GPIO 12 */
+   >;
+
+   range: gpio-range {
+   #pinctrl-single,gpio-range-cells = <3>;
+   };
+   };
+
+   pmx1: pinconf@844 {
+   compatible = "pinctrl-single";
+   reg = <0x844 4>;
+   pinctrl-single,register-width = <32>;
+   pinctrl-single,function-mask = <1>;
+   pinctrl-single,bit-per-mux;
+   };
+
uart0: serial@8b0 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x8b0 0x1000>;
@@ -209,6 +257,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+   gpio-ranges = < 0 0 8>;
clocks = < HISTB_APB_CLK>;
clock-names = "apb_pclk";
status = "disabled";
@@ -222,6 +271,13 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+   gpio-ranges = <
+0 8 1
+1 9 4
+5 13 1
+6 14 1
+7 15 1
+   >;
clocks = < HISTB_APB_CLK>;
clock-names = "apb_pclk";
status = "disabled";
@@ -235,6 +291,7 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+   gpio-ranges = < 0 16 5  5 21 3>;
clocks = < HISTB_APB_CLK>;
clock-names = "apb_pclk";
status = "disabled";
@@ -248,6 +305,12 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+   gpio-ranges = <
+0 24 4
+

Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations

[Michael Ellerman]

Mimi Zohar  writes:
> On Tue, 2017-10-17 at 12:11 +0200, Julia Lawall wrote:
>> On Tue, 17 Oct 2017, Dan Carpenter wrote:
>> > On Tue, Oct 17, 2017 at 10:56:42AM +0200, Julia Lawall wrote:
>> > > On Tue, 17 Oct 2017, Dan Carpenter wrote:
>> > > > On Mon, Oct 16, 2017 at 09:35:12PM +0300, Jarkko Sakkinen wrote:
>> > > > >
>> > > > > A minor complaint: all commits are missing "Fixes:" tag.
>> > > > >
>> > > >
>> > > > Fixes is only for bug fixes.  These don't fix any bugs.
>> > >
>> > > 0-day seems to put Fixes for everything.  Should they be removed when the
>> > > old code is undesirable but doesn't actually cause a crash, eg out of 
>> > > date
>> > > API.
>> >
>> > Yeah, I feel like Fixes tags don't belong for API updates and cleanups.
>> 
>> OK, I will remove them from the patches that go through me where they
>> don't seem appropriate.
>
> The "Fixes" tag is an indication that the patch should be backported.

No it's not that strong. It's an indication that the patch fixes another
commit, which may or may not mean it should be backported depending on
the preferences of the backporter. If it *does* need backporting then
the Fixes tag helps identify where it should go.

The doco is actually pretty well worded IMO:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n183

  If your patch fixes a bug in a specific commit, e.g. you found an issue using
  ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
  the SHA-1 ID, and the one line summary.

and:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n602

  A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
  is used to make it easy to determine where a bug originated, which can help
  review a bug fix. This tag also assists the stable kernel team in determining
  which stable kernel versions should receive your fix. This is the preferred
  method for indicating a bug fixed by the patch. See :ref:`describe_changes`
  for more details.


cheers

Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations

[Michael Ellerman]

Mimi Zohar  writes:
> On Tue, 2017-10-17 at 12:11 +0200, Julia Lawall wrote:
>> On Tue, 17 Oct 2017, Dan Carpenter wrote:
>> > On Tue, Oct 17, 2017 at 10:56:42AM +0200, Julia Lawall wrote:
>> > > On Tue, 17 Oct 2017, Dan Carpenter wrote:
>> > > > On Mon, Oct 16, 2017 at 09:35:12PM +0300, Jarkko Sakkinen wrote:
>> > > > >
>> > > > > A minor complaint: all commits are missing "Fixes:" tag.
>> > > > >
>> > > >
>> > > > Fixes is only for bug fixes.  These don't fix any bugs.
>> > >
>> > > 0-day seems to put Fixes for everything.  Should they be removed when the
>> > > old code is undesirable but doesn't actually cause a crash, eg out of 
>> > > date
>> > > API.
>> >
>> > Yeah, I feel like Fixes tags don't belong for API updates and cleanups.
>> 
>> OK, I will remove them from the patches that go through me where they
>> don't seem appropriate.
>
> The "Fixes" tag is an indication that the patch should be backported.

No it's not that strong. It's an indication that the patch fixes another
commit, which may or may not mean it should be backported depending on
the preferences of the backporter. If it *does* need backporting then
the Fixes tag helps identify where it should go.

The doco is actually pretty well worded IMO:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n183

  If your patch fixes a bug in a specific commit, e.g. you found an issue using
  ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
  the SHA-1 ID, and the one line summary.

and:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n602

  A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
  is used to make it easy to determine where a bug originated, which can help
  review a bug fix. This tag also assists the stable kernel team in determining
  which stable kernel versions should receive your fix. This is the preferred
  method for indicating a bug fixed by the patch. See :ref:`describe_changes`
  for more details.


cheers

[PATCH 1/3] arm64: dts: hisilicon: supplement properties of ir node for poplar board

[Jiancheng Xue]

From: Younian Wang 

Supplement properties of ir node for poplar board.

Signed-off-by: Younian Wang 
---
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 75865f8a..0d11dc7 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -405,6 +405,8 @@
reg = <0x8001000 0x1000>;
interrupts = ;
clocks = < HISTB_IR_CLK>;
+   hisilicon,power-syscon = <>;
+   linux,rc-map-name = "rc-hisi-poplar";
status = "disabled";
};
};
-- 
2.7.4

[PATCH 0/3] arm64: dts: add more nodes and properities for hi3798cv200-poplar board

[Jiancheng Xue]

Add more devices nodes and properties for poplar board, involving ir, emmc and 
pinctrl nodes.

Younian Wang (2):
  arm64: dts: hisilicon: supplement properties of ir node for poplar
board
  arm64: dts: hisilicon: add pinctrl nodes for hi3798cv200-poplar board

tianshuliang (1):
  arm64: dts: hisilicon: supplement properties of emmc nodes for
hi3798cv200-poplar board

 .../boot/dts/hisilicon/hi3798cv200-poplar.dts  |  13 +
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi |  81 ++-
 arch/arm64/boot/dts/hisilicon/poplar-pinctrl.dtsi  | 651 +
 3 files changed, 742 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/boot/dts/hisilicon/poplar-pinctrl.dtsi

-- 
2.7.4

[PATCH 3/3] arm64: dts: hisilicon: supplement properties of emmc nodes for hi3798cv200-poplar board

[Jiancheng Xue]

From: tianshuliang 

Supplement properties of emmc nodes to support high performance.

Signed-off-by: tianshuliang 
---
 arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts | 12 
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi   |  8 +---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
index 6a0b7e9..b890829 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
@@ -160,4 +160,16 @@
status = "okay";
label = "LS-UART0";
 };
+
+ {
+   status = "okay";
+   num-slots = <1>;
+   fifo-depth = <256>;
+   clock-frequency = <2>;
+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   non-removable;
+   bus-width = <8>;
+};
 /* No optional LS-UART1 on Low Speed Expansion Connector. */
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 5a73c68..df62382 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -241,12 +241,14 @@
};
 
emmc: mmc@983 {
-   compatible = "snps,dw-mshc";
+   compatible = "hisilicon,hi3798cv200-dw-mshc";
reg = <0x983 0x1>;
interrupts = ;
clocks = < HISTB_MMC_CIU_CLK>,
-< HISTB_MMC_BIU_CLK>;
-   clock-names = "ciu", "biu";
+< HISTB_MMC_BIU_CLK>,
+< HISTB_MMC_SAMPLE_CLK>,
+< HISTB_MMC_DRV_CLK>;
+   clock-names = "ciu", "biu", "ciu-sample", "ciu-drive";
};
 
gpio0: gpio@8b2 {
-- 
2.7.4

[PATCH 1/3] arm64: dts: hisilicon: supplement properties of ir node for poplar board

[Jiancheng Xue]

From: Younian Wang 

Supplement properties of ir node for poplar board.

Signed-off-by: Younian Wang 
---
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 75865f8a..0d11dc7 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -405,6 +405,8 @@
reg = <0x8001000 0x1000>;
interrupts = ;
clocks = < HISTB_IR_CLK>;
+   hisilicon,power-syscon = <>;
+   linux,rc-map-name = "rc-hisi-poplar";
status = "disabled";
};
};
-- 
2.7.4

[PATCH 0/3] arm64: dts: add more nodes and properities for hi3798cv200-poplar board

[Jiancheng Xue]

Add more devices nodes and properties for poplar board, involving ir, emmc and 
pinctrl nodes.

Younian Wang (2):
  arm64: dts: hisilicon: supplement properties of ir node for poplar
board
  arm64: dts: hisilicon: add pinctrl nodes for hi3798cv200-poplar board

tianshuliang (1):
  arm64: dts: hisilicon: supplement properties of emmc nodes for
hi3798cv200-poplar board

 .../boot/dts/hisilicon/hi3798cv200-poplar.dts  |  13 +
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi |  81 ++-
 arch/arm64/boot/dts/hisilicon/poplar-pinctrl.dtsi  | 651 +
 3 files changed, 742 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/boot/dts/hisilicon/poplar-pinctrl.dtsi

-- 
2.7.4

[PATCH 3/3] arm64: dts: hisilicon: supplement properties of emmc nodes for hi3798cv200-poplar board

[Jiancheng Xue]

From: tianshuliang 

Supplement properties of emmc nodes to support high performance.

Signed-off-by: tianshuliang 
---
 arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts | 12 
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi   |  8 +---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
index 6a0b7e9..b890829 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
@@ -160,4 +160,16 @@
status = "okay";
label = "LS-UART0";
 };
+
+ {
+   status = "okay";
+   num-slots = <1>;
+   fifo-depth = <256>;
+   clock-frequency = <2>;
+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   non-removable;
+   bus-width = <8>;
+};
 /* No optional LS-UART1 on Low Speed Expansion Connector. */
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 5a73c68..df62382 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -241,12 +241,14 @@
};
 
emmc: mmc@983 {
-   compatible = "snps,dw-mshc";
+   compatible = "hisilicon,hi3798cv200-dw-mshc";
reg = <0x983 0x1>;
interrupts = ;
clocks = < HISTB_MMC_CIU_CLK>,
-< HISTB_MMC_BIU_CLK>;
-   clock-names = "ciu", "biu";
+< HISTB_MMC_BIU_CLK>,
+< HISTB_MMC_SAMPLE_CLK>,
+< HISTB_MMC_DRV_CLK>;
+   clock-names = "ciu", "biu", "ciu-sample", "ciu-drive";
};
 
gpio0: gpio@8b2 {
-- 
2.7.4

Re: [PATCH] scsi: gdth: Convert timers to use timer_setup()

[Kees Cook]

On Tue, Oct 17, 2017 at 8:06 PM, Martin K. Petersen
 wrote:
>
> Kees,
>
>> Thanks for the reviews! Do you want the timer tree to carry these
>> patches, or can you pick them up in the scsi tree?
>
> Up to you. I'm not going to rebase my 4.15 queue this late in the cycle
> so the patches would end up going in at the end of the merge window. If
> you prefer to have them hit the first pull you should queue them up in
> the timer tree.

Okay, thanks, I'll take them via the timer tree.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] scsi: gdth: Convert timers to use timer_setup()

[Kees Cook]

On Tue, Oct 17, 2017 at 8:06 PM, Martin K. Petersen
 wrote:
>
> Kees,
>
>> Thanks for the reviews! Do you want the timer tree to carry these
>> patches, or can you pick them up in the scsi tree?
>
> Up to you. I'm not going to rebase my 4.15 queue this late in the cycle
> so the patches would end up going in at the end of the merge window. If
> you prefer to have them hit the first pull you should queue them up in
> the timer tree.

Okay, thanks, I'll take them via the timer tree.

-Kees

-- 
Kees Cook
Pixel Security

[PATCH 0/2] mmc: add an specific emmc driver for hi3798cv200-poplar board

[Jiancheng Xue]

Add an specific emmc driver for hi3798cv200-poplar board. Previously, it used 
the
generic dw-mmc driver with lower performance.

tianshuliang (2):
  dt-bindings: mmc: add bindings for hi3798cv200-dw-mshc
  mmc: dw_mmc: add support for hi3798cv200 specific extensions of
dw-mshc

 .../bindings/mmc/hi3798cv200-dw-mshc.txt   |  51 ++
 drivers/mmc/host/Kconfig   |   9 +
 drivers/mmc/host/Makefile  |   1 +
 drivers/mmc/host/dw_mmc-hi3798cv200.c  | 191 +
 4 files changed, 252 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt
 create mode 100644 drivers/mmc/host/dw_mmc-hi3798cv200.c

-- 
2.7.4

[PATCH 0/2] mmc: add an specific emmc driver for hi3798cv200-poplar board

[Jiancheng Xue]

Add an specific emmc driver for hi3798cv200-poplar board. Previously, it used 
the
generic dw-mmc driver with lower performance.

tianshuliang (2):
  dt-bindings: mmc: add bindings for hi3798cv200-dw-mshc
  mmc: dw_mmc: add support for hi3798cv200 specific extensions of
dw-mshc

 .../bindings/mmc/hi3798cv200-dw-mshc.txt   |  51 ++
 drivers/mmc/host/Kconfig   |   9 +
 drivers/mmc/host/Makefile  |   1 +
 drivers/mmc/host/dw_mmc-hi3798cv200.c  | 191 +
 4 files changed, 252 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt
 create mode 100644 drivers/mmc/host/dw_mmc-hi3798cv200.c

-- 
2.7.4

[PATCH 2/2] mmc: dw_mmc: add support for hi3798cv200 specific extensions of dw-mshc

[Jiancheng Xue]

From: tianshuliang 

Hi3798cv200 SoC extends the dw-mshc controller for additional clock
and bus control. Add support for these extensions.

Signed-off-by: tianshuliang 
Signed-off-by: Jiancheng Xue 
---
 drivers/mmc/host/Kconfig  |   9 ++
 drivers/mmc/host/Makefile |   1 +
 drivers/mmc/host/dw_mmc-hi3798cv200.c | 191 ++
 3 files changed, 201 insertions(+)
 create mode 100644 drivers/mmc/host/dw_mmc-hi3798cv200.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8c15637..2bf6aa8 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -712,6 +712,15 @@ config MMC_DW_K3
  Synopsys DesignWare Memory Card Interface driver. Select this option
  for platforms based on Hisilicon K3 SoC's.
 
+config MMC_DW_HI3798CV200
+   tristate "Hi3798cv200 specific extensions for Synopsys DW Memory Card 
Interface"
+   depends on MMC_DW
+   select MMC_DW_PLTFM
+   help
+ This selects support for HiSilicon hi3798cv200 SoC specific 
extensions to the
+ Synopsys DesignWare Memory Card Interface driver. Select this option
+ for platforms based on HiSilicon hi3798cv200 SoC's.
+
 config MMC_DW_PCI
tristate "Synopsys Designware MCI support on PCI bus"
depends on MMC_DW && PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 303f5cd..6e015d8 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_MMC_CAVIUM_THUNDERX) += thunderx-mmc.o
 obj-$(CONFIG_MMC_DW)   += dw_mmc.o
 obj-$(CONFIG_MMC_DW_PLTFM) += dw_mmc-pltfm.o
 obj-$(CONFIG_MMC_DW_EXYNOS)+= dw_mmc-exynos.o
+obj-$(CONFIG_MMC_DW_HI3798CV200) += dw_mmc-hi3798cv200.o
 obj-$(CONFIG_MMC_DW_K3)+= dw_mmc-k3.o
 obj-$(CONFIG_MMC_DW_PCI)   += dw_mmc-pci.o
 obj-$(CONFIG_MMC_DW_ROCKCHIP)  += dw_mmc-rockchip.o
diff --git a/drivers/mmc/host/dw_mmc-hi3798cv200.c 
b/drivers/mmc/host/dw_mmc-hi3798cv200.c
new file mode 100644
index 000..bd24001
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-hi3798cv200.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright (c) 2017 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+#define ALL_INT_CLR0x1EFFF
+
+#define SDMMC_DDR_REG  0x10c
+#define SDMMC_ENABLE_SH0x110
+#define SDMMC_DDR_HS400BIT(31)
+#define SDMMC_ENABLE_SH_PHASE  BIT(0)
+#define SDMMC_DRV_PS_135   3
+#define SDMMC_DRV_PS_180   4
+
+struct hi3798cv200_priv {
+   struct clk  *sample_clk;
+   struct clk  *drive_clk;
+};
+
+static void dw_mci_hi3798cv200_set_ios(struct dw_mci *host, struct mmc_ios 
*ios)
+{
+   u32 regs;
+   struct hi3798cv200_priv *priv = host->priv;
+   u32 drive_phase[] = {0, 45, 90, 135, 180, 225, 270, 315};
+
+   regs = mci_readl(host, UHS_REG);
+   if (ios->timing == MMC_TIMING_MMC_HS400)
+   regs &= ~(0x1 << 16);
+   mci_writel(host, UHS_REG, regs);
+
+   regs = mci_readl(host, ENABLE_SH);
+   if (ios->timing == MMC_TIMING_MMC_DDR52)
+   regs |= SDMMC_ENABLE_SH_PHASE;
+   else
+   regs &= ~SDMMC_ENABLE_SH_PHASE;
+   mci_writel(host, ENABLE_SH, regs);
+
+   regs = mci_readl(host, DDR_REG);
+   if (ios->timing == MMC_TIMING_MMC_HS400)
+   regs |= SDMMC_DDR_HS400;
+   else
+   regs &= ~SDMMC_DDR_HS400;
+   mci_writel(host, DDR_REG, regs);
+
+   if ((ios->timing == MMC_TIMING_MMC_HS) ||
+   (ios->timing == MMC_TIMING_LEGACY))
+   clk_set_phase(priv->drive_clk, drive_phase[SDMMC_DRV_PS_180]);
+   else if (ios->timing == MMC_TIMING_MMC_HS200)
+   clk_set_phase(priv->drive_clk, drive_phase[SDMMC_DRV_PS_135]);
+}
+
+static int
+dw_mci_hi3798cv200_execute_tuning(struct dw_mci_slot *slot, u32 opcode)
+{
+   struct dw_mci *host = slot->host;
+   struct hi3798cv200_priv *priv = host->priv;
+   u32 index, found = 0;
+   u32 sample_phase[] = {0, 45, 90, 135, 180, 225, 270, 315};
+   int err = 0, raise_point = -1, fall_point = -1, prev_err = -1;
+
+   for (index = 0; index < ARRAY_SIZE(sample_phase); index++) {
+   clk_set_phase(priv->sample_clk, sample_phase[index]);
+   mci_writel(host, RINTSTS, ALL_INT_CLR);
+
+   err = mmc_send_tuning(slot->mmc, opcode, NULL);
+   if (!err)
+   found = 1;
+   if (index > 0) {
+ 

[PATCH 1/2] dt-bindings: mmc: add bindings for hi3798cv200-dw-mshc

[Jiancheng Xue]

From: tianshuliang 

Hisilicon hi3798cv200 SoC extends the dw-mshc controller
for additional clock control. Add device tree bindings for
hi3798cv200-dw-mshc.

Signed-off-by: tianshuliang 
Signed-off-by: Jiancheng Xue 
---
 .../bindings/mmc/hi3798cv200-dw-mshc.txt   | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt

diff --git a/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt
new file mode 100644
index 000..845c32c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt
@@ -0,0 +1,51 @@
+* Hisilicon specific extensions to the Synopsys Designware Mobile
+  Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
+extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+  - "hisilicon,hi3798cv200-dw-mshc": for controllers with hi3798cv200 specific 
extensions.
+
+Optional Properties:
+* clocks: from common clock binding: if ciu-drive and ciu-sample are
+  specified in clock-names, should contain handles to these clocks.
+
+* clock-names:Apart from the clock-names described in synopsys-dw-mshc.txt
+  two more clocks "ciu-drive" and "ciu-sample" are supported. They are used
+  to control the clock phases, "ciu-sample" is required for tuning high-speed 
modes.
+
+Example:
+
+   /* for Hi3798cv200 */
+
+   /* SoC portion */
+   emmc: mmc@983 {
+   compatible = "hisilicon,hi3798cv200-dw-mshc";
+   reg = <0x983 0x1>;
+   interrupts = ;
+   clocks = < HISTB_MMC_CIU_CLK>,
+< HISTB_MMC_BIU_CLK>,
+< HISTB_MMC_SAMPLE_CLK>;
+   clock-names = "ciu", "biu", "ciu-sample";
+   };
+
+   /* Board portion */
+{
+   status = "okay";
+   num-slots = <1>;
+   fifo-depth = <256>;
+   clock-frequency = <2>;
+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   non-removable;
+   bus-width = <8>;
+   };
-- 
2.7.4

[PATCH 2/2] mmc: dw_mmc: add support for hi3798cv200 specific extensions of dw-mshc

[Jiancheng Xue]

From: tianshuliang 

Hi3798cv200 SoC extends the dw-mshc controller for additional clock
and bus control. Add support for these extensions.

Signed-off-by: tianshuliang 
Signed-off-by: Jiancheng Xue 
---
 drivers/mmc/host/Kconfig  |   9 ++
 drivers/mmc/host/Makefile |   1 +
 drivers/mmc/host/dw_mmc-hi3798cv200.c | 191 ++
 3 files changed, 201 insertions(+)
 create mode 100644 drivers/mmc/host/dw_mmc-hi3798cv200.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 8c15637..2bf6aa8 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -712,6 +712,15 @@ config MMC_DW_K3
  Synopsys DesignWare Memory Card Interface driver. Select this option
  for platforms based on Hisilicon K3 SoC's.
 
+config MMC_DW_HI3798CV200
+   tristate "Hi3798cv200 specific extensions for Synopsys DW Memory Card 
Interface"
+   depends on MMC_DW
+   select MMC_DW_PLTFM
+   help
+ This selects support for HiSilicon hi3798cv200 SoC specific 
extensions to the
+ Synopsys DesignWare Memory Card Interface driver. Select this option
+ for platforms based on HiSilicon hi3798cv200 SoC's.
+
 config MMC_DW_PCI
tristate "Synopsys Designware MCI support on PCI bus"
depends on MMC_DW && PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 303f5cd..6e015d8 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_MMC_CAVIUM_THUNDERX) += thunderx-mmc.o
 obj-$(CONFIG_MMC_DW)   += dw_mmc.o
 obj-$(CONFIG_MMC_DW_PLTFM) += dw_mmc-pltfm.o
 obj-$(CONFIG_MMC_DW_EXYNOS)+= dw_mmc-exynos.o
+obj-$(CONFIG_MMC_DW_HI3798CV200) += dw_mmc-hi3798cv200.o
 obj-$(CONFIG_MMC_DW_K3)+= dw_mmc-k3.o
 obj-$(CONFIG_MMC_DW_PCI)   += dw_mmc-pci.o
 obj-$(CONFIG_MMC_DW_ROCKCHIP)  += dw_mmc-rockchip.o
diff --git a/drivers/mmc/host/dw_mmc-hi3798cv200.c 
b/drivers/mmc/host/dw_mmc-hi3798cv200.c
new file mode 100644
index 000..bd24001
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-hi3798cv200.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright (c) 2017 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dw_mmc.h"
+#include "dw_mmc-pltfm.h"
+
+#define ALL_INT_CLR0x1EFFF
+
+#define SDMMC_DDR_REG  0x10c
+#define SDMMC_ENABLE_SH0x110
+#define SDMMC_DDR_HS400BIT(31)
+#define SDMMC_ENABLE_SH_PHASE  BIT(0)
+#define SDMMC_DRV_PS_135   3
+#define SDMMC_DRV_PS_180   4
+
+struct hi3798cv200_priv {
+   struct clk  *sample_clk;
+   struct clk  *drive_clk;
+};
+
+static void dw_mci_hi3798cv200_set_ios(struct dw_mci *host, struct mmc_ios 
*ios)
+{
+   u32 regs;
+   struct hi3798cv200_priv *priv = host->priv;
+   u32 drive_phase[] = {0, 45, 90, 135, 180, 225, 270, 315};
+
+   regs = mci_readl(host, UHS_REG);
+   if (ios->timing == MMC_TIMING_MMC_HS400)
+   regs &= ~(0x1 << 16);
+   mci_writel(host, UHS_REG, regs);
+
+   regs = mci_readl(host, ENABLE_SH);
+   if (ios->timing == MMC_TIMING_MMC_DDR52)
+   regs |= SDMMC_ENABLE_SH_PHASE;
+   else
+   regs &= ~SDMMC_ENABLE_SH_PHASE;
+   mci_writel(host, ENABLE_SH, regs);
+
+   regs = mci_readl(host, DDR_REG);
+   if (ios->timing == MMC_TIMING_MMC_HS400)
+   regs |= SDMMC_DDR_HS400;
+   else
+   regs &= ~SDMMC_DDR_HS400;
+   mci_writel(host, DDR_REG, regs);
+
+   if ((ios->timing == MMC_TIMING_MMC_HS) ||
+   (ios->timing == MMC_TIMING_LEGACY))
+   clk_set_phase(priv->drive_clk, drive_phase[SDMMC_DRV_PS_180]);
+   else if (ios->timing == MMC_TIMING_MMC_HS200)
+   clk_set_phase(priv->drive_clk, drive_phase[SDMMC_DRV_PS_135]);
+}
+
+static int
+dw_mci_hi3798cv200_execute_tuning(struct dw_mci_slot *slot, u32 opcode)
+{
+   struct dw_mci *host = slot->host;
+   struct hi3798cv200_priv *priv = host->priv;
+   u32 index, found = 0;
+   u32 sample_phase[] = {0, 45, 90, 135, 180, 225, 270, 315};
+   int err = 0, raise_point = -1, fall_point = -1, prev_err = -1;
+
+   for (index = 0; index < ARRAY_SIZE(sample_phase); index++) {
+   clk_set_phase(priv->sample_clk, sample_phase[index]);
+   mci_writel(host, RINTSTS, ALL_INT_CLR);
+
+   err = mmc_send_tuning(slot->mmc, opcode, NULL);
+   if (!err)
+   found = 1;
+   if (index > 0) {
+   if (err && !prev_err)
+   

[PATCH 1/2] dt-bindings: mmc: add bindings for hi3798cv200-dw-mshc

[Jiancheng Xue]

From: tianshuliang 

Hisilicon hi3798cv200 SoC extends the dw-mshc controller
for additional clock control. Add device tree bindings for
hi3798cv200-dw-mshc.

Signed-off-by: tianshuliang 
Signed-off-by: Jiancheng Xue 
---
 .../bindings/mmc/hi3798cv200-dw-mshc.txt   | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt

diff --git a/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt
new file mode 100644
index 000..845c32c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/hi3798cv200-dw-mshc.txt
@@ -0,0 +1,51 @@
+* Hisilicon specific extensions to the Synopsys Designware Mobile
+  Storage Host Controller
+
+Read synopsys-dw-mshc.txt for more details
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
+extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be one of the following.
+  - "hisilicon,hi3798cv200-dw-mshc": for controllers with hi3798cv200 specific 
extensions.
+
+Optional Properties:
+* clocks: from common clock binding: if ciu-drive and ciu-sample are
+  specified in clock-names, should contain handles to these clocks.
+
+* clock-names:Apart from the clock-names described in synopsys-dw-mshc.txt
+  two more clocks "ciu-drive" and "ciu-sample" are supported. They are used
+  to control the clock phases, "ciu-sample" is required for tuning high-speed 
modes.
+
+Example:
+
+   /* for Hi3798cv200 */
+
+   /* SoC portion */
+   emmc: mmc@983 {
+   compatible = "hisilicon,hi3798cv200-dw-mshc";
+   reg = <0x983 0x1>;
+   interrupts = ;
+   clocks = < HISTB_MMC_CIU_CLK>,
+< HISTB_MMC_BIU_CLK>,
+< HISTB_MMC_SAMPLE_CLK>;
+   clock-names = "ciu", "biu", "ciu-sample";
+   };
+
+   /* Board portion */
+{
+   status = "okay";
+   num-slots = <1>;
+   fifo-depth = <256>;
+   clock-frequency = <2>;
+   cap-mmc-highspeed;
+   mmc-ddr-1_8v;
+   mmc-hs200-1_8v;
+   non-removable;
+   bus-width = <8>;
+   };
-- 
2.7.4

Re: [PATCH v5 1/2] acpi: apei: remove the unused dead-code for SEA/NMI notification type

[gengdongjiu]

Hi,Borislav

On 2017/10/18 0:43, Borislav Petkov wrote:
>> -}
>> -
> So GHES NMI notification method is x86-only AFAIK and HAVE_ACPI_APEI_NMI
> is selected only on x86. Why are you removing those guards? Does ARM
> have ACPI_HEST_NOTIFY_NMI notification type now too?

ARM does not have ACPI_HEST_NOTIFY_NMI notification, which should only used by 
x86.
In the code, I see those guards are never used. As you see, if the 
'CONFIG_HAVE_ACPI_APEI_NMI'
does not defined in [1], it will print error info and goto [2], in the [2], it 
will return error,
then the probe for GHES NMI is failed. so those guards( ghes_nmi_add() and 
ghes_nmi_remove()) have no chance
to execute. so I redefine them to NULL for compiling[3].

static int ghes_probe(struct platform_device *ghes_dev)
{
  struct acpi_hest_generic *generic;
  struct ghes *ghes = NULL;

  int rc = -EINVAL;

   switch (generic->notify.type) {
   ...
   case ACPI_HEST_NOTIFY_NMI:[1]
  if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
  pr_warn(GHES_PFX "Generic hardware error source: %d notified via 
NMI interrupt is not supported!\n",
  generic->header.source_id);
  goto err;
  }
   ..
  }
  switch (generic->notify.type) {
  ...
  case ACPI_HEST_NOTIFY_NMI:
 ghes_nmi_add(ghes);
 break;
  }
  ..
 err:[2]
  if (ghes) {
  ghes_fini(ghes);
  kfree(ghes);
  }
  return rc;
}

[3]:
-static inline void ghes_nmi_add(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to add NMI notification which is not 
supported!\n",
-  ghes->generic->header.source_id);
-   BUG();
-}
-
-static inline void ghes_nmi_remove(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to remove NMI notification which is not 
supported!\n",
-  ghes->generic->header.source_id);
-   BUG();
-}
-
-static inline void ghes_nmi_init_cxt(void)
-{
-}
+static inline void ghes_nmi_add(struct ghes *ghes) { }
+static inline void ghes_nmi_remove(struct ghes *ghes) { }
+static inline void ghes_nmi_init_cxt(void) { }

Re: [PATCH v5 1/2] acpi: apei: remove the unused dead-code for SEA/NMI notification type

[gengdongjiu]

Hi,Borislav

On 2017/10/18 0:43, Borislav Petkov wrote:
>> -}
>> -
> So GHES NMI notification method is x86-only AFAIK and HAVE_ACPI_APEI_NMI
> is selected only on x86. Why are you removing those guards? Does ARM
> have ACPI_HEST_NOTIFY_NMI notification type now too?

ARM does not have ACPI_HEST_NOTIFY_NMI notification, which should only used by 
x86.
In the code, I see those guards are never used. As you see, if the 
'CONFIG_HAVE_ACPI_APEI_NMI'
does not defined in [1], it will print error info and goto [2], in the [2], it 
will return error,
then the probe for GHES NMI is failed. so those guards( ghes_nmi_add() and 
ghes_nmi_remove()) have no chance
to execute. so I redefine them to NULL for compiling[3].

static int ghes_probe(struct platform_device *ghes_dev)
{
  struct acpi_hest_generic *generic;
  struct ghes *ghes = NULL;

  int rc = -EINVAL;

   switch (generic->notify.type) {
   ...
   case ACPI_HEST_NOTIFY_NMI:[1]
  if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
  pr_warn(GHES_PFX "Generic hardware error source: %d notified via 
NMI interrupt is not supported!\n",
  generic->header.source_id);
  goto err;
  }
   ..
  }
  switch (generic->notify.type) {
  ...
  case ACPI_HEST_NOTIFY_NMI:
 ghes_nmi_add(ghes);
 break;
  }
  ..
 err:[2]
  if (ghes) {
  ghes_fini(ghes);
  kfree(ghes);
  }
  return rc;
}

[3]:
-static inline void ghes_nmi_add(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to add NMI notification which is not 
supported!\n",
-  ghes->generic->header.source_id);
-   BUG();
-}
-
-static inline void ghes_nmi_remove(struct ghes *ghes)
-{
-   pr_err(GHES_PFX "ID: %d, trying to remove NMI notification which is not 
supported!\n",
-  ghes->generic->header.source_id);
-   BUG();
-}
-
-static inline void ghes_nmi_init_cxt(void)
-{
-}
+static inline void ghes_nmi_add(struct ghes *ghes) { }
+static inline void ghes_nmi_remove(struct ghes *ghes) { }
+static inline void ghes_nmi_init_cxt(void) { }

Re: [PATCH] scsi: gdth: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> Thanks for the reviews! Do you want the timer tree to carry these
> patches, or can you pick them up in the scsi tree?

Up to you. I'm not going to rebase my 4.15 queue this late in the cycle
so the patches would end up going in at the end of the merge window. If
you prefer to have them hit the first pull you should queue them up in
the timer tree.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: gdth: Convert timers to use timer_setup()

[Martin K. Petersen]

Kees,

> Thanks for the reviews! Do you want the timer tree to carry these
> patches, or can you pick them up in the scsi tree?

Up to you. I'm not going to rebase my 4.15 queue this late in the cycle
so the patches would end up going in at the end of the merge window. If
you prefer to have them hit the first pull you should queue them up in
the timer tree.

-- 
Martin K. Petersen  Oracle Linux Engineering