[PATCH v3 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Rick Chang]

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
This patch depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/
---
 arch/arm/boot/dts/mt2701.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8f13c70..4dd5048 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
power-domains = < MT2701_POWER_DOMAIN_ISP>;
};
 
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
-- 
1.9.1

[PATCH v3 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Rick Chang]

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
This patch depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/
---
 arch/arm/boot/dts/mt2701.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8f13c70..4dd5048 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
power-domains = < MT2701_POWER_DOMAIN_ISP>;
};
 
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
-- 
1.9.1

[PATCH v3 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Add a DT binding documentation for Mediatek JPEG Decoder of
MT2701 SoC.

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 .../bindings/media/mediatek-jpeg-codec.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt 
b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
new file mode 100644
index 000..b2b19ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
@@ -0,0 +1,35 @@
+* Mediatek JPEG Decoder
+
+Mediatek JPEG Decoder is the JPEG decode hw present in Mediatek SoCs
+
+Required properties:
+- compatible : "mediatek,mt2701-jpgdec"
+- reg : physical base address of the jpeg decoder registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgdec-smi" and "jpgdec".
+- power-domains: a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current Socs, see
+  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+  for details.
+- iommus: should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+
+Example:
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
-- 
1.9.1

[PATCH v3 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Add a DT binding documentation for Mediatek JPEG Decoder of
MT2701 SoC.

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 .../bindings/media/mediatek-jpeg-codec.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt 
b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
new file mode 100644
index 000..b2b19ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
@@ -0,0 +1,35 @@
+* Mediatek JPEG Decoder
+
+Mediatek JPEG Decoder is the JPEG decode hw present in Mediatek SoCs
+
+Required properties:
+- compatible : "mediatek,mt2701-jpgdec"
+- reg : physical base address of the jpeg decoder registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgdec-smi" and "jpgdec".
+- power-domains: a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current Socs, see
+  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+  for details.
+- iommus: should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+
+Example:
+   jpegdec: jpegdec@15004000 {
+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
-- 
1.9.1

[PATCH v3 2/3] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

[Rick Chang]

Add v4l2 driver for Mediatek JPEG Decoder

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/Kconfig   |   15 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-jpeg/Makefile |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c  | 1271 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h  |  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c|  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h|   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h |   25 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h   |   58 +
 10 files changed, 2182 insertions(+)
 create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..96c9887 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,21 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_JPEG
+   tristate "Mediatek JPEG Codec driver"
+   depends on MTK_IOMMU_V1 || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ Mediatek jpeg codec driver provides HW capability to decode
+ JPEG format
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-jpeg
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..cf701e3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
new file mode 100644
index 000..b2e6069
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -0,0 +1,2 @@
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
new file mode 100644
index 000..64a2044
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -0,0 +1,1271 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai 
+ * Rick Chang 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_core.h"
+#include "mtk_jpeg_parse.h"
+
+static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+   {
+   .name   = "JPEG JFIF",
+   .fourcc = V4L2_PIX_FMT_JPEG,
+   .colplanes  = 1,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+   },
+   {
+   .name   = "YUV 4:2:0 non-contiguous 3-planar, Y/Cb/Cr",
+   .fourcc = V4L2_PIX_FMT_YUV420M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 2, 2},
+   .colplanes  = 3,
+   .h_align= 5,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+   },
+   {
+   .name   = "YUV 4:2:2 non-contiguous 3-planar, 

[PATCH v3 2/3] vcodec: mediatek: Add Mediatek JPEG Decoder Driver

[Rick Chang]

Add v4l2 driver for Mediatek JPEG Decoder

Signed-off-by: Rick Chang 
Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/Kconfig   |   15 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-jpeg/Makefile |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c  | 1271 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h  |  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c|  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h|   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h |   25 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h   |   58 +
 10 files changed, 2182 insertions(+)
 create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..96c9887 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,21 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_JPEG
+   tristate "Mediatek JPEG Codec driver"
+   depends on MTK_IOMMU_V1 || COMPILE_TEST
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on HAS_DMA
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   ---help---
+ Mediatek jpeg codec driver provides HW capability to decode
+ JPEG format
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-jpeg
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..cf701e3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
new file mode 100644
index 000..b2e6069
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -0,0 +1,2 @@
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
new file mode 100644
index 000..64a2044
--- /dev/null
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -0,0 +1,1271 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Ming Hsiu Tsai 
+ * Rick Chang 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_core.h"
+#include "mtk_jpeg_parse.h"
+
+static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+   {
+   .name   = "JPEG JFIF",
+   .fourcc = V4L2_PIX_FMT_JPEG,
+   .colplanes  = 1,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+   },
+   {
+   .name   = "YUV 4:2:0 non-contiguous 3-planar, Y/Cb/Cr",
+   .fourcc = V4L2_PIX_FMT_YUV420M,
+   .h_sample   = {4, 2, 2},
+   .v_sample   = {4, 2, 2},
+   .colplanes  = 3,
+   .h_align= 5,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+   },
+   {
+   .name   = "YUV 4:2:2 non-contiguous 3-planar, Y/Cb/Cr",
+   .fourcc = V4L2_PIX_FMT_YUV422M,
+   .h_sample   = {4, 2, 2},
+   

[PATCH v3 0/3] Add Mediatek JPEG Decoder

[Rick Chang]

This series of patches provide a v4l2 driver to control Mediatek JPEG decoder
for decoding JPEG image and Motion JPEG bitstream.

changes since v2:
- Revise DT binding documentation 

changes since v1:
- Rebase for v4.9-rc1.
- Update Compliance test version and result
- Remove redundant path in Makefile
- Fix potential build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
- Fix warnings from patch check and smatch check

* Dependency
The patch "arm: dts: mt2701: Add node for JPEG decoder" depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/

* Compliance test
v4l2-compliance SHA   : 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a

Driver Info:
Driver name   : mtk-jpeg decode
Card type : mtk-jpeg decoder
Bus info  : platform:15004000.jpegdec
Driver version: 4.9.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0

Rick Chang (3):
  dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
  vcodec: mediatek: Add Mediatek JPEG Decoder Driver
  arm: dts: mt2701: Add node for Mediatek JPEG Decoder

 .../bindings/media/mediatek-jpeg-codec.txt |   35 +
 arch/arm/boot/dts/mt2701.dtsi  |   14 +
 drivers/media/platform/Kconfig |   15 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/mtk-jpeg/Makefile   |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c| 1271 
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h|  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c  |  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h  |   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c   |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h   

[PATCH v3 0/3] Add Mediatek JPEG Decoder

[Rick Chang]

This series of patches provide a v4l2 driver to control Mediatek JPEG decoder
for decoding JPEG image and Motion JPEG bitstream.

changes since v2:
- Revise DT binding documentation 

changes since v1:
- Rebase for v4.9-rc1.
- Update Compliance test version and result
- Remove redundant path in Makefile
- Fix potential build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
- Fix warnings from patch check and smatch check

* Dependency
The patch "arm: dts: mt2701: Add node for JPEG decoder" depends on: 
  CCF "Add clock support for Mediatek MT2701"[1]
  iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/

* Compliance test
v4l2-compliance SHA   : 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a

Driver Info:
Driver name   : mtk-jpeg decode
Card type : mtk-jpeg decoder
Bus info  : platform:15004000.jpegdec
Driver version: 4.9.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video3 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0

Rick Chang (3):
  dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
  vcodec: mediatek: Add Mediatek JPEG Decoder Driver
  arm: dts: mt2701: Add node for Mediatek JPEG Decoder

 .../bindings/media/mediatek-jpeg-codec.txt |   35 +
 arch/arm/boot/dts/mt2701.dtsi  |   14 +
 drivers/media/platform/Kconfig |   15 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/mtk-jpeg/Makefile   |2 +
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c| 1271 
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h|  141 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c  |  417 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h  |   91 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c   |  160 +++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h   

[PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n

[Michael Ellerman]

Currently the kconfig logic for VFIO_IOMMU_SPAPR_TCE and VFIO_SPAPR_EEH
is broken when SPAPR_TCE_IOMMU=n. Leading to:

warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct 
dependencies (VFIO && SPAPR_TCE_IOMMU)
warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct 
dependencies (VFIO && SPAPR_TCE_IOMMU)
drivers/vfio/vfio_iommu_spapr_tce.c:113:8: error: implicit declaration of 
function 'mm_iommu_find'

This stems from the fact that VFIO selects VFIO_IOMMU_SPAPR_TCE, and
although it has an if clause, the condition is not correct.

We could fix it by doing select VFIO_IOMMU_SPAPR_TCE if SPAPR_TCE_IOMMU,
but the cleaner fix is to drop the selects and tie VFIO_IOMMU_SPAPR_TCE
to the value of VFIO, and express the dependencies in only once place.

Do the same for VFIO_SPAPR_EEH.

The end result is that the values of VFIO_IOMMU_SPAPR_TCE and
VFIO_SPAPR_EEH follow the value of VFIO, except when SPAPR_TCE_IOMMU=n
and/or EEH=n. Which is exactly what we want to happen.

Signed-off-by: Michael Ellerman 
---
 drivers/vfio/Kconfig | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index da6e2ce77495..6b51a4ebed8a 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -6,12 +6,12 @@ config VFIO_IOMMU_TYPE1
 config VFIO_IOMMU_SPAPR_TCE
tristate
depends on VFIO && SPAPR_TCE_IOMMU
-   default n
+   default VFIO
 
 config VFIO_SPAPR_EEH
tristate
depends on EEH && VFIO_IOMMU_SPAPR_TCE
-   default n
+   default VFIO
 
 config VFIO_VIRQFD
tristate
@@ -22,8 +22,6 @@ menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3)
-   select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES)
-   select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES)
select ANON_INODES
help
  VFIO provides a framework for secure userspace device drivers.
-- 
2.7.4

[PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n

[Michael Ellerman]

Currently the kconfig logic for VFIO_IOMMU_SPAPR_TCE and VFIO_SPAPR_EEH
is broken when SPAPR_TCE_IOMMU=n. Leading to:

warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct 
dependencies (VFIO && SPAPR_TCE_IOMMU)
warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct 
dependencies (VFIO && SPAPR_TCE_IOMMU)
drivers/vfio/vfio_iommu_spapr_tce.c:113:8: error: implicit declaration of 
function 'mm_iommu_find'

This stems from the fact that VFIO selects VFIO_IOMMU_SPAPR_TCE, and
although it has an if clause, the condition is not correct.

We could fix it by doing select VFIO_IOMMU_SPAPR_TCE if SPAPR_TCE_IOMMU,
but the cleaner fix is to drop the selects and tie VFIO_IOMMU_SPAPR_TCE
to the value of VFIO, and express the dependencies in only once place.

Do the same for VFIO_SPAPR_EEH.

The end result is that the values of VFIO_IOMMU_SPAPR_TCE and
VFIO_SPAPR_EEH follow the value of VFIO, except when SPAPR_TCE_IOMMU=n
and/or EEH=n. Which is exactly what we want to happen.

Signed-off-by: Michael Ellerman 
---
 drivers/vfio/Kconfig | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index da6e2ce77495..6b51a4ebed8a 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -6,12 +6,12 @@ config VFIO_IOMMU_TYPE1
 config VFIO_IOMMU_SPAPR_TCE
tristate
depends on VFIO && SPAPR_TCE_IOMMU
-   default n
+   default VFIO
 
 config VFIO_SPAPR_EEH
tristate
depends on EEH && VFIO_IOMMU_SPAPR_TCE
-   default n
+   default VFIO
 
 config VFIO_VIRQFD
tristate
@@ -22,8 +22,6 @@ menuconfig VFIO
tristate "VFIO Non-Privileged userspace driver framework"
depends on IOMMU_API
select VFIO_IOMMU_TYPE1 if (X86 || S390 || ARM_SMMU || ARM_SMMU_V3)
-   select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES)
-   select VFIO_SPAPR_EEH if (PPC_POWERNV || PPC_PSERIES)
select ANON_INODES
help
  VFIO provides a framework for secure userspace device drivers.
-- 
2.7.4

Re: [PATCH 1/3] clk: keystone: Fix an error checking

[Christophe JAILLET]

Le 02/11/2016 à 01:22, Stephen Boyd a écrit :

On 10/24, Christophe JAILLET wrote:

clk_register_pll() can return ERR_PTR(-ENOMEM) so checking the return value
against NULL only is not correct.

The code just doesn't propagate the error up to the caller.
Instead the caller treats NULL as an error and non-NULL as valid.
If the callee detects an error it hides it and returns NULL.


Could you please clarify?
I thought that your point was that 'clk_register_pll()' was returning 
NULL when 'clk_register()' was returning an error.

The proposed patch fixes it and now 'clk_register_pll()' returns:
   - either  ERR_PTR(-ENOMEM) if zkalloc fails
   - or clk if 'clk_register()' fails. In this case it is an error pointer
   - or a valid, non NULL, pointer in case of success

The caller, '_of_pll_clk_init()' has also been updated to test the 
return value using IS_ERR.



So, which caller/callee do you refer to?
Would you like '_of_pll_clk_init()' to also propagate the error?

Or is it the phrasing of the log entry which is not clear enough and 
should be updated?





In order to fix it, update clk_register_pll() to always return an error
pointer in case of error and check the return value with IS_ERR.

While at it, also fix a tab vs space in the surrounding code.

Signed-off-by: Christophe JAILLET 
---
Un-compiled and un-tested.

Please at least compile test patches.

Agreed, and I usually do.
But in this particular case, I don't have the build environment to do it.

I preferred to report what looks like a (small) bug to me and clearly 
state that I didn't even compile-tested it rather than just ignoring it.

Hoping that this approach, in such a case, is acceptable.

CJ

Re: [PATCH 1/3] clk: keystone: Fix an error checking

[Christophe JAILLET]

Le 02/11/2016 à 01:22, Stephen Boyd a écrit :

On 10/24, Christophe JAILLET wrote:

clk_register_pll() can return ERR_PTR(-ENOMEM) so checking the return value
against NULL only is not correct.

The code just doesn't propagate the error up to the caller.
Instead the caller treats NULL as an error and non-NULL as valid.
If the callee detects an error it hides it and returns NULL.


Could you please clarify?
I thought that your point was that 'clk_register_pll()' was returning 
NULL when 'clk_register()' was returning an error.

The proposed patch fixes it and now 'clk_register_pll()' returns:
   - either  ERR_PTR(-ENOMEM) if zkalloc fails
   - or clk if 'clk_register()' fails. In this case it is an error pointer
   - or a valid, non NULL, pointer in case of success

The caller, '_of_pll_clk_init()' has also been updated to test the 
return value using IS_ERR.



So, which caller/callee do you refer to?
Would you like '_of_pll_clk_init()' to also propagate the error?

Or is it the phrasing of the log entry which is not clear enough and 
should be updated?





In order to fix it, update clk_register_pll() to always return an error
pointer in case of error and check the return value with IS_ERR.

While at it, also fix a tab vs space in the surrounding code.

Signed-off-by: Christophe JAILLET 
---
Un-compiled and un-tested.

Please at least compile test patches.

Agreed, and I usually do.
But in this particular case, I don't have the build environment to do it.

I preferred to report what looks like a (small) bug to me and clearly 
state that I didn't even compile-tested it rather than just ignoring it.

Hoping that this approach, in such a case, is acceptable.

CJ

Re: linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Stephen Rothwell]

Hi Liviu,

On Thu, 3 Nov 2016 17:19:58 + Liviu Dudau  wrote:
>
> I have revamped the mali-dp tree and rebased it on the newer
> version of drm-next (which includes the drm-misc change) and pushed the
> updated patch in my tree.

Thanks for that.  However, several of the commits in your tree now have
no Signed-off-by from you as the committer :-(

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Stephen Rothwell]

Hi Liviu,

On Thu, 3 Nov 2016 17:19:58 + Liviu Dudau  wrote:
>
> I have revamped the mali-dp tree and rebased it on the newer
> version of drm-next (which includes the drm-misc change) and pushed the
> updated patch in my tree.

Thanks for that.  However, several of the commits in your tree now have
no Signed-off-by from you as the committer :-(

-- 
Cheers,
Stephen Rothwell

Re: [PATCH 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx

[Sekhar Nori]

Hi Kishon,

On Thursday 03 November 2016 10:20 PM, Kishon Vijay Abraham I wrote:
> 
> 
> On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote:
>> There is only one ohci on the da8xx series of chips,
>> so remove the ".0" when creating the phy. Also add
>> the "-da8xx" postfix to be consistent across davinci
>> usb drivers.
>>
>> Signed-off-by: Axel Haslam 
> 
> Acked-by: Kishon Vijay Abraham I 

You will have to carry this patch from your tree. I thought I can carry
the entire series, but the USB patch depends on other patches that Greg
has already queued. So I think its best if the individual patches go
through their respective trees.

Note that there is a v2 already submitted.

Thanks,
Sekhar

Re: [PATCH 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx

[Sekhar Nori]

Hi Kishon,

On Thursday 03 November 2016 10:20 PM, Kishon Vijay Abraham I wrote:
> 
> 
> On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote:
>> There is only one ohci on the da8xx series of chips,
>> so remove the ".0" when creating the phy. Also add
>> the "-da8xx" postfix to be consistent across davinci
>> usb drivers.
>>
>> Signed-off-by: Axel Haslam 
> 
> Acked-by: Kishon Vijay Abraham I 

You will have to carry this patch from your tree. I thought I can carry
the entire series, but the USB patch depends on other patches that Greg
has already queued. So I think its best if the individual patches go
through their respective trees.

Note that there is a v2 already submitted.

Thanks,
Sekhar

RE: [PATCH v2] arc: Implement arch-specific dma_map_ops.mmap

[Alexey Brodkin]

Hi Vineet,

> -Original Message-
> From: Vineet Gupta [mailto:vgu...@synopsys.com]
> Sent: Thursday, November 03, 2016 8:04 PM
> To: Alexey Brodkin ; 
> linux-snps-...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; Vineet Gupta 
> ; Marek Szyprowski
> ; sta...@vger.kernel.org
> Subject: Re: [PATCH v2] arc: Implement arch-specific dma_map_ops.mmap
> 
> On 11/03/2016 08:06 AM, Alexey Brodkin wrote:
> > We used to use generic implementation of dma_map_ops.mmap which is
> > dma_common_mmap() but that only worked for simpler cached mappings when
> > vaddr = paddr.
> >
> > If a driver requests uncached DMA buffer kernel maps it to virtual
> > address so that MMU gets involved and page uncached status takes into
> > account. In that case usage of dma_common_mmap() lead to mapping of
> > vaddr to vaddr for user-space which is obviously wrong. For more detals
> > please refer to verbose explanation here [1].
> >
> > So here we implement our own version of mmap() which always deals
> > with dma_addr and maps underlying memory to user-space properly
> > (note that DMA buffer mapped to user-space is always uncached
> > because there's no way to properly manage cache from user-space).
> >
> > [1] https://lkml.org/lkml/2016/10/26/973
> >
> > Signed-off-by: Alexey Brodkin 
> > Reviewed-by: Catalin Marinas 
> > Cc: Marek Szyprowski 
> > Cc: Vineet Gupta 
> > Cc: 
> 
> I've added a stable 4.5+, since ARC didn't use dma ops until 4.5-rc1.

Again I was hitting a strange problem when sending patch via "git send-email" to
address " # 3.3.x". Mail server complains on wrong 
email.
Thus I settled to just mention sta...@vger.kernel.org.

Anyways, thanks for doing that!

-Alexey

RE: [PATCH v2] arc: Implement arch-specific dma_map_ops.mmap

[Alexey Brodkin]

Hi Vineet,

> -Original Message-
> From: Vineet Gupta [mailto:vgu...@synopsys.com]
> Sent: Thursday, November 03, 2016 8:04 PM
> To: Alexey Brodkin ; 
> linux-snps-...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; Vineet Gupta 
> ; Marek Szyprowski
> ; sta...@vger.kernel.org
> Subject: Re: [PATCH v2] arc: Implement arch-specific dma_map_ops.mmap
> 
> On 11/03/2016 08:06 AM, Alexey Brodkin wrote:
> > We used to use generic implementation of dma_map_ops.mmap which is
> > dma_common_mmap() but that only worked for simpler cached mappings when
> > vaddr = paddr.
> >
> > If a driver requests uncached DMA buffer kernel maps it to virtual
> > address so that MMU gets involved and page uncached status takes into
> > account. In that case usage of dma_common_mmap() lead to mapping of
> > vaddr to vaddr for user-space which is obviously wrong. For more detals
> > please refer to verbose explanation here [1].
> >
> > So here we implement our own version of mmap() which always deals
> > with dma_addr and maps underlying memory to user-space properly
> > (note that DMA buffer mapped to user-space is always uncached
> > because there's no way to properly manage cache from user-space).
> >
> > [1] https://lkml.org/lkml/2016/10/26/973
> >
> > Signed-off-by: Alexey Brodkin 
> > Reviewed-by: Catalin Marinas 
> > Cc: Marek Szyprowski 
> > Cc: Vineet Gupta 
> > Cc: 
> 
> I've added a stable 4.5+, since ARC didn't use dma ops until 4.5-rc1.

Again I was hitting a strange problem when sending patch via "git send-email" to
address " # 3.3.x". Mail server complains on wrong 
email.
Thus I settled to just mention sta...@vger.kernel.org.

Anyways, thanks for doing that!

-Alexey

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

[Ravi Bangoria]

On Friday 04 November 2016 07:37 AM, Andrew Donnellan wrote:
> On 03/11/16 21:27, Ravi Bangoria wrote:
>> Yes, kernel-space hw-breakpoint feature is broken on LE without this.
>
> Is there any actual user-visible feature that depends on this, or is this 
> solely for debugging and development purposes?
>
> It would of course be *nice* to have it in stable trees (particularly so we 
> pick it up in distros) but I'm not convinced that enabling HW breakpoints on 
> a platform where it has *never* worked qualifies as an "actual bug".
>
> (BTW many thanks for fixing this - I had a shot at it late last year but 
> never quite got there!)

Thanks Andrew,

kprobe, uprobe, hw-breakpoint and xmon are the only user of emulate_step.

Kprobe / uprobe single-steps instruction if they can't emulate it, so there
is no problem with them. As I mention, hw-breakpoint is broken. However
I'm not sure about xmon, I need to check that.

So yes, there is no user-visible feature that depends on this.

-Ravi

Re: [PATCH 1/3] powerpc: Emulation support for load/store instructions on LE

[Ravi Bangoria]

On Friday 04 November 2016 07:37 AM, Andrew Donnellan wrote:
> On 03/11/16 21:27, Ravi Bangoria wrote:
>> Yes, kernel-space hw-breakpoint feature is broken on LE without this.
>
> Is there any actual user-visible feature that depends on this, or is this 
> solely for debugging and development purposes?
>
> It would of course be *nice* to have it in stable trees (particularly so we 
> pick it up in distros) but I'm not convinced that enabling HW breakpoints on 
> a platform where it has *never* worked qualifies as an "actual bug".
>
> (BTW many thanks for fixing this - I had a shot at it late last year but 
> never quite got there!)

Thanks Andrew,

kprobe, uprobe, hw-breakpoint and xmon are the only user of emulate_step.

Kprobe / uprobe single-steps instruction if they can't emulate it, so there
is no problem with them. As I mention, hw-breakpoint is broken. However
I'm not sure about xmon, I need to check that.

So yes, there is no user-visible feature that depends on this.

-Ravi

Re: [PATCH v6 0/9] Fix kdump faults on system with amd iommu

[Baoquan He]

On 11/04/16 at 01:14pm, Baoquan He wrote:
> Hi Joerg,
> 
> Ping!
> 
> About the v6 post, do you have any suggestions?
> 
> Because of GCR3 special handling in patch 9/9, I spent several days to
> study the knowledge and change code. Then when I tried to post, the
> virtual interrupt remapping feature caused kernel hang with this pachset
> applied. So it took me days to study spec and find it out. Finally it's
> very late to post.
> 
> Coule it be possibe that we review and merge patch 9/1~8, and leave the
> patch 9/9 which includes GCR3 special handling as 2nd step issue? Then
> I can back port patch 9/1~8 to our distro. Since this bug has been
> discussed so long time, and currently almost all system are deployed
> with amd iommu v1 hardware. It would be great if they can be accepted
 ~~~ Here I meant in our Redhat lab almost all
system are only deployed with amd iommu v1 support. 

> into 4.9 or 4.10-rc phase.
> 
> About patch 9/9, its code is a little complicated and not being
> reviewed, I am not sure if I understand your suggestion and GCR3 code
> well. What's your opinion?
> 
> Thanks
> Baoquan
> 
> 
> On 10/20/16 at 07:37pm, Baoquan He wrote:
> > This is v6 post. 
> > 
> > The principle of the fix is similar to intel iommu. Just defer the 
> > assignment
> > of device to domain to device driver init. But there's difference than
> > intel iommu. AMD iommu create protection domain and assign device to
> > domain in iommu driver init stage. So in this patchset I just allow the
> > assignment of device to domain in software level, but defer updating the
> > domain info, especially the pte_root to dev table entry to device driver
> > init stage.
> > 
> > v5: 
> > bnx2 NIC can't reset itself during driver init. Post patch to reset
> > it during driver init. IO_PAGE_FAULT can't be seen anymore.
> > 
> > Below is link of v5 post.
> > 
> > https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
> > 
> > v5->v6:
> > According to Joerg's comments made several below main changes:
> > - Add sanity check when copy old dev tables. 
> > 
> > - Discard the old patch 6/8.
> > 
> > - If a device is set up with guest translations (DTE.GV=1), then don't
> >   copy that information but move the device over to an empty guest-cr3
> >   table and handle the faults in the PPR log (which just answer them
> >   with INVALID).
> > 
> > Issues need be discussed:
> > - Joerg suggested hooking the behaviour that updates domain info into
> >   dte entry into the set_dma_mask call-back. I tried, but on my local
> >   machine with amd iommu v2, an ohci pci device doesn't call 
> > set_dma_mask.
> >   Then IO_PAGE_FAULT printing flooded.
> > 
> >   00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB 
> > OHCI Controller (rev 11)
> > 
> > - About GCR3 root pointer copying issue, I don't know how to setup the
> >   test environment and haven't tested yet. Hope Joerg or Zongshun can
> >   tell what steps should be taken to test it, or help take a test in 
> > your
> >   test environemnt.
> >  
> > Baoquan He (9):
> >   iommu/amd: Detect pre enabled translation
> >   iommu/amd: add several helper function
> >   iommu/amd: Define bit fields for DTE particularly
> >   iommu/amd: Add function copy_dev_tables
> >   iommu/amd: copy old trans table from old kernel
> >   iommu/amd: Don't update domain info to dte entry at iommu init stage
> >   iommu/amd: Update domain into to dte entry during device driver init
> >   iommu/amd: Add sanity check of irq remap information of old dev table
> > entry
> >   iommu/amd: Don't copy GCR3 table root pointer
> > 
> >  drivers/iommu/amd_iommu.c   |  93 +---
> >  drivers/iommu/amd_iommu_init.c  | 189 
> > +---
> >  drivers/iommu/amd_iommu_proto.h |   2 +
> >  drivers/iommu/amd_iommu_types.h |  53 ++-
> >  drivers/iommu/amd_iommu_v2.c|  18 +++-
> >  5 files changed, 307 insertions(+), 48 deletions(-)
> > 
> > -- 
> > 2.5.5
> > 

Re: [PATCH v6 0/9] Fix kdump faults on system with amd iommu

[Baoquan He]

On 11/04/16 at 01:14pm, Baoquan He wrote:
> Hi Joerg,
> 
> Ping!
> 
> About the v6 post, do you have any suggestions?
> 
> Because of GCR3 special handling in patch 9/9, I spent several days to
> study the knowledge and change code. Then when I tried to post, the
> virtual interrupt remapping feature caused kernel hang with this pachset
> applied. So it took me days to study spec and find it out. Finally it's
> very late to post.
> 
> Coule it be possibe that we review and merge patch 9/1~8, and leave the
> patch 9/9 which includes GCR3 special handling as 2nd step issue? Then
> I can back port patch 9/1~8 to our distro. Since this bug has been
> discussed so long time, and currently almost all system are deployed
> with amd iommu v1 hardware. It would be great if they can be accepted
 ~~~ Here I meant in our Redhat lab almost all
system are only deployed with amd iommu v1 support. 

> into 4.9 or 4.10-rc phase.
> 
> About patch 9/9, its code is a little complicated and not being
> reviewed, I am not sure if I understand your suggestion and GCR3 code
> well. What's your opinion?
> 
> Thanks
> Baoquan
> 
> 
> On 10/20/16 at 07:37pm, Baoquan He wrote:
> > This is v6 post. 
> > 
> > The principle of the fix is similar to intel iommu. Just defer the 
> > assignment
> > of device to domain to device driver init. But there's difference than
> > intel iommu. AMD iommu create protection domain and assign device to
> > domain in iommu driver init stage. So in this patchset I just allow the
> > assignment of device to domain in software level, but defer updating the
> > domain info, especially the pte_root to dev table entry to device driver
> > init stage.
> > 
> > v5: 
> > bnx2 NIC can't reset itself during driver init. Post patch to reset
> > it during driver init. IO_PAGE_FAULT can't be seen anymore.
> > 
> > Below is link of v5 post.
> > 
> > https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
> > 
> > v5->v6:
> > According to Joerg's comments made several below main changes:
> > - Add sanity check when copy old dev tables. 
> > 
> > - Discard the old patch 6/8.
> > 
> > - If a device is set up with guest translations (DTE.GV=1), then don't
> >   copy that information but move the device over to an empty guest-cr3
> >   table and handle the faults in the PPR log (which just answer them
> >   with INVALID).
> > 
> > Issues need be discussed:
> > - Joerg suggested hooking the behaviour that updates domain info into
> >   dte entry into the set_dma_mask call-back. I tried, but on my local
> >   machine with amd iommu v2, an ohci pci device doesn't call 
> > set_dma_mask.
> >   Then IO_PAGE_FAULT printing flooded.
> > 
> >   00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB 
> > OHCI Controller (rev 11)
> > 
> > - About GCR3 root pointer copying issue, I don't know how to setup the
> >   test environment and haven't tested yet. Hope Joerg or Zongshun can
> >   tell what steps should be taken to test it, or help take a test in 
> > your
> >   test environemnt.
> >  
> > Baoquan He (9):
> >   iommu/amd: Detect pre enabled translation
> >   iommu/amd: add several helper function
> >   iommu/amd: Define bit fields for DTE particularly
> >   iommu/amd: Add function copy_dev_tables
> >   iommu/amd: copy old trans table from old kernel
> >   iommu/amd: Don't update domain info to dte entry at iommu init stage
> >   iommu/amd: Update domain into to dte entry during device driver init
> >   iommu/amd: Add sanity check of irq remap information of old dev table
> > entry
> >   iommu/amd: Don't copy GCR3 table root pointer
> > 
> >  drivers/iommu/amd_iommu.c   |  93 +---
> >  drivers/iommu/amd_iommu_init.c  | 189 
> > +---
> >  drivers/iommu/amd_iommu_proto.h |   2 +
> >  drivers/iommu/amd_iommu_types.h |  53 ++-
> >  drivers/iommu/amd_iommu_v2.c|  18 +++-
> >  5 files changed, 307 insertions(+), 48 deletions(-)
> > 
> > -- 
> > 2.5.5
> > 

[PATCH 1/2] cpufreq: powernv: Adding fast_switch for schedutil

[Akshay Adiga]

Adding fast_switch which does light weight operation to
set the desired pstate.

Signed-off-by: Akshay Adiga 
---
 drivers/cpufreq/powernv-cpufreq.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index d3ffde8..09a0496 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -752,9 +752,12 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
spin_lock_init(>gpstate_lock);
ret = cpufreq_table_validate_and_show(policy, powernv_freqs);
 
-   if (ret < 0)
+   if (ret < 0) {
kfree(policy->driver_data);
+   return ret;
+   }
 
+   policy->fast_switch_possible = true;
return ret;
 }
 
@@ -897,6 +900,22 @@ static void powernv_cpufreq_stop_cpu(struct cpufreq_policy 
*policy)
del_timer_sync(>timer);
 }
 
+static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   int index;
+   struct powernv_smp_call_data freq_data;
+
+   index = cpufreq_table_find_index_dl(policy, target_freq);
+   if (index < 0 || index >= powernv_pstate_info.nr_pstates)
+   return CPUFREQ_ENTRY_INVALID;
+   freq_data.pstate_id = powernv_freqs[index].driver_data;
+   freq_data.gpstate_id = powernv_freqs[index].driver_data;
+   set_pstate(_data);
+
+   return powernv_freqs[index].frequency;
+}
+
 static struct cpufreq_driver powernv_cpufreq_driver = {
.name   = "powernv-cpufreq",
.flags  = CPUFREQ_CONST_LOOPS,
@@ -904,6 +923,7 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.exit   = powernv_cpufreq_cpu_exit,
.verify = cpufreq_generic_frequency_table_verify,
.target_index   = powernv_cpufreq_target_index,
+   .fast_switch= powernv_fast_switch,
.get= powernv_cpufreq_get,
.stop_cpu   = powernv_cpufreq_stop_cpu,
.attr   = powernv_cpu_freq_attr,
-- 
2.7.4

[PATCH 1/2] cpufreq: powernv: Adding fast_switch for schedutil

[Akshay Adiga]

Adding fast_switch which does light weight operation to
set the desired pstate.

Signed-off-by: Akshay Adiga 
---
 drivers/cpufreq/powernv-cpufreq.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index d3ffde8..09a0496 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -752,9 +752,12 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
spin_lock_init(>gpstate_lock);
ret = cpufreq_table_validate_and_show(policy, powernv_freqs);
 
-   if (ret < 0)
+   if (ret < 0) {
kfree(policy->driver_data);
+   return ret;
+   }
 
+   policy->fast_switch_possible = true;
return ret;
 }
 
@@ -897,6 +900,22 @@ static void powernv_cpufreq_stop_cpu(struct cpufreq_policy 
*policy)
del_timer_sync(>timer);
 }
 
+static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   int index;
+   struct powernv_smp_call_data freq_data;
+
+   index = cpufreq_table_find_index_dl(policy, target_freq);
+   if (index < 0 || index >= powernv_pstate_info.nr_pstates)
+   return CPUFREQ_ENTRY_INVALID;
+   freq_data.pstate_id = powernv_freqs[index].driver_data;
+   freq_data.gpstate_id = powernv_freqs[index].driver_data;
+   set_pstate(_data);
+
+   return powernv_freqs[index].frequency;
+}
+
 static struct cpufreq_driver powernv_cpufreq_driver = {
.name   = "powernv-cpufreq",
.flags  = CPUFREQ_CONST_LOOPS,
@@ -904,6 +923,7 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.exit   = powernv_cpufreq_cpu_exit,
.verify = cpufreq_generic_frequency_table_verify,
.target_index   = powernv_cpufreq_target_index,
+   .fast_switch= powernv_fast_switch,
.get= powernv_cpufreq_get,
.stop_cpu   = powernv_cpufreq_stop_cpu,
.attr   = powernv_cpu_freq_attr,
-- 
2.7.4

[PATCH 2/2] cpufreq: powernv: Use PMSR to verify global and local pstate

[Akshay Adiga]

As fast_switch may get called in interrupt disable mode, it does not
update the global_pstate_info data structure. Hence the global_pstate_info
has stale data whenever pstate is updated through fast_swtich().

So the gpstate_timer can fire after a fast_switch() call has update
the pstates to a different value. Hence the timer handler cannot rely
on the cached values of local and global pstate and needs to read it
from the PMSR. 

Signed-off-by: Akshay Adiga 

---
 drivers/cpufreq/powernv-cpufreq.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index 09a0496..57713b5 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -592,7 +592,8 @@ void gpstate_timer_handler(unsigned long data)
 {
struct cpufreq_policy *policy = (struct cpufreq_policy *)data;
struct global_pstate_info *gpstates = policy->driver_data;
-   int gpstate_idx;
+   int gpstate_idx, lpstate_idx;
+   unsigned long val;
unsigned int time_diff = jiffies_to_msecs(jiffies)
- gpstates->last_sampled_time;
struct powernv_smp_call_data freq_data;
@@ -600,21 +601,36 @@ void gpstate_timer_handler(unsigned long data)
if (!spin_trylock(>gpstate_lock))
return;
 
+   /*
+* If PMCR was last updated was using fast_swtich then
+* We may have wrong in gpstate->last_lpstate_idx
+* value. Hence, read from PMCR to get correct data.
+*/
+   val = get_pmspr(SPRN_PMCR);
+   freq_data.gpstate_id = (val >> (56)) & 0xFF;
+   freq_data.pstate_id = (val >> (48)) & 0xFF;
+   if (freq_data.gpstate_id  == freq_data.pstate_id) {
+   reset_gpstates(policy);
+   spin_unlock(>gpstate_lock);
+   return;
+   }
+
gpstates->last_sampled_time += time_diff;
gpstates->elapsed_time += time_diff;
-   freq_data.pstate_id = idx_to_pstate(gpstates->last_lpstate_idx);
 
-   if ((gpstates->last_gpstate_idx == gpstates->last_lpstate_idx) ||
-   (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME)) {
+   if (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME) {
gpstate_idx = pstate_to_idx(freq_data.pstate_id);
reset_gpstates(policy);
gpstates->highest_lpstate_idx = gpstate_idx;
} else {
+   lpstate_idx = pstate_to_idx(freq_data.pstate_id);
gpstate_idx = calc_global_pstate(gpstates->elapsed_time,
 gpstates->highest_lpstate_idx,
-gpstates->last_lpstate_idx);
+lpstate_idx);
}
-
+   freq_data.gpstate_id = idx_to_pstate(gpstate_idx);
+   gpstates->last_gpstate_idx = gpstate_idx;
+   gpstates->last_lpstate_idx = lpstate_idx;
/*
 * If local pstate is equal to global pstate, rampdown is over
 * So timer is not required to be queued.
@@ -622,10 +638,6 @@ void gpstate_timer_handler(unsigned long data)
if (gpstate_idx != gpstates->last_lpstate_idx)
queue_gpstate_timer(gpstates);
 
-   freq_data.gpstate_id = idx_to_pstate(gpstate_idx);
-   gpstates->last_gpstate_idx = pstate_to_idx(freq_data.gpstate_id);
-   gpstates->last_lpstate_idx = pstate_to_idx(freq_data.pstate_id);
-
spin_unlock(>gpstate_lock);
 
/* Timer may get migrated to a different cpu on cpu hot unplug */
-- 
2.7.4

[PATCH 2/2] cpufreq: powernv: Use PMSR to verify global and local pstate

[Akshay Adiga]

As fast_switch may get called in interrupt disable mode, it does not
update the global_pstate_info data structure. Hence the global_pstate_info
has stale data whenever pstate is updated through fast_swtich().

So the gpstate_timer can fire after a fast_switch() call has update
the pstates to a different value. Hence the timer handler cannot rely
on the cached values of local and global pstate and needs to read it
from the PMSR. 

Signed-off-by: Akshay Adiga 

---
 drivers/cpufreq/powernv-cpufreq.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/cpufreq/powernv-cpufreq.c 
b/drivers/cpufreq/powernv-cpufreq.c
index 09a0496..57713b5 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -592,7 +592,8 @@ void gpstate_timer_handler(unsigned long data)
 {
struct cpufreq_policy *policy = (struct cpufreq_policy *)data;
struct global_pstate_info *gpstates = policy->driver_data;
-   int gpstate_idx;
+   int gpstate_idx, lpstate_idx;
+   unsigned long val;
unsigned int time_diff = jiffies_to_msecs(jiffies)
- gpstates->last_sampled_time;
struct powernv_smp_call_data freq_data;
@@ -600,21 +601,36 @@ void gpstate_timer_handler(unsigned long data)
if (!spin_trylock(>gpstate_lock))
return;
 
+   /*
+* If PMCR was last updated was using fast_swtich then
+* We may have wrong in gpstate->last_lpstate_idx
+* value. Hence, read from PMCR to get correct data.
+*/
+   val = get_pmspr(SPRN_PMCR);
+   freq_data.gpstate_id = (val >> (56)) & 0xFF;
+   freq_data.pstate_id = (val >> (48)) & 0xFF;
+   if (freq_data.gpstate_id  == freq_data.pstate_id) {
+   reset_gpstates(policy);
+   spin_unlock(>gpstate_lock);
+   return;
+   }
+
gpstates->last_sampled_time += time_diff;
gpstates->elapsed_time += time_diff;
-   freq_data.pstate_id = idx_to_pstate(gpstates->last_lpstate_idx);
 
-   if ((gpstates->last_gpstate_idx == gpstates->last_lpstate_idx) ||
-   (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME)) {
+   if (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME) {
gpstate_idx = pstate_to_idx(freq_data.pstate_id);
reset_gpstates(policy);
gpstates->highest_lpstate_idx = gpstate_idx;
} else {
+   lpstate_idx = pstate_to_idx(freq_data.pstate_id);
gpstate_idx = calc_global_pstate(gpstates->elapsed_time,
 gpstates->highest_lpstate_idx,
-gpstates->last_lpstate_idx);
+lpstate_idx);
}
-
+   freq_data.gpstate_id = idx_to_pstate(gpstate_idx);
+   gpstates->last_gpstate_idx = gpstate_idx;
+   gpstates->last_lpstate_idx = lpstate_idx;
/*
 * If local pstate is equal to global pstate, rampdown is over
 * So timer is not required to be queued.
@@ -622,10 +638,6 @@ void gpstate_timer_handler(unsigned long data)
if (gpstate_idx != gpstates->last_lpstate_idx)
queue_gpstate_timer(gpstates);
 
-   freq_data.gpstate_id = idx_to_pstate(gpstate_idx);
-   gpstates->last_gpstate_idx = pstate_to_idx(freq_data.gpstate_id);
-   gpstates->last_lpstate_idx = pstate_to_idx(freq_data.pstate_id);
-
spin_unlock(>gpstate_lock);
 
/* Timer may get migrated to a different cpu on cpu hot unplug */
-- 
2.7.4

Re: [PATCH 1/2] tpm/tpm-interface: place kdoc just above tpm_pcr_extend

[Jarkko Sakkinen]

On Wed, Nov 02, 2016 at 04:02:20AM -0600, Jarkko Sakkinen wrote:
> On Tue, Nov 01, 2016 at 03:05:13AM +0200, Tomas Winkler wrote:
> > Place kdoc just above tpm_pcr_extend so it can be parsed
> > correctly.
> > 
> > Signed-off-by: Tomas Winkler 
> 
> Reviewed-by: Jarkko Sakkinen 

I applied this although I edited the short description (stripped
away "/tpm-interface".

/Jarkko

> 
> /Jarkko
> 
> > ---
> >  drivers/char/tpm/tpm-interface.c | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm-interface.c 
> > b/drivers/char/tpm/tpm-interface.c
> > index cb0e57ee053d..d496a6b26a45 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -731,6 +731,14 @@ int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 
> > *res_buf)
> >  }
> >  EXPORT_SYMBOL_GPL(tpm_pcr_read);
> >  
> > +#define TPM_ORD_PCR_EXTEND cpu_to_be32(20)
> > +#define EXTEND_PCR_RESULT_SIZE 34
> > +static const struct tpm_input_header pcrextend_header = {
> > +   .tag = TPM_TAG_RQU_COMMAND,
> > +   .length = cpu_to_be32(34),
> > +   .ordinal = TPM_ORD_PCR_EXTEND
> > +};
> > +
> >  /**
> >   * tpm_pcr_extend - extend pcr value with hash
> >   * @chip_num:  tpm idx # or AN&
> > @@ -741,14 +749,6 @@ EXPORT_SYMBOL_GPL(tpm_pcr_read);
> >   * isn't, protect against the chip disappearing, by incrementing
> >   * the module usage count.
> >   */
> > -#define TPM_ORD_PCR_EXTEND cpu_to_be32(20)
> > -#define EXTEND_PCR_RESULT_SIZE 34
> > -static const struct tpm_input_header pcrextend_header = {
> > -   .tag = TPM_TAG_RQU_COMMAND,
> > -   .length = cpu_to_be32(34),
> > -   .ordinal = TPM_ORD_PCR_EXTEND
> > -};
> > -
> >  int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash)
> >  {
> > struct tpm_cmd_t cmd;
> > -- 
> > 2.7.4
> > 

Re: [PATCH 1/2] tpm/tpm-interface: place kdoc just above tpm_pcr_extend

[Jarkko Sakkinen]

On Wed, Nov 02, 2016 at 04:02:20AM -0600, Jarkko Sakkinen wrote:
> On Tue, Nov 01, 2016 at 03:05:13AM +0200, Tomas Winkler wrote:
> > Place kdoc just above tpm_pcr_extend so it can be parsed
> > correctly.
> > 
> > Signed-off-by: Tomas Winkler 
> 
> Reviewed-by: Jarkko Sakkinen 

I applied this although I edited the short description (stripped
away "/tpm-interface".

/Jarkko

> 
> /Jarkko
> 
> > ---
> >  drivers/char/tpm/tpm-interface.c | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm-interface.c 
> > b/drivers/char/tpm/tpm-interface.c
> > index cb0e57ee053d..d496a6b26a45 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -731,6 +731,14 @@ int tpm_pcr_read(u32 chip_num, int pcr_idx, u8 
> > *res_buf)
> >  }
> >  EXPORT_SYMBOL_GPL(tpm_pcr_read);
> >  
> > +#define TPM_ORD_PCR_EXTEND cpu_to_be32(20)
> > +#define EXTEND_PCR_RESULT_SIZE 34
> > +static const struct tpm_input_header pcrextend_header = {
> > +   .tag = TPM_TAG_RQU_COMMAND,
> > +   .length = cpu_to_be32(34),
> > +   .ordinal = TPM_ORD_PCR_EXTEND
> > +};
> > +
> >  /**
> >   * tpm_pcr_extend - extend pcr value with hash
> >   * @chip_num:  tpm idx # or AN&
> > @@ -741,14 +749,6 @@ EXPORT_SYMBOL_GPL(tpm_pcr_read);
> >   * isn't, protect against the chip disappearing, by incrementing
> >   * the module usage count.
> >   */
> > -#define TPM_ORD_PCR_EXTEND cpu_to_be32(20)
> > -#define EXTEND_PCR_RESULT_SIZE 34
> > -static const struct tpm_input_header pcrextend_header = {
> > -   .tag = TPM_TAG_RQU_COMMAND,
> > -   .length = cpu_to_be32(34),
> > -   .ordinal = TPM_ORD_PCR_EXTEND
> > -};
> > -
> >  int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash)
> >  {
> > struct tpm_cmd_t cmd;
> > -- 
> > 2.7.4
> > 

[PATCH v6 1/7] net: phy: broadcom: add bcm54xx_auxctl_read

[Jon Mason]

Add a helper function to read the AUXCTL register for the BCM54xx.  This
mirrors the bcm54xx_auxctl_write function already present in the code.

Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
---
 drivers/net/phy/broadcom.c | 10 ++
 include/linux/brcmphy.h|  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 583ef8a..3a64b3d 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -30,6 +30,16 @@ MODULE_DESCRIPTION("Broadcom PHY driver");
 MODULE_AUTHOR("Maciej W. Rozycki");
 MODULE_LICENSE("GPL");
 
+static int bcm54xx_auxctl_read(struct phy_device *phydev, u16 regnum)
+{
+   /* The register must be written to both the Shadow Register Select and
+* the Shadow Read Register Selector
+*/
+   phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum |
+ regnum << MII_BCM54XX_AUXCTL_SHDWSEL_READ_SHIFT);
+   return phy_read(phydev, MII_BCM54XX_AUX_CTL);
+}
+
 static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
 {
return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 60def78..0ed6691 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -110,6 +110,7 @@
 #define MII_BCM54XX_AUXCTL_MISC_FORCE_AMDIX0x0200
 #define MII_BCM54XX_AUXCTL_MISC_RDSEL_MISC 0x7000
 #define MII_BCM54XX_AUXCTL_SHDWSEL_MISC0x0007
+#define MII_BCM54XX_AUXCTL_SHDWSEL_READ_SHIFT  12
 
 #define MII_BCM54XX_AUXCTL_SHDWSEL_MASK0x0007
 
-- 
2.7.4

[PATCH v6 1/7] net: phy: broadcom: add bcm54xx_auxctl_read

[Jon Mason]

Add a helper function to read the AUXCTL register for the BCM54xx.  This
mirrors the bcm54xx_auxctl_write function already present in the code.

Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
---
 drivers/net/phy/broadcom.c | 10 ++
 include/linux/brcmphy.h|  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 583ef8a..3a64b3d 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -30,6 +30,16 @@ MODULE_DESCRIPTION("Broadcom PHY driver");
 MODULE_AUTHOR("Maciej W. Rozycki");
 MODULE_LICENSE("GPL");
 
+static int bcm54xx_auxctl_read(struct phy_device *phydev, u16 regnum)
+{
+   /* The register must be written to both the Shadow Register Select and
+* the Shadow Read Register Selector
+*/
+   phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum |
+ regnum << MII_BCM54XX_AUXCTL_SHDWSEL_READ_SHIFT);
+   return phy_read(phydev, MII_BCM54XX_AUX_CTL);
+}
+
 static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
 {
return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 60def78..0ed6691 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -110,6 +110,7 @@
 #define MII_BCM54XX_AUXCTL_MISC_FORCE_AMDIX0x0200
 #define MII_BCM54XX_AUXCTL_MISC_RDSEL_MISC 0x7000
 #define MII_BCM54XX_AUXCTL_SHDWSEL_MISC0x0007
+#define MII_BCM54XX_AUXCTL_SHDWSEL_READ_SHIFT  12
 
 #define MII_BCM54XX_AUXCTL_SHDWSEL_MASK0x0007
 
-- 
2.7.4

Re: [PATCH v6 0/9] Fix kdump faults on system with amd iommu

[Baoquan He]

Hi Joerg,

Ping!

About the v6 post, do you have any suggestions?

Because of GCR3 special handling in patch 9/9, I spent several days to
study the knowledge and change code. Then when I tried to post, the
virtual interrupt remapping feature caused kernel hang with this pachset
applied. So it took me days to study spec and find it out. Finally it's
very late to post.

Coule it be possibe that we review and merge patch 9/1~8, and leave the
patch 9/9 which includes GCR3 special handling as 2nd step issue? Then
I can back port patch 9/1~8 to our distro. Since this bug has been
discussed so long time, and currently almost all system are deployed
with amd iommu v1 hardware. It would be great if they can be accepted
into 4.9 or 4.10-rc phase.

About patch 9/9, its code is a little complicated and not being
reviewed, I am not sure if I understand your suggestion and GCR3 code
well. What's your opinion?

Thanks
Baoquan


On 10/20/16 at 07:37pm, Baoquan He wrote:
> This is v6 post. 
> 
> The principle of the fix is similar to intel iommu. Just defer the assignment
> of device to domain to device driver init. But there's difference than
> intel iommu. AMD iommu create protection domain and assign device to
> domain in iommu driver init stage. So in this patchset I just allow the
> assignment of device to domain in software level, but defer updating the
> domain info, especially the pte_root to dev table entry to device driver
> init stage.
> 
> v5: 
> bnx2 NIC can't reset itself during driver init. Post patch to reset
> it during driver init. IO_PAGE_FAULT can't be seen anymore.
> 
> Below is link of v5 post.
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
> 
> v5->v6:
> According to Joerg's comments made several below main changes:
> - Add sanity check when copy old dev tables. 
> 
> - Discard the old patch 6/8.
> 
> - If a device is set up with guest translations (DTE.GV=1), then don't
>   copy that information but move the device over to an empty guest-cr3
>   table and handle the faults in the PPR log (which just answer them
>   with INVALID).
> 
> Issues need be discussed:
> - Joerg suggested hooking the behaviour that updates domain info into
>   dte entry into the set_dma_mask call-back. I tried, but on my local
>   machine with amd iommu v2, an ohci pci device doesn't call set_dma_mask.
>   Then IO_PAGE_FAULT printing flooded.
> 
>   00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI 
> Controller (rev 11)
> 
> - About GCR3 root pointer copying issue, I don't know how to setup the
>   test environment and haven't tested yet. Hope Joerg or Zongshun can
>   tell what steps should be taken to test it, or help take a test in your
>   test environemnt.
>  
> Baoquan He (9):
>   iommu/amd: Detect pre enabled translation
>   iommu/amd: add several helper function
>   iommu/amd: Define bit fields for DTE particularly
>   iommu/amd: Add function copy_dev_tables
>   iommu/amd: copy old trans table from old kernel
>   iommu/amd: Don't update domain info to dte entry at iommu init stage
>   iommu/amd: Update domain into to dte entry during device driver init
>   iommu/amd: Add sanity check of irq remap information of old dev table
> entry
>   iommu/amd: Don't copy GCR3 table root pointer
> 
>  drivers/iommu/amd_iommu.c   |  93 +---
>  drivers/iommu/amd_iommu_init.c  | 189 
> +---
>  drivers/iommu/amd_iommu_proto.h |   2 +
>  drivers/iommu/amd_iommu_types.h |  53 ++-
>  drivers/iommu/amd_iommu_v2.c|  18 +++-
>  5 files changed, 307 insertions(+), 48 deletions(-)
> 
> -- 
> 2.5.5
> 

[PATCH v6 2/7] Documentation: devicetree: add PHY lane swap binding

[Jon Mason]

Add the documentation for PHY lane swapping.  This is a boolean entry to
notify the phy device drivers that the TX/RX lanes need to be swapped.

Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
---
 Documentation/devicetree/bindings/net/phy.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/phy.txt 
b/Documentation/devicetree/bindings/net/phy.txt
index bc1c3c8..4627da3 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -35,6 +35,10 @@ Optional Properties:
 - broken-turn-around: If set, indicates the PHY device does not correctly
   release the turn around line low at the end of a MDIO transaction.
 
+- enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to
+  compensate for the board being designed with the lanes swapped.
+
+
 Example:
 
 ethernet-phy@0 {
-- 
2.7.4

[PATCH v6 3/7] net: phy: broadcom: Add BCM54810 PHY entry

[Jon Mason]

The BCM54810 PHY requires some semi-unique configuration, which results
in some additional configuration in addition to the standard config.
Also, some users of the BCM54810 require the PHY lanes to be swapped.
Since there is no way to detect this, add a device tree query to see if
it is applicable.

Inspired-by: Vikas Soni 
Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
---
 drivers/net/phy/Kconfig|  2 +-
 drivers/net/phy/broadcom.c | 58 +-
 include/linux/brcmphy.h|  9 +++
 3 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index ff31c10..d3fcfd2 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -217,7 +217,7 @@ config BROADCOM_PHY
select BCM_NET_PHYLIB
---help---
  Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
- BCM5481 and BCM5482 PHYs.
+ BCM5481, BCM54810 and BCM5482 PHYs.
 
 config CICADA_PHY
tristate "Cicada PHYs"
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 3a64b3d..b1e32e9 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-
+#include 
 
 #define BRCM_PHY_MODEL(phydev) \
((phydev)->drv->phy_id & (phydev)->drv->phy_id_mask)
@@ -45,6 +45,34 @@ static int bcm54xx_auxctl_write(struct phy_device *phydev, 
u16 regnum, u16 val)
return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
 }
 
+static int bcm54810_config(struct phy_device *phydev)
+{
+   int rc, val;
+
+   val = bcm_phy_read_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
+   val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
+   rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
+  val);
+   if (rc < 0)
+   return rc;
+
+   val = bcm54xx_auxctl_read(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
+   val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+   val |= MII_BCM54XX_AUXCTL_MISC_WREN;
+   rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ val);
+   if (rc < 0)
+   return rc;
+
+   val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
+   val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+   rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
+   if (rc < 0)
+   return rc;
+
+   return 0;
+}
+
 /* Needs SMDSP clock enabled via bcm54xx_phydsp_config() */
 static int bcm50610_a0_workaround(struct phy_device *phydev)
 {
@@ -217,6 +245,12 @@ static int bcm54xx_config_init(struct phy_device *phydev)
(phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
bcm54xx_adjust_rxrefclk(phydev);
 
+   if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
+   err = bcm54810_config(phydev);
+   if (err)
+   return err;
+   }
+
bcm54xx_phydsp_config(phydev);
 
return 0;
@@ -314,6 +348,7 @@ static int bcm5482_read_status(struct phy_device *phydev)
 
 static int bcm5481_config_aneg(struct phy_device *phydev)
 {
+   struct device_node *np = phydev->mdio.dev.of_node;
int ret;
 
/* Aneg firsly. */
@@ -344,6 +379,14 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
phy_write(phydev, 0x18, reg);
}
 
+   if (of_property_read_bool(np, "enet-phy-lane-swap")) {
+   /* Lane Swap - Undocumented register...magic! */
+   ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
+   0x11B);
+   if (ret < 0)
+   return ret;
+   }
+
return ret;
 }
 
@@ -578,6 +621,18 @@ static struct phy_driver broadcom_drivers[] = {
.ack_interrupt  = bcm_phy_ack_intr,
.config_intr= bcm_phy_config_intr,
 }, {
+   .phy_id = PHY_ID_BCM54810,
+   .phy_id_mask= 0xfff0,
+   .name   = "Broadcom BCM54810",
+   .features   = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+   .flags  = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+   .config_init= bcm54xx_config_init,
+   .config_aneg= bcm5481_config_aneg,
+   .read_status= genphy_read_status,
+   .ack_interrupt  = bcm_phy_ack_intr,
+   .config_intr= bcm_phy_config_intr,
+}, {
.phy_id = PHY_ID_BCM5482,
.phy_id_mask= 0xfff0,
.name   = "Broadcom BCM5482",
@@ -661,6 +716,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] 
= {
{ PHY_ID_BCM54616S, 0xfff0 },
{ PHY_ID_BCM5464, 0xfff0 },
{ PHY_ID_BCM5481, 0xfff0 },
+   { 

Re: [PATCH v6 0/9] Fix kdump faults on system with amd iommu

[Baoquan He]

Hi Joerg,

Ping!

About the v6 post, do you have any suggestions?

Because of GCR3 special handling in patch 9/9, I spent several days to
study the knowledge and change code. Then when I tried to post, the
virtual interrupt remapping feature caused kernel hang with this pachset
applied. So it took me days to study spec and find it out. Finally it's
very late to post.

Coule it be possibe that we review and merge patch 9/1~8, and leave the
patch 9/9 which includes GCR3 special handling as 2nd step issue? Then
I can back port patch 9/1~8 to our distro. Since this bug has been
discussed so long time, and currently almost all system are deployed
with amd iommu v1 hardware. It would be great if they can be accepted
into 4.9 or 4.10-rc phase.

About patch 9/9, its code is a little complicated and not being
reviewed, I am not sure if I understand your suggestion and GCR3 code
well. What's your opinion?

Thanks
Baoquan


On 10/20/16 at 07:37pm, Baoquan He wrote:
> This is v6 post. 
> 
> The principle of the fix is similar to intel iommu. Just defer the assignment
> of device to domain to device driver init. But there's difference than
> intel iommu. AMD iommu create protection domain and assign device to
> domain in iommu driver init stage. So in this patchset I just allow the
> assignment of device to domain in software level, but defer updating the
> domain info, especially the pte_root to dev table entry to device driver
> init stage.
> 
> v5: 
> bnx2 NIC can't reset itself during driver init. Post patch to reset
> it during driver init. IO_PAGE_FAULT can't be seen anymore.
> 
> Below is link of v5 post.
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2016-September/018527.html
> 
> v5->v6:
> According to Joerg's comments made several below main changes:
> - Add sanity check when copy old dev tables. 
> 
> - Discard the old patch 6/8.
> 
> - If a device is set up with guest translations (DTE.GV=1), then don't
>   copy that information but move the device over to an empty guest-cr3
>   table and handle the faults in the PPR log (which just answer them
>   with INVALID).
> 
> Issues need be discussed:
> - Joerg suggested hooking the behaviour that updates domain info into
>   dte entry into the set_dma_mask call-back. I tried, but on my local
>   machine with amd iommu v2, an ohci pci device doesn't call set_dma_mask.
>   Then IO_PAGE_FAULT printing flooded.
> 
>   00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI 
> Controller (rev 11)
> 
> - About GCR3 root pointer copying issue, I don't know how to setup the
>   test environment and haven't tested yet. Hope Joerg or Zongshun can
>   tell what steps should be taken to test it, or help take a test in your
>   test environemnt.
>  
> Baoquan He (9):
>   iommu/amd: Detect pre enabled translation
>   iommu/amd: add several helper function
>   iommu/amd: Define bit fields for DTE particularly
>   iommu/amd: Add function copy_dev_tables
>   iommu/amd: copy old trans table from old kernel
>   iommu/amd: Don't update domain info to dte entry at iommu init stage
>   iommu/amd: Update domain into to dte entry during device driver init
>   iommu/amd: Add sanity check of irq remap information of old dev table
> entry
>   iommu/amd: Don't copy GCR3 table root pointer
> 
>  drivers/iommu/amd_iommu.c   |  93 +---
>  drivers/iommu/amd_iommu_init.c  | 189 
> +---
>  drivers/iommu/amd_iommu_proto.h |   2 +
>  drivers/iommu/amd_iommu_types.h |  53 ++-
>  drivers/iommu/amd_iommu_v2.c|  18 +++-
>  5 files changed, 307 insertions(+), 48 deletions(-)
> 
> -- 
> 2.5.5
> 

[PATCH v6 2/7] Documentation: devicetree: add PHY lane swap binding

[Jon Mason]

Add the documentation for PHY lane swapping.  This is a boolean entry to
notify the phy device drivers that the TX/RX lanes need to be swapped.

Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
---
 Documentation/devicetree/bindings/net/phy.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/phy.txt 
b/Documentation/devicetree/bindings/net/phy.txt
index bc1c3c8..4627da3 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -35,6 +35,10 @@ Optional Properties:
 - broken-turn-around: If set, indicates the PHY device does not correctly
   release the turn around line low at the end of a MDIO transaction.
 
+- enet-phy-lane-swap: If set, indicates the PHY will swap the TX/RX lanes to
+  compensate for the board being designed with the lanes swapped.
+
+
 Example:
 
 ethernet-phy@0 {
-- 
2.7.4

[PATCH v6 3/7] net: phy: broadcom: Add BCM54810 PHY entry

[Jon Mason]

The BCM54810 PHY requires some semi-unique configuration, which results
in some additional configuration in addition to the standard config.
Also, some users of the BCM54810 require the PHY lanes to be swapped.
Since there is no way to detect this, add a device tree query to see if
it is applicable.

Inspired-by: Vikas Soni 
Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
---
 drivers/net/phy/Kconfig|  2 +-
 drivers/net/phy/broadcom.c | 58 +-
 include/linux/brcmphy.h|  9 +++
 3 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index ff31c10..d3fcfd2 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -217,7 +217,7 @@ config BROADCOM_PHY
select BCM_NET_PHYLIB
---help---
  Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
- BCM5481 and BCM5482 PHYs.
+ BCM5481, BCM54810 and BCM5482 PHYs.
 
 config CICADA_PHY
tristate "Cicada PHYs"
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 3a64b3d..b1e32e9 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-
+#include 
 
 #define BRCM_PHY_MODEL(phydev) \
((phydev)->drv->phy_id & (phydev)->drv->phy_id_mask)
@@ -45,6 +45,34 @@ static int bcm54xx_auxctl_write(struct phy_device *phydev, 
u16 regnum, u16 val)
return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
 }
 
+static int bcm54810_config(struct phy_device *phydev)
+{
+   int rc, val;
+
+   val = bcm_phy_read_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL);
+   val &= ~BCM54810_EXP_BROADREACH_LRE_MISC_CTL_EN;
+   rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL,
+  val);
+   if (rc < 0)
+   return rc;
+
+   val = bcm54xx_auxctl_read(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
+   val &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+   val |= MII_BCM54XX_AUXCTL_MISC_WREN;
+   rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ val);
+   if (rc < 0)
+   return rc;
+
+   val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
+   val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+   rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
+   if (rc < 0)
+   return rc;
+
+   return 0;
+}
+
 /* Needs SMDSP clock enabled via bcm54xx_phydsp_config() */
 static int bcm50610_a0_workaround(struct phy_device *phydev)
 {
@@ -217,6 +245,12 @@ static int bcm54xx_config_init(struct phy_device *phydev)
(phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
bcm54xx_adjust_rxrefclk(phydev);
 
+   if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
+   err = bcm54810_config(phydev);
+   if (err)
+   return err;
+   }
+
bcm54xx_phydsp_config(phydev);
 
return 0;
@@ -314,6 +348,7 @@ static int bcm5482_read_status(struct phy_device *phydev)
 
 static int bcm5481_config_aneg(struct phy_device *phydev)
 {
+   struct device_node *np = phydev->mdio.dev.of_node;
int ret;
 
/* Aneg firsly. */
@@ -344,6 +379,14 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
phy_write(phydev, 0x18, reg);
}
 
+   if (of_property_read_bool(np, "enet-phy-lane-swap")) {
+   /* Lane Swap - Undocumented register...magic! */
+   ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
+   0x11B);
+   if (ret < 0)
+   return ret;
+   }
+
return ret;
 }
 
@@ -578,6 +621,18 @@ static struct phy_driver broadcom_drivers[] = {
.ack_interrupt  = bcm_phy_ack_intr,
.config_intr= bcm_phy_config_intr,
 }, {
+   .phy_id = PHY_ID_BCM54810,
+   .phy_id_mask= 0xfff0,
+   .name   = "Broadcom BCM54810",
+   .features   = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+   .flags  = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+   .config_init= bcm54xx_config_init,
+   .config_aneg= bcm5481_config_aneg,
+   .read_status= genphy_read_status,
+   .ack_interrupt  = bcm_phy_ack_intr,
+   .config_intr= bcm_phy_config_intr,
+}, {
.phy_id = PHY_ID_BCM5482,
.phy_id_mask= 0xfff0,
.name   = "Broadcom BCM5482",
@@ -661,6 +716,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] 
= {
{ PHY_ID_BCM54616S, 0xfff0 },
{ PHY_ID_BCM5464, 0xfff0 },
{ PHY_ID_BCM5481, 0xfff0 },
+   { PHY_ID_BCM54810, 0xfff0 },
{ PHY_ID_BCM5482, 0xfff0 },
{ 

Re: [RFC] v4l2 support for thermopile devices

[Matt Ranostay]

On Thu, Nov 3, 2016 at 8:11 AM, Luca Barbato  wrote:
> On 03/11/2016 14:21, Attila Kinali wrote:
>> On Wed, 2 Nov 2016 23:10:41 -0700
>> Matt Ranostay  wrote:
>>
>>>
>>> So does anyone know of any software that is using V4L2_PIX_FMT_Y12
>>> currently? Want to test my driver but seems there isn't anything that
>>> uses that format (ffmpeg, mplayer, etc).
>>>
>>> Raw data seems correct but would like to visualize it :). Suspect I'll
>>> need to write a test case application though
>>
>> I was pretty sure that MPlayer supports 12bit greyscale, but I cannot
>> find where it was handled. You can of course pass it to the MPlayer
>> internas as 8bit greyscale, which would be IMGFMT_Y8 or just pass
>> it on as 16bit which would be IMGFMT_Y16_LE (LE = little endian).
>>
>> You can find the internal #defines of the image formats in
>> libmpcodecs/img_format.h and can use https://www.fourcc.org/yuv.php
>> to decode their meaning.
>>
>> The equivalent for libav would be libavutil/pixfmt.h
>>
>> Luca Barbato tells me that adding Y12 support to libav would be easy.
>>
>>   Attila Kinali
>>
>
> So easy that is [done][1], it still needs to be tested/reviewed/polished
> though.

Cool. Although needs to be processed since it is signed value, and
because it it is really just 0C based readings with 0.25C steps.. But
will look into that when I get a chance.

Anyway did hack in basic support so v4l2grab so I could test the
sensor, and seems to work well but needs some colorized processing to
be useful of course.

Soldering iron about 1 meter from sensor -> http://imgur.com/a/8totG


>
> [1]:https://github.com/lu-zero/libav/commits/gray12
>
> lu

[PATCH v6 4/7] Documentation: devicetree: net: add NS2 bindings to amac

[Jon Mason]

Clean-up the documentation to the bgmac-amac driver, per suggestion by
Rob Herring, and add details for NS2 support.

Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
---
 Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt 
b/Documentation/devicetree/bindings/net/brcm,amac.txt
index ba5ecc1..2fefa1a 100644
--- a/Documentation/devicetree/bindings/net/brcm,amac.txt
+++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
@@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
 -
 
 Required properties:
- - compatible: "brcm,amac" or "brcm,nsp-amac"
- - reg:Address and length of the GMAC registers,
-   Address and length of the GMAC IDM registers
- - reg-names:  Names of the registers.  Must have both "amac_base" and
-   "idm_base"
+ - compatible: "brcm,amac"
+   "brcm,nsp-amac"
+   "brcm,ns2-amac"
+ - reg:Address and length of the register set for the device. 
It
+   contains the information of registers in the same order as
+   described by reg-names
+ - reg-names:  Names of the registers.
+   "amac_base":Address and length of the GMAC registers
+   "idm_base": Address and length of the GMAC IDM registers
+   "nicpm_base":   Address and length of the NIC Port Manager
+   registers (required for Northstar2)
  - interrupts: Interrupt number
 
 Optional properties:
-- 
2.7.4

Re: [RFC] v4l2 support for thermopile devices

[Matt Ranostay]

On Thu, Nov 3, 2016 at 8:11 AM, Luca Barbato  wrote:
> On 03/11/2016 14:21, Attila Kinali wrote:
>> On Wed, 2 Nov 2016 23:10:41 -0700
>> Matt Ranostay  wrote:
>>
>>>
>>> So does anyone know of any software that is using V4L2_PIX_FMT_Y12
>>> currently? Want to test my driver but seems there isn't anything that
>>> uses that format (ffmpeg, mplayer, etc).
>>>
>>> Raw data seems correct but would like to visualize it :). Suspect I'll
>>> need to write a test case application though
>>
>> I was pretty sure that MPlayer supports 12bit greyscale, but I cannot
>> find where it was handled. You can of course pass it to the MPlayer
>> internas as 8bit greyscale, which would be IMGFMT_Y8 or just pass
>> it on as 16bit which would be IMGFMT_Y16_LE (LE = little endian).
>>
>> You can find the internal #defines of the image formats in
>> libmpcodecs/img_format.h and can use https://www.fourcc.org/yuv.php
>> to decode their meaning.
>>
>> The equivalent for libav would be libavutil/pixfmt.h
>>
>> Luca Barbato tells me that adding Y12 support to libav would be easy.
>>
>>   Attila Kinali
>>
>
> So easy that is [done][1], it still needs to be tested/reviewed/polished
> though.

Cool. Although needs to be processed since it is signed value, and
because it it is really just 0C based readings with 0.25C steps.. But
will look into that when I get a chance.

Anyway did hack in basic support so v4l2grab so I could test the
sensor, and seems to work well but needs some colorized processing to
be useful of course.

Soldering iron about 1 meter from sensor -> http://imgur.com/a/8totG


>
> [1]:https://github.com/lu-zero/libav/commits/gray12
>
> lu

[PATCH v6 4/7] Documentation: devicetree: net: add NS2 bindings to amac

[Jon Mason]

Clean-up the documentation to the bgmac-amac driver, per suggestion by
Rob Herring, and add details for NS2 support.

Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
---
 Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt 
b/Documentation/devicetree/bindings/net/brcm,amac.txt
index ba5ecc1..2fefa1a 100644
--- a/Documentation/devicetree/bindings/net/brcm,amac.txt
+++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
@@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
 -
 
 Required properties:
- - compatible: "brcm,amac" or "brcm,nsp-amac"
- - reg:Address and length of the GMAC registers,
-   Address and length of the GMAC IDM registers
- - reg-names:  Names of the registers.  Must have both "amac_base" and
-   "idm_base"
+ - compatible: "brcm,amac"
+   "brcm,nsp-amac"
+   "brcm,ns2-amac"
+ - reg:Address and length of the register set for the device. 
It
+   contains the information of registers in the same order as
+   described by reg-names
+ - reg-names:  Names of the registers.
+   "amac_base":Address and length of the GMAC registers
+   "idm_base": Address and length of the GMAC IDM registers
+   "nicpm_base":   Address and length of the NIC Port Manager
+   registers (required for Northstar2)
  - interrupts: Interrupt number
 
 Optional properties:
-- 
2.7.4

[PATCH v6 7/7] arm64: dts: NS2: add AMAC ethernet support

[Jon Mason]

Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
tree

Signed-off-by: Jon Mason 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts |  5 +
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 12 
 2 files changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index b09f3bc..c4d5442 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -56,6 +56,10 @@
};
 };
 
+ {
+   status = "ok";
+};
+
 _phy0 {
status = "ok";
 };
@@ -174,6 +178,7 @@
 _mux_iproc {
mdio@10 {
gphy0: eth-phy@10 {
+   enet-phy-lane-swap;
reg = <0x10>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..773ed59 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -191,6 +191,18 @@
 
#include "ns2-clock.dtsi"
 
+   enet: ethernet@6100 {
+   compatible = "brcm,ns2-amac";
+   reg = <0x6100 0x1000>,
+ <0x6109 0x1000>,
+ <0x6103 0x100>;
+   reg-names = "amac_base", "idm_base", "nicpm_base";
+   interrupts = ;
+   phy-handle = <>;
+   phy-mode = "rgmii";
+   status = "disabled";
+   };
+
dma0: dma@6136 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x6136 0x1000>;
-- 
2.7.4

[PATCH v6 6/7] net: ethernet: bgmac: add NS2 support

[Jon Mason]

Add support for the variant of amac hardware present in the Broadcom
Northstar2 based SoCs.  Northstar2 requires an additional register to be
configured with the port speed/duplexity (NICPM).  This can be added to
the link callback to hide it from the instances that do not use this.
Also, clearing of the pending interrupts on init is required due to
observed issues on some platforms.

Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
---
 drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +-
 drivers/net/ethernet/broadcom/bgmac.c  |  3 ++
 drivers/net/ethernet/broadcom/bgmac.h  |  1 +
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index 4642940..6f736c1 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -14,12 +14,21 @@
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include "bgmac.h"
 
+#define NICPM_IOMUX_CTRL   0x0008
+
+#define NICPM_IOMUX_CTRL_INIT_VAL  0x3196e000
+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
+#define NICPM_IOMUX_CTRL_SPD_10M   0
+#define NICPM_IOMUX_CTRL_SPD_100M  1
+#define NICPM_IOMUX_CTRL_SPD_1000M 2
+
 static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
 {
return readl(bgmac->plat.base + offset);
@@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac 
*bgmac, u16 offset,
WARN_ON(1);
 }
 
+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
+{
+   struct bgmac *bgmac = netdev_priv(net_dev);
+   u32 val;
+
+   if (!bgmac->plat.nicpm_base)
+   return;
+
+   val = NICPM_IOMUX_CTRL_INIT_VAL;
+   switch (bgmac->net_dev->phydev->speed) {
+   default:
+   netdev_err(net_dev, "Unsupported speed. Defaulting to 
1000Mb\n");
+   case SPEED_1000:
+   val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   case SPEED_100:
+   val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   case SPEED_10:
+   val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   }
+
+   writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
+
+   bgmac_adjust_link(bgmac->net_dev);
+}
+
 static int platform_phy_connect(struct bgmac *bgmac)
 {
struct phy_device *phy_dev;
 
-   phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
-bgmac_adjust_link);
+   if (bgmac->plat.nicpm_base)
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+bgmac->dev->of_node,
+bgmac_nicpm_speed_set);
+   else
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+bgmac->dev->of_node,
+bgmac_adjust_link);
if (!phy_dev) {
dev_err(bgmac->dev, "PHY connection failed\n");
return -ENODEV;
@@ -156,6 +199,14 @@ static int bgmac_probe(struct platform_device *pdev)
if (IS_ERR(bgmac->plat.idm_base))
return PTR_ERR(bgmac->plat.idm_base);
 
+   regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
+   if (regs) {
+   bgmac->plat.nicpm_base = devm_ioremap_resource(>dev,
+  regs);
+   if (IS_ERR(bgmac->plat.nicpm_base))
+   return PTR_ERR(bgmac->plat.nicpm_base);
+   }
+
bgmac->read = platform_bgmac_read;
bgmac->write = platform_bgmac_write;
bgmac->idm_read = platform_bgmac_idm_read;
@@ -187,6 +238,7 @@ static int bgmac_remove(struct platform_device *pdev)
 static const struct of_device_id bgmac_of_enet_match[] = {
{.compatible = "brcm,amac",},
{.compatible = "brcm,nsp-amac",},
+   {.compatible = "brcm,ns2-amac",},
{},
 };
 
diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 7f66ea7..a29787f 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
 /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
 static void bgmac_chip_init(struct bgmac *bgmac)
 {
+   /* Clear any erroneously pending interrupts */
+   bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
+
/* 1 interrupt per received frame */
bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
 
diff --git a/drivers/net/ethernet/broadcom/bgmac.h 

[PATCH v6 7/7] arm64: dts: NS2: add AMAC ethernet support

[Jon Mason]

Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
tree

Signed-off-by: Jon Mason 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts |  5 +
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 12 
 2 files changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index b09f3bc..c4d5442 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -56,6 +56,10 @@
};
 };
 
+ {
+   status = "ok";
+};
+
 _phy0 {
status = "ok";
 };
@@ -174,6 +178,7 @@
 _mux_iproc {
mdio@10 {
gphy0: eth-phy@10 {
+   enet-phy-lane-swap;
reg = <0x10>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..773ed59 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -191,6 +191,18 @@
 
#include "ns2-clock.dtsi"
 
+   enet: ethernet@6100 {
+   compatible = "brcm,ns2-amac";
+   reg = <0x6100 0x1000>,
+ <0x6109 0x1000>,
+ <0x6103 0x100>;
+   reg-names = "amac_base", "idm_base", "nicpm_base";
+   interrupts = ;
+   phy-handle = <>;
+   phy-mode = "rgmii";
+   status = "disabled";
+   };
+
dma0: dma@6136 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x6136 0x1000>;
-- 
2.7.4

[PATCH v6 6/7] net: ethernet: bgmac: add NS2 support

[Jon Mason]

Add support for the variant of amac hardware present in the Broadcom
Northstar2 based SoCs.  Northstar2 requires an additional register to be
configured with the port speed/duplexity (NICPM).  This can be added to
the link callback to hide it from the instances that do not use this.
Also, clearing of the pending interrupts on init is required due to
observed issues on some platforms.

Signed-off-by: Jon Mason 
Reviewed-by: Florian Fainelli 
---
 drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +-
 drivers/net/ethernet/broadcom/bgmac.c  |  3 ++
 drivers/net/ethernet/broadcom/bgmac.h  |  1 +
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index 4642940..6f736c1 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -14,12 +14,21 @@
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include "bgmac.h"
 
+#define NICPM_IOMUX_CTRL   0x0008
+
+#define NICPM_IOMUX_CTRL_INIT_VAL  0x3196e000
+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
+#define NICPM_IOMUX_CTRL_SPD_10M   0
+#define NICPM_IOMUX_CTRL_SPD_100M  1
+#define NICPM_IOMUX_CTRL_SPD_1000M 2
+
 static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
 {
return readl(bgmac->plat.base + offset);
@@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac 
*bgmac, u16 offset,
WARN_ON(1);
 }
 
+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
+{
+   struct bgmac *bgmac = netdev_priv(net_dev);
+   u32 val;
+
+   if (!bgmac->plat.nicpm_base)
+   return;
+
+   val = NICPM_IOMUX_CTRL_INIT_VAL;
+   switch (bgmac->net_dev->phydev->speed) {
+   default:
+   netdev_err(net_dev, "Unsupported speed. Defaulting to 
1000Mb\n");
+   case SPEED_1000:
+   val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   case SPEED_100:
+   val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   case SPEED_10:
+   val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   }
+
+   writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
+
+   bgmac_adjust_link(bgmac->net_dev);
+}
+
 static int platform_phy_connect(struct bgmac *bgmac)
 {
struct phy_device *phy_dev;
 
-   phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
-bgmac_adjust_link);
+   if (bgmac->plat.nicpm_base)
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+bgmac->dev->of_node,
+bgmac_nicpm_speed_set);
+   else
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+bgmac->dev->of_node,
+bgmac_adjust_link);
if (!phy_dev) {
dev_err(bgmac->dev, "PHY connection failed\n");
return -ENODEV;
@@ -156,6 +199,14 @@ static int bgmac_probe(struct platform_device *pdev)
if (IS_ERR(bgmac->plat.idm_base))
return PTR_ERR(bgmac->plat.idm_base);
 
+   regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
+   if (regs) {
+   bgmac->plat.nicpm_base = devm_ioremap_resource(>dev,
+  regs);
+   if (IS_ERR(bgmac->plat.nicpm_base))
+   return PTR_ERR(bgmac->plat.nicpm_base);
+   }
+
bgmac->read = platform_bgmac_read;
bgmac->write = platform_bgmac_write;
bgmac->idm_read = platform_bgmac_idm_read;
@@ -187,6 +238,7 @@ static int bgmac_remove(struct platform_device *pdev)
 static const struct of_device_id bgmac_of_enet_match[] = {
{.compatible = "brcm,amac",},
{.compatible = "brcm,nsp-amac",},
+   {.compatible = "brcm,ns2-amac",},
{},
 };
 
diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 7f66ea7..a29787f 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
 /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
 static void bgmac_chip_init(struct bgmac *bgmac)
 {
+   /* Clear any erroneously pending interrupts */
+   bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
+
/* 1 interrupt per received frame */
bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
 
diff --git a/drivers/net/ethernet/broadcom/bgmac.h 
b/drivers/net/ethernet/broadcom/bgmac.h
index 

[PATCH v6 5/7] net: ethernet: bgmac: device tree phy enablement

[Jon Mason]

Change the bgmac driver to allow for phy's defined by the device tree

Signed-off-by: Jon Mason 
---
 drivers/net/ethernet/broadcom/bgmac-bcma.c | 22 +++
 drivers/net/ethernet/broadcom/bgmac-platform.c | 22 ++-
 drivers/net/ethernet/broadcom/bgmac.c  | 29 +-
 drivers/net/ethernet/broadcom/bgmac.h  |  8 +++
 4 files changed, 56 insertions(+), 25 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c 
b/drivers/net/ethernet/broadcom/bgmac-bcma.c
index c16ec3a..4a4ffc0 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -80,6 +80,24 @@ static void bcma_bgmac_cmn_maskset32(struct bgmac *bgmac, 
u16 offset, u32 mask,
bcma_maskset32(bgmac->bcma.cmn, offset, mask, set);
 }
 
+static int bcma_phy_connect(struct bgmac *bgmac)
+{
+   struct phy_device *phy_dev;
+   char bus_id[MII_BUS_ID_SIZE + 3];
+
+   /* Connect to the PHY */
+   snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
+bgmac->phyaddr);
+   phy_dev = phy_connect(bgmac->net_dev, bus_id, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+   if (IS_ERR(phy_dev)) {
+   dev_err(bgmac->dev, "PHY connection failed\n");
+   return PTR_ERR(phy_dev);
+   }
+
+   return 0;
+}
+
 static const struct bcma_device_id bgmac_bcma_tbl[] = {
BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_4706_MAC_GBIT,
  BCMA_ANY_REV, BCMA_ANY_CLASS),
@@ -275,6 +293,10 @@ static int bgmac_probe(struct bcma_device *core)
bgmac->cco_ctl_maskset = bcma_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = bcma_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = bcma_bgmac_cmn_maskset32;
+   if (bgmac->mii_bus)
+   bgmac->phy_connect = bcma_phy_connect;
+   else
+   bgmac->phy_connect = bgmac_phy_connect_direct;
 
err = bgmac_enet_probe(bgmac);
if (err)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index be52f27..4642940 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "bgmac.h"
 
@@ -86,6 +87,20 @@ static void platform_bgmac_cmn_maskset32(struct bgmac 
*bgmac, u16 offset,
WARN_ON(1);
 }
 
+static int platform_phy_connect(struct bgmac *bgmac)
+{
+   struct phy_device *phy_dev;
+
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
+bgmac_adjust_link);
+   if (!phy_dev) {
+   dev_err(bgmac->dev, "PHY connection failed\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
 static int bgmac_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -102,7 +117,6 @@ static int bgmac_probe(struct platform_device *pdev)
/* Set the features of the 4707 family */
bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
-   bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
bgmac->feature_flags |= BGMAC_FEAT_CMDCFG_SR_REV4;
bgmac->feature_flags |= BGMAC_FEAT_TX_MASK_SETUP;
bgmac->feature_flags |= BGMAC_FEAT_RX_MASK_SETUP;
@@ -151,6 +165,12 @@ static int bgmac_probe(struct platform_device *pdev)
bgmac->cco_ctl_maskset = platform_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = platform_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = platform_bgmac_cmn_maskset32;
+   if (of_parse_phandle(np, "phy-handle", 0)) {
+   bgmac->phy_connect = platform_phy_connect;
+   } else {
+   bgmac->phy_connect = bgmac_phy_connect_direct;
+   bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
+   }
 
return bgmac_enet_probe(bgmac);
 }
diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 31ca204..7f66ea7 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1388,7 +1388,7 @@ static const struct ethtool_ops bgmac_ethtool_ops = {
  * MII
  **/
 
-static void bgmac_adjust_link(struct net_device *net_dev)
+void bgmac_adjust_link(struct net_device *net_dev)
 {
struct bgmac *bgmac = netdev_priv(net_dev);
struct phy_device *phy_dev = net_dev->phydev;
@@ -1411,8 +1411,9 @@ static void bgmac_adjust_link(struct net_device *net_dev)
phy_print_status(phy_dev);
}
 }
+EXPORT_SYMBOL_GPL(bgmac_adjust_link);
 
-static int bgmac_phy_connect_direct(struct bgmac *bgmac)
+int bgmac_phy_connect_direct(struct bgmac *bgmac)
 {
struct fixed_phy_status fphy_status = {
.link = 1,
@@ 

[PATCH v6 5/7] net: ethernet: bgmac: device tree phy enablement

[Jon Mason]

Change the bgmac driver to allow for phy's defined by the device tree

Signed-off-by: Jon Mason 
---
 drivers/net/ethernet/broadcom/bgmac-bcma.c | 22 +++
 drivers/net/ethernet/broadcom/bgmac-platform.c | 22 ++-
 drivers/net/ethernet/broadcom/bgmac.c  | 29 +-
 drivers/net/ethernet/broadcom/bgmac.h  |  8 +++
 4 files changed, 56 insertions(+), 25 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c 
b/drivers/net/ethernet/broadcom/bgmac-bcma.c
index c16ec3a..4a4ffc0 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -80,6 +80,24 @@ static void bcma_bgmac_cmn_maskset32(struct bgmac *bgmac, 
u16 offset, u32 mask,
bcma_maskset32(bgmac->bcma.cmn, offset, mask, set);
 }
 
+static int bcma_phy_connect(struct bgmac *bgmac)
+{
+   struct phy_device *phy_dev;
+   char bus_id[MII_BUS_ID_SIZE + 3];
+
+   /* Connect to the PHY */
+   snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
+bgmac->phyaddr);
+   phy_dev = phy_connect(bgmac->net_dev, bus_id, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+   if (IS_ERR(phy_dev)) {
+   dev_err(bgmac->dev, "PHY connection failed\n");
+   return PTR_ERR(phy_dev);
+   }
+
+   return 0;
+}
+
 static const struct bcma_device_id bgmac_bcma_tbl[] = {
BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_4706_MAC_GBIT,
  BCMA_ANY_REV, BCMA_ANY_CLASS),
@@ -275,6 +293,10 @@ static int bgmac_probe(struct bcma_device *core)
bgmac->cco_ctl_maskset = bcma_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = bcma_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = bcma_bgmac_cmn_maskset32;
+   if (bgmac->mii_bus)
+   bgmac->phy_connect = bcma_phy_connect;
+   else
+   bgmac->phy_connect = bgmac_phy_connect_direct;
 
err = bgmac_enet_probe(bgmac);
if (err)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index be52f27..4642940 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "bgmac.h"
 
@@ -86,6 +87,20 @@ static void platform_bgmac_cmn_maskset32(struct bgmac 
*bgmac, u16 offset,
WARN_ON(1);
 }
 
+static int platform_phy_connect(struct bgmac *bgmac)
+{
+   struct phy_device *phy_dev;
+
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
+bgmac_adjust_link);
+   if (!phy_dev) {
+   dev_err(bgmac->dev, "PHY connection failed\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
 static int bgmac_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -102,7 +117,6 @@ static int bgmac_probe(struct platform_device *pdev)
/* Set the features of the 4707 family */
bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
-   bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
bgmac->feature_flags |= BGMAC_FEAT_CMDCFG_SR_REV4;
bgmac->feature_flags |= BGMAC_FEAT_TX_MASK_SETUP;
bgmac->feature_flags |= BGMAC_FEAT_RX_MASK_SETUP;
@@ -151,6 +165,12 @@ static int bgmac_probe(struct platform_device *pdev)
bgmac->cco_ctl_maskset = platform_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = platform_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = platform_bgmac_cmn_maskset32;
+   if (of_parse_phandle(np, "phy-handle", 0)) {
+   bgmac->phy_connect = platform_phy_connect;
+   } else {
+   bgmac->phy_connect = bgmac_phy_connect_direct;
+   bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
+   }
 
return bgmac_enet_probe(bgmac);
 }
diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 31ca204..7f66ea7 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1388,7 +1388,7 @@ static const struct ethtool_ops bgmac_ethtool_ops = {
  * MII
  **/
 
-static void bgmac_adjust_link(struct net_device *net_dev)
+void bgmac_adjust_link(struct net_device *net_dev)
 {
struct bgmac *bgmac = netdev_priv(net_dev);
struct phy_device *phy_dev = net_dev->phydev;
@@ -1411,8 +1411,9 @@ static void bgmac_adjust_link(struct net_device *net_dev)
phy_print_status(phy_dev);
}
 }
+EXPORT_SYMBOL_GPL(bgmac_adjust_link);
 
-static int bgmac_phy_connect_direct(struct bgmac *bgmac)
+int bgmac_phy_connect_direct(struct bgmac *bgmac)
 {
struct fixed_phy_status fphy_status = {
.link = 1,
@@ -1437,24 +1438,7 @@ static 

[PATCH v6 0/7] add NS2 support to bgmac

[Jon Mason]

Changes in v6:
* Use a common bgmac_phy_connect_direct (per Rafal Milecki) 
* Rebased on latest net-next
* Added Reviewed-by to the relevant patches


Changes in v5:
* Change a pr_err to netdev_err (per Scott Branden)
* Reword the lane swap binding documentation (per Andrew Lunn)


Changes in v4:
* Actually send out the lane swap binding doc patch (Per Scott Branden)
* Remove unused #define (Per Andrew Lunn)


Changes in v3:
* Clean-up the bgmac DT binding doc (per Rob Herring)
* Document the lane swap binding and make it generic (Per Andrew Lunn)


Changes in v2:
* Remove the PHY power-on (per Andrew Lunn)
* Misc PHY clean-ups regarding comments and #defines (per Andrew Lunn)
  This results on none of the original PHY code from Vikas being
  present.  So, I'm removing him as an author and giving him
  "Inspired-by" credit.
* Move PHY lane swapping to PHY driver (per Andrew Lunn and Florian
  Fainelli)
* Remove bgmac sleep (per Florian Fainelli)
* Re-add bgmac chip reset (per Florian Fainelli and Ray Jui)
* Rebased on latest net-next
* Added patch for bcm54xx_auxctl_read, which is used in the BCM54810


Jon Mason (7):
  net: phy: broadcom: add bcm54xx_auxctl_read
  Documentation: devicetree: add PHY lane swap binding
  net: phy: broadcom: Add BCM54810 PHY entry
  Documentation: devicetree: net: add NS2 bindings to amac
  net: ethernet: bgmac: device tree phy enablement
  net: ethernet: bgmac: add NS2 support
  arm64: dts: NS2: add AMAC ethernet support

 .../devicetree/bindings/net/brcm,amac.txt  | 16 +++--
 Documentation/devicetree/bindings/net/phy.txt  |  4 ++
 arch/arm64/boot/dts/broadcom/ns2-svk.dts   |  5 ++
 arch/arm64/boot/dts/broadcom/ns2.dtsi  | 12 
 drivers/net/ethernet/broadcom/bgmac-bcma.c | 22 +++
 drivers/net/ethernet/broadcom/bgmac-platform.c | 74 +-
 drivers/net/ethernet/broadcom/bgmac.c  | 32 +++---
 drivers/net/ethernet/broadcom/bgmac.h  |  9 +++
 drivers/net/phy/Kconfig|  2 +-
 drivers/net/phy/broadcom.c | 68 +++-
 include/linux/brcmphy.h| 10 +++
 11 files changed, 222 insertions(+), 32 deletions(-)

-- 
2.7.4

[PATCH v6 0/7] add NS2 support to bgmac

[Jon Mason]

Changes in v6:
* Use a common bgmac_phy_connect_direct (per Rafal Milecki) 
* Rebased on latest net-next
* Added Reviewed-by to the relevant patches


Changes in v5:
* Change a pr_err to netdev_err (per Scott Branden)
* Reword the lane swap binding documentation (per Andrew Lunn)


Changes in v4:
* Actually send out the lane swap binding doc patch (Per Scott Branden)
* Remove unused #define (Per Andrew Lunn)


Changes in v3:
* Clean-up the bgmac DT binding doc (per Rob Herring)
* Document the lane swap binding and make it generic (Per Andrew Lunn)


Changes in v2:
* Remove the PHY power-on (per Andrew Lunn)
* Misc PHY clean-ups regarding comments and #defines (per Andrew Lunn)
  This results on none of the original PHY code from Vikas being
  present.  So, I'm removing him as an author and giving him
  "Inspired-by" credit.
* Move PHY lane swapping to PHY driver (per Andrew Lunn and Florian
  Fainelli)
* Remove bgmac sleep (per Florian Fainelli)
* Re-add bgmac chip reset (per Florian Fainelli and Ray Jui)
* Rebased on latest net-next
* Added patch for bcm54xx_auxctl_read, which is used in the BCM54810


Jon Mason (7):
  net: phy: broadcom: add bcm54xx_auxctl_read
  Documentation: devicetree: add PHY lane swap binding
  net: phy: broadcom: Add BCM54810 PHY entry
  Documentation: devicetree: net: add NS2 bindings to amac
  net: ethernet: bgmac: device tree phy enablement
  net: ethernet: bgmac: add NS2 support
  arm64: dts: NS2: add AMAC ethernet support

 .../devicetree/bindings/net/brcm,amac.txt  | 16 +++--
 Documentation/devicetree/bindings/net/phy.txt  |  4 ++
 arch/arm64/boot/dts/broadcom/ns2-svk.dts   |  5 ++
 arch/arm64/boot/dts/broadcom/ns2.dtsi  | 12 
 drivers/net/ethernet/broadcom/bgmac-bcma.c | 22 +++
 drivers/net/ethernet/broadcom/bgmac-platform.c | 74 +-
 drivers/net/ethernet/broadcom/bgmac.c  | 32 +++---
 drivers/net/ethernet/broadcom/bgmac.h  |  9 +++
 drivers/net/phy/Kconfig|  2 +-
 drivers/net/phy/broadcom.c | 68 +++-
 include/linux/brcmphy.h| 10 +++
 11 files changed, 222 insertions(+), 32 deletions(-)

-- 
2.7.4

[PATCH v7 3/3] fpga: Add support for Lattice iCE40 FPGAs

[Joel Holdsworth]

The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
and very regular structure, designed for low-cost, high-volume consumer
and system applications.

This patch adds support to the FPGA manager for configuring the SRAM of
iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
UltraPlus devices, through slave SPI.

The iCE40 family is notable because it is the first FPGA family to have
complete reverse engineered bit-stream documentation for the iCE40LP and
iCE40HX devices. Furthermore, there is now a Free Software Verilog
synthesis tool-chain: the "IceStorm" tool-chain.

This project is the work of Clifford Wolf, who is the maintainer of
Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
contributions from "Cotton Seed", the main author of "arachne-pnr"; a
place-and-route tool for iCE40 FPGAs.

Having a Free Software synthesis tool-chain offers interesting
opportunities for embedded devices that are able reconfigure themselves
with open firmware that is generated on the device itself. For example
a mobile device might have an application processor with an iCE40 FPGA
attached, which implements slave devices, or through which the processor
communicates with other devices through the FPGA fabric.

A kernel driver for the iCE40 is useful, because in some cases, the FPGA
may need to be configured before other devices can be accessed.

An example of such a device is the icoBoard; a RaspberryPI HAT which
features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
Digilent-compatible PMOD modules. A PMOD module may contain a device
with which the kernel communicates, via the FPGA.
---
 drivers/fpga/Kconfig |   6 ++
 drivers/fpga/Makefile|   1 +
 drivers/fpga/ice40-spi.c | 198 +++
 3 files changed, 205 insertions(+)
 create mode 100644 drivers/fpga/ice40-spi.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index d614102..85ff429 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -13,6 +13,12 @@ config FPGA
 
 if FPGA
 
+config FPGA_MGR_ICE40_SPI
+   tristate "Lattice iCE40 SPI"
+   depends on SPI
+   help
+ FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
+
 config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6..adb5811 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,5 +6,6 @@
 obj-$(CONFIG_FPGA) += fpga-mgr.o
 
 # FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_ICE40_SPI)   += ice40-spi.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
new file mode 100644
index 000..a977f19
--- /dev/null
+++ b/drivers/fpga/ice40-spi.c
@@ -0,0 +1,198 @@
+/*
+ * FPGA Manager Driver for Lattice iCE40.
+ *
+ *  Copyright (c) 2016 Joel Holdsworth
+ *
+ * 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; version 2 of the License.
+ *
+ * This driver adds support to the FPGA manager for configuring the SRAM of
+ * Lattice iCE40 FPGAs through slave SPI.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
+#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
+
+#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BITS 49 /* bits */
+
+struct ice40_fpga_priv {
+   struct spi_device *dev;
+   struct gpio_desc *reset;
+   struct gpio_desc *cdone;
+};
+
+static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+
+   return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
+   FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
+const char *buf, size_t count)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+   struct spi_device *dev = priv->dev;
+   struct spi_message message;
+   int ret;
+
+   if ((flags & FPGA_MGR_PARTIAL_RECONFIG)) {
+   dev_err(>dev,
+   "Partial reconfiguration is not supported\n");
+   return -ENOTSUPP;
+   }
+
+   /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
+   spi_bus_lock(dev->master);
+
+   gpiod_set_value(priv->reset, 1);
+
+   spi_message_init();
+   spi_message_add_tail(&(struct spi_transfer){.cs_change = 1,
+   .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY}, );
+   ret = spi_sync_locked(dev, );
+   if (ret) {
+   spi_bus_unlock(dev->master);
+   return ret;
+   }
+
+   /* Come out of reset */
+   gpiod_set_value(priv->reset, 0);
+
+   

[PATCH v7 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager

[Joel Holdsworth]

---
 .../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt

diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt 
b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
new file mode 100644
index 000..cb64184
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
@@ -0,0 +1,21 @@
+Lattice iCE40 FPGA Manager
+
+Required properties:
+- compatible:  Should contain "lattice,ice40-fpga-mgr"
+- reg: SPI chip select
+- spi-max-frequency:   Maximum SPI frequency (>=100, <=2500)
+- cdone-gpios: GPIO input connected to CDONE pin
+- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
+   that unless the GPIO is held low during startup, the
+   FPGA will enter Master SPI mode and drive SCK with a
+   clock signal, potentially jamming other devices on the
+   bus until the firmware is loaded.
+
+Example:
+   ice40: ice40@0 {
+   compatible = "lattice,ice40-fpga-mgr";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   cdone-gpios = < 24 GPIO_ACTIVE_HIGH>;
+   creset_b-gpios = < 22 GPIO_ACTIVE_LOW>;
+   };
-- 
2.7.4

[PATCH v7 1/3] of: Add vendor prefix for Lattice Semiconductor

[Joel Holdsworth]

Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..d64a835 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -146,6 +146,7 @@ kosagi  Sutajio Ko-Usagi PTE Ltd.
 kyoKyocera Corporation
 lacie  LaCie
 lantiq Lantiq Semiconductor
+latticeLattice Semiconductor
 lenovo Lenovo Group Ltd.
 lg LG Corporation
 linux  Linux-specific binding
-- 
2.7.4

[PATCH v7 3/3] fpga: Add support for Lattice iCE40 FPGAs

[Joel Holdsworth]

The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
and very regular structure, designed for low-cost, high-volume consumer
and system applications.

This patch adds support to the FPGA manager for configuring the SRAM of
iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
UltraPlus devices, through slave SPI.

The iCE40 family is notable because it is the first FPGA family to have
complete reverse engineered bit-stream documentation for the iCE40LP and
iCE40HX devices. Furthermore, there is now a Free Software Verilog
synthesis tool-chain: the "IceStorm" tool-chain.

This project is the work of Clifford Wolf, who is the maintainer of
Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
contributions from "Cotton Seed", the main author of "arachne-pnr"; a
place-and-route tool for iCE40 FPGAs.

Having a Free Software synthesis tool-chain offers interesting
opportunities for embedded devices that are able reconfigure themselves
with open firmware that is generated on the device itself. For example
a mobile device might have an application processor with an iCE40 FPGA
attached, which implements slave devices, or through which the processor
communicates with other devices through the FPGA fabric.

A kernel driver for the iCE40 is useful, because in some cases, the FPGA
may need to be configured before other devices can be accessed.

An example of such a device is the icoBoard; a RaspberryPI HAT which
features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
Digilent-compatible PMOD modules. A PMOD module may contain a device
with which the kernel communicates, via the FPGA.
---
 drivers/fpga/Kconfig |   6 ++
 drivers/fpga/Makefile|   1 +
 drivers/fpga/ice40-spi.c | 198 +++
 3 files changed, 205 insertions(+)
 create mode 100644 drivers/fpga/ice40-spi.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index d614102..85ff429 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -13,6 +13,12 @@ config FPGA
 
 if FPGA
 
+config FPGA_MGR_ICE40_SPI
+   tristate "Lattice iCE40 SPI"
+   depends on SPI
+   help
+ FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
+
 config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6..adb5811 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,5 +6,6 @@
 obj-$(CONFIG_FPGA) += fpga-mgr.o
 
 # FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_ICE40_SPI)   += ice40-spi.o
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
new file mode 100644
index 000..a977f19
--- /dev/null
+++ b/drivers/fpga/ice40-spi.c
@@ -0,0 +1,198 @@
+/*
+ * FPGA Manager Driver for Lattice iCE40.
+ *
+ *  Copyright (c) 2016 Joel Holdsworth
+ *
+ * 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; version 2 of the License.
+ *
+ * This driver adds support to the FPGA manager for configuring the SRAM of
+ * Lattice iCE40 FPGAs through slave SPI.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
+#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
+
+#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BITS 49 /* bits */
+
+struct ice40_fpga_priv {
+   struct spi_device *dev;
+   struct gpio_desc *reset;
+   struct gpio_desc *cdone;
+};
+
+static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+
+   return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
+   FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
+const char *buf, size_t count)
+{
+   struct ice40_fpga_priv *priv = mgr->priv;
+   struct spi_device *dev = priv->dev;
+   struct spi_message message;
+   int ret;
+
+   if ((flags & FPGA_MGR_PARTIAL_RECONFIG)) {
+   dev_err(>dev,
+   "Partial reconfiguration is not supported\n");
+   return -ENOTSUPP;
+   }
+
+   /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
+   spi_bus_lock(dev->master);
+
+   gpiod_set_value(priv->reset, 1);
+
+   spi_message_init();
+   spi_message_add_tail(&(struct spi_transfer){.cs_change = 1,
+   .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY}, );
+   ret = spi_sync_locked(dev, );
+   if (ret) {
+   spi_bus_unlock(dev->master);
+   return ret;
+   }
+
+   /* Come out of reset */
+   gpiod_set_value(priv->reset, 0);
+
+   

[PATCH v7 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager

[Joel Holdsworth]

---
 .../bindings/fpga/lattice-ice40-fpga-mgr.txt| 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt

diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt 
b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
new file mode 100644
index 000..cb64184
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
@@ -0,0 +1,21 @@
+Lattice iCE40 FPGA Manager
+
+Required properties:
+- compatible:  Should contain "lattice,ice40-fpga-mgr"
+- reg: SPI chip select
+- spi-max-frequency:   Maximum SPI frequency (>=100, <=2500)
+- cdone-gpios: GPIO input connected to CDONE pin
+- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
+   that unless the GPIO is held low during startup, the
+   FPGA will enter Master SPI mode and drive SCK with a
+   clock signal, potentially jamming other devices on the
+   bus until the firmware is loaded.
+
+Example:
+   ice40: ice40@0 {
+   compatible = "lattice,ice40-fpga-mgr";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   cdone-gpios = < 24 GPIO_ACTIVE_HIGH>;
+   creset_b-gpios = < 22 GPIO_ACTIVE_LOW>;
+   };
-- 
2.7.4

[PATCH v7 1/3] of: Add vendor prefix for Lattice Semiconductor

[Joel Holdsworth]

Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..d64a835 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -146,6 +146,7 @@ kosagi  Sutajio Ko-Usagi PTE Ltd.
 kyoKyocera Corporation
 lacie  LaCie
 lantiq Lantiq Semiconductor
+latticeLattice Semiconductor
 lenovo Lenovo Group Ltd.
 lg LG Corporation
 linux  Linux-specific binding
-- 
2.7.4

Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query

[Matt Ranostay]

On Wed, Nov 2, 2016 at 1:22 AM, Pavel Machek  wrote:
> Hi!
>
>> >> >> Better then previous one.
>> >> >>
>> >> >> But my version of bq27xxx_battery.c already contains this:
>> >> >
>> >> > This is for allowing udev rule to set the properties as well.
>> >> > otherwise a kinda crude RUN = " echo value >
>> >> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required.
>> >>
>> >> Any thoughts on this?
>> >
>> > I'd say  echo value >
>> > /sys/module/bq27xxx_battery/parameters/poll_interval .. is quite
>> > adequate solution...?
>> >
>> > Alternatively, convince us that something else is useful for everyone,
>> > and we can do the right thing (poll more often when battery is nearly
>> > empty), automatically...
>>
>> Ok should have had the patchset set it per device, and not use the
>> global poll_interval. Of need to add some logic to see if uses the
>> global poll_interval or it's own setting.
>>
>> There are times where you could have multiple batteries connected to
>> multiple fuel gauges, and want to up the polling interval on certain
>> ones that are discharging at different rates.
>>
>> But of course I'll let you guys let me know if this seems useful at all.
>
> I agree per-device polling would be cleaner.
>

Ok I'll work something up for RFC.

> But unless you have hardware with more than one bq27xxx, I'd avoid the
> work...
>
> Now... its also possible that poll_interval should change itself
> (within kernel) to do the right thing.
>

True but that is state machine territory, but I'll worry about that later...

> Best regards,
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query

[Matt Ranostay]

On Wed, Nov 2, 2016 at 1:22 AM, Pavel Machek  wrote:
> Hi!
>
>> >> >> Better then previous one.
>> >> >>
>> >> >> But my version of bq27xxx_battery.c already contains this:
>> >> >
>> >> > This is for allowing udev rule to set the properties as well.
>> >> > otherwise a kinda crude RUN = " echo value >
>> >> > /sys/module/bq27xxx_battery/parameters/poll_interval" is required.
>> >>
>> >> Any thoughts on this?
>> >
>> > I'd say  echo value >
>> > /sys/module/bq27xxx_battery/parameters/poll_interval .. is quite
>> > adequate solution...?
>> >
>> > Alternatively, convince us that something else is useful for everyone,
>> > and we can do the right thing (poll more often when battery is nearly
>> > empty), automatically...
>>
>> Ok should have had the patchset set it per device, and not use the
>> global poll_interval. Of need to add some logic to see if uses the
>> global poll_interval or it's own setting.
>>
>> There are times where you could have multiple batteries connected to
>> multiple fuel gauges, and want to up the polling interval on certain
>> ones that are discharging at different rates.
>>
>> But of course I'll let you guys let me know if this seems useful at all.
>
> I agree per-device polling would be cleaner.
>

Ok I'll work something up for RFC.

> But unless you have hardware with more than one bq27xxx, I'd avoid the
> work...
>
> Now... its also possible that poll_interval should change itself
> (within kernel) to do the right thing.
>

True but that is state machine territory, but I'll worry about that later...

> Best regards,
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC v2 6/7] mm/powerpc: Use generic VDSO remap and unmap functions

[Michael Ellerman]

Christopher Covington  writes:

> The PowerPC VDSO remap and unmap code was copied to a generic location,
> only modifying the variable name expected in mm->context (vdso instead of
> vdso_base) to match most other architectures. Having adopted this generic
> naming, drop the code in arch/powerpc and use the generic version.
>
> Signed-off-by: Christopher Covington 
> ---
>  arch/powerpc/Kconfig |  1 +
>  arch/powerpc/include/asm/Kbuild  |  1 +
>  arch/powerpc/include/asm/mm-arch-hooks.h | 28 -
>  arch/powerpc/include/asm/mmu_context.h   | 35 
> +---
>  4 files changed, 3 insertions(+), 62 deletions(-)
>  delete mode 100644 arch/powerpc/include/asm/mm-arch-hooks.h

This looks OK.

Have you tested it on powerpc? I could but I don't know how to actually
trigger these paths, I assume I need a CRIU setup?

Can you flip the subject to "powerpc/mm: ...".

cheers

Re: [RFC v2 6/7] mm/powerpc: Use generic VDSO remap and unmap functions

[Michael Ellerman]

Christopher Covington  writes:

> The PowerPC VDSO remap and unmap code was copied to a generic location,
> only modifying the variable name expected in mm->context (vdso instead of
> vdso_base) to match most other architectures. Having adopted this generic
> naming, drop the code in arch/powerpc and use the generic version.
>
> Signed-off-by: Christopher Covington 
> ---
>  arch/powerpc/Kconfig |  1 +
>  arch/powerpc/include/asm/Kbuild  |  1 +
>  arch/powerpc/include/asm/mm-arch-hooks.h | 28 -
>  arch/powerpc/include/asm/mmu_context.h   | 35 
> +---
>  4 files changed, 3 insertions(+), 62 deletions(-)
>  delete mode 100644 arch/powerpc/include/asm/mm-arch-hooks.h

This looks OK.

Have you tested it on powerpc? I could but I don't know how to actually
trigger these paths, I assume I need a CRIU setup?

Can you flip the subject to "powerpc/mm: ...".

cheers

Re: [PATCH v2 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Hi Laurent,

Thank you for the comments.I will fix them in the next patch (v3).

On Thu, 2016-11-03 at 20:34 +0200, Laurent Pinchart wrote:
> Hi Rick,
> 
> A few more comments.
> 
> On Thursday 03 Nov 2016 20:33:12 Laurent Pinchart wrote:
> > On Monday 31 Oct 2016 15:16:55 Rick Chang wrote:
> > > Add a DT binding documentation for Mediatek JPEG Decoder of
> > > MT2701 SoC.
> > > 
> > > Signed-off-by: Rick Chang 
> > > Signed-off-by: Minghsiu Tsai 
> > > ---
> > > 
> > >  .../bindings/media/mediatek-jpeg-codec.txt | 35 
> > >  1 file changed, 35 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > > b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt new
> > > file mode 100644
> > > index 000..514e656
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > > @@ -0,0 +1,35 @@
> > > +* Mediatek JPEG Codec
> > 
> > Is it a codec or a decoder only ?
> > 
> > > +Mediatek JPEG Codec device driver is a v4l2 driver which can decode
> > > +JPEG-encoded video frames.
> > 
> > DT bindings should not reference drivers, they are OS-agnostic.
> > 
> > > +Required properties:
> > > +  - compatible : "mediatek,mt2701-jpgdec"
> 
> Is the JPEG decoder found in MT2701 only, or in other Mediatek SoCs as well ?

Yes, the JPEG decoder is found in other Mediatek SoCs. However, the JPEG
decoder HW in different SoCs have different register base, interrupt,
power-domain and iommu setting. This patch series is only applicable in
MT2701.

> > > +  - reg : Physical base address of the jpeg codec registers and length of
> > > +memory mapped region.
> > > +  - interrupts : interrupt number to the cpu.
> > 
> > That's actually not correct, the interrupt number is local to the interrupt
> > controller, not to the CPU.
> > 
> > > +  - clocks : clock name from clock manager
> > 
> > The clocks property doesn't contain a name.
> 
> Furthermore you should document which clocks need to be specified here. There 
> are two of them in the example below, the documentation should explain this 
> clearly.

OK.

> > Until we provide standardized descriptions for those properties, I recommend
> > copying the compatible, reg, interrupts, clocks, clock-names, power-domains
> > and iommus properties descriptions from good DT bindings. Which DT bindings
> > are good source of inspiration here is left as an exercise for the reader
> > I'm afraid :-(
> > 
> > > +  - clock-names: the clocks of the jpeg codec H/W
> > > +  - power-domains : a phandle to the power domain.
> > > +  - larb : must contain the larbes of current platform
> > 
> > Shouldn't this be mediatek,larb ? And what is a larb ?
> > 
> > > +  - iommus : Mediatek IOMMU H/W has designed the fixed associations with
> > > +the multimedia H/W. and there is only one multimedia iommu
> > > domain.
> > > +"iommus = < portid>" the "portid" is from
> > > +dt-bindings\iommu\mt2701-iommu-port.h, it means that this portid
> > > will
> > > +enable iommu. The portid default is disable iommu if "<>
> > 
> > portid>"
> > 
> > > +don't be added.
> > 
> > There are two iommus instances in your example below, this should be
> > documented. This description is not very clear I'm afraid.
> > 
> > > +
> > > +Example:
> > > + jpegdec: jpegdec@15004000 {
> > > + compatible = "mediatek,mt2701-jpgdec";
> > > + reg = <0 0x15004000 0 0x1000>;
> > > + interrupts = ;
> > > + clocks =  < CLK_IMG_JPGDEC_SMI>,
> > > +   < CLK_IMG_JPGDEC>;
> > > + clock-names = "jpgdec-smi",
> > > +   "jpgdec";
> > > + power-domains = < MT2701_POWER_DOMAIN_ISP>;
> > > + mediatek,larb = <>;
> > > + iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
> > > +  < MT2701_M4U_PORT_JPGDEC_BSDMA>;
> > > + };
> 

Re: [PATCH v2 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Hi Laurent,

Thank you for the comments.I will fix them in the next patch (v3).

On Thu, 2016-11-03 at 20:34 +0200, Laurent Pinchart wrote:
> Hi Rick,
> 
> A few more comments.
> 
> On Thursday 03 Nov 2016 20:33:12 Laurent Pinchart wrote:
> > On Monday 31 Oct 2016 15:16:55 Rick Chang wrote:
> > > Add a DT binding documentation for Mediatek JPEG Decoder of
> > > MT2701 SoC.
> > > 
> > > Signed-off-by: Rick Chang 
> > > Signed-off-by: Minghsiu Tsai 
> > > ---
> > > 
> > >  .../bindings/media/mediatek-jpeg-codec.txt | 35 
> > >  1 file changed, 35 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > > b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt new
> > > file mode 100644
> > > index 000..514e656
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > > @@ -0,0 +1,35 @@
> > > +* Mediatek JPEG Codec
> > 
> > Is it a codec or a decoder only ?
> > 
> > > +Mediatek JPEG Codec device driver is a v4l2 driver which can decode
> > > +JPEG-encoded video frames.
> > 
> > DT bindings should not reference drivers, they are OS-agnostic.
> > 
> > > +Required properties:
> > > +  - compatible : "mediatek,mt2701-jpgdec"
> 
> Is the JPEG decoder found in MT2701 only, or in other Mediatek SoCs as well ?

Yes, the JPEG decoder is found in other Mediatek SoCs. However, the JPEG
decoder HW in different SoCs have different register base, interrupt,
power-domain and iommu setting. This patch series is only applicable in
MT2701.

> > > +  - reg : Physical base address of the jpeg codec registers and length of
> > > +memory mapped region.
> > > +  - interrupts : interrupt number to the cpu.
> > 
> > That's actually not correct, the interrupt number is local to the interrupt
> > controller, not to the CPU.
> > 
> > > +  - clocks : clock name from clock manager
> > 
> > The clocks property doesn't contain a name.
> 
> Furthermore you should document which clocks need to be specified here. There 
> are two of them in the example below, the documentation should explain this 
> clearly.

OK.

> > Until we provide standardized descriptions for those properties, I recommend
> > copying the compatible, reg, interrupts, clocks, clock-names, power-domains
> > and iommus properties descriptions from good DT bindings. Which DT bindings
> > are good source of inspiration here is left as an exercise for the reader
> > I'm afraid :-(
> > 
> > > +  - clock-names: the clocks of the jpeg codec H/W
> > > +  - power-domains : a phandle to the power domain.
> > > +  - larb : must contain the larbes of current platform
> > 
> > Shouldn't this be mediatek,larb ? And what is a larb ?
> > 
> > > +  - iommus : Mediatek IOMMU H/W has designed the fixed associations with
> > > +the multimedia H/W. and there is only one multimedia iommu
> > > domain.
> > > +"iommus = < portid>" the "portid" is from
> > > +dt-bindings\iommu\mt2701-iommu-port.h, it means that this portid
> > > will
> > > +enable iommu. The portid default is disable iommu if "<>
> > 
> > portid>"
> > 
> > > +don't be added.
> > 
> > There are two iommus instances in your example below, this should be
> > documented. This description is not very clear I'm afraid.
> > 
> > > +
> > > +Example:
> > > + jpegdec: jpegdec@15004000 {
> > > + compatible = "mediatek,mt2701-jpgdec";
> > > + reg = <0 0x15004000 0 0x1000>;
> > > + interrupts = ;
> > > + clocks =  < CLK_IMG_JPGDEC_SMI>,
> > > +   < CLK_IMG_JPGDEC>;
> > > + clock-names = "jpgdec-smi",
> > > +   "jpgdec";
> > > + power-domains = < MT2701_POWER_DOMAIN_ISP>;
> > > + mediatek,larb = <>;
> > > + iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
> > > +  < MT2701_M4U_PORT_JPGDEC_BSDMA>;
> > > + };
> 

Re: printk considered harmful (was: [TECH TOPIC] asynchronous printk)

[Jan Kara]

On Fri 04-11-16 03:01:31, Sergey Senozhatsky wrote:
> fix a typo
> 
> On (11/04/16 02:31), Sergey Senozhatsky wrote:
> [..]
> > #4 console semaphore
> > discussion outcome:
> >   we agreed that we can do better here and that it makes sense to do
>    IOW, console semaphore thing
>   can be improved
> 
> >   what's been proposed in my slides. but, I keep it as a low priority.
> >   frankly. I'd be happy to see #1-#3 in the mainline in 9-12 months.
> #1-#2, of course. but #1 consists
>of 2 steps.
> 
> I'm still not entirely sure if I want to split async pintk and printk
> deadlock rework. these things want to come together, for a number of
> reasons. or, at least, push the async printk before printk deadlock
> rework.

Yep, please push async printk patches soon. IMHO there's no reason to wait
with that. You can create a git tree with printk patches and push it directly
to Linus since he seems to be fine with the approach...

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: printk considered harmful (was: [TECH TOPIC] asynchronous printk)

[Jan Kara]

On Fri 04-11-16 03:01:31, Sergey Senozhatsky wrote:
> fix a typo
> 
> On (11/04/16 02:31), Sergey Senozhatsky wrote:
> [..]
> > #4 console semaphore
> > discussion outcome:
> >   we agreed that we can do better here and that it makes sense to do
>    IOW, console semaphore thing
>   can be improved
> 
> >   what's been proposed in my slides. but, I keep it as a low priority.
> >   frankly. I'd be happy to see #1-#3 in the mainline in 9-12 months.
> #1-#2, of course. but #1 consists
>of 2 steps.
> 
> I'm still not entirely sure if I want to split async pintk and printk
> deadlock rework. these things want to come together, for a number of
> reasons. or, at least, push the async printk before printk deadlock
> rework.

Yep, please push async printk patches soon. IMHO there's no reason to wait
with that. You can create a git tree with printk patches and push it directly
to Linus since he seems to be fine with the approach...

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v2 2/3] irqchip: mtk-cirq: Add mediatek mtk-cirq implement

[Youlin Pei]

On Tue, 2016-11-01 at 20:49 +, Marc Zyngier wrote:
> On Tue, Nov 01 2016 at 11:52:01 AM, Youlin Pei  
> wrote:
> > In Mediatek SOCs, the CIRQ is a low power interrupt controller
> > designed to works outside MCUSYS which comprises with Cortex-Ax
> > cores,CCI and GIC.
> >
> > The CIRQ controller is integrated in between MCUSYS( include
> > Cortex-Ax, CCI and GIC ) and interrupt sources as the second
> > level interrupt controller. The external interrupts which outside
> > MCUSYS will feed through CIRQ then bypass to GIC. CIRQ can monitors
> > all edge trigger interupts. When an edge interrupt is triggered,
> > CIRQ can record the status and generate a pulse signal to GIC when
> > flush command executed.
> >
> > When system enters sleep mode, MCUSYS will be turned off to improve
> > power consumption, also GIC is power down. The edge trigger interrupts
> > will be lost in this scenario without CIRQ.
> >
> > This commit provides the CIRQ irqchip implement.
> >
> > Signed-off-by: Youlin Pei 
> > ---
> >  drivers/irqchip/Makefile   |2 +-
> >  drivers/irqchip/irq-mtk-cirq.c |  262 
> > 
> >  2 files changed, 263 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/irqchip/irq-mtk-cirq.c
> >
> > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> > index e4dbfc8..8f33580 100644
> > --- a/drivers/irqchip/Makefile
> > +++ b/drivers/irqchip/Makefile
> > @@ -60,7 +60,7 @@ obj-$(CONFIG_BCM7120_L2_IRQ)  += 
> > irq-bcm7120-l2.o
> >  obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o
> >  obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
> >  obj-$(CONFIG_MIPS_GIC) += irq-mips-gic.o
> > -obj-$(CONFIG_ARCH_MEDIATEK)+= irq-mtk-sysirq.o
> > +obj-$(CONFIG_ARCH_MEDIATEK)+= irq-mtk-sysirq.o 
> > irq-mtk-cirq.o
> >  obj-$(CONFIG_ARCH_DIGICOLOR)   += irq-digicolor.o
> >  obj-$(CONFIG_RENESAS_H8300H_INTC)  += irq-renesas-h8300h.o
> >  obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
> > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
> > new file mode 100644
> > index 000..fc43ef3
> > --- /dev/null
> > +++ b/drivers/irqchip/irq-mtk-cirq.c
> > @@ -0,0 +1,262 @@
> > +/*
> > + * Copyright (c) 2016 MediaTek Inc.
> > + * Author: Youlin.Pei 
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define CIRQ_ACK   0x40
> > +#define CIRQ_MASK_SET  0xc0
> > +#define CIRQ_MASK_CLR  0x100
> > +#define CIRQ_SENS_SET  0x180
> > +#define CIRQ_SENS_CLR  0x1c0
> > +#define CIRQ_POL_SET   0x240
> > +#define CIRQ_POL_CLR   0x280
> > +#define CIRQ_CONTROL   0x300
> > +
> > +#define CIRQ_EN0x1
> > +#define CIRQ_EDGE  0x2
> > +#define CIRQ_FLUSH 0x4
> > +
> > +#define CIRQ_IRQ_NUM0x200
> > +
> > +struct mtk_cirq_chip_data {
> > +   void __iomem *base;
> > +   unsigned int ext_irq_start;
> > +};
> > +
> > +static struct mtk_cirq_chip_data *cirq_data;
> 
> Are you guaranteed that you'll only ever have a single CIRQ in any
> system?

In Mediatek's SOC, only hace a single CIRQ.

> 
> > +
> > +static void mtk_cirq_write_mask(struct irq_data *data, unsigned int offset)
> > +{
> > +   struct mtk_cirq_chip_data *chip_data = data->chip_data;
> > +   unsigned int cirq_num = data->hwirq;
> > +   u32 mask = 1 << (cirq_num % 32);
> > +
> > +   writel(mask, chip_data->base + offset + (cirq_num / 32) * 4);
> 
> Why can't you use the relaxed accessors?

It seems that i use wrong function, i will change the writel to
writel_relaxed in next version.

> 
> > +}
> > +
> > +static void mtk_cirq_mask(struct irq_data *data)
> > +{
> > +   mtk_cirq_write_mask(data, CIRQ_MASK_SET);
> > +   irq_chip_mask_parent(data);
> > +}
> > +
> > +static void mtk_cirq_unmask(struct irq_data *data)
> > +{
> > +   mtk_cirq_write_mask(data, CIRQ_MASK_CLR);
> > +   irq_chip_unmask_parent(data);
> > +}
> > +
> > +static void mtk_cirq_eoi(struct irq_data *data)
> > +{
> > +   mtk_cirq_write_mask(data, CIRQ_ACK);
> 
> EOI and ACK have very different semantics. What is this write actually
> doing? Also, you're now doing an additional MMIO write on each interrupt
> EOI, doubling its cost. Do you really need to do actually signal the HW
> that we've EOIed an interrupt? I would have hoped that 

Re: [PATCH v2 2/3] irqchip: mtk-cirq: Add mediatek mtk-cirq implement

[Youlin Pei]

On Tue, 2016-11-01 at 20:49 +, Marc Zyngier wrote:
> On Tue, Nov 01 2016 at 11:52:01 AM, Youlin Pei  
> wrote:
> > In Mediatek SOCs, the CIRQ is a low power interrupt controller
> > designed to works outside MCUSYS which comprises with Cortex-Ax
> > cores,CCI and GIC.
> >
> > The CIRQ controller is integrated in between MCUSYS( include
> > Cortex-Ax, CCI and GIC ) and interrupt sources as the second
> > level interrupt controller. The external interrupts which outside
> > MCUSYS will feed through CIRQ then bypass to GIC. CIRQ can monitors
> > all edge trigger interupts. When an edge interrupt is triggered,
> > CIRQ can record the status and generate a pulse signal to GIC when
> > flush command executed.
> >
> > When system enters sleep mode, MCUSYS will be turned off to improve
> > power consumption, also GIC is power down. The edge trigger interrupts
> > will be lost in this scenario without CIRQ.
> >
> > This commit provides the CIRQ irqchip implement.
> >
> > Signed-off-by: Youlin Pei 
> > ---
> >  drivers/irqchip/Makefile   |2 +-
> >  drivers/irqchip/irq-mtk-cirq.c |  262 
> > 
> >  2 files changed, 263 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/irqchip/irq-mtk-cirq.c
> >
> > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> > index e4dbfc8..8f33580 100644
> > --- a/drivers/irqchip/Makefile
> > +++ b/drivers/irqchip/Makefile
> > @@ -60,7 +60,7 @@ obj-$(CONFIG_BCM7120_L2_IRQ)  += 
> > irq-bcm7120-l2.o
> >  obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o
> >  obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
> >  obj-$(CONFIG_MIPS_GIC) += irq-mips-gic.o
> > -obj-$(CONFIG_ARCH_MEDIATEK)+= irq-mtk-sysirq.o
> > +obj-$(CONFIG_ARCH_MEDIATEK)+= irq-mtk-sysirq.o 
> > irq-mtk-cirq.o
> >  obj-$(CONFIG_ARCH_DIGICOLOR)   += irq-digicolor.o
> >  obj-$(CONFIG_RENESAS_H8300H_INTC)  += irq-renesas-h8300h.o
> >  obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
> > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
> > new file mode 100644
> > index 000..fc43ef3
> > --- /dev/null
> > +++ b/drivers/irqchip/irq-mtk-cirq.c
> > @@ -0,0 +1,262 @@
> > +/*
> > + * Copyright (c) 2016 MediaTek Inc.
> > + * Author: Youlin.Pei 
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define CIRQ_ACK   0x40
> > +#define CIRQ_MASK_SET  0xc0
> > +#define CIRQ_MASK_CLR  0x100
> > +#define CIRQ_SENS_SET  0x180
> > +#define CIRQ_SENS_CLR  0x1c0
> > +#define CIRQ_POL_SET   0x240
> > +#define CIRQ_POL_CLR   0x280
> > +#define CIRQ_CONTROL   0x300
> > +
> > +#define CIRQ_EN0x1
> > +#define CIRQ_EDGE  0x2
> > +#define CIRQ_FLUSH 0x4
> > +
> > +#define CIRQ_IRQ_NUM0x200
> > +
> > +struct mtk_cirq_chip_data {
> > +   void __iomem *base;
> > +   unsigned int ext_irq_start;
> > +};
> > +
> > +static struct mtk_cirq_chip_data *cirq_data;
> 
> Are you guaranteed that you'll only ever have a single CIRQ in any
> system?

In Mediatek's SOC, only hace a single CIRQ.

> 
> > +
> > +static void mtk_cirq_write_mask(struct irq_data *data, unsigned int offset)
> > +{
> > +   struct mtk_cirq_chip_data *chip_data = data->chip_data;
> > +   unsigned int cirq_num = data->hwirq;
> > +   u32 mask = 1 << (cirq_num % 32);
> > +
> > +   writel(mask, chip_data->base + offset + (cirq_num / 32) * 4);
> 
> Why can't you use the relaxed accessors?

It seems that i use wrong function, i will change the writel to
writel_relaxed in next version.

> 
> > +}
> > +
> > +static void mtk_cirq_mask(struct irq_data *data)
> > +{
> > +   mtk_cirq_write_mask(data, CIRQ_MASK_SET);
> > +   irq_chip_mask_parent(data);
> > +}
> > +
> > +static void mtk_cirq_unmask(struct irq_data *data)
> > +{
> > +   mtk_cirq_write_mask(data, CIRQ_MASK_CLR);
> > +   irq_chip_unmask_parent(data);
> > +}
> > +
> > +static void mtk_cirq_eoi(struct irq_data *data)
> > +{
> > +   mtk_cirq_write_mask(data, CIRQ_ACK);
> 
> EOI and ACK have very different semantics. What is this write actually
> doing? Also, you're now doing an additional MMIO write on each interrupt
> EOI, doubling its cost. Do you really need to do actually signal the HW
> that we've EOIed an interrupt? I would have hoped that you'd be able to
> put it in "bypass" mode as long as you're not suspending...

Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver

[Andi Shyti]

Hi Jacek,

> > > Only DT bindings of LED class drivers should be placed in
> > > Documentation/devicetree/bindings/leds. Please move it to the
> > > media bindings.
> > 
> > that's where I placed it first, but Rob asked me to put it in the
> > LED directory and Cc the LED mailining list.
> > 
> > That's the discussion of the version 2:
> > 
> > https://lkml.org/lkml/2016/9/12/380
> > 
> > Rob, Jacek, could you please agree where I can put the binding?
> 
> I'm not sure if this is a good approach. I've noticed also that
> backlight bindings have been moved to leds, whereas they don't look
> similarly.
> 
> We have common.txt LED bindings, that all LED class drivers' bindings
> have to follow. Neither backlight bindings nor these ones do that,
> which introduces some mess.
> 
> Eventually adding a sub-directory, e.g. remote_control could make it
> somehow logically justified, but still - shouldn't bindings be
> placed in the documentation directory related to the subsystem of the
> driver they are predestined to?

In principle I agree with you, also because I understood that the
led kind of bindings are for those LEDs which main function is to
emit light.

There is no need for a remote control directory, because there is
one already under bindings/media, where all the remote
controllers are placed.

Now this is a matter of interpretation, is this an IR LED used by
the driver as remote controller or is this a remote controller
with just an IR LED?

In any case, I will wait for you and Rob to agree where is best
to place the binding, then I will send a new version.

Thanks,
Andi

Re: [PATCH v3 5/6] Documentation: bindings: add documentation for ir-spi device driver

[Andi Shyti]

Hi Jacek,

> > > Only DT bindings of LED class drivers should be placed in
> > > Documentation/devicetree/bindings/leds. Please move it to the
> > > media bindings.
> > 
> > that's where I placed it first, but Rob asked me to put it in the
> > LED directory and Cc the LED mailining list.
> > 
> > That's the discussion of the version 2:
> > 
> > https://lkml.org/lkml/2016/9/12/380
> > 
> > Rob, Jacek, could you please agree where I can put the binding?
> 
> I'm not sure if this is a good approach. I've noticed also that
> backlight bindings have been moved to leds, whereas they don't look
> similarly.
> 
> We have common.txt LED bindings, that all LED class drivers' bindings
> have to follow. Neither backlight bindings nor these ones do that,
> which introduces some mess.
> 
> Eventually adding a sub-directory, e.g. remote_control could make it
> somehow logically justified, but still - shouldn't bindings be
> placed in the documentation directory related to the subsystem of the
> driver they are predestined to?

In principle I agree with you, also because I understood that the
led kind of bindings are for those LEDs which main function is to
emit light.

There is no need for a remote control directory, because there is
one already under bindings/media, where all the remote
controllers are placed.

Now this is a matter of interpretation, is this an IR LED used by
the driver as remote controller or is this a remote controller
with just an IR LED?

In any case, I will wait for you and Rob to agree where is best
to place the binding, then I will send a new version.

Thanks,
Andi

Re: [PATCH 04/12] xen: make use of xenbus_read_unsigned() in xen-tpmfront

[Jarkko Sakkinen]

On Mon, Oct 31, 2016 at 05:48:22PM +0100, Juergen Gross wrote:
> Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
> This requires to change the type of one read from int to unsigned,
> but this case has been wrong before: negative values are not allowed
> for the modified case.
> 
> Cc: peterhu...@gmx.de
> Cc: tp...@selhorst.net
> Cc: jarkko.sakki...@linux.intel.com
> Cc: jguntho...@obsidianresearch.com
> Cc: tpmdd-de...@lists.sourceforge.net
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jarkko Sakkinen 

/Jarkko

> ---
>  drivers/char/tpm/xen-tpmfront.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
> index 62028f4..50072cc 100644
> --- a/drivers/char/tpm/xen-tpmfront.c
> +++ b/drivers/char/tpm/xen-tpmfront.c
> @@ -337,18 +337,14 @@ static int tpmfront_resume(struct xenbus_device *dev)
>  static void backend_changed(struct xenbus_device *dev,
>   enum xenbus_state backend_state)
>  {
> - int val;
> -
>   switch (backend_state) {
>   case XenbusStateInitialised:
>   case XenbusStateConnected:
>   if (dev->state == XenbusStateConnected)
>   break;
>  
> - if (xenbus_scanf(XBT_NIL, dev->otherend,
> - "feature-protocol-v2", "%d", ) < 0)
> - val = 0;
> - if (!val) {
> + if (!xenbus_read_unsigned(dev->otherend, "feature-protocol-v2",
> +   0)) {
>   xenbus_dev_fatal(dev, -EINVAL,
>   "vTPM protocol 2 required");
>   return;
> -- 
> 2.6.6
> 

Re: [PATCH 04/12] xen: make use of xenbus_read_unsigned() in xen-tpmfront

[Jarkko Sakkinen]

On Mon, Oct 31, 2016 at 05:48:22PM +0100, Juergen Gross wrote:
> Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
> This requires to change the type of one read from int to unsigned,
> but this case has been wrong before: negative values are not allowed
> for the modified case.
> 
> Cc: peterhu...@gmx.de
> Cc: tp...@selhorst.net
> Cc: jarkko.sakki...@linux.intel.com
> Cc: jguntho...@obsidianresearch.com
> Cc: tpmdd-de...@lists.sourceforge.net
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jarkko Sakkinen 

/Jarkko

> ---
>  drivers/char/tpm/xen-tpmfront.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
> index 62028f4..50072cc 100644
> --- a/drivers/char/tpm/xen-tpmfront.c
> +++ b/drivers/char/tpm/xen-tpmfront.c
> @@ -337,18 +337,14 @@ static int tpmfront_resume(struct xenbus_device *dev)
>  static void backend_changed(struct xenbus_device *dev,
>   enum xenbus_state backend_state)
>  {
> - int val;
> -
>   switch (backend_state) {
>   case XenbusStateInitialised:
>   case XenbusStateConnected:
>   if (dev->state == XenbusStateConnected)
>   break;
>  
> - if (xenbus_scanf(XBT_NIL, dev->otherend,
> - "feature-protocol-v2", "%d", ) < 0)
> - val = 0;
> - if (!val) {
> + if (!xenbus_read_unsigned(dev->otherend, "feature-protocol-v2",
> +   0)) {
>   xenbus_dev_fatal(dev, -EINVAL,
>   "vTPM protocol 2 required");
>   return;
> -- 
> 2.6.6
> 

Re: [PATCH 2/2] tpm/tpm2-chip: fix kdoc errors

[Jarkko Sakkinen]

On Tue, Nov 01, 2016 at 03:05:14AM +0200, Tomas Winkler wrote:
> Use correct kdoc format, describe correct parameters and return values.
> 
> Signed-off-by: Tomas Winkler 
> ---
>  drivers/char/tpm/tpm2-cmd.c | 107 
> +++-
>  1 file changed, 66 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index 7df55d58c939..a7a519c87bee 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -258,11 +258,13 @@ static const struct tpm_input_header 
> tpm2_pcrread_header = {
>   * tpm2_pcr_read() - read a PCR value
>   * @chip:TPM chip to use.
>   * @pcr_idx: index of the PCR to read.
> - * @ref_buf: buffer to store the resulting hash,
> + * @res_buf: buffer to store the resulting hash,
>   *
> - * 0 is returned when the operation is successful. If a negative number is
> - * returned it remarks a POSIX error code. If a positive number is returned
> - * it remarks a TPM error.
> + *
> + * Return:
> + * 0 when the operation is successful
> + * A negative number for system errors (errno)
> + * A positive number for a TPM error.
>   */
>  int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
>  {
> @@ -304,13 +306,15 @@ static const struct tpm_input_header 
> tpm2_pcrextend_header = {
>  
>  /**
>   * tpm2_pcr_extend() - extend a PCR value
> + *
>   * @chip:TPM chip to use.
>   * @pcr_idx: index of the PCR.
>   * @hash:hash value to use for the extend operation.
>   *
> - * 0 is returned when the operation is successful. If a negative number is
> - * returned it remarks a POSIX error code. If a positive number is returned
> - * it remarks a TPM error.
> + * Return:
> + * 0 when the operation is successful
> + * A negative number for system errors (errno)
> + * A positive number for a TPM error.

Put this to tpm_transmit_cmd only and refer to that from other functions
with "same as with tpm_transmit_cmd()" with parenthesis because that
marks in rst a link to that function.

/Jarkko

Re: [PATCH 2/2] tpm/tpm2-chip: fix kdoc errors

[Jarkko Sakkinen]

On Tue, Nov 01, 2016 at 03:05:14AM +0200, Tomas Winkler wrote:
> Use correct kdoc format, describe correct parameters and return values.
> 
> Signed-off-by: Tomas Winkler 
> ---
>  drivers/char/tpm/tpm2-cmd.c | 107 
> +++-
>  1 file changed, 66 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index 7df55d58c939..a7a519c87bee 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -258,11 +258,13 @@ static const struct tpm_input_header 
> tpm2_pcrread_header = {
>   * tpm2_pcr_read() - read a PCR value
>   * @chip:TPM chip to use.
>   * @pcr_idx: index of the PCR to read.
> - * @ref_buf: buffer to store the resulting hash,
> + * @res_buf: buffer to store the resulting hash,
>   *
> - * 0 is returned when the operation is successful. If a negative number is
> - * returned it remarks a POSIX error code. If a positive number is returned
> - * it remarks a TPM error.
> + *
> + * Return:
> + * 0 when the operation is successful
> + * A negative number for system errors (errno)
> + * A positive number for a TPM error.
>   */
>  int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
>  {
> @@ -304,13 +306,15 @@ static const struct tpm_input_header 
> tpm2_pcrextend_header = {
>  
>  /**
>   * tpm2_pcr_extend() - extend a PCR value
> + *
>   * @chip:TPM chip to use.
>   * @pcr_idx: index of the PCR.
>   * @hash:hash value to use for the extend operation.
>   *
> - * 0 is returned when the operation is successful. If a negative number is
> - * returned it remarks a POSIX error code. If a positive number is returned
> - * it remarks a TPM error.
> + * Return:
> + * 0 when the operation is successful
> + * A negative number for system errors (errno)
> + * A positive number for a TPM error.

Put this to tpm_transmit_cmd only and refer to that from other functions
with "same as with tpm_transmit_cmd()" with parenthesis because that
marks in rst a link to that function.

/Jarkko

Re: [PATCH v2 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Hi Laurent,

Thanks for your patient review.I will fix them in the next patch (v3).

On Thu, 2016-11-03 at 20:33 +0200, Laurent Pinchart wrote:
> Hi Rick,
> 
> Thank you for the patch.
> 
> On Monday 31 Oct 2016 15:16:55 Rick Chang wrote:
> > Add a DT binding documentation for Mediatek JPEG Decoder of
> > MT2701 SoC.
> > 
> > Signed-off-by: Rick Chang 
> > Signed-off-by: Minghsiu Tsai 
> > ---
> >  .../bindings/media/mediatek-jpeg-codec.txt | 35 +++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt new file
> > mode 100644
> > index 000..514e656
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > @@ -0,0 +1,35 @@
> > +* Mediatek JPEG Codec
> 
> Is it a codec or a decoder only ?

It's a decoder precisely.

> > +Mediatek JPEG Codec device driver is a v4l2 driver which can decode
> > +JPEG-encoded video frames.
> 
> DT bindings should not reference drivers, they are OS-agnostic.

OK.

> > +Required properties:
> > +  - compatible : "mediatek,mt2701-jpgdec"
> > +  - reg : Physical base address of the jpeg codec registers and length of
> > +memory mapped region.
> > +  - interrupts : interrupt number to the cpu.
> 
> That's actually not correct, the interrupt number is local to the interrupt 
> controller, not to the CPU.

OK.

> > +  - clocks : clock name from clock manager
> 
> The clocks property doesn't contain a name.

OK.

> Until we provide standardized descriptions for those properties, I recommend 
> copying the compatible, reg, interrupts, clocks, clock-names, power-domains 
> and iommus properties descriptions from good DT bindings. Which DT bindings 
> are good source of inspiration here is left as an exercise for the reader I'm 
> afraid :-(

Thank you for the advice. I will revise the descriptions with the
statements in existed upstream documents.

> > +  - clock-names: the clocks of the jpeg codec H/W
> > +  - power-domains : a phandle to the power domain.
> > +  - larb : must contain the larbes of current platform
> 
> Shouldn't this be mediatek,larb ? And what is a larb ?

It should be mediatek,larb.

> > +  - iommus : Mediatek IOMMU H/W has designed the fixed associations with
> > +the multimedia H/W. and there is only one multimedia iommu domain.
> > +"iommus = < portid>" the "portid" is from
> > +dt-bindings\iommu\mt2701-iommu-port.h, it means that this portid
> > will
> > +enable iommu. The portid default is disable iommu if "<> 
> portid>"
> > +don't be added.
> 
> There are two iommus instances in your example below, this should be 
> documented. This description is not very clear I'm afraid.

OK.

> > +
> > +Example:
> > +   jpegdec: jpegdec@15004000 {
> > +   compatible = "mediatek,mt2701-jpgdec";
> > +   reg = <0 0x15004000 0 0x1000>;
> > +   interrupts = ;
> > +   clocks =  < CLK_IMG_JPGDEC_SMI>,
> > + < CLK_IMG_JPGDEC>;
> > +   clock-names = "jpgdec-smi",
> > + "jpgdec";
> > +   power-domains = < MT2701_POWER_DOMAIN_ISP>;
> > +   mediatek,larb = <>;
> > +   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
> > +< MT2701_M4U_PORT_JPGDEC_BSDMA>;
> > +   };
> 

Re: [PATCH v2 1/3] dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder

[Rick Chang]

Hi Laurent,

Thanks for your patient review.I will fix them in the next patch (v3).

On Thu, 2016-11-03 at 20:33 +0200, Laurent Pinchart wrote:
> Hi Rick,
> 
> Thank you for the patch.
> 
> On Monday 31 Oct 2016 15:16:55 Rick Chang wrote:
> > Add a DT binding documentation for Mediatek JPEG Decoder of
> > MT2701 SoC.
> > 
> > Signed-off-by: Rick Chang 
> > Signed-off-by: Minghsiu Tsai 
> > ---
> >  .../bindings/media/mediatek-jpeg-codec.txt | 35 +++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt new file
> > mode 100644
> > index 000..514e656
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-codec.txt
> > @@ -0,0 +1,35 @@
> > +* Mediatek JPEG Codec
> 
> Is it a codec or a decoder only ?

It's a decoder precisely.

> > +Mediatek JPEG Codec device driver is a v4l2 driver which can decode
> > +JPEG-encoded video frames.
> 
> DT bindings should not reference drivers, they are OS-agnostic.

OK.

> > +Required properties:
> > +  - compatible : "mediatek,mt2701-jpgdec"
> > +  - reg : Physical base address of the jpeg codec registers and length of
> > +memory mapped region.
> > +  - interrupts : interrupt number to the cpu.
> 
> That's actually not correct, the interrupt number is local to the interrupt 
> controller, not to the CPU.

OK.

> > +  - clocks : clock name from clock manager
> 
> The clocks property doesn't contain a name.

OK.

> Until we provide standardized descriptions for those properties, I recommend 
> copying the compatible, reg, interrupts, clocks, clock-names, power-domains 
> and iommus properties descriptions from good DT bindings. Which DT bindings 
> are good source of inspiration here is left as an exercise for the reader I'm 
> afraid :-(

Thank you for the advice. I will revise the descriptions with the
statements in existed upstream documents.

> > +  - clock-names: the clocks of the jpeg codec H/W
> > +  - power-domains : a phandle to the power domain.
> > +  - larb : must contain the larbes of current platform
> 
> Shouldn't this be mediatek,larb ? And what is a larb ?

It should be mediatek,larb.

> > +  - iommus : Mediatek IOMMU H/W has designed the fixed associations with
> > +the multimedia H/W. and there is only one multimedia iommu domain.
> > +"iommus = < portid>" the "portid" is from
> > +dt-bindings\iommu\mt2701-iommu-port.h, it means that this portid
> > will
> > +enable iommu. The portid default is disable iommu if "<> 
> portid>"
> > +don't be added.
> 
> There are two iommus instances in your example below, this should be 
> documented. This description is not very clear I'm afraid.

OK.

> > +
> > +Example:
> > +   jpegdec: jpegdec@15004000 {
> > +   compatible = "mediatek,mt2701-jpgdec";
> > +   reg = <0 0x15004000 0 0x1000>;
> > +   interrupts = ;
> > +   clocks =  < CLK_IMG_JPGDEC_SMI>,
> > + < CLK_IMG_JPGDEC>;
> > +   clock-names = "jpgdec-smi",
> > + "jpgdec";
> > +   power-domains = < MT2701_POWER_DOMAIN_ISP>;
> > +   mediatek,larb = <>;
> > +   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
> > +< MT2701_M4U_PORT_JPGDEC_BSDMA>;
> > +   };
> 

Re: [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II)

[Alex Williamson]

On Thu,  3 Nov 2016 21:39:30 +
Eric Auger  wrote:

> Following Will & Robin's suggestions, this series attempts to propose
> an alternative to [1] where the host would arbitrarily decide the
> location of the IOVA MSI window and would be able to report to the
> userspace the list of reserved IOVA regions that cannot be used
> along with VFIO_IOMMU_MAP_DMA. This would allow the userspace to react
> in case of conflict.
> 
> Userspace can retrieve all the reserved regions through the 
> VFIO_IOMMU_GET_INFO
> IOCTL by querying the new RESV_IOVA_RANGE chained capability. Each reserved
> IOVA range is put in a separate capability.

Doesn't it make more sense to describe the non-holes (ie. what I
can use for DMA) rather the holes (what I can't use for DMA)?  For
example on VT-d, the IOMMU not only has the block of MSI addresses
handled through interrupt remapping, but it also has a maximum address
width.  Rather than describing the reserved space we could describe the
usable DMA ranges above and below that reserved block.

Anyway, there's also a pretty harsh problem that I came up with in
talking to Will.  If the platform describes a fixed IOVA range as
reserved, that's great for the use case when a VM is instantiated with
a device attached, but it seems like it nearly excludes the case of
hotplugging a device.  We can't dynamically decide that a set of RAM
pages in the VM cannot be used as a DMA target.  Does the user need to
create the VM with a predefined hole that lines up with the reserved
regions for this platform?  How do they know the reserved regions for
this platform?  How would we handle migration where an assigned device
hot-add might not occur until after we've migrated to a slightly
different platform from the one we started on, that might have
different reserved memory requirements?

We can always have QEMU reject hot-adding the device if the reserved
region overlaps existing guest RAM, but I don't even really see how we
advise users to give them a reasonable chance of avoiding that
possibility.  Apparently there are also ARM platforms where MSI pages
cannot be remapped to support the previous programmable user/VM
address, is it even worthwhile to support those platforms?  Does that
decision influence whether user programmable MSI reserved regions are
really a second class citizen to fixed reserved regions?  I expect
we'll be talking about this tomorrow morning, but I certainly haven't
come up with any viable solutions to this.  Thanks,

Alex

> At IOMMU level, the reserved regions are stored in an iommu_domain list
> which is populated on each device attachment. An IOMMU add_reserved_regions
> callback specializes the registration of the reserved regions.
> 
> On x86, the [FEE0_h - FEF0_000h] MSI window is registered (NOT tested).
> 
> On ARM, the PCI host bridge windows (ACS check to be added?) + the MSI IOVA
> reserved regions are populated by the arm-smmu driver. Currently the MSI
> IOVA region is arbitrarily located at 0x800 and 1MB sized.  An IOVA domain
> is created in add_reserved_regions callback. Then MSIs are transparently
> mapped using this IOVA domain.
> 
> This series currently does not address some features addressed in [1]:
> - MSI IOVA size requirement computation
> - IRQ safety assessment
> 
> This RFC was just tested on ARM Overdrive with QEMU and is sent to help
> potential discussions at LPC. Additionnal development + testing is needed.
> 
> 2 tentative fixes may be submitted separately:
> - vfio: fix vfio_info_cap_add/shift
> - iommu/iova: fix __alloc_and_insert_iova_range
> 
> Best Regards
> 
> Eric
> 
> [1] [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64
> https://lkml.org/lkml/2016/10/12/347
> 
> Git: complete series available at
> https://github.com/eauger/linux/tree/v4.9-rc3-reserved-rfc
> 
> 
> Eric Auger (7):
>   vfio: fix vfio_info_cap_add/shift
>   iommu/iova: fix __alloc_and_insert_iova_range
>   iommu: Add a list of iommu_reserved_region in iommu_domain
>   vfio/type1: Introduce RESV_IOVA_RANGE capability
>   iommu: Handle the list of reserved regions
>   iommu/vt-d: Implement add_reserved_regions callback
>   iommu/arm-smmu: implement add_reserved_regions callback
> 
> Robin Murphy (1):
>   iommu/dma: Allow MSI-only cookies
> 
>  drivers/iommu/arm-smmu.c| 63 
> +
>  drivers/iommu/dma-iommu.c   | 39 +
>  drivers/iommu/intel-iommu.c | 48 ++-
>  drivers/iommu/iommu.c   | 25 
>  drivers/iommu/iova.c|  2 +-
>  drivers/vfio/vfio.c |  5 ++--
>  drivers/vfio/vfio_iommu_type1.c | 63 
> -
>  include/linux/dma-iommu.h   |  9 ++
>  include/linux/iommu.h   | 23 +++
>  include/uapi/linux/vfio.h   | 16 ++-
>  10 files changed, 275 insertions(+), 18 deletions(-)
> 

Re: [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II)

[Alex Williamson]

On Thu,  3 Nov 2016 21:39:30 +
Eric Auger  wrote:

> Following Will & Robin's suggestions, this series attempts to propose
> an alternative to [1] where the host would arbitrarily decide the
> location of the IOVA MSI window and would be able to report to the
> userspace the list of reserved IOVA regions that cannot be used
> along with VFIO_IOMMU_MAP_DMA. This would allow the userspace to react
> in case of conflict.
> 
> Userspace can retrieve all the reserved regions through the 
> VFIO_IOMMU_GET_INFO
> IOCTL by querying the new RESV_IOVA_RANGE chained capability. Each reserved
> IOVA range is put in a separate capability.

Doesn't it make more sense to describe the non-holes (ie. what I
can use for DMA) rather the holes (what I can't use for DMA)?  For
example on VT-d, the IOMMU not only has the block of MSI addresses
handled through interrupt remapping, but it also has a maximum address
width.  Rather than describing the reserved space we could describe the
usable DMA ranges above and below that reserved block.

Anyway, there's also a pretty harsh problem that I came up with in
talking to Will.  If the platform describes a fixed IOVA range as
reserved, that's great for the use case when a VM is instantiated with
a device attached, but it seems like it nearly excludes the case of
hotplugging a device.  We can't dynamically decide that a set of RAM
pages in the VM cannot be used as a DMA target.  Does the user need to
create the VM with a predefined hole that lines up with the reserved
regions for this platform?  How do they know the reserved regions for
this platform?  How would we handle migration where an assigned device
hot-add might not occur until after we've migrated to a slightly
different platform from the one we started on, that might have
different reserved memory requirements?

We can always have QEMU reject hot-adding the device if the reserved
region overlaps existing guest RAM, but I don't even really see how we
advise users to give them a reasonable chance of avoiding that
possibility.  Apparently there are also ARM platforms where MSI pages
cannot be remapped to support the previous programmable user/VM
address, is it even worthwhile to support those platforms?  Does that
decision influence whether user programmable MSI reserved regions are
really a second class citizen to fixed reserved regions?  I expect
we'll be talking about this tomorrow morning, but I certainly haven't
come up with any viable solutions to this.  Thanks,

Alex

> At IOMMU level, the reserved regions are stored in an iommu_domain list
> which is populated on each device attachment. An IOMMU add_reserved_regions
> callback specializes the registration of the reserved regions.
> 
> On x86, the [FEE0_h - FEF0_000h] MSI window is registered (NOT tested).
> 
> On ARM, the PCI host bridge windows (ACS check to be added?) + the MSI IOVA
> reserved regions are populated by the arm-smmu driver. Currently the MSI
> IOVA region is arbitrarily located at 0x800 and 1MB sized.  An IOVA domain
> is created in add_reserved_regions callback. Then MSIs are transparently
> mapped using this IOVA domain.
> 
> This series currently does not address some features addressed in [1]:
> - MSI IOVA size requirement computation
> - IRQ safety assessment
> 
> This RFC was just tested on ARM Overdrive with QEMU and is sent to help
> potential discussions at LPC. Additionnal development + testing is needed.
> 
> 2 tentative fixes may be submitted separately:
> - vfio: fix vfio_info_cap_add/shift
> - iommu/iova: fix __alloc_and_insert_iova_range
> 
> Best Regards
> 
> Eric
> 
> [1] [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64
> https://lkml.org/lkml/2016/10/12/347
> 
> Git: complete series available at
> https://github.com/eauger/linux/tree/v4.9-rc3-reserved-rfc
> 
> 
> Eric Auger (7):
>   vfio: fix vfio_info_cap_add/shift
>   iommu/iova: fix __alloc_and_insert_iova_range
>   iommu: Add a list of iommu_reserved_region in iommu_domain
>   vfio/type1: Introduce RESV_IOVA_RANGE capability
>   iommu: Handle the list of reserved regions
>   iommu/vt-d: Implement add_reserved_regions callback
>   iommu/arm-smmu: implement add_reserved_regions callback
> 
> Robin Murphy (1):
>   iommu/dma: Allow MSI-only cookies
> 
>  drivers/iommu/arm-smmu.c| 63 
> +
>  drivers/iommu/dma-iommu.c   | 39 +
>  drivers/iommu/intel-iommu.c | 48 ++-
>  drivers/iommu/iommu.c   | 25 
>  drivers/iommu/iova.c|  2 +-
>  drivers/vfio/vfio.c |  5 ++--
>  drivers/vfio/vfio_iommu_type1.c | 63 
> -
>  include/linux/dma-iommu.h   |  9 ++
>  include/linux/iommu.h   | 23 +++
>  include/uapi/linux/vfio.h   | 16 ++-
>  10 files changed, 275 insertions(+), 18 deletions(-)
> 

Re: [PATCH V2 2/2] blk-mq: immediately dispatch big size request

[Jens Axboe]

On 11/03/2016 06:13 PM, Shaohua Li wrote:

On Thu, Nov 03, 2016 at 05:09:54PM -0700, Christoph Hellwig wrote:

On Thu, Nov 03, 2016 at 05:03:54PM -0700, Shaohua Li wrote:

This is corresponding part for blk-mq. Disk with multiple hardware
queues doesn't need this as we only hold 1 request at most.


Any reason you only do this for the SQ and not the MQ case?


Right above:
Disk with multiple hardware queues doesn't need this as we only hold 1
request at most.


I've applied 1-2 for 4.10, but we probably should look into unifying
those parts of sq and mq in general. For instance, it doesn't seem to
make a lot of sense why we'd depth limit sq and not mq.

--
Jens Axboe

Re: [PATCH V2 2/2] blk-mq: immediately dispatch big size request

[Jens Axboe]

On 11/03/2016 06:13 PM, Shaohua Li wrote:

On Thu, Nov 03, 2016 at 05:09:54PM -0700, Christoph Hellwig wrote:

On Thu, Nov 03, 2016 at 05:03:54PM -0700, Shaohua Li wrote:

This is corresponding part for blk-mq. Disk with multiple hardware
queues doesn't need this as we only hold 1 request at most.


Any reason you only do this for the SQ and not the MQ case?


Right above:
Disk with multiple hardware queues doesn't need this as we only hold 1
request at most.


I've applied 1-2 for 4.10, but we probably should look into unifying
those parts of sq and mq in general. For instance, it doesn't seem to
make a lot of sense why we'd depth limit sq and not mq.

--
Jens Axboe

Re: [PATCH v2 4/6] pinctrl: aspeed: Read and write bits in LPCHC and GFX controllers

[Andrew Jeffery]

On Fri, 2016-11-04 at 09:54 +1030, Joel Stanley wrote:
> On Thu, Nov 3, 2016 at 1:07 AM, Andrew Jeffery  wrote:
> > 
> > The System Control Unit IP block in the Aspeed SoCs is typically where
> > the pinmux configuration is found, but not always. A number of pins
> > depend on state in one of LPC Host Control (LPCHC) or SoC Display
> > Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> > means to adjust these as necessary.
> > 
> > We use syscon to cast a regmap over the GFX and LPCHCR blocks, which is
> > used as an arbitration layer between the relevant driver and the pinctrl
> > subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> > drivers by phandles in the devicetree, and are selected during a mux
> > request by querying a new 'ip' member in struct aspeed_sig_desc.
> > 
> > Signed-off-by: Andrew Jeffery 
> I like this a lot more than the first go. Good work.
> 
> Some minor comments below.
> 
> > 
> > ---
> > Since v1:
> > 
> > The change is now proactive: instead of reporting that we need to flip bits 
> > in
> > controllers we can't access, the patch provides access via regmaps for the
> > relevant controllers. The implementation also splits out the IP block ID 
> > into
> > its own variable rather than packing the value into the upper bits of the 
> > reg
> > member of struct aspeed_sig_desc. This drives some churn in the diff, but 
> > I've
> > tried to minimise it.
> > 
> >  .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 +---
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 18 +++---
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 39 ++---
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.c| 66 
> > +-
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.h| 32 ---
> >  5 files changed, 144 insertions(+), 61 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > index 2ad18c4ea55c..115b0cce6c1c 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> >  The Aspeed SoCs vary in functionality inside a generation but have a 
> > common mux
> >  device register layout.
> > 
> > -Required properties:
> > -- compatible : Should be any one of the following:
> > -   "aspeed,ast2400-pinctrl"
> > -   "aspeed,g4-pinctrl"
> > -   "aspeed,ast2500-pinctrl"
> > -   "aspeed,g5-pinctrl"
> > +Required properties for g4:
> > +- compatible : Should be any one of the following:
> > +   "aspeed,ast2400-pinctrl"
> > +   "aspeed,g4-pinctrl"
> > +
> > +Required properties for g5:
> > +- compatible : Should be any one of the following:
> > +   "aspeed,ast2500-pinctrl"
> > +   "aspeed,g5-pinctrl"
> > +
> > +- aspeed,external-nodes:   A cell of phandles to external controller 
> > nodes:
> > +   0: compatible with "aspeed,ast2500-gfx", 
> > "syscon"
> > +   1: compatible with "aspeed,ast2500-lpchc", 
> > "syscon"
> > 
> >  The pin controller node should be a child of a syscon node with the 
> > required
> >  property:
> > @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU 
> > TIMER4 TIMER5 TIMER6
> >  TIMER7 TIMER8 VGABIOSROM
> > 
> > 
> > -Examples:
> > +g4 Example:
> > 
> >  syscon: scu@1e6e2000 {
> > compatible = "syscon", "simple-mfd";
> > @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
> > };
> >  };
> > 
> > +g5 Example:
> > +
> > +apb {
> > +   gfx: display@1e6e6000 {
> > +   compatible = "aspeed,ast2500-gfx", "syscon";
> > +   reg = <0x1e6e6000 0x1000>;
> > +   };
> > +
> > +   lpchc: lpchc@1e7890a0 {
> > +   compatible = "aspeed,ast2500-lpchc", "syscon";
> > +   reg = <0x1e7890a0 0xc4>;
> > +   };
> > +
> > +   syscon: scu@1e6e2000 {
> > +   compatible = "syscon", "simple-mfd";
> > +   reg = <0x1e6e2000 0x1a8>;
> > +
> > +   pinctrl: pinctrl {
> > +   compatible = "aspeed,g5-pinctrl";
> > +   aspeed,external-nodes = <, >;
> > +
> > +   pinctrl_i2c3_default: i2c3_default {
> > +   function = "I2C3";
> > +   groups = "I2C3";
> > +   };
> > +   };
> > +   };
> > +};
> > +
> >  Please refer to pinctrl-bindings.txt in this directory for details of the
> >  common pinctrl bindings used by client devices.
> > diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
> > 

Re: [PATCH v2 4/6] pinctrl: aspeed: Read and write bits in LPCHC and GFX controllers

[Andrew Jeffery]

On Fri, 2016-11-04 at 09:54 +1030, Joel Stanley wrote:
> On Thu, Nov 3, 2016 at 1:07 AM, Andrew Jeffery  wrote:
> > 
> > The System Control Unit IP block in the Aspeed SoCs is typically where
> > the pinmux configuration is found, but not always. A number of pins
> > depend on state in one of LPC Host Control (LPCHC) or SoC Display
> > Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> > means to adjust these as necessary.
> > 
> > We use syscon to cast a regmap over the GFX and LPCHCR blocks, which is
> > used as an arbitration layer between the relevant driver and the pinctrl
> > subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> > drivers by phandles in the devicetree, and are selected during a mux
> > request by querying a new 'ip' member in struct aspeed_sig_desc.
> > 
> > Signed-off-by: Andrew Jeffery 
> I like this a lot more than the first go. Good work.
> 
> Some minor comments below.
> 
> > 
> > ---
> > Since v1:
> > 
> > The change is now proactive: instead of reporting that we need to flip bits 
> > in
> > controllers we can't access, the patch provides access via regmaps for the
> > relevant controllers. The implementation also splits out the IP block ID 
> > into
> > its own variable rather than packing the value into the upper bits of the 
> > reg
> > member of struct aspeed_sig_desc. This drives some churn in the diff, but 
> > I've
> > tried to minimise it.
> > 
> >  .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 +---
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 18 +++---
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 39 ++---
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.c| 66 
> > +-
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.h| 32 ---
> >  5 files changed, 144 insertions(+), 61 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > index 2ad18c4ea55c..115b0cce6c1c 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> >  The Aspeed SoCs vary in functionality inside a generation but have a 
> > common mux
> >  device register layout.
> > 
> > -Required properties:
> > -- compatible : Should be any one of the following:
> > -   "aspeed,ast2400-pinctrl"
> > -   "aspeed,g4-pinctrl"
> > -   "aspeed,ast2500-pinctrl"
> > -   "aspeed,g5-pinctrl"
> > +Required properties for g4:
> > +- compatible : Should be any one of the following:
> > +   "aspeed,ast2400-pinctrl"
> > +   "aspeed,g4-pinctrl"
> > +
> > +Required properties for g5:
> > +- compatible : Should be any one of the following:
> > +   "aspeed,ast2500-pinctrl"
> > +   "aspeed,g5-pinctrl"
> > +
> > +- aspeed,external-nodes:   A cell of phandles to external controller 
> > nodes:
> > +   0: compatible with "aspeed,ast2500-gfx", 
> > "syscon"
> > +   1: compatible with "aspeed,ast2500-lpchc", 
> > "syscon"
> > 
> >  The pin controller node should be a child of a syscon node with the 
> > required
> >  property:
> > @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU 
> > TIMER4 TIMER5 TIMER6
> >  TIMER7 TIMER8 VGABIOSROM
> > 
> > 
> > -Examples:
> > +g4 Example:
> > 
> >  syscon: scu@1e6e2000 {
> > compatible = "syscon", "simple-mfd";
> > @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
> > };
> >  };
> > 
> > +g5 Example:
> > +
> > +apb {
> > +   gfx: display@1e6e6000 {
> > +   compatible = "aspeed,ast2500-gfx", "syscon";
> > +   reg = <0x1e6e6000 0x1000>;
> > +   };
> > +
> > +   lpchc: lpchc@1e7890a0 {
> > +   compatible = "aspeed,ast2500-lpchc", "syscon";
> > +   reg = <0x1e7890a0 0xc4>;
> > +   };
> > +
> > +   syscon: scu@1e6e2000 {
> > +   compatible = "syscon", "simple-mfd";
> > +   reg = <0x1e6e2000 0x1a8>;
> > +
> > +   pinctrl: pinctrl {
> > +   compatible = "aspeed,g5-pinctrl";
> > +   aspeed,external-nodes = <, >;
> > +
> > +   pinctrl_i2c3_default: i2c3_default {
> > +   function = "I2C3";
> > +   groups = "I2C3";
> > +   };
> > +   };
> > +   };
> > +};
> > +
> >  Please refer to pinctrl-bindings.txt in this directory for details of the
> >  common pinctrl bindings used by client devices.
> > diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
> > 

Re: vmalloced stacks and scatterwalk_map_and_copy()

[Andy Lutomirski]

On Thu, Nov 3, 2016 at 4:10 PM, Eric Biggers  wrote:
> On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote:
>> On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote:
>> >
>> > Also, Herbert, it seems like the considerable majority of the crypto
>> > code is acting on kernel virtual memory addresses and does software
>> > processing.  Would it perhaps make sense to add a kvec-based or
>> > iov_iter-based interface to the crypto code?  I bet it would be quite
>> > a bit faster and it would make crypto on stack buffers work directly.
>>
>> I'd like to hear Herbert's opinion on this too, but as I understand it, if a
>> symmetric cipher API operating on virtual addresses was added, similar to the
>> existing "shash" API it would only allow software processing.  Whereas with 
>> the
>> current API you can request a transform and use it the same way regardless of
>> whether the crypto framework has chosen a software or hardware 
>> implementation,
>> or a combination thereof.  If this wasn't a concern then I expect using 
>> virtual
>> addresses would indeed simplify things a lot, at least for users not already
>> working with physical memory (struct page).
>>
>> Either way, in the near term it looks like 4.9 will be released with the new
>> behavior that encryption/decryption is not supported on stack buffers.
>> Separately from the scatterwalk_map_and_copy() issue, today I've found two
>> places in the filesystem-level encryption code that do encryption on stack
>> buffers and therefore hit the 'BUG_ON(!virt_addr_valid(buf));' in 
>> sg_set_buf().
>> I will be sending patches to fix these, but I suspect there may be more 
>> crypto
>> API users elsewhere that have this same problem.
>>
>> Eric
>
> [Added linux-mm to Cc]
>
> For what it's worth, grsecurity has a special case to allow a scatterlist 
> entry
> to be created from a stack buffer:
>
> static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
>   unsigned int buflen)
> {
> const void *realbuf = buf;
>
> #ifdef CONFIG_GRKERNSEC_KSTACKOVERFLOW
> if (object_starts_on_stack(buf))
> realbuf = buf - current->stack + 
> current->lowmem_stack;
> #endif
>
> #ifdef CONFIG_DEBUG_SG
> BUG_ON(!virt_addr_valid(realbuf));
> #endif
> sg_set_page(sg, virt_to_page(realbuf), buflen, 
> offset_in_page(realbuf));
> }

Yes, that's how grsecurity works.  The upstream version is going to do
it right instead of hacking around it.

> I don't know about all the relative merits of the two approaches.  But one of
> the things that will need to be done with the currently upstream approach is
> that all callers of sg_set_buf() will need to be checked to make sure they
> aren't using stack addresses, and any that are will need to be updated to do
> otherwise, e.g. by using heap-allocated memory.

I tried to do this, but I may have missed a couple example.

>  I suppose this is already
> happening, but in the case of the crypto API it will probably take a while for
> all the users to be identified and updated.  (And it's not always clear from 
> the
> local context whether something can be stack memory or not, e.g. the memory 
> for
> crypto request objects may be either.)

The crypto request objects can live on the stack just fine.  It's the
request buffers that need to live elsewhere (or the alternative
interfaces can be used, or the crypto core code can start using
something other than scatterlists).

--Andy

Re: vmalloced stacks and scatterwalk_map_and_copy()

[Andy Lutomirski]

On Thu, Nov 3, 2016 at 4:10 PM, Eric Biggers  wrote:
> On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote:
>> On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote:
>> >
>> > Also, Herbert, it seems like the considerable majority of the crypto
>> > code is acting on kernel virtual memory addresses and does software
>> > processing.  Would it perhaps make sense to add a kvec-based or
>> > iov_iter-based interface to the crypto code?  I bet it would be quite
>> > a bit faster and it would make crypto on stack buffers work directly.
>>
>> I'd like to hear Herbert's opinion on this too, but as I understand it, if a
>> symmetric cipher API operating on virtual addresses was added, similar to the
>> existing "shash" API it would only allow software processing.  Whereas with 
>> the
>> current API you can request a transform and use it the same way regardless of
>> whether the crypto framework has chosen a software or hardware 
>> implementation,
>> or a combination thereof.  If this wasn't a concern then I expect using 
>> virtual
>> addresses would indeed simplify things a lot, at least for users not already
>> working with physical memory (struct page).
>>
>> Either way, in the near term it looks like 4.9 will be released with the new
>> behavior that encryption/decryption is not supported on stack buffers.
>> Separately from the scatterwalk_map_and_copy() issue, today I've found two
>> places in the filesystem-level encryption code that do encryption on stack
>> buffers and therefore hit the 'BUG_ON(!virt_addr_valid(buf));' in 
>> sg_set_buf().
>> I will be sending patches to fix these, but I suspect there may be more 
>> crypto
>> API users elsewhere that have this same problem.
>>
>> Eric
>
> [Added linux-mm to Cc]
>
> For what it's worth, grsecurity has a special case to allow a scatterlist 
> entry
> to be created from a stack buffer:
>
> static inline void sg_set_buf(struct scatterlist *sg, const void *buf,
>   unsigned int buflen)
> {
> const void *realbuf = buf;
>
> #ifdef CONFIG_GRKERNSEC_KSTACKOVERFLOW
> if (object_starts_on_stack(buf))
> realbuf = buf - current->stack + 
> current->lowmem_stack;
> #endif
>
> #ifdef CONFIG_DEBUG_SG
> BUG_ON(!virt_addr_valid(realbuf));
> #endif
> sg_set_page(sg, virt_to_page(realbuf), buflen, 
> offset_in_page(realbuf));
> }

Yes, that's how grsecurity works.  The upstream version is going to do
it right instead of hacking around it.

> I don't know about all the relative merits of the two approaches.  But one of
> the things that will need to be done with the currently upstream approach is
> that all callers of sg_set_buf() will need to be checked to make sure they
> aren't using stack addresses, and any that are will need to be updated to do
> otherwise, e.g. by using heap-allocated memory.

I tried to do this, but I may have missed a couple example.

>  I suppose this is already
> happening, but in the case of the crypto API it will probably take a while for
> all the users to be identified and updated.  (And it's not always clear from 
> the
> local context whether something can be stack memory or not, e.g. the memory 
> for
> crypto request objects may be either.)

The crypto request objects can live on the stack just fine.  It's the
request buffers that need to live elsewhere (or the alternative
interfaces can be used, or the crypto core code can start using
something other than scatterlists).

--Andy

Re: [PATCH v2 3/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LPCHC)

[Andrew Jeffery]

On Fri, 2016-11-04 at 09:36 +1030, Joel Stanley wrote:
> On Thu, Nov 3, 2016 at 1:07 AM, Andrew Jeffery  wrote:
> > 
> > The Aspeed LPC Host Controller is presented as a syscon device to
> > arbitrate access by LPC and pinmux drivers. LPC pinmux configuration on
> > fifth generation SoCs depends on bits in both the System Control Unit
> > and the LPC Host Controller.
> > 
> > Signed-off-by: Andrew Jeffery 
> > ---
> >  Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt | 17 
> > +
> >  1 file changed, 17 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt 
> > b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> > new file mode 100644
> > index ..792651488c3d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> > @@ -0,0 +1,17 @@
> > +* Device tree bindings for the Aspeed LPC Host Controller (LPCHC)
> I had to check the data sheet for that acronym. They call the
> registers LHC. I somewhat prefer that name, but if you're happy with
> it as-is then that's fine.

I had an internal debate about this. I figured LPCHC might give a bit
more context to the acronym. I'm not unhappy with it but I wouldn't
claim I'm happy either. I will change it to LHC since you somewhat
prefer it, and it better aligns with the datasheet.

> 
> I assume this is not an issue on the g4/ast2400?

Correct, we don't have the issue of pinmux needing to reach into the
LPC IO space on the AST2400. I don't think we've had anything else to
drive us to looking at the host controller space there, so I wasn't
going to add it to the bindings yet.

> 
> > 
> > +
> > +The LPCHC registers configure LPC behaviour between the BMC and the host
> > +system. The LPCHC also participates in pinmux requests on g5 SoCs and is
> > +therefore considered a syscon device.
> > +
> > +Required properties:
> > +- compatible:  "aspeed,ast2500-lpchc", "syscon"
> > +- reg: contains offset/length value of the LPCHC memory
> > +   region.
> > +
> > +Example:
> > +
> > +lpchc: lpchc@1e7890a0 {
> > +   compatible = "aspeed,ast2500-lpchc", "syscon";
> > +   reg = <0x1e7890a0 0xc4>;
> Where's the 0xc4 come from? I can see 9 registers, which would mean
> the length should be 0x24?

Yes, it should be 0x24. I can't even claim that 'c' is near '2'. Thanks
for catching that.

Andrew

> 
> Cheers,
> 
> Joel

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

Re: [PATCH v2 3/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LPCHC)

[Andrew Jeffery]

On Fri, 2016-11-04 at 09:36 +1030, Joel Stanley wrote:
> On Thu, Nov 3, 2016 at 1:07 AM, Andrew Jeffery  wrote:
> > 
> > The Aspeed LPC Host Controller is presented as a syscon device to
> > arbitrate access by LPC and pinmux drivers. LPC pinmux configuration on
> > fifth generation SoCs depends on bits in both the System Control Unit
> > and the LPC Host Controller.
> > 
> > Signed-off-by: Andrew Jeffery 
> > ---
> >  Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt | 17 
> > +
> >  1 file changed, 17 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt 
> > b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> > new file mode 100644
> > index ..792651488c3d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> > @@ -0,0 +1,17 @@
> > +* Device tree bindings for the Aspeed LPC Host Controller (LPCHC)
> I had to check the data sheet for that acronym. They call the
> registers LHC. I somewhat prefer that name, but if you're happy with
> it as-is then that's fine.

I had an internal debate about this. I figured LPCHC might give a bit
more context to the acronym. I'm not unhappy with it but I wouldn't
claim I'm happy either. I will change it to LHC since you somewhat
prefer it, and it better aligns with the datasheet.

> 
> I assume this is not an issue on the g4/ast2400?

Correct, we don't have the issue of pinmux needing to reach into the
LPC IO space on the AST2400. I don't think we've had anything else to
drive us to looking at the host controller space there, so I wasn't
going to add it to the bindings yet.

> 
> > 
> > +
> > +The LPCHC registers configure LPC behaviour between the BMC and the host
> > +system. The LPCHC also participates in pinmux requests on g5 SoCs and is
> > +therefore considered a syscon device.
> > +
> > +Required properties:
> > +- compatible:  "aspeed,ast2500-lpchc", "syscon"
> > +- reg: contains offset/length value of the LPCHC memory
> > +   region.
> > +
> > +Example:
> > +
> > +lpchc: lpchc@1e7890a0 {
> > +   compatible = "aspeed,ast2500-lpchc", "syscon";
> > +   reg = <0x1e7890a0 0xc4>;
> Where's the 0xc4 come from? I can see 9 registers, which would mean
> the length should be 0x24?

Yes, it should be 0x24. I can't even claim that 'c' is near '2'. Thanks
for catching that.

Andrew

> 
> Cheers,
> 
> Joel

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

Re: [PATCH 1/2] arm64: hugetlb: remove the wrong pmd check in find_num_contig()

[Huang Shijie]

On Thu, Nov 03, 2016 at 06:16:16PM -0600, Catalin Marinas wrote:
> On Thu, Nov 03, 2016 at 10:27:38AM +0800, Huang Shijie wrote:
> > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > index 2e49bd2..4811ef1 100644
> > --- a/arch/arm64/mm/hugetlbpage.c
> > +++ b/arch/arm64/mm/hugetlbpage.c
> > @@ -61,10 +61,6 @@ static int find_num_contig(struct mm_struct *mm, 
> > unsigned long addr,
> > return 1;
> > }
> > pmd = pmd_offset(pud, addr);
> > -   if (!pmd_present(*pmd)) {
> > -   VM_BUG_ON(!pmd_present(*pmd));
> > -   return 1;
> > -   }
> > if ((pte_t *)pmd == ptep) {
> > *pgsize = PMD_SIZE;
> > return CONT_PMDS;
> 
> BTW, for the !pud_present() and !pgd_present() cases, shouldn't
The kernel will not call the find_num_contig() if the PGD/PUD are empty.
Please see the code in the hugetlb_fault().

   --
ptep = huge_pte_offset(mm, address);
if (ptep) {
...
} else {
ptep = huge_pte_alloc(mm, address, huge_page_size(h));
if (!ptep)
return VM_FAULT_OOM;
}
   --


Thanks
Huang Shijie
> find_num_contig() actually return 0? These are more likely real bugs, so
> no point in setting the huge pte.

Re: [PATCH 1/2] arm64: hugetlb: remove the wrong pmd check in find_num_contig()

[Huang Shijie]

On Thu, Nov 03, 2016 at 06:16:16PM -0600, Catalin Marinas wrote:
> On Thu, Nov 03, 2016 at 10:27:38AM +0800, Huang Shijie wrote:
> > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> > index 2e49bd2..4811ef1 100644
> > --- a/arch/arm64/mm/hugetlbpage.c
> > +++ b/arch/arm64/mm/hugetlbpage.c
> > @@ -61,10 +61,6 @@ static int find_num_contig(struct mm_struct *mm, 
> > unsigned long addr,
> > return 1;
> > }
> > pmd = pmd_offset(pud, addr);
> > -   if (!pmd_present(*pmd)) {
> > -   VM_BUG_ON(!pmd_present(*pmd));
> > -   return 1;
> > -   }
> > if ((pte_t *)pmd == ptep) {
> > *pgsize = PMD_SIZE;
> > return CONT_PMDS;
> 
> BTW, for the !pud_present() and !pgd_present() cases, shouldn't
The kernel will not call the find_num_contig() if the PGD/PUD are empty.
Please see the code in the hugetlb_fault().

   --
ptep = huge_pte_offset(mm, address);
if (ptep) {
...
} else {
ptep = huge_pte_alloc(mm, address, huge_page_size(h));
if (!ptep)
return VM_FAULT_OOM;
}
   --


Thanks
Huang Shijie
> find_num_contig() actually return 0? These are more likely real bugs, so
> no point in setting the huge pte.

Re: [mm PATCH v2 18/26] arch/powerpc: Add option to skip DMA sync as a part of mapping

[Michael Ellerman]

Alexander Duyck  writes:

> This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
> avoid invoking cache line invalidation if the driver will just handle it
> via a sync_for_cpu or sync_for_device call.
>
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Alexander Duyck 
> ---
>  arch/powerpc/kernel/dma.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

LGTM.

Acked-by: Michael Ellerman  (powerpc)

cheers

Re: [mm PATCH v2 18/26] arch/powerpc: Add option to skip DMA sync as a part of mapping

[Michael Ellerman]

Alexander Duyck  writes:

> This change allows us to pass DMA_ATTR_SKIP_CPU_SYNC which allows us to
> avoid invoking cache line invalidation if the driver will just handle it
> via a sync_for_cpu or sync_for_device call.
>
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Alexander Duyck 
> ---
>  arch/powerpc/kernel/dma.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

LGTM.

Acked-by: Michael Ellerman  (powerpc)

cheers

Re: [PATCH 4/6] g_NCR5380: Add IRQ auto-configuration for HP C2502

[Finn Thain]

On Thu, 3 Nov 2016, Ondrej Zary wrote:

> On Thursday 03 November 2016, Finn Thain wrote:
> > On Wed, 2 Nov 2016, Ondrej Zary wrote:
> > > 
> > > The card is almost Plug The base address is already configured 
> > > automatically by the driver so doing the same for IRQ makes sense.
> >
> > Why don't we see any other drivers doing this?
> 
> Many ISA sound card drivers do this - there's even a function for this: 
> static int snd_legacy_find_free_irq(int *irq_table)

Well, if snd_legacy_find_free_irq() is good enough for the ALSA 
maintainers, it is good enough for me.

But I still don't like this patch. I would prefer to cut-and-paste 
snd_legacy_find_free_irq() as g_NCR5380_find_free_irq(), and 
snd_legacy_empty_irq_handler() as g_NCR5380_empty_irq_handler(), to allow 
for refactoring all that into a common header file later on.

When the user asks for board == BOARD_HP_C2502 and irq == IRQ_AUTO, just 
use the first result from g_NCR5380_find_free_irq() to program the card. 
If no irq is free, program the card for irq 0.

Then just proceed with the usual IRQ_AUTO probing, like you would for any 
other board. That way, there is no need for NCR5380_test_irq() at all, and 
you can drop patch 2/5 (at least until we figure out why a command timeout 
during modprobe hangs your system).

-- 

Re: [PATCH 4/6] g_NCR5380: Add IRQ auto-configuration for HP C2502

[Finn Thain]

On Thu, 3 Nov 2016, Ondrej Zary wrote:

> On Thursday 03 November 2016, Finn Thain wrote:
> > On Wed, 2 Nov 2016, Ondrej Zary wrote:
> > > 
> > > The card is almost Plug The base address is already configured 
> > > automatically by the driver so doing the same for IRQ makes sense.
> >
> > Why don't we see any other drivers doing this?
> 
> Many ISA sound card drivers do this - there's even a function for this: 
> static int snd_legacy_find_free_irq(int *irq_table)

Well, if snd_legacy_find_free_irq() is good enough for the ALSA 
maintainers, it is good enough for me.

But I still don't like this patch. I would prefer to cut-and-paste 
snd_legacy_find_free_irq() as g_NCR5380_find_free_irq(), and 
snd_legacy_empty_irq_handler() as g_NCR5380_empty_irq_handler(), to allow 
for refactoring all that into a common header file later on.

When the user asks for board == BOARD_HP_C2502 and irq == IRQ_AUTO, just 
use the first result from g_NCR5380_find_free_irq() to program the card. 
If no irq is free, program the card for irq 0.

Then just proceed with the usual IRQ_AUTO probing, like you would for any 
other board. That way, there is no need for NCR5380_test_irq() at all, and 
you can drop patch 2/5 (at least until we figure out why a command timeout 
during modprobe hangs your system).

-- 

[PATCH] remoteproc: qcom_wcnss: Fix circular module dependency

[Bjorn Andersson]

The tie between the main WCNSS driver and the IRIS driver causes a
circular dependency between the two modules. Neither part makes sense to
have on their own so lets merge them into one module.

For the sake of picking up the clock and regulator resources described
in the iris of_node we need an associated struct device. But, to keep
the size of the patch down we continue to represent the IRIS part as its
own platform_driver, within the same module, rather than setting up a
dummy device.

Reported-by: Andreas Färber 
Signed-off-by: Bjorn Andersson 
---
 drivers/remoteproc/Kconfig   |  5 -
 drivers/remoteproc/Makefile  |  5 +++--
 drivers/remoteproc/qcom_wcnss.c  | 25 +++--
 drivers/remoteproc/qcom_wcnss.h  |  2 ++
 drivers/remoteproc/qcom_wcnss_iris.c |  8 +---
 5 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f396bfef5d42..5fcbefcb8636 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -91,17 +91,12 @@ config QCOM_Q6V5_PIL
  Say y here to support the Qualcomm Peripherial Image Loader for the
  Hexagon V5 based remote processors.
 
-config QCOM_WCNSS_IRIS
-   tristate
-   depends on OF && ARCH_QCOM
-
 config QCOM_WCNSS_PIL
tristate "Qualcomm WCNSS Peripheral Image Loader"
depends on OF && ARCH_QCOM
depends on QCOM_SMEM
select QCOM_MDT_LOADER
select QCOM_SCM
-   select QCOM_WCNSS_IRIS
select REMOTEPROC
help
  Say y here to support the Peripheral Image Loader for the Qualcomm
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 6dfb62ed643f..034b6f3563a7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_WKUP_M3_RPROC)   += wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
-obj-$(CONFIG_QCOM_WCNSS_IRIS)  += qcom_wcnss_iris.o
-obj-$(CONFIG_QCOM_WCNSS_PIL)   += qcom_wcnss.o
+obj-$(CONFIG_QCOM_WCNSS_PIL)   += qcom_wcnss_pil.o
+qcom_wcnss_pil-y   += qcom_wcnss.o
+qcom_wcnss_pil-y   += qcom_wcnss_iris.o
 obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index f5cedeaafba1..323b629474a6 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -143,7 +143,6 @@ void qcom_wcnss_assign_iris(struct qcom_wcnss *wcnss,
 
mutex_unlock(>iris_lock);
 }
-EXPORT_SYMBOL_GPL(qcom_wcnss_assign_iris);
 
 static int wcnss_load(struct rproc *rproc, const struct firmware *fw)
 {
@@ -619,6 +618,28 @@ static struct platform_driver wcnss_driver = {
},
 };
 
-module_platform_driver(wcnss_driver);
+static int __init wcnss_init(void)
+{
+   int ret;
+
+   ret = platform_driver_register(_driver);
+   if (ret)
+   return ret;
+
+   ret = platform_driver_register(_iris_driver);
+   if (ret)
+   platform_driver_unregister(_driver);
+
+   return ret;
+}
+module_init(wcnss_init);
+
+static void __exit wcnss_exit(void)
+{
+   platform_driver_unregister(_iris_driver);
+   platform_driver_unregister(_driver);
+}
+module_exit(wcnss_exit);
+
 MODULE_DESCRIPTION("Qualcomm Peripherial Image Loader for Wireless Subsystem");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/remoteproc/qcom_wcnss.h b/drivers/remoteproc/qcom_wcnss.h
index 9dc4a9fe41e1..25fb7f62a457 100644
--- a/drivers/remoteproc/qcom_wcnss.h
+++ b/drivers/remoteproc/qcom_wcnss.h
@@ -4,6 +4,8 @@
 struct qcom_iris;
 struct qcom_wcnss;
 
+extern struct platform_driver qcom_iris_driver;
+
 struct wcnss_vreg_info {
const char * const name;
int min_voltage;
diff --git a/drivers/remoteproc/qcom_wcnss_iris.c 
b/drivers/remoteproc/qcom_wcnss_iris.c
index f0ca24a8dd0b..05d6e175411a 100644
--- a/drivers/remoteproc/qcom_wcnss_iris.c
+++ b/drivers/remoteproc/qcom_wcnss_iris.c
@@ -94,14 +94,12 @@ int qcom_iris_enable(struct qcom_iris *iris)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(qcom_iris_enable);
 
 void qcom_iris_disable(struct qcom_iris *iris)
 {
clk_disable_unprepare(iris->xo_clk);
regulator_bulk_disable(iris->num_vregs, iris->vregs);
 }
-EXPORT_SYMBOL_GPL(qcom_iris_disable);
 
 static int qcom_iris_probe(struct platform_device *pdev)
 {
@@ -174,7 +172,7 @@ static const struct of_device_id iris_of_match[] = {
{}
 };
 
-static struct platform_driver wcnss_driver = {
+struct platform_driver qcom_iris_driver = {
.probe = qcom_iris_probe,
.remove = qcom_iris_remove,
.driver = {
@@ -182,7 +180,3 @@ static struct platform_driver wcnss_driver = {

[PATCH] remoteproc: qcom_wcnss: Fix circular module dependency

[Bjorn Andersson]

The tie between the main WCNSS driver and the IRIS driver causes a
circular dependency between the two modules. Neither part makes sense to
have on their own so lets merge them into one module.

For the sake of picking up the clock and regulator resources described
in the iris of_node we need an associated struct device. But, to keep
the size of the patch down we continue to represent the IRIS part as its
own platform_driver, within the same module, rather than setting up a
dummy device.

Reported-by: Andreas Färber 
Signed-off-by: Bjorn Andersson 
---
 drivers/remoteproc/Kconfig   |  5 -
 drivers/remoteproc/Makefile  |  5 +++--
 drivers/remoteproc/qcom_wcnss.c  | 25 +++--
 drivers/remoteproc/qcom_wcnss.h  |  2 ++
 drivers/remoteproc/qcom_wcnss_iris.c |  8 +---
 5 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f396bfef5d42..5fcbefcb8636 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -91,17 +91,12 @@ config QCOM_Q6V5_PIL
  Say y here to support the Qualcomm Peripherial Image Loader for the
  Hexagon V5 based remote processors.
 
-config QCOM_WCNSS_IRIS
-   tristate
-   depends on OF && ARCH_QCOM
-
 config QCOM_WCNSS_PIL
tristate "Qualcomm WCNSS Peripheral Image Loader"
depends on OF && ARCH_QCOM
depends on QCOM_SMEM
select QCOM_MDT_LOADER
select QCOM_SCM
-   select QCOM_WCNSS_IRIS
select REMOTEPROC
help
  Say y here to support the Peripheral Image Loader for the Qualcomm
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 6dfb62ed643f..034b6f3563a7 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_WKUP_M3_RPROC)   += wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
 obj-$(CONFIG_QCOM_Q6V5_PIL)+= qcom_q6v5_pil.o
-obj-$(CONFIG_QCOM_WCNSS_IRIS)  += qcom_wcnss_iris.o
-obj-$(CONFIG_QCOM_WCNSS_PIL)   += qcom_wcnss.o
+obj-$(CONFIG_QCOM_WCNSS_PIL)   += qcom_wcnss_pil.o
+qcom_wcnss_pil-y   += qcom_wcnss.o
+qcom_wcnss_pil-y   += qcom_wcnss_iris.o
 obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index f5cedeaafba1..323b629474a6 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -143,7 +143,6 @@ void qcom_wcnss_assign_iris(struct qcom_wcnss *wcnss,
 
mutex_unlock(>iris_lock);
 }
-EXPORT_SYMBOL_GPL(qcom_wcnss_assign_iris);
 
 static int wcnss_load(struct rproc *rproc, const struct firmware *fw)
 {
@@ -619,6 +618,28 @@ static struct platform_driver wcnss_driver = {
},
 };
 
-module_platform_driver(wcnss_driver);
+static int __init wcnss_init(void)
+{
+   int ret;
+
+   ret = platform_driver_register(_driver);
+   if (ret)
+   return ret;
+
+   ret = platform_driver_register(_iris_driver);
+   if (ret)
+   platform_driver_unregister(_driver);
+
+   return ret;
+}
+module_init(wcnss_init);
+
+static void __exit wcnss_exit(void)
+{
+   platform_driver_unregister(_iris_driver);
+   platform_driver_unregister(_driver);
+}
+module_exit(wcnss_exit);
+
 MODULE_DESCRIPTION("Qualcomm Peripherial Image Loader for Wireless Subsystem");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/remoteproc/qcom_wcnss.h b/drivers/remoteproc/qcom_wcnss.h
index 9dc4a9fe41e1..25fb7f62a457 100644
--- a/drivers/remoteproc/qcom_wcnss.h
+++ b/drivers/remoteproc/qcom_wcnss.h
@@ -4,6 +4,8 @@
 struct qcom_iris;
 struct qcom_wcnss;
 
+extern struct platform_driver qcom_iris_driver;
+
 struct wcnss_vreg_info {
const char * const name;
int min_voltage;
diff --git a/drivers/remoteproc/qcom_wcnss_iris.c 
b/drivers/remoteproc/qcom_wcnss_iris.c
index f0ca24a8dd0b..05d6e175411a 100644
--- a/drivers/remoteproc/qcom_wcnss_iris.c
+++ b/drivers/remoteproc/qcom_wcnss_iris.c
@@ -94,14 +94,12 @@ int qcom_iris_enable(struct qcom_iris *iris)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(qcom_iris_enable);
 
 void qcom_iris_disable(struct qcom_iris *iris)
 {
clk_disable_unprepare(iris->xo_clk);
regulator_bulk_disable(iris->num_vregs, iris->vregs);
 }
-EXPORT_SYMBOL_GPL(qcom_iris_disable);
 
 static int qcom_iris_probe(struct platform_device *pdev)
 {
@@ -174,7 +172,7 @@ static const struct of_device_id iris_of_match[] = {
{}
 };
 
-static struct platform_driver wcnss_driver = {
+struct platform_driver qcom_iris_driver = {
.probe = qcom_iris_probe,
.remove = qcom_iris_remove,
.driver = {
@@ -182,7 +180,3 @@ static struct platform_driver wcnss_driver = {
.of_match_table = iris_of_match,
},
 };
-

[PATCH net-next v2 07/11] net: dsa: mv88e6xxx: add port link setter

[Vivien Didelot]

Most of the chips will have a port register control bits to force the
port's link up, down, or let normal link detection occurs.

Implement such operation to use it later when setting duplex, etc.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  | 17 +++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 10 +
 drivers/net/dsa/mv88e6xxx/port.c  | 41 +++
 drivers/net/dsa/mv88e6xxx/port.h  |  2 ++
 4 files changed, 70 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 181d3b9..cc43e6f 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3160,42 +3160,49 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6095_ops = {
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6123_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6131_ops = {
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6161_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6165_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6171_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6172_ops = {
@@ -3204,12 +3211,14 @@ static const struct mv88e6xxx_ops mv88e6172_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6175_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6176_ops = {
@@ -3218,12 +3227,14 @@ static const struct mv88e6xxx_ops mv88e6176_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6185_ops = {
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6240_ops = {
@@ -3232,6 +3243,7 @@ static const struct mv88e6xxx_ops mv88e6240_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6320_ops = {
@@ -3240,6 +3252,7 @@ static const struct mv88e6xxx_ops mv88e6320_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6321_ops = {
@@ -3248,18 +3261,21 @@ static const struct mv88e6xxx_ops mv88e6321_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6350_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6351_ops = {
 

[PATCH net-next v2 00/11] net: dsa: mv88e6xxx: refine port operations

[Vivien Didelot]

The Marvell chips have one internal SMI device per port, containing a
set of registers used to configure a port's link, STP state, default
VLAN or addresses database, etc.

This patchset creates port files to implement the port operations as
described in datasheets, and extend the chip ops structure with them.

Patches 1 to 6 implement accessors for port's STP state, port based VLAN
map, default FID, default VID, and 802.1Q mode.

Patches 7 to 11 implement the port's MAC setup of link state, duplex
mode, RGMII delay and speed, all accessed through port's register 0x01.

The new port's MAC setup code is used to re-implement the adjust_link
code and correctly force the link down before changing any of the MAC
settings, as requested by the datasheets.

The port's MAC accessors use values compatible with struct phy_device
(e.g. DUPLEX_FULL) and extend them when needed (e.g. SPEED_MAX).

Changes in v2:

  - Strictly use new _UNFORCED values instead of re-using _UNKNOWN ones.

Vivien Didelot (11):
  net: dsa: mv88e6xxx: add port files
  net: dsa: mv88e6xxx: add port state setter
  net: dsa: mv88e6xxx: add port vlan map setter
  net: dsa: mv88e6xxx: add port FID accessors
  net: dsa: mv88e6xxx: add port PVID accessors
  net: dsa: mv88e6xxx: add port 802.1Q mode setter
  net: dsa: mv88e6xxx: add port link setter
  net: dsa: mv88e6xxx: add port duplex setter
  net: dsa: mv88e6xxx: add port's RGMII delay setter
  net: dsa: mv88e6xxx: add port's MAC speed setter
  net: dsa: mv88e6xxx: setup port's MAC

 drivers/net/dsa/mv88e6xxx/Makefile|   1 +
 drivers/net/dsa/mv88e6xxx/chip.c  | 436 +
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  49 +++-
 drivers/net/dsa/mv88e6xxx/port.c  | 497 ++
 drivers/net/dsa/mv88e6xxx/port.h  |  52 
 5 files changed, 727 insertions(+), 308 deletions(-)
 create mode 100644 drivers/net/dsa/mv88e6xxx/port.c
 create mode 100644 drivers/net/dsa/mv88e6xxx/port.h

-- 
2.10.2

[PATCH net-next v2 03/11] net: dsa: mv88e6xxx: add port vlan map setter

[Vivien Didelot]

Add a port function to access the Port Based VLAN Map register.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 14 ++
 drivers/net/dsa/mv88e6xxx/port.c | 25 +
 drivers/net/dsa/mv88e6xxx/port.h |  2 ++
 3 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 12c1175..087 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1218,16 +1218,13 @@ static int _mv88e6xxx_atu_remove(struct mv88e6xxx_chip 
*chip, u16 fid,
 static int _mv88e6xxx_port_based_vlan_map(struct mv88e6xxx_chip *chip, int 
port)
 {
struct net_device *bridge = chip->ports[port].bridge_dev;
-   const u16 mask = (1 << mv88e6xxx_num_ports(chip)) - 1;
struct dsa_switch *ds = chip->ds;
u16 output_ports = 0;
-   u16 reg;
-   int err;
int i;
 
/* allow CPU port or DSA link(s) to send frames to every port */
if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port)) {
-   output_ports = mask;
+   output_ports = ~0;
} else {
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i) {
/* allow sending frames to every group member */
@@ -1243,14 +1240,7 @@ static int _mv88e6xxx_port_based_vlan_map(struct 
mv88e6xxx_chip *chip, int port)
/* prevent frames from going back out of the port they came in on */
output_ports &= ~BIT(port);
 
-   err = mv88e6xxx_port_read(chip, port, PORT_BASE_VLAN, );
-   if (err)
-   return err;
-
-   reg &= ~mask;
-   reg |= output_ports & mask;
-
-   return mv88e6xxx_port_write(chip, port, PORT_BASE_VLAN, reg);
+   return mv88e6xxx_port_set_vlan_map(chip, port, output_ports);
 }
 
 static void mv88e6xxx_port_stp_state_set(struct dsa_switch *ds, int port,
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 8d59fe7..c6a22ae 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -60,3 +60,28 @@ int mv88e6xxx_port_set_state(struct mv88e6xxx_chip *chip, 
int port, u8 state)
 
return 0;
 }
+
+/* Offset 0x06: Port Based VLAN Map */
+
+int mv88e6xxx_port_set_vlan_map(struct mv88e6xxx_chip *chip, int port, u16 map)
+{
+   const u16 mask = GENMASK(mv88e6xxx_num_ports(chip) - 1, 0);
+   u16 reg;
+   int err;
+
+   err = mv88e6xxx_port_read(chip, port, PORT_BASE_VLAN, );
+   if (err)
+   return err;
+
+   reg &= ~mask;
+   reg |= map & mask;
+
+   err = mv88e6xxx_port_write(chip, port, PORT_BASE_VLAN, reg);
+   if (err)
+   return err;
+
+   netdev_dbg(chip->ds->ports[port].netdev, "VLANTable set to %.3x\n",
+  map);
+
+   return 0;
+}
diff --git a/drivers/net/dsa/mv88e6xxx/port.h b/drivers/net/dsa/mv88e6xxx/port.h
index ac13988..037d638 100644
--- a/drivers/net/dsa/mv88e6xxx/port.h
+++ b/drivers/net/dsa/mv88e6xxx/port.h
@@ -23,4 +23,6 @@ int mv88e6xxx_port_write(struct mv88e6xxx_chip *chip, int 
port, int reg,
 
 int mv88e6xxx_port_set_state(struct mv88e6xxx_chip *chip, int port, u8 state);
 
+int mv88e6xxx_port_set_vlan_map(struct mv88e6xxx_chip *chip, int port, u16 
map);
+
 #endif /* _MV88E6XXX_PORT_H */
-- 
2.10.2

[PATCH net-next v2 08/11] net: dsa: mv88e6xxx: add port duplex setter

[Vivien Didelot]

Similarly to port's link, add setter to force port's half duplex, full
duplex or let normal duplex detection occurs.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  | 17 +
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  9 +
 drivers/net/dsa/mv88e6xxx/port.c  | 36 +++
 drivers/net/dsa/mv88e6xxx/port.h  |  2 ++
 4 files changed, 64 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index cc43e6f..49a6935 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3161,6 +3161,7 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6095_ops = {
@@ -3168,6 +3169,7 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6123_ops = {
@@ -3175,6 +3177,7 @@ static const struct mv88e6xxx_ops mv88e6123_ops = {
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6131_ops = {
@@ -3182,6 +3185,7 @@ static const struct mv88e6xxx_ops mv88e6131_ops = {
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6161_ops = {
@@ -3189,6 +3193,7 @@ static const struct mv88e6xxx_ops mv88e6161_ops = {
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6165_ops = {
@@ -3196,6 +3201,7 @@ static const struct mv88e6xxx_ops mv88e6165_ops = {
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6171_ops = {
@@ -3203,6 +3209,7 @@ static const struct mv88e6xxx_ops mv88e6171_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6172_ops = {
@@ -3212,6 +3219,7 @@ static const struct mv88e6xxx_ops mv88e6172_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6175_ops = {
@@ -3219,6 +3227,7 @@ static const struct mv88e6xxx_ops mv88e6175_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6176_ops = {
@@ -3228,6 +3237,7 @@ static const struct mv88e6xxx_ops mv88e6176_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6185_ops = {
@@ -3235,6 +3245,7 @@ static const struct mv88e6xxx_ops mv88e6185_ops = {
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6240_ops = {
@@ -3244,6 +3255,7 @@ static const struct mv88e6xxx_ops mv88e6240_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6320_ops = {
@@ -3253,6 +3265,7 @@ static const struct mv88e6xxx_ops mv88e6320_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6321_ops = {
@@ -3262,6 +3275,7 @@ static const struct mv88e6xxx_ops mv88e6321_ops = {
.phy_read = 

[PATCH net-next v2 06/11] net: dsa: mv88e6xxx: add port 802.1Q mode setter

[Vivien Didelot]

Add port functions to set the port 802.1Q mode.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 33 ++---
 drivers/net/dsa/mv88e6xxx/port.c | 32 
 drivers/net/dsa/mv88e6xxx/port.h |  3 +++
 3 files changed, 37 insertions(+), 31 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 9c0a028..181d3b9 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1806,48 +1806,19 @@ static int mv88e6xxx_port_check_hw_vlan(struct 
dsa_switch *ds, int port,
return err;
 }
 
-static const char * const mv88e6xxx_port_8021q_mode_names[] = {
-   [PORT_CONTROL_2_8021Q_DISABLED] = "Disabled",
-   [PORT_CONTROL_2_8021Q_FALLBACK] = "Fallback",
-   [PORT_CONTROL_2_8021Q_CHECK] = "Check",
-   [PORT_CONTROL_2_8021Q_SECURE] = "Secure",
-};
-
 static int mv88e6xxx_port_vlan_filtering(struct dsa_switch *ds, int port,
 bool vlan_filtering)
 {
struct mv88e6xxx_chip *chip = ds->priv;
-   u16 old, new = vlan_filtering ? PORT_CONTROL_2_8021Q_SECURE :
+   u16 mode = vlan_filtering ? PORT_CONTROL_2_8021Q_SECURE :
PORT_CONTROL_2_8021Q_DISABLED;
-   u16 reg;
int err;
 
if (!mv88e6xxx_has(chip, MV88E6XXX_FLAG_VTU))
return -EOPNOTSUPP;
 
mutex_lock(>reg_lock);
-
-   err = mv88e6xxx_port_read(chip, port, PORT_CONTROL_2, );
-   if (err)
-   goto unlock;
-
-   old = reg & PORT_CONTROL_2_8021Q_MASK;
-
-   if (new != old) {
-   reg &= ~PORT_CONTROL_2_8021Q_MASK;
-   reg |= new & PORT_CONTROL_2_8021Q_MASK;
-
-   err = mv88e6xxx_port_write(chip, port, PORT_CONTROL_2, reg);
-   if (err)
-   goto unlock;
-
-   netdev_dbg(ds->ports[port].netdev, "802.1Q Mode %s (was %s)\n",
-  mv88e6xxx_port_8021q_mode_names[new],
-  mv88e6xxx_port_8021q_mode_names[old]);
-   }
-
-   err = 0;
-unlock:
+   err = mv88e6xxx_port_set_8021q_mode(chip, port, mode);
mutex_unlock(>reg_lock);
 
return err;
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 104fe2d..53d17e6 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -190,3 +190,35 @@ int mv88e6xxx_port_set_pvid(struct mv88e6xxx_chip *chip, 
int port, u16 pvid)
 
return 0;
 }
+
+/* Offset 0x08: Port Control 2 Register */
+
+static const char * const mv88e6xxx_port_8021q_mode_names[] = {
+   [PORT_CONTROL_2_8021Q_DISABLED] = "Disabled",
+   [PORT_CONTROL_2_8021Q_FALLBACK] = "Fallback",
+   [PORT_CONTROL_2_8021Q_CHECK] = "Check",
+   [PORT_CONTROL_2_8021Q_SECURE] = "Secure",
+};
+
+int mv88e6xxx_port_set_8021q_mode(struct mv88e6xxx_chip *chip, int port,
+ u16 mode)
+{
+   u16 reg;
+   int err;
+
+   err = mv88e6xxx_port_read(chip, port, PORT_CONTROL_2, );
+   if (err)
+   return err;
+
+   reg &= ~PORT_CONTROL_2_8021Q_MASK;
+   reg |= mode & PORT_CONTROL_2_8021Q_MASK;
+
+   err = mv88e6xxx_port_write(chip, port, PORT_CONTROL_2, reg);
+   if (err)
+   return err;
+
+   netdev_dbg(chip->ds->ports[port].netdev, "802.1QMode set to %s\n",
+  mv88e6xxx_port_8021q_mode_names[mode]);
+
+   return 0;
+}
diff --git a/drivers/net/dsa/mv88e6xxx/port.h b/drivers/net/dsa/mv88e6xxx/port.h
index 4489d9e..921eecf 100644
--- a/drivers/net/dsa/mv88e6xxx/port.h
+++ b/drivers/net/dsa/mv88e6xxx/port.h
@@ -31,4 +31,7 @@ int mv88e6xxx_port_set_fid(struct mv88e6xxx_chip *chip, int 
port, u16 fid);
 int mv88e6xxx_port_get_pvid(struct mv88e6xxx_chip *chip, int port, u16 *pvid);
 int mv88e6xxx_port_set_pvid(struct mv88e6xxx_chip *chip, int port, u16 pvid);
 
+int mv88e6xxx_port_set_8021q_mode(struct mv88e6xxx_chip *chip, int port,
+ u16 mode);
+
 #endif /* _MV88E6XXX_PORT_H */
-- 
2.10.2

[PATCH net-next v2 09/11] net: dsa: mv88e6xxx: add port's RGMII delay setter

[Vivien Didelot]

Some chips such as 88E6352 and 88E6390 can be programmed to add delays
to RXCLK for IND inputs or to GTXCLK for OUTD outputs when port is in
RGMII mode.

Add a port function to program such delays according to the provided PHY
interface mode.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  |  4 +++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  6 
 drivers/net/dsa/mv88e6xxx/port.c  | 58 +++
 drivers/net/dsa/mv88e6xxx/port.h  |  5 +++
 4 files changed, 73 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 49a6935..bb93d0a 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3220,6 +3220,7 @@ static const struct mv88e6xxx_ops mv88e6172_ops = {
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
+   .port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
 };
 
 static const struct mv88e6xxx_ops mv88e6175_ops = {
@@ -3238,6 +3239,7 @@ static const struct mv88e6xxx_ops mv88e6176_ops = {
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
+   .port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
 };
 
 static const struct mv88e6xxx_ops mv88e6185_ops = {
@@ -3256,6 +3258,7 @@ static const struct mv88e6xxx_ops mv88e6240_ops = {
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
+   .port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
 };
 
 static const struct mv88e6xxx_ops mv88e6320_ops = {
@@ -3302,6 +3305,7 @@ static const struct mv88e6xxx_ops mv88e6352_ops = {
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
.port_set_duplex = mv88e6xxx_port_set_duplex,
+   .port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
 };
 
 static const struct mv88e6xxx_info mv88e6xxx_table[] = {
diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h 
b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index ab48eb9..c7527c0 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -728,6 +728,12 @@ struct mv88e6xxx_ops {
int (*phy_write)(struct mv88e6xxx_chip *chip, int addr, int reg,
 u16 val);
 
+   /* RGMII Receive/Transmit Timing Control
+* Add delay on PHY_INTERFACE_MODE_RGMII_*ID, no delay otherwise.
+*/
+   int (*port_set_rgmii_delay)(struct mv88e6xxx_chip *chip, int port,
+   phy_interface_t mode);
+
 #define LINK_FORCED_DOWN   0
 #define LINK_FORCED_UP 1
 #define LINK_UNFORCED  -2
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 17b5444..838068d 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -35,6 +35,64 @@ int mv88e6xxx_port_write(struct mv88e6xxx_chip *chip, int 
port, int reg,
  * Link, Duplex and Flow Control have one force bit, one value bit.
  */
 
+static int mv88e6xxx_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int 
port,
+ phy_interface_t mode)
+{
+   u16 reg;
+   int err;
+
+   err = mv88e6xxx_port_read(chip, port, PORT_PCS_CTRL, );
+   if (err)
+   return err;
+
+   reg &= ~(PORT_PCS_CTRL_RGMII_DELAY_RXCLK |
+PORT_PCS_CTRL_RGMII_DELAY_TXCLK);
+
+   switch (mode) {
+   case PHY_INTERFACE_MODE_RGMII_RXID:
+   reg |= PORT_PCS_CTRL_RGMII_DELAY_RXCLK;
+   break;
+   case PHY_INTERFACE_MODE_RGMII_TXID:
+   reg |= PORT_PCS_CTRL_RGMII_DELAY_TXCLK;
+   break;
+   case PHY_INTERFACE_MODE_RGMII_ID:
+   reg |= PORT_PCS_CTRL_RGMII_DELAY_RXCLK |
+   PORT_PCS_CTRL_RGMII_DELAY_TXCLK;
+   break;
+   default:
+   /* no delay */
+   break;
+   }
+
+   err = mv88e6xxx_port_write(chip, port, PORT_PCS_CTRL, reg);
+   if (err)
+   return err;
+
+   netdev_dbg(chip->ds->ports[port].netdev, "delay RXCLK %s, TXCLK %s\n",
+  reg & PORT_PCS_CTRL_RGMII_DELAY_RXCLK ? "yes" : "no",
+  reg & PORT_PCS_CTRL_RGMII_DELAY_TXCLK ? "yes" : "no");
+
+   return 0;
+}
+
+int mv88e6352_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
+  phy_interface_t mode)
+{
+   if (port < 5)
+   return -EOPNOTSUPP;
+
+   return mv88e6xxx_port_set_rgmii_delay(chip, port, mode);
+}
+
+int mv88e6390_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
+  phy_interface_t mode)
+{
+   if (port != 0)
+ 

[PATCH net-next v2 07/11] net: dsa: mv88e6xxx: add port link setter

[Vivien Didelot]

Most of the chips will have a port register control bits to force the
port's link up, down, or let normal link detection occurs.

Implement such operation to use it later when setting duplex, etc.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  | 17 +++
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 10 +
 drivers/net/dsa/mv88e6xxx/port.c  | 41 +++
 drivers/net/dsa/mv88e6xxx/port.h  |  2 ++
 4 files changed, 70 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 181d3b9..cc43e6f 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3160,42 +3160,49 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6095_ops = {
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6123_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6131_ops = {
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6161_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6165_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6171_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6172_ops = {
@@ -3204,12 +3211,14 @@ static const struct mv88e6xxx_ops mv88e6172_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6175_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6176_ops = {
@@ -3218,12 +3227,14 @@ static const struct mv88e6xxx_ops mv88e6176_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6185_ops = {
.set_switch_mac = mv88e6xxx_g1_set_switch_mac,
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6240_ops = {
@@ -3232,6 +3243,7 @@ static const struct mv88e6xxx_ops mv88e6240_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6320_ops = {
@@ -3240,6 +3252,7 @@ static const struct mv88e6xxx_ops mv88e6320_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6321_ops = {
@@ -3248,18 +3261,21 @@ static const struct mv88e6xxx_ops mv88e6321_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6350_ops = {
.set_switch_mac = mv88e6xxx_g2_set_switch_mac,
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
+   .port_set_link = mv88e6xxx_port_set_link,
 };
 
 static const struct mv88e6xxx_ops mv88e6351_ops = {
.set_switch_mac = 

[PATCH net-next v2 00/11] net: dsa: mv88e6xxx: refine port operations

[Vivien Didelot]

The Marvell chips have one internal SMI device per port, containing a
set of registers used to configure a port's link, STP state, default
VLAN or addresses database, etc.

This patchset creates port files to implement the port operations as
described in datasheets, and extend the chip ops structure with them.

Patches 1 to 6 implement accessors for port's STP state, port based VLAN
map, default FID, default VID, and 802.1Q mode.

Patches 7 to 11 implement the port's MAC setup of link state, duplex
mode, RGMII delay and speed, all accessed through port's register 0x01.

The new port's MAC setup code is used to re-implement the adjust_link
code and correctly force the link down before changing any of the MAC
settings, as requested by the datasheets.

The port's MAC accessors use values compatible with struct phy_device
(e.g. DUPLEX_FULL) and extend them when needed (e.g. SPEED_MAX).

Changes in v2:

  - Strictly use new _UNFORCED values instead of re-using _UNKNOWN ones.

Vivien Didelot (11):
  net: dsa: mv88e6xxx: add port files
  net: dsa: mv88e6xxx: add port state setter
  net: dsa: mv88e6xxx: add port vlan map setter
  net: dsa: mv88e6xxx: add port FID accessors
  net: dsa: mv88e6xxx: add port PVID accessors
  net: dsa: mv88e6xxx: add port 802.1Q mode setter
  net: dsa: mv88e6xxx: add port link setter
  net: dsa: mv88e6xxx: add port duplex setter
  net: dsa: mv88e6xxx: add port's RGMII delay setter
  net: dsa: mv88e6xxx: add port's MAC speed setter
  net: dsa: mv88e6xxx: setup port's MAC

 drivers/net/dsa/mv88e6xxx/Makefile|   1 +
 drivers/net/dsa/mv88e6xxx/chip.c  | 436 +
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  49 +++-
 drivers/net/dsa/mv88e6xxx/port.c  | 497 ++
 drivers/net/dsa/mv88e6xxx/port.h  |  52 
 5 files changed, 727 insertions(+), 308 deletions(-)
 create mode 100644 drivers/net/dsa/mv88e6xxx/port.c
 create mode 100644 drivers/net/dsa/mv88e6xxx/port.h

-- 
2.10.2

[PATCH net-next v2 03/11] net: dsa: mv88e6xxx: add port vlan map setter

[Vivien Didelot]

Add a port function to access the Port Based VLAN Map register.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 14 ++
 drivers/net/dsa/mv88e6xxx/port.c | 25 +
 drivers/net/dsa/mv88e6xxx/port.h |  2 ++
 3 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 12c1175..087 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1218,16 +1218,13 @@ static int _mv88e6xxx_atu_remove(struct mv88e6xxx_chip 
*chip, u16 fid,
 static int _mv88e6xxx_port_based_vlan_map(struct mv88e6xxx_chip *chip, int 
port)
 {
struct net_device *bridge = chip->ports[port].bridge_dev;
-   const u16 mask = (1 << mv88e6xxx_num_ports(chip)) - 1;
struct dsa_switch *ds = chip->ds;
u16 output_ports = 0;
-   u16 reg;
-   int err;
int i;
 
/* allow CPU port or DSA link(s) to send frames to every port */
if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port)) {
-   output_ports = mask;
+   output_ports = ~0;
} else {
for (i = 0; i < mv88e6xxx_num_ports(chip); ++i) {
/* allow sending frames to every group member */
@@ -1243,14 +1240,7 @@ static int _mv88e6xxx_port_based_vlan_map(struct 
mv88e6xxx_chip *chip, int port)
/* prevent frames from going back out of the port they came in on */
output_ports &= ~BIT(port);
 
-   err = mv88e6xxx_port_read(chip, port, PORT_BASE_VLAN, );
-   if (err)
-   return err;
-
-   reg &= ~mask;
-   reg |= output_ports & mask;
-
-   return mv88e6xxx_port_write(chip, port, PORT_BASE_VLAN, reg);
+   return mv88e6xxx_port_set_vlan_map(chip, port, output_ports);
 }
 
 static void mv88e6xxx_port_stp_state_set(struct dsa_switch *ds, int port,
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 8d59fe7..c6a22ae 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -60,3 +60,28 @@ int mv88e6xxx_port_set_state(struct mv88e6xxx_chip *chip, 
int port, u8 state)
 
return 0;
 }
+
+/* Offset 0x06: Port Based VLAN Map */
+
+int mv88e6xxx_port_set_vlan_map(struct mv88e6xxx_chip *chip, int port, u16 map)
+{
+   const u16 mask = GENMASK(mv88e6xxx_num_ports(chip) - 1, 0);
+   u16 reg;
+   int err;
+
+   err = mv88e6xxx_port_read(chip, port, PORT_BASE_VLAN, );
+   if (err)
+   return err;
+
+   reg &= ~mask;
+   reg |= map & mask;
+
+   err = mv88e6xxx_port_write(chip, port, PORT_BASE_VLAN, reg);
+   if (err)
+   return err;
+
+   netdev_dbg(chip->ds->ports[port].netdev, "VLANTable set to %.3x\n",
+  map);
+
+   return 0;
+}
diff --git a/drivers/net/dsa/mv88e6xxx/port.h b/drivers/net/dsa/mv88e6xxx/port.h
index ac13988..037d638 100644
--- a/drivers/net/dsa/mv88e6xxx/port.h
+++ b/drivers/net/dsa/mv88e6xxx/port.h
@@ -23,4 +23,6 @@ int mv88e6xxx_port_write(struct mv88e6xxx_chip *chip, int 
port, int reg,
 
 int mv88e6xxx_port_set_state(struct mv88e6xxx_chip *chip, int port, u8 state);
 
+int mv88e6xxx_port_set_vlan_map(struct mv88e6xxx_chip *chip, int port, u16 
map);
+
 #endif /* _MV88E6XXX_PORT_H */
-- 
2.10.2

[PATCH net-next v2 08/11] net: dsa: mv88e6xxx: add port duplex setter

[Vivien Didelot]

Similarly to port's link, add setter to force port's half duplex, full
duplex or let normal duplex detection occurs.

Signed-off-by: Vivien Didelot 
---
 drivers/net/dsa/mv88e6xxx/chip.c  | 17 +
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h |  9 +
 drivers/net/dsa/mv88e6xxx/port.c  | 36 +++
 drivers/net/dsa/mv88e6xxx/port.h  |  2 ++
 4 files changed, 64 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index cc43e6f..49a6935 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3161,6 +3161,7 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6095_ops = {
@@ -3168,6 +3169,7 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6123_ops = {
@@ -3175,6 +3177,7 @@ static const struct mv88e6xxx_ops mv88e6123_ops = {
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6131_ops = {
@@ -3182,6 +3185,7 @@ static const struct mv88e6xxx_ops mv88e6131_ops = {
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6161_ops = {
@@ -3189,6 +3193,7 @@ static const struct mv88e6xxx_ops mv88e6161_ops = {
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6165_ops = {
@@ -3196,6 +3201,7 @@ static const struct mv88e6xxx_ops mv88e6165_ops = {
.phy_read = mv88e6xxx_read,
.phy_write = mv88e6xxx_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6171_ops = {
@@ -3203,6 +3209,7 @@ static const struct mv88e6xxx_ops mv88e6171_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6172_ops = {
@@ -3212,6 +3219,7 @@ static const struct mv88e6xxx_ops mv88e6172_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6175_ops = {
@@ -3219,6 +3227,7 @@ static const struct mv88e6xxx_ops mv88e6175_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6176_ops = {
@@ -3228,6 +3237,7 @@ static const struct mv88e6xxx_ops mv88e6176_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6185_ops = {
@@ -3235,6 +3245,7 @@ static const struct mv88e6xxx_ops mv88e6185_ops = {
.phy_read = mv88e6xxx_phy_ppu_read,
.phy_write = mv88e6xxx_phy_ppu_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6240_ops = {
@@ -3244,6 +3255,7 @@ static const struct mv88e6xxx_ops mv88e6240_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6320_ops = {
@@ -3253,6 +3265,7 @@ static const struct mv88e6xxx_ops mv88e6320_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,
.phy_write = mv88e6xxx_g2_smi_phy_write,
.port_set_link = mv88e6xxx_port_set_link,
+   .port_set_duplex = mv88e6xxx_port_set_duplex,
 };
 
 static const struct mv88e6xxx_ops mv88e6321_ops = {
@@ -3262,6 +3275,7 @@ static const struct mv88e6xxx_ops mv88e6321_ops = {
.phy_read = mv88e6xxx_g2_smi_phy_read,