* [RFC PATCH 5/8] dt-bindings: mailbox: ti,message-manager: Add support for secure proxy threads
From: Nishanth Menon @ 2018-06-12 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612211128.GA22038@rob-hp-laptop>
On 21:11-20180612, Rob Herring wrote:
[...]
> > diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > index ebf0e3710cee..de796e90cac6 100644
> > --- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> > @@ -7,22 +7,40 @@ manager is broken up into queues in different address regions that are called
> > "proxies" - each instance is unidirectional and is instantiated at SoC
> > integration level to indicate receive or transmit path.
> >
> > +This can also be used to describe Texas Instrument's Secure Proxy
> > +controller that allows for individually configurable "threads" or
> > +"proxies" which allow for independent communication scheme.
>
> There seems to be very little re-use here. I think I would make this
> its own doc.
Agreed. will do the same in the formal series. Thanks.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [RFC PATCH 1/3] Documentation: dt: keystone: ti-sci: Add optional host-id parameter
From: Nishanth Menon @ 2018-06-12 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612213922.GA26791@rob-hp-laptop>
On 21:39-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:
> > Texas Instrument's System Control Interface (TISCI) permits the
> > ability for Operating Systems to running in virtual machines to be
>
> ...for OSs running in virtual...
Ack. thanks.
>
> > able to independently communicate with the firmware without the need
> > going through an hypervisor.
> >
> > The "host-id" in effect is the hardware representation of the
> > host (example: VMs locked to a core) as identified to the System
> > Controller.
>
> So the hypervisor will fill in host-id's for each VM instance?
Yes OR have it's own device tree blobs representation of it's own host
IDs assigned by system firmware. This provides complete independence of
VMs to communicate with the system controller (once the host-id is
provided) without switching to hyp for arbitration (and yes, verified
ability with jailhouse hypervisor and multiple linux instances operating
simultaneously). This also has the added benefit of:
1. The burden of hypervisor from being involved in PM functionality as each
of the VMs can operate autonomously.
2. In TI SoCs which are heterogeneous, the system firmware plays the role
of system master communicating with multiple firmware(running on various
uCs) and OSes running on bigger cores.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/2] ASoC: pxa: add binding for pxa2xx-ac97 audio complex
From: Rob Herring @ 2018-06-12 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611202211.15501-1-robert.jarzmik@free.fr>
On Mon, Jun 11, 2018 at 10:22:10PM +0200, Robert Jarzmik wrote:
> This adds a binding for the Marvell PXA audio complex, available in
> pxa2xx and pxa3xx variants.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> .../bindings/sound/marvell,pxa2xx-ac97.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
> new file mode 100644
> index 000000000000..b3f2882d9c7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
> @@ -0,0 +1,25 @@
> +Marvell PXA2xx audio complex
> +
> +This descriptions matches the AC97 controller found in pxa2xx and pxa3xx series.
> +
> +Required properties:
> + - compatible: "marvell,pxa2xx-ac97"
Don't use wildcards in compatible strings. Though this is so old...
> + - reg: device MMIO address space
> + - interrupts: single interrupt generated by AC97 IP
> + - clocks: input clock of the AC97 IP, refer to clock-bindings.txt
> +
> +Optional properties:
> + - pinctrl-names, pinctrl-0: refer to pinctrl-bindings.txt
> + - reset-gpio: gpio used for AC97 reset, refer to gpio.txt
reset-gpios
> +
> +Example:
> + ac97: sound at 40500000 {
> + compatible = "marvell,pxa2xx-ac97";
> + reg = < 0x40500000 0x1000 >;
> + interrupts = <14>;
> + reset-gpio = <&gpio 113 GPIO_ACTIVE_HIGH>;
> + #sound-dai-cells = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = < &pmux_ac97_default >;
> + status = "okay";
Don't show status in examples.
> + };
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 04/10] Input: ams_delta_serio: Replace power GPIO with regulator
From: Dmitry Torokhov @ 2018-06-12 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609140224.32606-4-jmkrzyszt@gmail.com>
On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> Modify the driver so it no longer requests and manipulates the
> "keybrd_pwr" GPIO pin but a "vcc" regulator supply instead.
>
> For this to work with Amstrad Delta, define a regulator over the
> "keybrd_pwr" GPIO pin with the "vcc" supply for ams-delta-serio device
> and register it from the board file. Both assign an absulute GPIO
> number to the soon depreciated .gpio member of the regulator config
> structure, and also build and register a GPIO lookup table so it is
> ready for use by the regulator driver as soon as its upcoming update
> is applied.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> ---
> arch/arm/mach-omap1/board-ams-delta.c | 63 +++++++++++++++++++++++++++++++++--
> drivers/input/serio/ams_delta_serio.c | 27 ++++++++++-----
> 2 files changed, 79 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 2119d2d3ba84..706eb2f9301d 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -509,6 +509,46 @@ static struct platform_device ams_delta_serio_device = {
> .id = PLATFORM_DEVID_NONE,
> };
>
> +static struct regulator_consumer_supply keybrd_pwr_consumers[] = {
> + /*
> + * Initialize supply .dev_name with NULL. It will be replaced
> + * with serio dev_name() as soon as the serio device is registered.
> + */
> + REGULATOR_SUPPLY("vcc", NULL),
> +};
> +
> +static struct regulator_init_data keybrd_pwr_initdata = {
> + .constraints = {
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(keybrd_pwr_consumers),
> + .consumer_supplies = keybrd_pwr_consumers,
> +};
> +
> +static struct fixed_voltage_config keybrd_pwr_config = {
> + .supply_name = "keybrd_pwr",
> + .microvolts = 5000000,
> + .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
> + .enable_high = 1,
> + .init_data = &keybrd_pwr_initdata,
> +};
> +
> +static struct platform_device keybrd_pwr_device = {
> + .name = "reg-fixed-voltage",
> + .id = PLATFORM_DEVID_AUTO,
> + .dev = {
> + .platform_data = &keybrd_pwr_config,
> + },
> +};
> +
> +static struct gpiod_lookup_table keybrd_pwr_gpio_table = {
> + .table = {
> + GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_KEYBRD_PWR, NULL,
> + GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static struct platform_device *ams_delta_devices[] __initdata = {
> &latch1_gpio_device,
> &latch2_gpio_device,
> @@ -526,6 +566,7 @@ static struct platform_device *late_devices[] __initdata = {
>
> static struct gpiod_lookup_table *ams_delta_gpio_tables[] __initdata = {
> &ams_delta_audio_gpio_table,
> + &keybrd_pwr_gpio_table,
> };
>
> static struct gpiod_lookup_table *late_gpio_tables[] __initdata = {
> @@ -566,12 +607,30 @@ static void __init ams_delta_init(void)
> platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
>
> /*
> - * As soon as devices have been registered, assign their dev_names
> - * to respective GPIO lookup tables before they are added.
> + * As soon as regulator consumers have been registered, assign their
> + * dev_names to consumer supply entries of respective regulators.
> + */
> + keybrd_pwr_consumers[0].dev_name =
> + dev_name(&ams_delta_serio_device.dev);
> +
> + /*
> + * Once consumer supply entries are populated with dev_names,
> + * register regulator devices. At this stage only the keyboard
> + * power regulator has its consumer supply table fully populated.
> + */
> + platform_device_register(&keybrd_pwr_device);
> +
> + /*
> + * As soon as GPIO consumers have been registered, assign
> + * their dev_names to respective GPIO lookup tables.
> */
> ams_delta_audio_gpio_table.dev_id =
> dev_name(&ams_delta_audio_device.dev);
> + keybrd_pwr_gpio_table.dev_id = dev_name(&keybrd_pwr_device.dev);
>
> + /*
> + * Once GPIO lookup tables are populated with dev_names, register them.
> + */
> gpiod_add_lookup_tables(ams_delta_gpio_tables,
> ARRAY_SIZE(ams_delta_gpio_tables));
>
> diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
> index 551a4fa73fe4..d48beab1d00d 100644
> --- a/drivers/input/serio/ams_delta_serio.c
> +++ b/drivers/input/serio/ams_delta_serio.c
> @@ -23,6 +23,7 @@
> #include <linux/gpio.h>
> #include <linux/irq.h>
> #include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> #include <linux/serio.h>
> #include <linux/slab.h>
> #include <linux/module.h>
> @@ -39,6 +40,7 @@ MODULE_LICENSE("GPL");
>
> struct ams_delta_serio {
> struct serio *serio;
> + struct regulator *vcc;
> };
>
> static int check_data(struct serio *serio, int data)
> @@ -94,16 +96,18 @@ static irqreturn_t ams_delta_serio_interrupt(int irq, void *dev_id)
>
> static int ams_delta_serio_open(struct serio *serio)
> {
> - /* enable keyboard */
> - gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 1);
> + struct ams_delta_serio *priv = serio->port_data;
>
> - return 0;
> + /* enable keyboard */
> + return regulator_enable(priv->vcc);
> }
>
> static void ams_delta_serio_close(struct serio *serio)
> {
> + struct ams_delta_serio *priv = serio->port_data;
> +
> /* disable keyboard */
> - gpio_set_value(AMS_DELTA_GPIO_PIN_KEYBRD_PWR, 0);
> + regulator_disable(priv->vcc);
> }
>
> static const struct gpio ams_delta_gpios[] __initconst_or_module = {
> @@ -117,11 +121,6 @@ static const struct gpio ams_delta_gpios[] __initconst_or_module = {
> .flags = GPIOF_DIR_IN,
> .label = "serio-clock",
> },
> - {
> - .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_PWR,
> - .flags = GPIOF_OUT_INIT_LOW,
> - .label = "serio-power",
> - },
> {
> .gpio = AMS_DELTA_GPIO_PIN_KEYBRD_DATAOUT,
> .flags = GPIOF_OUT_INIT_LOW,
> @@ -146,6 +145,16 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> goto serio;
> }
>
> + priv->vcc = devm_regulator_get(&pdev->dev, "vcc");
> + if (IS_ERR(priv->vcc)) {
> + err = PTR_ERR(priv->vcc);
> + dev_err(&pdev->dev, "regulator request failed (%d)\n", err);
> + /* Fail softly if the regulator is not available yet */
> + if (err == -ENODEV)
> + err = -EPROBE_DEFER;
Hmm, if regulator is not ready yet, devm_regulator_get() should be
returning -EPROBE_DEFER already, we should not have to convert -ENODEV
to -EPROBE_DEFER...
Is it because we have_full_constraints() returns false? You might need
to add call to regulator_has_full_constraints() to your board file.
> + goto gpio;
> + }
> +
> err = request_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> ams_delta_serio_interrupt, IRQ_TYPE_EDGE_RISING,
> DRIVER_NAME, priv);
> --
> 2.16.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 09/10] Input: ams_delta_serio: use IRQ resource
From: Dmitry Torokhov @ 2018-06-12 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609140224.32606-9-jmkrzyszt@gmail.com>
On Sat, Jun 09, 2018 at 04:02:23PM +0200, Janusz Krzysztofik wrote:
> The driver still obtains IRQ number from a hardcoded GPIO. Use IRQ
> resource instead.
>
> For this to work on Amstrad Delta, add the IRQ resource to
> ams-delta-serio platform device structure. Obtain the IRQ number
> assigned to "keyboard_clk" GPIO pin from FIQ initialization routine.
>
> As a benefit, the driver no longer needs to include
> <mach/board-ams-delta.h>.
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> ---
> arch/arm/mach-omap1/ams-delta-fiq.c | 8 +++++++-
> arch/arm/mach-omap1/ams-delta-fiq.h | 3 ++-
> arch/arm/mach-omap1/board-ams-delta.c | 17 ++++++++++++++++-
> drivers/input/serio/ams_delta_serio.c | 28 ++++++++++------------------
> 4 files changed, 35 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/ams-delta-fiq.c b/arch/arm/mach-omap1/ams-delta-fiq.c
> index e72935034d42..e9d350117240 100644
> --- a/arch/arm/mach-omap1/ams-delta-fiq.c
> +++ b/arch/arm/mach-omap1/ams-delta-fiq.c
> @@ -20,6 +20,7 @@
> #include <linux/module.h>
> #include <linux/io.h>
> #include <linux/platform_data/ams-delta-fiq.h>
> +#include <linux/platform_device.h>
>
> #include <mach/board-ams-delta.h>
>
> @@ -84,7 +85,8 @@ static irqreturn_t deferred_fiq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> -void __init ams_delta_init_fiq(struct gpio_chip *chip)
> +void __init ams_delta_init_fiq(struct gpio_chip *chip,
> + struct platform_device *serio)
> {
> struct gpio_desc *gpiod, *data = NULL, *clk = NULL;
> void *fiqhandler_start;
> @@ -201,6 +203,10 @@ void __init ams_delta_init_fiq(struct gpio_chip *chip)
> val = omap_readl(OMAP_IH1_BASE + offset) | 1;
> omap_writel(val, OMAP_IH1_BASE + offset);
>
> + /* Initialize serio device IRQ resource */
> + serio->resource[0].start = gpiod_to_irq(clk);
> + serio->resource[0].end = serio->resource[0].start;
> +
> return;
>
> out_gpio:
> diff --git a/arch/arm/mach-omap1/ams-delta-fiq.h b/arch/arm/mach-omap1/ams-delta-fiq.h
> index 3f691d68aa62..fd76df3cce37 100644
> --- a/arch/arm/mach-omap1/ams-delta-fiq.h
> +++ b/arch/arm/mach-omap1/ams-delta-fiq.h
> @@ -35,7 +35,8 @@
> #ifndef __ASSEMBLER__
> extern unsigned char qwerty_fiqin_start, qwerty_fiqin_end;
>
> -extern void __init ams_delta_init_fiq(struct gpio_chip *chip);
> +extern void __init ams_delta_init_fiq(struct gpio_chip *chip,
> + struct platform_device *pdev);
> #endif
>
> #endif
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index fe9a3e7cbfeb..84177ba3e39a 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -504,9 +504,24 @@ static struct platform_device cx20442_codec_device = {
> .id = -1,
> };
>
> +static struct resource ams_delta_serio_resources[] = {
> + {
> + .flags = IORESOURCE_IRQ,
> + /*
> + * Initialize IRQ resource with invalid IRQ number.
> + * It will be replaced with dynamically allocated GPIO IRQ
> + * obtained from GPIO chip as soon as the chip is available.
> + */
> + .start = -EINVAL,
> + .end = -EINVAL,
> + },
> +};
> +
> static struct platform_device ams_delta_serio_device = {
> .name = "ams-delta-serio",
> .id = PLATFORM_DEVID_NONE,
> + .num_resources = ARRAY_SIZE(ams_delta_serio_resources),
> + .resource = ams_delta_serio_resources,
> };
>
> static struct regulator_consumer_supply keybrd_pwr_consumers[] = {
> @@ -615,7 +630,7 @@ static void __init omap_gpio_deps_init(void)
> return;
> }
>
> - ams_delta_init_fiq(chip);
> + ams_delta_init_fiq(chip, &ams_delta_serio_device);
> }
>
> static void __init ams_delta_init(void)
> diff --git a/drivers/input/serio/ams_delta_serio.c b/drivers/input/serio/ams_delta_serio.c
> index 5d0bd2005648..03640b171516 100644
> --- a/drivers/input/serio/ams_delta_serio.c
> +++ b/drivers/input/serio/ams_delta_serio.c
> @@ -20,7 +20,6 @@
> * However, when used with the E3 mailboard that producecs non-standard
> * scancodes, a custom key table must be prepared and loaded from userspace.
> */
> -#include <linux/gpio.h>
> #include <linux/irq.h>
> #include <linux/platform_data/ams-delta-fiq.h>
> #include <linux/platform_device.h>
> @@ -29,8 +28,6 @@
> #include <linux/slab.h>
> #include <linux/module.h>
>
> -#include <mach/board-ams-delta.h>
> -
> #define DRIVER_NAME "ams-delta-serio"
>
> MODULE_AUTHOR("Matt Callow");
> @@ -113,7 +110,7 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> {
> struct ams_delta_serio *priv;
> struct serio *serio;
> - int err;
> + int irq, err;
>
> priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> @@ -129,9 +126,12 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> return err;
> }
>
> - err = request_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> - ams_delta_serio_interrupt, IRQ_TYPE_EDGE_RISING,
> - DRIVER_NAME, priv);
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return -ENXIO;
> +
> + err = devm_request_irq(&pdev->dev, irq, ams_delta_serio_interrupt,
> + IRQ_TYPE_EDGE_RISING, DRIVER_NAME, priv);
> if (err < 0) {
> dev_err(&pdev->dev, "IRQ request failed (%d)\n", err);
> return err;
> @@ -141,14 +141,11 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> * at FIQ level, switch back from edge to simple interrupt handler
> * to avoid bad interaction.
> */
> - irq_set_handler(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> - handle_simple_irq);
> + irq_set_handler(irq, handle_simple_irq);
Do we still need to do this here, or it can be moved into board file?
>
> serio = kzalloc(sizeof(*serio), GFP_KERNEL);
> - if (!serio) {
> - err = -ENOMEM;
> - goto irq;
> - }
> + if (!serio)
> + return -ENOMEM;
>
> priv->serio = serio;
>
> @@ -167,10 +164,6 @@ static int ams_delta_serio_init(struct platform_device *pdev)
> dev_info(&serio->dev, "%s\n", serio->name);
>
> return 0;
> -
> -irq:
> - free_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), priv);
> - return err;
> }
>
> static int ams_delta_serio_exit(struct platform_device *pdev)
> @@ -178,7 +171,6 @@ static int ams_delta_serio_exit(struct platform_device *pdev)
> struct ams_delta_serio *priv = platform_get_drvdata(pdev);
>
> serio_unregister_port(priv->serio);
> - free_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), 0);
>
> return 0;
> }
> --
> 2.16.1
>
--
Dmitry
^ permalink raw reply
* [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Dmitry Torokhov @ 2018-06-12 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609140224.32606-1-jmkrzyszt@gmail.com>
Hi Janusz,
On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> GPIO lookup table for ams-delta-serio device was introduced by commit
> 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> lookup table" was not accepted by subystem maintainer who requested
> conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> pin with IRQ resource, replacement of GPIO pin providing keyboard power
> with a regulator and removal of remaining GPIO pins from the driver as
> not handled by it.
>
> Let's start with removal of no the longer needed GPIO lookup table from
> the board init file.
>
> Series created and tested on top of next-20180608 tag from linux-next
> tree.
This all is really nice (modulo a couple of questions), thank you for
implementing this. How do you want to merge this? Through OMAP tree or
input?
>
> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
> ---
> arch/arm/mach-omap1/board-ams-delta.c | 19 -------------------
> 1 file changed, 19 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
> index 80f54cb54276..18e0ff437b27 100644
> --- a/arch/arm/mach-omap1/board-ams-delta.c
> +++ b/arch/arm/mach-omap1/board-ams-delta.c
> @@ -504,20 +504,6 @@ static struct platform_device cx20442_codec_device = {
> .id = -1,
> };
>
> -static struct gpiod_lookup_table ams_delta_serio_gpio_table = {
> - .table = {
> - GPIO_LOOKUP(OMAP_GPIO_LABEL, AMS_DELTA_GPIO_PIN_KEYBRD_DATA,
> - "data", 0),
> - GPIO_LOOKUP(OMAP_GPIO_LABEL, AMS_DELTA_GPIO_PIN_KEYBRD_CLK,
> - "clock", 0),
> - GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_KEYBRD_PWR,
> - "power", 0),
> - GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_KEYBRD_DATAOUT,
> - "dataout", 0),
> - { },
> - },
> -};
> -
> static struct platform_device *ams_delta_devices[] __initdata = {
> &latch1_gpio_device,
> &latch2_gpio_device,
> @@ -534,7 +520,6 @@ static struct platform_device *late_devices[] __initdata = {
>
> static struct gpiod_lookup_table *ams_delta_gpio_tables[] __initdata = {
> &ams_delta_audio_gpio_table,
> - &ams_delta_serio_gpio_table,
> };
>
> static struct gpiod_lookup_table *late_gpio_tables[] __initdata = {
> @@ -580,10 +565,6 @@ static void __init ams_delta_init(void)
> */
> ams_delta_audio_gpio_table.dev_id =
> dev_name(&ams_delta_audio_device.dev);
> - /*
> - * No device name is assigned to GPIO lookup table for serio device
> - * as long as serio driver is not converted to platform device driver.
> - */
>
> gpiod_add_lookup_tables(ams_delta_gpio_tables,
> ARRAY_SIZE(ams_delta_gpio_tables));
> --
> 2.16.1
>
--
Dmitry
^ permalink raw reply
* [PATCH] net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode
From: David Miller @ 2018-06-12 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <036618ae-887f-44b5-2b39-451b81191cc1@redhat.com>
From: Dean Nelson <dnelson@redhat.com>
Date: Mon, 11 Jun 2018 06:22:14 -0500
> On 06/10/2018 02:35 PM, David Miller wrote:
>> From: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
>> Date: Fri, 8 Jun 2018 02:27:59 -0700
>>
>>> + /* Save message data locally to prevent them from
>>> + * being overwritten by next ndo_set_rx_mode call().
>>> + */
>>> + spin_lock(&nic->rx_mode_wq_lock);
>>> + mode = vf_work->mode;
>>> + mc = vf_work->mc;
>>> + vf_work->mc = NULL;
>
> If I'm reading this code correctly, I believe nic->rx_mode_work.mc
> will
> have been set to NULL before the lock is dropped by
> nicvf_set_rx_mode_task() and acquired by nicvf_set_rx_mode().
>
>
>>> + spin_unlock(&nic->rx_mode_wq_lock);
>> At the moment you drop this lock, the memory behind 'mc' can be
>> freed up by:
>>
>>> + spin_lock(&nic->rx_mode_wq_lock);
>>> + kfree(nic->rx_mode_work.mc);
>
> So the kfree() will be called with a NULL pointer and quickly return.
>
>
>> And you'll crash when you dereference it above via
>> __nicvf_set_rx_mode_task().
>>
>
> I believe the call to kfree() in nicvf_set_rx_mode() is there to free
> up a mc_list that has been allocated by nicvf_set_rx_mode() during a
> previous callback to the function, one that has not yet been processed
> by nicvf_set_rx_mode_task().
>
> In this way only the last 'unprocessed' callback to
> nicvf_set_rx_mode()
> gets processed should there be multiple callbacks occurring between
> the
> times the nicvf_set_rx_mode_task() runs.
>
> In my testing with this patch, this is what I see happening.
You're right, my bad.
Patch applied.
^ permalink raw reply
* [PATCH] net: stmmac: dwmac-meson8b: Fix an error handling path in 'meson8b_dwmac_probe()'
From: David Miller @ 2018-06-12 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611175227.27509-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Mon, 11 Jun 2018 19:52:27 +0200
> If 'of_device_get_match_data()' fails, we need to release some resources as
> done in the other error handling path of this function.
>
> Fixes: efacb568c962 ("net: stmmac: dwmac-meson: extend phy mode setting")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied.
^ permalink raw reply
* [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports
From: Rob Herring @ 2018-06-12 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <395f1fe8-76f1-8310-d09e-63e25bca23d2@broadcom.com>
On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
<scott.branden@broadcom.com> wrote:
> Hi Rob,
>
> Could you please kindly comment on change below.
>
> It allows board variants to be added easily via a simple define for
> different number of SATA ports.
>
>
>
> On 18-06-04 09:22 AM, Florian Fainelli wrote:
>>
>> On 05/18/2018 11:34 AM, Scott Branden wrote:
>>>
>>> Move remaining sata configuration to stingray-sata.dtsi and enable
>>> ports based on NUM_SATA defined.
>>> Now, all that needs to be done is define NUM_SATA per board.
>>
>> Rob could you review this and let us know if this approach is okay or
>> not? Thank you!
>>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>> ---
>>> diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> index 8c68e0c..7f6d176 100644
>>> --- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> +++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
>>> @@ -43,7 +43,11 @@
>>> interrupts = <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>;
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> +#if (NUM_SATA > 0)
>>> + status = "okay";
>>> +#else
>>> status = "disabled";
>>> +#endif
This only works if ports are contiguously enabled (0-N). You might not
care, but it is not a pattern that works in general. And I'm not a fan
of C preprocessing in DT files in general beyond just defines for
single numbers.
Rob
^ permalink raw reply
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Marek Vasut @ 2018-06-12 23:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-3-nm@ti.com>
On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
> needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
> be done unconditionally for Cortex-A15 processors. Provide a config
> option for platforms to enable this option based on impact analysis
> for products.
>
> NOTE: This patch in itself is NOT the final solution, this requires:
> a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
> provide direct access to ACR register.
> b) Operating Systems such as Linux to provide adequate workaround in the
> right locations.
> c) This workaround applies to only the boot processor. It is important
> to apply workaround as necessary (context-save-restore) around low
> power context loss OR additional processors as necessary in either
> firmware support OR elsewhere in OS.
>
> [1] https://developer.arm.com/support/security-update
> [2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Andre Przywara <Andre.Przywara@arm.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/Kconfig | 4 ++++
> arch/arm/cpu/armv7/start.S | 8 ++++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9e32d5b43cb0..98f58fd27696 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -109,6 +109,7 @@ config SYS_ARM_MPU
> # CONFIG_ARM_ERRATA_798870
> # CONFIG_ARM_ERRATA_801819
> # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
> +# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>
> config ARM_ERRATA_430973
> bool
> @@ -182,6 +183,9 @@ config ARM_ERRATA_855873
> config ARM_CORTEX_A8_CVE_2017_5715
> bool
>
> +config ARM_CORTEX_A15_CVE_2017_5715
> + bool
> +
> config CPU_ARM720T
> bool
> select SYS_CACHE_SHIFT_5
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index 3beaf5a93d81..81edec01bf32 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -241,6 +241,14 @@ skip_errata_798870:
> skip_errata_801819:
> #endif
>
> +#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
> + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
> + orr r0, r0, #1 << 0 @ Enable invalidates of BTB
Can we use BIT() macro in the assembler code too ?
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 3/4] ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of BTB) to facilitate CVE_2017-5715 WA in OS
From: Marek Vasut @ 2018-06-12 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-4-nm@ti.com>
On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> Enable CVE_2017_5715 and since we have our own v7_arch_cp15_set_acr
> function to setup the bits, we are able to override the settings.
>
> Without this enabled, Linux kernel reports:
> CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
>
> With this enabled, Linux kernel reports:
> CPU0: Spectre v2: using ICIALLU workaround
>
> NOTE: This by itself does not enable the workaround for CPU1 (on
> OMAP5 and DRA72/AM572 SoCs) and may require additional kernel patches.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/mach-omap2/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 3bb1ecb58de0..77820cc8d1e4 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -53,6 +53,7 @@ config OMAP54XX
> bool "OMAP54XX SoC"
> select ARM_ERRATA_798870
> select SYS_THUMB_BUILD
> + select ARM_CORTEX_A15_CVE_2017_5715
> imply NAND_OMAP_ELM
> imply NAND_OMAP_GPMC
> imply SPL_DISPLAY_PRINT
>
Can this be enabled for all CA15 systems somehow ? I am sure there are
more that are vulnerable.
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 0/4] ARM: Provide workaround setup bits for CVE-2017-5715 (A8/A15)
From: Marek Vasut @ 2018-06-12 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-1-nm@ti.com>
On 06/12/2018 10:24 PM, Nishanth Menon wrote:
> Hi,
>
> This is a follow on from https://marc.info/?l=u-boot&m=151691688828176&w=2 (RFC)
>
> NOTE:
> * As per ARM recommendations[2], and discussions in list[1] ARM
> Cortex-A9/12/17 do not need additional steps in u-boot to enable the
> OS level workarounds.
> * This itself is'nt a complete solution and is based on recommendation
> This from Arm[2] for variant 2 CVE-2017-5715 -> Kernel changes can be seen on
> linux next (next-20180612) or on linux master (upcoming v4.18-rc1 tag).
> * I think it is necessary on older SoCs without firmware support
> (such as older OMAPs and AM*) to have kernel support mirroring what we do in
> u-boot to support additional cores AND/OR low power states where contexts are
> lost (assuming ACR states are'nt saved). just my 2 cents.
>
> Few of the tests (with linux next-20180612):
> AM571-IDK: https://pastebin.ubuntu.com/p/sr5X6sN3Tr/ (single core A15)
> OMAP5-uEVM: https://pastebin.ubuntu.com/p/9yDM22bJ6n/ (dual core A15)
> OMAP3-beagle-xm: https://pastebin.ubuntu.com/p/9DfDkpyxym/ (Single A8)
> AM335x-Beaglebone-black: https://pastebin.ubuntu.com/p/DczT9jPMwb/ (Single A8)
>
> Nishanth Menon (4):
> ARM: Introduce ability to enable ACR::IBE on Cortex-A8 for
> CVE-2017-5715
> ARM: Introduce ability to enable invalidate of BTB with ICIALLU on
> Cortex-A15 for CVE-2017-5715
> ARM: mach-omap2: omap5/dra7: Enable ACTLR[0] (Enable invalidates of
> BTB) to facilitate CVE_2017-5715 WA in OS
> ARM: mach-omap2: omap3/am335x: Enable ACR::IBE on Cortex-A8 SoCs for
> CVE-2017-5715
>
> arch/arm/Kconfig | 9 +++++++++
> arch/arm/cpu/armv7/start.S | 15 +++++++++++++--
> arch/arm/mach-omap2/Kconfig | 3 +++
> 3 files changed, 25 insertions(+), 2 deletions(-)
>
> [1] https://marc.info/?t=151639906500002&r=1&w=2
> [2] https://developer.arm.com/support/security-update
> [3] https://marc.info/?t=151543790400007&r=1&w=2 and the latest in:
> https://marc.info/?l=linux-arm-kernel&m=151689379521082&w=2
> [4]
> https://github.com/ARM-software/arm-trusted-firmware/wiki/ARM-Trusted-Firmware-Security-Advisory-TFV-6
> https://www.op-tee.org/security-advisories/
> https://www.linaro.org/blog/meltdown-spectre/
>
Except for that minor insignificant nit about BIT() macro, entire series
Acked-by: Marek Vasut <marek.vasut@gmail.com>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715
From: Florian Fainelli @ 2018-06-13 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612202411.29798-3-nm@ti.com>
On June 12, 2018 1:24:09 PM PDT, Nishanth Menon <nm@ti.com> wrote:
>As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
>needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
>be done unconditionally for Cortex-A15 processors. Provide a config
>option for platforms to enable this option based on impact analysis
>for products.
>
>NOTE: This patch in itself is NOT the final solution, this requires:
>a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
> provide direct access to ACR register.
>b) Operating Systems such as Linux to provide adequate workaround in
>the
> right locations.
This is the case as of 4.18 so you could probably reference CONFIG_CPU_SPECTRE and CONFIG_HARDEN_BRANCH_PREDICTOR in a v2.
>c) This workaround applies to only the boot processor. It is important
> to apply workaround as necessary (context-save-restore) around low
> power context loss OR additional processors as necessary in either
> firmware support OR elsewhere in OS.
About that, I don't know enough of uboot but are there existing PSCI or other seemingly standard secondary core support in uboot that would make us go through the same initialization as the boot CPU? If not, is everything going to be largely implementation specific and scattered between uboot and the hypervisors or kernel?
FWIW, this is what prompted me to submit this:
https://patchwork.kernel.org/patch/10453643/
>
>[1] https://developer.arm.com/support/security-update
>[2]
>http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
>
>Cc: Marc Zyngier <marc.zyngier@arm.com>
>Cc: Russell King <linux@arm.linux.org.uk>
>Cc: Tony Lindgren <tony@atomide.com>
>Cc: Robin Murphy <robin.murphy@arm.com>
>Cc: Florian Fainelli <f.fainelli@gmail.com>
>Cc: Catalin Marinas <catalin.marinas@arm.com>
>Cc: Will Deacon <will.deacon@arm.com>
>Cc: Christoffer Dall <christoffer.dall@linaro.org>
>Cc: Andre Przywara <Andre.Przywara@arm.com>
>Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Cc: Tom Rini <trini@konsulko.com>
>Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
>
>Signed-off-by: Nishanth Menon <nm@ti.com>
>---
> arch/arm/Kconfig | 4 ++++
> arch/arm/cpu/armv7/start.S | 8 ++++++++
> 2 files changed, 12 insertions(+)
>
>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>index 9e32d5b43cb0..98f58fd27696 100644
>--- a/arch/arm/Kconfig
>+++ b/arch/arm/Kconfig
>@@ -109,6 +109,7 @@ config SYS_ARM_MPU
> # CONFIG_ARM_ERRATA_798870
> # CONFIG_ARM_ERRATA_801819
> # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
>+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>
> config ARM_ERRATA_430973
> bool
>@@ -182,6 +183,9 @@ config ARM_ERRATA_855873
> config ARM_CORTEX_A8_CVE_2017_5715
> bool
>
>+config ARM_CORTEX_A15_CVE_2017_5715
>+ bool
>+
> config CPU_ARM720T
> bool
> select SYS_CACHE_SHIFT_5
>diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>index 3beaf5a93d81..81edec01bf32 100644
>--- a/arch/arm/cpu/armv7/start.S
>+++ b/arch/arm/cpu/armv7/start.S
>@@ -241,6 +241,14 @@ skip_errata_798870:
> skip_errata_801819:
> #endif
>
>+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>+ mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register
>+ orr r0, r0, #1 << 0 @ Enable invalidates of BTB
>+ push {r1-r5} @ Save the cpu info registers
>+ bl v7_arch_cp15_set_acr
>+ pop {r1-r5} @ Restore the cpu info - fall through
>+#endif
>+
> #ifdef CONFIG_ARM_ERRATA_454179
> mrc p15, 0, r0, c1, c0, 1 @ Read ACR
>
--
Florian
^ permalink raw reply
* [PATCH 04/10] Input: ams_delta_serio: Replace power GPIO with regulator
From: Janusz Krzysztofik @ 2018-06-13 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612221724.GB38773@dtor-ws>
On Wednesday, June 13, 2018 12:17:24 AM CEST Dmitry Torokhov wrote:
> On Sat, Jun 09, 2018 at 04:02:18PM +0200, Janusz Krzysztofik wrote:
> > ...
> > + priv->vcc = devm_regulator_get(&pdev->dev, "vcc");
> > + if (IS_ERR(priv->vcc)) {
> > + err = PTR_ERR(priv->vcc);
> > + dev_err(&pdev->dev, "regulator request failed (%d)\n", err);
> > + /* Fail softly if the regulator is not available yet */
> > + if (err == -ENODEV)
> > + err = -EPROBE_DEFER;
>
> Hmm, if regulator is not ready yet, devm_regulator_get() should be
> returning -EPROBE_DEFER already, we should not have to convert -ENODEV
> to -EPROBE_DEFER...
Regulator is not ready because its initialization at subsys_initcall is
deferred by not ready GPIO pin, that in turn is caused by gpio-mmio driver,
unlike many other GPIO drivers, registered as late as at device_initcall.
I agree devm_regulator_get() could return -EPROBE_DEFER in this case, but I
can see it does that only when of_get_regulator() indicates the regulator
should exist. In non-dt case there is apparently no way to justify if it
should unless its consumer supply table was already in place. For that,
registration of that table would have to be independent of successful
registration of the regulator itself while it's not. Maybe it should, but
that's a separate topic for a separate discussion, I think.
> Is it because we have_full_constraints() returns false? You might need
> to add call to regulator_has_full_constraints() to your board file.
If have_full_constraints() returned true before the regulator or its consumer
supply table is ready, devm_regulator_get() would happily return a dummy
regulator and our keyboard would never get its power.
I'm afraid we have to live with that return code conversion as long as the
only user of this driver is not migrated to dt.
Thanks,
Janusz
^ permalink raw reply
* [PATCH 09/10] Input: ams_delta_serio: use IRQ resource
From: Janusz Krzysztofik @ 2018-06-13 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612222104.GC38773@dtor-ws>
On Wednesday, June 13, 2018 12:21:04 AM CEST Dmitry Torokhov wrote:
> On Sat, Jun 09, 2018 at 04:02:23PM +0200, Janusz Krzysztofik wrote:
> > ...
> > @@ -141,14 +141,11 @@ static int ams_delta_serio_init(struct
> > platform_device *pdev)>
> > * at FIQ level, switch back from edge to simple interrupt handler
> > * to avoid bad interaction.
> > */
> >
> > - irq_set_handler(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK),
> > - handle_simple_irq);
> > + irq_set_handler(irq, handle_simple_irq);
>
> Do we still need to do this here, or it can be moved into board file?
You're right, it should be possible to move it. I'll check possible options
and submit a follow up patch.
Thanks,
Janusz
^ permalink raw reply
* [PATCH 1/2] ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
From: Peng Donglin @ 2018-06-13 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1528819790.git.dolinux.peng@gmail.com>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin <dolinux.peng@gmail.com>
---
arch/arm/mm/ptdump_debugfs.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
index be8d87b..79002fe 100644
--- a/arch/arm/mm/ptdump_debugfs.c
+++ b/arch/arm/mm/ptdump_debugfs.c
@@ -11,18 +11,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
From: Peng Donglin @ 2018-06-13 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b55024472e101a33b3d6b098aa2ce23c5b5dd6f7.1528819790.git.dolinux.peng@gmail.com>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Peng Donglin <dolinux.peng@gmail.com>
---
arch/arm64/mm/ptdump_debugfs.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
index 02b18f8..24d786f 100644
--- a/arch/arm64/mm/ptdump_debugfs.c
+++ b/arch/arm64/mm/ptdump_debugfs.c
@@ -10,18 +10,7 @@ static int ptdump_show(struct seq_file *m, void *v)
ptdump_walk_pgd(m, info);
return 0;
}
-
-static int ptdump_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ptdump_show, inode->i_private);
-}
-
-static const struct file_operations ptdump_fops = {
- .open = ptdump_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(ptdump);
int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
{
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] Re-use DEFINE_SHOW_ATTRIBUTE() macro
From: Peng Donglin @ 2018-06-13 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b55024472e101a33b3d6b098aa2ce23c5b5dd6f7.1528819790.git.dolinux.peng@gmail.com>
...instead of open coding file operations followed by custom ->open()
callbacks per each attribute.
Peng Donglin (2):
ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
ARM64: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro
arch/arm/mm/ptdump_debugfs.c | 13 +------------
arch/arm64/mm/ptdump_debugfs.c | 13 +------------
2 files changed, 2 insertions(+), 24 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Janusz Krzysztofik @ 2018-06-13 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612222356.GD38773@dtor-ws>
On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> Hi Janusz,
>
> On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > GPIO lookup table for ams-delta-serio device was introduced by commit
> > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > lookup table" was not accepted by subystem maintainer who requested
> > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > with a regulator and removal of remaining GPIO pins from the driver as
> > not handled by it.
> >
> > Let's start with removal of no the longer needed GPIO lookup table from
> > the board init file.
> >
> > Series created and tested on top of next-20180608 tag from linux-next
> > tree.
>
> This all is really nice (modulo a couple of questions), thank you for
> implementing this. How do you want to merge this? Through OMAP tree or
> input?
Hi Dmitry,
If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
have a few board patches built on top of it in my queue.
Thanks,
Janusz
^ permalink raw reply
* [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
From: Chen-Yu Tsai @ 2018-06-13 3:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-2-jernej.skrabec@siol.net>
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> According to documentation and experience with other similar SoCs, video
> PLLs don't work stable if their output frequency is set below 192 MHz.
>
> Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
From: Chen-Yu Tsai @ 2018-06-13 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-3-jernej.skrabec@siol.net>
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> Display related peripherals need precise clocks to operate correctly.
>
> Allow DE2, TCONs and HDMI to set parent clock.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Tony Lindgren @ 2018-06-13 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <69494657.T0PeNZxiFJ@z50>
* Janusz Krzysztofik <jmkrzyszt@gmail.com> [180613 01:18]:
> On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> > Hi Janusz,
> >
> > On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > > GPIO lookup table for ams-delta-serio device was introduced by commit
> > > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > > lookup table" was not accepted by subystem maintainer who requested
> > > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > > with a regulator and removal of remaining GPIO pins from the driver as
> > > not handled by it.
> > >
> > > Let's start with removal of no the longer needed GPIO lookup table from
> > > the board init file.
> > >
> > > Series created and tested on top of next-20180608 tag from linux-next
> > > tree.
> >
> > This all is really nice (modulo a couple of questions), thank you for
> > implementing this. How do you want to merge this? Through OMAP tree or
> > input?
>
> Hi Dmitry,
>
> If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
> have a few board patches built on top of it in my queue.
Works for me once Dmitry is happy with the patches.
Regards,
Tony
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-13 5:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d801005a-5f7a-8fe4-a486-bc6443a406a3@arm.com>
Hi James,
On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com> wrote:
> Hi Bhupesh, Ard,
>
> On 12/06/18 09:25, Bhupesh Sharma wrote:
>> On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>>>> The start of the linear region map on a KASLR enabled ARM64 machine -
>>>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
>>>> support), is no longer correctly represented by the PAGE_OFFSET macro,
>>>> since it is defined as:
>>>>
>>>> (UL(1) << (VA_BITS - 1)) + 1)
>
>>> PAGE_OFFSET is the VA of the start of the linear map. The linear map
>>> can be sparsely populated with actual memory, regardless of whether
>>> KASLR is in effect or not. The only difference in the presence of
>>> KASLR is that there may be such a hole at the beginning, but that does
>>> not mean the linear map has moved, or that the value of PAGE_OFFSET is
>>> now wrong.
>
>>>> So taking an example of a platform with VA_BITS=48, this gives a static
>>>> value of:
>>>> PAGE_OFFSET = 0xffff800000000000
>>>>
>>>> However, for the KASLR case, we use the 'memstart_offset_seed'
>>>> to randomize the linear region - since 'memstart_addr' indicates the
>>>> start of physical RAM, we randomize the same on basis
>>>> of 'memstart_offset_seed' value.
>>>>
>>>> As the PAGE_OFFSET value is used presently by several user space
>>>> tools (for e.g. makedumpfile and crash tools) to determine the start
>>>> of linear region and hence to read addresses (like PT_NOTE fields) from
>>>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
>>>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
>>>> the start of linear region for the KASLR cases and default to
>>>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
>>>> linear region.
>
>>> Userland code that assumes that the linear map cannot have a hole at
>>> the beginning should be fixed.
>
>> That is a separate case (although that needs fixing as well via a
>> kernel patch probably as the user-space tools rely on '/proc/iomem'
>> contents to determine the first System RAM/reserved range).
>
> This is for kexec-tools generating the kdump vmcore ELF headers in user-space?
Yes, but again, I would like to reiterate that the case where I see a
hole at the start of the System RAM range (as I listed above) is just
a specific case, which probably deserves a separate patch. The current
patch though is for a generic issue (please see more details below).
>> 1. In that particular case (see [1]) the EFI firmware sets the first
>> EFI block as EfiReservedMemType:
>>
>> Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
>> Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
>>
>> Since EFI firmware won't return the "EfiReservedMemType" memory to
>> Linux kernel,
>
> (Its linux that makes this choice in
> drivers/firmware/efi/arm-init.c::is_usable_memory())
>
>
>> so the kernel can't get any info about the first mem
>> block, and kernel can only see region2 as below:
>>
>> efi: Processing EFI memory map:
>> efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
>> | | | | |WB|WT|WC|UC]
>>
>> # head -1 /proc/iomem
>> 00200000-0021ffff : reserved
>>
>> 2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
>> kernel Virtual map we can see that the memory node is set to:
>>
>> # dmesg | grep memory
>> ..........
>> memory : 0xffff800000200000 - 0xffff801800000000
>>
>> 2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
>> if we use 'readelf' to get the last program Header from vmcore (logs
>> below are for the non-kaslr case):
>>
>> # readelf -l vmcore
>>
>> ELF Header:
>> ........................
>>
>> Program Headers:
>> Type Offset VirtAddr PhysAddr
>> FileSiz MemSiz Flags Align
>> ..............................................................................................................................................................
>> LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
>> 0x0000001680000000 0x0000001680000000 RWE 0
>>
>> 3. So if we do a simple calculation:
>>
>> (VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
>> 0xFFFF8017FFE00000 != 0xffff801800000000.
>>
>> which indicates that the end virtual memory nodes are not the same
>> between vmlinux and vmcore.
>
> If I've followed this properly: the problem is that to generate the ELF headers
> in the post-kdump vmcore, at kdump-load-time kexec-tools has to guess the
> virtual addresses of the 'System RAM' regions it can see in /proc/iomem.
>
> The problem you are hitting is an invisible hole at the beginning of RAM,
> meaning user-space's guess_phys_to_virt() is off by the size of this hole.
>
> Isn't KASLR a special case for this? You must have to correct for that after
> kdump has happened, based on an elf-note in the vmcore. Can't we always do this?
No, I hit this issue both for the KASLR and non-KASLR boot cases. We
can fix this either in kernel or user-space.
Fixing this in kernel space seems better to me as the definition of
'memstart_addr' is that it indicates the start of the physical ram,
but since in this case there is a hole at the start of the system ram
visible in Linux (and thus to user-space), but 'memstart_addr' is
still 0 which seems contradictory at the least. This causes PHY_OFFSET
to be 0 as well, which is again contradictory.
>> This happens because the kexec-tools rely on 'proc/iomem' contents
>> while 'memstart_addr' is computed as 0 by kernel (as value of
>> memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
>
>> Returning back to this patch, this is a generic requirement where we
>> need the linear region start/base addresses in user-space applications
>> which is used to read addresses which lie in the linear region (for
>> e.g. when we read /proc/kcore contents).
>
>
>>>> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
>>>> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
>>>> and was able to use a modified user space utility (like kexec-tools and
>>>> makedumpfile) to determine the start of linear region correctly for
>>>> both the KASLR and non-KASLR boot cases.
>>>>
>>>
>>> Can you explain the nature of the changes to the userland code?
>>
>> The changes are not to rely on the fixed PAGE_OFFSET macro value for
>> determining the base address of the linear region, but rather read the
>> ' linear_reg_start_addr' symbol from kernel and use the same both in
>> case of KASLR and non-KASLR boots to determine the base of the linear
>> region (in [2], I have implemented a test change to kexec-tools to
>> read the 'linear_reg_start_addr' symbol which is available on my
>
> Don't use /dev/mem.
I just used it as a quick hack, we can use other approaches as well.
>> public github tree, I have a similar change available in makedumpfile
>> which I have not yet pushed to github, as it implements other features
>> as well)
>
>>>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>>>> index 49d99214f43c..bfd0915ecaf8 100644
>>>> --- a/arch/arm64/include/asm/memory.h
>>>> +++ b/arch/arm64/include/asm/memory.h
>>>> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
>>>> /* PHYS_OFFSET - the physical address of the start of memory. */
>>>> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>>>>
>>>> +/* the virtual base of the linear region. */
>>>> +extern s64 linear_reg_start_addr;
>>>> +
>>>> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
>>>> extern u64 kimage_vaddr;
>>>>
>>>> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
>>>> index d894a20b70b2..a92238ea45ff 100644
>>>> --- a/arch/arm64/kernel/arm64ksyms.c
>>>> +++ b/arch/arm64/kernel/arm64ksyms.c
>>>> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>>>>
>>>> /* physical memory */
>>>> EXPORT_SYMBOL(memstart_addr);
>>>> +EXPORT_SYMBOL(linear_reg_start_addr);
>>>>
>>>> /* string / mem functions */
>>>> EXPORT_SYMBOL(strchr);
>>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>>> index 325cfb3b858a..29447adb0eef 100644
>>>> --- a/arch/arm64/mm/init.c
>>>> +++ b/arch/arm64/mm/init.c
>>>> @@ -60,6 +60,7 @@
>>>> * that cannot be mistaken for a real physical address.
>>>> */
>>>> s64 memstart_addr __ro_after_init = -1;
>>>> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
>>>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>>
>>>> #ifdef CONFIG_BLK_DEV_INITRD
>>>> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
>>>> }
>>>> }
>>>>
>>>> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
>
> This patch adds a variable that nothing uses, its going to be removed. You can't
> depend on reading this via /dev/mem.
>
> Could you add the information you need as an elf-note to the vmcore instead? You
> must already pick these up to handle kaslr. (from memory, this is where the
> kaslr-offset is described to user-space after we kdump).
No you are mixing up the two cases (please see above), the issue which
this patch fixes is for use cases where we don't have the vmcore
available in case of 'live' debugging via makedumpfile and crash tools
(we only have '/proc/kcore' or 'vmlinux' available in such cases). I
detailed the use case in [1] better (in a reply to Ard), I will detail
the use-case again below:
One specific use case that I am working on at the moment is the
makedumpfile '--mem-usage', which allows one to see the page numbers
of current system (1st kernel) in different use (please see
MAKEDUMPFILE(8) for more details).
Using this we can know how many pages are dumpable when different
dump_level is specified when invoking the makedumpfile.
Normally, makedumpfile analyses the contents of '/proc/kcore' (while
excluding the crashkernel range), and then calculates the page number
of different kind per vmcoreinfo.
For e.g. here is an output from my arm64 board (a non KASLR boot):
TYPE PAGES EXCLUDABLE DESCRIPTION
----------------------------------------------------------------------
ZERO 49524 yes Pages
filled with zero
NON_PRI_CACHE 15143 yes Cache
pages without private flag
PRI_CACHE 29147 yes Cache
pages with private flag
USER 3684 yes User process pages
FREE 1450569 yes Free pages
KERN_DATA 14243 no Dumpable kernel data
page size: 65536
Total pages on system: 1562310
Total size on system: 102387548160 Byte
This use case requires directly reading the '/proc/kcore' and the
hence the PAGE_OFFSET value is used to determine the base address of
the linear region, whose value is not static in case of KASLR boot.
Another use-case is where the crash-utility uses the PAGE_OFFSET value
to perform a virtual-to-physical conversion for the address lying in
the linear region:
ulong
arm64_VTOP(ulong addr)
{
if (machdep->flags & NEW_VMEMMAP) {
if (addr >= machdep->machspec->page_offset)
return machdep->machspec->phys_offset
+ (addr - machdep->machspec->page_offset);
<..snip..>
}
[1] https://www.spinics.net/lists/arm-kernel/msg656751.html
Regards,
Bhupesh
^ permalink raw reply
* [PATCH 04/28] drm/mediatek: add ddp component OD1
From: CK Hu @ 2018-06-13 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-5-git-send-email-stu.hsieh@mediatek.com>
On Mon, 2018-06-11 at 11:25 +0800, Stu Hsieh wrote:
> This patch add the component OD1 and
> rename the OD to OD0
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> 4 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 7217665f4b5d..58e44349e315 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -114,7 +114,7 @@ static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> [DDP_COMPONENT_COLOR1] = MT8173_MUTEX_MOD_DISP_COLOR1,
> [DDP_COMPONENT_GAMMA] = MT8173_MUTEX_MOD_DISP_GAMMA,
> - [DDP_COMPONENT_OD] = MT8173_MUTEX_MOD_DISP_OD,
> + [DDP_COMPONENT_OD0] = MT8173_MUTEX_MOD_DISP_OD,
> [DDP_COMPONENT_OVL0] = MT8173_MUTEX_MOD_DISP_OVL0,
> [DDP_COMPONENT_OVL1] = MT8173_MUTEX_MOD_DISP_OVL1,
> [DDP_COMPONENT_PWM0] = MT8173_MUTEX_MOD_DISP_PWM0,
> @@ -139,7 +139,7 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id cur,
> } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
> value = OVL_MOUT_EN_RDMA;
> - } else if (cur == DDP_COMPONENT_OD && next == DDP_COMPONENT_RDMA0) {
> + } else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD_MOUT_EN_RDMA0;
> } else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 0919039805aa..87acf6be87f6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -227,7 +227,8 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
> [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> - [DDP_COMPONENT_OD] = { MTK_DISP_OD, 0, &ddp_od },
> + [DDP_COMPONENT_OD0] = { MTK_DISP_OD, 0, &ddp_od },
> + [DDP_COMPONENT_OD1] = { MTK_DISP_OD, 1, &ddp_od },
> [DDP_COMPONENT_OVL0] = { MTK_DISP_OVL, 0, NULL },
> [DDP_COMPONENT_OVL1] = { MTK_DISP_OVL, 1, NULL },
> [DDP_COMPONENT_PWM0] = { MTK_DISP_PWM, 0, NULL },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index eee3c0cc2632..9b19fc4423f1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -50,7 +50,8 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_GAMMA,
> - DDP_COMPONENT_OD,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_OD1,
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index a415260f3d5f..08d5d0b47bfe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -150,7 +150,7 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_AAL0,
> - DDP_COMPONENT_OD,
> + DDP_COMPONENT_OD0,
> DDP_COMPONENT_RDMA0,
> DDP_COMPONENT_UFOE,
> DDP_COMPONENT_DSI0,
^ permalink raw reply
* [PATCH 07/28] drm/mediatek: add component DPI1
From: CK Hu @ 2018-06-13 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528687580-549-8-git-send-email-stu.hsieh@mediatek.com>
On Mon, 2018-06-11 at 11:25 +0800, Stu Hsieh wrote:
> This patch add the component DPI1
>
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 86e8c9e5df41..4f9d81025d69 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -224,6 +224,7 @@ static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, NULL },
> [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, NULL },
> [DDP_COMPONENT_DPI0] = { MTK_DPI, 0, NULL },
> + [DDP_COMPONENT_DPI1] = { MTK_DPI, 1, NULL },
> [DDP_COMPONENT_DSI0] = { MTK_DSI, 0, NULL },
> [DDP_COMPONENT_DSI1] = { MTK_DSI, 1, NULL },
> [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index e00c2e798abd..54c99c169093 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -47,6 +47,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_COLOR0,
> DDP_COMPONENT_COLOR1,
> DDP_COMPONENT_DPI0,
> + DDP_COMPONENT_DPI1,
> DDP_COMPONENT_DSI0,
> DDP_COMPONENT_DSI1,
> DDP_COMPONENT_GAMMA,
^ 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