Now that all the infrastructure is in place to support multiple required
OPPs, lets switch over to using it.
A new internal routine _set_required_opps() takes care of updating
performance state for all the required OPPs. With this the performance
state updates are supported even when the end
An earlier commit populated the OPP tables from the "required-opps"
property, this commit populates the individual OPPs. This is repeated
for each OPP in the OPP table and these populated OPPs will be used by
later commits.
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
We need to handle genpd OPP tables differently, this is already the case
at one location and will be extended going forward. Add another field to
the OPP table to check if the table belongs to a genpd or not.
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
drivers/opp/of.c | 6 --
Multiple generic power domains for a consumer device are supported with
the help of virtual devices, which are created for each consumer device
- genpd pair. These are the device structures which are attached to the
power domain and are required by the OPP core to set the performance
state of the
The OPP core currently stores the performance state in the consumer
device's OPP table, but that is going to change going forward and
performance state will rather be set directly in the genpd's OPP table.
For that we need to get the performance state for genpd's device
structure (genpd->dev)
The OPP core already has the performance state values for each of the
genpd's OPPs and there is no need to call the genpd callback again to
get the performance state for the case where the end device doesn't have
an OPP table and has the "required-opps" property directly in its node.
This commit
This isn't used anymore, remove it.
Signed-off-by: Viresh Kumar
---
drivers/opp/of.c | 54 --
include/linux/pm_opp.h | 5
2 files changed, 59 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 0755ee307b1a..da31874c7fe9
Now that all the infrastructure is in place to support multiple required
OPPs, lets switch over to using it.
A new internal routine _set_required_opps() takes care of updating
performance state for all the required OPPs. With this the performance
state updates are supported even when the end
An earlier commit populated the OPP tables from the "required-opps"
property, this commit populates the individual OPPs. This is repeated
for each OPP in the OPP table and these populated OPPs will be used by
later commits.
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
We need to handle genpd OPP tables differently, this is already the case
at one location and will be extended going forward. Add another field to
the OPP table to check if the table belongs to a genpd or not.
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
drivers/opp/of.c | 6 --
Multiple generic power domains for a consumer device are supported with
the help of virtual devices, which are created for each consumer device
- genpd pair. These are the device structures which are attached to the
power domain and are required by the OPP core to set the performance
state of the
The OPP core currently stores the performance state in the consumer
device's OPP table, but that is going to change going forward and
performance state will rather be set directly in the genpd's OPP table.
For that we need to get the performance state for genpd's device
structure (genpd->dev)
The OPP core already has the performance state values for each of the
genpd's OPPs and there is no need to call the genpd callback again to
get the performance state for the case where the end device doesn't have
an OPP table and has the "required-opps" property directly in its node.
This commit
This isn't used anymore, remove it.
Signed-off-by: Viresh Kumar
---
drivers/opp/of.c | 54 --
include/linux/pm_opp.h | 5
2 files changed, 59 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 0755ee307b1a..da31874c7fe9
The current implementation works only for the case where a single
phandle is present in the "required-opps" property, while DT allows
multiple phandles to be present there.
This patch adds new infrastructure to parse all the phandles present in
"required-opps" property and save pointers of the
The current implementation works only for the case where a single
phandle is present in the "required-opps" property, while DT allows
multiple phandles to be present there.
This patch adds new infrastructure to parse all the phandles present in
"required-opps" property and save pointers of the
Create a separate routine to take care of custom set_opp() handler
specific stuff.
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 67 +++---
1 file changed, 40 insertions(+), 27 deletions(-)
diff --git a/drivers/opp/core.c
Create a separate routine to take care of custom set_opp() handler
specific stuff.
Reviewed-by: Ulf Hansson
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 67 +++---
1 file changed, 40 insertions(+), 27 deletions(-)
diff --git a/drivers/opp/core.c
There are several struct device instances that genpd core handles. The
most common one is the consumer device structure, which is named
(correctly) as "dev" within genpd core. The second one is the genpd's
device structure, referenced as genpd->dev. The third one is the virtual
device structures
Hello,
This series improves the OPP core (and a bit of genpd core as well) to
support multiple phandles in the "required-opps" property, which are
only used for multiple power-domains per device for now.
We still don't propagate the changes to master domains for the
sub-domains, but this
There are several struct device instances that genpd core handles. The
most common one is the consumer device structure, which is named
(correctly) as "dev" within genpd core. The second one is the genpd's
device structure, referenced as genpd->dev. The third one is the virtual
device structures
Hello,
This series improves the OPP core (and a bit of genpd core as well) to
support multiple phandles in the "required-opps" property, which are
only used for multiple power-domains per device for now.
We still don't propagate the changes to master domains for the
sub-domains, but this
Commit-ID: ace6485a03266cc3c198ce8e927a1ce0ce139699
Gitweb: https://git.kernel.org/tip/ace6485a03266cc3c198ce8e927a1ce0ce139699
Author: Fenghua Yu
AuthorDate: Wed, 24 Oct 2018 14:57:17 -0700
Committer: Ingo Molnar
CommitDate: Thu, 25 Oct 2018 07:42:48 +0200
x86/cpufeatures: Enumerate
Commit-ID: ace6485a03266cc3c198ce8e927a1ce0ce139699
Gitweb: https://git.kernel.org/tip/ace6485a03266cc3c198ce8e927a1ce0ce139699
Author: Fenghua Yu
AuthorDate: Wed, 24 Oct 2018 14:57:17 -0700
Committer: Ingo Molnar
CommitDate: Thu, 25 Oct 2018 07:42:48 +0200
x86/cpufeatures: Enumerate
Commit-ID: 33823f4d63f7a010653d219800539409a78ef4be
Gitweb: https://git.kernel.org/tip/33823f4d63f7a010653d219800539409a78ef4be
Author: Fenghua Yu
AuthorDate: Wed, 24 Oct 2018 14:57:16 -0700
Committer: Ingo Molnar
CommitDate: Thu, 25 Oct 2018 07:42:48 +0200
x86/cpufeatures: Enumerate
Commit-ID: 33823f4d63f7a010653d219800539409a78ef4be
Gitweb: https://git.kernel.org/tip/33823f4d63f7a010653d219800539409a78ef4be
Author: Fenghua Yu
AuthorDate: Wed, 24 Oct 2018 14:57:16 -0700
Committer: Ingo Molnar
CommitDate: Thu, 25 Oct 2018 07:42:48 +0200
x86/cpufeatures: Enumerate
* Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> arch/x86/kernel/early-quirks.c contains special PCI quirks that need to
> run even before the usual DECLARE_PCI_FIXUP_EARLY() quirks. These have
> typically been merged by the x86 maintainers, which is fine, but PCI folks
> should at least
* Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> arch/x86/kernel/early-quirks.c contains special PCI quirks that need to
> run even before the usual DECLARE_PCI_FIXUP_EARLY() quirks. These have
> typically been merged by the x86 maintainers, which is fine, but PCI folks
> should at least
On 2018-10-23 11:43, Julia Lawall wrote:
On Tue, 23 Oct 2018, Michal Hocko wrote:
[Trimmed CC list + Julia - there is indeed no need to CC everybody
maintain a
file you are updating for the change like this]
On Tue 23-10-18 10:16:51, Arun Sudhilal wrote:
> On Mon, Oct 22, 2018 at 11:41 PM
On 2018-10-23 11:43, Julia Lawall wrote:
On Tue, 23 Oct 2018, Michal Hocko wrote:
[Trimmed CC list + Julia - there is indeed no need to CC everybody
maintain a
file you are updating for the change like this]
On Tue 23-10-18 10:16:51, Arun Sudhilal wrote:
> On Mon, Oct 22, 2018 at 11:41 PM
A week ago I upgraded to the latest Ubuntu distribution (Linux thunderbird
4.18.0-10-generic #11-Ubuntu SMP Thu Oct 11 15:13:55 UTC 2018 x86_64 x86_64
x86_64 GNU/Linux).
Whenever I run "shutdown -h now" or "reboot" I receive an immediate kernel
crash with a dump that has:
"Code: Bad RIP
A week ago I upgraded to the latest Ubuntu distribution (Linux thunderbird
4.18.0-10-generic #11-Ubuntu SMP Thu Oct 11 15:13:55 UTC 2018 x86_64 x86_64
x86_64 GNU/Linux).
Whenever I run "shutdown -h now" or "reboot" I receive an immediate kernel
crash with a dump that has:
"Code: Bad RIP
On (10/24/18 22:27), Rafael David Tinoco wrote:
> static unsigned long location_to_obj(struct page *page, unsigned int obj_idx)
> {
> - unsigned long obj;
> + unsigned long obj, pfn;
> +
> + pfn = page_to_pfn(page);
> +
> + if (unlikely(OBJ_OVERFLOW(pfn)))
> + BUG();
On (10/24/18 22:27), Rafael David Tinoco wrote:
> static unsigned long location_to_obj(struct page *page, unsigned int obj_idx)
> {
> - unsigned long obj;
> + unsigned long obj, pfn;
> +
> + pfn = page_to_pfn(page);
> +
> + if (unlikely(OBJ_OVERFLOW(pfn)))
> + BUG();
On Fri, Oct 5, 2018 at 7:59 PM Andy Gross wrote:
>
> On Tue, Oct 02, 2018 at 11:30:29AM +0200, Arnd Bergmann wrote:
> > On Sun, Sep 30, 2018 at 8:38 PM Andy Gross wrote:
> > >
> > > The following changes since commit
> > > 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> > >
> > > Linux 4.19-rc1
On Fri, Oct 5, 2018 at 7:59 PM Andy Gross wrote:
>
> On Tue, Oct 02, 2018 at 11:30:29AM +0200, Arnd Bergmann wrote:
> > On Sun, Sep 30, 2018 at 8:38 PM Andy Gross wrote:
> > >
> > > The following changes since commit
> > > 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> > >
> > > Linux 4.19-rc1
On Wed, 24 Oct 2018, Sven Van Asbroeck wrote:
> This patch adds devicetree binding documentation for the
> Arcx anybus bridge.
>
> Signed-off-by: Sven Van Asbroeck
> ---
> .../bindings/mfd/arcx,anybus-bridge.txt | 37 +++
> .../devicetree/bindings/vendor-prefixes.txt |
On Wed, 24 Oct 2018, Sven Van Asbroeck wrote:
> This patch adds devicetree binding documentation for the
> Arcx anybus bridge.
>
> Signed-off-by: Sven Van Asbroeck
> ---
> .../bindings/mfd/arcx,anybus-bridge.txt | 37 +++
> .../devicetree/bindings/vendor-prefixes.txt |
On 10/25/18 1:17 AM, Andrew Morton wrote:
> On Mon, 22 Oct 2018 15:27:54 +0200 Vlastimil Babka wrote:
>
>>> : Moreover the oriinal code allowed to trigger
>>> : WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));
>>> : in policy_node if the requested node (e.g. cpu local one)
On 10/25/18 1:17 AM, Andrew Morton wrote:
> On Mon, 22 Oct 2018 15:27:54 +0200 Vlastimil Babka wrote:
>
>>> : Moreover the oriinal code allowed to trigger
>>> : WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE));
>>> : in policy_node if the requested node (e.g. cpu local one)
> On Oct 24, 2018, at 8:46 PM, NeilBrown wrote:
>
>> On Wed, Oct 24 2018, Theodore Y. Ts'o wrote:
>>
>>> On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>>>
>>> I doubt it was copied - more likely independent evolution.
>>> But on reflection, I see that it is probably reasonable
> On Oct 24, 2018, at 8:46 PM, NeilBrown wrote:
>
>> On Wed, Oct 24 2018, Theodore Y. Ts'o wrote:
>>
>>> On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>>>
>>> I doubt it was copied - more likely independent evolution.
>>> But on reflection, I see that it is probably reasonable
On Wed, Oct 24 2018, Theodore Y. Ts'o wrote:
> On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>>
>> I doubt it was copied - more likely independent evolution.
>> But on reflection, I see that it is probably reasonable that it
>> shouldn't be used this way - or at all in this context.
On Wed, Oct 24 2018, Theodore Y. Ts'o wrote:
> On Wed, Oct 24, 2018 at 12:47:57PM +1100, NeilBrown wrote:
>>
>> I doubt it was copied - more likely independent evolution.
>> But on reflection, I see that it is probably reasonable that it
>> shouldn't be used this way - or at all in this context.
From: Nickhu
There two bitfield bug for perfomance counter
in bitfield.h:
PFM_CTL_offSEL1 21 --> 16
PFM_CTL_offSEL2 27 --> 22
This commit fix it.
Signed-off-by: Nickhu
---
arch/nds32/include/asm/bitfield.h | 4 ++--
1 file changed, 2 insertions(+), 2
From: Nickhu
There two bitfield bug for perfomance counter
in bitfield.h:
PFM_CTL_offSEL1 21 --> 16
PFM_CTL_offSEL2 27 --> 22
This commit fix it.
Signed-off-by: Nickhu
---
arch/nds32/include/asm/bitfield.h | 4 ++--
1 file changed, 2 insertions(+), 2
From: Nickhu
The document for how to add NDS32 PMU
in devicetree.
Signed-off-by: Nickhu
Reviewed-by: Rob Herring
---
.../devicetree/bindings/perf/nds32v3-pmu.txt| 17 +
1 file changed, 17 insertions(+)
create mode 100644
From: Nickhu
This is the commit that porting the perf for nds32.
1.Raw event:
The raw events start with 'r'.
Usage:
perf stat -e rXYZ ./app
X: the index of performance counter.
YZ: the index(convert
From: Nickhu
The document for how to add NDS32 PMU
in devicetree.
Signed-off-by: Nickhu
Reviewed-by: Rob Herring
---
.../devicetree/bindings/perf/nds32v3-pmu.txt| 17 +
1 file changed, 17 insertions(+)
create mode 100644
From: Nickhu
This is the commit that porting the perf for nds32.
1.Raw event:
The raw events start with 'r'.
Usage:
perf stat -e rXYZ ./app
X: the index of performance counter.
YZ: the index(convert
Hi, Michael,
Thanks a lot for the review and comments! Let us sync with Hyper-V team
to confirm these suspicious points.
BRs,
Sun Yi
On 18-10-24 16:53:00, Michael Kelley wrote:
> From: Yi Sun Sent: Friday, October 19, 2018 6:14
> AM
> >
> > The HvNotifyLongSpinWait hypercall
These four commits are perf supporting for nds32.
There are three perfomance counters in nds32, and
each of them can counts different events. You can
use 'perf list' to show the available events that
can be used.
Changes in V2:
1. Change the definition 'PFM_CTL_xxx' to
array form.
From: Nickhu
The perf call-graph option can trace the callchain
between functions. This commit add the perf callchain
for nds32. There are kerenl callchain and user callchain.
The kerenl callchain can trace the function in kernel
space. There are two type for user callchain. One for the
Hi, Michael,
Thanks a lot for the review and comments! Let us sync with Hyper-V team
to confirm these suspicious points.
BRs,
Sun Yi
On 18-10-24 16:53:00, Michael Kelley wrote:
> From: Yi Sun Sent: Friday, October 19, 2018 6:14
> AM
> >
> > The HvNotifyLongSpinWait hypercall
These four commits are perf supporting for nds32.
There are three perfomance counters in nds32, and
each of them can counts different events. You can
use 'perf list' to show the available events that
can be used.
Changes in V2:
1. Change the definition 'PFM_CTL_xxx' to
array form.
From: Nickhu
The perf call-graph option can trace the callchain
between functions. This commit add the perf callchain
for nds32. There are kerenl callchain and user callchain.
The kerenl callchain can trace the function in kernel
space. There are two type for user callchain. One for the
Hi Kirill,
Thanks for making this patchset. I have small concerns, please see the
inline comments.
On 10/24/18 at 03:51pm, Kirill A. Shutemov wrote:
> On 5-level paging LDT remap area is placed in the middle of
> KASLR randomization region and it can overlap with direct mapping,
> vmalloc or
Hi Kirill,
Thanks for making this patchset. I have small concerns, please see the
inline comments.
On 10/24/18 at 03:51pm, Kirill A. Shutemov wrote:
> On 5-level paging LDT remap area is placed in the middle of
> KASLR randomization region and it can overlap with direct mapping,
> vmalloc or
Oleg Nesterov wrote:
> On 10/22, Tetsuo Handa wrote:
> > > And again, I do not know how/if yama ensures that child is rcu-protected,
> > > perhaps
> > > task_is_descendant() needs to check pid_alive(child) right after
> > > rcu_read_lock() ?
> >
> > Since the caller (ptrace() path) called
Oleg Nesterov wrote:
> On 10/22, Tetsuo Handa wrote:
> > > And again, I do not know how/if yama ensures that child is rcu-protected,
> > > perhaps
> > > task_is_descendant() needs to check pid_alive(child) right after
> > > rcu_read_lock() ?
> >
> > Since the caller (ptrace() path) called
On Thu, Oct 25, 2018 at 02:01:02AM +0300, Igor Stoppa wrote:
> > > @@ -1747,6 +1750,10 @@ void *__vmalloc_node_range(unsigned long size,
> > > unsigned long align,
> > > if (!addr)
> > > return NULL;
> > > + va = __find_vmap_area((unsigned long)addr);
> > > + for (i =
On Thu, Oct 25, 2018 at 02:01:02AM +0300, Igor Stoppa wrote:
> > > @@ -1747,6 +1750,10 @@ void *__vmalloc_node_range(unsigned long size,
> > > unsigned long align,
> > > if (!addr)
> > > return NULL;
> > > + va = __find_vmap_area((unsigned long)addr);
> > > + for (i =
The function sdhci_allocate_bounce_buffer() always return zero at
present, so there's no need to have a return value, that will also make
error path easier.
CC: Linus Walleij
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 15 +--
1 file changed, 5 insertions(+), 10
The function sdhci_allocate_bounce_buffer() always return zero at
present, so there's no need to have a return value, that will also make
error path easier.
CC: Linus Walleij
Signed-off-by: Chunyan Zhang
---
drivers/mmc/host/sdhci.c | 15 +--
1 file changed, 5 insertions(+), 10
On Wed, Oct 24, 2018 at 05:09:05PM -0700, Florian Fainelli wrote:
> perf on ARM requires CONFIG_KUSER_HELPERS to be turned on to allow some
> independance with respect to the ARM CPU being used. Add a test which
> tries to locate the [vectors] page, created when CONFIG_KUSER_HELPERS is
> turned on
On Wed, Oct 24, 2018 at 05:09:05PM -0700, Florian Fainelli wrote:
> perf on ARM requires CONFIG_KUSER_HELPERS to be turned on to allow some
> independance with respect to the ARM CPU being used. Add a test which
> tries to locate the [vectors] page, created when CONFIG_KUSER_HELPERS is
> turned on
Hi Sebastian,
On 22 October 2018 at 15:43, Baolin Wang wrote:
> The internal resistance of a battery is not a constant in its life cycle,
> this varies over the age of the battery or temperature and so on. But we
> just want use one constant battery internal resistance to estimate the
> battery
Hi Sebastian,
On 22 October 2018 at 15:43, Baolin Wang wrote:
> The internal resistance of a battery is not a constant in its life cycle,
> this varies over the age of the battery or temperature and so on. But we
> just want use one constant battery internal resistance to estimate the
> battery
Hi Alexandre,
On 25 October 2018 at 08:34, Alexandre Belloni
wrote:
> Hello,
>
> On 18/10/2018 16:52:30+0800, Baolin Wang wrote:
>> When registering one RTC device, it will check to see if there is an
>> alarm already set in RTC hardware by reading RTC alarm, at this time
>> we should always
Hi Alexandre,
On 25 October 2018 at 08:34, Alexandre Belloni
wrote:
> Hello,
>
> On 18/10/2018 16:52:30+0800, Baolin Wang wrote:
>> When registering one RTC device, it will check to see if there is an
>> alarm already set in RTC hardware by reading RTC alarm, at this time
>> we should always
structure svm_init_data is never used. So remove it.
Signed-off-by: Peng Hao
---
arch/x86/kvm/svm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 61ccfb1..5c7dc8b 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -675,11 +675,6
structure svm_init_data is never used. So remove it.
Signed-off-by: Peng Hao
---
arch/x86/kvm/svm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 61ccfb1..5c7dc8b 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -675,11 +675,6
--
Dear Sir,
We are contacting your firm with a keen interest to consider a possible
collaboration through investments in viable projects globally. we are
an investment firm responsible for investing part of our client surplus
financial resources through a globally diversified investment
--
Dear Sir,
We are contacting your firm with a keen interest to consider a possible
collaboration through investments in viable projects globally. we are
an investment firm responsible for investing part of our client surplus
financial resources through a globally diversified investment
This patch adds the device tree bindings for the vibrator found on
various Qualcomm MSM SOCs.
Signed-off-by: Brian Masney
---
.../bindings/input/msm-vibrator.txt | 36 +++
1 file changed, 36 insertions(+)
create mode 100644
This patch set adds support for the vibrator found on various Qualcomm
MSM SOCs. This is based on work from:
Jonathan Marek from qcom,pwm-vibrator.c in the PostmarketOS repo:
https://gitlab.com/postmarketOS/linux-postmarketos/commit/7647fb36cb1cbd060f8b52087a68ab93583292b5
Jongrak Kwon and Devin
This patch adds the device tree bindings for the vibrator found on
various Qualcomm MSM SOCs.
Signed-off-by: Brian Masney
---
.../bindings/input/msm-vibrator.txt | 36 +++
1 file changed, 36 insertions(+)
create mode 100644
This patch set adds support for the vibrator found on various Qualcomm
MSM SOCs. This is based on work from:
Jonathan Marek from qcom,pwm-vibrator.c in the PostmarketOS repo:
https://gitlab.com/postmarketOS/linux-postmarketos/commit/7647fb36cb1cbd060f8b52087a68ab93583292b5
Jongrak Kwon and Devin
This patch adds a new vibrator driver that supports various Qualcomm
MSM SOCs. Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
drivers/input/misc/Kconfig| 10 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/msm-vibrator.c | 276
On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote:
> > On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> > > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner
> > > wrote:
> > >> On Fri, 19 Oct 2018, John Stultz
On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote:
> > On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> > > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner
> > > wrote:
> > >> On Fri, 19 Oct 2018, John Stultz
This patch adds a new vibrator driver that supports various Qualcomm
MSM SOCs. Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
drivers/input/misc/Kconfig| 10 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/msm-vibrator.c | 276
This patch adds device device tree bindings for the vibrator found on
the LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 31 +++
1 file changed, 31 insertions(+)
diff --git
This patch adds device device tree bindings for the vibrator found on
the LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
---
.../qcom-msm8974-lge-nexus5-hammerhead.dts| 31 +++
1 file changed, 31 insertions(+)
diff --git
Since commit 02390b87a945 ("mm/zsmalloc: Prepare to variable
MAX_PHYSMEM_BITS"), an architecture has to define this value in order to
guarantee that zsmalloc will be able to encode and decode the obj value
properly.
Similar to that change, this one sets the value for ARM LPAE, fixing a
possible
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break IF architecture does not re-define
MAX_PHYSMEM_BITS, causing:
[ 497.097843]
Since commit 02390b87a945 ("mm/zsmalloc: Prepare to variable
MAX_PHYSMEM_BITS"), an architecture has to define this value in order to
guarantee that zsmalloc will be able to encode and decode the obj value
properly.
Similar to that change, this one sets the value for ARM LPAE, fixing a
possible
On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
physical frame number might be so big that zsmalloc obj encoding (to
location) will break IF architecture does not re-define
MAX_PHYSMEM_BITS, causing:
[ 497.097843]
Daniel Jordan writes:
> On Wed, Oct 10, 2018 at 03:19:17PM +0800, Huang Ying wrote:
>> +static struct page *mc_handle_swap_pmd(struct vm_area_struct *vma,
>> +pmd_t pmd, swp_entry_t *entry)
>> +{
>
> Got
> /home/dbbench/linux/mm/memcontrol.c:4719:21: warning:
Daniel Jordan writes:
> On Wed, Oct 10, 2018 at 03:19:17PM +0800, Huang Ying wrote:
>> +static struct page *mc_handle_swap_pmd(struct vm_area_struct *vma,
>> +pmd_t pmd, swp_entry_t *entry)
>> +{
>
> Got
> /home/dbbench/linux/mm/memcontrol.c:4719:21: warning:
Hi Rob,
On Thu, Oct 25, 2018 at 02:32:48AM +0800, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 11:32:40AM +0800, Nickhu wrote:
> > The document for how to add NDS32 PMU
> > in devicetree.
> >
> > Signed-off-by: Nickhu
> > ---
> > Documentation/devicetree/bindings/nds32/pmu.txt | 17
Hi Rob,
On Thu, Oct 25, 2018 at 02:32:48AM +0800, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 11:32:40AM +0800, Nickhu wrote:
> > The document for how to add NDS32 PMU
> > in devicetree.
> >
> > Signed-off-by: Nickhu
> > ---
> > Documentation/devicetree/bindings/nds32/pmu.txt | 17
Daniel Jordan writes:
> On Wed, Oct 10, 2018 at 03:19:09PM +0800, Huang Ying wrote:
>> +#ifdef CONFIG_THP_SWAP
>> +/*
>> + * The corresponding page table shouldn't be changed under us, that
>> + * is, the page table lock should be held.
>> + */
>> +int split_swap_cluster_map(swp_entry_t entry)
Daniel Jordan writes:
> On Wed, Oct 10, 2018 at 03:19:09PM +0800, Huang Ying wrote:
>> +#ifdef CONFIG_THP_SWAP
>> +/*
>> + * The corresponding page table shouldn't be changed under us, that
>> + * is, the page table lock should be held.
>> + */
>> +int split_swap_cluster_map(swp_entry_t entry)
-Original Message-
From: Fabio Estevam [mailto:feste...@gmail.com]
Sent: 2018年10月24日 19:20
To: Joakim Zhang
Cc: Shawn Guo ; Sascha Hauer ;
Sascha Hauer ; Fabio Estevam ;
dl-linux-imx ; Rob Herring ; moderated
list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
; open list:OPEN FIRMWARE
On Wed, Oct 24, 2018 at 5:34 PM Peter Zijlstra wrote:
>
> On Wed, Oct 24, 2018 at 05:25:59PM -0700, Stephane Eranian wrote:
> > On Wed, Oct 24, 2018 at 5:23 PM Peter Zijlstra wrote:
>
> > > That is actually a different problem. And you're right, we never did fix
> > > that.
> > >
> > it is a
-Original Message-
From: Fabio Estevam [mailto:feste...@gmail.com]
Sent: 2018年10月24日 19:20
To: Joakim Zhang
Cc: Shawn Guo ; Sascha Hauer ;
Sascha Hauer ; Fabio Estevam ;
dl-linux-imx ; Rob Herring ; moderated
list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
; open list:OPEN FIRMWARE
On Wed, Oct 24, 2018 at 5:34 PM Peter Zijlstra wrote:
>
> On Wed, Oct 24, 2018 at 05:25:59PM -0700, Stephane Eranian wrote:
> > On Wed, Oct 24, 2018 at 5:23 PM Peter Zijlstra wrote:
>
> > > That is actually a different problem. And you're right, we never did fix
> > > that.
> > >
> > it is a
Daniel Jordan writes:
> On Wed, Oct 24, 2018 at 11:31:42AM +0800, Huang, Ying wrote:
>> Hi, Daniel,
>>
>> Daniel Jordan writes:
>>
>> > On Wed, Oct 10, 2018 at 03:19:03PM +0800, Huang Ying wrote:
>> >> And for all, Any comment is welcome!
>> >>
>> >> This patchset is based on the 2018-10-3
Daniel Jordan writes:
> On Wed, Oct 24, 2018 at 11:31:42AM +0800, Huang, Ying wrote:
>> Hi, Daniel,
>>
>> Daniel Jordan writes:
>>
>> > On Wed, Oct 10, 2018 at 03:19:03PM +0800, Huang Ying wrote:
>> >> And for all, Any comment is welcome!
>> >>
>> >> This patchset is based on the 2018-10-3
1 - 100 of 914 matches
Mail list logo
