[PATCH 10/13] rtc: s35390a: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 10/13] rtc: s35390a: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 08/13] rtc: ds1374: Set .of_match_table to OF device ID table

The driver has a OF device ID table but the struct i2c_driver .of_match_table field is not set. Signed-off-by: Javier Martinez Canillas --- drivers/rtc/rtc-ds1374.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c

[PATCH 08/13] rtc: ds1374: Set .of_match_table to OF device ID table

The driver has a OF device ID table but the struct i2c_driver .of_match_table field is not set. Signed-off-by: Javier Martinez Canillas --- drivers/rtc/rtc-ds1374.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c index

[PATCH 12/13] rtc: m41t80: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 12/13] rtc: m41t80: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 06/13] rtc: ds3232: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 13/13] rtc: rs5c372: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 06/13] rtc: ds3232: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 13/13] rtc: rs5c372: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 03/13] rtc: bq32k: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 3/4] tty/serial: mxs-auart: remove uneeded IS_ERR_OR_NULL calls

Since commit 1d267ea6539f ("serial: mctrl-gpio: simplify init routine"), the mctrl_gpio_to_gpiod() function can't return an error anymore. So, just testing for a NULL pointer is ok. Signed-off-by: Richard Genoud --- drivers/tty/serial/mxs-auart.c | 6 ++ 1 file

[PATCH 03/13] rtc: bq32k: Add OF device ID table

The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:. But this could

[PATCH 3/4] tty/serial: mxs-auart: remove uneeded IS_ERR_OR_NULL calls

Since commit 1d267ea6539f ("serial: mctrl-gpio: simplify init routine"), the mctrl_gpio_to_gpiod() function can't return an error anymore. So, just testing for a NULL pointer is ok. Signed-off-by: Richard Genoud --- drivers/tty/serial/mxs-auart.c | 6 ++ 1 file changed, 2 insertions(+), 4

Re: [PATCH v3 6/6] iio: adc: stm32: add support for EXTI trigger

On 03/03/2017 12:45 PM, Lars-Peter Clausen wrote: > On 02/28/2017 05:51 PM, Fabrice Gasnier wrote: >> EXTi (external interrupt) signal can be routed internally as trigger >> source for ADC conversions: STM32F4 ADC can use EXTI11. >> >> Retrieve interrupt trigger from DT, so it can be muxed into

Re: [PATCH v4] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

Ping Boris On 02/23/2017 at 09:36 PM, Xunlei Pang wrote: > We met an issue for kdump: after kdump kernel boots up, > and there comes a broadcasted mce in first kernel, the > other cpus remaining in first kernel will enter the old > mce handler of first kernel, then timeout and panic due > to MCE

Re: [PATCH v3 6/6] iio: adc: stm32: add support for EXTI trigger

On 03/03/2017 12:45 PM, Lars-Peter Clausen wrote: > On 02/28/2017 05:51 PM, Fabrice Gasnier wrote: >> EXTi (external interrupt) signal can be routed internally as trigger >> source for ADC conversions: STM32F4 ADC can use EXTI11. >> >> Retrieve interrupt trigger from DT, so it can be muxed into

Re: [PATCH v4] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

Ping Boris On 02/23/2017 at 09:36 PM, Xunlei Pang wrote: > We met an issue for kdump: after kdump kernel boots up, > and there comes a broadcasted mce in first kernel, the > other cpus remaining in first kernel will enter the old > mce handler of first kernel, then timeout and panic due > to MCE

[PATCH v3 4/5] staging: rts5208: Remove unnecessary cast on void pointer

The following Coccinelle script was used to detect this: @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T*)x)->f | - (T*) e ) Signed-off-by: simran singhal --- drivers/staging/rts5208/rtsx_transport.c | 3 +-- 1 file

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote: > And another meaning of defining kernel iamge size and mapping size > differently is we can randomize the limited kernel image in the mapping > area. If they are the same or kernel image can be very large, the > position will be fixed or

Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE

On Fri, Mar 03, 2017 at 09:11:52PM +0800, Baoquan He wrote: > And another meaning of defining kernel iamge size and mapping size > differently is we can randomize the limited kernel image in the mapping > area. If they are the same or kernel image can be very large, the > position will be fixed or

[PATCH v3 4/5] staging: rts5208: Remove unnecessary cast on void pointer

The following Coccinelle script was used to detect this: @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T*)x)->f | - (T*) e ) Signed-off-by: simran singhal --- drivers/staging/rts5208/rtsx_transport.c | 3 +-- 1 file changed, 1 insertion(+), 2

Re: [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > When CONFIG_KASAN is enabled, we have several functions that use rather > large kernel stacks, e.g. > > drivers/isdn/hardware/eicon/message.c: In function 'group_optimization': > drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame

Re: [PATCH 25/26] isdn: eicon: mark divascapi incompatible with kasan

On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > When CONFIG_KASAN is enabled, we have several functions that use rather > large kernel stacks, e.g. > > drivers/isdn/hardware/eicon/message.c: In function 'group_optimization': > drivers/isdn/hardware/eicon/message.c:14841:1: warning: the frame

Re: [PATCH v2 5/9] kasan: change report header

On Fri, Mar 3, 2017 at 3:18 PM, Andrey Konovalov wrote: > On Fri, Mar 3, 2017 at 2:21 PM, Andrey Ryabinin > wrote: >> >> >> On 03/02/2017 04:48 PM, Andrey Konovalov wrote: >> >>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >>> index

Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

On Thu, 2017-03-02 at 13:11 -0600, Brijesh Singh wrote: > Hi Mark, > > On 03/02/2017 11:39 AM, Mark Rutland wrote: > > On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote: > > > > > > +ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \ > > >   ccp-ops.o \ > > >   ccp-dev-v3.o \ > > >

Re: [PATCH v2 5/9] kasan: change report header

On Fri, Mar 3, 2017 at 3:18 PM, Andrey Konovalov wrote: > On Fri, Mar 3, 2017 at 2:21 PM, Andrey Ryabinin > wrote: >> >> >> On 03/02/2017 04:48 PM, Andrey Konovalov wrote: >> >>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >>> index 8b0b27eb37cd..945d0e13e8a4 100644 >>> ---

Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

On Thu, 2017-03-02 at 13:11 -0600, Brijesh Singh wrote: > Hi Mark, > > On 03/02/2017 11:39 AM, Mark Rutland wrote: > > On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote: > > > > > > +ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \ > > >   ccp-ops.o \ > > >   ccp-dev-v3.o \ > > >

Re: [PATCH v2 5/9] kasan: change report header

On Fri, Mar 3, 2017 at 2:21 PM, Andrey Ryabinin wrote: > > > On 03/02/2017 04:48 PM, Andrey Konovalov wrote: > >> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >> index 8b0b27eb37cd..945d0e13e8a4 100644 >> --- a/mm/kasan/report.c >> +++ b/mm/kasan/report.c >> @@

Re: [PATCH v2 5/9] kasan: change report header

On Fri, Mar 3, 2017 at 2:21 PM, Andrey Ryabinin wrote: > > > On 03/02/2017 04:48 PM, Andrey Konovalov wrote: > >> diff --git a/mm/kasan/report.c b/mm/kasan/report.c >> index 8b0b27eb37cd..945d0e13e8a4 100644 >> --- a/mm/kasan/report.c >> +++ b/mm/kasan/report.c >> @@ -130,11 +130,11 @@ static

[PATCH 2/4] tty/serial: atmel: remove uneeded IS_ERR_OR_NULL calls

Since commit 1d267ea6539f ("serial: mctrl-gpio: simplify init routine"), the mctrl_gpio_to_gpiod() function can't return an error anymore. So, just testing for a NULL pointer is ok. Signed-off-by: Richard Genoud --- drivers/tty/serial/atmel_serial.c | 12

[PATCH 2/4] tty/serial: atmel: remove uneeded IS_ERR_OR_NULL calls

Since commit 1d267ea6539f ("serial: mctrl-gpio: simplify init routine"), the mctrl_gpio_to_gpiod() function can't return an error anymore. So, just testing for a NULL pointer is ok. Signed-off-by: Richard Genoud --- drivers/tty/serial/atmel_serial.c | 12 1 file changed, 4

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, Mar 3, 2017 at 3:11 PM, Dmitry Vyukov wrote: > On Mon, Feb 13, 2017 at 11:29 PM, Cong Wang wrote: >> On Mon, Feb 13, 2017 at 11:19 AM, Andrey Konovalov >> wrote: >>> Hi, >>> >>> I've got the following error report

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Fri, Mar 3, 2017 at 3:11 PM, Dmitry Vyukov wrote: > On Mon, Feb 13, 2017 at 11:29 PM, Cong Wang wrote: >> On Mon, Feb 13, 2017 at 11:19 AM, Andrey Konovalov >> wrote: >>> Hi, >>> >>> I've got the following error report while fuzzing the kernel with syzkaller. >>> >>> On commit

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

On Fri, 3 Mar 2017 14:30:21 +0100 Alban wrote: > On Fri, 3 Mar 2017 13:34:19 +0100 > Boris Brezillon wrote: > > > On Fri, 3 Mar 2017 11:23:16 + > > Srinivas Kandagatla wrote: > > > > > > > > > > >

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

On Fri, 3 Mar 2017 14:30:21 +0100 Alban wrote: > On Fri, 3 Mar 2017 13:34:19 +0100 > Boris Brezillon wrote: > > > On Fri, 3 Mar 2017 11:23:16 + > > Srinivas Kandagatla wrote: > > > > > > > > > > > + mutex_lock(_nvmem_list_lock); > > > > +

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Mon, Feb 13, 2017 at 11:29 PM, Cong Wang wrote: > On Mon, Feb 13, 2017 at 11:19 AM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while fuzzing the kernel with syzkaller. >> >> On commit

Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

On 03/01/2017, 11:27 AM, Ingo Molnar wrote: > But no strong feelings either way, I just try to sneak in these small > namespace > structure tricks when nobody's looking! ;-) So I assume to introduce two underscores. thanks, -- js suse labs

Re: net/dccp: use-after-free in dccp_feat_activate_values

On Mon, Feb 13, 2017 at 11:29 PM, Cong Wang wrote: > On Mon, Feb 13, 2017 at 11:19 AM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while fuzzing the kernel with syzkaller. >> >> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742. >> >> A reproducer and .config are

Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

On 03/01/2017, 11:27 AM, Ingo Molnar wrote: > But no strong feelings either way, I just try to sneak in these small > namespace > structure tricks when nobody's looking! ;-) So I assume to introduce two underscores. thanks, -- js suse labs

Re: [RFC 06/11] mm: remove SWAP_MLOCK in ttu

On 03/02/2017 12:09 PM, Minchan Kim wrote: > ttu don't need to return SWAP_MLOCK. Instead, just return SWAP_FAIL > because it means the page is not-swappable so it should move to > another LRU list(active or unevictable). putback friends will > move it to right list depending on the page's LRU

Re: [RFC 06/11] mm: remove SWAP_MLOCK in ttu

On 03/02/2017 12:09 PM, Minchan Kim wrote: > ttu don't need to return SWAP_MLOCK. Instead, just return SWAP_FAIL > because it means the page is not-swappable so it should move to > another LRU list(active or unevictable). putback friends will > move it to right list depending on the page's LRU

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

On Fri, 3 Mar 2017 14:57:26 +0100 Alban wrote: > On Fri, 3 Mar 2017 14:36:58 +0100 > Boris Brezillon wrote: > > > On Fri, 3 Mar 2017 13:36:29 +0100 > > Alban wrote: > > > > > On Thu, 2 Mar 2017 22:18:03 +0100 > > > Boris

Re: [PATCH v2 4/9] kasan: simplify address description logic

On 03/02/2017 04:48 PM, Andrey Konovalov wrote: > -static void kasan_object_err(struct kmem_cache *cache, void *object) > +static struct page *addr_to_page(const void *addr) > +{ > + if ((addr >= (void *)PAGE_OFFSET) && > + (addr < high_memory)) Should fit in one line.

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

On Fri, 3 Mar 2017 14:57:26 +0100 Alban wrote: > On Fri, 3 Mar 2017 14:36:58 +0100 > Boris Brezillon wrote: > > > On Fri, 3 Mar 2017 13:36:29 +0100 > > Alban wrote: > > > > > On Thu, 2 Mar 2017 22:18:03 +0100 > > > Boris Brezillon wrote: > > > > > > > On Thu, 2 Mar 2017 20:50:22

Re: [PATCH v2 4/9] kasan: simplify address description logic

On 03/02/2017 04:48 PM, Andrey Konovalov wrote: > -static void kasan_object_err(struct kmem_cache *cache, void *object) > +static struct page *addr_to_page(const void *addr) > +{ > + if ((addr >= (void *)PAGE_OFFSET) && > + (addr < high_memory)) Should fit in one line.

[PATCH v2] clk: imx: clk-imxul: The i.mx6ul has no aips_tz3 clock

The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register. Reviewed-by: Fabio Estevam Signed-off-by: Robin van der Gracht --- drivers/clk/imx/clk-imx6ul.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH v2] clk: imx: clk-imxul: The i.mx6ul has no aips_tz3 clock

The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register. Reviewed-by: Fabio Estevam Signed-off-by: Robin van der Gracht --- drivers/clk/imx/clk-imx6ul.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/clk/imx/clk-imx6ul.c

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

Yup, when I disabled the s5p driver, xts DID show in the /proc/crypto list. Heh, I was about to ask if it was something I should push towards another maintainer for s5p stuff, but found you listed in that as well. If I am incorrect in that assumption, do let me know whom else I should make aware

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

Yup, when I disabled the s5p driver, xts DID show in the /proc/crypto list. Heh, I was about to ask if it was something I should push towards another maintainer for s5p stuff, but found you listed in that as well. If I am incorrect in that assumption, do let me know whom else I should make aware

[PATCH v6 4/4] drm/rockchip: Implement CRC debugfs API

Implement the .set_crc_source() callback and call the DP helpers accordingly to start and stop CRC capture. This is only done if this CRTC is currently using the eDP connector. v3: Remove superfluous check on rockchip_crtc_state->output_type v6: Remove superfluous variable Signed-off-by: Tomeu

[PATCH v6 4/4] drm/rockchip: Implement CRC debugfs API

Implement the .set_crc_source() callback and call the DP helpers accordingly to start and stop CRC capture. This is only done if this CRTC is currently using the eDP connector. v3: Remove superfluous check on rockchip_crtc_state->output_type v6: Remove superfluous variable Signed-off-by: Tomeu

Re: [PATCH 2/3] mmc: sdhci-acpi: Check device status before calling fix_up_power()

Hi, On 03-03-17 10:09, Jean Delvare wrote: Hi Hans, Adrian, On Sat, 25 Feb 2017 18:23:56 +0100, Hans de Goede wrote: Calling acpi_device_fix_up_power() on a device which is not present is not a good idea. How bad is it? Not that bad really, thinking more about this, since

Re: [PATCH 2/3] mmc: sdhci-acpi: Check device status before calling fix_up_power()

Hi, On 03-03-17 10:09, Jean Delvare wrote: Hi Hans, Adrian, On Sat, 25 Feb 2017 18:23:56 +0100, Hans de Goede wrote: Calling acpi_device_fix_up_power() on a device which is not present is not a good idea. How bad is it? Not that bad really, thinking more about this, since

[PATCH 2/2] acpi: apei: handle SEI notification type for ARMv8

ARM APEI extension proposal added SEI (asynchronous SError interrupt) notification type for ARMv8. Add a new GHES error source handling function for SEI. In firmware first mode, if an error source's notification type is SEI. Then GHES could parse and report the detail error information.

[PATCH 2/2] acpi: apei: handle SEI notification type for ARMv8

ARM APEI extension proposal added SEI (asynchronous SError interrupt) notification type for ARMv8. Add a new GHES error source handling function for SEI. In firmware first mode, if an error source's notification type is SEI. Then GHES could parse and report the detail error information.

[PATCH] clk: imx: clk-imxul: The i.mx6ul has no aips_tx3 clock

The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register. Signed-off-by: Robin van der Gracht --- drivers/clk/imx/clk-imx6ul.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c

[PATCH] clk: imx: clk-imxul: The i.mx6ul has no aips_tx3 clock

The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register. Signed-off-by: Robin van der Gracht --- drivers/clk/imx/clk-imx6ul.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c index 75c35fb..dbd6e59

[PATCH v5 2/4] dt-bindings: mfd: Add LED subnode binding for MT6323 PMIC

From: Sean Wang This patch adds documentation for devicetree bindings for LED support as the subnode of MT6323 PMIC Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/mfd/mt6397.txt | 5 + 1 file changed, 5 insertions(+) diff

[PATCH v5 1/4] dt-bindings: leds: Add document bindings for leds-mt6323

From: Sean Wang This patch adds documentation for devicetree bindings for LED support on MT6323 PMIC Signed-off-by: Sean Wang --- .../devicetree/bindings/leds/leds-mt6323.txt | 63 ++ 1 file changed, 63 insertions(+)

[PATCH v5 1/4] dt-bindings: leds: Add document bindings for leds-mt6323

From: Sean Wang This patch adds documentation for devicetree bindings for LED support on MT6323 PMIC Signed-off-by: Sean Wang --- .../devicetree/bindings/leds/leds-mt6323.txt | 63 ++ 1 file changed, 63 insertions(+) create mode 100644

[PATCH v5 2/4] dt-bindings: mfd: Add LED subnode binding for MT6323 PMIC

From: Sean Wang This patch adds documentation for devicetree bindings for LED support as the subnode of MT6323 PMIC Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/mfd/mt6397.txt | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH v5 4/4] mfd: mt6397: Add MT6323 LED support into MT6397 driver

From: Sean Wang Add compatible string as "mt6323-led" that will make the OF core spawn child devices for the LED subnode of that MT6323 MFD device. Signed-off-by: Sean Wang --- drivers/mfd/mt6397-core.c | 4 1 file changed, 4 insertions(+)

[PATCH v5 3/4] leds: Add LED support for MT6323 PMIC

From: Sean Wang MT6323 PMIC is a multi-function device that includes LED function. It allows attaching up to 4 LEDs which can either be on, off or dimmed and/or blinked with the controller. Signed-off-by: Sean Wang --- drivers/leds/Kconfig

[PATCH v5 4/4] mfd: mt6397: Add MT6323 LED support into MT6397 driver

From: Sean Wang Add compatible string as "mt6323-led" that will make the OF core spawn child devices for the LED subnode of that MT6323 MFD device. Signed-off-by: Sean Wang --- drivers/mfd/mt6397-core.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mfd/mt6397-core.c

[PATCH v5 3/4] leds: Add LED support for MT6323 PMIC

From: Sean Wang MT6323 PMIC is a multi-function device that includes LED function. It allows attaching up to 4 LEDs which can either be on, off or dimmed and/or blinked with the controller. Signed-off-by: Sean Wang --- drivers/leds/Kconfig | 8 + drivers/leds/Makefile | 1 +

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin wrote: > > > On 03/02/2017 07:38 PM, Arnd Bergmann wrote: >> When CONFIG_KASAN is set, we can run into some code that uses incredible >> amounts of kernel stack: >> >> drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On Fri, Mar 3, 2017 at 2:50 PM, Andrey Ryabinin wrote: > > > On 03/02/2017 07:38 PM, Arnd Bergmann wrote: >> When CONFIG_KASAN is set, we can run into some code that uses incredible >> amounts of kernel stack: >> >> drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes >>

Re: [PATCH v2 5/9] kasan: change report header

On 03/02/2017 04:48 PM, Andrey Konovalov wrote: > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > index 8b0b27eb37cd..945d0e13e8a4 100644 > --- a/mm/kasan/report.c > +++ b/mm/kasan/report.c > @@ -130,11 +130,11 @@ static void print_error_description(struct > kasan_access_info *info) > {

[PATCH v5 0/4] leds: add leds-mt6323 support on MT7623 SoC

From: Sean Wang MT7623 SoC uses MT6323 PMIC as the default power supply which has LED function insides. The patchset introduces the LED support for MT6323 with on, off and hardware dimmed and blinked and it should work on other similar SoCs if also using MT6323. Changes

Re: [PATCH v2 5/9] kasan: change report header

On 03/02/2017 04:48 PM, Andrey Konovalov wrote: > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > index 8b0b27eb37cd..945d0e13e8a4 100644 > --- a/mm/kasan/report.c > +++ b/mm/kasan/report.c > @@ -130,11 +130,11 @@ static void print_error_description(struct > kasan_access_info *info) > {

[PATCH v5 0/4] leds: add leds-mt6323 support on MT7623 SoC

From: Sean Wang MT7623 SoC uses MT6323 PMIC as the default power supply which has LED function insides. The patchset introduces the LED support for MT6323 with on, off and hardware dimmed and blinked and it should work on other similar SoCs if also using MT6323. Changes since v1: - fixed typo

[no subject]

Congratulations, OXFAM Grants U.A.E have donated grant funds of $800,000 to you (Winning ID: OXF/DXB/02/034903) as the lucky recipient for this March 2017 regular social programme, please contact us for more information via this Email: oxfamgran...@gmail.com

[no subject]

Congratulations, OXFAM Grants U.A.E have donated grant funds of $800,000 to you (Winning ID: OXF/DXB/02/034903) as the lucky recipient for this March 2017 regular social programme, please contact us for more information via this Email: oxfamgran...@gmail.com

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > When CONFIG_KASAN is set, we can run into some code that uses incredible > amounts of kernel stack: > > drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes > is larger than 2048 bytes [-Werror=frame-larger-than=] >

Re: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation

On 03/02/2017 07:38 PM, Arnd Bergmann wrote: > When CONFIG_KASAN is set, we can run into some code that uses incredible > amounts of kernel stack: > > drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes > is larger than 2048 bytes [-Werror=frame-larger-than=] >

[PATCH v6 2/4] drm/dp: add helpers for capture of frame CRCs

Adds helpers for starting and stopping capture of frame CRCs through the DPCD. When capture is on, a worker waits for vblanks and retrieves the frame CRC to put it in the queue on the CRTC that is using the eDP connector, so it's passed to userspace. v2: Reuse drm_crtc_wait_one_vblank Update

[PATCH v6 2/4] drm/dp: add helpers for capture of frame CRCs

Adds helpers for starting and stopping capture of frame CRCs through the DPCD. When capture is on, a worker waits for vblanks and retrieves the frame CRC to put it in the queue on the CRTC that is using the eDP connector, so it's passed to userspace. v2: Reuse drm_crtc_wait_one_vblank Update

[PATCH v6 1/4] drm/dp: add crtc backpointer to drm_dp_aux

This backpointer allows DP helpers to access the crtc it's currently being used for. v6: Have the backpointer be to drm_crtc (Sean Paul) Signed-off-by: Tomeu Vizoso --- include/drm/drm_dp_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH v6 1/4] drm/dp: add crtc backpointer to drm_dp_aux

This backpointer allows DP helpers to access the crtc it's currently being used for. v6: Have the backpointer be to drm_crtc (Sean Paul) Signed-off-by: Tomeu Vizoso --- include/drm/drm_dp_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_dp_helper.h

[PATCH v6 3/4] drm/bridge: analogix_dp: add helpers for capture of frame CRCs

Add two simple functions that just take the drm_dp_aux from our struct and calls the corresponding DP helpers with it. v6: Pass to the DP helper the drm_crtc of the current connector (Sean Paul) Signed-off-by: Tomeu Vizoso ---

[PATCH v6 3/4] drm/bridge: analogix_dp: add helpers for capture of frame CRCs

Add two simple functions that just take the drm_dp_aux from our struct and calls the corresponding DP helpers with it. v6: Pass to the DP helper the drm_crtc of the current connector (Sean Paul) Signed-off-by: Tomeu Vizoso --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 22

Re: [PATCH v11 1/9] dt-bindings: mmc: Add Cavium SOCs MMC bindings

On 6 February 2017 at 14:39, Jan Glauber wrote: > Add description of Cavium Octeon and ThunderX SOC device tree bindings. > > CC: Ulf Hansson > CC: Rob Herring > CC: Mark Rutland > CC:

Re: [PATCH v11 1/9] dt-bindings: mmc: Add Cavium SOCs MMC bindings

On 6 February 2017 at 14:39, Jan Glauber wrote: > Add description of Cavium Octeon and ThunderX SOC device tree bindings. > > CC: Ulf Hansson > CC: Rob Herring > CC: Mark Rutland > CC: devicet...@vger.kernel.org > > Signed-off-by: Jan Glauber > Signed-off-by: David Daney > Signed-off-by:

Re: [PATCH] clk: imx: correct uart4_serial clock name in driver for i.MX6UL

On Fri, Mar 3, 2017 at 9:36 AM, Robin van der Gracht wrote: > Signed-off-by: Robin van der Gracht Reviewed-by: Fabio Estevam

Re: [PATCH] clk: imx: correct uart4_serial clock name in driver for i.MX6UL

On Fri, Mar 3, 2017 at 9:36 AM, Robin van der Gracht wrote: > Signed-off-by: Robin van der Gracht Reviewed-by: Fabio Estevam

Re: [PATCH] clk: imx: clk-imxul: The i.mx6ul has no aips_tx3 clock

On Fri, Mar 3, 2017 at 10:26 AM, Robin van der Gracht wrote: > The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register. > > Signed-off-by: Robin van der Gracht Subject should say "aips_tz3". With that fixed you can: Reviewed-by: Fabio Estevam

Re: [PATCH] clk: imx: clk-imxul: The i.mx6ul has no aips_tx3 clock

On Fri, Mar 3, 2017 at 10:26 AM, Robin van der Gracht wrote: > The clock was mapped on CG15 (gpio2_clocks) in the CCRG0 register. > > Signed-off-by: Robin van der Gracht Subject should say "aips_tz3". With that fixed you can: Reviewed-by: Fabio Estevam

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

On Fri, Mar 3, 2017 at 9:26 AM, Christian Borntraeger wrote: > On 03/02/2017 10:45 PM, Arnd Bergmann wrote: >> Ok, got it. So I guess the behavior of forcing aligned accesses on aligned >> data is accidental, and allowing non-power-of-two arguments is also not >> the main

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

On Fri, 3 Mar 2017 13:36:29 +0100 Alban wrote: > On Thu, 2 Mar 2017 22:18:03 +0100 > Boris Brezillon wrote: > > > On Thu, 2 Mar 2017 20:50:22 +0100 > > Alban wrote: > > > > [snip] > > > > > +static void mtd_nvmem_add(struct

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

On Fri, Mar 3, 2017 at 9:26 AM, Christian Borntraeger wrote: > On 03/02/2017 10:45 PM, Arnd Bergmann wrote: >> Ok, got it. So I guess the behavior of forcing aligned accesses on aligned >> data is accidental, and allowing non-power-of-two arguments is also not >> the main purpose. > > > Right.

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

On Fri, 3 Mar 2017 13:36:29 +0100 Alban wrote: > On Thu, 2 Mar 2017 22:18:03 +0100 > Boris Brezillon wrote: > > > On Thu, 2 Mar 2017 20:50:22 +0100 > > Alban wrote: > > > > [snip] > > > > > +static void mtd_nvmem_add(struct mtd_info *mtd) > > > +{ > > > + struct device *dev = >dev; > > >

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

Heiko, you might be interested in this as well. On Fri, 2017-03-03 at 00:21 +, James Hogan wrote: > On Wed, Mar 01, 2017 at 08:50:20PM +0200, Andy Shevchenko wrote: > > On Wed, 2017-03-01 at 18:02 +, James Hogan wrote: > > > On 11 January 2017 at 19:48, Jason Uy >

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

Heiko, you might be interested in this as well. On Fri, 2017-03-03 at 00:21 +, James Hogan wrote: > On Wed, Mar 01, 2017 at 08:50:20PM +0200, Andy Shevchenko wrote: > > On Wed, 2017-03-01 at 18:02 +, James Hogan wrote: > > > On 11 January 2017 at 19:48, Jason Uy > > > wrote: > > > > In

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

On Fri, 3 Mar 2017 13:34:19 +0100 Boris Brezillon wrote: > On Fri, 3 Mar 2017 11:23:16 + > Srinivas Kandagatla wrote: > > > > > > > + mutex_lock(_nvmem_list_lock); > > > + list_for_each_entry(mtd_nvmem, _nvmem_list,

Re: [PATCH 2/3] mtd: Add support for reading MTD devices via the nvmem API

On Fri, 3 Mar 2017 13:34:19 +0100 Boris Brezillon wrote: > On Fri, 3 Mar 2017 11:23:16 + > Srinivas Kandagatla wrote: > > > > > > > + mutex_lock(_nvmem_list_lock); > > > + list_for_each_entry(mtd_nvmem, _nvmem_list, list) { > > > + if (mtd_nvmem->mtd == mtd) { > > > +

Re: [PATCH v5 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings

On Friday 03 March 2017 12:20 PM, Rob Herring wrote: On Thu, Mar 02, 2017 at 05:48:36AM -0500, Anurup M wrote: From: Tan Xiaojun Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die Signed-off-by: Tan Xiaojun Signed-off-by: Anurup M

Re: [PATCH v5 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings

On Friday 03 March 2017 12:20 PM, Rob Herring wrote: On Thu, Mar 02, 2017 at 05:48:36AM -0500, Anurup M wrote: From: Tan Xiaojun Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die Signed-off-by: Tan Xiaojun Signed-off-by: Anurup M ---

Re: next build: 208 builds: 2 failed, 206 passed, 423 warnings (next-20170303)

On Fri, Mar 3, 2017 at 4:41 AM, kernelci.org bot wrote: > > mips: gcc version 6.3.0 (GCC) > generic_defconfig FAIL This is a problem with kernelci missing a tool on the build machine. > x86: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) >

Re: next build: 208 builds: 2 failed, 206 passed, 423 warnings (next-20170303)

On Fri, Mar 3, 2017 at 4:41 AM, kernelci.org bot wrote: > > mips: gcc version 6.3.0 (GCC) > generic_defconfig FAIL This is a problem with kernelci missing a tool on the build machine. > x86: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) > allmodconfig+CONFIG_OF=n FAIL My patch

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