[PATCH 1/3] MIPS: ralink: fix MT7628 pinmux typos

Signed-off-by: Álvaro Fernández Rojas --- arch/mips/ralink/mt7620.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/ralink/mt7620.c b/arch/mips/ralink/mt7620.c index 0d3d1a9..caabee1 100644 --- a/arch/mips/ralink/mt7620.c +++

[PATCH 1/3] MIPS: ralink: fix MT7628 pinmux typos

Signed-off-by: Álvaro Fernández Rojas --- arch/mips/ralink/mt7620.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/ralink/mt7620.c b/arch/mips/ralink/mt7620.c index 0d3d1a9..caabee1 100644 --- a/arch/mips/ralink/mt7620.c +++ b/arch/mips/ralink/mt7620.c @@

[PATCH 3/3] MIPS: ralink: add MT7628 EPHY LEDs pinmux support

Signed-off-by: Álvaro Fernández Rojas --- arch/mips/ralink/mt7620.c | 100 ++ 1 file changed, 100 insertions(+) diff --git a/arch/mips/ralink/mt7620.c b/arch/mips/ralink/mt7620.c index 9f80492..251c165 100644 ---

[PATCH 2/3] MIPS: ralink: fix MT7628 wled_an pinmux gpio

Signed-off-by: Álvaro Fernández Rojas --- arch/mips/ralink/mt7620.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/mips/ralink/mt7620.c b/arch/mips/ralink/mt7620.c index caabee1..9f80492 100644 --- a/arch/mips/ralink/mt7620.c +++

[PATCH 3/3] MIPS: ralink: add MT7628 EPHY LEDs pinmux support

Signed-off-by: Álvaro Fernández Rojas --- arch/mips/ralink/mt7620.c | 100 ++ 1 file changed, 100 insertions(+) diff --git a/arch/mips/ralink/mt7620.c b/arch/mips/ralink/mt7620.c index 9f80492..251c165 100644 --- a/arch/mips/ralink/mt7620.c +++

[PATCH 2/3] MIPS: ralink: fix MT7628 wled_an pinmux gpio

Signed-off-by: Álvaro Fernández Rojas --- arch/mips/ralink/mt7620.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/mips/ralink/mt7620.c b/arch/mips/ralink/mt7620.c index caabee1..9f80492 100644 --- a/arch/mips/ralink/mt7620.c +++ b/arch/mips/ralink/mt7620.c @@

Re: [PATCH] ARM: dts: at91: add at91sam9260ek board DT

On 19/05/2016 at 14:54:22 +0200, Nicolas Ferre wrote : > Add Device Tree source file for at91sam9260ek board. This official Atmel > Evaluation Kit is designed around a SoC based on a ARM 926 core the > at91sam9260. > > The board is also added to the dts Makefile. > > Signed-off-by: Nicolas Ferre

Re: [PATCH] ARM: dts: at91: add at91sam9260ek board DT

On 19/05/2016 at 14:54:22 +0200, Nicolas Ferre wrote : > Add Device Tree source file for at91sam9260ek board. This official Atmel > Evaluation Kit is designed around a SoC based on a ARM 926 core the > at91sam9260. > > The board is also added to the dts Makefile. > > Signed-off-by: Nicolas Ferre

Re: [PATCH] ARM: at91: Documentation: update the sama5d2 entry

On 19/05/2016 at 15:11:03 +0200, Nicolas Ferre wrote : > Update the Atmel SoC entry for SAMA5D2 with all the product variants. Add the > datasheet web link, now that it's available, for instant access to full > product > documentation. > > Signed-off-by: Nicolas Ferre

Re: [PATCH] ARM: at91: Documentation: update the sama5d2 entry

On 19/05/2016 at 15:11:03 +0200, Nicolas Ferre wrote : > Update the Atmel SoC entry for SAMA5D2 with all the product variants. Add the > datasheet web link, now that it's available, for instant access to full > product > documentation. > > Signed-off-by: Nicolas Ferre Acked-by: Alexandre

Re: get_maintainer.pl and MAINTAINERS file

Cc: joe On 05/19/2016, 02:57 PM, Kalle Valo wrote: > (Changed the subject from "Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 > driver") > > Robin van der Gracht writes: > >>> And 4th, what is with the insane number of people on cc:? Use >>> get_maintainer.pl correctly

Re: get_maintainer.pl and MAINTAINERS file

Cc: joe On 05/19/2016, 02:57 PM, Kalle Valo wrote: > (Changed the subject from "Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 > driver") > > Robin van der Gracht writes: > >>> And 4th, what is with the insane number of people on cc:? Use >>> get_maintainer.pl correctly please, and don't

Re: [GIT PULL] pin control bulk changes for the v4.7 cycle

On Thu, May 19, 2016 at 4:20 AM, Linus Walleij wrote: > > This kernel cycle was quite calm when it comes to pin > control and there is really just one major change, and that > is the introduction of devm_pinctrl_register() managed > resources. WTF happened here?

Re: [GIT PULL] pin control bulk changes for the v4.7 cycle

On Thu, May 19, 2016 at 4:20 AM, Linus Walleij wrote: > > This kernel cycle was quite calm when it comes to pin > control and there is really just one major change, and that > is the introduction of devm_pinctrl_register() managed > resources. WTF happened here?

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Thu, May 19, 2016 at 01:44:36AM +0200, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > > The rate limit timestamp (last_freq_update_time) is currently advanced > > anytime schedutil re-evaluates the policy regardless of whether the CPU

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Thu, May 19, 2016 at 01:44:36AM +0200, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > > The rate limit timestamp (last_freq_update_time) is currently advanced > > anytime schedutil re-evaluates the policy regardless of whether the CPU > > frequency is changed

Re: [PATCH 3/7] pref annotate: Separate architecture specific annotation support

Em Thu, May 19, 2016 at 05:59:47PM +0100, Chris Ryder escreveu: > Currently the list of instructions recognised by perf annotate > contains an intermingled mix of x86 and ARM instructions, and the x86 > instructions are unconditionally included on all platforms. This means > that perf attempts to

Re: [PATCH 3/7] pref annotate: Separate architecture specific annotation support

Em Thu, May 19, 2016 at 05:59:47PM +0100, Chris Ryder escreveu: > Currently the list of instructions recognised by perf annotate > contains an intermingled mix of x86 and ARM instructions, and the x86 > instructions are unconditionally included on all platforms. This means > that perf attempts to

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote: > On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote: > > On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote: > > > On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote: > > > > On Thu, May 19, 2016

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote: > On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote: > > On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote: > > > On Wed, May 18, 2016 at 09:23:10PM -0700, Josh Triplett wrote: > > > > On Thu, May 19, 2016

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Thu, May 19, 2016 at 02:24:57PM +0200, Peter Zijlstra wrote: > On Thu, May 05, 2016 at 08:44:05PM -, Thomas Gleixner wrote: > > From: Sebastian Siewior > > > > The per process hash is allocated on the fly at the first futex operation > > of a > > process. The size

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Thu, May 19, 2016 at 02:24:57PM +0200, Peter Zijlstra wrote: > On Thu, May 05, 2016 at 08:44:05PM -, Thomas Gleixner wrote: > > From: Sebastian Siewior > > > > The per process hash is allocated on the fly at the first futex operation > > of a > > process. The size of the hash is

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Thu, May 19, 2016 at 02:28:49PM +0200, Peter Zijlstra wrote: > On Sat, May 07, 2016 at 10:47:38AM +0200, Thomas Gleixner wrote: > > On Fri, 6 May 2016, Darren Hart wrote: > > > > So this seems like it could be tricky for the user as system libraries, > > > like > > > glibc, make use of

Re: [patch V2 3/7] futex: Add op for hash preallocation

On Thu, May 19, 2016 at 02:28:49PM +0200, Peter Zijlstra wrote: > On Sat, May 07, 2016 at 10:47:38AM +0200, Thomas Gleixner wrote: > > On Fri, 6 May 2016, Darren Hart wrote: > > > > So this seems like it could be tricky for the user as system libraries, > > > like > > > glibc, make use of

Re: [PATCH 4/5] cpufreq: schedutil: map raw required frequency to CPU-supported frequency

On Thu, May 19, 2016 at 01:37:40AM +0200, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > > The mechanisms for remote CPU updates and slow-path frequency > > transitions are relatively expensive - the former is an IPI while the > > latter

Re: [PATCH 4/5] cpufreq: schedutil: map raw required frequency to CPU-supported frequency

On Thu, May 19, 2016 at 01:37:40AM +0200, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > > The mechanisms for remote CPU updates and slow-path frequency > > transitions are relatively expensive - the former is an IPI while the > > latter requires waking up a

[PATCH v2 1/1] net: hns: avoid null pointer dereference

In the statement assert(priv || priv->ae_handle); the right side of || is only evaluated if priv is null. v2: As suggested by David Leight and David Miller the assert statements are removed. Signed-off-by: Heinrich Schuchardt ---

[PATCH v2 1/1] net: hns: avoid null pointer dereference

In the statement assert(priv || priv->ae_handle); the right side of || is only evaluated if priv is null. v2: As suggested by David Leight and David Miller the assert statements are removed. Signed-off-by: Heinrich Schuchardt ---

Re: [PATCH] scsi: ultrastor.c depends on ISA_DMA_API

On Thu, May 19, 2016 at 02:53:35PM -0400, William Breathitt Gray wrote: >Although request_dma and free_dma are conditionally dependent on >CONFIG_ISA_DMA_API inside the arch/x86/include/asm/dma.h file, they are >defined inside the kernel/dma.c file which depends on >CONFIG_GENERIC_ISA_DMA in order

Re: [PATCH] scsi: ultrastor.c depends on ISA_DMA_API

On Thu, May 19, 2016 at 02:53:35PM -0400, William Breathitt Gray wrote: >Although request_dma and free_dma are conditionally dependent on >CONFIG_ISA_DMA_API inside the arch/x86/include/asm/dma.h file, they are >defined inside the kernel/dma.c file which depends on >CONFIG_GENERIC_ISA_DMA in order

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Thu, May 19, 2016 at 02:00:54PM +0200, Rafael J. Wysocki wrote: > On Thu, May 19, 2016 at 1:33 AM, Rafael J. Wysocki wrote: > > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle > > wrote: > >> Without calling the cpufreq hook for a remote wakeup it is

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Thu, May 19, 2016 at 02:00:54PM +0200, Rafael J. Wysocki wrote: > On Thu, May 19, 2016 at 1:33 AM, Rafael J. Wysocki wrote: > > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle > > wrote: > >> Without calling the cpufreq hook for a remote wakeup it is possible > >> for such a wakeup to go

Re: [RFC 4/8] usb: phy: move TCSR driver into new file

On 18 May 2016 at 16:24, Arnd Bergmann wrote: > +/* > + * This abstracts the TCSR register area in Qualcomm SoCs, originally > + * introduced by Tim Bird as part of the phy-msm-usb.ko device driver, > + * and split out by Arnd Bergmann into a separate file. > + * > + * This file

Re: [RFC 4/8] usb: phy: move TCSR driver into new file

On 18 May 2016 at 16:24, Arnd Bergmann wrote: > +/* > + * This abstracts the TCSR register area in Qualcomm SoCs, originally > + * introduced by Tim Bird as part of the phy-msm-usb.ko device driver, > + * and split out by Arnd Bergmann into a separate file. > + * > + * This file shouldn't

[PATCH] f2fs: avoid ENOSPC fault in the recovery process

This patch avoids impossible error injection, ENOSPC, during recovery process. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index f89b70e..3d7216d 100644 ---

[PATCH] f2fs: avoid ENOSPC fault in the recovery process

This patch avoids impossible error injection, ENOSPC, during recovery process. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index f89b70e..3d7216d 100644 --- a/fs/f2fs/recovery.c +++

[PULL] Documentation changes for 4.7

Here's the documentation tree for 4.7. A bit busier this time around; details below. Thanks, jon The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.lwn.net/linux.git

[PULL] Documentation changes for 4.7

Here's the documentation tree for 4.7. A bit busier this time around; details below. Thanks, jon The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.lwn.net/linux.git

Re: [PATCH] scsi: ultrastor.c depends on ISA_DMA_API

+- > 1 file changed, 1 insertion(+), 1 deletion(-) > >Found in linux-next but also applies to mainline. > >--- linux-next-20160519.orig/drivers/scsi/Kconfig >+++ linux-next-20160519/drivers/scsi/Kconfig >@@ -1433,7 +1433,7 @@ config SCSI_U14_34F_MAX_TAGS > > config SCSI_UL

Re: [PATCH] scsi: ultrastor.c depends on ISA_DMA_API

rs/scsi/ultrastor.c:658:3: error: implicit declaration of function >'free_dma' [-Werror=implicit-function-declaration] > free_dma(shost->dma_channel); > ^ > >Signed-off-by: Randy Dunlap >--- > drivers/scsi/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

Re: [PATCH v2] net: Fix coding style warnings and errors.

From: Amit Ghadge Date: Wed, 18 May 2016 06:46:30 +0530 > This is a patch to clean checkpatch warnings and errors > in the Space.c file. > Clean up the following warnings and errors. > > WARNING : > * Block comments use * on subsequent lines > * Missing a blank line after

Re: [PATCH v2] net: Fix coding style warnings and errors.

From: Amit Ghadge Date: Wed, 18 May 2016 06:46:30 +0530 > This is a patch to clean checkpatch warnings and errors > in the Space.c file. > Clean up the following warnings and errors. > > WARNING : > * Block comments use * on subsequent lines > * Missing a blank line after declarations > *

Re: [PATCH] iio: light: jsa1212: remove unneeded i2c check functionality test

Looks Good. Reviewed-by:Kuppuswamy Sathyanarayanan On 05/15/2016 11:37 AM, Alison Schofield wrote: This driver does not call i2c_smbus_read|write_byte_data(), so remove the corresponding functionality test. It uses regmap to handle byte transfers

Re: [PATCH] iio: light: jsa1212: remove unneeded i2c check functionality test

Looks Good. Reviewed-by:Kuppuswamy Sathyanarayanan On 05/15/2016 11:37 AM, Alison Schofield wrote: This driver does not call i2c_smbus_read|write_byte_data(), so remove the corresponding functionality test. It uses regmap to handle byte transfers transparently. Signed-off-by: Alison

syslog-ng invoked oom-killer in __inet6_check_established

Hi there, while downloading a few new kernels (don't know if that is related, however), the following trace appeared. I'm relatively new on the 4.5 series but such thing actually never happend on my former 3.12 installs. Is that somehow related to vm_swappiness==0 on the 4.5 (or: after 3.12/3.14)

syslog-ng invoked oom-killer in __inet6_check_established

Hi there, while downloading a few new kernels (don't know if that is related, however), the following trace appeared. I'm relatively new on the 4.5 series but such thing actually never happend on my former 3.12 installs. Is that somehow related to vm_swappiness==0 on the 4.5 (or: after 3.12/3.14)

Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs

On Thu, May 19, 2016 at 01:24:41AM +0200, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > > In preparation for the scheduler cpufreq callback happening on remote > > CPUs, add support for this in schedutil. > > > > Schedutil currently

Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs

On Thu, May 19, 2016 at 01:24:41AM +0200, Rafael J. Wysocki wrote: > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle wrote: > > In preparation for the scheduler cpufreq callback happening on remote > > CPUs, add support for this in schedutil. > > > > Schedutil currently requires the callback occur

Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2

Hi, Tony Lindgren writes: > * Peter Ujfalusi [160519 01:10]: >> On 05/18/2016 10:30 PM, Tony Lindgren wrote: >> > Ideally the adma support would be a separate loadable module, >> > similar how the cppi41dma is a child of the OTG controller. >> >> The

Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2

Hi, Tony Lindgren writes: > * Peter Ujfalusi [160519 01:10]: >> On 05/18/2016 10:30 PM, Tony Lindgren wrote: >> > Ideally the adma support would be a separate loadable module, >> > similar how the cppi41dma is a child of the OTG controller. >> >> The Master DMA is part of the hsmmc IP block.

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On Thu, May 19, 2016 at 11:01 AM, David Matlack wrote: > On Thu, May 19, 2016 at 6:27 AM, Wanpeng Li wrote: >> From: Wanpeng Li >> >> If an emulated lapic timer will fire soon(in the scope of 10us the >> base of dynamic

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On Thu, May 19, 2016 at 11:01 AM, David Matlack wrote: > On Thu, May 19, 2016 at 6:27 AM, Wanpeng Li wrote: >> From: Wanpeng Li >> >> If an emulated lapic timer will fire soon(in the scope of 10us the >> base of dynamic halt-polling, lower-end of message passing workload >> latency TCP_RR's

Re: [PATCH 1/1] net: pegasus: remove dead coding

From: Heinrich Schuchardt Date: Wed, 18 May 2016 02:13:30 +0200 > (!count || count < 4) is always true. > So let's remove the coding which is dead at least since 2005. > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/1] net: pegasus: remove dead coding

From: Heinrich Schuchardt Date: Wed, 18 May 2016 02:13:30 +0200 > (!count || count < 4) is always true. > So let's remove the coding which is dead at least since 2005. > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/2] Documentation: dt: add bindings for ti-cpufreq

On 05/18/2016 10:15 PM, Viresh Kumar wrote: On 18-05-16, 18:30, Dave Gerlach wrote: Add the device tree bindings document for the TI CPUFreq/OPP driver on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us to provide an opp-supported-hw property for each OPP to define when it is

Re: [PATCH 1/2] Documentation: dt: add bindings for ti-cpufreq

On 05/18/2016 10:15 PM, Viresh Kumar wrote: On 18-05-16, 18:30, Dave Gerlach wrote: Add the device tree bindings document for the TI CPUFreq/OPP driver on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us to provide an opp-supported-hw property for each OPP to define when it is

Re: [PATCH 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime

On 05/18/2016 11:39 PM, Viresh Kumar wrote: On 18-05-16, 18:30, Dave Gerlach wrote: Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families, have different OPPs available for the MPU depending on which specific variant of the SoC is in use. This can be determined through use

[GIT PULL] MD for 4.7-rc1

Hi Linus, pleae pull MD update for 4.7. It includes several patches from Guoqing fixing md-cluster bugs and several patches from Heinz fixing dm-raid bugs. Thanks, Shaohua The following changes since commit 4810d9682971e8eee659f96e4f9d9154e3c6c0b4: Merge branch 'for-linus' of

Re: [PATCH 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime

On 05/18/2016 11:39 PM, Viresh Kumar wrote: On 18-05-16, 18:30, Dave Gerlach wrote: Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families, have different OPPs available for the MPU depending on which specific variant of the SoC is in use. This can be determined through use

[GIT PULL] MD for 4.7-rc1

Hi Linus, pleae pull MD update for 4.7. It includes several patches from Guoqing fixing md-cluster bugs and several patches from Heinz fixing dm-raid bugs. Thanks, Shaohua The following changes since commit 4810d9682971e8eee659f96e4f9d9154e3c6c0b4: Merge branch 'for-linus' of

Re: [GIT PULL] First batch of KVM changes for 4.7

On Thu, May 19, 2016 at 5:17 AM, Paolo Bonzini wrote: > > git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus This conflicted with the MIPS updates I just pulled. I tried to fix things up, but since I don't cross-compile, my fixups have no testing even at the

Re: [GIT PULL] First batch of KVM changes for 4.7

On Thu, May 19, 2016 at 5:17 AM, Paolo Bonzini wrote: > > git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus This conflicted with the MIPS updates I just pulled. I tried to fix things up, but since I don't cross-compile, my fixups have no testing even at the "ok, it compiles, ship

Re: [PATCH] net: au1000 eth: simplify logical expression

From: Heinrich Schuchardt Date: Wed, 18 May 2016 01:58:45 +0200 > (a && a > 0) is equivalent to (a > 0). > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH] net: au1000 eth: simplify logical expression

From: Heinrich Schuchardt Date: Wed, 18 May 2016 01:58:45 +0200 > (a && a > 0) is equivalent to (a > 0). > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/1] net: ieee802154/adf7242: syntax error ifdef DEBUG

From: Heinrich Schuchardt Date: Tue, 17 May 2016 23:58:40 +0200 > If DEBUG is defined, a superfluous closing brace > is introduced. > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/1] net: ieee802154/adf7242: syntax error ifdef DEBUG

From: Heinrich Schuchardt Date: Tue, 17 May 2016 23:58:40 +0200 > If DEBUG is defined, a superfluous closing brace > is introduced. > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/1] net: rsi: eliminate superfluous NULL check

From: Heinrich Schuchardt Date: Wed, 18 May 2016 00:30:41 +0200 > msg is dereferenced before checking against NULL, e.g. > when assigning pad_bytes. > Remove the superfluous check in function rsi_mgmt_pkt_to_core. > > Signed-off-by: Heinrich Schuchardt

Re: [PATCH 1/1] net: rsi: eliminate superfluous NULL check

From: Heinrich Schuchardt Date: Wed, 18 May 2016 00:30:41 +0200 > msg is dereferenced before checking against NULL, e.g. > when assigning pad_bytes. > Remove the superfluous check in function rsi_mgmt_pkt_to_core. > > Signed-off-by: Heinrich Schuchardt I'll let the wireless folks pick this

Re: [PATCH 1/1] net: irda: avoid null pointer dereference

From: Heinrich Schuchardt Date: Wed, 18 May 2016 00:06:02 +0200 > Only dereference variable self after checking it is not NULL. > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/1] net: irda: avoid null pointer dereference

From: Heinrich Schuchardt Date: Wed, 18 May 2016 00:06:02 +0200 > Only dereference variable self after checking it is not NULL. > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/1] net: ehea: avoid null pointer dereference

From: Heinrich Schuchardt Date: Tue, 17 May 2016 22:28:54 +0200 > ehea_get_port may return NULL. Do not dereference NULL value. > > Fixes: 8c4877a4128e ("ehea: Use the standard logging functions") > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/1] net: ehea: avoid null pointer dereference

From: Heinrich Schuchardt Date: Tue, 17 May 2016 22:28:54 +0200 > ehea_get_port may return NULL. Do not dereference NULL value. > > Fixes: 8c4877a4128e ("ehea: Use the standard logging functions") > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH 1/1] net: hns: avoid null pointer dereference

From: Heinrich Schuchardt Date: Tue, 17 May 2016 22:01:15 +0200 > In the statement > assert(priv || priv->ae_handle); > the right side of || is only evaluated if priv is null. > > Signed-off-by: Heinrich Schuchardt I agree with others that this

Re: [PATCH 1/1] net: hns: avoid null pointer dereference

From: Heinrich Schuchardt Date: Tue, 17 May 2016 22:01:15 +0200 > In the statement > assert(priv || priv->ae_handle); > the right side of || is only evaluated if priv is null. > > Signed-off-by: Heinrich Schuchardt I agree with others that this assert() is pretty useless and should simply

Re: [PATCH 1/1] net: i40e: avoid null pointer dereference

From: Heinrich Schuchardt Date: Tue, 17 May 2016 22:41:33 +0200 > In function i40e_debug_aq parameter desc is assumed to be > possibly NULL. Do not dereference it before checking the > value. > > Fixes: f905dd62be88 ("i40e/i40evf: add max buf len to aq debug print helper") >

Re: [PATCH 1/1] net: i40e: avoid null pointer dereference

From: Heinrich Schuchardt Date: Tue, 17 May 2016 22:41:33 +0200 > In function i40e_debug_aq parameter desc is assumed to be > possibly NULL. Do not dereference it before checking the > value. > > Fixes: f905dd62be88 ("i40e/i40evf: add max buf len to aq debug print helper") > Signed-off-by:

RE: [PATCH] [SCSI] aacraid: use kmemdup

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Muhammad Falak R Wani > Sent: Thursday, May 19, 2016 7:09 AM > To: Hannes Reinecke > Cc: Adaptec OEM Raid Solutions; James E.J. Bottomley; Martin K. Petersen; >

Re: [PATCH 1/1] net: thunderx: avoid null pointer dereference

From: Heinrich Schuchardt Date: Tue, 17 May 2016 21:40:38 +0200 > In function bgx_lmac_handler only use a member of > lmac after checking it is not null. > > Signed-off-by: Heinrich Schuchardt Applied.

RE: [PATCH] [SCSI] aacraid: use kmemdup

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Muhammad Falak R Wani > Sent: Thursday, May 19, 2016 7:09 AM > To: Hannes Reinecke > Cc: Adaptec OEM Raid Solutions; James E.J. Bottomley; Martin K. Petersen; >

Re: [PATCH 1/1] net: thunderx: avoid null pointer dereference

From: Heinrich Schuchardt Date: Tue, 17 May 2016 21:40:38 +0200 > In function bgx_lmac_handler only use a member of > lmac after checking it is not null. > > Signed-off-by: Heinrich Schuchardt Applied.

Re: [PATCH net,stable v2] net: cdc_ncm: update datagram size after changing mtu

Robert Dobrowolski writes: > From: Rafal Redzimski > > Current implementation updates the mtu size and notify cdc_ncm > device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram > size change instead of changing

Re: [PATCH net,stable v2] net: cdc_ncm: update datagram size after changing mtu

Robert Dobrowolski writes: > From: Rafal Redzimski > > Current implementation updates the mtu size and notify cdc_ncm > device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram > size change instead of changing rx_urb_size. > > Whenever mtu is being changed, datagram size should also

[PATCH v4 05/14] staging: comedi: daqboard2000: rename serial EEPROM register macros

Rename the macros defining values for the Serial EEPROM Control Register to avoid CamelCase. Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten --- v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`. v3, v4: No change. ---

[PATCH v4 05/14] staging: comedi: daqboard2000: rename serial EEPROM register macros

Rename the macros defining values for the Serial EEPROM Control Register to avoid CamelCase. Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten --- v2: Shortened prefix from `DAQBOARD2000_` to `DB2K_`. v3, v4: No change. --- drivers/staging/comedi/drivers/daqboard2000.c | 26

[PATCH v4 04/14] staging: comedi: daqboard2000: add blank line after struct declaration

Fix checkpatch issue: "CHECK: Please use a blank line after function/struct/union/enum declarations". Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten --- v2: Fixed typo in patch description: `black line` --> `blank line`. v3, v4: No

[PATCH v4 04/14] staging: comedi: daqboard2000: add blank line after struct declaration

Fix checkpatch issue: "CHECK: Please use a blank line after function/struct/union/enum declarations". Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten --- v2: Fixed typo in patch description: `black line` --> `blank line`. v3, v4: No change. ---

[PATCH v4 02/14] staging: comedi: daqboard2000: use usual block comment style

Reformat one of the block comments to conform to the usual style (it's the only one that doesn't). Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten --- v2, v3, v4: No change. --- drivers/staging/comedi/drivers/daqboard2000.c | 6 --

[PATCH v4 02/14] staging: comedi: daqboard2000: use usual block comment style

Reformat one of the block comments to conform to the usual style (it's the only one that doesn't). Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten --- v2, v3, v4: No change. --- drivers/staging/comedi/drivers/daqboard2000.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)

Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller

On 05/10/2016 10:19 AM, Tomasz Nowicki wrote: From the functionality point of view this series may be split into the following logic parts: 1. New ECAM API and update for users of the pci-host-common API 2. Necessary fixes as the preparation for using driver on ARM64. 3. Use new MCFG interface

Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller

On 05/10/2016 10:19 AM, Tomasz Nowicki wrote: From the functionality point of view this series may be split into the following logic parts: 1. New ECAM API and update for users of the pci-host-common API 2. Necessary fixes as the preparation for using driver on ARM64. 3. Use new MCFG interface

[PATCH v4 06/14] staging: comedi: daqboard2000: rename register offset macros

Rename the macros defining register offsets to avoid CamelCase, and to use namespace associated with the driver. Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten --- Other CamelCase issues in this patch will be dealt with by later patches

[PATCH v4 14/14] staging: comedi: daqboard2000: prefer usleep_range()

The checkpatch.pl warns about two `udelay(x)` calls, one of 100 microseconds, and one of 10 microseconds. The 100 microseconds one is used when waiting for FPGA to become ready to accept firmware, and is not that critical, so replace it with a call to `usleep_range(100, 1000)`. The 10

[PATCH v4 12/14] staging: comedi: daqboard2000: rename reference DACs register macros

Rename the macros that define values for the reference DACs register to avoid CamelCase, and to make it clearer which register they are associated with. Add a macro `DB2K_REG_DACS_SET` for the value `0x0080` that triggers setting one of the references. Signed-off-by: Ian Abbott

[PATCH v4 08/14] staging: comedi: daqboard2000: rename acq status register macros

Rename the macros associated with the acquisition status register to avoid CamelCase and to make it clear which register they are associated with. Add a macro to define the offset of the read-only acquisition status register. It's the same offset as the acquisition control register, which is

[PATCH v4 06/14] staging: comedi: daqboard2000: rename register offset macros

Rename the macros defining register offsets to avoid CamelCase, and to use namespace associated with the driver. Signed-off-by: Ian Abbott Reviewed-by: H Hartley Sweeten --- Other CamelCase issues in this patch will be dealt with by later patches in the series. v2: Shortened prefix from

[PATCH v4 14/14] staging: comedi: daqboard2000: prefer usleep_range()

The checkpatch.pl warns about two `udelay(x)` calls, one of 100 microseconds, and one of 10 microseconds. The 100 microseconds one is used when waiting for FPGA to become ready to accept firmware, and is not that critical, so replace it with a call to `usleep_range(100, 1000)`. The 10

[PATCH v4 12/14] staging: comedi: daqboard2000: rename reference DACs register macros

Rename the macros that define values for the reference DACs register to avoid CamelCase, and to make it clearer which register they are associated with. Add a macro `DB2K_REG_DACS_SET` for the value `0x0080` that triggers setting one of the references. Signed-off-by: Ian Abbott Reviewed-by: H

[PATCH v4 08/14] staging: comedi: daqboard2000: rename acq status register macros

Rename the macros associated with the acquisition status register to avoid CamelCase and to make it clear which register they are associated with. Add a macro to define the offset of the read-only acquisition status register. It's the same offset as the acquisition control register, which is

[PATCH v4 10/14] staging: comedi: daqboard2000: redo DAC status macros and fix busy

Rename the macros defining values for the DAC status register to avoid CamelCase, and to make it clear which register they are associated with. Refactor the macros defining the regular DAC channel "busy" bits into a single macro that takes the DAC channel number as a parameter. Add a macro to

[PATCH v4 09/14] staging: comedi: daqboard2000: redo DAC control register macros

Rename the macros used to define values for the DAC control register to avoid CamelCase and to make it clearer which register they are associated with. Refactor the macros used to define values to enable or disable DAC channels to use the channel number as a parameter. None of these macros are

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