On Tue, 2019-01-22 at 16:12 +0100, Jiri Slaby wrote:
> Remove macros which are only wrappers around standard operations. When
> we expand them into code, we see that sisusbcon_memsetw can simply use
> memset16 and sisusbcon_putcs can just call memcpy. So make the code
> compact.
[]
> diff --git
From: Nicolai Stange
The ppc64 specific implementation of the reliable stacktracer,
save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
trace" whenever it finds an exception frame on the stack. Stack frames
are classified as exception frames if the STACK_FRAME_REGS_MARKER
Mostly cosmetic changes:
- Group common stack pointer code at the top
- Simplify the first frame logic
- Code stackframe iteration into for...loop construct
- Check for trace->nr_entries overflow before adding any into the array
Suggested-by: Nicolai Stange
Signed-off-by: Joe Lawrence
---
This patchset fixes a false negative report (ie, unreliable) from the
ppc64 reliable stack unwinder, discussed here [1] when it may
inadvertently trip over a stale exception marker left on the stack.
The first two patches fix this bug. Nicolai's change clears the marker
from the stack when an
On Tue, Jan 22, 2019 at 04:21:06PM +0100, 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.
Given that all the rest of the function
On Tue, Jan 22, 2019 at 03:34:14PM +, Quentin Perret wrote:
> On Monday 07 Jan 2019 at 12:26:08 (+), Quentin Perret wrote:
> > diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
> > index d9dc2c38764a..8ef48daa62ff 100644
> > --- a/kernel/power/energy_model.c
> > +++
Dt-bindings doc about Loongson-1 interrupt controller
Signed-off-by: Jiaxun Yang
---
.../loongson,ls1x-intc.txt| 28 +++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
diff
Joerg,
On 1/22/19 5:44 PM, j...@8bytes.org wrote:
> Hi Suravee,
>
> On Thu, Jan 17, 2019 at 08:44:36AM +, Suthikulpanit, Suravee wrote:
>> Then, in __domain_flush_pages, we issue command when the dev_iommu[] >= 0.
>> This should preserve previous behavior, and only add flushing condition to
On Tue, Jan 22, 2019 at 4:40 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 22, 2019 at 04:28:42PM +0100, Rafael J. Wysocki wrote:
> > 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.
On Tue, Jan 22, 2019 at 04:30:38PM +0100, Rafael J. Wysocki wrote:
> 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
On Tue, Jan 22, 2019 at 04:31:02PM +0100, Michal Hocko wrote:
> 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 @@
On in tree builds, subsequent builds will incorrectly include
the intermediate file 'processed-schema.yaml' with the input schema
files resulting in a build error. Update the find command to ignore
processed-schema.yaml.
Signed-off-by: Rob Herring
---
Documentation/devicetree/bindings/Makefile
Larry Finger writes:
> On 1/22/19 9:21 AM, 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: Ping-Ke Shih
>> Cc: Kalle
On Tue, Jan 22, 2019 at 11:48:36AM +0200, Matti Vaittinen wrote:
> Initial support for watchdog block included in ROHM BD70528
> power management IC.
>
> Configurations for low power states are still to be checked.
>
> Signed-off-by: Matti Vaittinen
> ---
> drivers/watchdog/Kconfig | 12
> @@ -131,7 +159,7 @@ let rec rcu-fence = rcu-gp | srcu-gp |
> (rcu-fence ; rcu-link ; rcu-fence)
>
> (* rb orders instructions just as pb does *)
> -let rb = prop ; po ; rcu-fence ; po? ; hb* ; pb*
> +let rb = prop ; po ; rcu-fence ; po? ; hb* ; pb* ; [marked]
Testing has revealed some
On 1/22/19 9:21 AM, 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: Kalle Valo
Cc: linux-wirel...@vger.kernel.org
Cc:
This controller appeared on Loongson-1 family MCUs
including Loongson-1B and Loongson-1C.
Signed-off-by: Jiaxun Yang
---
drivers/irqchip/Kconfig| 9 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ls1x.c | 194 +
3 files changed, 204
On 1/22/19 9:21 AM, 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: Larry Finger
Cc: Kalle Valo
Cc:
On 22-Jan 16:21, Peter Zijlstra wrote:
> 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,
> >
On Mon, Jan 21, 2019 at 09:42:15AM -0800, Davidlohr Bueso wrote:
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 6976e17dba68..640ae8a47c73 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -59,7 +59,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
>
This is the same sort of error we saw in [1].
Gigantic hugepages crosses several memblocks, so it can be
that the page we get in scan_movable_pages() is a page-tail
belonging to a 1G-hugepage.
If that happens, page_hstate()->size_to_hstate() will return NULL,
and we will blow up in
On 1/22/19 9:21 AM, 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: Ping-Ke Shih
Cc: Kalle Valo
Cc:
On Mon, 2019-01-21 at 14:29 +0200, Amir Goldstein wrote:
> On Mon, Jan 21, 2019 at 2:00 PM Mimi Zohar wrote:
> >
> > On Thu, 2019-01-17 at 15:34 -0600, Goldwyn Rodrigues wrote:
> > > On 13:47 18/12, Mimi Zohar wrote:
> > > > If tmpfiles can be made persistent, then newly created tmpfiles need to
On 1/21/19 4:18 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/21/19 2:20 PM, Liam Mark wrote:
>>> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>>>
On 1/21/19 1:44 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>
>> On Sat, Jan
On 22-Jan 16:13, Peter Zijlstra wrote:
> On Tue, Jan 22, 2019 at 02:43:29PM +, Patrick Bellasi wrote:
> > On 22-Jan 14:56, Peter Zijlstra wrote:
> > > On Tue, Jan 15, 2019 at 10:15:04AM +, Patrick Bellasi wrote:
> > >
> > > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> >
On Tue, Jan 22, 2019 at 4:34 PM Joel Fernandes wrote:
>
> On Tue, Jan 22, 2019 at 02:59:29PM +0100, Dmitry Vyukov wrote:
> > On Fri, Aug 10, 2018 at 6:18 PM Matthew Wilcox wrote:
> > >
> > >
> > > This is another ashmem lockdep splat. Forwarding to the appropriate
> > > ashmem
> > > people.
>
On Mon, Jan 21, 2019 at 10:22 PM Manivannan Sadhasivam
wrote:
>
> Add devicetree binding for LS1012A SoC based Oxalis board.
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Rob Herring
On Tue, Jan 22, 2019 at 04:28:42PM +0100, Rafael J. Wysocki wrote:
> 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
On Mon, Jan 21, 2019 at 10:22 PM Manivannan Sadhasivam
wrote:
>
> Fix devicetree bindings for Freescale LS1012A and LS1021A SoC based boards.
>
> Fixes: a1a38e1f4d1d ("dt-bindings: arm: Convert FSL board/soc bindings to
> json-schema")
> Signed-off-by: Manivannan Sadhasivam
> ---
>
On Mon, 2019-01-21 at 17:59 +0800, Kairui Song wrote:
> This patch let kexec_file_load makes use of .platform keyring as fall
> back if it failed to verify a PE signed image against secondary or
> builtin key ring, make it possible to verify kernel image signed with
> preboot keys as well.
>
>
On Mon, 2019-01-21 at 17:59 +0800, Kairui Song wrote:
> commit 9dc92c45177a ('integrity: Define a trusted platform keyring')
> introduced a .platform keyring for storing preboot keys, used for
> verifying kernel images' signature. Currently only IMA-appraisal is able
> to use the keyring to verify
On Monday 07 Jan 2019 at 12:26:08 (+), Quentin Perret wrote:
> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
> index d9dc2c38764a..8ef48daa62ff 100644
> --- a/kernel/power/energy_model.c
> +++ b/kernel/power/energy_model.c
> @@ -10,6 +10,7 @@
>
> #include
>
On Tue, Jan 22, 2019 at 02:59:29PM +0100, Dmitry Vyukov wrote:
> On Fri, Aug 10, 2018 at 6:18 PM Matthew Wilcox wrote:
> >
> >
> > This is another ashmem lockdep splat. Forwarding to the appropriate ashmem
> > people.
>
>
> Let's test Tetsuo's patch
>
> #syz test:
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
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
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
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
>
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)
> {
>
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
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
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
>
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
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:
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: Viresh Kumar
Cc: Nishanth Menon
Cc: Stephen Boyd
Cc: linux...@vger.kernel.org
Signed-off-by: Greg
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:
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
---
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:
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
---
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
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
---
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
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
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
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
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
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
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
---
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
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
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
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
---
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
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
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:
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
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
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
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
---
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
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
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
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:
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
---
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
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
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:
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
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
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
---
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 --
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
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: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
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.
And as the return value does not matter at all, no need to save the
dentry in struct backing_dev_info, so delete
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
---
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
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
---
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
---
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: Johannes Berg
Cc: Emmanuel Grumbach
Cc: Luca Coelho
Cc: Intel Linux Wireless
Cc: Kalle Valo
Cc:
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
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:
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.
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:
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
---
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:
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:
601 - 700 of 1233 matches
Mail list logo
