* [PATCH -next 01/12] crypto: artpec6 - use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:27 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190802132809.8116-1-yuehaibing@huawei.com>
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/crypto/axis/artpec6_crypto.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/axis/artpec6_crypto.c b/drivers/crypto/axis/artpec6_crypto.c
index 80fa04e..4b20606 100644
--- a/drivers/crypto/axis/artpec6_crypto.c
+++ b/drivers/crypto/axis/artpec6_crypto.c
@@ -2854,7 +2854,6 @@ static int artpec6_crypto_probe(struct platform_device *pdev)
struct artpec6_crypto *ac;
struct device *dev = &pdev->dev;
void __iomem *base;
- struct resource *res;
int irq;
int err;
@@ -2867,8 +2866,7 @@ static int artpec6_crypto_probe(struct platform_device *pdev)
variant = (enum artpec6_crypto_variant)match->data;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, res);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
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 -next 00/12] crypto: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:27 UTC (permalink / raw)
To: herbert, lars.persson, jesper.nilsson, davem, thomas.lendacky,
gary.hook, krzk, kgene, antoine.tenart, matthias.bgg, jamie,
agross, heiko, mcoquelin.stm32, alexandre.torgue, clabbe.montjoie,
mripard, wens
Cc: linux-samsung-soc, linux-arm-msm, YueHaibing, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-mediatek, linux-crypto,
linux-stm32, linux-arm-kernel
devm_platform_ioremap_resource() internally have platform_get_resource()
and devm_ioremap_resource() in it. So instead of calling them separately
use devm_platform_ioremap_resource() directly.
YueHaibing (12):
crypto: artpec6 - use devm_platform_ioremap_resource() to simplify
code
crypto: ccp - use devm_platform_ioremap_resource() to simplify code
crypto: exynos - use devm_platform_ioremap_resource() to simplify code
crypto: img-hash - use devm_platform_ioremap_resource() to simplify
code
crypto: inside-secure - use devm_platform_ioremap_resource() to
simplify code
crypto: mediatek - use devm_platform_ioremap_resource() to simplify
code
crypto: picoxcell - use devm_platform_ioremap_resource() to simplify
code
crypto: sunxi-ss - use devm_platform_ioremap_resource() to simplify
code
crypto: rockchip - use devm_platform_ioremap_resource() to simplify
code
crypto: stm32 - use devm_platform_ioremap_resource() to simplify code
crypto: qce - use devm_platform_ioremap_resource() to simplify code
crypto: qcom-rng - use devm_platform_ioremap_resource() to simplify
code
drivers/crypto/axis/artpec6_crypto.c | 4 +---
drivers/crypto/ccp/sp-platform.c | 4 +---
drivers/crypto/exynos-rng.c | 4 +---
drivers/crypto/img-hash.c | 4 +---
drivers/crypto/inside-secure/safexcel.c | 4 +---
drivers/crypto/mediatek/mtk-platform.c | 3 +--
drivers/crypto/picoxcell_crypto.c | 5 ++---
drivers/crypto/qce/core.c | 4 +---
drivers/crypto/qcom-rng.c | 4 +---
drivers/crypto/rockchip/rk3288_crypto.c | 4 +---
drivers/crypto/stm32/stm32-crc32.c | 4 +---
drivers/crypto/stm32/stm32-cryp.c | 4 +---
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 4 +---
13 files changed, 14 insertions(+), 38 deletions(-)
--
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
* Re: [PATCH v3 04/10] dt-bindings: mfd: Add compatible for the MediaTek MT6358 PMIC
From: Hsin-hsiung Wang @ 2019-08-02 13:28 UTC (permalink / raw)
To: Nicolas Boichat
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Sean Wang, Liam Girdwood, Rob Herring, lkml,
Mark Brown, moderated list:ARM/Mediatek SoC support,
Matthias Brugger, Eddie Huang, Lee Jones, linux-arm Mailing List,
linux-rtc
In-Reply-To: <CANMq1KCiK69kXkpagccqd1=pKOs7qOOVuJUaCe5JfoGVmPt7mg@mail.gmail.com>
Hi Nicolas,
On Tue, 2019-05-07 at 14:24 +0900, Nicolas Boichat wrote:
> On Fri, May 3, 2019 at 6:34 PM Hsin-Hsiung Wang
> <hsin-hsiung.wang@mediatek.com> wrote:
> >
...
> > This adds compatible for the MediaTek MT6358 PMIC.
> >
> > Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
> > ---
> > Documentation/devicetree/bindings/mfd/mt6397.txt | 11 ++++++++---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > index 0ebd08af777d..62f1c17c7738 100644
> > --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> > +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> > @@ -17,22 +17,27 @@ Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> > This document describes the binding for MFD device and its sub module.
> >
> > Required properties:
> > -compatible: "mediatek,mt6397" or "mediatek,mt6323"
> > +compatible:
> > + "mediatek,mt6323" for PMIC MT6323
> > + "mediatek,mt6358" for PMIC MT6358
> > + "mediatek,mt6397" for PMIC MT6397
> >
> > Optional subnodes:
> >
> > - rtc
> > Required properties:
> > - - compatible: "mediatek,mt6397-rtc"
> > + - compatible: "mediatek,mt6397-rtc" or "mediatek,mt6358-rtc"
> > - regulators
> > Required properties:
> > - compatible: "mediatek,mt6397-regulator"
> > see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> > + - compatible: "mediatek,mt6358-regulator"
> > + see Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> > - compatible: "mediatek,mt6323-regulator"
> > see Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> > - codec
> > Required properties:
> > - - compatible: "mediatek,mt6397-codec"
> > + - compatible: "mediatek,mt6397-codec" or "mediatek,mt6358-sound"
>
> Sean had a question about this
> (https://patchwork.kernel.org/patch/10846669/#22524299):
> "why didn't we use a more consistent naming as mt6358-codec?"
>
The compatible name, "mediatek,mt6358-sound", is already in mt6358 audio
driver which is already in the upstream codebase.
After discussing with audio owner, we will submit another patch to fix
it.
Thanks.
> > - clk
> > Required properties:
> > - compatible: "mediatek,mt6397-clk"
> > --
> > 2.18.0
> >
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH AUTOSEL 4.19 33/42] ARM: dts: bcm: bcm47094: add missing #cells for mdio-bus-mux
From: Sasha Levin @ 2019-08-02 13:22 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Olof Johansson, Sasha Levin, linux-arm-kernel, Arnd Bergmann,
devicetree
In-Reply-To: <20190802132302.13537-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 3a9d2569e45cb02769cda26fee4a02126867c934 ]
The mdio-bus-mux has no #address-cells/#size-cells property,
which causes a few dtc warnings:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
Add the normal cell numbers.
Link: https://lore.kernel.org/r/20190722145618.1155492-1-arnd@arndb.de
Fixes: 2bebdfcdcd0f ("ARM: dts: BCM5301X: Add support for Linksys EA9500")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index 36efe410dcd71..9e33c41f54112 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -125,6 +125,9 @@
};
mdio-bus-mux {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
/* BIT(9) = 1 => external mdio */
mdio_ext: mdio@200 {
reg = <0x200>;
--
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 AUTOSEL 5.2 63/76] ARM: dts: bcm: bcm47094: add missing #cells for mdio-bus-mux
From: Sasha Levin @ 2019-08-02 13:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Olof Johansson, Sasha Levin, linux-arm-kernel, Arnd Bergmann,
devicetree
In-Reply-To: <20190802131951.11600-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 3a9d2569e45cb02769cda26fee4a02126867c934 ]
The mdio-bus-mux has no #address-cells/#size-cells property,
which causes a few dtc warnings:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
Add the normal cell numbers.
Link: https://lore.kernel.org/r/20190722145618.1155492-1-arnd@arndb.de
Fixes: 2bebdfcdcd0f ("ARM: dts: BCM5301X: Add support for Linksys EA9500")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index 5fd47eec4407e..1679959a3654d 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -126,6 +126,9 @@
};
mdio-bus-mux {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
/* BIT(9) = 1 => external mdio */
mdio_ext: mdio@200 {
reg = <0x200>;
--
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 v4 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
From: Robert Richter @ 2019-08-02 13:05 UTC (permalink / raw)
To: Jeremy Linton
Cc: lorenzo.pieralisi, catalin.marinas, rjw, linux-acpi, sudeep.holla,
will, linux-arm-kernel, lenb
In-Reply-To: <20190801034634.26913-2-jeremy.linton@arm.com>
On 31.07.19 22:46:33, Jeremy Linton wrote:
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 9426b9aaed86..9d0e20a2ac83 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -1302,11 +1302,16 @@ static inline int lpit_read_residency_count_address(u64 *address)
> #endif
>
> #ifdef CONFIG_ACPI_PPTT
> +int acpi_pptt_cpu_is_thread(unsigned int cpu);
> int find_acpi_cpu_topology(unsigned int cpu, int level);
> int find_acpi_cpu_topology_package(unsigned int cpu);
> int find_acpi_cpu_topology_hetero_id(unsigned int cpu);
> int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
All those functions (exept hetero_id) are used only in
parse_acpi_topology(). So how about creating a struct with thread_id,
core_id, and cache_id (and hetero_id (?)) and have a single pptt table
parsing function that fills in all of this into that struct? This
simplifies the api and also the code.
This also shows that hetid (see arm_pmu_acpi.c) better should be
stored in cpu_topology[] too and thus being parsed with the other
parameters as well and made accessible from there by a helper.
-Robert
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] usb: dwc3: meson-g12a: use devm_platform_ioremap_resource() to simplify code
From: YueHaibing @ 2019-08-02 13:04 UTC (permalink / raw)
To: balbi, gregkh, khilman, narmstrong
Cc: linux-amlogic, linux-usb, YueHaibing, linux-kernel,
linux-arm-kernel
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/usb/dwc3/dwc3-meson-g12a.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c
index bca7e92..d73ccd9 100644
--- a/drivers/usb/dwc3/dwc3-meson-g12a.c
+++ b/drivers/usb/dwc3/dwc3-meson-g12a.c
@@ -386,7 +386,6 @@ static int dwc3_meson_g12a_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
void __iomem *base;
- struct resource *res;
enum phy_mode otg_id;
int ret, i, irq;
@@ -394,8 +393,7 @@ static int dwc3_meson_g12a_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(dev, res);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
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: next/master boot: 265 boots: 17 failed, 184 passed with 64 offline (next-20190730)
From: Neil Armstrong @ 2019-08-02 13:03 UTC (permalink / raw)
To: Mark Brown, khilman
Cc: linux-oxnas, linux-next, linux-arm-kernel, kernel-build-reports
In-Reply-To: <20190730123425.GB4264@sirena.org.uk>
[-- Attachment #1.1.1: Type: text/plain, Size: 1731 bytes --]
Hi Mark,
On 30/07/2019 14:34, Mark Brown wrote:
> On Tue, Jul 30, 2019 at 05:17:56AM -0700, kernelci.org bot wrote:
>
>> Boot Failures Detected:
>>
>> arm:
>> oxnas_v6_defconfig:
>> gcc-8:
>> ox820-cloudengines-pogoplug-series-3: 1 failed lab
>
> For some time now -next and mainline have been failing to boot on
> Pogoplug 3 with the oxnas_v6_defconfig, the kernel seems to start fine
> but fails to parse the ramdisk it's passed:
>
> 08:50:02.086589 <6>[ 7.719854] IP-Config: Complete:
> 08:50:02.087213 <6>[ 7.723330] device=eth0, hwaddr=0a:a2:89:27:10:1b, ipaddr=10.201.4.144, mask=255.255.0.0, gw=10.201.0.1
> 08:50:02.087413 <6>[ 7.733409] host=10.201.4.144, domain=, nis-domain=(none)
> 08:50:02.088056 <6>[ 7.739499] bootserver=10.201.1.1, rootserver=10.201.1.1, rootpath=
> 08:50:02.088248 <6>[ 7.739504] nameserver0=10.201.1.1
> 08:50:02.129966 <5>[ 7.752025] RAMDISK: Couldn't find valid RAM disk image starting at 0.
> 08:50:02.130381 <4>[ 7.759616] List of all partitions:
> 08:50:02.131333 <4>[ 7.763363] 0100 65536 ram0
>
> Possibly an issue with the ramdisk getting overwritten or something?
Thanks for reporting, it's my suspicion since my multiple bisect runs all point to
this merge commit :
a318423b61e8 Merge tag 'upstream-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs
This merge doesn't introduce notable changes for the oxnas_v6_defconfig, but disabling UBI entirely makes
it work again.
Continuing my investigations...
Neil
>
> Full details for today's -next can be seen here:
>
> https://kernelci.org/boot/id/5d4004bb59b51489d631b28d/
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] tracing: Function stack size and its name mismatch in arm64
From: Steven Rostedt @ 2019-08-02 13:03 UTC (permalink / raw)
To: Jiping Ma
Cc: catalin.marinas, will.deacon, linux-kernel, mingo, joel,
Will Deacon, linux-arm-kernel
In-Reply-To: <47e90170-e971-c2f5-b6c9-d3c6a694a4a7@windriver.com>
On Fri, 2 Aug 2019 10:43:03 +0800
Jiping Ma <Jiping.Ma2@windriver.com> wrote:
> > *Why* does the frame appear to be off-by-one?
> Because the PC is LR in ARM64 stack actually. Following is ARM64 stack
> layout. Please refer to the figure 3 in
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf
> LR
> FP
> ......
> LR
> FP
And the LR holds the return address, right? Which would be identical to
x86 and every other arch I know about.
-- Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/2] arm64: Document ICC_CTLR_EL3.PMHE setting requirements
From: Marc Zyngier @ 2019-08-02 12:52 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Suzuki K Poulose, maz, James Morse, linux-arm-kernel,
huawei.libin, guohanjun, liwei391, Julien Thierry
In-Reply-To: <20190802125208.73162-1-maz@kernel.org>
It goes without saying, but better saying it: the kernel expects
ICC_CTLR_EL3.PMHE to have the same value across all CPUs, and
for that setting not to change during the lifetime of the kernel.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
Documentation/arm64/booting.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst
index d3f3a60fbf25..5d78a6f5b0ae 100644
--- a/Documentation/arm64/booting.rst
+++ b/Documentation/arm64/booting.rst
@@ -213,6 +213,9 @@ Before jumping into the kernel, the following conditions must be met:
- ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
- ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
+ - ICC_CTLR_EL3.PMHE (bit 6) must be set to the same value across
+ all CPUs the kernel is executing on, and must stay constant
+ for the lifetime of the kernel.
- If the kernel is entered at EL1:
--
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 v2 1/2] arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear
From: Marc Zyngier @ 2019-08-02 12:52 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Will Deacon, Suzuki K Poulose, maz, James Morse, linux-arm-kernel,
huawei.libin, guohanjun, liwei391, Julien Thierry
In-Reply-To: <20190802125208.73162-1-maz@kernel.org>
From: Marc Zyngier <marc.zyngier@arm.com>
The GICv3 architecture specification is incredibly misleading when it
comes to PMR and the requirement for a DSB. It turns out that this DSB
is only required if the CPU interface sends an Upstream Control
message to the redistributor in order to update the RD's view of PMR.
This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't
the case in Linux. It can still be set from EL3, so some special care
is required. But the upshot is that in the (hopefuly large) majority
of the cases, we can drop the DSB altogether.
This relies on a new static key being set if the boot CPU has PMHE
set. The drawback is that this static key has to be exported to
modules.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm64/include/asm/barrier.h | 12 ++++++++++++
arch/arm64/include/asm/daifflags.h | 3 ++-
arch/arm64/include/asm/irqflags.h | 19 ++++++++++---------
arch/arm64/include/asm/kvm_host.h | 3 +--
arch/arm64/kernel/entry.S | 6 ++++--
arch/arm64/kvm/hyp/switch.c | 4 ++--
drivers/irqchip/irq-gic-v3.c | 17 +++++++++++++++++
include/linux/irqchip/arm-gic-v3.h | 2 ++
8 files changed, 50 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index e0e2b1946f42..7d9cc5ec4971 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -29,6 +29,18 @@
SB_BARRIER_INSN"nop\n", \
ARM64_HAS_SB))
+#ifdef CONFIG_ARM64_PSEUDO_NMI
+#define pmr_sync() \
+ do { \
+ extern struct static_key_false gic_pmr_sync; \
+ \
+ if (static_branch_unlikely(&gic_pmr_sync)) \
+ dsb(sy); \
+ } while(0)
+#else
+#define pmr_sync() do {} while (0)
+#endif
+
#define mb() dsb(sy)
#define rmb() dsb(ld)
#define wmb() dsb(st)
diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
index 987926ed535e..00b16793505a 100644
--- a/arch/arm64/include/asm/daifflags.h
+++ b/arch/arm64/include/asm/daifflags.h
@@ -8,6 +8,7 @@
#include <linux/irqflags.h>
#include <asm/arch_gicv3.h>
+#include <asm/barrier.h>
#include <asm/cpufeature.h>
#define DAIF_PROCCTX 0
@@ -63,7 +64,7 @@ static inline void local_daif_restore(unsigned long flags)
if (system_uses_irq_prio_masking()) {
gic_write_pmr(GIC_PRIO_IRQON);
- dsb(sy);
+ pmr_sync();
}
} else if (system_uses_irq_prio_masking()) {
u64 pmr;
diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
index 7872f260c9ee..a5e7115d2f93 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -8,6 +8,7 @@
#ifdef __KERNEL__
#include <asm/alternative.h>
+#include <asm/barrier.h>
#include <asm/ptrace.h>
#include <asm/sysreg.h>
@@ -36,14 +37,14 @@ static inline void arch_local_irq_enable(void)
}
asm volatile(ALTERNATIVE(
- "msr daifclr, #2 // arch_local_irq_enable\n"
- "nop",
- __msr_s(SYS_ICC_PMR_EL1, "%0")
- "dsb sy",
+ "msr daifclr, #2 // arch_local_irq_enable",
+ __msr_s(SYS_ICC_PMR_EL1, "%0"),
ARM64_HAS_IRQ_PRIO_MASKING)
:
: "r" ((unsigned long) GIC_PRIO_IRQON)
: "memory");
+
+ pmr_sync();
}
static inline void arch_local_irq_disable(void)
@@ -118,14 +119,14 @@ static inline unsigned long arch_local_irq_save(void)
static inline void arch_local_irq_restore(unsigned long flags)
{
asm volatile(ALTERNATIVE(
- "msr daif, %0\n"
- "nop",
- __msr_s(SYS_ICC_PMR_EL1, "%0")
- "dsb sy",
- ARM64_HAS_IRQ_PRIO_MASKING)
+ "msr daif, %0",
+ __msr_s(SYS_ICC_PMR_EL1, "%0"),
+ ARM64_HAS_IRQ_PRIO_MASKING)
:
: "r" (flags)
: "memory");
+
+ pmr_sync();
}
#endif
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index f656169db8c3..5ecb091c8576 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -600,8 +600,7 @@ static inline void kvm_arm_vhe_guest_enter(void)
* local_daif_mask() already sets GIC_PRIO_PSR_I_SET, we just need a
* dsb to ensure the redistributor is forwards EL2 IRQs to the CPU.
*/
- if (system_uses_irq_prio_masking())
- dsb(sy);
+ pmr_sync();
}
static inline void kvm_arm_vhe_guest_exit(void)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 9cdc4592da3e..6803dd5b4256 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -269,8 +269,10 @@ alternative_else_nop_endif
alternative_if ARM64_HAS_IRQ_PRIO_MASKING
ldr x20, [sp, #S_PMR_SAVE]
msr_s SYS_ICC_PMR_EL1, x20
- /* Ensure priority change is seen by redistributor */
- dsb sy
+ mrs_s x21, SYS_ICC_CTLR_EL1
+ tbz x21, #6, .L__skip_pmr_sync\@ // Check for ICC_CTLR_EL1.PMHE
+ dsb sy // Ensure priority change is seen by redistributor
+.L__skip_pmr_sync\@:
alternative_else_nop_endif
ldp x21, x22, [sp, #S_PC] // load ELR, SPSR
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index adaf266d8de8..eb131e09d207 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -12,7 +12,7 @@
#include <kvm/arm_psci.h>
-#include <asm/arch_gicv3.h>
+#include <asm/barrier.h>
#include <asm/cpufeature.h>
#include <asm/kprobes.h>
#include <asm/kvm_asm.h>
@@ -605,7 +605,7 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
*/
if (system_uses_irq_prio_masking()) {
gic_write_pmr(GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET);
- dsb(sy);
+ pmr_sync();
}
vcpu = kern_hyp_va(vcpu);
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 005b70e398b8..38fcb7eebdde 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -87,6 +87,15 @@ static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
*/
static DEFINE_STATIC_KEY_FALSE(supports_pseudo_nmis);
+/*
+ * Global static key controlling whether an update to PMR allowing more
+ * interrupts requires to be propagated to the redistributor (DSB SY).
+ * And this needs to be exported for modules to be able to enable
+ * interrupts...
+ */
+DEFINE_STATIC_KEY_FALSE(gic_pmr_sync);
+EXPORT_SYMBOL(gic_pmr_sync);
+
/* ppi_nmi_refs[n] == number of cpus having ppi[n + 16] set as NMI */
static refcount_t *ppi_nmi_refs;
@@ -1494,6 +1503,14 @@ static void gic_enable_nmi_support(void)
for (i = 0; i < gic_data.ppi_nr; i++)
refcount_set(&ppi_nmi_refs[i], 0);
+ /*
+ * Linux itself doesn't use 1:N distribution, so has no need to
+ * set PMHE. The only reason to have it set is if EL3 requires it
+ * (and we can't change it).
+ */
+ if (read_sysreg_s(SYS_ICC_CTLR_EL1) & ICC_CTLR_EL1_PMHE_MASK)
+ static_branch_enable(&gic_pmr_sync);
+
static_branch_enable(&supports_pseudo_nmis);
if (static_branch_likely(&supports_deactivate_key))
diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
index 5cc10cf7cb3e..a0bde9e12efa 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -487,6 +487,8 @@
#define ICC_CTLR_EL1_EOImode_MASK (1 << ICC_CTLR_EL1_EOImode_SHIFT)
#define ICC_CTLR_EL1_CBPR_SHIFT 0
#define ICC_CTLR_EL1_CBPR_MASK (1 << ICC_CTLR_EL1_CBPR_SHIFT)
+#define ICC_CTLR_EL1_PMHE_SHIFT 6
+#define ICC_CTLR_EL1_PMHE_MASK (1 << ICC_CTLR_EL1_PMHE_SHIFT)
#define ICC_CTLR_EL1_PRI_BITS_SHIFT 8
#define ICC_CTLR_EL1_PRI_BITS_MASK (0x7 << ICC_CTLR_EL1_PRI_BITS_SHIFT)
#define ICC_CTLR_EL1_ID_BITS_SHIFT 11
--
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 v2 0/2] arm64: Relax ICC_PMR_EL1 synchronisation when possible
From: Marc Zyngier @ 2019-08-02 12:52 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Suzuki K Poulose, maz, James Morse, linux-arm-kernel,
huawei.libin, guohanjun, liwei391, Julien Thierry
This is an update on [1] after Will's comments, turning the original
kernel patching into a static key. An additional patch now documents
the expectations of having ICC_CTLR_EL3.PMHE set to something
consistent across CPUs and over time.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2019-July/669756.html
Marc Zyngier (2):
arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear
arm64: Document ICC_CTLR_EL3.PMHE setting requirements
Documentation/arm64/booting.rst | 3 +++
arch/arm64/include/asm/barrier.h | 12 ++++++++++++
arch/arm64/include/asm/daifflags.h | 3 ++-
arch/arm64/include/asm/irqflags.h | 19 ++++++++++---------
arch/arm64/include/asm/kvm_host.h | 3 +--
arch/arm64/kernel/entry.S | 6 ++++--
arch/arm64/kvm/hyp/switch.c | 4 ++--
drivers/irqchip/irq-gic-v3.c | 17 +++++++++++++++++
include/linux/irqchip/arm-gic-v3.h | 2 ++
9 files changed, 53 insertions(+), 16 deletions(-)
--
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 v2] arm64: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Martin Ayotte @ 2019-08-02 12:45 UTC (permalink / raw)
To: 'Sunil Mohan Adapa', 'Chen-Yu Tsai'
Cc: 'Maxime Ripard', 'linux-arm-kernel'
In-Reply-To: <fd19b2e3-e340-f4fd-a320-1cfc45964f5b@medhas.org>
> gmai.com is likely a typo.
Right !
Signed-off-by: Martin Ayotte <martinayotte@gmail.com>
Tested-by: Martin Ayotte <martinayotte@gmail.com>
-----Message d'origine-----
De : Sunil Mohan Adapa [mailto:sunil@medhas.org]
Envoyé : Thursday, August 01, 2019 2:48 PM
À : Martin Ayotte; Chen-Yu Tsai
Cc : linux-arm-kernel; Maxime Ripard
Objet : Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on
A64-OLinuXino
On 01/08/19 6:49 am, Martin Ayotte wrote:
> If my SOB could help here, I don't mind since I've done the commit
> more than a year ago for Armbian ...
>
> Signed-off-by: Martin Ayotte <martinayotte@gmai.com>
> Tested-by: Martin Ayotte <martinayotte@gmai.com>
gmai.com is likely a typo.
> On Wed, Jul 31, 2019 at 10:42 PM Chen-Yu Tsai <wens@csie.org
>
>> Thanks. The patch looks good overall. The authorship is a little
>> confusing though. If it was initially done by Martin (CC-ed), then
>> he should be the author, and we should get his Signed-off-by if
>> possible.
Martin is indeed the original author of the patch. Thank you for reviewing.
--
Sunil
_______________________________________________
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/2] arm64: entry: Move ct_user_exit before we can take another exception
From: James Morse @ 2019-08-02 12:43 UTC (permalink / raw)
To: Will Deacon; +Cc: Catalin Marinas, Masami Hiramatsu, linux-arm-kernel
In-Reply-To: <20190801163919.jlpvy47pknqx75ze@willie-the-truck>
Hi Will,
On 01/08/2019 17:39, Will Deacon wrote:
> On Thu, Aug 01, 2019 at 04:41:50PM +0100, James Morse wrote:
>> When taking an exception from EL0 we unmask exceptions before calling
>> ct_user_exit. This means we could take an interrupt or be single-stepped
>> in the gap. The entry from EL1 code sees that we took an exception from
>> the kernel, whereas the context_tracking code believes we are still in
>> user-space.
>>
>> To keep these things consistent, move the ct_user_exit calls before
>> any unmask of exceptions.
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index 28681034d599..88f4ab21cb66 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -792,8 +792,8 @@ el0_cp15:
>> /*
>> * Trapped CP15 (MRC, MCR, MRRC, MCRR) instructions
>> */
>> - enable_daif
>> ct_user_exit
>> + enable_daif
>> mov x0, x25
>> mov x1, sp
>> bl do_cp15instr
>> @@ -805,8 +805,8 @@ el0_da:
>> * Data abort handling
>> */
>> mrs x26, far_el1
>> - enable_daif
>> ct_user_exit
>> + enable_daif
> This strikes me as a bit dodgy, since we end up in context_tracking_exit(),
> which calls local_irq_{save,restore}() and I think our accounting is
> probably off at this point.
Huh, I'm sure I had all those options turned on...
~
local_irq_save() calls trace_hardirqs_off() unconditionally, whereas local_irq_restore()
uses the saved flags to decide interrupts aren't enabled by this restore call, so the
accounting ends up being correct. It calls trace_hardirqs_off() a second time.
The asserts check trace_hardirqs_off() is called with interrupts masked, which it is in
this case.
> I think we need to call via
> user_{enter,exit}_irqoff() instead to make this work.
Sure, that would be clearer.
Thanks,
James
_______________________________________________
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 00/34] put_user_pages(): miscellaneous call sites
From: Jan Kara @ 2019-08-02 12:41 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, Dan Williams, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, John Hubbard, intel-gfx,
john.hubbard, linux-block, Jérôme Glisse,
linux-rpi-kernel, ceph-devel, linux-arm-kernel, linux-nfs, netdev,
LKML, linux-xfs, linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <20190802091244.GD6461@dhcp22.suse.cz>
On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> On Thu 01-08-19 19:19:31, john.hubbard@gmail.com wrote:
> [...]
> > 2) Convert all of the call sites for get_user_pages*(), to
> > invoke put_user_page*(), instead of put_page(). This involves dozens of
> > call sites, and will take some time.
>
> How do we make sure this is the case and it will remain the case in the
> future? There must be some automagic to enforce/check that. It is simply
> not manageable to do it every now and then because then 3) will simply
> be never safe.
>
> Have you considered coccinele or some other scripted way to do the
> transition? I have no idea how to deal with future changes that would
> break the balance though.
Yeah, that's why I've been suggesting at LSF/MM that we may need to create
a gup wrapper - say vaddr_pin_pages() - and track which sites dropping
references got converted by using this wrapper instead of gup. The
counterpart would then be more logically named as unpin_page() or whatever
instead of put_user_page(). Sure this is not completely foolproof (you can
create new callsite using vaddr_pin_pages() and then just drop refs using
put_page()) but I suppose it would be a high enough barrier for missed
conversions... Thoughts?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
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 4/4] serial: 8250: Don't check for mctrl_gpio_init() returning -ENOSYS
From: Greg Kroah-Hartman @ 2019-08-02 12:26 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, Schrempf Frieder, linux-imx@nxp.com,
kernel@pengutronix.de, Jiri Slaby, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802121555.dl6rpjphgaxdvcke@pengutronix.de>
On Fri, Aug 02, 2019 at 02:15:55PM +0200, Uwe Kleine-König wrote:
> On Fri, Aug 02, 2019 at 10:04:11AM +0000, Schrempf Frieder wrote:
> > From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >
> > Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
> > if CONFIG_GPIOLIB is disabled, we can safely remove this check.
> >
> > Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> @greg: This patch doesn't depend on patch 2; ditto for patch 3. So only
> taking patches 1, 3 and 4 should be fine. This way Frieder's v4 only
> have to care for patch 2. (Assuming noone objects to 1, 3 and 4 of
> course.)
Sounds good, I'll do that, thanks.
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: defconfig: CONFIG_DRM_ETNAVIV=m
From: Christian Gmeiner @ 2019-08-02 12:20 UTC (permalink / raw)
To: linux-kernel
Cc: Anson Huang, Maxime Ripard, Catalin Marinas, etnaviv,
Bjorn Andersson, Marcin Juszkiewicz, Dinh Nguyen,
Christian Gmeiner, Jagan Teki, Simon Horman, Olof Johansson,
Shawn Guo, Leonard Crestez, Will Deacon, linux-arm-kernel
For imx8 we want to enable etnaviv, let's enable it
in defconfig, it will be useful to have it enabled for KernelCI
boot and runtime testing.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0e58ef02880c..ae5bbbce8a30 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -531,6 +531,7 @@ CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_SII902X=m
CONFIG_DRM_I2C_ADV7511=m
CONFIG_DRM_VC4=m
+CONFIG_DRM_ETNAVIV=m
CONFIG_DRM_HISI_HIBMC=m
CONFIG_DRM_HISI_KIRIN=m
CONFIG_DRM_MESON=m
--
2.21.0
_______________________________________________
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 v3 4/4] serial: 8250: Don't check for mctrl_gpio_init() returning -ENOSYS
From: Uwe Kleine-König @ 2019-08-02 12:15 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802100349.8659-4-frieder.schrempf@kontron.de>
On Fri, Aug 02, 2019 at 10:04:11AM +0000, Schrempf Frieder wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
> if CONFIG_GPIOLIB is disabled, we can safely remove this check.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
@greg: This patch doesn't depend on patch 2; ditto for patch 3. So only
taking patches 1, 3 and 4 should be fine. This way Frieder's v4 only
have to care for patch 2. (Assuming noone objects to 1, 3 and 4 of
course.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 3/4] serial: sh-sci: Don't check for mctrl_gpio_init() returning -ENOSYS
From: Uwe Kleine-König @ 2019-08-02 12:13 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802100349.8659-3-frieder.schrempf@kontron.de>
On Fri, Aug 02, 2019 at 10:04:10AM +0000, Schrempf Frieder wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
> if CONFIG_GPIOLIB is disabled, we can safely remove this check.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 2/4] serial: mctrl_gpio: Add a NULL check to mctrl_gpio_to_gpiod()
From: Uwe Kleine-König @ 2019-08-02 12:12 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802100349.8659-2-frieder.schrempf@kontron.de>
On Fri, Aug 02, 2019 at 10:04:10AM +0000, Schrempf Frieder wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> As it is allowed to use the mctrl_gpio_* functions before
> initialization (as the 8250 driver does according to 434be0ae7aa7),
Actually I was surprised some time ago that 8250 used serial_mctrl
without first initializing it and expecting it to work. I didn't look in
detail, but I wouldn't go so far to call this "allowed". The commit
itself calls it "workaround" which seems a better match.
> it seems appropriate to have a NULL check in all of the functions.
> Otherwise the mctrl_gpio_to_gpiod() function is prone to be used
> in a context that can lead to a NULL pointer dereference.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 1/4] serial: mctrl_gpio: Avoid probe failures in case of missing gpiolib
From: Uwe Kleine-König @ 2019-08-02 12:08 UTC (permalink / raw)
To: Schrempf Frieder
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190802100349.8659-1-frieder.schrempf@kontron.de>
On Fri, Aug 02, 2019 at 10:04:09AM +0000, Schrempf Frieder wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
> mctrl_gpio_init_noauto() will currently return an error pointer with
> -ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
> check for this condition to allow continue probing.
>
> To avoid the need for this check in each driver, we return NULL
> instead, as all the mctrl_gpio_*() functions are skipped anyway.
> We also adapt mctrl_gpio_to_gpiod() to be in line with this change.
>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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 V13 12/12] PCI: tegra: Add Tegra194 PCIe support
From: Vidya Sagar @ 2019-08-02 12:06 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: mark.rutland, devicetree, mperttunen, mmaddireddy, linux-pci,
catalin.marinas, will.deacon, linux-kernel, kthota, kishon,
linux-tegra, robh+dt, thierry.reding, gustavo.pimentel,
jingoohan1, bhelgaas, digetx, jonathanh, linux-arm-kernel,
sagar.tv
In-Reply-To: <20190730154939.GA367@e121166-lin.cambridge.arm.com>
On 7/30/2019 9:19 PM, Lorenzo Pieralisi wrote:
> On Tue, Jul 23, 2019 at 08:14:08PM +0530, Vidya Sagar wrote:
>> On 7/16/2019 4:52 PM, Lorenzo Pieralisi wrote:
>>> On Sat, Jul 13, 2019 at 12:34:34PM +0530, Vidya Sagar wrote:
>>>
>>> [...]
>>>
>>>>>>>> +static int tegra_pcie_bpmp_set_ctrl_state(struct tegra_pcie_dw *pcie,
>>>>>>>> + bool enable)
>>>>>>>> +{
>>>>>>>> + struct mrq_uphy_response resp;
>>>>>>>> + struct tegra_bpmp_message msg;
>>>>>>>> + struct mrq_uphy_request req;
>>>>>>>> + int err;
>>>>>>>> +
>>>>>>>> + if (pcie->cid == 5)
>>>>>>>> + return 0;
>>>>>>>
>>>>>>> What's wrong with cid == 5 ? Explain please.
>>>>>> Controller with ID=5 doesn't need any programming to enable it which is
>>>>>> done here through calling firmware API.
>>>>>>
>>>>>>>
>>>>>>>> + memset(&req, 0, sizeof(req));
>>>>>>>> + memset(&resp, 0, sizeof(resp));
>>>>>>>> +
>>>>>>>> + req.cmd = CMD_UPHY_PCIE_CONTROLLER_STATE;
>>>>>>>> + req.controller_state.pcie_controller = pcie->cid;
>>>>>>>> + req.controller_state.enable = enable;
>>>>>>>> +
>>>>>>>> + memset(&msg, 0, sizeof(msg));
>>>>>>>> + msg.mrq = MRQ_UPHY;
>>>>>>>> + msg.tx.data = &req;
>>>>>>>> + msg.tx.size = sizeof(req);
>>>>>>>> + msg.rx.data = &resp;
>>>>>>>> + msg.rx.size = sizeof(resp);
>>>>>>>> +
>>>>>>>> + if (irqs_disabled())
>>>>>>>
>>>>>>> Can you explain to me what this check is meant to achieve please ?
>>>>>> Firmware interface provides different APIs to be called when there are
>>>>>> no interrupts enabled in the system (noirq context) and otherwise
>>>>>> hence checking that situation here and calling appropriate API.
>>>>>
>>>>> That's what I am questioning. Being called from {suspend/resume}_noirq()
>>>>> callbacks (if that's the code path this check caters for) does not mean
>>>>> irqs_disabled() == true.
>>>> Agree.
>>>> Actually, I got a hint of having this check from the following.
>>>> Both tegra_bpmp_transfer_atomic() and tegra_bpmp_transfer() are indirectly
>>>> called by APIs registered with .master_xfer() and .master_xfer_atomic() hooks of
>>>> struct i2c_algorithm and the decision to call which one of these is made using the
>>>> following check in i2c-core.h file.
>>>> static inline bool i2c_in_atomic_xfer_mode(void)
>>>> {
>>>> return system_state > SYSTEM_RUNNING && irqs_disabled();
>>>> }
>>>> I think I should use this condition as is IIUC.
>>>> Please let me know if there are any concerns with this.
>>>
>>> It is not a concern, it is just that I don't understand how this code
>>> can be called with IRQs disabled, if you can give me an execution path I
>>> am happy to leave the check there. On top of that, when called from
>>> suspend NOIRQ context, it is likely to use the blocking API (because
>>> IRQs aren't disabled at CPU level) behind which there is most certainly
>>> an IRQ required to wake the thread up and if the IRQ in question was
>>> disabled in the suspend NOIRQ phase this code is likely to deadlock.
>>>
>>> I want to make sure we can justify adding this check, I do not
>>> want to add it because we think it can be needed when it may not
>>> be needed at all (and it gets copy and pasted over and over again
>>> in other drivers).
>> I had a discussion internally about this and the prescribed usage of these APIs
>> seem to be that
>> use tegra_bpmp_transfer() in .probe() and other paths where interrupts are
>> enabled as this API needs interrupts to be enabled for its working.
>> Use tegra_bpmp_transfer_atomic() surrounded by local_irq_save()/local_irq_restore()
>> in other paths where interrupt servicing is disabled.
>
> Why tegra_bpmp_transfer_atomic() needs IRQs to be disabled ? And why
> is it needed in this piece of code where IRQs are _never_ disabled
> at CPU level ?
>
> IRQs are enabled when you call a suspend_noirq() callback, so the
> blocking API can be used as long as the IRQ descriptor backing
> the IRQ that will wake-up the blocked call is marked as
> IRQF_NO_SUSPEND.
>
> The problem is not IRQs enabled/disabled at CPU level, the problem is
> the IRQ descriptor of the IRQ required to handle the blocking BPMP call,
> mark it as IRQF_NO_SUSPEND and remove the tegra_bpmp_transfer_atomic()
> call from this code (or please give me a concrete example pinpointing
> why it is needed).
Ideally, using tegra_bpmp_transfer() alone in all paths (.probe() as well as .resume_noirq())
should have worked as the corresponding IRQ is already flagged as IRQF_NO_SUSPEND, but,
because of the way BPMP-FW driver in kernel making its interface available through .resume_early(),
tegra_bpmp_transfer() wasn't working as expected and I pushed a patch (CC'ing you) at
http://patchwork.ozlabs.org/patch/1140973/ to make it .resume_noirq() from .resume_early().
With that in place, we can just use tegra_bpmp_trasnfer().
I'll push a new patch with this change once my BPMP-FW driver patch is approved.
Thanks,
Vidya Sagar
>
> Thanks,
> Lorenzo
>
>> I'll go ahead and make next patch series with this if this looks fine to you.
>>
>>>
>>>>> Actually, if tegra_bpmp_transfer() requires IRQs to be enabled you may
>>>>> even end up in a situation where that blocking call does not wake up
>>>>> because the IRQ in question was disabled in the NOIRQ suspend/resume
>>>>> phase.
>>>>>
>>>>> [...]
>>>>>
>>>>>>>> +static int tegra_pcie_dw_probe(struct platform_device *pdev)
>>>>>>>> +{
>>>>>>>> + const struct tegra_pcie_soc *data;
>>>>>>>> + struct device *dev = &pdev->dev;
>>>>>>>> + struct resource *atu_dma_res;
>>>>>>>> + struct tegra_pcie_dw *pcie;
>>>>>>>> + struct resource *dbi_res;
>>>>>>>> + struct pcie_port *pp;
>>>>>>>> + struct dw_pcie *pci;
>>>>>>>> + struct phy **phys;
>>>>>>>> + char *name;
>>>>>>>> + int ret;
>>>>>>>> + u32 i;
>>>>>>>> +
>>>>>>>> + pcie = devm_kzalloc(dev, sizeof(*pcie), GFP_KERNEL);
>>>>>>>> + if (!pcie)
>>>>>>>> + return -ENOMEM;
>>>>>>>> +
>>>>>>>> + pci = &pcie->pci;
>>>>>>>> + pci->dev = &pdev->dev;
>>>>>>>> + pci->ops = &tegra_dw_pcie_ops;
>>>>>>>> + pp = &pci->pp;
>>>>>>>> + pcie->dev = &pdev->dev;
>>>>>>>> +
>>>>>>>> + data = (struct tegra_pcie_soc *)of_device_get_match_data(dev);
>>>>>>>> + if (!data)
>>>>>>>> + return -EINVAL;
>>>>>>>> + pcie->mode = (enum dw_pcie_device_mode)data->mode;
>>>>>>>> +
>>>>>>>> + ret = tegra_pcie_dw_parse_dt(pcie);
>>>>>>>> + if (ret < 0) {
>>>>>>>> + dev_err(dev, "Failed to parse device tree: %d\n", ret);
>>>>>>>> + return ret;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + 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",
>>>>>>>> + PTR_ERR(pcie->pex_ctl_supply));
>>>>>>>> + return PTR_ERR(pcie->pex_ctl_supply);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->core_clk = devm_clk_get(dev, "core");
>>>>>>>> + if (IS_ERR(pcie->core_clk)) {
>>>>>>>> + dev_err(dev, "Failed to get core clock: %ld\n",
>>>>>>>> + PTR_ERR(pcie->core_clk));
>>>>>>>> + return PTR_ERR(pcie->core_clk);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->appl_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>>>>>>>> + "appl");
>>>>>>>> + if (!pcie->appl_res) {
>>>>>>>> + dev_err(dev, "Failed to find \"appl\" region\n");
>>>>>>>> + return PTR_ERR(pcie->appl_res);
>>>>>>>> + }
>>>>>>>> + pcie->appl_base = devm_ioremap_resource(dev, pcie->appl_res);
>>>>>>>> + if (IS_ERR(pcie->appl_base))
>>>>>>>> + return PTR_ERR(pcie->appl_base);
>>>>>>>> +
>>>>>>>> + pcie->core_apb_rst = devm_reset_control_get(dev, "apb");
>>>>>>>> + if (IS_ERR(pcie->core_apb_rst)) {
>>>>>>>> + dev_err(dev, "Failed to get APB reset: %ld\n",
>>>>>>>> + PTR_ERR(pcie->core_apb_rst));
>>>>>>>> + return PTR_ERR(pcie->core_apb_rst);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + phys = devm_kcalloc(dev, pcie->phy_count, sizeof(*phys), GFP_KERNEL);
>>>>>>>> + if (!phys)
>>>>>>>> + return PTR_ERR(phys);
>>>>>>>> +
>>>>>>>> + for (i = 0; i < pcie->phy_count; i++) {
>>>>>>>> + name = kasprintf(GFP_KERNEL, "p2u-%u", i);
>>>>>>>> + if (!name) {
>>>>>>>> + dev_err(dev, "Failed to create P2U string\n");
>>>>>>>> + return -ENOMEM;
>>>>>>>> + }
>>>>>>>> + phys[i] = devm_phy_get(dev, name);
>>>>>>>> + kfree(name);
>>>>>>>> + if (IS_ERR(phys[i])) {
>>>>>>>> + ret = PTR_ERR(phys[i]);
>>>>>>>> + dev_err(dev, "Failed to get PHY: %d\n", ret);
>>>>>>>> + return ret;
>>>>>>>> + }
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->phys = phys;
>>>>>>>> +
>>>>>>>> + dbi_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
>>>>>>>> + if (!dbi_res) {
>>>>>>>> + dev_err(dev, "Failed to find \"dbi\" region\n");
>>>>>>>> + return PTR_ERR(dbi_res);
>>>>>>>> + }
>>>>>>>> + pcie->dbi_res = dbi_res;
>>>>>>>> +
>>>>>>>> + pci->dbi_base = devm_ioremap_resource(dev, dbi_res);
>>>>>>>> + if (IS_ERR(pci->dbi_base))
>>>>>>>> + return PTR_ERR(pci->dbi_base);
>>>>>>>> +
>>>>>>>> + /* Tegra HW locates DBI2 at a fixed offset from DBI */
>>>>>>>> + pci->dbi_base2 = pci->dbi_base + 0x1000;
>>>>>>>> +
>>>>>>>> + atu_dma_res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>>>>>>>> + "atu_dma");
>>>>>>>> + if (!atu_dma_res) {
>>>>>>>> + dev_err(dev, "Failed to find \"atu_dma\" region\n");
>>>>>>>> + return PTR_ERR(atu_dma_res);
>>>>>>>> + }
>>>>>>>> + pcie->atu_dma_res = atu_dma_res;
>>>>>>>> + pci->atu_base = devm_ioremap_resource(dev, atu_dma_res);
>>>>>>>> + if (IS_ERR(pci->atu_base))
>>>>>>>> + return PTR_ERR(pci->atu_base);
>>>>>>>> +
>>>>>>>> + pcie->core_rst = devm_reset_control_get(dev, "core");
>>>>>>>> + if (IS_ERR(pcie->core_rst)) {
>>>>>>>> + dev_err(dev, "Failed to get core reset: %ld\n",
>>>>>>>> + PTR_ERR(pcie->core_rst));
>>>>>>>> + return PTR_ERR(pcie->core_rst);
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pp->irq = platform_get_irq_byname(pdev, "intr");
>>>>>>>> + if (!pp->irq) {
>>>>>>>> + dev_err(dev, "Failed to get \"intr\" interrupt\n");
>>>>>>>> + return -ENODEV;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + ret = devm_request_irq(dev, pp->irq, tegra_pcie_irq_handler,
>>>>>>>> + IRQF_SHARED, "tegra-pcie-intr", pcie);
>>>>>>>> + if (ret) {
>>>>>>>> + dev_err(dev, "Failed to request IRQ %d: %d\n", pp->irq, ret);
>>>>>>>> + return ret;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + pcie->bpmp = tegra_bpmp_get(dev);
>>>>>>>> + if (IS_ERR(pcie->bpmp))
>>>>>>>> + return PTR_ERR(pcie->bpmp);
>>>>>>>> +
>>>>>>>> + platform_set_drvdata(pdev, pcie);
>>>>>>>> +
>>>>>>>> + if (pcie->mode == DW_PCIE_RC_TYPE) {
>>>>>>>> + ret = tegra_pcie_config_rp(pcie);
>>>>>>>> + if (ret && ret != -ENOMEDIUM)
>>>>>>>> + goto fail;
>>>>>>>> + else
>>>>>>>> + return 0;
>>>>>>>
>>>>>>> So if the link is not up we still go ahead and make probe
>>>>>>> succeed. What for ?
>>>>>> We may need root port to be available to support hot-plugging of
>>>>>> endpoint devices, so, we don't fail the probe.
>>>>>
>>>>> We need it or we don't. If you do support hotplugging of endpoint
>>>>> devices point me at the code, otherwise link up failure means
>>>>> failure to probe.
>>>> Currently hotplugging of endpoint is not supported, but it is one of
>>>> the use cases that we may add support for in future.
>>>
>>> You should elaborate on this, I do not understand what you mean,
>>> either the root port(s) supports hotplug or it does not.
>>>
>>>> But, why should we fail probe if link up doesn't happen? As such,
>>>> nothing went wrong in terms of root port initialization right? I
>>>> checked other DWC based implementations and following are not failing
>>>> the probe pci-dra7xx.c, pcie-armada8k.c, pcie-artpec6.c, pcie-histb.c,
>>>> pcie-kirin.c, pcie-spear13xx.c, pci-exynos.c, pci-imx6.c,
>>>> pci-keystone.c, pci-layerscape.c
>>>>
>>>> Although following do fail the probe if link is not up. pcie-qcom.c,
>>>> pcie-uniphier.c, pci-meson.c
>>>>
>>>> So, to me, it looks more like a choice we can make whether to fail the
>>>> probe or not and in this case we are choosing not to fail.
>>>
>>> I disagree. I had an offline chat with Bjorn and whether link-up should
>>> fail the probe or not depends on whether the root port(s) is hotplug
>>> capable or not and this in turn relies on the root port "Slot
>>> implemented" bit in the PCI Express capabilities register.
>>>
>>> It is a choice but it should be based on evidence.
>>>
>>> Lorenzo
>> With Bjorn's latest comment on top of this, I think we are good not to fail
>> the probe here.
>>
>> - Vidya Sagar
>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 3/3] Renesas DT binding updates for v5.4
From: Geert Uytterhoeven @ 2019-08-02 12:03 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190802120355.1430-1-geert+renesas@glider.be>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-dt-bindings-for-v5.4-tag1
for you to fetch changes up to 8cb7ec14188649cf2151464050413e2814fd7cf1:
dt-bindings: can: rcar_can: Complete documentation for RZ/G2[EM] (2019-07-29 15:36:39 +0200)
----------------------------------------------------------------
Renesas DT binding updates for v5.4
- RZ/G2 updates for the R-Car CAN and CANFD DT bindings.
----------------------------------------------------------------
Fabrizio Castro (2):
dt-bindings: can: rcar_canfd: document r8a774a1 support
dt-bindings: can: rcar_can: Complete documentation for RZ/G2[EM]
Documentation/devicetree/bindings/net/can/rcar_can.txt | 2 +-
Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 9 +++++----
2 files changed, 6 insertions(+), 5 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 1/3] Renesas ARM64 DT updates for v5.4
From: Geert Uytterhoeven @ 2019-08-02 12:03 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190802120355.1430-1-geert+renesas@glider.be>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-arm64-dt-for-v5.4-tag1
for you to fetch changes up to 0a05b3d7fee511de8a1c9dffc3d86f1df55e1737:
arm64: dts: renesas: ulcb: Sort nodes (2019-07-30 11:25:35 +0200)
----------------------------------------------------------------
Renesas ARM64 DT updates for v5.4
- CAN support for the HiHope RZ/G2E board,
- BT and WLAN support for the HiHope RZ/G2[MN] boards,
- Sound support for RZ/G2M,
- Sort nodes in various SoC and board DTSes,
- Small fixes and improvements.
----------------------------------------------------------------
Biju Das (3):
arm64: dts: renesas: hihope-common: Add PCA9654 I/O expander
arm64: dts: renesas: hihope-common: Add BT support
arm64: dts: renesas: hihope-common: Add WLAN support
Fabrizio Castro (6):
arm64: dts: renesas: r8a774c0: Add missing assigned-clocks for CAN[01]
arm64: dts: renesas: r8a774a1: Add missing assigned-clocks for CAN[01]
arm64: dts: renesas: r8a774a1: Add CANFD support
arm64: dts: renesas: hihope-rzg2-ex: Enable CAN interfaces
arm64: dts: renesas: r8a774a1: Use extended audio dmac registers
arm64: dts: renesas: r8a774a1: Add SSIU support for sound
Takeshi Kihara (1):
arm64: dts: renesas: r8a77990: Add cpg reset for DU
Yoshihiro Kaneko (13):
arm64: dts: renesas: r8a77995: Add cpg reset for DU
arm64: dts: renesas: r8a77995: Fix register range of display node
arm64: dts: renesas: r8a7795: Sort nodes
arm64: dts: renesas: r8a7795-es1: Sort nodes
arm64: dts: renesas: r8a77965: Sort nodes
arm64: dts: renesas: r8a7795-es1: salvator-x: Sort nodes
arm64: dts: renesas: r8a7795: salvator-x: Sort nodes
arm64: dts: renesas: r8a7795: salvator-xs: Sort nodes
arm64: dts: renesas: r8a7796: salvator-x: Sort nodes
arm64: dts: renesas: r8a7796: salvator-xs: Sort nodes
arm64: dts: renesas: salvator-common: Sort nodes
arm64: dts: renesas: ulcb-kf: Sort nodes
arm64: dts: renesas: ulcb: Sort nodes
arch/arm64/boot/dts/renesas/hihope-common.dtsi | 78 ++++++
arch/arm64/boot/dts/renesas/hihope-rzg2-ex.dtsi | 22 ++
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 282 +++++++++++++++++++--
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 4 +
.../boot/dts/renesas/r8a7795-es1-salvator-x.dts | 26 +-
arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 223 ++++++++--------
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 26 +-
.../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 82 +++---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 154 +++++------
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 10 +-
.../arm64/boot/dts/renesas/r8a7796-salvator-xs.dts | 10 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 48 ++--
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 +
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 4 +-
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 72 +++---
arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 226 ++++++++---------
arch/arm64/boot/dts/renesas/ulcb.dtsi | 10 +-
17 files changed, 814 insertions(+), 465 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PULL 2/3] Renesas driver updates for v5.4
From: Geert Uytterhoeven @ 2019-08-02 12:03 UTC (permalink / raw)
To: arm-soc, arm-soc
Cc: linux-renesas-soc, Simon Horman, Magnus Damm, Geert Uytterhoeven,
linux-arm-kernel
In-Reply-To: <20190802120355.1430-1-geert+renesas@glider.be>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git tags/renesas-drivers-for-v5.4-tag1
for you to fetch changes up to 0ed0eb0171d7c19310d9f7b06a6dee82a4fb8ab6:
soc: renesas: rcar-sysc: Use [] to denote a flexible array member (2019-07-29 15:36:56 +0200)
----------------------------------------------------------------
Renesas driver updates for v5.4
- Fix a flexible array member definition in the R-Car SYSC driver.
----------------------------------------------------------------
Geert Uytterhoeven (1):
soc: renesas: rcar-sysc: Use [] to denote a flexible array member
drivers/soc/renesas/rcar-sysc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
_______________________________________________
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