Reviewed-by: Aurelien Aptel
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Reviewed-by: Aurelien Aptel
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On Thu, Oct 04, 2018 at 10:03:21AM +0200, Joerg Roedel wrote:
> I also triggered this when working in the PTI-x32 code. It always
> happens on a 32-bit PAE kernel for me.
>
> Tracking it down I ended up in (iirc) arch/x86/mm/pageattr.c
> function static_protections():
>
> /*
On Thu, Oct 04, 2018 at 10:03:21AM +0200, Joerg Roedel wrote:
> I also triggered this when working in the PTI-x32 code. It always
> happens on a 32-bit PAE kernel for me.
>
> Tracking it down I ended up in (iirc) arch/x86/mm/pageattr.c
> function static_protections():
>
> /*
Hi Peter,
On 04/10/2018 09:57, Peter Zijlstra wrote:
> On Thu, Oct 04, 2018 at 09:42:07AM +0200, Daniel Lezcano wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index b88a145..5605f03 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2873,25 +2873,12 @@
Hi Peter,
On 04/10/2018 09:57, Peter Zijlstra wrote:
> On Thu, Oct 04, 2018 at 09:42:07AM +0200, Daniel Lezcano wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index b88a145..5605f03 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2873,25 +2873,12 @@
On Thu, Oct 04, 2018 at 09:42:07AM +0200, Daniel Lezcano wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b88a145..5605f03 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2873,25 +2873,12 @@ unsigned long long nr_context_switches(void)
>
> return
On Thu, Oct 04, 2018 at 09:42:07AM +0200, Daniel Lezcano wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b88a145..5605f03 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2873,25 +2873,12 @@ unsigned long long nr_context_switches(void)
>
> return
On (10/04/18 16:44), Sergey Senozhatsky wrote:
> So... Just an idea. Can you try a very dirty hack? Forcibly increase
> oops_in_progress in panic() before console_flush_on_panic(), so 8250
> serial8250_console_write() will use spin_trylock_irqsave() and maybe
> avoid deadlock.
E.g. something like
On (10/04/18 16:44), Sergey Senozhatsky wrote:
> So... Just an idea. Can you try a very dirty hack? Forcibly increase
> oops_in_progress in panic() before console_flush_on_panic(), so 8250
> serial8250_console_write() will use spin_trylock_irqsave() and maybe
> avoid deadlock.
E.g. something like
Commit-ID: 995d5f64b62f20f05b8e0972f07ec4d6c2c9
Gitweb: https://git.kernel.org/tip/995d5f64b62f20f05b8e0972f07ec4d6c2c9
Author: Pu Wen
AuthorDate: Thu, 4 Oct 2018 09:21:43 +0800
Committer: Borislav Petkov
CommitDate: Thu, 4 Oct 2018 09:57:25 +0200
tools/cpupower: Add Hygon
Commit-ID: 995d5f64b62f20f05b8e0972f07ec4d6c2c9
Gitweb: https://git.kernel.org/tip/995d5f64b62f20f05b8e0972f07ec4d6c2c9
Author: Pu Wen
AuthorDate: Thu, 4 Oct 2018 09:21:43 +0800
Committer: Borislav Petkov
CommitDate: Thu, 4 Oct 2018 09:57:25 +0200
tools/cpupower: Add Hygon
On Wed, Oct 03, 2018 at 11:22:55PM +0200, Borislav Petkov wrote:
> On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
> > Sorry for the delay and thanks for the data. A quick diff did not reveal
> > anything obvious. I'll have a closer look and we probably need more (other)
> >
On Wed, Oct 03, 2018 at 11:22:55PM +0200, Borislav Petkov wrote:
> On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
> > Sorry for the delay and thanks for the data. A quick diff did not reveal
> > anything obvious. I'll have a closer look and we probably need more (other)
> >
On Thu, Oct 04, 2018 at 09:53:39AM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 4, 2018 at 9:46 AM Peter Zijlstra wrote:
> >
> > On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> > > idx = -1;
> > > - for (i = first_idx; i < drv->state_count; i++) {
> > > + for
On Thu, Oct 04, 2018 at 09:53:39AM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 4, 2018 at 9:46 AM Peter Zijlstra wrote:
> >
> > On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> > > idx = -1;
> > > - for (i = first_idx; i < drv->state_count; i++) {
> > > + for
* Nadav Amit wrote:
> GCC considers the number of statements in inlined assembly blocks,
> according to new-lines and semicolons, as an indication to the cost of
> the block in time and space. This data is distorted by the kernel code,
> which puts information in alternative sections. As a
* Nadav Amit wrote:
> GCC considers the number of statements in inlined assembly blocks,
> according to new-lines and semicolons, as an indication to the cost of
> the block in time and space. This data is distorted by the kernel code,
> which puts information in alternative sections. As a
On Thu, Oct 4, 2018 at 9:46 AM Peter Zijlstra wrote:
>
> On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> > idx = -1;
> > - for (i = first_idx; i < drv->state_count; i++) {
> > + for (i = 0; i < drv->state_count; i++) {
> > struct cpuidle_state *s =
On Thu, Oct 4, 2018 at 9:46 AM Peter Zijlstra wrote:
>
> On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> > idx = -1;
> > - for (i = first_idx; i < drv->state_count; i++) {
> > + for (i = 0; i < drv->state_count; i++) {
> > struct cpuidle_state *s =
Move the various drivers for Intel platforms into their own subdir. Also
consolidate Qualcomm drivers into the qcom subdir.
This cleans up the directory making it easier to find things.
There is no great time to send patches that move files around, but I'm told
that towards the end of the merge
This cleans up the directory a bit, now that we have several other
platforms using platform-specific sub-directories. Compile-tested with
ARCH=x86 defconfig and the drivers explicitly enabled with menuconfig.
Signed-off-by: Amit Kucheria
Acked-by: Daniel Lezcano
---
drivers/thermal/Kconfig
Move the various drivers for Intel platforms into their own subdir. Also
consolidate Qualcomm drivers into the qcom subdir.
This cleans up the directory making it easier to find things.
There is no great time to send patches that move files around, but I'm told
that towards the end of the merge
This cleans up the directory a bit, now that we have several other
platforms using platform-specific sub-directories. Compile-tested with
ARCH=x86 defconfig and the drivers explicitly enabled with menuconfig.
Signed-off-by: Amit Kucheria
Acked-by: Daniel Lezcano
---
drivers/thermal/Kconfig
This cleans up the directory a bit allowing just one place to look for
thermal related drivers for QCOM platforms instead of being scattered in
the root directory and the qcom/ subdirectory. Compile-tested with
ARCH=arm64 defconfig and the driver explicitly enabled with menuconfig.
Signed-off-by:
On Thu, Oct 04, 2018 at 08:55:45AM +0200, Rafael J. Wysocki wrote:
> On Tue, Oct 2, 2018 at 11:51 PM Rafael J. Wysocki wrote:
> >
> > Hi All,
> >
> > This series fixes a couple of issues with the menu governor, optimizes it
> > somewhat and makes a couple of cleanups in it. Please refer to the
>
This cleans up the directory a bit allowing just one place to look for
thermal related drivers for QCOM platforms instead of being scattered in
the root directory and the qcom/ subdirectory. Compile-tested with
ARCH=arm64 defconfig and the driver explicitly enabled with menuconfig.
Signed-off-by:
On Thu, Oct 04, 2018 at 08:55:45AM +0200, Rafael J. Wysocki wrote:
> On Tue, Oct 2, 2018 at 11:51 PM Rafael J. Wysocki wrote:
> >
> > Hi All,
> >
> > This series fixes a couple of issues with the menu governor, optimizes it
> > somewhat and makes a couple of cleanups in it. Please refer to the
>
On Wed 2018-10-03 13:37:04, Steven Rostedt wrote:
> On Wed, 3 Oct 2018 10:16:08 -0700
> Daniel Wang wrote:
>
> > On Wed, Oct 3, 2018 at 2:14 AM Petr Mladek wrote:
> > >
> > > On Tue 2018-10-02 21:23:27, Steven Rostedt wrote:
> > > > I don't see the big deal of backporting this. The biggest
On Wed 2018-10-03 13:37:04, Steven Rostedt wrote:
> On Wed, 3 Oct 2018 10:16:08 -0700
> Daniel Wang wrote:
>
> > On Wed, Oct 3, 2018 at 2:14 AM Petr Mladek wrote:
> > >
> > > On Tue 2018-10-02 21:23:27, Steven Rostedt wrote:
> > > > I don't see the big deal of backporting this. The biggest
On Thu, Oct 04, 2018 at 05:11:17AM +0200, Paul Menzel wrote:
> Thank you for looking into this. On what board are you able to reproduce
> this? Do you build for 32-bit or 64-bit?
32-bit partition on an AMD F14h laptop.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid
On Thu, Oct 04, 2018 at 05:11:17AM +0200, Paul Menzel wrote:
> Thank you for looking into this. On what board are you able to reproduce
> this? Do you build for 32-bit or 64-bit?
32-bit partition on an AMD F14h laptop.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid
On Wed 03-10-18 19:15:24, Dan Williams wrote:
> Some data exfiltration and return-oriented-programming attacks rely on
> the ability to infer the location of sensitive data objects. The kernel
> page allocator, especially early in system boot, has predictable
> first-in-first out behavior for
On Wed 03-10-18 19:15:24, Dan Williams wrote:
> Some data exfiltration and return-oriented-programming attacks rely on
> the ability to infer the location of sensitive data objects. The kernel
> page allocator, especially early in system boot, has predictable
> first-in-first out behavior for
On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> idx = -1;
> - for (i = first_idx; i < drv->state_count; i++) {
> + for (i = 0; i < drv->state_count; i++) {
> struct cpuidle_state *s = >states[i];
> struct cpuidle_state_usage *su =
On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> idx = -1;
> - for (i = first_idx; i < drv->state_count; i++) {
> + for (i = 0; i < drv->state_count; i++) {
> struct cpuidle_state *s = >states[i];
> struct cpuidle_state_usage *su =
Add binding documentation for the True Random Number Generator
found on Samsung Exynos 5250+ SoCs.
Acked-by: Rob Herring
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Łukasz Stelmach
---
This time with proper tags, as requested.
Kind regards,
ŁS
Add binding documentation for the True Random Number Generator
found on Samsung Exynos 5250+ SoCs.
Acked-by: Rob Herring
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Łukasz Stelmach
---
This time with proper tags, as requested.
Kind regards,
ŁS
On 2018-09-26 03:19, Doug Anderson wrote:
Hi,
On Mon, Sep 24, 2018 at 4:52 PM Stephen Boyd
wrote:
We don't need to use goto here, we can just collapse the if statement
and goto chain into multiple branches and then combine some duplicate
completion calls into one big if statement. Let's do
On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano wrote:
>
> The function nr_iowait_cpu() can be used directly by nr_iowait() instead
> of duplicating code.
>
> Call nr_iowait_cpu() from nr_iowait()
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Rafael J. Wysocki
> ---
> kernel/sched/core.c | 40
On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano wrote:
>
> The function nr_iowait_cpu() can be used directly by nr_iowait() instead
> of duplicating code.
>
> Call nr_iowait_cpu() from nr_iowait()
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Rafael J. Wysocki
> ---
> kernel/sched/core.c | 40
On 2018-09-26 03:19, Doug Anderson wrote:
Hi,
On Mon, Sep 24, 2018 at 4:52 PM Stephen Boyd
wrote:
We don't need to use goto here, we can just collapse the if statement
and goto chain into multiple branches and then combine some duplicate
completion calls into one big if statement. Let's do
On Wed, Oct 03, 2018 at 09:59:48PM -0700, Nadav Amit wrote:
> This patch proposes to do something different: break
> it into two. One part holds code+data that is needed for the entry
> (trampoline code, entry stack and TSS), which is mapped in the fixmap.
> The other part holds the
On Wed, Oct 03, 2018 at 09:59:48PM -0700, Nadav Amit wrote:
> This patch proposes to do something different: break
> it into two. One part holds code+data that is needed for the entry
> (trampoline code, entry stack and TSS), which is mapped in the fixmap.
> The other part holds the
On Wed, Oct 03, 2018 at 03:25:54PM +0200, Jan Kara wrote:
> On Wed 03-10-18 08:53:37, Linus Walleij wrote:
> > On Wed, Oct 3, 2018 at 8:29 AM Paolo Valente
> > wrote:
> >
> > > So, I do understand your need for conservativeness, but, after so much
> > > evidence on single-queue devices, and so
On Wed, Oct 03, 2018 at 03:25:54PM +0200, Jan Kara wrote:
> On Wed 03-10-18 08:53:37, Linus Walleij wrote:
> > On Wed, Oct 3, 2018 at 8:29 AM Paolo Valente
> > wrote:
> >
> > > So, I do understand your need for conservativeness, but, after so much
> > > evidence on single-queue devices, and so
On Wed 03-10-18 19:15:18, Dan Williams wrote:
> Changes since v1:
> * Add support for shuffling hot-added memory (Andrew)
> * Update cover letter and commit message to clarify the performance impact
> and relevance to future platforms
I believe this hasn't addressed my questions in
On Wed 03-10-18 19:15:18, Dan Williams wrote:
> Changes since v1:
> * Add support for shuffling hot-added memory (Andrew)
> * Update cover letter and commit message to clarify the performance impact
> and relevance to future platforms
I believe this hasn't addressed my questions in
On (10/03/18 11:37), Daniel Wang wrote:
> When `softlockup_panic` is set (which is what my original repro had and
> what we use in production), without the backport patch, the expected panic
> would hit a seemingly deadlock. So even when the machine is configured
> to reboot immediately after the
On (10/03/18 11:37), Daniel Wang wrote:
> When `softlockup_panic` is set (which is what my original repro had and
> what we use in production), without the backport patch, the expected panic
> would hit a seemingly deadlock. So even when the machine is configured
> to reboot immediately after the
The function get_loadavg() returns almost always zero. To be more
precise, statistically speaking for a total of 1023379 times passing
in the function, the load is equal to zero 1020728 times, greater than
100, 610 times, the remaining is between 0 and 5.
In 2011, the get_loadavg() was removed
The function nr_iowait_cpu() can be used directly by nr_iowait() instead
of duplicating code.
Call nr_iowait_cpu() from nr_iowait()
Signed-off-by: Daniel Lezcano
---
kernel/sched/core.c | 40 +++-
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git
The function get_loadavg() returns almost always zero. To be more
precise, statistically speaking for a total of 1023379 times passing
in the function, the load is equal to zero 1020728 times, greater than
100, 610 times, the remaining is between 0 and 5.
In 2011, the get_loadavg() was removed
The function nr_iowait_cpu() can be used directly by nr_iowait() instead
of duplicating code.
Call nr_iowait_cpu() from nr_iowait()
Signed-off-by: Daniel Lezcano
---
kernel/sched/core.c | 40 +++-
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git
+Julien, Zhengxunli and Mason from Macronix
Hi Yogesh,
On Thu, 4 Oct 2018 06:51:41 +
Yogesh Narayan Gaur wrote:
> Hi Vignesh,
>
> > -Original Message-
> > From: Vignesh R [mailto:vigne...@ti.com]
> > Sent: Wednesday, October 3, 2018 10:26 PM
> > To: Boris Brezillon ; Marek Vasut
>
+Julien, Zhengxunli and Mason from Macronix
Hi Yogesh,
On Thu, 4 Oct 2018 06:51:41 +
Yogesh Narayan Gaur wrote:
> Hi Vignesh,
>
> > -Original Message-
> > From: Vignesh R [mailto:vigne...@ti.com]
> > Sent: Wednesday, October 3, 2018 10:26 PM
> > To: Boris Brezillon ; Marek Vasut
>
This patch adds support for the Dialog DA7280 Haptic driver IC.
In this patch set the following is provided:
[PATCH V2 1/3] MAINTAINERS file update for DA7280
[PATCH V2 2/3] DA7280 DT Binding
[PATCH V2 3/3] DA7280 Driver
This patch applies against linux-next and v4.19-rc6
Thank you,
Roy Im,
This patch adds support for the Dialog DA7280 Haptic driver IC.
In this patch set the following is provided:
[PATCH V2 1/3] MAINTAINERS file update for DA7280
[PATCH V2 2/3] DA7280 DT Binding
[PATCH V2 3/3] DA7280 Driver
This patch applies against linux-next and v4.19-rc6
Thank you,
Roy Im,
This patch adds the da7280 bindings doc and driver to the Dialog
Semiconductor support list.
Signed-off-by: Roy Im
---
v7: No changes.
v6: No changes.
v5: No changes.
v4: No changes.
v3: No changes.
v2: No changes.
MAINTAINERS |2 ++
1 file changed, 2 insertions(+)
diff --git
This patch adds the da7280 bindings doc and driver to the Dialog
Semiconductor support list.
Signed-off-by: Roy Im
---
v7: No changes.
v6: No changes.
v5: No changes.
v4: No changes.
v3: No changes.
v2: No changes.
MAINTAINERS |2 ++
1 file changed, 2 insertions(+)
diff --git
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
multiple mode and integrated waveform memory and wideband support.
It communicates via an I2C bus to the device.
Signed-off-by: Roy Im
---
v7:
- Added more attributes to handle one value per file.
- Replaced and
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
multiple mode and integrated waveform memory and wideband support.
It communicates via an I2C bus to the device.
Signed-off-by: Roy Im
---
v7:
- Added more attributes to handle one value per file.
- Replaced and
Add device tree binding information for DA7280 haptic driver.
Example bindings for DA7280 are added.
Reviewed-by: Rob Herring .
Signed-off-by: Roy Im
---
v7: No changes.
v6: No changes.
v5: Updated descriptions and fixed errors.
v4: Fixed commit message, properties.
v3: Fixed subject format.
Add device tree binding information for DA7280 haptic driver.
Example bindings for DA7280 are added.
Reviewed-by: Rob Herring .
Signed-off-by: Roy Im
---
v7: No changes.
v6: No changes.
v5: Updated descriptions and fixed errors.
v4: Fixed commit message, properties.
v3: Fixed subject format.
On Thu, 4 Oct 2018, Jia-Ju Bai wrote:
> > Why? Forcing all the report buffer to be limited to be non-sleeping
> > allocations just because of two drivers, looks like an overkill, and
> > actually calls for more issues (as GFP_ATOMIC is of course in principle
> > less likely to succeed).
>
>
On Thu, 4 Oct 2018, Jia-Ju Bai wrote:
> > Why? Forcing all the report buffer to be limited to be non-sleeping
> > allocations just because of two drivers, looks like an overkill, and
> > actually calls for more issues (as GFP_ATOMIC is of course in principle
> > less likely to succeed).
>
>
On 2018-09-25 05:22, Stephen Boyd wrote:
We never really look at the 'ret' local variable in these functions, so
let's remove it to make way for shorter and simpler code. Furthermore,
we can shorten some lines by adding two local variables for the SE and
the message length so that everything
On 2018-09-25 05:22, Stephen Boyd wrote:
We never really look at the 'ret' local variable in these functions, so
let's remove it to make way for shorter and simpler code. Furthermore,
we can shorten some lines by adding two local variables for the SE and
the message length so that everything
All the fields in struct bd718xx_pmic are not really necessary.
Remove struct bd718xx_pmic to simplify the code.
Signed-off-by: Axel Lin
Reviewed-by: Matti Vaittinen
---
v4: Drop the pointer to struct bd718xx_pmic inside the struct bd718xx
v3: Remove the references to struct bd718xx_pmic from
All the fields in struct bd718xx_pmic are not really necessary.
Remove struct bd718xx_pmic to simplify the code.
Signed-off-by: Axel Lin
Reviewed-by: Matti Vaittinen
---
v4: Drop the pointer to struct bd718xx_pmic inside the struct bd718xx
v3: Remove the references to struct bd718xx_pmic from
On Wed, Oct 3, 2018 at 8:08 PM Leonard Crestez wrote:
> On Wed, 2018-10-03 at 13:10 +0100, Mark Brown wrote:
> > On Tue, Oct 02, 2018 at 01:42:38PM +, Leonard Crestez wrote:
> >
> > > This turns the phy off and on again instead of leaving it up from uboot
> > > and it doesn't work for some
On Wed, Oct 3, 2018 at 8:08 PM Leonard Crestez wrote:
> On Wed, 2018-10-03 at 13:10 +0100, Mark Brown wrote:
> > On Tue, Oct 02, 2018 at 01:42:38PM +, Leonard Crestez wrote:
> >
> > > This turns the phy off and on again instead of leaving it up from uboot
> > > and it doesn't work for some
On Wed 12-09-18 15:28:52, Waiman Long wrote:
> From: Davidlohr Bueso
>
> Instead of the current O(N) implementation, at the cost
> of adding an atomic counter, we can convert the call to
> an atomic_read(). The counter only serves for accounting
> empty to non-empty transitions, and vice versa;
On Wed 12-09-18 15:28:52, Waiman Long wrote:
> From: Davidlohr Bueso
>
> Instead of the current O(N) implementation, at the cost
> of adding an atomic counter, we can convert the call to
> an atomic_read(). The counter only serves for accounting
> empty to non-empty transitions, and vice versa;
Stephen Rothwell writes:
> Hi Eric,
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> kernel/signal.c
>
> between commit:
>
> 49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use
> __kernel_timespec")
>
> from the y2038 tree and commit:
>
> ae7795bc6187
Stephen Rothwell writes:
> Hi Eric,
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> kernel/signal.c
>
> between commit:
>
> 49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use
> __kernel_timespec")
>
> from the y2038 tree and commit:
>
> ae7795bc6187
sn_sal_console_write() used spin_is_locked() + spin_lock() to get
achieve the same thing as a spin_trylock(), so simplify it by using that
instead. This is also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc:
---
On the OCSSD 2.0 spec, the device populates the metadata pointer (if
provided) when a chunk is reset. Implement this path in pblk. This is
the base for implementing wear-leveling and supporting variable size
chunks (e.g., due to the device mapping out certain sectors).
For 1.2, reset the write
sn_sal_console_write() used spin_is_locked() + spin_lock() to get
achieve the same thing as a spin_trylock(), so simplify it by using that
instead. This is also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc:
---
On the OCSSD 2.0 spec, the device populates the metadata pointer (if
provided) when a chunk is reset. Implement this path in pblk. This is
the base for implementing wear-leveling and supporting variable size
chunks (e.g., due to the device mapping out certain sectors).
For 1.2, reset the write
On Thu, Oct 04, 2018 at 02:51:48PM +0800, Axel Lin wrote:
> All the fields in struct bd718xx_pmic are not really necessary.
> Remove struct bd718xx_pmic to simplify the code.
>
> Signed-off-by: Axel Lin
> Reviewed-by: Matti Vaittinen
> ---
> v3: Remove the references to struct bd718xx_pmic from
On Thu, Oct 04, 2018 at 02:51:48PM +0800, Axel Lin wrote:
> All the fields in struct bd718xx_pmic are not really necessary.
> Remove struct bd718xx_pmic to simplify the code.
>
> Signed-off-by: Axel Lin
> Reviewed-by: Matti Vaittinen
> ---
> v3: Remove the references to struct bd718xx_pmic from
Hi Morimoto-san
Thanks for your comments
On 2018/10/04 12:43, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your feedback
in GEN3 SSI may use different BUSIF for data transfer,
this patch adds busif property to each dai stream,
to indicate the BUSIF used by playback/capture stream.
Hi Morimoto-san
Thanks for your comments
On 2018/10/04 12:43, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your feedback
in GEN3 SSI may use different BUSIF for data transfer,
this patch adds busif property to each dai stream,
to indicate the BUSIF used by playback/capture stream.
On Tue, Oct 2, 2018 at 11:51 PM Rafael J. Wysocki wrote:
>
> Hi All,
>
> This series fixes a couple of issues with the menu governor, optimizes it
> somewhat and makes a couple of cleanups in it. Please refer to the
> patch changelogs for details.
>
> All of the changes in the series are
On Tue, Oct 2, 2018 at 11:51 PM Rafael J. Wysocki wrote:
>
> Hi All,
>
> This series fixes a couple of issues with the menu governor, optimizes it
> somewhat and makes a couple of cleanups in it. Please refer to the
> patch changelogs for details.
>
> All of the changes in the series are
All the fields in struct bd718xx_pmic are not really necessary.
Remove struct bd718xx_pmic to simplify the code.
Signed-off-by: Axel Lin
Reviewed-by: Matti Vaittinen
---
v3: Remove the references to struct bd718xx_pmic from
include/linux/mfd/rohm-bd718x7.h
Hi Vignesh,
> -Original Message-
> From: Vignesh R [mailto:vigne...@ti.com]
> Sent: Wednesday, October 3, 2018 10:26 PM
> To: Boris Brezillon ; Marek Vasut
> ; Rob Herring
> Cc: Brian Norris ; Yogesh Narayan Gaur
> ; Linux ARM Mailing List ker...@lists.infradead.org>;
All the fields in struct bd718xx_pmic are not really necessary.
Remove struct bd718xx_pmic to simplify the code.
Signed-off-by: Axel Lin
Reviewed-by: Matti Vaittinen
---
v3: Remove the references to struct bd718xx_pmic from
include/linux/mfd/rohm-bd718x7.h
Hi Vignesh,
> -Original Message-
> From: Vignesh R [mailto:vigne...@ti.com]
> Sent: Wednesday, October 3, 2018 10:26 PM
> To: Boris Brezillon ; Marek Vasut
> ; Rob Herring
> Cc: Brian Norris ; Yogesh Narayan Gaur
> ; Linux ARM Mailing List ker...@lists.infradead.org>;
On Wed, Oct 03, 2018 at 11:00:51AM -0500, Bjorn Helgaas wrote:
> On Tue, Oct 02, 2018 at 10:38:47PM -0700, Lance Roy wrote:
> > lockdep_assert_held() is better suited to checking locking requirements,
> > since it won't get confused when someone else holds the lock. This is
> > also a step towards
On Wed, Oct 03, 2018 at 11:00:51AM -0500, Bjorn Helgaas wrote:
> On Tue, Oct 02, 2018 at 10:38:47PM -0700, Lance Roy wrote:
> > lockdep_assert_held() is better suited to checking locking requirements,
> > since it won't get confused when someone else holds the lock. This is
> > also a step towards
Hello Axel,
On Wed, Oct 03, 2018 at 11:32:46PM +0800, Axel Lin wrote:
> All the fields in struct bd718xx_pmic are not really necessary.
> Remove struct bd718xx_pmic to simplify the code.
>
> Signed-off-by: Axel Lin
> ---
> v2:
> Sorry, just update the subject line.
>
>
Hello Axel,
On Wed, Oct 03, 2018 at 11:32:46PM +0800, Axel Lin wrote:
> All the fields in struct bd718xx_pmic are not really necessary.
> Remove struct bd718xx_pmic to simplify the code.
>
> Signed-off-by: Axel Lin
> ---
> v2:
> Sorry, just update the subject line.
>
>
Commit-ID: 02e425668f5c9deb42787d10001a3b605993ad15
Gitweb: https://git.kernel.org/tip/02e425668f5c9deb42787d10001a3b605993ad15
Author: Andy Lutomirski
AuthorDate: Wed, 3 Oct 2018 16:23:49 -0700
Committer: Ingo Molnar
CommitDate: Thu, 4 Oct 2018 08:17:50 +0200
x86/vdso: Fix vDSO
Commit-ID: 02e425668f5c9deb42787d10001a3b605993ad15
Gitweb: https://git.kernel.org/tip/02e425668f5c9deb42787d10001a3b605993ad15
Author: Andy Lutomirski
AuthorDate: Wed, 3 Oct 2018 16:23:49 -0700
Committer: Ingo Molnar
CommitDate: Thu, 4 Oct 2018 08:17:50 +0200
x86/vdso: Fix vDSO
Hi Stephen,
On 04-10-18, 15:44, Stephen Rothwell wrote:
> Hi Vinod,
>
> After merging the slave-dma tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/dma/fsl-edma.c:67: warning: "EDMA_SEEI_SEEI" redefined
> #define EDMA_SEEI_SEEI(x) ((x) & 0x1F)
>
> In
Hi Stephen,
On 04-10-18, 15:44, Stephen Rothwell wrote:
> Hi Vinod,
>
> After merging the slave-dma tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/dma/fsl-edma.c:67: warning: "EDMA_SEEI_SEEI" redefined
> #define EDMA_SEEI_SEEI(x) ((x) & 0x1F)
>
> In
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in:
kernel/signal.c
between commit:
49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use
__kernel_timespec")
from the y2038 tree and commit:
ae7795bc6187 ("signal: Distinguish between kernel_siginfo and
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in:
kernel/signal.c
between commit:
49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use
__kernel_timespec")
from the y2038 tree and commit:
ae7795bc6187 ("signal: Distinguish between kernel_siginfo and
1201 - 1300 of 1300 matches
Mail list logo
