* [PATCH v3 0/4] add dual-boot support
From: Ivan Mikhaylov @ 2019-08-27 16:54 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
ASPEED SoCs support dual-boot feature for SPI Flash.
When strapped appropriately, the SoC starts wdt2 (/dev/watchdog1)
and if within a minute it is not disabled, it goes off and reboots
the SoC from an alternate SPI Flash chip by changing CS0 controls
to actually drive CS1 line.
When booted from alternate chip, in order to access the main chip
at CS0, the user must reset the appropriate bit in the watchdog
hardware. There is no interface that would allow to do that from
an embedded firmware startup script.
This commit implements support for that feature:
* Enable 'alt-boot' option for wdt2
* Enable secondary SPI flash chip
* Make it possible to get access to the primary SPI flash chip at CS0
after booting from the alternate chip at CS1. A sysfs interface is added
to provide an easy way for embedded firmware startup scripts to clear
the chip select bit to gain access to the primary flash chip in order
to allow for recovery of its contents.
Ivan Mikhaylov (4):
vesnin: add wdt2 section with alt-boot option
vesnin: add secondary SPI flash chip
watchdog/aspeed: add support for dual boot
aspeed/watchdog: Add access_cs0 option for alt-boot
.../ABI/testing/sysfs-class-watchdog | 34 ++++++++++
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 12 ++++
drivers/watchdog/aspeed_wdt.c | 65 ++++++++++++++++++-
3 files changed, 110 insertions(+), 1 deletion(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 2/4] vesnin: add secondary SPI flash chip
From: Ivan Mikhaylov @ 2019-08-27 16:54 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190827165426.17037-1-i.mikhaylov@yadro.com>
Adds secondary SPI flash chip into dts for vesnin.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
index 2ee26c86a32e..db4cc3df61ce 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
@@ -81,6 +81,14 @@
label = "bmc";
#include "openbmc-flash-layout.dtsi"
};
+
+ flash@1 {
+ status = "okay";
+ reg = < 1 >;
+ compatible = "jedec,spi-nor";
+ m25p,fast-read;
+ label = "alt";
+ };
};
&spi {
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/4] vesnin: add wdt2 section with alt-boot option
From: Ivan Mikhaylov @ 2019-08-27 16:54 UTC (permalink / raw)
To: Guenter Roeck, Wim Van Sebroeck
Cc: Mark Rutland, devicetree, linux-watchdog, linux-aspeed,
Andrew Jeffery, openbmc, Alexander Amelkin, linux-kernel,
Rob Herring, Joel Stanley, Ivan Mikhaylov, linux-arm-kernel
In-Reply-To: <20190827165426.17037-1-i.mikhaylov@yadro.com>
Adds wdt2 section with 'alt-boot' option into dts for vesnin.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
index 0b9e29c3212e..2ee26c86a32e 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts
@@ -222,3 +222,7 @@
&vuart {
status = "okay";
};
+
+&wdt2 {
+ aspeed,alt-boot;
+};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] PCI: Fix misspelled words.
From: Rob Herring @ 2019-08-27 16:53 UTC (permalink / raw)
To: Krzysztof Wilczynski
Cc: devicetree, Richard Zhu, Thomas Petazzoni, linux-pci,
Sascha Hauer, linux-kernel, Bjorn Helgaas, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel,
Lucas Stach
In-Reply-To: <20190819115306.27338-1-kw@linux.com>
On Mon, 19 Aug 2019 13:53:06 +0200, Krzysztof Wilczynski wrote:
> Fix misspelled words in include/linux/pci.h, drivers/pci/Kconfig,
> and in the documentation for Freescale i.MX6 and Marvell Armada 7K/8K
> PCIe interfaces. No functional change intended.
>
> Related commit 96291d565550 ("PCI: Fix typos and whitespace errors").
>
> Signed-off-by: Krzysztof Wilczynski <kw@linux.com>
> ---
> Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 2 +-
> Documentation/devicetree/bindings/pci/pci-armada8k.txt | 2 +-
> drivers/pci/Kconfig | 2 +-
> include/linux/pci.h | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: watchdog: Add ast2600 compatible
From: Rob Herring @ 2019-08-27 16:49 UTC (permalink / raw)
To: Joel Stanley
Cc: devicetree, Ryan Chen, linux-watchdog, linux-aspeed,
Andrew Jeffery, linux-arm-kernel, Wim Van Sebroeck, Guenter Roeck
In-Reply-To: <20190819051738.17370-2-joel@jms.id.au>
On Mon, 19 Aug 2019 14:47:37 +0930, Joel Stanley wrote:
> This adds a compatible for the ast2600, a new ASPEED SoC.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> v2:
> - Add Andrew's r-b
> ---
> Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/5] arm64: avoid out-of-line ll/sc atomics
From: Will Deacon @ 2019-08-27 16:49 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, Peter Zijlstra, Catalin Marinas, Boqun Feng,
Will Deacon, Ard.Biesheuvel, linux-arm-kernel
In-Reply-To: <20190812143625.42745-1-andrew.murray@arm.com>
Hi Andrew,
On Mon, Aug 12, 2019 at 03:36:20PM +0100, Andrew Murray wrote:
> When building for LSE atomics (CONFIG_ARM64_LSE_ATOMICS), if the hardware
> or toolchain doesn't support it the existing code will fallback to ll/sc
> atomics. It achieves this by branching from inline assembly to a function
> that is built with specical compile flags. Further this results in the
> clobbering of registers even when the fallback isn't used increasing
> register pressure.
>
> Let's improve this by providing inline implementatins of both LSE and
> ll/sc and use a static key to select between them. This allows for the
> compiler to generate better atomics code.
>
> Whilst it may be difficult to understand the performance impact, we gain
> improved code readability, ability to use Clang, and improved backtrace
> reliability.
>
> Build and boot tested, along with atomic_64_test.
I think this series is really close now and I was hoping to get something
queued for 5.4. Would you be able to respin, addressing Mark's comments
please? It would be a shame for this to miss another release.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V3, 1/2] media: dt-bindings: media: i2c: Add bindings for OV02A10
From: Rob Herring @ 2019-08-27 16:48 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
tfiga, louis.kuo, sj.huang, robh+dt, linux-mediatek, dongchun.zhu,
sakari.ailus, matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel,
linux-media
In-Reply-To: <20190819034331.13098-2-dongchun.zhu@mediatek.com>
On Mon, 19 Aug 2019 11:43:30 +0800, <dongchun.zhu@mediatek.com> wrote:
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> Add device tree binding documentation for the OV02A10 camera sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../devicetree/bindings/media/i2c/ov02a10.txt | 54 ++++++++++++++++++++++
> MAINTAINERS | 7 +++
> 2 files changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov02a10.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 04/13] dt-bindings: rtc: mediatek: add missing mt6397 rtc
From: Rob Herring @ 2019-08-27 16:47 UTC (permalink / raw)
To: Frank Wunderlich
Cc: linux-rtc, devicetree, Alexandre Belloni,
linux-arm-kernel @ lists . infradead . org Alessandro Zummo,
linux-pm, Frank Wunderlich, Josef Friedl, linux-kernel,
Tianping Fang, linux-mediatek, Matthias Brugger, Mark Rutland,
Eddie Huang, Lee Jones, linux-arm-kernel
In-Reply-To: <20190818135611.7776-5-frank-w@public-files.de>
On Sun, 18 Aug 2019 15:56:02 +0200, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> add missing devicetree-binding document for mt6397 rtc
> in later patch driver is extended with mt6323 chip
>
> Suggested-By: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> changes since v5: none
> changes since v4: use relative path
> changes since v3: moved SOB
> changes since v2: splitted rtc-mt6397.txt from first patch
> ---
> .../devicetree/bindings/rtc/rtc-mt6397.txt | 29 +++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 03/13] dt-bindings: mfd: mediatek: add mt6323 power-controller
From: Rob Herring @ 2019-08-27 16:46 UTC (permalink / raw)
To: Frank Wunderlich
Cc: linux-rtc, devicetree, Alexandre Belloni,
linux-arm-kernel @ lists . infradead . org Alessandro Zummo,
linux-pm, Frank Wunderlich, Josef Friedl, linux-kernel,
Tianping Fang, linux-mediatek, Matthias Brugger, Mark Rutland,
Eddie Huang, Lee Jones, linux-arm-kernel
In-Reply-To: <20190818135611.7776-4-frank-w@public-files.de>
On Sun, 18 Aug 2019 15:56:01 +0200, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> - add powercontroller-section to existing binding-document
> - add mt6323-pwrc bindings-document with example
>
> Suggested-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> ---
> changes since v5: split out non-pwrc related changes
> changes since v4: none
> changes since v3: none
> changes since v2: none (=v2 part 7)
> ---
> .../devicetree/bindings/mfd/mt6397.txt | 6 ++++++
> .../bindings/power/reset/mt6323-poweroff.txt | 20 +++++++++++++++++++
> 2 files changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 02/13] dt-bindings: mfd: mediatek: update rtc to include mt6323
From: Rob Herring @ 2019-08-27 16:46 UTC (permalink / raw)
To: Frank Wunderlich
Cc: linux-rtc, devicetree, Alexandre Belloni,
linux-arm-kernel @ lists . infradead . org Alessandro Zummo,
linux-pm, Frank Wunderlich, Josef Friedl, linux-kernel,
Tianping Fang, linux-mediatek, Matthias Brugger, Mark Rutland,
Eddie Huang, Lee Jones, linux-arm-kernel
In-Reply-To: <20190818135611.7776-3-frank-w@public-files.de>
On Sun, 18 Aug 2019 15:56:00 +0200, Frank Wunderlich wrote:
> From: Josef Friedl <josef.friedl@speed.at>
>
> add mt6323 to rtc-bindings
>
> Signed-off-by: Josef Friedl <josef.friedl@speed.at>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> changes since v5: splitted from "dt-bindings: add powercontroller"
> ---
> Documentation/devicetree/bindings/mfd/mt6397.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] drm/meson: add resume/suspend hooks
From: Daniel Vetter @ 2019-08-27 16:44 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-arm-kernel, khilman, linux-kernel, dri-devel, linux-amlogic
In-Reply-To: <20190827095825.21015-1-narmstrong@baylibre.com>
On Tue, Aug 27, 2019 at 11:58:23AM +0200, Neil Armstrong wrote:
> This serie adds the resume/suspend hooks in the Amlogic Meson VPU main driver
> and the DW-HDMI Glue driver to correctly save state and disable HW before
> suspend, and succesfully re-init the HW to recover functionnal display
> after resume.
>
> This serie has been tested on Amlogic G12A based SEI510 board, using
> the newly accepted VRTC driver and the rtcwake utility.
No idea about the hw, but looks all neatly integrated into pm stuff, so on
both patches:
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Neil Armstrong (2):
> drm/meson: dw_hdmi: add resume/suspend hooks
> drm/meson: add resume/suspend hooks
>
> drivers/gpu/drm/meson/meson_drv.c | 32 ++++++++
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 110 ++++++++++++++++++--------
> 2 files changed, 108 insertions(+), 34 deletions(-)
>
> --
> 2.22.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/9] block: support diskcipher
From: Theodore Y. Ts'o @ 2019-08-27 16:40 UTC (permalink / raw)
To: boojin.kim
Cc: 'Ulf Hansson', 'Mike Snitzer', dm-devel,
'Andreas Dilger', 'Alasdair Kergon',
'Eric Biggers', linux-samsung-soc, 'Herbert Xu',
'Krzysztof Kozlowski', 'Satya Tangirala',
'Jaehoon Chung', 'Kukjin Kim', linux-ext4,
'Chao Yu', linux-block, linux-fscrypt,
'Jaegeuk Kim', linux-arm-kernel, 'Jens Axboe',
linux-mmc, linux-kernel, linux-f2fs-devel, linux-crypto,
linux-fsdevel, 'David S. Miller'
In-Reply-To: <03b201d55cb2$1d4d31b0$57e79510$@samsung.com>
On Tue, Aug 27, 2019 at 05:33:33PM +0900, boojin.kim wrote:
>
> Dear Satya.
> Keyslot manager is a good solution for ICE. And probably no issue for FMP.
> But, I think it's complicated for FMP because FMP doesn't need
> any keyslot control.
Hi Boojin,
I think the important thing to realize here is that there are a large
number of hardware devices for which the keyslot manager *is* needed.
And from the upstream kernel's perspective, supporting two different
schemes for supporting the inline encryption feature is more
complexity than just supporting one which is general enough to support
a wider variety of hardware devices.
If you want somethig which is only good for the hardware platform you
are charged to support, that's fine if it's only going to be in a
Samsung-specific kernel. But if your goal is to get something that
works upstream, especially if it requires changes in core layers of
the kernel, it's important that it's general enough to support most,
if not all, if the hardware devices in the industry.
Regards,
- Ted
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Arnd Bergmann @ 2019-08-27 16:33 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Bartlomiej Zolnierkiewicz, Tony Lindgren, Greg Kroah-Hartman,
Linus Walleij, Linux Kernel Mailing List, Dominik Brodowski,
Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <20190816083403.GB1952@darkstar.musicnaut.iki.fi>
On Fri, Aug 16, 2019 at 10:34 AM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> On Wed, Aug 14, 2019 at 12:36:40PM +0200, Arnd Bergmann wrote:
> > On Wed, Aug 14, 2019 at 9:49 AM Tony Lindgren <tony@atomide.com> wrote:
> > > * Arnd Bergmann <arnd@arndb.de> [190813 19:34]:
> > > > -#define OMAP1_IO_OFFSET 0x01000000 /* Virtual IO
> > > > = 0xfefb0000 */
> > > > +#define OMAP1_IO_OFFSET 0x00fb0000 /* Virtual IO
> > > > = 0xff000000 */
> > > > #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET)
> > >
> > > Oh OK yeah sounds like that's the issue.
> > >
> > > > There may be additional locations that hardcode the virtual address.
> > >
> > > Those should be in mach-omap1/io.c, and I recall innovator had some
> > > hardcoded fpga address that should also be checked.
> >
> > I see four boards with hardcoded I/O addresses, but they are all below
> > the PCI I/O virtual address range, and are not affected by that change.
> >
> > For the innovator FPGA access, this was ok, it uses the correct address
> > in the OMAP1_IO_OFFSET range.
>
> I tried testing this on OSK board. If I boot with earlyprintk disabled,
> it boots OK and everything works (also CF card) with your playground
> commit 5723b6686943.
>
> However with earlyprintk it seems to hang as soon as kernel tries to print
> something. So something goes wrong with early DEBUG_LL mapping code when
> CONFIG_DEBUG_UART_VIRT=0xff000000 is used?
I just redid the calculation and came out with the same address, so I
don't think I put the wrong one there. The address also does not
conflict with the PCI mapping, and the address is the same one that
is installed later, so that should also be fine.
Are you sure you used the correct address in the .config file? If you
ran 'make oldconfig', the virtual address would not be changed here
as I just modify the default for a fresh 'make omap1_defconfig'
run or similar.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 01/13] dt-bindings: mfd: mediatek: mt6397: change to relative paths
From: Rob Herring @ 2019-08-27 16:33 UTC (permalink / raw)
To: Frank Wunderlich
Cc: linux-rtc, devicetree, Alexandre Belloni,
linux-arm-kernel @ lists . infradead . org Alessandro Zummo,
linux-pm, Frank Wunderlich, Josef Friedl, linux-kernel,
Tianping Fang, linux-mediatek, Matthias Brugger, Mark Rutland,
Eddie Huang, Lee Jones, linux-arm-kernel
In-Reply-To: <20190818135611.7776-2-frank-w@public-files.de>
On Sun, 18 Aug 2019 15:55:59 +0200, Frank Wunderlich wrote:
> paths in dt-bindings should be relative as suggested by Lee Johnes
>
> Suggested-By: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> changes since v5: splitted from dt-bindings: add powercontroller
> ---
> Documentation/devicetree/bindings/mfd/mt6397.txt | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 08/10] dt-bindings: PCI: Add the pf-offset property
From: Rob Herring @ 2019-08-27 16:26 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, Xiaowei Bao, arnd,
gregkh, jingoohan1, linuxppc-dev, linux-pci, linux-kernel,
leoyang.li, minghuan.Lian, devicetree, robh+dt, linux-arm-kernel,
gustavo.pimentel, bhelgaas, kishon, shawnguo, mingkai.hu
In-Reply-To: <20190815083716.4715-8-xiaowei.bao@nxp.com>
On Thu, 15 Aug 2019 16:37:14 +0800, Xiaowei Bao wrote:
> Add the pf-offset property for multiple PF.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] PCI: tegra: Add support to enable slot regulators
From: Vidya Sagar @ 2019-08-27 16:24 UTC (permalink / raw)
To: Andrew Murray
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, robh+dt, kishon, linux-tegra,
thierry.reding, linux-pci, bhelgaas, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190827154725.GP14582@e119886-lin.cambridge.arm.com>
On 8/27/2019 9:17 PM, Andrew Murray wrote:
> On Mon, Aug 26, 2019 at 01:01:43PM +0530, Vidya Sagar wrote:
>> Add support to get regulator information of 3.3V and 12V supplies of a PCIe
>> slot from the respective controller's device-tree node and enable those
>> supplies. This is required in platforms like p2972-0000 where the supplies
>> to x16 slot owned by C5 controller need to be enabled before attempting to
>> enumerate the devices.
>>
>> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
>> ---
>> drivers/pci/controller/dwc/pcie-tegra194.c | 65 ++++++++++++++++++++++
>> 1 file changed, 65 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
>> index 8a27b25893c9..97de2151a738 100644
>> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
>> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
>> @@ -278,6 +278,8 @@ struct tegra_pcie_dw {
>> u32 aspm_l0s_enter_lat;
>>
>> struct regulator *pex_ctl_supply;
>> + struct regulator *slot_ctl_3v3;
>> + struct regulator *slot_ctl_12v;
>>
>> unsigned int phy_count;
>> struct phy **phys;
>> @@ -1047,6 +1049,59 @@ static void tegra_pcie_downstream_dev_to_D0(struct tegra_pcie_dw *pcie)
>> }
>> }
>>
>> +static void tegra_pcie_get_slot_regulators(struct tegra_pcie_dw *pcie)
>> +{
>> + pcie->slot_ctl_3v3 = devm_regulator_get_optional(pcie->dev, "vpcie3v3");
>> + if (IS_ERR(pcie->slot_ctl_3v3))
>> + pcie->slot_ctl_3v3 = NULL;
>> +
>> + pcie->slot_ctl_12v = devm_regulator_get_optional(pcie->dev, "vpcie12v");
>> + if (IS_ERR(pcie->slot_ctl_12v))
>> + pcie->slot_ctl_12v = NULL;
>
> Do these need to take into consideration -EPROBE_DEFER?
Since these are devm_* APIs, isn't it taken care of automatically?
>
> Thanks,
>
> Andrew Murray
>
>> +}
>> +
>> +static int tegra_pcie_enable_slot_regulators(struct tegra_pcie_dw *pcie)
>> +{
>> + int ret;
>> +
>> + if (pcie->slot_ctl_3v3) {
>> + ret = regulator_enable(pcie->slot_ctl_3v3);
>> + if (ret < 0) {
>> + dev_err(pcie->dev,
>> + "Failed to enable 3V3 slot supply: %d\n", ret);
>> + return ret;
>> + }
>> + }
>> +
>> + if (pcie->slot_ctl_12v) {
>> + ret = regulator_enable(pcie->slot_ctl_12v);
>> + if (ret < 0) {
>> + dev_err(pcie->dev,
>> + "Failed to enable 12V slot supply: %d\n", ret);
>> + if (pcie->slot_ctl_3v3)
>> + regulator_disable(pcie->slot_ctl_3v3);
>> + return ret;
>> + }
>> + }
>> +
>> + /*
>> + * According to PCI Express Card Electromechanical Specification
>> + * Revision 1.1, Table-2.4, T_PVPERL (Power stable to PERST# inactive)
>> + * should be a minimum of 100ms.
>> + */
>> + msleep(100);
>> +
>> + return 0;
>> +}
>> +
>> +static void tegra_pcie_disable_slot_regulators(struct tegra_pcie_dw *pcie)
>> +{
>> + if (pcie->slot_ctl_12v)
>> + regulator_disable(pcie->slot_ctl_12v);
>> + if (pcie->slot_ctl_3v3)
>> + regulator_disable(pcie->slot_ctl_3v3);
>> +}
>> +
>> static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
>> bool en_hw_hot_rst)
>> {
>> @@ -1060,6 +1115,10 @@ static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
>> return ret;
>> }
>>
>> + ret = tegra_pcie_enable_slot_regulators(pcie);
>> + if (ret < 0)
>> + goto fail_slot_reg_en;
>> +
>> ret = regulator_enable(pcie->pex_ctl_supply);
>> if (ret < 0) {
>> dev_err(pcie->dev, "Failed to enable regulator: %d\n", ret);
>> @@ -1142,6 +1201,8 @@ static int tegra_pcie_config_controller(struct tegra_pcie_dw *pcie,
>> fail_core_clk:
>> regulator_disable(pcie->pex_ctl_supply);
>> fail_reg_en:
>> + tegra_pcie_disable_slot_regulators(pcie);
>> +fail_slot_reg_en:
>> tegra_pcie_bpmp_set_ctrl_state(pcie, false);
>>
>> return ret;
>> @@ -1174,6 +1235,8 @@ static int __deinit_controller(struct tegra_pcie_dw *pcie)
>> return ret;
>> }
>>
>> + tegra_pcie_disable_slot_regulators(pcie);
>> +
>> ret = tegra_pcie_bpmp_set_ctrl_state(pcie, false);
>> if (ret) {
>> dev_err(pcie->dev, "Failed to disable controller %d: %d\n",
>> @@ -1372,6 +1435,8 @@ static int tegra_pcie_dw_probe(struct platform_device *pdev)
>> return ret;
>> }
>>
>> + tegra_pcie_get_slot_regulators(pcie);
>> +
>> pcie->pex_ctl_supply = devm_regulator_get(dev, "vddio-pex-ctl");
>> if (IS_ERR(pcie->pex_ctl_supply)) {
>> dev_err(dev, "Failed to get regulator: %ld\n",
>> --
>> 2.17.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/11] dt-bindings: drm/bridge: analogix-anx78xx: add new variants
From: Rob Herring @ 2019-08-27 16:20 UTC (permalink / raw)
To: Brian Masney
Cc: mark.rutland, devicetree, jernej.skrabec, narmstrong, airlied,
linux-kernel, linus.walleij, jonas, agross, dri-devel,
bjorn.andersson, a.hajda, robdclark, robh+dt, Laurent.pinchart,
daniel, linux-arm-msm, enric.balletbo, freedreno, sean,
linux-arm-kernel
In-Reply-To: <20190815004854.19860-2-masneyb@onstation.org>
On Wed, 14 Aug 2019 20:48:44 -0400, Brian Masney wrote:
> Add support for the analogix,anx7808, analogix,anx7812, and
> analogix,anx7818 variants.
>
> Signed-off-by: Brian Masney <masneyb@onstation.org>
> ---
> .../devicetree/bindings/display/bridge/anx7814.txt | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] Fix TLB invalidation on arm64
From: Mark Rutland @ 2019-08-27 16:19 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, Catalin Marinas, Peter Zijlstra, linux-arm-kernel,
Marc Zyngier
In-Reply-To: <20190827131818.14724-1-will@kernel.org>
On Tue, Aug 27, 2019 at 02:18:12PM +0100, Will Deacon wrote:
> Hi all,
Hi Will,
For the series:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
>
> [+linux-arch since the end of this may be applicable to other architectures]
>
> Commit 24fe1b0efad4fcdd ("arm64: Remove unnecessary ISBs from
> set_{pte,pmd,pud") removed ISB instructions immediately following updates to
> the page table, on the grounds that they are not required by the
> architecture and a DSB alone is sufficient to ensure that subsequent data
> accesses use the new translation:
>
> DDI0487E_a, B2-128:
>
> | ... no instruction that appears in program order after the DSB instruction
> | can alter any state of the system or perform any part of its functionality
> | until the DSB completes other than:
> |
> | * Being fetched from memory and decoded
> | * Reading the general-purpose, SIMD and floating-point, Special-purpose, or
> | System registers that are directly or indirectly read without causing
> | side-effects.
>
> However, the same document also states the following:
>
> DDI0487E_a, B2-125:
>
> | DMB and DSB instructions affect reads and writes to the memory system
> | generated by Load/Store instructions and data or unified cache maintenance
> | instructions being executed by the PE. Instruction fetches or accesses
> | caused by a hardware translation table access are not explicit accesses.
>
> which appears to claim that the DSB alone is insufficient. Unfortunately,
> some CPU designers have followed the second clause above, whereas in Linux
> we've been relying on the first. This means that our mapping sequence:
>
> MOV X0, <valid pte>
> STR X0, [Xptep] // Store new PTE to page table
> DSB ISHST
> LDR X1, [X2] // Translates using the new PTE
>
> can actually raise a translation fault on the load instruction because the
> translation can be performed speculatively before the page table update and
> then marked as "faulting" by the CPU. For user PTEs, this is ok because we
> can handle the spurious fault, but for kernel PTEs and intermediate table
> entries this results in a panic().
>
> We can fix this by reverting 24fe1b0efad4fcdd, but the fun doesn't stop
> there. If we consider the unmap case, then a similar constraint applies to
> ordering subsequent memory accesses after the completion of the TLB
> invalidation, so we also need to add an ISB instruction to
> __flush_tlb_kernel_pgtable(). For user addresses, the exception return
> provides the necessary context synchronisation.
>
> This then raises an interesting question: if an ISB is required after a TLBI
> instruction to prevent speculative translation of subsequent instructions,
> how is this speculation prevented on concurrent CPUs that receive the
> broadcast TLB invalidation message? Sending and completing a broadcast TLB
> invalidation message does not imply execution of an ISB on the remote CPU,
> however it /does/ require that the remote CPU will no longer make use of any
> old translations because otherwise we wouldn't be able to guarantee that an
> unmapped page could no longer be modified. In this regard, receiving a TLB
> invalidation is in some ways stronger than sending one (where you need the
> ISB).
>
> So far, so good, but the final piece of the puzzle isn't quite so rosy.
>
> *** Other architecture maintainers -- start here! ***
>
> In the case that one CPU maps a page and then sets a flag to tell another
> CPU:
>
> CPU 0
> -----
>
> MOV X0, <valid pte>
> STR X0, [Xptep] // Store new PTE to page table
> DSB ISHST
> ISB
> MOV X1, #1
> STR X1, [Xflag] // Set the flag
>
> CPU 1
> -----
>
> loop: LDAR X0, [Xflag] // Poll flag with Acquire semantics
> CBZ X0, loop
> LDR X1, [X2] // Translates using the new PTE
>
> then the final load on CPU 1 can raise a translation fault for the same
> reasons as mentioned at the start of this description. In reality, code
> such as:
>
> CPU 0 CPU 1
> ----- -----
> spin_lock(&lock); spin_lock(&lock);
> *ptr = vmalloc(size); if (*ptr)
> spin_unlock(&lock); foo = **ptr;
> spin_unlock(&lock);
>
> will not trigger the fault because there is an address dependency on
> CPU1 which prevents the speculative translation. However, more exotic
> code where the virtual address is known ahead of time, such as:
>
> CPU 0 CPU 1
> ----- -----
> spin_lock(&lock); spin_lock(&lock);
> set_fixmap(0, paddr, prot); if (mapped)
> mapped = true; foo = *fix_to_virt(0);
> spin_unlock(&lock); spin_unlock(&lock);
>
> could fault. This can be avoided by any of:
>
> * Introducing broadcast TLB maintenance on the map path
> * Adding a DSB;ISB sequence after checking a flag which indicates
> that a virtual address is now mapped
> * Handling the spurious fault
>
> Given that we have never observed a problem in the concurrent case under
> Linux and future revisions of the architecture are being tightened so that
> translation table walks are effectively ordered in the same way as explicit
> memory accesses, we no longer treat spurious kernel faults as fatal if the
> page table indicates that the access was valid.
>
> Anyway, this patch series attempts to implement some of this and I plan
> to queue it for 5.4.
>
> Will
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
>
> --->8
>
> Will Deacon (6):
> Revert "arm64: Remove unnecessary ISBs from set_{pte,pmd,pud}"
> arm64: tlb: Ensure we execute an ISB following walk cache invalidation
> arm64: mm: Add ISB instruction to set_pgd()
> arm64: sysreg: Add some field definitions for PAR_EL1
> arm64: mm: Ignore spurious translation faults taken from the kernel
> arm64: kvm: Replace hardcoded '1' with SYS_PAR_EL1_F
>
> arch/arm64/include/asm/pgtable.h | 13 ++++++++++---
> arch/arm64/include/asm/sysreg.h | 3 +++
> arch/arm64/include/asm/tlbflush.h | 1 +
> arch/arm64/kvm/hyp/switch.c | 2 +-
> arch/arm64/mm/fault.c | 33 +++++++++++++++++++++++++++++++++
> 5 files changed, 48 insertions(+), 4 deletions(-)
>
> --
> 2.11.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm/arm64: defconfig: Update configs to use the new CROS_EC options
From: Arnd Bergmann @ 2019-08-27 16:12 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Gwendal Grignou, kernel, Geert Uytterhoeven, Tony Lindgren,
Catalin Marinas, Linus Walleij, Thierry Reding, Miquel Raynal,
Guenter Roeck, Leonard Crestez, Will Deacon, Marek Szyprowski,
Maxime Ripard,
moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Anson Huang,
Lee Jones, Daniel Lezcano, Russell King, Krzysztof Kozlowski,
Jonathan Hunter, Marcin Juszkiewicz, Chanwoo Choi, Kukjin Kim,
Jagan Teki, Alexandre Torgue, Robert Jarzmik,
Enric Balletbo i Serra, SoC Team,
open list:TEGRA ARCHITECTURE SUPPORT, Simon Horman,
Fabrice Gasnier, Benson Leung, Linux ARM,
Linux Kernel Mailing List, Yannick Fertr?, Dinh Nguyen,
Sudeep Holla, Olof Johansson, Shawn Guo, Daniel Mack
In-Reply-To: <20190827161045.GC26807@tuxbook-pro>
On Tue, Aug 27, 2019 at 6:08 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Tue 27 Aug 08:48 PDT 2019, Enric Balletbo i Serra wrote:
>
> > Recently we refactored the CrOS EC drivers moving part of the code from
> > the MFD subsystem to the platform chrome subsystem. During this change
> > we needed to rename some config options, so, update the defconfigs
> > accordingly.
> >
> > Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
> > Tested-by: Gwendal Grignou <gwendal@chromium.org>
>
> Can we make the entries in the generic arm64 defconfig modules?
Good idea.
Actually I would prefer to have all of them as modules for consistency,
if at all possible.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm/arm64: defconfig: Update configs to use the new CROS_EC options
From: Bjorn Andersson @ 2019-08-27 16:10 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: gwendal, kernel, Geert Uytterhoeven, Tony Lindgren,
Catalin Marinas, Linus Walleij, Thierry Reding, Miquel Raynal,
groeck, Leonard Crestez, lee.jones, Marek Szyprowski,
Maxime Ripard, linux-samsung-soc, Anson Huang, Will Deacon,
Daniel Lezcano, Russell King, Krzysztof Kozlowski,
Jonathan Hunter, Marcin Juszkiewicz, Chanwoo Choi, Kukjin Kim,
Jagan Teki, Alexandre Torgue, Arnd Bergmann, Robert Jarzmik, soc,
linux-tegra, Simon Horman, Fabrice Gasnier, bleung,
linux-arm-kernel, linux-kernel, Yannick Fertr?, Dinh Nguyen,
Sudeep Holla, Olof Johansson, Shawn Guo, Daniel Mack
In-Reply-To: <20190827154851.10486-1-enric.balletbo@collabora.com>
On Tue 27 Aug 08:48 PDT 2019, Enric Balletbo i Serra wrote:
> Recently we refactored the CrOS EC drivers moving part of the code from
> the MFD subsystem to the platform chrome subsystem. During this change
> we needed to rename some config options, so, update the defconfigs
> accordingly.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
> Tested-by: Gwendal Grignou <gwendal@chromium.org>
Can we make the entries in the generic arm64 defconfig modules?
Regards,
Bjorn
> ---
> Dear all,
>
> This is basically a resend of [1] in order to get patch into the arm-soc
> patchwork and can be merged independently of the series. The patch was
> originally sent as part of the these series [2] but as defconfig changes
> often cause merge conflicts the maintainers prefer to have this merged
> through the arm-soc tree. My bad was not including the soc ML from the
> begining, so sorry about that.
>
> Thanks,
> Enric
>
> [1] https://lkml.org/lkml/2019/8/23/518
> [2] https://lkml.org/lkml/2019/8/23/475
>
> arch/arm/configs/exynos_defconfig | 6 +++++-
> arch/arm/configs/multi_v7_defconfig | 6 ++++--
> arch/arm/configs/pxa_defconfig | 4 +++-
> arch/arm/configs/tegra_defconfig | 2 +-
> arch/arm64/configs/defconfig | 6 ++++--
> 5 files changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index 2e6a863d25aa..d29029f534ec 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -154,7 +154,11 @@ CONFIG_CPU_THERMAL=y
> CONFIG_THERMAL_EMULATION=y
> CONFIG_WATCHDOG=y
> CONFIG_S3C2410_WATCHDOG=y
> -CONFIG_MFD_CROS_EC=y
> +CONFIG_MFD_CROS_EC_DEV=y
> +CONFIG_CHROME_PLATFORMS=y
> +CONFIG_CROS_EC=y
> +CONFIG_CROS_EC_I2C=y
> +CONFIG_CROS_EC_SPI=y
> CONFIG_MFD_MAX14577=y
> CONFIG_MFD_MAX77686=y
> CONFIG_MFD_MAX77693=y
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 6a40bc2ef271..0e9e70badf88 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -511,10 +511,12 @@ CONFIG_MFD_BCM590XX=y
> CONFIG_MFD_AC100=y
> CONFIG_MFD_AXP20X_I2C=y
> CONFIG_MFD_AXP20X_RSB=y
> -CONFIG_MFD_CROS_EC=m
> +CONFIG_MFD_CROS_EC_DEV=m
> +CONFIG_CHROME_PLATFORMS=y
> +CONFIG_CROS_EC=m
> CONFIG_CROS_EC_I2C=m
> CONFIG_CROS_EC_SPI=m
> -CONFIG_MFD_CROS_EC_CHARDEV=m
> +CONFIG_CROS_EC_CHARDEV=m
> CONFIG_MFD_DA9063=m
> CONFIG_MFD_MAX14577=y
> CONFIG_MFD_MAX77686=y
> diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
> index 787c3f9be414..635bf7dec53c 100644
> --- a/arch/arm/configs/pxa_defconfig
> +++ b/arch/arm/configs/pxa_defconfig
> @@ -393,7 +393,9 @@ CONFIG_SA1100_WATCHDOG=m
> CONFIG_MFD_AS3711=y
> CONFIG_MFD_BCM590XX=m
> CONFIG_MFD_AXP20X=y
> -CONFIG_MFD_CROS_EC=m
> +CONFIG_MFD_CROS_EC_DEV=m
> +CONFIG_CHROME_PLATFORMS=y
> +CONFIG_CROS_EC=m
> CONFIG_CROS_EC_I2C=m
> CONFIG_CROS_EC_SPI=m
> CONFIG_MFD_ASIC3=y
> diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
> index 8f5c6a5b444c..061037012335 100644
> --- a/arch/arm/configs/tegra_defconfig
> +++ b/arch/arm/configs/tegra_defconfig
> @@ -147,7 +147,7 @@ CONFIG_SENSORS_LM95245=y
> CONFIG_WATCHDOG=y
> CONFIG_TEGRA_WATCHDOG=y
> CONFIG_MFD_AS3722=y
> -CONFIG_MFD_CROS_EC=y
> +CONFIG_MFD_CROS_EC_DEV=y
> CONFIG_MFD_MAX8907=y
> CONFIG_MFD_STMPE=y
> CONFIG_MFD_PALMAS=y
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 0e58ef02880c..c4df1999fe0d 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -457,8 +457,7 @@ CONFIG_MFD_ALTERA_SYSMGR=y
> CONFIG_MFD_BD9571MWV=y
> CONFIG_MFD_AXP20X_I2C=y
> CONFIG_MFD_AXP20X_RSB=y
> -CONFIG_MFD_CROS_EC=y
> -CONFIG_MFD_CROS_EC_CHARDEV=m
> +CONFIG_MFD_CROS_EC_DEV=y
> CONFIG_MFD_EXYNOS_LPASS=m
> CONFIG_MFD_HI6421_PMIC=y
> CONFIG_MFD_HI655X_PMIC=y
> @@ -668,8 +667,11 @@ CONFIG_VIRTIO_BALLOON=y
> CONFIG_VIRTIO_MMIO=y
> CONFIG_XEN_GNTDEV=y
> CONFIG_XEN_GRANT_DEV_ALLOC=y
> +CONFIG_CHROME_PLATFORMS=y
> +CONFIG_CROS_EC=y
> CONFIG_CROS_EC_I2C=y
> CONFIG_CROS_EC_SPI=y
> +CONFIG_CROS_EC_CHARDEV=m
> CONFIG_COMMON_CLK_RK808=y
> CONFIG_COMMON_CLK_SCPI=y
> CONFIG_COMMON_CLK_CS2000_CP=y
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] arm64: smp: Increase secondary CPU boot timeout value
From: Mark Rutland @ 2019-08-27 16:05 UTC (permalink / raw)
To: Will Deacon; +Cc: catalin.marinas, linux-arm-kernel
In-Reply-To: <20190827151815.2160-2-will@kernel.org>
On Tue, Aug 27, 2019 at 04:18:13PM +0100, Will Deacon wrote:
> When many debug options are enabled simultaneously (e.g. PROVE_LOCKING,
> KMEMLEAK, DEBUG_PAGE_ALLOC, KASAN etc), it is possible for us to timeout
> when attempting to boot a secondary CPU and give up. Unfortunately, the
> CPU will /eventually/ appear, and sit in the background happily stuck
> in a recursive exception due to a NULL stack pointer.
>
> Increase the timeout to 5s, which will of course be enough for anybody.
>
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/smp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 018a33e01b0e..63c7a7682e93 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -123,7 +123,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
> * time out.
> */
> wait_for_completion_timeout(&cpu_running,
> - msecs_to_jiffies(1000));
> + msecs_to_jiffies(5000));
>
> if (!cpu_online(cpu)) {
> pr_crit("CPU%u: failed to come online\n", cpu);
> --
> 2.11.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix fixmap copy for 16K pages and 48-bit VA
From: Marc Zyngier @ 2019-08-27 16:04 UTC (permalink / raw)
To: Mark Rutland
Cc: Anshuman Khandual, Ard Biesheuvel, Catalin Marinas, Steve Capper,
Will Deacon, linux-arm-kernel
In-Reply-To: <20190827155708.34699-1-mark.rutland@arm.com>
On 2019-08-27 16:57, Mark Rutland wrote:
> With 16K pages and 48-bit VAs, the PGD level of table has two
> entries,
> and so the fixmap shares a PGD with the kernel image. Since commit:
>
> f9040773b7bbbd9e ("arm64: move kernel image to base of vmalloc
> area")
>
> ... we copy the existing fixmap to the new fine-grained page tables
> at
> the PUD level in this case. When walking to the new PUD, we forgot to
> offset the PGD entry and always used the PGD entry at index 0, but
> this
> worked as the kernel image and fixmap were in the low half of the
> TTBR1
> address space.
>
> As of commit:
>
> 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
>
> ... the kernel image and fixmap are in the high half of the TTBR1
> address space, and hence use the PGD at index 1, but we didn't update
> the fixmap copying code to account for this.
>
> Thus, we'll erroneously try to copy the fixmap slots into a PUD under
> the PGD entry at index 0. At the point we do so this PGD entry has
> not
> been initialised, and thus we'll try to write a value to a small
> offset
> from physical address 0, causing a number of potential problems.
>
> Fix this be correctly offsetting the PGD. This is split over a few
> steps
> for legibility.
>
> Fixes: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")
> Reported-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Steve Capper <Steve.Capper@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
> arch/arm64/mm/mmu.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 1d4247f9a496..4197f27f86e5 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -646,6 +646,8 @@ static void __init map_kernel(pgd_t *pgdp)
> set_pgd(pgd_offset_raw(pgdp, FIXADDR_START),
> READ_ONCE(*pgd_offset_k(FIXADDR_START)));
> } else if (CONFIG_PGTABLE_LEVELS > 3) {
> + pgd_t *bm_pgdp;
> + pud_t *bm_pudp;
> /*
> * The fixmap shares its top level pgd entry with the kernel
> * mapping. This can really only occur when we are running
> @@ -653,9 +655,9 @@ static void __init map_kernel(pgd_t *pgdp)
> * entry instead.
> */
> BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
> - pud_populate(&init_mm,
> - pud_set_fixmap_offset(pgdp, FIXADDR_START),
> - lm_alias(bm_pmd));
> + bm_pgdp = pgd_offset_raw(pgdp, FIXADDR_START);
> + bm_pudp = pud_set_fixmap_offset(bm_pgdp, FIXADDR_START);
> + pud_populate(&init_mm, bm_pudp, lm_alias(bm_pmd));
> pud_clear_fixmap();
> } else {
> BUG();
I've thrown this at a guest running on a TX1 box, and the guest
booted flawlessly, which is a major improvement.
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] arm64: smp: Don't enter kernel with NULL stack pointer or task struct
From: Mark Rutland @ 2019-08-27 16:04 UTC (permalink / raw)
To: Will Deacon; +Cc: catalin.marinas, linux-arm-kernel
In-Reply-To: <20190827151815.2160-3-will@kernel.org>
On Tue, Aug 27, 2019 at 04:18:14PM +0100, Will Deacon wrote:
> Although SMP bringup is inherently racy, we can significantly reduce
> the window during which secondary CPUs can unexpectedly enter the
> kernel by sanity checking the 'stack' and 'task' fields of the
> 'secondary_data' structure. If the booting CPU gave up waiting for us,
> then they will have been cleared to NULL and we should spin in a WFE; WFI
> loop instead.
>
> Signed-off-by: Will Deacon <will@kernel.org>
In future I think that we can handle this better using the MPIDR hash
and atomics to flip the values and cater for races, but this is better
than what we have, so FWIW:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/kernel/head.S | 8 ++++++++
> arch/arm64/kernel/smp.c | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 2cdacd1c141b..0baadf335172 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -724,14 +724,22 @@ __secondary_switched:
>
> adr_l x0, secondary_data
> ldr x1, [x0, #CPU_BOOT_STACK] // get secondary_data.stack
> + cbz x1, __secondary_too_slow
> mov sp, x1
> ldr x2, [x0, #CPU_BOOT_TASK]
> + cbz x2, __secondary_too_slow
> msr sp_el0, x2
> mov x29, #0
> mov x30, #0
> b secondary_start_kernel
> ENDPROC(__secondary_switched)
>
> +__secondary_too_slow:
> + wfe
> + wfi
> + b __secondary_too_slow
> +ENDPROC(__secondary_too_slow)
> +
> /*
> * The booting CPU updates the failed status @__early_cpu_boot_status,
> * with MMU turned off.
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 63c7a7682e93..1f8aeb77cba5 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -136,6 +136,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>
> secondary_data.task = NULL;
> secondary_data.stack = NULL;
> + __flush_dcache_area(&secondary_data, sizeof(secondary_data));
> status = READ_ONCE(secondary_data.status);
> if (ret && status) {
>
> --
> 2.11.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 07/13] dt-bindings: i2c: bcm2835: Add brcm,bcm2711 compatible
From: Rob Herring @ 2019-08-27 16:00 UTC (permalink / raw)
To: Stefan Wahren
Cc: devicetree, Florian Fainelli, Scott Branden, Wolfram Sang,
Ray Jui, Stefan Wahren, Eric Anholt, bcm-kernel-feedback-list,
linux-i2c, linux-clk, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <1565713248-4906-8-git-send-email-wahrenst@gmx.net>
On Tue, 13 Aug 2019 18:20:42 +0200, Stefan Wahren wrote:
> Add a new compatible for the BCM2711, which hasn't the clock stretch bug.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
> Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 03/13] dt-bindings: bcm2835-cprman: Add bcm2711 support
From: Rob Herring @ 2019-08-27 16:00 UTC (permalink / raw)
To: Stefan Wahren
Cc: devicetree, Florian Fainelli, Scott Branden, Wolfram Sang,
Ray Jui, Stefan Wahren, Eric Anholt, bcm-kernel-feedback-list,
linux-i2c, linux-clk, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <1565713248-4906-4-git-send-email-wahrenst@gmx.net>
On Tue, 13 Aug 2019 18:20:38 +0200, Stefan Wahren wrote:
> The new BCM2711 supports an additional clock for the emmc2 block.
> So we need an additional compatible.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> Acked-by: Eric Anholt <eric@anholt.net>
> ---
> Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt | 4 +++-
> include/dt-bindings/clock/bcm2835.h | 2 ++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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