* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-13 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611081531.xaax5ouvffnarhq5@verge.net.au>
On 06/11/2018 11:15 AM, Simon Horman wrote:
>>> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
>>> 'renesas-devel-20180604-v4.17' tag. 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. These patches depend on the Thine THC63LVD1024
>>> driver and the R8A77980 LVDS support patch in order to work, and R8A77980
>>> GPIO DT patches in order to apply/compile...
>>>
>>> [1/5] arm64: dts: renesas: r8a77980: add FCPVD support
>>> [2/5] arm64: dts: renesas: r8a77980: add VSPD support
>>> [3/5] arm64: dts: renesas: r8a77980: add DU support
>>> [4/5] arm64: dts: renesas: r8a77980: add LVDS support
>>
>> Based on the recent request of the ARM SoC maintainers to avoid a plethora of
>> small patches, I think you can squash 1/5 to 4/5 all together.
>
> Agreed.
>
> Seregi could you please post a v2 with patches 1 - 4 squashed and the
It's going to be v3 already. :-)
> register range for VSPD0 reduced to 0x5000? Thanks!
More like increased. :-)
Working on it...
>>> [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
MBR, Sergei
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Florian Fainelli @ 2018-06-13 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJEFLXFf-Vq9c9XC41vBpisQwxkd06_v8Fmt6X=gp=2_g@mail.gmail.com>
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. And I'm not a fan
> of C preprocessing in DT files in general beyond just defines for
> single numbers.
Should we interpret this as a formal NAK?
--
Florian
^ permalink raw reply
* [PATCH] arm64: dts: hikey960: Define wl1837 power capabilities
From: John Stultz @ 2018-06-13 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613180321.16745-1-ryan@edited.us>
On Wed, Jun 13, 2018 at 11:03 AM, Ryan Grachek <ryan@edited.us> 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
>
> Signed-off-by: Ryan Grachek <ryan@edited.us>
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: John Stultz <john.stultz@linaro.org>
Wei Xu: This also fixes a functional regression with wifi on the
HiKey960 board that was introduced in 4.18-rc with commit 60f36637bbbd
("wlcore: sdio: allow pm to handle sdio power").
Could you please be sure to queue this for the 4.18-rc too?
thanks
-john
^ permalink raw reply
* [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
From: Mathieu Poirier @ 2018-06-13 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <075b99a1-2a29-f6dc-e9f2-99f895c27d35@arm.com>
On 13 June 2018 at 11:07, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
> Hi Matt,
>
> On 13/06/18 16:47, Matt Sealey wrote:
>>
>> Hi Suzuki,
>>
>>>> Why not use ?unit??
>>>>
>>>> I believe we had this discussion years ago about numbering serial ports
>>>> and sdhci (i.e. how do you know it?s UART0 or UART1 from just the
>>>> address?
>>>> Some SoC?s don?t address sequentially *or* in a forward direction) - I
>>>> believe it?s not exactly codified in ePAPR, not am I sure where it may
>>>> be
>>>> otherwise, but it exists.
>>>
>>>
>>> We have different situation here. We need to know *the port number* as
>>> understood by the hardware, so that we can enable *the specific* port for
>>> a given path.
>>
>>
>> For the purposes of abstraction, each port will have the property of
>> having
>> a node which is pointed to by other nodes, and in the case of a true ATB
>> endpoint, no other nodes behind it.
>>
>> It doesn't matter what the HW numbers it as as long as the driver can
>> derive
>> it from whatever you put in the DT. So a funnel (which is ~8 ports muxed
>> into
>> one output):
>>
>> f1p0: port {
>> unit = <0>;
>> endpoint = <&f1out>;
>> };
>> f1p1: port {
>> unit = <4>;
>> endpoint = <&f1out>;
>> };
>> f1out: port {
>> endpoint = <&etf1>;
>> };
>>
>> "unit" here is specific to the driver's understanding of ports within it's
>
>
> I may be missing, but is "unit" something that already exists and used by
> DT bindings already ? Or is this something new that we are proposing ?
>
>> own cycle of the graph. For a replicator you can invert the logic - input
>> ports don't need a unit, but the two outputs are filtered in CoreSight not
>
>
> I would prefer to make the new property mandatory for all the ports to avoid
> a potential problem in the future.
>
> How do you represent a TMC-ETF which has one input and one output connection
> ?
> Also what happens if we ever get a component which has m-to-n connections ?
>
>> by leg but by transiting ATB ID in groups of 16 IDs. In that case maybe
>> you would want to describe all 8 possible units on each leg with the first
>> ID it would filter? Or just list tuples of filter IDs <id, first, last>
>
>
> I am failing to follow the ATB ID group description above. As per the TRM,
> e.g, replicator filters the "trace stream" based on the "trace ID", which I
> believe can be programmed via IDFILTER<n> register. So why would we need
> that
> to be part of the DT ?
>
>>
>> Who cares, really, as long as the driver knows what it means.
>>
>> You don't need to namespace every property.
>>
>>> As I mentioned above, we need the hardware numbers to enable the
>>> "specific" port.
>>
>>
>> Okay and how is this not able to be prescribed in a binding for
>> "arm,coresight-funnel"
>> that:
>>
>> "input ports are numbered from 0 to N where N is the maximum input port
>> number. This number is identified with the "unit" property, which directly
>> corresponds to the bit position in the funnel Ctrl_Reg register, and the
>> bit position multiplied by 3 for each 3-bit priority in the funnel
>> Priority_Ctrl_Reg, with N having a maximum of the defined register
>> bitfield
>> DEVID[PORTCOUNT], minus one, for that component"
>
>
> The description looks over complicated to me at least, even after having
> known
> bit of the programming interface of the components. I would prefer staying
> closer to the terms used in the TRM ("slave/master" interfaces) and make it
> easier for people to write the DT.
>
>>
>> Or a replicator:
>>
>> "output ports are numbered per the CoreSight ATB Replicator specification,
>> unit corresponding to the IDFILTERn register controlling ID filters for
>> that leg, with a maximum of the defined register bitfield DEVID[PORTNUM],
>> minus one"
>>
>> One could clarify it, even, with labels for readability ("label"
>> definitely
>> is a well defined if also completely arbitrary property).
>>
>> ..
>>
>>> static void funnel_enable_hw(struct funnel_drvdata *drvdata, int port)
>>> {
>>> u32 functl;
>>>
>>> CS_UNLOCK(drvdata->base);
>>>
>>> functl = readl_relaxed(drvdata->base + FUNNEL_FUNCTL);
>>> functl &= ~FUNNEL_HOLDTIME_MASK;
>>> functl |= FUNNEL_HOLDTIME;
>>> functl |= (1 << port);
>>> writel_relaxed(functl, drvdata->base + FUNNEL_FUNCTL);
>>> writel_relaxed(drvdata->priority, drvdata->base +
>>> FUNNEL_PRICTL);
>>>
>>> CS_LOCK(drvdata->base);
>>> }
>>>
>>> No we don't need to parse it in both ways, up and down. Btw, the trace
>>> paths are not statically created. They are done at runtime, as configured
>>> by the user.
>>
>>
>> You do realize this isn't how the hardware works, correct?
>
>
> The "trace paths" mentioned above were indeed the software path, which
> was constructed at runtime. The graph connections are indeed a one time
> parsing at probe time and as you said they don't change. And by configuring,
> I mean selecting the "source" and the "sink".
>
>>
>> Trace paths are fixed, they may diverge with different configurations, but
>> the full CoreSight topology (all funnels, replicators and intermediary
>> Components) is entirely unchangeable.
>>
>> The DT should provide the information to provide a reference acyclic
>> directed
>> graph of the entire topology (or entirely reasonably programmable topology
>> where
>> at all possible) - if a user wants to trace from ETM_0 then they only
>> have particular paths to particular sinks, for instance ETM_0 and ETF_0
>> may be on their own path, so you cannot just "configure as a user"
>> a path from ETM_1 to ETF_0 since there isn't one.
>
>
>>
>> Walking said graphs with the knowledge that CoreSight specifically
>> disallows
>> loopbacks in ATB topology is basic computer science problem - literally a
>> matter of topological sorting. But let's build a graph once and traverse
>> it -
>> don't build the graph partially each time or try and build it to
>> cross-check
>> every time. The paths are wires in the design, lets not fake to the user
>> that there is any configurability in that or try and encode that in the
>> DT.
>
>
> Sorry for the confusion, as explained above, it is indeed a one time pass.
>
>>
>>> Coming back to your suggestion of "unit", what does it imply ?
>>
>>
>> Whatever the driver likes. For uart and mmc, it was just a spurious number
>> but it could be applied as the end of, say, ttyS<N> or mmcblk<N>p3 or used
>> in any other driver-specific manner. The number you put in is up to you,
>> but the valid numbers would be in the binding for that particular device.
>>
>>> Its too generic a term for something as concrete as a port number.
>>
>>
>> Is it?
>>
>> Why would you need a whole other property type to encode a u32 that
>> describes an arbitrary number specific to that hardware device?
>
>
> 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.
Mathieu
>
>
> Thanks for the comments.
>
> Cheers,
> Suzuki
^ permalink raw reply
* [PATCH 1/5] ARM: dts: cygnus: Fix I2C controller interrupt type
From: Florian Fainelli @ 2018-06-13 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-2-git-send-email-ray.jui@broadcom.com>
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.
> 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.
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 9fe4f5a..835a6f7 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -216,7 +216,7 @@
> reg = <0x18008000 0x100>;
> #address-cells = <1>;
> #size-cells = <0>;
> - interrupts = <GIC_SPI 85 IRQ_TYPE_NONE>;
> + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <100000>;
> status = "disabled";
> };
> @@ -245,7 +245,7 @@
> reg = <0x1800b000 0x100>;
> #address-cells = <1>;
> #size-cells = <0>;
> - interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
> + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <100000>;
> status = "disabled";
> };
>
--
Florian
^ permalink raw reply
* [PATCH 2/5] ARM: dts: cygnus: Fix PCIe controller interrupt type
From: Florian Fainelli @ 2018-06-13 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-3-git-send-email-ray.jui@broadcom.com>
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?
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 835a6f7..2c4df2d 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -256,7 +256,7 @@
>
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
> + interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
>
> linux,pci-domain = <0>;
>
> @@ -278,10 +278,10 @@
> compatible = "brcm,iproc-msi";
> msi-controller;
> interrupt-parent = <&gic>;
> - interrupts = <GIC_SPI 96 IRQ_TYPE_NONE>,
> - <GIC_SPI 97 IRQ_TYPE_NONE>,
> - <GIC_SPI 98 IRQ_TYPE_NONE>,
> - <GIC_SPI 99 IRQ_TYPE_NONE>;
> + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
> @@ -291,7 +291,7 @@
>
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
> + interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
>
> linux,pci-domain = <1>;
>
> @@ -313,10 +313,10 @@
> compatible = "brcm,iproc-msi";
> msi-controller;
> interrupt-parent = <&gic>;
> - interrupts = <GIC_SPI 102 IRQ_TYPE_NONE>,
> - <GIC_SPI 103 IRQ_TYPE_NONE>,
> - <GIC_SPI 104 IRQ_TYPE_NONE>,
> - <GIC_SPI 105 IRQ_TYPE_NONE>;
> + interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
>
--
Florian
^ permalink raw reply
* [PATCH v3 0/2] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-13 20:09 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180613-v4.17' tag and the Condor/V3HSK TD patches adding
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 v3 1/2] arm64: dts: renesas: r8a77980: add FCPVD/VSPD/DU/LVDS support
From: Sergei Shtylyov @ 2018-06-13 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95d0db34-713d-8206-00c2-ee9a42aab823@cogentembedded.com>
Describe the interconnected FCPVD0, VSPD0, DU, and LVDS0 devices in the
R8A77980 device tree...
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>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes in version 3:
- merged in the VSPD/DU/LVDS patches, renamed the patch, and updated the patch
description accordingly;
- fixed the VSPD0's "reg" property.
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 77 ++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,83 @@
resets = <&cpg 408>;
};
+ vspd0: vsp at fea20000 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea20000 0 0x5000>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
+ fcpvd0: fcp at fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ };
+
+ du: display at feb00000 {
+ compatible = "renesas,du-r8a77980",
+ "renesas,du-r8a77970";
+ reg = <0 0xfeb00000 0 0x80000>;
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 724>;
+ clock-names = "du.0";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 724>;
+ vsps = <&vspd0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder at feb90000 {
+ compatible = "renesas,r8a77980-lvds";
+ reg = <0 0xfeb90000 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
+ <&du_out_lvds0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ lvds0_out: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [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
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