On 03/10/18 15:42, Steven Rostedt wrote:
> On Mon, 3 Sep 2018 16:28:00 +0200
> Juri Lelli wrote:
>
>
> > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> > index 5b43f482fa0f..8dc26005bb1e 100644
> > --- a/kernel/cgroup/cpuset.c
> > +++ b/kernel/cgroup/cpuset.c
> > @@ -2410,6
On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
> On 4 October 2018 at 10:39, Rafael J. Wysocki wrote:
> > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson wrote:
> >>
> >> I have digested the review comments so far, including a recent offlist chat
> >> with with Lorenzo Pieralisi
On October 4, 2018 1:56:37 AM PDT, Nadav Amit wrote:
>at 1:40 AM, h...@zytor.com wrote:
>
>> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar
>wrote:
>>> * Ingo Molnar wrote:
>>>
I'm also somewhat annoyed at the fact that this series carries a
>>> boatload
of reviewed-by's and
On October 4, 2018 1:56:37 AM PDT, Nadav Amit wrote:
>at 1:40 AM, h...@zytor.com wrote:
>
>> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar
>wrote:
>>> * Ingo Molnar wrote:
>>>
I'm also somewhat annoyed at the fact that this series carries a
>>> boatload
of reviewed-by's and
Hi Peter,
On Thursday 04 Oct 2018 at 10:34:57 (+0200), Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 10:13:06AM +0100, Quentin Perret wrote:
> > +static unsigned long cpu_util_next(int cpu, struct task_struct *p, int
> > dst_cpu)
> > +{
> > + struct cfs_rq *cfs_rq = _rq(cpu)->cfs;
> > +
On Wed, Oct 3, 2018 at 1:49 PM Leonard Crestez wrote:
> On Tue, 2018-10-02 at 21:56 +0200, Linus Walleij wrote:
> > I guess I could hack to make "gpios" be ignored by the
> > regulator GPIO quirks in gpiolib, but I take it you probably
> > prefer to fix up the real issue like this.
>
> Maybe you
Hi Peter,
On Thursday 04 Oct 2018 at 10:34:57 (+0200), Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 10:13:06AM +0100, Quentin Perret wrote:
> > +static unsigned long cpu_util_next(int cpu, struct task_struct *p, int
> > dst_cpu)
> > +{
> > + struct cfs_rq *cfs_rq = _rq(cpu)->cfs;
> > +
On Wed, Oct 3, 2018 at 1:49 PM Leonard Crestez wrote:
> On Tue, 2018-10-02 at 21:56 +0200, Linus Walleij wrote:
> > I guess I could hack to make "gpios" be ignored by the
> > regulator GPIO quirks in gpiolib, but I take it you probably
> > prefer to fix up the real issue like this.
>
> Maybe you
* Nadav Amit wrote:
> Finally, note that it’s not as if the binary always becomes smaller.
> Overall, with the full patch-set it is slightly bigger. But still, that’s
> how it was supposed to be if gcc wasn’t doing things badly.
So what I cited was the changelog for the refcount patch, which
* Nadav Amit wrote:
> Finally, note that it’s not as if the binary always becomes smaller.
> Overall, with the full patch-set it is slightly bigger. But still, that’s
> how it was supposed to be if gcc wasn’t doing things badly.
So what I cited was the changelog for the refcount patch, which
Am Montag, den 01.10.2018, 22:53 +0300 schrieb Leonard Crestez:
> When the root complex suspends it must send a PME_Turn_Off TLP.
> Implement this by asserting the "turnoff" reset.
>
> On imx7d this is functionality is part of the SRC and exposed through
> the linux reset-controller subsystem. On
Am Montag, den 01.10.2018, 22:53 +0300 schrieb Leonard Crestez:
> When the root complex suspends it must send a PME_Turn_Off TLP.
> Implement this by asserting the "turnoff" reset.
>
> On imx7d this is functionality is part of the SRC and exposed through
> the linux reset-controller subsystem. On
On 4 October 2018 at 10:39, Rafael J. Wysocki wrote:
> On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson wrote:
>>
>> I have digested the review comments so far, including a recent offlist chat
>> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
>> have a plan for how to
On 4 October 2018 at 10:39, Rafael J. Wysocki wrote:
> On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson wrote:
>>
>> I have digested the review comments so far, including a recent offlist chat
>> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
>> have a plan for how to
Dear Borislav,
On 10/04/18 10:49, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
>> Do you have a commit, I could test.
>
> Not yet
I meant just the test you did.
> but I have a question for you: why are you running 32-bit and
> haven't moved to 64-bit
Dear Borislav,
On 10/04/18 10:49, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
>> Do you have a commit, I could test.
>
> Not yet
I meant just the test you did.
> but I have a question for you: why are you running 32-bit and
> haven't moved to 64-bit
at 1:40 AM, h...@zytor.com wrote:
> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>> * Ingo Molnar wrote:
>>
>>> I'm also somewhat annoyed at the fact that this series carries a
>> boatload
>>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>>> important to point
at 1:40 AM, h...@zytor.com wrote:
> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>> * Ingo Molnar wrote:
>>
>>> I'm also somewhat annoyed at the fact that this series carries a
>> boatload
>>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>>> important to point
* h...@zytor.com wrote:
> It's not just for working around a stupid GCC bug, but it also has a huge
> potential for
> cleaning up the inline asm in general.
Sorry but that's just plain false. For example this patch:
x86: cpufeature: use macros instead of inline assembly
... adds an
On Mon, Oct 01, 2018 at 09:42:37PM -0700, Guenter Roeck wrote:
> This reverts commit d76c74387e1c978b6c5524a146ab0f3f72206f98.
>
> While commit d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling")
> fixes runtime PM handling when using kgdb, it introduces a traceback for
> everyone else.
* h...@zytor.com wrote:
> It's not just for working around a stupid GCC bug, but it also has a huge
> potential for
> cleaning up the inline asm in general.
Sorry but that's just plain false. For example this patch:
x86: cpufeature: use macros instead of inline assembly
... adds an
On Mon, Oct 01, 2018 at 09:42:37PM -0700, Guenter Roeck wrote:
> This reverts commit d76c74387e1c978b6c5524a146ab0f3f72206f98.
>
> While commit d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling")
> fixes runtime PM handling when using kgdb, it introduces a traceback for
> everyone else.
On (10/04/18 10:36), Petr Mladek wrote:
>
> This looks like a reasonable explanation of what is happening here.
> It also explains why the console owner logic helped.
Well, I'm still a bit puzzled, frankly speaking. I've two theories.
Theory #1 [most likely]
Steven is a wizard and his code
On (10/04/18 10:36), Petr Mladek wrote:
>
> This looks like a reasonable explanation of what is happening here.
> It also explains why the console owner logic helped.
Well, I'm still a bit puzzled, frankly speaking. I've two theories.
Theory #1 [most likely]
Steven is a wizard and his code
These functions are unused externally, removed them and declare
the one used locally as static.
Signed-off-by: Clément Péron
---
arch/arm/mach-socfpga/core.h| 2 --
arch/arm/mach-socfpga/socfpga.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git
These functions are unused externally, removed them and declare
the one used locally as static.
Signed-off-by: Clément Péron
---
arch/arm/mach-socfpga/core.h| 2 --
arch/arm/mach-socfpga/socfpga.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git
From: Dinh Nguyen
When doing a software reboot, all peripheral clocks must get turned on for the
L3 interconnect to work.
This code is needed when doing a "reboot" from user-space and a peripheral
clock as been gated off. Why would a peripheral clock get gated? An example
use case would be a
From: Dinh Nguyen
When doing a software reboot, all peripheral clocks must get turned on for the
L3 interconnect to work.
This code is needed when doing a "reboot" from user-space and a peripheral
clock as been gated off. Why would a peripheral clock get gated? An example
use case would be a
From: Dinh Nguyen
Turn on these ARM and PL310 errata for SoCFPGA:
ARM_ERRATA_754322
ARM_ERRATA_764369
ARM_ERRATA_775420
PL310_ERRATA_588369
PL310_ERRATA_727915
PL310_ERRATA_753970
PL310_ERRATA_769419
Fixes: 387798b37c8d ("ARM: initial multiplatform support")
Signed-off-by: Dinh Nguyen
From: Dinh Nguyen
Turn on these ARM and PL310 errata for SoCFPGA:
ARM_ERRATA_754322
ARM_ERRATA_764369
ARM_ERRATA_775420
PL310_ERRATA_588369
PL310_ERRATA_727915
PL310_ERRATA_753970
PL310_ERRATA_769419
Fixes: 387798b37c8d ("ARM: initial multiplatform support")
Signed-off-by: Dinh Nguyen
Add support for octal mode IO data transfer.
Micron flash, mt35xu512aba, supports octal mode data transfer and
NXP FlexSPI controller supports 8 data lines for data transfer (Rx/Tx).
Patch series
* Add support for octal mode flags and parsing of same in spi driver.
* Add octal data communication
Flash mt35xu512aba connected to FlexSPI controller supports
1-1-8 protocol.
Added flag spi-rx-bus-width and spi-tx-bus-width with values as
8 and 1 respectively for both flashes connected at CS0 and CS1.
Signed-off-by: Yogesh Gaur
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4
Add support for octal mode data transfer for Micron mt35xu512aba.
Unfortunately, this flash is only complaint to SFDP JESD216B and does
not seem to support newer JESD216C standard that provides auto detection
of Octal mode capabilities and opcodes. Therefore, this capability is
manually added
Add flags for Octal I/O data transfer
Required for the SPI controller which can do the data transfer (TX/RX)
on 8 data lines e.g. NXP FlexSPI controller.
SPI_TX_OCTAL: transmit with 8 wires
SPI_RX_OCTAL: receive with 8 wires
Signed-off-by: Yogesh Gaur
---
drivers/spi/spi.c | 6 ++
Add support for octal mode IO data transfer.
Micron flash, mt35xu512aba, supports octal mode data transfer and
NXP FlexSPI controller supports 8 data lines for data transfer (Rx/Tx).
Patch series
* Add support for octal mode flags and parsing of same in spi driver.
* Add octal data communication
Flash mt35xu512aba connected to FlexSPI controller supports
1-1-8 protocol.
Added flag spi-rx-bus-width and spi-tx-bus-width with values as
8 and 1 respectively for both flashes connected at CS0 and CS1.
Signed-off-by: Yogesh Gaur
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4
Add support for octal mode data transfer for Micron mt35xu512aba.
Unfortunately, this flash is only complaint to SFDP JESD216B and does
not seem to support newer JESD216C standard that provides auto detection
of Octal mode capabilities and opcodes. Therefore, this capability is
manually added
Add flags for Octal I/O data transfer
Required for the SPI controller which can do the data transfer (TX/RX)
on 8 data lines e.g. NXP FlexSPI controller.
SPI_TX_OCTAL: transmit with 8 wires
SPI_RX_OCTAL: receive with 8 wires
Signed-off-by: Yogesh Gaur
---
drivers/spi/spi.c | 6 ++
Add mode flags for octal I/O data transfer support.
NXP FlexSPI controller supports octal mode data transfer.
Signed-off-by: Yogesh Gaur
---
drivers/spi/spi-nxp-fspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
Add mode flags for octal I/O data transfer support.
NXP FlexSPI controller supports octal mode data transfer.
Signed-off-by: Yogesh Gaur
---
drivers/spi/spi-nxp-fspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
> Do you have a commit, I could test.
Not yet but I have a question for you: why are you running 32-bit and
haven't moved to 64-bit already?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the
On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
> Do you have a commit, I could test.
Not yet but I have a question for you: why are you running 32-bit and
haven't moved to 64-bit already?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the
On Thu, Oct 04, 2018 at 10:43:18AM +0200, Joerg Roedel wrote:
> Yeah, that's what I also found out back then, the region needs to be WX.
> So we can either leave with the warning, as we know it is harmless and
> where it comes from or implement an exception in the checking code for
> that region.
On Thu, Oct 04, 2018 at 10:43:18AM +0200, Joerg Roedel wrote:
> Yeah, that's what I also found out back then, the region needs to be WX.
> So we can either leave with the warning, as we know it is harmless and
> where it comes from or implement an exception in the checking code for
> that region.
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Thursday, October 4, 2018 1:09 PM
> To: Yogesh Narayan Gaur
> Cc: Vignesh R ; Marek Vasut ; Rob
> Herring ; Brian Norris ;
> Linux ARM Mailing List ; linux-
> m...@lists.infradead.org;
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Thursday, October 4, 2018 1:09 PM
> To: Yogesh Narayan Gaur
> Cc: Vignesh R ; Marek Vasut ; Rob
> Herring ; Brian Norris ;
> Linux ARM Mailing List ; linux-
> m...@lists.infradead.org;
On Thu, Oct 4, 2018 at 10:40 AM Daniel Lezcano
wrote:
>
> On 04/10/2018 10:22, Rafael J. Wysocki wrote:
> > On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano
> > wrote:
[cut]
> >> - interactivity_req = data->predicted_us /
> >> performance_multiplier(nr_iowaiters, cpu_load);
> >> +
On Thu, Oct 4, 2018 at 10:40 AM Daniel Lezcano
wrote:
>
> On 04/10/2018 10:22, Rafael J. Wysocki wrote:
> > On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano
> > wrote:
[cut]
> >> - interactivity_req = data->predicted_us /
> >> performance_multiplier(nr_iowaiters, cpu_load);
> >> +
On Thu, Oct 04, 2018 at 10:14:38AM +0200, Borislav Petkov wrote:
> So looking at this, BIOS_BEGIN and BIOS_END is the same range as the ISA
> range:
>
> #define ISA_START_ADDRESS 0x000a
> #define ISA_END_ADDRESS 0x0010
>
> #define BIOS_BEGIN 0x000a
>
On Thu, Oct 04, 2018 at 10:14:38AM +0200, Borislav Petkov wrote:
> So looking at this, BIOS_BEGIN and BIOS_END is the same range as the ISA
> range:
>
> #define ISA_START_ADDRESS 0x000a
> #define ISA_END_ADDRESS 0x0010
>
> #define BIOS_BEGIN 0x000a
>
On 04.10.2018 01:02, gregkh wrote:
> On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
>> wrote:
>>> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> On Tue,
On 04.10.2018 01:02, gregkh wrote:
> On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
>> wrote:
>>> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> On Tue,
Hi Heiner,
Here's the reply to your questions. Sorry for the delay.
On 28/09/2018 23:13, Heiner Kallweit wrote:
> On 29.09.2018 00:00, Chris Clayton wrote:
>> Thanks Maciej.
>>
>> On 28/09/2018 16:54, Maciej S. Szmigiero wrote:
>>> Hi,
>>>
Hi,
I upgraded my kernel to 4.18.10
Hi Heiner,
Here's the reply to your questions. Sorry for the delay.
On 28/09/2018 23:13, Heiner Kallweit wrote:
> On 29.09.2018 00:00, Chris Clayton wrote:
>> Thanks Maciej.
>>
>> On 28/09/2018 16:54, Maciej S. Szmigiero wrote:
>>> Hi,
>>>
Hi,
I upgraded my kernel to 4.18.10
On 04/10/2018 10:22, Rafael J. Wysocki wrote:
> On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano
> wrote:
>>
>> 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
On 04/10/2018 10:22, Rafael J. Wysocki wrote:
> On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano
> wrote:
>>
>> 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
at 12:57 AM, Ingo Molnar wrote:
>
> * 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
Dear Borislav,
On 10/04/18 10:14, Borislav Petkov wrote:
> 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)
On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>
>* Ingo Molnar wrote:
>
>> I'm also somewhat annoyed at the fact that this series carries a
>boatload
>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>> important to point out the large chasm that is gaping between
at 12:57 AM, Ingo Molnar wrote:
>
> * 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
Dear Borislav,
On 10/04/18 10:14, Borislav Petkov wrote:
> 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)
On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>
>* Ingo Molnar wrote:
>
>> I'm also somewhat annoyed at the fact that this series carries a
>boatload
>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>> important to point out the large chasm that is gaping between
On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson wrote:
>
> I have digested the review comments so far, including a recent offlist chat
> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
> have a plan for how to move forward.
>
> However, to avoid re-posting non-changed
On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson wrote:
>
> I have digested the review comments so far, including a recent offlist chat
> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
> have a plan for how to move forward.
>
> However, to avoid re-posting non-changed
On 25-09-18, 14:43, Rob Herring wrote:
> On Tue, Sep 25, 2018 at 5:25 AM Rajendra Nayak wrote:
> >
> > Hi Rob,
> >
> > []...
> > > + rpmhpd_opp_table: opp-table {
> > > + compatible = "operating-points-v2-qcom-level";
> > > +
> > > + rpmhpd_opp_ret: opp1 {
>
Hello!
On 10/3/2018 8:23 PM, Maksym Kokhan wrote:
CONFIG_BUILTIN_DTB selection is duplicated in menu
"Machine selection" under MIPS_MALTA.
Fixes: e81a8c7dabac ("MIPS: Malta: Setup RAM regions via DT")
Signed-off-by: Maksym Kokhan
Signed-off-by: Andrii Bordunov
---
arch/mips/Kconfig | 1 -
On 25-09-18, 14:43, Rob Herring wrote:
> On Tue, Sep 25, 2018 at 5:25 AM Rajendra Nayak wrote:
> >
> > Hi Rob,
> >
> > []...
> > > + rpmhpd_opp_table: opp-table {
> > > + compatible = "operating-points-v2-qcom-level";
> > > +
> > > + rpmhpd_opp_ret: opp1 {
>
Hello!
On 10/3/2018 8:23 PM, Maksym Kokhan wrote:
CONFIG_BUILTIN_DTB selection is duplicated in menu
"Machine selection" under MIPS_MALTA.
Fixes: e81a8c7dabac ("MIPS: Malta: Setup RAM regions via DT")
Signed-off-by: Maksym Kokhan
Signed-off-by: Andrii Bordunov
---
arch/mips/Kconfig | 1 -
On Thu 2018-10-04 16:44:42, Sergey Senozhatsky wrote:
> 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
On Thu 2018-10-04 16:44:42, Sergey Senozhatsky wrote:
> 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
HI Boris
On Thu, Oct 4, 2018 at 12:19 AM Boris Brezillon
wrote:
>
> On Thu, 4 Oct 2018 00:14:15 +0200
> Boris Brezillon wrote:
>
> > On Wed, 3 Oct 2018 23:53:27 +0200
> > Ricardo Ribalda Delgado wrote:
> >
> > > Hi Boris
> > > On Wed, Oct 3, 2018 at 11:27 PM Boris Brezillon
> > > wrote:
> >
HI Boris
On Thu, Oct 4, 2018 at 12:19 AM Boris Brezillon
wrote:
>
> On Thu, 4 Oct 2018 00:14:15 +0200
> Boris Brezillon wrote:
>
> > On Wed, 3 Oct 2018 23:53:27 +0200
> > Ricardo Ribalda Delgado wrote:
> >
> > > Hi Boris
> > > On Wed, Oct 3, 2018 at 11:27 PM Boris Brezillon
> > > wrote:
> >
On Wed, Sep 12, 2018 at 10:13:06AM +0100, Quentin Perret wrote:
> +static unsigned long cpu_util_next(int cpu, struct task_struct *p, int
> dst_cpu)
> +{
> + struct cfs_rq *cfs_rq = _rq(cpu)->cfs;
> + unsigned long util_est, util = READ_ONCE(cfs_rq->avg.util_avg);
> +
> + /*
> +
On Wed, Sep 12, 2018 at 10:13:06AM +0100, Quentin Perret wrote:
> +static unsigned long cpu_util_next(int cpu, struct task_struct *p, int
> dst_cpu)
> +{
> + struct cfs_rq *cfs_rq = _rq(cpu)->cfs;
> + unsigned long util_est, util = READ_ONCE(cfs_rq->avg.util_avg);
> +
> + /*
> +
On Wed, Oct 3, 2018 at 2:38 PM Sodagudi Prasad wrote:
> This is regarding the protected pins configuration reading and printing
> from non-secure operating systems.
I do not think anyone with security in mind should have debugfs
enabled. But maybe that is beside the point.
> GPIO framework is
On Wed, Oct 3, 2018 at 2:38 PM Sodagudi Prasad wrote:
> This is regarding the protected pins configuration reading and printing
> from non-secure operating systems.
I do not think anyone with security in mind should have debugfs
enabled. But maybe that is beside the point.
> GPIO framework is
Hi all,
Changes since 20181003:
The bpf-next tree still had its build failure so I used the version
from next-20181002.
The kvm-arm tree gained conflicts against the arm64 tree.
The tty tree gained a build failure so I used the version from
next-20181003.
The slave-dma tree gained a build
Hi all,
Changes since 20181003:
The bpf-next tree still had its build failure so I used the version
from next-20181002.
The kvm-arm tree gained conflicts against the arm64 tree.
The tty tree gained a build failure so I used the version from
next-20181003.
The slave-dma tree gained a build
CTR_EL0.IDC reports the data cache clean requirements for instruction
to data coherence. However, if the field is 0, we need to check the
CLIDR_EL1 fields to detect the status of the feature. Currently we
don't do this and generate a warning with tainting the kernel, when
there is a mismatch in
This series makes sure that we handle the CTR_EL0 field mismatches
properly, especially for the IDC field. Also, skip trapping CTR
accesses on a CPU if it matches the safe value.
Applies on arm64 for-next/core
Suzuki K Poulose (3):
arm64: cpufeature: ctr: Fix cpu capability check for late CPUs
The matches() routine for a capability must honor the "scope"
passed to it and return the proper results.
i.e, when passed with SCOPE_LOCAL_CPU, it should check the
status of the capability on the current CPU. This is used by
verify_local_cpu_capabilities() on a late secondary CPU to make
sure
CTR_EL0.IDC reports the data cache clean requirements for instruction
to data coherence. However, if the field is 0, we need to check the
CLIDR_EL1 fields to detect the status of the feature. Currently we
don't do this and generate a warning with tainting the kernel, when
there is a mismatch in
This series makes sure that we handle the CTR_EL0 field mismatches
properly, especially for the IDC field. Also, skip trapping CTR
accesses on a CPU if it matches the safe value.
Applies on arm64 for-next/core
Suzuki K Poulose (3):
arm64: cpufeature: ctr: Fix cpu capability check for late CPUs
The matches() routine for a capability must honor the "scope"
passed to it and return the proper results.
i.e, when passed with SCOPE_LOCAL_CPU, it should check the
status of the capability on the current CPU. This is used by
verify_local_cpu_capabilities() on a late secondary CPU to make
sure
* Ingo Molnar wrote:
> I'm also somewhat annoyed at the fact that this series carries a boatload
> of reviewed-by's and acked-by's, yet none of those reviewers found it
> important to point out the large chasm that is gaping between description
> and reality.
Another problem I just realized
When there is a mismatch in the CTR_EL0 field, we trap
access to CTR from EL0 on all CPUs to expose the safe
value. However, we could skip trapping on a CPU which
matches the safe value.
Cc: Mark Rutland
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Suzuki K Poulose
---
On Thu, Oct 4, 2018 at 12:27 AM Rob Herring wrote:
>
> It's convenient to use Travis-CI for doing kernel builds. Doing so
> requires a github repo, Travis-CI enabled for that repo, and a
> .travis.yml file in the repository. This commit addresses the last part.
> Each repository branch must have
* Ingo Molnar wrote:
> I'm also somewhat annoyed at the fact that this series carries a boatload
> of reviewed-by's and acked-by's, yet none of those reviewers found it
> important to point out the large chasm that is gaping between description
> and reality.
Another problem I just realized
When there is a mismatch in the CTR_EL0 field, we trap
access to CTR from EL0 on all CPUs to expose the safe
value. However, we could skip trapping on a CPU which
matches the safe value.
Cc: Mark Rutland
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Suzuki K Poulose
---
On Thu, Oct 4, 2018 at 12:27 AM Rob Herring wrote:
>
> It's convenient to use Travis-CI for doing kernel builds. Doing so
> requires a github repo, Travis-CI enabled for that repo, and a
> .travis.yml file in the repository. This commit addresses the last part.
> Each repository branch must have
On Thu, 4 Oct 2018 at 00:31, Jae Hyun Yoo wrote:
>
> This commit removes hard-coded bus timeout value setting so that
> it can be set by i2c-core-base.
>
> Signed-off-by: Jae Hyun Yoo
Reviewed-by: Joel Stanley
On Thu, 4 Oct 2018 at 00:31, Jae Hyun Yoo wrote:
>
> This commit removes hard-coded bus timeout value setting so that
> it can be set by i2c-core-base.
>
> Signed-off-by: Jae Hyun Yoo
Reviewed-by: Joel Stanley
On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano wrote:
>
> 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
On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano wrote:
>
> 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
On 10/03/2018 11:03 AM, Clément Péron wrote:
> Hi,
>
> Saw this patch on the Altera OpenSource GitHub.
>
> But it's not mainlained can I propose it?
>
You sure can!
> How do you do when the patch is from someone else ? Do you keep the
> sign-off of the original author or do you just mention
On 10/03/2018 11:03 AM, Clément Péron wrote:
> Hi,
>
> Saw this patch on the Altera OpenSource GitHub.
>
> But it's not mainlained can I propose it?
>
You sure can!
> How do you do when the patch is from someone else ? Do you keep the
> sign-off of the original author or do you just mention
On 10/3/18 11:30 PM, Joe Perches wrote:
On Wed, 2018-10-03 at 22:43 +0200, Michael Straube wrote:
Cleanup array declaration to clear two 'line over 80 characters'
checkpatch warnings and improve readability.
[]
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
On 10/3/18 11:30 PM, Joe Perches wrote:
On Wed, 2018-10-03 at 22:43 +0200, Michael Straube wrote:
Cleanup array declaration to clear two 'line over 80 characters'
checkpatch warnings and improve readability.
[]
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
On 02/10/2018 23:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> If the CPU exits the "polling" state due to the time limit in the
> loop in poll_idle(), this is not a real wakeup and it just means
> that the "polling" state selection was not adequate. The governor
> mispredicted
On 02/10/2018 23:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> If the CPU exits the "polling" state due to the time limit in the
> loop in poll_idle(), this is not a real wakeup and it just means
> that the "polling" state selection was not adequate. The governor
> mispredicted
1101 - 1200 of 1300 matches
Mail list logo
