Hi Linus,
Please merge. Thanks!
-Olof
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes
for you to fetch changes up to a89f84a56ec95fd66b839bf9c545f8a59a4ffcd5:
Merge tag 'stratix10_dts_fix_for_v4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into fixes (2018-11-07 08:09:50 -0800)
----------------------------------------------------------------
ARM: SoC fixes
A few more fixes that have come in, and one revert of a previous fix.
I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
and it ended up regressing at least BeagleBone XM boards. While we get
that debugged for next merge window, let's disable it again.
Beyond that:
- Stratix change to fix multicast filtering
- Minor DT fixes for Renesas and i.MX
- Ethernet fix for a Renesas board (switching main interfaces)
- Ethernet phy regulator fix for i.MX6SX
----------------------------------------------------------------
Aaro Koskinen (1):
arm64: dts: stratix10: fix multicast filtering
Fabrizio Castro (1):
dt-bindings: arm: Fix RZ/G2E part number
Kuninori Morimoto (1):
arm64: dts: renesas: r8a7795: add missing dma-names on hscif2
Leonard Crestez (1):
ARM: dts: imx6sx-sdb: Fix enet phy regulator
Oleksij Rempel (1):
ARM: dts: imx6sll: fix typo for fsl,imx6sll-i2c node
Olof Johansson (4):
ARM: defconfig: Disable PREEMPT again on multi_v7
Merge tag 'imx-fixes-4.20' of git://git.kernel.org/.../shawnguo/linux into fixes
Merge tag 'renesas-fixes-for-v4.20' of https://git.kernel.org/.../horms/renesas into fixes
Merge tag 'stratix10_dts_fix_for_v4.20' of git://git.kernel.org/.../dinguyen/linux into fixes
Rob Herring (1):
ARM: dts: fsl: Fix improperly quoted stdout-path values
Sergei Shtylyov (1):
arm64: dts: renesas: condor: switch from EtherAVB to GEther
Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
arch/arm/boot/dts/imx53-ppd.dts | 2 +-
arch/arm/boot/dts/imx6sll.dtsi | 2 +-
arch/arm/boot/dts/imx6sx-sdb.dtsi | 7 +++-
arch/arm/boot/dts/vf610m4-colibri.dts | 4 +-
arch/arm/configs/multi_v7_defconfig | 1 -
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 3 ++
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 47 +++++++++++-----------
9 files changed, 39 insertions(+), 31 deletions(-)
On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson <[email protected]> wrote:
>
> ARM: SoC fixes
Pulled.
> I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> and it ended up regressing at least BeagleBone XM boards.
Odd. Did it hit some "may_sleep()" test in a driver that is hidden by
preempt being off? Otherwise I don't see how/why preempt should fail
in a board-specific manner..
Linus
On Wed, Nov 7, 2018 at 9:17 AM Linus Torvalds
<[email protected]> wrote:
>
> On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson <[email protected]> wrote:
> >
> > ARM: SoC fixes
>
> Pulled.
>
> > I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> > and it ended up regressing at least BeagleBone XM boards.
>
> Odd. Did it hit some "may_sleep()" test in a driver that is hidden by
> preempt being off? Otherwise I don't see how/why preempt should fail
> in a board-specific manner..
The board hangs early during boot and the usual way of collecting
early console doesn't seem to work when attempted (I haven't tried
personally).
It's one of the major non-SMP platforms covered by tests. I'd be
surprised if it turns out to be truly _board_ specific (and rather
specific to OMAP3), but we don't have enough data yet. Chances are it
either shuffles some timing around or indeed hits a may_sleep() test
somewhere.
(I just realized I might have missed to attribute Guillaume in the
revert patch. Sorry about that).
-Olof
-Olof
* Olof Johansson <[email protected]> [181107 09:28]:
> On Wed, Nov 7, 2018 at 9:17 AM Linus Torvalds
> <[email protected]> wrote:
> >
> > On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson <[email protected]> wrote:
> > >
> > > ARM: SoC fixes
> >
> > Pulled.
> >
> > > I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> > > and it ended up regressing at least BeagleBone XM boards.
> >
> > Odd. Did it hit some "may_sleep()" test in a driver that is hidden by
> > preempt being off? Otherwise I don't see how/why preempt should fail
> > in a board-specific manner..
>
> The board hangs early during boot and the usual way of collecting
> early console doesn't seem to work when attempted (I haven't tried
> personally).
>
> It's one of the major non-SMP platforms covered by tests. I'd be
> surprised if it turns out to be truly _board_ specific (and rather
> specific to OMAP3), but we don't have enough data yet. Chances are it
> either shuffles some timing around or indeed hits a may_sleep() test
> somewhere.
>
> (I just realized I might have missed to attribute Guillaume in the
> revert patch. Sorry about that).
Looks like we're missing the stdout-path for earlycon, maybe try
with the following patch? I can't find my Beagleboard-xm right now,
time to clean-up a bit I guess.
At least omap3-evm, logicpd-torpedo and n900 all boot with PREEMPT.
Regards,
Tony
8< ----------------------
From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <[email protected]>
Date: Thu, 8 Nov 2018 07:43:28 -0800
Subject: [PATCH] ARM: dts: Add missing earlycon UART for Beagleboard
We can get early boot messages if CONFIG_SERIAL_EARLYCON=y is set, and
kernel commandline has debug earlycon. But we're missing the related dts
entry for Beagleboard.
Signed-off-by: Tony Lindgren <[email protected]>
---
Note: Untested, I can't find my Beagleboard-XM right now..
---
arch/arm/boot/dts/omap3-beagle.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -24,6 +24,10 @@
reg = <0x80000000 0x10000000>; /* 256 MB */
};
+ chosen {
+ stdout-path = &uart3;
+ };
+
aliases {
display0 = &dvi0;
display1 = &tv0;
--
2.19.1
On Thu, Nov 8, 2018 at 7:49 AM Tony Lindgren <[email protected]> wrote:
>
> * Olof Johansson <[email protected]> [181107 09:28]:
> > On Wed, Nov 7, 2018 at 9:17 AM Linus Torvalds
> > <[email protected]> wrote:
> > >
> > > On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson <[email protected]> wrote:
> > > >
> > > > ARM: SoC fixes
> > >
> > > Pulled.
> > >
> > > > I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> > > > and it ended up regressing at least BeagleBone XM boards.
> > >
> > > Odd. Did it hit some "may_sleep()" test in a driver that is hidden by
> > > preempt being off? Otherwise I don't see how/why preempt should fail
> > > in a board-specific manner..
> >
> > The board hangs early during boot and the usual way of collecting
> > early console doesn't seem to work when attempted (I haven't tried
> > personally).
> >
> > It's one of the major non-SMP platforms covered by tests. I'd be
> > surprised if it turns out to be truly _board_ specific (and rather
> > specific to OMAP3), but we don't have enough data yet. Chances are it
> > either shuffles some timing around or indeed hits a may_sleep() test
> > somewhere.
> >
> > (I just realized I might have missed to attribute Guillaume in the
> > revert patch. Sorry about that).
>
> Looks like we're missing the stdout-path for earlycon, maybe try
> with the following patch? I can't find my Beagleboard-xm right now,
> time to clean-up a bit I guess.
>
> At least omap3-evm, logicpd-torpedo and n900 all boot with PREEMPT.
To follow up on this, it turned out to be an issue where the kernel
outgrew the location it was loaded to, and overwrite the device tree
on decompression. So, not a code issue.
It's a known fragile aspect on some of the u-boot setups, and
something I've been hit by myself on my farm a few times.
Still, for now we'll keep PREEMPT off until next merge window.
-Olof
On Sat, Nov 10, 2018 at 10:09:19AM -0800, Olof Johansson wrote:
> On Thu, Nov 8, 2018 at 7:49 AM Tony Lindgren <[email protected]> wrote:
> >
> > * Olof Johansson <[email protected]> [181107 09:28]:
> > > On Wed, Nov 7, 2018 at 9:17 AM Linus Torvalds
> > > <[email protected]> wrote:
> > > >
> > > > On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson <[email protected]> wrote:
> > > > >
> > > > > ARM: SoC fixes
> > > >
> > > > Pulled.
> > > >
> > > > > I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> > > > > and it ended up regressing at least BeagleBone XM boards.
> > > >
> > > > Odd. Did it hit some "may_sleep()" test in a driver that is hidden by
> > > > preempt being off? Otherwise I don't see how/why preempt should fail
> > > > in a board-specific manner..
> > >
> > > The board hangs early during boot and the usual way of collecting
> > > early console doesn't seem to work when attempted (I haven't tried
> > > personally).
> > >
> > > It's one of the major non-SMP platforms covered by tests. I'd be
> > > surprised if it turns out to be truly _board_ specific (and rather
> > > specific to OMAP3), but we don't have enough data yet. Chances are it
> > > either shuffles some timing around or indeed hits a may_sleep() test
> > > somewhere.
> > >
> > > (I just realized I might have missed to attribute Guillaume in the
> > > revert patch. Sorry about that).
> >
> > Looks like we're missing the stdout-path for earlycon, maybe try
> > with the following patch? I can't find my Beagleboard-xm right now,
> > time to clean-up a bit I guess.
> >
> > At least omap3-evm, logicpd-torpedo and n900 all boot with PREEMPT.
>
> To follow up on this, it turned out to be an issue where the kernel
> outgrew the location it was loaded to, and overwrite the device tree
> on decompression. So, not a code issue.
>
> It's a known fragile aspect on some of the u-boot setups, and
> something I've been hit by myself on my farm a few times.
>
> Still, for now we'll keep PREEMPT off until next merge window.
>
Hello
Note that CONFIG_PREEMPT cause some errors also on sun8i-a83t-bananapi-m3
Already reported https://lkml.org/lkml/2017/12/29/139
Regards
* Corentin Labbe <[email protected]> [181112 06:13]:
> On Sat, Nov 10, 2018 at 10:09:19AM -0800, Olof Johansson wrote:
> > On Thu, Nov 8, 2018 at 7:49 AM Tony Lindgren <[email protected]> wrote:
> > >
> > > * Olof Johansson <[email protected]> [181107 09:28]:
> > > > On Wed, Nov 7, 2018 at 9:17 AM Linus Torvalds
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Wed, Nov 7, 2018 at 9:10 AM Olof Johansson <[email protected]> wrote:
> > > > > >
> > > > > > ARM: SoC fixes
> > > > >
> > > > > Pulled.
> > > > >
> > > > > > I was a bit too trigger happy to enable PREEMPT on multi_v7_defconfig,
> > > > > > and it ended up regressing at least BeagleBone XM boards.
> > > > >
> > > > > Odd. Did it hit some "may_sleep()" test in a driver that is hidden by
> > > > > preempt being off? Otherwise I don't see how/why preempt should fail
> > > > > in a board-specific manner..
> > > >
> > > > The board hangs early during boot and the usual way of collecting
> > > > early console doesn't seem to work when attempted (I haven't tried
> > > > personally).
> > > >
> > > > It's one of the major non-SMP platforms covered by tests. I'd be
> > > > surprised if it turns out to be truly _board_ specific (and rather
> > > > specific to OMAP3), but we don't have enough data yet. Chances are it
> > > > either shuffles some timing around or indeed hits a may_sleep() test
> > > > somewhere.
> > > >
> > > > (I just realized I might have missed to attribute Guillaume in the
> > > > revert patch. Sorry about that).
> > >
> > > Looks like we're missing the stdout-path for earlycon, maybe try
> > > with the following patch? I can't find my Beagleboard-xm right now,
> > > time to clean-up a bit I guess.
> > >
> > > At least omap3-evm, logicpd-torpedo and n900 all boot with PREEMPT.
> >
> > To follow up on this, it turned out to be an issue where the kernel
> > outgrew the location it was loaded to, and overwrite the device tree
> > on decompression. So, not a code issue.
> >
> > It's a known fragile aspect on some of the u-boot setups, and
> > something I've been hit by myself on my farm a few times.
> >
> > Still, for now we'll keep PREEMPT off until next merge window.
> >
>
> Hello
>
> Note that CONFIG_PREEMPT cause some errors also on sun8i-a83t-bananapi-m3
> Already reported https://lkml.org/lkml/2017/12/29/139
Also thread "[PATCH v1 1/5] drivercore: Revert "deferral race condition fix"
is reverting commit 58b116bce136 ("drivercore: deferral race condition fix")
which has CONFIG_PREEMPT mentioned in the log. So more testing is
probably needed in Linux next before enabling CONFIG_PREEMPT again.
Regards,
Tony