Introduce a new PSCI DT helper function, psci_dt_attach_cpu(), which takes
a CPU number as an in-parameter and attaches the CPU's struct device to its
corresponding PM domain. Additionally, the helper prepares the CPU to be
power managed via runtime PM, which is the last step needed to enable the
If the hierarchical CPU topology is used, but the OS initiated mode isn't
supported, we rely solely on the regular cpuidle framework to manage the
idle state selection.
For this reason, introduce a new PSCI DT helper function,
psci_dt_pm_domains_parse_states(), which converts the hierarchically
When the hierarchical CPU topology layout is used in DT, let's allow the
CPU to be power managed through its PM domain and via runtime PM. In other
words, let's deploy runtime PM support to the PSCI driver during idle
management of the CPU.
Signed-off-by: Ulf Hansson
---
Changes in v10:
From: Lina Iyer
In the hierarchical layout, we are creating power domains around each CPU
and describes the idle states for them inside the power domain provider
node. Note that, the CPU's idle states still needs to be compatible with
"arm,idle-state".
Furthermore, represent the CPU cluster as
When the hierarchical CPU topology is used and when a CPU has been put
offline (hotplug), that same CPU prevents its PM domain and thus also
potential master PM domains, from being powered off. This is because genpd
observes the CPU's struct device to remain being active from a runtime PM
point of
Following changes are about to implement support for PM domains to PSCI.
Those changes are mainly going to be implemented in a new separate file,
hence a couple of the internal PSCI functions needs to be shared to be
accessible. So, let's do that via adding new PSCI header file.
Moreover, the
In order to allow the CPU to be power managed through a potential PM domain
and the corresponding topology, it needs to be attached to it. For that
reason, check if the PM domain data structures have been initiated for PSCI
and if so, let's try to attach the CPU device to its PM domain.
However,
To enable the OS to manage last-man standing activities for a CPU, while an
idle state for a group of CPUs is selected, let's convert the Hikey
platform into using the hierarchical CPU topology layout.
Signed-off-by: Ulf Hansson
---
Changes in v10:
- New patch.
---
Introduce a new PSCI DT helper function, psci_dt_attach_cpu(), which takes
a CPU number as an in-parameter and attaches the CPU's struct device to its
corresponding PM domain. Additionally, the helper prepares the CPU to be
power managed via runtime PM, which is the last step needed to enable the
If the hierarchical CPU topology is used, but the OS initiated mode isn't
supported, we rely solely on the regular cpuidle framework to manage the
idle state selection.
For this reason, introduce a new PSCI DT helper function,
psci_dt_pm_domains_parse_states(), which converts the hierarchically
When the hierarchical CPU topology layout is used in DT, let's allow the
CPU to be power managed through its PM domain and via runtime PM. In other
words, let's deploy runtime PM support to the PSCI driver during idle
management of the CPU.
Signed-off-by: Ulf Hansson
---
Changes in v10:
From: Lina Iyer
In the hierarchical layout, we are creating power domains around each CPU
and describes the idle states for them inside the power domain provider
node. Note that, the CPU's idle states still needs to be compatible with
"arm,idle-state".
Furthermore, represent the CPU cluster as
Instead of iterating through all the state nodes in DT, to find out how
many states that needs to be allocated, let's use the number already known
by the cpuidle driver. In this way we can drop the iteration altogether.
Signed-off-by: Ulf Hansson
---
Changes in v10:
- New patch.
---
To enable a device belonging to a CPU to be attached to a PM domain managed
by genpd, let's do a few changes to it, as to make it convenient to manage
the specifics around CPUs.
To be able to quickly find out what CPUs that are attached to a genpd,
which typically becomes useful from a genpd
From: Lina Iyer
Currently CPU's idle states are represented in a flattened model, via the
"cpu-idle-states" binding from within the CPU's device nodes.
Support the hierarchical layout during parsing and validating of the CPU's
idle states. This is simply done by calling the new OF helper,
Instead of iterating through all the state nodes in DT, to find out how
many states that needs to be allocated, let's use the number already known
by the cpuidle driver. In this way we can drop the iteration altogether.
Signed-off-by: Ulf Hansson
---
Changes in v10:
- New patch.
---
To enable a device belonging to a CPU to be attached to a PM domain managed
by genpd, let's do a few changes to it, as to make it convenient to manage
the specifics around CPUs.
To be able to quickly find out what CPUs that are attached to a genpd,
which typically becomes useful from a genpd
From: Lina Iyer
Currently CPU's idle states are represented in a flattened model, via the
"cpu-idle-states" binding from within the CPU's device nodes.
Support the hierarchical layout during parsing and validating of the CPU's
idle states. This is simply done by calling the new OF helper,
Let's split the psci_dt_cpu_init_idle() function into two functions, as to
allow following changes to re-use some of the code.
Cc: Lina Iyer
Co-developed-by: Lina Iyer
Signed-off-by: Ulf Hansson
---
Changes in v10:
- None.
---
drivers/firmware/psci/psci.c | 42
From: Lina Iyer
Knowing the sleep duration of CPUs, is known to be needed while selecting
the most energy efficient idle state for a CPU or a group of CPUs.
However, to be able to compute the sleep duration, we need to know at what
time the next expected wakeup is for the CPU. Therefore, let's
As it's now perfectly possible that a PM domain managed by genpd contains
devices belonging to CPUs, we should start to take into account the
residency values for the idle states during the state selection process.
The residency value specifies the minimum duration of time, the CPU or a
group of
From: Lina Iyer
Update DT bindings to represent hierarchical CPU and CPU PM domain idle
states for PSCI. Also update the PSCI examples to clearly show how
flattened and hierarchical idle states can be represented in DT.
Cc: Lina Iyer
Signed-off-by: Lina Iyer
Co-developed-by: Ulf Hansson
Let's split the psci_dt_cpu_init_idle() function into two functions, as to
allow following changes to re-use some of the code.
Cc: Lina Iyer
Co-developed-by: Lina Iyer
Signed-off-by: Ulf Hansson
---
Changes in v10:
- None.
---
drivers/firmware/psci/psci.c | 42
From: Lina Iyer
Knowing the sleep duration of CPUs, is known to be needed while selecting
the most energy efficient idle state for a CPU or a group of CPUs.
However, to be able to compute the sleep duration, we need to know at what
time the next expected wakeup is for the CPU. Therefore, let's
As it's now perfectly possible that a PM domain managed by genpd contains
devices belonging to CPUs, we should start to take into account the
residency values for the idle states during the state selection process.
The residency value specifies the minimum duration of time, the CPU or a
group of
From: Lina Iyer
Update DT bindings to represent hierarchical CPU and CPU PM domain idle
states for PSCI. Also update the PSCI examples to clearly show how
flattened and hierarchical idle states can be represented in DT.
Cc: Lina Iyer
Signed-off-by: Lina Iyer
Co-developed-by: Ulf Hansson
To enable the OS initiated mode, the CPU topology needs to be described
using the hierarchical model in DT. When used, the idle state bits for the
CPU are created by ORing the bits for PM domain's idle state.
Let's prepare the PSCI driver to deal with this, via introducing a per CPU
variable
To enable the OS initiated mode, the CPU topology needs to be described
using the hierarchical model in DT. When used, the idle state bits for the
CPU are created by ORing the bits for PM domain's idle state.
Let's prepare the PSCI driver to deal with this, via introducing a per CPU
variable
On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote:
>
> > On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
> >
> > On Thu, 29 Nov 2018 12:20:00 -0500
> > Steven Rostedt wrote:
> >
> >
> >> r8 = return address
> >> r9 = function to call
> >>
> >
> > Bad example, r8 and r9 are
On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote:
>
> > On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
> >
> > On Thu, 29 Nov 2018 12:20:00 -0500
> > Steven Rostedt wrote:
> >
> >
> >> r8 = return address
> >> r9 = function to call
> >>
> >
> > Bad example, r8 and r9 are
On Thu, Nov 29, 2018 at 04:16:27PM +0800, Chao Fan wrote:
> To fix the conflict between KASLR and memory-hotremove, memory
> information in SRAT table is necessary.
>
> ACPI SRAT (System/Static Resource Affinity Table) can show the details
> about memory ranges, including ranges of memory
On Thu, Nov 29, 2018 at 04:16:27PM +0800, Chao Fan wrote:
> To fix the conflict between KASLR and memory-hotremove, memory
> information in SRAT table is necessary.
>
> ACPI SRAT (System/Static Resource Affinity Table) can show the details
> about memory ranges, including ranges of memory
On Mon, Nov 12, 2018 at 11:56:59AM +, Julien Thierry wrote:
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
>
On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote:
>
> We can. At least in theory. The problem is that depending on the
> crazy mapping from physical and kernel virtual address to dma addresses
> these might be pages at pretty random places. Look at fun like
>
On Mon, Nov 12, 2018 at 11:56:59AM +, Julien Thierry wrote:
> CPU does not received signals for interrupts with a priority masked by
> ICC_PMR_EL1. This means the CPU might not come back from a WFI
> instruction.
>
> Make sure ICC_PMR_EL1 does not mask interrupts when doing a WFI.
>
>
On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote:
>
> We can. At least in theory. The problem is that depending on the
> crazy mapping from physical and kernel virtual address to dma addresses
> these might be pages at pretty random places. Look at fun like
>
On Thu, 29 Nov 2018 09:35:11 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt wrote:
> >
> > No, we really do need to sync after we change the second part of the
> > command with the int3 on it. Unless there's another way to guarantee
> > that the full instruction
On Thu, 29 Nov 2018 09:35:11 -0800
Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt wrote:
> >
> > No, we really do need to sync after we change the second part of the
> > command with the int3 on it. Unless there's another way to guarantee
> > that the full instruction
Dear Friend,
I am Abel Brent, a NATO soldier serving in Afghanistan. I and my
Comrades, we are seeking your assistance to help us
receive/invest our funds in your country in any lucrative
business. Please if this proposal is acceptable by you, kindly
respond back to me for more details.
Dear Friend,
I am Abel Brent, a NATO soldier serving in Afghanistan. I and my
Comrades, we are seeking your assistance to help us
receive/invest our funds in your country in any lucrative
business. Please if this proposal is acceptable by you, kindly
respond back to me for more details.
> On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
>
> On Thu, 29 Nov 2018 12:20:00 -0500
> Steven Rostedt wrote:
>
>
>> r8 = return address
>> r9 = function to call
>>
>
> Bad example, r8 and r9 are args, but r10 and r11 are available.
>
> -- Steve
>
>>push r8
>>jmp *r9
>>
> On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote:
>
> On Thu, 29 Nov 2018 12:20:00 -0500
> Steven Rostedt wrote:
>
>
>> r8 = return address
>> r9 = function to call
>>
>
> Bad example, r8 and r9 are args, but r10 and r11 are available.
>
> -- Steve
>
>>push r8
>>jmp *r9
>>
From: Adam Wong
Added the ability to detect the ELAN0621 touchpad found in some Lenovo
laptops.
Signed-off-by: Adam Wong
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index
From: Adam Wong
Added the ability to detect the ELAN0621 touchpad found in some Lenovo
laptops.
Signed-off-by: Adam Wong
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index
On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> A warning is generated when a PCIe device is probed with a degraded
> link, but there was no similar mechanism to warn when the link becomes
> degraded after probing. The Link Bandwidth Notification provides this
> mechanism.
>
Hi Han,
On 29.11.18 17:30, Han Xu wrote:
>
>
>> -Original Message-
>> From: Schrempf Frieder
>> Sent: Thursday, November 29, 2018 5:54 AM
>> To: Yogesh Narayan Gaur ; linux-
>> m...@lists.infradead.org; boris.brezil...@bootlin.com; linux-
>> s...@vger.kernel.org; Marek Vasut ; Mark
On Wed, Nov 28, 2018 at 06:08:24PM -0600, Alexandru Gagniuc wrote:
> A warning is generated when a PCIe device is probed with a degraded
> link, but there was no similar mechanism to warn when the link becomes
> degraded after probing. The Link Bandwidth Notification provides this
> mechanism.
>
Hi Han,
On 29.11.18 17:30, Han Xu wrote:
>
>
>> -Original Message-
>> From: Schrempf Frieder
>> Sent: Thursday, November 29, 2018 5:54 AM
>> To: Yogesh Narayan Gaur ; linux-
>> m...@lists.infradead.org; boris.brezil...@bootlin.com; linux-
>> s...@vger.kernel.org; Marek Vasut ; Mark
On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt wrote:
>
> No, we really do need to sync after we change the second part of the
> command with the int3 on it. Unless there's another way to guarantee
> that the full instruction gets seen when we replace the int3 with the
> finished command.
Making
> On Nov 29, 2018, at 9:29 AM, Linus Torvalds
> wrote:
>
> On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski wrote:
>>>
>>> - just restart the instruction (with the suggested "ptregs->rip --")
>>>
>>> - to avoid any "oh, we're not making progress" issues, just fix the
>>> instruction
On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt wrote:
>
> No, we really do need to sync after we change the second part of the
> command with the int3 on it. Unless there's another way to guarantee
> that the full instruction gets seen when we replace the int3 with the
> finished command.
Making
> On Nov 29, 2018, at 9:29 AM, Linus Torvalds
> wrote:
>
> On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski wrote:
>>>
>>> - just restart the instruction (with the suggested "ptregs->rip --")
>>>
>>> - to avoid any "oh, we're not making progress" issues, just fix the
>>> instruction
On Thu, 29 Nov 2018, Andy Lutomirski wrote:
> Does anyone know what the actual hardware semantics are? The SDM is not
> particularly informative unless I looked at the wrong section.
I don't think SDM answers all the questions there, unfortunately.
I vaguely remember that back then when I was
On Thu, 29 Nov 2018, Andy Lutomirski wrote:
> Does anyone know what the actual hardware semantics are? The SDM is not
> particularly informative unless I looked at the wrong section.
I don't think SDM answers all the questions there, unfortunately.
I vaguely remember that back then when I was
On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski wrote:
> >
> > - just restart the instruction (with the suggested "ptregs->rip --")
> >
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by looking it up in the
> > "what needs to
On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski wrote:
> >
> > - just restart the instruction (with the suggested "ptregs->rip --")
> >
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by looking it up in the
> > "what needs to
Hi Chao,
Thank you for your continued working.
Could you please build your patches before sending?
Your patches depend on the following kconfig,
so please build them under the config combination.
RANDOMIZE_BASE
MEMORY_HOTREMOVE
EARLY_PARSE_RSDP
KEXEC
EFI
Thanks,
Masa
On Thu, Nov 29, 2018 at
Hi Chao,
Thank you for your continued working.
Could you please build your patches before sending?
Your patches depend on the following kconfig,
so please build them under the config combination.
RANDOMIZE_BASE
MEMORY_HOTREMOVE
EARLY_PARSE_RSDP
KEXEC
EFI
Thanks,
Masa
On Thu, Nov 29, 2018 at
On Thu, 29 Nov 2018 at 17:10, Greg KH wrote:
> Your patch has to apply on top of the existing one, so there's not an
> issue here.
> And might as well fix it now, as I can never count on a "future" patch
> getting merged.
It is already fixed, i.e. it applies cleanly against the existing
(i.e.
On Thu, 29 Nov 2018 at 17:10, Greg KH wrote:
> Your patch has to apply on top of the existing one, so there's not an
> issue here.
> And might as well fix it now, as I can never count on a "future" patch
> getting merged.
It is already fixed, i.e. it applies cleanly against the existing
(i.e.
> On Nov 29, 2018, at 9:07 AM, Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote:
>>> On Nov 29, 2018, at 8:50 AM, Linus Torvalds
>>> wrote:
>
>>> So no. Do *not* try to change %rsp on the stack in the bp handler.
>>> Instead, I'd suggest:
>>>
>>> -
> On Nov 29, 2018, at 9:07 AM, Peter Zijlstra wrote:
>
> On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote:
>>> On Nov 29, 2018, at 8:50 AM, Linus Torvalds
>>> wrote:
>
>>> So no. Do *not* try to change %rsp on the stack in the bp handler.
>>> Instead, I'd suggest:
>>>
>>> -
On Thu, Nov 29, 2018 at 12:02:19PM -0500, Waiman Long wrote:
> On 11/29/2018 11:06 AM, Peter Zijlstra wrote:
> > Why; at that point we know the wakeup will happen after, which is all we
> > require.
> >
> Thread 1 Thread 2 Thread 3
>
>
On Thu, Nov 29, 2018 at 12:02:19PM -0500, Waiman Long wrote:
> On 11/29/2018 11:06 AM, Peter Zijlstra wrote:
> > Why; at that point we know the wakeup will happen after, which is all we
> > require.
> >
> Thread 1 Thread 2 Thread 3
>
>
On Thu, 29 Nov 2018 12:20:00 -0500
Steven Rostedt wrote:
> r8 = return address
> r9 = function to call
>
Bad example, r8 and r9 are args, but r10 and r11 are available.
-- Steve
> push r8
> jmp *r9
>
> Then have the regs->ip point to that trampoline.
>
> -- Steve
On Thu, 29 Nov 2018 12:20:00 -0500
Steven Rostedt wrote:
> r8 = return address
> r9 = function to call
>
Bad example, r8 and r9 are args, but r10 and r11 are available.
-- Steve
> push r8
> jmp *r9
>
> Then have the regs->ip point to that trampoline.
>
> -- Steve
On Wed, Nov 21, 2018 at 10:41:36AM +0100, Daniel Lezcano wrote:
> On 21/11/2018 10:16, Andy Tang wrote:
> > Hi Daniel,
> >
> > Thanks for your explanation. The problem is these two trees are not synced
> > well.
> > Let's take our driver(qoriq_thermal.c) for example.
> >
> > Git log on Rui's
On Wed, Nov 21, 2018 at 10:41:36AM +0100, Daniel Lezcano wrote:
> On 21/11/2018 10:16, Andy Tang wrote:
> > Hi Daniel,
> >
> > Thanks for your explanation. The problem is these two trees are not synced
> > well.
> > Let's take our driver(qoriq_thermal.c) for example.
> >
> > Git log on Rui's
On Thu, 29 Nov 2018 18:15:39 +0100
Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
> > If you make it conditional on CPL, do it for 32-bit as well, add
> > comments,
>
> > and convince yourself that there isn’t a better solution
> > (like pointing
On Thu, 29 Nov 2018 18:15:39 +0100
Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
> > If you make it conditional on CPL, do it for 32-bit as well, add
> > comments,
>
> > and convince yourself that there isn’t a better solution
> > (like pointing
On Wed, Nov 21, 2018 at 09:16:08AM +, Andy Tang wrote:
> Hi Daniel,
>
> Thanks for your explanation. The problem is these two trees are not synced
> well.
> Let's take our driver(qoriq_thermal.c) for example.
>
> Git log on Rui's tree next branch:
> 2dfef65 thermal: qoriq: Switch to SPDX
On Wed, Nov 21, 2018 at 09:16:08AM +, Andy Tang wrote:
> Hi Daniel,
>
> Thanks for your explanation. The problem is these two trees are not synced
> well.
> Let's take our driver(qoriq_thermal.c) for example.
>
> Git log on Rui's tree next branch:
> 2dfef65 thermal: qoriq: Switch to SPDX
On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> If you make it conditional on CPL, do it for 32-bit as well, add
> comments,
> and convince yourself that there isn’t a better solution
> (like pointing IP at a stub that retpolines to the target by reading
> the function
On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> If you make it conditional on CPL, do it for 32-bit as well, add
> comments,
> and convince yourself that there isn’t a better solution
> (like pointing IP at a stub that retpolines to the target by reading
> the function
On Thu, Nov 29, 2018 at 01:55:02PM +0800, Wei Ni wrote:
> On 28/11/2018 6:25 PM, Thierry Reding wrote:
> > On Wed, Nov 28, 2018 at 01:44:37PM +0800, Wei Ni wrote:
[...]
> >> + bool ret = false;
> >> + struct of_phandle_args sensor_specs;
> >> + struct device_node *np, *sensor_np;
> >> +
> >> +
On Thu, Nov 29, 2018 at 01:55:02PM +0800, Wei Ni wrote:
> On 28/11/2018 6:25 PM, Thierry Reding wrote:
> > On Wed, Nov 28, 2018 at 01:44:37PM +0800, Wei Ni wrote:
[...]
> >> + bool ret = false;
> >> + struct of_phandle_args sensor_specs;
> >> + struct device_node *np, *sensor_np;
> >> +
> >> +
On Thu, 29 Nov 2018 09:02:23 -0800
Andy Lutomirski wrote:
> > Instead, I'd suggest:
> >
> > - just restart the instruction (with the suggested "ptregs->rip --")
> >
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by
On Thu, 29 Nov 2018 09:02:23 -0800
Andy Lutomirski wrote:
> > Instead, I'd suggest:
> >
> > - just restart the instruction (with the suggested "ptregs->rip --")
> >
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by
On 11/29/18 6:17 AM, Sebastian Andrzej Siewior wrote:
> This is broken since v4.12-rc1. This is known [1] since April this year.
> Should I send a removal patch for MPX or is someone actually going to
> fix this? Or do we wait for gcc-9 to be released?
I've got a git tree prepared to do MPX
On 11/29/18 6:17 AM, Sebastian Andrzej Siewior wrote:
> This is broken since v4.12-rc1. This is known [1] since April this year.
> Should I send a removal patch for MPX or is someone actually going to
> fix this? Or do we wait for gcc-9 to be released?
I've got a git tree prepared to do MPX
On Mon, Nov 12, 2018 at 11:56:54AM +, Julien Thierry wrote:
> Add a cpufeature indicating whether a cpu supports masking interrupts
> by priority.
>
> The feature will be properly enabled in a later patch.
>
> Signed-off-by: Julien Thierry
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc:
From: Julien Thierry
Closing bracket seems to end a for statement when it is actually ending
the contained if. Add some brackets to have clear delimitation of each
scope.
No functional change/fix, just fix the indentation.
Signed-off-by: Julien Thierry
Signed-off-by: Ard Biesheuvel
---
On Mon, Nov 12, 2018 at 11:56:54AM +, Julien Thierry wrote:
> Add a cpufeature indicating whether a cpu supports masking interrupts
> by priority.
>
> The feature will be properly enabled in a later patch.
>
> Signed-off-by: Julien Thierry
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc:
From: Julien Thierry
Closing bracket seems to end a for statement when it is actually ending
the contained if. Add some brackets to have clear delimitation of each
scope.
No functional change/fix, just fix the indentation.
Signed-off-by: Julien Thierry
Signed-off-by: Ard Biesheuvel
---
On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 29, 2018, at 8:49 AM, Peter Zijlstra wrote:
> >
> > On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote:
> >>> can't we 'fix' that again? The alternative is moving that IRET-frame and
> >>> fixing
On Thu, Nov 29, 2018 at 11:30:19AM -0500, a...@adamwong.me wrote:
> From: TheWongGuy
>
> Added the ability to detect the ELAN0621 touchpad found in some Lenovo
> laptops.
>
> Signed-off-by: TheWongGuy
I doubt that is the name on your passport :(
Please use your "real" name, like you did for
On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 29, 2018, at 8:49 AM, Peter Zijlstra wrote:
> >
> > On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote:
> >>> can't we 'fix' that again? The alternative is moving that IRET-frame and
> >>> fixing
On Thu, Nov 29, 2018 at 11:30:19AM -0500, a...@adamwong.me wrote:
> From: TheWongGuy
>
> Added the ability to detect the ELAN0621 touchpad found in some Lenovo
> laptops.
>
> Signed-off-by: TheWongGuy
I doubt that is the name on your passport :(
Please use your "real" name, like you did for
On 11/29/18 10:05 AM, Christoph Hellwig wrote:
> On Thu, Nov 29, 2018 at 05:20:31PM +0800, kernel test robot wrote:
>> FYI, we noticed the following commit (built with gcc-7):
>>
>> commit: 9d037ad707ed6069fbea4e38e6ee37e027b13f1d ("block: remove
>> req->timeout_list")
>>
On Thu, Nov 29, 2018 at 04:55:20PM +, Tigran Aivazian wrote:
> On Thu, 29 Nov 2018 at 16:07, Greg KH wrote:
> > On Thu, Nov 29, 2018 at 03:23:00PM +, Tigran Aivazian wrote:
> > > Yes, of course I object to it.
> > I can not apply a patch to the stable trees that are not in Linus's tree
>
On 11/29/18 10:05 AM, Christoph Hellwig wrote:
> On Thu, Nov 29, 2018 at 05:20:31PM +0800, kernel test robot wrote:
>> FYI, we noticed the following commit (built with gcc-7):
>>
>> commit: 9d037ad707ed6069fbea4e38e6ee37e027b13f1d ("block: remove
>> req->timeout_list")
>>
On Thu, Nov 29, 2018 at 04:55:20PM +, Tigran Aivazian wrote:
> On Thu, 29 Nov 2018 at 16:07, Greg KH wrote:
> > On Thu, Nov 29, 2018 at 03:23:00PM +, Tigran Aivazian wrote:
> > > Yes, of course I object to it.
> > I can not apply a patch to the stable trees that are not in Linus's tree
>
On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote:
> > On Nov 29, 2018, at 8:50 AM, Linus Torvalds
> > wrote:
> > So no. Do *not* try to change %rsp on the stack in the bp handler.
> > Instead, I'd suggest:
> >
> > - just restart the instruction (with the suggested "ptregs->rip
On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote:
> > On Nov 29, 2018, at 8:50 AM, Linus Torvalds
> > wrote:
> > So no. Do *not* try to change %rsp on the stack in the bp handler.
> > Instead, I'd suggest:
> >
> > - just restart the instruction (with the suggested "ptregs->rip
On Thu, Nov 29, 2018 at 05:20:31PM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 9d037ad707ed6069fbea4e38e6ee37e027b13f1d ("block: remove
> req->timeout_list")
> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git mq-perf
On Thu, Nov 29, 2018 at 05:20:31PM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 9d037ad707ed6069fbea4e38e6ee37e027b13f1d ("block: remove
> req->timeout_list")
> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git mq-perf
From: Thierry Reding
While the sparse number space has the advantage of only providing (and
therefore allocating) the GPIOs (and interrupts) that really exist for
the given SoC, it also requires special cases in various callbacks.
Using the valid masks for GPIOs and interrupts enables reusing
From: Thierry Reding
While the sparse number space has the advantage of only providing (and
therefore allocating) the GPIOs (and interrupts) that really exist for
the given SoC, it also requires special cases in various callbacks.
Using the valid masks for GPIOs and interrupts enables reusing
From: Thierry Reding
The GPIO controller doesn't have any controls to enable the system to
wake up from low power states based on activity on GPIO pins. An extra
hardware block that is part of the power management controller (PMC)
contains these controls. In order for the GPIO controller to be
From: Thierry Reding
The GPIO controller doesn't have any controls to enable the system to
wake up from low power states based on activity on GPIO pins. An extra
hardware block that is part of the power management controller (PMC)
contains these controls. In order for the GPIO controller to be
901 - 1000 of 2748 matches
Mail list logo
