* Re: [PATCH 1/2] dt-bindings: rtc: new binding for Amlogic VRTC
From: Rob Herring @ 2019-07-09 2:07 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-rtc, Alexandre Belloni, linux-amlogic, linux-arm-kernel,
linux-kernel, devicetree, Kevin Hilman
In-Reply-To: <20190607194343.18359-1-khilman@kernel.org>
On Fri, 7 Jun 2019 12:43:42 -0700, Kevin Hilman wrote:
> From: Kevin Hilman <khilman@baylibre.com>
>
> Add binding fo the new VRTC driver for Amlogic SoCs. The 64-bit
> family of SoCs only has an RTC managed by firmware, and this VRTC
> driver provides the simple, one-register firmware interface.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> .../devicetree/bindings/rtc/rtc-meson-vrtc.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-meson-vrtc.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: Remove unused compatible strings
From: Rob Herring @ 2019-07-09 2:04 UTC (permalink / raw)
To: Paul Cercueil
Cc: Thierry Reding, Mark Rutland, od, linux-pwm, devicetree,
linux-kernel
In-Reply-To: <20190607154410.10633-2-paul@crapouillou.net>
On Fri, Jun 07, 2019 at 05:44:05PM +0200, Paul Cercueil wrote:
> Right now none of the Ingenic-based boards probe this driver from
> devicetree. This driver defined three compatible strings for the exact
> same behaviour. Before these strings are used, we can remove two of
> them.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
>
> Notes:
> v2: Rebase on v5.2-rc3
>
> Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt b/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
> index 7d9d3f90641b..493bec80d59b 100644
> --- a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
> @@ -2,10 +2,7 @@ Ingenic JZ47xx PWM Controller
> =============================
>
> Required properties:
> -- compatible: One of:
> - * "ingenic,jz4740-pwm"
> - * "ingenic,jz4770-pwm"
> - * "ingenic,jz4780-pwm"
> +- compatible: Should be "ingenic,jz4740-pwm"
Are you sure all 3 chips are exactly the same features and bugs?
The correct thing to do here generally is the 4770 and 4780 would also
have ingenic,jz4740-pwm as a fallback compatible. Then the driver can
match on that until you find some difference and can use the more
specific compatible.
> - #pwm-cells: Should be 3. See pwm.txt in this directory for a description
> of the cells format.
> - clocks : phandle to the external clock.
> --
> 2.21.0.593.g511ec345e18
>
^ permalink raw reply
* Re: [PATCH v3 5/5] dt-bindings: drm/panel: simple: add sharp,lq070y3dg3b panel
From: Rob Herring @ 2019-07-09 1:58 UTC (permalink / raw)
Cc: Mark Rutland, devicetree, letux-kernel, David Airlie,
marek.belisko, linux-kernel, dri-devel, tomi.valkeinen,
Thierry Reding, H. Nikolaus Schaller, linux-omap
In-Reply-To: <ee90ed56d2c294ce8ac3b44bf2229c5ab9f85e91.1559905870.git.hns@goldelico.com>
On Fri, 7 Jun 2019 13:11:11 +0200, "H. Nikolaus Schaller" wrote:
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> .../bindings/display/panel/sharp,lq070y3dg3b.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq070y3dg3b.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 4/5] dt-bindings: drm/panel: simple: add ortustech,com37h3m99dtc panel
From: Rob Herring @ 2019-07-09 1:58 UTC (permalink / raw)
Cc: Thierry Reding, David Airlie, Daniel Vetter, tomi.valkeinen,
imirkin, marek.belisko, Mark Rutland, dri-devel, linux-kernel,
linux-omap, letux-kernel, devicetree, H. Nikolaus Schaller
In-Reply-To: <3e0720fbddfd7b35ad8551440544411485d8ad9f.1559905870.git.hns@goldelico.com>
On Fri, 7 Jun 2019 13:11:10 +0200, "H. Nikolaus Schaller" wrote:
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> .../display/panel/ortustech,com37h3m99dtc.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ortustech,com37h3m99dtc.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/5] dt-bindings: drm/panel: simple: add ortustech,com37h3m05dtc panel
From: Rob Herring @ 2019-07-09 1:57 UTC (permalink / raw)
Cc: Thierry Reding, David Airlie, Daniel Vetter, tomi.valkeinen,
imirkin, marek.belisko, Mark Rutland, dri-devel, linux-kernel,
linux-omap, letux-kernel, devicetree, H. Nikolaus Schaller
In-Reply-To: <a650cb8df1bdf58ec3c8a182532692db16b77f70.1559905870.git.hns@goldelico.com>
On Fri, 7 Jun 2019 13:11:09 +0200, "H. Nikolaus Schaller" wrote:
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> .../display/panel/ortustech,com37h3m05dtc.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ortustech,com37h3m05dtc.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] clk: qcom: gcc: Add global clock controller driver for SM8150
From: Rob Herring @ 2019-07-09 1:56 UTC (permalink / raw)
To: Vinod Koul
Cc: Stephen Boyd, linux-arm-msm, Bjorn Andersson, Deepak Katragadda,
Andy Gross, David Brown, Michael Turquette, Mark Rutland,
linux-clk, devicetree, Taniya Das
In-Reply-To: <20190607101234.30449-2-vkoul@kernel.org>
On Fri, Jun 07, 2019 at 03:42:34PM +0530, Vinod Koul wrote:
> From: Deepak Katragadda <dkatraga@codeaurora.org>
>
> Add the clocks supported in global clock controller which clock the
> peripherals like BLSPs, SDCC, USB, MDSS etc. Register all the clocks
> to the clock framework for the clients to be able to request for them.
>
> Signed-off-by: Deepak Katragadda <dkatraga@codeaurora.org>
> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> [vkoul: port to upstream and tidy-up]
> Signed-off-by: Vinod Koul <vkoul@kernel.org>
> ---
> .../devicetree/bindings/clock/qcom,gcc.txt | 1 +
> drivers/clk/qcom/Kconfig | 7 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gcc-sm8150.c | 3649 +++++++++++++++++
> include/dt-bindings/clock/qcom,gcc-sm8150.h | 243 ++
Next time, please split bindings to separate patch.
For the DT parts,
Acked-by: Rob Herring <robh@kernel.org>
> 5 files changed, 3901 insertions(+)
> create mode 100644 drivers/clk/qcom/gcc-sm8150.c
> create mode 100644 include/dt-bindings/clock/qcom,gcc-sm8150.h
^ permalink raw reply
* Re: [PATCH v2 3/3] media: dt-bindings: imx7-csi: add i.MX6UL/L support
From: Rob Herring @ 2019-07-09 1:52 UTC (permalink / raw)
Cc: devel, linux-kernel, linux-arm-kernel, devicetree, linux-media,
Shawn Guo, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Philipp Zabel, Steve Longerbeam, NXP Linux Team, Fabio Estevam,
Pengutronix Kernel Team, Sascha Hauer, Mark Rutland,
Rui Miguel Silva, Sébastien Szymanski
In-Reply-To: <20190606153825.8183-3-sebastien.szymanski@armadeus.com>
On Thu, 6 Jun 2019 17:38:25 +0200, =?UTF-8?q?S=C3=A9bastien=20Szymanski?= wrote:
> Document "fsl,imx6ul-csi" entry.
>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
> ---
>
> Changes for v2:
> - New patch to document new "fsl,imx6ul-csi" entry.
>
> Documentation/devicetree/bindings/media/imx7-csi.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V2 2/2] dt-bindings: Document the DesignWare IP reset bindings
From: Rob Herring @ 2019-07-09 1:52 UTC (permalink / raw)
To: Luis Oliveira
Cc: p.zabel, mark.rutland, linux-kernel, devicetree, Joao.Pinto,
Gustavo Pimentel
In-Reply-To: <1559835388-2578-3-git-send-email-luis.oliveira@synopsys.com>
On Thu, Jun 06, 2019 at 05:36:28PM +0200, Luis Oliveira wrote:
> This adds documentation of device tree bindings for the
> DesignWare IP reset controller.
>
> Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
> Signed-off-by: Luis Oliveira <luis.oliveira@synopsys.com>
> ---
> Changelog
> - Add active low configuration example
> - Fix compatible string in the active high example
>
> .../devicetree/bindings/reset/snps,dw-reset.txt | 30 ++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> new file mode 100644
> index 0000000..85f3301
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> @@ -0,0 +1,30 @@
> +Synopsys DesignWare Reset controller
> +=======================================
> +
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +Required properties:
> +
> +- compatible: should be one of the following.
> + "snps,dw-high-reset" - for active high configuration
> + "snps,dw-low-reset" - for active low configuration
This is really a standalone block?
Are there versions of IP?
> +
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +
> +- #reset-cells: must be 1.
> +
> +example:
> +
> + dw_rst_1: reset-controller@0000 {
> + compatible = "snps,dw-high-reset";
> + reg = <0x0000 0x4>;
> + #reset-cells = <1>;
> + };
> +
> + dw_rst_2: reset-controller@1000 {i
> + compatible = "snps,dw-low-reset";
> + reg = <0x1000 0x8>;
> + #reset-cells = <1>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2 2/3] scsi: ufs: Allow resetting the UFS device
From: Rob Herring @ 2019-07-09 1:48 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Mark Rutland, Alim Akhtar, Avri Altman, Pedro Sousa,
James E.J. Bottomley, Martin K. Petersen, Andy Gross,
Linus Walleij, Evan Green, linux-arm-msm, linux-gpio, devicetree,
linux-kernel, linux-scsi
In-Reply-To: <20190606010249.3538-3-bjorn.andersson@linaro.org>
On Wed, Jun 05, 2019 at 06:02:48PM -0700, Bjorn Andersson wrote:
> Acquire the device-reset GPIO and toggle this to reset the UFS device
> during initialization and host reset.
>
> Based on downstream support implemented by Subhash Jadavani
> <subhashj@codeaurora.org>.
>
> Tested-by: John Stultz <john.stultz@linaro.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v1:
> - Added gpio to DT binding document
> - Fixed spelling of UFS
>
> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 2 +
> drivers/scsi/ufs/ufshcd.c | 44 +++++++++++++++++++
> drivers/scsi/ufs/ufshcd.h | 4 ++
> 3 files changed, 50 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> index a74720486ee2..d562d8b4919c 100644
> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
> @@ -54,6 +54,8 @@ Optional properties:
> PHY reset from the UFS controller.
> - resets : reset node register
> - reset-names : describe reset node register, the "rst" corresponds to reset the whole UFS IP.
> +- device-reset-gpios : A phandle and gpio specifier denoting the GPIO connected
> + to the RESET pin of the UFS memory device.
A sign we should have a child node for the device...
Doesn't using 'reset-gpios' work as I doubt one would have a GPIO reset
for the host controller.
Rob
^ permalink raw reply
* Re: [PATCH 3/6] clk: qcom: Add DT bindings for ipq6018 gcc clock controller
From: Rob Herring @ 2019-07-09 1:45 UTC (permalink / raw)
To: Sricharan R
Cc: robh+dt, sboyd, linus.walleij, agross, devicetree, linux-kernel,
linux-clk, linux-gpio, linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <1559755738-28643-4-git-send-email-sricharan@codeaurora.org>
On Wed, 5 Jun 2019 22:58:55 +0530, Sricharan R wrote:
> Add the compatible strings and the include file for ipq6018
> gcc clock controller.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> Signed-off-by: anusha <anusharao@codeaurora.org>
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
> .../devicetree/bindings/clock/qcom,gcc.txt | 1 +
> include/dt-bindings/clock/qcom,gcc-ipq6018.h | 405 +++++++++++++++++++++
> 2 files changed, 406 insertions(+)
> create mode 100644 include/dt-bindings/clock/qcom,gcc-ipq6018.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/6] pinctrl: qcom: Add ipq6018 pinctrl driver
From: Rob Herring @ 2019-07-09 1:44 UTC (permalink / raw)
To: Sricharan R
Cc: sboyd, linus.walleij, agross, devicetree, linux-kernel, linux-clk,
linux-gpio, linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <1559755738-28643-2-git-send-email-sricharan@codeaurora.org>
On Wed, Jun 05, 2019 at 10:58:53PM +0530, Sricharan R wrote:
> Add initial pinctrl driver to support pin configuration with
> pinctrl framework for ipq6018.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> Signed-off-by: Rajkumar Ayyasamy <arajkuma@codeaurora.org>
> Signed-off-by: speriaka <speriaka@codeaurora.org>
> ---
> .../bindings/pinctrl/qcom,ipq6018-pinctrl.txt | 186 +++
Please split bindings to separate patch. Using DT schema would be nice.
> drivers/pinctrl/qcom/Kconfig | 10 +
> drivers/pinctrl/qcom/Makefile | 1 +
> drivers/pinctrl/qcom/pinctrl-ipq6018.c | 1183 ++++++++++++++++++++
> 4 files changed, 1380 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.txt
> create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq6018.c
^ permalink raw reply
* Re: [PATCH 5.2 v2 2/2] dt-binding: edac: add NPCM ECC documentation
From: Rob Herring @ 2019-07-09 1:40 UTC (permalink / raw)
To: George Hung
Cc: linux-edac, linux-kernel, benjaminfair, wak, Avi.Fishman,
tomer.maimon, openbmc, Joel Stanley, Tali Perry, Patrick Venture,
Nancy Yuen, Mark Rutland, Borislav Petkov, Mauro Carvalho Chehab,
James Morse, davem, Greg Kroah-Hartman, Nicolas Ferre, paulmck,
devicetree, Linus Walleij, Jonathan Cameron
In-Reply-To: <20190605141253.38554-2-ghung.quanta@gmail.com>
On Wed, Jun 05, 2019 at 10:12:53PM +0800, George Hung wrote:
> Add device tree documentation for Nuvoton BMC ECC
>
> Signed-off-by: George Hung <ghung.quanta@gmail.com>
> ---
> .../bindings/edac/npcm7xx-sdram-edac.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
>
> diff --git a/Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt b/Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
> new file mode 100644
> index 000000000000..dd4dac59a5bd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/npcm7xx-sdram-edac.txt
> @@ -0,0 +1,17 @@
> +Nuvoton NPCM7xx SoC EDAC device driver
> +
> +The Nuvoton NPCM7xx SoC supports DDR4 memory with/without ECC and the driver
> +uses the EDAC framework to implement the ECC detection and corrtection.
> +
> +Required properties:
> +- compatible: should be "nuvoton,npcm7xx-sdram-edac"
Is this for the whole SDRAM controller or just ECC related registers?
In the former case, the naming should just reflect the block name and
not a Linux term.
> +- reg: Memory controller register set should be <0xf0824000 0x1000>
> +- interrupts: should be MC interrupt #25
> +
> +Example:
> +
> + mc: memory-controller@f0824000 {
> + compatible = "nuvoton,npcm7xx-sdram-edac";
> + reg = <0xf0824000 0x1000>;
> + interrupts = <0 25 4>;
> + };
> --
> 2.21.0
>
^ permalink raw reply
* RE: [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC mailbox
From: Peng Fan @ 2019-07-09 1:40 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, jassisinghbrar@gmail.com,
sudeep.holla@arm.com, f.fainelli@gmail.com, kernel@pengutronix.de,
dl-linux-imx, shawnguo@kernel.org, festevam@gmail.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com,
van.freenix@gmail.com
In-Reply-To: <20190708221947.GA13552@bogus>
Hi Rob,
> Subject: Re: [PATCH V2 1/2] DT: mailbox: add binding doc for the ARM SMC
> mailbox
>
> On Mon, Jun 03, 2019 at 04:30:04PM +0800, peng.fan@nxp.com wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The ARM SMC mailbox binding describes a firmware interface to trigger
> > actions in software layers running in the EL2 or EL3 exception levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> >
> > V2:
> > Introduce interrupts as a property.
> >
> > V1:
> > arm,func-ids is still kept as an optional property, because there is
> > no defined SMC funciton id passed from SCMI. So in my test, I still
> > use arm,func-ids for ARM SIP service.
> >
> > .../devicetree/bindings/mailbox/arm-smc.txt | 101
> +++++++++++++++++++++
> > 1 file changed, 101 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mailbox/arm-smc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> > b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> > new file mode 100644
> > index 000000000000..401887118c09
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
> > @@ -0,0 +1,101 @@
> > +ARM SMC Mailbox Interface
> > +=========================
> > +
> > +This mailbox uses the ARM smc (secure monitor call) instruction to
> > +trigger a mailbox-connected activity in firmware, executing on the
> > +very same core as the caller. By nature this operation is synchronous
> > +and this mailbox provides no way for asynchronous messages to be
> > +delivered the other way round, from firmware to the OS, but
> > +asynchronous notification could also be supported. However the value
> > +of r0/w0/x0 the firmware returns after the smc call is delivered as a
> > +received message to the mailbox framework, so a synchronous
> > +communication can be established, for a asynchronous notification, no
> > +value will be returned. The exact meaning of both the action the
> > +mailbox triggers as well as the return value is defined by their users and is
> not subject to this binding.
> > +
> > +One use case of this mailbox is the SCMI interface, which uses shared
> > +memory to transfer commands and parameters, and a mailbox to trigger
> > +a function call. This allows SoCs without a separate management
> > +processor (or when such a processor is not available or used) to use
> > +this standardized interface anyway.
> > +
> > +This binding describes no hardware, but establishes a firmware interface.
> > +Upon receiving an SMC using one of the described SMC function
> > +identifiers, the firmware is expected to trigger some mailbox connected
> functionality.
> > +The communication follows the ARM SMC calling convention[1].
> > +Firmware expects an SMC function identifier in r0 or w0. The
> > +supported identifiers are passed from consumers, or listed in the the
> > +arm,func-ids properties as described below. The firmware can return
> > +one value in the first SMC result register, it is expected to be an
> > +error value, which shall be propagated to the mailbox client.
> > +
> > +Any core which supports the SMC or HVC instruction can be used, as
> > +long as a firmware component running in EL3 or EL2 is handling these calls.
> > +
> > +Mailbox Device Node:
> > +====================
> > +
> > +This node is expected to be a child of the /firmware node.
> > +
> > +Required properties:
> > +--------------------
> > +- compatible: Shall be "arm,smc-mbox"
> > +- #mbox-cells Shall be 1 - the index of the channel needed.
> > +- arm,num-chans The number of channels supported.
> > +- method: A string, either:
> > + "hvc": if the driver shall use an HVC call, or
> > + "smc": if the driver shall use an SMC call.
> > +
> > +Optional properties:
> > +- arm,func-ids An array of 32-bit values specifying the function
> > + IDs used by each mailbox channel. Those function IDs
> > + follow the ARM SMC calling convention standard [1].
> > + There is one identifier per channel and the number
> > + of supported channels is determined by the length
> > + of this array.
> > +- interrupts SPI interrupts may be listed for notification,
> > + each channel should use a dedicated interrupt
> > + line.
> > +
> > +Example:
> > +--------
> > +
> > + sram@910000 {
> > + compatible = "mmio-sram";
> > + reg = <0x0 0x93f000 0x0 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x0 0x93f000 0x1000>;
> > +
> > + cpu_scp_lpri: scp-shmem@0 {
> > + compatible = "arm,scmi-shmem";
> > + reg = <0x0 0x200>;
> > + };
> > +
> > + cpu_scp_hpri: scp-shmem@200 {
> > + compatible = "arm,scmi-shmem";
> > + reg = <0x200 0x200>;
> > + };
> > + };
> > +
> > + smc_mbox: mailbox {
>
> This should be a child of 'firmware' node at least and really a child of the
> firmware component that implements the feature.
I checked other mbox driver, including the mbox used by ti sci, mbox used by
i.MX8QXP. both mbox dts node not a child a firmware node,
I am not sure why put mbox node into a child a firmware node here.
Thanks,
Peng.
>
> > + #mbox-cells = <1>;
> > + compatible = "arm,smc-mbox";
> > + method = "smc";
> > + arm,num-chans = <0x2>;
> > + /* Optional */
> > + arm,func-ids = <0xc20000fe>, <0xc20000ff>;
> > + };
> > +
> > + firmware {
> > + scmi {
> > + compatible = "arm,scmi";
> > + mboxes = <&mailbox 0 &mailbox 1>;
> > + mbox-names = "tx", "rx";
> > + shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
> > + };
> > + };
> > +
> > +
> > +[1]
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Finfo
> >
> +center.arm.com%2Fhelp%2Findex.jsp%3Ftopic%3D%2Fcom.arm.doc.den002
> 8a%2
> >
> +Findex.html&data=02%7C01%7Cpeng.fan%40nxp.com%7Cd8cf8b81b4f
> b49be5
> >
> +97c08d703f26576%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7
> C63698221
> >
> +1931902513&sdata=RtHkNN07b%2FuzdJkiu0QujeJ6czrcwOwEI6Y6JW
> VpPkY%3D
> > +&reserved=0
> > --
> > 2.16.4
> >
^ permalink raw reply
* Re: [PATCH v3, 04/27] dt-bindings: mediatek: add dither description for mt8183 display
From: Rob Herring @ 2019-07-09 1:37 UTC (permalink / raw)
Cc: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger, David Airlie,
Daniel Vetter, Mark Rutland, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Yongqiang Niu
In-Reply-To: <1559734986-7379-5-git-send-email-yongqiang.niu@mediatek.com>
On Wed, 5 Jun 2019 19:42:43 +0800, <yongqiang.niu@mediatek.com> wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3, 03/27] dt-bindings: mediatek: add ccorr description for mt8183 display
From: Rob Herring @ 2019-07-09 1:37 UTC (permalink / raw)
Cc: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger, David Airlie,
Daniel Vetter, Mark Rutland, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Yongqiang Niu
In-Reply-To: <1559734986-7379-4-git-send-email-yongqiang.niu@mediatek.com>
On Wed, 5 Jun 2019 19:42:42 +0800, <yongqiang.niu@mediatek.com> wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3, 02/27] dt-bindings: mediatek: add ovl_2l description for mt8183 display
From: Rob Herring @ 2019-07-09 1:37 UTC (permalink / raw)
To: yongqiang.niu
Cc: CK Hu, Philipp Zabel, Matthias Brugger, David Airlie,
Daniel Vetter, Mark Rutland, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <1559734986-7379-3-git-send-email-yongqiang.niu@mediatek.com>
On Wed, Jun 05, 2019 at 07:42:41PM +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index 70770fe..2418c56 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -28,6 +28,7 @@ Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
> Required properties (all function blocks):
> - compatible: "mediatek,<chip>-disp-<function>", one of
> "mediatek,<chip>-disp-ovl" - overlay (4 layers, blending, csc)
> + "mediatek,<chip>-disp-ovl-2l" - overlay (2 layers, blending, csc)
Does a single chip have a mixture of this block doing 2 and 4 layers? If
not, the <chip> part implies 2 vs. 4 layers.
Rob
^ permalink raw reply
* Re: [PATCH 17/60] dt-bindings: Add legacy 'toppoly' vendor prefix
From: Rob Herring @ 2019-07-09 1:35 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mark Rutland, devicetree, Maxime Ripard, Sebastian Reichel,
dri-devel, Tomi Valkeinen, Sean Paul
In-Reply-To: <20190709010004.GD4819@pendragon.ideasonboard.com>
On Mon, Jul 8, 2019 at 7:00 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Rob,
>
> On Mon, Jul 08, 2019 at 01:00:35PM -0600, Rob Herring wrote:
> > On Sun, Jul 7, 2019 at 12:25 PM Laurent Pinchart wrote:
> > >
> > > The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor
> > > prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and
> > > document it as legacy.
> > >
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > ---
> > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > index 2514463f2c63..d78527eb8254 100644
> > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > @@ -867,6 +867,8 @@ patternProperties:
> > > description: Tecon Microprocessor Technologies, LLC.
> > > "^topeet,.*":
> > > description: Topeet
> > > + "^toppoly,.*":
> > > + description: TPO (legacy prefix, see 'tpo')
> >
> > Add 'deprecated: true' also. That's a new property in json-schema
> > draft8. It's not used for anything yet other than documentation.
>
> Thank you for the pointer.
>
> By the way this series conflicts with your patches that move all panel
> bindings to yaml. I'll rebase it on top if yours gets merged first.
I committed the series today, but I don't see what conflicts though.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC
From: Jiangfeng Xiao @ 2019-07-09 1:07 UTC (permalink / raw)
To: David Miller
Cc: yisen.zhuang, salil.mehta, dingtianhong, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, leeyou.li, xiekunxun,
jianping.liu, nixiaoming
In-Reply-To: <20190708.111833.1002341757593028886.davem@davemloft.net>
On 2019/7/9 2:18, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sun, 07 Jul 2019 22:18:05 -0700 (PDT)
>
>> From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
>> Date: Fri, 5 Jul 2019 14:10:03 +0800
>>
>>> HI13X1 changed the offsets and bitmaps for tx_desc
>>> registers in the same peripheral device on different
>>> models of the hip04_eth.
>>>
>>> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
>>
>> Applied.
>
> Actually I didn't apply this because I can't see that HI13X1_GMAC
> kconfig knob anywhere in the tree at all.
>
Thank you for your guidance, I made a mistake, for which I am
sincerely sorry for wasting your time.
I will submit the correct one again.
I will not make this low-level mistake again.
Thanks,
Jiangfeng Xiao
^ permalink raw reply
* Re: [PATCH 17/60] dt-bindings: Add legacy 'toppoly' vendor prefix
From: Laurent Pinchart @ 2019-07-09 1:00 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Maxime Ripard, Sebastian Reichel,
dri-devel, Tomi Valkeinen, Sean Paul
In-Reply-To: <CAL_JsqLJy=UCeQ_Ex7tFh2OjtitNFVjT4v=PDZSbseva+ZrGDQ@mail.gmail.com>
Hi Rob,
On Mon, Jul 08, 2019 at 01:00:35PM -0600, Rob Herring wrote:
> On Sun, Jul 7, 2019 at 12:25 PM Laurent Pinchart wrote:
> >
> > The 'toppoly' vendor prefix is in use and refers to TPO, whose DT vendor
> > prefix is already defined as 'tpo'. Add 'toppoly' as an alternative and
> > document it as legacy.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > index 2514463f2c63..d78527eb8254 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > @@ -867,6 +867,8 @@ patternProperties:
> > description: Tecon Microprocessor Technologies, LLC.
> > "^topeet,.*":
> > description: Topeet
> > + "^toppoly,.*":
> > + description: TPO (legacy prefix, see 'tpo')
>
> Add 'deprecated: true' also. That's a new property in json-schema
> draft8. It's not used for anything yet other than documentation.
Thank you for the pointer.
By the way this series conflicts with your patches that move all panel
bindings to yaml. I'll rebase it on top if yours gets merged first.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
From: Vasily Khoruzhick @ 2019-07-09 0:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Harald Geyer,
Thierry Reding, Thomas Gleixner, arm-linux, Icenowy Zheng
In-Reply-To: <20190701095842.fvganvycce2cy7jn@flea>
On Mon, Jul 1, 2019 at 2:58 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> > On 12.06.2019 17:20, Maxime Ripard wrote:
> > >> I am not sure if I understand whole discussion here, but I also do not
> > >> understand whole edp-connector thing.
> > > The context is this one:
> > > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> > > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> > >
> > > TL;DR: This bridge is being used on ARM laptops that can come with
> > > different eDP panels. Some of these panels require a regulator to be
> > > enabled for the panel to work, and this is obviously something that
> > > should be in the DT.
> > >
> > > However, we can't really describe the panel itself, since the vendor
> > > uses several of them and just relies on the eDP bus to do its job at
> > > retrieving the EDIDs. A generic panel isn't really working either
> > > since that would mean having a generic behaviour for all the panels
> > > connected to that bus, which isn't there either.
> > >
> > > The connector allows to expose this nicely.
> >
> > As VESA presentation says[1] eDP is based on DP but is much more
> > flexible, it is up to integrator (!!!) how the connection, power
> > up/down, initialization sequence should be performed. Trying to cover
> > every such case in edp-connector seems to me similar to panel-simple
> > attempt failure. Moreover there is no such thing as physical standard
> > eDP connector. Till now I though DT connector should describe physical
> > connector on the device, now I am lost, are there some DT bindings
> > guidelines about definition of a connector?
>
> This might be semantics but I guess we're in some kind of grey area?
>
> Like, for eDP, if it's soldered I guess we could say that there's no
> connector. But what happens if for some other board, that signal is
> routed through a ribbon?
>
> You could argue that there's no physical connector in both cases, or
> that there's one in both, or one for the ribbon and no connector for
> the one soldered in.
>
> > Maybe instead of edp-connector one would introduce integrator's specific
> > connector, for example with compatible "olimex,teres-edp-connector"
> > which should follow edp abstract connector rules? This will be at least
> > consistent with below presentation[1] - eDP requirements depends on
> > integrator. Then if olimex has standard way of dealing with panels
> > present in olimex/teres platforms the driver would then create
> > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > Anyway it still looks fishy for me :), maybe because I am not
> > familiarized with details of these platforms.
>
> That makes sense yes
Actually, it makes no sense at all. Current implementation for anx6345
driver works fine as is with any panel specified assuming panel delays
are long enough for connected panel. It just doesn't use panel timings
from the driver. Creating a platform driver for connector itself looks
redundant since it can't be reused, it doesn't describe actual
hardware and it's just defeats purpose of DT by introducing
board-specific code.
There's another issue: if we introduce edp-connector we'll have to
specify power up delays somewhere (in dts? or in platform driver?), so
edp-connector doesn't really solve the issue of multiple panels with
same motherboard.
I'd say DT overlays should be preferred solution here, not another
connector binding.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
From: Iurii Zaikin @ 2019-07-08 23:34 UTC (permalink / raw)
To: Brendan Higgins
Cc: Petr Mladek, open list:DOCUMENTATION, Peter Zijlstra,
Amir Goldstein, dri-devel, Sasha Levin, Masahiro Yamada,
Michael Ellerman, open list:KERNEL SELFTEST FRAMEWORK, shuah,
Rob Herring, linux-nvdimm, Frank Rowand, Knut Omang,
Kieran Bingham, wfg-VuQAYsv1563Yd54FQh9/CA, Joel Stanley,
David Rientjes, Jeff Dike, Dan Carpenter, devicetree,
linux-kbuild
In-Reply-To: <CAAXuY3q1==RvAiw+gw5kfFJmjdR9JEUnnxou4Sv0POd88aD41w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> On Mon, Jul 8, 2019 at 4:16 PM Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>>
>> CC'ing Iurii Zaikin
>>
>> On Fri, Jul 5, 2019 at 1:48 PM Luis Chamberlain <mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> >
>> > On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote:
>> > > Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section.
>> > >
>> > > Signed-off-by: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> > > Reviewed-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
>> > > Reviewed-by: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
>> > > Acked-by: Luis Chamberlain <mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> >
>> > Come to think of it, I'd welcome Iurii to be added as a maintainer,
>> > with the hope Iurii would be up to review only the kunit changes. Of
>> > course if Iurii would be up to also help review future proc changes,
>> > even better. 3 pair of eyeballs is better than 2 pairs.
>>
>> What do you think, Iurii?
I'm in.
^ permalink raw reply
* Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
From: Iurii Zaikin @ 2019-07-08 23:29 UTC (permalink / raw)
To: Brendan Higgins
Cc: Petr Mladek, open list:DOCUMENTATION, Peter Zijlstra,
Amir Goldstein, dri-devel, Sasha Levin, Masahiro Yamada,
Michael Ellerman, open list:KERNEL SELFTEST FRAMEWORK, shuah,
Rob Herring, linux-nvdimm, Frank Rowand, Knut Omang,
Kieran Bingham, wfg-VuQAYsv1563Yd54FQh9/CA, Joel Stanley,
David Rientjes, Jeff Dike, Dan Carpenter, devicetree,
linux-kbuild
In-Reply-To: <CAFd5g44j7ECQorYLnDQadAaj+yBki98kFjmjejn+3W4eHtqGDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
I'm in.
On Mon, Jul 8, 2019 at 4:16 PM Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
wrote:
> CC'ing Iurii Zaikin
>
> On Fri, Jul 5, 2019 at 1:48 PM Luis Chamberlain <mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >
> > On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote:
> > > Add entry for the new proc sysctl KUnit test to the PROC SYSCTL
> section.
> > >
> > > Signed-off-by: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > > Reviewed-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> > > Reviewed-by: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
> > > Acked-by: Luis Chamberlain <mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > Come to think of it, I'd welcome Iurii to be added as a maintainer,
> > with the hope Iurii would be up to review only the kunit changes. Of
> > course if Iurii would be up to also help review future proc changes,
> > even better. 3 pair of eyeballs is better than 2 pairs.
>
> What do you think, Iurii?
>
^ permalink raw reply
* Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
From: Brendan Higgins @ 2019-07-08 23:15 UTC (permalink / raw)
To: Luis Chamberlain, Iurii Zaikin
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Peter Zijlstra, Rob Herring, Stephen Boyd, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List,
"open list:KERNEL SELFTEST FRAMEWORK" <linux-ks>
In-Reply-To: <20190705204810.GE19023@42.do-not-panic.com>
CC'ing Iurii Zaikin
On Fri, Jul 5, 2019 at 1:48 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote:
> > Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> > Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>
> Come to think of it, I'd welcome Iurii to be added as a maintainer,
> with the hope Iurii would be up to review only the kunit changes. Of
> course if Iurii would be up to also help review future proc changes,
> even better. 3 pair of eyeballs is better than 2 pairs.
What do you think, Iurii?
^ permalink raw reply
* [PATCH v4 8/8] of/platform: Create device links for all child-supplier depencencies
From: Saravana Kannan @ 2019-07-08 22:56 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki,
Frank Rowand
Cc: Saravana Kannan, devicetree, linux-kernel, David Collins,
kernel-team
In-Reply-To: <20190708225624.119973-1-saravanak@google.com>
A parent device can have child devices that it adds when it probes. But
this probing of the parent device can happen way after kernel init is done
-- for example, when the parent device's driver is loaded as a module.
In such cases, if the child devices depend on a supplier in the system, we
need to make sure the supplier gets the sync_state() callback only after
these child devices are added and probed.
To achieve this, when creating device links for a device by looking at its
DT node, don't just look at DT references at the top node level. Look at DT
references in all the descendant nodes too and create device links from the
ancestor device to all these supplier devices.
This way, when the parent device probes and adds child devices, the child
devices can then create their own device links to the suppliers and further
delay the supplier's sync_state() callback to after the child devices are
probed.
Example:
In this illustration, -> denotes DT references and indentation
represents child status.
Device node A
Device node B -> D
Device node C -> B, D
Device node D
Assume all these devices have their drivers loaded as modules.
Without this patch, this is the sequence of events:
1. D is added.
2. A is added.
3. Device D probes.
4. Device D gets its sync_state() callback.
5. Device B and C might malfunction because their resources got
altered/turned off before they can make active requests for them.
With this patch, this is the sequence of events:
1. D is added.
2. A is added and creates device links to D.
3. Device link from A to B is not added because A is a parent of B.
4. Device D probes.
5. Device D does not get it's sync_state() callback because consumer A
hasn't probed yet.
5. Device A probes.
5. a. Devices B and C are added.
5. b. Device links from B and C to D are added.
5. c. Device A's probe completes.
6. Device D does not get it's sync_state() callback because consumer A
has probed but consumers B and C haven't probed yet.
7. Device B and C probe.
8. Device D gets it's sync_state() callback because all its consumers
have probed.
9. None of the devices malfunction.
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/of/platform.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 98414ba53b1f..85796a09464c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -525,16 +525,26 @@ bool of_link_is_valid(struct device_node *con, struct device_node *sup)
return true;
}
-static int of_link_binding(struct device *dev,
+static int of_link_binding(struct device *dev, struct device_node *con_np,
const char *binding, const char *cell)
{
struct of_phandle_args sup_args;
+ struct device_node *child;
struct platform_device *sup_dev;
unsigned int i = 0, links = 0;
u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
+ bool done = true;
- while (!of_parse_phandle_with_args(dev->of_node, binding, cell, i,
+ while (!of_parse_phandle_with_args(con_np, binding, cell, i,
&sup_args)) {
+ /*
+ * This check needs to be done against dev->of_node (and not
+ * con_np) due to the recursive calls for the child DT nodes.
+ * Since all the device links for the child DT nodes are also
+ * created against the parent device, we need to check for
+ * validity against the parent DT node and not just the child
+ * DT nodes.
+ */
if (!of_link_is_valid(dev->of_node, sup_args.np)) {
of_node_put(sup_args.np);
continue;
@@ -548,7 +558,12 @@ static int of_link_binding(struct device *dev,
links++;
put_device(&sup_dev->dev);
}
- if (links < i)
+
+ for_each_child_of_node(con_np, child)
+ if (of_link_binding(dev, child, binding, cell))
+ done = false;
+
+ if (links < i || !done)
return -ENODEV;
return 0;
}
@@ -576,7 +591,8 @@ static int of_link_to_suppliers(struct device *dev)
return 0;
for (i = 0; i < ARRAY_SIZE(link_bindings) / 2; i++)
- if (of_link_binding(dev, link_bindings[i * 2],
+ if (of_link_binding(dev, dev->of_node,
+ link_bindings[i * 2],
link_bindings[i * 2 + 1]))
done = false;
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v4 7/8] of/platform: Sanity check DT bindings before creating device links
From: Saravana Kannan @ 2019-07-08 22:56 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki,
Frank Rowand
Cc: Saravana Kannan, devicetree, linux-kernel, David Collins,
kernel-team
In-Reply-To: <20190708225624.119973-1-saravanak@google.com>
If a common DT binding is pointing to a child DT node of a particular
parent DT node, don't add device links for such DT references. This is
because, by definition, a child node can't be a functional dependency for
the parent node.
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/of/platform.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index dba962a0ee50..98414ba53b1f 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -512,6 +512,19 @@ int of_platform_default_populate(struct device_node *root,
}
EXPORT_SYMBOL_GPL(of_platform_default_populate);
+bool of_link_is_valid(struct device_node *con, struct device_node *sup)
+{
+ of_node_get(sup);
+ while (sup) {
+ if (sup == con) {
+ of_node_put(sup);
+ return false;
+ }
+ sup = of_get_next_parent(sup);
+ }
+ return true;
+}
+
static int of_link_binding(struct device *dev,
const char *binding, const char *cell)
{
@@ -522,6 +535,10 @@ static int of_link_binding(struct device *dev,
while (!of_parse_phandle_with_args(dev->of_node, binding, cell, i,
&sup_args)) {
+ if (!of_link_is_valid(dev->of_node, sup_args.np)) {
+ of_node_put(sup_args.np);
+ continue;
+ }
i++;
sup_dev = of_find_device_by_node(sup_args.np);
of_node_put(sup_args.np);
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
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