Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors

Hi, On Thu, Mar 24, 2016 at 4:26 AM, Enric Balletbo Serra wrote: >> Ah, that would make some sense why things work OK on Rockchip. Adding >> DW_MCI_QUIRK_BROKEN_DTO to peach probably doesn't make sense, then. >> Hrm... >> >> Since my original debugging of the issue was over

Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors

Hi, On Thu, Mar 24, 2016 at 4:26 AM, Enric Balletbo Serra wrote: >> Ah, that would make some sense why things work OK on Rockchip. Adding >> DW_MCI_QUIRK_BROKEN_DTO to peach probably doesn't make sense, then. >> Hrm... >> >> Since my original debugging of the issue was over a year ago, I think

Re: [PATCH 05/13] libnvdimm, blk: use devm_add_action to release bdev resources

On Donnerstag, 24. März 2016 08:14:10 CET Dan Williams wrote: > On Thu, Mar 24, 2016 at 4:48 AM, Johannes Thumshirn wrote: > > On Mittwoch, 23. März 2016 18:25:47 CET Dan Williams wrote: > >> Register a callback to clean up the request_queue and put the gendisk at > >> driver

Re: [PATCH 05/13] libnvdimm, blk: use devm_add_action to release bdev resources

On Donnerstag, 24. März 2016 08:14:10 CET Dan Williams wrote: > On Thu, Mar 24, 2016 at 4:48 AM, Johannes Thumshirn wrote: > > On Mittwoch, 23. März 2016 18:25:47 CET Dan Williams wrote: > >> Register a callback to clean up the request_queue and put the gendisk at > >> driver disable time. > >>

Re: [PATCH 08/13] eeprom: at24: call read and write routines via function pointers

Hi Bartosz, [auto build test ERROR on next-20160324] [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Bartosz-Golaszewski/eeprom-support

Re: [PATCH 08/13] eeprom: at24: call read and write routines via function pointers

Hi Bartosz, [auto build test ERROR on next-20160324] [cannot apply to v4.5-rc7 v4.5-rc6 v4.5-rc5 v4.5] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Bartosz-Golaszewski/eeprom-support

Re: [PATCH 05/13] libnvdimm, blk: use devm_add_action to release bdev resources

On Thu, Mar 24, 2016 at 4:48 AM, Johannes Thumshirn wrote: > On Mittwoch, 23. März 2016 18:25:47 CET Dan Williams wrote: >> Register a callback to clean up the request_queue and put the gendisk at >> driver disable time. >> >> Cc: Ross Zwisler >>

Re: [PATCH 05/13] libnvdimm, blk: use devm_add_action to release bdev resources

On Thu, Mar 24, 2016 at 4:48 AM, Johannes Thumshirn wrote: > On Mittwoch, 23. März 2016 18:25:47 CET Dan Williams wrote: >> Register a callback to clean up the request_queue and put the gendisk at >> driver disable time. >> >> Cc: Ross Zwisler >> Signed-off-by: Dan Williams > > [...] > >> >>

Re: [PATCH 2/6] ftrace: Make ftrace_location_range() global

On Thu, 24 Mar 2016 22:04:01 +1100 Michael Ellerman wrote: > In order to support live patching on powerpc we would like to call > ftrace_location_range(), so make it global. Do you want me to try to get this into this merge window? -- Steve

Re: [PATCH 2/6] ftrace: Make ftrace_location_range() global

On Thu, 24 Mar 2016 22:04:01 +1100 Michael Ellerman wrote: > In order to support live patching on powerpc we would like to call > ftrace_location_range(), so make it global. Do you want me to try to get this into this merge window? -- Steve

Re: [PATCH 2/6] ftrace: Make ftrace_location_range() global

On Thu, 24 Mar 2016, Steven Rostedt wrote: > > In order to support live patching on powerpc we would like to call > > ftrace_location_range(), so make it global. > > Do you want me to try to get this into this merge window? I don't think that's necessary. The dependency (rest of livepatching

Re: [PATCH 2/6] ftrace: Make ftrace_location_range() global

On Thu, 24 Mar 2016, Steven Rostedt wrote: > > In order to support live patching on powerpc we would like to call > > ftrace_location_range(), so make it global. > > Do you want me to try to get this into this merge window? I don't think that's necessary. The dependency (rest of livepatching

[PATCH v2] staging: lustre: lnet: revert commit 4671a0266

Commit 4671a0266 change the parameter of the second parameter of cfs_precpt_alloc() from a sizeof type to sizeof type *pointer. This was incorrect in this case and it caused a crash when the LNet layer was brought up in my testing. The reason is cfs_precpt_alloc() creates an array of items where

[PATCH v2] staging: lustre: lnet: revert commit 4671a0266

Commit 4671a0266 change the parameter of the second parameter of cfs_precpt_alloc() from a sizeof type to sizeof type *pointer. This was incorrect in this case and it caused a crash when the LNet layer was brought up in my testing. The reason is cfs_precpt_alloc() creates an array of items where

Re: [PATCH 05/13] libnvdimm, blk: use devm_add_action to release bdev resources

On Thu, Mar 24, 2016 at 8:15 AM, Johannes Thumshirn wrote: > On Donnerstag, 24. März 2016 08:14:10 CET Dan Williams wrote: >> On Thu, Mar 24, 2016 at 4:48 AM, Johannes Thumshirn > wrote: >> > On Mittwoch, 23. März 2016 18:25:47 CET Dan Williams wrote: >>

Re: [PATCH 08/13] libnvdimm, blk: move i/o infrastructure to nd_namespace_blk

On Donnerstag, 24. März 2016 08:21:20 CET Dan Williams wrote: > On Thu, Mar 24, 2016 at 5:22 AM, Johannes Thumshirn wrote: > > On Mittwoch, 23. März 2016 18:26:03 CET Dan Williams wrote: > >> Consolidate the information for issuing i/o to a blk-namespace, and > >> eliminate

Re: [PATCH 05/13] libnvdimm, blk: use devm_add_action to release bdev resources

On Thu, Mar 24, 2016 at 8:15 AM, Johannes Thumshirn wrote: > On Donnerstag, 24. März 2016 08:14:10 CET Dan Williams wrote: >> On Thu, Mar 24, 2016 at 4:48 AM, Johannes Thumshirn > wrote: >> > On Mittwoch, 23. März 2016 18:25:47 CET Dan Williams wrote: >> >> Register a callback to clean up the

Re: [PATCH 08/13] libnvdimm, blk: move i/o infrastructure to nd_namespace_blk

On Donnerstag, 24. März 2016 08:21:20 CET Dan Williams wrote: > On Thu, Mar 24, 2016 at 5:22 AM, Johannes Thumshirn wrote: > > On Mittwoch, 23. März 2016 18:26:03 CET Dan Williams wrote: > >> Consolidate the information for issuing i/o to a blk-namespace, and > >> eliminate some pointer chasing.

Re: [PATCH 08/13] libnvdimm, blk: move i/o infrastructure to nd_namespace_blk

On Thu, Mar 24, 2016 at 5:22 AM, Johannes Thumshirn wrote: > On Mittwoch, 23. März 2016 18:26:03 CET Dan Williams wrote: >> Consolidate the information for issuing i/o to a blk-namespace, and >> eliminate some pointer chasing. >> >> Signed-off-by: Dan Williams

Re: [PATCH 08/13] libnvdimm, blk: move i/o infrastructure to nd_namespace_blk

On Thu, Mar 24, 2016 at 5:22 AM, Johannes Thumshirn wrote: > On Mittwoch, 23. März 2016 18:26:03 CET Dan Williams wrote: >> Consolidate the information for issuing i/o to a blk-namespace, and >> eliminate some pointer chasing. >> >> Signed-off-by: Dan Williams >> --- > [...] >>

Re: [PATCH 02/23] ARM: dts: n950: add display support

On Thu, 24 Mar 2016, Sebastian Reichel wrote: > As I said: I did use 864 initially. That results in missing pixels. Sorry, I didn't mean to question this. Go with what works, not with some old fart's ramblings! > I _think_, that your HW team decided to cover the first and the >

Re: [PATCH] mmc: Provide tracepoints for request processing

On Thu, 24 Mar 2016 19:54:08 +0800 Baolin Wang wrote: > +++ b/include/trace/events/mmc.h > @@ -0,0 +1,188 @@ > +#undef TRACE_SYSTEM > +#define TRACE_SYSTEM mmc > + > +#if !defined(_TRACE_MMC_H) || defined(TRACE_HEADER_MULTI_READ) > +#define _TRACE_MMC_H > + > +#include

Re: [PATCH 02/23] ARM: dts: n950: add display support

On Thu, 24 Mar 2016, Sebastian Reichel wrote: > As I said: I did use 864 initially. That results in missing pixels. Sorry, I didn't mean to question this. Go with what works, not with some old fart's ramblings! > I _think_, that your HW team decided to cover the first and the > last few pixels

Re: [PATCH] mmc: Provide tracepoints for request processing

On Thu, 24 Mar 2016 19:54:08 +0800 Baolin Wang wrote: > +++ b/include/trace/events/mmc.h > @@ -0,0 +1,188 @@ > +#undef TRACE_SYSTEM > +#define TRACE_SYSTEM mmc > + > +#if !defined(_TRACE_MMC_H) || defined(TRACE_HEADER_MULTI_READ) > +#define _TRACE_MMC_H > + > +#include > +#include > +#include

Re: [PATCH v2] cpufreq: rockchip: add driver

Hi Viresh, can we add a of_match_table with a common compatible name as follows ? --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -470,10 +470,16 @@ static int dt_cpufreq_remove(struct platform_device *pdev) cpufreq_unregister_driver(_cpufreq_driver);

Re: [PATCH v2 0/5] mempool based chained scatterlist alloc/free api

On Wed, Mar 23, 2016 at 12:40 AM, Christoph Hellwig wrote: > On Tue, Mar 22, 2016 at 03:03:11PM -0700, Ming Lin wrote: >> From: Ming Lin >> >> The fist 4 patches make the SG related definitions/structs/functions >> in SCSI code generic and the last patch move

Re: [PATCH v2] cpufreq: rockchip: add driver

Hi Viresh, can we add a of_match_table with a common compatible name as follows ? --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -470,10 +470,16 @@ static int dt_cpufreq_remove(struct platform_device *pdev) cpufreq_unregister_driver(_cpufreq_driver);

Re: [PATCH v2 0/5] mempool based chained scatterlist alloc/free api

On Wed, Mar 23, 2016 at 12:40 AM, Christoph Hellwig wrote: > On Tue, Mar 22, 2016 at 03:03:11PM -0700, Ming Lin wrote: >> From: Ming Lin >> >> The fist 4 patches make the SG related definitions/structs/functions >> in SCSI code generic and the last patch move it to lib/sg_pool.c. >> >> I still

Re: [PATCH 1/1] Btrfs: Code Cleanup

On Thu, 24 Mar 2016 16:03:07 +0100 David Sterba wrote: > On Sun, Mar 20, 2016 at 03:11:11PM +0800, Flex Liu wrote: >[...] > > --- a/fs/btrfs/volumes.c > > +++ b/fs/btrfs/volumes.c > > @@ -2325,7 +2325,10 @@ int btrfs_init_new_device(struct btrfs_root *root, > > char

Re: [PATCH 1/1] Btrfs: Code Cleanup

On Thu, 24 Mar 2016 16:03:07 +0100 David Sterba wrote: > On Sun, Mar 20, 2016 at 03:11:11PM +0800, Flex Liu wrote: >[...] > > --- a/fs/btrfs/volumes.c > > +++ b/fs/btrfs/volumes.c > > @@ -2325,7 +2325,10 @@ int btrfs_init_new_device(struct btrfs_root *root, > > char *device_path) > > if

Re: [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen

On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao wrote: > ACPI 6.0 introduces a new table STAO to list the devices which are used > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical > UART is used by Xen. So here it hides UART from Dom0. > > CC:

Re: [PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen

On Thu, Mar 24, 2016 at 3:44 PM, Shannon Zhao wrote: > ACPI 6.0 introduces a new table STAO to list the devices which are used > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical > UART is used by Xen. So here it hides UART from Dom0. > > CC: "Rafael J. Wysocki"

Re: [PATCH 1/1] Btrfs: Code Cleanup

On Sun, Mar 20, 2016 at 03:11:11PM +0800, Flex Liu wrote: > From: Flex Liu > > In fs/btrfs/volumes.c:2328 > > if (seeding_dev) { > sb->s_flags &= ~MS_RDONLY; > ret = btrfs_prepare_sprout(root); > BUG_ON(ret); /* -ENOMEM */ >

Re: [PATCH 1/1] Btrfs: Code Cleanup

On Sun, Mar 20, 2016 at 03:11:11PM +0800, Flex Liu wrote: > From: Flex Liu > > In fs/btrfs/volumes.c:2328 > > if (seeding_dev) { > sb->s_flags &= ~MS_RDONLY; > ret = btrfs_prepare_sprout(root); > BUG_ON(ret); /* -ENOMEM */ > } > >

[PATCH] MIPS: ath79: make bootconsole wait for both THRE and TEMT

This makes the ath79 bootconsole behave the same way as the generic 8250 bootconsole. Also waiting for TEMT (transmit buffer is empty) instead of just THRE (transmit buffer is not full) ensures that all characters have been transmitted before the real serial driver starts reconfiguring the serial

[PATCH] MIPS: ath79: make bootconsole wait for both THRE and TEMT

This makes the ath79 bootconsole behave the same way as the generic 8250 bootconsole. Also waiting for TEMT (transmit buffer is empty) instead of just THRE (transmit buffer is not full) ensures that all characters have been transmitted before the real serial driver starts reconfiguring the serial

[PATCH 06/13] eeprom: at24: add serial number flag

In preparation for supporting the at24cs EEPROM series add a new flag to platform data. When set, it should tell the driver that the chip has an additional read-only memory area that holds a factory pre-programmed serial number. Signed-off-by: Bartosz Golaszewski ---

[PATCH 06/13] eeprom: at24: add serial number flag

In preparation for supporting the at24cs EEPROM series add a new flag to platform data. When set, it should tell the driver that the chip has an additional read-only memory area that holds a factory pre-programmed serial number. Signed-off-by: Bartosz Golaszewski ---

[PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen

ACPI 6.0 introduces a new table STAO to list the devices which are used by Xen and can't be used by Dom0. On Xen virtual platforms, the physical UART is used by Xen. So here it hides UART from Dom0. CC: "Rafael J. Wysocki" (supporter:ACPI) CC: Len Brown

[PATCH v7 01/17] Xen: ACPI: Hide UART used by Xen

ACPI 6.0 introduces a new table STAO to list the devices which are used by Xen and can't be used by Dom0. On Xen virtual platforms, the physical UART is used by Xen. So here it hides UART from Dom0. CC: "Rafael J. Wysocki" (supporter:ACPI) CC: Len Brown (supporter:ACPI) CC:

Re: [PATCH 2/4 v3] drm: Add DT bindings documentation for ARC PGU display controller

Hi Rob, On Mon, 2016-03-21 at 08:04 -0500, Rob Herring wrote: > On Fri, Mar 11, 2016 at 06:42:37PM +0300, Alexey Brodkin wrote: > > > > This add DT bindings documentation for ARC PGU display controller. > > > > Signed-off-by: Alexey Brodkin > > Cc: Rob Herring

Re: [PATCH 2/4 v3] drm: Add DT bindings documentation for ARC PGU display controller

Hi Rob, On Mon, 2016-03-21 at 08:04 -0500, Rob Herring wrote: > On Fri, Mar 11, 2016 at 06:42:37PM +0300, Alexey Brodkin wrote: > > > > This add DT bindings documentation for ARC PGU display controller. > > > > Signed-off-by: Alexey Brodkin > > Cc: Rob Herring > > Cc: Pawel Moll > > Cc: Mark

[PATCH 00/13] eeprom: support for at24cs and at24mac

Chips from the at24cs EEPROM series have an additional read-only memory area containing a factory pre-programmed serial number. In order to access it, a dummy write must be executed before reading the serial number bytes. Chips from the at24mac familiy, apart from the serial number, have a second

[PATCH 02/13] eeprom: at24: improve the device_id table readability

As part of the preparation for introducing support for more chips, improve the readability of the device table by separating columns with tabs. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 28 ++-- 1 file changed, 14

[PATCH 00/13] eeprom: support for at24cs and at24mac

Chips from the at24cs EEPROM series have an additional read-only memory area containing a factory pre-programmed serial number. In order to access it, a dummy write must be executed before reading the serial number bytes. Chips from the at24mac familiy, apart from the serial number, have a second

[PATCH 02/13] eeprom: at24: improve the device_id table readability

As part of the preparation for introducing support for more chips, improve the readability of the device table by separating columns with tabs. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-)

[PATCH 04/13] eeprom: at24: make locking more fine-grained

The only field in struct at24_data that needs locking in the module code is u8 *writebuf. Other data is already protected by i2c core. Rename the lock in at24_data to wrbuf_lock and only use it where writebuf is accessed. Signed-off-by: Bartosz Golaszewski ---

Re: [PATCH 0/2] hid: corsair: Driver simplification and new supported device

On Thu, 24 Mar 2016, Benjamin Tissoires wrote: > I would say you can not do this this way. Even if you believe you are the > only user of the API, there might be someone who uses it, and you will end > up breaking his keyboard. > > Jiri will correct me, but the proper way to follow is to mark

Re: [REGRESSION] panic with Wacom One Tablet on 4.4.x kernel

On Mar 24 2016 or thereabouts, Jiri Kosina wrote: > On Wed, 16 Mar 2016, Ping Cheng wrote: > > > Yes, please provide a bisect report so we get a clue. > > > > I do not have a "Wacom One". I have a Wacom Bamboo Pen, which goes > > through the same code base as "Wacom One". I tested kernel 4.4.4.

[PATCH v7 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table

Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't rely on DT or ACPI to pass the start address and size of grant table. Signed-off-by: Shannon Zhao Acked-by: Stefano Stabellini --- arch/arm/xen/enlighten.c | 13

[PATCH 04/13] eeprom: at24: make locking more fine-grained

The only field in struct at24_data that needs locking in the module code is u8 *writebuf. Other data is already protected by i2c core. Rename the lock in at24_data to wrbuf_lock and only use it where writebuf is accessed. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 28

Re: [PATCH 0/2] hid: corsair: Driver simplification and new supported device

On Thu, 24 Mar 2016, Benjamin Tissoires wrote: > I would say you can not do this this way. Even if you believe you are the > only user of the API, there might be someone who uses it, and you will end > up breaking his keyboard. > > Jiri will correct me, but the proper way to follow is to mark

Re: [REGRESSION] panic with Wacom One Tablet on 4.4.x kernel

On Mar 24 2016 or thereabouts, Jiri Kosina wrote: > On Wed, 16 Mar 2016, Ping Cheng wrote: > > > Yes, please provide a bisect report so we get a clue. > > > > I do not have a "Wacom One". I have a Wacom Bamboo Pen, which goes > > through the same code base as "Wacom One". I tested kernel 4.4.4.

[PATCH v7 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table

Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't rely on DT or ACPI to pass the start address and size of grant table. Signed-off-by: Shannon Zhao Acked-by: Stefano Stabellini --- arch/arm/xen/enlighten.c | 13 - 1 file changed, 4 insertions(+), 9

[PATCH 03/13] eeprom: at24: platform_data: use BIT() macro

Use BIT() macro to replace the 0xXX constants in platform_data flags definitions. Signed-off-by: Bartosz Golaszewski --- include/linux/platform_data/at24.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/platform_data/at24.h

[PATCH 03/13] eeprom: at24: platform_data: use BIT() macro

Use BIT() macro to replace the 0xXX constants in platform_data flags definitions. Signed-off-by: Bartosz Golaszewski --- include/linux/platform_data/at24.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/platform_data/at24.h

Re: [ppdev] e7223f1860: kernel BUG at drivers/base/driver.c:153!

On Mon 2016-02-15 17:20:01, Sudip Mukherjee wrote: > On Mon, Feb 15, 2016 at 04:20:45PM +0800, kernel test robot wrote: > > Greetings, > > > > 0day kernel testing robot got the below dmesg and the first bad commit is > > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git >

Re: [ppdev] e7223f1860: kernel BUG at drivers/base/driver.c:153!

On Mon 2016-02-15 17:20:01, Sudip Mukherjee wrote: > On Mon, Feb 15, 2016 at 04:20:45PM +0800, kernel test robot wrote: > > Greetings, > > > > 0day kernel testing robot got the below dmesg and the first bad commit is > > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git >

[PATCH v7 00/17] Add ACPI support for Xen Dom0 on ARM64

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI information. Introduce a bus notifier of AMBA and Platform bus to map the new added device's

[PATCH v7 00/17] Add ACPI support for Xen Dom0 on ARM64

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI information. Introduce a bus notifier of AMBA and Platform bus to map the new added device's

[PATCH 1/3] atomic: Introduce atomic_fetch_or

This is deemed to replace the type generic fetch_or() which brings a lot of issues such as macro induced block variable aliasing and sloppy types. Not to mention fetch_or() doesn't refer to any namespace, adding even more confusion. So lets provide an atomic_t version. Current and next users of

[PATCH 1/3] atomic: Introduce atomic_fetch_or

This is deemed to replace the type generic fetch_or() which brings a lot of issues such as macro induced block variable aliasing and sloppy types. Not to mention fetch_or() doesn't refer to any namespace, adding even more confusion. So lets provide an atomic_t version. Current and next users of

Re: [RFC 0/6] drm/fences: add in-fences to DRM

Hi Inki, 2016-03-24 Inki Dae : > Hi, > > 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글: > > From: Gustavo Padovan > > > > Hi, > > > > This is a first proposal to discuss the addition of in-fences support > > to DRM. It adds a new struct to

Re: [RFC 0/6] drm/fences: add in-fences to DRM

Hi Inki, 2016-03-24 Inki Dae : > Hi, > > 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글: > > From: Gustavo Padovan > > > > Hi, > > > > This is a first proposal to discuss the addition of in-fences support > > to DRM. It adds a new struct to fence.c to abstract the use of sync_file > > in DRM

[PATCH 05/13] eeprom: at24: replace msleep() with usleep_range()

We cannot expect msleep(1) to actually sleep for a period shorter than 20 ms. Replace all calls to msleep() with usleep_range(). Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[PATCH 05/13] eeprom: at24: replace msleep() with usleep_range()

We cannot expect msleep(1) to actually sleep for a period shorter than 20 ms. Replace all calls to msleep() with usleep_range(). Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/misc/eeprom/at24.c

[PATCH 1/1] net: macb: replace macb_writel() call by queue_writel() to update queue ISR

macb_interrupt() should not use macb_writel(bp, ISR, ) but only queue_writel(queue, ISR, ). There is one IRQ and one set of {ISR, IER, IDR, IMR} [1] registers per queue on gem hardware, though only queue0 is actually used for now to receive frames: other queues can already be used to transmit

[PATCH 1/1] net: macb: replace macb_writel() call by queue_writel() to update queue ISR

macb_interrupt() should not use macb_writel(bp, ISR, ) but only queue_writel(queue, ISR, ). There is one IRQ and one set of {ISR, IER, IDR, IMR} [1] registers per queue on gem hardware, though only queue0 is actually used for now to receive frames: other queues can already be used to transmit

[PATCH 09/13] eeprom: at24: use at24cs_serial_read()

Assign at24cs_serial_read() to at24->read_func if the chip allows serial number read operation. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git

[PATCH 11/13] eeprom: at24: add at24mac series flag

As part of supporting the at24mac series add a new flag to the at24 platform data. When set, it indicates that this chip exposes the factory-programmed EUI-48 or EUI-64 address. Signed-off-by: Bartosz Golaszewski --- include/linux/platform_data/at24.h | 1 + 1 file

Re: [PATCH 1/1] net: macb: remove BUG_ON() and reset the queue to handle RX errors

On 03/24/2016 03:37 PM, Cyrille Pitchen wrote: > This patch removes two BUG_ON() used to notify about RX queue corruptions > on macb (not gem) hardware without actually handling the error. > > The new code skips corrupted frames but still processes faultless frames. > Then it resets the RX queue

[PATCH 12/13] eeprom: at24: add support for at24mac series

Add a new read function to the at24 driver allowing to retrieve the factory-programmed mac address embedded in chips from the at24mac family. These chips can be instantiated similarily to the at24cs family, except that there's no way of having access to both the serial number and the mac address

Re: [PATCH] mmc: Provide tracepoints for request processing

Hi Baolin, [auto build test ERROR on ulf.hansson-mmc/next] [also build test ERROR on v4.5 next-20160324] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Baolin-Wang/mmc-Provide-tracepoints

[PATCH 07/13] eeprom: at24: support reading of the serial number

The at24cs series EEPROM chips have an additional read-only memory area containing a factory pre-programmed serial number. In order to access it, one has to perform a dummy write before reading the serial number bytes. Add a function that allows to access the serial number. Signed-off-by:

[PATCH 09/13] eeprom: at24: use at24cs_serial_read()

Assign at24cs_serial_read() to at24->read_func if the chip allows serial number read operation. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/misc/eeprom/at24.c

[PATCH 11/13] eeprom: at24: add at24mac series flag

As part of supporting the at24mac series add a new flag to the at24 platform data. When set, it indicates that this chip exposes the factory-programmed EUI-48 or EUI-64 address. Signed-off-by: Bartosz Golaszewski --- include/linux/platform_data/at24.h | 1 + 1 file changed, 1 insertion(+) diff

Re: [PATCH 1/1] net: macb: remove BUG_ON() and reset the queue to handle RX errors

On 03/24/2016 03:37 PM, Cyrille Pitchen wrote: > This patch removes two BUG_ON() used to notify about RX queue corruptions > on macb (not gem) hardware without actually handling the error. > > The new code skips corrupted frames but still processes faultless frames. > Then it resets the RX queue

[PATCH 12/13] eeprom: at24: add support for at24mac series

Add a new read function to the at24 driver allowing to retrieve the factory-programmed mac address embedded in chips from the at24mac family. These chips can be instantiated similarily to the at24cs family, except that there's no way of having access to both the serial number and the mac address

Re: [PATCH] mmc: Provide tracepoints for request processing

Hi Baolin, [auto build test ERROR on ulf.hansson-mmc/next] [also build test ERROR on v4.5 next-20160324] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Baolin-Wang/mmc-Provide-tracepoints

[PATCH 07/13] eeprom: at24: support reading of the serial number

The at24cs series EEPROM chips have an additional read-only memory area containing a factory pre-programmed serial number. In order to access it, one has to perform a dummy write before reading the serial number bytes. Add a function that allows to access the serial number. Signed-off-by:

[PATCH 08/13] eeprom: at24: call read and write routines via function pointers

In order to support non-standard read/write functions (as part of the at24cs series support) introduce two function pointers in struct at24_data to which different implementations can be assigned. For now we continue to use the regular read/write routines by default. Signed-off-by: Bartosz

[PATCH 01/13] eeprom: at24: remove a reduntant if

It seems as if the second check for I2C_FUNC_I2C functionality had been introduced accidentally during a merge. Tt's reduntant, so remove it. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH 10/13] eeprom: at24: add the at24cs series to the list of supported devices

The infrastructure for reading of the factory-programmed serial number for at24cs EEPROM series is now in place. Add the chips that are actually equipped with the serial number memory area to the list of supported devices. The chips from the at24cs family have two memory areas - a regular

[PATCH 10/13] eeprom: at24: add the at24cs series to the list of supported devices

The infrastructure for reading of the factory-programmed serial number for at24cs EEPROM series is now in place. Add the chips that are actually equipped with the serial number memory area to the list of supported devices. The chips from the at24cs family have two memory areas - a regular

[PATCH 01/13] eeprom: at24: remove a reduntant if

It seems as if the second check for I2C_FUNC_I2C functionality had been introduced accidentally during a merge. Tt's reduntant, so remove it. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/misc/eeprom/at24.c

[PATCH 08/13] eeprom: at24: call read and write routines via function pointers

In order to support non-standard read/write functions (as part of the at24cs series support) introduce two function pointers in struct at24_data to which different implementations can be assigned. For now we continue to use the regular read/write routines by default. Signed-off-by: Bartosz

Re: [PATCH 0/2] hid: corsair: Driver simplification and new supported device

Hi Clément, On Mar 23 2016 or thereabouts, =?UTF-8?q?Cl=C3=A9ment=20Vuchener?= wrote: > I tried to add support for the K40 some time ago, but the vendor specific USB > protocol became over-complicated because of a lot of small differences > between the K90 and the K40. Also, since I wrote the

Re: [PATCH v5 00/21] PM / devferq: Add generic exynos bus frequency driver and new passive governor

Hi Chanwoo, Am 24.03.2016 um 05:25 schrieb Chanwoo Choi: > Dear all, > > This patchset uses the DEVFREQ_TRANSITION_NOTIFIER notifier to connecth > devfreq device using ondemand governor and devfreq device using passive > governor. Also I fix the some issue reported by 'Tobias Jakobi' and add the

[PATCH 3/3] Revert "atomic: Export fetch_or()"

This reverts commit 5fd7a09cfb8c6852f596c1f8c891c6158395250e. Now that we have introduced atomic_fetch_or(), fetch_or() is only used by the scheduler in order to deal with thread_info flags which type can vary across architectures. Lets confine fetch_or() back to the scheduler so that we

[PATCH 2/3] nohz: Convert tick dependency mask to atomic_t

The tick dependency mask was intially unsigned long because this is the type on which clear_bit() operates on and fetch_or() accepts it. But now that we have atomic_fetch_or(), we can instead use atomic_andnot() to clear the bit. This consolidates the type of our tick dependency mask, reduce its

Re: [REGRESSION] panic with Wacom One Tablet on 4.4.x kernel

On Thu, 24 Mar 2016, Jiri Kosina wrote: > > Yes, please provide a bisect report so we get a clue. > > > > I do not have a "Wacom One". I have a Wacom Bamboo Pen, which goes > > through the same code base as "Wacom One". I tested kernel 4.4.4. I > > don't see the issue. > > Laura, do we have

[PATCH 0/3] nohz: Convert tick dependency mask to atomic_t

As per Linus suggestion, lets convert the tick dependency mask to atomic_t. Introduce atomic_fetch_or() and confine fetch_or() back to scheduler guts. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git timers/nohz HEAD: 7b7e5da5733f58668181077ec394a718e08c392c

Re: [PATCH 0/2] hid: corsair: Driver simplification and new supported device

Hi Clément, On Mar 23 2016 or thereabouts, =?UTF-8?q?Cl=C3=A9ment=20Vuchener?= wrote: > I tried to add support for the K40 some time ago, but the vendor specific USB > protocol became over-complicated because of a lot of small differences > between the K90 and the K40. Also, since I wrote the

Re: [PATCH v5 00/21] PM / devferq: Add generic exynos bus frequency driver and new passive governor

Hi Chanwoo, Am 24.03.2016 um 05:25 schrieb Chanwoo Choi: > Dear all, > > This patchset uses the DEVFREQ_TRANSITION_NOTIFIER notifier to connecth > devfreq device using ondemand governor and devfreq device using passive > governor. Also I fix the some issue reported by 'Tobias Jakobi' and add the

[PATCH 3/3] Revert "atomic: Export fetch_or()"

This reverts commit 5fd7a09cfb8c6852f596c1f8c891c6158395250e. Now that we have introduced atomic_fetch_or(), fetch_or() is only used by the scheduler in order to deal with thread_info flags which type can vary across architectures. Lets confine fetch_or() back to the scheduler so that we

[PATCH 2/3] nohz: Convert tick dependency mask to atomic_t

The tick dependency mask was intially unsigned long because this is the type on which clear_bit() operates on and fetch_or() accepts it. But now that we have atomic_fetch_or(), we can instead use atomic_andnot() to clear the bit. This consolidates the type of our tick dependency mask, reduce its

Re: [REGRESSION] panic with Wacom One Tablet on 4.4.x kernel

On Thu, 24 Mar 2016, Jiri Kosina wrote: > > Yes, please provide a bisect report so we get a clue. > > > > I do not have a "Wacom One". I have a Wacom Bamboo Pen, which goes > > through the same code base as "Wacom One". I tested kernel 4.4.4. I > > don't see the issue. > > Laura, do we have

[PATCH 0/3] nohz: Convert tick dependency mask to atomic_t

As per Linus suggestion, lets convert the tick dependency mask to atomic_t. Introduce atomic_fetch_or() and confine fetch_or() back to scheduler guts. git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git timers/nohz HEAD: 7b7e5da5733f58668181077ec394a718e08c392c

Re: Warnings for invalid VDD (sdhci-s3c)

On 24/03/16 16:03, Ludovic Desroches wrote: > Hi, > > On Thu, Mar 24, 2016 at 03:11:25PM +0200, Adrian Hunter wrote: >> On 24/03/16 10:42, Krzysztof Kozlowski wrote: >>> On 24.03.2016 17:24, Jisheng Zhang wrote: Hi, On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote: >

Re: Warnings for invalid VDD (sdhci-s3c)

On 24/03/16 16:03, Ludovic Desroches wrote: > Hi, > > On Thu, Mar 24, 2016 at 03:11:25PM +0200, Adrian Hunter wrote: >> On 24/03/16 10:42, Krzysztof Kozlowski wrote: >>> On 24.03.2016 17:24, Jisheng Zhang wrote: Hi, On Thu, 24 Mar 2016 17:09:27 +0900 Jaehoon Chung wrote: >

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