[PATCH V8 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3 structure. The timestamp of when the firmware generated the error is now being reported. Signed-off-by: Tyler Baicar Signed-off-by:

[PATCH V8 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3 structure. The timestamp of when the firmware generated the error is now being reported. Signed-off-by: Tyler Baicar Signed-off-by: Jonathan (Zhixiong)

Re: [PATCH] remoteproc: qcom: fix initializers for qcom_mss_reg_res array

On Wed 01 Feb 08:56 PST 2017, Arnd Bergmann wrote: > The recently added initialization is rather unusual because it uses a > constructor for > a variable-length array to assign a constant structure to a member that uses > a fixed-length > array. This confuses clang and breaks the build. > >

Re: [PATCH] remoteproc: qcom: fix initializers for qcom_mss_reg_res array

On Wed 01 Feb 08:56 PST 2017, Arnd Bergmann wrote: > The recently added initialization is rather unusual because it uses a > constructor for > a variable-length array to assign a constant structure to a member that uses > a fixed-length > array. This confuses clang and breaks the build. > >

Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master

On Wed, Jan 18, 2017 at 3:57 PM, Rob Herring wrote: > On Thu, Jan 12, 2017 at 04:35:43PM -0600, christopher.lee.bos...@gmail.com > wrote: >> From: Chris Bostic >> >> Define the device tree bindings for the GPIO master type. >> >> Signed-off-by: Chris Bostic

[PATCH V8 07/10] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master

On Wed, Jan 18, 2017 at 3:57 PM, Rob Herring wrote: > On Thu, Jan 12, 2017 at 04:35:43PM -0600, christopher.lee.bos...@gmail.com > wrote: >> From: Chris Bostic >> >> Define the device tree bindings for the GPIO master type. >> >> Signed-off-by: Chris Bostic >> >> --- >> >> V2 - Break out this

[PATCH V8 07/10] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

Re: [PATCH v2] drm: Clean up the 1366x768 fixup codes

On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote: > On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote: > > This is just a cleanup, no functional change. > > > > The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is > > basically a copy of the existing code

Re: [PATCH v2] drm: Clean up the 1366x768 fixup codes

On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote: > On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote: > > This is just a cleanup, no functional change. > > > > The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is > > basically a copy of the existing code

[PATCH V8 10/10] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. Signed-off-by: Tyler Baicar --- arch/arm/include/asm/kvm_arm.h | 1 +

[PATCH V8 10/10] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. Signed-off-by: Tyler Baicar --- arch/arm/include/asm/kvm_arm.h | 1 + arch/arm/include/asm/system_misc.h | 5 +

Re: Question about replacing while_each_thread().

Hi Tetsuo, On 02/01, Tetsuo Handa wrote: > > Is rcu_read_lock() sufficient (i.e. > > rcu_read_lock(); > for_each_process_thread(g, p) { > (...snipped...) > } > rcu_read_unlock(); > > is OK) for "can't go away" ? Yes, this should work just fine, > Likewise, IOPRIO_WHO_PGRP case are

Re: Question about replacing while_each_thread().

Hi Tetsuo, On 02/01, Tetsuo Handa wrote: > > Is rcu_read_lock() sufficient (i.e. > > rcu_read_lock(); > for_each_process_thread(g, p) { > (...snipped...) > } > rcu_read_unlock(); > > is OK) for "can't go away" ? Yes, this should work just fine, > Likewise, IOPRIO_WHO_PGRP case are

[PATCH V8 09/10] trace, ras: add ARM processor error trace event

Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec

[PATCH V8 09/10] trace, ras: add ARM processor error trace event

Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec

Re: [PATCH v5 4/4] sparc64: Add support for ADI (Application Data Integrity)

From: Khalid Aziz Date: Tue, 31 Jan 2017 16:38:49 -0700 > Thanks for the feedback. This is very helpful. I checked and it indeed > can cost 50+ cycles even on M7 processor for PSTATE accesses. Consider how many bytes can be copied in 50+ cycles :-) >> On etrap, you

Re: [PATCH v5 4/4] sparc64: Add support for ADI (Application Data Integrity)

From: Khalid Aziz Date: Tue, 31 Jan 2017 16:38:49 -0700 > Thanks for the feedback. This is very helpful. I checked and it indeed > can cost 50+ cycles even on M7 processor for PSTATE accesses. Consider how many bytes can be copied in 50+ cycles :-) >> On etrap, you change ESTATE_PSTATE{1,2} to

Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()

On Wed, Feb 01, 2017 at 03:51:06PM +0100, Linus Walleij wrote: > On Wed, Feb 1, 2017 at 2:22 PM, Boris Brezillon > wrote: > > On Wed, 1 Feb 2017 14:05:43 +0100 > > Linus Walleij wrote: > > >> > Linus, is this something you really

Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()

On Mon, Jan 30, 2017 at 04:41:48PM +0100, Boris Brezillon wrote: > Rename devm_get_gpiod_from_child() into > devm_fwnode_get_gpiod_from_child() to reflect the fact that this > function is operating on a fwnode object. > > Signed-off-by: Boris Brezillon > --- >

Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()

On Wed, Feb 01, 2017 at 03:51:06PM +0100, Linus Walleij wrote: > On Wed, Feb 1, 2017 at 2:22 PM, Boris Brezillon > wrote: > > On Wed, 1 Feb 2017 14:05:43 +0100 > > Linus Walleij wrote: > > >> > Linus, is this something you really care about? If that's the case, can > >> > you step in? > >> > >>

Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()

On Mon, Jan 30, 2017 at 04:41:48PM +0100, Boris Brezillon wrote: > Rename devm_get_gpiod_from_child() into > devm_fwnode_get_gpiod_from_child() to reflect the fact that this > function is operating on a fwnode object. > > Signed-off-by: Boris Brezillon > --- > drivers/gpio/devres.c

[PATCH V8 08/10] ras: acpi / apei: generate trace event for unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V8 08/10] ras: acpi / apei: generate trace event for unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchronous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V8 04/10] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, report the error in the kernel logs. Update fault_info[] with

[PATCH V8 06/10] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification

[PATCH V8 04/10] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, report the error in the kernel logs. Update fault_info[] with

[PATCH V8 06/10] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification type. The OS should

[PATCH V8 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify the OS of the error. For example, platforms that implement firmware first handling may

[PATCH V8 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify the OS of the error. For example, platforms that implement firmware first handling may

[PATCH V8 03/10] efi: parse ARM processor error

Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Tyler Baicar

[PATCH V8 03/10] efi: parse ARM processor error

Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Tyler Baicar Signed-off-by: Jonathan

[PATCH V8 01/10] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

[PATCH V8 01/10] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

On Wed, Feb 01, 2017 at 03:43:35PM +0100, Lukasz Majewski wrote: > This patch adds support for enabling or disabling the port mirroring > feature of the DP83867 TI's PHY device. > > One use case is when bootstrap configuration enables this feature (because > of e.g. LED wiring) so then one needs

Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver

On Wed, Feb 01, 2017 at 03:43:35PM +0100, Lukasz Majewski wrote: > This patch adds support for enabling or disabling the port mirroring > feature of the DP83867 TI's PHY device. > > One use case is when bootstrap configuration enables this feature (because > of e.g. LED wiring) so then one needs

Re: [PATCH 0/3] Updates for ARC VDK platform

Hi Vineet, On Wed, 2017-02-01 at 09:13 -0800, Vineet Gupta wrote: > On 02/01/2017 08:43 AM, Alexey Brodkin wrote: > > > > This series improves ARC VDK support in upstream Linux kernel by: > >  1) Removal of UP configuration which is no longer supported by ARC VDK. > > Instead SMP platform

Re: [PATCH 0/3] Updates for ARC VDK platform

Hi Vineet, On Wed, 2017-02-01 at 09:13 -0800, Vineet Gupta wrote: > On 02/01/2017 08:43 AM, Alexey Brodkin wrote: > > > > This series improves ARC VDK support in upstream Linux kernel by: > >  1) Removal of UP configuration which is no longer supported by ARC VDK. > > Instead SMP platform

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

On Wed, Feb 01, 2017 at 05:02:43PM +, Punit Agrawal wrote: > Will Deacon writes: > > > On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote: > >> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote: > >> > Refactor the KVM code to use the

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

On Wed, Feb 01, 2017 at 05:02:43PM +, Punit Agrawal wrote: > Will Deacon writes: > > > On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote: > >> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote: > >> > Refactor the KVM code to use the __tlbi macros, which

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

Will Deacon writes: > On Wed, Feb 01, 2017 at 05:02:43PM +, Punit Agrawal wrote: >> Will Deacon writes: >> >> > On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote: >> >> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

Will Deacon writes: > On Wed, Feb 01, 2017 at 05:02:43PM +, Punit Agrawal wrote: >> Will Deacon writes: >> >> > On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote: >> >> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote: >> >> > Refactor the KVM code to

Re: [PATCH] regulator: cpcap: Add basic regulator support

On Mon, Jan 30, 2017 at 04:12:41PM -0800, Tony Lindgren wrote: > Many Motorola phones like droid 4 are using a custom PMIC called CPCAP > or 6556002. This PMIC is used with several SoCs, I've noticed at least > omap3, omap4 and Tegra2 based Motorola phones and tablets using it. > > Cc:

Re: [PATCH] regulator: cpcap: Add basic regulator support

On Mon, Jan 30, 2017 at 04:12:41PM -0800, Tony Lindgren wrote: > Many Motorola phones like droid 4 are using a custom PMIC called CPCAP > or 6556002. This PMIC is used with several SoCs, I've noticed at least > omap3, omap4 and Tegra2 based Motorola phones and tablets using it. > > Cc:

Re: [PATCH 1/3] arc: vdk: Disable halt on reset

Hi Vineet, On Wed, 2017-02-01 at 08:52 -0800, Vineet Gupta wrote: > On 02/01/2017 08:42 AM, Alexey Brodkin wrote: > > > > In recent VDKs ARC cores are configured as "run on reset" > > which made existing kernel configuration outdated to effect that > > slave cores never start execution of the

Re: [PATCH 1/3] arc: vdk: Disable halt on reset

Hi Vineet, On Wed, 2017-02-01 at 08:52 -0800, Vineet Gupta wrote: > On 02/01/2017 08:42 AM, Alexey Brodkin wrote: > > > > In recent VDKs ARC cores are configured as "run on reset" > > which made existing kernel configuration outdated to effect that > > slave cores never start execution of the

Re: keys: GPF in request_key

On Wed, Feb 1, 2017 at 5:50 PM, David Howells wrote: > Do you reboot the system between running individual programs? If not, the > programs will be influencing each other. Further, only those calls with valid > type and matching description values are relevant, I think.

Re: keys: GPF in request_key

On Wed, Feb 1, 2017 at 5:50 PM, David Howells wrote: > Do you reboot the system between running individual programs? If not, the > programs will be influencing each other. Further, only those calls with valid > type and matching description values are relevant, I think. This means those > that

Re: [PATCH 0/3] Updates for ARC VDK platform

On 02/01/2017 08:43 AM, Alexey Brodkin wrote: > This series improves ARC VDK support in upstream Linux kernel by: > 1) Removal of UP configuration which is no longer supported by ARC VDK. > Instead SMP platform with all but master cores halted is used to mimic > UP system. Is this

Re: [PATCH 0/3] Updates for ARC VDK platform

On 02/01/2017 08:43 AM, Alexey Brodkin wrote: > This series improves ARC VDK support in upstream Linux kernel by: > 1) Removal of UP configuration which is no longer supported by ARC VDK. > Instead SMP platform with all but master cores halted is used to mimic > UP system. Is this

Re: [PATCH v2 4/4] i2c: allow specify device properties in i2c_board_info

On Wed, Feb 01, 2017 at 05:24:18PM +0200, Mika Westerberg wrote: > On Tue, Jan 31, 2017 at 06:11:30PM -0800, Dmitry Torokhov wrote: > > With many drivers converting to using generic device properties, it is > > useful to provide array of device properties when instantiating new i2c > > client via

Re: [PATCH v2 4/4] i2c: allow specify device properties in i2c_board_info

On Wed, Feb 01, 2017 at 05:24:18PM +0200, Mika Westerberg wrote: > On Tue, Jan 31, 2017 at 06:11:30PM -0800, Dmitry Torokhov wrote: > > With many drivers converting to using generic device properties, it is > > useful to provide array of device properties when instantiating new i2c > > client via

Re: [PATCH v2 3/4] driver property: constify property arrays values

On Wed, Feb 01, 2017 at 04:42:33PM +0200, Mika Westerberg wrote: > On Tue, Jan 31, 2017 at 06:11:29PM -0800, Dmitry Torokhov wrote: > > Data that is fed into property arrays should not be modified, so let's mark > > relevant pointers as const. This will allow us making source arrays as > >

Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master

On Wed, Jan 18, 2017 at 8:11 PM, Jeremy Kerr wrote: > Hi Chris, > > From this: > >>> + >>> +The standard FSI master node >>> + >>> +This node describes a FSI master implmemented fully in hardware >>> +with dedicated input/output pins required for its

Re: [PATCH v2 3/4] driver property: constify property arrays values

On Wed, Feb 01, 2017 at 04:42:33PM +0200, Mika Westerberg wrote: > On Tue, Jan 31, 2017 at 06:11:29PM -0800, Dmitry Torokhov wrote: > > Data that is fed into property arrays should not be modified, so let's mark > > relevant pointers as const. This will allow us making source arrays as > >

Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master

On Wed, Jan 18, 2017 at 8:11 PM, Jeremy Kerr wrote: > Hi Chris, > > From this: > >>> + >>> +The standard FSI master node >>> + >>> +This node describes a FSI master implmemented fully in hardware >>> +with dedicated input/output pins required for its function (i.e. >>>

Re: [PATCH] usb: gadget: udc: atmel: fix debug output

Le 01/02/2017 à 18:00, Alexandre Belloni a écrit : > On 01/02/2017 at 17:41:55 +0100, Arnd Bergmann wrote: >> The debug output now contains the wrong variable, as seen from the compiler >> warning: >> >> drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': >>

Re: [PATCH] usb: gadget: udc: atmel: fix debug output

Le 01/02/2017 à 18:00, Alexandre Belloni a écrit : > On 01/02/2017 at 17:41:55 +0100, Arnd Bergmann wrote: >> The debug output now contains the wrong variable, as seen from the compiler >> warning: >> >> drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': >>

Re: [PATCH] net: ethernet: ti: cpsw: fix NULL pointer dereference in switch mode

From: Grygorii Strashko Date: Tue, 31 Jan 2017 14:04:04 -0600 > In switch mode on struct cpsw_slave->ndev field will be initialized with > proper value only for the one cpsw slave port, as result > cpsw_get_usage_count() will generate "Unable to handle kernel NULL

Re: [PATCH] net: ethernet: ti: cpsw: fix NULL pointer dereference in switch mode

From: Grygorii Strashko Date: Tue, 31 Jan 2017 14:04:04 -0600 > In switch mode on struct cpsw_slave->ndev field will be initialized with > proper value only for the one cpsw slave port, as result > cpsw_get_usage_count() will generate "Unable to handle kernel NULL pointer > dereference"

Re: [PATCHv7 6/8] printk: use printk_safe buffers in printk

On Tue, 27 Dec 2016 23:16:09 +0900 Sergey Senozhatsky wrote: > Use printk_safe per-CPU buffers in printk recursion-prone blocks: > -- around logbuf_lock protected sections in vprintk_emit() and >console_unlock() > -- around down_trylock_console_sem() and

Re: [PATCHv7 6/8] printk: use printk_safe buffers in printk

On Tue, 27 Dec 2016 23:16:09 +0900 Sergey Senozhatsky wrote: > Use printk_safe per-CPU buffers in printk recursion-prone blocks: > -- around logbuf_lock protected sections in vprintk_emit() and >console_unlock() > -- around down_trylock_console_sem() and up_console_sem() > > Note that this

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

Will Deacon writes: > On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote: >> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote: >> > Refactor the KVM code to use the __tlbi macros, which will allow an errata >> > workaround that repeats tlbi

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

Will Deacon writes: > On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote: >> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote: >> > Refactor the KVM code to use the __tlbi macros, which will allow an errata >> > workaround that repeats tlbi dsb sequences to

Re: [PATCH] ALSA: x86: hdmi: fix build with CONFIG_PM=n

On Wed, 01 Feb 2017 17:19:47 +0100, Arnd Bergmann wrote: > > The runtime_status field is defined conditionally and must not be accessed > outside > of #ifdef CONFIG_PM: > > sound/x86/intel_hdmi_audio_if.c: In function 'hdmi_audio_suspend': > sound/x86/intel_hdmi_audio_if.c:112:30: error:

Re: [PATCH] ALSA: x86: hdmi: fix build with CONFIG_PM=n

On Wed, 01 Feb 2017 17:19:47 +0100, Arnd Bergmann wrote: > > The runtime_status field is defined conditionally and must not be accessed > outside > of #ifdef CONFIG_PM: > > sound/x86/intel_hdmi_audio_if.c: In function 'hdmi_audio_suspend': > sound/x86/intel_hdmi_audio_if.c:112:30: error:

[PATCH] workqueue: avoid clang warning

Building with clang shows lots of warning like: drivers/amba/bus.c:447:8: warning: implicit conversion from 'long long' to 'int' changes value from 4294967248 to -48 [-Wconstant-conversion] static DECLARE_DELAYED_WORK(deferred_retry_work, amba_deferred_retry_func);

[PATCH] workqueue: avoid clang warning

Building with clang shows lots of warning like: drivers/amba/bus.c:447:8: warning: implicit conversion from 'long long' to 'int' changes value from 4294967248 to -48 [-Wconstant-conversion] static DECLARE_DELAYED_WORK(deferred_retry_work, amba_deferred_retry_func);

[PATCH v3 00/18] FSI device driver introduction

Introduction of the IBM 'Flexible Support Interface' (FSI) bus device driver. FSI is a high fan out serial bus consisting of a clock and a serial data line capable of running at speeds up to 166 MHz. This set provides the basic framework to add FSI extensions to the Linux bus and device models.

[PATCH v3 00/18] FSI device driver introduction

Introduction of the IBM 'Flexible Support Interface' (FSI) bus device driver. FSI is a high fan out serial bus consisting of a clock and a serial data line capable of running at speeds up to 166 MHz. This set provides the basic framework to add FSI extensions to the Linux bus and device models.

[PATCH v3 10/18] drivers/fsi: scan slaves & register devices

From: Jeremy Kerr Now that we have fsi_slave devices, scan each for endpoints, and register them on the fsi bus. Includes contributions from Chris Bostic Signed-off-by: Jeremy Kerr Signed-off-by: Chris Bostic ---

[PATCH v3 10/18] drivers/fsi: scan slaves & register devices

From: Jeremy Kerr Now that we have fsi_slave devices, scan each for endpoints, and register them on the fsi bus. Includes contributions from Chris Bostic Signed-off-by: Jeremy Kerr Signed-off-by: Chris Bostic --- drivers/fsi/fsi-core.c | 136

Re: [PATCH] usb: gadget: udc: atmel: fix debug output

On 01/02/2017 at 17:41:55 +0100, Arnd Bergmann wrote: > The debug output now contains the wrong variable, as seen from the compiler > warning: > > drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': > drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used

Re: [PATCH] usb: gadget: udc: atmel: fix debug output

On 01/02/2017 at 17:41:55 +0100, Arnd Bergmann wrote: > The debug output now contains the wrong variable, as seen from the compiler > warning: > > drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable': > drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used

[PATCH] modules: mark __inittest/__exittest as __maybe_unused

clang warns about unused inline functions by default: arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' [-Wunused-function] arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' [-Wunused-function] As these appear in every single module,

[PATCH] modules: mark __inittest/__exittest as __maybe_unused

clang warns about unused inline functions by default: arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' [-Wunused-function] arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' [-Wunused-function] As these appear in every single module,

[PATCH v3 02/18] drivers/fsi: Add device & driver definitions

From: Jeremy Kerr Add structs for fsi devices & drivers, and struct device conversion functions. Signed-off-by: Jeremy Kerr Signed-off-by: Chris Bostic --- include/linux/fsi.h | 11 +++ 1 file changed, 11 insertions(+) diff --git

[PATCH v3 02/18] drivers/fsi: Add device & driver definitions

From: Jeremy Kerr Add structs for fsi devices & drivers, and struct device conversion functions. Signed-off-by: Jeremy Kerr Signed-off-by: Chris Bostic --- include/linux/fsi.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/linux/fsi.h b/include/linux/fsi.h index

[PATCH v2 1/3] PCI: imx6: Fix a typo in error message

Cc: yurov...@gmail.com Cc: Lucas Stach Cc: Bjorn Helgaas Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Acked-by: Lucas Stach Signed-off-by: Andrey Smirnov ---

[PATCH v2 1/3] PCI: imx6: Fix a typo in error message

Cc: yurov...@gmail.com Cc: Lucas Stach Cc: Bjorn Helgaas Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Acked-by: Lucas Stach Signed-off-by: Andrey Smirnov --- drivers/pci/host/pci-imx6.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v2 2/3] PCI: imx6: Allow probe deferal by reset GPIO

Some designs implement reset GPIO via a GPIO expander connected to a peripheral bus. One such example would be i.MX7 Sabre board where said GPIO is provided by SPI shift register connected to a bitbanged SPI bus. In order to support such designs allow reset GPIO request to defer probing of the

[PATCH v2 2/3] PCI: imx6: Allow probe deferal by reset GPIO

Some designs implement reset GPIO via a GPIO expander connected to a peripheral bus. One such example would be i.MX7 Sabre board where said GPIO is provided by SPI shift register connected to a bitbanged SPI bus. In order to support such designs allow reset GPIO request to defer probing of the

[PATCH] tracing/kprobes: fix __init annotation

clang complains about "__init" being attached to a struct name: kernel/trace/trace_kprobe.c:1375:15: error: '__section__' attribute only applies to functions and global variables The intention must have been to mark the function as __init instead of the type, so move the attribute there.

Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric

On 2017-02-01 00:06, Greg KH wrote: > On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote: >> Currently qw_sign requires UTF-8 character to set, but returns UTF-16 >> when read. This isn't obvious when simply using cat since the null >> characters are not visible, but hexdump unveils the

[PATCH] tracing/kprobes: fix __init annotation

clang complains about "__init" being attached to a struct name: kernel/trace/trace_kprobe.c:1375:15: error: '__section__' attribute only applies to functions and global variables The intention must have been to mark the function as __init instead of the type, so move the attribute there.

Re: [PATCH 1/2] fs: configfs: make qw_sign attribute symmetric

On 2017-02-01 00:06, Greg KH wrote: > On Tue, Jan 31, 2017 at 06:19:16PM -0800, Stefan Agner wrote: >> Currently qw_sign requires UTF-8 character to set, but returns UTF-16 >> when read. This isn't obvious when simply using cat since the null >> characters are not visible, but hexdump unveils the

[PATCH v2 0/3] i.MX7 PCI support

Hello, everyone: This is a second iteration of the code that adds PCI-subsystem bits necessary for enabling PCI support on i.MX7. Changes since v1 (can be found at [version1]): - All GPC related code moved into a separate driver (subject of a different patch) - Removed

[PATCH v2 0/3] i.MX7 PCI support

Hello, everyone: This is a second iteration of the code that adds PCI-subsystem bits necessary for enabling PCI support on i.MX7. Changes since v1 (can be found at [version1]): - All GPC related code moved into a separate driver (subject of a different patch) - Removed

Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness

On 10/19/2016 09:22 AM, Will Deacon wrote: > On Wed, Oct 19, 2016 at 09:01:33AM -0700, Linus Torvalds wrote: >> On Wed, Oct 19, 2016 at 8:56 AM, Markus Trippelsdorf >> wrote: >>> On 2016.10.19 at 08:55 -0700, Linus Torvalds wrote: Well, in the meantime we

Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness

On 10/19/2016 09:22 AM, Will Deacon wrote: > On Wed, Oct 19, 2016 at 09:01:33AM -0700, Linus Torvalds wrote: >> On Wed, Oct 19, 2016 at 8:56 AM, Markus Trippelsdorf >> wrote: >>> On 2016.10.19 at 08:55 -0700, Linus Torvalds wrote: Well, in the meantime we apparently have to live with

[PATCH v3 15/18] drivers/fsi: Add FSI bus documentation

From: Chris Bostic Add details on the basic functions of the FSI serial bus. Signed-off-by: Chris Bostic --- Documentation/devicetree/bindings/fsi/fsi.txt | 54 +++ 1 file changed, 54 insertions(+) create mode 100644

[PATCH v3 15/18] drivers/fsi: Add FSI bus documentation

From: Chris Bostic Add details on the basic functions of the FSI serial bus. Signed-off-by: Chris Bostic --- Documentation/devicetree/bindings/fsi/fsi.txt | 54 +++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt diff

[PATCH] remoteproc: qcom: fix initializers for qcom_mss_reg_res array

The recently added initialization is rather unusual because it uses a constructor for a variable-length array to assign a constant structure to a member that uses a fixed-length array. This confuses clang and breaks the build. drivers/remoteproc/qcom_q6v5_pil.c:1024:18: error: incompatible

[PATCH] remoteproc: qcom: fix initializers for qcom_mss_reg_res array

The recently added initialization is rather unusual because it uses a constructor for a variable-length array to assign a constant structure to a member that uses a fixed-length array. This confuses clang and breaks the build. drivers/remoteproc/qcom_q6v5_pil.c:1024:18: error: incompatible

[PATCH v3 18/18] drivers/fsi: Add GPIO based FSI master

From: Chris Bostic Implement a FSI master using GPIO. Will generate FSI protocol for read and write commands to particular addresses. Sends master command and waits for and decodes a slave response. Includes Jeremy Kerr's original GPIO master base commit. Signed-off-by:

[PATCH v3 18/18] drivers/fsi: Add GPIO based FSI master

From: Chris Bostic Implement a FSI master using GPIO. Will generate FSI protocol for read and write commands to particular addresses. Sends master command and waits for and decodes a slave response. Includes Jeremy Kerr's original GPIO master base commit. Signed-off-by: Jeremy Kerr

[PATCH v3 14/18] drivers/fsi: Remove all scanned devices during master unregister

From: Chris Bostic Master will remove all previously scanned devices during an unregister operation. This will be necessary should any master attempt to register more than once. Signed-off-by: Chris Bostic --- drivers/fsi/fsi-core.c | 14 ++

[PATCH v3 14/18] drivers/fsi: Remove all scanned devices during master unregister

From: Chris Bostic Master will remove all previously scanned devices during an unregister operation. This will be necessary should any master attempt to register more than once. Signed-off-by: Chris Bostic --- drivers/fsi/fsi-core.c | 14 ++ 1 file changed, 14 insertions(+) diff

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