[GIT PULL] kbuild fix for v4.10-rc3

[Michal Marek]

Hi Linus,

The asm-prototypes.h file added in the last merge window results in
invalid code with CONFIG_KMEMCHECK=y. The net result is that genksyms
segfaults. This pull request fixes the header, the genksyms fix is in my
kbuild branch for 4.11.

Thanks,
Michal


The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git rc-fixes

for you to fetch changes up to c7858bf16c0b2cc62f475f31e6df28c3a68da1d6:

  asm-prototypes: Clear any CPP defines before declaring the functions 
(2017-01-05 12:57:42 +0100)


Michal Marek (1):
  asm-prototypes: Clear any CPP defines before declaring the functions

 include/asm-generic/asm-prototypes.h | 6 ++
 1 file changed, 6 insertions(+)

[GIT PULL] kbuild fix for v4.10-rc3

[Michal Marek]

Hi Linus,

The asm-prototypes.h file added in the last merge window results in
invalid code with CONFIG_KMEMCHECK=y. The net result is that genksyms
segfaults. This pull request fixes the header, the genksyms fix is in my
kbuild branch for 4.11.

Thanks,
Michal


The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git rc-fixes

for you to fetch changes up to c7858bf16c0b2cc62f475f31e6df28c3a68da1d6:

  asm-prototypes: Clear any CPP defines before declaring the functions 
(2017-01-05 12:57:42 +0100)


Michal Marek (1):
  asm-prototypes: Clear any CPP defines before declaring the functions

 include/asm-generic/asm-prototypes.h | 6 ++
 1 file changed, 6 insertions(+)

Re: [PATCH v4 07/15] mtd: nand: move Samsung specific init/detection logic in nand_samsung.c

[Boris Brezillon]

On Sat, 7 Jan 2017 00:53:24 +0100
Marek Vasut  wrote:

> On 01/04/2017 06:08 PM, Boris Brezillon wrote:
> > On Wed, 4 Jan 2017 16:14:07 +0100
> > Marek Vasut  wrote:
> >   
> >> On 01/03/2017 02:01 PM, Boris Brezillon wrote:  
> >>> Move Samsung specific initialization and detection logic into
> >>> nand_samsung.c. This is part of the "separate vendor specific code from
> >>> core" cleanup process.
> >>>
> >>> Signed-off-by: Boris Brezillon 
> >>
> >> [...]
> >>  
> >>> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> >>> index b3a332f37e14..05e9366696c9 100644
> >>> --- a/drivers/mtd/nand/nand_ids.c
> >>> +++ b/drivers/mtd/nand/nand_ids.c
> >>> @@ -10,7 +10,7 @@
> >>>  #include 
> >>>  #include 
> >>>  
> >>> -#define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
> >>> +#define LP_OPTIONS 0
> >>>  #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
> >>>  
> >>>  #define SP_OPTIONS NAND_NEED_READRDY
> >>> @@ -169,10 +169,12 @@ struct nand_flash_dev nand_flash_ids[] = {
> >>>  };
> >>>  
> >>>  /* Manufacturer IDs */
> >>> +extern const struct nand_manufacturer_ops samsung_nand_manuf_ops;
> >>
> >> Is the extern needed ?  
> > 
> > Yes, unless you have another solution. If you remove the extern keyword
> > you just redeclare samsung_nand_manuf_ops here, which is not what we
> > want.  
> 
> Maybe some accessor function can help ?
> 

You mean, in nand_ids.c

const struct nand_manufacturer_ops *get_samsung_nand_mafuf_ops();

struct nand_manufacturers nand_manuf_ids[] = {
...
{NAND_MFR_SAMSUNG, "Samsung", get_samsung_nand_mafuf_ops},
...
};

and then, in nand_samsung.c

const struct nand_manufacturer_ops *get_samsung_nand_mafuf_ops()
{
return _nand_mafuf_ops;
}

What's the point of this extra indirection? I mean, in both cases you
use a symbol that is not part of the same source file, so you'll have
to define this symbol (using a function prototype or an extern object
definition).
Is this all about fixing checkpatch warnings, or do you have a problem
with objects shared between different source files?

Now, I agree that the current approach is not ideal. A real improvement
would be to let the NAND manufacturer drivers (nand_.c) register
themselves to the core. Something similar to CLK_OF_DECLARE() or
IRQCHIP_DECLARE() for example. But that means creating a dedicated
section for the nand_manufs_id table, and it's a lot more invasive than
the current approach.

Re: [PATCH v4 07/15] mtd: nand: move Samsung specific init/detection logic in nand_samsung.c

[Boris Brezillon]

On Sat, 7 Jan 2017 00:53:24 +0100
Marek Vasut  wrote:

> On 01/04/2017 06:08 PM, Boris Brezillon wrote:
> > On Wed, 4 Jan 2017 16:14:07 +0100
> > Marek Vasut  wrote:
> >   
> >> On 01/03/2017 02:01 PM, Boris Brezillon wrote:  
> >>> Move Samsung specific initialization and detection logic into
> >>> nand_samsung.c. This is part of the "separate vendor specific code from
> >>> core" cleanup process.
> >>>
> >>> Signed-off-by: Boris Brezillon 
> >>
> >> [...]
> >>  
> >>> diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
> >>> index b3a332f37e14..05e9366696c9 100644
> >>> --- a/drivers/mtd/nand/nand_ids.c
> >>> +++ b/drivers/mtd/nand/nand_ids.c
> >>> @@ -10,7 +10,7 @@
> >>>  #include 
> >>>  #include 
> >>>  
> >>> -#define LP_OPTIONS NAND_SAMSUNG_LP_OPTIONS
> >>> +#define LP_OPTIONS 0
> >>>  #define LP_OPTIONS16 (LP_OPTIONS | NAND_BUSWIDTH_16)
> >>>  
> >>>  #define SP_OPTIONS NAND_NEED_READRDY
> >>> @@ -169,10 +169,12 @@ struct nand_flash_dev nand_flash_ids[] = {
> >>>  };
> >>>  
> >>>  /* Manufacturer IDs */
> >>> +extern const struct nand_manufacturer_ops samsung_nand_manuf_ops;
> >>
> >> Is the extern needed ?  
> > 
> > Yes, unless you have another solution. If you remove the extern keyword
> > you just redeclare samsung_nand_manuf_ops here, which is not what we
> > want.  
> 
> Maybe some accessor function can help ?
> 

You mean, in nand_ids.c

const struct nand_manufacturer_ops *get_samsung_nand_mafuf_ops();

struct nand_manufacturers nand_manuf_ids[] = {
...
{NAND_MFR_SAMSUNG, "Samsung", get_samsung_nand_mafuf_ops},
...
};

and then, in nand_samsung.c

const struct nand_manufacturer_ops *get_samsung_nand_mafuf_ops()
{
return _nand_mafuf_ops;
}

What's the point of this extra indirection? I mean, in both cases you
use a symbol that is not part of the same source file, so you'll have
to define this symbol (using a function prototype or an extern object
definition).
Is this all about fixing checkpatch warnings, or do you have a problem
with objects shared between different source files?

Now, I agree that the current approach is not ideal. A real improvement
would be to let the NAND manufacturer drivers (nand_.c) register
themselves to the core. Something similar to CLK_OF_DECLARE() or
IRQCHIP_DECLARE() for example. But that means creating a dedicated
section for the nand_manufs_id table, and it's a lot more invasive than
the current approach.

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Andy Lutomirski  wrote:

> > When I looked at the fixmap, you had to define the space you need ahead of 
> > time and I am not sure there was enough space as you said.
> 
> Can you try it and see if anything goes wrong?  Even if something does go 
> wrong, 
> I think we should fix *that* rather than making the memory layout more 
> complicated.

Absolutely! This should always be the driving principle when complicating the 
kernel's memory layout.

Thanks,

Ingo

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Andy Lutomirski  wrote:

> > When I looked at the fixmap, you had to define the space you need ahead of 
> > time and I am not sure there was enough space as you said.
> 
> Can you try it and see if anything goes wrong?  Even if something does go 
> wrong, 
> I think we should fix *that* rather than making the memory layout more 
> complicated.

Absolutely! This should always be the driving principle when complicating the 
kernel's memory layout.

Thanks,

Ingo

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Andy Lutomirski  wrote:

> > I looked back at the fixmap, and I can see a way it could be done (using 
> > NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to 
> > 512 (there is 2M memory left on fixmap on the default configuration). 
> > That's 
> > if we never add any other fixmap on x64. I don't know if it is an 
> > acceptable 
> > number and if the fixmap region could be increased. (128 if we do your kvm 
> > trick, of course).
> 
> IIRC we need 4096 CPUs.

On 64-bit the limit is 8192 CPUs, and the SGI guys are relying on that up to 
the 
tune of 6144 cores already, and I'd say the 64-bit CPU count is likely to go up 
further with 5-level paging.

On 32-bit the reasonable CPU limit is the number that the Intel 32-bit cluster 
computing nodes use. The latest public numbers are I think 36 'tiles' with each 
tile being a 2-CPU SMT core - i.e. a limit of 72 CPUs has to be maintained. 
(They'll obviously go to 64-bit as well so this problem will go away in a 
hardware 
generation or two.)

So I'd say 128 CPUs on 32-bit should be a reasonable practical limit going 
forward. Right now our 32-bit limit is 512 CPUs IIRC, but I don't think any 
real 
hardware in production is reaching that.

> P.S. Let's do the move to the fixmap, read/write as a separate patch. That 
> will 
> make bisecting much easier.

Absolutely, but this has to be within the same series, as the interim 
fixmap-only 
step is less secure in some circumstances: we are moving the writable GDT from 
a 
previously randomized location to a fixed location.

Thanks,

Ingo

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Andy Lutomirski  wrote:

> > I looked back at the fixmap, and I can see a way it could be done (using 
> > NR_CPUS) like the other fixmap ranges. It would limit the number of cpus to 
> > 512 (there is 2M memory left on fixmap on the default configuration). 
> > That's 
> > if we never add any other fixmap on x64. I don't know if it is an 
> > acceptable 
> > number and if the fixmap region could be increased. (128 if we do your kvm 
> > trick, of course).
> 
> IIRC we need 4096 CPUs.

On 64-bit the limit is 8192 CPUs, and the SGI guys are relying on that up to 
the 
tune of 6144 cores already, and I'd say the 64-bit CPU count is likely to go up 
further with 5-level paging.

On 32-bit the reasonable CPU limit is the number that the Intel 32-bit cluster 
computing nodes use. The latest public numbers are I think 36 'tiles' with each 
tile being a 2-CPU SMT core - i.e. a limit of 72 CPUs has to be maintained. 
(They'll obviously go to 64-bit as well so this problem will go away in a 
hardware 
generation or two.)

So I'd say 128 CPUs on 32-bit should be a reasonable practical limit going 
forward. Right now our 32-bit limit is 512 CPUs IIRC, but I don't think any 
real 
hardware in production is reaching that.

> P.S. Let's do the move to the fixmap, read/write as a separate patch. That 
> will 
> make bisecting much easier.

Absolutely, but this has to be within the same series, as the interim 
fixmap-only 
step is less secure in some circumstances: we are moving the writable GDT from 
a 
previously randomized location to a fixed location.

Thanks,

Ingo

Re: [PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Greg KH]

On Sat, Jan 07, 2017 at 04:48:01PM +1300, Derek Robson wrote:
> Two files change in style fix, changes are octal file permissions.
> 
> Derek Robson (2):
>   Staging: unisys: visorbus: style fix, using octal file permissions
>   Staging: unisys: visorbus: style fix, using octal file permissions

You can't send different patches that do different things with identical
subject lines, as that doesn't make sense, right?

Please resend making these subject unique, and add David's ack to them
as well on the resend.

thanks,

greg k-h

Re: [PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Greg KH]

On Sat, Jan 07, 2017 at 04:48:01PM +1300, Derek Robson wrote:
> Two files change in style fix, changes are octal file permissions.
> 
> Derek Robson (2):
>   Staging: unisys: visorbus: style fix, using octal file permissions
>   Staging: unisys: visorbus: style fix, using octal file permissions

You can't send different patches that do different things with identical
subject lines, as that doesn't make sense, right?

Please resend making these subject unique, and add David's ack to them
as well on the resend.

thanks,

greg k-h

Re: [PATCH v2] hv: retry infinitely on hypercall transient failures

[Greg KH]

On Sat, Jan 07, 2017 at 07:23:14AM +, Long Li wrote:
> > -Original Message-
> > From: Greg KH [mailto:g...@kroah.com]
> > Sent: Wednesday, January 04, 2017 11:48 PM
> > To: Long Li 
> > Cc: KY Srinivasan ; Haiyang Zhang
> > ; de...@linuxdriverproject.org; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH v2] hv: retry infinitely on hypercall transient failures
> > 
> > On Wed, Jan 04, 2017 at 06:12:20PM -0800, Long Li wrote:
> > > From: Long Li 
> > >
> > > Hyper-v host guarantees that a hypercall will finish in reasonable time.
> > > Retry infinitely on transient failures to avoid returning error to upper 
> > > layer.
> > 
> > Again, never retry "forever", always have a way out, otherwise you will 
> > crash.
> > 
> > And again, why are you making this change?  What problem does it solve?
> 
> The problem it tries to solve is that in this code we are returning
> error prematurely on transient failures. The hypercall is used mostly
> in channel establishment. If we return a transient failure, the VM may
> not boot or not useful after boot due to some devices missing.
> 
> Another approach is to increase the number of retries. But we don't
> know how many retries is safe, and Windows host side expects the guest
> retry infinitely and not return error on transient failures.

That implies a lot of trust in the host side, don't you think?

Worse case, make the delay a minute or so, but give the system a way out
incase there's a bug in the host.  As there will be bugs in the host,
just like there are bugs in the client :)

thanks,

greg k-h

Re: [PATCH v2] hv: retry infinitely on hypercall transient failures

[Greg KH]

On Sat, Jan 07, 2017 at 07:23:14AM +, Long Li wrote:
> > -Original Message-
> > From: Greg KH [mailto:g...@kroah.com]
> > Sent: Wednesday, January 04, 2017 11:48 PM
> > To: Long Li 
> > Cc: KY Srinivasan ; Haiyang Zhang
> > ; de...@linuxdriverproject.org; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [PATCH v2] hv: retry infinitely on hypercall transient failures
> > 
> > On Wed, Jan 04, 2017 at 06:12:20PM -0800, Long Li wrote:
> > > From: Long Li 
> > >
> > > Hyper-v host guarantees that a hypercall will finish in reasonable time.
> > > Retry infinitely on transient failures to avoid returning error to upper 
> > > layer.
> > 
> > Again, never retry "forever", always have a way out, otherwise you will 
> > crash.
> > 
> > And again, why are you making this change?  What problem does it solve?
> 
> The problem it tries to solve is that in this code we are returning
> error prematurely on transient failures. The hypercall is used mostly
> in channel establishment. If we return a transient failure, the VM may
> not boot or not useful after boot due to some devices missing.
> 
> Another approach is to increase the number of retries. But we don't
> know how many retries is safe, and Windows host side expects the guest
> retry infinitely and not return error on transient failures.

That implies a lot of trust in the host side, don't you think?

Worse case, make the delay a minute or so, but give the system a way out
incase there's a bug in the host.  As there will be bugs in the host,
just like there are bugs in the client :)

thanks,

greg k-h

Re: [PATCH] Staging: speakup: styel fix, octal file permissions

[Greg KH]

On Sat, Jan 07, 2017 at 05:11:16PM +1300, Derek Robson wrote:
> Changed file permission to octal style,
> Found using checkpatch

Typo in your subject line :(

> 
> Signed-off-by: Derek Robson 
> ---
>  drivers/staging/speakup/kobjects.c | 54 
> +++---
>  1 file changed, 27 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/speakup/kobjects.c 
> b/drivers/staging/speakup/kobjects.c
> index e744aa9730ff..4e7ebc306488 100644
> --- a/drivers/staging/speakup/kobjects.c
> +++ b/drivers/staging/speakup/kobjects.c
> @@ -865,66 +865,66 @@ static struct kobj_attribute version_attribute =
>   __ATTR_RO(version);
>  
>  static struct kobj_attribute delimiters_attribute =
> - __ATTR(delimiters, S_IWUSR | S_IRUGO, punc_show, punc_store);
> + __ATTR(delimiters, 0644, punc_show, punc_store);
>  static struct kobj_attribute ex_num_attribute =
> - __ATTR(ex_num, S_IWUSR | S_IRUGO, punc_show, punc_store);
> + __ATTR(ex_num, 0644, punc_show, punc_store);

Why not just use __ATTR_RW() for all of these instead?  Be much easier
and smaller and is recommended instead of spelling out the mode values
everywhere.

thanks,

greg k-h

Re: [PATCH] Staging: speakup: styel fix, octal file permissions

[Greg KH]

On Sat, Jan 07, 2017 at 05:11:16PM +1300, Derek Robson wrote:
> Changed file permission to octal style,
> Found using checkpatch

Typo in your subject line :(

> 
> Signed-off-by: Derek Robson 
> ---
>  drivers/staging/speakup/kobjects.c | 54 
> +++---
>  1 file changed, 27 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/speakup/kobjects.c 
> b/drivers/staging/speakup/kobjects.c
> index e744aa9730ff..4e7ebc306488 100644
> --- a/drivers/staging/speakup/kobjects.c
> +++ b/drivers/staging/speakup/kobjects.c
> @@ -865,66 +865,66 @@ static struct kobj_attribute version_attribute =
>   __ATTR_RO(version);
>  
>  static struct kobj_attribute delimiters_attribute =
> - __ATTR(delimiters, S_IWUSR | S_IRUGO, punc_show, punc_store);
> + __ATTR(delimiters, 0644, punc_show, punc_store);
>  static struct kobj_attribute ex_num_attribute =
> - __ATTR(ex_num, S_IWUSR | S_IRUGO, punc_show, punc_store);
> + __ATTR(ex_num, 0644, punc_show, punc_store);

Why not just use __ATTR_RW() for all of these instead?  Be much easier
and smaller and is recommended instead of spelling out the mode values
everywhere.

thanks,

greg k-h

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Thomas Garnier  wrote:

> > No, and I had the way this worked on 64-bit wrong.  LTR requires an
> > available TSS and changes it to busy.  So here are my thoughts on how
> > this should work:
> >
> > Let's get rid of any connection between this code and KASLR.  Every
> > time KASLR makes something work differently, a kitten turns all
> > Schrödinger on us.  This is moving the GDT to the fixmap, plain and
> > simple.  For now, make it one page per CPU and don't worry about the
> > GDT limit.
> 
> I am all for this change but that's more significant.
> 
> Ingo: What do you think about that?

I agree with Andy: as I alluded to earlier as well this should be an 
unconditional 
change (tested properly, etc.) that robustifies the GDT mapping for everyone. 
That 
KASLR kernels improve too is a happy side effect!

> > On 32-bit, we're going to have to make the fixmap GDT be read-write because 
> > making it read-only will break double-fault handling.
> >
> > On 64-bit, we can use your trick of temporarily mapping the GDT read-write 
> > every time we load TR, which should happen very rarely. Alternatively, we 
> > can 
> > reload the *GDT* every time we reload TR, which should be comparably slow.  
> > This is going to regress performance in the extremely rare case where KVM 
> > exits to a process that uses ioperm() (I think), but I doubt anyone cares.  
> > Or 
> > maybe we could arrange to never reload TR when GDT points at the fixmap by 
> > having KVM set the host GDT to the direct version and letting KVM's code to 
> > reload the GDT switch to the fixmap copy.

Please check whether the LTR write generates a page fault to a RO PTE even if 
the 
busy bit is already set. LTR is pretty slow which suggests that it's microcode, 
and microcode is usually not sloppy about such things: i.e. LTR would only 
generate an unconditional write if there's a compatibility dependency on it. 
But I 
could easily be wrong ...

> > If we need a quirk to keep the fixmap copy read-write, so be it.
> >
> > None of this should depend on KASLR.  IMO it should happen unconditionally.
> 
> I looked back at the fixmap, and I can see a way it could be done
> (using NR_CPUS) like the other fixmap ranges. It would limit the
> number of cpus to 512 (there is 2M memory left on fixmap on the
> default configuration). That's if we never add any other fixmap on
> x64. I don't know if it is an acceptable number and if the fixmap
> region could be increased. (128 if we do your kvm trick, of course).
> 
> Ingo: What do you think?

I think we should scale the fixmap size flexibly with NR_CPUs on 64-bit, and we 
should limit CPUs on 32-bit to a reasonable value.

I.e. let's just do it, if we run into problems it's all solvable AFAICS.

Thanks,

Ingo

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

[Ingo Molnar]

* Thomas Garnier  wrote:

> > No, and I had the way this worked on 64-bit wrong.  LTR requires an
> > available TSS and changes it to busy.  So here are my thoughts on how
> > this should work:
> >
> > Let's get rid of any connection between this code and KASLR.  Every
> > time KASLR makes something work differently, a kitten turns all
> > Schrödinger on us.  This is moving the GDT to the fixmap, plain and
> > simple.  For now, make it one page per CPU and don't worry about the
> > GDT limit.
> 
> I am all for this change but that's more significant.
> 
> Ingo: What do you think about that?

I agree with Andy: as I alluded to earlier as well this should be an 
unconditional 
change (tested properly, etc.) that robustifies the GDT mapping for everyone. 
That 
KASLR kernels improve too is a happy side effect!

> > On 32-bit, we're going to have to make the fixmap GDT be read-write because 
> > making it read-only will break double-fault handling.
> >
> > On 64-bit, we can use your trick of temporarily mapping the GDT read-write 
> > every time we load TR, which should happen very rarely. Alternatively, we 
> > can 
> > reload the *GDT* every time we reload TR, which should be comparably slow.  
> > This is going to regress performance in the extremely rare case where KVM 
> > exits to a process that uses ioperm() (I think), but I doubt anyone cares.  
> > Or 
> > maybe we could arrange to never reload TR when GDT points at the fixmap by 
> > having KVM set the host GDT to the direct version and letting KVM's code to 
> > reload the GDT switch to the fixmap copy.

Please check whether the LTR write generates a page fault to a RO PTE even if 
the 
busy bit is already set. LTR is pretty slow which suggests that it's microcode, 
and microcode is usually not sloppy about such things: i.e. LTR would only 
generate an unconditional write if there's a compatibility dependency on it. 
But I 
could easily be wrong ...

> > If we need a quirk to keep the fixmap copy read-write, so be it.
> >
> > None of this should depend on KASLR.  IMO it should happen unconditionally.
> 
> I looked back at the fixmap, and I can see a way it could be done
> (using NR_CPUS) like the other fixmap ranges. It would limit the
> number of cpus to 512 (there is 2M memory left on fixmap on the
> default configuration). That's if we never add any other fixmap on
> x64. I don't know if it is an acceptable number and if the fixmap
> region could be increased. (128 if we do your kvm trick, of course).
> 
> Ingo: What do you think?

I think we should scale the fixmap size flexibly with NR_CPUs on 64-bit, and we 
should limit CPUs on 32-bit to a reasonable value.

I.e. let's just do it, if we run into problems it's all solvable AFAICS.

Thanks,

Ingo

Re: [PATCH v1] mtd: spi nor: modify the boot and flash type of FMC

[linshunquan (A)]

Hi Cyrille,
 Thanks for your relay, I will update this patch soon.

On 2017/1/6 21:44, Cyrille Pitchen wrote:
> Hi,
> 
> Le 06/01/2017 à 10:12, linshunquan 00354166 a écrit :
>> (1) The HiSilicon Flash Memory Controller(FMC) is a multi-functions
>>  device which supports SPI Nor flash controller, SPI nand Flash
>>  controller and parallel nand flash controller. So when we are prepare
>>  to operation SPI Nor, we should make sure the flash type is SPI Nor.
>>
>> (2) Make sure the boot type is Normal Type before initialize the SPI
>> Nor controller.
>>
>> Signed-off-by: linshunquan 00354166 
>> ---
>>  drivers/mtd/spi-nor/hisi-sfc.c | 30 ++
>>  1 file changed, 30 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
>> index 20378b0..7855024 100644
>> --- a/drivers/mtd/spi-nor/hisi-sfc.c
>> +++ b/drivers/mtd/spi-nor/hisi-sfc.c
>> @@ -32,6 +32,8 @@
>>  #define FMC_CFG_OP_MODE_MASKBIT_MASK(0)
>>  #define FMC_CFG_OP_MODE_BOOT0
>>  #define FMC_CFG_OP_MODE_NORMAL  1
>> +#define FMC_CFG_OP_MODE_SEL(mode)  ((mode) & 0x1)
>> +#define FMC_CFG_FLASH_SEL_SPI_NOR   (0x0 << 1)
>>  #define FMC_CFG_FLASH_SEL(type) (((type) & 0x3) << 1)
>>  #define FMC_CFG_FLASH_SEL_MASK  0x6
>>  #define FMC_ECC_TYPE(type)  (((type) & 0x7) << 5)
>> @@ -141,10 +143,36 @@ static int get_if_type(enum read_mode flash_read)
>>  return if_type;
>>  }
>>  
>> +static void spi_nor_switch_spi_type(struct hifmc_host *host)
>> +{
>> +unsigned int reg;
>> +
>> +reg = readl(host->regbase + FMC_CFG);
>> +if ((reg & FMC_CFG_FLASH_SEL_MASK)
>> +== FMC_CFG_FLASH_SEL_SPI_NOR)
>> +return;
>> +
>> +/* if the flash type isn't spi nor, change it */
>> +reg &= ~FMC_CFG_FLASH_SEL_MASK;
>> +reg |= FMC_CFG_FLASH_SEL(0);
>> +writel(reg, host->regbase + FMC_CFG);
>> +}
>> +
> 
> This is not consistent: we have to check the macro definitions to
> understand that FMC_CFG_FLASH_SPI_NOR == FMC_CFG_FLASH_SEL(0)
> 
> In such a function, you should use the very same macro for both the test
> and the update of reg; either FMC_CFG_FLASH_SEL_SPI_NOR or
> FMC_CFG_FLASH_SEL(0). Please don't mix the use of those macros.
> 
>>  static void hisi_spi_nor_init(struct hifmc_host *host)
>>  {
>>  u32 reg;
>>  
>> +/* switch the flash type to spi nor */
>> +spi_nor_switch_spi_type(host);
>> +
>> +/* set the boot mode to normal */
>> +reg = readl(host->regbase + FMC_CFG);
>> +if ((reg & FMC_CFG_OP_MODE_MASK) == FMC_CFG_OP_MODE_BOOT) {
>> +reg |= FMC_CFG_OP_MODE_SEL(FMC_CFG_OP_MODE_NORMAL);
> 
> This is not consistent: you test FMC_CFG_OP_MODE_BOOT, hence without
> FMC_CFG_OP_MODE_SEL() but you set
> FMC_CFG_OP_MODE_SEL(FMC_CFG_OP_MODE_NORMAL), with FMC_CFG_OP_MODE_SEL().
> 
> Of course, looking at the macro definitions, it works as is but once again
> we have to check the macro definitions to understand why sometime you use
> FMC_CFG_OP_MODE_SEL() whereas other times you don't.
> 
>> +writel(reg, host->regbase + FMC_CFG);
>> +}
> 
> spi_nor_switch_spi_type() already updates the FMC_CFG register in the very
> same manner: read, test, modify, write. Hence you should write a more
> generic function and update both bitfields at once.
> 
> static void hisi_spi_nor_update_reg(struct hifmc_host *host,
>   unsigned int reg_offset,
>   unsigned int value,
>   unsigned int mask)
> {
>   unsigned int reg;
> 
>   reg = readl(host->regbase + reg_offset);
>   if (((reg ^ value) & mask) == 0)
>   return;
> 
>   reg = (reg & ~mask) | (value & mask);
>   writel(reg, host->regbase + reg_offset);
> }
> 
> ...
> 
>   unsigned int value, mask;
> 
>   /*
>* switch the flash type to spi nor and set the boot mode to
>* normal.
>*/
>   value = FMC_CFG_OP_MODE_NORMAL | FMC_CFG_FLASH_SEL_SPI_NOR;
>   mask = FMC_CFG_OP_MODE_MASK | FMC_CFG_FLASH_SEL_MASK;
>   hisi_spi_nor_update_reg(host, FMC_CFG, value, mask);
> 
>> +
>> +/* set timming */
>>  reg = TIMING_CFG_TCSH(CS_HOLD_TIME)
>>  | TIMING_CFG_TCSS(CS_SETUP_TIME)
>>  | TIMING_CFG_TSHSL(CS_DESELECT_TIME);
>> @@ -167,6 +195,8 @@ static int hisi_spi_nor_prep(struct spi_nor *nor, enum 
>> spi_nor_ops ops)
>>  if (ret)
>>  goto out;
>>  
>> +spi_nor_switch_spi_type(host);
>> +
>>  return 0;
>>  
>>  out:
>>
> 
> Best regards,
> 
> Cyrille
> .
> 

Re: [PATCH v1] mtd: spi nor: modify the boot and flash type of FMC

[linshunquan (A)]

Hi Cyrille,
 Thanks for your relay, I will update this patch soon.

On 2017/1/6 21:44, Cyrille Pitchen wrote:
> Hi,
> 
> Le 06/01/2017 à 10:12, linshunquan 00354166 a écrit :
>> (1) The HiSilicon Flash Memory Controller(FMC) is a multi-functions
>>  device which supports SPI Nor flash controller, SPI nand Flash
>>  controller and parallel nand flash controller. So when we are prepare
>>  to operation SPI Nor, we should make sure the flash type is SPI Nor.
>>
>> (2) Make sure the boot type is Normal Type before initialize the SPI
>> Nor controller.
>>
>> Signed-off-by: linshunquan 00354166 
>> ---
>>  drivers/mtd/spi-nor/hisi-sfc.c | 30 ++
>>  1 file changed, 30 insertions(+)
>>
>> diff --git a/drivers/mtd/spi-nor/hisi-sfc.c b/drivers/mtd/spi-nor/hisi-sfc.c
>> index 20378b0..7855024 100644
>> --- a/drivers/mtd/spi-nor/hisi-sfc.c
>> +++ b/drivers/mtd/spi-nor/hisi-sfc.c
>> @@ -32,6 +32,8 @@
>>  #define FMC_CFG_OP_MODE_MASKBIT_MASK(0)
>>  #define FMC_CFG_OP_MODE_BOOT0
>>  #define FMC_CFG_OP_MODE_NORMAL  1
>> +#define FMC_CFG_OP_MODE_SEL(mode)  ((mode) & 0x1)
>> +#define FMC_CFG_FLASH_SEL_SPI_NOR   (0x0 << 1)
>>  #define FMC_CFG_FLASH_SEL(type) (((type) & 0x3) << 1)
>>  #define FMC_CFG_FLASH_SEL_MASK  0x6
>>  #define FMC_ECC_TYPE(type)  (((type) & 0x7) << 5)
>> @@ -141,10 +143,36 @@ static int get_if_type(enum read_mode flash_read)
>>  return if_type;
>>  }
>>  
>> +static void spi_nor_switch_spi_type(struct hifmc_host *host)
>> +{
>> +unsigned int reg;
>> +
>> +reg = readl(host->regbase + FMC_CFG);
>> +if ((reg & FMC_CFG_FLASH_SEL_MASK)
>> +== FMC_CFG_FLASH_SEL_SPI_NOR)
>> +return;
>> +
>> +/* if the flash type isn't spi nor, change it */
>> +reg &= ~FMC_CFG_FLASH_SEL_MASK;
>> +reg |= FMC_CFG_FLASH_SEL(0);
>> +writel(reg, host->regbase + FMC_CFG);
>> +}
>> +
> 
> This is not consistent: we have to check the macro definitions to
> understand that FMC_CFG_FLASH_SPI_NOR == FMC_CFG_FLASH_SEL(0)
> 
> In such a function, you should use the very same macro for both the test
> and the update of reg; either FMC_CFG_FLASH_SEL_SPI_NOR or
> FMC_CFG_FLASH_SEL(0). Please don't mix the use of those macros.
> 
>>  static void hisi_spi_nor_init(struct hifmc_host *host)
>>  {
>>  u32 reg;
>>  
>> +/* switch the flash type to spi nor */
>> +spi_nor_switch_spi_type(host);
>> +
>> +/* set the boot mode to normal */
>> +reg = readl(host->regbase + FMC_CFG);
>> +if ((reg & FMC_CFG_OP_MODE_MASK) == FMC_CFG_OP_MODE_BOOT) {
>> +reg |= FMC_CFG_OP_MODE_SEL(FMC_CFG_OP_MODE_NORMAL);
> 
> This is not consistent: you test FMC_CFG_OP_MODE_BOOT, hence without
> FMC_CFG_OP_MODE_SEL() but you set
> FMC_CFG_OP_MODE_SEL(FMC_CFG_OP_MODE_NORMAL), with FMC_CFG_OP_MODE_SEL().
> 
> Of course, looking at the macro definitions, it works as is but once again
> we have to check the macro definitions to understand why sometime you use
> FMC_CFG_OP_MODE_SEL() whereas other times you don't.
> 
>> +writel(reg, host->regbase + FMC_CFG);
>> +}
> 
> spi_nor_switch_spi_type() already updates the FMC_CFG register in the very
> same manner: read, test, modify, write. Hence you should write a more
> generic function and update both bitfields at once.
> 
> static void hisi_spi_nor_update_reg(struct hifmc_host *host,
>   unsigned int reg_offset,
>   unsigned int value,
>   unsigned int mask)
> {
>   unsigned int reg;
> 
>   reg = readl(host->regbase + reg_offset);
>   if (((reg ^ value) & mask) == 0)
>   return;
> 
>   reg = (reg & ~mask) | (value & mask);
>   writel(reg, host->regbase + reg_offset);
> }
> 
> ...
> 
>   unsigned int value, mask;
> 
>   /*
>* switch the flash type to spi nor and set the boot mode to
>* normal.
>*/
>   value = FMC_CFG_OP_MODE_NORMAL | FMC_CFG_FLASH_SEL_SPI_NOR;
>   mask = FMC_CFG_OP_MODE_MASK | FMC_CFG_FLASH_SEL_MASK;
>   hisi_spi_nor_update_reg(host, FMC_CFG, value, mask);
> 
>> +
>> +/* set timming */
>>  reg = TIMING_CFG_TCSH(CS_HOLD_TIME)
>>  | TIMING_CFG_TCSS(CS_SETUP_TIME)
>>  | TIMING_CFG_TSHSL(CS_DESELECT_TIME);
>> @@ -167,6 +195,8 @@ static int hisi_spi_nor_prep(struct spi_nor *nor, enum 
>> spi_nor_ops ops)
>>  if (ret)
>>  goto out;
>>  
>> +spi_nor_switch_spi_type(host);
>> +
>>  return 0;
>>  
>>  out:
>>
> 
> Best regards,
> 
> Cyrille
> .
> 

Re: [PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock

[Bjorn Andersson]

On Fri 06 Jan 19:01 PST 2017, Andy Gross wrote:

> On Fri, Jan 06, 2017 at 05:10:44PM -0800, John Stultz wrote:
> > On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson
> >  wrote:
> > > As per the device tree binding the apq8064 scm node requires the core
> > > clock to be specified, so add this.
> > >
> > > Cc: John Stultz 
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > >  arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> > > b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > index 268bd470c865..78bf155a52f3 100644
> > > --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > @@ -303,6 +303,9 @@
> > > firmware {
> > > scm {
> > > compatible = "qcom,scm-apq8064";
> > > +
> > > +   clocks = < CE3_CORE_CLK>;
> > > +   clock-names = "core";
> > 
> > 
> > Tested-by: John Stultz 
> > 
> > I know Bjorn has a new version of this patch that uses the
> > RPM_DAYTONA_FABRIC_CLK value, but that one results in problems with
> > usb gadget functionality on my Nexus7.  This one seems to work ok
> > though.
> 
> Odd.  Is the usb gadget using the daytona but not getting a reference?  I 
> wonder
> if this is related to not having the bus driver running the bus clk enablement
> and frequencies.
> 

The fact that we now reference the Daytona clock means that we're also
telling the RPM to disable it, so that might very well be the case.

Unfortunately I can't find any block diagram for 8064 to show what hangs
off the Daytona, so I'm not sure in what way USB should reference it.

Regards,
Bjorn

Re: [PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock

[Bjorn Andersson]

On Fri 06 Jan 19:01 PST 2017, Andy Gross wrote:

> On Fri, Jan 06, 2017 at 05:10:44PM -0800, John Stultz wrote:
> > On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson
> >  wrote:
> > > As per the device tree binding the apq8064 scm node requires the core
> > > clock to be specified, so add this.
> > >
> > > Cc: John Stultz 
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > >  arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> > > b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > index 268bd470c865..78bf155a52f3 100644
> > > --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > @@ -303,6 +303,9 @@
> > > firmware {
> > > scm {
> > > compatible = "qcom,scm-apq8064";
> > > +
> > > +   clocks = < CE3_CORE_CLK>;
> > > +   clock-names = "core";
> > 
> > 
> > Tested-by: John Stultz 
> > 
> > I know Bjorn has a new version of this patch that uses the
> > RPM_DAYTONA_FABRIC_CLK value, but that one results in problems with
> > usb gadget functionality on my Nexus7.  This one seems to work ok
> > though.
> 
> Odd.  Is the usb gadget using the daytona but not getting a reference?  I 
> wonder
> if this is related to not having the bus driver running the bus clk enablement
> and frequencies.
> 

The fact that we now reference the Daytona clock means that we're also
telling the RPM to disable it, so that might very well be the case.

Unfortunately I can't find any block diagram for 8064 to show what hangs
off the Daytona, so I'm not sure in what way USB should reference it.

Regards,
Bjorn

RE: [PATCH v2] hv: retry infinitely on hypercall transient failures

[Long Li]

> -Original Message-
> From: Greg KH [mailto:g...@kroah.com]
> Sent: Wednesday, January 04, 2017 11:48 PM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2] hv: retry infinitely on hypercall transient failures
> 
> On Wed, Jan 04, 2017 at 06:12:20PM -0800, Long Li wrote:
> > From: Long Li 
> >
> > Hyper-v host guarantees that a hypercall will finish in reasonable time.
> > Retry infinitely on transient failures to avoid returning error to upper 
> > layer.
> 
> Again, never retry "forever", always have a way out, otherwise you will crash.
> 
> And again, why are you making this change?  What problem does it solve?

The problem it tries to solve is that in this code we are returning error 
prematurely on transient failures. The hypercall is used mostly in channel 
establishment. If we return a transient failure, the VM may not boot or not 
useful after boot due to some devices missing.

Another approach is to increase the number of retries. But we don't know how 
many retries is safe, and Windows host side expects the guest retry infinitely 
and not return error on transient failures.

> 
> greg k-h

RE: [PATCH v2] hv: retry infinitely on hypercall transient failures

[Long Li]

> -Original Message-
> From: Greg KH [mailto:g...@kroah.com]
> Sent: Wednesday, January 04, 2017 11:48 PM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2] hv: retry infinitely on hypercall transient failures
> 
> On Wed, Jan 04, 2017 at 06:12:20PM -0800, Long Li wrote:
> > From: Long Li 
> >
> > Hyper-v host guarantees that a hypercall will finish in reasonable time.
> > Retry infinitely on transient failures to avoid returning error to upper 
> > layer.
> 
> Again, never retry "forever", always have a way out, otherwise you will crash.
> 
> And again, why are you making this change?  What problem does it solve?

The problem it tries to solve is that in this code we are returning error 
prematurely on transient failures. The hypercall is used mostly in channel 
establishment. If we return a transient failure, the VM may not boot or not 
useful after boot due to some devices missing.

Another approach is to increase the number of retries. But we don't know how 
many retries is safe, and Windows host side expects the guest retry infinitely 
and not return error on transient failures.

> 
> greg k-h

RE: [PATCH] hv: use substraction to update ring buffer index

[Long Li]

> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, January 05, 2017 3:40 AM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] hv: use substraction to update ring buffer index
> 
> On Wed, Jan 04, 2017 at 08:08:22PM -0800, Long Li wrote:
> > From: Long Li 
> >
> > The ring buffer code uses %= to calculate index. For x86/64, %=
> > compiles to div, more than 10 times slower than sub.
> >
> > Replace div with sub for this data heavy code path.
> >
> > Signed-off-by: Long Li 
> > ---
> >  drivers/hv/ring_buffer.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index
> > cd49cb1..f8eee6e 100644
> > --- a/drivers/hv/ring_buffer.c
> > +++ b/drivers/hv/ring_buffer.c
> > @@ -135,7 +135,8 @@ hv_get_next_readlocation_withoffset(struct
> hv_ring_buffer_info *ring_info,
> > u32 next = ring_info->ring_buffer->read_index;
> >
> > next += offset;
> > -   next %= ring_info->ring_datasize;
> > +   if (next >= ring_info->ring_datasize)
> > +   next -= ring_info->ring_datasize;
> 
> I take it that we trust that offset is roughly correct and not more than 2x
> ring_info->ring_datasize?  I guess there is only one caller so it's probably
> true...

Yes, you are right. It's not possible that we are getting to 2x ring_datasize, 
because it's not possible to transfer data more than ring_datasize over ring 
buffer.

> 
> >
> > return next;
> >  }
> > @@ -179,7 +180,8 @@ static u32 hv_copyfrom_ringbuffer(
> > memcpy(dest, ring_buffer + start_read_offset, destlen);
> >
> > start_read_offset += destlen;
> > -   start_read_offset %= ring_buffer_size;
> > +   if (start_read_offset >= ring_buffer_size)
> > +   start_read_offset -= ring_buffer_size;
> 
> I totally don't understand the original code here.  We do the memset and
> then we verify that we are not copying beyond the end of the ring buffer?  If
> feels like we should verify that offset + destlen aren't more than
> ring_buffer_size before we do the memcpy().

The ring buffer pages are mapped to wraparound 2x virtual address space. Please 
see hv_ringbuffer_init(). The call to vmap() setup this virtual address space. 
So we can use memcpy across the last page.

> 
> regards,
> dan carpenter
> 

Thanks for reviewing!

Long

RE: [PATCH] hv: use substraction to update ring buffer index

[Long Li]

> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, January 05, 2017 3:40 AM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] hv: use substraction to update ring buffer index
> 
> On Wed, Jan 04, 2017 at 08:08:22PM -0800, Long Li wrote:
> > From: Long Li 
> >
> > The ring buffer code uses %= to calculate index. For x86/64, %=
> > compiles to div, more than 10 times slower than sub.
> >
> > Replace div with sub for this data heavy code path.
> >
> > Signed-off-by: Long Li 
> > ---
> >  drivers/hv/ring_buffer.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c index
> > cd49cb1..f8eee6e 100644
> > --- a/drivers/hv/ring_buffer.c
> > +++ b/drivers/hv/ring_buffer.c
> > @@ -135,7 +135,8 @@ hv_get_next_readlocation_withoffset(struct
> hv_ring_buffer_info *ring_info,
> > u32 next = ring_info->ring_buffer->read_index;
> >
> > next += offset;
> > -   next %= ring_info->ring_datasize;
> > +   if (next >= ring_info->ring_datasize)
> > +   next -= ring_info->ring_datasize;
> 
> I take it that we trust that offset is roughly correct and not more than 2x
> ring_info->ring_datasize?  I guess there is only one caller so it's probably
> true...

Yes, you are right. It's not possible that we are getting to 2x ring_datasize, 
because it's not possible to transfer data more than ring_datasize over ring 
buffer.

> 
> >
> > return next;
> >  }
> > @@ -179,7 +180,8 @@ static u32 hv_copyfrom_ringbuffer(
> > memcpy(dest, ring_buffer + start_read_offset, destlen);
> >
> > start_read_offset += destlen;
> > -   start_read_offset %= ring_buffer_size;
> > +   if (start_read_offset >= ring_buffer_size)
> > +   start_read_offset -= ring_buffer_size;
> 
> I totally don't understand the original code here.  We do the memset and
> then we verify that we are not copying beyond the end of the ring buffer?  If
> feels like we should verify that offset + destlen aren't more than
> ring_buffer_size before we do the memcpy().

The ring buffer pages are mapped to wraparound 2x virtual address space. Please 
see hv_ringbuffer_init(). The call to vmap() setup this virtual address space. 
So we can use memcpy across the last page.

> 
> regards,
> dan carpenter
> 

Thanks for reviewing!

Long

[PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor

[Kedareswara rao Appana]

Add channel idle state to ensure that dma descriptor is not
submitted when VDMA engine is in progress.

Reviewed-by: Jose Abreu 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v5:
---> None.
Changes for v4:
---> None.
Changes for v3:
---> None.
Changes for v2:
---> Add idle check in the reset as suggested by Jose Abreu
---> Removed xilinx_dma_is_running/xilinx_dma_is_idle checks
in the driver and used common idle checks across the driver
as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_dma.c | 56 +
 1 file changed, 17 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 8288fe4..be7eb41 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -321,6 +321,7 @@ struct xilinx_dma_tx_descriptor {
  * @cyclic: Check for cyclic transfers.
  * @genlock: Support genlock mode
  * @err: Channel has errors
+ * @idle: Check for channel idle
  * @tasklet: Cleanup work after irq
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
@@ -351,6 +352,7 @@ struct xilinx_dma_chan {
bool cyclic;
bool genlock;
bool err;
+   bool idle;
struct tasklet_struct tasklet;
struct xilinx_vdma_config config;
bool flush_on_fsync;
@@ -920,32 +922,6 @@ static enum dma_status xilinx_dma_tx_status(struct 
dma_chan *dchan,
 }
 
 /**
- * xilinx_dma_is_running - Check if DMA channel is running
- * @chan: Driver specific DMA channel
- *
- * Return: '1' if running, '0' if not.
- */
-static bool xilinx_dma_is_running(struct xilinx_dma_chan *chan)
-{
-   return !(dma_ctrl_read(chan, XILINX_DMA_REG_DMASR) &
-XILINX_DMA_DMASR_HALTED) &&
-   (dma_ctrl_read(chan, XILINX_DMA_REG_DMACR) &
-XILINX_DMA_DMACR_RUNSTOP);
-}
-
-/**
- * xilinx_dma_is_idle - Check if DMA channel is idle
- * @chan: Driver specific DMA channel
- *
- * Return: '1' if idle, '0' if not.
- */
-static bool xilinx_dma_is_idle(struct xilinx_dma_chan *chan)
-{
-   return dma_ctrl_read(chan, XILINX_DMA_REG_DMASR) &
-   XILINX_DMA_DMASR_IDLE;
-}
-
-/**
  * xilinx_dma_halt - Halt DMA channel
  * @chan: Driver specific DMA channel
  */
@@ -966,6 +942,7 @@ static void xilinx_dma_halt(struct xilinx_dma_chan *chan)
chan, dma_ctrl_read(chan, XILINX_DMA_REG_DMASR));
chan->err = true;
}
+   chan->idle = true;
 }
 
 /**
@@ -1007,6 +984,9 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->err)
return;
 
+   if (!chan->idle)
+   return;
+
if (list_empty(>pending_list))
return;
 
@@ -1018,13 +998,6 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
tail_segment = list_last_entry(_desc->segments,
   struct xilinx_vdma_tx_segment, node);
 
-   /* If it is SG mode and hardware is busy, cannot submit */
-   if (chan->has_sg && xilinx_dma_is_running(chan) &&
-   !xilinx_dma_is_idle(chan)) {
-   dev_dbg(chan->dev, "DMA controller still busy\n");
-   return;
-   }
-
/*
 * If hardware is idle, then all descriptors on the running lists are
 * done, start new transfers
@@ -1110,6 +1083,7 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
}
 
+   chan->idle = false;
if (!chan->has_sg) {
list_del(>node);
list_add_tail(>node, >active_list);
@@ -1136,6 +1110,9 @@ static void xilinx_cdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->err)
return;
 
+   if (!chan->idle)
+   return;
+
if (list_empty(>pending_list))
return;
 
@@ -1181,6 +1158,7 @@ static void xilinx_cdma_start_transfer(struct 
xilinx_dma_chan *chan)
 
list_splice_tail_init(>pending_list, >active_list);
chan->desc_pendingcount = 0;
+   chan->idle = false;
 }
 
 /**
@@ -1196,15 +1174,11 @@ static void xilinx_dma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->err)
return;
 
-   if (list_empty(>pending_list))
+   if (!chan->idle)
return;
 
-   /* If it is SG mode and hardware is busy, cannot submit */
-   if (chan->has_sg && xilinx_dma_is_running(chan) &&
-   !xilinx_dma_is_idle(chan)) {
-   dev_dbg(chan->dev, "DMA controller still busy\n");
+   if (list_empty(>pending_list))
return;
-   }
 
head_desc = list_first_entry(>pending_list,
 struct xilinx_dma_tx_descriptor, node);
@@ -1302,6 +1276,7 @@ static void xilinx_dma_start_transfer(struct 

[PATCH v5 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor

[Kedareswara rao Appana]

Add channel idle state to ensure that dma descriptor is not
submitted when VDMA engine is in progress.

Reviewed-by: Jose Abreu 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v5:
---> None.
Changes for v4:
---> None.
Changes for v3:
---> None.
Changes for v2:
---> Add idle check in the reset as suggested by Jose Abreu
---> Removed xilinx_dma_is_running/xilinx_dma_is_idle checks
in the driver and used common idle checks across the driver
as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_dma.c | 56 +
 1 file changed, 17 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 8288fe4..be7eb41 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -321,6 +321,7 @@ struct xilinx_dma_tx_descriptor {
  * @cyclic: Check for cyclic transfers.
  * @genlock: Support genlock mode
  * @err: Channel has errors
+ * @idle: Check for channel idle
  * @tasklet: Cleanup work after irq
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
@@ -351,6 +352,7 @@ struct xilinx_dma_chan {
bool cyclic;
bool genlock;
bool err;
+   bool idle;
struct tasklet_struct tasklet;
struct xilinx_vdma_config config;
bool flush_on_fsync;
@@ -920,32 +922,6 @@ static enum dma_status xilinx_dma_tx_status(struct 
dma_chan *dchan,
 }
 
 /**
- * xilinx_dma_is_running - Check if DMA channel is running
- * @chan: Driver specific DMA channel
- *
- * Return: '1' if running, '0' if not.
- */
-static bool xilinx_dma_is_running(struct xilinx_dma_chan *chan)
-{
-   return !(dma_ctrl_read(chan, XILINX_DMA_REG_DMASR) &
-XILINX_DMA_DMASR_HALTED) &&
-   (dma_ctrl_read(chan, XILINX_DMA_REG_DMACR) &
-XILINX_DMA_DMACR_RUNSTOP);
-}
-
-/**
- * xilinx_dma_is_idle - Check if DMA channel is idle
- * @chan: Driver specific DMA channel
- *
- * Return: '1' if idle, '0' if not.
- */
-static bool xilinx_dma_is_idle(struct xilinx_dma_chan *chan)
-{
-   return dma_ctrl_read(chan, XILINX_DMA_REG_DMASR) &
-   XILINX_DMA_DMASR_IDLE;
-}
-
-/**
  * xilinx_dma_halt - Halt DMA channel
  * @chan: Driver specific DMA channel
  */
@@ -966,6 +942,7 @@ static void xilinx_dma_halt(struct xilinx_dma_chan *chan)
chan, dma_ctrl_read(chan, XILINX_DMA_REG_DMASR));
chan->err = true;
}
+   chan->idle = true;
 }
 
 /**
@@ -1007,6 +984,9 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->err)
return;
 
+   if (!chan->idle)
+   return;
+
if (list_empty(>pending_list))
return;
 
@@ -1018,13 +998,6 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
tail_segment = list_last_entry(_desc->segments,
   struct xilinx_vdma_tx_segment, node);
 
-   /* If it is SG mode and hardware is busy, cannot submit */
-   if (chan->has_sg && xilinx_dma_is_running(chan) &&
-   !xilinx_dma_is_idle(chan)) {
-   dev_dbg(chan->dev, "DMA controller still busy\n");
-   return;
-   }
-
/*
 * If hardware is idle, then all descriptors on the running lists are
 * done, start new transfers
@@ -1110,6 +1083,7 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
}
 
+   chan->idle = false;
if (!chan->has_sg) {
list_del(>node);
list_add_tail(>node, >active_list);
@@ -1136,6 +1110,9 @@ static void xilinx_cdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->err)
return;
 
+   if (!chan->idle)
+   return;
+
if (list_empty(>pending_list))
return;
 
@@ -1181,6 +1158,7 @@ static void xilinx_cdma_start_transfer(struct 
xilinx_dma_chan *chan)
 
list_splice_tail_init(>pending_list, >active_list);
chan->desc_pendingcount = 0;
+   chan->idle = false;
 }
 
 /**
@@ -1196,15 +1174,11 @@ static void xilinx_dma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->err)
return;
 
-   if (list_empty(>pending_list))
+   if (!chan->idle)
return;
 
-   /* If it is SG mode and hardware is busy, cannot submit */
-   if (chan->has_sg && xilinx_dma_is_running(chan) &&
-   !xilinx_dma_is_idle(chan)) {
-   dev_dbg(chan->dev, "DMA controller still busy\n");
+   if (list_empty(>pending_list))
return;
-   }
 
head_desc = list_first_entry(>pending_list,
 struct xilinx_dma_tx_descriptor, node);
@@ -1302,6 +1276,7 @@ static void xilinx_dma_start_transfer(struct 
xilinx_dma_chan *chan)
 

[PATCH v5 0/3] dmaengine: xilinx_dma: Bug fixes

[Kedareswara rao Appana]

This patch series fixes below bugs in DMA and VDMA IP's
---> Do not start VDMA until frame buffer is processed by the h/w Fix 
---> bug in Multi frame sotres handling in VDMA Fix issues w.r.to multi 
---> frame descriptors submit with AXI DMA S2MM(recv) Side.

Kedareswara rao Appana (3):
  dmaengine: xilinx_dma: Check for channel idle state before submitting
dma descriptor
  dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in
vdma
  dmaengine: xilinx_dma: Fix race condition in the driver for multiple
descriptor scenario

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |   2 +
 drivers/dma/xilinx/xilinx_dma.c| 265 -
 2 files changed, 156 insertions(+), 111 deletions(-)

-- 
2.1.2

[PATCH v5 0/3] dmaengine: xilinx_dma: Bug fixes

[Kedareswara rao Appana]

This patch series fixes below bugs in DMA and VDMA IP's
---> Do not start VDMA until frame buffer is processed by the h/w Fix 
---> bug in Multi frame sotres handling in VDMA Fix issues w.r.to multi 
---> frame descriptors submit with AXI DMA S2MM(recv) Side.

Kedareswara rao Appana (3):
  dmaengine: xilinx_dma: Check for channel idle state before submitting
dma descriptor
  dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in
vdma
  dmaengine: xilinx_dma: Fix race condition in the driver for multiple
descriptor scenario

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |   2 +
 drivers/dma/xilinx/xilinx_dma.c| 265 -
 2 files changed, 156 insertions(+), 111 deletions(-)

-- 
2.1.2

[PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario

[Kedareswara rao Appana]

When driver is handling AXI DMA SoftIP
When user submits multiple descriptors back to back on the S2MM(recv)
side with the current driver flow the last buffer descriptor next bd
points to a invalid location resulting the invalid data or errors in the
DMA engine.

This patch fixes this issue by creating a BD Chain during
channel allocation itself and use those BD's.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v5:
---> None.
Changes for v4:
---> None.
Changes for v3:
---> None.
Changes for v2:
---> None.

 drivers/dma/xilinx/xilinx_dma.c | 133 +---
 1 file changed, 83 insertions(+), 50 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 0e9c02e..af2159d 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -163,6 +163,7 @@
 #define XILINX_DMA_BD_SOP  BIT(27)
 #define XILINX_DMA_BD_EOP  BIT(26)
 #define XILINX_DMA_COALESCE_MAX255
+#define XILINX_DMA_NUM_DESCS   255
 #define XILINX_DMA_NUM_APP_WORDS   5
 
 /* Multi-Channel DMA Descriptor offsets*/
@@ -310,6 +311,7 @@ struct xilinx_dma_tx_descriptor {
  * @pending_list: Descriptors waiting
  * @active_list: Descriptors ready to submit
  * @done_list: Complete descriptors
+ * @free_seg_list: Free descriptors
  * @common: DMA common channel
  * @desc_pool: Descriptors pool
  * @dev: The dma device
@@ -331,7 +333,9 @@ struct xilinx_dma_tx_descriptor {
  * @desc_submitcount: Descriptor h/w submitted count
  * @residue: Residue for AXI DMA
  * @seg_v: Statically allocated segments base
+ * @seg_p: Physical allocated segments base
  * @cyclic_seg_v: Statically allocated segment base for cyclic transfers
+ * @cyclic_seg_p: Physical allocated segments base for cyclic dma
  * @start_transfer: Differentiate b/w DMA IP's transfer
  */
 struct xilinx_dma_chan {
@@ -342,6 +346,7 @@ struct xilinx_dma_chan {
struct list_head pending_list;
struct list_head active_list;
struct list_head done_list;
+   struct list_head free_seg_list;
struct dma_chan common;
struct dma_pool *desc_pool;
struct device *dev;
@@ -363,7 +368,9 @@ struct xilinx_dma_chan {
u32 desc_submitcount;
u32 residue;
struct xilinx_axidma_tx_segment *seg_v;
+   dma_addr_t seg_p;
struct xilinx_axidma_tx_segment *cyclic_seg_v;
+   dma_addr_t cyclic_seg_p;
void (*start_transfer)(struct xilinx_dma_chan *chan);
u16 tdest;
 };
@@ -569,17 +576,31 @@ static struct xilinx_axidma_tx_segment *
 xilinx_axidma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 {
struct xilinx_axidma_tx_segment *segment;
-   dma_addr_t phys;
-
-   segment = dma_pool_zalloc(chan->desc_pool, GFP_ATOMIC, );
-   if (!segment)
-   return NULL;
+   unsigned long flags;
 
-   segment->phys = phys;
+   spin_lock_irqsave(>lock, flags);
+   if (!list_empty(>free_seg_list)) {
+   segment = list_first_entry(>free_seg_list,
+  struct xilinx_axidma_tx_segment,
+  node);
+   list_del(>node);
+   }
+   spin_unlock_irqrestore(>lock, flags);
 
return segment;
 }
 
+static void xilinx_dma_clean_hw_desc(struct xilinx_axidma_desc_hw *hw)
+{
+   u32 next_desc = hw->next_desc;
+   u32 next_desc_msb = hw->next_desc_msb;
+
+   memset(hw, 0, sizeof(struct xilinx_axidma_desc_hw));
+
+   hw->next_desc = next_desc;
+   hw->next_desc_msb = next_desc_msb;
+}
+
 /**
  * xilinx_dma_free_tx_segment - Free transaction segment
  * @chan: Driver specific DMA channel
@@ -588,7 +609,9 @@ xilinx_axidma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 static void xilinx_dma_free_tx_segment(struct xilinx_dma_chan *chan,
struct xilinx_axidma_tx_segment *segment)
 {
-   dma_pool_free(chan->desc_pool, segment, segment->phys);
+   xilinx_dma_clean_hw_desc(>hw);
+
+   list_add_tail(>node, >free_seg_list);
 }
 
 /**
@@ -713,16 +736,26 @@ static void xilinx_dma_free_descriptors(struct 
xilinx_dma_chan *chan)
 static void xilinx_dma_free_chan_resources(struct dma_chan *dchan)
 {
struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
+   unsigned long flags;
 
dev_dbg(chan->dev, "Free all channel resources.\n");
 
xilinx_dma_free_descriptors(chan);
+
if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
-   xilinx_dma_free_tx_segment(chan, chan->cyclic_seg_v);
-   xilinx_dma_free_tx_segment(chan, chan->seg_v);
+   spin_lock_irqsave(>lock, flags);
+   INIT_LIST_HEAD(>free_seg_list);
+   spin_unlock_irqrestore(>lock, flags);
+
+   /* Free Memory that is allocated for cyclic DMA Mode */
+   dma_free_coherent(chan->dev, sizeof(*chan->cyclic_seg_v),
+  

[PATCH v5 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Kedareswara rao Appana]

When VDMA is configured for more than one frame in the h/w
for example h/w is configured for n number of frames and user
Submits n number of frames and triggered the DMA using issue_pending API.
In the current driver flow we are submitting one frame at a time
but we should submit all the n number of frames at one time as the h/w
Is configured for n number of frames.

This patch fixes this issue.

Reviewed-by: Jose Abreu 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v5:
---> Updated xlnx,fstore-config property to xlnx,fstore-enable
 and updated description as suggested by Rob.
Changes for v4:
---> Add Check for framestore configuration on Transmit case as well
 as suggested by Jose Abreu.
---> Modified the dev_dbg checks to dev_warn checks as suggested
 by Jose Abreu.
Changes for v3:
---> Added Checks for frame store configuration. If frame store
 Configuration is not present at the h/w level and user
 Submits less frames added debug prints in the driver as relevant.
Changes for v2:
---> Fixed race conditions in the driver as suggested by Jose Abreu
---> Fixed unnecessray if else checks in the vdma_start_transfer
 as suggested by Laurent Pinchart.

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |  2 +
 drivers/dma/xilinx/xilinx_dma.c| 78 +++---
 2 files changed, 57 insertions(+), 23 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfa..e951c09 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -66,6 +66,8 @@ Optional child node properties:
 Optional child node properties for VDMA:
 - xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
+- xlnx,fstore-enable: boolean; if defined, it indicates that controller
+   supports frame store configuration.
 Optional child node properties for AXI DMA:
 -dma-channels: Number of dma channels in child node.
 
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index be7eb41..0e9c02e 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -322,6 +322,7 @@ struct xilinx_dma_tx_descriptor {
  * @genlock: Support genlock mode
  * @err: Channel has errors
  * @idle: Check for channel idle
+ * @has_fstoreen: Check for frame store configuration
  * @tasklet: Cleanup work after irq
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
@@ -353,6 +354,7 @@ struct xilinx_dma_chan {
bool genlock;
bool err;
bool idle;
+   bool has_fstoreen;
struct tasklet_struct tasklet;
struct xilinx_vdma_config config;
bool flush_on_fsync;
@@ -990,6 +992,27 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (list_empty(>pending_list))
return;
 
+   /*
+* Note: When VDMA is built with default h/w configuration
+* User should submit frames upto H/W configured.
+* If users submits less than h/w configured
+* VDMA engine tries to write to a invalid location
+* Results undefined behaviour/memory corruption.
+*
+* If user would like to submit frames less than h/w capable
+* On S2MM side please enable debug info 13 at the h/w level
+* On MM2S side please enable debug info 6 at the h/w level
+* It will allows the frame buffers numbers to be modified at runtime.
+*/
+   if (!chan->has_fstoreen &&
+chan->desc_pendingcount < chan->num_frms) {
+   dev_warn(chan->dev, "Frame Store Configuration is not enabled 
at the\n");
+   dev_warn(chan->dev, "H/w level enable Debug info 13 or 6 at the 
h/w level\n");
+   dev_warn(chan->dev, "OR Submit the frames upto h/w 
Capable\n\r");
+
+   return;
+   }
+
desc = list_first_entry(>pending_list,
struct xilinx_dma_tx_descriptor, node);
tail_desc = list_last_entry(>pending_list,
@@ -1052,25 +1075,38 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->has_sg) {
dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
tail_segment->phys);
+   list_splice_tail_init(>pending_list, >active_list);
+   chan->desc_pendingcount = 0;
} else {
struct xilinx_vdma_tx_segment *segment, *last = NULL;
-   int i = 0;
+   int i = 0, j = 0;
 
if (chan->desc_submitcount < chan->num_frms)
i = chan->desc_submitcount;
 
-   list_for_each_entry(segment, >segments, node) {
-   if (chan->ext_addr)
-   

[PATCH v5 3/3] dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario

[Kedareswara rao Appana]

When driver is handling AXI DMA SoftIP
When user submits multiple descriptors back to back on the S2MM(recv)
side with the current driver flow the last buffer descriptor next bd
points to a invalid location resulting the invalid data or errors in the
DMA engine.

This patch fixes this issue by creating a BD Chain during
channel allocation itself and use those BD's.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v5:
---> None.
Changes for v4:
---> None.
Changes for v3:
---> None.
Changes for v2:
---> None.

 drivers/dma/xilinx/xilinx_dma.c | 133 +---
 1 file changed, 83 insertions(+), 50 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 0e9c02e..af2159d 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -163,6 +163,7 @@
 #define XILINX_DMA_BD_SOP  BIT(27)
 #define XILINX_DMA_BD_EOP  BIT(26)
 #define XILINX_DMA_COALESCE_MAX255
+#define XILINX_DMA_NUM_DESCS   255
 #define XILINX_DMA_NUM_APP_WORDS   5
 
 /* Multi-Channel DMA Descriptor offsets*/
@@ -310,6 +311,7 @@ struct xilinx_dma_tx_descriptor {
  * @pending_list: Descriptors waiting
  * @active_list: Descriptors ready to submit
  * @done_list: Complete descriptors
+ * @free_seg_list: Free descriptors
  * @common: DMA common channel
  * @desc_pool: Descriptors pool
  * @dev: The dma device
@@ -331,7 +333,9 @@ struct xilinx_dma_tx_descriptor {
  * @desc_submitcount: Descriptor h/w submitted count
  * @residue: Residue for AXI DMA
  * @seg_v: Statically allocated segments base
+ * @seg_p: Physical allocated segments base
  * @cyclic_seg_v: Statically allocated segment base for cyclic transfers
+ * @cyclic_seg_p: Physical allocated segments base for cyclic dma
  * @start_transfer: Differentiate b/w DMA IP's transfer
  */
 struct xilinx_dma_chan {
@@ -342,6 +346,7 @@ struct xilinx_dma_chan {
struct list_head pending_list;
struct list_head active_list;
struct list_head done_list;
+   struct list_head free_seg_list;
struct dma_chan common;
struct dma_pool *desc_pool;
struct device *dev;
@@ -363,7 +368,9 @@ struct xilinx_dma_chan {
u32 desc_submitcount;
u32 residue;
struct xilinx_axidma_tx_segment *seg_v;
+   dma_addr_t seg_p;
struct xilinx_axidma_tx_segment *cyclic_seg_v;
+   dma_addr_t cyclic_seg_p;
void (*start_transfer)(struct xilinx_dma_chan *chan);
u16 tdest;
 };
@@ -569,17 +576,31 @@ static struct xilinx_axidma_tx_segment *
 xilinx_axidma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 {
struct xilinx_axidma_tx_segment *segment;
-   dma_addr_t phys;
-
-   segment = dma_pool_zalloc(chan->desc_pool, GFP_ATOMIC, );
-   if (!segment)
-   return NULL;
+   unsigned long flags;
 
-   segment->phys = phys;
+   spin_lock_irqsave(>lock, flags);
+   if (!list_empty(>free_seg_list)) {
+   segment = list_first_entry(>free_seg_list,
+  struct xilinx_axidma_tx_segment,
+  node);
+   list_del(>node);
+   }
+   spin_unlock_irqrestore(>lock, flags);
 
return segment;
 }
 
+static void xilinx_dma_clean_hw_desc(struct xilinx_axidma_desc_hw *hw)
+{
+   u32 next_desc = hw->next_desc;
+   u32 next_desc_msb = hw->next_desc_msb;
+
+   memset(hw, 0, sizeof(struct xilinx_axidma_desc_hw));
+
+   hw->next_desc = next_desc;
+   hw->next_desc_msb = next_desc_msb;
+}
+
 /**
  * xilinx_dma_free_tx_segment - Free transaction segment
  * @chan: Driver specific DMA channel
@@ -588,7 +609,9 @@ xilinx_axidma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 static void xilinx_dma_free_tx_segment(struct xilinx_dma_chan *chan,
struct xilinx_axidma_tx_segment *segment)
 {
-   dma_pool_free(chan->desc_pool, segment, segment->phys);
+   xilinx_dma_clean_hw_desc(>hw);
+
+   list_add_tail(>node, >free_seg_list);
 }
 
 /**
@@ -713,16 +736,26 @@ static void xilinx_dma_free_descriptors(struct 
xilinx_dma_chan *chan)
 static void xilinx_dma_free_chan_resources(struct dma_chan *dchan)
 {
struct xilinx_dma_chan *chan = to_xilinx_chan(dchan);
+   unsigned long flags;
 
dev_dbg(chan->dev, "Free all channel resources.\n");
 
xilinx_dma_free_descriptors(chan);
+
if (chan->xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA) {
-   xilinx_dma_free_tx_segment(chan, chan->cyclic_seg_v);
-   xilinx_dma_free_tx_segment(chan, chan->seg_v);
+   spin_lock_irqsave(>lock, flags);
+   INIT_LIST_HEAD(>free_seg_list);
+   spin_unlock_irqrestore(>lock, flags);
+
+   /* Free Memory that is allocated for cyclic DMA Mode */
+   dma_free_coherent(chan->dev, sizeof(*chan->cyclic_seg_v),
+  

[PATCH v5 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Kedareswara rao Appana]

When VDMA is configured for more than one frame in the h/w
for example h/w is configured for n number of frames and user
Submits n number of frames and triggered the DMA using issue_pending API.
In the current driver flow we are submitting one frame at a time
but we should submit all the n number of frames at one time as the h/w
Is configured for n number of frames.

This patch fixes this issue.

Reviewed-by: Jose Abreu 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v5:
---> Updated xlnx,fstore-config property to xlnx,fstore-enable
 and updated description as suggested by Rob.
Changes for v4:
---> Add Check for framestore configuration on Transmit case as well
 as suggested by Jose Abreu.
---> Modified the dev_dbg checks to dev_warn checks as suggested
 by Jose Abreu.
Changes for v3:
---> Added Checks for frame store configuration. If frame store
 Configuration is not present at the h/w level and user
 Submits less frames added debug prints in the driver as relevant.
Changes for v2:
---> Fixed race conditions in the driver as suggested by Jose Abreu
---> Fixed unnecessray if else checks in the vdma_start_transfer
 as suggested by Laurent Pinchart.

 .../devicetree/bindings/dma/xilinx/xilinx_dma.txt  |  2 +
 drivers/dma/xilinx/xilinx_dma.c| 78 +++---
 2 files changed, 57 insertions(+), 23 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfa..e951c09 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -66,6 +66,8 @@ Optional child node properties:
 Optional child node properties for VDMA:
 - xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
+- xlnx,fstore-enable: boolean; if defined, it indicates that controller
+   supports frame store configuration.
 Optional child node properties for AXI DMA:
 -dma-channels: Number of dma channels in child node.
 
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index be7eb41..0e9c02e 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -322,6 +322,7 @@ struct xilinx_dma_tx_descriptor {
  * @genlock: Support genlock mode
  * @err: Channel has errors
  * @idle: Check for channel idle
+ * @has_fstoreen: Check for frame store configuration
  * @tasklet: Cleanup work after irq
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
@@ -353,6 +354,7 @@ struct xilinx_dma_chan {
bool genlock;
bool err;
bool idle;
+   bool has_fstoreen;
struct tasklet_struct tasklet;
struct xilinx_vdma_config config;
bool flush_on_fsync;
@@ -990,6 +992,27 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (list_empty(>pending_list))
return;
 
+   /*
+* Note: When VDMA is built with default h/w configuration
+* User should submit frames upto H/W configured.
+* If users submits less than h/w configured
+* VDMA engine tries to write to a invalid location
+* Results undefined behaviour/memory corruption.
+*
+* If user would like to submit frames less than h/w capable
+* On S2MM side please enable debug info 13 at the h/w level
+* On MM2S side please enable debug info 6 at the h/w level
+* It will allows the frame buffers numbers to be modified at runtime.
+*/
+   if (!chan->has_fstoreen &&
+chan->desc_pendingcount < chan->num_frms) {
+   dev_warn(chan->dev, "Frame Store Configuration is not enabled 
at the\n");
+   dev_warn(chan->dev, "H/w level enable Debug info 13 or 6 at the 
h/w level\n");
+   dev_warn(chan->dev, "OR Submit the frames upto h/w 
Capable\n\r");
+
+   return;
+   }
+
desc = list_first_entry(>pending_list,
struct xilinx_dma_tx_descriptor, node);
tail_desc = list_last_entry(>pending_list,
@@ -1052,25 +1075,38 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->has_sg) {
dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
tail_segment->phys);
+   list_splice_tail_init(>pending_list, >active_list);
+   chan->desc_pendingcount = 0;
} else {
struct xilinx_vdma_tx_segment *segment, *last = NULL;
-   int i = 0;
+   int i = 0, j = 0;
 
if (chan->desc_submitcount < chan->num_frms)
i = chan->desc_submitcount;
 
-   list_for_each_entry(segment, >segments, node) {
-   if (chan->ext_addr)
-   vdma_desc_write_64(chan,
-  

Re: [GIT PULL] namespace related fixes for 4.10-rc3

[Al Viro]

On Sat, Jan 07, 2017 at 06:29:52AM +, Al Viro wrote:
> On Sat, Jan 07, 2017 at 06:30:05PM +1300, Eric W. Biederman wrote:
> 
> > Eric W. Biederman (3):
> >   mnt: Protect the mountpoint hashtable with mount_lock
> ACK
> 
> >   mnt: Tuck mounts under others instead of creating shadow/side mounts.
> 
> NAK; you have reintroduced put_mountpoint() outside of mount lock in there
> and you've got seriously confused umount side of the things.

PS: details are in my reply (admittedly, sent only ~20 minutes
before your pull request) to your patch.  Check Message-ID
<20170107050644.ga12...@zeniv.linux.org.uk>

My apologies for not getting to it yesterday (the patch was posted a couple of
days ago, AFAICS) - I'd been off-net since Wednesday, just got back ;-/

Re: [GIT PULL] namespace related fixes for 4.10-rc3

[Al Viro]

On Sat, Jan 07, 2017 at 06:29:52AM +, Al Viro wrote:
> On Sat, Jan 07, 2017 at 06:30:05PM +1300, Eric W. Biederman wrote:
> 
> > Eric W. Biederman (3):
> >   mnt: Protect the mountpoint hashtable with mount_lock
> ACK
> 
> >   mnt: Tuck mounts under others instead of creating shadow/side mounts.
> 
> NAK; you have reintroduced put_mountpoint() outside of mount lock in there
> and you've got seriously confused umount side of the things.

PS: details are in my reply (admittedly, sent only ~20 minutes
before your pull request) to your patch.  Check Message-ID
<20170107050644.ga12...@zeniv.linux.org.uk>

My apologies for not getting to it yesterday (the patch was posted a couple of
days ago, AFAICS) - I'd been off-net since Wednesday, just got back ;-/

Re: [GIT PULL] namespace related fixes for 4.10-rc3

[Al Viro]

On Sat, Jan 07, 2017 at 06:30:05PM +1300, Eric W. Biederman wrote:

> Eric W. Biederman (3):
>   mnt: Protect the mountpoint hashtable with mount_lock
ACK

>   mnt: Tuck mounts under others instead of creating shadow/side mounts.

NAK; you have reintroduced put_mountpoint() outside of mount lock in there
and you've got seriously confused umount side of the things.

>   libfs: Modify mount_pseudo_xattr to be clear it is not a userspace mount
ACK

> Zhou Chengming (1):
>   sysctl: Drop reference added by grab_header in proc_sys_readdir

ACK

The rest of the queue is fine.

Re: [GIT PULL] namespace related fixes for 4.10-rc3

[Al Viro]

On Sat, Jan 07, 2017 at 06:30:05PM +1300, Eric W. Biederman wrote:

> Eric W. Biederman (3):
>   mnt: Protect the mountpoint hashtable with mount_lock
ACK

>   mnt: Tuck mounts under others instead of creating shadow/side mounts.

NAK; you have reintroduced put_mountpoint() outside of mount lock in there
and you've got seriously confused umount side of the things.

>   libfs: Modify mount_pseudo_xattr to be clear it is not a userspace mount
ACK

> Zhou Chengming (1):
>   sysctl: Drop reference added by grab_header in proc_sys_readdir

ACK

The rest of the queue is fine.

Re: [V9fs-developer] 9pfs hangs since 4.7

[Al Viro]

On Fri, Jan 06, 2017 at 02:52:35PM +0100, Greg Kurz wrote:

> Looking at the tag numbers, I think we're hitting the hardcoded limit of 128
> simultaneous requests in QEMU (which doesn't produce any error, new requests
> are silently dropped).
> 
> Tuomas, can you change MAX_REQ to some higher value (< 65535 since tag is
> 2-byte and 0x is reserved) to confirm ?

Huh?

Just how is a client supposed to cope with that behaviour?  9P is not
SunRPC - there's a reason why it doesn't live on top of UDP.  Sure, it's
datagram-oriented, but it really wants reliable transport...

Setting the ring size at MAX_REQ is fine; that'll give you ENOSPC on
attempt to put a request there, and p9_virtio_request() will wait for
things to clear, but if you've accepted a request, that's bloody it -
you really should go and handle it.

How does it happen, anyway?  qemu-side, I mean...  Does it move the buffer
to used ring as soon as it has fetched the request?  AFAICS, it doesn't -
virtqueue_push() is called just before pdu_free(); we might get complications
in case of TFLUSH handling (queue with MAX_REQ-1 requests submitted, TFLUSH
arrives, cancel_pdu is found and ->cancelled is set on it, then v9fs_flush()
waits for it to complete.  Once the damn thing is done, buffer is released by
virtqueue_push(), but pdu freeing is delayed until v9fs_flush() gets woken
up.  In the meanwhile, another request arrives into the slot of freed by
that virtqueue_push() and we are out of pdus.

So it could happen, and the things might get unpleasant to some extent, but...
no TFLUSH had been present in all that traffic.  And none of the stuck
processes had been spinning in p9_virtio_request(), so they *did* find
ring slots...

Re: [V9fs-developer] 9pfs hangs since 4.7

[Al Viro]

On Fri, Jan 06, 2017 at 02:52:35PM +0100, Greg Kurz wrote:

> Looking at the tag numbers, I think we're hitting the hardcoded limit of 128
> simultaneous requests in QEMU (which doesn't produce any error, new requests
> are silently dropped).
> 
> Tuomas, can you change MAX_REQ to some higher value (< 65535 since tag is
> 2-byte and 0x is reserved) to confirm ?

Huh?

Just how is a client supposed to cope with that behaviour?  9P is not
SunRPC - there's a reason why it doesn't live on top of UDP.  Sure, it's
datagram-oriented, but it really wants reliable transport...

Setting the ring size at MAX_REQ is fine; that'll give you ENOSPC on
attempt to put a request there, and p9_virtio_request() will wait for
things to clear, but if you've accepted a request, that's bloody it -
you really should go and handle it.

How does it happen, anyway?  qemu-side, I mean...  Does it move the buffer
to used ring as soon as it has fetched the request?  AFAICS, it doesn't -
virtqueue_push() is called just before pdu_free(); we might get complications
in case of TFLUSH handling (queue with MAX_REQ-1 requests submitted, TFLUSH
arrives, cancel_pdu is found and ->cancelled is set on it, then v9fs_flush()
waits for it to complete.  Once the damn thing is done, buffer is released by
virtqueue_push(), but pdu freeing is delayed until v9fs_flush() gets woken
up.  In the meanwhile, another request arrives into the slot of freed by
that virtqueue_push() and we are out of pdus.

So it could happen, and the things might get unpleasant to some extent, but...
no TFLUSH had been present in all that traffic.  And none of the stuck
processes had been spinning in p9_virtio_request(), so they *did* find
ring slots...

[PATCH v1 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

[Baoyou Xie]

This patch adds thermal driver for ZTE's zx2967 family.

Signed-off-by: Baoyou Xie 
---
 drivers/thermal/Kconfig  |   6 +
 drivers/thermal/Makefile |   1 +
 drivers/thermal/zx2967_thermal.c | 241 +++
 3 files changed, 248 insertions(+)
 create mode 100644 drivers/thermal/zx2967_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 18f2de6..0dd597e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -445,3 +445,9 @@ config BCM2835_THERMAL
  Support for thermal sensors on Broadcom bcm2835 SoCs.
 
 endif
+
+config ZX2967_THERMAL
+   tristate "Thermal sensors on zx2967 SoC"
+   depends on ARCH_ZX
+   help
+ Support for thermal sensors on ZTE zx2967 SoCs.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 677c6d9..c00c05e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
 obj-$(CONFIG_MTK_THERMAL)  += mtk_thermal.o
 obj-$(CONFIG_GENERIC_ADC_THERMAL)  += thermal-generic-adc.o
 obj-$(CONFIG_BCM2835_THERMAL)  += bcm2835_thermal.o
+obj-$(CONFIG_ZX2967_THERMAL)   += zx2967_thermal.o
diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_thermal.c
new file mode 100644
index 000..1aef070
--- /dev/null
+++ b/drivers/thermal/zx2967_thermal.c
@@ -0,0 +1,241 @@
+/*
+ * ZTE's zx2967 family thermal sensor driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie 
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* DCF Control Register */
+#define ZX2967_THERMAL_DCF 0x4
+
+/* Selection Register */
+#define ZX2967_THERMAL_SEL 0x8
+
+/* Control Register */
+#define ZX2967_THERMAL_CTRL0x10
+
+#define ZX2967_THERMAL_ID_MASK (0x18)
+
+struct zx2967_thermal_sensor {
+   struct zx2967_thermal_priv *priv;
+   struct thermal_zone_device *tzd;
+   int id;
+};
+
+#define NUM_SENSORS1
+
+struct zx2967_thermal_priv {
+   struct zx2967_thermal_sensorsensors[NUM_SENSORS];
+   struct mutexlock;
+   struct clk  *clk_gate;
+   struct clk  *pclk;
+   void __iomem*regs;
+   struct pinctrl  *pinmux_dvi0_d3;
+   struct pinctrl  *pinmux_dvi0_d4;
+   struct pinctrl  *pinmux_dvi0_d5;
+};
+
+static int zx2967_thermal_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+
+   if (priv && priv->pclk)
+   clk_disable_unprepare(priv->pclk);
+
+   if (priv && priv->clk_gate)
+   clk_disable_unprepare(priv->clk_gate);
+   dev_info(dev, "suspended\n");
+
+   return 0;
+}
+
+static int zx2967_thermal_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+   int error;
+
+   error = clk_prepare_enable(priv->clk_gate);
+   if (error)
+   return error;
+
+   error = clk_prepare_enable(priv->pclk);
+   if (error)
+   return error;
+
+   dev_info(dev, "resumed\n");
+
+   return 0;
+}
+
+static int zx2967_thermal_get_temp(void *data, int *temp)
+{
+   void __iomem *regs;
+   struct zx2967_thermal_sensor *sensor = data;
+   struct zx2967_thermal_priv *priv = sensor->priv;
+   unsigned long timeout = jiffies + msecs_to_jiffies(100);
+   u32 val, sel_id;
+
+   regs = priv->regs;
+   mutex_lock(>lock);
+
+   writel_relaxed(0, regs);
+   writel_relaxed(2, regs + ZX2967_THERMAL_DCF);
+
+   val = readl_relaxed(regs + ZX2967_THERMAL_SEL);
+   val &= ~ZX2967_THERMAL_ID_MASK;
+   sel_id = sensor->id ? 8 : 0x10;
+   val |= sel_id;
+   writel_relaxed(val, regs + ZX2967_THERMAL_SEL);
+
+   usleep_range(100, 300);
+   while (!(readl_relaxed(regs + ZX2967_THERMAL_CTRL) & 0x1000)) {
+   if (time_after(jiffies, timeout)) {
+   pr_err("*** Thermal sensor %d data timeout\n",
+ sensor->id);
+   mutex_unlock(>lock);
+   return -EIO;
+   }
+   }
+
+   writel_relaxed(3, regs + ZX2967_THERMAL_DCF);
+   val = readl_relaxed(regs + ZX2967_THERMAL_CTRL) & 0xfff;
+   writel_relaxed(1, regs);
+
+   /** Calculate temperature */
+   *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static struct thermal_zone_of_device_ops zx2967_of_thermal_ops = {
+   .get_temp = 

[PATCH v1 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

[Baoyou Xie]

This patch adds thermal driver for ZTE's zx2967 family.

Signed-off-by: Baoyou Xie 
---
 drivers/thermal/Kconfig  |   6 +
 drivers/thermal/Makefile |   1 +
 drivers/thermal/zx2967_thermal.c | 241 +++
 3 files changed, 248 insertions(+)
 create mode 100644 drivers/thermal/zx2967_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 18f2de6..0dd597e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -445,3 +445,9 @@ config BCM2835_THERMAL
  Support for thermal sensors on Broadcom bcm2835 SoCs.
 
 endif
+
+config ZX2967_THERMAL
+   tristate "Thermal sensors on zx2967 SoC"
+   depends on ARCH_ZX
+   help
+ Support for thermal sensors on ZTE zx2967 SoCs.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 677c6d9..c00c05e 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
 obj-$(CONFIG_MTK_THERMAL)  += mtk_thermal.o
 obj-$(CONFIG_GENERIC_ADC_THERMAL)  += thermal-generic-adc.o
 obj-$(CONFIG_BCM2835_THERMAL)  += bcm2835_thermal.o
+obj-$(CONFIG_ZX2967_THERMAL)   += zx2967_thermal.o
diff --git a/drivers/thermal/zx2967_thermal.c b/drivers/thermal/zx2967_thermal.c
new file mode 100644
index 000..1aef070
--- /dev/null
+++ b/drivers/thermal/zx2967_thermal.c
@@ -0,0 +1,241 @@
+/*
+ * ZTE's zx2967 family thermal sensor driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie 
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* DCF Control Register */
+#define ZX2967_THERMAL_DCF 0x4
+
+/* Selection Register */
+#define ZX2967_THERMAL_SEL 0x8
+
+/* Control Register */
+#define ZX2967_THERMAL_CTRL0x10
+
+#define ZX2967_THERMAL_ID_MASK (0x18)
+
+struct zx2967_thermal_sensor {
+   struct zx2967_thermal_priv *priv;
+   struct thermal_zone_device *tzd;
+   int id;
+};
+
+#define NUM_SENSORS1
+
+struct zx2967_thermal_priv {
+   struct zx2967_thermal_sensorsensors[NUM_SENSORS];
+   struct mutexlock;
+   struct clk  *clk_gate;
+   struct clk  *pclk;
+   void __iomem*regs;
+   struct pinctrl  *pinmux_dvi0_d3;
+   struct pinctrl  *pinmux_dvi0_d4;
+   struct pinctrl  *pinmux_dvi0_d5;
+};
+
+static int zx2967_thermal_suspend(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+
+   if (priv && priv->pclk)
+   clk_disable_unprepare(priv->pclk);
+
+   if (priv && priv->clk_gate)
+   clk_disable_unprepare(priv->clk_gate);
+   dev_info(dev, "suspended\n");
+
+   return 0;
+}
+
+static int zx2967_thermal_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct zx2967_thermal_priv *priv = platform_get_drvdata(pdev);
+   int error;
+
+   error = clk_prepare_enable(priv->clk_gate);
+   if (error)
+   return error;
+
+   error = clk_prepare_enable(priv->pclk);
+   if (error)
+   return error;
+
+   dev_info(dev, "resumed\n");
+
+   return 0;
+}
+
+static int zx2967_thermal_get_temp(void *data, int *temp)
+{
+   void __iomem *regs;
+   struct zx2967_thermal_sensor *sensor = data;
+   struct zx2967_thermal_priv *priv = sensor->priv;
+   unsigned long timeout = jiffies + msecs_to_jiffies(100);
+   u32 val, sel_id;
+
+   regs = priv->regs;
+   mutex_lock(>lock);
+
+   writel_relaxed(0, regs);
+   writel_relaxed(2, regs + ZX2967_THERMAL_DCF);
+
+   val = readl_relaxed(regs + ZX2967_THERMAL_SEL);
+   val &= ~ZX2967_THERMAL_ID_MASK;
+   sel_id = sensor->id ? 8 : 0x10;
+   val |= sel_id;
+   writel_relaxed(val, regs + ZX2967_THERMAL_SEL);
+
+   usleep_range(100, 300);
+   while (!(readl_relaxed(regs + ZX2967_THERMAL_CTRL) & 0x1000)) {
+   if (time_after(jiffies, timeout)) {
+   pr_err("*** Thermal sensor %d data timeout\n",
+ sensor->id);
+   mutex_unlock(>lock);
+   return -EIO;
+   }
+   }
+
+   writel_relaxed(3, regs + ZX2967_THERMAL_DCF);
+   val = readl_relaxed(regs + ZX2967_THERMAL_CTRL) & 0xfff;
+   writel_relaxed(1, regs);
+
+   /** Calculate temperature */
+   *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static struct thermal_zone_of_device_ops zx2967_of_thermal_ops = {
+   .get_temp = zx2967_thermal_get_temp,
+};
+
+static int 

[PATCH v1 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture

[Baoyou Xie]

Add the zx2967 thermal drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.

Signed-off-by: Baoyou Xie 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 64f04df..2593296 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1981,6 +1981,7 @@ S:Maintained
 F: arch/arm/mach-zx/
 F: drivers/clk/zte/
 F: drivers/soc/zte/
+F: drivers/thermal/zx*
 F: Documentation/devicetree/bindings/arm/zte.txt
 F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
 F: Documentation/devicetree/bindings/soc/zte/
-- 
2.7.4

[PATCH v1 2/3] MAINTAINERS: add zx2967 thermal drivers to ARM ZTE architecture

[Baoyou Xie]

Add the zx2967 thermal drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.

Signed-off-by: Baoyou Xie 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 64f04df..2593296 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1981,6 +1981,7 @@ S:Maintained
 F: arch/arm/mach-zx/
 F: drivers/clk/zte/
 F: drivers/soc/zte/
+F: drivers/thermal/zx*
 F: Documentation/devicetree/bindings/arm/zte.txt
 F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
 F: Documentation/devicetree/bindings/soc/zte/
-- 
2.7.4

[PATCH v1 1/3] dt: bindings: add thermal device driver for zx2967

[Baoyou Xie]

This patch adds dt-binding documentation for zx2967 family thermal sensor.

Signed-off-by: Baoyou Xie 
---
 .../devicetree/bindings/thermal/zx2967-thermal.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/zx2967-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt 
b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
new file mode 100644
index 000..2633964
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
@@ -0,0 +1,22 @@
+* ZTE zx2967 family Thermal
+
+Required Properties:
+- compatible: should be one of the following.
+* zte,zx2967-thermal
+* zte,zx296718-thermal
+- reg: physical base address of the controller and length of memory mapped
+region.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "tempsensor_gate" for the topcrm clock.
+  "tempsensor_pclk" for the apb clock.
+- #thermal-sensor-cells: must be 0.
+
+Example:
+
+   tempsensor: tempsensor@148a000 {
+   compatible = "zte,zx2967-thermal";
+   reg = <0x0148a000 0x20>;
+   clocks = < TEMPSENSOR_GATE>, < AUDIO_TS_PCLK>;
+   clock-names = "tempsensor_gate", "tempsensor_pclk";
+   #thermal-sensor-cells = <0>;
+   };
-- 
2.7.4

[PATCH v1 1/3] dt: bindings: add thermal device driver for zx2967

[Baoyou Xie]

This patch adds dt-binding documentation for zx2967 family thermal sensor.

Signed-off-by: Baoyou Xie 
---
 .../devicetree/bindings/thermal/zx2967-thermal.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/zx2967-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt 
b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
new file mode 100644
index 000..2633964
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
@@ -0,0 +1,22 @@
+* ZTE zx2967 family Thermal
+
+Required Properties:
+- compatible: should be one of the following.
+* zte,zx2967-thermal
+* zte,zx296718-thermal
+- reg: physical base address of the controller and length of memory mapped
+region.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "tempsensor_gate" for the topcrm clock.
+  "tempsensor_pclk" for the apb clock.
+- #thermal-sensor-cells: must be 0.
+
+Example:
+
+   tempsensor: tempsensor@148a000 {
+   compatible = "zte,zx2967-thermal";
+   reg = <0x0148a000 0x20>;
+   clocks = < TEMPSENSOR_GATE>, < AUDIO_TS_PCLK>;
+   clock-names = "tempsensor_gate", "tempsensor_pclk";
+   #thermal-sensor-cells = <0>;
+   };
-- 
2.7.4

[GIT PULL] namespace related fixes for 4.10-rc3

[Eric W. Biederman]

Linus,

Please pull the for-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
for-linus

   HEAD: cd293bfacd57928627ef7da6194e0cbe24db3291 sysctl: Drop reference added 
by grab_header in proc_sys_readdir

This tree contains 5 fixes.

The first is a fix for a race that can causes oopses under the right
circumstances, and that someone just recently encountered.

The second is a fix that removes the possibility of creating unbounded
chains in the mount hash table.  After a lot of back and forth this fix
has finally matured into something mergeable.

Past that are several small trivial correct fixes.  A real issue that
was blocking development of an out of tree driver, but does not appear
to have caused any actual problems for in-tree code.  A potential
deadlock that was reported by lockdep.  And a deadlock people have
experienced and took the time to track down caused by a cleanup that
removed the code to drop a reference count.

Andrei Vagin (1):
  pid: fix lockdep deadlock warning due to ucount_lock

Eric W. Biederman (3):
  mnt: Protect the mountpoint hashtable with mount_lock
  mnt: Tuck mounts under others instead of creating shadow/side mounts.
  libfs: Modify mount_pseudo_xattr to be clear it is not a userspace mount

Zhou Chengming (1):
  sysctl: Drop reference added by grab_header in proc_sys_readdir

 fs/dcache.c|   7 +-
 fs/libfs.c |   3 +-
 fs/mount.h |   1 -
 fs/namespace.c | 174 +
 fs/pnode.c |  27 ++--
 fs/pnode.h |   2 +
 fs/proc/proc_sysctl.c  |   3 +-
 kernel/pid_namespace.c |  10 +--
 8 files changed, 142 insertions(+), 85 deletions(-)

Eric

[GIT PULL] namespace related fixes for 4.10-rc3

[Eric W. Biederman]

Linus,

Please pull the for-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
for-linus

   HEAD: cd293bfacd57928627ef7da6194e0cbe24db3291 sysctl: Drop reference added 
by grab_header in proc_sys_readdir

This tree contains 5 fixes.

The first is a fix for a race that can causes oopses under the right
circumstances, and that someone just recently encountered.

The second is a fix that removes the possibility of creating unbounded
chains in the mount hash table.  After a lot of back and forth this fix
has finally matured into something mergeable.

Past that are several small trivial correct fixes.  A real issue that
was blocking development of an out of tree driver, but does not appear
to have caused any actual problems for in-tree code.  A potential
deadlock that was reported by lockdep.  And a deadlock people have
experienced and took the time to track down caused by a cleanup that
removed the code to drop a reference count.

Andrei Vagin (1):
  pid: fix lockdep deadlock warning due to ucount_lock

Eric W. Biederman (3):
  mnt: Protect the mountpoint hashtable with mount_lock
  mnt: Tuck mounts under others instead of creating shadow/side mounts.
  libfs: Modify mount_pseudo_xattr to be clear it is not a userspace mount

Zhou Chengming (1):
  sysctl: Drop reference added by grab_header in proc_sys_readdir

 fs/dcache.c|   7 +-
 fs/libfs.c |   3 +-
 fs/mount.h |   1 -
 fs/namespace.c | 174 +
 fs/pnode.c |  27 ++--
 fs/pnode.h |   2 +
 fs/proc/proc_sysctl.c  |   3 +-
 kernel/pid_namespace.c |  10 +--
 8 files changed, 142 insertions(+), 85 deletions(-)

Eric

[PATCH perf/core 4/4] perf-probe: Find probe events without target module

[Masami Hiramatsu]

Find probe events without -m "module" option. If perf-probe
failed to find given function in kernel image, it tries to
find same symbol and module in kallsyms, and retry search
in the found module. E.g.

  # perf probe -D i915_capabilities
  p:probe/i915_capabilities i915:i915_capabilities+0

Note: without -m option, perf probe can not find inlined
function since there is no symbol information in kallsyms.

Signed-off-by: Masami Hiramatsu 
Suggested-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c |   74 ++---
 1 file changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 6a6f44d..09bd093 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -858,11 +858,7 @@ static int try_to_find_probe_trace_events(struct 
perf_probe_event *pev,
 
debuginfo__delete(dinfo);
 
-   if (ntevs == 0) {   /* No error but failed to find probe point. */
-   pr_warning("Probe point '%s' not found.\n",
-  synthesize_perf_probe_point(>point));
-   return -ENOENT;
-   } else if (ntevs < 0) {
+   if (ntevs < 0) {
/* Error path : ntevs < 0 */
pr_debug("An error occurred in debuginfo analysis (%d).\n", 
ntevs);
if (ntevs == -EBADF)
@@ -2073,8 +2069,10 @@ static int find_perf_probe_point_from_map(struct 
probe_trace_point *tp,
} else {
if (tp->symbol && !addr) {
if (kernel_get_symbol_address_by_name(tp->symbol,
-   , true, false) < 0)
+   , true, false) < 0) {
+   ret = 0;
goto out;
+   }
}
if (addr) {
addr += tp->offset;
@@ -2829,9 +2827,7 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
 */
num_matched_functions = find_probe_functions(map, pp->function, syms);
if (num_matched_functions == 0) {
-   pr_err("Failed to find symbol %s in %s\n", pp->function,
-   pev->target ? : "kernel");
-   ret = -ENOENT;
+   ret = 0;
goto out;
} else if (num_matched_functions > probe_conf.max_probes) {
pr_err("Too many functions matched in %s\n",
@@ -3233,6 +3229,43 @@ static int find_probe_trace_events_from_cache(struct 
perf_probe_event *pev,
return ret;
 }
 
+static int __convert_to_probe_trace_events(struct perf_probe_event *pev,
+  struct probe_trace_event **tevs)
+{
+   int ret;
+
+   /* At first, we need to lookup cache entry */
+   ret = find_probe_trace_events_from_cache(pev, tevs);
+   if (ret > 0 || pev->sdt)/* SDT can be found only in the cache */
+   return ret == 0 ? -ENOENT : ret; /* Found in probe cache */
+
+   /* Convert perf_probe_event with debuginfo */
+   ret = try_to_find_probe_trace_events(pev, tevs);
+   if (ret != 0)
+   return ret; /* Found in debuginfo or got an error */
+
+   return find_probe_trace_events_from_map(pev, tevs);
+}
+
+static char *find_module_from_kallsyms(const char *symbol_name)
+{
+   struct machine *machine = machine__new_kallsyms();
+   struct symbol *sym;
+   struct map *map;
+   char *module;
+
+   pr_debug("Try to find module for %s\n", symbol_name);
+   sym = machine__find_kernel_function_by_name(machine, symbol_name, );
+   if (!sym || map->dso->short_name[0] != '[')
+   return NULL;
+   pr_debug("Found: %s in %s\n", sym->name, map->dso->short_name);
+   module = strdup(map->dso->short_name + 1);
+   if (module)
+   module[strlen(module) - 1] = '\0';
+
+   return module;
+}
+
 static int convert_to_probe_trace_events(struct perf_probe_event *pev,
 struct probe_trace_event **tevs)
 {
@@ -3255,17 +3288,20 @@ static int convert_to_probe_trace_events(struct 
perf_probe_event *pev,
if (ret > 0)
return ret;
 
-   /* At first, we need to lookup cache entry */
-   ret = find_probe_trace_events_from_cache(pev, tevs);
-   if (ret > 0 || pev->sdt)/* SDT can be found only in the cache */
-   return ret == 0 ? -ENOENT : ret; /* Found in probe cache */
-
-   /* Convert perf_probe_event with debuginfo */
-   ret = try_to_find_probe_trace_events(pev, tevs);
-   if (ret != 0)
-   return ret; /* Found in debuginfo or got an error */
+   ret = __convert_to_probe_trace_events(pev, tevs);
+   /* Not found. will retry to check kmodule if possible */
+   if (ret == 0 && !pev->uprobes && 

[PATCH perf/core 4/4] perf-probe: Find probe events without target module

[Masami Hiramatsu]

Find probe events without -m "module" option. If perf-probe
failed to find given function in kernel image, it tries to
find same symbol and module in kallsyms, and retry search
in the found module. E.g.

  # perf probe -D i915_capabilities
  p:probe/i915_capabilities i915:i915_capabilities+0

Note: without -m option, perf probe can not find inlined
function since there is no symbol information in kallsyms.

Signed-off-by: Masami Hiramatsu 
Suggested-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/probe-event.c |   74 ++---
 1 file changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 6a6f44d..09bd093 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -858,11 +858,7 @@ static int try_to_find_probe_trace_events(struct 
perf_probe_event *pev,
 
debuginfo__delete(dinfo);
 
-   if (ntevs == 0) {   /* No error but failed to find probe point. */
-   pr_warning("Probe point '%s' not found.\n",
-  synthesize_perf_probe_point(>point));
-   return -ENOENT;
-   } else if (ntevs < 0) {
+   if (ntevs < 0) {
/* Error path : ntevs < 0 */
pr_debug("An error occurred in debuginfo analysis (%d).\n", 
ntevs);
if (ntevs == -EBADF)
@@ -2073,8 +2069,10 @@ static int find_perf_probe_point_from_map(struct 
probe_trace_point *tp,
} else {
if (tp->symbol && !addr) {
if (kernel_get_symbol_address_by_name(tp->symbol,
-   , true, false) < 0)
+   , true, false) < 0) {
+   ret = 0;
goto out;
+   }
}
if (addr) {
addr += tp->offset;
@@ -2829,9 +2827,7 @@ static int find_probe_trace_events_from_map(struct 
perf_probe_event *pev,
 */
num_matched_functions = find_probe_functions(map, pp->function, syms);
if (num_matched_functions == 0) {
-   pr_err("Failed to find symbol %s in %s\n", pp->function,
-   pev->target ? : "kernel");
-   ret = -ENOENT;
+   ret = 0;
goto out;
} else if (num_matched_functions > probe_conf.max_probes) {
pr_err("Too many functions matched in %s\n",
@@ -3233,6 +3229,43 @@ static int find_probe_trace_events_from_cache(struct 
perf_probe_event *pev,
return ret;
 }
 
+static int __convert_to_probe_trace_events(struct perf_probe_event *pev,
+  struct probe_trace_event **tevs)
+{
+   int ret;
+
+   /* At first, we need to lookup cache entry */
+   ret = find_probe_trace_events_from_cache(pev, tevs);
+   if (ret > 0 || pev->sdt)/* SDT can be found only in the cache */
+   return ret == 0 ? -ENOENT : ret; /* Found in probe cache */
+
+   /* Convert perf_probe_event with debuginfo */
+   ret = try_to_find_probe_trace_events(pev, tevs);
+   if (ret != 0)
+   return ret; /* Found in debuginfo or got an error */
+
+   return find_probe_trace_events_from_map(pev, tevs);
+}
+
+static char *find_module_from_kallsyms(const char *symbol_name)
+{
+   struct machine *machine = machine__new_kallsyms();
+   struct symbol *sym;
+   struct map *map;
+   char *module;
+
+   pr_debug("Try to find module for %s\n", symbol_name);
+   sym = machine__find_kernel_function_by_name(machine, symbol_name, );
+   if (!sym || map->dso->short_name[0] != '[')
+   return NULL;
+   pr_debug("Found: %s in %s\n", sym->name, map->dso->short_name);
+   module = strdup(map->dso->short_name + 1);
+   if (module)
+   module[strlen(module) - 1] = '\0';
+
+   return module;
+}
+
 static int convert_to_probe_trace_events(struct perf_probe_event *pev,
 struct probe_trace_event **tevs)
 {
@@ -3255,17 +3288,20 @@ static int convert_to_probe_trace_events(struct 
perf_probe_event *pev,
if (ret > 0)
return ret;
 
-   /* At first, we need to lookup cache entry */
-   ret = find_probe_trace_events_from_cache(pev, tevs);
-   if (ret > 0 || pev->sdt)/* SDT can be found only in the cache */
-   return ret == 0 ? -ENOENT : ret; /* Found in probe cache */
-
-   /* Convert perf_probe_event with debuginfo */
-   ret = try_to_find_probe_trace_events(pev, tevs);
-   if (ret != 0)
-   return ret; /* Found in debuginfo or got an error */
+   ret = __convert_to_probe_trace_events(pev, tevs);
+   /* Not found. will retry to check kmodule if possible */
+   if (ret == 0 && !pev->uprobes && !pev->target) {
+   pev->target = 

[PATCH perf/core 3/4] perf-probe: Fix to probe on gcc generated functions in modules

[Masami Hiramatsu]

Fix to probe on gcc generated functions on modules. Since
probing on a module is based on its symbol name, it should
be adjusted on actual symbols.

E.g. without this fix, perf probe shows probe definition
on non-exist symbol as below.

  $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -F in_range*
  in_range.isra.12
  $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
  p:probe/in_range nf_nat:in_range+0

With this fix, perf probe correctly shows a probe on
gcc-generated symbol.

  $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
  p:probe/in_range nf_nat:in_range.isra.12+0

This also fixes same problem on online module as below.

  $ perf probe -m i915 -D assert_plane
  p:probe/assert_plane i915:assert_plane.constprop.134+0

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c  |   45 ++--
 tools/perf/util/probe-finder.c |7 --
 tools/perf/util/probe-finder.h |3 +++
 3 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index aa8a922..6a6f44d 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -698,18 +698,31 @@ static int add_exec_to_probe_trace_events(struct 
probe_trace_event *tevs,
return ret;
 }
 
-static int add_module_to_probe_trace_events(struct probe_trace_event *tevs,
-   int ntevs, const char *module)
+static int
+post_process_module_probe_trace_events(struct probe_trace_event *tevs,
+  int ntevs, const char *module,
+  struct debuginfo *dinfo)
 {
+   Dwarf_Addr text_offs = 0;
int i, ret = 0;
char *mod_name = NULL;
+   struct map *map;
 
if (!module)
return 0;
 
-   mod_name = find_module_name(module);
+   map = get_target_map(module, false);
+   if (!map || debuginfo__get_text_offset(dinfo, _offs, true) < 0) {
+   pr_warning("Failed to get ELF symbols for %s\n", module);
+   return -EINVAL;
+   }
 
+   mod_name = find_module_name(module);
for (i = 0; i < ntevs; i++) {
+   ret = post_process_probe_trace_point([i].point,
+   map, (unsigned long)text_offs);
+   if (ret < 0)
+   break;
tevs[i].point.module =
strdup(mod_name ? mod_name : module);
if (!tevs[i].point.module) {
@@ -719,6 +732,8 @@ static int add_module_to_probe_trace_events(struct 
probe_trace_event *tevs,
}
 
free(mod_name);
+   map__put(map);
+
return ret;
 }
 
@@ -776,7 +791,7 @@ arch__post_process_probe_trace_events(struct 
perf_probe_event *pev __maybe_unuse
 static int post_process_probe_trace_events(struct perf_probe_event *pev,
   struct probe_trace_event *tevs,
   int ntevs, const char *module,
-  bool uprobe)
+  bool uprobe, struct debuginfo *dinfo)
 {
int ret;
 
@@ -784,7 +799,8 @@ static int post_process_probe_trace_events(struct 
perf_probe_event *pev,
ret = add_exec_to_probe_trace_events(tevs, ntevs, module);
else if (module)
/* Currently ref_reloc_sym based probe is not for drivers */
-   ret = add_module_to_probe_trace_events(tevs, ntevs, module);
+   ret = post_process_module_probe_trace_events(tevs, ntevs,
+module, dinfo);
else
ret = post_process_kernel_probe_trace_events(tevs, ntevs);
 
@@ -828,30 +844,27 @@ static int try_to_find_probe_trace_events(struct 
perf_probe_event *pev,
}
}
 
-   debuginfo__delete(dinfo);
-
if (ntevs > 0) {/* Succeeded to find trace events */
pr_debug("Found %d probe_trace_events.\n", ntevs);
ret = post_process_probe_trace_events(pev, *tevs, ntevs,
-   pev->target, pev->uprobes);
+   pev->target, pev->uprobes, dinfo);
if (ret < 0 || ret == ntevs) {
+   pr_debug("Post processing failed or all events are 
skipped. (%d)\n", ret);
clear_probe_trace_events(*tevs, ntevs);
zfree(tevs);
+   ntevs = 0;
}
-   if (ret != ntevs)
-   return ret < 0 ? ret : ntevs;
-   ntevs = 0;
-   /* Fall through */
}
 
+   debuginfo__delete(dinfo);
+
if (ntevs == 0) {   /* No error but failed to find probe point. */
pr_warning("Probe point 

[PATCH perf/core 3/4] perf-probe: Fix to probe on gcc generated functions in modules

[Masami Hiramatsu]

Fix to probe on gcc generated functions on modules. Since
probing on a module is based on its symbol name, it should
be adjusted on actual symbols.

E.g. without this fix, perf probe shows probe definition
on non-exist symbol as below.

  $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -F in_range*
  in_range.isra.12
  $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
  p:probe/in_range nf_nat:in_range+0

With this fix, perf probe correctly shows a probe on
gcc-generated symbol.

  $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
  p:probe/in_range nf_nat:in_range.isra.12+0

This also fixes same problem on online module as below.

  $ perf probe -m i915 -D assert_plane
  p:probe/assert_plane i915:assert_plane.constprop.134+0

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c  |   45 ++--
 tools/perf/util/probe-finder.c |7 --
 tools/perf/util/probe-finder.h |3 +++
 3 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index aa8a922..6a6f44d 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -698,18 +698,31 @@ static int add_exec_to_probe_trace_events(struct 
probe_trace_event *tevs,
return ret;
 }
 
-static int add_module_to_probe_trace_events(struct probe_trace_event *tevs,
-   int ntevs, const char *module)
+static int
+post_process_module_probe_trace_events(struct probe_trace_event *tevs,
+  int ntevs, const char *module,
+  struct debuginfo *dinfo)
 {
+   Dwarf_Addr text_offs = 0;
int i, ret = 0;
char *mod_name = NULL;
+   struct map *map;
 
if (!module)
return 0;
 
-   mod_name = find_module_name(module);
+   map = get_target_map(module, false);
+   if (!map || debuginfo__get_text_offset(dinfo, _offs, true) < 0) {
+   pr_warning("Failed to get ELF symbols for %s\n", module);
+   return -EINVAL;
+   }
 
+   mod_name = find_module_name(module);
for (i = 0; i < ntevs; i++) {
+   ret = post_process_probe_trace_point([i].point,
+   map, (unsigned long)text_offs);
+   if (ret < 0)
+   break;
tevs[i].point.module =
strdup(mod_name ? mod_name : module);
if (!tevs[i].point.module) {
@@ -719,6 +732,8 @@ static int add_module_to_probe_trace_events(struct 
probe_trace_event *tevs,
}
 
free(mod_name);
+   map__put(map);
+
return ret;
 }
 
@@ -776,7 +791,7 @@ arch__post_process_probe_trace_events(struct 
perf_probe_event *pev __maybe_unuse
 static int post_process_probe_trace_events(struct perf_probe_event *pev,
   struct probe_trace_event *tevs,
   int ntevs, const char *module,
-  bool uprobe)
+  bool uprobe, struct debuginfo *dinfo)
 {
int ret;
 
@@ -784,7 +799,8 @@ static int post_process_probe_trace_events(struct 
perf_probe_event *pev,
ret = add_exec_to_probe_trace_events(tevs, ntevs, module);
else if (module)
/* Currently ref_reloc_sym based probe is not for drivers */
-   ret = add_module_to_probe_trace_events(tevs, ntevs, module);
+   ret = post_process_module_probe_trace_events(tevs, ntevs,
+module, dinfo);
else
ret = post_process_kernel_probe_trace_events(tevs, ntevs);
 
@@ -828,30 +844,27 @@ static int try_to_find_probe_trace_events(struct 
perf_probe_event *pev,
}
}
 
-   debuginfo__delete(dinfo);
-
if (ntevs > 0) {/* Succeeded to find trace events */
pr_debug("Found %d probe_trace_events.\n", ntevs);
ret = post_process_probe_trace_events(pev, *tevs, ntevs,
-   pev->target, pev->uprobes);
+   pev->target, pev->uprobes, dinfo);
if (ret < 0 || ret == ntevs) {
+   pr_debug("Post processing failed or all events are 
skipped. (%d)\n", ret);
clear_probe_trace_events(*tevs, ntevs);
zfree(tevs);
+   ntevs = 0;
}
-   if (ret != ntevs)
-   return ret < 0 ? ret : ntevs;
-   ntevs = 0;
-   /* Fall through */
}
 
+   debuginfo__delete(dinfo);
+
if (ntevs == 0) {   /* No error but failed to find probe point. */
pr_warning("Probe point '%s' not found.\n",
 

[PATCH perf/core 2/4] perf-probe: Add error checks to offline probe post-processing

[Masami Hiramatsu]

Add error check codes to post process and improve it for
offline probe events as;
 - post process fails if no matched symbol found in map(-ENOENT)
   or strdup() failed(-ENOMEM).
 - Even if the symbol name is same, it updates symbol address
   and offset.

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |   50 +++--
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 4a57c8a..aa8a922 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -610,6 +610,33 @@ static int find_perf_probe_point_from_dwarf(struct 
probe_trace_point *tp,
return ret ? : -ENOENT;
 }
 
+/* Adjust symbol name and address */
+static int post_process_probe_trace_point(struct probe_trace_point *tp,
+  struct map *map, unsigned long offs)
+{
+   struct symbol *sym;
+   u64 addr = tp->address + tp->offset - offs;
+
+   sym = map__find_symbol(map, addr);
+   if (!sym)
+   return -ENOENT;
+
+   if (strcmp(sym->name, tp->symbol)) {
+   /* If we have no realname, use symbol for it */
+   if (!tp->realname)
+   tp->realname = tp->symbol;
+   else
+   free(tp->symbol);
+   tp->symbol = strdup(sym->name);
+   if (!tp->symbol)
+   return -ENOMEM;
+   }
+   tp->offset = addr - sym->start;
+   tp->address -= offs;
+
+   return 0;
+}
+
 /*
  * Rename DWARF symbols to ELF symbols -- gcc sometimes optimizes functions
  * and generate new symbols with suffixes such as .constprop.N or .isra.N
@@ -622,11 +649,9 @@ static int
 post_process_offline_probe_trace_events(struct probe_trace_event *tevs,
int ntevs, const char *pathname)
 {
-   struct symbol *sym;
struct map *map;
unsigned long stext = 0;
-   u64 addr;
-   int i;
+   int i, ret = 0;
 
/* Prepare a map for offline binary */
map = dso__new_map(pathname);
@@ -636,23 +661,14 @@ post_process_offline_probe_trace_events(struct 
probe_trace_event *tevs,
}
 
for (i = 0; i < ntevs; i++) {
-   addr = tevs[i].point.address + tevs[i].point.offset - stext;
-   sym = map__find_symbol(map, addr);
-   if (!sym)
-   continue;
-   if (!strcmp(sym->name, tevs[i].point.symbol))
-   continue;
-   /* If we have no realname, use symbol for it */
-   if (!tevs[i].point.realname)
-   tevs[i].point.realname = tevs[i].point.symbol;
-   else
-   free(tevs[i].point.symbol);
-   tevs[i].point.symbol = strdup(sym->name);
-   tevs[i].point.offset = addr - sym->start;
+   ret = post_process_probe_trace_point([i].point,
+map, stext);
+   if (ret < 0)
+   break;
}
map__put(map);
 
-   return 0;
+   return ret;
 }
 
 static int add_exec_to_probe_trace_events(struct probe_trace_event *tevs,

[PATCH perf/core 2/4] perf-probe: Add error checks to offline probe post-processing

[Masami Hiramatsu]

Add error check codes to post process and improve it for
offline probe events as;
 - post process fails if no matched symbol found in map(-ENOENT)
   or strdup() failed(-ENOMEM).
 - Even if the symbol name is same, it updates symbol address
   and offset.

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-event.c |   50 +++--
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 4a57c8a..aa8a922 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -610,6 +610,33 @@ static int find_perf_probe_point_from_dwarf(struct 
probe_trace_point *tp,
return ret ? : -ENOENT;
 }
 
+/* Adjust symbol name and address */
+static int post_process_probe_trace_point(struct probe_trace_point *tp,
+  struct map *map, unsigned long offs)
+{
+   struct symbol *sym;
+   u64 addr = tp->address + tp->offset - offs;
+
+   sym = map__find_symbol(map, addr);
+   if (!sym)
+   return -ENOENT;
+
+   if (strcmp(sym->name, tp->symbol)) {
+   /* If we have no realname, use symbol for it */
+   if (!tp->realname)
+   tp->realname = tp->symbol;
+   else
+   free(tp->symbol);
+   tp->symbol = strdup(sym->name);
+   if (!tp->symbol)
+   return -ENOMEM;
+   }
+   tp->offset = addr - sym->start;
+   tp->address -= offs;
+
+   return 0;
+}
+
 /*
  * Rename DWARF symbols to ELF symbols -- gcc sometimes optimizes functions
  * and generate new symbols with suffixes such as .constprop.N or .isra.N
@@ -622,11 +649,9 @@ static int
 post_process_offline_probe_trace_events(struct probe_trace_event *tevs,
int ntevs, const char *pathname)
 {
-   struct symbol *sym;
struct map *map;
unsigned long stext = 0;
-   u64 addr;
-   int i;
+   int i, ret = 0;
 
/* Prepare a map for offline binary */
map = dso__new_map(pathname);
@@ -636,23 +661,14 @@ post_process_offline_probe_trace_events(struct 
probe_trace_event *tevs,
}
 
for (i = 0; i < ntevs; i++) {
-   addr = tevs[i].point.address + tevs[i].point.offset - stext;
-   sym = map__find_symbol(map, addr);
-   if (!sym)
-   continue;
-   if (!strcmp(sym->name, tevs[i].point.symbol))
-   continue;
-   /* If we have no realname, use symbol for it */
-   if (!tevs[i].point.realname)
-   tevs[i].point.realname = tevs[i].point.symbol;
-   else
-   free(tevs[i].point.symbol);
-   tevs[i].point.symbol = strdup(sym->name);
-   tevs[i].point.offset = addr - sym->start;
+   ret = post_process_probe_trace_point([i].point,
+map, stext);
+   if (ret < 0)
+   break;
}
map__put(map);
 
-   return 0;
+   return ret;
 }
 
 static int add_exec_to_probe_trace_events(struct probe_trace_event *tevs,

[PATCH perf/core 1/4] perf-probe: Fix to show correct locations for events on modules

[Masami Hiramatsu]

Fix to show correct locations for events on modules by
relocating given address. Currently the relocation is
done when we failed to find the address in debuginfo,
but for modules it always makes a mistakes.

E.g. without this fix, events on module seems wrong,
but other cases (kernel and user space) looks good.

  # perf probe -l
probe:SyS_remap_file_pages (on SyS_remap_file_pages@mm/mmap.c)
probe:chv_prepare_pll (on 
intel_plane_atomic_get_property+16@drm/i915/intel_atomic_plane.c in i915)
probe_perf:alias_lookup (on alias_lookup@util/alias.c in 
/home/mhiramat/ksrc/linux/tools/perf/perf)

With this fix, all cases are OK now.

  # perf probe -l
probe:SyS_remap_file_pages (on SyS_remap_file_pages@mm/mmap.c)
probe:chv_prepare_pll (on chv_prepare_pll@gpu/drm/i915/intel_display.c in 
i915)
probe_perf:alias_lookup (on alias_lookup@util/alias.c in 
/home/mhiramat/ksrc/linux/tools/perf/perf)

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-finder.c |   10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index df4debe..0278fe1 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1543,16 +1543,12 @@ int debuginfo__find_probe_point(struct debuginfo *dbg, 
unsigned long addr,
Dwarf_Addr _addr = 0, baseaddr = 0;
const char *fname = NULL, *func = NULL, *basefunc = NULL, *tmp;
int baseline = 0, lineno = 0, ret = 0;
-   bool reloc = false;
 
-retry:
+   /* We always need to relocate the address for aranges */
+   if (debuginfo__get_text_offset(dbg, ) == 0)
+   addr += baseaddr;
/* Find cu die */
if (!dwarf_addrdie(dbg->dbg, (Dwarf_Addr)addr, )) {
-   if (!reloc && debuginfo__get_text_offset(dbg, ) == 0) {
-   addr += baseaddr;
-   reloc = true;
-   goto retry;
-   }
pr_warning("Failed to find debug information for address %lx\n",
   addr);
ret = -EINVAL;

[PATCH perf/core 1/4] perf-probe: Fix to show correct locations for events on modules

[Masami Hiramatsu]

Fix to show correct locations for events on modules by
relocating given address. Currently the relocation is
done when we failed to find the address in debuginfo,
but for modules it always makes a mistakes.

E.g. without this fix, events on module seems wrong,
but other cases (kernel and user space) looks good.

  # perf probe -l
probe:SyS_remap_file_pages (on SyS_remap_file_pages@mm/mmap.c)
probe:chv_prepare_pll (on 
intel_plane_atomic_get_property+16@drm/i915/intel_atomic_plane.c in i915)
probe_perf:alias_lookup (on alias_lookup@util/alias.c in 
/home/mhiramat/ksrc/linux/tools/perf/perf)

With this fix, all cases are OK now.

  # perf probe -l
probe:SyS_remap_file_pages (on SyS_remap_file_pages@mm/mmap.c)
probe:chv_prepare_pll (on chv_prepare_pll@gpu/drm/i915/intel_display.c in 
i915)
probe_perf:alias_lookup (on alias_lookup@util/alias.c in 
/home/mhiramat/ksrc/linux/tools/perf/perf)

Signed-off-by: Masami Hiramatsu 
---
 tools/perf/util/probe-finder.c |   10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index df4debe..0278fe1 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1543,16 +1543,12 @@ int debuginfo__find_probe_point(struct debuginfo *dbg, 
unsigned long addr,
Dwarf_Addr _addr = 0, baseaddr = 0;
const char *fname = NULL, *func = NULL, *basefunc = NULL, *tmp;
int baseline = 0, lineno = 0, ret = 0;
-   bool reloc = false;
 
-retry:
+   /* We always need to relocate the address for aranges */
+   if (debuginfo__get_text_offset(dbg, ) == 0)
+   addr += baseaddr;
/* Find cu die */
if (!dwarf_addrdie(dbg->dbg, (Dwarf_Addr)addr, )) {
-   if (!reloc && debuginfo__get_text_offset(dbg, ) == 0) {
-   addr += baseaddr;
-   reloc = true;
-   goto retry;
-   }
pr_warning("Failed to find debug information for address %lx\n",
   addr);
ret = -EINVAL;

[PATCH perf/core 0/4] perf-probe: Fix and improve module probe events

[Masami Hiramatsu]

Hello,

This series fixes some issues on offline/online module
probe support and improve perf-probe to probe module
without -m option (Thanks Arnaldo!).
This includes below patches.

 - [1/4] Fix perf-probe --list to show correct probe location
 in module.
 - [2/4] Improve error checking for the probes for offline
 kernel.
 - [3/4] (V2) Fix perf-probe to probe correctly on gcc generated
 functions in module.
 - [4/4] Improve perf-probe to find probe events in module
 without -m option.

Thank you,

---

Masami Hiramatsu (4):
  perf-probe: Fix to show correct locations for events on modules
  perf-probe: Add error checks to offline probe post-processing
  perf-probe: Fix to probe on gcc generated functions in modules
  perf-probe: Find probe events without target module


 tools/perf/util/probe-event.c  |  165 
 tools/perf/util/probe-finder.c |   15 ++--
 tools/perf/util/probe-finder.h |3 +
 3 files changed, 125 insertions(+), 58 deletions(-)

--
Masami Hiramatsu (Linaro)

[PATCH perf/core 0/4] perf-probe: Fix and improve module probe events

[Masami Hiramatsu]

Hello,

This series fixes some issues on offline/online module
probe support and improve perf-probe to probe module
without -m option (Thanks Arnaldo!).
This includes below patches.

 - [1/4] Fix perf-probe --list to show correct probe location
 in module.
 - [2/4] Improve error checking for the probes for offline
 kernel.
 - [3/4] (V2) Fix perf-probe to probe correctly on gcc generated
 functions in module.
 - [4/4] Improve perf-probe to find probe events in module
 without -m option.

Thank you,

---

Masami Hiramatsu (4):
  perf-probe: Fix to show correct locations for events on modules
  perf-probe: Add error checks to offline probe post-processing
  perf-probe: Fix to probe on gcc generated functions in modules
  perf-probe: Find probe events without target module


 tools/perf/util/probe-event.c  |  165 
 tools/perf/util/probe-finder.c |   15 ++--
 tools/perf/util/probe-finder.h |3 +
 3 files changed, 125 insertions(+), 58 deletions(-)

--
Masami Hiramatsu (Linaro)

RE: [PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Kershner, David A]

> -Original Message-
> From: Derek Robson [mailto:robso...@gmail.com]
> Sent: Friday, January 6, 2017 10:48 PM
> To: Kershner, David A ;
> gre...@linuxfoundation.org; Sell, Timothy C 
> Cc: *S-Par-Maintainer ;
> de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Derek Robson
> 
> Subject: [PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file
> permissions
> 
> Two files change in style fix, changes are octal file permissions.
> 

Series looks fine to me and runs on top of the s-Par firmware.

Acked-by: David Kershner 

> Derek Robson (2):
>   Staging: unisys: visorbus: style fix, using octal file permissions
>   Staging: unisys: visorbus: style fix, using octal file permissions
> 
>  drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
>  drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> --
> 2.11.0

RE: [PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Kershner, David A]

> -Original Message-
> From: Derek Robson [mailto:robso...@gmail.com]
> Sent: Friday, January 6, 2017 10:48 PM
> To: Kershner, David A ;
> gre...@linuxfoundation.org; Sell, Timothy C 
> Cc: *S-Par-Maintainer ;
> de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Derek Robson
> 
> Subject: [PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file
> permissions
> 
> Two files change in style fix, changes are octal file permissions.
> 

Series looks fine to me and runs on top of the s-Par firmware.

Acked-by: David Kershner 

> Derek Robson (2):
>   Staging: unisys: visorbus: style fix, using octal file permissions
>   Staging: unisys: visorbus: style fix, using octal file permissions
> 
>  drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
>  drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> --
> 2.11.0

Re: [PATCH] ipc/sem.c: fix semop()/semop() locking failure

[Mike Galbraith]

On Sun, 2016-12-18 at 19:45 -0800, Davidlohr Bueso wrote:
> Nit: the title is a bit unclear. How about:
> 
> ipc/sem.: fix semop() locking imbalance
> 
> Otherwise, Ack.

(notices patchlet _not_ flying upstream... s/failure/imbalance?)

Re: [PATCH] ipc/sem.c: fix semop()/semop() locking failure

[Mike Galbraith]

On Sun, 2016-12-18 at 19:45 -0800, Davidlohr Bueso wrote:
> Nit: the title is a bit unclear. How about:
> 
> ipc/sem.: fix semop() locking imbalance
> 
> Otherwise, Ack.

(notices patchlet _not_ flying upstream... s/failure/imbalance?)

[PATCH] Staging: speakup: styel fix, octal file permissions

[Derek Robson]

Changed file permission to octal style,
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/speakup/kobjects.c | 54 +++---
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index e744aa9730ff..4e7ebc306488 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -865,66 +865,66 @@ static struct kobj_attribute version_attribute =
__ATTR_RO(version);
 
 static struct kobj_attribute delimiters_attribute =
-   __ATTR(delimiters, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(delimiters, 0644, punc_show, punc_store);
 static struct kobj_attribute ex_num_attribute =
-   __ATTR(ex_num, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(ex_num, 0644, punc_show, punc_store);
 static struct kobj_attribute punc_all_attribute =
-   __ATTR(punc_all, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(punc_all, 0644, punc_show, punc_store);
 static struct kobj_attribute punc_most_attribute =
-   __ATTR(punc_most, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(punc_most, 0644, punc_show, punc_store);
 static struct kobj_attribute punc_some_attribute =
-   __ATTR(punc_some, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(punc_some, 0644, punc_show, punc_store);
 static struct kobj_attribute repeats_attribute =
-   __ATTR(repeats, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(repeats, 0644, punc_show, punc_store);
 
 static struct kobj_attribute attrib_bleep_attribute =
-   __ATTR(attrib_bleep, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(attrib_bleep, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute bell_pos_attribute =
-   __ATTR(bell_pos, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(bell_pos, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute bleep_time_attribute =
-   __ATTR(bleep_time, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(bleep_time, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute bleeps_attribute =
-   __ATTR(bleeps, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(bleeps, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute cursor_time_attribute =
-   __ATTR(cursor_time, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(cursor_time, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute key_echo_attribute =
-   __ATTR(key_echo, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(key_echo, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute no_interrupt_attribute =
-   __ATTR(no_interrupt, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(no_interrupt, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute punc_level_attribute =
-   __ATTR(punc_level, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(punc_level, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute reading_punc_attribute =
-   __ATTR(reading_punc, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(reading_punc, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute say_control_attribute =
-   __ATTR(say_control, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(say_control, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute say_word_ctl_attribute =
-   __ATTR(say_word_ctl, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(say_word_ctl, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute spell_delay_attribute =
-   __ATTR(spell_delay, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(spell_delay, 0644, spk_var_show, spk_var_store);
 
 /*
  * These attributes are i18n related.
  */
 static struct kobj_attribute announcements_attribute =
-   __ATTR(announcements, S_IWUSR | S_IRUGO, message_show, message_store);
+   __ATTR(announcements, 0644, message_show, message_store);
 static struct kobj_attribute characters_attribute =
-   __ATTR(characters, S_IWUSR | S_IRUGO, chars_chartab_show,
+   __ATTR(characters, 0644, chars_chartab_show,
   chars_chartab_store);
 static struct kobj_attribute chartab_attribute =
-   __ATTR(chartab, S_IWUSR | S_IRUGO, chars_chartab_show,
+   __ATTR(chartab, 0644, chars_chartab_show,
   chars_chartab_store);
 static struct kobj_attribute ctl_keys_attribute =
-   __ATTR(ctl_keys, S_IWUSR | S_IRUGO, message_show, message_store);
+   __ATTR(ctl_keys, 0644, message_show, message_store);
 static struct kobj_attribute colors_attribute =
-   __ATTR(colors, S_IWUSR | S_IRUGO, message_show, message_store);
+   __ATTR(colors, 0644, message_show, message_store);
 static struct kobj_attribute formatted_attribute =

[PATCH] Staging: speakup: styel fix, octal file permissions

[Derek Robson]

Changed file permission to octal style,
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/speakup/kobjects.c | 54 +++---
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index e744aa9730ff..4e7ebc306488 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -865,66 +865,66 @@ static struct kobj_attribute version_attribute =
__ATTR_RO(version);
 
 static struct kobj_attribute delimiters_attribute =
-   __ATTR(delimiters, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(delimiters, 0644, punc_show, punc_store);
 static struct kobj_attribute ex_num_attribute =
-   __ATTR(ex_num, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(ex_num, 0644, punc_show, punc_store);
 static struct kobj_attribute punc_all_attribute =
-   __ATTR(punc_all, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(punc_all, 0644, punc_show, punc_store);
 static struct kobj_attribute punc_most_attribute =
-   __ATTR(punc_most, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(punc_most, 0644, punc_show, punc_store);
 static struct kobj_attribute punc_some_attribute =
-   __ATTR(punc_some, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(punc_some, 0644, punc_show, punc_store);
 static struct kobj_attribute repeats_attribute =
-   __ATTR(repeats, S_IWUSR | S_IRUGO, punc_show, punc_store);
+   __ATTR(repeats, 0644, punc_show, punc_store);
 
 static struct kobj_attribute attrib_bleep_attribute =
-   __ATTR(attrib_bleep, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(attrib_bleep, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute bell_pos_attribute =
-   __ATTR(bell_pos, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(bell_pos, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute bleep_time_attribute =
-   __ATTR(bleep_time, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(bleep_time, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute bleeps_attribute =
-   __ATTR(bleeps, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(bleeps, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute cursor_time_attribute =
-   __ATTR(cursor_time, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(cursor_time, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute key_echo_attribute =
-   __ATTR(key_echo, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(key_echo, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute no_interrupt_attribute =
-   __ATTR(no_interrupt, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(no_interrupt, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute punc_level_attribute =
-   __ATTR(punc_level, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(punc_level, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute reading_punc_attribute =
-   __ATTR(reading_punc, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(reading_punc, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute say_control_attribute =
-   __ATTR(say_control, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(say_control, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute say_word_ctl_attribute =
-   __ATTR(say_word_ctl, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(say_word_ctl, 0644, spk_var_show, spk_var_store);
 static struct kobj_attribute spell_delay_attribute =
-   __ATTR(spell_delay, S_IWUSR | S_IRUGO, spk_var_show, spk_var_store);
+   __ATTR(spell_delay, 0644, spk_var_show, spk_var_store);
 
 /*
  * These attributes are i18n related.
  */
 static struct kobj_attribute announcements_attribute =
-   __ATTR(announcements, S_IWUSR | S_IRUGO, message_show, message_store);
+   __ATTR(announcements, 0644, message_show, message_store);
 static struct kobj_attribute characters_attribute =
-   __ATTR(characters, S_IWUSR | S_IRUGO, chars_chartab_show,
+   __ATTR(characters, 0644, chars_chartab_show,
   chars_chartab_store);
 static struct kobj_attribute chartab_attribute =
-   __ATTR(chartab, S_IWUSR | S_IRUGO, chars_chartab_show,
+   __ATTR(chartab, 0644, chars_chartab_show,
   chars_chartab_store);
 static struct kobj_attribute ctl_keys_attribute =
-   __ATTR(ctl_keys, S_IWUSR | S_IRUGO, message_show, message_store);
+   __ATTR(ctl_keys, 0644, message_show, message_store);
 static struct kobj_attribute colors_attribute =
-   __ATTR(colors, S_IWUSR | S_IRUGO, message_show, message_store);
+   __ATTR(colors, 0644, message_show, message_store);
 static struct kobj_attribute formatted_attribute =
-   

Re: [PATCH v2] ARM: dts: qcom: apq8064: Add missing scm clock

[John Stultz]

On Thu, Dec 29, 2016 at 4:06 AM, Bjorn Andersson
 wrote:
> As per the device tree binding the apq8064 scm node requires the core
> clock to be specified, so add this.
>
> Signed-off-by: Bjorn Andersson 
> ---
>
> Changes since v1:
> - Changed clock to Daytona Fabric
>
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 1dbe697b2e90..a27cc96ac069 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -303,6 +304,9 @@
> firmware {
> scm {
> compatible = "qcom,scm-apq8064";
> +
> +   clocks = < RPM_DAYTONA_FABRIC_CLK>;
> +   clock-names = "core";
> };
> };

So using this on my nexus7, I see:

[   14.240169] [ cut here ]
[   14.240230] WARNING: CPU: 0 PID: 0 at
drivers/usb/chipidea/udc.c:954 isr_setup_status_phase+0x98/0x9c
[   14.243872] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.10.0-rc2-00024-g4f53a60 #1774
[   14.252975] Hardware name: Generic DT based system
[   14.260810] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[   14.265493] [] (show_stack) from []
(dump_stack+0x80/0x94)
[   14.273385] [] (dump_stack) from [] (__warn+0xf0/0x10c)
[   14.280416] [] (__warn) from []
(warn_slowpath_null+0x30/0x38)
[   14.287269] [] (warn_slowpath_null) from []
(isr_setup_status_phase+0x98/0x9c)
[   14.294913] [] (isr_setup_status_phase) from []
(udc_irq+0x9f0/0xd0c)
[   14.303856] [] (udc_irq) from [] (ci_irq+0x64/0x118)
[   14.312103] [] (ci_irq) from []
(__handle_irq_event_percpu+0x84/0x2b4)
[   14.318871] [] (__handle_irq_event_percpu) from
[] (handle_irq_event_percpu+0x2c/0x68)
[   14.326945] [] (handle_irq_event_percpu) from
[] (handle_irq_event+0x48/0x6c)
[   14.336581] [] (handle_irq_event) from []
(handle_fasteoi_irq+0xe0/0x1b0)
[   14.345522] [] (handle_fasteoi_irq) from []
(generic_handle_irq+0x30/0x44)
[   14.354026] [] (generic_handle_irq) from []
(__handle_domain_irq+0x8c/0xfc)
[   14.362535] [] (__handle_domain_irq) from []
(gic_handle_irq+0x58/0x9c)
[   14.371125] [] (gic_handle_irq) from []
(__irq_svc+0x6c/0xa8)
[   14.379450] Exception stack(0xc1001ee8 to 0xc1001f30)
[   14.387102] 1ee0:   0001  
c031b240 c100 c10050c0
[   14.392145] 1f00: c100506c c0f92ea8 c1001f58  
c1001f44 c1001f48 c1001f38
[   14.400295] 1f20: c03097d4 c03097d8 6113 
[   14.408457] [] (__irq_svc) from []
(arch_cpu_idle+0x48/0x4c)
[   14.413497] [] (arch_cpu_idle) from []
(default_idle_call+0x30/0x3c)
[   14.420959] [] (default_idle_call) from []
(do_idle+0x17c/0x210)
[   14.429027] [] (do_idle) from []
(cpu_startup_entry+0x28/0x2c)
[   14.436756] [] (cpu_startup_entry) from []
(rest_init+0x94/0x98)
[   14.444130] [] (rest_init) from []
(start_kernel+0x390/0x39c)
[   14.452022] ---[ end trace cc56495fca556bcb ]---


And then usb doesn't seem to work...

thanks
-john

Re: [PATCH v2] ARM: dts: qcom: apq8064: Add missing scm clock

[John Stultz]

On Thu, Dec 29, 2016 at 4:06 AM, Bjorn Andersson
 wrote:
> As per the device tree binding the apq8064 scm node requires the core
> clock to be specified, so add this.
>
> Signed-off-by: Bjorn Andersson 
> ---
>
> Changes since v1:
> - Changed clock to Daytona Fabric
>
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 1dbe697b2e90..a27cc96ac069 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -303,6 +304,9 @@
> firmware {
> scm {
> compatible = "qcom,scm-apq8064";
> +
> +   clocks = < RPM_DAYTONA_FABRIC_CLK>;
> +   clock-names = "core";
> };
> };

So using this on my nexus7, I see:

[   14.240169] [ cut here ]
[   14.240230] WARNING: CPU: 0 PID: 0 at
drivers/usb/chipidea/udc.c:954 isr_setup_status_phase+0x98/0x9c
[   14.243872] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.10.0-rc2-00024-g4f53a60 #1774
[   14.252975] Hardware name: Generic DT based system
[   14.260810] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[   14.265493] [] (show_stack) from []
(dump_stack+0x80/0x94)
[   14.273385] [] (dump_stack) from [] (__warn+0xf0/0x10c)
[   14.280416] [] (__warn) from []
(warn_slowpath_null+0x30/0x38)
[   14.287269] [] (warn_slowpath_null) from []
(isr_setup_status_phase+0x98/0x9c)
[   14.294913] [] (isr_setup_status_phase) from []
(udc_irq+0x9f0/0xd0c)
[   14.303856] [] (udc_irq) from [] (ci_irq+0x64/0x118)
[   14.312103] [] (ci_irq) from []
(__handle_irq_event_percpu+0x84/0x2b4)
[   14.318871] [] (__handle_irq_event_percpu) from
[] (handle_irq_event_percpu+0x2c/0x68)
[   14.326945] [] (handle_irq_event_percpu) from
[] (handle_irq_event+0x48/0x6c)
[   14.336581] [] (handle_irq_event) from []
(handle_fasteoi_irq+0xe0/0x1b0)
[   14.345522] [] (handle_fasteoi_irq) from []
(generic_handle_irq+0x30/0x44)
[   14.354026] [] (generic_handle_irq) from []
(__handle_domain_irq+0x8c/0xfc)
[   14.362535] [] (__handle_domain_irq) from []
(gic_handle_irq+0x58/0x9c)
[   14.371125] [] (gic_handle_irq) from []
(__irq_svc+0x6c/0xa8)
[   14.379450] Exception stack(0xc1001ee8 to 0xc1001f30)
[   14.387102] 1ee0:   0001  
c031b240 c100 c10050c0
[   14.392145] 1f00: c100506c c0f92ea8 c1001f58  
c1001f44 c1001f48 c1001f38
[   14.400295] 1f20: c03097d4 c03097d8 6113 
[   14.408457] [] (__irq_svc) from []
(arch_cpu_idle+0x48/0x4c)
[   14.413497] [] (arch_cpu_idle) from []
(default_idle_call+0x30/0x3c)
[   14.420959] [] (default_idle_call) from []
(do_idle+0x17c/0x210)
[   14.429027] [] (do_idle) from []
(cpu_startup_entry+0x28/0x2c)
[   14.436756] [] (cpu_startup_entry) from []
(rest_init+0x94/0x98)
[   14.444130] [] (rest_init) from []
(start_kernel+0x390/0x39c)
[   14.452022] ---[ end trace cc56495fca556bcb ]---


And then usb doesn't seem to work...

thanks
-john

Re: [PATCH net-next 1/4] siphash: add cryptographically secure PRF

[Eric Biggers]

Hi Jason, just a few comments:

On Fri, Jan 06, 2017 at 09:10:52PM +0100, Jason A. Donenfeld wrote:
> +#define SIPHASH_ALIGNMENT __alignof__(u64)
> +typedef u64 siphash_key_t[2];

I was confused by all the functions passing siphash_key_t "by value" until I saw
that it's actually typedefed to u64[2].  Have you considered making it a struct
instead, something like this?

typedef struct {
u64 v[2];
} siphash_key_t;

Then it would be strongly typed and thus harder to misuse, and all the functions
would take 'const siphash_key_t *' instead of 'const siphash_key_t' which would
make it clear that the key is passed by pointer not by value.

> +static inline u64 ___siphash_aligned(const __le64 *data, size_t len, const 
> siphash_key_t key)
> +{
> + if (__builtin_constant_p(len) && len == 4)
> + return siphash_1u32(le32_to_cpu(data[0]), key);

Small bug here: data[0] is not valid if len is 4.  This can be fixed by casting
to a le32 pointer:

return siphash_1u32(le32_to_cpup((const __le32 *)data), key);

> +static int __init siphash_test_init(void)
> +{
> + u8 in[64] __aligned(SIPHASH_ALIGNMENT);
> + u8 in_unaligned[65];

It seems that in_unaligned+1 is meant to be misaligned, but that's not
guaranteed because in_unaligned has no alignment restriction, so it could
theoretically be misaligned in a way that makes in_unaligned+1 aligned.  So it
should be 'in_unaligned[65] __aligned(SIPHASH_ALIGNMENT)'.

There are also a lot of checkpatch warnings produced by this patch.  It looks
like many of them can be ignored, but there may be some that should be
addressed.

- Eric

Re: [PATCH net-next 1/4] siphash: add cryptographically secure PRF

[Eric Biggers]

Hi Jason, just a few comments:

On Fri, Jan 06, 2017 at 09:10:52PM +0100, Jason A. Donenfeld wrote:
> +#define SIPHASH_ALIGNMENT __alignof__(u64)
> +typedef u64 siphash_key_t[2];

I was confused by all the functions passing siphash_key_t "by value" until I saw
that it's actually typedefed to u64[2].  Have you considered making it a struct
instead, something like this?

typedef struct {
u64 v[2];
} siphash_key_t;

Then it would be strongly typed and thus harder to misuse, and all the functions
would take 'const siphash_key_t *' instead of 'const siphash_key_t' which would
make it clear that the key is passed by pointer not by value.

> +static inline u64 ___siphash_aligned(const __le64 *data, size_t len, const 
> siphash_key_t key)
> +{
> + if (__builtin_constant_p(len) && len == 4)
> + return siphash_1u32(le32_to_cpu(data[0]), key);

Small bug here: data[0] is not valid if len is 4.  This can be fixed by casting
to a le32 pointer:

return siphash_1u32(le32_to_cpup((const __le32 *)data), key);

> +static int __init siphash_test_init(void)
> +{
> + u8 in[64] __aligned(SIPHASH_ALIGNMENT);
> + u8 in_unaligned[65];

It seems that in_unaligned+1 is meant to be misaligned, but that's not
guaranteed because in_unaligned has no alignment restriction, so it could
theoretically be misaligned in a way that makes in_unaligned+1 aligned.  So it
should be 'in_unaligned[65] __aligned(SIPHASH_ALIGNMENT)'.

There are also a lot of checkpatch warnings produced by this patch.  It looks
like many of them can be ignored, but there may be some that should be
addressed.

- Eric

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[John Stultz]

On Fri, Jan 6, 2017 at 6:39 PM, Joel Fernandes  wrote:
> Hi John,
>
> On Fri, Jan 6, 2017 at 4:48 PM, John Stultz  wrote:
>> On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
>>> This boot clock can be used as a tracing clock and will account for
>>> suspend time.
>>>
>>> To keep it NMI safe since we're accessing from tracing, we're not using a
>>> separate timekeeper with updates to monotonic clock and boot offset
>>> protected with seqlocks. This has the following minor side effects:
>>>
>>> (1) Its possible that a timestamp be taken after the boot offset is updated
>>> but before the timekeeper is updated. If this happens, the new boot offset
>>> is added to the old timekeeping making the clock appear to update slightly
>>> earlier:
>>>CPU 0CPU 1
>>>timekeeping_inject_sleeptime64()
>>>__timekeeping_inject_sleeptime(tk, delta);
>>> timestamp();
>>>timekeeping_update(tk, TK_CLEAR_NTP...);
>>>
>>> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
>>> partially updated.  Since the tk->offs_boot update is a rare event, this
>>> should be a rare occurrence which postprocessing should be able to handle.
>>>
>>> Cc: Steven Rostedt 
>>> Cc: Thomas Gleixner 
>>> Cc: John Stultz 
>>> Cc: Ingo Molnar 
>>> Signed-off-by: Joel Fernandes 
>>
>> Hey Joel,
>>   Hope you had a good new years! I was queuing this up for testing,
>
> Thanks, yes I had a great new years, hope you did too.
>
>> and the patch set no longer applies (to v4.10-rc2). Can you respin it
>> and resend it?
>
> Actually these patches are already in 4.10-rc2.

Ha! Well, apologies for missing that over the holidays.

Sorry for the noise.
-john

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[John Stultz]

On Fri, Jan 6, 2017 at 6:39 PM, Joel Fernandes  wrote:
> Hi John,
>
> On Fri, Jan 6, 2017 at 4:48 PM, John Stultz  wrote:
>> On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
>>> This boot clock can be used as a tracing clock and will account for
>>> suspend time.
>>>
>>> To keep it NMI safe since we're accessing from tracing, we're not using a
>>> separate timekeeper with updates to monotonic clock and boot offset
>>> protected with seqlocks. This has the following minor side effects:
>>>
>>> (1) Its possible that a timestamp be taken after the boot offset is updated
>>> but before the timekeeper is updated. If this happens, the new boot offset
>>> is added to the old timekeeping making the clock appear to update slightly
>>> earlier:
>>>CPU 0CPU 1
>>>timekeeping_inject_sleeptime64()
>>>__timekeeping_inject_sleeptime(tk, delta);
>>> timestamp();
>>>timekeeping_update(tk, TK_CLEAR_NTP...);
>>>
>>> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
>>> partially updated.  Since the tk->offs_boot update is a rare event, this
>>> should be a rare occurrence which postprocessing should be able to handle.
>>>
>>> Cc: Steven Rostedt 
>>> Cc: Thomas Gleixner 
>>> Cc: John Stultz 
>>> Cc: Ingo Molnar 
>>> Signed-off-by: Joel Fernandes 
>>
>> Hey Joel,
>>   Hope you had a good new years! I was queuing this up for testing,
>
> Thanks, yes I had a great new years, hope you did too.
>
>> and the patch set no longer applies (to v4.10-rc2). Can you respin it
>> and resend it?
>
> Actually these patches are already in 4.10-rc2.

Ha! Well, apologies for missing that over the holidays.

Sorry for the noise.
-john

Re: [PATCH 2/3] Input: pwm-beeper - switch to using managed resources

[David Lechner]

On 01/06/2017 12:20 PM, Dmitry Torokhov wrote:

e of managed resources (devm) simplifies error handling and teardown

  ^
Looks like the commit message got cut off.


of the driver.

Re: [PATCH 2/3] Input: pwm-beeper - switch to using managed resources

[David Lechner]

On 01/06/2017 12:20 PM, Dmitry Torokhov wrote:

e of managed resources (devm) simplifies error handling and teardown

  ^
Looks like the commit message got cut off.


of the driver.

[PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Derek Robson]

Two files change in style fix, changes are octal file permissions.

Derek Robson (2):
  Staging: unisys: visorbus: style fix, using octal file permissions
  Staging: unisys: visorbus: style fix, using octal file permissions

 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
 drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.11.0

[PATCH 2/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Derek Robson]

Changed file permissions to octal sytle.
Found using checkpatch.

Signed-off-by: Derek Robson 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index d7148c351d3f..66944e7534e9 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -2277,7 +2277,7 @@ static void exit_unisys(void)
acpi_bus_unregister_driver(_acpi_driver);
 }
 
-module_param_named(major, visorchipset_major, int, S_IRUGO);
+module_param_named(major, visorchipset_major, int, 0444);
 MODULE_PARM_DESC(visorchipset_major,
 "major device number to use for the device node");
 
-- 
2.11.0

[PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Derek Robson]

Two files change in style fix, changes are octal file permissions.

Derek Robson (2):
  Staging: unisys: visorbus: style fix, using octal file permissions
  Staging: unisys: visorbus: style fix, using octal file permissions

 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
 drivers/staging/unisys/visorbus/visorchipset.c  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.11.0

[PATCH 2/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Derek Robson]

Changed file permissions to octal sytle.
Found using checkpatch.

Signed-off-by: Derek Robson 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index d7148c351d3f..66944e7534e9 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -2277,7 +2277,7 @@ static void exit_unisys(void)
acpi_bus_unregister_driver(_acpi_driver);
 }
 
-module_param_named(major, visorchipset_major, int, S_IRUGO);
+module_param_named(major, visorchipset_major, int, 0444);
 MODULE_PARM_DESC(visorchipset_major,
 "major device number to use for the device node");
 
-- 
2.11.0

[PATCH 1/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Derek Robson]

Changed file permissions to octal style.
Found with checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 3457ef338e1e..28ca291a4053 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -984,7 +984,7 @@ create_bus_instance(struct visor_device *dev)
goto err_hdr_info;
}
dev->debugfs_client_bus_info =
-   debugfs_create_file("client_bus_info", S_IRUSR | S_IRGRP,
+   debugfs_create_file("client_bus_info", 0440,
dev->debugfs_dir, dev,
_bus_info_debugfs_fops);
if (!dev->debugfs_client_bus_info) {
@@ -1337,10 +1337,10 @@ visorbus_exit(void)
debugfs_remove_recursive(visorbus_debugfs_dir);
 }
 
-module_param_named(forcematch, visorbus_forcematch, int, S_IRUGO);
+module_param_named(forcematch, visorbus_forcematch, int, 0444);
 MODULE_PARM_DESC(visorbus_forcematch,
 "1 to force a successful dev <--> drv match");
 
-module_param_named(forcenomatch, visorbus_forcenomatch, int, S_IRUGO);
+module_param_named(forcenomatch, visorbus_forcenomatch, int, 0444);
 MODULE_PARM_DESC(visorbus_forcenomatch,
 "1 to force an UNsuccessful dev <--> drv match");
-- 
2.11.0

[PATCH 1/2] Staging: unisys: visorbus: style fix, using octal file permissions

[Derek Robson]

Changed file permissions to octal style.
Found with checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 3457ef338e1e..28ca291a4053 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -984,7 +984,7 @@ create_bus_instance(struct visor_device *dev)
goto err_hdr_info;
}
dev->debugfs_client_bus_info =
-   debugfs_create_file("client_bus_info", S_IRUSR | S_IRGRP,
+   debugfs_create_file("client_bus_info", 0440,
dev->debugfs_dir, dev,
_bus_info_debugfs_fops);
if (!dev->debugfs_client_bus_info) {
@@ -1337,10 +1337,10 @@ visorbus_exit(void)
debugfs_remove_recursive(visorbus_debugfs_dir);
 }
 
-module_param_named(forcematch, visorbus_forcematch, int, S_IRUGO);
+module_param_named(forcematch, visorbus_forcematch, int, 0444);
 MODULE_PARM_DESC(visorbus_forcematch,
 "1 to force a successful dev <--> drv match");
 
-module_param_named(forcenomatch, visorbus_forcenomatch, int, S_IRUGO);
+module_param_named(forcenomatch, visorbus_forcenomatch, int, 0444);
 MODULE_PARM_DESC(visorbus_forcenomatch,
 "1 to force an UNsuccessful dev <--> drv match");
-- 
2.11.0

Re: [PATCH] net: use kvmalloc rather than open coded variant

[kbuild test robot]

Hi Michal,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[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/Michal-Hocko/net-use-kvmalloc-rather-than-open-coded-variant/20170107-104105
config: i386-randconfig-n0-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   net/sched/sch_fq.c: In function 'fq_resize':
>> net/sched/sch_fq.c:643:10: error: implicit declaration of function 
>> 'kvmalloc_node' [-Werror=implicit-function-declaration]
 array = kvmalloc_node(sizeof(struct rb_root) << log, GFP_KERNEL | 
__GFP_REPEAT,
 ^
>> net/sched/sch_fq.c:643:8: warning: assignment makes pointer from integer 
>> without a cast [-Wint-conversion]
 array = kvmalloc_node(sizeof(struct rb_root) << log, GFP_KERNEL | 
__GFP_REPEAT,
   ^
   cc1: some warnings being treated as errors

vim +/kvmalloc_node +643 net/sched/sch_fq.c

   637  u32 idx;
   638  
   639  if (q->fq_root && log == q->fq_trees_log)
   640  return 0;
   641  
   642  /* If XPS was setup, we can allocate memory on right NUMA node 
*/
 > 643  array = kvmalloc_node(sizeof(struct rb_root) << log, GFP_KERNEL 
 > | __GFP_REPEAT,
   644
netdev_queue_numa_node_read(sch->dev_queue));
   645  if (!array)
   646  return -ENOMEM;

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


.config.gz
Description: application/gzip

Re: [PATCH] net: use kvmalloc rather than open coded variant

[kbuild test robot]

Hi Michal,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[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/Michal-Hocko/net-use-kvmalloc-rather-than-open-coded-variant/20170107-104105
config: i386-randconfig-n0-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   net/sched/sch_fq.c: In function 'fq_resize':
>> net/sched/sch_fq.c:643:10: error: implicit declaration of function 
>> 'kvmalloc_node' [-Werror=implicit-function-declaration]
 array = kvmalloc_node(sizeof(struct rb_root) << log, GFP_KERNEL | 
__GFP_REPEAT,
 ^
>> net/sched/sch_fq.c:643:8: warning: assignment makes pointer from integer 
>> without a cast [-Wint-conversion]
 array = kvmalloc_node(sizeof(struct rb_root) << log, GFP_KERNEL | 
__GFP_REPEAT,
   ^
   cc1: some warnings being treated as errors

vim +/kvmalloc_node +643 net/sched/sch_fq.c

   637  u32 idx;
   638  
   639  if (q->fq_root && log == q->fq_trees_log)
   640  return 0;
   641  
   642  /* If XPS was setup, we can allocate memory on right NUMA node 
*/
 > 643  array = kvmalloc_node(sizeof(struct rb_root) << log, GFP_KERNEL 
 > | __GFP_REPEAT,
   644
netdev_queue_numa_node_read(sch->dev_queue));
   645  if (!array)
   646  return -ENOMEM;

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


.config.gz
Description: application/gzip

Re: [PATCH] net: use kvmalloc rather than open coded variant

[kbuild test robot]

Hi Michal,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[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/Michal-Hocko/net-use-kvmalloc-rather-than-open-coded-variant/20170107-104105
config: x86_64-randconfig-i0-201701 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Michal-Hocko/net-use-kvmalloc-rather-than-open-coded-variant/20170107-104105
 HEAD 29df6a817f53555953b47c6f8d09397f9f7b598c builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   net/core/dev.c: In function 'netif_alloc_rx_queues':
>> net/core/dev.c:7114:2: error: implicit declaration of function 'kvzalloc' 
>> [-Werror=implicit-function-declaration]
 rx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
 ^
>> net/core/dev.c:7114:5: warning: assignment makes pointer from integer 
>> without a cast
 rx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
^
   net/core/dev.c: In function 'netif_alloc_netdev_queues':
   net/core/dev.c:7154:5: warning: assignment makes pointer from integer 
without a cast
 tx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
^
   net/core/dev.c: In function 'alloc_netdev_mqs':
   net/core/dev.c:7690:4: warning: assignment makes pointer from integer 
without a cast
 p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_REPEAT);
   ^
   cc1: some warnings being treated as errors

vim +/kvzalloc +7114 net/core/dev.c

  7108  unsigned int i, count = dev->num_rx_queues;
  7109  struct netdev_rx_queue *rx;
  7110  size_t sz = count * sizeof(*rx);
  7111  
  7112  BUG_ON(count < 1);
  7113  
> 7114  rx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
  7115  if (!rx)
  7116  return -ENOMEM;
  7117  

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


.config.gz
Description: application/gzip

Re: [PATCH] net: use kvmalloc rather than open coded variant

[kbuild test robot]

Hi Michal,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[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/Michal-Hocko/net-use-kvmalloc-rather-than-open-coded-variant/20170107-104105
config: x86_64-randconfig-i0-201701 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Michal-Hocko/net-use-kvmalloc-rather-than-open-coded-variant/20170107-104105
 HEAD 29df6a817f53555953b47c6f8d09397f9f7b598c builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   net/core/dev.c: In function 'netif_alloc_rx_queues':
>> net/core/dev.c:7114:2: error: implicit declaration of function 'kvzalloc' 
>> [-Werror=implicit-function-declaration]
 rx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
 ^
>> net/core/dev.c:7114:5: warning: assignment makes pointer from integer 
>> without a cast
 rx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
^
   net/core/dev.c: In function 'netif_alloc_netdev_queues':
   net/core/dev.c:7154:5: warning: assignment makes pointer from integer 
without a cast
 tx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
^
   net/core/dev.c: In function 'alloc_netdev_mqs':
   net/core/dev.c:7690:4: warning: assignment makes pointer from integer 
without a cast
 p = kvzalloc(alloc_size, GFP_KERNEL | __GFP_REPEAT);
   ^
   cc1: some warnings being treated as errors

vim +/kvzalloc +7114 net/core/dev.c

  7108  unsigned int i, count = dev->num_rx_queues;
  7109  struct netdev_rx_queue *rx;
  7110  size_t sz = count * sizeof(*rx);
  7111  
  7112  BUG_ON(count < 1);
  7113  
> 7114  rx = kvzalloc(sz, GFP_KERNEL | __GFP_REPEAT);
  7115  if (!rx)
  7116  return -ENOMEM;
  7117  

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


.config.gz
Description: application/gzip

Re: [PATCH] usb: dwc2: use u32 for DT binding parameters

[John Youn]

On 1/6/2017 1:52 PM, John Stultz wrote:
> On Fri, Jan 6, 2017 at 4:45 AM, Leo Yan  wrote:
>> Commit 05ee799f2021 ("usb: dwc2: Move gadget settings into core_params")
>> changes to type u16 for DT binding "g-rx-fifo-size" and
>> "g-np-tx-fifo-size" but use type u32 for "g-tx-fifo-size". Finally the
>> the first two parameters cannot be passed successfully with wrong data
>> format. This is found the data transferring broken on 96boards Hikey.
>>
>> This patch is to change all parameters to u32 type, and verified on
>> Hikey board the DT parameters can pass successfully.
>>
>> Signed-off-by: Leo Yan 
> 
> Nice!
> 
> This patch (while it doesn't apply cleanly to v4.10-rc2) does resolve
> the regression I reported earlier here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_linux-2Dusb_msg150766.html=DgIBaQ=DPL6_X_6JkXFx7AXWqB0tg=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA=pIpbe7JcuPH0X7-CYbBt2U3yE2WPSPtrGaMQRtcvQM0=hYurvvfAzlq9WTDnKKUznSRb5thSAvIO9doLJOzfUSo=
>  
> 
> I didn't see the slight shift to u16s there.
> 
> Leo, does the patch need a respin, or is it against Linus' HEAD and my
> tree is stale?
> 
> Anyway, after re-applying it to my tree:
> Tested-by: John Stultz 
> 

Thanks Leo and John.

I just sent out a rebased version for Felipe to pick up.

Regards,
John

Re: [PATCH] usb: dwc2: use u32 for DT binding parameters

[John Youn]

On 1/6/2017 1:52 PM, John Stultz wrote:
> On Fri, Jan 6, 2017 at 4:45 AM, Leo Yan  wrote:
>> Commit 05ee799f2021 ("usb: dwc2: Move gadget settings into core_params")
>> changes to type u16 for DT binding "g-rx-fifo-size" and
>> "g-np-tx-fifo-size" but use type u32 for "g-tx-fifo-size". Finally the
>> the first two parameters cannot be passed successfully with wrong data
>> format. This is found the data transferring broken on 96boards Hikey.
>>
>> This patch is to change all parameters to u32 type, and verified on
>> Hikey board the DT parameters can pass successfully.
>>
>> Signed-off-by: Leo Yan 
> 
> Nice!
> 
> This patch (while it doesn't apply cleanly to v4.10-rc2) does resolve
> the regression I reported earlier here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_linux-2Dusb_msg150766.html=DgIBaQ=DPL6_X_6JkXFx7AXWqB0tg=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA=pIpbe7JcuPH0X7-CYbBt2U3yE2WPSPtrGaMQRtcvQM0=hYurvvfAzlq9WTDnKKUznSRb5thSAvIO9doLJOzfUSo=
>  
> 
> I didn't see the slight shift to u16s there.
> 
> Leo, does the patch need a respin, or is it against Linus' HEAD and my
> tree is stale?
> 
> Anyway, after re-applying it to my tree:
> Tested-by: John Stultz 
> 

Thanks Leo and John.

I just sent out a rebased version for Felipe to pick up.

Regards,
John

[PATCH] usb: dwc2: use u32 for DT binding parameters

[John Youn]

From: Leo Yan 

Commit 05ee799f2021 ("usb: dwc2: Move gadget settings into core_params")
changes to type u16 for DT binding "g-rx-fifo-size" and
"g-np-tx-fifo-size" but use type u32 for "g-tx-fifo-size". Finally the
the first two parameters cannot be passed successfully with wrong data
format. This is found the data transferring broken on 96boards Hikey.

This patch is to change all parameters to u32 type, and verified on
Hikey board the DT parameters can pass successfully.

[johnyoun: minor rebase]

Signed-off-by: Leo Yan 
Signed-off-by: John Youn 
Tested-by: John Stultz 
---
 drivers/usb/dwc2/core.h   |  4 ++--
 drivers/usb/dwc2/params.c | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e03453..302b8f5f7d27 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -513,8 +513,8 @@ struct dwc2_core_params {
/* Gadget parameters */
bool g_dma;
bool g_dma_desc;
-   u16 g_rx_fifo_size;
-   u16 g_np_tx_fifo_size;
+   u32 g_rx_fifo_size;
+   u32 g_np_tx_fifo_size;
u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
 };
 
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 11fe68a4627b..bcd1e19b4076 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -385,16 +385,16 @@ static void dwc2_set_param(struct dwc2_hsotg *hsotg, void 
*param,
 }
 
 /**
- * dwc2_set_param_u16() - Set a u16 parameter
+ * dwc2_set_param_u32() - Set a u32 parameter
  *
  * See dwc2_set_param().
  */
-static void dwc2_set_param_u16(struct dwc2_hsotg *hsotg, u16 *param,
+static void dwc2_set_param_u32(struct dwc2_hsotg *hsotg, u32 *param,
   bool lookup, char *property, u16 legacy,
   u16 def, u16 min, u16 max)
 {
dwc2_set_param(hsotg, param, lookup, property,
-  legacy, def, min, max, 2);
+  legacy, def, min, max, 4);
 }
 
 /**
@@ -1178,12 +1178,12 @@ static void dwc2_set_parameters(struct dwc2_hsotg 
*hsotg,
 * auto-detect if the hardware does not support the
 * default.
 */
-   dwc2_set_param_u16(hsotg, >g_rx_fifo_size,
+   dwc2_set_param_u32(hsotg, >g_rx_fifo_size,
   true, "g-rx-fifo-size", 2048,
   hw->rx_fifo_size,
   16, hw->rx_fifo_size);
 
-   dwc2_set_param_u16(hsotg, >g_np_tx_fifo_size,
+   dwc2_set_param_u32(hsotg, >g_np_tx_fifo_size,
   true, "g-np-tx-fifo-size", 1024,
   hw->dev_nperio_tx_fifo_size,
   16, hw->dev_nperio_tx_fifo_size);
-- 
2.11.0

[PATCH] usb: dwc2: use u32 for DT binding parameters

[John Youn]

From: Leo Yan 

Commit 05ee799f2021 ("usb: dwc2: Move gadget settings into core_params")
changes to type u16 for DT binding "g-rx-fifo-size" and
"g-np-tx-fifo-size" but use type u32 for "g-tx-fifo-size". Finally the
the first two parameters cannot be passed successfully with wrong data
format. This is found the data transferring broken on 96boards Hikey.

This patch is to change all parameters to u32 type, and verified on
Hikey board the DT parameters can pass successfully.

[johnyoun: minor rebase]

Signed-off-by: Leo Yan 
Signed-off-by: John Youn 
Tested-by: John Stultz 
---
 drivers/usb/dwc2/core.h   |  4 ++--
 drivers/usb/dwc2/params.c | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e03453..302b8f5f7d27 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -513,8 +513,8 @@ struct dwc2_core_params {
/* Gadget parameters */
bool g_dma;
bool g_dma_desc;
-   u16 g_rx_fifo_size;
-   u16 g_np_tx_fifo_size;
+   u32 g_rx_fifo_size;
+   u32 g_np_tx_fifo_size;
u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
 };
 
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 11fe68a4627b..bcd1e19b4076 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -385,16 +385,16 @@ static void dwc2_set_param(struct dwc2_hsotg *hsotg, void 
*param,
 }
 
 /**
- * dwc2_set_param_u16() - Set a u16 parameter
+ * dwc2_set_param_u32() - Set a u32 parameter
  *
  * See dwc2_set_param().
  */
-static void dwc2_set_param_u16(struct dwc2_hsotg *hsotg, u16 *param,
+static void dwc2_set_param_u32(struct dwc2_hsotg *hsotg, u32 *param,
   bool lookup, char *property, u16 legacy,
   u16 def, u16 min, u16 max)
 {
dwc2_set_param(hsotg, param, lookup, property,
-  legacy, def, min, max, 2);
+  legacy, def, min, max, 4);
 }
 
 /**
@@ -1178,12 +1178,12 @@ static void dwc2_set_parameters(struct dwc2_hsotg 
*hsotg,
 * auto-detect if the hardware does not support the
 * default.
 */
-   dwc2_set_param_u16(hsotg, >g_rx_fifo_size,
+   dwc2_set_param_u32(hsotg, >g_rx_fifo_size,
   true, "g-rx-fifo-size", 2048,
   hw->rx_fifo_size,
   16, hw->rx_fifo_size);
 
-   dwc2_set_param_u16(hsotg, >g_np_tx_fifo_size,
+   dwc2_set_param_u32(hsotg, >g_np_tx_fifo_size,
   true, "g-np-tx-fifo-size", 1024,
   hw->dev_nperio_tx_fifo_size,
   16, hw->dev_nperio_tx_fifo_size);
-- 
2.11.0

[PATCH] treewide: fix semicolon.cocci warnings

[kbuild test robot]

net/netfilter/x_tables.c:716:59-60: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Signed-off-by: Fengguang Wu 
---

 x_tables.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -713,7 +713,7 @@ EXPORT_SYMBOL(xt_check_entry_offsets);
 unsigned int *xt_alloc_entry_offsets(unsigned int size)
 {
if (size < (SIZE_MAX / sizeof(unsigned int)))
-   return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);;
+   return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);
 
return NULL;
 

[PATCH] treewide: fix semicolon.cocci warnings

[kbuild test robot]

net/netfilter/x_tables.c:716:59-60: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

Signed-off-by: Fengguang Wu 
---

 x_tables.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -713,7 +713,7 @@ EXPORT_SYMBOL(xt_check_entry_offsets);
 unsigned int *xt_alloc_entry_offsets(unsigned int size)
 {
if (size < (SIZE_MAX / sizeof(unsigned int)))
-   return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);;
+   return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);
 
return NULL;
 

[PATCH v3] ext4: increase the protection of nlink dec and ext4 inode destroy

[yi zhang]

Because of the disk and hardware issue, the ext4 filesystem have
many errors, the inode->i_nlink of ext4 becomes zero abnormally
but the dentry is still positive, it will cause memory corruption
after the following process:

 1) Due to the inode->i_nlink is 0, this inode will be added into
the orhpan list,
 2) ext4_rename() cover this inode, and drop_nlink() will reverse
the inode->i_nlink to 0x,
 3) iput() add this inode to LRU,
 4) evict() will call destroy_inode() to destroy this inode but
skip removing it from the orphan list,
 5) after this, the inode's memory address space will be used by
other module, when the ext4 filesystem change the orphan list, it will
trample other module's data and then may cause oops.

Although we cannot avoid hardware and disk errors, we can control the
softwore error in the ext4 module, do not affect other modules and
increase the difficulty of locating problems.

This patch avoid inode->i_nlink reverse and remove the inode from the
orphan list when destroy it if the list is not empty.

changes since: RFC Patch v2
 - move the protection from drop_nlink() to ext4_rename()

Signed-off-by: zhangyi (F) 
---
 fs/ext4/namei.c | 7 +++
 fs/ext4/super.c | 1 +
 2 files changed, 8 insertions(+)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index eadba91..e0718cd 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -3662,6 +3662,13 @@ static int ext4_rename(struct inode *old_dir, struct 
dentry *old_dentry,
}
 
if (new.inode) {
+   if (new.inode->i_nlink == 0) {
+   ext4_warning_inode(new.inode,
+  "Removing file '%.*s' with no links",
+  new.dentry->d_name.len,
+  new.dentry->d_name.name);
+   set_nlink(new.inode, 1);
+   }
ext4_dec_count(handle, new.inode);
new.inode->i_ctime = current_time(new.inode);
}
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 66845a0..ad5ad42 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -975,6 +975,7 @@ static void ext4_destroy_inode(struct inode *inode)
EXT4_I(inode), sizeof(struct ext4_inode_info),
true);
dump_stack();
+   ext4_orphan_del(NULL, inode);
}
call_rcu(>i_rcu, ext4_i_callback);
 }
-- 
2.5.0

[PATCH v3] ext4: increase the protection of nlink dec and ext4 inode destroy

[yi zhang]

Because of the disk and hardware issue, the ext4 filesystem have
many errors, the inode->i_nlink of ext4 becomes zero abnormally
but the dentry is still positive, it will cause memory corruption
after the following process:

 1) Due to the inode->i_nlink is 0, this inode will be added into
the orhpan list,
 2) ext4_rename() cover this inode, and drop_nlink() will reverse
the inode->i_nlink to 0x,
 3) iput() add this inode to LRU,
 4) evict() will call destroy_inode() to destroy this inode but
skip removing it from the orphan list,
 5) after this, the inode's memory address space will be used by
other module, when the ext4 filesystem change the orphan list, it will
trample other module's data and then may cause oops.

Although we cannot avoid hardware and disk errors, we can control the
softwore error in the ext4 module, do not affect other modules and
increase the difficulty of locating problems.

This patch avoid inode->i_nlink reverse and remove the inode from the
orphan list when destroy it if the list is not empty.

changes since: RFC Patch v2
 - move the protection from drop_nlink() to ext4_rename()

Signed-off-by: zhangyi (F) 
---
 fs/ext4/namei.c | 7 +++
 fs/ext4/super.c | 1 +
 2 files changed, 8 insertions(+)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index eadba91..e0718cd 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -3662,6 +3662,13 @@ static int ext4_rename(struct inode *old_dir, struct 
dentry *old_dentry,
}
 
if (new.inode) {
+   if (new.inode->i_nlink == 0) {
+   ext4_warning_inode(new.inode,
+  "Removing file '%.*s' with no links",
+  new.dentry->d_name.len,
+  new.dentry->d_name.name);
+   set_nlink(new.inode, 1);
+   }
ext4_dec_count(handle, new.inode);
new.inode->i_ctime = current_time(new.inode);
}
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 66845a0..ad5ad42 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -975,6 +975,7 @@ static void ext4_destroy_inode(struct inode *inode)
EXT4_I(inode), sizeof(struct ext4_inode_info),
true);
dump_stack();
+   ext4_orphan_del(NULL, inode);
}
call_rcu(>i_rcu, ext4_i_callback);
 }
-- 
2.5.0

Re: [net-next][PATCH] RDS: validate the requested traces user input against max supported

[David Miller]

From: Santosh Shilimkar 
Date: Fri,  6 Jan 2017 10:44:15 -0800

> Larger than supported value can lead to array read/write overflow.
> 
> Reported-by: Colin Ian King 
> Signed-off-by: Santosh Shilimkar 

Applied, thanks.

Re: [net-next][PATCH] RDS: validate the requested traces user input against max supported

[David Miller]

From: Santosh Shilimkar 
Date: Fri,  6 Jan 2017 10:44:15 -0800

> Larger than supported value can lead to array read/write overflow.
> 
> Reported-by: Colin Ian King 
> Signed-off-by: Santosh Shilimkar 

Applied, thanks.

Re: [PATCH net-next] bridge: multicast to unicast

[Stephen Hemminger]

On Mon,  2 Jan 2017 20:32:14 +0100
Linus Lüssing  wrote:

> This feature is intended for interface types which have a more reliable
> and/or efficient way to deliver unicast packets than broadcast ones
> (e.g. wifi).


Why is this not done in MAC80211 rather than  bridge?

Re: [PATCH net-next] bridge: multicast to unicast

[Stephen Hemminger]

On Mon,  2 Jan 2017 20:32:14 +0100
Linus Lüssing  wrote:

> This feature is intended for interface types which have a more reliable
> and/or efficient way to deliver unicast packets than broadcast ones
> (e.g. wifi).


Why is this not done in MAC80211 rather than  bridge?

[PATCH] Staging: media: lirc: style fix, using octal file permissions

[Derek Robson]

Change file permissions to octal style.
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/media/lirc/lirc_imon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/lirc/lirc_imon.c 
b/drivers/staging/media/lirc/lirc_imon.c
index 1e650fba4a92..6c8a4a15278e 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -182,7 +182,7 @@ MODULE_DESCRIPTION(MOD_DESC);
 MODULE_VERSION(MOD_VERSION);
 MODULE_LICENSE("GPL");
 MODULE_DEVICE_TABLE(usb, imon_usb_id_table);
-module_param(debug, int, S_IRUGO | S_IWUSR);
+module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "Debug messages: 0=no, 1=yes(default: no)");
 
 static void free_imon_context(struct imon_context *context)
-- 
2.11.0

[PATCH] Staging: media: lirc: style fix, using octal file permissions

[Derek Robson]

Change file permissions to octal style.
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/media/lirc/lirc_imon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/lirc/lirc_imon.c 
b/drivers/staging/media/lirc/lirc_imon.c
index 1e650fba4a92..6c8a4a15278e 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -182,7 +182,7 @@ MODULE_DESCRIPTION(MOD_DESC);
 MODULE_VERSION(MOD_VERSION);
 MODULE_LICENSE("GPL");
 MODULE_DEVICE_TABLE(usb, imon_usb_id_table);
-module_param(debug, int, S_IRUGO | S_IWUSR);
+module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "Debug messages: 0=no, 1=yes(default: no)");
 
 static void free_imon_context(struct imon_context *context)
-- 
2.11.0

Re: [PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock

[Andy Gross]

On Fri, Jan 06, 2017 at 05:10:44PM -0800, John Stultz wrote:
> On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson
>  wrote:
> > As per the device tree binding the apq8064 scm node requires the core
> > clock to be specified, so add this.
> >
> > Cc: John Stultz 
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> > b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > index 268bd470c865..78bf155a52f3 100644
> > --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> > +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > @@ -303,6 +303,9 @@
> > firmware {
> > scm {
> > compatible = "qcom,scm-apq8064";
> > +
> > +   clocks = < CE3_CORE_CLK>;
> > +   clock-names = "core";
> 
> 
> Tested-by: John Stultz 
> 
> I know Bjorn has a new version of this patch that uses the
> RPM_DAYTONA_FABRIC_CLK value, but that one results in problems with
> usb gadget functionality on my Nexus7.  This one seems to work ok
> though.

Odd.  Is the usb gadget using the daytona but not getting a reference?  I wonder
if this is related to not having the bus driver running the bus clk enablement
and frequencies.


Andy

Re: [PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock

[Andy Gross]

On Fri, Jan 06, 2017 at 05:10:44PM -0800, John Stultz wrote:
> On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson
>  wrote:
> > As per the device tree binding the apq8064 scm node requires the core
> > clock to be specified, so add this.
> >
> > Cc: John Stultz 
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> > b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > index 268bd470c865..78bf155a52f3 100644
> > --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> > +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > @@ -303,6 +303,9 @@
> > firmware {
> > scm {
> > compatible = "qcom,scm-apq8064";
> > +
> > +   clocks = < CE3_CORE_CLK>;
> > +   clock-names = "core";
> 
> 
> Tested-by: John Stultz 
> 
> I know Bjorn has a new version of this patch that uses the
> RPM_DAYTONA_FABRIC_CLK value, but that one results in problems with
> usb gadget functionality on my Nexus7.  This one seems to work ok
> though.

Odd.  Is the usb gadget using the daytona but not getting a reference?  I wonder
if this is related to not having the bus driver running the bus clk enablement
and frequencies.


Andy

Re: [PATCH net-next 0/2] afs: Implement bulk read

[David Miller]

From: David Howells <dhowe...@redhat.com>
Date: Fri, 06 Jan 2017 17:08:40 +

> This pair of patches implements bulk data reading from an AFS server.
> 
> The patches can be found here also:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite
> 
> Tagged thusly:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-rewrite-20170106

Pulled, thanks David.

Re: [PATCH net-next 0/2] afs: Implement bulk read

[David Miller]

From: David Howells 
Date: Fri, 06 Jan 2017 17:08:40 +

> This pair of patches implements bulk data reading from an AFS server.
> 
> The patches can be found here also:
> 
>   
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite
> 
> Tagged thusly:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-rewrite-20170106

Pulled, thanks David.

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[Joel Fernandes]

Hi John,

On Fri, Jan 6, 2017 at 4:48 PM, John Stultz  wrote:
> On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
>> This boot clock can be used as a tracing clock and will account for
>> suspend time.
>>
>> To keep it NMI safe since we're accessing from tracing, we're not using a
>> separate timekeeper with updates to monotonic clock and boot offset
>> protected with seqlocks. This has the following minor side effects:
>>
>> (1) Its possible that a timestamp be taken after the boot offset is updated
>> but before the timekeeper is updated. If this happens, the new boot offset
>> is added to the old timekeeping making the clock appear to update slightly
>> earlier:
>>CPU 0CPU 1
>>timekeeping_inject_sleeptime64()
>>__timekeeping_inject_sleeptime(tk, delta);
>> timestamp();
>>timekeeping_update(tk, TK_CLEAR_NTP...);
>>
>> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
>> partially updated.  Since the tk->offs_boot update is a rare event, this
>> should be a rare occurrence which postprocessing should be able to handle.
>>
>> Cc: Steven Rostedt 
>> Cc: Thomas Gleixner 
>> Cc: John Stultz 
>> Cc: Ingo Molnar 
>> Signed-off-by: Joel Fernandes 
>
> Hey Joel,
>   Hope you had a good new years! I was queuing this up for testing,

Thanks, yes I had a great new years, hope you did too.

> and the patch set no longer applies (to v4.10-rc2). Can you respin it
> and resend it?

Actually these patches are already in 4.10-rc2.

Regards,
Joel

Re: [PATCH v3 1/3] timekeeping: Add a fast and NMI safe boot clock

[Joel Fernandes]

Hi John,

On Fri, Jan 6, 2017 at 4:48 PM, John Stultz  wrote:
> On Thu, Nov 24, 2016 at 12:20 PM, Joel Fernandes  wrote:
>> This boot clock can be used as a tracing clock and will account for
>> suspend time.
>>
>> To keep it NMI safe since we're accessing from tracing, we're not using a
>> separate timekeeper with updates to monotonic clock and boot offset
>> protected with seqlocks. This has the following minor side effects:
>>
>> (1) Its possible that a timestamp be taken after the boot offset is updated
>> but before the timekeeper is updated. If this happens, the new boot offset
>> is added to the old timekeeping making the clock appear to update slightly
>> earlier:
>>CPU 0CPU 1
>>timekeeping_inject_sleeptime64()
>>__timekeeping_inject_sleeptime(tk, delta);
>> timestamp();
>>timekeeping_update(tk, TK_CLEAR_NTP...);
>>
>> (2) On 32-bit systems, the 64-bit boot offset (tk->offs_boot) may be
>> partially updated.  Since the tk->offs_boot update is a rare event, this
>> should be a rare occurrence which postprocessing should be able to handle.
>>
>> Cc: Steven Rostedt 
>> Cc: Thomas Gleixner 
>> Cc: John Stultz 
>> Cc: Ingo Molnar 
>> Signed-off-by: Joel Fernandes 
>
> Hey Joel,
>   Hope you had a good new years! I was queuing this up for testing,

Thanks, yes I had a great new years, hope you did too.

> and the patch set no longer applies (to v4.10-rc2). Can you respin it
> and resend it?

Actually these patches are already in 4.10-rc2.

Regards,
Joel