* [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Maxime Ripard @ 2017-12-15 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215190140.d4df71b202b9803baa6a1e10@magewell.com>
Hi,
On Fri, Dec 15, 2017 at 07:01:40PM +0800, Yong wrote:
> Hi Maxime,
>
> On Fri, 15 Dec 2017 11:50:47 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi Yong,
> >
> > On Mon, Dec 04, 2017 at 05:45:11PM +0800, Yong wrote:
> > > I just noticed that you are using the second iteration?
> > > Have you received my third iteration?
> >
> > Sorry for the late reply, and for not coming back to you yet about
> > that test. No, this is still in your v2. I've definitely received your
> > v3, I just didn't have time to update to it yet.
> >
> > But don't worry, my mail was mostly to know if you had tested that
> > setup on your side to try to nail down the issue on my end, not really
> > a review or comment that would prevent your patch from going in.
>
> I mean,
> The v2 exactly has a bug which may cause the CSI writing frame to
> a wrong memory address.
Ah, sorry I misunderstood you then. I'll definitely test your v3..
> BTW, should I send a new version. I have made some improve sine v3.
.. or your v4 :)
Yes, please send a new version.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: rtc: add bindings for i.MX53 SRTC
From: Rob Herring @ 2017-12-15 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3BB206AB2B1BD448954845CE6FF69A8E01CB53233C@NT-Mail07.beckhoff.com>
On Mon, Dec 11, 2017 at 1:08 AM, Patrick Br?nn <P.Bruenn@beckhoff.com> wrote:
>>From: Rob Herring [mailto:robh at kernel.org]
>>Sent: Mittwoch, 6. Dezember 2017 22:55
>>On Tue, Dec 05, 2017 at 03:06:42PM +0100, linux-kernel-dev at beckhoff.com
>>wrote:
>>> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>>>
>>> +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
>>> @@ -0,0 +1,17 @@
>>> +* i.MX53 Real Time Clock controller
>>> +
>>> +Required properties:
>>> +- compatible: should be: "fsl,imx53-rtc"
>>> +- reg: physical base address of the controller and length of memory
>>mapped
>>> + region.
>>> +- clocks: should contain the phandle for the rtc clock
>>
>>Shouldn't there be more than 1 here. From what I remember, the ipg clock
>>and the 32k clock?
> Yes, you are right. But if I am reading the original Freescale driver and the
> reference manual correctly, the second clock is always active.
> Section "72.3.1.1 Clocks" from the reference manual [1] reads:
> "SRTC runs on two clock sources, high frequency peripherals clock and low frequency
> timers clock. The high frequency peripheral IP clock is used by the SRTC peripheral bus
> interface, control and status registers. The low frequency 32.768 kHz clock is the
> always-active clock used by the SRTC timers..."
>
> That's why I would only include one clock . Should I change this?
Some chips supported 32.0kHz and 32.768kHz low freq clocks, so you'd
need to be able to query what the frequency is even if you don't need
to enable the clock, but maybe that may be gone in MX53. I don't
remember.
>>> +- interrupts: rtc alarm interrupt
>>> +
>>> +Example:
>>> +
>>> +srtc at 53fa4000 {
>>
>>rtc at ...
>>
> The rtc for which this series adds support is embedded within a function block called
> "Secure Real Time Clock". This driver doesn't utilize all of the hardware features by
> now. But maybe someone else wants to extend the functionalities, later.
> For that possibility I wanted to name the node "srtc". Should I still change this?
>
> I believe you have a much better understanding of what should be done here. I don't
> want to argue with you, just thought you might not had that information. So if I am
> wrong just tell me and I will change it without further "complaining".
Node names should be generic for the class of h/w they are. So yes, it
should be "rtc".
Rob
^ permalink raw reply
* [PATCH 1/3] dt-bindings: bcm2836-l1-intc: add interrupt polarity support
From: Eric Anholt @ 2017-12-15 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513024752-11246-2-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> This increases the interrupt cells for the 1st level interrupt controller
> binding in order to describe the polarity like on the other ARM platforms.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
I'm happy with this. Any DT maintainer concerns?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/46a79d48/attachment.sig>
^ permalink raw reply
* [PATCH 1/5] dt-bindings: pinctrl: Add st,stm32f769-pinctrl compatible to stm32-pinctrl
From: Rob Herring @ 2017-12-15 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512982475-32661-2-git-send-email-alexandre.torgue@st.com>
On Mon, Dec 11, 2017 at 09:54:31AM +0100, Alexandre Torgue wrote:
> Add new compatible for stm32f769 MCU.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2] arm: kirkwood: dts: Use lower case for bindings notation
From: Andrew Lunn @ 2017-12-15 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215170711.8212-1-malat@debian.org>
On Fri, Dec 15, 2017 at 06:07:11PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files using lower case to fix the following dtc warnings:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Thanks for fixing up the commit message.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net-next 1/2 v8] net: ethernet: Add DT bindings for the Gemini ethernet
From: Rob Herring @ 2017-12-15 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171210224558.27122-1-linus.walleij@linaro.org>
On Sun, Dec 10, 2017 at 11:45:57PM +0100, Linus Walleij wrote:
> This adds the device tree bindings for the Gemini ethernet
> controller. It is pretty straight-forward, using standard
> bindings and modelling the two child ports as child devices
> under the parent ethernet controller device.
>
> Cc: devicetree at vger.kernel.org
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Cc: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v7->v8:
> - Use ethernet-port at 0 and ethernet-port at 1 with unit names
> and following OF graph requirements.
> ---
> .../bindings/net/cortina,gemini-ethernet.txt | 92 ++++++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Fabio Estevam @ 2017-12-15 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215213403.GG7829@linux.vnet.ibm.com>
Hi Paul,
On Fri, Dec 15, 2017 at 7:34 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> That would be me being stupid. Please see below for an updated patch.
This one builds cleanly and works fine on my imx6q board. Thanks
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Paul E. McKenney @ 2017-12-15 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C2Mo4VQ2WNDqcXbsu=uP=3suAhPzXd3-LSwbir38A22g@mail.gmail.com>
On Fri, Dec 15, 2017 at 06:36:49PM -0200, Fabio Estevam wrote:
> Hi Paul,
>
> On Fri, Dec 15, 2017 at 4:23 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
>
> > How about this one, also untested etc.?
>
> This one gives a build warning:
>
> arch/arm/kernel/smp.c: In function ?__cpu_die?:
> arch/arm/kernel/smp.c:262:5: warning: ?ret? may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> if (!ret) {
> ^
That would be me being stupid. Please see below for an updated patch.
> but when I run suspend/resume I don't see the RCU warning with this
> patch applied.
So some progress, at least! Thank you for your testing efforts!!!
Thanx, Paul
------------------------------------------------------------------------
commit e1bb1ddc3402220eba1138322fedd520801ee510
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Dec 11 09:40:58 2017 -0800
ARM: CPU hotplug: Delegate complete() to surviving CPU
The ARM implementation of arch_cpu_idle_dead() invokes complete(), but
does so after RCU has stopped watching the outgoing CPU, which results
in lockdep complaints because complete() invokes functions containing RCU
readers. In addition, if the outgoing CPU really were to consume several
seconds of its five-second allotted time, multiple RCU updates could
complete, possibly giving the outgoing CPU an inconsistent view of the
scheduler data structures on which complete() relies.
This (untested, probably does not build) commit avoids this problem by
polling the outgoing CPU. The polling strategy in this prototype patch
is quite naive, with one jiffy between each poll and without any sort
of adaptive spin phase. The key point is that the polling CPU uses
atomic_dec_and_test(), which evicts the flag from the outgoing CPU's
cache. The outgoing CPU simply does an atomic_set() of the value 1 which
causes the next atomic_dec_and_test() to return true, and which also
minimizes opportunities for other data to get pulled into the outgoing
CPU's cache. This pulling of values from the outgoing CPU's cache is
important because the outgoing CPU might be unceremoniously powered off
before it has time to execute any code after the atomic_set().
Underflow is avoided because there can be at most 5,000 invocations of
atomic_dec_and_test() for a given offline operation, and the counter is
set back to zero each time.
Reported-by: Peng Fan <van.freenix@gmail.com>
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: <linux-arm-kernel@lists.infradead.org>
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4fbf00ee4ad..f9a4990689f3 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -241,7 +241,7 @@ int __cpu_disable(void)
return 0;
}
-static DECLARE_COMPLETION(cpu_died);
+static atomic_t cpu_died;
/*
* called on the thread which is asking for a CPU to be shutdown -
@@ -249,7 +249,17 @@ static DECLARE_COMPLETION(cpu_died);
*/
void __cpu_die(unsigned int cpu)
{
- if (!wait_for_completion_timeout(&cpu_died, msecs_to_jiffies(5000))) {
+ unsigned long deadline = jiffies + msecs_to_jiffies(5000);
+ char ret = 0;
+
+ while (time_before(jiffies, deadline)) {
+ ret = atomic_dec_and_test(&cpu_died);
+ if (ret)
+ break;
+ schedule_timeout_interruptible(1);
+ }
+ atomic_set(&cpu_died, 0);
+ if (!ret) {
pr_err("CPU%u: cpu didn't die\n", cpu);
return;
}
@@ -295,7 +305,7 @@ void arch_cpu_idle_dead(void)
* this returns, power and/or clocks can be removed at any point
* from this CPU and its cache by platform_cpu_kill().
*/
- complete(&cpu_died);
+ atomic_set(&cpu_died, 1);
/*
* Ensure that the cache lines associated with that completion are
^ permalink raw reply related
* [PATCH] of: build dbts with symbols when CONFIG_OF_OVERLAY is set
From: Frank Rowand @ 2017-12-15 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214151240.14555-1-a.heider@gmail.com>
On 12/14/17 07:12, Andre Heider wrote:
> The overlay feature requires the base dtb to be built with symbols, so
> lets build the dtbs with symbols when overlay support was explicitly
> enabled.
>
> With CONFIG_OF_ALL_DTBS on ARCH=arm the 989 dtb files grow about ~38% on
> average.
>
> Totals in bytes with the 3 biggest ones:
>
> Before:
> 90471 arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
> 90521 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
> 92639 arch/arm/boot/dts/dra7-evm.dtb
> 25731296 total
>
> After:
> 133203 arch/arm/boot/dts/am57xx-beagle-x15-revc.dtb
> 133237 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dtb
> 134545 arch/arm/boot/dts/dra7-evm.dtb
> 35464440 total
>
> Signed-off-by: Andre Heider <a.heider@gmail.com>
> ---
>
> Hi,
>
> while playing around with overlays I noticed that I needed to rebuilt
> my distro's device trees because they didn't come with symbols.
>
> Is that for a reason, maybe the not so minor increase in size?
Yes, size is the issue.
>
> Thanks,
> Andre
>
> drivers/of/unittest-data/Makefile | 7 -------
> scripts/Makefile.lib | 5 +++++
> 2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
> index 32389acfa616..b65061013512 100644
> --- a/drivers/of/unittest-data/Makefile
> +++ b/drivers/of/unittest-data/Makefile
> @@ -15,13 +15,6 @@ targets += overlay.dtb overlay.dtb.S
> targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S
> targets += overlay_bad_symbol.dtb overlay_bad_symbol.dtb.S
> targets += overlay_base.dtb overlay_base.dtb.S
> -
> -# enable creation of __symbols__ node
> -DTC_FLAGS_overlay := -@
> -DTC_FLAGS_overlay_bad_phandle := -@
> -DTC_FLAGS_overlay_bad_symbol := -@
> -DTC_FLAGS_overlay_base := -@
> -
> endif
>
> .PRECIOUS: \
No. The unittests require these to be set unconditionally.
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 1ca4dcd2d500..c7ba4aa8a07a 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -278,6 +278,11 @@ DTC_FLAGS += -Wnode_name_chars_strict \
> -Wproperty_name_chars_strict
> endif
>
> +ifeq ($(CONFIG_OF_OVERLAY),y)
> +# enable creation of __symbols__ node
> +DTC_FLAGS += -@
> +endif
> +
> DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
>
> # Generate an assembly file to wrap the output of the device tree compiler
>
Not needed. Instead set DTC_FLAGS in the make command. For example:
DTC_FLAGS=-@ make qcom-apq8074-dragonboard.dtb
There are a few architecture Makefiles that need to be fixed to not unconditionally
set DTC_FLAGS.
-Frank
^ permalink raw reply
* [PATCH 1/7] soc: mediatek: Add USB wakeup driver
From: Rob Herring @ 2017-12-15 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512809136-2779-2-git-send-email-chunfeng.yun@mediatek.com>
On Sat, Dec 09, 2017 at 04:45:30PM +0800, Chunfeng Yun wrote:
> This driver is used to support usb wakeup which is controlled by
> the glue layer between SSUSB and SPM. Usually the glue layer is put
> into a system controller, such as pericfg module, which is
> represented by a syscon node in DTS.
> Due to the glue layer may vary on different SoCs, it's useful to
> extract a separated driver to simplify usb controller drivers.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> drivers/soc/mediatek/Kconfig | 8 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-usb-wakeup.c | 519 ++++++++++++++++++++++++++
> include/dt-bindings/soc/mediatek,usb-wakeup.h | 15 +
This belongs in the binding patch and that should come first.
> include/linux/soc/mediatek/usb-wakeup.h | 88 +++++
> 5 files changed, 631 insertions(+)
> create mode 100644 drivers/soc/mediatek/mtk-usb-wakeup.c
> create mode 100644 include/dt-bindings/soc/mediatek,usb-wakeup.h
> create mode 100644 include/linux/soc/mediatek/usb-wakeup.h
> +++ b/drivers/soc/mediatek/mtk-usb-wakeup.c
> @@ -0,0 +1,519 @@
> +/*
> + * Copyright (c) 2017 MediaTek Inc.
> + * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0
This should be the first line of the file and use a // style comment.
[...]
> diff --git a/include/dt-bindings/soc/mediatek,usb-wakeup.h b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> new file mode 100644
> index 0000000..2461795
> --- /dev/null
> +++ b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (c) 2017 MediaTek Inc.
> + * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
> + *
> + * SPDX-License-Identifier: GPL-2.0
ditto. Except headers use /* */ comments...
^ permalink raw reply
* [PATCH 0/7] Add USB remote wakeup driver
From: Rob Herring @ 2017-12-15 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512809136-2779-1-git-send-email-chunfeng.yun@mediatek.com>
On Sat, Dec 09, 2017 at 04:45:29PM +0800, Chunfeng Yun wrote:
> These patches introduce the SSUSB and SPM glue layer driver which is
> used to support usb remote wakeup. Usually the glue layer is put into
> a system controller, such as PERICFG module.
> The old way to support usb wakeup is put into SSUSB controller drivers,
> including xhci-mtk driver and mtu3 driver, but there are some problems:
> 1. can't disdinguish the relation between glue layer and SSUSB IP
> when SoCs supports multi SSUSB IPs;
> 2. duplicated code for wakeup are put into both xhci-mtk and mtu3
> drivers;
> 3. the glue layer may vary on different SoCs with SSUSB IP, and will
> make SSUSB controller drivers complicated;
> In order to resolve these problems, it's useful to make the glue layer
> transparent by extracting a seperated driver, meanwhile to reduce the
> duplicated code and simplify SSUSB controller drivers.
Both the driver and binding look overly complicated to me when it looks
like you just have 2 versions of enable/disable functions which modify
a single register. The complexity may be justified if this was a common
binding and driver, but it is not.
You already have a phandle to the system controller. Can't you add cells
to it to handle any differences between instances? That and SoC specific
compatible strings should be enough to handle differences.
Rob
^ permalink raw reply
* WARNING: suspicious RCU usage
From: Fabio Estevam @ 2017-12-15 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215182340.GA30443@linux.vnet.ibm.com>
Hi Paul,
On Fri, Dec 15, 2017 at 4:23 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> How about this one, also untested etc.?
This one gives a build warning:
arch/arm/kernel/smp.c: In function ?__cpu_die?:
arch/arm/kernel/smp.c:262:5: warning: ?ret? may be used uninitialized
in this function [-Wmaybe-uninitialized]
if (!ret) {
^
but when I run suspend/resume I don't see the RCU warning with this
patch applied.
Thanks
^ permalink raw reply
* [PATCH 1/3] dt-bindings: gpu: mali-utgard: add rockchip,rk3328-mali compatible
From: Rob Herring @ 2017-12-15 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171209000738.32187-2-heiko@sntech.de>
On Sat, Dec 09, 2017 at 01:07:36AM +0100, Heiko Stuebner wrote:
> The rk3328 quad-core Cortex A53 uses a Mali-450MP2 with 2 PPs, so
> add a compatible for it.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 1 +
> 1 file changed, 1 insertion(+)
For the series,
Reviewed-by: Rob Herring <robh@kernel.org>
Though I don't think it's really necessary to enable the gpu per board
as it has no pinout. Default enabled would be better IMO.
Rob
^ permalink raw reply
* [PATCH v4 2/2] ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
From: Kevin Hilman @ 2017-12-15 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208015418.9632-3-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> From: Xingyu Chen <xingyu.chen@amlogic.com>
>
> Add new pinctrl DT info for the Amlogic's Meson-AXG SoC.
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 44 ++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index e7213eb53958..7b24f83ab4bf 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/gpio/meson-axg-gpio.h>
FYI: I dropped this line, since it's not used (yet) and it causes an
unncessary dependency on an external tree. It can be added back as soon
as there are users.
Kevin
^ permalink raw reply
* [PATCH] fix perl locale warnings in arch/arm/boot/
From: Pavel Machek @ 2017-12-15 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171127094620.GA18072@amd>
On Mon 2017-11-27 10:46:20, Pavel Machek wrote:
>
> Commit 429f7a062e3b5cf6fcf01eb00600cee5fe4d751f introduced perl into
> arch/arm/boot/compressed/Makefile, which unfortunately leads to locale
> warnings.
>
> Fix it by setting default locale.
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
RMK apparently can't be bothered to fix the stuff he broke. Can
someone take the patch? Arm-soc? Linus? Andrew?
Thanks,
Pavel
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index 45a6b9b..4656e98 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -118,7 +118,7 @@ asflags-y := -DZIMAGE
>
> # Supply kernel BSS size to the decompressor via a linker symbol.
> KBSS_SZ = $(shell $(CROSS_COMPILE)nm $(obj)/../../../../vmlinux | \
> - perl -e 'while (<>) { \
> + LC_ALL=C perl -e 'while (<>) { \
> $$bss_start=hex($$1) if /^([[:xdigit:]]+) B __bss_start$$/; \
> $$bss_end=hex($$1) if /^([[:xdigit:]]+) B __bss_stop$$/; \
> }; printf "%d\n", $$bss_end - $$bss_start;')
>
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/6fe8baf2/attachment.sig>
^ permalink raw reply
* [PATCH v3 3/8] PCI: brcmstb: Add Broadcom STB PCIe host controller driver
From: Bjorn Helgaas @ 2017-12-15 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANCKTBvFhHb57JdG01aiSypBAcUeLzY3Dhuh5xP-_F5k_NcAhA@mail.gmail.com>
On Fri, Dec 15, 2017 at 02:53:57PM -0500, Jim Quinlan wrote:
> On Thu, Dec 14, 2017 at 5:51 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, Dec 13, 2017 at 06:53:53PM -0500, Jim Quinlan wrote:
> >> On Tue, Dec 12, 2017 at 5:16 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> > On Tue, Nov 14, 2017 at 05:12:07PM -0500, Jim Quinlan wrote:
> >> >> This commit adds the basic Broadcom STB PCIe controller. Missing is
> >> >> the ability to process MSI and also handle dma-ranges for inbound
> >> >> memory accesses. These two functionalities are added in subsequent
> >> >> commits.
> >> >>
> >> >> The PCIe block contains an MDIO interface. This is a local interface
> >> >> only accessible by the PCIe controller. It cannot be used or shared
> >> >> by any other HW. As such, the small amount of code for this
> >> >> controller is included in this driver as there is little upside to put
> >> >> it elsewhere.
> >> ...
> >
> >> >> +static bool brcm_pcie_valid_device(struct brcm_pcie *pcie, struct pci_bus *bus,
> >> >> + int dev)
> >> >> +{
> >> >> + if (pci_is_root_bus(bus)) {
> >> >> + if (dev > 0)
> >> >> + return false;
> >> >> + } else {
> >> >> + /* If there is no link, then there is no device */
> >> >> + if (!brcm_pcie_link_up(pcie))
> >> >> + return false;
> >> >
> >> > This is racy, since the link can go down after you check but before
> >> > you do the config access. I assume your hardware can deal with a
> >> > config access that targets a link that is down?
> >>
> >> Yes, that can happen but there is really nothing that can be done if
> >> the link goes down in that vulnerability window. What do you suggest
> >> doing?
> >
> > Most hardware drops writes and returns ~0 on reads if the link is
> > down. I assume your hardware does something similar, and that should
> > be enough. You shouldn't have to check whether the link is up.
> Unfortunately our HW is quite unforgiving and effects a synchronous or
> asynchronous abort when doing a config access when the link or power
> has gone down on the EP. I will open a discussion with the PCIe HW
> folks regarding why our controller does not behave like "most
> hardware". Thanks, Jim
I mentioned in the other thread [1] that I think the best way to
handle this is to figure out how to deal with the abort cleanly.
Using a test like *_pcie_link_up() to try to avoid it is a 99%
solution that means we'll see rare failures that are very difficult to
reproduce and debug.
> > The hardware might report errors, e.g., via AER, if the link is down.
> > And we might not not handle those nicely. If we have issues there, we
> > should find out and fix them.
[1] https://lkml.kernel.org/r/20171214225821.GN30595 at bhelgaas-glaptop.roam.corp.google.com
^ permalink raw reply
* [PATCH v7 0/6] add clk controller driver for Meson-AXG SoC
From: Kevin Hilman @ 2017-12-15 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513245826.32163.7.camel@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote:
>> Qiufang Dai (3):
>> clk: meson-axg: add clocks dt-bindings required header
>> clk: meson-axg: add clock controller drivers
>> arm64: dts: meson-axg: add clock DT info for Meson AXG SoC
>>
>> Yixun Lan (3):
>> clk: meson: make the spinlock naming more specific
>> dt-bindings: clock: add compatible variant for the Meson-AXG
>> arm64: dts: meson-axg: switch uart_ao clock to CLK81
>>
>> .../bindings/clock/amlogic,gxbb-clkc.txt | 7 +-
>> arch/arm64/Kconfig.platforms | 1 +
>> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 +
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 19 +-
>> drivers/clk/meson/Kconfig | 8 +
>> drivers/clk/meson/Makefile | 1 +
>> drivers/clk/meson/axg.c | 936 +++++++++++++++++++++
>> drivers/clk/meson/axg.h | 126 +++
>> drivers/clk/meson/clkc.h | 2 +-
>> drivers/clk/meson/gxbb.c | 112 +--
>> drivers/clk/meson/meson8b.c | 24 +-
>> include/dt-bindings/clock/axg-clkc.h | 71 ++
>> 12 files changed, 1234 insertions(+), 75 deletions(-)
>> create mode 100644 drivers/clk/meson/axg.c
>> create mode 100644 drivers/clk/meson/axg.h
>> create mode 100644 include/dt-bindings/clock/axg-clkc.h
>
> Kevin,
>
> I took the first 4 patches through clk-meson. I left the last 2 for you.
>
> I have applied the DT bindings update separately.
> Let me know if you have dependency on these new bindings and need a tag.
Yes, I will need a tag on the headers since both the "switch uart_ao"
patch and a subsequent patch to add DT for SPICC are using new clock
IDs.
Thanks,
Kevin
^ permalink raw reply
* [PATCH v3 3/8] PCI: brcmstb: Add Broadcom STB PCIe host controller driver
From: Jim Quinlan @ 2017-12-15 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214225133.GM30595@bhelgaas-glaptop.roam.corp.google.com>
On Thu, Dec 14, 2017 at 5:51 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Dec 13, 2017 at 06:53:53PM -0500, Jim Quinlan wrote:
>> On Tue, Dec 12, 2017 at 5:16 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Tue, Nov 14, 2017 at 05:12:07PM -0500, Jim Quinlan wrote:
>> >> This commit adds the basic Broadcom STB PCIe controller. Missing is
>> >> the ability to process MSI and also handle dma-ranges for inbound
>> >> memory accesses. These two functionalities are added in subsequent
>> >> commits.
>> >>
>> >> The PCIe block contains an MDIO interface. This is a local interface
>> >> only accessible by the PCIe controller. It cannot be used or shared
>> >> by any other HW. As such, the small amount of code for this
>> >> controller is included in this driver as there is little upside to put
>> >> it elsewhere.
>> ...
>
>> >> +static bool brcm_pcie_valid_device(struct brcm_pcie *pcie, struct pci_bus *bus,
>> >> + int dev)
>> >> +{
>> >> + if (pci_is_root_bus(bus)) {
>> >> + if (dev > 0)
>> >> + return false;
>> >> + } else {
>> >> + /* If there is no link, then there is no device */
>> >> + if (!brcm_pcie_link_up(pcie))
>> >> + return false;
>> >
>> > This is racy, since the link can go down after you check but before
>> > you do the config access. I assume your hardware can deal with a
>> > config access that targets a link that is down?
>>
>> Yes, that can happen but there is really nothing that can be done if
>> the link goes down in that vulnerability window. What do you suggest
>> doing?
>
> Most hardware drops writes and returns ~0 on reads if the link is
> down. I assume your hardware does something similar, and that should
> be enough. You shouldn't have to check whether the link is up.
Unfortunately our HW is quite unforgiving and effects a synchronous or
asynchronous abort when doing a config access when the link or power
has gone down on the EP. I will open a discussion with the PCIe HW
folks regarding why our controller does not behave like "most
hardware". Thanks, Jim
>
> The hardware might report errors, e.g., via AER, if the link is down.
> And we might not not handle those nicely. If we have issues there, we
> should find out and fix them.
>
> I see that dwc, altera, rockchip, and xilinx all do check for link up
> there, too. I can't remember if they had a legitimate reason, or if I
> just missed it.
>
>> >> +static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
>> >> +{
>> >> + struct list_head *pos, *q;
>> >> + struct brcm_pcie *tmp;
>> >> +
>> >> + mutex_lock(&brcm_pcie_lock);
>> >> + list_for_each_safe(pos, q, &brcm_pcie) {
>> >> + tmp = list_entry(pos, struct brcm_pcie, list);
>> >> + if (tmp == pcie) {
>> >> + list_del(pos);
>> >> + if (list_empty(&brcm_pcie))
>> >> + num_memc = 0;
>> >> + break;
>> >> + }
>> >> + }
>> >> + mutex_unlock(&brcm_pcie_lock);
>> >
>> > I'm missing something. I don't see that num_memc is ever set to
>> > anything *other* than zero.
>> The num_memc is set and used in the dma commit. I will remove its
>> declaration from this commit.
>
> Thanks, that will make the patches much easier to read.
>
>> >> + pcie->id = of_get_pci_domain_nr(dn);
>> >
>> > Why do you call of_get_pci_domain_nr() directly? No other driver
>> > does.
>>
>> We use the domain as the controller number (id). We use the id to
>> identify and fix a HW bug that only affects the 2nd controller; see
>> the clause
>> " } else if (of_machine_is_compatible("brcm,bcm7278a0")) {".
>
> pci_register_host_bridge() already sets bus->domain_nr for every host
> bridge. That path calls of_get_pci_domain_nr() eventually. But I
> guess that's too late for your use case, because you have this:
>
> brcm_pcie_probe
> brcm_pcie_setup
> brcm_pcie_bridge_sw_init_set
> if (of_machine_is_compatible("brcm,bcm7278a0")) {
> offset = pcie->id ? ... <--- use
> pci_scan_root_bus_bridge
> pci_register_host_bridge
> bus->domain_nr = pci_bus_find_domain_nr <--- available
>
> I guess you haven't added a binding for brcm,bcm7278a0 yet?
>
> I'm not really sure that using the linux,pci-domain DT property is the
> best way to distinguish the two controllers. Maybe Rob has an
> opinion?
>
>> >> + if (pcie->id < 0)
>> >> + return pcie->id;
>
> Bjorn
^ permalink raw reply
* [PATCH v3] arm: imx: dts: Use lower case for bindings notation
From: Fabio Estevam @ 2017-12-15 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215191930.11410-1-malat@debian.org>
On Fri, Dec 15, 2017 at 5:19 PM, Mathieu Malaterre <malat@debian.org> wrote:
> Improve the DTS files using lower case to fix the following dtc warnings:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC
From: Kevin Hilman @ 2017-12-15 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215024739.106705-1-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add PWM DT info for the Amlogic's Meson-Axg SoC.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> ---
> Changes in v2 since [1]
> - drop clock DT info from soc.dtsi
Applied to v4.16/dt64,
Thanks,
Kevin
^ permalink raw reply
* [PATCH v3 1/8] SOC: brcmstb: add memory API
From: Jim Quinlan @ 2017-12-15 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215171440.GB32131@red-moon>
On Fri, Dec 15, 2017 at 12:14 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Tue, Dec 12, 2017 at 03:14:04PM -0600, Bjorn Helgaas wrote:
>> [+cc Lorenzo]
>>
>> On Tue, Dec 12, 2017 at 03:53:28PM -0500, Jim Quinlan wrote:
>> > On Tue, Dec 5, 2017 at 3:59 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > > On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote:
>> > >> From: Florian Fainelli <f.fainelli@gmail.com>
>> > >>
>> > >> This commit adds a memory API suitable for ascertaining the sizes of
>> > >> each of the N memory controllers in a Broadcom STB chip. Its first
>> > >> user will be the Broadcom STB PCIe root complex driver, which needs
>> > >> to know these sizes to properly set up DMA mappings for inbound
>> > >> regions.
>> > >>
>> > >> We cannot use memblock here or anything like what Linux provides
>> > >> because it collapses adjacent regions within a larger block, and here
>> > >> we actually need per-memory controller addresses and sizes, which is
>> > >> why we resort to manual DT parsing.
>> > >>
>> > >> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
>> > >> ---
>> > >> drivers/soc/bcm/brcmstb/Makefile | 2 +-
>> > >> drivers/soc/bcm/brcmstb/memory.c | 172 +++++++++++++++++++++++++++++++++++++++
>> > >> include/soc/brcmstb/memory_api.h | 25 ++++++
>> > >> 3 files changed, 198 insertions(+), 1 deletion(-)
>> > >> create mode 100644 drivers/soc/bcm/brcmstb/memory.c
>> > >> create mode 100644 include/soc/brcmstb/memory_api.h
>> > >>
>> > >> diff --git a/drivers/soc/bcm/brcmstb/Makefile b/drivers/soc/bcm/brcmstb/Makefile
>> > >> index 9120b27..4cea7b6 100644
>> > >> --- a/drivers/soc/bcm/brcmstb/Makefile
>> > >> +++ b/drivers/soc/bcm/brcmstb/Makefile
>> > >> @@ -1 +1 @@
>> > >> -obj-y += common.o biuctrl.o
>> > >> +obj-y += common.o biuctrl.o memory.o
>> > >> diff --git a/drivers/soc/bcm/brcmstb/memory.c b/drivers/soc/bcm/brcmstb/memory.c
>> > >> new file mode 100644
>> > >> index 0000000..eb647ad9
>> > >> --- /dev/null
>> > >> +++ b/drivers/soc/bcm/brcmstb/memory.c
>> > >
>> > > I sort of assume based on [1] that every new file should have an SPDX
>> > > identifier ("The Linux kernel requires the precise SPDX identifier in
>> > > all source files") and that the actual text of the GPL can be omitted.
>> > >
>> > > Only a few files in drivers/pci currently have an SPDX identifier. I
>> > > don't know if that's oversight or work-in-progress or what.
>> > >
>> > > [1] https://lkml.kernel.org/r/20171204212120.484179273 at linutronix.de
>> > >
>> >
>> > Bjorn, Did you get a chance to review the other commits of this
>> > submission (V3)? I would like any additional feedback before I send
>> > out a V4 with SPDX fixes. Thanks, JimQ
>>
>> Lorenzo is taking over drivers/pci/host/* and he'll no doubt have some
>> comments when he gets to this. I'll point out a few quick formatting
>> things in the meantime.
>
> I need some time to review the code but overall I am quite worried about
> patches 1 and 4 in particular, it is ok to have platform host bridge
> drivers but we can't rewrite a DMA layer for a specific host bridge, I
> really do not like that - it is just not manageable from a maintenance
> perspective for the mainline kernel.
>
> Lorenzo
Hi Lorenzo,
First I note that the file drivers/pci/host/vmd.c appears to do the
same thing -- rewrite a layer over the DMA ops. Secondly, there seems
to be no other way to accomplish what we need to do, especially that
will work with ARM, ARM64, and MIPs. Someone raised the same point
you did and suggested I involve ARM/ARM64 maintainers, so I expanded
my "--to" list to include Russell. I'm open to ideas. I've asked the
HW PCIe folks to redesign the controller to accommodate an
identity-map for inbound memory, but it will be a while if that
happens, if ever. --Jim
^ permalink raw reply
* [PATCH v4 0/2] dt: add pinctrl driver for Meson-AXG SoC
From: Kevin Hilman @ 2017-12-15 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208015418.9632-1-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> This is DT part patchset for adding pinctrl support for
> the Amlogic's Meson-AXG SoC.
>
> Changes since v3 at [3]
> -- rebase to khilman's v4.16/dt64 branch and re-send
> -- add Rob's Ack
>
> Changes since v2 at [2]:
> -- Resend this patch series due to fail to send patch [2/2]
>
> Changes since v1 at [1]:
> -- Separate DT part patches
> -- Add Neil Armstrong's Ack
>
> [3]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005392.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005393.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005394.html
>
> [2]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005390.html
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005270.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005271.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005272.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005273.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005274.html
>
> Xingyu Chen (2):
> documentation: Add compatibles for Amlogic Meson AXG pin controllers
> ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
Applied both to v4.14/dt64
Normally, the documentation patch should go with the driver, but since
Linus has already merged the driver, this time I'll take it with the DT
itself.
Kevin
^ permalink raw reply
* [Question ]: Avoid kernel panic when killing an application if happen RAS page table error
From: Matthew Wilcox @ 2017-12-15 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A3419F3.1030804@arm.com>
On Fri, Dec 15, 2017 at 06:52:35PM +0000, James Morse wrote:
> Leaking any memory that isn't marked as poisoned isn't a good idea.
>
> What you would need is a way to know from the struct_page that: this page is
> is page-table, and which struct_mm it belongs to. (If its the kernel's init_mm:
> panic()).
> Next you need a way to find all the other pages of page-table without walking
> them. With these three pieces of information you can free all the unaffected
> memory, with even more work you can probably regenerate the corrupted page.
>
> It's going to be complicated to do, I don't think its worth the effort.
We can find a bit in struct page that we guarantee will only be set if
this is allocated as a pagetable. Bit 1 of the third union is currently
available (compound_head is a pointer if bit 0 is set, so nothing is
using bit 1). We can put a pointer to the mm_struct in the same word.
Finding all the allocated pages will be the tricky bit. We could put a
list_head into struct page; perhaps in the same spot as page_deferred_list
for tail pages. Then we can link all the pagetables belonging to
this mm together and tear them all down if any of them get an error.
They'll repopulate on demand. It won't be quick or scalable, but when
the alternative is death, it looks relatively attractive.
^ permalink raw reply
* [PATCH v3 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board
From: Kevin Hilman @ 2017-12-15 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215021014.231308-3-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> This is tested in the S400 dev board which use a RTL8211F PHY,
> and the pins connect to the 'eth_rgmii_y_pins' group.
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 70eca1f8736a..b8c4f1913d28 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -20,3 +20,10 @@
> &uart_AO {
> status = "okay";
> };
> +
> +ðmac {
> + status = "okay";
> + phy-mode = "rgmii";
> + pinctrl-0 = <ð_rgmii_y_pins>;
> + pinctrl-names = "default";
> +};
Minor nit: we try to keep these sorted alphabetically. Can you move
this above the uart_A0 one?
Note: if PATCH 1/1 had applied cleanly, I would have fixed this up
myself and not required a respin.
Kevin
^ permalink raw reply
* [PATCH v3 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Kevin Hilman @ 2017-12-15 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215021014.231308-2-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> Add DT info for the stmmac ethernet MAC which found in
> the Amlogic's Meson-AXG SoC, also describe the ethernet
> pinctrl & clock information here.
>
> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
This patch does not apply, and dependencies are not described.
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index d356ce74ad89..94c4972222b7 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
>
> / {
> compatible = "amlogic,meson-axg";
> @@ -148,6 +149,19 @@
> #address-cells = <0>;
> };
>
> + ethmac: ethernet at ff3f0000 {
> + compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
> + reg = <0x0 0xff3f0000 0x0 0x10000
> + 0x0 0xff634540 0x0 0x8>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "macirq";
> + clocks = <&clkc CLKID_ETH>,
> + <&clkc CLKID_FCLK_DIV2>,
> + <&clkc CLKID_MPLL2>;
> + clock-names = "stmmaceth", "clkin0", "clkin1";
> + status = "disabled";
> + };
> +
> hiubus: bus at ff63c000 {
> compatible = "simple-bus";
> reg = <0x0 0xff63c000 0x0 0x1c00>;
Based on the hiubus node, presumably this depends on the patch from the
clock series.
> @@ -194,6 +208,46 @@
> #gpio-cells = <2>;
> gpio-ranges = <&pinctrl_periphs 0 0 86>;
> };
I'm not sure where this part is coming from, but it causes the rest of
it to not apply.
Please be sure to describe all dependencies.
Kevin
> +
> + eth_rgmii_x_pins: eth-x-rgmii {
> + mux {
> + groups = "eth_mdio_x",
> + "eth_mdc_x",
> + "eth_rgmii_rx_clk_x",
> + "eth_rx_dv_x",
> + "eth_rxd0_x",
> + "eth_rxd1_x",
> + "eth_rxd2_rgmii",
> + "eth_rxd3_rgmii",
> + "eth_rgmii_tx_clk",
> + "eth_txen_x",
> + "eth_txd0_x",
> + "eth_txd1_x",
> + "eth_txd2_rgmii",
> + "eth_txd3_rgmii";
> + function = "eth";
> + };
> + };
> +
> + eth_rgmii_y_pins: eth-y-rgmii {
> + mux {
> + groups = "eth_mdio_y",
> + "eth_mdc_y",
> + "eth_rgmii_rx_clk_y",
> + "eth_rx_dv_y",
> + "eth_rxd0_y",
> + "eth_rxd1_y",
> + "eth_rxd2_rgmii",
> + "eth_rxd3_rgmii",
> + "eth_rgmii_tx_clk",
> + "eth_txen_y",
> + "eth_txd0_y",
> + "eth_txd1_y",
> + "eth_txd2_rgmii",
> + "eth_txd3_rgmii";
> + function = "eth";
> + };
> + };
> };
> };
^ 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