* Re: [PATCH 1/5] drm/sun4i: tcon: Introduce LVDS setup routine setting
From: Maxime Ripard @ 2020-02-20 17:21 UTC (permalink / raw)
To: Andrey Lebedev
Cc: wens, airlied, daniel, dri-devel, linux-arm-kernel, linux-kernel,
linux-sunxi, Andrey Lebedev
In-Reply-To: <20200219180858.4806-2-andrey.lebedev@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]
On Wed, Feb 19, 2020 at 08:08:54PM +0200, Andrey Lebedev wrote:
> From: Andrey Lebedev <andrey@lebedev.lt>
>
> Different sunxi flavors require slightly different sequence for enabling
> LVDS output. This allows to differentiate between them.
>
> Signed-off-by: Andrey Lebedev <andrey@lebedev.lt>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 68 ++++++++++++++++--------------
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 3 ++
> 2 files changed, 39 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index c81cdce6ed55..cc6b05ca2c69 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -114,46 +114,48 @@ static void sun4i_tcon_channel_set_status(struct sun4i_tcon *tcon, int channel,
> }
> }
>
> +static void sun6i_tcon_setup_lvds_phy(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + u8 val;
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> + SUN6I_TCON0_LVDS_ANA0_C(2) |
> + SUN6I_TCON0_LVDS_ANA0_V(3) |
> + SUN6I_TCON0_LVDS_ANA0_PD(2) |
> + SUN6I_TCON0_LVDS_ANA0_EN_LDO);
> + udelay(2);
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> + SUN6I_TCON0_LVDS_ANA0_EN_MB,
> + SUN6I_TCON0_LVDS_ANA0_EN_MB);
> + udelay(2);
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> + SUN6I_TCON0_LVDS_ANA0_EN_DRVC,
> + SUN6I_TCON0_LVDS_ANA0_EN_DRVC);
> +
> + if (sun4i_tcon_get_pixel_depth(encoder) == 18)
> + val = 7;
> + else
> + val = 0xf;
> +
> + regmap_write_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> + SUN6I_TCON0_LVDS_ANA0_EN_DRVD(0xf),
> + SUN6I_TCON0_LVDS_ANA0_EN_DRVD(val));
> +
> +}
> +
There's an extra blank line here that was reported by checkpatch. I've
fixed it up while applying.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v8 0/6] arm/arm64: mediatek: Fix mmsys device probing
From: Enric Balletbo i Serra @ 2020-02-20 17:21 UTC (permalink / raw)
To: robh+dt, mark.rutland, ck.hu, p.zabel, airlied, mturquette, sboyd,
ulrich.hecht+renesas, laurent.pinchart
Cc: Mauro Carvalho Chehab, rdunlap, dri-devel, Weiyi Lu, Seiya Wang,
linux-clk, Collabora Kernel ML, mtk01761, Allison Randal,
Thomas Gleixner, wens, Kate Stewart, Greg Kroah-Hartman,
Houlong Wei, Matthias Brugger, linux-media, devicetree, sean.wang,
frank-w, Minghsiu Tsai, Andrew-CT Chen, linux-mediatek, hsinyi,
Matthias Brugger, linux-arm-kernel, Richard Fontana, linux-kernel,
matthias.bgg, Daniel Vetter, Fabien Parent, Krzysztof Kozlowski,
Nicolas Boichat, Owen Chen
Dear all,
Those patches are intended to solve an old standing issue on some
Mediatek devices (mt8173, mt2701 and mt2712) in a slightly different way
to the precedent series.
Up to now both drivers, clock and drm are probed with the same device tree
compatible. But only the first driver get probed, which in effect breaks
graphics on those devices.
The version eight of the series tries to solve the problem with a
different approach than the previous series but similar to how is solved
on other Mediatek devices.
The MMSYS (Multimedia subsystem) in Mediatek SoCs has some registers to
control clock gates (which is used in the clk driver) and some registers
to set the routing and enable the differnet blocks of the display
and MDP (Media Data Path) subsystem. On this series the clk driver is
not a pure clock controller but a system controller that can provide
access to the shared registers between the different drivers that need
it (mediatek-drm and mediatek-mdp). And the biggest change is, that in
this version, clk driver is the entry point (parent) which will trigger
the probe of the corresponding mediatek-drm driver and pass its MMSYS
platform data for display configuration.
All this series was tested on the Acer R13 Chromebook only.
For reference, here are the links to the old discussions:
* v7: https://patchwork.kernel.org/project/linux-mediatek/list/?series=241217
* v6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219
* v5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=44063
* v4:
* https://patchwork.kernel.org/patch/10530871/
* https://patchwork.kernel.org/patch/10530883/
* https://patchwork.kernel.org/patch/10530885/
* https://patchwork.kernel.org/patch/10530911/
* https://patchwork.kernel.org/patch/10530913/
* v3:
* https://patchwork.kernel.org/patch/10367857/
* https://patchwork.kernel.org/patch/10367861/
* https://patchwork.kernel.org/patch/10367877/
* https://patchwork.kernel.org/patch/10367875/
* https://patchwork.kernel.org/patch/10367885/
* https://patchwork.kernel.org/patch/10367883/
* https://patchwork.kernel.org/patch/10367889/
* https://patchwork.kernel.org/patch/10367907/
* https://patchwork.kernel.org/patch/10367909/
* https://patchwork.kernel.org/patch/10367905/
* v2: No relevant discussion, see v3
* v1:
* https://patchwork.kernel.org/patch/10016497/
* https://patchwork.kernel.org/patch/10016499/
* https://patchwork.kernel.org/patch/10016505/
* https://patchwork.kernel.org/patch/10016507/
Best regards,
Enric
Changes in v8:
- Be a builtin_platform_driver like other mediatek mmsys drivers.
- New patches introduced in this series.
Changes in v7:
- Add R-by from CK
- Add R-by from CK
- Fix check of return value of of_clk_get
- Fix identation
- Free clk_data->clks as well
- Get rid of private data structure
Enric Balletbo i Serra (2):
drm/mediatek: Move MMSYS configuration to include/linux/platform_data
clk/drm: mediatek: Fix mediatek-drm device probing
Matthias Brugger (4):
drm/mediatek: Use regmap for register access
drm/mediatek: Omit warning on probe defers
media: mtk-mdp: Check return value of of_clk_get
clk: mediatek: mt8173: Switch MMSYS to platform driver
drivers/clk/mediatek/Kconfig | 6 +
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt2701-mm.c | 30 +++
drivers/clk/mediatek/clk-mt2712-mm.c | 44 +++++
drivers/clk/mediatek/clk-mt8173-mm.c | 172 ++++++++++++++++++
drivers/clk/mediatek/clk-mt8173.c | 104 -----------
drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +-
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +-
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 12 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 53 +++---
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 56 +-----
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 113 +-----------
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 13 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 8 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +-
drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 6 +
include/linux/platform_data/mtk_mmsys.h | 73 ++++++++
20 files changed, 401 insertions(+), 317 deletions(-)
create mode 100644 drivers/clk/mediatek/clk-mt8173-mm.c
create mode 100644 include/linux/platform_data/mtk_mmsys.h
--
2.25.0
^ permalink raw reply
* Re: [PATCH 2/2 v3] leds: ns2: Convert to GPIO descriptors
From: Dan Murphy @ 2020-02-20 17:16 UTC (permalink / raw)
To: Linus Walleij, Jacek Anaszewski, Pavel Machek
Cc: linux-leds, Vincent Donnefort, Simon Guinot
In-Reply-To: <20200220150833.56542-2-linus.walleij@linaro.org>
Linus
On 2/20/20 9:08 AM, Linus Walleij wrote:
> This converts the NS2 LED driver to use GPIO descriptors.
> We take care to request the GPIOs "as is" which is what
> the current driver goes to lengths to achieve, then we use
> GPIOs throughout.
>
> As the nodes for each LED does not have any corresponding
> device, we need to use the DT-specific accessors to get these
> GPIO descriptors from the device tree.
>
> Cc: Vincent Donnefort <vdonnefort@gmail.com>
> Tested-by: Simon Guinot <simon.guinot@sequanux.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
Reviewed-by: Dan Murphy <dmurphy@ti.com>
^ permalink raw reply
* Re: [PATCH 1/2 v3] leds: ns2: Absorb platform data
From: Dan Murphy @ 2020-02-20 17:16 UTC (permalink / raw)
To: Linus Walleij, Jacek Anaszewski, Pavel Machek
Cc: linux-leds, Vincent Donnefort, Simon Guinot
In-Reply-To: <20200220150833.56542-1-linus.walleij@linaro.org>
Linus
On 2/20/20 9:08 AM, Linus Walleij wrote:
> Nothing in the kernel includes the external header
> <linux/platform_data/leds-kirkwood-ns2.h> so just push the
> contents into the ns2 leds driver. If someone wants to use
> platform data or board files to describe this device they
> should be able to do so using GPIO machine descriptors but
> in any case device tree should be the way forward for these
> systems in all cases I can think of, and the driver already
> supports that.
>
> Cc: Vincent Donnefort <vdonnefort@gmail.com>
> Tested-by: Simon Guinot <simon.guinot@sequanux.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
Reviewed-by: Dan Murphy <dmurphy@ti.com>
^ permalink raw reply
* Re: [PATCH 1/2] dma-mapping: support setting memory uncached in place
From: Robin Murphy @ 2020-02-20 17:21 UTC (permalink / raw)
To: Christoph Hellwig, Jonas Bonn, Stefan Kristiansson,
Stafford Horne
Cc: Mark Rutland, linux-arch, linux-kernel, iommu, openrisc,
Will Deacon, linux-arm-kernel
In-Reply-To: <20200220170139.387354-2-hch@lst.de>
On 20/02/2020 5:01 pm, Christoph Hellwig wrote:
> We currently only support remapping memory as uncached through vmap
> or a magic uncached segment provided by some architectures. But there
> is a simpler and much better way available on some architectures where
> we can just remap the memory in place. The advantages are:
>
> 1) no aliasing is possible, which prevents speculating into the
> cached alias
> 2) there is no need to allocate new ptes and thus no need for a special
> pre-allocated pool of memory that can be used with GFP_ATOMIC DMA
> allocations
>
> The downside is that architectures must provide a way to set arbitrary
> pages uncached in the kernel mapping, which might not be possible on
> architecture that have a special implicit kernel mapping, and requires
> splitting of huge page kernel mappings where they exist.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/dma-noncoherent.h | 3 +++
> kernel/dma/Kconfig | 8 ++++++++
> kernel/dma/direct.c | 28 ++++++++++++++++++----------
> 3 files changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
> index ca9b5770caee..0820ec58f119 100644
> --- a/include/linux/dma-noncoherent.h
> +++ b/include/linux/dma-noncoherent.h
> @@ -111,4 +111,7 @@ static inline void arch_dma_prep_coherent(struct page *page, size_t size)
> void *uncached_kernel_address(void *addr);
> void *cached_kernel_address(void *addr);
>
> +int arch_dma_set_uncached(void *cpu_addr, size_t size);
> +void arch_dma_clear_uncached(void *cpu_addr, size_t size);
> +
> #endif /* _LINUX_DMA_NONCOHERENT_H */
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 4c103a24e380..7bc0b77f1243 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -83,6 +83,14 @@ config DMA_DIRECT_REMAP
> bool
> select DMA_REMAP
>
> +#
> +# Should be selected if the architecture can remap memory from the page
> +# allocator and CMA as uncached and provides the arch_dma_set_uncached and
> +# arch_dma_clear_uncached helpers
> +#
> +config ARCH_HAS_DMA_SET_UNCACHED
> + bool
> +
> config DMA_CMA
> bool "DMA Contiguous Memory Allocator"
> depends on HAVE_DMA_CONTIGUOUS && CMA
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 6af7ae83c4ad..73fe65a4cbc0 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -169,11 +169,8 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> ret = dma_common_contiguous_remap(page, PAGE_ALIGN(size),
> dma_pgprot(dev, PAGE_KERNEL, attrs),
> __builtin_return_address(0));
> - if (!ret) {
> - dma_free_contiguous(dev, page, size);
> - return ret;
> - }
> -
> + if (!ret)
> + goto out_free_pages;
> memset(ret, 0, size);
> goto done;
> }
> @@ -186,8 +183,7 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> * so log an error and fail.
> */
> dev_info(dev, "Rejecting highmem page from CMA.\n");
> - dma_free_contiguous(dev, page, size);
> - return NULL;
> + goto out_free_pages;
> }
>
> ret = page_address(page);
> @@ -196,10 +192,15 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
>
> memset(ret, 0, size);
>
> - if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> - dma_alloc_need_uncached(dev, attrs)) {
> + if (dma_alloc_need_uncached(dev, attrs)) {
> arch_dma_prep_coherent(page, size);
> - ret = uncached_kernel_address(ret);
> +
> + if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) {
> + if (!arch_dma_set_uncached(ret, size))
> + goto out_free_pages;
> + } else if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT)) {
> + ret = uncached_kernel_address(ret);
Hmm, would we actually need to keep ARCH_HAS_UNCACHED_SEGMENT? If
arch_dma_set_uncached() returned void*/ERR_PTR instead, then it could
work for both cases (with arch_dma_clear_uncached() being a no-op for
segments).
Robin.
> + }
> }
> done:
> if (force_dma_unencrypted(dev))
> @@ -207,6 +208,9 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> else
> *dma_handle = phys_to_dma(dev, page_to_phys(page));
> return ret;
> +out_free_pages:
> + dma_free_contiguous(dev, page, size);
> + return NULL;
> }
>
> void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
> @@ -230,6 +234,8 @@ void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
>
> if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr))
> vunmap(cpu_addr);
> + else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
> + arch_dma_clear_uncached(cpu_addr, size);
>
> dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size);
> }
> @@ -238,6 +244,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> dma_alloc_need_uncached(dev, attrs))
> return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
> @@ -248,6 +255,7 @@ void dma_direct_free(struct device *dev, size_t size,
> void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
> {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> dma_alloc_need_uncached(dev, attrs))
> arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [PATCH 1/2] dma-mapping: support setting memory uncached in place
From: Robin Murphy @ 2020-02-20 17:21 UTC (permalink / raw)
To: Christoph Hellwig, Jonas Bonn, Stefan Kristiansson,
Stafford Horne
Cc: Mark Rutland, linux-arch, linux-kernel, iommu, openrisc,
Will Deacon, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20200220170139.387354-2-hch@lst.de>
On 20/02/2020 5:01 pm, Christoph Hellwig wrote:
> We currently only support remapping memory as uncached through vmap
> or a magic uncached segment provided by some architectures. But there
> is a simpler and much better way available on some architectures where
> we can just remap the memory in place. The advantages are:
>
> 1) no aliasing is possible, which prevents speculating into the
> cached alias
> 2) there is no need to allocate new ptes and thus no need for a special
> pre-allocated pool of memory that can be used with GFP_ATOMIC DMA
> allocations
>
> The downside is that architectures must provide a way to set arbitrary
> pages uncached in the kernel mapping, which might not be possible on
> architecture that have a special implicit kernel mapping, and requires
> splitting of huge page kernel mappings where they exist.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/dma-noncoherent.h | 3 +++
> kernel/dma/Kconfig | 8 ++++++++
> kernel/dma/direct.c | 28 ++++++++++++++++++----------
> 3 files changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
> index ca9b5770caee..0820ec58f119 100644
> --- a/include/linux/dma-noncoherent.h
> +++ b/include/linux/dma-noncoherent.h
> @@ -111,4 +111,7 @@ static inline void arch_dma_prep_coherent(struct page *page, size_t size)
> void *uncached_kernel_address(void *addr);
> void *cached_kernel_address(void *addr);
>
> +int arch_dma_set_uncached(void *cpu_addr, size_t size);
> +void arch_dma_clear_uncached(void *cpu_addr, size_t size);
> +
> #endif /* _LINUX_DMA_NONCOHERENT_H */
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 4c103a24e380..7bc0b77f1243 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -83,6 +83,14 @@ config DMA_DIRECT_REMAP
> bool
> select DMA_REMAP
>
> +#
> +# Should be selected if the architecture can remap memory from the page
> +# allocator and CMA as uncached and provides the arch_dma_set_uncached and
> +# arch_dma_clear_uncached helpers
> +#
> +config ARCH_HAS_DMA_SET_UNCACHED
> + bool
> +
> config DMA_CMA
> bool "DMA Contiguous Memory Allocator"
> depends on HAVE_DMA_CONTIGUOUS && CMA
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 6af7ae83c4ad..73fe65a4cbc0 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -169,11 +169,8 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> ret = dma_common_contiguous_remap(page, PAGE_ALIGN(size),
> dma_pgprot(dev, PAGE_KERNEL, attrs),
> __builtin_return_address(0));
> - if (!ret) {
> - dma_free_contiguous(dev, page, size);
> - return ret;
> - }
> -
> + if (!ret)
> + goto out_free_pages;
> memset(ret, 0, size);
> goto done;
> }
> @@ -186,8 +183,7 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> * so log an error and fail.
> */
> dev_info(dev, "Rejecting highmem page from CMA.\n");
> - dma_free_contiguous(dev, page, size);
> - return NULL;
> + goto out_free_pages;
> }
>
> ret = page_address(page);
> @@ -196,10 +192,15 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
>
> memset(ret, 0, size);
>
> - if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> - dma_alloc_need_uncached(dev, attrs)) {
> + if (dma_alloc_need_uncached(dev, attrs)) {
> arch_dma_prep_coherent(page, size);
> - ret = uncached_kernel_address(ret);
> +
> + if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) {
> + if (!arch_dma_set_uncached(ret, size))
> + goto out_free_pages;
> + } else if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT)) {
> + ret = uncached_kernel_address(ret);
Hmm, would we actually need to keep ARCH_HAS_UNCACHED_SEGMENT? If
arch_dma_set_uncached() returned void*/ERR_PTR instead, then it could
work for both cases (with arch_dma_clear_uncached() being a no-op for
segments).
Robin.
> + }
> }
> done:
> if (force_dma_unencrypted(dev))
> @@ -207,6 +208,9 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> else
> *dma_handle = phys_to_dma(dev, page_to_phys(page));
> return ret;
> +out_free_pages:
> + dma_free_contiguous(dev, page, size);
> + return NULL;
> }
>
> void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
> @@ -230,6 +234,8 @@ void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
>
> if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr))
> vunmap(cpu_addr);
> + else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
> + arch_dma_clear_uncached(cpu_addr, size);
>
> dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size);
> }
> @@ -238,6 +244,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> dma_alloc_need_uncached(dev, attrs))
> return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
> @@ -248,6 +255,7 @@ void dma_direct_free(struct device *dev, size_t size,
> void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
> {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> dma_alloc_need_uncached(dev, attrs))
> arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
>
_______________________________________________
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] dma-mapping: support setting memory uncached in place
From: Robin Murphy @ 2020-02-20 17:21 UTC (permalink / raw)
To: Christoph Hellwig, Jonas Bonn, Stefan Kristiansson,
Stafford Horne
Cc: Marek Szyprowski, Will Deacon, Mark Rutland, openrisc, iommu,
linux-arm-kernel, linux-arch, linux-kernel
In-Reply-To: <20200220170139.387354-2-hch@lst.de>
On 20/02/2020 5:01 pm, Christoph Hellwig wrote:
> We currently only support remapping memory as uncached through vmap
> or a magic uncached segment provided by some architectures. But there
> is a simpler and much better way available on some architectures where
> we can just remap the memory in place. The advantages are:
>
> 1) no aliasing is possible, which prevents speculating into the
> cached alias
> 2) there is no need to allocate new ptes and thus no need for a special
> pre-allocated pool of memory that can be used with GFP_ATOMIC DMA
> allocations
>
> The downside is that architectures must provide a way to set arbitrary
> pages uncached in the kernel mapping, which might not be possible on
> architecture that have a special implicit kernel mapping, and requires
> splitting of huge page kernel mappings where they exist.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/dma-noncoherent.h | 3 +++
> kernel/dma/Kconfig | 8 ++++++++
> kernel/dma/direct.c | 28 ++++++++++++++++++----------
> 3 files changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
> index ca9b5770caee..0820ec58f119 100644
> --- a/include/linux/dma-noncoherent.h
> +++ b/include/linux/dma-noncoherent.h
> @@ -111,4 +111,7 @@ static inline void arch_dma_prep_coherent(struct page *page, size_t size)
> void *uncached_kernel_address(void *addr);
> void *cached_kernel_address(void *addr);
>
> +int arch_dma_set_uncached(void *cpu_addr, size_t size);
> +void arch_dma_clear_uncached(void *cpu_addr, size_t size);
> +
> #endif /* _LINUX_DMA_NONCOHERENT_H */
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 4c103a24e380..7bc0b77f1243 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -83,6 +83,14 @@ config DMA_DIRECT_REMAP
> bool
> select DMA_REMAP
>
> +#
> +# Should be selected if the architecture can remap memory from the page
> +# allocator and CMA as uncached and provides the arch_dma_set_uncached and
> +# arch_dma_clear_uncached helpers
> +#
> +config ARCH_HAS_DMA_SET_UNCACHED
> + bool
> +
> config DMA_CMA
> bool "DMA Contiguous Memory Allocator"
> depends on HAVE_DMA_CONTIGUOUS && CMA
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 6af7ae83c4ad..73fe65a4cbc0 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -169,11 +169,8 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> ret = dma_common_contiguous_remap(page, PAGE_ALIGN(size),
> dma_pgprot(dev, PAGE_KERNEL, attrs),
> __builtin_return_address(0));
> - if (!ret) {
> - dma_free_contiguous(dev, page, size);
> - return ret;
> - }
> -
> + if (!ret)
> + goto out_free_pages;
> memset(ret, 0, size);
> goto done;
> }
> @@ -186,8 +183,7 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> * so log an error and fail.
> */
> dev_info(dev, "Rejecting highmem page from CMA.\n");
> - dma_free_contiguous(dev, page, size);
> - return NULL;
> + goto out_free_pages;
> }
>
> ret = page_address(page);
> @@ -196,10 +192,15 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
>
> memset(ret, 0, size);
>
> - if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> - dma_alloc_need_uncached(dev, attrs)) {
> + if (dma_alloc_need_uncached(dev, attrs)) {
> arch_dma_prep_coherent(page, size);
> - ret = uncached_kernel_address(ret);
> +
> + if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) {
> + if (!arch_dma_set_uncached(ret, size))
> + goto out_free_pages;
> + } else if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT)) {
> + ret = uncached_kernel_address(ret);
Hmm, would we actually need to keep ARCH_HAS_UNCACHED_SEGMENT? If
arch_dma_set_uncached() returned void*/ERR_PTR instead, then it could
work for both cases (with arch_dma_clear_uncached() being a no-op for
segments).
Robin.
> + }
> }
> done:
> if (force_dma_unencrypted(dev))
> @@ -207,6 +208,9 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> else
> *dma_handle = phys_to_dma(dev, page_to_phys(page));
> return ret;
> +out_free_pages:
> + dma_free_contiguous(dev, page, size);
> + return NULL;
> }
>
> void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
> @@ -230,6 +234,8 @@ void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
>
> if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr))
> vunmap(cpu_addr);
> + else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
> + arch_dma_clear_uncached(cpu_addr, size);
>
> dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size);
> }
> @@ -238,6 +244,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> dma_alloc_need_uncached(dev, attrs))
> return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
> @@ -248,6 +255,7 @@ void dma_direct_free(struct device *dev, size_t size,
> void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
> {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> dma_alloc_need_uncached(dev, attrs))
> arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
>
^ permalink raw reply
* [OpenRISC] [PATCH 1/2] dma-mapping: support setting memory uncached in place
From: Robin Murphy @ 2020-02-20 17:21 UTC (permalink / raw)
To: openrisc
In-Reply-To: <20200220170139.387354-2-hch@lst.de>
On 20/02/2020 5:01 pm, Christoph Hellwig wrote:
> We currently only support remapping memory as uncached through vmap
> or a magic uncached segment provided by some architectures. But there
> is a simpler and much better way available on some architectures where
> we can just remap the memory in place. The advantages are:
>
> 1) no aliasing is possible, which prevents speculating into the
> cached alias
> 2) there is no need to allocate new ptes and thus no need for a special
> pre-allocated pool of memory that can be used with GFP_ATOMIC DMA
> allocations
>
> The downside is that architectures must provide a way to set arbitrary
> pages uncached in the kernel mapping, which might not be possible on
> architecture that have a special implicit kernel mapping, and requires
> splitting of huge page kernel mappings where they exist.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/dma-noncoherent.h | 3 +++
> kernel/dma/Kconfig | 8 ++++++++
> kernel/dma/direct.c | 28 ++++++++++++++++++----------
> 3 files changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
> index ca9b5770caee..0820ec58f119 100644
> --- a/include/linux/dma-noncoherent.h
> +++ b/include/linux/dma-noncoherent.h
> @@ -111,4 +111,7 @@ static inline void arch_dma_prep_coherent(struct page *page, size_t size)
> void *uncached_kernel_address(void *addr);
> void *cached_kernel_address(void *addr);
>
> +int arch_dma_set_uncached(void *cpu_addr, size_t size);
> +void arch_dma_clear_uncached(void *cpu_addr, size_t size);
> +
> #endif /* _LINUX_DMA_NONCOHERENT_H */
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 4c103a24e380..7bc0b77f1243 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -83,6 +83,14 @@ config DMA_DIRECT_REMAP
> bool
> select DMA_REMAP
>
> +#
> +# Should be selected if the architecture can remap memory from the page
> +# allocator and CMA as uncached and provides the arch_dma_set_uncached and
> +# arch_dma_clear_uncached helpers
> +#
> +config ARCH_HAS_DMA_SET_UNCACHED
> + bool
> +
> config DMA_CMA
> bool "DMA Contiguous Memory Allocator"
> depends on HAVE_DMA_CONTIGUOUS && CMA
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 6af7ae83c4ad..73fe65a4cbc0 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -169,11 +169,8 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> ret = dma_common_contiguous_remap(page, PAGE_ALIGN(size),
> dma_pgprot(dev, PAGE_KERNEL, attrs),
> __builtin_return_address(0));
> - if (!ret) {
> - dma_free_contiguous(dev, page, size);
> - return ret;
> - }
> -
> + if (!ret)
> + goto out_free_pages;
> memset(ret, 0, size);
> goto done;
> }
> @@ -186,8 +183,7 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> * so log an error and fail.
> */
> dev_info(dev, "Rejecting highmem page from CMA.\n");
> - dma_free_contiguous(dev, page, size);
> - return NULL;
> + goto out_free_pages;
> }
>
> ret = page_address(page);
> @@ -196,10 +192,15 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
>
> memset(ret, 0, size);
>
> - if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> - dma_alloc_need_uncached(dev, attrs)) {
> + if (dma_alloc_need_uncached(dev, attrs)) {
> arch_dma_prep_coherent(page, size);
> - ret = uncached_kernel_address(ret);
> +
> + if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) {
> + if (!arch_dma_set_uncached(ret, size))
> + goto out_free_pages;
> + } else if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT)) {
> + ret = uncached_kernel_address(ret);
Hmm, would we actually need to keep ARCH_HAS_UNCACHED_SEGMENT? If
arch_dma_set_uncached() returned void*/ERR_PTR instead, then it could
work for both cases (with arch_dma_clear_uncached() being a no-op for
segments).
Robin.
> + }
> }
> done:
> if (force_dma_unencrypted(dev))
> @@ -207,6 +208,9 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
> else
> *dma_handle = phys_to_dma(dev, page_to_phys(page));
> return ret;
> +out_free_pages:
> + dma_free_contiguous(dev, page, size);
> + return NULL;
> }
>
> void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
> @@ -230,6 +234,8 @@ void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
>
> if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr))
> vunmap(cpu_addr);
> + else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
> + arch_dma_clear_uncached(cpu_addr, size);
>
> dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size);
> }
> @@ -238,6 +244,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
> {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> dma_alloc_need_uncached(dev, attrs))
> return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
> @@ -248,6 +255,7 @@ void dma_direct_free(struct device *dev, size_t size,
> void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
> {
> if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) &&
> + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
> !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
> dma_alloc_need_uncached(dev, attrs))
> arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
>
^ permalink raw reply
* Re: [PATCH v2 1/2] RDMA/rw: fix error flow during RDMA context initialization
From: Jason Gunthorpe @ 2020-02-20 17:21 UTC (permalink / raw)
To: Max Gurtovoy; +Cc: leon, linux-rdma, israelr, logang
In-Reply-To: <20200220100819.41860-1-maxg@mellanox.com>
On Thu, Feb 20, 2020 at 12:08:18PM +0200, Max Gurtovoy wrote:
> In case the SGL was mapped for P2P DMA operation, we must unmap it using
> pci_p2pdma_unmap_sg.
>
> Fixes: 7f73eac3a713 ("PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg()")
> Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
> Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> ---
> drivers/infiniband/core/rw.c | 32 +++++++++++++++++++++-----------
> 1 file changed, 21 insertions(+), 11 deletions(-)
Applied to for-rc. The other one can go to -next in a bit as there is
no current bug
Jason
^ permalink raw reply
* Re: [alsa-devel] No sound since 5.4 on skl_n88l25_s4567
From: ojab // @ 2020-02-20 17:19 UTC (permalink / raw)
To: Pierre-Louis Bossart
Cc: Linux-ALSA, Mark Brown, Ranjani Sridharan, Kuninori Morimoto
In-Reply-To: <394de883-f044-44cb-9b09-a4fbe2e14b75@linux.intel.com>
On Tue, Feb 18, 2020 at 8:24 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
>
> On 2/17/20 9:10 AM, ojab // wrote:
> > On Thu, Jan 16, 2020 at 5:57 PM Mark Brown <broonie@kernel.org> wrote:
> >>
> >> On Wed, Jan 15, 2020 at 07:04:48PM -0600, Pierre-Louis Bossart wrote:
> >>
> >>> Maybe we could have some sort of boolean flag in the component->driver
> >>> definition and explicitly request a backwards-compatible behavior (e.g. for
> >>> all SKL/KBL machine drivers) when that driver is known to be flaky. There's
> >>> already things like 'fully_routed', maybe we can add something such as
> >>> 'disable_route_check'?
> >>
> >> A quirk for old stuff that can't be fixed sounds like a sensible
> >> solution to this.
> >
> > Any update on this?
>
> Sorry, this is what I had in mind (not even compile-tested). I don't
> know if the checks need to be disabled twice.
Unfortunately no sound with this patch on top of 5.6-rc2
http://alsa-project.org/db/?f=0f5049d8f7dc906bd13f354056282a48d2e626cc
//wbr ojab
^ permalink raw reply
* Re: [PATCH 12/19] target/arm: Remove ARM_FEATURE_VFP check from disas_vfp_insn
From: Peter Maydell @ 2020-02-20 17:19 UTC (permalink / raw)
To: Richard Henderson; +Cc: QEMU Developers
In-Reply-To: <20200214181547.21408-13-richard.henderson@linaro.org>
On Fri, 14 Feb 2020 at 18:16, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> We now have proper ISA checks within each trans_* function.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
> target/arm/translate.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/target/arm/translate.c b/target/arm/translate.c
> index 0da780102c..e8c3d4f26f 100644
> --- a/target/arm/translate.c
> +++ b/target/arm/translate.c
> @@ -2652,10 +2652,6 @@ static void gen_neon_dup_high16(TCGv_i32 var)
> */
> static int disas_vfp_insn(DisasContext *s, uint32_t insn)
> {
> - if (!arm_dc_feature(s, ARM_FEATURE_VFP)) {
> - return 1;
> - }
> -
> /*
> * If the decodetree decoder handles this insn it will always
> * emit code to either execute the insn or generate an appropriate
> --
> 2.20.1
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH 5/5] mt76: enable Airtime Queue Limit support
From: Sebastian Gottschall @ 2020-02-20 17:20 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Felix Fietkau, linux-wireless
In-Reply-To: <87lfoyw71d.fsf@toke.dk>
the interface is bridged to a bridge named br0 and owns the local lan ip.
its a typical setup. lan switch is bridged together with ap interface
iperf was not running on the device itself needs to be mentioned. i was
running iperf -s on a device which was connected by ethernet to this
device.
my client was a simple lenovo p52 laptop with a iwlwifi 9560 card wich
was using iperf -c x.x.x.x -P 32 -i 1
Am 19.02.2020 um 23:23 schrieb Toke Høiland-Jørgensen:
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> nope (iperf3 with 32 parallel streams after 5 seconds of running)
>>
>> STA 30:24:32💿f9:c4 AC 2 txq pending airtime underflow: 4294967208, 88
>> Modules linked in: fast_classifier mt7615e mt76 mac80211 compat
>> CPU: 3 PID: 1890 Comm: hostapd Not tainted 4.14.171 #187
>> Stack : 00000000 00000001 00000040 8007e454 80490000 8048bc8c 80610000
>> 805aee78
>> 8058850c 8770b864 870f289c 805f07a7 80582204 00000001 8770b808
>> 805f60a8
>> 00000000 00000000 80650000 00000000 81147bb8 0000011e 00000007
>> 00000000
>> 00000000 80660000 80660000 68203a6d 80000000 80610000 00000000
>> 873079ec
>> 873a4654 00000775 00000000 00000001 00000000 80230b88 0000000c
>> 8065000c
>> ...
>> Call Trace:
>> [<800153a0>] show_stack+0x58/0x100
>> [<80438c54>] dump_stack+0xa4/0xe0
>> [<80035050>] __warn+0xe4/0x144
>> [<80034c8c>] warn_slowpath_fmt+0x30/0x3c
>> [<873079ec>] _616+0x110/0x214 [mac80211]
>> [<87301ce0>] _535+0x15c/0x4f8 [mac80211]
>> [<804224f0>] br_handle_frame_finish+0x4e0/0x524
>> [<873d5160>] _49+0x50/0xa4 [mt76]
>> [<87606e30>] _61+0x1e8/0x224 [mt7615e]
> Huh, why is there a bridge function name in there in the middle of the
> callstack?
>
> -Toke
>
>
^ permalink raw reply
* Re: [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val
From: Sean Christopherson @ 2020-02-20 17:20 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: linmiaohe, kvm, linux-kernel, x86, pbonzini, rkrcmar, wanpengli,
jmattson, joro, tglx, mingo, bp, hpa
In-Reply-To: <8736b56wxe.fsf@vitty.brq.redhat.com>
On Thu, Feb 20, 2020 at 05:33:17PM +0100, Vitaly Kuznetsov wrote:
> linmiaohe <linmiaohe@huawei.com> writes:
>
> > From: Miaohe Lin <linmiaohe@huawei.com>
> >
> > When get user eoi value failed, var val would be uninitialized and result
> > in calculating pending eoi from an uninitialized val. Initialize var val
> > to 0 to fix this case.
>
> Let me try to suggest an alternative wording,
>
> "When pv_eoi_get_user() fails, 'val' may remain uninitialized and the
> return value of pv_eoi_get_pending() becomes random. Fix the issue by
> initializing the variable."
>
> >
> > Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> > ---
> > arch/x86/kvm/lapic.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 4f14ec7525f6..7e77e94f3176 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -626,7 +626,7 @@ static inline bool pv_eoi_enabled(struct kvm_vcpu *vcpu)
> >
> > static bool pv_eoi_get_pending(struct kvm_vcpu *vcpu)
> > {
> > - u8 val;
> > + u8 val = 0;
Rather than initialize @val, I'd prefer to explicitly handle the error,
similar to pv_eoi_clr_pending() and pv_eoi_set_pending(), e.g.
u8 val;
if (pv_eoi_get_user(vcpu, &val) < 0) {
printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
(unsigned long long)vcpu->arch.pv_eoi.msr_val);
return false;
}
return val & 0x1;
> > if (pv_eoi_get_user(vcpu, &val) < 0)
> > printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
> > (unsigned long long)vcpu->arch.pv_eoi.msr_val);
>
> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>
> But why compilers don't complain?
Clang might?
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 383/542] gpio: Fix the no return statement warning
From: Sasha Levin @ 2020-02-20 17:20 UTC (permalink / raw)
To: Kevin Hao
Cc: linux-kernel, stable, kbuild test robot, Linus Walleij,
linux-gpio
In-Reply-To: <20200215004455.GA499724@pek-khao-d2.corp.ad.wrs.com>
On Sat, Feb 15, 2020 at 08:44:55AM +0800, Kevin Hao wrote:
>On Fri, Feb 14, 2020 at 10:46:15AM -0500, Sasha Levin wrote:
>> From: Kevin Hao <haokexin@gmail.com>
>>
>> [ Upstream commit 9c6722d85e92233082da2b3623685bba54d6093e ]
>>
>> In commit 242587616710 ("gpiolib: Add support for the irqdomain which
>> doesn't use irq_fwspec as arg") we have changed the return type of
>> gpiochip_populate_parent_fwspec_twocell/fourcell() from void to void *,
>> but forgot to add a return statement for these two dummy functions.
>> Add "return NULL" to fix the build warnings.
>>
>> Reported-by: kbuild test robot <lkp@intel.com>
>> Signed-off-by: Kevin Hao <haokexin@gmail.com>
>> Link: https://lore.kernel.org/r/20200116095003.30324-1-haokexin@gmail.com
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>> include/linux/gpio/driver.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
>> index e2480ef94c559..5dce9c67a961e 100644
>> --- a/include/linux/gpio/driver.h
>> +++ b/include/linux/gpio/driver.h
>> @@ -553,6 +553,7 @@ static inline void gpiochip_populate_parent_fwspec_twocell(struct gpio_chip *chi
>> unsigned int parent_hwirq,
>> unsigned int parent_type)
>> {
>> + return NULL;
>
>Hi Sasha,
>
>This commit shouldn't go to the v5.5.x kernel. This is a fix for the
>commit 242587616710, but that commit doesn't exist in the v5.5.x kernel,
>then it will trigger a build warning due to the wrong returning type.
Now dropped, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v4 4/5] Add reftable library
From: Jonathan Nieder @ 2020-02-20 17:20 UTC (permalink / raw)
To: Han-Wen Nienhuys
Cc: Junio C Hamano, brian m. carlson,
Han-Wen Nienhuys via GitGitGadget, git, Han-Wen Nienhuys
In-Reply-To: <CAFQ2z_OF=P6YYuFkB5=4w0-nX+g59bagZGvcUBg_kSh-gOdAbQ@mail.gmail.com>
Han-Wen Nienhuys wrote:
> The ground truth for the format is the spec. The spec is part of the
> JGit repository, so it seems reasonable for it to be reviewed there.
> Do you want to move it somewhere else?
Let's stick a copy in Documentation/technical. I can send a patch to
Git to do that today, and we can update the doc in JGit to point to
Git's version as the canonical one.
Thanks,
Jonathan
^ permalink raw reply
* Re: [Xen-devel] [PATCH v6 1/6] libxl: add infrastructure to track and query 'recent' domids
From: Ian Jackson @ 2020-02-20 17:19 UTC (permalink / raw)
To: Durrant, Paul; +Cc: Anthony Perard, xen-devel@lists.xenproject.org, Wei Liu
In-Reply-To: <5dfcf708db764fd1bb970cae54321c9a@EX13D32EUC003.ant.amazon.com>
Durrant, Paul writes ("RE: [PATCH v6 1/6] libxl: add infrastructure to track and query 'recent' domids"):
> Not being co-located makes this somewhat tricky; I think it will basically still come down to me writing some code and then you saying whether that's what you meant... unless you can write some (pseudo-)code to illustrate? I think, from what you say below, I might now have a better idea of what you want so let's have one more go-around of me writing the code first :-)
OK.
> [Ian:]
> > I think the path needs to be passed into these functions. This is why
> > I think the functions need to take a struct* as an argument, for their
> > shared state (including the path and the other stuff).
>
> Ok, if that's the style you prefer I'll re-structure it that way.
My bottom line on this aspect of code structure is that I want each
thing to be written only once.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
From: Frédéric Pierret @ 2020-02-20 17:19 UTC (permalink / raw)
To: bskeggs, airlied, daniel, dri-devel, nouveau, linux-kernel
In-Reply-To: <dac89843-5258-5bed-ee86-7038e94e56da@qubes-os.org>
[-- Attachment #1.1: Type: text/plain, Size: 1464 bytes --]
Hi,
Is anything missing here? How can I get this merged?
Best regards,
Frédéric Pierret
On 2020-02-08 20:43, Frédéric Pierret wrote:
> Pointer to structure array is assumed not NULL by default. It has
> the consequence to raise a kernel panic when it's not the case.
>
> Basically, running at least a RTX2080TI on Xen makes a bad mmio error
> which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the
> code, it's assumed to be not NULL by accessing directly 'mthd->data[0]'
> which is the reason of the kernel panic. Simply check if the pointer
> is not NULL before continuing.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206299
> Cc: stable@vger.kernel.org
> Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org>
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> index bcf32d92ee5a..50e3539f33d2 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> @@ -74,6 +74,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
>
> if (debug > subdev->debug)
> return;
> + if (!mthd)
> + return;
>
> for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
> u32 base = chan->head * mthd->addr;
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
From: Frédéric Pierret @ 2020-02-20 17:19 UTC (permalink / raw)
To: bskeggs-H+wXaHxf7aLQT0dZR+AlfA, airlied-cv59FeDIM0c,
daniel-/w4YWyX8dFk, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <dac89843-5258-5bed-ee86-7038e94e56da-aAmZIGRXKFlg9hUCZPvPmw@public.gmane.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 1488 bytes --]
Hi,
Is anything missing here? How can I get this merged?
Best regards,
Frédéric Pierret
On 2020-02-08 20:43, Frédéric Pierret wrote:
> Pointer to structure array is assumed not NULL by default. It has
> the consequence to raise a kernel panic when it's not the case.
>
> Basically, running at least a RTX2080TI on Xen makes a bad mmio error
> which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the
> code, it's assumed to be not NULL by accessing directly 'mthd->data[0]'
> which is the reason of the kernel panic. Simply check if the pointer
> is not NULL before continuing.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206299
> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org>
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> index bcf32d92ee5a..50e3539f33d2 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
> @@ -74,6 +74,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
>
> if (debug > subdev->debug)
> return;
> + if (!mthd)
> + return;
>
> for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
> u32 base = chan->head * mthd->addr;
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 182 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* Re: [PATCHv10 02/13] PCI: mobiveil: Move the host initialization into a function
From: Andrew Murray @ 2020-02-20 17:19 UTC (permalink / raw)
To: Zhiqiang Hou
Cc: linux-pci, linux-arm-kernel, devicetree, linux-kernel, bhelgaas,
robh+dt, andrew.murray, arnd, mark.rutland, l.subrahmanya,
shawnguo, m.karthikeyan, leoyang.li, lorenzo.pieralisi,
catalin.marinas, will.deacon, Mingkai.Hu, Minghuan.Lian,
Xiaowei.Bao
In-Reply-To: <20200213040644.45858-3-Zhiqiang.Hou@nxp.com>
On Thu, Feb 13, 2020 at 12:06:33PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>
> Move the host initialization related operations into a new
> routine such that it can be reused by other incoming platform's
> PCIe host driver, in which the Mobiveil GPEX is integrated.
>
> Change the subject and change log slightly.
> Change the function mobiveil_pcie_host_probe to static.
> Add back the comments that was lost in v9.
Are these three lines above supposed to be in the history below the
--- ?
Perhaps Lorenzo can change that when he applies it.
Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> ---
> V10:
> - Refined the subject and change log.
> - Changed the mobiveil_pcie_host_probe() to a static function.
> - Added back the lost comments.
>
> drivers/pci/controller/pcie-mobiveil.c | 39 +++++++++++++++-----------
> 1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c b/drivers/pci/controller/pcie-mobiveil.c
> index d4de560cd711..01df04ea5b48 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -873,27 +873,15 @@ static int mobiveil_pcie_init_irq_domain(struct mobiveil_pcie *pcie)
> return 0;
> }
>
> -static int mobiveil_pcie_probe(struct platform_device *pdev)
> +static int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
> {
> - struct mobiveil_pcie *pcie;
> + struct mobiveil_root_port *rp = &pcie->rp;
> + struct pci_host_bridge *bridge = rp->bridge;
> + struct device *dev = &pcie->pdev->dev;
> struct pci_bus *bus;
> struct pci_bus *child;
> - struct pci_host_bridge *bridge;
> - struct device *dev = &pdev->dev;
> - struct mobiveil_root_port *rp;
> int ret;
>
> - /* allocate the PCIe port */
> - bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> - if (!bridge)
> - return -ENOMEM;
> -
> - pcie = pci_host_bridge_priv(bridge);
> - rp = &pcie->rp;
> - rp->bridge = bridge;
> -
> - pcie->pdev = pdev;
> -
> ret = mobiveil_pcie_parse_dt(pcie);
> if (ret) {
> dev_err(dev, "Parsing DT failed, ret: %x\n", ret);
> @@ -956,6 +944,25 @@ static int mobiveil_pcie_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static int mobiveil_pcie_probe(struct platform_device *pdev)
> +{
> + struct mobiveil_pcie *pcie;
> + struct pci_host_bridge *bridge;
> + struct device *dev = &pdev->dev;
> +
> + /* allocate the PCIe port */
> + bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> + if (!bridge)
> + return -ENOMEM;
> +
> + pcie = pci_host_bridge_priv(bridge);
> + pcie->rp.bridge = bridge;
> +
> + pcie->pdev = pdev;
> +
> + return mobiveil_pcie_host_probe(pcie);
> +}
> +
> static const struct of_device_id mobiveil_pcie_of_match[] = {
> {.compatible = "mbvl,gpex40-pcie",},
> {},
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCHv10 02/13] PCI: mobiveil: Move the host initialization into a function
From: Andrew Murray @ 2020-02-20 17:19 UTC (permalink / raw)
To: Zhiqiang Hou
Cc: mark.rutland, devicetree, lorenzo.pieralisi, m.karthikeyan, arnd,
linux-pci, l.subrahmanya, will.deacon, linux-kernel, leoyang.li,
Minghuan.Lian, robh+dt, Mingkai.Hu, Xiaowei.Bao, catalin.marinas,
bhelgaas, andrew.murray, shawnguo, linux-arm-kernel
In-Reply-To: <20200213040644.45858-3-Zhiqiang.Hou@nxp.com>
On Thu, Feb 13, 2020 at 12:06:33PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>
> Move the host initialization related operations into a new
> routine such that it can be reused by other incoming platform's
> PCIe host driver, in which the Mobiveil GPEX is integrated.
>
> Change the subject and change log slightly.
> Change the function mobiveil_pcie_host_probe to static.
> Add back the comments that was lost in v9.
Are these three lines above supposed to be in the history below the
--- ?
Perhaps Lorenzo can change that when he applies it.
Reviewed-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> ---
> V10:
> - Refined the subject and change log.
> - Changed the mobiveil_pcie_host_probe() to a static function.
> - Added back the lost comments.
>
> drivers/pci/controller/pcie-mobiveil.c | 39 +++++++++++++++-----------
> 1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c b/drivers/pci/controller/pcie-mobiveil.c
> index d4de560cd711..01df04ea5b48 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -873,27 +873,15 @@ static int mobiveil_pcie_init_irq_domain(struct mobiveil_pcie *pcie)
> return 0;
> }
>
> -static int mobiveil_pcie_probe(struct platform_device *pdev)
> +static int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
> {
> - struct mobiveil_pcie *pcie;
> + struct mobiveil_root_port *rp = &pcie->rp;
> + struct pci_host_bridge *bridge = rp->bridge;
> + struct device *dev = &pcie->pdev->dev;
> struct pci_bus *bus;
> struct pci_bus *child;
> - struct pci_host_bridge *bridge;
> - struct device *dev = &pdev->dev;
> - struct mobiveil_root_port *rp;
> int ret;
>
> - /* allocate the PCIe port */
> - bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> - if (!bridge)
> - return -ENOMEM;
> -
> - pcie = pci_host_bridge_priv(bridge);
> - rp = &pcie->rp;
> - rp->bridge = bridge;
> -
> - pcie->pdev = pdev;
> -
> ret = mobiveil_pcie_parse_dt(pcie);
> if (ret) {
> dev_err(dev, "Parsing DT failed, ret: %x\n", ret);
> @@ -956,6 +944,25 @@ static int mobiveil_pcie_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static int mobiveil_pcie_probe(struct platform_device *pdev)
> +{
> + struct mobiveil_pcie *pcie;
> + struct pci_host_bridge *bridge;
> + struct device *dev = &pdev->dev;
> +
> + /* allocate the PCIe port */
> + bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> + if (!bridge)
> + return -ENOMEM;
> +
> + pcie = pci_host_bridge_priv(bridge);
> + pcie->rp.bridge = bridge;
> +
> + pcie->pdev = pdev;
> +
> + return mobiveil_pcie_host_probe(pcie);
> +}
> +
> static const struct of_device_id mobiveil_pcie_of_match[] = {
> {.compatible = "mbvl,gpex40-pcie",},
> {},
> --
> 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: [Intel-gfx] [PATCH v2 7/7] drm/i915: Fix broken num_entries in skl_ddb_allocation_overlaps
From: Ville Syrjälä @ 2020-02-20 17:18 UTC (permalink / raw)
To: Anshuman Gupta; +Cc: jani.nikula, intel-gfx
In-Reply-To: <20200211172532.14287-8-anshuman.gupta@intel.com>
On Tue, Feb 11, 2020 at 10:55:32PM +0530, Anshuman Gupta wrote:
> skl_ddb_allocation_overlaps() num_entries hass been passed as
> INTEL_NUM_PIPES, it should be I915_MAX_PIPES.
>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 6fdaeb019fef..dd77324206bc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15475,7 +15475,6 @@ static void skl_commit_modeset_enables(struct intel_atomic_state *state)
> struct intel_crtc *crtc;
> struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
> - const u8 num_pipes = INTEL_NUM_PIPES(dev_priv);
> u8 update_pipes = 0, modeset_pipes = 0;
> int i;
>
> @@ -15512,7 +15511,7 @@ static void skl_commit_modeset_enables(struct intel_atomic_state *state)
> continue;
>
> if (skl_ddb_allocation_overlaps(&new_crtc_state->wm.skl.ddb,
> - entries, num_pipes, pipe))
> + entries, I915_MAX_PIPES, pipe))
> continue;
>
> entries[pipe] = new_crtc_state->wm.skl.ddb;
> @@ -15550,7 +15549,7 @@ static void skl_commit_modeset_enables(struct intel_atomic_state *state)
> continue;
>
> WARN_ON(skl_ddb_allocation_overlaps(&new_crtc_state->wm.skl.ddb,
> - entries, num_pipes, pipe));
> + entries, I915_MAX_PIPES, pipe));
>
> entries[pipe] = new_crtc_state->wm.skl.ddb;
> modeset_pipes &= ~BIT(pipe);
> @@ -15585,7 +15584,7 @@ static void skl_commit_modeset_enables(struct intel_atomic_state *state)
> continue;
>
> WARN_ON(skl_ddb_allocation_overlaps(&new_crtc_state->wm.skl.ddb,
> - entries, num_pipes, pipe));
> + entries, I915_MAX_PIPES, pipe));
>
> entries[pipe] = new_crtc_state->wm.skl.ddb;
> modeset_pipes &= ~BIT(pipe);
> --
> 2.24.0
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: driver: Replace zero-length array with flexible-array member
From: Sudeep Holla @ 2020-02-20 17:18 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20200211231045.GA13956@embeddedor>
On Tue, Feb 11, 2020 at 05:10:45PM -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertenly introduced[3] to the codebase from now on.
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied these 3 patches [0][1][2] for v5.7
--
Regards,
Sudeep
[0]: https://lore.kernel.org/r/20200211231604.GA17274@embeddedor
[1]: https://lore.kernel.org/r/20200211231252.GA14830@embeddedor
[2]: https://lore.kernel.org/r/20200211231045.GA13956@embeddedor
_______________________________________________
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] firmware: arm_scmi: driver: Replace zero-length array with flexible-array member
From: Sudeep Holla @ 2020-02-20 17:18 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <20200211231045.GA13956@embeddedor>
On Tue, Feb 11, 2020 at 05:10:45PM -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertenly introduced[3] to the codebase from now on.
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied these 3 patches [0][1][2] for v5.7
--
Regards,
Sudeep
[0]: https://lore.kernel.org/r/20200211231604.GA17274@embeddedor
[1]: https://lore.kernel.org/r/20200211231252.GA14830@embeddedor
[2]: https://lore.kernel.org/r/20200211231045.GA13956@embeddedor
^ permalink raw reply
* [Bug 206613] On hitting tab key from terminal against a directory name ending with ':\' doesnot shows files/dir inside it
From: bugzilla-daemon @ 2020-02-20 17:18 UTC (permalink / raw)
To: linux-ext4
In-Reply-To: <bug-206613-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=206613
Abhishek Srivastava (cubonix@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|On hitting tab key from |On hitting tab key from
|terminal against a |terminal against a
|directory name ending with |directory name ending with
|':\' doesnot shows |':\' doesnot shows
|files/dir inside it rather |files/dir inside it
|shows dir name itself |
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Double check bumping after the spinlock
From: Patchwork @ 2020-02-20 17:18 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20200220123608.1666271-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with [1/2] drm/i915: Double check bumping after the spinlock
URL : https://patchwork.freedesktop.org/series/73707/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> Patchwork_16645
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/index.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and Patchwork_16645:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 1 dmesg-warn(s) 13 pass(s) 22 skip(s)
- Exec time: [0.0, 0.22] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 1 dmesg-warn(s) 25 pass(s) 10 skip(s)
- Exec time: [0.0, 6.74] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 1 dmesg-warn(s) 25 pass(s) 10 skip(s)
- Exec time: [0.45, 17.72] s
* igt@i915_pm_rps@basic-api:
- Statuses : 31 pass(s) 5 skip(s)
- Exec time: [0.0, 0.02] s
Known issues
------------
Here are the changes found in Patchwork_16645 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_selftest@live_gtt:
- fi-hsw-4770r: [PASS][1] -> [TIMEOUT][2] ([fdo#112271])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-4770r/igt@i915_selftest@live_gtt.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-hsw-4770r/igt@i915_selftest@live_gtt.html
* igt@prime_self_import@basic-llseek-size:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([CI#94] / [i915#402]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@prime_self_import@basic-llseek-size.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-tgl-y/igt@prime_self_import@basic-llseek-size.html
#### Possible fixes ####
* igt@gem_exec_parallel@contexts:
- fi-byt-n2820: [FAIL][5] ([i915#694]) -> [PASS][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_exec_parallel@contexts.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-byt-n2820/igt@gem_exec_parallel@contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][7] ([i915#217]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@prime_self_import@basic-llseek-bad:
- fi-tgl-y: [DMESG-WARN][9] ([CI#94] / [i915#402]) -> [PASS][10] +1 similar issue
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-tgl-y/igt@prime_self_import@basic-llseek-bad.html
#### Warnings ####
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][11] ([fdo#109315]) -> [SKIP][12] ([fdo#109315] / [i915#585])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@amdgpu/amd_prime@amd-to-i915.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-icl-u3/igt@amdgpu/amd_prime@amd-to-i915.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][13] ([fdo#111407]) -> [FAIL][14] ([fdo#111096] / [i915#323])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
Participating hosts (49 -> 39)
------------------------------
Additional (4): fi-kbl-soraka fi-skl-lmem fi-ivb-3770 fi-pnv-d510
Missing (14): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-skl-6770hq fi-hsw-peppy fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-cfl-8109u fi-bsw-kefka fi-bdw-samus fi-bsw-nick fi-skl-6600u
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7973 -> Patchwork_16645
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16645: e5bc0f843da36cdc8a5b8fcdb5c692f14347dcb3 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e5bc0f843da3 drm/i915: Protect i915_request_await_start from early waits
00c160893898 drm/i915: Double check bumping after the spinlock
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16645/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.