* Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps
From: David Hildenbrand @ 2018-07-23 17:20 UTC (permalink / raw)
To: Michal Hocko, Vlastimil Babka
Cc: linux-mm, linux-kernel, Andrew Morton, Baoquan He, Dave Young,
Greg Kroah-Hartman, Hari Bathini, Huang Ying, Kirill A. Shutemov,
Marc-André Lureau, Matthew Wilcox, Miles Chen,
Pavel Tatashin, Petr Tesarik
In-Reply-To: <20180723123043.GD31229@dhcp22.suse.cz>
On 23.07.2018 14:30, Michal Hocko wrote:
> On Mon 23-07-18 13:45:18, Vlastimil Babka wrote:
>> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
>>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
>>> So reserved pages might be access by dump tools although nobody except
>>> the owner should touch them.
>>
>> Are you sure about that? Or maybe I understand wrong. Maybe it changed
>> recently, but IIRC pages that are backing memmap (struct pages) are also
>> PG_reserved. And you definitely do want those in the dump.
>
> You are right. reserve_bootmem_region will make all early bootmem
> allocations (including those backing memmaps) PageReserved. I have asked
> several times but I haven't seen a satisfactory answer yet. Why do we
> even care for kdump about those. If they are reserved the nobody should
> really look at those specific struct pages and manipulate them. Kdump
> tools are using a kernel interface to read the content. If the specific
> content is backed by a non-existing memory then they should simply not
> return anything.
>
"new kernel" provides an interface to read memory from "old kernel".
The new kernel has no idea about
- which memory was added/online in the old kernel
- where struct pages of the old kernel are and what their content is
- which memory is save to touch and which not
Dump tools figure all that out by interpreting the VMCORE. They e.g.
identify "struct pages" and see if they should be dumped. The "new
kernel" only allows to read that memory. It cannot hinder to crash the
system (e.g. if a dump tool would try to read a hwpoison page).
So how should the "new kernel" know if a page can be touched or not?
The *only* way would be to have an interface to the hypervisor where we
"sense" if a memory location is safe to touch. I remember that xen or
hyper-v does that - they fake a zero page in that case, after querying
the hypervisor. But this does not sound like a clean approach to me,
especially es we need yet another hypervisor interface to sense for
memory provided via "some" device.
If we can find a way to just tag pages as "don't touch", it would be the
easiest and cleanest solution in my opinion.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: Lucas Stach @ 2018-07-23 17:19 UTC (permalink / raw)
To: Oleksij Rempel, Shawn Guo, Fabio Estevam, Rob Herring,
Mark Rutland, A.s. Dong, Vladimir Zapolskiy
Cc: kernel, devicetree, dl-linux-imx, linux-arm-kernel
In-Reply-To: <20180722063923.30222-6-o.rempel@pengutronix.de>
Am Sonntag, den 22.07.2018, 08:39 +0200 schrieb Oleksij Rempel:
> The Mailbox controller is able to send messages (up to 4 32 bit words)
> between the endpoints.
>
> This driver was tested using the mailbox-test driver sending messages
> between the Cortex-A7 and the Cortex-M4.
>
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> drivers/mailbox/Kconfig | 6 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/imx-mailbox.c | 273 ++++++++++++++++++++++++++++++++++
> 3 files changed, 281 insertions(+)
> create mode 100644 drivers/mailbox/imx-mailbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index a2bb27446dce..79060ddc380d 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -15,6 +15,12 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
>
> +config IMX_MBOX
> > + tristate "i.MX Mailbox"
> > + depends on ARCH_MXC || COMPILE_TEST
> > + help
> > + Mailbox implementation for i.MX Messaging Unit (MU).
> +
> config PLATFORM_MHU
> > tristate "Platform MHU Mailbox"
> > depends on OF
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index cc23c3a43fcd..ba2fe1b6dd62 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
>
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
>
> > +obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> +
> > obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
>
> > obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> new file mode 100644
> index 000000000000..29cf2876db01
> --- /dev/null
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -0,0 +1,273 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 Pengutronix, Oleksij Rempel <o.rempel@pengutronix.de>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +
> +/* Transmit Register */
> > +#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> +/* Receive Register */
> > +#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> +/* Status Register */
> > +#define IMX_MU_xSR 0x20
> > +#define IMX_MU_xSR_TEn(x) BIT(20 + (3 - (x)))
> > +#define IMX_MU_xSR_RFn(x) BIT(24 + (3 - (x)))
> > +#define IMX_MU_xSR_BRDIP BIT(9)
> +
> +/* Control Register */
> > +#define IMX_MU_xCR 0x24
> +/* Transmit Interrupt Enable */
> > +#define IMX_MU_xCR_TIEn(x) BIT(20 + (3 - (x)))
> +/* Receive Interrupt Enable */
> > +#define IMX_MU_xCR_RIEn(x) BIT(24 + (3 - (x)))
> +
> > +#define IMX_MU_CHANS 4u
> +
> +struct imx_mu_con_priv {
> > > + int irq;
> > > + unsigned int idx;
> > > + char *irq_desc;
> +};
> +
> +struct imx_mu_priv {
> > > + struct device *dev;
> > > + void __iomem *base;
> +
> > > + struct mbox_controller mbox;
> > > + struct mbox_chan mbox_chans[IMX_MU_CHANS];
> +
> > + struct imx_mu_con_priv con_priv[IMX_MU_CHANS];
> > > + struct clk *clk;
> +
> > > + bool side_b;
> +};
> +
> +static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
> +{
> > + return container_of(mbox, struct imx_mu_priv, mbox);
> +}
> +
> +static void imx_mu_write(struct imx_mu_priv *priv, u32 val, u32 offs)
> +{
> + iowrite32(val, priv->base + offs);
This driver is never going to be used on a device with port based IO,
so iowrite doesn't make much sense here, just use writel. Same comment
applies to the below read function.
Also, given that those functions are not really shortening the code in
the user they may also be removed completely IMHO.
> +}
> +
> +static u32 imx_mu_read(struct imx_mu_priv *priv, u32 offs)
> +{
> > + return ioread32(priv->base + offs);
> +}
> +
> +static u32 imx_mu_rmw(struct imx_mu_priv *priv, u32 offs, u32 set, u32 clr)
> +{
> > + u32 val;
> +
> > + val = imx_mu_read(priv, offs);
> > + val &= ~clr;
> > + val |= set;
> > + imx_mu_write(priv, val, offs);
> +
> > + return val;
> +}
> +
> +static irqreturn_t imx_mu_isr(int irq, void *p)
> +{
> > + struct mbox_chan *chan = p;
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val, ctrl, dat;
> +
> > + ctrl = imx_mu_read(priv, IMX_MU_xCR);
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + val &= IMX_MU_xSR_TEn(cp->idx) | IMX_MU_xSR_RFn(cp->idx);
> > + val &= ctrl & (IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> > + if (!val)
> > + return IRQ_NONE;
> +
> > + if (val & IMX_MU_xSR_TEn(cp->idx)) {
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0, IMX_MU_xCR_TIEn(cp->idx));
> > + mbox_chan_txdone(chan, 0);
> > + }
> +
> > + if (val & IMX_MU_xSR_RFn(cp->idx)) {
> > + dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
> > + mbox_chan_received_data(chan, (void *)&dat);
> > + }
> +
> > + return IRQ_HANDLED;
> +}
> +
> +static bool imx_mu_last_tx_done(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val;
> +
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + /* test if transmit register is empty */
> + return val & IMX_MU_xSR_TEn(cp->idx);
I guess
"return imx_mu_read(priv, IMX_MU_xSR) & IMX_MU_xSR_TEn(cp->idx);" is
shorter and equally well understood.
> +}
> +
> +static int imx_mu_send_data(struct mbox_chan *chan, void *data)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 *arg = data;
> +
> > + if (!imx_mu_last_tx_done(chan))
> > + return -EBUSY;
> +
> > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->idx), 0);
In multi-channel mode this RMW cycle needs some kind of locking. As
this register is also changed from the irq handler, this probably needs
to be a irqsave spinlock.
> +
> > + return 0;
> +}
> +
> +static int imx_mu_startup(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> +
> > + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
> > + cp->idx);
> > + if (!cp->irq_desc)
> > + return -ENOMEM;
> +
> > + ret = devm_request_irq(priv->dev, cp->irq, imx_mu_isr,
> + IRQF_SHARED, cp->irq_desc, chan);
Using the devm_ variants of those functions doesn't make sense when the
resources aren't tied to the device lifetime. As you are tearing them
down manually in imx_mu_shutdown anyways, just use the raw variants of
those functions.
> + if (ret) {
> > + dev_err(priv->dev,
> > + "Unable to acquire IRQ %d\n", cp->irq);
> > + return ret;
> > + }
> +
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xCR_RIEn(cp->idx), 0);
> +
> > + return 0;
> +}
> +
> +static void imx_mu_shutdown(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> +
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0,
> > + IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> +
> > + devm_free_irq(priv->dev, cp->irq, chan);
> > + devm_kfree(priv->dev, cp->irq_desc);
> +}
> +
> +static const struct mbox_chan_ops imx_mu_ops = {
> > + .send_data = imx_mu_send_data,
> > + .startup = imx_mu_startup,
> > + .shutdown = imx_mu_shutdown,
> +};
> +
> +static void imx_mu_init_generic(struct imx_mu_priv *priv)
> +{
> > + if (priv->side_b)
> > + return;
> +
> > + /* Set default MU configuration */
> > + imx_mu_write(priv, 0, IMX_MU_xCR);
> +}
> +
> +static int imx_mu_probe(struct platform_device *pdev)
> +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + struct resource *iomem;
> > + struct imx_mu_priv *priv;
> > + unsigned int i;
> > + int irq, ret;
> +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> +
> > + priv->dev = dev;
> +
> > + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->base = devm_ioremap_resource(&pdev->dev, iomem);
> > + if (IS_ERR(priv->base))
> > + return PTR_ERR(priv->base);
> +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0)
> > + return irq;
> +
> > + priv->clk = devm_clk_get(dev, NULL);
> > + if (IS_ERR(priv->clk)) {
> > + if (PTR_ERR(priv->clk) != -ENOENT)
> > + return PTR_ERR(priv->clk);
> +
> > + priv->clk = NULL;
> > + }
> +
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock\n");
> > + return ret;
> > + }
> +
> > + for (i = 0; i < IMX_MU_CHANS; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> +
> > + cp->idx = i;
> > + cp->irq = irq;
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> +
> > + if (of_property_read_bool(np, "fsl,mu-side-b"))
> + priv->side_b = true;
No need for the if clause here. Just assign the return value from
of_property_read_bool to priv->side_b.
> +
> > + priv->mbox.dev = dev;
> > + priv->mbox.ops = &imx_mu_ops;
> > + priv->mbox.chans = priv->mbox_chans;
> > + priv->mbox.num_chans = IMX_MU_CHANS;
> > + priv->mbox.txdone_irq = true;
> +
> > + platform_set_drvdata(pdev, priv);
> +
> > + imx_mu_init_generic(priv);
> +
> > + return mbox_controller_register(&priv->mbox);
> +}
> +
> +static int imx_mu_remove(struct platform_device *pdev)
> +{
> > + struct imx_mu_priv *priv = platform_get_drvdata(pdev);
> +
> > + mbox_controller_unregister(&priv->mbox);
> > + clk_disable_unprepare(priv->clk);
> +
> > + return 0;
> +}
> +
> +static const struct of_device_id imx_mu_dt_ids[] = {
> > + { .compatible = "fsl,imx6sx-mu" },
> > + { },
> +};
> +MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
> +
> +static struct platform_driver imx_mu_driver = {
> > > + .probe = imx_mu_probe,
> > > + .remove = imx_mu_remove,
> > + .driver = {
> > > + .name = "imx_mu",
> > + .of_match_table = imx_mu_dt_ids,
> > + },
> +};
> +module_platform_driver(imx_mu_driver);
> +
> > +MODULE_AUTHOR("Oleksij Rempel <o.rempel@pengutronix.de>");
> +MODULE_DESCRIPTION("Message Unit driver for i.MX");
> +MODULE_LICENSE("GPL v2");
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: Lucas Stach @ 2018-07-23 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180722063923.30222-6-o.rempel@pengutronix.de>
Am Sonntag, den 22.07.2018, 08:39 +0200 schrieb Oleksij Rempel:
> The Mailbox controller is able to send messages (up to 4 32 bit words)
> between the endpoints.
>
> This driver was tested using the mailbox-test driver sending messages
> between the Cortex-A7 and the Cortex-M4.
>
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> ?drivers/mailbox/Kconfig???????|???6 +
> ?drivers/mailbox/Makefile??????|???2 +
> ?drivers/mailbox/imx-mailbox.c | 273 ++++++++++++++++++++++++++++++++++
> ?3 files changed, 281 insertions(+)
> ?create mode 100644 drivers/mailbox/imx-mailbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index a2bb27446dce..79060ddc380d 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -15,6 +15,12 @@ config ARM_MHU
> > ? ??The controller has 3 mailbox channels, the last of which can be
> > ? ??used in Secure mode only.
> ?
> +config IMX_MBOX
> > + tristate "i.MX Mailbox"
> > + depends on ARCH_MXC || COMPILE_TEST
> > + help
> > + ??Mailbox implementation for i.MX Messaging Unit (MU).
> +
> ?config PLATFORM_MHU
> > ? tristate "Platform MHU Mailbox"
> > ? depends on OF
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index cc23c3a43fcd..ba2fe1b6dd62 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> ?
> > ?obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> ?
> > +obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> +
> > ?obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
> ?
> > ?obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> new file mode 100644
> index 000000000000..29cf2876db01
> --- /dev/null
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -0,0 +1,273 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 Pengutronix, Oleksij Rempel <o.rempel@pengutronix.de>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +
> +/* Transmit Register */
> > +#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> +/* Receive Register */
> > +#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> +/* Status Register */
> > +#define IMX_MU_xSR 0x20
> > +#define IMX_MU_xSR_TEn(x) BIT(20 + (3 - (x)))
> > +#define IMX_MU_xSR_RFn(x) BIT(24 + (3 - (x)))
> > +#define IMX_MU_xSR_BRDIP BIT(9)
> +
> +/* Control Register */
> > +#define IMX_MU_xCR 0x24
> +/* Transmit Interrupt Enable */
> > +#define IMX_MU_xCR_TIEn(x) BIT(20 + (3 - (x)))
> +/* Receive Interrupt Enable */
> > +#define IMX_MU_xCR_RIEn(x) BIT(24 + (3 - (x)))
> +
> > +#define IMX_MU_CHANS 4u
> +
> +struct imx_mu_con_priv {
> > > + int irq;
> > > + unsigned int idx;
> > > + char *irq_desc;
> +};
> +
> +struct imx_mu_priv {
> > > + struct device *dev;
> > > + void __iomem *base;
> +
> > > + struct mbox_controller mbox;
> > > + struct mbox_chan mbox_chans[IMX_MU_CHANS];
> +
> > + struct imx_mu_con_priv??con_priv[IMX_MU_CHANS];
> > > + struct clk *clk;
> +
> > > + bool side_b;
> +};
> +
> +static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
> +{
> > + return container_of(mbox, struct imx_mu_priv, mbox);
> +}
> +
> +static void imx_mu_write(struct imx_mu_priv *priv, u32 val, u32 offs)
> +{
> + iowrite32(val, priv->base + offs);
This driver is never going to be used on a device with port based IO,
so iowrite doesn't make much sense here, just use writel. Same comment
applies to the below read function.
Also, given that those functions are not really shortening the code in
the user they may also be removed completely IMHO.
> +}
> +
> +static u32 imx_mu_read(struct imx_mu_priv *priv, u32 offs)
> +{
> > + return ioread32(priv->base + offs);
> +}
> +
> +static u32 imx_mu_rmw(struct imx_mu_priv *priv, u32 offs, u32 set, u32 clr)
> +{
> > + u32 val;
> +
> > + val = imx_mu_read(priv, offs);
> > + val &= ~clr;
> > + val |= set;
> > + imx_mu_write(priv, val, offs);
> +
> > + return val;
> +}
> +
> +static irqreturn_t imx_mu_isr(int irq, void *p)
> +{
> > + struct mbox_chan *chan = p;
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val, ctrl, dat;
> +
> > + ctrl = imx_mu_read(priv, IMX_MU_xCR);
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + val &= IMX_MU_xSR_TEn(cp->idx) | IMX_MU_xSR_RFn(cp->idx);
> > + val &= ctrl & (IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> > + if (!val)
> > + return IRQ_NONE;
> +
> > + if (val & IMX_MU_xSR_TEn(cp->idx)) {
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0, IMX_MU_xCR_TIEn(cp->idx));
> > + mbox_chan_txdone(chan, 0);
> > + }
> +
> > + if (val & IMX_MU_xSR_RFn(cp->idx)) {
> > + dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
> > + mbox_chan_received_data(chan, (void *)&dat);
> > + }
> +
> > + return IRQ_HANDLED;
> +}
> +
> +static bool imx_mu_last_tx_done(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val;
> +
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + /* test if transmit register is empty */
> + return val & IMX_MU_xSR_TEn(cp->idx);
I guess
"return imx_mu_read(priv, IMX_MU_xSR) & IMX_MU_xSR_TEn(cp->idx);" is
shorter and equally well understood.
> +}
> +
> +static int imx_mu_send_data(struct mbox_chan *chan, void *data)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 *arg = data;
> +
> > + if (!imx_mu_last_tx_done(chan))
> > + return -EBUSY;
> +
> > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->idx), 0);
In multi-channel mode this RMW cycle needs some kind of locking. As
this register is also changed from the irq handler, this probably needs
to be a irqsave spinlock.
> +
> > + return 0;
> +}
> +
> +static int imx_mu_startup(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> +
> > + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
> > + ??????cp->idx);
> > + if (!cp->irq_desc)
> > + return -ENOMEM;
> +
> > + ret = devm_request_irq(priv->dev, cp->irq, imx_mu_isr,
> + ???????IRQF_SHARED, cp->irq_desc, chan);
Using the devm_ variants of those functions doesn't make sense when the
resources aren't tied to the device lifetime. As you are tearing them
down manually in imx_mu_shutdown anyways, just use the raw variants of
those functions.
> + if (ret) {
> > + dev_err(priv->dev,
> > + "Unable to acquire IRQ %d\n", cp->irq);
> > + return ret;
> > + }
> +
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xCR_RIEn(cp->idx), 0);
> +
> > + return 0;
> +}
> +
> +static void imx_mu_shutdown(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> +
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0,
> > + ???IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> +
> > + devm_free_irq(priv->dev, cp->irq, chan);
> > + devm_kfree(priv->dev, cp->irq_desc);
> +}
> +
> +static const struct mbox_chan_ops imx_mu_ops = {
> > + .send_data = imx_mu_send_data,
> > + .startup = imx_mu_startup,
> > + .shutdown = imx_mu_shutdown,
> +};
> +
> +static void imx_mu_init_generic(struct imx_mu_priv *priv)
> +{
> > + if (priv->side_b)
> > + return;
> +
> > + /* Set default MU configuration */
> > + imx_mu_write(priv, 0, IMX_MU_xCR);
> +}
> +
> +static int imx_mu_probe(struct platform_device *pdev)
> +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + struct resource *iomem;
> > + struct imx_mu_priv *priv;
> > + unsigned int i;
> > + int irq, ret;
> +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> +
> > + priv->dev = dev;
> +
> > + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->base = devm_ioremap_resource(&pdev->dev, iomem);
> > + if (IS_ERR(priv->base))
> > + return PTR_ERR(priv->base);
> +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0)
> > + return irq;
> +
> > + priv->clk = devm_clk_get(dev, NULL);
> > + if (IS_ERR(priv->clk)) {
> > + if (PTR_ERR(priv->clk) != -ENOENT)
> > + return PTR_ERR(priv->clk);
> +
> > + priv->clk = NULL;
> > + }
> +
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock\n");
> > + return ret;
> > + }
> +
> > + for (i = 0; i < IMX_MU_CHANS; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> +
> > + cp->idx = i;
> > + cp->irq = irq;
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> +
> > + if (of_property_read_bool(np, "fsl,mu-side-b"))
> + priv->side_b = true;
No need for the if clause here. Just assign the return value from
of_property_read_bool to priv->side_b.
> +
> > + priv->mbox.dev = dev;
> > + priv->mbox.ops = &imx_mu_ops;
> > + priv->mbox.chans = priv->mbox_chans;
> > + priv->mbox.num_chans = IMX_MU_CHANS;
> > + priv->mbox.txdone_irq = true;
> +
> > + platform_set_drvdata(pdev, priv);
> +
> > + imx_mu_init_generic(priv);
> +
> > + return mbox_controller_register(&priv->mbox);
> +}
> +
> +static int imx_mu_remove(struct platform_device *pdev)
> +{
> > + struct imx_mu_priv *priv = platform_get_drvdata(pdev);
> +
> > + mbox_controller_unregister(&priv->mbox);
> > + clk_disable_unprepare(priv->clk);
> +
> > + return 0;
> +}
> +
> +static const struct of_device_id imx_mu_dt_ids[] = {
> > + { .compatible = "fsl,imx6sx-mu" },
> > + { },
> +};
> +MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
> +
> +static struct platform_driver imx_mu_driver = {
> > > + .probe = imx_mu_probe,
> > > + .remove = imx_mu_remove,
> > + .driver = {
> > > + .name = "imx_mu",
> > + .of_match_table = imx_mu_dt_ids,
> > + },
> +};
> +module_platform_driver(imx_mu_driver);
> +
> > +MODULE_AUTHOR("Oleksij Rempel <o.rempel@pengutronix.de>");
> +MODULE_DESCRIPTION("Message Unit driver for i.MX");
> +MODULE_LICENSE("GPL v2");
^ permalink raw reply
* Re: [PATCH] mmc: renesas_sdhi: Add r8a77990 support
From: Simon Horman @ 2018-07-23 16:17 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-mmc, linux-renesas-soc, Niklas Söderlund
In-Reply-To: <20180721111449.10103-1-wsa+renesas@sang-engineering.com>
On Sat, Jul 21, 2018 at 01:14:49PM +0200, Wolfram Sang wrote:
> This patch adds SDHI support for the R8A77990 SoC (R-Car E3). No driver changes
> needed for anything except HS400 which we will enable separately later.
No driver update should be required for HS400, see below.
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Note: we shouldn't enable HS400 in the DTS files yet, since we don't have the 8
> tap support. But I think we can enable basic support.
8 tap support is included in the following patch which was accepted
for inclusion in upstream (search for 4TAP):
26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index 839f469f4525..c434200d19d5 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -28,6 +28,7 @@ Required properties:
> "renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC
> "renesas,sdhi-r8a77965" - SDHI IP on R8A77965 SoC
> "renesas,sdhi-r8a77980" - SDHI IP on R8A77980 SoC
> + "renesas,sdhi-r8a77990" - SDHI IP on R8A77990 SoC
> "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC
> "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller
> "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH] ACPI/IORT: Support address size limit for root complexes
From: Robin Murphy @ 2018-07-23 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180718163622.GA21924@red-moon>
[+Christoph]
On 18/07/18 17:36, Lorenzo Pieralisi wrote:
> [+Catalin, Will]
>
> On Mon, Jul 16, 2018 at 04:34:51PM +0100, Robin Murphy wrote:
>> On 2018-07-16 4:10 PM, Lorenzo Pieralisi wrote:
>>> On Tue, Jul 10, 2018 at 05:13:45PM +0100, Robin Murphy wrote:
>>>> IORT revision D allows PCI root complex nodes to specify a memory
>>>> address size limit equivalently to named components, to help describe
>>>> straightforward integrations which don't really warrant a full-blown
>>>> _DMA method. Now that our headers are up-to-date, plumb it in.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>>> ---
>>>> drivers/acpi/arm64/iort.c | 25 +++++++++++++++++++++++--
>>>> 1 file changed, 23 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>> index 7a3a541046ed..4a66896e2aa3 100644
>>>> --- a/drivers/acpi/arm64/iort.c
>>>> +++ b/drivers/acpi/arm64/iort.c
>>>> @@ -947,6 +947,24 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
>>>> return 0;
>>>> }
>>>> +static int rc_dma_get_range(struct device *dev, u64 *size)
>>>> +{
>>>> + struct acpi_iort_node *node;
>>>> + struct acpi_iort_root_complex *rc;
>>>> +
>>>> + node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
>>>> + iort_match_node_callback, dev);
>>>> + if (!node || node->revision < 1)
>>>> + return -ENODEV;
>>>> +
>>>> + rc = (struct acpi_iort_root_complex *)node->node_data;
>>>> +
>>>> + *size = rc->memory_address_limit >= 64 ? U64_MAX :
>>>> + 1ULL<<rc->memory_address_limit;
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> /**
>>>> * iort_dma_setup() - Set-up device DMA parameters.
>>>> *
>>>> @@ -975,10 +993,13 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
>>>> size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>>> - if (dev_is_pci(dev))
>>>> + if (dev_is_pci(dev)) {
>>>> ret = acpi_dma_get_range(dev, &dmaaddr, &offset, &size);
>>>> - else
>>>> + if (ret == -ENODEV)
>>>> + ret = rc_dma_get_range(dev, &size);
>>>
>>> Thank you for putting together the patch.
>>>
>>> The question is whether it is OK to ignore the IORT address limits
>>> when _DMA is actually specified. It is a sort of grey area that
>>> has to be clarified, maybe we can add a check to detect a size
>>> mismatch, I do not know if something should be added at IORT spec
>>> level to clarify its relation to the _DMA object, if present.
>>
>> Yeah, I'm assuming that _DMA would be used to describe conditions
>> more specific than the simple address size limit (i.e. bridge
>> windows), so even if both are present, the range inferred from _DMA
>> will always be less than or equal to that inferred from IORT, and
>> thus rather than explicitly calculating the intersection of the two
>> we can simply do this short-circuit.
>>
>> If IORT accurately reflects the total number of usable address bits,
>> then I can't see that it would ever make sense for _DMA to specify
>> an address range which exceeds that; I guess it comes down to how
>> much effort we want to spend verifying firmware instead of trusting
>> it.
>
> I agree with this reasoning and the patch looks fine, I have not
> queued anything for this cycle for IORT so I would ask Will/Catalin
> to pick it up (if we still have time for v4.19):
>
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cheers Lorenzo (and Hanjun). Given that my DMA mask series[1] is
nominally based on top of this, it might make sense for Christoph to
pick it up through the dma-mapping tree. Since I'm about to send a new
version of that series I'll resend this one as part of that.
Thanks,
Robin.
[1]
https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg24358.html
^ permalink raw reply
* Re: [PATCH] ACPI/IORT: Support address size limit for root complexes
From: Robin Murphy @ 2018-07-23 17:18 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: catalin.marinas, will.deacon, linux-acpi, hanjun.guo,
sudeep.holla, Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20180718163622.GA21924@red-moon>
[+Christoph]
On 18/07/18 17:36, Lorenzo Pieralisi wrote:
> [+Catalin, Will]
>
> On Mon, Jul 16, 2018 at 04:34:51PM +0100, Robin Murphy wrote:
>> On 2018-07-16 4:10 PM, Lorenzo Pieralisi wrote:
>>> On Tue, Jul 10, 2018 at 05:13:45PM +0100, Robin Murphy wrote:
>>>> IORT revision D allows PCI root complex nodes to specify a memory
>>>> address size limit equivalently to named components, to help describe
>>>> straightforward integrations which don't really warrant a full-blown
>>>> _DMA method. Now that our headers are up-to-date, plumb it in.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>>> ---
>>>> drivers/acpi/arm64/iort.c | 25 +++++++++++++++++++++++--
>>>> 1 file changed, 23 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>> index 7a3a541046ed..4a66896e2aa3 100644
>>>> --- a/drivers/acpi/arm64/iort.c
>>>> +++ b/drivers/acpi/arm64/iort.c
>>>> @@ -947,6 +947,24 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
>>>> return 0;
>>>> }
>>>> +static int rc_dma_get_range(struct device *dev, u64 *size)
>>>> +{
>>>> + struct acpi_iort_node *node;
>>>> + struct acpi_iort_root_complex *rc;
>>>> +
>>>> + node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
>>>> + iort_match_node_callback, dev);
>>>> + if (!node || node->revision < 1)
>>>> + return -ENODEV;
>>>> +
>>>> + rc = (struct acpi_iort_root_complex *)node->node_data;
>>>> +
>>>> + *size = rc->memory_address_limit >= 64 ? U64_MAX :
>>>> + 1ULL<<rc->memory_address_limit;
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> /**
>>>> * iort_dma_setup() - Set-up device DMA parameters.
>>>> *
>>>> @@ -975,10 +993,13 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
>>>> size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>>> - if (dev_is_pci(dev))
>>>> + if (dev_is_pci(dev)) {
>>>> ret = acpi_dma_get_range(dev, &dmaaddr, &offset, &size);
>>>> - else
>>>> + if (ret == -ENODEV)
>>>> + ret = rc_dma_get_range(dev, &size);
>>>
>>> Thank you for putting together the patch.
>>>
>>> The question is whether it is OK to ignore the IORT address limits
>>> when _DMA is actually specified. It is a sort of grey area that
>>> has to be clarified, maybe we can add a check to detect a size
>>> mismatch, I do not know if something should be added at IORT spec
>>> level to clarify its relation to the _DMA object, if present.
>>
>> Yeah, I'm assuming that _DMA would be used to describe conditions
>> more specific than the simple address size limit (i.e. bridge
>> windows), so even if both are present, the range inferred from _DMA
>> will always be less than or equal to that inferred from IORT, and
>> thus rather than explicitly calculating the intersection of the two
>> we can simply do this short-circuit.
>>
>> If IORT accurately reflects the total number of usable address bits,
>> then I can't see that it would ever make sense for _DMA to specify
>> an address range which exceeds that; I guess it comes down to how
>> much effort we want to spend verifying firmware instead of trusting
>> it.
>
> I agree with this reasoning and the patch looks fine, I have not
> queued anything for this cycle for IORT so I would ask Will/Catalin
> to pick it up (if we still have time for v4.19):
>
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cheers Lorenzo (and Hanjun). Given that my DMA mask series[1] is
nominally based on top of this, it might make sense for Christoph to
pick it up through the dma-mapping tree. Since I'm about to send a new
version of that series I'll resend this one as part of that.
Thanks,
Robin.
[1]
https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg24358.html
^ permalink raw reply
* Re: [PATCH 05/11] touchscreen: elants: Use octal permissions
From: Dmitry Torokhov @ 2018-07-23 17:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: dev-harsh1998, trivial, Simon Budig, Andi Shyti, Luca Ceresoli,
Joe Perches, Guenter Roeck, linux-input, linux-kernel
In-Reply-To: <20180723133200.GA1167@kroah.com>
On Mon, Jul 23, 2018 at 03:32:00PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 23, 2018 at 06:49:20PM +0530, dev-harsh1998 wrote:
> > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> > +static DEVICE_ATTR(iap_mode, S_IRUGO, show_iap_mode, NULL);
> >
> > WARNING: Symbolic permissions 'S_IWUSR' are not preferred. Consider using octal permissions '0200'.
> > +static DEVICE_ATTR(update_fw, S_IWUSR, NULL, write_update_fw)
> >
> > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> > + .dattr = __ATTR(_field, S_IRUGO, \
> >
> > Signed-off-by: Harshit Jain <harshitjain6751@gmail.com>
>
> This name doesn't match up with the From: line above :(
>
> Please fix up and try again.
dtor@dtor-ws:~/kernel/linux-next$ git grep S_IRU | wc -l
7605
We either need to run a tree-wide script or leave this alone. FWIW I am
perfectly fine with either octals or symbolic names so I do not see
benefit of doing conversion for code that is not known to be broken.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
From: Verma, Shally @ 2018-07-23 17:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: pablo.de.lara.guarch@intel.com, dev@dpdk.org,
Athreya, Narayana Prasad, Challa, Mahipal, Gupta, Ashish,
Sahu, Sunila, Sahu, Sunila
In-Reply-To: <20180723095357.5a85b206@xeon-e3>
>-----Original Message-----
>From: Stephen Hemminger <stephen@networkplumber.org>
>Sent: 23 July 2018 22:24
>To: Verma, Shally <Shally.Verma@cavium.com>
>Cc: pablo.de.lara.guarch@intel.com; dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Challa,
>Mahipal <Mahipal.Challa@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
>Sahu, Sunila <Sunila.Sahu@cavium.com>
>Subject: Re: [dpdk-dev] [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
>
>External Email
>
>On Sat, 21 Jul 2018 23:47:48 +0530
>Shally Verma <shally.verma@caviumnetworks.com> wrote:
>
>> -/** Parse comp xform and set private xform/stream parameters */
>> +/** Compute next mbuf in the list, assign data buffer and length,
>> + * returns 0 if mbuf is NULL
>> + */
>> +#define COMPUTE_BUF(mbuf, data, len) \
>> + ((mbuf = mbuf->next) ? \
>> + (data = rte_pktmbuf_mtod(mbuf, uint8_t *)), \
>> + (len = rte_pktmbuf_data_len(mbuf)) : 0)
>> +
>
>Could this be an inline not a macro?
[Shally] Again what goes in favour of inline here? Just curious to know if DPDK has any preferred guidelines regarding this?
Thanks
Shally
^ permalink raw reply
* [PATCH 8/9] fetch2/git: move generation of git source name into own method
From: Urs Fässler @ 2018-07-23 15:42 UTC (permalink / raw)
To: bitbake-devel
In-Reply-To: <20180723154259.9076-1-urs.fassler@bbv.ch>
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
---
lib/bb/fetch2/git.py | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/lib/bb/fetch2/git.py b/lib/bb/fetch2/git.py
index 7f7951f7..f9e31d2b 100644
--- a/lib/bb/fetch2/git.py
+++ b/lib/bb/fetch2/git.py
@@ -248,17 +248,7 @@ class Git(FetchMethod):
ud.unresolvedrev[name] = ud.revisions[name]
ud.revisions[name] = self.latest_revision(ud, d, name)
- gitsrcname = '%s%s' % (ud.host.replace(':', '.'), ud.path.replace('/', '.').replace('*', '.'))
- if gitsrcname.startswith('.'):
- gitsrcname = gitsrcname[1:]
-
- # for rebaseable git repo, it is necessary to keep mirror tar ball
- # per revision, so that even the revision disappears from the
- # upstream repo in the future, the mirror will remain intact and still
- # contains the revision
- if ud.rebaseable:
- for name in ud.names:
- gitsrcname = gitsrcname + '_' + ud.revisions[name]
+ gitsrcname = self.__build_git_source_name(ud.host, ud.path, ud.rebaseable, ud.names, ud.revisions)
dl_dir = d.getVar("DL_DIR")
gitdir = d.getVar("GITDIR") or (dl_dir + "/git2")
@@ -295,6 +285,22 @@ class Git(FetchMethod):
ud.fullshallow = os.path.join(dl_dir, ud.shallowtarball)
ud.mirrortarballs.insert(0, ud.shallowtarball)
+ @staticmethod
+ def __build_git_source_name(host, path, rebaseable, names, revisions):
+ gitsrcname = '%s%s' % (host.replace(':', '.'), path.replace('/', '.').replace('*', '.'))
+ if gitsrcname.startswith('.'):
+ gitsrcname = gitsrcname[1:]
+
+ # for rebaseable git repo, it is necessary to keep mirror tar ball
+ # per revision, so that even the revision disappears from the
+ # upstream repo in the future, the mirror will remain intact and still
+ # contains the revision
+ if rebaseable:
+ for name in names:
+ gitsrcname = gitsrcname + '_' + revisions[name]
+
+ return gitsrcname
+
def localpath(self, ud, d):
return ud.clonedir
--
2.18.0
^ permalink raw reply related
* [PATCH 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
From: Deepak Singh Rawat @ 2018-07-23 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720211509.23605-11-alexandru-cosmin.gheorghe@arm.com>
Hi Alexandru,
Thanks for the patch, for the vmwgfx part:
Reviewed-by: Deepak Rawat <drawat@vmware.com>
>
> Signed-off-by: Alexandru Gheorghe <alexandru-
> cosmin.gheorghe at arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 466336b34fff..1e0fb3c79b50 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> return;
> }
>
> - plane->state = &vps->base;
> - plane->state->plane = plane;
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> + __drm_atomic_helper_plane_reset(plane, &vps->base);
> }
>
>
> --
> 2.18.0
>
^ permalink raw reply
* RE: [PATCH 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
From: Deepak Singh Rawat @ 2018-07-23 17:16 UTC (permalink / raw)
To: Alexandru Gheorghe
Cc: alexandre.belloni@bootlin.com, airlied@linux.ie,
liviu.dudau@arm.com, dri-devel@lists.freedesktop.org,
laurent.pinchart@ideasonboard.com, Thomas Hellstrom,
krzk@kernel.org, maxime.ripard@bootlin.com, wens@csie.org,
kgene@kernel.org, malidp@foss.arm.com, linux-graphics-maintainer,
sunpeng.li@amd.com, boris.brezillon@bootlin.com,
linux-samsung-soc@vger.kernel.org, nd@arm.com, Tony.Cheng@amd.com,
linux-arm-kernel
In-Reply-To: <20180720211509.23605-11-alexandru-cosmin.gheorghe@arm.com>
Hi Alexandru,
Thanks for the patch, for the vmwgfx part:
Reviewed-by: Deepak Rawat <drawat@vmware.com>
>
> Signed-off-by: Alexandru Gheorghe <alexandru-
> cosmin.gheorghe@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 466336b34fff..1e0fb3c79b50 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> return;
> }
>
> - plane->state = &vps->base;
> - plane->state->plane = plane;
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> + __drm_atomic_helper_plane_reset(plane, &vps->base);
> }
>
>
> --
> 2.18.0
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.19
From: Geert Uytterhoeven @ 2018-07-23 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMh09Do+Yv-C+4hE0KdShajr0hVRfLEPmeoH0AmM5kVAmw@mail.gmail.com>
Hi Olof,
On Mon, Jul 23, 2018 at 6:22 PM Olof Johansson <olof@lixom.net> wrote:
> On Mon, Jul 23, 2018 at 2:11 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> >> > * Set CONFIG_LOCALVERSION to shmobile_defconfig
> >> >
> >> > This follows what appears to be common practice in defconfigs
> >> > and allows easier management of the kernel flavour at run-time.
> >>
> >> I replied to the multi-versions of defconfig for this patch -- it's not a good
> >> way to solve the problem of detecting config at runtime. Please drop this
> >> patch. See:
> >>
> >> https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ at mail.gmail.com/
> >
> > One more comment to the rescue: it does complicate regression testing,
> > as the test software running on the DUT has no easy way to distinguish
> > between e.g. shmobile_defconfig and multi_v7_defconfig (and whatever
> > other board-specific configs I use for testing).
> > Yes, I can have these as local patches in my tree (of course I already have ;-),
> > but when bisecting, I have to remember to (un)apply them in every step.
>
> It looks like scripts/setlocalversion will look for files named
> localversion* in the directory you build in, git won't touch the file
> so you don't have to re-apply it every time.
Thanks a lot, works fine!
I didn't know about that; I started using CONFIG_LOCALVERSION during the
version control dark ages.
Since I use different output directories for different builds anyway, the
file won't ever be removed by git.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/4] perf/x86/intel/ds: Handle PEBS overflow for fixed counters
From: Liang, Kan @ 2018-07-23 17:15 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tglx, mingo, linux-kernel, acme, alexander.shishkin,
vincent.weaver, jolsa, ak
In-Reply-To: <e56be489-3f66-8f27-37e4-77b12c1c99f4@linux.intel.com>
On 7/23/2018 12:56 PM, Liang, Kan wrote:
>
>
> On 7/23/2018 12:21 PM, Peter Zijlstra wrote:
>> On Mon, Jul 23, 2018 at 04:59:44PM +0200, Peter Zijlstra wrote:
>>> On Thu, Mar 08, 2018 at 06:15:41PM -0800, kan.liang@linux.intel.com
>>> wrote:
>>>> diff --git a/arch/x86/events/intel/core.c
>>>> b/arch/x86/events/intel/core.c
>>>> index ef47a418d819..86149b87cce8 100644
>>>> --- a/arch/x86/events/intel/core.c
>>>> +++ b/arch/x86/events/intel/core.c
>>>> @@ -2280,7 +2280,10 @@ static int intel_pmu_handle_irq(struct
>>>> pt_regs *regs)
>>>> * counters from the GLOBAL_STATUS mask and we always process
>>>> PEBS
>>>> * events via drain_pebs().
>>>> */
>>>> - status &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
>>>> + if (x86_pmu.flags & PMU_FL_PEBS_ALL)
>>>> + status &= ~(cpuc->pebs_enabled & EXTENDED_PEBS_COUNTER_MASK);
>>>> + else
>>>> + status &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
>>>> /*
>>>> * PEBS overflow sets bit 62 in the global status register
>>>
>>> Doesn't this re-introduce the problem fixed in commit fd583ad1563be,
>>> where pebs_enabled:32-34 are PEBS Load Latency, instead of fixed
>>> counters?
>>
>> Also, since they 'fixed' that conflict, the PEBS_ALL version could be:
>>
>> state &= cpuc->pebs_enabled;
>>
>> Right?
>
Here, we need to clear the bit for PEBS counters.
For PEBS_ALL version, it should be
status &= ~cpuc->pebs_enabled;
Thanks,
Kan
^ permalink raw reply
* Re: [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree
From: Andrii Anisov @ 2018-07-23 17:14 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall; +Cc: andrew.cooper3, jbeulich, xen-devel
In-Reply-To: <alpine.DEB.2.10.1807061523160.13502@sstabellini-ThinkPad-X260>
Hello Stefano,
On 07.07.18 02:11, Stefano Stabellini wrote:
> The device tree based boot protocol is extended to carry information
> about DomUs. Based on that information, Xen creates and starts one or
> more DomUs.
Please consider also status monitoring and restarting for those domains.
> DomUs created this way don't have access to xenstore for the
> moment. This is actually OK, because this is meant for mission critical
> applications that typically only access directly assigned devices. They
> cannot tolerate interference or increased IRQ latency due to PV
> protocols.
But even a mission critical application does exchange some information
with other entities in the system. So they would need interdomain
communication anyway (i.e. built with event channels and shared pages, etc.)
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree
From: Julien Grall @ 2018-07-23 17:13 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: andrew.cooper3, nd, andrii_anisov, jbeulich, xen-devel
In-Reply-To: <alpine.DEB.2.10.1807181047500.21200@sstabellini-ThinkPad-X260>
On 18/07/18 18:48, Stefano Stabellini wrote:
> On Wed, 18 Jul 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 13/07/18 21:54, Stefano Stabellini wrote:
>>> On Thu, 12 Jul 2018, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> Would it be possible to provide a branch with the patch applied? It would
>>>> be
>>>> nice to have that for every version, so I can easily know on which version
>>>> of
>>>> you are based and avoid spending time trying to apply it :).
>>>
>>> Makes sense, I'll do from next time
>>
>> Could you provide one from this version? So I can review some of your patches
>> more easily.
>
> http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git dom0less-v2
Thanks. I will have a look at the vpl011 patches. I think the rest is
either reviewed or will require changes based on other comments.
Let me know if I missed anything.
Cheers,
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Guenter Roeck @ 2018-07-23 17:13 UTC (permalink / raw)
To: Anton Vasilyev
Cc: Greg Kroah-Hartman, Dmitry Torokhov, Samuel Holland, Pan Bian,
linux-kernel, ldv-project
In-Reply-To: <20180723164857.24460-1-vasilyev@ispras.ru>
On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> in vpd_probe() based on header's ro and rw sizes.
> In vpd_remove() vpd_section_destroy() performs deinitialization based
> on enabled flag, which is set to true by vpd_sections_init().
> This leads to call of vpd_section_destroy() on already destroyed section
> for probe-release-probe-release sequence if first probe performs
> ro_vpd initialization and second probe does not initialize it.
>
I am not sure if the situation described can be seen in the first place.
The second probe would only not perform ro_vpd initialization if it fails
prior to that, ie if it fails to allocate memory or if there is a
consistency problem. In that case the remove function would not be called.
However, there is a problem in the code: A partially failed probe will
leave the system in inconsistent state. Example: ro section initializes,
rw section fails to initialize. The probe will fail, but the ro section
will not be destroyed, its sysfs attributes still exist, and its memory
is still mapped. It would make more sense to fix _that_ problem.
Essentially, vpd_sections_init() should clean up after itself after it
fails to initialize a section.
Note that I am not convinced that the "enabled" flag is needed in the first
place. It is only relevant if vpd_section_destroy() is called, which only
happens from the remove function. The remove function is only called if the
probe function succeeded. In that case it is always set for both sections.
Thanks,
Guenter
> The patch adds changing enabled flag on vpd_section_destroy.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
> ---
> drivers/firmware/google/vpd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
> index e9db895916c3..5347c17c7108 100644
> --- a/drivers/firmware/google/vpd.c
> +++ b/drivers/firmware/google/vpd.c
> @@ -246,6 +246,7 @@ static int vpd_section_destroy(struct vpd_section *sec)
> sysfs_remove_bin_file(vpd_kobj, &sec->bin_attr);
> kfree(sec->raw_name);
> memunmap(sec->baseaddr);
> + sec->enabled = false;
> }
>
> return 0;
> --
> 2.18.0
>
^ permalink raw reply
* [PATCH 5/5] ARM: dts: exynos: configure midas SD card CD pin
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-6-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:53PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we need to disable the SoC's
> internal pull down resistor to allow it to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs
From: Lyude Paul @ 2018-07-23 17:13 UTC (permalink / raw)
To: gregkh; +Cc: bskeggs, stable, David Airlie, dri-devel, nouveau, linux-kernel
In-Reply-To: <153227752119282@kroah.com>
commit eb493fbc150f4a28151ae1ee84f24395989f3600 upstream
Currently nouveau doesn't actually expose the state debugfs file that's
usually provided for any modesetting driver that supports atomic, even
if nouveau is loaded with atomic=1. This is due to the fact that the
standard debugfs files that DRM creates for atomic drivers is called
when drm_get_pci_dev() is called from nouveau_drm.c. This happens well
before we've initialized the display core, which is currently
responsible for setting the DRIVER_ATOMIC cap.
So, move the atomic option into nouveau_drm.c and just add the
DRIVER_ATOMIC cap whenever it's enabled on the kernel commandline. This
shouldn't cause any actual issues, as the atomic ioctl will still fail
as expected even if the display core doesn't disable it until later in
the init sequence. This also provides the added benefit of being able to
use the state debugfs file to check the current display state even if
clients aren't allowed to modify it through anything other than the
legacy ioctls.
Additionally, disable the DRIVER_ATOMIC cap in nv04's display core, as
this was already disabled there previously.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 +++
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +++++++
drivers/gpu/drm/nouveau/nv50_display.c | 6 ------
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 501d2d290e9c..70dce544984e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -55,6 +55,9 @@ nv04_display_create(struct drm_device *dev)
nouveau_display(dev)->init = nv04_display_init;
nouveau_display(dev)->fini = nv04_display_fini;
+ /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */
+ dev->driver->driver_features &= ~DRIVER_ATOMIC;
+
nouveau_hw_save_vga_fonts(dev, 1);
nv04_crtc_create(dev, 0);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index bbbf353682e1..21d28e812963 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -79,6 +79,10 @@ MODULE_PARM_DESC(modeset, "enable driver (default: auto, "
int nouveau_modeset = -1;
module_param_named(modeset, nouveau_modeset, int, 0400);
+MODULE_PARM_DESC(atomic, "Expose atomic ioctl (default: disabled)");
+static int nouveau_atomic = 0;
+module_param_named(atomic, nouveau_atomic, int, 0400);
+
MODULE_PARM_DESC(runpm, "disable (0), force enable (1), optimus only default (-1)");
static int nouveau_runtime_pm = -1;
module_param_named(runpm, nouveau_runtime_pm, int, 0400);
@@ -501,6 +505,9 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
pci_set_master(pdev);
+ if (nouveau_atomic)
+ driver_pci.driver_features |= DRIVER_ATOMIC;
+
ret = drm_get_pci_dev(pdev, pent, &driver_pci);
if (ret) {
nvkm_device_del(&device);
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c
index bc5c4f2402b4..abe297fda046 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4441,10 +4441,6 @@ nv50_display_destroy(struct drm_device *dev)
kfree(disp);
}
-MODULE_PARM_DESC(atomic, "Expose atomic ioctl (default: disabled)");
-static int nouveau_atomic = 0;
-module_param_named(atomic, nouveau_atomic, int, 0400);
-
int
nv50_display_create(struct drm_device *dev)
{
@@ -4469,8 +4465,6 @@ nv50_display_create(struct drm_device *dev)
disp->disp = &nouveau_display(dev)->disp;
dev->mode_config.funcs = &nv50_disp_func;
dev->driver->driver_features |= DRIVER_PREFER_XBGR_30BPP;
- if (nouveau_atomic)
- dev->driver->driver_features |= DRIVER_ATOMIC;
/* small shared memory area we use for notifiers and semaphores */
ret = nouveau_bo_new(&drm->client, 4096, 0x1000, TTM_PL_FLAG_VRAM,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 5/5] ARM: dts: exynos: configure midas SD card CD pin
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-6-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:53PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we need to disable the SoC's
> internal pull down resistor to allow it to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/5] ARM: dts: exynos: configure max77686 IRQ pin on midas
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-5-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:52PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we need to disable the
> SoC's internal pull-down.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] ARM: dts: exynos: configure max77686 IRQ pin on midas
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-5-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:52PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we need to disable the
> SoC's internal pull-down.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps
From: David Hildenbrand @ 2018-07-23 17:12 UTC (permalink / raw)
To: Vlastimil Babka, linux-mm
Cc: linux-kernel, Andrew Morton, Baoquan He, Dave Young,
Greg Kroah-Hartman, Hari Bathini, Huang Ying, Kirill A. Shutemov,
Marc-André Lureau, Matthew Wilcox, Michal Hocko,
Michal Hocko, Miles Chen, Pavel Tatashin, Petr Tesarik
In-Reply-To: <9f46f0ed-e34c-73be-60ca-c892fb19ed08@suse.cz>
On 23.07.2018 13:45, Vlastimil Babka wrote:
> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
>> So reserved pages might be access by dump tools although nobody except
>> the owner should touch them.
>
> Are you sure about that? Or maybe I understand wrong. Maybe it changed
> recently, but IIRC pages that are backing memmap (struct pages) are also
> PG_reserved. And you definitely do want those in the dump.
I proposed a new flag/value to mask pages that are logically offline but
Michal wanted me to go into this direction.
While we can special case struct pages in dump tools ("we have to
read/interpret them either way, so we can also dump them"), it smells
like my original attempt was cleaner. Michal?
>
>> This is relevant in virtual environments where we soon might want to
>> report certain reserved pages to the hypervisor and they might no longer
>> be accessible - what already was documented for reserved pages a long
>> time ago ("might not even exist").
>>
>> David Hildenbrand (2):
>> mm: clarify semantics of reserved pages
>> kdump: include PG_reserved value in VMCOREINFO
>>
>> include/linux/page-flags.h | 4 ++--
>> kernel/crash_core.c | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH 3/5] ARM: dts: exynos: add pinctrl for midas fuelgauge irq pin
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-4-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:51PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we should disable the SoC's
> pull down resistor in order for the interrupt to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/5] ARM: dts: exynos: add pinctrl for midas fuelgauge irq pin
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-4-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:51PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we should disable the SoC's
> pull down resistor in order for the interrupt to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/5] ARM: dts: exynos: add pinctrl config for midas keys
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-3-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:50PM +1000, Simon Shields wrote:
> This pins are externally pulled up, and so we should explicitly
> configure them to disable the SoC-internal pull-downs. Previously
> we relied on the bootloader doing this in order to allow the buttons
> to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.