Hi Petr,
On Tue, Apr 09, 2019 at 04:14:30PM +0200, Petr Mladek wrote:
> On Mon 2019-04-01 18:48:04, Feng Tang wrote:
> > Currently on panic, kernel will lower the loglevel and print out
> > new printk msg only. With this patch, user can configure the
> > "panic_print" to see all dmesg in buffer, s
On 10/04/19 11:38, Vitaly Kuznetsov wrote:
> Early RFC, based on state_test.
>
> Add a simplistic test for SMM. Currently it fails with
> "Unexpected result from KVM_SET_NESTED_STATE" even when a patch fixing
> rsm after VMXON is added. There's likey some other issue in nested
> save/restore when
Enable Vivante GPU driver for stm32mp157a-dk1 and dk2 boards.
Signed-off-by: Pierre-Yves MORDRET
---
Version history:
v2:
* move GPU reserved memeory out of bottom DDR to let free this area for
U-Boot
v1:
* Initial
---
---
arch/arm/boot/dts/stm32mp157a-dk1.dts |
On 4/10/19 12:47 PM, Flavio Suligoi wrote:
Add an info message for the PXA2xx device driver start-up,
with the indication of:
- mode (slave device or master controller)
- transfer mode (DMA or GPIO)
Signed-off-by: Flavio Suligoi
---
v1: - first version
v2: - remove warning message "no
On 10-04-19, 09:57, Quentin Perret wrote:
> Hmm, indeed... I thought cpufreq_table_validate_and_sort() was actively
> sorting the table but it seems I was wrong.
>
> But I _think_ in practice the freq table actually happens to be sorted
> for the upstream cpufreq drivers with the CPUFREQ_IS_COOLIN
While current node handling is probably terribly broken for memory block
devices that span several nodes (only possible when added during boot,
and something like that should be blocked completely), properly put the
device reference we obtained via find_memory_block() to get the nid.
Fixes: d0dc12
> On 4/10/19 12:47 PM, Flavio Suligoi wrote:
> > Add an info message for the PXA2xx device driver start-up,
> > with the indication of:
> >
> > - mode (slave device or master controller)
> > - transfer mode (DMA or GPIO)
> >
> > Signed-off-by: Flavio Suligoi
> > ---
> >
> > v1: - first version
> >
On 10/04/2019 10:27, Qais Yousef wrote:
[...]
>> @@ -1066,9 +1067,14 @@ static struct sched_group *get_group(int cpu, struct
>> sd_data *sdd)
>> sg = *per_cpu_ptr(sdd->sg, cpu);
>> sg->sgc = *per_cpu_ptr(sdd->sgc, cpu);
>>
>> -/* For claim_allocations: */
>> -atomic_inc(&sg->re
* Reshetova, Elena wrote:
> > * Josh Poimboeuf wrote:
> >
> > > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > > > index 7bc105f47d21..38ddc213a5e9 100644
> > > > --- a/arch/x86/entry/common.c
> > > >
Hi,
On Wed, 10 Apr 2019 at 10:03, Erwan Le Ray wrote:
>
> - This patch allows to configure UART instance for early console by setting
> physical and virtual base addresses.
> - This patch adds UART early console support for stm32h7 and stm32mp157c.
*Newbie kernel speaking*
I think this patch in
Hi All,
Any comments on below patch?
Thanks & Regards,
Sanjay Mehta
-Original Message-
From: Mehta, Sanju
Sent: Friday, March 29, 2019 5:03 PM
To: S-k, Shyam-sundar ; jdma...@kudzu.us;
dave.ji...@intel.com; alle...@gmail.com
Cc: linux-...@googlegroups.com; linux-kernel@vger.kernel.org
On 28-03-19, 20:58, Sibi Sankar wrote:
> Add and export 'dev_pm_opp_update_voltage' to find and update voltage
> of an opp for a given frequency. This will be useful to update the opps
> with voltages read back from firmware.
>
> Signed-off-by: Sibi Sankar
> ---
> drivers/opp/core.c | 62 +++
> > > On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> > > > diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> > > > index 7bc105f47d21..38ddc213a5e9 100644
> > > > --- a/arch/x86/entry/common.c
> > > > +++ b/arch/x86/entry/common.c
> > > > @@ -35,6 +35,12 @@
> >
Resolve checkpatch warning for using symbolic permissions by replacing
them with octal permissions.
Signed-off-by: Himadri Pandya
---
drivers/staging/gasket/gasket_sysfs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/gasket_sysfs.h
b/drivers/staging
On Wed, Apr 10, 2019 at 11:14:45AM +0530, Naga Sureshkumar Relli wrote:
> When building with CONFIG_SPI_MEM is not set
> gc warns this:
>
> drivers/spi/spi-zynq-qspi.o: In function `zynq_qspi_supports_op':
> spi-zynq-qspi.c:(.text+0x1da): undefined reference to
> `spi_mem_default_supports_op'
>
On 04/10/19 11:17, Valentin Schneider wrote:
> On 10/04/2019 10:27, Qais Yousef wrote:
> [...]
> >> @@ -1066,9 +1067,14 @@ static struct sched_group *get_group(int cpu,
> >> struct sd_data *sdd)
> >>sg = *per_cpu_ptr(sdd->sg, cpu);
> >>sg->sgc = *per_cpu_ptr(sdd->sgc, cpu);
> >>
> >> -
Paolo Bonzini writes:
> On 10/04/19 11:38, Vitaly Kuznetsov wrote:
>> Early RFC, based on state_test.
>>
>> Add a simplistic test for SMM. Currently it fails with
>> "Unexpected result from KVM_SET_NESTED_STATE" even when a patch fixing
>> rsm after VMXON is added. There's likey some other issue
On Tue, 9 Apr 2019 15:32:22 -0400 (EDT)
Mathieu Desnoyers wrote:
> Hi,
>
> We are about to include the code signature required prior to restartable
> sequences abort handlers into glibc, which will make this ABI choice final.
> We need architecture maintainer input on that signature value.
>
>
On 28-03-19, 20:58, Sibi Sankar wrote:
> Add support to parse and update OPP tables attached to the cpu nodes.
>
> Signed-off-by: Sibi Sankar
> ---
> drivers/cpufreq/qcom-cpufreq-hw.c | 29 +++--
> 1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers
On 09 April 2019 15:41, Hans de Goede wrote:
> Hi,
>
> On 09-04-19 15:06, Heikki Krogerus wrote:
> > On Tue, Apr 09, 2019 at 04:02:30PM +0300, Heikki Krogerus wrote:
> >> +Hans
> >>
> >> On Mon, Apr 08, 2019 at 10:17:35PM +0800, Kyle Tso wrote:
> >>> On Fri, Apr 5, 2019 at 9:42 PM Guenter Roeck
On Mon, Apr 08, 2019 at 05:22:44PM +0200, Flavio Suligoi wrote:
> Add an info message for the PXA2xx device driver start-up,
> with the indication of the transfer mode used (DMA or GPIO).
>
> This info is useful to individuate the timing when
> the module starts.
Adding this sort of message to ev
On Wed, 2019-04-10 at 10:27 +0200, Dmitry Vyukov wrote:
> On Wed, Apr 10, 2019 at 2:26 AM Al Viro wrote:
> >
> > On Tue, Apr 09, 2019 at 07:36:00AM -0700, syzbot wrote:
> > > Bisection is inconclusive: the first bad commit could be any of:
> >
> > [snip the useless pile]
> >
> > > bisection log
On Wednesday 10 Apr 2019 at 15:44:23 (+0530), Viresh Kumar wrote:
> On 10-04-19, 09:57, Quentin Perret wrote:
> > Hmm, indeed... I thought cpufreq_table_validate_and_sort() was actively
> > sorting the table but it seems I was wrong.
> >
> > But I _think_ in practice the freq table actually happen
On Mon, Apr 08, 2019 at 03:24:08PM +, Pascal PAILLET-LME wrote:
> +config REGULATOR_STM32_PWR
> + bool "STMicroelectronics STM32 PWR"
> + depends on ARCH_STM32
There's no build time dependency here, please also add an || COMPILE_TEST to
help with build coverage.
> +int stm32_pwr_reg
Hi,
This series enables interrupt support for GPIOs on port 3. Those are the
GPIOs that are connected directl to an interrupt controller (sic1 or
sic2). This was tested on a custom LPC3250 design.
The binding includes support for interrupts on port 0 and port 1 but
this requires the registration
Add the interrupts for the GPIO controller.
Signed-off-by: Alexandre Belloni
---
arch/arm/boot/dts/lpc32xx.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 20b38f4ade37..9c61b1856291 100644
-
On Wed, Apr 10, 2019 at 10:37:30AM +, Viorel Suman wrote:
> Remove "model" attribute.
>
> Signed-off-by: Viorel Suman
> Acked-by: Nicolin Chen
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
signature.asc
Descri
Interrupt support was disabled "temporarily" in commit 320a6480ef24 ("gpio:
lpc32xx: disable broken to_irq support").
Reenable to_irq for port 3 as they are directly connected to an interrupt
controller and a simple lookup is working.
Signed-off-by: Alexandre Belloni
---
drivers/gpio/gpio-lpc32
Some of the LPC32xx gpios are wired directly to one of the interrupt
controllers while port 0 and port 1 share the same interrupt for their
interrupt capable gpios.
Cc: Rob Herring
Signed-off-by: Alexandre Belloni
---
Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt | 4
1 file chan
On Wed, Apr 10, 2019 at 12:10 PM Jan Kara wrote:
>
> On Tue 09-04-19 21:01:54, Amir Goldstein wrote:
> > On Tue, Apr 9, 2019 at 6:43 PM Jan Kara wrote:
> > > On Tue 09-04-19 14:49:22, Amir Goldstein wrote:
> > > > Commit 23d0127096cb ("fs/sync.c: make sync_file_range(2) use
> > > > WB_SYNC_NONE
On Wed, Apr 10, 2019 at 03:30:22PM +0530, Himadri Pandya wrote:
> Fix checkpatch warning "Alignment should match open parenthesis".
>
> Signed-off-by: Himadri Pandya
> ---
> drivers/staging/fbtft/fb_tinylcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/stagi
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.locking/core
head: 5c587ed687faed2eb0afdd669ddd167d0d940236
commit: 2d6f2f61367455179ee140b3d4af6974d3e5d06d [25/29] locking/rwsem: Enable
time-based spinning on reader-owned rwsem
config: riscv-allyesconfig (attached as .c
Hi Mark,
On Mi, 2019-04-10 at 11:39 +0100, Mark Brown wrote:
> On Wed, Apr 10, 2019 at 10:37:30AM +, Viorel Suman wrote:
> >
> > Remove "model" attribute.
> >
> > Signed-off-by: Viorel Suman
> > Acked-by: Nicolin Chen
> Please use subject lines matching the style for the subsystem. This
>
On 10/04/19 4:12 PM, Dan Carpenter wrote:
On Wed, Apr 10, 2019 at 03:30:22PM +0530, Himadri Pandya wrote:
Fix checkpatch warning "Alignment should match open parenthesis".
Signed-off-by: Himadri Pandya
---
drivers/staging/fbtft/fb_tinylcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.locking/core
head: 5c587ed687faed2eb0afdd669ddd167d0d940236
commit: 0d8bd477cd9602fb18bee6e3dae41c5fda9cebab [28/29] locking/rwsem: Merge
owner into count on x86-64
config: riscv-tinyconfig (attached as .config)
compiler: r
Add the interrupts for the GPIO controller.
Signed-off-by: Alexandre Belloni
---
the previous patch was missing a line, sorry about that.
Changes in v2:
- add missing interrupt for gpi19
arch/arm/boot/dts/lpc32xx.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --
Hi,
everything you want is already available and on the way to mainline
concerning support for various FPGA loading modes or available for
checkout from a git repository.
All that has already been discussed on the mailing list.
FPGA loading interface is available here [1].
Patchset missing fo
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.locking/core
head: 5c587ed687faed2eb0afdd669ddd167d0d940236
commit: 2d6f2f61367455179ee140b3d4af6974d3e5d06d [25/29] locking/rwsem: Enable
time-based spinning on reader-owned rwsem
config: riscv-tinyconfig (attached as .con
Hey Gary,
On 4/10/19 9:35 AM, Gary Bisson wrote:
Hi,
On Tue, Apr 9, 2019 at 2:07 AM Robert Foss wrote:
Hey Fabio,
On 4/8/19 10:37 PM, Fabio Estevam wrote:
Hi Robert,
[Adding Gary]
Adding Troy, I'm no longer a full-time employee at Boundary Devices.
On Mon, Apr 8, 2019 at 2:54 PM Rober
Mostly minor grammer fixes:
* Will Deacon wrote:
> + (*) readX(), writeX():
>
> + The readX() and writeX() MMIO accessors take a pointer to the peripheral
> + being accessed as an __iomem * parameter. For pointers mapped with the
> + default I/O attributes (e.g. those returned by
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
It's only used in the source file where it is defined and it's using the
stack_trace_ namespace. Rename it to free it up for stack trace related
functions.
Signed-off-by: Thomas Gleixner
Cc: Steven Rostedt
---
include/linux/ftrace.h |1 -
kernel/trace/trace_stack.c |4 ++--
2 files
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
Signed-off-by: Thomas Gleixner
Cc: Michal Hocko
Cc: linux...@kvack.org
Cc: Mike Rapoport
Cc: Andrew Morton
---
mm/page_owner.c |3 ---
1 file changed, 3 deletions(-)
--- a/mm/page_owner.c
+++ b/mm/page_o
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
---
kernel/latencytop.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
--- a/kernel/latencytop.c
+++ b/kernel/latencytop.c
@@ -1
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
Signed-off-by: Thomas Gleixner
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: Dmitry Vyukov
Cc: kasan-...@googlegroups.com
Cc: linux...@kvack.org
---
mm/kasan/common.c | 30 -
There is only one caller of check_prev_add() which hands in a zeroed struct
stack trace and a function pointer to save_stack(). Inside check_prev_add()
the stack_trace struct is checked for being empty, which is always
true. Based on that one code path stores a stack trace which is unused. The
comm
It's only used in trace.c and there is absolutely no point in compiling it
in when user space stack traces are not supported.
Signed-off-by: Thomas Gleixner
Cc: Steven Rostedt
---
kernel/trace/trace.c | 14 --
kernel/trace/trace.h |8
2 files changed, 8 insertions(+),
The latest audmix patch-set (v5) had the "model" attribute removed as
requested by Nicolin Chen, but looks like (v4) version of DAI driver
reached "for-next" branch - fix this by removing "model" attribute.
Asside of this fix object reference leaks in machine probe reported by
Julia Lawall.
Viorel
No more users of the struct stack_trace based interfaces. Remove them.
Remove the macro stubs for !CONFIG_STACKTRACE as well as they are pointless
because the storage on the call sites is conditional on CONFIG_STACKTRACE
already. No point to be 'smart'.
Signed-off-by: Thomas Gleixner
---
includ
The per cpu stack trace buffer usage pattern is odd at best. The buffer has
place for 512 stack trace entries on 64-bit and 1024 on 32-bit. When
interrupts or exceptions nest after the per cpu buffer was acquired the
stacktrace length is hardcoded to 8 entries. 512/1024 stack trace entries
in kerne
No more users of the struct stack_trace based interfaces.
Signed-off-by: Thomas Gleixner
---
include/linux/stackdepot.h |4
lib/stackdepot.c | 20
2 files changed, 24 deletions(-)
--- a/include/linux/stackdepot.h
+++ b/include/linux/stackdepot.h
@@ -23,
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
Signed-off-by: Thomas Gleixner
Cc: Steven Rostedt
---
kernel/trace/trace.c | 34 +-
1 file changed, 9 insertions(+), 25 deletions(-)
--- a/kernel/trace/trace.c
+++
Use "of_device_id.data" to specify the machine driver
instead of "model" DTS attribute.
Signed-off-by: Viorel Suman
Acked-by: Nicolin Chen
---
sound/soc/fsl/fsl_audmix.c | 43 +++
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/sound/soc/f
Replace the indirection through struct stack_trace by using the storage
array based interfaces and storing the information is a small lockdep
specific data structure.
Signed-off-by: Thomas Gleixner
---
include/linux/lockdep.h |9 +++--
kernel/locking/lockdep.c | 39 +++
Thanks Keith, this solves my issue.
On a machine where node4 (PMEM) is close to node0 and node1 (1st socket
SNCs), hotplugging that node makes node0 and node1 appear as initiators
to node4 (and node4 as target to them). Same for the other socket. And
perf attributes look good.
Reported-and-tested
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface. This results in less storage space and
indirection.
Signed-off-by: Thomas Gleixner
Cc: dm-de...@redhat.com
Cc: Mike Snitzer
Cc: Alasdair Kergon
---
drivers/md/persistent-data/dm-block-ma
There should be no trouble to understand dev = pdev->dev.
This can save some space to have more print info or save
some wrapped lines.
Signed-off-by: Viorel Suman
Suggested-by: Nicolin Chen
---
sound/soc/fsl/fsl_audmix.c | 27 +--
1 file changed, 13 insertions(+), 14 del
The indirection through struct stack_trace is not necessary at all. Use the
storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: Steven Rostedt
---
kernel/trace/trace_events_hist.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
--- a/kernel/trace/trace_events
Signed-off-by: Thomas Gleixner
---
kernel/locking/lockdep.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1522,10 +1522,9 @@ static inline int class_equal(struct loc
}
static noinline int print_circular_bug
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: Alexey Dobriyan
---
fs/proc/base.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
--- a/fs/proc/base.c
+++
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: Akinobu Mita
---
lib/fault-inject.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
--- a/lib/fault-inject.c
+++ b/lib/fault-injec
Hey Viresh,
Thanks for the review!
On 2019-04-10 15:54, Viresh Kumar wrote:
On 28-03-19, 20:58, Sibi Sankar wrote:
Add and export 'dev_pm_opp_update_voltage' to find and update voltage
of an opp for a given frequency. This will be useful to update the
opps
with voltages read back from firmwar
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
Signed-off-by: Thomas Gleixner
Cc: Catalin Marinas
Cc: linux...@kvack.org
---
mm/kmemleak.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
--- a/mm/kmemleak.c
+++
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
The original code in all printing functions is really wrong. It allocates a
storage array on stack which is unused because depot_fetch_stack() does not
store anything in it. It overwrites the entries po
Commit-ID: 3966c3feca3fd10b2935caa0b4a08c7dd59469e5
Gitweb: https://git.kernel.org/tip/3966c3feca3fd10b2935caa0b4a08c7dd59469e5
Author: Lendacky, Thomas
AuthorDate: Tue, 2 Apr 2019 15:21:18 +
Committer: Ingo Molnar
CommitDate: Wed, 10 Apr 2019 13:03:18 +0200
x86/perf/amd: Remove ne
All operations with stack traces are based on struct stack_trace. That's a
horrible construct as the struct is a kitchen sink for input and
output. Quite some usage sites embed it into their own data structures
which creates weird indirections.
There is absolutely no point in doing so. For all use
The struct stack_trace indirection in the stack depot functions is a truly
pointless excercise which requires horrible code at the callsites.
Provide interfaces based on plain storage arrays.
Signed-off-by: Thomas Gleixner
---
include/linux/stackdepot.h |4 ++
lib/stackdepot.c |
Replace the indirection through struct stack_trace with an invocation of
the storage array based interface.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: Pekka Enberg
Cc: linux...@kvack.org
Cc: David Rientjes
Cc: Christoph Lameter
---
mm/slub.c | 12
1 file changed, 4 i
On Wed, Apr 10, 2019 at 12:28:22PM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace with an invocation of
> the storage array based interface.
This seems to be missing some context, at least stack_trace_save does
not actually exist in mainline.
Please always send
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
Signed-off-by: Thomas Gleixner
---
kernel/backtracetest.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
--- a/kernel/backtracetest.c
+++ b/kernel/backtracetest.c
@@ -48,19 +48,1
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
No architecture terminates the stack trace with ULONG_MAX anymore. As the
code checks the number of entries stored anyway there is no point in
keeping all that ULONG_MAX magic around.
The histogram code zeroes the storage before saving the stack, so if the
trace is shorter than the maximum number
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
Signed-off-by: Thomas Gleixner
Cc: Andrey Ryabinin
Cc: Alexander Potapenko
Cc: kasan-...@googlegroups.com
Cc: Dmitry Vyukov
Cc: linux...@kvack.org
---
mm/kasan/common.c |3 ---
1 file changed, 3 deletions
No architecture terminates the stack trace with ULONG_MAX anymore. The
consumer terminates on the first zero entry or at the number of entries, so
no functional change.
Remove the cruft.
Signed-off-by: Thomas Gleixner
---
fs/proc/base.c |3 +--
kernel/latencytop.c | 12 ++--
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
While at it remove the pointless loop of clearing the stack array
completely. It's sufficient to clear the last entry as the consumers break
out on the first zeroed entry anyway.
Signed-off-by: Thomas Gleixner
C
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Will Deacon
---
kernel/locking/lockdep.c | 11 ---
1 file changed, 11 deletions(-)
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
Hi Martin,
On 2019/4/5 12:30, Martin Blumenstingl wrote:
Hi Liang,
On Fri, Mar 29, 2019 at 8:44 AM Liang Yang wrote:
Hi Martin,
On 2019/3/29 2:03, Martin Blumenstingl wrote:
Hi Liang,
[..]
I don't think it is caused by a different NAND type, but i have followed
the some test on my GX
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
On Thu, Feb 28, 2019 at 09:57:00PM +0800, Pengcheng Li wrote:
> From: Youlin Wang
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
Please don't ignore review comments, people are generally making them
for a reason and a
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by:
Struct stack_trace is a sinkhole for input and output parameters which is
largely pointless for most usage sites. In fact if embedded into other data
structures it creates indirections and extra storage overhead for no benefit.
Looking at all usage sites makes it clear that they just require an
in
On Thu, Feb 28, 2019 at 09:57:41PM +0800, Pengcheng Li wrote:
> +Required properties:
> +
> +- compatible: should be one of the following:
> + - "hisilicon,hi3660-i2s-1.0"
> +- reg: physical base address of the i2s controller unit and length of
> + memory mapped region.
This binding is inaccu
On 2019-04-10 16:03, Viresh Kumar wrote:
On 28-03-19, 20:58, Sibi Sankar wrote:
Add support to parse and update OPP tables attached to the cpu nodes.
Signed-off-by: Sibi Sankar
---
drivers/cpufreq/qcom-cpufreq-hw.c | 29 +++--
1 file changed, 27 insertions(+), 2 deleti
Guenter Roeck writes:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patche
Resending the patch since the first attempt never made
it to lkml.
changes in v2:
- alloca() is changed to __builtin_alloca() in order
to be compatible with 32 bit versions
Elena Reshetova (1):
x86/entry/64: randomize kernel stack offset upon syscall
arch/Kconfig| 15 +
If CONFIG_RANDOMIZE_KSTACK_OFFSET is selected,
the kernel stack offset is randomized upon each
entry to a system call after fixed location of pt_regs
struct.
This feature is based on the original idea from
the PaX's RANDKSTACK feature:
https://pax.grsecurity.net/docs/randkstack.txt
All the credits
On 10-04-19, 16:46, Sibi Sankar wrote:
> On 2019-04-10 16:03, Viresh Kumar wrote:
> > On 28-03-19, 20:58, Sibi Sankar wrote:
> > > Add support to parse and update OPP tables attached to the cpu nodes.
> > >
> > > Signed-off-by: Sibi Sankar
> > > ---
> > > drivers/cpufreq/qcom-cpufreq-hw.c | 29 +
On Sat, Apr 06, 2019 at 11:30:47AM -0400, Sasha Levin wrote:
> On Wed, Apr 03, 2019 at 09:27:28PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Apr 03, 2019 at 09:18:27PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Apr 02, 2019 at 03:33:16PM -0400, Sasha Levin wrote:
> > > > This patch adds support for
On Wed, Apr 10, 2019 at 1:05 PM Thomas Gleixner wrote:
>
> No architecture terminates the stack trace with ULONG_MAX anymore. Remove
> the cruft.
>
> Signed-off-by: Thomas Gleixner
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: kasan-...@googlegroups.com
> Cc: Dmitry Vyukov
> Cc: linux.
Four packages exist for stm32mp157 die. As ball-out is different between
them, this patch covers those differences by creating dedicated pinctrl
dtsi files. Each dtsi pinctrl package file describes the package ball-out
through gpio-ranges.
stm32mp157a-dk1 / dk2 boards embed a STM32MP_PKG_AC (TFBGA
A same SoC can be available in several packages. Differences between
packages are only the numbers of available balls. In order not to write
a driver for each new package, same driver (ex: pinctrl-stm32mp157.c) will
be used. This patch introduces the "package" property for each pin. So on a
same dr
Add "st,package" entry. Possibles values are:
-STM32MP_PKG_AA for LFBGA448 (18*18) package
-STM32MP_PKG_AB for LFBGA354 (16*16) package
-STM32MP_PKG_AC for TFBGA361 (12*12) package
-STM32MP_PKG_AD for TFBGA257 (10*10) package
Signed-off-by: Alexandre Torgue
diff --git a/Documentation/devicetree/
Align pins names with names provided in official stm32mp157 datasheet
available on st.com.
Signed-off-by: Alexandre Torgue
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32mp157.c
b/drivers/pinctrl/stm32/pinctrl-stm32mp157.c
index 374ccc2..320544f 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32
Hi Linus,
Can you please pull the following regression fix for apparmor
Thanks!
- John
The following changes since commit 771acc7e4a6e5dba779cb1a7fd851a164bc81033:
Bluetooth: btusb: request wake pin with NOAUTOEN (2019-04-09 17:38:24 -1000)
are available in the Git repository at:
git://
syzbot has bisected this bug to:
commit 8f840e47f190cbe61a96945c13e9551048d42cef
Author: Xin Long
Date: Thu Apr 14 07:35:33 2016 +
sctp: add the sctp_diag.c file
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1719585b20
start commit: 0072a0c1 Merge tag 'media/v4.2
101 - 200 of 869 matches
Mail list logo
