[PATCH v3 1/2] befs: remove unused BEFS_BT_PARMATCH

befs_btree_find(), the only caller of befs_find_key(), only cares about if the return from that function is BEFS_BT_MATCH or not. It never uses the partial match given with BEFS_BT_PARMATCH. Make the overflow return clearer by having BEFS_BT_OVERFLOW instead of BEFS_BT_PARMATCH. Signed-off-by:

[PATCH v3 1/2] befs: remove unused BEFS_BT_PARMATCH

befs_btree_find(), the only caller of befs_find_key(), only cares about if the return from that function is BEFS_BT_MATCH or not. It never uses the partial match given with BEFS_BT_PARMATCH. Make the overflow return clearer by having BEFS_BT_OVERFLOW instead of BEFS_BT_PARMATCH. Signed-off-by:

Re: Build regressions/improvements in v4.8-rc1

On Mon, Aug 08, 2016 at 10:38:07AM +0200, Geert Uytterhoeven wrote: > On Mon, Aug 8, 2016 at 10:32 AM, Geert Uytterhoeven > wrote: > > Below is the list of build error/warning regressions/improvements in > > v4.8-rc1[1] compared to v4.7[2]. > > > > Summarized: > > - build

Re: Build regressions/improvements in v4.8-rc1

On Mon, Aug 08, 2016 at 10:38:07AM +0200, Geert Uytterhoeven wrote: > On Mon, Aug 8, 2016 at 10:32 AM, Geert Uytterhoeven > wrote: > > Below is the list of build error/warning regressions/improvements in > > v4.8-rc1[1] compared to v4.7[2]. > > > > Summarized: > > - build errors: +8/-12 > > >

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On 08/08/2016 07:13 AM, Daniel Thompson wrote: On 04/08/16 05:47, David Long wrote: From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001 From: "David A. Long" Date: Thu, 4 Aug 2016 00:35:33 -0400 Subject: [PATCH] arm64: Remove stack duplicating code from

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On 08/08/2016 07:13 AM, Daniel Thompson wrote: On 04/08/16 05:47, David Long wrote: From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001 From: "David A. Long" Date: Thu, 4 Aug 2016 00:35:33 -0400 Subject: [PATCH] arm64: Remove stack duplicating code from jprobes Because the

[PATCH v3 2/2] befs: fix typo in befs_find_key

Fixing skeep to skip. Signed-off-by: Luis de Bethencourt --- v3: no change fs/befs/btree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/befs/btree.c b/fs/befs/btree.c index 27b0336..54a1f95 100644 --- a/fs/befs/btree.c +++ b/fs/befs/btree.c @@

[PATCH v3 2/2] befs: fix typo in befs_find_key

Fixing skeep to skip. Signed-off-by: Luis de Bethencourt --- v3: no change fs/befs/btree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/befs/btree.c b/fs/befs/btree.c index 27b0336..54a1f95 100644 --- a/fs/befs/btree.c +++ b/fs/befs/btree.c @@ -344,7 +344,7 @@

Re: [PATCH 10/10] fault injection: inject faults in new/rare callchains

Hi, On 08/08/2016 03:54 PM, Akinobu Mita wrote: 2016-08-04 0:05 GMT+09:00 Vegard Nossum : Before this patch, fault injection uses a combination of randomness and frequency to determine where to inject faults. The problem with this is that code paths which are executed

Re: [PATCH 10/10] fault injection: inject faults in new/rare callchains

Hi, On 08/08/2016 03:54 PM, Akinobu Mita wrote: 2016-08-04 0:05 GMT+09:00 Vegard Nossum : Before this patch, fault injection uses a combination of randomness and frequency to determine where to inject faults. The problem with this is that code paths which are executed very rarely get

[PATCH 4/4] serial: imx-serial - update RX error counters when DMA is used

Update error counters when DMA is used for receiving data. Do this by using DMA transaction error event instead error interrupts to reduce interrupt load. Tested-by: Peter Senna Tschudin Acked-by: Peter Senna Tschudin Signed-off-by: Nandor

[PATCH 4/4] serial: imx-serial - update RX error counters when DMA is used

Update error counters when DMA is used for receiving data. Do this by using DMA transaction error event instead error interrupts to reduce interrupt load. Tested-by: Peter Senna Tschudin Acked-by: Peter Senna Tschudin Signed-off-by: Nandor Han --- drivers/tty/serial/imx.c | 32

Re: [PATCH 3/3] ARM: dts: imx6sx-udoo-neo: Add SD

On Tue, Jul 05, 2016 at 06:04:10AM +0200, Andreas Färber wrote: > Enable the SDHC node and model the SDIO_PWR GPIO as a regulator. > Use the SD card as default trigger for the red LED. > > Cc: Ettore Chimenti > Signed-off-by: Andreas Färber > --- >

Re: [PATCH 3/3] ARM: dts: imx6sx-udoo-neo: Add SD

On Tue, Jul 05, 2016 at 06:04:10AM +0200, Andreas Färber wrote: > Enable the SDHC node and model the SDIO_PWR GPIO as a regulator. > Use the SD card as default trigger for the red LED. > > Cc: Ettore Chimenti > Signed-off-by: Andreas Färber > --- > > > arch/arm/boot/dts/imx6sx-udoo-neo.dtsi

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 03:06:33PM +0200, Kurt Van Dijck wrote: > > --- Original message --- > > Date: Mon, 8 Aug 2016 14:28:39 +0200 > > From: Wolfgang Grandegger > > > [...] > > >>>+ > > >>>+if (!(cf->can_id & CAN_RTR_FLAG)) { > > >>>+

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 03:06:33PM +0200, Kurt Van Dijck wrote: > > --- Original message --- > > Date: Mon, 8 Aug 2016 14:28:39 +0200 > > From: Wolfgang Grandegger > > > [...] > > >>>+ > > >>>+if (!(cf->can_id & CAN_RTR_FLAG)) { > > >>>+writel(data[0],

Re: [PATCH] ASoC: simple-card: fix module load "unknown symbol" issue

On Tuesday 02 August 2016 05:06 AM, Kevin Hilman wrote: > An ASoC driver using simple-card, when built as a module gets the > following error at module load time: > > [ 23.571873] simple_card_utils: Unknown symbol snd_soc_of_parse_daifmt (err > 0) > [ 23.712726] simple_card_utils: Unknown

Re: [PATCH] ASoC: simple-card: fix module load "unknown symbol" issue

On Tuesday 02 August 2016 05:06 AM, Kevin Hilman wrote: > An ASoC driver using simple-card, when built as a module gets the > following error at module load time: > > [ 23.571873] simple_card_utils: Unknown symbol snd_soc_of_parse_daifmt (err > 0) > [ 23.712726] simple_card_utils: Unknown

Re: [RESEND v5] mtd: nand_bbt: scan for next free bbt block if writing bbt fails

Hi Kyle, On Tue, 2 Aug 2016 15:01:50 -0500 Kyle Roeschley wrote: > If erasing or writing the BBT fails, we should mark the current BBT > block as bad and use the BBT descriptor to scan for the next available > unused block in the BBT. We should only return a failure if

Re: [RESEND v5] mtd: nand_bbt: scan for next free bbt block if writing bbt fails

Hi Kyle, On Tue, 2 Aug 2016 15:01:50 -0500 Kyle Roeschley wrote: > If erasing or writing the BBT fails, we should mark the current BBT > block as bad and use the BBT descriptor to scan for the next available > unused block in the BBT. We should only return a failure if there isn't > any space

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote: > Hello, > > Am 08.08.2016 um 13:39 schrieb Andreas Werner: > >On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote: > >>Hello Andreas, > >> > >>a first quick review > >> > >>Am 26.07.2016 um 11:16 schrieb

Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver

On Mon, Aug 08, 2016 at 02:28:39PM +0200, Wolfgang Grandegger wrote: > Hello, > > Am 08.08.2016 um 13:39 schrieb Andreas Werner: > >On Mon, Aug 08, 2016 at 11:27:25AM +0200, Wolfgang Grandegger wrote: > >>Hello Andreas, > >> > >>a first quick review > >> > >>Am 26.07.2016 um 11:16 schrieb

[PATCH 2/4] dmaengine: imx-sdma - update the residue calculation for cyclic channels

The calculation of the DMA transaction residue supports only fixed size data transfers. This implementation is not covering all operations (e.g. data receiving) when we need to know the exact amount of bytes transferred. The loop channels handling was changed to clear the buffer descriptor errors

[PATCH 2/4] dmaengine: imx-sdma - update the residue calculation for cyclic channels

The calculation of the DMA transaction residue supports only fixed size data transfers. This implementation is not covering all operations (e.g. data receiving) when we need to know the exact amount of bytes transferred. The loop channels handling was changed to clear the buffer descriptor errors

[RFD] I/O scheduling in blk-mq

Hi Jens, Tejun, Christoph, all, AFAIK blk-mq does not yet feature I/O schedulers. In particular, there is no scheduler providing strong guarantees in terms of responsiveness, latency for time-sensitive applications and bandwidth distribution. For this reason, I'm trying to port BFQ to blk-mq, or

[RFD] I/O scheduling in blk-mq

Hi Jens, Tejun, Christoph, all, AFAIK blk-mq does not yet feature I/O schedulers. In particular, there is no scheduler providing strong guarantees in terms of responsiveness, latency for time-sensitive applications and bandwidth distribution. For this reason, I'm trying to port BFQ to blk-mq, or

Re: WARNING: CPU: 0 PID: 1271 at drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8

Hi, John Do you have a procedure to reproduce this? I set up my HiKey with v4.8-rc1 (official) and run for a while reading/writing SD card. But I didn't see that warning. -Guodong On 5 August 2016 at 12:52, John Stultz wrote: > Hey Ulf, > Since moving my HiKey branch

Re: WARNING: CPU: 0 PID: 1271 at drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8

Hi, John Do you have a procedure to reproduce this? I set up my HiKey with v4.8-rc1 (official) and run for a while reading/writing SD card. But I didn't see that warning. -Guodong On 5 August 2016 at 12:52, John Stultz wrote: > Hey Ulf, > Since moving my HiKey branch to pre-v4.8-rc1

Re: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support

On Tue, Jul 05, 2016 at 06:04:09AM +0200, Andreas Färber wrote: > + { > + status = "okay"; > + phy-handle = <>; We generally have 'status' at the bottom of property list. Shawn > + > + mdio { > + #address-cells = <1>; > + #size-cells = <0>; > + > +

Re: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support

On Tue, Jul 05, 2016 at 06:04:09AM +0200, Andreas Färber wrote: > + { > + status = "okay"; > + phy-handle = <>; We generally have 'status' at the bottom of property list. Shawn > + > + mdio { > + #address-cells = <1>; > + #size-cells = <0>; > + > +

Re: [RFC PATCH 3/4] Make deadline max-heap faster avoiding real swaps on heapify ops.

On Tue, Jul 19, 2016 at 11:44:52AM +0200, Tommaso Cucinotta wrote: > This change achieves up to 10% of speed-up for cpudl_set() calls, as > measured with a andomly generated workload of 1K,10K,100K random heap > insertions and deletions (75% cpudl_set() calls with is_valid=1 and > 25% with

Re: [RFC PATCH 3/4] Make deadline max-heap faster avoiding real swaps on heapify ops.

On Tue, Jul 19, 2016 at 11:44:52AM +0200, Tommaso Cucinotta wrote: > This change achieves up to 10% of speed-up for cpudl_set() calls, as > measured with a andomly generated workload of 1K,10K,100K random heap > insertions and deletions (75% cpudl_set() calls with is_valid=1 and > 25% with

Re: [PATCH 1/2] sc16is7xx: Do not handle irqs in endless loop

2016-08-08 15:43 GMT+02:00 Greg KH : > On Mon, Aug 08, 2016 at 03:32:15PM +0200, dirk.eib...@gdsys.cc wrote: >> From: Dirk Eibach >> >> sc16is7xx_port_irq() is laid out as an endless loop. It will exit only >> when there is no more interrupt left

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-08-08 at 14:44 +0200, Bjørn Mork wrote: > Oliver Neukum writes: > > I don't see how it would be specific for a subsystem. If the patch > > is correct, it belongs into the networking core. > > The bug is in the firmware implementation of the "read unique vendor >

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, 2016-08-08 at 14:44 +0200, Bjørn Mork wrote: > Oliver Neukum writes: > > I don't see how it would be specific for a subsystem. If the patch > > is correct, it belongs into the networking core. > > The bug is in the firmware implementation of the "read unique vendor > assigned mac

Re: [PATCH 1/2] sc16is7xx: Do not handle irqs in endless loop

2016-08-08 15:43 GMT+02:00 Greg KH : > On Mon, Aug 08, 2016 at 03:32:15PM +0200, dirk.eib...@gdsys.cc wrote: >> From: Dirk Eibach >> >> sc16is7xx_port_irq() is laid out as an endless loop. It will exit only >> when there is no more interrupt left to service. This not common >> practice. >> In our

Re: [PATCH 2/6] mfd: as3722: Make it explicitly non-modular

[Re: [PATCH 2/6] mfd: as3722: Make it explicitly non-modular] On 08/08/2016 (Mon 10:14) Lee Jones wrote: > On Fri, 05 Aug 2016, Paul Gortmaker wrote: D> [...] > > > > > > > > ...so I'll drop this patch in favour of the one line tristate > > > > conversion in v2. > > > > > > Did you ever get

Re: [PATCH 2/6] mfd: as3722: Make it explicitly non-modular

[Re: [PATCH 2/6] mfd: as3722: Make it explicitly non-modular] On 08/08/2016 (Mon 10:14) Lee Jones wrote: > On Fri, 05 Aug 2016, Paul Gortmaker wrote: D> [...] > > > > > > > > ...so I'll drop this patch in favour of the one line tristate > > > > conversion in v2. > > > > > > Did you ever get

Re: [PATCH 1/3] ARM: dts: imx6sx-sabreauto: Fix misspelled property

On Tue, Jul 05, 2016 at 06:04:08AM +0200, Andreas Färber wrote: > In commit 99fc5ba0bfb6 ("ARM: dts: imx6sx: add i.mx6sx sabreauto board > support") it should've been enable-sdio-wakeup (not -wakup). But that is > now considered a legacy name for wakeup-source, so directly use the new > name

Re: [PATCH 1/3] ARM: dts: imx6sx-sabreauto: Fix misspelled property

On Tue, Jul 05, 2016 at 06:04:08AM +0200, Andreas Färber wrote: > In commit 99fc5ba0bfb6 ("ARM: dts: imx6sx: add i.mx6sx sabreauto board > support") it should've been enable-sdio-wakeup (not -wakup). But that is > now considered a legacy name for wakeup-source, so directly use the new > name

[PATCH] gpio: max730x: set gpiochip data pointeur before using it

gpiochip_add_data() has to be called before calling max7301_direction_input() [4.389883] Unable to handle kernel paging request for data at address 0x0018 [4.397282] Faulting instruction address: 0xc01a8cbc [4.402023] Oops: Kernel access of bad area, sig: 11 [#1] [4.407331]

[PATCH] gpio: max730x: set gpiochip data pointeur before using it

gpiochip_add_data() has to be called before calling max7301_direction_input() [4.389883] Unable to handle kernel paging request for data at address 0x0018 [4.397282] Faulting instruction address: 0xc01a8cbc [4.402023] Oops: Kernel access of bad area, sig: 11 [#1] [4.407331]

Re: [PATCH v2 6/6] dmaengine: omap-dma: Support for LinkedList transfer of slave_sg

On 08/08/16 08:42, Vinod Koul wrote: > On Wed, Jul 20, 2016 at 11:50:32AM +0300, Peter Ujfalusi wrote: >> sDMA in OMAP3630 or newer SoC have support for LinkedList transfer. When >> LinkedList or Descriptor load feature is present we can create the >> descriptors for each and program sDMA to walk

Re: [PATCH v2 6/6] dmaengine: omap-dma: Support for LinkedList transfer of slave_sg

On 08/08/16 08:42, Vinod Koul wrote: > On Wed, Jul 20, 2016 at 11:50:32AM +0300, Peter Ujfalusi wrote: >> sDMA in OMAP3630 or newer SoC have support for LinkedList transfer. When >> LinkedList or Descriptor load feature is present we can create the >> descriptors for each and program sDMA to walk

Re: [PATCH v6 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods

On Thu 2016-07-14 16:50:29, Chris Metcalf wrote: > Currently you can only request a backtrace of either all cpus, or > all cpus but yourself. It can also be helpful to request a remote > backtrace of a single cpu, and since we want that, the logical > extension is to support a cpumask as the

Re: [PATCH v6 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods

On Thu 2016-07-14 16:50:29, Chris Metcalf wrote: > Currently you can only request a backtrace of either all cpus, or > all cpus but yourself. It can also be helpful to request a remote > backtrace of a single cpu, and since we want that, the logical > extension is to support a cpumask as the

Re: [PATCH 2/3] EDAC, altera: Add Arria10 SD-MMC EDAC support

On 08/08/2016 08:36 AM, Borislav Petkov wrote: On Tue, Aug 02, 2016 at 10:56:20AM -0500, ttha...@opensource.altera.com wrote: From: Thor Thayer Add Altera Arria10 SD-MMC FIFO memory EDAC support. The SD-MMC is a dual port RAM implementation which is different

Re: [PATCH 2/3] EDAC, altera: Add Arria10 SD-MMC EDAC support

On 08/08/2016 08:36 AM, Borislav Petkov wrote: On Tue, Aug 02, 2016 at 10:56:20AM -0500, ttha...@opensource.altera.com wrote: From: Thor Thayer Add Altera Arria10 SD-MMC FIFO memory EDAC support. The SD-MMC is a dual port RAM implementation which is different than any of the other

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Mon, Aug 8, 2016 at 3:40 PM, Borislav Petkov wrote: > On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The low-level resume-from-hibernation code on x86-64 uses >> kernel_ident_mapping_init() to

Re: [PATCH 10/10] fault injection: inject faults in new/rare callchains

2016-08-04 0:05 GMT+09:00 Vegard Nossum : > Before this patch, fault injection uses a combination of randomness and > frequency to determine where to inject faults. The problem with this is > that code paths which are executed very rarely get proportional amounts > of

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Mon, Aug 8, 2016 at 3:40 PM, Borislav Petkov wrote: > On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The low-level resume-from-hibernation code on x86-64 uses >> kernel_ident_mapping_init() to create the temoprary identity mapping, >> but

Re: [PATCH 10/10] fault injection: inject faults in new/rare callchains

2016-08-04 0:05 GMT+09:00 Vegard Nossum : > Before this patch, fault injection uses a combination of randomness and > frequency to determine where to inject faults. The problem with this is > that code paths which are executed very rarely get proportional amounts > of faults injected. > > A better

linux-4.8-rc1/drivers/scsi/sd.c:317: pointless test ?

Hello there, linux-4.8-rc1/drivers/scsi/sd.c:317]: (style) Unsigned variable 'val' can't be negative so it is unnecessary to test it. Source code is if (val >= 0 && val <= SD_DIF_TYPE3_PROTECTION) but unsigned int val; Suggest new code if (val <= SD_DIF_TYPE3_PROTECTION) Regards

linux-4.8-rc1/drivers/scsi/sd.c:317: pointless test ?

Hello there, linux-4.8-rc1/drivers/scsi/sd.c:317]: (style) Unsigned variable 'val' can't be negative so it is unnecessary to test it. Source code is if (val >= 0 && val <= SD_DIF_TYPE3_PROTECTION) but unsigned int val; Suggest new code if (val <= SD_DIF_TYPE3_PROTECTION) Regards

Re: [PATCH 7/9] remoteproc: core: Add function to over-ride current resource table

Hi Lee On 08/04/2016 11:21 AM, Lee Jones wrote: Most of the new resource table handling function are now in place, so it's time to put it all together. Once new resource table information has been requested, the structures will be held in a holding pen until boot-time. During boot-time

Re: [PATCH 7/9] remoteproc: core: Add function to over-ride current resource table

Hi Lee On 08/04/2016 11:21 AM, Lee Jones wrote: Most of the new resource table handling function are now in place, so it's time to put it all together. Once new resource table information has been requested, the structures will be held in a holding pen until boot-time. During boot-time

[PATCH] w1: fix timeout_us parameter description

Fix 'timeout_us' parameter description. Signed-off-by: Wei Yongjun --- drivers/w1/w1.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index bb34362..e213c67 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -53,8

[PATCH] w1: fix timeout_us parameter description

Fix 'timeout_us' parameter description. Signed-off-by: Wei Yongjun --- drivers/w1/w1.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c index bb34362..e213c67 100644 --- a/drivers/w1/w1.c +++ b/drivers/w1/w1.c @@ -53,8 +53,8 @@ int

Re: [PATCH] iio: adc: at91: unbreak channel adc channel 3

On 08/08/2016 at 14:42:16 +0200, Anders Darander wrote : > The driver always assumes that an input device has been created when > reading channel 3. This causes a kernel panic when dereferencing > st->ts_input. > > The change was introduced in > commit 84882b060301 ("iio: adc: at91_adc: Add

Re: [PATCH] iio: adc: at91: unbreak channel adc channel 3

On 08/08/2016 at 14:42:16 +0200, Anders Darander wrote : > The driver always assumes that an input device has been created when > reading channel 3. This causes a kernel panic when dereferencing > st->ts_input. > > The change was introduced in > commit 84882b060301 ("iio: adc: at91_adc: Add

Re: [PATCH] sunrpc: Remove unnecessary variable

On 08/08/2016 05:13 AM, Amitoj Kaur Chawla wrote: > The variable `err` is not used anywhere and just returns the > predefined value `0` at the end of the function. Hence, remove the > variable and return 0 explicitly. Makes sense to me. Thanks! Anna > > Signed-off-by: Amitoj Kaur Chawla

Re: [PATCH] sunrpc: Remove unnecessary variable

On 08/08/2016 05:13 AM, Amitoj Kaur Chawla wrote: > The variable `err` is not used anywhere and just returns the > predefined value `0` at the end of the function. Hence, remove the > variable and return 0 explicitly. Makes sense to me. Thanks! Anna > > Signed-off-by: Amitoj Kaur Chawla >

[PATCH 2/2] sc16is7xx: Disable regmap cache

From: Dirk Eibach The regcache_cache_bypass() calls are not implemented to be threadsafe. Since I don't see the point in using a regmap cache on an UART interface it is better to disable it alltogether and avoid these problems. Signed-off-by: Dirk Eibach

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The low-level resume-from-hibernation code on x86-64 uses > kernel_ident_mapping_init() to create the temoprary identity mapping, > but that function assumes that the

[PATCH 2/2] sc16is7xx: Disable regmap cache

From: Dirk Eibach The regcache_cache_bypass() calls are not implemented to be threadsafe. Since I don't see the point in using a regmap cache on an UART interface it is better to disable it alltogether and avoid these problems. Signed-off-by: Dirk Eibach --- drivers/tty/serial/sc16is7xx.c |

Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly

On Mon, Aug 08, 2016 at 03:31:31PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The low-level resume-from-hibernation code on x86-64 uses > kernel_ident_mapping_init() to create the temoprary identity mapping, > but that function assumes that the offset between kernel virtual >

Re: [PATCH v6 2/3] mfd: lpc_ich: Rename lpc-ich driver

On Thu, 14 Jul 2016, Tan Jui Nee wrote: > This patch follows the example of mfd/wm831x to rename the driver > from "lpc_ich" to "lpc_ich-core". > > Signed-off-by: Tan Jui Nee > --- > Changes in V6: > - none, just a subject line and commit message change. > >

Re: [PATCH v6 2/3] mfd: lpc_ich: Rename lpc-ich driver

On Thu, 14 Jul 2016, Tan Jui Nee wrote: > This patch follows the example of mfd/wm831x to rename the driver > from "lpc_ich" to "lpc_ich-core". > > Signed-off-by: Tan Jui Nee > --- > Changes in V6: > - none, just a subject line and commit message change. > > drivers/mfd/Makefile

[PATCH 1/2] sc16is7xx: Do not handle irqs in endless loop

From: Dirk Eibach sc16is7xx_port_irq() is laid out as an endless loop. It will exit only when there is no more interrupt left to service. This not common practice. In our case it lead to some strange hangup situation when there was an unexpected XOFF-interrupt that could

[PATCH 1/2] sc16is7xx: Do not handle irqs in endless loop

From: Dirk Eibach sc16is7xx_port_irq() is laid out as an endless loop. It will exit only when there is no more interrupt left to service. This not common practice. In our case it lead to some strange hangup situation when there was an unexpected XOFF-interrupt that could not be handled. So let's

Re: [RFC][PATCH 0/4] SRAM based reboot reason driver for HiKey

Hi Rob, On 08/06/2016 01:37 AM, Rob Herring wrote: On Fri, Aug 5, 2016 at 7:46 AM, Vladimir Zapolskiy wrote: Hi John, On 08/04/2016 02:05 AM, John Stultz wrote: Now that Andy's reboot reason core driver has landed, I wanted to resubmit a reworked version of

Re: [RFC][PATCH 0/4] SRAM based reboot reason driver for HiKey

Hi Rob, On 08/06/2016 01:37 AM, Rob Herring wrote: On Fri, Aug 5, 2016 at 7:46 AM, Vladimir Zapolskiy wrote: Hi John, On 08/04/2016 02:05 AM, John Stultz wrote: Now that Andy's reboot reason core driver has landed, I wanted to resubmit a reworked version of my SRAM based reboot reason

Re: [PATCH 4/9] remoteproc: core: New API to add new resources to the resource table

Hi Lee, After splitting this patch in 2, it may be good to add a debugfs entry to display current rsc associated to one rproc. Regards, Loic On 08/04/2016 11:21 AM, Lee Jones wrote: In order to amend or add a new resource table entry we need a method for a platform-specific to submit them.

Re: [PATCH 4/9] remoteproc: core: New API to add new resources to the resource table

Hi Lee, After splitting this patch in 2, it may be good to add a debugfs entry to display current rsc associated to one rproc. Regards, Loic On 08/04/2016 11:21 AM, Lee Jones wrote: In order to amend or add a new resource table entry we need a method for a platform-specific to submit them.

Re: [PATCH 1/2] sc16is7xx: Do not handle irqs in endless loop

On Mon, Aug 08, 2016 at 03:32:15PM +0200, dirk.eib...@gdsys.cc wrote: > From: Dirk Eibach > > sc16is7xx_port_irq() is laid out as an endless loop. It will exit only > when there is no more interrupt left to service. This not common > practice. > In our case it lead to some

Re: [PATCH 1/2] sc16is7xx: Do not handle irqs in endless loop

On Mon, Aug 08, 2016 at 03:32:15PM +0200, dirk.eib...@gdsys.cc wrote: > From: Dirk Eibach > > sc16is7xx_port_irq() is laid out as an endless loop. It will exit only > when there is no more interrupt left to service. This not common > practice. > In our case it lead to some strange hangup

linux-4.8-rc1/drivers/dma/txx9dmac.c: 2 * pointless expression ?

Hello there, 1, linux-4.8-rc1/drivers/dma/txx9dmac.c:751]: (style) Expression '(X & 0x7f) <= 0x7f' is always true. Source code is if (xfer_count > 0x80 && (xfer_count & 0x7f) >= 0x7e && (xfer_count & 0x7f) <= 0x7f) 2.

linux-4.8-rc1/drivers/dma/txx9dmac.c: 2 * pointless expression ?

Hello there, 1, linux-4.8-rc1/drivers/dma/txx9dmac.c:751]: (style) Expression '(X & 0x7f) <= 0x7f' is always true. Source code is if (xfer_count > 0x80 && (xfer_count & 0x7f) >= 0x7e && (xfer_count & 0x7f) <= 0x7f) 2.

Re: [PATCH v2 2/3] drm: simpledrm: add fbdev fallback support

Den 06.08.2016 00:38, skrev Paul Gortmaker: On Fri, Aug 5, 2016 at 11:44 AM, Noralf Trønnes wrote: Create a simple fbdev device during SimpleDRM setup so legacy user-space and fbcon can use it. Original work by David Herrmann. Cc: dh.herrm...@gmail.com Signed-off-by:

Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO_WARN attribute

On 08/05/2016 02:01 PM, Andrew Morton wrote: Bah. What about WARN__ON_ONCE()? Or much heavier ratelimiting? The problem w/ the WARN_ON_ONCE macro for this case is that it applies once per _function_ (because of its static variable), not per _device_. So, after the message happens for a

Re: [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ

Il 08/08/2016 15:19, Christoph Hellwig ha scritto: Again, please don't spend more time on the legacy request interface. If you want your work included and make an impact add it to blk-mq. Working on that front too (and about to send a RFD in this respect). Thanks, Paolo

Re: [PATCH v2 2/3] drm: simpledrm: add fbdev fallback support

Den 06.08.2016 00:38, skrev Paul Gortmaker: On Fri, Aug 5, 2016 at 11:44 AM, Noralf Trønnes wrote: Create a simple fbdev device during SimpleDRM setup so legacy user-space and fbcon can use it. Original work by David Herrmann. Cc: dh.herrm...@gmail.com Signed-off-by: Noralf Trønnes ---

Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO_WARN attribute

On 08/05/2016 02:01 PM, Andrew Morton wrote: Bah. What about WARN__ON_ONCE()? Or much heavier ratelimiting? The problem w/ the WARN_ON_ONCE macro for this case is that it applies once per _function_ (because of its static variable), not per _device_. So, after the message happens for a

Re: [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ

Il 08/08/2016 15:19, Christoph Hellwig ha scritto: Again, please don't spend more time on the legacy request interface. If you want your work included and make an impact add it to blk-mq. Working on that front too (and about to send a RFD in this respect). Thanks, Paolo

Re: [PATCH 1/1] mfd: qcom_rpm: add missing of_node_put after calling of_parse_phandle

On Fri, 15 Jul 2016, Peter Chen wrote: > of_node_put needs to be called when the device node which is got > from of_parse_phandle has finished using. > > Cc: Bjorn Andersson > Cc: Lee Jones > Signed-off-by: Peter Chen >

Re: [PATCH 1/1] mfd: qcom_rpm: add missing of_node_put after calling of_parse_phandle

On Fri, 15 Jul 2016, Peter Chen wrote: > of_node_put needs to be called when the device node which is got > from of_parse_phandle has finished using. > > Cc: Bjorn Andersson > Cc: Lee Jones > Signed-off-by: Peter Chen > --- > drivers/mfd/qcom_rpm.c | 1 + > 1 file changed, 1 insertion(+)

Re: [PATCH 3/3] ARM: dts: Add Arria10 SD/MMC EDAC devicetree entry

On Tue, Aug 02, 2016 at 10:56:21AM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add the device tree entries needed to support the Altera SD/MMC > FIFO buffer EDAC on the Arria10 chip. > > Signed-off-by: Thor Thayer

Re: [PATCH 3/3] ARM: dts: Add Arria10 SD/MMC EDAC devicetree entry

On Tue, Aug 02, 2016 at 10:56:21AM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add the device tree entries needed to support the Altera SD/MMC > FIFO buffer EDAC on the Arria10 chip. > > Signed-off-by: Thor Thayer > --- >

Re: [PATCH 2/3] EDAC, altera: Add Arria10 SD-MMC EDAC support

On Tue, Aug 02, 2016 at 10:56:20AM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add Altera Arria10 SD-MMC FIFO memory EDAC support. The SD-MMC > is a dual port RAM implementation which is different than any > of the other peripherals and

Re: [PATCH 2/3] EDAC, altera: Add Arria10 SD-MMC EDAC support

On Tue, Aug 02, 2016 at 10:56:20AM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add Altera Arria10 SD-MMC FIFO memory EDAC support. The SD-MMC > is a dual port RAM implementation which is different than any > of the other peripherals and therefore requires additional code.

[PATCH v2 0/4] clocksource: timer-atmel-pit: driver fix and cleanups

Hi, The first patch in the series is a fix that will be needed starting v4.9. The remaining patches are cleanups. Changes in v2: - Rebased on v4.8-rc1 - Collected acks Alexandre Belloni (4): clocksource: timer-atmel-pit: enable mck clocksource: timer-atmel-pit: drop

[PATCH v2 0/4] clocksource: timer-atmel-pit: driver fix and cleanups

Hi, The first patch in the series is a fix that will be needed starting v4.9. The remaining patches are cleanups. Changes in v2: - Rebased on v4.8-rc1 - Collected acks Alexandre Belloni (4): clocksource: timer-atmel-pit: enable mck clocksource: timer-atmel-pit: drop

[PATCH v2 3/4] clocksource: timer-atmel-pit: remove uselesss WARN_ON_ONCE

IRQ handlers are running with IRQ disabled for a while, remove wrong comment and useless test. Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni --- drivers/clocksource/timer-atmel-pit.c | 6 -- 1 file changed, 6

[PATCH v2 2/4] clocksource: timer-atmel-pit: drop at91sam926x_pit_common_init

Merge at91sam926x_pit_common_init in at91sam926x_pit_dt_init as this is the only initialization method now. Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni --- drivers/clocksource/timer-atmel-pit.c | 64

[PATCH v2 3/4] clocksource: timer-atmel-pit: remove uselesss WARN_ON_ONCE

IRQ handlers are running with IRQ disabled for a while, remove wrong comment and useless test. Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni --- drivers/clocksource/timer-atmel-pit.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/clocksource/timer-atmel-pit.c

[PATCH v2 2/4] clocksource: timer-atmel-pit: drop at91sam926x_pit_common_init

Merge at91sam926x_pit_common_init in at91sam926x_pit_dt_init as this is the only initialization method now. Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni --- drivers/clocksource/timer-atmel-pit.c | 64 ++- 1 file changed, 26 insertions(+), 38

[PATCH v2 1/4] clocksource: timer-atmel-pit: enable mck

mck is needed to get the PIT working. Explicitly prepare_enable it instead of assuming it is enabled. This solves an issue where the system is freezing when the ETM/ETB drivers are enabled. Reported-by: Olivier Schonken Reviewed-by: Boris Brezillon

[PATCH v2 1/4] clocksource: timer-atmel-pit: enable mck

mck is needed to get the PIT working. Explicitly prepare_enable it instead of assuming it is enabled. This solves an issue where the system is freezing when the ETM/ETB drivers are enabled. Reported-by: Olivier Schonken Reviewed-by: Boris Brezillon Acked-by: Nicolas Ferre Signed-off-by:

[PATCH v2 4/4] clocksource: timer-atmel-pit: simplify IRQ handler

Because the PIT is also a proper clocksource, the timekeeping code is already able to handle lost ticks. Reported-by: Thomas Gleixner Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni ---

[PATCH v2 4/4] clocksource: timer-atmel-pit: simplify IRQ handler

Because the PIT is also a proper clocksource, the timekeeping code is already able to handle lost ticks. Reported-by: Thomas Gleixner Acked-by: Nicolas Ferre Signed-off-by: Alexandre Belloni --- drivers/clocksource/timer-atmel-pit.c | 11 +++ 1 file changed, 3 insertions(+), 8

<    8   9   10   11   12   13   14   15   16   17   >