* [PATCH v3 2/2] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-13 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95d0db34-713d-8206-00c2-ee9a42aab823@cogentembedded.com>
Define the Condor/V3HSK board dependent parts of the DU and LVDS device
nodes. Also add the device nodes for Thine THC63LVD1024 LVDS decoder and
Analog Devices ADV7511W HDMI transmitter...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- added the V3HSK DT update, reworded the description, renamed the patch;
- added a space between the HDMI node name and a brace.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 +++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 120 ++++++++++++++++++++++++
2 files changed, 226 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -45,6 +45,56 @@
regulator-boot-on;
regulator-always-on;
};
+
+ d1_8v: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "D1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&d3_3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ x1_clk: x1-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <148500000>;
+ };
};
&avb {
@@ -74,6 +124,13 @@
};
};
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+ <&x1_clk>;
+ clock-names = "du.0", "dclkin.0";
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -102,6 +159,55 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&d1_8v>;
+ dvdd-supply = <&d1_8v>;
+ pvdd-supply = <&d1_8v>;
+ bgvdd-supply = <&d1_8v>;
+ dvdd-3v-supply = <&d3_3v>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
};
&mmc0 {
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -27,6 +27,63 @@
/* first 128MB is reserved for secure area. */
reg = <0 0x48000000 0 0x78000000>;
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&vcc3v3_d5>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ vcc1v8_d4: regulator-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8_D4";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc3v3_d5: regulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_D5";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&du {
+ status = "okay";
};
&extal_clk {
@@ -53,6 +110,64 @@
};
};
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
+};
+
+&i2c0 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ #sound-dai-cells = <0>;
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&vcc1v8_d4>;
+ dvdd-supply = <&vcc1v8_d4>;
+ pvdd-supply = <&vcc1v8_d4>;
+ bgvdd-supply = <&vcc1v8_d4>;
+ dvdd-3v-supply = <&vcc3v3_d5>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
&pfc {
gether_pins: gether {
groups = "gether_mdio_a", "gether_rgmii",
@@ -60,6 +175,11 @@
function = "gether";
};
+ i2c0_pins: i2c0 {
+ groups = "i2c0";
+ function = "i2c0";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Scott Branden @ 2018-06-13 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f20222ea-47ac-ca05-a8d3-69f28932de94@gmail.com>
Hi Rob,
Thanks for comment - reply inline.
On 18-06-13 12:31 PM, Florian Fainelli wrote:
> On 06/12/2018 03:54 PM, Rob Herring wrote:
>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>> <scott.branden@broadcom.com> wrote:
>>> Hi Rob,
>>>
>>> Could you please kindly comment on change below.
>>>
>>> It allows board variants to be added easily via a simple define for
>>> different number of SATA ports.
>>>
>>>
>>>
>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>> ports based on NUM_SATA defined.
>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>> Rob could you review this and let us know if this approach is okay or
>>>> not? Thank you!
>>>>
>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>> ---
>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> index 8c68e0c..7f6d176 100644
>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>> @@ -43,7 +43,11 @@
>>>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> +#if (NUM_SATA > 0)
>>>>> + status = "okay";
>>>>> +#else
>>>>> status = "disabled";
>>>>> +#endif
>> This only works if ports are contiguously enabled (0-N). You might not
>> care, but it is not a pattern that works in general.
Correct - all board designs that include this dtsi file follow such
commonality (ie. design with SATA0 first, etc).? By having common board
designs it allows for commonality in dts files rather than duplicating
information everywhere.? If somebody designs a bizarro board they are
free to create their own dts file of course.
>> And I'm not a fan
>> of C preprocessing in DT files in general beyond just defines for
>> single numbers.
The use of a define to specify the number of SATA ports in the board
design meets our requirements of being able to maintain many boards.? We
need a method to specify the number of ports in the board design rather
than copying and pasting the information in many dts files.? If you have
an alternative upstreamable mechanism to manage the configuration of
many boards without copy and paste that would be ideal?
> Should we interpret this as a formal NAK?
^ permalink raw reply
* [PATCH v3 0/2] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-13 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95d0db34-713d-8206-00c2-ee9a42aab823@cogentembedded.com>
On 06/13/2018 11:09 PM, Sergei Shtylyov wrote:
> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
Only 2, not 5 anymore. :-)
> 'renesas-devel-20180613-v4.17' tag and the Condor/V3HSK TD patches adding
Only 1 DT patch, not 2 anymore. :-)
> Ethernet PHY IRQs. We're adding the R8A77980 FCPVD/VSPD/DU/LVDS device nodes
> and then describing the LVDS decoder and HDMI encoder connected to the LVDS
> output on the Condor and V3HSK boards. These patches depend on the Thine
> THC63LVD1024 driver and the R8A77980 LVDS support patch in order to work...
>
> [1/2] arm64: dts: renesas: r8a77980: add FCPVD/VSPD/DU/LVDS support
> [2/2] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
WBR, Sergei
^ permalink raw reply
* [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
From: Marek Vasut @ 2018-06-13 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613173634.GC17671@n2100.armlinux.org.uk>
On 06/13/2018 07:36 PM, Russell King - ARM Linux wrote:
> On Wed, Jun 13, 2018 at 01:06:13AM +0200, Marek Vasut wrote:
>> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
>>> Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
>>> function to setup the bits, we are able to override the settings.
>>>
>>> Without this enabled, Linux kernel reports:
>>> CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
>>>
>>> With this enabled, Linux kernel reports:
>>> CPU0: Spectre v2: using ICIALLU workaround
>>>
>>> NOTE: This by itself does not enable the workaround for CPU1 (on
>>> OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
>>>
>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>> ---
>>> arch/arm/mach-omap2/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>>> index 3bb1ecb58de0..77820cc8d1e4 100644
>>> --- a/arch/arm/mach-omap2/Kconfig
>>> +++ b/arch/arm/mach-omap2/Kconfig
>>> @@ -53,6 +53,7 @@ config OMAP54XX
>>> bool "OMAP54XX SoC"
>>> select ARM_ERRATA_798870
>>> select SYS_THUMB_BUILD
>>> + select ARM_CORTEX_A15_CVE_2017_5715
>>> imply NAND_OMAP_ELM
>>> imply NAND_OMAP_GPMC
>>> imply SPL_DISPLAY_PRINT
>>>
>>
>> Can this be enabled for all CA15 systems somehow ? I am sure there are
>> more that are vulnerable.
>
> I think you're missing the point.
Please read the patch again.
This enables it only for a specific SoC. My point being, this should be
enabled for all SoCs with CA15, not just some select few.
> Spectre affects the _entire_ system. Working around it in just the
> kernel does not mean that the system is no longer vulnerable.
>
> Fixing the "system" means implementing the fixes also in the secure
> world, which on A15 and A8 also means setting the IBE bit there. If
> the IBE bit is set in the secure world, it will also be set in the
> non-secure world.
>
> The fact that the kernel is complaining is telling you that the
> system as a whole does not have the workarounds in place to mitigate
> against the vulnerability. Merely setting the IBE bit via some
> secure API doesn't "magically" fix the secure world.
>
> So, even if you were to set the IBE bit via some magic secure API,
> the fact still remains: even with these workarounds in place, as I
> understand it, the _system as a whole_ remains vulnerable - you
> might as well _not_ have the kernel workarounds.
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 04/10] Input: ams_delta_serio: Replace power GPIO with regulator
From: Dmitry Torokhov @ 2018-06-13 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2655614.ErW8VuCT6r@z50>
On Wed, Jun 13, 2018 at 03:01:05AM +0200, Janusz Krzysztofik wrote:
> On Wednesday, June 13, 2018 12:17:24 AM CEST Dmitry Torokhov wrote:
> > On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> > > ...
> > > + priv->vcc = devm_regulator_get(&pdev->dev, "vcc");
> > > + if (IS_ERR(priv->vcc)) {
> > > + err = PTR_ERR(priv->vcc);
> > > + dev_err(&pdev->dev, "regulator request failed (%d)\n", err);
> > > + /* Fail softly if the regulator is not available yet */
> > > + if (err == -ENODEV)
> > > + err = -EPROBE_DEFER;
> >
> > Hmm, if regulator is not ready yet, devm_regulator_get() should be
> > returning -EPROBE_DEFER already, we should not have to convert -ENODEV
> > to -EPROBE_DEFER...
>
> Regulator is not ready because its initialization at subsys_initcall is
> deferred by not ready GPIO pin, that in turn is caused by gpio-mmio driver,
> unlike many other GPIO drivers, registered as late as at device_initcall.
>
> I agree devm_regulator_get() could return -EPROBE_DEFER in this case, but I
> can see it does that only when of_get_regulator() indicates the regulator
> should exist. In non-dt case there is apparently no way to justify if it
> should unless its consumer supply table was already in place. For that,
> registration of that table would have to be independent of successful
> registration of the regulator itself while it's not. Maybe it should, but
> that's a separate topic for a separate discussion, I think.
>
> > Is it because we have_full_constraints() returns false? You might need
> > to add call to regulator_has_full_constraints() to your board file.
>
> If have_full_constraints() returned true before the regulator or its consumer
> supply table is ready, devm_regulator_get() would happily return a dummy
> regulator and our keyboard would never get its power.
>
> I'm afraid we have to live with that return code conversion as long as the
> only user of this driver is not migrated to dt.
OK, fair enough. Can you please add a comment to that effect?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH V3] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Marek Vasut @ 2018-06-13 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdUmqAWHFoM5tRJA+FoH59J8L3z0BMKVO-FEv4RQbokJyg@mail.gmail.com>
On 06/13/2018 01:28 PM, Geert Uytterhoeven wrote:
> Hi Marek,
Hi,
[...]
>>>> But wait, since we control which machines this code runs on , can't we
>>>> assure they have valid DTs ? This situation with invalid DT starts to
>>>> look a bit hypothetical to me.
>>>
>>> That assumes you keep the list of machines to check, and don't want to fix the
>>> issue automatically when detected (on any R-Car Gen2 or RZ/G1 platform, so
>>> you still need to check for r8a779[0-4] and r8a774[23457]).
>>
>> Yes, I want to keep a list of machines to check, to be _sure_ some
>> machine doesn't randomly blow up.
>
> Just checking for the presence of a "renesas,irqc" node should be sufficient.
How so? Any other R-Car machine can have the irqc node too. That's
fragile at best.
> Using that node would also get rid of the hardcoded IRQC_BASE address.
> Note that the code assumes IRQ2. If another IRQ is used, that won't harm
> much though (as in: if it didn't blow up before, it won't blow up now).
We could/should fix up the irqc detection though.
>>> Anyway, as we care about booting old DTBs on new kernels (for a while), we
>>> have a few more release cycles to bikeshed ;-)
>>
>> I was about to ask if this patch then makes any sense or not.
>
> Sure. Less hard-coding is always better.
> Especially if it means we can make it work on more machines automatically :-)
I prefer to be in control of that.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Matt Sealey @ 2018-06-13 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkx9cjV-bWg7aLg-kJT7x7DtwTHdsYzzM8A3+cFFnu_mNg@mail.gmail.com>
> -----Original Message-----
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> > So, if the suggestion is to use an existing property "unit", I am fine
> > with it, if people agree to it.
>
> If we're going to have something sharply different than ACPI I prefer
> Rob's idea.
What are you trying to say about being sharply different than ACPI?
Ta,
Matt
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
From: Nishanth Menon @ 2018-06-13 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <330ff593-4663-5393-74b3-55bf1f199561@gmail.com>
On 20:36-20180613, Marek Vasut wrote:
> On 06/13/2018 07:36 PM, Russell King - ARM Linux wrote:
> > On Wed, Jun 13, 2018 at 01:06:13AM +0200, Marek Vasut wrote:
> >> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> >>> Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
> >>> function to setup the bits, we are able to override the settings.
> >>>
> >>> Without this enabled, Linux kernel reports:
> >>> CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
> >>>
> >>> With this enabled, Linux kernel reports:
> >>> CPU0: Spectre v2: using ICIALLU workaround
> >>>
> >>> NOTE: This by itself does not enable the workaround for CPU1 (on
> >>> OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
> >>>
> >>> Signed-off-by: Nishanth Menon <nm@ti.com>
> >>> ---
> >>> arch/arm/mach-omap2/Kconfig | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> >>> index 3bb1ecb58de0..77820cc8d1e4 100644
> >>> --- a/arch/arm/mach-omap2/Kconfig
> >>> +++ b/arch/arm/mach-omap2/Kconfig
> >>> @@ -53,6 +53,7 @@ config OMAP54XX
> >>> bool "OMAP54XX SoC"
> >>> select ARM_ERRATA_798870
> >>> select SYS_THUMB_BUILD
> >>> + select ARM_CORTEX_A15_CVE_2017_5715
> >>> imply NAND_OMAP_ELM
> >>> imply NAND_OMAP_GPMC
> >>> imply SPL_DISPLAY_PRINT
> >>>
> >>
> >> Can this be enabled for all CA15 systems somehow ? I am sure there are
> >> more that are vulnerable.
> >
> > I think you're missing the point.
>
> Please read the patch again.
>
> This enables it only for a specific SoC. My point being, this should be
> enabled for all SoCs with CA15, not just some select few.
>
As I had previously responded in
https://marc.info/?l=u-boot&m=152889727127549&w=2
I am not disagreeing this needs to be done for all CA15 based SoCs
(and A8s for previous patches ...), but.. I am not sure what you'd
like me to do here -> I just dont know what the SMC convention is
for all SoCs with CA15! I can help with TI SoCs for sure.. but then,
Russell has a point that this is just one part of the solution -> on
devices that provide secure services, there is definitely a need to
lock the secure entry points down as well. But, specifically to this
patch, do recommend an alternative if one exists.. will gladly follow.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Nishanth Menon @ 2018-06-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613154627.GP350@bill-the-cat.ec.rr.com>
On 15:46-20180613, Tom Rini wrote:
> On Wed, Jun 13, 2018 at 08:32:15AM -0500, Nishanth Menon wrote:
> > On 23:05-20180612, Marek Vasut wrote:
> > > On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> > [..]
> > > > +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
> > > > + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
> > > > + orr r0, r0, #1 << 0 @ Enable invalidates of BTB
> > >
> > > Can we use BIT() macro in the assembler code too ?
> >
> > Probably, but just following convention in the rest of the file. Do we
> > want to change from existing code?
>
> Agreed, we should follow the existing style (and I'm not 100% sure I
> like using BIT() in asm files).
OK. Will drop this feedback about BIT() macro if I have to do a v2.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Florian Fainelli @ 2018-06-13 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613133704.dwytvpj3zeuywooh@kahuna>
On 06/13/2018 06:37 AM, Nishanth Menon wrote:
> On 00:30-20180613, Florian Fainelli wrote:
>> On June 12, 2018 1:24:09 PM PDT, Nishanth Menon <nm@ti.com> wrote:
>>> As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
>>> needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
>>> be done unconditionally for Cortex-A15 processors. Provide a config
>>> option for platforms to enable this option based on impact analysis
>>> for products.
>>>
>>> NOTE: This patch in itself is NOT the final solution, this requires:
>>> a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
>>> provide direct access to ACR register.
>>> b) Operating Systems such as Linux to provide adequate workaround in
>>> the
>>> right locations.
>>
>> This is the case as of 4.18 so you could probably reference CONFIG_CPU_SPECTRE and CONFIG_HARDEN_BRANCH_PREDICTOR in a v2.
>
> Did'nt want to tie the description too deep to Linux specifics.. Linux
> documents itself and users are encouraged to read that documentation,
> correct?
That's fair enough I guess, we also don't know how the other OSes do
provide that mitigation and whether they have run-time/build-time
configuration options gating those.
>
>>
>>> c) This workaround applies to only the boot processor. It is important
>>> to apply workaround as necessary (context-save-restore) around low
>>> power context loss OR additional processors as necessary in either
>>> firmware support OR elsewhere in OS.
>>
>> About that, I don't know enough of uboot but are there existing PSCI or
>> other seemingly standard secondary core support in uboot that would make
>> us go through the same initialization as the boot CPU? If not, is
>> everything going to be largely implementation specific and
>> scattered between uboot and the hypervisors or kernel?
>
> in ARMV7 SoCs, unfortunately, we lived in a world of no-exact-standard.
> even within TI, Few of the SoCs use PSCI, others did implement custom
> SMC calls (since they existed in an architecture prior to PSCI).
>
>>
>> FWIW, this is what prompted me to submit this:
>>
>> https://patchwork.kernel.org/patch/10453643/
>
> That wont work in a generic manner for precisely the same reason I had to do
> it with weak function in u-boot (some SoCs will only permit 'mcr
> p15, 0, r0, c1, c0, 1' in secure world and you need to make a custom smc
> call to make it happen). Unfortunately, IMHO, at least at this
> point, there'd be custom implementations per SoC and layers depending on
> where to implement it.
It won't work in a generic manner but it will work for some platforms
where updating the firmware is impractical, and since the bits are write
ignore if your PL does not allow it, this still seems like a net win for
platforms where this is effective, and it does take care of Linux doing
the SMP bring-up of secondary cores as well. That's what we have in our
downstream tree at least, and I was hoping this could land upstream too.
--
Florian
^ permalink raw reply
* [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
From: Russell King - ARM Linux @ 2018-06-13 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <330ff593-4663-5393-74b3-55bf1f199561@gmail.com>
On Wed, Jun 13, 2018 at 10:36:56PM +0200, Marek Vasut wrote:
> On 06/13/2018 07:36 PM, Russell King - ARM Linux wrote:
> > On Wed, Jun 13, 2018 at 01:06:13AM +0200, Marek Vasut wrote:
> >> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> >>> Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
> >>> function to setup the bits, we are able to override the settings.
> >>>
> >>> Without this enabled, Linux kernel reports:
> >>> CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
> >>>
> >>> With this enabled, Linux kernel reports:
> >>> CPU0: Spectre v2: using ICIALLU workaround
> >>>
> >>> NOTE: This by itself does not enable the workaround for CPU1 (on
> >>> OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
> >>>
> >>> Signed-off-by: Nishanth Menon <nm@ti.com>
> >>> ---
> >>> arch/arm/mach-omap2/Kconfig | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> >>> index 3bb1ecb58de0..77820cc8d1e4 100644
> >>> --- a/arch/arm/mach-omap2/Kconfig
> >>> +++ b/arch/arm/mach-omap2/Kconfig
> >>> @@ -53,6 +53,7 @@ config OMAP54XX
> >>> bool "OMAP54XX SoC"
> >>> select ARM_ERRATA_798870
> >>> select SYS_THUMB_BUILD
> >>> + select ARM_CORTEX_A15_CVE_2017_5715
> >>> imply NAND_OMAP_ELM
> >>> imply NAND_OMAP_GPMC
> >>> imply SPL_DISPLAY_PRINT
> >>>
> >>
> >> Can this be enabled for all CA15 systems somehow ? I am sure there are
> >> more that are vulnerable.
> >
> > I think you're missing the point.
>
> Please read the patch again.
Stop this madness - I /know/ precisely what _this_ patch is doing.
My reply was to *your* comment about extending it "for all CA15
systems".
> This enables it only for a specific SoC. My point being, this should be
> enabled for all SoCs with CA15, not just some select few.
Let's try again... the short answer: NO.
The long answer:
Enabling IBE does *not* universally solve the problem for all SoCs
using CA15. It merely enables the instructions required for
workarounds in the *kernel* part of the system to take effect. That
leaves the rest of the system *vulnerable*.
Just in the same way that we have to apply the workarounds /not only/
at the kernel level, but also the hypervisor level for KVM to prevent
KVM being vulnerable, the workarounds _also_ need to be appled at
secure firmware level, as I tried to explain.
Nishanth's OMAP5 case is kind of special because, from what he's
said (a) there's nothing in the secure world that really matters,
and (b) there's nothing that can be done to fix the secure world
because that firmware is in ROM and can never be changed.
That isn't true "for all CA15 systems", and if we're wanting
systems to be properly fixed, then fixing the problem properly
(by fixing the secure world to set IBE *and* implement the
workarounds there) is the right thing.
Setting the IBE bit in the kernel for all CA15 means that, while
we solve the kernel part (and KVM part), the secure world will
remain vulnerable if it has no protection - and worse, people
probably haven't thought enough about this, or know enough about it,
to realise that the vulnerability still exists all the time that any
part of the system has not been fixed. So, having the kernel print
a warning is critical.
If it was just the case that the kernel was all that was affected,
then KVM wouldn't have needed to be fixed, but the reality is it
needed to be fixed and has been. The same applies to the secure
world.
Think about this: if you can trick the secure world into speculatively
executing a set of gadgets by manipulating the ARM register values
passed to the SMC call to read secure world memory - or any memory
you shouldn't have access to (like the kernel) then setting the IBE
bit and having the kernel fixes in place is completely meaningless.
As I said below, the system _remains_ vulnerable.
Take a look at the work going on with ARM64 syscalls - they're now
explicitly zeroing all registers on entry that are not an explicit
argument to any syscall. The reason is to prevent userspace doing
exactly what I've described above, except with the kernel.
So, should we extend it "for all CA15 systems". No, definitely not
without knowing exactly what the situation is for each and every one.
Having it done in firmware - the same firmware that switches the
CPU out of secure mode - is the right answer where it's possible to
do so. That won't happen if we apply a "fix" to set IBE as a big
hammer to the kernel.
> > Spectre affects the _entire_ system. Working around it in just the
> > kernel does not mean that the system is no longer vulnerable.
> >
> > Fixing the "system" means implementing the fixes also in the secure
> > world, which on A15 and A8 also means setting the IBE bit there. If
> > the IBE bit is set in the secure world, it will also be set in the
> > non-secure world.
> >
> > The fact that the kernel is complaining is telling you that the
> > system as a whole does not have the workarounds in place to mitigate
> > against the vulnerability. Merely setting the IBE bit via some
> > secure API doesn't "magically" fix the secure world.
> >
> > So, even if you were to set the IBE bit via some magic secure API,
> > the fact still remains: even with these workarounds in place, as I
> > understand it, the _system as a whole_ remains vulnerable - you
> > might as well _not_ have the kernel workarounds.
And the long answer is basically what I said ^^^^^ there.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64: dts: hikey960: Define wl1837 power capabilities
From: Valentin Schneider @ 2018-06-13 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613180321.16745-1-ryan@edited.us>
On 13/06/18 19:03, Ryan Grachek wrote:
> These properties are required for compatibility with runtime PM.
> Without these properties, MMC host controller will not be aware
> of power capabilities. When the wlcore driver attempts to power
> on the device, it will erroneously fail with -EACCES. This fixes
> a regression found here: https://lkml.org/lkml/2018/6/12/930
>
Thanks! As mentioned in the above thread, this lets wlan0 come up properly,
which otherwise doesn't come up and spits out:
[ 8.466097] wl1271_sdio mmc1:0001:2: wl12xx_sdio_power_on: failed to get_sync(-13)
Tested-by: Valentin Schneider <valentin.schneider@arm.com>
> Signed-off-by: Ryan Grachek <ryan@edited.us>
> ---
> arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index c6999624ed8a..68c5a6c819ae 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -585,6 +585,8 @@
> vmmc-supply = <&wlan_en>;
> ti,non-removable;
> non-removable;
> + cap-power-off-card;
> + keep-power-in-suspend;
> #address-cells = <0x1>;
> #size-cells = <0x0>;
> status = "ok";
>
^ permalink raw reply
* [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
From: Giulio Benetti @ 2018-06-13 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613081647.31183-1-paul.kocialkowski@bootlin.com>
Hello,
sorry for my ignorance.
I don't know the right patch workflow in the case of "revert commit".
When I fix this bug, should I have to re-submit the previous patch
entire plus bug-fix?
Or do I have to submit patch with bug-fix only?
Thanks in advance to everybody
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
Il 13/06/2018 10:16, Paul Kocialkowski ha scritto:
> This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70.
>
> The offending commit triggers a run-time fault when accessing the panel
> element of the sun4i_tcon structure when no such panel is attached.
>
> It was apparently assumed in said commit that a panel is always used with
> the TCON. Although it is often the case, this is not always true.
> For instance a bridge might be used instead of a panel.
>
> This issue was discovered using an A13-OLinuXino, that uses the TCON
> in RGB mode for a simple DAC-based VGA bridge.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 -------------------------
> 1 file changed, 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index c3d92d537240..8045871335b5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -17,7 +17,6 @@
> #include <drm/drm_encoder.h>
> #include <drm/drm_modes.h>
> #include <drm/drm_of.h>
> -#include <drm/drm_panel.h>
>
> #include <uapi/drm/drm_mode.h>
>
> @@ -350,9 +349,6 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon,
> static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
> const struct drm_display_mode *mode)
> {
> - struct drm_panel *panel = tcon->panel;
> - struct drm_connector *connector = panel->connector;
> - struct drm_display_info display_info = connector->display_info;
> unsigned int bp, hsync, vsync;
> u8 clk_delay;
> u32 val = 0;
> @@ -410,27 +406,6 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
> if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
>
> - /*
> - * On A20 and similar SoCs, the only way to achieve Positive Edge
> - * (Rising Edge), is setting dclk clock phase to 2/3(240?).
> - * By default TCON works in Negative Edge(Falling Edge),
> - * this is why phase is set to 0 in that case.
> - * Unfortunately there's no way to logically invert dclk through
> - * IO_POL register.
> - * The only acceptable way to work, triple checked with scope,
> - * is using clock phase set to 0? for Negative Edge and set to 240?
> - * for Positive Edge.
> - * On A33 and similar SoCs there would be a 90? phase option,
> - * but it divides also dclk by 2.
> - * Following code is a way to avoid quirks all around TCON
> - * and DOTCLOCK drivers.
> - */
> - if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
> - clk_set_phase(tcon->dclk, 240);
> -
> - if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
> - clk_set_phase(tcon->dclk, 0);
> -
> regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
> SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
> val);
>
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Rob Herring @ 2018-06-13 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0bf3c57c-dac8-8ece-6b8a-3b4d024140fc@broadcom.com>
On Wed, Jun 13, 2018 at 2:18 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Thanks for comment - reply inline.
>
>
>
> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>>
>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>>
>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>> <scott.branden@broadcom.com> wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> Could you please kindly comment on change below.
>>>>
>>>> It allows board variants to be added easily via a simple define for
>>>> different number of SATA ports.
>>>>
>>>>
>>>>
>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>>
>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>>
>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>> ports based on NUM_SATA defined.
>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>>
>>>>> Rob could you review this and let us know if this approach is okay or
>>>>> not? Thank you!
>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> index 8c68e0c..7f6d176 100644
>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> @@ -43,7 +43,11 @@
>>>>>> interrupts = <GIC_SPI 321
>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>> #address-cells = <1>;
>>>>>> #size-cells = <0>;
>>>>>> +#if (NUM_SATA > 0)
>>>>>> + status = "okay";
>>>>>> +#else
>>>>>> status = "disabled";
>>>>>> +#endif
>>>
>>> This only works if ports are contiguously enabled (0-N). You might not
>>> care, but it is not a pattern that works in general.
>
> Correct - all board designs that include this dtsi file follow such
> commonality (ie. design with SATA0 first, etc). By having common board
> designs it allows for commonality in dts files rather than duplicating
> information everywhere. If somebody designs a bizarro board they are free
> to create their own dts file of course.
>>>
>>> And I'm not a fan
>>> of C preprocessing in DT files in general beyond just defines for
>>> single numbers.
>
> The use of a define to specify the number of SATA ports in the board design
> meets our requirements of being able to maintain many boards. We need a
> method to specify the number of ports in the board design rather than
> copying and pasting the information in many dts files. If you have an
> alternative upstreamable mechanism to manage the configuration of many
> boards without copy and paste that would be ideal?
Is this really the only problem with maintaining lots of boards? What
about all the other nodes that are conditionally enabled? Really, I
don't see the problem with 3 lines per node.
Does having an unused port enabled cause problems? If not, you could
handle it all at run-time and just shutdown ports which have no link.
You'd want to do that anyway for boards with a port, but is not
connected to a drive (except for hotplug capable ports).
Maybe we could add a property in /chosen that is a list of nodes to
enable and either the bootloader or kernel could update their
'status'. Or It could even be done in dtc perhaps with some
/directive/.
Rob
^ permalink raw reply
* [PATCH] clk: meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL
From: Kevin Hilman @ 2018-06-13 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528892421-12180-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> On Amlogic Meson GXBB & GXL platforms, the SCPI Cortex-M4 Co-Processor
> seems to be dependent on the FCLK_DIV2 to be operationnal.
>
> The issue occured since v4.17-rc1 by freezing the kernel boot when
> the 'schedutil' cpufreq governor was selected as default :
>
> [ 12.071837] scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version
> domain-0 init dvfs: 4
> [ 12.087757] hctosys: unable to open rtc device (rtc0)
> [ 12.087907] cfg80211: Loading compiled-in X.509 certificates for regulatory database
> [ 12.102241] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
>
> But when disabling the MMC driver, the boot finished but cpufreq failed to
> change the CPU frequency :
>
> [ 12.153045] cpufreq: __target_index: Failed to change cpu frequency: -5
>
> A bisect between v4.16 and v4.16-rc1 gave the 05f814402d61 commit to be
> the first bad commit.
> This commit added support for the missing clock gates before the fixed PLL
> fixed dividers (FCLK_DIVx) and the clock framework basically disabled
> all the unused fixed dividers, thus disabled a critical clock path for
> the SCPI Co-Processor.
>
> This patch simply sets the FCLK_DIV2 gate as critical to ensure
> nobody can disable it.
>
> Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Nice! this also fixes the boot hang I had noticed on gxm-nexbox-a1
(though MMC still needs to be disabled to fully boot.)
Tested-by: Kevin Hilman <khilman@baylibre.com>
Kevin
> ---
> drivers/clk/meson/gxbb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index b1e4d95..0e053c1 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -511,6 +511,7 @@ static struct clk_regmap gxbb_fclk_div2 = {
> .ops = &clk_regmap_gate_ops,
> .parent_names = (const char *[]){ "fclk_div2_div" },
> .num_parents = 1,
> + .flags = CLK_IS_CRITICAL,
> },
> };
^ permalink raw reply
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Marek Vasut @ 2018-06-13 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613213222.qxuiw7cajizslso7@kahuna>
On 06/13/2018 11:32 PM, Nishanth Menon wrote:
> On 15:46-20180613, Tom Rini wrote:
>> On Wed, Jun 13, 2018 at 08:32:15AM -0500, Nishanth Menon wrote:
>>> On 23:05-20180612, Marek Vasut wrote:
>>>> On 06/12/2018 10:24 PM, Nishanth Menon wrote:
>>> [..]
>>>>> +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>>>>> + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
>>>>> + orr r0, r0, #1 << 0 @ Enable invalidates of BTB
>>>>
>>>> Can we use BIT() macro in the assembler code too ?
>>>
>>> Probably, but just following convention in the rest of the file. Do we
>>> want to change from existing code?
>>
>> Agreed, we should follow the existing style (and I'm not 100% sure I
>> like using BIT() in asm files).
>
> OK. Will drop this feedback about BIT() macro if I have to do a v2.
Fine by me
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] arm64: dts: qcom: Add pm8005 and pm8998 support
From: Evan Green @ 2018-06-13 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613152054.54812-1-swboyd@chromium.org>
On Wed, Jun 13, 2018 at 8:21 AM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Add basic support for the pm8005 and pm8998 PMICs. For now just support
> the GPIO controllers.
>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
> arch/arm64/boot/dts/qcom/pm8005.dtsi | 33 +++++++++++++++++
> arch/arm64/boot/dts/qcom/pm8998.dtsi | 55 ++++++++++++++++++++++++++++
> 2 files changed, 88 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/pm8005.dtsi
> create mode 100644 arch/arm64/boot/dts/qcom/pm8998.dtsi
>
Reviewed-by: Evan Green <evgreen@chromium.org>
^ permalink raw reply
* [PATCH 1/5] ARM: dts: cygnus: Fix I2C controller interrupt type
From: Ray Jui @ 2018-06-13 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c368dbc-f654-ec52-0786-1f318156b8b5@gmail.com>
On 6/13/2018 12:49 PM, Florian Fainelli wrote:
> On 06/12/2018 01:21 PM, Ray Jui wrote:
>> Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
>> Cygnus SoC
>>
>> Fixes: b51c05a331ff ("ARM: dts: add I2C device nodes for Broadcom Cygnus")
>
> This appears to be the only one that is truly needed here, the two
> others below probably just moved things around but the offending commit
> was already introduced in the above commit.
>
Okay thanks. Will remove the other two "Fixes" below.
>> Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi bus")
>> Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
>>
>
> There is no need for an extra line between the last Fixes: tag and your
> Signed-off-by tag.
>
Got it, thanks!
Ray
^ permalink raw reply
* [PATCH 1/5] ARM: dts: cygnus: Fix I2C controller interrupt type
From: Florian Fainelli @ 2018-06-13 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21124af0-f867-56a9-753d-cadfce7d1cf2@broadcom.com>
On 06/13/2018 04:32 PM, Ray Jui wrote:
>
>
> On 6/13/2018 12:49 PM, Florian Fainelli wrote:
>> On 06/12/2018 01:21 PM, Ray Jui wrote:
>>> Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
>>> Cygnus SoC
>>>
>>> Fixes: b51c05a331ff ("ARM: dts: add I2C device nodes for Broadcom
>>> Cygnus")
>>
>> This appears to be the only one that is truly needed here, the two
>> others below probably just moved things around but the offending commit
>> was already introduced in the above commit.
>>
>
> Okay thanks. Will remove the other two "Fixes" below.
I can take care of that while applying the patches, no need for you to
resubmit, for the whole series I mean.
>
>>> Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi
>>> bus")
>>> Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
>>>
>>
>> There is no need for an extra line between the last Fixes: tag and your
>> Signed-off-by tag.
>>
>
> Got it, thanks!
And that as well.
--
Florian
^ permalink raw reply
* [PATCH 2/5] ARM: dts: cygnus: Fix PCIe controller interrupt type
From: Ray Jui @ 2018-06-13 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <99e3ab78-a639-5244-75a6-af39e56e7c67@gmail.com>
On 6/13/2018 12:50 PM, Florian Fainelli wrote:
> On 06/12/2018 01:21 PM, Ray Jui wrote:
>> Fix PCIe controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
>> Cygnus SoC
>>
>> Fixes: cd590b50a936 ("ARM: dts: enable PCIe support for Cygnus")
>
> This one is valid
>
>> Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi
>> bus")
>> Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
>> Fixes: f6b889358a82 ("ARM: dts: Enable MSI support for Broadcom Cygnus")
>
> And this one too, but the two others, I would probably drop them so we
> can get the backports to be possibly applicable as far as when these two
> commits can be resolved, does that work?
>
Yah that will work. Will make the change. Thanks.
^ permalink raw reply
* [PATCH 1/5] ARM: dts: cygnus: Fix I2C controller interrupt type
From: Ray Jui @ 2018-06-13 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fcb1d93a-3e1a-7020-a104-acc9360855e2@gmail.com>
On 6/13/2018 4:33 PM, Florian Fainelli wrote:
> On 06/13/2018 04:32 PM, Ray Jui wrote:
>>
>>
>> On 6/13/2018 12:49 PM, Florian Fainelli wrote:
>>> On 06/12/2018 01:21 PM, Ray Jui wrote:
>>>> Fix I2C controller interrupt to use IRQ_TYPE_LEVEL_HIGH for Broadcom
>>>> Cygnus SoC
>>>>
>>>> Fixes: b51c05a331ff ("ARM: dts: add I2C device nodes for Broadcom
>>>> Cygnus")
>>>
>>> This appears to be the only one that is truly needed here, the two
>>> others below probably just moved things around but the offending commit
>>> was already introduced in the above commit.
>>>
>>
>> Okay thanks. Will remove the other two "Fixes" below.
>
> I can take care of that while applying the patches, no need for you to
> resubmit, for the whole series I mean.
>
Excellent! Much appreciated!
>>
>>>> Fixes: 0f0b21a83ad2 ("ARM: dts: Move all Cygnus peripherals into axi
>>>> bus")
>>>> Fixes: 9c5101f7a253 ("ARM: dts: Reorder Cygnus peripherals")
>>>>
>>>
>>> There is no need for an extra line between the last Fixes: tag and your
>>> Signed-off-by tag.
>>>
>>
>> Got it, thanks!
>
> And that as well.
>
Thanks again!
Ray
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Florian Fainelli @ 2018-06-14 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0bf3c57c-dac8-8ece-6b8a-3b4d024140fc@broadcom.com>
On 06/13/2018 01:18 PM, Scott Branden wrote:
> Hi Rob,
>
> Thanks for comment - reply inline.
>
>
> On 18-06-13 12:31 PM, Florian Fainelli wrote:
>> On 06/12/2018 03:54 PM, Rob Herring wrote:
>>> On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
>>> <scott.branden@broadcom.com> wrote:
>>>> Hi Rob,
>>>>
>>>> Could you please kindly comment on change below.
>>>>
>>>> It allows board variants to be added easily via a simple define for
>>>> different number of SATA ports.
>>>>
>>>>
>>>>
>>>> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>>>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>>>>> ports based on NUM_SATA defined.
>>>>>> Now, all that needs to be done is define NUM_SATA per board.
>>>>> Rob could you review this and let us know if this approach is okay or
>>>>> not? Thank you!
>>>>>
>>>>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>>>>> ---
>>>>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> index 8c68e0c..7f6d176 100644
>>>>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>>>>> @@ -43,7 +43,11 @@
>>>>>> ???????????????????????? interrupts = <GIC_SPI 321
>>>>>> IRQ_TYPE_LEVEL_HIGH>;
>>>>>> ???????????????????????? #address-cells = <1>;
>>>>>> ???????????????????????? #size-cells = <0>;
>>>>>> +#if (NUM_SATA > 0)
>>>>>> +?????????????????????? status = "okay";
>>>>>> +#else
>>>>>> ???????????????????????? status = "disabled";
>>>>>> +#endif
>>> This only works if ports are contiguously enabled (0-N). You might not
>>> care, but it is not a pattern that works in general.
> Correct - all board designs that include this dtsi file follow such
> commonality (ie. design with SATA0 first, etc).? By having common board
> designs it allows for commonality in dts files rather than duplicating
> information everywhere.? If somebody designs a bizarro board they are
> free to create their own dts file of course.
>>> ? And I'm not a fan
>>> of C preprocessing in DT files in general beyond just defines for
>>> single numbers.
> The use of a define to specify the number of SATA ports in the board
> design meets our requirements of being able to maintain many boards.? We
> need a method to specify the number of ports in the board design rather
> than copying and pasting the information in many dts files.? If you have
> an alternative upstreamable mechanism to manage the configuration of
> many boards without copy and paste that would be ideal?
We had discussed this off-list, but I really think you should be having
some sort of higher level scripting engine which is able to generate
valid per-board DTS files and not have the kernel and its use of the C
pre-processor attempt to solve your problems because a) it's the wrong
place, and b) it is limited.
--
Florian
^ permalink raw reply
* [PATCH v3 0/6] add virt-dma support for imx-sdma
From: Robin Gong @ 2018-06-14 3:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528906072.21021.22.camel@pengutronix.de>
Hi Lucas,
I have identified the root cause besides the lockdep issue.
Will contain the UART patch into my next v4 patchset.
Hi Sascha,
Will address your comments in v4 too. Thank you both input.
On ?, 2018-06-13 at 18:07 +0200, Lucas Stach wrote:
> Hi Robin,
>
> Am Dienstag, den 12.06.2018, 08:58 +0000 schrieb Robin Gong:
> >
> > Hi Lucas,
> > Is the below DEAD LOCK issue same as your side? If yes, then
> > I'm afraid that we have to make another patch for uart to split dma
> > functions in uart driver out of the code area which protected by
> > port.lock. The warning make sense since allocate sdma bd memory
> > dynamically in virt-dma instead of static allocated as before. I'll
> > make another uart patch into my next version patchset.
> Yes, I see the same lockdep splat on my system. Though I'm not sure
> if
> this is really the root cause of the issue I see.
>
> I'm getting timeouts for a serdev attached device and I don't think
> this system ever enters memory reclaim, so the issue reported by
> lockdep seems to be a mostly theoretical on this system. But lets see
> how far I get when you fixed this issue, maybe the real bug is hiding
> behind this one.
>
> Regards,
> Lucas
^ permalink raw reply
* [PATCH 1/3] arm: dts: Fix error in Aspeed OpenPower Romulus device-tree
From: Benjamin Herrenschmidt @ 2018-06-14 3:56 UTC (permalink / raw)
To: linux-arm-kernel
The reserved memory for the VGA frame buffer is at the wrong address
for this system.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
---
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 0b9b37d4d6ef..7d28c03a9e0b 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -21,9 +21,9 @@
#size-cells = <1>;
ranges;
- vga_memory: framebuffer at bf000000 {
+ vga_memory: framebuffer at 9f000000 {
no-map;
- reg = <0xbf000000 0x01000000>; /* 16M */
+ reg = <0x9f000000 0x01000000>; /* 16M */
};
flash_memory: region at 98000000 {
--
2.17.0
^ permalink raw reply related
* [PATCH 2/3] arm: dts: Update AST2500 device-tree
From: Benjamin Herrenschmidt @ 2018-06-14 3:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180614035605.25286-1-benh@kernel.crashing.org>
Add the missing node for the CVIC (the coprocessor interrupt
controller) and add a label to the SRAM node so it can be
referenced from the board device-tree file.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-g5.dtsi | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 17f2714d18a7..251664984398 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -127,6 +127,11 @@
reg = <0x1e6c0080 0x80>;
};
+ cvic: interrupt-controller at 1e6c2000 {
+ compatible = "aspeed,ast2400-cvic";
+ reg = <0x1e6c2000 0x80>;
+ };
+
mac0: ethernet at 1e660000 {
compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e660000 0x180>;
@@ -211,7 +216,7 @@
status = "disabled";
};
- sram at 1e720000 {
+ sram: sram at 1e720000 {
compatible = "mmio-sram";
reg = <0x1e720000 0x9000>; // 36K
};
--
2.17.0
^ permalink raw reply related
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