On Tue, Oct 16, 2018 at 3:48 PM, John Stultz wrote:
> On Mon, Oct 15, 2018 at 8:41 PM, Martin K. Petersen
> wrote:
>>
>> John,
>>
>>> Hynix ufs has deviations on hi36xx platform which will result in ufs
>>> bursts transfer failures.
>>
>
On Tue, Oct 16, 2018 at 3:48 PM, John Stultz wrote:
> On Mon, Oct 15, 2018 at 8:41 PM, Martin K. Petersen
> wrote:
>>
>> John,
>>
>>> Hynix ufs has deviations on hi36xx platform which will result in ufs
>>> bursts transfer failures.
>>
>
te failed as expected due to seal
> : Permission denied
> map 3 prot-read passed as expected
>
> Note: This seal will also prevent growing and shrinking of the memfd.
> This is not something we do in Android so it does not affect us, however
> I have mentioned this behavior of the seal in the manpage.
>
> Cc: jr...@google.com
> Cc: john.stu...@linaro.org
> Cc: tk...@google.com
> Cc: gre...@linuxfoundation.org
> Signed-off-by: Joel Fernandes (Google)
Reviewed-by: John Stultz
thanks
-john
te failed as expected due to seal
> : Permission denied
> map 3 prot-read passed as expected
>
> Note: This seal will also prevent growing and shrinking of the memfd.
> This is not something we do in Android so it does not affect us, however
> I have mentioned this behavior of the seal in the manpage.
>
> Cc: jr...@google.com
> Cc: john.stu...@linaro.org
> Cc: tk...@google.com
> Cc: gre...@linuxfoundation.org
> Signed-off-by: Joel Fernandes (Google)
Reviewed-by: John Stultz
thanks
-john
iles for legacy devices, but I did not finish that
> for this kernel cycle.
>
> Fixes: commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor
> only")
> Reported-by: Leonard Crestez
> Reported-by: Fabio Estevam
> Reported-by: John Stultz
> Reported-by: Anders Roxell
> Signed-off-by: Linus Walleij
This seems to solve it!
Tested-by: John Stultz
iles for legacy devices, but I did not finish that
> for this kernel cycle.
>
> Fixes: commit efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor
> only")
> Reported-by: Leonard Crestez
> Reported-by: Fabio Estevam
> Reported-by: John Stultz
> Reported-by: Anders Roxell
> Signed-off-by: Linus Walleij
This seems to solve it!
Tested-by: John Stultz
On Mon, Oct 1, 2018 at 1:44 PM, Mark Salyzyn wrote:
> On 10/01/2018 11:49 AM, John Stultz wrote:
>> It seems the patchset is already somewhat broken up into separate
>> sets, so I might recommend picking just one area and focus on
>> upstreaming that first. Maybe the in-
On Mon, Oct 1, 2018 at 1:44 PM, Mark Salyzyn wrote:
> On 10/01/2018 11:49 AM, John Stultz wrote:
>> It seems the patchset is already somewhat broken up into separate
>> sets, so I might recommend picking just one area and focus on
>> upstreaming that first. Maybe the in-
On Mon, Oct 1, 2018 at 10:58 AM, Mark Salyzyn wrote:
> Last sent 23 Nov 2016.
>
> The following 23 patches are rebased and resent, and represent a
> rewrite of the arm and arm64 vDSO into C, adding support for arch32
> (32-bit user space hosted 64-bit kernels) and into a common library
> that
On Mon, Oct 1, 2018 at 10:58 AM, Mark Salyzyn wrote:
> Last sent 23 Nov 2016.
>
> The following 23 patches are rebased and resent, and represent a
> rewrite of the arm and arm64 vDSO into C, adding support for arch32
> (32-bit user space hosted 64-bit kernels) and into a common library
> that
On Thu, Sep 6, 2018 at 6:01 AM Linus Walleij wrote:
>
> As we augmented the regulator core to accept a GPIO descriptor instead
> of a GPIO number, we can augment the fixed GPIO regulator to look up
> and pass that descriptor directly from device tree or board GPIO
> descriptor look up tables.
>
>
On Thu, Sep 6, 2018 at 6:01 AM Linus Walleij wrote:
>
> As we augmented the regulator core to accept a GPIO descriptor instead
> of a GPIO number, we can augment the fixed GPIO regulator to look up
> and pass that descriptor directly from device tree or board GPIO
> descriptor look up tables.
>
>
On Tue, Sep 25, 2018 at 3:04 AM, Artur Petrosyan
wrote:
> Just a clarification by this commit "[PATCH] usb: dwc2: Fix HiKey
> regression caused by power_down feature"
> https://marc.info/?l=linux-usb=152669095513248=2
>
> the power_down is disabled setting "p->power_down = false;" in
>
On Tue, Sep 25, 2018 at 3:04 AM, Artur Petrosyan
wrote:
> Just a clarification by this commit "[PATCH] usb: dwc2: Fix HiKey
> regression caused by power_down feature"
> https://marc.info/?l=linux-usb=152669095513248=2
>
> the power_down is disabled setting "p->power_down = false;" in
>
On Sun, Sep 23, 2018 at 10:57 PM, Artur Petrosyan
wrote:
> Hi John,
>
> On 9/21/2018 05:05, John Stultz wrote:
>> On Thu, Sep 20, 2018 at 7:17 AM, Artur Petrosyan
>> wrote:
>>> On 5/23/2018 01:57, John Stultz wrote:
>>>> Its done automatically,
On Sun, Sep 23, 2018 at 10:57 PM, Artur Petrosyan
wrote:
> Hi John,
>
> On 9/21/2018 05:05, John Stultz wrote:
>> On Thu, Sep 20, 2018 at 7:17 AM, Artur Petrosyan
>> wrote:
>>> On 5/23/2018 01:57, John Stultz wrote:
>>>> Its done automatically,
On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski wrote:
> On Fri, Sep 14, 2018 at 5:50 AM, Thomas Gleixner wrote:
>> The code flow for the vclocks is convoluted as it requires the vclocks
>> which can be invalidated separately from the vsyscall_gtod_data sequence to
>> store the fact in a
On Mon, Sep 17, 2018 at 12:25 PM, Andy Lutomirski wrote:
> On Fri, Sep 14, 2018 at 5:50 AM, Thomas Gleixner wrote:
>> The code flow for the vclocks is convoluted as it requires the vclocks
>> which can be invalidated separately from the vsyscall_gtod_data sequence to
>> store the fact in a
On Fri, Aug 24, 2018 at 10:47 AM, Andy Lutomirski wrote:
> Minor nit: if it's not literally a resend, don't call it "RESEND" in
> $SUBJECT. Call it v2, please.
>
> Also, I added LKML and relevant maintainers to cc. John and Stephen:
> this is a purely x86 patch, but it digs into the core
On Fri, Aug 24, 2018 at 10:47 AM, Andy Lutomirski wrote:
> Minor nit: if it's not literally a resend, don't call it "RESEND" in
> $SUBJECT. Call it v2, please.
>
> Also, I added LKML and relevant maintainers to cc. John and Stephen:
> this is a purely x86 patch, but it digs into the core
On Thu, Aug 16, 2018 at 11:37 AM, Tuomas Tynkkynen
wrote:
> Hi,
>
> On 08/16/2018 08:57 PM, John Stultz wrote:
>>
>> On Thu, Aug 16, 2018 at 3:22 AM, Will Deacon wrote:
>>>
>>> Hi Tuomas, [+John]
>
> ...
>>>
>>>
>>> Out of i
On Thu, Aug 16, 2018 at 11:37 AM, Tuomas Tynkkynen
wrote:
> Hi,
>
> On 08/16/2018 08:57 PM, John Stultz wrote:
>>
>> On Thu, Aug 16, 2018 at 3:22 AM, Will Deacon wrote:
>>>
>>> Hi Tuomas, [+John]
>
> ...
>>>
>>>
>>> Out of i
y,
> insn = aarch64_insn_gen_nop();
> }
>
> - aarch64_insn_patch_text(, , 1);
> + aarch64_insn_patch_text_nosync(addr, insn);
> }
>
> void arch_jump_label_transform_static(struct jump_entry *entry,
Yes, this works for me as well.
Tested-by: John Stultz
thanks so much!
-john
y,
> insn = aarch64_insn_gen_nop();
> }
>
> - aarch64_insn_patch_text(, , 1);
> + aarch64_insn_patch_text_nosync(addr, insn);
> }
>
> void arch_jump_label_transform_static(struct jump_entry *entry,
Yes, this works for me as well.
Tested-by: John Stultz
thanks so much!
-john
On Tue, Aug 14, 2018 at 4:36 AM, Will Deacon wrote:
>
> Please pull these arm64 updates for 4.19. Details in the tag, but please be
> aware that we've pulled in the x86/mm branch from -tip so that we can make
> use of the core ioremap changes which allow us to put down huge mappings
> in the
On Tue, Aug 14, 2018 at 4:36 AM, Will Deacon wrote:
>
> Please pull these arm64 updates for 4.19. Details in the tag, but please be
> aware that we've pulled in the x86/mm branch from -tip so that we can make
> use of the core ioremap changes which allow us to put down huge mappings
> in the
On Wed, Aug 1, 2018 at 2:55 PM, Hugh Dickins wrote:
> On Wed, 1 Aug 2018, Kirill A. Shutemov wrote:
>> On Wed, Aug 01, 2018 at 11:31:52AM -0700, Hugh Dickins wrote:
>> > On Wed, 1 Aug 2018, Linus Torvalds wrote:
>> > >
>> > > Anyway, the upshot of all this is that I think I know what the ia64
>>
On Wed, Aug 1, 2018 at 2:55 PM, Hugh Dickins wrote:
> On Wed, 1 Aug 2018, Kirill A. Shutemov wrote:
>> On Wed, Aug 01, 2018 at 11:31:52AM -0700, Hugh Dickins wrote:
>> > On Wed, 1 Aug 2018, Linus Torvalds wrote:
>> > >
>> > > Anyway, the upshot of all this is that I think I know what the ia64
>>
fix vma_is_anonymous() false-positives")
Reported-by: Amit Pundir
Reported-by: Youling 257
Signed-off-by: John Stultz
---
Hopefully my explanation make sense here. Please let me know if it
needs corrections.
thanks
-john
---
drivers/staging/android/ashmem.c | 2 ++
1 file changed, 2
fix vma_is_anonymous() false-positives")
Reported-by: Amit Pundir
Reported-by: Youling 257
Signed-off-by: John Stultz
---
Hopefully my explanation make sense here. Please let me know if it
needs corrections.
thanks
-john
---
drivers/staging/android/ashmem.c | 2 ++
1 file changed, 2
On Tue, Jul 31, 2018 at 9:29 AM, Linus Torvalds
wrote:
> On Mon, Jul 30, 2018 at 11:40 PM Amit Pundir wrote:
>>
>> This ashmem change ^^ worked too.
>
> Ok, let's go for that one and hope it's the only one.
>
> John, can I get a proper commit message and sign-off for that ashmem change?
Will
On Tue, Jul 31, 2018 at 9:29 AM, Linus Torvalds
wrote:
> On Mon, Jul 30, 2018 at 11:40 PM Amit Pundir wrote:
>>
>> This ashmem change ^^ worked too.
>
> Ok, let's go for that one and hope it's the only one.
>
> John, can I get a proper commit message and sign-off for that ashmem change?
Will
On Mon, Jul 30, 2018 at 8:26 PM, Hugh Dickins wrote:
> On Mon, 30 Jul 2018, Linus Torvalds wrote:
>> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote:
>> >
>> > I have no problem with reverting -rc7's vma_is_anonymous() series.
>>
>> I don't think we need to revert the whole series: I think
On Mon, Jul 30, 2018 at 8:26 PM, Hugh Dickins wrote:
> On Mon, 30 Jul 2018, Linus Torvalds wrote:
>> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote:
>> >
>> > I have no problem with reverting -rc7's vma_is_anonymous() series.
>>
>> I don't think we need to revert the whole series: I think
gic properly.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Originally-by: Thomas Gleixner
Signed-off-by: Mukesh Ojha
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 32 +---
1 file
gic properly.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Originally-by: Thomas Gleixner
Signed-off-by: Mukesh Ojha
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 32 +---
1 file
Boyd
Cc: Daniel Lezcano
Reviewed-by: Thomas Gleixner
Reviewed-by: Daniel Lezcano
Suggested-by: Thomas Gleixner
Signed-off-by: Baolin Wang
[jstultz: minor tweaks to merge with previous resume changes]
Signed-off-by: John Stultz
---
include/linux/clocksource.h | 3 +
kernel/time/clocksource.c
Boyd
Cc: Daniel Lezcano
Reviewed-by: Thomas Gleixner
Reviewed-by: Daniel Lezcano
Suggested-by: Thomas Gleixner
Signed-off-by: Baolin Wang
[jstultz: minor tweaks to merge with previous resume changes]
Signed-off-by: John Stultz
---
include/linux/clocksource.h | 3 +
kernel/time/clocksource.c
-existing checkpatch warnings for
prototype arguments with no variable name]
Signed-off-by: John Stultz
---
include/linux/timekeeping.h| 2 +-
kernel/time/ntp.c | 6 +++---
kernel/time/ntp_internal.h | 4 ++--
kernel/time/timekeeping.c | 29
From: Ondrej Mosnacek
...instead of kstrtol with a dirty cast.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Signed-off-by: Ondrej Mosnacek
Signed-off-by: John Stultz
---
kernel/time/ntp.c | 5 ++---
1 file changed, 2
-existing checkpatch warnings for
prototype arguments with no variable name]
Signed-off-by: John Stultz
---
include/linux/timekeeping.h| 2 +-
kernel/time/ntp.c | 6 +++---
kernel/time/ntp_internal.h | 4 ++--
kernel/time/timekeeping.c | 29
From: Ondrej Mosnacek
...instead of kstrtol with a dirty cast.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Signed-off-by: Ondrej Mosnacek
Signed-off-by: John Stultz
---
kernel/time/ntp.c | 5 ++---
1 file changed, 2
The following changes since commit c6bb11147eb09bd39f316c6062455b88c905ab6e:
Merge branch 'fortglx/4.19/time' of
https://git.linaro.org/people/john.stultz/linux into timers/core (2018-07-12
22:19:58 +0200)
are available in the git repository at:
-by: John Stultz
---
kernel/time/ntp.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 10a7905..3eddac2 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -642,7 +642,7 @@ void ntp_notify_cmos_timer(void
The following changes since commit c6bb11147eb09bd39f316c6062455b88c905ab6e:
Merge branch 'fortglx/4.19/time' of
https://git.linaro.org/people/john.stultz/linux into timers/core (2018-07-12
22:19:58 +0200)
are available in the git repository at:
-by: John Stultz
---
kernel/time/ntp.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 10a7905..3eddac2 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -642,7 +642,7 @@ void ntp_notify_cmos_timer(void
On Tue, Jul 17, 2018 at 12:55 AM, Baolin Wang wrote:
> On some hardware with multiple clocksources, we have coarse grained
> clocksources that support the CLOCK_SOURCE_SUSPEND_NONSTOP flag, but
> which are less than ideal for timekeeping whereas other clocksources
> can be better candidates but
On Tue, Jul 17, 2018 at 12:55 AM, Baolin Wang wrote:
> On some hardware with multiple clocksources, we have coarse grained
> clocksources that support the CLOCK_SOURCE_SUSPEND_NONSTOP flag, but
> which are less than ideal for timekeeping whereas other clocksources
> can be better candidates but
On Mon, Jul 16, 2018 at 11:31 PM, Mukesh Ojha wrote:
> Currently, there exists a corner case assuming when there is
> only one clocksource e.g RTC, and system failed to go to
> suspend mode. While resume rtc_resume() injects the sleeptime
> as timekeeping_rtc_skipresume() returned 'false'
On Mon, Jul 16, 2018 at 11:31 PM, Mukesh Ojha wrote:
> Currently, there exists a corner case assuming when there is
> only one clocksource e.g RTC, and system failed to go to
> suspend mode. While resume rtc_resume() injects the sleeptime
> as timekeeping_rtc_skipresume() returned 'false'
On Mon, Jul 16, 2018 at 1:40 PM, Mukesh Ojha wrote:
> Currently, there exists a corner case assuming when there is
> only one clocksource e.g RTC, and system failed to go to
> suspend mode. While resume rtc_resume() injects the sleeptime
> as timekeeping_rtc_skipresume() returned 'false' (default
On Mon, Jul 16, 2018 at 1:40 PM, Mukesh Ojha wrote:
> Currently, there exists a corner case assuming when there is
> only one clocksource e.g RTC, and system failed to go to
> suspend mode. While resume rtc_resume() injects the sleeptime
> as timekeeping_rtc_skipresume() returned 'false' (default
On Mon, Jul 16, 2018 at 11:30 AM, Mukesh Ojha wrote:
>
>
> On 7/16/2018 10:44 PM, John Stultz wrote:
>>
>> On Mon, Jul 16, 2018 at 9:30 AM, John Stultz
>> wrote:
>>>
>>> On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha
>>> wro
On Mon, Jul 16, 2018 at 11:30 AM, Mukesh Ojha wrote:
>
>
> On 7/16/2018 10:44 PM, John Stultz wrote:
>>
>> On Mon, Jul 16, 2018 at 9:30 AM, John Stultz
>> wrote:
>>>
>>> On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha
>>> wro
On Mon, Jul 16, 2018 at 9:30 AM, John Stultz wrote:
> On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha wrote:
>> On 7/13/2018 10:50 PM, John Stultz wrote:
>>> On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha
>>>> On 7/11/2018 1:43 AM, John Stultz wrote:
>>>&
On Mon, Jul 16, 2018 at 9:30 AM, John Stultz wrote:
> On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha wrote:
>> On 7/13/2018 10:50 PM, John Stultz wrote:
>>> On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha
>>>> On 7/11/2018 1:43 AM, John Stultz wrote:
>>>&
On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha wrote:
> On 7/13/2018 10:50 PM, John Stultz wrote:
>> On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha
>>> On 7/11/2018 1:43 AM, John Stultz wrote:
>>>> I worry this upside-down logic is too subtle to be easily reasoned
On Mon, Jul 16, 2018 at 9:17 AM, Mukesh Ojha wrote:
> On 7/13/2018 10:50 PM, John Stultz wrote:
>> On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha
>>> On 7/11/2018 1:43 AM, John Stultz wrote:
>>>> I worry this upside-down logic is too subtle to be easily reasoned
On Fri, Jul 13, 2018 at 5:06 AM, Ondrej Mosnacek wrote:
> The 'ts' argument of process_adj_status() and process_adjtimex_modes()
> is unused and can be safely removed.
>
> Signed-off-by: Ondrej Mosnacek
Thanks for sending this set along. I'll queue them up for closer
review and testing.
thanks
On Fri, Jul 13, 2018 at 5:06 AM, Ondrej Mosnacek wrote:
> The 'ts' argument of process_adj_status() and process_adjtimex_modes()
> is unused and can be safely removed.
>
> Signed-off-by: Ondrej Mosnacek
Thanks for sending this set along. I'll queue them up for closer
review and testing.
thanks
On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha wrote:
> Hi John,
>
> Thanks for your response
> Please find my comments inline.
>
>
> On 7/11/2018 1:43 AM, John Stultz wrote:
>>
>> On Fri, Jul 6, 2018 at 6:17 AM, Mukesh Ojha wrote:
>>>
>>>
On Fri, Jul 13, 2018 at 12:13 AM, Mukesh Ojha wrote:
> Hi John,
>
> Thanks for your response
> Please find my comments inline.
>
>
> On 7/11/2018 1:43 AM, John Stultz wrote:
>>
>> On Fri, Jul 6, 2018 at 6:17 AM, Mukesh Ojha wrote:
>>>
>>>
On Thu, Jul 12, 2018 at 1:26 PM, Thomas Gleixner wrote:
> On Thu, 12 Jul 2018, John Stultz wrote:
>
>> I had a few other items in my stack here, but you've already
>> queued them in -tip, so here's what I have left.
>
> Did I miss you replying on them that you picked
On Thu, Jul 12, 2018 at 1:26 PM, Thomas Gleixner wrote:
> On Thu, 12 Jul 2018, John Stultz wrote:
>
>> I had a few other items in my stack here, but you've already
>> queued them in -tip, so here's what I have left.
>
> Did I miss you replying on them that you picked
: Stephen Boyd
Signed-off-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4786df9..6772011 100644
cause false negatives.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Suggested-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
v2: Widened the checks to look for other
cause false negatives.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Suggested-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
v2: Widened the checks to look for other
: Stephen Boyd
Signed-off-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
kernel/time/timekeeping.c | 36 ++--
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 4786df9..6772011 100644
fortglx/4.19/time
for you to fetch changes up to b061c7a513afe14a68af41cec7c3476befc40e95:
timekeeping: Update multiplier when NTP frequency is set directly (2018-07-10
12:44:25 -0700)
John Stultz (1):
selftest: timers: Tweak
fortglx/4.19/time
for you to fetch changes up to b061c7a513afe14a68af41cec7c3476befc40e95:
timekeeping: Update multiplier when NTP frequency is set directly (2018-07-10
12:44:25 -0700)
John Stultz (1):
selftest: timers: Tweak
On Fri, Jul 6, 2018 at 6:17 AM, Mukesh Ojha wrote:
> Currently, there exists a corner case assuming when there is
> only one clocksource e.g RTC, and system failed to go to
> suspend mode. While resume rtc_resume() injects the sleeptime
> as timekeeping_rtc_skipresume() returned 'false' (default
On Fri, Jul 6, 2018 at 6:17 AM, Mukesh Ojha wrote:
> Currently, there exists a corner case assuming when there is
> only one clocksource e.g RTC, and system failed to go to
> suspend mode. While resume rtc_resume() injects the sleeptime
> as timekeeping_rtc_skipresume() returned 'false' (default
that we don't cause false negatives.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Suggested-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
v2: Widened the checks to look
that we don't cause false negatives.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Suggested-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
v2: Widened the checks to look
.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Suggested-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
tools/testing/selftests/timers/raw_skew.c | 9 -
1 file
.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Miroslav Lichvar
Cc: Richard Cochran
Cc: Prarit Bhargava
Cc: Stephen Boyd
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Suggested-by: Miroslav Lichvar
Signed-off-by: John Stultz
---
tools/testing/selftests/timers/raw_skew.c | 9 -
1 file
On Mon, Jul 2, 2018 at 2:34 AM, gengdongjiu wrote:
> Hi Thomas/Anna/John,
>
> Recently I found that the hrtimer become inaccurate when there is a RT
> process runs on the same cpu core, and the kernel has applied preempt_rt
> patch.
> The Linux kernel version is v4.1.46, and the preempt_rt
On Mon, Jul 2, 2018 at 2:34 AM, gengdongjiu wrote:
> Hi Thomas/Anna/John,
>
> Recently I found that the hrtimer become inaccurate when there is a RT
> process runs on the same cpu core, and the kernel has applied preempt_rt
> patch.
> The Linux kernel version is v4.1.46, and the preempt_rt
; Reported-by: air icy
> Signed-off-by: Thomas Gleixner
Looks ok, and doesn't trip any regressions in testing so far.
Acked-by: John Stultz
thanks
-john
; Reported-by: air icy
> Signed-off-by: Thomas Gleixner
Looks ok, and doesn't trip any regressions in testing so far.
Acked-by: John Stultz
thanks
-john
d doesn't trip any regressions in testing so far.
Acked-by: John Stultz
thanks
-john
d doesn't trip any regressions in testing so far.
Acked-by: John Stultz
thanks
-john
On Sat, Jun 23, 2018 at 5:14 PM, Thomas Gleixner wrote:
> On Wed, 13 Jun 2018, Baolin Wang wrote:
>> Moreover we can register the clocksource with CLOCK_SOURCE_SUSPEND_NONSTOP
>> to be one persistent clock, then we can simplify the suspend/resume
>> accounting by removing
On Sat, Jun 23, 2018 at 5:14 PM, Thomas Gleixner wrote:
> On Wed, 13 Jun 2018, Baolin Wang wrote:
>> Moreover we can register the clocksource with CLOCK_SOURCE_SUSPEND_NONSTOP
>> to be one persistent clock, then we can simplify the suspend/resume
>> accounting by removing
On Fri, Jun 22, 2018 at 2:09 PM, Thomas Gleixner wrote:
> On Mon, 4 Jun 2018, Miroslav Lichvar wrote:
>
>> When the NTP frequency is set directly from userspace using the
>> ADJ_FREQUENCY or ADJ_TICK timex mode, immediately update the
>> timekeeper's multiplier instead of waiting for the next
On Fri, Jun 22, 2018 at 2:09 PM, Thomas Gleixner wrote:
> On Mon, 4 Jun 2018, Miroslav Lichvar wrote:
>
>> When the NTP frequency is set directly from userspace using the
>> ADJ_FREQUENCY or ADJ_TICK timex mode, immediately update the
>> timekeeper's multiplier instead of waiting for the next
On Tue, Jun 12, 2018 at 9:33 PM, Roman Gushchin wrote:
> On Tue, Jun 12, 2018 at 09:08:27PM -0700, John Stultz wrote:
>> On Tue, Jun 12, 2018 at 6:02 PM, John Stultz wrote:
>> > Hey Tejun,
>> > With the current linus/master, I'm able to fairly regularly trip
>
On Tue, Jun 12, 2018 at 9:33 PM, Roman Gushchin wrote:
> On Tue, Jun 12, 2018 at 09:08:27PM -0700, John Stultz wrote:
>> On Tue, Jun 12, 2018 at 6:02 PM, John Stultz wrote:
>> > Hey Tejun,
>> > With the current linus/master, I'm able to fairly regularly trip
>
neously fail with -EACCES.
>
> Signed-off-by: Ryan Grachek
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Tested-by: John Stultz
Acked-by: John Stultz
Wei Xu: This fixes a functional regression with wifi on the HiKey
board that was introduced in 4.18-rc with
neously fail with -EACCES.
>
> Signed-off-by: Ryan Grachek
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Tested-by: John Stultz
Acked-by: John Stultz
Wei Xu: This fixes a functional regression with wifi on the HiKey
board that was introduced in 4.18-rc with
On Wed, Jun 13, 2018 at 7:42 AM, Valentin Schneider
wrote:
> On 13/06/18 05:13, Tony Lindgren wrote:
>> * John Stultz [180612 22:15]:
>>> Hey Folks,
>>> I noticed with linus/master wifi wasn't coming up on HiKey960. I
>>> bisected it down and it seem
On Wed, Jun 13, 2018 at 7:42 AM, Valentin Schneider
wrote:
> On 13/06/18 05:13, Tony Lindgren wrote:
>> * John Stultz [180612 22:15]:
>>> Hey Folks,
>>> I noticed with linus/master wifi wasn't coming up on HiKey960. I
>>> bisected it down and it seem
On Tue, Jun 12, 2018 at 6:02 PM, John Stultz wrote:
> Hey Tejun,
> With the current linus/master, I'm able to fairly regularly trip
> OOPSes (two examples below) in mem_cgroup_protected(), which seems to
> be new. I haven't managed to trigger this sort of thing with v4.17.
>
On Tue, Jun 12, 2018 at 6:02 PM, John Stultz wrote:
> Hey Tejun,
> With the current linus/master, I'm able to fairly regularly trip
> OOPSes (two examples below) in mem_cgroup_protected(), which seems to
> be new. I haven't managed to trigger this sort of thing with v4.17.
>
On Tue, Jun 12, 2018 at 3:12 PM, John Stultz wrote:
> Hey Folks,
> I noticed with linus/master wifi wasn't coming up on HiKey960. I
> bisected it down and it seems to be due to:
>
> 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") and
> 728a9dc61f13 (&q
On Tue, Jun 12, 2018 at 3:12 PM, John Stultz wrote:
> Hey Folks,
> I noticed with linus/master wifi wasn't coming up on HiKey960. I
> bisected it down and it seems to be due to:
>
> 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power") and
> 728a9dc61f13 (&q
Hey Tejun,
With the current linus/master, I'm able to fairly regularly trip
OOPSes (two examples below) in mem_cgroup_protected(), which seems to
be new. I haven't managed to trigger this sort of thing with v4.17.
I've not had much time to dig in or bisect it - I only know that
enabling most
Hey Tejun,
With the current linus/master, I'm able to fairly regularly trip
OOPSes (two examples below) in mem_cgroup_protected(), which seems to
be new. I haven't managed to trigger this sort of thing with v4.17.
I've not had much time to dig in or bisect it - I only know that
enabling most
On Tue, Jun 12, 2018 at 3:52 PM, Kees Cook wrote:
> On Tue, Jun 12, 2018 at 3:40 PM, John Stultz wrote:
>> Hey all,
>> I noticed recently that linus/master (plus patches) stopped booting
>> to UI on HiKey960, and I bisected the issue down to:
>> 92
On Tue, Jun 12, 2018 at 3:52 PM, Kees Cook wrote:
> On Tue, Jun 12, 2018 at 3:40 PM, John Stultz wrote:
>> Hey all,
>> I noticed recently that linus/master (plus patches) stopped booting
>> to UI on HiKey960, and I bisected the issue down to:
>> 92
601 - 700 of 7113 matches
Mail list logo
