date:20160708

On Thu, Jul 07, 2016 at 09:42:32AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 07, 2016 at 11:20:36AM +1200, Campbell Steven wrote:
> 
> > > commit 8974189222159154c55f24ddad33e3613960521a
> > > Author: Peter Zijlstra 
> > > Date:   Thu Jun 16 10:50:40 2016 +0200
> 
> > Since these early reports from Stefan and I it looks like it's been
> > hit but alot more folks now so I'd like to ask what the process is for
> > getting this backported into 4.6, 4.5 and 4.4 as in our testing all
> > those versions for their latest point release seem to have the same
> > problem.
> 
> I think this should do; Greg is on Cc and will mark the commit
> somewhere. It is already in Linus' tree and should indeed be sufficient.
> 
> It has a Fixes tag referring the commit that introduced it, which IIRC
> is somewhere around v4.2.
> 
> Greg, anything else required?

Nope, that should be fine.

greg k-h

Re: divide error: 0000 [#1] SMP in task_numa_migrate - handle_mm_fault vanilla 4.4.6

On Thu, Jul 07, 2016 at 09:42:32AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 07, 2016 at 11:20:36AM +1200, Campbell Steven wrote:
> 
> > > commit 8974189222159154c55f24ddad33e3613960521a
> > > Author: Peter Zijlstra 
> > > Date:   Thu Jun 16 10:50:40 2016 +0200
> 
> > Since these early reports from Stefan and I it looks like it's been
> > hit but alot more folks now so I'd like to ask what the process is for
> > getting this backported into 4.6, 4.5 and 4.4 as in our testing all
> > those versions for their latest point release seem to have the same
> > problem.
> 
> I think this should do; Greg is on Cc and will mark the commit
> somewhere. It is already in Linus' tree and should indeed be sufficient.
> 
> It has a Fixes tag referring the commit that introduced it, which IIRC
> is somewhere around v4.2.
> 
> Greg, anything else required?

Nope, that should be fine.

greg k-h

Re: [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs

On Thu, Jul 07, 2016 at 07:39:12PM +0200, Andreas Noever wrote:
> On Tue, Jun 14, 2016 at 10:22 PM, Bjorn Helgaas  wrote:
> > On Tue, Jun 14, 2016 at 09:14:27PM +0200, Andreas Noever wrote:
> >> On Tue, Jun 14, 2016 at 6:37 PM, Bjorn Helgaas  wrote:
> >> > [+cc linux-kernel]
> >> >
> >> > On Sat, May 21, 2016 at 11:48:42AM +0200, Andreas Noever wrote:
> >> >>
> >> >> Signed-off-by: Andreas Noever 
> >> >>
> >> >> Tested on MacBookPro10,1
> >> >>
> >> >> On Fri, May 13, 2016 at 1:15 PM, Lukas Wunner  wrote:
> >> >> > This series powers Thunderbolt controllers on Macs down when nothing 
> >> >> > is
> >> >> > plugged in, saving 1.7 W on machines with a Light Ridge controller and
> >> >> > reportedly 4 W on Cactus Ridge 4C and Falcon Ridge 4C.
> >> >> >
> >> >> > Briefly, a custom ACPI method provided by Apple is used to cut power 
> >> >> > to
> >> >> > the controller.  A GPE is enabled while the controller is powered down
> >> >> > which side-band signals a plug event, whereupon power is reinstated 
> >> >> > using
> >> >> > the ACPI method.  Note that even though this mechanism is ACPI-based,
> >> >> > it does not use _PSx methods and is thus entirely nonstandard.
> >> >
> >> > I think the current arrangement was that Andreas would ack Thunderbolt
> >> > patches and I would merge them via the PCI tree.  That makes some sense
> >> > because Thunderbolt and PCIe are related, but the more I think about
> >> > it, the less I'm happy with it.
> >> >
> >> > This series is a good example.  I'm sure it's good work and
> >> > worthwhile.  But I can't really say anything about the content of it
> >> > because most of it is Thunderbolt-specific and there's no public spec.
> >> > It seems like this is basically a collection of reverse-engineered
> >> > quirks that happen to work with the current state of Linux PM on
> >> > certain Macs.  We don't know what might change on future Macs.  We
> >> > don't know what might break when we make changes to Linux PM.
> >> >
> >> > I can't test this series, nor do I want to.  I can't test most of the
> >> > patches I merge, but I can at least read the spec and see whether the
> >> > patches make sense.  What I would *like* is to have public Thunderbolt
> >> > specs and a kernel developer's guide so we know what to expect from
> >> > the hardware and the firmware and we can write code that should work
> >> > not just on current Macs, but also on non-Macs and future Macs.
> >> >
> >> > I don't think the current situation is really maintainable, and I'm
> >> > not comfortable merging code that I can't maintain.
> >> Most of the code is contained within the thunderbolt driver. I think
> >> there is quite some precedence for reverse engineered drivers without
> >> specs being part of the kernel. My understanding was that, since I am
> >> listed in MAINTAINERS, I am responsible for the driver. Now our
> >> changes often need improvements to the pci core, which is why I think
> >> merging through your tree is a good idea (without transferring
> >> responsibility). The changes to the drivers/pci should be supported by
> >> the PCI-spec and make sense without knowing about thunderbolt (but it
> >> might be the case that thunderbolt is the only user of these
> >> features).
> >>
> >> Specifically for this series we want to:
> >>  - whitelist thunderbolt bridges for PM. Detecting those bridges is
> >> non-standard but I think this is acceptable, since this
> >> blacklist/whitelist is basically a quirk.
> >>  - Load our portdrv on tb bridges. PCI just sees another portdriver
> >> and all the reverse engineered magic lives inside the driver.
> >>  - Forward more PM callbacks to portdrivers (not tb specific)
> >>  - hotplug D3cold fixes: resume around board_added/remove_board,
> >> ignore interrupts in d3cold (not tb specific and probably a general
> >> bugfix)
> >>  - Make pci not fail if bridges have been put into D3cold by some
> >> external mechanism.
> >>
> >> So maybe you could review the pci changes as a solution to the problem
> >> "we want to load a custom portdriver which can put bridges into d3cold
> >> in a device specific way". We certainly to not expect you to take
> >> responsibility for the thunderbolt driver.
> >
> > That's a fine solution as far as I'm personally concerned.  I think
> > it's poor for Linux overall, because I think it's fragile, and it's
> > disappointing that a technology as important as Thunderbolt is so
> > poorly supported by the promulgators.  But if you're willing to work
> > in that environment, that's great.
> >
> > You maintain the thunderbolt code and merge changes, and I'll review
> > the pieces that touch drivers/pci.  I do have a couple comments on
> > those pieces, but I don't think they'll be major.
> >
> > I just want to get out of the business of merging drivers/thunderbolt
> > code that I can't maintain.
> 
> [+ Greg]
> 
> Hi Greg,
> 
> do you mind if we

Re: [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs

On Thu, Jul 07, 2016 at 07:39:12PM +0200, Andreas Noever wrote:
> On Tue, Jun 14, 2016 at 10:22 PM, Bjorn Helgaas  wrote:
> > On Tue, Jun 14, 2016 at 09:14:27PM +0200, Andreas Noever wrote:
> >> On Tue, Jun 14, 2016 at 6:37 PM, Bjorn Helgaas  wrote:
> >> > [+cc linux-kernel]
> >> >
> >> > On Sat, May 21, 2016 at 11:48:42AM +0200, Andreas Noever wrote:
> >> >>
> >> >> Signed-off-by: Andreas Noever 
> >> >>
> >> >> Tested on MacBookPro10,1
> >> >>
> >> >> On Fri, May 13, 2016 at 1:15 PM, Lukas Wunner  wrote:
> >> >> > This series powers Thunderbolt controllers on Macs down when nothing 
> >> >> > is
> >> >> > plugged in, saving 1.7 W on machines with a Light Ridge controller and
> >> >> > reportedly 4 W on Cactus Ridge 4C and Falcon Ridge 4C.
> >> >> >
> >> >> > Briefly, a custom ACPI method provided by Apple is used to cut power 
> >> >> > to
> >> >> > the controller.  A GPE is enabled while the controller is powered down
> >> >> > which side-band signals a plug event, whereupon power is reinstated 
> >> >> > using
> >> >> > the ACPI method.  Note that even though this mechanism is ACPI-based,
> >> >> > it does not use _PSx methods and is thus entirely nonstandard.
> >> >
> >> > I think the current arrangement was that Andreas would ack Thunderbolt
> >> > patches and I would merge them via the PCI tree.  That makes some sense
> >> > because Thunderbolt and PCIe are related, but the more I think about
> >> > it, the less I'm happy with it.
> >> >
> >> > This series is a good example.  I'm sure it's good work and
> >> > worthwhile.  But I can't really say anything about the content of it
> >> > because most of it is Thunderbolt-specific and there's no public spec.
> >> > It seems like this is basically a collection of reverse-engineered
> >> > quirks that happen to work with the current state of Linux PM on
> >> > certain Macs.  We don't know what might change on future Macs.  We
> >> > don't know what might break when we make changes to Linux PM.
> >> >
> >> > I can't test this series, nor do I want to.  I can't test most of the
> >> > patches I merge, but I can at least read the spec and see whether the
> >> > patches make sense.  What I would *like* is to have public Thunderbolt
> >> > specs and a kernel developer's guide so we know what to expect from
> >> > the hardware and the firmware and we can write code that should work
> >> > not just on current Macs, but also on non-Macs and future Macs.
> >> >
> >> > I don't think the current situation is really maintainable, and I'm
> >> > not comfortable merging code that I can't maintain.
> >> Most of the code is contained within the thunderbolt driver. I think
> >> there is quite some precedence for reverse engineered drivers without
> >> specs being part of the kernel. My understanding was that, since I am
> >> listed in MAINTAINERS, I am responsible for the driver. Now our
> >> changes often need improvements to the pci core, which is why I think
> >> merging through your tree is a good idea (without transferring
> >> responsibility). The changes to the drivers/pci should be supported by
> >> the PCI-spec and make sense without knowing about thunderbolt (but it
> >> might be the case that thunderbolt is the only user of these
> >> features).
> >>
> >> Specifically for this series we want to:
> >>  - whitelist thunderbolt bridges for PM. Detecting those bridges is
> >> non-standard but I think this is acceptable, since this
> >> blacklist/whitelist is basically a quirk.
> >>  - Load our portdrv on tb bridges. PCI just sees another portdriver
> >> and all the reverse engineered magic lives inside the driver.
> >>  - Forward more PM callbacks to portdrivers (not tb specific)
> >>  - hotplug D3cold fixes: resume around board_added/remove_board,
> >> ignore interrupts in d3cold (not tb specific and probably a general
> >> bugfix)
> >>  - Make pci not fail if bridges have been put into D3cold by some
> >> external mechanism.
> >>
> >> So maybe you could review the pci changes as a solution to the problem
> >> "we want to load a custom portdriver which can put bridges into d3cold
> >> in a device specific way". We certainly to not expect you to take
> >> responsibility for the thunderbolt driver.
> >
> > That's a fine solution as far as I'm personally concerned.  I think
> > it's poor for Linux overall, because I think it's fragile, and it's
> > disappointing that a technology as important as Thunderbolt is so
> > poorly supported by the promulgators.  But if you're willing to work
> > in that environment, that's great.
> >
> > You maintain the thunderbolt code and merge changes, and I'll review
> > the pieces that touch drivers/pci.  I do have a couple comments on
> > those pieces, but I don't think they'll be major.
> >
> > I just want to get out of the business of merging drivers/thunderbolt
> > code that I can't maintain.
> 
> [+ Greg]
> 
> Hi Greg,
> 
> do you mind if we revert to the old scheme and merge TB changes
> through your tree?

I will be glad to

Re: [PATCH 4.6 00/31] 4.6.4-stable review

2016-07-08 Thread Greg Kroah-Hartman

On Thu, Jul 07, 2016 at 09:45:30PM -0600, Shuah Khan wrote:
> On 07/06/2016 07:18 PM, Greg Kroah-Hartman wrote:
> > ---
> > Note, I'm on vacation this week, so I only took a few "easy" patches for
> > the stable trees, due to me not having much time to debug anything here,
> > and because, well, I'm on vacation and supposed to be ignoring patches.
> > So if you have marked patches for inclusion, or emailed asking for
> > things to be included, and you don't see them here (which you almost
> > certainly will not), just wait a week or so before panicking please.
> > ---
> > 
> > This is the start of the stable review cycle for the 4.6.4 release.
> > There are 31 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Jul  9 01:15:40 UTC 2016.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.6.4-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.6.y
> > and the diffstat can be found below.
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing both of these and letting me know.

greg k-h

Re: [PATCH 4.6 00/31] 4.6.4-stable review

2016-07-08 Thread Greg Kroah-Hartman

On Thu, Jul 07, 2016 at 09:45:30PM -0600, Shuah Khan wrote:
> On 07/06/2016 07:18 PM, Greg Kroah-Hartman wrote:
> > ---
> > Note, I'm on vacation this week, so I only took a few "easy" patches for
> > the stable trees, due to me not having much time to debug anything here,
> > and because, well, I'm on vacation and supposed to be ignoring patches.
> > So if you have marked patches for inclusion, or emailed asking for
> > things to be included, and you don't see them here (which you almost
> > certainly will not), just wait a week or so before panicking please.
> > ---
> > 
> > This is the start of the stable review cycle for the 4.6.4 release.
> > There are 31 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Jul  9 01:15:40 UTC 2016.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.6.4-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.6.y
> > and the diffstat can be found below.
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing both of these and letting me know.

greg k-h

[PATCH v2 0/5] drivers: usb: chipidea: Add qoriq platform

Adds qoriq platform driver for chipidea controller as well as
qoriq usb 2.0 phy driver. Also, enables chipidea driver and QorIQ
USB 2.0 PHY driver on LS1021A platform.

Rajesh Bhagat (5):
  drivers: usb: chipidea: Add qoriq platform driver
  usb: DT binding documentation for qoriq usb 2.0 controller
  drivers: usb: phy: Add qoriq usb 2.0 phy driver support
  phy: DT binding documentation for qoriq usb 2.0 phy
  arm: dts: ls1021a: enable chipidea driver and USB 2.0 PHY driver

 .../devicetree/bindings/phy/qoriq-usb2-phy.txt |  22 ++
 .../devicetree/bindings/usb/ci-hdrc-qoriq.txt  |  34 +++
 arch/arm/boot/dts/ls1021a.dtsi |  15 +-
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qoriq-usb2.c   | 228 
 drivers/phy/phy-qoriq-usb2.h   |  50 +
 drivers/usb/chipidea/Makefile  |   2 +
 drivers/usb/chipidea/ci_hdrc_qoriq.c   | 237 +
 drivers/usb/chipidea/ci_hdrc_qoriq.h   |  65 ++
 10 files changed, 661 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt
 create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
 create mode 100644 drivers/phy/phy-qoriq-usb2.c
 create mode 100644 drivers/phy/phy-qoriq-usb2.h
 create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.c
 create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.h

-- 
2.6.2.198.g614a2ac

[PATCH v2 0/5] drivers: usb: chipidea: Add qoriq platform

Adds qoriq platform driver for chipidea controller as well as
qoriq usb 2.0 phy driver. Also, enables chipidea driver and QorIQ
USB 2.0 PHY driver on LS1021A platform.

Rajesh Bhagat (5):
  drivers: usb: chipidea: Add qoriq platform driver
  usb: DT binding documentation for qoriq usb 2.0 controller
  drivers: usb: phy: Add qoriq usb 2.0 phy driver support
  phy: DT binding documentation for qoriq usb 2.0 phy
  arm: dts: ls1021a: enable chipidea driver and USB 2.0 PHY driver

 .../devicetree/bindings/phy/qoriq-usb2-phy.txt |  22 ++
 .../devicetree/bindings/usb/ci-hdrc-qoriq.txt  |  34 +++
 arch/arm/boot/dts/ls1021a.dtsi |  15 +-
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qoriq-usb2.c   | 228 
 drivers/phy/phy-qoriq-usb2.h   |  50 +
 drivers/usb/chipidea/Makefile  |   2 +
 drivers/usb/chipidea/ci_hdrc_qoriq.c   | 237 +
 drivers/usb/chipidea/ci_hdrc_qoriq.h   |  65 ++
 10 files changed, 661 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt
 create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
 create mode 100644 drivers/phy/phy-qoriq-usb2.c
 create mode 100644 drivers/phy/phy-qoriq-usb2.h
 create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.c
 create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.h

-- 
2.6.2.198.g614a2ac

[PATCH v2 2/5] usb: DT binding documentation for qoriq usb 2.0 controller

Describes the qoriq usb 2.0 controller driver binding, currently used
for LS1021A and LS1012A platform.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2: 
 - Adds DT binding documentation for qoriq usb 2.0 controller
 - Changed the compatible string to fsl,ci-qoriq-usb2

 .../devicetree/bindings/usb/ci-hdrc-qoriq.txt  | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
new file mode 100644
index 000..8ad7306
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
@@ -0,0 +1,34 @@
+* Freescale QorIQ SoC USB 2.0 Controllers
+
+Required properties:
+- compatible: Should be "fsl,ci-qoriq-usb2"
+  Wherever applicable, the IP version of the USB controller should
+  also be mentioned (for eg. fsl,ci-qoriq-usb2-vX.Y).
+  where, X.Y is IP version of USB controller.
+- reg: Should contain registers location and length
+- interrupts: Should contain controller interrupt
+- phy-names: from the *Generic PHY* bindings
+- phys: from the *Generic PHY* bindings
+- clocks: clock provider specifier
+- clock-names: shall be "usb2-clock"
+Refer to clk/clock-bindings.txt for generic clock consumer properties
+
+Recommended properties:
+- dr_mode: One of "host" or "peripheral".
+- phy_type: the type of the phy connected to the core. Should be one
+  of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
+  property the PORTSC register won't be touched
+
+Examples:
+usb@860 {
+   compatible =  "fsl,ci-qoriq-usb2",
+ "fsl,ci-qoriq-usb2-v2.5";
+   reg = <0x0 0x860 0x0 0x1000>;
+   interrupts = <0 139 0x4>;
+   phy-names = "usb2-phy";
+   phys = <>;
+   clock-names = "usb2-clock";
+   clocks = < 4 3>;
+   dr_mode = "host";
+   phy_type = "ulpi";
+};
-- 
2.6.2.198.g614a2ac

[PATCH v2 3/5] drivers: usb: phy: Add qoriq usb 2.0 phy driver support

Adds qoriq usb 2.0 phy driver support for LS1021A and LS1012A
platform.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2:
 - Replaced Freescale with QorIQ in comments section
 - Changed the compatible string to fsl,qoriq-usb2-phy and added version
 - Added dependency on ARCH_MXC/ARCH_LAYERSCAPE and OF in Kconfig
 - Dropped CONFIG_ULPI #ifdefs to make code generic
 - Removed calls to devm free/release calls

 drivers/phy/Kconfig  |   8 ++
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qoriq-usb2.c | 228 +++
 drivers/phy/phy-qoriq-usb2.h |  50 ++
 4 files changed, 287 insertions(+)
 create mode 100644 drivers/phy/phy-qoriq-usb2.c
 create mode 100644 drivers/phy/phy-qoriq-usb2.h

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..cc69299 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -434,4 +434,12 @@ config PHY_CYGNUS_PCIE
 
 source "drivers/phy/tegra/Kconfig"
 
+config PHY_QORIQ_USB2
+   tristate "QorIQ USB 2.0 PHY driver"
+   depends on ARCH_MXC || ARCH_LAYERSCAPE
+   depends on OF
+   select GENERIC_PHY
+   help
+ Enable this to support the USB2.0 PHY on the QorIQ SoC.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..044105a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -53,5 +53,6 @@ obj-$(CONFIG_PHY_TUSB1210)+= phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
 obj-$(CONFIG_PHY_CYGNUS_PCIE)  += phy-bcm-cygnus-pcie.o
+obj-$(CONFIG_PHY_QORIQ_USB2)+= phy-qoriq-usb2.o
 
 obj-$(CONFIG_ARCH_TEGRA) += tegra/
diff --git a/drivers/phy/phy-qoriq-usb2.c b/drivers/phy/phy-qoriq-usb2.c
new file mode 100644
index 000..f74d255
--- /dev/null
+++ b/drivers/phy/phy-qoriq-usb2.c
@@ -0,0 +1,228 @@
+/*
+ * QorIQ SoC USB 2.0 PHY driver
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Author: Rajesh Bhagat 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "phy-qoriq-usb2.h"
+
+static int qoriq_usb2_phy_init(struct phy *_phy)
+{
+   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
+   struct device *dev = ctx->dev;
+
+   if (ctx->ulpi_phy) {
+   if (usb_phy_init(ctx->ulpi_phy)) {
+   dev_err(dev, "unable to init transceiver, probably 
missing\n");
+   return -ENODEV;
+   }
+   }
+
+   return 0;
+}
+
+static int qoriq_usb2_phy_power_on(struct phy *_phy)
+{
+   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
+   u32 flags;
+
+   if (ctx->ulpi_phy) {
+   flags = usb_phy_io_read(ctx->ulpi_phy, ULPI_OTG_CTRL);
+   usb_phy_io_write(ctx->ulpi_phy, flags |
+(ULPI_OTG_CTRL_DRVVBUS_EXT |
+ULPI_OTG_CTRL_EXTVBUSIND), ULPI_OTG_CTRL);
+   flags = usb_phy_io_read(ctx->ulpi_phy, ULPI_IFC_CTRL);
+   usb_phy_io_write(ctx->ulpi_phy, flags |
+(ULPI_IFC_CTRL_EXTERNAL_VBUS |
+ULPI_IFC_CTRL_PASSTHRU), ULPI_IFC_CTRL);
+   }
+
+   return 0;
+}
+
+static int qoriq_usb2_phy_power_off(struct phy *_phy)
+{
+   /* TODO: Add logic to power off phy */
+
+   return 0;
+}
+
+static int qoriq_usb2_phy_exit(struct phy *_phy)
+{
+   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
+
+   if (ctx->ulpi_phy)
+   usb_phy_shutdown(ctx->ulpi_phy);
+
+   return 0;
+}
+
+static const struct phy_ops ops = {
+   .init   = qoriq_usb2_phy_init,
+   .power_on   = qoriq_usb2_phy_power_on,
+   .power_off  = qoriq_usb2_phy_power_off,
+   .exit   = qoriq_usb2_phy_exit,
+   .owner  = THIS_MODULE,
+};
+
+
+static enum qoriq_usb2_phy_ver of_usb_get_phy_version(struct device_node *np)
+{
+   enum qoriq_usb2_phy_ver phy_version = QORIQ_PHY_UNKNOWN;
+
+   if (of_device_is_compatible(np, "fsl,qoriq-usb2-phy")) {
+   if (of_device_is_compatible(np, "fsl,qoriq-usb2-phy-v1.0"))
+   phy_version = QORIQ_PHY_LEGACY;
+   else if (of_device_is_compatible(np, "fsl,qoriq-usb2-phy-v2.0"))
+   phy_version = QORIQ_PHY_NXP_ISP1508;
+   }
+   return phy_version;
+}
+
+static int qoriq_usb2_phy_probe(struct platform_device *pdev)
+{
+   int ret;
+   struct resource *res;
+   struct qoriq_usb2_phy_ctx *ctx;
+   struct device *dev = >dev;
+   const struct

[PATCH v2 2/5] usb: DT binding documentation for qoriq usb 2.0 controller

Describes the qoriq usb 2.0 controller driver binding, currently used
for LS1021A and LS1012A platform.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2: 
 - Adds DT binding documentation for qoriq usb 2.0 controller
 - Changed the compatible string to fsl,ci-qoriq-usb2

 .../devicetree/bindings/usb/ci-hdrc-qoriq.txt  | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
new file mode 100644
index 000..8ad7306
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qoriq.txt
@@ -0,0 +1,34 @@
+* Freescale QorIQ SoC USB 2.0 Controllers
+
+Required properties:
+- compatible: Should be "fsl,ci-qoriq-usb2"
+  Wherever applicable, the IP version of the USB controller should
+  also be mentioned (for eg. fsl,ci-qoriq-usb2-vX.Y).
+  where, X.Y is IP version of USB controller.
+- reg: Should contain registers location and length
+- interrupts: Should contain controller interrupt
+- phy-names: from the *Generic PHY* bindings
+- phys: from the *Generic PHY* bindings
+- clocks: clock provider specifier
+- clock-names: shall be "usb2-clock"
+Refer to clk/clock-bindings.txt for generic clock consumer properties
+
+Recommended properties:
+- dr_mode: One of "host" or "peripheral".
+- phy_type: the type of the phy connected to the core. Should be one
+  of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
+  property the PORTSC register won't be touched
+
+Examples:
+usb@860 {
+   compatible =  "fsl,ci-qoriq-usb2",
+ "fsl,ci-qoriq-usb2-v2.5";
+   reg = <0x0 0x860 0x0 0x1000>;
+   interrupts = <0 139 0x4>;
+   phy-names = "usb2-phy";
+   phys = <>;
+   clock-names = "usb2-clock";
+   clocks = < 4 3>;
+   dr_mode = "host";
+   phy_type = "ulpi";
+};
-- 
2.6.2.198.g614a2ac

[PATCH v2 3/5] drivers: usb: phy: Add qoriq usb 2.0 phy driver support

Adds qoriq usb 2.0 phy driver support for LS1021A and LS1012A
platform.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2:
 - Replaced Freescale with QorIQ in comments section
 - Changed the compatible string to fsl,qoriq-usb2-phy and added version
 - Added dependency on ARCH_MXC/ARCH_LAYERSCAPE and OF in Kconfig
 - Dropped CONFIG_ULPI #ifdefs to make code generic
 - Removed calls to devm free/release calls

 drivers/phy/Kconfig  |   8 ++
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qoriq-usb2.c | 228 +++
 drivers/phy/phy-qoriq-usb2.h |  50 ++
 4 files changed, 287 insertions(+)
 create mode 100644 drivers/phy/phy-qoriq-usb2.c
 create mode 100644 drivers/phy/phy-qoriq-usb2.h

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..cc69299 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -434,4 +434,12 @@ config PHY_CYGNUS_PCIE
 
 source "drivers/phy/tegra/Kconfig"
 
+config PHY_QORIQ_USB2
+   tristate "QorIQ USB 2.0 PHY driver"
+   depends on ARCH_MXC || ARCH_LAYERSCAPE
+   depends on OF
+   select GENERIC_PHY
+   help
+ Enable this to support the USB2.0 PHY on the QorIQ SoC.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..044105a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -53,5 +53,6 @@ obj-$(CONFIG_PHY_TUSB1210)+= phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
 obj-$(CONFIG_PHY_CYGNUS_PCIE)  += phy-bcm-cygnus-pcie.o
+obj-$(CONFIG_PHY_QORIQ_USB2)+= phy-qoriq-usb2.o
 
 obj-$(CONFIG_ARCH_TEGRA) += tegra/
diff --git a/drivers/phy/phy-qoriq-usb2.c b/drivers/phy/phy-qoriq-usb2.c
new file mode 100644
index 000..f74d255
--- /dev/null
+++ b/drivers/phy/phy-qoriq-usb2.c
@@ -0,0 +1,228 @@
+/*
+ * QorIQ SoC USB 2.0 PHY driver
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Author: Rajesh Bhagat 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "phy-qoriq-usb2.h"
+
+static int qoriq_usb2_phy_init(struct phy *_phy)
+{
+   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
+   struct device *dev = ctx->dev;
+
+   if (ctx->ulpi_phy) {
+   if (usb_phy_init(ctx->ulpi_phy)) {
+   dev_err(dev, "unable to init transceiver, probably 
missing\n");
+   return -ENODEV;
+   }
+   }
+
+   return 0;
+}
+
+static int qoriq_usb2_phy_power_on(struct phy *_phy)
+{
+   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
+   u32 flags;
+
+   if (ctx->ulpi_phy) {
+   flags = usb_phy_io_read(ctx->ulpi_phy, ULPI_OTG_CTRL);
+   usb_phy_io_write(ctx->ulpi_phy, flags |
+(ULPI_OTG_CTRL_DRVVBUS_EXT |
+ULPI_OTG_CTRL_EXTVBUSIND), ULPI_OTG_CTRL);
+   flags = usb_phy_io_read(ctx->ulpi_phy, ULPI_IFC_CTRL);
+   usb_phy_io_write(ctx->ulpi_phy, flags |
+(ULPI_IFC_CTRL_EXTERNAL_VBUS |
+ULPI_IFC_CTRL_PASSTHRU), ULPI_IFC_CTRL);
+   }
+
+   return 0;
+}
+
+static int qoriq_usb2_phy_power_off(struct phy *_phy)
+{
+   /* TODO: Add logic to power off phy */
+
+   return 0;
+}
+
+static int qoriq_usb2_phy_exit(struct phy *_phy)
+{
+   struct qoriq_usb2_phy_ctx *ctx = phy_get_drvdata(_phy);
+
+   if (ctx->ulpi_phy)
+   usb_phy_shutdown(ctx->ulpi_phy);
+
+   return 0;
+}
+
+static const struct phy_ops ops = {
+   .init   = qoriq_usb2_phy_init,
+   .power_on   = qoriq_usb2_phy_power_on,
+   .power_off  = qoriq_usb2_phy_power_off,
+   .exit   = qoriq_usb2_phy_exit,
+   .owner  = THIS_MODULE,
+};
+
+
+static enum qoriq_usb2_phy_ver of_usb_get_phy_version(struct device_node *np)
+{
+   enum qoriq_usb2_phy_ver phy_version = QORIQ_PHY_UNKNOWN;
+
+   if (of_device_is_compatible(np, "fsl,qoriq-usb2-phy")) {
+   if (of_device_is_compatible(np, "fsl,qoriq-usb2-phy-v1.0"))
+   phy_version = QORIQ_PHY_LEGACY;
+   else if (of_device_is_compatible(np, "fsl,qoriq-usb2-phy-v2.0"))
+   phy_version = QORIQ_PHY_NXP_ISP1508;
+   }
+   return phy_version;
+}
+
+static int qoriq_usb2_phy_probe(struct platform_device *pdev)
+{
+   int ret;
+   struct resource *res;
+   struct qoriq_usb2_phy_ctx *ctx;
+   struct device *dev = >dev;
+   const struct of_device_id *of_id;
+   struct

[PATCH v2 5/5] arm: dts: ls1021a: enable chipidea driver and USB 2.0 PHY driver

This patch adds entries in dts to enable chipidea platform driver
and USB 2.0 PHY driver.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2:
 - Reworked for latest changes

 arch/arm/boot/dts/ls1021a.dtsi | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 5ae8e92..bbba1ba 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -612,10 +612,23 @@
};
};
 
+   usbphy0: usbphy@860 {
+   compatible = "fsl,qoriq-usb2-phy",
+"fsl,qoriq-usb2-phy-v1.0";
+   reg = <0x0 0x860 0x0 0x1000>;
+   #phy-cells = <0>;
+   phy_type = "ulpi";
+   };
+
usb@860 {
-   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+   compatible =  "fsl,ci-qoriq-usb2",
+ "fsl,ci-qoriq-usb2-v2.5";
reg = <0x0 0x860 0x0 0x1000>;
interrupts = ;
+   phy-names = "usb2-phy";
+   phys = <>;
+   clock-names = "usb2-clock";
+   clocks = <_clk 1>;
dr_mode = "host";
phy_type = "ulpi";
};
-- 
2.6.2.198.g614a2ac

[PATCH v2 5/5] arm: dts: ls1021a: enable chipidea driver and USB 2.0 PHY driver

This patch adds entries in dts to enable chipidea platform driver
and USB 2.0 PHY driver.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2:
 - Reworked for latest changes

 arch/arm/boot/dts/ls1021a.dtsi | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 5ae8e92..bbba1ba 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -612,10 +612,23 @@
};
};
 
+   usbphy0: usbphy@860 {
+   compatible = "fsl,qoriq-usb2-phy",
+"fsl,qoriq-usb2-phy-v1.0";
+   reg = <0x0 0x860 0x0 0x1000>;
+   #phy-cells = <0>;
+   phy_type = "ulpi";
+   };
+
usb@860 {
-   compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+   compatible =  "fsl,ci-qoriq-usb2",
+ "fsl,ci-qoriq-usb2-v2.5";
reg = <0x0 0x860 0x0 0x1000>;
interrupts = ;
+   phy-names = "usb2-phy";
+   phys = <>;
+   clock-names = "usb2-clock";
+   clocks = <_clk 1>;
dr_mode = "host";
phy_type = "ulpi";
};
-- 
2.6.2.198.g614a2ac

[PATCH v1] Specific requirement of type casting for 64-bit architectures.

2016-07-08 Thread Arvind Yadav

-Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
assigned in ucc_fast_tx_virtual_fifo_base_offset and
ucc_fast_rx_virtual_fifo_base_offset. It will work on 32-bit architectures
But data can be loss on 64-bit architectures if 'qe_muram_alloc' will
return greater then MAX value of 'unsigned int'.

-Passing value in IS_ERR_VALUE() is wrong, as they pass an 'unsigned int'
into a function, It will through this compilation warning.

"
 include/linux/err.h:21:49: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
 #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
 ^
 include/linux/compiler.h:170:42: note: in definition of macro ‘unlikely’
 # define unlikely(x) __builtin_expect(!!(x), 0)
"

-Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'unsigned int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Signed-off-by: Arvind Yadav 
---
 drivers/soc/fsl/qe/ucc_fast.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/fsl/qe/ucc_fast.c b/drivers/soc/fsl/qe/ucc_fast.c
index a768931..208b198 100644
--- a/drivers/soc/fsl/qe/ucc_fast.c
+++ b/drivers/soc/fsl/qe/ucc_fast.c
@@ -141,6 +141,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct 
ucc_fast_private ** ucc
struct ucc_fast __iomem *uf_regs;
u32 gumr;
int ret;
+   unsigned long ret_muram;
 
if (!uf_info)
return -EINVAL;
@@ -265,28 +266,34 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct 
ucc_fast_private ** ucc
gumr |= uf_info->mode;
out_be32(_regs->gumr, gumr);
 
-   /* Allocate memory for Tx Virtual Fifo */
-   uccf->ucc_fast_tx_virtual_fifo_base_offset =
-   qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
-   if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
+   ret_muram =
+   qe_muram_alloc(uf_info->utfs,
+   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
+
+   if (IS_ERR_VALUE(ret_muram)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
+   } else {
+   /* Allocate memory for Tx Virtual Fifo */
+   uccf->ucc_fast_tx_virtual_fifo_base_offset = (u32)ret_muram;
}
 
-   /* Allocate memory for Rx Virtual Fifo */
-   uccf->ucc_fast_rx_virtual_fifo_base_offset =
+   ret_muram =
qe_muram_alloc(uf_info->urfs +
   UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
-   if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
+   if (IS_ERR_VALUE(ret_muram)) {
printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
__func__);
uccf->ucc_fast_rx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
+   } else {
+   /* Allocate memory for Rx Virtual Fifo */
+   uccf->ucc_fast_rx_virtual_fifo_base_offset = (u32)ret_muram;
}
 
/* Set Virtual Fifo registers */
-- 
1.9.1

[PATCH v1] Specific requirement of type casting for 64-bit architectures.

2016-07-08 Thread Arvind Yadav

-Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
assigned in ucc_fast_tx_virtual_fifo_base_offset and
ucc_fast_rx_virtual_fifo_base_offset. It will work on 32-bit architectures
But data can be loss on 64-bit architectures if 'qe_muram_alloc' will
return greater then MAX value of 'unsigned int'.

-Passing value in IS_ERR_VALUE() is wrong, as they pass an 'unsigned int'
into a function, It will through this compilation warning.

"
 include/linux/err.h:21:49: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
 #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
 ^
 include/linux/compiler.h:170:42: note: in definition of macro ‘unlikely’
 # define unlikely(x) __builtin_expect(!!(x), 0)
"

-Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'unsigned int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Signed-off-by: Arvind Yadav 
---
 drivers/soc/fsl/qe/ucc_fast.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/fsl/qe/ucc_fast.c b/drivers/soc/fsl/qe/ucc_fast.c
index a768931..208b198 100644
--- a/drivers/soc/fsl/qe/ucc_fast.c
+++ b/drivers/soc/fsl/qe/ucc_fast.c
@@ -141,6 +141,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct 
ucc_fast_private ** ucc
struct ucc_fast __iomem *uf_regs;
u32 gumr;
int ret;
+   unsigned long ret_muram;
 
if (!uf_info)
return -EINVAL;
@@ -265,28 +266,34 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct 
ucc_fast_private ** ucc
gumr |= uf_info->mode;
out_be32(_regs->gumr, gumr);
 
-   /* Allocate memory for Tx Virtual Fifo */
-   uccf->ucc_fast_tx_virtual_fifo_base_offset =
-   qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
-   if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
+   ret_muram =
+   qe_muram_alloc(uf_info->utfs,
+   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
+
+   if (IS_ERR_VALUE(ret_muram)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
+   } else {
+   /* Allocate memory for Tx Virtual Fifo */
+   uccf->ucc_fast_tx_virtual_fifo_base_offset = (u32)ret_muram;
}
 
-   /* Allocate memory for Rx Virtual Fifo */
-   uccf->ucc_fast_rx_virtual_fifo_base_offset =
+   ret_muram =
qe_muram_alloc(uf_info->urfs +
   UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
-   if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
+   if (IS_ERR_VALUE(ret_muram)) {
printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
__func__);
uccf->ucc_fast_rx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
+   } else {
+   /* Allocate memory for Rx Virtual Fifo */
+   uccf->ucc_fast_rx_virtual_fifo_base_offset = (u32)ret_muram;
}
 
/* Set Virtual Fifo registers */
-- 
1.9.1

[PATCH v2 1/5] drivers: usb: chipidea: Add qoriq platform driver

Adds qoriq platform driver for chipidea controller,
verfied on LS1021A and LS1012A platforms.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2:
 - Replaced Freescale with QorIQ in comments section
 - Added macros to remove hardcoding while programming registers
 - Changed the compatible string to fsl,ci-qoriq-usb2 and added version
 - Removed calls to devm free/release calls 

 drivers/usb/chipidea/Makefile|   2 +
 drivers/usb/chipidea/ci_hdrc_qoriq.c | 237 +++
 drivers/usb/chipidea/ci_hdrc_qoriq.h |  65 ++
 3 files changed, 304 insertions(+)
 create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.c
 create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.h

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 518e445..3122b86b 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -14,3 +14,5 @@ obj-$(CONFIG_USB_CHIPIDEA)+= ci_hdrc_zevio.o
 obj-$(CONFIG_USB_CHIPIDEA_PCI) += ci_hdrc_pci.o
 
 obj-$(CONFIG_USB_CHIPIDEA_OF)  += usbmisc_imx.o ci_hdrc_imx.o
+
+obj-$(CONFIG_USB_CHIPIDEA)  += ci_hdrc_qoriq.o
diff --git a/drivers/usb/chipidea/ci_hdrc_qoriq.c 
b/drivers/usb/chipidea/ci_hdrc_qoriq.c
new file mode 100644
index 000..3f478c6
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_qoriq.c
@@ -0,0 +1,237 @@
+/*
+ * QorIQ SoC USB 2.0 Controller driver
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Author: Rajesh Bhagat 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ci.h"
+#include "ci_hdrc_qoriq.h"
+
+struct ci_hdrc_qoriq_data {
+   struct phy *phy;
+   struct clk *clk;
+   void __iomem *qoriq_regs;
+   struct platform_device *ci_pdev;
+   enum usb_phy_interface phy_mode;
+};
+
+/*
+ * clock helper functions
+ */
+static int ci_hdrc_qoriq_get_clks(struct platform_device *pdev)
+{
+   int ret;
+   struct device *dev = >dev;
+   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
+
+   data->clk = devm_clk_get(dev, "usb2-clock");
+   if (IS_ERR(data->clk)) {
+   dev_err(dev, "failed to get clk, err=%ld\n",
+   PTR_ERR(data->clk));
+   return ret;
+   }
+   return 0;
+}
+
+static int ci_hdrc_qoriq_prepare_enable_clks(struct platform_device *pdev)
+{
+   int ret;
+   struct device *dev = >dev;
+   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
+
+   ret = clk_prepare_enable(data->clk);
+   if (ret) {
+   dev_err(dev, "failed to prepare/enable clk, err=%d\n", ret);
+   return ret;
+   }
+   return 0;
+}
+
+static void ci_hdrc_qoriq_disable_unprepare_clks(struct platform_device *pdev)
+{
+   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
+
+   clk_disable_unprepare(data->clk);
+}
+
+static int ci_hdrc_qoriq_usb_setup(struct platform_device *pdev)
+{
+   u32 reg;
+   struct resource *res;
+   struct device *dev = >dev;
+   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   dev_err(dev, "failed to get I/O memory\n");
+   return -ENOENT;
+   }
+
+   dev_dbg(dev, "res->start %llx, resource_size(res) %llx\n", res->start,
+   resource_size(res));
+   data->qoriq_regs = devm_ioremap(dev, res->start, resource_size(res));
+   if (IS_ERR(data->qoriq_regs)) {
+   dev_err(dev, "failed to remap I/O memory\n");
+   return -ENOMEM;
+   }
+
+   data->phy_mode = of_usb_get_phy_mode(pdev->dev.of_node);
+   dev_dbg(dev, "phy_mode %d\n", data->phy_mode);
+
+   reg = ioread32be(data->qoriq_regs + QORIQ_SOC_USB_CTRL);
+   switch (data->phy_mode) {
+   case USBPHY_INTERFACE_MODE_ULPI:
+   iowrite32be(reg | ~UTMI_PHY_EN,
+   data->qoriq_regs + QORIQ_SOC_USB_CTRL);
+   reg = ioread32be(data->qoriq_regs + QORIQ_SOC_USB_CTRL);
+   iowrite32be(reg | USB_CTRL_USB_EN,
+   data->qoriq_regs + QORIQ_SOC_USB_CTRL);
+   break;
+   default:
+   dev_err(dev, "unsupported phy_mode %d\n", data->phy_mode);
+   return -EINVAL;
+   }
+
+   /* Setup Snooping for all the 4GB space */
+   /* SNOOP1 starts from 0x0, size 2G */
+   iowrite32be(SNOOP_SIZE_2GB, data->qoriq_regs + QORIQ_SOC_USB_SNOOP1);
+   /* SNOOP2 starts from 0x8000, size 2G */
+   iowrite32be(SNOOP_SIZE_2GB | 0x8000,
+   data->qoriq_regs + QORIQ_SOC_USB_SNOOP2);
+
+

[PATCH v2 1/5] drivers: usb: chipidea: Add qoriq platform driver

Adds qoriq platform driver for chipidea controller,
verfied on LS1021A and LS1012A platforms.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2:
 - Replaced Freescale with QorIQ in comments section
 - Added macros to remove hardcoding while programming registers
 - Changed the compatible string to fsl,ci-qoriq-usb2 and added version
 - Removed calls to devm free/release calls 

 drivers/usb/chipidea/Makefile|   2 +
 drivers/usb/chipidea/ci_hdrc_qoriq.c | 237 +++
 drivers/usb/chipidea/ci_hdrc_qoriq.h |  65 ++
 3 files changed, 304 insertions(+)
 create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.c
 create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.h

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 518e445..3122b86b 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -14,3 +14,5 @@ obj-$(CONFIG_USB_CHIPIDEA)+= ci_hdrc_zevio.o
 obj-$(CONFIG_USB_CHIPIDEA_PCI) += ci_hdrc_pci.o
 
 obj-$(CONFIG_USB_CHIPIDEA_OF)  += usbmisc_imx.o ci_hdrc_imx.o
+
+obj-$(CONFIG_USB_CHIPIDEA)  += ci_hdrc_qoriq.o
diff --git a/drivers/usb/chipidea/ci_hdrc_qoriq.c 
b/drivers/usb/chipidea/ci_hdrc_qoriq.c
new file mode 100644
index 000..3f478c6
--- /dev/null
+++ b/drivers/usb/chipidea/ci_hdrc_qoriq.c
@@ -0,0 +1,237 @@
+/*
+ * QorIQ SoC USB 2.0 Controller driver
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Author: Rajesh Bhagat 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ci.h"
+#include "ci_hdrc_qoriq.h"
+
+struct ci_hdrc_qoriq_data {
+   struct phy *phy;
+   struct clk *clk;
+   void __iomem *qoriq_regs;
+   struct platform_device *ci_pdev;
+   enum usb_phy_interface phy_mode;
+};
+
+/*
+ * clock helper functions
+ */
+static int ci_hdrc_qoriq_get_clks(struct platform_device *pdev)
+{
+   int ret;
+   struct device *dev = >dev;
+   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
+
+   data->clk = devm_clk_get(dev, "usb2-clock");
+   if (IS_ERR(data->clk)) {
+   dev_err(dev, "failed to get clk, err=%ld\n",
+   PTR_ERR(data->clk));
+   return ret;
+   }
+   return 0;
+}
+
+static int ci_hdrc_qoriq_prepare_enable_clks(struct platform_device *pdev)
+{
+   int ret;
+   struct device *dev = >dev;
+   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
+
+   ret = clk_prepare_enable(data->clk);
+   if (ret) {
+   dev_err(dev, "failed to prepare/enable clk, err=%d\n", ret);
+   return ret;
+   }
+   return 0;
+}
+
+static void ci_hdrc_qoriq_disable_unprepare_clks(struct platform_device *pdev)
+{
+   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
+
+   clk_disable_unprepare(data->clk);
+}
+
+static int ci_hdrc_qoriq_usb_setup(struct platform_device *pdev)
+{
+   u32 reg;
+   struct resource *res;
+   struct device *dev = >dev;
+   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   dev_err(dev, "failed to get I/O memory\n");
+   return -ENOENT;
+   }
+
+   dev_dbg(dev, "res->start %llx, resource_size(res) %llx\n", res->start,
+   resource_size(res));
+   data->qoriq_regs = devm_ioremap(dev, res->start, resource_size(res));
+   if (IS_ERR(data->qoriq_regs)) {
+   dev_err(dev, "failed to remap I/O memory\n");
+   return -ENOMEM;
+   }
+
+   data->phy_mode = of_usb_get_phy_mode(pdev->dev.of_node);
+   dev_dbg(dev, "phy_mode %d\n", data->phy_mode);
+
+   reg = ioread32be(data->qoriq_regs + QORIQ_SOC_USB_CTRL);
+   switch (data->phy_mode) {
+   case USBPHY_INTERFACE_MODE_ULPI:
+   iowrite32be(reg | ~UTMI_PHY_EN,
+   data->qoriq_regs + QORIQ_SOC_USB_CTRL);
+   reg = ioread32be(data->qoriq_regs + QORIQ_SOC_USB_CTRL);
+   iowrite32be(reg | USB_CTRL_USB_EN,
+   data->qoriq_regs + QORIQ_SOC_USB_CTRL);
+   break;
+   default:
+   dev_err(dev, "unsupported phy_mode %d\n", data->phy_mode);
+   return -EINVAL;
+   }
+
+   /* Setup Snooping for all the 4GB space */
+   /* SNOOP1 starts from 0x0, size 2G */
+   iowrite32be(SNOOP_SIZE_2GB, data->qoriq_regs + QORIQ_SOC_USB_SNOOP1);
+   /* SNOOP2 starts from 0x8000, size 2G */
+   iowrite32be(SNOOP_SIZE_2GB | 0x8000,
+   data->qoriq_regs + QORIQ_SOC_USB_SNOOP2);
+
+   iowrite32be(PRICTRL_PRI_LVL, data->qoriq_regs +

[PATCH v2 4/5] phy: DT binding documentation for qoriq usb 2.0 phy

Describes the qoriq usb 2.0 phy driver binding, currently used
for LS1021A and LS1012A platform.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2:
 - Adds DT binding documentation for qoriq usb 2.0 phy
 - Changed the compatible string to fsl,qoriq-usb2-phy

 .../devicetree/bindings/phy/qoriq-usb2-phy.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt
new file mode 100644
index 000..f043855
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt
@@ -0,0 +1,22 @@
+QorIQ SoC USB 2.0 PHY
+
+Required properties:
+ - compatible: should be "fsl,qoriq-usb2-phy",
+   Wherever applicable, the version of the USB PHY should
+   also be mentioned (for eg. fsl,qoriq-usb2-phy-vX.Y).
+   where, X = Phy vendor(Legacy = 1, NXP = 2) and Y = PHY version
+ - reg : Address and length of the usb phy control register set.
+ - phy_type : For multi port host USB controllers, should be one of
+   "ulpi", or "serial". For dual role USB controllers, should be
+   one of "ulpi", "utmi", "utmi_wide", or "serial".
+
+The main purpose of this PHY driver is to enable the USB PHY reference clock
+gate on the QorIQ SOC for USB2 PHY OR implement errata workaround in
+future. Otherwise it is just an NOP PHY driver.
+
+usbphy0: usbphy@860 {
+compatible = "fsl,qoriq-usb2-phy" "fsl,qoriq-usb2-phy-vX.Y";
+reg = <0x0 0x860 0x0 0x1000>;
+#phy-cells = <0>;
+phy_type = "ulpi";
+};
-- 
2.6.2.198.g614a2ac

[PATCH v2 4/5] phy: DT binding documentation for qoriq usb 2.0 phy

Describes the qoriq usb 2.0 phy driver binding, currently used
for LS1021A and LS1012A platform.

Signed-off-by: Rajesh Bhagat 
---
Changes in v2:
 - Adds DT binding documentation for qoriq usb 2.0 phy
 - Changed the compatible string to fsl,qoriq-usb2-phy

 .../devicetree/bindings/phy/qoriq-usb2-phy.txt | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt
new file mode 100644
index 000..f043855
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qoriq-usb2-phy.txt
@@ -0,0 +1,22 @@
+QorIQ SoC USB 2.0 PHY
+
+Required properties:
+ - compatible: should be "fsl,qoriq-usb2-phy",
+   Wherever applicable, the version of the USB PHY should
+   also be mentioned (for eg. fsl,qoriq-usb2-phy-vX.Y).
+   where, X = Phy vendor(Legacy = 1, NXP = 2) and Y = PHY version
+ - reg : Address and length of the usb phy control register set.
+ - phy_type : For multi port host USB controllers, should be one of
+   "ulpi", or "serial". For dual role USB controllers, should be
+   one of "ulpi", "utmi", "utmi_wide", or "serial".
+
+The main purpose of this PHY driver is to enable the USB PHY reference clock
+gate on the QorIQ SOC for USB2 PHY OR implement errata workaround in
+future. Otherwise it is just an NOP PHY driver.
+
+usbphy0: usbphy@860 {
+compatible = "fsl,qoriq-usb2-phy" "fsl,qoriq-usb2-phy-vX.Y";
+reg = <0x0 0x860 0x0 0x1000>;
+#phy-cells = <0>;
+phy_type = "ulpi";
+};
-- 
2.6.2.198.g614a2ac

Re: [PATCH net-next] net: dsa: initialize the routing table

From: Vivien Didelot 
Date: Wed,  6 Jul 2016 20:03:54 -0400

> The routing table of every switch in a tree is currently initialized to
> all zeros. This is an issue since 0 is a valid port number.
> 
> Add a DSA_RTABLE_NONE=-1 constant to initialize the signed values of the
> routing table pointing to other switches.
> 
> This fixes the device mapping of the mv88e6xxx driver where the port
> pointing to the switch itself and to non-existent switches was wrongly
> configured to be 0. It is now set to the expected 0xf value.
> 
> Signed-off-by: Vivien Didelot 

Applied.

Re: [PATCH net-next] net: dsa: initialize the routing table

From: Vivien Didelot 
Date: Wed,  6 Jul 2016 20:03:54 -0400

> The routing table of every switch in a tree is currently initialized to
> all zeros. This is an issue since 0 is a valid port number.
> 
> Add a DSA_RTABLE_NONE=-1 constant to initialize the signed values of the
> routing table pointing to other switches.
> 
> This fixes the device mapping of the mv88e6xxx driver where the port
> pointing to the switch itself and to non-existent switches was wrongly
> configured to be 0. It is now set to the expected 0xf value.
> 
> Signed-off-by: Vivien Didelot 

Applied.

Re: [GIT PULL net-next] rxrpc: Improve conn/call lookup and fix call number generation [ver #3]

From: David Howells 
Date: Wed, 06 Jul 2016 11:48:15 +0100

> Hi Dave,
> 
> Can you pull this into net-next please?

I'll pull, but this is not how I want you to operate.

If you change stuff, you must repost the entire series.  And this is
one of many reasons I want people to keep patch sets small, so that
this is less painful.

But the whole series repost is absolutely required.

I don't care if you just add a "." to the end of a sentence, I want to
see the series reposted for review in it's entirety.

Thanks.

Re: [GIT PULL net-next] rxrpc: Improve conn/call lookup and fix call number generation [ver #3]

From: David Howells 
Date: Wed, 06 Jul 2016 11:48:15 +0100

> Hi Dave,
> 
> Can you pull this into net-next please?

I'll pull, but this is not how I want you to operate.

If you change stuff, you must repost the entire series.  And this is
one of many reasons I want people to keep patch sets small, so that
this is less painful.

But the whole series repost is absolutely required.

I don't care if you just add a "." to the end of a sentence, I want to
see the series reposted for review in it's entirety.

Thanks.

Re: [PATCH net] r8152: remove the setting of LAN_WAKE_EN

From: Hayes Wang 
Date: Wed, 6 Jul 2016 17:03:29 +0800

> The LAN_WAKE_EN is not used to determine if the device could support
> WOL. It is used to sigal a GPIO pin when a WOL event occurs. The WOL
> still works even though it is disabled.
> 
> Signed-off-by: Hayes Wang 

Applied.

Re: [PATCH net] r8152: remove the setting of LAN_WAKE_EN

From: Hayes Wang 
Date: Wed, 6 Jul 2016 17:03:29 +0800

> The LAN_WAKE_EN is not used to determine if the device could support
> WOL. It is used to sigal a GPIO pin when a WOL event occurs. The WOL
> still works even though it is disabled.
> 
> Signed-off-by: Hayes Wang 

Applied.

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On 2016/7/8 21:22, Lorenzo Pieralisi wrote:

On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:

[...]

Anyway let's avoid these petty arguments, I agree there must be some
sort of ARM64 ACPI maintainership for the reasons you mentioned above.

To avoid confusion on who's going to push stuff to Linus, I can do
that, but it must be clear whose ACKs are needed for that to happen.
That may be one person or all of you, whatever you decide.

I think the reasoning is the same, to avoid confusion and avoid stepping
on each other toes it is best to have a single gatekeeper (still
multiple maintainer entries to keep patches reviewed correctly), if no
one complains I will do that and a) provide ACKs (I will definitely
require and request Hanjun and Sudeep ones too appropriately on a per
patch basis) and b) send you pull requests.

Fine to me.

Having a maintainer per file would be farcical, I really do not

Agree, but having three of us in maintainer entries in MAINTAINERS
file will help the patches be reviewed correctly with more eyes.

expect that amount of traffic for drivers/acpi/arm64 therefore I
really doubt there is any risk of me slowing things down.

Does this sound reasonable ? Comments/complaints welcome, please
manifest yourselves.

Fair enough. What I'm concern most is land ACPI on ARM64 soundly,
let's do that :)

OK, let's back to this patch set, Fuwei already prepared a new version
of patches [1] (moving acpi_gtdt.c to drivers/acpi/arm64/ and add a
maintainer entries patch), shall we review and comment on this patch
set for now, or just let Fuwei send out the new version?

[1]:
https://git.linaro.org/people/fu.wei/linux.git/shortlog/refs/heads/topic-gtdt-wakeup-timer_upstream_v7_devel

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

On 2016/7/8 21:22, Lorenzo Pieralisi wrote:

On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:

[...]

Anyway let's avoid these petty arguments, I agree there must be some
sort of ARM64 ACPI maintainership for the reasons you mentioned above.

To avoid confusion on who's going to push stuff to Linus, I can do
that, but it must be clear whose ACKs are needed for that to happen.
That may be one person or all of you, whatever you decide.

Fine to me.

Having a maintainer per file would be farcical, I really do not

Agree, but having three of us in maintainer entries in MAINTAINERS
file will help the patches be reviewed correctly with more eyes.

expect that amount of traffic for drivers/acpi/arm64 therefore I
really doubt there is any risk of me slowing things down.

Does this sound reasonable ? Comments/complaints welcome, please
manifest yourselves.

Fair enough. What I'm concern most is land ACPI on ARM64 soundly,
let's do that :)

[1]:
https://git.linaro.org/people/fu.wei/linux.git/shortlog/refs/heads/topic-gtdt-wakeup-timer_upstream_v7_devel

Thanks
Hanjun

Re: [PATCH net] net: mvneta: set real interrupt per packet for tx_done

From: Marcin Wojtas 
Date: Wed,  6 Jul 2016 04:18:58 +0200

> From: Dmitri Epshtein 
> 
> Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
> set coalescing threshold to a value guaranteeing interrupt generation
> per each sent packet, so that buffers can be released with no delay.
> 
> In fact setting threshold to '1' was wrong, because it causes interrupt
> every two packets. According to the documentation a reason behind it is
> following - interrupt occurs once sent buffers counter reaches a value,
> which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
> behavior was confirmed during tests. Also when testing the SoC working
> as a NAS device, better performance was observed with int-per-packet,
> as it strongly depends on the fact that all transmitted packets are
> released immediately.
> 
> This commit enables NETA controller work in interrupt per sent packet mode
> by setting coalescing threshold to 0.
> 
> Signed-off-by: Dmitri Epshtein 
> Signed-off-by: Marcin Wojtas 
> Cc:  # v3.10+
> Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")

Applied, thanks.

Re: [PATCH net] net: mvneta: set real interrupt per packet for tx_done

From: Marcin Wojtas 
Date: Wed,  6 Jul 2016 04:18:58 +0200

> From: Dmitri Epshtein 
> 
> Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
> set coalescing threshold to a value guaranteeing interrupt generation
> per each sent packet, so that buffers can be released with no delay.
> 
> In fact setting threshold to '1' was wrong, because it causes interrupt
> every two packets. According to the documentation a reason behind it is
> following - interrupt occurs once sent buffers counter reaches a value,
> which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
> behavior was confirmed during tests. Also when testing the SoC working
> as a NAS device, better performance was observed with int-per-packet,
> as it strongly depends on the fact that all transmitted packets are
> released immediately.
> 
> This commit enables NETA controller work in interrupt per sent packet mode
> by setting coalescing threshold to 0.
> 
> Signed-off-by: Dmitri Epshtein 
> Signed-off-by: Marcin Wojtas 
> Cc:  # v3.10+
> Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")

Applied, thanks.

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM


On Jul 8, 2016, at 11:10 PM, Al Viro wrote:

> On Fri, Jul 08, 2016 at 05:47:22PM -0400, Oleg Drokin wrote:
> 
>> I wonder if people just accept that "NFS is just weird" and code in 
>> workarounds,
>> where as with Lustre we promise (almost) full POSIX compliance, and also 
>> came much later
>> so people are just seeing that "this does not work" and complain more loudly?
> 
> To quote POSIX: "If more than one error occurs in processing a function call,
> any one of the possible errors may be returned, as the order of detection is
> undefined." (from System Interfaces: General Information: 2.3 Error Numbers)
> 
> And regarding mkdir(2) it has
> [EACCES]
>Search permission is denied on a component of the path prefix, or write
> permission is denied on the parent directory of the directory to be created.
> [EEXIST]
>The named file exists.
> among the error conditions.  In situations when both apply, the implementation
> is bloody well allowed to return either.  It might be nicer to return EEXIST
> in such cases, for consistency sake (if another thread does stat() on the
> pathname in question just as you are about to call mkdir(2), you will get
> EEXIST without ever reaching permission(9), let alone ->mkdir() method), but
> please do not bring POSIX compliance as an argument.  It's a QoI argument and
> nothing beyond that.

Ok, I see.
Thanks.

Bruce, do you want the patch resubmitted with a rewritten commit message,
or do you think it's best to just drop it them?

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM


On Jul 8, 2016, at 11:10 PM, Al Viro wrote:

> On Fri, Jul 08, 2016 at 05:47:22PM -0400, Oleg Drokin wrote:
> 
>> I wonder if people just accept that "NFS is just weird" and code in 
>> workarounds,
>> where as with Lustre we promise (almost) full POSIX compliance, and also 
>> came much later
>> so people are just seeing that "this does not work" and complain more loudly?
> 
> To quote POSIX: "If more than one error occurs in processing a function call,
> any one of the possible errors may be returned, as the order of detection is
> undefined." (from System Interfaces: General Information: 2.3 Error Numbers)
> 
> And regarding mkdir(2) it has
> [EACCES]
>Search permission is denied on a component of the path prefix, or write
> permission is denied on the parent directory of the directory to be created.
> [EEXIST]
>The named file exists.
> among the error conditions.  In situations when both apply, the implementation
> is bloody well allowed to return either.  It might be nicer to return EEXIST
> in such cases, for consistency sake (if another thread does stat() on the
> pathname in question just as you are about to call mkdir(2), you will get
> EEXIST without ever reaching permission(9), let alone ->mkdir() method), but
> please do not bring POSIX compliance as an argument.  It's a QoI argument and
> nothing beyond that.

Ok, I see.
Thanks.

Bruce, do you want the patch resubmitted with a rewritten commit message,
or do you think it's best to just drop it them?

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

2016-07-08 Thread William.wu


Dear Heiko & Balbi，


On 2016/7/8 21:29, Felipe Balbi wrote:

Hi,

Heiko Stuebner  writes:

Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:

Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interface is hardware property, and it's platform
dependent. Normall, the PHYIf can be configured
during coreconsultant. But for some specific usb
cores(e.g. rk3399 soc dwc3), the default PHYIf
configuration value is fault, so we need to
reconfigure it by software.

And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM
must be set to the corresponding value according to
the UTMI+ PHY interface.

Signed-off-by: William Wu 
---

[...]

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt index 020b0e9..8d7317d
100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -42,6 +42,10 @@ Optional properties:
   - snps,dis-u2-freeclk-exists-quirk: when set, clear the
u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
a free-running PHY clock.
+ - snps,phyif-utmi-quirk: when set core will set phyif UTMI+ interface.
+ - snps,phyif-utmi: the value to configure the core to support a UTMI+
PHY +   with an 8- or 16-bit interface. Value 0 select 8-bit
+   interface, value 1 select 16-bit interface.

maybe
snps,phyif-utmi-width = <8> or <16>;

devicetree is about describing the hardware, not the things that get written
to registers :-) . The conversion from the described width to the register
value can easily be done in the driver.

Thanks for your suggestion:-)
Yes， “snps,phyif-utmi-width = <8> or <16>” is much clearer and easier to 
understand.
And I have considered the same dts property for phyif-utmi, but I have 
no good idea about
the conversion from described width to the registers value for the time 
being.


About phyif utmi width configuration， we need to set two places in 
GUSB2PHYCFG register，
according to DWC3 USB3.0 controller databook version3.00a，6.3.46 
GUSB2PHYCFG


--
Bits   |  Name | Description
--
  13:10  |   USBTRDTIM   | Sets the turnaround time in PHY clocks.
|| 4'h5: When the MAC 
interface is 16-bit UTMI+
|| 4'h9: When the MAC 
interface is 8-bit UTMI+/ULPI.

--
  3|   PHYIF|If UTMI+ is selected, the 
application uses this bit to configure
||core to support a UTMI+ 
PHY with an 8- or 16-bit interface.

||1'b0: 8 bits
||1'b1: 16 bits
--

And I think maybe I can try to do this:
change it in dts:
snps,phyif-utmi-width = <8> or <16>;

Then convert to register value like this：
   device_property_read_u8(dev, "snps,phyif-utmi-width",
 _utmi_width);

   dwc->phyif_utmi = phyif_utmi_width >> 4;

 Ater the conversion， dwc->phyif_utmi value 0 means 8 bits, value 1 
means 16 bits,

 and it's easier for us to config GUSB2PHYCFG.

Is it OK?




Also I don't think you need two properties for this. If the snps,phyif-utmi
property is specified it indicates that you want to manually set the width
and if it is absent you want to use the IC default. All functions reading
property-values indicate if the property is missing.

Ah, it seems very good to me. One dts property "snps,phyif-utmi" can help to
reconfig phyif utmi width. And it seems that Felipe likes it very much 
too. :-D

But it looks like there is already a precendence in
snps,tx_de_emphasis(_quirk), so maybe Felipe has a different opinion here?




   - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
   - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 0b7bfd2..94036b1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -408,6 +408,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
  static int dwc3_phy_setup(struct dwc3 *dwc)
  {
u32 reg;
+   u32 usbtrdtim;
int ret;

reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
@@ -503,6 +504,15 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_u2_freeclk_exists_quirk)
reg &=

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

2016-07-08 Thread William.wu


Dear Heiko & Balbi，


On 2016/7/8 21:29, Felipe Balbi wrote:

Hi,

Heiko Stuebner  writes:

Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:

Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interface is hardware property, and it's platform
dependent. Normall, the PHYIf can be configured
during coreconsultant. But for some specific usb
cores(e.g. rk3399 soc dwc3), the default PHYIf
configuration value is fault, so we need to
reconfigure it by software.

And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM
must be set to the corresponding value according to
the UTMI+ PHY interface.

Signed-off-by: William Wu 
---

[...]

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt index 020b0e9..8d7317d
100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -42,6 +42,10 @@ Optional properties:
   - snps,dis-u2-freeclk-exists-quirk: when set, clear the
u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
a free-running PHY clock.
+ - snps,phyif-utmi-quirk: when set core will set phyif UTMI+ interface.
+ - snps,phyif-utmi: the value to configure the core to support a UTMI+
PHY +   with an 8- or 16-bit interface. Value 0 select 8-bit
+   interface, value 1 select 16-bit interface.

maybe
snps,phyif-utmi-width = <8> or <16>;

devicetree is about describing the hardware, not the things that get written
to registers :-) . The conversion from the described width to the register
value can easily be done in the driver.

Thanks for your suggestion:-)
Yes， “snps,phyif-utmi-width = <8> or <16>” is much clearer and easier to 
understand.
And I have considered the same dts property for phyif-utmi, but I have 
no good idea about
the conversion from described width to the registers value for the time 
being.


About phyif utmi width configuration， we need to set two places in 
GUSB2PHYCFG register，
according to DWC3 USB3.0 controller databook version3.00a，6.3.46 
GUSB2PHYCFG


--
Bits   |  Name | Description
--
  13:10  |   USBTRDTIM   | Sets the turnaround time in PHY clocks.
|| 4'h5: When the MAC 
interface is 16-bit UTMI+
|| 4'h9: When the MAC 
interface is 8-bit UTMI+/ULPI.

--
  3|   PHYIF|If UTMI+ is selected, the 
application uses this bit to configure
||core to support a UTMI+ 
PHY with an 8- or 16-bit interface.

||1'b0: 8 bits
||1'b1: 16 bits
--

And I think maybe I can try to do this:
change it in dts:
snps,phyif-utmi-width = <8> or <16>;

Then convert to register value like this：
   device_property_read_u8(dev, "snps,phyif-utmi-width",
 _utmi_width);

   dwc->phyif_utmi = phyif_utmi_width >> 4;

 Ater the conversion， dwc->phyif_utmi value 0 means 8 bits, value 1 
means 16 bits,

 and it's easier for us to config GUSB2PHYCFG.

Is it OK?




Also I don't think you need two properties for this. If the snps,phyif-utmi
property is specified it indicates that you want to manually set the width
and if it is absent you want to use the IC default. All functions reading
property-values indicate if the property is missing.

Ah, it seems very good to me. One dts property "snps,phyif-utmi" can help to
reconfig phyif utmi width. And it seems that Felipe likes it very much 
too. :-D

But it looks like there is already a precendence in
snps,tx_de_emphasis(_quirk), so maybe Felipe has a different opinion here?




   - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
   - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 0b7bfd2..94036b1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -408,6 +408,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
  static int dwc3_phy_setup(struct dwc3 *dwc)
  {
u32 reg;
+   u32 usbtrdtim;
int ret;

reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
@@ -503,6 +504,15 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_u2_freeclk_exists_quirk)
reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;

+   if

Re: Introspecting userns relationships to other namespaces?

"W. Trevor King"  writes:

> On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley wrote:
>> In theory, we could get nsfs to show this information as an option
>> (just add a show_options entry to the superblock ops), but the
>> problem is that although each namespace has a parent user_ns,
>> there's no way to get it without digging in the namespace specific
>> structure.  Probably we should restructure to move it into
>> ns_common, then we could display it (and enforce all namespaces
>> having owning user_ns) but it would be a reasonably large (but
>> mechanical) change.
>
> It sounds like everyone is either positive or or neutral on this
> groundwork, even if we haven't decided if/how to expose the
> information to userspace.  I'm happy to work up a patch while the rest
> of the discussion continues.  I'm also happy to let someone else work
> up the patch, if anyone else is chomping at the bit ;).

I am dubious on moving all of the user namespace members into ns_common.

I would happy to be proved wrong but I suspect in the cases where we
actually use that user namespace the code will become uglier.  Making
the ordinary uses uglier to make a rare corner case nicer is the wrong
trade off.

But feel free to try it is certainly worth doing if it doesn't make the
code that uses the user namespaces uglier.

Eric

Re: [PATCH 4/6] irqchip: add irqchip driver for nuc900

2016-07-08 Thread Wan Zongshun




On 2016年06月29日 23:27, Arnd Bergmann wrote:

On Saturday, June 25, 2016 6:37:20 PM CEST Wan Zongshun wrote:

+#define IRQ_WDTW90X900_IRQ(1)
+#define IRQ_WWDT   W90X900_IRQ(2)
+#define IRQ_LVDW90X900_IRQ(3)
+#define IRQ_EXT0   W90X900_IRQ(4)
+#define IRQ_EXT1   W90X900_IRQ(5)
+#define IRQ_EXT2   W90X900_IRQ(6)
+#define IRQ_EXT3   W90X900_IRQ(7)
+#define IRQ_EXT4   W90X900_IRQ(8)
+#define IRQ_EXT5   W90X900_IRQ(9)
+#define IRQ_EXT6   W90X900_IRQ(10)


I'd suggest dropping the list, the contents are now in the dts.


Arnd, I will drop this file later, since old w90x900 plat still need it.
but I will remove the Macros related to nuc970 and avoid nuc970 
interrupt using those Macro.


But I still need hack this irqs.h like below, since here NR_IRQS defined 
and it is need for nuc970 irqchip driver.


#if !defined(CONFIG_SOC_NUC900)
#define NR_IRQS (IRQ_ADC+1)
#else
#define NR_IRQS 62
#endif




diff --git a/arch/arm/mach-w90x900/include/mach/nuc970-regs-aic.h 
b/arch/arm/mach-w90x900/include/mach/nuc970-regs-aic.h
new file mode 100644
index 000..7a77016
--- /dev/null
+++ b/arch/arm/mach-w90x900/include/mach/nuc970-regs-aic.h
@@ -0,0 +1,53 @@
+#ifndef __ASM_ARCH_REGS_AIC_H
+#define __ASM_ARCH_REGS_AIC_H
+
+/*NUC970 AIC regs*/
+
+#defineREG_AIC_SCR10x00
+#defineREG_AIC_SCR20x04
+#defineREG_AIC_SCR30x08
+#defineREG_AIC_SCR40x0C
+#defineREG_AIC_SCR50x10


And like the clk driver, these should all be in the irqchip driver instead
of a separate header.


+
+static void __iomem *aic_base;
+static struct irq_domain *aic_domain;
+#define MAKE_HWIRQ(irqnum) (irqnum)


The macro appears to be unused.


+static void nuc970_irq_mask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   __raw_writel(1 << (d->irq), aic_base + REG_AIC_MDCR);
+   else
+   __raw_writel(1 << (d->irq - 32), aic_base + REG_AIC_MDCRH);
+}


writel()

Arnd


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Introspecting userns relationships to other namespaces?

"W. Trevor King"  writes:

> On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley wrote:
>> In theory, we could get nsfs to show this information as an option
>> (just add a show_options entry to the superblock ops), but the
>> problem is that although each namespace has a parent user_ns,
>> there's no way to get it without digging in the namespace specific
>> structure.  Probably we should restructure to move it into
>> ns_common, then we could display it (and enforce all namespaces
>> having owning user_ns) but it would be a reasonably large (but
>> mechanical) change.
>
> It sounds like everyone is either positive or or neutral on this
> groundwork, even if we haven't decided if/how to expose the
> information to userspace.  I'm happy to work up a patch while the rest
> of the discussion continues.  I'm also happy to let someone else work
> up the patch, if anyone else is chomping at the bit ;).

I am dubious on moving all of the user namespace members into ns_common.

I would happy to be proved wrong but I suspect in the cases where we
actually use that user namespace the code will become uglier.  Making
the ordinary uses uglier to make a rare corner case nicer is the wrong
trade off.

But feel free to try it is certainly worth doing if it doesn't make the
code that uses the user namespaces uglier.

Eric

Re: [PATCH 4/6] irqchip: add irqchip driver for nuc900

2016-07-08 Thread Wan Zongshun




On 2016年06月29日 23:27, Arnd Bergmann wrote:

On Saturday, June 25, 2016 6:37:20 PM CEST Wan Zongshun wrote:

+#define IRQ_WDTW90X900_IRQ(1)
+#define IRQ_WWDT   W90X900_IRQ(2)
+#define IRQ_LVDW90X900_IRQ(3)
+#define IRQ_EXT0   W90X900_IRQ(4)
+#define IRQ_EXT1   W90X900_IRQ(5)
+#define IRQ_EXT2   W90X900_IRQ(6)
+#define IRQ_EXT3   W90X900_IRQ(7)
+#define IRQ_EXT4   W90X900_IRQ(8)
+#define IRQ_EXT5   W90X900_IRQ(9)
+#define IRQ_EXT6   W90X900_IRQ(10)


I'd suggest dropping the list, the contents are now in the dts.


Arnd, I will drop this file later, since old w90x900 plat still need it.
but I will remove the Macros related to nuc970 and avoid nuc970 
interrupt using those Macro.


But I still need hack this irqs.h like below, since here NR_IRQS defined 
and it is need for nuc970 irqchip driver.


#if !defined(CONFIG_SOC_NUC900)
#define NR_IRQS (IRQ_ADC+1)
#else
#define NR_IRQS 62
#endif




diff --git a/arch/arm/mach-w90x900/include/mach/nuc970-regs-aic.h 
b/arch/arm/mach-w90x900/include/mach/nuc970-regs-aic.h
new file mode 100644
index 000..7a77016
--- /dev/null
+++ b/arch/arm/mach-w90x900/include/mach/nuc970-regs-aic.h
@@ -0,0 +1,53 @@
+#ifndef __ASM_ARCH_REGS_AIC_H
+#define __ASM_ARCH_REGS_AIC_H
+
+/*NUC970 AIC regs*/
+
+#defineREG_AIC_SCR10x00
+#defineREG_AIC_SCR20x04
+#defineREG_AIC_SCR30x08
+#defineREG_AIC_SCR40x0C
+#defineREG_AIC_SCR50x10


And like the clk driver, these should all be in the irqchip driver instead
of a separate header.


+
+static void __iomem *aic_base;
+static struct irq_domain *aic_domain;
+#define MAKE_HWIRQ(irqnum) (irqnum)


The macro appears to be unused.


+static void nuc970_irq_mask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   __raw_writel(1 << (d->irq), aic_base + REG_AIC_MDCR);
+   else
+   __raw_writel(1 << (d->irq - 32), aic_base + REG_AIC_MDCRH);
+}


writel()

Arnd


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [CRIU] Introspecting userns relationships to other namespaces?

James Bottomley  writes:

> On Fri, 2016-07-08 at 18:52 -0500, Eric W. Biederman wrote:
>> James Bottomley  writes:
>> 
>> > On July 8, 2016 1:38:19 PM PDT, Andrew Vagin 
>> > wrote:
>> 
>> > > What do you think about the idea to mount nsfs and be able to 
>> > > look up any alive namespace by inum:
>> > 
>> > I think I like it.  It will give us a way to enter any extant
>> > namespace.  It will work for Eric's fs namespaces as well.  Perhaps 
>> > a /process/ns/ Directory?
>
> As you understood, I meant /proc/ns/ (damn mobile phone
> completions).
>
>> *Shivers*
>> 
>> That makes it very easy to bypass any existing controls that exist 
>> for getting at namespaces.  It is true that everything of that kind 
>> is directory based but still.
>> 
>> Plus I think it would serve as information leak to information 
>> outside of the container.
>> 
>> An operation to get a user namespace file descriptor from some kernel
>> object sounds reasonably sane.
>> 
>> A great big list of things sounds about as scary as it can get.  This 
>> is not the time to be making it easier to escape from containers.
>
> To be honest, I think this argument is rubbish.  If we're afraid of
> giving out a list of all the namespaces, it means we're afraid there's
> some security bug and we're trying to obscure it by making the list
> hard to get.  All we've done is allayed fears about the bug but the
> hackers still know the portals to get through.
>
> If such a bug exists, it will be possible to exploit it by simply
> reconstructing the information from the individual process directories,
> so obscurity doesn't protect us and all it does is give us a false
> sense of security.   If such a bug doesn't exist, then all the security
> mechanisms currently in place (like no re-entry to prior namespace)
> should protect us and we can give out the list.
>
> Let's deal with the world as we'd like it to be (no obscure namespace
> bugs) and accept the consequences and the responsibility for fixing
> them if we turn out to be slightly incorrect.  We'll end up in a far
> better place than security by obscurity would land us.

No.  That is not the fear.  The permission checks on /proc/self/ns/xxx
are different than if the namespace is bind mounted somewhere.

That was done deliberately and with a reasonable amount of forethought.
You are asking to throw those permission checks out.   The answer is no.

Furthermore there is a much clearer reason not to go with a list of all
namespaces. A list of all namespaces breaks CRIU.  As you have described
it the list will change depending upon which machine you restore a
checkpoint on.  I honestly don't know what kind of havoc that will cause
but it is certainly something we won't be able to checkpoint no matter
how hard we try.

A global list of namespaces especially of the kind that you can open
and get a handle to the namespace is just not appropriate.

I know inode numbers comes darn close to names but they aren't really
names and if it comes to it we can figure out how to preserve an
applications view of it all across a checkpoint/restart.  So far it
hasn't proven necessary to preserve any inode numbers across
checkpoint/restart but again it is theoretically possible if it becomes
necessary.

Throwing away checkpoint/restart support for the sake of
checkpoint/restart is a no-go.

Containers fundamentally imply you don't have global visibility,
and that is a good thing.

Eric

Re: [CRIU] Introspecting userns relationships to other namespaces?

James Bottomley  writes:

> On Fri, 2016-07-08 at 18:52 -0500, Eric W. Biederman wrote:
>> James Bottomley  writes:
>> 
>> > On July 8, 2016 1:38:19 PM PDT, Andrew Vagin 
>> > wrote:
>> 
>> > > What do you think about the idea to mount nsfs and be able to 
>> > > look up any alive namespace by inum:
>> > 
>> > I think I like it.  It will give us a way to enter any extant
>> > namespace.  It will work for Eric's fs namespaces as well.  Perhaps 
>> > a /process/ns/ Directory?
>
> As you understood, I meant /proc/ns/ (damn mobile phone
> completions).
>
>> *Shivers*
>> 
>> That makes it very easy to bypass any existing controls that exist 
>> for getting at namespaces.  It is true that everything of that kind 
>> is directory based but still.
>> 
>> Plus I think it would serve as information leak to information 
>> outside of the container.
>> 
>> An operation to get a user namespace file descriptor from some kernel
>> object sounds reasonably sane.
>> 
>> A great big list of things sounds about as scary as it can get.  This 
>> is not the time to be making it easier to escape from containers.
>
> To be honest, I think this argument is rubbish.  If we're afraid of
> giving out a list of all the namespaces, it means we're afraid there's
> some security bug and we're trying to obscure it by making the list
> hard to get.  All we've done is allayed fears about the bug but the
> hackers still know the portals to get through.
>
> If such a bug exists, it will be possible to exploit it by simply
> reconstructing the information from the individual process directories,
> so obscurity doesn't protect us and all it does is give us a false
> sense of security.   If such a bug doesn't exist, then all the security
> mechanisms currently in place (like no re-entry to prior namespace)
> should protect us and we can give out the list.
>
> Let's deal with the world as we'd like it to be (no obscure namespace
> bugs) and accept the consequences and the responsibility for fixing
> them if we turn out to be slightly incorrect.  We'll end up in a far
> better place than security by obscurity would land us.

No.  That is not the fear.  The permission checks on /proc/self/ns/xxx
are different than if the namespace is bind mounted somewhere.

That was done deliberately and with a reasonable amount of forethought.
You are asking to throw those permission checks out.   The answer is no.

Furthermore there is a much clearer reason not to go with a list of all
namespaces. A list of all namespaces breaks CRIU.  As you have described
it the list will change depending upon which machine you restore a
checkpoint on.  I honestly don't know what kind of havoc that will cause
but it is certainly something we won't be able to checkpoint no matter
how hard we try.

A global list of namespaces especially of the kind that you can open
and get a handle to the namespace is just not appropriate.

I know inode numbers comes darn close to names but they aren't really
names and if it comes to it we can figure out how to preserve an
applications view of it all across a checkpoint/restart.  So far it
hasn't proven necessary to preserve any inode numbers across
checkpoint/restart but again it is theoretically possible if it becomes
necessary.

Throwing away checkpoint/restart support for the sake of
checkpoint/restart is a no-go.

Containers fundamentally imply you don't have global visibility,
and that is a good thing.

Eric

Re: Introspecting userns relationships to other namespaces?

2016-07-08 Thread W. Trevor King

On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley wrote:
> In theory, we could get nsfs to show this information as an option
> (just add a show_options entry to the superblock ops), but the
> problem is that although each namespace has a parent user_ns,
> there's no way to get it without digging in the namespace specific
> structure.  Probably we should restructure to move it into
> ns_common, then we could display it (and enforce all namespaces
> having owning user_ns) but it would be a reasonably large (but
> mechanical) change.

It sounds like everyone is either positive or or neutral on this
groundwork, even if we haven't decided if/how to expose the
information to userspace.  I'm happy to work up a patch while the rest
of the discussion continues.  I'm also happy to let someone else work
up the patch, if anyone else is chomping at the bit ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: Introspecting userns relationships to other namespaces?

2016-07-08 Thread W. Trevor King

On Thu, Jul 07, 2016 at 08:01:52AM -0700, James Bottomley wrote:
> In theory, we could get nsfs to show this information as an option
> (just add a show_options entry to the superblock ops), but the
> problem is that although each namespace has a parent user_ns,
> there's no way to get it without digging in the namespace specific
> structure.  Probably we should restructure to move it into
> ns_common, then we could display it (and enforce all namespaces
> having owning user_ns) but it would be a reasonably large (but
> mechanical) change.

It sounds like everyone is either positive or or neutral on this
groundwork, even if we haven't decided if/how to expose the
information to userspace.  I'm happy to work up a patch while the rest
of the discussion continues.  I'm also happy to let someone else work
up the patch, if anyone else is chomping at the bit ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM

On Fri, Jul 08, 2016 at 10:58:38PM -0400, Oleg Drokin wrote:

> > When more than one condition applies, we have every right to return any of
> > them.  POSIX does *NOT* specify the order of checks.  Never had.
> 
> Out of curiosity, why does filename_create() delay EROFS then?

QoI and historical behaviour...

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM

On Fri, Jul 08, 2016 at 10:58:38PM -0400, Oleg Drokin wrote:

> > When more than one condition applies, we have every right to return any of
> > them.  POSIX does *NOT* specify the order of checks.  Never had.
> 
> Out of curiosity, why does filename_create() delay EROFS then?

QoI and historical behaviour...

Re: [PATCH RESEND net-next] netvsc: Use the new in-place consumption APIs in the rx path

From: k...@exchange.microsoft.com
Date: Tue,  5 Jul 2016 16:52:46 -0700

> From: K. Y. Srinivasan 
> 
> Use the new APIs for eliminating a copy on the receive path. These new APIs 
> also
> help in minimizing the number of memory barriers we end up issuing (in the
> ringbuffer code) since we can better control when we want to expose the ring
> state to the host.
> 
> The patch is being resent to address earlier email issues.
> 
> Signed-off-by: K. Y. Srinivasan 

Applied.

Re: [PATCH RESEND net-next] netvsc: Use the new in-place consumption APIs in the rx path

From: k...@exchange.microsoft.com
Date: Tue,  5 Jul 2016 16:52:46 -0700

> From: K. Y. Srinivasan 
> 
> Use the new APIs for eliminating a copy on the receive path. These new APIs 
> also
> help in minimizing the number of memory barriers we end up issuing (in the
> ringbuffer code) since we can better control when we want to expose the ring
> state to the host.
> 
> The patch is being resent to address earlier email issues.
> 
> Signed-off-by: K. Y. Srinivasan 

Applied.

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM

On Fri, Jul 08, 2016 at 05:47:22PM -0400, Oleg Drokin wrote:

> I wonder if people just accept that "NFS is just weird" and code in 
> workarounds,
> where as with Lustre we promise (almost) full POSIX compliance, and also came 
> much later
> so people are just seeing that "this does not work" and complain more loudly?

To quote POSIX: "If more than one error occurs in processing a function call,
any one of the possible errors may be returned, as the order of detection is
undefined." (from System Interfaces: General Information: 2.3 Error Numbers)

And regarding mkdir(2) it has
[EACCES]
Search permission is denied on a component of the path prefix, or write
permission is denied on the parent directory of the directory to be created.
[EEXIST]
The named file exists.
among the error conditions.  In situations when both apply, the implementation
is bloody well allowed to return either.  It might be nicer to return EEXIST
in such cases, for consistency sake (if another thread does stat() on the
pathname in question just as you are about to call mkdir(2), you will get
EEXIST without ever reaching permission(9), let alone ->mkdir() method), but
please do not bring POSIX compliance as an argument.  It's a QoI argument and
nothing beyond that.

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM

On Fri, Jul 08, 2016 at 05:47:22PM -0400, Oleg Drokin wrote:

> I wonder if people just accept that "NFS is just weird" and code in 
> workarounds,
> where as with Lustre we promise (almost) full POSIX compliance, and also came 
> much later
> so people are just seeing that "this does not work" and complain more loudly?

To quote POSIX: "If more than one error occurs in processing a function call,
any one of the possible errors may be returned, as the order of detection is
undefined." (from System Interfaces: General Information: 2.3 Error Numbers)

And regarding mkdir(2) it has
[EACCES]
Search permission is denied on a component of the path prefix, or write
permission is denied on the parent directory of the directory to be created.
[EEXIST]
The named file exists.
among the error conditions.  In situations when both apply, the implementation
is bloody well allowed to return either.  It might be nicer to return EEXIST
in such cases, for consistency sake (if another thread does stat() on the
pathname in question just as you are about to call mkdir(2), you will get
EEXIST without ever reaching permission(9), let alone ->mkdir() method), but
please do not bring POSIX compliance as an argument.  It's a QoI argument and
nothing beyond that.

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer


On 2016/7/7 21:58, Rafael J. Wysocki wrote:

On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:

[+Sudeep]

On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:

[...]


So is this a documentation issue in which case Fu Wei can add that to
the file to explain its limited to ARM64. Or we could even rename the
file acpi_arm64_gtdt.c

It seems a pity as the comment on this series were minors to block
things on a filename/location.


Let me repeat what I said above:

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward.

This is not about documentation, it is about responsibility.

Honestly, I don't think I'm the right maintainer to apply the patch
introducing this code and then handle bug reports regarding it and so
on.  That has to be done by somebody else.


I'm working on ACPI for years and upstreamed the ARM64 ACPI core
support (with lots of people's help), I'm willing to maintain the ARM64
ACPI code under drivers/acpi/ if no objections.


OK


I would ask you please to add Sudeep and myself for the ARM64 specific
ACPI code maintainership too.


OK


Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?


I'm fine with it as it helps for maintain.

Thanks
Hanjun

Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer


On 2016/7/7 21:58, Rafael J. Wysocki wrote:

On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:

[+Sudeep]

On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:

[...]


So is this a documentation issue in which case Fu Wei can add that to
the file to explain its limited to ARM64. Or we could even rename the
file acpi_arm64_gtdt.c

It seems a pity as the comment on this series were minors to block
things on a filename/location.


Let me repeat what I said above:

I'm mostly concerned about how (and by whom) that code is going to be
maintained going forward.

This is not about documentation, it is about responsibility.

Honestly, I don't think I'm the right maintainer to apply the patch
introducing this code and then handle bug reports regarding it and so
on.  That has to be done by somebody else.


I'm working on ACPI for years and upstreamed the ARM64 ACPI core
support (with lots of people's help), I'm willing to maintain the ARM64
ACPI code under drivers/acpi/ if no objections.


OK


I would ask you please to add Sudeep and myself for the ARM64 specific
ACPI code maintainership too.


OK


Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?


I'm fine with it as it helps for maintain.

Thanks
Hanjun

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM


On Jul 8, 2016, at 10:52 PM, Al Viro wrote:

> On Fri, Jul 08, 2016 at 11:59:50AM -0400, Oleg Drokin wrote:
> 
>> "If path names a symbolic link, mkdir() shall fail and set errno to 
>> [EEXIST]."
>> 
>> This sounds pretty straightforward to me, no?
>> Since it does not matter that we do not have write permissions here, because
>> the name already exists.
> 
> When more than one condition applies, we have every right to return any of
> them.  POSIX does *NOT* specify the order of checks.  Never had.

Out of curiosity, why does filename_create() delay EROFS then?

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM


On Jul 8, 2016, at 10:52 PM, Al Viro wrote:

> On Fri, Jul 08, 2016 at 11:59:50AM -0400, Oleg Drokin wrote:
> 
>> "If path names a symbolic link, mkdir() shall fail and set errno to 
>> [EEXIST]."
>> 
>> This sounds pretty straightforward to me, no?
>> Since it does not matter that we do not have write permissions here, because
>> the name already exists.
> 
> When more than one condition applies, we have every right to return any of
> them.  POSIX does *NOT* specify the order of checks.  Never had.

Out of curiosity, why does filename_create() delay EROFS then?

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM

On Fri, Jul 08, 2016 at 11:59:50AM -0400, Oleg Drokin wrote:

> "If path names a symbolic link, mkdir() shall fail and set errno to [EEXIST]."
> 
> This sounds pretty straightforward to me, no?
> Since it does not matter that we do not have write permissions here, because
> the name already exists.

When more than one condition applies, we have every right to return any of
them.  POSIX does *NOT* specify the order of checks.  Never had.

Re: [PATCH] nfsd: Make creates return EEXIST correctly instead of EPERM

On Fri, Jul 08, 2016 at 11:59:50AM -0400, Oleg Drokin wrote:

> "If path names a symbolic link, mkdir() shall fail and set errno to [EEXIST]."
> 
> This sounds pretty straightforward to me, no?
> Since it does not matter that we do not have write permissions here, because
> the name already exists.

When more than one condition applies, we have every right to return any of
them.  POSIX does *NOT* specify the order of checks.  Never had.

Re: [PATCH 0/9] mm: Hardened usercopy

2016-07-08 Thread Rik van Riel

On Fri, 2016-07-08 at 19:22 -0700, Laura Abbott wrote:
> 
> Even with the SLUB fixup I'm still seeing this blow up on my arm64
> system. This is a
> Fedora rawhide kernel + the patches
> 
> [0.666700] usercopy: kernel memory exposure attempt detected from
> fc0008b4dd58 () (8 bytes)
> [0.666720] CPU: 2 PID: 79 Comm: modprobe Tainted:
> GW   4.7.0-0.rc6.git1.1.hardenedusercopy.fc25.aarch64 #1
> [0.666733] Hardware name: AppliedMicro Mustang/Mustang, BIOS
> 1.1.0 Nov 24 2015
> [0.666744] Call trace:
> [0.666756] [] dump_backtrace+0x0/0x1e8
> [0.666765] [] show_stack+0x24/0x30
> [0.666775] [] dump_stack+0xa4/0xe0
> [0.666785] [] __check_object_size+0x6c/0x230
> [0.666795] [] create_elf_tables+0x74/0x420
> [0.666805] [] load_elf_binary+0x828/0xb70
> [0.666814] [] search_binary_handler+0xb4/0x240
> [0.666823] [] do_execveat_common+0x63c/0x950
> [0.666832] [] do_execve+0x3c/0x50
> [0.666841] []
> call_usermodehelper_exec_async+0xe8/0x148
> [0.666850] [] ret_from_fork+0x10/0x50
> 
> This happens on every call to execve. This seems to be the first
> copy_to_user in
> create_elf_tables. I didn't get a chance to debug and I'm going out
> of town
> all of next week so all I have is the report unfortunately. config
> attached.

That's odd, this should be copying a piece of kernel data (not text)
to userspace.

from fs/binfmt_elf.c

        const char *k_platform = ELF_PLATFORM;

...
                size_t len = strlen(k_platform) + 1;

                u_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
if (__copy_to_user(u_platform, k_platform, len))
return -EFAULT;

from arch/arm/include/asm/elf.h:

#define ELF_PLATFORM_SIZE 8
#define ELF_PLATFORM(elf_platform)

extern char elf_platform[];

from arch/arm/kernel/setup.c:

char elf_platform[ELF_PLATFORM_SIZE];
EXPORT_SYMBOL(elf_platform);

...

snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c",
 list->elf_name, ENDIANNESS);

How does that end up in the .text section of the
image, instead of in one of the various data sections?

What kind of linker oddity is going on with ARM?

--  
All Rights Reversed.

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

Re: [PATCH 0/9] mm: Hardened usercopy

2016-07-08 Thread Rik van Riel

On Fri, 2016-07-08 at 19:22 -0700, Laura Abbott wrote:
> 
> Even with the SLUB fixup I'm still seeing this blow up on my arm64
> system. This is a
> Fedora rawhide kernel + the patches
> 
> [0.666700] usercopy: kernel memory exposure attempt detected from
> fc0008b4dd58 () (8 bytes)
> [0.666720] CPU: 2 PID: 79 Comm: modprobe Tainted:
> GW   4.7.0-0.rc6.git1.1.hardenedusercopy.fc25.aarch64 #1
> [0.666733] Hardware name: AppliedMicro Mustang/Mustang, BIOS
> 1.1.0 Nov 24 2015
> [0.666744] Call trace:
> [0.666756] [] dump_backtrace+0x0/0x1e8
> [0.666765] [] show_stack+0x24/0x30
> [0.666775] [] dump_stack+0xa4/0xe0
> [0.666785] [] __check_object_size+0x6c/0x230
> [0.666795] [] create_elf_tables+0x74/0x420
> [0.666805] [] load_elf_binary+0x828/0xb70
> [0.666814] [] search_binary_handler+0xb4/0x240
> [0.666823] [] do_execveat_common+0x63c/0x950
> [0.666832] [] do_execve+0x3c/0x50
> [0.666841] []
> call_usermodehelper_exec_async+0xe8/0x148
> [0.666850] [] ret_from_fork+0x10/0x50
> 
> This happens on every call to execve. This seems to be the first
> copy_to_user in
> create_elf_tables. I didn't get a chance to debug and I'm going out
> of town
> all of next week so all I have is the report unfortunately. config
> attached.

That's odd, this should be copying a piece of kernel data (not text)
to userspace.

from fs/binfmt_elf.c

        const char *k_platform = ELF_PLATFORM;

...
                size_t len = strlen(k_platform) + 1;

                u_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
if (__copy_to_user(u_platform, k_platform, len))
return -EFAULT;

from arch/arm/include/asm/elf.h:

#define ELF_PLATFORM_SIZE 8
#define ELF_PLATFORM(elf_platform)

extern char elf_platform[];

from arch/arm/kernel/setup.c:

char elf_platform[ELF_PLATFORM_SIZE];
EXPORT_SYMBOL(elf_platform);

...

snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c",
 list->elf_name, ENDIANNESS);

How does that end up in the .text section of the
image, instead of in one of the various data sections?

What kind of linker oddity is going on with ARM?

--  
All Rights Reversed.

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

Re: [tip:x86/debug] printk: Make the printk*once() variants return a value

2016-07-08 Thread Joe Perches

On Fri, 2016-07-08 at 05:08 -0700, tip-bot for Borislav Petkov wrote:
> printk: Make the printk*once() variants return a value
[]
> diff --git a/include/linux/printk.h b/include/linux/printk.h
[]
> @@ -108,11 +108,14 @@ struct va_format {
>   * Dummy printk for disabled debugging statements to use whilst maintaining
>   * gcc's format checking.
>   */
> -#define no_printk(fmt, ...)  \
> -do { \
> - if (0)  \
> - printk(fmt, ##__VA_ARGS__); \
> -} while (0)
> +#define no_printk(fmt, ...)  \
> +({   \
> + do {\
> + if (0)  \
> + printk(fmt, ##__VA_ARGS__); \
> + } while (0);\
> + 0;  \
> +})

This change isn't described in the commit message and there
doesn't seem to be a need to change this.

And as statement expressions these no longer need
"do {  } while (0)" this could have been be simplified to

#define no_printk(fmt, ...)
({
if (0)
printk(fmt, ##__VA_ARGS__);
})

Re: [tip:x86/debug] printk: Make the printk*once() variants return a value

2016-07-08 Thread Joe Perches

On Fri, 2016-07-08 at 05:08 -0700, tip-bot for Borislav Petkov wrote:
> printk: Make the printk*once() variants return a value
[]
> diff --git a/include/linux/printk.h b/include/linux/printk.h
[]
> @@ -108,11 +108,14 @@ struct va_format {
>   * Dummy printk for disabled debugging statements to use whilst maintaining
>   * gcc's format checking.
>   */
> -#define no_printk(fmt, ...)  \
> -do { \
> - if (0)  \
> - printk(fmt, ##__VA_ARGS__); \
> -} while (0)
> +#define no_printk(fmt, ...)  \
> +({   \
> + do {\
> + if (0)  \
> + printk(fmt, ##__VA_ARGS__); \
> + } while (0);\
> + 0;  \
> +})

This change isn't described in the commit message and there
doesn't seem to be a need to change this.

And as statement expressions these no longer need
"do {  } while (0)" this could have been be simplified to

#define no_printk(fmt, ...)
({
if (0)
printk(fmt, ##__VA_ARGS__);
})

Re: [PATCH] i2c: imx: add retries for i2c-0 on Ventana boards

2016-07-08 Thread Wolfram Sang


> > The issue I have is that the i2c device emulates several other devices
> > with existing drivers (pca953x, ds1672, at24) and those drivers don't
> > have any retry mechanism in place for a retry.
> > 
> > Maybe if I converted those drivers to use regmap I could implement a
> > regmap with retries in the mfd driver for my device?
> 
> Wolfram: what do you think?

What NAK means is device specific IMO, so to do it generally at regmap
level is convenient but wrong. at24 already has retry support because it
may be accessed while in an erase cycle. I don't know the other devices.
You need to discuss with the driver authors/maintainers if a NAK can
generally mean "let's retry" or if you need a seperate i2c_device_id for
your variant which then handles the NAK differently.



signature.asc
Description: PGP signature

Re: [PATCH v1] Specific requirement of type casting for 64-bit architectures.

2016-07-08 Thread Guenter Roeck


On 07/08/2016 02:44 PM, Arvind Yadav wrote:

I would really suggest to read section 14 of Documentation/SubmittingPatches
and to follow the guidance it provides.

For the subject line: The subsystem/driver is still not listed,
and I am quite sure that this is not v1 of this patch.
It also does not describe the patch, much less concisely.


-Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
assigned in ucc_fast_tx_virtual_fifo_base_offset and
ucc_fast_rx_virtual_fifo_base_offset. It will work on 32-bit architectures
But data can be loss on 64-bit architectures if 'qe_muram_alloc' will
return greater then MAX value of 'unsigned int'.


Try to rephrase this to make it better readable.


-Passing value in IS_ERR_VALUE() is wrong, as they pass an 'unsigned int'
into a function, It will through this compilation warning.



What is wrong it that the return value from the allocator function is truncated
to 32 bit, and that the resulting value is then used as argument to 
IS_ERR_VALUE().


"
  include/linux/err.h:21:49: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
  #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
  ^
  include/linux/compiler.h:170:42: note: in definition of macro ‘unlikely’
  # define unlikely(x) __builtin_expect(!!(x), 0)
"

-Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'unsigned int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.


While this may be true, the description of this patch should be about
this patch, not about the rest of the kernel.


However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.



What does that have to do with this patch ?

Again, the problem here is that a unsigned long is assigned to an u32, and that
the u32 is then used as parameter to IS_ERR_VALUE. This is wrong and needs to
be fixed. Describe what is wrong and needs to be fixed, not what can be wrong
elsewhere in the kernel.


Signed-off-by: Arvind Yadav 
---


Here is where one would normally expect a change log.


  drivers/soc/fsl/qe/ucc_fast.c | 21 ++---
  1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/fsl/qe/ucc_fast.c b/drivers/soc/fsl/qe/ucc_fast.c
index a768931..208b198 100644
--- a/drivers/soc/fsl/qe/ucc_fast.c
+++ b/drivers/soc/fsl/qe/ucc_fast.c
@@ -141,6 +141,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct 
ucc_fast_private ** ucc
struct ucc_fast __iomem *uf_regs;
u32 gumr;
int ret;
+   unsigned long ret_muram;



Kind of an unfortunate variable name. A simple "offset" might be a better 
choice.


if (!uf_info)
return -EINVAL;
@@ -265,28 +266,34 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct 
ucc_fast_private ** ucc
gumr |= uf_info->mode;
out_be32(_regs->gumr, gumr);

-   /* Allocate memory for Tx Virtual Fifo */
-   uccf->ucc_fast_tx_virtual_fifo_base_offset =
-   qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
-   if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
+   ret_muram =
+   qe_muram_alloc(uf_info->utfs,
+   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);


While minor, this introduces a checkpatch CHECK message.


+

This added empty line is an unnecessary whitespace change and does not add any 
value.


+   if (IS_ERR_VALUE(ret_muram)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
+   } else {
+   /* Allocate memory for Tx Virtual Fifo */


Why did you move the comment here ? The code below does not allocate anything.


+   uccf->ucc_fast_tx_virtual_fifo_base_offset = (u32)ret_muram;
}


checkpatch will rightfully tell you that else after return is generally not 
useful.
Also, the typecast is not necessary.



-   /* Allocate memory for Rx Virtual Fifo */
-   uccf->ucc_fast_rx_virtual_fifo_base_offset =
+   ret_muram =
qe_muram_alloc(uf_info->urfs +
   UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
-   if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
+   if (IS_ERR_VALUE(ret_muram)) {
printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
__func__);

Re: [PATCH] i2c: imx: add retries for i2c-0 on Ventana boards

2016-07-08 Thread Wolfram Sang


> > The issue I have is that the i2c device emulates several other devices
> > with existing drivers (pca953x, ds1672, at24) and those drivers don't
> > have any retry mechanism in place for a retry.
> > 
> > Maybe if I converted those drivers to use regmap I could implement a
> > regmap with retries in the mfd driver for my device?
> 
> Wolfram: what do you think?

What NAK means is device specific IMO, so to do it generally at regmap
level is convenient but wrong. at24 already has retry support because it
may be accessed while in an erase cycle. I don't know the other devices.
You need to discuss with the driver authors/maintainers if a NAK can
generally mean "let's retry" or if you need a seperate i2c_device_id for
your variant which then handles the NAK differently.



signature.asc
Description: PGP signature

Re: [PATCH v1] Specific requirement of type casting for 64-bit architectures.

2016-07-08 Thread Guenter Roeck


On 07/08/2016 02:44 PM, Arvind Yadav wrote:

I would really suggest to read section 14 of Documentation/SubmittingPatches
and to follow the guidance it provides.

For the subject line: The subsystem/driver is still not listed,
and I am quite sure that this is not v1 of this patch.
It also does not describe the patch, much less concisely.


-Return type of 'qe_muram_alloc' is 'unsigned long', That Was trying to
assigned in ucc_fast_tx_virtual_fifo_base_offset and
ucc_fast_rx_virtual_fifo_base_offset. It will work on 32-bit architectures
But data can be loss on 64-bit architectures if 'qe_muram_alloc' will
return greater then MAX value of 'unsigned int'.


Try to rephrase this to make it better readable.


-Passing value in IS_ERR_VALUE() is wrong, as they pass an 'unsigned int'
into a function, It will through this compilation warning.



What is wrong it that the return value from the allocator function is truncated
to 32 bit, and that the resulting value is then used as argument to 
IS_ERR_VALUE().


"
  include/linux/err.h:21:49: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
  #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned 
long)-MAX_ERRNO)
  ^
  include/linux/compiler.h:170:42: note: in definition of macro ‘unlikely’
  # define unlikely(x) __builtin_expect(!!(x), 0)
"

-Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'unsigned int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.


While this may be true, the description of this patch should be about
this patch, not about the rest of the kernel.


However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.



What does that have to do with this patch ?

Again, the problem here is that a unsigned long is assigned to an u32, and that
the u32 is then used as parameter to IS_ERR_VALUE. This is wrong and needs to
be fixed. Describe what is wrong and needs to be fixed, not what can be wrong
elsewhere in the kernel.


Signed-off-by: Arvind Yadav 
---


Here is where one would normally expect a change log.


  drivers/soc/fsl/qe/ucc_fast.c | 21 ++---
  1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/fsl/qe/ucc_fast.c b/drivers/soc/fsl/qe/ucc_fast.c
index a768931..208b198 100644
--- a/drivers/soc/fsl/qe/ucc_fast.c
+++ b/drivers/soc/fsl/qe/ucc_fast.c
@@ -141,6 +141,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct 
ucc_fast_private ** ucc
struct ucc_fast __iomem *uf_regs;
u32 gumr;
int ret;
+   unsigned long ret_muram;



Kind of an unfortunate variable name. A simple "offset" might be a better 
choice.


if (!uf_info)
return -EINVAL;
@@ -265,28 +266,34 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct 
ucc_fast_private ** ucc
gumr |= uf_info->mode;
out_be32(_regs->gumr, gumr);

-   /* Allocate memory for Tx Virtual Fifo */
-   uccf->ucc_fast_tx_virtual_fifo_base_offset =
-   qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
-   if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
+   ret_muram =
+   qe_muram_alloc(uf_info->utfs,
+   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);


While minor, this introduces a checkpatch CHECK message.


+

This added empty line is an unnecessary whitespace change and does not add any 
value.


+   if (IS_ERR_VALUE(ret_muram)) {
printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
__func__);
uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
ucc_fast_free(uccf);
return -ENOMEM;
+   } else {
+   /* Allocate memory for Tx Virtual Fifo */


Why did you move the comment here ? The code below does not allocate anything.


+   uccf->ucc_fast_tx_virtual_fifo_base_offset = (u32)ret_muram;
}


checkpatch will rightfully tell you that else after return is generally not 
useful.
Also, the typecast is not necessary.



-   /* Allocate memory for Rx Virtual Fifo */
-   uccf->ucc_fast_rx_virtual_fifo_base_offset =
+   ret_muram =
qe_muram_alloc(uf_info->urfs +
   UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
   UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
-   if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
+   if (IS_ERR_VALUE(ret_muram)) {
printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
__func__);
uccf->ucc_fast_rx_virtual_fifo_base_offset = 0;

Re: [f2fs-dev] [PATCH 3/7] f2fs: drop any block plugging

2016-07-08 Thread Chao Yu

Hi Jaegeuk,

On 2016/6/9 1:24, Jaegeuk Kim wrote:
> In f2fs, we don't need to keep block plugging for NODE and DATA writes, since
> we already merged bios as much as possible.

IMO, we can not remove block plug, this is because there are still many
conditions which stops us merging r/w IOs into one bio as we expect,
theoretically, block plug can hold bios as much as possible, then submitting
them into queue in batch, it will reduce racing of grabbing queue->lock during
bio submitting, if we drop them, when syncing nodes or flushing datas, we will
suffer more lock racing.

Or there are something I am missing, do you suffer any performance issue on
block plug?

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/checkpoint.c |  4 
>  fs/f2fs/data.c   | 17 ++---
>  fs/f2fs/gc.c |  5 -
>  fs/f2fs/segment.c|  7 +--
>  4 files changed, 11 insertions(+), 22 deletions(-)
> 
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index 5ddd15c..4179c7b 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -897,11 +897,8 @@ static int block_operations(struct f2fs_sb_info *sbi)
>   .nr_to_write = LONG_MAX,
>   .for_reclaim = 0,
>   };
> - struct blk_plug plug;
>   int err = 0;
>  
> - blk_start_plug();
> -
>  retry_flush_dents:
>   f2fs_lock_all(sbi);
>   /* write all the dirty dentry pages */
> @@ -938,7 +935,6 @@ retry_flush_nodes:
>   goto retry_flush_nodes;
>   }
>  out:
> - blk_finish_plug();
>   return err;
>  }
>  
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 30dc448..5f655d0 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -98,10 +98,13 @@ static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, 
> block_t blk_addr,
>  }
>  
>  static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
> - struct bio *bio)
> + struct bio *bio, enum page_type type)
>  {
> - if (!is_read_io(rw))
> + if (!is_read_io(rw)) {
>   atomic_inc(>nr_wb_bios);
> + if (current->plug && (type == DATA || type == NODE))
> + blk_finish_plug(current->plug);
> + }
>   submit_bio(rw, bio);
>  }
>  
> @@ -117,7 +120,7 @@ static void __submit_merged_bio(struct f2fs_bio_info *io)
>   else
>   trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
>  
> - __submit_bio(io->sbi, fio->rw, io->bio);
> + __submit_bio(io->sbi, fio->rw, io->bio, fio->type);
>   io->bio = NULL;
>  }
>  
> @@ -235,7 +238,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
>   return -EFAULT;
>   }
>  
> - __submit_bio(fio->sbi, fio->rw, bio);
> + __submit_bio(fio->sbi, fio->rw, bio, fio->type);
>   return 0;
>  }
>  
> @@ -1040,7 +1043,7 @@ got_it:
>*/
>   if (bio && (last_block_in_bio != block_nr - 1)) {
>  submit_and_realloc:
> - __submit_bio(F2FS_I_SB(inode), READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>   bio = NULL;
>   }
>   if (bio == NULL) {
> @@ -1083,7 +1086,7 @@ set_error_page:
>   goto next_page;
>  confused:
>   if (bio) {
> - __submit_bio(F2FS_I_SB(inode), READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>   bio = NULL;
>   }
>   unlock_page(page);
> @@ -1093,7 +1096,7 @@ next_page:
>   }
>   BUG_ON(pages && !list_empty(pages));
>   if (bio)
> - __submit_bio(F2FS_I_SB(inode), READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>   return 0;
>  }
>  
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 4a03076..67fd285 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -777,7 +777,6 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,
>  {
>   struct page *sum_page;
>   struct f2fs_summary_block *sum;
> - struct blk_plug plug;
>   unsigned int segno = start_segno;
>   unsigned int end_segno = start_segno + sbi->segs_per_sec;
>   int seg_freed = 0;
> @@ -795,8 +794,6 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,
>   unlock_page(sum_page);
>   }
>  
> - blk_start_plug();
> -
>   for (segno = start_segno; segno < end_segno; segno++) {
>   /* find segment summary of victim */
>   sum_page = find_get_page(META_MAPPING(sbi),
> @@ -830,8 +827,6 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,
>   f2fs_submit_merged_bio(sbi,
>   (type == SUM_TYPE_NODE) ? NODE : DATA, WRITE);
>  
> - blk_finish_plug();
> -
>   if (gc_type == FG_GC) {
>   while (start_segno < end_segno)
>   if (get_valid_blocks(sbi, start_segno++, 1) == 0)
>

Re: [f2fs-dev] [PATCH 3/7] f2fs: drop any block plugging

2016-07-08 Thread Chao Yu

Hi Jaegeuk,

On 2016/6/9 1:24, Jaegeuk Kim wrote:
> In f2fs, we don't need to keep block plugging for NODE and DATA writes, since
> we already merged bios as much as possible.

IMO, we can not remove block plug, this is because there are still many
conditions which stops us merging r/w IOs into one bio as we expect,
theoretically, block plug can hold bios as much as possible, then submitting
them into queue in batch, it will reduce racing of grabbing queue->lock during
bio submitting, if we drop them, when syncing nodes or flushing datas, we will
suffer more lock racing.

Or there are something I am missing, do you suffer any performance issue on
block plug?

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/checkpoint.c |  4 
>  fs/f2fs/data.c   | 17 ++---
>  fs/f2fs/gc.c |  5 -
>  fs/f2fs/segment.c|  7 +--
>  4 files changed, 11 insertions(+), 22 deletions(-)
> 
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index 5ddd15c..4179c7b 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -897,11 +897,8 @@ static int block_operations(struct f2fs_sb_info *sbi)
>   .nr_to_write = LONG_MAX,
>   .for_reclaim = 0,
>   };
> - struct blk_plug plug;
>   int err = 0;
>  
> - blk_start_plug();
> -
>  retry_flush_dents:
>   f2fs_lock_all(sbi);
>   /* write all the dirty dentry pages */
> @@ -938,7 +935,6 @@ retry_flush_nodes:
>   goto retry_flush_nodes;
>   }
>  out:
> - blk_finish_plug();
>   return err;
>  }
>  
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 30dc448..5f655d0 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -98,10 +98,13 @@ static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, 
> block_t blk_addr,
>  }
>  
>  static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
> - struct bio *bio)
> + struct bio *bio, enum page_type type)
>  {
> - if (!is_read_io(rw))
> + if (!is_read_io(rw)) {
>   atomic_inc(>nr_wb_bios);
> + if (current->plug && (type == DATA || type == NODE))
> + blk_finish_plug(current->plug);
> + }
>   submit_bio(rw, bio);
>  }
>  
> @@ -117,7 +120,7 @@ static void __submit_merged_bio(struct f2fs_bio_info *io)
>   else
>   trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
>  
> - __submit_bio(io->sbi, fio->rw, io->bio);
> + __submit_bio(io->sbi, fio->rw, io->bio, fio->type);
>   io->bio = NULL;
>  }
>  
> @@ -235,7 +238,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
>   return -EFAULT;
>   }
>  
> - __submit_bio(fio->sbi, fio->rw, bio);
> + __submit_bio(fio->sbi, fio->rw, bio, fio->type);
>   return 0;
>  }
>  
> @@ -1040,7 +1043,7 @@ got_it:
>*/
>   if (bio && (last_block_in_bio != block_nr - 1)) {
>  submit_and_realloc:
> - __submit_bio(F2FS_I_SB(inode), READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>   bio = NULL;
>   }
>   if (bio == NULL) {
> @@ -1083,7 +1086,7 @@ set_error_page:
>   goto next_page;
>  confused:
>   if (bio) {
> - __submit_bio(F2FS_I_SB(inode), READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>   bio = NULL;
>   }
>   unlock_page(page);
> @@ -1093,7 +1096,7 @@ next_page:
>   }
>   BUG_ON(pages && !list_empty(pages));
>   if (bio)
> - __submit_bio(F2FS_I_SB(inode), READ, bio);
> + __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
>   return 0;
>  }
>  
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 4a03076..67fd285 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -777,7 +777,6 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,
>  {
>   struct page *sum_page;
>   struct f2fs_summary_block *sum;
> - struct blk_plug plug;
>   unsigned int segno = start_segno;
>   unsigned int end_segno = start_segno + sbi->segs_per_sec;
>   int seg_freed = 0;
> @@ -795,8 +794,6 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,
>   unlock_page(sum_page);
>   }
>  
> - blk_start_plug();
> -
>   for (segno = start_segno; segno < end_segno; segno++) {
>   /* find segment summary of victim */
>   sum_page = find_get_page(META_MAPPING(sbi),
> @@ -830,8 +827,6 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,
>   f2fs_submit_merged_bio(sbi,
>   (type == SUM_TYPE_NODE) ? NODE : DATA, WRITE);
>  
> - blk_finish_plug();
> -
>   if (gc_type == FG_GC) {
>   while (start_segno < end_segno)
>   if (get_valid_blocks(sbi, start_segno++, 1) == 0)
> diff --git

[PATCH v2 2/6] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag

From: Jeremy Gebben 

Allow the creation of privileged mode mappings, for stage 1 only.

Signed-off-by: Jeremy Gebben 
---
 drivers/iommu/io-pgtable-arm.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a1ed1b73fed4..e9e7dd179708 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -101,8 +101,10 @@
 ARM_LPAE_PTE_ATTR_HI_MASK)
 
 /* Stage-1 PTE */
-#define ARM_LPAE_PTE_AP_UNPRIV (((arm_lpae_iopte)1) << 6)
-#define ARM_LPAE_PTE_AP_RDONLY (((arm_lpae_iopte)2) << 6)
+#define ARM_LPAE_PTE_AP_PRIV_RW(((arm_lpae_iopte)0) << 6)
+#define ARM_LPAE_PTE_AP_RW (((arm_lpae_iopte)1) << 6)
+#define ARM_LPAE_PTE_AP_PRIV_RO(((arm_lpae_iopte)2) << 6)
+#define ARM_LPAE_PTE_AP_RO (((arm_lpae_iopte)3) << 6)
 #define ARM_LPAE_PTE_ATTRINDX_SHIFT2
 #define ARM_LPAE_PTE_nG(((arm_lpae_iopte)1) << 11)
 
@@ -350,10 +352,14 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct 
arm_lpae_io_pgtable *data,
 
if (data->iop.fmt == ARM_64_LPAE_S1 ||
data->iop.fmt == ARM_32_LPAE_S1) {
-   pte = ARM_LPAE_PTE_AP_UNPRIV | ARM_LPAE_PTE_nG;
+   pte = ARM_LPAE_PTE_nG;
 
-   if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
-   pte |= ARM_LPAE_PTE_AP_RDONLY;
+   if (prot & IOMMU_WRITE)
+   pte |= (prot & IOMMU_PRIV) ? ARM_LPAE_PTE_AP_PRIV_RW
+   : ARM_LPAE_PTE_AP_RW;
+   else
+   pte |= (prot & IOMMU_PRIV) ? ARM_LPAE_PTE_AP_PRIV_RO
+   : ARM_LPAE_PTE_AP_RO;
 
if (prot & IOMMU_MMIO)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 3/6] Revert "iommu/arm-smmu: Treat all device transactions as unprivileged"

This reverts commit d346180e70b9 ("iommu/arm-smmu: Treat all device
transactions as unprivileged") since some platforms actually make use of
privileged transactions.

Signed-off-by: Mitchel Humpherys 
---
 drivers/iommu/arm-smmu.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 9345a3fcb706..d0627ef26b05 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -178,9 +178,6 @@
 #define S2CR_TYPE_BYPASS   (1 << S2CR_TYPE_SHIFT)
 #define S2CR_TYPE_FAULT(2 << S2CR_TYPE_SHIFT)
 
-#define S2CR_PRIVCFG_SHIFT 24
-#define S2CR_PRIVCFG_UNPRIV(2 << S2CR_PRIVCFG_SHIFT)
-
 /* Context bank attribute registers */
 #define ARM_SMMU_GR1_CBAR(n)   (0x0 + ((n) << 2))
 #define CBAR_VMID_SHIFT0
@@ -1175,7 +1172,7 @@ static int arm_smmu_domain_add_master(struct 
arm_smmu_domain *smmu_domain,
u32 idx, s2cr;
 
idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
-   s2cr = S2CR_TYPE_TRANS | S2CR_PRIVCFG_UNPRIV |
+   s2cr = S2CR_TYPE_TRANS |
   (smmu_domain->cfg.cbndx << S2CR_CBNDX_SHIFT);
writel_relaxed(s2cr, gr0_base + ARM_SMMU_GR0_S2CR(idx));
}
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 5/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE

The newly added DMA_ATTR_PRIVILEGED_EXECUTABLE is useful for creating
mappings that are executable by privileged DMA engines.  Implement it in
dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it.

Signed-off-by: Mitchel Humpherys 
---
 arch/arm64/mm/dma-mapping.c |  6 +++---
 drivers/iommu/dma-iommu.c   | 15 +++
 include/linux/dma-iommu.h   |  3 ++-
 3 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index c566ec83719f..44f676268df6 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -543,7 +543,7 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t 
size,
 struct dma_attrs *attrs)
 {
bool coherent = is_device_dma_coherent(dev);
-   int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
+   int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
size_t iosize = size;
void *addr;
 
@@ -697,7 +697,7 @@ static dma_addr_t __iommu_map_page(struct device *dev, 
struct page *page,
   struct dma_attrs *attrs)
 {
bool coherent = is_device_dma_coherent(dev);
-   int prot = dma_direction_to_prot(dir, coherent);
+   int prot = dma_direction_to_prot(dir, coherent, attrs);
dma_addr_t dev_addr = iommu_dma_map_page(dev, page, offset, size, prot);
 
if (!iommu_dma_mapping_error(dev, dev_addr) &&
@@ -755,7 +755,7 @@ static int __iommu_map_sg_attrs(struct device *dev, struct 
scatterlist *sgl,
__iommu_sync_sg_for_device(dev, sgl, nelems, dir);
 
return iommu_dma_map_sg(dev, sgl, nelems,
-   dma_direction_to_prot(dir, coherent));
+   dma_direction_to_prot(dir, coherent, attrs));
 }
 
 static void __iommu_unmap_sg_attrs(struct device *dev,
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ea5a9ebf0f78..ccc6219da228 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -132,23 +132,30 @@ EXPORT_SYMBOL(iommu_dma_init_domain);
  * dma_direction_to_prot - Translate DMA API directions to IOMMU API page flags
  * @dir: Direction of DMA transfer
  * @coherent: Is the DMA master cache-coherent?
+ * @attrs: DMA attributes for the mapping
  *
  * Return: corresponding IOMMU API page protection flags
  */
-int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
+int dma_direction_to_prot(enum dma_data_direction dir, bool coherent,
+ struct dma_attrs *attrs)
 {
int prot = coherent ? IOMMU_CACHE : 0;
 
switch (dir) {
case DMA_BIDIRECTIONAL:
-   return prot | IOMMU_READ | IOMMU_WRITE;
+   prot |= IOMMU_READ | IOMMU_WRITE;
case DMA_TO_DEVICE:
-   return prot | IOMMU_READ;
+   prot |= IOMMU_READ;
case DMA_FROM_DEVICE:
-   return prot | IOMMU_WRITE;
+   prot |= IOMMU_WRITE;
default:
return 0;
}
+   if (dma_get_attr(DMA_ATTR_PRIVILEGED_EXECUTABLE, attrs)) {
+   prot &= ~IOMMU_WRITE;
+   prot |= IOMMU_PRIV;
+   }
+   return prot;
 }
 
 static struct iova *__alloc_iova(struct iova_domain *iovad, size_t size,
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 8443bbb5c071..d5a37e58d29b 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -32,7 +32,8 @@ void iommu_put_dma_cookie(struct iommu_domain *domain);
 int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base, u64 
size);
 
 /* General helpers for DMA-API <-> IOMMU-API interaction */
-int dma_direction_to_prot(enum dma_data_direction dir, bool coherent);
+int dma_direction_to_prot(enum dma_data_direction dir, bool coherent,
+ struct dma_attrs *attrs);
 
 /*
  * These implement the bulk of the relevant DMA mapping callbacks, but require
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 4/6] common: DMA-mapping: add DMA_ATTR_PRIVILEGED_EXECUTABLE attribute

This patch adds the DMA_ATTR_PRIVILEGED_EXECUTABLE attribute to the
DMA-mapping subsystem.

Some architectures require that writable mappings also be non-executable at
lesser-privileged levels of execution.  This attribute is used to indicate
to the DMA-mapping subsystem that it should do whatever is necessary to
ensure that the buffer is executable at an elevated privilege level (by
making it read-only at the lesser-privileged levels, for example).

Cc: linux-...@vger.kernel.org
Signed-off-by: Mitchel Humpherys 
---
 Documentation/DMA-attributes.txt | 9 +
 include/linux/dma-attrs.h| 1 +
 2 files changed, 10 insertions(+)

diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index e8cf9cf873b3..6a22d4307008 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -126,3 +126,12 @@ means that we won't try quite as hard to get them.
 
 NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM,
 though ARM64 patches will likely be posted soon.
+
+DMA_ATTR_PRIVILEGED_EXECUTABLE
+--
+
+Some architectures require that writable mappings also be non-executable at
+lesser-privileged levels of execution.  This attribute is used to indicate
+to the DMA-mapping subsystem that it should do whatever is necessary to
+ensure that the buffer is executable at an elevated privilege level (by
+making it read-only at the lesser-privileged levels, for example).
diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
index 5246239a4953..8cf4dff6185b 100644
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -19,6 +19,7 @@ enum dma_attr {
DMA_ATTR_SKIP_CPU_SYNC,
DMA_ATTR_FORCE_CONTIGUOUS,
DMA_ATTR_ALLOC_SINGLE_PAGES,
+   DMA_ATTR_PRIVILEGED_EXECUTABLE,
DMA_ATTR_MAX,
 };
 
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/6] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag

From: Jeremy Gebben 

Allow the creation of privileged mode mappings, for stage 1 only.

Signed-off-by: Jeremy Gebben 
---
 drivers/iommu/io-pgtable-arm.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a1ed1b73fed4..e9e7dd179708 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -101,8 +101,10 @@
 ARM_LPAE_PTE_ATTR_HI_MASK)
 
 /* Stage-1 PTE */
-#define ARM_LPAE_PTE_AP_UNPRIV (((arm_lpae_iopte)1) << 6)
-#define ARM_LPAE_PTE_AP_RDONLY (((arm_lpae_iopte)2) << 6)
+#define ARM_LPAE_PTE_AP_PRIV_RW(((arm_lpae_iopte)0) << 6)
+#define ARM_LPAE_PTE_AP_RW (((arm_lpae_iopte)1) << 6)
+#define ARM_LPAE_PTE_AP_PRIV_RO(((arm_lpae_iopte)2) << 6)
+#define ARM_LPAE_PTE_AP_RO (((arm_lpae_iopte)3) << 6)
 #define ARM_LPAE_PTE_ATTRINDX_SHIFT2
 #define ARM_LPAE_PTE_nG(((arm_lpae_iopte)1) << 11)
 
@@ -350,10 +352,14 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct 
arm_lpae_io_pgtable *data,
 
if (data->iop.fmt == ARM_64_LPAE_S1 ||
data->iop.fmt == ARM_32_LPAE_S1) {
-   pte = ARM_LPAE_PTE_AP_UNPRIV | ARM_LPAE_PTE_nG;
+   pte = ARM_LPAE_PTE_nG;
 
-   if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
-   pte |= ARM_LPAE_PTE_AP_RDONLY;
+   if (prot & IOMMU_WRITE)
+   pte |= (prot & IOMMU_PRIV) ? ARM_LPAE_PTE_AP_PRIV_RW
+   : ARM_LPAE_PTE_AP_RW;
+   else
+   pte |= (prot & IOMMU_PRIV) ? ARM_LPAE_PTE_AP_PRIV_RO
+   : ARM_LPAE_PTE_AP_RO;
 
if (prot & IOMMU_MMIO)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 3/6] Revert "iommu/arm-smmu: Treat all device transactions as unprivileged"

This reverts commit d346180e70b9 ("iommu/arm-smmu: Treat all device
transactions as unprivileged") since some platforms actually make use of
privileged transactions.

Signed-off-by: Mitchel Humpherys 
---
 drivers/iommu/arm-smmu.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 9345a3fcb706..d0627ef26b05 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -178,9 +178,6 @@
 #define S2CR_TYPE_BYPASS   (1 << S2CR_TYPE_SHIFT)
 #define S2CR_TYPE_FAULT(2 << S2CR_TYPE_SHIFT)
 
-#define S2CR_PRIVCFG_SHIFT 24
-#define S2CR_PRIVCFG_UNPRIV(2 << S2CR_PRIVCFG_SHIFT)
-
 /* Context bank attribute registers */
 #define ARM_SMMU_GR1_CBAR(n)   (0x0 + ((n) << 2))
 #define CBAR_VMID_SHIFT0
@@ -1175,7 +1172,7 @@ static int arm_smmu_domain_add_master(struct 
arm_smmu_domain *smmu_domain,
u32 idx, s2cr;
 
idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
-   s2cr = S2CR_TYPE_TRANS | S2CR_PRIVCFG_UNPRIV |
+   s2cr = S2CR_TYPE_TRANS |
   (smmu_domain->cfg.cbndx << S2CR_CBNDX_SHIFT);
writel_relaxed(s2cr, gr0_base + ARM_SMMU_GR0_S2CR(idx));
}
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 5/6] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE

The newly added DMA_ATTR_PRIVILEGED_EXECUTABLE is useful for creating
mappings that are executable by privileged DMA engines.  Implement it in
dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it.

Signed-off-by: Mitchel Humpherys 
---
 arch/arm64/mm/dma-mapping.c |  6 +++---
 drivers/iommu/dma-iommu.c   | 15 +++
 include/linux/dma-iommu.h   |  3 ++-
 3 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index c566ec83719f..44f676268df6 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -543,7 +543,7 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t 
size,
 struct dma_attrs *attrs)
 {
bool coherent = is_device_dma_coherent(dev);
-   int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
+   int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
size_t iosize = size;
void *addr;
 
@@ -697,7 +697,7 @@ static dma_addr_t __iommu_map_page(struct device *dev, 
struct page *page,
   struct dma_attrs *attrs)
 {
bool coherent = is_device_dma_coherent(dev);
-   int prot = dma_direction_to_prot(dir, coherent);
+   int prot = dma_direction_to_prot(dir, coherent, attrs);
dma_addr_t dev_addr = iommu_dma_map_page(dev, page, offset, size, prot);
 
if (!iommu_dma_mapping_error(dev, dev_addr) &&
@@ -755,7 +755,7 @@ static int __iommu_map_sg_attrs(struct device *dev, struct 
scatterlist *sgl,
__iommu_sync_sg_for_device(dev, sgl, nelems, dir);
 
return iommu_dma_map_sg(dev, sgl, nelems,
-   dma_direction_to_prot(dir, coherent));
+   dma_direction_to_prot(dir, coherent, attrs));
 }
 
 static void __iommu_unmap_sg_attrs(struct device *dev,
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ea5a9ebf0f78..ccc6219da228 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -132,23 +132,30 @@ EXPORT_SYMBOL(iommu_dma_init_domain);
  * dma_direction_to_prot - Translate DMA API directions to IOMMU API page flags
  * @dir: Direction of DMA transfer
  * @coherent: Is the DMA master cache-coherent?
+ * @attrs: DMA attributes for the mapping
  *
  * Return: corresponding IOMMU API page protection flags
  */
-int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
+int dma_direction_to_prot(enum dma_data_direction dir, bool coherent,
+ struct dma_attrs *attrs)
 {
int prot = coherent ? IOMMU_CACHE : 0;
 
switch (dir) {
case DMA_BIDIRECTIONAL:
-   return prot | IOMMU_READ | IOMMU_WRITE;
+   prot |= IOMMU_READ | IOMMU_WRITE;
case DMA_TO_DEVICE:
-   return prot | IOMMU_READ;
+   prot |= IOMMU_READ;
case DMA_FROM_DEVICE:
-   return prot | IOMMU_WRITE;
+   prot |= IOMMU_WRITE;
default:
return 0;
}
+   if (dma_get_attr(DMA_ATTR_PRIVILEGED_EXECUTABLE, attrs)) {
+   prot &= ~IOMMU_WRITE;
+   prot |= IOMMU_PRIV;
+   }
+   return prot;
 }
 
 static struct iova *__alloc_iova(struct iova_domain *iovad, size_t size,
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 8443bbb5c071..d5a37e58d29b 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -32,7 +32,8 @@ void iommu_put_dma_cookie(struct iommu_domain *domain);
 int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base, u64 
size);
 
 /* General helpers for DMA-API <-> IOMMU-API interaction */
-int dma_direction_to_prot(enum dma_data_direction dir, bool coherent);
+int dma_direction_to_prot(enum dma_data_direction dir, bool coherent,
+ struct dma_attrs *attrs);
 
 /*
  * These implement the bulk of the relevant DMA mapping callbacks, but require
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 4/6] common: DMA-mapping: add DMA_ATTR_PRIVILEGED_EXECUTABLE attribute

This patch adds the DMA_ATTR_PRIVILEGED_EXECUTABLE attribute to the
DMA-mapping subsystem.

Some architectures require that writable mappings also be non-executable at
lesser-privileged levels of execution.  This attribute is used to indicate
to the DMA-mapping subsystem that it should do whatever is necessary to
ensure that the buffer is executable at an elevated privilege level (by
making it read-only at the lesser-privileged levels, for example).

Cc: linux-...@vger.kernel.org
Signed-off-by: Mitchel Humpherys 
---
 Documentation/DMA-attributes.txt | 9 +
 include/linux/dma-attrs.h| 1 +
 2 files changed, 10 insertions(+)

diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index e8cf9cf873b3..6a22d4307008 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -126,3 +126,12 @@ means that we won't try quite as hard to get them.
 
 NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM,
 though ARM64 patches will likely be posted soon.
+
+DMA_ATTR_PRIVILEGED_EXECUTABLE
+--
+
+Some architectures require that writable mappings also be non-executable at
+lesser-privileged levels of execution.  This attribute is used to indicate
+to the DMA-mapping subsystem that it should do whatever is necessary to
+ensure that the buffer is executable at an elevated privilege level (by
+making it read-only at the lesser-privileged levels, for example).
diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
index 5246239a4953..8cf4dff6185b 100644
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -19,6 +19,7 @@ enum dma_attr {
DMA_ATTR_SKIP_CPU_SYNC,
DMA_ATTR_FORCE_CONTIGUOUS,
DMA_ATTR_ALLOC_SINGLE_PAGES,
+   DMA_ATTR_PRIVILEGED_EXECUTABLE,
DMA_ATTR_MAX,
 };
 
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/6] iommu: add IOMMU_PRIV attribute

Add the IOMMU_PRIV attribute, which is used to indicate privileged
mappings.

Signed-off-by: Mitchel Humpherys 
---
 include/linux/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 664683aedcce..01c9f2667f2b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -31,6 +31,7 @@
 #define IOMMU_CACHE(1 << 2) /* DMA cache coherency */
 #define IOMMU_NOEXEC   (1 << 3)
 #define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
+#define IOMMU_PRIV (1 << 5)
 
 struct iommu_ops;
 struct iommu_group;
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/6] iommu: add IOMMU_PRIV attribute

Add the IOMMU_PRIV attribute, which is used to indicate privileged
mappings.

Signed-off-by: Mitchel Humpherys 
---
 include/linux/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 664683aedcce..01c9f2667f2b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -31,6 +31,7 @@
 #define IOMMU_CACHE(1 << 2) /* DMA cache coherency */
 #define IOMMU_NOEXEC   (1 << 3)
 #define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
+#define IOMMU_PRIV (1 << 5)
 
 struct iommu_ops;
 struct iommu_group;
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 0/6] Add support for privileged mappings

The following patch to the ARM SMMU driver:

commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
Author: Robin Murphy 
Date:   Tue Jan 26 18:06:34 2016 +

iommu/arm-smmu: Treat all device transactions as unprivileged

started forcing all SMMU transactions to come through as "unprivileged".
The rationale given was that:

  (1) There is no way in the IOMMU API to even request privileged mappings.

  (2) It's difficult to implement a DMA mapper that correctly models the
  ARM VMSAv8 behavior of unprivileged-writeable =>
  privileged-execute-never.

This series rectifies (1) by introducing an IOMMU API for privileged
mappings and implements it in io-pgtable-arm.

This series rectifies (2) by introducing a new dma attribute
(DMA_ATTR_PRIVILEGED_EXECUTABLE) for users of the DMA API that need
privileged, executable mappings, and implements it in the arm64 IOMMU DMA
mapper.  The one known user (pl330.c) is converted over to the new
attribute.

Jordan and Jeremy can provide more info on the use case if needed, but the
high level is that it's a security feature to prevent attacks such as [1].

[1] https://github.com/robclark/kilroy

Changelog:

  v1..v2

- Added a new DMA attribute to make executable privileged mappings
  work, and use that in the pl330 driver (suggested by Will).


Jeremy Gebben (1):
  iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag

Mitchel Humpherys (5):
  iommu: add IOMMU_PRIV attribute
  Revert "iommu/arm-smmu: Treat all device transactions as unprivileged"
  common: DMA-mapping: add DMA_ATTR_PRIVILEGED_EXECUTABLE attribute
  arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE
  dmaengine: pl330: Make sure microcode is privileged-executable

 Documentation/DMA-attributes.txt |  9 +
 arch/arm64/mm/dma-mapping.c  |  6 +++---
 drivers/dma/pl330.c  |  7 +--
 drivers/iommu/arm-smmu.c |  5 +
 drivers/iommu/dma-iommu.c| 15 +++
 drivers/iommu/io-pgtable-arm.c   | 16 +++-
 include/linux/dma-attrs.h|  1 +
 include/linux/dma-iommu.h|  3 ++-
 include/linux/iommu.h|  1 +
 9 files changed, 44 insertions(+), 19 deletions(-)

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

[PATCH v2 6/6] dmaengine: pl330: Make sure microcode is privileged-executable

The PL330 can perform privileged instruction fetches.  This can result
in SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which
specifies that mappings that are writeable at one execution level shall
not be executable at any higher-privileged level.  Fix this by using the
DMA_ATTR_PRIVILEGED_EXECUTABLE attribute, which will ensure that the
microcode IOMMU mapping is not writeable.

Cc: Dan Williams 
Cc: Jassi Brar 
Signed-off-by: Mitchel Humpherys 
---
 drivers/dma/pl330.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 372b4359da97..25bc49d47c45 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1854,14 +1854,17 @@ static int dmac_alloc_resources(struct pl330_dmac 
*pl330)
 {
int chans = pl330->pcfg.num_chan;
int ret;
+   DEFINE_DMA_ATTRS(attrs);
 
+   dma_set_attr(DMA_ATTR_PRIVILEGED_EXECUTABLE, );
/*
 * Alloc MicroCode buffer for 'chans' Channel threads.
 * A channel's buffer offset is (Channel_Id * MCODE_BUFF_PERCHAN)
 */
-   pl330->mcode_cpu = dma_alloc_coherent(pl330->ddma.dev,
+   pl330->mcode_cpu = dma_alloc_attrs(pl330->ddma.dev,
chans * pl330->mcbufsz,
-   >mcode_bus, GFP_KERNEL);
+   >mcode_bus, GFP_KERNEL,
+   );
if (!pl330->mcode_cpu) {
dev_err(pl330->ddma.dev, "%s:%d Can't allocate memory!\n",
__func__, __LINE__);
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 0/6] Add support for privileged mappings

The following patch to the ARM SMMU driver:

commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
Author: Robin Murphy 
Date:   Tue Jan 26 18:06:34 2016 +

iommu/arm-smmu: Treat all device transactions as unprivileged

started forcing all SMMU transactions to come through as "unprivileged".
The rationale given was that:

  (1) There is no way in the IOMMU API to even request privileged mappings.

  (2) It's difficult to implement a DMA mapper that correctly models the
  ARM VMSAv8 behavior of unprivileged-writeable =>
  privileged-execute-never.

This series rectifies (1) by introducing an IOMMU API for privileged
mappings and implements it in io-pgtable-arm.

This series rectifies (2) by introducing a new dma attribute
(DMA_ATTR_PRIVILEGED_EXECUTABLE) for users of the DMA API that need
privileged, executable mappings, and implements it in the arm64 IOMMU DMA
mapper.  The one known user (pl330.c) is converted over to the new
attribute.

Jordan and Jeremy can provide more info on the use case if needed, but the
high level is that it's a security feature to prevent attacks such as [1].

[1] https://github.com/robclark/kilroy

Changelog:

  v1..v2

- Added a new DMA attribute to make executable privileged mappings
  work, and use that in the pl330 driver (suggested by Will).


Jeremy Gebben (1):
  iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag

Mitchel Humpherys (5):
  iommu: add IOMMU_PRIV attribute
  Revert "iommu/arm-smmu: Treat all device transactions as unprivileged"
  common: DMA-mapping: add DMA_ATTR_PRIVILEGED_EXECUTABLE attribute
  arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED_EXECUTABLE
  dmaengine: pl330: Make sure microcode is privileged-executable

 Documentation/DMA-attributes.txt |  9 +
 arch/arm64/mm/dma-mapping.c  |  6 +++---
 drivers/dma/pl330.c  |  7 +--
 drivers/iommu/arm-smmu.c |  5 +
 drivers/iommu/dma-iommu.c| 15 +++
 drivers/iommu/io-pgtable-arm.c   | 16 +++-
 include/linux/dma-attrs.h|  1 +
 include/linux/dma-iommu.h|  3 ++-
 include/linux/iommu.h|  1 +
 9 files changed, 44 insertions(+), 19 deletions(-)

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

[PATCH v2 6/6] dmaengine: pl330: Make sure microcode is privileged-executable

The PL330 can perform privileged instruction fetches.  This can result
in SMMU permission faults on SMMUs that implement the ARMv8 VMSA, which
specifies that mappings that are writeable at one execution level shall
not be executable at any higher-privileged level.  Fix this by using the
DMA_ATTR_PRIVILEGED_EXECUTABLE attribute, which will ensure that the
microcode IOMMU mapping is not writeable.

Cc: Dan Williams 
Cc: Jassi Brar 
Signed-off-by: Mitchel Humpherys 
---
 drivers/dma/pl330.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 372b4359da97..25bc49d47c45 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1854,14 +1854,17 @@ static int dmac_alloc_resources(struct pl330_dmac 
*pl330)
 {
int chans = pl330->pcfg.num_chan;
int ret;
+   DEFINE_DMA_ATTRS(attrs);
 
+   dma_set_attr(DMA_ATTR_PRIVILEGED_EXECUTABLE, );
/*
 * Alloc MicroCode buffer for 'chans' Channel threads.
 * A channel's buffer offset is (Channel_Id * MCODE_BUFF_PERCHAN)
 */
-   pl330->mcode_cpu = dma_alloc_coherent(pl330->ddma.dev,
+   pl330->mcode_cpu = dma_alloc_attrs(pl330->ddma.dev,
chans * pl330->mcbufsz,
-   >mcode_bus, GFP_KERNEL);
+   >mcode_bus, GFP_KERNEL,
+   );
if (!pl330->mcode_cpu) {
dev_err(pl330->ddma.dev, "%s:%d Can't allocate memory!\n",
__func__, __LINE__);
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] printk: introduce suppress_message_printing()

2016-07-08 Thread Sergey Senozhatsky

On (06/27/16 22:50), Sergey Senozhatsky wrote:
> Messages' levels and console log level are inspected when the
> actual printing occurs, which may provoke console_unlock() and
> console_cont_flush() to waste CPU cycles on every message that
> has loglevel above the current console_loglevel.
> 
> Schematically, console_unlock() does the following:

Hello Andrew,

just in case if you missed this one. the patch is fine.

the cont printk problem I talked about in the v1 thread
is not related to this patch, but to *async* printk (which
is not in the mainline... yet. hm... shall we discuss it
on the kernel summit?)

-ss

> console_unlock()
> {
> ...
> for (;;) {
> ...
> raw_spin_lock_irqsave(_lock, flags);
> skip:
> msg = log_from_idx(console_idx);
> 
> if (msg->flags & LOG_NOCONS) {
> ...
> goto skip;
> }
> 
> level = msg->level;
> len += msg_print_text();>> sprintfs
>memcpy,
>etc.
> 
> if (nr_ext_console_drivers) {
> ext_len = msg_print_ext_header();   >> scnprintf
> ext_len += msg_print_ext_body();>> scnprintfs
>etc.
> }
> ...
> raw_spin_unlock(_lock);
> 
> call_console_drivers(level, ext_text, ext_len, text, len)
> {
> if (level >= console_loglevel &&>> drop the 
> message
> !ignore_loglevel)
> return;
> 
> console->write(...);
> }
> 
> local_irq_restore(flags);
> }
> ...
> }
> 
> The thing here is this deferred `level >= console_loglevel' check. We are
> wasting CPU cycles on sprintfs/memcpy/etc. preparing the messages that we
> will eventually drop.
> 
> This can be huge when we register a new CON_PRINTBUFFER console, for
> instance. For every such a console register_console() resets the
> console_seq, console_idx, console_prev
> and sets a `exclusive console' pointer to replay the log buffer to that
> just-registered console. And there can be a lot of messages to replay, in
> the worst case most of which can be dropped after console_loglevel test.
> 
> We know messages' levels long before we call msg_print_text() and friends,
> so we can just move console_loglevel check out of call_console_drivers()
> and format a new message only if we are sure that it won't be dropped.
> 
> The patch factors out loglevel check into suppress_message_printing()
> function and tests message->level and console_loglevel before formatting
> functions in console_unlock() and console_cont_flush() are getting
> executed. This improves things not only for exclusive CON_PRINTBUFFER
> consoles, but for every console_unlock() that attempts to print a
> message of level above the console_loglevel.
> 
> Signed-off-by: Sergey Senozhatsky 
> Reviewed-by: Petr Mladek 
> ---
> 
> v2: rename function to suppress_message_printing()
> 
>  kernel/printk/printk.c | 25 +++--
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 414a89f..33957d2 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -987,6 +987,11 @@ module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(ignore_loglevel,
>"ignore loglevel setting (prints all kernel messages to the 
> console)");
>  
> +static bool suppress_message_printing(int level)
> +{
> + return (level >= console_loglevel && !ignore_loglevel);
> +}
> +
>  #ifdef CONFIG_BOOT_PRINTK_DELAY
>  
>  static int boot_delay; /* msecs delay after each printk during bootup */
> @@ -1016,7 +1021,7 @@ static void boot_delay_msec(int level)
>   unsigned long timeout;
>  
>   if ((boot_delay == 0 || system_state != SYSTEM_BOOTING)
> - || (level >= console_loglevel && !ignore_loglevel)) {
> + || suppress_message_printing(level)) {
>   return;
>   }
>  
> @@ -1506,8 +1511,6 @@ static void call_console_drivers(int level,
>  
>   trace_console(text, len);
>  
> - if (level >= console_loglevel && !ignore_loglevel)
> - return;
>   if (!console_drivers)
>   return;
>  
> @@ -1955,6 +1958,7 @@ static void call_console_drivers(int level,
>  static size_t msg_print_text(const struct printk_log *msg, enum log_flags 
> prev,
>bool syslog, char *buf, size_t size) { return 0; }
>  static

Re: [PATCH v2] printk: introduce suppress_message_printing()

2016-07-08 Thread Sergey Senozhatsky

On (06/27/16 22:50), Sergey Senozhatsky wrote:
> Messages' levels and console log level are inspected when the
> actual printing occurs, which may provoke console_unlock() and
> console_cont_flush() to waste CPU cycles on every message that
> has loglevel above the current console_loglevel.
> 
> Schematically, console_unlock() does the following:

Hello Andrew,

just in case if you missed this one. the patch is fine.

the cont printk problem I talked about in the v1 thread
is not related to this patch, but to *async* printk (which
is not in the mainline... yet. hm... shall we discuss it
on the kernel summit?)

-ss

> console_unlock()
> {
> ...
> for (;;) {
> ...
> raw_spin_lock_irqsave(_lock, flags);
> skip:
> msg = log_from_idx(console_idx);
> 
> if (msg->flags & LOG_NOCONS) {
> ...
> goto skip;
> }
> 
> level = msg->level;
> len += msg_print_text();>> sprintfs
>memcpy,
>etc.
> 
> if (nr_ext_console_drivers) {
> ext_len = msg_print_ext_header();   >> scnprintf
> ext_len += msg_print_ext_body();>> scnprintfs
>etc.
> }
> ...
> raw_spin_unlock(_lock);
> 
> call_console_drivers(level, ext_text, ext_len, text, len)
> {
> if (level >= console_loglevel &&>> drop the 
> message
> !ignore_loglevel)
> return;
> 
> console->write(...);
> }
> 
> local_irq_restore(flags);
> }
> ...
> }
> 
> The thing here is this deferred `level >= console_loglevel' check. We are
> wasting CPU cycles on sprintfs/memcpy/etc. preparing the messages that we
> will eventually drop.
> 
> This can be huge when we register a new CON_PRINTBUFFER console, for
> instance. For every such a console register_console() resets the
> console_seq, console_idx, console_prev
> and sets a `exclusive console' pointer to replay the log buffer to that
> just-registered console. And there can be a lot of messages to replay, in
> the worst case most of which can be dropped after console_loglevel test.
> 
> We know messages' levels long before we call msg_print_text() and friends,
> so we can just move console_loglevel check out of call_console_drivers()
> and format a new message only if we are sure that it won't be dropped.
> 
> The patch factors out loglevel check into suppress_message_printing()
> function and tests message->level and console_loglevel before formatting
> functions in console_unlock() and console_cont_flush() are getting
> executed. This improves things not only for exclusive CON_PRINTBUFFER
> consoles, but for every console_unlock() that attempts to print a
> message of level above the console_loglevel.
> 
> Signed-off-by: Sergey Senozhatsky 
> Reviewed-by: Petr Mladek 
> ---
> 
> v2: rename function to suppress_message_printing()
> 
>  kernel/printk/printk.c | 25 +++--
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 414a89f..33957d2 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -987,6 +987,11 @@ module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(ignore_loglevel,
>"ignore loglevel setting (prints all kernel messages to the 
> console)");
>  
> +static bool suppress_message_printing(int level)
> +{
> + return (level >= console_loglevel && !ignore_loglevel);
> +}
> +
>  #ifdef CONFIG_BOOT_PRINTK_DELAY
>  
>  static int boot_delay; /* msecs delay after each printk during bootup */
> @@ -1016,7 +1021,7 @@ static void boot_delay_msec(int level)
>   unsigned long timeout;
>  
>   if ((boot_delay == 0 || system_state != SYSTEM_BOOTING)
> - || (level >= console_loglevel && !ignore_loglevel)) {
> + || suppress_message_printing(level)) {
>   return;
>   }
>  
> @@ -1506,8 +1511,6 @@ static void call_console_drivers(int level,
>  
>   trace_console(text, len);
>  
> - if (level >= console_loglevel && !ignore_loglevel)
> - return;
>   if (!console_drivers)
>   return;
>  
> @@ -1955,6 +1958,7 @@ static void call_console_drivers(int level,
>  static size_t msg_print_text(const struct printk_log *msg, enum log_flags 
> prev,
>bool syslog, char *buf, size_t size) { return 0; }
>  static size_t cont_print_text(char *text, size_t size) {

Re: [PATCH v2 2/2] x86/acpi: Remove the repeated lapic address override entry parsing

2016-07-08 Thread Baoquan He

Hi Ingo,

On 07/08/16 at 02:27pm, Ingo Molnar wrote:
> 
> * Baoquan He  wrote:
> 
> > ACPI MADT has a 32-bit field providing lapic address at which
> > each processor can access its lapic information. MADT also contains
> > an optional entry to provide a 64-bit address to override the 32-bit
> > one. However the current code does the lapic address override entry
> > parsing twice. One is in early_acpi_boot_init() because AMD NUMA need
> > get boot_cpu_id earlier. The other is in acpi_boot_init() which parses
> > all MADT entries.
> > 
> > So in this patch remove the repeated code in the 2nd part. Meanwhile
> > print lapic override entry information like other MADT entry.
> 
> So this patch is not supposed to change behavior (modulo kernel messages), 
> right? 
> If so it would make sense to spell that out explicitly in the changelog.

I am not sure if I understand your question correctly. In this patch I
added the calling of acpi_table_print_madt_entry(header) in
acpi_parse_lapic_addr_ovr, it will print information related if a lapic
address override entry is provided as below:

case ACPI_MADT_TYPE_LOCAL_APIC_OVERRIDE:
  
{   
  
struct acpi_madt_local_apic_override *p =   
  
(struct acpi_madt_local_apic_override*)header;  
 
pr_info("LAPIC_ADDR_OVR (address[%p])\n",   
  
(void *)(unsigned long)p->address); 
  
}   
  
break;

This will add one line of message to boot log if lapic addr override
entry provided:
"LAPIC_ADDR_OVR (address[0x])"

I don't know if this is the behaviour change (modulo kernel messages)
you mentioned.

Thanks
Baoquan

Re: [PATCH v2 2/2] x86/acpi: Remove the repeated lapic address override entry parsing

2016-07-08 Thread Baoquan He

Hi Ingo,

On 07/08/16 at 02:27pm, Ingo Molnar wrote:
> 
> * Baoquan He  wrote:
> 
> > ACPI MADT has a 32-bit field providing lapic address at which
> > each processor can access its lapic information. MADT also contains
> > an optional entry to provide a 64-bit address to override the 32-bit
> > one. However the current code does the lapic address override entry
> > parsing twice. One is in early_acpi_boot_init() because AMD NUMA need
> > get boot_cpu_id earlier. The other is in acpi_boot_init() which parses
> > all MADT entries.
> > 
> > So in this patch remove the repeated code in the 2nd part. Meanwhile
> > print lapic override entry information like other MADT entry.
> 
> So this patch is not supposed to change behavior (modulo kernel messages), 
> right? 
> If so it would make sense to spell that out explicitly in the changelog.

I am not sure if I understand your question correctly. In this patch I
added the calling of acpi_table_print_madt_entry(header) in
acpi_parse_lapic_addr_ovr, it will print information related if a lapic
address override entry is provided as below:

case ACPI_MADT_TYPE_LOCAL_APIC_OVERRIDE:
  
{   
  
struct acpi_madt_local_apic_override *p =   
  
(struct acpi_madt_local_apic_override*)header;  
 
pr_info("LAPIC_ADDR_OVR (address[%p])\n",   
  
(void *)(unsigned long)p->address); 
  
}   
  
break;

This will add one line of message to boot log if lapic addr override
entry provided:
"LAPIC_ADDR_OVR (address[0x])"

I don't know if this is the behaviour change (modulo kernel messages)
you mentioned.

Thanks
Baoquan

[PATCH v2 2/2] input: add ADC resistor ladder driver

A common way of multiplexing buttons on a single input in cheap devices is
to use a resistor ladder on an ADC. This driver supports that configuration
by polling an ADC channel provided by IIO.

Signed-off-by: Alexandre Belloni 
---
Changes in v2:
 - removed dependency on COMPILE_TEST which is not useful anyway
 - use new bindings

 drivers/input/keyboard/Kconfig|  15 +++
 drivers/input/keyboard/Makefile   |   1 +
 drivers/input/keyboard/adc-keys.c | 210 ++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/input/keyboard/adc-keys.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 509608c95994..4cf042cc5e63 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -12,6 +12,21 @@ menuconfig INPUT_KEYBOARD
 
 if INPUT_KEYBOARD
 
+config KEYBOARD_ADC
+   tristate "ADC ladder Buttons"
+   depends on IIO
+   select INPUT_POLLDEV
+   help
+ This driver implements support for buttons connected
+ to an ADC using a resistor ladder.
+
+ Say Y here if your device has such buttons connected to an ADC.  Your
+ board-specific setup logic must also provide a configuration data
+ saying mapping voltages to buttons.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adc_keys.
+
 config KEYBOARD_ADP5520
tristate "Keypad Support for ADP5520 PMIC"
depends on PMIC_ADP5520
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 1d416ddf84e4..d9f4cfcf3410 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -4,6 +4,7 @@
 
 # Each configuration option enables a list of files.
 
+obj-$(CONFIG_KEYBOARD_ADC) += adc-keys.o
 obj-$(CONFIG_KEYBOARD_ADP5520) += adp5520-keys.o
 obj-$(CONFIG_KEYBOARD_ADP5588) += adp5588-keys.o
 obj-$(CONFIG_KEYBOARD_ADP5589) += adp5589-keys.o
diff --git a/drivers/input/keyboard/adc-keys.c 
b/drivers/input/keyboard/adc-keys.c
new file mode 100644
index ..cf299ff517a0
--- /dev/null
+++ b/drivers/input/keyboard/adc-keys.c
@@ -0,0 +1,210 @@
+/* Input driver for resistor ladder connected on ADC
+ *
+ * Copyright (c) 2016 Alexandre Belloni
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct adc_keys_button {
+   u32 voltage;
+   u32 keycode;
+};
+
+struct adc_keys_state {
+   struct iio_channel *channel;
+   u32 num_keys;
+   u32 last_key;
+   u32 keyup_voltage;
+   struct adc_keys_button *map;
+};
+
+static void adc_keys_poll(struct input_polled_dev *dev)
+{
+   struct adc_keys_state *st = dev->private;
+   int i, value, ret;
+   u32 diff, closest = 0x;
+   int keycode = 0;
+
+   ret = iio_read_channel_processed(st->channel, );
+   if (ret < 0) {
+   if (st->last_key) {
+   input_report_key(dev->input, st->last_key, 0);
+   input_sync(dev->input);
+   st->last_key = 0;
+   }
+   return;
+   }
+
+   for (i = 0; i < st->num_keys; i++) {
+   diff = abs(st->map[i].voltage - value);
+   if (diff < closest) {
+   closest = diff;
+   keycode = st->map[i].keycode;
+   }
+   }
+
+   if (abs(st->keyup_voltage - value) < closest) {
+   input_report_key(dev->input, st->last_key, 0);
+   st->last_key = 0;
+   } else {
+   if (st->last_key && st->last_key != keycode)
+   input_report_key(dev->input, st->last_key, 0);
+   input_report_key(dev->input, keycode, 1);
+   st->last_key = keycode;
+   }
+
+   input_sync(dev->input);
+}
+
+static int adc_keys_load_dt_keymap(struct device *dev,
+  struct adc_keys_state *st)
+{
+   struct device_node *pp, *np = dev->of_node;
+   int i;
+
+   st->num_keys = of_get_child_count(np);
+   if (st->num_keys == 0) {
+   dev_err(dev, "keymap is missing\n");
+   return -EINVAL;
+   }
+
+   st->map = devm_kmalloc_array(dev, st->num_keys, sizeof(*st->map),
+GFP_KERNEL);
+   if (!st->map)
+   return -ENOMEM;
+
+   i = 0;
+   for_each_child_of_node(np, pp) {
+   struct adc_keys_button *map = >map[i];
+
+   if (of_property_read_u32(pp, "press-threshold-mvolt",
+>voltage)) {
+   dev_err(dev, "%s: Invalid or

[PATCH v2 2/2] input: add ADC resistor ladder driver

A common way of multiplexing buttons on a single input in cheap devices is
to use a resistor ladder on an ADC. This driver supports that configuration
by polling an ADC channel provided by IIO.

Signed-off-by: Alexandre Belloni 
---
Changes in v2:
 - removed dependency on COMPILE_TEST which is not useful anyway
 - use new bindings

 drivers/input/keyboard/Kconfig|  15 +++
 drivers/input/keyboard/Makefile   |   1 +
 drivers/input/keyboard/adc-keys.c | 210 ++
 3 files changed, 226 insertions(+)
 create mode 100644 drivers/input/keyboard/adc-keys.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 509608c95994..4cf042cc5e63 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -12,6 +12,21 @@ menuconfig INPUT_KEYBOARD
 
 if INPUT_KEYBOARD
 
+config KEYBOARD_ADC
+   tristate "ADC ladder Buttons"
+   depends on IIO
+   select INPUT_POLLDEV
+   help
+ This driver implements support for buttons connected
+ to an ADC using a resistor ladder.
+
+ Say Y here if your device has such buttons connected to an ADC.  Your
+ board-specific setup logic must also provide a configuration data
+ saying mapping voltages to buttons.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adc_keys.
+
 config KEYBOARD_ADP5520
tristate "Keypad Support for ADP5520 PMIC"
depends on PMIC_ADP5520
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 1d416ddf84e4..d9f4cfcf3410 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -4,6 +4,7 @@
 
 # Each configuration option enables a list of files.
 
+obj-$(CONFIG_KEYBOARD_ADC) += adc-keys.o
 obj-$(CONFIG_KEYBOARD_ADP5520) += adp5520-keys.o
 obj-$(CONFIG_KEYBOARD_ADP5588) += adp5588-keys.o
 obj-$(CONFIG_KEYBOARD_ADP5589) += adp5589-keys.o
diff --git a/drivers/input/keyboard/adc-keys.c 
b/drivers/input/keyboard/adc-keys.c
new file mode 100644
index ..cf299ff517a0
--- /dev/null
+++ b/drivers/input/keyboard/adc-keys.c
@@ -0,0 +1,210 @@
+/* Input driver for resistor ladder connected on ADC
+ *
+ * Copyright (c) 2016 Alexandre Belloni
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct adc_keys_button {
+   u32 voltage;
+   u32 keycode;
+};
+
+struct adc_keys_state {
+   struct iio_channel *channel;
+   u32 num_keys;
+   u32 last_key;
+   u32 keyup_voltage;
+   struct adc_keys_button *map;
+};
+
+static void adc_keys_poll(struct input_polled_dev *dev)
+{
+   struct adc_keys_state *st = dev->private;
+   int i, value, ret;
+   u32 diff, closest = 0x;
+   int keycode = 0;
+
+   ret = iio_read_channel_processed(st->channel, );
+   if (ret < 0) {
+   if (st->last_key) {
+   input_report_key(dev->input, st->last_key, 0);
+   input_sync(dev->input);
+   st->last_key = 0;
+   }
+   return;
+   }
+
+   for (i = 0; i < st->num_keys; i++) {
+   diff = abs(st->map[i].voltage - value);
+   if (diff < closest) {
+   closest = diff;
+   keycode = st->map[i].keycode;
+   }
+   }
+
+   if (abs(st->keyup_voltage - value) < closest) {
+   input_report_key(dev->input, st->last_key, 0);
+   st->last_key = 0;
+   } else {
+   if (st->last_key && st->last_key != keycode)
+   input_report_key(dev->input, st->last_key, 0);
+   input_report_key(dev->input, keycode, 1);
+   st->last_key = keycode;
+   }
+
+   input_sync(dev->input);
+}
+
+static int adc_keys_load_dt_keymap(struct device *dev,
+  struct adc_keys_state *st)
+{
+   struct device_node *pp, *np = dev->of_node;
+   int i;
+
+   st->num_keys = of_get_child_count(np);
+   if (st->num_keys == 0) {
+   dev_err(dev, "keymap is missing\n");
+   return -EINVAL;
+   }
+
+   st->map = devm_kmalloc_array(dev, st->num_keys, sizeof(*st->map),
+GFP_KERNEL);
+   if (!st->map)
+   return -ENOMEM;
+
+   i = 0;
+   for_each_child_of_node(np, pp) {
+   struct adc_keys_button *map = >map[i];
+
+   if (of_property_read_u32(pp, "press-threshold-mvolt",
+>voltage)) {
+   dev_err(dev, "%s: Invalid or missing voltage\n",
+

[PATCH v2 1/2] input: adc-keys: add DT binding documentation

Add documentation for ADC keys

Signed-off-by: Alexandre Belloni 
---
Changes in v2:
 - fix title
 - use keyup-threshold-mvolt and press-threshold-mvolt instead of
   voltage-keyup-mvolt and voltage-mvolt.

 .../devicetree/bindings/input/adc-keys.txt | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt

diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt 
b/Documentation/devicetree/bindings/input/adc-keys.txt
new file mode 100644
index ..e43b8979b85a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/adc-keys.txt
@@ -0,0 +1,45 @@
+ADC attached resistor ladder buttons
+
+
+Required properties:
+ - compatible: "adc-keys"
+ - io-channels: Phandle to an ADC channel
+ - io-channel-names = "buttons";
+ - keyup-threshold-mvolt: Voltage at which all the keys are considered up.
+
+Each key is represented as a sub-node of "adc-keys":
+
+Required subnode-properties:
+   - label: Descriptive name of the key.
+   - linux,code: Keycode to emit.
+   - press-threshold-mvolt: Voltage adc input when this key is pressed.
+
+Example:
+
+#include 
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-mvolt = <2000>;
+
+   button@1500 {
+   label = "Volume Up";
+   linux,code = ;
+   press-threshold-mvolt = <1500>;
+   };
+
+   button@1000 {
+   label = "Volume Down";
+   linux,code = ;
+   press-threshold-mvolt = <1000>;
+   };
+
+   button@500 {
+   label = "Enter";
+   linux,code = ;
+   press-threshold-mvolt = <500>;
+   };
+   };
+
-- 
2.8.1

[PATCH v2 1/2] input: adc-keys: add DT binding documentation

Add documentation for ADC keys

Signed-off-by: Alexandre Belloni 
---
Changes in v2:
 - fix title
 - use keyup-threshold-mvolt and press-threshold-mvolt instead of
   voltage-keyup-mvolt and voltage-mvolt.

 .../devicetree/bindings/input/adc-keys.txt | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt

diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt 
b/Documentation/devicetree/bindings/input/adc-keys.txt
new file mode 100644
index ..e43b8979b85a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/adc-keys.txt
@@ -0,0 +1,45 @@
+ADC attached resistor ladder buttons
+
+
+Required properties:
+ - compatible: "adc-keys"
+ - io-channels: Phandle to an ADC channel
+ - io-channel-names = "buttons";
+ - keyup-threshold-mvolt: Voltage at which all the keys are considered up.
+
+Each key is represented as a sub-node of "adc-keys":
+
+Required subnode-properties:
+   - label: Descriptive name of the key.
+   - linux,code: Keycode to emit.
+   - press-threshold-mvolt: Voltage adc input when this key is pressed.
+
+Example:
+
+#include 
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = < 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-mvolt = <2000>;
+
+   button@1500 {
+   label = "Volume Up";
+   linux,code = ;
+   press-threshold-mvolt = <1500>;
+   };
+
+   button@1000 {
+   label = "Volume Down";
+   linux,code = ;
+   press-threshold-mvolt = <1000>;
+   };
+
+   button@500 {
+   label = "Enter";
+   linux,code = ;
+   press-threshold-mvolt = <500>;
+   };
+   };
+
-- 
2.8.1

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

On 07/08/2016 04:32 PM, Michael Turquette wrote:
> ---
>  drivers/clk/clk.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 820a939fb6bb..70efe4c4e0cc 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2449,8 +2449,14 @@ static int __clk_core_init(struct clk_core *core)
>   hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, child_node) {
>   struct clk_core *parent = __clk_init_parent(orphan);
>  
> - if (parent)
> - clk_core_reparent(orphan, parent);
> + /*
> +  * we could call __clk_set_parent, but that would result in a
> +  * reducant call to the .set_rate op, if it exists

Did you mean .set_parent op?

> +  */
> + if (parent) {
> + __clk_set_parent_before(orphan, parent);
> + __clk_set_parent_after(orphan, parent, NULL);
> + }
>   }
>  
>   /*


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

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

On 07/08/2016 04:32 PM, Michael Turquette wrote:
> ---
>  drivers/clk/clk.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 820a939fb6bb..70efe4c4e0cc 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2449,8 +2449,14 @@ static int __clk_core_init(struct clk_core *core)
>   hlist_for_each_entry_safe(orphan, tmp2, _orphan_list, child_node) {
>   struct clk_core *parent = __clk_init_parent(orphan);
>  
> - if (parent)
> - clk_core_reparent(orphan, parent);
> + /*
> +  * we could call __clk_set_parent, but that would result in a
> +  * reducant call to the .set_rate op, if it exists

Did you mean .set_parent op?

> +  */
> + if (parent) {
> + __clk_set_parent_before(orphan, parent);
> + __clk_set_parent_after(orphan, parent, NULL);
> + }
>   }
>  
>   /*


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

Re: [PATCH 1/2] tty: amba-pl011: add support for clock frequency setting via dt

On 07/08/2016 05:23 PM, Michael Turquette wrote:
> Quoting Jorge Ramirez (2016-07-08 14:39:50)
>> On 07/08/2016 07:14 PM, Michael Turquette wrote:
>>> Quoting Jorge Ramirez-Ortiz (2016-07-08 01:11:06)
 Allow to specify the clock frequency for any given port via the
 assigned-clock-rates device tree property.

 Signed-off-by: Jorge Ramirez-Ortiz 
 Tested-by: Jorge Ramirez-Ortiz 
 ---
   drivers/tty/serial/amba-pl011.c | 5 +
   1 file changed, 5 insertions(+)

 diff --git a/drivers/tty/serial/amba-pl011.c 
 b/drivers/tty/serial/amba-pl011.c
 index 1b7331e..51867ab 100644
 --- a/drivers/tty/serial/amba-pl011.c
 +++ b/drivers/tty/serial/amba-pl011.c
 @@ -55,6 +55,7 @@
   #include 
   #include 
   #include 
 +#include 
   #include 
   #include 
   #include 
 @@ -2472,6 +2473,10 @@ static int pl011_probe(struct amba_device *dev, 
 const struct amba_id *id)
  if (IS_ERR(uap->clk))
  return PTR_ERR(uap->clk);
   
 +   ret = of_clk_set_defaults(dev->dev.of_node, false);
>>> Change looks good to me, but with one question: should this change be
>>> put into more generic code instead of in this specific driver? For
>>> instance, we call of_clk_set_defaults from the following files:
>>>
>>> drivers/base/platform.c
>>> drivers/i2c/i2c-core.c
>>> drivers/spi/spi.c
>>>
>>> And Stephen posted a patch to do this for devices on the AMBA bus:
>>>
>>> https://patchwork.kernel.org/patch/6501691/
>>>
>>> Does Stephen's patch mean that you do not need patch #1?
>> I did a quick test (replaced my changes with the patch above) and the 
>> console broke and the BT stack couldn't communicate to the device over 
>> the uart...I guess something else needs doing on top of Stephen's change.
>>
> Let's give Stephen a chance to respond. If he doesn't soon then I'm OK
> to merge your two patches.
>


Yeah we need to restart that patch. It's been in my "pending" list for a
year now it seems.

Curious why it broke things, perhaps device probe is failing when it
didn't fail before?

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

Re: [PATCH 1/2] tty: amba-pl011: add support for clock frequency setting via dt