[PATCH v2 1/2] auxdisplay: Move panel.c to drivers/auxdisplay folder

It looks like panel.c belongs to auxdisplay subsystem. Move it to drivers/auxdisplay folder. No functional changes intended. Acked-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko --- drivers/auxdisplay/Kconfig | 280

[PATCH v2 1/2] auxdisplay: Move panel.c to drivers/auxdisplay folder

It looks like panel.c belongs to auxdisplay subsystem. Move it to drivers/auxdisplay folder. No functional changes intended. Acked-by: Geert Uytterhoeven Signed-off-by: Andy Shevchenko --- drivers/auxdisplay/Kconfig | 280 +++

X86 4.8 kernel boot questions

Hi All, The production board I'm using doesn't have a JTAG available, upgrading to 4.8 from 4.1,.and need to understand why Linux 4.8.3 doesn't boot on a x86_64 corei7-64. Boots with no issues with 4.1. Hangs at the last message of u-boot, the typical "Starting kernel." The bootcmd and arguments

Re: [RFC 4/8] p2pmem: Add debugfs "stats" file

On 04/04/17 04:46 AM, Sagi Grimberg wrote: > >> +p2pmem_debugfs_root = debugfs_create_dir("p2pmem", NULL); >> +if (!p2pmem_debugfs_root) >> +pr_info("could not create debugfs entry, continuing\n"); >> + > > Why continue? I think it'd be better to just fail it. Yup, agreed.

X86 4.8 kernel boot questions

Hi All, The production board I'm using doesn't have a JTAG available, upgrading to 4.8 from 4.1,.and need to understand why Linux 4.8.3 doesn't boot on a x86_64 corei7-64. Boots with no issues with 4.1. Hangs at the last message of u-boot, the typical "Starting kernel." The bootcmd and arguments

Re: [RFC 4/8] p2pmem: Add debugfs "stats" file

On 04/04/17 04:46 AM, Sagi Grimberg wrote: > >> +p2pmem_debugfs_root = debugfs_create_dir("p2pmem", NULL); >> +if (!p2pmem_debugfs_root) >> +pr_info("could not create debugfs entry, continuing\n"); >> + > > Why continue? I think it'd be better to just fail it. Yup, agreed.

[PATCH v2 2/2] auxdisplay: Move arm-charlcd.c to drivers/auxdisplay folder

It looks like arm-charlcd.c belongs to auxdisplay subsystem. Move it to drivers/auxdisplay folder. No functional changes intended. Reviewed-by: Linus Walleij Signed-off-by: Andy Shevchenko --- drivers/auxdisplay/Kconfig

[PATCH v2 2/2] auxdisplay: Move arm-charlcd.c to drivers/auxdisplay folder

It looks like arm-charlcd.c belongs to auxdisplay subsystem. Move it to drivers/auxdisplay folder. No functional changes intended. Reviewed-by: Linus Walleij Signed-off-by: Andy Shevchenko --- drivers/auxdisplay/Kconfig | 10 ++ drivers/auxdisplay/Makefile

[PATCH v2 2/2] x86/mce/AMD: Carve out SMCA bank configuration

From: Yazen Ghannam Scalable MCA systems have a new MCA_CONFIG register that we use to configure each bank. We currently use this when we set up thresholding. However, this is logically separate. Group all SMCA-related initialization into a single, separate function. This

[PATCH v2 2/2] x86/mce/AMD: Carve out SMCA bank configuration

From: Yazen Ghannam Scalable MCA systems have a new MCA_CONFIG register that we use to configure each bank. We currently use this when we set up thresholding. However, this is logically separate. Group all SMCA-related initialization into a single, separate function. This includes setting

[PATCH v2 1/2] x86/mce/AMD: Redo use of SMCA MCA_DE{STAT,ADDR} registers

From: Yazen Ghannam We have support for the new SMCA MCA_DE{STAT,ADDR} registers in Linux. So we've used these registers in place of MCA_{STATUS,ADDR} on SMCA systems. However, the guidance for current implementations of SMCA is to continue using MCA_{STATUS,ADDR} and to

[PATCH v2 1/2] x86/mce/AMD: Redo use of SMCA MCA_DE{STAT,ADDR} registers

From: Yazen Ghannam We have support for the new SMCA MCA_DE{STAT,ADDR} registers in Linux. So we've used these registers in place of MCA_{STATUS,ADDR} on SMCA systems. However, the guidance for current implementations of SMCA is to continue using MCA_{STATUS,ADDR} and to use MCA_DE{STAT,ADDR}

[PATCH v3 03/18] arm64: Define Cortex-A73 MIDR

As we're about to introduce a new workaround that is specific to Cortex-A73, let's define the coresponding MIDR. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH v3 03/18] arm64: Define Cortex-A73 MIDR

As we're about to introduce a new workaround that is specific to Cortex-A73, let's define the coresponding MIDR. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h

[PATCH v3 01/18] arm64: Allow checking of a CPU-local erratum

this_cpu_has_cap() only checks the feature array, and not the errata one. In order to be able to check for a CPU-local erratum, allow it to inspect the latter as well. This is consistent with cpus_have_cap()'s behaviour, which includes errata already. Acked-by: Daniel Lezcano

[PATCH v3 01/18] arm64: Allow checking of a CPU-local erratum

this_cpu_has_cap() only checks the feature array, and not the errata one. In order to be able to check for a CPU-local erratum, allow it to inspect the latter as well. This is consistent with cpus_have_cap()'s behaviour, which includes errata already. Acked-by: Daniel Lezcano Reviewed-by:

[PATCH v3 07/18] arm64: arch_timer: Add erratum handler for CPU-specific capability

Should we ever have a workaround for an erratum that is detected using a capability and affecting a particular CPU, it'd be nice to have a way to probe them directly. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/arch_timer.h | 1 +

[PATCH v3 07/18] arm64: arch_timer: Add erratum handler for CPU-specific capability

Should we ever have a workaround for an erratum that is detected using a capability and affecting a particular CPU, it'd be nice to have a way to probe them directly. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/arch_timer.h | 1 + drivers/clocksource/arm_arch_timer.c | 28

[PATCH v3 11/18] arm64: arch_timer: Make workaround methods optional

Not all errata need to workaround all access types. Allow them to be optional. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/arch_timer.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/arch_timer.h

[PATCH v3 09/18] arm64: arch_timer: Get rid of erratum_workaround_set_sne

Let's move the handling of workarounds affecting set_next_event to the affected function, instead of overriding the pointers as an afterthough. Yes, this is an extra indirection on the erratum handling path, but the HW is busted anyway. This will allow for some more flexibility later.

[PATCH v3 11/18] arm64: arch_timer: Make workaround methods optional

Not all errata need to workaround all access types. Allow them to be optional. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/arch_timer.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h

[PATCH v3 09/18] arm64: arch_timer: Get rid of erratum_workaround_set_sne

Let's move the handling of workarounds affecting set_next_event to the affected function, instead of overriding the pointers as an afterthough. Yes, this is an extra indirection on the erratum handling path, but the HW is busted anyway. This will allow for some more flexibility later.

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

On 04/04/17 04:59 AM, Sagi Grimberg wrote: > We can never ever get here from an IO command, and that is a good thing > because it would have been broken if we did, regardless of what copy > method we use... Yes, I changed this mostly for admin commands. I did notice connect commands do end up

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

On 04/04/17 04:59 AM, Sagi Grimberg wrote: > We can never ever get here from an IO command, and that is a good thing > because it would have been broken if we did, regardless of what copy > method we use... Yes, I changed this mostly for admin commands. I did notice connect commands do end up

[PATCH v3 10/18] arm64: arch_timer: Rework the set_next_event workarounds

The way we work around errata affecting set_next_event is not very nice, at it imposes this workaround on errata that do not need it. Add new workaround hooks and let the existing workarounds use them. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/arch_timer.h |

[PATCH v3 10/18] arm64: arch_timer: Rework the set_next_event workarounds

The way we work around errata affecting set_next_event is not very nice, at it imposes this workaround on errata that do not need it. Add new workaround hooks and let the existing workarounds use them. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/arch_timer.h | 4

[PATCH v3 13/18] arm64: arch_timer: Move clocksource_counter and co around

In order to access clocksource_counter from the errata handling code, move it (together with the related structures and functions) towards the top of the file. Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 62 ++-- 1

[PATCH v3 13/18] arm64: arch_timer: Move clocksource_counter and co around

In order to access clocksource_counter from the errata handling code, move it (together with the related structures and functions) towards the top of the file. Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 62 ++-- 1 file changed, 31

[PATCH v3 08/18] arm64: arch_timer: Move arch_timer_reg_read/write around

As we're about to move things around, let's start with the low level read/write functions. This allows us to use these functions in the errata handling code without having to use forward declaration of static functions. Acked-by: Mark Rutland Acked-by: Daniel Lezcano

[PATCH v3 08/18] arm64: arch_timer: Move arch_timer_reg_read/write around

As we're about to move things around, let's start with the low level read/write functions. This allows us to use these functions in the errata handling code without having to use forward declaration of static functions. Acked-by: Mark Rutland Acked-by: Daniel Lezcano Signed-off-by: Marc Zyngier

Re: [PATCH v4 04/11] VAS: Define vas_init() and vas_exit()

Sukadev Bhattiprolu [sukadevatlinux.vnet.ibm.com] wrote: > Implement vas_init() and vas_exit() functions for a new VAS module. > This VAS module is essentially a library for other device drivers > and kernel users of the NX coprocessors like NX-842 and NX-GZIP. > In the future this will be

Re: [PATCH v4 04/11] VAS: Define vas_init() and vas_exit()

Sukadev Bhattiprolu [sukadevatlinux.vnet.ibm.com] wrote: > Implement vas_init() and vas_exit() functions for a new VAS module. > This VAS module is essentially a library for other device drivers > and kernel users of the NX coprocessors like NX-842 and NX-GZIP. > In the future this will be

[PATCH v3 14/18] arm64: arch_timer: Save cntkctl_el1 as a per-cpu variable

As we're about to allow per CPU cntkctl_el1 configuration, we cannot rely on the register value to be common when performing power management. Let's turn saved_cntkctl into a per-cpu variable. Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 6 +++---

[PATCH v3 16/18] arm64: arch_timer: Workaround for Cortex-A73 erratum 858921

Cortex-A73 (all versions) counter read can return a wrong value when the counter crosses a 32bit boundary. The workaround involves performing the read twice, and to return one or the other depending on whether a transition has taken place. Signed-off-by: Marc Zyngier ---

[PATCH v3 14/18] arm64: arch_timer: Save cntkctl_el1 as a per-cpu variable

As we're about to allow per CPU cntkctl_el1 configuration, we cannot rely on the register value to be common when performing power management. Let's turn saved_cntkctl into a per-cpu variable. Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 6 +++--- 1 file changed, 3

[PATCH v3 16/18] arm64: arch_timer: Workaround for Cortex-A73 erratum 858921

Cortex-A73 (all versions) counter read can return a wrong value when the counter crosses a 32bit boundary. The workaround involves performing the read twice, and to return one or the other depending on whether a transition has taken place. Signed-off-by: Marc Zyngier ---

[PATCH] ASoC: max9867: export OF device ID as module aliases

The I2C core always reports a MODALIAS of the form i2c: even if the device was registered via OF, this means that exporting the OF device ID table device aliases in the module is not needed. But in order to change how the core reports modaliases to user-space, it's better to export it. While

[PATCH] ASoC: max9867: export OF device ID as module aliases

The I2C core always reports a MODALIAS of the form i2c: even if the device was registered via OF, this means that exporting the OF device ID table device aliases in the module is not needed. But in order to change how the core reports modaliases to user-space, it's better to export it. While

[PATCH v3 18/18] arm64: arch_timer: Add HISILICON_ERRATUM_161010101 ACPI matching data

In order to deal with ACPI enabled platforms suffering from the HISILICON_ERRATUM_161010101, let's add the required OEM data that allow the workaround to be enabled. Tested-by: dann frazier Tested-by: Hanjun Guo Reviewed-by: Hanjun Guo

[PATCH v3 18/18] arm64: arch_timer: Add HISILICON_ERRATUM_161010101 ACPI matching data

In order to deal with ACPI enabled platforms suffering from the HISILICON_ERRATUM_161010101, let's add the required OEM data that allow the workaround to be enabled. Tested-by: dann frazier Tested-by: Hanjun Guo Reviewed-by: Hanjun Guo Signed-off-by: Marc Zyngier ---

[PATCH v3 15/18] arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled

Userspace being allowed to use read CNTVCT_EL0 anytime (and not only in the VDSO), we need to enable trapping whenever a cntvct workaround is enabled on a given CPU. Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 45

[PATCH v3 15/18] arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled

Userspace being allowed to use read CNTVCT_EL0 anytime (and not only in the VDSO), we need to enable trapping whenever a cntvct workaround is enabled on a given CPU. Signed-off-by: Marc Zyngier --- drivers/clocksource/arm_arch_timer.c | 45 +--- 1 file changed,

Re: [PATCH 2/2] ACPI / CPPC: Make cppc acpi driver aware of pcc subspace ids

On Tue, 4 Apr 2017 16:21:20 +0530 George Cherian wrote: > > Hi Alexey, > > On 04/03/2017 11:07 PM, Alexey Klimov wrote: > > (adding Prashanth to c/c) > > > > Hi George, > > > > On Fri, Mar 31, 2017 at 06:24:02AM +, George Cherian wrote: > >> Based on Section

Re: [PATCH 2/2] ACPI / CPPC: Make cppc acpi driver aware of pcc subspace ids

On Tue, 4 Apr 2017 16:21:20 +0530 George Cherian wrote: > > Hi Alexey, > > On 04/03/2017 11:07 PM, Alexey Klimov wrote: > > (adding Prashanth to c/c) > > > > Hi George, > > > > On Fri, Mar 31, 2017 at 06:24:02AM +, George Cherian wrote: > >> Based on Section 14.1 of ACPI specification, it

[PATCH v3 06/18] arm64: arch_timer: Add infrastructure for multiple erratum detection methods

We're currently stuck with DT when it comes to handling errata, which is pretty restrictive. In order to make things more flexible, let's introduce an infrastructure that could support alternative discovery methods. No change in functionality. Reviewed-by: Hanjun Guo

[PATCH v3 17/18] arm64: arch_timer: Allow erratum matching with ACPI OEM information

Just as we're able to identify a broken platform using some DT information, let's enable a way to spot the offenders with ACPI. The difference is that we can only match on some OEM info instead of implementation-specific properties. So in order to avoid the insane multiplication of errata

[PATCH v3 02/18] arm64: Add CNTVCT_EL0 trap handler

Since people seem to make a point in breaking the userspace visible counter, we have no choice but to trap the access. Add the required handler. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/esr.h | 2 ++

[PATCH v3 12/18] arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUs

Instead of applying a CPU-specific workaround to all CPUs in the system, allow it to only affect a subset of them (typical big-little case). This is done by turning the erratum pointer into a per-CPU variable. Signed-off-by: Marc Zyngier ---

[PATCH v3 06/18] arm64: arch_timer: Add infrastructure for multiple erratum detection methods

We're currently stuck with DT when it comes to handling errata, which is pretty restrictive. In order to make things more flexible, let's introduce an infrastructure that could support alternative discovery methods. No change in functionality. Reviewed-by: Hanjun Guo Signed-off-by: Marc Zyngier

[PATCH v3 17/18] arm64: arch_timer: Allow erratum matching with ACPI OEM information

Just as we're able to identify a broken platform using some DT information, let's enable a way to spot the offenders with ACPI. The difference is that we can only match on some OEM info instead of implementation-specific properties. So in order to avoid the insane multiplication of errata

[PATCH v3 02/18] arm64: Add CNTVCT_EL0 trap handler

Since people seem to make a point in breaking the userspace visible counter, we have no choice but to trap the access. Add the required handler. Acked-by: Mark Rutland Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/esr.h | 2 ++ arch/arm64/kernel/traps.c| 14 ++ 2

[PATCH v3 12/18] arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUs

Instead of applying a CPU-specific workaround to all CPUs in the system, allow it to only affect a subset of them (typical big-little case). This is done by turning the erratum pointer into a per-CPU variable. Signed-off-by: Marc Zyngier --- arch/arm64/include/asm/arch_timer.h | 31

[PATCH v3 00/18] clocksource/arch_timer: Errata workaround infrastructure rework

It has recently become obvious that a number of arm64 systems have been blessed with a set of timers that are slightly less than perfect, and require a bit of hand-holding. We already have a bunch of errata-specific code to deal with this, but as we're adding more potential detection methods (DT,

[PATCH v3 00/18] clocksource/arch_timer: Errata workaround infrastructure rework

It has recently become obvious that a number of arm64 systems have been blessed with a set of timers that are slightly less than perfect, and require a bit of hand-holding. We already have a bunch of errata-specific code to deal with this, but as we're adding more potential detection methods (DT,

[PATCH v3 05/18] arm64: cpu_errata: Add capability to advertise Cortex-A73 erratum 858921

In order to work around Cortex-A73 erratum 858921 in a subsequent patch, add the required capability that advertise the erratum. As the configuration option it depends on is not present yet, this has no immediate effect. Acked-by: Daniel Lezcano Signed-off-by: Marc

[PATCH v3 05/18] arm64: cpu_errata: Add capability to advertise Cortex-A73 erratum 858921

In order to work around Cortex-A73 erratum 858921 in a subsequent patch, add the required capability that advertise the erratum. As the configuration option it depends on is not present yet, this has no immediate effect. Acked-by: Daniel Lezcano Signed-off-by: Marc Zyngier ---

[PATCH v3 04/18] arm64: cpu_errata: Allow an erratum to be match for all revisions of a core

Some minor erratum may not be fixed in further revisions of a core, leading to a situation where the workaround needs to be updated each time an updated core is released. Introduce a MIDR_ALL_VERSIONS match helper that will work for all versions of that MIDR, once and for all. Acked-by: Mark

[PATCH v3 04/18] arm64: cpu_errata: Allow an erratum to be match for all revisions of a core

Some minor erratum may not be fixed in further revisions of a core, leading to a situation where the workaround needs to be updated each time an updated core is released. Introduce a MIDR_ALL_VERSIONS match helper that will work for all versions of that MIDR, once and for all. Acked-by: Mark

Re: [PATCH v4 02/11] VAS: Define macros, register fields and structures

Sukadev Bhattiprolu [sukadevatlinux.vnet.ibm.com] wrote: > Define macros for the VAS hardware registers and bit-fields as well > as couple of data structures needed by the VAS driver. > > Signed-off-by: Sukadev Bhattiprolu > +++ b/arch/powerpc/platforms/powernv/vas.h > @@ -0,0 +1,387 @@ > +/*

Re: [PATCH v4 02/11] VAS: Define macros, register fields and structures

Sukadev Bhattiprolu [sukadevatlinux.vnet.ibm.com] wrote: > Define macros for the VAS hardware registers and bit-fields as well > as couple of data structures needed by the VAS driver. > > Signed-off-by: Sukadev Bhattiprolu > +++ b/arch/powerpc/platforms/powernv/vas.h > @@ -0,0 +1,387 @@ > +/*

Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot

On Tue, Apr 04, 2017 at 06:29:06PM +0200, Paul Menzel wrote: > Unfortunately, there seems to have been a regression between Linux 3.16 > and 4.8 and 4.9, so that the Linux kernel doesn’t create the TPM > device. That old kernel did not check error codes when reading burst count, the new one

Re: [tpmdd-devel] Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot

On Tue, Apr 04, 2017 at 06:29:06PM +0200, Paul Menzel wrote: > Unfortunately, there seems to have been a regression between Linux 3.16 > and 4.8 and 4.9, so that the Linux kernel doesn’t create the TPM > device. That old kernel did not check error codes when reading burst count, the new one

Re: [PATCH 1/2] platform/x86: silead_dmi - do not treat all devices as i2c_clients

On Tue, Apr 04, 2017 at 07:33:30PM +0300, Andy Shevchenko wrote: > On Tue, Apr 4, 2017 at 7:31 PM, Darren Hart wrote: > > On Tue, Apr 04, 2017 at 07:08:28PM +0300, Andy Shevchenko wrote: > >> On Tue, Apr 4, 2017 at 7:05 PM, Darren Hart wrote: > >> > On

Re: [PATCH 1/2] platform/x86: silead_dmi - do not treat all devices as i2c_clients

On Tue, Apr 04, 2017 at 07:33:30PM +0300, Andy Shevchenko wrote: > On Tue, Apr 4, 2017 at 7:31 PM, Darren Hart wrote: > > On Tue, Apr 04, 2017 at 07:08:28PM +0300, Andy Shevchenko wrote: > >> On Tue, Apr 4, 2017 at 7:05 PM, Darren Hart wrote: > >> > On Tue, Apr 04, 2017 at 04:45:05PM +0300, Andy

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Tue, Apr 04, 2017 at 12:25:46PM -0400, Jeff Layton wrote: > That said, I think giving more specific errors where we can is useful. > When your program is erroring out and writing 'I/O error' to the logs, > then how much time will your admins burn before they figure out that it > really failed

Re: [RFC PATCH 0/4] fs: introduce new writeback error tracking infrastructure and convert ext4 to use it

On Tue, Apr 04, 2017 at 12:25:46PM -0400, Jeff Layton wrote: > That said, I think giving more specific errors where we can is useful. > When your program is erroring out and writing 'I/O error' to the logs, > then how much time will your admins burn before they figure out that it > really failed

Re: [PATCH 1/2] Alps HID I2C T4 device support

Hi Masaki, Yes, I think I have a 044E:120C. Is there a way to find out for sure? It's not listed by e.g. lspci. The touchpad is definitely not reacting to anything. evemu-record does not show any events either. I have attached the dmesg output. Best, -Nikolaus On Apr 04 2017, Masaki Ota

Re: [PATCH 1/2] Alps HID I2C T4 device support

Hi Masaki, Yes, I think I have a 044E:120C. Is there a way to find out for sure? It's not listed by e.g. lspci. The touchpad is definitely not reacting to anything. evemu-record does not show any events either. I have attached the dmesg output. Best, -Nikolaus On Apr 04 2017, Masaki Ota

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi wrote: > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote: > Yes, in a previous project, I had been working toward getting a < 1M > system to boot on Galileo hardware (which it did, but using more than > that - the

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi wrote: > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote: > Yes, in a previous project, I had been working toward getting a < 1M > system to boot on Galileo hardware (which it did, but using more than > that - the Galileo2 has 256MB, but it

Re: [PATCH] input: touchscreen: sur40: fix bad endianness handling in sur40_poll

On Tue, Apr 04, 2017 at 03:06:17PM +0200, Martin Kepplinger wrote: > sparse says: > > sur40.c:372:40: warning: restricted __le32 degrades to integer > > the header's data is __le32 so we need to convert it before comparing. > > Signed-off-by: Martin Kepplinger Applied,

Re: [PATCH] input: touchscreen: sur40: fix bad endianness handling in sur40_poll

On Tue, Apr 04, 2017 at 03:06:17PM +0200, Martin Kepplinger wrote: > sparse says: > > sur40.c:372:40: warning: restricted __le32 degrades to integer > > the header's data is __le32 so we need to convert it before comparing. > > Signed-off-by: Martin Kepplinger Applied, thank you. > --- >

[PATCH v2 2/4] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

If the cpufreq driver tries to modify voltage/freq during suspend/resume it might need to control an external PMIC via I2C or SPI but those devices might be already suspended. This issue is likely to happen whenever the LDOs have their vin-supply set. To avoid this scenario we just increase

[PATCH v2 2/4] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

If the cpufreq driver tries to modify voltage/freq during suspend/resume it might need to control an external PMIC via I2C or SPI but those devices might be already suspended. This issue is likely to happen whenever the LDOs have their vin-supply set. To avoid this scenario we just increase

[PATCH v2 3/4] ARM: dts: imx6qdl-sabresd: Set LDO regulator supply

Setting the supply is optional but beneficial, it will cause PMIC voltages to be dynamically changed with cpu frequency. Signed-off-by: Leonard Crestez Reviewed-by: Lucas Stach --- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 12 1 file

[PATCH v2 3/4] ARM: dts: imx6qdl-sabresd: Set LDO regulator supply

Setting the supply is optional but beneficial, it will cause PMIC voltages to be dynamically changed with cpu frequency. Signed-off-by: Leonard Crestez Reviewed-by: Lucas Stach --- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 12 1 file changed, 12 insertions(+) diff --git

Re: [PATCH 3/5] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

On Tue, 2017-04-04 at 11:51 +0200, Lucas Stach wrote: > Am Freitag, den 31.03.2017, 22:25 +0300 schrieb Leonard Crestez: > > > > If the cpufreq driver tries to modify voltage/freq during suspend/resume > > it might need to control an external PMIC via I2C or SPI but those > > devices might be

Re: [PATCH 3/5] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

On Tue, 2017-04-04 at 11:51 +0200, Lucas Stach wrote: > Am Freitag, den 31.03.2017, 22:25 +0300 schrieb Leonard Crestez: > > > > If the cpufreq driver tries to modify voltage/freq during suspend/resume > > it might need to control an external PMIC via I2C or SPI but those > > devices might be

Re: [PATCH] bnx2x: fix spelling mistake in macros HW_INTERRUT_ASSERT_SET_*

From: Colin King Date: Mon, 3 Apr 2017 11:19:10 +0100 > From: Colin Ian King > > Trival fix, rename HW_INTERRUT_ASSERT_SET_* to HW_INTERRUPT_ASSERT_SET_* > > Signed-off-by: Colin Ian King Applied.

Re: [PATCH] bnx2x: fix spelling mistake in macros HW_INTERRUT_ASSERT_SET_*

From: Colin King Date: Mon, 3 Apr 2017 11:19:10 +0100 > From: Colin Ian King > > Trival fix, rename HW_INTERRUT_ASSERT_SET_* to HW_INTERRUPT_ASSERT_SET_* > > Signed-off-by: Colin Ian King Applied.

[PATCH v2 4/4] ARM: dts: imx6qp-sabresd: Set reg_arm regulator supply

On imx6qp-sabresd LDO_ARM is connected to a different PMIC output than the other imx6qdl-sabresd boards. Setting cpu0 arm-supply to sw2_reg is wrong, this must have mistakenly slipped out of the vendor tree where this is are used for LDO bypass. Signed-off-by: Leonard Crestez

[PATCH v2 1/4] cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator

From: Irina Tirdea If there are any errors in getting the cpu0 regulators, the driver returns -ENOENT. In case the regulators are not yet available, the devm_regulator_get calls will return -EPROBE_DEFER, so that the driver can be probed later. If we return -ENOENT, the

[PATCH v2 0/4] ARM: imx: Set LDO regulator supply

Setting the LDO regulator parent is optional but beneficial. It will cause the PMIC output voltage to be dynamically set to the minimum input for the LDOs, this should be more efficient. This propagation was introduced by: commit fc42112c0eaa ("regulator: core: Propagate voltage changes to supply

[PATCH v2 4/4] ARM: dts: imx6qp-sabresd: Set reg_arm regulator supply

On imx6qp-sabresd LDO_ARM is connected to a different PMIC output than the other imx6qdl-sabresd boards. Setting cpu0 arm-supply to sw2_reg is wrong, this must have mistakenly slipped out of the vendor tree where this is are used for LDO bypass. Signed-off-by: Leonard Crestez Reviewed-by: Lucas

[PATCH v2 1/4] cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator

From: Irina Tirdea If there are any errors in getting the cpu0 regulators, the driver returns -ENOENT. In case the regulators are not yet available, the devm_regulator_get calls will return -EPROBE_DEFER, so that the driver can be probed later. If we return -ENOENT, the driver will fail its

[PATCH v2 0/4] ARM: imx: Set LDO regulator supply

Setting the LDO regulator parent is optional but beneficial. It will cause the PMIC output voltage to be dynamically set to the minimum input for the LDOs, this should be more efficient. This propagation was introduced by: commit fc42112c0eaa ("regulator: core: Propagate voltage changes to supply

Re: [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings

Hello Rob, On 04/04/2017 12:54 PM, Rob Herring wrote: > On Tue, Apr 4, 2017 at 10:30 AM, Javier Martinez Canillas > wrote: >> There are Device Tree source files defining a device node for the >> retu/tahvo I2C chip, but there isn't a DT binding document for it. >> >>

Re: [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings

Hello Rob, On 04/04/2017 12:54 PM, Rob Herring wrote: > On Tue, Apr 4, 2017 at 10:30 AM, Javier Martinez Canillas > wrote: >> There are Device Tree source files defining a device node for the >> retu/tahvo I2C chip, but there isn't a DT binding document for it. >> >> Signed-off-by: Javier

Re: [PATCH v5 2/3] gpio: wm831x: Add basic device tree support

On Thu, Mar 23, 2017 at 1:47 PM, Lee Jones wrote: > On Fri, 17 Mar 2017, Charles Keepax wrote: > >> Now the wm831x-core has basic DT support we can update this driver to >> allow use of the GPIOs within a device tree system. >> >> Signed-off-by: Charles Keepax

Re: [PATCH v5 2/3] gpio: wm831x: Add basic device tree support

On Thu, Mar 23, 2017 at 1:47 PM, Lee Jones wrote: > On Fri, 17 Mar 2017, Charles Keepax wrote: > >> Now the wm831x-core has basic DT support we can update this driver to >> allow use of the GPIOs within a device tree system. >> >> Signed-off-by: Charles Keepax >> Acked-by: Linus Walleij >> ---

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

Hi, On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote: > +Cc: Tom > > Summon Tom to the discussion. He tried once hard to shrink a Linux > kernel to something working in 1M+ RAM on x86. > Yes, in a previous project, I had been working toward getting a < 1M system to boot on Galileo

Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

Hi, On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote: > +Cc: Tom > > Summon Tom to the discussion. He tried once hard to shrink a Linux > kernel to something working in 1M+ RAM on x86. > Yes, in a previous project, I had been working toward getting a < 1M system to boot on Galileo

Re: [PATCH] watchdog: core: Make use of devm_register_reboot_notifier()

On Tue, Apr 4, 2017 at 7:51 PM, Guenter Roeck wrote: > On 04/04/2017 08:47 AM, Andy Shevchenko wrote: >> On Tue, Apr 4, 2017 at 5:10 PM, Andrey Smirnov >> wrote: >>> + ret = devm_register_reboot_notifier(wdd->parent, >>> +

Re: [PATCH] watchdog: core: Make use of devm_register_reboot_notifier()

On Tue, Apr 4, 2017 at 7:51 PM, Guenter Roeck wrote: > On 04/04/2017 08:47 AM, Andy Shevchenko wrote: >> On Tue, Apr 4, 2017 at 5:10 PM, Andrey Smirnov >> wrote: >>> + ret = devm_register_reboot_notifier(wdd->parent, >>> +

Re: [PATCH] x86/signals: Fix lower/upper bound reporting in compat siginfo

On 04/04/2017 09:15 AM, Joerg Roedel wrote: > Put the right values from the original siginfo into the > userspace compat-siginfo. > > This fixes the 32-bit mpx tabletest on a 64-bit kernel. Ugh, thanks for finding that. Acked-by: Dave Hansen

Re: [PATCH] x86/signals: Fix lower/upper bound reporting in compat siginfo

On 04/04/2017 09:15 AM, Joerg Roedel wrote: > Put the right values from the original siginfo into the > userspace compat-siginfo. > > This fixes the 32-bit mpx tabletest on a 64-bit kernel. Ugh, thanks for finding that. Acked-by: Dave Hansen

Re: [PATCH v4 0/8] mfd: Add OF device table to I2C drivers that are missing it

On Tue, Apr 4, 2017 at 10:30 AM, Javier Martinez Canillas wrote: > Hello, > > This series add OF device ID tables to mfd I2C drivers whose devices are > either used in Device Tree source files or are listed in binding docs as > a compatible string. For the series,

Re: [PATCH v4 0/8] mfd: Add OF device table to I2C drivers that are missing it

On Tue, Apr 4, 2017 at 10:30 AM, Javier Martinez Canillas wrote: > Hello, > > This series add OF device ID tables to mfd I2C drivers whose devices are > either used in Device Tree source files or are listed in binding docs as > a compatible string. For the series, Acked-by: Rob Herring

Re: [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings

On Tue, Apr 4, 2017 at 10:30 AM, Javier Martinez Canillas wrote: > There are Device Tree source files defining a device node for the > retu/tahvo I2C chip, but there isn't a DT binding document for it. > > Signed-off-by: Javier Martinez Canillas >

Re: [PATCH v3 1/4] ARM: dts: sun4i: Add CAN node

Am 04.04.2017 um 17:40 schrieb Maxime Ripard: > On Mon, Apr 03, 2017 at 07:00:11PM +0200, Patrick Menschel wrote: >> The A10 SoC has an on-board CAN controller. >> This patch adds the device node. >> >> This patch is adapted from the description in >>

<    3   4   5   6   7   8   9   10   11   12   >