Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

[Borislav Petkov]

On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote:
> > If I make the scattered feature support conditional on CONFIG_X86_64
> > (based on comment below) then cpu_has() will always be false unless
> > CONFIG_X86_64 is enabled. So this won't need to be wrapped by the
> > #ifdef.
> 
> If you change it to use cpu_feature_enabled(), gcc will see that it is
> disabled and eliminate the dead code at compile time.

Just do this:

   if (cpu_has(c, X86_FEATURE_SME)) {
   if (IS_ENABLED(CONFIG_X86_32)) {
   clear_cpu_cap(c, X86_FEATURE_SME);
   } else {
   u64 msr;

   /* Check if SME is enabled */
  rdmsrl(MSR_K8_SYSCFG, msr);
  if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
  clear_cpu_cap(c, X86_FEATURE_SME);
   }
   }

so that it is explicit that we disable it on 32-bit and we can save us
the ifdeffery elsewhere.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

[Borislav Petkov]

On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote:
> > If I make the scattered feature support conditional on CONFIG_X86_64
> > (based on comment below) then cpu_has() will always be false unless
> > CONFIG_X86_64 is enabled. So this won't need to be wrapped by the
> > #ifdef.
> 
> If you change it to use cpu_feature_enabled(), gcc will see that it is
> disabled and eliminate the dead code at compile time.

Just do this:

   if (cpu_has(c, X86_FEATURE_SME)) {
   if (IS_ENABLED(CONFIG_X86_32)) {
   clear_cpu_cap(c, X86_FEATURE_SME);
   } else {
   u64 msr;

   /* Check if SME is enabled */
  rdmsrl(MSR_K8_SYSCFG, msr);
  if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
  clear_cpu_cap(c, X86_FEATURE_SME);
   }
   }

so that it is explicit that we disable it on 32-bit and we can save us
the ifdeffery elsewhere.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Arvind Yadav]

Hi Joe,


On Tuesday 11 July 2017 11:17 AM, Joe Perches wrote:

On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:

Hi Joe,


On Monday 10 July 2017 10:30 PM, Joe Perches wrote:

On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

I think it's good you are doing all of these.

Instead of individually sending these patches, could you
please send a patch series for all of these attribute_group
patches with a cover letter at the same time?

That could make it easier for a trivial maintainer to apply
all of these at once and not get some applied and others
ignored or dropped on the floor.


Once again, I will send all of patch together, But I have doubt. If it's
having
different maintainer. Example- 'net:' subsystem is having a different
different
maintainer. So do i need to add all the maintainer in single list. Which
can confuse
what patch is for what maintainer. Please suggest me.

Please send individual patches, one per maintainer/subsystem
as a series with a cover letter like:

[PATCH 0/N] treewide: constify attribute_group structures
[PATCH 1/N] chelsio: cxgb3: constify attribute_group
[PATCH 2/N] chelsio: cxgb4: constify attribute_group
...
[PATCH N/N] subsystem: constify attribute_group


Thank you, I will follow as per your suggestion.

Regards,
~arvind

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Arvind Yadav]

Hi Joe,


On Tuesday 11 July 2017 11:17 AM, Joe Perches wrote:

On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:

Hi Joe,


On Monday 10 July 2017 10:30 PM, Joe Perches wrote:

On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

I think it's good you are doing all of these.

Instead of individually sending these patches, could you
please send a patch series for all of these attribute_group
patches with a cover letter at the same time?

That could make it easier for a trivial maintainer to apply
all of these at once and not get some applied and others
ignored or dropped on the floor.


Once again, I will send all of patch together, But I have doubt. If it's
having
different maintainer. Example- 'net:' subsystem is having a different
different
maintainer. So do i need to add all the maintainer in single list. Which
can confuse
what patch is for what maintainer. Please suggest me.

Please send individual patches, one per maintainer/subsystem
as a series with a cover letter like:

[PATCH 0/N] treewide: constify attribute_group structures
[PATCH 1/N] chelsio: cxgb3: constify attribute_group
[PATCH 2/N] chelsio: cxgb4: constify attribute_group
...
[PATCH N/N] subsystem: constify attribute_group


Thank you, I will follow as per your suggestion.

Regards,
~arvind

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Joe Perches]

On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:
> Hi Joe,
> 
> 
> On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
> > On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
> > > attribute_groups are not supposed to change at runtime. All functions
> > > working with attribute_groups provided by  work
> > > with const attribute_group. So mark the non-const structs as const.
> > 
> > I think it's good you are doing all of these.
> > 
> > Instead of individually sending these patches, could you
> > please send a patch series for all of these attribute_group
> > patches with a cover letter at the same time?
> > 
> > That could make it easier for a trivial maintainer to apply
> > all of these at once and not get some applied and others
> > ignored or dropped on the floor.
> > 
> 
> Once again, I will send all of patch together, But I have doubt. If it's 
> having
> different maintainer. Example- 'net:' subsystem is having a different 
> different
> maintainer. So do i need to add all the maintainer in single list. Which 
> can confuse
> what patch is for what maintainer. Please suggest me.

Please send individual patches, one per maintainer/subsystem
as a series with a cover letter like:

[PATCH 0/N] treewide: constify attribute_group structures
[PATCH 1/N] chelsio: cxgb3: constify attribute_group
[PATCH 2/N] chelsio: cxgb4: constify attribute_group
...
[PATCH N/N] subsystem: constify attribute_group

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Joe Perches]

On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:
> Hi Joe,
> 
> 
> On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
> > On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
> > > attribute_groups are not supposed to change at runtime. All functions
> > > working with attribute_groups provided by  work
> > > with const attribute_group. So mark the non-const structs as const.
> > 
> > I think it's good you are doing all of these.
> > 
> > Instead of individually sending these patches, could you
> > please send a patch series for all of these attribute_group
> > patches with a cover letter at the same time?
> > 
> > That could make it easier for a trivial maintainer to apply
> > all of these at once and not get some applied and others
> > ignored or dropped on the floor.
> > 
> 
> Once again, I will send all of patch together, But I have doubt. If it's 
> having
> different maintainer. Example- 'net:' subsystem is having a different 
> different
> maintainer. So do i need to add all the maintainer in single list. Which 
> can confuse
> what patch is for what maintainer. Please suggest me.

Please send individual patches, one per maintainer/subsystem
as a series with a cover letter like:

[PATCH 0/N] treewide: constify attribute_group structures
[PATCH 1/N] chelsio: cxgb3: constify attribute_group
[PATCH 2/N] chelsio: cxgb4: constify attribute_group
...
[PATCH N/N] subsystem: constify attribute_group

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Arvind Yadav]

Hi Joe,


On Monday 10 July 2017 10:30 PM, Joe Perches wrote:

On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

I think it's good you are doing all of these.

Instead of individually sending these patches, could you
please send a patch series for all of these attribute_group
patches with a cover letter at the same time?

That could make it easier for a trivial maintainer to apply
all of these at once and not get some applied and others
ignored or dropped on the floor.

Once again, I will send all of patch together, But I have doubt. If it's 
having
different maintainer. Example- 'net:' subsystem is having a different 
different
maintainer. So do i need to add all the maintainer in single list. Which 
can confuse

what patch is for what maintainer. Please suggest me.

Thanks ,
~arvind

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Arvind Yadav]

Hi Joe,


On Monday 10 July 2017 10:30 PM, Joe Perches wrote:

On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

I think it's good you are doing all of these.

Instead of individually sending these patches, could you
please send a patch series for all of these attribute_group
patches with a cover letter at the same time?

That could make it easier for a trivial maintainer to apply
all of these at once and not get some applied and others
ignored or dropped on the floor.

Once again, I will send all of patch together, But I have doubt. If it's 
having
different maintainer. Example- 'net:' subsystem is having a different 
different
maintainer. So do i need to add all the maintainer in single list. Which 
can confuse

what patch is for what maintainer. Please suggest me.

Thanks ,
~arvind

Re: [greybus-dev] [PATCH v2] staging: greybus: arche: wrap over-length lines

[Joe Perches]

On Mon, 2017-07-10 at 15:01 +0530, Viresh Kumar wrote:
> On 10-07-17, 11:30, Frans Klaver wrote:
> > On Mon, Jul 10, 2017 at 6:46 AM, Viresh Kumar  
> > wrote:
> > > Hi Mitchell,
> > > 
> > > On 09-07-17, 20:25, Mitchell Tasman wrote:
> > > > Adjust formatting of various statements to keep line length within
> > > > the 80 column limit preferred by the Linux kernel coding style.
> > > 
> > > We try to follow that most of the time, but the end result should be 
> > > easily
> > > readable.  If it isn't, then we just ignore the rule.
> > > 
> > > > Signed-off-by: Mitchell Tasman 
> > > > ---
> > > > Changes in v2: Add back a missing space in a comment
> > > > 
> > > >  drivers/staging/greybus/arche-platform.c | 29 
> > > > +++--
> > > >  1 file changed, 19 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/greybus/arche-platform.c 
> > > > b/drivers/staging/greybus/arche-platform.c
> > > > index eced2d2..eedd239 100644
> > > > --- a/drivers/staging/greybus/arche-platform.c
> > > > +++ b/drivers/staging/greybus/arche-platform.c
> > > > @@ -172,15 +172,21 @@ static irqreturn_t arche_platform_wd_irq(int irq, 
> > > > void *devid)
> > > >   if (arche_pdata->wake_detect_state == WD_STATE_BOOT_INIT) 
> > > > {
> > > >   if (time_before(jiffies,
> > > >   arche_pdata->wake_detect_start +
> > > > - 
> > > > msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
> > > > - 
> > > > arche_platform_set_wake_detect_state(arche_pdata,
> > > > -  
> > > > WD_STATE_IDLE);
> > > > + msecs_to_jiffies(
> > > > + 
> > > > WD_COLDBOOT_PULSE_WIDTH_MS))) {
> > > > + arche_platform_set_wake_detect_state(
> > > 
> > > We don't break the lines like this in kernel to satisfy the 80 column 
> > > width
> > > rule. Surely, some places would have similar code, but in general this 
> > > isn't
> > > recommended. And that's why we never bothered about 80 column rule in 
> > > this and
> > > below cases.
> > 
> > In cases like this, one could argue that you should start looking at
> > the level of indentation, rather than the line length per se. After
> > all, the documentation states that "if you need more than 3 levels of
> > indentation, you're screwed anyway, and you should fix your program".
> 
> And I completely agree to that :)

Another thing to consider is to s/arche_platform_//
as the identifier lengths are just way too long.

Re: [greybus-dev] [PATCH v2] staging: greybus: arche: wrap over-length lines

[Joe Perches]

On Mon, 2017-07-10 at 15:01 +0530, Viresh Kumar wrote:
> On 10-07-17, 11:30, Frans Klaver wrote:
> > On Mon, Jul 10, 2017 at 6:46 AM, Viresh Kumar  
> > wrote:
> > > Hi Mitchell,
> > > 
> > > On 09-07-17, 20:25, Mitchell Tasman wrote:
> > > > Adjust formatting of various statements to keep line length within
> > > > the 80 column limit preferred by the Linux kernel coding style.
> > > 
> > > We try to follow that most of the time, but the end result should be 
> > > easily
> > > readable.  If it isn't, then we just ignore the rule.
> > > 
> > > > Signed-off-by: Mitchell Tasman 
> > > > ---
> > > > Changes in v2: Add back a missing space in a comment
> > > > 
> > > >  drivers/staging/greybus/arche-platform.c | 29 
> > > > +++--
> > > >  1 file changed, 19 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/greybus/arche-platform.c 
> > > > b/drivers/staging/greybus/arche-platform.c
> > > > index eced2d2..eedd239 100644
> > > > --- a/drivers/staging/greybus/arche-platform.c
> > > > +++ b/drivers/staging/greybus/arche-platform.c
> > > > @@ -172,15 +172,21 @@ static irqreturn_t arche_platform_wd_irq(int irq, 
> > > > void *devid)
> > > >   if (arche_pdata->wake_detect_state == WD_STATE_BOOT_INIT) 
> > > > {
> > > >   if (time_before(jiffies,
> > > >   arche_pdata->wake_detect_start +
> > > > - 
> > > > msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
> > > > - 
> > > > arche_platform_set_wake_detect_state(arche_pdata,
> > > > -  
> > > > WD_STATE_IDLE);
> > > > + msecs_to_jiffies(
> > > > + 
> > > > WD_COLDBOOT_PULSE_WIDTH_MS))) {
> > > > + arche_platform_set_wake_detect_state(
> > > 
> > > We don't break the lines like this in kernel to satisfy the 80 column 
> > > width
> > > rule. Surely, some places would have similar code, but in general this 
> > > isn't
> > > recommended. And that's why we never bothered about 80 column rule in 
> > > this and
> > > below cases.
> > 
> > In cases like this, one could argue that you should start looking at
> > the level of indentation, rather than the line length per se. After
> > all, the documentation states that "if you need more than 3 levels of
> > indentation, you're screwed anyway, and you should fix your program".
> 
> And I completely agree to that :)

Another thing to consider is to s/arche_platform_//
as the identifier lengths are just way too long.

Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used

[Joel Fernandes]

On Mon, Jul 10, 2017 at 10:49 AM, Vikram Mulukutla
 wrote:
[..]
>
>>> Given that the utilization update hooks are called with the per-cpu rq
>>> lock
>>> held (for all classes), I don't think PELT utilization can change
>>> throughout
>>> the lifetime of the cpufreq_update_{util,this_cpu} call? Even with
>>> Viresh's
>>> remote cpu callback series we'd still have to hold the rq lock across
>>> cpufreq_update_util..  what can change today is 'max'
>>> (arch_scale_cpu_capacity) when a cpufreq policy is shared, so the patch
>>> is
>>> still needed for that reason I think?
>>>
>>
>> I didn't follow, Could you elaborate more why you think the patch
>> helps with the case where max changes while the per-cpu rq lock held?
>>
>
> So going by Patrick's commit text, the concern was a TOC/TOU
> problem, but since we agree that CFS utilization can't change
> within an rq-locked critical section, the only thing that can
> change is 'max'. So you might be the 8th cpu in line waiting
> for the sg-policy lock, and after you get the lock, the max may
> be outdated.
>
> But come to think of it max changes should be triggering schedutil
> updates and those shouldn't be rate-throttled, so maybe we don't
> need this at all? It's still somewhat future-proof in case there
> is some stat that we read in sugov_get_util that can be updated
> asynchronously. However we can put it in when we need it...

It looks like Juri's patch [1] to split signals already cleaned it up
so we should be all set ;-)

Thanks,

-Joel

[1] https://patchwork.kernel.org/patch/9826201/

Re: [PATCH v2 4/6] cpufreq: schedutil: update CFS util only if used

[Joel Fernandes]

On Mon, Jul 10, 2017 at 10:49 AM, Vikram Mulukutla
 wrote:
[..]
>
>>> Given that the utilization update hooks are called with the per-cpu rq
>>> lock
>>> held (for all classes), I don't think PELT utilization can change
>>> throughout
>>> the lifetime of the cpufreq_update_{util,this_cpu} call? Even with
>>> Viresh's
>>> remote cpu callback series we'd still have to hold the rq lock across
>>> cpufreq_update_util..  what can change today is 'max'
>>> (arch_scale_cpu_capacity) when a cpufreq policy is shared, so the patch
>>> is
>>> still needed for that reason I think?
>>>
>>
>> I didn't follow, Could you elaborate more why you think the patch
>> helps with the case where max changes while the per-cpu rq lock held?
>>
>
> So going by Patrick's commit text, the concern was a TOC/TOU
> problem, but since we agree that CFS utilization can't change
> within an rq-locked critical section, the only thing that can
> change is 'max'. So you might be the 8th cpu in line waiting
> for the sg-policy lock, and after you get the lock, the max may
> be outdated.
>
> But come to think of it max changes should be triggering schedutil
> updates and those shouldn't be rate-throttled, so maybe we don't
> need this at all? It's still somewhat future-proof in case there
> is some stat that we read in sugov_get_util that can be updated
> asynchronously. However we can put it in when we need it...

It looks like Juri's patch [1] to split signals already cleaned it up
so we should be all set ;-)

Thanks,

-Joel

[1] https://patchwork.kernel.org/patch/9826201/

Re: [PATCH V4 5/6] iommu/arm-smmu: Add support for MMU40x/500 clocks

[Vivek Gautam]

Hi Rob,


On 07/10/2017 09:07 AM, Rob Herring wrote:

On Thu, Jul 06, 2017 at 03:07:04PM +0530, Vivek Gautam wrote:

From: Sricharan R

The MMU400x/500 is the implementation of the SMMUv2
arch specification. It is split in to two blocks
TBU, TCU. TBU caches the page table, instantiated
for each master locally, clocked by the TBUn_clk.
TCU manages the address translation with PTW and has
the programming interface as well, clocked using the
TCU_CLK. The TBU can also be sharing the same clock
domain as TCU, in which case both are clocked using
the TCU_CLK.

No TBU clock below. When is it shared or not? If that's an integration
option then the binding should always have a TBU clock with the same
parent as the TCU_CLK.


Right. This is something that the ARM spec also says.
The TBU clock can either be in the same clock and power domain as
the TCU clock, or in a separate.

As you said, we should have the TBU clock as well, and based on the
integration the TBU clock can either have same parent as TCU or
different.

I will change these bindings to include the TBU clock as well.


Best Regards
Vivek


This defines the clock bindings for the same and adds
the clock names to compatible data.

Signed-off-by: Sricharan R
[vivek: clock rework and cleanup]
Signed-off-by: Vivek Gautam
---
  .../devicetree/bindings/iommu/arm,smmu.txt | 24 ++
  drivers/iommu/arm-smmu.c   | 12 ++-
  2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 8a6ffce12af5..00331752d355 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -71,6 +71,26 @@ conditions.
or using stream matching with #iommu-cells = <2>, and
may be ignored if present in such cases.
  
+- clock-names:Should be "tcu" and "iface" for "arm,mmu-400",

+  "arm,mmu-401" and "arm,mmu-500"
+
+  "tcu" clock is required for smmu's register access using the
+  programming interface and ptw for downstream bus access. This
+  clock is also used for access to the TBU connected to the
+  master locally. Sometimes however, TBU is clocked along with
+  the master.
+
+  "iface" clock is required to access the TCU's programming
+  interface, apart from the "tcu" clock.
+
+- clocks: Phandles for respective clocks described by clock-names.
+
+- power-domains:  Phandles to SMMU's power domain specifier. This is
+  required even if SMMU belongs to the master's power
+  domain, as the SMMU will have to be enabled and
+  accessed before master gets enabled and linked to its
+  SMMU.
+
  ** Deprecated properties:
  
  - mmu-masters (deprecated in favour of the generic "iommus" binding) :

@@ -95,6 +115,10 @@ conditions.
   <0 36 4>,
   <0 37 4>;
  #iommu-cells = <1>;
+clocks = < GCC_SMMU_CFG_CLK>,
+ < GCC_APSS_TCU_CLK>;
+
+   clock-names = "iface", "tcu";
  };
  
  /* device with two stream IDs, 0 and 7 */

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 75567d9698ab..7bb09280fa11 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1947,9 +1947,19 @@ struct arm_smmu_match_data {
  ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);
  ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
  ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, GENERIC_SMMU);
-ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
  ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
  
+static const char * const arm_mmu500_clks[] = {

+   "tcu", "iface",
+};
+
+static const struct arm_smmu_match_data arm_mmu500 = {
+   .version = ARM_SMMU_V2,
+   .model = ARM_MMU500,
+   .clks = arm_mmu500_clks,
+   .num_clks = ARRAY_SIZE(arm_mmu500_clks),
+};
+
  static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v1", .data = _generic_v1 },
{ .compatible = "arm,smmu-v2", .data = _generic_v2 },
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message tomajord...@vger.kernel.org
More majordomo info athttp://vger.kernel.org/majordomo-info.html


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V4 5/6] iommu/arm-smmu: Add support for MMU40x/500 clocks

[Vivek Gautam]

Hi Rob,


On 07/10/2017 09:07 AM, Rob Herring wrote:

On Thu, Jul 06, 2017 at 03:07:04PM +0530, Vivek Gautam wrote:

From: Sricharan R

The MMU400x/500 is the implementation of the SMMUv2
arch specification. It is split in to two blocks
TBU, TCU. TBU caches the page table, instantiated
for each master locally, clocked by the TBUn_clk.
TCU manages the address translation with PTW and has
the programming interface as well, clocked using the
TCU_CLK. The TBU can also be sharing the same clock
domain as TCU, in which case both are clocked using
the TCU_CLK.

No TBU clock below. When is it shared or not? If that's an integration
option then the binding should always have a TBU clock with the same
parent as the TCU_CLK.


Right. This is something that the ARM spec also says.
The TBU clock can either be in the same clock and power domain as
the TCU clock, or in a separate.

As you said, we should have the TBU clock as well, and based on the
integration the TBU clock can either have same parent as TCU or
different.

I will change these bindings to include the TBU clock as well.


Best Regards
Vivek


This defines the clock bindings for the same and adds
the clock names to compatible data.

Signed-off-by: Sricharan R
[vivek: clock rework and cleanup]
Signed-off-by: Vivek Gautam
---
  .../devicetree/bindings/iommu/arm,smmu.txt | 24 ++
  drivers/iommu/arm-smmu.c   | 12 ++-
  2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 8a6ffce12af5..00331752d355 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -71,6 +71,26 @@ conditions.
or using stream matching with #iommu-cells = <2>, and
may be ignored if present in such cases.
  
+- clock-names:Should be "tcu" and "iface" for "arm,mmu-400",

+  "arm,mmu-401" and "arm,mmu-500"
+
+  "tcu" clock is required for smmu's register access using the
+  programming interface and ptw for downstream bus access. This
+  clock is also used for access to the TBU connected to the
+  master locally. Sometimes however, TBU is clocked along with
+  the master.
+
+  "iface" clock is required to access the TCU's programming
+  interface, apart from the "tcu" clock.
+
+- clocks: Phandles for respective clocks described by clock-names.
+
+- power-domains:  Phandles to SMMU's power domain specifier. This is
+  required even if SMMU belongs to the master's power
+  domain, as the SMMU will have to be enabled and
+  accessed before master gets enabled and linked to its
+  SMMU.
+
  ** Deprecated properties:
  
  - mmu-masters (deprecated in favour of the generic "iommus" binding) :

@@ -95,6 +115,10 @@ conditions.
   <0 36 4>,
   <0 37 4>;
  #iommu-cells = <1>;
+clocks = < GCC_SMMU_CFG_CLK>,
+ < GCC_APSS_TCU_CLK>;
+
+   clock-names = "iface", "tcu";
  };
  
  /* device with two stream IDs, 0 and 7 */

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 75567d9698ab..7bb09280fa11 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1947,9 +1947,19 @@ struct arm_smmu_match_data {
  ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);
  ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
  ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K, GENERIC_SMMU);
-ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
  ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
  
+static const char * const arm_mmu500_clks[] = {

+   "tcu", "iface",
+};
+
+static const struct arm_smmu_match_data arm_mmu500 = {
+   .version = ARM_SMMU_V2,
+   .model = ARM_MMU500,
+   .clks = arm_mmu500_clks,
+   .num_clks = ARRAY_SIZE(arm_mmu500_clks),
+};
+
  static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v1", .data = _generic_v1 },
{ .compatible = "arm,smmu-v2", .data = _generic_v2 },
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message tomajord...@vger.kernel.org
More majordomo info athttp://vger.kernel.org/majordomo-info.html


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

[Tony Lindgren]

* Mark Brown  [170710 10:52]:
> On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id cpcap_audio_of_match[] = {
> > +   { .compatible = "motorola,cpcap-audio-codec", },
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, cpcap_audio_of_match);
> > +#endif
> 
> If this is part of a MFD shouldn't the parent device register it without
> it needing to be in the DT?

Having the MFD core part just do devm_of_platform_populate() leaves out
dependencies between the MFD core and it's child devices.

There are also a lot of board specific configuration to be done for many
child devices such as ADC wiring, GPIO pins used, and macro firmware
usage.

Not sure what all board specific stuff needs to be configured for this
driver yet, but it seems at least the macro interrupt wiring needs to
be configured. I would not be surprised to find GPIOs or ADC being used
for some connector detection too.

Regards,

Tony

Re: [PATCH 1/3] ASoC: codec: cpcap: new codec

[Tony Lindgren]

* Mark Brown  [170710 10:52]:
> On Fri, Jul 07, 2017 at 06:42:27PM +0200, Sebastian Reichel wrote:
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id cpcap_audio_of_match[] = {
> > +   { .compatible = "motorola,cpcap-audio-codec", },
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, cpcap_audio_of_match);
> > +#endif
> 
> If this is part of a MFD shouldn't the parent device register it without
> it needing to be in the DT?

Having the MFD core part just do devm_of_platform_populate() leaves out
dependencies between the MFD core and it's child devices.

There are also a lot of board specific configuration to be done for many
child devices such as ADC wiring, GPIO pins used, and macro firmware
usage.

Not sure what all board specific stuff needs to be configured for this
driver yet, but it seems at least the macro interrupt wiring needs to
be configured. I would not be surprised to find GPIOs or ADC being used
for some connector detection too.

Regards,

Tony

Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient

[Joel Fernandes]

Hi Juri,

On Mon, Jul 10, 2017 at 3:55 AM, Juri Lelli  wrote:
> Hi Joel,
>
> On 09/07/17 10:08, Joel Fernandes wrote:
>> Currently the iowait_boost feature in schedutil makes the frequency go to 
>> max.
>> This feature was added to handle a case that Peter described where the
>> throughput of operations involving continuous I/O requests [1] is reduced due
>> to running at a lower frequency, however the lower throughput itself causes
>> utilization to be low and hence causing frequency to be low hence its 
>> "stuck".
>>
>> Instead of going to max, its also possible to achieve the same effect by
>> ramping up to max if there are repeated in_iowait wakeups happening. This 
>> patch
>> is an attempt to do that. We start from a lower frequency (iowait_boost_min)
>> and double the boost for every consecutive iowait update until we reach the
>> maximum iowait boost frequency (iowait_boost_max).
>>
>> I ran a synthetic test on an x86 machine with intel_pstate in passive mode
>> using schedutil. The patch achieves the desired effect as the existing
>> behavior. Also tested on ARM64 platform and see that there the transient 
>> iowait
>> requests aren't causing frequency spikes.
>>
>> [1] https://patchwork.kernel.org/patch/9735885/
>>
>> Cc: Srinivas Pandruvada 
>> Cc: Len Brown 
>> Cc: Rafael J. Wysocki 
>> Cc: Viresh Kumar 
>> Cc: Ingo Molnar 
>> Cc: Peter Zijlstra 
>> Suggested-by: Peter Zijlstra 
>> Signed-off-by: Joel Fernandes 
[..]
>>
>> diff --git a/kernel/sched/cpufreq_schedutil.c 
>> b/kernel/sched/cpufreq_schedutil.c
>> index 622eed1b7658..4d9e8b96bed1 100644
>> --- a/kernel/sched/cpufreq_schedutil.c
>> +++ b/kernel/sched/cpufreq_schedutil.c
>> @@ -53,7 +53,9 @@ struct sugov_cpu {
>>   struct update_util_data update_util;
>>   struct sugov_policy *sg_policy;
>>
>> + bool prev_iowait_boost;
>>   unsigned long iowait_boost;
>> + unsigned long iowait_boost_min;
>>   unsigned long iowait_boost_max;
>>   u64 last_update;
>>
>> @@ -168,22 +170,47 @@ static void sugov_get_util(unsigned long *util, 
>> unsigned long *max)
>>   *max = cfs_max;
>>  }
>>
>> +static void sugov_decay_iowait_boost(struct sugov_cpu *sg_cpu)
>> +{
>> + sg_cpu->iowait_boost >>= 1;
>> +
>> + if (sg_cpu->iowait_boost < sg_cpu->iowait_boost_min)
>> + sg_cpu->iowait_boost = 0;
>> +}
>> +
>>  static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
>>  unsigned int flags)
>>  {
>>   if (flags & SCHED_CPUFREQ_IOWAIT) {
>> - sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
>> + /* Remember for next time that we did an iowait boost */
>> + sg_cpu->prev_iowait_boost = true;
>> + if (sg_cpu->iowait_boost) {
>> + sg_cpu->iowait_boost <<= 1;
>> + sg_cpu->iowait_boost = min(sg_cpu->iowait_boost,
>> +sg_cpu->iowait_boost_max);
>> + } else {
>> + sg_cpu->iowait_boost = sg_cpu->iowait_boost_min;
>> + }
>>   } else if (sg_cpu->iowait_boost) {
>>   s64 delta_ns = time - sg_cpu->last_update;
>>
>>   /* Clear iowait_boost if the CPU apprears to have been idle. */
>>   if (delta_ns > TICK_NSEC)
>>   sg_cpu->iowait_boost = 0;
>
> In this case we might just also want to reset prev_iowait_boost
> unconditionally and return.

Ok, will do.

>> +
>> + /*
>> +  * Since we don't decay iowait_boost when its consumed during
>> +  * the previous SCHED_CPUFREQ_IOWAIT update, decay it now.
>> +  */
>
> Code below seems pretty self-explaning to me. :)
>

Ok :)

>> + if (sg_cpu->prev_iowait_boost) {
>> + sugov_decay_iowait_boost(sg_cpu);
>> + sg_cpu->prev_iowait_boost = false;
>> + }
>>   }
>>  }
>>
>>  static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long 
>> *util,
>> -unsigned long *max)
>> +unsigned long *max, unsigned int flags)
>>  {
>>   unsigned long boost_util = sg_cpu->iowait_boost;
>>   unsigned long boost_max = sg_cpu->iowait_boost_max;
>> @@ -195,7 +222,16 @@ static void sugov_iowait_boost(struct sugov_cpu 
>> *sg_cpu, unsigned long *util,
>>   *util = boost_util;
>>   *max = boost_max;
>>   }
>> - sg_cpu->iowait_boost >>= 1;
>> +
>> + /*
>> +  * Incase iowait boost just happened on this CPU, don't reduce it right
>> +  * away since then the iowait boost will never increase on subsequent
>> +  * in_iowait wakeups.
>> +  */
>> + if (flags & SCHED_CPUFREQ_IOWAIT && 

Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient

[Joel Fernandes]

Hi Juri,

On Mon, Jul 10, 2017 at 3:55 AM, Juri Lelli  wrote:
> Hi Joel,
>
> On 09/07/17 10:08, Joel Fernandes wrote:
>> Currently the iowait_boost feature in schedutil makes the frequency go to 
>> max.
>> This feature was added to handle a case that Peter described where the
>> throughput of operations involving continuous I/O requests [1] is reduced due
>> to running at a lower frequency, however the lower throughput itself causes
>> utilization to be low and hence causing frequency to be low hence its 
>> "stuck".
>>
>> Instead of going to max, its also possible to achieve the same effect by
>> ramping up to max if there are repeated in_iowait wakeups happening. This 
>> patch
>> is an attempt to do that. We start from a lower frequency (iowait_boost_min)
>> and double the boost for every consecutive iowait update until we reach the
>> maximum iowait boost frequency (iowait_boost_max).
>>
>> I ran a synthetic test on an x86 machine with intel_pstate in passive mode
>> using schedutil. The patch achieves the desired effect as the existing
>> behavior. Also tested on ARM64 platform and see that there the transient 
>> iowait
>> requests aren't causing frequency spikes.
>>
>> [1] https://patchwork.kernel.org/patch/9735885/
>>
>> Cc: Srinivas Pandruvada 
>> Cc: Len Brown 
>> Cc: Rafael J. Wysocki 
>> Cc: Viresh Kumar 
>> Cc: Ingo Molnar 
>> Cc: Peter Zijlstra 
>> Suggested-by: Peter Zijlstra 
>> Signed-off-by: Joel Fernandes 
[..]
>>
>> diff --git a/kernel/sched/cpufreq_schedutil.c 
>> b/kernel/sched/cpufreq_schedutil.c
>> index 622eed1b7658..4d9e8b96bed1 100644
>> --- a/kernel/sched/cpufreq_schedutil.c
>> +++ b/kernel/sched/cpufreq_schedutil.c
>> @@ -53,7 +53,9 @@ struct sugov_cpu {
>>   struct update_util_data update_util;
>>   struct sugov_policy *sg_policy;
>>
>> + bool prev_iowait_boost;
>>   unsigned long iowait_boost;
>> + unsigned long iowait_boost_min;
>>   unsigned long iowait_boost_max;
>>   u64 last_update;
>>
>> @@ -168,22 +170,47 @@ static void sugov_get_util(unsigned long *util, 
>> unsigned long *max)
>>   *max = cfs_max;
>>  }
>>
>> +static void sugov_decay_iowait_boost(struct sugov_cpu *sg_cpu)
>> +{
>> + sg_cpu->iowait_boost >>= 1;
>> +
>> + if (sg_cpu->iowait_boost < sg_cpu->iowait_boost_min)
>> + sg_cpu->iowait_boost = 0;
>> +}
>> +
>>  static void sugov_set_iowait_boost(struct sugov_cpu *sg_cpu, u64 time,
>>  unsigned int flags)
>>  {
>>   if (flags & SCHED_CPUFREQ_IOWAIT) {
>> - sg_cpu->iowait_boost = sg_cpu->iowait_boost_max;
>> + /* Remember for next time that we did an iowait boost */
>> + sg_cpu->prev_iowait_boost = true;
>> + if (sg_cpu->iowait_boost) {
>> + sg_cpu->iowait_boost <<= 1;
>> + sg_cpu->iowait_boost = min(sg_cpu->iowait_boost,
>> +sg_cpu->iowait_boost_max);
>> + } else {
>> + sg_cpu->iowait_boost = sg_cpu->iowait_boost_min;
>> + }
>>   } else if (sg_cpu->iowait_boost) {
>>   s64 delta_ns = time - sg_cpu->last_update;
>>
>>   /* Clear iowait_boost if the CPU apprears to have been idle. */
>>   if (delta_ns > TICK_NSEC)
>>   sg_cpu->iowait_boost = 0;
>
> In this case we might just also want to reset prev_iowait_boost
> unconditionally and return.

Ok, will do.

>> +
>> + /*
>> +  * Since we don't decay iowait_boost when its consumed during
>> +  * the previous SCHED_CPUFREQ_IOWAIT update, decay it now.
>> +  */
>
> Code below seems pretty self-explaning to me. :)
>

Ok :)

>> + if (sg_cpu->prev_iowait_boost) {
>> + sugov_decay_iowait_boost(sg_cpu);
>> + sg_cpu->prev_iowait_boost = false;
>> + }
>>   }
>>  }
>>
>>  static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long 
>> *util,
>> -unsigned long *max)
>> +unsigned long *max, unsigned int flags)
>>  {
>>   unsigned long boost_util = sg_cpu->iowait_boost;
>>   unsigned long boost_max = sg_cpu->iowait_boost_max;
>> @@ -195,7 +222,16 @@ static void sugov_iowait_boost(struct sugov_cpu 
>> *sg_cpu, unsigned long *util,
>>   *util = boost_util;
>>   *max = boost_max;
>>   }
>> - sg_cpu->iowait_boost >>= 1;
>> +
>> + /*
>> +  * Incase iowait boost just happened on this CPU, don't reduce it right
>> +  * away since then the iowait boost will never increase on subsequent
>> +  * in_iowait wakeups.
>> +  */
>> + if (flags & SCHED_CPUFREQ_IOWAIT && this_cpu_ptr(_cpu) == sg_cpu)
>> + return;
>> +
>> + sugov_decay_iowait_boost(sg_cpu);
>
> Mmm, do we need to decay even when we are computing frequency requests
> for a domain?
>
> Considering it a 

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

[Brian Gerst]

On Mon, Jul 10, 2017 at 3:41 PM, Tom Lendacky  wrote:
> On 7/8/2017 7:50 AM, Brian Gerst wrote:
>>
>> On Fri, Jul 7, 2017 at 9:38 AM, Tom Lendacky 
>> wrote:
>>>
>>> Update the CPU features to include identifying and reporting on the
>>> Secure Memory Encryption (SME) feature.  SME is identified by CPUID
>>> 0x801f, but requires BIOS support to enable it (set bit 23 of
>>> MSR_K8_SYSCFG).  Only show the SME feature as available if reported by
>>> CPUID and enabled by BIOS.
>>>
>>> Reviewed-by: Borislav Petkov 
>>> Signed-off-by: Tom Lendacky 
>>> ---
>>>   arch/x86/include/asm/cpufeatures.h |1 +
>>>   arch/x86/include/asm/msr-index.h   |2 ++
>>>   arch/x86/kernel/cpu/amd.c  |   13 +
>>>   arch/x86/kernel/cpu/scattered.c|1 +
>>>   4 files changed, 17 insertions(+)
>>>
>>> diff --git a/arch/x86/include/asm/cpufeatures.h
>>> b/arch/x86/include/asm/cpufeatures.h
>>> index 2701e5f..2b692df 100644
>>> --- a/arch/x86/include/asm/cpufeatures.h
>>> +++ b/arch/x86/include/asm/cpufeatures.h
>>> @@ -196,6 +196,7 @@
>>>
>>>   #define X86_FEATURE_HW_PSTATE  ( 7*32+ 8) /* AMD HW-PState */
>>>   #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD
>>> ProcFeedbackInterface */
>>> +#define X86_FEATURE_SME( 7*32+10) /* AMD Secure Memory
>>> Encryption */
>>
>>
>> Given that this feature is available only in long mode, this should be
>> added to disabled-features.h as disabled for 32-bit builds.
>
>
> I can add that.  If the series needs a re-spin then I'll include this
> change in the series, otherwise I can send a follow-on patch to handle
> the feature for 32-bit builds if that works.
>
>
>>
>>>   #define X86_FEATURE_INTEL_PPIN ( 7*32+14) /* Intel Processor Inventory
>>> Number */
>>>   #define X86_FEATURE_INTEL_PT   ( 7*32+15) /* Intel Processor Trace */
>>> diff --git a/arch/x86/include/asm/msr-index.h
>>> b/arch/x86/include/asm/msr-index.h
>>> index 18b1623..460ac01 100644
>>> --- a/arch/x86/include/asm/msr-index.h
>>> +++ b/arch/x86/include/asm/msr-index.h
>>> @@ -352,6 +352,8 @@
>>>   #define MSR_K8_TOP_MEM10xc001001a
>>>   #define MSR_K8_TOP_MEM20xc001001d
>>>   #define MSR_K8_SYSCFG  0xc0010010
>>> +#define MSR_K8_SYSCFG_MEM_ENCRYPT_BIT  23
>>> +#define MSR_K8_SYSCFG_MEM_ENCRYPT
>>> BIT_ULL(MSR_K8_SYSCFG_MEM_ENCRYPT_BIT)
>>>   #define MSR_K8_INT_PENDING_MSG 0xc0010055
>>>   /* C1E active bits in int pending message */
>>>   #define K8_INTP_C1E_ACTIVE_MASK0x1800
>>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>>> index bb5abe8..c47ceee 100644
>>> --- a/arch/x86/kernel/cpu/amd.c
>>> +++ b/arch/x86/kernel/cpu/amd.c
>>> @@ -611,6 +611,19 @@ static void early_init_amd(struct cpuinfo_x86 *c)
>>>   */
>>>  if (cpu_has_amd_erratum(c, amd_erratum_400))
>>>  set_cpu_bug(c, X86_BUG_AMD_E400);
>>> +
>>> +   /*
>>> +* BIOS support is required for SME. If BIOS has not enabled SME
>>> +* then don't advertise the feature (set in scattered.c)
>>> +*/
>>> +   if (cpu_has(c, X86_FEATURE_SME)) {
>>> +   u64 msr;
>>> +
>>> +   /* Check if SME is enabled */
>>> +   rdmsrl(MSR_K8_SYSCFG, msr);
>>> +   if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
>>> +   clear_cpu_cap(c, X86_FEATURE_SME);
>>> +   }
>>
>>
>> This should be conditional on CONFIG_X86_64.
>
>
> If I make the scattered feature support conditional on CONFIG_X86_64
> (based on comment below) then cpu_has() will always be false unless
> CONFIG_X86_64 is enabled. So this won't need to be wrapped by the
> #ifdef.

If you change it to use cpu_feature_enabled(), gcc will see that it is
disabled and eliminate the dead code at compile time.

>>
>>>   }
>>>
>>>   static void init_amd_k8(struct cpuinfo_x86 *c)
>>> diff --git a/arch/x86/kernel/cpu/scattered.c
>>> b/arch/x86/kernel/cpu/scattered.c
>>> index 23c2350..05459ad 100644
>>> --- a/arch/x86/kernel/cpu/scattered.c
>>> +++ b/arch/x86/kernel/cpu/scattered.c
>>> @@ -31,6 +31,7 @@ struct cpuid_bit {
>>>  { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
>>>  { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
>>>  { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
>>> +   { X86_FEATURE_SME,  CPUID_EAX,  0, 0x801f, 0 },
>>
>>
>> This should also be conditional.  We don't want to set this feature on
>> 32-bit, even if the processor has support.
>
>
> Can do.  See comment above about re-spin vs. follow-on patch.
>
> Thanks,
> Tom

A followup patch will be OK if there is no code that will get confused
by the SME bit being present but not active.

--
Brian Gerst

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

[Brian Gerst]

On Mon, Jul 10, 2017 at 3:41 PM, Tom Lendacky  wrote:
> On 7/8/2017 7:50 AM, Brian Gerst wrote:
>>
>> On Fri, Jul 7, 2017 at 9:38 AM, Tom Lendacky 
>> wrote:
>>>
>>> Update the CPU features to include identifying and reporting on the
>>> Secure Memory Encryption (SME) feature.  SME is identified by CPUID
>>> 0x801f, but requires BIOS support to enable it (set bit 23 of
>>> MSR_K8_SYSCFG).  Only show the SME feature as available if reported by
>>> CPUID and enabled by BIOS.
>>>
>>> Reviewed-by: Borislav Petkov 
>>> Signed-off-by: Tom Lendacky 
>>> ---
>>>   arch/x86/include/asm/cpufeatures.h |1 +
>>>   arch/x86/include/asm/msr-index.h   |2 ++
>>>   arch/x86/kernel/cpu/amd.c  |   13 +
>>>   arch/x86/kernel/cpu/scattered.c|1 +
>>>   4 files changed, 17 insertions(+)
>>>
>>> diff --git a/arch/x86/include/asm/cpufeatures.h
>>> b/arch/x86/include/asm/cpufeatures.h
>>> index 2701e5f..2b692df 100644
>>> --- a/arch/x86/include/asm/cpufeatures.h
>>> +++ b/arch/x86/include/asm/cpufeatures.h
>>> @@ -196,6 +196,7 @@
>>>
>>>   #define X86_FEATURE_HW_PSTATE  ( 7*32+ 8) /* AMD HW-PState */
>>>   #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD
>>> ProcFeedbackInterface */
>>> +#define X86_FEATURE_SME( 7*32+10) /* AMD Secure Memory
>>> Encryption */
>>
>>
>> Given that this feature is available only in long mode, this should be
>> added to disabled-features.h as disabled for 32-bit builds.
>
>
> I can add that.  If the series needs a re-spin then I'll include this
> change in the series, otherwise I can send a follow-on patch to handle
> the feature for 32-bit builds if that works.
>
>
>>
>>>   #define X86_FEATURE_INTEL_PPIN ( 7*32+14) /* Intel Processor Inventory
>>> Number */
>>>   #define X86_FEATURE_INTEL_PT   ( 7*32+15) /* Intel Processor Trace */
>>> diff --git a/arch/x86/include/asm/msr-index.h
>>> b/arch/x86/include/asm/msr-index.h
>>> index 18b1623..460ac01 100644
>>> --- a/arch/x86/include/asm/msr-index.h
>>> +++ b/arch/x86/include/asm/msr-index.h
>>> @@ -352,6 +352,8 @@
>>>   #define MSR_K8_TOP_MEM10xc001001a
>>>   #define MSR_K8_TOP_MEM20xc001001d
>>>   #define MSR_K8_SYSCFG  0xc0010010
>>> +#define MSR_K8_SYSCFG_MEM_ENCRYPT_BIT  23
>>> +#define MSR_K8_SYSCFG_MEM_ENCRYPT
>>> BIT_ULL(MSR_K8_SYSCFG_MEM_ENCRYPT_BIT)
>>>   #define MSR_K8_INT_PENDING_MSG 0xc0010055
>>>   /* C1E active bits in int pending message */
>>>   #define K8_INTP_C1E_ACTIVE_MASK0x1800
>>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>>> index bb5abe8..c47ceee 100644
>>> --- a/arch/x86/kernel/cpu/amd.c
>>> +++ b/arch/x86/kernel/cpu/amd.c
>>> @@ -611,6 +611,19 @@ static void early_init_amd(struct cpuinfo_x86 *c)
>>>   */
>>>  if (cpu_has_amd_erratum(c, amd_erratum_400))
>>>  set_cpu_bug(c, X86_BUG_AMD_E400);
>>> +
>>> +   /*
>>> +* BIOS support is required for SME. If BIOS has not enabled SME
>>> +* then don't advertise the feature (set in scattered.c)
>>> +*/
>>> +   if (cpu_has(c, X86_FEATURE_SME)) {
>>> +   u64 msr;
>>> +
>>> +   /* Check if SME is enabled */
>>> +   rdmsrl(MSR_K8_SYSCFG, msr);
>>> +   if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
>>> +   clear_cpu_cap(c, X86_FEATURE_SME);
>>> +   }
>>
>>
>> This should be conditional on CONFIG_X86_64.
>
>
> If I make the scattered feature support conditional on CONFIG_X86_64
> (based on comment below) then cpu_has() will always be false unless
> CONFIG_X86_64 is enabled. So this won't need to be wrapped by the
> #ifdef.

If you change it to use cpu_feature_enabled(), gcc will see that it is
disabled and eliminate the dead code at compile time.

>>
>>>   }
>>>
>>>   static void init_amd_k8(struct cpuinfo_x86 *c)
>>> diff --git a/arch/x86/kernel/cpu/scattered.c
>>> b/arch/x86/kernel/cpu/scattered.c
>>> index 23c2350..05459ad 100644
>>> --- a/arch/x86/kernel/cpu/scattered.c
>>> +++ b/arch/x86/kernel/cpu/scattered.c
>>> @@ -31,6 +31,7 @@ struct cpuid_bit {
>>>  { X86_FEATURE_HW_PSTATE,CPUID_EDX,  7, 0x8007, 0 },
>>>  { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
>>>  { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
>>> +   { X86_FEATURE_SME,  CPUID_EAX,  0, 0x801f, 0 },
>>
>>
>> This should also be conditional.  We don't want to set this feature on
>> 32-bit, even if the processor has support.
>
>
> Can do.  See comment above about re-spin vs. follow-on patch.
>
> Thanks,
> Tom

A followup patch will be OK if there is no code that will get confused
by the SME bit being present but not active.

--
Brian Gerst

Re: sun4v+DMA related boot crash on 4.13-git

[Meelis Roos]

> > > I tested yesterdayd 4.12+git on sparc64 to see if the sparc merge works
> > > fine, and on all of my sun4v machines (T1000, T2000, T5120) it crashed
> > > on boot with DMA-related stacktrace (below). Allt he machines are sun4v
> > > physical machines, not VM-s. Older sun4 machines do not exhibit this
> > > problem.
> > >
> > > Maybae DMA APi realted, maybe sparc64. Will try to bisect when I get
> > > time.
> > I see whats going on with panic. I will reproduce locally. Will get back
> > soon.
> This patch should fix panic. Please give it a try.

Yes, this patch fixes it. Thank you for fixing it quickly!
> 
> commit b02c2b0bfd ("sparc: remove arch specific dma_supported
> implementations") introduced a code that incorrectly allow dma_supported() to
> succeed for 64bit dma mask even if system doesn't have ATU IOMMU. 64bit DMA
> only supported on sun4v equipped with ATU IOMMU HW.
> 
> diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c
> index 24f21c7..0a32c57 100644
> --- a/arch/sparc/kernel/pci_sun4v.c
> +++ b/arch/sparc/kernel/pci_sun4v.c
> @@ -673,12 +673,14 @@ static void dma_4v_unmap_sg(struct device *dev, struct
> scatterlist *sglist,
>  static int dma_4v_supported(struct device *dev, u64 device_mask)
>  {
> struct iommu *iommu = dev->archdata.iommu;
> -   u64 dma_addr_mask;
> +   u64 dma_addr_mask = iommu->dma_addr_mask;
> 
> -   if (device_mask > DMA_BIT_MASK(32) && iommu->atu)
> -   dma_addr_mask = iommu->atu->dma_addr_mask;
> -   else
> -   dma_addr_mask = iommu->dma_addr_mask;
> +   if (device_mask > DMA_BIT_MASK(32)) {
> +   if (iommu->atu)
> +   dma_addr_mask = iommu->atu->dma_addr_mask;
> +   else
> +   return 0;
> +   }
> 
> if ((device_mask & dma_addr_mask) == dma_addr_mask)
> return 1;
> 
> 
> -Tushar
> 
> 
> > 
> > -Tushar
> > >
> > >
> > > [0.24] PROMLIB: Sun IEEE Boot Prom 'OBP 4.30.4.d 2011/07/06 14:29'
> > > [0.33] PROMLIB: Root node compatible: sun4v
> > > [0.79] Linux version 4.12.0-08915-gf263fbb (mroos@t2000) (gcc
> > > version 4.9.2 (Debian 4.9.2-20)) #141 SMP Sun Jul 9 17:51:12 EEST 2017
> > > [0.002047] bootconsole [earlyprom0] enabled
> > > [0.002383] ARCH: SUN4V
> > > [0.002668] Ethernet address: 00:14:4f:86:99:26
> > > [0.003406] MM: PAGE_OFFSET is 0x8000 (max_phys_bits == 39)
> > > [0.004089] MM: VMALLOC [0x0001 --> 0x6000]
> > > [0.004562] MM: VMEMMAP [0x6000 --> 0xc000]
> > > [0.095699] Kernel: Using 3 locked TLB entries for main kernel image.
> > > [0.096387] Remapping the kernel...
> > > [0.096400] done.
> > > [1.906342] OF stdout device is: /virtual-devices@100/console@1
> > > [1.907160] PROM: Built device tree with 148821 bytes of memory.
> > > [1.907804] MDESC: Size is 42336 bytes.
> > > [1.910139] PLATFORM: banner-name [Sun Fire T200]
> > > [1.910564] PLATFORM: name [SUNW,Sun-Fire-T200]
> > > [1.910919] PLATFORM: hostid [84869926]
> > > [1.911224] PLATFORM: serial# [00ab4130]
> > > [1.911536] PLATFORM: stick-frequency [3b9aca00]
> > > [1.911894] PLATFORM: mac-address [144f869926]
> > > [1.912241] PLATFORM: watchdog-resolution [1000 ms]
> > > [1.912619] PLATFORM: watchdog-max-timeout [3153600 ms]
> > > [1.913042] PLATFORM: max-cpus [32]
> > > [1.913501] Top of RAM: 0x3ffd34000, Total RAM: 0x3f7918000
> > > [1.913936] Memory hole size: 132MB
> > > [2.279507] Allocated 16384 bytes for kernel page tables.
> > > [2.280578] Zone ranges:
> > > [2.280819]   Normal   [mem 0x0840-0x0003ffd33fff]
> > > [2.281292] Movable zone start for each node
> > > [2.281626] Early memory node ranges
> > > [2.281916]   node   0: [mem 0x0840-0x0003ffc1]
> > > [2.282557]   node   0: [mem 0x0003ffc28000-0x0003ffcfdfff]
> > > [2.283030]   node   0: [mem 0x0003ffd0e000-0x0003ffd27fff]
> > > [2.283514]   node   0: [mem 0x0003ffd2c000-0x0003ffd33fff]
> > > [2.283994] Initmem setup node 0 [mem
> > > 0x0840-0x0003ffd33fff]
> > > [2.782262] Booting Linux...
> > > [2.782734] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,mul32,div32]
> > > [2.783255] CPU CAPS: [v8plus,ASIBlkInit]
> > > [2.897543] percpu: Embedded 12 pages/cpu @8003ff80 s55872
> > > r8192 d34240 u262144
> > > [2.913264] SUN4V: Mondo queue sizes [cpu(4096) dev(16384) r(8192)
> > > nr(256)]
> > > [2.915492] Built 1 zonelists in Node order, mobility grouping on.
> > > Total pages: 2063634
> > > [2.916160] Policy zone: Normal
> > > [2.916420] Kernel command line: root=/dev/sda1 ro
> > > [2.918743] PID hash table entries: 4096 (order: 2, 32768 bytes)
> > > [2.919230] Sorting __ex_table...
> > > [3.220450] Memory: 16497120K/16639072K 

Re: sun4v+DMA related boot crash on 4.13-git

[Meelis Roos]

> > > I tested yesterdayd 4.12+git on sparc64 to see if the sparc merge works
> > > fine, and on all of my sun4v machines (T1000, T2000, T5120) it crashed
> > > on boot with DMA-related stacktrace (below). Allt he machines are sun4v
> > > physical machines, not VM-s. Older sun4 machines do not exhibit this
> > > problem.
> > >
> > > Maybae DMA APi realted, maybe sparc64. Will try to bisect when I get
> > > time.
> > I see whats going on with panic. I will reproduce locally. Will get back
> > soon.
> This patch should fix panic. Please give it a try.

Yes, this patch fixes it. Thank you for fixing it quickly!
> 
> commit b02c2b0bfd ("sparc: remove arch specific dma_supported
> implementations") introduced a code that incorrectly allow dma_supported() to
> succeed for 64bit dma mask even if system doesn't have ATU IOMMU. 64bit DMA
> only supported on sun4v equipped with ATU IOMMU HW.
> 
> diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c
> index 24f21c7..0a32c57 100644
> --- a/arch/sparc/kernel/pci_sun4v.c
> +++ b/arch/sparc/kernel/pci_sun4v.c
> @@ -673,12 +673,14 @@ static void dma_4v_unmap_sg(struct device *dev, struct
> scatterlist *sglist,
>  static int dma_4v_supported(struct device *dev, u64 device_mask)
>  {
> struct iommu *iommu = dev->archdata.iommu;
> -   u64 dma_addr_mask;
> +   u64 dma_addr_mask = iommu->dma_addr_mask;
> 
> -   if (device_mask > DMA_BIT_MASK(32) && iommu->atu)
> -   dma_addr_mask = iommu->atu->dma_addr_mask;
> -   else
> -   dma_addr_mask = iommu->dma_addr_mask;
> +   if (device_mask > DMA_BIT_MASK(32)) {
> +   if (iommu->atu)
> +   dma_addr_mask = iommu->atu->dma_addr_mask;
> +   else
> +   return 0;
> +   }
> 
> if ((device_mask & dma_addr_mask) == dma_addr_mask)
> return 1;
> 
> 
> -Tushar
> 
> 
> > 
> > -Tushar
> > >
> > >
> > > [0.24] PROMLIB: Sun IEEE Boot Prom 'OBP 4.30.4.d 2011/07/06 14:29'
> > > [0.33] PROMLIB: Root node compatible: sun4v
> > > [0.79] Linux version 4.12.0-08915-gf263fbb (mroos@t2000) (gcc
> > > version 4.9.2 (Debian 4.9.2-20)) #141 SMP Sun Jul 9 17:51:12 EEST 2017
> > > [0.002047] bootconsole [earlyprom0] enabled
> > > [0.002383] ARCH: SUN4V
> > > [0.002668] Ethernet address: 00:14:4f:86:99:26
> > > [0.003406] MM: PAGE_OFFSET is 0x8000 (max_phys_bits == 39)
> > > [0.004089] MM: VMALLOC [0x0001 --> 0x6000]
> > > [0.004562] MM: VMEMMAP [0x6000 --> 0xc000]
> > > [0.095699] Kernel: Using 3 locked TLB entries for main kernel image.
> > > [0.096387] Remapping the kernel...
> > > [0.096400] done.
> > > [1.906342] OF stdout device is: /virtual-devices@100/console@1
> > > [1.907160] PROM: Built device tree with 148821 bytes of memory.
> > > [1.907804] MDESC: Size is 42336 bytes.
> > > [1.910139] PLATFORM: banner-name [Sun Fire T200]
> > > [1.910564] PLATFORM: name [SUNW,Sun-Fire-T200]
> > > [1.910919] PLATFORM: hostid [84869926]
> > > [1.911224] PLATFORM: serial# [00ab4130]
> > > [1.911536] PLATFORM: stick-frequency [3b9aca00]
> > > [1.911894] PLATFORM: mac-address [144f869926]
> > > [1.912241] PLATFORM: watchdog-resolution [1000 ms]
> > > [1.912619] PLATFORM: watchdog-max-timeout [3153600 ms]
> > > [1.913042] PLATFORM: max-cpus [32]
> > > [1.913501] Top of RAM: 0x3ffd34000, Total RAM: 0x3f7918000
> > > [1.913936] Memory hole size: 132MB
> > > [2.279507] Allocated 16384 bytes for kernel page tables.
> > > [2.280578] Zone ranges:
> > > [2.280819]   Normal   [mem 0x0840-0x0003ffd33fff]
> > > [2.281292] Movable zone start for each node
> > > [2.281626] Early memory node ranges
> > > [2.281916]   node   0: [mem 0x0840-0x0003ffc1]
> > > [2.282557]   node   0: [mem 0x0003ffc28000-0x0003ffcfdfff]
> > > [2.283030]   node   0: [mem 0x0003ffd0e000-0x0003ffd27fff]
> > > [2.283514]   node   0: [mem 0x0003ffd2c000-0x0003ffd33fff]
> > > [2.283994] Initmem setup node 0 [mem
> > > 0x0840-0x0003ffd33fff]
> > > [2.782262] Booting Linux...
> > > [2.782734] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,mul32,div32]
> > > [2.783255] CPU CAPS: [v8plus,ASIBlkInit]
> > > [2.897543] percpu: Embedded 12 pages/cpu @8003ff80 s55872
> > > r8192 d34240 u262144
> > > [2.913264] SUN4V: Mondo queue sizes [cpu(4096) dev(16384) r(8192)
> > > nr(256)]
> > > [2.915492] Built 1 zonelists in Node order, mobility grouping on.
> > > Total pages: 2063634
> > > [2.916160] Policy zone: Normal
> > > [2.916420] Kernel command line: root=/dev/sda1 ro
> > > [2.918743] PID hash table entries: 4096 (order: 2, 32768 bytes)
> > > [2.919230] Sorting __ex_table...
> > > [3.220450] Memory: 16497120K/16639072K 

Re: [PATCH 5/5] powernv:idle: Disable LOSE_FULL_CONTEXT states when stop-api fails.

[Gautham R Shenoy]

On Sat, Jul 08, 2017 at 07:05:26PM +1000, Nicholas Piggin wrote:
> On Fri, 7 Jul 2017 23:07:10 +0530
> Gautham R Shenoy  wrote:
> 
> > On Fri, Jul 07, 2017 at 01:29:16AM +1000, Nicholas Piggin wrote:
> > > On Wed,  5 Jul 2017 22:08:16 +0530
> > > "Gautham R. Shenoy"  wrote:
> > >   
> > > > From: "Gautham R. Shenoy" 
> > > > 
> > > > Currently, we use the opal call opal_slw_set_reg() to inform the that
> > > > the Sleep-Winkle Engine (SLW) to restore the contents of some of the
> > > > Hypervisor state on wakeup from deep idle states that lose full
> > > > hypervisor context (characterized by the flag
> > > > OPAL_PM_LOSE_FULL_CONTEXT).
> > > > 
> > > > However, the current code has a bug in that if opal_slw_set_reg()
> > > > fails, we don't disable the use of these deep states (winkle on
> > > > POWER8, stop4 onwards on POWER9).
> > > > 
> > > > This patch fixes this bug by ensuring that if the the sleep winkle
> > > > engine is unable to restore the hypervisor states in
> > > > pnv_save_sprs_for_deep_states(), then we mark as invalid the states
> > > > which lose full context.
> > > > 
> > > > As a side-effect, since supported_cpuidle_states in
> > > > pnv_probe_idle_states() consists of flags of only the valid states,
> > > > this patch will ensure that no other subsystem in the kernel can use
> > > > the states which lose full context on stop-api failures.  
> > > 
> > > Looks good. Is there something minimal we can do for stable here?
> > > 
> > > Aside question, do we need to restore LPCR at all with the SLW engine?
> > > It gets set up again when by the idle wakeup code.  
> > 
> > 
> > > 
> > > And does POWER9 really need MSR and PSSCR restored by SLW? (going a bit
> > > off topic here, I'm just curious)  
> > 
> > MSR is needed to be restored so that we wakeup with the right
> > endianness and with the IR,DR disabled.
> 
> And POWER8 does not require this?
> 
> > PSSCR is set to a value so that in case of a special wakeup for a
> > deep-stop, the SLW can program the core to go back to the stop level
> > provided by the PSSCR value via the stop-api.
> 
> It always restores to deepest stop? Is there any way to restore to the
> achieved stop level? Maybe there is no usefulness for that.

That would have been ideal. But there's no way to achieve that at the
moment. The alternative is to have call the stop-api with psscr set to
the desired stop level before every stop entry. This is will consume
additional cycles which is what we are trying to avoid.

So we are currently setting the psscr value to deepest stop via stop
api as a compromise, because then on wakeup, we end up restoring more
than what would typically be required, but that's still ok since we
would be erring on the side of caution.

Programming the PSSCR to any other value might have safety
concerns. Eg: Suppose a core which was in stop11 got woken up by a
special wakeup and if the psscr programmed via stop API was stop4 then
the firmware will put the core in stop4. Now, since stop4 doesn't lose
timebase and stop11 does, in the aforementioned case TB would have
gone out of sync in the duration that the core was in stop11. Thus,
when the core wakes up in the kernel in stop4, the kernel won't resync
the TB which is a problematic.

> 
> Thanks,
> Nick
> 

Re: [PATCH 5/5] powernv:idle: Disable LOSE_FULL_CONTEXT states when stop-api fails.

[Gautham R Shenoy]

On Sat, Jul 08, 2017 at 07:05:26PM +1000, Nicholas Piggin wrote:
> On Fri, 7 Jul 2017 23:07:10 +0530
> Gautham R Shenoy  wrote:
> 
> > On Fri, Jul 07, 2017 at 01:29:16AM +1000, Nicholas Piggin wrote:
> > > On Wed,  5 Jul 2017 22:08:16 +0530
> > > "Gautham R. Shenoy"  wrote:
> > >   
> > > > From: "Gautham R. Shenoy" 
> > > > 
> > > > Currently, we use the opal call opal_slw_set_reg() to inform the that
> > > > the Sleep-Winkle Engine (SLW) to restore the contents of some of the
> > > > Hypervisor state on wakeup from deep idle states that lose full
> > > > hypervisor context (characterized by the flag
> > > > OPAL_PM_LOSE_FULL_CONTEXT).
> > > > 
> > > > However, the current code has a bug in that if opal_slw_set_reg()
> > > > fails, we don't disable the use of these deep states (winkle on
> > > > POWER8, stop4 onwards on POWER9).
> > > > 
> > > > This patch fixes this bug by ensuring that if the the sleep winkle
> > > > engine is unable to restore the hypervisor states in
> > > > pnv_save_sprs_for_deep_states(), then we mark as invalid the states
> > > > which lose full context.
> > > > 
> > > > As a side-effect, since supported_cpuidle_states in
> > > > pnv_probe_idle_states() consists of flags of only the valid states,
> > > > this patch will ensure that no other subsystem in the kernel can use
> > > > the states which lose full context on stop-api failures.  
> > > 
> > > Looks good. Is there something minimal we can do for stable here?
> > > 
> > > Aside question, do we need to restore LPCR at all with the SLW engine?
> > > It gets set up again when by the idle wakeup code.  
> > 
> > 
> > > 
> > > And does POWER9 really need MSR and PSSCR restored by SLW? (going a bit
> > > off topic here, I'm just curious)  
> > 
> > MSR is needed to be restored so that we wakeup with the right
> > endianness and with the IR,DR disabled.
> 
> And POWER8 does not require this?
> 
> > PSSCR is set to a value so that in case of a special wakeup for a
> > deep-stop, the SLW can program the core to go back to the stop level
> > provided by the PSSCR value via the stop-api.
> 
> It always restores to deepest stop? Is there any way to restore to the
> achieved stop level? Maybe there is no usefulness for that.

That would have been ideal. But there's no way to achieve that at the
moment. The alternative is to have call the stop-api with psscr set to
the desired stop level before every stop entry. This is will consume
additional cycles which is what we are trying to avoid.

So we are currently setting the psscr value to deepest stop via stop
api as a compromise, because then on wakeup, we end up restoring more
than what would typically be required, but that's still ok since we
would be erring on the side of caution.

Programming the PSSCR to any other value might have safety
concerns. Eg: Suppose a core which was in stop11 got woken up by a
special wakeup and if the psscr programmed via stop API was stop4 then
the firmware will put the core in stop4. Now, since stop4 doesn't lose
timebase and stop11 does, in the aforementioned case TB would have
gone out of sync in the duration that the core was in stop11. Thus,
when the core wakes up in the kernel in stop4, the kernel won't resync
the TB which is a problematic.

> 
> Thanks,
> Nick
> 

Re: [PATCH v2 3/4] btrfs: Add zstd support

[Nick Terrell]

On 7/10/17, 5:36 AM, "Austin S. Hemmelgarn"  wrote:
> On 2017-07-07 23:07, Adam Borowski wrote:
>> On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote:
>>> On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote:
 On 7/6/17, 9:32 AM, "Adam Borowski"  wrote:
> Got a reproducible crash on amd64:
>>>
 Thanks for the bug report Adam! I'm looking into the failure, and haven't
 been able to reproduce it yet. I've built my kernel from your tree, and
 I ran your script with the kernel.tar tarball 100 times, but haven't gotten
 a failure yet.
>>>
 I have a few questions to guide my debugging.

 - How many cores are you running with? I’ve run the script with 1, 2, and 
 4 cores.
 - Which version of gcc are you using to compile the kernel? I’m using 
 gcc-6.2.0-5ubuntu12.
 - Are the failures always in exactly the same place, and does it fail 100%
of the time or just regularly?
>>>
>>> 6 cores -- all on bare metal.  gcc-7.1.0-9.
>>> Lemme try with gcc-6, a different config or in a VM.
>>
>> I've tried the following:
>> * gcc-6, defconfig (+btrfs obviously)
>> * gcc-7, defconfig
>> * gcc-6, my regular config
>> * gcc-7, my regular config
>> * gcc-7, debug + UBSAN + etc
>> * gcc-7, defconfig, qemu-kvm with only 1 core
>>
>> Every build with gcc-7 reproduces the crash, every with gcc-6 does not.
>>
> Got a GCC7 tool-chain built, and I can confirm this here too, tested 
> with various numbers of cores ranging from 1-32 in a QEMU+KVM VM, with 
> various combinations of debug options and other config switches.

The problem is caused by a gcc-7 bug [1]. It miscompiles
ZSTD_wildcopy(void *dst, void const *src, ptrdiff_t len) when len is 0.
It only happens when it can't analyze ZSTD_copy8(), which is the case in
the kernel, because memcpy() is implemented with inline assembly. The
generated code is slow anyways, so I propose this workaround, which will
be included in the next patch set. I've confirmed that it fixes the bug for
me. This alternative implementation is also 10-20x faster, and compiles to
the same x86 assembly as the original ZSTD_wildcopy() with the userland
memcpy() implementation [2].

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81388#add_comment
[2] https://godbolt.org/g/q5YpLx

Signed-off-by: Nick Terrell 
---
 lib/zstd/zstd_internal.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/zstd/zstd_internal.h b/lib/zstd/zstd_internal.h
index 6748719..ade0365 100644
--- a/lib/zstd/zstd_internal.h
+++ b/lib/zstd/zstd_internal.h
@@ -126,7 +126,9 @@ static const U32 OF_defaultNormLog = OF_DEFAULTNORMLOG;
 /*-***
 *  Shared functions to include for inlining
 */
-static void ZSTD_copy8(void *dst, const void *src) { memcpy(dst, src, 8); }
+static void ZSTD_copy8(void *dst, const void *src) {
+   ZSTD_write64(dst, ZSTD_read64(src));
+}
 #define COPY8(d, s)   \
{ \
ZSTD_copy8(d, s); \
--
2.9.3

Re: [PATCH v2 3/4] btrfs: Add zstd support

[Nick Terrell]

On 7/10/17, 5:36 AM, "Austin S. Hemmelgarn"  wrote:
> On 2017-07-07 23:07, Adam Borowski wrote:
>> On Sat, Jul 08, 2017 at 01:40:18AM +0200, Adam Borowski wrote:
>>> On Fri, Jul 07, 2017 at 11:17:49PM +, Nick Terrell wrote:
 On 7/6/17, 9:32 AM, "Adam Borowski"  wrote:
> Got a reproducible crash on amd64:
>>>
 Thanks for the bug report Adam! I'm looking into the failure, and haven't
 been able to reproduce it yet. I've built my kernel from your tree, and
 I ran your script with the kernel.tar tarball 100 times, but haven't gotten
 a failure yet.
>>>
 I have a few questions to guide my debugging.

 - How many cores are you running with? I’ve run the script with 1, 2, and 
 4 cores.
 - Which version of gcc are you using to compile the kernel? I’m using 
 gcc-6.2.0-5ubuntu12.
 - Are the failures always in exactly the same place, and does it fail 100%
of the time or just regularly?
>>>
>>> 6 cores -- all on bare metal.  gcc-7.1.0-9.
>>> Lemme try with gcc-6, a different config or in a VM.
>>
>> I've tried the following:
>> * gcc-6, defconfig (+btrfs obviously)
>> * gcc-7, defconfig
>> * gcc-6, my regular config
>> * gcc-7, my regular config
>> * gcc-7, debug + UBSAN + etc
>> * gcc-7, defconfig, qemu-kvm with only 1 core
>>
>> Every build with gcc-7 reproduces the crash, every with gcc-6 does not.
>>
> Got a GCC7 tool-chain built, and I can confirm this here too, tested 
> with various numbers of cores ranging from 1-32 in a QEMU+KVM VM, with 
> various combinations of debug options and other config switches.

The problem is caused by a gcc-7 bug [1]. It miscompiles
ZSTD_wildcopy(void *dst, void const *src, ptrdiff_t len) when len is 0.
It only happens when it can't analyze ZSTD_copy8(), which is the case in
the kernel, because memcpy() is implemented with inline assembly. The
generated code is slow anyways, so I propose this workaround, which will
be included in the next patch set. I've confirmed that it fixes the bug for
me. This alternative implementation is also 10-20x faster, and compiles to
the same x86 assembly as the original ZSTD_wildcopy() with the userland
memcpy() implementation [2].

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81388#add_comment
[2] https://godbolt.org/g/q5YpLx

Signed-off-by: Nick Terrell 
---
 lib/zstd/zstd_internal.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/zstd/zstd_internal.h b/lib/zstd/zstd_internal.h
index 6748719..ade0365 100644
--- a/lib/zstd/zstd_internal.h
+++ b/lib/zstd/zstd_internal.h
@@ -126,7 +126,9 @@ static const U32 OF_defaultNormLog = OF_DEFAULTNORMLOG;
 /*-***
 *  Shared functions to include for inlining
 */
-static void ZSTD_copy8(void *dst, const void *src) { memcpy(dst, src, 8); }
+static void ZSTD_copy8(void *dst, const void *src) {
+   ZSTD_write64(dst, ZSTD_read64(src));
+}
 #define COPY8(d, s)   \
{ \
ZSTD_copy8(d, s); \
--
2.9.3

Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

[Brian Gerst]

On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky  wrote:
> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>
>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky 
>> wrote:
>>>
>>> Currently there is a check if the address being mapped is in the ISA
>>> range (is_ISA_range()), and if it is, then phys_to_virt() is used to
>>> perform the mapping. When SME is active, the default is to add pagetable
>>> mappings with the encryption bit set unless specifically overridden. The
>>> resulting pagetable mapping from phys_to_virt() will result in a mapping
>>> that has the encryption bit set. With SME, the use of ioremap() is
>>> intended to generate pagetable mappings that do not have the encryption
>>> bit set through the use of the PAGE_KERNEL_IO protection value.
>>>
>>> Rather than special case the SME scenario, remove the ISA range check and
>>> usage of phys_to_virt() and have ISA range mappings continue through the
>>> remaining ioremap() path.
>>>
>>> Signed-off-by: Tom Lendacky 
>>> ---
>>>   arch/x86/mm/ioremap.c |7 +--
>>>   1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>>> index 4c1b5fd..bfc3e2d 100644
>>> --- a/arch/x86/mm/ioremap.c
>>> +++ b/arch/x86/mm/ioremap.c
>>> @@ -13,6 +13,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>
>>>   #include 
>>>   #include 
>>> @@ -106,12 +107,6 @@ static void __iomem
>>> *__ioremap_caller(resource_size_t phys_addr,
>>>  }
>>>
>>>  /*
>>> -* Don't remap the low PCI/ISA area, it's always mapped..
>>> -*/
>>> -   if (is_ISA_range(phys_addr, last_addr))
>>> -   return (__force void __iomem *)phys_to_virt(phys_addr);
>>> -
>>> -   /*
>>>   * Don't allow anybody to remap normal RAM that we're using..
>>>   */
>>>  pfn  = phys_addr >> PAGE_SHIFT;
>>>
>>
>> Removing this also affects 32-bit, which is more likely to access
>> legacy devices in this range.  Put in a check for SME instead
>
>
> I originally had a check for SME here in a previous version of the
> patch.  Thomas Gleixner recommended removing the check so that the code
> path was always exercised regardless of the state of SME in order to
> better detect issues:
>
> http://marc.info/?l=linux-kernel=149803067811436=2
>
> Thanks,
> Tom

Looking a bit closer, this shortcut doesn't set the caching
attributes.  So it's probably best to get rid of it anyways.  Also
note, there is a corresponding check in iounmap().

--
Brian Gerst

Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

[Brian Gerst]

On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky  wrote:
> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>
>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky 
>> wrote:
>>>
>>> Currently there is a check if the address being mapped is in the ISA
>>> range (is_ISA_range()), and if it is, then phys_to_virt() is used to
>>> perform the mapping. When SME is active, the default is to add pagetable
>>> mappings with the encryption bit set unless specifically overridden. The
>>> resulting pagetable mapping from phys_to_virt() will result in a mapping
>>> that has the encryption bit set. With SME, the use of ioremap() is
>>> intended to generate pagetable mappings that do not have the encryption
>>> bit set through the use of the PAGE_KERNEL_IO protection value.
>>>
>>> Rather than special case the SME scenario, remove the ISA range check and
>>> usage of phys_to_virt() and have ISA range mappings continue through the
>>> remaining ioremap() path.
>>>
>>> Signed-off-by: Tom Lendacky 
>>> ---
>>>   arch/x86/mm/ioremap.c |7 +--
>>>   1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>>> index 4c1b5fd..bfc3e2d 100644
>>> --- a/arch/x86/mm/ioremap.c
>>> +++ b/arch/x86/mm/ioremap.c
>>> @@ -13,6 +13,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>
>>>   #include 
>>>   #include 
>>> @@ -106,12 +107,6 @@ static void __iomem
>>> *__ioremap_caller(resource_size_t phys_addr,
>>>  }
>>>
>>>  /*
>>> -* Don't remap the low PCI/ISA area, it's always mapped..
>>> -*/
>>> -   if (is_ISA_range(phys_addr, last_addr))
>>> -   return (__force void __iomem *)phys_to_virt(phys_addr);
>>> -
>>> -   /*
>>>   * Don't allow anybody to remap normal RAM that we're using..
>>>   */
>>>  pfn  = phys_addr >> PAGE_SHIFT;
>>>
>>
>> Removing this also affects 32-bit, which is more likely to access
>> legacy devices in this range.  Put in a check for SME instead
>
>
> I originally had a check for SME here in a previous version of the
> patch.  Thomas Gleixner recommended removing the check so that the code
> path was always exercised regardless of the state of SME in order to
> better detect issues:
>
> http://marc.info/?l=linux-kernel=149803067811436=2
>
> Thanks,
> Tom

Looking a bit closer, this shortcut doesn't set the caching
attributes.  So it's probably best to get rid of it anyways.  Also
note, there is a corresponding check in iounmap().

--
Brian Gerst

linux-next: Tree for Jul 11

[Stephen Rothwell]

Hi all,

Please do not add any v4.14 material to you linux-next included branches
until after v4.13-rc1 has been released.

Changes since 20170710:

The mips tree gained a conflict against Linus' tree.

The vfs tree lost its build failures but gained another for which I
applied a fix patch.

The spi tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1391
 1300 files changed, 50703 insertions(+), 19744 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (548aa0e3c516 Merge tag 'devprop-4.13-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (11352460b8dc ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d6bd8194e286 powerpc/32: Avoid miscompilation 
w/GCC 4.6.3 - don't inline copy_to/from_user())
Merging sparc/master (dbd2667a4fb9 sparc64: Fix gup_huge_pmd)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (de92cd6cf489 net/mlx5: IPSec, fix 64-bit division correctly)
Merging ipsec/master (ca3a1b856636 esp6_offload: Fix IP6CB(skb)->nhoff for ESP 
GRO)
Merging netfilter/master (c644bd79c0a7 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (85dc0f8554fa ALSA: pcm: Simplify check for 
dma_mmap_coherent() availability)
Merging pci-current/for-linus (f01fc4177352 ARM/PCI: Fix 
pcibios_init_resource() struct pci_host_bridge leak)
Merging driver-core.current/driver-core-linus (650fc870a2ef Merge tag 
'docs-4.13' of git://git.lwn.net/linux)
Merging tty.current/tty-linus (650fc870a2ef Merge tag 'docs-4.13' of 
git://git.lwn.net/linux)
Merging usb.current/usb-linus (cee37d83e6d9 Merge branch 'work.read_write' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (af3c8d98508d Merge tag 'drm-for-v4.13' 
of git://people.freedesktop.org/~airlied/linux)
Merging char-misc.current/char-misc-linus (650fc870a2ef Merge 

linux-next: Tree for Jul 11

[Stephen Rothwell]

Hi all,

Please do not add any v4.14 material to you linux-next included branches
until after v4.13-rc1 has been released.

Changes since 20170710:

The mips tree gained a conflict against Linus' tree.

The vfs tree lost its build failures but gained another for which I
applied a fix patch.

The spi tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1391
 1300 files changed, 50703 insertions(+), 19744 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 266 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (548aa0e3c516 Merge tag 'devprop-4.13-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (11352460b8dc ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (9e25ebfe56ec ARM: 8685/1: ensure memblock-limit is 
pmd-aligned)
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (d6bd8194e286 powerpc/32: Avoid miscompilation 
w/GCC 4.6.3 - don't inline copy_to/from_user())
Merging sparc/master (dbd2667a4fb9 sparc64: Fix gup_huge_pmd)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (de92cd6cf489 net/mlx5: IPSec, fix 64-bit division correctly)
Merging ipsec/master (ca3a1b856636 esp6_offload: Fix IP6CB(skb)->nhoff for ESP 
GRO)
Merging netfilter/master (c644bd79c0a7 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (35abcd4f9f30 brcmfmac: fix uninitialized 
warning in brcmf_usb_probe_phase2())
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (85dc0f8554fa ALSA: pcm: Simplify check for 
dma_mmap_coherent() availability)
Merging pci-current/for-linus (f01fc4177352 ARM/PCI: Fix 
pcibios_init_resource() struct pci_host_bridge leak)
Merging driver-core.current/driver-core-linus (650fc870a2ef Merge tag 
'docs-4.13' of git://git.lwn.net/linux)
Merging tty.current/tty-linus (650fc870a2ef Merge tag 'docs-4.13' of 
git://git.lwn.net/linux)
Merging usb.current/usb-linus (cee37d83e6d9 Merge branch 'work.read_write' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging usb-gadget-fixes/fixes (f50b878fed33 USB: gadget: fix GPF in gadgetfs)
Merging usb-serial-fixes/usb-linus (996fab55d864 USB: serial: qcserial: new 
Sierra Wireless EM7305 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (9605bc46433d phy: qualcomm: phy-qcom-qmp: fix application of 
sizeof to pointer)
Merging staging.current/staging-linus (af3c8d98508d Merge tag 'drm-for-v4.13' 
of git://people.freedesktop.org/~airlied/linux)
Merging char-misc.current/char-misc-linus (650fc870a2ef Merge 

Re: [PATCH v2 1/3] of: overlay: add overlay unittest data for node names and symbols

[Frank Rowand]

On 07/10/17 19:31, Rob Herring wrote:
> On Mon, Jul 10, 2017 at 2:05 PM,   wrote:
>> From: Frank Rowand 
>>
>> Add nodes and properties to overlay_base and overlay dts files to
>> test for
>>- incorrect existing node name detection when overlay node name
>>  has a unit-address
>>- adding overlay __symbols__ properties to live tree when an
>>  overlay is added to the live tree
>>
>> Expected result from patch 2/3 is overlay will update the nodes and
>> properties for /testcase-data-2/fairway-1/ride@100/
>>
>> Before patch 2/3 is applied:
> 
> This is good information, but what is patch 2/3 is less clear when
> this is committed.

Yes, but that is the best way I've figured out to convey the information.
I'm expecting the three patches to be three consecutive commits in the
history.  I'd love to have a way to specify what the commit id of
patch 3 will be in the patch 1 commit message.  Given the way that
I think git works, I don't think there is any way the git wizards
will be able to add that feature.  Maybe it would be clearer to
reference the short description of patch 2 and patch 3 instead.


> And 1 and 2 are probably stable material? I'd just
> note in this patch what the failures are and show before and after
> results in the patch that changes them.

I consider overlays to be a not yet functional feature, that
still needs a some more code before being usable. In that case,
I don't think it is worth marking the patches for stable.


>>Console error message near end of unittest:
>>   OF: Duplicate name in fairway-1, renamed to "ride@100#1"
>>
>>$ cd /proc/device-tree/testcase-data-2/fairway-1/
>>$ # extra node: ride@100#1
>>$ ls
>>#address-cells  linux,phandle   phandle ride@200
>>#size-cells nameride@100status
>>compatible  orientation ride@100#1
>>$ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/
>>$ ls track@3/incline_up
>>ls: track@3/incline_up: No such file or directory
>>$ ls track@4/incline_up
>>ls: track@4/incline_up: No such file or directory
> 
> [...]
> 
>> diff --git a/drivers/of/unittest-data/Makefile 
>> b/drivers/of/unittest-data/Makefile
>> index 6e00a9c69e58..dae2fe23cd2e 100644
>> --- a/drivers/of/unittest-data/Makefile
>> +++ b/drivers/of/unittest-data/Makefile
>> @@ -1,11 +1,13 @@
>>  obj-y += testcases.dtb.o
>>  obj-y += overlay.dtb.o
>>  obj-y += overlay_bad_phandle.dtb.o
>> +obj-y += overlay_bad_symbol.dtb.o
>>  obj-y += overlay_base.dtb.o
> 
> There's no reason for these all to be 1 per line.

OK.  Do you prefer something like:

   obj-y += testcases.dtb.o overlay.dtb.o overlay_bad_phandle.dtb.o \
overlay_bad_symbol.dtb.o overlay_base.dtb.o

My preference is to keep the objects in alphabetic order.  That might
argue for something easier to read and update, like:

   obj-y += testcases.dtb.o \
overlay.dtb.o \
overlay_bad_phandle.dtb.o \
overlay_bad_symbol.dtb.o \
overlay_base.dtb.o


> Also, should the
> overlay dtb's be conditioned on CONFIG_OF_OVERLAY (or whatever we call
> it)?

I think so.  I'll verify that it doesn't break anything (and if so fix
the breakage).


> 
> But this is fine. That can all be a followup patch.
> 

Re: [PATCH v2 1/3] of: overlay: add overlay unittest data for node names and symbols

[Frank Rowand]

On 07/10/17 19:31, Rob Herring wrote:
> On Mon, Jul 10, 2017 at 2:05 PM,   wrote:
>> From: Frank Rowand 
>>
>> Add nodes and properties to overlay_base and overlay dts files to
>> test for
>>- incorrect existing node name detection when overlay node name
>>  has a unit-address
>>- adding overlay __symbols__ properties to live tree when an
>>  overlay is added to the live tree
>>
>> Expected result from patch 2/3 is overlay will update the nodes and
>> properties for /testcase-data-2/fairway-1/ride@100/
>>
>> Before patch 2/3 is applied:
> 
> This is good information, but what is patch 2/3 is less clear when
> this is committed.

Yes, but that is the best way I've figured out to convey the information.
I'm expecting the three patches to be three consecutive commits in the
history.  I'd love to have a way to specify what the commit id of
patch 3 will be in the patch 1 commit message.  Given the way that
I think git works, I don't think there is any way the git wizards
will be able to add that feature.  Maybe it would be clearer to
reference the short description of patch 2 and patch 3 instead.


> And 1 and 2 are probably stable material? I'd just
> note in this patch what the failures are and show before and after
> results in the patch that changes them.

I consider overlays to be a not yet functional feature, that
still needs a some more code before being usable. In that case,
I don't think it is worth marking the patches for stable.


>>Console error message near end of unittest:
>>   OF: Duplicate name in fairway-1, renamed to "ride@100#1"
>>
>>$ cd /proc/device-tree/testcase-data-2/fairway-1/
>>$ # extra node: ride@100#1
>>$ ls
>>#address-cells  linux,phandle   phandle ride@200
>>#size-cells nameride@100status
>>compatible  orientation ride@100#1
>>$ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/
>>$ ls track@3/incline_up
>>ls: track@3/incline_up: No such file or directory
>>$ ls track@4/incline_up
>>ls: track@4/incline_up: No such file or directory
> 
> [...]
> 
>> diff --git a/drivers/of/unittest-data/Makefile 
>> b/drivers/of/unittest-data/Makefile
>> index 6e00a9c69e58..dae2fe23cd2e 100644
>> --- a/drivers/of/unittest-data/Makefile
>> +++ b/drivers/of/unittest-data/Makefile
>> @@ -1,11 +1,13 @@
>>  obj-y += testcases.dtb.o
>>  obj-y += overlay.dtb.o
>>  obj-y += overlay_bad_phandle.dtb.o
>> +obj-y += overlay_bad_symbol.dtb.o
>>  obj-y += overlay_base.dtb.o
> 
> There's no reason for these all to be 1 per line.

OK.  Do you prefer something like:

   obj-y += testcases.dtb.o overlay.dtb.o overlay_bad_phandle.dtb.o \
overlay_bad_symbol.dtb.o overlay_base.dtb.o

My preference is to keep the objects in alphabetic order.  That might
argue for something easier to read and update, like:

   obj-y += testcases.dtb.o \
overlay.dtb.o \
overlay_bad_phandle.dtb.o \
overlay_bad_symbol.dtb.o \
overlay_base.dtb.o


> Also, should the
> overlay dtb's be conditioned on CONFIG_OF_OVERLAY (or whatever we call
> it)?

I think so.  I'll verify that it doesn't break anything (and if so fix
the breakage).


> 
> But this is fine. That can all be a followup patch.
> 

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Li, Aubrey]

On 2017/7/11 1:27, Andi Kleen wrote:
> On Mon, Jul 10, 2017 at 06:42:06PM +0200, Peter Zijlstra wrote:
>> On Mon, Jul 10, 2017 at 07:46:09AM -0700, Andi Kleen wrote:
 So how much of the gain is simply due to skipping NOHZ? Mike used to
 carry a patch that would throttle NOHZ. And that is a _far_ smaller and
 simpler patch to do.
>>>
>>> Have you ever looked at a ftrace or PT trace of the idle entry?
>>>
>>> There's just too much stuff going on there. NOHZ is just the tip
>>> of the iceberg.
>>
>> I have, and last time I did the actual poking at the LAPIC (to make NOHZ
>> happen) was by far the slowest thing happening.
> 
> That must have been a long time ago because modern systems use TSC deadline
> for a very long time ...  
> 
> It's still slow, but not as slow as the LAPIC.
> 
>> Data to indicate what hurts how much would be a very good addition to
>> the Changelogs. Clearly you have some, you really should have shared.
>
Here is an article indicates why we need to improve this:
https://cacm.acm.org/magazines/2017/4/215032-attack-of-the-killer-microseconds/fulltext

Given that we have a few new low-latency I/O devices like Xpoint 3D memory,
25/40GB Ethernet, etc, this proposal targets to improve the latency of
microsecond(us)-scale events as well.

Basically we are looking at how much we can improve(instead of what hurts),
the data is against v4.8.8.

In the idle loop,

- quiet_vmstat costs 5562ns - 6296ns
- tick_nohz_idle_enter costs 7058ns - 10726ns
- totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return costs
  9122ns - 15318ns.
  --In this period, rcu_idle_enter costs 1985ns - 2262ns, rcu_idle_exit costs
1813ns - 3507ns
- tick_nohz_idle_exit costs 8372ns - 20850ns

Benchmark fio on a NVMe disk shows 3-4% improvement due to skipping nohz, extra
1-2% improvement overall

Benchmark netperf loopback in TCP Request-Response mode shows 6-7% improvement
due to skipping nohz, extra 2-3% improvement overall

Note, the data includes measurement overhead, and it could be varied on the 
different platforms, different CPU frequency, and different workload, but they
are consistent once the testing configuration is fixed.

Thanks,
-Aubrey

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Li, Aubrey]

On 2017/7/11 1:27, Andi Kleen wrote:
> On Mon, Jul 10, 2017 at 06:42:06PM +0200, Peter Zijlstra wrote:
>> On Mon, Jul 10, 2017 at 07:46:09AM -0700, Andi Kleen wrote:
 So how much of the gain is simply due to skipping NOHZ? Mike used to
 carry a patch that would throttle NOHZ. And that is a _far_ smaller and
 simpler patch to do.
>>>
>>> Have you ever looked at a ftrace or PT trace of the idle entry?
>>>
>>> There's just too much stuff going on there. NOHZ is just the tip
>>> of the iceberg.
>>
>> I have, and last time I did the actual poking at the LAPIC (to make NOHZ
>> happen) was by far the slowest thing happening.
> 
> That must have been a long time ago because modern systems use TSC deadline
> for a very long time ...  
> 
> It's still slow, but not as slow as the LAPIC.
> 
>> Data to indicate what hurts how much would be a very good addition to
>> the Changelogs. Clearly you have some, you really should have shared.
>
Here is an article indicates why we need to improve this:
https://cacm.acm.org/magazines/2017/4/215032-attack-of-the-killer-microseconds/fulltext

Given that we have a few new low-latency I/O devices like Xpoint 3D memory,
25/40GB Ethernet, etc, this proposal targets to improve the latency of
microsecond(us)-scale events as well.

Basically we are looking at how much we can improve(instead of what hurts),
the data is against v4.8.8.

In the idle loop,

- quiet_vmstat costs 5562ns - 6296ns
- tick_nohz_idle_enter costs 7058ns - 10726ns
- totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return costs
  9122ns - 15318ns.
  --In this period, rcu_idle_enter costs 1985ns - 2262ns, rcu_idle_exit costs
1813ns - 3507ns
- tick_nohz_idle_exit costs 8372ns - 20850ns

Benchmark fio on a NVMe disk shows 3-4% improvement due to skipping nohz, extra
1-2% improvement overall

Benchmark netperf loopback in TCP Request-Response mode shows 6-7% improvement
due to skipping nohz, extra 2-3% improvement overall

Note, the data includes measurement overhead, and it could be varied on the 
different platforms, different CPU frequency, and different workload, but they
are consistent once the testing configuration is fixed.

Thanks,
-Aubrey

Re: [RFC] mm/mremap: Remove redundant checks inside vma_expandable()

[Anshuman Khandual]

On 07/10/2017 07:19 PM, Michal Hocko wrote:
> On Mon 10-07-17 16:40:59, Anshuman Khandual wrote:
>> As 'delta' is an unsigned long, 'end' (vma->vm_end + delta) cannot
>> be less than 'vma->vm_end'.
> 
> This just doesn't make any sense. This is exactly what the overflow
> check is for. Maybe vm_end + delta can never overflow because of
> (old_len == vma->vm_end - addr) and guarantee old_len < new_len
> in mremap but I haven't checked that too deeply.

Irrespective of that, just looking at the variables inside this
particular function where delta is an 'unsigned long', 'end' cannot
be less than vma->vm_end. Is not that true ?

> 
>> Checking for availability of virtual
>> address range at the end of the VMA for the incremental size is
>> also reduntant at this point. Hence drop them both.
> 
> OK, this seems to be the case due the above (comment says "old_len
> exactly to the end of the area..").

yeah but is the check necessary ?

> 
> But I am wondering what led you to the patch because you do not say so

As can be seen in the test program, was trying to measure the speed
of VMA expansion and contraction inside an address space and then
figured out that dropping this check improves the speed prima facie.


> here. This is hardly something that would save many cycles in a
> relatively cold path.

Though I have not done any detailed instruction level measurement,
there is a reduction in real and system amount of time to execute
the test with and without the patch.

Without the patch

real0m2.100s
user0m0.162s
sys 0m1.937s

With this patch

real0m0.928s
user0m0.161s
sys 0m0.756s

Re: [RFC] mm/mremap: Remove redundant checks inside vma_expandable()

[Anshuman Khandual]

On 07/10/2017 07:19 PM, Michal Hocko wrote:
> On Mon 10-07-17 16:40:59, Anshuman Khandual wrote:
>> As 'delta' is an unsigned long, 'end' (vma->vm_end + delta) cannot
>> be less than 'vma->vm_end'.
> 
> This just doesn't make any sense. This is exactly what the overflow
> check is for. Maybe vm_end + delta can never overflow because of
> (old_len == vma->vm_end - addr) and guarantee old_len < new_len
> in mremap but I haven't checked that too deeply.

Irrespective of that, just looking at the variables inside this
particular function where delta is an 'unsigned long', 'end' cannot
be less than vma->vm_end. Is not that true ?

> 
>> Checking for availability of virtual
>> address range at the end of the VMA for the incremental size is
>> also reduntant at this point. Hence drop them both.
> 
> OK, this seems to be the case due the above (comment says "old_len
> exactly to the end of the area..").

yeah but is the check necessary ?

> 
> But I am wondering what led you to the patch because you do not say so

As can be seen in the test program, was trying to measure the speed
of VMA expansion and contraction inside an address space and then
figured out that dropping this check improves the speed prima facie.


> here. This is hardly something that would save many cycles in a
> relatively cold path.

Though I have not done any detailed instruction level measurement,
there is a reduction in real and system amount of time to execute
the test with and without the patch.

Without the patch

real0m2.100s
user0m0.162s
sys 0m1.937s

With this patch

real0m0.928s
user0m0.161s
sys 0m0.756s

Re: [RFC] mm/mremap: Remove redundant checks inside vma_expandable()

[Anshuman Khandual]

On 07/10/2017 07:19 PM, Michal Hocko wrote:
> On Mon 10-07-17 16:40:59, Anshuman Khandual wrote:
>> As 'delta' is an unsigned long, 'end' (vma->vm_end + delta) cannot
>> be less than 'vma->vm_end'.
> 
> This just doesn't make any sense. This is exactly what the overflow
> check is for. Maybe vm_end + delta can never overflow because of
> (old_len == vma->vm_end - addr) and guarantee old_len < new_len
> in mremap but I haven't checked that too deeply.

Irrespective of that, just looking at the variables inside this
particular function where delta is an 'unsigned long', 'end' cannot
be less than vma->vm_end. Is not that true ?

> 
>> Checking for availability of virtual
>> address range at the end of the VMA for the incremental size is
>> also reduntant at this point. Hence drop them both.
> 
> OK, this seems to be the case due the above (comment says "old_len
> exactly to the end of the area..").

yeah but is the check necessary ?

> 
> But I am wondering what led you to the patch because you do not say so

As can be seen in the test program, was trying to measure the speed
of VMA expansion and contraction inside an address space and then
figured out that dropping this check improves the speed prima facie.


> here. This is hardly something that would save many cycles in a
> relatively cold path.

Though I have not done any detailed instruction level measurement,
there is a reduction in real and system amount of time to execute
the test with and without the patch.

Without the patch

real0m2.100s
user0m0.162s
sys 0m1.937s

With this patch

real0m0.928s
user0m0.161s
sys 0m0.756s

Re: [RFC] mm/mremap: Remove redundant checks inside vma_expandable()

[Anshuman Khandual]

On 07/10/2017 07:19 PM, Michal Hocko wrote:
> On Mon 10-07-17 16:40:59, Anshuman Khandual wrote:
>> As 'delta' is an unsigned long, 'end' (vma->vm_end + delta) cannot
>> be less than 'vma->vm_end'.
> 
> This just doesn't make any sense. This is exactly what the overflow
> check is for. Maybe vm_end + delta can never overflow because of
> (old_len == vma->vm_end - addr) and guarantee old_len < new_len
> in mremap but I haven't checked that too deeply.

Irrespective of that, just looking at the variables inside this
particular function where delta is an 'unsigned long', 'end' cannot
be less than vma->vm_end. Is not that true ?

> 
>> Checking for availability of virtual
>> address range at the end of the VMA for the incremental size is
>> also reduntant at this point. Hence drop them both.
> 
> OK, this seems to be the case due the above (comment says "old_len
> exactly to the end of the area..").

yeah but is the check necessary ?

> 
> But I am wondering what led you to the patch because you do not say so

As can be seen in the test program, was trying to measure the speed
of VMA expansion and contraction inside an address space and then
figured out that dropping this check improves the speed prima facie.


> here. This is hardly something that would save many cycles in a
> relatively cold path.

Though I have not done any detailed instruction level measurement,
there is a reduction in real and system amount of time to execute
the test with and without the patch.

Without the patch

real0m2.100s
user0m0.162s
sys 0m1.937s

With this patch

real0m0.928s
user0m0.161s
sys 0m0.756s

Re: [RFC v5 01/11] mm: Dont assume page-table invariance during faults

[Balbir Singh]

On Mon, 10 Jul 2017 19:48:43 +0200
Laurent Dufour  wrote:

> On 07/07/2017 09:07, Balbir Singh wrote:
> > On Fri, 2017-06-16 at 19:52 +0200, Laurent Dufour wrote:  
> >> From: Peter Zijlstra 
> >>
> >> One of the side effects of speculating on faults (without holding
> >> mmap_sem) is that we can race with free_pgtables() and therefore we
> >> cannot assume the page-tables will stick around.
> >>
> >> Remove the relyance on the pte pointer.  
> >  ^^ reliance
> > 
> > Looking at the changelog and the code the impact is not clear.
> > It looks like after this patch we always assume the pte is not
> > the same. What is the impact of this patch?  
> 
> Hi Balbir,
> 
> In most of the case pte_unmap_same() was returning 1, which meaning that
> do_swap_page() should do its processing.
> 
> So in most of the case there will be no impact.
> 
> Now regarding the case where pte_unmap_safe() was returning 0, and thus
> do_swap_page return 0 too, this happens when the page has already been
> swapped back. This may happen before do_swap_page() get called or while in
> the call to do_swap_page(). In that later case, the check done when
> swapin_readahead() returns will detect that case.
> 
> The worst case would be that a page fault is occuring on 2 threads at the
> same time on the same swapped out page. In that case one thread will take
> much time looping in __read_swap_cache_async(). But in the regular page
> fault path, this is even worse since the thread would wait for semaphore to
> be released before starting anything.
> 
>

Sounds good!

Thanks,
Balbir Singh 

Re: [RFC v5 01/11] mm: Dont assume page-table invariance during faults

[Balbir Singh]

On Mon, 10 Jul 2017 19:48:43 +0200
Laurent Dufour  wrote:

> On 07/07/2017 09:07, Balbir Singh wrote:
> > On Fri, 2017-06-16 at 19:52 +0200, Laurent Dufour wrote:  
> >> From: Peter Zijlstra 
> >>
> >> One of the side effects of speculating on faults (without holding
> >> mmap_sem) is that we can race with free_pgtables() and therefore we
> >> cannot assume the page-tables will stick around.
> >>
> >> Remove the relyance on the pte pointer.  
> >  ^^ reliance
> > 
> > Looking at the changelog and the code the impact is not clear.
> > It looks like after this patch we always assume the pte is not
> > the same. What is the impact of this patch?  
> 
> Hi Balbir,
> 
> In most of the case pte_unmap_same() was returning 1, which meaning that
> do_swap_page() should do its processing.
> 
> So in most of the case there will be no impact.
> 
> Now regarding the case where pte_unmap_safe() was returning 0, and thus
> do_swap_page return 0 too, this happens when the page has already been
> swapped back. This may happen before do_swap_page() get called or while in
> the call to do_swap_page(). In that later case, the check done when
> swapin_readahead() returns will detect that case.
> 
> The worst case would be that a page fault is occuring on 2 threads at the
> same time on the same swapped out page. In that case one thread will take
> much time looping in __read_swap_cache_async(). But in the regular page
> fault path, this is even worse since the thread would wait for semaphore to
> be released before starting anything.
> 
>

Sounds good!

Thanks,
Balbir Singh 

Re: [PATCH 3/3] Make LSM Writable Hooks a command line option

[kbuild test robot]

Hi Igor,

[auto build test ERROR on linus/master]
[cannot apply to v4.12]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/mm-security-ro-protection-for-dynamic-data/20170711-084116
config: score-spct6600_defconfig (attached as .config)
compiler: score-elf-gcc (GCC) 4.9.1 20140622 (prerelease)
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=score 

All errors (new ones prefixed by >>):

   security/security.o: In function `security_init':
>> security.c:(.init.text+0x68): undefined reference to `pmalloc_create_pool'
>> security.c:(.init.text+0x98): undefined reference to `pmalloc'
>> security.c:(.init.text+0x150): undefined reference to `pmalloc_protect_pool'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 3/3] Make LSM Writable Hooks a command line option

[kbuild test robot]

Hi Igor,

[auto build test ERROR on linus/master]
[cannot apply to v4.12]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/mm-security-ro-protection-for-dynamic-data/20170711-084116
config: score-spct6600_defconfig (attached as .config)
compiler: score-elf-gcc (GCC) 4.9.1 20140622 (prerelease)
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=score 

All errors (new ones prefixed by >>):

   security/security.o: In function `security_init':
>> security.c:(.init.text+0x68): undefined reference to `pmalloc_create_pool'
>> security.c:(.init.text+0x98): undefined reference to `pmalloc'
>> security.c:(.init.text+0x150): undefined reference to `pmalloc_protect_pool'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/5] mm/device-public-memory: device memory cache coherent with CPU v2

[Balbir Singh]

On Mon,  3 Jul 2017 17:14:12 -0400
Jérôme Glisse  wrote:

> Platform with advance system bus (like CAPI or CCIX) allow device
> memory to be accessible from CPU in a cache coherent fashion. Add
> a new type of ZONE_DEVICE to represent such memory. The use case
> are the same as for the un-addressable device memory but without
> all the corners cases.
>

Looks good overall, some comments inline.
 
> Changed since v1:
>   - Kconfig and #if/#else cleanup
> 
> Signed-off-by: Jérôme Glisse 
> Cc: Balbir Singh 
> Cc: Aneesh Kumar 
> Cc: Paul E. McKenney 
> Cc: Benjamin Herrenschmidt 
> Cc: Dan Williams 
> Cc: Ross Zwisler 
> ---
>  fs/proc/task_mmu.c   |  2 +-
>  include/linux/hmm.h  |  4 ++--
>  include/linux/ioport.h   |  1 +
>  include/linux/memremap.h | 21 +
>  include/linux/mm.h   | 16 -
>  kernel/memremap.c| 11 ++---
>  mm/Kconfig   | 11 +
>  mm/gup.c |  7 ++
>  mm/hmm.c |  4 ++--
>  mm/madvise.c |  2 +-
>  mm/memory.c  | 46 +
>  mm/migrate.c | 60 
> 
>  mm/swap.c| 11 +
>  13 files changed, 156 insertions(+), 40 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 957b6ea80d5f..1f38f2c7cc34 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1182,7 +1182,7 @@ static pagemap_entry_t pte_to_pagemap_entry(struct 
> pagemapread *pm,
>   if (pm->show_pfn)
>   frame = pte_pfn(pte);
>   flags |= PM_PRESENT;
> - page = vm_normal_page(vma, addr, pte);
> + page = _vm_normal_page(vma, addr, pte, true);
>   if (pte_soft_dirty(pte))
>   flags |= PM_SOFT_DIRTY;
>   } else if (is_swap_pte(pte)) {
> diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> index 458d0d6d82f3..a40288309fd2 100644
> --- a/include/linux/hmm.h
> +++ b/include/linux/hmm.h
> @@ -327,7 +327,7 @@ int hmm_vma_fault(struct vm_area_struct *vma,
>  #endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */
>  
>  
> -#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
> +#if IS_ENABLED(CONFIG_DEVICE_PRIVATE) ||  IS_ENABLED(CONFIG_DEVICE_PUBLIC)
>  struct hmm_devmem;
>  
>  struct page *hmm_vma_alloc_locked_page(struct vm_area_struct *vma,
> @@ -443,7 +443,7 @@ struct hmm_device {
>   */
>  struct hmm_device *hmm_device_new(void *drvdata);
>  void hmm_device_put(struct hmm_device *hmm_device);
> -#endif /* IS_ENABLED(CONFIG_DEVICE_PRIVATE) */
> +#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
>  
>  
>  /* Below are for HMM internal use only! Not to be used by device driver! */
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 3a4f69137bc2..f5cf32e80041 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -131,6 +131,7 @@ enum {
>   IORES_DESC_PERSISTENT_MEMORY= 4,
>   IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
>   IORES_DESC_DEVICE_PRIVATE_MEMORY= 6,
> + IORES_DESC_DEVICE_PUBLIC_MEMORY = 7,
>  };
>  
>  /* helpers to define resources */
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 2299cc2d387d..916ca1653ced 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -57,10 +57,18 @@ static inline struct vmem_altmap *to_vmem_altmap(unsigned 
> long memmap_start)
>   *
>   * A more complete discussion of unaddressable memory may be found in
>   * include/linux/hmm.h and Documentation/vm/hmm.txt.
> + *
> + * MEMORY_DEVICE_PUBLIC:
> + * Device memory that is cache coherent from device and CPU point of view. 
> This
> + * is use on platform that have an advance system bus (like CAPI or CCIX). A
> + * driver can hotplug the device memory using ZONE_DEVICE and with that 
> memory
> + * type. Any page of a process can be migrated to such memory. However no one
> + * should be allow to pin such memory so that it can always be evicted.
>   */
>  enum memory_type {
>   MEMORY_DEVICE_PERSISTENT = 0,
>   MEMORY_DEVICE_PRIVATE,
> + MEMORY_DEVICE_PUBLIC,
>  };
>  
>  /*
> @@ -92,6 +100,8 @@ enum memory_type {
>   * The page_free() callback is called once the page refcount reaches 1
>   * (ZONE_DEVICE pages never reach 0 refcount unless there is a refcount bug.
>   * This allows the device driver to implement its own memory management.)
> + *
> + * For MEMORY_DEVICE_CACHE_COHERENT only the page_free() callback matter.

Correct, but I wonder if we should in the long term allow for minor faults
(due to coherency) via this interface?

>   */
>  typedef int (*dev_page_fault_t)(struct vm_area_struct *vma,
>   unsigned long 

Re: [PATCH 2/5] mm/device-public-memory: device memory cache coherent with CPU v2

[Balbir Singh]

On Mon,  3 Jul 2017 17:14:12 -0400
Jérôme Glisse  wrote:

> Platform with advance system bus (like CAPI or CCIX) allow device
> memory to be accessible from CPU in a cache coherent fashion. Add
> a new type of ZONE_DEVICE to represent such memory. The use case
> are the same as for the un-addressable device memory but without
> all the corners cases.
>

Looks good overall, some comments inline.
 
> Changed since v1:
>   - Kconfig and #if/#else cleanup
> 
> Signed-off-by: Jérôme Glisse 
> Cc: Balbir Singh 
> Cc: Aneesh Kumar 
> Cc: Paul E. McKenney 
> Cc: Benjamin Herrenschmidt 
> Cc: Dan Williams 
> Cc: Ross Zwisler 
> ---
>  fs/proc/task_mmu.c   |  2 +-
>  include/linux/hmm.h  |  4 ++--
>  include/linux/ioport.h   |  1 +
>  include/linux/memremap.h | 21 +
>  include/linux/mm.h   | 16 -
>  kernel/memremap.c| 11 ++---
>  mm/Kconfig   | 11 +
>  mm/gup.c |  7 ++
>  mm/hmm.c |  4 ++--
>  mm/madvise.c |  2 +-
>  mm/memory.c  | 46 +
>  mm/migrate.c | 60 
> 
>  mm/swap.c| 11 +
>  13 files changed, 156 insertions(+), 40 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 957b6ea80d5f..1f38f2c7cc34 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1182,7 +1182,7 @@ static pagemap_entry_t pte_to_pagemap_entry(struct 
> pagemapread *pm,
>   if (pm->show_pfn)
>   frame = pte_pfn(pte);
>   flags |= PM_PRESENT;
> - page = vm_normal_page(vma, addr, pte);
> + page = _vm_normal_page(vma, addr, pte, true);
>   if (pte_soft_dirty(pte))
>   flags |= PM_SOFT_DIRTY;
>   } else if (is_swap_pte(pte)) {
> diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> index 458d0d6d82f3..a40288309fd2 100644
> --- a/include/linux/hmm.h
> +++ b/include/linux/hmm.h
> @@ -327,7 +327,7 @@ int hmm_vma_fault(struct vm_area_struct *vma,
>  #endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */
>  
>  
> -#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
> +#if IS_ENABLED(CONFIG_DEVICE_PRIVATE) ||  IS_ENABLED(CONFIG_DEVICE_PUBLIC)
>  struct hmm_devmem;
>  
>  struct page *hmm_vma_alloc_locked_page(struct vm_area_struct *vma,
> @@ -443,7 +443,7 @@ struct hmm_device {
>   */
>  struct hmm_device *hmm_device_new(void *drvdata);
>  void hmm_device_put(struct hmm_device *hmm_device);
> -#endif /* IS_ENABLED(CONFIG_DEVICE_PRIVATE) */
> +#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
>  
>  
>  /* Below are for HMM internal use only! Not to be used by device driver! */
> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> index 3a4f69137bc2..f5cf32e80041 100644
> --- a/include/linux/ioport.h
> +++ b/include/linux/ioport.h
> @@ -131,6 +131,7 @@ enum {
>   IORES_DESC_PERSISTENT_MEMORY= 4,
>   IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
>   IORES_DESC_DEVICE_PRIVATE_MEMORY= 6,
> + IORES_DESC_DEVICE_PUBLIC_MEMORY = 7,
>  };
>  
>  /* helpers to define resources */
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 2299cc2d387d..916ca1653ced 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -57,10 +57,18 @@ static inline struct vmem_altmap *to_vmem_altmap(unsigned 
> long memmap_start)
>   *
>   * A more complete discussion of unaddressable memory may be found in
>   * include/linux/hmm.h and Documentation/vm/hmm.txt.
> + *
> + * MEMORY_DEVICE_PUBLIC:
> + * Device memory that is cache coherent from device and CPU point of view. 
> This
> + * is use on platform that have an advance system bus (like CAPI or CCIX). A
> + * driver can hotplug the device memory using ZONE_DEVICE and with that 
> memory
> + * type. Any page of a process can be migrated to such memory. However no one
> + * should be allow to pin such memory so that it can always be evicted.
>   */
>  enum memory_type {
>   MEMORY_DEVICE_PERSISTENT = 0,
>   MEMORY_DEVICE_PRIVATE,
> + MEMORY_DEVICE_PUBLIC,
>  };
>  
>  /*
> @@ -92,6 +100,8 @@ enum memory_type {
>   * The page_free() callback is called once the page refcount reaches 1
>   * (ZONE_DEVICE pages never reach 0 refcount unless there is a refcount bug.
>   * This allows the device driver to implement its own memory management.)
> + *
> + * For MEMORY_DEVICE_CACHE_COHERENT only the page_free() callback matter.

Correct, but I wonder if we should in the long term allow for minor faults
(due to coherency) via this interface?

>   */
>  typedef int (*dev_page_fault_t)(struct vm_area_struct *vma,
>   unsigned long addr,
> @@ -134,6 +144,12 @@ static inline bool is_device_private_page(const struct 
> page *page)
>   return is_zone_device_page(page) &&
>   page->pgmap->type == MEMORY_DEVICE_PRIVATE;
>  }

Re: [PATCH] printk: Modify operators of printed_len

[pierre kuo]

hi Petr
> I just noticed that the same applies also to text_len
> variable. Well, it was caused by another commit ddb9baa822265b55
> ("printk: report lost messages in printk safe/nmi contexts").
> Could you please send a patch for this as well?
sure and it is my pleasure.

>
> This seems to be your first patch sent to the kernel mailing list.
Yes :-)

> There is a standard format how to reference older commits. It is
> 'commit <12+ chars of sha1> ("")', see my comment above
> for an example.
>
> A good practice is to run ./scripts/checkpatch.pl  before
> you send the patch. Well, you need to use a common sense and ignore
> false positives or hints that make a particular patch less readable
> in the end.
>
> Also it is handy to bump the version of the patch when it is
> updated, e.g. use [PATCH v2] in the subject. People also
> summarize changes against the previous version(s) below
> the --- line. Well, this is more useful when there is a longer
> delay between the versions and the changes are more complicated.
Really appreciate hints you provided and I will send the v2 patch soon.

Best Regards.

Re: [PATCH] printk: Modify operators of printed_len

[pierre kuo]

hi Petr
> I just noticed that the same applies also to text_len
> variable. Well, it was caused by another commit ddb9baa822265b55
> ("printk: report lost messages in printk safe/nmi contexts").
> Could you please send a patch for this as well?
sure and it is my pleasure.

>
> This seems to be your first patch sent to the kernel mailing list.
Yes :-)

> There is a standard format how to reference older commits. It is
> 'commit <12+ chars of sha1> ("")', see my comment above
> for an example.
>
> A good practice is to run ./scripts/checkpatch.pl  before
> you send the patch. Well, you need to use a common sense and ignore
> false positives or hints that make a particular patch less readable
> in the end.
>
> Also it is handy to bump the version of the patch when it is
> updated, e.g. use [PATCH v2] in the subject. People also
> summarize changes against the previous version(s) below
> the --- line. Well, this is more useful when there is a longer
> delay between the versions and the changes are more complicated.
Really appreciate hints you provided and I will send the v2 patch soon.

Best Regards.

[PATCH] staging: unisys: visorbus: fix function open braces

[Mitchell Tasman]

Resolve multiple checkpatch errors by relocating open braces
following function definitions to the next line.

Signed-off-by: Mitchell Tasman 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1c785dd..c564962 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -270,7 +270,8 @@ static const struct attribute_group 
*visorbus_channel_groups[] = {
 
 static ssize_t partition_handle_show(struct device *dev,
 struct device_attribute *attr,
-char *buf) {
+char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
u64 handle = visorchannel_get_clientpartition(vdev->visorchannel);
 
@@ -280,7 +281,8 @@ static DEVICE_ATTR_RO(partition_handle);
 
 static ssize_t partition_guid_show(struct device *dev,
   struct device_attribute *attr,
-  char *buf) {
+  char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
 
return sprintf(buf, "{%pUb}\n", >partition_uuid);
@@ -289,7 +291,8 @@ static DEVICE_ATTR_RO(partition_guid);
 
 static ssize_t partition_name_show(struct device *dev,
   struct device_attribute *attr,
-  char *buf) {
+  char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
 
return sprintf(buf, "%s\n", vdev->name);
@@ -298,7 +301,8 @@ static DEVICE_ATTR_RO(partition_name);
 
 static ssize_t channel_addr_show(struct device *dev,
 struct device_attribute *attr,
-char *buf) {
+char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
u64 addr = visorchannel_get_physaddr(vdev->visorchannel);
 
@@ -308,7 +312,8 @@ static DEVICE_ATTR_RO(channel_addr);
 
 static ssize_t channel_bytes_show(struct device *dev,
  struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
u64 nbytes = visorchannel_get_nbytes(vdev->visorchannel);
 
@@ -318,7 +323,8 @@ static DEVICE_ATTR_RO(channel_bytes);
 
 static ssize_t channel_id_show(struct device *dev,
   struct device_attribute *attr,
-  char *buf) {
+  char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
int len = 0;
 
-- 
2.9.3

[PATCH] staging: unisys: visorbus: fix function open braces

[Mitchell Tasman]

Resolve multiple checkpatch errors by relocating open braces
following function definitions to the next line.

Signed-off-by: Mitchell Tasman 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1c785dd..c564962 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -270,7 +270,8 @@ static const struct attribute_group 
*visorbus_channel_groups[] = {
 
 static ssize_t partition_handle_show(struct device *dev,
 struct device_attribute *attr,
-char *buf) {
+char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
u64 handle = visorchannel_get_clientpartition(vdev->visorchannel);
 
@@ -280,7 +281,8 @@ static DEVICE_ATTR_RO(partition_handle);
 
 static ssize_t partition_guid_show(struct device *dev,
   struct device_attribute *attr,
-  char *buf) {
+  char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
 
return sprintf(buf, "{%pUb}\n", >partition_uuid);
@@ -289,7 +291,8 @@ static DEVICE_ATTR_RO(partition_guid);
 
 static ssize_t partition_name_show(struct device *dev,
   struct device_attribute *attr,
-  char *buf) {
+  char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
 
return sprintf(buf, "%s\n", vdev->name);
@@ -298,7 +301,8 @@ static DEVICE_ATTR_RO(partition_name);
 
 static ssize_t channel_addr_show(struct device *dev,
 struct device_attribute *attr,
-char *buf) {
+char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
u64 addr = visorchannel_get_physaddr(vdev->visorchannel);
 
@@ -308,7 +312,8 @@ static DEVICE_ATTR_RO(channel_addr);
 
 static ssize_t channel_bytes_show(struct device *dev,
  struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
u64 nbytes = visorchannel_get_nbytes(vdev->visorchannel);
 
@@ -318,7 +323,8 @@ static DEVICE_ATTR_RO(channel_bytes);
 
 static ssize_t channel_id_show(struct device *dev,
   struct device_attribute *attr,
-  char *buf) {
+  char *buf)
+{
struct visor_device *vdev = to_visor_device(dev);
int len = 0;
 
-- 
2.9.3

Re: [PATCH 1/5] mm/persistent-memory: match IORES_DESC name and enum memory_type one

[Balbir Singh]

On Wed, 5 Jul 2017 14:49:33 -0400
Jerome Glisse  wrote:

> On Wed, Jul 05, 2017 at 09:15:35AM -0700, Dan Williams wrote:
> > On Wed, Jul 5, 2017 at 7:25 AM, Jerome Glisse  wrote:  
> > > On Mon, Jul 03, 2017 at 04:49:18PM -0700, Dan Williams wrote:  
> > >> On Mon, Jul 3, 2017 at 2:14 PM, Jérôme Glisse  
> > >> wrote:  
> > >> > Use consistent name between IORES_DESC and enum memory_type, rename
> > >> > MEMORY_DEVICE_PUBLIC to MEMORY_DEVICE_PERSISTENT. This is to free up
> > >> > the public name for CDM (cache coherent device memory) for which the
> > >> > term public is a better match.
> > >> >
> > >> > Signed-off-by: Jérôme Glisse 
> > >> > Cc: Dan Williams 
> > >> > Cc: Ross Zwisler 
> > >> > ---
> > >> >  include/linux/memremap.h | 4 ++--
> > >> >  kernel/memremap.c| 2 +-
> > >> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > >> >
> > >> > diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> > >> > index 57546a07a558..2299cc2d387d 100644
> > >> > --- a/include/linux/memremap.h
> > >> > +++ b/include/linux/memremap.h
> > >> > @@ -41,7 +41,7 @@ static inline struct vmem_altmap 
> > >> > *to_vmem_altmap(unsigned long memmap_start)
> > >> >   * Specialize ZONE_DEVICE memory into multiple types each having 
> > >> > differents
> > >> >   * usage.
> > >> >   *
> > >> > - * MEMORY_DEVICE_PUBLIC:
> > >> > + * MEMORY_DEVICE_PERSISTENT:
> > >> >   * Persistent device memory (pmem): struct page might be allocated in 
> > >> > different
> > >> >   * memory and architecture might want to perform special actions. It 
> > >> > is similar
> > >> >   * to regular memory, in that the CPU can access it transparently. 
> > >> > However,
> > >> > @@ -59,7 +59,7 @@ static inline struct vmem_altmap 
> > >> > *to_vmem_altmap(unsigned long memmap_start)
> > >> >   * include/linux/hmm.h and Documentation/vm/hmm.txt.
> > >> >   */
> > >> >  enum memory_type {
> > >> > -   MEMORY_DEVICE_PUBLIC = 0,
> > >> > +   MEMORY_DEVICE_PERSISTENT = 0,
> > >> > MEMORY_DEVICE_PRIVATE,
> > >> >  };
> > >> >
> > >> > diff --git a/kernel/memremap.c b/kernel/memremap.c
> > >> > index b9baa6c07918..e82456c39a6a 100644
> > >> > --- a/kernel/memremap.c
> > >> > +++ b/kernel/memremap.c
> > >> > @@ -350,7 +350,7 @@ void *devm_memremap_pages(struct device *dev, 
> > >> > struct resource *res,
> > >> > }
> > >> > pgmap->ref = ref;
> > >> > pgmap->res = _map->res;
> > >> > -   pgmap->type = MEMORY_DEVICE_PUBLIC;
> > >> > +   pgmap->type = MEMORY_DEVICE_PERSISTENT;
> > >> > pgmap->page_fault = NULL;
> > >> > pgmap->page_free = NULL;
> > >> > pgmap->data = NULL;  
> > >>
> > >> I think we need a different name. There's nothing "persistent" about
> > >> the devm_memremap_pages() path. Why can't they share name, is the only
> > >> difference coherence? I'm thinking something like:
> > >>
> > >> MEMORY_DEVICE_PRIVATE
> > >> MEMORY_DEVICE_COHERENT /* persistent memory and coherent devices */
> > >> MEMORY_DEVICE_IO /* "public", but not coherent */  
> > >
> > > No that would not work. Device public (in the context of this patchset)
> > > is like device private ie device public page can be anywhere inside a
> > > process address space either as anonymous memory page or as file back
> > > page of regular filesystem (ie vma->ops is not pointing to anything
> > > specific to the device memory).
> > >
> > > As such device public is different from how persistent memory is use
> > > and those the cache coherency being the same between the two kind of
> > > memory is not a discerning factor. So i need to distinguish between
> > > persistent memory and device public memory.
> > >
> > > I believe keeping enum memory_type close to IORES_DESC naming is the
> > > cleanest way to do that but i am open to other name suggestion.
> > >  
> > 
> > The IORES_DESC has nothing to do with how the memory range is handled
> > by the core mm. It sounds like the distinction this is trying to make
> > is between MEMORY_DEVICE_{PUBLIC,PRIVATE} and MEMORY_DEVICE_HOST.
> > Where a "host" memory range is one that does not need coordination
> > with a specific device.  
> 
> I want to distinguish between:
>   - device memory that is not accessible by the CPU
>   - device memory that is accessible by the CPU just like regular
> memory
>   - existing user of devm_memremap_pages() which is persistent memory
> (only pmem seems to call devm_memremap_pages()) that is use like a
> filesystem or block device and thus isn't use like generic page in
> a process address space
> 
> So if existing user of devm_memremap_pages() are only persistent memory
> then it made sense to match the IORES_DESC we are expecting to see on
> see such memory.
> 
> For public device memory (in the sense introduced by this patchset) i
> do not know how it will be 

Re: [PATCH 1/5] mm/persistent-memory: match IORES_DESC name and enum memory_type one

[Balbir Singh]

On Wed, 5 Jul 2017 14:49:33 -0400
Jerome Glisse  wrote:

> On Wed, Jul 05, 2017 at 09:15:35AM -0700, Dan Williams wrote:
> > On Wed, Jul 5, 2017 at 7:25 AM, Jerome Glisse  wrote:  
> > > On Mon, Jul 03, 2017 at 04:49:18PM -0700, Dan Williams wrote:  
> > >> On Mon, Jul 3, 2017 at 2:14 PM, Jérôme Glisse  
> > >> wrote:  
> > >> > Use consistent name between IORES_DESC and enum memory_type, rename
> > >> > MEMORY_DEVICE_PUBLIC to MEMORY_DEVICE_PERSISTENT. This is to free up
> > >> > the public name for CDM (cache coherent device memory) for which the
> > >> > term public is a better match.
> > >> >
> > >> > Signed-off-by: Jérôme Glisse 
> > >> > Cc: Dan Williams 
> > >> > Cc: Ross Zwisler 
> > >> > ---
> > >> >  include/linux/memremap.h | 4 ++--
> > >> >  kernel/memremap.c| 2 +-
> > >> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > >> >
> > >> > diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> > >> > index 57546a07a558..2299cc2d387d 100644
> > >> > --- a/include/linux/memremap.h
> > >> > +++ b/include/linux/memremap.h
> > >> > @@ -41,7 +41,7 @@ static inline struct vmem_altmap 
> > >> > *to_vmem_altmap(unsigned long memmap_start)
> > >> >   * Specialize ZONE_DEVICE memory into multiple types each having 
> > >> > differents
> > >> >   * usage.
> > >> >   *
> > >> > - * MEMORY_DEVICE_PUBLIC:
> > >> > + * MEMORY_DEVICE_PERSISTENT:
> > >> >   * Persistent device memory (pmem): struct page might be allocated in 
> > >> > different
> > >> >   * memory and architecture might want to perform special actions. It 
> > >> > is similar
> > >> >   * to regular memory, in that the CPU can access it transparently. 
> > >> > However,
> > >> > @@ -59,7 +59,7 @@ static inline struct vmem_altmap 
> > >> > *to_vmem_altmap(unsigned long memmap_start)
> > >> >   * include/linux/hmm.h and Documentation/vm/hmm.txt.
> > >> >   */
> > >> >  enum memory_type {
> > >> > -   MEMORY_DEVICE_PUBLIC = 0,
> > >> > +   MEMORY_DEVICE_PERSISTENT = 0,
> > >> > MEMORY_DEVICE_PRIVATE,
> > >> >  };
> > >> >
> > >> > diff --git a/kernel/memremap.c b/kernel/memremap.c
> > >> > index b9baa6c07918..e82456c39a6a 100644
> > >> > --- a/kernel/memremap.c
> > >> > +++ b/kernel/memremap.c
> > >> > @@ -350,7 +350,7 @@ void *devm_memremap_pages(struct device *dev, 
> > >> > struct resource *res,
> > >> > }
> > >> > pgmap->ref = ref;
> > >> > pgmap->res = _map->res;
> > >> > -   pgmap->type = MEMORY_DEVICE_PUBLIC;
> > >> > +   pgmap->type = MEMORY_DEVICE_PERSISTENT;
> > >> > pgmap->page_fault = NULL;
> > >> > pgmap->page_free = NULL;
> > >> > pgmap->data = NULL;  
> > >>
> > >> I think we need a different name. There's nothing "persistent" about
> > >> the devm_memremap_pages() path. Why can't they share name, is the only
> > >> difference coherence? I'm thinking something like:
> > >>
> > >> MEMORY_DEVICE_PRIVATE
> > >> MEMORY_DEVICE_COHERENT /* persistent memory and coherent devices */
> > >> MEMORY_DEVICE_IO /* "public", but not coherent */  
> > >
> > > No that would not work. Device public (in the context of this patchset)
> > > is like device private ie device public page can be anywhere inside a
> > > process address space either as anonymous memory page or as file back
> > > page of regular filesystem (ie vma->ops is not pointing to anything
> > > specific to the device memory).
> > >
> > > As such device public is different from how persistent memory is use
> > > and those the cache coherency being the same between the two kind of
> > > memory is not a discerning factor. So i need to distinguish between
> > > persistent memory and device public memory.
> > >
> > > I believe keeping enum memory_type close to IORES_DESC naming is the
> > > cleanest way to do that but i am open to other name suggestion.
> > >  
> > 
> > The IORES_DESC has nothing to do with how the memory range is handled
> > by the core mm. It sounds like the distinction this is trying to make
> > is between MEMORY_DEVICE_{PUBLIC,PRIVATE} and MEMORY_DEVICE_HOST.
> > Where a "host" memory range is one that does not need coordination
> > with a specific device.  
> 
> I want to distinguish between:
>   - device memory that is not accessible by the CPU
>   - device memory that is accessible by the CPU just like regular
> memory
>   - existing user of devm_memremap_pages() which is persistent memory
> (only pmem seems to call devm_memremap_pages()) that is use like a
> filesystem or block device and thus isn't use like generic page in
> a process address space
> 
> So if existing user of devm_memremap_pages() are only persistent memory
> then it made sense to match the IORES_DESC we are expecting to see on
> see such memory.
> 
> For public device memory (in the sense introduced by this patchset) i
> do not know how it will be described by IORES_DESC. i think first folks
> with it are IBM with CAPI and i am not sure they defined something for
> that already.
> 
> I am 

[git pull] m68knommu changes for v4.13

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.

Only a single change, to remove old Kconfig options from defconfigs.

Regards
Greg



The following changes since commit c0bc126f97fb929b3ae02c1c62322645d70eb408:

  Linux 4.12-rc7 (2017-06-25 18:30:05 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next

for you to fetch changes up to 354b6382847d1d95b576d0c851df7a5743b8a2c2:

  m68k: defconfig: Cleanup from old Kconfig options (2017-06-26 11:53:49 +1000)


Krzysztof Kozlowski (1):
  m68k: defconfig: Cleanup from old Kconfig options

 arch/m68k/configs/m5208evb_defconfig | 1 -
 arch/m68k/configs/m5249evb_defconfig | 1 -
 arch/m68k/configs/m5272c3_defconfig  | 1 -
 arch/m68k/configs/m5275evb_defconfig | 1 -
 arch/m68k/configs/m5307c3_defconfig  | 1 -
 arch/m68k/configs/m5407c3_defconfig  | 1 -
 6 files changed, 6 deletions(-)

[git pull] m68knommu changes for v4.13

[Greg Ungerer]

Hi Linus,

Can you please pull the m68knommu git tree, for-next branch.

Only a single change, to remove old Kconfig options from defconfigs.

Regards
Greg



The following changes since commit c0bc126f97fb929b3ae02c1c62322645d70eb408:

  Linux 4.12-rc7 (2017-06-25 18:30:05 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next

for you to fetch changes up to 354b6382847d1d95b576d0c851df7a5743b8a2c2:

  m68k: defconfig: Cleanup from old Kconfig options (2017-06-26 11:53:49 +1000)


Krzysztof Kozlowski (1):
  m68k: defconfig: Cleanup from old Kconfig options

 arch/m68k/configs/m5208evb_defconfig | 1 -
 arch/m68k/configs/m5249evb_defconfig | 1 -
 arch/m68k/configs/m5272c3_defconfig  | 1 -
 arch/m68k/configs/m5275evb_defconfig | 1 -
 arch/m68k/configs/m5307c3_defconfig  | 1 -
 arch/m68k/configs/m5407c3_defconfig  | 1 -
 6 files changed, 6 deletions(-)

Re: [PATCH] input: serio: constify attribute_group structures.

[Dmitry Torokhov]

On Wed, Jul 05, 2017 at 03:12:53PM +0530, Arvind Yadav wrote:
> attribute_groups are not supposed to change at runtime. All functions
> working with attribute_groups provided by  work with const
> attribute_group. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>6862  1008   478741ec2 drivers/input/serio/serio.o
> 
> File size After adding 'const':
>text  data bss dec hex filename
>6990   880   478741ec2 drivers/input/serio/serio.o
> 
> Signed-off-by: Arvind Yadav 

Thanks, I'll queue this and the rest for 4.14.

> ---
>  drivers/input/serio/serio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
> index 30d6230..24a90c8 100644
> --- a/drivers/input/serio/serio.c
> +++ b/drivers/input/serio/serio.c
> @@ -469,7 +469,7 @@ static ssize_t firmware_id_show(struct device *dev, 
> struct device_attribute *att
>   NULL
>  };
>  
> -static struct attribute_group serio_id_attr_group = {
> +static const struct attribute_group serio_id_attr_group = {
>   .name   = "id",
>   .attrs  = serio_device_id_attrs,
>  };
> @@ -489,7 +489,7 @@ static ssize_t firmware_id_show(struct device *dev, 
> struct device_attribute *att
>   NULL
>  };
>  
> -static struct attribute_group serio_device_attr_group = {
> +static const struct attribute_group serio_device_attr_group = {
>   .attrs  = serio_device_attrs,
>  };
>  
> -- 
> 1.9.1
> 

-- 
Dmitry

Re: [PATCH] input: serio: constify attribute_group structures.

[Dmitry Torokhov]

On Wed, Jul 05, 2017 at 03:12:53PM +0530, Arvind Yadav wrote:
> attribute_groups are not supposed to change at runtime. All functions
> working with attribute_groups provided by  work with const
> attribute_group. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>6862  1008   478741ec2 drivers/input/serio/serio.o
> 
> File size After adding 'const':
>text  data bss dec hex filename
>6990   880   478741ec2 drivers/input/serio/serio.o
> 
> Signed-off-by: Arvind Yadav 

Thanks, I'll queue this and the rest for 4.14.

> ---
>  drivers/input/serio/serio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
> index 30d6230..24a90c8 100644
> --- a/drivers/input/serio/serio.c
> +++ b/drivers/input/serio/serio.c
> @@ -469,7 +469,7 @@ static ssize_t firmware_id_show(struct device *dev, 
> struct device_attribute *att
>   NULL
>  };
>  
> -static struct attribute_group serio_id_attr_group = {
> +static const struct attribute_group serio_id_attr_group = {
>   .name   = "id",
>   .attrs  = serio_device_id_attrs,
>  };
> @@ -489,7 +489,7 @@ static ssize_t firmware_id_show(struct device *dev, 
> struct device_attribute *att
>   NULL
>  };
>  
> -static struct attribute_group serio_device_attr_group = {
> +static const struct attribute_group serio_device_attr_group = {
>   .attrs  = serio_device_attrs,
>  };
>  
> -- 
> 1.9.1
> 

-- 
Dmitry

I am Rv.Father paul Olo,

[RV.FATHER PAUL]

RE:ATTN:PAYMENT NOTIFICATION!

10/7/2017

GOOD DAY,
I am Rv.Father paul Olo.

This is to bring to your notice that, I have paid the DHL courier Service 
charges and the delivery of your ATM CARD.I paid it because the ATM CARD worth 
{USD$10.5M}has less Four weeks and four days to expire and when it expires the 
money will go into Government reserve.

With that I decided to help you pay the money so that the ATM CARD will not
expire, because I know when you get your ATM CARD definitely you must
compensate me. Now your ATM CARD has been deposited with DHL Courier Company
for delivery so I want you to reconfirm DHL Director Courier Company with your 
Full
Contact information so that they can deliver your ATM CARD to your designated
address without any delay.

Your Full Name:
Home Address:...
Country:
Phone Number:...

Contact person..Mr.Anni Anam
Email  directordhlcouriercompany...@gmail.com

Like I stated earlier, the delivery charges has been paid.


>From Rv.Paul Olo
The General Payment
Contractor of Federal Republic of Benin

MAY THE PACE OF GOD ALMIGHTY BE ITH YOU

I am Rv.Father paul Olo,

[RV.FATHER PAUL]

RE:ATTN:PAYMENT NOTIFICATION!

10/7/2017

GOOD DAY,
I am Rv.Father paul Olo.

This is to bring to your notice that, I have paid the DHL courier Service 
charges and the delivery of your ATM CARD.I paid it because the ATM CARD worth 
{USD$10.5M}has less Four weeks and four days to expire and when it expires the 
money will go into Government reserve.

With that I decided to help you pay the money so that the ATM CARD will not
expire, because I know when you get your ATM CARD definitely you must
compensate me. Now your ATM CARD has been deposited with DHL Courier Company
for delivery so I want you to reconfirm DHL Director Courier Company with your 
Full
Contact information so that they can deliver your ATM CARD to your designated
address without any delay.

Your Full Name:
Home Address:...
Country:
Phone Number:...

Contact person..Mr.Anni Anam
Email  directordhlcouriercompany...@gmail.com

Like I stated earlier, the delivery charges has been paid.


>From Rv.Paul Olo
The General Payment
Contractor of Federal Republic of Benin

MAY THE PACE OF GOD ALMIGHTY BE ITH YOU

Re: [greybus-dev] [PATCH v3] staging: greybus: arche: wrap over-length lines

[Viresh Kumar]

On 10-07-17, 23:14, Mitchell Tasman wrote:
> Adjust formatting of several comments to keep line length within
> the 80 column limit preferred by the Linux kernel coding style.
> 
> Signed-off-by: Mitchell Tasman 
> ---
> Changes in v3: Narrow scope of patch per Viresh Kumar's feedback
> Changes in v2: Add back a missing space in a comment
> 
>  drivers/staging/greybus/arche-platform.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/greybus/arche-platform.c 
> b/drivers/staging/greybus/arche-platform.c
> index eced2d2..6259904 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -176,7 +176,10 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
> *devid)
>   
> arche_platform_set_wake_detect_state(arche_pdata,
>
> WD_STATE_IDLE);
>   } else {
> - /* Check we are not in middle of irq thread 
> already */
> + /*
> +  * Check we are not in middle of irq thread
> +  * already
> +  */
>   if (arche_pdata->wake_detect_state !=
>   WD_STATE_COLDBOOT_START) {
>   
> arche_platform_set_wake_detect_state(arche_pdata,
> @@ -657,12 +660,14 @@ static SIMPLE_DEV_PM_OPS(arche_platform_pm_ops,
>   arche_platform_resume);
>  
>  static const struct of_device_id arche_platform_of_match[] = {
> - { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
> device */
> + /* Use PID/VID of SVC device */
> + { .compatible = "google,arche-platform", },
>   { },
>  };
>  
>  static const struct of_device_id arche_combined_id[] = {
> - { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
> device */
> + /* Use PID/VID of SVC device */
> + { .compatible = "google,arche-platform", },
>   { .compatible = "usb,2", },
>   { },
>  };

Acked-by: Viresh Kumar 

-- 
viresh

Re: [greybus-dev] [PATCH v3] staging: greybus: arche: wrap over-length lines

[Viresh Kumar]

On 10-07-17, 23:14, Mitchell Tasman wrote:
> Adjust formatting of several comments to keep line length within
> the 80 column limit preferred by the Linux kernel coding style.
> 
> Signed-off-by: Mitchell Tasman 
> ---
> Changes in v3: Narrow scope of patch per Viresh Kumar's feedback
> Changes in v2: Add back a missing space in a comment
> 
>  drivers/staging/greybus/arche-platform.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/greybus/arche-platform.c 
> b/drivers/staging/greybus/arche-platform.c
> index eced2d2..6259904 100644
> --- a/drivers/staging/greybus/arche-platform.c
> +++ b/drivers/staging/greybus/arche-platform.c
> @@ -176,7 +176,10 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
> *devid)
>   
> arche_platform_set_wake_detect_state(arche_pdata,
>
> WD_STATE_IDLE);
>   } else {
> - /* Check we are not in middle of irq thread 
> already */
> + /*
> +  * Check we are not in middle of irq thread
> +  * already
> +  */
>   if (arche_pdata->wake_detect_state !=
>   WD_STATE_COLDBOOT_START) {
>   
> arche_platform_set_wake_detect_state(arche_pdata,
> @@ -657,12 +660,14 @@ static SIMPLE_DEV_PM_OPS(arche_platform_pm_ops,
>   arche_platform_resume);
>  
>  static const struct of_device_id arche_platform_of_match[] = {
> - { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
> device */
> + /* Use PID/VID of SVC device */
> + { .compatible = "google,arche-platform", },
>   { },
>  };
>  
>  static const struct of_device_id arche_combined_id[] = {
> - { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
> device */
> + /* Use PID/VID of SVC device */
> + { .compatible = "google,arche-platform", },
>   { .compatible = "usb,2", },
>   { },
>  };

Acked-by: Viresh Kumar 

-- 
viresh

[GIT PULL] chrome-platform updates for v4.13

[Benson Leung]

Hi Linus,

Please pull chrome-platform updates for Linux v4.13 from signed tag:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/chrome-platform-for-linus-4.13

Sorry for the delay on getting this into the merge window. My first
merge window as maintainer.

Thanks,
Benson

The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452:

  Linux 4.12-rc5 (2017-06-11 16:48:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/chrome-platform-for-linus-4.13

for you to fetch changes up to 3c778a7fcfaa4bb51aefb4f2c7364a5e2c4d0b66:

  platform/chrome : Add myself as Maintainer (2017-07-10 16:15:45 -0700)


chrome-platform-for-linus-4.13

Changes in this pull request are around catching up
cros_ec with the internal chromeos-kernel versions of
cros_ec, cros_ec_lpc, and cros_ec_lightbar.

Also, switching maintainership from olof to bleung.


Archana Patni (1):
  platform/chrome: cros_ec_lpc: Add power management ops

Arnd Bergmann (1):
  platform/chrome: cros_ec_lightbar - hide unused PM functions

Benson Leung (1):
  platform/chrome : Add myself as Maintainer

Eric Caruso (4):
  mfd: cros_ec: add debugfs, console log file
  platform/chrome: cros_ec_lightbar - Add lightbar program feature to sysfs
  platform/chrome: cros_ec_lightbar - Control of suspend/resume lightbar 
sequence
  platform/chrome: cros_ec_lightbar - Add userspace lightbar control bit to 
EC

Gwendal Grignou (4):
  mfd: cros_ec: Add helper for event notifier.
  platform/chrome: cros_ec_lpc: Add support for GOOG004 ACPI device
  platform/chrome: cros_ec_lpc: Add MKBP events support over ACPI
  cros_ec: Fix deadlock when EC is not responsive at probe

Jeffery Yu (1):
  platform/chrome: cros_ec_lightbar - Avoid I2C xfer to EC during suspend

Nicolas Boichat (2):
  mfd: cros_ec: Add EC console read structures definitions
  mfd: cros_ec: Add support for dumping panic information

Shawn Nematbakhsh (4):
  cros_ec_debugfs: Pass proper struct sizes to cros_ec_cmd_xfer()
  platform/chrome: cros_ec_lpc: Add R/W helpers to LPC protocol variants
  platform/chrome: cros_ec_lpc: Add support for mec1322 EC
  cros_ec: Don't signal wake event for non-wake host events

Thierry Escande (1):
  cros_ec: Don't return error when checking command version

 MAINTAINERS|   3 +-
 drivers/mfd/cros_ec.c  |  13 +-
 drivers/platform/chrome/Kconfig|  14 +-
 drivers/platform/chrome/Makefile   |   7 +-
 drivers/platform/chrome/cros_ec_debugfs.c  | 401 +
 drivers/platform/chrome/cros_ec_debugfs.h  |  27 ++
 drivers/platform/chrome/cros_ec_dev.c  |  40 +++
 drivers/platform/chrome/cros_ec_dev.h  |   6 +
 drivers/platform/chrome/cros_ec_lightbar.c | 197 +-
 drivers/platform/chrome/cros_ec_lpc.c  | 168 +++-
 drivers/platform/chrome/cros_ec_lpc_mec.c  | 140 ++
 drivers/platform/chrome/cros_ec_lpc_reg.c  | 133 ++
 drivers/platform/chrome/cros_ec_proto.c| 116 -
 include/linux/mfd/cros_ec.h|  19 +-
 include/linux/mfd/cros_ec_commands.h   |  42 ++-
 include/linux/mfd/cros_ec_lpc_mec.h|  90 +++
 include/linux/mfd/cros_ec_lpc_reg.h|  61 +
 17 files changed, 1393 insertions(+), 84 deletions(-)
 create mode 100644 drivers/platform/chrome/cros_ec_debugfs.c
 create mode 100644 drivers/platform/chrome/cros_ec_debugfs.h
 create mode 100644 drivers/platform/chrome/cros_ec_lpc_mec.c
 create mode 100644 drivers/platform/chrome/cros_ec_lpc_reg.c
 create mode 100644 include/linux/mfd/cros_ec_lpc_mec.h
 create mode 100644 include/linux/mfd/cros_ec_lpc_reg.h

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

[GIT PULL] chrome-platform updates for v4.13

[Benson Leung]

Hi Linus,

Please pull chrome-platform updates for Linux v4.13 from signed tag:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/chrome-platform-for-linus-4.13

Sorry for the delay on getting this into the merge window. My first
merge window as maintainer.

Thanks,
Benson

The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452:

  Linux 4.12-rc5 (2017-06-11 16:48:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/chrome-platform-for-linus-4.13

for you to fetch changes up to 3c778a7fcfaa4bb51aefb4f2c7364a5e2c4d0b66:

  platform/chrome : Add myself as Maintainer (2017-07-10 16:15:45 -0700)


chrome-platform-for-linus-4.13

Changes in this pull request are around catching up
cros_ec with the internal chromeos-kernel versions of
cros_ec, cros_ec_lpc, and cros_ec_lightbar.

Also, switching maintainership from olof to bleung.


Archana Patni (1):
  platform/chrome: cros_ec_lpc: Add power management ops

Arnd Bergmann (1):
  platform/chrome: cros_ec_lightbar - hide unused PM functions

Benson Leung (1):
  platform/chrome : Add myself as Maintainer

Eric Caruso (4):
  mfd: cros_ec: add debugfs, console log file
  platform/chrome: cros_ec_lightbar - Add lightbar program feature to sysfs
  platform/chrome: cros_ec_lightbar - Control of suspend/resume lightbar 
sequence
  platform/chrome: cros_ec_lightbar - Add userspace lightbar control bit to 
EC

Gwendal Grignou (4):
  mfd: cros_ec: Add helper for event notifier.
  platform/chrome: cros_ec_lpc: Add support for GOOG004 ACPI device
  platform/chrome: cros_ec_lpc: Add MKBP events support over ACPI
  cros_ec: Fix deadlock when EC is not responsive at probe

Jeffery Yu (1):
  platform/chrome: cros_ec_lightbar - Avoid I2C xfer to EC during suspend

Nicolas Boichat (2):
  mfd: cros_ec: Add EC console read structures definitions
  mfd: cros_ec: Add support for dumping panic information

Shawn Nematbakhsh (4):
  cros_ec_debugfs: Pass proper struct sizes to cros_ec_cmd_xfer()
  platform/chrome: cros_ec_lpc: Add R/W helpers to LPC protocol variants
  platform/chrome: cros_ec_lpc: Add support for mec1322 EC
  cros_ec: Don't signal wake event for non-wake host events

Thierry Escande (1):
  cros_ec: Don't return error when checking command version

 MAINTAINERS|   3 +-
 drivers/mfd/cros_ec.c  |  13 +-
 drivers/platform/chrome/Kconfig|  14 +-
 drivers/platform/chrome/Makefile   |   7 +-
 drivers/platform/chrome/cros_ec_debugfs.c  | 401 +
 drivers/platform/chrome/cros_ec_debugfs.h  |  27 ++
 drivers/platform/chrome/cros_ec_dev.c  |  40 +++
 drivers/platform/chrome/cros_ec_dev.h  |   6 +
 drivers/platform/chrome/cros_ec_lightbar.c | 197 +-
 drivers/platform/chrome/cros_ec_lpc.c  | 168 +++-
 drivers/platform/chrome/cros_ec_lpc_mec.c  | 140 ++
 drivers/platform/chrome/cros_ec_lpc_reg.c  | 133 ++
 drivers/platform/chrome/cros_ec_proto.c| 116 -
 include/linux/mfd/cros_ec.h|  19 +-
 include/linux/mfd/cros_ec_commands.h   |  42 ++-
 include/linux/mfd/cros_ec_lpc_mec.h|  90 +++
 include/linux/mfd/cros_ec_lpc_reg.h|  61 +
 17 files changed, 1393 insertions(+), 84 deletions(-)
 create mode 100644 drivers/platform/chrome/cros_ec_debugfs.c
 create mode 100644 drivers/platform/chrome/cros_ec_debugfs.h
 create mode 100644 drivers/platform/chrome/cros_ec_lpc_mec.c
 create mode 100644 drivers/platform/chrome/cros_ec_lpc_reg.c
 create mode 100644 include/linux/mfd/cros_ec_lpc_mec.h
 create mode 100644 include/linux/mfd/cros_ec_lpc_reg.h

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: Digital signature

[PATCH v3] staging: greybus: arche: wrap over-length lines

[Mitchell Tasman]

Adjust formatting of several comments to keep line length within
the 80 column limit preferred by the Linux kernel coding style.

Signed-off-by: Mitchell Tasman 
---
Changes in v3: Narrow scope of patch per Viresh Kumar's feedback
Changes in v2: Add back a missing space in a comment

 drivers/staging/greybus/arche-platform.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/greybus/arche-platform.c 
b/drivers/staging/greybus/arche-platform.c
index eced2d2..6259904 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -176,7 +176,10 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
*devid)

arche_platform_set_wake_detect_state(arche_pdata,
 
WD_STATE_IDLE);
} else {
-   /* Check we are not in middle of irq thread 
already */
+   /*
+* Check we are not in middle of irq thread
+* already
+*/
if (arche_pdata->wake_detect_state !=
WD_STATE_COLDBOOT_START) {

arche_platform_set_wake_detect_state(arche_pdata,
@@ -657,12 +660,14 @@ static SIMPLE_DEV_PM_OPS(arche_platform_pm_ops,
arche_platform_resume);
 
 static const struct of_device_id arche_platform_of_match[] = {
-   { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
device */
+   /* Use PID/VID of SVC device */
+   { .compatible = "google,arche-platform", },
{ },
 };
 
 static const struct of_device_id arche_combined_id[] = {
-   { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
device */
+   /* Use PID/VID of SVC device */
+   { .compatible = "google,arche-platform", },
{ .compatible = "usb,2", },
{ },
 };
-- 
2.9.3

[PATCH v3] staging: greybus: arche: wrap over-length lines

[Mitchell Tasman]

Adjust formatting of several comments to keep line length within
the 80 column limit preferred by the Linux kernel coding style.

Signed-off-by: Mitchell Tasman 
---
Changes in v3: Narrow scope of patch per Viresh Kumar's feedback
Changes in v2: Add back a missing space in a comment

 drivers/staging/greybus/arche-platform.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/greybus/arche-platform.c 
b/drivers/staging/greybus/arche-platform.c
index eced2d2..6259904 100644
--- a/drivers/staging/greybus/arche-platform.c
+++ b/drivers/staging/greybus/arche-platform.c
@@ -176,7 +176,10 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
*devid)

arche_platform_set_wake_detect_state(arche_pdata,
 
WD_STATE_IDLE);
} else {
-   /* Check we are not in middle of irq thread 
already */
+   /*
+* Check we are not in middle of irq thread
+* already
+*/
if (arche_pdata->wake_detect_state !=
WD_STATE_COLDBOOT_START) {

arche_platform_set_wake_detect_state(arche_pdata,
@@ -657,12 +660,14 @@ static SIMPLE_DEV_PM_OPS(arche_platform_pm_ops,
arche_platform_resume);
 
 static const struct of_device_id arche_platform_of_match[] = {
-   { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
device */
+   /* Use PID/VID of SVC device */
+   { .compatible = "google,arche-platform", },
{ },
 };
 
 static const struct of_device_id arche_combined_id[] = {
-   { .compatible = "google,arche-platform", }, /* Use PID/VID of SVC 
device */
+   /* Use PID/VID of SVC device */
+   { .compatible = "google,arche-platform", },
{ .compatible = "usb,2", },
{ },
 };
-- 
2.9.3

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Jin, Yao]

On 7/11/2017 10:28 AM, Michael Ellerman wrote:

"Jin, Yao"  writes:


On 7/10/2017 9:46 PM, Peter Zijlstra wrote:

On Mon, Jul 10, 2017 at 08:10:50AM -0500, Segher Boessenkool wrote:


PERF_BR_INT is triggered by instruction "int" .
PERF_BR_IRQ is triggered by interrupts, traps, faults (the ring 0,3
transition).

So your "PERF_BR_INT" is a system call?

The "INT" thing has indeed been used as system call mechanism (typically
INT 80). But these days we have special purpose syscall instructions.

It could maybe be compared to the PPC "Unconditional TRAP with
immediate" where you use the immediate value as an index into a handler
vector.


And PERF_BR_IRQ is not an interrupt request (as its name suggests),
not what we call an "external interrupt" either; instead it is every
interrupt that is not a system call?

It is actual interrupts, but also faults, traps and all the other
exceptions not caused by "INT" I think.


Yes. It's interrupt, traps, faults. If from is in the user space and to
is in the kernel, it indicates the ring3 -> ring0 transition.

If the from instruction is not syscall or other ring transition
instruction, it should be interrupt, traps and faults. That's how we get
the PERF_BR_IRQ on x86.

Anyway, maybe we just use a minimum but the most common set of branch
types now, it could be a good start and acceptable on all architectures.

PERF_BR_COND= 1,/* conditional */
PERF_BR_UNCOND= 2,/* unconditional */
PERF_BR_IND= 3,/* indirect */
PERF_BR_CALL= 4,/* call */
PERF_BR_IND_CALL= 5,/* indirect call */
PERF_BR_RET= 6,/* return */

That would be fine by me, if you're sick of talking about it and just
want to get it merged :)

:)


I think you could expand it a bit, this list would cover the vast bulk
of branch types for us:

   PERF_BR_COND /* Conditional */
   PERF_BR_UNCOND   /* Unconditional */
   PERF_BR_IND  /* Indirect */
   PERF_BR_CALL /* Function call */
   PERF_BR_IND_CALL /* Indirect function call */
   PERF_BR_RET  /* Function return */
   PERF_BR_SYSCALL  /* Syscall */
   PERF_BR_SYSRET   /* Syscall return */
   PERF_BR_COND_CALL/* Conditional function call */
   PERF_BR_COND_RET /* Conditional function return */

cheers


OK, accept! Use 4 bits for above branch types and we can reserve 5 for 
potential future types.


Thanks
Jin Yao

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Jin, Yao]

On 7/11/2017 10:28 AM, Michael Ellerman wrote:

"Jin, Yao"  writes:


On 7/10/2017 9:46 PM, Peter Zijlstra wrote:

On Mon, Jul 10, 2017 at 08:10:50AM -0500, Segher Boessenkool wrote:


PERF_BR_INT is triggered by instruction "int" .
PERF_BR_IRQ is triggered by interrupts, traps, faults (the ring 0,3
transition).

So your "PERF_BR_INT" is a system call?

The "INT" thing has indeed been used as system call mechanism (typically
INT 80). But these days we have special purpose syscall instructions.

It could maybe be compared to the PPC "Unconditional TRAP with
immediate" where you use the immediate value as an index into a handler
vector.


And PERF_BR_IRQ is not an interrupt request (as its name suggests),
not what we call an "external interrupt" either; instead it is every
interrupt that is not a system call?

It is actual interrupts, but also faults, traps and all the other
exceptions not caused by "INT" I think.


Yes. It's interrupt, traps, faults. If from is in the user space and to
is in the kernel, it indicates the ring3 -> ring0 transition.

If the from instruction is not syscall or other ring transition
instruction, it should be interrupt, traps and faults. That's how we get
the PERF_BR_IRQ on x86.

Anyway, maybe we just use a minimum but the most common set of branch
types now, it could be a good start and acceptable on all architectures.

PERF_BR_COND= 1,/* conditional */
PERF_BR_UNCOND= 2,/* unconditional */
PERF_BR_IND= 3,/* indirect */
PERF_BR_CALL= 4,/* call */
PERF_BR_IND_CALL= 5,/* indirect call */
PERF_BR_RET= 6,/* return */

That would be fine by me, if you're sick of talking about it and just
want to get it merged :)

:)


I think you could expand it a bit, this list would cover the vast bulk
of branch types for us:

   PERF_BR_COND /* Conditional */
   PERF_BR_UNCOND   /* Unconditional */
   PERF_BR_IND  /* Indirect */
   PERF_BR_CALL /* Function call */
   PERF_BR_IND_CALL /* Indirect function call */
   PERF_BR_RET  /* Function return */
   PERF_BR_SYSCALL  /* Syscall */
   PERF_BR_SYSRET   /* Syscall return */
   PERF_BR_COND_CALL/* Conditional function call */
   PERF_BR_COND_RET /* Conditional function return */

cheers


OK, accept! Use 4 bits for above branch types and we can reserve 5 for 
potential future types.


Thanks
Jin Yao

Re: [PATCH v2 4/8] objtool: add undwarf debuginfo generation

[Josh Poimboeuf]

On Fri, Jul 07, 2017 at 11:44:37AM +0200, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  wrote:
> 
> > On Thu, Jun 29, 2017 at 10:06:52AM -0500, Josh Poimboeuf wrote:
> > > On Thu, Jun 29, 2017 at 04:46:18PM +0200, Ingo Molnar wrote:
> > > > 
> > > > * Josh Poimboeuf  wrote:
> > > > 
> > > > > > Plus, shouldn't we use __packed for 'struct undwarf' to minimize 
> > > > > > the 
> > > > > > structure's size (to 6 bytes AFAICS?) - or is optimal packing of 
> > > > > > the main 
> > > > > > undwarf array already guaranteed on every platform with this layout?
> > > > > 
> > > > > Ah yes, it should definitely be packed (assuming that doesn't affect 
> > > > > performance 
> > > > > negatively).
> > > > 
> > > > So if I count that correctly that should shave another ~1MB off a 
> > > > typical ~4MB 
> > > > table size?
> > > 
> > > Here's what my Fedora kernel looks like *before* the packed change:
> > > 
> > >   $ eu-readelf -S vmlinux |grep undwarf
> > >   [15] .undwarf_ip  PROGBITS 81f776d0 011776d0 
> > > 0012d9d0  0 A  0   0  1
> > >   [16] .undwarf PROGBITS 820a50a0 012a50a0 
> > > 0025b3a0  0 A  0   0  1
> > > 
> > > The total undwarf data size is ~3.5MB.
> > > 
> > > There are 308852 entries of two parallel arrays:
> > > 
> > > * .undwarf(8 bytes/entry) = 2470816 bytes
> > > * .undwarf_ip (4 bytes/entry) = 1235408 bytes
> > > 
> > > If we pack undwarf, reducing the size of the .undwarf entries by two
> > > bytes, it will save 308852 * 2 = 617704.
> > > 
> > > So the savings will be ~600k, and the typical size will be reduced to 
> > > ~3MB.
> > 
> > Just for the record, while packing the struct from 8 to 6 bytes did save 
> > 600k, 
> > it also made the unwinder ~7% slower.  I think that's probably an ok 
> > tradeoff, 
> > so I'll leave it packed in v3.
> 
> So, out of curiosity, I'm wondering where that slowdown comes from: on modern 
> x86 
> CPUs indexing by units of 6 bytes ought to be just as fast as indexing by 8 
> bytes, 
> unless I'm missing something? Is it maybe the not naturally aligned 32-bit 
> words?
> 
> Or maybe there's some bad case of a 32-bit word crossing a 64-byte cache line 
> boundary that hits some pathological aspect of the CPU? We could probably get 
> around any such problems by padding by 2 bytes on 64-byte boundaries - that's 
> only 
> a ~3% data size increase. The flip side would be a complication of the data 
> structure and its accessors - which might cost more in terms of code 
> generation 
> efficiency than it buys us to begin with ...
> 
> Also, there's another aspect besides RAM footprint: a large data structure 
> that is 
> ~20% smaller means 20% less cache footprint: which for cache cold lookups 
> might 
> matter more than the direct computational cost.

tl;dr: Packed really seems to be more like ~2% slower, time for an adult
beverage.

So I tested again with the latest version of my code, and this time
packed was 5% *faster* than unpacked, rather than 7% slower.  'perf
stat' showed that, in both cases, most of the difference was caused by
branch misses in the binary search code.  But that code doesn't even
touch the packed struct...

After some hair-pulling/hand-wringing I realized that changing the
struct packing caused GCC to change some of the unwinder code a bit,
which shifted the rest of the kernel's function offsets enough that it
changed the behavior of the unwind table binary search in a way that
affected the CPU's branch prediction.  And my crude benchmark was just
unwinding the same stack on repeat, so a small change in the loop
behavior had a big impact on the overall branch predictability.

Anyway, I used some linker magic to temporarily move the unwinder code
to the end of .text, so that unwinder changes don't add unexpected side
effects to the microbenchmark behavior.  Now I'm getting more consistent
results: the packed struct is measuring ~2% slower.  The slight slowdown
might just be explained by the fact that GCC generates some extra
instructions for extracting the fields out of the packed struct.

In the meantime, I found a ~10% speedup by making the "fast lookup
table" block size a power-of-two (256) to get rid of the need for a slow
'div' instruction.

I think I'm done performance tweaking for now.  I'll keep the packed
struct, and add the code for the 'div' removal, and hope to submit v3
soon.

-- 
Josh

Re: [PATCH v2 4/8] objtool: add undwarf debuginfo generation

[Josh Poimboeuf]

On Fri, Jul 07, 2017 at 11:44:37AM +0200, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  wrote:
> 
> > On Thu, Jun 29, 2017 at 10:06:52AM -0500, Josh Poimboeuf wrote:
> > > On Thu, Jun 29, 2017 at 04:46:18PM +0200, Ingo Molnar wrote:
> > > > 
> > > > * Josh Poimboeuf  wrote:
> > > > 
> > > > > > Plus, shouldn't we use __packed for 'struct undwarf' to minimize 
> > > > > > the 
> > > > > > structure's size (to 6 bytes AFAICS?) - or is optimal packing of 
> > > > > > the main 
> > > > > > undwarf array already guaranteed on every platform with this layout?
> > > > > 
> > > > > Ah yes, it should definitely be packed (assuming that doesn't affect 
> > > > > performance 
> > > > > negatively).
> > > > 
> > > > So if I count that correctly that should shave another ~1MB off a 
> > > > typical ~4MB 
> > > > table size?
> > > 
> > > Here's what my Fedora kernel looks like *before* the packed change:
> > > 
> > >   $ eu-readelf -S vmlinux |grep undwarf
> > >   [15] .undwarf_ip  PROGBITS 81f776d0 011776d0 
> > > 0012d9d0  0 A  0   0  1
> > >   [16] .undwarf PROGBITS 820a50a0 012a50a0 
> > > 0025b3a0  0 A  0   0  1
> > > 
> > > The total undwarf data size is ~3.5MB.
> > > 
> > > There are 308852 entries of two parallel arrays:
> > > 
> > > * .undwarf(8 bytes/entry) = 2470816 bytes
> > > * .undwarf_ip (4 bytes/entry) = 1235408 bytes
> > > 
> > > If we pack undwarf, reducing the size of the .undwarf entries by two
> > > bytes, it will save 308852 * 2 = 617704.
> > > 
> > > So the savings will be ~600k, and the typical size will be reduced to 
> > > ~3MB.
> > 
> > Just for the record, while packing the struct from 8 to 6 bytes did save 
> > 600k, 
> > it also made the unwinder ~7% slower.  I think that's probably an ok 
> > tradeoff, 
> > so I'll leave it packed in v3.
> 
> So, out of curiosity, I'm wondering where that slowdown comes from: on modern 
> x86 
> CPUs indexing by units of 6 bytes ought to be just as fast as indexing by 8 
> bytes, 
> unless I'm missing something? Is it maybe the not naturally aligned 32-bit 
> words?
> 
> Or maybe there's some bad case of a 32-bit word crossing a 64-byte cache line 
> boundary that hits some pathological aspect of the CPU? We could probably get 
> around any such problems by padding by 2 bytes on 64-byte boundaries - that's 
> only 
> a ~3% data size increase. The flip side would be a complication of the data 
> structure and its accessors - which might cost more in terms of code 
> generation 
> efficiency than it buys us to begin with ...
> 
> Also, there's another aspect besides RAM footprint: a large data structure 
> that is 
> ~20% smaller means 20% less cache footprint: which for cache cold lookups 
> might 
> matter more than the direct computational cost.

tl;dr: Packed really seems to be more like ~2% slower, time for an adult
beverage.

So I tested again with the latest version of my code, and this time
packed was 5% *faster* than unpacked, rather than 7% slower.  'perf
stat' showed that, in both cases, most of the difference was caused by
branch misses in the binary search code.  But that code doesn't even
touch the packed struct...

After some hair-pulling/hand-wringing I realized that changing the
struct packing caused GCC to change some of the unwinder code a bit,
which shifted the rest of the kernel's function offsets enough that it
changed the behavior of the unwind table binary search in a way that
affected the CPU's branch prediction.  And my crude benchmark was just
unwinding the same stack on repeat, so a small change in the loop
behavior had a big impact on the overall branch predictability.

Anyway, I used some linker magic to temporarily move the unwinder code
to the end of .text, so that unwinder changes don't add unexpected side
effects to the microbenchmark behavior.  Now I'm getting more consistent
results: the packed struct is measuring ~2% slower.  The slight slowdown
might just be explained by the fact that GCC generates some extra
instructions for extracting the fields out of the packed struct.

In the meantime, I found a ~10% speedup by making the "fast lookup
table" block size a power-of-two (256) to get rid of the need for a slow
'div' instruction.

I think I'm done performance tweaking for now.  I'll keep the packed
struct, and add the code for the 'div' removal, and hope to submit v3
soon.

-- 
Josh

Re: [PATCH v2 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Rob Herring]

On Sun, Jul 09, 2017 at 08:40:05PM +0300, Vladimir Barinov wrote:
> From: Vladimir Barinov 
> 
> IDT VersaClock 5 5P49V5925 has 5 clock outputs, 4 fractional dividers.
> Input clock source can be taken only from external reference clock.
> 
> Signed-off-by: Vladimir Barinov 
> ---
> Changes in version 2:
> - fixed typo in patch header: VC5 has 5 clock outputs
> - rebased against patch:
>   [V3,7/8] clk: vc5: Add bindings for IDT VersaClock 5P49V6901
> 
>  Documentation/devicetree/bindings/clock/idt,versaclock5.txt | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v2 2/2] dt: Add bindings for IDT VersaClock 5P49V5925

[Rob Herring]

On Sun, Jul 09, 2017 at 08:40:05PM +0300, Vladimir Barinov wrote:
> From: Vladimir Barinov 
> 
> IDT VersaClock 5 5P49V5925 has 5 clock outputs, 4 fractional dividers.
> Input clock source can be taken only from external reference clock.
> 
> Signed-off-by: Vladimir Barinov 
> ---
> Changes in version 2:
> - fixed typo in patch header: VC5 has 5 clock outputs
> - rebased against patch:
>   [V3,7/8] clk: vc5: Add bindings for IDT VersaClock 5P49V6901
> 
>  Documentation/devicetree/bindings/clock/idt,versaclock5.txt | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v4 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC

[Eddie Huang]

Hi Sean,

On Mon, 2017-07-10 at 22:23 +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with
> single cluster and this hardware is also compatible with the existing
> driver through enabling CPU frequency feature with operating-points-v2
> bindings. Also, this driver actually supports all MediaTek SoCs, the
> Kconfig menu entry and file name itself should be updated with more
> generic name to drop "MT8173"
> 
> Signed-off-by: Sean Wang 
> Acked-by: Viresh Kumar 
> Reviewed-by: Jean Delvare 
> ---
>  drivers/cpufreq/Kconfig.arm  | 7 +++
>  drivers/cpufreq/Makefile | 2 +-
>  drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} | 2 ++
>  3 files changed, 6 insertions(+), 5 deletions(-)
>  rename drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} (99%)
> 

As Viresh mentioned, there are already many drivers use "mtk" as
filename prefix or postfix.To align with those files, I suggest use
mtk-cpufreq.c.I think there are not too many values to change all "mtk-"
to "mediatek-", but it is worth to have the same naming rule for
mediatek upstream driver.

Regards,
Eddie. 

Re: [PATCH v4 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC

[Eddie Huang]

Hi Sean,

On Mon, 2017-07-10 at 22:23 +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with
> single cluster and this hardware is also compatible with the existing
> driver through enabling CPU frequency feature with operating-points-v2
> bindings. Also, this driver actually supports all MediaTek SoCs, the
> Kconfig menu entry and file name itself should be updated with more
> generic name to drop "MT8173"
> 
> Signed-off-by: Sean Wang 
> Acked-by: Viresh Kumar 
> Reviewed-by: Jean Delvare 
> ---
>  drivers/cpufreq/Kconfig.arm  | 7 +++
>  drivers/cpufreq/Makefile | 2 +-
>  drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} | 2 ++
>  3 files changed, 6 insertions(+), 5 deletions(-)
>  rename drivers/cpufreq/{mt8173-cpufreq.c => mediatek-cpufreq.c} (99%)
> 

As Viresh mentioned, there are already many drivers use "mtk" as
filename prefix or postfix.To align with those files, I suggest use
mtk-cpufreq.c.I think there are not too many values to change all "mtk-"
to "mediatek-", but it is worth to have the same naming rule for
mediatek upstream driver.

Regards,
Eddie. 

Re: [PATCH RFC 0/2] KVM: x86: Support using the VMX preemption timer for APIC Timer periodic/oneshot mode

[Wanpeng Li]

2017-07-11 8:13 GMT+08:00 Andy Lutomirski :
> On 10/11/2016 05:17 AM, Wanpeng Li wrote:
>>
>> Most windows guests which I have on hand currently still utilize APIC
>> Timer
>> periodic/oneshot mode instead of APIC Timer tsc-deadline mode:
>> - windows 2008 server r2
>> - windows 2012 server r2
>> - windows 7
>> - windows 10
>>
>> This patchset adds the support using the VMX preemption timer for APIC
>> Timer
>> periodic/oneshot mode.
>>
>> I add a print in oneshot mode testcase of kvm-unit-tests/apic.flat and
>> observed
>> that w/ patch the latency is ~2% of w/o patch. I think maybe something is
>> still
>> not right in the patchset, in addition, tmcct in apic_get_tmcct() maybe is
>> not
>> calculated correctly. Your comments to improve the patchset is a great
>> appreciated.
>>
>> Wanpeng Li (2):
>>KVM: lapic: Extract start_sw_period() to handle oneshot/periodic mode
>>KVM: x86: Support using the vmx preemption timer for APIC Timer
>> periodic/one mode
>>
>>   arch/x86/kvm/lapic.c | 162
>> ++-
>>   1 file changed, 95 insertions(+), 67 deletions(-)
>>
>
> I think this is a step in the right direction, but I think there's a
> different approach that would be much, much faster: use the VMX preemption
> timer for *host* preemption.  Specifically, do this:

Yeah, I agreed.

>
> 1. Refactor the host TSC deadline timer a bit to allow the TSC deadline
> timer to be "borrow".  It might look something like this:
>
> u64 borrow_tsc_deadline(void (*timer_callback)());
>
> The caller is now permitted to use the TSC deadline timer for its own
> nefarious purposes.  The caller promises to call return_tsc_deadline() in a
> timely manner if the TSC exceeds the return value while the deadline timer
> is borrowed.
>
> If the TSC deadline fires while it's borrowed, timer_callback() will be
> called.
>
> void return_tsc_deadline(bool timer_fired);
>
> The caller is done borrowing the TSC deadline timer.  The caller need not
> reset the TSC deadline timer MSR to its previous value before calling this.
> It must be called with IRQs on and preemption off.
>
> Getting this to work cleanly without races may be a bit tricky.  So be it.
>
> 2. Teach KVM to use the VMX preemption timer as a substitute deadline timer
> while in guest mode.  Specifically, KVM will borrow_tsc_deadline() (if TSC
> deadline is enabled) when entering guest mode and return_tsc_deadline() when
> returning out of guest mode.
>
> 3. Now KVM can change its MSR bitmaps to allow the guest to program the TSC
> deadline MSR directly.  No exit at all needed to handle guest writes to the
> deadline timer.
>
>
> Tglx, etc, would this be even remotely acceptable?  I'm not personally
> touching this code with a ten-foot pole, but there seem to be plenty of
> people who really care about performance here.

Sigh, I heard the same idea from a company called Huawei, they applied
the patent for the idea.

Regard,
Wanpeng Li

Re: [PATCH RFC 0/2] KVM: x86: Support using the VMX preemption timer for APIC Timer periodic/oneshot mode

[Wanpeng Li]

2017-07-11 8:13 GMT+08:00 Andy Lutomirski :
> On 10/11/2016 05:17 AM, Wanpeng Li wrote:
>>
>> Most windows guests which I have on hand currently still utilize APIC
>> Timer
>> periodic/oneshot mode instead of APIC Timer tsc-deadline mode:
>> - windows 2008 server r2
>> - windows 2012 server r2
>> - windows 7
>> - windows 10
>>
>> This patchset adds the support using the VMX preemption timer for APIC
>> Timer
>> periodic/oneshot mode.
>>
>> I add a print in oneshot mode testcase of kvm-unit-tests/apic.flat and
>> observed
>> that w/ patch the latency is ~2% of w/o patch. I think maybe something is
>> still
>> not right in the patchset, in addition, tmcct in apic_get_tmcct() maybe is
>> not
>> calculated correctly. Your comments to improve the patchset is a great
>> appreciated.
>>
>> Wanpeng Li (2):
>>KVM: lapic: Extract start_sw_period() to handle oneshot/periodic mode
>>KVM: x86: Support using the vmx preemption timer for APIC Timer
>> periodic/one mode
>>
>>   arch/x86/kvm/lapic.c | 162
>> ++-
>>   1 file changed, 95 insertions(+), 67 deletions(-)
>>
>
> I think this is a step in the right direction, but I think there's a
> different approach that would be much, much faster: use the VMX preemption
> timer for *host* preemption.  Specifically, do this:

Yeah, I agreed.

>
> 1. Refactor the host TSC deadline timer a bit to allow the TSC deadline
> timer to be "borrow".  It might look something like this:
>
> u64 borrow_tsc_deadline(void (*timer_callback)());
>
> The caller is now permitted to use the TSC deadline timer for its own
> nefarious purposes.  The caller promises to call return_tsc_deadline() in a
> timely manner if the TSC exceeds the return value while the deadline timer
> is borrowed.
>
> If the TSC deadline fires while it's borrowed, timer_callback() will be
> called.
>
> void return_tsc_deadline(bool timer_fired);
>
> The caller is done borrowing the TSC deadline timer.  The caller need not
> reset the TSC deadline timer MSR to its previous value before calling this.
> It must be called with IRQs on and preemption off.
>
> Getting this to work cleanly without races may be a bit tricky.  So be it.
>
> 2. Teach KVM to use the VMX preemption timer as a substitute deadline timer
> while in guest mode.  Specifically, KVM will borrow_tsc_deadline() (if TSC
> deadline is enabled) when entering guest mode and return_tsc_deadline() when
> returning out of guest mode.
>
> 3. Now KVM can change its MSR bitmaps to allow the guest to program the TSC
> deadline MSR directly.  No exit at all needed to handle guest writes to the
> deadline timer.
>
>
> Tglx, etc, would this be even remotely acceptable?  I'm not personally
> touching this code with a ten-foot pole, but there seem to be plenty of
> people who really care about performance here.

Sigh, I heard the same idea from a company called Huawei, they applied
the patent for the idea.

Regard,
Wanpeng Li

[PATCH] clk: mediatek: fixed static checker warning in clk_cpumux_get_parent call

[sean.wang]

From: Sean Wang 

Fixed the signedness bug returning '(-22)' on the return type as u8 with
moving the sanity checker into clk_cpumux_set_parent() to ensure always
validity in clk_cpumux_get_parent() got called.

Fixes: commit 1e17de9049da ("clk: mediatek: add missing cpu mux causing 
Mediatek cpufreq can't work")
Reported-by: Dan Carpenter 
Signed-off-by: Sean Wang 
---
 drivers/clk/mediatek/clk-cpumux.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/mediatek/clk-cpumux.c 
b/drivers/clk/mediatek/clk-cpumux.c
index edd8e69..c6a3a1a 100644
--- a/drivers/clk/mediatek/clk-cpumux.c
+++ b/drivers/clk/mediatek/clk-cpumux.c
@@ -27,7 +27,6 @@ static inline struct mtk_clk_cpumux *to_mtk_clk_cpumux(struct 
clk_hw *_hw)
 static u8 clk_cpumux_get_parent(struct clk_hw *hw)
 {
struct mtk_clk_cpumux *mux = to_mtk_clk_cpumux(hw);
-   int num_parents = clk_hw_get_num_parents(hw);
unsigned int val;
 
regmap_read(mux->regmap, mux->reg, );
@@ -35,17 +34,18 @@ static u8 clk_cpumux_get_parent(struct clk_hw *hw)
val >>= mux->shift;
val &= mux->mask;
 
-   if (val >= num_parents)
-   return -EINVAL;
-
return val;
 }
 
 static int clk_cpumux_set_parent(struct clk_hw *hw, u8 index)
 {
struct mtk_clk_cpumux *mux = to_mtk_clk_cpumux(hw);
+   int num_parents = clk_hw_get_num_parents(hw);
u32 mask, val;
 
+   if (index >= num_parents)
+   return -EINVAL;
+
val = index << mux->shift;
mask = mux->mask << mux->shift;
 
-- 
2.7.4

[PATCH] clk: mediatek: fixed static checker warning in clk_cpumux_get_parent call

[sean.wang]

From: Sean Wang 

Fixed the signedness bug returning '(-22)' on the return type as u8 with
moving the sanity checker into clk_cpumux_set_parent() to ensure always
validity in clk_cpumux_get_parent() got called.

Fixes: commit 1e17de9049da ("clk: mediatek: add missing cpu mux causing 
Mediatek cpufreq can't work")
Reported-by: Dan Carpenter 
Signed-off-by: Sean Wang 
---
 drivers/clk/mediatek/clk-cpumux.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/mediatek/clk-cpumux.c 
b/drivers/clk/mediatek/clk-cpumux.c
index edd8e69..c6a3a1a 100644
--- a/drivers/clk/mediatek/clk-cpumux.c
+++ b/drivers/clk/mediatek/clk-cpumux.c
@@ -27,7 +27,6 @@ static inline struct mtk_clk_cpumux *to_mtk_clk_cpumux(struct 
clk_hw *_hw)
 static u8 clk_cpumux_get_parent(struct clk_hw *hw)
 {
struct mtk_clk_cpumux *mux = to_mtk_clk_cpumux(hw);
-   int num_parents = clk_hw_get_num_parents(hw);
unsigned int val;
 
regmap_read(mux->regmap, mux->reg, );
@@ -35,17 +34,18 @@ static u8 clk_cpumux_get_parent(struct clk_hw *hw)
val >>= mux->shift;
val &= mux->mask;
 
-   if (val >= num_parents)
-   return -EINVAL;
-
return val;
 }
 
 static int clk_cpumux_set_parent(struct clk_hw *hw, u8 index)
 {
struct mtk_clk_cpumux *mux = to_mtk_clk_cpumux(hw);
+   int num_parents = clk_hw_get_num_parents(hw);
u32 mask, val;
 
+   if (index >= num_parents)
+   return -EINVAL;
+
val = index << mux->shift;
mask = mux->mask << mux->shift;
 
-- 
2.7.4

Re: [PATCH v2 1/3] of: overlay: add overlay unittest data for node names and symbols

[Rob Herring]

On Mon, Jul 10, 2017 at 2:05 PM,   wrote:
> From: Frank Rowand 
>
> Add nodes and properties to overlay_base and overlay dts files to
> test for
>- incorrect existing node name detection when overlay node name
>  has a unit-address
>- adding overlay __symbols__ properties to live tree when an
>  overlay is added to the live tree
>
> Expected result from patch 2/3 is overlay will update the nodes and
> properties for /testcase-data-2/fairway-1/ride@100/
>
> Before patch 2/3 is applied:

This is good information, but what is patch 2/3 is less clear when
this is committed. And 1 and 2 are probably stable material? I'd just
note in this patch what the failures are and show before and after
results in the patch that changes them.

>Console error message near end of unittest:
>   OF: Duplicate name in fairway-1, renamed to "ride@100#1"
>
>$ cd /proc/device-tree/testcase-data-2/fairway-1/
>$ # extra node: ride@100#1
>$ ls
>#address-cells  linux,phandle   phandle ride@200
>#size-cells nameride@100status
>compatible  orientation ride@100#1
>$ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/
>$ ls track@3/incline_up
>ls: track@3/incline_up: No such file or directory
>$ ls track@4/incline_up
>ls: track@4/incline_up: No such file or directory

[...]

> diff --git a/drivers/of/unittest-data/Makefile 
> b/drivers/of/unittest-data/Makefile
> index 6e00a9c69e58..dae2fe23cd2e 100644
> --- a/drivers/of/unittest-data/Makefile
> +++ b/drivers/of/unittest-data/Makefile
> @@ -1,11 +1,13 @@
>  obj-y += testcases.dtb.o
>  obj-y += overlay.dtb.o
>  obj-y += overlay_bad_phandle.dtb.o
> +obj-y += overlay_bad_symbol.dtb.o
>  obj-y += overlay_base.dtb.o

There's no reason for these all to be 1 per line. Also, should the
overlay dtb's be conditioned on CONFIG_OF_OVERLAY (or whatever we call
it)?

But this is fine. That can all be a followup patch.

Re: [PATCH v2 1/3] of: overlay: add overlay unittest data for node names and symbols

[Rob Herring]

On Mon, Jul 10, 2017 at 2:05 PM,   wrote:
> From: Frank Rowand 
>
> Add nodes and properties to overlay_base and overlay dts files to
> test for
>- incorrect existing node name detection when overlay node name
>  has a unit-address
>- adding overlay __symbols__ properties to live tree when an
>  overlay is added to the live tree
>
> Expected result from patch 2/3 is overlay will update the nodes and
> properties for /testcase-data-2/fairway-1/ride@100/
>
> Before patch 2/3 is applied:

This is good information, but what is patch 2/3 is less clear when
this is committed. And 1 and 2 are probably stable material? I'd just
note in this patch what the failures are and show before and after
results in the patch that changes them.

>Console error message near end of unittest:
>   OF: Duplicate name in fairway-1, renamed to "ride@100#1"
>
>$ cd /proc/device-tree/testcase-data-2/fairway-1/
>$ # extra node: ride@100#1
>$ ls
>#address-cells  linux,phandle   phandle ride@200
>#size-cells nameride@100status
>compatible  orientation ride@100#1
>$ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/
>$ ls track@3/incline_up
>ls: track@3/incline_up: No such file or directory
>$ ls track@4/incline_up
>ls: track@4/incline_up: No such file or directory

[...]

> diff --git a/drivers/of/unittest-data/Makefile 
> b/drivers/of/unittest-data/Makefile
> index 6e00a9c69e58..dae2fe23cd2e 100644
> --- a/drivers/of/unittest-data/Makefile
> +++ b/drivers/of/unittest-data/Makefile
> @@ -1,11 +1,13 @@
>  obj-y += testcases.dtb.o
>  obj-y += overlay.dtb.o
>  obj-y += overlay_bad_phandle.dtb.o
> +obj-y += overlay_bad_symbol.dtb.o
>  obj-y += overlay_base.dtb.o

There's no reason for these all to be 1 per line. Also, should the
overlay dtb's be conditioned on CONFIG_OF_OVERLAY (or whatever we call
it)?

But this is fine. That can all be a followup patch.

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Michael Ellerman]

"Jin, Yao"  writes:

> On 7/10/2017 9:46 PM, Peter Zijlstra wrote:
>> On Mon, Jul 10, 2017 at 08:10:50AM -0500, Segher Boessenkool wrote:
>>
 PERF_BR_INT is triggered by instruction "int" .
 PERF_BR_IRQ is triggered by interrupts, traps, faults (the ring 0,3
 transition).
>>> So your "PERF_BR_INT" is a system call?
>> The "INT" thing has indeed been used as system call mechanism (typically
>> INT 80). But these days we have special purpose syscall instructions.
>>
>> It could maybe be compared to the PPC "Unconditional TRAP with
>> immediate" where you use the immediate value as an index into a handler
>> vector.
>>
>>> And PERF_BR_IRQ is not an interrupt request (as its name suggests),
>>> not what we call an "external interrupt" either; instead it is every
>>> interrupt that is not a system call?
>> It is actual interrupts, but also faults, traps and all the other
>> exceptions not caused by "INT" I think.
>>
> Yes. It's interrupt, traps, faults. If from is in the user space and to 
> is in the kernel, it indicates the ring3 -> ring0 transition.
>
> If the from instruction is not syscall or other ring transition 
> instruction, it should be interrupt, traps and faults. That's how we get 
> the PERF_BR_IRQ on x86.
>
> Anyway, maybe we just use a minimum but the most common set of branch 
> types now, it could be a good start and acceptable on all architectures.
>
> PERF_BR_COND= 1,/* conditional */
> PERF_BR_UNCOND= 2,/* unconditional */
> PERF_BR_IND= 3,/* indirect */
> PERF_BR_CALL= 4,/* call */
> PERF_BR_IND_CALL= 5,/* indirect call */
> PERF_BR_RET= 6,/* return */

That would be fine by me, if you're sick of talking about it and just
want to get it merged :)

I think you could expand it a bit, this list would cover the vast bulk
of branch types for us:

  PERF_BR_COND  /* Conditional */
  PERF_BR_UNCOND/* Unconditional */
  PERF_BR_IND   /* Indirect */
  PERF_BR_CALL  /* Function call */
  PERF_BR_IND_CALL  /* Indirect function call */
  PERF_BR_RET   /* Function return */
  PERF_BR_SYSCALL   /* Syscall */
  PERF_BR_SYSRET/* Syscall return */
  PERF_BR_COND_CALL /* Conditional function call */
  PERF_BR_COND_RET  /* Conditional function return */

cheers

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Michael Ellerman]

"Jin, Yao"  writes:

> On 7/10/2017 9:46 PM, Peter Zijlstra wrote:
>> On Mon, Jul 10, 2017 at 08:10:50AM -0500, Segher Boessenkool wrote:
>>
 PERF_BR_INT is triggered by instruction "int" .
 PERF_BR_IRQ is triggered by interrupts, traps, faults (the ring 0,3
 transition).
>>> So your "PERF_BR_INT" is a system call?
>> The "INT" thing has indeed been used as system call mechanism (typically
>> INT 80). But these days we have special purpose syscall instructions.
>>
>> It could maybe be compared to the PPC "Unconditional TRAP with
>> immediate" where you use the immediate value as an index into a handler
>> vector.
>>
>>> And PERF_BR_IRQ is not an interrupt request (as its name suggests),
>>> not what we call an "external interrupt" either; instead it is every
>>> interrupt that is not a system call?
>> It is actual interrupts, but also faults, traps and all the other
>> exceptions not caused by "INT" I think.
>>
> Yes. It's interrupt, traps, faults. If from is in the user space and to 
> is in the kernel, it indicates the ring3 -> ring0 transition.
>
> If the from instruction is not syscall or other ring transition 
> instruction, it should be interrupt, traps and faults. That's how we get 
> the PERF_BR_IRQ on x86.
>
> Anyway, maybe we just use a minimum but the most common set of branch 
> types now, it could be a good start and acceptable on all architectures.
>
> PERF_BR_COND= 1,/* conditional */
> PERF_BR_UNCOND= 2,/* unconditional */
> PERF_BR_IND= 3,/* indirect */
> PERF_BR_CALL= 4,/* call */
> PERF_BR_IND_CALL= 5,/* indirect call */
> PERF_BR_RET= 6,/* return */

That would be fine by me, if you're sick of talking about it and just
want to get it merged :)

I think you could expand it a bit, this list would cover the vast bulk
of branch types for us:

  PERF_BR_COND  /* Conditional */
  PERF_BR_UNCOND/* Unconditional */
  PERF_BR_IND   /* Indirect */
  PERF_BR_CALL  /* Function call */
  PERF_BR_IND_CALL  /* Indirect function call */
  PERF_BR_RET   /* Function return */
  PERF_BR_SYSCALL   /* Syscall */
  PERF_BR_SYSRET/* Syscall return */
  PERF_BR_COND_CALL /* Conditional function call */
  PERF_BR_COND_RET  /* Conditional function return */

cheers

Re: [PATCH] mm/mremap: Document MREMAP_FIXED dependency on MREMAP_MAYMOVE

[Anshuman Khandual]

On 07/10/2017 11:01 PM, Mike Kravetz wrote:
> On 07/10/2017 06:41 AM, Michal Hocko wrote:
>> On Mon 10-07-17 17:02:11, Anshuman Khandual wrote:
>>> In the header file, just specify the dependency of MREMAP_FIXED
>>> on MREMAP_MAYMOVE and make it explicit for the user space.
>> I really fail to see a point of this patch. The depency belongs to the
>> code and it seems that we already enforce it
>>  if (flags & MREMAP_FIXED && !(flags & MREMAP_MAYMOVE))
>>  return ret;
>>
>> So what is the point here?
> Agree, I am not sure of your reasoning.
> 
> If to assist the programmer, there is no need as this is clearly specified
> in the man page:
> 
> "If  MREMAP_FIXED  is  specified,  then MREMAP_MAYMOVE must also be
>  specified."

Yeah the idea was to assist the programmer and I missed the man page's
details on this. My bad.

Re: [PATCH] mm/mremap: Document MREMAP_FIXED dependency on MREMAP_MAYMOVE

[Anshuman Khandual]

On 07/10/2017 11:01 PM, Mike Kravetz wrote:
> On 07/10/2017 06:41 AM, Michal Hocko wrote:
>> On Mon 10-07-17 17:02:11, Anshuman Khandual wrote:
>>> In the header file, just specify the dependency of MREMAP_FIXED
>>> on MREMAP_MAYMOVE and make it explicit for the user space.
>> I really fail to see a point of this patch. The depency belongs to the
>> code and it seems that we already enforce it
>>  if (flags & MREMAP_FIXED && !(flags & MREMAP_MAYMOVE))
>>  return ret;
>>
>> So what is the point here?
> Agree, I am not sure of your reasoning.
> 
> If to assist the programmer, there is no need as this is clearly specified
> in the man page:
> 
> "If  MREMAP_FIXED  is  specified,  then MREMAP_MAYMOVE must also be
>  specified."

Yeah the idea was to assist the programmer and I missed the man page's
details on this. My bad.

Re: [patches] Re: [PATCH 01/17] lib: Add shared copies of some GCC library routines

[Randy Dunlap]

On 07/10/2017 07:09 PM, Palmer Dabbelt wrote:
> On Mon, 10 Jul 2017 19:03:44 PDT (-0700), rdun...@infradead.org wrote:
>> On 07/10/2017 07:02 PM, Stephen Rothwell wrote:
>>> Hi Palmer,
>>>
>>> On Mon, 10 Jul 2017 18:39:08 -0700 Palmer Dabbelt  
>>> wrote:

 This patch adds a new copy of these library routine files, which are
 functionally identical to the various other copies.  These are
 availiable via Kconfig as CONFIG_LIB_$ROUTINE, which currently isn't
>>>
>>> Umm, the patch actually uses CONFIG_GENERIC_$ROUTINE.
>>>
 +config GENERIC_ASHLDI3
 +  def_bool n
>>>
>>> Just
>>> bool
>>> is the same.
>>>
>>
>> and several "default n" lines can (should) be removed from Kconfig.
> 
> I'm not much of a Kconfig hacker...  How does this look?
> 

Looks good.  Thanks.

> commit 4aaad1e6e8a70020dd95b8a13a4075af97cb858f
> Author: Palmer Dabbelt 
> Date:   Mon Jul 10 19:07:43 2017 -0700
> 
> lib: Remove "default n" lines from Kconfig
> 
> These lines aren't necessary, as the default is "n" anyway.
> 
> Signed-off-by: Palmer Dabbelt 
> 
> diff --git a/lib/Kconfig b/lib/Kconfig
> index ee7d8bf0b7e1..78dec2408481 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -15,7 +15,6 @@ config BITREVERSE
> 
>  config HAVE_ARCH_BITREVERSE
>   bool
> - default n
>   depends on BITREVERSE
>   help
> This option enables the use of hardware bit-reversal instructions on
> @@ -48,7 +47,6 @@ config GENERIC_IOMAP
> 
>  config GENERIC_IO
>   bool
> - default n
> 
>  config STMP_DEVICE
>   bool
> @@ -199,7 +197,6 @@ config AUDIT_GENERIC
> 
>  config AUDIT_ARCH_COMPAT_GENERIC
>   bool
> - default n
> 
>  config AUDIT_COMPAT_GENERIC
>   bool
> @@ -208,7 +205,6 @@ config AUDIT_COMPAT_GENERIC
> 
>  config RANDOM32_SELFTEST
>   bool "PRNG perform self test on init"
> - default n
>   help
> This option enables the 32 bit PRNG library functions to perform a
> self test on initialization.
> @@ -405,12 +401,10 @@ config HAS_DMA
>  config DMA_NOOP_OPS
>   bool
>   depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
> - default n
> 
>  config DMA_VIRT_OPS
>   bool
>   depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
> - default n
> 
>  config CHECK_SIGNATURE
>   bool
> 


-- 
~Randy

Re: [patches] Re: [PATCH 01/17] lib: Add shared copies of some GCC library routines

[Randy Dunlap]

On 07/10/2017 07:09 PM, Palmer Dabbelt wrote:
> On Mon, 10 Jul 2017 19:03:44 PDT (-0700), rdun...@infradead.org wrote:
>> On 07/10/2017 07:02 PM, Stephen Rothwell wrote:
>>> Hi Palmer,
>>>
>>> On Mon, 10 Jul 2017 18:39:08 -0700 Palmer Dabbelt  
>>> wrote:

 This patch adds a new copy of these library routine files, which are
 functionally identical to the various other copies.  These are
 availiable via Kconfig as CONFIG_LIB_$ROUTINE, which currently isn't
>>>
>>> Umm, the patch actually uses CONFIG_GENERIC_$ROUTINE.
>>>
 +config GENERIC_ASHLDI3
 +  def_bool n
>>>
>>> Just
>>> bool
>>> is the same.
>>>
>>
>> and several "default n" lines can (should) be removed from Kconfig.
> 
> I'm not much of a Kconfig hacker...  How does this look?
> 

Looks good.  Thanks.

> commit 4aaad1e6e8a70020dd95b8a13a4075af97cb858f
> Author: Palmer Dabbelt 
> Date:   Mon Jul 10 19:07:43 2017 -0700
> 
> lib: Remove "default n" lines from Kconfig
> 
> These lines aren't necessary, as the default is "n" anyway.
> 
> Signed-off-by: Palmer Dabbelt 
> 
> diff --git a/lib/Kconfig b/lib/Kconfig
> index ee7d8bf0b7e1..78dec2408481 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -15,7 +15,6 @@ config BITREVERSE
> 
>  config HAVE_ARCH_BITREVERSE
>   bool
> - default n
>   depends on BITREVERSE
>   help
> This option enables the use of hardware bit-reversal instructions on
> @@ -48,7 +47,6 @@ config GENERIC_IOMAP
> 
>  config GENERIC_IO
>   bool
> - default n
> 
>  config STMP_DEVICE
>   bool
> @@ -199,7 +197,6 @@ config AUDIT_GENERIC
> 
>  config AUDIT_ARCH_COMPAT_GENERIC
>   bool
> - default n
> 
>  config AUDIT_COMPAT_GENERIC
>   bool
> @@ -208,7 +205,6 @@ config AUDIT_COMPAT_GENERIC
> 
>  config RANDOM32_SELFTEST
>   bool "PRNG perform self test on init"
> - default n
>   help
> This option enables the 32 bit PRNG library functions to perform a
> self test on initialization.
> @@ -405,12 +401,10 @@ config HAS_DMA
>  config DMA_NOOP_OPS
>   bool
>   depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
> - default n
> 
>  config DMA_VIRT_OPS
>   bool
>   depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
> - default n
> 
>  config CHECK_SIGNATURE
>   bool
> 


-- 
~Randy

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Michael Ellerman]

Segher Boessenkool  writes:
> Hi!
>
> On Mon, Jul 10, 2017 at 07:46:17PM +0800, Jin, Yao wrote:
>> 1. We all agree these definitions:
>> 
>> +PERF_BR_COND= 1,/* conditional */
>> +PERF_BR_UNCOND  = 2,/* unconditional */
>> +PERF_BR_IND = 3,/* indirect */
>> +PERF_BR_CALL= 4,/* call */
>> +PERF_BR_IND_CALL= 5,/* indirect call */
>> +PERF_BR_RET = 6,/* return */
>> +PERF_BR_SYSCALL = 7,/* syscall */
>> +PERF_BR_SYSRET  = 8,/* syscall return */
>> +PERF_BR_IRET= 11,   /* return from interrupt */
>
> Do we?  It does not map very well to PowerPC branch types.

I think they map well enough to the types of branches that are actually
used in practice.

To represent the full range of possibilities we'd need to switch to a
bitmap of flags, ie. COND, IND, CALL, RET, SYSCALL, INT, etc. But it
would need more than 4 bits and I don't think there's that much added
value in being able to represent all the bizarre combinations.

But maybe that is the best option as it makes the API more flexible and
means we don't have to get the list of branches correct up front?


I ran some quick numbers on a kernel I had here (powernv w/gcc 7):

  Type  Percent
  -
  cond  40.92%  beq (79166) bne (57379) ble (10411) bgt (9587) blt 
(6248) bge (3704) bdnz (1251) bdz (353) bns (30) bdnzf (2) bdnzt (1)
  uncond14.89%  b (61182) 
  indirect  0.10%   bctr (418)
  call  33.33%  bl (136926)
  ind call  1.44%   bctrl (5912)
  return9.23%   blr (37943)
=   99.91%

If we add cond call/return that covers another 0.08% taking us to 99.99%
of branches.

I know future compilers and or different code might use a different
distribution, but I doubt it will change all that much.

Maybe cond could be broken down further, but the only really meaningful
sub category I can think of is the decrementing type, and those are
quite rare.

cheers

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Michael Ellerman]

Segher Boessenkool  writes:
> Hi!
>
> On Mon, Jul 10, 2017 at 07:46:17PM +0800, Jin, Yao wrote:
>> 1. We all agree these definitions:
>> 
>> +PERF_BR_COND= 1,/* conditional */
>> +PERF_BR_UNCOND  = 2,/* unconditional */
>> +PERF_BR_IND = 3,/* indirect */
>> +PERF_BR_CALL= 4,/* call */
>> +PERF_BR_IND_CALL= 5,/* indirect call */
>> +PERF_BR_RET = 6,/* return */
>> +PERF_BR_SYSCALL = 7,/* syscall */
>> +PERF_BR_SYSRET  = 8,/* syscall return */
>> +PERF_BR_IRET= 11,   /* return from interrupt */
>
> Do we?  It does not map very well to PowerPC branch types.

I think they map well enough to the types of branches that are actually
used in practice.

To represent the full range of possibilities we'd need to switch to a
bitmap of flags, ie. COND, IND, CALL, RET, SYSCALL, INT, etc. But it
would need more than 4 bits and I don't think there's that much added
value in being able to represent all the bizarre combinations.

But maybe that is the best option as it makes the API more flexible and
means we don't have to get the list of branches correct up front?


I ran some quick numbers on a kernel I had here (powernv w/gcc 7):

  Type  Percent
  -
  cond  40.92%  beq (79166) bne (57379) ble (10411) bgt (9587) blt 
(6248) bge (3704) bdnz (1251) bdz (353) bns (30) bdnzf (2) bdnzt (1)
  uncond14.89%  b (61182) 
  indirect  0.10%   bctr (418)
  call  33.33%  bl (136926)
  ind call  1.44%   bctrl (5912)
  return9.23%   blr (37943)
=   99.91%

If we add cond call/return that covers another 0.08% taking us to 99.99%
of branches.

I know future compilers and or different code might use a different
distribution, but I doubt it will change all that much.

Maybe cond could be broken down further, but the only really meaningful
sub category I can think of is the decrementing type, and those are
quite rare.

cheers

Re: [PATCH v4 1/4] ARM: dts: imx6ul-geam-kit: Remove re-enabled usdhc1

[Shawn Guo]

On Fri, Jun 16, 2017 at 12:34:37PM +0530, Jagan Teki wrote:
> From: Jagan Teki 
> 
> usdhc1 is enabled and assigned pinctrl-0 on imx6ul-geam.dtsi
> but same thing done on imx6ul-geam-kit.dts, so remove this
> re-enabled node from the same.
> 
> Signed-off-by: Jagan Teki 

Applied all, thanks.

Re: [PATCH v4 1/4] ARM: dts: imx6ul-geam-kit: Remove re-enabled usdhc1

[Shawn Guo]

On Fri, Jun 16, 2017 at 12:34:37PM +0530, Jagan Teki wrote:
> From: Jagan Teki 
> 
> usdhc1 is enabled and assigned pinctrl-0 on imx6ul-geam.dtsi
> but same thing done on imx6ul-geam-kit.dts, so remove this
> re-enabled node from the same.
> 
> Signed-off-by: Jagan Teki 

Applied all, thanks.

Re: [patches] Re: [PATCH 01/17] lib: Add shared copies of some GCC library routines

[Palmer Dabbelt]

On Mon, 10 Jul 2017 19:03:44 PDT (-0700), rdun...@infradead.org wrote:
> On 07/10/2017 07:02 PM, Stephen Rothwell wrote:
>> Hi Palmer,
>>
>> On Mon, 10 Jul 2017 18:39:08 -0700 Palmer Dabbelt  wrote:
>>>
>>> This patch adds a new copy of these library routine files, which are
>>> functionally identical to the various other copies.  These are
>>> availiable via Kconfig as CONFIG_LIB_$ROUTINE, which currently isn't
>>
>> Umm, the patch actually uses CONFIG_GENERIC_$ROUTINE.
>>
>>> +config GENERIC_ASHLDI3
>>> +   def_bool n
>>
>> Just
>>  bool
>> is the same.
>>
>
> and several "default n" lines can (should) be removed from Kconfig.

I'm not much of a Kconfig hacker...  How does this look?

commit 4aaad1e6e8a70020dd95b8a13a4075af97cb858f
Author: Palmer Dabbelt 
Date:   Mon Jul 10 19:07:43 2017 -0700

lib: Remove "default n" lines from Kconfig

These lines aren't necessary, as the default is "n" anyway.

Signed-off-by: Palmer Dabbelt 

diff --git a/lib/Kconfig b/lib/Kconfig
index ee7d8bf0b7e1..78dec2408481 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -15,7 +15,6 @@ config BITREVERSE

 config HAVE_ARCH_BITREVERSE
bool
-   default n
depends on BITREVERSE
help
  This option enables the use of hardware bit-reversal instructions on
@@ -48,7 +47,6 @@ config GENERIC_IOMAP

 config GENERIC_IO
bool
-   default n

 config STMP_DEVICE
bool
@@ -199,7 +197,6 @@ config AUDIT_GENERIC

 config AUDIT_ARCH_COMPAT_GENERIC
bool
-   default n

 config AUDIT_COMPAT_GENERIC
bool
@@ -208,7 +205,6 @@ config AUDIT_COMPAT_GENERIC

 config RANDOM32_SELFTEST
bool "PRNG perform self test on init"
-   default n
help
  This option enables the 32 bit PRNG library functions to perform a
  self test on initialization.
@@ -405,12 +401,10 @@ config HAS_DMA
 config DMA_NOOP_OPS
bool
depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
-   default n

 config DMA_VIRT_OPS
bool
depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
-   default n

 config CHECK_SIGNATURE
bool

Re: [patches] Re: [PATCH 01/17] lib: Add shared copies of some GCC library routines

[Palmer Dabbelt]

On Mon, 10 Jul 2017 19:03:44 PDT (-0700), rdun...@infradead.org wrote:
> On 07/10/2017 07:02 PM, Stephen Rothwell wrote:
>> Hi Palmer,
>>
>> On Mon, 10 Jul 2017 18:39:08 -0700 Palmer Dabbelt  wrote:
>>>
>>> This patch adds a new copy of these library routine files, which are
>>> functionally identical to the various other copies.  These are
>>> availiable via Kconfig as CONFIG_LIB_$ROUTINE, which currently isn't
>>
>> Umm, the patch actually uses CONFIG_GENERIC_$ROUTINE.
>>
>>> +config GENERIC_ASHLDI3
>>> +   def_bool n
>>
>> Just
>>  bool
>> is the same.
>>
>
> and several "default n" lines can (should) be removed from Kconfig.

I'm not much of a Kconfig hacker...  How does this look?

commit 4aaad1e6e8a70020dd95b8a13a4075af97cb858f
Author: Palmer Dabbelt 
Date:   Mon Jul 10 19:07:43 2017 -0700

lib: Remove "default n" lines from Kconfig

These lines aren't necessary, as the default is "n" anyway.

Signed-off-by: Palmer Dabbelt 

diff --git a/lib/Kconfig b/lib/Kconfig
index ee7d8bf0b7e1..78dec2408481 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -15,7 +15,6 @@ config BITREVERSE

 config HAVE_ARCH_BITREVERSE
bool
-   default n
depends on BITREVERSE
help
  This option enables the use of hardware bit-reversal instructions on
@@ -48,7 +47,6 @@ config GENERIC_IOMAP

 config GENERIC_IO
bool
-   default n

 config STMP_DEVICE
bool
@@ -199,7 +197,6 @@ config AUDIT_GENERIC

 config AUDIT_ARCH_COMPAT_GENERIC
bool
-   default n

 config AUDIT_COMPAT_GENERIC
bool
@@ -208,7 +205,6 @@ config AUDIT_COMPAT_GENERIC

 config RANDOM32_SELFTEST
bool "PRNG perform self test on init"
-   default n
help
  This option enables the 32 bit PRNG library functions to perform a
  self test on initialization.
@@ -405,12 +401,10 @@ config HAS_DMA
 config DMA_NOOP_OPS
bool
depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
-   default n

 config DMA_VIRT_OPS
bool
depends on HAS_DMA && (!64BIT || ARCH_DMA_ADDR_T_64BIT)
-   default n

 config CHECK_SIGNATURE
bool

Re: [PATCH 01/17] lib: Add shared copies of some GCC library routines

[Palmer Dabbelt]

On Mon, 10 Jul 2017 19:02:19 PDT (-0700), s...@canb.auug.org.au wrote:
> Hi Palmer,
>
> On Mon, 10 Jul 2017 18:39:08 -0700 Palmer Dabbelt  wrote:
>>
>> This patch adds a new copy of these library routine files, which are
>> functionally identical to the various other copies.  These are
>> availiable via Kconfig as CONFIG_LIB_$ROUTINE, which currently isn't
>
> Umm, the patch actually uses CONFIG_GENERIC_$ROUTINE.

IIRC someone suggested I change the Kconfig name, but I must have forgotten to
change the commit message.  I'll fix that up if we do a v6.

>
>> +config GENERIC_ASHLDI3
>> +def_bool n
>
> Just
>   bool
> is the same.

OK, that'll go in the v6 as well.

Thanks!

Re: [PATCH 01/17] lib: Add shared copies of some GCC library routines

[Palmer Dabbelt]

On Mon, 10 Jul 2017 19:02:19 PDT (-0700), s...@canb.auug.org.au wrote:
> Hi Palmer,
>
> On Mon, 10 Jul 2017 18:39:08 -0700 Palmer Dabbelt  wrote:
>>
>> This patch adds a new copy of these library routine files, which are
>> functionally identical to the various other copies.  These are
>> availiable via Kconfig as CONFIG_LIB_$ROUTINE, which currently isn't
>
> Umm, the patch actually uses CONFIG_GENERIC_$ROUTINE.

IIRC someone suggested I change the Kconfig name, but I must have forgotten to
change the commit message.  I'll fix that up if we do a v6.

>
>> +config GENERIC_ASHLDI3
>> +def_bool n
>
> Just
>   bool
> is the same.

OK, that'll go in the v6 as well.

Thanks!

Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition

[Aleksa Sarai]

This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
because it doesn't copy anything from/to userspace to access the
argument.


  Acked-by: Aleksa Sarai 

Oops, I misunderstood what _IOR means semantically. TIL -- thanks!

--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition

[Aleksa Sarai]

This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
because it doesn't copy anything from/to userspace to access the
argument.


  Acked-by: Aleksa Sarai 

Oops, I misunderstood what _IOR means semantically. TIL -- thanks!

--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/

Re: [PATCH v2 2/8] exec: Move security_bprm_secureexec() earlier

[Kees Cook]

On Mon, Jul 10, 2017 at 10:18 AM, Eric W. Biederman
 wrote:
> Kees Cook  writes:
>
>> On Mon, Jul 10, 2017 at 1:57 AM, Eric W. Biederman
>>  wrote:
>>> Kees Cook  writes:
>>>
 There are several places where exec needs to know if a privilege-gain has
 happened. These should be using the results of security_bprm_secureexec()
 but it is getting (needlessly) called very late.
>>>
>>> It is hard to tell at a glance but I believe this introduces a
>>> regression.
>>>
>>> cap_bprm_set_creds is currently called before cap_bprm_secureexec and
>>> it has a number of cases such as no_new_privs and ptrace that can result
>>> in some of the precomputed credential changes not happening.
>>>
>>> Without accounting for that I believe your cap_bprm_securexec now
>>> returns a postive value too early.
>>
>> It's still before cap_bprm_secureexec. cap_brpm_set_creds() is in
>> prepare_binprm(), which is well before exec_binprm() and it's eventual
>> call to setup_new_exec().
>
> Good point.  I didn't double check and the set in the name had me
> thinking it was setting the creds on current.
>
> Is there any reason we need a second security hook?  It feels like we
> should be able to just fold the secureexec hook into the set_creds hook.
>
> The two are so interrelated I fear that having them separate only
> encourages them to diverge in trivial ways as it is easy to forget about
> some detail or other.
>
> Certainly having them called from different functions seems wrong.  If
> we know enough in prepare_binprm we know enough.

Hmmm, yes. That would let us have the secureexec-ness knowledge before
copy_strings(), in case we ever need to make that logic
secureexec-aware.

I'll dig through the LSMs to examine the set_creds hooks to see if
this could be possible.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v2 2/8] exec: Move security_bprm_secureexec() earlier

[Kees Cook]

On Mon, Jul 10, 2017 at 10:18 AM, Eric W. Biederman
 wrote:
> Kees Cook  writes:
>
>> On Mon, Jul 10, 2017 at 1:57 AM, Eric W. Biederman
>>  wrote:
>>> Kees Cook  writes:
>>>
 There are several places where exec needs to know if a privilege-gain has
 happened. These should be using the results of security_bprm_secureexec()
 but it is getting (needlessly) called very late.
>>>
>>> It is hard to tell at a glance but I believe this introduces a
>>> regression.
>>>
>>> cap_bprm_set_creds is currently called before cap_bprm_secureexec and
>>> it has a number of cases such as no_new_privs and ptrace that can result
>>> in some of the precomputed credential changes not happening.
>>>
>>> Without accounting for that I believe your cap_bprm_securexec now
>>> returns a postive value too early.
>>
>> It's still before cap_bprm_secureexec. cap_brpm_set_creds() is in
>> prepare_binprm(), which is well before exec_binprm() and it's eventual
>> call to setup_new_exec().
>
> Good point.  I didn't double check and the set in the name had me
> thinking it was setting the creds on current.
>
> Is there any reason we need a second security hook?  It feels like we
> should be able to just fold the secureexec hook into the set_creds hook.
>
> The two are so interrelated I fear that having them separate only
> encourages them to diverge in trivial ways as it is easy to forget about
> some detail or other.
>
> Certainly having them called from different functions seems wrong.  If
> we know enough in prepare_binprm we know enough.

Hmmm, yes. That would let us have the secureexec-ness knowledge before
copy_strings(), in case we ever need to make that logic
secureexec-aware.

I'll dig through the LSMs to examine the set_creds hooks to see if
this could be possible.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 1/3] Protectable memory support

[kbuild test robot]

Hi Igor,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.12 next-20170710]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/mm-security-ro-protection-for-dynamic-data/20170711-084116
config: i386-randconfig-x070-07101331 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   mm/pmalloc.c: In function '__pmalloc_pool_show_avail':
   mm/pmalloc.c:78:25: warning: format '%lu' expects argument of type 'long 
unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=]
 return sprintf(buf, "%lu\n", gen_pool_avail(data->pool));
^
   mm/pmalloc.c: In function '__pmalloc_pool_show_size':
   mm/pmalloc.c:88:25: warning: format '%lu' expects argument of type 'long 
unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=]
 return sprintf(buf, "%lu\n", gen_pool_size(data->pool));
^
   In file included from include/linux/init.h:4:0,
from include/linux/printk.h:5,
from mm/pmalloc.c:13:
   mm/pmalloc.c: In function 'pmalloc':
   mm/pmalloc.c:263:5: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
(phys_addr_t)NULL, chunk_size, NUMA_NO_NODE));
^
   include/linux/compiler.h:175:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
   mm/pmalloc.c:262:2: note: in expansion of macro 'BUG_ON'
 BUG_ON(gen_pool_add_virt(pool, (unsigned long)chunk,
 ^~
   mm/pmalloc.c: In function '__pmalloc_connect':
>> mm/pmalloc.c:118:2: warning: ignoring return value of 'sysfs_create_file', 
>> declared with attribute warn_unused_result [-Wunused-result]
 sysfs_create_file(data->pool_kobject, >attr_protected.attr);
 ^
   mm/pmalloc.c:119:2: warning: ignoring return value of 'sysfs_create_file', 
declared with attribute warn_unused_result [-Wunused-result]
 sysfs_create_file(data->pool_kobject, >attr_avail.attr);
 ^
   mm/pmalloc.c:120:2: warning: ignoring return value of 'sysfs_create_file', 
declared with attribute warn_unused_result [-Wunused-result]
 sysfs_create_file(data->pool_kobject, >attr_size.attr);
 ^~~~
   mm/pmalloc.c:121:2: warning: ignoring return value of 'sysfs_create_file', 
declared with attribute warn_unused_result [-Wunused-result]
 sysfs_create_file(data->pool_kobject, >attr_chunks.attr);
 ^~

vim +/sysfs_create_file +118 mm/pmalloc.c

   110  
   111  /**
   112   * Exposes the pool and its attributes through sysfs.
   113   */
   114  static void __pmalloc_connect(struct pmalloc_data *data)
   115  {
   116  data->pool_kobject = kobject_create_and_add(data->pool->name,
   117  pmalloc_kobject);
 > 118  sysfs_create_file(data->pool_kobject, 
 > >attr_protected.attr);
   119  sysfs_create_file(data->pool_kobject, >attr_avail.attr);
   120  sysfs_create_file(data->pool_kobject, >attr_size.attr);
   121  sysfs_create_file(data->pool_kobject, >attr_chunks.attr);
   122  }
   123  
   124  /**
   125   * Removes the pool and its attributes from sysfs.
   126   */
   127  static void __pmalloc_disconnect(struct pmalloc_data *data)
   128  {
   129  sysfs_remove_file(data->pool_kobject, 
>attr_protected.attr);
   130  sysfs_remove_file(data->pool_kobject, >attr_avail.attr);
   131  sysfs_remove_file(data->pool_kobject, >attr_size.attr);
   132  sysfs_remove_file(data->pool_kobject, >attr_chunks.attr);
   133  kobject_put(data->pool_kobject);
   134  }
   135  
   136  /**
   137   * Declares an attribute of the pool.
   138   */
   139  
   140  
   141  #ifdef CONFIG_DEBUG_LOCK_ALLOC
   142  #define do_lock_dep(data, attr_name) \
   143  (data->attr_##attr_name.attr.ignore_lockdep = 1)
   144  #else
   145  #define do_lock_dep(data, attr_name) do {} while (0)
   146  #endif
   147  
   148  #define __pmalloc_attr_init(data, attr_name) \
   149  do { \
   150  data->attr_##attr_name.attr.name = #attr_name; \
   151  data->attr_##attr_name.attr.mode = 
VERIFY_OCTAL_PERMISSIONS(0444); \
   152  data->attr_##attr_name.show = __pmalloc_pool_show_##attr_name; \
   153  do_loc

Re: [PATCH 1/3] Protectable memory support

[kbuild test robot]

Hi Igor,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.12 next-20170710]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/mm-security-ro-protection-for-dynamic-data/20170711-084116
config: i386-randconfig-x070-07101331 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   mm/pmalloc.c: In function '__pmalloc_pool_show_avail':
   mm/pmalloc.c:78:25: warning: format '%lu' expects argument of type 'long 
unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=]
 return sprintf(buf, "%lu\n", gen_pool_avail(data->pool));
^
   mm/pmalloc.c: In function '__pmalloc_pool_show_size':
   mm/pmalloc.c:88:25: warning: format '%lu' expects argument of type 'long 
unsigned int', but argument 3 has type 'size_t {aka unsigned int}' [-Wformat=]
 return sprintf(buf, "%lu\n", gen_pool_size(data->pool));
^
   In file included from include/linux/init.h:4:0,
from include/linux/printk.h:5,
from mm/pmalloc.c:13:
   mm/pmalloc.c: In function 'pmalloc':
   mm/pmalloc.c:263:5: warning: cast from pointer to integer of different size 
[-Wpointer-to-int-cast]
(phys_addr_t)NULL, chunk_size, NUMA_NO_NODE));
^
   include/linux/compiler.h:175:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
   mm/pmalloc.c:262:2: note: in expansion of macro 'BUG_ON'
 BUG_ON(gen_pool_add_virt(pool, (unsigned long)chunk,
 ^~
   mm/pmalloc.c: In function '__pmalloc_connect':
>> mm/pmalloc.c:118:2: warning: ignoring return value of 'sysfs_create_file', 
>> declared with attribute warn_unused_result [-Wunused-result]
 sysfs_create_file(data->pool_kobject, >attr_protected.attr);
 ^
   mm/pmalloc.c:119:2: warning: ignoring return value of 'sysfs_create_file', 
declared with attribute warn_unused_result [-Wunused-result]
 sysfs_create_file(data->pool_kobject, >attr_avail.attr);
 ^
   mm/pmalloc.c:120:2: warning: ignoring return value of 'sysfs_create_file', 
declared with attribute warn_unused_result [-Wunused-result]
 sysfs_create_file(data->pool_kobject, >attr_size.attr);
 ^~~~
   mm/pmalloc.c:121:2: warning: ignoring return value of 'sysfs_create_file', 
declared with attribute warn_unused_result [-Wunused-result]
 sysfs_create_file(data->pool_kobject, >attr_chunks.attr);
 ^~

vim +/sysfs_create_file +118 mm/pmalloc.c

   110  
   111  /**
   112   * Exposes the pool and its attributes through sysfs.
   113   */
   114  static void __pmalloc_connect(struct pmalloc_data *data)
   115  {
   116  data->pool_kobject = kobject_create_and_add(data->pool->name,
   117  pmalloc_kobject);
 > 118  sysfs_create_file(data->pool_kobject, 
 > >attr_protected.attr);
   119  sysfs_create_file(data->pool_kobject, >attr_avail.attr);
   120  sysfs_create_file(data->pool_kobject, >attr_size.attr);
   121  sysfs_create_file(data->pool_kobject, >attr_chunks.attr);
   122  }
   123  
   124  /**
   125   * Removes the pool and its attributes from sysfs.
   126   */
   127  static void __pmalloc_disconnect(struct pmalloc_data *data)
   128  {
   129  sysfs_remove_file(data->pool_kobject, 
>attr_protected.attr);
   130  sysfs_remove_file(data->pool_kobject, >attr_avail.attr);
   131  sysfs_remove_file(data->pool_kobject, >attr_size.attr);
   132  sysfs_remove_file(data->pool_kobject, >attr_chunks.attr);
   133  kobject_put(data->pool_kobject);
   134  }
   135  
   136  /**
   137   * Declares an attribute of the pool.
   138   */
   139  
   140  
   141  #ifdef CONFIG_DEBUG_LOCK_ALLOC
   142  #define do_lock_dep(data, attr_name) \
   143  (data->attr_##attr_name.attr.ignore_lockdep = 1)
   144  #else
   145  #define do_lock_dep(data, attr_name) do {} while (0)
   146  #endif
   147  
   148  #define __pmalloc_attr_init(data, attr_name) \
   149  do { \
   150  data->attr_##attr_name.attr.name = #attr_name; \
   151  data->attr_##attr_name.attr.mode = 
VERIFY_OCTAL_PERMISSIONS(0444); \
   152  data->attr_##attr_name.show = __pmalloc_pool_show_##attr_name; \
   153  do_loc

Re: [PATCH v4 1/3] ARM: dts: imx6ul-isiot: Move common nodes in imx6ul-isiot.dtsi

[Shawn Guo]

On Thu, Jun 15, 2017 at 05:33:37PM +0530, Jagan Teki wrote:
> From: Jagan Teki 
> 
> Maintaining separate dtsi file with common nodes make unclear and
> confusing since -isiot.dtsi is available for adding common nodes.
> If the nodes are common between the dts files then mark status
> as "okay" otherwise mark it "disabled" so-that respective dts
> can mark status "okay"
> 
> Signed-off-by: Jagan Teki 

Applied all, thanks.

Re: [PATCH v4 1/3] ARM: dts: imx6ul-isiot: Move common nodes in imx6ul-isiot.dtsi

[Shawn Guo]

On Thu, Jun 15, 2017 at 05:33:37PM +0530, Jagan Teki wrote:
> From: Jagan Teki 
> 
> Maintaining separate dtsi file with common nodes make unclear and
> confusing since -isiot.dtsi is available for adding common nodes.
> If the nodes are common between the dts files then mark status
> as "okay" otherwise mark it "disabled" so-that respective dts
> can mark status "okay"
> 
> Signed-off-by: Jagan Teki 

Applied all, thanks.

Re: [PATCH 01/17] lib: Add shared copies of some GCC library routines

[Randy Dunlap]

On 07/10/2017 07:02 PM, Stephen Rothwell wrote:
> Hi Palmer,
> 
> On Mon, 10 Jul 2017 18:39:08 -0700 Palmer Dabbelt  wrote:
>>
>> This patch adds a new copy of these library routine files, which are
>> functionally identical to the various other copies.  These are
>> availiable via Kconfig as CONFIG_LIB_$ROUTINE, which currently isn't
> 
> Umm, the patch actually uses CONFIG_GENERIC_$ROUTINE.
> 
>> +config GENERIC_ASHLDI3
>> +def_bool n
> 
> Just
>   bool
> is the same.
> 

and several "default n" lines can (should) be removed from Kconfig.


-- 
~Randy

Re: [PATCH 01/17] lib: Add shared copies of some GCC library routines

[Randy Dunlap]

On 07/10/2017 07:02 PM, Stephen Rothwell wrote:
> Hi Palmer,
> 
> On Mon, 10 Jul 2017 18:39:08 -0700 Palmer Dabbelt  wrote:
>>
>> This patch adds a new copy of these library routine files, which are
>> functionally identical to the various other copies.  These are
>> availiable via Kconfig as CONFIG_LIB_$ROUTINE, which currently isn't
> 
> Umm, the patch actually uses CONFIG_GENERIC_$ROUTINE.
> 
>> +config GENERIC_ASHLDI3
>> +def_bool n
> 
> Just
>   bool
> is the same.
> 

and several "default n" lines can (should) be removed from Kconfig.


-- 
~Randy