* [PATCH 3/3] arm64: dts: allwinner: add support for Pinebook
From: Maxime Ripard @ 2018-06-01 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601062901.8052-4-anarsoul@gmail.com>
On Thu, May 31, 2018 at 11:29:01PM -0700, Vasily Khoruzhick wrote:
> From: Icenowy Zheng <icenowy@aosc.xyz>
>
> Pinebook is a A64-based laptop produced by Pine64, with the following
> peripherals:
>
> USB:
> - Two external USB ports (one is directly connected to A64's OTG
> controller, the other is under a internal hub connected to the host-only
> controller.)
> - USB HID keyboard and touchpad connected to the internal hub.
> - USB UVC camera connected to the internal hub.
>
> Power-related:
> - A DC IN jack connected to AXP803's DCIN pin.
> - A Li-Polymer battery connected to AXP803's battery pins.
>
> Storage:
> - An eMMC by Foresee on the main board (in the product revision of the
> main board it's designed to be switchable).
> - An external MicroSD card slot.
>
> Display:
> - An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
> - A mini HDMI port.
>
> Misc:
> - A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
> - A headphone jack connected to the SoC's internal codec.
> - A debug UART port muxed with headphone jack.
>
> This commit adds basical support for it.
>
> [vasily: squashed several commits into one, added simplefb node, added usbphy
> to ehci0 and ohci0 nodes]
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-a64-pinebook.dts | 285 ++++++++++++++++++
> 2 files changed, 286 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 8bebe7da5ed9..a8c6d0c6f2c5 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> new file mode 100644
> index 000000000000..d952db217702
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
> @@ -0,0 +1,285 @@
> +/*
> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
> + * Copyright (C) 2018 Vasily Khoruzhick <anarsoul@gmail.com>
> + *
> + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
The SPDX tag should be the first one.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pwm/pwm.h>
> +
> +/ {
> + model = "Pinebook";
> + compatible = "pine64,pinebook", "allwinner,sun50i-a64";
> +
> + aliases {
> + serial0 = &uart0;
> + ethernet0 = &rtl8723cs;
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 50000 0>;
> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
The perceived brightness should be increasing linearly. This usually
means that you need an function close to a power of two sequence.
> + default-brightness-level = <2>;
> + enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> +
> + framebuffer-lcd {
> + panel-supply = <®_dc1sw>;
> + dvdd25-supply = <®_dldo2>;
> + dvdd12-supply = <®_fldo1>;
> + };
> + };
> +
> + gpio_keys {
> + compatible = "gpio-keys";
> +
> + lid_switch {
> + label = "Lid Switch";
> + gpios = <&r_pio 0 12 GPIO_ACTIVE_LOW>; /* PL12 */
> + linux,input-type = <EV_SW>;
> + linux,code = <SW_LID>;
> + linux,can-disable;
> + };
> + };
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> + };
> +};
> +
> +&ehci0 {
> + phys = <&usbphy 0>;
> + phy-names = "usb";
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> + vmmc-supply = <®_dcdc1>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> + disable-wp;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_dldo4>;
> + vqmmc-supply = <®_eldo1>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + rtl8723cs: wifi at 1 {
> + reg = <1>;
> + };
> +};
> +
> +&mmc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_pins>;
> + vmmc-supply = <®_dcdc1>;
> + vqmmc-supply = <®_eldo1>;
> + bus-width = <8>;
> + non-removable;
> + cap-mmc-hw-reset;
> + mmc-hs200-1_8v;
> + status = "okay";
> +};
> +
> +&ohci0 {
> + phys = <&usbphy 0>;
> + phy-names = "usb";
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&pwm {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm_pin>;
> + status = "okay";
> +};
> +
> +&r_rsb {
> + status = "okay";
> +
> + axp803: pmic at 3a3 {
> + compatible = "x-powers,axp803";
> + reg = <0x3a3>;
> + interrupt-parent = <&r_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + };
> +};
> +
> +/* The ANX6345 eDP-bridge is on r_i2c. There is no linux (mainline)
> + * driver for this chip at the moment, the bootloader initializes it.
> + * However it can be accessed with the i2c-dev driver from user space.
> + */
The comment format is wrong, and the part after r_i2c, about i2c-dev
and the mainline support is not really relevant. The DT describes the
hardware, and is used by several different projects that might or
might not have i2c-dev, an interface similar, or might have or not a
driver for the bridge.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180601/48c13123/attachment.sig>
^ permalink raw reply
* [PATCH 05/11] ARM: dts: Reflect change of FSL QSPI driver and remove unused properties
From: Frieder Schrempf @ 2018-06-01 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530171057.39f1a2be@bbrezillon>
Hi Boris,
On 30.05.2018 17:10, Boris Brezillon wrote:
> On Wed, 30 May 2018 15:14:34 +0200
> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>
>> The FSL QSPI driver was moved to the SPI framework and it now
>> acts as a SPI controller. Therefore the subnodes need to set
>> spi-[rx/tx]-bus-width = <4>, so quad mode is used just as before.
>
> We should try to keep the current behavior even when
> spi-[rx/tx]-bus-width are not defined. How about considering
> spi-[rx/tx]-bus-width as board constraints and then let the core pick
> the best mode based on these constraints plus the SPI NOR chip
> limitations.
Ok, I'll try to adjust this, so we can leave spi-[rx/tx]-bus-width
undefined and still get quad mode as default if possible.
>
>>
>> Also the properties 'bus-num', 'fsl,spi-num-chipselects' and
>> 'fsl,spi-flash-chipselects' were never read by the driver and
>> can be removed.
>>
>> The 'reg' properties are adjusted to reflect the what bus and
>> chipselect the flash is connected to, as the new driver needs
>> this information.
>>
>> The property 'fsl,qspi-has-second-chip' is not needed anymore
>> and will be removed after the old driver was disabled to avoid
>> breaking ls1021a-moxa-uc-8410a.dts.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>> arch/arm/boot/dts/imx6sx-sdb-reva.dts | 8 ++++++--
>> arch/arm/boot/dts/imx6sx-sdb.dts | 8 ++++++--
>> arch/arm/boot/dts/imx6ul-14x14-evk.dtsi | 2 ++
>> arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 5 ++---
>> 4 files changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6sx-sdb-reva.dts b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
>> index e3533e7..1a6f680 100644
>> --- a/arch/arm/boot/dts/imx6sx-sdb-reva.dts
>> +++ b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
>> @@ -131,13 +131,17 @@
>> #size-cells = <1>;
>> compatible = "spansion,s25fl128s", "jedec,spi-nor";
>> spi-max-frequency = <66000000>;
>> + spi-rx-bus-width = <4>;
>> + spi-tx-bus-width = <4>;
>> };
>>
>> - flash1: s25fl128s at 1 {
>> - reg = <1>;
>> + flash1: s25fl128s at 2 {
>> + reg = <2>;
>
> Hm, you're breaking backward compat here. Can we try to re-use the
> old numbering scheme instead of patching all DTs?
Unfortunately in the current setup, the definitions for the reg property
are already broken.
For example imx6sx-sdb.dts seems to have one chip connected on bus A,
CS0 and one on bus B, CS0. It has reg set to 0 for the first and 1 for
the second chip.
While fsl-ls208xa-qds.dtsi uses the same hw setup, but has reg set to 0
and 2.
So either way we need to change the reg property at some place.
So the best approach in my opinion is to fix the definitions to use a
single scheme and while at it also remove the fsl,qspi-has-second-chip
property, that is not needed if a single consistent scheme for the reg
properties is used.
Regards,
Frieder
^ permalink raw reply
* [PATCH 0/4] lib/vsprintf: Remove atomic-unsafe support for printk format %pCr
From: Geert Uytterhoeven @ 2018-06-01 9:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
"%pCr" formats the current rate of a clock, and calls clk_get_rate().
The latter obtains a mutex, hence it must not be called from atomic
context. As vsprintf() (and e.g. printk()) must be callable from any
context, it's better to remove support for this (rarely-used) format.
This patch series:
- Changes all existing users of "%pCr" to print the result of
clk_get_rate() directly, which is safe as they all do this in task
context only,
- Removes support for the "%pCr" printk format.
Note that any remaining out-of-tree users will start seeing the clock's
name printed instead of its rate.
Thanks for your comments!
Geert Uytterhoeven (4):
clk: renesas: cpg-mssr: Stop using printk format %pCr
thermal: bcm2835: Stop using printk format %pCr
serial: sh-sci: Stop using printk format %pCr
lib/vsprintf: Remove atomic-unsafe support for %pCr
Documentation/core-api/printk-formats.rst | 3 +--
drivers/clk/renesas/renesas-cpg-mssr.c | 9 +++++----
drivers/thermal/broadcom/bcm2835_thermal.c | 4 ++--
drivers/tty/serial/sh-sci.c | 4 ++--
lib/vsprintf.c | 3 ---
5 files changed, 10 insertions(+), 13 deletions(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/4] clk: renesas: cpg-mssr: Stop using printk format %pCr
From: Geert Uytterhoeven @ 2018-06-01 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-1-git-send-email-geert+renesas@glider.be>
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/clk/renesas/renesas-cpg-mssr.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c b/drivers/clk/renesas/renesas-cpg-mssr.c
index 49e510691eeeab07..f4b013e9352d9efc 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -258,8 +258,9 @@ struct clk *cpg_mssr_clk_src_twocell_get(struct of_phandle_args *clkspec,
dev_err(dev, "Cannot get %s clock %u: %ld", type, clkidx,
PTR_ERR(clk));
else
- dev_dbg(dev, "clock (%u, %u) is %pC at %pCr Hz\n",
- clkspec->args[0], clkspec->args[1], clk, clk);
+ dev_dbg(dev, "clock (%u, %u) is %pC at %lu Hz\n",
+ clkspec->args[0], clkspec->args[1], clk,
+ clk_get_rate(clk));
return clk;
}
@@ -326,7 +327,7 @@ static void __init cpg_mssr_register_core_clk(const struct cpg_core_clk *core,
if (IS_ERR_OR_NULL(clk))
goto fail;
- dev_dbg(dev, "Core clock %pC at %pCr Hz\n", clk, clk);
+ dev_dbg(dev, "Core clock %pC at %lu Hz\n", clk, clk_get_rate(clk));
priv->clks[id] = clk;
return;
@@ -392,7 +393,7 @@ static void __init cpg_mssr_register_mod_clk(const struct mssr_mod_clk *mod,
if (IS_ERR(clk))
goto fail;
- dev_dbg(dev, "Module clock %pC at %pCr Hz\n", clk, clk);
+ dev_dbg(dev, "Module clock %pC at %lu Hz\n", clk, clk_get_rate(clk));
priv->clks[id] = clk;
priv->smstpcr_saved[clock->index / 32].mask |= BIT(clock->index % 32);
return;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] thermal: bcm2835: Stop using printk format %pCr
From: Geert Uytterhoeven @ 2018-06-01 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-1-git-send-email-geert+renesas@glider.be>
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by printing the variable that already holds the clock rate.
Note that calling clk_get_rate() is safe here, as the code runs in task
context.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/thermal/broadcom/bcm2835_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/broadcom/bcm2835_thermal.c b/drivers/thermal/broadcom/bcm2835_thermal.c
index a4d6a0e2e9938190..23ad4f9f21438e45 100644
--- a/drivers/thermal/broadcom/bcm2835_thermal.c
+++ b/drivers/thermal/broadcom/bcm2835_thermal.c
@@ -213,8 +213,8 @@ static int bcm2835_thermal_probe(struct platform_device *pdev)
rate = clk_get_rate(data->clk);
if ((rate < 1920000) || (rate > 5000000))
dev_warn(&pdev->dev,
- "Clock %pCn running at %pCr Hz is outside of the recommended range: 1.92 to 5MHz\n",
- data->clk, data->clk);
+ "Clock %pCn running at %lu Hz is outside of the recommended range: 1.92 to 5MHz\n",
+ data->clk, rate);
/* register of thermal sensor and get info from DT */
tz = thermal_zone_of_sensor_register(&pdev->dev, 0, data,
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] serial: sh-sci: Stop using printk format %pCr
From: Geert Uytterhoeven @ 2018-06-01 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-1-git-send-email-geert+renesas@glider.be>
Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
called in atomic context.
Replace it by open-coding the operation. This is safe here, as the code
runs in task context.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index b46b146524ce7495..c181eb37f98509e6 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2724,8 +2724,8 @@ static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
dev_dbg(dev, "failed to get %s (%ld)\n", clk_names[i],
PTR_ERR(clk));
else
- dev_dbg(dev, "clk %s is %pC rate %pCr\n", clk_names[i],
- clk, clk);
+ dev_dbg(dev, "clk %s is %pC rate %lu\n", clk_names[i],
+ clk, clk_get_rate(clk));
sci_port->clks[i] = IS_ERR(clk) ? NULL : clk;
}
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] lib/vsprintf: Remove atomic-unsafe support for %pCr
From: Geert Uytterhoeven @ 2018-06-01 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-1-git-send-email-geert+renesas@glider.be>
"%pCr" formats the current rate of a clock, and calls clk_get_rate().
The latter obtains a mutex, hence it must not be called from atomic
context.
Remove support for this rarely-used format, as vsprintf() (and e.g.
printk()) must be callable from any context.
Any remaining out-of-tree users will start seeing the clock's name
printed instead of its rate.
Reported-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Fixes: 900cca2944254edd ("lib/vsprintf: add %pC{,n,r} format specifiers for clocks")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/core-api/printk-formats.rst | 3 +--
lib/vsprintf.c | 3 ---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst
index eb30efdd2e789616..25dc591cb1108790 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -419,11 +419,10 @@ struct clk
%pC pll1
%pCn pll1
- %pCr 1560000000
For printing struct clk structures. %pC and %pCn print the name
(Common Clock Framework) or address (legacy clock framework) of the
-structure; %pCr prints the current clock rate.
+structure.
Passed by reference.
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 247a7e0bf24f6f74..a48aaa79d352313a 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1469,9 +1469,6 @@ char *clock(char *buf, char *end, struct clk *clk, struct printf_spec spec,
return string(buf, end, NULL, spec);
switch (fmt[1]) {
- case 'r':
- return number(buf, end, clk_get_rate(clk), spec);
-
case 'n':
default:
#ifdef CONFIG_COMMON_CLK
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] thermal: bcm2835: Stop using printk format %pCr
From: Stefan Wahren @ 2018-06-01 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527845302-12159-3-git-send-email-geert+renesas@glider.be>
Am 01.06.2018 um 11:28 schrieb Geert Uytterhoeven:
> Printk format "%pCr" will be removed soon, as clk_get_rate() must not be
> called in atomic context.
>
> Replace it by printing the variable that already holds the clock rate.
> Note that calling clk_get_rate() is safe here, as the code runs in task
> context.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Thanks
^ permalink raw reply
* [PATCH 0/4] arm64/mm: migrate swapper_pg_dir
From: Robin Murphy @ 2018-06-01 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601080819.11712-1-yaojun8558363@gmail.com>
On 01/06/18 09:08, Jun Yao wrote:
> Currently, The offset between swapper_pg_dir and _text is
> fixed. When attackers know the address of _text(no KASLR or
> breaking KASLR), they can caculate the address of
> swapper_pg_dir. Then KSMA(Kernel Space Mirroring Attack) can
> be applied.
>
> The principle of KSMA is to insert a carefully constructed PGD
> entry into the translation table. The type of this entry is
Out of interest, how does that part work? AFAICS, modifying a PGD entry
involves writing to kernel memory, which would mean the implication of
KSMA is "userspace can gain write permission to kernel memory by writing
to kernel memory" - that doesn't sound like an attack in itself, more
just a convenience for ease of exploiting whatever successful attack got
you in there in the first place.
That's not to say that it isn't still worth mitigating, I'm just
questioning the given rationale here.
Robin.
> block, which maps the kernel text and its access permissions
> bits are 01. The user process can then modify kernel text
> directly through this mapping.
>
> To protect against KSMA, these patches migrate swapper_pg_dir
> to new place, which is dynamically allocated. Since it is
> allocated during the kernel boot process and the address is
> relatively fixed, further randomization may be required.
>
> Jun Yao (4):
> arm64/mm: pass swapper_pg_dir as an argument to __enable_mmu()
> arm64/mm: introduce variable to save new swapper_pg_dir address
> arm64/mm: make tramp_pg_dir and swapper_pg_dir adjacent
> arm64/mm: migrate swapper_pg_dir and tramp_pg_dir
>
> arch/arm64/include/asm/mmu_context.h | 6 +--
> arch/arm64/include/asm/pgtable.h | 2 +
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/kernel/entry.S | 4 +-
> arch/arm64/kernel/head.S | 10 ++--
> arch/arm64/kernel/hibernate.c | 2 +-
> arch/arm64/kernel/sleep.S | 2 +
> arch/arm64/kernel/vmlinux.lds.S | 9 ++--
> arch/arm64/mm/kasan_init.c | 6 +--
> arch/arm64/mm/mmu.c | 75 +++++++++++++++++-----------
> 10 files changed, 71 insertions(+), 47 deletions(-)
>
^ permalink raw reply
* [PATCH] KVM: arm64: VHE: Migrate _elx sysreg accessors to msr_s/mrs_s
From: Mark Rutland @ 2018-06-01 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527603647-24787-1-git-send-email-Dave.Martin@arm.com>
Hi,
On Tue, May 29, 2018 at 03:20:47PM +0100, Dave Martin wrote:
> Currently, the {read,write}_sysreg_el*() accessors for accessing
> particular ELs' sysregs in the presence of VHE rely on some local
> hacks and define their system register encodings in a way that is
> inconsistent with the core definitions in <asm/sysreg.h>.
>
> As a result, it is necessary to add duplicate definitions for any
> system register that already needs a definition in sysreg.h for
> other reasons.
>
> This is a bit of a maintenance headache, and the reasons for the
> _el*() accessors working the way they do is a bit historical.
>
> This patch gets rid of the shadow sysreg definitions in
> <asm/kvm_hyp.h>, converts the _el*() accessors to use the core
> msr_s/mrs_s interface, and converts all call sites to use the
> standard sysreg #define names (i.e., upper case, with SYS_ prefix).
Nice!
[...]
> static inline unsigned long vcpu_read_elr_el1(const struct kvm_vcpu *vcpu)
> {
> if (vcpu->arch.sysregs_loaded_on_cpu)
> - return read_sysreg_el1(elr);
> + return read_sysreg_el1(SYS_ELR);
Could we have the macro implicitly handle the SYS_ prefix?
A further bit of cleanup that I'd like to do is make {read,write}_sysreg() use
{mrs,msr}_s, implicitly handling the SYS_ prefix, so that we can kill off
{read,write}_sysreg_s(), and always use a {read,write}_sysreg().
A minor pain point is that we'd have to convert callers to pass the sysreg name
in upper-case, but that conversion can be scripted fairly easily.
e.g. for the above, read_sysreg() would take ELR_EL1, and read_sysreg_el1()
would take ELR.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 4/4] arm64/mm: migrate swapper_pg_dir and tramp_pg_dir
From: Robin Murphy @ 2018-06-01 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601080918.11918-1-yaojun8558363@gmail.com>
On 01/06/18 09:09, Jun Yao wrote:
> Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
> do not correlate with kernel's address.
I think this might break software PAN, which IIRC depends on the
reserved TTBR0 PGD being physically adjacent to the live swapper PGD for
the trickery in __uaccess_ttbr0_{en,dis}able() to work.
Robin.
> Signed-off-by: Jun Yao <yaojun8558363@gmail.com>
> ---
> arch/arm64/mm/mmu.c | 70 +++++++++++++++++++++++++++------------------
> 1 file changed, 42 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 26ba3e70a91c..5baae59479d8 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -57,6 +57,9 @@ EXPORT_SYMBOL(kimage_voffset);
>
> phys_addr_t __pa_swapper_pg_dir;
> pgd_t *new_swapper_pg_dir = swapper_pg_dir;
> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> +pgd_t *new_tramp_pg_dir;
> +#endif
>
> /*
> * Empty_zero_page is a special page that is used for zero-initialized data
> @@ -80,19 +83,14 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
> }
> EXPORT_SYMBOL(phys_mem_access_prot);
>
> -static phys_addr_t __init early_pgtable_alloc(void)
> +static void __init clear_page_phys(phys_addr_t phys)
> {
> - phys_addr_t phys;
> - void *ptr;
> -
> - phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
> -
> /*
> * The FIX_{PGD,PUD,PMD} slots may be in active use, but the FIX_PTE
> * slot will be free, so we can (ab)use the FIX_PTE slot to initialise
> * any level of table.
> */
> - ptr = pte_set_fixmap(phys);
> + void *ptr = pte_set_fixmap(phys);
>
> memset(ptr, 0, PAGE_SIZE);
>
> @@ -101,6 +99,14 @@ static phys_addr_t __init early_pgtable_alloc(void)
> * table walker
> */
> pte_clear_fixmap();
> +}
> +
> +static phys_addr_t __init early_pgtable_alloc(void)
> +{
> + phys_addr_t phys;
> +
> + phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
> + clear_page_phys(phys);
>
> return phys;
> }
> @@ -554,6 +560,10 @@ static int __init map_entry_trampoline(void)
> __create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
> prot, pgd_pgtable_alloc, 0);
>
> + memcpy(new_tramp_pg_dir, tramp_pg_dir, PGD_SIZE);
> + memblock_free(__pa_symbol(tramp_pg_dir),
> + __pa_symbol(swapper_pg_dir) - __pa_symbol(tramp_pg_dir));
> +
> /* Map both the text and data into the kernel page table */
> __set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> @@ -631,36 +641,40 @@ static void __init map_kernel(pgd_t *pgdp)
> */
> void __init paging_init(void)
> {
> - phys_addr_t pgd_phys = early_pgtable_alloc();
> - pgd_t *pgdp = pgd_set_fixmap(pgd_phys);
> + phys_addr_t pgd_phys;
> + pgd_t *pgdp;
> +
> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> + phys_addr_t mem_size;
> + phys_addr_t p;
>
> - __pa_swapper_pg_dir = __pa_symbol(swapper_pg_dir);
> + mem_size = __pa_symbol(swapper_pg_dir) + PAGE_SIZE
> + - __pa_symbol(tramp_pg_dir);
> + pgd_phys = memblock_alloc(mem_size, PAGE_SIZE);
> +
> + for (p = pgd_phys; p < pgd_phys + mem_size; p += PAGE_SIZE)
> + clear_page_phys(p);
> +
> + new_tramp_pg_dir = __va(pgd_phys);
> + __pa_swapper_pg_dir = pgd_phys + PAGE_SIZE;
> +#else
> + pgd_phys = early_pgtable_alloc();
> + __pa_swapper_pg_dir = pgd_phys;
> +#endif
> + new_swapper_pg_dir = __va(__pa_swapper_pg_dir);
> +
> + pgdp = pgd_set_fixmap(__pa_swapper_pg_dir);
>
> map_kernel(pgdp);
> map_mem(pgdp);
>
> - /*
> - * We want to reuse the original swapper_pg_dir so we don't have to
> - * communicate the new address to non-coherent secondaries in
> - * secondary_entry, and so cpu_switch_mm can generate the address with
> - * adrp+add rather than a load from some global variable.
> - *
> - * To do this we need to go via a temporary pgd.
> - */
> - cpu_replace_ttbr1(pgd_phys);
> - memcpy(swapper_pg_dir, pgdp, PGD_SIZE);
> cpu_replace_ttbr1(__pa_swapper_pg_dir);
> + init_mm.pgd = new_swapper_pg_dir;
>
> pgd_clear_fixmap();
> - memblock_free(pgd_phys, PAGE_SIZE);
>
> - /*
> - * We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
> - * allocated with it.
> - */
> - memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
> - __pa_symbol(swapper_pg_end) - __pa_symbol(swapper_pg_dir)
> - - PAGE_SIZE);
> + memblock_free(__pa_symbol(swapper_pg_dir),
> + __pa_symbol(swapper_pg_end) - __pa_symbol(swapper_pg_dir));
> }
>
> /*
>
^ permalink raw reply
* [PATCH v1 1/2] ACPI / APEI: Add SEI notification type support for ARMv8
From: gengdongjiu @ 2018-06-01 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531105252.it67drvnsfz62pqa@lakrids.cambridge.arm.com>
Hi Mark,
Thanks for the comments.
On 2018/5/31 18:52, Mark Rutland wrote:
> On Thu, May 31, 2018 at 08:41:45PM +0800, Dongjiu Geng wrote:
>> +#ifdef CONFIG_ACPI_APEI_SEI
>> +static LIST_HEAD(ghes_sei);
>> +
>> +/*
>> + * Return 0 only if one of the SEI error sources successfully reported an error
>> + * record sent from the firmware.
>> + */
>> +int ghes_notify_sei(void)
>> +{
>> + struct ghes *ghes;
>> + int ret = -ENOENT;
>> +
>> + rcu_read_lock();
>> + list_for_each_entry_rcu(ghes, &ghes_sei, list) {
>> + if (!ghes_proc(ghes))
>> + ret = 0;
>> + }
>> + rcu_read_unlock();
>> + return ret;
>> +}
>> +
>> +static void ghes_sei_add(struct ghes *ghes)
>> +{
>> + mutex_lock(&ghes_list_mutex);
>> + list_add_rcu(&ghes->list, &ghes_sei);
>> + mutex_unlock(&ghes_list_mutex);
>> +}
>> +
>> +static void ghes_sei_remove(struct ghes *ghes)
>> +{
>> + mutex_lock(&ghes_list_mutex);
>> + list_del_rcu(&ghes->list);
>> + mutex_unlock(&ghes_list_mutex);
>> + synchronize_rcu();
>> +}
>> +#else /* CONFIG_ACPI_APEI_SEI */
>> +static inline void ghes_sei_add(struct ghes *ghes) { }
>> +static inline void ghes_sei_remove(struct ghes *ghes) { }
>> +#endif /* CONFIG_ACPI_APEI_SEI */
>> +
>> #ifdef CONFIG_HAVE_ACPI_APEI_NMI
>> /*
>
>> index 8feb0c8..9ba59e2 100644
>> --- a/include/acpi/ghes.h
>> +++ b/include/acpi/ghes.h
>> @@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata)
>> section = acpi_hest_get_next(section))
>>
>> int ghes_notify_sea(void);
>> +int ghes_notify_sei(void);
>
> It would be nice to have a stub definition when !CONFIG_ACPI_APEI_SEI,
> e.g.
>
> #ifdef CONFIG_ACPI_APEI_SEI
> int ghes_notify_sei(void);
> #else
> static in int ghes_notify_sei(void) { return -ENOENT; }
> #endif
>
> ... as callers could simply call this without additional checks.
>
> As a cleanup, similar would be nice for ghes_notify_sea() with
> CONFIG_ACPI_APEI_SEA.
I think your suggestion is better, I will do the cleanup include the ghes_notify_sea().
thanks again.
>
> Thanks,
> Mark.
>
> .
>
^ permalink raw reply
* [PATCH v6 0/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-06-01 10:10 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for telling userspace the size of the signal
frame via a new AT_MINSIGSTKSZ entry in the aux vector.
This is an update to [1]. An omitted AT_MINSIGSTKSZ is now replaced
with an AT_IGNORE entry instead of being collapsed out of the auxv
entirely.
See individual patches for the delta.
[1] [PATCH v5 0/2] arm64: signal: Report signal frame size to userspace via auxv
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/580974.html
Dave Martin (2):
arm64/sve: Thin out initialisation sanity-checks for sve_max_vl
arm64: signal: Report signal frame size to userspace via auxv
arch/arm64/include/asm/elf.h | 13 +++++++++
arch/arm64/include/asm/processor.h | 5 ++++
arch/arm64/include/uapi/asm/auxvec.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/fpsimd.c | 17 +++---------
arch/arm64/kernel/ptrace.c | 3 ---
arch/arm64/kernel/signal.c | 52 +++++++++++++++++++++++++++++++-----
7 files changed, 70 insertions(+), 24 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v6 1/2] arm64/sve: Thin out initialisation sanity-checks for sve_max_vl
From: Dave Martin @ 2018-06-01 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527847814-22829-1-git-send-email-Dave.Martin@arm.com>
Now that the kernel SVE support is reasonably mature, it is
excessive to default sve_max_vl to the invalid value -1 and then
sprinkle WARN_ON()s around the place to make sure it has been
initialised before use. The cpufeatures code already runs pretty
early, and will ensure sve_max_vl gets initialised.
This patch initialises sve_max_vl to something sane that will be
supported by every SVE implementation, and removes most of the
sanity checks.
The checks in find_supported_vector_length() are retained for now.
If anything goes horribly wrong, we are likely to trip a check here
sooner or later.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/fpsimd.c | 17 ++++-------------
arch/arm64/kernel/ptrace.c | 3 ---
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 87a3536..f9ec640 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -129,7 +129,7 @@ static int sve_default_vl = -1;
#ifdef CONFIG_ARM64_SVE
/* Maximum supported vector length across all CPUs (initially poisoned) */
-int __ro_after_init sve_max_vl = -1;
+int __ro_after_init sve_max_vl = SVE_VL_MIN;
/* Set of available vector lengths, as vq_to_bit(vq): */
static __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
static void __percpu *efi_sve_state;
@@ -360,22 +360,13 @@ static int sve_proc_do_default_vl(struct ctl_table *table, int write,
return ret;
/* Writing -1 has the special meaning "set to max": */
- if (vl == -1) {
- /* Fail safe if sve_max_vl wasn't initialised */
- if (WARN_ON(!sve_vl_valid(sve_max_vl)))
- vl = SVE_VL_MIN;
- else
- vl = sve_max_vl;
-
- goto chosen;
- }
+ if (vl == -1)
+ vl = sve_max_vl;
if (!sve_vl_valid(vl))
return -EINVAL;
- vl = find_supported_vector_length(vl);
-chosen:
- sve_default_vl = vl;
+ sve_default_vl = find_supported_vector_length(vl);
return 0;
}
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 7ff81fe..577deb0 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -766,9 +766,6 @@ static void sve_init_header_from_task(struct user_sve_header *header,
vq = sve_vq_from_vl(header->vl);
header->max_vl = sve_max_vl;
- if (WARN_ON(!sve_vl_valid(sve_max_vl)))
- header->max_vl = header->vl;
-
header->size = SVE_PT_SIZE(vq, header->flags);
header->max_size = SVE_PT_SIZE(sve_vq_from_vl(header->max_vl),
SVE_PT_REGS_SVE);
--
2.1.4
^ permalink raw reply related
* [PATCH v6 2/2] arm64: signal: Report signal frame size to userspace via auxv
From: Dave Martin @ 2018-06-01 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527847814-22829-1-git-send-email-Dave.Martin@arm.com>
Stateful CPU architecture extensions may require the signal frame
to grow to a size that exceeds the arch's MINSIGSTKSZ #define.
However, changing this #define is an ABI break.
To allow userspace the option of determining the signal frame size
in a more forwards-compatible way, this patch adds a new auxv entry
tagged with AT_MINSIGSTKSZ, which provides the maximum signal frame
size that the process can observe during its lifetime.
If AT_MINSIGSTKSZ is absent from the aux vector, the caller can
assume that the MINSIGSTKSZ #define is sufficient. This allows for
a consistent interface with older kernels that do not provide
AT_MINSIGSTKSZ.
The idea is that libc could expose this via sysconf() or some
similar mechanism.
There is deliberately no AT_SIGSTKSZ. The kernel knows nothing
about userspace's own stack overheads and should not pretend to
know.
For arm64:
The primary motivation for this interface is the Scalable Vector
Extension, which can require at least 4KB or so of extra space
in the signal frame for the largest hardware implementations.
To determine the correct value, a "Christmas tree" mode (via the
add_all argument) is added to setup_sigframe_layout(), to simulate
addition of all possible records to the signal frame at maximum
possible size.
If this procedure goes wrong somehow, resulting in a stupidly large
frame layout and hence failure of sigframe_alloc() to allocate a
record to the frame, then this is indicative of a kernel bug. In
this case, we WARN() and no attempt is made to populate
AT_MINSIGSTKSZ for userspace.
For arm64 SVE:
The SVE context block in the signal frame needs to be considered
too when computing the maximum possible signal frame size.
Because the size of this block depends on the vector length, this
patch computes the size based not on the thread's current vector
length but instead on the maximum possible vector length: this
determines the maximum size of SVE context block that can be
observed in any signal frame for the lifetime of the process.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Alex Benn?e <alex.bennee@linaro.org>
---
Changes since v5:
Requested by Will Deacon:
* Fill the hole left by a missing AT_MINSIGSTKSZ with AT_IGNORE
(due to concerns about how a short auxv may affect the FDPIC
loader and PR_SET_MM related stuff.
---
arch/arm64/include/asm/elf.h | 13 +++++++++
arch/arm64/include/asm/processor.h | 5 ++++
arch/arm64/include/uapi/asm/auxvec.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kernel/signal.c | 52 +++++++++++++++++++++++++++++++-----
5 files changed, 66 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index fac1c4d..433b955 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -121,6 +121,9 @@
#ifndef __ASSEMBLY__
+#include <linux/bug.h>
+#include <asm/processor.h> /* for signal_minsigstksz, used by ARCH_DLINFO */
+
typedef unsigned long elf_greg_t;
#define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
@@ -148,6 +151,16 @@ typedef struct user_fpsimd_state elf_fpregset_t;
do { \
NEW_AUX_ENT(AT_SYSINFO_EHDR, \
(elf_addr_t)current->mm->context.vdso); \
+ \
+ /* \
+ * Should always be nonzero unless there's a kernel bug. \
+ * If we haven't determined a sensible value to give to \
+ * userspace, omit the entry: \
+ */ \
+ if (likely(signal_minsigstksz)) \
+ NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \
+ else \
+ NEW_AUX_ENT(AT_IGNORE, 0); \
} while (0)
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 7675989..65ab83e 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -35,6 +35,8 @@
#ifdef __KERNEL__
#include <linux/build_bug.h>
+#include <linux/cache.h>
+#include <linux/init.h>
#include <linux/stddef.h>
#include <linux/string.h>
@@ -244,6 +246,9 @@ void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused);
void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused);
void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused);
+extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
+extern void __init minsigstksz_setup(void);
+
/* Userspace interface for PR_SVE_{SET,GET}_VL prctl()s: */
#define SVE_SET_VL(arg) sve_set_current_vl(arg)
#define SVE_GET_VL() sve_get_current_vl()
diff --git a/arch/arm64/include/uapi/asm/auxvec.h b/arch/arm64/include/uapi/asm/auxvec.h
index ec0a86d..743c0b8 100644
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -19,7 +19,8 @@
/* vDSO location */
#define AT_SYSINFO_EHDR 33
+#define AT_MINSIGSTKSZ 51 /* stack needed for signal delivery */
-#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
+#define AT_VECTOR_SIZE_ARCH 2 /* entries in ARCH_DLINFO */
#endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d..0e0b53d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1619,6 +1619,7 @@ void __init setup_cpu_features(void)
pr_info("emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching\n");
sve_setup();
+ minsigstksz_setup();
/* Advertise that we have computed the system capabilities */
set_sys_caps_initialised();
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 154b7d3..e7da5db 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/cache.h>
#include <linux/compat.h>
#include <linux/errno.h>
#include <linux/kernel.h>
@@ -570,8 +571,15 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
return 0;
}
-/* Determine the layout of optional records in the signal frame */
-static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
+/*
+ * Determine the layout of optional records in the signal frame
+ *
+ * add_all: if true, lays out the biggest possible signal frame for
+ * this task; otherwise, generates a layout for the current state
+ * of the task.
+ */
+static int setup_sigframe_layout(struct rt_sigframe_user_layout *user,
+ bool add_all)
{
int err;
@@ -581,7 +589,7 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return err;
/* fault information, if valid */
- if (current->thread.fault_code) {
+ if (add_all || current->thread.fault_code) {
err = sigframe_alloc(user, &user->esr_offset,
sizeof(struct esr_context));
if (err)
@@ -591,8 +599,14 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
if (system_supports_sve()) {
unsigned int vq = 0;
- if (test_thread_flag(TIF_SVE))
- vq = sve_vq_from_vl(current->thread.sve_vl);
+ if (add_all || test_thread_flag(TIF_SVE)) {
+ int vl = sve_max_vl;
+
+ if (!add_all)
+ vl = current->thread.sve_vl;
+
+ vq = sve_vq_from_vl(vl);
+ }
err = sigframe_alloc(user, &user->sve_offset,
SVE_SIG_CONTEXT_SIZE(vq));
@@ -603,7 +617,6 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
return sigframe_alloc_end(user);
}
-
static int setup_sigframe(struct rt_sigframe_user_layout *user,
struct pt_regs *regs, sigset_t *set)
{
@@ -701,7 +714,7 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
int err;
init_user_layout(user);
- err = setup_sigframe_layout(user);
+ err = setup_sigframe_layout(user, false);
if (err)
return err;
@@ -936,3 +949,28 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
thread_flags = READ_ONCE(current_thread_info()->flags);
} while (thread_flags & _TIF_WORK_MASK);
}
+
+unsigned long __ro_after_init signal_minsigstksz;
+
+/*
+ * Determine the stack space required for guaranteed signal devliery.
+ * This function is used to populate AT_MINSIGSTKSZ at process startup.
+ * cpufeatures setup is assumed to be complete.
+ */
+void __init minsigstksz_setup(void)
+{
+ struct rt_sigframe_user_layout user;
+
+ init_user_layout(&user);
+
+ /*
+ * If this fails, SIGFRAME_MAXSZ needs to be enlarged. It won't
+ * be big enough, but it's our best guess:
+ */
+ if (WARN_ON(setup_sigframe_layout(&user, true)))
+ return;
+
+ signal_minsigstksz = sigframe_size(&user) +
+ round_up(sizeof(struct frame_record), 16) +
+ 16; /* max alignment padding */
+}
--
2.1.4
^ permalink raw reply related
* [PATCH v3] PCI: mediatek: Add system pm support for MT2712
From: Andy Shevchenko @ 2018-06-01 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527822270-30280-1-git-send-email-honghui.zhang@mediatek.com>
On Fri, Jun 1, 2018 at 6:04 AM, <honghui.zhang@mediatek.com> wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
> +#ifdef CONFIG_PM_SLEEP
> +static int mtk_pcie_suspend_noirq(struct device *dev)
__maybe_unused
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client
From: Peter Ujfalusi @ 2018-06-01 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DM6PR02MB43612FF66323449C7D2B4FDCC76C0@DM6PR02MB4361.namprd02.prod.outlook.com>
Hi Radhey,
On 2018-05-30 20:29, Radhey Shyam Pandey wrote:
>> In couple of days I can update the metadata patches I have atm and send
>> as RFC.
>>
>> Is there anything from your side I should take into account when doing that?
> I think a generic interface to attach/share metadata buffer b/w client and the
> dmaengine driver is good enough. Is metadata patchset (early version)
> available in TI external repos?
I don't have it in public repository, but now that the TRM is public I
can start preparing things for upstream.
I have attached the patch I ended up with, but I need to add the
documentation part.
Since the 'metadata' is part of the DMA descriptor itself I thought that
it might be better to reflect that -> the metadata_ops is part of the
dma_async_tx_descriptor struct.
DMA drivers can initialize it when it is supported by the channel or
setup. In my case it is optional, many peripherals did not use it at all.
I have two modes to deal with the metadata:
1. attach mode
Client drivers are giving a buffer and a size to the DMA driver and in
case of TX the data is copied to the descriptor's metadata part. In case
of RX when the transfer is completed the DMA driver will copy the data
from the DMA descriptor to the client provided buffer.
Here we need one memcpy for each descriptor.
2. pointer mode
If we have high throughput peripheral, the per descriptor memcpy can be
an obstacle for performance.
TX: The client dmaengine_desc_get_metadata_ptr() to get the pointer to
the metadata section of the descriptor, it will receive back the max
size and the currently used size (important for RX). This is done before
issue_pending().
The client can update the metadata directly and when it is done calls
the dmaengine_desc_set_metadata_len() to tell the DMA driver the size of
the metadata it has configured.
RX: in the DMA callback the client calls
dmaengine_desc_get_metadata_ptr() to get the pointer and the size of the
metadata we have received and can process the information w/o memcpy.
I think it might be better to rename these from metadata to client_data
or something. It is part of the DMA descriptor, passed along with the
DMA descriptor, but it is owned by the client driver.
- P?ter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dmaengine-Add-metadat_ops-for-dma_async_tx_descripto.patch
Type: text/x-patch
Size: 3092 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180601/d3c18cb2/attachment-0001.bin>
^ permalink raw reply
* [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor
From: Peter Ujfalusi @ 2018-06-01 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <32208a9c-2b15-d345-1432-f1e387531f9b@ti.com>
If the DMA supports per descriptor metadata it can implement the attach,
get_ptr/set_len callbacks.
Client drivers must only use either attach or get_ptr/set_len to avoid
miss configuration.
Wrappers are also added for the metadata_ops:
dmaengine_desc_attach_metadata()
dmaengine_desc_get_metadata_ptr()
dmaengine_desc_set_metadata_len()
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
Hi,
since attachments are bouncing back, I send the patch separately
Regards,
Peter
include/linux/dmaengine.h | 50 +++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 51fbb861e84b..ac42ace36aa3 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -491,6 +491,18 @@ struct dmaengine_unmap_data {
dma_addr_t addr[0];
};
+struct dma_async_tx_descriptor;
+
+struct dma_descriptor_metadata_ops {
+ int (*attach)(struct dma_async_tx_descriptor *desc, void *data,
+ size_t len);
+
+ void *(*get_ptr)(struct dma_async_tx_descriptor *desc,
+ size_t *payload_len, size_t *max_len);
+ int (*set_len)(struct dma_async_tx_descriptor *desc,
+ size_t payload_len);
+};
+
/**
* struct dma_async_tx_descriptor - async transaction descriptor
* ---dma generic offload fields---
@@ -520,6 +532,7 @@ struct dma_async_tx_descriptor {
dma_async_tx_callback_result callback_result;
void *callback_param;
struct dmaengine_unmap_data *unmap;
+ struct dma_descriptor_metadata_ops *metadata_ops;
#ifdef CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH
struct dma_async_tx_descriptor *next;
struct dma_async_tx_descriptor *parent;
@@ -932,6 +945,43 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_memcpy(
len, flags);
}
+static inline int dmaengine_desc_attach_metadata(
+ struct dma_async_tx_descriptor *desc, void *data, size_t len)
+{
+ if (!desc)
+ return 0;
+
+ if (!desc->metadata_ops || !desc->metadata_ops->attach)
+ return -ENOTSUPP;
+
+ return desc->metadata_ops->attach(desc, data, len);
+}
+
+static inline void *dmaengine_desc_get_metadata_ptr(
+ struct dma_async_tx_descriptor *desc, size_t *payload_len,
+ size_t *max_len)
+{
+ if (!desc)
+ return NULL;
+
+ if (!desc->metadata_ops || !desc->metadata_ops->get_ptr)
+ return ERR_PTR(-ENOTSUPP);
+
+ return desc->metadata_ops->get_ptr(desc, payload_len, max_len);
+}
+
+static inline int dmaengine_desc_set_metadata_len(
+ struct dma_async_tx_descriptor *desc, size_t payload_len)
+{
+ if (!desc)
+ return 0;
+
+ if (!desc->metadata_ops || !desc->metadata_ops->set_len)
+ return -ENOTSUPP;
+
+ return desc->metadata_ops->set_len(desc, payload_len);
+}
+
/**
* dmaengine_terminate_all() - Terminate all active DMA transfers
* @chan: The channel for which to terminate the transfers
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* [PATCH v3 2/8] dt-bindings: media: Document data-enable-active property
From: Sakari Ailus @ 2018-06-01 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527606359-19261-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for the patch.
On Tue, May 29, 2018 at 05:05:53PM +0200, Jacopo Mondi wrote:
> Add 'data-enable-active' property to endpoint node properties list.
>
> The property allows to specify the polarity of the data-enable signal, which
> when in active state determinates when data lanes have to sampled for valid
> pixel data.
Lanes or lines? I understand this is forthe parallel interface.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> v3:
> - new patch
> ---
> Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index 258b8df..9839d26 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -109,6 +109,8 @@ Optional endpoint properties
> Note, that if HSYNC and VSYNC polarities are not specified, embedded
> synchronization may be required, where supported.
> - data-active: similar to HSYNC and VSYNC, specifies data line polarity.
> +- data-enable-active: similar to HSYNC and VSYNC, specifies the data enable
> + signal polarity.
> - field-even-active: field signal level during the even field data transmission.
> - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
> signal.
--
Sakari Ailus
sakari.ailus at linux.intel.com
^ permalink raw reply
* [PATCH 06/18] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Mark Rutland @ 2018-06-01 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516090121.GQ7753@e103592.cambridge.arm.com>
On Wed, May 16, 2018 at 10:01:32AM +0100, Dave Martin wrote:
> On Tue, May 15, 2018 at 05:33:52PM +0100, Mark Rutland wrote:
> > On Tue, May 15, 2018 at 01:19:26PM +0100, Dave Martin wrote:
> > > On Tue, May 15, 2018 at 11:39:36AM +0100, Mark Rutland wrote:
> > > > Earlier I'd put BUILD_BUG() in the body for the !CONFIG_ARM64_SVE case,
> > > > to catch that kind of thing -- I could restore that.
> > >
> > > IIUC:
> > >
> > > if (0) {
> > > BUILD_BUG_ON(1);
> > > }
> > >
> > > can still fire, in which case it's futile checking for CONFIG_ARM64_SVE
> > > in most of the SVE support code.
> >
> > We already rely on BUILD_BUG() not firing in paths that can be trivially
> > optimized away. e.g. in the cmpxchg code.
>
> Fair enough. I had been unsure on this point.
>
> If you want to put a BUILD_BUG_ON(!IS_ENABLED(CONFIG_ARM64_SVE)) in
> sve_user_enable() and build with CONFIG_ARM64_SVE=n to check it works,
> then I'd be fine with that.
>
> This doesn't capture the runtime part of the condition, but it's better
> than nothing.
For the moment, I've kept the stubs, but placed a BUILD_BUG() in each,
as per the above rationale.
We generally do that rather than than BUILD_BUG_ON(!IS_ENABLED(...)) in
a common definition, and it's more in keeping with the other stubs in
<asm/fpsimd.h>.
> > > > > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > > > > > index 088940387a4d..79a81c7d85c6 100644
> > > > > > --- a/arch/arm64/kernel/fpsimd.c
> > > > > > +++ b/arch/arm64/kernel/fpsimd.c
> > > > > > @@ -159,7 +159,6 @@ static void sve_free(struct task_struct *task)
> > > > > > __sve_free(task);
> > > > > > }
> > > > > >
> > > > > > -
> > > > >
> > > > > Hmmm, Ack. Check for conflicts with the KVM FPSIMD rework [1] (though
> > > > > trivial).
> > > >
> > > > I'll assume that Ack stands regardless. :)
> > >
> > > Actually, I was just commenting on the deleted blank line...
> >
> > Ah. I've restored that now.
>
> I meant Ack to the deletion. It looks like the blank line was
> spuriously introduced in the first place. But it doesn't hugely matter
> either way.
Ok. I've dropped that for now to minimize the potential for conflicts,
but we can clean this up later.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 06/18] arm64: move sve_user_{enable, disable} to <asm/fpsimd.h>
From: Dave Martin @ 2018-06-01 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180601102913.ougz2vshzzttvuaj@lakrids.cambridge.arm.com>
On Fri, Jun 01, 2018 at 11:29:13AM +0100, Mark Rutland wrote:
> On Wed, May 16, 2018 at 10:01:32AM +0100, Dave Martin wrote:
> > On Tue, May 15, 2018 at 05:33:52PM +0100, Mark Rutland wrote:
> > > On Tue, May 15, 2018 at 01:19:26PM +0100, Dave Martin wrote:
> > > > On Tue, May 15, 2018 at 11:39:36AM +0100, Mark Rutland wrote:
> > > > > Earlier I'd put BUILD_BUG() in the body for the !CONFIG_ARM64_SVE case,
> > > > > to catch that kind of thing -- I could restore that.
> > > >
> > > > IIUC:
> > > >
> > > > if (0) {
> > > > BUILD_BUG_ON(1);
> > > > }
> > > >
> > > > can still fire, in which case it's futile checking for CONFIG_ARM64_SVE
> > > > in most of the SVE support code.
> > >
> > > We already rely on BUILD_BUG() not firing in paths that can be trivially
> > > optimized away. e.g. in the cmpxchg code.
> >
> > Fair enough. I had been unsure on this point.
> >
> > If you want to put a BUILD_BUG_ON(!IS_ENABLED(CONFIG_ARM64_SVE)) in
> > sve_user_enable() and build with CONFIG_ARM64_SVE=n to check it works,
> > then I'd be fine with that.
> >
> > This doesn't capture the runtime part of the condition, but it's better
> > than nothing.
>
> For the moment, I've kept the stubs, but placed a BUILD_BUG() in each,
> as per the above rationale.
>
> We generally do that rather than than BUILD_BUG_ON(!IS_ENABLED(...)) in
> a common definition, and it's more in keeping with the other stubs in
> <asm/fpsimd.h>.
OK, fine by me.
> > > > > > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > > > > > > index 088940387a4d..79a81c7d85c6 100644
> > > > > > > --- a/arch/arm64/kernel/fpsimd.c
> > > > > > > +++ b/arch/arm64/kernel/fpsimd.c
> > > > > > > @@ -159,7 +159,6 @@ static void sve_free(struct task_struct *task)
> > > > > > > __sve_free(task);
> > > > > > > }
> > > > > > >
> > > > > > > -
> > > > > >
> > > > > > Hmmm, Ack. Check for conflicts with the KVM FPSIMD rework [1] (though
> > > > > > trivial).
> > > > >
> > > > > I'll assume that Ack stands regardless. :)
> > > >
> > > > Actually, I was just commenting on the deleted blank line...
> > >
> > > Ah. I've restored that now.
> >
> > I meant Ack to the deletion. It looks like the blank line was
> > spuriously introduced in the first place. But it doesn't hugely matter
> > either way.
>
> Ok. I've dropped that for now to minimize the potential for conflicts,
> but we can clean this up later.
No big deal either way.
Cheers
---Dave
^ permalink raw reply
* [PATCH v2 21/40] iommu/arm-smmu-v3: Add support for Substream IDs
From: Jean-Philippe Brucker @ 2018-06-01 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BLUPR0201MB1505AA55707BE2E13392FFAFA5630@BLUPR0201MB1505.namprd02.prod.outlook.com>
On 31/05/18 12:01, Bharat Kumar Gogada wrote:
>> static void arm_smmu_sync_cd(void *cookie, int ssid, bool leaf) {
>> + struct arm_smmu_cmdq_ent cmd = {
>> + .opcode = CMDQ_OP_CFGI_CD_ALL,
>
> Hi Jean, here CMDQ_OP_CFGI_CD opcode 0x5.
Woops, nice catch!
I pushed fixes for all comments so far to branch sva/current
Thanks,
Jean
^ permalink raw reply
* [PATCH v3] PCI: mediatek: Add system pm support for MT2712
From: Honghui Zhang @ 2018-06-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VeBTmC=3nJ-t+OO9bp0mzJuTYsGBwi8fokT16bu2nE9RA@mail.gmail.com>
On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
> On Fri, Jun 1, 2018 at 6:04 AM, <honghui.zhang@mediatek.com> wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_pcie_suspend_noirq(struct device *dev)
>
> __maybe_unused
>
Hi, Andy, thanks for your review.
Bjorn had point this out that at:
https://www.spinics.net/lists/arm-kernel/msg656774.html
So __maybe_unused is not really needed.
thanks
^ permalink raw reply
* [PATCH v3] PCI: mediatek: Add system pm support for MT2712
From: Andy Shevchenko @ 2018-06-01 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527850145.28160.6.camel@mhfsdcap03>
On Fri, Jun 1, 2018 at 1:49 PM, Honghui Zhang
<honghui.zhang@mediatek.com> wrote:
> On Fri, 2018-06-01 at 13:17 +0300, Andy Shevchenko wrote:
>> On Fri, Jun 1, 2018 at 6:04 AM, <honghui.zhang@mediatek.com> wrote:
>> > From: Honghui Zhang <honghui.zhang@mediatek.com>
>>
>> > +#ifdef CONFIG_PM_SLEEP
>> > +static int mtk_pcie_suspend_noirq(struct device *dev)
>>
>> __maybe_unused
>>
>
> Hi, Andy, thanks for your review.
> Bjorn had point this out that at:
> https://www.spinics.net/lists/arm-kernel/msg656774.html
Nice, one more maintainer with strong opinion here.
Arnd, that's what I mentioned as a split in opinions earlier.
Any new developer or even existing contributor would be now really
confusing since maintainers asked for two different approaches on the
same matter.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] ARM: avoid Cortex-A9 livelock on tight dmb loops
From: Russell King @ 2018-06-01 11:00 UTC (permalink / raw)
To: linux-arm-kernel
Executing loops such as:
while (1)
cpu_relax();
with interrupts disabled results in a livelock of the entire system,
as other CPUs are prevented making progress. This is most noticable
as a failure of crashdump kexec, which stops just after issuing:
Loading crashdump kernel...
to the system console. Two other locations of these loops within the
ARM code have been identified and fixed up.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
v2: use wfe() instead of cpu_do_idle
arch/arm/include/asm/barrier.h | 2 ++
arch/arm/kernel/machine_kexec.c | 5 ++++-
arch/arm/kernel/smp.c | 4 +++-
arch/arm/mach-omap2/prm_common.c | 4 +++-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 69772e742a0a..83ae97c049d9 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -11,6 +11,8 @@
#define sev() __asm__ __volatile__ ("sev" : : : "memory")
#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
#define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
+#else
+#define wfe() do { } while (0)
#endif
#if __LINUX_ARM_ARCH__ >= 7
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index dd2eb5f76b9f..76300f3813e8 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -91,8 +91,11 @@ void machine_crash_nonpanic_core(void *unused)
set_cpu_online(smp_processor_id(), false);
atomic_dec(&waiting_for_crash_ipi);
- while (1)
+
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
void crash_smp_send_stop(void)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 9ec9a366ef44..a39fe6ab89a2 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -570,8 +570,10 @@ static void ipi_cpu_stop(unsigned int cpu)
local_fiq_disable();
local_irq_disable();
- while (1)
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
static DEFINE_PER_CPU(struct completion *, cpu_completion);
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 021b5a8b9c0a..bb15a9eec05c 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -522,8 +522,10 @@ void omap_prm_reset_system(void)
prm_ll_data->reset_system();
- while (1)
+ while (1) {
cpu_relax();
+ wfe();
+ }
}
/**
--
2.7.4
^ 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