* Re: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: Peter Zijlstra @ 2019-08-02 8:05 UTC (permalink / raw)
To: john.hubbard
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, Dan Williams, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, John Hubbard, intel-gfx,
linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, linux-arm-kernel, linux-nfs, netdev, LKML, linux-xfs,
linux-crypto, linux-fsdevel, Andrew Morton
In-Reply-To: <20190802021653.4882-1-jhubbard@nvidia.com>
On Thu, Aug 01, 2019 at 07:16:19PM -0700, john.hubbard@gmail.com wrote:
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions"). That commit
> has an extensive description of the problem and the planned steps to
> solve it, but the highlites are:
That is one horridly mangled Changelog there :-/ It looks like it's
partially duplicated.
Anyway; no objections to any of that, but I just wanted to mention that
there are other problems with long term pinning that haven't been
mentioned, notably they inhibit compaction.
A long time ago I proposed an interface to mark pages as pinned, such
that we could run compaction before we actually did the pinning.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add phy-dsi-supply property on stm32mp157c-ev1
From: Yannick FERTRE @ 2019-08-02 8:01 UTC (permalink / raw)
To: Alexandre TORGUE, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Benjamin GAIGNARD, Philippe CORNU,
Fabrice GASNIER
In-Reply-To: <346d04ad-17ed-40c8-f10a-b13a2ea79d92@st.com>
Many thanks Alex.
On 8/2/19 9:36 AM, Alexandre Torgue wrote:
> Hi Yannick
>
> On 7/29/19 4:29 PM, Yannick Fertré wrote:
>> The dsi physical layer is powered by the 1v8 power controller supply.
>>
>> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
>> ---
>> arch/arm/boot/dts/stm32mp157c-ev1.dts | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> b/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> index feb8f77..19d69d0 100644
>> --- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> +++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
>> @@ -101,6 +101,7 @@
>> &dsi {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + phy-dsi-supply = <®18>;
>> status = "okay";
>> ports {
>>
>
> Applied on stm32-next.
>
> Thanks.
> Alex
--
Yannick Fertré | TINA: 166 7152 | Tel: +33 244027152 | Mobile: +33 620600270
Microcontrollers and Digital ICs Group | Microcontrolleurs Division
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] serial: sh-sci: Remove check for specific mctrl_gpio_init() return value
From: Schrempf Frieder @ 2019-08-02 7:59 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190801203902.xie5dexnsoqxxlat@pengutronix.de>
On 01.08.19 22:39, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 06:45:24PM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> Now that the mctrl_gpio code returns NULL instead of ERR_PTR(-ENOSYS)
>> in cases when CONFIG_GPIOLIB is disabled, we can safely remove this
>> check.
>
> I would mention -ENOSYS in the Subject line. Something like:
>
> serial: sh-sci: don't check for mctrl_gpio_init returning -ENOSYS
>
> Now that the mctrl_gpio code returns NULL instead of
> ERR_PTR(-ENOSYS) if CONFIG_GPIOLIB is disabled, we can safely
> remove this check.
Indeed, I failed to come up with a better subject line. I will adopt
your proposal.
> Thanks
> Uwe
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] serial: mctrl_gpio: Avoid probe failures in case of missing gpiolib
From: Schrempf Frieder @ 2019-08-02 7:56 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-serial@vger.kernel.org, geert+renesas@glider.be,
shawnguo@kernel.org, s.hauer@pengutronix.de, Jiri Slaby,
linux-kernel@vger.kernel.org, linux-imx@nxp.com,
kernel@pengutronix.de, Greg Kroah-Hartman, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190801203316.7ntlv6hequmddfxu@pengutronix.de>
On 01.08.19 22:33, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 06:45:21PM +0000, Schrempf Frieder wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() and
>> mctrl_gpio_init_noauto() will currently return an error pointer with
>> -ENOSYS. As the mctrl GPIOs are usually optional, drivers need to
>> check for this condition to allow continue probing.
>>
>> To avoid the need for this check in each driver, we return NULL
>> instead, as all the mctrl_gpio_*() functions are skipped anyway.
>> We also adapt mctrl_gpio_to_gpiod() to be in line with this change.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> Reviewed-by: Fabio Estevam <festevam@gmail.com>
>
> nitpick: put your S-o-b last.
Ok.
>> ---
>> Changes in v2
>> =============
>> * Move the sh_sci changes to a separate patch
>> * Add a patch for the 8250 driver
>> * Add Fabio's R-b tag
>> ---
>> drivers/tty/serial/serial_mctrl_gpio.c | 3 +++
>> drivers/tty/serial/serial_mctrl_gpio.h | 6 +++---
>> 2 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/tty/serial/serial_mctrl_gpio.c b/drivers/tty/serial/serial_mctrl_gpio.c
>> index 2b400189be91..54c43e02e375 100644
>> --- a/drivers/tty/serial/serial_mctrl_gpio.c
>> +++ b/drivers/tty/serial/serial_mctrl_gpio.c
>> @@ -61,6 +61,9 @@ EXPORT_SYMBOL_GPL(mctrl_gpio_set);
>> struct gpio_desc *mctrl_gpio_to_gpiod(struct mctrl_gpios *gpios,
>> enum mctrl_gpio_idx gidx)
>> {
>> + if (gpios == NULL)
>> + return NULL;
>> +
>
> I wonder why you need this. If GPIOLIB is off this code isn't active and
> with GPIOLIB calling mctrl_gpio_to_gpiod with a gpios == NULL is a bug
> that IMHO should not be silently ignored.
>
> Am I missing something (again)?
No, you're right. My thoughts were, that if the mctrl_gpio functions are
allowed to be passed a NULL pointer in general, they all should have a
NULL check, even if in the current context (GPIOLIB disabled) this code
is not active. Apparently there are other cases when a NULL pointer is
passed, see [1]. So you can't really consider gpios == NULL to be a bug
as this seems to be allowed in general.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=434be0ae7aa746f481c3a22139e472dbc3f4f817
>
>> return gpios->gpio[gidx];
>> }
>
> Best regards
> Uwe
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: ARM: multi_v7_defconfig: Enable SPI_STM32_QSPI support
From: Alexandre Torgue @ 2019-08-02 7:38 UTC (permalink / raw)
To: patrice.chotard, Arnd Bergmann, Olof Johansson, Russell King
Cc: soc, linux-kernel, linux-arm-kernel, linux-stm32
In-Reply-To: <20190731072204.32160-1-patrice.chotard@st.com>
Dear Patrice
On 7/31/19 9:22 AM, patrice.chotard@st.com wrote:
> From: Patrice Chotard <patrice.chotard@st.com>
>
> Enable support for QSPI block on STM32 SoCs.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> ---
> arch/arm/configs/multi_v7_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 6a40bc2ef271..78d1d93298af 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -403,6 +403,7 @@ CONFIG_SPI_SH_MSIOF=m
> CONFIG_SPI_SH_HSPI=y
> CONFIG_SPI_SIRF=y
> CONFIG_SPI_STM32=m
> +CONFIG_SPI_STM32_QSPI=m
> CONFIG_SPI_SUN4I=y
> CONFIG_SPI_SUN6I=y
> CONFIG_SPI_TEGRA114=y
>
Applied on stm32-next.
Thanks.
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add phy-dsi-supply property on stm32mp157c-ev1
From: Alexandre Torgue @ 2019-08-02 7:36 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu, Fabrice Gasnier
In-Reply-To: <1564410548-20436-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 7/29/19 4:29 PM, Yannick Fertré wrote:
> The dsi physical layer is powered by the 1v8 power controller supply.
>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157c-ev1.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts b/arch/arm/boot/dts/stm32mp157c-ev1.dts
> index feb8f77..19d69d0 100644
> --- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
> @@ -101,6 +101,7 @@
> &dsi {
> #address-cells = <1>;
> #size-cells = <0>;
> + phy-dsi-supply = <®18>;
> status = "okay";
>
> ports {
>
Applied on stm32-next.
Thanks.
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 2/2] mailbox: imx: add support for imx v1 mu
From: Richard Zhu @ 2019-08-02 7:01 UTC (permalink / raw)
To: jassisinghbrar, o.rempel, aisheng.dong
Cc: Richard Zhu, linux-imx, linux-arm-kernel, linux-kernel
In-Reply-To: <1564729300-30374-1-git-send-email-hongxing.zhu@nxp.com>
There is a version 1.0 MU on i.MX7ULP platform.
One new version ID register is added, and it's offset is 0.
TRn registers are defined at the offset 0x20 ~ 0x2C.
RRn registers are defined at the offset 0x40 ~ 0x4C.
SR/CR registers are defined at 0x60/0x64.
Extend this driver to support it.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Suggested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/mailbox/imx-mailbox.c | 55 ++++++++++++++++++++++++++++++-------------
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 3ecebdc..dc08ef4 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -12,19 +12,11 @@
#include <linux/of_device.h>
#include <linux/slab.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_GIPn(x) BIT(28 + (3 - (x)))
#define IMX_MU_xSR_RFn(x) BIT(24 + (3 - (x)))
#define IMX_MU_xSR_TEn(x) BIT(20 + (3 - (x)))
#define IMX_MU_xSR_BRDIP BIT(9)
-/* Control Register */
-#define IMX_MU_xCR 0x24
/* General Purpose Interrupt Enable */
#define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
/* Receive Interrupt Enable */
@@ -44,6 +36,13 @@ enum imx_mu_chan_type {
IMX_MU_TYPE_RXDB, /* Rx doorbell */
};
+struct imx_mu_dcfg {
+ u32 xTR[4]; /* Transmit Registers */
+ u32 xRR[4]; /* Receive Registers */
+ u32 xSR; /* Status Register */
+ u32 xCR; /* Control Register */
+};
+
struct imx_mu_con_priv {
unsigned int idx;
char irq_desc[IMX_MU_CHAN_NAME_SIZE];
@@ -61,12 +60,27 @@ struct imx_mu_priv {
struct mbox_chan mbox_chans[IMX_MU_CHANS];
struct imx_mu_con_priv con_priv[IMX_MU_CHANS];
+ const struct imx_mu_dcfg *dcfg;
struct clk *clk;
int irq;
bool side_b;
};
+static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
+ .xTR = {0x0, 0x4, 0x8, 0xc},
+ .xRR = {0x10, 0x14, 0x18, 0x1c},
+ .xSR = 0x20,
+ .xCR = 0x24,
+};
+
+static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
+ .xTR = {0x20, 0x24, 0x28, 0x2c},
+ .xRR = {0x40, 0x44, 0x48, 0x4c},
+ .xSR = 0x60,
+ .xCR = 0x64,
+};
+
static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
{
return container_of(mbox, struct imx_mu_priv, mbox);
@@ -88,10 +102,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32 set, u32 clr)
u32 val;
spin_lock_irqsave(&priv->xcr_lock, flags);
- val = imx_mu_read(priv, IMX_MU_xCR);
+ val = imx_mu_read(priv, priv->dcfg->xCR);
val &= ~clr;
val |= set;
- imx_mu_write(priv, val, IMX_MU_xCR);
+ imx_mu_write(priv, val, priv->dcfg->xCR);
spin_unlock_irqrestore(&priv->xcr_lock, flags);
return val;
@@ -111,8 +125,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
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);
+ ctrl = imx_mu_read(priv, priv->dcfg->xCR);
+ val = imx_mu_read(priv, priv->dcfg->xSR);
switch (cp->type) {
case IMX_MU_TYPE_TX:
@@ -138,10 +152,10 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
mbox_chan_txdone(chan, 0);
} else if (val == IMX_MU_xSR_RFn(cp->idx)) {
- dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
+ dat = imx_mu_read(priv, priv->dcfg->xRR[cp->idx]);
mbox_chan_received_data(chan, (void *)&dat);
} else if (val == IMX_MU_xSR_GIPn(cp->idx)) {
- imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), IMX_MU_xSR);
+ imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), priv->dcfg->xSR);
mbox_chan_received_data(chan, NULL);
} else {
dev_warn_ratelimited(priv->dev, "Not handled interrupt\n");
@@ -159,7 +173,7 @@ static int imx_mu_send_data(struct mbox_chan *chan, void *data)
switch (cp->type) {
case IMX_MU_TYPE_TX:
- imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
+ imx_mu_write(priv, *arg, priv->dcfg->xTR[cp->idx]);
imx_mu_xcr_rmw(priv, IMX_MU_xCR_TIEn(cp->idx), 0);
break;
case IMX_MU_TYPE_TXDB:
@@ -270,7 +284,7 @@ static void imx_mu_init_generic(struct imx_mu_priv *priv)
return;
/* Set default MU configuration */
- imx_mu_write(priv, 0, IMX_MU_xCR);
+ imx_mu_write(priv, 0, priv->dcfg->xCR);
}
static int imx_mu_probe(struct platform_device *pdev)
@@ -278,6 +292,7 @@ static int imx_mu_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct device_node *np = dev->of_node;
struct imx_mu_priv *priv;
+ const struct imx_mu_dcfg *dcfg;
unsigned int i;
int ret;
@@ -295,6 +310,11 @@ static int imx_mu_probe(struct platform_device *pdev)
if (priv->irq < 0)
return priv->irq;
+ dcfg = of_device_get_match_data(dev);
+ if (!dcfg)
+ return -EINVAL;
+ priv->dcfg = dcfg;
+
priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk)) {
if (PTR_ERR(priv->clk) != -ENOENT)
@@ -348,7 +368,8 @@ static int imx_mu_remove(struct platform_device *pdev)
}
static const struct of_device_id imx_mu_dt_ids[] = {
- { .compatible = "fsl,imx6sx-mu" },
+ { .compatible = "fsl,imx7ulp-mu", .data = &imx_mu_cfg_imx7ulp },
+ { .compatible = "fsl,imx6sx-mu", .data = &imx_mu_cfg_imx6sx },
{ },
};
MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: mailbox: imx-mu: add imx7ulp MU support
From: Richard Zhu @ 2019-08-02 7:01 UTC (permalink / raw)
To: jassisinghbrar, o.rempel, aisheng.dong
Cc: Richard Zhu, linux-imx, linux-arm-kernel, linux-kernel
In-Reply-To: <1564729300-30374-1-git-send-email-hongxing.zhu@nxp.com>
There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" compatible
to support it.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
index f3cf77e..9c43357 100644
--- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
+++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
@@ -21,6 +21,8 @@ Required properties:
imx6sx, imx7s, imx8qxp, imx8qm.
The "fsl,imx6sx-mu" compatible is seen as generic and should
be included together with SoC specific compatible.
+ There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
+ compatible to support it.
- reg : Should contain the registers location and length
- interrupts : Interrupt number. The interrupt specifier format depends
on the interrupt controller parent.
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 0/2] mailbox: imx: add support for imx v1 mu
From: Richard Zhu @ 2019-08-02 7:01 UTC (permalink / raw)
To: jassisinghbrar, o.rempel, aisheng.dong
Cc: Richard Zhu, linux-imx, linux-arm-kernel, linux-kernel
Change logs:
v3 --> v4:
- Change "version1.0" to "version 1.0" in the commit log.
- Update the devicetree binding document to support the imx7ulp mu.
- Rebase the patch refer to the following bug-fixs patch-set issued
by Daniel Baluta <daniel.baluta@gmail.com>.
"https://patchwork.kernel.org/patch/11069479/"
v2 --> v3:
- Format the patch-set refer to Oleksij's guidance.
- Init the register array by a simple way recommended by Oleksij.
- Add Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> tag.
v1 --> v2:
- Use to have the register layout linked on probe, suggested by
Oleksij Rempel <o.rempel@pengutronix.de>.
- Add Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> tag.
Richard Zhu (2):
dt-bindings: mailbox: imx-mu: add imx7ulp MU support
mailbox: imx: add support for imx v1 mu
.../devicetree/bindings/mailbox/fsl,mu.txt | 2 +
drivers/mailbox/imx-mailbox.c | 55 +++++++++++++++-------
2 files changed, 40 insertions(+), 17 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V4 1/2] perf: imx8_ddr_perf: add AXI ID filter support
From: Joakim Zhang @ 2019-08-02 7:19 UTC (permalink / raw)
To: Robin Murphy, will@kernel.org, mark.rutland@arm.com, Frank Li
Cc: kernel@pengutronix.de, linux-arm-kernel@lists.infradead.org,
dl-linux-imx
In-Reply-To: <5988bae3-e0db-a64d-8399-8ce65a92d970@arm.com>
> -----Original Message-----
> From: Robin Murphy <robin.murphy@arm.com>
> Sent: 2019年8月1日 18:00
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; will@kernel.org;
> mark.rutland@arm.com; Frank Li <frank.li@nxp.com>
> Cc: linux-arm-kernel@lists.infradead.org; kernel@pengutronix.de; dl-linux-imx
> <linux-imx@nxp.com>
> Subject: Re: [PATCH V4 1/2] perf: imx8_ddr_perf: add AXI ID filter support
>
> On 2019-08-01 6:25 am, Joakim Zhang wrote:
> [...]
> >>> @@ -195,6 +214,18 @@ static int ddr_perf_event_init(struct
> >>> perf_event
> >> *event)
> >>> struct hw_perf_event *hwc = &event->hw;
> >>> struct perf_event *sibling;
> >>>
> >>> + if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> >>> + if (event->attr.config == 0x41)
> >>> + pmu->axi_id_read = event->attr.config1;
> >>> +
> >>> + if (event->attr.config == 0x42)
> >>> + pmu->axi_id_write = event->attr.config1;
> >>> +
> >>> + if (pmu->axi_id_read && pmu->axi_id_write &&
> >>> + (pmu->axi_id_read != pmu->axi_id_write))
> >>> + return -EINVAL;
> >>> + }
> >>
> >> This isn't the correct approach that Mark outlined :(
> >>
> >> In event_init, you should validate that any filtering for the given
> >> event is compatible with any other sibling events in the same group,
> >> but you should not consider (and should definitely not change) the
> >> current state of the PMU at that point. This step is about rejecting
> >> event configurations which could
> >> *never* be successfully scheduled (since a group represents a set of
> >> events which must be scheduled all at the same time).
> >>
> >> In event_add, you know the given event/group is sufficiently valid to
> >> *potentially* be scheduled, given that it has passed the event_init
> >> checks, but you then need to check that the filtering is compatible
> >> with all other events
> >> *currently* counting on the PMU. If this fails, perf core will try to
> >> reschedule the current events until the new one is able to run.
> >> That's why you need the additional step of validating groups
> >> beforehand, because otherwise you could end up with contradictory
> >> scheduling constraints at this point and never make progress.
> >
> > Hi Mark and Robin,
> >
> > Thanks for all your kindly detailed explanation firstly.
> >
> > My understanding from your comments, I need to validate the filtering (i.e.
> config1/axi_id) for *all* events in same group during event_init, right?
> > But it's so strange for that axi_id is only for axi-id-read and axi-id-write event.
> We don't need to specify axi_id for any other events when mixed with these
> two events.
>
> Sorry, I implicitly meant all *relevant* events - obviously there's nothing to
> check for events which don't have filtering anyway. All that matters is the case
> where we're asked to create a read/write event in a group which already has at
> least one other read/write event as a sibling. I've sketched out a quick
> (completely untested) example of one way to do that part below. The logic for
> event_add would be very similar, except instead of comparing the sibling
> against the event, there you'd compare the event against the current PMU
> state.
>
> > If I can just check the axi-id-read and axi-id-write event during
> > event_add and then pass the axi_id value to the filter register. Don't
> > check the case that user specify both of them at the same time with different
> filtering value. Instead of checking it in the driver, I add the doc in
> Documentation/admin-guide/perf/ directory to note that axi-id-read and
> axi-id-write event should be specified separately, or specified at the same time
> with same axi_id value.
>
> Sure, we could just rely on the user to get it right, but that means there's a fair
> chance that the user can inadvertently get it wrong, get nonsensical results,
> and waste a week trying to debug a perceived problem which doesn't actually
> exist. It's not difficult for the driver to perform the correct validation, so it's
> better for everyone if it does.
>
> It also seems reasonable that a user might want to intentionally measure
> events on different IDs over the same run (but not in the same group), e.g. to
> compare the relative average bandwidth of two devices, perhaps to tune QoS
> parameters. That requires perf core to know it needs to rotate the events
> during the run, which will only happen if event_add does the right thing.
>
> Robin.
Hi Robin,
I completely understood what you said now, thank you very much. But I came across another issue when I
test this case. You can see below.
[...]
> for_each_sibling_event(sibling, event->group_leader) {
> if (sibling->pmu != event->pmu &&
> !is_software_event(sibling))
> return -EINVAL;
> +
> + if (is_filtered && ddr_perf_is_filtered(sibling) &&
> + ddr_perf_filter_val(sibling) != filter_val)
> + return -EINVAL;
> }
[...]
Need to check the axi id value of sibling events in one same group with for_each_sibling_event ():
#define for_each_sibling_event(sibling, event) \
if ((event)->group_leader == (event)) \
list_for_each_entry((sibling), &(event)->sibling_list, sibling_list)
But I found that all check in this For loop will never be checked, that means the code never runs into this For loop.
if (sibling->pmu != event->pmu &&
!is_software_event(sibling))
return -EINVAL;
if (is_filtered && ddr_perf_is_filtered(sibling) &&
ddr_perf_filter_val(sibling) != filter_val)
return -EINVAL;
Finally I found that it can't iterate over the list with list_for_each_entry((sibling), &(event)->sibling_list, sibling_list). So driver
can't reject event group with axi id illegal value during event_init() now. Do you know why it can't iterate to sibling events?
Best Regards,
Joakim Zhang
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/14] gpio: lpc32xx: allow building on non-lpc32xx targets
From: Bartosz Golaszewski @ 2019-08-02 7:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Lunn, LINUXWATCHDOG, LKML, Jason Cooper, David S. Miller,
Greg Kroah-Hartman, Gregory Clement, linux-usb, Russell King,
Vladimir Zapolskiy, linux-gpio, soc, netdev, Alan Stern,
Guenter Roeck, linux-serial, Sylvain Lemieux, Lee Jones,
Linus Walleij, arm-soc, Sebastian Hesselbarth
In-Reply-To: <20190731195713.3150463-6-arnd@arndb.de>
śr., 31 lip 2019 o 22:06 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> The driver uses hardwire MMIO addresses instead of the data
> that is passed in device tree. Change it over to only
> hardcode the register offset values and allow compile-testing.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Hi Arnd,
thanks for working on this.
> ---
> drivers/gpio/Kconfig | 8 +++++
> drivers/gpio/Makefile | 2 +-
> drivers/gpio/gpio-lpc32xx.c | 63 ++++++++++++++++++++++++-------------
> 3 files changed, 50 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index bb13c266c329..ae86ee963eae 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -311,6 +311,14 @@ config GPIO_LPC18XX
> Select this option to enable GPIO driver for
> NXP LPC18XX/43XX devices.
>
> +config GPIO_LPC32XX
> + tristate "NXP LPC32XX GPIO support"
> + default ARCH_LPC32XX
> + depends on OF_GPIO && (ARCH_LPC32XX || COMPILE_TEST)
> + help
> + Select this option to enable GPIO driver for
> + NXP LPC32XX devices.
> +
> config GPIO_LYNXPOINT
> tristate "Intel Lynxpoint GPIO support"
> depends on ACPI && X86
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index a4e91175c708..87d659ae95eb 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -74,7 +74,7 @@ obj-$(CONFIG_GPIO_LP3943) += gpio-lp3943.o
> obj-$(CONFIG_GPIO_LP873X) += gpio-lp873x.o
> obj-$(CONFIG_GPIO_LP87565) += gpio-lp87565.o
> obj-$(CONFIG_GPIO_LPC18XX) += gpio-lpc18xx.o
> -obj-$(CONFIG_ARCH_LPC32XX) += gpio-lpc32xx.o
> +obj-$(CONFIG_GPIO_LPC32XX) += gpio-lpc32xx.o
> obj-$(CONFIG_GPIO_LYNXPOINT) += gpio-lynxpoint.o
> obj-$(CONFIG_GPIO_MADERA) += gpio-madera.o
> obj-$(CONFIG_GPIO_MAX3191X) += gpio-max3191x.o
> diff --git a/drivers/gpio/gpio-lpc32xx.c b/drivers/gpio/gpio-lpc32xx.c
> index 24885b3db3d5..548f7cb69386 100644
> --- a/drivers/gpio/gpio-lpc32xx.c
> +++ b/drivers/gpio/gpio-lpc32xx.c
> @@ -16,8 +16,7 @@
> #include <linux/platform_device.h>
> #include <linux/module.h>
>
> -#include <mach/hardware.h>
> -#include <mach/platform.h>
> +#define _GPREG(x) (x)
What purpose does this macro serve?
>
> #define LPC32XX_GPIO_P3_INP_STATE _GPREG(0x000)
> #define LPC32XX_GPIO_P3_OUTP_SET _GPREG(0x004)
> @@ -72,12 +71,12 @@
> #define LPC32XX_GPO_P3_GRP (LPC32XX_GPI_P3_GRP + LPC32XX_GPI_P3_MAX)
>
> struct gpio_regs {
> - void __iomem *inp_state;
> - void __iomem *outp_state;
> - void __iomem *outp_set;
> - void __iomem *outp_clr;
> - void __iomem *dir_set;
> - void __iomem *dir_clr;
> + unsigned long inp_state;
> + unsigned long outp_state;
> + unsigned long outp_set;
> + unsigned long outp_clr;
> + unsigned long dir_set;
> + unsigned long dir_clr;
> };
>
> /*
> @@ -167,14 +166,26 @@ struct lpc32xx_gpio_chip {
> struct gpio_regs *gpio_grp;
> };
>
> +void __iomem *gpio_reg_base;
Any reason why this can't be made part of struct lpc32xx_gpio_chip?
> +
> +static inline u32 gpreg_read(unsigned long offset)
Here and elsewhere: could you please keep the lpc32xx_gpio prefix for
all symbols?
> +{
> + return __raw_readl(gpio_reg_base + offset);
> +}
> +
> +static inline void gpreg_write(u32 val, unsigned long offset)
> +{
> + __raw_writel(val, gpio_reg_base + offset);
> +}
> +
> static void __set_gpio_dir_p012(struct lpc32xx_gpio_chip *group,
> unsigned pin, int input)
> {
> if (input)
> - __raw_writel(GPIO012_PIN_TO_BIT(pin),
> + gpreg_write(GPIO012_PIN_TO_BIT(pin),
> group->gpio_grp->dir_clr);
> else
> - __raw_writel(GPIO012_PIN_TO_BIT(pin),
> + gpreg_write(GPIO012_PIN_TO_BIT(pin),
> group->gpio_grp->dir_set);
> }
>
> @@ -184,19 +195,19 @@ static void __set_gpio_dir_p3(struct lpc32xx_gpio_chip *group,
> u32 u = GPIO3_PIN_TO_BIT(pin);
>
> if (input)
> - __raw_writel(u, group->gpio_grp->dir_clr);
> + gpreg_write(u, group->gpio_grp->dir_clr);
> else
> - __raw_writel(u, group->gpio_grp->dir_set);
> + gpreg_write(u, group->gpio_grp->dir_set);
> }
>
> static void __set_gpio_level_p012(struct lpc32xx_gpio_chip *group,
> unsigned pin, int high)
> {
> if (high)
> - __raw_writel(GPIO012_PIN_TO_BIT(pin),
> + gpreg_write(GPIO012_PIN_TO_BIT(pin),
> group->gpio_grp->outp_set);
> else
> - __raw_writel(GPIO012_PIN_TO_BIT(pin),
> + gpreg_write(GPIO012_PIN_TO_BIT(pin),
> group->gpio_grp->outp_clr);
> }
>
> @@ -206,31 +217,31 @@ static void __set_gpio_level_p3(struct lpc32xx_gpio_chip *group,
> u32 u = GPIO3_PIN_TO_BIT(pin);
>
> if (high)
> - __raw_writel(u, group->gpio_grp->outp_set);
> + gpreg_write(u, group->gpio_grp->outp_set);
> else
> - __raw_writel(u, group->gpio_grp->outp_clr);
> + gpreg_write(u, group->gpio_grp->outp_clr);
> }
>
> static void __set_gpo_level_p3(struct lpc32xx_gpio_chip *group,
> unsigned pin, int high)
> {
> if (high)
> - __raw_writel(GPO3_PIN_TO_BIT(pin), group->gpio_grp->outp_set);
> + gpreg_write(GPO3_PIN_TO_BIT(pin), group->gpio_grp->outp_set);
> else
> - __raw_writel(GPO3_PIN_TO_BIT(pin), group->gpio_grp->outp_clr);
> + gpreg_write(GPO3_PIN_TO_BIT(pin), group->gpio_grp->outp_clr);
> }
>
> static int __get_gpio_state_p012(struct lpc32xx_gpio_chip *group,
> unsigned pin)
> {
> - return GPIO012_PIN_IN_SEL(__raw_readl(group->gpio_grp->inp_state),
> + return GPIO012_PIN_IN_SEL(gpreg_read(group->gpio_grp->inp_state),
> pin);
> }
>
> static int __get_gpio_state_p3(struct lpc32xx_gpio_chip *group,
> unsigned pin)
> {
> - int state = __raw_readl(group->gpio_grp->inp_state);
> + int state = gpreg_read(group->gpio_grp->inp_state);
>
> /*
> * P3 GPIO pin input mapping is not contiguous, GPIOP3-0..4 is mapped
> @@ -242,13 +253,13 @@ static int __get_gpio_state_p3(struct lpc32xx_gpio_chip *group,
> static int __get_gpi_state_p3(struct lpc32xx_gpio_chip *group,
> unsigned pin)
> {
> - return GPI3_PIN_IN_SEL(__raw_readl(group->gpio_grp->inp_state), pin);
> + return GPI3_PIN_IN_SEL(gpreg_read(group->gpio_grp->inp_state), pin);
> }
>
> static int __get_gpo_state_p3(struct lpc32xx_gpio_chip *group,
> unsigned pin)
> {
> - return GPO3_PIN_IN_SEL(__raw_readl(group->gpio_grp->outp_state), pin);
> + return GPO3_PIN_IN_SEL(gpreg_read(group->gpio_grp->outp_state), pin);
> }
>
> /*
> @@ -498,6 +509,10 @@ static int lpc32xx_gpio_probe(struct platform_device *pdev)
> {
> int i;
>
> + gpio_reg_base = devm_platform_ioremap_resource(pdev, 0);
> + if (gpio_reg_base)
> + return -ENXIO;
> +
> for (i = 0; i < ARRAY_SIZE(lpc32xx_gpiochip); i++) {
> if (pdev->dev.of_node) {
> lpc32xx_gpiochip[i].chip.of_xlate = lpc32xx_of_xlate;
> @@ -527,3 +542,7 @@ static struct platform_driver lpc32xx_gpio_driver = {
> };
>
> module_platform_driver(lpc32xx_gpio_driver);
> +
> +MODULE_AUTHOR("Kevin Wells <kevin.wells@nxp.com>");
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("GPIO driver for LPC32xx SoC");
> --
> 2.20.0
>
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
From: Christoph Hellwig @ 2019-08-02 7:03 UTC (permalink / raw)
To: Takashi Iwai, iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Robin Murphy,
x86, linux-kernel, linux-m68k, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190725063401.29904-6-hch@lst.de>
Takashi,
any comments on the sounds/ side of this?
On Thu, Jul 25, 2019 at 08:34:01AM +0200, Christoph Hellwig wrote:
> Now that we never use a default ->mmap implementation, and non-coherent
> architectures can control the presence of ->mmap support by enabling
> ARCH_HAS_DMA_COHERENT_TO_PFN for the dma direct implementation there
> is no need for a global config option to control the availability
> of dma_common_mmap.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/Kconfig | 3 ---
> arch/c6x/Kconfig | 1 -
> arch/m68k/Kconfig | 1 -
> arch/microblaze/Kconfig | 1 -
> arch/parisc/Kconfig | 1 -
> arch/sh/Kconfig | 1 -
> arch/xtensa/Kconfig | 1 -
> kernel/dma/mapping.c | 4 ----
> sound/core/pcm_native.c | 10 +---------
> 9 files changed, 1 insertion(+), 22 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index a7b57dd42c26..ec2834206d08 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -790,9 +790,6 @@ config COMPAT_32BIT_TIME
> This is relevant on all 32-bit architectures, and 64-bit architectures
> as part of compat syscall handling.
>
> -config ARCH_NO_COHERENT_DMA_MMAP
> - bool
> -
> config ARCH_NO_PREEMPT
> bool
>
> diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
> index b4fb61c83494..e65e8d82442a 100644
> --- a/arch/c6x/Kconfig
> +++ b/arch/c6x/Kconfig
> @@ -20,7 +20,6 @@ config C6X
> select OF_EARLY_FLATTREE
> select GENERIC_CLOCKEVENTS
> select MODULES_USE_ELF_RELA
> - select ARCH_NO_COHERENT_DMA_MMAP
> select MMU_GATHER_NO_RANGE if MMU
>
> config MMU
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index c518d695c376..614b355ae338 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -8,7 +8,6 @@ config M68K
> select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
> select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
> - select ARCH_NO_COHERENT_DMA_MMAP if !MMU
> select ARCH_NO_PREEMPT if !COLDFIRE
> select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
> select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index d411de05b628..632c9477a0f6 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -9,7 +9,6 @@ config MICROBLAZE
> select ARCH_HAS_SYNC_DMA_FOR_CPU
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> select ARCH_MIGHT_HAVE_PC_PARPORT
> - select ARCH_NO_COHERENT_DMA_MMAP if !MMU
> select ARCH_WANT_IPC_PARSE_VERSION
> select BUILDTIME_EXTABLE_SORT
> select TIMER_OF
> diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
> index 6d732e451071..e9dd88b7f81e 100644
> --- a/arch/parisc/Kconfig
> +++ b/arch/parisc/Kconfig
> @@ -52,7 +52,6 @@ config PARISC
> select GENERIC_SCHED_CLOCK
> select HAVE_UNSTABLE_SCHED_CLOCK if SMP
> select GENERIC_CLOCKEVENTS
> - select ARCH_NO_COHERENT_DMA_MMAP
> select CPU_NO_EFFICIENT_FFS
> select NEED_DMA_MAP_STATE
> select NEED_SG_DMA_LENGTH
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index 6b1b5941b618..f356ee674d89 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -5,7 +5,6 @@ config SUPERH
> select ARCH_HAS_PTE_SPECIAL
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_MIGHT_HAVE_PC_PARPORT
> - select ARCH_NO_COHERENT_DMA_MMAP if !MMU
> select HAVE_PATA_PLATFORM
> select CLKDEV_LOOKUP
> select DMA_DECLARE_COHERENT
> diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
> index ebc135bda921..70653aed3005 100644
> --- a/arch/xtensa/Kconfig
> +++ b/arch/xtensa/Kconfig
> @@ -5,7 +5,6 @@ config XTENSA
> select ARCH_HAS_BINFMT_FLAT if !MMU
> select ARCH_HAS_SYNC_DMA_FOR_CPU
> select ARCH_HAS_SYNC_DMA_FOR_DEVICE
> - select ARCH_NO_COHERENT_DMA_MMAP if !MMU
> select ARCH_USE_QUEUED_RWLOCKS
> select ARCH_USE_QUEUED_SPINLOCKS
> select ARCH_WANT_FRAME_POINTERS
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index 7dff1829c8c5..815446f76995 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
> @@ -169,7 +169,6 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
> void *cpu_addr, dma_addr_t dma_addr, size_t size,
> unsigned long attrs)
> {
> -#ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
> unsigned long user_count = vma_pages(vma);
> unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> unsigned long off = vma->vm_pgoff;
> @@ -198,9 +197,6 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
>
> return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> user_count << PAGE_SHIFT, vma->vm_page_prot);
> -#else
> - return -ENXIO;
> -#endif /* !CONFIG_ARCH_NO_COHERENT_DMA_MMAP */
> }
>
> /**
> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> index 860543a4c840..2dadc708343a 100644
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -218,15 +218,7 @@ int snd_pcm_info_user(struct snd_pcm_substream *substream,
>
> static bool hw_support_mmap(struct snd_pcm_substream *substream)
> {
> - if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
> - return false;
> - /* architecture supports dma_mmap_coherent()? */
> -#if defined(CONFIG_ARCH_NO_COHERENT_DMA_MMAP) || !defined(CONFIG_HAS_DMA)
> - if (!substream->ops->mmap &&
> - substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
> - return false;
> -#endif
> - return true;
> + return substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP;
> }
>
> static int constrain_mask_params(struct snd_pcm_substream *substream,
> --
> 2.20.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
---end quoted text---
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 16/34] drivers/tee: convert put_page() to put_user_page*()
From: Jens Wiklander @ 2019-08-02 6:29 UTC (permalink / raw)
To: john.hubbard
Cc: linux-fbdev, Jan Kara, kvm, Dave Hansen, Dave Chinner, dri-devel,
linux-mm, sparclinux, Ira Weiny, Dan Williams, devel, rds-devel,
linux-rdma, x86, amd-gfx, Christoph Hellwig, Jason Gunthorpe,
xen-devel, devel, linux-media, John Hubbard, intel-gfx,
linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, Linux ARM, linux-nfs, netdev, LKML, linux-xfs,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-fsdevel,
Andrew Morton
In-Reply-To: <20190802022005.5117-17-jhubbard@nvidia.com>
On Fri, Aug 2, 2019 at 4:20 AM <john.hubbard@gmail.com> wrote:
>
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Jens Wiklander <jens.wiklander@linaro.org>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> drivers/tee/tee_shm.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
I suppose you're taking this via your own tree or such.
Thanks,
Jens
>
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 2da026fd12c9..c967d0420b67 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -31,16 +31,13 @@ static void tee_shm_release(struct tee_shm *shm)
>
> poolm->ops->free(poolm, shm);
> } else if (shm->flags & TEE_SHM_REGISTER) {
> - size_t n;
> int rc = teedev->desc->ops->shm_unregister(shm->ctx, shm);
>
> if (rc)
> dev_err(teedev->dev.parent,
> "unregister shm %p failed: %d", shm, rc);
>
> - for (n = 0; n < shm->num_pages; n++)
> - put_page(shm->pages[n]);
> -
> + put_user_pages(shm->pages, shm->num_pages);
> kfree(shm->pages);
> }
>
> @@ -313,16 +310,13 @@ struct tee_shm *tee_shm_register(struct tee_context *ctx, unsigned long addr,
> return shm;
> err:
> if (shm) {
> - size_t n;
> -
> if (shm->id >= 0) {
> mutex_lock(&teedev->mutex);
> idr_remove(&teedev->idr, shm->id);
> mutex_unlock(&teedev->mutex);
> }
> if (shm->pages) {
> - for (n = 0; n < shm->num_pages; n++)
> - put_page(shm->pages[n]);
> + put_user_pages(shm->pages, shm->num_pages);
> kfree(shm->pages);
> }
> }
> --
> 2.22.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: aspeed: Deprecate g[45]-style compatibles
From: Joel Stanley @ 2019-08-02 6:15 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-aspeed, Linus Walleij, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Rob Herring, Lee Jones, Linux ARM
In-Reply-To: <3691f6cb-2451-43f7-9f00-d5693071ba59@www.fastmail.com>
On Thu, 1 Aug 2019 at 05:45, Andrew Jeffery <andrew@aj.id.au> wrote:
>
>
>
> On Tue, 30 Jul 2019, at 10:27, Andrew Jeffery wrote:
> >
> >
> > On Tue, 30 Jul 2019, at 07:23, Linus Walleij wrote:
> > > On Wed, Jul 24, 2019 at 10:13 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> > >
> > > > It's probably best if we push the three patches all through one tree rather
> > > > than fragmenting. Is everyone happy if Joel applies them to the aspeed tree?
> > >
> > > If you are sure it will not collide with parallell work in the
> > > pinctrl tree, yes.
> > > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > >
> > > (If it does collide I'd prefer to take the pinctrl patches and fix the
> > > conflicts in my tree.)
> >
> > Fair enough, I don't know the answer so I'll poke around. I don't
> > really mind
> > where the series goes in, I just want to avoid landing only part of it
> > if I split it up.
>
> Okay, it currently conflicts with my cleanup-devicetree-warnings series.
>
> Joel, do you mind if Linus takes this series through the pinctrl tree, given
> the fix to the devicetrees is patch 1/3?
It depends if you plan more changes to that part of the device tree
this merge window :)
Linus, perhaps the safer option is for me to take 1/3 through my tree
and you can take the rest through yours?
Cheers,
Joel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 20/34] xen: convert put_page() to put_user_page*()
From: Juergen Gross @ 2019-08-02 6:10 UTC (permalink / raw)
To: John Hubbard, john.hubbard, Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Boris Ostrovsky, Dave Hansen,
Dave Chinner, dri-devel, linux-mm, sparclinux, Ira Weiny,
Dan Williams, devel, rds-devel, linux-rdma, x86, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, xen-devel, devel, linux-media,
intel-gfx, linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, linux-arm-kernel, linux-nfs, netdev, LKML, linux-xfs,
linux-crypto, linux-fsdevel
In-Reply-To: <d5140833-e9ee-beb5-ff0a-2d13a4fe819f@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]
On 02.08.19 07:48, John Hubbard wrote:
> On 8/1/19 9:36 PM, Juergen Gross wrote:
>> On 02.08.19 04:19, john.hubbard@gmail.com wrote:
>>> From: John Hubbard <jhubbard@nvidia.com>
> ...
>>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>>> index 2f5ce7230a43..29e461dbee2d 100644
>>> --- a/drivers/xen/privcmd.c
>>> +++ b/drivers/xen/privcmd.c
>>> @@ -611,15 +611,10 @@ static int lock_pages(
>>> static void unlock_pages(struct page *pages[], unsigned int nr_pages)
>>> {
>>> - unsigned int i;
>>> -
>>> if (!pages)
>>> return;
>>> - for (i = 0; i < nr_pages; i++) {
>>> - if (pages[i])
>>> - put_page(pages[i]);
>>> - }
>>> + put_user_pages(pages, nr_pages);
>>
>> You are not handling the case where pages[i] is NULL here. Or am I
>> missing a pending patch to put_user_pages() here?
>>
>
> Hi Juergen,
>
> You are correct--this no longer handles the cases where pages[i]
> is NULL. It's intentional, though possibly wrong. :)
>
> I see that I should have added my standard blurb to this
> commit description. I missed this one, but some of the other patches
> have it. It makes the following, possibly incorrect claim:
>
> "This changes the release code slightly, because each page slot in the
> page_list[] array is no longer checked for NULL. However, that check
> was wrong anyway, because the get_user_pages() pattern of usage here
> never allowed for NULL entries within a range of pinned pages."
>
> The way I've seen these page arrays used with get_user_pages(),
> things are either done single page, or with a contiguous range. So
> unless I'm missing a case where someone is either
>
> a) releasing individual pages within a range (and thus likely messing
> up their count of pages they have), or
>
> b) allocating two gup ranges within the same pages[] array, with a
> gap between the allocations,
>
> ...then it should be correct. If so, then I'll add the above blurb
> to this patch's commit description.
>
> If that's not the case (both here, and in 3 or 4 other patches in this
> series, then as you said, I should add NULL checks to put_user_pages()
> and put_user_pages_dirty_lock().
In this case it is not correct, but can easily be handled. The NULL case
can occur only in an error case with the pages array filled partially or
not at all.
I'd prefer something like the attached patch here.
Juergen
[-- Attachment #2: gup.patch --]
[-- Type: text/x-patch, Size: 2001 bytes --]
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 2f5ce7230a43..12bd3154126d 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -582,10 +582,11 @@ static long privcmd_ioctl_mmap_batch(
static int lock_pages(
struct privcmd_dm_op_buf kbufs[], unsigned int num,
- struct page *pages[], unsigned int nr_pages)
+ struct page *pages[], unsigned int *nr_pages)
{
- unsigned int i;
+ unsigned int i, free = *nr_pages;
+ *nr_pages = 0;
for (i = 0; i < num; i++) {
unsigned int requested;
int pinned;
@@ -593,35 +594,22 @@ static int lock_pages(
requested = DIV_ROUND_UP(
offset_in_page(kbufs[i].uptr) + kbufs[i].size,
PAGE_SIZE);
- if (requested > nr_pages)
+ if (requested > free)
return -ENOSPC;
pinned = get_user_pages_fast(
(unsigned long) kbufs[i].uptr,
- requested, FOLL_WRITE, pages);
+ requested, FOLL_WRITE, pages + *nr_pages);
if (pinned < 0)
return pinned;
- nr_pages -= pinned;
- pages += pinned;
+ free -= pinned;
+ *nr_pages += pinned;
}
return 0;
}
-static void unlock_pages(struct page *pages[], unsigned int nr_pages)
-{
- unsigned int i;
-
- if (!pages)
- return;
-
- for (i = 0; i < nr_pages; i++) {
- if (pages[i])
- put_page(pages[i]);
- }
-}
-
static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
{
struct privcmd_data *data = file->private_data;
@@ -681,11 +669,12 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
xbufs = kcalloc(kdata.num, sizeof(*xbufs), GFP_KERNEL);
if (!xbufs) {
+ nr_pages = 0;
rc = -ENOMEM;
goto out;
}
- rc = lock_pages(kbufs, kdata.num, pages, nr_pages);
+ rc = lock_pages(kbufs, kdata.num, pages, &nr_pages);
if (rc)
goto out;
@@ -699,7 +688,8 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
xen_preemptible_hcall_end();
out:
- unlock_pages(pages, nr_pages);
+ if (pages)
+ put_user_pages(pages, nr_pages);
kfree(xbufs);
kfree(pages);
kfree(kbufs);
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC-ish PATCH 00/17] Clean up ASPEED devicetree warnings
From: Joel Stanley @ 2019-08-02 5:51 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Mark Rutland, linux-aspeed, Linus Walleij, Corey Minyard,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, Xo Wang, Arnd Bergmann, Ken Chen, Adriana Kobylak,
open list:GPIO SUBSYSTEM, Rob Herring,
YangBrianC.W 楊嘉偉 TAO, openipmi-developer,
Alexander A. Filippov, Tao Ren, linux-kernel@vger.kernel.org,
yao.yuan, Patrick Venture, John Wang, Greg Kroah-Hartman,
Stefan M Schaeckeler, Haiyue Wang
In-Reply-To: <fd8e57f0-aee2-403e-b6fb-76d0c18fe306@www.fastmail.com>
On Tue, 30 Jul 2019 at 01:09, Andrew Jeffery <andrew@aj.id.au> wrote:
> > > The bang-for-buck is in fixing up the KCS bindings which removes all-but-two of
> > > the remaining warnings (which we can't feasibly remove), but doing so forces
> > > code changes (which I'd avoided up until this point).
> > >
> > > Reflecting broadly on the fixes, I think I've made a mistake way back by using
> > > syscon/simple-mfds to expose the innards of the SCU and LPC controllers in the
> > > devicetree. This series cleans up what's currently there, but I have half a
> > > mind to rev the SCU and LPC bindings to not use simple-mfd and instead have a
> > > driver implementation that uses `platform_device_register_full()` or similar to
> > > deal with the mess.
> > >
> > > Rob - I'm looking for your thoughts here and on the series, I've never felt
> > > entirely comfortable with what I cooked up. Your advice would be appreciated.
> >
> > The series generally looks fine to me from a quick scan. As far as
> > dropping 'simple-mfd', having less fine grained description in DT is
> > generally my preference. It comes down to whether what you have
> > defined is maintainable. As most of it is just additions, I think what
> > you have is fine. Maybe keep all this in mind for the next chip
> > depending how the SCU and LPC change.
>
> Okay, I think the timing of that suggestion is good given where things are with
> the AST2600. I'll keep that in mind.
>
> Consensus so far seems to be that the series is fine. I'll split it up and send out
> the sub-series to the relevant lists with the acks accumulated here.
The series look good. I suggest posting the KCS bindings and driver
changes as their own series to go through the IPMI tree.
Please add my tag to all the patches except the OCC one, which I need
to do some investigation in to.
Reviewed-by: Joel Stanley <joel@jms.id.au>
The others can go via the aspeed tree. Perhaps post them as their own
series too so I don't get confused and apply the wrong ones. That way
if Rob wants to send his reviewed-by he can.
Cheers,
Joel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 20/34] xen: convert put_page() to put_user_page*()
From: John Hubbard @ 2019-08-02 5:48 UTC (permalink / raw)
To: Juergen Gross, john.hubbard, Andrew Morton
Cc: linux-fbdev, Jan Kara, kvm, Boris Ostrovsky, Dave Hansen,
Dave Chinner, dri-devel, linux-mm, sparclinux, Ira Weiny,
Dan Williams, devel, rds-devel, linux-rdma, x86, amd-gfx,
Christoph Hellwig, Jason Gunthorpe, xen-devel, devel, linux-media,
intel-gfx, linux-block, Jérôme Glisse, linux-rpi-kernel,
ceph-devel, linux-arm-kernel, linux-nfs, netdev, LKML, linux-xfs,
linux-crypto, linux-fsdevel
In-Reply-To: <4471e9dc-a315-42c1-0c3c-55ba4eeeb106@suse.com>
On 8/1/19 9:36 PM, Juergen Gross wrote:
> On 02.08.19 04:19, john.hubbard@gmail.com wrote:
>> From: John Hubbard <jhubbard@nvidia.com>
...
>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
>> index 2f5ce7230a43..29e461dbee2d 100644
>> --- a/drivers/xen/privcmd.c
>> +++ b/drivers/xen/privcmd.c
>> @@ -611,15 +611,10 @@ static int lock_pages(
>> static void unlock_pages(struct page *pages[], unsigned int nr_pages)
>> {
>> - unsigned int i;
>> -
>> if (!pages)
>> return;
>> - for (i = 0; i < nr_pages; i++) {
>> - if (pages[i])
>> - put_page(pages[i]);
>> - }
>> + put_user_pages(pages, nr_pages);
>
> You are not handling the case where pages[i] is NULL here. Or am I
> missing a pending patch to put_user_pages() here?
>
Hi Juergen,
You are correct--this no longer handles the cases where pages[i]
is NULL. It's intentional, though possibly wrong. :)
I see that I should have added my standard blurb to this
commit description. I missed this one, but some of the other patches
have it. It makes the following, possibly incorrect claim:
"This changes the release code slightly, because each page slot in the
page_list[] array is no longer checked for NULL. However, that check
was wrong anyway, because the get_user_pages() pattern of usage here
never allowed for NULL entries within a range of pinned pages."
The way I've seen these page arrays used with get_user_pages(),
things are either done single page, or with a contiguous range. So
unless I'm missing a case where someone is either
a) releasing individual pages within a range (and thus likely messing
up their count of pages they have), or
b) allocating two gup ranges within the same pages[] array, with a
gap between the allocations,
...then it should be correct. If so, then I'll add the above blurb
to this patch's commit description.
If that's not the case (both here, and in 3 or 4 other patches in this
series, then as you said, I should add NULL checks to put_user_pages()
and put_user_pages_dirty_lock().
thanks,
--
John Hubbard
NVIDIA
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] efi/arm: fix allocation failure when reserving the kernel base
From: Chester Lin @ 2019-08-02 5:38 UTC (permalink / raw)
To: linux@armlinux.org.uk, ard.biesheuvel@linaro.org,
akpm@linux-foundation.org, rppt@linux.ibm.com, ren_guo@c-sky.com,
Juergen Gross, geert@linux-m68k.org, mingo@kernel.org
Cc: Joey Lee, linux-efi@vger.kernel.org, guillaume.gardet@arm.com,
linux-kernel@vger.kernel.org, Chester Lin, Gary Lin,
linux-arm-kernel@lists.infradead.org
In some cases the arm32 efistub could fail to allocate memory for
uncompressed kernel. For example, we got the following error message when
verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
EFI stub: Booting Linux Kernel...
EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
EFI stub: ERROR: Failed to relocate kernel
After checking the EFI memory map we found that the first page [0 - 0xfff]
had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
set the dram base at 0, which was actually in a reserved region.
grub> lsefimmap
Type Physical start - end #Pages Size Attributes
reserved 0000000000000000-0000000000000fff 00000001 4KiB WB
conv-mem 0000000000001000-0000000007ef5fff 00007ef5 130004KiB WB
RT-data 0000000007ef6000-0000000007f09fff 00000014 80KiB RT WB
conv-mem 0000000007f0a000-000000002d871fff 00025968 615840KiB WB
.....
To avoid a reserved address, we have to ignore the memory regions which are
marked as EFI_RESERVED_TYPE, and only conventional memory regions can be
chosen. If the region before the kernel base is unaligned, it will be
marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit
will not be sticked with a very low address such as 0x1000.
Signed-off-by: Chester Lin <clin@suse.com>
---
arch/arm/mm/mmu.c | 3 ++
drivers/firmware/efi/libstub/arm32-stub.c | 43 ++++++++++++++++++-----
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f3ce34113f89..909b11ba48d8 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
phys_addr_t block_start = reg->base;
phys_addr_t block_end = reg->base + reg->size;
+ if (memblock_is_nomap(reg))
+ continue;
+
if (reg->base < vmalloc_limit) {
if (block_end > lowmem_limit)
/*
diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
index e8f7aefb6813..10d33d36df00 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -128,7 +128,7 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
for (l = 0; l < map_size; l += desc_size) {
efi_memory_desc_t *desc;
- u64 start, end;
+ u64 start, end, spare, kernel_base;
desc = (void *)memory_map + l;
start = desc->phys_addr;
@@ -144,27 +144,52 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
case EFI_BOOT_SERVICES_DATA:
/* Ignore types that are released to the OS anyway */
continue;
-
+ case EFI_RESERVED_TYPE:
+ /* Ignore reserved regions */
+ continue;
case EFI_CONVENTIONAL_MEMORY:
/*
* Reserve the intersection between this entry and the
* region.
*/
start = max(start, (u64)dram_base);
- end = min(end, (u64)dram_base + MAX_UNCOMP_KERNEL_SIZE);
+ kernel_base = round_up(start, PMD_SIZE);
+ spare = kernel_base - start;
+ end = min(end, kernel_base + MAX_UNCOMP_KERNEL_SIZE);
+
+ status = efi_call_early(allocate_pages,
+ EFI_ALLOCATE_ADDRESS,
+ EFI_LOADER_DATA,
+ MAX_UNCOMP_KERNEL_SIZE / EFI_PAGE_SIZE,
+ &kernel_base);
+ if (status != EFI_SUCCESS) {
+ pr_efi_err(sys_table_arg,
+ "reserve_kernel_base: alloc failed.\n");
+ goto out;
+ }
+ *reserve_addr = kernel_base;
+ if (!spare)
+ break;
+ /*
+ * If there's a gap between start and kernel_base,
+ * it needs be reserved so that the memblock_limit
+ * will not fall on a very low address when running
+ * adjust_lowmem_bounds(), wchich could eventually
+ * cause CMA reservation issue.
+ */
status = efi_call_early(allocate_pages,
EFI_ALLOCATE_ADDRESS,
- EFI_LOADER_DATA,
- (end - start) / EFI_PAGE_SIZE,
+ EFI_RESERVED_TYPE,
+ spare / EFI_PAGE_SIZE,
&start);
if (status != EFI_SUCCESS) {
pr_efi_err(sys_table_arg,
- "reserve_kernel_base(): alloc failed.\n");
+ "reserve spare-region failed\n");
goto out;
}
- break;
+ break;
case EFI_LOADER_CODE:
case EFI_LOADER_DATA:
/*
@@ -220,7 +245,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
*image_size = image->image_size;
status = efi_relocate_kernel(sys_table, image_addr, *image_size,
*image_size,
- dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
+ *reserve_addr + MAX_UNCOMP_KERNEL_SIZE, 0);
if (status != EFI_SUCCESS) {
pr_efi_err(sys_table, "Failed to relocate kernel.\n");
efi_free(sys_table, *reserve_size, *reserve_addr);
@@ -233,7 +258,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
* in memory. The kernel determines the base of DRAM from the
* address at which the zImage is loaded.
*/
- if (*image_addr + *image_size > dram_base + ZIMAGE_OFFSET_LIMIT) {
+ if (*image_addr + *image_size > *reserve_addr + ZIMAGE_OFFSET_LIMIT) {
pr_efi_err(sys_table, "Failed to relocate kernel, no low memory available.\n");
efi_free(sys_table, *reserve_size, *reserve_addr);
*reserve_size = 0;
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] ARM: dts: aspeed: Add Facebook Wedge100 BMC
From: Tao Ren @ 2019-08-02 5:31 UTC (permalink / raw)
To: Joel Stanley
Cc: Mark Rutland, devicetree, linux-aspeed@lists.ozlabs.org,
Andrew Jeffery, OpenBMC Maillist, Linux Kernel Mailing List,
Rob Herring, Linux ARM
In-Reply-To: <CACPK8Xc-vjJJ_kbe_KGss+RDMdhRVw-YDj9Cdux8iERSvE0_GQ@mail.gmail.com>
On 8/1/19, 10:26 PM, "Joel Stanley" <joel@jms.id.au> wrote:
> I've applied both of these to the aspeed tree for 5.4.
Thank you Joel.
Cheers,
Tao
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: aspeed: Add Facebook Wedge100 BMC
From: Joel Stanley @ 2019-08-02 5:25 UTC (permalink / raw)
To: Tao Ren
Cc: Mark Rutland, devicetree, linux-aspeed@lists.ozlabs.org,
Andrew Jeffery, OpenBMC Maillist, Linux Kernel Mailing List,
Rob Herring, Linux ARM
In-Reply-To: <606273F4-E021-4AAF-9F59-F363E4FFF92A@fb.com>
On Fri, 2 Aug 2019 at 05:20, Tao Ren <taoren@fb.com> wrote:
>
> On 8/1/19, 9:21 PM, "Joel Stanley" <joel@jms.id.au> wrote:
>
> > On Fri, 2 Aug 2019 at 04:10, Tao Ren <taoren@fb.com> wrote:
> >>
> >> Add initial version of device tree for Facebook Wedge100 AST2400 BMC
> >> platform.
> >>
> >> Signed-off-by: Tao Ren <taoren@fb.com>
> >> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> >> ---
> >> Changes in v2:
> >> - remove "debug" from bootargs.
> >
> > Thanks. I applied wedge40 and then this one fails to apply due to
> > conflicts in the Makefile. Next time you have two patches, send them
> > as a series they apply one atop the other.
>
> I thought about asking you if I should send them as a series although they are logically independent patches..
> Sorry about that and I will do so for future patches.
>
> > The naming of these two files suggests they come from a family. I
> > noticed there's very minor differences, a pca9548 switch and the use
> > of a watchdog.
> >
> > Are these device trees complete? If yes, do you think it's worthwhile
> > to have a common wedge description in eg.
> > aspeed-bmc-facebook-wedge.dtsi, and put the unique description in
> > respective dts board files?
> >
> > The upside of this is reduced duplication.
> >
> > If you have a reason not to, then that is okay and we can leave it as
> > you submitted them.
>
> Thank you for the suggestion. I'm also considering moving common stuff into "dtsi" file, but let me take care of it in a separate patch, mainly because:
> 1) I have one more BMC platform (galaxy100) which is also similar to wedge.
> I haven't started the platform, but once I have galaxy100 device tree ready, it would be easier for me to extract common part.
> 2) the device tree is not complete yet.
> For example, all the i2c devices are still created from userspace.
> I'm trying to move the logic from userspace to device tree but I haven't decided what to do with those cpld/fpga devices.
Okay, thanks.
I've applied both of these to the aspeed tree for 5.4.
Cheers,
Joel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64: zynqmp: Add ZynqMP SDHCI compatible string
From: Michal Simek @ 2019-08-02 5:23 UTC (permalink / raw)
To: Manish Narani, robh+dt, michal.simek, mark.rutland, sudeep.holla,
rrichter, gregory.clement, amit.kucheria
Cc: devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1561959452-22915-1-git-send-email-manish.narani@xilinx.com>
On 01. 07. 19 7:37, Manish Narani wrote:
> Add the new compatible string for ZynqMP SD Host Controller for its use
> in the Arasan SDHCI driver for some of the ZynqMP specific operations.
> Add required properties for the same.
>
> Signed-off-by: Manish Narani <manish.narani@xilinx.com>
> ---
> This patch depends on the below series of patches:
> https://lkml.org/lkml/2019/7/1/25
>
> Changes in v2:
> - Added clock-names for SD card clocks for getting clocks in the driver
Just for a record. I am waiting till binding is Acked.
M
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: aspeed: Add Facebook Wedge100 BMC
From: Tao Ren @ 2019-08-02 5:20 UTC (permalink / raw)
To: Joel Stanley
Cc: Mark Rutland, devicetree, linux-aspeed@lists.ozlabs.org,
Andrew Jeffery, OpenBMC Maillist, Linux Kernel Mailing List,
Rob Herring, Linux ARM
In-Reply-To: <CACPK8XcuwNE3aBrsgn-paTZt-EtF6pc6WwYBQef5xc7157bk2g@mail.gmail.com>
On 8/1/19, 9:21 PM, "Joel Stanley" <joel@jms.id.au> wrote:
> On Fri, 2 Aug 2019 at 04:10, Tao Ren <taoren@fb.com> wrote:
>>
>> Add initial version of device tree for Facebook Wedge100 AST2400 BMC
>> platform.
>>
>> Signed-off-by: Tao Ren <taoren@fb.com>
>> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
>> ---
>> Changes in v2:
>> - remove "debug" from bootargs.
>
> Thanks. I applied wedge40 and then this one fails to apply due to
> conflicts in the Makefile. Next time you have two patches, send them
> as a series they apply one atop the other.
I thought about asking you if I should send them as a series although they are logically independent patches..
Sorry about that and I will do so for future patches.
> The naming of these two files suggests they come from a family. I
> noticed there's very minor differences, a pca9548 switch and the use
> of a watchdog.
>
> Are these device trees complete? If yes, do you think it's worthwhile
> to have a common wedge description in eg.
> aspeed-bmc-facebook-wedge.dtsi, and put the unique description in
> respective dts board files?
>
> The upside of this is reduced duplication.
>
> If you have a reason not to, then that is okay and we can leave it as
> you submitted them.
Thank you for the suggestion. I'm also considering moving common stuff into "dtsi" file, but let me take care of it in a separate patch, mainly because:
1) I have one more BMC platform (galaxy100) which is also similar to wedge.
I haven't started the platform, but once I have galaxy100 device tree ready, it would be easier for me to extract common part.
2) the device tree is not complete yet.
For example, all the i2c devices are still created from userspace.
I'm trying to move the logic from userspace to device tree but I haven't decided what to do with those cpld/fpga devices.
Cheers,
Tao
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mailbox: zynqmp-ipi-mailbox: Add of_node_put() before goto
From: Michal Simek @ 2019-08-02 5:12 UTC (permalink / raw)
To: Nishka Dasgupta, Michal Simek, jassisinghbrar, linux-kernel,
linux-arm-kernel
In-Reply-To: <ab6db31d-ff16-5a32-f097-347daa6b98fc@gmail.com>
On 02. 08. 19 6:59, Nishka Dasgupta wrote:
> On 31/07/19 7:51 PM, Michal Simek wrote:
>> On 31. 07. 19 15:06, Nishka Dasgupta wrote:
>>> On 31/07/19 2:01 PM, Michal Simek wrote:
>>>> On 09. 07. 19 19:28, Nishka Dasgupta wrote:
>>>>> Each iteration of for_each_available_child_of_node puts the previous
>>>>> node, but in the case of a goto from the middle of the loop, there is
>>>>> no put, thus causing a memory leak. Hence add an of_node_put before
>>>>> the
>>>>> goto.
>>>>> Issue found with Coccinelle.
>>>>>
>>>>> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
>>>>> ---
>>>>> drivers/mailbox/zynqmp-ipi-mailbox.c | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c
>>>>> b/drivers/mailbox/zynqmp-ipi-mailbox.c
>>>>> index 86887c9a349a..bd80d4c10ec2 100644
>>>>> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
>>>>> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
>>>>> @@ -661,6 +661,7 @@ static int zynqmp_ipi_probe(struct
>>>>> platform_device *pdev)
>>>>> if (ret) {
>>>>> dev_err(dev, "failed to probe subdev.\n");
>>>>> ret = -EINVAL;
>>>>> + of_node_put(nc);
>>>>> goto free_mbox_dev;
>>>>> }
>>>>> mbox++;
>>>>>
>>>>
>>>> Patch is good but when you are saying that this was found by Coccinelle
>>>> then it should be added as script to kernel to detect it.
>>>
>>> This particular patch was suggested by a script I did not write myself;
>>> someone else wrote it and sent it to me. How should I proceed in this
>>> case?
>>
>> You can ask him to submit it to kernel.
>> Or you can take it, keep his authorship and send it to:
>
> I have asked her to submit this script, thank you. Will I need to
> resubmit this patch, however?
I will let Jassi to decide.
Thanks,
Michal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mailbox: zynqmp-ipi-mailbox: Add of_node_put() before goto
From: Nishka Dasgupta @ 2019-08-02 4:59 UTC (permalink / raw)
To: Michal Simek, jassisinghbrar, linux-kernel, linux-arm-kernel
In-Reply-To: <c0be80c9-16ef-fe03-ae3b-a7d3d1a2ede8@xilinx.com>
On 31/07/19 7:51 PM, Michal Simek wrote:
> On 31. 07. 19 15:06, Nishka Dasgupta wrote:
>> On 31/07/19 2:01 PM, Michal Simek wrote:
>>> On 09. 07. 19 19:28, Nishka Dasgupta wrote:
>>>> Each iteration of for_each_available_child_of_node puts the previous
>>>> node, but in the case of a goto from the middle of the loop, there is
>>>> no put, thus causing a memory leak. Hence add an of_node_put before the
>>>> goto.
>>>> Issue found with Coccinelle.
>>>>
>>>> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
>>>> ---
>>>> drivers/mailbox/zynqmp-ipi-mailbox.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/mailbox/zynqmp-ipi-mailbox.c
>>>> b/drivers/mailbox/zynqmp-ipi-mailbox.c
>>>> index 86887c9a349a..bd80d4c10ec2 100644
>>>> --- a/drivers/mailbox/zynqmp-ipi-mailbox.c
>>>> +++ b/drivers/mailbox/zynqmp-ipi-mailbox.c
>>>> @@ -661,6 +661,7 @@ static int zynqmp_ipi_probe(struct
>>>> platform_device *pdev)
>>>> if (ret) {
>>>> dev_err(dev, "failed to probe subdev.\n");
>>>> ret = -EINVAL;
>>>> + of_node_put(nc);
>>>> goto free_mbox_dev;
>>>> }
>>>> mbox++;
>>>>
>>>
>>> Patch is good but when you are saying that this was found by Coccinelle
>>> then it should be added as script to kernel to detect it.
>>
>> This particular patch was suggested by a script I did not write myself;
>> someone else wrote it and sent it to me. How should I proceed in this case?
>
> You can ask him to submit it to kernel.
> Or you can take it, keep his authorship and send it to:
I have asked her to submit this script, thank you. Will I need to
resubmit this patch, however?
Regards,
Nishka
> ./scripts/get_maintainer.pl -f scripts/coccinelle/
> Julia Lawall <Julia.Lawall@lip6.fr> (supporter:COCCINELLE/Semantic
> Patches (SmPL))
> Gilles Muller <Gilles.Muller@lip6.fr> (supporter:COCCINELLE/Semantic
> Patches (SmPL))
> Nicolas Palix <nicolas.palix@imag.fr> (supporter:COCCINELLE/Semantic
> Patches (SmPL))
> Michal Marek <michal.lkml@markovi.net> (supporter:COCCINELLE/Semantic
> Patches (SmPL))
> cocci@systeme.lip6.fr (moderated list:COCCINELLE/Semantic Patches (SmPL))
> linux-kernel@vger.kernel.org (open list)
>
> Thanks,
> Michal
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] hwrng: Use device-managed registration API
From: Herbert Xu @ 2019-08-02 4:55 UTC (permalink / raw)
To: Chuhong Yuan
Cc: Alexandre Belloni, Deepak Saxena, Benjamin Herrenschmidt,
linux-kernel, Arnd Bergmann, Greg Kroah-Hartman,
Łukasz Stelmach, Krzysztof Kozlowski, Patrice Chotard,
linux-samsung-soc, Ludovic Desroches, Kukjin Kim, Paul Mackerras,
Michael Ellerman, Matt Mackall, linuxppc-dev, linux-arm-kernel,
linux-crypto
In-Reply-To: <20190725080155.19875-1-hslester96@gmail.com>
On Thu, Jul 25, 2019 at 04:01:55PM +0800, Chuhong Yuan wrote:
> Use devm_hwrng_register to simplify the implementation.
> Manual unregistration and some remove functions can be
> removed now.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
> drivers/char/hw_random/atmel-rng.c | 3 +--
> drivers/char/hw_random/cavium-rng-vf.c | 11 +----------
> drivers/char/hw_random/exynos-trng.c | 3 +--
> drivers/char/hw_random/n2-drv.c | 4 +---
> drivers/char/hw_random/nomadik-rng.c | 3 +--
> drivers/char/hw_random/omap-rng.c | 3 +--
> drivers/char/hw_random/powernv-rng.c | 10 +---------
> drivers/char/hw_random/st-rng.c | 4 +---
> drivers/char/hw_random/xgene-rng.c | 4 +---
> 9 files changed, 9 insertions(+), 36 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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