* [PATCH v2 0/2] arm64: E0PD support
From: Mark Brown @ 2019-08-14 18:31 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: linux-arm-kernel, Suzuki K Poulose
This series adds support for E0PD. We enable E0PD unconditionally where
present and on systems where all the CPUs in the system support E0PD we
will not automatically enable KPTI for KASLR. The integration with KPTI
is safe but not optimal for big.LITTLE systems where only some CPUs
support E0PD since for them it will still use KPTI even on the CPUs that
have E0PD, I've not yet come up with something I like for integrating
support for them with the command line overrides.
Mark Brown (2):
arm64: Add initial support for E0PD
arm64: Don't use KPTI where we have E0PD
arch/arm64/Kconfig | 15 +++++++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/mmu.h | 13 ++++++++++++-
arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
arch/arm64/include/asm/sysreg.h | 1 +
arch/arm64/kernel/cpufeature.c | 29 ++++++++++++++++++++++++++++-
6 files changed, 60 insertions(+), 3 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 1/6] arm64: unexport set_memory_x and set_memory_nx
From: Christoph Hellwig @ 2019-08-14 18:22 UTC (permalink / raw)
To: Will Deacon
Cc: Dave Hansen, Peter Zijlstra, Catalin Marinas, x86, linux-kernel,
Andy Lutomirski, Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20190814165029.yfmpopn34vxpnmte@willie-the-truck>
On Wed, Aug 14, 2019 at 05:50:29PM +0100, Will Deacon wrote:
> arm64 allmodconfig and defconfig are happy with this, so I'll pick it up
> for 5.4 if that's ok with you?
Sounds great.
_______________________________________________
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 04/15] iommu/arm-smmu: Rework cb_base handling
From: Will Deacon @ 2019-08-14 18:05 UTC (permalink / raw)
To: Robin Murphy
Cc: robdclark, joro, bjorn.andersson, iommu, vivek.gautam,
gregory.clement, linux-arm-kernel
In-Reply-To: <f4dccad78815ca0a2dd7926be7052759d099b920.1565369764.git.robin.murphy@arm.com>
On Fri, Aug 09, 2019 at 06:07:41PM +0100, Robin Murphy wrote:
> To keep register-access quirks manageable, we want to structure things
> to avoid needing too many individual overrides. It seems fairly clean to
> have a single interface which handles both global and context registers
> in terms of the architectural pages, so the first preparatory step is to
> rework cb_base into a page number rather than an absolute address.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 22 ++++++++++++----------
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index d9a93e5f422f..463bc8d98adb 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -95,7 +95,7 @@
> #endif
>
> /* Translation context bank */
> -#define ARM_SMMU_CB(smmu, n) ((smmu)->cb_base + ((n) << (smmu)->pgshift))
> +#define ARM_SMMU_CB(smmu, n) ((smmu)->base + (((smmu)->cb_base + (n)) << (smmu)->pgshift))
>
> #define MSI_IOVA_BASE 0x8000000
> #define MSI_IOVA_LENGTH 0x100000
> @@ -168,8 +168,8 @@ struct arm_smmu_device {
> struct device *dev;
>
> void __iomem *base;
> - void __iomem *cb_base;
> - unsigned long pgshift;
> + unsigned int cb_base;
I think this is now a misnomer. Would you be able to rename it cb_pfn or
something, please?
Otherwise, this seems fine.
Will
_______________________________________________
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 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Mathieu Poirier @ 2019-08-14 18:04 UTC (permalink / raw)
To: Igor Lubashev
Cc: Suzuki K Poulose, Peter Zijlstra, Alexey Budankov,
Linux Kernel Mailing List, Arnaldo Carvalho de Melo, James Morris,
Alexander Shishkin, Ingo Molnar, Namhyung Kim, Jiri Olsa,
linux-arm-kernel
In-Reply-To: <291d2cda6ee75b4cd4c9ce717c177db18bf03a31.1565188228.git.ilubashe@akamai.com>
On Wed, 7 Aug 2019 at 08:44, Igor Lubashev <ilubashe@akamai.com> wrote:
>
> Kernel is using CAP_SYSLOG capability instead of uid==0 and euid==0 when
> checking kptr_restrict. Make perf do the same.
>
> Also, the kernel is a more restrictive than "no restrictions" in case of
> kptr_restrict==0, so add the same logic to perf.
>
> Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
> ---
> tools/perf/util/symbol.c | 15 +++++++++++----
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index 173f3378aaa0..046271103499 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -4,6 +4,7 @@
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> +#include <linux/capability.h>
> #include <linux/kernel.h>
> #include <linux/mman.h>
> #include <linux/time64.h>
> @@ -15,8 +16,10 @@
> #include <inttypes.h>
> #include "annotate.h"
> #include "build-id.h"
> +#include "cap.h"
> #include "util.h"
> #include "debug.h"
> +#include "event.h"
> #include "machine.h"
> #include "map.h"
> #include "symbol.h"
> @@ -890,7 +893,11 @@ bool symbol__restricted_filename(const char *filename,
> {
> bool restricted = false;
>
> - if (symbol_conf.kptr_restrict) {
> + /* Per kernel/kallsyms.c:
> + * we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
> + */
> + if (symbol_conf.kptr_restrict ||
> + (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))) {
> char *r = realpath(filename, NULL);
>
# echo 0 > /proc/sys/kernel/kptr_restrict
# ./tools/perf/perf record -e instructions:k uname
perf: Segmentation fault
Obtained 10 stack frames.
./tools/perf/perf(sighandler_dump_stack+0x44) [0x55af9e5da5d4]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7fd31efb6f20]
./tools/perf/perf(perf_event__synthesize_kernel_mmap+0xa7) [0x55af9e590337]
./tools/perf/perf(+0x1cf5be) [0x55af9e50c5be]
./tools/perf/perf(cmd_record+0x1022) [0x55af9e50dff2]
./tools/perf/perf(+0x23f98d) [0x55af9e57c98d]
./tools/perf/perf(+0x23fc9e) [0x55af9e57cc9e]
./tools/perf/perf(main+0x369) [0x55af9e4f6bc9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7fd31ef99b97]
./tools/perf/perf(_start+0x2a) [0x55af9e4f704a]
Segmentation fault
I can reproduce this on both x86 and ARM64.
> if (r != NULL) {
> @@ -2190,9 +2197,9 @@ static bool symbol__read_kptr_restrict(void)
> char line[8];
>
> if (fgets(line, sizeof(line), fp) != NULL)
> - value = ((geteuid() != 0) || (getuid() != 0)) ?
> - (atoi(line) != 0) :
> - (atoi(line) == 2);
> + value = perf_cap__capable(CAP_SYSLOG) ?
> + (atoi(line) >= 2) :
> + (atoi(line) != 0);
>
> fclose(fp);
> }
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Steve Capper @ 2019-08-14 17:53 UTC (permalink / raw)
To: Mark Rutland
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, Catalin Marinas,
bhsharma@redhat.com, maz@kernel.org, Andrey Ryabinin, nd,
Will Deacon, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814160324.GE51963@lakrids.cambridge.arm.com>
On Wed, Aug 14, 2019 at 05:03:24PM +0100, Mark Rutland wrote:
> On Wed, Aug 14, 2019 at 04:57:11PM +0100, Will Deacon wrote:
> > On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> > > On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > > index b2400f9c1213..2b7db0d41498 100644
> > > > --- a/arch/arm64/Makefile
> > > > +++ b/arch/arm64/Makefile
> > > > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > >
> > > > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > > > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > > > -# in 32-bit arithmetic
> > > > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > > > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > > > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > > > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > > > -
> > > > export TEXT_OFFSET GZFLAGS
> > > >
> > > > core-y += arch/arm64/kernel/ arch/arm64/mm/
> > >
> > > I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> > > CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> > > CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> > > CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> > > regardless.
> > >
> > > I think that's by accident rather than by design, but to
> > > minimize/localize the fixup, how about the below? I can send a cleanup
> > > patch for scripts/Makefile.kasan later.
> >
> > How much work is that? I've dropped this stuff from -next for now, so we
> > have time to fix it properly as long as it's not going to take weeks.
>
> I wrote it first, so no effort; patch below.
>
> Andrey, would you be happy with this?
>
> Thanks,
> Mark.
FWIW, this one worked well for me too (52-bit VA runtime, SW TAGS +
GENERIC both inlined).
Tested-by: Steve Capper <steve.capper@arm.com>
Cheers,
--
Steve
_______________________________________________
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 01/15] iommu/arm-smmu: Convert GR0 registers to bitfields
From: Robin Murphy @ 2019-08-14 17:35 UTC (permalink / raw)
To: Will Deacon
Cc: gregory.clement, iommu, bjorn.andersson, robdclark, vivek.gautam,
joro, linux-arm-kernel
In-Reply-To: <20190814172030.accr7azgkkkwumt2@willie-the-truck>
On 14/08/2019 18:20, Will Deacon wrote:
> On Fri, Aug 09, 2019 at 06:07:38PM +0100, Robin Murphy wrote:
>> FIELD_PREP remains a terrible name, but the overall simplification will
>> make further work on this stuff that much more manageable. This also
>> serves as an audit of the header, wherein we can impose a consistent
>> grouping and ordering of the offset and field definitions
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu-regs.h | 126 ++++++++++++++++------------------
>> drivers/iommu/arm-smmu.c | 51 +++++++-------
>> 2 files changed, 84 insertions(+), 93 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-regs.h b/drivers/iommu/arm-smmu-regs.h
>> index 1c278f7ae888..d189f025537a 100644
>> --- a/drivers/iommu/arm-smmu-regs.h
>> +++ b/drivers/iommu/arm-smmu-regs.h
>> @@ -10,111 +10,101 @@
>> #ifndef _ARM_SMMU_REGS_H
>> #define _ARM_SMMU_REGS_H
>>
>> +#include <linux/bits.h>
>> +
>> /* Configuration registers */
>> #define ARM_SMMU_GR0_sCR0 0x0
>> -#define sCR0_CLIENTPD (1 << 0)
>> -#define sCR0_GFRE (1 << 1)
>> -#define sCR0_GFIE (1 << 2)
>> -#define sCR0_EXIDENABLE (1 << 3)
>> -#define sCR0_GCFGFRE (1 << 4)
>> -#define sCR0_GCFGFIE (1 << 5)
>> -#define sCR0_USFCFG (1 << 10)
>> -#define sCR0_VMIDPNE (1 << 11)
>> -#define sCR0_PTM (1 << 12)
>> -#define sCR0_FB (1 << 13)
>> -#define sCR0_VMID16EN (1 << 31)
>> -#define sCR0_BSU_SHIFT 14
>> -#define sCR0_BSU_MASK 0x3
>> +#define sCR0_VMID16EN BIT(31)
>> +#define sCR0_BSU GENMASK(15, 14)
>> +#define sCR0_FB BIT(13)
>> +#define sCR0_PTM BIT(12)
>> +#define sCR0_VMIDPNE BIT(11)
>> +#define sCR0_USFCFG BIT(10)
>> +#define sCR0_GCFGFIE BIT(5)
>> +#define sCR0_GCFGFRE BIT(4)
>> +#define sCR0_EXIDENABLE BIT(3)
>> +#define sCR0_GFIE BIT(2)
>> +#define sCR0_GFRE BIT(1)
>> +#define sCR0_CLIENTPD BIT(0)
>>
>> /* Auxiliary Configuration register */
>> #define ARM_SMMU_GR0_sACR 0x10
>>
>> /* Identification registers */
>> #define ARM_SMMU_GR0_ID0 0x20
>> +#define ID0_S1TS BIT(30)
>> +#define ID0_S2TS BIT(29)
>> +#define ID0_NTS BIT(28)
>> +#define ID0_SMS BIT(27)
>> +#define ID0_ATOSNS BIT(26)
>> +#define ID0_PTFS_NO_AARCH32 BIT(25)
>> +#define ID0_PTFS_NO_AARCH32S BIT(24)
>> +#define ID0_CTTW BIT(14)
>> +#define ID0_NUMIRPT GENMASK(23, 16)
>
> nit: assuming this should be above ID0_CTTW so things are in descending
> bit order?
Bah, indeed it should. Fixed now.
> Other than that, looks good to me.
Thanks!
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 07/15] drm/mxsfb: Fix the vblank events
From: Daniel Vetter @ 2019-08-14 17:31 UTC (permalink / raw)
To: Robert Chiras
Cc: Marek Vasut, Mark Rutland, Pengutronix Kernel Team, dri-devel,
devicetree, David Airlie, Fabio Estevam, Guido Günther,
linux-kernel, Stefan Agner, Rob Herring, NXP Linux Team,
Daniel Vetter, Shawn Guo, Sascha Hauer, linux-arm-kernel
In-Reply-To: <1565779731-1300-8-git-send-email-robert.chiras@nxp.com>
On Wed, Aug 14, 2019 at 01:48:43PM +0300, Robert Chiras wrote:
> Currently, the vblank support is not correctly implemented in MXSFB_DRM
> driver. The call to drm_vblank_init is made with mode_config.num_crtc
> which at that time is 0. Because of this, vblank is not activated, so
> there won't be any vblank event submitted.
> For example, when running modetest with the '-v' parameter will result
> in an astronomical refresh rate (10000+ Hz), because of that.
Uh, that sounds a bit like a bug somewhere. If vblank doesn't work, we
should give userspace an error back.
Maybe we need more checks in drm_vblank_init()? Can you pls look into
that?
>
> Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 2743975..829abec 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -38,6 +38,9 @@
> #include "mxsfb_drv.h"
> #include "mxsfb_regs.h"
>
> +/* The eLCDIF max possible CRTCs */
> +#define MAX_CRTCS 1
> +
> enum mxsfb_devtype {
> MXSFB_V3,
> MXSFB_V4,
> @@ -138,6 +141,8 @@ static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
> mxsfb->connector = &mxsfb->panel_connector;
> }
>
> + drm_crtc_vblank_on(&pipe->crtc);
> +
> pm_runtime_get_sync(drm->dev);
> drm_panel_prepare(mxsfb->panel);
> mxsfb_crtc_enable(mxsfb);
> @@ -164,6 +169,8 @@ static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
> }
> spin_unlock_irq(&drm->event_lock);
>
> + drm_crtc_vblank_off(&pipe->crtc);
> +
> if (mxsfb->connector != &mxsfb->panel_connector)
> mxsfb->connector = NULL;
> }
> @@ -246,7 +253,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long flags)
>
> pm_runtime_enable(drm->dev);
>
> - ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> + ret = drm_vblank_init(drm, MAX_CRTCS);
> if (ret < 0) {
> dev_err(drm->dev, "Failed to initialise vblank\n");
> goto err_vblank;
> @@ -269,6 +276,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned long flags)
> goto err_vblank;
> }
>
> + drm_crtc_vblank_off(&mxsfb->pipe.crtc);
Are you sure you need this one here? vblanks should be off after
drm_vblank_init() is called.
Thanks, Daniel
> +
> /*
> * Attach panel only if there is one.
> * If there is no panel attach, it must be a bridge. In this case, we
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
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] drm/aspeed: gfc_crtc: Make structure aspeed_gfx_funcs constant
From: Daniel Vetter @ 2019-08-14 17:27 UTC (permalink / raw)
To: Nishka Dasgupta
Cc: linux-aspeed, airlied, dri-devel, andrew, joel, daniel,
linux-arm-kernel
In-Reply-To: <20190813063355.25549-1-nishkadg.linux@gmail.com>
On Tue, Aug 13, 2019 at 12:03:55PM +0530, Nishka Dasgupta wrote:
> The static structure aspeed_gfx_funcs, of type
> drm_simple_display_pipe_funcs, is used only as an argument to
> drm_simple_display_pipe_init(), which does not modify it. Hence make it
> constant to protect it from unintended modification.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Applied, thanks for your patch.
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> index 15db9e426ec4..2184b8be6fd4 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> @@ -215,7 +215,7 @@ static void aspeed_gfx_disable_vblank(struct drm_simple_display_pipe *pipe)
> writel(reg | CRT_CTRL_VERTICAL_INTR_STS, priv->base + CRT_CTRL1);
> }
>
> -static struct drm_simple_display_pipe_funcs aspeed_gfx_funcs = {
> +static const struct drm_simple_display_pipe_funcs aspeed_gfx_funcs = {
> .enable = aspeed_gfx_pipe_enable,
> .disable = aspeed_gfx_pipe_disable,
> .update = aspeed_gfx_pipe_update,
> --
> 2.19.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Explicitly marking initializer overrides (was "Re: [PATCH] arm64/cache: silence -Woverride-init warnings")
From: Nathan Chancellor @ 2019-08-14 17:26 UTC (permalink / raw)
To: Mark Rutland
Cc: catalin.marinas, linux-kernel, clang-built-linux, Qian Cai, will,
linux-arm-kernel
In-Reply-To: <20190809083251.GA48423@lakrids.cambridge.arm.com>
On Fri, Aug 09, 2019 at 09:32:51AM +0100, Mark Rutland wrote:
> On Thu, Aug 08, 2019 at 10:09:16AM -0700, Nathan Chancellor wrote:
> > On Thu, Aug 08, 2019 at 11:38:08AM +0100, Mark Rutland wrote:
> > > On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
> > > > The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> > > > VIVT I-caches") introduced some compiation warnings from GCC (and
> > > > Clang) with -Winitializer-overrides),
> > > >
> > > > arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> > > > overwritten [-Woverride-init]
> > > > [ICACHE_POLICY_VIPT] = "VIPT",
> > > > ^~~~~~
> > > > arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
> > > > 'icache_policy_str[2]')
> > > > arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
> > > > overwritten [-Woverride-init]
> > > > [ICACHE_POLICY_PIPT] = "PIPT",
> > > > ^~~~~~
> > > > arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
> > > > 'icache_policy_str[3]')
> > > > arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
> > > > overwritten [-Woverride-init]
> > > > [ICACHE_POLICY_VPIPT] = "VPIPT",
> > > > ^~~~~~~
> > > > arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
> > > > 'icache_policy_str[0]')
> > > >
> > > > because it initializes icache_policy_str[0 ... 3] twice. Since
> > > > arm64 developers are keen to keep the style of initializing a static
> > > > array with a non-zero pattern first, just disable those warnings for
> > > > both GCC and Clang of this file.
> > > >
> > > > Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
> > > > Signed-off-by: Qian Cai <cai@lca.pw>
> > >
> > > This is _not_ a fix, and should not require backporting to stable trees.
> > >
> > > What about all the other instances that we have in mainline?
> > >
> > > I really don't think that we need to go down this road; we're just going
> > > to end up adding this to every file that happens to include a header
> > > using this scheme...
> > >
> > > Please just turn this off by default for clang.
> > >
> > > If we want to enable this, we need a mechanism to permit overridable
> > > assignments as we use range initializers for.
> > >
> > > Thanks,
> > > Mark.
> > >
> >
> > For what it's worth, this is disabled by default for clang in the
> > kernel:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.extrawarn?h=v5.3-rc3#n69
> >
> > It only becomes visible with clang at W=1 because that section doesn't
> > get applied. It becomes visible with GCC at W=1 because of -Wextra.
>
> Thanks for clarifying that!
>
> Do you know if there's any existing mechanism that we can use to silence
> the warning on a per-assignment basis? Either to say that an assignment
> can be overridden, or that the assignment is expected to override an
> existing assignment?
>
I don't think there is, from the brief amount of research I did.
> If not, who would be able to look at adding a mechanism to clang for
> this?
>
I've filed https://github.com/ClangBuiltLinux/linux/issues/639 on our
issue tracker so that I can try to remember to distill all of this
down and file an LLVM bug.
> If we could have some attribute or intrinsic that we could wrap like:
>
> struct foo f = {
> .bar __defaultval = <default>,
> .bar = <newval>, // no warning
> .bar = <anotherval>, // warning
> };
>
> ... or:
>
> struct foo f = {
> .bar = <default>,
> .bar __override = <newval>, // no warning
> .bar = <anotherval>, // warning
> };
>
> ... or:
>
> .bar = OVERRIDE(<newval>), // no warning
>
> ... or:
> OVERRIDE(.bar) = <newval>, // no warning
>
> ... then I think it would be possible to make use of the warning
> effectively, as we could distinguish intentional overrides from
> unintentional ones, and annotating assignments in this way doesn't seem
> onerous to me.
>
> Thanks,
> Mark.
I definitely think it is an interesting idea, hopefully some of our
resident clang experts can weigh in and see how feasible it would be to
implement.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] firmware: arm_scmi: updates for v5.4
From: Sudeep Holla @ 2019-08-14 17:24 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Olof Johansson, Kevin Hilman, Arnd Bergmann, Sudeep Holla
Hi ARM SoC Team,
Please pull !
There are minor changes in clock and hwmon subsystems that are Acked-by
Stephen Boyd and Guenter Roeck. It also contains a new reset driver that
is reviewed by Philipp Zabel. Further all these are in -next for a while.
Regards,
Sudeep
-->8
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-5.4
for you to fetch changes up to c8ae9c2da1cc5d18b6d51d10160508a3dc3436bf:
reset: Add support for resets provided by SCMI (2019-08-12 12:23:02 +0100)
----------------------------------------------------------------
ARM SCMI updates/fixes for v5.4
Handful of fixes/updates including:
1. SCMI v2.0(recently released) support for:
- Performance protocol fast channels
- Reset Management Protocol
2. SCMI infrastructure/core support for recieve(Rx) channels,
asynchronous commands and delayed response
3. Usage of asynchronous commands for clock rate setting and sensor
reading based on the attributes read from the firmware
4. Miscellaneous cleanups(typos, naming alignment with specification,
and SPDX License identifier)
5. Couple of fixes: removal of extra check for invalid length and
additional check to ensure platform/firmware has released shared
memory before using it in OSPM
----------------------------------------------------------------
Sudeep Holla (22):
firmware: arm_scmi: Use the correct style for SPDX License Identifier
firmware: arm_scmi: Align few names in sensors protocol with SCMI specification
firmware: arm_scmi: Remove extra check for invalid length message responses
firmware: arm_scmi: Fix few trivial typos in comments
firmware: arm_scmi: Use the term 'message' instead of 'command'
firmware: arm_scmi: Check if platform has released shmem before using
firmware: arm_scmi: Reorder some functions to avoid forward declarations
firmware: arm_scmi: Segregate tx channel handling and prepare to add rx
firmware: arm_scmi: Add receive channel support for notifications
firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx
firmware: arm_scmi: Add mechanism to unpack message headers
firmware: arm_scmi: Add support for asynchronous commands and delayed response
firmware: arm_scmi: Drop async flag in sensor_ops->reading_get
firmware: arm_scmi: Add asynchronous sensor read if it supports
firmware: arm_scmi: Drop config flag in clk_ops->rate_set
firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible
firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors
firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels
firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol
dt-bindings: arm: Extend SCMI to support new reset protocol
firmware: arm_scmi: Add RESET protocol in SCMI v2.0
reset: Add support for resets provided by SCMI
Documentation/devicetree/bindings/arm/arm,scmi.txt | 17 +
MAINTAINERS | 1 +
drivers/clk/clk-scmi.c | 2 +-
drivers/firmware/arm_scmi/Makefile | 2 +-
drivers/firmware/arm_scmi/base.c | 2 +-
drivers/firmware/arm_scmi/clock.c | 33 +-
drivers/firmware/arm_scmi/common.h | 18 +-
drivers/firmware/arm_scmi/driver.c | 366 +++++++++++++--------
drivers/firmware/arm_scmi/perf.c | 264 ++++++++++++++-
drivers/firmware/arm_scmi/power.c | 6 +-
drivers/firmware/arm_scmi/reset.c | 231 +++++++++++++
drivers/firmware/arm_scmi/sensors.c | 57 ++--
drivers/hwmon/scmi-hwmon.c | 2 +-
drivers/reset/Kconfig | 11 +
drivers/reset/Makefile | 1 +
drivers/reset/reset-scmi.c | 124 +++++++
include/linux/scmi_protocol.h | 46 ++-
17 files changed, 981 insertions(+), 202 deletions(-)
create mode 100644 drivers/firmware/arm_scmi/reset.c
create mode 100644 drivers/reset/reset-scmi.c
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: vexpress: updates for v5.4
From: Sudeep Holla @ 2019-08-14 17:24 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Lorenzo Pieralisi, Arnd Bergmann, Kevin Hilman, Liviu Dudau,
Sudeep Holla, Olof Johansson
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-update-5.4
for you to fetch changes up to ace4682635db252d40071f62af328c90508cafdd:
ARM: vexpress: Cleanup cppcheck shifting warning (2019-07-31 16:36:58 +0100)
----------------------------------------------------------------
ARMv7 Vexpress update for v5.4
Single cleanup patch handling type checks using cppcheck tool
(bitwise shift by more than 31 on a 32 bit type)
----------------------------------------------------------------
Phong Tran (1):
ARM: vexpress: Cleanup cppcheck shifting warning
arch/arm/mach-vexpress/spc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: dts: vexpress: updates for v5.4
From: Sudeep Holla @ 2019-08-14 17:24 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Lorenzo Pieralisi, Arnd Bergmann, Kevin Hilman, Liviu Dudau,
Sudeep Holla, Olof Johansson
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-dt-updates-5.4
for you to fetch changes up to 7ff1154d459d25f8f674765a5ec575207516168c:
ARM: dts: vexpress: Add missing newline at end of file (2019-07-31 16:36:05 +0100)
----------------------------------------------------------------
ARMv7 Vexpress DTS updates for v5.4
Couple of updates adding missing: SPDX GPL-2.0 license identifier
and newline at the end of the file
----------------------------------------------------------------
Geert Uytterhoeven (1):
ARM: dts: vexpress: Add missing newline at end of file
Sudeep Holla (1):
ARM: dts: vexpress: add missing SPDX GPL-2.0 license identifier
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 1 +
arch/arm/boot/dts/vexpress-v2m.dtsi | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64: dts: juno: updates for v5.4
From: Sudeep Holla @ 2019-08-14 17:24 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Olof Johansson, Kevin Hilman, Liviu Dudau, Arnd Bergmann,
Sudeep Holla
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-update-5.4
for you to fetch changes up to a24810673638d5da0336ccae5407c3fd59da14ac:
arm64: dts: fast models: Remove clcd's max-memory-bandwidth (2019-08-05 11:44:00 +0100)
----------------------------------------------------------------
ARMv8 Juno/FVP update for v5.4
Single patch removing optional 'max-memory-bandwidth' property for CLCD
that enables to allocate and use 32bpp buffers(used on FVP for Android
development)
----------------------------------------------------------------
Kevin Brodsky (1):
arm64: dts: fast models: Remove clcd's max-memory-bandwidth
arch/arm64/boot/dts/arm/fvp-base-revc.dts | 8 --------
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 2 --
2 files changed, 10 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 01/15] iommu/arm-smmu: Convert GR0 registers to bitfields
From: Will Deacon @ 2019-08-14 17:20 UTC (permalink / raw)
To: Robin Murphy
Cc: robdclark, joro, bjorn.andersson, iommu, vivek.gautam,
gregory.clement, linux-arm-kernel
In-Reply-To: <910cad718be01904db20ce73d8d54e7481290136.1565369764.git.robin.murphy@arm.com>
On Fri, Aug 09, 2019 at 06:07:38PM +0100, Robin Murphy wrote:
> FIELD_PREP remains a terrible name, but the overall simplification will
> make further work on this stuff that much more manageable. This also
> serves as an audit of the header, wherein we can impose a consistent
> grouping and ordering of the offset and field definitions
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu-regs.h | 126 ++++++++++++++++------------------
> drivers/iommu/arm-smmu.c | 51 +++++++-------
> 2 files changed, 84 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu-regs.h b/drivers/iommu/arm-smmu-regs.h
> index 1c278f7ae888..d189f025537a 100644
> --- a/drivers/iommu/arm-smmu-regs.h
> +++ b/drivers/iommu/arm-smmu-regs.h
> @@ -10,111 +10,101 @@
> #ifndef _ARM_SMMU_REGS_H
> #define _ARM_SMMU_REGS_H
>
> +#include <linux/bits.h>
> +
> /* Configuration registers */
> #define ARM_SMMU_GR0_sCR0 0x0
> -#define sCR0_CLIENTPD (1 << 0)
> -#define sCR0_GFRE (1 << 1)
> -#define sCR0_GFIE (1 << 2)
> -#define sCR0_EXIDENABLE (1 << 3)
> -#define sCR0_GCFGFRE (1 << 4)
> -#define sCR0_GCFGFIE (1 << 5)
> -#define sCR0_USFCFG (1 << 10)
> -#define sCR0_VMIDPNE (1 << 11)
> -#define sCR0_PTM (1 << 12)
> -#define sCR0_FB (1 << 13)
> -#define sCR0_VMID16EN (1 << 31)
> -#define sCR0_BSU_SHIFT 14
> -#define sCR0_BSU_MASK 0x3
> +#define sCR0_VMID16EN BIT(31)
> +#define sCR0_BSU GENMASK(15, 14)
> +#define sCR0_FB BIT(13)
> +#define sCR0_PTM BIT(12)
> +#define sCR0_VMIDPNE BIT(11)
> +#define sCR0_USFCFG BIT(10)
> +#define sCR0_GCFGFIE BIT(5)
> +#define sCR0_GCFGFRE BIT(4)
> +#define sCR0_EXIDENABLE BIT(3)
> +#define sCR0_GFIE BIT(2)
> +#define sCR0_GFRE BIT(1)
> +#define sCR0_CLIENTPD BIT(0)
>
> /* Auxiliary Configuration register */
> #define ARM_SMMU_GR0_sACR 0x10
>
> /* Identification registers */
> #define ARM_SMMU_GR0_ID0 0x20
> +#define ID0_S1TS BIT(30)
> +#define ID0_S2TS BIT(29)
> +#define ID0_NTS BIT(28)
> +#define ID0_SMS BIT(27)
> +#define ID0_ATOSNS BIT(26)
> +#define ID0_PTFS_NO_AARCH32 BIT(25)
> +#define ID0_PTFS_NO_AARCH32S BIT(24)
> +#define ID0_CTTW BIT(14)
> +#define ID0_NUMIRPT GENMASK(23, 16)
nit: assuming this should be above ID0_CTTW so things are in descending
bit order?
Other than that, looks good to me.
Will
_______________________________________________
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/6] arm64: unexport set_memory_x and set_memory_nx
From: Will Deacon @ 2019-08-14 16:50 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Hansen, Peter Zijlstra, Catalin Marinas, x86, linux-kernel,
Andy Lutomirski, linux-arm-kernel
In-Reply-To: <20190813090146.26377-2-hch@lst.de>
On Tue, Aug 13, 2019 at 11:01:41AM +0200, Christoph Hellwig wrote:
> No module currently messed with clearing or setting the execute
> permission of kernel memory, and none really should.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/mm/pageattr.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 03c53f16ee77..9ce7bd9d4d9c 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -128,7 +128,6 @@ int set_memory_nx(unsigned long addr, int numpages)
> __pgprot(PTE_PXN),
> __pgprot(0));
> }
> -EXPORT_SYMBOL_GPL(set_memory_nx);
>
> int set_memory_x(unsigned long addr, int numpages)
> {
> @@ -136,7 +135,6 @@ int set_memory_x(unsigned long addr, int numpages)
> __pgprot(0),
> __pgprot(PTE_PXN));
> }
> -EXPORT_SYMBOL_GPL(set_memory_x);
arm64 allmodconfig and defconfig are happy with this, so I'll pick it up
for 5.4 if that's ok with you?
Will
_______________________________________________
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] arm64/efi: Move variable assignments after SECTIONS
From: Kees Cook @ 2019-08-14 16:35 UTC (permalink / raw)
To: Will Deacon
Cc: Fangrui Song, Ard Biesheuvel, Catalin Marinas,
Linux Kernel Mailing List, clang-built-linux, Peter Smith,
Nathan Chancellor, linux-arm-kernel
In-Reply-To: <20190814161904.55jgaxnhd4ujyh2h@willie-the-truck>
On Wed, Aug 14, 2019 at 05:19:04PM +0100, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 07:14:42PM +0300, Ard Biesheuvel wrote:
> > On Wed, 14 Aug 2019 at 02:04, Kees Cook <keescook@chromium.org> wrote:
> > >
> > > It seems that LLVM's linker does not correctly handle variable assignments
> > > involving section positions that are updated during the SECTIONS
> > > parsing. Commit aa69fb62bea1 ("arm64/efi: Mark __efistub_stext_offset as
> > > an absolute symbol explicitly") ran into this too, but found a different
> > > workaround.
> > >
> > > However, this was not enough, as other variables were also miscalculated
> > > which manifested as boot failures under UEFI where __efistub__end was
> > > not taking the correct _end value (they should be the same):
> > >
> > > $ ld.lld -EL -maarch64elf --no-undefined -X -shared \
> > > -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> > > -o vmlinux.lld -T poc.lds --whole-archive vmlinux.o && \
> > > readelf -Ws vmlinux.lld | egrep '\b(__efistub_|)_end\b'
> > > 368272: ffff000002218000 0 NOTYPE LOCAL HIDDEN 38 __efistub__end
> > > 368322: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 38 _end
> > >
> > > $ aarch64-linux-gnu-ld.bfd -EL -maarch64elf --no-undefined -X -shared \
> > > -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> > > -o vmlinux.bfd -T poc.lds --whole-archive vmlinux.o && \
> > > readelf -Ws vmlinux.bfd | egrep '\b(__efistub_|)_end\b'
> > > 338124: ffff000012318000 0 NOTYPE LOCAL DEFAULT ABS __efistub__end
> > > 383812: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 15325 _end
> > >
> > > To work around this, all of the __efistub_-prefixed variable assignments
> > > need to be moved after the linker script's SECTIONS entry. As it turns
> > > out, this also solves the problem fixed in commit aa69fb62bea1, so those
> > > changes are reverted here.
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/634
> > > Link: https://bugs.llvm.org/show_bug.cgi?id=42990
> > > Signed-off-by: Kees Cook <keescook@chromium.org>
> >
> > Although it is slightly disappointing that we need to work around this
> > kind of bugs when adding support for a new toolchain, I don't see
> > anything wrong with this patch, so
> >
> > Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Yup, it's gross, but I'll queue it with your ack.
Thanks, and agreed. :)
--
Kees Cook
_______________________________________________
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] arm64/efi: Move variable assignments after SECTIONS
From: Will Deacon @ 2019-08-14 16:19 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Kees Cook, Fangrui Song, Catalin Marinas,
Linux Kernel Mailing List, clang-built-linux, Peter Smith,
Nathan Chancellor, linux-arm-kernel
In-Reply-To: <CAKv+Gu9fEAG3CqmORyO2X_Uqse09nnXEQiB1kTL-xBqLWsy8Xg@mail.gmail.com>
On Wed, Aug 14, 2019 at 07:14:42PM +0300, Ard Biesheuvel wrote:
> On Wed, 14 Aug 2019 at 02:04, Kees Cook <keescook@chromium.org> wrote:
> >
> > It seems that LLVM's linker does not correctly handle variable assignments
> > involving section positions that are updated during the SECTIONS
> > parsing. Commit aa69fb62bea1 ("arm64/efi: Mark __efistub_stext_offset as
> > an absolute symbol explicitly") ran into this too, but found a different
> > workaround.
> >
> > However, this was not enough, as other variables were also miscalculated
> > which manifested as boot failures under UEFI where __efistub__end was
> > not taking the correct _end value (they should be the same):
> >
> > $ ld.lld -EL -maarch64elf --no-undefined -X -shared \
> > -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> > -o vmlinux.lld -T poc.lds --whole-archive vmlinux.o && \
> > readelf -Ws vmlinux.lld | egrep '\b(__efistub_|)_end\b'
> > 368272: ffff000002218000 0 NOTYPE LOCAL HIDDEN 38 __efistub__end
> > 368322: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 38 _end
> >
> > $ aarch64-linux-gnu-ld.bfd -EL -maarch64elf --no-undefined -X -shared \
> > -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> > -o vmlinux.bfd -T poc.lds --whole-archive vmlinux.o && \
> > readelf -Ws vmlinux.bfd | egrep '\b(__efistub_|)_end\b'
> > 338124: ffff000012318000 0 NOTYPE LOCAL DEFAULT ABS __efistub__end
> > 383812: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 15325 _end
> >
> > To work around this, all of the __efistub_-prefixed variable assignments
> > need to be moved after the linker script's SECTIONS entry. As it turns
> > out, this also solves the problem fixed in commit aa69fb62bea1, so those
> > changes are reverted here.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/634
> > Link: https://bugs.llvm.org/show_bug.cgi?id=42990
> > Signed-off-by: Kees Cook <keescook@chromium.org>
>
> Although it is slightly disappointing that we need to work around this
> kind of bugs when adding support for a new toolchain, I don't see
> anything wrong with this patch, so
>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Yup, it's gross, but I'll queue it with your ack.
Will
_______________________________________________
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] arm64/efi: Move variable assignments after SECTIONS
From: Ard Biesheuvel @ 2019-08-14 16:14 UTC (permalink / raw)
To: Kees Cook
Cc: Fangrui Song, Catalin Marinas, Linux Kernel Mailing List,
clang-built-linux, Peter Smith, Nathan Chancellor, Will Deacon,
linux-arm-kernel
In-Reply-To: <201908131602.6E858DEC@keescook>
On Wed, 14 Aug 2019 at 02:04, Kees Cook <keescook@chromium.org> wrote:
>
> It seems that LLVM's linker does not correctly handle variable assignments
> involving section positions that are updated during the SECTIONS
> parsing. Commit aa69fb62bea1 ("arm64/efi: Mark __efistub_stext_offset as
> an absolute symbol explicitly") ran into this too, but found a different
> workaround.
>
> However, this was not enough, as other variables were also miscalculated
> which manifested as boot failures under UEFI where __efistub__end was
> not taking the correct _end value (they should be the same):
>
> $ ld.lld -EL -maarch64elf --no-undefined -X -shared \
> -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> -o vmlinux.lld -T poc.lds --whole-archive vmlinux.o && \
> readelf -Ws vmlinux.lld | egrep '\b(__efistub_|)_end\b'
> 368272: ffff000002218000 0 NOTYPE LOCAL HIDDEN 38 __efistub__end
> 368322: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 38 _end
>
> $ aarch64-linux-gnu-ld.bfd -EL -maarch64elf --no-undefined -X -shared \
> -Bsymbolic -z notext -z norelro --no-apply-dynamic-relocs \
> -o vmlinux.bfd -T poc.lds --whole-archive vmlinux.o && \
> readelf -Ws vmlinux.bfd | egrep '\b(__efistub_|)_end\b'
> 338124: ffff000012318000 0 NOTYPE LOCAL DEFAULT ABS __efistub__end
> 383812: ffff000012318000 0 NOTYPE GLOBAL DEFAULT 15325 _end
>
> To work around this, all of the __efistub_-prefixed variable assignments
> need to be moved after the linker script's SECTIONS entry. As it turns
> out, this also solves the problem fixed in commit aa69fb62bea1, so those
> changes are reverted here.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/634
> Link: https://bugs.llvm.org/show_bug.cgi?id=42990
> Signed-off-by: Kees Cook <keescook@chromium.org>
Although it is slightly disappointing that we need to work around this
kind of bugs when adding support for a new toolchain, I don't see
anything wrong with this patch, so
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/kernel/image-vars.h | 51 +++++++++++++++++++++++++++++++++
> arch/arm64/kernel/image.h | 42 ---------------------------
> arch/arm64/kernel/vmlinux.lds.S | 2 ++
> 3 files changed, 53 insertions(+), 42 deletions(-)
> create mode 100644 arch/arm64/kernel/image-vars.h
>
> diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> new file mode 100644
> index 000000000000..25a2a9b479c2
> --- /dev/null
> +++ b/arch/arm64/kernel/image-vars.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Linker script variables to be set after section resolution, as
> + * ld.lld does not like variables assigned before SECTIONS is processed.
> + */
> +#ifndef __ARM64_KERNEL_IMAGE_VARS_H
> +#define __ARM64_KERNEL_IMAGE_VARS_H
> +
> +#ifndef LINKER_SCRIPT
> +#error This file should only be included in vmlinux.lds.S
> +#endif
> +
> +#ifdef CONFIG_EFI
> +
> +__efistub_stext_offset = stext - _text;
> +
> +/*
> + * The EFI stub has its own symbol namespace prefixed by __efistub_, to
> + * isolate it from the kernel proper. The following symbols are legally
> + * accessed by the stub, so provide some aliases to make them accessible.
> + * Only include data symbols here, or text symbols of functions that are
> + * guaranteed to be safe when executed at another offset than they were
> + * linked at. The routines below are all implemented in assembler in a
> + * position independent manner
> + */
> +__efistub_memcmp = __pi_memcmp;
> +__efistub_memchr = __pi_memchr;
> +__efistub_memcpy = __pi_memcpy;
> +__efistub_memmove = __pi_memmove;
> +__efistub_memset = __pi_memset;
> +__efistub_strlen = __pi_strlen;
> +__efistub_strnlen = __pi_strnlen;
> +__efistub_strcmp = __pi_strcmp;
> +__efistub_strncmp = __pi_strncmp;
> +__efistub_strrchr = __pi_strrchr;
> +__efistub___flush_dcache_area = __pi___flush_dcache_area;
> +
> +#ifdef CONFIG_KASAN
> +__efistub___memcpy = __pi_memcpy;
> +__efistub___memmove = __pi_memmove;
> +__efistub___memset = __pi_memset;
> +#endif
> +
> +__efistub__text = _text;
> +__efistub__end = _end;
> +__efistub__edata = _edata;
> +__efistub_screen_info = screen_info;
> +
> +#endif
> +
> +#endif /* __ARM64_KERNEL_IMAGE_VARS_H */
> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
> index 2b85c0d6fa3d..c7d38c660372 100644
> --- a/arch/arm64/kernel/image.h
> +++ b/arch/arm64/kernel/image.h
> @@ -65,46 +65,4 @@
> DEFINE_IMAGE_LE64(_kernel_offset_le, TEXT_OFFSET); \
> DEFINE_IMAGE_LE64(_kernel_flags_le, __HEAD_FLAGS);
>
> -#ifdef CONFIG_EFI
> -
> -/*
> - * Use ABSOLUTE() to avoid ld.lld treating this as a relative symbol:
> - * https://github.com/ClangBuiltLinux/linux/issues/561
> - */
> -__efistub_stext_offset = ABSOLUTE(stext - _text);
> -
> -/*
> - * The EFI stub has its own symbol namespace prefixed by __efistub_, to
> - * isolate it from the kernel proper. The following symbols are legally
> - * accessed by the stub, so provide some aliases to make them accessible.
> - * Only include data symbols here, or text symbols of functions that are
> - * guaranteed to be safe when executed at another offset than they were
> - * linked at. The routines below are all implemented in assembler in a
> - * position independent manner
> - */
> -__efistub_memcmp = __pi_memcmp;
> -__efistub_memchr = __pi_memchr;
> -__efistub_memcpy = __pi_memcpy;
> -__efistub_memmove = __pi_memmove;
> -__efistub_memset = __pi_memset;
> -__efistub_strlen = __pi_strlen;
> -__efistub_strnlen = __pi_strnlen;
> -__efistub_strcmp = __pi_strcmp;
> -__efistub_strncmp = __pi_strncmp;
> -__efistub_strrchr = __pi_strrchr;
> -__efistub___flush_dcache_area = __pi___flush_dcache_area;
> -
> -#ifdef CONFIG_KASAN
> -__efistub___memcpy = __pi_memcpy;
> -__efistub___memmove = __pi_memmove;
> -__efistub___memset = __pi_memset;
> -#endif
> -
> -__efistub__text = _text;
> -__efistub__end = _end;
> -__efistub__edata = _edata;
> -__efistub_screen_info = screen_info;
> -
> -#endif
> -
> #endif /* __ARM64_KERNEL_IMAGE_H */
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 7fa008374907..803b24d2464a 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -245,6 +245,8 @@ SECTIONS
> HEAD_SYMBOLS
> }
>
> +#include "image-vars.h"
> +
> /*
> * The HYP init code and ID map text can't be longer than a page each,
> * and should not cross a page boundary.
> --
> 2.17.1
>
>
> --
> Kees Cook
_______________________________________________
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] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Steve Capper @ 2019-08-14 16:14 UTC (permalink / raw)
To: Mark Rutland
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, Catalin Marinas,
bhsharma@redhat.com, maz@kernel.org, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814160713.GA1614@capper-ampere.manchester.arm.com>
On Wed, Aug 14, 2019 at 05:07:15PM +0100, Steve Capper wrote:
> On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> > Hi Steve,
> >
>
> Hi Mark,
>
> > On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > > +config KASAN_SHADOW_OFFSET
> > > + hex
> > > + depends on KASAN
> > > + default 0xdfffa00000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && !KASAN_SW_TAGS
> > > + default 0xdfffd00000000000 if ARM64_VA_BITS_47 && !KASAN_SW_TAGS
> > > + default 0xdffffe8000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS
> > > + default 0xdfffffd000000000 if ARM64_VA_BITS_39 && !KASAN_SW_TAGS
> > > + default 0xdffffffa00000000 if ARM64_VA_BITS_36 && !KASAN_SW_TAGS
> > > + default 0xefff900000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && KASAN_SW_TAGS
> > > + default 0xefffc80000000000 if ARM64_VA_BITS_47 && KASAN_SW_TAGS
> > > + default 0xeffffe4000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
> > > + default 0xefffffc800000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
> > > + default 0xeffffff900000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
> > > + default 0xffffffffffffffff
> > > +
> > > source "arch/arm64/Kconfig.platforms"
> > >
> > > menu "Kernel Features"
> > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > index b2400f9c1213..2b7db0d41498 100644
> > > --- a/arch/arm64/Makefile
> > > +++ b/arch/arm64/Makefile
> > > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > >
> > > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > > -# in 32-bit arithmetic
> > > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > > -
> > > export TEXT_OFFSET GZFLAGS
> > >
> > > core-y += arch/arm64/kernel/ arch/arm64/mm/
> >
> > I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> > CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> > CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> > CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> > regardless.
> >
> > I think that's by accident rather than by design, but to
> > minimize/localize the fixup, how about the below? I can send a cleanup
> > patch for scripts/Makefile.kasan later.
> >
> > Build and boot tested with CONFIG_KASAN_{SW_TAGS,GENERIC} and
> > VA_BITS_52 (on a 48-bit VA system).
> >
>
> I've tested this with VA_BITS_52 (booted with 52-bit) with inline
> SW_TAGS and generic KASAN.
>
> FWIW:
> Tested-by: Steve Capper <steve.capper@arm.com>
> Reviewed-by: Steve Capper <steve.capper@arm.com>
>
> Agreed for this small fix now and a bigger fix in Makefile.kasan later.
>
Apologies for the noise, I didn't notice the thread progress as I was
testing. Will test the improved patch :-).
Cheers,
--
Steve
_______________________________________________
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] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Steve Capper @ 2019-08-14 16:07 UTC (permalink / raw)
To: Mark Rutland
Cc: crecklin@redhat.com, ard.biesheuvel@linaro.org, Catalin Marinas,
bhsharma@redhat.com, maz@kernel.org, nd, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190814152017.GD51963@lakrids.cambridge.arm.com>
On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> Hi Steve,
>
Hi Mark,
> On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > +config KASAN_SHADOW_OFFSET
> > + hex
> > + depends on KASAN
> > + default 0xdfffa00000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && !KASAN_SW_TAGS
> > + default 0xdfffd00000000000 if ARM64_VA_BITS_47 && !KASAN_SW_TAGS
> > + default 0xdffffe8000000000 if ARM64_VA_BITS_42 && !KASAN_SW_TAGS
> > + default 0xdfffffd000000000 if ARM64_VA_BITS_39 && !KASAN_SW_TAGS
> > + default 0xdffffffa00000000 if ARM64_VA_BITS_36 && !KASAN_SW_TAGS
> > + default 0xefff900000000000 if (ARM64_VA_BITS_48 || ARM64_USER_VA_BITS_52) && KASAN_SW_TAGS
> > + default 0xefffc80000000000 if ARM64_VA_BITS_47 && KASAN_SW_TAGS
> > + default 0xeffffe4000000000 if ARM64_VA_BITS_42 && KASAN_SW_TAGS
> > + default 0xefffffc800000000 if ARM64_VA_BITS_39 && KASAN_SW_TAGS
> > + default 0xeffffff900000000 if ARM64_VA_BITS_36 && KASAN_SW_TAGS
> > + default 0xffffffffffffffff
> > +
> > source "arch/arm64/Kconfig.platforms"
> >
> > menu "Kernel Features"
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index b2400f9c1213..2b7db0d41498 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> >
> > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > -# in 32-bit arithmetic
> > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > -
> > export TEXT_OFFSET GZFLAGS
> >
> > core-y += arch/arm64/kernel/ arch/arm64/mm/
>
> I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> regardless.
>
> I think that's by accident rather than by design, but to
> minimize/localize the fixup, how about the below? I can send a cleanup
> patch for scripts/Makefile.kasan later.
>
> Build and boot tested with CONFIG_KASAN_{SW_TAGS,GENERIC} and
> VA_BITS_52 (on a 48-bit VA system).
>
I've tested this with VA_BITS_52 (booted with 52-bit) with inline
SW_TAGS and generic KASAN.
FWIW:
Tested-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Agreed for this small fix now and a bigger fix in Makefile.kasan later.
Cheers,
--
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/3] kbuild: rebuild modules when module linker scripts are updated
From: Masahiro Yamada @ 2019-08-14 16:06 UTC (permalink / raw)
To: linux-kbuild
Cc: linux-ia64, linux-doc, Catalin Marinas, Palmer Dabbelt,
James E.J. Bottomley, Masahiro Yamada, Paul Mackerras,
linux-riscv, Will Deacon, Jonathan Corbet, Michael Ellerman,
Helge Deller, Russell King, Geert Uytterhoeven,
Benjamin Herrenschmidt, Fenghua Yu, Albert Ou, linux-m68k,
Michal Marek, Paul Walmsley, linux-arm-kernel, Tony Luck,
linux-parisc, linux-kernel, linuxppc-dev
In-Reply-To: <20190814160623.24802-1-yamada.masahiro@socionext.com>
Currently, the timestamp of module linker scripts are not checked.
Add them to the dependency of modules so they are correctly rebuilt.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Documentation/kbuild/makefiles.rst | 5 +++++
Makefile | 3 ++-
arch/arm/Makefile | 2 +-
arch/arm64/Makefile | 2 +-
arch/ia64/Makefile | 2 +-
arch/m68k/Makefile | 2 +-
arch/parisc/Makefile | 2 +-
arch/powerpc/Makefile | 2 +-
arch/riscv/Makefile | 2 +-
scripts/Makefile.modpost | 5 +++--
10 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst
index d3448d2c8017..36ba92e199d2 100644
--- a/Documentation/kbuild/makefiles.rst
+++ b/Documentation/kbuild/makefiles.rst
@@ -999,6 +999,11 @@ When kbuild executes, the following steps are followed (roughly):
The linker script with full path. Assigned by the top-level Makefile.
+ KBUILD_LDS_MODULE
+
+ The module linker script with full path. Assigned by the top-level
+ Makefile and additionally by the arch Makefile.
+
KBUILD_VMLINUX_OBJS
All object files for vmlinux. They are linked to vmlinux in the same
diff --git a/Makefile b/Makefile
index 164ca615e2f6..af808837a1f2 100644
--- a/Makefile
+++ b/Makefile
@@ -485,7 +485,8 @@ KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
KBUILD_AFLAGS_MODULE := -DMODULE
KBUILD_CFLAGS_MODULE := -DMODULE
-KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
+KBUILD_LDFLAGS_MODULE :=
+export KBUILD_LDS_MODULE := $(srctree)/scripts/module-common.lds
KBUILD_LDFLAGS :=
GCC_PLUGINS_CFLAGS :=
CLANG_FLAGS :=
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c3624ca6c0bc..fbe50eec8f34 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -17,7 +17,7 @@ KBUILD_LDFLAGS_MODULE += --be8
endif
ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
endif
GZFLAGS :=-9
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 61de992bbea3..d4ed1869e536 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -101,7 +101,7 @@ endif
CHECKFLAGS += -D__aarch64__
ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/arm64/kernel/module.lds
endif
# Default value
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index 171290f9f1de..5c3bcaee5980 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -20,7 +20,7 @@ CHECKFLAGS += -D__ia64=1 -D__ia64__=1 -D_LP64 -D__LP64__
OBJCOPYFLAGS := --strip-all
LDFLAGS_vmlinux := -static
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/ia64/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/ia64/module.lds
KBUILD_AFLAGS_KERNEL := -mconstant-gp
EXTRA :=
diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index 482513b9af2c..5d9288384096 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -73,7 +73,7 @@ KBUILD_AFLAGS += -D__uClinux__
endif
KBUILD_LDFLAGS := -m m68kelf
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/m68k/kernel/module.lds
ifdef CONFIG_SUN3
LDFLAGS_vmlinux = -N
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 3b77d729057f..36b834f1c933 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -60,7 +60,7 @@ KBUILD_CFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY=1 \
-DFTRACE_PATCHABLE_FUNCTION_SIZE=$(NOP_COUNT)
CC_FLAGS_FTRACE := -fpatchable-function-entry=$(NOP_COUNT),$(shell echo $$(($(NOP_COUNT)-1)))
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/parisc/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/parisc/kernel/module.lds
endif
OBJCOPY_FLAGS =-O binary -R .note -R .comment -S
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index c345b79414a9..b2227855de20 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -67,7 +67,7 @@ UTS_MACHINE := $(subst $(space),,$(machine-y))
ifdef CONFIG_PPC32
KBUILD_LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o
else
-KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/powerpc/kernel/module.lds
+KBUILD_LDS_MODULE += $(srctree)/arch/powerpc/kernel/module.lds
ifeq ($(call ld-ifversion, -ge, 225000000, y),y)
# Have the linker provide sfpr if possible.
# There is a corresponding test in arch/powerpc/lib/Makefile
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 7a117be8297c..426d989125a8 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -52,7 +52,7 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
KBUILD_CFLAGS += -mcmodel=medany
endif
ifeq ($(CONFIG_MODULE_SECTIONS),y)
- KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/riscv/kernel/module.lds
+ KBUILD_LDS_MODULE += $(srctree)/arch/riscv/kernel/module.lds
endif
KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-relax)
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index bf15818f6947..905db30d6622 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -126,10 +126,11 @@ quiet_cmd_ld_ko_o = LD [M] $@
cmd_ld_ko_o = \
$(LD) -r $(KBUILD_LDFLAGS) \
$(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
- -o $@ $(real-prereqs) ; \
+ $(addprefix -T , $(KBUILD_LDS_MODULE)) \
+ -o $@ $(filter %.o, $^); \
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
-$(modules): %.ko :%.o %.mod.o FORCE
+$(modules): %.ko :%.o %.mod.o $(KBUILD_LDS_MODULE) FORCE
+$(call if_changed,ld_ko_o)
targets += $(modules)
--
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 related
* Re: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Mark Rutland @ 2019-08-14 16:03 UTC (permalink / raw)
To: Will Deacon, Andrey Ryabinin
Cc: crecklin, ard.biesheuvel, catalin.marinas, bhsharma, Steve Capper,
maz, linux-arm-kernel
In-Reply-To: <20190814155711.ldwot7ezrrqjlswc@willie-the-truck>
On Wed, Aug 14, 2019 at 04:57:11PM +0100, Will Deacon wrote:
> On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> > On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > > index b2400f9c1213..2b7db0d41498 100644
> > > --- a/arch/arm64/Makefile
> > > +++ b/arch/arm64/Makefile
> > > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > >
> > > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > > -# in 32-bit arithmetic
> > > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > > -
> > > export TEXT_OFFSET GZFLAGS
> > >
> > > core-y += arch/arm64/kernel/ arch/arm64/mm/
> >
> > I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> > CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> > CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> > CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> > regardless.
> >
> > I think that's by accident rather than by design, but to
> > minimize/localize the fixup, how about the below? I can send a cleanup
> > patch for scripts/Makefile.kasan later.
>
> How much work is that? I've dropped this stuff from -next for now, so we
> have time to fix it properly as long as it's not going to take weeks.
I wrote it first, so no effort; patch below.
Andrey, would you be happy with this?
Thanks,
Mark.
---->8----
From ecdf60051a850f817d98f84ae9011afa2311b8f1 Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Wed, 14 Aug 2019 15:31:57 +0100
Subject: [PATCH] kasan/arm64: fix CONFIG_KASAN_SW_TAGS && KASAN_INLINE
The generic Makefile.kasan propagates CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET, but only does so for CONFIG_KASAN_GENERIC.
Since commit:
6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
... arm64 defines CONFIG_KASAN_SHADOW_OFFSET in Kconfig rather than
defining KASAN_SHADOW_OFFSET in a Makefile. Thus, if
CONFIG_KASAN_SW_TAGS && KASAN_INLINE are selected, we get build time
splats due to KASAN_SHADOW_OFFSET not being set:
| [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
| scripts/kconfig/conf --syncconfig Kconfig
| CC scripts/mod/empty.o
| clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
| scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
| make[1]: *** [scripts/mod/empty.o] Error 1
| Makefile:1123: recipe for target 'prepare0' failed
| make: *** [prepare0] Error 2
Let's fix this by always propagating CONFIG_KASAN_SHADOW_OFFSET into
KASAN_SHADOW_OFFSET if CONFIG_KASAN is selected, moving the existing
common definition of +CFLAGS_KASAN_NOSANITIZE to the top of
Makefile.kasan.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
---
scripts/Makefile.kasan | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 6410bd22fe38..03757cc60e06 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -1,4 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
+ifdef CONFIG_KASAN
+CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
+endif
+
ifdef CONFIG_KASAN_GENERIC
ifdef CONFIG_KASAN_INLINE
@@ -7,8 +12,6 @@ else
call_threshold := 0
endif
-KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
-
CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address
cc-param = $(call cc-option, -mllvm -$(1), $(call cc-option, --param $(1)))
@@ -45,7 +48,3 @@ CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
$(instrumentation_flags)
endif # CONFIG_KASAN_SW_TAGS
-
-ifdef CONFIG_KASAN
-CFLAGS_KASAN_NOSANITIZE := -fno-builtin
-endif
--
2.11.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: Best representation for TDM devices
From: Mark Brown @ 2019-08-14 16:02 UTC (permalink / raw)
To: Ali Burak Parım; +Cc: maxime.ripard, linux-arm-kernel
In-Reply-To: <CAMTEBE2L6KXH6JW2Z_6RSKdtFJc9ncFvfakwW_Vm88BCGC6aeQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1458 bytes --]
On Wed, Aug 14, 2019 at 12:53:24PM +0200, Ali Burak Parım wrote:
> On Thu, 1 Aug 2019 at 13:48, Mark Brown <broonie@kernel.org> wrote:
> > On Thu, Aug 01, 2019 at 01:43:06PM +0200, Ali Burak Parım wrote:
> > > On Thu, Jul 25, 2019 at 03:01:12PM +0200, Maxime Ripard wrote:
> > > Hardware is a custom board I designed with 4 PDM output microphones
> > > and 2 adau7002 devices as the codec for PDM-to-PCM. We want to do
> > > signal processing with this board. Therefore having separate streams for
> > > each microphone is crucial to the application though I am not sure where
> > > we should implement this exactly.
> > What is this processing - are the streams from these microphones
> > logically related in any way (eg, is this a microphone array)? There's
> Yes, it is a microphone array application for speech enhancement. Thus,
> signal levels and physical time delays are important.
> > probably going to be some overlap in the input signals at least. If you
> > need to for example correlate different microphones then that's
> > relevant.
> Yes, we correlate different microphone signals in some of our algorithms.
OK, in that case I'd recommend providing them to userspace as a single
four channel stream - keeping everything bundled together as long as
possible to make it easier to keep the processing synced up.
> P.S.: I am so sorry for late reply, the thread went to my junk box somehow.
No problem.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE (was: Re: [PATCH V5 03/12] arm64: kasan: Switch to using) KASAN_SHADOW_OFFSET
From: Will Deacon @ 2019-08-14 15:57 UTC (permalink / raw)
To: Mark Rutland
Cc: crecklin, ard.biesheuvel, catalin.marinas, bhsharma, Steve Capper,
maz, linux-arm-kernel
In-Reply-To: <20190814152017.GD51963@lakrids.cambridge.arm.com>
On Wed, Aug 14, 2019 at 04:20:18PM +0100, Mark Rutland wrote:
> On Wed, Aug 07, 2019 at 04:55:15PM +0100, Steve Capper wrote:
> > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> > index b2400f9c1213..2b7db0d41498 100644
> > --- a/arch/arm64/Makefile
> > +++ b/arch/arm64/Makefile
> > @@ -126,14 +126,6 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> > KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> >
> > -# KASAN_SHADOW_OFFSET = VA_START + (1 << (VA_BITS - KASAN_SHADOW_SCALE_SHIFT))
> > -# - (1 << (64 - KASAN_SHADOW_SCALE_SHIFT))
> > -# in 32-bit arithmetic
> > -KASAN_SHADOW_OFFSET := $(shell printf "0x%08x00000000\n" $$(( \
> > - (0xffffffff & (-1 << ($(CONFIG_ARM64_VA_BITS) - 1 - 32))) \
> > - + (1 << ($(CONFIG_ARM64_VA_BITS) - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) \
> > - - (1 << (64 - 32 - $(KASAN_SHADOW_SCALE_SHIFT))) )) )
> > -
> > export TEXT_OFFSET GZFLAGS
> >
> > core-y += arch/arm64/kernel/ arch/arm64/mm/
>
> I've just spotted this breaks build using CONFIG_KASAN_SW_TAGS &&
> CONFIG_KASAN_INLINE, as scripts/Makefile.kasan only propagates
> CONFIG_KASAN_SHADOW_OFFSET into KASAN_SHADOW_OFFSET when
> CONFIG_KASAN_GENERIC is selected, but consumes KASAN_SHADOW_OFFSET
> regardless.
>
> I think that's by accident rather than by design, but to
> minimize/localize the fixup, how about the below? I can send a cleanup
> patch for scripts/Makefile.kasan later.
How much work is that? I've dropped this stuff from -next for now, so we
have time to fix it properly as long as it's not going to take weeks.
> ---->8----
> From b1a6f2dd5aa30d874c4bd97a20ea1330607da624 Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland@arm.com>
> Date: Wed, 14 Aug 2019 15:51:14 +0100
> Subject: [PATCH] arm64: fix CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE
>
> Since commit:
>
> 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
>
> ... attempting to build with CONFIG_KASAN_SW_TAGS && CONFIG_KASAN_INLINE
> results ins splat:
>
> | [mark@lakrids:~/src/linux]% usellvm 8.0.1 usekorg 8.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- CC=clang
> | scripts/kconfig/conf --syncconfig Kconfig
> | CC scripts/mod/empty.o
> | clang (LLVM option parsing): for the -hwasan-mapping-offset option: '' value invalid for uint argument!
> | scripts/Makefile.build:273: recipe for target 'scripts/mod/empty.o' failed
> | make[1]: *** [scripts/mod/empty.o] Error 1
> | Makefile:1123: recipe for target 'prepare0' failed
> | make: *** [prepare0] Error 2
>
> ... since Makefile.kasan only consumes CONFIG_KASAN_SHADOW_OFFSET when
> CONFIG_KASAN_GENERIC is selected, and for CONFIG_KASAN_SW_TAGS it consumes
> KASAN_SHADOW_OFFSET (without a CONFIG_ prefix).
>
> For the moment, let's always propagate CONFIG_KASAN_SHADOW_OFFSET into
> KASAN_SHADOW_OFFSET via the arm64 Makefile. We can clean up the generic kasan
> Makefile later down the line.
>
> Fixes: 6bd1d0be0e97936d ("arm64: kasan: Switch to using KASAN_SHADOW_OFFSET")
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Steve Capper <steve.capper@arm.com>
> Cc: Will Deacon <will@kernel.org>
> ---
> arch/arm64/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index a8d2a241ac58..a0c733f93b5b 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -126,6 +126,8 @@ KBUILD_CFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> KBUILD_CPPFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
> KBUILD_AFLAGS += -DKASAN_SHADOW_SCALE_SHIFT=$(KASAN_SHADOW_SCALE_SHIFT)
>
> +KASAN_SHADOW_OFFSET := $(CONFIG_KASAN_SHADOW_OFFSET)
This needs a comment explaining what it's doing and that it's a dirty,
temporary hack.
Will
_______________________________________________
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 6/6] driver core: initialize a default DMA mask for platform device
From: Robin Murphy @ 2019-08-14 15:49 UTC (permalink / raw)
To: Christoph Hellwig, Greg Kroah-Hartman, Maxime Chevallier
Cc: linux-arch, Gavin Li, Pengutronix Kernel Team, Mathias Nyman,
Geoff Levand, Olav Kongas, Sascha Hauer, linux-usb, Michal Simek,
linux-kernel, Tony Prisk, iommu, Alan Stern, NXP Linux Team,
Fabio Estevam, Minas Harutyunyan, Shawn Guo, linuxppc-dev,
Bin Liu, linux-arm-kernel
In-Reply-To: <20190811080520.21712-7-hch@lst.de>
On 11/08/2019 09:05, Christoph Hellwig wrote:
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_object so that we can initialize
s/object/device/
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default. Architectures can still override this in
> arch_setup_pdev_archdata if needed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
This would be a good point to also get rid of the long-standing bodge in
platform_device_register_full().
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/base/platform.c | 15 +++++++++++++--
> include/linux/platform_device.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index ec974ba9c0c4..b216fcb0a8af 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -264,6 +264,17 @@ struct platform_object {
> char name[];
> };
>
> +static void setup_pdev_archdata(struct platform_device *pdev)
Bikeshed: painting the generic DMA API properties as "archdata" feels a
bit off-target :/
> +{
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dma_mask)
> + pdev->dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &pdev->dma_mask;
> + arch_setup_pdev_archdata(pdev);
AFAICS m68k's implementation of that arch hook becomes entirely
redundant after this change, so may as well go. That would just leave
powerpc's actual archdata, which at a glance looks like it could
probably be cleaned up with not *too* much trouble.
Robin.
> +};
> +
> /**
> * platform_device_put - destroy a platform device
> * @pdev: platform device to free
> @@ -310,7 +321,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> - arch_setup_pdev_archdata(&pa->pdev);
> + setup_pdev_archdata(&pa->pdev);
> }
>
> return pa ? &pa->pdev : NULL;
> @@ -512,7 +523,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
> int platform_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> - arch_setup_pdev_archdata(pdev);
> + setup_pdev_archdata(pdev);
> return platform_device_add(pdev);
> }
> EXPORT_SYMBOL_GPL(platform_device_register);
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 9bc36b589827..a2abde2aef25 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -24,6 +24,7 @@ struct platform_device {
> int id;
> bool id_auto;
> struct device dev;
> + u64 dma_mask;
> u32 num_resources;
> struct resource *resource;
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox