* [PATCH] arm64: use generic free_initrd_mem()
From: Mike Rapoport @ 2019-09-16 7:21 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland
Cc: linux-kernel, linux-arm-kernel, Mike Rapoport
From: Mike Rapoport <rppt@linux.ibm.com>
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page allocator and the memblock.reserved is unused, so there is no
point to update it.
Without the memblock_free() call the only difference between arm64 and the
generic versions of free_initrd_mem() is the memory poisoning. Switching
arm64 to the generic version will enable the poisoning.
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
I've boot tested it on qemu and I've checked that kexec works.
arch/arm64/mm/init.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3c7952..8ad2934 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -567,14 +567,6 @@ void free_initmem(void)
unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
}
-#ifdef CONFIG_BLK_DEV_INITRD
-void __init free_initrd_mem(unsigned long start, unsigned long end)
-{
- free_reserved_area((void *)start, (void *)end, 0, "initrd");
- memblock_free(__virt_to_phys(start), end - start);
-}
-#endif
-
/*
* Dump out memory limit information on panic.
*/
--
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
* Re: [PATCH v3] net: stmmac: socfpga: re-use the `interface` parameter from platform data
From: David Miller @ 2019-09-16 7:22 UTC (permalink / raw)
To: alexandru.ardelean
Cc: alexandre.torgue, netdev, linux-kernel, joabreu, mcoquelin.stm32,
peppe.cavallaro, linux-stm32, linux-arm-kernel
In-Reply-To: <20190916070400.18721-1-alexandru.ardelean@analog.com>
From: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date: Mon, 16 Sep 2019 10:04:00 +0300
> The socfpga sub-driver defines an `interface` field in the `socfpga_dwmac`
> struct and parses it on init.
>
> The shared `stmmac_probe_config_dt()` function also parses this from the
> device-tree and makes it available on the returned `plat_data` (which is
> the same data available via `netdev_priv()`).
>
> All that's needed now is to dig that information out, via some
> `dev_get_drvdata()` && `netdev_priv()` calls and re-use it.
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Applied.
_______________________________________________
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 v3] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: Robin Gong @ 2019-09-16 7:45 UTC (permalink / raw)
To: robin, Dmitry Torokhov
Cc: Shawn Guo, Marco Felsch, linux-kernel @ vger . kernel . org,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Adam Ford, linux-arm-kernel @ lists . infradead . org
In-Reply-To: <803592d161b9ca75d6ac1c2c54e891a1@protonic.nl>
On 2019/9/13 15:31 robin <robin@protonic.nl> wrote:>
> Hi Dmitry,
>
> On 2019-09-12 22:13, Dmitry Torokhov wrote:
> > Hi Robin,
> >
> > On Wed, Sep 04, 2019 at 06:23:29AM +0000, Robin van der Gracht wrote:
> >> The first generation i.MX6 processors does not send an interrupt when
> >> the power key is pressed. It sends a power down request interrupt if
> >> the key is released before a hard shutdown (5 second press). This
> >> should allow software to bring down the SoC safely.
> >>
> >> For this driver to work as a regular power key with the older SoCs,
> >> we need to send a keypress AND release when we get the power down
> >> request irq.
> >>
> >> Signed-off-by: Robin van der Gracht <robin@protonic.nl>
> >> ---
> >> @@ -67,13 +83,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int
> >> irq, void *dev_id) {
> >> struct platform_device *pdev = dev_id;
> >> struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> >> + unsigned long expire = jiffies;
> >> u32 lp_status;
> >>
> >> pm_wakeup_event(pdata->input->dev.parent, 0);
> >>
> >> regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> >> - if (lp_status & SNVS_LPSR_SPO)
> >> - mod_timer(&pdata->check_timer, jiffies +
> >> msecs_to_jiffies(DEBOUNCE_TIME));
> >> + if (lp_status & SNVS_LPSR_SPO) {
> >> + if (pdata->minor_rev > 0)
> >> + expire = jiffies + msecs_to_jiffies(DEBOUNCE_TIME);
> >> + mod_timer(&pdata->check_timer, expire);
> >
> > Why do we even need to fire the timer in case of the first generation
> > hardware? Just send press and release events directly from the ISR.
That timer looks like a software debounce to prevent unexpected and
meaningless interrupt/event caused by quick press/release.
>
> Robin Gong proposed to move the code to imx_imx_snvs_check_for_events()
> to improve readability and unload the ISR.
>
> But since I, eventually, couldn't use the existing handling in
> imx_imx_snvs_check_for_events(), I do see why you're asking.
>
> I'll move the code to the ISR and submit a new patch.
>
> Robin van der Gracht
_______________________________________________
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/6] ARM, arm64: Remove arm_pm_restart()
From: Arnd Bergmann @ 2019-09-16 7:49 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Thierry Reding, linux-kernel@vger.kernel.org, Linux ARM
In-Reply-To: <20190914152544.GA17499@roeck-us.net>
On Sat, Sep 14, 2019 at 5:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On Mon, Jan 30, 2017 at 12:05:06PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Hi everyone,
> >
> > This small series is preparatory work for a series that I'm working on
> > which attempts to establish a formal framework for system restart and
> > power off.
> >
> > Guenter has done a lot of good work in this area, but it never got
> > merged. I think this set is a valuable addition to the kernel because
> > it converts all odd providers to the established mechanism for restart.
> >
> > Since this is stretched across both 32-bit and 64-bit ARM, as well as
> > PSCI, and given the SoC/board level of functionality, I think it might
> > make sense to take this through the ARM SoC tree in order to simplify
> > the interdependencies. But it should also be possible to take patches
> > 1-4 via their respective trees this cycle and patches 5-6 through the
> > ARM and arm64 trees for the next cycle, if that's preferred.
> >
>
> We tried this twice now, and it seems to go nowhere. What does it take
> to get it applied ?
Can you send a pull request to soc@kernel.org after the merge window,
with everyone else on Cc? If nobody objects, I'll merge it through
the soc tree.
Arnd
_______________________________________________
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 v3 12/14] drm/mediatek: Add pm runtime support for ovl and rdma
From: CK Hu @ 2019-09-16 7:55 UTC (permalink / raw)
To: Yong Wu
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, Tomasz Figa, Joerg Roedel, Will Deacon,
linux-kernel, Evan Green, chao.hao, iommu, Rob Herring,
linux-mediatek, Yongqiang Niu, Matthias Brugger, ming-fan.chen,
anan.sun, Robin Murphy, Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <1567503456-24725-13-git-send-email-yong.wu@mediatek.com>
Hi, Yong:
On Tue, 2019-09-03 at 17:37 +0800, Yong Wu wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> Display use the dispsys device to call pm_rumtime_get_sync before.
> This patch add pm_runtime_xx with ovl and rdma device which has linked
> with larb0, then it will enable the correpsonding larb0 clock
> automatically by the device link.
This patch should be applied before "drm/mediatek: Get rid of
mtk_smi_larb_get/put". If before that patch, this patch is a preparation
of that patch. If after that patch, this patch is a bug fix of that
patch. Why let bug happen?
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +++++
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +++++
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 ++++++++++++++++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 9 +++++++++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> 5 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index c4f07c2..51958cf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -9,6 +9,7 @@
> #include <linux/of_device.h>
> #include <linux/of_irq.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>
> #include "mtk_drm_crtc.h"
> #include "mtk_drm_ddp_comp.h"
> @@ -300,6 +301,8 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
> return ret;
> }
>
> + pm_runtime_enable(dev);
> +
> ret = component_add(dev, &mtk_disp_ovl_component_ops);
> if (ret)
> dev_err(dev, "Failed to add component: %d\n", ret);
This error should do some error handling to undo pm_runtime_enable().
> @@ -311,6 +314,8 @@ static int mtk_disp_ovl_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_ovl_component_ops);
>
> + pm_runtime_disable(&pdev->dev);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 9a6f0a2..15e5c3a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -9,6 +9,7 @@
> #include <linux/of_device.h>
> #include <linux/of_irq.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>
> #include "mtk_drm_crtc.h"
> #include "mtk_drm_ddp_comp.h"
> @@ -306,6 +307,8 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, priv);
>
> + pm_runtime_enable(dev);
> +
> ret = component_add(dev, &mtk_disp_rdma_component_ops);
> if (ret)
> dev_err(dev, "Failed to add component: %d\n", ret);
Ditto.
> @@ -317,6 +320,8 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
> {
> component_del(&pdev->dev, &mtk_disp_rdma_component_ops);
>
> + pm_runtime_disable(&pdev->dev);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index c1e891e..daf002e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -358,13 +358,21 @@ static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> int ret;
>
> DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
>
> + ret = pm_runtime_get_sync(comp->dev);
> + if (ret < 0)
> + DRM_DEV_ERROR(comp->dev, "Failed to enable power domain: %d\n",
> + ret);
> +
> ret = mtk_crtc_ddp_hw_init(mtk_crtc);
> - if (ret)
> + if (ret) {
> + pm_runtime_put(comp->dev);
> return;
> + }
>
> drm_crtc_vblank_on(crtc);
> mtk_crtc->enabled = true;
> @@ -374,7 +382,8 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
> {
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> - int i;
> + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> + int i, ret;
>
> DRM_DEBUG_DRIVER("%s %d\n", __func__, crtc->base.id);
> if (!mtk_crtc->enabled)
> @@ -398,6 +407,11 @@ static void mtk_drm_crtc_atomic_disable(struct drm_crtc *crtc,
> mtk_crtc_ddp_hw_fini(mtk_crtc);
>
> mtk_crtc->enabled = false;
> +
> + ret = pm_runtime_put(comp->dev);
> + if (ret < 0)
> + DRM_DEV_ERROR(comp->dev, "Failed to disable power domain: %d\n",
> + ret);
> }
>
> static void mtk_drm_crtc_atomic_begin(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 7dc8496..c45e1f0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -256,6 +256,8 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
> struct mtk_ddp_comp *comp, enum mtk_ddp_comp_id comp_id,
> const struct mtk_ddp_comp_funcs *funcs)
> {
> + struct platform_device *comp_pdev;
> +
> if (comp_id < 0 || comp_id >= DDP_COMPONENT_ID_MAX)
> return -EINVAL;
>
> @@ -282,6 +284,13 @@ int mtk_ddp_comp_init(struct device *dev, struct device_node *node,
> if (IS_ERR(comp->clk))
> return PTR_ERR(comp->clk);
>
> + comp_pdev = of_find_device_by_node(node);
> + if (!comp_pdev) {
> + dev_err(dev, "Waiting for device %s\n", node->full_name);
> + return -EPROBE_DEFER;
> + }
> + comp->dev = &comp_pdev->dev;
This should be
comp->dev = dev;
Regards,
CK
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 108de60..d1838a8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -83,6 +83,7 @@ struct mtk_ddp_comp {
> struct clk *clk;
> void __iomem *regs;
> int irq;
> + struct device *dev;
> enum mtk_ddp_comp_id id;
> const struct mtk_ddp_comp_funcs *funcs;
> };
_______________________________________________
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/4] Fix UART DMA freezes for iMX6
From: Robin Gong @ 2019-09-16 8:02 UTC (permalink / raw)
To: Philipp Puschmann, linux-kernel@vger.kernel.org
Cc: linux-serial@vger.kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, jslaby@suse.com, vkoul@kernel.org,
dl-linux-imx, kernel@pengutronix.de, gregkh@linuxfoundation.org,
dmaengine@vger.kernel.org, dan.j.williams@intel.com,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190911144943.21554-1-philipp.puschmann@emlix.com>
On 2019/9/11 Philipp Puschmann <philipp.puschmann@emlix.com> wrote:
> For some years and since many kernel versions there are reports that RX
> UART DMA channel stops working at one point. So far the usual workaround
> was to disable RX DMA. This patches try to fix the underlying problem.
>
> When a running sdma script does not find any usable destination buffer to put
> its data into it just leads to stopping the channel being scheduled again. As
> solution we we manually retrigger the sdma script for this channel and by this
> dissolve the freeze.
>
> While this seems to work fine so far a further patch in this series increases the
> number of RX DMA periods for UART to reduce use cases running into such a
> situation.
>
> This patch series was tested with the current kernel and backported to kernel
> 4.15 with a special use case using a WL1837MOD via UART and provoking the
Hi Philipp, Could your Bluetooth issue be reproduce on latest linux-next? Or did
your kernel which can be reproduced include the below patch?
commit d1a792f3b4072bfac4150bb62aa34917b77fdb6d
Author: Russell King - ARM Linux <linux@arm.linux.org.uk>
Date: Wed Jun 25 13:00:33 2014 +0100
Update imx-sdma cyclic handling to report residue
> hanging of UART RX DMA within seconds after starting a test application.
> It resulted in well known
> "Bluetooth: hci0: command 0x0408 tx timeout"
> errors and complete stop of UART data reception. Our Bluetooth traffic
> consists of many independent small packets, mostly only a few bytes, causing
> high usage of periods.
>
>
> Philipp Puschmann (4):
> dmaengine: imx-sdma: fix buffer ownership
> dmaengine: imx-sdma: fix dma freezes
> serial: imx: adapt rx buffer and dma periods
> dmaengine: imx-sdma: drop redundant variable
>
> drivers/dma/imx-sdma.c | 32 ++++++++++++++++++++++----------
> drivers/tty/serial/imx.c | 5 ++---
> 2 files changed, 24 insertions(+), 13 deletions(-)
>
> --
> 2.23.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] mfd: mt6360: add pmic mt6360 driver
From: Lee Jones @ 2019-09-16 8:06 UTC (permalink / raw)
To: Matthias Brugger
Cc: gene_chen, Gene Chen, linux-kernel, linux-mediatek, Gene Chen,
Wilma.Wu, linux-arm-kernel
In-Reply-To: <be0bbf3b-76f8-9e2a-7c51-d5987263a859@gmail.com>
On Thu, 12 Sep 2019, Matthias Brugger wrote:
> Hi Gene Chen,
>
> Please use ./scripts/get_maintainer.pl to find out which are the maintainer(s)
> for a specific series/patch.
>
> I added Lee Jones, who is the maintainer of the MTD subsystem.
>
> Right now I have no time to review the patches, sorry.
>
> Regards,
> Matthias
>
> On 12/09/2019 10:10, Gene Chen wrote:
> > From: Gene Chen <gene_chen@mediatek.corp-partner.google.com>
Please resubmit this containing a suitable commit message with me on
Cc.
> > ---
> > drivers/mfd/Kconfig | 12 ++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/mt6360-core.c | 463 ++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 476 insertions(+)
> > create mode 100644 drivers/mfd/mt6360-core.c
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 00/11] ARM: dts: qcom: msm8974: add support for external display
From: Andrzej Hajda @ 2019-09-16 8:13 UTC (permalink / raw)
To: Brian Masney, bjorn.andersson, robh+dt, agross, narmstrong,
robdclark, sean
Cc: mark.rutland, devicetree, jernej.skrabec, jonas, airlied,
linux-arm-msm, linus.walleij, linux-kernel, dri-devel,
Laurent.pinchart, daniel, enric.balletbo, freedreno,
linux-arm-kernel
In-Reply-To: <20190815004854.19860-1-masneyb@onstation.org>
Hi Brian,
On 15.08.2019 02:48, Brian Masney wrote:
> This patch series begins to add support for the external display over
> HDMI that is supported on msm8974 SoCs. I'm testing this series on the
> Nexus 5, and I'm able to communicate with the HDMI bridge via the
> analogix-anx78xx driver, however the external display is not working
> yet.
>
> When I plug in the HDMI cable, the monitor detects that a device is
> hooked up, but nothing is shown on the external monitor. The hot plug
> detect GPIO (hpd-gpios) on the analogix-anx78xx bridge and MSM HDMI
> drivers do not change state when the slimport adapter or HDMI cable is
> plugged in or removed. I wonder if a regulator is not enabled somewhere?
> I have a comment in patch 10 regarding 'hpd-gdsc-supply' that may
> potentially be an issue.
>
> I'm still digging in on this, however I'd appreciate any feedback if
> anyone has time. Most of these patches are ready now, so I marked the
> ones that aren't ready with 'PATCH RFC'.
>
> I'm using an Analogix Semiconductor SP6001 SlimPort Micro-USB to 4K HDMI
> Adapter to connect my phone to an external display via a standard HDMI
> cable. This works just fine with the downstream MSM kernel using
> Android.
This patchset risks to be forgotten. To avoid it, at least partially, I
can merge patches 1-5, is it OK for you?
Regards
Andrzej
>
> Brian Masney (11):
> dt-bindings: drm/bridge: analogix-anx78xx: add new variants
> drm/bridge: analogix-anx78xx: add new variants
> drm/bridge: analogix-anx78xx: silence -EPROBE_DEFER warnings
> drm/bridge: analogix-anx78xx: convert to i2c_new_dummy_device
> drm/bridge: analogix-anx78xx: correct value of TX_P0
> drm/bridge: analogix-anx78xx: add support for avdd33 regulator
> ARM: qcom_defconfig: add CONFIG_DRM_ANALOGIX_ANX78XX
> drm/msm/hdmi: silence -EPROBE_DEFER warning
> ARM: dts: qcom: pm8941: add 5vs2 regulator node
> ARM: dts: qcom: msm8974: add HDMI nodes
> ARM: dts: qcom: msm8974-hammerhead: add support for external display
>
> .../bindings/display/bridge/anx7814.txt | 6 +-
> .../qcom-msm8974-lge-nexus5-hammerhead.dts | 140 ++++++++++++++++++
> arch/arm/boot/dts/qcom-msm8974.dtsi | 80 ++++++++++
> arch/arm/boot/dts/qcom-pm8941.dtsi | 10 ++
> arch/arm/configs/qcom_defconfig | 1 +
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 60 +++++++-
> drivers/gpu/drm/bridge/analogix-anx78xx.h | 2 +-
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 8 +-
> 8 files changed, 295 insertions(+), 12 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: imx7s: Correct GPT's ipg clock source
From: Anson Huang @ 2019-09-16 8:29 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
devicetree, linux-arm-kernel, linux-kernel
Cc: Linux-imx
i.MX7S/D's GPT ipg clock should be from GPT clock root and
controlled by CCM's GPT CCGR, using correct clock source for
GPT ipg clock instead of IMX7D_CLK_DUMMY.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/boot/dts/imx7s.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 710f850..e2e604d 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -448,7 +448,7 @@
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x302d0000 0x10000>;
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_CLK_DUMMY>,
+ clocks = <&clks IMX7D_GPT1_ROOT_CLK>,
<&clks IMX7D_GPT1_ROOT_CLK>;
clock-names = "ipg", "per";
};
@@ -457,7 +457,7 @@
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x302e0000 0x10000>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_CLK_DUMMY>,
+ clocks = <&clks IMX7D_GPT2_ROOT_CLK>,
<&clks IMX7D_GPT2_ROOT_CLK>;
clock-names = "ipg", "per";
status = "disabled";
@@ -467,7 +467,7 @@
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x302f0000 0x10000>;
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_CLK_DUMMY>,
+ clocks = <&clks IMX7D_GPT3_ROOT_CLK>,
<&clks IMX7D_GPT3_ROOT_CLK>;
clock-names = "ipg", "per";
status = "disabled";
@@ -477,7 +477,7 @@
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x30300000 0x10000>;
interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7D_CLK_DUMMY>,
+ clocks = <&clks IMX7D_GPT4_ROOT_CLK>,
<&clks IMX7D_GPT4_ROOT_CLK>;
clock-names = "ipg", "per";
status = "disabled";
--
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
* Re: [PATCH] crypto: sun4i-ss: erase key after use
From: Sasha Levin @ 2019-09-16 8:30 UTC (permalink / raw)
To: Sasha Levin, Corentin Labbe, davem, herbert
Cc: stable, linux-crypto, linux-arm-kernel
In-Reply-To: <20190915183536.3835-1-clabbe.montjoie@gmail.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 6298e948215f crypto: sunxi-ss - Add Allwinner Security System crypto accelerator.
The bot has tested the following trees: v5.2.14, v4.19.72, v4.14.143, v4.9.192, v4.4.192.
v5.2.14: Build OK!
v4.19.72: Failed to apply! Possible dependencies:
0ae1f46c55f8 ("crypto: sun4i-ss - fallback when length is not multiple of blocksize")
v4.14.143: Failed to apply! Possible dependencies:
0ae1f46c55f8 ("crypto: sun4i-ss - fallback when length is not multiple of blocksize")
249c8d98ea33 ("crypto: crypto4xx - move and refactor dynamic_contents helpers")
2c95e6d97892 ("crypto: skcipher - remove useless setting of type flags")
333eb3edda38 ("crypto: crypto4xx - fix type mismatch compiler error")
40e3b847bff7 ("crypto: crypto4xx - replace crypto4xx_dev's scatter_buffer_size with constant")
453e3090b9c3 ("crypto: crypto4xx - fix dynamic_sa_ctl's sa_contents declaration")
4865b122d4af ("crypto: crypto4xx - use the correct LE32 format for IV and key defs")
5c727f92ea5e ("crypto: crypto4xx - refactor crypto4xx_copy_pkt_to_dst()")
81065f66dd99 ("crypto: crypto4xx - remove unused definitions and write-only variables")
886c251fd4ca ("crypto: crypto4xx - remove extern statement before function declaration")
8ef8d195430c ("crypto: crypto4xx - add backlog queue support")
9e0a0b3a192a ("crypto: crypto4xx - pointer arithmetic overhaul")
a0aae821ba3d ("crypto: crypto4xx - prepare for AEAD support")
a8d79d7bfb14 ("crypto: crypto4xx - performance optimizations")
cd4dcd6da7a2 ("crypto: crypto4xx - overhaul crypto4xx_build_pd()")
ce05ffe10457 ("crypto: crypto4xx - convert to skcipher")
f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
v4.9.192: Failed to apply! Possible dependencies:
0ae1f46c55f8 ("crypto: sun4i-ss - fallback when length is not multiple of blocksize")
249c8d98ea33 ("crypto: crypto4xx - move and refactor dynamic_contents helpers")
2c95e6d97892 ("crypto: skcipher - remove useless setting of type flags")
317cbacf720c ("crypto: sun4i-ss - move from ablkcipher to skcipher API")
333eb3edda38 ("crypto: crypto4xx - fix type mismatch compiler error")
40e3b847bff7 ("crypto: crypto4xx - replace crypto4xx_dev's scatter_buffer_size with constant")
453e3090b9c3 ("crypto: crypto4xx - fix dynamic_sa_ctl's sa_contents declaration")
4865b122d4af ("crypto: crypto4xx - use the correct LE32 format for IV and key defs")
5c727f92ea5e ("crypto: crypto4xx - refactor crypto4xx_copy_pkt_to_dst()")
81065f66dd99 ("crypto: crypto4xx - remove unused definitions and write-only variables")
886c251fd4ca ("crypto: crypto4xx - remove extern statement before function declaration")
8ef8d195430c ("crypto: crypto4xx - add backlog queue support")
9e0a0b3a192a ("crypto: crypto4xx - pointer arithmetic overhaul")
a0aae821ba3d ("crypto: crypto4xx - prepare for AEAD support")
a595e60a70c0 ("crypto: sun4i-ss - remove conditional checks against 0")
a8d79d7bfb14 ("crypto: crypto4xx - performance optimizations")
cd4dcd6da7a2 ("crypto: crypto4xx - overhaul crypto4xx_build_pd()")
ce05ffe10457 ("crypto: crypto4xx - convert to skcipher")
f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
v4.4.192: Failed to apply! Possible dependencies:
0ae1f46c55f8 ("crypto: sun4i-ss - fallback when length is not multiple of blocksize")
249c8d98ea33 ("crypto: crypto4xx - move and refactor dynamic_contents helpers")
2c95e6d97892 ("crypto: skcipher - remove useless setting of type flags")
317cbacf720c ("crypto: sun4i-ss - move from ablkcipher to skcipher API")
333eb3edda38 ("crypto: crypto4xx - fix type mismatch compiler error")
40e3b847bff7 ("crypto: crypto4xx - replace crypto4xx_dev's scatter_buffer_size with constant")
453e3090b9c3 ("crypto: crypto4xx - fix dynamic_sa_ctl's sa_contents declaration")
477d9b2e591b ("crypto: sun4i-ss - unify update/final function")
4865b122d4af ("crypto: crypto4xx - use the correct LE32 format for IV and key defs")
5343e674f32f ("crypto4xx: integrate ppc4xx-rng into crypto4xx")
81065f66dd99 ("crypto: crypto4xx - remove unused definitions and write-only variables")
886c251fd4ca ("crypto: crypto4xx - remove extern statement before function declaration")
9e0a0b3a192a ("crypto: crypto4xx - pointer arithmetic overhaul")
a0aae821ba3d ("crypto: crypto4xx - prepare for AEAD support")
a595e60a70c0 ("crypto: sun4i-ss - remove conditional checks against 0")
a8d79d7bfb14 ("crypto: crypto4xx - performance optimizations")
b6ff2fdd429c ("crypto: sun4i-ss - fix indentation of two crypto alg")
bfb2892018ca ("crypto: sunxi - don't print confusing data")
cd4dcd6da7a2 ("crypto: crypto4xx - overhaul crypto4xx_build_pd()")
ce05ffe10457 ("crypto: crypto4xx - convert to skcipher")
ea1a67414318 ("crypto: sun4i-ss - fix a few signed warning")
f2a13e7cba9e ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
_______________________________________________
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 1/2] perf/imx_ddr: add enhanced AXI ID filter support
From: Joakim Zhang @ 2019-09-16 8:34 UTC (permalink / raw)
To: will@kernel.org, mark.rutland@arm.com, robin.murphy@arm.com
Cc: Frank Li, dl-linux-imx, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190906082356.25485-1-qiangqing.zhang@nxp.com>
Kindly Ping...
Best Regards,
Joakim Zhang
> -----Original Message-----
> From: Joakim Zhang
> Sent: 2019年9月6日 16:27
> To: will@kernel.org; mark.rutland@arm.com; robin.murphy@arm.com; Frank
> Li <frank.li@nxp.com>
> Cc: dl-linux-imx <linux-imx@nxp.com>; linux-arm-kernel@lists.infradead.org;
> Joakim Zhang <qiangqing.zhang@nxp.com>
> Subject: [PATCH 1/2] perf/imx_ddr: add enhanced AXI ID filter support
>
> With DDR_CAP_AXI_ID_FILTER quirk, indicating HW supports AXI ID filter
> which only can get bursts of reading/writing DDR, i.e. DDR read/write request.
>
> This patch add DDR_CAP_AXI_ID_ENHANCED_FILTER quirk, indicating HW
> supports AXI ID filter which can get bytes of reading/writing DDR. This feature
> is more meaningful due to we always care more about bandwidth.
>
> Need select both above two qiurks together when HW support enhanced AXI ID
> filter.
>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
> drivers/perf/fsl_imx8_ddr_perf.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
> index ce7345745b42..5f70dbfa9607 100644
> --- a/drivers/perf/fsl_imx8_ddr_perf.c
> +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> @@ -45,7 +45,8 @@
> static DEFINE_IDA(ddr_ida);
>
> /* DDR Perf hardware feature */
> -#define DDR_CAP_AXI_ID_FILTER 0x1 /* support AXI ID filter
> */
> +#define DDR_CAP_AXI_ID_FILTER BIT(1) /* support AXI ID
> filter */
> +#define DDR_CAP_AXI_ID_FILTER_ENHANCED BIT(2) /* support
> enhanced AXI ID filter */
>
> struct fsl_ddr_devtype_data {
> unsigned int quirks; /* quirks needed for different DDR Perf core */
> @@ -209,7 +210,15 @@ static void ddr_perf_free_counter(struct ddr_pmu
> *pmu, int counter)
>
> static u32 ddr_perf_read_counter(struct ddr_pmu *pmu, int counter) {
> - return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
> + if ((pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) &&
> + (pmu->devtype_data->quirks &
> DDR_CAP_AXI_ID_FILTER_ENHANCED)) {
> + if ((pmu->events[counter]->attr.config == 0x41) ||
> + (pmu->events[counter]->attr.config == 0x42))
> + return readl_relaxed(pmu->base + COUNTER_DPCR1 + counter
> * 4);
> + else
> + return readl_relaxed(pmu->base + COUNTER_READ + counter *
> 4);
> + } else
> + return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);
> }
>
> static bool ddr_perf_is_filtered(struct perf_event *event)
> --
> 2.17.1
_______________________________________________
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 v3 08/11] PCI: layerscape: Modify the MSIX to the doorbell mode
From: Gustavo Pimentel @ 2019-09-16 8:54 UTC (permalink / raw)
To: Xiaowei Bao, Gustavo Pimentel, Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, kishon@ti.com, M.h. Lian,
robh+dt@kernel.org, gregkh@linuxfoundation.org,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
Leo Li, shawnguo@kernel.org, Mingkai Hu
In-Reply-To: <AM5PR04MB32994FAF102AD4F760792808F5B20@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Sat, Sep 14, 2019 at 7:37:54, Xiaowei Bao <xiaowei.bao@nxp.com> wrote:
>
>
> > -----Original Message-----
> > From: Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>
> > Sent: 2019年9月12日 19:24
> > To: Andrew Murray <andrew.murray@arm.com>; Xiaowei Bao
> > <xiaowei.bao@nxp.com>
> > Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> > Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> > arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> > <zhiqiang.hou@nxp.com>
> > Subject: RE: [PATCH v3 08/11] PCI: layerscape: Modify the MSIX to the
> > doorbell mode
> >
> > Hi,
> >
> > Sorry for the delay I was in parental leave and I'm still trying not to drown in
> > the mailing list emails... 😊
> >
> > On Mon, Sep 2, 2019 at 13:1:47, Andrew Murray <andrew.murray@arm.com>
> > wrote:
> >
> > > On Mon, Sep 02, 2019 at 11:17:13AM +0800, Xiaowei Bao wrote:
> > > > dw_pcie_ep_raise_msix_irq was never called in the exisitng driver
> > > > before, because the ls1046a platform don't support the MSIX feature
> > > > and msix_capable was always set to false.
> > > > Now that add the ls1088a platform with MSIX support, but the
> > > > existing dw_pcie_ep_raise_msix_irq doesn't work, so use the doorbell
> > > > method to support the MSIX feature.
> >
> > Hum... the implementation of msix implementation did work on my use case,
> > however, at the time the setup used for developing and testing the
> > implementation only had one PF (by default 0). Perhaps this could was is
> > causing the different behavior between our setups.
> >
> > You have more than one PF, right?
>
> Yes, I have two PFs.
Probably that's the reason why my MSI-X raise function implementation
didn't work on your case.
>
> Thanks
> Xiaowei
>
> >
> > If I remember correctly, msix feature support entered on kernel 4.19 version
> > and it worked quite well at the time, but I didn't test since there (I've to
> > manage time to be able to retest it again), I'm didn't seen any patch that
> > could interfere with this.
> >
> > Regards,
> > Gustavo
> >
> >
> > > >
> > > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > >
> > > Reviewed-by: Andrew Murray <andrew.murray@arm.com>
> > >
> > > > ---
> > > > v2:
> > > > - No change
> > > > v3:
> > > > - Modify the commit message make it clearly.
> > > >
> > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > index 1e07287..5f0cb99 100644
> > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > @@ -79,7 +79,8 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep
> > *ep, u8 func_no,
> > > > case PCI_EPC_IRQ_MSI:
> > > > return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
> > > > case PCI_EPC_IRQ_MSIX:
> > > > - return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num);
> > > > + return dw_pcie_ep_raise_msix_irq_doorbell(ep, func_no,
> > > > + interrupt_num);
> > > > default:
> > > > dev_err(pci->dev, "UNKNOWN IRQ type\n");
> > > > return -EINVAL;
> > > > --
> > > > 2.9.5
> > > >
> >
_______________________________________________
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 00/11] ARM: dts: qcom: msm8974: add support for external display
From: Brian Masney @ 2019-09-16 9:01 UTC (permalink / raw)
To: Andrzej Hajda
Cc: mark.rutland, devicetree, jernej.skrabec, narmstrong, airlied,
linux-kernel, linus.walleij, jonas, agross, dri-devel,
bjorn.andersson, robdclark, robh+dt, Laurent.pinchart, daniel,
linux-arm-msm, enric.balletbo, freedreno, sean, linux-arm-kernel
In-Reply-To: <2da29e80-73fb-8620-532e-0b5f54b00841@samsung.com>
Hi Andrzej,
On Mon, Sep 16, 2019 at 10:13:58AM +0200, Andrzej Hajda wrote:
> Hi Brian,
>
> On 15.08.2019 02:48, Brian Masney wrote:
> > This patch series begins to add support for the external display over
> > HDMI that is supported on msm8974 SoCs. I'm testing this series on the
> > Nexus 5, and I'm able to communicate with the HDMI bridge via the
> > analogix-anx78xx driver, however the external display is not working
> > yet.
> >
> > When I plug in the HDMI cable, the monitor detects that a device is
> > hooked up, but nothing is shown on the external monitor. The hot plug
> > detect GPIO (hpd-gpios) on the analogix-anx78xx bridge and MSM HDMI
> > drivers do not change state when the slimport adapter or HDMI cable is
> > plugged in or removed. I wonder if a regulator is not enabled somewhere?
> > I have a comment in patch 10 regarding 'hpd-gdsc-supply' that may
> > potentially be an issue.
> >
> > I'm still digging in on this, however I'd appreciate any feedback if
> > anyone has time. Most of these patches are ready now, so I marked the
> > ones that aren't ready with 'PATCH RFC'.
> >
> > I'm using an Analogix Semiconductor SP6001 SlimPort Micro-USB to 4K HDMI
> > Adapter to connect my phone to an external display via a standard HDMI
> > cable. This works just fine with the downstream MSM kernel using
> > Android.
>
>
> This patchset risks to be forgotten. To avoid it, at least partially, I
> can merge patches 1-5, is it OK for you?
That would be great if you could do that.
Thanks,
Brian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH][next] memory: exynos5422: fix spelling mistake "counld" -> "could"
From: Colin King @ 2019-09-16 9:12 UTC (permalink / raw)
To: Lukasz Luba, Kukjin Kim, Krzysztof Kozlowski, linux-pm,
linux-samsung-soc, linux-arm-kernel
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/memory/samsung/exynos5422-dmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/samsung/exynos5422-dmc.c b/drivers/memory/samsung/exynos5422-dmc.c
index 8c2ec29a7d57..ac5f55813900 100644
--- a/drivers/memory/samsung/exynos5422-dmc.c
+++ b/drivers/memory/samsung/exynos5422-dmc.c
@@ -1078,7 +1078,7 @@ static int exynos5_performance_counters_init(struct exynos5_dmc *dmc)
ret = exynos5_counters_set_event(dmc);
if (ret < 0) {
exynos5_counters_disable_edev(dmc);
- dev_err(dmc->dev, "counld not set event counter\n");
+ dev_err(dmc->dev, "could not set event counter\n");
return ret;
}
--
2.20.1
_______________________________________________
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 0/5] iommu: Implement iommu_put_resv_regions_simple()
From: Auger Eric @ 2019-09-16 9:14 UTC (permalink / raw)
To: Thierry Reding, Joerg Roedel
Cc: Jean-Philippe Brucker, Will Deacon, linux-kernel, virtualization,
iommu, Robin Murphy, David Woodhouse, linux-arm-kernel
In-Reply-To: <20190829111752.17513-1-thierry.reding@gmail.com>
Hi Thierry,
On 8/29/19 1:17 PM, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Most IOMMU drivers only need to free the memory allocated for each
> reserved region. Instead of open-coding the loop to do this in each
> driver, extract the code into a common function that can be used by
> all these drivers.
If I am not wrong, all the drivers now use the
iommu_put_resv_regions_simple helper. So we can wonder if the callback
is still relevant?
Thanks
Eric
>
> Thierry
>
> Thierry Reding (5):
> iommu: Implement iommu_put_resv_regions_simple()
> iommu: arm: Use iommu_put_resv_regions_simple()
> iommu: amd: Use iommu_put_resv_regions_simple()
> iommu: intel: Use iommu_put_resv_regions_simple()
> iommu: virt: Use iommu_put_resv_regions_simple()
>
> drivers/iommu/amd_iommu.c | 11 +----------
> drivers/iommu/arm-smmu-v3.c | 11 +----------
> drivers/iommu/arm-smmu.c | 11 +----------
> drivers/iommu/intel-iommu.c | 11 +----------
> drivers/iommu/iommu.c | 19 +++++++++++++++++++
> drivers/iommu/virtio-iommu.c | 14 +++-----------
> include/linux/iommu.h | 2 ++
> 7 files changed, 28 insertions(+), 51 deletions(-)
>
_______________________________________________
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 v3 2/2] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Kirill A. Shutemov @ 2019-09-16 9:16 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Ralph Campbell, Andrew Morton, Anshuman Khandual,
Catalin Marinas, linux-kernel, Matthew Wilcox, Jun Yao, linux-mm,
Jérôme Glisse, James Morse, linux-arm-kernel,
Punit Agrawal, Marc Zyngier, hejianet, Thomas Gleixner,
Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190913163239.125108-3-justin.he@arm.com>
On Sat, Sep 14, 2019 at 12:32:39AM +0800, Jia He wrote:
> When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
> will be a double page fault in __copy_from_user_inatomic of cow_user_page.
>
> Below call trace is from arm64 do_page_fault for debugging purpose
> [ 110.016195] Call trace:
> [ 110.016826] do_page_fault+0x5a4/0x690
> [ 110.017812] do_mem_abort+0x50/0xb0
> [ 110.018726] el1_da+0x20/0xc4
> [ 110.019492] __arch_copy_from_user+0x180/0x280
> [ 110.020646] do_wp_page+0xb0/0x860
> [ 110.021517] __handle_mm_fault+0x994/0x1338
> [ 110.022606] handle_mm_fault+0xe8/0x180
> [ 110.023584] do_page_fault+0x240/0x690
> [ 110.024535] do_mem_abort+0x50/0xb0
> [ 110.025423] el0_da+0x20/0x24
>
> The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003, pmd=000000023d4b3003, pte=360000298607bd3
>
> As told by Catalin: "On arm64 without hardware Access Flag, copying from
> user will fail because the pte is old and cannot be marked young. So we
> always end up with zeroed page after fork() + CoW for pfn mappings. we
> don't always have a hardware-managed access flag on arm64."
>
> This patch fix it by calling pte_mkyoung. Also, the parameter is
> changed because vmf should be passed to cow_user_page()
>
> [1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
>
> Reported-by: Yibo Cai <Yibo.Cai@arm.com>
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
> mm/memory.c | 30 +++++++++++++++++++++++++-----
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e2bb51b6242e..a64af6495f71 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> 2;
> #endif
>
> +#ifndef arch_faults_on_old_pte
> +static inline bool arch_faults_on_old_pte(void)
> +{
> + return false;
> +}
> +#endif
> +
> static int __init disable_randmaps(char *s)
> {
> randomize_va_space = 0;
> @@ -2140,7 +2147,8 @@ static inline int pte_unmap_same(struct mm_struct *mm, pmd_t *pmd,
> return same;
> }
>
> -static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
> +static inline void cow_user_page(struct page *dst, struct page *src,
> + struct vm_fault *vmf)
> {
> debug_dma_assert_idle(src);
>
> @@ -2152,20 +2160,32 @@ static inline void cow_user_page(struct page *dst, struct page *src, unsigned lo
> */
> if (unlikely(!src)) {
> void *kaddr = kmap_atomic(dst);
> - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> + void __user *uaddr = (void __user *)(vmf->address & PAGE_MASK);
> + pte_t entry;
>
> /*
> * This really shouldn't fail, because the page is there
> * in the page tables. But it might just be unreadable,
> * in which case we just give up and fill the result with
> - * zeroes.
> + * zeroes. If PTE_AF is cleared on arm64, it might
> + * cause double page fault. So makes pte young here
> */
> + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
> + spin_lock(vmf->ptl);
> + entry = pte_mkyoung(vmf->orig_pte);
Should't you re-validate that orig_pte after re-taking ptl? It can be
stale by now.
> + if (ptep_set_access_flags(vmf->vma, vmf->address,
> + vmf->pte, entry, 0))
> + update_mmu_cache(vmf->vma, vmf->address,
> + vmf->pte);
> + spin_unlock(vmf->ptl);
> + }
> +
> if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> clear_page(kaddr);
> kunmap_atomic(kaddr);
> flush_dcache_page(dst);
> } else
> - copy_user_highpage(dst, src, va, vma);
> + copy_user_highpage(dst, src, vmf->address, vmf->vma);
> }
>
> static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
> @@ -2318,7 +2338,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
> vmf->address);
> if (!new_page)
> goto oom;
> - cow_user_page(new_page, old_page, vmf->address, vma);
> + cow_user_page(new_page, old_page, vmf);
> }
>
> if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL, &memcg, false))
> --
> 2.17.1
>
>
--
Kirill A. Shutemov
_______________________________________________
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 v3 1/2] arm64: mm: implement arch_faults_on_old_pte() on arm64
From: Kirill A. Shutemov @ 2019-09-16 9:20 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Ralph Campbell, Andrew Morton, Anshuman Khandual,
Catalin Marinas, linux-kernel, Matthew Wilcox, Jun Yao, linux-mm,
Jérôme Glisse, James Morse, linux-arm-kernel,
Punit Agrawal, Marc Zyngier, hejianet, Thomas Gleixner,
Will Deacon, Alex Van Brunt, Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190913163239.125108-2-justin.he@arm.com>
On Sat, Sep 14, 2019 at 12:32:38AM +0800, Jia He wrote:
> On arm64 without hardware Access Flag, copying fromuser will fail because
> the pte is old and cannot be marked young. So we always end up with zeroed
> page after fork() + CoW for pfn mappings. we don't always have a
> hardware-managed access flag on arm64.
>
> Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
> cause page fault when accessing old pte.
>
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
> arch/arm64/include/asm/pgtable.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index e09760ece844..b41399d758df 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -868,6 +868,18 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
> #define phys_to_ttbr(addr) (addr)
> #endif
>
> +/*
> + * On arm64 without hardware Access Flag, copying fromuser will fail because
> + * the pte is old and cannot be marked young. So we always end up with zeroed
> + * page after fork() + CoW for pfn mappings. we don't always have a
> + * hardware-managed access flag on arm64.
> + */
> +static inline bool arch_faults_on_old_pte(void)
> +{
> + return true;
Shouldn't youc check if this particular machine supports hardware access
bit?
> +}
> +#define arch_faults_on_old_pte arch_faults_on_old_pte
> +
> #endif /* !__ASSEMBLY__ */
>
> #endif /* __ASM_PGTABLE_H */
> --
> 2.17.1
>
>
--
Kirill A. Shutemov
_______________________________________________
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 v3 2/2] mm: fix double page fault on arm64 if PTE_AF is cleared
From: Justin He (Arm Technology China) @ 2019-09-16 9:35 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Mark Rutland, Ralph Campbell, Andrew Morton, Anshuman Khandual,
Catalin Marinas, linux-kernel@vger.kernel.org, Matthew Wilcox,
Jun Yao, linux-mm@kvack.org, Jérôme Glisse, James Morse,
linux-arm-kernel@lists.infradead.org, Punit Agrawal, Marc Zyngier,
hejianet@gmail.com, Thomas Gleixner, Will Deacon, Alex Van Brunt,
Kirill A. Shutemov, Robin Murphy
In-Reply-To: <20190916091628.bkuvd3g3ie3x6qav@box.shutemov.name>
Hi Kirill
> -----Original Message-----
> From: Kirill A. Shutemov <kirill@shutemov.name>
> Sent: 2019年9月16日 17:16
> To: Justin He (Arm Technology China) <Justin.He@arm.com>
> Cc: Catalin Marinas <Catalin.Marinas@arm.com>; Will Deacon
> <will@kernel.org>; Mark Rutland <Mark.Rutland@arm.com>; James Morse
> <James.Morse@arm.com>; Marc Zyngier <maz@kernel.org>; Matthew
> Wilcox <willy@infradead.org>; Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com>; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-mm@kvack.org; Punit Agrawal
> <punitagrawal@gmail.com>; Anshuman Khandual
> <Anshuman.Khandual@arm.com>; Jun Yao <yaojun8558363@gmail.com>;
> Alex Van Brunt <avanbrunt@nvidia.com>; Robin Murphy
> <Robin.Murphy@arm.com>; Thomas Gleixner <tglx@linutronix.de>;
> Andrew Morton <akpm@linux-foundation.org>; Jérôme Glisse
> <jglisse@redhat.com>; Ralph Campbell <rcampbell@nvidia.com>;
> hejianet@gmail.com
> Subject: Re: [PATCH v3 2/2] mm: fix double page fault on arm64 if PTE_AF
> is cleared
>
> On Sat, Sep 14, 2019 at 12:32:39AM +0800, Jia He wrote:
> > When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest,
> there
> > will be a double page fault in __copy_from_user_inatomic of
> cow_user_page.
> >
> > Below call trace is from arm64 do_page_fault for debugging purpose
> > [ 110.016195] Call trace:
> > [ 110.016826] do_page_fault+0x5a4/0x690
> > [ 110.017812] do_mem_abort+0x50/0xb0
> > [ 110.018726] el1_da+0x20/0xc4
> > [ 110.019492] __arch_copy_from_user+0x180/0x280
> > [ 110.020646] do_wp_page+0xb0/0x860
> > [ 110.021517] __handle_mm_fault+0x994/0x1338
> > [ 110.022606] handle_mm_fault+0xe8/0x180
> > [ 110.023584] do_page_fault+0x240/0x690
> > [ 110.024535] do_mem_abort+0x50/0xb0
> > [ 110.025423] el0_da+0x20/0x24
> >
> > The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
> > [ffff9b007000] pgd=000000023d4f8003, pud=000000023da9b003,
> pmd=000000023d4b3003, pte=360000298607bd3
> >
> > As told by Catalin: "On arm64 without hardware Access Flag, copying
> from
> > user will fail because the pte is old and cannot be marked young. So we
> > always end up with zeroed page after fork() + CoW for pfn mappings. we
> > don't always have a hardware-managed access flag on arm64."
> >
> > This patch fix it by calling pte_mkyoung. Also, the parameter is
> > changed because vmf should be passed to cow_user_page()
> >
> > [1]
> https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
> >
> > Reported-by: Yibo Cai <Yibo.Cai@arm.com>
> > Signed-off-by: Jia He <justin.he@arm.com>
> > ---
> > mm/memory.c | 30 +++++++++++++++++++++++++-----
> > 1 file changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index e2bb51b6242e..a64af6495f71 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
> > 2;
> > #endif
> >
> > +#ifndef arch_faults_on_old_pte
> > +static inline bool arch_faults_on_old_pte(void)
> > +{
> > + return false;
> > +}
> > +#endif
> > +
> > static int __init disable_randmaps(char *s)
> > {
> > randomize_va_space = 0;
> > @@ -2140,7 +2147,8 @@ static inline int pte_unmap_same(struct
> mm_struct *mm, pmd_t *pmd,
> > return same;
> > }
> >
> > -static inline void cow_user_page(struct page *dst, struct page *src,
> unsigned long va, struct vm_area_struct *vma)
> > +static inline void cow_user_page(struct page *dst, struct page *src,
> > + struct vm_fault *vmf)
> > {
> > debug_dma_assert_idle(src);
> >
> > @@ -2152,20 +2160,32 @@ static inline void cow_user_page(struct page
> *dst, struct page *src, unsigned lo
> > */
> > if (unlikely(!src)) {
> > void *kaddr = kmap_atomic(dst);
> > - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > + void __user *uaddr = (void __user *)(vmf->address &
> PAGE_MASK);
> > + pte_t entry;
> >
> > /*
> > * This really shouldn't fail, because the page is there
> > * in the page tables. But it might just be unreadable,
> > * in which case we just give up and fill the result with
> > - * zeroes.
> > + * zeroes. If PTE_AF is cleared on arm64, it might
> > + * cause double page fault. So makes pte young here
> > */
> > + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte))
> {
> > + spin_lock(vmf->ptl);
> > + entry = pte_mkyoung(vmf->orig_pte);
>
> Should't you re-validate that orig_pte after re-taking ptl? It can be
> stale by now.
Thanks, do you mean flush_cache_page(vma, vmf->address, pte_pfn(vmf->orig_pte))
before pte_mkyoung?
--
Cheers,
Justin (Jia He)
>
> > + if (ptep_set_access_flags(vmf->vma, vmf->address,
> > + vmf->pte, entry, 0))
> > + update_mmu_cache(vmf->vma, vmf-
> >address,
> > + vmf->pte);
> > + spin_unlock(vmf->ptl);
> > + }
> > +
> > if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
> > clear_page(kaddr);
> > kunmap_atomic(kaddr);
> > flush_dcache_page(dst);
> > } else
> > - copy_user_highpage(dst, src, va, vma);
> > + copy_user_highpage(dst, src, vmf->address, vmf->vma);
> > }
> >
> > static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
> > @@ -2318,7 +2338,7 @@ static vm_fault_t wp_page_copy(struct
> vm_fault *vmf)
> > vmf->address);
> > if (!new_page)
> > goto oom;
> > - cow_user_page(new_page, old_page, vmf->address, vma);
> > + cow_user_page(new_page, old_page, vmf);
> > }
> >
> > if (mem_cgroup_try_charge_delay(new_page, mm, GFP_KERNEL,
> &memcg, false))
> > --
> > 2.17.1
> >
> >
>
> --
> Kirill A. Shutemov
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 00/12] Unify SMP stop generic logic to common code
From: Cristian Marussi @ 2019-09-16 9:38 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-arch, mark.rutland, sparclinux, dzickus, ehabkost, peterz,
catalin.marinas, x86, linux-kernel, davem, hch, takahiro.akashi,
mingo, james.morse, hidehiro.kawai.ez, tglx, will, dave.martin,
linux-arm-kernel
In-Reply-To: <20190913182713.GB13294@shell.armlinux.org.uk>
On 13/09/2019 19:27, Russell King - ARM Linux admin wrote:
> On Fri, Sep 13, 2019 at 07:19:41PM +0100, Cristian Marussi wrote:
>> Tested as follows:
>>
>> - arm:
>> 1. boot
>
> So this basically means the code paths you're touching are untested on
> ARM... given that, and the variety of systems we have out there, why
> should the patches touching ARM be taken?
>
Yes, but sincerely it's an RFC, so I was not expecting any change to be picked up
by anyone at this stage: the expectation was to have some feedback on the general
approach used in the common code side of the series (patches 01-02-03-04):
is it worth ? is it over-engineered ? is it badly coded ? is it complete crap ?
In fact in the cover letter I stated:
> A couple more of still to be done potential enhancements have been noted
> on specific commits, and a lot more of testing remains surely to be done
> as of now, but, in the context of this RFC, any thoughts on this approach
> in general ?
I didn't want to port and test a lot of architectures before having some basic
feedback: in fact I did port more than one arch just to verify if they could
easily all fit into the new common code logic/layout I introduced, and, also,
to show that it could be generally useful to more than on arch. (as asked in V1)
As you noticed, though, I did certainly test as of now a lot more on some of them:
- arm64: because is where the initial bug was observed, so I had to verify if all
of the above at least also fixed something at the end
- x86: because the original x86 SMP stop code differs more than other archs and so
it was a good challenge to see if it could fit inside the new common SMP code logic
(and in fact I had to extend the common framework to fit also x86 SMP stop needs)
Moreover within this series structure it is not mandatory for all archs to switch to the
new common logic: if not deemed important they can simply stick to their old code, while
other archs can switch to it.
So testing and porting to further archs is certainly work in progress at this time,
but in this RFC stage, I could be wrong, but I considered the arch-patches in this series more
as an example to showcase the usefulness (or not) of the series related to the common code
changes: I did not extensively tested all archs to the their full extent, so more fixes
could come in V3 (if ever) together with more testing and archs.
> Given that you're an ARM Ltd employee, I'm sure you can find 32-bit
> systems to test - or have ARM Ltd got rid of everything that isn't
> 64-bit? ;)
>
well...worst case there's always Amazon anyway ... :D
Cheers
Cristian
_______________________________________________
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 v3] mm/kasan: dump alloc and free stack for page allocator
From: Vlastimil Babka @ 2019-09-16 9:42 UTC (permalink / raw)
To: Andrey Ryabinin, Walter Wu
Cc: wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, Martin Schwidefsky,
Alexander Potapenko, linux-arm-kernel, Matthias Brugger, Qian Cai,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <79fede05-735b-8477-c273-f34db93fd72b@virtuozzo.com>
On 9/12/19 7:05 PM, Andrey Ryabinin wrote:
>
> Or another alternative option (and actually easier one to implement), leave PAGE_OWNER as is (no "select"s in Kconfigs)
> Make PAGE_OWNER_FREE_STACK like this:
>
> +config PAGE_OWNER_FREE_STACK
> + def_bool KASAN || DEBUG_PAGEALLOC
> + depends on PAGE_OWNER
> +
>
> So, users that want alloc/free stack will have to enable CONFIG_PAGE_OWNER=y and add page_owner=on to boot cmdline.
>
>
> Basically the difference between these alternative is whether we enable page_owner by default or not. But there is always a possibility to disable it.
OK, how about this?
BTW, the bugzilla [1] also mentions that on overflow we might be dumping
the wrong page (including stacks). I'll leave that to somebody familiar
with KASAN internals though.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203967
----8<----
From 887e3c092c073d996098ac2b101b0feaef110b54 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka@suse.cz>
Date: Mon, 16 Sep 2019 11:28:19 +0200
Subject: [PATCH] mm, debug, kasan: save and dump freeing stack trace for kasan
The commit "mm, page_owner, debug_pagealloc: save and dump freeing stack trace"
enhanced page_owner to also store freeing stack trace, when debug_pagealloc is
also enabled. KASAN would also like to do this [1] to improve error reports to
debug e.g. UAF issues. This patch therefore introduces a helper config option
PAGE_OWNER_FREE_STACK, which is enabled when PAGE_OWNER and either of
DEBUG_PAGEALLOC or KASAN is enabled. Boot-time, the free stack saving is
enabled when booting a KASAN kernel with page_owner=on, or non-KASAN kernel
with debug_pagealloc=on and page_owner=on.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203967
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Suggested-by: Walter Wu <walter-zh.wu@mediatek.com>
Suggested-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
Documentation/dev-tools/kasan.rst | 4 ++++
include/linux/page_owner.h | 1 +
mm/Kconfig.debug | 4 ++++
mm/page_alloc.c | 6 +++++-
mm/page_owner.c | 35 +++++++++++++++++++------------
5 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index b72d07d70239..434e605030e9 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -41,6 +41,10 @@ smaller binary while the latter is 1.1 - 2 times faster.
Both KASAN modes work with both SLUB and SLAB memory allocators.
For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
+To augment reports with last allocation and freeing stack of the physical
+page, it is recommended to configure kernel also with CONFIG_PAGE_OWNER = y
+and boot with page_owner=on.
+
To disable instrumentation for specific files or directories, add a line
similar to the following to the respective kernel Makefile:
diff --git a/include/linux/page_owner.h b/include/linux/page_owner.h
index 8679ccd722e8..6ffe8b81ba85 100644
--- a/include/linux/page_owner.h
+++ b/include/linux/page_owner.h
@@ -6,6 +6,7 @@
#ifdef CONFIG_PAGE_OWNER
extern struct static_key_false page_owner_inited;
+extern bool page_owner_free_stack_disabled;
extern struct page_ext_operations page_owner_ops;
extern void __reset_page_owner(struct page *page, unsigned int order);
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 327b3ebf23bf..1ea247da3322 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -62,6 +62,10 @@ config PAGE_OWNER
If unsure, say N.
+config PAGE_OWNER_FREE_STACK
+ def_bool KASAN || DEBUG_PAGEALLOC
+ depends on PAGE_OWNER
+
config PAGE_POISONING
bool "Poison pages after freeing"
select PAGE_POISONING_NO_SANITY if HIBERNATION
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c5d62f1c2851..d9e44671af3f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -710,8 +710,12 @@ static int __init early_debug_pagealloc(char *buf)
if (kstrtobool(buf, &enable))
return -EINVAL;
- if (enable)
+ if (enable) {
static_branch_enable(&_debug_pagealloc_enabled);
+#ifdef CONFIG_PAGE_OWNER
+ page_owner_free_stack_disabled = false;
+#endif
+ }
return 0;
}
diff --git a/mm/page_owner.c b/mm/page_owner.c
index dee931184788..b589bfbc4795 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -24,13 +24,15 @@ struct page_owner {
short last_migrate_reason;
gfp_t gfp_mask;
depot_stack_handle_t handle;
-#ifdef CONFIG_DEBUG_PAGEALLOC
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
depot_stack_handle_t free_handle;
#endif
};
static bool page_owner_disabled = true;
+bool page_owner_free_stack_disabled = true;
DEFINE_STATIC_KEY_FALSE(page_owner_inited);
+static DEFINE_STATIC_KEY_FALSE(page_owner_free_stack);
static depot_stack_handle_t dummy_handle;
static depot_stack_handle_t failure_handle;
@@ -46,6 +48,9 @@ static int __init early_page_owner_param(char *buf)
if (strcmp(buf, "on") == 0)
page_owner_disabled = false;
+ if (!page_owner_disabled && IS_ENABLED(CONFIG_KASAN))
+ page_owner_free_stack_disabled = false;
+
return 0;
}
early_param("page_owner", early_page_owner_param);
@@ -91,6 +96,8 @@ static void init_page_owner(void)
register_failure_stack();
register_early_stack();
static_branch_enable(&page_owner_inited);
+ if (!page_owner_free_stack_disabled)
+ static_branch_enable(&page_owner_free_stack);
init_early_allocated_pages();
}
@@ -148,11 +155,11 @@ void __reset_page_owner(struct page *page, unsigned int order)
{
int i;
struct page_ext *page_ext;
-#ifdef CONFIG_DEBUG_PAGEALLOC
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
depot_stack_handle_t handle = 0;
struct page_owner *page_owner;
- if (debug_pagealloc_enabled())
+ if (static_branch_unlikely(&page_owner_free_stack))
handle = save_stack(GFP_NOWAIT | __GFP_NOWARN);
#endif
@@ -161,8 +168,8 @@ void __reset_page_owner(struct page *page, unsigned int order)
if (unlikely(!page_ext))
continue;
__clear_bit(PAGE_EXT_OWNER_ACTIVE, &page_ext->flags);
-#ifdef CONFIG_DEBUG_PAGEALLOC
- if (debug_pagealloc_enabled()) {
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
+ if (static_branch_unlikely(&page_owner_free_stack)) {
page_owner = get_page_owner(page_ext);
page_owner->free_handle = handle;
}
@@ -451,14 +458,16 @@ void __dump_page_owner(struct page *page)
stack_trace_print(entries, nr_entries, 0);
}
-#ifdef CONFIG_DEBUG_PAGEALLOC
- handle = READ_ONCE(page_owner->free_handle);
- if (!handle) {
- pr_alert("page_owner free stack trace missing\n");
- } else {
- nr_entries = stack_depot_fetch(handle, &entries);
- pr_alert("page last free stack trace:\n");
- stack_trace_print(entries, nr_entries, 0);
+#ifdef CONFIG_PAGE_OWNER_FREE_STACK
+ if (static_branch_unlikely(&page_owner_free_stack)) {
+ handle = READ_ONCE(page_owner->free_handle);
+ if (!handle) {
+ pr_alert("page_owner free stack trace missing\n");
+ } else {
+ nr_entries = stack_depot_fetch(handle, &entries);
+ pr_alert("page last free stack trace:\n");
+ stack_trace_print(entries, nr_entries, 0);
+ }
}
#endif
--
2.23.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
* [PATCH V6 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan @ 2019-09-16 9:44 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
From: Peng Fan <peng.fan@nxp.com>
V6:
Switch to per-channel a mbox controller
Drop arm,num-chans, transports, method
Add arm,hvc-mbox compatible
Fix smc/hvc args, drop client id and use correct type.
V5:
yaml fix
https://patchwork.kernel.org/cover/11117741/
V4:
yaml fix for num-chans in patch 1/2.
https://patchwork.kernel.org/cover/11116521/
V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
https://patchwork.kernel.org/cover/11043541/
V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.
[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.
The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.
The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.
This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.
This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.
Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.
Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.
[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi
Peng Fan (2):
dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
mailbox: introduce ARM SMC based mailbox
.../devicetree/bindings/mailbox/arm-smc.yaml | 96 ++++++++++++
drivers/mailbox/Kconfig | 7 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 167 +++++++++++++++++++++
4 files changed, 272 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
--
2.16.4
_______________________________________________
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 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-09-16 9:44 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <1568626884-5189-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
.../devicetree/bindings/mailbox/arm-smc.yaml | 96 ++++++++++++++++++++++
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index 000000000000..bf01bec035fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. The value of r0/w0/x0
+ the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so synchronous communication can be
+ established. The exact meaning of the action the mailbox triggers as
+ well as the return value is defined by their users and is not subject
+ to this binding.
+
+ One use case of this mailbox is the SCMI interface, which uses shared
+ memory to transfer commands and parameters, and a mailbox to trigger a
+ function call. This allows SoCs without a separate management processor
+ (or when such a processor is not available or used) to use this
+ standardized interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using one of the described SMC function identifiers,
+ the firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifiers are passed from consumers, or listed in the the arm,func-ids
+ properties as described below. The firmware can return one value in
+ the first SMC result register, it is expected to be an error value,
+ which shall be propagated to the mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long
+ as a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+ oneOf:
+ - description:
+ For implementations using ARM SMC instruction.
+ const: arm,smc-mbox
+
+ - description:
+ For implementations using ARM HVC instruction.
+ const: arm,hvc-mbox
+
+ "#mbox-cells":
+ const: 1
+
+ arm,func-id:
+ description: |
+ An 32-bit value specifying the function ID used by the mailbox.
+ The function ID follow the ARM SMC calling convention standard [1].
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - "#mbox-cells"
+
+examples:
+ - |
+ sram@93f000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+ };
+ };
+
+ smc_tx_mbox: tx_mbox {
+ #mbox-cells = <1>;
+ compatible = "arm,smc-mbox";
+ /* optional */
+ arm,func-id = <0xc20000fe>;
+ };
+
+ firmware {
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = <&smc_tx_mbox 0>;
+ mbox-names = "tx";
+ shmem = <&cpu_scp_lpri>;
+ };
+ };
+
+...
--
2.16.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 V6 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-09-16 9:44 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <1568626884-5189-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 167 ++++++++++++++++++++++++++++++++++++++
3 files changed, 176 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 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_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) += armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index 000000000000..c84aef39c8d9
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/interrupt.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+struct arm_smc_chan_data {
+ unsigned int function_id;
+};
+
+struct arm_smccc_mbox_cmd {
+ unsigned int function_id;
+ union {
+ unsigned int args_smccc32[6];
+ unsigned long args_smccc64[6];
+ };
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+ u32 function_id;
+
+ function_id = chan_data->function_id;
+ if (!function_id)
+ function_id = cmd->function_id;
+
+ if (function_id & BIT(30)) {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0],
+ cmd->args_smccc64[1],
+ cmd->args_smccc64[2],
+ cmd->args_smccc64[3],
+ cmd->args_smccc64[4],
+ cmd->args_smccc64[5]);
+ } else {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0],
+ cmd->args_smccc32[1],
+ cmd->args_smccc32[2],
+ cmd->args_smccc32[3],
+ cmd->args_smccc32[4],
+ cmd->args_smccc32[5]);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned int function_id,
+ unsigned long arg0, unsigned long arg1,
+ unsigned long arg2, unsigned long arg3,
+ unsigned long arg4, unsigned long arg5)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, &res);
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned int function_id,
+ unsigned long arg0, unsigned long arg1,
+ unsigned long arg2, unsigned long arg3,
+ unsigned long arg4, unsigned long arg5)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, &res);
+ return res.a0;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+ .send_data = arm_smc_send_data,
+};
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mbox_controller *mbox;
+ struct arm_smc_chan_data *chan_data;
+ int ret;
+ u32 function_id = 0;
+
+ if (of_device_is_compatible(dev->of_node, "arm,smc-mbox"))
+ invoke_smc_mbox_fn = __invoke_fn_smc;
+ else
+ invoke_smc_mbox_fn = __invoke_fn_hvc;
+
+ mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+
+ mbox->num_chans = 1;
+ mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans), GFP_KERNEL);
+ if (!mbox->chans)
+ return -ENOMEM;
+
+ chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL);
+ if (!chan_data)
+ return -ENOMEM;
+
+ of_property_read_u32(dev->of_node, "arm,func-id", &function_id);
+ chan_data->function_id = function_id;
+
+ mbox->chans->con_priv = chan_data;
+
+ mbox->txdone_poll = false;
+ mbox->txdone_irq = false;
+ mbox->ops = &arm_smc_mbox_chan_ops;
+ mbox->dev = dev;
+
+ platform_set_drvdata(pdev, mbox);
+
+ ret = devm_mbox_controller_register(dev, mbox);
+ if (ret)
+ return ret;
+
+ dev_info(dev, "ARM SMC mailbox enabled.\n");
+
+ return ret;
+}
+
+static int arm_smc_mbox_remove(struct platform_device *pdev)
+{
+ struct mbox_controller *mbox = platform_get_drvdata(pdev);
+
+ mbox_controller_unregister(mbox);
+ return 0;
+}
+
+static const struct of_device_id arm_smc_mbox_of_match[] = {
+ { .compatible = "arm,smc-mbox", },
+ { .compatible = "arm,hvc-mbox", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
+
+static struct platform_driver arm_smc_mbox_driver = {
+ .driver = {
+ .name = "arm-smc-mbox",
+ .of_match_table = arm_smc_mbox_of_match,
+ },
+ .probe = arm_smc_mbox_probe,
+ .remove = arm_smc_mbox_remove,
+};
+module_platform_driver(arm_smc_mbox_driver);
+
+MODULE_AUTHOR("Peng Fan <peng.fan@nxp.com>");
+MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
+MODULE_LICENSE("GPL v2");
--
2.16.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
* Re: [PATCH 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
From: Lukasz Luba @ 2019-09-16 9:49 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski
Cc: mark.rutland, devicetree, willy.mh.wolff.ml,
linux-samsung-soc@vger.kernel.org,
Bartłomiej Żołnierkiewicz, linux-pm,
linux-kernel@vger.kernel.org, Chanwoo Choi, kyungmin.park, kgene,
myungjoo.ham, s.nawrocki, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <5d7ba95a.1c69fb81.bfd81.77ba@mx.google.com>
Hi Rob,
On 9/13/19 4:36 PM, Rob Herring wrote:
> On Fri, Sep 06, 2019 at 01:50:26PM +0200, Krzysztof Kozlowski wrote:
>> On Fri, 6 Sep 2019 at 13:39, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>>
>>> Hi Krzysztof,
>>>
>>> On 9/6/19 12:56 PM, Krzysztof Kozlowski wrote:
>>>> On Fri, 6 Sep 2019 at 12:14, Lukasz Luba <l.luba@partner.samsung.com> wrote:
>>>>>
>>>>> Add description of bindings for Samsung k3qf2f20db LPDDR3 memory.
>>>>> Minor fixes in the old documentation.
>>>>>
>>>>> Signed-off-by: Lukasz Luba <l.luba@partner.samsung.com>
>>>>> ---
>>>>> .../devicetree/bindings/ddr/lpddr3.txt | 29 +++++++++++++++++--
>>>>> 1 file changed, 27 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt b/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>>> index 3b2485b84b3f..de0905239767 100644
>>>>> --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>>> +++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt
>>>>> @@ -40,10 +40,34 @@ Child nodes:
>>>>> a given speed-bin. Please see Documentation/devicetree/
>>>>> bindings/ddr/lpddr3-timings.txt for more information on "lpddr3-timings"
>>>>>
>>>>> +Samsung K3QF2F20DB LPDDR3 memory
>>>>> +------------------------------------------------------------
>>>>> +
>>>>> +This binding uses the LPDDR3 binding (described above)
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible: Should be:
>>>>> + "samsung,K3QF2F20DB"
>>>>> + followed by "jedec,lpddr3"
>>>>> +- density : <u32> representing density in Mb (Mega bits)
>>>>> +- io-width : <u32> representing bus width. Possible value 32
>>>>> +- #address-cells: Must be set to 1
>>>>> +- #size-cells: Must be set to 0
>>>>
>>>> If you decided to repeat all properties again, then it deserves its
>>>> own bindings file. However I though about simpler solution - just
>>>> document compatible. Exactly the same as AT24 or AT25 EEPROM bindings.
>>>> There is not much benefit from copying all these properties.
>>> OK, I see. I will add only 'compatible' and skip the rest then.
>>> So the lpddr3.txt file will get this addition:
>>>
>>> +Samsung K3QF2F20DB LPDDR3 memory
>>> +------------------------------------------------------------
>>> +
>>> +This binding uses the LPDDR3 binding (described above)
>>> +
>>> +Required properties:
>>> +- compatible: Should be:
>>> + "samsung,K3QF2F20DB"
>>> + followed by "jedec,lpddr3"
>>> +
>>> +Optional properties:
>>> +
>>> +The optional properties are the same as in the LPDDR3 generic bindings and
>>> +values should be taken from the data-sheet. Detailed bindings are described
>>> +above.
>>> +
>>> +Child nodes:
>>> +
>>> +Detailed bindings are described in LPDDR3 generic bindings described above.
>>> +
>>>
>>> Is it OK?
>>
>> To me it is still a lot of text just for one compatible and I can
>> image more of such entries for other memories... However I do not mind
>> and anyway, YAML will simplify it. If you're in doubt, wait for Rob's
>> reply as this is his part.
>
> We can't have multiple (top-level) schema in one file, so better to add
> in where the existing compatible strings are.
Thank you for your comment. I will add the needed string into existing
compatible then.
Regards,
Lukasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V3] arm: xen: mm: use __GPF_DMA32 for arm64
From: Peng Fan @ 2019-09-16 9:51 UTC (permalink / raw)
To: sstabellini@kernel.org, linux@armlinux.org.uk,
catalin.marinas@arm.com, will@kernel.org, robin.murphy@arm.com
Cc: xen-devel@lists.xenproject.org, Peng Fan, dl-linux-imx,
linux-arm-kernel@lists.infradead.org
From: Peng Fan <peng.fan@nxp.com>
arm64 shares some code under arch/arm/xen, including mm.c.
However ZONE_DMA is removed by commit
ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
So add a check if CONFIG_ZONE_DMA32 is enabled use __GFP_DMA32.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
V3:
Use IS_ENABLED(CONFIG_ZONE_DMA32) and drop xen_set_gfp_dma.
V2:
Follow suggestion from Stefano,
introduce static inline void xen_set_gfp_dma(gfp_t *flags) for arm32/arm64, and
for arm64 using __GFP_DMA for the former and __GFP_DMA32 for the latter.
arch/arm/xen/mm.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 2b2c208408bb..38fa917c8585 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -28,7 +28,10 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
for_each_memblock(memory, reg) {
if (reg->base < (phys_addr_t)0xffffffff) {
- flags |= __GFP_DMA;
+ if (IS_ENABLED(CONFIG_ZONE_DMA32))
+ flags |= __GFP_DMA32;
+ else
+ flags |= __GFP_DMA;
break;
}
}
--
2.16.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
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