* [PATCH 1/3] dt-bindings: i2c: bcm2835: Add brcm,bcm2711 compatible
From: Stefan Wahren @ 2019-08-27 17:04 UTC (permalink / raw)
To: Wolfram Sang, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden
Cc: linux-i2c, linux-arm-kernel, Stefan Wahren
In-Reply-To: <1566925456-5928-1-git-send-email-wahrenst@gmx.net>
Add a new compatible for the BCM2711, which hasn't the clock stretch bug.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
index e9de375..c9a6587 100644
--- a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
@@ -1,7 +1,9 @@
Broadcom BCM2835 I2C controller
Required properties:
-- compatible : Should be "brcm,bcm2835-i2c".
+- compatible : Should be one of:
+ "brcm,bcm2711-i2c"
+ "brcm,bcm2835-i2c"
- reg: Should contain register location and length.
- interrupts: Should contain interrupt.
- clocks : The clock feeding the I2C controller.
--
2.7.4
_______________________________________________
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 3/3] i2c: bcm2835: Add full name of devicetree node to adapter name
From: Stefan Wahren @ 2019-08-27 17:04 UTC (permalink / raw)
To: Wolfram Sang, Eric Anholt, Florian Fainelli, Ray Jui,
Scott Branden
Cc: linux-i2c, linux-arm-kernel, Stefan Wahren
In-Reply-To: <1566925456-5928-1-git-send-email-wahrenst@gmx.net>
Inspired by Lori Hikichi's patch for iproc, this adds the full name of
the devicetree node to the adapter name. With the introduction of
BCM2711 it's very difficult to distinguish between the multiple instances.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
drivers/i2c/busses/i2c-bcm2835.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index ab5502f..e01b2b5 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -472,7 +472,8 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
i2c_set_adapdata(adap, i2c_dev);
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DEPRECATED;
- strlcpy(adap->name, "bcm2835 I2C adapter", sizeof(adap->name));
+ snprintf(adap->name, sizeof(adap->name), "bcm2835 (%s)",
+ of_node_full_name(pdev->dev.of_node));
adap->algo = &bcm2835_i2c_algo;
adap->dev.parent = &pdev->dev;
adap->dev.of_node = pdev->dev.of_node;
--
2.7.4
_______________________________________________
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 V4 01/11] dt-bindings: firmware: imx-scu: new binding to parse clocks from device tree
From: Rob Herring @ 2019-08-27 17:04 UTC (permalink / raw)
To: Dong Aisheng
Cc: Dong Aisheng, devicetree, sboyd, mturquette, linux-imx, kernel,
fabio.estevam, shawnguo, linux-clk, linux-arm-kernel
In-Reply-To: <1566299605-15641-2-git-send-email-aisheng.dong@nxp.com>
On Tue, 20 Aug 2019 07:13:15 -0400, Dong Aisheng wrote:
> There's a few limitations on the original one cell clock binding
> (#clock-cells = <1>) that we have to define some SW clock IDs for device
> tree to reference. This may cause troubles if we want to use common
> clock IDs for multi platforms support when the clock of those platforms
> are mostly the same.
> e.g. Current clock IDs name are defined with SS prefix.
>
> However the device may reside in different SS across CPUs, that means the
> SS prefix may not valid anymore for a new SoC. Furthermore, the device
> availability of those clocks may also vary a bit.
>
> For such situation, we want to eliminate the using of SW Clock IDs and
> change to use a more close to HW one instead.
> For SCU clocks usage, only two params required: Resource id + Clock Type.
> Both parameters are platform independent. So we could use two cells binding
> to pass those parameters,
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> ChangeLog:
> v3->v4:
> * add some comments for various clock types
> v2->v3:
> * Changed to two cells binding and register all clocks in driver
> instead of parse from device tree.
> v1->v2:
> * changed to one cell binding inspired by arm,scpi.txt
> Documentation/devicetree/bindings/arm/arm,scpi.txt
> Resource ID is encoded in 'reg' property.
> Clock type is encoded in generic clock-indices property.
> Then we don't have to search all the DT nodes to fetch
> those two value to construct clocks which is relatively
> low efficiency.
> * Add required power-domain property as well.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 12 ++++++-----
> include/dt-bindings/firmware/imx/rsrc.h | 23 ++++++++++++++++++++++
> 2 files changed, 30 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
* [PATCH v3 4/4] aspeed/watchdog: Add access_cs0 option for alt-boot
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>
The option for the ast2400/2500 to get access to CS0 at runtime.
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
.../ABI/testing/sysfs-class-watchdog | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-watchdog b/Documentation/ABI/testing/sysfs-class-watchdog
index 6317ade5ad19..675f9b537661 100644
--- a/Documentation/ABI/testing/sysfs-class-watchdog
+++ b/Documentation/ABI/testing/sysfs-class-watchdog
@@ -72,3 +72,37 @@ Description:
It is a read/write file. When read, the currently assigned
pretimeout governor is returned. When written, it sets
the pretimeout governor.
+
+What: /sys/class/watchdog/watchdog1/access_cs0
+Date: August 2019
+Contact: Ivan Mikhaylov <i.mikhaylov@yadro.com>,
+ Alexander Amelkin <a.amelkin@yadro.com>
+Description:
+ It is a read/write file. This attribute exists only if the
+ system has booted from the alternate flash chip due to
+ expiration of a watchdog timer of AST2400/AST2500 when
+ alternate boot function was enabled with 'aspeed,alt-boot'
+ devicetree option for that watchdog or with an appropriate
+ h/w strapping (for WDT2 only).
+
+ At alternate flash the 'access_cs0' sysfs node provides:
+ ast2400: a way to get access to the primary SPI flash
+ chip at CS0 after booting from the alternate
+ chip at CS1.
+ ast2500: a way to restore the normal address mapping
+ from (CS0->CS1, CS1->CS0) to (CS0->CS0,
+ CS1->CS1).
+
+ Clearing the boot code selection and timeout counter also
+ resets to the initial state the chip select line mapping. When
+ the SoC is in normal mapping state (i.e. booted from CS0),
+ clearing those bits does nothing for both versions of the SoC.
+ For alternate boot mode (booted from CS1 due to wdt2
+ expiration) the behavior differs as described above.
+
+ This option can be used with wdt2 (watchdog1) only.
+
+ When read, the current status of the boot code selection is
+ shown. When written with any non-zero value, it clears
+ the boot code selection and the timeout counter, which results
+ in chipselect reset for AST2400/AST2500.
--
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 3/4] watchdog/aspeed: add support for dual boot
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>
Set WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION into WDT_CLEAR_TIMEOUT_STATUS
to clear out boot code source and re-enable access to the primary SPI flash
chip while booted via wdt2 from the alternate chip.
AST2400 datasheet says:
"In the 2nd flash booting mode, all the address mapping to CS0# would be
re-directed to CS1#. And CS0# is not accessable under this mode. To access
CS0#, firmware should clear the 2nd boot mode register in the WDT2 status
register WDT30.bit[1]."
Signed-off-by: Ivan Mikhaylov <i.mikhaylov@yadro.com>
---
drivers/watchdog/aspeed_wdt.c | 65 ++++++++++++++++++++++++++++++++++-
1 file changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
index cc71861e033a..d27030d766ed 100644
--- a/drivers/watchdog/aspeed_wdt.c
+++ b/drivers/watchdog/aspeed_wdt.c
@@ -53,6 +53,8 @@ MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
#define WDT_CTRL_ENABLE BIT(0)
#define WDT_TIMEOUT_STATUS 0x10
#define WDT_TIMEOUT_STATUS_BOOT_SECONDARY BIT(1)
+#define WDT_CLEAR_TIMEOUT_STATUS 0x14
+#define WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION BIT(0)
/*
* WDT_RESET_WIDTH controls the characteristics of the external pulse (if
@@ -165,6 +167,60 @@ static int aspeed_wdt_restart(struct watchdog_device *wdd,
return 0;
}
+/* access_cs0 shows if cs0 is accessible, hence the reverted bit */
+static ssize_t access_cs0_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct aspeed_wdt *wdt = dev_get_drvdata(dev);
+ uint32_t status = readl(wdt->base + WDT_TIMEOUT_STATUS);
+
+ return sprintf(buf, "%u\n",
+ !(status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY));
+}
+
+static ssize_t access_cs0_store(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t size)
+{
+ struct aspeed_wdt *wdt = dev_get_drvdata(dev);
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ if (val)
+ writel(WDT_CLEAR_TIMEOUT_AND_BOOT_CODE_SELECTION,
+ wdt->base + WDT_CLEAR_TIMEOUT_STATUS);
+
+ return size;
+}
+
+/*
+ * This attribute exists only if the system has booted from the alternate
+ * flash with 'alt-boot' option.
+ *
+ * At alternate flash the 'access_cs0' sysfs node provides:
+ * ast2400: a way to get access to the primary SPI flash chip at CS0
+ * after booting from the alternate chip at CS1.
+ * ast2500: a way to restore the normal address mapping from
+ * (CS0->CS1, CS1->CS0) to (CS0->CS0, CS1->CS1).
+ *
+ * Clearing the boot code selection and timeout counter also resets to the
+ * initial state the chip select line mapping. When the SoC is in normal
+ * mapping state (i.e. booted from CS0), clearing those bits does nothing for
+ * both versions of the SoC. For alternate boot mode (booted from CS1 due to
+ * wdt2 expiration) the behavior differs as described above.
+ *
+ * This option can be used with wdt2 (watchdog1) only.
+ */
+static DEVICE_ATTR_RW(access_cs0);
+
+static struct attribute *bswitch_attrs[] = {
+ &dev_attr_access_cs0.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(bswitch);
+
static const struct watchdog_ops aspeed_wdt_ops = {
.start = aspeed_wdt_start,
.stop = aspeed_wdt_stop,
@@ -306,9 +362,16 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
}
status = readl(wdt->base + WDT_TIMEOUT_STATUS);
- if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY)
+ if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
wdt->wdd.bootstatus = WDIOF_CARDRESET;
+ if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
+ of_device_is_compatible(np, "aspeed,ast2500-wdt"))
+ wdt->wdd.groups = bswitch_groups;
+ }
+
+ dev_set_drvdata(dev, wdt);
+
return devm_watchdog_register_device(dev, &wdt->wdd);
}
--
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 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
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