* [PATCH v5 4/6] MAINTAINERS: add at91 usart spi driver
From: Radu Pirea @ 2018-06-04 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604165943.31381-1-radu.pirea@microchip.com>
Added entry for at91 usart mfd driver.
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 12203d07c6af..dae31df711fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9201,6 +9201,13 @@ F: drivers/mfd/at91-usart.c
F: include/dt-bindings/mfd/at91-usart.h
F: Documentation/devicetree/bindings/mfd/atmel-usart.txt
+MICROCHIP AT91 USART SPI DRIVER
+M: Radu Pirea <radu.pirea@microchip.com>
+L: linux-spi at vger.kernel.org
+S: Supported
+F: drivers/spi/spi-at91-usart.c
+F: Documentation/devicetree/bindings/mfd/atmel-usart.txt
+
MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
M: Woojung Huh <Woojung.Huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
--
2.17.1
^ permalink raw reply related
* [PATCH v5 3/6] mfd: at91-usart: added mfd driver for usart
From: Radu Pirea @ 2018-06-04 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604165943.31381-1-radu.pirea@microchip.com>
This mfd driver is just a wrapper over atmel_serial driver and
spi-at91-usart driver. Selection of one of the drivers is based on a
property from device tree. If the property is not specified, the default
driver is atmel_serial.
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
Acked-by: Rob Herring <robh@kernel.org>
---
drivers/mfd/Kconfig | 9 ++++++
drivers/mfd/Makefile | 1 +
drivers/mfd/at91-usart.c | 67 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 77 insertions(+)
create mode 100644 drivers/mfd/at91-usart.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..a886672b960d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -99,6 +99,15 @@ config MFD_AAT2870_CORE
additional drivers must be enabled in order to use the
functionality of the device.
+config MFD_AT91_USART
+ tristate "AT91 USART Driver"
+ select MFD_CORE
+ help
+ Select this to get support for AT91 USART IP. This is a wrapper
+ over at91-usart-serial driver and usart-spi-driver. Only one function
+ can be used at a time. The choice is done at boot time by the probe
+ function of this MFD driver according to a device tree property.
+
config MFD_ATMEL_FLEXCOM
tristate "Atmel Flexcom (Flexible Serial Communication Unit)"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d9d2cf0d32ef..db1332aa96db 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -185,6 +185,7 @@ obj-$(CONFIG_MFD_SPMI_PMIC) += qcom-spmi-pmic.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_TPS65090) += tps65090.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_AT91_USART) += at91-usart.o
obj-$(CONFIG_MFD_ATMEL_FLEXCOM) += atmel-flexcom.o
obj-$(CONFIG_MFD_ATMEL_HLCDC) += atmel-hlcdc.o
obj-$(CONFIG_MFD_ATMEL_SMC) += atmel-smc.o
diff --git a/drivers/mfd/at91-usart.c b/drivers/mfd/at91-usart.c
new file mode 100644
index 000000000000..262e7affba22
--- /dev/null
+++ b/drivers/mfd/at91-usart.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Driver for AT91 USART
+ *
+ * Copyright (C) 2018 Microchip Technology
+ *
+ * Author: Radu Pirea <radu.pirea@microchip.com>
+ *
+ */
+
+#include <dt-bindings/mfd/at91-usart.h>
+
+#include <linux/module.h>
+#include <linux/mfd/core.h>
+#include <linux/property.h>
+
+static struct mfd_cell at91_usart_spi_subdev = {
+ .name = "at91_usart_spi",
+ .of_compatible = "microchip,at91sam9g45-usart-spi",
+ };
+
+static struct mfd_cell at91_usart_serial_subdev = {
+ .name = "atmel_usart_serial",
+ .of_compatible = "atmel,at91rm9200-usart-serial",
+ };
+
+static int at91_usart_mode_probe(struct platform_device *pdev)
+{
+ struct mfd_cell cell;
+ u32 opmode;
+ int err;
+
+ err = device_property_read_u32(&pdev->dev, "atmel,usart-mode", &opmode);
+
+ switch (opmode) {
+ case AT91_USART_MODE_SPI:
+ cell = at91_usart_spi_subdev;
+ break;
+ case AT91_USART_MODE_SERIAL:
+ default:
+ cell = at91_usart_serial_subdev;
+ }
+
+ return devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO, &cell, 1,
+ NULL, 0, NULL);
+}
+
+static const struct of_device_id at91_usart_mode_of_match[] = {
+ { .compatible = "atmel,at91rm9200-usart" },
+ { .compatible = "atmel,at91sam9260-usart" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, at91_flexcom_of_match);
+
+static struct platform_driver at91_usart_mfd = {
+ .probe = at91_usart_mode_probe,
+ .driver = {
+ .name = "at91_usart_mode",
+ .of_match_table = at91_usart_mode_of_match,
+ },
+};
+
+module_platform_driver(at91_usart_mfd);
+
+MODULE_AUTHOR("Radu Pirea <radu.pirea@microchip.com>");
+MODULE_DESCRIPTION("AT91 USART MFD driver");
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v5 2/6] dt-bindings: add binding for atmel-usart in SPI mode
From: Radu Pirea @ 2018-06-04 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604165943.31381-1-radu.pirea@microchip.com>
This patch moves the bindings for serial from serial/atmel-usart.txt to
mfd/atmel-usart.txt and adds bindings for USART in SPI mode.
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/{serial => mfd}/atmel-usart.txt | 25 +++++++++++++++++--
include/dt-bindings/mfd/at91-usart.h | 17 +++++++++++++
2 files changed, 40 insertions(+), 2 deletions(-)
rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt (76%)
create mode 100644 include/dt-bindings/mfd/at91-usart.h
diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/mfd/atmel-usart.txt
similarity index 76%
rename from Documentation/devicetree/bindings/serial/atmel-usart.txt
rename to Documentation/devicetree/bindings/mfd/atmel-usart.txt
index 7c0d6b2f53e4..3b9e18642c3b 100644
--- a/Documentation/devicetree/bindings/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/mfd/atmel-usart.txt
@@ -1,6 +1,6 @@
* Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
-Required properties:
+Required properties for USART:
- compatible: Should be "atmel,<chip>-usart" or "atmel,<chip>-dbgu"
The compatible <chip> indicated will be the first SoC to support an
additional mode or an USART new feature.
@@ -11,7 +11,13 @@ Required properties:
Required elements: "usart"
- clocks: phandles to input clocks.
-Optional properties:
+Required properties for USART in SPI mode:
+- #size-cells : Must be <0>
+- #address-cells : Must be <1>
+- cs-gpios: chipselects (internal cs not supported)
+- atmel,usart-mode : Must be <USART_MODE_SPI> (found in dt-bindings/mfd/at91-usart.h)
+
+Optional properties in serial mode:
- atmel,use-dma-rx: use of PDC or DMA for receiving data
- atmel,use-dma-tx: use of PDC or DMA for transmitting data
- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD line respectively.
@@ -62,3 +68,18 @@ Example:
dma-names = "tx", "rx";
atmel,fifo-size = <32>;
};
+
+- SPI mode:
+ #include <dt-bindings/mfd/at91-usart.h>
+
+ spi0: spi at f001c000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "atmel,at91rm9200-usart", "atmel,at91sam9260-usart";
+ atmel,usart-mode = <USART_MODE_SPI>;
+ reg = <0xf001c000 0x100>;
+ interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&usart0_clk>;
+ clock-names = "usart";
+ cs-gpios = <&pioB 3 0>;
+ };
diff --git a/include/dt-bindings/mfd/at91-usart.h b/include/dt-bindings/mfd/at91-usart.h
new file mode 100644
index 000000000000..ac811628a42d
--- /dev/null
+++ b/include/dt-bindings/mfd/at91-usart.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides macros for AT91 USART DT bindings.
+ *
+ * Copyright (C) 2018 Microchip Technology
+ *
+ * Author: Radu Pirea <radu.pirea@microchip.com>
+ *
+ */
+
+#ifndef __DT_BINDINGS_AT91_USART_H__
+#define __DT_BINDINGS_AT91_USART_H__
+
+#define AT91_USART_MODE_SERIAL 1
+#define AT91_USART_MODE_SPI 2
+
+#endif /* __DT_BINDINGS_AT91_USART_H__ */
--
2.17.1
^ permalink raw reply related
* [PATCH v5 1/6] MAINTAINERS: add at91 usart mfd driver
From: Radu Pirea @ 2018-06-04 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604165943.31381-1-radu.pirea@microchip.com>
Added entry for at91 usart mfd driver.
Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
---
MAINTAINERS | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e2a2fddbd19..12203d07c6af 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9160,6 +9160,7 @@ M: Richard Genoud <richard.genoud@gmail.com>
S: Maintained
F: drivers/tty/serial/atmel_serial.c
F: drivers/tty/serial/atmel_serial.h
+F: Documentation/devicetree/bindings/mfd/atmel-usart.txt
MICROCHIP / ATMEL DMA DRIVER
M: Ludovic Desroches <ludovic.desroches@microchip.com>
@@ -9192,6 +9193,14 @@ S: Supported
F: drivers/mtd/nand/raw/atmel/*
F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
+MICROCHIP AT91 USART MFD DRIVER
+M: Radu Pirea <radu.pirea@microchip.com>
+L: linux-kernel at vger.kernel.org
+S: Supported
+F: drivers/mfd/at91-usart.c
+F: include/dt-bindings/mfd/at91-usart.h
+F: Documentation/devicetree/bindings/mfd/atmel-usart.txt
+
MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
M: Woojung Huh <Woojung.Huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
--
2.17.1
^ permalink raw reply related
* [PATCH v5 0/6] Driver for at91 usart in spi mode
From: Radu Pirea @ 2018-06-04 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This is the second version of driver. I added a mfd driver which by
default probes atmel_serial driver and if in dt is specified to probe
the spi driver, then the spi-at91-usart driver will be probed. The
compatible for atmel_serial is now the compatible for at91-usart mfd
driver and compatilbe for atmel_serial driver was changed in order to
keep the bindings for serial as they are.
Changes in v1:
- added spi-at91-usart driver
Changes in v2:
- added at91-usart mfd driver
- modified spi-at91-usart driver to work as mfd driver child
- modified atmel_serial driver to work as mfd driver child
Changes in v3:
- fixed spi slaves probing
Changes in v4:
- modified the spi driver to use cs gpio support form spi subsystem
- fixed dma transfers for serial driver
- squashed binding for spi and serial and moved them to mfd/atmel-usart.txt
Changes in v5:
- fixed usage of stdout-path property with atmel_serial driver
Radu Pirea (6):
MAINTAINERS: add at91 usart mfd driver
dt-bindings: add binding for atmel-usart in SPI mode
mfd: at91-usart: added mfd driver for usart
MAINTAINERS: add at91 usart spi driver
spi: at91-usart: add driver for at91-usart as spi
tty/serial: atmel: changed the driver to work under at91-usart mfd
.../bindings/{serial => mfd}/atmel-usart.txt | 25 +-
MAINTAINERS | 16 +
drivers/mfd/Kconfig | 9 +
drivers/mfd/Makefile | 1 +
drivers/mfd/at91-usart.c | 67 +++
drivers/spi/Kconfig | 9 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-at91-usart.c | 436 ++++++++++++++++++
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/atmel_serial.c | 41 +-
include/dt-bindings/mfd/at91-usart.h | 17 +
11 files changed, 604 insertions(+), 19 deletions(-)
rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt (76%)
create mode 100644 drivers/mfd/at91-usart.c
create mode 100644 drivers/spi/spi-at91-usart.c
create mode 100644 include/dt-bindings/mfd/at91-usart.h
--
2.17.1
^ permalink raw reply
* [PATCH V2] ARM: shmobile: Rework the PMIC IRQ line quirk
From: Marek Vasut @ 2018-06-04 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604093428.x3br3wb7m7r3jaoj@verge.net.au>
On 06/04/2018 11:34 AM, Simon Horman wrote:
> On Fri, May 25, 2018 at 10:05:08PM +0200, Marek Vasut wrote:
>> Rather than hard-coding the quirk topology, which stopped scaling,
>> parse the information from DT. The code looks for all compatible
>> PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied
>> to the same pin. If so, the code sends a matching sequence to the
>> PMIC to deassert the IRQ.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> Cc: Simon Horman <horms+renesas@verge.net.au>
>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
>> Cc: linux-renesas-soc at vger.kernel.org
>> ---
>> V2: - Replace the DT shared IRQ check loop with memcmp()
>> - Send the I2C message to deassert the IRQ line to all PMICs
>> in the list with shared IRQ line instead of just one
>> - Add comment that this works only in case all the PMICs are
>> on the same I2C bus
>> ---
>> arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 117 ++++++++++++++++-----
>> 1 file changed, 93 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> index 93f628acfd94..4db8d9ea5f97 100644
>> --- a/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> +++ b/arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c
>> @@ -31,8 +31,10 @@
>> #include <linux/i2c.h>
>> #include <linux/init.h>
>> #include <linux/io.h>
>> +#include <linux/list.h>
>> #include <linux/notifier.h>
>> #include <linux/of.h>
>> +#include <linux/of_irq.h>
>> #include <linux/mfd/da9063/registers.h>
>>
>>
>> @@ -44,34 +46,47 @@
>> /* start of DA9210 System Control and Event Registers */
>> #define DA9210_REG_MASK_A 0x54
>>
>> +struct regulator_quirk {
>> + struct list_head list;
>> + const struct of_device_id *id;
>> + struct of_phandle_args irq_args;
>> + struct i2c_msg i2c_msg;
>> + bool shared; /* IRQ line is shared */
>> +};
>> +
>> +static LIST_HEAD(quirk_list);
>> static void __iomem *irqc;
>>
>> /* first byte sets the memory pointer, following are consecutive reg values */
>> static u8 da9063_irq_clr[] = { DA9063_REG_IRQ_MASK_A, 0xff, 0xff, 0xff, 0xff };
>> static u8 da9210_irq_clr[] = { DA9210_REG_MASK_A, 0xff, 0xff };
>>
>> -static struct i2c_msg da9xxx_msgs[3] = {
>> - {
>> - .addr = 0x58,
>> - .len = ARRAY_SIZE(da9063_irq_clr),
>> - .buf = da9063_irq_clr,
>> - }, {
>> - .addr = 0x68,
>> - .len = ARRAY_SIZE(da9210_irq_clr),
>> - .buf = da9210_irq_clr,
>> - }, {
>> - .addr = 0x70,
>> - .len = ARRAY_SIZE(da9210_irq_clr),
>> - .buf = da9210_irq_clr,
>> - },
>> +static struct i2c_msg da9063_msgs = {
>> + .addr = 0x00,
>
> I don't think you need to explicitly initialise the .addr fields to 0.
>
>> + .len = ARRAY_SIZE(da9063_irq_clr),
>> + .buf = da9063_irq_clr,
>> +};
>> +
>> +static struct i2c_msg da9210_msgs = {
>> + .addr = 0x00,
>> + .len = ARRAY_SIZE(da9210_irq_clr),
>> + .buf = da9210_irq_clr,
>> +};
>> +
>> +static const struct of_device_id rcar_gen2_quirk_match[] = {
>> + { .compatible = "dlg,da9063", .data = &da9063_msgs },
>> + { .compatible = "dlg,da9210", .data = &da9210_msgs },
>> + {},
>> };
>>
>> static int regulator_quirk_notify(struct notifier_block *nb,
>> unsigned long action, void *data)
>> {
>> + struct regulator_quirk *pos, *tmp;
>> struct device *dev = data;
>> struct i2c_client *client;
>> static bool done;
>> + int ret;
>> u32 mon;
>>
>> if (done)
>> @@ -88,17 +103,20 @@ static int regulator_quirk_notify(struct notifier_block *nb,
>> client = to_i2c_client(dev);
>> dev_dbg(dev, "Detected %s\n", client->name);
>>
>> - if ((client->addr == 0x58 && !strcmp(client->name, "da9063")) ||
>> - (client->addr == 0x68 && !strcmp(client->name, "da9210")) ||
>> - (client->addr == 0x70 && !strcmp(client->name, "da9210"))) {
>> - int ret, len;
>> + /*
>> + * Send message to all PMICs that share an IRQ line to deassert it.
>> + *
>> + * WARNING: This works only if all the PMICs are on the same I2C bus.
>> + */
>> + list_for_each_entry(pos, &quirk_list, list) {
>> + if (!pos->shared)
>> + continue;
>>
>> - /* There are two DA9210 on Stout, one on the other boards. */
>> - len = of_machine_is_compatible("renesas,stout") ? 3 : 2;
>> + dev_info(&client->dev, "clearing %s at 0x%02x interrupts\n",
>> + pos->id->compatible, pos->i2c_msg.addr);
>>
>> - dev_info(&client->dev, "clearing da9063/da9210 interrupts\n");
>> - ret = i2c_transfer(client->adapter, da9xxx_msgs, len);
>> - if (ret != len)
>> + ret = i2c_transfer(client->adapter, &pos->i2c_msg, 1);
>> + if (ret != 1)
>> dev_err(&client->dev, "i2c error %d\n", ret);
>> }
>>
>> @@ -111,6 +129,11 @@ static int regulator_quirk_notify(struct notifier_block *nb,
>> remove:
>> dev_info(dev, "IRQ2 is not asserted, removing quirk\n");
>>
>> + list_for_each_entry_safe(pos, tmp, &quirk_list, list) {
>> + list_del(&pos->list);
>> + kfree(pos);
>> + }
>> +
>> done = true;
>> iounmap(irqc);
>> return 0;
>> @@ -122,7 +145,13 @@ static struct notifier_block regulator_quirk_nb = {
>>
>> static int __init rcar_gen2_regulator_quirk(void)
>> {
>> - u32 mon;
>> + struct device_node *np;
>> + const struct of_device_id *id;
>> + struct regulator_quirk *quirk;
>> + struct regulator_quirk *pos;
>> + struct of_phandle_args *argsa, *argsb;
>> + u32 mon, addr;
>> + int ret;
>>
>> if (!of_machine_is_compatible("renesas,koelsch") &&
>> !of_machine_is_compatible("renesas,lager") &&
>> @@ -130,6 +159,46 @@ static int __init rcar_gen2_regulator_quirk(void)
>> !of_machine_is_compatible("renesas,gose"))
>> return -ENODEV;
>>
>> + for_each_matching_node_and_match(np, rcar_gen2_quirk_match, &id) {
>> + if (!np || !of_device_is_available(np))
>> + break;
>> +
>> + quirk = kzalloc(sizeof(*quirk), GFP_KERNEL);
>> +
>> + argsa = &quirk->irq_args;
>> + memcpy(&quirk->i2c_msg, id->data, sizeof(quirk->i2c_msg));
>> +
>> + ret = of_property_read_u32(np, "reg", &addr);
>> + if (ret)
>> + return ret;
>> +
>> + quirk->id = id;
>> + quirk->i2c_msg.addr = addr;
>> + quirk->shared = false;
>> +
>> + ret = of_irq_parse_one(np, 0, &quirk->irq_args);
>
> &quirk->irq_args is assigned to argsa above and used directly here.
>
>> + if (ret)
>> + return ret;
>> +
>> + list_for_each_entry(pos, &quirk_list, list) {
>> + argsa = &quirk->irq_args;
>
> argsa is initialised both here and further above.
Fixed
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] arm: cntvoff: Add a function definition when !SMP
From: Maxime Ripard @ 2018-06-04 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180528084016.9271-1-maxime.ripard@bootlin.com>
On Mon, May 28, 2018 at 10:40:16AM +0200, Maxime Ripard wrote:
> The secure_cntvoff_init function is only compiled if CONFIG_SMP is set to
> true. However, that will lead to linking errors if one uses this function
> without an ifdef CONFIG_SMP guard, which isn't ideal.
>
> Provide a dumb implementation when CONFIG_SMP is false so that we don't end
> up with a compilation error on our hands.
>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Myl?ne Josserand <mylene.josserand@bootlin.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Fixes: cad160ed0a94 ("ARM: shmobile: Convert file to use cntvoff")
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Ping?
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/20180604/43cdc1b2/attachment.sig>
^ permalink raw reply
* [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Maxime Ripard @ 2018-06-04 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8937075.mEvrCV6laa@jernej-laptop>
On Mon, Jun 04, 2018 at 05:09:56PM +0200, Jernej ?krabec wrote:
> Dne ponedeljek, 04. junij 2018 ob 13:50:34 CEST je Maxime Ripard napisal(a):
> > On Fri, Jun 01, 2018 at 09:19:43AM -0700, Chen-Yu Tsai wrote:
> > > On Fri, Jun 1, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com>
> wrote:
> > > > On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej ?krabec wrote:
> > > >> Dne ?etrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
> > > >> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > > >> > > >> > > + if (tcon->quirks->needs_tcon_top) {
> > > >> > > >> > > + struct device_node *np;
> > > >> > > >> > > +
> > > >> > > >> > > + np = of_parse_phandle(dev->of_node,
> > > >> > > >> > > "allwinner,tcon-top",
> > > >> > > >> > > 0);
> > > >> > > >> > > + if (np) {
> > > >> > > >> > > + struct platform_device *pdev;
> > > >> > > >> > > +
> > > >> > > >> > > + pdev = of_find_device_by_node(np);
> > > >> > > >> > > + if (pdev)
> > > >> > > >> > > + tcon->tcon_top =
> > > >> > > >> > > platform_get_drvdata(pdev);
> > > >> > > >> > > + of_node_put(np);
> > > >> > > >> > > +
> > > >> > > >> > > + if (!tcon->tcon_top)
> > > >> > > >> > > + return -EPROBE_DEFER;
> > > >> > > >> > > + }
> > > >> > > >> > > + }
> > > >> > > >> > > +
> > > >> > > >> >
> > > >> > > >> > I might have missed it, but I've not seen the bindings
> > > >> > > >> > additions for
> > > >> > > >> > that property. This shouldn't really be done that way anyway,
> > > >> > > >> > instead
> > > >> > > >> > of using a direct phandle, you should be using the of-graph,
> > > >> > > >> > with the
> > > >> > > >> > TCON-top sitting where it belongs in the flow of data.
> > > >> > > >>
> > > >> > > >> Just to answer to the first question, it did describe it in
> > > >> > > >> "[PATCH
> > > >> > > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
> > > >> > > >>
> > > >> > > >> As why I designed it that way - HW representation could be
> > > >> > > >> described
> > > >> > > >> that way> >>
> > > >> > > >>
> > > >> > > >> (ASCII art makes sense when fixed width font is used to view
> it):
> > > >> > > >> / LCD0/LVDS0
> > > >> > > >>
> > > >> > > >> / TCON-LCD0
> > > >> > > >>
> > > >> > > >> | \ MIPI DSI
> > > >> > > >>
> > > >> > > >> mixer0 |
> > > >> > > >>
> > > >> > > >> \ / TCON-LCD1 - LCD1/LVDS1
> > > >> > > >>
> > > >> > > >> TCON-TOP
> > > >> > > >>
> > > >> > > >> / \ TCON-TV0 - TVE0/RGB
> > > >> > > >>
> > > >> > > >> mixer1 | \
> > > >> > > >>
> > > >> > > >> | TCON-TOP - HDMI
> > > >> > > >> |
> > > >> > > >> | /
> > > >> > > >>
> > > >> > > >> \ TCON-TV1 - TVE1/RGB
> > > >> > > >>
> > > >> > > >> This is a bit simplified, since there is also TVE-TOP, which is
> > > >> > > >> responsible
> > > >> > > >> for sharing 4 DACs between both TVE encoders. You can have two
> > > >> > > >> TV outs
> > > >> > > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It
> > > >> > > >> even
> > > >> > > >> seems that you can arbitrarly choose which DAC is responsible
> > > >> > > >> for
> > > >> > > >> which signal, so there is a ton of possible end combinations,
> > > >> > > >> but I'm
> > > >> > > >> not 100% sure.
> > > >> > > >>
> > > >> > > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40
> > > >> > > >> manual
> > > >> > > >> suggest more possibilities, although some of them seem wrong,
> > > >> > > >> like RGB
> > > >> > > >> feeding from LCD TCON. That is confirmed to be wrong when
> > > >> > > >> checking BSP
> > > >> > > >> code.
> > > >> > > >>
> > > >> > > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0,
> > > >> > > >> TVE1 and
> > > >> > > >> LCD1 for pin muxing, although I'm not sure why is that needed at
> > > >> > > >> all,
> > > >> > > >> since according to R40 datasheet, TVE0 and TVE1 pins are
> > > >> > > >> dedicated and
> > > >> > > >> not on PORT D and PORT H, respectively, as TCON-TOP
> > > >> > > >> documentation
> > > >> > > >> suggest. However, HSYNC and PSYNC lines might be shared between
> > > >> > > >> TVE
> > > >> > > >> (when it works in RGB mode) and LCD. But that is just my guess
> > > >> > > >> since
> > > >> > > >> I'm not really familiar with RGB and LCD interfaces.
> > > >> > > >>
> > > >> > > >> I'm really not sure what would be the best representation in
> > > >> > > >> OF-graph.
> > > >> > > >> Can you suggest one?
> > > >> > > >
> > > >> > > > Rob might disagree on this one, but I don't see anything wrong
> > > >> > > > with
> > > >> > > > having loops in the graph. If the TCON-TOP can be both the input
> > > >> > > > and
> > > >> > > > output of the TCONs, then so be it, and have it described that
> > > >> > > > way in
> > > >> > > > the graph.
> > > >> > > >
> > > >> > > > The code is already able to filter out nodes that have already
> > > >> > > > been
> > > >> > > > added to the list of devices we need to wait for in the component
> > > >> > > > framework, so that should work as well.
> > > >> > > >
> > > >> > > > And we'd need to describe TVE-TOP as well, even though we don't
> > > >> > > > have a
> > > >> > > > driver for it yet. That will simplify the backward compatibility
> > > >> > > > later
> > > >> > > > on.
> > > >> > >
> > > >> > > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer
> > > >> > > that
> > > >> > > binds everything together, and provides signal routing, kind of
> > > >> > > like
> > > >> > > DE-TOP on A64. So the signal mux controls that were originally
> > > >> > > found
> > > >> > > in TCON0 and TVE0 were moved out.
> > > >> > >
> > > >> > > The driver needs to know about that, but the graph about doesn't
> > > >> > > make
> > > >> > > much sense directly. Without looking at the manual, I understand it
> > > >> > > to
> > > >> > > likely be one mux between the mixers and TCONs, and one between the
> > > >> > > TCON-TVs and HDMI. Would it make more sense to just have the graph
> > > >> > > connections between the muxed components, and remove TCON-TOP from
> > > >> > > it, like we had in the past? A phandle could be used to reference
> > > >> > > the TCON-TOP for mux controls, in addition to the clocks and
> > > >> > > resets.
> > > >> > >
> > > >> > > For TVE, we would need something to represent each of the output
> > > >> > > pins,
> > > >> > > so the device tree can actually describe what kind of signal, be it
> > > >> > > each component of RGB/YUV or composite video, is wanted on each
> > > >> > > pin,
> > > >> > > if any. This is also needed on the A20 for the Cubietruck, so we
> > > >> > > can
> > > >> > > describe which pins are tied to the VGA connector, and which one
> > > >> > > does
> > > >> > > R, G, or B.
> > > >> >
> > > >> > I guess we'll see how the DT maintainers feel about this, but my
> > > >> > impression is that the OF graph should model the flow of data between
> > > >> > the devices. If there's a mux somewhere, then the data is definitely
> > > >> > going through it, and as such it should be part of the graph.
> > > >>
> > > >> I concur, but I spent few days thinking how to represent this sanely in
> > > >> graph, but I didn't find any good solution. I'll represent here my
> > > >> idea and please tell your opinion before I start implementing it.
> > > >>
> > > >> First, let me be clear that mixer0 and mixer1 don't have same
> > > >> capabilities
> > > >> (different number of planes, mixer0 supports writeback, mixer1 does
> > > >> not,
> > > >> etc.). Thus, it does matter which mixer is connected to which
> > > >> TCON/encoder.
> > > >> mixer0 is meant to be connected to main display and mixer1 to
> > > >> auxiliary. That obviously depends on end system.
> > > >>
> > > >> So, TCON TOP has 3 muxes, which have to be represented in graph. Two of
> > > >> them are for mixer/TCON relationship (each of them 1 input and 4
> > > >> possible outputs) and one for TV TCON/HDMI pair selection (2 possible
> > > >> inputs, 1 output).
> > > >>
> > > >> According to current practice in sun4i-drm driver, graph has to have
> > > >> port 0, representing input and port 1, representing output. This would
> > > >> mean that graph looks something like that:
> > > >>
> > > >> tcon_top: tcon-top at 1c70000 {
> > > >>
> > > >> compatible = "allwinner,sun8i-r40-tcon-top";
> > > >> ...
> > > >> ports {
> > > >>
> > > >> #address-cells = <1>;
> > > >> #size-cells = <0>;
> > > >>
> > > >> tcon_top_in: port at 0 {
> > > >>
> > > >> #address-cells = <1>;
> > > >> #size-cells = <0>;
> > > >> reg = <0>;
> > > >>
> > > >> tcon_top_in_mixer0: endpoint at 0 {
> > > >>
> > > >> reg = <0>;
> > > >> remote-endpoint = <&mixer0_out_tcon_top>;
> > > >>
> > > >> };
> > > >>
> > > >> tcon_top_in_mixer1: endpoint at 1 {
> > > >>
> > > >> reg = <1>;
> > > >> remote-endpoint = <&mixer1_out_tcon_top>;
> > > >>
> > > >> };
> > > >>
> > > >> tcon_top_in_tcon_tv: endpoint at 2 {
> > > >>
> > > >> reg = <2>;
> > > >> // here is HDMI input connection, part of
> > > >> board DTS
> > > >> remote-endpoint = <board specific phandle
> > > >> to TV TCON output>;
> > > >>
> > > >> };
> > > >>
> > > >> };
> > > >>
> > > >> tcon_top_out: port at 1 {
> > > >>
> > > >> #address-cells = <1>;
> > > >> #size-cells = <0>;
> > > >> reg = <1>;
> > > >>
> > > >> tcon_top_out_tcon0: endpoint at 0 {
> > > >>
> > > >> reg = <0>;
> > > >> // here is mixer0 output connection, part
> > > >> of board DTS
> > > >> remote-endpoint = <board specific phandle
> > > >> to TCON>;
> > > >>
> > > >> };
> > > >>
> > > >> tcon_top_out_tcon1: endpoint at 1 {
> > > >>
> > > >> reg = <1>;
> > > >> // here is mixer1 output connection, part
> > > >> of board DTS
> > > >> remote-endpoint = <board specific phandle
> > > >> to TCON>;
> > > >>
> > > >> };
> > > >>
> > > >> tcon_top_out_hdmi: endpoint at 2 {
> > > >>
> > > >> reg = <2>;
> > > >> remote-endpoint = <&hdmi_in_tcon_top>;
> > > >>
> > > >> };
> > > >>
> > > >> };
> > > >>
> > > >> };
> > > >>
> > > >> };
> > > >
> > > > IIRC, each port is supposed to be one route for the data, so we would
> > > > have multiple ports, one for the mixers in input and for the tcon in
> > > > output, and one for the TCON in input and for the HDMI/TV in
> > > > output. Rob might correct me here.
>
> Ok, that seems more clean approach. I'll have to extend graph traversing
> algorithm in sun4i_drv.c, but that's no problem.
>
> Just to be clear, you have in mind 3 pairs of ports (0/1 for mixer0 mux, 2/3
> for mixer1 and 4/5 for HDMI input), right? That way each mux is represented
> with one pair of ports, even numbered for input and odd numbered for output.
Yep, unless Rob feels otherwise.
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/20180604/dcdd3d1c/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Florian Fainelli @ 2018-06-04 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526668446-20048-1-git-send-email-scott.branden@broadcom.com>
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>
> ---
> .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 --------------------
> .../boot/dts/broadcom/stingray/bcm958742k.dts | 2 +
> .../boot/dts/broadcom/stingray/bcm958742t.dts | 2 +
> .../boot/dts/broadcom/stingray/stingray-sata.dtsi | 68 ++++++++++++++++++++++
> 4 files changed, 72 insertions(+), 64 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> index 8862ec9..cacc25e 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
> @@ -72,70 +72,6 @@
> <0x00000008 0x80000000 0x1 0x80000000>; /* 6G @ 34G */
> };
>
> -&sata0 {
> - status = "okay";
> -};
> -
> -&sata_phy0{
> - status = "okay";
> -};
> -
> -&sata1 {
> - status = "okay";
> -};
> -
> -&sata_phy1{
> - status = "okay";
> -};
> -
> -&sata2 {
> - status = "okay";
> -};
> -
> -&sata_phy2{
> - status = "okay";
> -};
> -
> -&sata3 {
> - status = "okay";
> -};
> -
> -&sata_phy3{
> - status = "okay";
> -};
> -
> -&sata4 {
> - status = "okay";
> -};
> -
> -&sata_phy4{
> - status = "okay";
> -};
> -
> -&sata5 {
> - status = "okay";
> -};
> -
> -&sata_phy5{
> - status = "okay";
> -};
> -
> -&sata6 {
> - status = "okay";
> -};
> -
> -&sata_phy6{
> - status = "okay";
> -};
> -
> -&sata7 {
> - status = "okay";
> -};
> -
> -&sata_phy7{
> - status = "okay";
> -};
> -
> &mdio_mux_iproc {
> mdio at 10 {
> gphy0: eth-phy at 10 {
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> index 77efa28..a515346 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
> @@ -32,6 +32,8 @@
>
> /dts-v1/;
>
> +#define NUM_SATA 8
> +
> #include "bcm958742-base.dtsi"
>
> / {
> diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> index 5084b03..6a4d19e 100644
> --- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> +++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
> @@ -32,6 +32,8 @@
>
> /dts-v1/;
>
> +#define NUM_SATA 8
> +
> #include "bcm958742-base.dtsi"
>
> / {
> 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
>
> sata0_port0: sata-port at 0 {
> reg = <0>;
> @@ -58,7 +62,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 0)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata0_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -73,7 +81,11 @@
> interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 1)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata1_port0: sata-port at 0 {
> reg = <0>;
> @@ -88,7 +100,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 1)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata1_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -103,7 +119,11 @@
> interrupts = <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 2)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata2_port0: sata-port at 0 {
> reg = <0>;
> @@ -118,7 +138,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 2)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata2_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -133,7 +157,11 @@
> interrupts = <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 3)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata3_port0: sata-port at 0 {
> reg = <0>;
> @@ -148,7 +176,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 3)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata3_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -163,7 +195,11 @@
> interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 4)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata4_port0: sata-port at 0 {
> reg = <0>;
> @@ -178,7 +214,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 4)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata4_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -193,7 +233,11 @@
> interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 5)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata5_port0: sata-port at 0 {
> reg = <0>;
> @@ -208,7 +252,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 5)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata5_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -223,7 +271,11 @@
> interrupts = <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 6)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata6_port0: sata-port at 0 {
> reg = <0>;
> @@ -238,7 +290,11 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 6)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata6_phy0: sata-phy at 0 {
> reg = <0>;
> @@ -253,7 +309,11 @@
> interrupts = <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 7)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata7_port0: sata-port at 0 {
> reg = <0>;
> @@ -268,11 +328,19 @@
> reg-names = "phy";
> #address-cells = <1>;
> #size-cells = <0>;
> +#if (NUM_SATA > 7)
> + status = "okay";
> +#else
> status = "disabled";
> +#endif
>
> sata7_phy0: sata-phy at 0 {
> reg = <0>;
> #phy-cells = <0>;
> };
> };
> +
> +#if (NUM_SATA > 8)
> +#error "NUM_SATA > 8"
> +#endif
> };
>
--
Florian
^ permalink raw reply
* [PATCH v8 0/2] SDM845 System Cache Driver
From: rishabhb at codeaurora.org @ 2018-06-04 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527122121-31452-1-git-send-email-rishabhb@codeaurora.org>
On 2018-05-23 17:35, Rishabh Bhatnagar wrote:
> This series implements system cache or LLCC(Last Level Cache
> Controller)
> driver for SDM845 SOC. The purpose of the driver is to partition the
> system cache and program the settings such as priortiy, lines to probe
> while doing a look up in the system cache, low power related settings
> etc.
> The partitions are called cache slices. Each cache slice is associated
> with size and SCID(System Cache ID). The driver also provides API for
> clients to query the cache slice details,activate and deactivate them.
>
> The driver can be broadly classified into:
> * SOC specific driver: llcc-sdm845.c: Cache partitioning and cache
> slice
> properties for usecases on sdm845 that need to use system cache.
>
> * API : llcc-slice.c: Exports APIs to clients to query cache slice
> details,
> activate and deactivate cache slices.
>
> Changes since v7:
> * Change the DT node name to cache-controller.
> * Use the module_platform_driver_macro
> * Use GENMASK and SZ_* macros
> * Correct indentation, and remove unnecessary assignemnts.
> * Addresed all comments by Andy Schevchenko except the comment to
> ignore some
> lines of code going over 80 characters.
>
> Changes since v6:
> * Remove the max-slices property from DT.
> * Make client's slice_ids as macros.
> * Unlock mutex while returning from function in case of error.
>
> Changes since v5:
> * Remove client information from DT.
> * Make the llcc driver data as global.
> * Check return value of llcc_update_act_ctrl function
> * Change error returned from -EFAULT to -EINVAL
>
> Changes since v4:
> * Remove null pointer checks as per comments.
> * Remove extra blank lines.
>
> Changes since v3:
> * Use the regmap_read_poll_timeout function
> * Check for regmap read/write errors.
> * Remove memory barrier after regmap write
> * Derive memory bank offsets using stride macro variable
> * Remove debug statements from code
> * Remove the qcom_llcc_remove function
> * Use if IS_ENABLED in place of ifdef for built-in module
> * Change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
> * Remove unnecessary free functions
> * Change the variable names as per review comments
>
> Changes since v2:
> * Corrected the Makefile to fix compilation.
>
> Changes since v1:
> * Added Makefile and Kconfig.
>
> Changes since v0:
> * Removed the syscon and simple-mfd approach
> * Updated the device tree nodes to mention LLCC as a single HW block
> * Moved llcc bank offsets from device tree and handled the offset
> in the driver.
>
> ckadabi at codeaurora.org (2):
> dt-bindings: Documentation for qcom, llcc
> drivers: soc: Add LLCC driver
>
> .../devicetree/bindings/arm/msm/qcom,llcc.txt | 26 ++
> drivers/soc/qcom/Kconfig | 17 ++
> drivers/soc/qcom/Makefile | 2 +
> drivers/soc/qcom/llcc-sdm845.c | 94 ++++++
> drivers/soc/qcom/llcc-slice.c | 335
> +++++++++++++++++++++
> include/linux/soc/qcom/llcc-qcom.h | 180 +++++++++++
> 6 files changed, 654 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt
> create mode 100644 drivers/soc/qcom/llcc-sdm845.c
> create mode 100644 drivers/soc/qcom/llcc-slice.c
> create mode 100644 include/linux/soc/qcom/llcc-qcom.h
Does this spin look fine to everyone? If yes can we go ahead and merge
this?
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Boris Brezillon @ 2018-06-04 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28c58ca3-d8ca-7195-3aa2-10d7c703dd65@microchip.com>
On Mon, 4 Jun 2018 18:46:56 +0300
Tudor Ambarus <tudor.ambarus@microchip.com> wrote:
> Hi, Peter,
>
> On 05/28/2018 01:10 PM, Peter Rosin wrote:
>
> [cut]
>
> > So, I think I want either
> >
> > A) the NAND controller to use master 1 DMAC0/IF0 (i.e. slave 8 DDR2 port 2) and
> > the LCDC to use master 9 (i.e. slave 9 DDR2 Port 3)
> >
> > or
> >
> > B) the NAND controller to use master 2 DMAC0/IF1 (i.e. slave 7 DDR2 port 1, and
> > possibly slave 9 DDR2 port 3 (if my previous findings are relevant) and the
> > LCDC to use master 8 (i.e. slave 8 DDR2 Port 2)
>
> My understanding is that "Table 14-3. Master to Slave Access" describes
> what connections are allowed between the masters and slaves, while the
> PRxSy registers just set the priorities. What happens when you assign
> the highest priority to a master to slave connection that is not
> allowed? Probably it is ignored, but I'll check with the hardware team.
> So I expect that the NAND controller can not use DDR2 port 3 regardless
> of the priority set.
>
> [cut]
>
> > So, output is as expected and I believe that the patch makes the NAND DMA
> > accesses use master 2 DMAC0/IF1 and are thus forced to use slave 7 DDR2 Port 1
> > (and possibly 9). The LCDC is using slave 8 DDR2 Port 2. So there should be no
> > slave conflict?
> >
> > But the on-screen crap remains during NAND accesses.
>
> No conflict, but you missed to dispatch the load on the LCDC DMA
> masters, if I understood correctly.
>
> So, I think we want to test the following:
> - NAND controller to use DMAC0/IF1 (slave 7 DDR2 port 1)
As I explained in one of my previous email, it's not that easy to set
up, because the SRAM is connected to IF0, and we're using DMA memcpy
here. Also, I don't see how it could solve Peter's problem if, even
when he switches to LCDC master 9 for the primary overlay, he still
keeps experiencing FIFO underruns.
> - LCDC to use master 8 (slave 8 DDR2 Port 2) and master 9 (slave 9 DDR2
> Port 3).
Except that only works if you have several overlays activated, which
AFAIR, is not the case in Peter's setup.
^ permalink raw reply
* [RFC PATCH -tip v5 24/27] bpf: error-inject: kprobes: Clear current_kprobe and enable preempt in kprobe
From: Masami Hiramatsu @ 2018-06-04 16:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152812730943.10068.5166429445118734697.stgit@devbox>
Clear current_kprobe and enable preemption in kprobe
even if pre_handler returns !0.
This simplifies function override using kprobes.
Jprobe used to require to keep the preemption disabled and
keep current_kprobe until it returned to original function
entry. For this reason kprobe_int3_handler() and similar
arch dependent kprobe handers checks pre_handler result
and exit without enabling preemption if the result is !0.
After removing the jprobe, Kprobes does not need to
keep preempt disabled even if user handler returns !0
anymore.
But since the function override handler in error-inject
and bpf is also returns !0 if it overrides a function,
to balancing the preempt count, it enables preemption
and reset current kprobe by itself.
That is a bad design that is very buggy. This fixes
such unbalanced preempt-count and current_kprobes setting
in kprobes, bpf and error-inject.
Note: for powerpc and x86, this removes all preempt_disable
from kprobe_ftrace_handler because ftrace callbacks are
called under preempt disabled.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Josef Bacik <jbacik@fb.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: x86 at kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-ia64 at vger.kernel.org
Cc: linux-mips at linux-mips.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-s390 at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: sparclinux at vger.kernel.org
---
Changes in v5:
- Fix kprobe_ftrace_handler in arch/powerpc too.
---
arch/arc/kernel/kprobes.c | 5 +++--
arch/arm/probes/kprobes/core.c | 10 +++++-----
arch/arm64/kernel/probes/kprobes.c | 10 +++++-----
arch/ia64/kernel/kprobes.c | 13 ++++---------
arch/mips/kernel/kprobes.c | 4 ++--
arch/powerpc/kernel/kprobes-ftrace.c | 15 ++++++---------
arch/powerpc/kernel/kprobes.c | 7 +++++--
arch/s390/kernel/kprobes.c | 7 ++++---
arch/sh/kernel/kprobes.c | 7 ++++---
arch/sparc/kernel/kprobes.c | 7 ++++---
arch/x86/kernel/kprobes/core.c | 4 ++++
arch/x86/kernel/kprobes/ftrace.c | 15 ++++++++-------
kernel/fail_function.c | 3 ---
kernel/trace/trace_kprobe.c | 11 +++--------
14 files changed, 57 insertions(+), 61 deletions(-)
diff --git a/arch/arc/kernel/kprobes.c b/arch/arc/kernel/kprobes.c
index 465365696c91..df35d4c0b0b8 100644
--- a/arch/arc/kernel/kprobes.c
+++ b/arch/arc/kernel/kprobes.c
@@ -231,6 +231,9 @@ int __kprobes arc_kprobe_handler(unsigned long addr, struct pt_regs *regs)
if (!p->pre_handler || !p->pre_handler(p, regs)) {
setup_singlestep(p, regs);
kcb->kprobe_status = KPROBE_HIT_SS;
+ } else {
+ reset_current_kprobe();
+ preempt_enable_no_resched();
}
return 1;
@@ -442,9 +445,7 @@ static int __kprobes trampoline_probe_handler(struct kprobe *p,
kretprobe_assert(ri, orig_ret_address, trampoline_address);
regs->ret = orig_ret_address;
- reset_current_kprobe();
kretprobe_hash_unlock(current, &flags);
- preempt_enable_no_resched();
hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
hlist_del(&ri->hlist);
diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index 3192350f389d..8d37601fdb20 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -300,10 +300,10 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
/*
* If we have no pre-handler or it returned 0, we
- * continue with normal processing. If we have a
- * pre-handler and it returned non-zero, it prepped
- * for calling the break_handler below on re-entry,
- * so get out doing nothing more here.
+ * continue with normal processing. If we have a
+ * pre-handler and it returned non-zero, it will
+ * modify the execution path and no need to single
+ * stepping. Let's just reset current kprobe and exit.
*/
if (!p->pre_handler || !p->pre_handler(p, regs)) {
kcb->kprobe_status = KPROBE_HIT_SS;
@@ -312,8 +312,8 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
kcb->kprobe_status = KPROBE_HIT_SSDONE;
p->post_handler(p, regs, 0);
}
- reset_current_kprobe();
}
+ reset_current_kprobe();
}
} else {
/*
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 076c3c0775a6..5daf3d721cb7 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -395,9 +395,9 @@ static void __kprobes kprobe_handler(struct pt_regs *regs)
/*
* If we have no pre-handler or it returned 0, we
* continue with normal processing. If we have a
- * pre-handler and it returned non-zero, it prepped
- * for calling the break_handler below on re-entry,
- * so get out doing nothing more here.
+ * pre-handler and it returned non-zero, it will
+ * modify the execution path and no need to single
+ * stepping. Let's just reset current kprobe and exit.
*
* pre_handler can hit a breakpoint and can step thru
* before return, keep PSTATE D-flag enabled until
@@ -405,8 +405,8 @@ static void __kprobes kprobe_handler(struct pt_regs *regs)
*/
if (!p->pre_handler || !p->pre_handler(p, regs)) {
setup_singlestep(p, regs, kcb, 0);
- return;
- }
+ } else
+ reset_current_kprobe();
}
}
/*
diff --git a/arch/ia64/kernel/kprobes.c b/arch/ia64/kernel/kprobes.c
index 74c8524e6309..aa41bd5cf9b7 100644
--- a/arch/ia64/kernel/kprobes.c
+++ b/arch/ia64/kernel/kprobes.c
@@ -478,12 +478,9 @@ int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
*/
break;
}
-
kretprobe_assert(ri, orig_ret_address, trampoline_address);
- reset_current_kprobe();
kretprobe_hash_unlock(current, &flags);
- preempt_enable_no_resched();
hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
hlist_del(&ri->hlist);
@@ -851,13 +848,11 @@ static int __kprobes pre_kprobes_handler(struct die_args *args)
set_current_kprobe(p, kcb);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
- if (p->pre_handler && p->pre_handler(p, regs))
- /*
- * Our pre-handler is specifically requesting that we just
- * do a return. This is used for both the jprobe pre-handler
- * and the kretprobe trampoline
- */
+ if (p->pre_handler && p->pre_handler(p, regs)) {
+ reset_current_kprobe();
+ preempt_enable_no_resched();
return 1;
+ }
#if !defined(CONFIG_PREEMPT)
if (p->ainsn.inst_flag == INST_FLAG_BOOSTABLE && !p->post_handler) {
diff --git a/arch/mips/kernel/kprobes.c b/arch/mips/kernel/kprobes.c
index 7fd277bc59b9..54cd675c5d1d 100644
--- a/arch/mips/kernel/kprobes.c
+++ b/arch/mips/kernel/kprobes.c
@@ -358,6 +358,8 @@ static int __kprobes kprobe_handler(struct pt_regs *regs)
if (p->pre_handler && p->pre_handler(p, regs)) {
/* handler has already set things up, so skip ss setup */
+ reset_current_kprobe();
+ preempt_enable_no_resched();
return 1;
}
@@ -543,9 +545,7 @@ static int __kprobes trampoline_probe_handler(struct kprobe *p,
kretprobe_assert(ri, orig_ret_address, trampoline_address);
instruction_pointer(regs) = orig_ret_address;
- reset_current_kprobe();
kretprobe_hash_unlock(current, &flags);
- preempt_enable_no_resched();
hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
hlist_del(&ri->hlist);
diff --git a/arch/powerpc/kernel/kprobes-ftrace.c b/arch/powerpc/kernel/kprobes-ftrace.c
index 3869b0e5d5c7..c80c35d1e26e 100644
--- a/arch/powerpc/kernel/kprobes-ftrace.c
+++ b/arch/powerpc/kernel/kprobes-ftrace.c
@@ -51,11 +51,9 @@ void kprobe_ftrace_handler(unsigned long nip, unsigned long parent_nip,
struct kprobe *p;
struct kprobe_ctlblk *kcb;
- preempt_disable();
-
p = get_kprobe((kprobe_opcode_t *)nip);
if (unlikely(!p) || kprobe_disabled(p))
- goto end;
+ return;
kcb = get_kprobe_ctlblk();
if (kprobe_running()) {
@@ -75,15 +73,14 @@ void kprobe_ftrace_handler(unsigned long nip, unsigned long parent_nip,
skip_singlestep(p, regs, kcb, orig_nip);
else {
/*
- * If pre_handler returns !0, it sets regs->nip and
- * resets current kprobe. In this case, we should not
- * re-enable preemption.
+ * If pre_handler returns !0, this handler
+ * modifies regs->ip and goes back to there
+ * directly without single stepping.
+ * So let's just clear current kprobe.
*/
- return;
+ __this_cpu_write(current_kprobe, NULL);
}
}
-end:
- preempt_enable_no_resched();
}
NOKPROBE_SYMBOL(kprobe_ftrace_handler);
diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index f06747e2e70d..5c60bb0f927f 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -358,9 +358,12 @@ int kprobe_handler(struct pt_regs *regs)
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
set_current_kprobe(p, regs, kcb);
- if (p->pre_handler && p->pre_handler(p, regs))
- /* handler has already set things up, so skip ss setup */
+ if (p->pre_handler && p->pre_handler(p, regs)) {
+ /* handler changed execution path, so skip ss setup */
+ reset_current_kprobe();
+ preempt_enable_no_resched();
return 1;
+ }
if (p->ainsn.boostable >= 0) {
ret = try_to_emulate(p, regs);
diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c
index 3e34018960b5..7c0a095e9c5f 100644
--- a/arch/s390/kernel/kprobes.c
+++ b/arch/s390/kernel/kprobes.c
@@ -326,8 +326,11 @@ static int kprobe_handler(struct pt_regs *regs)
*/
push_kprobe(kcb, p);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
- if (p->pre_handler && p->pre_handler(p, regs))
+ if (p->pre_handler && p->pre_handler(p, regs)) {
+ pop_kprobe(kcb);
+ preempt_enable_no_resched();
return 1;
+ }
kcb->kprobe_status = KPROBE_HIT_SS;
}
enable_singlestep(kcb, regs, (unsigned long) p->ainsn.insn);
@@ -431,9 +434,7 @@ static int trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
regs->psw.addr = orig_ret_address;
- pop_kprobe(get_kprobe_ctlblk());
kretprobe_hash_unlock(current, &flags);
- preempt_enable_no_resched();
hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
hlist_del(&ri->hlist);
diff --git a/arch/sh/kernel/kprobes.c b/arch/sh/kernel/kprobes.c
index 4fafe0cd12c6..241e903dd3ee 100644
--- a/arch/sh/kernel/kprobes.c
+++ b/arch/sh/kernel/kprobes.c
@@ -272,9 +272,12 @@ static int __kprobes kprobe_handler(struct pt_regs *regs)
set_current_kprobe(p, regs, kcb);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
- if (p->pre_handler && p->pre_handler(p, regs))
+ if (p->pre_handler && p->pre_handler(p, regs)) {
/* handler has already set things up, so skip ss setup */
+ reset_current_kprobe();
+ preempt_enable_no_resched();
return 1;
+ }
prepare_singlestep(p, regs);
kcb->kprobe_status = KPROBE_HIT_SS;
@@ -352,8 +355,6 @@ int __kprobes trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
regs->pc = orig_ret_address;
kretprobe_hash_unlock(current, &flags);
- preempt_enable_no_resched();
-
hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
hlist_del(&ri->hlist);
kfree(ri);
diff --git a/arch/sparc/kernel/kprobes.c b/arch/sparc/kernel/kprobes.c
index c684c96ef2e9..dfbca2470536 100644
--- a/arch/sparc/kernel/kprobes.c
+++ b/arch/sparc/kernel/kprobes.c
@@ -175,8 +175,11 @@ static int __kprobes kprobe_handler(struct pt_regs *regs)
set_current_kprobe(p, regs, kcb);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
- if (p->pre_handler && p->pre_handler(p, regs))
+ if (p->pre_handler && p->pre_handler(p, regs)) {
+ reset_current_kprobe();
+ preempt_enable_no_resched();
return 1;
+ }
prepare_singlestep(p, regs, kcb);
kcb->kprobe_status = KPROBE_HIT_SS;
@@ -508,9 +511,7 @@ static int __kprobes trampoline_probe_handler(struct kprobe *p,
regs->tpc = orig_ret_address;
regs->tnpc = orig_ret_address + 4;
- reset_current_kprobe();
kretprobe_hash_unlock(current, &flags);
- preempt_enable_no_resched();
hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
hlist_del(&ri->hlist);
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 0ac16a0d93e5..814e26b7c8a2 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -694,6 +694,10 @@ int kprobe_int3_handler(struct pt_regs *regs)
*/
if (!p->pre_handler || !p->pre_handler(p, regs))
setup_singlestep(p, regs, kcb, 0);
+ else {
+ reset_current_kprobe();
+ preempt_enable_no_resched();
+ }
return 1;
}
} else if (*addr != BREAKPOINT_INSTRUCTION) {
diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
index c8696f2a583f..310ef737b9d4 100644
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -63,18 +63,19 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
/* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
regs->ip = ip + sizeof(kprobe_opcode_t);
- /* To emulate trap based kprobes, preempt_disable here */
- preempt_disable();
__this_cpu_write(current_kprobe, p);
kcb->kprobe_status = KPROBE_HIT_ACTIVE;
if (!p->pre_handler || !p->pre_handler(p, regs)) {
skip_singlestep(p, regs, kcb, orig_ip);
- preempt_enable_no_resched();
+ } else {
+ /*
+ * If pre_handler returns !0, this handler
+ * modifies regs->ip and goes back to there
+ * directly without single stepping.
+ * So let's just clear current kprobe.
+ */
+ __this_cpu_write(current_kprobe, NULL);
}
- /*
- * If pre_handler returns !0, it sets regs->ip and
- * resets current kprobe, and keep preempt count +1.
- */
}
}
NOKPROBE_SYMBOL(kprobe_ftrace_handler);
diff --git a/kernel/fail_function.c b/kernel/fail_function.c
index 1d5632d8bbcc..b090688df94f 100644
--- a/kernel/fail_function.c
+++ b/kernel/fail_function.c
@@ -184,9 +184,6 @@ static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs)
if (should_fail(&fei_fault_attr, 1)) {
regs_set_return_value(regs, attr->retval);
override_function_with_return(regs);
- /* Kprobe specific fixup */
- reset_current_kprobe();
- preempt_enable_no_resched();
return 1;
}
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 02aed76e0978..b65cd6834450 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1217,16 +1217,11 @@ kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs *regs)
/*
* We need to check and see if we modified the pc of the
- * pt_regs, and if so clear the kprobe and return 1 so that we
- * don't do the single stepping.
- * The ftrace kprobe handler leaves it up to us to re-enable
- * preemption here before returning if we've modified the ip.
+ * pt_regs, and if so return 1 so that we don't do the
+ * single stepping.
*/
- if (orig_ip != instruction_pointer(regs)) {
- reset_current_kprobe();
- preempt_enable_no_resched();
+ if (orig_ip != instruction_pointer(regs))
return 1;
- }
if (!ret)
return 0;
}
^ permalink raw reply related
* [RFC PATCH -tip v5 17/27] arm64: kprobes: Don't call the ->break_handler() in arm kprobes code
From: Masami Hiramatsu @ 2018-06-04 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152812730943.10068.5166429445118734697.stgit@devbox>
Don't call the ->break_handler() from the arm kprobes code,
because it was only used by jprobes which got removed.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm64/kernel/probes/kprobes.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index 3ca2351109a6..076c3c0775a6 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -408,14 +408,6 @@ static void __kprobes kprobe_handler(struct pt_regs *regs)
return;
}
}
- } else if ((le32_to_cpu(*(kprobe_opcode_t *) addr) ==
- BRK64_OPCODE_KPROBES) && cur_kprobe) {
- /* We probably hit a jprobe. Call its break handler. */
- if (cur_kprobe->break_handler &&
- cur_kprobe->break_handler(cur_kprobe, regs)) {
- setup_singlestep(cur_kprobe, regs, kcb, 0);
- return;
- }
}
/*
* The breakpoint instruction was removed right
^ permalink raw reply related
* [RFC PATCH -tip v5 16/27] ARM: kprobes: Don't call the ->break_handler() in arm kprobes code
From: Masami Hiramatsu @ 2018-06-04 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152812730943.10068.5166429445118734697.stgit@devbox>
Don't call the ->break_handler() from the arm kprobes code,
because it was only used by jprobes which got removed.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/probes/kprobes/core.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index 23562111c511..3192350f389d 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -315,17 +315,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
reset_current_kprobe();
}
}
- } else if (cur) {
- /* We probably hit a jprobe. Call its break handler. */
- if (cur->break_handler && cur->break_handler(cur, regs)) {
- kcb->kprobe_status = KPROBE_HIT_SS;
- singlestep(cur, regs, kcb);
- if (cur->post_handler) {
- kcb->kprobe_status = KPROBE_HIT_SSDONE;
- cur->post_handler(cur, regs, 0);
- }
- }
- reset_current_kprobe();
} else {
/*
* The probe was removed and a race is in progress.
^ permalink raw reply related
* [RFC PATCH -tip v5 06/27] arm64: kprobes: Remove jprobe implementation
From: Masami Hiramatsu @ 2018-06-04 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152812730943.10068.5166429445118734697.stgit@devbox>
Remove arch dependent setjump/longjump functions
and unused fields in kprobe_ctlblk for jprobes
from arch/arm64.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm64/include/asm/kprobes.h | 1 -
arch/arm64/kernel/probes/kprobes.c | 68 ------------------------------------
2 files changed, 69 deletions(-)
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 6deb8d726041..d5a44cf859e9 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -48,7 +48,6 @@ struct kprobe_ctlblk {
unsigned long saved_irqflag;
struct prev_kprobe prev_kprobe;
struct kprobe_step_ctx ss_ctx;
- struct pt_regs jprobe_saved_regs;
};
void arch_remove_kprobe(struct kprobe *);
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index d849d9804011..3ca2351109a6 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -465,74 +465,6 @@ kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
return DBG_HOOK_HANDLED;
}
-int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
-{
- struct jprobe *jp = container_of(p, struct jprobe, kp);
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
-
- kcb->jprobe_saved_regs = *regs;
- /*
- * Since we can't be sure where in the stack frame "stacked"
- * pass-by-value arguments are stored we just don't try to
- * duplicate any of the stack. Do not use jprobes on functions that
- * use more than 64 bytes (after padding each to an 8 byte boundary)
- * of arguments, or pass individual arguments larger than 16 bytes.
- */
-
- instruction_pointer_set(regs, (unsigned long) jp->entry);
- preempt_disable();
- pause_graph_tracing();
- return 1;
-}
-
-void __kprobes jprobe_return(void)
-{
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
-
- /*
- * Jprobe handler return by entering break exception,
- * encoded same as kprobe, but with following conditions
- * -a special PC to identify it from the other kprobes.
- * -restore stack addr to original saved pt_regs
- */
- asm volatile(" mov sp, %0 \n"
- "jprobe_return_break: brk %1 \n"
- :
- : "r" (kcb->jprobe_saved_regs.sp),
- "I" (BRK64_ESR_KPROBES)
- : "memory");
-
- unreachable();
-}
-
-int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
-{
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
- long stack_addr = kcb->jprobe_saved_regs.sp;
- long orig_sp = kernel_stack_pointer(regs);
- struct jprobe *jp = container_of(p, struct jprobe, kp);
- extern const char jprobe_return_break[];
-
- if (instruction_pointer(regs) != (u64) jprobe_return_break)
- return 0;
-
- if (orig_sp != stack_addr) {
- struct pt_regs *saved_regs =
- (struct pt_regs *)kcb->jprobe_saved_regs.sp;
- pr_err("current sp %lx does not match saved sp %lx\n",
- orig_sp, stack_addr);
- pr_err("Saved registers for jprobe %p\n", jp);
- __show_regs(saved_regs);
- pr_err("Current registers\n");
- __show_regs(regs);
- BUG();
- }
- unpause_graph_tracing();
- *regs = kcb->jprobe_saved_regs;
- preempt_enable_no_resched();
- return 1;
-}
-
bool arch_within_kprobe_blacklist(unsigned long addr)
{
if ((addr >= (unsigned long)__kprobes_text_start &&
^ permalink raw reply related
* [RFC PATCH -tip v5 05/27] ARM: kprobes: Remove jprobe arm implementation
From: Masami Hiramatsu @ 2018-06-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152812730943.10068.5166429445118734697.stgit@devbox>
Remove arch dependent setjump/longjump functions
and unused fields in kprobe_ctlblk for jprobes
from arch/arm.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/include/asm/kprobes.h | 2 -
arch/arm/include/asm/probes.h | 1
arch/arm/probes/kprobes/core.c | 114 ----------------------------------------
3 files changed, 117 deletions(-)
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index 59655459da59..82290f212d8e 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -44,8 +44,6 @@ struct prev_kprobe {
struct kprobe_ctlblk {
unsigned int kprobe_status;
struct prev_kprobe prev_kprobe;
- struct pt_regs jprobe_saved_regs;
- char jprobes_stack[MAX_STACK_SIZE];
};
void arch_remove_kprobe(struct kprobe *);
diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
index 1e5b9bb92270..991c9127c650 100644
--- a/arch/arm/include/asm/probes.h
+++ b/arch/arm/include/asm/probes.h
@@ -51,7 +51,6 @@ struct arch_probes_insn {
* We assume one instruction can consume at most 64 bytes stack, which is
* 'push {r0-r15}'. Instructions consume more or unknown stack space like
* 'str r0, [sp, #-80]' and 'str r0, [sp, r1]' should be prohibit to probe.
- * Both kprobe and jprobe use this macro.
*/
#define MAX_STACK_SIZE 64
diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index e90cc8a08186..23562111c511 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -47,9 +47,6 @@
(unsigned long)(addr) + \
(size))
-/* Used as a marker in ARM_pc to note when we're in a jprobe. */
-#define JPROBE_MAGIC_ADDR 0xffffffff
-
DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
@@ -521,117 +518,6 @@ void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
regs->ARM_lr = (unsigned long)&kretprobe_trampoline;
}
-int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
-{
- struct jprobe *jp = container_of(p, struct jprobe, kp);
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
- long sp_addr = regs->ARM_sp;
- long cpsr;
-
- kcb->jprobe_saved_regs = *regs;
- memcpy(kcb->jprobes_stack, (void *)sp_addr, MIN_STACK_SIZE(sp_addr));
- regs->ARM_pc = (long)jp->entry;
-
- cpsr = regs->ARM_cpsr | PSR_I_BIT;
-#ifdef CONFIG_THUMB2_KERNEL
- /* Set correct Thumb state in cpsr */
- if (regs->ARM_pc & 1)
- cpsr |= PSR_T_BIT;
- else
- cpsr &= ~PSR_T_BIT;
-#endif
- regs->ARM_cpsr = cpsr;
-
- preempt_disable();
- return 1;
-}
-
-void __kprobes jprobe_return(void)
-{
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
-
- __asm__ __volatile__ (
- /*
- * Setup an empty pt_regs. Fill SP and PC fields as
- * they're needed by longjmp_break_handler.
- *
- * We allocate some slack between the original SP and start of
- * our fabricated regs. To be precise we want to have worst case
- * covered which is STMFD with all 16 regs so we allocate 2 *
- * sizeof(struct_pt_regs)).
- *
- * This is to prevent any simulated instruction from writing
- * over the regs when they are accessing the stack.
- */
-#ifdef CONFIG_THUMB2_KERNEL
- "sub r0, %0, %1 \n\t"
- "mov sp, r0 \n\t"
-#else
- "sub sp, %0, %1 \n\t"
-#endif
- "ldr r0, ="__stringify(JPROBE_MAGIC_ADDR)"\n\t"
- "str %0, [sp, %2] \n\t"
- "str r0, [sp, %3] \n\t"
- "mov r0, sp \n\t"
- "bl kprobe_handler \n\t"
-
- /*
- * Return to the context saved by setjmp_pre_handler
- * and restored by longjmp_break_handler.
- */
-#ifdef CONFIG_THUMB2_KERNEL
- "ldr lr, [sp, %2] \n\t" /* lr = saved sp */
- "ldrd r0, r1, [sp, %5] \n\t" /* r0,r1 = saved lr,pc */
- "ldr r2, [sp, %4] \n\t" /* r2 = saved psr */
- "stmdb lr!, {r0, r1, r2} \n\t" /* push saved lr and */
- /* rfe context */
- "ldmia sp, {r0 - r12} \n\t"
- "mov sp, lr \n\t"
- "ldr lr, [sp], #4 \n\t"
- "rfeia sp! \n\t"
-#else
- "ldr r0, [sp, %4] \n\t"
- "msr cpsr_cxsf, r0 \n\t"
- "ldmia sp, {r0 - pc} \n\t"
-#endif
- :
- : "r" (kcb->jprobe_saved_regs.ARM_sp),
- "I" (sizeof(struct pt_regs) * 2),
- "J" (offsetof(struct pt_regs, ARM_sp)),
- "J" (offsetof(struct pt_regs, ARM_pc)),
- "J" (offsetof(struct pt_regs, ARM_cpsr)),
- "J" (offsetof(struct pt_regs, ARM_lr))
- : "memory", "cc");
-}
-
-int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
-{
- struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
- long stack_addr = kcb->jprobe_saved_regs.ARM_sp;
- long orig_sp = regs->ARM_sp;
- struct jprobe *jp = container_of(p, struct jprobe, kp);
-
- if (regs->ARM_pc == JPROBE_MAGIC_ADDR) {
- if (orig_sp != stack_addr) {
- struct pt_regs *saved_regs =
- (struct pt_regs *)kcb->jprobe_saved_regs.ARM_sp;
- printk("current sp %lx does not match saved sp %lx\n",
- orig_sp, stack_addr);
- printk("Saved registers for jprobe %p\n", jp);
- show_regs(saved_regs);
- printk("Current registers\n");
- show_regs(regs);
- BUG();
- }
- *regs = kcb->jprobe_saved_regs;
- memcpy((void *)stack_addr, kcb->jprobes_stack,
- MIN_STACK_SIZE(stack_addr));
- preempt_enable_no_resched();
- return 1;
- }
- return 0;
-}
-
int __kprobes arch_trampoline_kprobe(struct kprobe *p)
{
return 0;
^ permalink raw reply related
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Tudor Ambarus @ 2018-06-04 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3cc1894-2d7d-93b6-a9de-ed9ca4564ae9@axentia.se>
Hi, Peter,
On 05/28/2018 01:10 PM, Peter Rosin wrote:
[cut]
> So, I think I want either
>
> A) the NAND controller to use master 1 DMAC0/IF0 (i.e. slave 8 DDR2 port 2) and
> the LCDC to use master 9 (i.e. slave 9 DDR2 Port 3)
>
> or
>
> B) the NAND controller to use master 2 DMAC0/IF1 (i.e. slave 7 DDR2 port 1, and
> possibly slave 9 DDR2 port 3 (if my previous findings are relevant) and the
> LCDC to use master 8 (i.e. slave 8 DDR2 Port 2)
My understanding is that "Table 14-3. Master to Slave Access" describes
what connections are allowed between the masters and slaves, while the
PRxSy registers just set the priorities. What happens when you assign
the highest priority to a master to slave connection that is not
allowed? Probably it is ignored, but I'll check with the hardware team.
So I expect that the NAND controller can not use DDR2 port 3 regardless
of the priority set.
[cut]
> So, output is as expected and I believe that the patch makes the NAND DMA
> accesses use master 2 DMAC0/IF1 and are thus forced to use slave 7 DDR2 Port 1
> (and possibly 9). The LCDC is using slave 8 DDR2 Port 2. So there should be no
> slave conflict?
>
> But the on-screen crap remains during NAND accesses.
No conflict, but you missed to dispatch the load on the LCDC DMA
masters, if I understood correctly.
So, I think we want to test the following:
- NAND controller to use DMAC0/IF1 (slave 7 DDR2 port 1)
- LCDC to use master 8 (slave 8 DDR2 Port 2) and master 9 (slave 9 DDR2
Port 3).
Best,
ta
^ permalink raw reply
* [PATCH v3] of: platform: stop accessing invalid dev in of_platform_device_destroy
From: Rob Herring @ 2018-06-04 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604141408.3179-1-srinivas.kandagatla@linaro.org>
On Mon, Jun 04, 2018 at 03:14:08PM +0100, Srinivas Kandagatla wrote:
> Immediately after the platform_device_unregister() the device will be
> cleaned up. Accessing the freed pointer immediately after that will
> crash the system.
>
> Found this bug when kernel is built with CONFIG_PAGE_POISONING and testing
> loading/unloading audio drivers in a loop on Qcom platforms.
>
> Fix this by moving of_node_clear_flag() just before the unregister calls.
>
> Below is the crash trace:
>
> Unable to handle kernel paging request at virtual address 6b6b6b6b6b6c03
> Mem abort info:
> ESR = 0x96000021
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x00000021
> CM = 0, WnR = 0
> [006b6b6b6b6b6c03] address between user and kernel address ranges
> Internal error: Oops: 96000021 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 2 PID: 1784 Comm: sh Tainted: G W 4.17.0-rc7-02230-ge3a63a7ef641-dirty #204
> Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> pstate: 80000005 (Nzcv daif -PAN -UAO)
> pc : clear_bit+0x18/0x2c
> lr : of_platform_device_destroy+0x64/0xb8
> sp : ffff00000c9c3930
> x29: ffff00000c9c3930 x28: ffff80003d39b200
> x27: ffff000008bb1000 x26: 0000000000000040
> x25: 0000000000000124 x24: ffff80003a9a3080
> x23: 0000000000000060 x22: ffff00000939f518
> x21: ffff80003aa79e98 x20: ffff80003aa3dae0
> x19: ffff80003aa3c890 x18: ffff800009feb794
> x17: 0000000000000000 x16: 0000000000000000
> x15: ffff800009feb790 x14: 0000000000000000
> x13: ffff80003a058778 x12: ffff80003a058728
> x11: ffff80003a058750 x10: 0000000000000000
> x9 : 0000000000000006 x8 : ffff80003a825988
> x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000001
> x5 : 0000000000000000 x4 : 0000000000000001
> x3 : 0000000000000008 x2 : 0000000000000001
> x1 : 6b6b6b6b6b6b6c03 x0 : 0000000000000000
> Process sh (pid: 1784, stack limit = 0x (ptrval))
> Call trace:
> clear_bit+0x18/0x2c
> q6afe_remove+0x20/0x38
> apr_device_remove+0x30/0x70
> device_release_driver_internal+0x170/0x208
> device_release_driver+0x14/0x20
> bus_remove_device+0xcc/0x150
> device_del+0x10c/0x310
> device_unregister+0x1c/0x70
> apr_remove_device+0xc/0x18
> device_for_each_child+0x50/0x80
> apr_remove+0x18/0x20
> rpmsg_dev_remove+0x38/0x68
> device_release_driver_internal+0x170/0x208
> device_release_driver+0x14/0x20
> bus_remove_device+0xcc/0x150
> device_del+0x10c/0x310
> device_unregister+0x1c/0x70
> qcom_smd_remove_device+0xc/0x18
> device_for_each_child+0x50/0x80
> qcom_smd_unregister_edge+0x3c/0x70
> smd_subdev_remove+0x18/0x28
> rproc_stop+0x48/0xd8
> rproc_shutdown+0x60/0xe8
> state_store+0xbc/0xf8
> dev_attr_store+0x18/0x28
> sysfs_kf_write+0x3c/0x50
> kernfs_fop_write+0x118/0x1e0
> __vfs_write+0x18/0x110
> vfs_write+0xa4/0x1a8
> ksys_write+0x48/0xb0
> sys_write+0xc/0x18
> el0_svc_naked+0x30/0x34
> Code: d2800022 8b400c21 f9800031 9ac32043 (c85f7c22)
> ---[ end trace 32020935775616a2 ]---
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
> Changes since v2:
> Move the calls to of_node_clear_flag just before unregister,
> suggested by Rob.
>
> drivers/of/platform.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Applied, thanks.
Rob
^ permalink raw reply
* [PATCHv9 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: Rob Herring @ 2018-06-04 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528094404-3542-2-git-send-email-hean.loong.ong@intel.com>
On Mon, Jun 04, 2018 at 02:40:02PM +0800, Hean-Loong, Ong wrote:
> From: Ong, Hean Loong <hean.loong.ong@intel.com>
>
> Device tree binding for Intel FPGA Video and Image Processing Suite. The binding involved would be generated from the Altera (Intel) Qsys system. The bindings would set the max width, max height, buts per pixel and memory port width. The device tree binding only supports the Intel
> Arria10 devkit and its variants. Vendor name retained as altr.
You need to wrap long lines.
>
> V8:
> *Add port to Display port decoder
>
> V7:
> *Fix OF graph for better description
> *Add description for encoder
>
> V6:
> *Description have not describe DT device in general
>
> V5:
> *remove bindings for bits per symbol as it has only one value which is 8
>
> V4:
> *fix properties that does not describe the values
>
> V3:
> *OF graph not in accordance to graph.txt
>
> V2:
> *Remove Linux driver description
>
> V1:
> *Missing vendor prefix
>
> Signed-off-by: Ong, Hean Loong <hean.loong.ong@intel.com>
> ---
> .../devicetree/bindings/display/altr,vip-fb2.txt | 99 ++++++++++++++++++++
> 1 files changed, 99 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
>
> diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> new file mode 100644
> index 0000000..4092804
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> @@ -0,0 +1,99 @@
> +Intel Video and Image Processing(VIP) Frame Buffer II bindings
> +
> +Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
> +
> +The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
> +that interfaces between system memory and Avalon-ST video ports. The IP core
> +can be configured to support the memory reader (from memory to Avalon-ST)
> +and/or memory writer (from Avalon-ST to memory) interfaces.
> +
> +More information the FPGA video IP component can be acquired from
> +https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
> +/literature/ug/ug_vip.pdf
But URLs you don't need to wrap.
> +
> +DT-Bindings:
> +=============
> +Required properties:
> +----------------------------
> +- compatible: "altr,vip-frame-buffer-2.0"
> +- reg: Physical base address and length of the framebuffer controller's
> + registers.
> +- altr,max-width: The maximum width of the framebuffer in pixels.
> +- altr,max-height: The maximum height of the framebuffer in pixels.
> +- altr,mem-port-width = the bus width of the avalon master port
> + on the frame reader
> +
> +Optional sub-nodes:
> +- ports: The connection to the encoder
> +
> +Optional properties
These are not optional properties because this is a whole other node.
Group things by node (perhaps even make this 2 docments) and within each
node you describe required and optional properties.
> +----------------------------
> +- compatible: "altr, display-port"
spurious space ^
This needs to be more specific. Is there an IP version?
This is a DisplayPort encoder?
> +- reg: Physical base address and length of the display port controller's
> + registers
> +- clocks: required clock handles for specified pairs in clock name
> +- clock-names: required clock names. Contains:
> + - aux_clk: auxiliary clock,
> + - clk: 100 MHz output clock
But 'clocks' are input clocks.
Needs a better name than 'clk'.
> + - xcvr_mgmt_clk: transceiver management clock
'_clk' is redundant.
> +
> +Optional sub-nodes:
> +- ports: The connection to the controller
> +
> +Connections between the Frame Buffer II and other video IP cores in the system
> +are modelled using the OF graph DT bindings. The Frame Buffer II node has up
s/modelled/modeled/
> +to two OF graph ports. When the memory writer interface is enabled, port 0
> +maps to the Avalon-ST Input (din) port. When the memory reader interface is
> +enabled, port 1 maps to the Avalon-ST Output (dout) port.
> +
> +The encoder is built into the FPGA HW design and therefore would not
> +be accessible from the DDR.
> +
> + Port 0 Port1
> +---------------------------------------------------------
> +ARRIA10 AVALON_ST (DIN) AVALON_ST (DOUT)
> +
> +Required Properties Example:
> +----------------------------
> +
> +framebuffer at 100000280 {
> + compatible = "altr,vip-frame-buffer-2.0";
> + reg = <0x00000001 0x00000280 0x00000040>;
> + altr,max-width = <1280>;
> + altr,max-height = <720>;
> + altr,mem-port-width = <128>;
Doesn't this block require some clocks too?
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 1 {
> + reg = <1>;
> + fb_output: endpoint {
> + remote-endpoint = <&dp_encoder_input>;
> + };
> + };
> + };
> +};
> +
> +Optional Properties Example:
> +This is not required unless there are needs to customize
> +Display Port controller settings.
> +
> +displayport at 100002000 {
> + compatible = "altr, display-port";
> + reg = <0x00000001 0x00002000 0x00000800>;
> + clocks = <&dp_0_clk_16 &dp_0_clk_100 &dp_0_clk_100>;
> + clock-names = "aux_clk", "clk", "xcvr_mgmt_clk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <1>;
> + dp_input: endpoint {
> + remote-endpoint = <&dp_controller_input>;
> + };
> + };
> +};
> --
> 1.7.1
>
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Catalin Marinas @ 2018-06-04 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517170523.h7tuvbzdfluuidcz@armageddon.cambridge.arm.com>
On Thu, May 17, 2018 at 06:05:24PM +0100, Catalin Marinas wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> > Jeremy Linton (12):
> > drivers: base: cacheinfo: move cache_setup_of_node()
> > drivers: base: cacheinfo: setup DT cache properties early
> > cacheinfo: rename of_node to fw_token
> > arm64/acpi: Create arch specific cpu to acpi id helper
> > ACPI/PPTT: Add Processor Properties Topology Table parsing
> > ACPI: Enable PPTT support on ARM64
> > drivers: base cacheinfo: Add support for ACPI based firmware tables
> > arm64: Add support for ACPI based firmware tables
> > arm64: topology: rename cluster_id
> > arm64: topology: enable ACPI/PPTT based CPU topology
> > ACPI: Add PPTT to injectable table list
> > arm64: topology: divorce MC scheduling domain from core_siblings
>
> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
> can add it separately).
I'm going to revert patch 12 in this series (arm64: topology: divorce MC
scheduling domain from core_siblings) until the problem is understood
and a fix proposed and tested. It's likely that the PPTT for arm64 will
only be fully enabled in 4.19.
--
Catalin
^ permalink raw reply
* [PATCH v12 3/5] arm64: pgtable: Add p*d_page_vaddr helper macros
From: Will Deacon @ 2018-06-04 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28cc339e-b184-5f15-eca3-cf54e9376e01@codeaurora.org>
On Mon, Jun 04, 2018 at 07:13:48PM +0530, Chintan Pandya wrote:
>
>
> On 6/4/2018 5:43 PM, Will Deacon wrote:
> >On Fri, Jun 01, 2018 at 06:09:16PM +0530, Chintan Pandya wrote:
> >>Add helper macros to give virtual references to page
> >>tables. These will be used while freeing dangling
> >>page tables.
> >>
> >>Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
> >>---
> >> arch/arm64/include/asm/pgtable.h | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >>diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> >>index 7c4c8f3..ef4047f 100644
> >>--- a/arch/arm64/include/asm/pgtable.h
> >>+++ b/arch/arm64/include/asm/pgtable.h
> >>@@ -580,6 +580,9 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
> >> #endif /* CONFIG_PGTABLE_LEVELS > 3 */
> >>+#define pmd_page_vaddr(pmd) __va(pmd_page_paddr(pmd))
> >>+#define pud_page_vaddr(pud) __va(pud_page_paddr(pud))
> >
> >Are these actually needed, or do pte_offset_kernel and pmd_offset do the
> >job already?
> >
>
> I introduced these macros for consistency across different arch.
>
> Looking at pte_offset_kernel, it seems to use READ_ONCE() which looks
> little costly for its intended use (in next patch) where we already have
> dereferenced value. Do you still suggest to remove this ?
It's only an additional load instruction on the freeing path and it matches
what we do in other page table code, so I'd rather use the existing API
unless we have numbers to show otherwise.
Will
^ permalink raw reply
* [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Jernej Škrabec @ 2018-06-04 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604115034.kuy35s4ajewapk4m@flea>
Dne ponedeljek, 04. junij 2018 ob 13:50:34 CEST je Maxime Ripard napisal(a):
> On Fri, Jun 01, 2018 at 09:19:43AM -0700, Chen-Yu Tsai wrote:
> > On Fri, Jun 1, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard@bootlin.com>
wrote:
> > > On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej ?krabec wrote:
> > >> Dne ?etrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
> > >> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > >> > > >> > > + if (tcon->quirks->needs_tcon_top) {
> > >> > > >> > > + struct device_node *np;
> > >> > > >> > > +
> > >> > > >> > > + np = of_parse_phandle(dev->of_node,
> > >> > > >> > > "allwinner,tcon-top",
> > >> > > >> > > 0);
> > >> > > >> > > + if (np) {
> > >> > > >> > > + struct platform_device *pdev;
> > >> > > >> > > +
> > >> > > >> > > + pdev = of_find_device_by_node(np);
> > >> > > >> > > + if (pdev)
> > >> > > >> > > + tcon->tcon_top =
> > >> > > >> > > platform_get_drvdata(pdev);
> > >> > > >> > > + of_node_put(np);
> > >> > > >> > > +
> > >> > > >> > > + if (!tcon->tcon_top)
> > >> > > >> > > + return -EPROBE_DEFER;
> > >> > > >> > > + }
> > >> > > >> > > + }
> > >> > > >> > > +
> > >> > > >> >
> > >> > > >> > I might have missed it, but I've not seen the bindings
> > >> > > >> > additions for
> > >> > > >> > that property. This shouldn't really be done that way anyway,
> > >> > > >> > instead
> > >> > > >> > of using a direct phandle, you should be using the of-graph,
> > >> > > >> > with the
> > >> > > >> > TCON-top sitting where it belongs in the flow of data.
> > >> > > >>
> > >> > > >> Just to answer to the first question, it did describe it in
> > >> > > >> "[PATCH
> > >> > > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
> > >> > > >>
> > >> > > >> As why I designed it that way - HW representation could be
> > >> > > >> described
> > >> > > >> that way> >>
> > >> > > >>
> > >> > > >> (ASCII art makes sense when fixed width font is used to view
it):
> > >> > > >> / LCD0/LVDS0
> > >> > > >>
> > >> > > >> / TCON-LCD0
> > >> > > >>
> > >> > > >> | \ MIPI DSI
> > >> > > >>
> > >> > > >> mixer0 |
> > >> > > >>
> > >> > > >> \ / TCON-LCD1 - LCD1/LVDS1
> > >> > > >>
> > >> > > >> TCON-TOP
> > >> > > >>
> > >> > > >> / \ TCON-TV0 - TVE0/RGB
> > >> > > >>
> > >> > > >> mixer1 | \
> > >> > > >>
> > >> > > >> | TCON-TOP - HDMI
> > >> > > >> |
> > >> > > >> | /
> > >> > > >>
> > >> > > >> \ TCON-TV1 - TVE1/RGB
> > >> > > >>
> > >> > > >> This is a bit simplified, since there is also TVE-TOP, which is
> > >> > > >> responsible
> > >> > > >> for sharing 4 DACs between both TVE encoders. You can have two
> > >> > > >> TV outs
> > >> > > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It
> > >> > > >> even
> > >> > > >> seems that you can arbitrarly choose which DAC is responsible
> > >> > > >> for
> > >> > > >> which signal, so there is a ton of possible end combinations,
> > >> > > >> but I'm
> > >> > > >> not 100% sure.
> > >> > > >>
> > >> > > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40
> > >> > > >> manual
> > >> > > >> suggest more possibilities, although some of them seem wrong,
> > >> > > >> like RGB
> > >> > > >> feeding from LCD TCON. That is confirmed to be wrong when
> > >> > > >> checking BSP
> > >> > > >> code.
> > >> > > >>
> > >> > > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0,
> > >> > > >> TVE1 and
> > >> > > >> LCD1 for pin muxing, although I'm not sure why is that needed at
> > >> > > >> all,
> > >> > > >> since according to R40 datasheet, TVE0 and TVE1 pins are
> > >> > > >> dedicated and
> > >> > > >> not on PORT D and PORT H, respectively, as TCON-TOP
> > >> > > >> documentation
> > >> > > >> suggest. However, HSYNC and PSYNC lines might be shared between
> > >> > > >> TVE
> > >> > > >> (when it works in RGB mode) and LCD. But that is just my guess
> > >> > > >> since
> > >> > > >> I'm not really familiar with RGB and LCD interfaces.
> > >> > > >>
> > >> > > >> I'm really not sure what would be the best representation in
> > >> > > >> OF-graph.
> > >> > > >> Can you suggest one?
> > >> > > >
> > >> > > > Rob might disagree on this one, but I don't see anything wrong
> > >> > > > with
> > >> > > > having loops in the graph. If the TCON-TOP can be both the input
> > >> > > > and
> > >> > > > output of the TCONs, then so be it, and have it described that
> > >> > > > way in
> > >> > > > the graph.
> > >> > > >
> > >> > > > The code is already able to filter out nodes that have already
> > >> > > > been
> > >> > > > added to the list of devices we need to wait for in the component
> > >> > > > framework, so that should work as well.
> > >> > > >
> > >> > > > And we'd need to describe TVE-TOP as well, even though we don't
> > >> > > > have a
> > >> > > > driver for it yet. That will simplify the backward compatibility
> > >> > > > later
> > >> > > > on.
> > >> > >
> > >> > > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer
> > >> > > that
> > >> > > binds everything together, and provides signal routing, kind of
> > >> > > like
> > >> > > DE-TOP on A64. So the signal mux controls that were originally
> > >> > > found
> > >> > > in TCON0 and TVE0 were moved out.
> > >> > >
> > >> > > The driver needs to know about that, but the graph about doesn't
> > >> > > make
> > >> > > much sense directly. Without looking at the manual, I understand it
> > >> > > to
> > >> > > likely be one mux between the mixers and TCONs, and one between the
> > >> > > TCON-TVs and HDMI. Would it make more sense to just have the graph
> > >> > > connections between the muxed components, and remove TCON-TOP from
> > >> > > it, like we had in the past? A phandle could be used to reference
> > >> > > the TCON-TOP for mux controls, in addition to the clocks and
> > >> > > resets.
> > >> > >
> > >> > > For TVE, we would need something to represent each of the output
> > >> > > pins,
> > >> > > so the device tree can actually describe what kind of signal, be it
> > >> > > each component of RGB/YUV or composite video, is wanted on each
> > >> > > pin,
> > >> > > if any. This is also needed on the A20 for the Cubietruck, so we
> > >> > > can
> > >> > > describe which pins are tied to the VGA connector, and which one
> > >> > > does
> > >> > > R, G, or B.
> > >> >
> > >> > I guess we'll see how the DT maintainers feel about this, but my
> > >> > impression is that the OF graph should model the flow of data between
> > >> > the devices. If there's a mux somewhere, then the data is definitely
> > >> > going through it, and as such it should be part of the graph.
> > >>
> > >> I concur, but I spent few days thinking how to represent this sanely in
> > >> graph, but I didn't find any good solution. I'll represent here my
> > >> idea and please tell your opinion before I start implementing it.
> > >>
> > >> First, let me be clear that mixer0 and mixer1 don't have same
> > >> capabilities
> > >> (different number of planes, mixer0 supports writeback, mixer1 does
> > >> not,
> > >> etc.). Thus, it does matter which mixer is connected to which
> > >> TCON/encoder.
> > >> mixer0 is meant to be connected to main display and mixer1 to
> > >> auxiliary. That obviously depends on end system.
> > >>
> > >> So, TCON TOP has 3 muxes, which have to be represented in graph. Two of
> > >> them are for mixer/TCON relationship (each of them 1 input and 4
> > >> possible outputs) and one for TV TCON/HDMI pair selection (2 possible
> > >> inputs, 1 output).
> > >>
> > >> According to current practice in sun4i-drm driver, graph has to have
> > >> port 0, representing input and port 1, representing output. This would
> > >> mean that graph looks something like that:
> > >>
> > >> tcon_top: tcon-top at 1c70000 {
> > >>
> > >> compatible = "allwinner,sun8i-r40-tcon-top";
> > >> ...
> > >> ports {
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >>
> > >> tcon_top_in: port at 0 {
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >> reg = <0>;
> > >>
> > >> tcon_top_in_mixer0: endpoint at 0 {
> > >>
> > >> reg = <0>;
> > >> remote-endpoint = <&mixer0_out_tcon_top>;
> > >>
> > >> };
> > >>
> > >> tcon_top_in_mixer1: endpoint at 1 {
> > >>
> > >> reg = <1>;
> > >> remote-endpoint = <&mixer1_out_tcon_top>;
> > >>
> > >> };
> > >>
> > >> tcon_top_in_tcon_tv: endpoint at 2 {
> > >>
> > >> reg = <2>;
> > >> // here is HDMI input connection, part of
> > >> board DTS
> > >> remote-endpoint = <board specific phandle
> > >> to TV TCON output>;
> > >>
> > >> };
> > >>
> > >> };
> > >>
> > >> tcon_top_out: port at 1 {
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >> reg = <1>;
> > >>
> > >> tcon_top_out_tcon0: endpoint at 0 {
> > >>
> > >> reg = <0>;
> > >> // here is mixer0 output connection, part
> > >> of board DTS
> > >> remote-endpoint = <board specific phandle
> > >> to TCON>;
> > >>
> > >> };
> > >>
> > >> tcon_top_out_tcon1: endpoint at 1 {
> > >>
> > >> reg = <1>;
> > >> // here is mixer1 output connection, part
> > >> of board DTS
> > >> remote-endpoint = <board specific phandle
> > >> to TCON>;
> > >>
> > >> };
> > >>
> > >> tcon_top_out_hdmi: endpoint at 2 {
> > >>
> > >> reg = <2>;
> > >> remote-endpoint = <&hdmi_in_tcon_top>;
> > >>
> > >> };
> > >>
> > >> };
> > >>
> > >> };
> > >>
> > >> };
> > >
> > > IIRC, each port is supposed to be one route for the data, so we would
> > > have multiple ports, one for the mixers in input and for the tcon in
> > > output, and one for the TCON in input and for the HDMI/TV in
> > > output. Rob might correct me here.
Ok, that seems more clean approach. I'll have to extend graph traversing
algorithm in sun4i_drv.c, but that's no problem.
Just to be clear, you have in mind 3 pairs of ports (0/1 for mixer0 mux, 2/3
for mixer1 and 4/5 for HDMI input), right? That way each mux is represented
with one pair of ports, even numbered for input and odd numbered for output.
> > >
> > >> tcon_tv0: lcd-controller at 1c73000 {
> > >>
> > >> compatible = "allwinner,sun8i-r40-tcon-tv-0";
> > >> ...
> > >> ports {
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >>
> > >> tcon_tv0_in: port at 0 {
> > >>
> > >> reg = <0>;
> > >>
> > >> tcon_tv0_in_tcon_top: endpoint {
> > >>
> > >> // endpoint depends on board, part of
> > >> board DTS
> > >> remote-endpoint = <phandle to one of
> > >> tcon_top_out_tcon>;
> > >
> > > Just curious, what would be there?
Either phandle to tcon_top_out_tcon0 or tcon_top_out_tcon1.
> > >
> > >> };
> > >>
> > >> };
> > >>
> > >> tcon_tv0_out: port at 1 {
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >> reg = <1>;
> > >>
> > >> // endpoints to TV TOP and TCON TOP HDMI input
> > >> ...
> > >>
> > >> };
> > >>
> > >> };
> > >>
> > >> };
> > >>
> > >> tcon_tv1: lcd-controller at 1c74000 {
> > >>
> > >> compatible = "allwinner,sun8i-r40-tcon-tv-1";
> > >> ...
> > >> ports {
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >>
> > >> tcon_tv1_in: port at 0 {
> > >>
> > >> reg = <0>;
> > >>
> > >> tcon_tv1_in_tcon_top: endpoint {
> > >>
> > >> // endpoint depends on board, part of
> > >> board DTS
> > >> remote-endpoint = <phandle to one of
> > >> tcon_top_out_tcon>;
> > >>
> > >> };
> > >>
> > >> };
> > >>
> > >> tcon_tv1_out: port at 1 {
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <0>;
> > >> reg = <1>;
> > >>
> > >> // endpoints to TV TOP and TCON TOP HDMI input
> > >> ...
> > >>
> > >> };
> > >>
> > >> };
> > >>
> > >> };
> > >>
> > >> tcon_lcd0 and tcon_lcd1 would have similar connections, except that for
> > >> outputs would be LCD or LVDS panels or MIPI DSI encoder.
> > >>
> > >> Please note that each TCON (there are 4 of them) would need to have
> > >> unique
> > >> compatible and have HW index stored in quirks data. It would be used by
> > >> TCON TOP driver for configuring muxes.
> > >
> > > Can't we use the port/endpoint ID instead? If the mux is the only
> > > thing that changes, the compatible has no reason to. It's the same IP,
> > > and the only thing that changes is something that is not part of that
> > > IP.
> >
> > I agree. Endpoint IDs should provide that information. I'm still not
> > sure How to encode multiple in/out mux groups in a device node though.
>
> I guess we can do that through different ports?
Ok, I'll try to do something with "reg" property.
Best regards,
Jernej
^ permalink raw reply
* [PATCH v12 4/5] arm64: Implement page table free interfaces
From: Will Deacon @ 2018-06-04 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <98ef3cd0-a9a1-d5b5-f1a6-c0ab8b15ec6a@codeaurora.org>
On Mon, Jun 04, 2018 at 07:13:18PM +0530, Chintan Pandya wrote:
> On 6/4/2018 5:43 PM, Will Deacon wrote:
> >On Fri, Jun 01, 2018 at 06:09:17PM +0530, Chintan Pandya wrote:
> >>+ next = addr;
> >>+ end = addr + PUD_SIZE;
> >>+ do {
> >>+ pmd_free_pte_page(entry, next);
> >>+ } while (entry++, next += PMD_SIZE, next != end);
> >>+
> >>+ pud_clear(pudp);
> >>+ __flush_tlb_kernel_pgtable(addr);
> >>+ pmd_free(NULL, table);
> >>+ }
> >>+ return 1;
> >
> >So with these patches, we only ever return 1 from these helpers. It looks
> >like the same is true for x86, so how about we make them void and move the
> >calls inside the conditionals in lib/ioremap.c? Obviously, this would be a
> >separate patch on the end.
>
> That sounds valid code churn to me. But since x86 discussion is not
> concluded yet, I would wait to share until that gets resolved. May be
> not in v13 but separate effort. Would that be okay to you ?
Yes, fine by me.
Will
^ permalink raw reply
* [PATCH 1/5] arm64: topology: refactor reset_cpu_topology to add support for removing topology
From: Jeffrey Hugo @ 2018-06-04 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528108797-13743-2-git-send-email-sudeep.holla@arm.com>
On 6/4/2018 4:39 AM, Sudeep Holla wrote:
> Currently reset_cpu_topology clears all the CPU topology information
> and resets to default values. However we may need to just clear the
> information when we hotplig out the CPU. In preparation to add the
hotplug
> support the same, let's refactor reset_cpu_topology to clear out the
> information and reset them only if explicitly requested.
>
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v5 4/4] ARM: dts: imx: add missing compatible and clock properties for EPIT
From: kbuild test robot @ 2018-06-04 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604100035.19558-5-peron.clem@gmail.com>
Hi Colin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on v4.17 next-20180601]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Cl-ment-P-ron/Reintroduce-i-MX-EPIT-Timer/20180604-211036
base: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next
config: arm-realview_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/imx6sl.dtsi:661.19-20 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 18007 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180604/87639177/attachment-0001.gz>
^ 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