Re: [RFC PATCH 00/15] Provide atomics and bitops implemented with ISO C++11 atomics

[Paul E. McKenney]

On Wed, Jun 01, 2016 at 03:45:45PM +0100, Will Deacon wrote:
> Hi David,
> 
> On Wed, May 18, 2016 at 04:10:37PM +0100, David Howells wrote:
> > 
> > Here's a set of patches to provide kernel atomics and bitops implemented
> > with ISO C++11 atomic intrinsics.  The second part of the set makes the x86
> > arch use the implementation.
> 
> As you know, I'm really not a big fan of this :)
> 
> Whilst you're seeing some advantages in using this on x86, I suspect
> that's because the vast majority of memory models out there end up using
> similar instructions sequences on that architecture (i.e. MOV and a very
> occasional mfence). For weakly ordered architectures such as arm64, the
> kernel memory model is noticeably different to that offered by C11 and
> I'd be hesitant to map the two as you're proposing here, for the following
> reasons:
> 
>   (1) C11's SC RMW operations are weaker than our full barrier atomics
> 
>   (2) There is no high quality implementation of consume loads, so we'd
>   either need to continue using our existing rcu_deference code or
>   be forced to use acquire loads
> 
>   (3) wmb/rmb don't exist in C11
> 
>   (4) We patch our atomics at runtime based on the CPU capabilites, since
>   we require a single binary kernel Image
> 
>   (5) Even recent versions of GCC have been found to have serious issues
>   generating correct (let alone performant) code [1]
> 
>   (6) If we start mixing and patching C11 atomics with homebrew atomics
>   in an attempt to address some of the issues above, we open ourselves
>   up to potential data races (i.e. undefined behaviour), but I doubt
>   existing compilers actually manage to detect this.

One of the big short-term benefits of David's work is the resulting
bug reports against gcc on sub-optimal code, a number of which are
now fixed, if I remember correctly.  I do agree that the differences
between C11's and the Linux kernel's memory models mean that you have
to be quite careful when using C11 atomics in the Linux kernel.
Even ignoring the self-modifying Linux kernels.  ;-)

> Now, given all of that, you might be surprised to hear that I'm not
> completely against some usage of C11 atomics in the kernel! What I think
> would work quite nicely is defining an asm-generic interface built solely
> out of the C11 _relaxed atomics and SC fences. Would it be efficient? Almost
> certainly not. Would it be useful for new architecture ports to get up and
> running quickly? Definitely.

I agree that might be very hard for the C11 intrinsics to beat tightly
coded asms.  But it might not be all that long before the compilers can
beat straightforward hand-written assembly.  And the compiler might well
eventually be able to beat even tightly code asms in the more complex
cases such as cmpxchg loops.

> In my opinion, if an architecture wants to go further than that (like you've
> proposed here), then the code should be entirely confined to the relevant
> arch/ directory and not advertised as a general, portable mapping between
> the memory models.

Agreed, at least in the near term.

Thanx, Paul

> Will
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69875
> 

Re: [PATCH 06/11] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock

[Rob Herring]

On Tue, Jun 07, 2016 at 03:44:39PM -0700, Douglas Anderson wrote:
> Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work
> with arasan,sdhci-5.1) need to know the card clock in order to function
> properly.  Let's expose this clock using a standard device tree
> mechanism so that the PHY can get access to and query the card clock.

Need to know the clock freq or need the clock? The former doesn't need 
to be in DT.

> 
> Signed-off-by: Douglas Anderson 
> ---
>  Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt 
> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index b67e623ca1ff..074d03e630ec 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -30,6 +30,12 @@ Optional Properties:
>- arasan,soc-ctl-syscon: A phandle to a syscon device (see 
> ../mfd/syscon.txt)
>  used to access core corecfg registers.  Offsets of registers in this
>  syscon are determined based on the main compatible string for the device.
> +  - clock-output-names: If specified, this will be the name of the card clock
> +which will be exposed by this device.  Required if #clock-cells is
> +specified.
> +  - #clock-cells: If specified this should be the value <0>.  With this 
> property
> +in place we will export a clock representing the Card Clock.  This clock
> +is expected to be consumed by our PHY.  You must also specify
>  
>  Example:
>   sdhci@e010 {
> @@ -61,7 +67,9 @@ Example:
>   arasan,soc-ctl-syscon = <>;
>   assigned-clocks = < SCLK_EMMC>;
>   assigned-clock-rates = <2>;
> + clock-output-names = "emmc_cardclock";
>   phys = <_phy>;
>   phy-names = "phy_arasan";
> + #clock-cells = <0>;
>   status = "disabled";
>   };
> -- 
> 2.8.0.rc3.226.g39d4020
> 

Re: [PATCH 2/4] dell-wmi: Sort WMI event codes and update comments

[Pali Rohár]

On Wednesday 08 June 2016 22:15:18 Darren Hart wrote:
> On Wed, Jun 08, 2016 at 09:57:26PM +0200, Pali Rohár wrote:
> > On Wednesday 08 June 2016 21:48:24 Darren Hart wrote:
> > > On Wed, Jun 08, 2016 at 12:03:24AM +0200, Pali Rohár wrote:
> > > > On Thursday 02 June 2016 12:41:42 Michał Kępień wrote:
> > > > > > Signed-off-by: Pali Rohár 
> > > > > 
> > > > > My guess is that Darren won't let you off without at least a
> > > > > short commit message.
> > > > 
> > > > I have no idea what else to write. I think that description is
> > > > enough.
> > > 
> > > There is always something. For example, why? See
> > > Documentation/SubmittingPatches section "14) The canonical patch
> > > format" for an explanation.
> > > 
> > > "Traceability" of changes is important. If it's worth preparing
> > > the patch, it's worth documenting why.
> > 
> > In my opinion current description is enough and cover everything
> > what this patch is doing. I think it is clear from my description
> > what this patch is doing and so it is documented.
> > 
> > But if it is not clear and something is missing, let me know or
> > show what is wrong and how you change it... It is just my
> > assumption that "Sort WMI event codes and update comments" is
> > clear...
> 
> The patch summary accurately states what it does. It does not explain
> why it does it, or why it is necessary. I understand this is a
> trivial change, but also understand that both maintainers and people
> doing maintenance and regression analysis will appreciate
> understanding the motivation and intent of the patch, in addition to
> the content of the patch.
> 
> From the maintainer perspective, whether we have 20 or 200 patches to
> review, we will naturally merge the ones that require the least
> effort first. This maximizes our efficiency and benefits the most
> people with what time we have available. For many of us, this is our
> nights and weekends (guessing that's the case for you as well). It
> is in the submitter's best interest to take the time document the
> why, what, and how of each patch in a way that minimizes the effort
> on the part of the maintainer to decide if the patch should be
> merged. It is also a matter of scale, if every patch conforms to
> these guidelines, the workflow is much more efficient.
> 
> In this case, I don't know why you decided to sort the event codes or
> update the comments. I assume the comments were wrong before, but
> maybe something changed. Do you care about alphabetically order or
> optimizing the switch statements? Is it purely for legibility? Etc.
> 
> If that isn't sufficient, then just do it out of self-interest,
> because I will not send patches to Linus that do not provide both a
> summary and a description in the commit which meet the guidelines of
> section 14 referenced above.
> 
> Thanks,

I fully understand your maintainer perspective. I just though that my 
one line explain everything what is needed about my patch...

So do you want to include reason for my patch? What about this 
additional description?

===
For better readability of keymap table, sort events by codes and also 
update comments for events to be more informative.
===

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] Documentation: bindings: add dt documentation for Rockchip PCIe PHY

[Heiko Stübner]

Am Mittwoch, 8. Juni 2016, 15:29:00 schrieb Rob Herring:
> gOn Wed, Jun 08, 2016 at 03:25:08PM +0800, Shawn Lin wrote:
> > This patch adds a binding that describes the Rockchip PCIe PHY
> > found on Rockchip SoCs PCIe interface.
> > 
> > Signed-off-by: Shawn Lin 
> > ---
> > 
> >  .../devicetree/bindings/phy/rockchip-pcie-phy.txt  | 22
> >  ++ 1 file changed, 22 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt> 
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt
> > b/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt new file
> > mode 100644
> > index 000..ba8c406
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt
> > @@ -0,0 +1,22 @@
> > +Rockchip PCIE PHY
> > +---
> > +
> > +Required properties:
> > + - compatible: rockchip,rk3399-pcie-phy
> > + - #phy-cells: must be 0
> > +
> > +Example:
> > +
> > +grf: syscon@ff77 {
> > +   compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   ...
> > +
> > +   pcie_phy: phy@e220 {
> 
> unit-address needs a reg property or drop the unit address. I'd do the
> former if there's a register range you can describe here.

Hmm, I think I'd suggest going the other way - call the node pcie-phy .

While the General Register Files do contain some specific address ranges (like 
for the emmc phy, or some performance monitor things), the register at 0xe220 
is a shared register (GRF_SOC_CON8), containing both i2s and pcie setting 
bits.

Specifying register ranges suggests some form of exclusivity to me - which is 
just great for things like the emmc phy that has an actual range, but for a 
device being controlled from some shared register.


Heiko

Re: [PATCH] bitmap: bitmap_equal memcmp optimization

[Andrew Morton]

On Tue,  7 Jun 2016 10:37:41 +0200 Martin Schwidefsky  
wrote:

> The bitmap_equal function has optimized code for small bitmaps with less
> than BITS_PER_LONG bits. For larger bitmaps the out-of-line function
> __bitmap_equal is called.
> 
> For a constant number of bits divisible by BITS_PER_LONG the memcmp
> function can be used. For s390 gcc knows how to optimize this function,
> memcmp calls with up to 256 bytes / 2048 bits are translated into a
> single instruction.

Patch looks simple enough, although it would benefit from a comment
explaining what's special about s390.

> --- a/include/linux/bitmap.h
> +++ b/include/linux/bitmap.h
> @@ -267,6 +267,10 @@ static inline int bitmap_equal(const unsigned long *src1,
>  {
>   if (small_const_nbits(nbits))
>   return ! ((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits));
> +#ifdef CONFIG_S390
> + else if (__builtin_constant_p(nbits) && (nbits % BITS_PER_LONG) == 0)
> + return !memcmp(src1, src2, nbits / 8);
> +#endif
>   else
>   return __bitmap_equal(src1, src2, nbits);
>  }

Those elses are a bit daffy.  This:

--- a/include/linux/bitmap.h~bitmap-bitmap_equal-memcmp-optimization-fix
+++ a/include/linux/bitmap.h
@@ -266,13 +266,12 @@ static inline int bitmap_equal(const uns
const unsigned long *src2, unsigned int nbits)
 {
if (small_const_nbits(nbits))
-   return ! ((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits));
+   return !((*src1 ^ *src2) & BITMAP_LAST_WORD_MASK(nbits));
 #ifdef CONFIG_S390
-   else if (__builtin_constant_p(nbits) && (nbits % BITS_PER_LONG) == 0)
+   if (__builtin_constant_p(nbits) && (nbits % BITS_PER_LONG) == 0)
return !memcmp(src1, src2, nbits / 8);
 #endif
-   else
-   return __bitmap_equal(src1, src2, nbits);
+   return __bitmap_equal(src1, src2, nbits);
 }
 
 static inline int bitmap_intersects(const unsigned long *src1,
_

Re: [PATCH 2/4] dell-wmi: Sort WMI event codes and update comments

[Darren Hart]

On Wed, Jun 08, 2016 at 10:27:20PM +0200, Pali Rohár wrote:
> On Wednesday 08 June 2016 22:15:18 Darren Hart wrote:
> > On Wed, Jun 08, 2016 at 09:57:26PM +0200, Pali Rohár wrote:
> > > On Wednesday 08 June 2016 21:48:24 Darren Hart wrote:
> > > > On Wed, Jun 08, 2016 at 12:03:24AM +0200, Pali Rohár wrote:
> > > > > On Thursday 02 June 2016 12:41:42 Michał Kępień wrote:
> > > > > > > Signed-off-by: Pali Rohár 
> > > > > > 
> > > > > > My guess is that Darren won't let you off without at least a
> > > > > > short commit message.
> > > > > 
> > > > > I have no idea what else to write. I think that description is
> > > > > enough.
> > > > 
> > > > There is always something. For example, why? See
> > > > Documentation/SubmittingPatches section "14) The canonical patch
> > > > format" for an explanation.
> > > > 
> > > > "Traceability" of changes is important. If it's worth preparing
> > > > the patch, it's worth documenting why.
> > > 
> > > In my opinion current description is enough and cover everything
> > > what this patch is doing. I think it is clear from my description
> > > what this patch is doing and so it is documented.
> > > 
> > > But if it is not clear and something is missing, let me know or
> > > show what is wrong and how you change it... It is just my
> > > assumption that "Sort WMI event codes and update comments" is
> > > clear...
> > 
> > The patch summary accurately states what it does. It does not explain
> > why it does it, or why it is necessary. I understand this is a
> > trivial change, but also understand that both maintainers and people
> > doing maintenance and regression analysis will appreciate
> > understanding the motivation and intent of the patch, in addition to
> > the content of the patch.
> > 
> > From the maintainer perspective, whether we have 20 or 200 patches to
> > review, we will naturally merge the ones that require the least
> > effort first. This maximizes our efficiency and benefits the most
> > people with what time we have available. For many of us, this is our
> > nights and weekends (guessing that's the case for you as well). It
> > is in the submitter's best interest to take the time document the
> > why, what, and how of each patch in a way that minimizes the effort
> > on the part of the maintainer to decide if the patch should be
> > merged. It is also a matter of scale, if every patch conforms to
> > these guidelines, the workflow is much more efficient.
> > 
> > In this case, I don't know why you decided to sort the event codes or
> > update the comments. I assume the comments were wrong before, but
> > maybe something changed. Do you care about alphabetically order or
> > optimizing the switch statements? Is it purely for legibility? Etc.
> > 
> > If that isn't sufficient, then just do it out of self-interest,
> > because I will not send patches to Linus that do not provide both a
> > summary and a description in the commit which meet the guidelines of
> > section 14 referenced above.
> > 
> > Thanks,
> 
> I fully understand your maintainer perspective. I just though that my 
> one line explain everything what is needed about my patch...
> 
> So do you want to include reason for my patch? What about this 
> additional description?
> 
> ===
> For better readability of keymap table, sort events by codes and also 
> update comments for events to be more informative.

Great, that works for me. Reason was readability and providing context.

I'm just getting to the series now, if it's otherwise ready, I'll include this
myself. If changes are required, I'll leave it to you. Thanks Pali.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] x86:pvclock: add missing barriers

[Roman Kagan]

On Wed, Jun 08, 2016 at 09:45:09PM +0200, Borislav Petkov wrote:
> On Wed, Jun 08, 2016 at 09:11:39PM +0300, Roman Kagan wrote:
> > Gradual removal of excessive barriers in pvclock reading functions
> > (commits 502dfeff239e8313bfbe906ca0a1a6827ac8481b,
> > a3eb97bd80134ba07864ca00747466c02118aca1) ended up removing too much:
> > although rdtsc is now orderd WRT other loads, there's no protection
> > against the compiler reordering the loads of ->version with the loads of
> > other fields.
> > 
> > E.g. on my system gcc-5.3.1 generates code which loads ->system_time and
> > ->flags outside of the ->version test loop.
> > 
> > (Re)introduce the compiler barriers around accesses to the contents of
> > pvclock.  While at this, make the function a bit more compact by
> > removing unnecessary local variables.
> > 
> > Signed-off-by: Roman Kagan 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: x...@kernel.org
> > Cc: Andy Lutomirski 
> > Cc: Borislav Petkov 
> > Cc: Paolo Bonzini 
> > Cc: sta...@vger.kernel.org
> > ---
> >  arch/x86/include/asm/pvclock.h | 17 +
> >  1 file changed, 5 insertions(+), 12 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
> > index fdcc040..65c4de2 100644
> > --- a/arch/x86/include/asm/pvclock.h
> > +++ b/arch/x86/include/asm/pvclock.h
> > @@ -80,18 +80,11 @@ static __always_inline
> >  unsigned __pvclock_read_cycles(const struct pvclock_vcpu_time_info *src,
> >cycle_t *cycles, u8 *flags)
> >  {
> > -   unsigned version;
> > -   cycle_t ret, offset;
> > -   u8 ret_flags;
> > -
> > -   version = src->version;
> > -
> > -   offset = pvclock_get_nsec_offset(src);
> > -   ret = src->system_time + offset;
> > -   ret_flags = src->flags;
> > -
> > -   *cycles = ret;
> > -   *flags = ret_flags;
> > +   unsigned version = src->version;
> > +   barrier();
> > +   *cycles = src->system_time + pvclock_get_nsec_offset(src);
> > +   *flags = src->flags;
> > +   barrier();
> > return version;
> 
> I have a similar patchset in my mbox starting here:
> 
> https://lkml.kernel.org/r/1464329832-4638-1-git-send-email-mngh...@gmail.com
> 
> Care to take a look?

Just did, thanks for the link.

The difference is whether you want the reader to see consistent view of
the pvclock data (as in my patch) or also the most up to date one
(as in Minfei Huang's patch) at the cost of extra lfence instructions
(on my machine this is 30% slowdown).

I'm not sure if the latter is really necessary.  If it is, then the
lfence or mfence in rdtsc_ordered() becomes excessive.  Perhaps we'd
have to revert to rdtsc_barrier() to surround pvclock data access, and
plain rdtsc() instead of rdtsc_ordered().

Roman.

Re: [PATCH v9 0/7] KVM PCIe/MSI passthrough on ARM/ARM64: kernel part 3/3: vfio changes

[Alex Williamson]

On Wed, 8 Jun 2016 10:29:35 +0200
Auger Eric  wrote:

> Dear all,
> Le 20/05/2016 à 18:01, Eric Auger a écrit :
> > Alex, Robin,
> > 
> > While my 3 part series primarily addresses the problematic of mapping
> > MSI doorbells into arm-smmu, it fails in :
> > 
> > 1) determining whether the MSI controller is downstream or upstream to
> > the IOMMU,  
> > => indicates whether the MSI doorbell must be mapped
> > => participates in the decision about 2)  
> > 
> > 2) determining whether it is safe to assign a PCIe device.
> > 
> > I think we share this understanding with Robin. All above of course
> > stands for ARM.
> > 
> > I get stuck with those 2 issues and I have few questions about iommu
> > group setup, PCIe, iommu dt/ACPI description. I would be grateful to you
> > if you could answer part of those questions and advise about the
> > strategy to fix those.  
> 
> gentle reminder about the questions below; hope I did not miss any reply.
> If anybody has some time to spent on this topic...
> 
> > 
> > Best Regards
> > 
> > Eric
> > 
> > QUESTIONS:
> > 
> > 1) Robin, you pointed some host controllers which also are MSI
> > controllers
> > (http://thread.gmane.org/gmane.linux.kernel.pci/47174/focus=47268). In
> > that case MSIs never reach the IOMMU. I failed in finding anything about
> > MSIs in PCIe ACS spec. What should be the iommu groups in that
> > situation. Isn't the upstreamed code able to see some DMA transfers are
> > not properly isolated and alias devices in the same group? According to
> > your security warning, Alex, I would think the code does not recognize
> > it, can you confirm please?  
> my current understanding is end points would be in separate groups (assuming
> ACS support) although MSI controller frame is not properly protected.

We don't currently consider MSI differently from other DMA and we don't
currently have any sort of concept of a device within the intermediate
fabric as being a DMA target.  We expect fabric devices to only be
transaction routers.  We use ACS to determine whether there's any
possibility of DMA being redirected before it reaches the IOMMU, but it
seems that a DMA being consumed by an interrupt controller before it
reaches the IOMMU would be another cause for an isolation breach.
 
> > 2) can other PCIe components be MSI controllers?

I'm not even entirely sure what this means.  Would a DMA write from an
endpoint target the MMIO space of an intermediate, fabric device?
 
> > 3) Am I obliged to consider arbitrary topologies where an MSI controller
> > stands between the PCIe host and the iommu? in the PCIe space or
> > platform space? If this only relates to PCIe couldn' I check if an MSI
> > controller exists in the PCIe tree?  
> In my last series, I consider the assignment of platform device unsafe as
> soon as there is a GICv2m. This is a change in the user experience compared to
> what we have before.

If the MSI controller is downstream of our DMA translation, it doesn't
seem like we have much choice but to mark it unsafe.  The endpoint is
fully able to attempt to exploit it.
 
> > 4) Robin suggested in a private thread to enumerate through a list of
> > "registered" doorbells and if any belongs to an unsafe MSI controller,
> > consider the assignment is unsafe. This would be a first step before
> > doing something more complex. Alex, would that be acceptable to you for
> > issue #2?  
> I implemented this technique in my last series waiting for more discussion
> on 4, 5.

Seems sufficient.  I don't mind taking a broad swing versus all the
extra complexity of defining which devices are safe vs unsafe.
 
> > 5) About issue #1: don't we miss tools in dt/ACPI to describe the
> > location of the iommu on ARM? This is not needed on x86 because
> > irq_remapping and IOMMU are at the same place but my understanding is
> > that it is on ARM where
> > - there is no connection between the MSI controller - which implements
> > irq remapping - and the iommu
> > - MSI are conveyed on the same address space as standard memory
> > transactions.

It seems pretty dubious to me to have fixed address, unprotected MSI
controllers sitting in the DMA space of a device before IOMMU
translation.  Seems like you not only need to mark interrupts as
unsafe, but exclude the address space of the MSI controller from the
available IOVA space to the user.
 
> > 6)  can't we live with iommu/MSI controller respective location uncertainty?
> > 
> > - in my current series, with the above Xilinx MSI controller, I would
> > see there is an arm-smmu requiring mapping behind the PCI host, would
> > query the characteristics of the MSI doorbell (not implemented by that
> > controller), so no mapping would be done. So it would work I think.
> > - However in case we have this topology: PCIe host -> MSI controller
> > generally used behind an IOMMU (so registering a doorbell) -> IOMMU,
> > this wouldn't work since the doorbell would be mapped.  

I'm a little 

[PATCH v4 19/29] staging: unisys: visorbus: fix visorchannel.c comments

[David Kershner]

From: David Binder 

This patch ONLY touches comment lines, i.e., NO executable code is
affected.

Comments were fixed in visorchannel.c:
* All functions worthy of documenting now use standard kerneldoc
  formatting.
* Multi-line comments were tweaked so as to use appropriate conventions.
* Minor typos were corrected.
* Useless comments were removed.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
Signed-off-by: David Binder 
---
 drivers/staging/unisys/visorbus/visorchannel.c | 83 ++
 1 file changed, 71 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 1bfbc06..0ddfe05 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -15,7 +15,7 @@
  */
 
 /*
- *  This provides Supervisor channel communication primitives, which are
+ *  This provides s-Par channel communication primitives, which are
  *  independent of the mechanism used to access the channel data.
  */
 
@@ -55,8 +55,28 @@ struct visorchannel {
uuid_le inst;
 };
 
-/* Creates the struct visorchannel abstraction for a data area in memory,
- * but does NOT modify this data area.
+/**
+ * visorchannel_create_guts() - creates the struct visorchannel abstraction
+ *  for a data area in memory, but does NOT modify
+ *  this data area
+ * @physaddr:  physical address of start of channel
+ * @channel_bytes: size of the channel in bytes; this may 0 if the channel has
+ * already been initialized in memory (which is true for all
+ * channels provided to guest environments by the s-Par
+ * back-end), in which case the actual channel size will be
+ * read from the channel header in memory
+ * @gfp:   gfp_t to use when allocating memory for the data struct
+ * @guid:  uuid that identifies channel type; this may 0 if the channel
+ * has already been initialized in memory (which is true for 
all
+ * channels provided to guest environments by the s-Par
+ * back-end), in which case the actual channel guid will be
+ * read from the channel header in memory
+ * @needs_lock:must specify true if you have multiple threads of execution
+ * that will be calling visorchannel methods of this
+ * visorchannel at the same time
+ *
+ * Return: pointer to visorchannel that was created if successful,
+ * otherwise NULL
  */
 static struct visorchannel *
 visorchannel_create_guts(u64 physaddr, unsigned long channel_bytes,
@@ -77,7 +97,8 @@ visorchannel_create_guts(u64 physaddr, unsigned long 
channel_bytes,
spin_lock_init(>insert_lock);
spin_lock_init(>remove_lock);
 
-   /* Video driver constains the efi framebuffer so it will get a
+   /*
+* Video driver constains the efi framebuffer so it will get a
 * conflict resource when requesting its full mem region. Since
 * we are only using the efi framebuffer for video we can ignore
 * this. Remember that we haven't requested it so we don't try to
@@ -214,6 +235,12 @@ visorchannel_set_clientpartition(struct visorchannel 
*channel,
return 0;
 }
 
+/**
+ * visorchannel_get_uuid() - queries the UUID of the designated channel
+ * @channel: the channel to query
+ *
+ * Return: the UUID of the provided channel
+ */
 uuid_le
 visorchannel_get_uuid(struct visorchannel *channel)
 {
@@ -260,22 +287,25 @@ visorchannel_get_header(struct visorchannel *channel)
return (void __iomem *)>chan_hdr;
 }
 
-/** Return offset of a specific SIGNAL_QUEUE_HEADER from the beginning of a
- *  channel header
+/*
+ * Return offset of a specific SIGNAL_QUEUE_HEADER from the beginning of a
+ * channel header
  */
 #define SIG_QUEUE_OFFSET(chan_hdr, q) \
((chan_hdr)->ch_space_offset + \
 ((q) * sizeof(struct signal_queue_header)))
 
-/** Return offset of a specific queue entry (data) from the beginning of a
- *  channel header
+/*
+ * Return offset of a specific queue entry (data) from the beginning of a
+ * channel header
  */
 #define SIG_DATA_OFFSET(chan_hdr, q, sig_hdr, slot) \
(SIG_QUEUE_OFFSET(chan_hdr, q) + (sig_hdr)->sig_base_offset + \
((slot) * (sig_hdr)->signal_size))
 
-/** Write the contents of a specific field within a SIGNAL_QUEUE_HEADER back
- *  into host memory
+/*
+ * Write the contents of a specific field within a SIGNAL_QUEUE_HEADER back
+ * into host memory
  */
 #define SIG_WRITE_FIELD(channel, queue, sig_hdr, FIELD)
 \
(visorchannel_write(channel, \
@@ -350,7 +380,8 @@ signalremove_inner(struct visorchannel *channel, u32 queue, 

[GIT PULL] arch/sh updates for 4.7

[Rich Felker]

Hi Linus,

Here are arch/sh changes for 4.7. I realize and apologize that these
are rather late coming. That's due to a mix of a (probably misguided)
attempt to get the baseline J-Core support changes in and unexpected
personal circumstances.

If you can merge these still I'd appreciate it (they don't affect
anything outside arch/sh) but if not I can hold them until next time.

Rich


--

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.libc.org/linux-sh tags/sh-for-4.7

for you to fetch changes up to 21233d635e161daa5d46d6d13c85320725f40e47:

  sh: fix build regression with CONFIG_OF && !CONFIG_OF_FLATTREE (2016-06-08 
00:35:30 +)


These changes include fixes for some nommu-specific bugs and for minor
bugs introduced in 4.6, cleanup, builtin DTB support, and resolution
of a longstanding sigcontext ABI mismatch issue.


Pan Xinhui (1):
  sh: cmpxchg: fix a bit shift bug in big_endian os

Paul Gortmaker (4):
  sh: make time.c explicitly non-modular
  sh: make mm/asids-debugfs explicitly non-modular
  sh: make board-secureedge5410 explicitly non-modular
  sh: make heartbeat driver explicitly non-modular

Rich Felker (6):
  sh: add support for linking a builtin device tree blob in the kernel
  sh: make sigcontext definition consistent across fpu/nofpu models
  sh: disable aliased page logic on NOMMU models
  sh: fix futex/robust_list on nommu models
  sh: allow clocksource drivers to register sched_clock backends
  sh: fix build regression with CONFIG_OF && !CONFIG_OF_FLATTREE

 arch/sh/Kconfig   | 22 ++
 arch/sh/Makefile  |  2 ++
 arch/sh/boards/board-secureedge5410.c |  3 +--
 arch/sh/boards/of-generic.c   | 15 ---
 arch/sh/boot/dts/Makefile |  3 +++
 arch/sh/drivers/heartbeat.c   | 32 +++-
 arch/sh/include/asm/cmpxchg-xchg.h|  2 +-
 arch/sh/include/uapi/asm/sigcontext.h |  3 ---
 arch/sh/kernel/cpu/init.c |  4 
 arch/sh/kernel/head_32.S  |  6 +++---
 arch/sh/kernel/setup.c|  6 +-
 arch/sh/kernel/time.c |  3 +--
 arch/sh/mm/asids-debugfs.c|  5 +
 arch/sh/mm/cache.c|  4 
 14 files changed, 62 insertions(+), 48 deletions(-)
 create mode 100644 arch/sh/boot/dts/Makefile

Re: [musl] Broken vDSO on built kernel

[Alexander Monakov]

On Wed, 8 Jun 2016, fREW Schmidt wrote:
> I was debugging an issue I ran into (
> https://github.com/docker/docker/issues/23378) and after chatting with the
> folks in #musl and we triaged it down to a broken vDSO (tested by running
> `strace date` and seeing a clock_gettime call.)

To provide a bit more detail, we've found that the vdso mappend into the
application has no dynamic symbols; Glibc ignores the vdso, so it continues to
work, but musl segfaults since the vdso is invalid.

I'm pasting below `readelf -aW` output on the vdso dumped on the affected
system (via 'fwrite((void*)getauxval(AT_SYSINFO_EHDR), 8192, 1, stdout)';
as you can see, there's no dynamic symbols and symbol hash tables.  It may
be a toolchain bug since there was no issue with 4.6 kernel (and reportedly
there were no significant vdso changes merged into 4.7 -- the issue is seen
on Ubuntu's 4.7rc2).

Alexander

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x600
  Start of program headers:  64 (bytes into file)
  Start of section headers:  2976 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 4
  Size of section headers:   64 (bytes)
  Number of section headers: 10
  Section header string table index: 9

Section Headers:
  [Nr] Name  TypeAddress  OffSize   ES Flg 
Lk Inf Al
  [ 0]   NULL 00 00 00  
0   0  0
  [ 1] .rodata   PROGBITS0120 000120 000340 00  WA  
0   0  1
  [ 2] .note NOTE0460 000460 3c 00   A  
0   0  4
  [ 3] .eh_frame_hdr PROGBITS049c 00049c 3c 00   A  
0   0  4
  [ 4] .eh_frame PROGBITS04d8 0004d8 000120 00   A  
0   0  8
  [ 5] .text PROGBITS0600 000600 0004c9 00  AX  
0   0 16
  [ 6] .altinstructions  PROGBITS0ac9 000ac9 34 00   A  
0   0  1
  [ 7] .altinstr_replacement PROGBITS0afd 000afd 0c 00  
AX  0   0  1
  [ 8] .comment  PROGBITS 000b09 2e 01  MS  
0   0  1
  [ 9] .shstrtab STRTAB   000b37 67 00  
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz 
  Flg Align
  LOAD   0x00 0x 0x 0x000b09 
0x000b09 R E 0x1000
  DYNAMIC0x00 0x 0x 0x00 
0x00 R   0x8
  NOTE   0x000460 0x0460 0x0460 0x3c 
0x3c R   0x4
  GNU_EH_FRAME   0x00049c 0x049c 0x049c 0x3c 
0x3c R   0x4

 Section to Segment mapping:
  Segment Sections...
   00 .rodata .note .eh_frame_hdr .eh_frame .text .altinstructions 
.altinstr_replacement 
   01 
   02 .note 
   03 .eh_frame_hdr 

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type Advanced Micro Devices X86-64 
is not currently supported.

No version information found in this file.

Displaying notes found at file offset 0x0460 with length 0x003c:
  Owner Data size   Description
  Linux0x0004   Unknown note type: (0x)
  GNU  0x0014   NT_GNU_BUILD_ID (unique build ID 
bitstring)
Build ID: 496e9db3f494533ffaaf39737eb1023938861349

Re: [PATCH] nfit: add Microsoft NVDIMM DSM command set to white list

[Stuart Hayes]

On 5/26/2016 11:38 AM, Stuart Hayes wrote:

Add the Microsoft _DSM command set to the white list of NVDIMM command sets.

This command set is documented at 
https://msdn.microsoft.com/library/windows/hardware/mt604741.

Signed-off-by: Stuart Hayes 
---
 drivers/acpi/nfit.c| 9 ++---
 drivers/acpi/nfit.h| 4 
 include/uapi/linux/ndctl.h | 1 +
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
index 2215fc8..48fc575 100644
--- a/drivers/acpi/nfit.c
+++ b/drivers/acpi/nfit.c
@@ -1130,11 +1130,11 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc 
*acpi_desc,
 }

 /*
- * Until standardization materializes we need to consider up to 3
+ * Until standardization materializes we need to consider several
  * different command sets.  Note, that checking for function0 (bit0)
  * tells us if any commands are reachable through this uuid.
  */
-for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_HPE2; i++)
+for (i = NVDIMM_FAMILY_INTEL; i <= NVDIMM_FAMILY_MSFT; i++)
 if (acpi_check_dsm(adev_dimm->handle, to_nfit_uuid(i), 1, 1))
 break;

@@ -1150,7 +1150,9 @@ static int acpi_nfit_add_dimm(struct acpi_nfit_desc 
*acpi_desc,
 dsm_mask = 0x1fe;
 if (disable_vendor_specific)
 dsm_mask &= ~(1 << 8);
-} else {
+} else if (nfit_mem->family == NVDIMM_FAMILY_MSFT)
+dsm_mask = 0x;
+else {
 dev_err(dev, "unknown dimm command family\n");
 nfit_mem->family = -1;
 return force_enable_dimms ? 0 : -ENODEV;
@@ -2692,6 +2694,7 @@ static __init int nfit_init(void)
 acpi_str_to_uuid(UUID_NFIT_DIMM, nfit_uuid[NFIT_DEV_DIMM]);
 acpi_str_to_uuid(UUID_NFIT_DIMM_N_HPE1, nfit_uuid[NFIT_DEV_DIMM_N_HPE1]);
 acpi_str_to_uuid(UUID_NFIT_DIMM_N_HPE2, nfit_uuid[NFIT_DEV_DIMM_N_HPE2]);
+acpi_str_to_uuid(UUID_NFIT_DIMM_N_MSFT, nfit_uuid[NFIT_DEV_DIMM_N_MSFT]);

 nfit_wq = create_singlethread_workqueue("nfit");
 if (!nfit_wq)
diff --git a/drivers/acpi/nfit.h b/drivers/acpi/nfit.h
index 11cb383..f06fa91 100644
--- a/drivers/acpi/nfit.h
+++ b/drivers/acpi/nfit.h
@@ -31,6 +31,9 @@
 #define UUID_NFIT_DIMM_N_HPE1 "9002c334-acf3-4c0e-9642-a235f0d53bc6"
 #define UUID_NFIT_DIMM_N_HPE2 "5008664b-b758-41a0-a03c-27c2f2d04f7e"

+/* https://msdn.microsoft.com/library/windows/hardware/mt604741 */
+#define UUID_NFIT_DIMM_N_MSFT "1ee68b36-d4bd-4a1a-9a16-4f8e53d46e05"
+
 #define ACPI_NFIT_MEM_FAILED_MASK (ACPI_NFIT_MEM_SAVE_FAILED \
 | ACPI_NFIT_MEM_RESTORE_FAILED | ACPI_NFIT_MEM_FLUSH_FAILED \
 | ACPI_NFIT_MEM_NOT_ARMED)
@@ -40,6 +43,7 @@ enum nfit_uuids {
 NFIT_DEV_DIMM = NVDIMM_FAMILY_INTEL,
 NFIT_DEV_DIMM_N_HPE1 = NVDIMM_FAMILY_HPE1,
 NFIT_DEV_DIMM_N_HPE2 = NVDIMM_FAMILY_HPE2,
+NFIT_DEV_DIMM_N_MSFT = NVDIMM_FAMILY_MSFT,
 NFIT_SPA_VOLATILE,
 NFIT_SPA_PM,
 NFIT_SPA_DCR,
diff --git a/include/uapi/linux/ndctl.h b/include/uapi/linux/ndctl.h
index 309915f..ba5a8c7 100644
--- a/include/uapi/linux/ndctl.h
+++ b/include/uapi/linux/ndctl.h
@@ -298,6 +298,7 @@ struct nd_cmd_pkg {
 #define NVDIMM_FAMILY_INTEL 0
 #define NVDIMM_FAMILY_HPE1 1
 #define NVDIMM_FAMILY_HPE2 2
+#define NVDIMM_FAMILY_MSFT 3

 #define ND_IOCTL_CALL_IOWR(ND_IOCTL, ND_CMD_CALL,\
 struct nd_cmd_pkg)


Is there a problem with this patch?  I never saw any responses, and wasn't sure 
if maybe I goofed.  Thanks!

Re: [PATCH v4 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

[Boris Brezillon]

On Tue, 7 Jun 2016 15:11:53 +0800
Songjun Wu  wrote:

> DT binding documentation for ISC driver.
> 
> Signed-off-by: Songjun Wu 
> ---
> 
> Changes in v4:
> - Remove the isc clock nodes.
> 
> Changes in v3:
> - Remove the 'atmel,sensor-preferred'.
> - Modify the isc clock node according to the Rob's remarks.
> 
> Changes in v2:
> - Remove the unit address of the endpoint.
> - Add the unit address to the clock node.
> - Avoid using underscores in node names.
> - Drop the "0x" in the unit address of the i2c node.
> - Modify the description of 'atmel,sensor-preferred'.
> - Add the description for the ISC internal clock.
> 
>  .../devicetree/bindings/media/atmel-isc.txt| 69 
> ++
>  1 file changed, 69 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt 
> b/Documentation/devicetree/bindings/media/atmel-isc.txt
> new file mode 100644
> index 000..3f83524
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
> @@ -0,0 +1,69 @@
> +Atmel Image Sensor Controller (ISC)
> +--
> +
> +Required properties for ISC:
> +- compatible
> + Must be "atmel,sama5d2-isc".
> +- reg
> + Physical base address and length of the registers set for the device.
> +- interrupts
> + Should contain IRQ line for the ISC.
> +- clocks
> + List of clock specifiers, corresponding to entries in
> + the clock-names property;
> + Please refer to clock-bindings.txt.
> +- clock-names
> + Required elements: "hclock".
> +- #clock-cells
> + Should be 0.
> +- clock-output-names
> + Should contain the name of the clock driving the sensor master clock.
> +- pinctrl-names, pinctrl-0
> + Please refer to pinctrl-bindings.txt.
> +
> +
> +ISC supports a single port node with parallel bus. It should contain one
> +'port' child node with child 'endpoint' node. Please refer to the bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +isc: isc@f0008000 {
> + compatible = "atmel,sama5d2-isc";
> + reg = <0xf0008000 0x4000>;
> + interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
> + clocks = <_clk>, <>, <_gclk>;
> + clock-names = "hclock";

You have 3 clocks here and only one name. Are you sure this example is
actually working?

> + #clock-cells = <0>;
> + clock-output-names = "isc-mck";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + isc_0: endpoint {
> + remote-endpoint = <_0>;
> + hsync-active = <1>;
> + vsync-active = <0>;
> + pclk-sample = <1>;
> + };
> + };
> +
> +
> +};
> +
> +i2c1: i2c@fc028000 {
> + ov7740: camera@21 {
> + compatible = "ovti,ov7740";
> + reg = <0x21>;
> +
> + clocks = <>;
> + clock-names = "xvclk";
> + assigned-clocks = <>;
> + assigned-clock-rates = <2400>;
> +
> + port {
> + ov7740_0: endpoint {
> + remote-endpoint = <_0>;
> + };
> + };
> +};



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[v3 PATCH] arm64: kasan: instrument user memory access API

[Yang Shi]

The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef
("x86/kasan: instrument user memory access API") added KASAN instrument to
x86 user memory access API, so added such instrument to ARM64 too.

Define __copy_to/from_user in C in order to add kasan_check_read/write call,
rename assembly implementation to __arch_copy_to/from_user.

Tested by test_kasan module.

Acked-by: Andrey Ryabinin 
Reviewed-by: Mark Rutland 
Tested-by: Mark Rutland 
Signed-off-by: Yang Shi 
---
v3:
 Moved linux/kasan-checks.h before the other includes to keep them ordered
 alphabetically as suggested by Mark.
 Added Acked-by from Andrey Ryabinin and Reviewed-by/Tested-by from Mark.
v2:
 Adopted the comment from Andrey and Mark to add kasan_check_read/write into
 __copy_to/from_user.

 arch/arm64/include/asm/uaccess.h | 25 +
 arch/arm64/kernel/arm64ksyms.c   |  4 ++--
 arch/arm64/lib/copy_from_user.S  |  4 ++--
 arch/arm64/lib/copy_to_user.S|  4 ++--
 4 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 0685d74..672d367 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -21,6 +21,7 @@
 /*
  * User space memory access functions
  */
+#include 
 #include 
 #include 
 
@@ -269,15 +270,29 @@ do {  
\
-EFAULT;\
 })
 
-extern unsigned long __must_check __copy_from_user(void *to, const void __user 
*from, unsigned long n);
-extern unsigned long __must_check __copy_to_user(void __user *to, const void 
*from, unsigned long n);
+extern unsigned long __must_check __arch_copy_from_user(void *to, const void 
__user *from, unsigned long n);
+extern unsigned long __must_check __arch_copy_to_user(void __user *to, const 
void *from, unsigned long n);
 extern unsigned long __must_check __copy_in_user(void __user *to, const void 
__user *from, unsigned long n);
 extern unsigned long __must_check __clear_user(void __user *addr, unsigned 
long n);
 
+static inline unsigned long __must_check __copy_from_user(void *to, const void 
__user *from, unsigned long n)
+{
+   kasan_check_write(to, n);
+   return  __arch_copy_from_user(to, from, n);
+}
+
+static inline unsigned long __must_check __copy_to_user(void __user *to, const 
void *from, unsigned long n)
+{
+   kasan_check_read(from, n);
+   return  __arch_copy_to_user(to, from, n);
+}
+
 static inline unsigned long __must_check copy_from_user(void *to, const void 
__user *from, unsigned long n)
 {
+   kasan_check_write(to, n);
+
if (access_ok(VERIFY_READ, from, n))
-   n = __copy_from_user(to, from, n);
+   n = __arch_copy_from_user(to, from, n);
else /* security hole - plug it */
memset(to, 0, n);
return n;
@@ -285,8 +300,10 @@ static inline unsigned long __must_check 
copy_from_user(void *to, const void __u
 
 static inline unsigned long __must_check copy_to_user(void __user *to, const 
void *from, unsigned long n)
 {
+   kasan_check_read(from, n);
+
if (access_ok(VERIFY_WRITE, to, n))
-   n = __copy_to_user(to, from, n);
+   n = __arch_copy_to_user(to, from, n);
return n;
 }
 
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index 678f30b0..2dc4440 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -34,8 +34,8 @@ EXPORT_SYMBOL(copy_page);
 EXPORT_SYMBOL(clear_page);
 
/* user mem (segment) */
-EXPORT_SYMBOL(__copy_from_user);
-EXPORT_SYMBOL(__copy_to_user);
+EXPORT_SYMBOL(__arch_copy_from_user);
+EXPORT_SYMBOL(__arch_copy_to_user);
 EXPORT_SYMBOL(__clear_user);
 EXPORT_SYMBOL(__copy_in_user);
 
diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 17e8306..0b90497 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -66,7 +66,7 @@
.endm
 
 end.reqx5
-ENTRY(__copy_from_user)
+ENTRY(__arch_copy_from_user)
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
CONFIG_ARM64_PAN)
add end, x0, x2
@@ -75,7 +75,7 @@ ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), 
ARM64_ALT_PAN_NOT_UAO, \
CONFIG_ARM64_PAN)
mov x0, #0  // Nothing to copy
ret
-ENDPROC(__copy_from_user)
+ENDPROC(__arch_copy_from_user)
 
.section .fixup,"ax"
.align  2
diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
index 21faae6..7a7efe2 100644
--- a/arch/arm64/lib/copy_to_user.S
+++ b/arch/arm64/lib/copy_to_user.S
@@ -65,7 +65,7 @@
.endm
 
 end.reqx5
-ENTRY(__copy_to_user)
+ENTRY(__arch_copy_to_user)
 ALTERNATIVE("nop", 

Re: [v1,4/4] drm/rockchip: cdn-dp: add cdn DP support for rk3399

[Guenter Roeck]

On Fri, Jun 03, 2016 at 11:15:11PM +0800, Chris Zhong wrote:
> Add support for cdn DP controller which is embedded in the rk3399
> SoCs. The DP is compliant with DisplayPort Specification,
> Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
> There is a uCPU in DP controller, it need a firmware to work,
> please put the firmware file to /lib/firmware/cdn/dptx.bin. The
> uCPU in charge of aux communication and link training, the host use
> mailbox to communicate with the ucpu.
> The dclk pin_pol of vop must not be invert for DP.
> 
> Signed-off-by: Chris Zhong 

Disclaimer: I am not familiar with drm code, so this is a very generic review,
and it may miss some (or lots of) problems.

> ---
> 
> Changes in v1:
> - use extcon API
> - use hdmi-codec for the DP Asoc
> - do not initialize the "ret"
> - printk a err log when drm_of_encoder_active_endpoint_id
> - modify the dclk pin_pol to a single line
> 
>  drivers/gpu/drm/rockchip/Kconfig|   9 +
>  drivers/gpu/drm/rockchip/Makefile   |   1 +
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  | 709 +++
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  | 110 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   | 721 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   | 404 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   2 +
>  9 files changed, 1963 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index d30bdc3..20da9a8 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -25,6 +25,15 @@ config ROCKCHIP_ANALOGIX_DP
> for the Analogix Core DP driver. If you want to enable DP
> on RK3288 based SoC, you should selet this option.
>  
> +config ROCKCHIP_CDN_DP
> +tristate "Rockchip cdn DP"
> +depends on DRM_ROCKCHIP
> +help
> +   This selects support for Rockchip SoC specific extensions
> +   for the cdn Dp driver. If you want to enable Dp on
> +   RK3399 based SoC, you should selet this
> +   option.
> +
>  config ROCKCHIP_DW_HDMI
>  tristate "Rockchip specific extensions for Synopsys DW HDMI"
>  depends on DRM_ROCKCHIP
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index 05d0713..abdecd5 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>  
>  obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> 
> Please make sure that this builds with CONFIG_ROCKCHIP_CDN_DP=m.
> Hint: Probably it won't build, because it will generate two modules,
> and the global functions are not exported.
> 
>  obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> new file mode 100644
> index 000..d51e65a
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -0,0 +1,709 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 

Alphabetic order

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include "rockchip_drm_vop.h"
> +#include "cdn-dp-reg.h"
> +#include "cdn-dp-core.h"
> +

Alphabetic order

> +#define connector_to_dp(c) \
> + container_of(c, struct cdn_dp_device, connector)
> +
> +#define encoder_to_dp(c) \
> + container_of(c, struct cdn_dp_device, encoder)
> +
> +/* dp grf register offset */
> +#define DP_VOP_SEL   0x6224
> +#define DP_SEL_VOP_LIT 

Re: [PATCH v4 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

[Rob Herring]

On Tue, Jun 07, 2016 at 05:15:53PM +0800, Frank Wang wrote:
> Signed-off-by: Frank Wang 
> ---
> 
> Changes in v4:
>  - Used 'phy-supply' instead of 'vbus_*-supply'.
> 
> Changes in v3:
>  - Added 'clocks' and 'clock-names' optional properties.
>  - Specified 'otg-port' and 'host-port' as the sub-node name.
> 
> Changes in v2:
>  - Changed vbus_host optional property from gpio to regulator.
>  - Specified vbus_otg-supply optional property.
>  - Specified otg_id and otg_bvalid property.
> 
>  .../bindings/phy/phy-rockchip-inno-usb2.txt|   62 
> 
>  1 file changed, 62 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt

Acked-by: Rob Herring 

Re: [PATCH V4 1/2] thermal: max77620: Add DT binding doc for thermal driver

[Rob Herring]

On Tue, Jun 07, 2016 at 04:22:33PM +0530, Laxman Dewangan wrote:
> Maxim Semiconductor MAX77620 supports alarm interrupts when
> its die temperature crosses 120C and 140C. These threshold
> temperatures are not configurable.
> 
> Add DT binding document to details out the DT property related
> to MAX77620 thermal functionality.
> 
> Signed-off-by: Laxman Dewangan 
> 
> ---
> Changes from V3:
> Added example node for the critical trips also as critical.
> Also change the warning as "hot" type.
> 
>  .../bindings/thermal/thermal-max77620.txt  | 70 
> ++
>  1 file changed, 70 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/thermal-max77620.txt

Acked-by: Rob Herring 

Re: [PATCH 2/4] dell-wmi: Sort WMI event codes and update comments

[Darren Hart]

On Wed, Jun 08, 2016 at 09:57:26PM +0200, Pali Rohár wrote:
> On Wednesday 08 June 2016 21:48:24 Darren Hart wrote:
> > On Wed, Jun 08, 2016 at 12:03:24AM +0200, Pali Rohár wrote:
> > > On Thursday 02 June 2016 12:41:42 Michał Kępień wrote:
> > > > > Signed-off-by: Pali Rohár 
> > > > 
> > > > My guess is that Darren won't let you off without at least a
> > > > short commit message.
> > > 
> > > I have no idea what else to write. I think that description is
> > > enough.
> > 
> > There is always something. For example, why? See
> > Documentation/SubmittingPatches section "14) The canonical patch
> > format" for an explanation.
> > 
> > "Traceability" of changes is important. If it's worth preparing the
> > patch, it's worth documenting why.
> 
> In my opinion current description is enough and cover everything what 
> this patch is doing. I think it is clear from my description what this 
> patch is doing and so it is documented.
> 
> But if it is not clear and something is missing, let me know or show 
> what is wrong and how you change it... It is just my assumption that 
> "Sort WMI event codes and update comments" is clear...

The patch summary accurately states what it does. It does not explain why it
does it, or why it is necessary. I understand this is a trivial change, but also
understand that both maintainers and people doing maintenance and regression
analysis will appreciate understanding the motivation and intent of the patch,
in addition to the content of the patch.

>From the maintainer perspective, whether we have 20 or 200 patches to review, 
>we
will naturally merge the ones that require the least effort first. This
maximizes our efficiency and benefits the most people with what time we have
available. For many of us, this is our nights and weekends (guessing that's the
case for you as well). It is in the submitter's best interest to take the time
document the why, what, and how of each patch in a way that minimizes the effort
on the part of the maintainer to decide if the patch should be merged. It is
also a matter of scale, if every patch conforms to these guidelines, the
workflow is much more efficient.

In this case, I don't know why you decided to sort the event codes or update the
comments. I assume the comments were wrong before, but maybe something changed.
Do you care about alphabetically order or optimizing the switch statements? Is
it purely for legibility? Etc.

If that isn't sufficient, then just do it out of self-interest, because I will
not send patches to Linus that do not provide both a summary and a description
in the commit which meet the guidelines of section 14 referenced above.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

Re: [tip:perf/core] perf/x86/intel: Use Intel family macros for core perf events

[Vince Weaver]

On Wed, 8 Jun 2016, Borislav Petkov wrote:

> On Wed, Jun 08, 2016 at 06:25:29PM +0200, Ingo Molnar wrote:
> >  model string: IvyBridge_X
> > 
> > ... or something like that. The string could even be auto-generated from 
> > the list 
> > in intel-family.h?
> 
> Yap, that sounds cool too. And then we should issue that too during boot:
> 
> [0.542398] smpboot: CPU0: AMD FX(tm)-8350 Eight-Core Processor (family: 
> 0x15, model: 0x2, stepping: 0x0; Piledriver)
> 
> so that we don't need to ask for dmesg *and* /proc/cpuinfo.
> 
> Hohumm, this should be very useful.

However you do it, you want to make the strings match intel-family.h for 
maximum grepability.

It's also unclear what internal names matter.  For example is AMD 15h/60h
"Carrizo" or "Excavator" or both?

I just spent the afternoon making a huge RAPL/APM kernel support matrix 
for the PAPI people.

Lots of fun since
 arch/x86/events/intel/rapl.c
and
 drivers/powercap/intel_rapl.c

support widely different subsets of Intel hardware, and one uses decimal 
while one uses hex for the model numbers.  So I reluctantly admit unifying 
this all somehow would be nice.

(why we need two different interfaces for RAPL is another thing, not to 
mention the fact that powercap you can read the values as a normal user 
but with perf you need to be root to read the exact same thing).

Vince

Re: [PATCH] intel_menlow: prevent NULL pointer dereference

[Darren Hart]

On Wed, May 25, 2016 at 04:20:11PM +0200, Vincent Stehlé wrote:
> The function acpi_driver_data() will dereference its parameter; make sure
> to check for NULL pointer before we call it.

+Rafael

Under what circumstances can the .remove op be called with a NULL struct
acpi_device * as a parameter? From what I can see, most acpi_* calls accpeting
an acpi_device rely on it not being null, and they are regularly called from
driver remove functions.

Did you observe an explicit failure or can you describe a call path where this
can occur?


> 
> Signed-off-by: Vincent Stehlé 
> Cc: Sujith Thomas 
> Cc: Darren Hart 
> Cc: Zhang Rui 
> Cc: Len Brown 
> ---
>  drivers/platform/x86/intel_menlow.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel_menlow.c 
> b/drivers/platform/x86/intel_menlow.c
> index 0a919d8..185a1bd 100644
> --- a/drivers/platform/x86/intel_menlow.c
> +++ b/drivers/platform/x86/intel_menlow.c
> @@ -196,9 +196,13 @@ static int intel_menlow_memory_add(struct acpi_device 
> *device)
>  
>  static int intel_menlow_memory_remove(struct acpi_device *device)
>  {
> - struct thermal_cooling_device *cdev = acpi_driver_data(device);
> + struct thermal_cooling_device *cdev;
> +
> + if (!device)
> + return -EINVAL;
>  
> - if (!device || !cdev)
> + cdev = acpi_driver_data(device);
> + if (!cdev)
>   return -EINVAL;
>  
>   sysfs_remove_link(>dev.kobj, "thermal_cooling");
> -- 
> 2.8.1
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

Re: [PATCH] Smack: ignore null signal in smack_task_kill

[Casey Schaufler]

On 4/4/2016 2:14 AM, Rafal Krypa wrote:
> Kill with signal number 0 is commonly used for checking PID existence.
> Smack treated such cases like any other kills, although no signal is
> actually delivered when sig == 0.
>
> Checking permissions when sig == 0 didn't prevent an unprivileged caller
> from learning whether PID exists or not. When it existed, kernel returned
> EPERM, when it didn't - ESRCH. The only effect of policy check in such
> case is noise in audit logs.
>
> This change lets Smack silently ignore kill() invocations with sig == 0.
>
> Signed-off-by: Rafal Krypa 

Acked-by: Casey Schaufler 

Applied to git://github.com/cschaufler/smack-next.git#smack-for-4.8

> ---
>  security/smack/smack_lsm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 11f7901..3d9bbed 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -2227,6 +2227,9 @@ static int smack_task_kill(struct task_struct *p, 
> struct siginfo *info,
>   struct smack_known *tkp = smk_of_task_struct(p);
>   int rc;
>  
> + if (!sig)
> + return 0; /* null signal; existence test */
> +
>   smk_ad_init(, __func__, LSM_AUDIT_DATA_TASK);
>   smk_ad_setfield_u_tsk(, p);
>   /*

Re: [PATCH v2 2/5] mfd: add Ricoh RN5T567 PMIC support

[Rob Herring]

On Tue, Jun 07, 2016 at 06:04:26PM -0700, Stefan Agner wrote:
> The Ricoh RN5T567 is from the same family as the Ricoh RN5T618 is,
> the differences are:
> 
> + DCDC4
> + Slightly different output voltage/currents
> + 32kHz Output
> - ADC/Charger capabilities
> 
> Reviewed-by: Marcel Ziswiler 
> Signed-off-by: Stefan Agner 
> ---
>  Documentation/devicetree/bindings/mfd/rn5t618.txt | 19 ++---
>  drivers/mfd/Kconfig   |  7 +++---
>  drivers/mfd/rn5t618.c | 26 
> +--
>  include/linux/mfd/rn5t618.h   | 12 +++
>  4 files changed, 46 insertions(+), 18 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt 
> b/Documentation/devicetree/bindings/mfd/rn5t618.txt
> index 937785a..5b493ed 100644
> --- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
> +++ b/Documentation/devicetree/bindings/mfd/rn5t618.txt
> @@ -1,18 +1,21 @@
> -* Ricoh RN5T618 PMIC
> +* Ricoh RN5T567/RN5T618 PMIC
>  
> -Ricoh RN5T618 is a power management IC which integrates 3 step-down
> -DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
> -fuel gauge, ADC, GPIOs and a watchdog timer. It can be controlled
> -through a I2C interface.
> +Ricoh RN5T567/RN5T618 is a power management IC family which integrates
> +3 to 5 step-down DCDC converters, 7 low-dropout regulators, GPIOs and

I count 4?

Otherwise, for the binding:

Acked-by: Rob Herring 

Re: [PATCH] Fix NFS option parsing bit-rot.

[Trond Myklebust]

On 6/8/16, 15:41, "Rob Landley"  wrote:
>So addr= is at _best_ redundant. You MUST supply host:/ always,
>the current code just wasn't using it.

That’s because you just happen to be supplying an IP address instead of a 
hostname. The kernel has no DNS resolving functionality. It cannot resolve 
hostnames into IP addresses without help either by the caller or by means of an 
upcall. That is why ‘addr=’ has been a mandatory parameter ever since we 
introduced the text based parser.

Now we could, theoretically, have the client call nfs_dns_resolve_name() on the 
hostname to resolve it. However that breaks when you have net namespaces and 
such, since the kernel’s dns_query() call is not container aware.

Trond

Re: [PATCH v2 1/2] Documentation: bindings: add dt doc for Rockchip PCIe controller

[Rob Herring]

On Wed, Jun 08, 2016 at 04:05:17PM +0800, Shawn Lin wrote:
> This patch adds a binding that describes the Rockchip PCIe controller
> found on Rockchip SoCs PCIe interface.
> 
> Signed-off-by: Shawn Lin 
> 
> ---
> 
> Changes in v2:
> - fix lots clk/reset stuff suggested by Heiko
> - remove msi-parent and add msi-map suggested by Marc
> - drop phy related stuff
> - some others minor fixes
> 
>  .../devicetree/bindings/pci/rockchip-pcie.txt  | 86 
> ++
>  1 file changed, 86 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt 
> b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> new file mode 100644
> index 000..eb92e29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt
> @@ -0,0 +1,86 @@
> +* Rockchip AXI PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> + interrupt source. The value must be 1.
> +- compatible: Should contain "rockchip,rk3399-pcie"
> +- reg: Two register ranges as listed in the reg-names property
> +- reg-names: Must include the following names
> + - "axi-base"
> + - "apb-base"
> +- clocks: Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> +- clock-names: Must include the following entries:
> + - "aclk"
> + - "aclk-perf"
> + - "hclk"
> + - "pm"
> +- phys: From PHY bindings: Phandle for the Generic PHY for PCIe.
> +- phy-names:  MUST be "pcie-phy".

phy-names is kind of pointless for 1 phy.

> +- interrupts: Three interrupt entries must be specified.
> +- interrupt-names: Must include the following names
> + - "sys"
> + - "legacy"
> + - "client"
> +- resets: Must contain five entries for each entry in reset-names.
> +See ../reset/reset.txt for details.
> +- reset-names: Must include the following names
> + - "core"
> + - "mgmt"
> + - "mgmt-sticky"
> + - "pipe"
> +- pinctrl-names : The pin control state names
> +- pinctrl-0: The "default" pinctrl state
> +- interrupt-map-mask and interrupt-map: standard PCI properties
> +- interrupt-controller: identifies the node as an interrupt controller
> +
> +Optional Property:
> +- ep-gpios: contain the entry for pre-reset gpio
> +- num-lanes: number of lanes to use
> +- vpcie3v3-supply: The phandle to the 3.3v regulator to use for pcie. If this
> +  is specified we'll defer probe until we can find this regulator.
> +- vpcie1v8-supply: The phandle to the 1.8v regulator to use for pcie. If this
> +  is specified we'll defer probe until we can find this regulator.
> +- vpcie0v9-supply: The phandle to the 0.9v regulator to use for pcie. If this
> +  is specified we'll defer probe until we can find this regulator.
> +
> +Example:
> +
> +pcie0: pcie@f800 {
> + compatible = "rockchip,rk3399-pcie";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + clocks = < ACLK_PCIE>, < ACLK_PERF_PCIE>,
> +  < PCLK_PCIE>;
> + clock-names = "aclk", "aclk-perf",
> +   "hclk";
> + bus-range = <0x0 0x1>;
> + interrupts = ,  IRQ_TYPE_LEVEL_HIGH>,
> +  ;
> + interrupt-names: "sys", "legacy", "client";
> + assigned-clocks = < SCLK_PCIEPHY_REF>;
> + assigned-clock-parents = < SCLK_PCIEPHY_REF100M>;
> + assigned-clock-rates = <1>;
> + ep-gpios = < 13 GPIO_ACTIVE_HIGH>;
> + ranges = < 0x8200 0 0xfa00 0x0 0xfa00 0 0x60
> +0x8100 0 0xfa60 0x0 0xfa60 0 0x10 >;

No 64-bit memory space?

> + num-lanes = <4>;
> + reg = < 0x0 0xf800 0x0 0x200 >, < 0x0 0xfd00 0x0 0x100 
> >;
> + reg-name = "axi-base", "apb-base";
> + resets = < SRST_PCIEPHY>, < SRST_PCIE_CORE>, < 
> SRST_PCIE_MGMT>,
> +  < SRST_PCIE_MGMT_STICKY>, < SRST_PCIE_PIPE>;
> + reset-names = "core", "mgmt", "mgmt-sticky", "pipe";
> + phys = <_phy>;
> + phy-names = "pcie-phy";
> + pinctrl-names = "default";
> + pinctrl-0 = <_clkreq>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1  1>,
> + <0 0 0 2  2>,
> + <0 0 0 3  3>,
> + <0 0 0 4  4>;
> +};
> -- 
> 2.3.7
> 
> 

Re: [PATCH 06/11] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock

[Doug Anderson]

Rob,

On Wed, Jun 8, 2016 at 1:19 PM, Rob Herring  wrote:
> On Tue, Jun 07, 2016 at 03:44:39PM -0700, Douglas Anderson wrote:
>> Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work
>> with arasan,sdhci-5.1) need to know the card clock in order to function
>> properly.  Let's expose this clock using a standard device tree
>> mechanism so that the PHY can get access to and query the card clock.
>
> Need to know the clock freq or need the clock? The former doesn't need
> to be in DT.

The PHY needs to know the card clock frequency.  This clock clock
frequency is known nowhere else in the system except the SDHCI driver
since the SDHCI component takes its input clock and applies some
dividers to get the card clock.  In silicon, the SDHCI component and
the PHY are separate and there is a physical clock signal going from
the SDHCI component to the PHY component, so modeling this as a clock
in in the device tree seems sane, doesn't it?

-Doug

Re: [PATCH v3 20/20] dt-bindings: pwm: sti: Update DT bindings with recent changes

[Rob Herring]

On Wed, Jun 08, 2016 at 10:21:35AM +0100, Lee Jones wrote:
> We're renaming the 'st,pwm-num-chan' binding to 'st,pwm-num-devs' to
> be more inline with the naming conventions of the subsystem.  Where
> we used to treat each line as a channel, the PWM convention is to
> describe them as devices.

That's all linux implementation details and you are breaking 
compatibility.

> The second documentation adaption entails adding support for PWM
> capture devices.  A new clock is required as well as an IRQ line.
> We're also adding a new property similar to the one described
> above, but for capture channels.  Typically, there will be less
> capture channels than PWM-out, since all channels have the latter
> capability, but only some have capture support.

Humm, sounds like all of this should be implied from compatible strings.

> 
> Signed-off-by: Lee Jones 
> ---
>  Documentation/devicetree/bindings/pwm/pwm-st.txt | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-st.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-st.txt
> index 84d2fb8..b09f3a4 100644
> --- a/Documentation/devicetree/bindings/pwm/pwm-st.txt
> +++ b/Documentation/devicetree/bindings/pwm/pwm-st.txt
> @@ -13,13 +13,14 @@ Required parameters:
>  - pinctrl-0: List of phandles pointing to pin configuration 
> nodes
>   for PWM module.
>   For Pinctrl properties, please refer to [1].
> -- clock-names:   Set to "pwm".
> +- clock-names:   Valid entries are "pwm" and/or "capture".
>  - clocks:phandle of the clock used by the PWM module.
>   For Clk properties, please refer to [2].
> +- interrupts:IRQ for the Capture device
>  
>  Optional properties:
> -- st,pwm-num-chan:   Number of available channels. If not passed, the driver
> - will consider single channel by default.
> +- st,pwm-num-devs:   Number of available PWM channels.  Default is 0.
> +- st,capture-num-devs:   Number of available Capture channels.  Default 
> is 0.
>  
>  [1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>  [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
> @@ -37,5 +38,6 @@ pwm1: pwm@fe51 {
>_pwm1_chan3_default>;
>   clocks = <_sysin>;
>   clock-names = "pwm";
> - st,pwm-num-chan = <4>;
> + st,pwm-num-devs = <4>;
> + st,capture-num-devs = <2>;
>  };
> -- 
> 2.8.3
> 

[PATCH v4 11/29] staging: unisys: visorbus: remove periodic_work.h/.c

[David Kershner]

From: Tim Sell 

These files were made no-longer-necessary by recent commits.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/include/periodic_work.h  |  40 -
 drivers/staging/unisys/visorbus/Makefile|   1 -
 drivers/staging/unisys/visorbus/periodic_work.c | 204 
 drivers/staging/unisys/visorbus/visorchipset.c  |   1 -
 4 files changed, 246 deletions(-)
 delete mode 100644 drivers/staging/unisys/include/periodic_work.h
 delete mode 100644 drivers/staging/unisys/visorbus/periodic_work.c

diff --git a/drivers/staging/unisys/include/periodic_work.h 
b/drivers/staging/unisys/include/periodic_work.h
deleted file mode 100644
index 0b3335a..000
--- a/drivers/staging/unisys/include/periodic_work.h
+++ /dev/null
@@ -1,40 +0,0 @@
-/* periodic_work.h
- *
- * Copyright (C) 2010 - 2013 UNISYS CORPORATION
- * All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
- * NON INFRINGEMENT.  See the GNU General Public License for more
- * details.
- */
-
-#ifndef __PERIODIC_WORK_H__
-#define __PERIODIC_WORK_H__
-
-#include 
-#include 
-
-/* PERIODIC_WORK an opaque structure to users.
- * Fields are declared only in the implementation .c files.
- */
-struct periodic_work;
-
-struct periodic_work *
-visor_periodic_work_create(ulong jiffy_interval,
-  struct workqueue_struct *workqueue,
-  void (*workfunc)(void *),
-  void *workfuncarg,
-  const char *devnam);
-void visor_periodic_work_destroy(struct periodic_work *pw);
-bool visor_periodic_work_nextperiod(struct periodic_work *pw);
-bool visor_periodic_work_start(struct periodic_work *pw);
-bool visor_periodic_work_stop(struct periodic_work *pw);
-
-#endif
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/staging/unisys/visorbus/Makefile
index fc790e7..f3730d8 100644
--- a/drivers/staging/unisys/visorbus/Makefile
+++ b/drivers/staging/unisys/visorbus/Makefile
@@ -7,6 +7,5 @@ obj-$(CONFIG_UNISYS_VISORBUS)   += visorbus.o
 visorbus-y := visorbus_main.o
 visorbus-y += visorchannel.o
 visorbus-y += visorchipset.o
-visorbus-y += periodic_work.o
 
 ccflags-y += -Idrivers/staging/unisys/include
diff --git a/drivers/staging/unisys/visorbus/periodic_work.c 
b/drivers/staging/unisys/visorbus/periodic_work.c
deleted file mode 100644
index 00b1527..000
--- a/drivers/staging/unisys/visorbus/periodic_work.c
+++ /dev/null
@@ -1,204 +0,0 @@
-/* periodic_work.c
- *
- * Copyright (C) 2010 - 2015 UNISYS CORPORATION
- * All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
- * NON INFRINGEMENT.  See the GNU General Public License for more
- * details.
- */
-
-/*
- *  Helper functions to schedule periodic work in Linux kernel mode.
- */
-#include 
-
-#include "periodic_work.h"
-
-#define MYDRVNAME "periodic_work"
-
-struct periodic_work {
-   rwlock_t lock;
-   struct delayed_work work;
-   void (*workfunc)(void *);
-   void *workfuncarg;
-   bool is_scheduled;
-   bool want_to_stop;
-   ulong jiffy_interval;
-   struct workqueue_struct *workqueue;
-   const char *devnam;
-};
-
-static void periodic_work_func(struct work_struct *work)
-{
-   struct periodic_work *pw;
-
-   pw = container_of(work, struct periodic_work, work.work);
-   (*pw->workfunc)(pw->workfuncarg);
-}
-
-struct periodic_work
-*visor_periodic_work_create(ulong jiffy_interval,
-   struct workqueue_struct *workqueue,
-   void (*workfunc)(void *),
-   void *workfuncarg,
-   const char *devnam)
-{
-   struct periodic_work *pw;
-
-   pw = kzalloc(sizeof(*pw), GFP_KERNEL | __GFP_NORETRY);
-   if (!pw)
-   return NULL;
-
-   rwlock_init(>lock);
-   pw->jiffy_interval = jiffy_interval;
-   pw->workqueue = workqueue;
-   pw->workfunc = workfunc;
-   pw->workfuncarg = workfuncarg;
-   pw->devnam = devnam;
-   return pw;
-}
-EXPORT_SYMBOL_GPL(visor_periodic_work_create);
-

[PATCH v4 25/29] staging: unisys: visorbus: fix visorbus_private.h comments

[David Kershner]

From: Tim Sell 

This patch ONLY touches comment lines, i.e., NO executable code is
affected.

Comments were fixed in visorbus_private.h:
* Minor typos were corrected.
* Useless comments were removed.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/visorbus_private.h | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index a7b1d4f..3f6ad52 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -37,16 +37,11 @@ void device_destroy_response(struct visor_device *p, int 
response);
 void device_resume_response(struct visor_device *p, int response);
 void device_pause_response(struct visor_device *p, int response);
 
-/* visorbus init and exit functions */
 int visorbus_init(void);
 void visorbus_exit(void);
 
-/* Visorchannel access functions */
+/* visorchannel access functions */
 
-/* Note that for visorchannel_create()
- *  and  arguments may be 0 if we are a channel CLIENT.
- * In this case, the values can simply be read from the channel header.
- */
 struct visorchannel *visorchannel_create(u64 physaddr,
 unsigned long channel_bytes,
 gfp_t gfp, uuid_le guid);
-- 
1.9.1

[PATCH] proc_oom_score: remove tasklist_lock and pid_alive()

[Oleg Nesterov]

This was needed before to ensure that ->signal != 0 and do_each_thread()
is safe, see the commit b95c35e76b29b for details.

Today tsk->signal can't go away and for_each_thread(tsk) is always safe.

Signed-off-by: Oleg Nesterov 
---
 fs/proc/base.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index a11eb71..93e7754 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -579,11 +579,8 @@ static int proc_oom_score(struct seq_file *m, struct 
pid_namespace *ns,
unsigned long totalpages = totalram_pages + total_swap_pages;
unsigned long points = 0;
 
-   read_lock(_lock);
-   if (pid_alive(task))
-   points = oom_badness(task, NULL, NULL, totalpages) *
-   1000 / totalpages;
-   read_unlock(_lock);
+   points = oom_badness(task, NULL, NULL, totalpages) *
+   1000 / totalpages;
seq_printf(m, "%lu\n", points);
 
return 0;
-- 
2.5.0

Broken vDSO on built kernel

[fREW Schmidt]

Hello!

I was debugging an issue I ran into (
https://github.com/docker/docker/issues/23378) and after chatting with the
folks in #musl and we triaged it down to a broken vDSO (tested by running
`strace date` and seeing a clock_gettime call.)

The theory is that the toolchain was somehow subtly broken and made a
broken kernel, I think.

The built binaries in this case are from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc2-yakkety/

I am not a Kernel dev or anything, just following the issues.  Hope this
helps!

(sorry Andy and musl, resending as plaintext)

-- 
fREW Schmidt
http://blog.afoolishmanifesto.com

[PATCH v4 26/29] staging: unisys: Move vbushelper.h to visorbus directory

[David Kershner]

Only visorbus needs this header file so move it to visorbus
directory.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/{include => visorbus}/vbushelper.h | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename drivers/staging/unisys/{include => visorbus}/vbushelper.h (100%)

diff --git a/drivers/staging/unisys/include/vbushelper.h 
b/drivers/staging/unisys/visorbus/vbushelper.h
similarity index 100%
rename from drivers/staging/unisys/include/vbushelper.h
rename to drivers/staging/unisys/visorbus/vbushelper.h
-- 
1.9.1

Re: [PATCH v2 2/5] mfd: add Ricoh RN5T567 PMIC support

[Stefan Agner]

On 2016-06-08 13:22, Rob Herring wrote:
> On Tue, Jun 07, 2016 at 06:04:26PM -0700, Stefan Agner wrote:
>> The Ricoh RN5T567 is from the same family as the Ricoh RN5T618 is,
>> the differences are:
>>
>> + DCDC4
>> + Slightly different output voltage/currents
>> + 32kHz Output
>> - ADC/Charger capabilities
>>
>> Reviewed-by: Marcel Ziswiler 
>> Signed-off-by: Stefan Agner 
>> ---
>>  Documentation/devicetree/bindings/mfd/rn5t618.txt | 19 ++---
>>  drivers/mfd/Kconfig   |  7 +++---
>>  drivers/mfd/rn5t618.c | 26 
>> +--
>>  include/linux/mfd/rn5t618.h   | 12 +++
>>  4 files changed, 46 insertions(+), 18 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/rn5t618.txt 
>> b/Documentation/devicetree/bindings/mfd/rn5t618.txt
>> index 937785a..5b493ed 100644
>> --- a/Documentation/devicetree/bindings/mfd/rn5t618.txt
>> +++ b/Documentation/devicetree/bindings/mfd/rn5t618.txt
>> @@ -1,18 +1,21 @@
>> -* Ricoh RN5T618 PMIC
>> +* Ricoh RN5T567/RN5T618 PMIC
>>
>> -Ricoh RN5T618 is a power management IC which integrates 3 step-down
>> -DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
>> -fuel gauge, ADC, GPIOs and a watchdog timer. It can be controlled
>> -through a I2C interface.
>> +Ricoh RN5T567/RN5T618 is a power management IC family which integrates
>> +3 to 5 step-down DCDC converters, 7 low-dropout regulators, GPIOs and
> 
> I count 4?

There is actually a third PMIC in this family RC5T619 which has 5, that
is where the number comes from. But that PMIC also has 12 LDO's so the
numbers are a bit a mix and much right now...

If I have to amend something anyway, I will fix that. Otherwise I look
at it as a preparation for the one which adds RC5T619 support :-)

--
Stefan

Re: [PATCH] Fix NFS option parsing bit-rot.

[Rob Landley]

On 06/08/2016 03:35 PM, Trond Myklebust wrote:
> 
> 
> On 6/8/16, 15:41, "Rob Landley"  wrote:
>>So addr= is at _best_ redundant. You MUST supply host:/ always,
>>the current code just wasn't using it.
> 
> That’s because you just happen to be supplying an IP address instead of
> a hostname. The kernel has no DNS resolving functionality. It cannot
> resolve hostnames into IP addresses without help either by the caller or
> by means of an upcall. That is why ‘addr=’ has been a mandatory
> parameter ever since we introduced the text based parser.

Then why is host: mandatory in the dev name?

Rob

Re: [PATCH 7/7] ARM: dts: sun7i: Enable NAND on Wexler TAB7200

[Maxime Ripard]

Hi,

On Mon, Jun 06, 2016 at 01:24:24PM +0300, Aleksei Mamlin wrote:
> Enable the NFC and describe the NAND flash connected to this controller.
> 
> Signed-off-by: Aleksei Mamlin 
> ---
>  arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 41 
> ++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts 
> b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> index 2f6b21a..42aff91 100644
> --- a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> @@ -159,6 +159,47 @@
>   status = "okay";
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>, <_cs0_pins_a>, <_rb0_pins_a>;
> + status = "okay";
> +
> + nand@0 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + reg = <0>;
> + allwinner,rb = <0>;
> +
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + boot0@0 {
> + label = "boot0";
> + reg = /bits/ 64 <0x0 0x20>;
> + };
> +
> + boot0-rescue@20 {
> + label = "boot0-rescue";
> + reg = /bits/ 64 <0x20 0x20>;
> + };
> +
> + uboot@40 {
> + label = "uboot";
> + reg = /bits/ 64 <0x40 0x20>;
> + };
> +
> + uboot-rescue@60 {
> + label = "uboot-rescue";
> + reg = /bits/ 64 <0x60 0x20>;
> + };
> +
> + main@80 {
> + label = "main";
> + reg = /bits/ 64 <0x80 0xff80>;
> + };
> + };
> +};

This feels a bit premature. The two boards you're using have an MLC
NAND which is not supported yet. Until there's proper MLC support in
the kernel, I'm not sure we want to enable that for end-users when we
know that things will get wrong.

However, after discussing this with Boris, I appreciate that we don't
have any example available because of this policy for people that want
to opt-in anyway.

What we could do is to still mark the status as disabled in the DTS,
with a big fat warning as comment just before, so that it requires
user action, and that user will have been warned.

Would that work for you?
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 1/7] ARM: dts: sun4i: Add A10 NAND controller pin definitions

[Maxime Ripard]

Hi,

On Mon, Jun 06, 2016 at 01:24:18PM +0300, Aleksei Mamlin wrote:
> From: Boris Brezillon 
> 
> Define the NAND controller pin configs.
> 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Aleksei Mamlin 
> ---
>  arch/arm/boot/dts/sun4i-a10.dtsi | 80 
> 
>  1 file changed, 80 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi 
> b/arch/arm/boot/dts/sun4i-a10.dtsi
> index a9c3190..146a08db 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -1144,6 +1144,86 @@
>   allwinner,drive = ;
>   allwinner,pull = ;
>   };
> +
> + nand_pins_a: nand_base0@0 {
> + allwinner,pins = "PC0", "PC1", "PC2",
> + "PC5", "PC8", "PC9", "PC10",
> + "PC11", "PC12", "PC13", "PC14",
> + "PC15", "PC16";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_cs0_pins_a: nand_cs@0 {
> + allwinner,pins = "PC4";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_cs1_pins_a: nand_cs@1 {
> + allwinner,pins = "PC3";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_cs2_pins_a: nand_cs@2 {
> + allwinner,pins = "PC17";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_cs3_pins_a: nand_cs@3 {
> + allwinner,pins = "PC18";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_cs4_pins_a: nand_cs@4 {
> + allwinner,pins = "PC19";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_cs5_pins_a: nand_cs@5 {
> + allwinner,pins = "PC20";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_cs6_pins_a: nand_cs@6 {
> + allwinner,pins = "PC21";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_cs7_pins_a: nand_cs@7 {
> + allwinner,pins = "PC22";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_rb0_pins_a: nand_rb@0 {
> + allwinner,pins = "PC6";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
> +
> + nand_rb1_pins_a: nand_rb@1 {
> + allwinner,pins = "PC7";
> + allwinner,function = "nand0";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };

We usually enable only the pin groups that are actually used by some
board to avoid bloating the DT too much.

And the nodes should be sorted alphabetically.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH] staging: comedi: serial2002: bare unsigned and unneeded cast styling issues

[Chris Cesare]

checkpatch.pl reported two warnings: A bare "unsigned" and an
unnecessary cast. Fixed both.

Signed-off-by: Chris Cesare 
---
 drivers/staging/comedi/drivers/serial2002.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/serial2002.c 
b/drivers/staging/comedi/drivers/serial2002.c
index 7a1defc..d3c2743 100644
--- a/drivers/staging/comedi/drivers/serial2002.c
+++ b/drivers/staging/comedi/drivers/serial2002.c
@@ -95,7 +95,7 @@ struct serial_data {
 #define S2002_CFG_SIGN(x)  (((x) >> 13) & 0x1)
 #define S2002_CFG_BASE(x)  (((x) >> 14) & 0xf)
 
-static long serial2002_tty_ioctl(struct file *f, unsigned op,
+static long serial2002_tty_ioctl(struct file *f, unsigned int op,
 unsigned long param)
 {
if (f->f_op->unlocked_ioctl)
@@ -379,7 +379,8 @@ static int serial2002_setup_subdevice(struct 
comedi_subdevice *s,
range_table_list[chan] =
(const struct comedi_lrange *)[j];
}
-   maxdata_list[chan] = ((long long)1 << cfg[j].bits) - 1;
+   maxdata_list[chan] = (1 << cfg[j].bits) - 1;
+
chan++;
}
}
-- 
2.7.4

Re: [tip:x86/urgent] x86/quirks: Add early quirk to reset Apple AirPort card

[Lukas Wunner]

On Wed, Jun 08, 2016 at 11:56:14AM -0700, Yinghai Lu wrote:
> On Wed, Jun 8, 2016 at 7:23 AM, tip-bot for Lukas Wunner  
> wrote:
> > --- a/arch/x86/kernel/early-quirks.c
> > +++ b/arch/x86/kernel/early-quirks.c
> ...
> 
> Extend bus scan range part should be in separated patch?
> 
> and put apple_airport_reset() related in second patch.

I had considered that but decided against it as it would make things
a bit more complicated for stable maintainers.

Nevertheless I'll be happy to split in two if this is the consensus?
I'm not sure though if x86/urgent is a rebasing branch?


> > +
> > +   if ((type & 0x7f) == PCI_HEADER_TYPE_BRIDGE) {
> > +   sec = read_pci_config_byte(num, slot, func, 
> > PCI_SECONDARY_BUS);
> > +   early_pci_scan_bus(sec);
> 
> How do you know that sec is valid ?
> 
> How about on the system that have one bridge that still have sec num register 
> 0?
> 
> it will be get into dead loop.

Good point. I've just checked pci_scan_bridge() and it does verify that
and avoids recursing to a child bus if it's number is zero. It also
ensures that sec > num before recursing.

I can provide a follow-up patch to fix that, will wait a bit though to
see if there are further comments.


> > -void __init early_quirks(void)
> > +static void __init early_pci_scan_bus(int bus)
> >  {
> > int slot, func;
> >
> > -   if (!early_pci_allowed())
> > -   return;
> > -
> > /* Poor man's PCI discovery */
> > -   /* Only scan the root bus */
> > for (slot = 0; slot < 32; slot++)
> > for (func = 0; func < 8; func++) {
> > /* Only probe function 0 on single fn devices */
> > -   if (check_dev_quirk(0, slot, func))
> > +   if (check_dev_quirk(bus, slot, func))
> > break;
> > }
> >  }
> > +
> > +void __init early_quirks(void)
> > +{
> > +   if (!early_pci_allowed())
> > +   return;
> > +
> > +   early_pci_scan_bus(0);
> > +}
> 
> Would just revert to scan domain 0, bus 0 to 255.

The commit message of 8659c406ade3 sounds like this would lengthen
boot time noticeably, so I expected significant backlash had I just
gone back to this old algorithm.

Thanks,

Lukas

Re: [PATCH] mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB

[kbuild test robot]

Hi,

[auto build test WARNING on v4.7-rc2]
[cannot apply to next-20160608]
[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/Alexander-Potapenko/mm-kasan-switch-SLUB-to-stackdepot-enable-memory-quarantine-for-SLUB/20160609-024216
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   mm/kasan/kasan.c: In function 'kasan_cache_create':
>> mm/kasan/kasan.c:374:22: warning: unused variable 'orig_size' 
>> [-Wunused-variable]
 int redzone_adjust, orig_size = *size;
 ^
   mm/kasan/kasan.c: In function 'kasan_slab_free':
>> mm/kasan/kasan.c:561:4: warning: 'return' with no value, in function 
>> returning non-void [-Wreturn-type]
   return;
   ^~
   mm/kasan/kasan.c:547:6: note: declared here
bool kasan_slab_free(struct kmem_cache *cache, void *object)
 ^~~

vim +/orig_size +374 mm/kasan/kasan.c

   368  return rz;
   369  }
   370  
   371  void kasan_cache_create(struct kmem_cache *cache, size_t *size,
   372  unsigned long *flags)
   373  {
 > 374  int redzone_adjust, orig_size = *size;
   375  
   376  #ifdef CONFIG_SLAB
   377  /*
   378   * Make sure the adjusted size is still less than
   379   * KMALLOC_MAX_CACHE_SIZE, i.e. we don't use the page allocator.
   380   */
   381  
   382  if (*size > KMALLOC_MAX_CACHE_SIZE -
   383  sizeof(struct kasan_alloc_meta) -
   384  sizeof(struct kasan_free_meta))
   385  return;
   386  #endif
   387  *flags |= SLAB_KASAN;
   388  
   389  /* Add alloc meta. */
   390  cache->kasan_info.alloc_meta_offset = *size;
   391  *size += sizeof(struct kasan_alloc_meta);
   392  
   393  /* Add free meta. */
   394  if (cache->flags & SLAB_DESTROY_BY_RCU || cache->ctor ||
   395  cache->object_size < sizeof(struct kasan_free_meta)) {
   396  cache->kasan_info.free_meta_offset = *size;
   397  *size += sizeof(struct kasan_free_meta);
   398  } else {
   399  cache->kasan_info.free_meta_offset = 0;
   400  }
   401  redzone_adjust = optimal_redzone(cache->object_size) -
   402  (*size - cache->object_size);
   403  
   404  if (redzone_adjust > 0)
   405  *size += redzone_adjust;
   406  
   407  #ifdef CONFIG_SLAB
   408  *size = min(KMALLOC_MAX_CACHE_SIZE,
   409  max(*size,
   410  cache->object_size +
   411  optimal_redzone(cache->object_size)));
   412  /*
   413   * If the metadata doesn't fit, disable KASAN at all.
   414   */
   415  if (*size <= cache->kasan_info.alloc_meta_offset ||
   416  *size <= cache->kasan_info.free_meta_offset) {
   417  *flags &= ~SLAB_KASAN;
   418  *size = orig_size;
   419  cache->kasan_info.alloc_meta_offset = -1;
   420  cache->kasan_info.free_meta_offset = -1;
   421  }
   422  #else
   423  *size = max(*size,
   424  cache->object_size +
   425  optimal_redzone(cache->object_size));
   426  
   427  #endif
   428  }
   429  
   430  void kasan_cache_shrink(struct kmem_cache *cache)
   431  {
   432  quarantine_remove_cache(cache);
   433  }
   434  
   435  void kasan_cache_destroy(struct kmem_cache *cache)
   436  {
   437  quarantine_remove_cache(cache);
   438  }
   439  
   440  void kasan_poison_slab(struct page *page)
   441  {
   442  kasan_poison_shadow(page_address(page),
   443  PAGE_SIZE << compound_order(page),
   444  KASAN_KMALLOC_REDZONE);
   445  }
   446  
   447  void kasan_unpoison_object_data(struct kmem_cache *cache, void *object)
   448  {
   449  kasan_unpoison_shadow(object, cache->object_size);
   450  }
   451  
   452  void kasan_poison_object_data(struct kmem_cache *cache, void *object)
   453  {
   454  kasan_poison_shadow(object,
   455  round_up(cache->object_size, 
KASAN_SHADOW_SCALE_SIZE),
   456  KASAN_KMALLOC_REDZONE);
   457  if (cache->flags & SLAB_KASAN) {
   458  struct kasan_alloc_meta *alloc_info =
   459  get_alloc_info(cache, object);
   460  if (alloc_info)
   461

Re: [PATCH v2 2/2] Documentation: DT: cpsw: remove rx_descs property

[Rob Herring]

On Tue, Jun 07, 2016 at 04:59:36PM +0300, Ivan Khoronzhuk wrote:
> There is no reason to hold s/w dependent parameter in device tree.
> Even more, there is no reason in this parameter because davinici_cpdma
> driver splits pool of descriptors equally between tx and rx channels
> anyway.
> 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  Documentation/devicetree/bindings/net/cpsw.txt | 1 -
>  arch/arm/boot/dts/am33xx.dtsi  | 1 -
>  arch/arm/boot/dts/am4372.dtsi  | 1 -
>  arch/arm/boot/dts/dm814x.dtsi  | 1 -
>  arch/arm/boot/dts/dra7.dtsi| 1 -
>  5 files changed, 5 deletions(-)

Acked-by: Rob Herring 

Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support

[Rafael J. Wysocki]

On Wed, Jun 8, 2016 at 8:35 PM, Mark Brown  wrote:
> On Wed, Jun 08, 2016 at 08:12:34PM +0200, Rafael J. Wysocki wrote:
>> On Wed, Jun 8, 2016 at 2:48 PM, Mark Brown  wrote:
>> > On Thu, Jan 14, 2016 at 02:54:17AM +0100, Rafael J. Wysocki wrote:
>
>> >> + * A side effect of the link creation is re-ordering of dpm_list and the
>> >> + * devices_kset list by moving the consumer device and all devices 
>> >> depending
>> >> + * on it to the ends of those lists.
>
>> > How does this work in the scenario where a device instantiates a child
>> > device then uses services that child provides to complete the
>> > initializiation?  We do have that scenario currently for on chip
>> > regulators to allow external regulators to be used.
>
>> I'm not sure I understand the question correctly, but it that is the
>> parent and a child, we don't need an extra link entity to represent
>> that dependency, as parent-child dependencies are taken by the current
>> code into account already.
>
> A parent (especially a MFD) may create a child to fulfil a role that
> could also be filled by a non-parent device, if that happens then
> depending on what ends up creating these links (it's not 100% clear from
> this series) it's likely that the link creation will also end up
> registering a dependency unless we do something special.  Now I think
> about it this does depend on how we create the children though, it's
> less likely to be an issue if the dependencies are created by firmware
> code.

If that's a non-child device, I would expect it to exist beforehand
and then the link creation would only enforce the specific ordering of
certain operations (like runtime PM or async suspend/resume) between
the two devices linked by it.  That shouldn't be problematic in
principle.

Let me redo the series, though (that may take a couple of days realistically).

Re: [RFC PATCH 1/4] Documentation: mmc: add description for new caps

[Rob Herring]

On Wed, Jun 08, 2016 at 04:20:21PM +0800, Shawn Lin wrote:
> Let's add some basic description for cap-no-sdio,
> cap-no-sd and cap-no-mmc.

This doesn't say why.

If you know what is there, then there's a better way to do this. Look at 
the child nodes because chances are if you have something soldered down 
like SDIO or eMMC, then you have a child node already for resets, 
regulators, etc.

Rob

Re: [v1,2/4] phy: Add USB Type-C PHY driver for rk3399

[Guenter Roeck]

On Fri, Jun 03, 2016 at 11:15:09PM +0800, Chris Zhong wrote:
> Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
> Type-C PHY is designed to support the USB3 and DP applications. The
> PHY basically has two main components: USB3 and DisplyPort. USB3
> operates in SuperSpeed mode and the DP can operate at RBR, HBR and
> HBR2 data rates.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Kever Yang 
> ---
> 
> Changes in v1:
> - update the licence note
> - init core clock to 50MHz
> - use extcon API
> - remove unused global
> - add some comments for magic num
> - change usleep_range(1000, 2000) tousleep_range(1000, 1050)
> - remove __func__ from dev_err
> - return err number when get clk failed
> - remove ADDR_ADJ define
> - use devm_clk_get(>dev, "tcpdcore")
> 
>  drivers/phy/Kconfig|   7 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-rockchip-typec.c   | 942 
> +
>  include/linux/phy/phy-rockchip-typec.h |  20 +
>  4 files changed, 970 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-typec.c
>  create mode 100644 include/linux/phy/phy-rockchip-typec.h
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 26566db..dc388a3d 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -351,6 +351,13 @@ config PHY_ROCKCHIP_DP
>   help
> Enable this to support the Rockchip Display Port PHY.
>  
> +config PHY_ROCKCHIP_TYPEC
> + tristate "Rockchip TYPEC PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY

Should also select RESET_CONTROLLER.

> + help
> +   Enable this to support the Rockchip USB TYPEC PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>   tristate "ST SPEAR1310-MIPHY driver"
>   select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 24596a9..91fa413 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += 
> phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
>  obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
> +obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-typec.c 
> b/drivers/phy/phy-rockchip-typec.c
> new file mode 100644
> index 000..40be944
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-typec.c
> @@ -0,0 +1,942 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + * Kever Yang 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

alphabetic order

> +
> +#define CMN_SSM_BANDGAP  (0x21 << 2)
> +#define CMN_SSM_BIAS (0x22 << 2)
> +#define CMN_PLLSM0_PLLEN (0x29 << 2)
> +#define CMN_PLLSM0_PLLPRE(0x2a << 2)
> +#define CMN_PLLSM0_PLLVREF   (0x2b << 2)
> +#define CMN_PLLSM0_PLLLOCK   (0x2c << 2)
> +#define CMN_PLLSM1_PLLEN (0x31 << 2)
> +#define CMN_PLLSM1_PLLPRE(0x32 << 2)
> +#define CMN_PLLSM1_PLLVREF   (0x33 << 2)
> +#define CMN_PLLSM1_PLLLOCK   (0x34 << 2)
> +#define CMN_PLLSM1_USER_DEF_CTRL (0x37 << 2)
> +#define CMN_ICAL_OVRD(0xc1 << 2)
> +#define CMN_PLL0_VCOCAL_OVRD (0x83 << 2)
> +#define CMN_PLL0_VCOCAL_INIT (0x84 << 2)
> +#define CMN_PLL0_VCOCAL_ITER (0x85 << 2)
> +#define CMN_PLL0_LOCK_REFCNT_START   (0x90 << 2)
> +#define CMN_PLL0_LOCK_PLLCNT_START   (0x92 << 2)
> +#define CMN_PLL0_LOCK_PLLCNT_THR (0x93 << 2)
> +#define CMN_PLL0_INTDIV  (0x94 << 2)
> +#define CMN_PLL0_FRACDIV (0x95 << 2)
> +#define CMN_PLL0_HIGH_THR(0x96 << 2)
> +#define CMN_PLL0_DSM_DIAG(0x97 << 2)
> +#define CMN_PLL0_SS_CTRL1(0x98 << 2)
> +#define CMN_PLL0_SS_CTRL2(0x99 << 2)
> +#define CMN_PLL1_VCOCAL_START(0xa1 << 2)
> 

[PATCH v4 22/29] staging: unisys: visorbus: rectify kerneldoc comment for struct

[David Kershner]

From: David Binder 

Fixes the kerneldoc comment for struct visor_device - the struct members
were not listed with the appropriate @ prefix.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/include/visorbus.h | 34 +++
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 666a04e..c836c8d 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -121,33 +121,33 @@ struct visor_driver {
 /**
  * struct visor_device - A device type for things "plugged" into the visorbus
  * bus
- * visorchannel:   Points to the channel that the device is
+ * @visorchannel:  Points to the channel that the device is
  * associated with.
- * channel_type_guid:  Identifies the channel type to the bus driver.
- * device: Device struct meant for use by the bus driver
+ * @channel_type_guid: Identifies the channel type to the bus driver.
+ * @device:Device struct meant for use by the bus driver
  * only.
- * list_all:   Used by the bus driver to enumerate devices.
- * timer:  Timer fired periodically to do interrupt-type
+ * @list_all:  Used by the bus driver to enumerate devices.
+ * @timer: Timer fired periodically to do interrupt-type
  * activity.
- * being_removed:  Indicates that the device is being removed from
+ * @being_removed: Indicates that the device is being removed from
  * the bus. Private bus driver use only.
- * visordriver_callback_lock:  Used by the bus driver to lock when handling
+ * @visordriver_callback_lock: Used by the bus driver to lock when handling
  * channel events.
- * pausing:Indicates that a change towards a paused state.
+ * @pausing:   Indicates that a change towards a paused state.
  * is in progress. Only modified by the bus driver.
- * resuming:   Indicates that a change towards a running state
+ * @resuming:  Indicates that a change towards a running state
  * is in progress. Only modified by the bus driver.
- * chipset_bus_no: Private field used by the bus driver.
- * chipset_dev_no: Private field used the bus driver.
- * state:  Used to indicate the current state of the
+ * @chipset_bus_no:Private field used by the bus driver.
+ * @chipset_dev_no:Private field used the bus driver.
+ * @state: Used to indicate the current state of the
  * device.
- * inst:   Unique GUID for this instance of the device.
- * name:   Name of the device.
- * pending_msg_hdr:For private use by bus driver to respond to
+ * @inst:  Unique GUID for this instance of the device.
+ * @name:  Name of the device.
+ * @pending_msg_hdr:   For private use by bus driver to respond to
  * hypervisor requests.
- * vbus_hdr_info:  A pointer to header info. Private use by bus
+ * @vbus_hdr_info: A pointer to header info. Private use by bus
  * driver.
- * partition_uuid: Indicates client partion id. This should be the
+ * @partition_uuid:Indicates client partion id. This should be the
  * same across all visor_devices in the current
  * guest. Private use by bus driver only.
  */
-- 
1.9.1

[PATCH v4 27/29] include: linux: visorbus: Add visorbus to include/linux directory

[David Kershner]

Update include/linux to include the s-Par associated common include
header files needed for the s-Par visorbus.

Since we have now moved the include directories over to
include/linux/visorbus this patch makes all of the visor
drivers visorbus, visorinput, visornic, and visorhba use
the new include folders.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/MAINTAINERS| 2 +-
 drivers/staging/unisys/visorbus/Makefile  | 2 --
 drivers/staging/unisys/visorbus/controlvmchannel.h| 2 +-
 drivers/staging/unisys/visorbus/vbuschannel.h | 3 ++-
 drivers/staging/unisys/visorbus/visorbus_main.c   | 6 +++---
 drivers/staging/unisys/visorbus/visorchannel.c| 4 ++--
 drivers/staging/unisys/visorbus/visorchipset.c| 8 
 drivers/staging/unisys/visorbus/vmcallinterface.h | 5 ++---
 drivers/staging/unisys/visorhba/Makefile  | 2 --
 drivers/staging/unisys/visorhba/visorhba_main.c   | 5 ++---
 drivers/staging/unisys/visorinput/Makefile| 2 --
 drivers/staging/unisys/visorinput/visorinput.c| 6 +++---
 drivers/staging/unisys/visornic/Makefile  | 2 --
 drivers/staging/unisys/visornic/visornic_main.c   | 5 ++---
 .../staging/unisys/include => include/linux/visorbus}/channel.h   | 0
 .../unisys/include => include/linux/visorbus}/channel_guid.h  | 0
 .../unisys/include => include/linux/visorbus}/diagchannel.h   | 0
 .../unisys/include => include/linux/visorbus}/guestlinuxdebug.h   | 0
 .../staging/unisys/include => include/linux/visorbus}/iochannel.h | 0
 .../staging/unisys/include => include/linux/visorbus}/version.h   | 0
 .../staging/unisys/include => include/linux/visorbus}/visorbus.h  | 0
 21 files changed, 22 insertions(+), 32 deletions(-)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/channel.h 
(100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/channel_guid.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/diagchannel.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/guestlinuxdebug.h (100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/iochannel.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/version.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/visorbus.h 
(100%)

diff --git a/drivers/staging/unisys/MAINTAINERS 
b/drivers/staging/unisys/MAINTAINERS
index 1f0425b..146a8c3 100644
--- a/drivers/staging/unisys/MAINTAINERS
+++ b/drivers/staging/unisys/MAINTAINERS
@@ -1,5 +1,5 @@
 Unisys s-Par drivers
 M: David Kershner 
 S: Maintained
-F: Documentation/s-Par/overview.txt
+F: Documentation/visorbus.txt
 F: drivers/staging/unisys/
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/staging/unisys/visorbus/Makefile
index f3730d8..7f328cc 100644
--- a/drivers/staging/unisys/visorbus/Makefile
+++ b/drivers/staging/unisys/visorbus/Makefile
@@ -7,5 +7,3 @@ obj-$(CONFIG_UNISYS_VISORBUS)   += visorbus.o
 visorbus-y := visorbus_main.o
 visorbus-y += visorchannel.o
 visorbus-y += visorchipset.o
-
-ccflags-y += -Idrivers/staging/unisys/include
diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/staging/unisys/visorbus/controlvmchannel.h
index 03e36fb..0a0e221 100644
--- a/drivers/staging/unisys/visorbus/controlvmchannel.h
+++ b/drivers/staging/unisys/visorbus/controlvmchannel.h
@@ -16,7 +16,7 @@
 #define __CONTROLVMCHANNEL_H__
 
 #include 
-#include "channel.h"
+#include 
 
 /* {2B3C2D10-7EF5-4ad8-B966-3448B7386B3D} */
 #define SPAR_CONTROLVM_CHANNEL_PROTOCOL_UUID   \
diff --git a/drivers/staging/unisys/visorbus/vbuschannel.h 
b/drivers/staging/unisys/visorbus/vbuschannel.h
index 90fa12e..3e0388d 100644
--- a/drivers/staging/unisys/visorbus/vbuschannel.h
+++ b/drivers/staging/unisys/visorbus/vbuschannel.h
@@ -23,8 +23,9 @@
  *  the client devices and client drivers for the server end to see.
  */
 #include 
+#include 
+
 #include "vbusdeviceinfo.h"
-#include "channel.h"
 
 /* {193b331b-c58f-11da-95a9-00e08161165f} */
 #define SPAR_VBUS_CHANNEL_PROTOCOL_UUID \
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 293532f..2af051c 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -16,11 +16,11 @@
 
 #include 
 
-#include "visorbus.h"
+#include 
+#include 
+#include 
 #include "visorbus_private.h"
-#include "version.h"
 #include "vbuschannel.h"
-#include "guestlinuxdebug.h"
 #include "vmcallinterface.h"
 
 #define MYDRVNAME "visorbus"
diff --git 

[PATCH v4 00/29] Fixed issues raised by tglx, then move visorbus to drivers/virt

[David Kershner]

tglx: The following patchset fixes issues you raised during your
code review of visorbus on 5/18.

Converts visorbus to use a kernel timer for periodic device-specific
callbacks instead of a workqueue, making the implementation in
periodic_work.c and periodic_work.h no longer necessary.  These files
are then deleted.

The visordriver_callback_lock has been switched to a mutex.

Several module parameters and structures were removed that were no
longer being used.

Moves drivers/staging/unisys/include to include/linux/visorbus
and moves drivers/staging/unisys/visorbus to drivers/virt/visorbus.

Changes since v3: 
 - Updated patches to apply cleanly on top of staging-next
 - Modified patch comment to point to correct destination directory

Changes since v2:
 - Fixed comments raised by Neil Horman regarding return -1 changes
 - Fixed kernel-doc style comments for visorbus driver, and added
   kernel-doc documentation for many more functions
 - Reworked visorbus so we did not need notifier_lock

Changes since v1: 
 - Added the patch staging: unisys: visorbus change -1 return values
 - Added the patch staging: unisys: visorchipset change -1 return value
 - Added the patch staging: unisys: iovmcall_gnuc.h change -1 return values

Bryan Thompson (4):
  staging: unisys: visorbus: Make visordriver_callback_lock a mutex
  staging: unisys: visorbus: Remove unnecessary EXPORT_SYMBOL statements
  staging: unisys: visorbus: Remove unused functions
  staging: unisys: Remove reference to unused STANDALONE_CLIENT

David Binder (13):
  staging: unisys: visorbus: remove unused module parameters
  staging: unisys: visorbus: remove unused struct
  staging: unisys: visorbus: modify format string to match argument
  staging: unisys: visornic: Correct comment spelling mistake
  staging: unisys: include: Remove thread-related enum members
  staging: unisys: visorbus: fix commenting in vbusdevinfo.h
  staging: unisys: visorbus: fix commenting in visorbus_main.c
  staging: unisys: visorbus: fix visorchannel.c comments
  staging: unisys: visorbus: Rectify commenting in visorchipset.c
  staging: unisys: visorbus: Move visorbus-unique functions to private
header
  staging: unisys: visorbus: rectify kerneldoc comment for struct
  staging: unisys: visorbus: Remove notifier-related code from visorbus
  staging: unisys: visorbus: Rename function to follow existing
convention

David Kershner (4):
  staging: unisys: Move vbushelper.h to visorbus directory
  include: linux: visorbus: Add visorbus to include/linux directory
  Documentation: Move visorbus documentation from staging to
Documentation/
  drivers: Add visorbus to the drivers/virt directory

Erik Arfvidson (2):
  staging: unisys: visorbus: remove return values for write_vbus
functions
  staging: unisys: visorbus: check parahotplug_request_complete_result

Tim Sell (6):
  staging: unisys: visorbus: removed unused periodic_test_workqueue
  staging: unisys: visorinput: remove unnecessary locking
  staging: unisys: visorbus: use kernel timer instead of workqueue
  staging: unisys: visorbus: remove periodic_work.h/.c
  staging: unisys: visorbus: remove unused parameter from function
  staging: unisys: visorbus: fix visorbus_private.h comments

 .../ABI/stable/sysfs-bus-visorbus  |0
 .../overview.txt => Documentation/visorbus.txt |0
 drivers/staging/unisys/Kconfig |3 +-
 drivers/staging/unisys/MAINTAINERS |2 +-
 drivers/staging/unisys/Makefile|1 -
 drivers/staging/unisys/include/periodic_work.h |   40 -
 drivers/staging/unisys/include/visorbus.h  |  234 
 drivers/staging/unisys/visorbus/Makefile   |   12 -
 drivers/staging/unisys/visorbus/periodic_work.c|  204 ---
 drivers/staging/unisys/visorbus/vbusdeviceinfo.h   |  213 ---
 drivers/staging/unisys/visorbus/visorbus_main.c| 1344 ---
 drivers/staging/unisys/visorbus/visorbus_private.h |   68 -
 drivers/staging/unisys/visorbus/visorchannel.c |  635 -
 drivers/staging/unisys/visorhba/Makefile   |2 -
 drivers/staging/unisys/visorhba/visorhba_main.c|5 +-
 drivers/staging/unisys/visorinput/Makefile |2 -
 drivers/staging/unisys/visorinput/visorinput.c |   63 +-
 drivers/staging/unisys/visornic/Makefile   |2 -
 drivers/staging/unisys/visornic/visornic_main.c|7 +-
 drivers/virt/Kconfig   |2 +
 drivers/virt/Makefile  |1 +
 drivers/{staging/unisys => virt}/visorbus/Kconfig  |0
 drivers/virt/visorbus/Makefile |9 +
 .../unisys => virt}/visorbus/controlvmchannel.h|2 +-
 .../visorbus/controlvmcompletionstatus.h   |0
 .../unisys => virt}/visorbus/iovmcall_gnuc.h   |0
 .../unisys => virt}/visorbus/vbuschannel.h |3 +-
 drivers/virt/visorbus/vbusdeviceinfo.h |  234 
 .../unisys/include 

[PATCH v4 10/29] staging: unisys: visorbus: use kernel timer instead of workqueue

[David Kershner]

From: Tim Sell 

A kernel timer is now used as the vehicle to periodically call the
channel_interrupt function of registered visor drivers, instead of a
workqueue.

This simplifies a lot of things by making periodic_work.c and
periodic_work.h no longer necessary.  This change also means that the
channel_interrupt() callbacks registered by visor drivers (via
visorbus_register_visor_driver()) will now be called in atomic context
(i.e., canNOT sleep) rather than kernel thread context (CAN sleep).
Fortunately this did NOT necessitate any change to the existing
channel_interrupt() callbacks, because none of them ever perform any
operations that would be invalid in atomic context.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/include/visorbus.h   | 10 +++--
 drivers/staging/unisys/visorbus/visorbus_main.c | 54 +++--
 2 files changed, 21 insertions(+), 43 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 9baf1ec..9bb88bb 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -34,8 +34,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
-#include "periodic_work.h"
 #include "channel.h"
 
 struct visor_driver;
@@ -126,8 +127,8 @@ struct visor_driver {
  * device: Device struct meant for use by the bus driver
  * only.
  * list_all:   Used by the bus driver to enumerate devices.
- * periodic_work:  Device work queue. Private use by bus driver
- * only.
+ * timer:  Timer fired periodically to do interrupt-type
+ * activity.
  * being_removed:  Indicates that the device is being removed from
  * the bus. Private bus driver use only.
  * visordriver_callback_lock:  Used by the bus driver to lock when handling
@@ -157,7 +158,8 @@ struct visor_device {
/* These fields are for private use by the bus driver only. */
struct device device;
struct list_head list_all;
-   struct periodic_work *periodic_work;
+   struct timer_list timer;
+   bool timer_active;
bool being_removed;
struct semaphore visordriver_callback_lock;
bool pausing;
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index ebdd5de..e98e720 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -19,7 +19,6 @@
 #include "visorbus.h"
 #include "visorbus_private.h"
 #include "version.h"
-#include "periodic_work.h"
 #include "vbuschannel.h"
 #include "guestlinuxdebug.h"
 #include "vmcallinterface.h"
@@ -116,7 +115,6 @@ struct bus_type visorbus_type = {
.bus_groups = visorbus_bus_groups,
 };
 
-static struct workqueue_struct *periodic_dev_workqueue;
 static long long bus_count;/** number of bus instances */
/** ever-increasing */
 
@@ -222,10 +220,6 @@ visorbus_release_device(struct device *xdev)
 {
struct visor_device *dev = to_visor_device(xdev);
 
-   if (dev->periodic_work) {
-   visor_periodic_work_destroy(dev->periodic_work);
-   dev->periodic_work = NULL;
-   }
if (dev->visorchannel) {
visorchannel_destroy(dev->visorchannel);
dev->visorchannel = NULL;
@@ -530,35 +524,36 @@ unregister_driver_attributes(struct visor_driver *drv)
 }
 
 static void
-dev_periodic_work(void *xdev)
+dev_periodic_work(unsigned long __opaque)
 {
-   struct visor_device *dev = xdev;
+   struct visor_device *dev = (struct visor_device *)__opaque;
struct visor_driver *drv = to_visor_driver(dev->device.driver);
 
-   down(>visordriver_callback_lock);
if (drv->channel_interrupt)
drv->channel_interrupt(dev);
-   up(>visordriver_callback_lock);
-   if (!visor_periodic_work_nextperiod(dev->periodic_work))
-   put_device(>device);
+   mod_timer(>timer, jiffies + POLLJIFFIES_NORMALCHANNEL);
 }
 
 static void
 dev_start_periodic_work(struct visor_device *dev)
 {
-   if (dev->being_removed)
+   if (dev->being_removed || dev->timer_active)
return;
/* now up by at least 2 */
get_device(>device);
-   if (!visor_periodic_work_start(dev->periodic_work))
-   put_device(>device);
+   dev->timer.expires = jiffies + POLLJIFFIES_NORMALCHANNEL;
+   add_timer(>timer);
+   dev->timer_active = true;
 }
 
 static void
 dev_stop_periodic_work(struct visor_device *dev)
 {
-   if (visor_periodic_work_stop(dev->periodic_work))
-   put_device(>device);
+   if (!dev->timer_active)
+   

[PATCH v4 07/29] staging: unisys: include: Remove thread-related enum members

[David Kershner]

From: David Binder 

Code relating to ktheads was previously removed from s-Par driver code.
This patch cleans up lingering remnants of kthreads by removing thread-
related enum types.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/guestlinuxdebug.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/include/guestlinuxdebug.h 
b/drivers/staging/unisys/include/guestlinuxdebug.h
index b81287f..5af3f77 100644
--- a/drivers/staging/unisys/include/guestlinuxdebug.h
+++ b/drivers/staging/unisys/include/guestlinuxdebug.h
@@ -56,7 +56,7 @@ enum driver_pc {  /* POSTCODE driver identifier 
tuples */
UISLIB_PC = 0xD0,
UISLIB_PC_uislib_c = 0xD1,
UISLIB_PC_uisqueue_c = 0xD2,
-   UISLIB_PC_uisthread_c = 0xD3,
+   /* 0xD3 RESERVED */
UISLIB_PC_uisutils_c = 0xD4,
 };
 
@@ -91,7 +91,7 @@ enum event_pc {   /* POSTCODE event 
identifier tuples */
DRIVER_EXIT_PC = 0x0AC,
MALLOC_FAILURE_PC = 0x0AD,
QUEUE_DELAYED_WORK_PC = 0x0AE,
-   UISLIB_THREAD_FAILURE_PC = 0x0B7,
+   /* 0x0B7 RESERVED */
VBUS_CHANNEL_ENTRY_PC = 0x0B8,
VBUS_CHANNEL_FAILURE_PC = 0x0B9,
VBUS_CHANNEL_EXIT_PC = 0x0BA,
-- 
1.9.1

[PATCH 2/2] perf stat: Remove nmi watchdog check code again

[Andi Kleen]

From: Andi Kleen 

Now that the NMI watchdog runs with reference cycles, and does not
conflict with TopDown anymore, we don't need to check that the
NMI watchdog is off in perf stat --topdown.

Remove the code that does this and always use a group unconditionally.

Signed-off-by: Andi Kleen 
---
 tools/perf/Documentation/perf-stat.txt |  6 --
 tools/perf/arch/x86/util/Build |  1 -
 tools/perf/arch/x86/util/group.c   | 27 ---
 tools/perf/builtin-stat.c  | 18 +-
 tools/perf/util/group.h|  7 ---
 5 files changed, 1 insertion(+), 58 deletions(-)
 delete mode 100644 tools/perf/arch/x86/util/group.c
 delete mode 100644 tools/perf/util/group.h

diff --git a/tools/perf/Documentation/perf-stat.txt 
b/tools/perf/Documentation/perf-stat.txt
index d96ccd4844df..6cf4028ddc2c 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -225,12 +225,6 @@ CPU thread. Per core mode is automatically enabled
 and -a (global monitoring) is needed, requiring root rights or
 perf.perf_event_paranoid=-1.
 
-Topdown uses the full Performance Monitoring Unit, and needs
-disabling of the NMI watchdog (as root):
-echo 0 > /proc/sys/kernel/nmi_watchdog
-for best results. Otherwise the bottlenecks may be inconsistent
-on workload with changing phases.
-
 This enables --metric-only, unless overriden with --no-metric-only.
 
 To interpret the results it is usually needed to know on which
diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index f95e6f46ef0d..bc24b75add88 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -3,7 +3,6 @@ libperf-y += tsc.o
 libperf-y += pmu.o
 libperf-y += kvm-stat.o
 libperf-y += perf_regs.o
-libperf-y += group.o
 
 libperf-$(CONFIG_DWARF) += dwarf-regs.o
 libperf-$(CONFIG_BPF_PROLOGUE) += dwarf-regs.o
diff --git a/tools/perf/arch/x86/util/group.c b/tools/perf/arch/x86/util/group.c
deleted file mode 100644
index 37f92aa39a5d..
--- a/tools/perf/arch/x86/util/group.c
+++ /dev/null
@@ -1,27 +0,0 @@
-#include 
-#include "api/fs/fs.h"
-#include "util/group.h"
-
-/*
- * Check whether we can use a group for top down.
- * Without a group may get bad results due to multiplexing.
- */
-bool arch_topdown_check_group(bool *warn)
-{
-   int n;
-
-   if (sysctl__read_int("kernel/nmi_watchdog", ) < 0)
-   return false;
-   if (n > 0) {
-   *warn = true;
-   return false;
-   }
-   return true;
-}
-
-void arch_topdown_group_warn(void)
-{
-   fprintf(stderr,
-   "nmi_watchdog enabled with topdown. May give wrong results.\n"
-   "Disable with echo 0 > /proc/sys/kernel/nmi_watchdog\n");
-}
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index dff63733dfb7..a599a78b2f22 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -59,10 +59,8 @@
 #include "util/thread.h"
 #include "util/thread_map.h"
 #include "util/counts.h"
-#include "util/group.h"
 #include "util/session.h"
 #include "util/tool.h"
-#include "util/group.h"
 #include "asm/bug.h"
 
 #include 
@@ -1861,16 +1859,6 @@ static int topdown_filter_events(const char **attr, char 
**str, bool use_group)
return 0;
 }
 
-__weak bool arch_topdown_check_group(bool *warn)
-{
-   *warn = false;
-   return false;
-}
-
-__weak void arch_topdown_group_warn(void)
-{
-}
-
 /*
  * Add default attributes, if there were no attributes specified or
  * if -d/--detailed, -d -d or -d -d -d is used:
@@ -2010,7 +1998,6 @@ static int add_default_attributes(void)
 
if (topdown_run) {
char *str = NULL;
-   bool warn = false;
 
if (stat_config.aggr_mode != AGGR_GLOBAL &&
stat_config.aggr_mode != AGGR_CORE) {
@@ -2025,14 +2012,11 @@ static int add_default_attributes(void)
 
if (!force_metric_only)
metric_only = true;
-   if (topdown_filter_events(topdown_attrs, ,
-   arch_topdown_check_group()) < 0) {
+   if (topdown_filter_events(topdown_attrs, , true) < 0) {
pr_err("Out of memory\n");
return -1;
}
if (topdown_attrs[0] && str) {
-   if (warn)
-   arch_topdown_group_warn();
err = parse_events(evsel_list, str, NULL);
if (err) {
fprintf(stderr,
diff --git a/tools/perf/util/group.h b/tools/perf/util/group.h
deleted file mode 100644
index 116debe7a995..
--- a/tools/perf/util/group.h
+++ /dev/null
@@ -1,7 +0,0 @@
-#ifndef GROUP_H
-#define GROUP_H 1
-
-bool arch_topdown_check_group(bool *warn);
-void arch_topdown_group_warn(void);
-
-#endif
-- 
2.5.5

Re: [PATCH v4 1/2] [media] atmel-isc: add the Image Sensor Controller code

[Boris Brezillon]

Hi Songjun,

On Tue, 7 Jun 2016 15:11:52 +0800
Songjun Wu  wrote:

> Add driver for the Image Sensor Controller. It manages
> incoming data from a parallel based CMOS/CCD sensor.
> It has an internal image processor, also integrates a
> triple channel direct memory access controller master
> interface.
> 
> Signed-off-by: Songjun Wu 
> ---
> 
> Changes in v4:
> - Modify the isc clock code since the dt is changed.
> 
> Changes in v3:
> - Add pm runtime feature.
> - Modify the isc clock code since the dt is changed.
> 
> Changes in v2:
> - Add "depends on COMMON_CLK" and "VIDEO_V4L2_SUBDEV_API"
>   in Kconfig file.
> - Correct typos and coding style according to Laurent's remarks
> - Delete the loop while in 'isc_clk_enable' function.
> - Add the code to support VIDIOC_CREATE_BUFS in
>   'isc_queue_setup' function.
> - Invoke isc_config to configure register in
>   'isc_start_streaming' function.
> - Add the struct completion 'comp' to synchronize with
>   the frame end interrupt in 'isc_stop_streaming' function.
> - Check the return value of the clk_prepare_enable
>   in 'isc_open' function.
> - Set the default format in 'isc_open' function.
> - Add an exit condition in the loop while in 'isc_config'.
> - Delete the hardware setup operation in 'isc_set_format'.
> - Refuse format modification during streaming
>   in 'isc_s_fmt_vid_cap' function.
> - Invoke v4l2_subdev_alloc_pad_config to allocate and
>   initialize the pad config in 'isc_async_complete' function.
> - Remove the '.owner  = THIS_MODULE,' in atmel_isc_driver.
> - Replace the module_platform_driver_probe() with
>   module_platform_driver().
> 
>  drivers/media/platform/Kconfig|1 +
>  drivers/media/platform/Makefile   |2 +
>  drivers/media/platform/atmel/Kconfig  |9 +
>  drivers/media/platform/atmel/Makefile |1 +
>  drivers/media/platform/atmel/atmel-isc-regs.h |  276 +
>  drivers/media/platform/atmel/atmel-isc.c  | 1580 
> +
>  6 files changed, 1869 insertions(+)
>  create mode 100644 drivers/media/platform/atmel/Kconfig
>  create mode 100644 drivers/media/platform/atmel/Makefile
>  create mode 100644 drivers/media/platform/atmel/atmel-isc-regs.h
>  create mode 100644 drivers/media/platform/atmel/atmel-isc.c
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 84e041c..91d7aea 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -110,6 +110,7 @@ source "drivers/media/platform/exynos4-is/Kconfig"
>  source "drivers/media/platform/s5p-tv/Kconfig"
>  source "drivers/media/platform/am437x/Kconfig"
>  source "drivers/media/platform/xilinx/Kconfig"
> +source "drivers/media/platform/atmel/Kconfig"
>  
>  config VIDEO_TI_CAL
>   tristate "TI CAL (Camera Adaptation Layer) driver"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index bbb7bd1..ad8f471 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -55,4 +55,6 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE) += am437x/
>  
>  obj-$(CONFIG_VIDEO_XILINX)   += xilinx/
>  
> +obj-$(CONFIG_VIDEO_ATMEL_ISC)+= atmel/
> +
>  ccflags-y += -I$(srctree)/drivers/media/i2c
> diff --git a/drivers/media/platform/atmel/Kconfig 
> b/drivers/media/platform/atmel/Kconfig
> new file mode 100644
> index 000..867dca2
> --- /dev/null
> +++ b/drivers/media/platform/atmel/Kconfig
> @@ -0,0 +1,9 @@
> +config VIDEO_ATMEL_ISC
> + tristate "ATMEL Image Sensor Controller (ISC) support"
> + depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA
> + depends on ARCH_AT91 || COMPILE_TEST
> + select VIDEOBUF2_DMA_CONTIG
> + select REGMAP_MMIO
> + help
> +This module makes the ATMEL Image Sensor Controller available
> +as a v4l2 device.
> \ No newline at end of file
> diff --git a/drivers/media/platform/atmel/Makefile 
> b/drivers/media/platform/atmel/Makefile
> new file mode 100644
> index 000..9d7c999
> --- /dev/null
> +++ b/drivers/media/platform/atmel/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o
> diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h 
> b/drivers/media/platform/atmel/atmel-isc-regs.h
> new file mode 100644
> index 000..dda9396
> --- /dev/null
> +++ b/drivers/media/platform/atmel/atmel-isc-regs.h
> @@ -0,0 +1,276 @@
> +#ifndef __ATMEL_ISC_REGS_H
> +#define __ATMEL_ISC_REGS_H
> +
> +#include 
> +
> +/* ISC Control Enable Register 0 */
> +#define ISC_CTRLEN  0x
> +
> +#define ISC_CTRLEN_CAPTURE  BIT(0)
> +#define ISC_CTRLEN_CAPTURE_MASK BIT(0)
> +
> +#define ISC_CTRLEN_UPPROBIT(1)
> +#define ISC_CTRLEN_UPPRO_MASK   BIT(1)
> +
> +#define ISC_CTRLEN_HISREQ   BIT(2)
> +#define ISC_CTRLEN_HISREQ_MASK  BIT(2)
> +
> +#define ISC_CTRLEN_HISCLR

Re: [PATCH v4 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver

[Rob Herring]

On Tue, Jun 07, 2016 at 03:11:53PM +0800, Songjun Wu wrote:
> DT binding documentation for ISC driver.
> 
> Signed-off-by: Songjun Wu 
> ---
> 
> Changes in v4:
> - Remove the isc clock nodes.
> 
> Changes in v3:
> - Remove the 'atmel,sensor-preferred'.
> - Modify the isc clock node according to the Rob's remarks.
> 
> Changes in v2:
> - Remove the unit address of the endpoint.
> - Add the unit address to the clock node.
> - Avoid using underscores in node names.
> - Drop the "0x" in the unit address of the i2c node.
> - Modify the description of 'atmel,sensor-preferred'.
> - Add the description for the ISC internal clock.
> 
>  .../devicetree/bindings/media/atmel-isc.txt| 69 
> ++
>  1 file changed, 69 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt

Almost there...

> diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt 
> b/Documentation/devicetree/bindings/media/atmel-isc.txt
> new file mode 100644
> index 000..3f83524
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
> @@ -0,0 +1,69 @@
> +Atmel Image Sensor Controller (ISC)
> +--
> +
> +Required properties for ISC:
> +- compatible
> + Must be "atmel,sama5d2-isc".
> +- reg
> + Physical base address and length of the registers set for the device.
> +- interrupts
> + Should contain IRQ line for the ISC.
> +- clocks
> + List of clock specifiers, corresponding to entries in
> + the clock-names property;
> + Please refer to clock-bindings.txt.
> +- clock-names
> + Required elements: "hclock".
> +- #clock-cells
> + Should be 0.
> +- clock-output-names
> + Should contain the name of the clock driving the sensor master clock.
> +- pinctrl-names, pinctrl-0
> + Please refer to pinctrl-bindings.txt.

Required, but not in your example.

> +
> +
> +ISC supports a single port node with parallel bus. It should contain one
> +'port' child node with child 'endpoint' node. Please refer to the bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +isc: isc@f0008000 {
> + compatible = "atmel,sama5d2-isc";
> + reg = <0xf0008000 0x4000>;
> + interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
> + clocks = <_clk>, <>, <_gclk>;
> + clock-names = "hclock";
> + #clock-cells = <0>;
> + clock-output-names = "isc-mck";
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;

These 2 you can drop.

> +
> + isc_0: endpoint {
> + remote-endpoint = <_0>;
> + hsync-active = <1>;
> + vsync-active = <0>;
> + pclk-sample = <1>;
> + };
> + };
> +
> +
> +};
> +
> +i2c1: i2c@fc028000 {
> + ov7740: camera@21 {
> + compatible = "ovti,ov7740";

Fix the indentation.

> + reg = <0x21>;
> +
> + clocks = <>;
> + clock-names = "xvclk";
> + assigned-clocks = <>;
> + assigned-clock-rates = <2400>;
> +
> + port {
> + ov7740_0: endpoint {
> + remote-endpoint = <_0>;
> + };
> + };
> +};
> -- 
> 2.7.4
> 

Re: [PATCH] nvmem: fix nvmem_cell_read() return type for !CONFIG_NVMEM

[Brian Norris]

On Wed, Jun 08, 2016 at 07:52:06PM +0100, Srinivas Kandagatla wrote:
> On 08/06/16 17:40, Brian Norris wrote:
> >On Wed, Jun 08, 2016 at 09:26:46AM -0700, Brian Norris wrote:
> >>With CONFIG_NVMEM, nvmem_cell_read() returns void *. With !CONFIG_NVMEM
> >>it returns char *. Let's make that consistent. Also drop the
> >>incorrect/inconsistent comment about char * above the nvmem_cell_read()
> >>definition.
> >>
> >>drivers/thermal/mtk_thermal.c is already working around this by casting
> >>to (u32 *).
> >>
> >>Signed-off-by: Brian Norris 
> >
> >Seems Guenter submitted the same thing a week ago, with no response:
> 
> This patch has been already sent to Greg few days back with my sign
> off http://permalink.gmane.org/gmane.linux.kernel/2233276

Ah, didn't notice that either. Anyway, doesn't seem to show up in
linux-next.

Brian

ima and tpm2.0

[Jerry Snitselaar]

Should the ima Kconfig have a select line for tpm_crb similar to the tpm_tis 
and tpm_ibmvtpm bits?

Re: [PATCH 03/11] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs

[Rob Herring]

On Tue, Jun 07, 2016 at 03:44:36PM -0700, Douglas Anderson wrote:
> As can be seen in Arasan's datasheet [1] there are several "corecfg"
> settings in their SDHCI IP Block that are supposed to be controlled by
> software.  Although the datasheet referenced is a bit vague about how to
> access corecfg, in Figure 5 you can see that for Arasan's PHY (a
> separate component than their SDHCI component) they describe the
> "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up
> to the licensee of the Arasan IP block to implement these registers.  It
> seems sane to assume that the "corecfg" registers in their SDHCI IP
> block works in a similar way for all licensees of the IP Block.
> 
> Device tree has a model that allows a device to get a reference to
> random registers located elsewhere in the SoC: sysctl.  Let's leverage
> this model and allow adding a sysctl reference to access the control
> registers for the Arasan SDHCI PHYs.
> 
> Having a reference to the control registers doesn't do much for us on
> its own since the Arasan spec doesn't specify how these corecfg values
> are laid out in memory.  In the SDHCI driver we'll need a map detailing
> where each corecfg can be found in each implementation.  This map can be
> found using the primary compatible string of the SDHCI device.  In that
> spirit, document that existing rk3399 device trees already have a
> specific compatible string, though up to now they've always been relying
> on the driver supporting the generic.
> 
> Note that since existing devices seem to work fairly well as-is, we'll
> list the syscon reference as "optional", but it's likely that we'll run
> into much fewer problems if we can actually set the proper values in the
> syscon, so it is strongly suggested that any SoCs where we have a map to
> set the corecfg also include a reference to the syscon.
> 
> [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf
> 
> Signed-off-by: Douglas Anderson 
> ---
>  .../devicetree/bindings/mmc/arasan,sdhci.txt   | 27 
> --
>  1 file changed, 25 insertions(+), 2 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH 1/3] ACPICA: Events: Introduce acpi_block_gpe()/acpi_unblock_gpe()/acpi_control_gpe_handling() to allow administrative GPE enabling/disabling

[Rafael J. Wysocki]

On Wed, Jun 8, 2016 at 9:49 AM, Zheng, Lv  wrote:
> Hi,
>
>> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
>> Subject: Re: [PATCH 1/3] ACPICA: Events: Introduce
>> acpi_block_gpe()/acpi_unblock_gpe()/acpi_control_gpe_handling() to
>> allow administrative GPE enabling/disabling
>>
>> On Monday, May 16, 2016 05:11:11 PM Lv Zheng wrote:
>> > There is a facility in Linux, developers can manage GPE enabling/disabling
>> > through /sys/firmware/acpi/interrupts/gpexx. This is mainly for
>> debugging
>> > purposes. Many users expect to use this facility to implement quirks to
>> > disable specific GPEs when there is a gap in Linux causing GPE flood.
>> > This is not working correctly because currently this facility invokes
>> > enabling/disabling counting based GPE driver APIs:
>> >  acpi_enable_gpe()/acpi_disable_gpe()
>> > and the GPE drivers can still affect the count to mess up the GPE
>> > management purposes.
>> >
>> > This patch introduces acpi_block_gpe()/acpi_unblock_gpe() to be used in
>> such
>> > situation instead of acpi_enable_gpe()/acpi_disable_gpe().
>>
>> Up to this point, I agree.
>>
>> > The idea to implement this is to replace the GPE register EN bit with the
>> > managed value, block EN set/clear operations but record the operation
>> > results in blocked_enabled, so that after the managed state is removed,
>> > restore the saved blocked_enabled back to the GPE register EN bit.
>>
>> Unfortunately, I don't really follow the above paragraph, so chances are
>> that
>> whoever is not familiar with the code will not be able to follow it either.
> [Lv Zheng]
> I see.
> I should stop talking this using "managed".
> It is better to use "masked".
> As this facility is actually trying to implement the kind of the facility 
> that can be seen in many other IRQ chips - the IRQ MASK bit.

This is a somewhat simplified special case of it, though.

>> > Now OSPMs should be able to use this facility to generate quirks. ACPICA
>> > BZ 1102.
>> >
>> > This facility can also be used by the administrator to control the GPE
>> > handling mode during the runtime when the driver is capable of handling
>> the
>> > GPE in both the interrupt mode and the polling mode (for example, the
>> Linux
>> > EC driver). acpi_control_gpe_handling() is offered for this purpose. Lv
>> Zheng.
>>
>> That is too much.  The patch should focus on the block/unblock
>> functionality.
>> Anything beyond that should be added later IMO.
> [Lv Zheng]
> OK.
> So after examining all of your comments.
> I think what I need to improve is eliminating this feature.
> That should be able to make the code simpler and thus easier for the others 
> to follow.

Sounds good!

Re: [PATCH 1/2] Documentation: bindings: add dt documentation for Rockchip PCIe PHY

[Rob Herring]

gOn Wed, Jun 08, 2016 at 03:25:08PM +0800, Shawn Lin wrote:
> This patch adds a binding that describes the Rockchip PCIe PHY
> found on Rockchip SoCs PCIe interface.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
>  .../devicetree/bindings/phy/rockchip-pcie-phy.txt  | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt 
> b/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt
> new file mode 100644
> index 000..ba8c406
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie-phy.txt
> @@ -0,0 +1,22 @@
> +Rockchip PCIE PHY
> +---
> +
> +Required properties:
> + - compatible: rockchip,rk3399-pcie-phy
> + - #phy-cells: must be 0
> +
> +Example:
> +
> +grf: syscon@ff77 {
> + compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + ...
> +
> + pcie_phy: phy@e220 {

unit-address needs a reg property or drop the unit address. I'd do the 
former if there's a register range you can describe here.


> + compatible = "rockchip,rk3399-pcie-phy";
> + #phy-cells = <0>;
> + };
> +};
> +
> -- 
> 2.3.7
> 
> 

Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Alexandre Belloni]

On 08/06/2016 at 15:26:51 -0500, Rob Herring wrote :
> On Wed, Jun 08, 2016 at 12:15:10PM +0800, Wenyou Yang wrote:
> > In order to the save power consumption, as a workaround, suspend
> > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> > Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> > 
> > This suspend operation must be done before the USB clock is disabled,
> > resume after the USB clock is enabled.
> > 
> > Signed-off-by: Wenyou Yang 
> > ---
> > 
> > Changes in v3:
> >  - Change the compatible description for more precise.
> > 
> > Changes in v2:
> >  - Add compatible to support forcibly suspend the ports.
> >  - Add soc/at91/at91_sfr.h to accommodate the defines.
> >  - Add error checking for .sfr_regmap.
> >  - Remove unnecessary regmap_read() statement.
> > 
> >  .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
> >  drivers/usb/host/ohci-at91.c   | 80 
> > +-
> >  include/soc/at91/at91_sfr.h| 29 
> >  3 files changed, 112 insertions(+), 3 deletions(-)
> >  create mode 100644 include/soc/at91/at91_sfr.h
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt 
> > b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > index 5883b73..888deaa 100644
> > --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > @@ -3,8 +3,10 @@ Atmel SOC USB controllers
> >  OHCI
> >  
> >  Required properties:
> > - - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
> > -   used in host mode.
> > + - compatible: Should be one of the following
> > +  "atmel,at91rm9200-ohci" for USB controllers used in host mode.
> > +  "atmel,sama5d2-ohci" for USB controllers used in host mode
> > +  on SAMA5D2 which can force to suspend.
> 
> Guess I wasn't clear enough before. Drop "which can force to suspend".
> 

Well, my point is that we don't need a new compatible anyway.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 2/4] dell-wmi: Sort WMI event codes and update comments

[Pali Rohár]

On Wednesday 08 June 2016 22:43:28 Darren Hart wrote:
> I'm just getting to the series now, if it's otherwise ready, I'll
> include this myself. If changes are required, I'll leave it to you.
> Thanks Pali.

There is already V2 of this series with fixed problems reported by 
Michał. So Michał should ack it...

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v4 1/2] i2c: qup: add ACPI support

[Arnd Bergmann]

On Wednesday, June 8, 2016 12:19:44 PM CEST Austin Christ wrote:
> +   ret = device_property_read_u32(qup->dev,
> +   "src-clock-hz", _clk_freq);
> +   if (ret) {
> +   dev_warn(qup->dev, "using default src-clock-hz %d",
> +   DEFAULT_SRC_CLK);
> +   src_clk_freq = DEFAULT_SRC_CLK;
> +   }
> 

Where is this property documented?

Arnd

[PATCH v4 20/29] staging: unisys: visorbus: Rectify commenting in visorchipset.c

[David Kershner]

From: David Binder 

Adds kerneldoc formatting to appropriate functions. Other multi-line
comments now use proper formatting.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 292 -
 1 file changed, 190 insertions(+), 102 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index b5942c6..f8e1fa5 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -78,10 +78,11 @@ visorchipset_release(struct inode *inode, struct file *file)
return 0;
 }
 
-/* When the controlvm channel is idle for at least MIN_IDLE_SECONDS,
-* we switch to slow polling mode.  As soon as we get a controlvm
-* message, we switch back to fast polling mode.
-*/
+/*
+ * When the controlvm channel is idle for at least MIN_IDLE_SECONDS,
+ * we switch to slow polling mode. As soon as we get a controlvm
+ * message, we switch back to fast polling mode.
+ */
 #define MIN_IDLE_SECONDS 10
 static unsigned long poll_jiffies = POLLJIFFIES_CONTROLVMCHANNEL_FAST;
 /* when we got our last controlvm message */
@@ -112,7 +113,8 @@ static struct visorchannel *controlvm_channel;
 /* Manages the request payload in the controlvm channel */
 struct visor_controlvm_payload_info {
u8 *ptr;/* pointer to base address of payload pool */
-   u64 offset; /* offset from beginning of controlvm
+   u64 offset; /*
+* offset from beginning of controlvm
 * channel to beginning of payload * pool
 */
u32 bytes;  /* number of bytes in payload pool */
@@ -120,15 +122,17 @@ struct visor_controlvm_payload_info {
 
 static struct visor_controlvm_payload_info controlvm_payload_info;
 
-/* The following globals are used to handle the scenario where we are unable to
- * offload the payload from a controlvm message due to memory requirements.  In
+/*
+ * The following globals are used to handle the scenario where we are unable to
+ * offload the payload from a controlvm message due to memory requirements. In
  * this scenario, we simply stash the controlvm message, then attempt to
  * process it again the next time controlvm_periodic_work() runs.
  */
 static struct controlvm_message controlvm_pending_msg;
 static bool controlvm_pending_msg_valid;
 
-/* This identifies a data buffer that has been received via a controlvm 
messages
+/*
+ * This identifies a data buffer that has been received via a controlvm 
messages
  * in a remote --> local CONTROLVM_TRANSMIT_FILE conversation.
  */
 struct putfile_buffer_entry {
@@ -136,13 +140,15 @@ struct putfile_buffer_entry {
struct parser_context *parser_ctx; /* points to input data buffer */
 };
 
-/* List of struct putfile_request *, via next_putfile_request member.
+/*
+ * List of struct putfile_request *, via next_putfile_request member.
  * Each entry in this list identifies an outstanding TRANSMIT_FILE
  * conversation.
  */
 static LIST_HEAD(putfile_request_list);
 
-/* This describes a buffer and its current state of transfer (e.g., how many
+/*
+ * This describes a buffer and its current state of transfer (e.g., how many
  * bytes have already been supplied as putfile data, and how many bytes are
  * remaining) for a putfile_request.
  */
@@ -154,8 +160,9 @@ struct putfile_active_buffer {
 };
 
 #define PUTFILE_REQUEST_SIG 0x0906101302281211
-/* This identifies a single remote --> local CONTROLVM_TRANSMIT_FILE
- * conversation.  Structs of this type are dynamically linked into
+/*
+ * This identifies a single remote --> local CONTROLVM_TRANSMIT_FILE
+ * conversation. Structs of this type are dynamically linked into
  * .
  */
 struct putfile_request {
@@ -167,7 +174,8 @@ struct putfile_request {
/* link to next struct putfile_request */
struct list_head next_putfile_request;
 
-   /* head of putfile_buffer_entry list, which describes the data to be
+   /*
+* head of putfile_buffer_entry list, which describes the data to be
 * supplied as putfile data;
 * - this list is added to when controlvm messages come in that supply
 * file data
@@ -183,11 +191,13 @@ struct putfile_request {
/* data not yet read within current putfile_buffer_entry */
struct putfile_active_buffer active_buf;
 
-   /* <0 = failed, 0 = in-progress, >0 = successful; */
-   /* note that this must be set with req_list_lock, and if you set <0, */
-   /* it is your responsibility to also free up all of the other objects */
-   /* in this struct (like input_buffer_list, active_buf.parser_ctx) */
-   /* before releasing the lock */
+   /*
+* <0 = 

[PATCH v4 24/29] staging: unisys: visorbus: Rename function to follow existing convention

[David Kershner]

From: David Binder 

Renames visorchipset_device_pause_response to device_pause_response,
thereby following the convention that other responder functions follow.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/visorbus_main.c| 4 ++--
 drivers/staging/unisys/visorbus/visorbus_private.h | 3 +--
 drivers/staging/unisys/visorbus/visorchipset.c | 4 ++--
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index c361077..293532f 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1218,7 +1218,7 @@ pause_state_change_complete(struct visor_device *dev, int 
status)
 
dev->pausing = false;
 
-   visorchipset_device_pause_response(dev, status);
+   device_pause_response(dev, status);
 }
 
 /**
@@ -1265,7 +1265,7 @@ initiate_chipset_device_pause_resume(struct visor_device 
*dev, bool is_pause)
void (*notify_func)(struct visor_device *dev, int response) = NULL;
 
if (is_pause)
-   notify_func = visorchipset_device_pause_response;
+   notify_func = device_pause_response;
else
notify_func = device_resume_response;
if (!notify_func)
diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 3b5a8f2..a7b1d4f 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -35,8 +35,7 @@ void bus_destroy_response(struct visor_device *p, int 
response);
 void device_create_response(struct visor_device *p, int response);
 void device_destroy_response(struct visor_device *p, int response);
 void device_resume_response(struct visor_device *p, int response);
-void visorchipset_device_pause_response(struct visor_device *p,
-   int response);
+void device_pause_response(struct visor_device *p, int response);
 
 /* visorbus init and exit functions */
 int visorbus_init(void);
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index ea548df..0b4a138 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1983,8 +1983,8 @@ device_destroy_response(struct visor_device *dev_info, 
int response)
 }
 
 void
-visorchipset_device_pause_response(struct visor_device *dev_info,
-  int response)
+device_pause_response(struct visor_device *dev_info,
+ int response)
 {
device_changestate_responder(CONTROLVM_DEVICE_CHANGESTATE,
 dev_info, response,
-- 
1.9.1

[PATCH v4 28/29] Documentation: Move visorbus documentation from staging to Documentation/

[David Kershner]

This patch simple does a git mv of the
drivers/staging/unisys/Documentation directory to Documentation. Renames
overview.txt to visorbus.txt and renames sysfs-platform-visorchipset to
the correct name sysfs-bus-visorbus.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 .../ABI/stable/sysfs-bus-visorbus | 0
 .../unisys/Documentation/overview.txt => Documentation/visorbus.txt   | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset => 
Documentation/ABI/stable/sysfs-bus-visorbus (100%)
 rename drivers/staging/unisys/Documentation/overview.txt => 
Documentation/visorbus.txt (100%)

diff --git 
a/drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset 
b/Documentation/ABI/stable/sysfs-bus-visorbus
similarity index 100%
rename from drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset
rename to Documentation/ABI/stable/sysfs-bus-visorbus
diff --git a/drivers/staging/unisys/Documentation/overview.txt 
b/Documentation/visorbus.txt
similarity index 100%
rename from drivers/staging/unisys/Documentation/overview.txt
rename to Documentation/visorbus.txt
-- 
1.9.1

[PATCH v4 14/29] staging: unisys: visorbus: Remove unused functions

[David Kershner]

From: Bryan Thompson 

Remove visorbus_clear_channel, visorchannel_signalqueue_slots_avail,
visorchannel_signalqueue_max_slots, visorchannel_clear, and
visorchannel_debug which are no longer called by any driver.

Signed-off-by: Bryan Thompson 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h   |   9 --
 drivers/staging/unisys/visorbus/visorbus_main.c |   7 --
 drivers/staging/unisys/visorbus/visorchannel.c  | 161 
 3 files changed, 177 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 3ba01cf..cbe240a 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -185,8 +185,6 @@ int visorbus_read_channel(struct visor_device *dev,
 int visorbus_write_channel(struct visor_device *dev,
   unsigned long offset, void *src,
   unsigned long nbytes);
-int visorbus_clear_channel(struct visor_device *dev,
-  unsigned long offset, u8 ch, unsigned long nbytes);
 void visorbus_enable_channel_interrupts(struct visor_device *dev);
 void visorbus_disable_channel_interrupts(struct visor_device *dev);
 #endif
@@ -206,17 +204,12 @@ int visorchannel_read(struct visorchannel *channel, ulong 
offset,
  void *local, ulong nbytes);
 int visorchannel_write(struct visorchannel *channel, ulong offset,
   void *local, ulong nbytes);
-int visorchannel_clear(struct visorchannel *channel, ulong offset,
-  u8 ch, ulong nbytes);
 bool visorchannel_signalremove(struct visorchannel *channel, u32 queue,
   void *msg);
 bool visorchannel_signalinsert(struct visorchannel *channel, u32 queue,
   void *msg);
 bool visorchannel_signalempty(struct visorchannel *channel, u32 queue);
 
-int visorchannel_signalqueue_slots_avail(struct visorchannel *channel,
-u32 queue);
-int visorchannel_signalqueue_max_slots(struct visorchannel *channel, u32 
queue);
 u64 visorchannel_get_physaddr(struct visorchannel *channel);
 ulong visorchannel_get_nbytes(struct visorchannel *channel);
 char *visorchannel_id(struct visorchannel *channel, char *s);
@@ -226,8 +219,6 @@ int visorchannel_set_clientpartition(struct visorchannel 
*channel,
 u64 partition_handle);
 uuid_le visorchannel_get_uuid(struct visorchannel *channel);
 char *visorchannel_uuid_id(uuid_le *guid, char *s);
-void visorchannel_debug(struct visorchannel *channel, int num_queues,
-   struct seq_file *seq, u32 off);
 void __iomem *visorchannel_get_header(struct visorchannel *channel);
 
 #define BUS_ROOT_DEVICEUINT_MAX
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index f7f5986..8c1754f9 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -715,13 +715,6 @@ visorbus_write_channel(struct visor_device *dev, unsigned 
long offset,
 }
 EXPORT_SYMBOL_GPL(visorbus_write_channel);
 
-int
-visorbus_clear_channel(struct visor_device *dev, unsigned long offset, u8 ch,
-  unsigned long nbytes)
-{
-   return visorchannel_clear(dev->visorchannel, offset, ch, nbytes);
-}
-
 /** We don't really have a real interrupt, so for now we just call the
  *  interrupt function periodically...
  */
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 1f626c3..43315c2 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -255,41 +255,6 @@ visorchannel_write(struct visorchannel *channel, ulong 
offset,
return 0;
 }
 
-int
-visorchannel_clear(struct visorchannel *channel, ulong offset, u8 ch,
-  ulong nbytes)
-{
-   int err;
-   int bufsize = PAGE_SIZE;
-   int written = 0;
-   u8 *buf;
-
-   buf = (u8 *)__get_free_page(GFP_KERNEL);
-   if (!buf)
-   return -ENOMEM;
-
-   memset(buf, ch, bufsize);
-
-   while (nbytes > 0) {
-   int thisbytes = bufsize;
-
-   if (nbytes < thisbytes)
-   thisbytes = nbytes;
-   err = visorchannel_write(channel, offset + written,
-buf, thisbytes);
-   if (err)
-   goto out_free_page;
-
-   written += thisbytes;
-   nbytes -= thisbytes;
-   }
-   err = 0;
-
-out_free_page:
-   free_page((unsigned long)buf);
-   return err;
-}
-
 void __iomem  *
 visorchannel_get_header(struct visorchannel *channel)
 {
@@ 

[PATCH v4 09/29] staging: unisys: visorinput: remove unnecessary locking

[David Kershner]

From: Tim Sell 

Locking in the _interrupt() function is NOT necessary so long as we ensure
that interrupts have been stopped whenever we need to pause or resume the
device, which we now do.

While a device is paused, we ensure that interrupts stay disabled, i.e.
that the _interrupt() function will NOT be called, yet remember the desired
state in devdata->interrupts_enabled if open() or close() are called are
called while the device is paused.  Then when the device is resumed, we
restore the actual state of interrupts (i.e., whether _interrupt() is going
to be called or not) to the desired state in devdata->interrupts_enabled.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorinput/visorinput.c | 57 +-
 1 file changed, 47 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/unisys/visorinput/visorinput.c 
b/drivers/staging/unisys/visorinput/visorinput.c
index d67cd763..f633985 100644
--- a/drivers/staging/unisys/visorinput/visorinput.c
+++ b/drivers/staging/unisys/visorinput/visorinput.c
@@ -66,6 +66,7 @@ struct visorinput_devdata {
struct rw_semaphore lock_visor_dev; /* lock for dev */
struct input_dev *visorinput_dev;
bool paused;
+   bool interrupts_enabled;
unsigned int keycode_table_bytes; /* size of following array */
/* for keyboard devices: visorkbd_keycode[] + visorkbd_ext_keycode[] */
unsigned char keycode_table[0];
@@ -228,7 +229,21 @@ static int visorinput_open(struct input_dev 
*visorinput_dev)
return -EINVAL;
}
dev_dbg(_dev->dev, "%s opened\n", __func__);
+
+   /*
+* If we're not paused, really enable interrupts.
+* Regardless of whether we are paused, set a flag indicating
+* interrupts should be enabled so when we resume, interrupts
+* will really be enabled.
+*/
+   down_write(>lock_visor_dev);
+   devdata->interrupts_enabled = true;
+   if (devdata->paused)
+   goto out_unlock;
visorbus_enable_channel_interrupts(devdata->dev);
+
+out_unlock:
+   up_write(>lock_visor_dev);
return 0;
 }
 
@@ -243,7 +258,22 @@ static void visorinput_close(struct input_dev 
*visorinput_dev)
return;
}
dev_dbg(_dev->dev, "%s closed\n", __func__);
+
+   /*
+* If we're not paused, really disable interrupts.
+* Regardless of whether we are paused, set a flag indicating
+* interrupts should be disabled so when we resume we will
+* not re-enable them.
+*/
+
+   down_write(>lock_visor_dev);
+   devdata->interrupts_enabled = false;
+   if (devdata->paused)
+   goto out_unlock;
visorbus_disable_channel_interrupts(devdata->dev);
+
+out_unlock:
+   up_write(>lock_visor_dev);
 }
 
 /*
@@ -438,10 +468,8 @@ visorinput_remove(struct visor_device *dev)
 * in visorinput_channel_interrupt()
 */
 
-   down_write(>lock_visor_dev);
dev_set_drvdata(>device, NULL);
unregister_client_input(devdata->visorinput_dev);
-   up_write(>lock_visor_dev);
kfree(devdata);
 }
 
@@ -529,13 +557,7 @@ visorinput_channel_interrupt(struct visor_device *dev)
if (!devdata)
return;
 
-   down_write(>lock_visor_dev);
-   if (devdata->paused) /* don't touch device/channel when paused */
-   goto out_locked;
-
visorinput_dev = devdata->visorinput_dev;
-   if (!visorinput_dev)
-   goto out_locked;
 
while (visorchannel_signalremove(dev->visorchannel, 0, )) {
scancode = r.activity.arg1;
@@ -611,8 +633,6 @@ visorinput_channel_interrupt(struct visor_device *dev)
break;
}
}
-out_locked:
-   up_write(>lock_visor_dev);
 }
 
 static int
@@ -632,6 +652,14 @@ visorinput_pause(struct visor_device *dev,
rc = -EBUSY;
goto out_locked;
}
+   if (devdata->interrupts_enabled)
+   visorbus_disable_channel_interrupts(dev);
+
+   /*
+* due to above, at this time no thread of execution will be
+* in visorinput_channel_interrupt()
+*/
+
devdata->paused = true;
complete_func(dev, 0);
rc = 0;
@@ -659,6 +687,15 @@ visorinput_resume(struct visor_device *dev,
}
devdata->paused = false;
complete_func(dev, 0);
+
+   /*
+* Re-establish calls to visorinput_channel_interrupt() if that is
+* the desired state that we've kept track of in interrupts_enabled
+* while the device was paused.
+*/
+   if (devdata->interrupts_enabled)
+   visorbus_enable_channel_interrupts(dev);
+
rc = 0;
 out_locked:
up_write(>lock_visor_dev);
-- 
1.9.1

[PATCH v4 06/29] staging: unisys: visornic: Correct comment spelling mistake

[David Kershner]

From: David Binder 

Fixes a comment spelling mistake in visornic.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visornic/visornic_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index a28388d..4fbe703 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -1586,7 +1586,7 @@ drain_resp_queue(struct uiscmdrsp *cmdrsp, struct 
visornic_devdata *devdata)
  *
  * Drain the respones queue of any responses from the IO partition.
  * Process the responses as we get them.
- * Returns when response queue is empty or when the threadd stops.
+ * Returns when response queue is empty or when the thread stops.
  */
 static void
 service_resp_queue(struct uiscmdrsp *cmdrsp, struct visornic_devdata *devdata,
-- 
1.9.1

[PATCH v4 04/29] staging: unisys: visorbus: remove unused struct

[David Kershner]

From: David Binder 

Removes unused struct definition, channel_size_info, in response to
findings by SonarQube.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 71bff07..08d560c 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1260,12 +1260,6 @@ chipset_device_resume(struct visor_device *dev_info)
initiate_chipset_device_pause_resume(dev_info, false);
 }
 
-struct channel_size_info {
-   uuid_le guid;
-   unsigned long min_size;
-   unsigned long max_size;
-};
-
 int
 visorbus_init(void)
 {
-- 
1.9.1

[PATCH v4 23/29] staging: unisys: visorbus: Remove notifier-related code from visorbus

[David Kershner]

From: David Binder 

When this functionality was first implemented, visorchipset and visorbus
were separate drivers, which necessitated a registration mechanism for
them to communicate.  More-recently, visorchipset and visorbus were
combined into a single driver, and now exist as separate source files
within the same driver, known as 'visorbus'.  This eliminated the need
for a registration mechanism, but it has remained nevertheless until now.
For the sake of simplification, this registration mechanism is now being
removed.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c|  76 +++-
 drivers/staging/unisys/visorbus/visorbus_private.h |  50 +++-
 drivers/staging/unisys/visorbus/visorchipset.c | 130 -
 3 files changed, 50 insertions(+), 206 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 2468264..c361077 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -119,32 +119,6 @@ struct bus_type visorbus_type = {
 static long long bus_count;/* number of bus instances */
/* ever-increasing */
 
-static void chipset_bus_create(struct visor_device *bus_info);
-static void chipset_bus_destroy(struct visor_device *bus_info);
-static void chipset_device_create(struct visor_device *dev_info);
-static void chipset_device_destroy(struct visor_device *dev_info);
-static void chipset_device_pause(struct visor_device *dev_info);
-static void chipset_device_resume(struct visor_device *dev_info);
-
-/*
- * These functions are implemented herein, and are called by the chipset
- * driver to notify us about specific events.
- */
-static struct visorchipset_busdev_notifiers chipset_notifiers = {
-   .bus_create = chipset_bus_create,
-   .bus_destroy = chipset_bus_destroy,
-   .device_create = chipset_device_create,
-   .device_destroy = chipset_device_destroy,
-   .device_pause = chipset_device_pause,
-   .device_resume = chipset_device_resume,
-};
-
-/*
- * These functions are implemented in the chipset driver, and we call them
- * herein when we want to acknowledge a specific event.
- */
-static struct visorchipset_busdev_responders chipset_responders;
-
 /* filled in with info about parent chipset driver when we register with it */
 static struct ultra_vbus_deviceinfo chipset_driverinfo;
 /* filled in with info about this driver, wrt it servicing client busses */
@@ -1171,7 +1145,7 @@ remove_all_visor_devices(void)
}
 }
 
-static void
+void
 chipset_bus_create(struct visor_device *dev)
 {
int rc;
@@ -1188,19 +1162,17 @@ chipset_bus_create(struct visor_device *dev)
POSTCODE_LINUX_3(CHIPSET_INIT_SUCCESS_PC, bus_no,
 POSTCODE_SEVERITY_INFO);
 
-   if (chipset_responders.bus_create)
-   (*chipset_responders.bus_create) (dev, rc);
+   bus_create_response(dev, rc);
 }
 
-static void
+void
 chipset_bus_destroy(struct visor_device *dev)
 {
remove_bus_instance(dev);
-   if (chipset_responders.bus_destroy)
-   (*chipset_responders.bus_destroy)(dev, 0);
+   bus_destroy_response(dev, 0);
 }
 
-static void
+void
 chipset_device_create(struct visor_device *dev_info)
 {
int rc;
@@ -1211,8 +1183,7 @@ chipset_device_create(struct visor_device *dev_info)
 POSTCODE_SEVERITY_INFO);
 
rc = create_visor_device(dev_info);
-   if (chipset_responders.device_create)
-   chipset_responders.device_create(dev_info, rc);
+   device_create_response(dev_info, rc);
 
if (rc < 0)
POSTCODE_LINUX_4(DEVICE_CREATE_FAILURE_PC, dev_no, bus_no,
@@ -1222,13 +1193,12 @@ chipset_device_create(struct visor_device *dev_info)
 POSTCODE_SEVERITY_INFO);
 }
 
-static void
+void
 chipset_device_destroy(struct visor_device *dev_info)
 {
remove_visor_device(dev_info);
 
-   if (chipset_responders.device_destroy)
-   (*chipset_responders.device_destroy) (dev_info, 0);
+   device_destroy_response(dev_info, 0);
 }
 
 /**
@@ -1247,14 +1217,8 @@ pause_state_change_complete(struct visor_device *dev, 
int status)
return;
 
dev->pausing = false;
-   if (!chipset_responders.device_pause) /* this can never happen! */
-   return;
 
-   /* Notify the chipset driver that the pause is complete, which
-* will presumably want to send some sort of response to the
-* initiator.
-*/
-   (*chipset_responders.device_pause) (dev, status);
+   visorchipset_device_pause_response(dev, status);
 }
 
 /**
@@ -1273,15 +1237,13 @@ 

[PATCH v4 05/29] staging: unisys: visorbus: modify format string to match argument

[David Kershner]

From: David Binder 

Modifies the format string of snprintf to expect an unsigned int
instead of a signed one, per the supplied argument.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 08d560c..756df41 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -433,7 +433,7 @@ static ssize_t client_bus_info_show(struct device *dev,
if (vdev->name)
partition_name = vdev->name;
shift = snprintf(pos, remain,
-"Client device / client driver info for %s 
eartition (vbus #%d):\n",
+"Client device / client driver info for %s 
eartition (vbus #%u):\n",
 partition_name, vdev->chipset_dev_no);
pos += shift;
remain -= shift;
-- 
1.9.1

[PATCH] pinctrl: Always recurse into bcm folder

[Florian Fainelli]

drivers/pinctrl/bcm/Makefile properly builds individual drivers based on
their respective Kconfig symbols. ARCH_BCM is currently a menuconfig
option from arch/arm/mach-bcm/Kconfig, which is fine, but prevents ARM64
platforms which do not have such menuconfig option from building their
pinctrl drivers, so let's get rid of that dependency.

Signed-off-by: Florian Fainelli 
---
 drivers/pinctrl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 25ec45090620..8ebd7b8e1621 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -37,7 +37,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
 obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
 
-obj-$(CONFIG_ARCH_BCM) += bcm/
+obj-y  += bcm/
 obj-$(CONFIG_PINCTRL_BERLIN)   += berlin/
 obj-y  += freescale/
 obj-$(CONFIG_X86)  += intel/
-- 
2.7.4

[PATCH] LSM: module hierarchy in /proc/.../attr

[Casey Schaufler]

Subject: [PATCH] LSM: module hierarchy in /proc/.../attr

Back in 2007 I made what turned out to be a rather serious
mistake in the implementation of the Smack security module.
The SELinux module used an interface in /proc to manipulate
the security context on processes. Rather than use a similar
interface, I used the same interface. The AppArmor team did
likewise. Now /proc/.../attr/current will tell you the
security "context" of the process, but it will be different
depending on the security module you're using. That hasn't
been a problem to date, as you can only have one module
that supports process attributes at a time. We are coming
up on a change to that, where multiple modules with process
attributes can be supported. (Not included here)

This patch provides a subdirectory in /proc/.../attr for
each of the security modules that use the LSM hooks
getprocattr() and setprocattr(). Each of the interfaces
used by a module are presented in the subdirectory. The
old interfaces remain and work the same as before.
User space code can begin migrating to the subdirectory
interfaces in anticipation of the time when what comes
from /proc/self/attr/current might not be what a runtime
wants.

Also looking ahead, the attr directory and each of its
subdirectories provides a "context" interface. The data
provided is the same as the "current" interface in each
of the subdirectories, except that it is formatted to
identify the module it comes from. The format is:

lsmname='context-value'

When multiple concurrent modules are supported the
/proc/.../attr/context interface will include the data
for all of the active modules.

Finally, I got tired of having to find indirect ways to
determine what security modules are active on a system.
I have added /sys/kernel/security/lsm, which contains a
comma separated list of the active security modules. No
more groping around in /proc/filesystems, which won't
help if the module doesn't support its own filesystem.

The original implementation is by Kees Cook. The code
has been changed a bit to reflect changes in the direction
of the multiple concurrent module work, to be independent
of it, and to bring it up to date with the current tree.

Signed-off-by: Casey Schaufler 

---
 Documentation/security/LSM.txt |  26 +--
 fs/proc/base.c |  95 ---
 fs/proc/internal.h |   1 +
 include/linux/lsm_hooks.h  |  19 ++---
 include/linux/security.h   |  15 ++--
 security/apparmor/lsm.c|  45 ---
 security/commoncap.c   |   3 +-
 security/inode.c   |  26 ++-
 security/security.c| 166 -
 security/selinux/hooks.c   |  28 +--
 security/smack/smack_lsm.c |  28 ---
 security/tomoyo/tomoyo.c   |   2 +-
 security/yama/yama_lsm.c   |   2 +-
 13 files changed, 391 insertions(+), 65 deletions(-)

diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
index 3db7e67..125c489 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/security/LSM.txt
@@ -16,11 +16,25 @@ MAC extensions, other extensions can be built using the LSM 
to provide
 specific changes to system operation when these tweaks are not available
 in the core functionality of Linux itself.
 
-Without a specific LSM built into the kernel, the default LSM will be the
-Linux capabilities system. Most LSMs choose to extend the capabilities
-system, building their checks on top of the defined capability hooks.
-For more details on capabilities, see capabilities(7) in the Linux
-man-pages project.
+The Linux capabilities modules will always be included. For more details
+on capabilities, see capabilities(7) in the Linux man-pages project.
+This may be followed by any number of "minor" modules and at most one
+"major" module.
+
+A list of the active security modules can be found by reading
+/sys/kernel/security/lsm. This is a comma separated list, and
+will always include the capability module. The list reflects the
+order in which checks are made. The capability module will always
+be first, followed by any "minor" modules (e.g. Yama) and then
+the one "major" module (e.g. SELinux) if there is one configured.
+
+Process attributes associated with "major" security modules should
+be accessed and maintained using the special files in the module
+specific subdirectories in /proc/.../attr. The attributes related
+to Smack would be found in /proc/.../attr/smack while the attributes
+for SELinux would be in /proc/.../attr/selinux. Using the files
+found directly in /proc/.../attr (e.g. current) should be avoided.
+These files remain as legacy interfaces.
 
 Based on https://lkml.org/lkml/2007/10/26/215,
 a new LSM is accepted into the kernel when its intent (a description of
@@ -31,4 +45,4 @@ that end users and distros can make a more informed decision 
about which
 LSMs suit their requirements.
 
 For extensive 

[PATCH] aic7xxx: fix wrong return values

[Luis de Bethencourt]

Convention of error codes says to return them as negative values.

Signed-off-by: Luis de Bethencourt 
---
 drivers/scsi/aic7xxx/aic7770_osm.c |  6 +++---
 drivers/scsi/aic7xxx/aic79xx_core.c| 24 
 drivers/scsi/aic7xxx/aic79xx_osm.c |  8 
 drivers/scsi/aic7xxx/aic79xx_osm_pci.c | 16 
 drivers/scsi/aic7xxx/aic79xx_pci.c |  2 +-
 drivers/scsi/aic7xxx/aic7xxx_core.c| 26 +-
 drivers/scsi/aic7xxx/aic7xxx_osm.c |  8 
 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c | 12 ++--
 drivers/scsi/aic7xxx/aic7xxx_pci.c |  4 ++--
 9 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/drivers/scsi/aic7xxx/aic7770_osm.c 
b/drivers/scsi/aic7xxx/aic7770_osm.c
index 3d401d0..50f030d 100644
--- a/drivers/scsi/aic7xxx/aic7770_osm.c
+++ b/drivers/scsi/aic7xxx/aic7770_osm.c
@@ -51,7 +51,7 @@ aic7770_map_registers(struct ahc_softc *ahc, u_int port)
 * Lock out other contenders for our i/o space.
 */
if (!request_region(port, AHC_EISA_IOSIZE, "aic7xxx"))
-   return (ENOMEM);
+   return -ENOMEM;
ahc->tag = BUS_SPACE_PIO;
ahc->bsh.ioport = port;
return (0);
@@ -87,10 +87,10 @@ aic7770_probe(struct device *dev)
sprintf(buf, "ahc_eisa:%d", eisaBase >> 12);
name = kstrdup(buf, GFP_ATOMIC);
if (name == NULL)
-   return (ENOMEM);
+   return -ENOMEM;
ahc = ahc_alloc(_driver_template, name);
if (ahc == NULL)
-   return (ENOMEM);
+   return -ENOMEM;
error = aic7770_config(ahc, aic7770_ident_table + edev->id.driver_data,
   eisaBase);
if (error != 0) {
diff --git a/drivers/scsi/aic7xxx/aic79xx_core.c 
b/drivers/scsi/aic7xxx/aic79xx_core.c
index 109e2c9..bf850d8 100644
--- a/drivers/scsi/aic7xxx/aic79xx_core.c
+++ b/drivers/scsi/aic7xxx/aic79xx_core.c
@@ -6422,7 +6422,7 @@ ahd_init_scbdata(struct ahd_softc *ahd)
scb_data->maxhscbs = ahd_probe_scbs(ahd);
if (scb_data->maxhscbs == 0) {
printk("%s: No SCB space found\n", ahd_name(ahd));
-   return (ENXIO);
+   return -ENXIO;
}
 
ahd_initialize_hscbs(ahd);
@@ -6501,7 +6501,7 @@ ahd_init_scbdata(struct ahd_softc *ahd)
 
 error_exit:
 
-   return (ENOMEM);
+   return -ENOMEM;
 }
 
 static struct scb *
@@ -7076,7 +7076,7 @@ ahd_init(struct ahd_softc *ahd)
ahd->stack_size = ahd_probe_stack_size(ahd);
ahd->saved_stack = kmalloc(ahd->stack_size * sizeof(uint16_t), 
GFP_ATOMIC);
if (ahd->saved_stack == NULL)
-   return (ENOMEM);
+   return -ENOMEM;
 
/*
 * Verify that the compiler hasn't over-aggressively
@@ -7115,7 +7115,7 @@ ahd_init(struct ahd_softc *ahd)
   /*maxsegsz*/AHD_MAXTRANSFER_SIZE,
   /*flags*/BUS_DMA_ALLOCNOW,
   >buffer_dmat) != 0) {
-   return (ENOMEM);
+   return -ENOMEM;
}
 #endif
 
@@ -7143,7 +7143,7 @@ ahd_init(struct ahd_softc *ahd)
   /*nsegments*/1,
   /*maxsegsz*/BUS_SPACE_MAXSIZE_32BIT,
   /*flags*/0, >shared_data_dmat) != 0) {
-   return (ENOMEM);
+   return -ENOMEM;
}
 
ahd->init_level++;
@@ -7153,7 +7153,7 @@ ahd_init(struct ahd_softc *ahd)
 (void **)>shared_data_map.vaddr,
 BUS_DMA_NOWAIT,
 >shared_data_map.dmamap) != 0) {
-   return (ENOMEM);
+   return -ENOMEM;
}
 
ahd->init_level++;
@@ -7194,7 +7194,7 @@ ahd_init(struct ahd_softc *ahd)
 
/* Allocate SCB data now that buffer_dmat is initialized */
if (ahd_init_scbdata(ahd) != 0)
-   return (ENOMEM);
+   return -ENOMEM;
 
if ((ahd->flags & AHD_INITIATORROLE) == 0)
ahd->flags &= ~AHD_RESET_BUS_A;
@@ -7644,7 +7644,7 @@ ahd_default_config(struct ahd_softc *ahd)
if (ahd_alloc_tstate(ahd, ahd->our_id, 'A') == NULL) {
printk("%s: unable to allocate ahd_tmode_tstate.  "
   "Failing attach\n", ahd_name(ahd));
-   return (ENOMEM);
+   return -ENOMEM;
}
 
for (targ = 0; targ < AHD_NUM_TARGETS; targ++) {
@@ -7723,7 +7723,7 @@ ahd_parse_cfgdata(struct ahd_softc *ahd, struct 
seeprom_config *sc)
if (ahd_alloc_tstate(ahd, ahd->our_id, 'A') == NULL) {
printk("%s: unable to allocate ahd_tmode_tstate.  "
   "Failing attach\n", ahd_name(ahd));
-   return (ENOMEM);
+   return -ENOMEM;
}
 
for (targ = 0; targ < max_targ; targ++) {
@@ -7967,7 +7967,7 @@ ahd_suspend(struct 

Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support

[Mark Brown]

On Wed, Jun 08, 2016 at 10:48:23PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 8, 2016 at 8:35 PM, Mark Brown  wrote:

> > A parent (especially a MFD) may create a child to fulfil a role that
> > could also be filled by a non-parent device, if that happens then
> > depending on what ends up creating these links (it's not 100% clear from
> > this series) it's likely that the link creation will also end up
> > registering a dependency unless we do something special.  Now I think
> > about it this does depend on how we create the children though, it's
> > less likely to be an issue if the dependencies are created by firmware
> > code.

> If that's a non-child device, I would expect it to exist beforehand

No, it's an actual child.


signature.asc
Description: PGP signature

[PATCH v3 3/7] powerpc: use the new LED disk activity trigger

[Stephan Linz]

- dts: rename 'ide-disk' to 'disk-activity'
- defconfig: rename 'ADB_PMU_LED_IDE' to 'ADB_PMU_LED_DISK'

Cc: Joseph Jezak 
Cc: Nico Macrionitis 
Cc: Jörg Sommer 
Signed-off-by: Stephan Linz 
---
 arch/powerpc/boot/dts/mpc8315erdb.dts |  2 +-
 arch/powerpc/boot/dts/mpc8377_rdb.dts |  2 +-
 arch/powerpc/boot/dts/mpc8378_rdb.dts |  2 +-
 arch/powerpc/boot/dts/mpc8379_rdb.dts |  2 +-
 arch/powerpc/configs/pmac32_defconfig |  2 +-
 arch/powerpc/configs/ppc6xx_defconfig |  2 +-
 drivers/macintosh/Kconfig | 13 ++---
 drivers/macintosh/via-pmu-led.c   |  4 ++--
 8 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts 
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 4354684..ca5139e 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -472,7 +472,7 @@
 
hdd {
gpios = <_pio 1 0>;
-   linux,default-trigger = "ide-disk";
+   linux,default-trigger = "disk-activity";
};
};
 };
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts 
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 2b4b653..e326139 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -496,7 +496,7 @@
 
hdd {
gpios = <_pio 1 0>;
-   linux,default-trigger = "ide-disk";
+   linux,default-trigger = "disk-activity";
};
};
 };
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts 
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 74b6a53..71842fc 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -480,7 +480,7 @@
 
hdd {
gpios = <_pio 1 0>;
-   linux,default-trigger = "ide-disk";
+   linux,default-trigger = "disk-activity";
};
};
 };
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts 
b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index 3b5cbac..e442a29 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -446,7 +446,7 @@
 
hdd {
gpios = <_pio 1 0>;
-   linux,default-trigger = "ide-disk";
+   linux,default-trigger = "disk-activity";
};
};
 };
diff --git a/arch/powerpc/configs/pmac32_defconfig 
b/arch/powerpc/configs/pmac32_defconfig
index ea8705f..3f6c9a6 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -158,7 +158,7 @@ CONFIG_ADB=y
 CONFIG_ADB_CUDA=y
 CONFIG_ADB_PMU=y
 CONFIG_ADB_PMU_LED=y
-CONFIG_ADB_PMU_LED_IDE=y
+CONFIG_ADB_PMU_LED_DISK=y
 CONFIG_PMAC_APM_EMU=m
 CONFIG_PMAC_MEDIABAY=y
 CONFIG_PMAC_BACKLIGHT=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig 
b/arch/powerpc/configs/ppc6xx_defconfig
index 99ccbeba..1dde0be 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -442,7 +442,7 @@ CONFIG_ADB=y
 CONFIG_ADB_CUDA=y
 CONFIG_ADB_PMU=y
 CONFIG_ADB_PMU_LED=y
-CONFIG_ADB_PMU_LED_IDE=y
+CONFIG_ADB_PMU_LED_DISK=y
 CONFIG_PMAC_APM_EMU=y
 CONFIG_PMAC_MEDIABAY=y
 CONFIG_PMAC_BACKLIGHT=y
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 3e8b29e..d28690f 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -96,19 +96,18 @@ config ADB_PMU_LED
  Support the front LED on Power/iBooks as a generic LED that can
  be triggered by any of the supported triggers. To get the
  behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this
- and the ide-disk LED trigger and configure appropriately through
- sysfs.
+ and the disk LED trigger and configure appropriately through sysfs.
 
-config ADB_PMU_LED_IDE
-   bool "Use front LED as IDE LED by default"
+config ADB_PMU_LED_DISK
+   bool "Use front LED as DISK LED by default"
depends on ADB_PMU_LED
depends on LEDS_CLASS
depends on IDE_GD_ATA
select LEDS_TRIGGERS
-   select LEDS_TRIGGER_IDE_DISK
+   select LEDS_TRIGGER_DISK
help
- This option makes the front LED default to the IDE trigger
- so that it blinks on IDE activity.
+ This option makes the front LED default to the disk trigger
+ so that it blinks on disk activity.
 
 config PMAC_SMU
bool "Support for SMU  based PowerMacs"
diff --git a/drivers/macintosh/via-pmu-led.c b/drivers/macintosh/via-pmu-led.c
index 19c3718..ae067ab 100644
--- a/drivers/macintosh/via-pmu-led.c
+++ b/drivers/macintosh/via-pmu-led.c
@@ -73,8 +73,8 @@ static void pmu_led_set(struct led_classdev *led_cdev,
 
 static struct led_classdev pmu_led = {
.name = "pmu-led::front",
-#ifdef 

[PATCH v3 2/7] leds: documentation: 'ide-disk' to 'disk-activity'

[Stephan Linz]

Cc: Joseph Jezak 
Cc: Nico Macrionitis 
Cc: Jörg Sommer 
Signed-off-by: Stephan Linz 
---
 Documentation/devicetree/bindings/leds/common.txt| 2 +-
 Documentation/devicetree/bindings/leds/leds-gpio.txt | 2 +-
 Documentation/laptops/asus-laptop.txt| 2 +-
 Documentation/leds/leds-class.txt| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index af10678..1e97169 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -26,7 +26,7 @@ Optional properties for child nodes:
  "default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/gpio/led.txt)
  "heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
+ "disk-activity" - LED indicates disk activity
  "timer" - LED flashes at a fixed, configurable rate
 
 - led-max-microamp : Maximum LED supply current in microamperes. This property
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt 
b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index cbbeb18..e166053 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -35,7 +35,7 @@ leds {
hdd {
label = "IDE Activity";
gpios = <_pio 0 GPIO_ACTIVE_LOW>;
-   linux,default-trigger = "ide-disk";
+   linux,default-trigger = "disk-activity";
};
 
fault {
diff --git a/Documentation/laptops/asus-laptop.txt 
b/Documentation/laptops/asus-laptop.txt
index 79a1bc6..5f28587 100644
--- a/Documentation/laptops/asus-laptop.txt
+++ b/Documentation/laptops/asus-laptop.txt
@@ -72,7 +72,7 @@ LEDs
 echo 1 >  /sys/class/leds/asus::mail/brightness
   will switch the mail LED on.
   You can also know if they are on/off by reading their content and use
-  kernel triggers like ide-disk or heartbeat.
+  kernel triggers like disk-activity or heartbeat.
 
 Backlight
 -
diff --git a/Documentation/leds/leds-class.txt 
b/Documentation/leds/leds-class.txt
index d406d98..44c1bcf 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero 
brightness settings.
 The class also introduces the optional concept of an LED trigger. A trigger
 is a kernel based source of led events. Triggers can either be simple or
 complex. A simple trigger isn't configurable and is designed to slot into
-existing subsystems with minimal additional code. Examples are the ide-disk,
+existing subsystems with minimal additional code. Examples are the 
disk-activity,
 nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
 optimises away.
 
-- 
2.8.4

[PATCH v3 6/7] parisc: use the new LED disk activity trigger

[Stephan Linz]

- platform: rename 'ide-disk' to 'disk-activity'

Signed-off-by: Stephan Linz 
---
 arch/parisc/configs/generic-32bit_defconfig | 2 +-
 arch/parisc/configs/generic-64bit_defconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/parisc/configs/generic-32bit_defconfig 
b/arch/parisc/configs/generic-32bit_defconfig
index 5b04d70..8688ba7 100644
--- a/arch/parisc/configs/generic-32bit_defconfig
+++ b/arch/parisc/configs/generic-32bit_defconfig
@@ -214,7 +214,7 @@ CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
-CONFIG_LEDS_TRIGGER_IDE_DISK=y
+CONFIG_LEDS_TRIGGER_DISK=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
 CONFIG_DMADEVICES=y
diff --git a/arch/parisc/configs/generic-64bit_defconfig 
b/arch/parisc/configs/generic-64bit_defconfig
index e945c08..7e07926 100644
--- a/arch/parisc/configs/generic-64bit_defconfig
+++ b/arch/parisc/configs/generic-64bit_defconfig
@@ -231,7 +231,7 @@ CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_ONESHOT=y
-CONFIG_LEDS_TRIGGER_IDE_DISK=y
+CONFIG_LEDS_TRIGGER_DISK=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=m
 CONFIG_LEDS_TRIGGER_BACKLIGHT=m
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=m
-- 
2.8.4

[PATCH v3 1/7] leds: convert IDE trigger to common disk trigger

[Stephan Linz]

This patch converts the IDE specific LED trigger to a generic disk
activity LED trigger. The libata core is now a trigger source just
like before the IDE disk driver. It's merely a replacement of the
string ide by disk.

The patch is taken from http://dev.gentoo.org/~josejx/ata.patch and is
widely used by any ibook/powerbook owners with great satisfaction.
Likewise, it is very often used successfully on different ARM platforms.

The original patch was split into different parts to clarify platform
independent and dependent changes.

Cc: Joseph Jezak 
Cc: Nico Macrionitis 
Cc: Jörg Sommer 
Cc: Richard Purdie 
Cc: Jacek Anaszewski 
Signed-off-by: Stephan Linz 
---
Changes in v3:
  - Port to kernel 4.x
  - Split into platform independent and dependent parts.

v2: https://patchwork.ozlabs.org/patch/117485/
v1: http://dev.gentoo.org/~josejx/ata.patch
---
 drivers/ata/libata-core.c|  4 
 drivers/ide/ide-disk.c   |  2 +-
 drivers/leds/leds-hp6xx.c|  2 +-
 drivers/leds/trigger/Kconfig |  8 
 drivers/leds/trigger/Makefile|  2 +-
 .../trigger/{ledtrig-ide-disk.c => ledtrig-disk.c}   | 20 ++--
 include/linux/leds.h |  6 +++---
 7 files changed, 24 insertions(+), 20 deletions(-)
 rename drivers/leds/trigger/{ledtrig-ide-disk.c => ledtrig-disk.c} (50%)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 6be7770..2eca572 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -69,6 +69,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -5072,6 +5073,9 @@ void ata_qc_complete(struct ata_queued_cmd *qc)
 {
struct ata_port *ap = qc->ap;
 
+   /* Trigger the LED (if available) */
+   ledtrig_disk_activity();
+
/* XXX: New EH and old EH use different mechanisms to
 * synchronize EH with regular execution path.
 *
diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
index 05dbcce..5ceb176 100644
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -186,7 +186,7 @@ static ide_startstop_t ide_do_rw_disk(ide_drive_t *drive, 
struct request *rq,
BUG_ON(drive->dev_flags & IDE_DFLAG_BLOCKED);
BUG_ON(rq->cmd_type != REQ_TYPE_FS);
 
-   ledtrig_ide_activity();
+   ledtrig_disk_activity();
 
pr_debug("%s: %sing: block=%llu, sectors=%u\n",
 drive->name, rq_data_dir(rq) == READ ? "read" : "writ",
diff --git a/drivers/leds/leds-hp6xx.c b/drivers/leds/leds-hp6xx.c
index a6b8db0..137969f 100644
--- a/drivers/leds/leds-hp6xx.c
+++ b/drivers/leds/leds-hp6xx.c
@@ -50,7 +50,7 @@ static struct led_classdev hp6xx_red_led = {
 
 static struct led_classdev hp6xx_green_led = {
.name   = "hp6xx:green",
-   .default_trigger= "ide-disk",
+   .default_trigger= "disk-activity",
.brightness_set = hp6xxled_green_set,
.flags  = LED_CORE_SUSPENDRESUME,
 };
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 9893d91..3f9ddb9 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -33,12 +33,12 @@ config LEDS_TRIGGER_ONESHOT
 
  If unsure, say Y.
 
-config LEDS_TRIGGER_IDE_DISK
-   bool "LED IDE Disk Trigger"
-   depends on IDE_GD_ATA
+config LEDS_TRIGGER_DISK
+   bool "LED Disk Trigger"
+   depends on IDE_GD_ATA || ATA
depends on LEDS_TRIGGERS
help
- This allows LEDs to be controlled by IDE disk activity.
+ This allows LEDs to be controlled by disk activity.
  If unsure, say Y.
 
 config LEDS_TRIGGER_MTD
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 8cc64a4..a72c43c 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_LEDS_TRIGGER_TIMER)   += ledtrig-timer.o
 obj-$(CONFIG_LEDS_TRIGGER_ONESHOT) += ledtrig-oneshot.o
-obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
+obj-$(CONFIG_LEDS_TRIGGER_DISK)+= ledtrig-disk.o
 obj-$(CONFIG_LEDS_TRIGGER_MTD) += ledtrig-mtd.o
 obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT)   += ledtrig-heartbeat.o
 obj-$(CONFIG_LEDS_TRIGGER_BACKLIGHT)   += ledtrig-backlight.o
diff --git a/drivers/leds/trigger/ledtrig-ide-disk.c 
b/drivers/leds/trigger/ledtrig-disk.c
similarity index 50%
rename from drivers/leds/trigger/ledtrig-ide-disk.c
rename to drivers/leds/trigger/ledtrig-disk.c
index 15123d3..7a1fe44 100644
--- a/drivers/leds/trigger/ledtrig-ide-disk.c
+++ b/drivers/leds/trigger/ledtrig-disk.c
@@ -1,5 +1,5 @@
 /*
- * LED IDE-Disk Activity Trigger
+ * LED Disk Activity Trigger
  *
  * Copyright 2006 Openedhand Ltd.
  *
@@ -17,20 +17,20 @@
 
 

[PATCH v3 7/7] unicore32: use the new LED disk activity trigger

[Stephan Linz]

- platform: rename 'ide-disk' to 'disk-activity'
- defconfig: rename 'LEDS_TRIGGER_IDE_DISK' to 'LEDS_TRIGGER_DISK'

Signed-off-by: Stephan Linz 
---
 arch/unicore32/configs/unicore32_defconfig | 2 +-
 arch/unicore32/kernel/gpio.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/unicore32/configs/unicore32_defconfig 
b/arch/unicore32/configs/unicore32_defconfig
index 45f47f8..aebd01f 100644
--- a/arch/unicore32/configs/unicore32_defconfig
+++ b/arch/unicore32/configs/unicore32_defconfig
@@ -161,7 +161,7 @@ CONFIG_LEDS_GPIO=y
 #  LED Triggers
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
-CONFIG_LEDS_TRIGGER_IDE_DISK=y
+CONFIG_LEDS_TRIGGER_DISK=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 
 #  Real Time Clock
diff --git a/arch/unicore32/kernel/gpio.c b/arch/unicore32/kernel/gpio.c
index 49347a0..bf164bb 100644
--- a/arch/unicore32/kernel/gpio.c
+++ b/arch/unicore32/kernel/gpio.c
@@ -27,7 +27,7 @@ static const struct gpio_led puv3_gpio_leds[] = {
{ .name = "cpuhealth", .gpio = GPO_CPU_HEALTH, .active_low = 0,
.default_trigger = "heartbeat", },
{ .name = "hdd_led", .gpio = GPO_HDD_LED, .active_low = 1,
-   .default_trigger = "ide-disk", },
+   .default_trigger = "disk-activity", },
 };
 
 static const struct gpio_led_platform_data puv3_gpio_led_data = {
-- 
2.8.4

Re: [PATCH 2/2] staging: lustre: lnet: Replace semaphore ln_rc_signal with completion

[James Simmons]

> The semaphore ln_rc_signal is used as completion, so convert it to
> struct completion.  Semaphores are going away in the future.
> 
> Signed-off-by: Binoy Jayan 

No problems in testing.

Acked-by: James Simmons 

> ---
>  drivers/staging/lustre/include/linux/lnet/lib-types.h | 3 ++-
>  drivers/staging/lustre/lnet/lnet/router.c | 9 +
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h 
> b/drivers/staging/lustre/include/linux/lnet/lib-types.h
> index 24c4a08..7967b01 100644
> --- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
> +++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "types.h"
>  #include "lnetctl.h"
> @@ -610,7 +611,7 @@ typedef struct {
>   /* rcd ready for free */
>   struct list_head  ln_rcd_zombie;
>   /* serialise startup/shutdown */
> - struct semaphore  ln_rc_signal;
> + struct completion ln_rc_signal;
>  
>   struct mutex  ln_api_mutex;
>   struct mutex  ln_lnd_mutex;
> diff --git a/drivers/staging/lustre/lnet/lnet/router.c 
> b/drivers/staging/lustre/lnet/lnet/router.c
> index b01dc42..0635432 100644
> --- a/drivers/staging/lustre/lnet/lnet/router.c
> +++ b/drivers/staging/lustre/lnet/lnet/router.c
> @@ -18,6 +18,7 @@
>   */
>  
>  #define DEBUG_SUBSYSTEM S_LNET
> +#include 
>  #include "../../include/linux/lnet/lib-lnet.h"
>  
>  #define LNET_NRB_TINY_MIN512 /* min value for each CPT */
> @@ -1065,7 +1066,7 @@ lnet_router_checker_start(void)
>   return -EINVAL;
>   }
>  
> - sema_init(_lnet.ln_rc_signal, 0);
> + init_completion(_lnet.ln_rc_signal);
>  
>   rc = LNetEQAlloc(0, lnet_router_checker_event, _lnet.ln_rc_eqh);
>   if (rc) {
> @@ -1079,7 +1080,7 @@ lnet_router_checker_start(void)
>   rc = PTR_ERR(task);
>   CERROR("Can't start router checker thread: %d\n", rc);
>   /* block until event callback signals exit */
> - down(_lnet.ln_rc_signal);
> + wait_for_completion(_lnet.ln_rc_signal);
>   rc = LNetEQFree(the_lnet.ln_rc_eqh);
>   LASSERT(!rc);
>   the_lnet.ln_rc_state = LNET_RC_STATE_SHUTDOWN;
> @@ -1112,7 +1113,7 @@ lnet_router_checker_stop(void)
>   wake_up(_lnet.ln_rc_waitq);
>  
>   /* block until event callback signals exit */
> - down(_lnet.ln_rc_signal);
> + wait_for_completion(_lnet.ln_rc_signal);
>   LASSERT(the_lnet.ln_rc_state == LNET_RC_STATE_SHUTDOWN);
>  
>   rc = LNetEQFree(the_lnet.ln_rc_eqh);
> @@ -1295,7 +1296,7 @@ rescan:
>   lnet_prune_rc_data(1); /* wait for UNLINK */
>  
>   the_lnet.ln_rc_state = LNET_RC_STATE_SHUTDOWN;
> - up(_lnet.ln_rc_signal);
> + complete(_lnet.ln_rc_signal);
>   /* The unlink event callback will signal final completion */
>   return 0;
>  }
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
> 

[PATCH v5 4/4] tpm_tis: Increase ST19NP18 TPM command duration to avoid chip lockup

[Ed Swierk]

The STMicro ST19NP18-TPM sometimes takes much longer to execute
commands than it reports in its capabilities. For example, command 186
(TPM_FlushSpecific) has been observed to take 14560 msec to complete,
far longer than the 3000 msec limit for "short" commands reported by
the chip. The behavior has also been seen with command 101
(TPM_GetCapability).

Worse, when the tpm_tis driver attempts to cancel the current command
(by writing commandReady = 1 to TPM_STS_x), the chip locks up
completely, returning all-1s from all memory-mapped register
reads. The lockup can be cleared only by resetting the system.

The occurrence of this excessive command duration depends on the
sequence of commands preceding it. One sequence is creating at least 2
new keys via TPM_CreateWrapKey, then letting the TPM idle for at least
30 seconds, then loading a key via TPM_LoadKey2. The next
TPM_FlushSpecific occasionally takes tens of seconds to
complete. Another sequence is creating many keys in a row without
pause. The TPM_CreateWrapKey operation gets much slower after the
first few iterations, as one would expect when the pool of precomputed
keys is exhausted. Then after a 35-second pause, the same TPM_LoadKey2
followed by TPM_FlushSpecific sequence triggers the behavior.

Our working theory is that this older TPM sometimes pauses to
precompute keys, which modern chips implement as a background
process. Without access to the chip's implementation details it's
impossible to know whether any commands are immune to being blocked by
this process. So it seems safest to ignore the chip's reported command
durations, and use a value much higher than any observed duration,
like 180 sec (which is the duration this chip reports for "long"
commands).

Signed-off-by: Ed Swierk 
---
 drivers/char/tpm/tpm_tis.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index caf7278..862c502 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -485,6 +485,11 @@ static void tpm_tis_update_timeouts(struct tpm_chip *chip)
chip->vendor.timeout_d = msecs_to_jiffies(TIS_SHORT_TIMEOUT);
chip->vendor.timeout_adjusted = true;
break;
+   case 0x104a: /* STMicro ST19NP18-TPM */
+   chip->vendor.duration[TPM_SHORT] = 180 * HZ;
+   chip->vendor.duration[TPM_MEDIUM] = 180 * HZ;
+   chip->vendor.duration[TPM_LONG] = 180 * HZ;
+   chip->vendor.duration_adjusted = true;
}
 }
 
-- 
1.9.1

[PATCH v5 1/4] tpm_tis: Improve reporting of IO errors

[Ed Swierk]

Mysterious TPM behavior can be difficult to track down through all the
layers of software. Add error messages for conditions that should
never happen. Also include the manufacturer ID along with other chip
data printed during init.

Signed-off-by: Ed Swierk 
Reviewed-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_tis.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 65f7eec..088fa86 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -299,6 +299,8 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, 
size_t count)
 
expected = be32_to_cpu(*(__be32 *) (buf + 2));
if (expected > count) {
+   dev_err(chip->pdev, "Response too long (wanted %zd, got %d)\n",
+   count, expected);
size = -EIO;
goto out;
}
@@ -366,6 +368,8 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
  >vendor.int_queue, false);
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
+   dev_err(chip->pdev, "Chip not accepting %zd bytes\n",
+   len - count);
rc = -EIO;
goto out_err;
}
@@ -378,6 +382,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 
*buf, size_t len)
  >vendor.int_queue, false);
status = tpm_tis_status(chip);
if ((status & TPM_STS_DATA_EXPECT) != 0) {
+   dev_err(chip->pdev, "Chip not accepting last byte\n");
rc = -EIO;
goto out_err;
}
@@ -689,8 +694,9 @@ static int tpm_tis_init(struct device *dev, struct tpm_info 
*tpm_info,
vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
chip->vendor.manufacturer_id = vendor;
 
-   dev_info(dev, "%s TPM (device-id 0x%X, rev-id %d)\n",
+   dev_info(dev, "%s TPM (manufacturer-id 0x%X, device-id 0x%X, rev-id 
%d)\n",
 (chip->flags & TPM_CHIP_FLAG_TPM2) ? "2.0" : "1.2",
+chip->vendor.manufacturer_id,
 vendor >> 16, ioread8(chip->vendor.iobase + TPM_RID(0)));
 
if (!itpm) {
-- 
1.9.1

Re: [PATCH] ASoC: cs53l30: Correct clock inversion check

[Nicolin Chen]

On Wed, Jun 8, 2016 at 4:03 PM, Nicolin Chen  wrote:
> SND_SOC_DAIFMT_IB_NF = 0x3 (11b) | SND_SOC_DAIFMT_IB_IF = 0x4 (100b)
> creates a mask 0x7 (111b) which also includes SND_SOC_DAIFMT_IB_NF

Oops, here should be NB_IF for (10b). Will send v2. Please ignore this one.

> = 0x2 (10b).
>
> So this patch uses the traditional way to check the clock inversion.
>
> Signed-off-by: Nicolin Chen 
> ---
>  sound/soc/codecs/cs53l30.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/codecs/cs53l30.c b/sound/soc/codecs/cs53l30.c
> index ac90dd7..62daa0c 100644
> --- a/sound/soc/codecs/cs53l30.c
> +++ b/sound/soc/codecs/cs53l30.c
> @@ -598,8 +598,14 @@ static int cs53l30_set_dai_fmt(struct snd_soc_dai *dai, 
> unsigned int fmt)
> }
>
> /* Check to see if the SCLK is inverted */
> -   if (fmt & (SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_IB_IF))
> +   switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
> +   case SND_SOC_DAIFMT_IB_NF:
> +   case SND_SOC_DAIFMT_IB_IF:
> aspcfg ^= CS53L30_ASP_SCLK_INV;
> +   break;
> +   default:
> +   break;
> +   }
>
> regmap_update_bits(priv->regmap, CS53L30_ASPCFG_CTL,
>CS53L30_ASP_MS | CS53L30_ASP_SCLK_INV, aspcfg);
> --
> 2.1.4
>

Re: [PATCH v2 0/2] net: ethernet: ti: cpsw: delete rx_descs property

[Schuyler Patton]

On 06/08/2016 09:06 AM, Ivan Khoronzhuk wrote:



On 08.06.16 17:01, Ivan Khoronzhuk wrote:

Hi Schuyer,

On 07.06.16 18:26, Schuyler Patton wrote:

Hi,

On 06/07/2016 08:59 AM, Ivan Khoronzhuk wrote:

There is no reason in rx_descs property because davinici_cpdma
driver splits pool of descriptors equally between tx and rx channels.
So, this patch series makes driver to use available number of
descriptors for rx channels.


I agree with the idea of consolidating how the descriptors are 
defined because of
the two variable components, number and size of the pool can be 
confusing to
end users. I would like to request to change how it is being 
proposed here.


I think the number of descriptors should be left in the device tree 
source file as
is and remove the BD size variable and have the driver calculate the 
size of the
pool necessary to support the descriptor request. From an user 
perspective it is
easier I think to be able to list the number of descriptors 
necessary vs. the size

of the pool.

Since the patch series points out how it is used so in the driver so 
to make that

consistent is perhaps change rx_descs to total_descs.

Regards,
Schuyler


The DT entry for cpsw doesn't have property for size of the pool.
It contains only BD ram size, if you mean this. The size of the pool is
software decision. Current version of DT entry contain only rx desc 
number.
That is not correct, as it depends on the size of the descriptor, 
which is also
h/w parameter. The DT entry has to describe only h/w part and 
shouldn't contain
driver implementation details, and I'm looking on it from this 
perspective.


Besides, rx_descs describes only rx number of descriptors, that are 
taken from
the same pool as tx descriptors, and setting rx desc to some new 
value doesn't
mean that rest of them are freed for tx. Also, I'm going to send 
series that
adds multi channel support to the driver, and in this case, splitting 
of the
pool will be more sophisticated than now, after what setting those 
parameters
for user (he should do this via device tree) can be even more 
confusing. But,

should -> shouldn't


as it's supposed, it's software decision that shouldn't leak to the DT.


If this rx-desc field is removed how will the number of descriptors be set?

This field has been used to increase the number of descriptors so high
volume short packets are not dropped due to descriptor exhaustion. The 
current
default number of 64 rx descriptors is too low for gigabit networks. 
Some users
have a strong requirement for zero loss of UDP packets setting this 
field to a

larger number and setting the descriptors off-chip was a means to solve
the problem.






Based on master branch

Since v1:
- separate device tree and driver patches
- return number of rx buffers from cpdma driver

Ivan Khoronzhuk (2):
   net: ethernet: ti: cpsw: remove rx_descs property
   Documentation: DT: cpsw: remove rx_descs property

  Documentation/devicetree/bindings/net/cpsw.txt |  1 -
  arch/arm/boot/dts/am33xx.dtsi  |  1 -
  arch/arm/boot/dts/am4372.dtsi  |  1 -
  arch/arm/boot/dts/dm814x.dtsi  |  1 -
  arch/arm/boot/dts/dra7.dtsi|  1 -
  drivers/net/ethernet/ti/cpsw.c | 13 +++--
  drivers/net/ethernet/ti/cpsw.h |  1 -
  drivers/net/ethernet/ti/davinci_cpdma.c|  6 ++
  drivers/net/ethernet/ti/davinci_cpdma.h|  1 +
  9 files changed, 10 insertions(+), 16 deletions(-)

[PATCH v2] ASoC: cs53l30: Correct clock inversion check

[Nicolin Chen]

SND_SOC_DAIFMT_IB_NF = 0x3 (11b) | SND_SOC_DAIFMT_IB_IF = 0x4 (100b)
creates a mask 0x7 (111b) which also includes SND_SOC_DAIFMT_NB_IF
= 0x2 (10b).

So this patch uses the traditional way to check the clock inversion.

Signed-off-by: Nicolin Chen 
---
Changelog:
v1->v2:
 * Correct one typo in the commit log

 sound/soc/codecs/cs53l30.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/cs53l30.c b/sound/soc/codecs/cs53l30.c
index ac90dd7..62daa0c 100644
--- a/sound/soc/codecs/cs53l30.c
+++ b/sound/soc/codecs/cs53l30.c
@@ -598,8 +598,14 @@ static int cs53l30_set_dai_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
}
 
/* Check to see if the SCLK is inverted */
-   if (fmt & (SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_IB_IF))
+   switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+   case SND_SOC_DAIFMT_IB_NF:
+   case SND_SOC_DAIFMT_IB_IF:
aspcfg ^= CS53L30_ASP_SCLK_INV;
+   break;
+   default:
+   break;
+   }
 
regmap_update_bits(priv->regmap, CS53L30_ASPCFG_CTL,
   CS53L30_ASP_MS | CS53L30_ASP_SCLK_INV, aspcfg);
-- 
2.1.4

Re: [PATCH] cpumask: fix code comment

[Rusty Russell]

Geliang Tang  writes:
> Fix code comment for cpumask_parse().
>
> Signed-off-by: Geliang Tang 

Acked-by: Rusty Russell 

(CC'd triv...@kernel.org).

Thanks,
Rusty.

> ---
>  include/linux/cpumask.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index e828cf6..da7fbf1 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -579,7 +579,7 @@ static inline int cpumask_parselist_user(const char 
> __user *buf, int len,
>  }
>  
>  /**
> - * cpumask_parse - extract a cpumask from from a string
> + * cpumask_parse - extract a cpumask from a string
>   * @buf: the buffer to extract from
>   * @dstp: the cpumask to set.
>   *
> -- 
> 1.9.1

[PATCH v2 4/5] freeze: Add error reporting

[dbasehore]

From: Derek Basehore 

This adds error reporting for cpuidle to freeze so suspend-to-idle can
report errors when the CPU/SoC is unable to idle properly. Freeze will
abort when an error is encounted.

Signed-off-by: Derek Basehore 
---
 drivers/acpi/processor_idle.c | 10 ++
 drivers/cpuidle/cpuidle.c | 31 ++-
 drivers/idle/intel_idle.c |  8 +---
 include/linux/cpuidle.h   | 10 ++
 kernel/power/suspend.c| 11 +++
 5 files changed, 50 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 444e374..a959b32 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -783,8 +783,8 @@ static int acpi_idle_enter(struct cpuidle_device *dev,
return index;
 }
 
-static void acpi_idle_enter_freeze(struct cpuidle_device *dev,
-  struct cpuidle_driver *drv, int index)
+static int acpi_idle_enter_freeze(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
 {
struct acpi_processor_cx *cx = per_cpu(acpi_cstate[index], dev->cpu);
 
@@ -792,16 +792,18 @@ static void acpi_idle_enter_freeze(struct cpuidle_device 
*dev,
struct acpi_processor *pr = __this_cpu_read(processors);
 
if (unlikely(!pr))
-   return;
+   return 0;
 
if (pr->flags.bm_check) {
acpi_idle_enter_bm(pr, cx, false);
-   return;
+   return 0;
} else {
ACPI_FLUSH_CPU_CACHE();
}
}
acpi_idle_do_entry(cx);
+
+   return 0;
 }
 
 struct cpuidle_driver acpi_idle_driver = {
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index a4d0059..2664a6c 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -34,6 +34,7 @@ LIST_HEAD(cpuidle_detected_devices);
 static int enabled_devices;
 static int off __read_mostly;
 static int initialized __read_mostly;
+static int cpuidle_freeze_error;
 
 int cpuidle_disabled(void)
 {
@@ -109,9 +110,11 @@ int cpuidle_find_deepest_state(struct cpuidle_driver *drv,
return find_deepest_state(drv, dev, UINT_MAX, 0, false);
 }
 
-static void enter_freeze_proper(struct cpuidle_driver *drv,
+static int enter_freeze_proper(struct cpuidle_driver *drv,
struct cpuidle_device *dev, int index)
 {
+   int ret;
+
/*
 * trace_suspend_resume() called by tick_freeze() for the last CPU
 * executing it contains RCU usage regarded as invalid in the idle
@@ -124,7 +127,7 @@ static void enter_freeze_proper(struct cpuidle_driver *drv,
 * suspended is generally unsafe.
 */
stop_critical_timings();
-   drv->states[index].enter_freeze(dev, drv, index);
+   ret = drv->states[index].enter_freeze(dev, drv, index);
WARN_ON(!irqs_disabled());
/*
 * timekeeping_resume() that will be called by tick_unfreeze() for the
@@ -133,6 +136,7 @@ static void enter_freeze_proper(struct cpuidle_driver *drv,
 */
RCU_NONIDLE(tick_unfreeze());
start_critical_timings();
+   return ret;
 }
 
 /**
@@ -145,7 +149,7 @@ static void enter_freeze_proper(struct cpuidle_driver *drv,
  */
 int cpuidle_enter_freeze(struct cpuidle_driver *drv, struct cpuidle_device 
*dev)
 {
-   int index;
+   int index, ret = 0;
 
/*
 * Find the deepest state with ->enter_freeze present, which guarantees
@@ -153,8 +157,13 @@ int cpuidle_enter_freeze(struct cpuidle_driver *drv, 
struct cpuidle_device *dev)
 * be frozen safely.
 */
index = find_deepest_state(drv, dev, UINT_MAX, 0, true);
-   if (index > 0)
-   enter_freeze_proper(drv, dev, index);
+   if (index >= 0)
+   ret = enter_freeze_proper(drv, dev, index);
+
+   if (ret < 0) {
+   cpuidle_freeze_error = ret;
+   freeze_wake();
+   }
 
return index;
 }
@@ -353,6 +362,18 @@ void cpuidle_resume(void)
mutex_unlock(_lock);
 }
 
+void cpuidle_prepare_freeze(void)
+{
+   cpuidle_freeze_error = 0;
+   cpuidle_resume();
+}
+
+int cpuidle_complete_freeze(void)
+{
+   cpuidle_pause();
+   return cpuidle_freeze_error;
+}
+
 /**
  * cpuidle_enable_device - enables idle PM for a CPU
  * @dev: the CPU
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index c966492..98565de 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -97,8 +97,8 @@ static const struct idle_cpu *icpu;
 static struct cpuidle_device __percpu *intel_idle_cpuidle_devices;
 static int intel_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index);
-static void intel_idle_freeze(struct 

[PATCH v2 1/5] x86: stub out pmc function

[dbasehore]

From: Derek Basehore 

This creates an inline function of intel_pmc_slp_s0_counter_read for
!CONFIG_INTEL_PMC_CORE.

Signed-off-by: Derek Basehore 
---
 arch/x86/include/asm/pmc_core.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pmc_core.h b/arch/x86/include/asm/pmc_core.h
index d4855f1..786e526 100644
--- a/arch/x86/include/asm/pmc_core.h
+++ b/arch/x86/include/asm/pmc_core.h
@@ -22,6 +22,10 @@
 #define _ASM_PMC_CORE_H
 
 /* API to read SLP_S0_RESIDENCY counter */
-int intel_pmc_slp_s0_counter_read(u32 *data);
+#ifdef CONFIG_INTEL_PMC_CORE
+extern int intel_pmc_slp_s0_counter_read(u32 *data);
+#else
+static inline int intel_pmc_slp_s0_counter_read(u32 *data) { return -ENOSYS; }
+#endif
 
 #endif /* _ASM_PMC_CORE_H */
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH 01/10] mm: allow swappiness that prefers anon over file

[Minchan Kim]

On Wed, Jun 08, 2016 at 11:58:12AM -0400, Johannes Weiner wrote:
> On Wed, Jun 08, 2016 at 09:06:32AM +0900, Minchan Kim wrote:
> > On Tue, Jun 07, 2016 at 10:18:18AM -0400, Johannes Weiner wrote:
> > > On Tue, Jun 07, 2016 at 09:25:50AM +0900, Minchan Kim wrote:
> > > > On Mon, Jun 06, 2016 at 03:48:27PM -0400, Johannes Weiner wrote:
> > > > > --- a/Documentation/sysctl/vm.txt
> > > > > +++ b/Documentation/sysctl/vm.txt
> > > > > @@ -771,14 +771,20 @@ with no ill effects: errors and warnings on 
> > > > > these stats are suppressed.)
> > > > >  
> > > > >  swappiness
> > > > >  
> > > > > -This control is used to define how aggressive the kernel will swap
> > > > > -memory pages.  Higher values will increase agressiveness, lower 
> > > > > values
> > > > > -decrease the amount of swap.  A value of 0 instructs the kernel not 
> > > > > to
> > > > > -initiate swap until the amount of free and file-backed pages is less
> > > > > -than the high water mark in a zone.
> > > > > +This control is used to define the relative IO cost of cache misses
> > > > > +between the swap device and the filesystem as a value between 0 and
> > > > > +200. At 100, the VM assumes equal IO cost and will thus apply memory
> > > > > +pressure to the page cache and swap-backed pages equally. At 0, the
> > > > > +kernel will not initiate swap until the amount of free and 
> > > > > file-backed
> > > > > +pages is less than the high watermark in a zone.
> > > > 
> > > > Generally, I agree extending swappiness value good but not sure 200 is
> > > > enough to represent speed gap between file and swap sotrage in every
> > > > cases. - Just nitpick.
> > > 
> > > How so? You can't give swap more weight than 100%. 200 is the maximum
> > > possible value.
> > 
> > In old, swappiness is how agressively reclaim anonymous pages in favour
> > of page cache. But when I read your description and changes about
> > swappiness in vm.txt, esp, *relative IO cost*, I feel you change swappiness
> > define to represent relative IO cost between swap storage and file storage.
> > Then, with that, we could balance anonymous and file LRU with the weight.
> > 
> > For example, let's assume that in-memory swap storage is 10x times faster
> > than slow thumb drive. In that case, IO cost of 5 anonymous pages
> > swapping-in/out is equal to 1 file-backed page-discard/read.
> > 
> > I thought it does make sense because that measuring the speed gab between
> > those storages is easier than selecting vague swappiness tendency.
> > 
> > In terms of such approach, I thought 200 is not enough to show the gab
> > because the gap is started from 100.
> > Isn't it your intention? If so, to me, the description was rather
> > misleading. :(
> 
> The way swappiness works never actually changed.
> 
> The only thing that changed is that we used to look at referenced
> pages (recent_rotated) and *assumed* they would likely cause IO when
> reclaimed, whereas with my patches we actually know whether they are.
> But swappiness has always been about relative IO cost of the LRUs.
> 
> Swappiness defines relative IO cost between file and swap on a scale
> from 0 to 200, where 100 is the point of equality. The scale factors
> are calculated in get_scan_count() like this:
> 
>   anon_prio = swappiness
>   file_prio = 200 - swappiness
> 
> and those are applied to the recorded cost/value ratios like this:
> 
>   ap = anon_prio * scanned / rotated
>   fp = file_prio * scanned / rotated
> 
> That means if your swap device is 10 times faster than your filesystem
> device, and you thus want anon to receive 10x the refaults when the
> anon and file pages are used equally, you do this:
> 
>   x + 10x = 200
> x = 18 (ish)
> 
> So your file priority is ~18 and your swap priority is the remainder
> of the range, 200 - 18. You set swappiness to 182.
> 
> Now fill in the numbers while assuming all pages on both lists have
> been referenced before and will likely refault (or in the new model,
> all pages are refaulting):
> 
>   fraction[anon] = ap  = 182 * 1 / 1 = 182
>   fraction[file] = fp  =  18 * 1 / 1 =  18
>  denominator = ap + fp =182 + 18 = 200
> 
> and then calculate the scan target like this:
> 
>   scan[type] = (lru_size() >> priority) * fraction[type] / denominator
> 
> This will scan and reclaim 9% of the file pages and 90% of the anon
> pages. On refault, 9% of the IO will be from the filesystem and 90%
> from the swap device.

Thanks for the detail example. Then, let's change the example a little bit.

A system has big HDD storage and SSD swap.

HDD:200 IOPS
SSD: 10 IOPS
>From https://en.wikipedia.org/wiki/IOPS

So, speed gap is 500x.
x + 500x = 200
If we use PCIe-SSD, the gap will be larger.
That's why I said 200 is enough to represent speed gap.
Such system configuration is already non-sense so it is okay to ignore such
usecases?

mmotm 2016-06-08-15-25 uploaded

[akpm]

The mm-of-the-moment snapshot 2016-06-08-15-25 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.7-rc2:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
* tree-wide-get-rid-of-__gfp_repeat-for-order-0-allocations-part-i.patch
* x86-get-rid-of-superfluous-__gfp_repeat.patch
* x86-efi-get-rid-of-superfluous-__gfp_repeat.patch
* arm-get-rid-of-superfluous-__gfp_repeat.patch
* arm64-get-rid-of-superfluous-__gfp_repeat.patch
* arc-get-rid-of-superfluous-__gfp_repeat.patch
* mips-get-rid-of-superfluous-__gfp_repeat.patch
* nios2-get-rid-of-superfluous-__gfp_repeat.patch
* parisc-get-rid-of-superfluous-__gfp_repeat.patch
* score-get-rid-of-superfluous-__gfp_repeat.patch
* powerpc-get-rid-of-superfluous-__gfp_repeat.patch
* sparc-get-rid-of-superfluous-__gfp_repeat.patch
* s390-get-rid-of-superfluous-__gfp_repeat.patch
* sh-get-rid-of-superfluous-__gfp_repeat.patch
* tile-get-rid-of-superfluous-__gfp_repeat.patch
* unicore32-get-rid-of-superfluous-__gfp_repeat.patch
* jbd2-get-rid-of-superfluous-__gfp_repeat.patch
* mm-hugetlb-fix-huge-page-reserve-accounting-for-private-mappings.patch
* kasan-change-memory-hot-add-error-messages-to-info-messages.patch
* mmoom_reaper-dont-call-mmput_async-without-atomic_inc_not_zero.patch
* revert-mm-memcontrol-fix-possible-css-ref-leak-on-oom.patch
* thp-broken-page-count-after-commit-aa88b68c.patch
* relay-fix-potential-memory-leak.patch
* mm-introduce-dedicated-wq_mem_reclaim-workqueue-to-do-lru_add_drain_all.patch
* mm-do-not-discard-partial-pages-with-posix_fadv_dontneed.patch
* oom_reaper-avoid-pointless-atomic_inc_not_zero-usage.patch
* selftests-vm-compaction_test-fix-write-to-restore-nr_hugepages.patch
* tmpfs-dont-undo-fallocate-past-its-last-page.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch
* ocfs2-fix-a-redundant-re-initialization.patch
* ocfs2-insure-dlm-lockspace-is-created-by-kernel-module.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
  mm.patch
* mm-reorganize-slab-freelist-randomization.patch
* mm-reorganize-slab-freelist-randomization-fix.patch
* mm-slub-freelist-randomization.patch
* mm-memcontrol-remove-the-useless-parameter-for-mc_handle_swap_pte.patch
* mm-init-fix-zone-boundary-creation.patch
* memory-hotplug-add-move_pfn_range.patch
* memory-hotplug-more-general-validation-of-zone-during-online.patch
* memory-hotplug-use-zone_can_shift-for-sysfs-valid_zones-attribute.patch
* mm-zap-zone_oom_locked.patch
* mm-oom-add-memcg-to-oom_control.patch
* 

Re: [PATCH] LSM: module hierarchy in /proc/.../attr

[kbuild test robot]

Hi,

[auto build test WARNING on security/next]
[also build test WARNING on v4.7-rc2 next-20160608]
[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/Casey-Schaufler/LSM-module-hierarchy-in-proc-attr/20160609-055140
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   lib/crc32.c:148: warning: No description found for parameter 'tab)[256]'
   lib/crc32.c:148: warning: Excess function parameter 'tab' description in 
'crc32_le_generic'
   lib/crc32.c:293: warning: No description found for parameter 'tab)[256]'
   lib/crc32.c:293: warning: Excess function parameter 'tab' description in 
'crc32_be_generic'
   lib/crc32.c:1: warning: no structured comments found
   mm/memory.c:2881: warning: No description found for parameter 'old'
>> security/security.c:127: warning: No description found for parameter 'hooks'
>> security/security.c:127: warning: No description found for parameter 'count'
>> security/security.c:127: warning: No description found for parameter 'lsm'

vim +/hooks +127 security/security.c

   111   * Otherwise, return false.
   112   */
   113  int __init security_module_enable(const char *module)
   114  {
   115  return !strcmp(module, chosen_lsm);
   116  }
   117  
   118  /**
   119   * security_add_hooks - Add a modules hooks to the hook lists.
   120   * @hooks - the hooks to add
   121   * @count - the number of hooks to add
   122   *
   123   * Each LSM has to register its hooks with the infrastructure.
   124   */
   125  void __init security_add_hooks(struct security_hook_list *hooks, int 
count,
   126  char *lsm)
 > 127  {
   128  int i;
   129  
   130  for (i = 0; i < count; i++) {
   131  hooks[i].lsm = lsm;
   132  list_add_tail_rcu([i].list, hooks[i].head);
   133  }
   134  if (lsm_append(lsm, _names) < 0)
   135  panic("%s - Cannot get early memory.\n", __func__);

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


.config.gz
Description: Binary data

Linux 4.1.26

[Sasha Levin]

I'm announcing the release of the 4.1.26 kernel.

All users of the 4.1 kernel series must upgrade.

The updated 4.1.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.1.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary




Linux 4.1.26


Adrian Hunter (2):
  mmc: mmc: Fix partition switch timeout for some eMMCs
  mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers

Akshay Bhat (1):
  hwmon: (ads7828) Enable internal reference

Alan Stern (2):
  USB: leave LPM alone if possible when binding/unbinding interface drivers
  usb: misc: usbtest: format the data pattern according to max packet size

Andreas Noever (1):
  thunderbolt: Fix double free of drom buffer

Andreas Werner (1):
  mcb: Fixed bar number assignment for the gdd

Andrew Jeffery (1):
  pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range

Andy Shevchenko (1):
  mfd: intel_quark_i2c_gpio: load gpio driver first

Anilkumar Kolli (1):
  ath10k: fix debugfs pktlog_filter write

Arnd Bergmann (2):
  gcov: disable tree-loop-im to reduce stack usage
  kbuild: move -Wunused-const-variable to W=1 warning level

Axel Lin (1):
  ASoC: ak4642: Fix up max_register setting

Brian Bloniarz (1):
  Fix OpenSSH pty regression on close

Catalin Marinas (1):
  arm64: Ensure pmd_present() returns false after pmd_mknotpresent()

Catalin Vasile (1):
  crypto: caam - fix caam_jr_alloc() ret code

Chris Bainbridge (1):
  usb: core: hub: hub_port_init lock controller instead of bus

Daniel Lezcano (1):
  cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter()

Darrick J. Wong (1):
  libxfs: pack the agfl header structure so XFS_AGFL_SIZE is correct

Dave Chinner (4):
  xfs: Don't wrap growfs AGFL indexes
  xfs: xfs_iflush_cluster fails to abort on error
  xfs: fix inode validity check in xfs_iflush_cluster
  xfs: skip stale inodes in xfs_iflush_cluster

Dave Gerlach (1):
  cpuidle: Indicate when a device has been unregistered

David Henningsson (1):
  ALSA: hda - Fix headphone mic input on a few Dell ALC293 machines

David Müller (1):
  serial: 8250_pci: fix divide error bug if baud rate is 0

Eric Sandeen (1):
  xfs: disallow rw remount on fs with unknown ro-compat features

Gavin Shan (2):
  powerpc/eeh: Don't report error in eeh_pe_reset_and_recover()
  powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover()

Guilherme G. Piccoli (1):
  Revert "powerpc/eeh: Fix crash in eeh_add_device_early() on Cell"

H Hartley Sweeten (1):
  staging: comedi: das1800: fix possible NULL dereference

Hari Bathini (1):
  powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel

Itai Handler (1):
  drm/gma500: Fix possible out of bounds read

James Hogan (7):
  MIPS: Fix siginfo.h to use strict posix types
  MIPS: Don't unwind to user mode with EVA
  MIPS: Avoid using unwind_stack() with usermode
  MIPS: KVM: Fix timer IRQ race when freezing timer
  MIPS: KVM: Fix timer IRQ race when writing CP0_Compare
  SIGNAL: Move generic copy_siginfo() to signal.h
  MIPS: Fix uapi include in exported asm/siginfo.h

Jan Kara (1):
  ext4: fix oops on corrupted filesystem

Javier Martinez Canillas (1):
  regulator: Try to resolve regulators supplies on registration

Jiri Slaby (3):
  Bluetooth: vhci: fix open_timeout vs. hdev race
  Bluetooth: vhci: purge unhandled skbs
  TTY: n_gsm, fix false positive WARN_ON

Johan Hovold (5):
  USB: serial: io_edgeport: fix memory leaks in attach error path
  USB: serial: io_edgeport: fix memory leaks in probe error path
  USB: serial: keyspan: fix use-after-free in probe error path
  USB: serial: mxuport: fix use-after-free in probe error path
  USB: serial: quatech2: fix use-after-free in probe error path

Joseph Salisbury (1):
  ath5k: Change led pin configuration for compaq c700 laptop

Kai-Heng Feng (1):
  ALSA: hda - Fix headphone noise on Dell XPS 13 9360

Konstantin Shkolnyy (2):
  USB: cp210x: relocate private data from USB interface to port
  USB: serial: cp210x: fix hardware flow-control disable

Krzysztof Kozlowski (2):
  crypto: s5p-sss - Remove useless hash interrupt handler
  crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

Krzysztof Opasiak (3):
  usb: gadget: mass_storage: Free buffers if create lun fails
  usb: gadget: mass_storage: Fix freeing luns sysfs implementation
  usb: gadget: mass_storage: Use static array for luns

Larry Finger (2):
  rtlwifi: rtl8723be: Add antenna select module parameter
  rtlwifi: btcoexist: Implement antenna 

Linux 3.18.35

[Sasha Levin]

I'm announcing the release of the 3.18.35 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary




Linux 3.18.35


Adrian Hunter (3):
  mmc: mmc: Fix partition switch timeout for some eMMCs
  mmc: sdhci-acpi: Add two host capabilities for Intel
  mmc: sdhci-acpi: Remove MMC_CAP_BUS_WIDTH_TEST for Intel controllers

Alan Stern (2):
  USB: leave LPM alone if possible when binding/unbinding interface drivers
  usb: misc: usbtest: format the data pattern according to max packet size

Andreas Noever (1):
  thunderbolt: Fix double free of drom buffer

Andreas Werner (1):
  mcb: Fixed bar number assignment for the gdd

Andrew Jeffery (1):
  pinctrl: exynos5440: Use off-stack memory for pinctrl_gpio_range

Arnd Bergmann (2):
  gcov: disable tree-loop-im to reduce stack usage
  kbuild: move -Wunused-const-variable to W=1 warning level

Artem Bityutskiy (1):
  UBI: do propagate positive error codes up

Axel Lin (1):
  ASoC: ak4642: Fix up max_register setting

Brian Norris (1):
  UBI: fix missing brace control flow

Catalin Marinas (1):
  arm64: Ensure pmd_present() returns false after pmd_mknotpresent()

Catalin Vasile (1):
  crypto: caam - fix caam_jr_alloc() ret code

Chris Bainbridge (1):
  usb: core: hub: hub_port_init lock controller instead of bus

Daniel Lezcano (1):
  cpuidle: Fix cpuidle_state_is_coupled() argument in cpuidle_enter()

Dave Chinner (3):
  xfs: xfs_iflush_cluster fails to abort on error
  xfs: fix inode validity check in xfs_iflush_cluster
  xfs: skip stale inodes in xfs_iflush_cluster

Dave Gerlach (1):
  cpuidle: Indicate when a device has been unregistered

Eric Sandeen (2):
  xfs: disallow ro->rw remount on norecovery mount
  xfs: disallow rw remount on fs with unknown ro-compat features

Gavin Shan (2):
  powerpc/eeh: Don't report error in eeh_pe_reset_and_recover()
  powerpc/eeh: Restore initial state in eeh_pe_reset_and_recover()

Hari Bathini (1):
  powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel

Itai Handler (1):
  drm/gma500: Fix possible out of bounds read

James Hogan (5):
  MIPS: Fix siginfo.h to use strict posix types
  MIPS: Don't unwind to user mode with EVA
  MIPS: Avoid using unwind_stack() with usermode
  MIPS: KVM: Fix timer IRQ race when freezing timer
  MIPS: KVM: Fix timer IRQ race when writing CP0_Compare

Jan Kara (1):
  ext4: fix oops on corrupted filesystem

Jiang Liu (1):
  x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi

Jiri Slaby (3):
  Bluetooth: vhci: fix open_timeout vs. hdev race
  Bluetooth: vhci: purge unhandled skbs
  TTY: n_gsm, fix false positive WARN_ON

Johan Hovold (5):
  USB: serial: io_edgeport: fix memory leaks in attach error path
  USB: serial: io_edgeport: fix memory leaks in probe error path
  USB: serial: keyspan: fix use-after-free in probe error path
  USB: serial: mxuport: fix use-after-free in probe error path
  USB: serial: quatech2: fix use-after-free in probe error path

Joseph Salisbury (1):
  ath5k: Change led pin configuration for compaq c700 laptop

Kirill A. Shutemov (1):
  mm: fix huge zero page accounting in smaps report

Konstantin Shkolnyy (2):
  USB: cp210x: relocate private data from USB interface to port
  USB: serial: cp210x: fix hardware flow-control disable

Krzysztof Kozlowski (2):
  crypto: s5p-sss - Remove useless hash interrupt handler
  crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

Lei Liu (1):
  USB: serial: option: add even more ZTE device ids

Luke Dashjr (1):
  btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in 
btrfs_ioctl

Lv Zheng (1):
  ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal 
strings

Lyude (1):
  drm/fb_helper: Fix references to dev->mode_config.num_connector

Maciej W. Rozycki (1):
  MIPS: MSA: Fix a link error on `_init_msa_upper' with older GCC

Marc Zyngier (1):
  arm/arm64: KVM: Enforce Break-Before-Make on Stage-2 page tables

Mark Brown (2):
  regulator: core: Use class device list for regulator_list in late init
  ASoC: ak4642: Enable cache usage to fix crashes on resume

Mathias Nyman (1):
  usb: misc: usbtest: fix pattern tests for scatterlists.

Matt Gumbel (1):
  mmc: longer timeout for long read time quirk

Matthias Schiffer (1):
  MIPS: ath79: make bootconsole wait for both THRE and TEMT

Nicolai Stange (2):
  ext4: address UBSAN 

Re: [PATCH v3 0/6] Introduce pci_(request|release)_(mem|io)_regions

[Jeff Kirsher]

On Wed, 2016-06-08 at 09:28 +0200, Johannes Thumshirn wrote:
> On Tue, Jun 07, 2016 at 09:44:00AM +0200, Johannes Thumshirn wrote:
> > The first patch in this series introduces the following 4 helper
> functions to
> > the PCI core:
> > 
> > * pci_request_mem_regions()
> > * pci_request_io_regions()
> > * pci_release_mem_regions()
> > * pci_release_io_regions()
> > 
> > which encapsulate the request and release of a PCI device's memory or
> I/O
> > bars.
> > 
> > The subsequent patches convert the drivers, which use the
> > pci_request_selected_regions(pdev, 
> >   pci_select_bars(pdev, IORESOURCE_MEM), name); 
> > and similar pattern to use the new interface.
> > 
> > This was suggested by Christoph Hellwig in
> > http://lists.infradead.org/pipermail/linux-nvme/2016-May/004570.html an
> d
> > tested on kernel v4.6 with NVMe.
> > 
> 
> Btw, as I've seen already Jeff applying the Intel Ethernet patch to his
> tree, I think this should go via the PCI tree as the build dependency is
> the PCI patch.

Bjorn should pick up the entire series, I just applied the Intel patch (and
dependent patches) so we could touch test it.

signature.asc
Description: This is a digitally signed message part

[PATCH] ASoC: cs53l30: Correct clock inversion check

[Nicolin Chen]

SND_SOC_DAIFMT_IB_NF = 0x3 (11b) | SND_SOC_DAIFMT_IB_IF = 0x4 (100b)
creates a mask 0x7 (111b) which also includes SND_SOC_DAIFMT_IB_NF
= 0x2 (10b).

So this patch uses the traditional way to check the clock inversion.

Signed-off-by: Nicolin Chen 
---
 sound/soc/codecs/cs53l30.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/cs53l30.c b/sound/soc/codecs/cs53l30.c
index ac90dd7..62daa0c 100644
--- a/sound/soc/codecs/cs53l30.c
+++ b/sound/soc/codecs/cs53l30.c
@@ -598,8 +598,14 @@ static int cs53l30_set_dai_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
}
 
/* Check to see if the SCLK is inverted */
-   if (fmt & (SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_IB_IF))
+   switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+   case SND_SOC_DAIFMT_IB_NF:
+   case SND_SOC_DAIFMT_IB_IF:
aspcfg ^= CS53L30_ASP_SCLK_INV;
+   break;
+   default:
+   break;
+   }
 
regmap_update_bits(priv->regmap, CS53L30_ASPCFG_CTL,
   CS53L30_ASP_MS | CS53L30_ASP_SCLK_INV, aspcfg);
-- 
2.1.4

[RESEND PATCH V2 2/2] usb: phy: phy-brcm-usb: Add Broadcom STB USB phy driver

[Al Cooper]

Add a new USB Phy driver for Broadcom STB SoCs. This driver
supports all Broadcom STB ARM SoCs. This driver in combination
with the generic ohci, ehci and xhci platform drivers will enable
USB1.1, USB2.0 and USB3.0 support. This Phy driver also supports
the Broadcom UDC gadget driver.

Signed-off-by: Al Cooper 
---
 .../bindings/phy/brcm,brcmstb-usb-phy.txt  |  39 +
 MAINTAINERS|   7 +
 drivers/phy/Kconfig|  10 +
 drivers/phy/Makefile   |   2 +
 drivers/phy/phy-brcm-usb-init.c| 792 +
 drivers/phy/phy-brcm-usb-init.h|  49 ++
 drivers/phy/phy-brcm-usb.c | 206 ++
 7 files changed, 1105 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
 create mode 100644 drivers/phy/phy-brcm-usb-init.c
 create mode 100644 drivers/phy/phy-brcm-usb-init.h
 create mode 100644 drivers/phy/phy-brcm-usb.c

diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
new file mode 100644
index 000..34fa9dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
@@ -0,0 +1,39 @@
+Broadcom STB USB PHY
+
+Required properties:
+ - compatible: brcm,brcmstb-usb-phy
+ - reg: two offset and length pairs. The second pair specifies the
+USB 3.0 related registers and is only required for PHYs
+that support USB 3.0
+ - #phy-cells: Shall be 1 as it expects one argument for setting
+  the type of the PHY. Possible values are 0 (1.1 and 2.0),
+  1 (3.0)
+
+
+Optional Properties:
+- clocks : phandle + clock specifier for the phy clocks
+- clock-names: string, clock name
+- ipp: Invert Port Power
+- ioc: Invert Over Current detection
+- has_xhci: Contains an optional 3.0 PHY
+- device: PHY Device mode. Possible values are: 0 (Host), 1 (Device)
+  or 2 (DRD)
+
+
+
+Example:
+
+usbphy_0: usb-phy@f0470200 {
+   reg = <0xf0470200 0xb8>,
+   <0xf0471940 0x6c0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "brcm,brcmstb-usb-phy";
+   ioc = <1>;
+   ipp = <1>;
+   #phy-cells = <1>;
+   ranges;
+   has_xhci;
+   clocks = <_usb20>;
+   clock-names = "sw_usb";
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index ed1229e..4d529e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2631,6 +2631,13 @@ S:   Maintained
 F: drivers/bcma/
 F: include/linux/bcma/
 
+BROADCOM STB USB PHY DRIVER
+M: Al Cooper 
+L: linux-...@vger.kernel.org
+L: bcm-kernel-feedback-l...@broadcom.com
+S: Supported
+F: drivers/phy/phy-brcm-usb*
+
 BROADCOM SYSTEMPORT ETHERNET DRIVER
 M: Florian Fainelli 
 L: net...@vger.kernel.org
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..61a0244 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -432,6 +432,16 @@ config PHY_CYGNUS_PCIE
  Enable this to support the Broadcom Cygnus PCIe PHY.
  If unsure, say N.
 
+config BRCM_USB_PHY
+   tristate "Broadcom USB PHY driver"
+   depends on OF && USB && ARCH_BRCMSTB
+   select GENERIC_PHY
+   default y
+   help
+ Enable this to support the Broadcom USB PHY on
+ Broadcom STB SoCs.
+ If unsure, say Y.
+
 source "drivers/phy/tegra/Kconfig"
 
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..babb0c7 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_PHY_BERLIN_SATA)   += phy-berlin-sata.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
 obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
+obj-$(CONFIG_BRCM_USB_PHY) += phy-brcm-usb.o
+obj-$(CONFIG_BRCM_USB_PHY) += phy-brcm-usb-init.o
 obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)  += phy-exynos-dp-video.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
 obj-$(CONFIG_PHY_LPC18XX_USB_OTG)  += phy-lpc18xx-usb-otg.o
diff --git a/drivers/phy/phy-brcm-usb-init.c b/drivers/phy/phy-brcm-usb-init.c
new file mode 100644
index 000..f5d8c32
--- /dev/null
+++ b/drivers/phy/phy-brcm-usb-init.c
@@ -0,0 +1,792 @@
+/*
+ * Copyright (C) 2014-2016 Broadcom
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *

Re: [PATCH v2 0/2] net: ethernet: ti: cpsw: delete rx_descs property

[Ivan Khoronzhuk]

On 09.06.16 02:11, Schuyler Patton wrote:



On 06/08/2016 09:06 AM, Ivan Khoronzhuk wrote:



On 08.06.16 17:01, Ivan Khoronzhuk wrote:

Hi Schuyer,

On 07.06.16 18:26, Schuyler Patton wrote:

Hi,

On 06/07/2016 08:59 AM, Ivan Khoronzhuk wrote:

There is no reason in rx_descs property because davinici_cpdma
driver splits pool of descriptors equally between tx and rx channels.
So, this patch series makes driver to use available number of
descriptors for rx channels.


I agree with the idea of consolidating how the descriptors are defined because 
of
the two variable components, number and size of the pool can be confusing to
end users. I would like to request to change how it is being proposed here.

I think the number of descriptors should be left in the device tree source file 
as
is and remove the BD size variable and have the driver calculate the size of the
pool necessary to support the descriptor request. From an user perspective it is
easier I think to be able to list the number of descriptors necessary vs. the 
size
of the pool.

Since the patch series points out how it is used so in the driver so to make 
that
consistent is perhaps change rx_descs to total_descs.

Regards,
Schuyler


The DT entry for cpsw doesn't have property for size of the pool.
It contains only BD ram size, if you mean this. The size of the pool is
software decision. Current version of DT entry contain only rx desc number.
That is not correct, as it depends on the size of the descriptor, which is also
h/w parameter. The DT entry has to describe only h/w part and shouldn't contain
driver implementation details, and I'm looking on it from this perspective.

Besides, rx_descs describes only rx number of descriptors, that are taken from
the same pool as tx descriptors, and setting rx desc to some new value doesn't
mean that rest of them are freed for tx. Also, I'm going to send series that
adds multi channel support to the driver, and in this case, splitting of the
pool will be more sophisticated than now, after what setting those parameters
for user (he should do this via device tree) can be even more confusing. But,

should -> shouldn't


as it's supposed, it's software decision that shouldn't leak to the DT.


If this rx-desc field is removed how will the number of descriptors be set?

This field has been used to increase the number of descriptors so high
volume short packets are not dropped due to descriptor exhaustion. The current
default number of 64 rx descriptors is too low for gigabit networks. Some users
have a strong requirement for zero loss of UDP packets setting this field to a
larger number and setting the descriptors off-chip was a means to solve
the problem.

The current implementation of cpdma driver splits descs num on 2 parts equally.
Total number = 256, then 128 reserved for rx and 128 for tx, but setting this to
64, simply limits usage of reserved rx descriptors to 64, so that:
64 rx descs, 128 tx descs and 64 are always present in the pool but cannot be 
used,
(as new rx descriptor is allocated only after previous was freed).
That means, 64 rx descs are unused. In case of rx descriptor exhaustion, an 
user can
set rx_descs to 128, for instance, in this case all descriptors will be in use, 
but then question,
why intentionally limit number of rx descs, anyway rest 64 descs cannot be used 
for other
purposes. In case of this patch, all rx descs are in use, and no need to 
correct number
of rx descs anymore, use all of themand it doesn't have impact on 
performance, as
anyway, bunch of rx descs were simply limited by DT and unused. So, probably, 
there is no
reason to worry about that.

PS:
It doesn't concern this patch, but, which PPS makes rx descs to be exhausted?...
(In this case "desc_alloc_fail" counter contains some value for rx channel,
and can be read with "ethtool -S eth0". Also, the user will be WARNed ON by the 
driver)

it's interesting to test it, I'm worrying about, because in case of 
multichannel,
the pool is split between all channels... they are throughput limited, but
anyway, it's good to correlate the number of descs with throughput assigned to
a channel, if possible. That has to be possible, if setting to 128 helps, then
has to be value between 64 and 128 to make handling of rx packets fast enough.
After what, can be calculated correlation between number of rx descs and 
throughput
split between channels








Based on master branch

Since v1:
- separate device tree and driver patches
- return number of rx buffers from cpdma driver

Ivan Khoronzhuk (2):
   net: ethernet: ti: cpsw: remove rx_descs property
   Documentation: DT: cpsw: remove rx_descs property

  Documentation/devicetree/bindings/net/cpsw.txt |  1 -
  arch/arm/boot/dts/am33xx.dtsi  |  1 -
  arch/arm/boot/dts/am4372.dtsi  |  1 -
  arch/arm/boot/dts/dm814x.dtsi  |  1 -
  arch/arm/boot/dts/dra7.dtsi|  1 -
  drivers/net/ethernet/ti/cpsw.c

[PATCH 6/9] x86, pkeys: add pkey set/get syscalls

[Dave Hansen]

From: Dave Hansen 

This establishes two more system calls for protection key management:

unsigned long pkey_get(int pkey);
int pkey_set(int pkey, unsigned long access_rights);

The return value from pkey_get() and the 'access_rights' passed
to pkey_set() are the same format: a bitmask containing
PKEY_DENY_WRITE and/or PKEY_DENY_ACCESS, or nothing set at all.

These can replace userspace's direct use of the new rdpkru/wrpkru
instructions.

With current hardware, the kernel can not enforce that it has
control over a given key.  But, this at least allows the kernel
to indicate to userspace that userspace does not control a given
protection key.  This makes it more likely that situations like
using a pkey after sys_pkey_free() can be detected.

The kernel does _not_ enforce that this interface must be used for
changes to PKRU, whether or not a key has been "allocated".

This syscall interface could also theoretically be replaced with a
pair of vsyscalls.  The vsyscalls would just call WRPKRU/RDPKRU
directly in situations where they are drop-in equivalents for
what the kernel would be doing.

Signed-off-by: Dave Hansen 
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc: torva...@linux-foundation.org
Cc: a...@linux-foundation.org
---

 b/arch/x86/entry/syscalls/syscall_32.tbl |2 +
 b/arch/x86/entry/syscalls/syscall_64.tbl |2 +
 b/arch/x86/include/asm/pkeys.h   |4 +-
 b/arch/x86/kernel/fpu/xstate.c   |   55 +--
 b/include/linux/pkeys.h  |8 
 b/mm/mprotect.c  |   41 +++
 6 files changed, 109 insertions(+), 3 deletions(-)

diff -puN arch/x86/entry/syscalls/syscall_32.tbl~pkeys-118-syscalls-set-get 
arch/x86/entry/syscalls/syscall_32.tbl
--- a/arch/x86/entry/syscalls/syscall_32.tbl~pkeys-118-syscalls-set-get 
2016-06-08 16:26:35.894970089 -0700
+++ b/arch/x86/entry/syscalls/syscall_32.tbl2016-06-08 16:26:35.906970634 
-0700
@@ -389,3 +389,5 @@
 380i386pkey_mprotect   sys_pkey_mprotect
 381i386pkey_alloc  sys_pkey_alloc
 382i386pkey_free   sys_pkey_free
+383i386pkey_getsys_pkey_get
+384i386pkey_setsys_pkey_set
diff -puN arch/x86/entry/syscalls/syscall_64.tbl~pkeys-118-syscalls-set-get 
arch/x86/entry/syscalls/syscall_64.tbl
--- a/arch/x86/entry/syscalls/syscall_64.tbl~pkeys-118-syscalls-set-get 
2016-06-08 16:26:35.896970180 -0700
+++ b/arch/x86/entry/syscalls/syscall_64.tbl2016-06-08 16:26:35.906970634 
-0700
@@ -338,6 +338,8 @@
 329common  pkey_mprotect   sys_pkey_mprotect
 330common  pkey_alloc  sys_pkey_alloc
 331common  pkey_free   sys_pkey_free
+332common  pkey_getsys_pkey_get
+333common  pkey_setsys_pkey_set
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff -puN arch/x86/include/asm/pkeys.h~pkeys-118-syscalls-set-get 
arch/x86/include/asm/pkeys.h
--- a/arch/x86/include/asm/pkeys.h~pkeys-118-syscalls-set-get   2016-06-08 
16:26:35.898970271 -0700
+++ b/arch/x86/include/asm/pkeys.h  2016-06-08 16:26:35.908970724 -0700
@@ -56,7 +56,7 @@ static inline bool validate_pkey(int pke
 }
 
 static inline
-bool mm_pkey_is_allocated(struct mm_struct *mm, unsigned long pkey)
+bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
 {
if (!validate_pkey(pkey))
return true;
@@ -107,4 +107,6 @@ extern int arch_set_user_pkey_access(str
 extern int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
unsigned long init_val);
 
+extern unsigned long arch_get_user_pkey_access(struct task_struct *tsk,
+   int pkey);
 #endif /*_ASM_X86_PKEYS_H */
diff -puN arch/x86/kernel/fpu/xstate.c~pkeys-118-syscalls-set-get 
arch/x86/kernel/fpu/xstate.c
--- a/arch/x86/kernel/fpu/xstate.c~pkeys-118-syscalls-set-get   2016-06-08 
16:26:35.899970316 -0700
+++ b/arch/x86/kernel/fpu/xstate.c  2016-06-08 16:26:35.908970724 -0700
@@ -690,7 +690,7 @@ void fpu__resume_cpu(void)
  *
  * Note: does not work for compacted buffers.
  */
-void *__raw_xsave_addr(struct xregs_state *xsave, int xstate_feature_mask)
+static void *__raw_xsave_addr(struct xregs_state *xsave, int 
xstate_feature_mask)
 {
int feature_nr = fls64(xstate_feature_mask) - 1;
 
@@ -864,6 +864,7 @@ out:
 
 #define NR_VALID_PKRU_BITS (CONFIG_NR_PROTECTION_KEYS * 2)
 #define PKRU_VALID_MASK (NR_VALID_PKRU_BITS - 1)
+#define PKRU_INIT_STATE0
 
 /*
  * This will go out and modify the XSAVE buffer so that PKRU is
@@ -882,6 +883,9 @@ int __arch_set_user_pkey_access(struct t
int pkey_shift = (pkey * PKRU_BITS_PER_PKEY);
u32 new_pkru_bits = 0;
 
+   /* Only support manipulating current task for now */
+   if (tsk != current)
+   

[PATCH 0/9] [v3] System Calls for Memory Protection Keys

[Dave Hansen]

Are there any concerns with merging these into the x86 tree so
that they go upstream for 4.8?  The updates here are pretty
minor.

Changes from v2:
 * selftest updates:
  * formatting changes like what Ingo asked for with MPX
  * actually call WRPKRU in __wrpkru()
  * once __wrpkru() was fixed, revealed a bug in the ptrace
test where we were testing against the wrong pointer during
the "baseline" test
 * Man-pages that match this set are here:
 http://marc.info/?l=linux-man=146540723525616=2

Changes from v1:
 * updates to alloc/free patch description calling out that
   "in-use" pkeys may still be pkey_free()'d successfully.
 * Fixed a bug in the selftest where the 'flags' argument was
   not passed to pkey_get().
 * Added all syscalls to generic syscalls header
 * Added extra checking to selftests so it doesn't fall over
   when 1G pages are made the hugetlbfs default.

--

Memory Protection Keys for User pages (pkeys) is a CPU feature
which will first appear on Skylake Servers, but will also be
supported on future non-server parts.  It provides a mechanism
for enforcing page-based protections, but without requiring
modification of the page tables when an application changes
wishes to change permissions.

Patches to implement execute-only mapping support using pkeys
were merged in to 4.6.  But, to do anything else useful with
pkeys, an application needs to be able to set the pkey field in
the PTE (obviously has to be done in-kernel) and make changes to
the "rights" register (using unprivileged instructions).

An application also needs to have an an allocator for the keys
themselves.  If two different parts of an application both want
to protect their data with pkeys, they first need to know which
key to use for their individual purposes.

This set introduces 5 system calls, in 3 logical groups:

1. PTE pkey setting (sys_pkey_mprotect(), patches #1-3)
2. Key allocation (sys_pkey_alloc() / sys_pkey_free(), patch #4)
3. Rights register manipulation (sys_pkey_set/get(), patch #5)

These patches build on top of "core" pkeys support already in
4.6.

I have manpages written for some of these syscalls, and have
had multiple rounds of reviews on the manpages list.

This set is also available here:

git://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-pkeys.git 
pkeys-v039

I've written a set of unit tests for these interfaces, which is
available as the last patch in the series and integrated in to
kselftests.

Note: this is based on a plain 4.6 kernel and will have a minor
merge conflict in the x86 selftests makefile with the new
MPX selftest if those get merged first.

=== diffstat ===

Dave Hansen (9):
  x86, pkeys: add fault handling for PF_PK page fault bit
  mm: implement new pkey_mprotect() system call
  x86, pkeys: make mprotect_key() mask off additional vm_flags
  x86: wire up mprotect_key() system call
  x86, pkeys: allocation/free syscalls
  x86, pkeys: add pkey set/get syscalls
  generic syscalls: wire up memory protection keys syscalls
  pkeys: add details of system call use to Documentation/
  x86, pkeys: add self-tests

 Documentation/x86/protection-keys.txt |   63 +
 arch/alpha/include/uapi/asm/mman.h|5 +
 arch/mips/include/uapi/asm/mman.h |5 +
 arch/parisc/include/uapi/asm/mman.h   |5 +
 arch/x86/entry/syscalls/syscall_32.tbl|5 +
 arch/x86/entry/syscalls/syscall_64.tbl|5 +
 arch/x86/include/asm/mmu.h|8 +
 arch/x86/include/asm/mmu_context.h|   25 +-
 arch/x86/include/asm/pkeys.h  |   80 +-
 arch/x86/kernel/fpu/xstate.c  |   73 +-
 arch/x86/mm/fault.c   |9 +
 arch/x86/mm/pkeys.c   |   38 +-
 arch/xtensa/include/uapi/asm/mman.h   |5 +
 include/linux/pkeys.h |   39 +-
 include/uapi/asm-generic/mman-common.h|5 +
 include/uapi/asm-generic/unistd.h |   12 +-
 mm/mprotect.c |  134 +-
 tools/testing/selftests/x86/Makefile  |3 +-
 tools/testing/selftests/x86/pkey-helpers.h|  191 +++
 tools/testing/selftests/x86/protection_keys.c | 1316 +
 20 files changed, 1995 insertions(+), 31 deletions(-)

Cc: linux-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc: torva...@linux-foundation.org
Cc: a...@linux-foundation.org
Cc: Arnd Bergmann 

[PATCH 8/9] pkeys: add details of system call use to Documentation/

[Dave Hansen]

From: Dave Hansen 

This spells out all of the pkey-related system calls that we have
and provides some example code fragments to demonstrate how we
expect them to be used.

Signed-off-by: Dave Hansen 
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc: torva...@linux-foundation.org
Cc: a...@linux-foundation.org
---

 b/Documentation/x86/protection-keys.txt |   63 
 1 file changed, 63 insertions(+)

diff -puN Documentation/x86/protection-keys.txt~pkeys-120-syscall-docs 
Documentation/x86/protection-keys.txt
--- a/Documentation/x86/protection-keys.txt~pkeys-120-syscall-docs  
2016-06-08 16:26:36.871014363 -0700
+++ b/Documentation/x86/protection-keys.txt 2016-06-08 16:26:36.874014499 
-0700
@@ -18,6 +18,69 @@ even though there is theoretically space
 permissions are enforced on data access only and have no effect on
 instruction fetches.
 
+=== Syscalls ===
+
+There are 5 system calls which directly interact with pkeys:
+
+   int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
+   int pkey_free(int pkey);
+   int pkey_mprotect(unsigned long start, size_t len,
+ unsigned long prot, int pkey);
+   unsigned long pkey_get(int pkey);
+   int pkey_set(int pkey, unsigned long access_rights);
+
+Before a pkey can be used, it must first be allocated with
+pkey_alloc().  An application may either call pkey_set() or the
+WRPKRU instruction directly in order to change access permissions
+to memory covered with a key.
+
+   int real_prot = PROT_READ|PROT_WRITE;
+   pkey = pkey_alloc(0, PKEY_DENY_WRITE);
+   ptr = mmap(NULL, PAGE_SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 
0);
+   ret = pkey_mprotect(ptr, PAGE_SIZE, real_prot, pkey);
+   ... application runs here
+
+Now, if the application needs to update the data at 'ptr', it can
+gain access, do the update, then remove its write access:
+
+   pkey_set(pkey, 0); // clear PKEY_DENY_WRITE
+   *ptr = foo; // assign something
+   pkey_set(pkey, PKEY_DENY_WRITE); // set PKEY_DENY_WRITE again
+
+Now when it frees the memory, it will also free the pkey since it
+is no longer in use:
+
+   munmap(ptr, PAGE_SIZE);
+   pkey_free(pkey);
+
+=== Behavior ===
+
+The kernel attempts to make protection keys consistent with the
+behavior of a plain mprotect().  For instance if you do this:
+
+   mprotect(ptr, size, PROT_NONE);
+   something(ptr);
+
+you can expect the same effects with protection keys when doing this:
+
+   pkey = pkey_alloc(0, PKEY_DISABLE_WRITE | PKEY_DISABLE_READ);
+   pkey_mprotect(ptr, size, PROT_READ|PROT_WRITE, pkey);
+   something(ptr);
+
+That should be true whether something() is a direct access to 'ptr'
+like:
+
+   *ptr = foo;
+
+or when the kernel does the access on the application's behalf like
+with a read():
+
+   read(fd, ptr, 1);
+
+The kernel will send a SIGSEGV in both cases, but si_code will be set
+to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when
+the plain mprotect() permissions are violated.
+
 === Config Option ===
 
 This config option adds approximately 1.5kb of text. and 50 bytes of
_

[PATCH 7/9] generic syscalls: wire up memory protection keys syscalls

[Dave Hansen]

From: Dave Hansen 

These new syscalls are implemented as generic code, so enable
them for architectures like arm64 which use the generic syscall
table.

According to Arnd:

Even if the support is x86 specific for the forseeable
future, it may be good to reserve the number just in
case.  The other architecture specific syscall lists are
usually left to the individual arch maintainers, most a
lot of the newer architectures share this table.

Signed-off-by: Dave Hansen 
Acked-by: Arnd Bergmann 
---

 b/include/uapi/asm-generic/unistd.h |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff -puN include/uapi/asm-generic/unistd.h~pkeys-119-syscalls-generic 
include/uapi/asm-generic/unistd.h
--- a/include/uapi/asm-generic/unistd.h~pkeys-119-syscalls-generic  
2016-06-08 16:26:36.450995311 -0700
+++ b/include/uapi/asm-generic/unistd.h 2016-06-08 16:26:36.455995538 -0700
@@ -724,9 +724,19 @@ __SYSCALL(__NR_copy_file_range, sys_copy
 __SC_COMP(__NR_preadv2, sys_preadv2, compat_sys_preadv2)
 #define __NR_pwritev2 287
 __SC_COMP(__NR_pwritev2, sys_pwritev2, compat_sys_pwritev2)
+#define __NR_pkey_mprotect 288
+__SYSCALL(__NR_pkey_mprotect, sys_pkey_mprotect)
+#define __NR_pkey_alloc 289
+__SYSCALL(__NR_pkey_alloc,sys_pkey_alloc)
+#define __NR_pkey_free 290
+__SYSCALL(__NR_pkey_free, sys_pkey_free)
+#define __NR_pkey_get 291
+__SYSCALL(__NR_pkey_get,  sys_pkey_get)
+#define __NR_pkey_set 292
+__SYSCALL(__NR_pkey_set,  sys_pkey_set)
 
 #undef __NR_syscalls
-#define __NR_syscalls 288
+#define __NR_syscalls 293
 
 /*
  * All syscalls below here should go away really,
_

[PATCH 3/9] x86, pkeys: make mprotect_key() mask off additional vm_flags

[Dave Hansen]

From: Dave Hansen 

Today, mprotect() takes 4 bits of data: PROT_READ/WRITE/EXEC/NONE.
Three of those bits: READ/WRITE/EXEC get translated directly in to
vma->vm_flags by calc_vm_prot_bits().  If a bit is unset in
mprotect()'s 'prot' argument then it must be cleared in vma->vm_flags
during the mprotect() call.

We do this clearing today by first calculating the VMA flags we
want set, then clearing the ones we do not want to inherit from
the original VMA:

vm_flags = calc_vm_prot_bits(prot, key);
...
newflags = vm_flags;
newflags |= (vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));

However, we *also* want to mask off the original VMA's vm_flags in
which we store the protection key.

To do that, this patch adds a new macro:

ARCH_VM_PKEY_FLAGS

which allows the architecture to specify additional bits that it would
like cleared.  We use that to ensure that the VM_PKEY_BIT* bits get
cleared.

Signed-off-by: Dave Hansen 
Reviewed-by: Thomas Gleixner 
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc: torva...@linux-foundation.org
Cc: a...@linux-foundation.org
---

 b/arch/x86/include/asm/pkeys.h |2 ++
 b/include/linux/pkeys.h|1 +
 b/mm/mprotect.c|   11 ++-
 3 files changed, 13 insertions(+), 1 deletion(-)

diff -puN arch/x86/include/asm/pkeys.h~pkeys-112-mask-off-correct-vm_flags 
arch/x86/include/asm/pkeys.h
--- a/arch/x86/include/asm/pkeys.h~pkeys-112-mask-off-correct-vm_flags  
2016-06-08 16:26:34.200893245 -0700
+++ b/arch/x86/include/asm/pkeys.h  2016-06-08 16:26:34.207893563 -0700
@@ -38,4 +38,6 @@ static inline int arch_override_mprotect
 extern int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
unsigned long init_val);
 
+#define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | 
VM_PKEY_BIT3)
+
 #endif /*_ASM_X86_PKEYS_H */
diff -puN include/linux/pkeys.h~pkeys-112-mask-off-correct-vm_flags 
include/linux/pkeys.h
--- a/include/linux/pkeys.h~pkeys-112-mask-off-correct-vm_flags 2016-06-08 
16:26:34.202893336 -0700
+++ b/include/linux/pkeys.h 2016-06-08 16:26:34.207893563 -0700
@@ -16,6 +16,7 @@
 #define execute_only_pkey(mm) (0)
 #define arch_override_mprotect_pkey(vma, prot, pkey) (0)
 #define PKEY_DEDICATED_EXECUTE_ONLY 0
+#define ARCH_VM_PKEY_FLAGS 0
 #endif /* ! CONFIG_ARCH_HAS_PKEYS */
 
 /*
diff -puN mm/mprotect.c~pkeys-112-mask-off-correct-vm_flags mm/mprotect.c
--- a/mm/mprotect.c~pkeys-112-mask-off-correct-vm_flags 2016-06-08 
16:26:34.203893381 -0700
+++ b/mm/mprotect.c 2016-06-08 16:26:34.207893563 -0700
@@ -411,6 +411,7 @@ static int do_mprotect_pkey(unsigned lon
prev = vma;
 
for (nstart = start ; ; ) {
+   unsigned long mask_off_old_flags;
unsigned long newflags;
int new_vma_pkey;
 
@@ -420,9 +421,17 @@ static int do_mprotect_pkey(unsigned lon
if (rier && (vma->vm_flags & VM_MAYEXEC))
prot |= PROT_EXEC;
 
+   /*
+* Each mprotect() call explicitly passes r/w/x permissions.
+* If a permission is not passed to mprotect(), it must be
+* cleared from the VMA.
+*/
+   mask_off_old_flags = VM_READ | VM_WRITE | VM_EXEC |
+   ARCH_VM_PKEY_FLAGS;
+
new_vma_pkey = arch_override_mprotect_pkey(vma, prot, pkey);
newflags = calc_vm_prot_bits(prot, new_vma_pkey);
-   newflags |= (vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));
+   newflags |= (vma->vm_flags & ~mask_off_old_flags);
 
/* newflags >> 4 shift VM_MAY% in place of VM_% */
if ((newflags & ~(newflags >> 4)) & (VM_READ | VM_WRITE | 
VM_EXEC)) {
_

[PATCH 5/9] x86, pkeys: allocation/free syscalls

[Dave Hansen]

From: Dave Hansen 

This patch adds two new system calls:

int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
int pkey_free(int pkey);

These implement an "allocator" for the protection keys
themselves, which can be thought of as analogous to the allocator
that the kernel has for file descriptors.  The kernel tracks
which numbers are in use, and only allows operations on keys that
are valid.  A key which was not obtained by pkey_alloc() may not,
for instance, be passed to pkey_mprotect() (or the forthcoming
get/set syscalls).

These system calls are also very important given the kernel's use
of pkeys to implement execute-only support.  These help ensure
that userspace can never assume that it has control of a key
unless it first asks the kernel.

The 'init_access_rights' argument to pkey_alloc() specifies the
rights that will be established for the returned pkey.  For
instance:

pkey = pkey_alloc(flags, PKEY_DENY_WRITE);

will allocate 'pkey', but also sets the bits in PKRU[1] such that
writing to 'pkey' is already denied.  This keeps userspace from
needing to have knowledge about manipulating PKRU with the
RDPKRU/WRPKRU instructions.  Userspace is still free to use these
instructions as it wishes, but this facility ensures it is no
longer required.

The kernel does _not_ enforce that this interface must be used for
changes to PKRU, even for keys it does not control.

The kernel does not prevent pkey_free() from successfully freeing
in-use pkeys (those still assigned to a memory range by
pkey_mprotect()).  It would be expensive to implement the checks
for this, so we instead say, "Just don't do it" since sane
software will never do it anyway.

This allocation mechanism could be implemented in userspace.
Even if we did it in userspace, we would still need additional
user/kernel interfaces to tell userspace which keys are being
used by the kernel internally (such as for execute-only
mappings).  Having the kernel provide this facility completely
removes the need for these additional interfaces, or having an
implementation of this in userspace at all.

Note that we have to make changes to all of the architectures
that do not use mman-common.h because we use the new
PKEY_DENY_ACCESS/WRITE macros in arch-independent code.

1. PKRU is the Protection Key Rights User register.  It is a
   usermode-accessible register that controls whether writes
   and/or access to each individual pkey is allowed or denied.

Signed-off-by: Dave Hansen 
Cc: linux-...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
Cc: x...@kernel.org
Cc: torva...@linux-foundation.org
Cc: a...@linux-foundation.org
---

 b/arch/alpha/include/uapi/asm/mman.h |5 +
 b/arch/mips/include/uapi/asm/mman.h  |5 +
 b/arch/parisc/include/uapi/asm/mman.h|5 +
 b/arch/x86/entry/syscalls/syscall_32.tbl |2 
 b/arch/x86/entry/syscalls/syscall_64.tbl |2 
 b/arch/x86/include/asm/mmu.h |8 +++
 b/arch/x86/include/asm/mmu_context.h |   10 +++
 b/arch/x86/include/asm/pkeys.h   |   79 ---
 b/arch/x86/kernel/fpu/xstate.c   |3 +
 b/arch/x86/mm/pkeys.c|   38 +++---
 b/arch/xtensa/include/uapi/asm/mman.h|5 +
 b/include/linux/pkeys.h  |   30 +--
 b/include/uapi/asm-generic/mman-common.h |5 +
 b/mm/mprotect.c  |   55 +
 14 files changed, 231 insertions(+), 21 deletions(-)

diff -puN arch/alpha/include/uapi/asm/mman.h~pkeys-116-syscalls-allocation 
arch/alpha/include/uapi/asm/mman.h
--- a/arch/alpha/include/uapi/asm/mman.h~pkeys-116-syscalls-allocation  
2016-06-08 16:26:35.124935160 -0700
+++ b/arch/alpha/include/uapi/asm/mman.h2016-06-08 16:26:35.149936294 
-0700
@@ -78,4 +78,9 @@
 #define MAP_HUGE_SHIFT 26
 #define MAP_HUGE_MASK  0x3f
 
+#define PKEY_DISABLE_ACCESS0x1
+#define PKEY_DISABLE_WRITE 0x2
+#define PKEY_ACCESS_MASK   (PKEY_DISABLE_ACCESS |\
+PKEY_DISABLE_WRITE)
+
 #endif /* __ALPHA_MMAN_H__ */
diff -puN arch/mips/include/uapi/asm/mman.h~pkeys-116-syscalls-allocation 
arch/mips/include/uapi/asm/mman.h
--- a/arch/mips/include/uapi/asm/mman.h~pkeys-116-syscalls-allocation   
2016-06-08 16:26:35.125935205 -0700
+++ b/arch/mips/include/uapi/asm/mman.h 2016-06-08 16:26:35.150936340 -0700
@@ -105,4 +105,9 @@
 #define MAP_HUGE_SHIFT 26
 #define MAP_HUGE_MASK  0x3f
 
+#define PKEY_DISABLE_ACCESS0x1
+#define PKEY_DISABLE_WRITE 0x2
+#define PKEY_ACCESS_MASK   (PKEY_DISABLE_ACCESS |\
+PKEY_DISABLE_WRITE)
+
 #endif /* _ASM_MMAN_H */
diff -puN arch/parisc/include/uapi/asm/mman.h~pkeys-116-syscalls-allocation 
arch/parisc/include/uapi/asm/mman.h
--- a/arch/parisc/include/uapi/asm/mman.h~pkeys-116-syscalls-allocation 
2016-06-08 16:26:35.127935296 -0700
+++