* [PATCH v2 0/4] Fixes for omapdrm on OpenPandora and GTA04
From: H. Nikolaus Schaller @ 2017-11-16 8:50 UTC (permalink / raw)
To: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Tomi Valkeinen,
Bartlomiej Zolnierkiewicz, Laurent Pinchart, H. Nikolaus Schaller,
Julia Lawall, Sean Paul
Cc: devicetree, linux-fbdev, letux-kernel, linux-kernel, dri-devel,
kernel, linux-omap, linux-arm-kernel
V2:
* replaced patch to fix DSI VDDS for OMAP3 by equivalent patch from Laurent Pinchart
* keep previous compatibility option in panel driver to handle older device tree binaries
2017-11-08 22:09:36:
This patch set fixes vendor names of the panels
and fixes a problem on omapdrm with enabling
VDD_DSI for OMAP3 which is needed for displaying
the Red and Green channel on OMAP3530 (Pandora).
H. Nikolaus Schaller (3):
omapdrm: fix compatible string for td028ttec1
DTS: GTA04: fix panel compatibility string
DTS: Pandora: fix panel compatibility string
Laurent Pinchart (1):
drm: omapdrm: Fix DPI on platforms using the DSI VDDS
.../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} | 4 ++--
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 4 ++--
drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 4 +++-
6 files changed, 11 insertions(+), 9 deletions(-)
rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} (84%)
--
2.12.2
^ permalink raw reply
* Re: [PATCH 4/8] dt-bindings: usb: document hub and host-controller properties
From: Johan Hovold @ 2017-11-16 8:45 UTC (permalink / raw)
To: Rob Herring
Cc: Johan Hovold, Greg Kroah-Hartman, Mark Rutland, Arnd Bergmann,
Alan Stern, Peter Chen, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171115154655.rw4n5ihhcm7ilrmv@rob-hp-laptop>
On Wed, Nov 15, 2017 at 09:46:55AM -0600, Rob Herring wrote:
> On Thu, Nov 09, 2017 at 06:07:19PM +0100, Johan Hovold wrote:
> > Hub nodes and host-controller nodes with child nodes must specify values
> > for #address-cells (1) and #size-cells (0).
> >
> > Also make the definition of the related reg property a bit more
> > stringent, and add comments to the example source.
> >
> > Signed-off-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/usb/usb-device.txt | 20 ++++++++++++++++----
> > 1 file changed, 16 insertions(+), 4 deletions(-)
>
> I'm happy to apply patches 1-4 for 4.15 if you want.
Sure, that would be great. Greg will probably base usb-next on 4.15-rc2,
and otherwise the rest of the binding updates can just go through your
tree instead.
Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm64: dts: ls1088a: add fsl-mc hardware resource manager node
From: Shawn Guo @ 2017-11-16 8:39 UTC (permalink / raw)
To: Ioana Ciornei
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1510147805-24873-1-git-send-email-ioana.ciornei-3arQi8VN3Tc@public.gmane.org>
On Wed, Nov 08, 2017 at 03:30:05PM +0200, Ioana Ciornei wrote:
> Add the fsl-mc node in the LS1088A device tree.
>
> Signed-off-by: Ioana Ciornei <ioana.ciornei-3arQi8VN3Tc@public.gmane.org>
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 62 ++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index bd80e9a..aa37ffe 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -166,6 +166,68 @@
> <1 10 IRQ_TYPE_LEVEL_LOW>;/* Hypervisor PPI */
> };
>
> + fsl_mc: fsl-mc@80c000000 {
The unit-address of the node should be somehow related to 'reg'
property. Can you please help me understand how they are related?
> + compatible = "fsl,qoriq-mc";
> + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */
> + <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> + msi-parent = <&its>;
> + #address-cells = <3>;
> + #size-cells = <1>;
> +
> + /*
> + * Region type 0x0 - MC portals
> + * Region type 0x1 - QBMAN portals
> + */
> + ranges = <0x0 0x0 0x0 0x8 0x0c000000 0x4000000
> + 0x1 0x0 0x0 0x8 0x18000000 0x8000000>;
> +
> + dpmacs {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dpmac1: dpmac@1 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <1>;
> + };
Please have a newline in between nodes.
Shawn
> + dpmac2: dpmac@2 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <2>;
> + };
> + dpmac3: dpmac@3 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <3>;
> + };
> + dpmac4: dpmac@4 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <4>;
> + };
> + dpmac5: dpmac@5 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <5>;
> + };
> + dpmac6: dpmac@6 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <6>;
> + };
> + dpmac7: dpmac@7 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <7>;
> + };
> + dpmac8: dpmac@8 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <8>;
> + };
> + dpmac9: dpmac@9 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <9>;
> + };
> + dpmac10: dpmac@10 {
> + compatible = "fsl,qoriq-mc-dpmac";
> + reg = <0xa>;
> + };
> + };
> + };
> +
> psci {
> compatible = "arm,psci-0.2";
> method = "smc";
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 2/2] ARM: dts: TS-4600: add basic device tree
From: Shawn Guo @ 2017-11-16 8:00 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, mark.rutland-5wv7dgnIgG8,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
fabio.estevam-3arQi8VN3Tc, kris-L1vi/lXTdtvnC/t2CciAbw,
mark-L1vi/lXTdtvnC/t2CciAbw
In-Reply-To: <20171101170645.12918-2-sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
On Wed, Nov 01, 2017 at 01:06:45PM -0400, Sebastien Bourdelin wrote:
> These device trees add support for the TS-4600 by Technologic Systems.
>
> More details here:
> http://wiki.embeddedarm.com/wiki/TS-4600
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
> ---
> Changes v6 -> v7:
> - rebase on master
> - remove unneeded pinctrl-name (suggested by Shawn Guo)
> - add reg to the node en-sd-pwr (suggested by Shawn Guo)
> - use define for gpio polarity (suggested by Shawn Guo)
> - remove the fake bus container for regulator (suggested by Shawn Guo)
>
> Changes v5 -> v6:
> - rebase on master
> - split the previous patch series into series by subsystem
>
> Changes v4 -> v5:
> - fix missing signed off
>
> Changes v3 -> v4:
> - rebase on master
>
> Changes v2 -> v3:
> - rebase on master
>
> Changes v1 -> v2:
> - rebase on master
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx28-ts4600-common.dtsi | 74 ++++++++++++++++++++++++++++++
> arch/arm/boot/dts/imx28-ts4600-rev-a.dts | 22 +++++++++
> arch/arm/boot/dts/imx28-ts4600-rev-b.dts | 22 +++++++++
> 4 files changed, 120 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
> create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
> create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faf46abaa4a2..430fe7f1e644 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -532,6 +532,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
> imx28-m28cu3.dtb \
> imx28-m28evk.dtb \
> imx28-sps1.dtb \
> + imx28-ts4600-rev-a.dtb \
> + imx28-ts4600-rev-b.dtb \
> imx28-tx28.dtb
> dtb-$(CONFIG_ARCH_NOMADIK) += \
> ste-nomadik-s8815.dtb \
> diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> new file mode 100644
> index 000000000000..c5f6bef87fd5
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> @@ -0,0 +1,74 @@
> +/*
> + * Copyright (C) 2016 Savoir-Faire Linux
> + * Author: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx28.dtsi"
> +#include "dt-bindings/gpio/gpio.h"
> +
> +/ {
> +
> + compatible = "technologic,imx28-ts4600", "fsl,imx28";
> +
> + apb@80000000 {
> + apbh@80000000 {
> + ssp0: ssp@80010000 {
> + compatible = "fsl,imx28-mmc";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_4bit_pins_a
> + &mmc0_sck_cfg
> + &en_sd_pwr>;
> + broken-cd = <1>;
> + bus-width = <4>;
> + vmmc-supply = <®_vddio_sd0>;
> + status = "okay";
> + };
> +
> + pinctrl@80018000 {
> +
> + en_sd_pwr: en-sd-pwr@0 {
> + reg = <0>;
> + fsl,pinmux-ids = <
> + MX28_PAD_PWM3__GPIO_3_28
> + >;
> + fsl,drive-strength = <MXS_DRIVE_4mA>;
> + fsl,voltage = <MXS_VOLTAGE_HIGH>;
> + fsl,pull-up = <MXS_PULL_DISABLE>;
> + };
> +
> + };
> + };
> +
> + apbx@80040000 {
> + pwm: pwm@80064000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm2_pins_a>;
> + status = "okay";
> + };
> +
> + duart: serial@80074000 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&duart_pins_a>;
> + status = "okay";
> + };
> + };
> + };
> +
> + reg_vddio_sd0: regulator-vddio-sd0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vddio-sd0";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + gpio = <&gpio3 28 GPIO_ACTIVE_HIGH>;
> + };
> +
> +};
> diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-a.dts b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
> new file mode 100644
> index 000000000000..e8cb72988fcf
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2016 Savoir-Faire Linux
> + * Author: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include "imx28-ts4600-common.dtsi"
> +
> +/ {
> + model = "Technologic Systems i.MX28 TS-4600 Rev A";
> +
> + memory {
> + reg = <0x40000000 0x08000000>; /* 128MB */
If memory size is the only difference between Rev A and B, can we have
device tree default to most used revision and ask bootloader to fix up
memory node for the other revision? In that case, we only need to
maintain imx28-ts4600.dts then.
Shawn
> + };
> +
> +};
> diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-b.dts b/arch/arm/boot/dts/imx28-ts4600-rev-b.dts
> new file mode 100644
> index 000000000000..a115f831fe2b
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx28-ts4600-rev-b.dts
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2016 Savoir-Faire Linux
> + * Author: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include "imx28-ts4600-common.dtsi"
> +
> +/ {
> + model = "Technologic Systems i.MX28 TS-4600 Rev B";
> +
> + memory {
> + reg = <0x40000000 0x10000000>; /* 256MB */
> + };
> +
> +};
> --
> 2.13.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5] ARM: dts: imx53-tx53: Fix 'ethernet-phy@0' node with unit name and no reg property
From: Shawn Guo @ 2017-11-16 7:36 UTC (permalink / raw)
To: Marco Franchi
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
festevam-Re5JQEeQqe8AvxtiuMwx3w, marcofrk-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1509031514-30602-1-git-send-email-marco.franchi-3arQi8VN3Tc@public.gmane.org>
On Thu, Oct 26, 2017 at 01:25:14PM -0200, Marco Franchi wrote:
> The following build warning is seen with W=1:
>
> Warning (unit_address_vs_reg): Node /soc/aips@60000000/ethernet@63fec000/ethernet-phy@0 has a unit name, but no reg property
>
> Fix this warning by adding reg property from such node and, consequently,
> includes a mdio node into the fec node, with the 'address-cells' and
> 'size-cells' to avoid these other following warnings:
>
> Warning (reg_format): "reg" property in /soc/aips@60000000/ethernet@63fec000/ethernet-phy@0 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
> Warning (avoid_default_addr_size): Relying on default #address-cells value for /soc/aips@60000000/ethernet@63fec000/ethernet-phy@0
> Warning (avoid_default_addr_size): Relying on default #size-cells value for /soc/aips@60000000/ethernet@63fec000/ethernet-phy@0
>
> Signed-off-by: Marco Franchi <marco.franchi-3arQi8VN3Tc@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH] ARM: dts: ls1021a: Add support for QSPI with ls1021a SoC
From: Shawn Guo @ 2017-11-16 7:33 UTC (permalink / raw)
To: Li Yang
Cc: SZ Lin, Minghuan Lian, Zhiqiang Hou, andy.tang-3arQi8VN3Tc,
yi.sheng.lin-3arQi8VN3Tc, Rob Herring, Mark Rutland, Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
lkml
In-Reply-To: <CADRPPNREzRzzW-VRpm6P3y8_sYwvm_c13n6vjgQZP24fxO9uKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Oct 25, 2017 at 04:00:36PM -0500, Li Yang wrote:
> On Tue, Sep 12, 2017 at 1:49 AM, SZ Lin <sz.lin-D4fb9hXD9d4@public.gmane.org> wrote:
> > Add QSPI node support, and this function is disabled by default
> > This setting could be overwritten in board-level definitions
>
> Adding Shawn Guo.
>
> >
> > Signed-off-by: SZ Lin <sz.lin-D4fb9hXD9d4@public.gmane.org>
>
> Acked-by: Li Yang <leoyang.li-3arQi8VN3Tc@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ls1088a: Add USB support
From: Shawn Guo @ 2017-11-16 6:58 UTC (permalink / raw)
To: Yinbo Zhu
Cc: Mark Rutland, Harninder Rai, Andy Tang,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Catalin Marinas ), Will Deacon ), Ashish Kumar, open list,
Rob Herring, Raghav Dogra,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <AM3PR04MB12515DB71B8ACF7422A20244E9280-f56W/S9L6NR31AIMYRlgnc9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Tue, Nov 14, 2017 at 08:00:00AM +0000, Yinbo Zhu wrote:
> On Wed, Sep 13, 2017 at 05:10:09PM +0800, yinbo.zhu-3arQi8VN3Tc@public.gmane.org wrote:
> > From: "yinbo.zhu" <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
> >
> > Fix the issue that usb is not detected on ls1088ardb
>
> >It's not really about fixing issue but adding support.
>
> The patch had been tested on upstream 4.14 code, it can fix the issue.
> >
> > Signed-off-by: yinbo.zhu <yinbo.zhu-3arQi8VN3Tc@public.gmane.org>
> > Signed-off-by: Ran Wang <ran.wang_1-3arQi8VN3Tc@public.gmane.org>
> > ---
>
> >You should better have a version history here to tell what's changed between version.
>
> >I will add a version history on next v3 patch
> Hi,
>
> I had modified the code as v4 version,
> https://patchwork.kernel.org/patch/10027393/
> please check.
You should copy me on that patch, if you expect me to pick it up.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND 1/4] crypto: caam: add caam-dma node to SEC4.0 device tree binding
From: Vinod Koul @ 2017-11-16 6:24 UTC (permalink / raw)
To: Kim Phillips
Cc: Radu Andrei Alexe, Horia Geantă, Herbert Xu, David S. Miller,
Dan Douglass, Shawn Guo,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171110104430.28b2f56f910b7514d778c4b2-5wv7dgnIgG8@public.gmane.org>
On Fri, Nov 10, 2017 at 10:44:30AM -0600, Kim Phillips wrote:
> On Fri, 10 Nov 2017 08:02:01 +0000
> Radu Andrei Alexe <radu.alexe-3arQi8VN3Tc@public.gmane.org> wrote:
>
> > On 11/9/2017 6:34 PM, Kim Phillips wrote:
> > > On Thu, 9 Nov 2017 11:54:13 +0000
> > > Radu Andrei Alexe <radu.alexe-3arQi8VN3Tc@public.gmane.org> wrote:
> > >> The next patch version will create the platform device dynamically at
> > >> run time.
> > >
> > > Why create a new device when that h/w already has one?
> > >
> > > Why doesn't the existing crypto driver register dma capabilities with
> > > the dma driver subsystem?
> > >
> > I can think of two reasons:
> >
> > 1. The code that this driver introduces has nothing to do with crypto
> > and everything to do with dma.
>
> I would think that at least a crypto "null" algorithm implementation
> would share code.
>
> > Placing the code in the same directory as
> > the caam subsystem would only create confusion for the reader of an
> > already complex driver.
>
> this different directory argument seems to be identical to your 2 below:
>
> > 2. I wanted this driver to be tracked by the dma engine team. They have
> > the right expertise to provide adequate feedback. If all the code was in
> > the crypto directory they wouldn't know about this driver or any
> > subsequent changes to it.
>
> dma subsystem bits could still be put in the dma area if deemed
> necessary but I don't think it is: I see
> drivers/crypto/ccp/ccp-dmaengine.c calls dma_async_device_register for
> example.
which is a shame as it was sneaked past the dmaengine community!!
This is the *only* example and there and other examples where people use
dmaengine:
$ grep -rl dmaengine_prep* drivers/crypto/* |uniq
drivers/crypto/atmel-aes.c
drivers/crypto/atmel-sha.c
drivers/crypto/atmel-tdes.c
drivers/crypto/img-hash.c
drivers/crypto/omap-aes.c
drivers/crypto/omap-des.c
drivers/crypto/omap-sham.c
drivers/crypto/qce/dma.c
drivers/crypto/stm32/stm32-hash.c
drivers/crypto/ux500/cryp/cryp_core.c
drivers/crypto/ux500/hash/hash_core.c
>
> I also don't see how that complicates things much further.
>
> What is the rationale for using the crypto h/w as a dma engine anyway?
> Are there supporting performance figures?
that is a very good question, perf does matter. Given that we have many
folks using it, I think it would help, but yes nothing better than numbers
speak for themselves.
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND 1/4] crypto: caam: add caam-dma node to SEC4.0 device tree binding
From: Vinod Koul @ 2017-11-16 6:18 UTC (permalink / raw)
To: Radu Andrei Alexe
Cc: Kim Phillips, Horia Geantă, Herbert Xu, David S. Miller,
Dan Douglass, Shawn Guo, dmaengine@vger.kernel.org,
linux-crypto@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <VI1PR04MB13253DB5164A151D8E4AB8308A540@VI1PR04MB1325.eurprd04.prod.outlook.com>
On Fri, Nov 10, 2017 at 08:02:01AM +0000, Radu Andrei Alexe wrote:
> On 11/9/2017 6:34 PM, Kim Phillips wrote:
> > On Thu, 9 Nov 2017 11:54:13 +0000
> > Radu Andrei Alexe <radu.alexe@nxp.com> wrote:
> >
> >> On 10/30/2017 4:24 PM, Kim Phillips wrote:
> >>> On Mon, 30 Oct 2017 15:46:51 +0200
> >>> Horia Geantă <horia.geanta@nxp.com> wrote:
> >>>
> >>>> +=====================================================================
> >>>> +CAAM DMA Node
> >>>> +
> >>>> + Child node of the crypto node that enables the use of the DMA capabilities
> >>>> + of the CAAM by a stand-alone driver. The only required property is the
> >>>> + "compatible" property. All the other properties are determined from
> >>>> + the job rings on which the CAAM DMA driver depends (ex: the number of
> >>>> + dma-channels is equal to the number of defined job rings).
> >>>> +
> >>>> + - compatible
> >>>> + Usage: required
> >>>> + Value type: <string>
> >>>> + Definition: Must include "fsl,sec-v4.0-dma"
> >>>> +
> >>>> +EXAMPLE
> >>>> + caam-dma {
> >>>> + compatible = "fsl,sec-v5.4-dma",
> >>>> + "fsl,sec-v5.0-dma",
> >>>> + "fsl,sec-v4.0-dma";
> >>>> + }
> >>>
> >>> If this isn't describing an aspect of the hardware, then what is it
> >>> doing in the device tree?
> >>>
> >>> Kim
> >>>
> >>
> >> Because the caam_dma driver is a platform driver I needed to create a
> >> platform device to activate the driver. My thought was that it was
> >> simpler to implement it using device tree.
> >> The next patch version will create the platform device dynamically at
> >> run time.
> >
> > Why create a new device when that h/w already has one?
> >
> > Why doesn't the existing crypto driver register dma capabilities with
> > the dma driver subsystem?
> >
> > Kim
> >
>
>
> I can think of two reasons:
>
> 1. The code that this driver introduces has nothing to do with crypto
> and everything to do with dma. Placing the code in the same directory as
> the caam subsystem would only create confusion for the reader of an
> already complex driver.
>
> 2. I wanted this driver to be tracked by the dma engine team. They have
> the right expertise to provide adequate feedback. If all the code was in
> the crypto directory they wouldn't know about this driver or any
> subsequent changes to it.
These are very good reasons.
We already have one DMA implementation drivers/crypto/ccp/ccp-dmaengine.c
which was sneaked past us and put into kernel with proper review!
On the other hand we have *bunch* of dmaengine users in crypto subsystem
which use dmaengine drivers and APIs and are good citizens. It allows folks
to share code with other usages of dmaengine and the usual arguments for
common code and frameworks...
If there are enough users we can add up a crypto-dmaengine lib which
programs dma controller for crypto users and avoid open coding for everyone.
for example sound-dmaengine layers does that...
HTH
--
~Vinod
^ permalink raw reply
* [PATCHi v2] dt-bindings: add device tree binding for Arm TrustZone CryptoCell crypto engine
From: Gilad Ben-Yossef @ 2017-11-16 6:15 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Mark Rutland
Cc: Ofir Drang, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The Arm TrustZone CryptoCell is a hardware security engine. This patch
adds DT bindings for its Rich Execution Environment crypto engine.
A driver supporting this device is already present in the staging tree.
Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes from v1:
- Change node name to reflect type of device in example as pointed out by
Rob Herring.
.../devicetree/bindings/crypto/arm-cryptocell.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
new file mode 100644
index 0000000..cec8d5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
@@ -0,0 +1,22 @@
+Arm TrustZone CryptoCell cryptographic engine
+
+Required properties:
+- compatible: Should be "arm,cryptocell-712-ree".
+- reg: Base physical address of the engine and length of memory mapped region.
+- interrupts: Interrupt number for the device.
+
+Optional properties:
+- interrupt-parent: The phandle for the interrupt controller that services
+ interrupts for this device.
+- clocks: Reference to the crypto engine clock.
+- dma-coherent: Present if dma operations are coherent.
+
+Examples:
+
+ arm_cc712: crypto@80000000 {
+ compatible = "arm,cryptocell-712-ree";
+ interrupt-parent = <&intc>;
+ interrupts = < 0 30 4 >;
+ reg = < 0x80000000 0x10000 >;
+
+ };
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH RESEND 4/4] dma: caam: add dma memcpy driver
From: Vinod Koul @ 2017-11-16 6:11 UTC (permalink / raw)
To: Radu Andrei Alexe
Cc: Horia Geantă, Herbert Xu, David S. Miller, Dan Douglass,
Shawn Guo, dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tudor Ambarus,
Rajiv Vishwakarma
In-Reply-To: <VI1PR04MB1325358D7898120FC0BCEBE88A560-mr6QIVyDiCGGEpojCloM0M9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Wed, Nov 08, 2017 at 02:36:31PM +0000, Radu Andrei Alexe wrote:
> On 10/31/2017 2:01 PM, Vinod Koul wrote:
> > On Mon, Oct 30, 2017 at 03:46:54PM +0200, Horia Geantă wrote:
> >> +/*
> >> + * caam support for SG DMA
> >> + *
> >> + * Copyright 2016 Freescale Semiconductor, Inc
> >> + * Copyright 2017 NXP
> >> + */
> >
> > that is interesting, no license text?
> >
>
> Thanks for the catch. The next patch will contain the full license text.
or as is the "new" practice, you may used SPDX tags
> >> +#include "../crypto/caam/regs.h"
> >> +#include "../crypto/caam/jr.h"
> >> +#include "../crypto/caam/error.h"
> >> +#include "../crypto/caam/intern.h"
> >> +#include "../crypto/caam/desc_constr.h"
> >
> > ah that puts very hard assumptions on locations of the subsystems. Please do
> > not do that and move the required stuff into common header location in
> > include/
> >
>
> Unfortunately this is not possible. The functionality used by CAAM DMA
> from the CAAM subsystem should not be exported to be used by other
> modules. It is because this driver is so tightly coupled with the CAAM
> driver(s) that it needs access to it's 'internal' functionality (that
> should not be otherwise shared with anyone).
Which other driver would be interested in your CAM implementation except
you. Realistically speaking none, so it is perfectly fine to do so in a
header at a right place!
> >> +struct caam_dma_sh_desc {
> >
> > sh?
> >
>
> It means "shared". It is obvious to anyone who is familiar with the CAAM
> system.
Unfortunately I am not. As a patch writer you have the onus to explain it to
people who live outside the CAAM world
> >> +static struct dma_device *dma_dev;
> >> +static struct caam_dma_sh_desc *dma_sh_desc;
> >> +static LIST_HEAD(dma_ctx_list);
> >
> > why do you need so many globals?
> >
>
> How many globals are too many? I can group them in a common structure.
> But I'm not sure how would that help.
I prefer none. Make sure the struct instance is not global and allocated in
your driver probe routine.
> >> +static dma_cookie_t caam_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> >> +{
> >> + struct caam_dma_edesc *edesc = NULL;
> >> + struct caam_dma_ctx *ctx = NULL;
> >> + dma_cookie_t cookie;
> >> +
> >> + edesc = container_of(tx, struct caam_dma_edesc, async_tx);
> >> + ctx = container_of(tx->chan, struct caam_dma_ctx, chan);
> >> +
> >> + spin_lock_bh(&ctx->edesc_lock);
> >
> > why _bh, i didnt see any irqs or tasklets here which is actually odd, so
> > what is going on
> >
>
> The tasklet is hidden inside the JR driver from the CAAM subsystem (see
> drivers/crypto/caam/jr.c). The function caam_dma_done(), which is called
> from the JR tasklet handler, also uses the spin_lock. I need to disable
> bottom half to make sure that I don't run into a deadlock when I'm
> preempted.
This would be the right time to explain why. I understand that your subsystem
has tightly coupled DMA but that doesn't really mean the DMA controller should
not have its own IRQ and bh. This makes things harder to review and follow.
> >> + cookie = dma_cookie_assign(tx);
> >> + list_add_tail(&edesc->node, &ctx->submit_q);
> >> +
> >> + spin_unlock_bh(&ctx->edesc_lock);
> >> +
> >> + return cookie;
> >> +}
> >
> > we have a virtual channel wrapper where we do the same stuff as above, so
> > consider reusing that
> >
>
> Some of the functionality that the virtual channel might provide cannot
> be extracted because it is embedded into the JR driver (e.g. the
> tasklet). Therefore the use of the virtual channel is inefficient at
> best if not even impossible.
Which itself is problematic in first place and no explanation provided on
why. Yes you have a special hardware, so does every second person!
> >> +static void caam_dma_issue_pending(struct dma_chan *chan)
> >> +{
> >> + struct caam_dma_ctx *ctx = container_of(chan, struct caam_dma_ctx,
> >> + chan);
> >> + struct caam_dma_edesc *edesc, *_edesc;
> >> +
> >> + spin_lock_bh(&ctx->edesc_lock);
> >> + list_for_each_entry_safe(edesc, _edesc, &ctx->submit_q, node) {
> >> + if (caam_jr_enqueue(ctx->jrdev, edesc->jd,
> >> + caam_dma_done, edesc) < 0)
> >
> > what does the caam_jr_enqueue() do?
> >
>
> Enqueues a job descriptor (jd) into a job ring (jr). Additionally the
> "caam_dma_done()" function is registered to be used as a callback when
> the job finishes. For more details see drivers/crypto/caam/jr.c.
Sorry I am going to refuse to look at other references. A patch should
provide enough explanation on its own for me to review.
> >> + err = dma_async_device_register(dma_dev);
> >> + if (err) {
> >> + dev_err(dev, "Failed to register CAAM DMA engine\n");
> >> + goto jr_bind_err;
> >> + }
> >> +
> >> + dev_info(dev, "caam dma support with %d job rings\n", bonds);
> >
> > that is very noisy
> >
>
> I want to print a line that informs that the caam_dma driver has been
> successfully probed. Do you have any other suggestion?
Please remove the line, or worst make this debug print
Overall I am not very excited about this implementation. I think things can
be improved and decoupled from crypto driver and things done independently.
If you do so this driver can be reused across different crypto
implementations where you have the same DMA controller.
Thanks
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] MIPS: implement a "bootargs-append" DT property
From: Rob Herring @ 2017-11-16 5:26 UTC (permalink / raw)
To: Daniel Gimpelevich
Cc: James Hogan, Linux-MIPS, Frank Rowand, devicetree@vger.kernel.org,
Geert Uytterhoeven
In-Reply-To: <1510796793.16864.25.camel@chimera>
On Wed, Nov 15, 2017 at 7:46 PM, Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us> wrote:
> On Tue, 2017-11-14 at 11:18 -0600, Rob Herring wrote:
>> I understand you can't apply random strings in any order you like. I'm
>> questioning the need to do that and what are the concrete example(s)
>> where you need that ability.
>
> Concrete:
> Pre-DT bootloader provides "console=/dev/someunusualdevice" and
> "root=/dev/mtdblock1" in argv. The dtb arranges flash differently and
> supplies "root=/dev/mtd2" in bootargs. Kernel uses /dev/mtdblock1 and
> panics, or alternatively uses /dev/mtd2 with no console.
>
>> I'd generally expect that only board specific options are in the dtb,
>> and a distro will add it's own options common for all and the specific
>> arch into the bootloader config files. And generally, the last thing
>> loaded gets the last say in what is set.
>
> Bootloaders and their configs are not distro-dependent.
For the ones that install grub, they are.
>> What h/w specific options would be needed for recovery kernel? That's
>> getting into putting not just Linux specifics into the dtb, but distro
>> specifics there. While yes, the dts files often already have bootargs
>> filled with Linux options, the intention is really that the bootloader
>> fills in bootargs. And if you have multiple kernels or OSs, then the
>> bootloader provides the mechanism to choose and boot with the right
>> options.
>
> Kernels _are_ distro-specific. A recovery kernel might also have options
> that are not hardware specific in addition to options that are.
>
>> I think the kernel (being last) should fully decide what to do:
>> append, prepend, and/or override. There was some work a while back to
>> support more flexible command line handling and be arch neutral, but
>> it never got merged.
>
> The kernel would not always have all the information needed for this
> decision now like it would before DT. The dtb should decide what
> precedence its bootargs have, and the kernel should decide what
> precedence compiled-in bootargs have. Such logic is provided by this
> patch, but not completely, because there is still no "bootargs-prepend"
> property. The only use case I can think of for "bootargs-prepend" would
> be to provide a default command line that is specific to a board that
> would sometimes have one bootloader, and sometimes another. Currently,
> such a situation can be worked around using a board-specific kernel, but
> this mechanism is a relic from pre-DT days.
>
^ permalink raw reply
* Re: [PATCH v7 10/13] dt-bindings: Add qcom slimbus controller bindings
From: Rob Herring @ 2017-11-16 5:19 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, alsa-devel, michael.opdenacker, poeschel,
andreas.noever, arnd, vinod.koul, treding, devicetree,
james.hogan, pawel.moll, linux-arm-msm, sharon.dvir1, broonie,
sdharia, alan, bp, mathieu.poirier, gregkh, linux-kernel, daniel,
jkosina, joe, davem
In-Reply-To: <20171115141043.29202-11-srinivas.kandagatla@linaro.org>
On Wed, Nov 15, 2017 at 02:10:40PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Sagar Dharia <sdharia@codeaurora.org>
>
> This patch add device tree bindings for Qualcomm slimbus controller.
>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> .../devicetree/bindings/slimbus/slim-qcom-ctrl.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
> new file mode 100644
> index 000000000000..e4d28910b2e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
> @@ -0,0 +1,43 @@
> +Qualcomm SLIMBUS controller
> +This controller is used if applications processor driver controls slimbus
> +master component.
> +
> +Required properties:
> +
> + - #address-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
> + - #size-cells - refer to Documentation/devicetree/bindings/slimbus/bus.txt
> +
> + - reg : Offset and length of the register region(s) for the device
> + - reg-names : Register region name(s) referenced in reg above
> + Required register resource entries are:
> + "ctrl": Physical address of controller register blocks
> + - compatible : should be "qcom,<SOC-NAME>-slim" for SOC specific compatible
> + followed by "qcom,slim" for fallback.
> + - interrupts : Interrupt number used by this controller
> + - clocks : Interface and core clocks used by this slimbus controller
> + - clock-names : Required clock-name entries are:
> + "iface_clk" : Interface clock for this controller
> + "core_clk" : Interrupt for controller core's BAM
> +
> +
> +Optional property:
> + - reg entry for slew rate : If slew rate control register is provided, this
> + entry should be used.
> + - reg-name for slew rate: "slew"
reg-names
I'd prefer it be explicit as to which compatibles do or don't have this
register.
> +
> +Example:
> +
> + slim@28080000 {
> + compatible = "qcom,apq8064-slim", "qcom,slim";
> + reg = <0x28080000 0x2000>,
error ^
> + interrupts = <0 33 0>;
> + clocks = <&lcc SLIMBUS_SRC>, <&lcc AUDIO_SLIMBUS_CLK>;
> + clock-names = "iface", "core";
> + #address-cells = <2>;
> + #size-cell = <0>;
> +
> + codec: wcd9310@1,0{
Use generic node names:
wcd9310: audio-codec@1,0
> + compatible = "slim217,60";
> + reg = <1 0>;
> + };
> + };
> --
> 2.15.0
>
^ permalink raw reply
* Re: [GIT PULL] DeviceTree updates for 4.15
From: Linus Torvalds @ 2017-11-16 5:15 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqLgpL+19ekd_J7h-jBic1whcQuU+Vp-HEh-VgShhvSVGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Nov 15, 2017 at 9:05 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> These cases are intentionally bad DT data to feed the testcase. We can
> switch off the warning (at least I think the kbuild infrastructure is
> there), but then the check is disabled for all the good cases too
> which isn't great.
It's fine to have test-cases that are supposed to fail.
But they should warn not as they fail, but only if they fail to fail.
Warning about expected behavior and annoying everybody else is simply
not acceptable.
Linus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 02/13] dt-bindings: Add SLIMbus bindings
From: Rob Herring @ 2017-11-16 5:15 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, alsa-devel, michael.opdenacker, poeschel,
andreas.noever, arnd, vinod.koul, treding, devicetree,
james.hogan, pawel.moll, linux-arm-msm, sharon.dvir1, broonie,
sdharia, alan, bp, mathieu.poirier, gregkh, linux-kernel, daniel,
jkosina, joe, davem
In-Reply-To: <20171115141043.29202-3-srinivas.kandagatla@linaro.org>
On Wed, Nov 15, 2017 at 02:10:32PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Sagar Dharia <sdharia@codeaurora.org>
>
> SLIMbus (Serial Low Power Interchip Media Bus) is a specification
> developed by MIPI (Mobile Industry Processor Interface) alliance.
> SLIMbus is a 2-wire implementation, which is used to communicate with
> peripheral components like audio-codec.
>
> This patch adds device tree bindings for the slimbus.
>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> Documentation/devicetree/bindings/slimbus/bus.txt | 50 +++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: add device tree binding for Arm TrustZone CryptoCell crypto engine
From: Rob Herring @ 2017-11-16 5:12 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Herbert Xu, David S. Miller, Mark Rutland, Ofir Drang,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1510751117-13627-1-git-send-email-gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
On Wed, Nov 15, 2017 at 01:05:17PM +0000, Gilad Ben-Yossef wrote:
> The Arm TrustZone CryptoCell is a hardware security engine. This patch
> adds DT bindings for its Rich Execution Environment crypto engine.
>
> A driver supporting this device is already present in the staging tree.
>
> Signed-off-by: Gilad Ben-Yossef <gilad-6S/DczAoZh3WXxRugSxzZg@public.gmane.org>
> ---
> .../devicetree/bindings/crypto/arm-cryptocell.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
> new file mode 100644
> index 0000000..ccf8a101
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
> @@ -0,0 +1,22 @@
> +Arm TrustZone CryptoCell cryptographic engine
> +
> +Required properties:
> +- compatible: Should be "arm,cryptocell-712-ree".
> +- reg: Base physical address of the engine and length of memory mapped region.
> +- interrupts: Interrupt number for the device.
> +
> +Optional properties:
> +- interrupt-parent: The phandle for the interrupt controller that services
> + interrupts for this device.
> +- clocks: Reference to the crypto engine clock.
> +- dma-coherent: Present if dma operations are coherent.
> +
> +Examples:
> +
> + arm_cc712: arm_cc712@80000000 {
crypto@...
With that,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> + compatible = "arm,cryptocell-712-ree";
> + interrupt-parent = <&intc>;
> + interrupts = < 0 30 4 >;
> + reg = < 0x80000000 0x10000 >;
> +
> + };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of/pci: Fix theoretical NULL dereference
From: Rob Herring @ 2017-11-16 5:10 UTC (permalink / raw)
To: Robin Murphy
Cc: frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f367c825b5e9f8eb9fee3607bbcc16222f10bd72.1510749974.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
On Wed, Nov 15, 2017 at 12:50:06PM +0000, Robin Murphy wrote:
> In the (relatively mechanical) process of adapting the RID-mapping code
> to put the resulting ID in an output argument rather than the funtion
> return value, we ended up with the debug print using the argument
> pointer rather than the local value, which potentially defeats the
> earlier NULL check.
>
> Fixes: 987068fcbdb7: "of/irq: Break out msi-map lookup (again)"
> Reported-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
> drivers/of/of_pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/3] DT: leds: Add Qualcomm Light Pulse Generator binding
From: Rob Herring @ 2017-11-16 5:09 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Richard Purdie, Jacek Anaszewski, Pavel Machek, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Fenglin Wu
In-Reply-To: <20171115071345.24331-4-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Nov 14, 2017 at 11:13:45PM -0800, Bjorn Andersson wrote:
> This adds the binding document describing the three hardware blocks
> related to the Light Pulse Generator found in a wide range of Qualcomm
> PMICs.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> Changes since v2:
> - Squashed all things into one node
> - Removed quirks from the binding, compatible implies number of channels, their
> configuration etc.
> - Binding describes LEDs connected as child nodes
> - Support describing multi-channel LEDs
> - Change style of the binding document, to match other LED bindings
>
> Changes since v1:
> - Dropped custom pattern properties
> - Renamed cell-index to qcom,lpg-channel to clarify its purpose
>
> .../devicetree/bindings/leds/leds-qcom-lpg.txt | 66 ++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/8] dt-bindings: pci: Add DT docs for Brcmstb PCIe device
From: Rob Herring @ 2017-11-16 5:07 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-kernel, Bjorn Helgaas, Catalin Marinas, Will Deacon,
Brian Norris, Russell King, Robin Murphy, Christoph Hellwig,
Florian Fainelli, Jonas Gorski, linux-pci,
bcm-kernel-feedback-list, Gregory Fong, Kevin Cernekee,
Mark Rutland, devicetree, linux-arm-kernel, linux-mips,
Ralf Baechle
In-Reply-To: <1510697532-32828-3-git-send-email-jim2101024@gmail.com>
On Tue, Nov 14, 2017 at 05:12:06PM -0500, Jim Quinlan wrote:
> The DT bindings description of the Brcmstb PCIe device is described. This
> node can be used by almost all Broadcom settop box chips, using
> ARM, ARM64, or MIPS CPU architectures.
>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> ---
> .../devicetree/bindings/pci/brcmstb-pcie.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcmstb-pcie.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [GIT PULL] DeviceTree updates for 4.15
From: Rob Herring @ 2017-11-16 5:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: Frank Rowand, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CA+55aFyPe=uWLF8gH5_bkPTbGbTP5h1Uq6XTUZA7oiNF8nd_SQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Nov 15, 2017 at 9:00 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> So these two warnings seems to be happening:
>
> drivers/of/unittest-data/testcases.dtb: Warning
> (interrupts_extended_property): Could not get phandle node for
> /__local_fixups__/testcase-data/interrupts/interrupts-extended0:interrupts-extended(cell
> 3)
>
> drivers/of/unittest-data/testcases.dtb: Warning
> (interrupts_property): interrupts size is (4), expected multiple of 8
> in /testcase-data/testcase-device2
>
> and honestly, warnings during "make allmodconfig" are not acceptable.
> Right now we have a few module license warnings that I hope are going
> to go away, but the devicetree one I didn't even notice when it
> appeared. I'm actually surprised, because I do a "make allmodconfig"
> in between all pulls, and I didn't notice it after doing the
> devicetree pull.
>
> Of course, that is probably just exactly because those module-license
> warnings have made me warning-blind, which is why warnings aren't
> acceptable.
>
> "It's a benign warning" is never true, exactly because a couple of
> benign warnings that people get used to then end up hiding all the
> _bad_ cases.
These cases are intentionally bad DT data to feed the testcase. We can
switch off the warning (at least I think the kbuild infrastructure is
there), but then the check is disabled for all the good cases too
which isn't great. We probably need to split the test data into good
and bad data dtbs, but that will take some restructuring of the tests.
> I have no idea how that dts test-case is _supposed_ to work, so I'll
> just write this plaintive email. Please fix it.
Okay, we'll come up with something.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: arm: actions: Add Sparky
From: Rob Herring @ 2017-11-16 4:40 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thomas Liau,
Jeff Chen, 张东风, 刘炜,
张天益, 梅利, Ioan B, Sudeep Kumar,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171114180114.26408-3-afaerber-l3A5Bk7waGM@public.gmane.org>
On Tue, Nov 14, 2017 at 07:01:13PM +0100, Andreas Färber wrote:
> Define a binding for Allo.com Sparky SBC.
>
> Cc: Ioan B. <ioan-HmMszb9TTf4@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/actions.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: Add vendor prefix for Allo.com
From: Rob Herring @ 2017-11-16 4:38 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thomas Liau,
Jeff Chen, 张东风, 刘炜,
张天益, 梅利, Ioan B, Sudeep Kumar,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171114180114.26408-2-afaerber-l3A5Bk7waGM@public.gmane.org>
On Tue, Nov 14, 2017 at 07:01:12PM +0100, Andreas Färber wrote:
> ALLO is a Canadian-Indian manufacturer of telecommunications hardware.
>
> Cc: Ioan B. <ioan-HmMszb9TTf4@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: display/ti: Add optional property to set memory bandwidth limit
From: Rob Herring @ 2017-11-16 4:37 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: tomi.valkeinen-l0cyMroinI0,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, airlied-cv59FeDIM0c,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, daniel-/w4YWyX8dFk
In-Reply-To: <20171114124755.14277-2-peter.ujfalusi-l0cyMroinI0@public.gmane.org>
On Tue, Nov 14, 2017 at 02:47:53PM +0200, Peter Ujfalusi wrote:
> max-memory-bandwidth can be used to specify the maximum bandwidth dispc
> can use when reading display data from main memory.
>
> In some SoC (am437x for example) we have memory bandwidth limitation
> which causes underflow in the display subsystem.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt | 5 +++++
> Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt | 4 ++++
> Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt | 4 ++++
> Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt | 4 ++++
> Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt | 4 ++++
> 5 files changed, 21 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: add document for rk3126-vop
From: Rob Herring @ 2017-11-16 4:36 UTC (permalink / raw)
To: Sandy Huang
Cc: Mark Yao, David Airlie, Mark Rutland, Heiko Stuebner,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1510658855-90223-1-git-send-email-hjc-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Tue, Nov 14, 2017 at 07:27:34PM +0800, Sandy Huang wrote:
> Signed-off-by: Sandy Huang <hjc-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 6/8] dt-bindings: power: Add Actions Semi S700 SPS
From: Rob Herring @ 2017-11-16 4:35 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thomas Liau,
Jeff Chen, 张东风, 刘炜,
张天益, 梅利,
support-om/0PrzuAKC1Z/+hSey0Gg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171113233427.5386-7-afaerber-l3A5Bk7waGM@public.gmane.org>
On Tue, Nov 14, 2017 at 12:34:25AM +0100, Andreas Färber wrote:
> Define power domains for Actions Semi S700 SoC Smart Power System (SPS).
>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> v2: New
>
> .../devicetree/bindings/power/actions,owl-sps.txt | 2 ++
> include/dt-bindings/power/owl-s700-powergate.h | 20 ++++++++++++++++++++
> 2 files changed, 22 insertions(+)
> create mode 100644 include/dt-bindings/power/owl-s700-powergate.h
>
> diff --git a/Documentation/devicetree/bindings/power/actions,owl-sps.txt b/Documentation/devicetree/bindings/power/actions,owl-sps.txt
> index 007b9a7ae723..78edd63641e8 100644
> --- a/Documentation/devicetree/bindings/power/actions,owl-sps.txt
> +++ b/Documentation/devicetree/bindings/power/actions,owl-sps.txt
> @@ -2,10 +2,12 @@ Actions Semi Owl Smart Power System (SPS)
>
> Required properties:
> - compatible : "actions,s500-sps" for S500
> + "actions,s700-sps" for S700
> - reg : Offset and length of the register set for the device.
> - #power-domain-cells : Must be 1.
> See macros in:
> include/dt-bindings/power/owl-s500-powergate.h for S500
> + include/dt-bindings/power/owl-s700-powergate.h for S700
>
>
> Example:
> diff --git a/include/dt-bindings/power/owl-s700-powergate.h b/include/dt-bindings/power/owl-s700-powergate.h
> new file mode 100644
> index 000000000000..4ded16bc074f
> --- /dev/null
> +++ b/include/dt-bindings/power/owl-s700-powergate.h
> @@ -0,0 +1,20 @@
> +/*
> + * Actions Semi S700 SPS
> + *
> + * Copyright (c) 2017 Andreas Färber
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
The decree now for SPDX tags is make this the first line using "//".
Otherwise,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox