When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Srikanth Jampala
Cc: Yangtao Li
Cc: Gadam Sreerama
Cc: Eric Biggers
C
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jesper Nilsson
Cc: Lars Persson
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-arm-ker...@axis.com
Cc: linux
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Yael Chemla
Cc: Gilad Ben-Yossef
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: linux-cry...@vger.kernel.org
Signe
When calling debugfs code, there is no need to ever check the return
value of the call, as no logic should ever change if a call works
properly or not. Fix up a bunch of infiniband-specific code to not care
about the results of debugfs.
Greg Kroah-Hartman (8):
infiniband: cxgb4: no need to chec
On Sat, Jan 19, 2019 at 11:41:22AM +0900, Tetsuo Handa wrote:
> On 2019/01/19 4:48, Daniel Jordan wrote:
> > On Sat, Jan 19, 2019 at 02:04:58AM +0900, Tetsuo Handa wrote:
> > __queue_work has a sanity check already for work, but using list_empty.
> > Seems
> > slightly better to be consistent?
>
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Steve Wise
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: linux-r...@vger.kernel.org
Signed-off-by: Greg Kroah-Hart
The macro was just making things harder to follow, and audit, so remove
it and call debugfs_create_file() directly. Also, the macro did not
need to warn about the call failing as no one should ever care about any
debugfs functions failing.
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Doug Le
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Leon Romanovsky
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: linux-r...@vger.kernel.org
Signed-off-by: Greg Kroah
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Selvin Xavier
Cc: Devesh Sharma
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: Leon Romanovsky
Cc: Yuval Shaia
C
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: Leon Romanovsky
Cc: Kamal Heib
Cc: Denis Drozdov
Cc: Saeed Mahameed
C
From: Colin Ian King
There are two statements that are indented incorrectly. Fix these.
Signed-off-by: Colin Ian King
---
drivers/scsi/hpsa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index ff67ef5d5347..528fdd10 10064
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Christian Benvenuti
Cc: Nelson Escobar
Cc: Parvi Kaustubhi
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: linux-r
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: linux-r...@vger.kernel.org
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: linux-r...@vger.kernel.org
On Sat, Jan 19, 2019 at 6:41 PM Moritz Fischer
wrote:
>
> On Tue, Jan 15, 2019 at 6:01 PM Alan Tull wrote:
> >
> > The Altera Freeze Bridge should not be restricted to ARCH_SOCFPGA
> > since it can be used on other platforms such as Stratix10.
> >
> > Signed-off-by: Alan Tull
> Reviewed-by: Mori
Hi Adam,
On Tue, Jan 22, 2019 at 12:07 PM Adam Ford wrote:
> + reg_audio: regulator-audio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_reg_audio>;
> + compatible = "regulator-fixed";
> + regulator-name = "3v3_aud";
> +
Fieldbus device (client) adapters allow data exchange with a PLC aka.
"Fieldbus Controller" over a fieldbus (Profinet, FLNet, etc.)
They are typically used when a Linux device wants to expose itself
as an actuator, motor, console light, switch, etc. over the fieldbus.
This framework is designed t
This patch:
1. adds a Fieldbus subsystem
2. adds support for the HMS Industrial Networks AB Profinet card.
1. Fieldbus subsystem
-
Fieldbus device (client) adapters allow data exchange with a PLC aka.
"Fieldbus Controller" over a fieldbus (Profinet, FLNet, etc.)
They are t
The Anybus-S/Anybus-M is a series of interchangeable fieldbus communication
modules featuring on board memory and processing power. All software and
hardware functionality required to communicate on the fieldbus is
incorporated in the module itself, allowing the application to focus on
other tasks.
Add a driver for the Arcx anybus controller.
This device implements two Anybus-S hosts (buses),
and connects to the SoC via a parallel memory bus.
There is also a CAN power readout, unrelated to the Anybus,
modelled as a regulator.
Signed-off-by: Sven Van Asbroeck
---
drivers/fieldbus/Makefile
The Anybus-S PROFINET IRT communication module provides instant integration
to any Ethernet based LAN via SMTP, FTP, HTTP as well as PROFINET and
Modbus-TCP. Additional protocols can be implemented on top of TCP/IP
or UDP using the transparent socket interface.
Official documentation:
https://www.
From: Sven Van Asbroeck
This patch adds devicetree binding documentation for the
Arcx anybus controller.
Signed-off-by: Sven Van Asbroeck
---
.../fieldbus/arcx,anybus-controller.txt | 71 +++
1 file changed, 71 insertions(+)
create mode 100644
Documentation/devicetree/b
On Tue, Jan 22, 2019 at 12:58:05PM -0200, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jan 22, 2019 at 03:51:19PM +0100, Jiri Olsa escreveu:
> > On Tue, Jan 22, 2019 at 12:31:17PM -0200, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Jan 22, 2019 at 12:13:20PM -0200, Arnaldo Carvalho de Melo
> > > esc
On Tue, Jan 15, 2019 at 10:15:05AM +, Patrick Bellasi wrote:
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -218,8 +218,15 @@ unsigned long schedutil_freq_util(int cpu, unsigned long
> util_cfs,
>* CFS tasks and we use the same metric to track th
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: linux-s...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
a
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Naoya Horiguchi
Cc: linux...@kvack.org
Signed-off-by: Greg Kroah-Hartman
---
mm/hwpoison-inject.c | 67 ++
On Mon, Jan 21, 2019 at 03:33:31PM +, Julien Thierry wrote:
> diff --git a/arch/arm64/include/asm/irqflags.h
> b/arch/arm64/include/asm/irqflags.h
> index 24692ed..7e82a92 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -18,7 +18,9 @@
>
> #ifd
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Sebastian Ott
Cc: Gerald Schaefer
Cc: linux-s...@vger.kernel.org
S
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Catalin Marinas
Cc: linux...@kvack.org
Signed-off-by: Greg Kroah-Hartman
---
mm/kmemleak.c | 7 +--
1 fil
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Konrad Rzeszutek Wilk
Cc: linux...@kvack.org
Signed-off-by: Greg Kroah-Hartman
---
mm/cleancache.c | 3 +--
1
There is no need to keep the dentries around for the individual debugfs
files, just delete the whole directory all at once at shutdown instead.
This also fixes a tiny memory leak where the memory for the pointers to
the file dentries was never freed when the device shut down, as well as
making the
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Borislav Petkov
Cc: Mauro Carvalho Chehab
Cc: linux-e...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
--
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Bartlomiej Zolnierkiewicz
Cc: Mauro Carvalho Chehab
Cc: linux-o...@vger.kernel.org
Cc: linux-fb...@vger.kernel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wireless
Cc: Kalle Valo
Cc: linux-wirel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wireless
Cc: Kalle Valo
Cc: linux-wirel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Stanislaw Gruszka
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
..
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kalle Valo
Cc: Tony Lindgren
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
driver
On Tue, 22 Jan 2019, Arnaldo Carvalho de Melo wrote:
Em Thu, Dec 06, 2018 at 11:18:18AM -0800, Davidlohr Bueso escreveu:
At the cost of an extra pointer, we can avoid the O(logN) cost
of finding the first element in the tree (smallest node), which
is something heavily required for histograms. S
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Tony Luck
Cc: Borislav Petkov
Cc: Yangtao Li
Cc: linux-a...@vger.kern
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wireless
Cc: Kalle Valo
Cc: linux-wirel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wireless
Cc: Kalle Valo
Cc: linux-wirel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "Rafael J. Wysocki"
Cc: Kevin Hilman
Cc: Ulf Hansson
Cc: Len Brown
Cc: linux...@vger.kernel.org
Signed-off-b
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kalle Valo
Cc: Tony Lindgren
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
driver
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Solomon Peachy
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drive
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Larry Finger
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Cc: b43-...@lists.infradead.org
Signed-off-by:
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/rsi/
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jens Axboe
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: linux-bl...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartm
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
And as the return value does not matter at all, no need to save the
dentry in struct backing_dev_info, so delete it.
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman
---
kernel/time/timekeep
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Pavel Machek
Cc: linux...@vger.kernel.org
Signed-off-by: Greg Kroah-Har
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Also delete the dentry variable as it is never needed.
Cc: Peter Oberparleiter
Signed-off-by: Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Thomas Gleixner
Cc: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
---
kernel/irq/debugfs.c | 2 --
kernel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kalle Valo
Cc: libertas-...@lists.infradead.org
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Ha
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Ping-Ke Shih
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
kernel/trace/trace.c | 4
1 file c
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Arend van Spriel
Cc: Franky Lin
Cc: Hante Meuleman
Cc: Chi-Hsien Lin
Cc: Wright Feng
Cc: Kalle Valo
Cc: li
On Tue, Jan 22, 2019 at 04:11:59PM +0100, Jiri Slaby wrote:
> Convert SISUSB_VADDR and SISUSB_HADDR to inline functions. Now, there
> are no more hidden accesses to local variables (vc_data and
> sisusb_usb_data).
>
> sisusb_haddr returns unsigned long from now on, not u16 *, as ulong is
> what ev
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Also delete the variables for the file dentries for the debugfs entries
as they are never used at all once they are
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Amitkumar Karwar
Cc: Nishant Sarmukadam
Cc: Ganapathi Bhat
Cc: Xinming Hu
Cc: Kalle Valo
Cc: linux-wirel...
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Darren Hart
Signed-off-by: Greg Kroah-Hartman
---
k
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Igor Mitsyanko
Cc: Avinash Patil
Cc: Sergey Matyukevich
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Si
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Stanislaw Gruszka
Cc: Helmut Schaa
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroa
On Thu 17-01-19 10:17:59, Jerome Glisse wrote:
> On Thu, Jan 17, 2019 at 10:30:47AM +0100, Jan Kara wrote:
> > On Wed 16-01-19 08:08:14, Jerome Glisse wrote:
> > > On Wed, Jan 16, 2019 at 12:38:19PM +0100, Jan Kara wrote:
> > > > On Tue 15-01-19 09:07:59, Jan Kara wrote:
> > > > > Agreed. So with p
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
There is no need to save the dentries for the debugfs files, so drop
those variables to save a bit of space and make
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: k...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
virt/kvm/kvm
On Mon, Jan 21, 2019 at 03:33:28PM +, Julien Thierry wrote:
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
> Since t
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "Naveen N. Rao"
Cc: Anil S Keshavamurthy
Cc: "David S. Miller"
Cc: Masami Hiramatsu
Signed-off-by: Greg Kroa
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Andrew Morton
Cc: Andrey Ryabinin
Cc: Mark Rutland
Cc: Arnd Bergmann
Cc: "Steven Rostedt (VMware)"
Cc: Dmit
On Tue, Jan 22, 2019 at 02:05:26AM +, Zhang, Lei wrote:
> Hi, Mark
>
> Thanks for your comments, and sorry for late.
>
> > -Original Message-
> > * Under what conditions can the fault occur? e.g. is this in place of
> > some other fault, or completely spurious?
> This fault can occ
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Masami Hiramatsu
Cc: Kees Cook
Cc: Josef Bacik
Cc: Thomas Gleixner
Cc: "Naveen N. Rao"
Cc: zhong jiang
Sig
Add slimSSS node to DT and crypto AES support for Exynos5433. Tested on
Exynos5433 board with crypto run-time self tests and with tcrypt with
command insmod tcrypt.ko mode=500 sec=1
Kamil Konieczny (3):
arm64: dts: exynos: add SlimSSS for Exynos5433
dt-bindings: crypto: document Exynos5433 Sli
Document DT bindings for crypto Samsung Exynos5433 SlimSSS (Slim Security
SubSystem) IP.
Signed-off-by: Kamil Konieczny
---
.../devicetree/bindings/crypto/samsung-sss.txt | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/cry
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Signed-off-by: Greg Kroah-Hartman
---
kernel/locking/qspinlo
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Mark Brown
Cc: "Rafael J. Wysocki"
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/regmap/regmap-debugfs.
On 22. 01. 19, 16:23, Greg KH wrote:
> On Tue, Jan 22, 2019 at 04:11:59PM +0100, Jiri Slaby wrote:
>> Convert SISUSB_VADDR and SISUSB_HADDR to inline functions. Now, there
>> are no more hidden accesses to local variables (vc_data and
>> sisusb_usb_data).
>>
>> sisusb_haddr returns unsigned long fr
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Seth Jennings
Cc: Dan Streetman
Cc: linux...@kvack.org
Signed-off-by: Greg Kroah-Hartman
---
mm/zswap.c | 2
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Minchan Kim
Cc: Nitin Gupta
Cc: Sergey Senozhatsky
Cc: linux...@kvack.org
Signed-off-by: Greg Kroah-Hartman
Hi Nick,
Missatge de Nick Crews del dia ds., 19 de gen.
2019 a les 1:17:
>
>
> There is a new chromebook that contains a different Embedded Controller
> (codename Wilco) than the rest of the chromebook series. Thus the kernel
> requires a different driver than the already existing and generalized
Add DT node for SlimSSS (aka Slim SecuritySubSystem) in Exynos5433 SoC.
The users can use compatibility "samsung,exynos5433-slim-sss".
Signed-off-by: Kamil Konieczny
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/ex
Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.
Signed-off-by: Kamil Konieczny
---
drivers/crypto/s5p-sss.c | 50
1 file changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.
Commit 9178412ddf5a ("tracing: probeevent: Return consumed
bytes of dynamic area") improved the string fetching
mechanism by returning the number of required bytes after
copying the argument to the dynamic area. However, this
return value is now only used to increment the pointer
inside the dynamic
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "Ed L. Cashin"
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Cc: b43-...@lists.infradead.org
Signed-off-by: Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kalle Valo
Cc: Tony Lindgren
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
driver
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Kalle Valo
Cc: Tony Lindgren
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
driver
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wireless
Cc: Kalle Valo
Cc: linux-wirel
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Kees Cook
Cc: Christian Borntraeger
Cc: Hendrik Brueckner
Cc: lin
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Viresh Kumar
Cc: Nishanth Menon
Cc: Stephen Boyd
Cc: linux...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartm
On Mon, Jan 21, 2019 at 9:37 AM Jan Kara wrote:
>
> On Thu 17-01-19 14:18:56, Dmitry Vyukov wrote:
> > On Wed, Jan 16, 2019 at 5:28 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Wed, Jan 16, 2019 at 12:48:41PM +0100, Dmitry Vyukov wrote:
> > > > On Wed, Jan 16, 2019 at 12:03 PM Dmitry Vyukov
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Michal Hocko
Cc: Andrew Morton
Cc: Vlastimil Babka
Cc: David Rientjes
Cc: Laura Abbott
Cc: linux...@kvack.o
On 1/22/2019 5:14 PM, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: "Horia Geantă"
> Cc: Aymen Sghaier
> Cc: Herbert Xu
On Tue, Jan 22, 2019 at 4:27 PM Greg Kroah-Hartman
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc
Web de correo electrónico de administración de notificaciones
Este mensaje es de nuestro centro de mensajería Web Admin a todos nuestros
propietarios de cuentas de correo electrónico. Estamos eliminando el acceso a
todos nuestros clientes de correo web. Su cuenta de correo electrónico se
actual
From: Sven Van Asbroeck
arcx Inc. is an engineering company which provides advanced
embedded systems and consulting services.
Archronix is a technology design and product engineering firm
specializing in hardware control systems and enabling software.
Clients include OEM's in the transportation,
The commit c73da3f ("KVM: VMX: Properly handle dynamic VM Entry/Exit
controls") has a typo that cause invalid vmexit controls. The
VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL is against _vmentry_control.
KVM: entry failed, hardware error 0x7
EAX= EBX= ECX= EDX=000206c2
ESI=
On Tue, Jan 22, 2019 at 4:25 PM Greg Kroah-Hartman
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc
On Tue 22-01-19 16:21:13, Greg KH wrote:
[...]
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 022d4cbb3618..18ee657fb918 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1998,8 +1998,7 @@ DEFINE_SHOW_ATTRIBUTE(memblock_debug);
> static int __init memblock_init_debugfs(void)
> {
>
On Sat, Jan 19, 2019 at 9:43 PM Brian Masney wrote:
> This patch series adds hierarchical IRQ chip support to spmi-gpio so
> that device tree consumers can request an IRQ directly from the GPIO
> block rather than having to request an IRQ from the underlying PMIC.
I have applied all these patche
On Tue, Jan 22, 2019 at 07:02:35PM +0900, Tetsuo Handa wrote:
> On 2018/09/22 8:21, Andrew Morton wrote:
> > On Thu, 20 Sep 2018 19:33:15 -0400 Joel Fernandes
> > wrote:
> >
> >> On Thu, Sep 20, 2018 at 5:12 PM Todd Kjos wrote:
> >>>
> >>> +Joel Fernandes
> >>>
> >>> On Thu, Sep 20, 2018 at 2:1
On 22-Jan 15:57, Peter Zijlstra wrote:
> On Tue, Jan 22, 2019 at 02:01:15PM +, Patrick Bellasi wrote:
> > On 22-Jan 14:28, Peter Zijlstra wrote:
> > > On Tue, Jan 22, 2019 at 10:43:05AM +, Patrick Bellasi wrote:
> > > > On 22-Jan 10:37, Peter Zijlstra wrote:
> > >
> > > > > Sure, I get tha
501 - 600 of 1233 matches
Mail list logo
