Re: [PATCH v3] ata: add Amiga Gayle PATA controller driver

[Philippe Ombredanne]

On Fri, Mar 16, 2018 at 9:15 AM, Bartlomiej Zolnierkiewicz
 wrote:
> Add Amiga Gayle PATA controller driver. It enables libata support
> for the on-board IDE interfaces on some Amiga models (A600, A1200,
> A4000 and A4000T) and also for IDE interfaces on the Zorro expansion
> bus (M-Tech E-Matrix 530 expansion card).
>
> Thanks to John Paul Adrian Glaubitz and Michael Schmitz for help
> with testing the driver.
>
> Tested-by: John Paul Adrian Glaubitz 
> Cc: Michael Schmitz 
> Cc: Geert Uytterhoeven 
> Cc: Philippe Ombredanne 
> Cc: Andy Shevchenko 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
> v3:
> - fix minor issues reported by Andy
>
> v2:
> - clarify license version (it should be GPL 2.0)
> - use SPDX header

For the use of SPDX ids, you have my ack: (I am not qualified for the rest)

Acked-by: Philippe Ombredanne 

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v3] ata: add Amiga Gayle PATA controller driver

[Philippe Ombredanne]

On Fri, Mar 16, 2018 at 9:15 AM, Bartlomiej Zolnierkiewicz
 wrote:
> Add Amiga Gayle PATA controller driver. It enables libata support
> for the on-board IDE interfaces on some Amiga models (A600, A1200,
> A4000 and A4000T) and also for IDE interfaces on the Zorro expansion
> bus (M-Tech E-Matrix 530 expansion card).
>
> Thanks to John Paul Adrian Glaubitz and Michael Schmitz for help
> with testing the driver.
>
> Tested-by: John Paul Adrian Glaubitz 
> Cc: Michael Schmitz 
> Cc: Geert Uytterhoeven 
> Cc: Philippe Ombredanne 
> Cc: Andy Shevchenko 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> ---
> v3:
> - fix minor issues reported by Andy
>
> v2:
> - clarify license version (it should be GPL 2.0)
> - use SPDX header

For the use of SPDX ids, you have my ack: (I am not qualified for the rest)

Acked-by: Philippe Ombredanne 

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v10 1/5] arm64: KVM: Prepare set virtual SEI syndrome value

[gengdongjiu]

Hi James,

> 
> Hi Dongjiu Geng,
> 
> On 03/03/18 16:09, Dongjiu Geng wrote:
> > Export one API to specify virtual SEI syndrome value for guest, and
> > add a helper to get the VSESR_EL2 value.
> 
> This patch adds two helpers that nothing calls... its not big, please merge 
> it with the patch that uses these.

OK, thanks, I will merge them.

> 
> 
> > diff --git a/arch/arm64/include/asm/kvm_emulate.h
> > b/arch/arm64/include/asm/kvm_emulate.h
> > index 413dc82..3294885 100644
> > --- a/arch/arm64/include/asm/kvm_emulate.h
> > +++ b/arch/arm64/include/asm/kvm_emulate.h
> > @@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, 
> > unsigned long hcr)
> > vcpu->arch.hcr_el2 = hcr;
> >  }
> >
> > +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) {
> > +   return vcpu->arch.vsesr_el2;
> > +}
> > +
> >  static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
> > {
> > vcpu->arch.vsesr_el2 = vsesr;
> > diff --git a/arch/arm64/include/asm/kvm_host.h
> > b/arch/arm64/include/asm/kvm_host.h
> > index a73f63a..3dc49b7 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -354,6 +354,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu,
> > struct kvm_run *run,  int kvm_perf_init(void);  int
> > kvm_perf_teardown(void);
> >
> > +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
> > +
> >  struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long
> > mpidr);
> >
> >  static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr, diff
> > --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> > index 60666a0..78ecb28 100644
> > --- a/arch/arm64/kvm/inject_fault.c
> > +++ b/arch/arm64/kvm/inject_fault.c
> > @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu)  {
> > pend_guest_serror(vcpu, ESR_ELx_ISV);  }
> > +
> > +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) {
> > +   pend_guest_serror(vcpu, syndrome & ESR_ELx_ISS_MASK);
> 
> If you move the ISS_MASK into pend_guest_serror(), you wouldn't need this at 
> all.
> 
> It would be better if any validation were in the user-space helpers so we can 
> check user-space hasn't put something funny in the top bits.

Yes, I agree your idea, thanks for the good suggestion.

> 
> > +}
> >
> 
> 
> Thanks,
> 
> James

Re: [PATCH v10 1/5] arm64: KVM: Prepare set virtual SEI syndrome value

[gengdongjiu]

Hi James,

> 
> Hi Dongjiu Geng,
> 
> On 03/03/18 16:09, Dongjiu Geng wrote:
> > Export one API to specify virtual SEI syndrome value for guest, and
> > add a helper to get the VSESR_EL2 value.
> 
> This patch adds two helpers that nothing calls... its not big, please merge 
> it with the patch that uses these.

OK, thanks, I will merge them.

> 
> 
> > diff --git a/arch/arm64/include/asm/kvm_emulate.h
> > b/arch/arm64/include/asm/kvm_emulate.h
> > index 413dc82..3294885 100644
> > --- a/arch/arm64/include/asm/kvm_emulate.h
> > +++ b/arch/arm64/include/asm/kvm_emulate.h
> > @@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, 
> > unsigned long hcr)
> > vcpu->arch.hcr_el2 = hcr;
> >  }
> >
> > +static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu) {
> > +   return vcpu->arch.vsesr_el2;
> > +}
> > +
> >  static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
> > {
> > vcpu->arch.vsesr_el2 = vsesr;
> > diff --git a/arch/arm64/include/asm/kvm_host.h
> > b/arch/arm64/include/asm/kvm_host.h
> > index a73f63a..3dc49b7 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -354,6 +354,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu,
> > struct kvm_run *run,  int kvm_perf_init(void);  int
> > kvm_perf_teardown(void);
> >
> > +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
> > +
> >  struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long
> > mpidr);
> >
> >  static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr, diff
> > --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
> > index 60666a0..78ecb28 100644
> > --- a/arch/arm64/kvm/inject_fault.c
> > +++ b/arch/arm64/kvm/inject_fault.c
> > @@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu)  {
> > pend_guest_serror(vcpu, ESR_ELx_ISV);  }
> > +
> > +void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome) {
> > +   pend_guest_serror(vcpu, syndrome & ESR_ELx_ISS_MASK);
> 
> If you move the ISS_MASK into pend_guest_serror(), you wouldn't need this at 
> all.
> 
> It would be better if any validation were in the user-space helpers so we can 
> check user-space hasn't put something funny in the top bits.

Yes, I agree your idea, thanks for the good suggestion.

> 
> > +}
> >
> 
> 
> Thanks,
> 
> James

Re: [PATCH] arm64: rename the function arm64_is_ras_serror() to avoid confusion

[gengdongjiu]

Hi James,

> Hi gengdongjiu,
> 
> On 26/02/18 16:13, gengdongjiu wrote:
> > 2018-02-24 1:58 GMT+08:00 James Morse :
> >> On 22/02/18 18:02, Dongjiu Geng wrote:
> >>> The RAS SError Syndrome can be Implementation-Defined,
> >>> arm64_is_ras_serror() is used to judge whether it is RAS SError, but
> >>> arm64_is_ras_serror() does not include this judgement. In order to
> >>> avoid function name confusion, we rename the arm64_is_ras_serror()
> >>> to arm64_is_categorized_ras_serror(), this function is used to judge
> >>> whether it is categorized RAS Serror.
> >>
> >> I don't see how 'categorized' is relevant. The most significant ISS
> >> bit is used to determine if this is an IMP-DEF ESR, or one that uses the 
> >> architected layout.
> >
> > From the name arm64_is_ras_serror(), it used to judge whether this is
> > RAS Serror, but arm64_is_ras_serror() think the IMP-DEF SError is not
> > RAS SError, as shown the code note and code in[1].
> 
> > In fact the IMP-DEF SError is also RAS SError, so when I read the
> > code, it looks like
> 
> This is just you then. No-one else has your imp-def:RAS error ESR values.
> 
> This would be like me adding some impdef branch instruction, then claiming
> aarch64_insn_is_branch() doesn't take account of my private additions.
> 
> I agree the name is assuming all architected ESR are RAS-errors, and that 
> impdef ESR are just that: impdef, that's all we know about them.
> Unless this causes us to do the wrong thing, I don't think it matters.
> Obviously we would need to change it if a new architected ESR is added.

Ok, let us keep the current code and not change it until a new architected ESR 
is added

Re: [PATCH] arm64: rename the function arm64_is_ras_serror() to avoid confusion

[gengdongjiu]

Hi James,

> Hi gengdongjiu,
> 
> On 26/02/18 16:13, gengdongjiu wrote:
> > 2018-02-24 1:58 GMT+08:00 James Morse :
> >> On 22/02/18 18:02, Dongjiu Geng wrote:
> >>> The RAS SError Syndrome can be Implementation-Defined,
> >>> arm64_is_ras_serror() is used to judge whether it is RAS SError, but
> >>> arm64_is_ras_serror() does not include this judgement. In order to
> >>> avoid function name confusion, we rename the arm64_is_ras_serror()
> >>> to arm64_is_categorized_ras_serror(), this function is used to judge
> >>> whether it is categorized RAS Serror.
> >>
> >> I don't see how 'categorized' is relevant. The most significant ISS
> >> bit is used to determine if this is an IMP-DEF ESR, or one that uses the 
> >> architected layout.
> >
> > From the name arm64_is_ras_serror(), it used to judge whether this is
> > RAS Serror, but arm64_is_ras_serror() think the IMP-DEF SError is not
> > RAS SError, as shown the code note and code in[1].
> 
> > In fact the IMP-DEF SError is also RAS SError, so when I read the
> > code, it looks like
> 
> This is just you then. No-one else has your imp-def:RAS error ESR values.
> 
> This would be like me adding some impdef branch instruction, then claiming
> aarch64_insn_is_branch() doesn't take account of my private additions.
> 
> I agree the name is assuming all architected ESR are RAS-errors, and that 
> impdef ESR are just that: impdef, that's all we know about them.
> Unless this causes us to do the wrong thing, I don't think it matters.
> Obviously we would need to change it if a new architected ESR is added.

Ok, let us keep the current code and not change it until a new architected ESR 
is added

Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode

[Baruch Siach]

Hi Antoine,

On Fri, Mar 16, 2018 at 11:33:46AM +0100, Antoine Tenart wrote:
> This patch allow the CP100 comphy to configure some lanes in the

Should be 'CP110'.

> 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
> same code path.
> 
> Signed-off-by: Antoine Tenart 

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH net-next 05/10] phy: cp110-comphy: 2.5G SGMII mode

[Baruch Siach]

Hi Antoine,

On Fri, Mar 16, 2018 at 11:33:46AM +0100, Antoine Tenart wrote:
> This patch allow the CP100 comphy to configure some lanes in the

Should be 'CP110'.

> 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
> same code path.
> 
> Signed-off-by: Antoine Tenart 

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[RFC PATCH] ext2, dax: ext2_dax_aops can be static

[kbuild test robot]

Fixes: 97affa6a9d1c ("ext2, dax: introduce ext2_dax_aops")
Signed-off-by: Fengguang Wu 
---
 inode.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 9590712..8ea394c8 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -989,7 +989,7 @@ const struct address_space_operations ext2_nobh_aops = {
.error_remove_page  = generic_error_remove_page,
 };
 
-const struct address_space_operations ext2_dax_aops = {
+static const struct address_space_operations ext2_dax_aops = {
.direct_IO  = ext2_direct_IO,
.writepages = ext2_dax_writepages,
.set_page_dirty = noop_set_page_dirty,

[RFC PATCH] ext2, dax: ext2_dax_aops can be static

[kbuild test robot]

Fixes: 97affa6a9d1c ("ext2, dax: introduce ext2_dax_aops")
Signed-off-by: Fengguang Wu 
---
 inode.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index 9590712..8ea394c8 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -989,7 +989,7 @@ const struct address_space_operations ext2_nobh_aops = {
.error_remove_page  = generic_error_remove_page,
 };
 
-const struct address_space_operations ext2_dax_aops = {
+static const struct address_space_operations ext2_dax_aops = {
.direct_IO  = ext2_direct_IO,
.writepages = ext2_dax_writepages,
.set_page_dirty = noop_set_page_dirty,

Re: [PATCH v6 06/15] ext2, dax: introduce ext2_dax_aops

[kbuild test robot]

Hi Dan,

I love your patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> fs/ext2/inode.c:992:39: sparse: symbol 'ext2_dax_aops' was not declared. 
>> Should it be static?

Please review and possibly fold the followup patch.

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

Re: [PATCH v6 06/15] ext2, dax: introduce ext2_dax_aops

[kbuild test robot]

Hi Dan,

I love your patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> fs/ext2/inode.c:992:39: sparse: symbol 'ext2_dax_aops' was not declared. 
>> Should it be static?

Please review and possibly fold the followup patch.

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

Re: [PATCH v4.16-rc5 2/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

[Jason Vas Dias]

On 18/03/2018, Jason Vas Dias  wrote:
(should have CC'ed to list, sorry)
> On 17/03/2018, Andi Kleen  wrote:
>>
>> That's quite a mischaracterization of the issue. gcc works as intended,
>> but the kernel did not correctly supply a indirect call retpoline thunk
>> to the vdso, and it just happened to work by accident with the old
>> vdso.
>>
>>>
>>>  The automated test builds should now succeed with this patch.
>>
>> How about just adding the thunk function to the vdso object instead of
>> this cheap hack?
>>
>> The other option would be to build vdso with inline thunks.
>>
>> But just disabling is completely the wrong action.
>>
>> -Andi
>>
>
> Aha! Thanks for the clarification , Andi!
>
> I will do so and resend the 2nd patch.
>
> But is everyone agreed we should accept any slowdown for the timer
> functions ? I personally don't think it is a good idea, but I will
> regenerate the patch with the thunk function and without
> the Makefile change.
>
> Thanks & Best Regards,
> Jason
>


I am wondering if it is not better to avoid the thunk being generated
and remove the Makefile patch ?

I know that changing the switch in __vdso_clock_gettime() like
this avoids the thunk :

   switch(clock) {
   case CLOCK_MONOTONIC:
if (do_monotonic(ts) == VCLOCK_NONE)
goto fallback;
break;
default:
switch (clock) {
case CLOCK_REALTIME:
if (do_realtime(ts) == VCLOCK_NONE)
   goto fallback;
break;
 case CLOCK_MONOTONIC_RAW:
 if (do_monotonic_raw(ts) == VCLOCK_NONE)
   goto fallback;
 break;
 case CLOCK_REALTIME_COARSE:
 do_realtime_coarse(ts);
 break;
 case CLOCK_MONOTONIC_COARSE:
 do_monotonic_coarse(ts);
 break;
 default:
goto fallback;
 }
 return 0;
 fallback: ...
}


So at the cost of an unnecessary extra test of the clock parameter,
the thunk is avoided .

I wonder if the whole switch should be changed to an if / else clause ?

Or, I know this might be unorthodox, but might work :
#define _CAT(V1,V2) V1##V2
#define GTOD_CLK_LABEL(CLK) _CAT(_VCG_L_,CLK)
#define  MAX_CLK 16
//^^ ??
 __vdso_clock_gettime(  ... ) { ...
 static const void *clklbl_tab[MAX_CLK]
 ={ [ CLOCK_MONOTONIC ]
  =   &_CLK_LABEL(CLOCK_MONOTONIC) ,
 [ CLOCK_MONOTONIC_RAW ]
  =   &_CLK_LABEL(CLOCK_MONOTONIC_RAW) ,
// and similarly for all clocks handled ...
};

   goto clklbl_tab[ clock & 0xf ] ;

   GTOD_CLK_LABEL(CLOCK_MONOTONIC) :
if ( do_monotonic(ts) == VCLOCK_NONE )
  goto fallback ;

   GTOD_CLK_LABEL(CLOCK_MONOTONIC_RAW) :
if ( do_monotonic_raw(ts) == VCLOCK_NONE )
  goto fallback ;

 ... // similarly for all clocks

fallback:
 return vdso_fallback_gettime(clock,ts);
}


If a restructuring like that might be acceptable (with correct tab-based
formatting) , and the VDSO can have such a table in its .BSS ,  I think it
would avoid the thunk, and have the advantage of
precomputing the jump table at compile-time, and would not require any
indirect branches, I think.

Any thoughts ?

Thanks & Best regards,
Jason




  ;

 G

Re: [PATCH v4.16-rc5 2/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

[Jason Vas Dias]

On 18/03/2018, Jason Vas Dias  wrote:
(should have CC'ed to list, sorry)
> On 17/03/2018, Andi Kleen  wrote:
>>
>> That's quite a mischaracterization of the issue. gcc works as intended,
>> but the kernel did not correctly supply a indirect call retpoline thunk
>> to the vdso, and it just happened to work by accident with the old
>> vdso.
>>
>>>
>>>  The automated test builds should now succeed with this patch.
>>
>> How about just adding the thunk function to the vdso object instead of
>> this cheap hack?
>>
>> The other option would be to build vdso with inline thunks.
>>
>> But just disabling is completely the wrong action.
>>
>> -Andi
>>
>
> Aha! Thanks for the clarification , Andi!
>
> I will do so and resend the 2nd patch.
>
> But is everyone agreed we should accept any slowdown for the timer
> functions ? I personally don't think it is a good idea, but I will
> regenerate the patch with the thunk function and without
> the Makefile change.
>
> Thanks & Best Regards,
> Jason
>


I am wondering if it is not better to avoid the thunk being generated
and remove the Makefile patch ?

I know that changing the switch in __vdso_clock_gettime() like
this avoids the thunk :

   switch(clock) {
   case CLOCK_MONOTONIC:
if (do_monotonic(ts) == VCLOCK_NONE)
goto fallback;
break;
default:
switch (clock) {
case CLOCK_REALTIME:
if (do_realtime(ts) == VCLOCK_NONE)
   goto fallback;
break;
 case CLOCK_MONOTONIC_RAW:
 if (do_monotonic_raw(ts) == VCLOCK_NONE)
   goto fallback;
 break;
 case CLOCK_REALTIME_COARSE:
 do_realtime_coarse(ts);
 break;
 case CLOCK_MONOTONIC_COARSE:
 do_monotonic_coarse(ts);
 break;
 default:
goto fallback;
 }
 return 0;
 fallback: ...
}


So at the cost of an unnecessary extra test of the clock parameter,
the thunk is avoided .

I wonder if the whole switch should be changed to an if / else clause ?

Or, I know this might be unorthodox, but might work :
#define _CAT(V1,V2) V1##V2
#define GTOD_CLK_LABEL(CLK) _CAT(_VCG_L_,CLK)
#define  MAX_CLK 16
//^^ ??
 __vdso_clock_gettime(  ... ) { ...
 static const void *clklbl_tab[MAX_CLK]
 ={ [ CLOCK_MONOTONIC ]
  =   &_CLK_LABEL(CLOCK_MONOTONIC) ,
 [ CLOCK_MONOTONIC_RAW ]
  =   &_CLK_LABEL(CLOCK_MONOTONIC_RAW) ,
// and similarly for all clocks handled ...
};

   goto clklbl_tab[ clock & 0xf ] ;

   GTOD_CLK_LABEL(CLOCK_MONOTONIC) :
if ( do_monotonic(ts) == VCLOCK_NONE )
  goto fallback ;

   GTOD_CLK_LABEL(CLOCK_MONOTONIC_RAW) :
if ( do_monotonic_raw(ts) == VCLOCK_NONE )
  goto fallback ;

 ... // similarly for all clocks

fallback:
 return vdso_fallback_gettime(clock,ts);
}


If a restructuring like that might be acceptable (with correct tab-based
formatting) , and the VDSO can have such a table in its .BSS ,  I think it
would avoid the thunk, and have the advantage of
precomputing the jump table at compile-time, and would not require any
indirect branches, I think.

Any thoughts ?

Thanks & Best regards,
Jason




  ;

 G

[PATCH V2 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range

[Anson Huang]

Update sw1a/vldo4's voltage range according to pfuze3000
datasheet(Rev.9.0) from:

https://www.nxp.com/docs/en/data-sheet/PF3000.pdf

Signed-off-by: Anson Huang 
Signed-off-by: Robin Gong 
---
no changes since V1.
 arch/arm/boot/dts/imx6sx-udoo-neo.dtsi  | 2 +-
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 4 ++--
 arch/arm/boot/dts/imx7d-nitrogen7.dts   | 2 +-
 arch/arm/boot/dts/imx7d-sdb.dts | 6 +++---
 arch/arm/boot/dts/imx7s-warp.dts| 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi 
b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
index 53b3eac..1de0a0f 100644
--- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -142,7 +142,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts 
b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index ae45af1..3781cb8 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -87,7 +87,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
@@ -284,4 +284,4 @@
MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG 
PWREN */
>;
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/imx7d-nitrogen7.dts 
b/arch/arm/boot/dts/imx7d-nitrogen7.dts
index 2b05898..2802bcf 100644
--- a/arch/arm/boot/dts/imx7d-nitrogen7.dts
+++ b/arch/arm/boot/dts/imx7d-nitrogen7.dts
@@ -188,7 +188,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index a7a5dc7..ba60457 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -248,7 +248,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
@@ -324,8 +324,8 @@
};
 
vgen6_reg: vldo4 {
-   regulator-min-microvolt = <280>;
-   regulator-max-microvolt = <280>;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
regulator-always-on;
};
};
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 9bdf121..0e0cbcf 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -129,7 +129,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
-- 
2.7.4

[PATCH V2 2/2] regulator: pfuze100: update voltage setting for pfuze3000 sw1a

[Anson Huang]

pfuze3000 datasheet(Rev.9.0) from:

https://www.nxp.com/docs/en/data-sheet/PF3000.pdf

updates sw1a's voltage range, the settings for 1.450V and 1.475V
are replaced with 1.8V and 3.3V:

5b'0 1.450 (SW1B), 1.8 (SW1A/SW1AB)
5b'1 1.475 (SW1B), 3.3 (SW1A/SW1AB)

the voltage calculation using steps is NOT available for sw1a now,
use voltage table instead.

Signed-off-by: Anson Huang 
Signed-off-by: Robin Gong 
---
changes since V1:
update the latest datasheet link and add version into commit message.
 drivers/regulator/pfuze100-regulator.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/pfuze100-regulator.c 
b/drivers/regulator/pfuze100-regulator.c
index 63922a2..680f076 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -86,6 +86,13 @@ static const int pfuze100_coin[] = {
250, 270, 280, 290, 300, 310, 320, 330,
 };
 
+static const int pfuze3000_sw1a[] = {
+   70, 725000, 75, 775000, 80, 825000, 85, 875000,
+   90, 925000, 95, 975000, 100, 1025000, 105, 1075000,
+   110, 1125000, 115, 1175000, 120, 1225000, 125, 1275000,
+   130, 1325000, 135, 1375000, 140, 1425000, 180, 330,
+};
+
 static const int pfuze3000_sw2lo[] = {
150, 155, 160, 165, 170, 175, 180, 185,
 };
@@ -343,7 +350,7 @@ static struct pfuze_regulator pfuze200_regulators[] = {
 };
 
 static struct pfuze_regulator pfuze3000_regulators[] = {
-   PFUZE100_SW_REG(PFUZE3000, SW1A, PFUZE100_SW1ABVOL, 70, 1475000, 
25000),
+   PFUZE100_SWB_REG(PFUZE3000, SW1A, PFUZE100_SW1ABVOL, 0x1f, 
pfuze3000_sw1a),
PFUZE100_SW_REG(PFUZE3000, SW1B, PFUZE100_SW1CVOL, 70, 1475000, 
25000),
PFUZE100_SWB_REG(PFUZE3000, SW2, PFUZE100_SW2VOL, 0x7, pfuze3000_sw2lo),
PFUZE3000_SW3_REG(PFUZE3000, SW3, PFUZE100_SW3AVOL, 90, 165, 
5),
-- 
2.7.4

[PATCH V2 2/2] regulator: pfuze100: update voltage setting for pfuze3000 sw1a

[Anson Huang]

pfuze3000 datasheet(Rev.9.0) from:

https://www.nxp.com/docs/en/data-sheet/PF3000.pdf

updates sw1a's voltage range, the settings for 1.450V and 1.475V
are replaced with 1.8V and 3.3V:

5b'0 1.450 (SW1B), 1.8 (SW1A/SW1AB)
5b'1 1.475 (SW1B), 3.3 (SW1A/SW1AB)

the voltage calculation using steps is NOT available for sw1a now,
use voltage table instead.

Signed-off-by: Anson Huang 
Signed-off-by: Robin Gong 
---
changes since V1:
update the latest datasheet link and add version into commit message.
 drivers/regulator/pfuze100-regulator.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/pfuze100-regulator.c 
b/drivers/regulator/pfuze100-regulator.c
index 63922a2..680f076 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -86,6 +86,13 @@ static const int pfuze100_coin[] = {
250, 270, 280, 290, 300, 310, 320, 330,
 };
 
+static const int pfuze3000_sw1a[] = {
+   70, 725000, 75, 775000, 80, 825000, 85, 875000,
+   90, 925000, 95, 975000, 100, 1025000, 105, 1075000,
+   110, 1125000, 115, 1175000, 120, 1225000, 125, 1275000,
+   130, 1325000, 135, 1375000, 140, 1425000, 180, 330,
+};
+
 static const int pfuze3000_sw2lo[] = {
150, 155, 160, 165, 170, 175, 180, 185,
 };
@@ -343,7 +350,7 @@ static struct pfuze_regulator pfuze200_regulators[] = {
 };
 
 static struct pfuze_regulator pfuze3000_regulators[] = {
-   PFUZE100_SW_REG(PFUZE3000, SW1A, PFUZE100_SW1ABVOL, 70, 1475000, 
25000),
+   PFUZE100_SWB_REG(PFUZE3000, SW1A, PFUZE100_SW1ABVOL, 0x1f, 
pfuze3000_sw1a),
PFUZE100_SW_REG(PFUZE3000, SW1B, PFUZE100_SW1CVOL, 70, 1475000, 
25000),
PFUZE100_SWB_REG(PFUZE3000, SW2, PFUZE100_SW2VOL, 0x7, pfuze3000_sw2lo),
PFUZE3000_SW3_REG(PFUZE3000, SW3, PFUZE100_SW3AVOL, 90, 165, 
5),
-- 
2.7.4

[PATCH V2 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range

[Anson Huang]

Update sw1a/vldo4's voltage range according to pfuze3000
datasheet(Rev.9.0) from:

https://www.nxp.com/docs/en/data-sheet/PF3000.pdf

Signed-off-by: Anson Huang 
Signed-off-by: Robin Gong 
---
no changes since V1.
 arch/arm/boot/dts/imx6sx-udoo-neo.dtsi  | 2 +-
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 4 ++--
 arch/arm/boot/dts/imx7d-nitrogen7.dts   | 2 +-
 arch/arm/boot/dts/imx7d-sdb.dts | 6 +++---
 arch/arm/boot/dts/imx7s-warp.dts| 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi 
b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
index 53b3eac..1de0a0f 100644
--- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
+++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
@@ -142,7 +142,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts 
b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index ae45af1..3781cb8 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -87,7 +87,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
@@ -284,4 +284,4 @@
MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG 
PWREN */
>;
};
-};
\ No newline at end of file
+};
diff --git a/arch/arm/boot/dts/imx7d-nitrogen7.dts 
b/arch/arm/boot/dts/imx7d-nitrogen7.dts
index 2b05898..2802bcf 100644
--- a/arch/arm/boot/dts/imx7d-nitrogen7.dts
+++ b/arch/arm/boot/dts/imx7d-nitrogen7.dts
@@ -188,7 +188,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index a7a5dc7..ba60457 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -248,7 +248,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
@@ -324,8 +324,8 @@
};
 
vgen6_reg: vldo4 {
-   regulator-min-microvolt = <280>;
-   regulator-max-microvolt = <280>;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
regulator-always-on;
};
};
diff --git a/arch/arm/boot/dts/imx7s-warp.dts b/arch/arm/boot/dts/imx7s-warp.dts
index 9bdf121..0e0cbcf 100644
--- a/arch/arm/boot/dts/imx7s-warp.dts
+++ b/arch/arm/boot/dts/imx7s-warp.dts
@@ -129,7 +129,7 @@
regulators {
sw1a_reg: sw1a {
regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <1475000>;
+   regulator-max-microvolt = <330>;
regulator-boot-on;
regulator-always-on;
regulator-ramp-delay = <6250>;
-- 
2.7.4

[PATCH 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

[Anson Huang]

On i.MX6SX SabreAuto board, there is external 24MHz clock
source for analog clock2, add this clock source to clock tree.

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx6sx-sabreauto.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts 
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 72da5ac..83f7cac 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -18,6 +18,14 @@
reg = <0x8000 0x8000>;
};
 
+   clocks {
+   codec_osc: anaclk2 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <24576000>;
+   };
+   };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
-- 
2.7.4

[PATCH 1/2] clk: imx6sx: add missing lvds2 clock to the clock tree

[Anson Huang]

i.MX6SX has lvds2 (analog clock2), an I/O clock like lvds1.
And this lvds2, along with lvds1, can be used to provide
external clock source to the internal pll, such as pll4_audio
and pll5_video.

This patch mainly adds the lvds2 to the clock tree and fix its
relationship with pll accordingly.

Signed-off-by: Anson Huang 
Signed-off-by: Shengjiu Wang 
---
 drivers/clk/imx/clk-imx6sx.c | 6 +-
 include/dt-bindings/clock/imx6sx-clock.h | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index e6d389e..d180797 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -80,7 +80,7 @@ static const char *lvds_sels[]= {
"arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy", 
"pll5_video_div",
"dummy", "dummy", "pcie_ref_125m", "dummy", "usbphy1", "usbphy2",
 };
-static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", };
+static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", "lvds2_in", 
"dummy", };
 static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src", };
 static const char *pll2_bypass_sels[] = { "pll2", "pll2_bypass_src", };
 static const char *pll3_bypass_sels[] = { "pll3", "pll3_bypass_src", };
@@ -160,6 +160,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 
/* Clock source from external clock via CLK1 PAD */
clks[IMX6SX_CLK_ANACLK1] = imx_obtain_fixed_clock("anaclk1", 0);
+   clks[IMX6SX_CLK_ANACLK2] = imx_obtain_fixed_clock("anaclk2", 0);
 
np = of_find_compatible_node(NULL, NULL, "fsl,imx6sx-anatop");
base = of_iomap(np, 0);
@@ -228,7 +229,9 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_PCIE_REF_125M] = imx_clk_gate("pcie_ref_125m", 
"pcie_ref", base + 0xe0, 19);
 
clks[IMX6SX_CLK_LVDS1_OUT] = imx_clk_gate_exclusive("lvds1_out", 
"lvds1_sel", base + 0x160, 10, BIT(12));
+   clks[IMX6SX_CLK_LVDS2_OUT] = imx_clk_gate_exclusive("lvds2_out", 
"lvds2_sel", base + 0x160, 11, BIT(13));
clks[IMX6SX_CLK_LVDS1_IN]  = imx_clk_gate_exclusive("lvds1_in",  
"anaclk1",   base + 0x160, 12, BIT(10));
+   clks[IMX6SX_CLK_LVDS2_IN]  = imx_clk_gate_exclusive("lvds2_in",  
"anaclk2",   base + 0x160, 13, BIT(11));
 
clks[IMX6SX_CLK_ENET_REF] = clk_register_divider_table(NULL, 
"enet_ref", "pll6_enet", 0,
base + 0xe0, 0, 2, 0, clk_enet_ref_table,
@@ -270,6 +273,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 
/*name
reg   shift   width   parent_names   num_parents */
clks[IMX6SX_CLK_LVDS1_SEL]  = imx_clk_mux("lvds1_sel",
base + 0x160, 0,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
+   clks[IMX6SX_CLK_LVDS2_SEL]  = imx_clk_mux("lvds2_sel",
base + 0x160, 5,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
 
np = ccm_node;
base = of_iomap(np, 0);
diff --git a/include/dt-bindings/clock/imx6sx-clock.h 
b/include/dt-bindings/clock/imx6sx-clock.h
index 36f0324..cd2d6c5 100644
--- a/include/dt-bindings/clock/imx6sx-clock.h
+++ b/include/dt-bindings/clock/imx6sx-clock.h
@@ -275,6 +275,10 @@
 #define IMX6SX_PLL6_BYPASS 262
 #define IMX6SX_PLL7_BYPASS 263
 #define IMX6SX_CLK_SPDIF_GCLK  264
-#define IMX6SX_CLK_CLK_END 265
+#define IMX6SX_CLK_LVDS2_SEL   265
+#define IMX6SX_CLK_LVDS2_OUT   266
+#define IMX6SX_CLK_LVDS2_IN267
+#define IMX6SX_CLK_ANACLK2 268
+#define IMX6SX_CLK_CLK_END 269
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6SX_H */
-- 
2.7.4

[PATCH 2/2] ARM: dts: imx6sx-sabreauto: add external 24MHz clock source

[Anson Huang]

On i.MX6SX SabreAuto board, there is external 24MHz clock
source for analog clock2, add this clock source to clock tree.

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx6sx-sabreauto.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts 
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index 72da5ac..83f7cac 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -18,6 +18,14 @@
reg = <0x8000 0x8000>;
};
 
+   clocks {
+   codec_osc: anaclk2 {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <24576000>;
+   };
+   };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
-- 
2.7.4

[PATCH 1/2] clk: imx6sx: add missing lvds2 clock to the clock tree

[Anson Huang]

i.MX6SX has lvds2 (analog clock2), an I/O clock like lvds1.
And this lvds2, along with lvds1, can be used to provide
external clock source to the internal pll, such as pll4_audio
and pll5_video.

This patch mainly adds the lvds2 to the clock tree and fix its
relationship with pll accordingly.

Signed-off-by: Anson Huang 
Signed-off-by: Shengjiu Wang 
---
 drivers/clk/imx/clk-imx6sx.c | 6 +-
 include/dt-bindings/clock/imx6sx-clock.h | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index e6d389e..d180797 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -80,7 +80,7 @@ static const char *lvds_sels[]= {
"arm", "pll1_sys", "dummy", "dummy", "dummy", "dummy", "dummy", 
"pll5_video_div",
"dummy", "dummy", "pcie_ref_125m", "dummy", "usbphy1", "usbphy2",
 };
-static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", };
+static const char *pll_bypass_src_sels[] = { "osc", "lvds1_in", "lvds2_in", 
"dummy", };
 static const char *pll1_bypass_sels[] = { "pll1", "pll1_bypass_src", };
 static const char *pll2_bypass_sels[] = { "pll2", "pll2_bypass_src", };
 static const char *pll3_bypass_sels[] = { "pll3", "pll3_bypass_src", };
@@ -160,6 +160,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 
/* Clock source from external clock via CLK1 PAD */
clks[IMX6SX_CLK_ANACLK1] = imx_obtain_fixed_clock("anaclk1", 0);
+   clks[IMX6SX_CLK_ANACLK2] = imx_obtain_fixed_clock("anaclk2", 0);
 
np = of_find_compatible_node(NULL, NULL, "fsl,imx6sx-anatop");
base = of_iomap(np, 0);
@@ -228,7 +229,9 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_PCIE_REF_125M] = imx_clk_gate("pcie_ref_125m", 
"pcie_ref", base + 0xe0, 19);
 
clks[IMX6SX_CLK_LVDS1_OUT] = imx_clk_gate_exclusive("lvds1_out", 
"lvds1_sel", base + 0x160, 10, BIT(12));
+   clks[IMX6SX_CLK_LVDS2_OUT] = imx_clk_gate_exclusive("lvds2_out", 
"lvds2_sel", base + 0x160, 11, BIT(13));
clks[IMX6SX_CLK_LVDS1_IN]  = imx_clk_gate_exclusive("lvds1_in",  
"anaclk1",   base + 0x160, 12, BIT(10));
+   clks[IMX6SX_CLK_LVDS2_IN]  = imx_clk_gate_exclusive("lvds2_in",  
"anaclk2",   base + 0x160, 13, BIT(11));
 
clks[IMX6SX_CLK_ENET_REF] = clk_register_divider_table(NULL, 
"enet_ref", "pll6_enet", 0,
base + 0xe0, 0, 2, 0, clk_enet_ref_table,
@@ -270,6 +273,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 
/*name
reg   shift   width   parent_names   num_parents */
clks[IMX6SX_CLK_LVDS1_SEL]  = imx_clk_mux("lvds1_sel",
base + 0x160, 0,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
+   clks[IMX6SX_CLK_LVDS2_SEL]  = imx_clk_mux("lvds2_sel",
base + 0x160, 5,  5,  lvds_sels, ARRAY_SIZE(lvds_sels));
 
np = ccm_node;
base = of_iomap(np, 0);
diff --git a/include/dt-bindings/clock/imx6sx-clock.h 
b/include/dt-bindings/clock/imx6sx-clock.h
index 36f0324..cd2d6c5 100644
--- a/include/dt-bindings/clock/imx6sx-clock.h
+++ b/include/dt-bindings/clock/imx6sx-clock.h
@@ -275,6 +275,10 @@
 #define IMX6SX_PLL6_BYPASS 262
 #define IMX6SX_PLL7_BYPASS 263
 #define IMX6SX_CLK_SPDIF_GCLK  264
-#define IMX6SX_CLK_CLK_END 265
+#define IMX6SX_CLK_LVDS2_SEL   265
+#define IMX6SX_CLK_LVDS2_OUT   266
+#define IMX6SX_CLK_LVDS2_IN267
+#define IMX6SX_CLK_ANACLK2 268
+#define IMX6SX_CLK_CLK_END 269
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6SX_H */
-- 
2.7.4

Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Masahiro Yamada]

2018-02-08 4:32 GMT+09:00 Wolfram Sang :
> On Thu, Jan 18, 2018 at 10:58:36AM +0900, Masahiro Yamada wrote:
>> 2018-01-18 1:28 GMT+09:00 Masahiro Yamada :
>> > This property is equivalent to "disable-wp" defined in
>> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt
>>
>> This is mistake.
>>
>> "disable-wp" is defined in
>>
>> Documentation/devicetree/bindings/mmc/mmc.txt
>
> With that fixed:
>
> Reviewed-by: Wolfram Sang 
>

BTW, the subject of the applied version is wrong.

In my original post:
https://patchwork.kernel.org/patch/10170007/
"toshiba,mmc-wrprotect-disable"
No space after the vendor prefix.


But, applied commit (788778b0d21a6d5cd5)
I see a space, like
"toshiba, mmc-wrprotect-disable"


I think this is a bug of patchwork.


I have seen various bugs that break
the patch format.

I filed some bug reports for patchwork,
but not sure what happened.

-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 11/16] mmc: tmio: deprecate "toshiba,mmc-wrprotect-disable" DT property

[Masahiro Yamada]

2018-02-08 4:32 GMT+09:00 Wolfram Sang :
> On Thu, Jan 18, 2018 at 10:58:36AM +0900, Masahiro Yamada wrote:
>> 2018-01-18 1:28 GMT+09:00 Masahiro Yamada :
>> > This property is equivalent to "disable-wp" defined in
>> > Documentation/devicetree/bindings/mmc/tmio_mmc.txt
>>
>> This is mistake.
>>
>> "disable-wp" is defined in
>>
>> Documentation/devicetree/bindings/mmc/mmc.txt
>
> With that fixed:
>
> Reviewed-by: Wolfram Sang 
>

BTW, the subject of the applied version is wrong.

In my original post:
https://patchwork.kernel.org/patch/10170007/
"toshiba,mmc-wrprotect-disable"
No space after the vendor prefix.


But, applied commit (788778b0d21a6d5cd5)
I see a space, like
"toshiba, mmc-wrprotect-disable"


I think this is a bug of patchwork.


I have seen various bugs that break
the patch format.

I filed some bug reports for patchwork,
but not sure what happened.

-- 
Best Regards
Masahiro Yamada

RE: [PATCH 2/2] regulator: pfuze100: update voltage setting for pfuze3000 sw1a

[Anson Huang]

Anson Huang
Best Regards!


> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Sunday, March 18, 2018 2:27 AM
> To: Stefan Wahren 
> Cc: Rob Herring ; Fabio Estevam
> ; Mark Rutland ; Robin
> Gong ; Russell King - ARM Linux
> ; Anson Huang ; Liam
> Girdwood ; Shawn Guo ;
> Sascha Hauer ; Mark Brown ;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; dl-linux-imx ; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> ; linux-kernel
> 
> Subject: Re: [PATCH 2/2] regulator: pfuze100: update voltage setting for
> pfuze3000 sw1a
> 
> Hi Stefan,
> 
> On Sat, Mar 17, 2018 at 9:35 AM, Stefan Wahren 
> wrote:
> > Hi Anson,
> >
> >> Anson Huang  hat am 17. März 2018 um 07:57
> geschrieben:
> >>
> >>
> >> Latest pfuze3000 datasheet from:
> >>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcache.fr
> eescale.com%2Ffiles%2Fanalog%2Fdoc%2Fdata_sheet%2FPF3000.pdf%3Ffsrch
> %3D1%26sr%3D1%26pageNum%3D1=02%7C01%7CAnson.Huang%40nxp
> .com%7Cf6e1374a196741efe49b08d58c34bbab%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C1%7C636569080479216580=DZQFb2hHbYqXjduHC0
> 1z%2FiAT4xvztN4Gy85S89mULwo%3D=0
> >
> > this link goes to Rev. 7.0, 9/2016, which isn't the latest one.
> >
> > I guess Rev. 9.0, 8/2017 is the latest.
> 
> You are right. This is the link to the latest datasheet:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.n
> xp.com%2Fdocs%2Fen%2Fdata-sheet%2FPF3000.pdf=02%7C01%7CAnson
> .Huang%40nxp.com%7Cf6e1374a196741efe49b08d58c34bbab%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C1%7C636569080479216580=WIQYD
> 7WDn0%2FTl4BzM7oJdSuwK31Z64TfekeBAkou9XQ%3D=0

Yes, thank you for the reminder, I will update the commit message and the link 
in V2.
 
Anson.

RE: [PATCH 2/2] regulator: pfuze100: update voltage setting for pfuze3000 sw1a

[Anson Huang]

Anson Huang
Best Regards!


> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Sunday, March 18, 2018 2:27 AM
> To: Stefan Wahren 
> Cc: Rob Herring ; Fabio Estevam
> ; Mark Rutland ; Robin
> Gong ; Russell King - ARM Linux
> ; Anson Huang ; Liam
> Girdwood ; Shawn Guo ;
> Sascha Hauer ; Mark Brown ;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; dl-linux-imx ; moderated
> list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
> ; linux-kernel
> 
> Subject: Re: [PATCH 2/2] regulator: pfuze100: update voltage setting for
> pfuze3000 sw1a
> 
> Hi Stefan,
> 
> On Sat, Mar 17, 2018 at 9:35 AM, Stefan Wahren 
> wrote:
> > Hi Anson,
> >
> >> Anson Huang  hat am 17. März 2018 um 07:57
> geschrieben:
> >>
> >>
> >> Latest pfuze3000 datasheet from:
> >>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcache.fr
> eescale.com%2Ffiles%2Fanalog%2Fdoc%2Fdata_sheet%2FPF3000.pdf%3Ffsrch
> %3D1%26sr%3D1%26pageNum%3D1=02%7C01%7CAnson.Huang%40nxp
> .com%7Cf6e1374a196741efe49b08d58c34bbab%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C1%7C636569080479216580=DZQFb2hHbYqXjduHC0
> 1z%2FiAT4xvztN4Gy85S89mULwo%3D=0
> >
> > this link goes to Rev. 7.0, 9/2016, which isn't the latest one.
> >
> > I guess Rev. 9.0, 8/2017 is the latest.
> 
> You are right. This is the link to the latest datasheet:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.n
> xp.com%2Fdocs%2Fen%2Fdata-sheet%2FPF3000.pdf=02%7C01%7CAnson
> .Huang%40nxp.com%7Cf6e1374a196741efe49b08d58c34bbab%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C1%7C636569080479216580=WIQYD
> 7WDn0%2FTl4BzM7oJdSuwK31Z64TfekeBAkou9XQ%3D=0

Yes, thank you for the reminder, I will update the commit message and the link 
in V2.
 
Anson.

RE: [PATCH 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range

[Anson Huang]

Anson Huang
Best Regards!


> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Saturday, March 17, 2018 10:53 PM
> To: Anson Huang 
> Cc: Robin Gong ; Shawn Guo ;
> Sascha Hauer ; Fabio Estevam
> ; Rob Herring ; Mark Rutland
> ; Russell King - ARM Linux ;
> Liam Girdwood ; Mark Brown ;
> dl-linux-imx ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE ; open list:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; linux-kernel 
> Subject: Re: [PATCH 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range
> 
> Hi Anson,
> 
> On Sat, Mar 17, 2018 at 3:57 AM, Anson Huang 
> wrote:
> > Update sw1a/vldo4's voltage range according to latest pfuze3000
> > datasheet from:
> >
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcach
> >
> e.freescale.com%2Ffiles%2Fanalog%2Fdoc%2Fdata_sheet%2FPF3000.pdf%3Ffsr
> >
> ch%3D1%26sr%3D1%26pageNum%3D1=02%7C01%7CAnson.Huang%40n
> xp.com%7Cc
> >
> 9614ae26f9443c2d0ae08d58c16cd8a%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0
> > %7C1%7C636568951923456037=OeM%2B3xPNlm9OETpZcrvG65LjH%
> 2Fp4CRZvyD
> > HT819kuPk%3D=0
> >
> > Signed-off-by: Anson Huang 
> > Signed-off-by: Robin Gong 
> > ---
> >  arch/arm/boot/dts/imx6sx-udoo-neo.dtsi  | 2 +-
> > arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 4 ++--
> >  arch/arm/boot/dts/imx7d-nitrogen7.dts   | 2 +-
> >  arch/arm/boot/dts/imx7d-sdb.dts | 6 +++---
> >  arch/arm/boot/dts/imx7s-warp.dts| 2 +-
> >  5 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > index 53b3eac..1de0a0f 100644
> > --- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > +++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > @@ -142,7 +142,7 @@
> > regulators {
> > sw1a_reg: sw1a {
> > regulator-min-microvolt = <70>;
> > -   regulator-max-microvolt = <1475000>;
> > +   regulator-max-microvolt =
> <330>;
> 
> This change does not look like a safe thing to do without carefully checking 
> each
> one of the board schematics.
> 
> Even if the regulator itself is capable of driving a higher voltage, it does 
> not
> mean that the circuitry that consumes such regulator is allowed to receive the
> higher voltages.
 
I thought the max value here means the capability of regulator itself, like the 
internal
anatop LDO regulator VDD_CORE, the max value defined in dtsi is 1.45V, but out 
i.MX6
SoCs can NOT receive to voltage higher than 1.3V.

The default setting of PMIC output is controlled by its OTP and the OTP value 
should
consider the board design, the rest of voltage setting should be taken care by 
device driver.
Here I think the max means PMIC's capability.

Anson.

RE: [PATCH 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range

[Anson Huang]

Anson Huang
Best Regards!


> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Saturday, March 17, 2018 10:53 PM
> To: Anson Huang 
> Cc: Robin Gong ; Shawn Guo ;
> Sascha Hauer ; Fabio Estevam
> ; Rob Herring ; Mark Rutland
> ; Russell King - ARM Linux ;
> Liam Girdwood ; Mark Brown ;
> dl-linux-imx ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE ; open list:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; linux-kernel 
> Subject: Re: [PATCH 1/2] ARM: dts: pfuze3000: update sw1a/vldo4 voltage range
> 
> Hi Anson,
> 
> On Sat, Mar 17, 2018 at 3:57 AM, Anson Huang 
> wrote:
> > Update sw1a/vldo4's voltage range according to latest pfuze3000
> > datasheet from:
> >
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcach
> >
> e.freescale.com%2Ffiles%2Fanalog%2Fdoc%2Fdata_sheet%2FPF3000.pdf%3Ffsr
> >
> ch%3D1%26sr%3D1%26pageNum%3D1=02%7C01%7CAnson.Huang%40n
> xp.com%7Cc
> >
> 9614ae26f9443c2d0ae08d58c16cd8a%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0
> > %7C1%7C636568951923456037=OeM%2B3xPNlm9OETpZcrvG65LjH%
> 2Fp4CRZvyD
> > HT819kuPk%3D=0
> >
> > Signed-off-by: Anson Huang 
> > Signed-off-by: Robin Gong 
> > ---
> >  arch/arm/boot/dts/imx6sx-udoo-neo.dtsi  | 2 +-
> > arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 4 ++--
> >  arch/arm/boot/dts/imx7d-nitrogen7.dts   | 2 +-
> >  arch/arm/boot/dts/imx7d-sdb.dts | 6 +++---
> >  arch/arm/boot/dts/imx7s-warp.dts| 2 +-
> >  5 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > index 53b3eac..1de0a0f 100644
> > --- a/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > +++ b/arch/arm/boot/dts/imx6sx-udoo-neo.dtsi
> > @@ -142,7 +142,7 @@
> > regulators {
> > sw1a_reg: sw1a {
> > regulator-min-microvolt = <70>;
> > -   regulator-max-microvolt = <1475000>;
> > +   regulator-max-microvolt =
> <330>;
> 
> This change does not look like a safe thing to do without carefully checking 
> each
> one of the board schematics.
> 
> Even if the regulator itself is capable of driving a higher voltage, it does 
> not
> mean that the circuitry that consumes such regulator is allowed to receive the
> higher voltages.
 
I thought the max value here means the capability of regulator itself, like the 
internal
anatop LDO regulator VDD_CORE, the max value defined in dtsi is 1.45V, but out 
i.MX6
SoCs can NOT receive to voltage higher than 1.3V.

The default setting of PMIC output is controlled by its OTP and the OTP value 
should
consider the board design, the rest of voltage setting should be taken care by 
device driver.
Here I think the max means PMIC's capability.

Anson.

[PATCH] iommu/mediatek: Fix protect memory setting

[Yong Wu]

In MediaTek's IOMMU design, When a iommu translation fault occurs
(HW can NOT translate the destination address to a valid physical
address), the IOMMU HW output the dirty data into a special memory
to avoid corrupting the main memory, this is called "protect memory".
the register(0x114) for protect memory is a little different between
mt8173 and mt2712.

In the mt8173, bit[30:6] in the register represents [31:7] of the
physical address. In the 4GB mode, the register bit[31] should be 1.
While in the mt2712, the bits don't shift. bit[31:7] in the register
represents [31:7] in the physical address, and bit[1:0] in the
register represents bit[33:32] of the physical address if it has.

Fixes: e6dec9230862 ("iommu/mediatek: Add mt2712 IOMMU support")
Reported-by: Honghui Zhang 
Signed-off-by: Yong Wu 
---
After adding the setting above, the macro will be complex, like:
 #define F_MMU_IVRP_PA_SET(data)({  \
const struct mtk_iommu_data *_data =  data; \
phys_addr_t _pa = data->protect_base;   \
((_data->m4u_plat == M4U_MT8173) ?  \
((_pa >> 1) | (_data->enable_4GB << 31)) :  \
(lower_32_bits(_pa) | (_pa >> 32)));\
})
And this macro is called twice(hw_init and resume).

To avoid adding this complex macro or a new function, I put
it in the code and backup its value in the suspend registers.
---
 drivers/iommu/mtk_iommu.c | 15 ++-
 drivers/iommu/mtk_iommu.h |  1 +
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index f227d73..f2832a1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -60,7 +60,7 @@
(((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
 
 #define REG_MMU_IVRP_PADDR 0x114
-#define F_MMU_IVRP_PA_SET(pa, ext) (((pa) >> 1) | ((!!(ext)) << 
31))
+
 #define REG_MMU_VLD_PA_RNG 0x118
 #define F_MMU_VLD_PA_RNG(EA, SA)   (((EA) << 8) | (SA))
 
@@ -539,8 +539,13 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data 
*data)
F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
 
-   writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
-  data->base + REG_MMU_IVRP_PADDR);
+   if (data->m4u_plat == M4U_MT8173)
+   regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
+   else
+   regval = lower_32_bits(data->protect_base) |
+upper_32_bits(data->protect_base);
+   writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
+
if (data->enable_4GB && data->m4u_plat != M4U_MT8173) {
/*
 * If 4GB mode is enabled, the validate PA range is from
@@ -695,6 +700,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device 
*dev)
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
+   reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
clk_disable_unprepare(data->bclk);
return 0;
 }
@@ -717,8 +723,7 @@ static int __maybe_unused mtk_iommu_resume(struct device 
*dev)
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
-   writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
-  base + REG_MMU_IVRP_PADDR);
+   writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
if (data->m4u_dom)
writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
   base + REG_MMU_PT_BASE_ADDR);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b4451a1..778498b 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -32,6 +32,7 @@ struct mtk_iommu_suspend_reg {
u32 ctrl_reg;
u32 int_control0;
u32 int_main_control;
+   u32 ivrp_paddr;
 };
 
 enum mtk_iommu_plat {
-- 
1.8.1.1.dirty

[PATCH] iommu/mediatek: Fix protect memory setting

[Yong Wu]

In MediaTek's IOMMU design, When a iommu translation fault occurs
(HW can NOT translate the destination address to a valid physical
address), the IOMMU HW output the dirty data into a special memory
to avoid corrupting the main memory, this is called "protect memory".
the register(0x114) for protect memory is a little different between
mt8173 and mt2712.

In the mt8173, bit[30:6] in the register represents [31:7] of the
physical address. In the 4GB mode, the register bit[31] should be 1.
While in the mt2712, the bits don't shift. bit[31:7] in the register
represents [31:7] in the physical address, and bit[1:0] in the
register represents bit[33:32] of the physical address if it has.

Fixes: e6dec9230862 ("iommu/mediatek: Add mt2712 IOMMU support")
Reported-by: Honghui Zhang 
Signed-off-by: Yong Wu 
---
After adding the setting above, the macro will be complex, like:
 #define F_MMU_IVRP_PA_SET(data)({  \
const struct mtk_iommu_data *_data =  data; \
phys_addr_t _pa = data->protect_base;   \
((_data->m4u_plat == M4U_MT8173) ?  \
((_pa >> 1) | (_data->enable_4GB << 31)) :  \
(lower_32_bits(_pa) | (_pa >> 32)));\
})
And this macro is called twice(hw_init and resume).

To avoid adding this complex macro or a new function, I put
it in the code and backup its value in the suspend registers.
---
 drivers/iommu/mtk_iommu.c | 15 ++-
 drivers/iommu/mtk_iommu.h |  1 +
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index f227d73..f2832a1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -60,7 +60,7 @@
(((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
 
 #define REG_MMU_IVRP_PADDR 0x114
-#define F_MMU_IVRP_PA_SET(pa, ext) (((pa) >> 1) | ((!!(ext)) << 
31))
+
 #define REG_MMU_VLD_PA_RNG 0x118
 #define F_MMU_VLD_PA_RNG(EA, SA)   (((EA) << 8) | (SA))
 
@@ -539,8 +539,13 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data 
*data)
F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
 
-   writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
-  data->base + REG_MMU_IVRP_PADDR);
+   if (data->m4u_plat == M4U_MT8173)
+   regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
+   else
+   regval = lower_32_bits(data->protect_base) |
+upper_32_bits(data->protect_base);
+   writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
+
if (data->enable_4GB && data->m4u_plat != M4U_MT8173) {
/*
 * If 4GB mode is enabled, the validate PA range is from
@@ -695,6 +700,7 @@ static int __maybe_unused mtk_iommu_suspend(struct device 
*dev)
reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
+   reg->ivrp_paddr = readl_relaxed(base + REG_MMU_IVRP_PADDR);
clk_disable_unprepare(data->bclk);
return 0;
 }
@@ -717,8 +723,7 @@ static int __maybe_unused mtk_iommu_resume(struct device 
*dev)
writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
-   writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
-  base + REG_MMU_IVRP_PADDR);
+   writel_relaxed(reg->ivrp_paddr, base + REG_MMU_IVRP_PADDR);
if (data->m4u_dom)
writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
   base + REG_MMU_PT_BASE_ADDR);
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index b4451a1..778498b 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -32,6 +32,7 @@ struct mtk_iommu_suspend_reg {
u32 ctrl_reg;
u32 int_control0;
u32 int_main_control;
+   u32 ivrp_paddr;
 };
 
 enum mtk_iommu_plat {
-- 
1.8.1.1.dirty

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

[Dave Hansen]

On 03/17/2018 04:24 PM, Ram Pai wrote:
> So the difference between the two proposals is just the freeing part i.e (b).
> Did I get this right?

Yeah, I think that's the only difference.

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

[Dave Hansen]

On 03/17/2018 04:24 PM, Ram Pai wrote:
> So the difference between the two proposals is just the freeing part i.e (b).
> Did I get this right?

Yeah, I think that's the only difference.

Re: [PATCH v2 net 1/2] vmxnet3: avoid xmit reset due to a race in vmxnet3

[David Miller]

From: Ronak Doshi 
Date: Fri, 16 Mar 2018 14:47:54 -0700

> The field txNumDeferred is used by the driver to keep track of the number
> of packets it has pushed to the emulation. The driver increments it on
> pushing the packet to the emulation and the emulation resets it to 0 at
> the end of the transmit.
> 
> There is a possibility of a race either when (a) ESX is under heavy load or
> (b) workload inside VM is of low packet rate.
> 
> This race results in xmit hangs when network coalescing is disabled. This
> change creates a local copy of txNumDeferred and uses it to perform ring
> arithmetic.
> 
> Reported-by: Noriho Tanaka 
> Signed-off-by: Ronak Doshi 
> Acked-by: Shrikrishna Khare 

Applied.

Re: [PATCH v2 net 2/2] vmxnet3: use correct flag to indicate LRO feature

[David Miller]

From: Ronak Doshi 
Date: Fri, 16 Mar 2018 14:49:19 -0700

> 'Commit 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2
> (fwd)")' introduced a flag "lro" in structure vmxnet3_adapter which is
> used to indicate whether LRO is enabled or not. However, the patch
> did not set the flag and hence it was never exercised.
> 
> So, when LRO is enabled, it resulted in poor TCP performance due to
> delayed acks. This issue is seen with packets which are larger than
> the mss getting a delayed ack rather than an immediate ack, thus
> resulting in high latency.
> 
> This patch removes the lro flag and directly uses device features
> against NETIF_F_LRO to check if lro is enabled.
> 
> Fixes: 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)")
> Reported-by: Rachel Lunnon 
> Signed-off-by: Ronak Doshi 
> Acked-by: Shrikrishna Khare 

Applied.

Re: [PATCH v2 net 1/2] vmxnet3: avoid xmit reset due to a race in vmxnet3

[David Miller]

From: Ronak Doshi 
Date: Fri, 16 Mar 2018 14:47:54 -0700

> The field txNumDeferred is used by the driver to keep track of the number
> of packets it has pushed to the emulation. The driver increments it on
> pushing the packet to the emulation and the emulation resets it to 0 at
> the end of the transmit.
> 
> There is a possibility of a race either when (a) ESX is under heavy load or
> (b) workload inside VM is of low packet rate.
> 
> This race results in xmit hangs when network coalescing is disabled. This
> change creates a local copy of txNumDeferred and uses it to perform ring
> arithmetic.
> 
> Reported-by: Noriho Tanaka 
> Signed-off-by: Ronak Doshi 
> Acked-by: Shrikrishna Khare 

Applied.

Re: [PATCH v2 net 2/2] vmxnet3: use correct flag to indicate LRO feature

[David Miller]

From: Ronak Doshi 
Date: Fri, 16 Mar 2018 14:49:19 -0700

> 'Commit 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2
> (fwd)")' introduced a flag "lro" in structure vmxnet3_adapter which is
> used to indicate whether LRO is enabled or not. However, the patch
> did not set the flag and hence it was never exercised.
> 
> So, when LRO is enabled, it resulted in poor TCP performance due to
> delayed acks. This issue is seen with packets which are larger than
> the mss getting a delayed ack rather than an immediate ack, thus
> resulting in high latency.
> 
> This patch removes the lro flag and directly uses device features
> against NETIF_F_LRO to check if lro is enabled.
> 
> Fixes: 45dac1d6ea04 ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)")
> Reported-by: Rachel Lunnon 
> Signed-off-by: Ronak Doshi 
> Acked-by: Shrikrishna Khare 

Applied.

Re: [PATCH v4 3/8] doc: Add doc for the Ingenic TCU hardware

[Randy Dunlap]

On 03/17/2018 04:28 PM, Paul Cercueil wrote:
> Add a documentation file about the Timer/Counter Unit (TCU)
> present in the Ingenic JZ47xx SoCs.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  Documentation/mips/00-INDEX|  3 +++
>  Documentation/mips/ingenic-tcu.txt | 50 
> ++
>  2 files changed, 53 insertions(+)
>  create mode 100644 Documentation/mips/ingenic-tcu.txt
> 
>  v4: New patch in this series

> diff --git a/Documentation/mips/ingenic-tcu.txt 
> b/Documentation/mips/ingenic-tcu.txt
> new file mode 100644
> index ..2508e5793da8
> --- /dev/null
> +++ b/Documentation/mips/ingenic-tcu.txt
> @@ -0,0 +1,50 @@
> +Ingenic JZ47xx SoCs Timer/Counter Unit hardware
> +---
> +
> +The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
> +hardware block. It features eight channels, that can be used as counters,

drop comma . ^

> +timers, or PWM.
> +
> +- JZ4770 introduced a separate channel, called Operating System Timer (OST).
> +  It is a 64-bit programmable timer.
> +
> +- Each one of the eight channels has its own clock, which can be reparented
> +  to three different clocks (pclk, ext, rtc), gated, and reclocked, through
> +  their TCSR register.
> +  * The watchdog and OST hardware blocks also feature a TCSR register with
> + the same format in their register space.
> +  * The TCU registers used to gate/ungate can also gate/ungate the watchdog
> + and OST clocks.
> +
> +- On SoCs >= JZ4770, there are two different modes:
> +  * Channels 0, 3-7 operate in TCU1 mode: they cannot work in sleep mode,
> + but are easier to operate.
> +  * Channels 1-2 operate in TCU2 mode: they can work in sleep mode, but
> + the operation is a bit more complicated than with TCU1 channels.
> +
> +- Each channel can generate an interrupt. Some channels share an interrupt   
> +  line, some don't, and this changes between SoC versions:
> +  * on JZ4740, timer 0 and timer 1 have their own interrupt line; others 
> share
> + one interrupt line.
> +  * on JZ4770 and JZ4780, timer 5 has its own interrupt; timers 0-4 and 6-7 
> all
> + use one interrupt line; the OST uses the last interrupt.

"The OST uses the last interrupt." is not clear to someone who doesn't know
about this hardware. (I can read it several ways.)

Does it mean that the 4770 and 4780 have 3 interrupt lines used like so?

- timer 5 uses one interrupt line
- timers 0-4 and 6-7 use a second interrupt line
- the OST uses a third interrupt line


thanks,
-- 
~Randy

Re: [PATCH v4 3/8] doc: Add doc for the Ingenic TCU hardware

[Randy Dunlap]

On 03/17/2018 04:28 PM, Paul Cercueil wrote:
> Add a documentation file about the Timer/Counter Unit (TCU)
> present in the Ingenic JZ47xx SoCs.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  Documentation/mips/00-INDEX|  3 +++
>  Documentation/mips/ingenic-tcu.txt | 50 
> ++
>  2 files changed, 53 insertions(+)
>  create mode 100644 Documentation/mips/ingenic-tcu.txt
> 
>  v4: New patch in this series

> diff --git a/Documentation/mips/ingenic-tcu.txt 
> b/Documentation/mips/ingenic-tcu.txt
> new file mode 100644
> index ..2508e5793da8
> --- /dev/null
> +++ b/Documentation/mips/ingenic-tcu.txt
> @@ -0,0 +1,50 @@
> +Ingenic JZ47xx SoCs Timer/Counter Unit hardware
> +---
> +
> +The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
> +hardware block. It features eight channels, that can be used as counters,

drop comma . ^

> +timers, or PWM.
> +
> +- JZ4770 introduced a separate channel, called Operating System Timer (OST).
> +  It is a 64-bit programmable timer.
> +
> +- Each one of the eight channels has its own clock, which can be reparented
> +  to three different clocks (pclk, ext, rtc), gated, and reclocked, through
> +  their TCSR register.
> +  * The watchdog and OST hardware blocks also feature a TCSR register with
> + the same format in their register space.
> +  * The TCU registers used to gate/ungate can also gate/ungate the watchdog
> + and OST clocks.
> +
> +- On SoCs >= JZ4770, there are two different modes:
> +  * Channels 0, 3-7 operate in TCU1 mode: they cannot work in sleep mode,
> + but are easier to operate.
> +  * Channels 1-2 operate in TCU2 mode: they can work in sleep mode, but
> + the operation is a bit more complicated than with TCU1 channels.
> +
> +- Each channel can generate an interrupt. Some channels share an interrupt   
> +  line, some don't, and this changes between SoC versions:
> +  * on JZ4740, timer 0 and timer 1 have their own interrupt line; others 
> share
> + one interrupt line.
> +  * on JZ4770 and JZ4780, timer 5 has its own interrupt; timers 0-4 and 6-7 
> all
> + use one interrupt line; the OST uses the last interrupt.

"The OST uses the last interrupt." is not clear to someone who doesn't know
about this hardware. (I can read it several ways.)

Does it mean that the 4770 and 4780 have 3 interrupt lines used like so?

- timer 5 uses one interrupt line
- timers 0-4 and 6-7 use a second interrupt line
- the OST uses a third interrupt line


thanks,
-- 
~Randy

Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

[David Miller]

From: Grygorii Strashko 
Date: Thu, 15 Mar 2018 15:15:50 -0500

> In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host
> port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in
> CPSW_CONTROL register. VLAN header encapsulation word has following format:
> 
>  HDR_PKT_Priority bits 29-31 - Header Packet VLAN prio (Highest prio: 7)
>  HDR_PKT_CFIbits 28 - Header Packet VLAN CFI bit.
>  HDR_PKT_Vidbits 27-16 - Header Packet VLAN ID
>  PKT_Type bits 8-9 - Packet Type. Indicates whether the packet is
>   VLAN-tagged, priority-tagged, or non-tagged.
>   00: VLAN-tagged packet
>   01: Reserved
>   10: Priority-tagged packet
>   11: Non-tagged packet
> 
> This feature can be used to implement TX VLAN offload in case of
> VLAN-tagged packets and to insert VLAN tag in case Non-tagged packet was
> received on port with PVID set. As per documentation, CPSW never modifies
> packet data on Host egress (RX) and as result, without this feature
> enabled, Host port will not be able to receive properly packets which
> entered switch non-tagged through external Port with PVID set (when
> non-tagged packet forwarded from external Port with PVID set to another
> external Port - packet will be VLAN tagged properly).
> 
> Implementation details:
> - on RX driver will check CPDMA status bit RX_VLAN_ENCAP BIT(19) in CPPI
> descriptor to identify when VLAN header encapsulation word is present.
> - PKT_Type = 0x01 or 0x02 then ignore VLAN header encapsulation word and
> pass packet as is;
> - if HDR_PKT_Vid = 0 then ignore VLAN header encapsulation word and pass
> packet as is;
> - In dual mac mode traffic is separated between ports using default port
> vlans, which are not be visible to Host and so should not be reported.
> Hence, check for default port vlans in dual mac mode and ignore VLAN header
> encapsulation word;
> - otherwise fill SKB with VLAN info using __vlan_hwaccel_put_tag();
> - PKT_Type = 0x00 (VLAN-tagged) then strip out VLAN header from SKB.
> 
> Signed-off-by: Grygorii Strashko 

Applied, thank you.

Re: [PATCH net-next] net: ethernet: ti: cpsw: enable vlan rx vlan offload

[David Miller]

From: Grygorii Strashko 
Date: Thu, 15 Mar 2018 15:15:50 -0500

> In VLAN_AWARE mode CPSW can insert VLAN header encapsulation word on Host
> port 0 egress (RX) before the packet data if RX_VLAN_ENCAP bit is set in
> CPSW_CONTROL register. VLAN header encapsulation word has following format:
> 
>  HDR_PKT_Priority bits 29-31 - Header Packet VLAN prio (Highest prio: 7)
>  HDR_PKT_CFIbits 28 - Header Packet VLAN CFI bit.
>  HDR_PKT_Vidbits 27-16 - Header Packet VLAN ID
>  PKT_Type bits 8-9 - Packet Type. Indicates whether the packet is
>   VLAN-tagged, priority-tagged, or non-tagged.
>   00: VLAN-tagged packet
>   01: Reserved
>   10: Priority-tagged packet
>   11: Non-tagged packet
> 
> This feature can be used to implement TX VLAN offload in case of
> VLAN-tagged packets and to insert VLAN tag in case Non-tagged packet was
> received on port with PVID set. As per documentation, CPSW never modifies
> packet data on Host egress (RX) and as result, without this feature
> enabled, Host port will not be able to receive properly packets which
> entered switch non-tagged through external Port with PVID set (when
> non-tagged packet forwarded from external Port with PVID set to another
> external Port - packet will be VLAN tagged properly).
> 
> Implementation details:
> - on RX driver will check CPDMA status bit RX_VLAN_ENCAP BIT(19) in CPPI
> descriptor to identify when VLAN header encapsulation word is present.
> - PKT_Type = 0x01 or 0x02 then ignore VLAN header encapsulation word and
> pass packet as is;
> - if HDR_PKT_Vid = 0 then ignore VLAN header encapsulation word and pass
> packet as is;
> - In dual mac mode traffic is separated between ports using default port
> vlans, which are not be visible to Host and so should not be reported.
> Hence, check for default port vlans in dual mac mode and ignore VLAN header
> encapsulation word;
> - otherwise fill SKB with VLAN info using __vlan_hwaccel_put_tag();
> - PKT_Type = 0x00 (VLAN-tagged) then strip out VLAN header from SKB.
> 
> Signed-off-by: Grygorii Strashko 

Applied, thank you.

Re: [PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface

[David Miller]

From: SZ Lin (林上智) 
Date: Fri, 16 Mar 2018 00:56:01 +0800

> According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and
> DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only
> available when PHY is configured in RGMII mode with 10Mbps speed. It will
> cause some networking issues without RGMII mode, such as carrier sense
> errors and low throughput. TI also mentioned this issue in their forum[4].
> 
> This patch adds the check mechanism for PHY interface with RGMII interface
> type, the in-band mode can only be set in RGMII mode with 10Mbps speed.
> 
> References:
> [1]: https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf
> [2]: http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf
> [3]: http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf
> [4]: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/640765/2392155
> 
> Suggested-by: Holsety Chen (陳憲輝) 
> Signed-off-by: SZ Lin (林上智) 
> Signed-off-by: Schuyler Patton 

Applied and queued up for -stable, thank you.

Re: [PATCH v2] net: ethernet: ti: cpsw: add check for in-band mode setting with RGMII PHY interface

[David Miller]

From: SZ Lin (林上智) 
Date: Fri, 16 Mar 2018 00:56:01 +0800

> According to AM335x TRM[1] 14.3.6.2, AM437x TRM[2] 15.3.6.2 and
> DRA7 TRM[3] 24.11.4.8.7.3.3, in-band mode in EXT_EN(bit18) register is only
> available when PHY is configured in RGMII mode with 10Mbps speed. It will
> cause some networking issues without RGMII mode, such as carrier sense
> errors and low throughput. TI also mentioned this issue in their forum[4].
> 
> This patch adds the check mechanism for PHY interface with RGMII interface
> type, the in-band mode can only be set in RGMII mode with 10Mbps speed.
> 
> References:
> [1]: https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf
> [2]: http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf
> [3]: http://www.ti.com/lit/ug/spruic2b/spruic2b.pdf
> [4]: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/640765/2392155
> 
> Suggested-by: Holsety Chen (陳憲輝) 
> Signed-off-by: SZ Lin (林上智) 
> Signed-off-by: Schuyler Patton 

Applied and queued up for -stable, thank you.

Re: [PATCH] net: hns: Fix ethtool private flags

[David Miller]

From: Matthias Brugger 
Date: Thu, 15 Mar 2018 17:54:20 +0100

> The driver implementation returns support for private flags, while
> no private flags are present. When asked for the number of private
> flags it returns the number of statistic flag names.
> 
> Fix this by returning EOPNOTSUPP for not implemented ethtool flags.
> 
> Signed-off-by: Matthias Brugger 

Looks good, applied, thank you.

Re: [PATCH] net: hns: Fix ethtool private flags

[David Miller]

From: Matthias Brugger 
Date: Thu, 15 Mar 2018 17:54:20 +0100

> The driver implementation returns support for private flags, while
> no private flags are present. When asked for the number of private
> flags it returns the number of statistic flag names.
> 
> Fix this by returning EOPNOTSUPP for not implemented ethtool flags.
> 
> Signed-off-by: Matthias Brugger 

Looks good, applied, thank you.

Re: [PATCH] MAINTAINERS: update maintainers for MTD and SPI NOR subsystems

[Marek Vasut]

On 03/15/2018 08:04 PM, Cyrille Pitchen wrote:
> remove myself as MTD and SPI NOR maintainer.
> 
> Signed-off-by: Cyrille Pitchen 

What happened ?

> ---
>  MAINTAINERS | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3bdc260e36b7..7892db9a9494 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9037,7 +9037,6 @@ M:  Brian Norris 
>  M:   Boris Brezillon 
>  M:   Marek Vasut 
>  M:   Richard Weinberger 
> -M:   Cyrille Pitchen 
>  L:   linux-...@lists.infradead.org
>  W:   http://www.linux-mtd.infradead.org/
>  Q:   http://patchwork.ozlabs.org/project/linux-mtd/list/
> @@ -13006,7 +13005,6 @@ F:arch/arm/boot/dts/spear*
>  F:   arch/arm/mach-spear/
>  
>  SPI NOR SUBSYSTEM
> -M:   Cyrille Pitchen 
>  M:   Marek Vasut 
>  L:   linux-...@lists.infradead.org
>  W:   http://www.linux-mtd.infradead.org/
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH] MAINTAINERS: update maintainers for MTD and SPI NOR subsystems

[Marek Vasut]

On 03/15/2018 08:04 PM, Cyrille Pitchen wrote:
> remove myself as MTD and SPI NOR maintainer.
> 
> Signed-off-by: Cyrille Pitchen 

What happened ?

> ---
>  MAINTAINERS | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3bdc260e36b7..7892db9a9494 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9037,7 +9037,6 @@ M:  Brian Norris 
>  M:   Boris Brezillon 
>  M:   Marek Vasut 
>  M:   Richard Weinberger 
> -M:   Cyrille Pitchen 
>  L:   linux-...@lists.infradead.org
>  W:   http://www.linux-mtd.infradead.org/
>  Q:   http://patchwork.ozlabs.org/project/linux-mtd/list/
> @@ -13006,7 +13005,6 @@ F:arch/arm/boot/dts/spear*
>  F:   arch/arm/mach-spear/
>  
>  SPI NOR SUBSYSTEM
> -M:   Cyrille Pitchen 
>  M:   Marek Vasut 
>  L:   linux-...@lists.infradead.org
>  W:   http://www.linux-mtd.infradead.org/
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH v6 15/15] xfs, dax: introduce xfs_break_dax_layouts()

[kbuild test robot]

Hi Dan,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
config: x86_64-randconfig-s2-03180641 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   fs//xfs/xfs_file.c: In function 'xfs_break_dax_layouts':
>> fs//xfs/xfs_file.c:786:8: error: implicit declaration of function 
>> '___wait_var_event' [-Werror=implicit-function-declaration]
 ret = ___wait_var_event(>_refcount,
   ^
   fs//xfs/xfs_file.c:788:4: error: invalid use of void expression
   0, 0, xfs_wait_var_event(inode, iolock));
   ^
   cc1: some warnings being treated as errors
--
   drivers//dax/super.c: In function 'generic_dax_pagefree':
>> drivers//dax/super.c:170:2: error: implicit declaration of function 
>> 'wake_up_var' [-Werror=implicit-function-declaration]
 wake_up_var(>_refcount);
 ^~~
   cc1: some warnings being treated as errors

vim +/___wait_var_event +786 fs//xfs/xfs_file.c

   773  
   774  static int
   775  xfs_break_dax_layouts(
   776  struct inode*inode,
   777  uintiolock)
   778  {
   779  struct page *page;
   780  int ret;
   781  
   782  page = dax_layout_busy_page(inode->i_mapping);
   783  if (!page)
   784  return 0;
   785  
 > 786  ret = ___wait_var_event(>_refcount,
   787  atomic_read(>_refcount) == 1, 
TASK_INTERRUPTIBLE,
   788  0, 0, xfs_wait_var_event(inode, iolock));
   789  if (ret < 0)
   790  return ret;
   791  return 1;
   792  }
   793  

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


.config.gz
Description: application/gzip

Re: [PATCH v6 15/15] xfs, dax: introduce xfs_break_dax_layouts()

[kbuild test robot]

Hi Dan,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
config: x86_64-randconfig-s2-03180641 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   fs//xfs/xfs_file.c: In function 'xfs_break_dax_layouts':
>> fs//xfs/xfs_file.c:786:8: error: implicit declaration of function 
>> '___wait_var_event' [-Werror=implicit-function-declaration]
 ret = ___wait_var_event(>_refcount,
   ^
   fs//xfs/xfs_file.c:788:4: error: invalid use of void expression
   0, 0, xfs_wait_var_event(inode, iolock));
   ^
   cc1: some warnings being treated as errors
--
   drivers//dax/super.c: In function 'generic_dax_pagefree':
>> drivers//dax/super.c:170:2: error: implicit declaration of function 
>> 'wake_up_var' [-Werror=implicit-function-declaration]
 wake_up_var(>_refcount);
 ^~~
   cc1: some warnings being treated as errors

vim +/___wait_var_event +786 fs//xfs/xfs_file.c

   773  
   774  static int
   775  xfs_break_dax_layouts(
   776  struct inode*inode,
   777  uintiolock)
   778  {
   779  struct page *page;
   780  int ret;
   781  
   782  page = dax_layout_busy_page(inode->i_mapping);
   783  if (!page)
   784  return 0;
   785  
 > 786  ret = ___wait_var_event(>_refcount,
   787  atomic_read(>_refcount) == 1, 
TASK_INTERRUPTIBLE,
   788  0, 0, xfs_wait_var_event(inode, iolock));
   789  if (ret < 0)
   790  return ret;
   791  return 1;
   792  }
   793  

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


.config.gz
Description: application/gzip

Re: [PATCH v5 3/8] docs: Add Generic Counter interface documentation

[Randy Dunlap]

On 03/09/2018 10:42 AM, William Breathitt Gray wrote:
> This patch adds high-level documentation about the Generic Counter
> interface.
> 
> Signed-off-by: William Breathitt Gray 
> ---
>  Documentation/driver-api/generic-counter.rst | 321 
> +++
>  Documentation/driver-api/index.rst   |   1 +
>  MAINTAINERS  |   1 +
>  3 files changed, 323 insertions(+)
>  create mode 100644 Documentation/driver-api/generic-counter.rst
> 
> diff --git a/Documentation/driver-api/generic-counter.rst 
> b/Documentation/driver-api/generic-counter.rst
> new file mode 100644
> index ..bce0cbc31963
> --- /dev/null
> +++ b/Documentation/driver-api/generic-counter.rst
> @@ -0,0 +1,321 @@

[snip]

> +There are three core components to a counter:
> +
> +COUNT
> +-
> +A Count represents the count data for a set of Signals. The
> +Generic Counter interface provides the following available count
> +data types:
> +
> + * COUNT_POSITION_UNSIGNED:
> + Unsigned integer value representing position.
> +
> + * COUNT_POSITION_SIGNED:
> + Signed integer value representing position.
> +
> +A Count has a count function mode which represents the update
> +behavior for the count data. The Generic Counter interface
> +provides the following available count function modes:
> +
> + * Increase:
> + Accumulated count is incremented.
> +
> + * Decrease:
> + Accumulated count is decremented.
> +
> + * Pulse-Direction:
> + Rising edges on quadrature pair signal A updates
> +the respective count. The input level of
> +quadrature pair signal B determines direction.
> +
> + * Quadrature x1:
> + If direction is forward, rising edges on
> +quadrature pair signal A updates the respective
> +count; if the direction is backward, falling
> +edges on quadrature pair signal A updates the
> +respective count. Quadrature encoding determines
> +the direction.
> +
> + * Quadrature x2:
> + Any state transition on quadrature pair signal A
> +updates the respective count. Quadrature
> +encoding determines the direction.
> +
> + * Quadrature x4:
> + Any state transition on either quadrature pair
> +signals updates  the respective count. Quadrature

   change  ^^^ to 

> +encoding determines the direction.
> +
> +A Count has a set of one or more associated Signals.
> +
> +SIGNAL
> +--
> +A Signal represents a counter input data; this is the input data
> +that is analyzed by the counter to determine the count data;
> +e.g. a quadrature signal output line of a rotary encoder. Not
> +all counter devices provide user access to the Signal data.
> +
> +The Generic Counter interface provides the following available
> +signal data types for when the Signal data is available for user
> +access:
> +
> + * SIGNAL_LEVEL_LOW:
> +Signal line is in a low state.
> +
> +* SIGNAL_LEVEL_HIGH:
> +Signal line is in a high state.
> +
> +A Signal may be associated to one or more Counts.

  with (?)

Hm, there are around 8 or so instances of "associated to" here -- and at least
one of "associated with" (to my surprise :).  But it's no big deal.


Reviewed-by: Randy Dunlap 

thanks,
-- 
~Randy

Re: [PATCH v5 3/8] docs: Add Generic Counter interface documentation

[Randy Dunlap]

On 03/09/2018 10:42 AM, William Breathitt Gray wrote:
> This patch adds high-level documentation about the Generic Counter
> interface.
> 
> Signed-off-by: William Breathitt Gray 
> ---
>  Documentation/driver-api/generic-counter.rst | 321 
> +++
>  Documentation/driver-api/index.rst   |   1 +
>  MAINTAINERS  |   1 +
>  3 files changed, 323 insertions(+)
>  create mode 100644 Documentation/driver-api/generic-counter.rst
> 
> diff --git a/Documentation/driver-api/generic-counter.rst 
> b/Documentation/driver-api/generic-counter.rst
> new file mode 100644
> index ..bce0cbc31963
> --- /dev/null
> +++ b/Documentation/driver-api/generic-counter.rst
> @@ -0,0 +1,321 @@

[snip]

> +There are three core components to a counter:
> +
> +COUNT
> +-
> +A Count represents the count data for a set of Signals. The
> +Generic Counter interface provides the following available count
> +data types:
> +
> + * COUNT_POSITION_UNSIGNED:
> + Unsigned integer value representing position.
> +
> + * COUNT_POSITION_SIGNED:
> + Signed integer value representing position.
> +
> +A Count has a count function mode which represents the update
> +behavior for the count data. The Generic Counter interface
> +provides the following available count function modes:
> +
> + * Increase:
> + Accumulated count is incremented.
> +
> + * Decrease:
> + Accumulated count is decremented.
> +
> + * Pulse-Direction:
> + Rising edges on quadrature pair signal A updates
> +the respective count. The input level of
> +quadrature pair signal B determines direction.
> +
> + * Quadrature x1:
> + If direction is forward, rising edges on
> +quadrature pair signal A updates the respective
> +count; if the direction is backward, falling
> +edges on quadrature pair signal A updates the
> +respective count. Quadrature encoding determines
> +the direction.
> +
> + * Quadrature x2:
> + Any state transition on quadrature pair signal A
> +updates the respective count. Quadrature
> +encoding determines the direction.
> +
> + * Quadrature x4:
> + Any state transition on either quadrature pair
> +signals updates  the respective count. Quadrature

   change  ^^^ to 

> +encoding determines the direction.
> +
> +A Count has a set of one or more associated Signals.
> +
> +SIGNAL
> +--
> +A Signal represents a counter input data; this is the input data
> +that is analyzed by the counter to determine the count data;
> +e.g. a quadrature signal output line of a rotary encoder. Not
> +all counter devices provide user access to the Signal data.
> +
> +The Generic Counter interface provides the following available
> +signal data types for when the Signal data is available for user
> +access:
> +
> + * SIGNAL_LEVEL_LOW:
> +Signal line is in a low state.
> +
> +* SIGNAL_LEVEL_HIGH:
> +Signal line is in a high state.
> +
> +A Signal may be associated to one or more Counts.

  with (?)

Hm, there are around 8 or so instances of "associated to" here -- and at least
one of "associated with" (to my surprise :).  But it's no big deal.


Reviewed-by: Randy Dunlap 

thanks,
-- 
~Randy

Re: [PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

[Jason Vas Dias]

fixed typo in timer_latency.c affecting only -r  printout
:

$ gcc -DN_SAMPLES=1000 -o timer timer_latency.c
CLOCK_MONOTONIC ( using rdtscp_ordered() ) :

$ ./timer -m -r 10
sum: 67615
Total time: 0.67615S - Average Latency: 0.00067S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51858
Total time: 0.51858S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51742
Total time: 0.51742S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51944
Total time: 0.51944S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51838
Total time: 0.51838S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52397
Total time: 0.52397S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52428
Total time: 0.52428S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52135
Total time: 0.52135S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52145
Total time: 0.52145S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 53116
Total time: 0.53116S - Average Latency: 0.00053S N zero
deltas: 0 N inconsistent deltas: 0
Average of 10 average latencies of 1000 samples : 0.00053S


CLOCK_MONOTONIC_RAW ( using rdtscp() ) :

$ ./timer  -r 10
sum: 25755
Total time: 0.25755S - Average Latency: 0.00025S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21614
Total time: 0.21614S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21616
Total time: 0.21616S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21610
Total time: 0.21610S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21619
Total time: 0.21619S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21617
Total time: 0.21617S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21610
Total time: 0.21610S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16940
Total time: 0.16940S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16939
Total time: 0.16939S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16943
Total time: 0.16943S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
Average of 10 average latencies of 1000 samples : 0.00019S
/*
 * Program to measure high-res timer latency.
 *
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifndef N_SAMPLES
#define N_SAMPLES 100
#endif
#define _STR(_S_) #_S_
#define STR(_S_) _STR(_S_)

#define TS2NS(_TS_) unsigned long long)(_TS_).tv_sec)*10ULL) + (((unsigned long long)((_TS_).tv_nsec 

int main(int argc, char *const* argv, char *const* envp)
{ struct timespec sample[N_SAMPLES+1];
  unsigned int cnt=N_SAMPLES, s=0 , avg_n=0;
  unsigned long long
deltas [ N_SAMPLES ]
, t1, t2, sum=0, zd=0, ic=0, d
, t_start, avg_ns, *avgs=0;
  clockid_t clk = CLOCK_MONOTONIC_RAW;
  bool do_dump = false;
  int argn=1, repeat=1;
  for(; argn < argc; argn+=1)
if( argv[argn] != NULL )
  if( *(argv[argn]) == '-')
	switch( *(argv[argn]+1) )
	{ case 'm':
	  case 'M':
	clk = CLOCK_MONOTONIC;
	break;
	  case 'd':
	  case 'D':
	do_dump = true;
	break;
 	  case 'r':
  	  case 'R':
	if( (argn < argc) && (argv[argn+1] != NULL))
	  repeat = atoi(argv[argn+=1]);
	break;
	  case '?':
	  case 'h':
	  case 'u':
	  case 'U':
	  case 'H':
	fprintf(stderr,"Usage: timer_latency [\n\t-m : use CLOCK_MONOTONIC clock (not CLOCK_MONOTONIC_RAW)\n\t-d : dump timespec contents. N_SAMPLES: " STR(N_SAMPLES) "\n\t"
	"-r \n]\t"
	"Calculates average timer latency (minimum time that can be measured) over N_SAMPLES.\n"
	   );
	return 0;
	}
  if( repeat > 1 )
  { avgs=alloca(sizeof(unsigned long long) * (N_SAMPLES + 1));
if( ((unsigned long) avgs) & 7 )
  avgs = ((unsigned long long*)(((unsigned char*)avgs)+(8-((unsigned long) avgs) & 7)));
  }
  do {
cnt=N_SAMPLES;
s=0;
  do
  { if( 0 != clock_gettime(clk, [s++]) )
{ fprintf(stderr,"oops, clock_gettime() failed: %d: '%s'.\n", errno, strerror(errno));
  return 1;
}
  }while( --cnt );
  clock_gettime(clk, [s]);
  for(s=1; s < (N_SAMPLES+1); s+=1)
  { t1 = TS2NS(sample[s-1]);
t2 = TS2NS(sample[s]);
if ( (t1 > t2)
   ||(sample[s-1].tv_sec > sample[s].tv_sec)
   ||((sample[s-1].tv_sec == sample[s].tv_sec)
&&(sample[s-1].tv_nsec > sample[s].tv_nsec)
 )
   )
{ fprintf(stderr,"Inconsistency: %llu %llu %lu.%lu %lu.%lu\n", t1 , t2
, sample[s-1].tv_sec, sample[s-1].tv_nsec
, sample[s].tv_sec,   sample[s].tv_nsec
  );
  ic+=1;
  

Re: [PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

[Jason Vas Dias]

fixed typo in timer_latency.c affecting only -r  printout
:

$ gcc -DN_SAMPLES=1000 -o timer timer_latency.c
CLOCK_MONOTONIC ( using rdtscp_ordered() ) :

$ ./timer -m -r 10
sum: 67615
Total time: 0.67615S - Average Latency: 0.00067S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51858
Total time: 0.51858S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51742
Total time: 0.51742S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51944
Total time: 0.51944S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 51838
Total time: 0.51838S - Average Latency: 0.00051S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52397
Total time: 0.52397S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52428
Total time: 0.52428S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52135
Total time: 0.52135S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 52145
Total time: 0.52145S - Average Latency: 0.00052S N zero
deltas: 0 N inconsistent deltas: 0
sum: 53116
Total time: 0.53116S - Average Latency: 0.00053S N zero
deltas: 0 N inconsistent deltas: 0
Average of 10 average latencies of 1000 samples : 0.00053S


CLOCK_MONOTONIC_RAW ( using rdtscp() ) :

$ ./timer  -r 10
sum: 25755
Total time: 0.25755S - Average Latency: 0.00025S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21614
Total time: 0.21614S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21616
Total time: 0.21616S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21610
Total time: 0.21610S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21619
Total time: 0.21619S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21617
Total time: 0.21617S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 21610
Total time: 0.21610S - Average Latency: 0.00021S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16940
Total time: 0.16940S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16939
Total time: 0.16939S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
sum: 16943
Total time: 0.16943S - Average Latency: 0.00016S N zero
deltas: 0 N inconsistent deltas: 0
Average of 10 average latencies of 1000 samples : 0.00019S
/*
 * Program to measure high-res timer latency.
 *
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifndef N_SAMPLES
#define N_SAMPLES 100
#endif
#define _STR(_S_) #_S_
#define STR(_S_) _STR(_S_)

#define TS2NS(_TS_) unsigned long long)(_TS_).tv_sec)*10ULL) + (((unsigned long long)((_TS_).tv_nsec 

int main(int argc, char *const* argv, char *const* envp)
{ struct timespec sample[N_SAMPLES+1];
  unsigned int cnt=N_SAMPLES, s=0 , avg_n=0;
  unsigned long long
deltas [ N_SAMPLES ]
, t1, t2, sum=0, zd=0, ic=0, d
, t_start, avg_ns, *avgs=0;
  clockid_t clk = CLOCK_MONOTONIC_RAW;
  bool do_dump = false;
  int argn=1, repeat=1;
  for(; argn < argc; argn+=1)
if( argv[argn] != NULL )
  if( *(argv[argn]) == '-')
	switch( *(argv[argn]+1) )
	{ case 'm':
	  case 'M':
	clk = CLOCK_MONOTONIC;
	break;
	  case 'd':
	  case 'D':
	do_dump = true;
	break;
 	  case 'r':
  	  case 'R':
	if( (argn < argc) && (argv[argn+1] != NULL))
	  repeat = atoi(argv[argn+=1]);
	break;
	  case '?':
	  case 'h':
	  case 'u':
	  case 'U':
	  case 'H':
	fprintf(stderr,"Usage: timer_latency [\n\t-m : use CLOCK_MONOTONIC clock (not CLOCK_MONOTONIC_RAW)\n\t-d : dump timespec contents. N_SAMPLES: " STR(N_SAMPLES) "\n\t"
	"-r \n]\t"
	"Calculates average timer latency (minimum time that can be measured) over N_SAMPLES.\n"
	   );
	return 0;
	}
  if( repeat > 1 )
  { avgs=alloca(sizeof(unsigned long long) * (N_SAMPLES + 1));
if( ((unsigned long) avgs) & 7 )
  avgs = ((unsigned long long*)(((unsigned char*)avgs)+(8-((unsigned long) avgs) & 7)));
  }
  do {
cnt=N_SAMPLES;
s=0;
  do
  { if( 0 != clock_gettime(clk, [s++]) )
{ fprintf(stderr,"oops, clock_gettime() failed: %d: '%s'.\n", errno, strerror(errno));
  return 1;
}
  }while( --cnt );
  clock_gettime(clk, [s]);
  for(s=1; s < (N_SAMPLES+1); s+=1)
  { t1 = TS2NS(sample[s-1]);
t2 = TS2NS(sample[s]);
if ( (t1 > t2)
   ||(sample[s-1].tv_sec > sample[s].tv_sec)
   ||((sample[s-1].tv_sec == sample[s].tv_sec)
&&(sample[s-1].tv_nsec > sample[s].tv_nsec)
 )
   )
{ fprintf(stderr,"Inconsistency: %llu %llu %lu.%lu %lu.%lu\n", t1 , t2
, sample[s-1].tv_sec, sample[s-1].tv_nsec
, sample[s].tv_sec,   sample[s].tv_nsec
  );
  ic+=1;
  

[PATCH v4 3/8] doc: Add doc for the Ingenic TCU hardware

[Paul Cercueil]

Add a documentation file about the Timer/Counter Unit (TCU)
present in the Ingenic JZ47xx SoCs.

Signed-off-by: Paul Cercueil 
---
 Documentation/mips/00-INDEX|  3 +++
 Documentation/mips/ingenic-tcu.txt | 50 ++
 2 files changed, 53 insertions(+)
 create mode 100644 Documentation/mips/ingenic-tcu.txt

 v4: New patch in this series

diff --git a/Documentation/mips/00-INDEX b/Documentation/mips/00-INDEX
index 8ae9cffc2262..8ab8c3f83771 100644
--- a/Documentation/mips/00-INDEX
+++ b/Documentation/mips/00-INDEX
@@ -2,3 +2,6 @@
- this file.
 AU1xxx_IDE.README
- README for MIPS AU1XXX IDE driver.
+ingenic-tcu.txt
+   - Information file about the Timer/Counter Unit present
+ in Ingenic JZ47xx SoCs.
diff --git a/Documentation/mips/ingenic-tcu.txt 
b/Documentation/mips/ingenic-tcu.txt
new file mode 100644
index ..2508e5793da8
--- /dev/null
+++ b/Documentation/mips/ingenic-tcu.txt
@@ -0,0 +1,50 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit hardware
+---
+
+The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
+hardware block. It features eight channels, that can be used as counters,
+timers, or PWM.
+
+- JZ4770 introduced a separate channel, called Operating System Timer (OST).
+  It is a 64-bit programmable timer.
+
+- Each one of the eight channels has its own clock, which can be reparented
+  to three different clocks (pclk, ext, rtc), gated, and reclocked, through
+  their TCSR register.
+  * The watchdog and OST hardware blocks also feature a TCSR register with
+   the same format in their register space.
+  * The TCU registers used to gate/ungate can also gate/ungate the watchdog
+   and OST clocks.
+
+- On SoCs >= JZ4770, there are two different modes:
+  * Channels 0, 3-7 operate in TCU1 mode: they cannot work in sleep mode,
+   but are easier to operate.
+  * Channels 1-2 operate in TCU2 mode: they can work in sleep mode, but
+   the operation is a bit more complicated than with TCU1 channels.
+
+- Each channel can generate an interrupt. Some channels share an interrupt
+  line, some don't, and this changes between SoC versions:
+  * on JZ4740, timer 0 and timer 1 have their own interrupt line; others share
+   one interrupt line.
+  * on JZ4770 and JZ4780, timer 5 has its own interrupt; timers 0-4 and 6-7 all
+   use one interrupt line; the OST uses the last interrupt.
+
+Implementation
+--
+
+The functionalities of the TCU hardware are spread across multiple drivers:
+- interrupts:   drivers/irqchip/irq-ingenic-tcu.c
+- clocks:   drivers/clk/ingenic/tcu.c
+- timer:drivers/clocksource/timer-ingenic.c
+- PWM:  drivers/pwm/pwm-jz4740.c
+- watchdog: drivers/watchdog/jz4740_wdt.c
+- OST: (none yet)
+
+Because various functionalities of the TCU that belong to different drivers
+and frameworks can be controlled from the same registers, all of these drivers
+access their registers through the same regmap.
+
+In practice, the devicetree nodes for all of these drivers must be children
+of a "syscon" node that defines the register area.
+For more information regarding the devicetree bindings of the TCU drivers,
+have a look at Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
-- 
2.11.0

[PATCH v4 6/8] clk: ingenic: Add JZ47xx TCU clocks driver

[Paul Cercueil]

The TCU (Timer Counter Unit) of the Ingenic JZ47xx SoCs features 8
channels, each one having its own clock, that can be started and
stopped, reparented, and reclocked.

This driver only modifies the bits of the registers of the TCU that are
related to clocks control. It provides one clock per TCU channel (plus
one for the watchdog and one for the OS timer) that can be used by other
drivers.

Signed-off-by: Paul Cercueil 
Acked-by: Stephen Boyd 
---
 drivers/clk/ingenic/Makefile |   2 +-
 drivers/clk/ingenic/tcu.c| 319 +++
 2 files changed, 320 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/ingenic/tcu.c

 v2: - Use SPDX identifier for the license
 - Fix broken build caused by typo when correcting patch
 v3: - Move documentation to its own patch
 - Get rid of ingenic_tcu structure. The "struct regmap *map" was
   added to struct ingenic_tcu_clk, the other fields are gone.
 - Replace clk_register / clk_register_clockdev /
   of_clk_add_provider with their "clk_hw" variant.
 v4: No change

diff --git a/drivers/clk/ingenic/Makefile b/drivers/clk/ingenic/Makefile
index 1456e4cdb562..9dcadd4fed4c 100644
--- a/drivers/clk/ingenic/Makefile
+++ b/drivers/clk/ingenic/Makefile
@@ -1,4 +1,4 @@
-obj-y  += cgu.o
+obj-y  += cgu.o tcu.o
 obj-$(CONFIG_MACH_JZ4740)  += jz4740-cgu.o
 obj-$(CONFIG_MACH_JZ4770)  += jz4770-cgu.o
 obj-$(CONFIG_MACH_JZ4780)  += jz4780-cgu.o
diff --git a/drivers/clk/ingenic/tcu.c b/drivers/clk/ingenic/tcu.c
new file mode 100644
index ..b550b6ac8fb4
--- /dev/null
+++ b/drivers/clk/ingenic/tcu.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic JZ47xx SoC TCU clocks driver
+ * Copyright (C) 2018 Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+enum ingenic_version {
+   ID_JZ4740,
+   ID_JZ4770,
+   ID_JZ4780,
+};
+
+struct ingenic_tcu_clk_info {
+   struct clk_init_data init_data;
+   u8 gate_bit;
+   u8 tcsr_reg;
+};
+
+struct ingenic_tcu_clk {
+   struct clk_hw hw;
+
+   struct regmap *map;
+   const struct ingenic_tcu_clk_info *info;
+
+   unsigned int idx;
+};
+
+#define to_tcu_clk(_hw) container_of(_hw, struct ingenic_tcu_clk, hw)
+
+static int ingenic_tcu_enable(struct clk_hw *hw)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+
+   regmap_write(tcu_clk->map, TCU_REG_TSCR, BIT(info->gate_bit));
+   return 0;
+}
+
+static void ingenic_tcu_disable(struct clk_hw *hw)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+
+   regmap_write(tcu_clk->map, TCU_REG_TSSR, BIT(info->gate_bit));
+}
+
+static int ingenic_tcu_is_enabled(struct clk_hw *hw)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+   unsigned int value;
+
+   regmap_read(tcu_clk->map, TCU_REG_TSR, );
+
+   return !(value & BIT(info->gate_bit));
+}
+
+static u8 ingenic_tcu_get_parent(struct clk_hw *hw)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+   unsigned int val = 0;
+   int ret;
+
+   ret = regmap_read(tcu_clk->map, info->tcsr_reg, );
+   WARN_ONCE(ret < 0, "Unable to read TCSR %i", tcu_clk->idx);
+
+   return ffs(val & TCU_TCSR_PARENT_CLOCK_MASK) - 1;
+}
+
+static int ingenic_tcu_set_parent(struct clk_hw *hw, u8 idx)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+   struct regmap *map = tcu_clk->map;
+   int ret;
+
+   /*
+* Our clock provider has the CLK_SET_PARENT_GATE flag set, so we know
+* that the clk is in unprepared state. To be able to access TCSR
+* we must ungate the clock supply and we gate it again when done.
+*/
+
+   regmap_write(map, TCU_REG_TSCR, BIT(info->gate_bit));
+
+   ret = regmap_update_bits(map, info->tcsr_reg,
+   TCU_TCSR_PARENT_CLOCK_MASK, BIT(idx));
+   WARN_ONCE(ret < 0, "Unable to update TCSR %i", tcu_clk->idx);
+
+   regmap_write(map, TCU_REG_TSSR, BIT(info->gate_bit));
+
+   return 0;
+}
+
+static unsigned long ingenic_tcu_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+   unsigned int prescale;
+   int ret;
+
+   ret = regmap_read(tcu_clk->map, info->tcsr_reg, );
+   WARN_ONCE(ret < 0, "Unable to read TCSR %i", tcu_clk->idx);
+
+   prescale = (prescale & 

[PATCH v4 3/8] doc: Add doc for the Ingenic TCU hardware

[Paul Cercueil]

Add a documentation file about the Timer/Counter Unit (TCU)
present in the Ingenic JZ47xx SoCs.

Signed-off-by: Paul Cercueil 
---
 Documentation/mips/00-INDEX|  3 +++
 Documentation/mips/ingenic-tcu.txt | 50 ++
 2 files changed, 53 insertions(+)
 create mode 100644 Documentation/mips/ingenic-tcu.txt

 v4: New patch in this series

diff --git a/Documentation/mips/00-INDEX b/Documentation/mips/00-INDEX
index 8ae9cffc2262..8ab8c3f83771 100644
--- a/Documentation/mips/00-INDEX
+++ b/Documentation/mips/00-INDEX
@@ -2,3 +2,6 @@
- this file.
 AU1xxx_IDE.README
- README for MIPS AU1XXX IDE driver.
+ingenic-tcu.txt
+   - Information file about the Timer/Counter Unit present
+ in Ingenic JZ47xx SoCs.
diff --git a/Documentation/mips/ingenic-tcu.txt 
b/Documentation/mips/ingenic-tcu.txt
new file mode 100644
index ..2508e5793da8
--- /dev/null
+++ b/Documentation/mips/ingenic-tcu.txt
@@ -0,0 +1,50 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit hardware
+---
+
+The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
+hardware block. It features eight channels, that can be used as counters,
+timers, or PWM.
+
+- JZ4770 introduced a separate channel, called Operating System Timer (OST).
+  It is a 64-bit programmable timer.
+
+- Each one of the eight channels has its own clock, which can be reparented
+  to three different clocks (pclk, ext, rtc), gated, and reclocked, through
+  their TCSR register.
+  * The watchdog and OST hardware blocks also feature a TCSR register with
+   the same format in their register space.
+  * The TCU registers used to gate/ungate can also gate/ungate the watchdog
+   and OST clocks.
+
+- On SoCs >= JZ4770, there are two different modes:
+  * Channels 0, 3-7 operate in TCU1 mode: they cannot work in sleep mode,
+   but are easier to operate.
+  * Channels 1-2 operate in TCU2 mode: they can work in sleep mode, but
+   the operation is a bit more complicated than with TCU1 channels.
+
+- Each channel can generate an interrupt. Some channels share an interrupt
+  line, some don't, and this changes between SoC versions:
+  * on JZ4740, timer 0 and timer 1 have their own interrupt line; others share
+   one interrupt line.
+  * on JZ4770 and JZ4780, timer 5 has its own interrupt; timers 0-4 and 6-7 all
+   use one interrupt line; the OST uses the last interrupt.
+
+Implementation
+--
+
+The functionalities of the TCU hardware are spread across multiple drivers:
+- interrupts:   drivers/irqchip/irq-ingenic-tcu.c
+- clocks:   drivers/clk/ingenic/tcu.c
+- timer:drivers/clocksource/timer-ingenic.c
+- PWM:  drivers/pwm/pwm-jz4740.c
+- watchdog: drivers/watchdog/jz4740_wdt.c
+- OST: (none yet)
+
+Because various functionalities of the TCU that belong to different drivers
+and frameworks can be controlled from the same registers, all of these drivers
+access their registers through the same regmap.
+
+In practice, the devicetree nodes for all of these drivers must be children
+of a "syscon" node that defines the register area.
+For more information regarding the devicetree bindings of the TCU drivers,
+have a look at Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
-- 
2.11.0

[PATCH v4 6/8] clk: ingenic: Add JZ47xx TCU clocks driver

[Paul Cercueil]

The TCU (Timer Counter Unit) of the Ingenic JZ47xx SoCs features 8
channels, each one having its own clock, that can be started and
stopped, reparented, and reclocked.

This driver only modifies the bits of the registers of the TCU that are
related to clocks control. It provides one clock per TCU channel (plus
one for the watchdog and one for the OS timer) that can be used by other
drivers.

Signed-off-by: Paul Cercueil 
Acked-by: Stephen Boyd 
---
 drivers/clk/ingenic/Makefile |   2 +-
 drivers/clk/ingenic/tcu.c| 319 +++
 2 files changed, 320 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/ingenic/tcu.c

 v2: - Use SPDX identifier for the license
 - Fix broken build caused by typo when correcting patch
 v3: - Move documentation to its own patch
 - Get rid of ingenic_tcu structure. The "struct regmap *map" was
   added to struct ingenic_tcu_clk, the other fields are gone.
 - Replace clk_register / clk_register_clockdev /
   of_clk_add_provider with their "clk_hw" variant.
 v4: No change

diff --git a/drivers/clk/ingenic/Makefile b/drivers/clk/ingenic/Makefile
index 1456e4cdb562..9dcadd4fed4c 100644
--- a/drivers/clk/ingenic/Makefile
+++ b/drivers/clk/ingenic/Makefile
@@ -1,4 +1,4 @@
-obj-y  += cgu.o
+obj-y  += cgu.o tcu.o
 obj-$(CONFIG_MACH_JZ4740)  += jz4740-cgu.o
 obj-$(CONFIG_MACH_JZ4770)  += jz4770-cgu.o
 obj-$(CONFIG_MACH_JZ4780)  += jz4780-cgu.o
diff --git a/drivers/clk/ingenic/tcu.c b/drivers/clk/ingenic/tcu.c
new file mode 100644
index ..b550b6ac8fb4
--- /dev/null
+++ b/drivers/clk/ingenic/tcu.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic JZ47xx SoC TCU clocks driver
+ * Copyright (C) 2018 Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+enum ingenic_version {
+   ID_JZ4740,
+   ID_JZ4770,
+   ID_JZ4780,
+};
+
+struct ingenic_tcu_clk_info {
+   struct clk_init_data init_data;
+   u8 gate_bit;
+   u8 tcsr_reg;
+};
+
+struct ingenic_tcu_clk {
+   struct clk_hw hw;
+
+   struct regmap *map;
+   const struct ingenic_tcu_clk_info *info;
+
+   unsigned int idx;
+};
+
+#define to_tcu_clk(_hw) container_of(_hw, struct ingenic_tcu_clk, hw)
+
+static int ingenic_tcu_enable(struct clk_hw *hw)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+
+   regmap_write(tcu_clk->map, TCU_REG_TSCR, BIT(info->gate_bit));
+   return 0;
+}
+
+static void ingenic_tcu_disable(struct clk_hw *hw)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+
+   regmap_write(tcu_clk->map, TCU_REG_TSSR, BIT(info->gate_bit));
+}
+
+static int ingenic_tcu_is_enabled(struct clk_hw *hw)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+   unsigned int value;
+
+   regmap_read(tcu_clk->map, TCU_REG_TSR, );
+
+   return !(value & BIT(info->gate_bit));
+}
+
+static u8 ingenic_tcu_get_parent(struct clk_hw *hw)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+   unsigned int val = 0;
+   int ret;
+
+   ret = regmap_read(tcu_clk->map, info->tcsr_reg, );
+   WARN_ONCE(ret < 0, "Unable to read TCSR %i", tcu_clk->idx);
+
+   return ffs(val & TCU_TCSR_PARENT_CLOCK_MASK) - 1;
+}
+
+static int ingenic_tcu_set_parent(struct clk_hw *hw, u8 idx)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+   struct regmap *map = tcu_clk->map;
+   int ret;
+
+   /*
+* Our clock provider has the CLK_SET_PARENT_GATE flag set, so we know
+* that the clk is in unprepared state. To be able to access TCSR
+* we must ungate the clock supply and we gate it again when done.
+*/
+
+   regmap_write(map, TCU_REG_TSCR, BIT(info->gate_bit));
+
+   ret = regmap_update_bits(map, info->tcsr_reg,
+   TCU_TCSR_PARENT_CLOCK_MASK, BIT(idx));
+   WARN_ONCE(ret < 0, "Unable to update TCSR %i", tcu_clk->idx);
+
+   regmap_write(map, TCU_REG_TSSR, BIT(info->gate_bit));
+
+   return 0;
+}
+
+static unsigned long ingenic_tcu_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct ingenic_tcu_clk *tcu_clk = to_tcu_clk(hw);
+   const struct ingenic_tcu_clk_info *info = tcu_clk->info;
+   unsigned int prescale;
+   int ret;
+
+   ret = regmap_read(tcu_clk->map, info->tcsr_reg, );
+   WARN_ONCE(ret < 0, "Unable to read TCSR %i", tcu_clk->idx);
+
+   prescale = (prescale & TCU_TCSR_PRESCALE_MASK) >> TCU_TCSR_PRESCALE_LSB;
+
+   return 

[PATCH v4 2/8] dt-bindings: ingenic: Add DT bindings for TCU clocks

[Paul Cercueil]

This header provides clock numbers for the ingenic,tcu
DT binding.

Signed-off-by: Paul Cercueil 
Reviewed-by: Rob Herring 
---
 include/dt-bindings/clock/ingenic,tcu.h | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 include/dt-bindings/clock/ingenic,tcu.h

 v2: Use SPDX identifier for the license
 v3: No change
 v4: No change

diff --git a/include/dt-bindings/clock/ingenic,tcu.h 
b/include/dt-bindings/clock/ingenic,tcu.h
new file mode 100644
index ..179815d7b3bb
--- /dev/null
+++ b/include/dt-bindings/clock/ingenic,tcu.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides clock numbers for the ingenic,tcu DT binding.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
+#define __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
+
+#define JZ4740_CLK_TIMER0  0
+#define JZ4740_CLK_TIMER1  1
+#define JZ4740_CLK_TIMER2  2
+#define JZ4740_CLK_TIMER3  3
+#define JZ4740_CLK_TIMER4  4
+#define JZ4740_CLK_TIMER5  5
+#define JZ4740_CLK_TIMER6  6
+#define JZ4740_CLK_TIMER7  7
+#define JZ4740_CLK_WDT 8
+#define JZ4740_CLK_LASTJZ4740_CLK_WDT
+
+#define JZ4770_CLK_OST 9
+#define JZ4770_CLK_LASTJZ4770_CLK_OST
+
+#endif /* __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ */
-- 
2.11.0

[PATCH v4 2/8] dt-bindings: ingenic: Add DT bindings for TCU clocks

[Paul Cercueil]

This header provides clock numbers for the ingenic,tcu
DT binding.

Signed-off-by: Paul Cercueil 
Reviewed-by: Rob Herring 
---
 include/dt-bindings/clock/ingenic,tcu.h | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 include/dt-bindings/clock/ingenic,tcu.h

 v2: Use SPDX identifier for the license
 v3: No change
 v4: No change

diff --git a/include/dt-bindings/clock/ingenic,tcu.h 
b/include/dt-bindings/clock/ingenic,tcu.h
new file mode 100644
index ..179815d7b3bb
--- /dev/null
+++ b/include/dt-bindings/clock/ingenic,tcu.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides clock numbers for the ingenic,tcu DT binding.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
+#define __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
+
+#define JZ4740_CLK_TIMER0  0
+#define JZ4740_CLK_TIMER1  1
+#define JZ4740_CLK_TIMER2  2
+#define JZ4740_CLK_TIMER3  3
+#define JZ4740_CLK_TIMER4  4
+#define JZ4740_CLK_TIMER5  5
+#define JZ4740_CLK_TIMER6  6
+#define JZ4740_CLK_TIMER7  7
+#define JZ4740_CLK_WDT 8
+#define JZ4740_CLK_LASTJZ4740_CLK_WDT
+
+#define JZ4770_CLK_OST 9
+#define JZ4770_CLK_LASTJZ4770_CLK_OST
+
+#endif /* __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ */
-- 
2.11.0

[PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

[Paul Cercueil]

This driver will use the TCU (Timer Counter Unit) present on the Ingenic
JZ47xx SoCs to provide the kernel with a clocksource and timers.

Signed-off-by: Paul Cercueil 
---
 drivers/clocksource/Kconfig |   8 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-ingenic.c | 278 
 3 files changed, 287 insertions(+)
 create mode 100644 drivers/clocksource/timer-ingenic.c

 v2: Use SPDX identifier for the license
 v3: - Move documentation to its own patch
 - Search the devicetree for PWM clients, and use all the TCU
   channels that won't be used for PWM
 v4: - Add documentation about why we search for PWM clients
 - Verify that the PWM clients are for the TCU PWM driver

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index d2e5382821a4..481422145fb4 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -592,4 +592,12 @@ config CLKSRC_ST_LPC
  Enable this option to use the Low Power controller timer
  as clocksource.
 
+config INGENIC_TIMER
+   bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
+   depends on MACH_INGENIC || COMPILE_TEST
+   select CLKSRC_OF
+   default y
+   help
+ Support for the timer/counter unit of the Ingenic JZ SoCs.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index d6dec4489d66..98691e8999fe 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -74,5 +74,6 @@ obj-$(CONFIG_ASM9260_TIMER)   += asm9260_timer.o
 obj-$(CONFIG_H8300_TMR8)   += h8300_timer8.o
 obj-$(CONFIG_H8300_TMR16)  += h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
+obj-$(CONFIG_INGENIC_TIMER)+= timer-ingenic.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
diff --git a/drivers/clocksource/timer-ingenic.c 
b/drivers/clocksource/timer-ingenic.c
new file mode 100644
index ..8c777c0c0023
--- /dev/null
+++ b/drivers/clocksource/timer-ingenic.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic JZ47xx SoC TCU clocksource driver
+ * Copyright (C) 2018 Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NUM_CHANNELS   8
+
+struct ingenic_tcu;
+
+struct ingenic_tcu_channel {
+   unsigned int idx;
+   struct clk *clk;
+};
+
+struct ingenic_tcu {
+   struct ingenic_tcu_channel channels[NUM_CHANNELS];
+   unsigned long requested;
+   struct regmap *map;
+};
+
+struct ingenic_clock_event_device {
+   struct clock_event_device cevt;
+   struct ingenic_tcu_channel *channel;
+   char name[32];
+};
+
+#define ingenic_cevt(_evt) \
+   container_of(_evt, struct ingenic_clock_event_device, cevt)
+
+static inline struct ingenic_tcu *to_ingenic_tcu(struct ingenic_tcu_channel 
*ch)
+{
+   return container_of(ch, struct ingenic_tcu, channels[ch->idx]);
+}
+
+static int ingenic_tcu_cevt_set_state_shutdown(struct clock_event_device *evt)
+{
+   struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
+   struct ingenic_tcu_channel *channel = jzcevt->channel;
+   struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+   unsigned int idx = channel->idx;
+
+   regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
+   return 0;
+}
+
+static int ingenic_tcu_cevt_set_next(unsigned long next,
+   struct clock_event_device *evt)
+{
+   struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
+   struct ingenic_tcu_channel *channel = jzcevt->channel;
+   struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+   unsigned int idx = channel->idx;
+
+   if (next > 0x)
+   return -EINVAL;
+
+   regmap_write(tcu->map, TCU_REG_TDFRc(idx), (unsigned int) next);
+   regmap_write(tcu->map, TCU_REG_TCNTc(idx), 0);
+   regmap_write(tcu->map, TCU_REG_TESR, BIT(idx));
+
+   return 0;
+}
+
+static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
+{
+   struct clock_event_device *cevt = dev_id;
+   struct ingenic_clock_event_device *jzcevt = ingenic_cevt(cevt);
+   struct ingenic_tcu_channel *channel = jzcevt->channel;
+   struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+   unsigned int idx = channel->idx;
+
+   regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
+
+   if (cevt->event_handler)
+   cevt->event_handler(cevt);
+
+   return IRQ_HANDLED;
+}
+
+static int __init ingenic_tcu_req_channel(struct ingenic_tcu_channel *channel)
+{
+   struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+   char buf[16];
+   int err;
+
+   if (test_and_set_bit(channel->idx, >requested))
+   return -EBUSY;
+
+   

[PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

[Paul Cercueil]

This driver will use the TCU (Timer Counter Unit) present on the Ingenic
JZ47xx SoCs to provide the kernel with a clocksource and timers.

Signed-off-by: Paul Cercueil 
---
 drivers/clocksource/Kconfig |   8 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-ingenic.c | 278 
 3 files changed, 287 insertions(+)
 create mode 100644 drivers/clocksource/timer-ingenic.c

 v2: Use SPDX identifier for the license
 v3: - Move documentation to its own patch
 - Search the devicetree for PWM clients, and use all the TCU
   channels that won't be used for PWM
 v4: - Add documentation about why we search for PWM clients
 - Verify that the PWM clients are for the TCU PWM driver

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index d2e5382821a4..481422145fb4 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -592,4 +592,12 @@ config CLKSRC_ST_LPC
  Enable this option to use the Low Power controller timer
  as clocksource.
 
+config INGENIC_TIMER
+   bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
+   depends on MACH_INGENIC || COMPILE_TEST
+   select CLKSRC_OF
+   default y
+   help
+ Support for the timer/counter unit of the Ingenic JZ SoCs.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index d6dec4489d66..98691e8999fe 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -74,5 +74,6 @@ obj-$(CONFIG_ASM9260_TIMER)   += asm9260_timer.o
 obj-$(CONFIG_H8300_TMR8)   += h8300_timer8.o
 obj-$(CONFIG_H8300_TMR16)  += h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
+obj-$(CONFIG_INGENIC_TIMER)+= timer-ingenic.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
diff --git a/drivers/clocksource/timer-ingenic.c 
b/drivers/clocksource/timer-ingenic.c
new file mode 100644
index ..8c777c0c0023
--- /dev/null
+++ b/drivers/clocksource/timer-ingenic.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Ingenic JZ47xx SoC TCU clocksource driver
+ * Copyright (C) 2018 Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NUM_CHANNELS   8
+
+struct ingenic_tcu;
+
+struct ingenic_tcu_channel {
+   unsigned int idx;
+   struct clk *clk;
+};
+
+struct ingenic_tcu {
+   struct ingenic_tcu_channel channels[NUM_CHANNELS];
+   unsigned long requested;
+   struct regmap *map;
+};
+
+struct ingenic_clock_event_device {
+   struct clock_event_device cevt;
+   struct ingenic_tcu_channel *channel;
+   char name[32];
+};
+
+#define ingenic_cevt(_evt) \
+   container_of(_evt, struct ingenic_clock_event_device, cevt)
+
+static inline struct ingenic_tcu *to_ingenic_tcu(struct ingenic_tcu_channel 
*ch)
+{
+   return container_of(ch, struct ingenic_tcu, channels[ch->idx]);
+}
+
+static int ingenic_tcu_cevt_set_state_shutdown(struct clock_event_device *evt)
+{
+   struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
+   struct ingenic_tcu_channel *channel = jzcevt->channel;
+   struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+   unsigned int idx = channel->idx;
+
+   regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
+   return 0;
+}
+
+static int ingenic_tcu_cevt_set_next(unsigned long next,
+   struct clock_event_device *evt)
+{
+   struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
+   struct ingenic_tcu_channel *channel = jzcevt->channel;
+   struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+   unsigned int idx = channel->idx;
+
+   if (next > 0x)
+   return -EINVAL;
+
+   regmap_write(tcu->map, TCU_REG_TDFRc(idx), (unsigned int) next);
+   regmap_write(tcu->map, TCU_REG_TCNTc(idx), 0);
+   regmap_write(tcu->map, TCU_REG_TESR, BIT(idx));
+
+   return 0;
+}
+
+static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
+{
+   struct clock_event_device *cevt = dev_id;
+   struct ingenic_clock_event_device *jzcevt = ingenic_cevt(cevt);
+   struct ingenic_tcu_channel *channel = jzcevt->channel;
+   struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+   unsigned int idx = channel->idx;
+
+   regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
+
+   if (cevt->event_handler)
+   cevt->event_handler(cevt);
+
+   return IRQ_HANDLED;
+}
+
+static int __init ingenic_tcu_req_channel(struct ingenic_tcu_channel *channel)
+{
+   struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
+   char buf[16];
+   int err;
+
+   if (test_and_set_bit(channel->idx, >requested))
+   return -EBUSY;
+
+   snprintf(buf, sizeof(buf), "timer%u", channel->idx);
+   

[PATCH v4 8/8] MAINTAINERS: Add myself as maintainer for Ingenic TCU drivers

[Paul Cercueil]

Add myself as maintainer for the ingenic-tcu-intc interrupt controller
driver, the ingenic-tcu-clocks clock driver, and the ingenic-tcu
clocksource driver.

Signed-off-by: Paul Cercueil 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

 v2: No change
 v3: No change
 v4: No change

diff --git a/MAINTAINERS b/MAINTAINERS
index 4623caf8d72d..46d3955b92aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6959,6 +6959,15 @@ L:   linux-...@lists.infradead.org
 S: Maintained
 F: drivers/mtd/nand/jz4780_*
 
+INGENIC JZ47xx TCU drivers
+M: Paul Cercueil 
+S: Maintained
+F: drivers/clk/ingenic/tcu.c
+F: drivers/irqchip/irq-ingenic-tcu.c
+F: drivers/clocksource/timer-ingenic.c
+F: include/linux/mfd/syscon/ingenic-tcu.h
+F: include/dt-bindings/clock/ingenic,tcu.h
+
 INOTIFY
 M: Jan Kara 
 R: Amir Goldstein 
-- 
2.11.0

[PATCH v4 8/8] MAINTAINERS: Add myself as maintainer for Ingenic TCU drivers

[Paul Cercueil]

Add myself as maintainer for the ingenic-tcu-intc interrupt controller
driver, the ingenic-tcu-clocks clock driver, and the ingenic-tcu
clocksource driver.

Signed-off-by: Paul Cercueil 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

 v2: No change
 v3: No change
 v4: No change

diff --git a/MAINTAINERS b/MAINTAINERS
index 4623caf8d72d..46d3955b92aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6959,6 +6959,15 @@ L:   linux-...@lists.infradead.org
 S: Maintained
 F: drivers/mtd/nand/jz4780_*
 
+INGENIC JZ47xx TCU drivers
+M: Paul Cercueil 
+S: Maintained
+F: drivers/clk/ingenic/tcu.c
+F: drivers/irqchip/irq-ingenic-tcu.c
+F: drivers/clocksource/timer-ingenic.c
+F: include/linux/mfd/syscon/ingenic-tcu.h
+F: include/dt-bindings/clock/ingenic,tcu.h
+
 INOTIFY
 M: Jan Kara 
 R: Amir Goldstein 
-- 
2.11.0

[PATCH v4 5/8] irqchip: Add the ingenic-tcu-intc driver

[Paul Cercueil]

This simple driver handles the IRQ chip of the TCU
(Timer Counter Unit) of the JZ47xx Ingenic SoCs.

Signed-off-by: Paul Cercueil 
---
 drivers/irqchip/Kconfig   |   6 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-ingenic-tcu.c | 161 ++
 3 files changed, 168 insertions(+)
 create mode 100644 drivers/irqchip/irq-ingenic-tcu.c

 v2: - Use SPDX identifier for the license
 - Make KConfig option select CONFIG_IRQ_DOMAIN since we depend on it
 v3: - Move documentation to its own patch
 - Add comment explaining why we only use IRQCHIP_DECLARE
 v4: - Rename variables to avoid splitting long lines
 - Add comment about the multiple IRQ parents

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index d913aec85109..2b56587d04ed 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -267,6 +267,12 @@ config INGENIC_IRQ
depends on MACH_INGENIC
default y
 
+config INGENIC_TCU_IRQ
+   bool
+   depends on MACH_INGENIC || COMPILE_TEST
+   select IRQ_DOMAIN
+   default y
+
 config RENESAS_H8300H_INTC
 bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index d27e3e3619e0..48b0bdf2b1a2 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
 obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
 obj-$(CONFIG_ARCH_SA1100)  += irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)  += irq-ingenic.o
+obj-$(CONFIG_INGENIC_TCU_IRQ)  += irq-ingenic-tcu.o
 obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)   += irq-pic32-evic.o
 obj-$(CONFIG_MVEBU_GICP)   += irq-mvebu-gicp.o
diff --git a/drivers/irqchip/irq-ingenic-tcu.c 
b/drivers/irqchip/irq-ingenic-tcu.c
new file mode 100644
index ..add3e9cc6f82
--- /dev/null
+++ b/drivers/irqchip/irq-ingenic-tcu.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ47xx SoCs TCU IRQ driver
+ * Copyright (C) 2018 Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static void ingenic_tcu_intc_cascade(struct irq_desc *desc)
+{
+   struct irq_chip *irq_chip = irq_data_get_irq_chip(>irq_data);
+   struct irq_domain *domain = irq_desc_get_handler_data(desc);
+   struct irq_chip_generic *gc = irq_get_domain_generic_chip(domain, 0);
+   struct regmap *map = gc->private;
+   uint32_t irq_reg, irq_mask;
+   unsigned int i;
+
+   regmap_read(map, TCU_REG_TFR, _reg);
+   regmap_read(map, TCU_REG_TMR, _mask);
+
+   chained_irq_enter(irq_chip, desc);
+
+   irq_reg &= ~irq_mask;
+
+   for (i = 0; i < 32; i++) {
+   if (irq_reg & BIT(i))
+   generic_handle_irq(irq_linear_revmap(domain, i));
+   }
+
+   chained_irq_exit(irq_chip, desc);
+}
+
+static void ingenic_tcu_gc_unmask_enable_reg(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   struct regmap *map = gc->private;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   regmap_write(map, ct->regs.ack, mask);
+   regmap_write(map, ct->regs.enable, mask);
+   *ct->mask_cache |= mask;
+   irq_gc_unlock(gc);
+}
+
+static void ingenic_tcu_gc_mask_disable_reg(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   struct regmap *map = gc->private;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   regmap_write(map, ct->regs.disable, mask);
+   *ct->mask_cache &= ~mask;
+   irq_gc_unlock(gc);
+}
+
+static void ingenic_tcu_gc_mask_disable_reg_and_ack(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   struct regmap *map = gc->private;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   regmap_write(map, ct->regs.ack, mask);
+   regmap_write(map, ct->regs.disable, mask);
+   irq_gc_unlock(gc);
+}
+
+static int __init ingenic_tcu_intc_of_init(struct device_node *node,
+   struct device_node *parent)
+{
+   struct irq_domain *domain;
+   struct irq_chip_generic *gc;
+   struct irq_chip_type *ct;
+   int err, i, irqs;
+   u32 parent_irqs[3];
+   struct regmap *map;
+
+   irqs = of_property_count_elems_of_size(node, "interrupts", sizeof(u32));
+   if (irqs < 0 || irqs > ARRAY_SIZE(parent_irqs))
+   return -EINVAL;
+
+   map = syscon_node_to_regmap(node->parent);
+   if (IS_ERR(map))
+   return PTR_ERR(map);
+
+   domain = 

[PATCH v4 5/8] irqchip: Add the ingenic-tcu-intc driver

[Paul Cercueil]

This simple driver handles the IRQ chip of the TCU
(Timer Counter Unit) of the JZ47xx Ingenic SoCs.

Signed-off-by: Paul Cercueil 
---
 drivers/irqchip/Kconfig   |   6 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-ingenic-tcu.c | 161 ++
 3 files changed, 168 insertions(+)
 create mode 100644 drivers/irqchip/irq-ingenic-tcu.c

 v2: - Use SPDX identifier for the license
 - Make KConfig option select CONFIG_IRQ_DOMAIN since we depend on it
 v3: - Move documentation to its own patch
 - Add comment explaining why we only use IRQCHIP_DECLARE
 v4: - Rename variables to avoid splitting long lines
 - Add comment about the multiple IRQ parents

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index d913aec85109..2b56587d04ed 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -267,6 +267,12 @@ config INGENIC_IRQ
depends on MACH_INGENIC
default y
 
+config INGENIC_TCU_IRQ
+   bool
+   depends on MACH_INGENIC || COMPILE_TEST
+   select IRQ_DOMAIN
+   default y
+
 config RENESAS_H8300H_INTC
 bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index d27e3e3619e0..48b0bdf2b1a2 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
 obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
 obj-$(CONFIG_ARCH_SA1100)  += irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)  += irq-ingenic.o
+obj-$(CONFIG_INGENIC_TCU_IRQ)  += irq-ingenic-tcu.o
 obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)   += irq-pic32-evic.o
 obj-$(CONFIG_MVEBU_GICP)   += irq-mvebu-gicp.o
diff --git a/drivers/irqchip/irq-ingenic-tcu.c 
b/drivers/irqchip/irq-ingenic-tcu.c
new file mode 100644
index ..add3e9cc6f82
--- /dev/null
+++ b/drivers/irqchip/irq-ingenic-tcu.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ47xx SoCs TCU IRQ driver
+ * Copyright (C) 2018 Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static void ingenic_tcu_intc_cascade(struct irq_desc *desc)
+{
+   struct irq_chip *irq_chip = irq_data_get_irq_chip(>irq_data);
+   struct irq_domain *domain = irq_desc_get_handler_data(desc);
+   struct irq_chip_generic *gc = irq_get_domain_generic_chip(domain, 0);
+   struct regmap *map = gc->private;
+   uint32_t irq_reg, irq_mask;
+   unsigned int i;
+
+   regmap_read(map, TCU_REG_TFR, _reg);
+   regmap_read(map, TCU_REG_TMR, _mask);
+
+   chained_irq_enter(irq_chip, desc);
+
+   irq_reg &= ~irq_mask;
+
+   for (i = 0; i < 32; i++) {
+   if (irq_reg & BIT(i))
+   generic_handle_irq(irq_linear_revmap(domain, i));
+   }
+
+   chained_irq_exit(irq_chip, desc);
+}
+
+static void ingenic_tcu_gc_unmask_enable_reg(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   struct regmap *map = gc->private;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   regmap_write(map, ct->regs.ack, mask);
+   regmap_write(map, ct->regs.enable, mask);
+   *ct->mask_cache |= mask;
+   irq_gc_unlock(gc);
+}
+
+static void ingenic_tcu_gc_mask_disable_reg(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   struct regmap *map = gc->private;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   regmap_write(map, ct->regs.disable, mask);
+   *ct->mask_cache &= ~mask;
+   irq_gc_unlock(gc);
+}
+
+static void ingenic_tcu_gc_mask_disable_reg_and_ack(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   struct regmap *map = gc->private;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   regmap_write(map, ct->regs.ack, mask);
+   regmap_write(map, ct->regs.disable, mask);
+   irq_gc_unlock(gc);
+}
+
+static int __init ingenic_tcu_intc_of_init(struct device_node *node,
+   struct device_node *parent)
+{
+   struct irq_domain *domain;
+   struct irq_chip_generic *gc;
+   struct irq_chip_type *ct;
+   int err, i, irqs;
+   u32 parent_irqs[3];
+   struct regmap *map;
+
+   irqs = of_property_count_elems_of_size(node, "interrupts", sizeof(u32));
+   if (irqs < 0 || irqs > ARRAY_SIZE(parent_irqs))
+   return -EINVAL;
+
+   map = syscon_node_to_regmap(node->parent);
+   if (IS_ERR(map))
+   return PTR_ERR(map);
+
+   domain = irq_domain_add_linear(node, 32, _generic_chip_ops, NULL);
+   

[PATCH v4 0/8] Ingenic JZ47xx Timer/Counter Unit drivers

[Paul Cercueil]

Hi,

This is the 4th version of my TCU patchset.

The major change is a greatly improved documentation, both in-code
and as separate text files, to describe how the hardware works and
how the devicetree bindings should be used.

There are also cosmetic changes in the irqchip driver, and the
clocksource driver will now use as timers all TCU channels not
requested by the TCU PWM driver.

Cheers,
-Paul

[PATCH v4 1/8] mfd: syscon: Add ingenic-tcu.h header

[Paul Cercueil]

This header contains macros for the registers that are present in the
regmap shared by all the drivers related to the TCU (Timer Counter Unit)
of the Ingenic JZ47xx SoCs.

Signed-off-by: Paul Cercueil 
Acked-by: Lee Jones 
---
 include/linux/mfd/syscon/ingenic-tcu.h | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 include/linux/mfd/syscon/ingenic-tcu.h

 v2: Use SPDX identifier for the license
 v3: - Use macros instead of enum
 - Add 'TCU_' at the beginning of each macro
 - Remove useless include 
 v4: No change

diff --git a/include/linux/mfd/syscon/ingenic-tcu.h 
b/include/linux/mfd/syscon/ingenic-tcu.h
new file mode 100644
index ..96dd59f7c3b2
--- /dev/null
+++ b/include/linux/mfd/syscon/ingenic-tcu.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Header file for the Ingenic JZ47xx TCU driver
+ */
+#ifndef __LINUX_CLK_INGENIC_TCU_H_
+#define __LINUX_CLK_INGENIC_TCU_H_
+
+#include 
+
+#define TCU_REG_WDT_TDR0x00
+#define TCU_REG_WDT_TCER   0x04
+#define TCU_REG_WDT_TCNT   0x08
+#define TCU_REG_WDT_TCSR   0x0c
+#define TCU_REG_TER0x10
+#define TCU_REG_TESR   0x14
+#define TCU_REG_TECR   0x18
+#define TCU_REG_TSR0x1c
+#define TCU_REG_TFR0x20
+#define TCU_REG_TFSR   0x24
+#define TCU_REG_TFCR   0x28
+#define TCU_REG_TSSR   0x2c
+#define TCU_REG_TMR0x30
+#define TCU_REG_TMSR   0x34
+#define TCU_REG_TMCR   0x38
+#define TCU_REG_TSCR   0x3c
+#define TCU_REG_TDFR0  0x40
+#define TCU_REG_TDHR0  0x44
+#define TCU_REG_TCNT0  0x48
+#define TCU_REG_TCSR0  0x4c
+#define TCU_REG_OST_DR 0xe0
+#define TCU_REG_OST_CNTL   0xe4
+#define TCU_REG_OST_CNTH   0xe8
+#define TCU_REG_OST_TCSR   0xec
+#define TCU_REG_TSTR   0xf0
+#define TCU_REG_TSTSR  0xf4
+#define TCU_REG_TSTCR  0xf8
+#define TCU_REG_OST_CNTHBUF0xfc
+
+#define TCU_TCSR_RESERVED_BITS 0x3f
+#define TCU_TCSR_PARENT_CLOCK_MASK 0x07
+#define TCU_TCSR_PRESCALE_LSB  3
+#define TCU_TCSR_PRESCALE_MASK 0x38
+
+#define TCU_TCSR_PWM_SDBIT(9)  /* 0: Shutdown abruptly 1: 
gracefully */
+#define TCU_TCSR_PWM_INITL_HIGHBIT(8)  /* Sets the initial output 
level */
+#define TCU_TCSR_PWM_ENBIT(7)  /* PWM pin output enable */
+
+#define TCU_CHANNEL_STRIDE 0x10
+#define TCU_REG_TDFRc(c)   (TCU_REG_TDFR0 + ((c) * TCU_CHANNEL_STRIDE))
+#define TCU_REG_TDHRc(c)   (TCU_REG_TDHR0 + ((c) * TCU_CHANNEL_STRIDE))
+#define TCU_REG_TCNTc(c)   (TCU_REG_TCNT0 + ((c) * TCU_CHANNEL_STRIDE))
+#define TCU_REG_TCSRc(c)   (TCU_REG_TCSR0 + ((c) * TCU_CHANNEL_STRIDE))
+
+#endif /* __LINUX_CLK_INGENIC_TCU_H_ */
-- 
2.11.0

[PATCH v4 0/8] Ingenic JZ47xx Timer/Counter Unit drivers

[Paul Cercueil]

Hi,

This is the 4th version of my TCU patchset.

The major change is a greatly improved documentation, both in-code
and as separate text files, to describe how the hardware works and
how the devicetree bindings should be used.

There are also cosmetic changes in the irqchip driver, and the
clocksource driver will now use as timers all TCU channels not
requested by the TCU PWM driver.

Cheers,
-Paul

[PATCH v4 1/8] mfd: syscon: Add ingenic-tcu.h header

[Paul Cercueil]

This header contains macros for the registers that are present in the
regmap shared by all the drivers related to the TCU (Timer Counter Unit)
of the Ingenic JZ47xx SoCs.

Signed-off-by: Paul Cercueil 
Acked-by: Lee Jones 
---
 include/linux/mfd/syscon/ingenic-tcu.h | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 include/linux/mfd/syscon/ingenic-tcu.h

 v2: Use SPDX identifier for the license
 v3: - Use macros instead of enum
 - Add 'TCU_' at the beginning of each macro
 - Remove useless include 
 v4: No change

diff --git a/include/linux/mfd/syscon/ingenic-tcu.h 
b/include/linux/mfd/syscon/ingenic-tcu.h
new file mode 100644
index ..96dd59f7c3b2
--- /dev/null
+++ b/include/linux/mfd/syscon/ingenic-tcu.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Header file for the Ingenic JZ47xx TCU driver
+ */
+#ifndef __LINUX_CLK_INGENIC_TCU_H_
+#define __LINUX_CLK_INGENIC_TCU_H_
+
+#include 
+
+#define TCU_REG_WDT_TDR0x00
+#define TCU_REG_WDT_TCER   0x04
+#define TCU_REG_WDT_TCNT   0x08
+#define TCU_REG_WDT_TCSR   0x0c
+#define TCU_REG_TER0x10
+#define TCU_REG_TESR   0x14
+#define TCU_REG_TECR   0x18
+#define TCU_REG_TSR0x1c
+#define TCU_REG_TFR0x20
+#define TCU_REG_TFSR   0x24
+#define TCU_REG_TFCR   0x28
+#define TCU_REG_TSSR   0x2c
+#define TCU_REG_TMR0x30
+#define TCU_REG_TMSR   0x34
+#define TCU_REG_TMCR   0x38
+#define TCU_REG_TSCR   0x3c
+#define TCU_REG_TDFR0  0x40
+#define TCU_REG_TDHR0  0x44
+#define TCU_REG_TCNT0  0x48
+#define TCU_REG_TCSR0  0x4c
+#define TCU_REG_OST_DR 0xe0
+#define TCU_REG_OST_CNTL   0xe4
+#define TCU_REG_OST_CNTH   0xe8
+#define TCU_REG_OST_TCSR   0xec
+#define TCU_REG_TSTR   0xf0
+#define TCU_REG_TSTSR  0xf4
+#define TCU_REG_TSTCR  0xf8
+#define TCU_REG_OST_CNTHBUF0xfc
+
+#define TCU_TCSR_RESERVED_BITS 0x3f
+#define TCU_TCSR_PARENT_CLOCK_MASK 0x07
+#define TCU_TCSR_PRESCALE_LSB  3
+#define TCU_TCSR_PRESCALE_MASK 0x38
+
+#define TCU_TCSR_PWM_SDBIT(9)  /* 0: Shutdown abruptly 1: 
gracefully */
+#define TCU_TCSR_PWM_INITL_HIGHBIT(8)  /* Sets the initial output 
level */
+#define TCU_TCSR_PWM_ENBIT(7)  /* PWM pin output enable */
+
+#define TCU_CHANNEL_STRIDE 0x10
+#define TCU_REG_TDFRc(c)   (TCU_REG_TDFR0 + ((c) * TCU_CHANNEL_STRIDE))
+#define TCU_REG_TDHRc(c)   (TCU_REG_TDHR0 + ((c) * TCU_CHANNEL_STRIDE))
+#define TCU_REG_TCNTc(c)   (TCU_REG_TCNT0 + ((c) * TCU_CHANNEL_STRIDE))
+#define TCU_REG_TCSRc(c)   (TCU_REG_TCSR0 + ((c) * TCU_CHANNEL_STRIDE))
+
+#endif /* __LINUX_CLK_INGENIC_TCU_H_ */
-- 
2.11.0

[PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers

[Paul Cercueil]

Add documentation about how to properly use the Ingenic TCU
(Timer/Counter Unit) drivers from devicetree.

Signed-off-by: Paul Cercueil 
---
 .../bindings/clock/ingenic,tcu-clocks.txt  | 42 
 .../bindings/interrupt-controller/ingenic,tcu.txt  | 39 +++
 .../devicetree/bindings/mfd/ingenic,tcu.txt| 56 ++
 .../devicetree/bindings/timer/ingenic,tcu.txt  | 41 
 4 files changed, 178 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
 create mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.txt

 v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
 added content.

diff --git a/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt 
b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
new file mode 100644
index ..471d27078599
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
@@ -0,0 +1,42 @@
+Ingenic SoC TCU binding
+
+The TCU is the Timer/Counter Unit present in all Ingenic SoCs. It features 8
+channels, each one having its own clock, that can be started and stopped,
+reparented, and reclocked.
+
+Required properties:
+- compatible : One of:
+  * ingenic,jz4740-tcu-clocks,
+  * ingenic,jz4770-tcu-clocks,
+  * ingenic,jz4780-tcu-clocks.
+- clocks : List of phandle & clock specifiers for clocks external to the TCU.
+  The "pclk", "rtc" and "ext" clocks should be provided.
+- clock-names : List of name strings for the external clocks.
+- #clock-cells: Should be 1.
+  Clock consumers specify this argument to identify a clock. The valid values
+  may be found in .
+
+Example:
+
+/ {
+   tcu: mfd@10002000 {
+   compatible = "ingenic,tcu", "simple-mfd", "syscon";
+   reg = <0x10002000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x10002000 0x1000>;
+
+   tcu_clk: clocks@10 {
+   compatible = "ingenic,jz4740-tcu-clocks";
+   reg = <0x10 0xff0>;
+
+   clocks = <>, <>, <>;
+   clock-names = "ext", "rtc", "pclk";
+
+   #clock-cells = <1>;
+   };
+   };
+};
+
+For information about the top-level "ingenic,tcu" compatible node and other
+children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt 
b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
new file mode 100644
index ..7f3af2da77cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
@@ -0,0 +1,39 @@
+Ingenic SoCs Timer/Counter Unit Interrupt Controller
+
+Required properties:
+
+- compatible : should be "ingenic,-tcu-intc". Valid strings are:
+  * ingenic,jz4740-tcu-intc
+  * ingenic,jz4770-tcu-intc
+  * ingenic,jz4780-tcu-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+- interrupt-parent : phandle of the interrupt controller.
+- interrupts : Specifies the interrupt the controller is connected to.
+
+Example:
+
+/ {
+   tcu: mfd@10002000 {
+   compatible = "ingenic,tcu", "simple-mfd", "syscon";
+   reg = <0x10002000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x10002000 0x1000>;
+
+   tcu_irq: interrupt-controller@20 {
+   compatible = "ingenic,jz4740-tcu-intc";
+   reg = <0x20 0x20>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <>;
+   interrupts = <15>;
+   };
+   };
+};
+
+For information about the top-level "ingenic,tcu" compatible node and other
+children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
diff --git a/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt 
b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
new file mode 100644
index ..5742c3f21550
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
@@ -0,0 +1,56 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
+--
+
+For a description of the TCU hardware and drivers, have a look at
+Documentation/mips/ingenic-tcu.txt.
+
+The TCU is implemented as a parent node, whose role is to create the
+regmap, and child nodes for the various drivers listed in the aforementioned

[PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers

[Paul Cercueil]

Add documentation about how to properly use the Ingenic TCU
(Timer/Counter Unit) drivers from devicetree.

Signed-off-by: Paul Cercueil 
---
 .../bindings/clock/ingenic,tcu-clocks.txt  | 42 
 .../bindings/interrupt-controller/ingenic,tcu.txt  | 39 +++
 .../devicetree/bindings/mfd/ingenic,tcu.txt| 56 ++
 .../devicetree/bindings/timer/ingenic,tcu.txt  | 41 
 4 files changed, 178 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
 create mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.txt

 v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
 added content.

diff --git a/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt 
b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
new file mode 100644
index ..471d27078599
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
@@ -0,0 +1,42 @@
+Ingenic SoC TCU binding
+
+The TCU is the Timer/Counter Unit present in all Ingenic SoCs. It features 8
+channels, each one having its own clock, that can be started and stopped,
+reparented, and reclocked.
+
+Required properties:
+- compatible : One of:
+  * ingenic,jz4740-tcu-clocks,
+  * ingenic,jz4770-tcu-clocks,
+  * ingenic,jz4780-tcu-clocks.
+- clocks : List of phandle & clock specifiers for clocks external to the TCU.
+  The "pclk", "rtc" and "ext" clocks should be provided.
+- clock-names : List of name strings for the external clocks.
+- #clock-cells: Should be 1.
+  Clock consumers specify this argument to identify a clock. The valid values
+  may be found in .
+
+Example:
+
+/ {
+   tcu: mfd@10002000 {
+   compatible = "ingenic,tcu", "simple-mfd", "syscon";
+   reg = <0x10002000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x10002000 0x1000>;
+
+   tcu_clk: clocks@10 {
+   compatible = "ingenic,jz4740-tcu-clocks";
+   reg = <0x10 0xff0>;
+
+   clocks = <>, <>, <>;
+   clock-names = "ext", "rtc", "pclk";
+
+   #clock-cells = <1>;
+   };
+   };
+};
+
+For information about the top-level "ingenic,tcu" compatible node and other
+children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt 
b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
new file mode 100644
index ..7f3af2da77cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
@@ -0,0 +1,39 @@
+Ingenic SoCs Timer/Counter Unit Interrupt Controller
+
+Required properties:
+
+- compatible : should be "ingenic,-tcu-intc". Valid strings are:
+  * ingenic,jz4740-tcu-intc
+  * ingenic,jz4770-tcu-intc
+  * ingenic,jz4780-tcu-intc
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+- interrupt-parent : phandle of the interrupt controller.
+- interrupts : Specifies the interrupt the controller is connected to.
+
+Example:
+
+/ {
+   tcu: mfd@10002000 {
+   compatible = "ingenic,tcu", "simple-mfd", "syscon";
+   reg = <0x10002000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x10002000 0x1000>;
+
+   tcu_irq: interrupt-controller@20 {
+   compatible = "ingenic,jz4740-tcu-intc";
+   reg = <0x20 0x20>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <>;
+   interrupts = <15>;
+   };
+   };
+};
+
+For information about the top-level "ingenic,tcu" compatible node and other
+children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
diff --git a/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt 
b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
new file mode 100644
index ..5742c3f21550
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
@@ -0,0 +1,56 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
+--
+
+For a description of the TCU hardware and drivers, have a look at
+Documentation/mips/ingenic-tcu.txt.
+
+The TCU is implemented as a parent node, whose role is to create the
+regmap, and child nodes for the various drivers listed in the aforementioned
+document.
+
+Required 

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

[Ram Pai]

On Fri, Mar 16, 2018 at 02:46:56PM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen 
> 
> mm_pkey_is_allocated() treats pkey 0 as unallocated.  That is
> inconsistent with the manpages, and also inconsistent with
> mm->context.pkey_allocation_map.  Stop special casing it and only
> disallow values that are actually bad (< 0).
> 
> The end-user visible effect of this is that you can now use
> mprotect_pkey() to set pkey=0.
> 
> This is a bit nicer than what Ram proposed because it is simpler
> and removes special-casing for pkey 0.  On the other hand, it does
> allow applciations to pkey_free() pkey-0, but that's just a silly
> thing to do, so we are not going to protect against it.

So your proposal 
(a) allocates pkey 0 implicitly, 
(b) does not stop anyone from freeing pkey-0
(c) and allows pkey-0 to be explicitly associated with any address range.
correct?

My proposal
(a) allocates pkey 0 implicitly, 
(b) stops anyone from freeing pkey-0
(c) and allows pkey-0 to be explicitly associated with any address range.

So the difference between the two proposals is just the freeing part i.e (b).
Did I get this right?

Its a philosophical debate; allow the user
to shoot-in-the-feet or stop from not doing so. There is no 
clear answer either way. I am fine either way.

So here is my

Reviewed-by: Ram Pai 

I will write a corresponding patch for powerpc.

> 
> Signed-off-by: Dave Hansen 
> Cc: Ram Pai 
> Cc: Thomas Gleixner 
> Cc: Dave Hansen 
> Cc: Michael Ellermen 
> Cc: Ingo Molnar 
> Cc: Andrew Morton p
> Cc: Shuah Khan 
> ---
> 
>  b/arch/x86/include/asm/mmu_context.h |2 +-
>  b/arch/x86/include/asm/pkeys.h   |6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff -puN arch/x86/include/asm/mmu_context.h~x86-pkey-0-default-allocated 
> arch/x86/include/asm/mmu_context.h
> --- a/arch/x86/include/asm/mmu_context.h~x86-pkey-0-default-allocated 
> 2018-03-16 14:46:39.023285476 -0700
> +++ b/arch/x86/include/asm/mmu_context.h  2018-03-16 14:46:39.028285476 
> -0700
> @@ -191,7 +191,7 @@ static inline int init_new_context(struc
> 
>  #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
>   if (cpu_feature_enabled(X86_FEATURE_OSPKE)) {
> - /* pkey 0 is the default and always allocated */
> + /* pkey 0 is the default and allocated implicitly */
>   mm->context.pkey_allocation_map = 0x1;
>   /* -1 means unallocated or invalid */
>   mm->context.execute_only_pkey = -1;
> diff -puN arch/x86/include/asm/pkeys.h~x86-pkey-0-default-allocated 
> arch/x86/include/asm/pkeys.h
> --- a/arch/x86/include/asm/pkeys.h~x86-pkey-0-default-allocated   
> 2018-03-16 14:46:39.025285476 -0700
> +++ b/arch/x86/include/asm/pkeys.h2018-03-16 14:46:39.028285476 -0700
> @@ -49,10 +49,10 @@ bool mm_pkey_is_allocated(struct mm_stru
>  {
>   /*
>* "Allocated" pkeys are those that have been returned
> -  * from pkey_alloc().  pkey 0 is special, and never
> -  * returned from pkey_alloc().
> +  * from pkey_alloc() or pkey 0 which is allocated
> +  * implicitly when the mm is created.
>*/
> - if (pkey <= 0)
> + if (pkey < 0)
>   return false;
>   if (pkey >= arch_max_pkey())
>   return false;
> _

-- 
Ram Pai

Re: [PATCH 1/3] x86, pkeys: do not special case protection key 0

[Ram Pai]

On Fri, Mar 16, 2018 at 02:46:56PM -0700, Dave Hansen wrote:
> 
> From: Dave Hansen 
> 
> mm_pkey_is_allocated() treats pkey 0 as unallocated.  That is
> inconsistent with the manpages, and also inconsistent with
> mm->context.pkey_allocation_map.  Stop special casing it and only
> disallow values that are actually bad (< 0).
> 
> The end-user visible effect of this is that you can now use
> mprotect_pkey() to set pkey=0.
> 
> This is a bit nicer than what Ram proposed because it is simpler
> and removes special-casing for pkey 0.  On the other hand, it does
> allow applciations to pkey_free() pkey-0, but that's just a silly
> thing to do, so we are not going to protect against it.

So your proposal 
(a) allocates pkey 0 implicitly, 
(b) does not stop anyone from freeing pkey-0
(c) and allows pkey-0 to be explicitly associated with any address range.
correct?

My proposal
(a) allocates pkey 0 implicitly, 
(b) stops anyone from freeing pkey-0
(c) and allows pkey-0 to be explicitly associated with any address range.

So the difference between the two proposals is just the freeing part i.e (b).
Did I get this right?

Its a philosophical debate; allow the user
to shoot-in-the-feet or stop from not doing so. There is no 
clear answer either way. I am fine either way.

So here is my

Reviewed-by: Ram Pai 

I will write a corresponding patch for powerpc.

> 
> Signed-off-by: Dave Hansen 
> Cc: Ram Pai 
> Cc: Thomas Gleixner 
> Cc: Dave Hansen 
> Cc: Michael Ellermen 
> Cc: Ingo Molnar 
> Cc: Andrew Morton p
> Cc: Shuah Khan 
> ---
> 
>  b/arch/x86/include/asm/mmu_context.h |2 +-
>  b/arch/x86/include/asm/pkeys.h   |6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff -puN arch/x86/include/asm/mmu_context.h~x86-pkey-0-default-allocated 
> arch/x86/include/asm/mmu_context.h
> --- a/arch/x86/include/asm/mmu_context.h~x86-pkey-0-default-allocated 
> 2018-03-16 14:46:39.023285476 -0700
> +++ b/arch/x86/include/asm/mmu_context.h  2018-03-16 14:46:39.028285476 
> -0700
> @@ -191,7 +191,7 @@ static inline int init_new_context(struc
> 
>  #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
>   if (cpu_feature_enabled(X86_FEATURE_OSPKE)) {
> - /* pkey 0 is the default and always allocated */
> + /* pkey 0 is the default and allocated implicitly */
>   mm->context.pkey_allocation_map = 0x1;
>   /* -1 means unallocated or invalid */
>   mm->context.execute_only_pkey = -1;
> diff -puN arch/x86/include/asm/pkeys.h~x86-pkey-0-default-allocated 
> arch/x86/include/asm/pkeys.h
> --- a/arch/x86/include/asm/pkeys.h~x86-pkey-0-default-allocated   
> 2018-03-16 14:46:39.025285476 -0700
> +++ b/arch/x86/include/asm/pkeys.h2018-03-16 14:46:39.028285476 -0700
> @@ -49,10 +49,10 @@ bool mm_pkey_is_allocated(struct mm_stru
>  {
>   /*
>* "Allocated" pkeys are those that have been returned
> -  * from pkey_alloc().  pkey 0 is special, and never
> -  * returned from pkey_alloc().
> +  * from pkey_alloc() or pkey 0 which is allocated
> +  * implicitly when the mm is created.
>*/
> - if (pkey <= 0)
> + if (pkey < 0)
>   return false;
>   if (pkey >= arch_max_pkey())
>   return false;
> _

-- 
Ram Pai

Re: linux-next: build failure after merge of the y2038 tree

[Deepa Dinamani]

I posted the patch.

The patch has simple changes. Let me know if maybe posting a new
version makes sense.

I also needed this patch to build linux-next:

commit b784c76bb7c1c440a4ce06a18f4b3a936f33967d
Author: Deepa Dinamani 
Date:   Fri Mar 16 20:57:10 2018 -0700

i40iw: add missing irq.h include

iwarp driver began using irq_get_affinity_mask in commit 7e952b19eb638.
Add the needed include irq.h to get the definition.

This was found while trying allmodconfig for arm64, s390, and sparc.

Signed-off-by: Deepa Dinamani 

diff --git a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
index a51798578f27..506b10e8ea4e 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -32,6 +32,7 @@
 *
 
***/

+#include 
 #include 
 #include 
 #include 

-Deepa

On Fri, Mar 16, 2018 at 1:14 AM, Arnd Bergmann  wrote:
> On Fri, Mar 16, 2018 at 6:23 AM, Deepa Dinamani  
> wrote:
>> Hi Arnd,
>>
>> Do you want me to send the fix as a patch or should I re-post the series?
>
> Please send a fix relative to linux-next. Due to my travel next week, I might
> not be able to apply it right away but maybe Stephen can add it on top until
> I get back.
>
>   Arnd
>
>> On Thu, Mar 15, 2018 at 7:25 PM, Stephen Rothwell  
>> wrote:
>>> Hi Arnd,
>>>
>>> After merging the y2038 tree, today's linux-next build (s390 allnoconfig)
>>> failed like this:
>>>
>>> In file included from include/linux/elf.h:5:0,
>>>  from include/linux/module.h:15,
>>>  from init/main.c:16:
>>> arch/s390/include/asm/elf.h:138:1: error: unknown type name 
>>> 's390_compat_regs'
>>>
>>> Caused by commit
>>>
>>>   f00689038f71 ("include: Move compat_timespec/ timeval to compat_time.h")
>>>

Re: linux-next: build failure after merge of the y2038 tree

[Deepa Dinamani]

I posted the patch.

The patch has simple changes. Let me know if maybe posting a new
version makes sense.

I also needed this patch to build linux-next:

commit b784c76bb7c1c440a4ce06a18f4b3a936f33967d
Author: Deepa Dinamani 
Date:   Fri Mar 16 20:57:10 2018 -0700

i40iw: add missing irq.h include

iwarp driver began using irq_get_affinity_mask in commit 7e952b19eb638.
Add the needed include irq.h to get the definition.

This was found while trying allmodconfig for arm64, s390, and sparc.

Signed-off-by: Deepa Dinamani 

diff --git a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
index a51798578f27..506b10e8ea4e 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
@@ -32,6 +32,7 @@
 *
 
***/

+#include 
 #include 
 #include 
 #include 

-Deepa

On Fri, Mar 16, 2018 at 1:14 AM, Arnd Bergmann  wrote:
> On Fri, Mar 16, 2018 at 6:23 AM, Deepa Dinamani  
> wrote:
>> Hi Arnd,
>>
>> Do you want me to send the fix as a patch or should I re-post the series?
>
> Please send a fix relative to linux-next. Due to my travel next week, I might
> not be able to apply it right away but maybe Stephen can add it on top until
> I get back.
>
>   Arnd
>
>> On Thu, Mar 15, 2018 at 7:25 PM, Stephen Rothwell  
>> wrote:
>>> Hi Arnd,
>>>
>>> After merging the y2038 tree, today's linux-next build (s390 allnoconfig)
>>> failed like this:
>>>
>>> In file included from include/linux/elf.h:5:0,
>>>  from include/linux/module.h:15,
>>>  from init/main.c:16:
>>> arch/s390/include/asm/elf.h:138:1: error: unknown type name 
>>> 's390_compat_regs'
>>>
>>> Caused by commit
>>>
>>>   f00689038f71 ("include: Move compat_timespec/ timeval to compat_time.h")
>>>

[PATCH] s390: Use asm/compat.h instead of linux/compat.h

[Deepa Dinamani]

Include asm/compat.h directly for uses of compat_ptr.
This includes the compat defines when CONFIG_COMPAT is
not on.

Also make compat data structure definitions conditional on
CONFIG_COMPAT, to remove circular include dependencies in
elf.h

Cc: David Hildenbrand 
Cc: linux-s...@vger.kernel.org
Signed-off-by: Deepa Dinamani 
---
 arch/s390/hypfs/hypfs_sprp.c  | 1 +
 arch/s390/include/asm/compat.h| 1 +
 arch/s390/include/asm/elf.h   | 2 ++
 arch/s390/kvm/priv.c  | 2 +-
 arch/s390/pci/pci_clp.c   | 1 +
 drivers/s390/block/dasd_ioctl.c   | 2 +-
 drivers/s390/char/fs3270.c| 2 +-
 drivers/s390/char/sclp_ctl.c  | 1 +
 drivers/s390/char/vmcp.c  | 1 +
 drivers/s390/cio/chsc_sch.c   | 2 +-
 drivers/s390/net/qeth_core_main.c | 2 +-
 11 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/s390/hypfs/hypfs_sprp.c b/arch/s390/hypfs/hypfs_sprp.c
index 5d85a039391c..d800b8067042 100644
--- a/arch/s390/hypfs/hypfs_sprp.c
+++ b/arch/s390/hypfs/hypfs_sprp.c
@@ -7,6 +7,7 @@
  *Author(s): Martin Schwidefsky 
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index 501aaff85304..1832d98c9328 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -4,6 +4,7 @@
 /*
  * Architecture specific compatibility types
  */
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h
index 7d22a474a040..e572ae613b19 100644
--- a/arch/s390/include/asm/elf.h
+++ b/arch/s390/include/asm/elf.h
@@ -134,8 +134,10 @@
 typedef s390_fp_regs elf_fpregset_t;
 typedef s390_regs elf_gregset_t;
 
+#ifdef CONFIG_COMPAT
 typedef s390_fp_regs compat_elf_fpregset_t;
 typedef s390_compat_regs compat_elf_gregset_t;
+#endif
 
 #include /* for task_struct */
 #include 
diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
index a3bce0e84346..b7e6d81547bd 100644
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/arch/s390/pci/pci_clp.c b/arch/s390/pci/pci_clp.c
index 19b2d2a9b43d..4b6fe97823b7 100644
--- a/arch/s390/pci/pci_clp.c
+++ b/arch/s390/pci/pci_clp.c
@@ -9,6 +9,7 @@
 #define KMSG_COMPONENT "zpci"
 #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/block/dasd_ioctl.c b/drivers/s390/block/dasd_ioctl.c
index 2016e0ed5865..288fa9d4d105 100644
--- a/drivers/s390/block/dasd_ioctl.c
+++ b/drivers/s390/block/dasd_ioctl.c
@@ -13,7 +13,7 @@
 #define KMSG_COMPONENT "dasd"
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/char/fs3270.c b/drivers/s390/char/fs3270.c
index 16a4e8528bbc..cf4a26c6f76d 100644
--- a/drivers/s390/char/fs3270.c
+++ b/drivers/s390/char/fs3270.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/char/sclp_ctl.c b/drivers/s390/char/sclp_ctl.c
index 248b5db3eaa8..bd0d9e5cabd7 100644
--- a/drivers/s390/char/sclp_ctl.c
+++ b/drivers/s390/char/sclp_ctl.c
@@ -7,6 +7,7 @@
  * Author: Michael Holzheu 
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/char/vmcp.c b/drivers/s390/char/vmcp.c
index 948ce82a7725..0a153741ea88 100644
--- a/drivers/s390/char/vmcp.c
+++ b/drivers/s390/char/vmcp.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/cio/chsc_sch.c b/drivers/s390/cio/chsc_sch.c
index 8d9f36625ba5..3a541e694cb1 100644
--- a/drivers/s390/cio/chsc_sch.c
+++ b/drivers/s390/cio/chsc_sch.c
@@ -9,7 +9,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/net/qeth_core_main.c 
b/drivers/s390/net/qeth_core_main.c
index d3529ef6e0f7..adde6b30bad6 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -10,7 +10,7 @@
 #define KMSG_COMPONENT "qeth"
 #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.14.1

[PATCH] s390: Use asm/compat.h instead of linux/compat.h

[Deepa Dinamani]

Include asm/compat.h directly for uses of compat_ptr.
This includes the compat defines when CONFIG_COMPAT is
not on.

Also make compat data structure definitions conditional on
CONFIG_COMPAT, to remove circular include dependencies in
elf.h

Cc: David Hildenbrand 
Cc: linux-s...@vger.kernel.org
Signed-off-by: Deepa Dinamani 
---
 arch/s390/hypfs/hypfs_sprp.c  | 1 +
 arch/s390/include/asm/compat.h| 1 +
 arch/s390/include/asm/elf.h   | 2 ++
 arch/s390/kvm/priv.c  | 2 +-
 arch/s390/pci/pci_clp.c   | 1 +
 drivers/s390/block/dasd_ioctl.c   | 2 +-
 drivers/s390/char/fs3270.c| 2 +-
 drivers/s390/char/sclp_ctl.c  | 1 +
 drivers/s390/char/vmcp.c  | 1 +
 drivers/s390/cio/chsc_sch.c   | 2 +-
 drivers/s390/net/qeth_core_main.c | 2 +-
 11 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/s390/hypfs/hypfs_sprp.c b/arch/s390/hypfs/hypfs_sprp.c
index 5d85a039391c..d800b8067042 100644
--- a/arch/s390/hypfs/hypfs_sprp.c
+++ b/arch/s390/hypfs/hypfs_sprp.c
@@ -7,6 +7,7 @@
  *Author(s): Martin Schwidefsky 
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index 501aaff85304..1832d98c9328 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -4,6 +4,7 @@
 /*
  * Architecture specific compatibility types
  */
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h
index 7d22a474a040..e572ae613b19 100644
--- a/arch/s390/include/asm/elf.h
+++ b/arch/s390/include/asm/elf.h
@@ -134,8 +134,10 @@
 typedef s390_fp_regs elf_fpregset_t;
 typedef s390_regs elf_gregset_t;
 
+#ifdef CONFIG_COMPAT
 typedef s390_fp_regs compat_elf_fpregset_t;
 typedef s390_compat_regs compat_elf_gregset_t;
+#endif
 
 #include /* for task_struct */
 #include 
diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
index a3bce0e84346..b7e6d81547bd 100644
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -11,7 +11,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/arch/s390/pci/pci_clp.c b/arch/s390/pci/pci_clp.c
index 19b2d2a9b43d..4b6fe97823b7 100644
--- a/arch/s390/pci/pci_clp.c
+++ b/arch/s390/pci/pci_clp.c
@@ -9,6 +9,7 @@
 #define KMSG_COMPONENT "zpci"
 #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/block/dasd_ioctl.c b/drivers/s390/block/dasd_ioctl.c
index 2016e0ed5865..288fa9d4d105 100644
--- a/drivers/s390/block/dasd_ioctl.c
+++ b/drivers/s390/block/dasd_ioctl.c
@@ -13,7 +13,7 @@
 #define KMSG_COMPONENT "dasd"
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/char/fs3270.c b/drivers/s390/char/fs3270.c
index 16a4e8528bbc..cf4a26c6f76d 100644
--- a/drivers/s390/char/fs3270.c
+++ b/drivers/s390/char/fs3270.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/char/sclp_ctl.c b/drivers/s390/char/sclp_ctl.c
index 248b5db3eaa8..bd0d9e5cabd7 100644
--- a/drivers/s390/char/sclp_ctl.c
+++ b/drivers/s390/char/sclp_ctl.c
@@ -7,6 +7,7 @@
  * Author: Michael Holzheu 
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/char/vmcp.c b/drivers/s390/char/vmcp.c
index 948ce82a7725..0a153741ea88 100644
--- a/drivers/s390/char/vmcp.c
+++ b/drivers/s390/char/vmcp.c
@@ -14,6 +14,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/cio/chsc_sch.c b/drivers/s390/cio/chsc_sch.c
index 8d9f36625ba5..3a541e694cb1 100644
--- a/drivers/s390/cio/chsc_sch.c
+++ b/drivers/s390/cio/chsc_sch.c
@@ -9,7 +9,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/s390/net/qeth_core_main.c 
b/drivers/s390/net/qeth_core_main.c
index d3529ef6e0f7..adde6b30bad6 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -10,7 +10,7 @@
 #define KMSG_COMPONENT "qeth"
 #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.14.1

Re: [PATCH v4.16-rc5 2/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

[Andi Kleen]

On Sat, Mar 17, 2018 at 02:29:34PM +, jason.vas.d...@gmail.com wrote:
>  This patch allows compilation to succeed with compilers that support 
> -DRETPOLINE -
>  it was kindly contributed by H.J. Liu in GCC Bugzilla: 84908 :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
> 
>  Apparently the GCC retpoline implementation has a limitation that it 
> cannot
>  handle switch statements with more than 5 clauses, which 
> vclock_gettime.c's
>  __vdso_clock_gettime function now conts.

That's quite a mischaracterization of the issue. gcc works as intended,
but the kernel did not correctly supply a indirect call retpoline thunk
to the vdso, and it just happened to work by accident with the old
vdso.

> 
>  The automated test builds should now succeed with this patch.

How about just adding the thunk function to the vdso object instead of
this cheap hack? 

The other option would be to build vdso with inline thunks.

But just disabling is completely the wrong action.

-Andi


> 
> 
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 1943aeb..cb64e10 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -76,7 +76,7 @@ CFL := $(PROFILING) -mcmodel=small -fPIC -O2 
> -fasynchronous-unwind-tables -m64 \
> -fno-omit-frame-pointer -foptimize-sibling-calls \
> -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
>  
> -$(vobjs): KBUILD_CFLAGS := $(filter-out 
> $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
> +$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) 
> $(RETPOLINE_CFLAGS) -DRETPOLINE,$(KBUILD_CFLAGS)) $(CFL)
>  
>  #
>  # vDSO code runs in userspace and -pg doesn't help with profiling anyway.
> @@ -143,6 +143,7 @@ KBUILD_CFLAGS_32 := $(filter-out 
> -mcmodel=kernel,$(KBUILD_CFLAGS_32))
>  KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
>  KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
>  KBUILD_CFLAGS_32 := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS_32))
> +KBUILD_CFLAGS_32 := $(filter-out $(RETPOLINE_CFLAGS) 
> -DRETPOLINE,$(KBUILD_CFLAGS_32))
>  KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
>  KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
>  KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
> 

Re: [PATCH v4.16-rc5 2/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

[Andi Kleen]

On Sat, Mar 17, 2018 at 02:29:34PM +, jason.vas.d...@gmail.com wrote:
>  This patch allows compilation to succeed with compilers that support 
> -DRETPOLINE -
>  it was kindly contributed by H.J. Liu in GCC Bugzilla: 84908 :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
> 
>  Apparently the GCC retpoline implementation has a limitation that it 
> cannot
>  handle switch statements with more than 5 clauses, which 
> vclock_gettime.c's
>  __vdso_clock_gettime function now conts.

That's quite a mischaracterization of the issue. gcc works as intended,
but the kernel did not correctly supply a indirect call retpoline thunk
to the vdso, and it just happened to work by accident with the old
vdso.

> 
>  The automated test builds should now succeed with this patch.

How about just adding the thunk function to the vdso object instead of
this cheap hack? 

The other option would be to build vdso with inline thunks.

But just disabling is completely the wrong action.

-Andi


> 
> 
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 1943aeb..cb64e10 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -76,7 +76,7 @@ CFL := $(PROFILING) -mcmodel=small -fPIC -O2 
> -fasynchronous-unwind-tables -m64 \
> -fno-omit-frame-pointer -foptimize-sibling-calls \
> -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
>  
> -$(vobjs): KBUILD_CFLAGS := $(filter-out 
> $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
> +$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) 
> $(RETPOLINE_CFLAGS) -DRETPOLINE,$(KBUILD_CFLAGS)) $(CFL)
>  
>  #
>  # vDSO code runs in userspace and -pg doesn't help with profiling anyway.
> @@ -143,6 +143,7 @@ KBUILD_CFLAGS_32 := $(filter-out 
> -mcmodel=kernel,$(KBUILD_CFLAGS_32))
>  KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
>  KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
>  KBUILD_CFLAGS_32 := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS_32))
> +KBUILD_CFLAGS_32 := $(filter-out $(RETPOLINE_CFLAGS) 
> -DRETPOLINE,$(KBUILD_CFLAGS_32))
>  KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
>  KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
>  KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
> 

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

[Josh Poimboeuf]

On Sat, Mar 17, 2018 at 01:07:32PM -0700, Kees Cook wrote:
> On Sat, Mar 17, 2018 at 11:52 AM, Linus Torvalds
>  wrote:
> > So the above is completely insane, bit there is actually a chance that
> > using that completely crazy "x -> sizeof(char[x])" conversion actually
> > helps, because it really does have a (very odd) evaluation-time
> > change.  sizeof() has to be evaluated as part of the constant
> > expression evaluation, in ways that "__builtin_constant_p()" isn't
> > specified to be done.
> >
> > But it is also definitely me grasping at straws. If that doesn't work
> > for 4.4, there's nothing else I can possibly see.
> 
> No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only
> does it not change the complaint about __builtin_choose_expr(), it
> also thinks that's a VLA now.
> 
> ./include/linux/mm.h: In function ‘get_mm_hiwater_rss’:
> ./include/linux/mm.h:1567: warning: variable length array is used
> ./include/linux/mm.h:1567: error: first argument to
> ‘__builtin_choose_expr’ not a constant
> 
> 6.8 is happy with it (of course).
> 
> I do think the earlier version (without the
> sizeof-hiding-builting_constant_p) provides a template for a
> const_max() that both you and Rasmus would be happy with, though!

I thought we were dropping support for 4.4 (for other reasons).  Isn't
it 4.6 we should be looking at?

-- 
Josh

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

[Josh Poimboeuf]

On Sat, Mar 17, 2018 at 01:07:32PM -0700, Kees Cook wrote:
> On Sat, Mar 17, 2018 at 11:52 AM, Linus Torvalds
>  wrote:
> > So the above is completely insane, bit there is actually a chance that
> > using that completely crazy "x -> sizeof(char[x])" conversion actually
> > helps, because it really does have a (very odd) evaluation-time
> > change.  sizeof() has to be evaluated as part of the constant
> > expression evaluation, in ways that "__builtin_constant_p()" isn't
> > specified to be done.
> >
> > But it is also definitely me grasping at straws. If that doesn't work
> > for 4.4, there's nothing else I can possibly see.
> 
> No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only
> does it not change the complaint about __builtin_choose_expr(), it
> also thinks that's a VLA now.
> 
> ./include/linux/mm.h: In function ‘get_mm_hiwater_rss’:
> ./include/linux/mm.h:1567: warning: variable length array is used
> ./include/linux/mm.h:1567: error: first argument to
> ‘__builtin_choose_expr’ not a constant
> 
> 6.8 is happy with it (of course).
> 
> I do think the earlier version (without the
> sizeof-hiding-builting_constant_p) provides a template for a
> const_max() that both you and Rasmus would be happy with, though!

I thought we were dropping support for 4.4 (for other reasons).  Isn't
it 4.6 we should be looking at?

-- 
Josh

re: [PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

[Jason Vas Dias]

Hi -

I submitted a new stripped-down to bare essentials version of
the patch, (see LKML emails with $subject)  which passes all
checkpatch.pl tests and addresses all concerns raised by reviewers,
which uses only rdtsc_ordered(), and which only only updates in
  vsyscall_gtod_data the new fields:
u32 raw_mult,  raw_shift ; ...
gtod_long_t  monotonic_time_raw_sec   /* == tk->raw_sec */ ,
  monotonic_time_raw_nsec /* == tk->tkr_raw.nsec */;
(this is NOT the formatting used in vgtod.h - sorry about previous
 formatting issues .
) .

I don't see how one could present the raw timespec in user-space
properly without tk->tkr_raw.xtime_nsec and and tk->raw_sec ;
monotonic has gtod->monotonic_time_sec and gtod->monotonic_time_snsec,
and I am only trying to follow exactly the existing algorithm in
timekeeping.c's
getrawmonotonic64() .

When I submitted the initial version of this stripped down patch,
I got an email back from robot reporting a compilation
error saying :

>
>   arch/x86/entry/vdso/vclock_gettime.o: In function `__vdso_clock_gettime':
>   vclock_gettime.c:(.text+0xf7): undefined reference to 
> >`__x86_indirect_thunk_rax'
>   /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_PC32 
> >against undefined symbol `__x86_indirect_thunk_rax' can not be used when 
> making >a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Bad value
>>> collect2: error: ld returned 1 exit status
>--
>>> arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
>--
>>> objcopy: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
>---


I had fixed this problem with the patch to the RHEL kernel attached to
bug #198161 (attachment #274751:
https://bugzilla.kernel.org/attachment.cgi?id=274751) ,
 by simply reducing the number of clauses in __vdso_clock_gettime's
switch(clock) from 6 to 5 , but at the cost of an extra test of clock
& second switch(clock).

I reported this as GCC bug :
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
because I don't think GCC should fail to do anything
for a switch with 6 clauses and not for one with 5, but
the response I got from H.J. Liu was:

H.J. Lu wrote @ 2018-03-16 22:13:27 UTC:
>
> vDSO isn't compiled with $(KBUILD_CFLAGS).  Why does your kernel do it?
>
> Please try my kernel patch at comment 4..
>

So that patch to the arch/x86/vdso/Makefile only prevents it enabling the
RETPOLINE_CFLAGS for building  the vDSO .

I defer to H.J.'s expertise on GCC + binutils & advisability of enabling
RETPOLINE_CFLAGS in the VDSO - GCC definitely behaves strangely
for the vDSO when RETPOLINE _CFLAGS  are enabled.

Please provide something like the patch in a future version of Linux ,
and I suggest not compiling the vDSO with RETPOLINE_CFLAGS
as does H.J. .

The inconsistency_check program in tools/testing/selftests/timers produces
no errors for long runs and the timer_latency.c program (attached) also
produces no errors and latencies of @ 20ns for CLOCK_MONOTONIC_RAW
and latencies of @ 40ns for CLOCK_MONOTONIC - this is however
with the additional rdtscp patches , and under 4.15.9, for use on my system ;
the 4.16-rc5 version submitted still uses barrier() + rdtsc  , and
that has  a latency
of @ 30ns for CLOCK_MONOTONIC_RAW and @40ns for CLOCK_MONOTONIC ; but
both are much, much better that
200-1000ns for CLOCK_MONOTONIC_RAW that the unpatched
kernels have (all times refer to 'Average Latency' output produced
by 'timer_latency.c').

I do apologize for whitespace errors, unread emails and resends and confusion
of previous emails - I now understand the process and standards much better
and will attempt to adhere to them more closely in future.

Thanks & Best Regards,
Jason Vas Dias
/* 
 * Program to measure high-res timer latency.
 *
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifndef N_SAMPLES
#define N_SAMPLES 100
#endif
#define _STR(_S_) #_S_
#define STR(_S_) _STR(_S_)

#define TS2NS(_TS_) unsigned long long)(_TS_).tv_sec)*10ULL) + (((unsigned long long)((_TS_).tv_nsec 

int main(int argc, char *const* argv, char *const* envp)
{ struct timespec sample[N_SAMPLES+1];
  unsigned int cnt=N_SAMPLES, s=0 , avg_n=0;
  unsigned long long
deltas [ N_SAMPLES ]
, t1, t2, sum=0, zd=0, ic=0, d
, t_start, avg_ns, *avgs=0;
  clockid_t clk = CLOCK_MONOTONIC_RAW;
  bool do_dump = false;
  int argn=1, repeat=1;
  for(; argn < argc; argn+=1)
if( argv[argn] != NULL )
  if( *(argv[argn]) == '-')
	switch( *(argv[argn]+1) )
	{ case 'm':
	  case 'M':
	clk = CLOCK_MONOTONIC;
	break;
	  case 'd':
	  case 'D':
	do_dump = true;
	break;
 	  case 'r':
  	  case 'R':
	if( (argn < argc) && (argv[argn+1] != NULL))
	  repeat = atoi(argv[argn+=1]);
	break;
	  case '?':
	  case 'h':
	  case 'u':
	  case 'U':
	  case 'H':
	fprintf(stderr,"Usage: timer_latency [\n\t-m : use CLOCK_MONOTONIC clock (not 

re: [PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

[Jason Vas Dias]

Hi -

I submitted a new stripped-down to bare essentials version of
the patch, (see LKML emails with $subject)  which passes all
checkpatch.pl tests and addresses all concerns raised by reviewers,
which uses only rdtsc_ordered(), and which only only updates in
  vsyscall_gtod_data the new fields:
u32 raw_mult,  raw_shift ; ...
gtod_long_t  monotonic_time_raw_sec   /* == tk->raw_sec */ ,
  monotonic_time_raw_nsec /* == tk->tkr_raw.nsec */;
(this is NOT the formatting used in vgtod.h - sorry about previous
 formatting issues .
) .

I don't see how one could present the raw timespec in user-space
properly without tk->tkr_raw.xtime_nsec and and tk->raw_sec ;
monotonic has gtod->monotonic_time_sec and gtod->monotonic_time_snsec,
and I am only trying to follow exactly the existing algorithm in
timekeeping.c's
getrawmonotonic64() .

When I submitted the initial version of this stripped down patch,
I got an email back from robot reporting a compilation
error saying :

>
>   arch/x86/entry/vdso/vclock_gettime.o: In function `__vdso_clock_gettime':
>   vclock_gettime.c:(.text+0xf7): undefined reference to 
> >`__x86_indirect_thunk_rax'
>   /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_PC32 
> >against undefined symbol `__x86_indirect_thunk_rax' can not be used when 
> making >a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Bad value
>>> collect2: error: ld returned 1 exit status
>--
>>> arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
>--
>>> objcopy: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
>---


I had fixed this problem with the patch to the RHEL kernel attached to
bug #198161 (attachment #274751:
https://bugzilla.kernel.org/attachment.cgi?id=274751) ,
 by simply reducing the number of clauses in __vdso_clock_gettime's
switch(clock) from 6 to 5 , but at the cost of an extra test of clock
& second switch(clock).

I reported this as GCC bug :
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
because I don't think GCC should fail to do anything
for a switch with 6 clauses and not for one with 5, but
the response I got from H.J. Liu was:

H.J. Lu wrote @ 2018-03-16 22:13:27 UTC:
>
> vDSO isn't compiled with $(KBUILD_CFLAGS).  Why does your kernel do it?
>
> Please try my kernel patch at comment 4..
>

So that patch to the arch/x86/vdso/Makefile only prevents it enabling the
RETPOLINE_CFLAGS for building  the vDSO .

I defer to H.J.'s expertise on GCC + binutils & advisability of enabling
RETPOLINE_CFLAGS in the VDSO - GCC definitely behaves strangely
for the vDSO when RETPOLINE _CFLAGS  are enabled.

Please provide something like the patch in a future version of Linux ,
and I suggest not compiling the vDSO with RETPOLINE_CFLAGS
as does H.J. .

The inconsistency_check program in tools/testing/selftests/timers produces
no errors for long runs and the timer_latency.c program (attached) also
produces no errors and latencies of @ 20ns for CLOCK_MONOTONIC_RAW
and latencies of @ 40ns for CLOCK_MONOTONIC - this is however
with the additional rdtscp patches , and under 4.15.9, for use on my system ;
the 4.16-rc5 version submitted still uses barrier() + rdtsc  , and
that has  a latency
of @ 30ns for CLOCK_MONOTONIC_RAW and @40ns for CLOCK_MONOTONIC ; but
both are much, much better that
200-1000ns for CLOCK_MONOTONIC_RAW that the unpatched
kernels have (all times refer to 'Average Latency' output produced
by 'timer_latency.c').

I do apologize for whitespace errors, unread emails and resends and confusion
of previous emails - I now understand the process and standards much better
and will attempt to adhere to them more closely in future.

Thanks & Best Regards,
Jason Vas Dias
/* 
 * Program to measure high-res timer latency.
 *
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifndef N_SAMPLES
#define N_SAMPLES 100
#endif
#define _STR(_S_) #_S_
#define STR(_S_) _STR(_S_)

#define TS2NS(_TS_) unsigned long long)(_TS_).tv_sec)*10ULL) + (((unsigned long long)((_TS_).tv_nsec 

int main(int argc, char *const* argv, char *const* envp)
{ struct timespec sample[N_SAMPLES+1];
  unsigned int cnt=N_SAMPLES, s=0 , avg_n=0;
  unsigned long long
deltas [ N_SAMPLES ]
, t1, t2, sum=0, zd=0, ic=0, d
, t_start, avg_ns, *avgs=0;
  clockid_t clk = CLOCK_MONOTONIC_RAW;
  bool do_dump = false;
  int argn=1, repeat=1;
  for(; argn < argc; argn+=1)
if( argv[argn] != NULL )
  if( *(argv[argn]) == '-')
	switch( *(argv[argn]+1) )
	{ case 'm':
	  case 'M':
	clk = CLOCK_MONOTONIC;
	break;
	  case 'd':
	  case 'D':
	do_dump = true;
	break;
 	  case 'r':
  	  case 'R':
	if( (argn < argc) && (argv[argn+1] != NULL))
	  repeat = atoi(argv[argn+=1]);
	break;
	  case '?':
	  case 'h':
	  case 'u':
	  case 'U':
	  case 'H':
	fprintf(stderr,"Usage: timer_latency [\n\t-m : use CLOCK_MONOTONIC clock (not CLOCK_MONOTONIC_RAW)\n\t-d : 

Re: [PATCH 0/2] iio: stm32-dfsdm-adc: fix filter & rate setting

[Jonathan Cameron]

On Fri, 16 Mar 2018 10:10:09 +0100
Arnaud Pouliquen  wrote:

> Hello,
> 
> For the series:
> Acked-by: Arnaud Pouliquen 
Both applied and marked for stable (as I'm not sure exactly when this will hit
mainline and it may be after the next merge window)

Thanks,

Jonathan

> 
> Thanks,
> Arnaud
> 
> On 03/13/2018 03:23 PM, Fabrice Gasnier wrote:
> > This series brings fixes to STM32 DFSDM ADC driver.
> > 
> > Fabrice Gasnier (2):
> >   iio: adc: stm32-dfsdm: fix successive oversampling settings
> >   iio: adc: stm32-dfsdm: fix sample rate for div2 spi clock
> > 
> >  drivers/iio/adc/stm32-dfsdm-adc.c | 17 ++---
> >  1 file changed, 14 insertions(+), 3 deletions(-)
> >   

Re: [PATCH 0/2] iio: stm32-dfsdm-adc: fix filter & rate setting

[Jonathan Cameron]

On Fri, 16 Mar 2018 10:10:09 +0100
Arnaud Pouliquen  wrote:

> Hello,
> 
> For the series:
> Acked-by: Arnaud Pouliquen 
Both applied and marked for stable (as I'm not sure exactly when this will hit
mainline and it may be after the next merge window)

Thanks,

Jonathan

> 
> Thanks,
> Arnaud
> 
> On 03/13/2018 03:23 PM, Fabrice Gasnier wrote:
> > This series brings fixes to STM32 DFSDM ADC driver.
> > 
> > Fabrice Gasnier (2):
> >   iio: adc: stm32-dfsdm: fix successive oversampling settings
> >   iio: adc: stm32-dfsdm: fix sample rate for div2 spi clock
> > 
> >  drivers/iio/adc/stm32-dfsdm-adc.c | 17 ++---
> >  1 file changed, 14 insertions(+), 3 deletions(-)
> >   

Re: [PATCH] iio/accel/kxcjk-1013: Improve unlocking of a mutex in three functions

[Jonathan Cameron]

On Tue, 13 Mar 2018 13:47:20 +0100
SF Markus Elfring  wrote:

> From: Markus Elfring 
> Date: Tue, 13 Mar 2018 13:40:12 +0100
> 
> * Add jump targets so that a call of the function "mutex_unlock" is stored
>   less often in these function implementations.
> 
> * Replace eight calls by goto statements.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
A few minor comments inline, but at first glance at least these look
to be fine in principle.

Jonathan

> ---
>  drivers/iio/accel/kxcjk-1013.c | 46 
> ++
>  1 file changed, 20 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
> index af53a1084ee5..4adf38b6d939 100644
> --- a/drivers/iio/accel/kxcjk-1013.c
> +++ b/drivers/iio/accel/kxcjk-1013.c
> @@ -765,19 +765,18 @@ static int kxcjk1013_read_raw(struct iio_dev *indio_dev,
>   ret = -EBUSY;
>   else {
>   ret = kxcjk1013_set_power_state(data, true);
> - if (ret < 0) {
> - mutex_unlock(>mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
> +
>   ret = kxcjk1013_get_acc_reg(data, chan->scan_index);
>   if (ret < 0) {
>   kxcjk1013_set_power_state(data, false);
> - mutex_unlock(>mutex);
> - return ret;
> + goto unlock;
>   }
>   *val = sign_extend32(ret >> 4, 11);
>   ret = kxcjk1013_set_power_state(data, false);
>   }
> +unlock:
>   mutex_unlock(>mutex);
>  
>   if (ret < 0)
> @@ -905,8 +904,8 @@ static int kxcjk1013_write_event_config(struct iio_dev 
> *indio_dev,
>  
>   if (!state && data->motion_trigger_on) {
>   data->ev_enable_state = 0;
> - mutex_unlock(>mutex);
> - return 0;
> + ret = 0;
do this where it is orginally defined rather than here.

int ret = 0;
> + goto unlock;
>   }
>  
>   /*
> @@ -919,23 +918,20 @@ static int kxcjk1013_write_event_config(struct iio_dev 
> *indio_dev,
>* is always on so sequence doesn't matter
>*/
>   ret = kxcjk1013_set_power_state(data, state);
> - if (ret < 0) {
> - mutex_unlock(>mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
>  
>   ret =  kxcjk1013_setup_any_motion_interrupt(data, state);
>   if (ret < 0) {
>   kxcjk1013_set_power_state(data, false);
>   data->ev_enable_state = 0;
> - mutex_unlock(>mutex);
> - return ret;
> + goto unlock;
>   }
>  
>   data->ev_enable_state = state;
> +unlock:
>   mutex_unlock(>mutex);
> -
> - return 0;
> + return ret;
>  }
>  
>  static int kxcjk1013_buffer_preenable(struct iio_dev *indio_dev)
> @@ -1086,32 +1082,30 @@ static int 
> kxcjk1013_data_rdy_trigger_set_state(struct iio_trigger *trig,
>  
>   if (!state && data->ev_enable_state && data->motion_trigger_on) {
>   data->motion_trigger_on = false;
> - mutex_unlock(>mutex);
> - return 0;
> + ret = 0;
> + goto unlock;
>   }
>  
>   ret = kxcjk1013_set_power_state(data, state);
> - if (ret < 0) {
> - mutex_unlock(>mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
> +
>   if (data->motion_trig == trig)
>   ret = kxcjk1013_setup_any_motion_interrupt(data, state);
>   else
>   ret = kxcjk1013_setup_new_data_interrupt(data, state);
>   if (ret < 0) {
>   kxcjk1013_set_power_state(data, false);
> - mutex_unlock(>mutex);
> - return ret;
> + goto unlock;
>   }
>   if (data->motion_trig == trig)
>   data->motion_trigger_on = state;
>   else
>   data->dready_trigger_on = state;
>  
> +unlock:
>   mutex_unlock(>mutex);
> -
Please leave the blank line.  It makes it slightly easier for the eye
to pick up on the return.

> - return 0;
> + return ret;
>  }
>  
>  static const struct iio_trigger_ops kxcjk1013_trigger_ops = {

Re: [PATCH] iio/accel/kxcjk-1013: Improve unlocking of a mutex in three functions

[Jonathan Cameron]

On Tue, 13 Mar 2018 13:47:20 +0100
SF Markus Elfring  wrote:

> From: Markus Elfring 
> Date: Tue, 13 Mar 2018 13:40:12 +0100
> 
> * Add jump targets so that a call of the function "mutex_unlock" is stored
>   less often in these function implementations.
> 
> * Replace eight calls by goto statements.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
A few minor comments inline, but at first glance at least these look
to be fine in principle.

Jonathan

> ---
>  drivers/iio/accel/kxcjk-1013.c | 46 
> ++
>  1 file changed, 20 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
> index af53a1084ee5..4adf38b6d939 100644
> --- a/drivers/iio/accel/kxcjk-1013.c
> +++ b/drivers/iio/accel/kxcjk-1013.c
> @@ -765,19 +765,18 @@ static int kxcjk1013_read_raw(struct iio_dev *indio_dev,
>   ret = -EBUSY;
>   else {
>   ret = kxcjk1013_set_power_state(data, true);
> - if (ret < 0) {
> - mutex_unlock(>mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
> +
>   ret = kxcjk1013_get_acc_reg(data, chan->scan_index);
>   if (ret < 0) {
>   kxcjk1013_set_power_state(data, false);
> - mutex_unlock(>mutex);
> - return ret;
> + goto unlock;
>   }
>   *val = sign_extend32(ret >> 4, 11);
>   ret = kxcjk1013_set_power_state(data, false);
>   }
> +unlock:
>   mutex_unlock(>mutex);
>  
>   if (ret < 0)
> @@ -905,8 +904,8 @@ static int kxcjk1013_write_event_config(struct iio_dev 
> *indio_dev,
>  
>   if (!state && data->motion_trigger_on) {
>   data->ev_enable_state = 0;
> - mutex_unlock(>mutex);
> - return 0;
> + ret = 0;
do this where it is orginally defined rather than here.

int ret = 0;
> + goto unlock;
>   }
>  
>   /*
> @@ -919,23 +918,20 @@ static int kxcjk1013_write_event_config(struct iio_dev 
> *indio_dev,
>* is always on so sequence doesn't matter
>*/
>   ret = kxcjk1013_set_power_state(data, state);
> - if (ret < 0) {
> - mutex_unlock(>mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
>  
>   ret =  kxcjk1013_setup_any_motion_interrupt(data, state);
>   if (ret < 0) {
>   kxcjk1013_set_power_state(data, false);
>   data->ev_enable_state = 0;
> - mutex_unlock(>mutex);
> - return ret;
> + goto unlock;
>   }
>  
>   data->ev_enable_state = state;
> +unlock:
>   mutex_unlock(>mutex);
> -
> - return 0;
> + return ret;
>  }
>  
>  static int kxcjk1013_buffer_preenable(struct iio_dev *indio_dev)
> @@ -1086,32 +1082,30 @@ static int 
> kxcjk1013_data_rdy_trigger_set_state(struct iio_trigger *trig,
>  
>   if (!state && data->ev_enable_state && data->motion_trigger_on) {
>   data->motion_trigger_on = false;
> - mutex_unlock(>mutex);
> - return 0;
> + ret = 0;
> + goto unlock;
>   }
>  
>   ret = kxcjk1013_set_power_state(data, state);
> - if (ret < 0) {
> - mutex_unlock(>mutex);
> - return ret;
> - }
> + if (ret < 0)
> + goto unlock;
> +
>   if (data->motion_trig == trig)
>   ret = kxcjk1013_setup_any_motion_interrupt(data, state);
>   else
>   ret = kxcjk1013_setup_new_data_interrupt(data, state);
>   if (ret < 0) {
>   kxcjk1013_set_power_state(data, false);
> - mutex_unlock(>mutex);
> - return ret;
> + goto unlock;
>   }
>   if (data->motion_trig == trig)
>   data->motion_trigger_on = state;
>   else
>   data->dready_trigger_on = state;
>  
> +unlock:
>   mutex_unlock(>mutex);
> -
Please leave the blank line.  It makes it slightly easier for the eye
to pick up on the return.

> - return 0;
> + return ret;
>  }
>  
>  static const struct iio_trigger_ops kxcjk1013_trigger_ops = {

Re: Plan to move cdc:ad7746 driver out of staging

[Jonathan Cameron]

On Mon, 12 Mar 2018 16:25:52 -0300
Hernán Gonzalez  wrote:

> Hi,
> 
> This is my plan for moving out the ad7746 driver out of staging. I
> have some specific questions that would be really helpful if someone
> can point me in the right direction to go.
> 
> 1. Pick up on David's clean-up patch. Finish cleaning CHECKs from
> checkpatch.pl if possible.
> 
> 2. Reorder includes alphabetically.
> 
> 3. Reorder some variable declarations in an inverse-pyramid scheme.
> 
> 4. Fix sysfs attrs naming to comply with the ABI, e.g.:
> in_capacitance0_calibbias_calibration -> in_capacitance0_calibbias
Take a careful look at what these are doing before you do that :)
Then consider what the usecases are.  If we need to, we may need
to add new ABI to cover the requirement.

> 
> 5. Add documentation to the {cap,vt}_filter_rate tables and to the
> processed info read. There are some magic numbers out there, I will
> read the datasheet and explain the math that I consider appropiate.
> 
> 6. There are a few too many defines that are not used at all but they
> do follow the datasheet. I don't know if there are plans to keep
> adding functionalities to this driver or if I should just remove them.
> 
> 8. EXCLVL is duplicated. There's a simple macro in ad7746.c and some
> defines in ad7746.h. The latter are not used anywhere in the code.
> Remove them.
> 
> 7. Move the struct ad7746_platform_data to include/linux/iio.
> 
> As mentioned in earlier mails, I will avoid adding new features as I
> have no access to the hardware and, therefore, could not test it.
Michael has stated he has at least some of the CDCs still so may be able
to help with that.

> 
> I guess that'd be all. If I'm missing something I would be really
> grateful if you can let me know or give me some pointers where to look
> at.

It would probably be a good idea to add devicetree bindings if possible.
Hardly anything is done with board files these days - though we should
maintain the platform data for anyone who is using them (for now).

There may well be other things that come out of the woodwork once
we do a formal review of the patch that proposes moving it out of
staging (there almost always is!)

Jonathan

> 
> Cheers,
> 
> Hernán
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Plan to move cdc:ad7746 driver out of staging

[Jonathan Cameron]

On Mon, 12 Mar 2018 16:25:52 -0300
Hernán Gonzalez  wrote:

> Hi,
> 
> This is my plan for moving out the ad7746 driver out of staging. I
> have some specific questions that would be really helpful if someone
> can point me in the right direction to go.
> 
> 1. Pick up on David's clean-up patch. Finish cleaning CHECKs from
> checkpatch.pl if possible.
> 
> 2. Reorder includes alphabetically.
> 
> 3. Reorder some variable declarations in an inverse-pyramid scheme.
> 
> 4. Fix sysfs attrs naming to comply with the ABI, e.g.:
> in_capacitance0_calibbias_calibration -> in_capacitance0_calibbias
Take a careful look at what these are doing before you do that :)
Then consider what the usecases are.  If we need to, we may need
to add new ABI to cover the requirement.

> 
> 5. Add documentation to the {cap,vt}_filter_rate tables and to the
> processed info read. There are some magic numbers out there, I will
> read the datasheet and explain the math that I consider appropiate.
> 
> 6. There are a few too many defines that are not used at all but they
> do follow the datasheet. I don't know if there are plans to keep
> adding functionalities to this driver or if I should just remove them.
> 
> 8. EXCLVL is duplicated. There's a simple macro in ad7746.c and some
> defines in ad7746.h. The latter are not used anywhere in the code.
> Remove them.
> 
> 7. Move the struct ad7746_platform_data to include/linux/iio.
> 
> As mentioned in earlier mails, I will avoid adding new features as I
> have no access to the hardware and, therefore, could not test it.
Michael has stated he has at least some of the CDCs still so may be able
to help with that.

> 
> I guess that'd be all. If I'm missing something I would be really
> grateful if you can let me know or give me some pointers where to look
> at.

It would probably be a good idea to add devicetree bindings if possible.
Hardly anything is done with board files these days - though we should
maintain the platform data for anyone who is using them (for now).

There may well be other things that come out of the woodwork once
we do a formal review of the patch that proposes moving it out of
staging (there almost always is!)

Jonathan

> 
> Cheers,
> 
> Hernán
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: manual merge of the rtc tree with the asm-generic tree

[Stephen Rothwell]

Hi Alexandre,

On Sat, 17 Mar 2018 14:22:52 +0100 Alexandre Belloni 
 wrote:
>
> I've removed the patch from my tree as there is no point in modifying a
> driver that is removed.

Thanks for letting me know.

-- 
Cheers,
Stephen Rothwell


pgpsZMXnkISMY.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the rtc tree with the asm-generic tree

[Stephen Rothwell]

Hi Alexandre,

On Sat, 17 Mar 2018 14:22:52 +0100 Alexandre Belloni 
 wrote:
>
> I've removed the patch from my tree as there is no point in modifying a
> driver that is removed.

Thanks for letting me know.

-- 
Cheers,
Stephen Rothwell


pgpsZMXnkISMY.pgp
Description: OpenPGP digital signature

[RFC PATCH 3/3] drm: bridge: lvds-encoder: on request, override the bus format

[Peter Rosin]

If the bridge changes the bus format, allow this to be described in
the bridge, instead of providing false information about the bus
format of the panel itself.

Signed-off-by: Peter Rosin 
---
 .../bindings/display/bridge/lvds-transmitter.txt   |  8 
 drivers/gpu/drm/bridge/lvds-encoder.c  | 18 ++
 2 files changed, 26 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index 9d09190d9210..c0fbe74272e7 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -29,6 +29,14 @@ Required properties:
 
  "ti,ds90c185"
 
+Optional properties:
+
+- interface-pix-fmt:
+ Override the bus format of the panel, in case the bridge
+ converts the signals. Recognized formats include:
+
+ "rgb565"
+
 Required nodes:
 
 This device has two video ports. Their connections are modeled using the OF
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..acff3a5b0562 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -39,6 +39,9 @@ static int lvds_encoder_probe(struct platform_device *pdev)
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_encoder *lvds_encoder;
+   u32 bus_format = 0;
+   const char *fmt;
+   int ret;
 
lvds_encoder = devm_kzalloc(>dev, sizeof(*lvds_encoder),
GFP_KERNEL);
@@ -79,6 +82,21 @@ static int lvds_encoder_probe(struct platform_device *pdev)
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
 
+   ret = of_property_read_string(pdev->dev.of_node,
+ "interface-pix-fmt", );
+   if (!ret) {
+   if (!strcmp(fmt, "rgb565")) {
+   bus_format = MEDIA_BUS_FMT_RGB565_1X16;
+   } else {
+   dev_dbg(>dev,
+   "requested interface-pix-fmt not recognized\n");
+   return -EINVAL;
+   }
+   }
+   if (bus_format)
+   drm_panel_bridge_set_bus_format(lvds_encoder->panel_bridge,
+   bus_format);
+
/* The panel_bridge bridge is attached to the panel's of_node,
 * but we need a bridge attached to our of_node for our user
 * to look up.
-- 
2.11.0

[RFC PATCH 3/3] drm: bridge: lvds-encoder: on request, override the bus format

[Peter Rosin]

If the bridge changes the bus format, allow this to be described in
the bridge, instead of providing false information about the bus
format of the panel itself.

Signed-off-by: Peter Rosin 
---
 .../bindings/display/bridge/lvds-transmitter.txt   |  8 
 drivers/gpu/drm/bridge/lvds-encoder.c  | 18 ++
 2 files changed, 26 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index 9d09190d9210..c0fbe74272e7 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -29,6 +29,14 @@ Required properties:
 
  "ti,ds90c185"
 
+Optional properties:
+
+- interface-pix-fmt:
+ Override the bus format of the panel, in case the bridge
+ converts the signals. Recognized formats include:
+
+ "rgb565"
+
 Required nodes:
 
 This device has two video ports. Their connections are modeled using the OF
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..acff3a5b0562 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -39,6 +39,9 @@ static int lvds_encoder_probe(struct platform_device *pdev)
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_encoder *lvds_encoder;
+   u32 bus_format = 0;
+   const char *fmt;
+   int ret;
 
lvds_encoder = devm_kzalloc(>dev, sizeof(*lvds_encoder),
GFP_KERNEL);
@@ -79,6 +82,21 @@ static int lvds_encoder_probe(struct platform_device *pdev)
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
 
+   ret = of_property_read_string(pdev->dev.of_node,
+ "interface-pix-fmt", );
+   if (!ret) {
+   if (!strcmp(fmt, "rgb565")) {
+   bus_format = MEDIA_BUS_FMT_RGB565_1X16;
+   } else {
+   dev_dbg(>dev,
+   "requested interface-pix-fmt not recognized\n");
+   return -EINVAL;
+   }
+   }
+   if (bus_format)
+   drm_panel_bridge_set_bus_format(lvds_encoder->panel_bridge,
+   bus_format);
+
/* The panel_bridge bridge is attached to the panel's of_node,
 * but we need a bridge attached to our of_node for our user
 * to look up.
-- 
2.11.0

[RFC PATCH 2/3] drm: bridge: panel: allow override of the bus format

[Peter Rosin]

Useful if the bridge does some kind of conversion of the bus format.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/bridge/panel.c | 22 +-
 include/drm/drm_bridge.h   |  1 +
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 6d99d4a3beb3..ccef0283ff41 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -22,6 +22,7 @@ struct panel_bridge {
struct drm_connector connector;
struct drm_panel *panel;
u32 connector_type;
+   u32 bus_format;
 };
 
 static inline struct panel_bridge *
@@ -40,8 +41,15 @@ static int panel_bridge_connector_get_modes(struct 
drm_connector *connector)
 {
struct panel_bridge *panel_bridge =
drm_connector_to_panel_bridge(connector);
+   int ret;
+
+   ret = drm_panel_get_modes(panel_bridge->panel);
+
+   if (panel_bridge->bus_format)
+   drm_display_info_set_bus_formats(>display_info,
+_bridge->bus_format, 1);
 
-   return drm_panel_get_modes(panel_bridge->panel);
+   return ret;
 }
 
 static const struct drm_connector_helper_funcs
@@ -203,6 +211,18 @@ void drm_panel_bridge_remove(struct drm_bridge *bridge)
 }
 EXPORT_SYMBOL(drm_panel_bridge_remove);
 
+void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32 bus_format)
+{
+   struct panel_bridge *panel_bridge;
+
+   if (!bridge)
+   return;
+
+   panel_bridge = drm_bridge_to_panel_bridge(bridge);
+   panel_bridge->bus_format = bus_format;
+}
+EXPORT_SYMBOL(drm_panel_bridge_set_bus_format);
+
 static void devm_drm_panel_bridge_release(struct device *dev, void *res)
 {
struct drm_bridge **bridge = res;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 682d01ba920c..81903b92f187 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -268,6 +268,7 @@ void drm_bridge_enable(struct drm_bridge *bridge);
 struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
u32 connector_type);
 void drm_panel_bridge_remove(struct drm_bridge *bridge);
+void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32 
bus_format);
 struct drm_bridge *devm_drm_panel_bridge_add(struct device *dev,
 struct drm_panel *panel,
 u32 connector_type);
-- 
2.11.0

[RFC PATCH 1/3] dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185

[Peter Rosin]

Start list of actual chips compatible with "lvds-encoder".

Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/display/bridge/lvds-transmitter.txt  | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index fd39ad34c383..9d09190d9210 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -24,6 +24,11 @@ Required properties:
 
 - compatible: Must be "lvds-encoder"
 
+ Known actual chips (these should still use "lvds-encoder" as a
+ fallback compatible) include:
+
+ "ti,ds90c185"
+
 Required nodes:
 
 This device has two video ports. Their connections are modeled using the OF
-- 
2.11.0

[RFC PATCH 0/3] allow override of bus format in bridges

[Peter Rosin]

I'm trying to get something to work that I assumed would not
need patches, so I think I might be missing something completely
obvious...

I have an Atmel sama5d31 hooked up to an lvds encoder and then
on to an lvds panel. Which seems like something that has been
done one or two times before...

The problem (I think) is that the bus_format of the SoC and the
panel do not agree. The SoC driver (atmel-hlcdc) can handle the
rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
wired for the rgb565 case. The lvds encoder supports rgb888 on
its input side with the LSB wires simply pulled down internally
in the encoder in my case. And the panel is expecting lvds
(vesa-24), which is what the encoder outputs.

The reason I "blame" the bus_format of the drm_connector is that
with the below DT snippet, things do not work *exactly* due to
that. At least, it starts to work if I hack the panel-lvds driver
to report the rgb565 bus_format instead of vesa-24.

panel: panel {
compatible = "panel-lvds";

width-mm = <476>;
height-mm = <268>;

data-mapping = "vesa-24";

panel-timing {
// 1024x768 @ 60Hz (typical)
clock-frequency = <5214 6500 7110>;
hactive = <1024>;
vactive = <768>;
hfront-porch = <59 107 107>;
hback-porch = <59 107 107>;
hsync-len = <59 106 106>;
vfront-porch = <8 13 14>;
vback-porch = <8 13 14>;
vsync-len = <8 12 14>;
};

port {
panel_input: endpoint {
remote-endpoint = <_encoder_output>;
};
};
};

lvds-encoder {
compatible = "ti,ds90c187", "lvds-encoder";

ports {
#address-cells = <1>;
#size-cells = <0>;

port@0 {
reg = <0>;

lvds_encoder_input: endpoint {
remote-endpoint = <_output>;
};
};

port@1 {
reg = <1>;

lvds_encoder_output: endpoint {
remote-endpoint = <_input>;
};
};
};
};

But, instead of perverting the panel-lvds driver with support
for a totally fake non-lvds bus_format, I came up with an optional
bus_format override in the lvds-encoder driver, which I trigger with
this addition to the lvds-encoder DT node:

interface-pix-fmt = "rgb565";

There are some issues with the interface-pix-fmt name. I copied it
from the freescale fsl-imx-drm binding, but a) I personally don't
like how that binding uses rgb24 instead of rgb888 and b) I don't
like how the implementation of that binding selects rgb666 when you
say bgr666 in the DT, but for parallel hardware interface the bit
order is not really relevant so I swallowed that. Anyway, it might
be better to use something else than interface-pix-fmt? Perhaps
reuse the "data-mapping" name from the panel-lvds binding? But that
seems somewhat lvds specific? Then there a couple of instances of
"bus-format-override" in some dtsi files, but that name is not
mentioned in any binding, nor in (upstream) code...

And maybe it should be fourcc codes or something instead of these
"rgb565" names?

I threw in the first patch, since that is the actual lvds encoder
I have in this case.

Suggestions welcome.

Cheers,
Peter

Peter Rosin (3):
  dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
  drm: bridge: panel: allow override of the bus format
  drm: bridge: lvds-encoder: on request, override the bus format

 .../bindings/display/bridge/lvds-transmitter.txt   | 13 +
 drivers/gpu/drm/bridge/lvds-encoder.c  | 18 ++
 drivers/gpu/drm/bridge/panel.c | 22 +-
 include/drm/drm_bridge.h   |  1 +
 4 files changed, 53 insertions(+), 1 deletion(-)

-- 
2.11.0

[RFC PATCH 2/3] drm: bridge: panel: allow override of the bus format

[Peter Rosin]

Useful if the bridge does some kind of conversion of the bus format.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/bridge/panel.c | 22 +-
 include/drm/drm_bridge.h   |  1 +
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 6d99d4a3beb3..ccef0283ff41 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -22,6 +22,7 @@ struct panel_bridge {
struct drm_connector connector;
struct drm_panel *panel;
u32 connector_type;
+   u32 bus_format;
 };
 
 static inline struct panel_bridge *
@@ -40,8 +41,15 @@ static int panel_bridge_connector_get_modes(struct 
drm_connector *connector)
 {
struct panel_bridge *panel_bridge =
drm_connector_to_panel_bridge(connector);
+   int ret;
+
+   ret = drm_panel_get_modes(panel_bridge->panel);
+
+   if (panel_bridge->bus_format)
+   drm_display_info_set_bus_formats(>display_info,
+_bridge->bus_format, 1);
 
-   return drm_panel_get_modes(panel_bridge->panel);
+   return ret;
 }
 
 static const struct drm_connector_helper_funcs
@@ -203,6 +211,18 @@ void drm_panel_bridge_remove(struct drm_bridge *bridge)
 }
 EXPORT_SYMBOL(drm_panel_bridge_remove);
 
+void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32 bus_format)
+{
+   struct panel_bridge *panel_bridge;
+
+   if (!bridge)
+   return;
+
+   panel_bridge = drm_bridge_to_panel_bridge(bridge);
+   panel_bridge->bus_format = bus_format;
+}
+EXPORT_SYMBOL(drm_panel_bridge_set_bus_format);
+
 static void devm_drm_panel_bridge_release(struct device *dev, void *res)
 {
struct drm_bridge **bridge = res;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 682d01ba920c..81903b92f187 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -268,6 +268,7 @@ void drm_bridge_enable(struct drm_bridge *bridge);
 struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
u32 connector_type);
 void drm_panel_bridge_remove(struct drm_bridge *bridge);
+void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32 
bus_format);
 struct drm_bridge *devm_drm_panel_bridge_add(struct device *dev,
 struct drm_panel *panel,
 u32 connector_type);
-- 
2.11.0

[RFC PATCH 1/3] dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185

[Peter Rosin]

Start list of actual chips compatible with "lvds-encoder".

Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/display/bridge/lvds-transmitter.txt  | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index fd39ad34c383..9d09190d9210 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -24,6 +24,11 @@ Required properties:
 
 - compatible: Must be "lvds-encoder"
 
+ Known actual chips (these should still use "lvds-encoder" as a
+ fallback compatible) include:
+
+ "ti,ds90c185"
+
 Required nodes:
 
 This device has two video ports. Their connections are modeled using the OF
-- 
2.11.0

[RFC PATCH 0/3] allow override of bus format in bridges

[Peter Rosin]

I'm trying to get something to work that I assumed would not
need patches, so I think I might be missing something completely
obvious...

I have an Atmel sama5d31 hooked up to an lvds encoder and then
on to an lvds panel. Which seems like something that has been
done one or two times before...

The problem (I think) is that the bus_format of the SoC and the
panel do not agree. The SoC driver (atmel-hlcdc) can handle the
rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
wired for the rgb565 case. The lvds encoder supports rgb888 on
its input side with the LSB wires simply pulled down internally
in the encoder in my case. And the panel is expecting lvds
(vesa-24), which is what the encoder outputs.

The reason I "blame" the bus_format of the drm_connector is that
with the below DT snippet, things do not work *exactly* due to
that. At least, it starts to work if I hack the panel-lvds driver
to report the rgb565 bus_format instead of vesa-24.

panel: panel {
compatible = "panel-lvds";

width-mm = <476>;
height-mm = <268>;

data-mapping = "vesa-24";

panel-timing {
// 1024x768 @ 60Hz (typical)
clock-frequency = <5214 6500 7110>;
hactive = <1024>;
vactive = <768>;
hfront-porch = <59 107 107>;
hback-porch = <59 107 107>;
hsync-len = <59 106 106>;
vfront-porch = <8 13 14>;
vback-porch = <8 13 14>;
vsync-len = <8 12 14>;
};

port {
panel_input: endpoint {
remote-endpoint = <_encoder_output>;
};
};
};

lvds-encoder {
compatible = "ti,ds90c187", "lvds-encoder";

ports {
#address-cells = <1>;
#size-cells = <0>;

port@0 {
reg = <0>;

lvds_encoder_input: endpoint {
remote-endpoint = <_output>;
};
};

port@1 {
reg = <1>;

lvds_encoder_output: endpoint {
remote-endpoint = <_input>;
};
};
};
};

But, instead of perverting the panel-lvds driver with support
for a totally fake non-lvds bus_format, I came up with an optional
bus_format override in the lvds-encoder driver, which I trigger with
this addition to the lvds-encoder DT node:

interface-pix-fmt = "rgb565";

There are some issues with the interface-pix-fmt name. I copied it
from the freescale fsl-imx-drm binding, but a) I personally don't
like how that binding uses rgb24 instead of rgb888 and b) I don't
like how the implementation of that binding selects rgb666 when you
say bgr666 in the DT, but for parallel hardware interface the bit
order is not really relevant so I swallowed that. Anyway, it might
be better to use something else than interface-pix-fmt? Perhaps
reuse the "data-mapping" name from the panel-lvds binding? But that
seems somewhat lvds specific? Then there a couple of instances of
"bus-format-override" in some dtsi files, but that name is not
mentioned in any binding, nor in (upstream) code...

And maybe it should be fourcc codes or something instead of these
"rgb565" names?

I threw in the first patch, since that is the actual lvds encoder
I have in this case.

Suggestions welcome.

Cheers,
Peter

Peter Rosin (3):
  dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
  drm: bridge: panel: allow override of the bus format
  drm: bridge: lvds-encoder: on request, override the bus format

 .../bindings/display/bridge/lvds-transmitter.txt   | 13 +
 drivers/gpu/drm/bridge/lvds-encoder.c  | 18 ++
 drivers/gpu/drm/bridge/panel.c | 22 +-
 include/drm/drm_bridge.h   |  1 +
 4 files changed, 53 insertions(+), 1 deletion(-)

-- 
2.11.0

Re: [PATCH v6 11/15] mm, fs, dax: handle layout changes to pinned dax mappings

[kbuild test robot]

Hi Dan,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
config: x86_64-randconfig-x010-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/dax/super.c: In function 'generic_dax_pagefree':
>> drivers/dax/super.c:170:2: error: implicit declaration of function 
>> 'wake_up_var'; did you mean 'wake_up_nr'? 
>> [-Werror=implicit-function-declaration]
 wake_up_var(>_refcount);
 ^~~
 wake_up_nr
   cc1: some warnings being treated as errors

vim +170 drivers/dax/super.c

   166  
   167  #if IS_ENABLED(CONFIG_FS_DAX)
   168  static void generic_dax_pagefree(struct page *page, void *data)
   169  {
 > 170  wake_up_var(>_refcount);
   171  }
   172  

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


.config.gz
Description: application/gzip

Re: [PATCH v6 11/15] mm, fs, dax: handle layout changes to pinned dax mappings

[kbuild test robot]

Hi Dan,

I love your patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Dan-Williams/dax-fix-dma-vs-truncate-hole-punch/20180318-050250
config: x86_64-randconfig-x010-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/dax/super.c: In function 'generic_dax_pagefree':
>> drivers/dax/super.c:170:2: error: implicit declaration of function 
>> 'wake_up_var'; did you mean 'wake_up_nr'? 
>> [-Werror=implicit-function-declaration]
 wake_up_var(>_refcount);
 ^~~
 wake_up_nr
   cc1: some warnings being treated as errors

vim +170 drivers/dax/super.c

   166  
   167  #if IS_ENABLED(CONFIG_FS_DAX)
   168  static void generic_dax_pagefree(struct page *page, void *data)
   169  {
 > 170  wake_up_var(>_refcount);
   171  }
   172  

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


.config.gz
Description: application/gzip