Re: [PATCH v4 4/9] ARM: dts: at91: sama5d2: add classd nodes

[Alexandre Belloni]

On 25/07/2017 at 09:37:05 +0200, Quentin Schulz wrote:
> From: Cyrille Pitchen 
> 
> This patch adds nodes for the classd device and its generated clock.
> 
> Signed-off-by: Cyrille Pitchen 
> Signed-off-by: Nicolas Ferre 
> Signed-off-by: Quentin Schulz 
> ---
>  arch/arm/boot/dts/sama5d2.dtsi | 39 ++-
>  1 file changed, 38 insertions(+), 1 deletion(-)
> 
Applied, thanks.

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

Re: [PATCH v2] drm/hisilicon: fix build error without fbdev emulation

[Arnd Bergmann]

On Wed, Jul 26, 2017 at 7:55 AM, Daniel Vetter  wrote:
> On Tue, Jul 25, 2017 at 8:05 PM, Arnd Bergmann  wrote:
>> We cannot reference priv->fbdev outside of the #ifdef:
>>
>> drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but 
>> not used [-Werror=unused-function]
>>  static int virtnet_restore_up(struct virtio_device *vdev)
>> drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but 
>> not used [-Werror=unused-function]
>>  static void virtnet_freeze_down(struct virtio_device *vdev)
>>
>> As the #ifdef is a bit annoying here, this removes it entirely
>> and uses an IS_ENABLED() check in it place where needed.
>>
>> Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup")
>> Signed-off-by: Arnd Bergmann 
>
> I guess I wasn't clear enough, but you don't even need the IS_ENABLED.
> The cma_fini/init functions themselves don't get no-opped out (I guess
> we could fix that), but the underlying fb helper functions they call
> do, so this is all perfectly fine to call unconditionally. And that's
> what all other drivers do. Should I edit while applying, or do you
> want to respin?

Please just edit as you like then, I think that's quicker.

The version I sent was meant to have smaller object code as well, and
I didn't think we could rely on drm_fb_cma_helper.c being built without
CONFIG_DRM_FBDEV_EMULATION, but I see now that they are
independent as you say, so making them unconditional indeed gives
the simplest code.

Thanks!

Arnd

Re: [PATCH v4 0/9] add support for Sama5d2 audio PLLs and enable ClassD

[Alexandre Belloni]

On 25/07/2017 at 17:44:19 +0200, Nicolas Ferre wrote:
> On 25/07/2017 at 09:37, Quentin Schulz wrote:
> > This patch series adds support for the audio PLLs and enables ClassD that
> > can be found in ATMEL Sama5d2 SoC.
> > 
> > There are two audio PLLs (PMC and PAD) that shares the same parent (FRAC).
> > FRAC can output between 620 and 700MHz and only multiply the rate of its
> > parent. The two audio PLLs then divide the FRAC rate to best match the
> > asked rate.
> > 
> > I basically took an old patch series posted by Nicolas on December, 6th
> > 2016[1][2][3] and the comments Boris did on the first version[4] Nicolas
> > sent on July, 15th 2015.
> > 
> > I also fixed the function used to compute the divisors, removed useless
> > spinlocks and added a range to the audio frac PLL to stay within vendor's
> > supported range. Clocks that are children of gclk (generated-clk) are now
> > able to propagate rate to the audio PLL clocks when needed.
> > 
> > However, there are multiple children clocks that could technically
> > change the rate of audio_pll (via gck). With the rate locking introduced
> > in Jerome Brunet's patch series[5], the first consumer to enable the clock
> > will be the one definitely setting the rate of the clock. Without the rate
> > locking, the last consumer to set the rate will be able to mess with the
> > rate.
> > Since audio IPs are most likely to request the same rate, we enforce
> > that the only clks able to modify gck rate are those of audio IPs.
> > 
> > To remain consistent, we deny other clocks to be children of audio_pll.
> 
> Quentin,
> 
> Thanks for having revived this series. Everything's okay on my side for
> this v4. I think that my tag isn't missing from any patch of this
> series. Now we surely need to define which path it must take...
> 

I'll take the two dts patches now as the bindings have been acked.
Everything else should probably go through the clk tree.


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

Re: [patches] [PATCH 17/17] RISC-V: Build Infastructure

[Arnd Bergmann]

On Wed, Jul 26, 2017 at 7:20 AM, Palmer Dabbelt  wrote:
> On Tue, 25 Jul 2017 19:57:17 PDT (-0700), j.neuschae...@gmx.net wrote:
>> On Tue, Jul 11, 2017 at 06:31:30PM -0700, Palmer Dabbelt wrote:
>>> This patch contains all the build infastructure that actually enables
>>> the RISC-V port.  This includes Makefiles, linker scripts, and Kconfig
>>> files.  It also contains the only top-level change, which adds RISC-V to
>>> the list of architectures that need a sed run to produce the ARCH
>>> variable when building locally.
>>>
>>> Signed-off-by: Palmer Dabbelt 
>>> ---
>> [...]
>>> +config ISA_C
>>> +bool "Emit compressed instructions when building Linux"
>>
>> As a user, I'd prefer to have slightly more globally-recognisable names
>> than ISA_ for RISC-V instruction set architecture
>> extensions. A quick "git grep -A2 'config ISA'" shows the following
>> Kconfig symbols:
>
> Good timing: I was about to submit a v6 patch set.  I'm cool with
> CONFIG_ISA_RVC and friends, do you mind submitting a patch?

I'd generally prefix those highly architecture specific ones with the
architecture name, e.g. CONFIG_RISCV_ISA_C

  Arnd

RE: [PATCH v8 1/1] f2fs: dax: implement direct access

[sunqiuyang]

Hi, 

Considering the current interfaces of F2FS and EXT4, my thought is that we can 
define a generic user-modifiable flag FS_DAX_FL, which can be included in the 
i_flags field of [f2fs | ext4]_inode_info. Thus, DAX can be enabled in either 
of the two ways below: 

1) mount the FS with a "dax" option, so that all files created will have the 
flag S_DAX set in the VFS inode, and the flag FS_DAX_FL set in [f2fs | 
ext4]_inode_info, by default.

2) mount the FS without "dax", and enable DAX per-inode from 
f2fs_ioctl_setflags() => f2fs_set_inode_flags()
 
Thanks,


From: Jaegeuk Kim [jaeg...@kernel.org]
Sent: Wednesday, July 26, 2017 10:16
To: Dan Williams
Cc: sunqiuyang; Linux Kernel Mailing List; linux-fsdevel; 
linux-f2fs-de...@lists.sourceforge.net; linux-nvd...@lists.01.org
Subject: Re: [PATCH v8 1/1] f2fs: dax: implement direct access

Hi Dan,

On 07/25, Dan Williams wrote:
> [ adding linux-nvdimm ]
>
> On Thu, Jul 20, 2017 at 5:10 AM, sunqiuyang  wrote:
> > From: Qiuyang Sun 
> >
> > This patch implements Direct Access (DAX) in F2FS, including:
> >  - a mount option to choose whether to enable DAX or not
>
> We're in the process of walking back and potentially deprecating the
> use of the dax mount option for xfs and ext4 since dax can have
> negative performance implications if page cache memory happens to be
> faster than pmem. It should be limited to applications that
> specifically want the semantic, not globally enabled for the entire
> mount. xfs has went ahead and added the XFS_DIFLAG2_DAX indoe flag for
> per-inode enabling of dax.

Thank you so much for pointing this out. So, is there a plan to define a
generic inode flag to enable dax via inode_set_flag? Or, does each filesystem
need to handle it individually likewise xfs?

>
> I'm wondering if any new filesystem that adds dax support at this
> point should do so with inode flags and not a mount option?

Anyway, in such the case, I have to postpone merging this patch for a while.

Thanks,

Re: [PATCH v2 00/10] Constify attribute_group structures

[Arvind Yadav]

Hi Kalle,


On Tuesday 25 July 2017 06:25 PM, Kalle Valo wrote:

Arvind Yadav  writes:


attribute_groups are not supposed to change at runtime. So mark the
non-const structs as const.

Arvind Yadav (10):
   [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures.
   [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures.
   [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures.
   [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures.
   [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures.
   [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures.
   [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures.
   [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures.
   [PATCH v2 09/10] net: bonding: constify attribute_group structures.
   [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures.

Via which tree were you planning to push these? Is it ok if I take the
wireless patches to my tree?

I have push these changes to linux-next branch. you can take this to 
your branch.


~arvind

Re: [PATCH v2 00/10] Constify attribute_group structures

[Arvind Yadav]

Hi Kalle,


On Tuesday 25 July 2017 06:25 PM, Kalle Valo wrote:

Arvind Yadav  writes:


attribute_groups are not supposed to change at runtime. So mark the
non-const structs as const.

Arvind Yadav (10):
   [PATCH v2 01/10] net: cdc_ncm: constify attribute_group structures.
   [PATCH v2 02/10] net: can: at91_can: constify attribute_group structures.
   [PATCH v2 03/10] net: can: janz-ican3: constify attribute_group structures.
   [PATCH v2 04/10] wireless: ipw2200: constify attribute_group structures.
   [PATCH v2 05/10] wireless: ipw2100: constify attribute_group structures.
   [PATCH v2 06/10] wireless: iwlegacy: constify attribute_group structures.
   [PATCH v2 07/10] wireless: iwlegacy: Constify attribute_group structures.
   [PATCH v2 08/10] arcnet: com20020-pci: constify attribute_group structures.
   [PATCH v2 09/10] net: bonding: constify attribute_group structures.
   [PATCH v2 10/10] net: chelsio: cxgb3: constify attribute_group structures.

Via which tree were you planning to push these? Is it ok if I take the
wireless patches to my tree?


I have push these changes to linux-branch. you can take this to your branch.

~arvind

[PATCH v2 0/4] Enable usb2 function on poplar board

[Jiancheng Xue]

This patchset is mainly used to enable the usb2 function on poplar board,
including usb2 phy drivers, dts nodes and configs.

Jiancheng Xue (3):
  dt-bindings: phy-hisi-inno-usb2: add support for hisi-inno-usb2 phy
  arm64: dts: hisilicon: add usb2 controller and phy nodes for poplar
board.
  arm64: defconfig: enable some drivers for hi3798cv200-poplar board.

Pengcheng Li (1):
  phy: add inno-usb2-phy driver for hi3798cv200 SoC

 .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt |  31 +++
 .../boot/dts/hisilicon/hi3798cv200-poplar.dts  |  13 ++
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi |  60 ++
 arch/arm64/configs/defconfig   |   4 +
 drivers/phy/hisilicon/Kconfig  |  11 +-
 drivers/phy/hisilicon/Makefile |   1 +
 drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 236 +
 7 files changed, 355 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
 create mode 100644 drivers/phy/hisilicon/phy-hisi-inno-usb2.c

-- 
1.9.1

[PATCH v2 3/4] arm64: dts: hisilicon: add usb2 controller and phy nodes for poplar board.

[Jiancheng Xue]

Add usb2 controller and phy nodes for poplar board.

Signed-off-by: Jiancheng Xue 
Reviewed-by: Daniel Thompson 
---
 .../boot/dts/hisilicon/hi3798cv200-poplar.dts  | 13 +
 arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 60 ++
 2 files changed, 73 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
index b914287..4656ba9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dts
@@ -63,6 +63,10 @@
};
 };
 
+&ehci {
+   status = "okay";
+};
+
 &gmac1 {
status = "okay";
#address-cells = <1>;
@@ -146,6 +150,10 @@
status = "okay";
 };
 
+&ohci {
+   status = "okay";
+};
+
 &spi0 {
status = "okay";
label = "LS-SPI0";
@@ -160,3 +168,8 @@
label = "LS-UART0";
 };
 /* No optional LS-UART1 on Low Speed Expansion Connector. */
+
+&usb2_phy1 {
+   status = "okay";
+};
+
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 75865f8a..250b68b 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -106,6 +106,11 @@
#reset-cells = <2>;
};
 
+   peri_ctrl: system-controller@8a2 {
+   compatible = "syscon";
+   reg = <0x8a2 0x1000>;
+   };
+
uart0: serial@8b0 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x8b0 0x1000>;
@@ -407,5 +412,60 @@
clocks = <&sysctrl HISTB_IR_CLK>;
status = "disabled";
};
+
+   ehci: ehci@0x989 {
+   compatible = "generic-ehci";
+   reg = <0x989 0x1>;
+   interrupts = ;
+   clocks = <&crg HISTB_USB2_BUS_CLK>,
+<&crg HISTB_USB2_PHY_CLK>,
+<&crg HISTB_USB2_UTMI_CLK>;
+   clock-names = "ehci_system", "phy", "utmi";
+   resets = <&crg 0xb8 12>,
+<&crg 0xb8 16>,
+<&crg 0xb8 13>;
+   reset-names = "bus", "phy", "utmi";
+   status = "disabled";
+   };
+
+   ohci: ohci@0x988 {
+   compatible = "generic-ohci";
+   reg = <0x988 0x1>;
+   interrupts = ;
+   clocks = <&crg HISTB_USB2_BUS_CLK>,
+<&crg HISTB_USB2_12M_CLK>,
+<&crg HISTB_USB2_48M_CLK>;
+   clock-names = "ahb_biu", "clk12", "clk48";
+   resets = <&crg 0xb8 12>;
+   reset-names = "bus";
+   status = "disabled";
+   };
+
+   usb2_phy1: usb-phy@1 {
+   compatible = "hisilicon,hi3798cv200-usb2-phy";
+   #phy-cells = <0>;
+   hisilicon,peripheral-syscon = <&peri_ctrl>;
+   hisilicon,phycon-reg = <0x120>;
+   hisilicon,port-num = <2>;
+   clocks = <&crg HISTB_USB2_PHY1_REF_CLK>;
+   resets = <&crg 0xbc 4>,
+<&crg 0xbc 8>,
+<&crg 0xbc 9>;
+   reset-names = "power_on", "utmi0", "utmi1";
+   status = "disabled";
+   };
+
+   usb2_phy2: usb-phy@2 {
+   compatible = "hisilicon,hi3798cv200-usb2-phy";
+   #phy-cells = <0>;
+   hisilicon,peripheral-syscon = <&peri_ctrl>;
+   hisilicon,phycon-reg = <0x124>;
+   hisilicon,port-num = <1>;
+   clocks = <&crg HISTB_USB2_PHY2_REF_CLK>;
+   resets = <&crg 0xbc 6>,
+<&crg 0xbc 10>;
+   reset-names = "power_on", "utmi0";
+   status = "disabled";
+   };
};
 };
-- 
1.9.1

[PATCH v2 4/4] arm64: defconfig: enable some drivers for hi3798cv200-poplar board.

[Jiancheng Xue]

Enable GMAC,I2C,USB2-PHY for hi3798cv200-poplar board.

Signed-off-by: Jiancheng Xue 
---
 arch/arm64/configs/defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6c7d147..93c709d7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -184,6 +184,7 @@ CONFIG_VIRTIO_NET=y
 CONFIG_AMD_XGBE=y
 CONFIG_NET_XGENE=y
 CONFIG_MACB=y
+CONFIG_HIX5HD2_GMAC=y
 CONFIG_HNS_DSAF=y
 CONFIG_HNS_ENET=y
 CONFIG_E1000E=y
@@ -267,6 +268,7 @@ CONFIG_I2C_TEGRA=y
 CONFIG_I2C_UNIPHIER_F=y
 CONFIG_I2C_RCAR=y
 CONFIG_I2C_CROS_EC_TUNNEL=y
+CONFIG_I2C_HIX5HD2=y
 CONFIG_SPI=y
 CONFIG_SPI_MESON_SPICC=m
 CONFIG_SPI_MESON_SPIFC=m
@@ -504,7 +506,9 @@ CONFIG_PWM_MESON=m
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_PWM_SAMSUNG=y
 CONFIG_PWM_TEGRA=m
+CONFIG_TI_SYSCON_RESET=y
 CONFIG_PHY_RCAR_GEN3_USB2=y
+CONFIG_PHY_HISI_INNO_USB2=y
 CONFIG_PHY_HI6220_USB=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_ROCKCHIP_INNO_USB2=y
-- 
1.9.1

[PATCH v2 2/4] phy: add inno-usb2-phy driver for hi3798cv200 SoC

[Jiancheng Xue]

From: Pengcheng Li 

Add inno-usb2-phy driver for hi3798cv200 SoC.

Signed-off-by: Pengcheng Li 
Signed-off-by: Jiancheng Xue 
---
 drivers/phy/hisilicon/Kconfig  |  11 +-
 drivers/phy/hisilicon/Makefile |   1 +
 drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 236 +
 3 files changed, 247 insertions(+), 1 deletion(-)
 create mode 100644 drivers/phy/hisilicon/phy-hisi-inno-usb2.c

diff --git a/drivers/phy/hisilicon/Kconfig b/drivers/phy/hisilicon/Kconfig
index 6164c4c..6a675c5 100644
--- a/drivers/phy/hisilicon/Kconfig
+++ b/drivers/phy/hisilicon/Kconfig
@@ -8,9 +8,18 @@ config PHY_HI6220_USB
select MFD_SYSCON
help
  Enable this to support the HISILICON HI6220 USB PHY.
-
  To compile this driver as a module, choose M here.
 
+config PHY_HISI_INNO_USB2
+   tristate "HiSilicon INNO USB2 PHY support"
+   depends on (ARCH_HISI) || COMPILE_TEST
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Support for INNO USB2 PHY on HiSilicon SoCs. This Phy supports
+ USB 1.5Mb/s, USB 12Mb/s, USB 480Mb/s speeds. It supports one
+ USB host port to accept one USB device.
+
 config PHY_HIX5HD2_SATA
tristate "HIX5HD2 SATA PHY Driver"
depends on ARCH_HIX5HD2 && OF && HAS_IOMEM
diff --git a/drivers/phy/hisilicon/Makefile b/drivers/phy/hisilicon/Makefile
index 541b348..e6c9794 100644
--- a/drivers/phy/hisilicon/Makefile
+++ b/drivers/phy/hisilicon/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_PHY_HI6220_USB)   += phy-hi6220-usb.o
+obj-$(CONFIG_PHY_HISI_INNO_USB2)   += phy-hisi-inno-usb2.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c 
b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
new file mode 100644
index 000..7edf4a3
--- /dev/null
+++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
@@ -0,0 +1,236 @@
+/*
+ * HiSilicon INNO USB2 PHY Driver.
+ *
+ * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INNO_PHY_PORT_NUM  2
+#define REF_CLK_STABLE_TIME100 /* unit:us */
+#define UTMI_CLK_STABLE_TIME   200 /* unit:us */
+#define TEST_CLK_STABLE_TIME   2   /* unit:ms */
+#define PHY_CLK_STABLE_TIME2   /* unit:ms */
+#define UTMI_RST_COMPLETE_TIME 2   /* unit:ms */
+#define TEST_RST_COMPLETE_TIME 100 /* unit:us */
+#define POR_RST_COMPLETE_TIME  300 /* unit:us */
+#define PHY_TEST_DATA  GENMASK(7, 0)
+#define PHY_TEST_ADDR  GENMASK(15, 8)
+#define PHY_TEST_PORT  GENMASK(18, 16)
+#define PHY_TEST_WREN  BIT(21)
+#define PHY_TEST_CLK   BIT(22) /* rising edge active */
+#define PHY_TEST_RST   BIT(23) /* low active */
+#define PHY_CLK_ENABLE BIT(2)
+
+struct hisi_inno_phy_priv {
+   struct regmap *syscon;
+   u32 reg;
+   struct clk *ref_clk;
+   struct reset_control *por_rst;
+   struct reset_control *test_rst;
+   struct reset_control *utmi_rst[INNO_PHY_PORT_NUM];
+   u32 port_num;
+};
+
+static void hisi_inno_phy_write_reg(struct regmap *syscon,
+   u32 reg, u8 port, u32 addr, u32 data)
+{
+   u32 value;
+
+   value = (data & PHY_TEST_DATA)
+   | ((addr << 8) & PHY_TEST_ADDR)
+   | ((port << 16) & PHY_TEST_PORT)
+   | PHY_TEST_WREN | PHY_TEST_RST;
+   regmap_write(syscon, reg, value);
+   value |= PHY_TEST_CLK;
+   regmap_write(syscon, reg, value);
+   value &= ~PHY_TEST_CLK;
+   regmap_write(syscon, reg, value);
+}
+
+static void hisi_inno_phy_setup(struct hisi_inno_phy_priv *priv)
+{
+   /* The phy clk is controlled by the port0 register 0x06. */
+   hisi_inno_phy_write_reg(priv->syscon,
+   priv->reg, 0, 0x06, PHY_CLK_ENABLE);
+   msleep(PHY_CLK_STABLE_TIME);
+}
+
+static int hisi_inno_phy_init(struct phy *phy)
+{
+   struct hisi_inno_phy_priv *priv = phy_get_drvdata(phy);
+   int ret, i;
+
+   ret = clk_prepare_enable(priv->ref_clk);
+   if (ret)
+   return ret;
+   udelay(REF_CLK_STABLE_TIME);
+
+   if (priv->test_rst) {
+   reset_control_deassert(priv->test_rst);
+   udelay(TEST_RST_COMPLETE_TIME);
+   }
+
+   

[PATCH v2 1/4] dt-bindings: phy-hisi-inno-usb2: add support for hisi-inno-usb2 phy

[Jiancheng Xue]

Add support for hisi-inno-usb2 phy.

Signed-off-by: Jiancheng Xue 
---
 .../devicetree/bindings/phy/phy-hisi-inno-usb2.txt | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt 
b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
new file mode 100644
index 000..417eeaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-hisi-inno-usb2.txt
@@ -0,0 +1,31 @@
+HiSilicon INNO USB2 PHY
+---
+Required properties:
+- compatible: Should be one of the following strings:
+   "hisilicon,inno-usb2-phy",
+   "hisilicon,hi3798cv200-usb2-phy",
+- #phy-cells: Shall be 0.
+- hisilicon,peripheral-syscon: Phandle of syscon used to control phy.
+- hisilicon,phycon-reg: Offset of the phy control register in the syscon.
+- hisilicon,port-num: Number of utmi ports. Range [1,2].
+- clocks: Phandle and clock specifier pair for reference clock utmi_refclk.
+- resets: List of phandle and reset specifier pairs for each reset signal
+in reset-names.
+- reset-names: Shall be "power_on", "utmi0", "utmi1". Thereinto, utmi[n] is
+required only if port[n] exists.
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+usb2_phy: phy {
+compatible = "hisilicon,inno-usb2-phy";
+#phy-cells = <0>;
+hisilicon,peripheral-syscon = <&peri_ctrl>;
+hisilicon,phycon-reg = <0x120>;
+hisilicon,port-num = <2>;
+clocks = <&crg USB2_PHY_UTMI_REF_CLK>;
+resets = <&crg 0xbc 2>,
+ <&crg 0xbc 8>,
+ <&crg 0xbc 9>,
+reset-names = "power_on", "utmi0", "utmi1";
+};
-- 
1.9.1

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

[Martin Schwidefsky]

On Wed, 26 Jul 2017 08:05:27 +0200
Heiko Carstens  wrote:

> On Wed, Jul 26, 2017 at 07:40:44AM +0200, Martin Schwidefsky wrote:
> > On Wed, 26 Jul 2017 07:00:33 +0200
> > Heiko Carstens  wrote:
> >   
> > > On Tue, Jul 25, 2017 at 06:14:51PM -0700, Guenter Roeck wrote:  
> > > > Hi Martin,
> > > > 
> > > > my s390 qemu tests in linux-next stopped working a few days ago.
> > > > Bisect points to commit 's390/spinlock: add niai spinlock hints'.
> > > > 
> > > > Looking at the patch, this isn't really surprising; at least to me it 
> > > > looks
> > > > like the patch is making instructions mandatory which are only 
> > > > available in
> > > > Z14 CPUs. Does this mean that older s390 CPUs (such as the Z900 used in 
> > > > my
> > > > qemu tests) are no longer going to be supported in Linux ?
> > > 
> > > No, that means that the patch has a bug. The NIAI instruction is only
> > > available if the execution-hint facility is installed. That facility came
> > > with zEC12. Luckily it uses the same facility indicator bit like the
> > > miscellaneous-instruction-extensions facility, which we already use anyway
> > > if the kernel gets compiled for zEC12. In that case we have early code
> > > which verifies if all required facilities to run the kernel are installed,
> > > and if not it will print a message to the console and stop the machine.
> > > 
> > > So the easiest fix would be to generate the NIAI instruction only if the
> > > kernel gets compiled for zEC12 or newer.  
> > 
> > Hmm, I though that NIAI is a NOP on older machines. A runtime check for
> > the facility bit is out of the question as the NIAI-7 gets inlined in
> > the spin_unlock code. So yes, the only available fix is to make the
> > NIAI hinting conditional on zEC12. Which is quite ugly as we would need
> > an architecture level set to zEC12 for the distribution kernel to make
> > use of NIAI.  
> 
> Alternatively you could generate a four-byte nop, and replace that at IPL
> time with the needed NIAI instruction, if the facility is available. Some
> sort of "alternative" code patching infrastructure that x86 already has.
> Not sure if it is worth it, however...

Patching all spin_unlock inlines? There are a lot of callers for this
function. We could think about an out-of-line spin_unlock and patch this
single function but then we'd loose the advantage of inlining.
I do not think it is worthwhile.

I pushed an updated patch to the features branch of s390/linux. Should
be in linux-next tomorroy. Thanks. 

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

Re: [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

[Viresh Kumar]

On 24-07-17, 15:47, Peter Zijlstra wrote:
> I said nothing about the shared locking. That is indeed required. All I
> said is that those two tests you add could be left out.

I was right, I didn't understood your comment at all :(

> > > That would then continue to process the iowait and other accounting
> > > stuff, but stall the moment we call into the actual driver, which will
> > > then drop the request on the floor as per the first few hunks.
> > 
> > I am not sure I understood your comment completely though.
> 
> Since we call cpufreq_update_util(@rq, ...) with @rq->lock held, all
> such calls are in fact serialized for that cpu.

Yes, they are serialized but ..

> Therefore the cpu !=
> current_cpu test you add are pointless.

.. I didn't understand why you said so. This check isn't there to take
care of serialization but remote callbacks.

> Only once we get to the actual cpufreq driver (intel_pstate and others)
> do we run into the fact that we might not be able to service the request
> remotely.

We never check for remote callbacks in drivers.

> But since you also add a test there, that is sufficient.

No.

The diff for intel-pstate that you saw in this patch was for the case
where intel-pstate works directly with the scheduler (i.e. no
schedutil governor). The routine that gets called with schedutil is
intel_cpufreq_target(), which doesn't check for remoteness at all.

-- 
viresh

[PATCH v6 4/7] drm/rockchip: vop: group vop registers

[Mark Yao]

Grouping the vop registers facilitates make register
definition clearer, and also is useful for different vop
reuse the same group register.

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  99 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  60 ---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 112 +++-
 3 files changed, 144 insertions(+), 127 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fd47da5..92d098b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -42,30 +42,19 @@
 #include "rockchip_drm_psr.h"
 #include "rockchip_drm_vop.h"
 
-#define REG_SET(x, base, reg, v) \
-   vop_mask_write(x, base + reg.offset, reg.mask, reg.shift, \
-  v, reg.write_mask, reg.relaxed)
-#define REG_SET_MASK(x, base, reg, mask, v) \
-   vop_mask_write(x, base + reg.offset, \
-  mask, reg.shift, v, reg.write_mask, reg.relaxed)
-
 #define VOP_WIN_SET(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->name, v)
+   vop_reg_set(vop, &win->phy->name, win->base, ~0, v, #name)
 #define VOP_SCL_SET(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->scl->name, v)
+   vop_reg_set(vop, &win->phy->scl->name, win->base, ~0, v, #name)
 #define VOP_SCL_SET_EXT(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->scl->ext->name, v)
-#define VOP_CTRL_SET(x, name, v) \
-   REG_SET(x, 0, (x)->data->ctrl->name, v)
-
-#define VOP_INTR_GET(vop, name) \
-   vop_read_reg(vop, 0, &vop->data->ctrl->name)
-
-#define VOP_INTR_SET(vop, name, v) \
-   REG_SET(vop, 0, vop->data->intr->name, v)
+   vop_reg_set(vop, &win->phy->scl->ext->name, \
+   win->base, ~0, v, #name)
 
 #define VOP_INTR_SET_MASK(vop, name, mask, v) \
-   REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v)
+   vop_reg_set(vop, &vop->data->intr->name, 0, mask, v, #name)
+
+#define VOP_REG_SET(vop, group, name, v) \
+   vop_reg_set(vop, &vop->data->group->name, 0, ~0, v, #name)
 
 #define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
@@ -82,7 +71,7 @@
vop_get_intr_type(vop, &vop->data->intr->name, type)
 
 #define VOP_WIN_GET(x, win, name) \
-   vop_read_reg(x, win->base, &win->phy->name)
+   vop_read_reg(x, win->offset, win->phy->name)
 
 #define VOP_WIN_GET_YRGBADDR(vop, win) \
vop_readl(vop, win->base + win->phy->yrgb_mst.offset)
@@ -164,14 +153,20 @@ static inline uint32_t vop_read_reg(struct vop *vop, 
uint32_t base,
return (vop_readl(vop, base + reg->offset) >> reg->shift) & reg->mask;
 }
 
-static inline void vop_mask_write(struct vop *vop, uint32_t offset,
- uint32_t mask, uint32_t shift, uint32_t v,
- bool write_mask, bool relaxed)
+static void vop_reg_set(struct vop *vop, const struct vop_reg *reg,
+   uint32_t _offset, uint32_t _mask, uint32_t v,
+   const char *reg_name)
 {
-   if (!mask)
+   int offset = reg->offset + _offset;
+   int mask = reg->mask & _mask;
+   int shift = reg->shift;
+
+   if (!reg || !reg->mask) {
+   dev_dbg(vop->dev, "Warning: not support %s\n", reg_name);
return;
+   }
 
-   if (write_mask) {
+   if (reg->write_mask) {
v = ((v << shift) & 0x) | (mask << (shift + 16));
} else {
uint32_t cached_val = vop->regsbak[offset >> 2];
@@ -180,7 +175,7 @@ static inline void vop_mask_write(struct vop *vop, uint32_t 
offset,
vop->regsbak[offset >> 2] = v;
}
 
-   if (relaxed)
+   if (reg->relaxed)
writel_relaxed(v, vop->regs + offset);
else
writel(v, vop->regs + offset);
@@ -202,7 +197,7 @@ static inline uint32_t vop_get_intr_type(struct vop *vop,
 
 static inline void vop_cfg_done(struct vop *vop)
 {
-   VOP_CTRL_SET(vop, cfg_done, 1);
+   VOP_REG_SET(vop, common, cfg_done, 1);
 }
 
 static bool has_rb_swapped(uint32_t format)
@@ -540,7 +535,7 @@ static int vop_enable(struct drm_crtc *crtc)
 
spin_lock(&vop->reg_lock);
 
-   VOP_CTRL_SET(vop, standby, 0);
+   VOP_REG_SET(vop, common, standby, 1);
 
spin_unlock(&vop->reg_lock);
 
@@ -600,7 +595,7 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
 
spin_lock(&vop->reg_lock);
 
-   VOP_CTRL_SET(vop, standby, 1);
+   VOP_REG_SET(vop, common, standby, 1);
 
spin_unlock(&vop->reg_lock);
 
@@ -923,7 +918,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
 
spin_lock(&vop->reg_lock);
 
-   VOP_CTRL_SET(v

[PATCH v6 5/7] drm/rockchip: vop: add a series of vop support

[Mark Yao]

Vop Full framework now has following vops:
IP versionchipname
  3.1   rk3288
  3.2   rk3368
  3.4   rk3366
  3.5   rk3399 big
  3.6   rk3399 lit
  3.7   rk3228
  3.8   rk3328

The above IP version is from H/W define, some of vop support get
the IP version from VERSION_INFO register, some are not.
hardcode the IP version for each vop to identify them.

major version: used for IP structure, Vop full framework is 3,
   vop little framework is 2.
minor version: on same structure, newer design vop will bigger
   then old one.

Signed-off-by: Mark Yao 
---
Changes in v3:
- fixup some mistake
- use separate structures instead VOP_REG_VER mechanism

Changes in v2:
- rename rk322x to rk3228(Heiko Stübner)
- correct some vop registers define

 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 218 ++-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 905 ++--
 3 files changed, 908 insertions(+), 224 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 3ba962c..43d08c8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -15,6 +15,14 @@
 #ifndef _ROCKCHIP_DRM_VOP_H
 #define _ROCKCHIP_DRM_VOP_H
 
+/*
+ * major: IP major version, used for IP structure
+ * minor: big feature change under same structure
+ */
+#define VOP_VERSION(major, minor)  ((major) << 8 | (minor))
+#define VOP_MAJOR(version) ((version) >> 8)
+#define VOP_MINOR(version) ((version) & 0xff)
+
 enum vop_data_format {
VOP_FMT_ARGB = 0,
VOP_FMT_RGB888,
@@ -142,6 +150,7 @@ struct vop_win_data {
 };
 
 struct vop_data {
+   uint32_t version;
const struct vop_intr *intr;
const struct vop_common *common;
const struct vop_misc *misc;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 20607a8..bc7b2d0 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -277,6 +277,7 @@
 };
 
 static const struct vop_data rk3288_vop = {
+   .version = VOP_VERSION(3, 1),
.feature = VOP_FEATURE_OUTPUT_RGB10,
.intr = &rk3288_vop_intr,
.common = &rk3288_common,
@@ -286,7 +287,7 @@
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
 };
 
-static const int rk3399_vop_intrs[] = {
+static const int rk3368_vop_intrs[] = {
FS_INTR,
0, 0,
LINE_FLAG_INTR,
@@ -296,22 +297,95 @@
DSP_HOLD_VALID_INTR,
 };
 
-static const struct vop_intr rk3399_vop_intr = {
-   .intrs = rk3399_vop_intrs,
-   .nintrs = ARRAY_SIZE(rk3399_vop_intrs),
-   .line_flag_num[0] = VOP_REG(RK3399_LINE_FLAG, 0x, 0),
-   .line_flag_num[1] = VOP_REG(RK3399_LINE_FLAG, 0x, 16),
-   .status = VOP_REG_MASK_SYNC(RK3399_INTR_STATUS0, 0x, 0),
-   .enable = VOP_REG_MASK_SYNC(RK3399_INTR_EN0, 0x, 0),
-   .clear = VOP_REG_MASK_SYNC(RK3399_INTR_CLEAR0, 0x, 0),
+static const struct vop_intr rk3368_vop_intr = {
+   .intrs = rk3368_vop_intrs,
+   .nintrs = ARRAY_SIZE(rk3368_vop_intrs),
+   .line_flag_num[0] = VOP_REG(RK3368_LINE_FLAG, 0x, 0),
+   .line_flag_num[1] = VOP_REG(RK3368_LINE_FLAG, 0x, 16),
+   .status = VOP_REG_MASK_SYNC(RK3368_INTR_STATUS, 0x3fff, 0),
+   .enable = VOP_REG_MASK_SYNC(RK3368_INTR_EN, 0x3fff, 0),
+   .clear = VOP_REG_MASK_SYNC(RK3368_INTR_CLEAR, 0x3fff, 0),
+};
+
+static const struct vop_win_phy rk3368_win23_data = {
+   .data_formats = formats_win_lite,
+   .nformats = ARRAY_SIZE(formats_win_lite),
+   .gate = VOP_REG(RK3368_WIN2_CTRL0, 0x1, 0),
+   .enable = VOP_REG(RK3368_WIN2_CTRL0, 0x1, 4),
+   .format = VOP_REG(RK3368_WIN2_CTRL0, 0x3, 5),
+   .rb_swap = VOP_REG(RK3368_WIN2_CTRL0, 0x1, 20),
+   .dsp_info = VOP_REG(RK3368_WIN2_DSP_INFO0, 0x0fff0fff, 0),
+   .dsp_st = VOP_REG(RK3368_WIN2_DSP_ST0, 0x1fff1fff, 0),
+   .yrgb_mst = VOP_REG(RK3368_WIN2_MST0, 0x, 0),
+   .yrgb_vir = VOP_REG(RK3368_WIN2_VIR0_1, 0x1fff, 0),
+   .src_alpha_ctl = VOP_REG(RK3368_WIN2_SRC_ALPHA_CTRL, 0xff, 0),
+   .dst_alpha_ctl = VOP_REG(RK3368_WIN2_DST_ALPHA_CTRL, 0xff, 0),
+};
+
+static const struct vop_win_data rk3368_vop_win_data[] = {
+   { .base = 0x00, .phy = &rk3288_win01_data,
+ .type = DRM_PLANE_TYPE_PRIMARY },
+   { .base = 0x40, .phy = &rk3288_win01_data,
+ .type = DRM_PLANE_TYPE_OVERLAY },
+   { .base = 0x00, .phy = &rk3368_win23_data,
+ .type = DRM_PLANE_TYPE_OVERLAY },
+   { .base = 0x50, .phy = &rk3368_win23_data,
+ .type = DRM_PLANE_TYPE_CURSOR },
+};
+
+static const struct vop_output rk3368_output = {
+   .rgb_pin_pol = VOP_REG(RK3368_DSP_CTRL1, 0xf, 16),
+   .hdmi_pin_pol = VOP_REG(RK3368_DSP_CTRL1,

[PATCH v6 7/7] drm/rockchip: vop: rk3328: fix overlay abnormal

[Mark Yao]

It's a hardware bug, all window's overlay channel reset
value is same, hardware overlay would be die.

so we must initial difference id for each overlay channel.

The Channel register is supported on all vop will full design.
Following is the details for this register
VOP_WIN0_CTRL2
  bit[7:4] win_rid_win0_cbr
   axi read id of win0 cbr channel
  bit[3:0] win_rid_win0_yrgb
   axi read id of win0 yrgb channel

Signed-off-by: Mark Yao 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
 3 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 92d098b..e4b3388 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1452,7 +1452,9 @@ static int vop_initial(struct vop *vop)
 
for (i = 0; i < vop_data->win_size; i++) {
const struct vop_win_data *win = &vop_data->win[i];
+   int channel = i * 2 + 1;
 
+   VOP_WIN_SET(vop, win, channel, (channel + 1) << 4 | channel);
VOP_WIN_SET(vop, win, enable, 0);
VOP_WIN_SET(vop, win, gate, 1);
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 43d08c8..af1091f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -141,6 +141,7 @@ struct vop_win_phy {
 
struct vop_reg dst_alpha_ctl;
struct vop_reg src_alpha_ctl;
+   struct vop_reg channel;
 };
 
 struct vop_win_data {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index bc7b2d0..94de7b9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -197,6 +197,7 @@
.uv_vir = VOP_REG(RK3288_WIN0_VIR, 0x3fff, 16),
.src_alpha_ctl = VOP_REG(RK3288_WIN0_SRC_ALPHA_CTRL, 0xff, 0),
.dst_alpha_ctl = VOP_REG(RK3288_WIN0_DST_ALPHA_CTRL, 0xff, 0),
+   .channel = VOP_REG(RK3288_WIN0_CTRL2, 0xff, 0),
 };
 
 static const struct vop_win_phy rk3288_win23_data = {
-- 
1.9.1

[PATCH v6 3/7] drm/rockchip: vop: move line_flag_num to interrupt registers

[Mark Yao]

In the hardware design process, the design of line flags
register is associated with the interrupt register,
placing the line flags in the interrupt definition is
more reasonable, and it would make multi-vop define easilier.

Signed-off-by: Mark Yao 
Reviewed-by: Sean Paul 
---
Changes in v6:
- fixes complie error

Changes in v3:
- Explain more in details, introduce why we need this patch

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 +++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  4 ++--
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  8 
 3 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index a792ea3..fd47da5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -61,8 +61,12 @@
 #define VOP_INTR_GET(vop, name) \
vop_read_reg(vop, 0, &vop->data->ctrl->name)
 
-#define VOP_INTR_SET(vop, name, mask, v) \
+#define VOP_INTR_SET(vop, name, v) \
+   REG_SET(vop, 0, vop->data->intr->name, v)
+
+#define VOP_INTR_SET_MASK(vop, name, mask, v) \
REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v)
+
 #define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
int i, reg = 0, mask = 0; \
@@ -72,7 +76,7 @@
mask |= 1 << i; \
} \
} \
-   VOP_INTR_SET(vop, name, mask, reg); \
+   VOP_INTR_SET_MASK(vop, name, mask, reg); \
} while (0)
 #define VOP_INTR_GET_TYPE(vop, name, type) \
vop_get_intr_type(vop, &vop->data->intr->name, type)
@@ -982,7 +986,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, vact_st_end, val);
VOP_CTRL_SET(vop, vpost_st_end, val);
 
-   VOP_CTRL_SET(vop, line_flag_num[0], vact_end);
+   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
 
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 056b974..850f8e4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -60,8 +60,6 @@ struct vop_ctrl {
struct vop_reg hpost_st_end;
struct vop_reg vpost_st_end;
 
-   struct vop_reg line_flag_num[2];
-
struct vop_reg global_regdone_en;
struct vop_reg cfg_done;
 };
@@ -69,6 +67,8 @@ struct vop_ctrl {
 struct vop_intr {
const int *intrs;
uint32_t nintrs;
+
+   struct vop_reg line_flag_num[2];
struct vop_reg enable;
struct vop_reg clear;
struct vop_reg status;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index d7974da..0a5f0d2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -116,6 +116,7 @@
 static const struct vop_intr rk3036_intr = {
.intrs = rk3036_vop_intrs,
.nintrs = ARRAY_SIZE(rk3036_vop_intrs),
+   .line_flag_num[0] = VOP_REG(RK3036_INT_STATUS, 0xfff, 12),
.status = VOP_REG(RK3036_INT_STATUS, 0xf, 0),
.enable = VOP_REG(RK3036_INT_STATUS, 0xf, 4),
.clear = VOP_REG(RK3036_INT_STATUS, 0xf, 8),
@@ -130,7 +131,6 @@
.hact_st_end = VOP_REG(RK3036_DSP_HACT_ST_END, 0x1fff1fff, 0),
.vtotal_pw = VOP_REG(RK3036_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
.vact_st_end = VOP_REG(RK3036_DSP_VACT_ST_END, 0x1fff1fff, 0),
-   .line_flag_num[0] = VOP_REG(RK3036_INT_STATUS, 0xfff, 12),
.cfg_done = VOP_REG_SYNC(RK3036_REG_CFG_DONE, 0x1, 0),
 };
 
@@ -226,7 +226,6 @@
.vact_st_end = VOP_REG(RK3288_DSP_VACT_ST_END, 0x1fff1fff, 0),
.hpost_st_end = VOP_REG(RK3288_POST_DSP_HACT_INFO, 0x1fff1fff, 0),
.vpost_st_end = VOP_REG(RK3288_POST_DSP_VACT_INFO, 0x1fff1fff, 0),
-   .line_flag_num[0] = VOP_REG(RK3288_INTR_CTRL0, 0x1fff, 12),
.global_regdone_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 11),
.cfg_done = VOP_REG_SYNC(RK3288_REG_CFG_DONE, 0x1, 0),
 };
@@ -258,6 +257,7 @@
 static const struct vop_intr rk3288_vop_intr = {
.intrs = rk3288_vop_intrs,
.nintrs = ARRAY_SIZE(rk3288_vop_intrs),
+   .line_flag_num[0] = VOP_REG(RK3288_INTR_CTRL0, 0x1fff, 12),
.status = VOP_REG(RK3288_INTR_CTRL0, 0xf, 0),
.enable = VOP_REG(RK3288_INTR_CTRL0, 0xf, 4),
.clear = VOP_REG(RK3288_INTR_CTRL0, 0xf, 8),
@@ -294,8 +294,6 @@
.vact_st_end = VOP_REG(RK3399_DSP_VACT_ST_END, 0x1fff1fff, 0),
.hpost_st_end = VOP_REG(RK3399_POST_DSP_HACT_INFO, 0x1fff1fff, 0),
.vpost_st_end = VOP_REG(RK3399_POST_DSP_VACT_INFO, 0x1fff1fff, 0),
-   .line_flag_num[0] = VOP_REG(RK3399_LINE_FLAG, 0x, 0),
-   .line_flag_num[1] = VOP_REG(RK3399_LINE_FLAG, 0x, 16),
.cfg_done = VOP_REG_MASK_SYNC(RK3399_REG_CFG_DONE, 0x1, 0),
 

[PATCH v6 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

[Mark Yao]

Since the drm atomic framework, only a small part of the vop
register needs sync write, Currently seems only following registers
need sync write:
   cfg_done, standby and interrupt related register.

All ctrl registers are using the sync write method that is
inefficient, hardcode the write_relaxed flags to vop registers,
then can only do synchronize write for those actual needed register.

Signed-off-by: Mark Yao 
---
Changes in v6:
- fix compile error

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 28 ---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 -
 3 files changed, 36 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 81164d6..a792ea3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -42,33 +42,27 @@
 #include "rockchip_drm_psr.h"
 #include "rockchip_drm_vop.h"
 
-#define __REG_SET_RELAXED(x, off, mask, shift, v, write_mask) \
-   vop_mask_write(x, off, mask, shift, v, write_mask, true)
-
-#define __REG_SET_NORMAL(x, off, mask, shift, v, write_mask) \
-   vop_mask_write(x, off, mask, shift, v, write_mask, false)
-
-#define REG_SET(x, base, reg, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, \
-reg.mask, reg.shift, v, reg.write_mask)
-#define REG_SET_MASK(x, base, reg, mask, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, \
-mask, reg.shift, v, reg.write_mask)
+#define REG_SET(x, base, reg, v) \
+   vop_mask_write(x, base + reg.offset, reg.mask, reg.shift, \
+  v, reg.write_mask, reg.relaxed)
+#define REG_SET_MASK(x, base, reg, mask, v) \
+   vop_mask_write(x, base + reg.offset, \
+  mask, reg.shift, v, reg.write_mask, reg.relaxed)
 
 #define VOP_WIN_SET(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->name, v, RELAXED)
+   REG_SET(x, win->base, win->phy->name, v)
 #define VOP_SCL_SET(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->scl->name, v, RELAXED)
+   REG_SET(x, win->base, win->phy->scl->name, v)
 #define VOP_SCL_SET_EXT(x, win, name, v) \
-   REG_SET(x, win->base, win->phy->scl->ext->name, v, RELAXED)
+   REG_SET(x, win->base, win->phy->scl->ext->name, v)
 #define VOP_CTRL_SET(x, name, v) \
-   REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)
+   REG_SET(x, 0, (x)->data->ctrl->name, v)
 
 #define VOP_INTR_GET(vop, name) \
vop_read_reg(vop, 0, &vop->data->ctrl->name)
 
 #define VOP_INTR_SET(vop, name, mask, v) \
-   REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v, NORMAL)
+   REG_SET_MASK(vop, 0, vop->data->intr->name, mask, v)
 #define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
int i, reg = 0, mask = 0; \
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 084d3b2..056b974 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -29,6 +29,7 @@ struct vop_reg {
uint32_t shift;
uint32_t mask;
bool write_mask;
+   bool relaxed;
 };
 
 struct vop_ctrl {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 58da855..d7974da 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -20,17 +20,23 @@
 #include "rockchip_drm_vop.h"
 #include "rockchip_vop_reg.h"
 
-#define VOP_REG(off, _mask, s) \
-   {.offset = off, \
+#define _VOP_REG(off, _mask, _shift, _write_mask, _relaxed) \
+   { \
+.offset = off, \
 .mask = _mask, \
-.shift = s, \
-.write_mask = false,}
+.shift = _shift, \
+.write_mask = _write_mask, \
+.relaxed = _relaxed, \
+   }
 
-#define VOP_REG_MASK(off, _mask, s) \
-   {.offset = off, \
-.mask = _mask, \
-.shift = s, \
-.write_mask = true,}
+#define VOP_REG(off, _mask, _shift) \
+   _VOP_REG(off, _mask, _shift, false, true)
+
+#define VOP_REG_SYNC(off, _mask, _shift) \
+   _VOP_REG(off, _mask, _shift, false, false)
+
+#define VOP_REG_MASK_SYNC(off, _mask, _shift) \
+   _VOP_REG(off, _mask, _shift, true, false)
 
 static const uint32_t formats_win_full[] = {
DRM_FORMAT_XRGB,
@@ -116,7 +122,7 @@
 };
 
 static const struct vop_ctrl rk3036_ctrl_data = {
-   .standby = VOP_REG(RK3036_SYS_CTRL, 0x1, 30),
+   .standby = VOP_REG_SYNC(RK3036_SYS_CTRL, 0x1, 30),
.o

[PATCH v6 1/7] drm/rockchip: vop: initialize registers directly

[Mark Yao]

At present we are using init_table to initialize some
registers, but the Register init table use un-document define,
it is unreadable, and sometimes we only want to update tiny
bits, init table method is not friendly, it's diffcult to
reuse for difference chips.

To make it clean, initialize registers directly, and drops
init_table mechanism out.

Signed-off-by: Mark Yao 
---
Changes in v6:
- fix rk3036 blank display

Changes in v3:
- Explain more in details

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  6 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 10 ++-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 44 -
 3 files changed, 11 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d45033..81164d6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1395,7 +1395,6 @@ static void vop_destroy_crtc(struct vop *vop)
 static int vop_initial(struct vop *vop)
 {
const struct vop_data *vop_data = vop->data;
-   const struct vop_reg_data *init_table = vop_data->init_table;
struct reset_control *ahb_rst;
int i, ret;
 
@@ -1455,13 +1454,14 @@ static int vop_initial(struct vop *vop)
 
memcpy(vop->regsbak, vop->regs, vop->len);
 
-   for (i = 0; i < vop_data->table_size; i++)
-   vop_writel(vop, init_table[i].offset, init_table[i].value);
+   VOP_CTRL_SET(vop, global_regdone_en, 1);
+   VOP_CTRL_SET(vop, dsp_blank, 0);
 
for (i = 0; i < vop_data->win_size; i++) {
const struct vop_win_data *win = &vop_data->win[i];
 
VOP_WIN_SET(vop, win, enable, 0);
+   VOP_WIN_SET(vop, win, gate, 1);
}
 
vop_cfg_done(vop);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 9979fd0..084d3b2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -24,11 +24,6 @@ enum vop_data_format {
VOP_FMT_YUV444SP,
 };
 
-struct vop_reg_data {
-   uint32_t offset;
-   uint32_t value;
-};
-
 struct vop_reg {
uint32_t offset;
uint32_t shift;
@@ -46,6 +41,7 @@ struct vop_ctrl {
struct vop_reg hdmi_en;
struct vop_reg mipi_en;
struct vop_reg dp_en;
+   struct vop_reg dsp_blank;
struct vop_reg out_mode;
struct vop_reg dither_down;
struct vop_reg dither_up;
@@ -65,6 +61,7 @@ struct vop_ctrl {
 
struct vop_reg line_flag_num[2];
 
+   struct vop_reg global_regdone_en;
struct vop_reg cfg_done;
 };
 
@@ -115,6 +112,7 @@ struct vop_win_phy {
uint32_t nformats;
 
struct vop_reg enable;
+   struct vop_reg gate;
struct vop_reg format;
struct vop_reg rb_swap;
struct vop_reg act_info;
@@ -136,8 +134,6 @@ struct vop_win_data {
 };
 
 struct vop_data {
-   const struct vop_reg_data *init_table;
-   unsigned int table_size;
const struct vop_ctrl *ctrl;
const struct vop_intr *intr;
const struct vop_win_data *win;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index bafd698..58da855 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -119,6 +119,7 @@
.standby = VOP_REG(RK3036_SYS_CTRL, 0x1, 30),
.out_mode = VOP_REG(RK3036_DSP_CTRL0, 0xf, 0),
.pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+   .dsp_blank = VOP_REG(RK3036_DSP_CTRL1, 0x1, 24),
.htotal_pw = VOP_REG(RK3036_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
.hact_st_end = VOP_REG(RK3036_DSP_HACT_ST_END, 0x1fff1fff, 0),
.vtotal_pw = VOP_REG(RK3036_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
@@ -127,13 +128,7 @@
.cfg_done = VOP_REG(RK3036_REG_CFG_DONE, 0x1, 0),
 };
 
-static const struct vop_reg_data rk3036_vop_init_reg_table[] = {
-   {RK3036_DSP_CTRL1, 0x},
-};
-
 static const struct vop_data rk3036_vop = {
-   .init_table = rk3036_vop_init_reg_table,
-   .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
.ctrl = &rk3036_ctrl_data,
.intr = &rk3036_intr,
.win = rk3036_vop_win_data,
@@ -193,7 +188,8 @@
 static const struct vop_win_phy rk3288_win23_data = {
.data_formats = formats_win_lite,
.nformats = ARRAY_SIZE(formats_win_lite),
-   .enable = VOP_REG(RK3288_WIN2_CTRL0, 0x1, 0),
+   .enable = VOP_REG(RK3288_WIN2_CTRL0, 0x1, 4),
+   .gate = VOP_REG(RK3288_WIN2_CTRL0, 0x1, 0),
.format = VOP_REG(RK3288_WIN2_CTRL0, 0x7, 1),
.rb_swap = VOP_REG(RK3288_WIN2_CTRL0, 0x1, 12),
.dsp_info = VOP_REG(RK3288_WIN2_DSP_INFO0, 0x0fff0fff, 0),
@@ -215,6 +211,7 @@
.dither_down = VOP_REG(RK3288_DSP_CTRL1, 0xf, 1),
.dither_up = VOP_REG(RK3288_DSP_CTRL1, 0x1, 6),
.data_bl

[PATCH v6 0/7] drm/rockchip: add all full framework vop support

[Mark Yao]

These patches try to make all current rockchip full framework vop works
on drm, fill missing vop on full framework.
Vop Full framework now has following vops:
IP versionchipname
  3.1   rk3288
  3.2   rk3368
  3.4   rk3366
  3.5   rk3399 big
  3.6   rk3399 lit
  3.7   rk3228
  3.8   rk3328

Group the vop register, it would make register  definition clearer and
more easily to reuse same group register define for difference vops.

Tested on rk3399 excavator board with kernel 4.13-rc1.

And other chips tested on rockchip kernel 4.4:
   
https://github.com/rockchip-linux/kernel/tree/release-4.4/drivers/gpu/drm/rockchip

Changes in v6:
- fix some patches complie error
- fix rk3036 display blank

Changes in v5:
- clean document commit title
- move changes description out of docummit commit msg

Changes in v4:
- rebase to newest torvalds kernel, fix merge conflict 

Changes in v3:
- group vop register instead using VOP_REG_VER mechanism
- Explain more on patch commit message
- move write_relaxed flags to vop registers
- fix rk3328 overlay abnormal

Changes in v2:
- rename rk322x to rk3228
- correct some vop registers define

Mark Yao (7):
  drm/rockchip: vop: initialize registers directly
  drm/rockchip: vop: move write_relaxed flags to vop register
  drm/rockchip: vop: move line_flag_num to interrupt registers
  drm/rockchip: vop: group vop registers
  drm/rockchip: vop: add a series of vop support
  dt-bindings: display: rockchip: fill Documents for vop series
  drm/rockchip: vop: rk3328: fix overlay abnormal

 .../bindings/display/rockchip/rockchip-vop.txt |   4 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 109 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  81 +-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 375 ++---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 905 -
 5 files changed, 1075 insertions(+), 399 deletions(-)

-- 
1.9.1

[lkp-robot] [lib] e859afe1ee: kernel_BUG_at_lib/test_rhashtable.c

[kernel test robot]

FYI, we noticed the following commit:

commit: e859afe1ee0c5ae981c55387ccd45eba258a7842 ("lib: test_rhashtable: fix 
for large entry counts")
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git master

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|  | 1d9b86de37 | e859afe1ee |
+--+++
| boot_successes   | 6  | 0  |
| boot_failures| 2  | 6  |
| BUG:kernel_hang_in_test_stage| 2  ||
| kernel_BUG_at_lib/test_rhashtable.c  | 0  | 6  |
| invalid_opcode:#[##] | 0  | 6  |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 6  |
+--+++



[3.687816] kernel BUG at lib/test_rhashtable.c:230!
[3.687816] kernel BUG at lib/test_rhashtable.c:230!
[3.690340] invalid opcode:  [#1]
[3.690340] invalid opcode:  [#1]
[3.691685] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.13.0-rc1-00196-ge859afe #1
[3.691685] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.13.0-rc1-00196-ge859afe #1
[3.693655] task: 880018c3e040 task.stack: 880018c48000
[3.693655] task: 880018c3e040 task.stack: 880018c48000
[3.693655] RIP: 0010:test_rhashtable+0x7e0/0x10d7
[3.693655] RIP: 0010:test_rhashtable+0x7e0/0x10d7
[3.693655] RSP: :880018c4bdb8 EFLAGS: 00010202
[3.693655] RSP: :880018c4bdb8 EFLAGS: 00010202
[3.693655] RAX: 0206 RBX: 330af60b9f217ec1 RCX: 06a6
[3.693655] RAX: 0206 RBX: 330af60b9f217ec1 RCX: 06a6
[3.693655] RDX: 0001 RSI: 0001 RDI: 0206
[3.693655] RDX: 0001 RSI: 0001 RDI: 0206
[3.693655] RBP: 880018c4be40 R08: c5b6f33d R09: 
[3.693655] RBP: 880018c4be40 R08: c5b6f33d R09: 
[3.693655] R10: 92872260 R11:  R12: 3001a345
[3.693655] R10: 92872260 R11:  R12: 3001a345
[3.693655] R13:  R14: d1a2 R15: 
[3.693655] R13:  R14: d1a2 R15: 
[3.693655] FS:  () GS:92645000() 
knlGS:
[3.693655] FS:  () GS:92645000() 
knlGS:
[3.693655] CS:  0010 DS:  ES:  CR0: 80050033
[3.693655] CS:  0010 DS:  ES:  CR0: 80050033
[3.693655] CR2:  CR3: 07e17000 CR4: 06f0
[3.693655] CR2:  CR3: 07e17000 CR4: 06f0
[3.693655] Call Trace:
[3.693655] Call Trace:
[3.693655]  test_rht_init+0x16f/0x746
[3.693655]  test_rht_init+0x16f/0x746
[3.693655]  ? test_rhashtable+0x10d7/0x10d7
[3.693655]  ? test_rhashtable+0x10d7/0x10d7
[3.693655]  do_one_initcall+0x111/0x2cf
[3.693655]  do_one_initcall+0x111/0x2cf
[3.693655]  kernel_init_freeable+0x248/0x3c2
[3.693655]  kernel_init_freeable+0x248/0x3c2
[3.693655]  ? rest_init+0x1d6/0x1d6
[3.693655]  ? rest_init+0x1d6/0x1d6
[3.693655]  kernel_init+0x10/0x18d
[3.693655]  kernel_init+0x10/0x18d
[3.693655]  ret_from_fork+0x2a/0x40
[3.693655]  ret_from_fork+0x2a/0x40
[3.693655] Code: 48 c7 c7 60 22 87 92 ff 0d 2c db 66 ff 48 ff 05 cd c1 11 
01 48 c1 cb 07 e8 18 2f 93 fd 48 83 7d b8 00 75 10 48 ff 05 be c1 11 01 <0f> 0b 
48 ff 05 c5 c1 11 01 48 b8 81 f1 ab cd fa 08 0e 67 48 ff 
[3.693655] Code: 48 c7 c7 60 22 87 92 ff 0d 2c db 66 ff 48 ff 05 cd c1 11 
01 48 c1 cb 07 e8 18 2f 93 fd 48 83 7d b8 00 75 10 48 ff 05 be c1 11 01 <0f> 0b 
48 ff 05 c5 c1 11 01 48 b8 81 f1 ab cd fa 08 0e 67 48 ff 
[3.693655] RIP: test_rhashtable+0x7e0/0x10d7 RSP: 880018c4bdb8
[3.693655] RIP: test_rhashtable+0x7e0/0x10d7 RSP: 880018c4bdb8
[3.741828] ---[ end trace d459aa683f867d44 ]---


To reproduce:

git clone https://github.com/01org/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.13.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMP

[PATCH v6 6/7] dt-bindings: display: rockchip: fill Documents for vop series

[Mark Yao]

Signed-off-by: Mark Yao 
Acked-by: Rob Herring 
---
Changes in v5:
- clean document commit title
- move changes description out of docummit commit msg

Changes in v2:
- rename rk322x to rk3228
- correct some vop registers define

 Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index 9eb3f0a..5d835d9 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -8,8 +8,12 @@ Required properties:
 - compatible: value should be one of the following
"rockchip,rk3036-vop";
"rockchip,rk3288-vop";
+   "rockchip,rk3368-vop";
+   "rockchip,rk3366-vop";
"rockchip,rk3399-vop-big";
"rockchip,rk3399-vop-lit";
+   "rockchip,rk3228-vop";
+   "rockchip,rk3328-vop";
 
 - interrupts: should contain a list of all VOP IP block interrupts in the
 order: VSYNC, LCD_SYSTEM. The interrupt specifier
-- 
1.9.1

Re: [PATCH v5 3/7] drm/rockchip: vop: move line_flag_num to interrupt registers

[Mark yao]

On 2017年07月26日 05:54, Heiko Stuebner wrote:

Hi Mark,

Am Donnerstag, 20. Juli 2017, 10:43:32 CEST schrieb Mark Yao:

In the hardware design process, the design of line flags
register is associated with the interrupt register,
placing the line flags in the interrupt definition is
more reasonable, and it would make multi-vop define easilier.

Changes in v3:
- Explain more in details, introduce why we need this patch

Signed-off-by: Mark Yao 
Reviewed-by: Sean Paul 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 ++--
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 
  3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 784a2b7..4f6c7bc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -982,7 +982,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, vact_st_end, val);
VOP_CTRL_SET(vop, vpost_st_end, val);
  
-	VOP_CTRL_SET(vop, line_flag_num[0], vact_end);

+   VOP_INTR_SET(vop, line_flag_num[0], vact_end);

With patches applied up to this one I end up with

   CC [M]  drivers/gpu/drm/rockchip/rockchip_drm_vop.o
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function ‘vop_crtc_enable’:
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:46: error: macro 
"VOP_INTR_SET" requires 4 arguments, but only 3 given
   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
   ^
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:2: error: ‘VOP_INTR_SET’ 
undeclared (first use in this function)
   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
   ^~~~
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:985:2: note: each undeclared 
identifier is reported only once for each function it appears in

In patch4 you replace this again, with
-   VOP_INTR_SET(vop, line_flag_num[0], vact_end);
+   VOP_REG_SET(vop, intr, line_flag_num[0], vact_end);

but this intermediate breakage should not happen, to keep bisectability.


Heiko




Hi Heiko

Thanks for the test, will fix it at next version.

--
Ｍark Yao

Re: [PATCH v5 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

[Mark yao]

On 2017年07月26日 05:47, Heiko Stuebner wrote:

Hi Mark,

Am Donnerstag, 20. Juli 2017, 10:43:27 CEST schrieb Mark Yao:

Since the drm atomic framework, only a small part of the vop
register needs sync write, Currently seems only following registers
need sync write:
cfg_done, standby and interrupt related register.

All ctrl registers are using the sync write method that is
inefficient, hardcode the write_relaxed flags to vop registers,
then can only do synchronize write for those actual needed register.

Signed-off-by: Mark Yao 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 +++---
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 42 -
  2 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 81164d6..784a2b7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -42,18 +42,12 @@
  #include "rockchip_drm_psr.h"
  #include "rockchip_drm_vop.h"
  
-#define __REG_SET_RELAXED(x, off, mask, shift, v, write_mask) \

-   vop_mask_write(x, off, mask, shift, v, write_mask, true)
-
-#define __REG_SET_NORMAL(x, off, mask, shift, v, write_mask) \
-   vop_mask_write(x, off, mask, shift, v, write_mask, false)
-
  #define REG_SET(x, base, reg, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, \
-reg.mask, reg.shift, v, reg.write_mask)
+   vop_mask_write(x, base + reg.offset, reg.mask, reg.shift, \
+  v, reg.write_mask, reg.relaxed)
  #define REG_SET_MASK(x, base, reg, mask, v, mode) \
-   __REG_SET_##mode(x, base + reg.offset, \
-mask, reg.shift, v, reg.write_mask)
+   vop_mask_write(x, base + reg.offset, \
+  mask, reg.shift, v, reg.write_mask, reg.relaxed)

you only introduce the relaxed element of struct vop_reg in patch4.
So using it here produces a compile error

../drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function ‘vop_cfg_done’:
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:47:33: error: ‘const struct 
vop_reg’ has no member named ‘relaxed’
v, reg.write_mask, reg.relaxed)
  ^
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:59:3: note: in expansion of 
macro ‘REG_SET’
REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)
^~~
../drivers/gpu/drm/rockchip/rockchip_drm_vop.c:201:2: note: in expansion of 
macro ‘VOP_CTRL_SET’
   VOP_CTRL_SET(vop, cfg_done, 1);
   ^~~~

when only patches 1+2 are applied. So the relaxed field addition should
definitly move into this patch to not break bisectability.


Heiko





Hi Heiko

Thanks for the test, will fix it at next version.

--
Ｍark Yao

Re: [PATCH] ACPI, APEI: Fixup incorrect 16-bit access width firmware bug

[Liwei Song]

On 07/21/2017 05:56 PM, Andy Shevchenko wrote:
> On Fri, Jul 21, 2017 at 12:41 PM, Song liwei  wrote:
> 
>> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0xb2/16/0/1/1]
>>
>> This is due to an 8-bit access width is specified for a 16-bit register,
>> Do bit_width check just like what the original commit have done.
> 
>> else if (bit_width == 64 && bit_offset == 0 && (*paddr & 0x07) == 0 
>> &&
>> *access_bit_width < 64)
>> *access_bit_width = 64;
>> +   else if (bit_width == 16 && bit_offset == 0 && (*paddr & 0x01) == 0 
>> &&
>> +   *access_bit_width < 16)
>> +   *access_bit_width = 16;
> 
> Wouldn't be better to rearrange that it will go in a sequence
> (16,32,64 or 64,32,16) ?
> 
> or move bit_offset == 0 into external condion
> 
> /* Fixup common BIOS bug */
> if (bit_offset == 0) {
>   if (bit_width == 16 && (*paddr & 0x01) == 0 && *access_bit_width < 16)
>*access_bit_width = 16;
>   else if (bit_width == 32 && (*paddr & 0x03) == 0 &&
> *access_bit_width < 32)
>*access_bit_width = 32;
>   else if (bit_width == 64 && (*paddr & 0x07) == 0 &&
> *access_bit_width < 64)
>*access_bit_width = 64;
> }
> 
> 
> It might be (I'm not sure it will make it better, just a side note)
> considered to convert each internal conditional to
> 
> ...if (bit_width == XX && (*paddr & YY) == 0)
>*access_bit_width = max(*access_bit_width, bit_width);

Hi Andy,

Thanks for your suggestion, what about the condition like the following?
The main bug in bios is bit_width is not comfortable with access_bit_width
So check it first.

if (*access_bit_width < bit_width && bit_offset == 0) {
if ((bit_width == 16 && (*paddr & 0x01) == 0) ||
(bit_width == 32 && (*paddr & 0x03) == 0) ||
(bit_width == 64 && (*paddr & 0x07) == 0))
*access_bit_width = bit_width;
}


Thanks,
Liwei.


> 

linux-next: Tree for Jul 26

[Stephen Rothwell]

Hi all,

Changes since 20170725:

Non-merge commits (relative to Linus' tree): 2358
 2466 files changed, 86994 insertions(+), 44655 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 267 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (25f6a53799d6 Merge tag 'jfs-4.13' of 
git://github.com/kleikamp/linux-shaggy)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (ce184a0dee92 ARM: 8687/1: signal: Fix unparseable 
iwmmxt_sigframe in uc_regspace[])
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (029d9252b116 powerpc/mm: Mark __init memory 
no-execute when STRICT_KERNEL_RWX=y)
Merging sparc/master (8cd3ec51c0c3 sbus: Convert to using %pOF instead of 
full_name)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (783692558a60 lib: test_rhashtable: Fix KASAN warning)
Merging ipsec/master (e6194923237f esp: Fix memleaks on error paths.)
Merging netfilter/master (f7fb77fc1235 netfilter: nft_compat: check extension 
hook mask only if set)
Merging ipvs/master (3c5ab3f395d6 ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d755cbc26e82 Merge tag 
'iwlwifi-for-kalle-2017-07-21' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (ba92b1142879 ALSA: hda - Add mute led support 
for HP ProBook 440 G4)
Merging pci-current/for-linus (34d5ac2af644 PCI: rockchip: Check for 
pci_scan_root_bus_bridge() failure correctly)
Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1)
Merging tty.current/tty-linus (520eccdfe187 Linux 4.13-rc2)
Merging usb.current/usb-linus (520eccdfe187 Linux 4.13-rc2)
Merging usb-gadget-fixes/fixes (520eccdfe187 Linux 4.13-rc2)
Merging usb-serial-fixes/usb-linus (9585e340db9f USB: serial: cp210x: add 
support for Qivicon USB ZigBee dongle)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (055655a9f0fe Merge tag 
'iio-fixes-for-4.13a' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (520eccdfe187 Linux 4.13-rc2)
Merging input-current/for-linus (293b915fd9be Input: trackpoint - assume 3 
buttons when buttons detection fails)
Merging crypto-current/master (41cdf7a45389 crypto: authencesn - Fix 
digest_null crash)
Merging ide/master (921edf312a6a ide: avoid warning for timings calculation)
Merging vfio-fixes/for-linus (39da7c509acf Linux 4.11-rc6)
Merging kselftest-fixes/fixes (5771a8c08880 Linux v4.

linux-next: unsigned commits in the drm-misc tree

[Stephen Rothwell]

Hi all,

I noticed a set of commits that have no Signed-off-by from their
committer:

  d9864a1d2dfc ("drm/stm: drv: Rename platform driver name")

to

  ed34d261a12a ("drm/stm: dsi: Constify phy ops structure")

-- 
Cheers,
Stephen Rothwell

Re: [PATCH V3 3/9] cpufreq: Cap the default transition delay value to 10 ms

[Viresh Kumar]

On 25-07-17, 14:54, Leonard Crestez wrote:

Thanks for reporting Leonard, really appreciate it.

> This patch made it's way into linux-next and it seems to cause imx socs
> to almost always hang around their max frequency with the ondemand
> governor, even when almost completely idle. The lowest frequency is
> never reached. This seems wrong?

Sure thing. Though I tried to reproduce it on Hikey today and it all
worked pretty fine with ondemand governor. The latency is around 500
us here. I don't have a clue right now on what's wrong in your setup.

> This driver calculates transition_latency at probe time, the value is
> not terribly accurate but it reaches values like latency = 109 us, so

So this is the value that is stored in the global variable
"transition_latency" in the imx6q-cpufreq.c file? i.e.
transition_latency = 109000 (ns) to be exact ?

> this patch clamps it at about 10% of the value.

Without this patch the sampling rate of ondemand governor will be 109
ms. And after this patch it would be capped at 10 ms. Why would that
screw up anyone's setup ? I don't have an answer to that right now.

> It's worth noting that the default IMX config has HZ=100 and
> NO_HZ_IDLE=y, so maybe doing idle checks at a rate comparable to the
> jiffie tick screws stuff up?

Maybe, but I am not sure at all.

Can you try few things ?

- Don't use this patch and try to change ondemand's sampling rate from
  sysfs. Try setting it to 1 and see if the behavior is identical
  to after this patch.

- Find how much time does it really take to change the frequency of
  the CPU. I don't really thing 109 us is the right transition
  latency. Use attached patch for that and look for the print message.

-- 
viresh
>From 95d830ad8765d6c35fb9e91d5028bf3cf1ff2451 Mon Sep 17 00:00:00 2001
Message-Id: <95d830ad8765d6c35fb9e91d5028bf3cf1ff2451.1501049147.git.viresh.ku...@linaro.org>
From: Viresh Kumar 
Date: Fri, 2 Jun 2017 15:00:58 +0530
Subject: [PATCH] cpufreq: Find transition latency dynamically

Test patch to find latency dynamically.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 58 +++
 1 file changed, 58 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0d6fbb3099b4..e62d670dffd2 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1076,6 +1076,62 @@ __weak struct cpufreq_governor *cpufreq_default_governor(void)
 	return NULL;
 }
 
+static int find_dvfs_latency(struct cpufreq_policy *policy, unsigned long freq,
+			 unsigned int *latency_ns)
+{
+	u64 time;
+	int ret;
+
+	time = local_clock();
+	ret = __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L);
+	*latency_ns = local_clock() - time;
+
+	return ret;
+}
+
+/*
+ * Find the transition latency dynamically by:
+ * - Switching to min freq first.
+ * - Then switching to max freq.
+ * - And finally switching back to the initial freq.
+ *
+ * The maximum duration of the above three freq changes should be good enough to
+ * find the maximum transition latency for a platform.
+ */
+static void cpufreq_find_target_latency(struct cpufreq_policy *policy)
+{
+	unsigned long initial_freq = policy->cur;
+	unsigned int latency_ns, latency_max_ns;
+	int ret;
+
+	if (!has_target())
+		return;
+
+	/* Go to min frequency first */
+	ret = find_dvfs_latency(policy, policy->cpuinfo.min_freq, &latency_ns);
+	if (ret)
+		return;
+
+	latency_max_ns = latency_ns;
+
+	/* Go to max frequency then.. */
+	ret = find_dvfs_latency(policy, policy->cpuinfo.max_freq, &latency_ns);
+	if (ret)
+		return;
+
+	latency_max_ns = max(latency_max_ns, latency_ns);
+
+	/* And finally switch back to where we started from */
+	ret = find_dvfs_latency(policy, initial_freq, &latency_ns);
+	if (ret)
+		return;
+
+	policy->cpuinfo.transition_latency = max(latency_max_ns, latency_ns);
+
+	pr_info("%s: Setting transition latency to %u ns for policy of CPU%d\n",
+		__func__, policy->cpuinfo.transition_latency, policy->cpu);
+}
+
 static int cpufreq_init_policy(struct cpufreq_policy *policy)
 {
 	struct cpufreq_governor *gov = NULL;
@@ -1345,6 +1401,8 @@ static int cpufreq_online(unsigned int cpu)
 	}
 
 	if (new_policy) {
+		cpufreq_find_target_latency(policy);
+
 		ret = cpufreq_add_dev_interface(policy);
 		if (ret)
 			goto out_exit_policy;
-- 
2.13.0.71.gd7076ec9c9cb

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

[Heiko Carstens]

On Wed, Jul 26, 2017 at 07:40:44AM +0200, Martin Schwidefsky wrote:
> On Wed, 26 Jul 2017 07:00:33 +0200
> Heiko Carstens  wrote:
> 
> > On Tue, Jul 25, 2017 at 06:14:51PM -0700, Guenter Roeck wrote:
> > > Hi Martin,
> > > 
> > > my s390 qemu tests in linux-next stopped working a few days ago.
> > > Bisect points to commit 's390/spinlock: add niai spinlock hints'.
> > > 
> > > Looking at the patch, this isn't really surprising; at least to me it 
> > > looks
> > > like the patch is making instructions mandatory which are only available 
> > > in
> > > Z14 CPUs. Does this mean that older s390 CPUs (such as the Z900 used in my
> > > qemu tests) are no longer going to be supported in Linux ?  
> > 
> > No, that means that the patch has a bug. The NIAI instruction is only
> > available if the execution-hint facility is installed. That facility came
> > with zEC12. Luckily it uses the same facility indicator bit like the
> > miscellaneous-instruction-extensions facility, which we already use anyway
> > if the kernel gets compiled for zEC12. In that case we have early code
> > which verifies if all required facilities to run the kernel are installed,
> > and if not it will print a message to the console and stop the machine.
> > 
> > So the easiest fix would be to generate the NIAI instruction only if the
> > kernel gets compiled for zEC12 or newer.
> 
> Hmm, I though that NIAI is a NOP on older machines. A runtime check for
> the facility bit is out of the question as the NIAI-7 gets inlined in
> the spin_unlock code. So yes, the only available fix is to make the
> NIAI hinting conditional on zEC12. Which is quite ugly as we would need
> an architecture level set to zEC12 for the distribution kernel to make
> use of NIAI.

Alternatively you could generate a four-byte nop, and replace that at IPL
time with the needed NIAI instruction, if the facility is available. Some
sort of "alternative" code patching infrastructure that x86 already has.
Not sure if it is worth it, however...

[Kein Betreff]

[Lars Reichardt]

unsubscribe linux-kernel

[RFC] hwmon: (ibmpowernv) Add support for reset-history sensors

[Shilpasri G Bhat]

In P9, OCC allows for clearing the sensor min-max history. This patch
exports attribute to reset history when set will clear the history of
all the sensors owned by CSM and belonging to the chip.

Signed-off-by: Shilpasri G Bhat 
---
This patch is on top of this patchset:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1453891.html

This patch creates a non-standard attribute called as reset_historyX
which clears the lowest and highest of all the sensors like power,
temperature, voltage belonging to the chip.

 drivers/hwmon/ibmpowernv.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 5ccdd0b..611e472 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -51,6 +51,7 @@ enum sensors {
POWER_SUPPLY,
POWER_INPUT,
CURRENT,
+   RESET_HISTORY,
MAX_SENSOR_TYPE,
 };
 
@@ -78,6 +79,7 @@ enum sensors {
{ "in"},
{ "power" },
{ "curr"  },
+   { "reset_history" },
 };
 
 struct sensor_data {
@@ -126,6 +128,25 @@ static ssize_t show_label(struct device *dev, struct 
device_attribute *devattr,
return sprintf(buf, "%s\n", sdata->label);
 }
 
+static ssize_t store_reset_history(struct device *dev,
+  struct device_attribute *devattr,
+  const char *buf, size_t count)
+{
+   struct sensor_data *sdata = container_of(devattr, struct sensor_data,
+dev_attr);
+   int rc;
+   int reset;
+
+   rc = kstrtoint(buf, 0, &reset);
+   if (rc)
+   return rc;
+
+   if (reset == 1)
+   rc = opal_sensor_groups_clear_history(sdata->id);
+
+   return rc ? rc : count;
+}
+
 static int __init get_logical_cpu(int hwcpu)
 {
int cpu;
@@ -458,6 +479,16 @@ static int create_device_attrs(struct platform_device 
*pdev)
 
create_hwmon_attr(&sdata[count], attr_name, show_sensor);
 
+   if (type == RESET_HISTORY) {
+   snprintf(sdata[count].name, MAX_ATTR_LEN, "%s%d",
+sensor_groups[type].name,
+sdata[count].hwmon_index);
+
+   sdata[count].dev_attr.attr.mode = 0220;
+   sdata[count].dev_attr.store = store_reset_history;
+   sdata[count].dev_attr.show = NULL;
+   }
+
pgroups[type]->attrs[sensor_groups[type].attr_count++] =
&sdata[count++].dev_attr.attr;
 
-- 
1.8.3.1

Re: [PATCH v2] drm/hisilicon: fix build error without fbdev emulation

[Daniel Vetter]

On Tue, Jul 25, 2017 at 8:05 PM, Arnd Bergmann  wrote:
> We cannot reference priv->fbdev outside of the #ifdef:
>
> drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not 
> used [-Werror=unused-function]
>  static int virtnet_restore_up(struct virtio_device *vdev)
> drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but 
> not used [-Werror=unused-function]
>  static void virtnet_freeze_down(struct virtio_device *vdev)
>
> As the #ifdef is a bit annoying here, this removes it entirely
> and uses an IS_ENABLED() check in it place where needed.
>
> Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup")
> Signed-off-by: Arnd Bergmann 

I guess I wasn't clear enough, but you don't even need the IS_ENABLED.
The cma_fini/init functions themselves don't get no-opped out (I guess
we could fix that), but the underlying fb helper functions they call
do, so this is all perfectly fine to call unconditionally. And that's
what all other drivers do. Should I edit while applying, or do you
want to respin?

Thanks, Daniel

> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 19 ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  2 --
>  2 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index 1178341c3858..5d2dfe92f62c 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -34,12 +34,11 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
>  {
> struct kirin_drm_private *priv = dev->dev_private;
>
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
> -   if (priv->fbdev) {
> +   if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) && priv->fbdev) {
> drm_fbdev_cma_fini(priv->fbdev);
> priv->fbdev = NULL;
> }
> -#endif
> +
> drm_kms_helper_poll_fini(dev);
> dc_ops->cleanup(to_platform_device(dev->dev));
> drm_mode_config_cleanup(dev);
> @@ -49,20 +48,17 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
> return 0;
>  }
>
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
>  static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
>  {
> struct kirin_drm_private *priv = dev->dev_private;
>
> drm_fbdev_cma_hotplug_event(priv->fbdev);
>  }
> -#endif
>
>  static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
> .fb_create = drm_fb_cma_create,
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
> -   .output_poll_changed = kirin_fbdev_output_poll_changed,
> -#endif
> +   .output_poll_changed = IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION) ?
> +  kirin_fbdev_output_poll_changed : NULL,
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
>  };
> @@ -121,14 +117,15 @@ static int kirin_drm_kms_init(struct drm_device *dev)
> /* init kms poll for handling hpd */
> drm_kms_helper_poll_init(dev);
>
> -   priv->fbdev = drm_fbdev_cma_init(dev, 32,
> -dev->mode_config.num_connector);
> +   if (IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION))
> +   priv->fbdev = drm_fbdev_cma_init(dev, 32,
> +
> dev->mode_config.num_connector);
> +
> if (IS_ERR(priv->fbdev)) {
> DRM_ERROR("failed to initialize fbdev.\n");
> ret = PTR_ERR(priv->fbdev);
> goto err_cleanup_poll;
> }
> -
> return 0;
>
>  err_cleanup_poll:
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> index 7f60c64915d9..56cb62df065c 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> @@ -20,9 +20,7 @@ struct kirin_dc_ops {
>  };
>
>  struct kirin_drm_private {
> -#ifdef CONFIG_DRM_FBDEV_EMULATION
> struct drm_fbdev_cma *fbdev;
> -#endif
>  };
>
>  extern const struct kirin_dc_ops ade_dc_ops;
> --
> 2.9.0
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH V2] selftests/vm: Add tests to validate mirror functionality with mremap

[Michal Hocko]

On Wed 26-07-17 09:54:26, Anshuman Khandual wrote:
> On 07/25/2017 07:06 PM, Michal Hocko wrote:
> > On Tue 25-07-17 12:06:57, Anshuman Khandual wrote:
> > [...]
> >> diff --git a/tools/testing/selftests/vm/mremap_mirror_private_anon.c 
> >> b/tools/testing/selftests/vm/mremap_mirror_private_anon.c
> > [...]
> >> +  ptr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
> >> +  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> >> +  if (ptr == MAP_FAILED) {
> >> +  perror("map() failed");
> >> +  return -1;
> >> +  }
> >> +  memset(ptr, PATTERN, alloc_size);
> >> +
> >> +  mirror_ptr =  (char *) mremap(ptr, 0, alloc_size, MREMAP_MAYMOVE);
> >> +  if (mirror_ptr == MAP_FAILED) {
> >> +  perror("mremap() failed");
> >> +  return -1;
> >> +  }
> > 
> > What is the point of this test? It will break with Mike's patch very
> > soon. Btw. it never worked.
> 
> It works now. The new 'mirrored' buffer does not have same elements
> as that of the original one.

So what exactly are you testing here? The current implementation or the
semantic of mremap. Because having a different content after mremap
doesn't make _any_ sense to me. I might be misreading the intention of
the syscall but to me it sounds like the content should be same as the
original one... If my reading is wrong then -EINVAL for anon mremaps is
simply wrong.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm, oom: allow oom reaper to race with exit_mmap

[Michal Hocko]

On Tue 25-07-17 21:19:52, Andrea Arcangeli wrote:
> On Tue, Jul 25, 2017 at 06:04:00PM +0200, Michal Hocko wrote:
> > -   down_write(&mm->mmap_sem);
> > +   if (tsk_is_oom_victim(current))
> > +   down_write(&mm->mmap_sem);
> > free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
> > tlb_finish_mmu(&tlb, 0, -1);
> >  
> > @@ -3012,7 +3014,8 @@ void exit_mmap(struct mm_struct *mm)
> > }
> > mm->mmap = NULL;
> > vm_unacct_memory(nr_accounted);
> > -   up_write(&mm->mmap_sem);
> > +   if (tsk_is_oom_victim(current))
> > +   up_write(&mm->mmap_sem);
> 
> How is this possibly safe? mark_oom_victim can run while exit_mmap is
> running.

I believe it cannot. We always call mark_oom_victim (on !current) with
task_lock held and check task->mm != NULL and we call do_exit->mmput after
mm is set to NULL under the same lock.
-- 
Michal Hocko
SUSE Labs

[PATCH v2 01/11] ASoC: samsung: s3c2412: Handle return value of clk_prepare_enable.

[Arvind Yadav]

clk_prepare_enable() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
Chnage in v2 :
 Error handling for things done in s3c_i2sv2_probe().

 sound/soc/samsung/s3c2412-i2s.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/sound/soc/samsung/s3c2412-i2s.c b/sound/soc/samsung/s3c2412-i2s.c
index 0a47182..0b96927 100644
--- a/sound/soc/samsung/s3c2412-i2s.c
+++ b/sound/soc/samsung/s3c2412-i2s.c
@@ -65,13 +65,16 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
s3c2412_i2s.iis_cclk = devm_clk_get(dai->dev, "i2sclk");
if (IS_ERR(s3c2412_i2s.iis_cclk)) {
pr_err("failed to get i2sclk clock\n");
-   return PTR_ERR(s3c2412_i2s.iis_cclk);
+   ret = PTR_ERR(s3c2412_i2s.iis_cclk);
+   goto err;
}
 
/* Set MPLL as the source for IIS CLK */
 
clk_set_parent(s3c2412_i2s.iis_cclk, clk_get(NULL, "mpll"));
-   clk_prepare_enable(s3c2412_i2s.iis_cclk);
+   ret = clk_prepare_enable(s3c2412_i2s.iis_cclk);
+   if (ret)
+   goto err;
 
s3c2412_i2s.iis_cclk = s3c2412_i2s.iis_pclk;
 
@@ -80,6 +83,11 @@ static int s3c2412_i2s_probe(struct snd_soc_dai *dai)
  S3C_GPIO_PULL_NONE);
 
return 0;
+
+err:
+   clk_disable(s3c2412_i2s.iis_pclk);
+   clk_put(s3c2412_i2s.iis_pclk);
+   return ret;
 }
 
 static int s3c2412_i2s_remove(struct snd_soc_dai *dai)
-- 
1.9.1

Re: [PATCH] mm, oom: allow oom reaper to race with exit_mmap

[Michal Hocko]

On Tue 25-07-17 20:26:19, Andrea Arcangeli wrote:
> On Tue, Jul 25, 2017 at 05:45:14PM +0200, Michal Hocko wrote:
> > That problem is real though as reported by David.
> 
> I'm not against fixing it, I just think it's not a major concern, and
> the solution doesn't seem optimal as measured by Kirill.
> 
> I'm just skeptical it's the best to solve that tiny race, 99.9% of the
> time such down_write is unnecessary.
> 
> > it is not only about exit_mmap. __mmput calls into exit_aio and that can
> > wait for completion and there is no way to guarantee this will finish in
> > finite time.
> 
> exit_aio blocking is actually the only good point for wanting this
> concurrency where exit_mmap->unmap_vmas and
> oom_reap_task->unmap_page_range have to run concurrently on the same
> mm.

Yes, exit_aio is the only blocking call I know of currently. But I would
like this to be as robust as possible and so I do not want to rely on
the current implementation. This can change in future and I can
guarantee that nobody will think about the oom path when adding
something to the final __mmput path.

> exit_mmap would have no issue, if there was enough time in the
> lifetime CPU to allocate the memory, sure the memory will also be
> freed in finite amount of time by exit_mmap.

I am not sure I understand. Say that any call prior to unmap_vmas blocks
on a lock which is held by another call path which cannot proceed with
the allocation...
 
> In fact you mentioned multiple OOM in the NUMA case, exit_mmap may not
> solve that, so depending on the runtime it may have been better not to
> wait all memory of the process to be freed before moving to the next
> task, but only a couple of seconds before the OOM reaper moves to a
> new candidate. Again this is only a tradeoff between solving the OOM
> faster vs risk of false positives OOM.

I really do not want to rely on any timing. This just too fragile. Once
we have killed a task then we shouldn't pick another victim until it
passed exit_mmap or the oom_reaper did its job. Otherwise we just risk
false positives while we have already disrupted the workload.
 
> If it wasn't because of exit_aio (which may have to wait I/O
> completion), changing the OOM reaper to return "false" if
> mmget_not_zero returns zero and MMF_OOM_SKIP is not set yet, would
> have been enough (and depending on the runtime it may have solved OOM
> faster in NUMA) and there would be absolutely no need to run OOM
> reaper and exit_mmap concurrently on the same mm. However there's such
> exit_aio..
> 
> Raw I/O mempools never require memory allocations, although aio if it
> involves a filesystem to complete may run into filesystem or buffering
> locks which are known to loop forever or depend on other tasks stuck
> in kernel allocations, so I didn't go down that chain too long.

Exactly. We simply cannot assume anything here because veryfying this
basically impossible.
 
[...]
> diff --git a/mm/mmap.c b/mm/mmap.c
> index f19efcf75418..615133762b99 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2993,6 +2993,11 @@ void exit_mmap(struct mm_struct *mm)
>   /* Use -1 here to ensure all VMAs in the mm are unmapped */
>   unmap_vmas(&tlb, vma, 0, -1);
>  
> + if (test_and_set_bit(MMF_OOM_SKIP, &mm->flags)) {
> + /* wait the OOM reaper to stop working on this mm */
> + down_write(&mm->mmap_sem);
> + up_write(&mm->mmap_sem);
> + }
>   free_pgtables(&tlb, vma, FIRST_USER_ADDRESS, USER_PGTABLES_CEILING);
>   tlb_finish_mmu(&tlb, 0, -1);
>  
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 9e8b4f030c1c..2a7000995784 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -471,6 +471,7 @@ static bool __oom_reap_task_mm(struct task_struct *tsk, 
> struct mm_struct *mm)
>   struct mmu_gather tlb;
>   struct vm_area_struct *vma;
>   bool ret = true;
> + bool mmgot = true;
>  
>   /*
>* We have to make sure to not race with the victim exit path
> @@ -500,9 +501,16 @@ static bool __oom_reap_task_mm(struct task_struct *tsk, 
> struct mm_struct *mm)
>* and delayed __mmput doesn't matter that much
>*/
>   if (!mmget_not_zero(mm)) {
> - up_read(&mm->mmap_sem);
>   trace_skip_task_reaping(tsk->pid);
> - goto unlock_oom;
> + /*
> +  * MMF_OOM_SKIP is set by exit_mmap when the OOM
> +  * reaper can't work on the mm anymore.
> +  */
> + if (test_and_set_bit(MMF_OOM_SKIP, &mm->flags)) {
> + up_read(&mm->mmap_sem);
> + goto unlock_oom;
> + }
> + mmgot = false;
>   }

This will work more or less the same to what we have currently.

[victim][oom reaper][oom killer]
do_exit __oom_reap_task_mm
  mmput
__mmput
  mmget_not_zero
test_and_set_bit(MMF_OOM_SKIP)

Re: [PATCH V2 1/4] hw_breakpoint: Add step_needed event attribute

[Pratyush Anand]

On Tuesday 25 July 2017 06:57 PM, Will Deacon wrote:

On Fri, Jul 07, 2017 at 05:33:57PM +0530, Pratyush Anand wrote:

Architecture like ARM64 currently allows to use default hw breakpoint
single step handler only to perf. However, some other users like few
systemtap tests or kernel test in
samples/hw_breakpoint/data_breakpoint.c can also work with default step
handler implementation. At the same time, some other like GDB/ptrace may
implement their own step handler.

Therefore, this patch introduces a new perf_event_attr bit field, so
that arch specific code(specially on arm64) can make a decision to
enable single stepping.

Any architecture which is not using this field will not have any
side effect.

Signed-off-by: Pratyush Anand 
---
  include/linux/hw_breakpoint.h | 6 ++
  include/uapi/linux/perf_event.h   | 3 ++-
  kernel/events/core.c  | 2 ++
  tools/include/uapi/linux/perf_event.h | 3 ++-
  4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h
index 0464c85e63fd..6173ae048cbc 100644
--- a/include/linux/hw_breakpoint.h
+++ b/include/linux/hw_breakpoint.h
@@ -38,6 +38,12 @@ static inline int hw_breakpoint_type(struct perf_event *bp)
return bp->attr.bp_type;
  }
  
+static inline bool

+hw_breakpoint_needs_single_step(struct perf_event *bp)
+{
+   return bp->attr.step_needed;
+}
+
  static inline unsigned long hw_breakpoint_len(struct perf_event *bp)
  {
return bp->attr.bp_len;
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index b1c0b187acfe..00935808de0d 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -345,7 +345,8 @@ struct perf_event_attr {
context_switch :  1, /* context switch data */
write_backward :  1, /* Write ring buffer from 
end to beginning */
namespaces :  1, /* include namespaces data 
*/
-   __reserved_1   : 35;
+   step_needed:  1, /* Use arch step handler */
+   __reserved_1   : 34;


This needs documenting properly, as I really have no idea how userspace is
going to use it sensibley, especially as you silently overwrite it in some
cases below.


I too had thought to put it under include/linux/perf_event.h : struct 
perf_event. But, see hw_break_module_init() which does not have knowledge of 
this structure, and we need to have some way so that none-perf kernel module 
implementation can tell that it needs default arch step handler.


Do you see any alternative?

--
Regards
Pratyush

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

[Martin Schwidefsky]

On Wed, 26 Jul 2017 07:00:33 +0200
Heiko Carstens  wrote:

> On Tue, Jul 25, 2017 at 06:14:51PM -0700, Guenter Roeck wrote:
> > Hi Martin,
> > 
> > my s390 qemu tests in linux-next stopped working a few days ago.
> > Bisect points to commit 's390/spinlock: add niai spinlock hints'.
> > 
> > Looking at the patch, this isn't really surprising; at least to me it looks
> > like the patch is making instructions mandatory which are only available in
> > Z14 CPUs. Does this mean that older s390 CPUs (such as the Z900 used in my
> > qemu tests) are no longer going to be supported in Linux ?  
> 
> No, that means that the patch has a bug. The NIAI instruction is only
> available if the execution-hint facility is installed. That facility came
> with zEC12. Luckily it uses the same facility indicator bit like the
> miscellaneous-instruction-extensions facility, which we already use anyway
> if the kernel gets compiled for zEC12. In that case we have early code
> which verifies if all required facilities to run the kernel are installed,
> and if not it will print a message to the console and stop the machine.
> 
> So the easiest fix would be to generate the NIAI instruction only if the
> kernel gets compiled for zEC12 or newer.

Hmm, I though that NIAI is a NOP on older machines. A runtime check for
the facility bit is out of the question as the NIAI-7 gets inlined in
the spin_unlock code. So yes, the only available fix is to make the
NIAI hinting conditional on zEC12. Which is quite ugly as we would need
an architecture level set to zEC12 for the distribution kernel to make
use of NIAI.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

[PATCH 3/6] dma: bcm-sba-raid: pre-ack async tx descriptor

[Anup Patel]

We should pre-ack async tx descriptor at time of
allocating SBA request (just like other RAID drivers).

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/dma/bcm-sba-raid.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index 321420b..db5e3db 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -236,6 +236,7 @@ static struct sba_request *sba_alloc_request(struct 
sba_device *sba)
atomic_set(&req->next_pending_count, 1);
 
dma_async_tx_descriptor_init(&req->tx, &sba->dma_chan);
+   async_tx_ack(&req->tx);
 
return req;
 }
-- 
2.7.4

[PATCH 2/6] dma: bcm-sba-raid: Peek mbox when we are left with no free requests

[Anup Patel]

We should peek mbox channels when we are left with no free
sba_requests in sba_alloc_request()

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/dma/bcm-sba-raid.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index 6d15fed..321420b 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -199,6 +199,14 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 b1, 
u32 b0)
 
 /* == General helper routines = */
 
+static void sba_peek_mchans(struct sba_device *sba)
+{
+   int mchan_idx;
+
+   for (mchan_idx = 0; mchan_idx < sba->mchans_count; mchan_idx++)
+   mbox_client_peek_data(sba->mchans[mchan_idx]);
+}
+
 static struct sba_request *sba_alloc_request(struct sba_device *sba)
 {
unsigned long flags;
@@ -210,8 +218,17 @@ static struct sba_request *sba_alloc_request(struct 
sba_device *sba)
if (req)
list_move_tail(&req->node, &sba->reqs_alloc_list);
spin_unlock_irqrestore(&sba->reqs_lock, flags);
-   if (!req)
+
+   if (!req) {
+   /*
+* We have no more free requests so, we peek
+* mailbox channels hoping few active requests
+* would have completed which will create more
+* room for new requests.
+*/
+   sba_peek_mchans(sba);
return NULL;
+   }
 
req->flags = SBA_REQUEST_STATE_ALLOCED;
req->first = req;
@@ -558,17 +575,15 @@ static enum dma_status sba_tx_status(struct dma_chan 
*dchan,
 dma_cookie_t cookie,
 struct dma_tx_state *txstate)
 {
-   int mchan_idx;
enum dma_status ret;
struct sba_device *sba = to_sba_device(dchan);
 
-   for (mchan_idx = 0; mchan_idx < sba->mchans_count; mchan_idx++)
-   mbox_client_peek_data(sba->mchans[mchan_idx]);
-
ret = dma_cookie_status(dchan, cookie, txstate);
if (ret == DMA_COMPLETE)
return ret;
 
+   sba_peek_mchans(sba);
+
return dma_cookie_status(dchan, cookie, txstate);
 }
 
-- 
2.7.4

[PATCH 6/6] arm64: dts: Add SBA-RAID DT nodes for Stingray SoC

[Anup Patel]

This patch adds Broadcom SBA-RAID DT nodes for Stingray SoC.

The Stingray SoC has total 32 SBA-RAID FlexRM rings and it has
8 CPUs so we create 8 SBA-RAID instances (one for each CPU).
This way Linux DMAENGINE will have one SBA-RAID DMA device for
each CPU.

Signed-off-by: Anup Patel 
---
 .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
index 1f927c4..8bf1dc6 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi
@@ -51,4 +51,68 @@
msi-parent = <&gic_its 0x4300>;
#mbox-cells = <3>;
};
+
+   raid0: raid@0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 0 0x1 0xff00>,
+<&raid_mbox 1 0x1 0xff00>,
+<&raid_mbox 2 0x1 0xff00>,
+<&raid_mbox 3 0x1 0xff00>;
+   };
+
+   raid1: raid@1 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 4 0x1 0xff00>,
+<&raid_mbox 5 0x1 0xff00>,
+<&raid_mbox 6 0x1 0xff00>,
+<&raid_mbox 7 0x1 0xff00>;
+   };
+
+   raid2: raid@2 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 8 0x1 0xff00>,
+<&raid_mbox 9 0x1 0xff00>,
+<&raid_mbox 10 0x1 0xff00>,
+<&raid_mbox 11 0x1 0xff00>;
+   };
+
+   raid3: raid@3 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 12 0x1 0xff00>,
+<&raid_mbox 13 0x1 0xff00>,
+<&raid_mbox 14 0x1 0xff00>,
+<&raid_mbox 15 0x1 0xff00>;
+   };
+
+   raid4: raid@4 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 16 0x1 0xff00>,
+<&raid_mbox 17 0x1 0xff00>,
+<&raid_mbox 18 0x1 0xff00>,
+<&raid_mbox 19 0x1 0xff00>;
+   };
+
+   raid5: raid@5 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 20 0x1 0xff00>,
+<&raid_mbox 21 0x1 0xff00>,
+<&raid_mbox 22 0x1 0xff00>,
+<&raid_mbox 23 0x1 0xff00>;
+   };
+
+   raid6: raid@6 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 24 0x1 0xff00>,
+<&raid_mbox 25 0x1 0xff00>,
+<&raid_mbox 26 0x1 0xff00>,
+<&raid_mbox 27 0x1 0xff00>;
+   };
+
+   raid7: raid@7 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <&raid_mbox 28 0x1 0xff00>,
+<&raid_mbox 29 0x1 0xff00>,
+<&raid_mbox 30 0x1 0xff00>,
+<&raid_mbox 31 0x1 0xff00>;
+   };
};
-- 
2.7.4

[PATCH 4/6] dma: bcm-sba-raid: Break sba_process_deferred_requests() into two parts

[Anup Patel]

This patch breaks sba_process_deferred_requests() into two parts
sba_process_received_request() and _sba_process_pending_requests()
for readability.

In addition, we remove redundant SBA_REQUEST_STATE_RECEIVED state
and ensure that all requests in a chained request should be freed
only after all have been received.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
---
 drivers/dma/bcm-sba-raid.c | 130 -
 1 file changed, 47 insertions(+), 83 deletions(-)

diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index db5e3db..b92c756 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -97,9 +97,8 @@ enum sba_request_flags {
SBA_REQUEST_STATE_ALLOCED   = 0x002,
SBA_REQUEST_STATE_PENDING   = 0x004,
SBA_REQUEST_STATE_ACTIVE= 0x008,
-   SBA_REQUEST_STATE_RECEIVED  = 0x010,
-   SBA_REQUEST_STATE_COMPLETED = 0x020,
-   SBA_REQUEST_STATE_ABORTED   = 0x040,
+   SBA_REQUEST_STATE_COMPLETED = 0x010,
+   SBA_REQUEST_STATE_ABORTED   = 0x020,
SBA_REQUEST_STATE_MASK  = 0x0ff,
SBA_REQUEST_FENCE   = 0x100,
 };
@@ -159,7 +158,6 @@ struct sba_device {
struct list_head reqs_alloc_list;
struct list_head reqs_pending_list;
struct list_head reqs_active_list;
-   struct list_head reqs_received_list;
struct list_head reqs_completed_list;
struct list_head reqs_aborted_list;
struct list_head reqs_free_list;
@@ -306,17 +304,6 @@ static void _sba_complete_request(struct sba_device *sba,
sba->reqs_fence = false;
 }
 
-/* Note: Must be called with sba->reqs_lock held */
-static void _sba_received_request(struct sba_device *sba,
- struct sba_request *req)
-{
-   lockdep_assert_held(&sba->reqs_lock);
-   req->flags = SBA_REQUEST_STATE_RECEIVED;
-   list_move_tail(&req->node, &sba->reqs_received_list);
-   if (list_empty(&sba->reqs_active_list))
-   sba->reqs_fence = false;
-}
-
 static void sba_free_chained_requests(struct sba_request *req)
 {
unsigned long flags;
@@ -358,10 +345,6 @@ static void sba_cleanup_nonpending_requests(struct 
sba_device *sba)
list_for_each_entry_safe(req, req1, &sba->reqs_alloc_list, node)
_sba_free_request(sba, req);
 
-   /* Freeup all received request */
-   list_for_each_entry_safe(req, req1, &sba->reqs_received_list, node)
-   _sba_free_request(sba, req);
-
/* Freeup all completed request */
list_for_each_entry_safe(req, req1, &sba->reqs_completed_list, node)
_sba_free_request(sba, req);
@@ -417,22 +400,20 @@ static int sba_send_mbox_request(struct sba_device *sba,
return 0;
 }
 
-static void sba_process_deferred_requests(struct sba_device *sba)
+/* Note: Must be called with sba->reqs_lock held */
+static void _sba_process_pending_requests(struct sba_device *sba)
 {
int ret;
u32 count;
-   unsigned long flags;
struct sba_request *req;
-   struct dma_async_tx_descriptor *tx;
-
-   spin_lock_irqsave(&sba->reqs_lock, flags);
-
-   /* Count pending requests */
-   count = 0;
-   list_for_each_entry(req, &sba->reqs_pending_list, node)
-   count++;
 
-   /* Process pending requests */
+   /*
+* Process few pending requests
+*
+* For now, we process ( * 8)
+* number of requests at a time.
+*/
+   count = sba->mchans_count * 8;
while (!list_empty(&sba->reqs_pending_list) && count) {
/* Get the first pending request */
req = list_first_entry(&sba->reqs_pending_list,
@@ -443,11 +424,7 @@ static void sba_process_deferred_requests(struct 
sba_device *sba)
break;
 
/* Send request to mailbox channel */
-   spin_unlock_irqrestore(&sba->reqs_lock, flags);
ret = sba_send_mbox_request(sba, req);
-   spin_lock_irqsave(&sba->reqs_lock, flags);
-
-   /* If something went wrong then keep request pending */
if (ret < 0) {
_sba_pending_request(sba, req);
break;
@@ -455,20 +432,18 @@ static void sba_process_deferred_requests(struct 
sba_device *sba)
 
count--;
}
+}
 
-   /* Count completed requests */
-   count = 0;
-   list_for_each_entry(req, &sba->reqs_completed_list, node)
-   count++;
-
-   /* Process completed requests */
-   while (!list_empty(&sba->reqs_completed_list) && count) {
-   req = list_first_entry(&sba->reqs_completed_list,
-   struct sba_request, node);
-   list_del_init(&req->node);
-   tx = &req->tx;
+static void sba_process_received_request(struct sba_device *sba,
+  

[PATCH 5/6] dma: bcm-sba-raid: Add debugfs support

[Anup Patel]

This patch adds debugfs support to report stats via debugfs
which in-turn will help debug hang situations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/dma/bcm-sba-raid.c | 82 +-
 1 file changed, 81 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index b92c756..dd1e89e 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -36,6 +36,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -161,6 +162,9 @@ struct sba_device {
struct list_head reqs_completed_list;
struct list_head reqs_aborted_list;
struct list_head reqs_free_list;
+   /* DebugFS directory entries */
+   struct dentry *root;
+   struct dentry *stats;
 };
 
 /* == Command helper routines = */
@@ -485,6 +489,45 @@ static void sba_process_received_request(struct sba_device 
*sba,
}
 }
 
+static void sba_write_stats_in_seqfile(struct sba_device *sba,
+  struct seq_file *file)
+{
+   unsigned long flags;
+   struct sba_request *req;
+   u32 free_count = 0, alloced_count = 0, pending_count = 0;
+   u32 active_count = 0, aborted_count = 0, completed_count = 0;
+
+   spin_lock_irqsave(&sba->reqs_lock, flags);
+
+   list_for_each_entry(req, &sba->reqs_free_list, node)
+   free_count++;
+
+   list_for_each_entry(req, &sba->reqs_alloc_list, node)
+   alloced_count++;
+
+   list_for_each_entry(req, &sba->reqs_pending_list, node)
+   pending_count++;
+
+   list_for_each_entry(req, &sba->reqs_active_list, node)
+   active_count++;
+
+   list_for_each_entry(req, &sba->reqs_aborted_list, node)
+   aborted_count++;
+
+   list_for_each_entry(req, &sba->reqs_completed_list, node)
+   completed_count++;
+
+   spin_unlock_irqrestore(&sba->reqs_lock, flags);
+
+   seq_printf(file, "maximum requests   = %d\n", sba->max_req);
+   seq_printf(file, "free requests  = %d\n", free_count);
+   seq_printf(file, "alloced requests   = %d\n", alloced_count);
+   seq_printf(file, "pending requests   = %d\n", pending_count);
+   seq_printf(file, "active requests= %d\n", active_count);
+   seq_printf(file, "aborted requests   = %d\n", aborted_count);
+   seq_printf(file, "completed requests = %d\n", completed_count);
+}
+
 /* == DMAENGINE callbacks = */
 
 static void sba_free_chan_resources(struct dma_chan *dchan)
@@ -1450,6 +1493,19 @@ static void sba_receive_message(struct mbox_client *cl, 
void *msg)
sba_process_received_request(sba, req);
 }
 
+/* == Debugfs callbacks == */
+
+static int sba_debugfs_stats_show(struct seq_file *file, void *offset)
+{
+   struct platform_device *pdev = to_platform_device(file->private);
+   struct sba_device *sba = platform_get_drvdata(pdev);
+
+   /* Write stats in file */
+   sba_write_stats_in_seqfile(sba, file);
+
+   return 0;
+}
+
 /* == Platform driver routines = */
 
 static int sba_prealloc_channel_resources(struct sba_device *sba)
@@ -1721,10 +1777,30 @@ static int sba_probe(struct platform_device *pdev)
if (ret)
goto fail_free_mchans;
 
+   /* Check availability of debugfs */
+   if (!debugfs_initialized())
+   goto skip_debugfs;
+
+   /* Create debugfs root entry */
+   sba->root = debugfs_create_dir(dev_name(sba->dev), NULL);
+   if (IS_ERR_OR_NULL(sba->root)) {
+   ret = PTR_ERR_OR_ZERO(sba->root);
+   goto fail_free_resources;
+   }
+
+   /* Create debugfs stats entry */
+   sba->stats = debugfs_create_devm_seqfile(sba->dev, "stats", sba->root,
+sba_debugfs_stats_show);
+   if (IS_ERR_OR_NULL(sba->stats)) {
+   ret = PTR_ERR_OR_ZERO(sba->stats);
+   goto fail_free_debugfs_root;
+   }
+skip_debugfs:
+
/* Register DMA device with linux async framework */
ret = sba_async_register(sba);
if (ret)
-   goto fail_free_resources;
+   goto fail_free_debugfs_root;
 
/* Print device info */
dev_info(sba->dev, "%s using SBAv%d and %d mailbox channels",
@@ -1733,6 +1809,8 @@ static int sba_probe(struct platform_device *pdev)
 
return 0;
 
+fail_free_debugfs_root:
+   debugfs_remove_recursive(sba->root);
 fail_free_resources:
sba_freeup_channel_resources(sba);
 fail_free_mchans:
@@ -1748,6 +1826,8 @@ static int sba_remove(struct platform_device *pdev)
 
dma_async_device_unregister(&sba->dma_dev);
 
+   debugfs_remove_recursive(sba->root);
+
sba_freeup_channel_resources(sba);
 
for (i = 0; i < sba->mchans_count; i++)
-- 
2.7.4

[PATCH 0/6] Broadcom SBA-RAID driver improvements

[Anup Patel]

This patchset does various improvments to Broadcom SBA-RAID
driver and also adds SBA-RAID DT nodes for Stingray SOC.

The patches are based on "[PATCH v2 0/7] FlexRM driver improvements"
and can also be found at sba-raid-imp-v1 branch of
https://github.com/Broadcom/arm64-linux.git

Anup Patel (6):
  dma: bcm-sba-raid: Improve memory allocation in SBA RAID driver
  dma: bcm-sba-raid: Peek mbox when we are left with no free requests
  dma: bcm-sba-raid: pre-ack async tx descriptor
  dma: bcm-sba-raid: Break sba_process_deferred_requests() into two
parts
  dma: bcm-sba-raid: Add debugfs support
  arm64: dts: Add SBA-RAID DT nodes for Stingray SoC

 .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   |  64 +++
 drivers/dma/bcm-sba-raid.c | 527 -
 2 files changed, 364 insertions(+), 227 deletions(-)

-- 
2.7.4

[PATCH 1/6] dma: bcm-sba-raid: Improve memory allocation in SBA RAID driver

[Anup Patel]

This patch improves memory allocation in SBA RAID driver in
following ways:
1. Simplify struct sba_request to reduce memory consumption
2. Allocate sba resources before registering dma device

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
Reviewed-by: Vikram Prakash 
---
 drivers/dma/bcm-sba-raid.c | 439 +++--
 1 file changed, 226 insertions(+), 213 deletions(-)

diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
index e41bbc7..6d15fed 100644
--- a/drivers/dma/bcm-sba-raid.c
+++ b/drivers/dma/bcm-sba-raid.c
@@ -48,7 +48,8 @@
 
 #include "dmaengine.h"
 
-/* SBA command related defines */
+/* == Driver macros and defines = */
+
 #define SBA_TYPE_SHIFT 48
 #define SBA_TYPE_MASK  GENMASK(1, 0)
 #define SBA_TYPE_A 0x0
@@ -82,39 +83,41 @@
 #define SBA_CMD_WRITE_BUFFER   0xc
 #define SBA_CMD_GALOIS 0xe
 
-/* Driver helper macros */
+#define SBA_MAX_REQ_PER_MBOX_CHANNEL   8192
+
 #define to_sba_request(tx) \
container_of(tx, struct sba_request, tx)
 #define to_sba_device(dchan)   \
container_of(dchan, struct sba_device, dma_chan)
 
-enum sba_request_state {
-   SBA_REQUEST_STATE_FREE = 1,
-   SBA_REQUEST_STATE_ALLOCED = 2,
-   SBA_REQUEST_STATE_PENDING = 3,
-   SBA_REQUEST_STATE_ACTIVE = 4,
-   SBA_REQUEST_STATE_RECEIVED = 5,
-   SBA_REQUEST_STATE_COMPLETED = 6,
-   SBA_REQUEST_STATE_ABORTED = 7,
+/* = Driver data structures = */
+
+enum sba_request_flags {
+   SBA_REQUEST_STATE_FREE  = 0x001,
+   SBA_REQUEST_STATE_ALLOCED   = 0x002,
+   SBA_REQUEST_STATE_PENDING   = 0x004,
+   SBA_REQUEST_STATE_ACTIVE= 0x008,
+   SBA_REQUEST_STATE_RECEIVED  = 0x010,
+   SBA_REQUEST_STATE_COMPLETED = 0x020,
+   SBA_REQUEST_STATE_ABORTED   = 0x040,
+   SBA_REQUEST_STATE_MASK  = 0x0ff,
+   SBA_REQUEST_FENCE   = 0x100,
 };
 
 struct sba_request {
/* Global state */
struct list_head node;
struct sba_device *sba;
-   enum sba_request_state state;
-   bool fence;
+   u32 flags;
/* Chained requests management */
struct sba_request *first;
struct list_head next;
-   unsigned int next_count;
atomic_t next_pending_count;
/* BRCM message data */
-   void *resp;
-   dma_addr_t resp_dma;
-   struct brcm_sba_command *cmds;
struct brcm_message msg;
struct dma_async_tx_descriptor tx;
+   /* SBA commands */
+   struct brcm_sba_command cmds[0];
 };
 
 enum sba_version {
@@ -128,11 +131,11 @@ struct sba_device {
/* DT configuration parameters */
enum sba_version ver;
/* Derived configuration parameters */
-   u32 max_req;
u32 hw_buf_size;
u32 hw_resp_size;
u32 max_pq_coefs;
u32 max_pq_srcs;
+   u32 max_req;
u32 max_cmd_per_req;
u32 max_xor_srcs;
u32 max_resp_pool_size;
@@ -152,7 +155,6 @@ struct sba_device {
void *cmds_base;
dma_addr_t cmds_dma_base;
spinlock_t reqs_lock;
-   struct sba_request *reqs;
bool reqs_fence;
struct list_head reqs_alloc_list;
struct list_head reqs_pending_list;
@@ -161,10 +163,9 @@ struct sba_device {
struct list_head reqs_completed_list;
struct list_head reqs_aborted_list;
struct list_head reqs_free_list;
-   int reqs_free_count;
 };
 
-/* == SBA command helper routines = */
+/* == Command helper routines = */
 
 static inline u64 __pure sba_cmd_enc(u64 cmd, u32 val, u32 shift, u32 mask)
 {
@@ -196,7 +197,7 @@ static inline u32 __pure sba_cmd_pq_c_mdata(u32 d, u32 b1, 
u32 b0)
   ((d & SBA_C_MDATA_DNUM_MASK) << SBA_C_MDATA_DNUM_SHIFT);
 }
 
-/* == Channel resource management routines = */
+/* == General helper routines = */
 
 static struct sba_request *sba_alloc_request(struct sba_device *sba)
 {
@@ -204,24 +205,20 @@ static struct sba_request *sba_alloc_request(struct 
sba_device *sba)
struct sba_request *req = NULL;
 
spin_lock_irqsave(&sba->reqs_lock, flags);
-
req = list_first_entry_or_null(&sba->reqs_free_list,
   struct sba_request, node);
-   if (req) {
+   if (req)
list_move_tail(&req->node, &sba->reqs_alloc_list);
-   req->state = SBA_REQUEST_STATE_ALLOCED;
-   req->fence = false;
-   req->first = req;
-   INIT_LIST_HEAD(&req->next);
-   req->next_count = 1;
-   atomic_set(&req->next_pending_count, 1);
-
-   sba->reqs_free_count--;
+   spin_unlock_irqrestore(&sba->reqs_lock, flags);
+   if (!re

Re: [PATCH V2 4/4] arm64: disable irq between breakpoint and step exception

[Pratyush Anand]

Hi Will,

Thanks for your review.

On Tuesday 25 July 2017 06:55 PM, Will Deacon wrote:

On Fri, Jul 07, 2017 at 05:34:00PM +0530, Pratyush Anand wrote:

If an interrupt is generated between breakpoint and step handler then
step handler can not get correct step address. This situation can easily
be invoked by samples/hw_breakpoint/data_breakpoint.c. It can also be
reproduced if we insert any printk() statement or dump_stack() in perf
overflow_handler. So, it seems that perf is working fine just luckily.
If the CPU which is handling perf breakpoint handler receives any
interrupt then, perf step handler will not execute sanely.

This patch improves do_debug_exception() handling, which enforces now,
that exception handler function:
- should return 0 for any software breakpoint and hw
breakpoint/watchpoint handler if it does not expect a single step stage
- should return 1 if it expects single step.
- A single step handler should always return 0.
- All handler should return a -ve error in any other case.

Now, we can know in do_debug_exception() that whether a step exception
will be followed or not. If there will a step exception then disable
irq. Re-enable it after single step handling.


AFAICT, this is only a problem for kernel-mode breakpoints where we end up
stepping into the interrupt handler when trying to step over a breakpoint.


I think yes.



We'd probably be better off getting all users of kernel step (kprobes, kgdb
and perf) to run the step with irqs disabled,



That should be doable. We can easily manage all of them in 
do_debug_exception() if individual brk handlers return correct value as per 
the rule mentioned in the commit log of this patch.


I think, I can take care of kprobes and kgdb as well in next version of patch.


but I still have reservations
about that:


So, IIUC, you have concern about faulting of a instruction being stepped. 
Since we will have a notion of *irq_en_needed*, so I think, if needed we can 
re-enable interrupt in fault handler do_mem_abort().


Whats your opinion here?



   http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/508066.html
   http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/510814.html

Wouldn't it be better to follow kprobes/kgdb and have perf run the step with
irqs disabled?

--
Regards
Pratyush

Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver

[Vinod Koul]

On Mon, Jul 24, 2017 at 01:55:10PM +, Pierre Yves MORDRET wrote:

> >> +
> >> +  res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> +  if (!res)
> >> +  return -ENODEV;
> >> +
> >> +  iomem = devm_ioremap_resource(&pdev->dev, res);
> >> +  if (!iomem)
> >> +  return -ENOMEM;
> >> +
> >> +  spin_lock_init(&stm32_dmamux->lock);
> >> +
> >> +  stm32_dmamux->clk = devm_clk_get(&pdev->dev, NULL);
> >> +  if (IS_ERR(stm32_dmamux->clk)) {
> >> +  dev_info(&pdev->dev, "Missing controller clock\n");
> > 
> > Can you check for EPROBE_DEFER and print only for if that is not the error
> > otherwise we end up sapmming with defered probe issues
> > 
> 
> This is what you meant ?
>   if (IS_ERR(stm32_dmamux->clk) != EPROBE_DEFER) {
>   dev_info(&pdev->dev, "Missing controller clock\n");
>   return PTR_ERR(stm32_dmamux->clk);
>   }
> 
> OR
> 
>   if (IS_ERR(stm32_dmamux->clk)) {
>   if (IS_ERR(stm32_dmamux->clk) != EPROBE_DEFER)
>   dev_info(&pdev->dev, "Missing controller clock\n");
>   return PTR_ERR(stm32_dmamux->clk);
>   }

This one please

> 
> >> +
> >> +#ifndef __DMA_STM32_DMAMUX_H
> >> +#define __DMA_STM32_DMAMUX_H
> >> +
> >> +#if defined(CONFIG_STM32_DMAMUX)
> >> +int stm32_dmamux_set_config(struct device *dev, void *route_data, u32 
> >> chan_id);
> > 
> > Why do we need a custom API in this case?
> > 
> 
> This API is called by DMA when a slave is requested by client. DMA can work
> without DMAMUX this API has been put in place to configure DMAMUX whether 
> client
> is requesting a DMAMUX Channel instead of a DMA one.

You mean the dmaengine driver right?

-- 
~Vinod

Re: [patches] [PATCH 17/17] RISC-V: Build Infastructure

[Palmer Dabbelt]

On Tue, 25 Jul 2017 19:57:17 PDT (-0700), j.neuschae...@gmx.net wrote:
> On Tue, Jul 11, 2017 at 06:31:30PM -0700, Palmer Dabbelt wrote:
>> This patch contains all the build infastructure that actually enables
>> the RISC-V port.  This includes Makefiles, linker scripts, and Kconfig
>> files.  It also contains the only top-level change, which adds RISC-V to
>> the list of architectures that need a sed run to produce the ARCH
>> variable when building locally.
>>
>> Signed-off-by: Palmer Dabbelt 
>> ---
> [...]
>> +config ISA_C
>> +bool "Emit compressed instructions when building Linux"
>
> As a user, I'd prefer to have slightly more globally-recognisable names
> than ISA_ for RISC-V instruction set architecture
> extensions. A quick "git grep -A2 'config ISA'" shows the following
> Kconfig symbols:
>
> * ISA, ISA_BUS_API, ISA_DMA_API, ISAPNP:
>   Settings related to the historic ISA bus.
> * ISA_ARCOMPACT/ISA_ARCV2 (arch/arc),
>   ISA_M32R/ISA_M32R2/ISA_DSP_LEVEL2/ISA_DUAL_ISSUE (arch/m32r):
>   Instruction set options.
>
> Four out of the six instruction set options have ARC/M32R in the name,
> and I think that makes things slightly more readable. Therefore I
> humbly propose something longer, and with a hint of RISC-V in the name,
> such as ISA_RVC.
>
> (Take this with a grain of salt, perhaps.)

Good timing: I was about to submit a v6 patch set.  I'm cool with
CONFIG_ISA_RVC and friends, do you mind submitting a patch?

Re: [PATCH 1/1] usb: xhci: Handle USB transaction error on address command

[Lu Baolu]

Hi,

On 07/26/2017 01:11 PM, Xing, Zhengjun wrote:
>
>
> On 7/25/2017 1:09 PM, Lu Baolu wrote:
>> Xhci driver handles USB transaction errors on transfer events,
>> but transaction errors are possible on address device command
>> completion events as well.
>>
>> The xHCI specification (section 4.6.5) says: A USB Transaction
>> Error Completion Code for an Address Device Command may be due
>> to a Stall response from a device. Software should issue a Disable
>> Slot Command for the Device Slot then an Enable Slot Command to
>> recover from this error.
>>
>> This patch handles USB transaction errors on address command
>> completion events. The related discussion threads can be found
>> through below links.
>>
>> http://marc.info/?l=linux-usb&m=149362010728921&w=2
>> http://marc.info/?l=linux-usb&m=149252752825755&w=2
>>
>> Suggested-by: Mathias Nyman 
>> Signed-off-by: Lu Baolu 
>> ---
>>   drivers/usb/host/xhci.c | 6 ++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index b2ff1ff..9cc56cd 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -3836,6 +3836,12 @@ static int xhci_setup_device(struct usb_hcd *hcd, 
>> struct usb_device *udev,
>>   ret = -EINVAL;
>>   break;
>>   case COMP_USB_TRANSACTION_ERROR:
>> +xhci_free_virt_device(xhci, udev->slot_id);
>
>  In xhci_free_virt_device  xhci->devs[slot_id]will be set to NULL.
>
>> +ret = xhci_disable_slot(xhci, command, udev->slot_id);
>
> When xhci_disable_slot check xhci->devs[slot_id] is NULL, just return 
> -EINVAL, the slot will not be disabled.

Yes, really.

I don't think xhci_disable_slot() should return directly when
the virtual device structure is not allocated. This function
is also used to issue a disable slot command when the
virtual device data allocation fails in xhci_alloc_dev().

I will develop v2 patch with a fix for xhci_disable_slot().

Best regards,
Lu Baolu

[PATCH V8 2/3] powernv: Add support to set power-shifting-ratio

[Shilpasri G Bhat]

This patch adds support to set power-shifting-ratio for CPU-GPU which
is used by OCC power capping algorithm.

Signed-off-by: Shilpasri G Bhat 
---
Changes from V7:
- Replaced sscanf with kstrtoint

 arch/powerpc/include/asm/opal-api.h|   4 +-
 arch/powerpc/include/asm/opal.h|   3 +
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-psr.c  | 169 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   2 +
 arch/powerpc/platforms/powernv/opal.c  |   3 +
 6 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/powernv/opal-psr.c

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index c3e0c4a..0d37315 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -193,7 +193,9 @@
 #define OPAL_NPU_MAP_LPAR  148
 #define OPAL_GET_POWERCAP  152
 #define OPAL_SET_POWERCAP  153
-#define OPAL_LAST  153
+#define OPAL_GET_PSR   154
+#define OPAL_SET_PSR   155
+#define OPAL_LAST  155
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ec2087c..58b30a4 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -269,6 +269,8 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int64_t opal_xive_dump(uint32_t type, uint32_t id);
 int opal_get_powercap(u32 handle, int token, u32 *pcap);
 int opal_set_powercap(u32 handle, int token, u32 pcap);
+int opal_get_power_shifting_ratio(u32 handle, int token, u32 *psr);
+int opal_set_power_shifting_ratio(u32 handle, int token, u32 psr);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -348,6 +350,7 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 void opal_wake_poller(void);
 
 void opal_powercap_init(void);
+void opal_psr_init(void);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index e79f806..9ed7d33 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o opal-powercap.o
+obj-y  += opal-kmsg.o opal-powercap.o opal-psr.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-psr.c 
b/arch/powerpc/platforms/powernv/opal-psr.c
new file mode 100644
index 000..07e3f78
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-psr.c
@@ -0,0 +1,169 @@
+/*
+ * PowerNV OPAL Power-Shifting-Ratio interface
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt) "opal-psr: " fmt
+
+#include 
+#include 
+#include 
+
+#include 
+
+DEFINE_MUTEX(psr_mutex);
+
+static struct kobject *psr_kobj;
+
+struct psr_attr {
+   u32 handle;
+   struct kobj_attribute attr;
+};
+
+static struct psr_attr *psr_attrs;
+static struct kobject *psr_kobj;
+
+static ssize_t psr_show(struct kobject *kobj, struct kobj_attribute *attr,
+   char *buf)
+{
+   struct psr_attr *psr_attr = container_of(attr, struct psr_attr, attr);
+   struct opal_msg msg;
+   int psr, ret, token;
+
+   token = opal_async_get_token_interruptible();
+   if (token < 0) {
+   pr_devel("Failed to get token\n");
+   return token;
+   }
+
+   mutex_lock(&psr_mutex);
+   ret = opal_get_power_shifting_ratio(psr_attr->handle, token, &psr);
+   switch (ret) {
+   case OPAL_ASYNC_COMPLETION:
+   ret = opal_async_wait_response(token, &msg);
+   if (ret) {
+   pr_devel("Failed to wait for the async response %d\n",
+ret);
+   goto out;
+   }
+   ret = opal_error_code(opal_get_async_rc(msg));
+   if (!ret)
+   ret = sprintf(buf, "%u\n", be32_to_cpu(psr));
+   break;
+   case OPAL_SUCCESS:
+   ret = sprintf(buf, "%u\n", be32_to_cpu(psr));
+   break;
+   default:
+   r

[PATCH V8 3/3] powernv: Add support to clear sensor groups data

[Shilpasri G Bhat]

Adds support for clearing different sensor groups. OCC inband sensor
groups like CSM, Profiler, Job Scheduler can be cleared using this
driver. The min/max of all sensors belonging to these sensor groups
will be cleared.

Signed-off-by: Shilpasri G Bhat 
---
Changes from V7:
- s/send_occ_command/opal_sensor_groups_clear_history

 arch/powerpc/include/asm/opal-api.h|   3 +-
 arch/powerpc/include/asm/opal.h|   2 +
 arch/powerpc/include/uapi/asm/opal-occ.h   |  23 ++
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-occ.c  | 109 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 arch/powerpc/platforms/powernv/opal.c  |   3 +
 7 files changed, 141 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/include/uapi/asm/opal-occ.h
 create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 0d37315..342738a 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -195,7 +195,8 @@
 #define OPAL_SET_POWERCAP  153
 #define OPAL_GET_PSR   154
 #define OPAL_SET_PSR   155
-#define OPAL_LAST  155
+#define OPAL_SENSOR_GROUPS_CLEAR   156
+#define OPAL_LAST  156
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 58b30a4..92db6af 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -271,6 +271,7 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int opal_set_powercap(u32 handle, int token, u32 pcap);
 int opal_get_power_shifting_ratio(u32 handle, int token, u32 *psr);
 int opal_set_power_shifting_ratio(u32 handle, int token, u32 psr);
+int opal_sensor_groups_clear(u32 group_hndl, int token);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -351,6 +352,7 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 
 void opal_powercap_init(void);
 void opal_psr_init(void);
+int opal_sensor_groups_clear_history(u32 handle);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/powerpc/include/uapi/asm/opal-occ.h 
b/arch/powerpc/include/uapi/asm/opal-occ.h
new file mode 100644
index 000..97c45e2
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/opal-occ.h
@@ -0,0 +1,23 @@
+/*
+ * OPAL OCC command interface
+ * Supported on POWERNV platform
+ *
+ * (C) Copyright IBM 2017
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _UAPI_ASM_POWERPC_OPAL_OCC_H_
+#define _UAPI_ASM_POWERPC_OPAL_OCC_H_
+
+#define OPAL_OCC_IOCTL_CLEAR_SENSOR_GROUPS _IOR('o', 1, u32)
+
+#endif /* _UAPI_ASM_POWERPC_OPAL_OCC_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index 9ed7d33..f193b33 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o opal-powercap.o opal-psr.o
+obj-y  += opal-kmsg.o opal-powercap.o opal-psr.o opal-occ.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-occ.c 
b/arch/powerpc/platforms/powernv/opal-occ.c
new file mode 100644
index 000..d1d4b28
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-occ.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright IBM Corporation 2017
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) "opal-occ: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DEFINE_MUTEX(opa

[PATCH V8 1/3] powernv: powercap: Add support for powercap framework

[Shilpasri G Bhat]

Adds a generic powercap framework to change the system powercap
inband through OPAL-OCC command/response interface.

Signed-off-by: Shilpasri G Bhat 
---
Changes from V7:
- Replaced sscanf with kstrtoint

 arch/powerpc/include/asm/opal-api.h|   5 +-
 arch/powerpc/include/asm/opal.h|   4 +
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-powercap.c | 237 +
 arch/powerpc/platforms/powernv/opal-wrappers.S |   2 +
 arch/powerpc/platforms/powernv/opal.c  |   4 +
 6 files changed, 252 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/platforms/powernv/opal-powercap.c

diff --git a/arch/powerpc/include/asm/opal-api.h 
b/arch/powerpc/include/asm/opal-api.h
index 3130a73..c3e0c4a 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -42,6 +42,7 @@
 #define OPAL_I2C_STOP_ERR  -24
 #define OPAL_XIVE_PROVISIONING -31
 #define OPAL_XIVE_FREE_ACTIVE  -32
+#define OPAL_TIMEOUT   -33
 
 /* API Tokens (in r0) */
 #define OPAL_INVALID_CALL -1
@@ -190,7 +191,9 @@
 #define OPAL_NPU_INIT_CONTEXT  146
 #define OPAL_NPU_DESTROY_CONTEXT   147
 #define OPAL_NPU_MAP_LPAR  148
-#define OPAL_LAST  148
+#define OPAL_GET_POWERCAP  152
+#define OPAL_SET_POWERCAP  153
+#define OPAL_LAST  153
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 588fb1c..ec2087c 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -267,6 +267,8 @@ int64_t opal_xive_set_vp_info(uint64_t vp,
 int64_t opal_xive_free_irq(uint32_t girq);
 int64_t opal_xive_sync(uint32_t type, uint32_t id);
 int64_t opal_xive_dump(uint32_t type, uint32_t id);
+int opal_get_powercap(u32 handle, int token, u32 *pcap);
+int opal_set_powercap(u32 handle, int token, u32 pcap);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
@@ -345,6 +347,8 @@ static inline int opal_get_async_rc(struct opal_msg msg)
 
 void opal_wake_poller(void);
 
+void opal_powercap_init(void);
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index b5d98cb..e79f806 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -2,7 +2,7 @@ obj-y   += setup.o opal-wrappers.o opal.o 
opal-async.o idle.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
 obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
-obj-y  += opal-kmsg.o
+obj-y  += opal-kmsg.o opal-powercap.o
 
 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-ioda.o npu-dma.o
diff --git a/arch/powerpc/platforms/powernv/opal-powercap.c 
b/arch/powerpc/platforms/powernv/opal-powercap.c
new file mode 100644
index 000..7c57f4b
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-powercap.c
@@ -0,0 +1,237 @@
+/*
+ * PowerNV OPAL Powercap interface
+ *
+ * Copyright 2017 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt) "opal-powercap: " fmt
+
+#include 
+#include 
+#include 
+
+#include 
+
+DEFINE_MUTEX(powercap_mutex);
+
+static struct kobject *powercap_kobj;
+
+struct powercap_attr {
+   u32 handle;
+   struct kobj_attribute attr;
+};
+
+static struct attribute_group *pattr_groups;
+static struct powercap_attr *pcap_attrs;
+
+static ssize_t powercap_show(struct kobject *kobj, struct kobj_attribute *attr,
+char *buf)
+{
+   struct powercap_attr *pcap_attr = container_of(attr,
+   struct powercap_attr, attr);
+   struct opal_msg msg;
+   u32 pcap;
+   int ret, token;
+
+   token = opal_async_get_token_interruptible();
+   if (token < 0) {
+   pr_devel("Failed to get token\n");
+   return token;
+   }
+
+   mutex_lock(&powercap_mutex);
+   ret = opal_get_powercap(pcap_attr->handle, token, &pcap);
+   switch (ret) {
+   case OPAL_ASYNC_COMPLETION:
+   ret = opal_async_wait_response(token, &msg);
+   if (ret) {
+   pr_devel("Failed to wait for the async response %d\n",
+ret);
+   goto out;
+   }
+   r

[PATCH V8 0/3] powernv : Add support for OPAL-OCC command/response interface

[Shilpasri G Bhat]

In P9, OCC (On-Chip-Controller) supports shared memory based
commad-response interface. Within the shared memory there is an OPAL
command buffer and OCC response buffer that can be used to send
inband commands to OCC. The following commands are supported:

1) Set system powercap
2) Set CPU-GPU power shifting ratio
3) Clear min/max for OCC sensor groups

The skiboot patch for this interface is posted here:
https://lists.ozlabs.org/pipermail/skiboot/2017-July/008352.html

Shilpasri G Bhat (3):
  powernv: powercap: Add support for powercap framework
  powernv: Add support to set power-shifting-ratio
  powernv: Add support to clear sensor groups data

 arch/powerpc/include/asm/opal-api.h|   8 +-
 arch/powerpc/include/asm/opal.h|   9 +
 arch/powerpc/include/uapi/asm/opal-occ.h   |  23 +++
 arch/powerpc/platforms/powernv/Makefile|   2 +-
 arch/powerpc/platforms/powernv/opal-occ.c  | 109 
 arch/powerpc/platforms/powernv/opal-powercap.c | 237 +
 arch/powerpc/platforms/powernv/opal-psr.c  | 169 ++
 arch/powerpc/platforms/powernv/opal-wrappers.S |   5 +
 arch/powerpc/platforms/powernv/opal.c  |  10 ++
 9 files changed, 570 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/include/uapi/asm/opal-occ.h
 create mode 100644 arch/powerpc/platforms/powernv/opal-occ.c
 create mode 100644 arch/powerpc/platforms/powernv/opal-powercap.c
 create mode 100644 arch/powerpc/platforms/powernv/opal-psr.c

-- 
1.8.3.1

Re: Qemu problems in -next with 's390/spinlock: add niai spinlock hints'

[Heiko Carstens]

On Tue, Jul 25, 2017 at 06:14:51PM -0700, Guenter Roeck wrote:
> Hi Martin,
> 
> my s390 qemu tests in linux-next stopped working a few days ago.
> Bisect points to commit 's390/spinlock: add niai spinlock hints'.
> 
> Looking at the patch, this isn't really surprising; at least to me it looks
> like the patch is making instructions mandatory which are only available in
> Z14 CPUs. Does this mean that older s390 CPUs (such as the Z900 used in my
> qemu tests) are no longer going to be supported in Linux ?

No, that means that the patch has a bug. The NIAI instruction is only
available if the execution-hint facility is installed. That facility came
with zEC12. Luckily it uses the same facility indicator bit like the
miscellaneous-instruction-extensions facility, which we already use anyway
if the kernel gets compiled for zEC12. In that case we have early code
which verifies if all required facilities to run the kernel are installed,
and if not it will print a message to the console and stop the machine.

So the easiest fix would be to generate the NIAI instruction only if the
kernel gets compiled for zEC12 or newer.

Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver

[Vinod Koul]

On Mon, Jul 24, 2017 at 09:34:18AM +, Pierre Yves MORDRET wrote:
> 
> On 07/21/2017 12:32 PM, Pierre Yves MORDRET wrote:
>  >
>  >
>  > On 07/21/2017 11:54 AM, Vinod Koul wrote:
>  >> On Fri, Jul 21, 2017 at 09:30:00AM +, Pierre Yves MORDRET wrote:
>  > +static enum dma_slave_buswidth stm32_mdma_get_max_width(u32 buf_len, 
> u32 
> tlen)
>  > +{
>  > +  enum dma_slave_buswidth max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
>  > +
>  > +  while (((buf_len % max_width) || (tlen < max_width)) &&
>  > + (max_width > DMA_SLAVE_BUSWIDTH_1_BYTE))
>  > +  max_width = max_width >> 1;
>  
>   ok, this is a bit hard to read...
>  >>>
>  >>> This code snippet has already been reworked and optimized. Would you 
> mind to
>  >>> provide me a example with your expectation ? Thanks
>  >>
>  >> Code is optimized yes, but readable no
>  >>
>  >> I would like readability to be improved upon...
>  >>
>  >
>  > gotcha
>  >
> 
> Doest he code snippet below has a better looking for you ?
> 
>   for (max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
>max_width > DMA_SLAVE_BUSWIDTH_1_BYTE; max_width >>= 1)
>   if (((buf_len % max_width) == 0) && (tlen >= max_width))
>   break;

Am actually not sure :(

Indentation wise it is still a bit messy to follow..

How about:

for (max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
max_width > DMA_SLAVE_BUSWIDTH_1_BYTE;
max_width >>=1) {
if (((buf_len % max_width) == 0) && (tlen >= max_width))
break;
}

Thanks
-- 
~Vinod

[PATCH] drm: adding SDI to drm_connector_enum_list

[Saurabh Sengar]

adding SDI to drm connector list

Signed-off-by: Saurabh Sengar 
---
 drivers/gpu/drm/drm_connector.c | 1 +
 include/uapi/drm/drm_mode.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2db7fb5..ea48ddb 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -86,6 +86,7 @@ static struct drm_conn_prop_enum_list 
drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
+   { DRM_MODE_CONNECTOR_SDI, "SDI" },
 };
 
 void drm_connector_ida_init(void)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index df0e350..9b8d204 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -247,6 +247,7 @@ struct drm_mode_get_encoder {
 #define DRM_MODE_CONNECTOR_VIRTUAL  15
 #define DRM_MODE_CONNECTOR_DSI 16
 #define DRM_MODE_CONNECTOR_DPI 17
+#define DRM_MODE_CONNECTOR_SDI 18
 
 struct drm_mode_get_connector {
 
-- 
2.7.4

Re: [PATCH 29/32] tracing: Add 'last error' error facility for hist triggers

[Namhyung Kim]

On Mon, Jun 26, 2017 at 05:49:30PM -0500, Tom Zanussi wrote:
> With the addition of variables and actions, it's become necessary to
> provide more detailed error information to users about syntax errors.
> 
> Add a 'last error' facility accessible via the erroring event's 'hist'
> file.  Reading the hist file after an error will display more detailed
> information about what went wrong, if information is available.  This
> extended error information will be available until the next hist
> trigger command for that event.
> 
>   # echo xxx > /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
>   echo: write error: Invalid argument
> 
>   # cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/hist
> 
>   ERROR: Couldn't yyy: zzz
>   Last command: xxx
> 
> Also add specific error messages for variable and action errors.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  Documentation/trace/events.txt   |  19 
>  kernel/trace/trace_events_hist.c | 181 
> ---
>  2 files changed, 188 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
> index 9717688..f271d87 100644
> --- a/Documentation/trace/events.txt
> +++ b/Documentation/trace/events.txt
> @@ -686,6 +686,25 @@ The following commands are supported:
>interpreted as microseconds.
>  cpuint - the cpu on which the event occurred.
>  
> +  Extended error information
> +  --
> +
> +  For some error conditions encountered when invoking a hist trigger
> +  command, extended error information is available via the
> +  corresponding event's 'hist' file.  Reading the hist file after an
> +  error will display more detailed information about what went wrong,
> +  if information is available.  This extended error information will
> +  be available until the next hist trigger command for that event.
> +
> +  If available for a given error condition, the extended error
> +  information and usage takes the following form:
> +
> +# echo xxx > /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
> +echo: write error: Invalid argument
> +
> +# cat /sys/kernel/debug/tracing/events/sched/sched_wakeup/hist
> +ERROR: Couldn't yyy: zzz
> +  Last command: xxx
>  
>  6.2 'hist' trigger examples
>  ---
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index 799b95e..06049f8 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -288,6 +288,7 @@ struct hist_trigger_data {
>   struct field_var*max_vars[SYNTH_FIELDS_MAX];
>   unsigned intn_max_vars;
>   unsigned intn_max_var_str;
> + char*last_err;

I couldn't find where it's used.

>  };
>  
>  struct synth_field {
> @@ -332,6 +333,83 @@ struct action_data {
>   struct hist_field   *onmax_var;
>  };
>  
> +
> +static char *hist_err_str;
> +static char *last_hist_cmd;
> +
> +static int hist_err_alloc(void)
> +{
> + int ret = 0;
> +
> + last_hist_cmd = kzalloc(MAX_FILTER_STR_VAL, GFP_KERNEL);
> + hist_err_str = kzalloc(MAX_FILTER_STR_VAL, GFP_KERNEL);
> + if (!last_hist_cmd || !hist_err_str)
> + ret = -ENOMEM;

This makes me uncomfortable..

> +
> + return ret;
> +}
> +
> +static void last_cmd_set(char *str)
> +{
> + if (!last_hist_cmd || !str)
> + return;
> +
> + if (strlen(last_hist_cmd) > MAX_FILTER_STR_VAL - 1)
> + return;

Hmm.. why does it check 'last_hist_cmd' rather than 'str'?

> +
> + strcpy(last_hist_cmd, str);
> +}
> +
> +static void hist_err(char *str, char *var)
> +{
> + int maxlen = MAX_FILTER_STR_VAL - 1;
> +
> + if (strlen(hist_err_str))
> + return;

Shouldn't it move to after the NULL check below?

Thanks,
Namhyung


> +
> + if (!hist_err_str || !str)
> + return;
> +
> + if (!var)
> + var = "";
> +
> + if (strlen(hist_err_str) + strlen(str) + strlen(var) > maxlen)
> + return;
> +
> + strcat(hist_err_str, str);
> + strcat(hist_err_str, var);
> +}
> +
> +static void hist_err_event(char *str, char *system, char *event, char *var)
> +{
> + char err[MAX_FILTER_STR_VAL];
> +
> + if (system && var)
> + sprintf(err, "%s.%s.%s", system, event, var);
> + else if (system)
> + sprintf(err, "%s.%s", system, event);
> + else
> + strcpy(err, var);
> +
> + hist_err(str, err);
> +}
> +
> +static void hist_err_clear(void)
> +{
> + if (!hist_err_str)
> + return;
> +
> + hist_err_str[0] = '\0';
> +}
> +
> +static bool have_hist_err(void)
> +{
> + if (hist_err_str && strlen(hist_err_str))
> + return true;
> +
> + return false;
> +}

Re: [PATCH v2 1/3] ptp: introduce ptp auxiliary worker

[Richard Cochran]

On Wed, Jul 26, 2017 at 06:24:39AM +0200, Richard Cochran wrote:
> Thanks for coding this up.  I'd like to get some broader review.  On
> the next round, please include lkml, John Stultz, and Thomas Gleixner.

I just noticed that you already have lkml.

Thanks,
Richard

Re: [RFC Part1 PATCH v3 03/17] x86/mm: Secure Encrypted Virtualization (SEV) support

[Borislav Petkov]

On Mon, Jul 24, 2017 at 02:07:43PM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> Provide support for Secure Encyrpted Virtualization (SEV). This initial

Your subject misses a verb and patch subjects should have an active verb
denoting what the patch does. The sentence above is a good example.

> support defines a flag that is used by the kernel to determine if it is
> running with SEV active.
> 
> Signed-off-by: Tom Lendacky 
> Signed-off-by: Brijesh Singh 
> ---
>  arch/x86/include/asm/mem_encrypt.h | 2 ++
>  arch/x86/mm/mem_encrypt.c  | 3 +++
>  include/linux/mem_encrypt.h| 8 +++-
>  3 files changed, 12 insertions(+), 1 deletion(-)

...

> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 0fbd092..1e4643e 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -40,6 +40,9 @@ static char sme_cmdline_off[] __initdata = "off";
>  unsigned long sme_me_mask __section(.data) = 0;
>  EXPORT_SYMBOL_GPL(sme_me_mask);
>  
> +unsigned int sev_enabled __section(.data) = 0;
> +EXPORT_SYMBOL_GPL(sev_enabled);

So sev_enabled is a pure bool used only in bool context, not like
sme_me_mask whose value is read too. Which means, you can make the
former static and query it only through accessor functions.

>  /* Buffer used for early in-place encryption by BSP, no locking needed */
>  static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);
>  
> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
> index 1255f09..ea0831a 100644
> --- a/include/linux/mem_encrypt.h
> +++ b/include/linux/mem_encrypt.h
> @@ -22,12 +22,18 @@
>  #else/* !CONFIG_ARCH_HAS_MEM_ENCRYPT */
>  
>  #define sme_me_mask  0UL
> +#define sev_enabled  0
>  
>  #endif   /* CONFIG_ARCH_HAS_MEM_ENCRYPT */
>  
>  static inline bool sme_active(void)
>  {
> - return !!sme_me_mask;
> + return (sme_me_mask && !sev_enabled);

You don't need the brackets. Below too.

> +}
> +
> +static inline bool sev_active(void)
> +{
> + return (sme_me_mask && sev_enabled);
>  }

So this is confusing, TBH. SME and SEV are not mutually exclusive and
yet the logic here says so. Why?

I mean, in the hypervisor context, sme_active() is still true.

/me is confused.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH V2] selftests/vm: Add tests to validate mirror functionality with mremap

[Anshuman Khandual]

On 07/25/2017 07:06 PM, Michal Hocko wrote:
> On Tue 25-07-17 12:06:57, Anshuman Khandual wrote:
> [...]
>> diff --git a/tools/testing/selftests/vm/mremap_mirror_private_anon.c 
>> b/tools/testing/selftests/vm/mremap_mirror_private_anon.c
> [...]
>> +ptr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
>> +MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>> +if (ptr == MAP_FAILED) {
>> +perror("map() failed");
>> +return -1;
>> +}
>> +memset(ptr, PATTERN, alloc_size);
>> +
>> +mirror_ptr =  (char *) mremap(ptr, 0, alloc_size, MREMAP_MAYMOVE);
>> +if (mirror_ptr == MAP_FAILED) {
>> +perror("mremap() failed");
>> +return -1;
>> +}
> 
> What is the point of this test? It will break with Mike's patch very
> soon. Btw. it never worked.

It works now. The new 'mirrored' buffer does not have same elements
as that of the original one. Yes, once Mike's patch is merged, it
will fail during the mremap() call itself IIUC. I can change this
test to verify that mremap() call failure then but now the mismatch
of elements between the buffers is what is expected and is happening.

But if you would like I can change the test to check for mremap()
failure in this case (which will fail in the current mainline but
will pass eventually when Mike's patch is in). Please do suggest.

Re: [PATCH v2 1/3] ptp: introduce ptp auxiliary worker

[Richard Cochran]

Thanks for coding this up.  I'd like to get some broader review.  On
the next round, please include lkml, John Stultz, and Thomas Gleixner.

On Tue, Jul 25, 2017 at 03:24:18PM -0500, Grygorii Strashko wrote:
> @@ -217,6 +231,19 @@ struct ptp_clock *ptp_clock_register(struct 
> ptp_clock_info *info,
>   mutex_init(&ptp->pincfg_mux);
>   init_waitqueue_head(&ptp->tsev_wq);
>  
> + if (ptp->info->do_aux_work) {
> + char *worker_name = kasprintf(GFP_KERNEL, "ptp%d", ptp->index);
> +
> + kthread_init_delayed_work(&ptp->aux_work, ptp_aux_kworker);
> + ptp->kworker = kthread_create_worker(0, worker_name ?
> +  worker_name : info->name);
> + if (IS_ERR(ptp->kworker)) {
> + pr_err("failed to create ptp aux_worker task %ld\n",
> +PTR_ERR(ptp->kworker));
> + return ERR_CAST(ptp->kworker);

In case of error, we should undo the allocations.  

> + }
> + }
> +
>   err = ptp_populate_pin_groups(ptp);
>   if (err)
>   goto no_pin_groups;

> @@ -339,6 +371,14 @@ int ptp_find_pin(struct ptp_clock *ptp,
>  }
>  EXPORT_SYMBOL(ptp_find_pin);
>  
> +int ptp_schedule_worker(struct ptp_clock *ptp, unsigned long delay)
> +{
> + if (!ptp->kworker)
> + return -EOPNOTSUPP;

We don't need error checking here.  Surely the driver knows whether to
call this function or not.

> + return kthread_mod_delayed_work(ptp->kworker, &ptp->aux_work, delay);
> +}
> +EXPORT_SYMBOL(ptp_schedule_worker);
> +
>  /* module operations */
>  
>  static void __exit ptp_exit(void)

> diff --git a/include/linux/ptp_clock_kernel.h 
> b/include/linux/ptp_clock_kernel.h
> index a026bfd..ec86fd2 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -98,6 +98,10 @@ struct system_device_crosststamp;
>   *parameter pin: index of the pin in question.
>   *parameter func: the desired function to use.
>   *parameter chan: the function channel index to use.

Blank comment line here please.

> + * @do_work:  Request driver to perform auxiliary (periodic) operations
> + * Driver should return delay of the next auxiliary work scheduling
> + * time (>=0) or negative value in case further scheduling
> + * is not required.
>   *

Thanks,
Richard

Re: [PATCH net-next] virtio-net: mark PM functions as __maybe_unused

[David Miller]

From: Arnd Bergmann 
Date: Tue, 25 Jul 2017 17:35:50 +0200

> After removing the reset function, the freeze and restore functions
> are now unused when CONFIG_PM_SLEEP is disabled:
> 
> drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not 
> used [-Werror=unused-function]
>  static int virtnet_restore_up(struct virtio_device *vdev)
> drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but 
> not used [-Werror=unused-function]
>  static void virtnet_freeze_down(struct virtio_device *vdev)
> 
> A more robust way to do this is to remove the #ifdef around the callers
> and instead mark them as __maybe_unused. The compiler will now just
> silently drop the unused code.
> 
> Fixes: 4941d472bf95 ("virtio-net: do not reset during XDP set")
> Signed-off-by: Arnd Bergmann 

Applied, thanks.

[PATCH v4] mm: Add SLUB free list pointer obfuscation

[Kees Cook]

This SLUB free list pointer obfuscation code is modified from Brad
Spengler/PaX Team's code in the last public patch of grsecurity/PaX based
on my understanding of the code. Changes or omissions from the original
code are mine and don't reflect the original grsecurity/PaX code.

This adds a per-cache random value to SLUB caches that is XORed with
their freelist pointer address and value. This adds nearly zero overhead
and frustrates the very common heap overflow exploitation method of
overwriting freelist pointers. A recent example of the attack is written
up here: http://cyseclabs.com/blog/cve-2016-6187-heap-off-by-one-exploit
and there is a section dedicated to the technique the book "A Guide to
Kernel Exploitation: Attacking the Core", from 2010.

This is based on patches by Daniel Micay, and refactored to minimize the
use of #ifdef.

Under 200-count cycles of "hackbench -g 20 -l 1000" I saw the following
run times:

before:
mean 10.11882495
variance .03320378329145728642
stdev .18221905304181911048

after:
mean 10.12654014
variance .04700556623115577889
stdev .21680767106160192064

The difference gets lost in the noise, but if the above is to be taken
literally, using CONFIG_FREELIST_HARDENED is 0.07% slower.

Suggested-by: Daniel Micay 
Cc: Christoph Lameter 
Cc: Rik van Riel 
Cc: Tycho Andersen 
Cc: Alexander Popov 
Signed-off-by: Kees Cook 
---
v4:
- add another reference to how common this exploit technique is.
v3:
- use static inlines instead of macros (akpm).
v2:
- rename CONFIG_SLAB_HARDENED to CONFIG_FREELIST_HARDENED (labbott).
---
 include/linux/slub_def.h |  4 
 init/Kconfig |  9 +
 mm/slub.c| 42 +-
 3 files changed, 50 insertions(+), 5 deletions(-)

diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index cc0faf3a90be..0783b622311e 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -115,6 +115,10 @@ struct kmem_cache {
 #endif
 #endif
 
+#ifdef CONFIG_SLAB_FREELIST_HARDENED
+   unsigned long random;
+#endif
+
 #ifdef CONFIG_NUMA
/*
 * Defragmentation by allocating from a remote node.
diff --git a/init/Kconfig b/init/Kconfig
index 8514b25db21c..3dbb980cb70b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1571,6 +1571,15 @@ config SLAB_FREELIST_RANDOM
  security feature reduces the predictability of the kernel slab
  allocator against heap overflows.
 
+config SLAB_FREELIST_HARDENED
+   bool "Harden slab freelist metadata"
+   depends on SLUB
+   help
+ Many kernel heap attacks try to target slab cache metadata and
+ other infrastructure. This options makes minor performance
+ sacrifies to harden the kernel slab allocator against common
+ freelist exploit methods.
+
 config SLUB_CPU_PARTIAL
default y
depends on SLUB && SMP
diff --git a/mm/slub.c b/mm/slub.c
index 1d3f9835f4ea..c92d6369f5e0 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -238,30 +239,58 @@ static inline void stat(const struct kmem_cache *s, enum 
stat_item si)
  * Core slab cache functions
  ***/
 
+/*
+ * Returns freelist pointer (ptr). With hardening, this is obfuscated
+ * with an XOR of the address where the pointer is held and a per-cache
+ * random number.
+ */
+static inline void *freelist_ptr(const struct kmem_cache *s, void *ptr,
+unsigned long ptr_addr)
+{
+#ifdef CONFIG_SLAB_FREELIST_HARDENED
+   return (void *)((unsigned long)ptr ^ s->random ^ ptr_addr);
+#else
+   return ptr;
+#endif
+}
+
+/* Returns the freelist pointer recorded at location ptr_addr. */
+static inline void *freelist_dereference(const struct kmem_cache *s,
+void *ptr_addr)
+{
+   return freelist_ptr(s, (void *)*(unsigned long *)(ptr_addr),
+   (unsigned long)ptr_addr);
+}
+
 static inline void *get_freepointer(struct kmem_cache *s, void *object)
 {
-   return *(void **)(object + s->offset);
+   return freelist_dereference(s, object + s->offset);
 }
 
 static void prefetch_freepointer(const struct kmem_cache *s, void *object)
 {
-   prefetch(object + s->offset);
+   if (object)
+   prefetch(freelist_dereference(s, object + s->offset));
 }
 
 static inline void *get_freepointer_safe(struct kmem_cache *s, void *object)
 {
+   unsigned long freepointer_addr;
void *p;
 
if (!debug_pagealloc_enabled())
return get_freepointer(s, object);
 
-   probe_kernel_read(&p, (void **)(object + s->offset), sizeof(p));
-   return p;
+   freepointer_addr = (unsigned long)object + s->offset;
+   probe_kernel_read(&p, (void **)freepointer_addr, sizeof(p)

Re: [linux-sunxi] Re: [PATCH 0/3] Add ethernet0 alias for several A64 boards

[Chen-Yu Tsai]

On Wed, Jul 26, 2017 at 7:54 AM, Icenowy Zheng  wrote:
>
>
> 于 2017年7月25日 GMT+08:00 下午10:31:27, Maxime Ripard 
>  写到:
>>On Tue, Jul 25, 2017 at 05:18:19AM +0200, Adam Borowski wrote:
>>> On Tue, Jul 25, 2017 at 11:04:24AM +0800, icen...@aosc.io wrote:
>>> > 在 2017-07-24 15:58，Maxime Ripard 写道：
>>> > > On Sat, Jul 22, 2017 at 10:28:49AM +0800, Icenowy Zheng wrote:
>>> > > > Allwinner A64 SoC has an EMAC which is used to provide Ethernet
>>> > > > function on several boards.
>>> > > >
>>> > > > The EMAC itself doesn't have a fixed MAC address, but the sunxi
>>> > > > mainline U-Boot have the ability to generate one based on the
>>eFUSE
>>> > > > SID in the chip, and add the generated MAC address to the
>>device
>>> > > > tree when booting.
>>> > > >
>>> > > > The MAC address setting step is based on the device tree's
>>aliases,
>>> > > > and device tree nodes prefixed "ethernet" will get the MAC
>>address
>>> > > > added. However, in several A64 boards' device tree, the alias
>>is not
>>> > > > set up, so that the U-Boot won't set the MAC address.
>>> > > >
>>> > > > Add the ethernet0 aliases to these boards.
>>> > > >
>>> > > > I hope this patchset can be queued in 4.13, otherwise 4.13
>>kernels
>>> > > > won't get non-volatile MAC addresses, and will use random ones
>>> > > > instead, which is annoying to many users.
>>> > > >
>>> > > > Icenowy Zheng (3):
>>> > > >   arm64: allwinner: a64: add ethernet0 alias for BPi M64 EMAC
>>node
>>> > > >   arm64: allwinner: a64: add ethernet0 alias for Pine64 EMAC
>>node
>>> > > >   arm64: allwinner: a64: add ethernet0 alias for SoPine EMAC
>>node
>>> > >
>>> > > Applied all three, thanks!
>>> >
>>> > Sorry, but could you queue them to 4.13?
>>> >
>>> > Otherwise 4.13 kernel release will have annoying random MAC
>>problem,
>>> > which heavily affects headless usages.
>>>
>>> Perhaps it would be better to reword the commit subject as "fix
>>missing
>>> ethernet0 alias ..."?  That'd convey that the previous behaviour is a
>>defect
>>> that needs these patches as a fix.
>>
>>Yes, definitely.
>>
>>That and having a fixes: tag.
>
> Should I resend them with different commit message?

Yes please. And add the "Fixes:" tag.

ChenYu

[PATCH] irqchip: create a Kconfig menu for irqchip drivers

[Masahiro Yamada]

Some irqchip drivers have a Kconfig prompt.  When we run menuconfig
or friends, those drivers are directly listed in the "Device Drivers"
menu level.  This does not look nice.  Create a sub-system level menu.

Signed-off-by: Masahiro Yamada 
---

 drivers/irqchip/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index f1fd5f44d1d4..7b66313a2952 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -1,3 +1,5 @@
+menu "IRQ chip support"
+
 config IRQCHIP
def_bool y
depends on OF_IRQ
@@ -306,3 +308,5 @@ config QCOM_IRQ_COMBINER
help
  Say yes here to add support for the IRQ combiner devices embedded
  in Qualcomm Technologies chips.
+
+endmenu
-- 
2.7.4

[PATCH v7] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

[Baoquan He]

Currently KASLR will parse all e820 entries of RAM type and add all
candidate position into slots array. Then we will choose one slot
randomly as the new position which kernel will be decompressed into
and run at.

On system with EFI enabled, e820 memory regions are coming from EFI
memory regions by combining adjacent regions. While these EFI memory
regions have more attributes to mark their different use. Mirror
attribute is such kind. The physical memory region whose descriptors
in EFI memory map has EFI_MEMORY_MORE_RELIABLE attribute (bit: 16) are
mirrored. The address range mirroring feature of kernel arranges such
mirror region into normal zone and other region into movable zone. And
with mirroring feature enabled, the code and date of kernel can only be
located in more reliable mirror region. However, the current KASLR code
doesn't check EFI memory entries, and could choose new position in
non-mirrored region. This will break the functionality of the address
range mirroring feature.

So if EFI is detected, iterate EFI memory map and pick the mirror region
to process for adding candidate of randomization slot. If EFI is disabled
or no mirror region found, still process e820 memory map.

Signed-off-by: Baoquan He 
---
v6->v7:
  Ingo pointed out several incorrect line break issues and unclear 
  description of patch log. Correct them and rewrite patch log.

  And also rewrite the EFI warning message that if EFI memmap is above
  4G in 32bit system since 32bit system can not handle data above 4G at
  kernel decompression stage. This is suggested by Ingo too.

v5->v6:
  Code style issue fix according to Kees's comment.

  This is based on tip/x86/boot, patch 1,2,3/4 in v5 post has
  been put into tip/x86/boot now.

 arch/x86/boot/compressed/kaslr.c | 68 ++--
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 99c7194f7ea6..e1dd59ea8a8f 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -37,7 +37,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 /* Macros used by the included decompressor code below. */
 #define STATIC
@@ -558,6 +560,65 @@ static void process_mem_region(struct mem_vector *entry,
}
 }
 
+#ifdef CONFIG_EFI
+/*
+ * Returns true if mirror region found (and must have been processed
+ * for slots adding)
+ */
+static bool
+process_efi_entries(unsigned long minimum, unsigned long image_size)
+{
+   struct efi_info *e = &boot_params->efi_info;
+   bool efi_mirror_found = false;
+   struct mem_vector region;
+   efi_memory_desc_t *md;
+   unsigned long pmap;
+   char *signature;
+   u32 nr_desc;
+   int i;
+
+   signature = (char *)&e->efi_loader_signature;
+   if (strncmp(signature, EFI32_LOADER_SIGNATURE, 4) &&
+   strncmp(signature, EFI64_LOADER_SIGNATURE, 4))
+   return false;
+
+#ifdef CONFIG_X86_32
+   /* Can't handle data above 4GB at this time */
+   if (e->efi_memmap_hi) {
+   warn("EFI memmap is above 4GB, can't be handled now on x86_32. 
EFI should be disabled.\n");
+   return false;
+   }
+   pmap =  e->efi_memmap;
+#else
+   pmap = (e->efi_memmap | ((__u64)e->efi_memmap_hi << 32));
+#endif
+
+   nr_desc = e->efi_memmap_size / e->efi_memdesc_size;
+   for (i = 0; i < nr_desc; i++) {
+   md = (efi_memory_desc_t *)(pmap + (i * e->efi_memdesc_size));
+   if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
+   region.start = md->phys_addr;
+   region.size = md->num_pages << EFI_PAGE_SHIFT;
+   process_mem_region(®ion, minimum, image_size);
+   efi_mirror_found = true;
+
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted EFI scan (slot_areas 
full)!\n");
+   break;
+   }
+   }
+   }
+
+   return efi_mirror_found;
+}
+#else
+static inline bool
+process_efi_entries(unsigned long minimum, unsigned long image_size)
+{
+   return false;
+}
+#endif
+
 static void process_e820_entries(unsigned long minimum,
 unsigned long image_size)
 {
@@ -586,13 +647,16 @@ static unsigned long find_random_phys_addr(unsigned long 
minimum,
 {
/* Check if we had too many memmaps. */
if (memmap_too_large) {
-   debug_putstr("Aborted e820 scan (more than 4 memmap= args)!\n");
+   debug_putstr("Aborted memory entries scan (more than 4 memmap= 
args)!\n");
return 0;
}
 
/* Make sure minimum is aligned. */
minimum = ALIGN(minimum, CONFIG_PHYSICAL_ALIGN);
 
+   if (process_efi_entries(minimum, image_size))
+   return slots_fetch_random();
+
process_e820_en

Re: [PATCH v3 10/15] exec: Use secureexec for setting dumpability

[Kees Cook]

On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook  wrote:
> The examination of "current" to decide dumpability is wrong. This was a
> check of and euid/uid (or egid/gid) mismatch in the existing process,
> not the newly created one. This appears to stretch back into even the
> "history.git" tree. Luckily, dumpability is later set in commit_creds().
> In earlier kernel versions before creds existed, similar checks also
> existed late in the exec flow, covering up the mistake as far back as I
> could find.
>
> Note that because the commit_creds() check examines differences of euid,
> uid, egid, gid, and capabilities between the old and new creds, it would
> look like the setup_new_exec() dumpability test could be entirely removed.
> However, the secureexec test may cover a different set of tests (specific
> to the LSMs) than what commit_creds() checks for. So, fix this test to
> use secureexec (the removed euid tests are redundant to the commoncap
> secureexec checks now).
>
> Cc: David Howells 
> Signed-off-by: Kees Cook 

David (or anyone else), how does this (and the following undiscussed
patches) look? I only have a few unreviewed patches in this series,
and I'd like to get some more eyes on it.

Thanks!

-Kees

> ---
>  fs/exec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/exec.c b/fs/exec.c
> index f9480d3e0b82..5241c8f25f5d 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1353,7 +1353,7 @@ void setup_new_exec(struct linux_binprm * bprm)
>
> current->sas_ss_sp = current->sas_ss_size = 0;
>
> -   if (uid_eq(current_euid(), current_uid()) && gid_eq(current_egid(), 
> current_gid()))
> +   if (!bprm->secureexec)
> set_dumpable(current->mm, SUID_DUMP_USER);
> else
> set_dumpable(current->mm, suid_dumpable);
> --
> 2.7.4
>



-- 
Kees Cook
Pixel Security

Re: [PATCH v3 05/15] smack: Refactor to remove bprm_secureexec hook

[Kees Cook]

On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook  wrote:
> The Smack bprm_secureexec hook can be merged with the bprm_set_creds
> hook since it's dealing with the same information, and all of the details
> are finalized during the first call to the bprm_set_creds hook via
> prepare_binprm() (subsequent calls due to binfmt_script, etc, are ignored
> via bprm->called_set_creds).
>
> Here, the test can just happen at the end of the bprm_set_creds hook,
> and the bprm_secureexec hook can be dropped.
>
> Cc: Casey Schaufler 
> Signed-off-by: Kees Cook 

How does this look to you, Casey? I've only got a few unreviewed
patches in this series. Two touch Smack. :)

Thanks!

-Kees

> ---
>  security/smack/smack_lsm.c | 21 -
>  1 file changed, 4 insertions(+), 17 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 7d4b2e221124..4f1967be3d20 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -950,6 +950,10 @@ static int smack_bprm_set_creds(struct linux_binprm 
> *bprm)
> bsp->smk_task = isp->smk_task;
> bprm->per_clear |= PER_CLEAR_ON_SETID;
>
> +   /* Decide if this is a secure exec. */
> +   if (bsp->smk_task != bsp->smk_forked)
> +   bprm->secureexec = 1;
> +
> return 0;
>  }
>
> @@ -967,22 +971,6 @@ static void smack_bprm_committing_creds(struct 
> linux_binprm *bprm)
> current->pdeath_signal = 0;
>  }
>
> -/**
> - * smack_bprm_secureexec - Return the decision to use secureexec.
> - * @bprm: binprm for exec
> - *
> - * Returns 0 on success.
> - */
> -static int smack_bprm_secureexec(struct linux_binprm *bprm)
> -{
> -   struct task_smack *tsp = current_security();
> -
> -   if (tsp->smk_task != tsp->smk_forked)
> -   return 1;
> -
> -   return 0;
> -}
> -
>  /*
>   * Inode hooks
>   */
> @@ -4646,7 +4634,6 @@ static struct security_hook_list smack_hooks[] 
> __lsm_ro_after_init = {
>
> LSM_HOOK_INIT(bprm_set_creds, smack_bprm_set_creds),
> LSM_HOOK_INIT(bprm_committing_creds, smack_bprm_committing_creds),
> -   LSM_HOOK_INIT(bprm_secureexec, smack_bprm_secureexec),
>
> LSM_HOOK_INIT(inode_alloc_security, smack_inode_alloc_security),
> LSM_HOOK_INIT(inode_free_security, smack_inode_free_security),
> --
> 2.7.4
>



-- 
Kees Cook
Pixel Security

Re: [PATCH] virtio-net: fix module unloading

[Jason Wang]

On 2017年07月24日 21:38, Andrew Jones wrote:

Unregister the driver before removing multi-instance hotplug
callbacks. This order avoids the warning issued from
__cpuhp_remove_state_cpuslocked when the number of remaining
instances isn't yet zero.

Fixes: 8017c279196a ("net/virtio-net: Convert to hotplug state machine")
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Andrew Jones 
---
  drivers/net/virtio_net.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 99a26a9efec1..f41ab0ea942a 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2743,9 +2743,9 @@ module_init(virtio_net_driver_init);
  
  static __exit void virtio_net_driver_exit(void)

  {
+   unregister_virtio_driver(&virtio_net_driver);
cpuhp_remove_multi_state(CPUHP_VIRT_NET_DEAD);
cpuhp_remove_multi_state(virtionet_online);
-   unregister_virtio_driver(&virtio_net_driver);
  }
  module_exit(virtio_net_driver_exit);
  


Acked-by: Jason Wang 

Re: [PATCH] x86/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask

[Borislav Petkov]

On Thu, Jul 20, 2017 at 04:52:08AM -0500, Suravee Suthikulpanit wrote:
> With X86_FEATURE_TOPOEXT, current logic default to using APIC ID
> to calculate cpumask for shared_cpu_map. However, since APIC IDs
> are not guarantee to be contiguous for cores across different L3,
> such as in family17h system w/ downcore configuration.
> This results in incorrect L3 shared_cpu_map.

There are syntactic and formulation errors in this paragraph, it reads
funny. Please improve.

> Instead, it should be safe to always use the pre-calculated
> cpu_llc_shared_mask to derive L3 shared_cpu_map.

"should"?!?

What does that mean? You tested it on relevant machines or you're hoping
that nothing would go wrong?

> Signed-off-by: Suravee Suthikulpanit 
> ---
>  arch/x86/kernel/cpu/intel_cacheinfo.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
> b/arch/x86/kernel/cpu/intel_cacheinfo.c
> index c55fb2c..10427bb 100644
> --- a/arch/x86/kernel/cpu/intel_cacheinfo.c
> +++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
> @@ -811,7 +811,20 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, 
> int index,
>   struct cacheinfo *this_leaf;
>   int i, sibling;
>  
> - if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
> + if (index == 3) {
> + for_each_cpu(i, cpu_llc_shared_mask(cpu)) {
> + this_cpu_ci = get_cpu_cacheinfo(i);
> + if (!this_cpu_ci->info_list)
> + continue;
> + this_leaf = this_cpu_ci->info_list + index;
> + for_each_cpu(sibling, cpu_llc_shared_mask(cpu)) {
> + if (!cpu_online(sibling))
> + continue;
> + cpumask_set_cpu(sibling,
> + &this_leaf->shared_cpu_map);
> + }
> + }
> + } else if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {

So this leaves more questions open than before it:

* Is cpu_llc_shared_map now *the* mask for the L3?

* Is the X86_FEATURE_TOPOEXT thing still going to be used for the other cache
levels? Apparently yes, I guess.

IOW, what is the big picture here? I could use some more details in the
commit message about it.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH] fortify: Use WARN instead of BUG for now

[Kees Cook]

While CONFIG_FORTIFY_SOURCE continues to shake out, don't unconditionally
use BUG(), opting instead for WARN(). At the same time, expand the runtime
detection to provide a better hint about what went wrong.

Cc: Daniel Micay 
Suggested-by: Linus Torvalds 
Signed-off-by: Kees Cook 
---
Sending to akpm, since fortify went through -mm originally.
---
 include/linux/string.h | 48 ++--
 lib/string.c   | 19 +++
 2 files changed, 45 insertions(+), 22 deletions(-)

diff --git a/include/linux/string.h b/include/linux/string.h
index a467e617eeb0..97468047b965 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -197,7 +197,10 @@ static inline const char *kbasename(const char *path)
 #define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
 #define __RENAME(x) __asm__(#x)
 
-void fortify_panic(const char *name) __noreturn __cold;
+void fortify_read_overflow(const char *func) __cold;
+void fortify_read_overflow2(const char *func) __cold;
+void fortify_write_overflow(const char *func) __cold;
+
 void __read_overflow(void) __compiletime_error("detected read beyond size of 
object passed as 1st parameter");
 void __read_overflow2(void) __compiletime_error("detected read beyond size of 
object passed as 2nd parameter");
 void __write_overflow(void) __compiletime_error("detected write beyond size of 
object passed as 1st parameter");
@@ -209,7 +212,7 @@ __FORTIFY_INLINE char *strncpy(char *p, const char *q, 
__kernel_size_t size)
if (__builtin_constant_p(size) && p_size < size)
__write_overflow();
if (p_size < size)
-   fortify_panic(__func__);
+   fortify_write_overflow(__func__);
return __builtin_strncpy(p, q, size);
 }
 
@@ -219,7 +222,7 @@ __FORTIFY_INLINE char *strcat(char *p, const char *q)
if (p_size == (size_t)-1)
return __builtin_strcat(p, q);
if (strlcat(p, q, p_size) >= p_size)
-   fortify_panic(__func__);
+   fortify_write_overflow(__func__);
return p;
 }
 
@@ -231,7 +234,7 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p)
return __builtin_strlen(p);
ret = strnlen(p, p_size);
if (p_size <= ret)
-   fortify_panic(__func__);
+   fortify_read_overflow(__func__);
return ret;
 }
 
@@ -241,7 +244,7 @@ __FORTIFY_INLINE __kernel_size_t strnlen(const char *p, 
__kernel_size_t maxlen)
size_t p_size = __builtin_object_size(p, 0);
__kernel_size_t ret = __real_strnlen(p, maxlen < p_size ? maxlen : 
p_size);
if (p_size <= ret && maxlen != ret)
-   fortify_panic(__func__);
+   fortify_read_overflow(__func__);
return ret;
 }
 
@@ -260,7 +263,7 @@ __FORTIFY_INLINE size_t strlcpy(char *p, const char *q, 
size_t size)
if (__builtin_constant_p(len) && len >= p_size)
__write_overflow();
if (len >= p_size)
-   fortify_panic(__func__);
+   fortify_write_overflow(__func__);
__builtin_memcpy(p, q, len);
p[len] = '\0';
}
@@ -278,7 +281,7 @@ __FORTIFY_INLINE char *strncat(char *p, const char *q, 
__kernel_size_t count)
p_len = strlen(p);
copy_len = strnlen(q, count);
if (p_size < p_len + copy_len + 1)
-   fortify_panic(__func__);
+   fortify_write_overflow(__func__);
__builtin_memcpy(p + p_len, q, copy_len);
p[p_len + copy_len] = '\0';
return p;
@@ -290,7 +293,7 @@ __FORTIFY_INLINE void *memset(void *p, int c, 
__kernel_size_t size)
if (__builtin_constant_p(size) && p_size < size)
__write_overflow();
if (p_size < size)
-   fortify_panic(__func__);
+   fortify_write_overflow(__func__);
return __builtin_memset(p, c, size);
 }
 
@@ -303,9 +306,12 @@ __FORTIFY_INLINE void *memcpy(void *p, const void *q, 
__kernel_size_t size)
__write_overflow();
if (q_size < size)
__read_overflow2();
+   } else {
+   if (p_size < size)
+   fortify_write_overflow(__func__);
+   if (q_size < size)
+   fortify_read_overflow2(__func__);
}
-   if (p_size < size || q_size < size)
-   fortify_panic(__func__);
return __builtin_memcpy(p, q, size);
 }
 
@@ -318,9 +324,12 @@ __FORTIFY_INLINE void *memmove(void *p, const void *q, 
__kernel_size_t size)
__write_overflow();
if (q_size < size)
__read_overflow2();
+   } else {
+   if (p_size < size)
+   fortify_write_overflow(__func__);
+   if (q_size < size)
+   fortify_read_overflow2(__func__);
}
-   i

Re: [PATCH v2] include/linux/vfio.h: Guard powerpc-specific functions with CONFIG_VFIO_SPAPR_EEH

[David Gibson]

On Tue, Jul 18, 2017 at 02:22:20PM -0300, Murilo Opsfelder Araujo wrote:
> When CONFIG_EEH=y and CONFIG_VFIO_SPAPR_EEH=n, build fails with the
> following:
> 
> drivers/vfio/pci/vfio_pci.o: In function `.vfio_pci_release':
> vfio_pci.c:(.text+0xa98): undefined reference to 
> `.vfio_spapr_pci_eeh_release'
> drivers/vfio/pci/vfio_pci.o: In function `.vfio_pci_open':
> vfio_pci.c:(.text+0x1420): undefined reference to 
> `.vfio_spapr_pci_eeh_open'
> 
> In this case, vfio_pci.c should use the empty definitions of
> vfio_spapr_pci_eeh_open and vfio_spapr_pci_eeh_release functions.
> 
> This patch fixes it by guarding these function definitions with
> CONFIG_VFIO_SPAPR_EEH, the symbol that controls whether vfio_spapr_eeh.c is
> built, which is where the non-empty versions of these functions are. We need 
> to
> make use of IS_ENABLED() macro because CONFIG_VFIO_SPAPR_EEH is a tristate
> option.
> 
> This issue was found during a randconfig build. Logs are here:
> 
> http://kisskb.ellerman.id.au/kisskb/buildresult/12982362/
> 
> Signed-off-by: Murilo Opsfelder Araujo 

Reviewed-by: David Gibson 

> ---
> 
> Changes from v1:
> - Rebased on top of next-20170718.
> 
>  include/linux/vfio.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index 586809a..a47b985 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -152,7 +152,7 @@ extern int vfio_set_irqs_validate_and_prepare(struct 
> vfio_irq_set *hdr,
> size_t *data_size);
> 
>  struct pci_dev;
> -#ifdef CONFIG_EEH
> +#if IS_ENABLED(CONFIG_VFIO_SPAPR_EEH)
>  extern void vfio_spapr_pci_eeh_open(struct pci_dev *pdev);
>  extern void vfio_spapr_pci_eeh_release(struct pci_dev *pdev);
>  extern long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group,
> @@ -173,7 +173,7 @@ static inline long vfio_spapr_iommu_eeh_ioctl(struct 
> iommu_group *group,
>  {
>   return -ENOTTY;
>  }
> -#endif /* CONFIG_EEH */
> +#endif /* CONFIG_VFIO_SPAPR_EEH */
> 
>  /*
>   * IRQfd - generic

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

[Wei Wang]

On 07/23/2017 09:45 AM, Michael S. Tsirkin wrote:

On Fri, Jul 14, 2017 at 03:12:43PM +0800, Wei Wang wrote:

On 07/14/2017 04:19 AM, Michael S. Tsirkin wrote:

On Thu, Jul 13, 2017 at 03:42:35PM +0800, Wei Wang wrote:

On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote:

So the way I see it, there are several issues:

- internal wait - forces multiple APIs like kick/kick_sync
 note how kick_sync can fail but your code never checks return code
- need to re-write the last descriptor - might not work
 for alternative layouts which always expose descriptors
 immediately

Probably it wasn't clear. Please let me explain the two functions here:

1) virtqueue_add_chain_desc(vq, head_id, prev_id,..):
grabs a desc from the vq and inserts it to the chain tail (which is indexed
by
prev_id, probably better to call it tail_id). Then, the new added desc
becomes
the tail (i.e. the last desc). The _F_NEXT flag is cleared for each desc
when it's
added to the chain, and set when another desc comes to follow later.

And this only works if there are multiple rings like
avail + descriptor ring.
It won't work e.g. with the proposed new layout where
writing out a descriptor exposes it immediately.

I think it can support the 1.1 proposal, too. But before getting
into that, I think we first need to deep dive into the implementation
and usage of _first/next/last. The usage would need to lock the vq
from the first to the end (otherwise, the returned info about the number
of available desc in the vq, i.e. num_free, would be invalid):

lock(vq);
add_first();
add_next();
add_last();
unlock(vq);

However, I think the case isn't this simple, since we need to check more
things
after each add_xx() step. For example, if only one entry is available at the
time
we start to use the vq, that is, num_free is 0 after add_first(), we
wouldn't be
able to add_next and add_last. So, it would work like this:

start:
 ...get free page block..
 lock(vq)
retry:
 ret = add_first(..,&num_free,);
 if(ret == -ENOSPC) {
 goto retry;
 } else if (!num_free) {
 add_chain_head();
 unlock(vq);
 kick & wait;
 goto start;
 }
next_one:
 ...get free page block..
 add_next(..,&num_free,);
 if (!num_free) {
 add_chain_head();
 unlock(vq);
 kick & wait;
 goto start;
 } if (num_free == 1) {
 ...get free page block..
 add_last(..);
 unlock(vq);
 kick & wait;
 goto start;
 } else {
 goto next_one;
 }

The above seems unnecessary to me to have three different APIs.
That's the reason to combine them into one virtqueue_add_chain_desc().

-- or, do you have a different thought about using the three APIs?


Implementation Reference:

struct desc_iterator {
 unsigned int head;
 unsigned int tail;
};

add_first(*vq, *desc_iterator, *num_free, ..)
{
 if (vq->vq.num_free < 1)
 return -ENOSPC;
 get_desc(&desc_id);
 desc[desc_id].flag &= ~_F_NEXT;
 desc_iterator->head = desc_id
 desc_iterator->tail = desc_iterator->head;
 *num_free = vq->vq.num_free;
}

add_next(vq, desc_iterator, *num_free,..)
{
 get_desc(&desc_id);
 desc[desc_id].flag &= ~_F_NEXT;
 desc[desc_iterator.tail].next = desc_id;
 desc[desc_iterator->tail].flag |= _F_NEXT;
 desc_iterator->tail = desc_id;
 *num_free = vq->vq.num_free;
}

add_last(vq, desc_iterator,..)
{
 get_desc(&desc_id);
 desc[desc_id].flag &= ~_F_NEXT;
 desc[desc_iterator.tail].next = desc_id;
 desc_iterator->tail = desc_id;

 add_chain_head(); // put the desc_iterator.head to the ring
}


Best,
Wei

OK I thought this over. While we might need these new APIs in
the future, I think that at the moment, there's a way to implement
this feature that is significantly simpler. Just add each s/g
as a separate input buffer.



Should it be an output buffer? I think output means from the
driver to device (i.e. DMA_TO_DEVICE).



This needs zero new APIs.

I know that follow-up patches need to add a header in front
so you might be thinking: how am I going to add this
header? The answer is quite simple - add it as a separate
out header.

Host will be able to distinguish between header and pages
by looking at the direction, and - should we want to add
IN data to header - additionally size (<4K => header).



I think this works fine when the cmdq is only used for
reporting the unused pages. It would be an issue
if there are other usages (e.g. report memory statistics)
interleaving. I think one solution would be to lock the cmdq until
a cmd usage is done ((e.g. all the unused pages are reported) ) -
in this case, the periodically updated guest memory statistics
may be delayed for a while occasionally when live migration starts.
Would this be acceptable? If not, probably we can have the cmdq
for one usage only.


Best,
Wei

[PATCH] clk: uniphier: remove sLD3 SoC support

[Masahiro Yamada]

This SoC is too old.  It is difficult to maintain any longer.

Signed-off-by: Masahiro Yamada 
---

 .../devicetree/bindings/clock/uniphier-clock.txt   |  5 ---
 drivers/clk/uniphier/clk-uniphier-core.c   | 16 +++--
 drivers/clk/uniphier/clk-uniphier-mio.c|  4 +--
 drivers/clk/uniphier/clk-uniphier-sys.c| 42 --
 drivers/clk/uniphier/clk-uniphier.h|  3 +-
 5 files changed, 20 insertions(+), 50 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/uniphier-clock.txt 
b/Documentation/devicetree/bindings/clock/uniphier-clock.txt
index 812163060fa3..2aec32d888ac 100644
--- a/Documentation/devicetree/bindings/clock/uniphier-clock.txt
+++ b/Documentation/devicetree/bindings/clock/uniphier-clock.txt
@@ -6,7 +6,6 @@ System clock
 
 Required properties:
 - compatible: should be one of the following:
-"socionext,uniphier-sld3-clock" - for sLD3 SoC.
 "socionext,uniphier-ld4-clock"  - for LD4 SoC.
 "socionext,uniphier-pro4-clock" - for Pro4 SoC.
 "socionext,uniphier-sld8-clock" - for sLD8 SoC.
@@ -48,7 +47,6 @@ Media I/O (MIO) clock, SD clock
 
 Required properties:
 - compatible: should be one of the following:
-"socionext,uniphier-sld3-mio-clock" - for sLD3 SoC.
 "socionext,uniphier-ld4-mio-clock"  - for LD4 SoC.
 "socionext,uniphier-pro4-mio-clock" - for Pro4 SoC.
 "socionext,uniphier-sld8-mio-clock" - for sLD8 SoC.
@@ -82,11 +80,9 @@ Provided clocks:
  8: USB2 ch0 host
  9: USB2 ch1 host
 10: USB2 ch2 host
-11: USB2 ch3 host
 12: USB2 ch0 PHY
 13: USB2 ch1 PHY
 14: USB2 ch2 PHY
-15: USB2 ch3 PHY
 
 
 Peripheral clock
@@ -94,7 +90,6 @@ Peripheral clock
 
 Required properties:
 - compatible: should be one of the following:
-"socionext,uniphier-sld3-peri-clock" - for sLD3 SoC.
 "socionext,uniphier-ld4-peri-clock"  - for LD4 SoC.
 "socionext,uniphier-pro4-peri-clock" - for Pro4 SoC.
 "socionext,uniphier-sld8-peri-clock" - for sLD8 SoC.
diff --git a/drivers/clk/uniphier/clk-uniphier-core.c 
b/drivers/clk/uniphier/clk-uniphier-core.c
index 2cf386347f0c..cb6ae261bb36 100644
--- a/drivers/clk/uniphier/clk-uniphier-core.c
+++ b/drivers/clk/uniphier/clk-uniphier-core.c
@@ -111,10 +111,6 @@ static int uniphier_clk_remove(struct platform_device 
*pdev)
 static const struct of_device_id uniphier_clk_match[] = {
/* System clock */
{
-   .compatible = "socionext,uniphier-sld3-clock",
-   .data = uniphier_sld3_sys_clk_data,
-   },
-   {
.compatible = "socionext,uniphier-ld4-clock",
.data = uniphier_ld4_sys_clk_data,
},
@@ -144,20 +140,16 @@ static const struct of_device_id uniphier_clk_match[] = {
},
/* Media I/O clock, SD clock */
{
-   .compatible = "socionext,uniphier-sld3-mio-clock",
-   .data = uniphier_sld3_mio_clk_data,
-   },
-   {
.compatible = "socionext,uniphier-ld4-mio-clock",
-   .data = uniphier_sld3_mio_clk_data,
+   .data = uniphier_ld4_mio_clk_data,
},
{
.compatible = "socionext,uniphier-pro4-mio-clock",
-   .data = uniphier_sld3_mio_clk_data,
+   .data = uniphier_ld4_mio_clk_data,
},
{
.compatible = "socionext,uniphier-sld8-mio-clock",
-   .data = uniphier_sld3_mio_clk_data,
+   .data = uniphier_ld4_mio_clk_data,
},
{
.compatible = "socionext,uniphier-pro5-sd-clock",
@@ -169,7 +161,7 @@ static const struct of_device_id uniphier_clk_match[] = {
},
{
.compatible = "socionext,uniphier-ld11-mio-clock",
-   .data = uniphier_sld3_mio_clk_data,
+   .data = uniphier_ld4_mio_clk_data,
},
{
.compatible = "socionext,uniphier-ld20-sd-clock",
diff --git a/drivers/clk/uniphier/clk-uniphier-mio.c 
b/drivers/clk/uniphier/clk-uniphier-mio.c
index 218d20f099ce..16e4d303f535 100644
--- a/drivers/clk/uniphier/clk-uniphier-mio.c
+++ b/drivers/clk/uniphier/clk-uniphier-mio.c
@@ -76,7 +76,7 @@
 #define UNIPHIER_MIO_CLK_DMAC(idx) \
UNIPHIER_CLK_GATE("miodmac", (idx), "stdmac", 0x20, 25)
 
-const struct uniphier_clk_data uniphier_sld3_mio_clk_data[] = {
+const struct uniphier_clk_data uniphier_ld4_mio_clk_data[] = {
UNIPHIER_MIO_CLK_SD_FIXED,
UNIPHIER_MIO_CLK_SD(0, 0),
UNIPHIER_MIO_CLK_SD(1, 1),
@@ -85,11 +85,9 @@ const struct uniphier_clk_data uniphier_sld3_mio_clk_data[] 
= {
UNIPHIER_MIO_CLK_USB2(8, 0),
UNIPHIER_MIO_CLK_USB2(9, 1),
UNIPHIER_MIO_CLK_USB2(10, 2),
-   UNIPHIER_MIO_CLK_USB2(11, 3),
UNIPHIER_MIO_CLK_USB2_PHY(12, 0),
UNIPHIER_MIO_CLK_USB2_PHY(13, 1),
UNIPHIER_MIO_CLK_USB2_PHY(14, 2),
-   UNIPHIER_MIO_CLK_USB2_PHY(15, 3),
{ /* sentinel */ }
 };
 
diff --git

Re: [PATCH net-next] virtio-net: mark PM functions as __maybe_unused

[Jason Wang]

On 2017年07月25日 23:35, Arnd Bergmann wrote:

After removing the reset function, the freeze and restore functions
are now unused when CONFIG_PM_SLEEP is disabled:

drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not 
used [-Werror=unused-function]
  static int virtnet_restore_up(struct virtio_device *vdev)
drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but not 
used [-Werror=unused-function]
  static void virtnet_freeze_down(struct virtio_device *vdev)

A more robust way to do this is to remove the #ifdef around the callers
and instead mark them as __maybe_unused. The compiler will now just
silently drop the unused code.

Fixes: 4941d472bf95 ("virtio-net: do not reset during XDP set")
Signed-off-by: Arnd Bergmann 
---
  drivers/net/virtio_net.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index d4751ce23b4f..1902701e15a9 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2702,8 +2702,7 @@ static void virtnet_remove(struct virtio_device *vdev)
free_netdev(vi->dev);
  }
  
-#ifdef CONFIG_PM_SLEEP

-static int virtnet_freeze(struct virtio_device *vdev)
+static __maybe_unused int virtnet_freeze(struct virtio_device *vdev)
  {
struct virtnet_info *vi = vdev->priv;
  
@@ -2714,7 +2713,7 @@ static int virtnet_freeze(struct virtio_device *vdev)

return 0;
  }
  
-static int virtnet_restore(struct virtio_device *vdev)

+static __maybe_unused int virtnet_restore(struct virtio_device *vdev)
  {
struct virtnet_info *vi = vdev->priv;
int err;
@@ -2730,7 +2729,6 @@ static int virtnet_restore(struct virtio_device *vdev)
  
  	return 0;

  }
-#endif
  
  static struct virtio_device_id id_table[] = {

{ VIRTIO_ID_NET, VIRTIO_DEV_ANY_ID },


Acked-by: Jason Wang 

Re: [PATCH net-next V2 5/5] virtio-net: switch off offloads on demand if possible on XDP set

[Jason Wang]

On 2017年07月25日 05:29, Michael S. Tsirkin wrote:

On Wed, Jul 19, 2017 at 04:54:49PM +0800, Jason Wang wrote:

Current XDP implementation wants guest offloads feature to be disabled
on device. This is inconvenient and means guest can't benefit from
offloads if XDP is not used. This patch tries to address this
limitation by disabling the offloads on demand through control guest
offloads. Guest offloads will be disabled and enabled on demand on XDP
set.

Signed-off-by: Jason Wang 

Doesn't look like my comments on v1 were addressed.
Copying here:

In fact, since we no longer reset when XDP is set,
here device might have offloads enabled, buffers are
used but not consumed, then XDP is set.

This can result in
- packet scattered across multiple buffers
   (handled correctly but need to update the comment)


We drop all gso packet now, so this won't happen.


- packet may have VIRTIO_NET_HDR_F_NEEDS_CSUM, in that case
   the spec says "The checksum on the packet is incomplete".
   (probably needs to be handled by calculating the checksum).


This needs to be fixed, but it was not introduced by this commit but:

b00f70b0dacb virtio-net: unbreak csumed packets for XDP_PASS which 
allows NEEDS_CSUM for mergeable buffer
bb91accf2733 virtio-net: XDP support for small buffers which forbid 
checksumed packet for small buffer


Will post a patch to checksum the packet.

Thanks



Jason, as David applied this patch already, can you comment
on the issues please?


---
  drivers/net/virtio_net.c | 70 
  1 file changed, 65 insertions(+), 5 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b3fc01d..5fbd15e 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -57,6 +57,11 @@ DECLARE_EWMA(pkt_len, 0, 64)
  
  #define VIRTNET_DRIVER_VERSION "1.0.0"
  
+const unsigned long guest_offloads[] = { VIRTIO_NET_F_GUEST_TSO4,

+VIRTIO_NET_F_GUEST_TSO6,
+VIRTIO_NET_F_GUEST_ECN,
+VIRTIO_NET_F_GUEST_UFO };
+
  struct virtnet_stats {
struct u64_stats_sync tx_syncp;
struct u64_stats_sync rx_syncp;
@@ -164,10 +169,13 @@ struct virtnet_info {
u8 ctrl_promisc;
u8 ctrl_allmulti;
u16 ctrl_vid;
+   u64 ctrl_offloads;
  
  	/* Ethtool settings */

u8 duplex;
u32 speed;
+
+   unsigned long guest_offloads;
  };
  
  struct padded_vnet_hdr {

@@ -1896,6 +1904,47 @@ static int virtnet_restore_up(struct virtio_device *vdev)
return err;
  }
  
+static int virtnet_set_guest_offloads(struct virtnet_info *vi, u64 offloads)

+{
+   struct scatterlist sg;
+   vi->ctrl_offloads = cpu_to_virtio64(vi->vdev, offloads);
+
+   sg_init_one(&sg, &vi->ctrl_offloads, sizeof(vi->ctrl_offloads));
+
+   if (!virtnet_send_command(vi, VIRTIO_NET_CTRL_GUEST_OFFLOADS,
+ VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET, &sg)) {
+   dev_warn(&vi->dev->dev, "Fail to set guest offload. \n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int virtnet_clear_guest_offloads(struct virtnet_info *vi)
+{
+   u64 offloads = 0;
+
+   if (!vi->guest_offloads)
+   return 0;
+
+   if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
+   offloads = 1ULL << VIRTIO_NET_F_GUEST_CSUM;
+
+   return virtnet_set_guest_offloads(vi, offloads);
+}
+
+static int virtnet_restore_guest_offloads(struct virtnet_info *vi)
+{
+   u64 offloads = vi->guest_offloads;
+
+   if (!vi->guest_offloads)
+   return 0;
+   if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
+   offloads |= 1ULL << VIRTIO_NET_F_GUEST_CSUM;
+
+   return virtnet_set_guest_offloads(vi, offloads);
+}
+
  static int virtnet_xdp_set(struct net_device *dev, struct bpf_prog *prog,
   struct netlink_ext_ack *extack)
  {
@@ -1905,10 +1954,11 @@ static int virtnet_xdp_set(struct net_device *dev, 
struct bpf_prog *prog,
u16 xdp_qp = 0, curr_qp;
int i, err;
  
-	if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||

-   virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6) ||
-   virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_ECN) ||
-   virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_UFO)) {
+   if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS)
+   && (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) ||
+   virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6) ||
+   virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_ECN) ||
+   virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_UFO))) {
NL_SET_ERR_MSG_MOD(extack, "Can't set XDP while host is implementing 
LRO, disable LRO first");
return -EOPNOTSUPP;
}
@@ -1955,6 +2005,

Re: [PATCH V3 1/3] x86/numa_emulation: refine the calculation of max_emu_nid and dfl_phys_nid

[Wei Yang]

On Tue, Jul 18, 2017 at 01:03:39PM +0200, Borislav Petkov wrote:
>On Sat, Jul 08, 2017 at 09:30:57AM +0800, Wei Yang wrote:
>> max_emu_nid and dfl_phys_nid is calculated from emu_nid_to_phys[], which is
>> calculated in split_nodes_xxx_interleave(). From the logic in these
>
>$ git grep split_nodes_xxx_interleave
>$
>
>> functions, it is assured the emu_nid_to_phys[] has meaningful value if it
>> return successfully and ensures dfl_phys_nid will get a valid value.
>> 
>> This patch removes the error branch to check invalid dfl_phys_nid and
>
>So the check doesn't hurt anyone.
>
>On the contrary - it is an "assertion" of sorts in otherwise complex
>code and actually documents the fact that by then emu_nid_to_phys[]
>needs to be setup properly.
>
>And it is especially useful if someone decides to change that code in
>the future, for whatever reason, and gets to hit that check - it'll even
>be helpful in that case.
>
>So I'd vote for keeping that check and not doing anything.
>
>While we're at it, never say "this patch" in a commit message - that is
>tautologically obvious.
>

Hi, Borislav 

Thanks for your comment, I will this in my mind.

>-- 
>Regards/Gruss,
>Boris.
>
>ECO tip #101: Trim your mails when you reply.
>--

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature

Re: [PATCH v3 2/3] usb: phy: Add USB charger support

[Baolin Wang]

Hi Manu,

On 25 July 2017 at 19:19, Manu Gautam  wrote:
> Hi,
>
>
> On 7/25/2017 1:30 PM, Baolin Wang wrote:
>> This patch introduces the usb charger support based on usb phy that
>> makes an enhancement to a power driver. The basic conception of the
>> usb charger is that, when one usb charger is added or removed by
>> reporting from the extcon device state change, the usb charger will
>> report to power user to set the current limitation.
>>
>> Power user can register a notifiee on the usb phy by issuing
>> usb_register_notifier() to get notified by charger status changes
>> or charger current changes.
>
> Why can't we use power_supply framework for this?
> Power user can register usb power_supply and USB PHY driver
> can update charging current using - power_supply_set_property().

No. We can get the current can be drawn from USB layer not from power
supply framework, moreover some USB controller can detect the charger
type and power supply framework can not. I think you missed lots of
previous discussion, maybe you can check below links to follow what we
have discussed before.
https://lists.gt.net/linux/kernel/2546730
https://patchwork.kernel.org/patch/9601973/


>> we can notify what current to be drawn to power user according to
>> different charger type, and now we have 2 methods to get charger type.
>> One is get charger type from extcon subsystem, which also means the
>> charger state changes. Another is we can get the charger type from
>> USB controller detecting or PMIC detecting, and the charger state
>> changes should be told by issuing usb_phy_set_charger_state().
>>
>> Signed-off-by: Baolin Wang 
>> ---
>>  drivers/usb/phy/phy.c   |  272 
>> +++
>>  include/linux/usb/phy.h |   49 +
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>



-- 
Baolin.wang
Best Regards

Re: [PATCH 3.18 00/60] 3.18.63-stable review

[Guenter Roeck]

On 07/25/2017 12:15 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.18.63 release.
There are 60 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 Thu Jul 27 19:15:49 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 135 pass: 135 fail: 0
Qemu test results:
total: 111 pass: 111 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Hi,

On 25 July 2017 at 17:59, Sebastian Reichel
 wrote:
> Hi,
>
> On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown 
>> Signed-off-by: Baolin Wang 
>> ---
>>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>>  drivers/power/supply/wm831x_power.c  |   58 
>> ++
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
>> b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> index 9f8b743..4e3bc07 100644
>> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
>> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> @@ -31,6 +31,7 @@ Required properties:
>>  ../interrupt-controller/interrupts.txt
>>
>>  Optional sub-nodes:
>> +  - usb-phy : Contains a phandle to the USB PHY.
>>- regulators : Contains sub-nodes for each of the regulators supplied by
>>  the device. The regulators are bound using their names listed below:
>>
>> diff --git a/drivers/power/supply/wm831x_power.c 
>> b/drivers/power/supply/wm831x_power.c
>> index 7082301..d3948ab 100644
>> --- a/drivers/power/supply/wm831x_power.c
>> +++ b/drivers/power/supply/wm831x_power.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -31,6 +32,8 @@ struct wm831x_power {
>>   char usb_name[20];
>>   char battery_name[20];
>>   bool have_battery;
>> + struct usb_phy *usb_phy;
>> + struct notifier_block usb_notify;
>>  };
>>
>>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
>> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>>  };
>>
>> +/* In milliamps */
>> +static const unsigned int wm831x_usb_limits[] = {
>> + 0,
>> + 2,
>> + 100,
>> + 500,
>> + 900,
>> + 1500,
>> + 1800,
>> + 550,
>> +};
>> +
>> +static int wm831x_usb_limit_change(struct notifier_block *nb,
>> +unsigned long limit, void *data)
>> +{
>> + struct wm831x_power *wm831x_power = container_of(nb,
>> +  struct wm831x_power,
>> +  usb_notify);
>> + unsigned int i, best;
>> +
>> + /* Find the highest supported limit */
>> + best = 0;
>> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
>> + if (limit >= wm831x_usb_limits[i] &&
>> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
>> + best = i;
>> + }
>> +
>> + dev_dbg(wm831x_power->wm831x->dev,
>> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
>> +
>> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
>> + WM831X_USB_ILIM_MASK, best);
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   *   Battery properties
>>   */
>> @@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device 
>> *pdev)
>>   }
>>   }
>>
>> + power->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev,
>> +  "usb-phy", 0);
>> + if (!IS_ERR(power->usb_phy)) {
>> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
>> + ret = usb_register_notifier(power->usb_phy,
>> + &power->usb_notify);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to register notifier: 
>> %d\n",
>> + ret);
>> + goto err_bat_irq;
>> + }
>> + }
>
> No error handling for power->usb_phy? I think you should bail out
> for all errors except for "not defined in DT". Especially I would
> expect probe defer handling in case the power supply driver is
> loaded before the phy driver.

Make sense. So I think I need to change like below:

power->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
if (!IS_ERR(power->usb_phy)) {
power->usb_notify.notifier_call = wm831x_usb_limit_change;
ret = usb_register_notifier(power->usb_phy, &power->usb_notify);
if (ret) {
dev_err(&pdev->dev, "Failed to register notifier: %d\n", ret);
goto err_bat_irq;
}
} else if (PTR_ERR(power->usb_phy) != -ENODEV &&
PTR_ERR(power->usb_phy) != -EINVAL) {
   ret = PTR_ERR(power->usb_phy);
   dev_err(&pdev->dev, "Failed to find USB phy: %d\n", ret);
   goto err_

Re: [PATCH 24/32] tracing: Add 'onmax' hist trigger action support

[Namhyung Kim]

On Mon, Jun 26, 2017 at 05:49:25PM -0500, Tom Zanussi wrote:
> Add an 'onmax(var).save(field,...)' hist trigger action which is
> invoked whenever an event exceeds the current maximum.
> 
> The end result is that the trace event fields or variables specified
> as the onmax.save() params will be saved if 'var' exceeds the current
> maximum for that hist trigger entry.  This allows context from the
> event that exhibited the new maximum to be saved for later reference.
> When the histogram is displayed, additional fields displaying the
> saved values will be printed.
> 
> As an example the below defines a couple of hist triggers, one for
> sched_wakeup and another for sched_switch, keyed on pid.  Whenever a
> sched_wakeup occurs, the timestamp is saved in the entry corresponding
> to the current pid, and when the scheduler switches back to that pid,
> the timestamp difference is calculated.  If the resulting latency
> exceeds the current maximum latency, the specified save() values are
> saved:
> 
> # echo 'hist:keys=pid:ts0=common_timestamp.usecs \
> if comm=="cyclictest"' >> \
>   /sys/kernel/debug/tracing/events/sched/sched_wakeup/trigger
> 
> # echo 'hist:keys=next_pid:\
>   wakeup_lat=common_timestamp.usecs-$ts0:\
>   onmax($wakeup_lat).save(next_comm,prev_pid,prev_prio,prev_comm) \
> if next_comm=="cyclictest"' >> \
>   /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
> 
> When the histogram is displayed, the max value and the saved values
> corresponding to the max are displayed following the rest of the
> fields:
> 
> # cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist
>   { next_pid:   2255 } hitcount:239 \
> common_timestamp-$ts0:  0

What is this, wakeup_lat?  If so, it'd be better showing the variable name.


> max: 27  next_comm: cyclictest \
> prev_pid:  0  prev_prio:120  prev_comm: swapper/1 \
>   { next_pid:   2256 } hitcount:   2355  common_timestamp-$ts0: 0 
> \
>   max: 49  next_comm: cyclictest \
> prev_pid:  0  prev_prio:120  prev_comm: swapper/0
> 
> Totals:
> Hits: 12970

Why total hits is different than the sum of two?

> Entries: 2
> Dropped: 0
> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_hist.c | 310 
> ++-
>  1 file changed, 276 insertions(+), 34 deletions(-)
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index b1f859c..d191f1a 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -282,6 +282,10 @@ struct hist_trigger_data {
>   unsigned intn_field_var_str;
>   struct field_var_hist   *field_var_hists[SYNTH_FIELDS_MAX];
>   unsigned intn_field_var_hists;
> +
> + struct field_var*max_vars[SYNTH_FIELDS_MAX];
> + unsigned intn_max_vars;
> + unsigned intn_max_var_str;
>  };
>  
>  struct synth_field {
> @@ -318,6 +322,12 @@ struct action_data {
>   char*match_event_system;
>   char*synth_event_name;
>   struct synth_event  *synth_event;
> +
> + char*onmax_var_str;
> + char*onmax_fn_name;
> + unsigned intmax_var_ref_idx;
> + struct hist_field   *max_var;
> + struct hist_field   *onmax_var;

Couldn't it be a union?

>  };

[SNIP]
> @@ -2613,6 +2633,222 @@ static struct field_var *create_field_var(struct 
> hist_trigger_data *hist_data,
>   return create_field_var(hist_data, file, var_name);
>  }
>  
> +static void onmax_print(struct seq_file *m,
> + struct hist_trigger_data *hist_data,
> + struct tracing_map_elt *elt,
> + struct action_data *data)
> +{
> + unsigned int i, save_var_idx, max_idx = data->max_var->var.idx;
> +
> + seq_printf(m, "\n\tmax: %10llu", tracing_map_read_var(elt, max_idx));
> +
> + for (i = 0; i < hist_data->n_max_vars; i++) {
> + struct hist_field *save_val = hist_data->max_vars[i]->val;
> + struct hist_field *save_var = hist_data->max_vars[i]->var;
> + u64 val;
> +
> + save_var_idx = save_var->var.idx;
> +
> + val = tracing_map_read_var(elt, save_var_idx);
> +
> + if (save_val->flags & HIST_FIELD_FL_STRING) {
> + seq_printf(m, "  %s: %-50s", save_var->var.name,

It seems TASK_COMM_LEN is enough.  Or please define STR_VAR_LEN or
something.


> +(char *)(uintptr_t)(val));
> + } else
> + seq_printf(m, "  %s: %10llu", save_var->var.name, val);
> + }
> +}

[SNIP]
> +static struct action_data *onmax_parse(char *str)
> +{

Re: [PATCH] initcall_debug: add deferred probe times

[Todd Poynor]

On Tue, Jul 25, 2017 at 4:40 PM, Greg Kroah-Hartman
 wrote:
> On Tue, Jul 25, 2017 at 04:31:59PM -0700, Todd Poynor wrote:
>> initcall_debug attributes all deferred device probe retries for the
>> late_initcall level to function deferred_probe_initcall.  Add logs of
>> the individual device probe routines called, to identify which drivers
>> are executing for how long during the initcall path.  Deferred probes
>> that occur after initcall processing are not shown.
>>
>> Example log messages added:
>>
>> [0.505119] deferred probe my-sound-device @ 6
>> [0.517656] deferred probe my-sound-device returned after 1227 usecs
>
> Can't you subtract the timestamp number right there?

This patch extends the existing initcall_debug functionality; I've
copied the methods used by do_one_initcall_debug() to compute and
report timing info in a compatible format.  If it's better to change
the way this is reported, I can also suggest changes to the existing
initcall_debug code.  cc'ed the maintainers (I should have in the
first place).

> And doesn't the tools/power/pm-graph/ scripts do this type of thing
> automatically for you to give you pretty graphs you can use to drill
> down on what is taking how long and such?

analyze_boot.py parses the dmesg output printed by initcall_debug to
produce those graphs (and can also produce ftrace-based function
callgraphs).  The initcall_debug output printed (and graphed) for
deferred probe calls are lumped into a single entry
"deferred_probe_initcall".  This patch logs the times of the
individual deferred probe calls by device name, to better help
developers understand where the time is spent.  If this feature finds
favor, it may also be deemed useful to update analyze_boot.py to graph
this information.

>> Signed-off-by: Todd Poynor 
>> ---
>>  drivers/base/dd.c | 28 +++-
>>  1 file changed, 27 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index 4882f06d12df..6831cb48e9dd 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -20,6 +20,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -53,6 +54,7 @@ static DEFINE_MUTEX(deferred_probe_mutex);
>>  static LIST_HEAD(deferred_probe_pending_list);
>>  static LIST_HEAD(deferred_probe_active_list);
>>  static atomic_t deferred_trigger_count = ATOMIC_INIT(0);
>> +static bool initcalls_done;
>>
>>  /*
>>   * In some cases, like suspend to RAM or hibernation, It might be reasonable
>> @@ -61,6 +63,26 @@ static atomic_t deferred_trigger_count = ATOMIC_INIT(0);
>>   */
>>  static bool defer_all_probes;
>>
>> +/*
>> + * For initcall_debug, show the deferred probes executed in late_initcall
>> + * processing.
>> + */
>> +static void deferred_probe_debug(struct device *dev)
>> +{
>> + ktime_t calltime, delta, rettime;
>> + unsigned long long duration;
>> +
>> + printk(KERN_DEBUG "deferred probe %s @ %i\n", dev_name(dev),
>> +task_pid_nr(current));
>
> _if_ I were to take something like this, it would be best to use
> dev_info(), right?

dev_info() is fine by me, if the initcall_debug command line parameter
is specified I would think it shouldn't be required to use the debug
loglevel.  But we may want to change the existing initcall_debug
messages to use info loglevel as well.

> But look at the analyze_boot.py script, I think it does all of this for
> you automagically...
>
> thanks,
>
> greg k-h

Thanks -- Todd

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

[Serge E. Hallyn]

On Fri, Jul 14, 2017 at 03:26:14PM -0400, Mimi Zohar wrote:
> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:
> > Which brings us to the semantic question of would it be nice to have
> > stacked IMA/EVM on the same file.
> > 
> > I really don't think we do.  I think allowing multiple keys for
> > different part of trusting files is easy enough that we should have no
> > need to fight over which keys do which.
> 
> We definitely want to support different policies on the native and in
> the namespace with different keys and keyrings.

Ok, so Stefan's code to support userspace in a container reading
security.ima and getting back the value for security.ima@uid=1000
(if 1000 is the kuid of the container's root user) is in fact
useful to IMA?

Re: [patches] [PATCH 17/17] RISC-V: Build Infastructure

[Jonathan Neuschäfer]

On Tue, Jul 11, 2017 at 06:31:30PM -0700, Palmer Dabbelt wrote:
> This patch contains all the build infastructure that actually enables
> the RISC-V port.  This includes Makefiles, linker scripts, and Kconfig
> files.  It also contains the only top-level change, which adds RISC-V to
> the list of architectures that need a sed run to produce the ARCH
> variable when building locally.
> 
> Signed-off-by: Palmer Dabbelt 
> ---
[...]
> +config ISA_C
> + bool "Emit compressed instructions when building Linux"

As a user, I'd prefer to have slightly more globally-recognisable names
than ISA_ for RISC-V instruction set architecture
extensions. A quick "git grep -A2 'config ISA'" shows the following
Kconfig symbols:

* ISA, ISA_BUS_API, ISA_DMA_API, ISAPNP:
  Settings related to the historic ISA bus.
* ISA_ARCOMPACT/ISA_ARCV2 (arch/arc),
  ISA_M32R/ISA_M32R2/ISA_DSP_LEVEL2/ISA_DUAL_ISSUE (arch/m32r):
  Instruction set options.

Four out of the six instruction set options have ARC/M32R in the name,
and I think that makes things slightly more readable. Therefore I
humbly propose something longer, and with a hint of RISC-V in the name,
such as ISA_RVC.

(Take this with a grain of salt, perhaps.)


Jonathan Neuschäfer


signature.asc
Description: PGP signature

Re: [PATCH 4.12 000/196] 4.12.4-stable review

[Guenter Roeck]

On 07/25/2017 12:19 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.12.4 release.
There are 196 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 Thu Jul 27 19:20:09 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

RE: [PATCH V2 00/10] clk: add imx7ulp clk support

[A.s. Dong]

Ping...

> -Original Message-
> From: Dong Aisheng [mailto:aisheng.d...@nxp.com]
> Sent: Thursday, July 13, 2017 7:47 PM
> To: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> sb...@codeaurora.org; mturque...@baylibre.com; A.s. Dong;
> donga...@gmail.com; shawn...@kernel.org; Anson Huang; Jacky Bai
> Subject: [PATCH V2 00/10] clk: add imx7ulp clk support
> 
> This patch series intends to add imx7ulp clk support.
> 
> i.MX7ULP Clock functions are under joint control of the System Clock
> Generation (SCG) modules, Peripheral Clock Control (PCC) modules, and Core
> Mode Controller (CMC)1 blocks
> 
> The clocking scheme provides clear separation between M4 domain and A7
> domain. Except for a few clock sources shared between two domains, such as
> the System Oscillator clock, the Slow IRC (SIRC), and and the Fast IRC
> clock (FIRCLK), clock sources and clock management are separated and
> contained within each domain.
> 
> M4 clock management consists of SCG0, PCC0, PCC1, and CMC0 modules.
> A7 clock management consists of SCG1, PCC2, PCC3, and CMC1 modules.
> 
> Note: this series only adds A7 clock domain support as M4 clock domain
> will be handled by M4 seperately.
> 
> Change Log:
> v1->v2:
>  * add enable/disable for the type of CLK_DIVIDER_ZERO_GATE dividers
>  * use clk_hw apis to register clocks
>  * use of_clk_add_hw_provider
>  * split the clocks register process into two parts: early part for
> possible
>timers clocks registered by CLK_OF_DECLARE_DRIVER and the later part
> for
>the left normal peripheral clocks registered by a platform driver.
> 
> Dong Aisheng (10):
>   clk: clk-divider: add CLK_DIVIDER_ZERO_GATE clk support
>   clk: reparent orphans after critical clocks enabled
>   clk: fractional-divider: add CLK_FRAC_DIVIDER_ZERO_BASED flag support
>   clk: imx: add pllv4 support
>   clk: imx: add pfdv2 support
>   clk: imx: add composite clk support
>   dt-bindings: clock: add imx7ulp clock binding doc
>   clk: imx: make mux parent strings const
>   clk: imx: implement new clk_hw based APIs
>   clk: imx: add imx7ulp clk driver
> 
>  .../devicetree/bindings/clock/imx7ulp-clock.txt|  62 ++
>  drivers/clk/clk-divider.c  | 100 -
>  drivers/clk/clk-fractional-divider.c   |  10 +
>  drivers/clk/clk.c  |  39 ++--
>  drivers/clk/imx/Makefile   |   6 +-
>  drivers/clk/imx/clk-busy.c |   2 +-
>  drivers/clk/imx/clk-composite.c|  90 
>  drivers/clk/imx/clk-fixup-mux.c|   2 +-
>  drivers/clk/imx/clk-imx7ulp.c  | 245
> +
>  drivers/clk/imx/clk-pfdv2.c| 207
> +
>  drivers/clk/imx/clk-pllv4.c| 188 
>  drivers/clk/imx/clk.c  |  22 ++
>  drivers/clk/imx/clk.h  |  92 +++-
>  include/dt-bindings/clock/imx7ulp-clock.h  | 108 +
>  include/linux/clk-provider.h   |  17 ++
>  15 files changed, 1159 insertions(+), 31 deletions(-)  create mode 100644
> Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
>  create mode 100644 drivers/clk/imx/clk-composite.c  create mode 100644
> drivers/clk/imx/clk-imx7ulp.c  create mode 100644 drivers/clk/imx/clk-
> pfdv2.c  create mode 100644 drivers/clk/imx/clk-pllv4.c  create mode
> 100644 include/dt-bindings/clock/imx7ulp-clock.h
> 
> --
> 2.7.4

Re: [PATCH 4.9 000/125] 4.9.40-stable review

[Guenter Roeck]

On 07/25/2017 12:18 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.9.40 release.
There are 125 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 Thu Jul 27 19:19:43 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.4 00/83] 4.4.79-stable review

[Guenter Roeck]

On 07/25/2017 12:18 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.79 release.
There are 83 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 Thu Jul 27 19:16:34 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH v4 0/4] Add support for ThunderX2 pmu events using json files

[Zhangshaokun]

Hi Ganapat

I have tested patch-v4 on Hisilicon's hip08 board for implementation defined 
PMU events,
and it works, So
Tested-by: Shaokun Zhang 

Thanks.
Shaokun

On 2017/7/20 13:56, Ganapatrao Kulkarni wrote:
> Extending json/jevent framework for parsing arm64 event files.
> Adding jevents for ThunderX2 implementation defined PMU events.
> 
> v4:
>- Rebased to 4.13-rc1
> 
> v3:
>- Addressed comments from Will Deacon and Jayachandran C.
>- Rebased to 4.12-rc1
> 
> v2:
>- Updated as per Mark Rutland's suggestions.
>- Added provision for get_cpuid_str to get cpu id string
>  from associated cpus of pmu core device.
> 
> v1: Initial patchset.
> 
> Ganapatrao Kulkarni (4):
>   perf utils: passing pmu as a parameter to function get_cpuid_str
>   perf tools arm64: Add support for get_cpuid_str function.
>   perf utils: Add helper function is_pmu_core to detect PMU CORE devices
>   perf vendor events arm64: Add ThunderX2 implementation defined pmu
> core events
> 
>  tools/perf/arch/arm64/util/Build   |  1 +
>  tools/perf/arch/arm64/util/header.c| 59 
>  tools/perf/arch/powerpc/util/header.c  |  2 +-
>  tools/perf/arch/x86/util/header.c  |  2 +-
>  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>  .../arm64/thunderx2/implementation-defined.json| 62 
> ++
>  tools/perf/util/header.h   |  3 +-
>  tools/perf/util/pmu.c  | 53 +++---
>  8 files changed, 186 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm64/util/header.c
>  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>  create mode 100644 
> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
> 

[PATCH] Staging: wlan-ng: hfa384x.h: Fix endianness warning for hfa384x_ps_user_count

[Manny Vindiola]

The field in hfa384x_ps_user_count was defined as u16 but used as __le16
Changed type to __le16 for consistency

Signed-off-by: Manny Vindiola 
---
 drivers/staging/wlan-ng/hfa384x.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wlan-ng/hfa384x.h 
b/drivers/staging/wlan-ng/hfa384x.h
index 9837a59..3b18e57 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -739,7 +739,7 @@ struct hfa384x_auth_request {
 /*--  Unsolicited Frame, MAC Mgmt: PSUserCount (AP Only) --*/
 
 struct hfa384x_ps_user_count {
-   u16 usercnt;
+   __le16 usercnt;
 } __packed;
 
 struct hfa384x_key_id_changed {
-- 
2.7.4

Re: [PATCH RESEND] arm64: arch_timer: fix the infinite recursion when enable ftrace and erratum workaround

[Ding Tianhong]

On 2017/7/10 19:22, Mark Rutland wrote:
> On Sun, Jul 09, 2017 at 04:30:54PM +0800, Ding Tianhong wrote:
>> When enable preempt and debug ftrace, and perform the following steps, the
>> system will hang:
>> mount -t debugfs nodev /sys/kernel/debug/
>> cd /sys/kernel/debug/tracing/
>> echo function_graph > current_tracer
>>
>> This is because tracing the preempt_disable/enable calls would cause
>> trace_clock() which would get local timer to go into infinite recursion
>> when enable the arch timer erratum workaround for some chips, so Prevent
>> tracing of preempt_disable/enable() in arch_timer_reg_read_stable().
>>
>> This problem is similar to the fixed by upstream commit 96b3d28bf4
>> ("sched/clock: Prevent tracing recursion in sched_clock_cpu()").
> 
> As I mentioned before, the patch itself looks fine to me, but the commit
> message is somewhat difficult to read.
> 
> Can we please change this to:
> 
>   arm64: arch_timer: avoid infinite recursion when ftrace is enabled
> 
>   On platforms with an arch timer erratum workaround, it's possible for
>   arch_timer_reg_read_stable() to recurse into itself when certain
>   tracing options are enabled, leading to stack overflows and related
>   problems.
>  
>   For example, when PREEMPT_TRACER and FUNCTION_GRAPH_TRACER are
>   selected, it's possible to trigger this with:
>   
>   $ mount -t debugfs nodev /sys/kernel/debug/
>   $ echo function_graph > /sys/kernel/debug/tracing/current_tracer
> 
>   The problem is that in such cases, preempt_disable() instrumentation
>   attempts to acquire a timestamp via trace_clock(), resulting in a call
>   back to arch_timer_reg_read_stable(), and hence recursion.
> 
>   This patch changes arch_timer_reg_read_stable() to use
>   preempt_{disable,enable}_notrace(), which avoids this.
> 
> With that commit message:
> 
> Acked-by: Mark Rutland 
> 
> Daniel, Thomas, would you be happy to fold that in when picking this? Or
> would you prefer that I fix this up and resend?
> 

Hi Danial, Thomas:

It looks didn't merge to the mainline tree yet, should I update the commit and
resend this patch again?

Thanks
Ding

> Thanks,
> Mark.
> 
>> Fixes: 6acc71ccac71 ("arm64: arch_timer: Allows a CPU-specific erratum to 
>> only affect a subset of CPUs")
>> Signed-off-by: Ding Tianhong 
>> ---
>>  arch/arm64/include/asm/arch_timer.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/arch_timer.h 
>> b/arch/arm64/include/asm/arch_timer.h
>> index 74d08e4..67bb7a4 100644
>> --- a/arch/arm64/include/asm/arch_timer.h
>> +++ b/arch/arm64/include/asm/arch_timer.h
>> @@ -65,13 +65,13 @@ struct arch_timer_erratum_workaround {
>>  u64 _val;   \
>>  if (needs_unstable_timer_counter_workaround()) {\
>>  const struct arch_timer_erratum_workaround *wa; \
>> -preempt_disable();  \
>> +preempt_disable_notrace();  \
>>  wa = __this_cpu_read(timer_unstable_counter_workaround); \
>>  if (wa && wa->read_##reg)   \
>>  _val = wa->read_##reg();\
>>  else\
>>  _val = read_sysreg(reg);\
>> -preempt_enable();   \
>> +preempt_enable_notrace();   \
>>  } else {\
>>  _val = read_sysreg(reg);\
>>  }   \
>> -- 
>> 1.9.0
>>
>>
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> .
> 

Re: [PATCH v2 0/2] ARM: dts: sabrelite/nitrogen6x: fix USB PHY reset

[Shawn Guo]

On Mon, Jul 24, 2017 at 02:59:56PM +0200, Gary Bisson wrote:
> Gary Bisson (2):
>   ARM: dts: imx6qdl-sabrelite: fix USB PHY reset
>   ARM: dts: imx6qdl-nitrogen6x: fix USB PHY reset

Applied both, thanks.

Re: [PATCH 23/32] tracing: Add 'onmatch' hist trigger action support

[Namhyung Kim]

Hi Tom,

On Mon, Jun 26, 2017 at 05:49:24PM -0500, Tom Zanussi wrote:
> Add an 'onmatch(matching.event).(param list)'
> hist trigger action which is invoked with the set of variables or
> event fields named in the 'param list'.  The result is the generation
> of a synthetic event that consists of the values contained in those
> variables and/or fields at the time the invoking event was hit.
> 
> As an example the below defines a simple synthetic event using a
> variable defined on the sched_wakeup_new event, and shows the event
> definition with unresolved fields, since the sched_wakeup_new event
> with the testpid variable hasn't been defined yet:
> 
> # echo 'wakeup_new_test pid_t pid; int prio' >> \
>   /sys/kernel/debug/tracing/synthetic_events
> 
> # cat /sys/kernel/debug/tracing/synthetic_events
>   wakeup_new_test pid_t pid; int prio
> 
> The following hist trigger both defines a testpid variable and
> specifies an onmatch() trace action that uses that variable along with
> a non-variable field to generate a wakeup_new_test synthetic event
> whenever a sched_wakeup_new event occurs, which because of the 'if
> comm == "cyclictest"' filter only happens when the executable is
> cyclictest:
> 
> # echo 'hist:keys=testpid=pid:\
>   onmatch(sched.sched_wakeup_new).wakeup_new_test($testpid, prio) \
> if comm=="cyclictest"' >> \
>   /sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger
> 
> Creating and displaying a histogram based on those events is now just
> a matter of using the fields and new synthetic event in the
> tracing/events/synthetic directory, as usual:
> 
> # echo 'hist:keys=pid,prio:sort=pid,prio' >> \
>   /sys/kernel/debug/tracing/events/synthetic/wakeup_new_test/trigger
> 
> Signed-off-by: Tom Zanussi 
> ---

[SNIP]
>  static void hist_trigger_elt_data_free(struct tracing_map_elt *elt)
>  {
> + struct hist_trigger_data *hist_data = elt->map->private_data;
>   struct hist_elt_data *private_data = elt->private_data;
> + unsigned int i, n_str;
> +
> + n_str = hist_data->n_field_var_str;
> +
> + for (i = 0; i < n_str; i++)
> + kfree(private_data->field_var_str[i]);
>  
>   kfree(private_data->comm);
>   kfree(private_data);
> @@ -1537,7 +1627,7 @@ static int hist_trigger_elt_data_alloc(struct 
> tracing_map_elt *elt)
>   unsigned int size = TASK_COMM_LEN + 1;
>   struct hist_elt_data *elt_data;
>   struct hist_field *key_field;
> - unsigned int i;
> + unsigned int i, n_str;
>  
>   elt->private_data = elt_data = kzalloc(sizeof(*elt_data), GFP_KERNEL);
>   if (!elt_data)
> @@ -1557,6 +1647,16 @@ static int hist_trigger_elt_data_alloc(struct 
> tracing_map_elt *elt)
>   }
>   }
>  
> + n_str = hist_data->n_field_var_str;
> +
> + for (i = 0; i < n_str; i++) {
> + elt_data->field_var_str[i] = kzalloc(size, GFP_KERNEL);

So the max length of a string variable is TASK_COMM_LEN, right?

In addition, isn't it necessary for hist_trigger_elt_data_copy() to
copy the field_var_str array?


> + if (!elt_data->field_var_str[i]) {
> + hist_trigger_elt_data_free(elt);
> + return -ENOMEM;
> + }
> + }
> +
>   return 0;
>  }

[SNIP]
> +static bool compatible_keys(struct hist_trigger_data *target_hist_data,
> + struct hist_trigger_data *hist_data,
> + unsigned int n_keys)
> +{
> + struct hist_field *target_hist_field, *hist_field;
> + unsigned int n, i, j;
> +
> + if (hist_data->n_fields - hist_data->n_vals != n_keys)
> + return false;
> +
> + i = hist_data->n_vals;
> + j = target_hist_data->n_vals;
> +
> + for (n = 0; n < n_keys; n++) {
> + hist_field = hist_data->fields[i + n];
> + target_hist_field = hist_data->fields[j + n];

Shouldn't it be 'target_hist_field = target_hist_data->fields[j + n]'?
 

> +
> + if (strcmp(hist_field->type, target_hist_field->type) != 0)
> + return false;
> + if (hist_field->size != target_hist_field->size)
> + return false;
> + if (hist_field->is_signed != target_hist_field->is_signed)
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static struct hist_trigger_data *
> +find_compatible_hist(struct hist_trigger_data *target_hist_data,
> +  struct trace_event_file *file)
> +{
> + struct hist_trigger_data *hist_data;
> + struct event_trigger_data *test;
> + unsigned int n_keys;
> +
> + n_keys = target_hist_data->n_fields - target_hist_data->n_vals;
> +
> + list_for_each_entry_rcu(test, &file->triggers, list) {
> + if (test->cmd_ops->trigger_type == ETT_EVENT_HIST) {
> + hist_data = test->private_data;
> +
> +

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

[Daniel Micay]

It was known that there are going to be bugs to work through, many of
them relatively benign like the leaks of data near string constants
(probably other string constants) in rodata. It makes sense to have it
default to WARN with BUG / noreturn as a non-default configuration
option for it, I guess with !COMPILE_TEST like UBSAN_SANITIZE_ALL. I
don't think there's any sane way to bound the length of either reads /
writes. It needs to either WARN + continue on into doing the overflow or
use BUG. Trying to correct it might make things worse and would make
this more complicated / bug-prone. It already has enough subtle edge
cases to deal with.

I think 'benign' is a better term than 'false positive' because there
hasn't been a non-bug found yet. They're mostly not security vulns but
they're undefined behavior.

Re: USB disk speed regression WD Elements - with bisect result 22547c4cc4fe20698a6a85a55b8788859134b8e4

[Guenter Roeck]

On 07/25/2017 12:50 PM, Alan Stern wrote:

On Tue, 25 Jul 2017, Zdenek Kabelac wrote:


Dne 25.7.2017 v 19:02 Alan Stern napsal(a):

On Tue, 25 Jul 2017, Zdenek Kabelac wrote:


And in fact it's the very same commit - which adds this message
(just check current 4.13 with and without this commit reverted)

So here goes usbmon trace (aka  'cat /sys/kernel/debug/usb/usbmon/0u')
no other usb device has been touch so should not hopefully interfere here.

Trace is from 4.12 kernel - so it has reported  "not running at top speed"


Can you collect an equivalent trace under 4.8?

Alan Stern



Hi


Sure - no pb.

Just attached & detached  USB disk in this trace


This is really peculiar.  The only difference is that the 4.12 trace
shows an extra 250 ms delay (including two extra Get-Port-Status


Most likely we are now catching the long reset timeout. HUB_LONG_RESET_TIME
is 200 ms. It looks like the code is catching exactly the condition
addressed in my patch, ie USB_PORT_STAT_RESET is cleared but
USB_PORT_STAT_CONNECTION is not yet set. hub_port_wait_reset() will
now wait for USB_PORT_STAT_CONNECTION, which it didn't do before.


requests) compared to the 4.8 trace.  I honestly can't tell what could
be causing the switch from high speed to full speed, or why it would
happen in one case but not the other.



We talked about this today. What is causing the switch from high speed to
full speed ? Is this triggered by the kernel, or by the USB controller ?

If it is triggered by the USB controller, maybe the changed timing around
repeated hub resets, either in combination with an additional hub reset
or in combination with fewer resets, results in the full speed connection.
That is just a wild guess, of course.

Guenter


It's obvious that _something_ is confusing the USB hardware in the disk
drive.  This shows up in both traces: After you unplug and replug the
drive, it initially connects at high-speed and then disconnects itself
before the computer can communicate with it.  Then a second connection
occurs.  For example, in the 4.8 log:

08:18 usb 2-2: USB disconnect, device number 2
08:25 usb 2-2: new high-speed USB device number 3 using ehci-pci
08:26 usb 2-2: new high-speed USB device number 4 using ehci-pci

If the drive were working entirely correctly, it wouldn't do that.
 > We could continue futzing around with hardware and driver tests for a
long time.  But there may be a shortcut: If you have a USB hub, you
could try attaching the drive through it.  It's entirely possible that
this will fix the problem.

If not, you'll have to start doing some very detailed tests.  As a
start, you can enable debugging for the usbcore and ehci_hcd drivers
immediately before the test:

echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module ehci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
dmesg -C

Then after the test, see what shows up in the dmesg output.  And again,
we'll want to do a comparison.  In fact, 4.12 with and without the
commit you identified would make a better comparison than 4.12 vs. 4.8.

Alan Stern

Re: [PATCH] usb: dts: fix the issue that usb is not detected on ls1088ardb

[Shawn Guo]

On Thu, Jul 20, 2017 at 10:38:26AM +0800, yinbo@nxp.com wrote:
> From: "yinbo.zhu" 
> 
> Signed-off-by: yinbo.zhu 

The subject should be prefixed like 'arm64: dts: ls1088a: ...'.  And
the current subject is confusing.  You are adding USB support rather
than fixing something.

Also empty commit log is not really good.

> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts |  8 
>  arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 18 ++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts 
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> index e9276a5..d5c3d96 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> @@ -149,6 +149,14 @@
>   status = "okay";
>  };
>  
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> +
>  &emdio1 {
>   /* Freescale F104 PHY1 */
>   mdio1_phy1: emdio1_phy@1 {

What tree is your patch generated against?  I do not see this 'emdio1'
device in my tree.

Remember to sort the node alphabetically in label name when adding new
labelled nodes.

> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index 3a3be87..65b3059 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -566,6 +566,24 @@
>   fsl,qspi-has-second-chip;
>   };
>  
> + usb0: usb3@310 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x310 0x0 0x1>;
> + interrupts = <0 80 0x4>; /* Level high type */

Use IRQ_TYPE_LEVEL_HIGH, so that you can save the comment here.

> + dr_mode = "host";
> + configure-gfladj;

What is this property?

Shawn

> + snps,dis_rxdet_inp3_quirk;
> + };
> +
> + usb1: usb3@311 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x311 0x0 0x1>;
> + interrupts = <0 81 0x4>; /* Level high type */
> + dr_mode = "host";
> + configure-gfladj;
> + snps,dis_rxdet_inp3_quirk;
> + };
> +
>   pcie@340 {
>   compatible = "fsl,ls2088a-pcie", "fsl,ls1088a-pcie",
>"snps,dw-pcie";
> -- 
> 2.1.0.27.g96db324
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v12 6/8] mm: support reporting free page blocks

[Wei Wang]

On 07/25/2017 10:53 PM, Michal Hocko wrote:

On Tue 25-07-17 14:47:16, Wang, Wei W wrote:

On Tuesday, July 25, 2017 8:42 PM, hal Hocko wrote:

On Tue 25-07-17 19:56:24, Wei Wang wrote:

On 07/25/2017 07:25 PM, Michal Hocko wrote:

On Tue 25-07-17 17:32:00, Wei Wang wrote:

On 07/24/2017 05:00 PM, Michal Hocko wrote:

On Wed 19-07-17 20:01:18, Wei Wang wrote:

On 07/19/2017 04:13 PM, Michal Hocko wrote:

[...

We don't need to do the pfn walk in the guest kernel. When the API
reports, for example, a 2MB free page block, the API caller offers to
the hypervisor the base address of the page block, and size=2MB, to
the hypervisor.

So you want to skip pfn walks by regularly calling into the page allocator to
update your bitmap. If that is the case then would an API that would allow you
to update your bitmap via a callback be s sufficient? Something like
void walk_free_mem(int node, int min_order,
void (*visit)(unsigned long pfn, unsigned long 
nr_pages))

The function will call the given callback for each free memory block on the 
given
node starting from the given min_order. The callback will be strictly an atomic
and very light context. You can update your bitmap from there.

I would need to introduce more about the background here:
The hypervisor and the guest live in their own address space. The hypervisor's 
bitmap
isn't seen by the guest. I think we also wouldn't be able to give a callback 
function
from the hypervisor to the guest in this case.

How did you plan to use your original API which export struct page array
then?



That's where the virtio-balloon driver comes in. It uses a shared ring 
mechanism to

send the guest memory info to the hypervisor.

We didn't expose the struct page array from the guest to the hypervisor. 
For example, when
a 2MB free page block is reported from the free page list, the info put 
on the ring is just

(base address of the 2MB continuous memory, size=2M).





This would address my main concern that the allocator internals would get
outside of the allocator proper.

What issue would it have to expose the internal, for_each_zone()?

zone is a MM internal concept. No code outside of the MM proper should
really care about zones.


I think this is also what Andrew suggested in the previous discussion:
https://lkml.org/lkml/2017/3/16/951

Move the code to virtio-balloon and a little layering violation seems 
acceptable.



Best,
Wei

Re: [PATCH v2] hwmon: (it87) Reapply probe path chip registers settings after resume

[Guenter Roeck]

On 07/24/2017 12:37 PM, Maciej S. Szmigiero wrote:

After a suspend / resume cycle we possibly need to reapply chip registers
settings that we had set or fixed in a probe path, since they might have
been reset to default values or set incorrectly by a BIOS again.

Tested on a Gigabyte M720-US3 board, which requires routing internal VCCH5V
to in7 (and had it wrong again on resume from S3).

Signed-off-by: Maciej S. Szmigiero 
---
Changes from v1: Move code of common probe / resume steps to new functions
so we don't need to make large parts of probe function conditional on a
newly added 'resume' parameter.



Much better. Please split cleanup and pm functionality addition into two patches
to simplify review. More comments inline.


  drivers/hwmon/it87.c | 214 +++
  1 file changed, 163 insertions(+), 51 deletions(-)

diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c
index 4dfc7238313e..b565e29c405c 100644
--- a/drivers/hwmon/it87.c
+++ b/drivers/hwmon/it87.c
@@ -497,6 +497,7 @@ static const struct it87_devices it87_devices[] = {
  #define has_vin3_5v(data) ((data)->features & FEAT_VIN3_5V)
  
  struct it87_sio_data {

+   int sioaddr;
enum chips type;
/* Values read from Super-I/O config space */
u8 revision;
@@ -517,6 +518,7 @@ struct it87_sio_data {
   */
  struct it87_data {
const struct attribute_group *groups[7];
+   int sioaddr;
enum chips type;
u32 features;
u8 peci_mask;
@@ -2389,10 +2391,11 @@ static const struct attribute_group it87_group_auto_pwm 
= {
  };
  
  /* SuperIO detection - will change isa_address if a chip is found */

-static int __init it87_find(int sioaddr, unsigned short *address,
+static int __init it87_find(unsigned short *address,
struct it87_sio_data *sio_data)
  {
int err;
+   int sioaddr = sio_data->sioaddr;
u16 chip_type;
const char *board_vendor, *board_name;
const struct it87_devices *config;
@@ -2828,13 +2831,89 @@ static int __init it87_find(int sioaddr, unsigned short 
*address,
return err;
  }
  
+/*

+ * Some chips seem to have default value 0xff for all limit
+ * registers. For low voltage limits it makes no sense and triggers
+ * alarms, so change to 0 instead. For high temperature limits, it
+ * means -1 degree C, which surprisingly doesn't trigger an alarm,
+ * but is still confusing, so change to 127 degrees C.
+ */
+static void it87_check_limit_regs(struct it87_data *data)
+{
+   int i, reg;
+
+   for (i = 0; i < NUM_VIN_LIMIT; i++) {
+   reg = it87_read_value(data, IT87_REG_VIN_MIN(i));
+   if (reg == 0xff)
+   it87_write_value(data, IT87_REG_VIN_MIN(i), 0);
+   }
+   for (i = 0; i < NUM_TEMP_LIMIT; i++) {
+   reg = it87_read_value(data, IT87_REG_TEMP_HIGH(i));
+   if (reg == 0xff)
+   it87_write_value(data, IT87_REG_TEMP_HIGH(i), 127);
+   }
+}
+
+/* Check if voltage monitors are reset manually or by some reason */
+static void it87_check_voltage_monitors_reset(struct it87_data *data)
+{
+   int reg;
+
+   reg = it87_read_value(data, IT87_REG_VIN_ENABLE);
+   if ((reg & 0xff) == 0) {
+   /* Enable all voltage monitors */
+   it87_write_value(data, IT87_REG_VIN_ENABLE, 0xff);
+   }
+}
+
+/* Check if tachometers are reset manually or by some reason */
+static void it87_check_tachometers_reset(struct platform_device *pdev)
+{
+   struct it87_sio_data *sio_data = dev_get_platdata(&pdev->dev);
+   struct it87_data *data = platform_get_drvdata(pdev);
+   u8 mask, fan_main_ctrl;
+
+   mask = 0x70 & ~(sio_data->skip_fan << 4);
+   fan_main_ctrl = it87_read_value(data, IT87_REG_FAN_MAIN_CTRL);
+   if ((fan_main_ctrl & mask) == 0) {
+   /* Enable all fan tachometers */
+   fan_main_ctrl |= mask;
+   it87_write_value(data, IT87_REG_FAN_MAIN_CTRL,
+fan_main_ctrl);
+   }
+}
+
+/* Set tachometers to 16-bit mode if needed */
+static void it87_check_tachometers_16bit_mode(struct platform_device *pdev)
+{
+   struct it87_data *data = platform_get_drvdata(pdev);
+   int reg;
+
+   if (!has_fan16_config(data))
+   return;
+
+   reg = it87_read_value(data, IT87_REG_FAN_16BIT);
+   if (~reg & 0x07 & data->has_fan) {
+   dev_dbg(&pdev->dev,
+   "Setting fan1-3 to 16-bit mode\n");
+   it87_write_value(data, IT87_REG_FAN_16BIT,
+reg | 0x07);
+   }
+}
+
+static void it87_start_monitoring(struct it87_data *data)
+{
+   it87_write_value(data, IT87_REG_CONFIG,
+(it87_read_value(data, IT87_REG_CONFIG) & 0x3e)
+| (update_vbat ? 0x41 : 0x01));
+}
+
  /* Called when we have found a new IT87. */
  sta

[PATCH 1/3] ARM: dts: am335x-evm: Enable NAND dma prefetch by default

[Franklin S Cooper Jr]

Currently the default method of prefetch polled shows the highest
possible read and write speed when minimal non NAND background
activity is being done. But it is also very CPU intensive to reach
these high speeds (CPU load of 99% via mtd performance tests). While
DMA prefetch only uses 50% of the CPU to achieve around 23% less in
top read and write performance.

However, as the non NAND CPU load increases the read and write
performance takes a large hit when using polled prefetch. Therefore,
prefetch dma mode ends up outperforming prefetch polled in general
"system level" test. So switch to using dma prefetch by default since
it is likely what most users would prefer.

Signed-off-by: Franklin S Cooper Jr 
---
 arch/arm/boot/dts/am335x-evm.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 1c37a7c..ddd8975 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -531,6 +531,7 @@
interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
 <1 IRQ_TYPE_NONE>; /* termcount */
rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
+   ti,nand-xfer-type = "prefetch-dma";
ti,nand-ecc-opt = "bch8";
ti,elm-id = <&elm>;
nand-bus-width = <8>;
-- 
2.10.0