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

[Balbir Singh]

On Tue, 11 Jul 2017 10:57:44 -0400
Jerome Glisse  wrote:

> On Tue, Jul 11, 2017 at 02:12:15PM +1000, Balbir Singh wrote:
> > 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.
> >
> 
> [...]
> 
> > >  /*
> > > @@ -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?  
> 
> This is something we can explore latter on.
> 
> [...]
> 

Agreed

> > > diff --git a/kernel/memremap.c b/kernel/memremap.c
> > > index e82456c39a6a..da74775f2247 100644
> > > --- a/kernel/memremap.c
> > > +++ b/kernel/memremap.c
> > > @@ -466,7 +466,7 @@ struct vmem_altmap *to_vmem_altmap(unsigned long 
> > > memmap_start)
> > >  
> > >  
> > >  #ifdef CONFIG_DEVICE_PRIVATE  
> > 
> > Does the #ifdef above need to go as well?  
> 
> Good catch i should make that conditional on DEVICE_PUBLIC or whatever
> the name endup to be. I will make sure i test without DEVICE_PRIVATE
> config before posting again.
> 
> [...]
> 

I've been testing with this off, I should have sent you a patch, but
I thought I'd also update in the review.

> > > @@ -2541,11 +2551,21 @@ static void migrate_vma_insert_page(struct 
> > > migrate_vma *migrate,
> > >*/
> > >   __SetPageUptodate(page);
> > >  
> > > - if (is_zone_device_page(page) && is_device_private_page(page)) {
> > > - swp_entry_t swp_entry;
> > > + if (is_zone_device_page(page)) {
> > > + if (is_device_private_page(page)) {
> > > + swp_entry_t swp_entry;
> > >  
> > > - swp_entry = make_device_private_entry(page, vma->vm_flags & 
> > > VM_WRITE);
> > > - entry = swp_entry_to_pte(swp_entry);
> > > + swp_entry = make_device_private_entry(page, 
> > > vma->vm_flags & VM_WRITE);
> > > + entry = swp_entry_to_pte(swp_entry);
> > > + }
> > > +#if IS_ENABLED(CONFIG_DEVICE_PUBLIC)  
> > 
> > Do we need this #if check? is_device_public_page(page)
> > will return false if the config is disabled  
> 
> pte_mkdevmap() is not define if ZONE_DEVICE is not enabled hence
> i had to protect this with #if/#endif to avoid build error.

pte_mkdevmap is always defined, could you please share the build
error.


Balbir Singh.

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

[Balbir Singh]

On Tue, 11 Jul 2017 10:57:44 -0400
Jerome Glisse  wrote:

> On Tue, Jul 11, 2017 at 02:12:15PM +1000, Balbir Singh wrote:
> > 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.
> >
> 
> [...]
> 
> > >  /*
> > > @@ -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?  
> 
> This is something we can explore latter on.
> 
> [...]
> 

Agreed

> > > diff --git a/kernel/memremap.c b/kernel/memremap.c
> > > index e82456c39a6a..da74775f2247 100644
> > > --- a/kernel/memremap.c
> > > +++ b/kernel/memremap.c
> > > @@ -466,7 +466,7 @@ struct vmem_altmap *to_vmem_altmap(unsigned long 
> > > memmap_start)
> > >  
> > >  
> > >  #ifdef CONFIG_DEVICE_PRIVATE  
> > 
> > Does the #ifdef above need to go as well?  
> 
> Good catch i should make that conditional on DEVICE_PUBLIC or whatever
> the name endup to be. I will make sure i test without DEVICE_PRIVATE
> config before posting again.
> 
> [...]
> 

I've been testing with this off, I should have sent you a patch, but
I thought I'd also update in the review.

> > > @@ -2541,11 +2551,21 @@ static void migrate_vma_insert_page(struct 
> > > migrate_vma *migrate,
> > >*/
> > >   __SetPageUptodate(page);
> > >  
> > > - if (is_zone_device_page(page) && is_device_private_page(page)) {
> > > - swp_entry_t swp_entry;
> > > + if (is_zone_device_page(page)) {
> > > + if (is_device_private_page(page)) {
> > > + swp_entry_t swp_entry;
> > >  
> > > - swp_entry = make_device_private_entry(page, vma->vm_flags & 
> > > VM_WRITE);
> > > - entry = swp_entry_to_pte(swp_entry);
> > > + swp_entry = make_device_private_entry(page, 
> > > vma->vm_flags & VM_WRITE);
> > > + entry = swp_entry_to_pte(swp_entry);
> > > + }
> > > +#if IS_ENABLED(CONFIG_DEVICE_PUBLIC)  
> > 
> > Do we need this #if check? is_device_public_page(page)
> > will return false if the config is disabled  
> 
> pte_mkdevmap() is not define if ZONE_DEVICE is not enabled hence
> i had to protect this with #if/#endif to avoid build error.

pte_mkdevmap is always defined, could you please share the build
error.


Balbir Singh.

Re: [PATCH] Clean up lirc zilog error codes

[Frans Klaver]

On Tue, Jul 11, 2017 at 7:57 PM, Yves Lemée  wrote:
> According the coding style guidelines, the ENOSYS error code must be returned
> in case of a non existent system call. This code has been replaced with
> the ENOTTY error code indicating, a missing functionality.
>
> Signed-off-by: Yves Lemée 

Your subject line is not according to the patch submission guidelines.

Also, on a nit-picking note, that comma after 'indicating' is rather
oddly placed. Please move or remove it.

Frans

Re: [PATCH] Clean up lirc zilog error codes

[Frans Klaver]

On Tue, Jul 11, 2017 at 7:57 PM, Yves Lemée  wrote:
> According the coding style guidelines, the ENOSYS error code must be returned
> in case of a non existent system call. This code has been replaced with
> the ENOTTY error code indicating, a missing functionality.
>
> Signed-off-by: Yves Lemée 

Your subject line is not according to the patch submission guidelines.

Also, on a nit-picking note, that comma after 'indicating' is rather
oddly placed. Please move or remove it.

Frans

Re: [GIT pull] irq updates for 4.13

[Tony Lindgren]

* Sebastian Reichel  [170711 15:51]:
> Hi,
> 
> On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > [...]
> >
> > Here is a revised version of the previous patch with the conditional
> > locking removed and a bunch of comments added.
> 
> That one also fixes Droid 4 boot.
> 
> Tested-by: Sebastian Reichel 

Sill works for me too:

Tested-by: Tony Lindgren 

Thanks,

Tony

Re: [GIT pull] irq updates for 4.13

[Tony Lindgren]

* Sebastian Reichel  [170711 15:51]:
> Hi,
> 
> On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > [...]
> >
> > Here is a revised version of the previous patch with the conditional
> > locking removed and a bunch of comments added.
> 
> That one also fixes Droid 4 boot.
> 
> Tested-by: Sebastian Reichel 

Sill works for me too:

Tested-by: Tony Lindgren 

Thanks,

Tony

Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers

[Balbir Singh]

On Wed,  5 Jul 2017 14:21:52 -0700
Ram Pai  wrote:

> Implements helper functions to read and write the key related
> registers; AMR, IAMR, UAMOR.
> 
> AMR register tracks the read,write permission of a key
> IAMR register tracks the execute permission of a key
> UAMOR register enables and disables a key
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/book3s/64/pgtable.h |   60 
> ++
>  1 files changed, 60 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
> b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 85bc987..435d6a7 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -428,6 +428,66 @@ static inline void huge_ptep_set_wrprotect(struct 
> mm_struct *mm,
>   pte_update(mm, addr, ptep, 0, _PAGE_PRIVILEGED, 1);
>  }
>  
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +
> +#include 
> +static inline u64 read_amr(void)
> +{
> + return mfspr(SPRN_AMR);
> +}
> +static inline void write_amr(u64 value)
> +{
> + mtspr(SPRN_AMR, value);
> +}
> +static inline u64 read_iamr(void)
> +{
> + return mfspr(SPRN_IAMR);
> +}
> +static inline void write_iamr(u64 value)
> +{
> + mtspr(SPRN_IAMR, value);
> +}
> +static inline u64 read_uamor(void)
> +{
> + return mfspr(SPRN_UAMOR);
> +}
> +static inline void write_uamor(u64 value)
> +{
> + mtspr(SPRN_UAMOR, value);
> +}
> +
> +#else /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +
> +static inline u64 read_amr(void)
> +{
> + WARN(1, "%s called with MEMORY PROTECTION KEYS disabled\n", __func__);
> + return -1;
> +}

Why do we need to have a version here if we are going to WARN(), why not
let the compilation fail if called from outside of 
CONFIG_PPC64_MEMORY_PROTECTION_KEYS?
Is that the intention?

Balbir Singh

Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers

[Balbir Singh]

On Wed,  5 Jul 2017 14:21:52 -0700
Ram Pai  wrote:

> Implements helper functions to read and write the key related
> registers; AMR, IAMR, UAMOR.
> 
> AMR register tracks the read,write permission of a key
> IAMR register tracks the execute permission of a key
> UAMOR register enables and disables a key
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/include/asm/book3s/64/pgtable.h |   60 
> ++
>  1 files changed, 60 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
> b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 85bc987..435d6a7 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -428,6 +428,66 @@ static inline void huge_ptep_set_wrprotect(struct 
> mm_struct *mm,
>   pte_update(mm, addr, ptep, 0, _PAGE_PRIVILEGED, 1);
>  }
>  
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +
> +#include 
> +static inline u64 read_amr(void)
> +{
> + return mfspr(SPRN_AMR);
> +}
> +static inline void write_amr(u64 value)
> +{
> + mtspr(SPRN_AMR, value);
> +}
> +static inline u64 read_iamr(void)
> +{
> + return mfspr(SPRN_IAMR);
> +}
> +static inline void write_iamr(u64 value)
> +{
> + mtspr(SPRN_IAMR, value);
> +}
> +static inline u64 read_uamor(void)
> +{
> + return mfspr(SPRN_UAMOR);
> +}
> +static inline void write_uamor(u64 value)
> +{
> + mtspr(SPRN_UAMOR, value);
> +}
> +
> +#else /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
> +
> +static inline u64 read_amr(void)
> +{
> + WARN(1, "%s called with MEMORY PROTECTION KEYS disabled\n", __func__);
> + return -1;
> +}

Why do we need to have a version here if we are going to WARN(), why not
let the compilation fail if called from outside of 
CONFIG_PPC64_MEMORY_PROTECTION_KEYS?
Is that the intention?

Balbir Singh

Re: [PATCH v4] clk: axs10x: introduce AXS10X pll driver

[Stephen Boyd]

On 06/21, Eugeniy Paltsev wrote:
> AXS10X boards manages it's clocks using various PLLs. These PLL has same
> dividers and corresponding control registers mapped to different addresses.
> So we add one common driver for such PLLs.
> 
> Each PLL on AXS10X board consist of three dividers: IDIV, FBDIV and
> ODIV. Output clock value is managed using these dividers.
> 
> We add pre-defined tables with supported rate values and appropriate
> configurations of IDIV, FBDIV and ODIV for each value.
> 
> As of today we add support for PLLs that generate clock for the
> following devices:
>  * ARC core on AXC CPU tiles.
>  * ARC PGU on ARC SDP Mainboard.
> and more to come later.
> 
> By this patch we add support for two plls (arc core pll and pgu pll),
> so we had to use two different init types: CLK_OF_DECLARE for arc core pll and
> regular probing for pgu pll.
> 
> Acked-by: Rob Herring 
> Acked-by: Jose Abreu 
> 
> Signed-off-by: Eugeniy Paltsev 
> Signed-off-by: Vlad Zakharov 
> Signed-off-by: Jose Abreu 

Sorry this missed the cutoff for new code for v4.13. Should be in
clk-next next week though.

> +}
> +
> +static inline struct axs10x_pll_clk *to_axs10x_pll_clk(struct clk_hw *hw)
> +{
> + return container_of(hw, struct axs10x_pll_clk, hw);
> +}
> +
> +static inline u32 axs10x_div_get_value(u32 reg)
> +{
> + if (PLL_REG_GET_BYPASS(reg))
> + return 1;
> +
> + return PLL_REG_GET_HIGH(reg) + PLL_REG_GET_LOW(reg);
> +}
> +
> +static inline u32 axs10x_encode_div(unsigned int id, int upd)
> +{
> + u32 div = 0;
> +
> + PLL_REG_SET_LOW(div, (id % 2 == 0) ? id >> 1 : (id >> 1) + 1);
> + PLL_REG_SET_HIGH(div, id >> 1);
> + PLL_REG_SET_EDGE(div, id % 2);
> + PLL_REG_SET_BYPASS(div, id == 1 ? 1 : 0);
> + PLL_REG_SET_NOUPD(div, !upd);

So sparse complains here about a "dubious !x & y". Perhaps this
can be changed to

PLL_REG_SET_NOUPD(div, upd == 0 ? 1 : 0);

That way sparse doesn't complain. I can make the change when
applying if you agree.

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

Re: [PATCH v4] clk: axs10x: introduce AXS10X pll driver

[Stephen Boyd]

On 06/21, Eugeniy Paltsev wrote:
> AXS10X boards manages it's clocks using various PLLs. These PLL has same
> dividers and corresponding control registers mapped to different addresses.
> So we add one common driver for such PLLs.
> 
> Each PLL on AXS10X board consist of three dividers: IDIV, FBDIV and
> ODIV. Output clock value is managed using these dividers.
> 
> We add pre-defined tables with supported rate values and appropriate
> configurations of IDIV, FBDIV and ODIV for each value.
> 
> As of today we add support for PLLs that generate clock for the
> following devices:
>  * ARC core on AXC CPU tiles.
>  * ARC PGU on ARC SDP Mainboard.
> and more to come later.
> 
> By this patch we add support for two plls (arc core pll and pgu pll),
> so we had to use two different init types: CLK_OF_DECLARE for arc core pll and
> regular probing for pgu pll.
> 
> Acked-by: Rob Herring 
> Acked-by: Jose Abreu 
> 
> Signed-off-by: Eugeniy Paltsev 
> Signed-off-by: Vlad Zakharov 
> Signed-off-by: Jose Abreu 

Sorry this missed the cutoff for new code for v4.13. Should be in
clk-next next week though.

> +}
> +
> +static inline struct axs10x_pll_clk *to_axs10x_pll_clk(struct clk_hw *hw)
> +{
> + return container_of(hw, struct axs10x_pll_clk, hw);
> +}
> +
> +static inline u32 axs10x_div_get_value(u32 reg)
> +{
> + if (PLL_REG_GET_BYPASS(reg))
> + return 1;
> +
> + return PLL_REG_GET_HIGH(reg) + PLL_REG_GET_LOW(reg);
> +}
> +
> +static inline u32 axs10x_encode_div(unsigned int id, int upd)
> +{
> + u32 div = 0;
> +
> + PLL_REG_SET_LOW(div, (id % 2 == 0) ? id >> 1 : (id >> 1) + 1);
> + PLL_REG_SET_HIGH(div, id >> 1);
> + PLL_REG_SET_EDGE(div, id % 2);
> + PLL_REG_SET_BYPASS(div, id == 1 ? 1 : 0);
> + PLL_REG_SET_NOUPD(div, !upd);

So sparse complains here about a "dubious !x & y". Perhaps this
can be changed to

PLL_REG_SET_NOUPD(div, upd == 0 ? 1 : 0);

That way sparse doesn't complain. I can make the change when
applying if you agree.

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

Re: [PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

[Viresh Kumar]

On 11-07-17, 19:24, Saravana Kannan wrote:
> Currently, the governor calculates the next frequency, set the current CPU
> frequency (policy->cur). It also assumes the current CPU frequency doesn't
> change if the next frequency isn't calculated again and hence caches the
> "current frequency".
> 
> However, this isn't true when CPU min/max frequency limits are changed. So,
> there's room for the CPU frequency to get stuck at the wrong level if the
> calculated next frequency doesn't change across multiple limits updates.
> 
> Fix this by updating the cached "current frequency" when limits changes the
> current CPU frequency.
> 
> Signed-off-by: Saravana Kannan 
> ---
>  kernel/sched/cpufreq_schedutil.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 076a2e3..fe0b2fb 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -226,6 +226,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
>  
>   busy = sugov_cpu_is_busy(sg_cpu);
>  
> + raw_spin_lock(_policy->update_lock);
>   if (flags & SCHED_CPUFREQ_RT_DL) {
>   next_f = policy->cpuinfo.max_freq;
>   } else {
> @@ -240,6 +241,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
>   next_f = sg_policy->next_freq;
>   }
>   sugov_update_commit(sg_policy, time, next_f);
> + raw_spin_unlock(_policy->update_lock);

We wouldn't allow locking here until the time we can :)

>  }
>  
>  static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 
> time)
> @@ -637,10 +639,14 @@ static void sugov_stop(struct cpufreq_policy *policy)
>  static void sugov_limits(struct cpufreq_policy *policy)
>  {
>   struct sugov_policy *sg_policy = policy->governor_data;
> + unsigned long flags;
>  
>   if (!policy->fast_switch_enabled) {
>   mutex_lock(_policy->work_lock);
>   cpufreq_policy_apply_limits(policy);
> + raw_spin_lock_irqsave(_policy->update_lock, flags);
> + sg_policy->next_freq = policy->cur;
> + raw_spin_unlock_irqrestore(_policy->update_lock, flags);
>   mutex_unlock(_policy->work_lock);
>   }

Did you miss the following part which is after the closing } here ?

sg_policy->need_freq_update = true;

As this should already take care of the problem you are worried about. Or did I
misunderstood your problem completely ?

-- 
viresh

Re: [PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

[Viresh Kumar]

On 11-07-17, 19:24, Saravana Kannan wrote:
> Currently, the governor calculates the next frequency, set the current CPU
> frequency (policy->cur). It also assumes the current CPU frequency doesn't
> change if the next frequency isn't calculated again and hence caches the
> "current frequency".
> 
> However, this isn't true when CPU min/max frequency limits are changed. So,
> there's room for the CPU frequency to get stuck at the wrong level if the
> calculated next frequency doesn't change across multiple limits updates.
> 
> Fix this by updating the cached "current frequency" when limits changes the
> current CPU frequency.
> 
> Signed-off-by: Saravana Kannan 
> ---
>  kernel/sched/cpufreq_schedutil.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/kernel/sched/cpufreq_schedutil.c 
> b/kernel/sched/cpufreq_schedutil.c
> index 076a2e3..fe0b2fb 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -226,6 +226,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
>  
>   busy = sugov_cpu_is_busy(sg_cpu);
>  
> + raw_spin_lock(_policy->update_lock);
>   if (flags & SCHED_CPUFREQ_RT_DL) {
>   next_f = policy->cpuinfo.max_freq;
>   } else {
> @@ -240,6 +241,7 @@ static void sugov_update_single(struct update_util_data 
> *hook, u64 time,
>   next_f = sg_policy->next_freq;
>   }
>   sugov_update_commit(sg_policy, time, next_f);
> + raw_spin_unlock(_policy->update_lock);

We wouldn't allow locking here until the time we can :)

>  }
>  
>  static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 
> time)
> @@ -637,10 +639,14 @@ static void sugov_stop(struct cpufreq_policy *policy)
>  static void sugov_limits(struct cpufreq_policy *policy)
>  {
>   struct sugov_policy *sg_policy = policy->governor_data;
> + unsigned long flags;
>  
>   if (!policy->fast_switch_enabled) {
>   mutex_lock(_policy->work_lock);
>   cpufreq_policy_apply_limits(policy);
> + raw_spin_lock_irqsave(_policy->update_lock, flags);
> + sg_policy->next_freq = policy->cur;
> + raw_spin_unlock_irqrestore(_policy->update_lock, flags);
>   mutex_unlock(_policy->work_lock);
>   }

Did you miss the following part which is after the closing } here ?

sg_policy->need_freq_update = true;

As this should already take care of the problem you are worried about. Or did I
misunderstood your problem completely ?

-- 
viresh

Re: [PATCH v2 2/2] Staging: android/ion: fix sparse warning

[Frans Klaver]

Hi,

Again, your subject is too generic.


On Wed, Jul 12, 2017 at 6:51 AM, Joseph Wright  wrote:
> Declare private function static to fix sparse warning:
>
> ion_cma_heap.c:109:5: warning: symbol '__ion_add_cma_heaps' \
> was not declared. Should it be static?
>
> Signed-off-by: Joseph Wright 
> ---
> Changes in v2:
>   - Split into multiple patches
>
>  drivers/staging/android/ion/ion_cma_heap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
> b/drivers/staging/android/ion/ion_cma_heap.c
> index a0949bc..c6db9b7 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -106,7 +106,7 @@ static struct ion_heap *__ion_cma_heap_create(struct cma 
> *cma)
> return _heap->heap;
>  }
>
> -int __ion_add_cma_heaps(struct cma *cma, void *data)
> +static int __ion_add_cma_heaps(struct cma *cma, void *data)
>  {
> struct ion_heap *heap;
>
> --
> 2.9.3
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 2/2] Staging: android/ion: fix sparse warning

[Frans Klaver]

Hi,

Again, your subject is too generic.


On Wed, Jul 12, 2017 at 6:51 AM, Joseph Wright  wrote:
> Declare private function static to fix sparse warning:
>
> ion_cma_heap.c:109:5: warning: symbol '__ion_add_cma_heaps' \
> was not declared. Should it be static?
>
> Signed-off-by: Joseph Wright 
> ---
> Changes in v2:
>   - Split into multiple patches
>
>  drivers/staging/android/ion/ion_cma_heap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
> b/drivers/staging/android/ion/ion_cma_heap.c
> index a0949bc..c6db9b7 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -106,7 +106,7 @@ static struct ion_heap *__ion_cma_heap_create(struct cma 
> *cma)
> return _heap->heap;
>  }
>
> -int __ion_add_cma_heaps(struct cma *cma, void *data)
> +static int __ion_add_cma_heaps(struct cma *cma, void *data)
>  {
> struct ion_heap *heap;
>
> --
> 2.9.3
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

[Li, Aubrey]

On 2017/7/12 13:03, Paul E. McKenney wrote:
> On Wed, Jul 12, 2017 at 11:19:59AM +0800, Li, Aubrey wrote:
>> On 2017/7/12 2:11, Paul E. McKenney wrote:
>>> On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
 On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
>> From: Aubrey Li 
>>
>> The system will enter a fast idle loop if the predicted idle period
>> is shorter than the threshold.
>> ---
>>  kernel/sched/idle.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
>> index cf6c11f..16a766c 100644
>> --- a/kernel/sched/idle.c
>> +++ b/kernel/sched/idle.c
>> @@ -280,6 +280,8 @@ static void cpuidle_generic(void)
>>   */
>>  static void do_idle(void)
>>  {
>> +unsigned int predicted_idle_us;
>> +unsigned int short_idle_threshold = jiffies_to_usecs(1) / 2;
>>  /*
>>   * If the arch has a polling bit, we maintain an invariant:
>>   *
>> @@ -291,7 +293,12 @@ static void do_idle(void)
>>
>>  __current_set_polling();
>>
>> -cpuidle_generic();
>> +predicted_idle_us = cpuidle_predict();
>> +
>> +if (likely(predicted_idle_us < short_idle_threshold))
>> +cpuidle_fast();
>
> What if we get here from nohz_full usermode execution?  In that
> case, if I remember correctly, the scheduling-clock interrupt
> will still be disabled, and would have to be re-enabled before
> we could safely invoke cpuidle_fast().
>
> Or am I missing something here?

 That's a good point. It's partially ok because if the tick is needed
 for something specific, it is not entirely stopped but programmed to that
 deadline.

 Now there is some idle specific code when we enter dynticks-idle. See
 tick_nohz_start_idle(), tick_nohz_stop_idle(), 
 sched_clock_idle_wakeup_event()
 and some subsystems that react differently when we enter dyntick idle
 mode (scheduler_tick_max_deferment) so the tick may need a reevaluation.

 For now I'd rather suggest that we treat full nohz as an exception case 
 here
 and do:

 if (!tick_nohz_full_cpu(smp_processor_id()) && 
 likely(predicted_idle_us < short_idle_threshold))
 cpuidle_fast();

 Ugly but safer!
>>>
>>> Works for me!
>>
>> I guess who enabled full nohz(for example the financial guys who need the 
>> system
>> response as fast as possible) does not like this compromise, ;)
> 
> And some HPC guys and some real-time guys with CPU-bound real-time
> processing, so there are likely quite a few different views on this
> compromise.
> 
>> How about add rcu_idle enter/exit back only for full nohz case in fast idle? 
>> RCU idle
>> is the only risky ops if removing them from fast idle path. Comparing to 
>> adding RCU
>> idle back, going to normal idle path has more overhead IMHO.
> 
> That might work, but I would need to see the actual patch.  Frederic
> Weisbecker should look at it as well.
> 
Okay, let me address the first round of comments and deliver v2 soon.

Thanks,
-Aubrey

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

[Li, Aubrey]

On 2017/7/12 13:03, Paul E. McKenney wrote:
> On Wed, Jul 12, 2017 at 11:19:59AM +0800, Li, Aubrey wrote:
>> On 2017/7/12 2:11, Paul E. McKenney wrote:
>>> On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
 On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
>> From: Aubrey Li 
>>
>> The system will enter a fast idle loop if the predicted idle period
>> is shorter than the threshold.
>> ---
>>  kernel/sched/idle.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
>> index cf6c11f..16a766c 100644
>> --- a/kernel/sched/idle.c
>> +++ b/kernel/sched/idle.c
>> @@ -280,6 +280,8 @@ static void cpuidle_generic(void)
>>   */
>>  static void do_idle(void)
>>  {
>> +unsigned int predicted_idle_us;
>> +unsigned int short_idle_threshold = jiffies_to_usecs(1) / 2;
>>  /*
>>   * If the arch has a polling bit, we maintain an invariant:
>>   *
>> @@ -291,7 +293,12 @@ static void do_idle(void)
>>
>>  __current_set_polling();
>>
>> -cpuidle_generic();
>> +predicted_idle_us = cpuidle_predict();
>> +
>> +if (likely(predicted_idle_us < short_idle_threshold))
>> +cpuidle_fast();
>
> What if we get here from nohz_full usermode execution?  In that
> case, if I remember correctly, the scheduling-clock interrupt
> will still be disabled, and would have to be re-enabled before
> we could safely invoke cpuidle_fast().
>
> Or am I missing something here?

 That's a good point. It's partially ok because if the tick is needed
 for something specific, it is not entirely stopped but programmed to that
 deadline.

 Now there is some idle specific code when we enter dynticks-idle. See
 tick_nohz_start_idle(), tick_nohz_stop_idle(), 
 sched_clock_idle_wakeup_event()
 and some subsystems that react differently when we enter dyntick idle
 mode (scheduler_tick_max_deferment) so the tick may need a reevaluation.

 For now I'd rather suggest that we treat full nohz as an exception case 
 here
 and do:

 if (!tick_nohz_full_cpu(smp_processor_id()) && 
 likely(predicted_idle_us < short_idle_threshold))
 cpuidle_fast();

 Ugly but safer!
>>>
>>> Works for me!
>>
>> I guess who enabled full nohz(for example the financial guys who need the 
>> system
>> response as fast as possible) does not like this compromise, ;)
> 
> And some HPC guys and some real-time guys with CPU-bound real-time
> processing, so there are likely quite a few different views on this
> compromise.
> 
>> How about add rcu_idle enter/exit back only for full nohz case in fast idle? 
>> RCU idle
>> is the only risky ops if removing them from fast idle path. Comparing to 
>> adding RCU
>> idle back, going to normal idle path has more overhead IMHO.
> 
> That might work, but I would need to see the actual patch.  Frederic
> Weisbecker should look at it as well.
> 
Okay, let me address the first round of comments and deliver v2 soon.

Thanks,
-Aubrey

Re: [PATCH v2 1/2] Staging: android/ion: fix sparse warnings

[Frans Klaver]

Hi,

please consider changing your subject to something like

staging: android/ion: declare two functions

Perhaps you can make it more on-topic. It's more useful than "fix
sparse warning"

On Wed, Jul 12, 2017 at 6:51 AM, Joseph Wright  wrote:
> Declare functions to fix sparse warnings:
>
> ion_carveout_heap.c:115:17: warning: symbol 'ion_carveout_heap_create' \
> was not declared. Should it be static?
> ion_chunk_heap.c:120:17: warning: symbol 'ion_chunk_heap_create' \
> was not declared. Should it be static?

And then explain why declaring them is preferred over making them static.

Frans

Re: [PATCH v2 1/2] Staging: android/ion: fix sparse warnings

[Frans Klaver]

Hi,

please consider changing your subject to something like

staging: android/ion: declare two functions

Perhaps you can make it more on-topic. It's more useful than "fix
sparse warning"

On Wed, Jul 12, 2017 at 6:51 AM, Joseph Wright  wrote:
> Declare functions to fix sparse warnings:
>
> ion_carveout_heap.c:115:17: warning: symbol 'ion_carveout_heap_create' \
> was not declared. Should it be static?
> ion_chunk_heap.c:120:17: warning: symbol 'ion_chunk_heap_create' \
> was not declared. Should it be static?

And then explain why declaring them is preferred over making them static.

Frans

[PATCH] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'

[Christophe JAILLET]

We should free 'wgds.pointer' here as done a few lines above in another
error handling path.
It was allocated within 'acpi_evaluate_object()'.

Signed-off-by: Christophe JAILLET 
---
A comment in '/drivers/acpi/acpica/utalloc.c' states that:
/* [...] Note: The caller should use acpi_os_free to free this
 * buffer created via ACPI_ALLOCATE_BUFFER.
 */

So, at the end of this function:
out_free:
kfree(wgds.pointer);
should maybe be:
out_free:
acpi_os_free(wgds.pointer);

If correct, several places should be fixed accordingly.
---
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 24cc406d87ef..56d535ab696f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -1287,8 +1287,10 @@ static int iwl_mvm_sar_get_wgds_table(struct iwl_mvm 
*mvm,
 
entry = _pkg->package.elements[i + 1];
if ((entry->type != ACPI_TYPE_INTEGER) ||
-   (entry->integer.value > U8_MAX))
-   return -EINVAL;
+   (entry->integer.value > U8_MAX)) {
+   ret = -EINVAL;
+   goto out_free;
+   }
 
geo_table->values[i] = entry->integer.value;
}
-- 
2.11.0

[PATCH] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'

[Christophe JAILLET]

We should free 'wgds.pointer' here as done a few lines above in another
error handling path.
It was allocated within 'acpi_evaluate_object()'.

Signed-off-by: Christophe JAILLET 
---
A comment in '/drivers/acpi/acpica/utalloc.c' states that:
/* [...] Note: The caller should use acpi_os_free to free this
 * buffer created via ACPI_ALLOCATE_BUFFER.
 */

So, at the end of this function:
out_free:
kfree(wgds.pointer);
should maybe be:
out_free:
acpi_os_free(wgds.pointer);

If correct, several places should be fixed accordingly.
---
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 24cc406d87ef..56d535ab696f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@ -1287,8 +1287,10 @@ static int iwl_mvm_sar_get_wgds_table(struct iwl_mvm 
*mvm,
 
entry = _pkg->package.elements[i + 1];
if ((entry->type != ACPI_TYPE_INTEGER) ||
-   (entry->integer.value > U8_MAX))
-   return -EINVAL;
+   (entry->integer.value > U8_MAX)) {
+   ret = -EINVAL;
+   goto out_free;
+   }
 
geo_table->values[i] = entry->integer.value;
}
-- 
2.11.0

Re: [PATCH 8/8] Staging: lustre :lustre: include :lustre_compat.h: Prefer using the BIT macro

[Dilger, Andreas]

> On Jul 11, 2017, at 11:08, Greg KH  wrote:
> 
> On Thu, Jul 06, 2017 at 12:43:15PM +0530, Jaya Durga wrote:
>> Replace all instances of (1 << 27) with BIT(27) to fix
>> checkpatch check messages
>> 
>> Signed-off-by: Jaya Durga 
>> ---
>> drivers/staging/lustre/lustre/include/lustre_compat.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/staging/lustre/lustre/include/lustre_compat.h 
>> b/drivers/staging/lustre/lustre/include/lustre_compat.h
>> index da9ce19..686a251 100644
>> --- a/drivers/staging/lustre/lustre/include/lustre_compat.h
>> +++ b/drivers/staging/lustre/lustre/include/lustre_compat.h
>> @@ -43,7 +43,7 @@
>>  * set ATTR_BLOCKS to a high value to avoid any risk of collision with other
>>  * ATTR_* attributes (see bug 13828)
>>  */
>> -#define ATTR_BLOCKS(1 << 27)
>> +#define ATTR_BLOCKSBIT(27)
> 
> Isn't this used in lustre's userspace code?  If so, you can't use the
> BIT() macro there :(
> 
> Please check before you redo this.

The "lustre_compat.h" header was previously used for compatibility between 
different kernel
versions, which is why it is now basically empty.  It isn't used for userspace 
interfaces
as other "compat" headers are in the kernel.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH 8/8] Staging: lustre :lustre: include :lustre_compat.h: Prefer using the BIT macro

[Dilger, Andreas]

> On Jul 11, 2017, at 11:08, Greg KH  wrote:
> 
> On Thu, Jul 06, 2017 at 12:43:15PM +0530, Jaya Durga wrote:
>> Replace all instances of (1 << 27) with BIT(27) to fix
>> checkpatch check messages
>> 
>> Signed-off-by: Jaya Durga 
>> ---
>> drivers/staging/lustre/lustre/include/lustre_compat.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/staging/lustre/lustre/include/lustre_compat.h 
>> b/drivers/staging/lustre/lustre/include/lustre_compat.h
>> index da9ce19..686a251 100644
>> --- a/drivers/staging/lustre/lustre/include/lustre_compat.h
>> +++ b/drivers/staging/lustre/lustre/include/lustre_compat.h
>> @@ -43,7 +43,7 @@
>>  * set ATTR_BLOCKS to a high value to avoid any risk of collision with other
>>  * ATTR_* attributes (see bug 13828)
>>  */
>> -#define ATTR_BLOCKS(1 << 27)
>> +#define ATTR_BLOCKSBIT(27)
> 
> Isn't this used in lustre's userspace code?  If so, you can't use the
> BIT() macro there :(
> 
> Please check before you redo this.

The "lustre_compat.h" header was previously used for compatibility between 
different kernel
versions, which is why it is now basically empty.  It isn't used for userspace 
interfaces
as other "compat" headers are in the kernel.

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH 3/4] Staging: Lustre Fixing multiline block comments in lnetst.h

[Dilger, Andreas]

On Jul 11, 2017, at 11:14, Greg Kroah-Hartman  
wrote:
> 
> On Fri, Jul 07, 2017 at 01:47:04AM +, Craig Inches wrote:
>> This fixes multiple block statements found not to match
>> style as per checkpatch
>> 
>> Signed-off-by: Craig Inches 
>> ---
>> drivers/staging/lustre/include/linux/lnet/lnetst.h | 129 
>> +
>> 1 file changed, 81 insertions(+), 48 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/include/linux/lnet/lnetst.h 
>> b/drivers/staging/lustre/include/linux/lnet/lnetst.h
>> index ea736f8d5231..a4f9ff01d458 100644
>> --- a/drivers/staging/lustre/include/linux/lnet/lnetst.h
>> +++ b/drivers/staging/lustre/include/linux/lnet/lnetst.h
>> @@ -54,7 +54,8 @@
>> #define LSTIO_GROUP_ADD  0xC10   /* add group */
>> #define LSTIO_GROUP_LIST 0xC11   /* list all groups in session */
>> #define LSTIO_GROUP_INFO 0xC12   /* query default information of
>> - * specified group */
>> + * specified group
>> + */
>> #define LSTIO_GROUP_DEL  0xC13   /* delete group */
>> #define LSTIO_NODES_ADD  0xC14   /* add nodes to specified group 
>> */
>> #define LSTIO_GROUP_UPDATE  0xC15/* update group */
>> @@ -102,27 +103,32 @@ struct lstcon_test_ent {
>>  int tse_type;   /* test type */
>>  int tse_loop;   /* loop count */
>>  int tse_concur; /* concurrency of test */
>> -};  /*** test summary entry, for
>> - *** list_batch command */
>> +};  /* test summary entry, for
>> + * list_batch command
>> + */
> 
> That's odd, what was the *** stuff for?
> 
> I'd like to get a lustre maintainer's ack for all of these before I
> apply them...

It's nothing that I know about.  We used DOxygen to comment the code and 
generate docs,
but the "***" isn't any markup that I'm familiar with.

Reviewed-by: Andreas Dilger 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH 3/4] Staging: Lustre Fixing multiline block comments in lnetst.h

[Dilger, Andreas]

On Jul 11, 2017, at 11:14, Greg Kroah-Hartman  
wrote:
> 
> On Fri, Jul 07, 2017 at 01:47:04AM +, Craig Inches wrote:
>> This fixes multiple block statements found not to match
>> style as per checkpatch
>> 
>> Signed-off-by: Craig Inches 
>> ---
>> drivers/staging/lustre/include/linux/lnet/lnetst.h | 129 
>> +
>> 1 file changed, 81 insertions(+), 48 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/include/linux/lnet/lnetst.h 
>> b/drivers/staging/lustre/include/linux/lnet/lnetst.h
>> index ea736f8d5231..a4f9ff01d458 100644
>> --- a/drivers/staging/lustre/include/linux/lnet/lnetst.h
>> +++ b/drivers/staging/lustre/include/linux/lnet/lnetst.h
>> @@ -54,7 +54,8 @@
>> #define LSTIO_GROUP_ADD  0xC10   /* add group */
>> #define LSTIO_GROUP_LIST 0xC11   /* list all groups in session */
>> #define LSTIO_GROUP_INFO 0xC12   /* query default information of
>> - * specified group */
>> + * specified group
>> + */
>> #define LSTIO_GROUP_DEL  0xC13   /* delete group */
>> #define LSTIO_NODES_ADD  0xC14   /* add nodes to specified group 
>> */
>> #define LSTIO_GROUP_UPDATE  0xC15/* update group */
>> @@ -102,27 +103,32 @@ struct lstcon_test_ent {
>>  int tse_type;   /* test type */
>>  int tse_loop;   /* loop count */
>>  int tse_concur; /* concurrency of test */
>> -};  /*** test summary entry, for
>> - *** list_batch command */
>> +};  /* test summary entry, for
>> + * list_batch command
>> + */
> 
> That's odd, what was the *** stuff for?
> 
> I'd like to get a lustre maintainer's ack for all of these before I
> apply them...

It's nothing that I know about.  We used DOxygen to comment the code and 
generate docs,
but the "***" isn't any markup that I'm familiar with.

Reviewed-by: Andreas Dilger 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH 0/3] USB Mux support for Chipidea

[Peter Rosin]

On 2017-07-12 03:02, Stephen Boyd wrote:
> This patchset adds support for the TC7USB40MU usb mux found on 
> db410c 96boards platforms via the new multiplexer framework and
> hooks that into the chipidea driver. This allows us to properly
> control host or device mode on this board via the sysfs knob.
> 
> So far I've only tested this on db410c, and there are some rough
> edges to finish off before it can merge. Also I'm experiencing
> odd behavior with switching the role while gadget is enabled and
> the micro-usb cable is kept connected. Not sure what's wrong but
> it seems like the gadget never gets disconnected? I'll investigate
> more.
> 
> TODO:
> 
>  1. The mux framework has to be selected for consumers to use it. We'll
> need some stubs in the consumer header file to allow compilation to
> continue without mux always enabled by consumers.

Instead of "depends on MULTIPLEXER", just add "select MULTIPLEXER"
to the Kconfig. Otherwise, you'll have to convince Linus that we
really do need a Kconfig question for the subsystem :-)

https://lkml.org/lkml/2017/7/4/118

>  2. We probably need some sort of mux_control_get_optional() API so that
> we know if there was an error getting the mux control, instead of just
> ignoring errors. For now I can pass up EPROBE_DEFER errors and ignore
> other errors and consider it "missing from DT".

Yes, mux_control_get_optional should be easy to add.

>  3. Maybe we can get rid of the mux driver and just use mux-gpio.c with
> a compatible string update? I split it off because we may want to
> support the "S" pin on the TC7USB40MU one day that shuts off both
> mux outputs.

Maybe no need for a compatible update either, if it works to do something
like this in the DT?

usb_switch: usb-switch {
compatible = "gpio-mux";
mux-gpios = <_gpios 4 GPIO_ACTIVE_HIGH>,
<_gpios XXX GPIO_ACTIVE_XXX>;
idle-state = <2>;
#mux-control-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <_sw_sel_pm>;
};

But I obviously know little about how things are wired and really works,
so that might be totally off...

Otherwise, maybe a generic mux-pinctrl driver would do the trick?
(compare with drivers/i2c/muxes/i2c-mux-pinctrl.c)

Cheers,
peda

>  4. The userspace side of things is murky. What is expected to go and toggle
> the host/gadget side of things in userspace at this very specific location
> for chipidea devices?
> 
> Stephen Boyd (3):
>   usb: misc: Add a driver for TC7USB40MU
>   usb: chipidea: Hook into mux framework to toggle usb switch
>   arm64: dts: qcom: Collapse usb support into one node
> 
>  .../devicetree/bindings/usb/ci-hdrc-usb2.txt   |  8 +++
>  .../devicetree/bindings/usb/toshiba,tc7usb40mu.txt | 31 +
>  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 39 +++-
>  arch/arm64/boot/dts/qcom/msm8916.dtsi  | 62 +-
>  drivers/usb/chipidea/core.c| 17 +
>  drivers/usb/chipidea/host.c| 10 +++
>  drivers/usb/chipidea/udc.c | 11 
>  drivers/usb/misc/Kconfig   | 11 
>  drivers/usb/misc/Makefile  |  1 +
>  drivers/usb/misc/tc7usb40mu.c  | 74 
> ++
>  include/linux/usb/chipidea.h   | 14 
>  11 files changed, 228 insertions(+), 50 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt
>  create mode 100644 drivers/usb/misc/tc7usb40mu.c
> 

Re: [PATCH 0/3] USB Mux support for Chipidea

[Peter Rosin]

On 2017-07-12 03:02, Stephen Boyd wrote:
> This patchset adds support for the TC7USB40MU usb mux found on 
> db410c 96boards platforms via the new multiplexer framework and
> hooks that into the chipidea driver. This allows us to properly
> control host or device mode on this board via the sysfs knob.
> 
> So far I've only tested this on db410c, and there are some rough
> edges to finish off before it can merge. Also I'm experiencing
> odd behavior with switching the role while gadget is enabled and
> the micro-usb cable is kept connected. Not sure what's wrong but
> it seems like the gadget never gets disconnected? I'll investigate
> more.
> 
> TODO:
> 
>  1. The mux framework has to be selected for consumers to use it. We'll
> need some stubs in the consumer header file to allow compilation to
> continue without mux always enabled by consumers.

Instead of "depends on MULTIPLEXER", just add "select MULTIPLEXER"
to the Kconfig. Otherwise, you'll have to convince Linus that we
really do need a Kconfig question for the subsystem :-)

https://lkml.org/lkml/2017/7/4/118

>  2. We probably need some sort of mux_control_get_optional() API so that
> we know if there was an error getting the mux control, instead of just
> ignoring errors. For now I can pass up EPROBE_DEFER errors and ignore
> other errors and consider it "missing from DT".

Yes, mux_control_get_optional should be easy to add.

>  3. Maybe we can get rid of the mux driver and just use mux-gpio.c with
> a compatible string update? I split it off because we may want to
> support the "S" pin on the TC7USB40MU one day that shuts off both
> mux outputs.

Maybe no need for a compatible update either, if it works to do something
like this in the DT?

usb_switch: usb-switch {
compatible = "gpio-mux";
mux-gpios = <_gpios 4 GPIO_ACTIVE_HIGH>,
<_gpios XXX GPIO_ACTIVE_XXX>;
idle-state = <2>;
#mux-control-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <_sw_sel_pm>;
};

But I obviously know little about how things are wired and really works,
so that might be totally off...

Otherwise, maybe a generic mux-pinctrl driver would do the trick?
(compare with drivers/i2c/muxes/i2c-mux-pinctrl.c)

Cheers,
peda

>  4. The userspace side of things is murky. What is expected to go and toggle
> the host/gadget side of things in userspace at this very specific location
> for chipidea devices?
> 
> Stephen Boyd (3):
>   usb: misc: Add a driver for TC7USB40MU
>   usb: chipidea: Hook into mux framework to toggle usb switch
>   arm64: dts: qcom: Collapse usb support into one node
> 
>  .../devicetree/bindings/usb/ci-hdrc-usb2.txt   |  8 +++
>  .../devicetree/bindings/usb/toshiba,tc7usb40mu.txt | 31 +
>  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 39 +++-
>  arch/arm64/boot/dts/qcom/msm8916.dtsi  | 62 +-
>  drivers/usb/chipidea/core.c| 17 +
>  drivers/usb/chipidea/host.c| 10 +++
>  drivers/usb/chipidea/udc.c | 11 
>  drivers/usb/misc/Kconfig   | 11 
>  drivers/usb/misc/Makefile  |  1 +
>  drivers/usb/misc/tc7usb40mu.c  | 74 
> ++
>  include/linux/usb/chipidea.h   | 14 
>  11 files changed, 228 insertions(+), 50 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt
>  create mode 100644 drivers/usb/misc/tc7usb40mu.c
> 

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

[Paul E. McKenney]

On Wed, Jul 12, 2017 at 11:19:59AM +0800, Li, Aubrey wrote:
> On 2017/7/12 2:11, Paul E. McKenney wrote:
> > On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
> >> On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote:
> >>> On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
>  From: Aubrey Li 
> 
>  The system will enter a fast idle loop if the predicted idle period
>  is shorter than the threshold.
>  ---
>   kernel/sched/idle.c | 9 -
>   1 file changed, 8 insertions(+), 1 deletion(-)
> 
>  diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
>  index cf6c11f..16a766c 100644
>  --- a/kernel/sched/idle.c
>  +++ b/kernel/sched/idle.c
>  @@ -280,6 +280,8 @@ static void cpuidle_generic(void)
>    */
>   static void do_idle(void)
>   {
>  +unsigned int predicted_idle_us;
>  +unsigned int short_idle_threshold = jiffies_to_usecs(1) / 2;
>   /*
>    * If the arch has a polling bit, we maintain an invariant:
>    *
>  @@ -291,7 +293,12 @@ static void do_idle(void)
> 
>   __current_set_polling();
> 
>  -cpuidle_generic();
>  +predicted_idle_us = cpuidle_predict();
>  +
>  +if (likely(predicted_idle_us < short_idle_threshold))
>  +cpuidle_fast();
> >>>
> >>> What if we get here from nohz_full usermode execution?  In that
> >>> case, if I remember correctly, the scheduling-clock interrupt
> >>> will still be disabled, and would have to be re-enabled before
> >>> we could safely invoke cpuidle_fast().
> >>>
> >>> Or am I missing something here?
> >>
> >> That's a good point. It's partially ok because if the tick is needed
> >> for something specific, it is not entirely stopped but programmed to that
> >> deadline.
> >>
> >> Now there is some idle specific code when we enter dynticks-idle. See
> >> tick_nohz_start_idle(), tick_nohz_stop_idle(), 
> >> sched_clock_idle_wakeup_event()
> >> and some subsystems that react differently when we enter dyntick idle
> >> mode (scheduler_tick_max_deferment) so the tick may need a reevaluation.
> >>
> >> For now I'd rather suggest that we treat full nohz as an exception case 
> >> here
> >> and do:
> >>
> >> if (!tick_nohz_full_cpu(smp_processor_id()) && 
> >> likely(predicted_idle_us < short_idle_threshold))
> >> cpuidle_fast();
> >>
> >> Ugly but safer!
> > 
> > Works for me!
> 
> I guess who enabled full nohz(for example the financial guys who need the 
> system
> response as fast as possible) does not like this compromise, ;)

And some HPC guys and some real-time guys with CPU-bound real-time
processing, so there are likely quite a few different views on this
compromise.

> How about add rcu_idle enter/exit back only for full nohz case in fast idle? 
> RCU idle
> is the only risky ops if removing them from fast idle path. Comparing to 
> adding RCU
> idle back, going to normal idle path has more overhead IMHO.

That might work, but I would need to see the actual patch.  Frederic
Weisbecker should look at it as well.

Thanx, Paul

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

[Paul E. McKenney]

On Wed, Jul 12, 2017 at 11:19:59AM +0800, Li, Aubrey wrote:
> On 2017/7/12 2:11, Paul E. McKenney wrote:
> > On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
> >> On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote:
> >>> On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
>  From: Aubrey Li 
> 
>  The system will enter a fast idle loop if the predicted idle period
>  is shorter than the threshold.
>  ---
>   kernel/sched/idle.c | 9 -
>   1 file changed, 8 insertions(+), 1 deletion(-)
> 
>  diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
>  index cf6c11f..16a766c 100644
>  --- a/kernel/sched/idle.c
>  +++ b/kernel/sched/idle.c
>  @@ -280,6 +280,8 @@ static void cpuidle_generic(void)
>    */
>   static void do_idle(void)
>   {
>  +unsigned int predicted_idle_us;
>  +unsigned int short_idle_threshold = jiffies_to_usecs(1) / 2;
>   /*
>    * If the arch has a polling bit, we maintain an invariant:
>    *
>  @@ -291,7 +293,12 @@ static void do_idle(void)
> 
>   __current_set_polling();
> 
>  -cpuidle_generic();
>  +predicted_idle_us = cpuidle_predict();
>  +
>  +if (likely(predicted_idle_us < short_idle_threshold))
>  +cpuidle_fast();
> >>>
> >>> What if we get here from nohz_full usermode execution?  In that
> >>> case, if I remember correctly, the scheduling-clock interrupt
> >>> will still be disabled, and would have to be re-enabled before
> >>> we could safely invoke cpuidle_fast().
> >>>
> >>> Or am I missing something here?
> >>
> >> That's a good point. It's partially ok because if the tick is needed
> >> for something specific, it is not entirely stopped but programmed to that
> >> deadline.
> >>
> >> Now there is some idle specific code when we enter dynticks-idle. See
> >> tick_nohz_start_idle(), tick_nohz_stop_idle(), 
> >> sched_clock_idle_wakeup_event()
> >> and some subsystems that react differently when we enter dyntick idle
> >> mode (scheduler_tick_max_deferment) so the tick may need a reevaluation.
> >>
> >> For now I'd rather suggest that we treat full nohz as an exception case 
> >> here
> >> and do:
> >>
> >> if (!tick_nohz_full_cpu(smp_processor_id()) && 
> >> likely(predicted_idle_us < short_idle_threshold))
> >> cpuidle_fast();
> >>
> >> Ugly but safer!
> > 
> > Works for me!
> 
> I guess who enabled full nohz(for example the financial guys who need the 
> system
> response as fast as possible) does not like this compromise, ;)

And some HPC guys and some real-time guys with CPU-bound real-time
processing, so there are likely quite a few different views on this
compromise.

> How about add rcu_idle enter/exit back only for full nohz case in fast idle? 
> RCU idle
> is the only risky ops if removing them from fast idle path. Comparing to 
> adding RCU
> idle back, going to normal idle path has more overhead IMHO.

That might work, but I would need to see the actual patch.  Frederic
Weisbecker should look at it as well.

Thanx, Paul

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

[Viresh Kumar]

On 11-07-17, 07:14, Joel Fernandes wrote:
> I think the whole point of IOWAIT boost was to solve the issue with a
> long sequence of repeated I/O requests as described in the commit
> message. So IIUC there isn't a usecase for that (increase freq. on
> first request).

Right. So we can take example that Peter gave earlier. Task runs .1 ms and waits
for IO for 1 ms (at max speed). But there is high possibility that the util
update handler gets called within that 1 ms (from non-enqueue paths) and because
you chose to reduce iowait boost from sugov_set_iowait_boost() in your commit,
we can easily end up ignoring iowait boosting.

> Also its just for the first couple of requests in my
> testing and doesn't hurt the performance at all for the intended
> usecase while still not causing transient spikes.

We can have bad enough timing where the util handler gets called right in that 1
ms of IOWAIT period and we will never boost.

> Another approach than setting min in sugov_set_iowait_boost, is, since
> we have already retrieved the current util, we can check if flags ==
> SCHED_CPUFREQ_IOWAIT, then set initial the iowait_boost such that
> (iowait_boost / iowait_boost_max) is aleast equal to (util / max) or
> iowait_boost_min, which ever is lower.

So my concerns weren't only about the initial min value, but also that you
reduce the freq from sugov_set_iowait_boost(). We can discuss what the ideal
value to start with can be.

> This still will not increase
> frequency on the first request, but will ensure the next one will
> benefit.

If there is no non-enqueue path request lands.

> Yes, I've seen that happen in my testing (consecutive iowait).

The CFS scheduler can send a util update request every 1 ms for util updates and
I am not sure why isn't that happening in your case.

How much is the time between two consecutive IOWAIT requests in your case ?
Maybe it is too less (Ofcourse it isn't in your control :). But if we take
Peter's example, then it will surely have a non-enqueue path request between two
IOWAIT requests.

> I
> haven't seen the other case where you have IOWAIT followed by
> non-IOWAIT for a repeated set of IOWAIT requests. Would you more
> comfortable if we moved sugov_set_iowait_boost() after the
> sugov_should_update_freq() ?

That may make us ignore all IOWAIT requests that happen between rate_limit_us
time. And that would be bad IMHO.

> That way if there are consecutive
> requests in the same path, then it most likely rate-limiting will
> prevent such updates. I will also try to collect some stats as you
> suggested to see if how often if at all this can happen.

Completely untested, but what about something like this ? This should get rid of
the spikes you were getting.

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 076a2e31951c..3459f327c94e 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -53,6 +53,7 @@ struct sugov_cpu {
struct update_util_data update_util;
struct sugov_policy *sg_policy;
 
+   bool iowait_boost_pending;
unsigned long iowait_boost;
unsigned long iowait_boost_max;
u64 last_update;
@@ -169,7 +170,12 @@ 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;
+   sg_cpu->iowait_boost_pending = true;
+
+   if (!sg_cpu->iowait_boost) {
+   sg_cpu->iowait_boost = sg_cpu->sg_policy->policy->cur;
+   sg_cpu->iowait_boost >>= 1;
+   }
} else if (sg_cpu->iowait_boost) {
s64 delta_ns = time - sg_cpu->last_update;
 
@@ -182,17 +188,26 @@ static void sugov_set_iowait_boost(struct sugov_cpu 
*sg_cpu, u64 time,
 static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long *util,
   unsigned long *max)
 {
-   unsigned long boost_util = sg_cpu->iowait_boost;
-   unsigned long boost_max = sg_cpu->iowait_boost_max;
+   unsigned long boost_util, boost_max;
 
-   if (!boost_util)
+   if (!sg_cpu->iowait_boost)
return;
 
+   if (sg_cpu->iowait_boost_pending) {
+   sg_cpu->iowait_boost_pending = false;
+   sg_cpu->iowait_boost = min(sg_cpu->iowait_boost << 1,
+  sg_cpu->iowait_boost_max);
+   } else {
+   sg_cpu->iowait_boost >>= 1;
+   }
+
+   boost_util = sg_cpu->iowait_boost;
+   boost_max = sg_cpu->iowait_boost_max;
+
if (*util * boost_max < *max * boost_util) {
*util = boost_util;
*max = boost_max;
}
-   sg_cpu->iowait_boost >>= 1;
 }
 
 #ifdef CONFIG_NO_HZ_COMMON

-- 
viresh

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

[Viresh Kumar]

On 11-07-17, 07:14, Joel Fernandes wrote:
> I think the whole point of IOWAIT boost was to solve the issue with a
> long sequence of repeated I/O requests as described in the commit
> message. So IIUC there isn't a usecase for that (increase freq. on
> first request).

Right. So we can take example that Peter gave earlier. Task runs .1 ms and waits
for IO for 1 ms (at max speed). But there is high possibility that the util
update handler gets called within that 1 ms (from non-enqueue paths) and because
you chose to reduce iowait boost from sugov_set_iowait_boost() in your commit,
we can easily end up ignoring iowait boosting.

> Also its just for the first couple of requests in my
> testing and doesn't hurt the performance at all for the intended
> usecase while still not causing transient spikes.

We can have bad enough timing where the util handler gets called right in that 1
ms of IOWAIT period and we will never boost.

> Another approach than setting min in sugov_set_iowait_boost, is, since
> we have already retrieved the current util, we can check if flags ==
> SCHED_CPUFREQ_IOWAIT, then set initial the iowait_boost such that
> (iowait_boost / iowait_boost_max) is aleast equal to (util / max) or
> iowait_boost_min, which ever is lower.

So my concerns weren't only about the initial min value, but also that you
reduce the freq from sugov_set_iowait_boost(). We can discuss what the ideal
value to start with can be.

> This still will not increase
> frequency on the first request, but will ensure the next one will
> benefit.

If there is no non-enqueue path request lands.

> Yes, I've seen that happen in my testing (consecutive iowait).

The CFS scheduler can send a util update request every 1 ms for util updates and
I am not sure why isn't that happening in your case.

How much is the time between two consecutive IOWAIT requests in your case ?
Maybe it is too less (Ofcourse it isn't in your control :). But if we take
Peter's example, then it will surely have a non-enqueue path request between two
IOWAIT requests.

> I
> haven't seen the other case where you have IOWAIT followed by
> non-IOWAIT for a repeated set of IOWAIT requests. Would you more
> comfortable if we moved sugov_set_iowait_boost() after the
> sugov_should_update_freq() ?

That may make us ignore all IOWAIT requests that happen between rate_limit_us
time. And that would be bad IMHO.

> That way if there are consecutive
> requests in the same path, then it most likely rate-limiting will
> prevent such updates. I will also try to collect some stats as you
> suggested to see if how often if at all this can happen.

Completely untested, but what about something like this ? This should get rid of
the spikes you were getting.

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 076a2e31951c..3459f327c94e 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -53,6 +53,7 @@ struct sugov_cpu {
struct update_util_data update_util;
struct sugov_policy *sg_policy;
 
+   bool iowait_boost_pending;
unsigned long iowait_boost;
unsigned long iowait_boost_max;
u64 last_update;
@@ -169,7 +170,12 @@ 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;
+   sg_cpu->iowait_boost_pending = true;
+
+   if (!sg_cpu->iowait_boost) {
+   sg_cpu->iowait_boost = sg_cpu->sg_policy->policy->cur;
+   sg_cpu->iowait_boost >>= 1;
+   }
} else if (sg_cpu->iowait_boost) {
s64 delta_ns = time - sg_cpu->last_update;
 
@@ -182,17 +188,26 @@ static void sugov_set_iowait_boost(struct sugov_cpu 
*sg_cpu, u64 time,
 static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long *util,
   unsigned long *max)
 {
-   unsigned long boost_util = sg_cpu->iowait_boost;
-   unsigned long boost_max = sg_cpu->iowait_boost_max;
+   unsigned long boost_util, boost_max;
 
-   if (!boost_util)
+   if (!sg_cpu->iowait_boost)
return;
 
+   if (sg_cpu->iowait_boost_pending) {
+   sg_cpu->iowait_boost_pending = false;
+   sg_cpu->iowait_boost = min(sg_cpu->iowait_boost << 1,
+  sg_cpu->iowait_boost_max);
+   } else {
+   sg_cpu->iowait_boost >>= 1;
+   }
+
+   boost_util = sg_cpu->iowait_boost;
+   boost_max = sg_cpu->iowait_boost_max;
+
if (*util * boost_max < *max * boost_util) {
*util = boost_util;
*max = boost_max;
}
-   sg_cpu->iowait_boost >>= 1;
 }
 
 #ifdef CONFIG_NO_HZ_COMMON

-- 
viresh

[PATCH v2 2/2] Staging: android/ion: fix sparse warning

[Joseph Wright]

Declare private function static to fix sparse warning:

ion_cma_heap.c:109:5: warning: symbol '__ion_add_cma_heaps' \
was not declared. Should it be static?

Signed-off-by: Joseph Wright 
---
Changes in v2:
  - Split into multiple patches

 drivers/staging/android/ion/ion_cma_heap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index a0949bc..c6db9b7 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -106,7 +106,7 @@ static struct ion_heap *__ion_cma_heap_create(struct cma 
*cma)
return _heap->heap;
 }
 
-int __ion_add_cma_heaps(struct cma *cma, void *data)
+static int __ion_add_cma_heaps(struct cma *cma, void *data)
 {
struct ion_heap *heap;
 
-- 
2.9.3

[PATCH v2 2/2] Staging: android/ion: fix sparse warning

[Joseph Wright]

Declare private function static to fix sparse warning:

ion_cma_heap.c:109:5: warning: symbol '__ion_add_cma_heaps' \
was not declared. Should it be static?

Signed-off-by: Joseph Wright 
---
Changes in v2:
  - Split into multiple patches

 drivers/staging/android/ion/ion_cma_heap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index a0949bc..c6db9b7 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -106,7 +106,7 @@ static struct ion_heap *__ion_cma_heap_create(struct cma 
*cma)
return _heap->heap;
 }
 
-int __ion_add_cma_heaps(struct cma *cma, void *data)
+static int __ion_add_cma_heaps(struct cma *cma, void *data)
 {
struct ion_heap *heap;
 
-- 
2.9.3

[PATCH v2 0/2] Staging: android/ion: fix sparse warnings

[Joseph Wright]

Split sparse warning fixes into multiple patches.

Joseph Wright (2):
  Staging: android/ion: fix sparse warnings
  Staging: android/ion: fix sparse warning

 drivers/staging/android/ion/ion.h  | 4 
 drivers/staging/android/ion/ion_cma_heap.c | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

-- 
2.9.3

[PATCH v2 0/2] Staging: android/ion: fix sparse warnings

[Joseph Wright]

Split sparse warning fixes into multiple patches.

Joseph Wright (2):
  Staging: android/ion: fix sparse warnings
  Staging: android/ion: fix sparse warning

 drivers/staging/android/ion/ion.h  | 4 
 drivers/staging/android/ion/ion_cma_heap.c | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

-- 
2.9.3

[PATCH v2 1/2] Staging: android/ion: fix sparse warnings

[Joseph Wright]

Declare functions to fix sparse warnings:

ion_carveout_heap.c:115:17: warning: symbol 'ion_carveout_heap_create' \
was not declared. Should it be static?
ion_chunk_heap.c:120:17: warning: symbol 'ion_chunk_heap_create' \
was not declared. Should it be static?

Signed-off-by: Joseph Wright 
---
Changes in v2:
  - Split into multiple patches

 drivers/staging/android/ion/ion.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index fa9ed81..fda1e91 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -358,4 +358,8 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg);
 
 int ion_query_heaps(struct ion_heap_query *query);
 
+struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data);
+
+struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data);
+
 #endif /* _ION_H */
-- 
2.9.3

[PATCH v2 1/2] Staging: android/ion: fix sparse warnings

[Joseph Wright]

Declare functions to fix sparse warnings:

ion_carveout_heap.c:115:17: warning: symbol 'ion_carveout_heap_create' \
was not declared. Should it be static?
ion_chunk_heap.c:120:17: warning: symbol 'ion_chunk_heap_create' \
was not declared. Should it be static?

Signed-off-by: Joseph Wright 
---
Changes in v2:
  - Split into multiple patches

 drivers/staging/android/ion/ion.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index fa9ed81..fda1e91 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -358,4 +358,8 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg);
 
 int ion_query_heaps(struct ion_heap_query *query);
 
+struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data);
+
+struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data);
+
 #endif /* _ION_H */
-- 
2.9.3

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Stephen Rothwell]

Hi all,

On Sat, 06 May 2017 11:12:36 -0700 James Bottomley 
 wrote:
>
> What about resending the conflict reminders at -rc7 ... that way we
> only have a week or two to forget again?

OK, I attempted to do that this time ... I wonder if it made a
difference :-)

> The other issue is that one of the potential trees only got notified
> directly (the char-misc one) because the tpmdd tree takes an indirect
> pull route.  I'm not sure what we can do about this one.

I have also tried (in most cases) to notify the effected maintainers
that ask Linus to pull.
 
-- 
Cheers,
Stephen Rothwell

Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

[Stephen Rothwell]

Hi all,

On Sat, 06 May 2017 11:12:36 -0700 James Bottomley 
 wrote:
>
> What about resending the conflict reminders at -rc7 ... that way we
> only have a week or two to forget again?

OK, I attempted to do that this time ... I wonder if it made a
difference :-)

> The other issue is that one of the potential trees only got notified
> directly (the char-misc one) because the tpmdd tree takes an indirect
> pull route.  I'm not sure what we can do about this one.

I have also tried (in most cases) to notify the effected maintainers
that ask Linus to pull.
 
-- 
Cheers,
Stephen Rothwell

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

[Tushar Dave]

On 07/11/2017 09:02 PM, David Miller wrote:

From: Tushar Dave 
Date: Tue, 11 Jul 2017 20:43:39 -0700


Yes, indeed the bug is in Linus's tree. However, 'sparc' tree doesn't
have DMA API change (e.g. commit b02c2b0bfd7ae) yet that introduced
the panic.


You can simply make a note of this when you send the bug fix to me.:( yeah, I 
should have mentioned this when I sent patch to you. My bad.

Will make sure to left you a note for this kid of occurrence in future!

-Tushar


--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tushar Dave]

On 07/11/2017 09:02 PM, David Miller wrote:

From: Tushar Dave 
Date: Tue, 11 Jul 2017 20:43:39 -0700


Yes, indeed the bug is in Linus's tree. However, 'sparc' tree doesn't
have DMA API change (e.g. commit b02c2b0bfd7ae) yet that introduced
the panic.


You can simply make a note of this when you send the bug fix to me.:( yeah, I 
should have mentioned this when I sent patch to you. My bad.

Will make sure to left you a note for this kid of occurrence in future!

-Tushar


--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 2/4] net-next: mediatek: add platform data to adapt into various hardware

[Florian Fainelli]

On 07/11/2017 08:37 PM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> This patch is the preparation patch in order to adapt into various
> hardware through adding platform data which holds specific characteristics
> among MediaTek SoCs and introducing the unified clock handler for those
> distinct clock requirements depending on different features such as
> TRGMII and SGMII getting support on the target SoC. And finally, add
> enhancement with given the generic description for Kconfig and remove the
> unnecessary machine type dependency in Makefile.
> 
> Signed-off-by: Sean Wang 
> ---

>   if (dev->phydev->link)
> @@ -1837,6 +1838,39 @@ static void ethsys_reset(struct mtk_eth *eth, u32 
> reset_bits)
>   mdelay(10);
>  }
>  
> +static void mtk_clk_disable(struct mtk_eth *eth)
> +{
> + int clk;
> +
> + for (clk = MTK_CLK_MAX - 1; clk >= 0; clk--) {
> + if (eth->clks[clk])
> + clk_disable_unprepare(eth->clks[clk]);
> + }

The clock framework works just fine with NULL clk references, no need to
check that.

> +}

There are now (or will be soon in clk-next) bulk accessors that you may
consider using for this.

> +
> +static int mtk_clk_enable(struct mtk_eth *eth)
> +{
> + int clk, ret;
> +
> + for (clk = 0; clk < MTK_CLK_MAX ; clk++) {
> + if (eth->clks[clk]) {
> + ret = clk_prepare_enable(eth->clks[clk]);
> + if (ret)
> + goto err_disable_clks;
> + }
> + }

Same here.
-- 
Florian

Re: [PATCH net-next 2/4] net-next: mediatek: add platform data to adapt into various hardware

[Florian Fainelli]

On 07/11/2017 08:37 PM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> This patch is the preparation patch in order to adapt into various
> hardware through adding platform data which holds specific characteristics
> among MediaTek SoCs and introducing the unified clock handler for those
> distinct clock requirements depending on different features such as
> TRGMII and SGMII getting support on the target SoC. And finally, add
> enhancement with given the generic description for Kconfig and remove the
> unnecessary machine type dependency in Makefile.
> 
> Signed-off-by: Sean Wang 
> ---

>   if (dev->phydev->link)
> @@ -1837,6 +1838,39 @@ static void ethsys_reset(struct mtk_eth *eth, u32 
> reset_bits)
>   mdelay(10);
>  }
>  
> +static void mtk_clk_disable(struct mtk_eth *eth)
> +{
> + int clk;
> +
> + for (clk = MTK_CLK_MAX - 1; clk >= 0; clk--) {
> + if (eth->clks[clk])
> + clk_disable_unprepare(eth->clks[clk]);
> + }

The clock framework works just fine with NULL clk references, no need to
check that.

> +}

There are now (or will be soon in clk-next) bulk accessors that you may
consider using for this.

> +
> +static int mtk_clk_enable(struct mtk_eth *eth)
> +{
> + int clk, ret;
> +
> + for (clk = 0; clk < MTK_CLK_MAX ; clk++) {
> + if (eth->clks[clk]) {
> + ret = clk_prepare_enable(eth->clks[clk]);
> + if (ret)
> + goto err_disable_clks;
> + }
> + }

Same here.
-- 
Florian

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

[Li, Aubrey]

On 2017/7/12 0:34, Peter Zijlstra wrote:
> On Tue, Jul 11, 2017 at 06:09:27PM +0200, Frederic Weisbecker wrote:
> 
 - tick_nohz_idle_enter costs 7058ns - 10726ns
 - tick_nohz_idle_exit costs 8372ns - 20850ns
>>>
>>> Right, those are horrible expensive, but skipping them isn't 'hard', the
>>> only tricky bit is finding a condition that makes sense.
>>
>> Note you can statically disable it with nohz=0 boot parameter.
> 
> Yeah, but that's bad for power usage, nobody wants that.
> 
>>> See Mike's patch: https://patchwork.kernel.org/patch/2839221/
>>>
>>> Combined with the above, and possibly a better condition, that should
>>> get rid of most of this.
>>
>> Such a patch could work well if the decision from the scheduler to not stop 
>> the tick
>> happens on idle entry.
>>
>> Now if sched_needs_cpu() first allows to stop the tick then refuses it later
>> in the end of an idle IRQ, this won't have the desired effect. As long as 
>> ts->tick_stopped=1,
>> it stays so until we really restart the tick. So the whole costly nohz 
>> machinery stays on.
>>
>> I guess it doesn't matter though, as we are talking about making fast idle 
>> entry so the
>> decision not to stop the tick is likely to be done once on idle entry, when 
>> ts->tick_stopped=0.
>>
>> One exception though: if the tick is already stopped when we enter idle 
>> (full nohz case). And
>> BTW stopping the tick outside idle shouldn't be concerned here.
>>
>> So I'd rather put that on can_stop_idle_tick().
> 
> Mike's patch much predates the existence of that function I think ;-) But
> sure..
> 

Okay, the difference is that Mike's patch uses a very simple algorithm to make 
the decision.

/*
 * delta is wakeup_timestamp - idle_timestamp
 */
update_avg(>avg_idle, delta);
...
static void update_avg(u64 *avg, u64 sample)
{
s64 diff = sample - *avg;
*avg += diff >> 3;
}

While my proposal is trying to leverage the prediction functionality of the 
existing idle menu
governor, which works very well for a long time.

I know the the code change is big and the running overhead is a bit higher than 
rq->avg_idle, but
should we make a comparison for some typical workloads?

Thanks,
-Aubrey

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

[Li, Aubrey]

On 2017/7/12 0:34, Peter Zijlstra wrote:
> On Tue, Jul 11, 2017 at 06:09:27PM +0200, Frederic Weisbecker wrote:
> 
 - tick_nohz_idle_enter costs 7058ns - 10726ns
 - tick_nohz_idle_exit costs 8372ns - 20850ns
>>>
>>> Right, those are horrible expensive, but skipping them isn't 'hard', the
>>> only tricky bit is finding a condition that makes sense.
>>
>> Note you can statically disable it with nohz=0 boot parameter.
> 
> Yeah, but that's bad for power usage, nobody wants that.
> 
>>> See Mike's patch: https://patchwork.kernel.org/patch/2839221/
>>>
>>> Combined with the above, and possibly a better condition, that should
>>> get rid of most of this.
>>
>> Such a patch could work well if the decision from the scheduler to not stop 
>> the tick
>> happens on idle entry.
>>
>> Now if sched_needs_cpu() first allows to stop the tick then refuses it later
>> in the end of an idle IRQ, this won't have the desired effect. As long as 
>> ts->tick_stopped=1,
>> it stays so until we really restart the tick. So the whole costly nohz 
>> machinery stays on.
>>
>> I guess it doesn't matter though, as we are talking about making fast idle 
>> entry so the
>> decision not to stop the tick is likely to be done once on idle entry, when 
>> ts->tick_stopped=0.
>>
>> One exception though: if the tick is already stopped when we enter idle 
>> (full nohz case). And
>> BTW stopping the tick outside idle shouldn't be concerned here.
>>
>> So I'd rather put that on can_stop_idle_tick().
> 
> Mike's patch much predates the existence of that function I think ;-) But
> sure..
> 

Okay, the difference is that Mike's patch uses a very simple algorithm to make 
the decision.

/*
 * delta is wakeup_timestamp - idle_timestamp
 */
update_avg(>avg_idle, delta);
...
static void update_avg(u64 *avg, u64 sample)
{
s64 diff = sample - *avg;
*avg += diff >> 3;
}

While my proposal is trying to leverage the prediction functionality of the 
existing idle menu
governor, which works very well for a long time.

I know the the code change is big and the running overhead is a bit higher than 
rq->avg_idle, but
should we make a comparison for some typical workloads?

Thanks,
-Aubrey

Remove __end_entry_SYSENTER_compat?

[Borislav Petkov]

Anyone think this is an OK-ish idea?

It saves us the global symbol but requires the two functions to remained
glued together. :-\

---
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index e1721dafbcb1..262519da8661 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -131,7 +131,6 @@ ENTRY(entry_SYSENTER_compat)
pushq   $X86_EFLAGS_FIXED
popfq
jmp .Lsysenter_flags_fixed
-GLOBAL(__end_entry_SYSENTER_compat)
 ENDPROC(entry_SYSENTER_compat)
 
 /*
@@ -180,6 +179,9 @@ ENDPROC(entry_SYSENTER_compat)
  * edi  arg5
  * esp  user stack
  * 0(%esp) arg6
+ *
+ * DO NOT! move this function and the above before adjusting
+ * is_sysenter_singlestep().
  */
 ENTRY(entry_SYSCALL_compat)
/* Interrupts are off on entry. */
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index 8d3964fc5f91..afdef9f3f0f0 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -21,7 +21,6 @@ void __end_SYSENTER_singlestep_region(void);
 
 #ifdef CONFIG_IA32_EMULATION
 void entry_SYSENTER_compat(void);
-void __end_entry_SYSENTER_compat(void);
 void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
 #endif
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index bf54309b85da..143902ffe9ff 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -668,7 +668,7 @@ static bool is_sysenter_singlestep(struct pt_regs *regs)
(unsigned long)__begin_SYSENTER_singlestep_region;
 #elif defined(CONFIG_IA32_EMULATION)
return (regs->ip - (unsigned long)entry_SYSENTER_compat) <
-   (unsigned long)__end_entry_SYSENTER_compat -
+   (unsigned long)entry_SYSCALL_compat -
(unsigned long)entry_SYSENTER_compat;
 #else
return false;

-- 
Regards/Gruss,
Boris.

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

Remove __end_entry_SYSENTER_compat?

[Borislav Petkov]

Anyone think this is an OK-ish idea?

It saves us the global symbol but requires the two functions to remained
glued together. :-\

---
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index e1721dafbcb1..262519da8661 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -131,7 +131,6 @@ ENTRY(entry_SYSENTER_compat)
pushq   $X86_EFLAGS_FIXED
popfq
jmp .Lsysenter_flags_fixed
-GLOBAL(__end_entry_SYSENTER_compat)
 ENDPROC(entry_SYSENTER_compat)
 
 /*
@@ -180,6 +179,9 @@ ENDPROC(entry_SYSENTER_compat)
  * edi  arg5
  * esp  user stack
  * 0(%esp) arg6
+ *
+ * DO NOT! move this function and the above before adjusting
+ * is_sysenter_singlestep().
  */
 ENTRY(entry_SYSCALL_compat)
/* Interrupts are off on entry. */
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index 8d3964fc5f91..afdef9f3f0f0 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -21,7 +21,6 @@ void __end_SYSENTER_singlestep_region(void);
 
 #ifdef CONFIG_IA32_EMULATION
 void entry_SYSENTER_compat(void);
-void __end_entry_SYSENTER_compat(void);
 void entry_SYSCALL_compat(void);
 void entry_INT80_compat(void);
 #endif
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index bf54309b85da..143902ffe9ff 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -668,7 +668,7 @@ static bool is_sysenter_singlestep(struct pt_regs *regs)
(unsigned long)__begin_SYSENTER_singlestep_region;
 #elif defined(CONFIG_IA32_EMULATION)
return (regs->ip - (unsigned long)entry_SYSENTER_compat) <
-   (unsigned long)__end_entry_SYSENTER_compat -
+   (unsigned long)entry_SYSCALL_compat -
(unsigned long)entry_SYSENTER_compat;
 #else
return false;

-- 
Regards/Gruss,
Boris.

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

Re: in:imklog segfault in 4.12+git on most sparc64's

[David Miller]

From: Al Viro 
Date: Wed, 12 Jul 2017 04:59:45 +0100

> Again, my apologies for format of that all - I'm almost completely
> off-net and while typing an ed script is feasible, context diff is
> too far over the top.  Usimg mutt in ssh session from android is
> not fun, to put it mildly...  

Yes, that might be it.

Meelis, please test this:


fix a braino in compat_sys_getrlimit()

Fixes: commit d9e968cb9f84 "getrlimit()/setrlimit(): move compat to native"
Signed-off-by: Al Viro 
Acked-by: David S. Miller 

diff --git a/kernel/sys.c b/kernel/sys.c
index 73fc0af..2855ee7 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1362,7 +1362,7 @@ COMPAT_SYSCALL_DEFINE2(getrlimit, unsigned int, resource,
 
ret = do_prlimit(current, resource, NULL, );
if (!ret) {
-   struct rlimit r32;
+   struct compat_rlimit r32;
if (r.rlim_cur > COMPAT_RLIM_INFINITY)
r32.rlim_cur = COMPAT_RLIM_INFINITY;
else

Re: in:imklog segfault in 4.12+git on most sparc64's

[David Miller]

From: Al Viro 
Date: Wed, 12 Jul 2017 04:59:45 +0100

> Again, my apologies for format of that all - I'm almost completely
> off-net and while typing an ed script is feasible, context diff is
> too far over the top.  Usimg mutt in ssh session from android is
> not fun, to put it mildly...  

Yes, that might be it.

Meelis, please test this:


fix a braino in compat_sys_getrlimit()

Fixes: commit d9e968cb9f84 "getrlimit()/setrlimit(): move compat to native"
Signed-off-by: Al Viro 
Acked-by: David S. Miller 

diff --git a/kernel/sys.c b/kernel/sys.c
index 73fc0af..2855ee7 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1362,7 +1362,7 @@ COMPAT_SYSCALL_DEFINE2(getrlimit, unsigned int, resource,
 
ret = do_prlimit(current, resource, NULL, );
if (!ret) {
-   struct rlimit r32;
+   struct compat_rlimit r32;
if (r.rlim_cur > COMPAT_RLIM_INFINITY)
r32.rlim_cur = COMPAT_RLIM_INFINITY;
else

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

[Viresh Kumar]

On 11-07-17, 16:06, Dietmar Eggemann wrote:
> But in the meantime we're convinced that cpufreq_driver_fast_switch() is
> not the right place to call arch_set_freq_scale() since for (future)
> arm/arm64 fast-switch driver, the return value of
> cpufreq_driver->fast_switch() does not give us the information that the
> frequency value did actually change.

Yeah, I saw your discussion with Peter on #linux-rt IRC and TBH I wasn't aware
that we are going to do fast switching that way. Just trying to get
understanding of that idea a bit..

So we will do fast switching from scheduler's point of view, i.e. we wouldn't
schedule a kthread to change the frequency. But the real hardware still can't do
that without sleeping, like if we have I2C somewhere in between. AFAIU, we will
still have some kind of *software* bottom half to do that work, isn't it? And it
wouldn't be that we have pushed some instructions to the hardware, which it can
do a bit later.

For example, the regulator may be accessed via I2C and we need to program that
before changing the clock. So, it will be done by some software code only.

And now I am wondering on why that would be any better than the kthread in
schedutil. Sorry, I haven't understood the idea completely yet :(

-- 
viresh

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

[Viresh Kumar]

On 11-07-17, 16:06, Dietmar Eggemann wrote:
> But in the meantime we're convinced that cpufreq_driver_fast_switch() is
> not the right place to call arch_set_freq_scale() since for (future)
> arm/arm64 fast-switch driver, the return value of
> cpufreq_driver->fast_switch() does not give us the information that the
> frequency value did actually change.

Yeah, I saw your discussion with Peter on #linux-rt IRC and TBH I wasn't aware
that we are going to do fast switching that way. Just trying to get
understanding of that idea a bit..

So we will do fast switching from scheduler's point of view, i.e. we wouldn't
schedule a kthread to change the frequency. But the real hardware still can't do
that without sleeping, like if we have I2C somewhere in between. AFAIU, we will
still have some kind of *software* bottom half to do that work, isn't it? And it
wouldn't be that we have pushed some instructions to the hardware, which it can
do a bit later.

For example, the regulator may be accessed via I2C and we need to program that
before changing the clock. So, it will be done by some software code only.

And now I am wondering on why that would be any better than the kthread in
schedutil. Sorry, I haven't understood the idea completely yet :(

-- 
viresh

linux-next: Tree for Jul 12

[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 20170711:

The vfs tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1170
 1121 files changed, 44069 insertions(+), 16713 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 (130568d5eac5 Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block)
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 (2400fd822f46 powerpc/asm: Mark cr0 as clobbered in 
mftb())
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 (ffa423fb3251 tap: convert a mutex to a spinlock)
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 (65553b12e8fd ALSA: hda/realtek - New codec 
device ID for ALC1220)
Merging pci-current/for-linus (f01fc4177352 ARM/PCI: Fix 
pcibios_init_resource() struct pci_host_bridge leak)
Merging driver-core.current/driver-core-linus (9967468c0a10 Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (9967468c0a10 Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (9967468c0a10 Merge branch 'akpm' (patches from 
Andrew))
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 (9967468c0a10 Merge branch 'akpm' 
(patches from Andrew))
Merging char-misc.current/char-misc-linus (9967468c0a10 Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (ede2e7cdc58e Merge branch 'next' into 
for-linus)
Merging crypto-current/master (b82ce24426a4 crypto: sha1-ssse3 - Disable avx2)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da

linux-next: Tree for Jul 12

[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 20170711:

The vfs tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1170
 1121 files changed, 44069 insertions(+), 16713 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 (130568d5eac5 Merge branch 'for-linus' of 
git://git.kernel.dk/linux-block)
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 (2400fd822f46 powerpc/asm: Mark cr0 as clobbered in 
mftb())
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 (ffa423fb3251 tap: convert a mutex to a spinlock)
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 (65553b12e8fd ALSA: hda/realtek - New codec 
device ID for ALC1220)
Merging pci-current/for-linus (f01fc4177352 ARM/PCI: Fix 
pcibios_init_resource() struct pci_host_bridge leak)
Merging driver-core.current/driver-core-linus (9967468c0a10 Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (9967468c0a10 Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (9967468c0a10 Merge branch 'akpm' (patches from 
Andrew))
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 (9967468c0a10 Merge branch 'akpm' 
(patches from Andrew))
Merging char-misc.current/char-misc-linus (9967468c0a10 Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (ede2e7cdc58e Merge branch 'next' into 
for-linus)
Merging crypto-current/master (b82ce24426a4 crypto: sha1-ssse3 - Disable avx2)
Merging ide/master (acfead32f3f9 ide: don't call memcpy with the same source 
and destination)
Merging vfio-fixes/for-linus (39da

[GIT] Sparc

[David Miller]

1) Fix symbol version generation for assembler on sparc, from
   Nagarathnam Muthusamy.

2) Fix compound page handling in gup_huge_pmd(), from Nitin Gupta.

Please pull, thanks a lot!

The following changes since commit 5faab9e0f03c4eef97886b45436015e107f79f5f:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2017-06-10 11:09:23 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc 

for you to fetch changes up to dbd2667a4fb9ce4f547982b07cd69dda127c47ea:

  sparc64: Fix gup_huge_pmd (2017-06-25 15:23:57 -0400)


David S. Miller (1):
  Merge branch 
'sparc-Suppressing-version-generation-failed-warnings-in-sparc'

Nagarathnam Muthusamy (3):
  Adding asm-prototypes.h for genksyms to generate crc
  sed regex in Makefile.build requires line break between exported symbols
  Adding the type of exported symbols

Nitin Gupta (1):
  sparc64: Fix gup_huge_pmd

 arch/sparc/include/asm/asm-prototypes.h | 24 
 arch/sparc/lib/atomic_64.S  | 44 
++--
 arch/sparc/lib/checksum_64.S|  1 +
 arch/sparc/lib/csum_copy.S  |  1 +
 arch/sparc/lib/memscan_64.S |  2 ++
 arch/sparc/lib/memset.S |  1 +
 arch/sparc/mm/gup.c |  4 ++--
 7 files changed, 57 insertions(+), 20 deletions(-)
 create mode 100644 arch/sparc/include/asm/asm-prototypes.h

[GIT] Sparc

[David Miller]

1) Fix symbol version generation for assembler on sparc, from
   Nagarathnam Muthusamy.

2) Fix compound page handling in gup_huge_pmd(), from Nitin Gupta.

Please pull, thanks a lot!

The following changes since commit 5faab9e0f03c4eef97886b45436015e107f79f5f:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2017-06-10 11:09:23 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc 

for you to fetch changes up to dbd2667a4fb9ce4f547982b07cd69dda127c47ea:

  sparc64: Fix gup_huge_pmd (2017-06-25 15:23:57 -0400)


David S. Miller (1):
  Merge branch 
'sparc-Suppressing-version-generation-failed-warnings-in-sparc'

Nagarathnam Muthusamy (3):
  Adding asm-prototypes.h for genksyms to generate crc
  sed regex in Makefile.build requires line break between exported symbols
  Adding the type of exported symbols

Nitin Gupta (1):
  sparc64: Fix gup_huge_pmd

 arch/sparc/include/asm/asm-prototypes.h | 24 
 arch/sparc/lib/atomic_64.S  | 44 
++--
 arch/sparc/lib/checksum_64.S|  1 +
 arch/sparc/lib/csum_copy.S  |  1 +
 arch/sparc/lib/memscan_64.S |  2 ++
 arch/sparc/lib/memset.S |  1 +
 arch/sparc/mm/gup.c |  4 ++--
 7 files changed, 57 insertions(+), 20 deletions(-)
 create mode 100644 arch/sparc/include/asm/asm-prototypes.h

[PATCH V4] PCI: Add Extended Tags quirk for Broadcom HT2100 Root Port

[Sinan Kaya]

All PCIe devices are expected to be able to handle 8-bit tags.
'commit 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")'
enabled extended tags for all devices based on the spec direction.

The Broadcom HT2100 seems to be having issues with handling
8-bit tags. Mark it as broken.

If a device with extended tags quirk is found, disable extended tags for
all devices in the tree assuming peer-to-peer is possible.

The pci_walk_bus() in the quirk handles all devices we've already
enumerated, and all devices we'll enumerate in the future are handled in
pci_configure_device().

Reported-by: Wim ten Have 
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1467674
Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")
Signed-off-by: Sinan Kaya 
---
 drivers/pci/pci.h|  1 +
 drivers/pci/probe.c  | 35 ++-
 drivers/pci/quirks.c | 19 +++
 include/linux/pci.h  |  1 +
 4 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f8113e5..7153c92 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -239,6 +239,7 @@ enum pci_bar_type {
pci_bar_mem64,  /* A 64-bit memory BAR */
 };
 
+int pci_configure_extended_tags(struct pci_dev *dev, void *ign);
 bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *pl,
int crs_timeout);
 int pci_setup_device(struct pci_dev *dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 19c8950..bc067fb 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1684,22 +1684,47 @@ static void program_hpp_type2(struct pci_dev *dev, 
struct hpp_type2 *hpp)
 */
 }
 
-static void pci_configure_extended_tags(struct pci_dev *dev)
+int pci_configure_extended_tags(struct pci_dev *dev, void *ign)
 {
+   struct pci_host_bridge *host;
u32 dev_cap;
int ret;
+   u16 ctl;
 
if (!pci_is_pcie(dev))
-   return;
+   return 0;
 
ret = pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, _cap);
if (ret)
-   return;
+   return 0;
+
+   if (!(dev_cap & PCI_EXP_DEVCAP_EXT_TAG))
+   return 0;
+
+   ret = pcie_capability_read_word(dev, PCI_EXP_DEVCTL, );
+   if (ret)
+   return 0;
+
+   host = pci_find_host_bridge(dev->bus);
+   if (!host)
+   return 0;
 
-   if (dev_cap & PCI_EXP_DEVCAP_EXT_TAG)
+   if (host->broken_ext_tags) {
+   if (ctl & PCI_EXP_DEVCTL_EXT_TAG) {
+   dev_info(>dev, "disabling Extended Tags\n");
+   pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
+  PCI_EXP_DEVCTL_EXT_TAG);
+   }
+   return 0;
+   }
+   if (!(ctl & PCI_EXP_DEVCTL_EXT_TAG)) {
+   dev_info(>dev, "enabling Extended Tags\n");
pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
 PCI_EXP_DEVCTL_EXT_TAG);
+   }
+   return 0;
 }
+EXPORT_SYMBOL(pci_configure_extended_tags);
 
 static void pci_configure_device(struct pci_dev *dev)
 {
@@ -1707,7 +1732,7 @@ static void pci_configure_device(struct pci_dev *dev)
int ret;
 
pci_configure_mps(dev);
-   pci_configure_extended_tags(dev);
+   pci_configure_extended_tags(dev, NULL);
 
memset(, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, );
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..b5dc99c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4664,3 +4664,22 @@ static void quirk_intel_no_flr(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_intel_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_intel_no_flr);
+
+static void quirk_exttags_completer(struct pci_dev *pdev)
+{
+   struct pci_host_bridge *bridge = pci_find_host_bridge(pdev->bus);
+
+   if (!bridge)
+   return;
+
+   bridge->broken_ext_tags = 1;
+   dev_info(>dev, "Extended Tag handling is broken\n");
+
+   pci_walk_bus(bridge->bus, pci_configure_extended_tags, NULL);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS, 0x0140,
+   quirk_exttags_completer);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS, 0x0142,
+   quirk_exttags_completer);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS, 0x0144,
+   quirk_exttags_completer);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8039f9f..2b22c3e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -441,6 +441,7 @@ struct pci_host_bridge {
void *release_data;
struct msi_controller *msi;
unsigned int ignore_reset_delay:1;  /* for entire hierarchy */
+   unsigned int broken_ext_tags:1;
/* Resource 

[PATCH V4] PCI: Add Extended Tags quirk for Broadcom HT2100 Root Port

[Sinan Kaya]

All PCIe devices are expected to be able to handle 8-bit tags.
'commit 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")'
enabled extended tags for all devices based on the spec direction.

The Broadcom HT2100 seems to be having issues with handling
8-bit tags. Mark it as broken.

If a device with extended tags quirk is found, disable extended tags for
all devices in the tree assuming peer-to-peer is possible.

The pci_walk_bus() in the quirk handles all devices we've already
enumerated, and all devices we'll enumerate in the future are handled in
pci_configure_device().

Reported-by: Wim ten Have 
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1467674
Fixes: 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")
Signed-off-by: Sinan Kaya 
---
 drivers/pci/pci.h|  1 +
 drivers/pci/probe.c  | 35 ++-
 drivers/pci/quirks.c | 19 +++
 include/linux/pci.h  |  1 +
 4 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index f8113e5..7153c92 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -239,6 +239,7 @@ enum pci_bar_type {
pci_bar_mem64,  /* A 64-bit memory BAR */
 };
 
+int pci_configure_extended_tags(struct pci_dev *dev, void *ign);
 bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *pl,
int crs_timeout);
 int pci_setup_device(struct pci_dev *dev);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 19c8950..bc067fb 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1684,22 +1684,47 @@ static void program_hpp_type2(struct pci_dev *dev, 
struct hpp_type2 *hpp)
 */
 }
 
-static void pci_configure_extended_tags(struct pci_dev *dev)
+int pci_configure_extended_tags(struct pci_dev *dev, void *ign)
 {
+   struct pci_host_bridge *host;
u32 dev_cap;
int ret;
+   u16 ctl;
 
if (!pci_is_pcie(dev))
-   return;
+   return 0;
 
ret = pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, _cap);
if (ret)
-   return;
+   return 0;
+
+   if (!(dev_cap & PCI_EXP_DEVCAP_EXT_TAG))
+   return 0;
+
+   ret = pcie_capability_read_word(dev, PCI_EXP_DEVCTL, );
+   if (ret)
+   return 0;
+
+   host = pci_find_host_bridge(dev->bus);
+   if (!host)
+   return 0;
 
-   if (dev_cap & PCI_EXP_DEVCAP_EXT_TAG)
+   if (host->broken_ext_tags) {
+   if (ctl & PCI_EXP_DEVCTL_EXT_TAG) {
+   dev_info(>dev, "disabling Extended Tags\n");
+   pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
+  PCI_EXP_DEVCTL_EXT_TAG);
+   }
+   return 0;
+   }
+   if (!(ctl & PCI_EXP_DEVCTL_EXT_TAG)) {
+   dev_info(>dev, "enabling Extended Tags\n");
pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
 PCI_EXP_DEVCTL_EXT_TAG);
+   }
+   return 0;
 }
+EXPORT_SYMBOL(pci_configure_extended_tags);
 
 static void pci_configure_device(struct pci_dev *dev)
 {
@@ -1707,7 +1732,7 @@ static void pci_configure_device(struct pci_dev *dev)
int ret;
 
pci_configure_mps(dev);
-   pci_configure_extended_tags(dev);
+   pci_configure_extended_tags(dev, NULL);
 
memset(, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, );
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..b5dc99c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4664,3 +4664,22 @@ static void quirk_intel_no_flr(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_intel_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_intel_no_flr);
+
+static void quirk_exttags_completer(struct pci_dev *pdev)
+{
+   struct pci_host_bridge *bridge = pci_find_host_bridge(pdev->bus);
+
+   if (!bridge)
+   return;
+
+   bridge->broken_ext_tags = 1;
+   dev_info(>dev, "Extended Tag handling is broken\n");
+
+   pci_walk_bus(bridge->bus, pci_configure_extended_tags, NULL);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS, 0x0140,
+   quirk_exttags_completer);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS, 0x0142,
+   quirk_exttags_completer);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS, 0x0144,
+   quirk_exttags_completer);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 8039f9f..2b22c3e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -441,6 +441,7 @@ struct pci_host_bridge {
void *release_data;
struct msi_controller *msi;
unsigned int ignore_reset_delay:1;  /* for entire hierarchy */
+   unsigned int broken_ext_tags:1;
/* Resource alignment requirements */

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

[David Miller]

From: Tushar Dave 
Date: Tue, 11 Jul 2017 20:43:39 -0700

> Yes, indeed the bug is in Linus's tree. However, 'sparc' tree doesn't
> have DMA API change (e.g. commit b02c2b0bfd7ae) yet that introduced
> the panic.

You can simply make a note of this when you send the bug fix to me.

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

[David Miller]

From: Tushar Dave 
Date: Tue, 11 Jul 2017 20:43:39 -0700

> Yes, indeed the bug is in Linus's tree. However, 'sparc' tree doesn't
> have DMA API change (e.g. commit b02c2b0bfd7ae) yet that introduced
> the panic.

You can simply make a note of this when you send the bug fix to me.

[PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

[gustavo panizzo]

The dwc3 could not release resources when the module is built-in
because this module does not have shutdown method. This causes the USB
3.0 hub is not able to detect after warm boot.

Original patch by Brian Kim, updated and submitted upstream by gustavo
panizzo.

Also see https://bugs.debian.org/843448

Signed-off-by: Brian Kim 
Signed-off-by: gustavo panizzo 
---
 drivers/usb/dwc3/core.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 326b302fc440..f92dfe213d89 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1259,6 +1259,38 @@ static int dwc3_probe(struct platform_device *pdev)
return ret;
 }
 
+static void dwc3_shutdown(struct platform_device *pdev)
+{
+   struct dwc3 *dwc = platform_get_drvdata(pdev);
+   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+   pm_runtime_get_sync(>dev);
+   /*
+* restore res->start back to its original value so that, in case the
+* probe is deferred, we don't end up getting error in request the
+* memory region the next time probe is called.
+*/
+   res->start -= DWC3_GLOBALS_REGS_START;
+
+   dwc3_debugfs_exit(dwc);
+   dwc3_core_exit_mode(dwc);
+   dwc3_event_buffers_cleanup(dwc);
+   dwc3_free_event_buffers(dwc);
+
+   usb_phy_set_suspend(dwc->usb2_phy, 1);
+   usb_phy_set_suspend(dwc->usb3_phy, 1);
+
+   phy_power_off(dwc->usb2_generic_phy);
+   phy_power_off(dwc->usb3_generic_phy);
+
+   dwc3_core_exit(dwc);
+   dwc3_ulpi_exit(dwc);
+
+   pm_runtime_put_sync(>dev);
+   pm_runtime_allow(>dev);
+   pm_runtime_disable(>dev);
+}
+
 static int dwc3_remove(struct platform_device *pdev)
 {
struct dwc3 *dwc = platform_get_drvdata(pdev);
@@ -1488,6 +1520,7 @@ MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
 static struct platform_driver dwc3_driver = {
.probe  = dwc3_probe,
.remove = dwc3_remove,
+   .shutdown   = dwc3_shutdown,
.driver = {
.name   = "dwc3",
.of_match_table = of_match_ptr(of_dwc3_match),
-- 
2.11.0

[PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

[gustavo panizzo]

The dwc3 could not release resources when the module is built-in
because this module does not have shutdown method. This causes the USB
3.0 hub is not able to detect after warm boot.

Original patch by Brian Kim, updated and submitted upstream by gustavo
panizzo.

Also see https://bugs.debian.org/843448

Signed-off-by: Brian Kim 
Signed-off-by: gustavo panizzo 
---
 drivers/usb/dwc3/core.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 326b302fc440..f92dfe213d89 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1259,6 +1259,38 @@ static int dwc3_probe(struct platform_device *pdev)
return ret;
 }
 
+static void dwc3_shutdown(struct platform_device *pdev)
+{
+   struct dwc3 *dwc = platform_get_drvdata(pdev);
+   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+   pm_runtime_get_sync(>dev);
+   /*
+* restore res->start back to its original value so that, in case the
+* probe is deferred, we don't end up getting error in request the
+* memory region the next time probe is called.
+*/
+   res->start -= DWC3_GLOBALS_REGS_START;
+
+   dwc3_debugfs_exit(dwc);
+   dwc3_core_exit_mode(dwc);
+   dwc3_event_buffers_cleanup(dwc);
+   dwc3_free_event_buffers(dwc);
+
+   usb_phy_set_suspend(dwc->usb2_phy, 1);
+   usb_phy_set_suspend(dwc->usb3_phy, 1);
+
+   phy_power_off(dwc->usb2_generic_phy);
+   phy_power_off(dwc->usb3_generic_phy);
+
+   dwc3_core_exit(dwc);
+   dwc3_ulpi_exit(dwc);
+
+   pm_runtime_put_sync(>dev);
+   pm_runtime_allow(>dev);
+   pm_runtime_disable(>dev);
+}
+
 static int dwc3_remove(struct platform_device *pdev)
 {
struct dwc3 *dwc = platform_get_drvdata(pdev);
@@ -1488,6 +1520,7 @@ MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
 static struct platform_driver dwc3_driver = {
.probe  = dwc3_probe,
.remove = dwc3_remove,
+   .shutdown   = dwc3_shutdown,
.driver = {
.name   = "dwc3",
.of_match_table = of_match_ptr(of_dwc3_match),
-- 
2.11.0

Re: in:imklog segfault in 4.12+git on most sparc64's

[Al Viro]

> In following commits around this one (some bisect steps before, and the 
> last step) the crashes were slightly different from the original crash 
> yersterday, like
> 
> in:imuxsock[1606]: segfault at fff8 ip f774e154 (rpc 
> f774dfe8) sp 0001f7965a68 error 30002 in 
> libc-2.19.so[f76cc000+16a000]
> 
> but this was the first commit introducing the crashes.
> 
> d9e968cb9f849770288f5fde3d8d3a5f7e339052 is the first bad commit
> commit d9e968cb9f849770288f5fde3d8d3a5f7e339052
> Author: Al Viro 
> Date:   Wed May 31 04:33:51 2017 -0400
> 
w getrlimit()/setrlimit(): move compat to native
> 
> Signed-off-by: Al Viro 
> 
> :04 04 5e1a0c25f4554ccdc824b18dc50078d379cdbf9a 
> 6d820451a388c5771a2a410578365d14a0194e4e M  kernel
> 
> -- 
> Meelis Roos (mr...@linux.ee)

With apologies for ed scripts,

ed kernel/sys.c <<'EOF'
/struct rlimit r32/s/rlimit/compat_&/
w
q
EOF

AFAICS, that should fix it.  If it does, commit message would be

fix a braino in compat_sys_getrlimit()

Fixes: commit d9e968cb9f84 "getrlimit()/setrlimit(): move compat to native"
Signed-off-by: Al Viro 
---

Again, my apologies for format of that all - I'm almost completely
off-net and while typing an ed script is feasible, context diff is
too far over the top.  Usimg mutt in ssh session from android is
not fun, to put it mildly...  

Re: in:imklog segfault in 4.12+git on most sparc64's

[Al Viro]

> In following commits around this one (some bisect steps before, and the 
> last step) the crashes were slightly different from the original crash 
> yersterday, like
> 
> in:imuxsock[1606]: segfault at fff8 ip f774e154 (rpc 
> f774dfe8) sp 0001f7965a68 error 30002 in 
> libc-2.19.so[f76cc000+16a000]
> 
> but this was the first commit introducing the crashes.
> 
> d9e968cb9f849770288f5fde3d8d3a5f7e339052 is the first bad commit
> commit d9e968cb9f849770288f5fde3d8d3a5f7e339052
> Author: Al Viro 
> Date:   Wed May 31 04:33:51 2017 -0400
> 
w getrlimit()/setrlimit(): move compat to native
> 
> Signed-off-by: Al Viro 
> 
> :04 04 5e1a0c25f4554ccdc824b18dc50078d379cdbf9a 
> 6d820451a388c5771a2a410578365d14a0194e4e M  kernel
> 
> -- 
> Meelis Roos (mr...@linux.ee)

With apologies for ed scripts,

ed kernel/sys.c <<'EOF'
/struct rlimit r32/s/rlimit/compat_&/
w
q
EOF

AFAICS, that should fix it.  If it does, commit message would be

fix a braino in compat_sys_getrlimit()

Fixes: commit d9e968cb9f84 "getrlimit()/setrlimit(): move compat to native"
Signed-off-by: Al Viro 
---

Again, my apologies for format of that all - I'm almost completely
off-net and while typing an ed script is feasible, context diff is
too far over the top.  Usimg mutt in ssh session from android is
not fun, to put it mildly...  

AW: Wir vergeben Kredite mit einem Zinssatz von jährlich 2%

[Bernhard Stöckl]

Wir vergeben Kredite mit einem Zinssatz von jährlich 2%.

Die Bearbeitung des Antrags erfolgt rasch, wir verlangen keine Gebühren, was 
sie beantragen werden wir annehmen. Wir bewilligen Kredite von bis zu 40 
Millionen Euro und von mindestens 15.000 Euro. Sie können einen geschäftlichen 
oder privaten Kredit beantrage, wobei Sie bei Geschäftskrediten eine 
Zahlungsfrist von einem Jahr erhalten.

Anfragen bitte per Mail an:   sunrisefundin...@hotmail.com  

AW: Wir vergeben Kredite mit einem Zinssatz von jährlich 2%

[Bernhard Stöckl]

Wir vergeben Kredite mit einem Zinssatz von jährlich 2%.

Die Bearbeitung des Antrags erfolgt rasch, wir verlangen keine Gebühren, was 
sie beantragen werden wir annehmen. Wir bewilligen Kredite von bis zu 40 
Millionen Euro und von mindestens 15.000 Euro. Sie können einen geschäftlichen 
oder privaten Kredit beantrage, wobei Sie bei Geschäftskrediten eine 
Zahlungsfrist von einem Jahr erhalten.

Anfragen bitte per Mail an:   sunrisefundin...@hotmail.com  

Re: [PATCH net-next 0/4] net-next: mediatek: add support for ethernet on MT7622 SoC

[David Miller]

From: 
Date: Wed, 12 Jul 2017 11:37:41 +0800

> From: Sean Wang 
> 
> The series adds the driver for ethernet controller found on MT7622 SoC.
> There are additions against with previous MT7623 SoC such as shared SGMII
> given for the dual GMACs and built-in 5-ports 10/100 embedded switch support
> (ESW). Thus more clocks consumers and SGMII hardware setup for the extra
> features are all introduced here and as for the support for ESW that would be
> planned to add in the separate patch integrating with DSA infrastructure
> in the future.
> 
> Currently testing successfully is done with those patches for the conditions
> such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with RTL8211F PHY via 
> SGMII.

net-next is closed, please resubmit this when net-next is open again:

http://vger.kernel.org/~davem/net-next.html

Thanks.

Re: [PATCH net-next 0/4] net-next: mediatek: add support for ethernet on MT7622 SoC

[David Miller]

From: 
Date: Wed, 12 Jul 2017 11:37:41 +0800

> From: Sean Wang 
> 
> The series adds the driver for ethernet controller found on MT7622 SoC.
> There are additions against with previous MT7623 SoC such as shared SGMII
> given for the dual GMACs and built-in 5-ports 10/100 embedded switch support
> (ESW). Thus more clocks consumers and SGMII hardware setup for the extra
> features are all introduced here and as for the support for ESW that would be
> planned to add in the separate patch integrating with DSA infrastructure
> in the future.
> 
> Currently testing successfully is done with those patches for the conditions
> such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with RTL8211F PHY via 
> SGMII.

net-next is closed, please resubmit this when net-next is open again:

http://vger.kernel.org/~davem/net-next.html

Thanks.

[PATCH] PM / OPP: OF: Use pr_debug() instead of pr_err() while adding OPP table

[Viresh Kumar]

Some platforms add the OPPs dynamically from platform specific drivers
instead of getting them statically from DT. The cpufreq-dt driver
already ignores the return value of dev_pm_opp_of_cpumask_add_table() to
not error out for such cases, but we still end up printing error message
from that routine. That's not nice.

Convert the print message to use pr_debug() instead.

Reported-by: Mason 
Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/of.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
index 779428676f63..f1d8b01db546 100644
--- a/drivers/base/power/opp/of.c
+++ b/drivers/base/power/opp/of.c
@@ -533,8 +533,12 @@ int dev_pm_opp_of_cpumask_add_table(const struct cpumask 
*cpumask)
 
ret = dev_pm_opp_of_add_table(cpu_dev);
if (ret) {
-   pr_err("%s: couldn't find opp table for cpu:%d, %d\n",
-  __func__, cpu, ret);
+   /*
+* OPP may get registered dynamically, don't print error
+* message here.
+*/
+   pr_debug("%s: couldn't find opp table for cpu:%d, %d\n",
+__func__, cpu, ret);
 
/* Free all other OPPs */
dev_pm_opp_of_cpumask_remove_table(cpumask);
-- 
2.13.0.71.gd7076ec9c9cb

[PATCH] PM / OPP: OF: Use pr_debug() instead of pr_err() while adding OPP table

[Viresh Kumar]

Some platforms add the OPPs dynamically from platform specific drivers
instead of getting them statically from DT. The cpufreq-dt driver
already ignores the return value of dev_pm_opp_of_cpumask_add_table() to
not error out for such cases, but we still end up printing error message
from that routine. That's not nice.

Convert the print message to use pr_debug() instead.

Reported-by: Mason 
Signed-off-by: Viresh Kumar 
---
 drivers/base/power/opp/of.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
index 779428676f63..f1d8b01db546 100644
--- a/drivers/base/power/opp/of.c
+++ b/drivers/base/power/opp/of.c
@@ -533,8 +533,12 @@ int dev_pm_opp_of_cpumask_add_table(const struct cpumask 
*cpumask)
 
ret = dev_pm_opp_of_add_table(cpu_dev);
if (ret) {
-   pr_err("%s: couldn't find opp table for cpu:%d, %d\n",
-  __func__, cpu, ret);
+   /*
+* OPP may get registered dynamically, don't print error
+* message here.
+*/
+   pr_debug("%s: couldn't find opp table for cpu:%d, %d\n",
+__func__, cpu, ret);
 
/* Free all other OPPs */
dev_pm_opp_of_cpumask_remove_table(cpumask);
-- 
2.13.0.71.gd7076ec9c9cb

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

[Serge E. Hallyn]

Quoting Stefan Berger (Stefan bergerstef...@linux.vnet.ibm.com):
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user 
> namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid= when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list:list of 0-byte separated xattr names
> + * @size:the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == _user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = [s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);

Why are you doing this here?  If we get here it means that
xattr_is_userns_supported() returned < 0, meaning name is
not userns-supported.  So xattr_rewrite_userns_xattr() will
just return name.  Am I missing something?

> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {

Now here, if name was recalculated to @newname, and @newname is
found in the nlist, that should raise an error right?  Something
fishy is going on?

> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)

d_off needs to be set to -ERANGE here.

> + break;
> + strcpy([d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}

Re: [PATCH v2] xattr: Enable security.capability in user namespaces

[Serge E. Hallyn]

Quoting Stefan Berger (Stefan bergerstef...@linux.vnet.ibm.com):
> +/*
> + * xattr_list_userns_rewrite - Rewrite list of xattr names for user 
> namespaces
> + * or determine needed size for attribute list
> + * in case size == 0
> + *
> + * In a user namespace we do not present all extended attributes to the
> + * user. We filter out those that are in the list of userns supported xattr.
> + * Besides that we filter out those with @uid= when there is no mapping
> + * for that uid in the current user namespace.
> + *
> + * @list:list of 0-byte separated xattr names
> + * @size:the size of the list; may be 0 to determine needed list size
> + * @list_maxlen: allocated buffer size of list
> + */
> +static ssize_t
> +xattr_list_userns_rewrite(char *list, ssize_t size, size_t list_maxlen)
> +{
> + char *nlist = NULL;
> + size_t s_off, len, nlen;
> + ssize_t d_off;
> + char *name, *newname;
> +
> + if (!list || size < 0 || current_user_ns() == _user_ns)
> + return size;
> +
> + if (size) {
> + nlist = kmalloc(list_maxlen, GFP_KERNEL);
> + if (!nlist)
> + return -ENOMEM;
> + }
> +
> + s_off = d_off = 0;
> + while (s_off < size || size == 0) {
> + name = [s_off];
> +
> + len = strlen(name);
> + if (!len)
> + break;
> +
> + if (xattr_is_userns_supported(name, false) >= 0)
> + newname = name;
> + else {
> + newname = xattr_rewrite_userns_xattr(name);

Why are you doing this here?  If we get here it means that
xattr_is_userns_supported() returned < 0, meaning name is
not userns-supported.  So xattr_rewrite_userns_xattr() will
just return name.  Am I missing something?

> + if (IS_ERR(newname)) {
> + d_off = PTR_ERR(newname);
> + goto out_free;
> + }
> + }
> + if (newname && !xattr_list_contains(nlist, d_off, newname)) {

Now here, if name was recalculated to @newname, and @newname is
found in the nlist, that should raise an error right?  Something
fishy is going on?

> + nlen = strlen(newname);
> +
> + if (nlist) {
> + if (nlen + 1 > list_maxlen)

d_off needs to be set to -ERANGE here.

> + break;
> + strcpy([d_off], newname);
> + }
> +
> + d_off += nlen + 1;
> + if (newname != name)
> + kfree(newname);
> + }
> + s_off += len + 1;
> + }
> + if (nlist)
> + memcpy(list, nlist, d_off);
> +out_free:
> + kfree(nlist);
> +
> + return d_off;
> +}

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

[Tushar Dave]

On 07/11/2017 05:34 PM, David Miller wrote:

From: Tushar Dave 
Date: Tue, 11 Jul 2017 15:38:21 -0700




On 07/11/2017 02:48 PM, Meelis Roos wrote:

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!

Thanks for testing. Patch sent for sparc-next.

Why sparc-next - it should go into 4.13 since 4.13 would break all
niagara1 and niagara2 systems otherwise?This is sparc arch fix so I
used sparc tree(in this case for sparc-next).

I am open to maintainers suggestions. Thanks.


If the bug is in Linus's tree the fix must target 'sparc' not
'sparc-next'.


Dave,

Yes, indeed the bug is in Linus's tree. However, 'sparc' tree doesn't 
have DMA API change (e.g. commit b02c2b0bfd7ae) yet that introduced the 
panic. Looks like the DMA API changes have not merged into 'sparc' tree 
yet. In other words, 'sparc' tree doesn't have mentioned panic issue, 
nothing to fix there!
However, 'sparc-next' is up to date (or more close to) linus tree and 
has DMA API change that cause mentioned panic issue. So I have send 
patch targeted for sparc-next.


Let me know what should be the best tree to get this fix in and I will 
send v2.


Thanks.

-Tushar

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tushar Dave]

On 07/11/2017 05:34 PM, David Miller wrote:

From: Tushar Dave 
Date: Tue, 11 Jul 2017 15:38:21 -0700




On 07/11/2017 02:48 PM, Meelis Roos wrote:

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!

Thanks for testing. Patch sent for sparc-next.

Why sparc-next - it should go into 4.13 since 4.13 would break all
niagara1 and niagara2 systems otherwise?This is sparc arch fix so I
used sparc tree(in this case for sparc-next).

I am open to maintainers suggestions. Thanks.


If the bug is in Linus's tree the fix must target 'sparc' not
'sparc-next'.


Dave,

Yes, indeed the bug is in Linus's tree. However, 'sparc' tree doesn't 
have DMA API change (e.g. commit b02c2b0bfd7ae) yet that introduced the 
panic. Looks like the DMA API changes have not merged into 'sparc' tree 
yet. In other words, 'sparc' tree doesn't have mentioned panic issue, 
nothing to fix there!
However, 'sparc-next' is up to date (or more close to) linus tree and 
has DMA API change that cause mentioned panic issue. So I have send 
patch targeted for sparc-next.


Let me know what should be the best tree to get this fix in and I will 
send v2.


Thanks.

-Tushar

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 2/4] pmbus: Add fan configuration support

[Guenter Roeck]

On 07/11/2017 05:39 PM, Andrew Jeffery wrote:

On Tue, 2017-07-11 at 06:40 -0700, Guenter Roeck wrote:

On 07/10/2017 06:56 AM, Andrew Jeffery wrote:

Augment PMBus support to include control of fans via the
FAN_COMMAND_[1-4] registers, both in RPM and PWM modes. The behaviour
of FAN_CONFIG_{1_2,3_4} and FAN_COMMAND_[1-4] are tightly coupled, and
their interactions do not fit the existing use of struct pmbus_sensor.
The patch introduces struct pmbus_fan_ctrl to distinguish from the
simple sensor case, along with associated sysfs show/set implementations.

Further, the interpreting the value of FAN_COMMAND_[1-4] depends on both
the current fan mode (RPM or PWM, as configured in
FAN_CONFIG_{1_2,3_4}), and the device-specific behaviour for the
register. For example, the MAX31785 chip defines the following:

PWM (m = 1, b = 0, R = 2):
   0x - 0x2710: 0 - 100% fan PWM duty cycle
   0x2711 - 0x7fff: 100% fan PWM duty cycle
   0x8000 - 0x: Ignore FAN_COMMAND_[1-4], use automatic fan control

RPM (m = 1, b = 0, R = 0):
   0x - 0x7FFF: 0 - 32,767 RPM
   0x8000 - 0x: Ignore FAN_COMMAND_[1-4], use automatic fan control

To handle the device-specific interpretation of the FAN_COMMAND_[1-4],
add an optional callbacks to the info struct to get/set the 'mode'
value required for the pwm[1-n]_enable sysfs attribute. A fallback
calculation exists if the callbacks are not populated; the fallback
ignores device-specific ranges and tries to determine a reasonable value
from FAN_CONFIG_{1_2,3_4} and FAN_COMMAND_[1-4].



This seems overly complex, but unfortunately I don't have time for a detailed
analysis right now.


No worries. It turned out more complex than I was hoping as well, and I
  am keen to hear any insights to trim it down.


Couple of comments below.


Yep, thanks for taking a look.



Guenter


Signed-off-by: Andrew Jeffery 

---
   drivers/hwmon/pmbus/pmbus.h  |   7 +
   drivers/hwmon/pmbus/pmbus_core.c | 335 
+++
   2 files changed, 342 insertions(+)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index bfcb13bae34b..927eabc1b273 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -223,6 +223,8 @@ enum pmbus_regs {

   #define PB_FAN_1_RPM BIT(6)
   #define PB_FAN_1_INSTALLED   BIT(7)
   
+enum pmbus_fan_mode { percent = 0, rpm };

+
   /*
* STATUS_BYTE, STATUS_WORD (lower)
*/
@@ -380,6 +382,11 @@ struct pmbus_driver_info {

int (*identify)(struct i2c_client *client,
struct pmbus_driver_info *info);
   

+   /* Allow the driver to interpret the fan command value */
+   int (*get_pwm_mode)(int id, u8 fan_config, u16 fan_command);
+   int (*set_pwm_mode)(int id, long mode, u8 *fan_config,
+   u16 *fan_command);

+


It is not entirely obvious to me why this would require new callback functions.
Can you overload PMBUS_FAN_CONFIG_12 / PMBUS_FAN_CONFIG_34 or, if that does not
work for some reason, introduce a virtual register, such as PMBUS_VIRT_PWM_MODE 
?


Can you expand on the thought of overloading PMBUS_FAN_CONFIG_{12,34}?



Every register/command can be implemented in the front end driver in its 
read/write
functions. For example, see max34440_read_byte_data(), which replaces some of 
the
status registers. ucd9000.c actually overrides PMBUS_FAN_CONFIG_12 and
PMBUS_FAN_CONFIG_34.


Regarding virtual registers, I saw references to them whilst I was
working my way through the core code but didn't stop to investigate.
I'll take a deeper look.


Virtual registers/commands are meant to "standardize" non-standard PMBus 
commands.

For example, PMBus provides no means to read the average/minimum/maximum 
temperature.
Modeling the respective attributes using PMBUS_VIRT_READ_TEMP_AVG, 
PMBUS_VIRT_READ_TEMP_MIN,
and PMBUS_VIRT_READ_TEMP_MAX, and providing driver-specific read/write functions
which map the virtual commands to real chip registers makes the code much 
simpler
than per-attribute callbacks. With virtual commands, the core only needs 
entries such as

   }, {
.reg = PMBUS_VIRT_READ_TEMP_MIN,
.attr = "lowest",
}, {
.reg = PMBUS_VIRT_READ_TEMP_AVG,
.attr = "average",
}, {
.reg = PMBUS_VIRT_READ_TEMP_MAX,
.attr = "highest",

to support such non-standard attributes. Imagine how that would look like
if each of the supported virtual commands would be implemented as callback.


However, the addition of the callbacks was driven by the behaviour of
the MAX31785, where some values written to PMBUS_FAN_COMMAND_1 trigger
automated control, while others retain manual control. Patch 4/4 should
provide a bit more context, though I've also outlined the behaviour in
the commit message for this patch. I don't have a lot of experience
with PMBus devices 

Re: [RFC PATCH 2/4] pmbus: Add fan configuration support

[Guenter Roeck]

On 07/11/2017 05:39 PM, Andrew Jeffery wrote:

On Tue, 2017-07-11 at 06:40 -0700, Guenter Roeck wrote:

On 07/10/2017 06:56 AM, Andrew Jeffery wrote:

Augment PMBus support to include control of fans via the
FAN_COMMAND_[1-4] registers, both in RPM and PWM modes. The behaviour
of FAN_CONFIG_{1_2,3_4} and FAN_COMMAND_[1-4] are tightly coupled, and
their interactions do not fit the existing use of struct pmbus_sensor.
The patch introduces struct pmbus_fan_ctrl to distinguish from the
simple sensor case, along with associated sysfs show/set implementations.

Further, the interpreting the value of FAN_COMMAND_[1-4] depends on both
the current fan mode (RPM or PWM, as configured in
FAN_CONFIG_{1_2,3_4}), and the device-specific behaviour for the
register. For example, the MAX31785 chip defines the following:

PWM (m = 1, b = 0, R = 2):
   0x - 0x2710: 0 - 100% fan PWM duty cycle
   0x2711 - 0x7fff: 100% fan PWM duty cycle
   0x8000 - 0x: Ignore FAN_COMMAND_[1-4], use automatic fan control

RPM (m = 1, b = 0, R = 0):
   0x - 0x7FFF: 0 - 32,767 RPM
   0x8000 - 0x: Ignore FAN_COMMAND_[1-4], use automatic fan control

To handle the device-specific interpretation of the FAN_COMMAND_[1-4],
add an optional callbacks to the info struct to get/set the 'mode'
value required for the pwm[1-n]_enable sysfs attribute. A fallback
calculation exists if the callbacks are not populated; the fallback
ignores device-specific ranges and tries to determine a reasonable value
from FAN_CONFIG_{1_2,3_4} and FAN_COMMAND_[1-4].



This seems overly complex, but unfortunately I don't have time for a detailed
analysis right now.


No worries. It turned out more complex than I was hoping as well, and I
  am keen to hear any insights to trim it down.


Couple of comments below.


Yep, thanks for taking a look.



Guenter


Signed-off-by: Andrew Jeffery 

---
   drivers/hwmon/pmbus/pmbus.h  |   7 +
   drivers/hwmon/pmbus/pmbus_core.c | 335 
+++
   2 files changed, 342 insertions(+)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index bfcb13bae34b..927eabc1b273 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -223,6 +223,8 @@ enum pmbus_regs {

   #define PB_FAN_1_RPM BIT(6)
   #define PB_FAN_1_INSTALLED   BIT(7)
   
+enum pmbus_fan_mode { percent = 0, rpm };

+
   /*
* STATUS_BYTE, STATUS_WORD (lower)
*/
@@ -380,6 +382,11 @@ struct pmbus_driver_info {

int (*identify)(struct i2c_client *client,
struct pmbus_driver_info *info);
   

+   /* Allow the driver to interpret the fan command value */
+   int (*get_pwm_mode)(int id, u8 fan_config, u16 fan_command);
+   int (*set_pwm_mode)(int id, long mode, u8 *fan_config,
+   u16 *fan_command);

+


It is not entirely obvious to me why this would require new callback functions.
Can you overload PMBUS_FAN_CONFIG_12 / PMBUS_FAN_CONFIG_34 or, if that does not
work for some reason, introduce a virtual register, such as PMBUS_VIRT_PWM_MODE 
?


Can you expand on the thought of overloading PMBUS_FAN_CONFIG_{12,34}?



Every register/command can be implemented in the front end driver in its 
read/write
functions. For example, see max34440_read_byte_data(), which replaces some of 
the
status registers. ucd9000.c actually overrides PMBUS_FAN_CONFIG_12 and
PMBUS_FAN_CONFIG_34.


Regarding virtual registers, I saw references to them whilst I was
working my way through the core code but didn't stop to investigate.
I'll take a deeper look.


Virtual registers/commands are meant to "standardize" non-standard PMBus 
commands.

For example, PMBus provides no means to read the average/minimum/maximum 
temperature.
Modeling the respective attributes using PMBUS_VIRT_READ_TEMP_AVG, 
PMBUS_VIRT_READ_TEMP_MIN,
and PMBUS_VIRT_READ_TEMP_MAX, and providing driver-specific read/write functions
which map the virtual commands to real chip registers makes the code much 
simpler
than per-attribute callbacks. With virtual commands, the core only needs 
entries such as

   }, {
.reg = PMBUS_VIRT_READ_TEMP_MIN,
.attr = "lowest",
}, {
.reg = PMBUS_VIRT_READ_TEMP_AVG,
.attr = "average",
}, {
.reg = PMBUS_VIRT_READ_TEMP_MAX,
.attr = "highest",

to support such non-standard attributes. Imagine how that would look like
if each of the supported virtual commands would be implemented as callback.


However, the addition of the callbacks was driven by the behaviour of
the MAX31785, where some values written to PMBUS_FAN_COMMAND_1 trigger
automated control, while others retain manual control. Patch 4/4 should
provide a bit more context, though I've also outlined the behaviour in
the commit message for this patch. I don't have a lot of experience
with PMBus devices so I don't have 

[PATCH] Input: i8042 - add Gigabyte P57 to the keyboard reset table

[Kai-Heng Feng]

Similar to other Gigabyte laptops, the touchpad on P57 requires a
keyboard reset to detect Elantech touchpad correctly.

BugLink: https://bugs.launchpad.net/bugs/1594214
Signed-off-by: Kai-Heng Feng 
---
 drivers/input/serio/i8042-x86ia64io.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/input/serio/i8042-x86ia64io.h 
b/drivers/input/serio/i8042-x86ia64io.h
index 09720d950686..1c6a49b5b93d 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -833,6 +833,13 @@ static const struct dmi_system_id __initconst 
i8042_dmi_kbdreset_table[] = {
},
},
{
+   /* Gigabyte P57 - Elantech touchpad */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "P57"),
+   },
+   },
+   {
/* Schenker XMG C504 - Elantech touchpad */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "XMG"),
-- 
2.13.2

[PATCH] Input: i8042 - add Gigabyte P57 to the keyboard reset table

[Kai-Heng Feng]

Similar to other Gigabyte laptops, the touchpad on P57 requires a
keyboard reset to detect Elantech touchpad correctly.

BugLink: https://bugs.launchpad.net/bugs/1594214
Signed-off-by: Kai-Heng Feng 
---
 drivers/input/serio/i8042-x86ia64io.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/input/serio/i8042-x86ia64io.h 
b/drivers/input/serio/i8042-x86ia64io.h
index 09720d950686..1c6a49b5b93d 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -833,6 +833,13 @@ static const struct dmi_system_id __initconst 
i8042_dmi_kbdreset_table[] = {
},
},
{
+   /* Gigabyte P57 - Elantech touchpad */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "P57"),
+   },
+   },
+   {
/* Schenker XMG C504 - Elantech touchpad */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "XMG"),
-- 
2.13.2

[PATCH net-next 3/4] net-next: mediatek: add support for MediaTek MT7622 SoC

[sean.wang]

From: Sean Wang 

This patch adds the driver for ethernet controller on MT7622 SoC. It has
the similar handling logic as the previously MT7623 does, but there are
additions against with MT7623 SoC, the shared SGMII given for the dual
GMACs and including 5-ports 10/100 embedded switch support (ESW) as the
GMAC1 option, thus more clocks consumers for the extra feature are
introduced here. So for ease portability and maintenance, those
differences all are being kept inside the platform data as other drivers
usually do. Currently testing successfully is done with those patches for
the conditions such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with
RTL8211F PHY via SGMII.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 72 -
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 54 +-
 2 files changed, 122 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 51ca79f..e3dbea1 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -52,7 +52,8 @@ static const struct mtk_ethtool_stats {
 };
 
 static const char * const mtk_clks_source_name[] = {
-   "ethif", "esw", "gp1", "gp2", "trgpll"
+   "ethif", "esw", "gp0", "gp1", "gp2", "trgpll", "sgmii_tx250m",
+   "sgmii_rx250m", "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii_ck", "eth2pll"
 };
 
 void mtk_w32(struct mtk_eth *eth, u32 val, unsigned reg)
@@ -162,6 +163,47 @@ static void mtk_gmac0_rgmii_adjust(struct mtk_eth *eth, 
int speed)
mtk_w32(eth, val, TRGMII_TCK_CTRL);
 }
 
+static void mtk_gmac_sgmii_hw_setup(struct mtk_eth *eth, int mac_id)
+{
+   u32 val;
+
+   /* Setup the link timer and QPHY power up inside SGMIISYS */
+   regmap_write(eth->sgmiisys, SGMSYS_PCS_LINK_TIMER,
+SGMII_LINK_TIMER_DEFAULT);
+
+   regmap_read(eth->sgmiisys, SGMSYS_SGMII_MODE, );
+   val |= SGMII_REMOTE_FAULT_DIS;
+   regmap_write(eth->sgmiisys, SGMSYS_SGMII_MODE, val);
+
+   regmap_read(eth->sgmiisys, SGMSYS_PCS_CONTROL_1, );
+   val |= SGMII_AN_RESTART;
+   regmap_write(eth->sgmiisys, SGMSYS_PCS_CONTROL_1, val);
+
+   regmap_read(eth->sgmiisys, SGMSYS_QPHY_PWR_STATE_CTRL, );
+   val &= ~SGMII_PHYA_PWD;
+   regmap_write(eth->sgmiisys, SGMSYS_QPHY_PWR_STATE_CTRL, val);
+
+   /* Determine MUX for which GMAC uses the SGMII interface */
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_DUAL_GMAC_SHARED_SGMII)) {
+   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, );
+   val &= ~SYSCFG0_SGMII_MASK;
+   val |= !mac_id ? SYSCFG0_SGMII_GMAC1 : SYSCFG0_SGMII_GMAC2;
+   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+
+   dev_info(eth->dev, "setup shared sgmii for gmac=%d\n",
+mac_id);
+   }
+
+   /* Setup the GMAC1 going through SGMII path when SoC also support
+* ESW on GMAC1
+*/
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_GMAC1_ESW | MTK_GMAC1_SGMII) &&
+   !mac_id) {
+   mtk_w32(eth, 0, MTK_MAC_MISC);
+   dev_info(eth->dev, "setup gmac1 going through sgmii");
+   }
+}
+
 static void mtk_phy_link_adjust(struct net_device *dev)
 {
struct mtk_mac *mac = netdev_priv(dev);
@@ -269,6 +311,7 @@ static int mtk_phy_connect(struct net_device *dev)
if (!np)
return -ENODEV;
 
+   mac->ge_mode = 0;
switch (of_get_phy_mode(np)) {
case PHY_INTERFACE_MODE_TRGMII:
mac->trgmii = true;
@@ -276,7 +319,15 @@ static int mtk_phy_connect(struct net_device *dev)
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII:
-   mac->ge_mode = 0;
+   break;
+   case PHY_INTERFACE_MODE_SGMII:
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII))
+   mtk_gmac_sgmii_hw_setup(eth, mac->id);
+   break;
+   case PHY_INTERFACE_MODE_INTERNAL:
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_GMAC1_ESW) && !mac->id)
+   /* Setup the path through ESW internal switch */
+   mtk_w32(eth, MTK_MUX_TO_ESW, MTK_MAC_MISC);
break;
case PHY_INTERFACE_MODE_MII:
mac->ge_mode = 1;
@@ -2424,6 +2475,7 @@ static int mtk_get_chip_id(struct mtk_eth *eth, u32 
*chip_id)
 static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
 {
switch (eth->chip_id) {
+   case MT7622_ETH:
case MT7623_ETH:
return true;
}
@@ -2463,6 +2515,16 @@ static int mtk_probe(struct platform_device *pdev)
return PTR_ERR(eth->ethsys);
}
 
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
+   eth->sgmiisys =
+   

[PATCH net-next 2/4] net-next: mediatek: add platform data to adapt into various hardware

[sean.wang]

From: Sean Wang 

This patch is the preparation patch in order to adapt into various
hardware through adding platform data which holds specific characteristics
among MediaTek SoCs and introducing the unified clock handler for those
distinct clock requirements depending on different features such as
TRGMII and SGMII getting support on the target SoC. And finally, add
enhancement with given the generic description for Kconfig and remove the
unnecessary machine type dependency in Makefile.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/Kconfig   |  6 +--
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 71 -
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 23 +-
 3 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/Kconfig 
b/drivers/net/ethernet/mediatek/Kconfig
index 698bb89..f9149d2 100644
--- a/drivers/net/ethernet/mediatek/Kconfig
+++ b/drivers/net/ethernet/mediatek/Kconfig
@@ -7,11 +7,11 @@ config NET_VENDOR_MEDIATEK
 if NET_VENDOR_MEDIATEK
 
 config NET_MEDIATEK_SOC
-   tristate "MediaTek MT7623 Gigabit ethernet support"
-   depends on NET_VENDOR_MEDIATEK && (MACH_MT7623 || MACH_MT2701)
+   tristate "MediaTek SoC Gigabit Ethernet support"
+   depends on NET_VENDOR_MEDIATEK
select PHYLIB
---help---
  This driver supports the gigabit ethernet MACs in the
- MediaTek MT2701/MT7623 chipset family.
+ MediaTek SoC family.
 
 endif #NET_VENDOR_MEDIATEK
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index b8068ce..51ca79f 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -184,7 +184,8 @@ static void mtk_phy_link_adjust(struct net_device *dev)
break;
};
 
-   if (mac->id == 0 && !mac->trgmii)
+   if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) &&
+   !mac->id && !mac->trgmii)
mtk_gmac0_rgmii_adjust(mac->hw, dev->phydev->speed);
 
if (dev->phydev->link)
@@ -1837,6 +1838,39 @@ static void ethsys_reset(struct mtk_eth *eth, u32 
reset_bits)
mdelay(10);
 }
 
+static void mtk_clk_disable(struct mtk_eth *eth)
+{
+   int clk;
+
+   for (clk = MTK_CLK_MAX - 1; clk >= 0; clk--) {
+   if (eth->clks[clk])
+   clk_disable_unprepare(eth->clks[clk]);
+   }
+}
+
+static int mtk_clk_enable(struct mtk_eth *eth)
+{
+   int clk, ret;
+
+   for (clk = 0; clk < MTK_CLK_MAX ; clk++) {
+   if (eth->clks[clk]) {
+   ret = clk_prepare_enable(eth->clks[clk]);
+   if (ret)
+   goto err_disable_clks;
+   }
+   }
+
+   return 0;
+
+err_disable_clks:
+   while (--clk >= 0) {
+   if (eth->clks[clk])
+   clk_disable_unprepare(eth->clks[clk]);
+   }
+
+   return ret;
+}
+
 static int mtk_hw_init(struct mtk_eth *eth)
 {
int i, val;
@@ -1847,10 +1881,8 @@ static int mtk_hw_init(struct mtk_eth *eth)
pm_runtime_enable(eth->dev);
pm_runtime_get_sync(eth->dev);
 
-   clk_prepare_enable(eth->clks[MTK_CLK_ETHIF]);
-   clk_prepare_enable(eth->clks[MTK_CLK_ESW]);
-   clk_prepare_enable(eth->clks[MTK_CLK_GP1]);
-   clk_prepare_enable(eth->clks[MTK_CLK_GP2]);
+   mtk_clk_enable(eth);
+
ethsys_reset(eth, RSTCTRL_FE);
ethsys_reset(eth, RSTCTRL_PPE);
 
@@ -1925,10 +1957,7 @@ static int mtk_hw_deinit(struct mtk_eth *eth)
if (!test_and_clear_bit(MTK_HW_INIT, >state))
return 0;
 
-   clk_disable_unprepare(eth->clks[MTK_CLK_GP2]);
-   clk_disable_unprepare(eth->clks[MTK_CLK_GP1]);
-   clk_disable_unprepare(eth->clks[MTK_CLK_ESW]);
-   clk_disable_unprepare(eth->clks[MTK_CLK_ETHIF]);
+   mtk_clk_disable(eth);
 
pm_runtime_put_sync(eth->dev);
pm_runtime_disable(eth->dev);
@@ -2406,6 +2435,7 @@ static int mtk_probe(struct platform_device *pdev)
 {
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct device_node *mac_np;
+   const struct of_device_id *match;
struct mtk_eth *eth;
int err;
int i;
@@ -2414,6 +2444,9 @@ static int mtk_probe(struct platform_device *pdev)
if (!eth)
return -ENOMEM;
 
+   match = of_match_device(of_mtk_match, >dev);
+   eth->soc = (struct mtk_soc_data *)match->data;
+
eth->dev = >dev;
eth->base = devm_ioremap_resource(>dev, res);
if (IS_ERR(eth->base))
@@ -2450,7 +2483,12 @@ static int mtk_probe(struct platform_device *pdev)
if (IS_ERR(eth->clks[i])) {
if (PTR_ERR(eth->clks[i]) == -EPROBE_DEFER)
return -EPROBE_DEFER;
-   return 

[PATCH net-next 4/4] MAINTAINERS: add Sean/Nelson as MediaTek ethernet maintainers

[sean.wang]

From: Sean Wang 

Sean and Nelson work for MediaTek on maintaining the MediaTek ethernet
driver for the existing SoCs and adding support for the following SoCs.
In the past, Sean has been active at making most of the qualifications
, stress test and submitting a lot of patches for the driver while
Nelson was looking into the aspects more on hardware additions and details
such as introducing PDMA with Hardware LRO to the driver.

Cc: John Crispin 
Signed-off-by: Sean Wang 
Signed-off-by: Nelson Chang 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4f4057c..3b2dd4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8385,6 +8385,8 @@ F:include/uapi/linux/uvcvideo.h
 MEDIATEK ETHERNET DRIVER
 M: Felix Fietkau 
 M: John Crispin 
+M: Sean Wang 
+M: Nelson Chang 
 L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/mediatek/
-- 
2.7.4

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

[Adam Borowski]

On Tue, Jul 11, 2017 at 06:01:38AM +, Nick Terrell wrote:
> On 7/10/17, 9:57 PM, "Nick Terrell"  wrote:
> > 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.
>
> Sorry, my patch still triggered the gcc bug, I used the wrong compiler.
> This patch works, and runs about the same speed as before the patch for
> small inputs, and slightly faster for larger inputs (100+ bytes). I'll
> look for a faster workaround if benchmarks show it matters.

Confirmed, the fix stops the crash for me.  Yay!

> --- a/lib/zstd/zstd_internal.h
> +++ b/lib/zstd/zstd_internal.h
> @@ -139,12 +139,8 @@ static void ZSTD_copy8(void *dst, const void *src) { 
> memcpy(dst, src, 8); }
>  #define WILDCOPY_OVERLENGTH 8
>  ZSTD_STATIC void ZSTD_wildcopy(void *dst, const void *src, ptrdiff_t length)
>  {
> - const BYTE *ip = (const BYTE *)src;
> - BYTE *op = (BYTE *)dst;
> - BYTE *const oend = op + length;
> - do
> - COPY8(op, ip)
> - while (op < oend);
> + if (length > 0)
> + memcpy(dst, src, length);
>  }
>  
>  ZSTD_STATIC void ZSTD_wildcopy_e(void *dst, const void *src, void *dstEnd) 
> /* should be faster for decoding, but strangely, not verified on all platform 
> */

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

[PATCH net-next 4/4] MAINTAINERS: add Sean/Nelson as MediaTek ethernet maintainers

[sean.wang]

From: Sean Wang 

Sean and Nelson work for MediaTek on maintaining the MediaTek ethernet
driver for the existing SoCs and adding support for the following SoCs.
In the past, Sean has been active at making most of the qualifications
, stress test and submitting a lot of patches for the driver while
Nelson was looking into the aspects more on hardware additions and details
such as introducing PDMA with Hardware LRO to the driver.

Cc: John Crispin 
Signed-off-by: Sean Wang 
Signed-off-by: Nelson Chang 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4f4057c..3b2dd4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8385,6 +8385,8 @@ F:include/uapi/linux/uvcvideo.h
 MEDIATEK ETHERNET DRIVER
 M: Felix Fietkau 
 M: John Crispin 
+M: Sean Wang 
+M: Nelson Chang 
 L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/mediatek/
-- 
2.7.4

[PATCH net-next 2/4] net-next: mediatek: add platform data to adapt into various hardware

[sean.wang]

From: Sean Wang 

This patch is the preparation patch in order to adapt into various
hardware through adding platform data which holds specific characteristics
among MediaTek SoCs and introducing the unified clock handler for those
distinct clock requirements depending on different features such as
TRGMII and SGMII getting support on the target SoC. And finally, add
enhancement with given the generic description for Kconfig and remove the
unnecessary machine type dependency in Makefile.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/Kconfig   |  6 +--
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 71 -
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 23 +-
 3 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/Kconfig 
b/drivers/net/ethernet/mediatek/Kconfig
index 698bb89..f9149d2 100644
--- a/drivers/net/ethernet/mediatek/Kconfig
+++ b/drivers/net/ethernet/mediatek/Kconfig
@@ -7,11 +7,11 @@ config NET_VENDOR_MEDIATEK
 if NET_VENDOR_MEDIATEK
 
 config NET_MEDIATEK_SOC
-   tristate "MediaTek MT7623 Gigabit ethernet support"
-   depends on NET_VENDOR_MEDIATEK && (MACH_MT7623 || MACH_MT2701)
+   tristate "MediaTek SoC Gigabit Ethernet support"
+   depends on NET_VENDOR_MEDIATEK
select PHYLIB
---help---
  This driver supports the gigabit ethernet MACs in the
- MediaTek MT2701/MT7623 chipset family.
+ MediaTek SoC family.
 
 endif #NET_VENDOR_MEDIATEK
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index b8068ce..51ca79f 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -184,7 +184,8 @@ static void mtk_phy_link_adjust(struct net_device *dev)
break;
};
 
-   if (mac->id == 0 && !mac->trgmii)
+   if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII) &&
+   !mac->id && !mac->trgmii)
mtk_gmac0_rgmii_adjust(mac->hw, dev->phydev->speed);
 
if (dev->phydev->link)
@@ -1837,6 +1838,39 @@ static void ethsys_reset(struct mtk_eth *eth, u32 
reset_bits)
mdelay(10);
 }
 
+static void mtk_clk_disable(struct mtk_eth *eth)
+{
+   int clk;
+
+   for (clk = MTK_CLK_MAX - 1; clk >= 0; clk--) {
+   if (eth->clks[clk])
+   clk_disable_unprepare(eth->clks[clk]);
+   }
+}
+
+static int mtk_clk_enable(struct mtk_eth *eth)
+{
+   int clk, ret;
+
+   for (clk = 0; clk < MTK_CLK_MAX ; clk++) {
+   if (eth->clks[clk]) {
+   ret = clk_prepare_enable(eth->clks[clk]);
+   if (ret)
+   goto err_disable_clks;
+   }
+   }
+
+   return 0;
+
+err_disable_clks:
+   while (--clk >= 0) {
+   if (eth->clks[clk])
+   clk_disable_unprepare(eth->clks[clk]);
+   }
+
+   return ret;
+}
+
 static int mtk_hw_init(struct mtk_eth *eth)
 {
int i, val;
@@ -1847,10 +1881,8 @@ static int mtk_hw_init(struct mtk_eth *eth)
pm_runtime_enable(eth->dev);
pm_runtime_get_sync(eth->dev);
 
-   clk_prepare_enable(eth->clks[MTK_CLK_ETHIF]);
-   clk_prepare_enable(eth->clks[MTK_CLK_ESW]);
-   clk_prepare_enable(eth->clks[MTK_CLK_GP1]);
-   clk_prepare_enable(eth->clks[MTK_CLK_GP2]);
+   mtk_clk_enable(eth);
+
ethsys_reset(eth, RSTCTRL_FE);
ethsys_reset(eth, RSTCTRL_PPE);
 
@@ -1925,10 +1957,7 @@ static int mtk_hw_deinit(struct mtk_eth *eth)
if (!test_and_clear_bit(MTK_HW_INIT, >state))
return 0;
 
-   clk_disable_unprepare(eth->clks[MTK_CLK_GP2]);
-   clk_disable_unprepare(eth->clks[MTK_CLK_GP1]);
-   clk_disable_unprepare(eth->clks[MTK_CLK_ESW]);
-   clk_disable_unprepare(eth->clks[MTK_CLK_ETHIF]);
+   mtk_clk_disable(eth);
 
pm_runtime_put_sync(eth->dev);
pm_runtime_disable(eth->dev);
@@ -2406,6 +2435,7 @@ static int mtk_probe(struct platform_device *pdev)
 {
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
struct device_node *mac_np;
+   const struct of_device_id *match;
struct mtk_eth *eth;
int err;
int i;
@@ -2414,6 +2444,9 @@ static int mtk_probe(struct platform_device *pdev)
if (!eth)
return -ENOMEM;
 
+   match = of_match_device(of_mtk_match, >dev);
+   eth->soc = (struct mtk_soc_data *)match->data;
+
eth->dev = >dev;
eth->base = devm_ioremap_resource(>dev, res);
if (IS_ERR(eth->base))
@@ -2450,7 +2483,12 @@ static int mtk_probe(struct platform_device *pdev)
if (IS_ERR(eth->clks[i])) {
if (PTR_ERR(eth->clks[i]) == -EPROBE_DEFER)
return -EPROBE_DEFER;
-   return -ENODEV;
+   if 

[PATCH net-next 3/4] net-next: mediatek: add support for MediaTek MT7622 SoC

[sean.wang]

From: Sean Wang 

This patch adds the driver for ethernet controller on MT7622 SoC. It has
the similar handling logic as the previously MT7623 does, but there are
additions against with MT7623 SoC, the shared SGMII given for the dual
GMACs and including 5-ports 10/100 embedded switch support (ESW) as the
GMAC1 option, thus more clocks consumers for the extra feature are
introduced here. So for ease portability and maintenance, those
differences all are being kept inside the platform data as other drivers
usually do. Currently testing successfully is done with those patches for
the conditions such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with
RTL8211F PHY via SGMII.

Signed-off-by: Sean Wang 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 72 -
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 54 +-
 2 files changed, 122 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 51ca79f..e3dbea1 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -52,7 +52,8 @@ static const struct mtk_ethtool_stats {
 };
 
 static const char * const mtk_clks_source_name[] = {
-   "ethif", "esw", "gp1", "gp2", "trgpll"
+   "ethif", "esw", "gp0", "gp1", "gp2", "trgpll", "sgmii_tx250m",
+   "sgmii_rx250m", "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii_ck", "eth2pll"
 };
 
 void mtk_w32(struct mtk_eth *eth, u32 val, unsigned reg)
@@ -162,6 +163,47 @@ static void mtk_gmac0_rgmii_adjust(struct mtk_eth *eth, 
int speed)
mtk_w32(eth, val, TRGMII_TCK_CTRL);
 }
 
+static void mtk_gmac_sgmii_hw_setup(struct mtk_eth *eth, int mac_id)
+{
+   u32 val;
+
+   /* Setup the link timer and QPHY power up inside SGMIISYS */
+   regmap_write(eth->sgmiisys, SGMSYS_PCS_LINK_TIMER,
+SGMII_LINK_TIMER_DEFAULT);
+
+   regmap_read(eth->sgmiisys, SGMSYS_SGMII_MODE, );
+   val |= SGMII_REMOTE_FAULT_DIS;
+   regmap_write(eth->sgmiisys, SGMSYS_SGMII_MODE, val);
+
+   regmap_read(eth->sgmiisys, SGMSYS_PCS_CONTROL_1, );
+   val |= SGMII_AN_RESTART;
+   regmap_write(eth->sgmiisys, SGMSYS_PCS_CONTROL_1, val);
+
+   regmap_read(eth->sgmiisys, SGMSYS_QPHY_PWR_STATE_CTRL, );
+   val &= ~SGMII_PHYA_PWD;
+   regmap_write(eth->sgmiisys, SGMSYS_QPHY_PWR_STATE_CTRL, val);
+
+   /* Determine MUX for which GMAC uses the SGMII interface */
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_DUAL_GMAC_SHARED_SGMII)) {
+   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, );
+   val &= ~SYSCFG0_SGMII_MASK;
+   val |= !mac_id ? SYSCFG0_SGMII_GMAC1 : SYSCFG0_SGMII_GMAC2;
+   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+
+   dev_info(eth->dev, "setup shared sgmii for gmac=%d\n",
+mac_id);
+   }
+
+   /* Setup the GMAC1 going through SGMII path when SoC also support
+* ESW on GMAC1
+*/
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_GMAC1_ESW | MTK_GMAC1_SGMII) &&
+   !mac_id) {
+   mtk_w32(eth, 0, MTK_MAC_MISC);
+   dev_info(eth->dev, "setup gmac1 going through sgmii");
+   }
+}
+
 static void mtk_phy_link_adjust(struct net_device *dev)
 {
struct mtk_mac *mac = netdev_priv(dev);
@@ -269,6 +311,7 @@ static int mtk_phy_connect(struct net_device *dev)
if (!np)
return -ENODEV;
 
+   mac->ge_mode = 0;
switch (of_get_phy_mode(np)) {
case PHY_INTERFACE_MODE_TRGMII:
mac->trgmii = true;
@@ -276,7 +319,15 @@ static int mtk_phy_connect(struct net_device *dev)
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII:
-   mac->ge_mode = 0;
+   break;
+   case PHY_INTERFACE_MODE_SGMII:
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII))
+   mtk_gmac_sgmii_hw_setup(eth, mac->id);
+   break;
+   case PHY_INTERFACE_MODE_INTERNAL:
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_GMAC1_ESW) && !mac->id)
+   /* Setup the path through ESW internal switch */
+   mtk_w32(eth, MTK_MUX_TO_ESW, MTK_MAC_MISC);
break;
case PHY_INTERFACE_MODE_MII:
mac->ge_mode = 1;
@@ -2424,6 +2475,7 @@ static int mtk_get_chip_id(struct mtk_eth *eth, u32 
*chip_id)
 static bool mtk_is_hwlro_supported(struct mtk_eth *eth)
 {
switch (eth->chip_id) {
+   case MT7622_ETH:
case MT7623_ETH:
return true;
}
@@ -2463,6 +2515,16 @@ static int mtk_probe(struct platform_device *pdev)
return PTR_ERR(eth->ethsys);
}
 
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
+   eth->sgmiisys =
+   syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+  

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

[Adam Borowski]

On Tue, Jul 11, 2017 at 06:01:38AM +, Nick Terrell wrote:
> On 7/10/17, 9:57 PM, "Nick Terrell"  wrote:
> > 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.
>
> Sorry, my patch still triggered the gcc bug, I used the wrong compiler.
> This patch works, and runs about the same speed as before the patch for
> small inputs, and slightly faster for larger inputs (100+ bytes). I'll
> look for a faster workaround if benchmarks show it matters.

Confirmed, the fix stops the crash for me.  Yay!

> --- a/lib/zstd/zstd_internal.h
> +++ b/lib/zstd/zstd_internal.h
> @@ -139,12 +139,8 @@ static void ZSTD_copy8(void *dst, const void *src) { 
> memcpy(dst, src, 8); }
>  #define WILDCOPY_OVERLENGTH 8
>  ZSTD_STATIC void ZSTD_wildcopy(void *dst, const void *src, ptrdiff_t length)
>  {
> - const BYTE *ip = (const BYTE *)src;
> - BYTE *op = (BYTE *)dst;
> - BYTE *const oend = op + length;
> - do
> - COPY8(op, ip)
> - while (op < oend);
> + if (length > 0)
> + memcpy(dst, src, length);
>  }
>  
>  ZSTD_STATIC void ZSTD_wildcopy_e(void *dst, const void *src, void *dstEnd) 
> /* should be faster for decoding, but strangely, not verified on all platform 
> */

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

[PATCH net-next 1/4] dt-bindings: net: mediatek: add support for MediaTek MT7623 and MT7622 SoC

[sean.wang]

From: Sean Wang 

The patch adds the supplements in the dt-binding document for MediaTek
MT7622 SoC with extra SGMII system controller and relevant clock consumers
listed as the requirements for those SoCs equipped with the SGMII circuit.
Also, add the missing binding information for MT7623 SoC here which relies
on the fallback binding of MT2701.

Signed-off-by: Sean Wang 
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index c7194e8..1d1168b 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -7,24 +7,30 @@ have dual GMAC each represented by a child node..
 * Ethernet controller node
 
 Required properties:
-- compatible: Should be "mediatek,mt2701-eth"
+- compatible: Should be
+   "mediatek,mt2701-eth": for MT2701 SoC
+   "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
+   "mediatek,mt7622-eth": for MT7622 SoC
 - reg: Address and length of the register set for the device
 - interrupts: Should contain the three frame engines interrupts in numeric
order. These are fe_int0, fe_int1 and fe_int2.
 - clocks: the clock used by the core
 - clock-names: the names of the clock listed in the clocks property. These are
-   "ethif", "esw", "gp2", "gp1"
+   "ethif", "esw", "gp2", "gp1" : For MT2701 and MT7623 SoC
+"ethif", "esw", "gp0", "gp1", "gp2", "sgmii_tx250m", "sgmii_rx250m",
+   "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii_ck", "eth2pll" : For MT7622 SoC
 - power-domains: phandle to the power domain that the ethernet is part of
 - resets: Should contain a phandle to the ethsys reset signal
 - reset-names: Should contain the reset signal name "eth"
 - mediatek,ethsys: phandle to the syscon node that handles the port setup
+- mediatek,sgmiisys: phandle to the syscon node that handles the SGMII setup
+   which is required for those SoCs equipped with SGMII such as MT7622 SoC.
 - mediatek,pctl: phandle to the syscon node that handles the ports slew rate
and driver current
 
 Optional properties:
 - interrupt-parent: Should be the phandle for the interrupt controller
   that services interrupts for this device
-
 * Ethernet MAC node
 
 Required properties:
-- 
2.7.4

[PATCH net-next 1/4] dt-bindings: net: mediatek: add support for MediaTek MT7623 and MT7622 SoC

[sean.wang]

From: Sean Wang 

The patch adds the supplements in the dt-binding document for MediaTek
MT7622 SoC with extra SGMII system controller and relevant clock consumers
listed as the requirements for those SoCs equipped with the SGMII circuit.
Also, add the missing binding information for MT7623 SoC here which relies
on the fallback binding of MT2701.

Signed-off-by: Sean Wang 
---
 Documentation/devicetree/bindings/net/mediatek-net.txt | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index c7194e8..1d1168b 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -7,24 +7,30 @@ have dual GMAC each represented by a child node..
 * Ethernet controller node
 
 Required properties:
-- compatible: Should be "mediatek,mt2701-eth"
+- compatible: Should be
+   "mediatek,mt2701-eth": for MT2701 SoC
+   "mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
+   "mediatek,mt7622-eth": for MT7622 SoC
 - reg: Address and length of the register set for the device
 - interrupts: Should contain the three frame engines interrupts in numeric
order. These are fe_int0, fe_int1 and fe_int2.
 - clocks: the clock used by the core
 - clock-names: the names of the clock listed in the clocks property. These are
-   "ethif", "esw", "gp2", "gp1"
+   "ethif", "esw", "gp2", "gp1" : For MT2701 and MT7623 SoC
+"ethif", "esw", "gp0", "gp1", "gp2", "sgmii_tx250m", "sgmii_rx250m",
+   "sgmii_cdr_ref", "sgmii_cdr_fb", "sgmii_ck", "eth2pll" : For MT7622 SoC
 - power-domains: phandle to the power domain that the ethernet is part of
 - resets: Should contain a phandle to the ethsys reset signal
 - reset-names: Should contain the reset signal name "eth"
 - mediatek,ethsys: phandle to the syscon node that handles the port setup
+- mediatek,sgmiisys: phandle to the syscon node that handles the SGMII setup
+   which is required for those SoCs equipped with SGMII such as MT7622 SoC.
 - mediatek,pctl: phandle to the syscon node that handles the ports slew rate
and driver current
 
 Optional properties:
 - interrupt-parent: Should be the phandle for the interrupt controller
   that services interrupts for this device
-
 * Ethernet MAC node
 
 Required properties:
-- 
2.7.4

[PATCH net-next 0/4] net-next: mediatek: add support for ethernet on MT7622 SoC

[sean.wang]

From: Sean Wang 

The series adds the driver for ethernet controller found on MT7622 SoC.
There are additions against with previous MT7623 SoC such as shared SGMII
given for the dual GMACs and built-in 5-ports 10/100 embedded switch support
(ESW). Thus more clocks consumers and SGMII hardware setup for the extra
features are all introduced here and as for the support for ESW that would be
planned to add in the separate patch integrating with DSA infrastructure
in the future.

Currently testing successfully is done with those patches for the conditions
such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with RTL8211F PHY via SGMII.

Sean Wang (4):
  dt-bindings: net: mediatek: add support for MediaTek MT7623 and MT7622
SoC
  net-next: mediatek: add platform data to adapt into various hardware
  net-next: mediatek: add support for MediaTek MT7622 SoC
  MAINTAINERS: add Sean/Nelson as MediaTek ethernet maintainers

 .../devicetree/bindings/net/mediatek-net.txt   |  12 +-
 MAINTAINERS|   2 +
 drivers/net/ethernet/mediatek/Kconfig  |   6 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c| 143 +++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h|  73 ++-
 5 files changed, 216 insertions(+), 20 deletions(-)

-- 
2.7.4

[PATCH net-next 0/4] net-next: mediatek: add support for ethernet on MT7622 SoC

[sean.wang]

From: Sean Wang 

The series adds the driver for ethernet controller found on MT7622 SoC.
There are additions against with previous MT7623 SoC such as shared SGMII
given for the dual GMACs and built-in 5-ports 10/100 embedded switch support
(ESW). Thus more clocks consumers and SGMII hardware setup for the extra
features are all introduced here and as for the support for ESW that would be
planned to add in the separate patch integrating with DSA infrastructure
in the future.

Currently testing successfully is done with those patches for the conditions
such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with RTL8211F PHY via SGMII.

Sean Wang (4):
  dt-bindings: net: mediatek: add support for MediaTek MT7623 and MT7622
SoC
  net-next: mediatek: add platform data to adapt into various hardware
  net-next: mediatek: add support for MediaTek MT7622 SoC
  MAINTAINERS: add Sean/Nelson as MediaTek ethernet maintainers

 .../devicetree/bindings/net/mediatek-net.txt   |  12 +-
 MAINTAINERS|   2 +
 drivers/net/ethernet/mediatek/Kconfig  |   6 +-
 drivers/net/ethernet/mediatek/mtk_eth_soc.c| 143 +++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h|  73 ++-
 5 files changed, 216 insertions(+), 20 deletions(-)

-- 
2.7.4

Re: [RFC v5 14/38] powerpc: initial plumbing for key management

[Balbir Singh]

On Wed,  5 Jul 2017 14:21:51 -0700
Ram Pai  wrote:

> Initial plumbing to manage all the keys supported by the
> hardware.
> 
> Total 32 keys are supported on powerpc. However pkey 0,1
> and 31 are reserved. So effectively we have 29 pkeys.
> 
> This patch keeps track of reserved keys, allocated  keys
> and keys that are currently free.

It looks like this patch will only work in guest mode?
Is that an assumption we've made? What happens if I use
keys when running in hypervisor mode?

> 
> Also it  adds  skeletal  functions  and macros, that the
> architecture-independent code expects to be available.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/Kconfig |   16 +
>  arch/powerpc/include/asm/book3s/64/mmu.h |9 +++
>  arch/powerpc/include/asm/pkeys.h |  106 
> ++
>  arch/powerpc/mm/mmu_context_book3s64.c   |5 ++
>  4 files changed, 136 insertions(+), 0 deletions(-)
>  create mode 100644 arch/powerpc/include/asm/pkeys.h
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index f7c8f99..a2480b6 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -871,6 +871,22 @@ config SECCOMP
>  
> If unsure, say Y. Only embedded should say N here.
>  
> +config PPC64_MEMORY_PROTECTION_KEYS
> + prompt "PowerPC Memory Protection Keys"
> + def_bool y
> + # Note: only available in 64-bit mode
> + depends on PPC64 && PPC_64K_PAGES
> + select ARCH_USES_HIGH_VMA_FLAGS
> + select ARCH_HAS_PKEYS
> + ---help---
> +   Memory Protection Keys provides a mechanism for enforcing
> +   page-based protections, but without requiring modification of the
> +   page tables when an application changes protection domains.
> +
> +   For details, see Documentation/powerpc/protection-keys.txt
> +
> +   If unsure, say y.
> +
>  endmenu
>  
>  config ISA_DMA_API
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
> b/arch/powerpc/include/asm/book3s/64/mmu.h
> index 77529a3..104ad72 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -108,6 +108,15 @@ struct patb_entry {
>  #ifdef CONFIG_SPAPR_TCE_IOMMU
>   struct list_head iommu_group_mem_list;
>  #endif
> +
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> + /*
> +  * Each bit represents one protection key.
> +  * bit set   -> key allocated
> +  * bit unset -> key available for allocation
> +  */
> + u32 pkey_allocation_map;
> +#endif
>  } mm_context_t;
>  
>  /*
> diff --git a/arch/powerpc/include/asm/pkeys.h 
> b/arch/powerpc/include/asm/pkeys.h
> new file mode 100644
> index 000..9345767
> --- /dev/null
> +++ b/arch/powerpc/include/asm/pkeys.h
> @@ -0,0 +1,106 @@
> +#ifndef _ASM_PPC64_PKEYS_H
> +#define _ASM_PPC64_PKEYS_H
> +
> +#define arch_max_pkey()  32
> +#define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
> + VM_PKEY_BIT3 | VM_PKEY_BIT4)
> +/*
> + * Bits are in BE format.
> + * NOTE: key 31, 1, 0 are not used.
> + * key 0 is used by default. It give read/write/execute permission.
> + * key 31 is reserved by the hypervisor.
> + * key 1 is recommended to be not used.
> + * PowerISA(3.0) page 1015, programming note.
> + */
> +#define PKEY_INITIAL_ALLOCAION  0xc001

Shouldn't this be exchanged via CAS for guests? Have you seen
ibm,processor-storage-keys?

> +
> +#define pkeybit_mask(pkey) (0x1 << (arch_max_pkey() - pkey - 1))
> +
> +#define mm_pkey_allocation_map(mm)   (mm->context.pkey_allocation_map)
> +
> +#define mm_set_pkey_allocated(mm, pkey) {\
> + mm_pkey_allocation_map(mm) |= pkeybit_mask(pkey); \
> +}
> +
> +#define mm_set_pkey_free(mm, pkey) { \
> + mm_pkey_allocation_map(mm) &= ~pkeybit_mask(pkey);  \
> +}
> +
> +#define mm_set_pkey_is_allocated(mm, pkey)   \
> + (mm_pkey_allocation_map(mm) & pkeybit_mask(pkey))
> +
> +#define mm_set_pkey_is_reserved(mm, pkey) (PKEY_INITIAL_ALLOCAION & \
> + pkeybit_mask(pkey))
> +
> +static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
> +{
> + /* a reserved key is never considered as 'explicitly allocated' */
> + return (!mm_set_pkey_is_reserved(mm, pkey) &&
> + mm_set_pkey_is_allocated(mm, pkey));
> +}
> +
> +/*
> + * Returns a positive, 5-bit key on success, or -1 on failure.
> + */
> +static inline int mm_pkey_alloc(struct mm_struct *mm)
> +{
> + /*
> +  * Note: this is the one and only place we make sure
> +  * that the pkey is valid as far as the hardware is
> +  * concerned.  The rest of the kernel trusts that
> +  * only good, valid pkeys come out of here.
> +  */
> + u32 all_pkeys_mask = (u32)(~(0x0));
> + int ret;
> +
> + /*
> +  * Are we out of pkeys?  We must handle this specially
> +  * because ffz() behavior is undefined if there are no
> +  * zeros.
> 

Re: [RFC v5 14/38] powerpc: initial plumbing for key management

[Balbir Singh]

On Wed,  5 Jul 2017 14:21:51 -0700
Ram Pai  wrote:

> Initial plumbing to manage all the keys supported by the
> hardware.
> 
> Total 32 keys are supported on powerpc. However pkey 0,1
> and 31 are reserved. So effectively we have 29 pkeys.
> 
> This patch keeps track of reserved keys, allocated  keys
> and keys that are currently free.

It looks like this patch will only work in guest mode?
Is that an assumption we've made? What happens if I use
keys when running in hypervisor mode?

> 
> Also it  adds  skeletal  functions  and macros, that the
> architecture-independent code expects to be available.
> 
> Signed-off-by: Ram Pai 
> ---
>  arch/powerpc/Kconfig |   16 +
>  arch/powerpc/include/asm/book3s/64/mmu.h |9 +++
>  arch/powerpc/include/asm/pkeys.h |  106 
> ++
>  arch/powerpc/mm/mmu_context_book3s64.c   |5 ++
>  4 files changed, 136 insertions(+), 0 deletions(-)
>  create mode 100644 arch/powerpc/include/asm/pkeys.h
> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index f7c8f99..a2480b6 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -871,6 +871,22 @@ config SECCOMP
>  
> If unsure, say Y. Only embedded should say N here.
>  
> +config PPC64_MEMORY_PROTECTION_KEYS
> + prompt "PowerPC Memory Protection Keys"
> + def_bool y
> + # Note: only available in 64-bit mode
> + depends on PPC64 && PPC_64K_PAGES
> + select ARCH_USES_HIGH_VMA_FLAGS
> + select ARCH_HAS_PKEYS
> + ---help---
> +   Memory Protection Keys provides a mechanism for enforcing
> +   page-based protections, but without requiring modification of the
> +   page tables when an application changes protection domains.
> +
> +   For details, see Documentation/powerpc/protection-keys.txt
> +
> +   If unsure, say y.
> +
>  endmenu
>  
>  config ISA_DMA_API
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
> b/arch/powerpc/include/asm/book3s/64/mmu.h
> index 77529a3..104ad72 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -108,6 +108,15 @@ struct patb_entry {
>  #ifdef CONFIG_SPAPR_TCE_IOMMU
>   struct list_head iommu_group_mem_list;
>  #endif
> +
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> + /*
> +  * Each bit represents one protection key.
> +  * bit set   -> key allocated
> +  * bit unset -> key available for allocation
> +  */
> + u32 pkey_allocation_map;
> +#endif
>  } mm_context_t;
>  
>  /*
> diff --git a/arch/powerpc/include/asm/pkeys.h 
> b/arch/powerpc/include/asm/pkeys.h
> new file mode 100644
> index 000..9345767
> --- /dev/null
> +++ b/arch/powerpc/include/asm/pkeys.h
> @@ -0,0 +1,106 @@
> +#ifndef _ASM_PPC64_PKEYS_H
> +#define _ASM_PPC64_PKEYS_H
> +
> +#define arch_max_pkey()  32
> +#define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
> + VM_PKEY_BIT3 | VM_PKEY_BIT4)
> +/*
> + * Bits are in BE format.
> + * NOTE: key 31, 1, 0 are not used.
> + * key 0 is used by default. It give read/write/execute permission.
> + * key 31 is reserved by the hypervisor.
> + * key 1 is recommended to be not used.
> + * PowerISA(3.0) page 1015, programming note.
> + */
> +#define PKEY_INITIAL_ALLOCAION  0xc001

Shouldn't this be exchanged via CAS for guests? Have you seen
ibm,processor-storage-keys?

> +
> +#define pkeybit_mask(pkey) (0x1 << (arch_max_pkey() - pkey - 1))
> +
> +#define mm_pkey_allocation_map(mm)   (mm->context.pkey_allocation_map)
> +
> +#define mm_set_pkey_allocated(mm, pkey) {\
> + mm_pkey_allocation_map(mm) |= pkeybit_mask(pkey); \
> +}
> +
> +#define mm_set_pkey_free(mm, pkey) { \
> + mm_pkey_allocation_map(mm) &= ~pkeybit_mask(pkey);  \
> +}
> +
> +#define mm_set_pkey_is_allocated(mm, pkey)   \
> + (mm_pkey_allocation_map(mm) & pkeybit_mask(pkey))
> +
> +#define mm_set_pkey_is_reserved(mm, pkey) (PKEY_INITIAL_ALLOCAION & \
> + pkeybit_mask(pkey))
> +
> +static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
> +{
> + /* a reserved key is never considered as 'explicitly allocated' */
> + return (!mm_set_pkey_is_reserved(mm, pkey) &&
> + mm_set_pkey_is_allocated(mm, pkey));
> +}
> +
> +/*
> + * Returns a positive, 5-bit key on success, or -1 on failure.
> + */
> +static inline int mm_pkey_alloc(struct mm_struct *mm)
> +{
> + /*
> +  * Note: this is the one and only place we make sure
> +  * that the pkey is valid as far as the hardware is
> +  * concerned.  The rest of the kernel trusts that
> +  * only good, valid pkeys come out of here.
> +  */
> + u32 all_pkeys_mask = (u32)(~(0x0));
> + int ret;
> +
> + /*
> +  * Are we out of pkeys?  We must handle this specially
> +  * because ffz() behavior is undefined if there are no
> +  * zeros.
> +  */
> + if 

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

[Zhenyu Wang]

On 2017.07.11 11:12:36 +0200, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 08:14:08AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > > +struct vfio_device_query_gfx_plane {
> > > > +   __u32 argsz;
> > > > +   __u32 flags;
> > > > +   struct vfio_device_gfx_plane_info plane_info;
> > > > +   __u32 plane_type;
> > > > +   __s32 fd; /* dma-buf fd */
> > > > +   __u32 plane_id;
> > > > +};
> > > > +
> > > 
> > > It would be better to have comment here about what are expected
> > > values
> > > for plane_type and plane_id.
> > 
> > plane_type is DRM_PLANE_TYPE_*.
> > 
> > yes, a comment saying so would be good, same for drm_format which is
> > DRM_FORMAT_*.  While looking at these two: renaming plane_type to
> > drm_plane_type (for consistency) is probably a good idea too.

For drm universal plane, this is not in drm uapi, but uabi. I think we
can align with drm plane definition for sure, but not need to pull in
drm header for that enum type.

> > 
> > plane_id needs a specification.
> 
> Why do you need plane_type? With universal planes the plane_id along is
> sufficient to identify a plane on a given drm device instance. I'd just
> remove it.

This interface is to get vGPU display plane info, there's no normal
drm kms client involved, but vGPU device model trys to expose guest
planes for display. We need to ask for what type of plane required on
target vGPU. I think plane_id here doesn't mean like in drm kms,
but I'm not sure about plane_id here without details, what's the
purpose, etc.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature

Re: [PATCH v10] vfio: ABI for mdev display dma-buf operation

[Zhenyu Wang]

On 2017.07.11 11:12:36 +0200, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 08:14:08AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > > +struct vfio_device_query_gfx_plane {
> > > > +   __u32 argsz;
> > > > +   __u32 flags;
> > > > +   struct vfio_device_gfx_plane_info plane_info;
> > > > +   __u32 plane_type;
> > > > +   __s32 fd; /* dma-buf fd */
> > > > +   __u32 plane_id;
> > > > +};
> > > > +
> > > 
> > > It would be better to have comment here about what are expected
> > > values
> > > for plane_type and plane_id.
> > 
> > plane_type is DRM_PLANE_TYPE_*.
> > 
> > yes, a comment saying so would be good, same for drm_format which is
> > DRM_FORMAT_*.  While looking at these two: renaming plane_type to
> > drm_plane_type (for consistency) is probably a good idea too.

For drm universal plane, this is not in drm uapi, but uabi. I think we
can align with drm plane definition for sure, but not need to pull in
drm header for that enum type.

> > 
> > plane_id needs a specification.
> 
> Why do you need plane_type? With universal planes the plane_id along is
> sufficient to identify a plane on a given drm device instance. I'd just
> remove it.

This interface is to get vGPU display plane info, there's no normal
drm kms client involved, but vGPU device model trys to expose guest
planes for display. We need to ask for what type of plane required on
target vGPU. I think plane_id here doesn't mean like in drm kms,
but I'm not sure about plane_id here without details, what's the
purpose, etc.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature

Re: [PATCH v1] clk: fractional-divider: fix up the fractional clk's jitter

[Elaine Zhang]

On 07/06/2017 06:01 PM, Heiko Stübner wrote:

Hi Elaine,

Am Donnerstag, 6. Juli 2017, 16:28:34 CEST schrieb Elaine Zhang:

fractional divider must set that denominator is 20 times larger than
numerator to generate precise clock frequency.
Otherwise the CLK jitter is very big, poor quality of the clock signal.

RK document description:
3.1.9  Fractional divider usage
To get specific frequency, clocks of I2S, SPDIF, UARTcan be generated by
fractional divider. Generally you must set that denominator is 20 times
larger than numerator to generate precise clock frequency. So the
fractional divider applies only to generate low frequency clock like
I2S, UART.

Signed-off-by: Elaine Zhang 
---
  drivers/clk/clk-fractional-divider.c | 13 +


As I said in our previous private mails, having soc-specific quirks in
the generic driver won't work.

I just realized that while I mentioned a different approach in one my
mails, I seem to have forgotten to attach the patch showcasing my idea.
[Just realized that while looking at the old mails] Sorry about that.

So the idea would be allowing clk-fractional users to just provide their
own approximation function, which you could then provide one
for the rockchip-specific requirements. That change was only compile-
tested at the time, so you might want to check if it actually works,


For the below you would "just" need to create an approximation
function and adapt the rockchip_clk_register_frac_branch
to set div->approx to your approximation function.


Heiko


-
From: Heiko Stuebner 
Date: Fri, 2 Jun 2017 13:42:51 +0200
Subject: [PATCH] clk: fractional-divider: allow clk-specific approximation
  functions

Fractional dividers may have special requirements concerning numerator
and denominator selection that differ from just getting the best
approximation.

For example on Rockchip socs the denominator must be at least 20 times
larger than the numerator to generate precise clock frequencies.

Therefore add the ability to provide custom approximation functions
but fall back to rational_best_approximation in the default case.


The custom approximation functions is not need.
The rational_best_approximation is work well, I modified is parent_rate,
I just need to make sure the parent_rate > frac_rate * 20.
According to your patch, I can't correction the parent_rate.

In clk_fd_round_rate() function:
fd->approx(rate, *parent_rate,
GENMASK(fd->mwidth - 1, 0), GENMASK(fd->nwidth - 1, 0),
, );
I just need to set the *parent_rate >= 20* rate.



Signed-off-by: Heiko Stuebner 
---
  drivers/clk/clk-fractional-divider.c | 42 
  include/linux/clk-provider.h | 17 +++
  2 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-fractional-divider.c 
b/drivers/clk/clk-fractional-divider.c
index aab904618eb6..2a066d8182e1 100644
--- a/drivers/clk/clk-fractional-divider.c
+++ b/drivers/clk/clk-fractional-divider.c
@@ -69,7 +69,7 @@ static long clk_fd_round_rate(struct clk_hw *hw, unsigned 
long rate,
if (scale > fd->nwidth)
rate <<= scale - fd->nwidth;

-   rational_best_approximation(rate, *parent_rate,
+   fd->approx(rate, *parent_rate,
GENMASK(fd->mwidth - 1, 0), GENMASK(fd->nwidth - 1, 0),
, );

@@ -87,7 +87,7 @@ static int clk_fd_set_rate(struct clk_hw *hw, unsigned long 
rate,
unsigned long m, n;
u32 val;

-   rational_best_approximation(rate, parent_rate,
+   fd->approx(rate, parent_rate,
GENMASK(fd->mwidth - 1, 0), GENMASK(fd->nwidth - 1, 0),
, );

@@ -116,10 +116,13 @@ const struct clk_ops clk_fractional_divider_ops = {
  };
  EXPORT_SYMBOL_GPL(clk_fractional_divider_ops);

-struct clk_hw *clk_hw_register_fractional_divider(struct device *dev,
+struct clk_hw *clk_hw_register_fractional_divider_custom(struct device *dev,
const char *name, const char *parent_name, unsigned long flags,
void __iomem *reg, u8 mshift, u8 mwidth, u8 nshift, u8 nwidth,
-   u8 clk_divider_flags, spinlock_t *lock)
+   u8 clk_divider_flags, spinlock_t *lock, void (*approx)
+   (unsigned long gnum, unsigned long gdenom,
+unsigned long mnum, unsigned long mdenom,
+unsigned long *bnum, unsigned long *bdenom))
  {
struct clk_fractional_divider *fd;
struct clk_init_data init;
@@ -145,6 +148,7 @@ struct clk_hw *clk_hw_register_fractional_divider(struct 
device *dev,
fd->nmask = GENMASK(nwidth - 1, 0) << nshift;
fd->flags = clk_divider_flags;
fd->lock = lock;
+   fd->approx = approx;
fd->hw.init = 

hw = >hw;
@@ -156,8 +160,38 @@ struct clk_hw 

Re: [PATCH v1] clk: fractional-divider: fix up the fractional clk's jitter

[Elaine Zhang]

On 07/06/2017 06:01 PM, Heiko Stübner wrote:

Hi Elaine,

Am Donnerstag, 6. Juli 2017, 16:28:34 CEST schrieb Elaine Zhang:

fractional divider must set that denominator is 20 times larger than
numerator to generate precise clock frequency.
Otherwise the CLK jitter is very big, poor quality of the clock signal.

RK document description:
3.1.9  Fractional divider usage
To get specific frequency, clocks of I2S, SPDIF, UARTcan be generated by
fractional divider. Generally you must set that denominator is 20 times
larger than numerator to generate precise clock frequency. So the
fractional divider applies only to generate low frequency clock like
I2S, UART.

Signed-off-by: Elaine Zhang 
---
  drivers/clk/clk-fractional-divider.c | 13 +


As I said in our previous private mails, having soc-specific quirks in
the generic driver won't work.

I just realized that while I mentioned a different approach in one my
mails, I seem to have forgotten to attach the patch showcasing my idea.
[Just realized that while looking at the old mails] Sorry about that.

So the idea would be allowing clk-fractional users to just provide their
own approximation function, which you could then provide one
for the rockchip-specific requirements. That change was only compile-
tested at the time, so you might want to check if it actually works,


For the below you would "just" need to create an approximation
function and adapt the rockchip_clk_register_frac_branch
to set div->approx to your approximation function.


Heiko


-
From: Heiko Stuebner 
Date: Fri, 2 Jun 2017 13:42:51 +0200
Subject: [PATCH] clk: fractional-divider: allow clk-specific approximation
  functions

Fractional dividers may have special requirements concerning numerator
and denominator selection that differ from just getting the best
approximation.

For example on Rockchip socs the denominator must be at least 20 times
larger than the numerator to generate precise clock frequencies.

Therefore add the ability to provide custom approximation functions
but fall back to rational_best_approximation in the default case.


The custom approximation functions is not need.
The rational_best_approximation is work well, I modified is parent_rate,
I just need to make sure the parent_rate > frac_rate * 20.
According to your patch, I can't correction the parent_rate.

In clk_fd_round_rate() function:
fd->approx(rate, *parent_rate,
GENMASK(fd->mwidth - 1, 0), GENMASK(fd->nwidth - 1, 0),
, );
I just need to set the *parent_rate >= 20* rate.



Signed-off-by: Heiko Stuebner 
---
  drivers/clk/clk-fractional-divider.c | 42 
  include/linux/clk-provider.h | 17 +++
  2 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk-fractional-divider.c 
b/drivers/clk/clk-fractional-divider.c
index aab904618eb6..2a066d8182e1 100644
--- a/drivers/clk/clk-fractional-divider.c
+++ b/drivers/clk/clk-fractional-divider.c
@@ -69,7 +69,7 @@ static long clk_fd_round_rate(struct clk_hw *hw, unsigned 
long rate,
if (scale > fd->nwidth)
rate <<= scale - fd->nwidth;

-   rational_best_approximation(rate, *parent_rate,
+   fd->approx(rate, *parent_rate,
GENMASK(fd->mwidth - 1, 0), GENMASK(fd->nwidth - 1, 0),
, );

@@ -87,7 +87,7 @@ static int clk_fd_set_rate(struct clk_hw *hw, unsigned long 
rate,
unsigned long m, n;
u32 val;

-   rational_best_approximation(rate, parent_rate,
+   fd->approx(rate, parent_rate,
GENMASK(fd->mwidth - 1, 0), GENMASK(fd->nwidth - 1, 0),
, );

@@ -116,10 +116,13 @@ const struct clk_ops clk_fractional_divider_ops = {
  };
  EXPORT_SYMBOL_GPL(clk_fractional_divider_ops);

-struct clk_hw *clk_hw_register_fractional_divider(struct device *dev,
+struct clk_hw *clk_hw_register_fractional_divider_custom(struct device *dev,
const char *name, const char *parent_name, unsigned long flags,
void __iomem *reg, u8 mshift, u8 mwidth, u8 nshift, u8 nwidth,
-   u8 clk_divider_flags, spinlock_t *lock)
+   u8 clk_divider_flags, spinlock_t *lock, void (*approx)
+   (unsigned long gnum, unsigned long gdenom,
+unsigned long mnum, unsigned long mdenom,
+unsigned long *bnum, unsigned long *bdenom))
  {
struct clk_fractional_divider *fd;
struct clk_init_data init;
@@ -145,6 +148,7 @@ struct clk_hw *clk_hw_register_fractional_divider(struct 
device *dev,
fd->nmask = GENMASK(nwidth - 1, 0) << nshift;
fd->flags = clk_divider_flags;
fd->lock = lock;
+   fd->approx = approx;
fd->hw.init = 

hw = >hw;
@@ -156,8 +160,38 @@ struct clk_hw *clk_hw_register_fractional_divider(struct 
device *dev,

return hw;
  }

Re: [RFC PATCH 3/4] pmbus: Allow dynamic fan coefficient values

[Guenter Roeck]

On 07/11/2017 06:20 PM, Andrew Jeffery wrote:

On Tue, 2017-07-11 at 06:31 -0700, Guenter Roeck wrote:

On 07/10/2017 06:56 AM, Andrew Jeffery wrote:

Some PMBus chips, such as the MAX31785, use different coefficients for
FAN_COMMAND_[1-4] depending on whether the fan is in PWM (percent duty)
or RPM mode. Add a callback to allow the driver to provide the
applicable coefficients to avoid imposing on devices that don't have
this requirement.



Why not just introduce another class, such as PSC_PWM ?


I considered this up front however I wasn't sure where the PMBus sensor
classes were modelled from. The PMBus spec generally doesn't discuss


The classes are modeled from my brain, so we can do whatever we want with them.


PMW beyond the concept of fans, and given PSC_FAN already existed I had
a vague feeling that introducing PSC_PWM might not be the way to go. It
also means that PSC_FAN is implicitly RPM in some circumstances, or
both RPM and PWM in others, and wasn't previously contrasted against
PWM as PWM-specific configuration wasn't an option.

However if it's reasonable it should lead to a more straight forward
patch. I'll rework and resend if it falls out nicely.


Please do.

Thanks,
Guenter


Thanks,

Andrew




Signed-off-by: Andrew Jeffery 

---
   drivers/hwmon/pmbus/pmbus.h  |  18 +--
   drivers/hwmon/pmbus/pmbus_core.c | 112 
---
   2 files changed, 108 insertions(+), 22 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index 927eabc1b273..338ecc8b25a4 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -345,6 +345,12 @@ enum pmbus_sensor_classes {
   enum pmbus_data_format { linear = 0, direct, vid };
   enum vrm_version { vr11 = 0, vr12 };
   
+struct pmbus_coeffs {

+   int m; /* mantissa for direct data format */
+   int b; /* offset */
+   int R; /* exponent */

+};
+
   struct pmbus_driver_info {

int pages;  /* Total number of pages */

enum pmbus_data_format format[PSC_NUM_CLASSES];

@@ -353,9 +359,7 @@ struct pmbus_driver_info {

 * Support one set of coefficients for each sensor type
 * Used for chips providing data in direct mode.
 */

-   int m[PSC_NUM_CLASSES]; /* mantissa for direct data format */
-   int b[PSC_NUM_CLASSES]; /* offset */
-   int R[PSC_NUM_CLASSES]; /* exponent */

+   struct pmbus_coeffs coeffs[PSC_NUM_CLASSES];
   

u32 func[PMBUS_PAGES];  /* Functionality, per page */

/*

@@ -382,6 +386,14 @@ struct pmbus_driver_info {

int (*identify)(struct i2c_client *client,
struct pmbus_driver_info *info);
   

+   /*
+* If a fan's coefficents change over time (e.g. between RPM and PWM
+* mode), then the driver can provide a function for retrieving the
+* currently applicable coefficients.
+*/
+   const struct pmbus_coeffs *(*get_fan_coeffs)(
+   const struct pmbus_driver_info *info, int index,
+   enum pmbus_fan_mode mode, int command);
/* Allow the driver to interpret the fan command value */
int (*get_pwm_mode)(int id, u8 fan_config, u16 fan_command);
int (*set_pwm_mode)(int id, long mode, u8 *fan_config,

diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 3b0a55bbbd2c..4ff6a1fd5cce 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -58,10 +58,11 @@
   struct pmbus_sensor {

struct pmbus_sensor *next;

char name[PMBUS_NAME_SIZE]; /* sysfs sensor name */

-   struct device_attribute attribute;
+   struct sensor_device_attribute attribute;

u8 page;/* page number */
u16 reg;/* register */
enum pmbus_sensor_classes class;/* sensor class */

+   const struct pmbus_coeffs *coeffs;

bool update;/* runtime sensor update needed */
int data;   /* Sensor data.

   Negative if there was a read error */

@@ -89,6 +90,7 @@ struct pmbus_fan_ctrl {

u8 id;
u8 config;
u16 command;
+   const struct pmbus_coeffs *coeffs;

   };
   #define to_pmbus_fan_ctrl_attr(_attr) \

container_of(_attr, struct pmbus_fan_ctrl_attr, attribute)

@@ -511,9 +513,15 @@ static long pmbus_reg2data_direct(struct pmbus_data *data,

long val = (s16) sensor->data;
long m, b, R;
   

-   m = data->info->m[sensor->class];
-   b = data->info->b[sensor->class];
-   R = data->info->R[sensor->class];
+   if (sensor->coeffs) {
+   m = sensor->coeffs->m;
+   b = sensor->coeffs->b;
+   R = sensor->coeffs->R;
+   } else {
+   m = data->info->coeffs[sensor->class].m;
+   b = 

Re: [RFC PATCH 3/4] pmbus: Allow dynamic fan coefficient values

[Guenter Roeck]

On 07/11/2017 06:20 PM, Andrew Jeffery wrote:

On Tue, 2017-07-11 at 06:31 -0700, Guenter Roeck wrote:

On 07/10/2017 06:56 AM, Andrew Jeffery wrote:

Some PMBus chips, such as the MAX31785, use different coefficients for
FAN_COMMAND_[1-4] depending on whether the fan is in PWM (percent duty)
or RPM mode. Add a callback to allow the driver to provide the
applicable coefficients to avoid imposing on devices that don't have
this requirement.



Why not just introduce another class, such as PSC_PWM ?


I considered this up front however I wasn't sure where the PMBus sensor
classes were modelled from. The PMBus spec generally doesn't discuss


The classes are modeled from my brain, so we can do whatever we want with them.


PMW beyond the concept of fans, and given PSC_FAN already existed I had
a vague feeling that introducing PSC_PWM might not be the way to go. It
also means that PSC_FAN is implicitly RPM in some circumstances, or
both RPM and PWM in others, and wasn't previously contrasted against
PWM as PWM-specific configuration wasn't an option.

However if it's reasonable it should lead to a more straight forward
patch. I'll rework and resend if it falls out nicely.


Please do.

Thanks,
Guenter


Thanks,

Andrew




Signed-off-by: Andrew Jeffery 

---
   drivers/hwmon/pmbus/pmbus.h  |  18 +--
   drivers/hwmon/pmbus/pmbus_core.c | 112 
---
   2 files changed, 108 insertions(+), 22 deletions(-)

diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
index 927eabc1b273..338ecc8b25a4 100644
--- a/drivers/hwmon/pmbus/pmbus.h
+++ b/drivers/hwmon/pmbus/pmbus.h
@@ -345,6 +345,12 @@ enum pmbus_sensor_classes {
   enum pmbus_data_format { linear = 0, direct, vid };
   enum vrm_version { vr11 = 0, vr12 };
   
+struct pmbus_coeffs {

+   int m; /* mantissa for direct data format */
+   int b; /* offset */
+   int R; /* exponent */

+};
+
   struct pmbus_driver_info {

int pages;  /* Total number of pages */

enum pmbus_data_format format[PSC_NUM_CLASSES];

@@ -353,9 +359,7 @@ struct pmbus_driver_info {

 * Support one set of coefficients for each sensor type
 * Used for chips providing data in direct mode.
 */

-   int m[PSC_NUM_CLASSES]; /* mantissa for direct data format */
-   int b[PSC_NUM_CLASSES]; /* offset */
-   int R[PSC_NUM_CLASSES]; /* exponent */

+   struct pmbus_coeffs coeffs[PSC_NUM_CLASSES];
   

u32 func[PMBUS_PAGES];  /* Functionality, per page */

/*

@@ -382,6 +386,14 @@ struct pmbus_driver_info {

int (*identify)(struct i2c_client *client,
struct pmbus_driver_info *info);
   

+   /*
+* If a fan's coefficents change over time (e.g. between RPM and PWM
+* mode), then the driver can provide a function for retrieving the
+* currently applicable coefficients.
+*/
+   const struct pmbus_coeffs *(*get_fan_coeffs)(
+   const struct pmbus_driver_info *info, int index,
+   enum pmbus_fan_mode mode, int command);
/* Allow the driver to interpret the fan command value */
int (*get_pwm_mode)(int id, u8 fan_config, u16 fan_command);
int (*set_pwm_mode)(int id, long mode, u8 *fan_config,

diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 3b0a55bbbd2c..4ff6a1fd5cce 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -58,10 +58,11 @@
   struct pmbus_sensor {

struct pmbus_sensor *next;

char name[PMBUS_NAME_SIZE]; /* sysfs sensor name */

-   struct device_attribute attribute;
+   struct sensor_device_attribute attribute;

u8 page;/* page number */
u16 reg;/* register */
enum pmbus_sensor_classes class;/* sensor class */

+   const struct pmbus_coeffs *coeffs;

bool update;/* runtime sensor update needed */
int data;   /* Sensor data.

   Negative if there was a read error */

@@ -89,6 +90,7 @@ struct pmbus_fan_ctrl {

u8 id;
u8 config;
u16 command;
+   const struct pmbus_coeffs *coeffs;

   };
   #define to_pmbus_fan_ctrl_attr(_attr) \

container_of(_attr, struct pmbus_fan_ctrl_attr, attribute)

@@ -511,9 +513,15 @@ static long pmbus_reg2data_direct(struct pmbus_data *data,

long val = (s16) sensor->data;
long m, b, R;
   

-   m = data->info->m[sensor->class];
-   b = data->info->b[sensor->class];
-   R = data->info->R[sensor->class];
+   if (sensor->coeffs) {
+   m = sensor->coeffs->m;
+   b = sensor->coeffs->b;
+   R = sensor->coeffs->R;
+   } else {
+   m = data->info->coeffs[sensor->class].m;
+   b = data->info->coeffs[sensor->class].b;
+ 

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

[Li, Aubrey]

On 2017/7/12 2:11, Paul E. McKenney wrote:
> On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
>> On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote:
>>> On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
 From: Aubrey Li 

 The system will enter a fast idle loop if the predicted idle period
 is shorter than the threshold.
 ---
  kernel/sched/idle.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
 index cf6c11f..16a766c 100644
 --- a/kernel/sched/idle.c
 +++ b/kernel/sched/idle.c
 @@ -280,6 +280,8 @@ static void cpuidle_generic(void)
   */
  static void do_idle(void)
  {
 +  unsigned int predicted_idle_us;
 +  unsigned int short_idle_threshold = jiffies_to_usecs(1) / 2;
/*
 * If the arch has a polling bit, we maintain an invariant:
 *
 @@ -291,7 +293,12 @@ static void do_idle(void)

__current_set_polling();

 -  cpuidle_generic();
 +  predicted_idle_us = cpuidle_predict();
 +
 +  if (likely(predicted_idle_us < short_idle_threshold))
 +  cpuidle_fast();
>>>
>>> What if we get here from nohz_full usermode execution?  In that
>>> case, if I remember correctly, the scheduling-clock interrupt
>>> will still be disabled, and would have to be re-enabled before
>>> we could safely invoke cpuidle_fast().
>>>
>>> Or am I missing something here?
>>
>> That's a good point. It's partially ok because if the tick is needed
>> for something specific, it is not entirely stopped but programmed to that
>> deadline.
>>
>> Now there is some idle specific code when we enter dynticks-idle. See
>> tick_nohz_start_idle(), tick_nohz_stop_idle(), 
>> sched_clock_idle_wakeup_event()
>> and some subsystems that react differently when we enter dyntick idle
>> mode (scheduler_tick_max_deferment) so the tick may need a reevaluation.
>>
>> For now I'd rather suggest that we treat full nohz as an exception case here
>> and do:
>>
>> if (!tick_nohz_full_cpu(smp_processor_id()) && likely(predicted_idle_us 
>> < short_idle_threshold))
>> cpuidle_fast();
>>
>> Ugly but safer!
> 
> Works for me!
>

I guess who enabled full nohz(for example the financial guys who need the system
response as fast as possible) does not like this compromise, ;)

How about add rcu_idle enter/exit back only for full nohz case in fast idle? 
RCU idle
is the only risky ops if removing them from fast idle path. Comparing to adding 
RCU
idle back, going to normal idle path has more overhead IMHO.

Thanks,
-Aubrey

Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods

[Li, Aubrey]

On 2017/7/12 2:11, Paul E. McKenney wrote:
> On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
>> On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote:
>>> On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
 From: Aubrey Li 

 The system will enter a fast idle loop if the predicted idle period
 is shorter than the threshold.
 ---
  kernel/sched/idle.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
 index cf6c11f..16a766c 100644
 --- a/kernel/sched/idle.c
 +++ b/kernel/sched/idle.c
 @@ -280,6 +280,8 @@ static void cpuidle_generic(void)
   */
  static void do_idle(void)
  {
 +  unsigned int predicted_idle_us;
 +  unsigned int short_idle_threshold = jiffies_to_usecs(1) / 2;
/*
 * If the arch has a polling bit, we maintain an invariant:
 *
 @@ -291,7 +293,12 @@ static void do_idle(void)

__current_set_polling();

 -  cpuidle_generic();
 +  predicted_idle_us = cpuidle_predict();
 +
 +  if (likely(predicted_idle_us < short_idle_threshold))
 +  cpuidle_fast();
>>>
>>> What if we get here from nohz_full usermode execution?  In that
>>> case, if I remember correctly, the scheduling-clock interrupt
>>> will still be disabled, and would have to be re-enabled before
>>> we could safely invoke cpuidle_fast().
>>>
>>> Or am I missing something here?
>>
>> That's a good point. It's partially ok because if the tick is needed
>> for something specific, it is not entirely stopped but programmed to that
>> deadline.
>>
>> Now there is some idle specific code when we enter dynticks-idle. See
>> tick_nohz_start_idle(), tick_nohz_stop_idle(), 
>> sched_clock_idle_wakeup_event()
>> and some subsystems that react differently when we enter dyntick idle
>> mode (scheduler_tick_max_deferment) so the tick may need a reevaluation.
>>
>> For now I'd rather suggest that we treat full nohz as an exception case here
>> and do:
>>
>> if (!tick_nohz_full_cpu(smp_processor_id()) && likely(predicted_idle_us 
>> < short_idle_threshold))
>> cpuidle_fast();
>>
>> Ugly but safer!
> 
> Works for me!
>

I guess who enabled full nohz(for example the financial guys who need the system
response as fast as possible) does not like this compromise, ;)

How about add rcu_idle enter/exit back only for full nohz case in fast idle? 
RCU idle
is the only risky ops if removing them from fast idle path. Comparing to adding 
RCU
idle back, going to normal idle path has more overhead IMHO.

Thanks,
-Aubrey

Re: in:imklog segfault in 4.12+git on most sparc64's

[David Miller]

From: Meelis Roos 
Date: Tue, 11 Jul 2017 14:48:27 +0300 (EEST)

>> I tested yesterdays git with 4.13 sparc merge on a big bunch of my test 
>> machines.
>> 
>> Good news: the timestamps starting from boot seem to work on all the 
>> machines, starting with Ultra 1 and Ultra 2.
>> 
>> Bad news: all working sun4u machines have the following line in dmesg 
>> (PID varies):
>> in:imklog[1036]: segfault at 49 ip 00035bb0 (rpc f779dfa0) 
>> sp 0002f7a78818 error 30002 in rsyslogd[1+88000]
>> 
>> This is with Debian unstable 32-bit userland as of 2015 summer. It did 
>> not happen with 4.12.
> 
> I bisected it to the commit below. CC Al Viro.
> 
> In following commits around this one (some bisect steps before, and the 
> last step) the crashes were slightly different from the original crash 
> yersterday, like
> 
> in:imuxsock[1606]: segfault at fff8 ip f774e154 (rpc 
> f774dfe8) sp 0001f7965a68 error 30002 in 
> libc-2.19.so[f76cc000+16a000]
> 
> but this was the first commit introducing the crashes.
> 
> d9e968cb9f849770288f5fde3d8d3a5f7e339052 is the first bad commit
> commit d9e968cb9f849770288f5fde3d8d3a5f7e339052
> Author: Al Viro 
> Date:   Wed May 31 04:33:51 2017 -0400
> 
> getrlimit()/setrlimit(): move compat to native
> 
> Signed-off-by: Al Viro 
> 
> :04 04 5e1a0c25f4554ccdc824b18dc50078d379cdbf9a 
> 6d820451a388c5771a2a410578365d14a0194e4e M  kernel

I can't figure out what is wrong in this change, except that it does
two things at once.

It moves code, and changes it at the same time.  That should have been
done in two changes.

Because of that, we can't tell which of the two things introduced the
regression.

Al?

Re: in:imklog segfault in 4.12+git on most sparc64's

[David Miller]

From: Meelis Roos 
Date: Tue, 11 Jul 2017 14:48:27 +0300 (EEST)

>> I tested yesterdays git with 4.13 sparc merge on a big bunch of my test 
>> machines.
>> 
>> Good news: the timestamps starting from boot seem to work on all the 
>> machines, starting with Ultra 1 and Ultra 2.
>> 
>> Bad news: all working sun4u machines have the following line in dmesg 
>> (PID varies):
>> in:imklog[1036]: segfault at 49 ip 00035bb0 (rpc f779dfa0) 
>> sp 0002f7a78818 error 30002 in rsyslogd[1+88000]
>> 
>> This is with Debian unstable 32-bit userland as of 2015 summer. It did 
>> not happen with 4.12.
> 
> I bisected it to the commit below. CC Al Viro.
> 
> In following commits around this one (some bisect steps before, and the 
> last step) the crashes were slightly different from the original crash 
> yersterday, like
> 
> in:imuxsock[1606]: segfault at fff8 ip f774e154 (rpc 
> f774dfe8) sp 0001f7965a68 error 30002 in 
> libc-2.19.so[f76cc000+16a000]
> 
> but this was the first commit introducing the crashes.
> 
> d9e968cb9f849770288f5fde3d8d3a5f7e339052 is the first bad commit
> commit d9e968cb9f849770288f5fde3d8d3a5f7e339052
> Author: Al Viro 
> Date:   Wed May 31 04:33:51 2017 -0400
> 
> getrlimit()/setrlimit(): move compat to native
> 
> Signed-off-by: Al Viro 
> 
> :04 04 5e1a0c25f4554ccdc824b18dc50078d379cdbf9a 
> 6d820451a388c5771a2a410578365d14a0194e4e M  kernel

I can't figure out what is wrong in this change, except that it does
two things at once.

It moves code, and changes it at the same time.  That should have been
done in two changes.

Because of that, we can't tell which of the two things introduced the
regression.

Al?