Re: [tip:x86/microcode] x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

[Borislav Petkov]

On Tue, Jul 26, 2016 at 01:37:07PM -0700, Kees Cook wrote:
> These ifdefs aren't needed if we added a no-op __PAGE_OFFSET_BASE to
> the 32-bit page table headers. Then the compiler will DTRT with the
> start calculation. When CONFIG_RANDOMIZE_MEMORY is set, start will
> have a non-zero value, and when not set it'll be 0.

Something like this? I'm trying to mimick the 64-bit version:

---
diff --git a/arch/x86/include/asm/page_32_types.h 
b/arch/x86/include/asm/page_32_types.h
index 3a52ee0e726d..3bae4969ac65 100644
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -13,7 +13,8 @@
  * If you want more physical memory than this then see the CONFIG_HIGHMEM4G
  * and CONFIG_HIGHMEM64G options in the kernel configuration.
  */
-#define __PAGE_OFFSET  _AC(CONFIG_PAGE_OFFSET, UL)
+#define __PAGE_OFFSET_BASE _AC(CONFIG_PAGE_OFFSET, UL)
+#define __PAGE_OFFSET  __PAGE_OFFSET_BASE
 
 #define __START_KERNEL_map __PAGE_OFFSET
 
-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [tip:x86/microcode] x86/microcode/intel: Fix initrd loading with CONFIG_RANDOMIZE_MEMORY=y

[Borislav Petkov]

On Tue, Jul 26, 2016 at 01:37:07PM -0700, Kees Cook wrote:
> These ifdefs aren't needed if we added a no-op __PAGE_OFFSET_BASE to
> the 32-bit page table headers. Then the compiler will DTRT with the
> start calculation. When CONFIG_RANDOMIZE_MEMORY is set, start will
> have a non-zero value, and when not set it'll be 0.

Something like this? I'm trying to mimick the 64-bit version:

---
diff --git a/arch/x86/include/asm/page_32_types.h 
b/arch/x86/include/asm/page_32_types.h
index 3a52ee0e726d..3bae4969ac65 100644
--- a/arch/x86/include/asm/page_32_types.h
+++ b/arch/x86/include/asm/page_32_types.h
@@ -13,7 +13,8 @@
  * If you want more physical memory than this then see the CONFIG_HIGHMEM4G
  * and CONFIG_HIGHMEM64G options in the kernel configuration.
  */
-#define __PAGE_OFFSET  _AC(CONFIG_PAGE_OFFSET, UL)
+#define __PAGE_OFFSET_BASE _AC(CONFIG_PAGE_OFFSET, UL)
+#define __PAGE_OFFSET  __PAGE_OFFSET_BASE
 
 #define __START_KERNEL_map __PAGE_OFFSET
 
-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Borislav Petkov]

On Tue, Jul 26, 2016 at 02:17:29PM -0700, Thomas Garnier wrote:
> I am sorry, there has been parallel work between KASLR memory
> randomization and hibernation support. That's why hibernation was not
> tested, it was not supported when the feature was created.
> Communication will be better next time.
> 
> I will work on identifying the problem and pushing a fix.

Would you please do me a favor and stop top-posting. It really disrupts
reading the thread.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: Fwd: [Bug 150021] New: kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk

[Borislav Petkov]

On Tue, Jul 26, 2016 at 02:17:29PM -0700, Thomas Garnier wrote:
> I am sorry, there has been parallel work between KASLR memory
> randomization and hibernation support. That's why hibernation was not
> tested, it was not supported when the feature was created.
> Communication will be better next time.
> 
> I will work on identifying the problem and pushing a fix.

Would you please do me a favor and stop top-posting. It really disrupts
reading the thread.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [PATCH] ACPICA: cleanup method properly on error

[Vegard Nossum]

On 07/26/2016 10:28 PM, Moore, Robert wrote:

 /* Put the new state at the head of the walk list */

 if (Thread)
 {
 AcpiDsPushWalkState (WalkState, Thread);
 }

Is there any chance that Thread could be zero?


I'm not sure if this question was for me or not, but that code (modulo
the capitalisation differences) is the reason why I also used 'if
(thread)' in my patch.


Vegard




-Original Message-
From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, July 26, 2016 7:40 AM
To: Vegard Nossum ; Zheng, Lv
; Wysocki, Rafael J 
Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
sta...@vger.kernel.org; de...@acpica.org
Subject: Re: [Devel] [PATCH] ACPICA: cleanup method properly on error

We'll look at this.
Thanks.



-Original Message-
From: Vegard Nossum [mailto:vegard.nos...@oracle.com]
Sent: Friday, July 22, 2016 8:35 AM
To: Moore, Robert ; Zheng, Lv
; Wysocki, Rafael J 
Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
ker...@vger.kernel.org; Vegard Nossum ;
sta...@vger.kernel.org
Subject: [PATCH] ACPICA: cleanup method properly on error

If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
walk state push done by acpi_ds_create_walk_state(). Otherwise, the
new walk state (which has just been freed) will remain on the thread's
walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try
to get the new state.

You can observe this when reading e.g.

 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status

Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum 
---
  drivers/acpi/acpica/dsmethod.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/acpica/dsmethod.c
b/drivers/acpi/acpica/dsmethod.c index 47c7b52..44b50a6 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -596,6 +596,8 @@ cleanup:
/* On error, we must terminate the method properly */

acpi_ds_terminate_control_method(obj_desc, next_walk_state);
+   if (thread)
+   acpi_ds_pop_walk_state(thread);
acpi_ds_delete_walk_state(next_walk_state);

return_ACPI_STATUS(status);
--
1.9.1


___
Devel mailing list
de...@acpica.org
https://lists.acpica.org/mailman/listinfo/devel

Re: [PATCH] ACPICA: cleanup method properly on error

[Vegard Nossum]

On 07/26/2016 10:28 PM, Moore, Robert wrote:

 /* Put the new state at the head of the walk list */

 if (Thread)
 {
 AcpiDsPushWalkState (WalkState, Thread);
 }

Is there any chance that Thread could be zero?


I'm not sure if this question was for me or not, but that code (modulo
the capitalisation differences) is the reason why I also used 'if
(thread)' in my patch.


Vegard




-Original Message-
From: Devel [mailto:devel-boun...@acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, July 26, 2016 7:40 AM
To: Vegard Nossum ; Zheng, Lv
; Wysocki, Rafael J 
Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
sta...@vger.kernel.org; de...@acpica.org
Subject: Re: [Devel] [PATCH] ACPICA: cleanup method properly on error

We'll look at this.
Thanks.



-Original Message-
From: Vegard Nossum [mailto:vegard.nos...@oracle.com]
Sent: Friday, July 22, 2016 8:35 AM
To: Moore, Robert ; Zheng, Lv
; Wysocki, Rafael J 
Cc: linux-a...@vger.kernel.org; de...@acpica.org; linux-
ker...@vger.kernel.org; Vegard Nossum ;
sta...@vger.kernel.org
Subject: [PATCH] ACPICA: cleanup method properly on error

If the call to acpi_ds_init_aml_walk() fails, then we have to undo the
walk state push done by acpi_ds_create_walk_state(). Otherwise, the
new walk state (which has just been freed) will remain on the thread's
walk_state_list and be dereferenced in acpi_ps_parse_aml() when we try
to get the new state.

You can observe this when reading e.g.

 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/status

Cc: sta...@vger.kernel.org
Signed-off-by: Vegard Nossum 
---
  drivers/acpi/acpica/dsmethod.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/acpica/dsmethod.c
b/drivers/acpi/acpica/dsmethod.c index 47c7b52..44b50a6 100644
--- a/drivers/acpi/acpica/dsmethod.c
+++ b/drivers/acpi/acpica/dsmethod.c
@@ -596,6 +596,8 @@ cleanup:
/* On error, we must terminate the method properly */

acpi_ds_terminate_control_method(obj_desc, next_walk_state);
+   if (thread)
+   acpi_ds_pop_walk_state(thread);
acpi_ds_delete_walk_state(next_walk_state);

return_ACPI_STATUS(status);
--
1.9.1


___
Devel mailing list
de...@acpica.org
https://lists.acpica.org/mailman/listinfo/devel

Re: [PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

[Eric Anholt]

Rob Clark  writes:

> On Tue, Jul 26, 2016 at 7:11 PM, Eric Anholt  wrote:
>> Rob Clark  writes:
>>
>>> On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt  wrote:
 Overflow memory handling is tricky: While it's still referenced by the
 BPO registers, we want to keep it from being freed.  When we are
 putting a new set of overflow memory in the registers, we need to
 assign the old one to the last rendering job using it.

 We were looking at "what's currently running in the binner", but since
 the bin/render submission split, we may end up with the binner
 completing and having no new job while the renderer is still
 processing.  So, if we don't find a bin job at all, look at the
 highest-seqno (last) render job to attach our overflow to.
>>>
>>> so, drive-by comment.. but can you allocate gem bo's without backing
>>> them immediately with pages?  If so, just always allocate the bo
>>> up-front and attach it as a dependency of the batch, and only pin it
>>> to actual pages when you have to overflow?
>>
>> The amount of overflow for a given CL is arbitrary, depending on the
>> geometry submitted, and the overflow pool just gets streamed into by the
>> hardware as you submit bin jobs.  You'll end up allocating [0,n] new
>> overflows per bin job.  I don't see where "allocate gem BOs without
>> backing them immediately with pages" idea would fit into this.
>
> well, even not knowing the size up front shouldn't really be a
> show-stopper, unless you had to mmap it to userspace, perhaps..
> normally backing pages aren't allocated until drm_gem_get_pages() so
> allocating the gem bo as placeholder to track dependencies of the
> batch/submit shouldn't be an issue.  But I noticed you don't use
> drm_gem_get_pages().. maybe w/ cma helpers it is harder to decouple
> allocation of the drm_gem_object from the backing store.

There's no period of time between "I need to allocate an overflow BO"
and "I need pages in the BO", though.

I could have a different setup that allocated a massive (all of CMA?),
fresh overflow BO per CL and populated page ranges in it as I overflow,
but with CMA you really need to never do new allocations in the hot path
because you get to stop and wait approximately forever.  So you'd want
to chunk it up so you could cache the groups of contiguous pages of
overflow, and it turns out we already have a thing for this in the form
of GEM BOs.  Anyway, doing that that means you're losing out on the rest
of the last overflow BO for the new CL, expanding the working set in
your precious 256MB CMA area.

Well, OK, actually I *do* allocate a fresh overflow BO per CL today,
because of leftover bringup code that I think I could just delete at
this point.  I'm not doing that in a -fixes commit, though.


signature.asc
Description: PGP signature

Re: [PATCH 5/6] drm/vc4: Fix overflow mem unreferencing when the binner runs dry.

[Eric Anholt]

Rob Clark  writes:

> On Tue, Jul 26, 2016 at 7:11 PM, Eric Anholt  wrote:
>> Rob Clark  writes:
>>
>>> On Tue, Jul 26, 2016 at 4:47 PM, Eric Anholt  wrote:
 Overflow memory handling is tricky: While it's still referenced by the
 BPO registers, we want to keep it from being freed.  When we are
 putting a new set of overflow memory in the registers, we need to
 assign the old one to the last rendering job using it.

 We were looking at "what's currently running in the binner", but since
 the bin/render submission split, we may end up with the binner
 completing and having no new job while the renderer is still
 processing.  So, if we don't find a bin job at all, look at the
 highest-seqno (last) render job to attach our overflow to.
>>>
>>> so, drive-by comment.. but can you allocate gem bo's without backing
>>> them immediately with pages?  If so, just always allocate the bo
>>> up-front and attach it as a dependency of the batch, and only pin it
>>> to actual pages when you have to overflow?
>>
>> The amount of overflow for a given CL is arbitrary, depending on the
>> geometry submitted, and the overflow pool just gets streamed into by the
>> hardware as you submit bin jobs.  You'll end up allocating [0,n] new
>> overflows per bin job.  I don't see where "allocate gem BOs without
>> backing them immediately with pages" idea would fit into this.
>
> well, even not knowing the size up front shouldn't really be a
> show-stopper, unless you had to mmap it to userspace, perhaps..
> normally backing pages aren't allocated until drm_gem_get_pages() so
> allocating the gem bo as placeholder to track dependencies of the
> batch/submit shouldn't be an issue.  But I noticed you don't use
> drm_gem_get_pages().. maybe w/ cma helpers it is harder to decouple
> allocation of the drm_gem_object from the backing store.

There's no period of time between "I need to allocate an overflow BO"
and "I need pages in the BO", though.

I could have a different setup that allocated a massive (all of CMA?),
fresh overflow BO per CL and populated page ranges in it as I overflow,
but with CMA you really need to never do new allocations in the hot path
because you get to stop and wait approximately forever.  So you'd want
to chunk it up so you could cache the groups of contiguous pages of
overflow, and it turns out we already have a thing for this in the form
of GEM BOs.  Anyway, doing that that means you're losing out on the rest
of the last overflow BO for the new CL, expanding the working set in
your precious 256MB CMA area.

Well, OK, actually I *do* allocate a fresh overflow BO per CL today,
because of leftover bringup code that I think I could just delete at
this point.  I'm not doing that in a -fixes commit, though.


signature.asc
Description: PGP signature

[PATCH v4 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

At the hardware level, the J-Core PIT is integrated with the interrupt
controller, but it is represented as its own device and has an
independent programming interface. It provides a 12-bit countdown
timer, which is not presently used, and a periodic timer. The interval
length for the latter is programmable via a 32-bit throttle register
whose units are determined by a bus-period register. The periodic
timer is used to implement both periodic and oneshot clock event
modes; in oneshot mode the interrupt handler simply disables the timer
as soon as it fires.

Despite its device tree node representing an interrupt for the PIT,
the actual irq generated is programmable, not hard-wired. The driver
is responsible for programming the PIT to generate the hardware irq
number that the DT assigns to it.

On SMP configurations, J-Core provides cpu-local instances of the PIT;
no broadcast timer is needed. This driver supports the creation of the
necessary per-cpu clock_event_device instances. The code has been
tested and works on SMP, but will not be usable without additional
J-Core SMP-support patches and appropriate hardware capable of running
SMP.

A nanosecond-resolution clocksource is provided using the J-Core "RTC"
registers, which give a 64-bit seconds count and 32-bit nanoseconds.
The driver converts these to a 64-bit nanoseconds count.

Signed-off-by: Rich Felker 
---
 drivers/clocksource/Kconfig |   8 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/jcore-pit.c | 277 
 3 files changed, 286 insertions(+)
 create mode 100644 drivers/clocksource/jcore-pit.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 47352d2..b6d4d43 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -313,6 +313,14 @@ config SYS_SUPPORTS_SH_TMU
 config SYS_SUPPORTS_EM_STI
 bool
 
+config CLKSRC_JCORE_PIT
+   bool "J-Core PIT timer driver"
+   depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
+   help
+ This enables build of clocksource and clockevent driver for
+ the integrated PIT in the J-Core synthesizable, open source SoC.
+
 config SH_TIMER_CMT
bool "Renesas CMT timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 473974f..b41a834 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_ATMEL_TCB_CLKSRC)  += tcb_clksrc.o
 obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
 obj-$(CONFIG_SCx200HR_TIMER)   += scx200_hrt.o
 obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)   += cs5535-clockevt.o
+obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
new file mode 100644
index 000..373b9f9
--- /dev/null
+++ b/drivers/clocksource/jcore-pit.c
@@ -0,0 +1,277 @@
+/*
+ * J-Core SoC PIT/clocksource driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIT_IRQ_SHIFT 12
+#define PIT_PRIO_SHIFT 20
+#define PIT_ENABLE_SHIFT 26
+#define PIT_IRQ_MASK 0x3f
+#define PIT_PRIO_MASK 0xf
+
+#define REG_PITEN 0x00
+#define REG_THROT 0x10
+#define REG_COUNT 0x14
+#define REG_BUSPD 0x18
+#define REG_SECHI 0x20
+#define REG_SECLO 0x24
+#define REG_NSEC  0x28
+
+struct jcore_clocksource {
+   struct clocksource cs;
+   __iomem void *base;
+};
+
+struct jcore_pit {
+   struct clock_event_device ced;
+   __iomem void *base;
+   unsigned long periodic_delta;
+   unsigned cpu;
+   u32 enable_val;
+};
+
+struct jcore_pit_nb {
+   struct notifier_block nb;
+   struct jcore_pit __percpu *pit_percpu;
+};
+
+static struct clocksource *jcore_cs;
+
+static cycle_t jcore_clocksource_read(struct clocksource *cs)
+{
+   __iomem void *base =
+   container_of(cs, struct jcore_clocksource, cs)->base;
+   u32 sechi, seclo, nsec, sechi0, seclo0;
+
+   sechi = __raw_readl(base + REG_SECHI);
+   seclo = __raw_readl(base + REG_SECLO);
+   do {
+   sechi0 = sechi;
+   seclo0 = seclo;
+   nsec  = __raw_readl(base + REG_NSEC);
+   sechi = __raw_readl(base + REG_SECHI);
+   seclo = __raw_readl(base + REG_SECLO);
+   } while (sechi0 != sechi || seclo0 != seclo);
+
+   return ((u64)sechi << 32 | seclo) * NSEC_PER_SEC + nsec;
+}
+
+static notrace u64 jcore_sched_clock_read(void)
+{
+   return jcore_clocksource_read(jcore_cs);
+}
+

[PATCH v4 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

At the hardware level, the J-Core PIT is integrated with the interrupt
controller, but it is represented as its own device and has an
independent programming interface. It provides a 12-bit countdown
timer, which is not presently used, and a periodic timer. The interval
length for the latter is programmable via a 32-bit throttle register
whose units are determined by a bus-period register. The periodic
timer is used to implement both periodic and oneshot clock event
modes; in oneshot mode the interrupt handler simply disables the timer
as soon as it fires.

Despite its device tree node representing an interrupt for the PIT,
the actual irq generated is programmable, not hard-wired. The driver
is responsible for programming the PIT to generate the hardware irq
number that the DT assigns to it.

On SMP configurations, J-Core provides cpu-local instances of the PIT;
no broadcast timer is needed. This driver supports the creation of the
necessary per-cpu clock_event_device instances. The code has been
tested and works on SMP, but will not be usable without additional
J-Core SMP-support patches and appropriate hardware capable of running
SMP.

A nanosecond-resolution clocksource is provided using the J-Core "RTC"
registers, which give a 64-bit seconds count and 32-bit nanoseconds.
The driver converts these to a 64-bit nanoseconds count.

Signed-off-by: Rich Felker 
---
 drivers/clocksource/Kconfig |   8 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/jcore-pit.c | 277 
 3 files changed, 286 insertions(+)
 create mode 100644 drivers/clocksource/jcore-pit.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 47352d2..b6d4d43 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -313,6 +313,14 @@ config SYS_SUPPORTS_SH_TMU
 config SYS_SUPPORTS_EM_STI
 bool
 
+config CLKSRC_JCORE_PIT
+   bool "J-Core PIT timer driver"
+   depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
+   help
+ This enables build of clocksource and clockevent driver for
+ the integrated PIT in the J-Core synthesizable, open source SoC.
+
 config SH_TIMER_CMT
bool "Renesas CMT timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 473974f..b41a834 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_ATMEL_TCB_CLKSRC)  += tcb_clksrc.o
 obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
 obj-$(CONFIG_SCx200HR_TIMER)   += scx200_hrt.o
 obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)   += cs5535-clockevt.o
+obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
new file mode 100644
index 000..373b9f9
--- /dev/null
+++ b/drivers/clocksource/jcore-pit.c
@@ -0,0 +1,277 @@
+/*
+ * J-Core SoC PIT/clocksource driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIT_IRQ_SHIFT 12
+#define PIT_PRIO_SHIFT 20
+#define PIT_ENABLE_SHIFT 26
+#define PIT_IRQ_MASK 0x3f
+#define PIT_PRIO_MASK 0xf
+
+#define REG_PITEN 0x00
+#define REG_THROT 0x10
+#define REG_COUNT 0x14
+#define REG_BUSPD 0x18
+#define REG_SECHI 0x20
+#define REG_SECLO 0x24
+#define REG_NSEC  0x28
+
+struct jcore_clocksource {
+   struct clocksource cs;
+   __iomem void *base;
+};
+
+struct jcore_pit {
+   struct clock_event_device ced;
+   __iomem void *base;
+   unsigned long periodic_delta;
+   unsigned cpu;
+   u32 enable_val;
+};
+
+struct jcore_pit_nb {
+   struct notifier_block nb;
+   struct jcore_pit __percpu *pit_percpu;
+};
+
+static struct clocksource *jcore_cs;
+
+static cycle_t jcore_clocksource_read(struct clocksource *cs)
+{
+   __iomem void *base =
+   container_of(cs, struct jcore_clocksource, cs)->base;
+   u32 sechi, seclo, nsec, sechi0, seclo0;
+
+   sechi = __raw_readl(base + REG_SECHI);
+   seclo = __raw_readl(base + REG_SECLO);
+   do {
+   sechi0 = sechi;
+   seclo0 = seclo;
+   nsec  = __raw_readl(base + REG_NSEC);
+   sechi = __raw_readl(base + REG_SECHI);
+   seclo = __raw_readl(base + REG_SECLO);
+   } while (sechi0 != sechi || seclo0 != seclo);
+
+   return ((u64)sechi << 32 | seclo) * NSEC_PER_SEC + nsec;
+}
+
+static notrace u64 jcore_sched_clock_read(void)
+{
+   return jcore_clocksource_read(jcore_cs);
+}
+
+static int 

[PATCH v4 0/2] J-Core timer support

[Rich Felker]

This driver is used with the J2, an open-source VHDL reimplementation
of SH-2.

I've split this out from the main J-Core support patches going
upstream through my own linux-sh tree. Changes since the v3 are mainly
cleanup/simplification, inclusion of sched_clock support based on
suggestions by Daniel Lezcano, and reworking the DT bindings to use
separate reg ranges per cpu rather than cpu-offset for greater
flexibility.

Rich


Rich Felker (2):
  of: add J-Core timer bindings
  clocksource: add J-Core timer/clocksource driver

 .../devicetree/bindings/timer/jcore,pit.txt|  25 ++
 drivers/clocksource/Kconfig|   8 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/jcore-pit.c| 277 +
 4 files changed, 311 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt
 create mode 100644 drivers/clocksource/jcore-pit.c

-- 
2.8.1

[PATCH v4 1/2] of: add J-Core timer bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../devicetree/bindings/timer/jcore,pit.txt| 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt

diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt 
b/Documentation/devicetree/bindings/timer/jcore,pit.txt
new file mode 100644
index 000..0f42af4
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt
@@ -0,0 +1,25 @@
+J-Core Programmable Interval Timer and Clocksource
+
+Required properties:
+
+- compatible: Must be "jcore,pit".
+
+- reg: Memory region(s) for timer/clocksource registers. For SMP,
+  there should be one region per cpu, indexed by the sequential,
+  zero-based hardware cpu number (which is also the logical cpu
+  number).
+
+- interrupts: An interrupt to assign for the timer. The actual pit
+  core is integrated with the aic and allows the timer interrupt
+  assignment to be programmed by software, but this property is
+  required in order to reserve an interrupt number that doesn't
+  conflict with other devices.
+
+
+Example:
+
+timer@200 {
+   compatible = "jcore,pit";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupts = < 0x48 >;
+};
-- 
2.8.1

[PATCH v4 0/2] J-Core timer support

[Rich Felker]

This driver is used with the J2, an open-source VHDL reimplementation
of SH-2.

I've split this out from the main J-Core support patches going
upstream through my own linux-sh tree. Changes since the v3 are mainly
cleanup/simplification, inclusion of sched_clock support based on
suggestions by Daniel Lezcano, and reworking the DT bindings to use
separate reg ranges per cpu rather than cpu-offset for greater
flexibility.

Rich


Rich Felker (2):
  of: add J-Core timer bindings
  clocksource: add J-Core timer/clocksource driver

 .../devicetree/bindings/timer/jcore,pit.txt|  25 ++
 drivers/clocksource/Kconfig|   8 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/jcore-pit.c| 277 +
 4 files changed, 311 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt
 create mode 100644 drivers/clocksource/jcore-pit.c

-- 
2.8.1

[PATCH v4 1/2] of: add J-Core timer bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../devicetree/bindings/timer/jcore,pit.txt| 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt

diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt 
b/Documentation/devicetree/bindings/timer/jcore,pit.txt
new file mode 100644
index 000..0f42af4
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt
@@ -0,0 +1,25 @@
+J-Core Programmable Interval Timer and Clocksource
+
+Required properties:
+
+- compatible: Must be "jcore,pit".
+
+- reg: Memory region(s) for timer/clocksource registers. For SMP,
+  there should be one region per cpu, indexed by the sequential,
+  zero-based hardware cpu number (which is also the logical cpu
+  number).
+
+- interrupts: An interrupt to assign for the timer. The actual pit
+  core is integrated with the aic and allows the timer interrupt
+  assignment to be programmed by software, but this property is
+  required in order to reserve an interrupt number that doesn't
+  conflict with other devices.
+
+
+Example:
+
+timer@200 {
+   compatible = "jcore,pit";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupts = < 0x48 >;
+};
-- 
2.8.1

[PATCH v4 1/2] of: add J-Core interrupt controller bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../bindings/interrupt-controller/jcore,aic.txt| 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt 
b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
new file mode 100644
index 000..b7a56ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
@@ -0,0 +1,26 @@
+J-Core Advanced Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "jcore,aic1" for the (obsolete) first-generation aic
+  with 8 interrupt lines with programmable priorities, or "jcore,aic2" for
+  the "aic2" core with 64 interrupts.
+
+- reg: Memory region(s) for configuration. For SMP, there should be one
+  region per cpu, indexed by the sequential, zero-based hardware cpu
+  number (which is also the logical cpu number).
+
+- interrupt-controller: Identifies the node as an interrupt controller
+
+- #interrupt-cells: Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+
+
+Example:
+
+aic: interrupt-controller@200 {
+   compatible = "jcore,aic2";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+};
-- 
2.8.1

Re: [PATCH 1/6] extcon: Add the extcon_type to group each connector into five category

[Chanwoo Choi]

Hi Myungjoo,

On 2016년 07월 27일 13:27, MyungJoo Ham wrote:
>> This patch adds the new extcon type to group the each connecotr
>> into following five category. This type would be used to handle
>> the connectors as a group unit instead of a connector unit.
>> - EXTCON_TYPE_USB  : USB connector
>> - EXTCON_TYPE_CHG  : Charger connector
>> - EXTCON_TYPE_JACK : Jack connector
> 
> "Jack" seems to be an internal jargon that many people won't recognize.
> It's, in fact, 3.5-pi, isn't it?

You're right. But, the ALSA framework already used the 'jack' word
for headphone/headset/microphone for a long time. (sound/soc/soc-jack.c)
So, To prevent the confusion, I use the 'jack' word.

> 
> Anyway, this is already being used as an enum with drivers,
> I'd suggest to add a comment in extcon.h stating that 
> "Jack connector" is usually the 3.5-pi earbud connector.

Additionally,  jack means the the LINE_IN/OUT, VIDEO_IN/OUT,
SPDIF_IN/OUT in the extcon.

> 
> Anyway, I like the direction of this patch.

Thanks.

> 
> 
> Signed-off-by: MyungJoo Ham 

Regards,
Chanwoo Choi

> 
> Cheers,
> MyungJoo
> 
>> --- a/include/linux/extcon.h
>> +++ b/include/linux/extcon.h
>> @@ -29,6 +29,15 @@
>>  #include 
>>  
>>  /*
>> + * Define the type of supported external connectors
>> + */
>> +#define EXTCON_TYPE_USB BIT(0)  /* USB connector */
>> +#define EXTCON_TYPE_CHG BIT(1)  /* Charger connector */
>> +#define EXTCON_TYPE_JACKBIT(2)  /* Jack connector */
> +/* Usually, this is a 3.5-pi earbud conector 
> */
>> +#define EXTCON_TYPE_DISPBIT(3)  /* Display connector */
>> +#define EXTCON_TYPE_MISCBIT(4)  /* Miscellaneous connector */
>> +
>> +/*
>>   * Define the unique id of supported external connectors
>>   */
>>  #define EXTCON_NONE 0
>> -- 
>> 1.9.1
>>

[PATCH v4 1/2] of: add J-Core interrupt controller bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../bindings/interrupt-controller/jcore,aic.txt| 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt 
b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
new file mode 100644
index 000..b7a56ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
@@ -0,0 +1,26 @@
+J-Core Advanced Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "jcore,aic1" for the (obsolete) first-generation aic
+  with 8 interrupt lines with programmable priorities, or "jcore,aic2" for
+  the "aic2" core with 64 interrupts.
+
+- reg: Memory region(s) for configuration. For SMP, there should be one
+  region per cpu, indexed by the sequential, zero-based hardware cpu
+  number (which is also the logical cpu number).
+
+- interrupt-controller: Identifies the node as an interrupt controller
+
+- #interrupt-cells: Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+
+
+Example:
+
+aic: interrupt-controller@200 {
+   compatible = "jcore,aic2";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+};
-- 
2.8.1

Re: [PATCH 1/6] extcon: Add the extcon_type to group each connector into five category

[Chanwoo Choi]

Hi Myungjoo,

On 2016년 07월 27일 13:27, MyungJoo Ham wrote:
>> This patch adds the new extcon type to group the each connecotr
>> into following five category. This type would be used to handle
>> the connectors as a group unit instead of a connector unit.
>> - EXTCON_TYPE_USB  : USB connector
>> - EXTCON_TYPE_CHG  : Charger connector
>> - EXTCON_TYPE_JACK : Jack connector
> 
> "Jack" seems to be an internal jargon that many people won't recognize.
> It's, in fact, 3.5-pi, isn't it?

You're right. But, the ALSA framework already used the 'jack' word
for headphone/headset/microphone for a long time. (sound/soc/soc-jack.c)
So, To prevent the confusion, I use the 'jack' word.

> 
> Anyway, this is already being used as an enum with drivers,
> I'd suggest to add a comment in extcon.h stating that 
> "Jack connector" is usually the 3.5-pi earbud connector.

Additionally,  jack means the the LINE_IN/OUT, VIDEO_IN/OUT,
SPDIF_IN/OUT in the extcon.

> 
> Anyway, I like the direction of this patch.

Thanks.

> 
> 
> Signed-off-by: MyungJoo Ham 

Regards,
Chanwoo Choi

> 
> Cheers,
> MyungJoo
> 
>> --- a/include/linux/extcon.h
>> +++ b/include/linux/extcon.h
>> @@ -29,6 +29,15 @@
>>  #include 
>>  
>>  /*
>> + * Define the type of supported external connectors
>> + */
>> +#define EXTCON_TYPE_USB BIT(0)  /* USB connector */
>> +#define EXTCON_TYPE_CHG BIT(1)  /* Charger connector */
>> +#define EXTCON_TYPE_JACKBIT(2)  /* Jack connector */
> +/* Usually, this is a 3.5-pi earbud conector 
> */
>> +#define EXTCON_TYPE_DISPBIT(3)  /* Display connector */
>> +#define EXTCON_TYPE_MISCBIT(4)  /* Miscellaneous connector */
>> +
>> +/*
>>   * Define the unique id of supported external connectors
>>   */
>>  #define EXTCON_NONE 0
>> -- 
>> 1.9.1
>>

[PATCH v4 2/2] irqchip: add J-Core AIC driver

[Rich Felker]

There are two versions of the J-Core interrupt controller in use, aic1
which generates interrupts with programmable priorities, but only
supports 8 irq lines and maps them to cpu traps in the range 17 to 24,
and aic2 which uses traps in the range 64-127 and supports up to 128
irqs, with priorities dependent on the interrupt number. The Linux
driver does not make use of priorities anyway.

For simplicity, there is no aic1-specific logic in the driver beyond
setting the priority register, which is necessary for interrupts to
work at all. Eventually aic1 will likely be phased out, but it's
currently in use in deployments and all released bitstream binaries.

Signed-off-by: Rich Felker 
---
 drivers/irqchip/Kconfig |  6 
 drivers/irqchip/Makefile|  1 +
 drivers/irqchip/irq-jcore-aic.c | 79 +
 3 files changed, 86 insertions(+)
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index fa33c50..fe58177 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -150,6 +150,12 @@ config PIC32_EVIC
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config JCORE_AIC
+   bool "J-Core integrated AIC"
+   select IRQ_DOMAIN
+   help
+ Support for the J-Core integrated AIC.
+
 config RENESAS_INTC_IRQPIN
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..5b1a2fa 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_I8259)   += irq-i8259.o
 obj-$(CONFIG_IMGPDC_IRQ)   += irq-imgpdc.o
 obj-$(CONFIG_IRQ_MIPS_CPU) += irq-mips-cpu.o
 obj-$(CONFIG_SIRF_IRQ) += irq-sirfsoc.o
+obj-$(CONFIG_JCORE_AIC)+= irq-jcore-aic.o
 obj-$(CONFIG_RENESAS_INTC_IRQPIN)  += irq-renesas-intc-irqpin.o
 obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)   += irq-versatile-fpga.o
diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
new file mode 100644
index 000..7b3b30e
--- /dev/null
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -0,0 +1,79 @@
+/*
+ * J-Core SoC AIC driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AIC1_INTPRI 8
+
+static struct aic_data {
+   struct irq_chip chip;
+   struct irq_domain *domain;
+   struct notifier_block nb;
+} aic_data;
+
+static int aic_irqdomain_map(struct irq_domain *d, unsigned int irq, 
irq_hw_number_t hwirq)
+{
+   struct aic_data *aic = d->host_data;
+
+   irq_set_chip_data(irq, aic);
+   irq_set_chip_and_handler(irq, >chip, handle_simple_irq);
+   irq_set_probe(irq);
+
+   return 0;
+}
+
+static const struct irq_domain_ops aic_irqdomain_ops = {
+   .map = aic_irqdomain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void noop(struct irq_data *data)
+{
+}
+
+int __init aic_irq_of_init(struct device_node *node, struct device_node 
*parent)
+{
+   struct aic_data *aic = _data;
+   unsigned min_irq = 64;
+
+   pr_info("Initializing J-Core AIC\n");
+
+   if (!of_device_is_compatible(node, "jcore,aic2")) {
+   unsigned cpu;
+   for_each_possible_cpu(cpu) {
+   void __iomem *base = of_iomap(node, cpu);
+   if (!base)
+   continue;
+   pr_info("Local AIC1 enable for cpu %u at %p\n",
+   cpu, base + AIC1_INTPRI);
+   __raw_writel(0x, base + AIC1_INTPRI);
+   }
+   min_irq = 16;
+   }
+
+   aic->chip.name = node->name;
+   aic->chip.irq_mask = noop;
+   aic->chip.irq_unmask = noop;
+
+   aic->domain = irq_domain_add_linear(node, 128, _irqdomain_ops, aic);
+   irq_create_strict_mappings(aic->domain, min_irq, min_irq, 128-min_irq);
+
+   return 0;
+}
+
+IRQCHIP_DECLARE(jcore_aic2, "jcore,aic2", aic_irq_of_init);
+IRQCHIP_DECLARE(jcore_aic1, "jcore,aic1", aic_irq_of_init);
-- 
2.8.1

[PATCH v4 2/2] irqchip: add J-Core AIC driver

[Rich Felker]

There are two versions of the J-Core interrupt controller in use, aic1
which generates interrupts with programmable priorities, but only
supports 8 irq lines and maps them to cpu traps in the range 17 to 24,
and aic2 which uses traps in the range 64-127 and supports up to 128
irqs, with priorities dependent on the interrupt number. The Linux
driver does not make use of priorities anyway.

For simplicity, there is no aic1-specific logic in the driver beyond
setting the priority register, which is necessary for interrupts to
work at all. Eventually aic1 will likely be phased out, but it's
currently in use in deployments and all released bitstream binaries.

Signed-off-by: Rich Felker 
---
 drivers/irqchip/Kconfig |  6 
 drivers/irqchip/Makefile|  1 +
 drivers/irqchip/irq-jcore-aic.c | 79 +
 3 files changed, 86 insertions(+)
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index fa33c50..fe58177 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -150,6 +150,12 @@ config PIC32_EVIC
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config JCORE_AIC
+   bool "J-Core integrated AIC"
+   select IRQ_DOMAIN
+   help
+ Support for the J-Core integrated AIC.
+
 config RENESAS_INTC_IRQPIN
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..5b1a2fa 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_I8259)   += irq-i8259.o
 obj-$(CONFIG_IMGPDC_IRQ)   += irq-imgpdc.o
 obj-$(CONFIG_IRQ_MIPS_CPU) += irq-mips-cpu.o
 obj-$(CONFIG_SIRF_IRQ) += irq-sirfsoc.o
+obj-$(CONFIG_JCORE_AIC)+= irq-jcore-aic.o
 obj-$(CONFIG_RENESAS_INTC_IRQPIN)  += irq-renesas-intc-irqpin.o
 obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)   += irq-versatile-fpga.o
diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
new file mode 100644
index 000..7b3b30e
--- /dev/null
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -0,0 +1,79 @@
+/*
+ * J-Core SoC AIC driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AIC1_INTPRI 8
+
+static struct aic_data {
+   struct irq_chip chip;
+   struct irq_domain *domain;
+   struct notifier_block nb;
+} aic_data;
+
+static int aic_irqdomain_map(struct irq_domain *d, unsigned int irq, 
irq_hw_number_t hwirq)
+{
+   struct aic_data *aic = d->host_data;
+
+   irq_set_chip_data(irq, aic);
+   irq_set_chip_and_handler(irq, >chip, handle_simple_irq);
+   irq_set_probe(irq);
+
+   return 0;
+}
+
+static const struct irq_domain_ops aic_irqdomain_ops = {
+   .map = aic_irqdomain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void noop(struct irq_data *data)
+{
+}
+
+int __init aic_irq_of_init(struct device_node *node, struct device_node 
*parent)
+{
+   struct aic_data *aic = _data;
+   unsigned min_irq = 64;
+
+   pr_info("Initializing J-Core AIC\n");
+
+   if (!of_device_is_compatible(node, "jcore,aic2")) {
+   unsigned cpu;
+   for_each_possible_cpu(cpu) {
+   void __iomem *base = of_iomap(node, cpu);
+   if (!base)
+   continue;
+   pr_info("Local AIC1 enable for cpu %u at %p\n",
+   cpu, base + AIC1_INTPRI);
+   __raw_writel(0x, base + AIC1_INTPRI);
+   }
+   min_irq = 16;
+   }
+
+   aic->chip.name = node->name;
+   aic->chip.irq_mask = noop;
+   aic->chip.irq_unmask = noop;
+
+   aic->domain = irq_domain_add_linear(node, 128, _irqdomain_ops, aic);
+   irq_create_strict_mappings(aic->domain, min_irq, min_irq, 128-min_irq);
+
+   return 0;
+}
+
+IRQCHIP_DECLARE(jcore_aic2, "jcore,aic2", aic_irq_of_init);
+IRQCHIP_DECLARE(jcore_aic1, "jcore,aic1", aic_irq_of_init);
-- 
2.8.1

[PATCH v4 0/2] J-Core interrupt controller support

[Rich Felker]

This driver is used with the J2, an open-source VHDL reimplementation
of SH-2.

I've split this out from the main J-Core support patches going
upstream through my own linux-sh tree. Changes since the v3 stem out
of reworking the DT to use separate reg ranges per cpu rather than
cpu-offset. The intent is to avoid out-of-mapping arithmetic via
cpu-offset and to avoid artifically restricting how the hardware lays
out the mappings, but this also allows the cpu notifier logic which
was present before to be removed with simple iteration over the reg
ranges present in its place.

Rich


Rich Felker (2):
  of: add J-Core interrupt controller bindings
  irqchip: add J-Core AIC driver

 .../bindings/interrupt-controller/jcore,aic.txt| 26 +++
 drivers/irqchip/Kconfig|  6 ++
 drivers/irqchip/Makefile   |  1 +
 drivers/irqchip/irq-jcore-aic.c| 79 ++
 4 files changed, 112 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

-- 
2.8.1

[PATCH v4 0/2] J-Core interrupt controller support

[Rich Felker]

This driver is used with the J2, an open-source VHDL reimplementation
of SH-2.

I've split this out from the main J-Core support patches going
upstream through my own linux-sh tree. Changes since the v3 stem out
of reworking the DT to use separate reg ranges per cpu rather than
cpu-offset. The intent is to avoid out-of-mapping arithmetic via
cpu-offset and to avoid artifically restricting how the hardware lays
out the mappings, but this also allows the cpu notifier logic which
was present before to be removed with simple iteration over the reg
ranges present in its place.

Rich


Rich Felker (2):
  of: add J-Core interrupt controller bindings
  irqchip: add J-Core AIC driver

 .../bindings/interrupt-controller/jcore,aic.txt| 26 +++
 drivers/irqchip/Kconfig|  6 ++
 drivers/irqchip/Makefile   |  1 +
 drivers/irqchip/irq-jcore-aic.c| 79 ++
 4 files changed, 112 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

-- 
2.8.1

Re: [PATCH v3 01/12] of: add vendor prefix for J-Core

[Rich Felker]

On Wed, May 25, 2016 at 08:18:06AM -0500, Rob Herring wrote:
> On Wed, May 25, 2016 at 12:43 AM, Rich Felker  wrote:
> > The J-Core project (j-core.org) produces open source cpu and SoC
> > peripheral cores synthesizable as FPGA bitstreams or ASICs.
> >
> > Signed-off-by: Rich Felker 
> 
> Please add acks when posting subsequent versions.
> 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 86740d4..9c070b8 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -126,6 +126,7 @@ invensense  InvenSense Inc.
> >  isee   ISEE 2007 S.L.
> >  isil   Intersil
> >  issi   Integrated Silicon Solutions Inc.
> > +jcore  J-Core.org
> >  jedec  JEDEC Solid State Technology Association
> >  karo   Ka-Ro electronics GmbH
> >  keymileKeymile GmbH
> > --
> > 2.8.1

Since this was previously acked, can I include it in my tree for
upstreaming? Or do you want me to submit the patch again?

Rich

Re: [PATCH v3 01/12] of: add vendor prefix for J-Core

[Rich Felker]

On Wed, May 25, 2016 at 08:18:06AM -0500, Rob Herring wrote:
> On Wed, May 25, 2016 at 12:43 AM, Rich Felker  wrote:
> > The J-Core project (j-core.org) produces open source cpu and SoC
> > peripheral cores synthesizable as FPGA bitstreams or ASICs.
> >
> > Signed-off-by: Rich Felker 
> 
> Please add acks when posting subsequent versions.
> 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 86740d4..9c070b8 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -126,6 +126,7 @@ invensense  InvenSense Inc.
> >  isee   ISEE 2007 S.L.
> >  isil   Intersil
> >  issi   Integrated Silicon Solutions Inc.
> > +jcore  J-Core.org
> >  jedec  JEDEC Solid State Technology Association
> >  karo   Ka-Ro electronics GmbH
> >  keymileKeymile GmbH
> > --
> > 2.8.1

Since this was previously acked, can I include it in my tree for
upstreaming? Or do you want me to submit the patch again?

Rich

Re: [PATCH] clocksource: j-core: type fix init function return code

[Rich Felker]

On Tue, Jul 26, 2016 at 02:31:29PM +0200, Arnd Bergmann wrote:
> The CLOCKSOURCE_OF_DECLARE now takes a function that returns an 'int', but a 
> this
> new clocksource driver has just appeared in linux-next and causes a warning 
> because
> it has the old 'void' return value:
> 
> In file included from ../include/linux/clocksource.h:18:0,
>  from ../include/linux/clockchips.h:13,
>  from ../drivers/clocksource/jcore-pit.c:14:
> include/linux/of.h:1006:20: error: comparison of distinct pointer types lacks 
> a cast [-Werror]
> .data = (fn == (fn_type)NULL) ? fn : fn  }
> ^
> 
> This adapts the jcore_pit_init() function to the correct return type.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> ---
> The patch that introduces the warnign currently only exists in the linux-sh 
> git
> tree and showed up in linux-next this week.

I've removed the commit from my for-next branch since it's not
appropriate to go upstream through my tree. Your patch should still be
applied in the proper subsystem tree, though, I think. Daniel?

Rich


> ---
>  drivers/clocksource/jcore-pit.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
> index 373b9f954a5c..4a2f7803624b 100644
> --- a/drivers/clocksource/jcore-pit.c
> +++ b/drivers/clocksource/jcore-pit.c
> @@ -154,7 +154,7 @@ static irqreturn_t jcore_timer_interrupt(int irq, void 
> *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> -static void __init jcore_pit_init(struct device_node *node)
> +static int __init jcore_pit_init(struct device_node *node)
>  {
>   int err;
>   __iomem void *pit_base;
> @@ -169,12 +169,14 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   pit_base = of_iomap(node, 0);
>   if (!pit_base) {
>   pr_err("Error: Cannot map base address for J-Core PIT\n");
> + err = -ENXIO;
>   goto out;
>   }
>  
>   pit_irq = irq_of_parse_and_map(node, 0);
>   if (!pit_irq) {
>   pr_err("Error: J-Core PIT has no IRQ\n");
> + err = -ENXIO;
>   goto out;
>   }
>  
> @@ -183,6 +185,7 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   cs = kzalloc(sizeof *cs, GFP_KERNEL);
>   if (!cs) {
>   pr_err("Failed to allocate memory for clocksource\n");
> + err = ENOMEM;
>   goto out;
>   }
>   jcore_cs = >cs;
> @@ -207,12 +210,14 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   pit_percpu = alloc_percpu(struct jcore_pit);
>   if (!pit_percpu) {
>   pr_err("Failed to allocate memory for clock event device\n");
> + err = ENOMEM;
>   goto out;
>   }
>  
>   nb = kzalloc(sizeof *nb, GFP_KERNEL);
>   if (!nb) {
>   pr_err("Failed to allocate memory for J-Core PIT notifier\n");
> + err = ENOMEM;
>   goto out;
>   }
>  
> @@ -268,10 +273,11 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>  
>   jcore_pit_local_init(this_cpu_ptr(pit_percpu));
>  
> - return;
> + return 0;
>  
>  out:
>   pr_err("Could not initialize J-Core PIT driver\n");
> + return err;
>  }
>  
>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> -- 
> 2.9.0

Re: [PATCH] clocksource: j-core: type fix init function return code

[Rich Felker]

On Tue, Jul 26, 2016 at 02:31:29PM +0200, Arnd Bergmann wrote:
> The CLOCKSOURCE_OF_DECLARE now takes a function that returns an 'int', but a 
> this
> new clocksource driver has just appeared in linux-next and causes a warning 
> because
> it has the old 'void' return value:
> 
> In file included from ../include/linux/clocksource.h:18:0,
>  from ../include/linux/clockchips.h:13,
>  from ../drivers/clocksource/jcore-pit.c:14:
> include/linux/of.h:1006:20: error: comparison of distinct pointer types lacks 
> a cast [-Werror]
> .data = (fn == (fn_type)NULL) ? fn : fn  }
> ^
> 
> This adapts the jcore_pit_init() function to the correct return type.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: e0aa0655c60b ("clocksource: add J-Core timer/clocksource driver")
> ---
> The patch that introduces the warnign currently only exists in the linux-sh 
> git
> tree and showed up in linux-next this week.

I've removed the commit from my for-next branch since it's not
appropriate to go upstream through my tree. Your patch should still be
applied in the proper subsystem tree, though, I think. Daniel?

Rich


> ---
>  drivers/clocksource/jcore-pit.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
> index 373b9f954a5c..4a2f7803624b 100644
> --- a/drivers/clocksource/jcore-pit.c
> +++ b/drivers/clocksource/jcore-pit.c
> @@ -154,7 +154,7 @@ static irqreturn_t jcore_timer_interrupt(int irq, void 
> *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> -static void __init jcore_pit_init(struct device_node *node)
> +static int __init jcore_pit_init(struct device_node *node)
>  {
>   int err;
>   __iomem void *pit_base;
> @@ -169,12 +169,14 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   pit_base = of_iomap(node, 0);
>   if (!pit_base) {
>   pr_err("Error: Cannot map base address for J-Core PIT\n");
> + err = -ENXIO;
>   goto out;
>   }
>  
>   pit_irq = irq_of_parse_and_map(node, 0);
>   if (!pit_irq) {
>   pr_err("Error: J-Core PIT has no IRQ\n");
> + err = -ENXIO;
>   goto out;
>   }
>  
> @@ -183,6 +185,7 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   cs = kzalloc(sizeof *cs, GFP_KERNEL);
>   if (!cs) {
>   pr_err("Failed to allocate memory for clocksource\n");
> + err = ENOMEM;
>   goto out;
>   }
>   jcore_cs = >cs;
> @@ -207,12 +210,14 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>   pit_percpu = alloc_percpu(struct jcore_pit);
>   if (!pit_percpu) {
>   pr_err("Failed to allocate memory for clock event device\n");
> + err = ENOMEM;
>   goto out;
>   }
>  
>   nb = kzalloc(sizeof *nb, GFP_KERNEL);
>   if (!nb) {
>   pr_err("Failed to allocate memory for J-Core PIT notifier\n");
> + err = ENOMEM;
>   goto out;
>   }
>  
> @@ -268,10 +273,11 @@ static void __init jcore_pit_init(struct device_node 
> *node)
>  
>   jcore_pit_local_init(this_cpu_ptr(pit_percpu));
>  
> - return;
> + return 0;
>  
>  out:
>   pr_err("Could not initialize J-Core PIT driver\n");
> + return err;
>  }
>  
>  CLOCKSOURCE_OF_DECLARE(jcore_pit, "jcore,pit", jcore_pit_init);
> -- 
> 2.9.0

[PATCH BUGFIX V5] block: add missing group association in bio-cloning functions

[Paolo Valente]

When a bio is cloned, the newly created bio must be associated with
the same blkcg as the original bio (if BLK_CGROUP is enabled). If
this operation is not performed, then the new bio is not associated
with any group, and the group of the current task is returned when
the group of the bio is requested.

Depending on the cloning frequency, this may cause a large
percentage of the bios belonging to a given group to be treated
as if belonging to other groups (in most cases as if belonging to
the root group). The expected group isolation may thereby be broken.

This commit adds the missing association in bio-cloning functions.

Fixes: da2f0f74cf7d ("Btrfs: add support for blkio controllers")
Cc: sta...@vger.kernel.org # v4.3+

Signed-off-by: Paolo Valente 
Reviewed-by: Nikolay Borisov 
Reviewed-by: Jeff Moyer 
Acked-by: Tejun Heo 
---
Fixed a compilation issue reported by kbuild test robot
---
 block/bio.c  | 15 +++
 fs/btrfs/extent_io.c |  6 --
 include/linux/bio.h  |  3 +++
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 0e4aa42..4623869 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -579,6 +579,8 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src)
bio->bi_rw = bio_src->bi_rw;
bio->bi_iter = bio_src->bi_iter;
bio->bi_io_vec = bio_src->bi_io_vec;
+
+   bio_clone_blkcg_association(bio, bio_src);
 }
 EXPORT_SYMBOL(__bio_clone_fast);
 
@@ -684,6 +686,8 @@ integrity_clone:
}
}
 
+   bio_clone_blkcg_association(bio, bio_src);
+
return bio;
 }
 EXPORT_SYMBOL(bio_clone_bioset);
@@ -2005,6 +2009,17 @@ void bio_disassociate_task(struct bio *bio)
}
 }
 
+/**
+ * bio_clone_blkcg_association - clone blkcg association from src to dst bio
+ * @dst: destination bio
+ * @src: source bio
+ */
+void bio_clone_blkcg_association(struct bio *dst, struct bio *src)
+{
+   if (src->bi_css)
+   WARN_ON(bio_associate_blkcg(dst, src->bi_css));
+}
+
 #endif /* CONFIG_BLK_CGROUP */
 
 static void __init biovec_init_slabs(void)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 75533ad..92fe3f8 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2696,12 +2696,6 @@ struct bio *btrfs_bio_clone(struct bio *bio, gfp_t 
gfp_mask)
btrfs_bio->csum = NULL;
btrfs_bio->csum_allocated = NULL;
btrfs_bio->end_io = NULL;
-
-#ifdef CONFIG_BLK_CGROUP
-   /* FIXME, put this into bio_clone_bioset */
-   if (bio->bi_css)
-   bio_associate_blkcg(new, bio->bi_css);
-#endif
}
return new;
 }
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 9faebf7..75fadd2 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -527,11 +527,14 @@ extern unsigned int bvec_nr_vecs(unsigned short idx);
 int bio_associate_blkcg(struct bio *bio, struct cgroup_subsys_state 
*blkcg_css);
 int bio_associate_current(struct bio *bio);
 void bio_disassociate_task(struct bio *bio);
+void bio_clone_blkcg_association(struct bio *dst, struct bio *src);
 #else  /* CONFIG_BLK_CGROUP */
 static inline int bio_associate_blkcg(struct bio *bio,
struct cgroup_subsys_state *blkcg_css) { return 0; }
 static inline int bio_associate_current(struct bio *bio) { return -ENOENT; }
 static inline void bio_disassociate_task(struct bio *bio) { }
+static inline void bio_clone_blkcg_association(struct bio *dst,
+   struct bio *src) { }
 #endif /* CONFIG_BLK_CGROUP */
 
 #ifdef CONFIG_HIGHMEM
-- 
1.9.1

[PATCH BUGFIX V5] block: add missing group association in bio-cloning functions

[Paolo Valente]

When a bio is cloned, the newly created bio must be associated with
the same blkcg as the original bio (if BLK_CGROUP is enabled). If
this operation is not performed, then the new bio is not associated
with any group, and the group of the current task is returned when
the group of the bio is requested.

Depending on the cloning frequency, this may cause a large
percentage of the bios belonging to a given group to be treated
as if belonging to other groups (in most cases as if belonging to
the root group). The expected group isolation may thereby be broken.

This commit adds the missing association in bio-cloning functions.

Fixes: da2f0f74cf7d ("Btrfs: add support for blkio controllers")
Cc: sta...@vger.kernel.org # v4.3+

Signed-off-by: Paolo Valente 
Reviewed-by: Nikolay Borisov 
Reviewed-by: Jeff Moyer 
Acked-by: Tejun Heo 
---
Fixed a compilation issue reported by kbuild test robot
---
 block/bio.c  | 15 +++
 fs/btrfs/extent_io.c |  6 --
 include/linux/bio.h  |  3 +++
 3 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 0e4aa42..4623869 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -579,6 +579,8 @@ void __bio_clone_fast(struct bio *bio, struct bio *bio_src)
bio->bi_rw = bio_src->bi_rw;
bio->bi_iter = bio_src->bi_iter;
bio->bi_io_vec = bio_src->bi_io_vec;
+
+   bio_clone_blkcg_association(bio, bio_src);
 }
 EXPORT_SYMBOL(__bio_clone_fast);
 
@@ -684,6 +686,8 @@ integrity_clone:
}
}
 
+   bio_clone_blkcg_association(bio, bio_src);
+
return bio;
 }
 EXPORT_SYMBOL(bio_clone_bioset);
@@ -2005,6 +2009,17 @@ void bio_disassociate_task(struct bio *bio)
}
 }
 
+/**
+ * bio_clone_blkcg_association - clone blkcg association from src to dst bio
+ * @dst: destination bio
+ * @src: source bio
+ */
+void bio_clone_blkcg_association(struct bio *dst, struct bio *src)
+{
+   if (src->bi_css)
+   WARN_ON(bio_associate_blkcg(dst, src->bi_css));
+}
+
 #endif /* CONFIG_BLK_CGROUP */
 
 static void __init biovec_init_slabs(void)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 75533ad..92fe3f8 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2696,12 +2696,6 @@ struct bio *btrfs_bio_clone(struct bio *bio, gfp_t 
gfp_mask)
btrfs_bio->csum = NULL;
btrfs_bio->csum_allocated = NULL;
btrfs_bio->end_io = NULL;
-
-#ifdef CONFIG_BLK_CGROUP
-   /* FIXME, put this into bio_clone_bioset */
-   if (bio->bi_css)
-   bio_associate_blkcg(new, bio->bi_css);
-#endif
}
return new;
 }
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 9faebf7..75fadd2 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -527,11 +527,14 @@ extern unsigned int bvec_nr_vecs(unsigned short idx);
 int bio_associate_blkcg(struct bio *bio, struct cgroup_subsys_state 
*blkcg_css);
 int bio_associate_current(struct bio *bio);
 void bio_disassociate_task(struct bio *bio);
+void bio_clone_blkcg_association(struct bio *dst, struct bio *src);
 #else  /* CONFIG_BLK_CGROUP */
 static inline int bio_associate_blkcg(struct bio *bio,
struct cgroup_subsys_state *blkcg_css) { return 0; }
 static inline int bio_associate_current(struct bio *bio) { return -ENOENT; }
 static inline void bio_disassociate_task(struct bio *bio) { }
+static inline void bio_clone_blkcg_association(struct bio *dst,
+   struct bio *src) { }
 #endif /* CONFIG_BLK_CGROUP */
 
 #ifdef CONFIG_HIGHMEM
-- 
1.9.1

Re: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s

[Darren Hart]

On Fri, Jul 22, 2016 at 03:01:24PM -0500, Mario Limonciello wrote:
> The Dell Rugged 7202 has 3 programmable buttons (labeled P1, P2, P3)
> and a detachable magnetic keyboard/mouse.
> 
> Signed-off-by: Mario Limonciello 

+Pali

Pali, any concerns?

> ---
>  drivers/platform/x86/dell-wmi.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index 15c6f11..6ba42d0 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -222,6 +222,16 @@ static const struct key_entry dell_wmi_extra_keymap[] 
> __initconst = {
>  
>   /* Stealth mode toggle */
>   { KE_IGNORE, 0x155, { KEY_RESERVED } },
> +
> + /* Rugged magnetic keyboard/mouse events */
> + { KE_IGNORE, 0x156, { KEY_RESERVED } },
> + { KE_IGNORE, 0x157, { KEY_RESERVED } },
> +
> + /* Rugged programmable (P1/P2/P3 keys) */
> + { KE_KEY, 0x850, { KEY_PROG1 } },
> + { KE_KEY, 0x851, { KEY_PROG2 } },
> + { KE_KEY, 0x852, { KEY_PROG3 } },
> +
>  };
>  
>  static struct input_dev *dell_wmi_input_dev;
> -- 
> 2.7.4
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] dell-wmi: Add events created by Dell Rugged 2-in-1s

[Darren Hart]

On Fri, Jul 22, 2016 at 03:01:24PM -0500, Mario Limonciello wrote:
> The Dell Rugged 7202 has 3 programmable buttons (labeled P1, P2, P3)
> and a detachable magnetic keyboard/mouse.
> 
> Signed-off-by: Mario Limonciello 

+Pali

Pali, any concerns?

> ---
>  drivers/platform/x86/dell-wmi.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
> index 15c6f11..6ba42d0 100644
> --- a/drivers/platform/x86/dell-wmi.c
> +++ b/drivers/platform/x86/dell-wmi.c
> @@ -222,6 +222,16 @@ static const struct key_entry dell_wmi_extra_keymap[] 
> __initconst = {
>  
>   /* Stealth mode toggle */
>   { KE_IGNORE, 0x155, { KEY_RESERVED } },
> +
> + /* Rugged magnetic keyboard/mouse events */
> + { KE_IGNORE, 0x156, { KEY_RESERVED } },
> + { KE_IGNORE, 0x157, { KEY_RESERVED } },
> +
> + /* Rugged programmable (P1/P2/P3 keys) */
> + { KE_KEY, 0x850, { KEY_PROG1 } },
> + { KE_KEY, 0x851, { KEY_PROG2 } },
> + { KE_KEY, 0x852, { KEY_PROG3 } },
> +
>  };
>  
>  static struct input_dev *dell_wmi_input_dev;
> -- 
> 2.7.4
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH v4] ARM: dts: sun8i: Add dts file for Olimex A33-OLinuXino

[stefan . mavrodiev]

On Tuesday, July 26, 2016 5:33:52 PM EEST Maxime Ripard wrote:
> Hi Stefan,
> 
> On Mon, Jul 25, 2016 at 03:37:23PM +0300, Stefan Mavrodiev wrote:
> > A33-OLinuXino is A33 development board designed by Olimex LTD.
> > 
> > It has AXP233 PMU, 1GB DRAM, a micro SD card, one USB-OTG connector,
> > headphone and mic jacks, connector for LiPo battery and optional
> > 4GB NAND Flash.
> > 
> > It has two 40-pin headers. One for LCD panel, and one for
> > additional modules. Also there is CSI/DSI connector.
> > 
> > Signed-off-by: Stefan Mavrodiev 
> 
> It looks mostly good, a few comments though.
> 
> > + {
> > +   led_pin_olinuxino: led_pins@0 {
> > +   allwinner,pins = "PB7";
> > +allwinner,function = "gpio_out";
> 
> This line is not properly indented.
> 
> > +   allwinner,drive = ;
> > +   allwinner,pull = ;
> > +};
> 
> And this one too.
> 
> > +_dc1sw {
> > +   regulator-name = "vcc-lcd";
> > +};
> 
> No constraints on this one?
> 
> > +_dcdc1 {
> > +   regulator-always-on;
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   regulator-name = "vcc-dsi";
> > +};
> 
> What is it used for? Is it really necessary to keep it on at all time?

I think so.
This is the supply for the MMC.
> 
> Thanks,
> Maxime

Best regards,
Stefan Mavrodiev

Re: [PATCH v4] ARM: dts: sun8i: Add dts file for Olimex A33-OLinuXino

[stefan . mavrodiev]

On Tuesday, July 26, 2016 5:33:52 PM EEST Maxime Ripard wrote:
> Hi Stefan,
> 
> On Mon, Jul 25, 2016 at 03:37:23PM +0300, Stefan Mavrodiev wrote:
> > A33-OLinuXino is A33 development board designed by Olimex LTD.
> > 
> > It has AXP233 PMU, 1GB DRAM, a micro SD card, one USB-OTG connector,
> > headphone and mic jacks, connector for LiPo battery and optional
> > 4GB NAND Flash.
> > 
> > It has two 40-pin headers. One for LCD panel, and one for
> > additional modules. Also there is CSI/DSI connector.
> > 
> > Signed-off-by: Stefan Mavrodiev 
> 
> It looks mostly good, a few comments though.
> 
> > + {
> > +   led_pin_olinuxino: led_pins@0 {
> > +   allwinner,pins = "PB7";
> > +allwinner,function = "gpio_out";
> 
> This line is not properly indented.
> 
> > +   allwinner,drive = ;
> > +   allwinner,pull = ;
> > +};
> 
> And this one too.
> 
> > +_dc1sw {
> > +   regulator-name = "vcc-lcd";
> > +};
> 
> No constraints on this one?
> 
> > +_dcdc1 {
> > +   regulator-always-on;
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   regulator-name = "vcc-dsi";
> > +};
> 
> What is it used for? Is it really necessary to keep it on at all time?

I think so.
This is the supply for the MMC.
> 
> Thanks,
> Maxime

Best regards,
Stefan Mavrodiev

Re: [PATCH 11/13] rapidio: modify for rev.3 specification changes

[Michael Ellerman]

Alexandre Bounine  writes:

> Implement changes made in RapidIO specification rev.3 to LP-Serial Physical
> Layer register definitions:
> - use per-port register offset calculations based on LP-Serial Extended
>   Features Block (EFB) Register Map type (I or II) with different per-port
>   offset step (0x20 vs. 0x40 respectfully).
> - remove deprecated Parallel Physical layer definitions and related code.
>
> Signed-off-by: Alexandre Bounine 
> Tested-by: Barry Wood 
> Cc: Matt Porter 
> Cc: Andre van Herk 
> Cc: Barry Wood 
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/rapidio/devices/rio_mport_cdev.c |2 +-
>  drivers/rapidio/devices/tsi721.c |8 +-
>  drivers/rapidio/rio-scan.c   |   74 +++--
>  drivers/rapidio/rio.c|  149 ++-
>  drivers/rapidio/rio.h|2 +-
>  drivers/rapidio/switches/tsi57x.c|   26 ++---
>  include/linux/rio.h  |   11 +--
>  include/linux/rio_regs.h |  167 +++--
>  8 files changed, 248 insertions(+), 191 deletions(-)

This is breaking the build for me on powerpc, for
corenet64_smp_defconfig at least.

eg.

http://kisskb.ellerman.id.au/kisskb/buildresult/12750751/

Commit:   Add linux-next specific files for 20160722
  13123042d0dbf7635f052efc2ae69fd9af624f1d
Compiler: powerpc-linux-gcc (GCC) 4.6.3

Possible errors
---

arch/powerpc/sysdev/fsl_rio.c:702:11: error: 'struct rio_mport' has no member 
named 'phy_type'
arch/powerpc/sysdev/fsl_rio.c:702:25: error: 'RIO_PHY_SERIAL' undeclared (first 
use in this function)
make[2]: *** [arch/powerpc/sysdev/fsl_rio.o] Error 1
make[1]: *** [arch/powerpc/sysdev] Error 2
make: *** [sub-make] Error 2

cheers

Re: [PATCH 11/13] rapidio: modify for rev.3 specification changes

[Michael Ellerman]

Alexandre Bounine  writes:

> Implement changes made in RapidIO specification rev.3 to LP-Serial Physical
> Layer register definitions:
> - use per-port register offset calculations based on LP-Serial Extended
>   Features Block (EFB) Register Map type (I or II) with different per-port
>   offset step (0x20 vs. 0x40 respectfully).
> - remove deprecated Parallel Physical layer definitions and related code.
>
> Signed-off-by: Alexandre Bounine 
> Tested-by: Barry Wood 
> Cc: Matt Porter 
> Cc: Andre van Herk 
> Cc: Barry Wood 
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/rapidio/devices/rio_mport_cdev.c |2 +-
>  drivers/rapidio/devices/tsi721.c |8 +-
>  drivers/rapidio/rio-scan.c   |   74 +++--
>  drivers/rapidio/rio.c|  149 ++-
>  drivers/rapidio/rio.h|2 +-
>  drivers/rapidio/switches/tsi57x.c|   26 ++---
>  include/linux/rio.h  |   11 +--
>  include/linux/rio_regs.h |  167 +++--
>  8 files changed, 248 insertions(+), 191 deletions(-)

This is breaking the build for me on powerpc, for
corenet64_smp_defconfig at least.

eg.

http://kisskb.ellerman.id.au/kisskb/buildresult/12750751/

Commit:   Add linux-next specific files for 20160722
  13123042d0dbf7635f052efc2ae69fd9af624f1d
Compiler: powerpc-linux-gcc (GCC) 4.6.3

Possible errors
---

arch/powerpc/sysdev/fsl_rio.c:702:11: error: 'struct rio_mport' has no member 
named 'phy_type'
arch/powerpc/sysdev/fsl_rio.c:702:25: error: 'RIO_PHY_SERIAL' undeclared (first 
use in this function)
make[2]: *** [arch/powerpc/sysdev/fsl_rio.o] Error 1
make[1]: *** [arch/powerpc/sysdev] Error 2
make: *** [sub-make] Error 2

cheers

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/vmx.c

between commit:

  4e59516a12a6 ("kvm: vmx: ensure VMCS is current while enabling PML")

from Linus' tree and commit:

  37e4c997dadf ("KVM: VMX: validate individual bits of guest 
MSR_IA32_FEATURE_CONTROL")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index df4a3b818048,b61cdadf8623..
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -8954,6 -9086,20 +9105,8 @@@ static struct kvm_vcpu *vmx_create_vcpu
vmx->nested.current_vmptr = -1ull;
vmx->nested.current_vmcs12 = NULL;
  
 -  /*
 -   * If PML is turned on, failure on enabling PML just results in failure
 -   * of creating the vcpu, therefore we can simplify PML logic (by
 -   * avoiding dealing with cases, such as enabling PML partially on vcpus
 -   * for the guest, etc.
 -   */
 -  if (enable_pml) {
 -  err = vmx_create_pml_buffer(vmx);
 -  if (err)
 -  goto free_vmcs;
 -  }
 -
+   vmx->msr_ia32_feature_control_valid_bits = FEATURE_CONTROL_LOCKED;
+ 
return >vcpu;
  
  free_vmcs:
@@@ -10913,7 -11149,17 +11161,17 @@@ out
return ret;
  }
  
+ static void vmx_setup_mce(struct kvm_vcpu *vcpu)
+ {
+   if (vcpu->arch.mcg_cap & MCG_LMCE_P)
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits |=
+   FEATURE_CONTROL_LMCE;
+   else
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits &=
+   ~FEATURE_CONTROL_LMCE;
+ }
+ 
 -static struct kvm_x86_ops vmx_x86_ops = {
 +static struct kvm_x86_ops vmx_x86_ops __ro_after_init = {
.cpu_has_kvm_support = cpu_has_kvm_support,
.disabled_by_bios = vmx_disabled_by_bios,
.hardware_setup = hardware_setup,

linux-next: manual merge of the kvm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/x86/kvm/vmx.c

between commit:

  4e59516a12a6 ("kvm: vmx: ensure VMCS is current while enabling PML")

from Linus' tree and commit:

  37e4c997dadf ("KVM: VMX: validate individual bits of guest 
MSR_IA32_FEATURE_CONTROL")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kvm/vmx.c
index df4a3b818048,b61cdadf8623..
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@@ -8954,6 -9086,20 +9105,8 @@@ static struct kvm_vcpu *vmx_create_vcpu
vmx->nested.current_vmptr = -1ull;
vmx->nested.current_vmcs12 = NULL;
  
 -  /*
 -   * If PML is turned on, failure on enabling PML just results in failure
 -   * of creating the vcpu, therefore we can simplify PML logic (by
 -   * avoiding dealing with cases, such as enabling PML partially on vcpus
 -   * for the guest, etc.
 -   */
 -  if (enable_pml) {
 -  err = vmx_create_pml_buffer(vmx);
 -  if (err)
 -  goto free_vmcs;
 -  }
 -
+   vmx->msr_ia32_feature_control_valid_bits = FEATURE_CONTROL_LOCKED;
+ 
return >vcpu;
  
  free_vmcs:
@@@ -10913,7 -11149,17 +11161,17 @@@ out
return ret;
  }
  
+ static void vmx_setup_mce(struct kvm_vcpu *vcpu)
+ {
+   if (vcpu->arch.mcg_cap & MCG_LMCE_P)
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits |=
+   FEATURE_CONTROL_LMCE;
+   else
+   to_vmx(vcpu)->msr_ia32_feature_control_valid_bits &=
+   ~FEATURE_CONTROL_LMCE;
+ }
+ 
 -static struct kvm_x86_ops vmx_x86_ops = {
 +static struct kvm_x86_ops vmx_x86_ops __ro_after_init = {
.cpu_has_kvm_support = cpu_has_kvm_support,
.disabled_by_bios = vmx_disabled_by_bios,
.hardware_setup = hardware_setup,

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

[Andrew Vagin]

On Tue, Jul 26, 2016 at 11:32:25AM -0700, W. Trevor King wrote:
> On Tue, Jul 26, 2016 at 11:25:24AM -0700, Andrew Vagin wrote:
> > Sure. If a process wants to compare two namespaces, it needs to get file
> > descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
> > process which has them),
> > and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
> 
> If you use the new ioctl-s to get ns_fd2, do you walk your local /proc
> to find pid2?

If you use the new ioctl-s to get nf_fd2, you will have it in the
current process, so pid2 will be getpid().

pidX identifies a process where to find fdX.

man 2 kcmp:
 The kcmp() system call can be used to check whether the  two processes
 identified  by  pid1  and  pid2 share a kernel resource such as virtual
 memory, file descriptors, and so on.

> 
> Cheers,
> Trevor
> 
> -- 
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Re: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

[Andrew Vagin]

On Tue, Jul 26, 2016 at 11:32:25AM -0700, W. Trevor King wrote:
> On Tue, Jul 26, 2016 at 11:25:24AM -0700, Andrew Vagin wrote:
> > Sure. If a process wants to compare two namespaces, it needs to get file
> > descriptors for them (open /proc/PID/ns/XXX, use new ioctl-s, find a
> > process which has them),
> > and then it calls kcmp(pid1, pid2, KCMP_NSFD, ns_fd1, ns_fd2)
> 
> If you use the new ioctl-s to get ns_fd2, do you walk your local /proc
> to find pid2?

If you use the new ioctl-s to get nf_fd2, you will have it in the
current process, so pid2 will be getpid().

pidX identifies a process where to find fdX.

man 2 kcmp:
 The kcmp() system call can be used to check whether the  two processes
 identified  by  pid1  and  pid2 share a kernel resource such as virtual
 memory, file descriptors, and so on.

> 
> Cheers,
> Trevor
> 
> -- 
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Re: [PATCH 4.4 000/146] 4.4.16-stable review

[Greg Kroah-Hartman]

On Tue, Jul 26, 2016 at 02:55:35PM -0700, Kevin Hilman wrote:
> kernelci.org bot  writes:
> 
> > stable-rc boot: 353 boots: 7 failed, 345 passed with 1 offline 
> > (v4.4.15-147-g0b4b25c69607)
> >
> > Full Boot Summary: 
> > https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.15-147-g0b4b25c69607/
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/kernel/v4.4.15-147-g0b4b25c69607/
> >
> > Tree: stable-rc
> > Branch: local/linux-4.4.y
> > Git Describe: v4.4.15-147-g0b4b25c69607
> > Git Commit: 0b4b25c69607c7515308f6a2beb6120dec2ad9dc
> > Git URL: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Tested: 64 unique boards, 17 SoC families, 27 builds out of 140
> >
> > Boot Failures Detected: 
> > https://kernelci.org/boot/?v4.4.15-147-g0b4b25c69607
> >
> > arm64:
> >
> > defconfig:
> > apm-mustang-kvm-guest: 1 failed lab
> > apm-mustang-kvm-uefi-guest: 1 failed lab
> > juno-kvm-guest: 1 failed lab
> > juno-kvm-uefi-guest: 1 failed lab
> 
> Can be ignored.  KVM issues with the qemu on the rootfs, under
> investigation.
> 
> > arm:
> >
> > multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> > sun9i-a80-optimus: 1 failed lab
> >
> > sunxi_defconfig:
> > sun9i-a80-optimus: 1 failed lab
> >
> > multi_v7_defconfig+CONFIG_LKDTM=y:
> > sun9i-a80-optimus: 1 failed lab
> 
> These ones look legit.
> 
> I've asked the folks in the Free Electrons lab to have a closer look at
> this one.

Ok, thanks, let me know if they find I messed anything up.

greg k-h

Re: [PATCH 4.4 000/146] 4.4.16-stable review

[Greg Kroah-Hartman]

On Tue, Jul 26, 2016 at 02:55:35PM -0700, Kevin Hilman wrote:
> kernelci.org bot  writes:
> 
> > stable-rc boot: 353 boots: 7 failed, 345 passed with 1 offline 
> > (v4.4.15-147-g0b4b25c69607)
> >
> > Full Boot Summary: 
> > https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.15-147-g0b4b25c69607/
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/kernel/v4.4.15-147-g0b4b25c69607/
> >
> > Tree: stable-rc
> > Branch: local/linux-4.4.y
> > Git Describe: v4.4.15-147-g0b4b25c69607
> > Git Commit: 0b4b25c69607c7515308f6a2beb6120dec2ad9dc
> > Git URL: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Tested: 64 unique boards, 17 SoC families, 27 builds out of 140
> >
> > Boot Failures Detected: 
> > https://kernelci.org/boot/?v4.4.15-147-g0b4b25c69607
> >
> > arm64:
> >
> > defconfig:
> > apm-mustang-kvm-guest: 1 failed lab
> > apm-mustang-kvm-uefi-guest: 1 failed lab
> > juno-kvm-guest: 1 failed lab
> > juno-kvm-uefi-guest: 1 failed lab
> 
> Can be ignored.  KVM issues with the qemu on the rootfs, under
> investigation.
> 
> > arm:
> >
> > multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> > sun9i-a80-optimus: 1 failed lab
> >
> > sunxi_defconfig:
> > sun9i-a80-optimus: 1 failed lab
> >
> > multi_v7_defconfig+CONFIG_LKDTM=y:
> > sun9i-a80-optimus: 1 failed lab
> 
> These ones look legit.
> 
> I've asked the folks in the Free Electrons lab to have a closer look at
> this one.

Ok, thanks, let me know if they find I messed anything up.

greg k-h

Re: [PATCH 4.6 000/203] 4.6.5-stable review

[Greg Kroah-Hartman]

On Tue, Jul 26, 2016 at 02:27:54PM -0700, Kevin Hilman wrote:
> kernelci.org bot  writes:
> 
> > stable-rc boot: 670 boots: 4 failed, 662 passed with 3 offline, 1 conflict 
> > (v4.6.4-204-g02256e5f7d73)
> >
> > Full Boot Summary: 
> > https://kernelci.org/boot/all/job/stable-rc/kernel/v4.6.4-204-g02256e5f7d73/
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/kernel/v4.6.4-204-g02256e5f7d73/
> >
> > Tree: stable-rc
> > Branch: local/linux-4.6.y
> > Git Describe: v4.6.4-204-g02256e5f7d73
> > Git Commit: 02256e5f7d734c5aa48de4310ca72f1887aea3d4
> > Git URL: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Tested: 106 unique boards, 25 SoC families, 36 builds out of 140
> >
> > Boot Failures Detected: 
> > https://kernelci.org/boot/?v4.6.4-204-g02256e5f7d73
> >
> > arm64:
> >
> > defconfig:
> > apm-mustang-kvm-guest: 1 failed lab
> > apm-mustang-kvm-uefi-guest: 1 failed lab
> > juno-kvm-uefi-guest: 1 failed lab
> >
> 
> Can be ignored: ongoing KVM issues with qemu on the rootfs here.  
> 
> > arm:
> >
> > multi_v7_defconfig+CONFIG_EFI=y:
> > am335x-bone: 1 failed lab
> 
> After retry: PASS
> 
> I re-ran this one a few times and it's OK, not sure what happend.

Thanks for letting me know.

greg k-h

Re: [PATCH 4.6 000/203] 4.6.5-stable review

[Greg Kroah-Hartman]

On Tue, Jul 26, 2016 at 02:27:54PM -0700, Kevin Hilman wrote:
> kernelci.org bot  writes:
> 
> > stable-rc boot: 670 boots: 4 failed, 662 passed with 3 offline, 1 conflict 
> > (v4.6.4-204-g02256e5f7d73)
> >
> > Full Boot Summary: 
> > https://kernelci.org/boot/all/job/stable-rc/kernel/v4.6.4-204-g02256e5f7d73/
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/kernel/v4.6.4-204-g02256e5f7d73/
> >
> > Tree: stable-rc
> > Branch: local/linux-4.6.y
> > Git Describe: v4.6.4-204-g02256e5f7d73
> > Git Commit: 02256e5f7d734c5aa48de4310ca72f1887aea3d4
> > Git URL: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Tested: 106 unique boards, 25 SoC families, 36 builds out of 140
> >
> > Boot Failures Detected: 
> > https://kernelci.org/boot/?v4.6.4-204-g02256e5f7d73
> >
> > arm64:
> >
> > defconfig:
> > apm-mustang-kvm-guest: 1 failed lab
> > apm-mustang-kvm-uefi-guest: 1 failed lab
> > juno-kvm-uefi-guest: 1 failed lab
> >
> 
> Can be ignored: ongoing KVM issues with qemu on the rootfs here.  
> 
> > arm:
> >
> > multi_v7_defconfig+CONFIG_EFI=y:
> > am335x-bone: 1 failed lab
> 
> After retry: PASS
> 
> I re-ran this one a few times and it's OK, not sure what happend.

Thanks for letting me know.

greg k-h

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[Greg KH]

On Tue, Jul 26, 2016 at 07:05:37PM -0700, k...@exchange.microsoft.com wrote:
> +/*
> + * Create a char device that can support read/write for passing
> + * the payload.
> + */

That sounds "interesting"...

> +
> +static struct completion ip_event;
> +static bool opened;
> +
> +char hvnd_ip_addr[4];
> +char hvnd_mac_addr[6];
> +bool hvnd_addr_set;

Global variables?

> +
> +int hvnd_get_ip_addr(char **ip_addr, char **mac_addr)
> +{
> + int t;
> +
> + /*
> +  * Now wait for the user level daemon to get us the
> +  * IP addresses bound to the MAC address.
> +  */
> + if (!hvnd_addr_set) {
> + t = wait_for_completion_timeout(_event, 600*HZ);
> + if (t == 0)
> + return -ETIMEDOUT;
> + }
> +
> + if (hvnd_addr_set) {
> + *ip_addr = hvnd_ip_addr;
> + *mac_addr = hvnd_mac_addr;
> + return 0;
> + }
> +
> + return -ENODATA;
> +}
> +
> +static ssize_t hvnd_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + char input[120];
> + int scaned, i;
> + unsigned int mac_addr[6], ip_addr[4];
> +
> + if (hvnd_addr_set) {
> + hvnd_error("IP/MAC address already set, ignoring input\n");
> + return count;
> + }
> +
> + if (count > sizeof(input)-1)
> + return -EINVAL;
> +
> + if (copy_from_user(input, buf, count))
> + return -EFAULT;
> +
> + input[count] = 0;
> +
> + /*
> +  * Wakeup the context that may be waiting for this.
> +  */
> + hvnd_debug("get user mode input: %s\n", input);
> +
> + scaned = sscanf(input,
> + "rdmaMacAddress=\"%x:%x:%x:%x:%x:%x\" 
> rdmaIPv4Address=\"%u.%u.%u.%u\"",
> + _addr[0],
> + _addr[1],
> + _addr[2],
> + _addr[3],
> + _addr[4],
> + _addr[5],
> + _addr[0],
> + _addr[1],
> + _addr[2],
> + _addr[3]);

Oh, that's a mess, you are going to parse text in the kernel that is
passed on a char device?  Please tell me that not all IB drivers are
like this...

> +
> + if (scaned == 10) {
> +
> + for (i = 0; i < 6; i++)
> + hvnd_mac_addr[i] = (char) mac_addr[i];
> + for (i = 0; i < 4; i++)
> + hvnd_ip_addr[i] = (char) ip_addr[i];
> +
> + hvnd_error("Scanned IP address: %pI4 Mac address: %pM\n",
> +hvnd_ip_addr, hvnd_mac_addr);
> +
> + hvnd_addr_set = true;
> + complete(_event);
> + }
> +
> + return count;
> +}
> +
> +static int hvnd_open(struct inode *inode, struct file *f)
> +{
> + /*
> +  * The user level daemon that will open this device is
> +  * really an extension of this driver. We can have only
> +  * active open at a time.

Do you have a pointer to that code?  As it's a logical extension, you
know what the license for that code better be... :)

> +  */
> + if (opened)
> + return -EBUSY;

You just raced, and lost, oops :(

There are better ways to do this, the easiest being, why do you need
"exclusive" access at all?

> +
> + /*
> +  * The daemon is alive; setup the state.
> +  */
> + opened = true;
> + return 0;
> +}
> +
> +static int hvnd_release(struct inode *inode, struct file *f)
> +{
> + /*
> +  * The daemon has exited; reset the state.
> +  */
> + opened = false;
> + return 0;
> +}
> +
> +
> +static const struct file_operations hvnd_fops = {
> + .write  = hvnd_write,
> + .release= hvnd_release,
> + .open   = hvnd_open,
> +};
> +
> +static struct miscdevice hvnd_misc = {
> + .minor  = MISC_DYNAMIC_MINOR,
> + .name   = "hvnd_rdma",
> + .fops   = _fops,
> +};
> +
> +static int hvnd_dev_init(void)
> +{
> + init_completion(_event);
> + return misc_register(_misc);
> +}
> +
> +static void hvnd_dev_deinit(void)
> +{
> +
> + /*
> +  * The device is going away - perhaps because the
> +  * host has rescinded the channel. Setup state so that
> +  * user level daemon can gracefully exit if it is blocked
> +  * on the read semaphore.
> +  */
> + opened = false;

But if it's blocked, it's not going to get unblocked here :(


> + /*
> +  * Signal the semaphore as the device is
> +  * going away.
> +  */
> + misc_deregister(_misc);
> +}

Your comment doesn't match the code you are calling.

I gave up here, sorry.

Exactly why do you want a char interface?  It looks like you are using
it to configure your "hardware", surely there is already other ways to
do this and not every driver needs to roll-their-own like this?

thanks,

greg k-h

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[Greg KH]

On Tue, Jul 26, 2016 at 07:05:37PM -0700, k...@exchange.microsoft.com wrote:
> +/*
> + * Create a char device that can support read/write for passing
> + * the payload.
> + */

That sounds "interesting"...

> +
> +static struct completion ip_event;
> +static bool opened;
> +
> +char hvnd_ip_addr[4];
> +char hvnd_mac_addr[6];
> +bool hvnd_addr_set;

Global variables?

> +
> +int hvnd_get_ip_addr(char **ip_addr, char **mac_addr)
> +{
> + int t;
> +
> + /*
> +  * Now wait for the user level daemon to get us the
> +  * IP addresses bound to the MAC address.
> +  */
> + if (!hvnd_addr_set) {
> + t = wait_for_completion_timeout(_event, 600*HZ);
> + if (t == 0)
> + return -ETIMEDOUT;
> + }
> +
> + if (hvnd_addr_set) {
> + *ip_addr = hvnd_ip_addr;
> + *mac_addr = hvnd_mac_addr;
> + return 0;
> + }
> +
> + return -ENODATA;
> +}
> +
> +static ssize_t hvnd_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + char input[120];
> + int scaned, i;
> + unsigned int mac_addr[6], ip_addr[4];
> +
> + if (hvnd_addr_set) {
> + hvnd_error("IP/MAC address already set, ignoring input\n");
> + return count;
> + }
> +
> + if (count > sizeof(input)-1)
> + return -EINVAL;
> +
> + if (copy_from_user(input, buf, count))
> + return -EFAULT;
> +
> + input[count] = 0;
> +
> + /*
> +  * Wakeup the context that may be waiting for this.
> +  */
> + hvnd_debug("get user mode input: %s\n", input);
> +
> + scaned = sscanf(input,
> + "rdmaMacAddress=\"%x:%x:%x:%x:%x:%x\" 
> rdmaIPv4Address=\"%u.%u.%u.%u\"",
> + _addr[0],
> + _addr[1],
> + _addr[2],
> + _addr[3],
> + _addr[4],
> + _addr[5],
> + _addr[0],
> + _addr[1],
> + _addr[2],
> + _addr[3]);

Oh, that's a mess, you are going to parse text in the kernel that is
passed on a char device?  Please tell me that not all IB drivers are
like this...

> +
> + if (scaned == 10) {
> +
> + for (i = 0; i < 6; i++)
> + hvnd_mac_addr[i] = (char) mac_addr[i];
> + for (i = 0; i < 4; i++)
> + hvnd_ip_addr[i] = (char) ip_addr[i];
> +
> + hvnd_error("Scanned IP address: %pI4 Mac address: %pM\n",
> +hvnd_ip_addr, hvnd_mac_addr);
> +
> + hvnd_addr_set = true;
> + complete(_event);
> + }
> +
> + return count;
> +}
> +
> +static int hvnd_open(struct inode *inode, struct file *f)
> +{
> + /*
> +  * The user level daemon that will open this device is
> +  * really an extension of this driver. We can have only
> +  * active open at a time.

Do you have a pointer to that code?  As it's a logical extension, you
know what the license for that code better be... :)

> +  */
> + if (opened)
> + return -EBUSY;

You just raced, and lost, oops :(

There are better ways to do this, the easiest being, why do you need
"exclusive" access at all?

> +
> + /*
> +  * The daemon is alive; setup the state.
> +  */
> + opened = true;
> + return 0;
> +}
> +
> +static int hvnd_release(struct inode *inode, struct file *f)
> +{
> + /*
> +  * The daemon has exited; reset the state.
> +  */
> + opened = false;
> + return 0;
> +}
> +
> +
> +static const struct file_operations hvnd_fops = {
> + .write  = hvnd_write,
> + .release= hvnd_release,
> + .open   = hvnd_open,
> +};
> +
> +static struct miscdevice hvnd_misc = {
> + .minor  = MISC_DYNAMIC_MINOR,
> + .name   = "hvnd_rdma",
> + .fops   = _fops,
> +};
> +
> +static int hvnd_dev_init(void)
> +{
> + init_completion(_event);
> + return misc_register(_misc);
> +}
> +
> +static void hvnd_dev_deinit(void)
> +{
> +
> + /*
> +  * The device is going away - perhaps because the
> +  * host has rescinded the channel. Setup state so that
> +  * user level daemon can gracefully exit if it is blocked
> +  * on the read semaphore.
> +  */
> + opened = false;

But if it's blocked, it's not going to get unblocked here :(


> + /*
> +  * Signal the semaphore as the device is
> +  * going away.
> +  */
> + misc_deregister(_misc);
> +}

Your comment doesn't match the code you are calling.

I gave up here, sorry.

Exactly why do you want a char interface?  It looks like you are using
it to configure your "hardware", surely there is already other ways to
do this and not every driver needs to roll-their-own like this?

thanks,

greg k-h

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chris Zhong]

Hi Chanwoo

On 07/27/2016 11:57 AM, Chanwoo Choi wrote:

On 2016년 07월 27일 12:51, Guenter Roeck wrote:

On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:

Hi Chris,

On 2016년 07월 27일 11:09, Chris Zhong wrote:

Hi Guernter

On 07/27/2016 09:44 AM, Guenter Roeck wrote:

Hi Chris,

On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:

[ ... ]


  > +
  > +/* Properties of EXTCON_TYPE_DISP. */
  > +#define EXTCON_PROP_DISP_MIN   150
  > +#define EXTCON_PROP_DISP_MAX   150
  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
  EXTCON_PROP_DISP_MIN)

   + 1


ok.

Tested with these "+1", it works for my DP patch.


You should be able to use
https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
you didn't do that already).

Thanks,
Guenter

Thanks Guenter, and I saw this bug has fixed in extcon-test branch.



Do you test it with extcon_set_property_capability()?
And if you test this patch-es, could you send the tested-by tag for these 
patches?

Yes, the new API need this extcon_set_property_capability to be called 
before setting property.
On this basis, My DP patches works well with a little bit modification. 
Then, I will post the V7 version soon, base on this patches and 
Guenter's FIXUP patch.
Please feel free to add my Tested-by: Chris Zhong  
tag in the next version.




For my part I did. Above link is public, so you should be able to see
the complete patch set which uses the new API from
drivers/extcon/extcon-cros_ec.c.

I'll re-test tomorrow with the updated patches from your test branch.






OK. Thanks.

Regards,
Chanwoo Choi

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chris Zhong]

Hi Chanwoo

On 07/27/2016 11:57 AM, Chanwoo Choi wrote:

On 2016년 07월 27일 12:51, Guenter Roeck wrote:

On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:

Hi Chris,

On 2016년 07월 27일 11:09, Chris Zhong wrote:

Hi Guernter

On 07/27/2016 09:44 AM, Guenter Roeck wrote:

Hi Chris,

On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:

[ ... ]


  > +
  > +/* Properties of EXTCON_TYPE_DISP. */
  > +#define EXTCON_PROP_DISP_MIN   150
  > +#define EXTCON_PROP_DISP_MAX   150
  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
  EXTCON_PROP_DISP_MIN)

   + 1


ok.

Tested with these "+1", it works for my DP patch.


You should be able to use
https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
you didn't do that already).

Thanks,
Guenter

Thanks Guenter, and I saw this bug has fixed in extcon-test branch.



Do you test it with extcon_set_property_capability()?
And if you test this patch-es, could you send the tested-by tag for these 
patches?

Yes, the new API need this extcon_set_property_capability to be called 
before setting property.
On this basis, My DP patches works well with a little bit modification. 
Then, I will post the V7 version soon, base on this patches and 
Guenter's FIXUP patch.
Please feel free to add my Tested-by: Chris Zhong  
tag in the next version.




For my part I did. Above link is public, so you should be able to see
the complete patch set which uses the new API from
drivers/extcon/extcon-cros_ec.c.

I'll re-test tomorrow with the updated patches from your test branch.






OK. Thanks.

Regards,
Chanwoo Choi

RE: [PATCH 1/6] extcon: Add the extcon_type to group each connector into five category

[MyungJoo Ham]

> This patch adds the new extcon type to group the each connecotr
> into following five category. This type would be used to handle
> the connectors as a group unit instead of a connector unit.
> - EXTCON_TYPE_USB  : USB connector
> - EXTCON_TYPE_CHG  : Charger connector
> - EXTCON_TYPE_JACK : Jack connector

"Jack" seems to be an internal jargon that many people won't recognize.
It's, in fact, 3.5-pi, isn't it?

Anyway, this is already being used as an enum with drivers,
I'd suggest to add a comment in extcon.h stating that 
"Jack connector" is usually the 3.5-pi earbud connector.

Anyway, I like the direction of this patch.


Signed-off-by: MyungJoo Ham 

Cheers,
MyungJoo

> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -29,6 +29,15 @@
>  #include 
>  
>  /*
> + * Define the type of supported external connectors
> + */
> +#define EXTCON_TYPE_USB  BIT(0)  /* USB connector */
> +#define EXTCON_TYPE_CHG  BIT(1)  /* Charger connector */
> +#define EXTCON_TYPE_JACK BIT(2)  /* Jack connector */
+/* Usually, this is a 3.5-pi earbud conector */
> +#define EXTCON_TYPE_DISP BIT(3)  /* Display connector */
> +#define EXTCON_TYPE_MISC BIT(4)  /* Miscellaneous connector */
> +
> +/*
>   * Define the unique id of supported external connectors
>   */
>  #define EXTCON_NONE  0
> -- 
> 1.9.1
> 

RE: [PATCH 1/6] extcon: Add the extcon_type to group each connector into five category

[MyungJoo Ham]

> This patch adds the new extcon type to group the each connecotr
> into following five category. This type would be used to handle
> the connectors as a group unit instead of a connector unit.
> - EXTCON_TYPE_USB  : USB connector
> - EXTCON_TYPE_CHG  : Charger connector
> - EXTCON_TYPE_JACK : Jack connector

"Jack" seems to be an internal jargon that many people won't recognize.
It's, in fact, 3.5-pi, isn't it?

Anyway, this is already being used as an enum with drivers,
I'd suggest to add a comment in extcon.h stating that 
"Jack connector" is usually the 3.5-pi earbud connector.

Anyway, I like the direction of this patch.


Signed-off-by: MyungJoo Ham 

Cheers,
MyungJoo

> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -29,6 +29,15 @@
>  #include 
>  
>  /*
> + * Define the type of supported external connectors
> + */
> +#define EXTCON_TYPE_USB  BIT(0)  /* USB connector */
> +#define EXTCON_TYPE_CHG  BIT(1)  /* Charger connector */
> +#define EXTCON_TYPE_JACK BIT(2)  /* Jack connector */
+/* Usually, this is a 3.5-pi earbud conector */
> +#define EXTCON_TYPE_DISP BIT(3)  /* Display connector */
> +#define EXTCON_TYPE_MISC BIT(4)  /* Miscellaneous connector */
> +
> +/*
>   * Define the unique id of supported external connectors
>   */
>  #define EXTCON_NONE  0
> -- 
> 1.9.1
> 

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[Leon Romanovsky]

On Tue, Jul 26, 2016 at 07:05:37PM -0700, k...@exchange.microsoft.com wrote:
> From: K. Y. Srinivasan 
> 
> This driver is a bridge driver that surfaces a Mellanox device in the Linux 
> guest and plugs into
> the "NetworkDirect" RDMA infrastructure on the Windows host. Only a subset of 
> the ibverbs are
> implemented (this decision is based on the verbs supported by the Windows 
> host).
> The control path is implemented over the vmbus using the NetworkDirect 
> protocol for
> virtualized environments. The data path bypasses the guest and host kernel 
> and the NIC is able to RDMA
> into guest addresses.
> 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/infiniband/Kconfig  |1 +
>  drivers/infiniband/hw/Makefile  |1 +
>  drivers/infiniband/hw/vmbus-nd/Kconfig  |5 +
>  drivers/infiniband/hw/vmbus-nd/Makefile |3 +
>  drivers/infiniband/hw/vmbus-nd/hvnd_addr.c  |  292 +++
>  drivers/infiniband/hw/vmbus-nd/mx_abi.h |  232 ++
>  drivers/infiniband/hw/vmbus-nd/provider.c   | 2844 
>  drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c | 3086 
> +++
>  drivers/infiniband/hw/vmbus-nd/vmbus_rdma.h | 2205 +++
>  9 files changed, 8669 insertions(+), 0 deletions(-)

If your final goal is to merge this driver into Linux kernel, so I will
ask from you to do the following actions:

1. Split this patch to smaller patches to allow review.
You can see as an example - latest submission of "Add Paravirtual RDMA Driver" 
[1].
2. Fix licenses, magic numbers, remove creepy comments and learn about
MAINTAINERS file.
3. Use preferred for this susbsystem title format.
4. Find the relevant mailing list and maintainer for this submission and
don't add unrelated people.

Thanks.

[1] http://marc.info/?l=linux-rdma=146835226218818=2

>  create mode 100644 drivers/infiniband/hw/vmbus-nd/Kconfig
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/Makefile
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/hvnd_addr.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/mx_abi.h
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/provider.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/vmbus_rdma.h


signature.asc
Description: Digital signature

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[Leon Romanovsky]

On Tue, Jul 26, 2016 at 07:05:37PM -0700, k...@exchange.microsoft.com wrote:
> From: K. Y. Srinivasan 
> 
> This driver is a bridge driver that surfaces a Mellanox device in the Linux 
> guest and plugs into
> the "NetworkDirect" RDMA infrastructure on the Windows host. Only a subset of 
> the ibverbs are
> implemented (this decision is based on the verbs supported by the Windows 
> host).
> The control path is implemented over the vmbus using the NetworkDirect 
> protocol for
> virtualized environments. The data path bypasses the guest and host kernel 
> and the NIC is able to RDMA
> into guest addresses.
> 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/infiniband/Kconfig  |1 +
>  drivers/infiniband/hw/Makefile  |1 +
>  drivers/infiniband/hw/vmbus-nd/Kconfig  |5 +
>  drivers/infiniband/hw/vmbus-nd/Makefile |3 +
>  drivers/infiniband/hw/vmbus-nd/hvnd_addr.c  |  292 +++
>  drivers/infiniband/hw/vmbus-nd/mx_abi.h |  232 ++
>  drivers/infiniband/hw/vmbus-nd/provider.c   | 2844 
>  drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c | 3086 
> +++
>  drivers/infiniband/hw/vmbus-nd/vmbus_rdma.h | 2205 +++
>  9 files changed, 8669 insertions(+), 0 deletions(-)

If your final goal is to merge this driver into Linux kernel, so I will
ask from you to do the following actions:

1. Split this patch to smaller patches to allow review.
You can see as an example - latest submission of "Add Paravirtual RDMA Driver" 
[1].
2. Fix licenses, magic numbers, remove creepy comments and learn about
MAINTAINERS file.
3. Use preferred for this susbsystem title format.
4. Find the relevant mailing list and maintainer for this submission and
don't add unrelated people.

Thanks.

[1] http://marc.info/?l=linux-rdma=146835226218818=2

>  create mode 100644 drivers/infiniband/hw/vmbus-nd/Kconfig
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/Makefile
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/hvnd_addr.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/mx_abi.h
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/provider.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c
>  create mode 100644 drivers/infiniband/hw/vmbus-nd/vmbus_rdma.h


signature.asc
Description: Digital signature

Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT

[Fu Wei]

Hi all,

On 27 July 2016 at 11:33, Jisheng Zhang  wrote:
> +1
>
> On Tue, 26 Jul 2016 09:11:49 -0500 Timur Tabi  wrote:
>
>> Will Deacon wrote:
>> > The kernel really needs to support both of those platforms :/
>> >
>> > For the memory-mapped counter registers, the architecture says:
>> >
>> >`If the implementation supports 64-bit atomic accesses, then the
>> > CNTV_CVAL register must be accessible as an atomic 64-bit value.'
>> >
>> > which is borderline tautological. If we take the generous reading that
>> > this means AArch64 CPUs can use readq (and I'm not completely
>> > comfortable with that assertion, particularly as you say that it breaks
>> > the model), then you still need to use readq_relaxed here to avoid a
>> > DSB. Furthermore, what are you going to do for AArch32? readq doesn't
>> > exist over there, and if you use the generic implementation then it's
>> > not atomic. In which case, we end up with the current code, as well as a
>> > readq_relaxed guarded by a questionable #ifdef that is known to break a
>> > supported platform for an unknown performance improvement. Hardly a big
>> > win.
>>
>> I know Fu dropped this patch, and I don't want to kick a dead horse, but
>> I was wondering if it would be okay to do this:
>>
>> static u64 arch_counter_get_cntvct_mem(void)
>> {
>> #ifdef readq_relaxed
>>   return readq_relaxed(arch_counter_base + CNTVCT_LO);
>> #else
>>   u32 vct_lo, vct_hi, tmp_hi;
>>
>>   do {
>>   vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>>   vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
>>   tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>>   } while (vct_hi != tmp_hi);
>>
>>   return ((u64) vct_hi << 32) | vct_lo;
>> #endif
>> }
>>
>> readq and readq_relaxed are defined in arch/arm64/include/asm/io.h.  Why
>> would the function exist if AArch64 CPUs can't use it?

yes, that is a good idea. Thanks Timur! :-)

>
> +1

I like this idea too, but please allow me to upstream this patch separately,
because this GTDT patchset can work without it, this readq support is
a  optimizing.

I also can see another arm-related driver are using readq in this way(
#ifdef readq): bus/arm-ccn.c
And some other drivers are also doing this.

>
> I measured the performance on berlin arm64 platforms:
>
> compared with original version, using readq_relaxed could reduce
> time of arch_counter_get_cntvct_mem() by about 42%!

Great thanks for your data, :-)

>
> Thanks,
> Jisheng



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT

[Fu Wei]

Hi all,

On 27 July 2016 at 11:33, Jisheng Zhang  wrote:
> +1
>
> On Tue, 26 Jul 2016 09:11:49 -0500 Timur Tabi  wrote:
>
>> Will Deacon wrote:
>> > The kernel really needs to support both of those platforms :/
>> >
>> > For the memory-mapped counter registers, the architecture says:
>> >
>> >`If the implementation supports 64-bit atomic accesses, then the
>> > CNTV_CVAL register must be accessible as an atomic 64-bit value.'
>> >
>> > which is borderline tautological. If we take the generous reading that
>> > this means AArch64 CPUs can use readq (and I'm not completely
>> > comfortable with that assertion, particularly as you say that it breaks
>> > the model), then you still need to use readq_relaxed here to avoid a
>> > DSB. Furthermore, what are you going to do for AArch32? readq doesn't
>> > exist over there, and if you use the generic implementation then it's
>> > not atomic. In which case, we end up with the current code, as well as a
>> > readq_relaxed guarded by a questionable #ifdef that is known to break a
>> > supported platform for an unknown performance improvement. Hardly a big
>> > win.
>>
>> I know Fu dropped this patch, and I don't want to kick a dead horse, but
>> I was wondering if it would be okay to do this:
>>
>> static u64 arch_counter_get_cntvct_mem(void)
>> {
>> #ifdef readq_relaxed
>>   return readq_relaxed(arch_counter_base + CNTVCT_LO);
>> #else
>>   u32 vct_lo, vct_hi, tmp_hi;
>>
>>   do {
>>   vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>>   vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
>>   tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>>   } while (vct_hi != tmp_hi);
>>
>>   return ((u64) vct_hi << 32) | vct_lo;
>> #endif
>> }
>>
>> readq and readq_relaxed are defined in arch/arm64/include/asm/io.h.  Why
>> would the function exist if AArch64 CPUs can't use it?

yes, that is a good idea. Thanks Timur! :-)

>
> +1

I like this idea too, but please allow me to upstream this patch separately,
because this GTDT patchset can work without it, this readq support is
a  optimizing.

I also can see another arm-related driver are using readq in this way(
#ifdef readq): bus/arm-ccn.c
And some other drivers are also doing this.

>
> I measured the performance on berlin arm64 platforms:
>
> compared with original version, using readq_relaxed could reduce
> time of arch_counter_get_cntvct_mem() by about 42%!

Great thanks for your data, :-)

>
> Thanks,
> Jisheng



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[kbuild test robot]

Hi,

[auto build test WARNING on rdma/master]
[also build test WARNING on v4.7 next-20160726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/kys-exchange-microsoft-com/Drivers-infiniband-hw-vmbus-nd-NetworkDirect-driver-for-Linux/20160727-090222
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 
'hvnd_send_pg_buffer':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:247:20: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_cookie.pkt = (void *)cookie;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:254:6: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 (u64)(_cookie));
 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_send_packet':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:279:20: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_cookie.pkt = (void *)cookie;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:283:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)(_cookie), VM_PKT_DATA_INBAND,
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_open_adaptor':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:763:38: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 pr_o_adap->ioctl.input.adapter_id = (u64)nd_dev;
 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:813:132: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("adaptor handle: %p\n", (void *)uctx->adaptor_hdl);

   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:818:126: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("uar base: %p\n", (void *)uctx->uar_base);

 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:822:125: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("bf base: %p\n", (void *)uctx->bf_base);

^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_create_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:963:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)cq->cq_buf;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:972:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)cq->db_addr;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:982:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)>arm_sn;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1023:60: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 ret = hvnd_send_ioctl_pkt(nd_dev, >hdr, cq_pkt_size, (u64)pkt);
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1041:4: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("CQ create after success cq handle is %p\n",
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_destroy_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1071:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)_cq_pkt);
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_notify_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1114:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)_cq_pkt);
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_cr_mr':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1142:130: warning: cast to 
pointer from integer of different size [-Wint-t

Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[kbuild test robot]

Hi,

[auto build test WARNING on rdma/master]
[also build test WARNING on v4.7 next-20160726]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/kys-exchange-microsoft-com/Drivers-infiniband-hw-vmbus-nd-NetworkDirect-driver-for-Linux/20160727-090222
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 
'hvnd_send_pg_buffer':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:247:20: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_cookie.pkt = (void *)cookie;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:254:6: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 (u64)(_cookie));
 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_send_packet':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:279:20: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_cookie.pkt = (void *)cookie;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:283:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)(_cookie), VM_PKT_DATA_INBAND,
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_open_adaptor':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:763:38: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 pr_o_adap->ioctl.input.adapter_id = (u64)nd_dev;
 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:813:132: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("adaptor handle: %p\n", (void *)uctx->adaptor_hdl);

   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:818:126: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("uar base: %p\n", (void *)uctx->uar_base);

 ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:822:125: warning: cast to 
pointer from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("bf base: %p\n", (void *)uctx->bf_base);

^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_create_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:963:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)cq->cq_buf;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:972:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)cq->db_addr;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:982:24: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  map_memory.address = (u64)>arm_sn;
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1023:60: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
 ret = hvnd_send_ioctl_pkt(nd_dev, >hdr, cq_pkt_size, (u64)pkt);
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1041:4: warning: cast to pointer 
from integer of different size [-Wint-to-pointer-cast]
 hvnd_debug("CQ create after success cq handle is %p\n",
   ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_destroy_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1071:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)_cq_pkt);
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_notify_cq':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1114:11: warning: cast from 
pointer to integer of different size [-Wpointer-to-int-cast]
  (u64)_cq_pkt);
  ^
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c: In function 'hvnd_cr_mr':
   drivers/infiniband/hw/vmbus-nd/vmbus_rdma.c:1142:130: warning: cast to 
pointer from integer of different size [-Wint-t

Re: [PATCH v2 2/4] arm64: dts: rockchip: add the saradc for rk3399

[Doug Anderson]

Hi,


On Tue, Jul 26, 2016 at 5:13 AM, Caesar Wang  wrote:
> This patch adds saradc needed information on rk3399 SoCs.
>
> Signed-off-by: Caesar Wang 
> ---
>
> Changes in v2: None
>
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 4c84229..b81f84b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -299,6 +299,18 @@
> };
> };
>
> +   saradc: saradc@ff10 {
> +   compatible = "rockchip,rk3399-saradc";
> +   reg = <0x0 0xff10 0x0 0x100>;
> +   interrupts = ;
> +   #io-channel-cells = <1>;
> +   clocks = < SCLK_SARADC>, < PCLK_SARADC>;
> +   clock-names = "saradc", "apb_pclk";
> +   resets = < SRST_P_SARADC>;
> +   reset-names = "saradc-apb";
> +   status = "disabled";
> +   };
> +

Seems reasonable to me.  I'll let Heiko comment if he cares about the
sort ordering.  I can never quite figure out what it should be so I've
sorta given up on it...  ;)

Reviewed-by: Douglas Anderson 

-Doug

Re: [PATCH v2 2/4] arm64: dts: rockchip: add the saradc for rk3399

[Doug Anderson]

Hi,


On Tue, Jul 26, 2016 at 5:13 AM, Caesar Wang  wrote:
> This patch adds saradc needed information on rk3399 SoCs.
>
> Signed-off-by: Caesar Wang 
> ---
>
> Changes in v2: None
>
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 4c84229..b81f84b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -299,6 +299,18 @@
> };
> };
>
> +   saradc: saradc@ff10 {
> +   compatible = "rockchip,rk3399-saradc";
> +   reg = <0x0 0xff10 0x0 0x100>;
> +   interrupts = ;
> +   #io-channel-cells = <1>;
> +   clocks = < SCLK_SARADC>, < PCLK_SARADC>;
> +   clock-names = "saradc", "apb_pclk";
> +   resets = < SRST_P_SARADC>;
> +   reset-names = "saradc-apb";
> +   status = "disabled";
> +   };
> +

Seems reasonable to me.  I'll let Heiko comment if he cares about the
sort ordering.  I can never quite figure out what it should be so I've
sorta given up on it...  ;)

Reviewed-by: Douglas Anderson 

-Doug

[GIT PULL] f2fs for 4.8

[Jaegeuk Kim]

Hi Linus,

Could you please consider this pull request?

Thanks,

The following changes since commit 4340fa55298d17049e71c7a34e04647379c269f3:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
(2016-06-02 15:08:06 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git 
tags/for-f2fs-4.8

for you to fetch changes up to 5302fb000def84100740a84d7f176c0e167b2141:

  f2fs: clean up coding style and redundancy (2016-07-25 12:58:12 -0700)


The major change in this version is mitigating cpu overheads on write paths by
replacing redundant inode page updates with mark_inode_dirty calls. And we tried
to reduce lock contentions as well to improve filesystem scalability.
Other feature is setting F2FS automatically when detecting host-managed SMR.

= Enhancement =
 - ioctl to move a range of data between files
 - inject orphan inode errors
 - avoid flush commands congestion
 - support lazytime

= Bug fixes =
 - return proper results for some dentry operations
 - fix deadlock in add_link failure
 - disable extent_cache for fcollapse/finsert


Chao Yu (9):
  f2fs: fix to avoid reading out encrypted data in page cache
  f2fs: fix to detect truncation prior rather than EIO during read
  f2fs: fix to redirty page if fail to gc data page
  f2fs: add nodiscard mount option
  f2fs: fix incorrect f_bfree calculation in ->statfs
  f2fs: fix to avoid redundant discard during fstrim
  f2fs: fix to avoid data update racing between GC and DIO
  f2fs: reset default idle interval value
  f2fs: fix to report error number of f2fs_find_entry

Jaegeuk Kim (54):
  Revert "f2fs: no need inc dirty pages under inode lock"
  f2fs: use inode pointer for {set, clear}_inode_flag
  f2fs: introduce f2fs_i_size_write with mark_inode_dirty_sync
  f2fs: introduce f2fs_i_blocks_write with mark_inode_dirty_sync
  f2fs: introduce f2fs_i_links_write with mark_inode_dirty_sync
  f2fs: call mark_inode_dirty_sync for i_field changes
  f2fs: flush inode metadata when checkpoint is doing
  f2fs: remove syncing inode page in all the cases
  f2fs: avoid unnecessary updating inode during fsync
  f2fs: add lazytime mount option
  f2fs: detect congestion of flush command issues
  f2fs: set flush_merge by default
  f2fs: remove writepages lock
  f2fs: propagate error given by f2fs_find_entry
  f2fs: inject to produce some orphan inodes
  f2fs: do not skip writing data pages
  f2fs: remove two steps to flush dirty data pages
  f2fs: return error of f2fs_lookup
  f2fs: handle writepage correctly
  f2fs: remove deprecated parameter
  f2fs: avoid wrong count on dirty inodes
  f2fs: remove obsolete parameter in f2fs_truncate
  f2fs: avoid data race between FI_DIRTY_INODE flag and update_inode
  f2fs: fix wrong percentage
  f2fs: control not to exceed # of cached nat entries
  f2fs: set mapping error for EIO
  f2fs: avoid reverse IO order for NODE and DATA
  f2fs: drop any block plugging
  f2fs: skip clean segment for gc
  f2fs: introduce mode=lfs mount option
  f2fs: fix deadlock in add_link failure
  f2fs: report error for f2fs_parent_dir
  f2fs: call update_inode_page for orphan inodes
  f2fs: detect host-managed SMR by feature flag
  f2fs: produce more nids and reduce readahead nats
  f2fs: avoid writing node/metapages during writes
  f2fs: avoid latency-critical readahead of node pages
  f2fs: introduce f2fs_set_page_dirty_nobuffer
  f2fs: call SetPageUptodate if needed
  f2fs: shrink critical region in spin_lock
  f2fs: skip to check the block address of node page
  f2fs: use percpu_rw_semaphore
  f2fs: move i_size_write in f2fs_write_end
  f2fs: avoid mark_inode_dirty
  f2fs: fix ERR_PTR returned by bio
  f2fs: refactor __exchange_data_block for speed up
  f2fs: disable extent_cache for fcollapse/finsert inodes
  f2fs: add maximum prefree segments
  f2fs: use blk_plug in all the possible paths
  f2fs: avoid memory allocation failure due to a long length
  f2fs: support an ioctl to move a range of data blocks
  f2fs: avoid data race when deciding checkpoin in f2fs_sync_file
  f2fs: handle error case with f2fs_bug_on
  f2fs: clean up coding style and redundancy

Sheng Yong (1):
  f2fs: find parent dentry correctly

Tiezhu Yang (1):
  f2fs: remove unnecessary goto statement

Yunlei He (2):
  f2fs: avoid mismatching block range for discard
  f2fs: get victim segment again after new cp

Yunlong Song (1):
  f2fs: return the errno to the caller to avoid using a wrong page

 Documentation/filesystems/f2fs.txt |   7 +-
 fs/f2fs/acl.c  |   9 +-
 fs/f2fs/acl.h  |   

[GIT PULL] f2fs for 4.8

[Jaegeuk Kim]

Hi Linus,

Could you please consider this pull request?

Thanks,

The following changes since commit 4340fa55298d17049e71c7a34e04647379c269f3:

  Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm 
(2016-06-02 15:08:06 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git 
tags/for-f2fs-4.8

for you to fetch changes up to 5302fb000def84100740a84d7f176c0e167b2141:

  f2fs: clean up coding style and redundancy (2016-07-25 12:58:12 -0700)


The major change in this version is mitigating cpu overheads on write paths by
replacing redundant inode page updates with mark_inode_dirty calls. And we tried
to reduce lock contentions as well to improve filesystem scalability.
Other feature is setting F2FS automatically when detecting host-managed SMR.

= Enhancement =
 - ioctl to move a range of data between files
 - inject orphan inode errors
 - avoid flush commands congestion
 - support lazytime

= Bug fixes =
 - return proper results for some dentry operations
 - fix deadlock in add_link failure
 - disable extent_cache for fcollapse/finsert


Chao Yu (9):
  f2fs: fix to avoid reading out encrypted data in page cache
  f2fs: fix to detect truncation prior rather than EIO during read
  f2fs: fix to redirty page if fail to gc data page
  f2fs: add nodiscard mount option
  f2fs: fix incorrect f_bfree calculation in ->statfs
  f2fs: fix to avoid redundant discard during fstrim
  f2fs: fix to avoid data update racing between GC and DIO
  f2fs: reset default idle interval value
  f2fs: fix to report error number of f2fs_find_entry

Jaegeuk Kim (54):
  Revert "f2fs: no need inc dirty pages under inode lock"
  f2fs: use inode pointer for {set, clear}_inode_flag
  f2fs: introduce f2fs_i_size_write with mark_inode_dirty_sync
  f2fs: introduce f2fs_i_blocks_write with mark_inode_dirty_sync
  f2fs: introduce f2fs_i_links_write with mark_inode_dirty_sync
  f2fs: call mark_inode_dirty_sync for i_field changes
  f2fs: flush inode metadata when checkpoint is doing
  f2fs: remove syncing inode page in all the cases
  f2fs: avoid unnecessary updating inode during fsync
  f2fs: add lazytime mount option
  f2fs: detect congestion of flush command issues
  f2fs: set flush_merge by default
  f2fs: remove writepages lock
  f2fs: propagate error given by f2fs_find_entry
  f2fs: inject to produce some orphan inodes
  f2fs: do not skip writing data pages
  f2fs: remove two steps to flush dirty data pages
  f2fs: return error of f2fs_lookup
  f2fs: handle writepage correctly
  f2fs: remove deprecated parameter
  f2fs: avoid wrong count on dirty inodes
  f2fs: remove obsolete parameter in f2fs_truncate
  f2fs: avoid data race between FI_DIRTY_INODE flag and update_inode
  f2fs: fix wrong percentage
  f2fs: control not to exceed # of cached nat entries
  f2fs: set mapping error for EIO
  f2fs: avoid reverse IO order for NODE and DATA
  f2fs: drop any block plugging
  f2fs: skip clean segment for gc
  f2fs: introduce mode=lfs mount option
  f2fs: fix deadlock in add_link failure
  f2fs: report error for f2fs_parent_dir
  f2fs: call update_inode_page for orphan inodes
  f2fs: detect host-managed SMR by feature flag
  f2fs: produce more nids and reduce readahead nats
  f2fs: avoid writing node/metapages during writes
  f2fs: avoid latency-critical readahead of node pages
  f2fs: introduce f2fs_set_page_dirty_nobuffer
  f2fs: call SetPageUptodate if needed
  f2fs: shrink critical region in spin_lock
  f2fs: skip to check the block address of node page
  f2fs: use percpu_rw_semaphore
  f2fs: move i_size_write in f2fs_write_end
  f2fs: avoid mark_inode_dirty
  f2fs: fix ERR_PTR returned by bio
  f2fs: refactor __exchange_data_block for speed up
  f2fs: disable extent_cache for fcollapse/finsert inodes
  f2fs: add maximum prefree segments
  f2fs: use blk_plug in all the possible paths
  f2fs: avoid memory allocation failure due to a long length
  f2fs: support an ioctl to move a range of data blocks
  f2fs: avoid data race when deciding checkpoin in f2fs_sync_file
  f2fs: handle error case with f2fs_bug_on
  f2fs: clean up coding style and redundancy

Sheng Yong (1):
  f2fs: find parent dentry correctly

Tiezhu Yang (1):
  f2fs: remove unnecessary goto statement

Yunlei He (2):
  f2fs: avoid mismatching block range for discard
  f2fs: get victim segment again after new cp

Yunlong Song (1):
  f2fs: return the errno to the caller to avoid using a wrong page

 Documentation/filesystems/f2fs.txt |   7 +-
 fs/f2fs/acl.c  |   9 +-
 fs/f2fs/acl.h  |   

Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

[NeilBrown]

On Tue, Jul 26 2016, Mikulas Patocka wrote:

> On Sat, 23 Jul 2016, NeilBrown wrote:
>
>> "dirtying ... from the reclaim context" ??? What does that mean?
>> According to
>>   Commit: 26eecbf3543b ("[PATCH] vm: pageout throttling")
>> From the history tree, the purpose of throttle_vm_writeout() is to
>> limit the amount of memory that is concurrently under I/O.
>> That seems strange to me because I thought it was the responsibility of
>> each backing device to impose a limit - a maximum queue size of some
>> sort.
>
> Device mapper doesn't impose any limit for in-flight bios.

I would suggest that it probably should. At least it should
"set_wb_congested()" when the number of in-flight bios reaches some
arbitrary threshold.

The write-back throttling needs this to get an estimate of how fast the
backing device is, so it can share the dirty_threshold space fairly
among the different backing devices.

I added an arbitrary limit to raid1 back in 2011 (34db0cd60f8a1f)
because the lack of a limit was causing problems.
Specifically the write queue would get so long that ext3 would block for
an extended period when trying to flush a transaction, and that blocked
lots of other things, like atime updates.

Maybe there have been other fixes since then to other parts of the
puzzle, but the congestion tracking still seems to be an important part
of the picture and I think it would be best if every bdi would admit to
being congested well before it has consumed a significant fraction of
memory in its output queue.

> I've made some patches that limit in-flight bios for device mapper in
> the past, but there were not integrated into upstream.

I second the motion to resurrect these.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

[NeilBrown]

On Tue, Jul 26 2016, Mikulas Patocka wrote:

> On Sat, 23 Jul 2016, NeilBrown wrote:
>
>> "dirtying ... from the reclaim context" ??? What does that mean?
>> According to
>>   Commit: 26eecbf3543b ("[PATCH] vm: pageout throttling")
>> From the history tree, the purpose of throttle_vm_writeout() is to
>> limit the amount of memory that is concurrently under I/O.
>> That seems strange to me because I thought it was the responsibility of
>> each backing device to impose a limit - a maximum queue size of some
>> sort.
>
> Device mapper doesn't impose any limit for in-flight bios.

I would suggest that it probably should. At least it should
"set_wb_congested()" when the number of in-flight bios reaches some
arbitrary threshold.

The write-back throttling needs this to get an estimate of how fast the
backing device is, so it can share the dirty_threshold space fairly
among the different backing devices.

I added an arbitrary limit to raid1 back in 2011 (34db0cd60f8a1f)
because the lack of a limit was causing problems.
Specifically the write queue would get so long that ext3 would block for
an extended period when trying to flush a transaction, and that blocked
lots of other things, like atime updates.

Maybe there have been other fixes since then to other parts of the
puzzle, but the congestion tracking still seems to be an important part
of the picture and I think it would be best if every bdi would admit to
being congested well before it has consumed a significant fraction of
memory in its output queue.

> I've made some patches that limit in-flight bios for device mapper in
> the past, but there were not integrated into upstream.

I second the motion to resurrect these.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

[GIT PULL V2] Changes for 4.8

[Juergen Gross]

Hi Linus,

please consider pulling a patch series for 4.8 from:

  https://github.com/jgross1/linux.git tags/for-linus-4-8

Support calling functions on dedicated physical cpu

Some hardware (e.g. Dell Studio laptops) require special functions to
be called on physical cpu 0 in order to avoid occasional hangs. When
running as dom0 under Xen this could be achieved only via special boot
parameters (vcpu pinning) limiting the hypervisor in it's scheduling
decisions.

This patch series is adding a generic function to be able to temporarily
pin a (virtual) cpu to a dedicated physical cpu for executing above
mentioned functions on that specific cpu. The drivers (dcdbas and i8k)
requiring this functionality are modified accordingly.

Unfortunately 2 of the 6 patches got no Acks as the maintainers didn't
react in spite of multiple pings and resends. The core modification in
the scheduler got an Ack from Peter and multiple tests showed no
regressions.

As the series is touching multiple subsystems I couldn't find anyone
willing to take the series via his tree (I tried Ingo, Thomas, Peter).

Juergen Gross (6):
  xen: sync xen header
  virt, sched: add generic vcpu pinning support
  smp: add function to execute a function synchronously on a cpu
  xen: add xen_pin_vcpu() to support calling functions on a
dedicated pcpu
  dcdbas: make use of smp_call_on_cpu()
  hwmon: use smp_call_on_cpu() for dell-smm i8k

 MAINTAINERS   |   1 +
 arch/x86/include/asm/hypervisor.h |   4 ++
 arch/x86/kernel/cpu/hypervisor.c  |  11 +
 arch/x86/xen/enlighten.c  |  40 +++
 drivers/firmware/dcdbas.c |  51 +--
 drivers/hwmon/dell-smm-hwmon.c|  36 --
 include/linux/hypervisor.h|  17 +++
 include/linux/smp.h   |   3 ++
 include/xen/interface/sched.h | 100
+++---
 kernel/smp.c  |  51 +++
 kernel/up.c   |  18 +++
 11 files changed, 273 insertions(+), 59 deletions(-)
 create mode 100644 include/linux/hypervisor.h





signature.asc
Description: OpenPGP digital signature

[GIT PULL V2] Changes for 4.8

[Juergen Gross]

Hi Linus,

please consider pulling a patch series for 4.8 from:

  https://github.com/jgross1/linux.git tags/for-linus-4-8

Support calling functions on dedicated physical cpu

Some hardware (e.g. Dell Studio laptops) require special functions to
be called on physical cpu 0 in order to avoid occasional hangs. When
running as dom0 under Xen this could be achieved only via special boot
parameters (vcpu pinning) limiting the hypervisor in it's scheduling
decisions.

This patch series is adding a generic function to be able to temporarily
pin a (virtual) cpu to a dedicated physical cpu for executing above
mentioned functions on that specific cpu. The drivers (dcdbas and i8k)
requiring this functionality are modified accordingly.

Unfortunately 2 of the 6 patches got no Acks as the maintainers didn't
react in spite of multiple pings and resends. The core modification in
the scheduler got an Ack from Peter and multiple tests showed no
regressions.

As the series is touching multiple subsystems I couldn't find anyone
willing to take the series via his tree (I tried Ingo, Thomas, Peter).

Juergen Gross (6):
  xen: sync xen header
  virt, sched: add generic vcpu pinning support
  smp: add function to execute a function synchronously on a cpu
  xen: add xen_pin_vcpu() to support calling functions on a
dedicated pcpu
  dcdbas: make use of smp_call_on_cpu()
  hwmon: use smp_call_on_cpu() for dell-smm i8k

 MAINTAINERS   |   1 +
 arch/x86/include/asm/hypervisor.h |   4 ++
 arch/x86/kernel/cpu/hypervisor.c  |  11 +
 arch/x86/xen/enlighten.c  |  40 +++
 drivers/firmware/dcdbas.c |  51 +--
 drivers/hwmon/dell-smm-hwmon.c|  36 --
 include/linux/hypervisor.h|  17 +++
 include/linux/smp.h   |   3 ++
 include/xen/interface/sched.h | 100
+++---
 kernel/smp.c  |  51 +++
 kernel/up.c   |  18 +++
 11 files changed, 273 insertions(+), 59 deletions(-)
 create mode 100644 include/linux/hypervisor.h





signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chanwoo Choi]

On 2016년 07월 27일 12:51, Guenter Roeck wrote:
> On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:
>> Hi Chris,
>>
>> On 2016년 07월 27일 11:09, Chris Zhong wrote:
>>> Hi Guernter
>>>
>>> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
 Hi Chris,

 On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:

 [ ... ]

>>  > +
>>  > +/* Properties of EXTCON_TYPE_DISP. */
>>  > +#define EXTCON_PROP_DISP_MIN   150
>>  > +#define EXTCON_PROP_DISP_MAX   150
>>  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
>>  EXTCON_PROP_DISP_MIN)
>>
>>   + 1
>>
>>
>> ok.
>
> Tested with these "+1", it works for my DP patch.
>
 You should be able to use
 https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
 you didn't do that already).

 Thanks,
 Guenter
>>>
>>> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
>>>
>>>
>>
>> Do you test it with extcon_set_property_capability()?
>> And if you test this patch-es, could you send the tested-by tag for these 
>> patches?
>>
> 
> For my part I did. Above link is public, so you should be able to see
> the complete patch set which uses the new API from
> drivers/extcon/extcon-cros_ec.c.
> 
> I'll re-test tomorrow with the updated patches from your test branch.

OK. Thanks. 

Regards,
Chanwoo Choi

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chanwoo Choi]

On 2016년 07월 27일 12:51, Guenter Roeck wrote:
> On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:
>> Hi Chris,
>>
>> On 2016년 07월 27일 11:09, Chris Zhong wrote:
>>> Hi Guernter
>>>
>>> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
 Hi Chris,

 On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:

 [ ... ]

>>  > +
>>  > +/* Properties of EXTCON_TYPE_DISP. */
>>  > +#define EXTCON_PROP_DISP_MIN   150
>>  > +#define EXTCON_PROP_DISP_MAX   150
>>  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
>>  EXTCON_PROP_DISP_MIN)
>>
>>   + 1
>>
>>
>> ok.
>
> Tested with these "+1", it works for my DP patch.
>
 You should be able to use
 https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
 you didn't do that already).

 Thanks,
 Guenter
>>>
>>> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
>>>
>>>
>>
>> Do you test it with extcon_set_property_capability()?
>> And if you test this patch-es, could you send the tested-by tag for these 
>> patches?
>>
> 
> For my part I did. Above link is public, so you should be able to see
> the complete patch set which uses the new API from
> drivers/extcon/extcon-cros_ec.c.
> 
> I'll re-test tomorrow with the updated patches from your test branch.

OK. Thanks. 

Regards,
Chanwoo Choi

Re: [GIT PULL] usercopy protection for v4.8

[Kees Cook]

On Tue, Jul 26, 2016 at 2:55 PM, Kees Cook  wrote:
> Hi,
>
> This is my next pull request for v4.8, which introduces a kernel self
> protection of copy_to_user/copy_from_user that has been under review and
> test on the kernel-hardening list for a while. It has lived for a bit
> in -next, and appears to be ready IMO. There will be more improvements
> in the future, but this is a solid start.
>
> Again, if I can improve these pull request emails in any way, please
> let me know. :)

Hrm, part of the complexity of the KSPP work: this series depends on
_etext fixes in the arm and arm64 trees, so this should likely wait
until those trees are pulled.

-Kees

>
> Thanks!
>
> -Kees
>
> The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:
>
>   Linux 4.7 (2016-07-24 12:23:50 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
> tags/usercopy-v4.8
>
> for you to fetch changes up to ed18adc1cdd00a5c55a20fbdaed4804660772281:
>
>   mm: SLUB hardened usercopy support (2016-07-26 14:43:54 -0700)
>
> 
> Implements HARDENED_USERCOPY verification of copy_to_user/copy_from_user
> bounds checking for most architectures on SLAB and SLUB.
>
> 
> Kees Cook (11):
>   mm: Implement stack frame object validation
>   mm: Hardened usercopy
>   x86/uaccess: Enable hardened usercopy
>   ARM: uaccess: Enable hardened usercopy
>   arm64/uaccess: Enable hardened usercopy
>   ia64/uaccess: Enable hardened usercopy
>   powerpc/uaccess: Enable hardened usercopy
>   sparc/uaccess: Enable hardened usercopy
>   s390/uaccess: Enable hardened usercopy
>   mm: SLAB hardened usercopy support
>   mm: SLUB hardened usercopy support
>
> Laura Abbott (1):
>   mm: Add is_migrate_cma_page
>
>  arch/Kconfig|   9 ++
>  arch/arm/Kconfig|   1 +
>  arch/arm/include/asm/uaccess.h  |  11 +-
>  arch/arm64/Kconfig  |   1 +
>  arch/arm64/include/asm/uaccess.h|  29 +++-
>  arch/arm64/kernel/arm64ksyms.c  |   4 +-
>  arch/arm64/lib/copy_from_user.S |   4 +-
>  arch/arm64/lib/copy_to_user.S   |   4 +-
>  arch/ia64/Kconfig   |   1 +
>  arch/ia64/include/asm/uaccess.h |  18 ++-
>  arch/powerpc/Kconfig|   1 +
>  arch/powerpc/include/asm/uaccess.h  |  21 ++-
>  arch/s390/Kconfig   |   1 +
>  arch/s390/lib/uaccess.c |   2 +
>  arch/sparc/Kconfig  |   1 +
>  arch/sparc/include/asm/uaccess_32.h |  14 +-
>  arch/sparc/include/asm/uaccess_64.h |  11 +-
>  arch/x86/Kconfig|   2 +
>  arch/x86/include/asm/thread_info.h  |  44 ++
>  arch/x86/include/asm/uaccess.h  |  10 +-
>  arch/x86/include/asm/uaccess_32.h   |   2 +
>  arch/x86/include/asm/uaccess_64.h   |   2 +
>  include/linux/mmzone.h  |   2 +
>  include/linux/slab.h|  12 ++
>  include/linux/thread_info.h |  24 
>  init/Kconfig|   2 +
>  mm/Makefile |   4 +
>  mm/slab.c   |  30 
>  mm/slub.c   |  40 ++
>  mm/usercopy.c   | 268 
> 
>  security/Kconfig|  28 
>  31 files changed, 573 insertions(+), 30 deletions(-)
>  create mode 100644 mm/usercopy.c
>
> --
> Kees Cook
> Brillo & Chrome OS Security



-- 
Kees Cook
Chrome OS & Brillo Security

Re: [GIT PULL] usercopy protection for v4.8

[Kees Cook]

On Tue, Jul 26, 2016 at 2:55 PM, Kees Cook  wrote:
> Hi,
>
> This is my next pull request for v4.8, which introduces a kernel self
> protection of copy_to_user/copy_from_user that has been under review and
> test on the kernel-hardening list for a while. It has lived for a bit
> in -next, and appears to be ready IMO. There will be more improvements
> in the future, but this is a solid start.
>
> Again, if I can improve these pull request emails in any way, please
> let me know. :)

Hrm, part of the complexity of the KSPP work: this series depends on
_etext fixes in the arm and arm64 trees, so this should likely wait
until those trees are pulled.

-Kees

>
> Thanks!
>
> -Kees
>
> The following changes since commit 523d939ef98fd712632d93a5a2b588e477a7565e:
>
>   Linux 4.7 (2016-07-24 12:23:50 -0700)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
> tags/usercopy-v4.8
>
> for you to fetch changes up to ed18adc1cdd00a5c55a20fbdaed4804660772281:
>
>   mm: SLUB hardened usercopy support (2016-07-26 14:43:54 -0700)
>
> 
> Implements HARDENED_USERCOPY verification of copy_to_user/copy_from_user
> bounds checking for most architectures on SLAB and SLUB.
>
> 
> Kees Cook (11):
>   mm: Implement stack frame object validation
>   mm: Hardened usercopy
>   x86/uaccess: Enable hardened usercopy
>   ARM: uaccess: Enable hardened usercopy
>   arm64/uaccess: Enable hardened usercopy
>   ia64/uaccess: Enable hardened usercopy
>   powerpc/uaccess: Enable hardened usercopy
>   sparc/uaccess: Enable hardened usercopy
>   s390/uaccess: Enable hardened usercopy
>   mm: SLAB hardened usercopy support
>   mm: SLUB hardened usercopy support
>
> Laura Abbott (1):
>   mm: Add is_migrate_cma_page
>
>  arch/Kconfig|   9 ++
>  arch/arm/Kconfig|   1 +
>  arch/arm/include/asm/uaccess.h  |  11 +-
>  arch/arm64/Kconfig  |   1 +
>  arch/arm64/include/asm/uaccess.h|  29 +++-
>  arch/arm64/kernel/arm64ksyms.c  |   4 +-
>  arch/arm64/lib/copy_from_user.S |   4 +-
>  arch/arm64/lib/copy_to_user.S   |   4 +-
>  arch/ia64/Kconfig   |   1 +
>  arch/ia64/include/asm/uaccess.h |  18 ++-
>  arch/powerpc/Kconfig|   1 +
>  arch/powerpc/include/asm/uaccess.h  |  21 ++-
>  arch/s390/Kconfig   |   1 +
>  arch/s390/lib/uaccess.c |   2 +
>  arch/sparc/Kconfig  |   1 +
>  arch/sparc/include/asm/uaccess_32.h |  14 +-
>  arch/sparc/include/asm/uaccess_64.h |  11 +-
>  arch/x86/Kconfig|   2 +
>  arch/x86/include/asm/thread_info.h  |  44 ++
>  arch/x86/include/asm/uaccess.h  |  10 +-
>  arch/x86/include/asm/uaccess_32.h   |   2 +
>  arch/x86/include/asm/uaccess_64.h   |   2 +
>  include/linux/mmzone.h  |   2 +
>  include/linux/slab.h|  12 ++
>  include/linux/thread_info.h |  24 
>  init/Kconfig|   2 +
>  mm/Makefile |   4 +
>  mm/slab.c   |  30 
>  mm/slub.c   |  40 ++
>  mm/usercopy.c   | 268 
> 
>  security/Kconfig|  28 
>  31 files changed, 573 insertions(+), 30 deletions(-)
>  create mode 100644 mm/usercopy.c
>
> --
> Kees Cook
> Brillo & Chrome OS Security



-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Guenter Roeck]

On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:
> Hi Chris,
>
> On 2016년 07월 27일 11:09, Chris Zhong wrote:
>> Hi Guernter
>>
>> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
>>> Hi Chris,
>>>
>>> On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:
>>>
>>> [ ... ]
>>>
>  > +
>  > +/* Properties of EXTCON_TYPE_DISP. */
>  > +#define EXTCON_PROP_DISP_MIN   150
>  > +#define EXTCON_PROP_DISP_MAX   150
>  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
>  EXTCON_PROP_DISP_MIN)
>
>   + 1
>
>
> ok.

 Tested with these "+1", it works for my DP patch.

>>> You should be able to use
>>> https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
>>> you didn't do that already).
>>>
>>> Thanks,
>>> Guenter
>>
>> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
>>
>>
>
> Do you test it with extcon_set_property_capability()?
> And if you test this patch-es, could you send the tested-by tag for these 
> patches?
>

For my part I did. Above link is public, so you should be able to see
the complete patch set which uses the new API from
drivers/extcon/extcon-cros_ec.c.

I'll re-test tomorrow with the updated patches from your test branch.

> I'll send the next version after a few days.

Great.

Thanks,
Guenter

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Guenter Roeck]

On Tue, Jul 26, 2016 at 8:42 PM, Chanwoo Choi  wrote:
> Hi Chris,
>
> On 2016년 07월 27일 11:09, Chris Zhong wrote:
>> Hi Guernter
>>
>> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
>>> Hi Chris,
>>>
>>> On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:
>>>
>>> [ ... ]
>>>
>  > +
>  > +/* Properties of EXTCON_TYPE_DISP. */
>  > +#define EXTCON_PROP_DISP_MIN   150
>  > +#define EXTCON_PROP_DISP_MAX   150
>  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
>  EXTCON_PROP_DISP_MIN)
>
>   + 1
>
>
> ok.

 Tested with these "+1", it works for my DP patch.

>>> You should be able to use
>>> https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
>>> you didn't do that already).
>>>
>>> Thanks,
>>> Guenter
>>
>> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
>>
>>
>
> Do you test it with extcon_set_property_capability()?
> And if you test this patch-es, could you send the tested-by tag for these 
> patches?
>

For my part I did. Above link is public, so you should be able to see
the complete patch set which uses the new API from
drivers/extcon/extcon-cros_ec.c.

I'll re-test tomorrow with the updated patches from your test branch.

> I'll send the next version after a few days.

Great.

Thanks,
Guenter

Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

[NeilBrown]

On Mon, Jul 25 2016, Michal Hocko wrote:

> On Sat 23-07-16 10:12:24, NeilBrown wrote:

>> Maybe that is impractical, but having firm rules like that would go a
>> long way to make it possible to actually understand and reason about how
>> MM works.  As it is, there seems to be a tendency to put bandaids over
>> bandaids.
>
> Ohh, I would definitely wish for this to be more clear but as it turned
> out over time there are quite some interdependencies between MM/FS/IO
> layers which make the picture really blur. If there is a brave soul to
> make that more clear without breaking any of that it would be really
> cool ;)

Just need that comprehensive regression-test-suite and off we go


>> > My thinking was that throttle_vm_writeout is there to prevent from
>> > dirtying too many pages from the reclaim the context.  PF_LESS_THROTTLE
>> > is part of the writeout so throttling it on too many dirty pages is
>> > questionable (well we get some bias but that is not really reliable). It
>> > still makes sense to throttle when the backing device is congested
>> > because the writeout path wouldn't make much progress anyway and we also
>> > do not want to cycle through LRU lists too quickly in that case.
>> 
>> "dirtying ... from the reclaim context" ??? What does that mean?
>
> Say you would cause a swapout from the reclaim context. You would
> effectively dirty that anon page until it gets written down to the
> storage.

I should probably figure out how swap really works.  I have vague ideas
which are probably missing important details...
Isn't the first step that the page gets moved into the swap-cache - and
marked dirty I guess.  Then it gets written out and the page is marked
'clean'.
Then further memory pressure might push it out of the cache, or an early
re-use would pull it back from the cache.
If so, then "dirtying in reclaim context" could also be described as
"moving into the swap cache" - yes?  So should there be a limit on dirty
pages in the swap cache just like there is for dirty pages in any
filesystem (the max_dirty_ratio thing) ??
Maybe there is?

>> The use of PF_LESS_THROTTLE in current_may_throttle() in vmscan.c is to
>> avoid a live-lock.  A key premise is that nfsd only allocates unbounded
>> memory when it is writing to the page cache.  So it only needs to be
>> throttled when the backing device it is writing to is congested.  It is
>> particularly important that it *doesn't* get throttled just because an
>> NFS backing device is congested, because nfsd might be trying to clear
>> that congestion.
>
> Thanks for the clarification. IIUC then removing throttle_vm_writeout
> for the nfsd writeout should be harmless as well, right?

Certainly shouldn't hurt from the perspective of nfsd.

>> >> The purpose of that flag is to allow a thread to dirty a page-cache page
>> >> as part of cleaning another page-cache page.
>> >> So it makes sense for loop and sometimes for nfsd.  It would make sense
>> >> for dm-crypt if it was putting the encrypted version in the page cache.
>> >> But if dm-crypt is just allocating a transient page (which I think it
>> >> is), then a mempool should be sufficient (and we should make sure it is
>> >> sufficient) and access to an extra 10% (or whatever) of the page cache
>> >> isn't justified.
>> >
>> > If you think that PF_LESS_THROTTLE (ab)use in mempool_alloc is not
>> > appropriate then would a PF_MEMPOOL be any better?
>> 
>> Why a PF rather than a GFP flag?
>
> Well, short answer is that gfp masks are almost depleted.

Really?  We have 26.

pagemap has a cute hack to store both GFP flags and other flag bits in
the one 32 it number per address_space.  'struct address_space' could
afford an extra 32 number I think.

radix_tree_root adds 3 'tag' flags to the gfp_mask.
There is 16bits of free space in radix_tree_node (between 'offset' and
'count').  That space on the root node could store a record of which tags
are set anywhere.  Or would that extra memory de-ref be a killer?

I think we'd end up with cleaner code if we removed the cute-hacks.  And
we'd be able to use 6 more GFP flags!!  (though I do wonder if we really
need all those 26).

Thanks,
NeilBrown



signature.asc
Description: PGP signature

Re: [dm-devel] [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

[NeilBrown]

On Mon, Jul 25 2016, Michal Hocko wrote:

> On Sat 23-07-16 10:12:24, NeilBrown wrote:

>> Maybe that is impractical, but having firm rules like that would go a
>> long way to make it possible to actually understand and reason about how
>> MM works.  As it is, there seems to be a tendency to put bandaids over
>> bandaids.
>
> Ohh, I would definitely wish for this to be more clear but as it turned
> out over time there are quite some interdependencies between MM/FS/IO
> layers which make the picture really blur. If there is a brave soul to
> make that more clear without breaking any of that it would be really
> cool ;)

Just need that comprehensive regression-test-suite and off we go


>> > My thinking was that throttle_vm_writeout is there to prevent from
>> > dirtying too many pages from the reclaim the context.  PF_LESS_THROTTLE
>> > is part of the writeout so throttling it on too many dirty pages is
>> > questionable (well we get some bias but that is not really reliable). It
>> > still makes sense to throttle when the backing device is congested
>> > because the writeout path wouldn't make much progress anyway and we also
>> > do not want to cycle through LRU lists too quickly in that case.
>> 
>> "dirtying ... from the reclaim context" ??? What does that mean?
>
> Say you would cause a swapout from the reclaim context. You would
> effectively dirty that anon page until it gets written down to the
> storage.

I should probably figure out how swap really works.  I have vague ideas
which are probably missing important details...
Isn't the first step that the page gets moved into the swap-cache - and
marked dirty I guess.  Then it gets written out and the page is marked
'clean'.
Then further memory pressure might push it out of the cache, or an early
re-use would pull it back from the cache.
If so, then "dirtying in reclaim context" could also be described as
"moving into the swap cache" - yes?  So should there be a limit on dirty
pages in the swap cache just like there is for dirty pages in any
filesystem (the max_dirty_ratio thing) ??
Maybe there is?

>> The use of PF_LESS_THROTTLE in current_may_throttle() in vmscan.c is to
>> avoid a live-lock.  A key premise is that nfsd only allocates unbounded
>> memory when it is writing to the page cache.  So it only needs to be
>> throttled when the backing device it is writing to is congested.  It is
>> particularly important that it *doesn't* get throttled just because an
>> NFS backing device is congested, because nfsd might be trying to clear
>> that congestion.
>
> Thanks for the clarification. IIUC then removing throttle_vm_writeout
> for the nfsd writeout should be harmless as well, right?

Certainly shouldn't hurt from the perspective of nfsd.

>> >> The purpose of that flag is to allow a thread to dirty a page-cache page
>> >> as part of cleaning another page-cache page.
>> >> So it makes sense for loop and sometimes for nfsd.  It would make sense
>> >> for dm-crypt if it was putting the encrypted version in the page cache.
>> >> But if dm-crypt is just allocating a transient page (which I think it
>> >> is), then a mempool should be sufficient (and we should make sure it is
>> >> sufficient) and access to an extra 10% (or whatever) of the page cache
>> >> isn't justified.
>> >
>> > If you think that PF_LESS_THROTTLE (ab)use in mempool_alloc is not
>> > appropriate then would a PF_MEMPOOL be any better?
>> 
>> Why a PF rather than a GFP flag?
>
> Well, short answer is that gfp masks are almost depleted.

Really?  We have 26.

pagemap has a cute hack to store both GFP flags and other flag bits in
the one 32 it number per address_space.  'struct address_space' could
afford an extra 32 number I think.

radix_tree_root adds 3 'tag' flags to the gfp_mask.
There is 16bits of free space in radix_tree_node (between 'offset' and
'count').  That space on the root node could store a record of which tags
are set anywhere.  Or would that extra memory de-ref be a killer?

I think we'd end up with cleaner code if we removed the cute-hacks.  And
we'd be able to use 6 more GFP flags!!  (though I do wonder if we really
need all those 26).

Thanks,
NeilBrown



signature.asc
Description: PGP signature

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chanwoo Choi]

Hi Chris,

On 2016년 07월 27일 11:09, Chris Zhong wrote:
> Hi Guernter
> 
> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
>> Hi Chris,
>>
>> On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:
>>
>> [ ... ]
>>
  > +
  > +/* Properties of EXTCON_TYPE_DISP. */
  > +#define EXTCON_PROP_DISP_MIN   150
  > +#define EXTCON_PROP_DISP_MAX   150
  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
  EXTCON_PROP_DISP_MIN)

   + 1


 ok.
>>>
>>> Tested with these "+1", it works for my DP patch.
>>>
>> You should be able to use
>> https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
>> you didn't do that already).
>>
>> Thanks,
>> Guenter
> 
> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
> 
> 

Do you test it with extcon_set_property_capability()?
And if you test this patch-es, could you send the tested-by tag for these 
patches?

I'll send the next version after a few days.

Regards,
Chanwoo Choi

Re: [PATCH 2/6] extcon: Add the support for extcon property according to extcon type

[Chanwoo Choi]

Hi Chris,

On 2016년 07월 27일 11:09, Chris Zhong wrote:
> Hi Guernter
> 
> On 07/27/2016 09:44 AM, Guenter Roeck wrote:
>> Hi Chris,
>>
>> On Tue, Jul 26, 2016 at 6:15 PM, Chris Zhong  wrote:
>>
>> [ ... ]
>>
  > +
  > +/* Properties of EXTCON_TYPE_DISP. */
  > +#define EXTCON_PROP_DISP_MIN   150
  > +#define EXTCON_PROP_DISP_MAX   150
  > +#define EXTCON_PROP_DISP_CNT   (EXTCON_PROP_DISP_MAX -
  EXTCON_PROP_DISP_MIN)

   + 1


 ok.
>>>
>>> Tested with these "+1", it works for my DP patch.
>>>
>> You should be able to use
>> https://chromium-review.googlesource.com/#/c/363623/1 as baseline (if
>> you didn't do that already).
>>
>> Thanks,
>> Guenter
> 
> Thanks Guenter, and I saw this bug has fixed in extcon-test branch.
> 
> 

Do you test it with extcon_set_property_capability()?
And if you test this patch-es, could you send the tested-by tag for these 
patches?

I'll send the next version after a few days.

Regards,
Chanwoo Choi

Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT

[Jisheng Zhang]

+1

On Tue, 26 Jul 2016 09:11:49 -0500 Timur Tabi  wrote:

> Will Deacon wrote:
> > The kernel really needs to support both of those platforms :/
> >
> > For the memory-mapped counter registers, the architecture says:
> >
> >`If the implementation supports 64-bit atomic accesses, then the
> > CNTV_CVAL register must be accessible as an atomic 64-bit value.'
> >
> > which is borderline tautological. If we take the generous reading that
> > this means AArch64 CPUs can use readq (and I'm not completely
> > comfortable with that assertion, particularly as you say that it breaks
> > the model), then you still need to use readq_relaxed here to avoid a
> > DSB. Furthermore, what are you going to do for AArch32? readq doesn't
> > exist over there, and if you use the generic implementation then it's
> > not atomic. In which case, we end up with the current code, as well as a
> > readq_relaxed guarded by a questionable #ifdef that is known to break a
> > supported platform for an unknown performance improvement. Hardly a big
> > win.  
> 
> I know Fu dropped this patch, and I don't want to kick a dead horse, but 
> I was wondering if it would be okay to do this:
> 
> static u64 arch_counter_get_cntvct_mem(void)
> {
> #ifdef readq_relaxed
>   return readq_relaxed(arch_counter_base + CNTVCT_LO);
> #else
>   u32 vct_lo, vct_hi, tmp_hi;
> 
>   do {
>   vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>   vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
>   tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>   } while (vct_hi != tmp_hi);
> 
>   return ((u64) vct_hi << 32) | vct_lo;
> #endif
> }
> 
> readq and readq_relaxed are defined in arch/arm64/include/asm/io.h.  Why 
> would the function exist if AArch64 CPUs can't use it?

+1

I measured the performance on berlin arm64 platforms:

compared with original version, using readq_relaxed could reduce
time of arch_counter_get_cntvct_mem() by about 42%!

Thanks,
Jisheng

Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT

[Jisheng Zhang]

+1

On Tue, 26 Jul 2016 09:11:49 -0500 Timur Tabi  wrote:

> Will Deacon wrote:
> > The kernel really needs to support both of those platforms :/
> >
> > For the memory-mapped counter registers, the architecture says:
> >
> >`If the implementation supports 64-bit atomic accesses, then the
> > CNTV_CVAL register must be accessible as an atomic 64-bit value.'
> >
> > which is borderline tautological. If we take the generous reading that
> > this means AArch64 CPUs can use readq (and I'm not completely
> > comfortable with that assertion, particularly as you say that it breaks
> > the model), then you still need to use readq_relaxed here to avoid a
> > DSB. Furthermore, what are you going to do for AArch32? readq doesn't
> > exist over there, and if you use the generic implementation then it's
> > not atomic. In which case, we end up with the current code, as well as a
> > readq_relaxed guarded by a questionable #ifdef that is known to break a
> > supported platform for an unknown performance improvement. Hardly a big
> > win.  
> 
> I know Fu dropped this patch, and I don't want to kick a dead horse, but 
> I was wondering if it would be okay to do this:
> 
> static u64 arch_counter_get_cntvct_mem(void)
> {
> #ifdef readq_relaxed
>   return readq_relaxed(arch_counter_base + CNTVCT_LO);
> #else
>   u32 vct_lo, vct_hi, tmp_hi;
> 
>   do {
>   vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>   vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
>   tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
>   } while (vct_hi != tmp_hi);
> 
>   return ((u64) vct_hi << 32) | vct_lo;
> #endif
> }
> 
> readq and readq_relaxed are defined in arch/arm64/include/asm/io.h.  Why 
> would the function exist if AArch64 CPUs can't use it?

+1

I measured the performance on berlin arm64 platforms:

compared with original version, using readq_relaxed could reduce
time of arch_counter_get_cntvct_mem() by about 42%!

Thanks,
Jisheng

Re: debug tip after earlycon is closed?

[Masahiro Yamada]

Hi Sebastian,


2016-07-27 11:17 GMT+09:00 Sebastian Reichel :
> Hi,
>
> On Wed, Jul 27, 2016 at 10:23:09AM +0900, Masahiro Yamada wrote:
>> When the kernel fails to boot and its log console is silent,
>> I use earlycon and I often find the cause of error with it.
>>
>> But, I have been wondering if there is an easy-to-use
>> debug tip which is available after earlycon is disabled.
>>
>> I noticed the current mainline would not boot on my ARMv8 board.
>> According to the following log, I am guessing something wrong
>> is happening after the "bootconsole [uniphier0] disabled" log.
>>
>> Is there a good practice to see more log?
>
> Documentation/kernel-parameters.txt
> keep_bootcon[KNL]
> Do not unregister boot console at start. This is only
> useful for debugging when something happens in the 
> window
> between unregistering the boot console and 
> initializing
> the real console.


I did not know this kernel parameter, and it is exactly what I wanted.
Thanks a lot!


-- 
Best Regards
Masahiro Yamada

Re: debug tip after earlycon is closed?

[Masahiro Yamada]

Hi Sebastian,


2016-07-27 11:17 GMT+09:00 Sebastian Reichel :
> Hi,
>
> On Wed, Jul 27, 2016 at 10:23:09AM +0900, Masahiro Yamada wrote:
>> When the kernel fails to boot and its log console is silent,
>> I use earlycon and I often find the cause of error with it.
>>
>> But, I have been wondering if there is an easy-to-use
>> debug tip which is available after earlycon is disabled.
>>
>> I noticed the current mainline would not boot on my ARMv8 board.
>> According to the following log, I am guessing something wrong
>> is happening after the "bootconsole [uniphier0] disabled" log.
>>
>> Is there a good practice to see more log?
>
> Documentation/kernel-parameters.txt
> keep_bootcon[KNL]
> Do not unregister boot console at start. This is only
> useful for debugging when something happens in the 
> window
> between unregistering the boot console and 
> initializing
> the real console.


I did not know this kernel parameter, and it is exactly what I wanted.
Thanks a lot!


-- 
Best Regards
Masahiro Yamada

from Walters's Wife, Deborah writing from my sick bed

[Deborah Walters]

from Walters's Wife, Deborah writing from my sick bed
This is Walters's wife, Deborah. I am writing this message to you today because 
of my Love for the less privileges. As a fellow faithful person like you, it is 
my desire and enthusiasm to donate amount of $19.1 million in your hands for a 
charity project, which will benefit the less privilege. Kindly reply for more 
detail;
Best Regards and remain bless.
Mrs. Deborah Walters

from Walters's Wife, Deborah writing from my sick bed

[Deborah Walters]

from Walters's Wife, Deborah writing from my sick bed
This is Walters's wife, Deborah. I am writing this message to you today because 
of my Love for the less privileges. As a fellow faithful person like you, it is 
my desire and enthusiasm to donate amount of $19.1 million in your hands for a 
charity project, which will benefit the less privilege. Kindly reply for more 
detail;
Best Regards and remain bless.
Mrs. Deborah Walters

[PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Bob Liu]

The current VBD layer reserves buffer space for each attached device based on
three statically configured settings which are read at boot time.
 * max_indirect_segs: Maximum amount of segments.
 * max_ring_page_order: Maximum order of pages to be used for the shared ring.
 * max_queues: Maximum of queues(rings) to be used.

But the storage backend, workload, and guest memory result in very different
tuning requirements. It's impossible to centrally predict application
characteristics so it's best to leave allow the settings can be dynamiclly
adjusted based on workload inside the Guest.

Usage:
Show current values:
cat /sys/devices/vbd-xxx/max_indirect_segs
cat /sys/devices/vbd-xxx/max_ring_page_order
cat /sys/devices/vbd-xxx/max_queues

Write new values:
echo  > /sys/devices/vbd-xxx/max_indirect_segs
echo  > /sys/devices/vbd-xxx/max_ring_page_order
echo  > /sys/devices/vbd-xxx/max_queues

Signed-off-by: Bob Liu 
--
v3:
 * Remove new_max_indirect_segments.
 * Fix BUG_ON().
v2:
 * Rename to max_ring_page_order.
 * Remove the waiting code suggested by Roger.
---
 drivers/block/xen-blkfront.c |  277 --
 1 file changed, 269 insertions(+), 8 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 1b4c380..57baa54 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -212,6 +212,10 @@ struct blkfront_info
/* Save uncomplete reqs and bios for migration. */
struct list_head requests;
struct bio_list bio_list;
+   /* For dynamic configuration. */
+   unsigned int reconfiguring:1;
+   unsigned int max_ring_page_order;
+   unsigned int max_queues;
 };
 
 static unsigned int nr_minors;
@@ -1350,6 +1354,31 @@ static void blkif_free(struct blkfront_info *info, int 
suspend)
for (i = 0; i < info->nr_rings; i++)
blkif_free_ring(>rinfo[i]);
 
+   /* Remove old xenstore nodes. */
+   if (info->nr_ring_pages > 1)
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-page-order");
+
+   if (info->nr_rings == 1) {
+   if (info->nr_ring_pages == 1) {
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-ref");
+   } else {
+   for (i = 0; i < info->nr_ring_pages; i++) {
+   char ring_ref_name[RINGREF_NAME_LEN];
+
+   snprintf(ring_ref_name, RINGREF_NAME_LEN, 
"ring-ref%u", i);
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, 
ring_ref_name);
+   }
+   }
+   } else {
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, 
"multi-queue-num-queues");
+
+   for (i = 0; i < info->nr_rings; i++) {
+   char queuename[QUEUE_NAME_LEN];
+
+   snprintf(queuename, QUEUE_NAME_LEN, "queue-%u", i);
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, queuename);
+   }
+   }
kfree(info->rinfo);
info->rinfo = NULL;
info->nr_rings = 0;
@@ -1763,15 +1792,20 @@ static int talk_to_blkback(struct xenbus_device *dev,
const char *message = NULL;
struct xenbus_transaction xbt;
int err;
-   unsigned int i, max_page_order = 0;
+   unsigned int i, backend_max_order = 0;
unsigned int ring_page_order = 0;
 
err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "max-ring-page-order", "%u", _page_order);
+  "max-ring-page-order", "%u", _max_order);
if (err != 1)
info->nr_ring_pages = 1;
else {
-   ring_page_order = min(xen_blkif_max_ring_order, max_page_order);
+   if (info->max_ring_page_order)
+   /* Dynamic configured through /sys. */
+   ring_page_order = min(info->max_ring_page_order, 
backend_max_order);
+   else
+   /* Default. */
+   ring_page_order = min(xen_blkif_max_ring_order, 
backend_max_order);
info->nr_ring_pages = 1 << ring_page_order;
}
 
@@ -1894,7 +1928,13 @@ static int negotiate_mq(struct blkfront_info *info)
if (err < 0)
backend_max_queues = 1;
 
-   info->nr_rings = min(backend_max_queues, xen_blkif_max_queues);
+   if (info->max_queues)
+   /* Dynamic configured through /sys */
+   info->nr_rings = min(backend_max_queues, info->max_queues);
+   else
+   /* Default. */
+   info->nr_rings = min(backend_max_queues, xen_blkif_max_queues);
+
/* We need at least one ring. */
if (!info->nr_rings)
info->nr_rings = 1;
@@ -2352,11 +2392,198 @@ static void blkfront_gather_backend_features(struct 
blkfront_info *info)
NULL);
if (err)

[PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

[Bob Liu]

The current VBD layer reserves buffer space for each attached device based on
three statically configured settings which are read at boot time.
 * max_indirect_segs: Maximum amount of segments.
 * max_ring_page_order: Maximum order of pages to be used for the shared ring.
 * max_queues: Maximum of queues(rings) to be used.

But the storage backend, workload, and guest memory result in very different
tuning requirements. It's impossible to centrally predict application
characteristics so it's best to leave allow the settings can be dynamiclly
adjusted based on workload inside the Guest.

Usage:
Show current values:
cat /sys/devices/vbd-xxx/max_indirect_segs
cat /sys/devices/vbd-xxx/max_ring_page_order
cat /sys/devices/vbd-xxx/max_queues

Write new values:
echo  > /sys/devices/vbd-xxx/max_indirect_segs
echo  > /sys/devices/vbd-xxx/max_ring_page_order
echo  > /sys/devices/vbd-xxx/max_queues

Signed-off-by: Bob Liu 
--
v3:
 * Remove new_max_indirect_segments.
 * Fix BUG_ON().
v2:
 * Rename to max_ring_page_order.
 * Remove the waiting code suggested by Roger.
---
 drivers/block/xen-blkfront.c |  277 --
 1 file changed, 269 insertions(+), 8 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 1b4c380..57baa54 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -212,6 +212,10 @@ struct blkfront_info
/* Save uncomplete reqs and bios for migration. */
struct list_head requests;
struct bio_list bio_list;
+   /* For dynamic configuration. */
+   unsigned int reconfiguring:1;
+   unsigned int max_ring_page_order;
+   unsigned int max_queues;
 };
 
 static unsigned int nr_minors;
@@ -1350,6 +1354,31 @@ static void blkif_free(struct blkfront_info *info, int 
suspend)
for (i = 0; i < info->nr_rings; i++)
blkif_free_ring(>rinfo[i]);
 
+   /* Remove old xenstore nodes. */
+   if (info->nr_ring_pages > 1)
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-page-order");
+
+   if (info->nr_rings == 1) {
+   if (info->nr_ring_pages == 1) {
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, "ring-ref");
+   } else {
+   for (i = 0; i < info->nr_ring_pages; i++) {
+   char ring_ref_name[RINGREF_NAME_LEN];
+
+   snprintf(ring_ref_name, RINGREF_NAME_LEN, 
"ring-ref%u", i);
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, 
ring_ref_name);
+   }
+   }
+   } else {
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, 
"multi-queue-num-queues");
+
+   for (i = 0; i < info->nr_rings; i++) {
+   char queuename[QUEUE_NAME_LEN];
+
+   snprintf(queuename, QUEUE_NAME_LEN, "queue-%u", i);
+   xenbus_rm(XBT_NIL, info->xbdev->nodename, queuename);
+   }
+   }
kfree(info->rinfo);
info->rinfo = NULL;
info->nr_rings = 0;
@@ -1763,15 +1792,20 @@ static int talk_to_blkback(struct xenbus_device *dev,
const char *message = NULL;
struct xenbus_transaction xbt;
int err;
-   unsigned int i, max_page_order = 0;
+   unsigned int i, backend_max_order = 0;
unsigned int ring_page_order = 0;
 
err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-  "max-ring-page-order", "%u", _page_order);
+  "max-ring-page-order", "%u", _max_order);
if (err != 1)
info->nr_ring_pages = 1;
else {
-   ring_page_order = min(xen_blkif_max_ring_order, max_page_order);
+   if (info->max_ring_page_order)
+   /* Dynamic configured through /sys. */
+   ring_page_order = min(info->max_ring_page_order, 
backend_max_order);
+   else
+   /* Default. */
+   ring_page_order = min(xen_blkif_max_ring_order, 
backend_max_order);
info->nr_ring_pages = 1 << ring_page_order;
}
 
@@ -1894,7 +1928,13 @@ static int negotiate_mq(struct blkfront_info *info)
if (err < 0)
backend_max_queues = 1;
 
-   info->nr_rings = min(backend_max_queues, xen_blkif_max_queues);
+   if (info->max_queues)
+   /* Dynamic configured through /sys */
+   info->nr_rings = min(backend_max_queues, info->max_queues);
+   else
+   /* Default. */
+   info->nr_rings = min(backend_max_queues, xen_blkif_max_queues);
+
/* We need at least one ring. */
if (!info->nr_rings)
info->nr_rings = 1;
@@ -2352,11 +2392,198 @@ static void blkfront_gather_backend_features(struct 
blkfront_info *info)
NULL);
if (err)

[PATCH] tools: iio: iio_generic_buffer: initialize channel array pointer

[Alison Schofield]

Uninitialized channel pointer causes segmentation fault when we
call free(channel) during cleanup() with no channels initialized.
This happens when you exit early for usage errors.  Initialize
the pointer to NULL when it is declared.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 tools/iio/iio_generic_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c
index 0e8a1f7..ae68bf0 100644
--- a/tools/iio/iio_generic_buffer.c
+++ b/tools/iio/iio_generic_buffer.c
@@ -348,7 +348,7 @@ int main(int argc, char **argv)
int notrigger = 0;
char *dummy;
 
-   struct iio_channel_info *channels;
+   struct iio_channel_info *channels = NULL;
 
register_cleanup();
 
-- 
2.1.4

[PATCH] tools: iio: iio_generic_buffer: initialize channel array pointer

[Alison Schofield]

Uninitialized channel pointer causes segmentation fault when we
call free(channel) during cleanup() with no channels initialized.
This happens when you exit early for usage errors.  Initialize
the pointer to NULL when it is declared.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 tools/iio/iio_generic_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/iio/iio_generic_buffer.c b/tools/iio/iio_generic_buffer.c
index 0e8a1f7..ae68bf0 100644
--- a/tools/iio/iio_generic_buffer.c
+++ b/tools/iio/iio_generic_buffer.c
@@ -348,7 +348,7 @@ int main(int argc, char **argv)
int notrigger = 0;
char *dummy;
 
-   struct iio_channel_info *channels;
+   struct iio_channel_info *channels = NULL;
 
register_cleanup();
 
-- 
2.1.4

Re: [PATCH v3] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

[Baolin Wang]

Hi Felipe,

On 26 July 2016 at 19:06, Felipe Ferreri Tonello  wrote:
> Hi Baolin,
>
> Sorry for not replying for previous emails because for some reason these
> emails were archived. :(
>
> On 12/07/16 10:01, Baolin Wang wrote:
>> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang 
>> Acked-by: Michal Nazarewicz 
>> ---
>> Changelog:
>> v2:
>>  - Simplify the method to get buffer length.
>> v1:
>>  - Remove the in_ep modification.
>>  - Remove max_t() function.
>>
>>  drivers/usb/gadget/function/f_midi.c |   11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..3486941 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -359,10 +359,13 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* allocate a bunch of read buffers and queue them all at once. */
>>   for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> + unsigned length;
>> +
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>> +
>> + req = midi_alloc_ep_req(midi->out_ep, length);
>>   if (req == NULL)
>>   return -ENOMEM;
>>
>>
>
> Yes, as mentioned before, my intent was to align the size otherwise an
> actual nasty bug happens.
>
> I have two problems with this approach:
> * usb_ep_align_maybe() has a bug that it doesn't convert wMaxPacketSize
> endianness to the CPU. See my patch on that[1] subject. Also this

Yes, you are right, I missed that.

> function uses round_up which expects x and y to be a power of 2, is that
> a feasible assumption?

I suppose it only expects y is a power of 2.

> * If the gadget driver doesn't support quirk_ep_out_aligned_size,
> usb_ep_align_maybe() can potentially return a len < wMaxPacketSize.
> Basically causing a regression.

Okay.

>
> I believe we should protect this bad behavior on alloc_ep_req() in
> drivers/usb/gadget/u_f.c by forcing align the size if the endpoint in
> subject is OUT.
>
> [1] [PATCH 1/4] usb: gadget: f_midi: fixed endianness when using
> wMaxPacketSize: https://lkml.org/lkml/2016/7/25/1028


-- 
Baolin.wang
Best Regards

Re: [PATCH v3] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

[Baolin Wang]

Hi Felipe,

On 26 July 2016 at 19:06, Felipe Ferreri Tonello  wrote:
> Hi Baolin,
>
> Sorry for not replying for previous emails because for some reason these
> emails were archived. :(
>
> On 12/07/16 10:01, Baolin Wang wrote:
>> Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
>> attribute, which means it need to align the request buffer's size to an ep's
>> maxpacketsize.
>>
>> Thus we add usb_ep_align_maybe() function to check if it is need to align
>> the request buffer's size to an ep's maxpacketsize.
>>
>> Signed-off-by: Baolin Wang 
>> Acked-by: Michal Nazarewicz 
>> ---
>> Changelog:
>> v2:
>>  - Simplify the method to get buffer length.
>> v1:
>>  - Remove the in_ep modification.
>>  - Remove max_t() function.
>>
>>  drivers/usb/gadget/function/f_midi.c |   11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 58fc199..3486941 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -359,10 +359,13 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>>
>>   /* allocate a bunch of read buffers and queue them all at once. */
>>   for (i = 0; i < midi->qlen && err == 0; i++) {
>> - struct usb_request *req =
>> - midi_alloc_ep_req(midi->out_ep,
>> - max_t(unsigned, midi->buflen,
>> - bulk_out_desc.wMaxPacketSize));
>> + struct usb_request *req;
>> + unsigned length;
>> +
>> + length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
>> + midi->buflen);
>> +
>> + req = midi_alloc_ep_req(midi->out_ep, length);
>>   if (req == NULL)
>>   return -ENOMEM;
>>
>>
>
> Yes, as mentioned before, my intent was to align the size otherwise an
> actual nasty bug happens.
>
> I have two problems with this approach:
> * usb_ep_align_maybe() has a bug that it doesn't convert wMaxPacketSize
> endianness to the CPU. See my patch on that[1] subject. Also this

Yes, you are right, I missed that.

> function uses round_up which expects x and y to be a power of 2, is that
> a feasible assumption?

I suppose it only expects y is a power of 2.

> * If the gadget driver doesn't support quirk_ep_out_aligned_size,
> usb_ep_align_maybe() can potentially return a len < wMaxPacketSize.
> Basically causing a regression.

Okay.

>
> I believe we should protect this bad behavior on alloc_ep_req() in
> drivers/usb/gadget/u_f.c by forcing align the size if the endpoint in
> subject is OUT.
>
> [1] [PATCH 1/4] usb: gadget: f_midi: fixed endianness when using
> wMaxPacketSize: https://lkml.org/lkml/2016/7/25/1028


-- 
Baolin.wang
Best Regards

[RESEND PATCH 2/4] fs: befs: Coding style fix

[Salah Triki]

Constant has to be capitalized.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/btree.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/befs/btree.c b/fs/befs/btree.c
index 307645f9..e59ad20 100644
--- a/fs/befs/btree.c
+++ b/fs/befs/btree.c
@@ -85,7 +85,7 @@ struct befs_btree_node {
 };
 
 /* local constants */
-static const befs_off_t befs_bt_inval = 0xULL;
+static const befs_off_t BEFS_BT_INVAL = 0xULL;
 
 /* local functions */
 static int befs_btree_seekleaf(struct super_block *sb, const befs_data_stream 
*ds,
@@ -467,7 +467,7 @@ befs_btree_read(struct super_block *sb, const 
befs_data_stream *ds,
while (key_sum + this_node->head.all_key_count <= key_no) {
 
/* no more nodes to look in: key_no is too large */
-   if (this_node->head.right == befs_bt_inval) {
+   if (this_node->head.right == BEFS_BT_INVAL) {
*keysize = 0;
*value = 0;
befs_debug(sb,
@@ -608,7 +608,7 @@ static int
 befs_leafnode(struct befs_btree_node *node)
 {
/* all interior nodes (and only interior nodes) have an overflow node */
-   if (node->head.overflow == befs_bt_inval)
+   if (node->head.overflow == BEFS_BT_INVAL)
return 1;
else
return 0;
-- 
1.9.1

[RESEND PATCH 2/4] fs: befs: Coding style fix

[Salah Triki]

Constant has to be capitalized.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/btree.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/befs/btree.c b/fs/befs/btree.c
index 307645f9..e59ad20 100644
--- a/fs/befs/btree.c
+++ b/fs/befs/btree.c
@@ -85,7 +85,7 @@ struct befs_btree_node {
 };
 
 /* local constants */
-static const befs_off_t befs_bt_inval = 0xULL;
+static const befs_off_t BEFS_BT_INVAL = 0xULL;
 
 /* local functions */
 static int befs_btree_seekleaf(struct super_block *sb, const befs_data_stream 
*ds,
@@ -467,7 +467,7 @@ befs_btree_read(struct super_block *sb, const 
befs_data_stream *ds,
while (key_sum + this_node->head.all_key_count <= key_no) {
 
/* no more nodes to look in: key_no is too large */
-   if (this_node->head.right == befs_bt_inval) {
+   if (this_node->head.right == BEFS_BT_INVAL) {
*keysize = 0;
*value = 0;
befs_debug(sb,
@@ -608,7 +608,7 @@ static int
 befs_leafnode(struct befs_btree_node *node)
 {
/* all interior nodes (and only interior nodes) have an overflow node */
-   if (node->head.overflow == befs_bt_inval)
+   if (node->head.overflow == BEFS_BT_INVAL)
return 1;
else
return 0;
-- 
1.9.1

[RESEND PATCH 4/4] fs: befs: Remove goto from befs_bread_iaddr

[Salah Triki]

Since goto statement merely returns NULL, replace it with return
statement.

Signed-off-by: Salah Triki 
---
 fs/befs/io.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/fs/befs/io.c b/fs/befs/io.c
index 4223b77..af631a6 100644
--- a/fs/befs/io.c
+++ b/fs/befs/io.c
@@ -37,7 +37,7 @@ befs_bread_iaddr(struct super_block *sb, befs_inode_addr 
iaddr)
if (iaddr.allocation_group > befs_sb->num_ags) {
befs_error(sb, "BEFS: Invalid allocation group %u, max is %u",
   iaddr.allocation_group, befs_sb->num_ags);
-   goto error;
+   return NULL;
}
 
block = iaddr2blockno(sb, );
@@ -49,13 +49,9 @@ befs_bread_iaddr(struct super_block *sb, befs_inode_addr 
iaddr)
if (bh == NULL) {
befs_error(sb, "Failed to read block %lu",
   (unsigned long)block);
-   goto error;
+   return NULL;
}
 
befs_debug(sb, "<--- %s", __func__);
return bh;
-
-  error:
-   befs_debug(sb, "<--- %s ERROR", __func__);
-   return NULL;
 }
-- 
1.9.1

[RESEND PATCH 3/4] fs: befs: Remove useless calls to brelse in befs_find_brun_dblindirect

[Salah Triki]

The calls to brelse are useless since dbl_indir_block and indir_block
are NULL.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/datastream.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/befs/datastream.c b/fs/befs/datastream.c
index e224b9a..b68b6f9 100644
--- a/fs/befs/datastream.c
+++ b/fs/befs/datastream.c
@@ -471,7 +471,6 @@ befs_find_brun_dblindirect(struct super_block *sb,
   (unsigned long)
   iaddr2blockno(sb, >double_indirect) +
   dbl_which_block);
-   brelse(dbl_indir_block);
return BEFS_ERR;
}
 
@@ -496,7 +495,6 @@ befs_find_brun_dblindirect(struct super_block *sb,
befs_error(sb, "%s couldn't read the indirect block "
   "at blockno %lu", __func__, (unsigned long)
   iaddr2blockno(sb, _run) + which_block);
-   brelse(indir_block);
return BEFS_ERR;
}
 
-- 
1.9.1

[RESEND PATCH 1/4] fs: befs: Remove redundant validation from befs_find_brun_direct

[Salah Triki]

The only caller of befs_find_brun_direct is befs_fblock2brun, which
already validates that the block is within the range of direct blocks.
So remove the duplicate validation.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/datastream.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/fs/befs/datastream.c b/fs/befs/datastream.c
index 26cc417..e224b9a 100644
--- a/fs/befs/datastream.c
+++ b/fs/befs/datastream.c
@@ -249,17 +249,9 @@ befs_find_brun_direct(struct super_block *sb, const 
befs_data_stream *data,
int i;
const befs_block_run *array = data->direct;
befs_blocknr_t sum;
-   befs_blocknr_t max_block =
-   data->max_direct_range >> BEFS_SB(sb)->block_shift;
 
befs_debug(sb, "---> %s, find %lu", __func__, (unsigned long)blockno);
 
-   if (blockno > max_block) {
-   befs_error(sb, "%s passed block outside of direct region",
-  __func__);
-   return BEFS_ERR;
-   }
-
for (i = 0, sum = 0; i < BEFS_NUM_DIRECT_BLOCKS;
 sum += array[i].len, i++) {
if (blockno >= sum && blockno < sum + (array[i].len)) {
-- 
1.9.1

[RESEND PATCH 4/4] fs: befs: Remove goto from befs_bread_iaddr

[Salah Triki]

Since goto statement merely returns NULL, replace it with return
statement.

Signed-off-by: Salah Triki 
---
 fs/befs/io.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/fs/befs/io.c b/fs/befs/io.c
index 4223b77..af631a6 100644
--- a/fs/befs/io.c
+++ b/fs/befs/io.c
@@ -37,7 +37,7 @@ befs_bread_iaddr(struct super_block *sb, befs_inode_addr 
iaddr)
if (iaddr.allocation_group > befs_sb->num_ags) {
befs_error(sb, "BEFS: Invalid allocation group %u, max is %u",
   iaddr.allocation_group, befs_sb->num_ags);
-   goto error;
+   return NULL;
}
 
block = iaddr2blockno(sb, );
@@ -49,13 +49,9 @@ befs_bread_iaddr(struct super_block *sb, befs_inode_addr 
iaddr)
if (bh == NULL) {
befs_error(sb, "Failed to read block %lu",
   (unsigned long)block);
-   goto error;
+   return NULL;
}
 
befs_debug(sb, "<--- %s", __func__);
return bh;
-
-  error:
-   befs_debug(sb, "<--- %s ERROR", __func__);
-   return NULL;
 }
-- 
1.9.1

[RESEND PATCH 3/4] fs: befs: Remove useless calls to brelse in befs_find_brun_dblindirect

[Salah Triki]

The calls to brelse are useless since dbl_indir_block and indir_block
are NULL.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/datastream.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/befs/datastream.c b/fs/befs/datastream.c
index e224b9a..b68b6f9 100644
--- a/fs/befs/datastream.c
+++ b/fs/befs/datastream.c
@@ -471,7 +471,6 @@ befs_find_brun_dblindirect(struct super_block *sb,
   (unsigned long)
   iaddr2blockno(sb, >double_indirect) +
   dbl_which_block);
-   brelse(dbl_indir_block);
return BEFS_ERR;
}
 
@@ -496,7 +495,6 @@ befs_find_brun_dblindirect(struct super_block *sb,
befs_error(sb, "%s couldn't read the indirect block "
   "at blockno %lu", __func__, (unsigned long)
   iaddr2blockno(sb, _run) + which_block);
-   brelse(indir_block);
return BEFS_ERR;
}
 
-- 
1.9.1

[RESEND PATCH 1/4] fs: befs: Remove redundant validation from befs_find_brun_direct

[Salah Triki]

The only caller of befs_find_brun_direct is befs_fblock2brun, which
already validates that the block is within the range of direct blocks.
So remove the duplicate validation.

Signed-off-by: Salah Triki 
Acked-by: Luis de Bethencourt 
---
 fs/befs/datastream.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/fs/befs/datastream.c b/fs/befs/datastream.c
index 26cc417..e224b9a 100644
--- a/fs/befs/datastream.c
+++ b/fs/befs/datastream.c
@@ -249,17 +249,9 @@ befs_find_brun_direct(struct super_block *sb, const 
befs_data_stream *data,
int i;
const befs_block_run *array = data->direct;
befs_blocknr_t sum;
-   befs_blocknr_t max_block =
-   data->max_direct_range >> BEFS_SB(sb)->block_shift;
 
befs_debug(sb, "---> %s, find %lu", __func__, (unsigned long)blockno);
 
-   if (blockno > max_block) {
-   befs_error(sb, "%s passed block outside of direct region",
-  __func__);
-   return BEFS_ERR;
-   }
-
for (i = 0, sum = 0; i < BEFS_NUM_DIRECT_BLOCKS;
 sum += array[i].len, i++) {
if (blockno >= sum && blockno < sum + (array[i].len)) {
-- 
1.9.1

Re: Volunteering for BeFS maintainership

[Theodore Ts'o]

On Tue, Jul 26, 2016 at 09:30:13PM +0100, Luis de Bethencourt wrote:
> > 
> > Sounds great!  Do you have a git tree set up for your befs development?
> 
> Yes, I have the following in github (if that is OK):
> https://github.com/luisbg/linux-befs
> 
> I have two branches there based on Linus' master:
>  - befs-linus: with patches Andrew Morton has approved
>  - befs-next: with patches I've tested but that remain under review

So it sounds like you plan to send patches through Andrew's tree.
That works fine, although if you end up sending a larger number of
patches through the linux-mm tree, it might make sense for you to send
patches to Linus directly.  So if you have a chance to get a GPG key
which is signed by people in the Kernel keyring, that would be a good
preparation for that eventuality.  That will require face-to-face
verification of your identity by people who are already in the GPG web
of trust, so it's good to plan for that in advance.

> It would be amazing to have a framework to run xfstests in a GCE VM.

Please see:

   https://thunk.org/gce-xfstests

and

https://github.com/tytso/xfstests-bld/blob/master/README.md

for more information.

I plan to do some work to make it simpler to get started using
gce-xfstests.  (Specifically, so you don't have to build the tree and
generate your own GCE image, but instead using a premade one.)

Are there userspace tools available to create and consistency check
BeFS file systems?  If so, I can try to get those included into the
test appliance image.  (Better yet, if you can arrange to have someone
create a debian package for BeFStools, that would be great.)

- Ted

Re: Volunteering for BeFS maintainership

[Theodore Ts'o]

On Tue, Jul 26, 2016 at 09:30:13PM +0100, Luis de Bethencourt wrote:
> > 
> > Sounds great!  Do you have a git tree set up for your befs development?
> 
> Yes, I have the following in github (if that is OK):
> https://github.com/luisbg/linux-befs
> 
> I have two branches there based on Linus' master:
>  - befs-linus: with patches Andrew Morton has approved
>  - befs-next: with patches I've tested but that remain under review

So it sounds like you plan to send patches through Andrew's tree.
That works fine, although if you end up sending a larger number of
patches through the linux-mm tree, it might make sense for you to send
patches to Linus directly.  So if you have a chance to get a GPG key
which is signed by people in the Kernel keyring, that would be a good
preparation for that eventuality.  That will require face-to-face
verification of your identity by people who are already in the GPG web
of trust, so it's good to plan for that in advance.

> It would be amazing to have a framework to run xfstests in a GCE VM.

Please see:

   https://thunk.org/gce-xfstests

and

https://github.com/tytso/xfstests-bld/blob/master/README.md

for more information.

I plan to do some work to make it simpler to get started using
gce-xfstests.  (Specifically, so you don't have to build the tree and
generate your own GCE image, but instead using a premade one.)

Are there userspace tools available to create and consistency check
BeFS file systems?  If so, I can try to get those included into the
test appliance image.  (Better yet, if you can arrange to have someone
create a debian package for BeFStools, that would be great.)

- Ted

Re: [PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel

[Mark yao]

On 2016年07月26日 17:02, Thierry Reding wrote:

On Tue, Jul 26, 2016 at 10:01:32AM +0800, Mark yao wrote:

On 2016年07月25日 23:21, Thierry Reding wrote:

 On Wed, Jul 20, 2016 at 11:18:50AM +0800, Mark Yao wrote:

 Allow user add display timing on device tree with simple-panel-dsi
 or simple-panel.

 Cc: Thierry Reding 
 Cc: Rob Herring 
 Cc: Mark Rutland 

 Signed-off-by: Mark Yao 
 ---
  .../bindings/display/panel/simple-panel.txt| 48 
++
  1 file changed, 48 insertions(+)

 Sorry, not going to happen. Read this for an explanation of why not:

 
https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html

 Thierry


Hi Thierry

The blog actually not persuade me why can't use display timing on
device tree.

Okay, perhaps read it again, it addresses most of your points below.


1, Binding panel as a simple string on device tree seems simple on device tree,
but it's complex on kernel code, and kernel code would became bigger and
bigger.

I don't think the video timings in the simple-panel driver are very
complex. They also don't use very much space. And if you're really
concerned about space you can always use conditional compilation and
Kconfig symbols to remove timings for panels that you don't use.

Also, panels are characterized by much more than just video timings.
There were attempts, way back, to fully describe panels in device tree
and that failed. What you propose here is a partial solution to a much
more complex problem.

This is all explained in the blog post.


2, Our customer always ask me, where is the display timing? They only find a
simple panel string on device tree,  need search the kernel code to find the
actually timing. They are used to find all device info on device tree, but
panel timing info is not, this would confuse them. They don't want to know how
code work, just want a easier interface.

That's not a very good argument. There's plenty of data that's not in
device tree for other devices, why should panels be different? Also, I
would hope that any customer of yours knows their way around kernel
code and can therefore easily add video timings for new panels. It's
quite trivial to do, and there are many examples on how to do it.


3, I think device tree not only can use for kernel, other module also can use
it. on our project, we use uboot + kernel, the uboot support fdt, that function
can parsing device tree. So if describe the display timing on device tree, both
uboot and kernel can share same display timing, not need to describe twice, it
would save work and not easy to make mistake.

That's a bit of a stretch. Video timings is fairly straightforward data
and can be easily added to any other piece of code that you want to run.
Yes you will have to duplicate the data, but how is that different from
duplicating all the driver code?


4, For differentiation product, we face many different panel, every once in a
while, need to add a new panel, we can't convert all the panel , code the panel
on kernel seems too bad, and the kernel image became bigger and bigger.

Why can't you convert all the panels? We already support a bunch of them
and haven't yet run into any problems. If you do encounter any issues
trying to port panels to the DRM panel infrastructure, please let me
know and I can help sort them out.

The kernel image size isn't a problem either. In any modern kernel the
video timing data in the panel driver is tiny compared to the rest.


Generally, Our customer don't want to do any modify on kernel, they just modify
device tree to bring up their device. Describe the panel timing on device tree,
would make customer easy to use and reuse it.

Yes, that would perhaps make it easier for them to bring up the device.
But soon after they'll notice that there are glitches when turning the
panel on and off, and then they'll realize that they can't fix that
using their simple device tree.
About the panel on and off, I don't think the panel-simple do the good 
enough.


panel-simple only have one gpio and one regulator, and their sequence is 
hard code, Why not a panel have two gpio or two regulator? On our 
project, we find many customer don't use the RC to do panel reset, they 
directly use gpio reset, so they need a gpio to do panel reset.


the device tree panel's on and off function is what the next step I want 
to upstream, on our downstream kernel, we do like that:


panel {
power_ctrl {
  power0 {
  gpios = ;
  delay,ms = <3>;
  }
  power1 {
  regulator = ;
  delay,ms = <3>;
  }
  power2 {
  backlight = ;
  delay,ms = <3>;
  }
}
}
and on driver, power on sequence with power0->power1->power2, power down 

Re: [PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel

[Mark yao]

On 2016年07月26日 17:02, Thierry Reding wrote:

On Tue, Jul 26, 2016 at 10:01:32AM +0800, Mark yao wrote:

On 2016年07月25日 23:21, Thierry Reding wrote:

 On Wed, Jul 20, 2016 at 11:18:50AM +0800, Mark Yao wrote:

 Allow user add display timing on device tree with simple-panel-dsi
 or simple-panel.

 Cc: Thierry Reding 
 Cc: Rob Herring 
 Cc: Mark Rutland 

 Signed-off-by: Mark Yao 
 ---
  .../bindings/display/panel/simple-panel.txt| 48 
++
  1 file changed, 48 insertions(+)

 Sorry, not going to happen. Read this for an explanation of why not:

 
https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html

 Thierry


Hi Thierry

The blog actually not persuade me why can't use display timing on
device tree.

Okay, perhaps read it again, it addresses most of your points below.


1, Binding panel as a simple string on device tree seems simple on device tree,
but it's complex on kernel code, and kernel code would became bigger and
bigger.

I don't think the video timings in the simple-panel driver are very
complex. They also don't use very much space. And if you're really
concerned about space you can always use conditional compilation and
Kconfig symbols to remove timings for panels that you don't use.

Also, panels are characterized by much more than just video timings.
There were attempts, way back, to fully describe panels in device tree
and that failed. What you propose here is a partial solution to a much
more complex problem.

This is all explained in the blog post.


2, Our customer always ask me, where is the display timing? They only find a
simple panel string on device tree,  need search the kernel code to find the
actually timing. They are used to find all device info on device tree, but
panel timing info is not, this would confuse them. They don't want to know how
code work, just want a easier interface.

That's not a very good argument. There's plenty of data that's not in
device tree for other devices, why should panels be different? Also, I
would hope that any customer of yours knows their way around kernel
code and can therefore easily add video timings for new panels. It's
quite trivial to do, and there are many examples on how to do it.


3, I think device tree not only can use for kernel, other module also can use
it. on our project, we use uboot + kernel, the uboot support fdt, that function
can parsing device tree. So if describe the display timing on device tree, both
uboot and kernel can share same display timing, not need to describe twice, it
would save work and not easy to make mistake.

That's a bit of a stretch. Video timings is fairly straightforward data
and can be easily added to any other piece of code that you want to run.
Yes you will have to duplicate the data, but how is that different from
duplicating all the driver code?


4, For differentiation product, we face many different panel, every once in a
while, need to add a new panel, we can't convert all the panel , code the panel
on kernel seems too bad, and the kernel image became bigger and bigger.

Why can't you convert all the panels? We already support a bunch of them
and haven't yet run into any problems. If you do encounter any issues
trying to port panels to the DRM panel infrastructure, please let me
know and I can help sort them out.

The kernel image size isn't a problem either. In any modern kernel the
video timing data in the panel driver is tiny compared to the rest.


Generally, Our customer don't want to do any modify on kernel, they just modify
device tree to bring up their device. Describe the panel timing on device tree,
would make customer easy to use and reuse it.

Yes, that would perhaps make it easier for them to bring up the device.
But soon after they'll notice that there are glitches when turning the
panel on and off, and then they'll realize that they can't fix that
using their simple device tree.
About the panel on and off, I don't think the panel-simple do the good 
enough.


panel-simple only have one gpio and one regulator, and their sequence is 
hard code, Why not a panel have two gpio or two regulator? On our 
project, we find many customer don't use the RC to do panel reset, they 
directly use gpio reset, so they need a gpio to do panel reset.


the device tree panel's on and off function is what the next step I want 
to upstream, on our downstream kernel, we do like that:


panel {
power_ctrl {
  power0 {
  gpios = ;
  delay,ms = <3>;
  }
  power1 {
  regulator = ;
  delay,ms = <3>;
  }
  power2 {
  backlight = ;
  delay,ms = <3>;
  }
}
}
and on driver, power on sequence with power0->power1->power2, power down 
with power2->power1->power0.
if user want to swap the power, can easy do that by  adjust dts 

STRICTLY CONFIDENTIAL .

[Acct. Dept. Bank Of China]

I have important transaction for you as next of kin to claim US$8.37m  Mail me 
on my private email: chi...@yahoo.com   so i can send you more details

Thanks

Mr.Chim Wai Kim










===

DISCLAIMER: This email and any files it contains are confidential and intended 
for the use of the recipient(s) only. If you are not the intended recipient you 
should notify the sender immediately and destroy the material from your system. 
Unauthorised use, disclosure, copying, distribution or any action taken or 
omitted to be taken in reliance on the information in this e-mail is prohibited 
and may be unlawful..And might be punishable under 
section 67B of the IT Act (2008

STRICTLY CONFIDENTIAL .

[Acct. Dept. Bank Of China]

I have important transaction for you as next of kin to claim US$8.37m  Mail me 
on my private email: chi...@yahoo.com   so i can send you more details

Thanks

Mr.Chim Wai Kim










===

DISCLAIMER: This email and any files it contains are confidential and intended 
for the use of the recipient(s) only. If you are not the intended recipient you 
should notify the sender immediately and destroy the material from your system. 
Unauthorised use, disclosure, copying, distribution or any action taken or 
omitted to be taken in reliance on the information in this e-mail is prohibited 
and may be unlawful..And might be punishable under 
section 67B of the IT Act (2008

linux-next: manual merge of the net-next tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

between commit:

  cafc4cd0c8b8 ("arm64: dts: apm: Use lowercase consistently for hex constants")

from the arm-soc tree and commit:

  8e694cd2762c ("dtb: xgene: Add MDIO node")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 21028b145d91,2e1e5daa1dc7..
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@@ -628,9 -636,9 +636,9 @@@
sgenet0: ethernet@1f61 {
compatible = "apm,xgene2-sgenet";
status = "disabled";
-   reg = <0x0 0x1f61 0x0 0x1>,
+   reg = <0x0 0x1f61 0x0 0xd100>,
 -<0x0 0x1f60 0x0 0Xd100>,
 -<0x0 0x2000 0x0 0X2>;
 +<0x0 0x1f60 0x0 0xd100>,
 +<0x0 0x2000 0x0 0x2>;
interrupts = <0 96 4>,
 <0 97 4>;
dma-coherent;

linux-next: manual merge of the net-next tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

between commit:

  cafc4cd0c8b8 ("arm64: dts: apm: Use lowercase consistently for hex constants")

from the arm-soc tree and commit:

  8e694cd2762c ("dtb: xgene: Add MDIO node")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 21028b145d91,2e1e5daa1dc7..
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@@ -628,9 -636,9 +636,9 @@@
sgenet0: ethernet@1f61 {
compatible = "apm,xgene2-sgenet";
status = "disabled";
-   reg = <0x0 0x1f61 0x0 0x1>,
+   reg = <0x0 0x1f61 0x0 0xd100>,
 -<0x0 0x1f60 0x0 0Xd100>,
 -<0x0 0x2000 0x0 0X2>;
 +<0x0 0x1f60 0x0 0xd100>,
 +<0x0 0x2000 0x0 0x2>;
interrupts = <0 96 4>,
 <0 97 4>;
dma-coherent;