* [PATCH v2] drm/mediatek: fix a typo
From: CK Hu @ 2016-10-18 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476779039-28963-1-git-send-email-bibby.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
On Tue, 2016-10-18 at 16:23 +0800, Bibby Hsieh wrote:
> If we want to set the hardware OD to relay mode,
> we have to set OD_CFG register rather than
> OD_RELAYMODE; otherwise, the system will access
> the wrong address.
>
> Fixes: 7216436420414144646f5d8343d061355fd23483 ("drm/mediatek: set mt8173 dithering function")
> Cc: stable at vger.kernel.org # v4.9+
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index df33b3c..aa5f20f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -123,7 +123,7 @@ static void mtk_od_config(struct mtk_ddp_comp *comp, unsigned int w,
> unsigned int bpc)
> {
> writel(w << 16 | h, comp->regs + DISP_OD_SIZE);
> - writel(OD_RELAYMODE, comp->regs + OD_RELAYMODE);
> + writel(OD_RELAYMODE, comp->regs + OD_CFG);
> mtk_dither_set(comp, bpc, DISP_OD_CFG);
> }
>
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Pavel Machek @ 2016-10-18 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82ddd0e1-9ecc-5e54-e8ee-86f947fc0ecd@arm.com>
Hi!
> >b. in arm64, if some platform has its own suspend flow, couldn't it
> >adopts arm/match-xxx to register its own global suspend method?
> >
>
> No, PSCI is highly recommended.
Relying on firmware for suspend on x86 was a great disaster, lets not repeat
that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
for example) -- feel free to copy that code from arm32.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Bunch of CRC errors in next with arm: move exports to definitions
From: Arnd Bergmann @ 2016-10-18 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018093628.GE5783@n2100.arm.linux.org.uk>
On Tuesday, October 18, 2016 10:36:28 AM CEST Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 11:13:31AM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 18, 2016 6:59:44 AM CEST Sebastian Reichel wrote:
> > > Hi,
> > >
> > > On Mon, Aug 22, 2016 at 09:25:13AM -0700, Tony Lindgren wrote:
> > > > Looks like starting with next-20160818 I'm now getting close to
> > > > 800 lines of WARNINGs on ARM with omap2plus_defconfig while doing
> > > > make modules:
> > > >
> > > > Building modules, stage 2.
> > > > MODPOST 399 modules
> > > > WARNING: "__memzero" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > WARNING: "memset" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > WARNING: "memcpy" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > WARNING: "_set_bit" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > WARNING: "_test_and_set_bit" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > WARNING: "_clear_bit" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > WARNING: "__aeabi_uidivmod" [sound/usb/snd-usb-audio.ko] has no CRC!
> > > > WARNING: "_test_and_clear_bit" [sound/usb/snd-usb-audio.ko] has no CRC!
> > > > WARNING: "arm_copy_to_user" [sound/usb/snd-usb-audio.ko] has no CRC!
> > > > WARNING: "__aeabi_uidiv" [sound/usb/snd-usb-audio.ko] has no CRC!
> > > > ...
> > > > WARNING: "memset" [crypto/drbg.ko] has no CRC!
> > > > WARNING: "memcpy" [crypto/ctr.ko] has no CRC!
> > > > WARNING: "memcpy" [crypto/cmac.ko] has no CRC!
> > > > WARNING: "__memzero" [crypto/cmac.ko] has no CRC!
> > > > WARNING: "memcpy" [crypto/ccm.ko] has no CRC!
> > > > WARNING: "__memzero" [crypto/ccm.ko] has no CRC!
> > >
> > > Any update on this one? I just updated my power-supply next branch
> > > to v4.9-rc1 and now get almost 18000 CRC warnings for allmodconfig.
> > > (I use arm-linux-gnueabihf-gcc (Debian 6.1.1-9) 6.1.1 20160705)
> >
> > Nick did a patch to fix this in general, and in powerpc specifically,
> > I sent a patch yesterday to fix the ARM specific symbols.
>
> Did you now? You failed to _at least_ copy me on that. This is clearly
> about core ARM code and not arm-soc stuff, you should always copy me on
> such changes, and if I were Lee Jones, I'd insist that it was merged
> through my tree.
Right, sorry for missing the Cc, this was one of many build-time
bugfix patches I sent out recently.
Nick's patch is still under discussion on linux-arch, and my patch
is part of that discussion, but of course you should have been
included in the discussion as well.
Arnd
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Maxime Ripard @ 2016-10-18 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018092422.GJ1041@n2100.armlinux.org.uk>
Hi Russell,
On Tue, Oct 18, 2016 at 10:24:22AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 10:29:33AM +0200, Maxime Ripard wrote:
> > The Allwinner display engine doesn't have any kind of hardware help to deal
> > with TV overscan.
>
> I'm not sure I follow. My understanding (from reading the CEA specs)
> is that TVs are expected to overscan the image, so the upper left, and
> bottom right pixels are not visible.
Yes, this is why we have to work around it somehow.
> I assume we are talking about TVs connected via HDMI. In the HDMI AVI
> infoframe, there are bits which specify whether the image should be
> overscanned or underscanned - however, whether a TV implements those
> bits is rather sketchy. I assume when you say "any kind of hardware
> help" you mean you can't control these bits?
>
> However, some (most?) TVs now implement a menu option which allows the
> (over)scan mode to be selected. Others assume that if it's a TV mode,
> it's supposed to be overscanned, if it's a "PC" mode, it should be
> underscanned and provide no option to change the behaviour.
We're talking about plain dumb composite output, so no infoframes,
setup or anything here :)
> > This means that if we use the only mode the hardware provides (either PAL
> > or NTSC, or something else), most of the screens will crop the borders of
> > the image, which is bad.
>
> I think you're trying to apply monitor-type behaviour to TVs...
Yes, kind of. Our users are usually running a desktop distro, and the
default output on those boards are just plain composite, which means
running any DE onto a TV.
Note that it's not only about the interface itself, but you'll lose
content for all pictures displayed. And no one cares about the TV safe
area anymore these days (starting with the framebuffer console).
> > We can however use somekind of a hack, to instead reduce the mode
> > exposed to the userspace, and center it in the final image. We
> > would expose different overscan ratio to be able to deal with most
> > of the screens, each reducing more the displayable area.
>
> I'm not sure we need "a hack". What if we treated the primary plane just
> like any other (eg, overlay) plane? We could then specify (eg) a 1920x1080
> display mode, but with the primary plane reduced in size, positioned in
> the centre of the display mode?
>
> I know that there's hardware out there which can do exactly that - Marvell
> Dove implements this: you set the display size separately from two planes,
> one graphics plane and one video plane. Both planes can be positioned
> anywhere in the displayed size.
This might have been poorly worded on my side, but it's exactly what
I'm doing in those patches.
> We could then specify at DRM level that a connected device overscans by
> N%, and have the primary plane adjusted by DRM itself.
I'd agree with you, however, there's a few issues with that I
think.
The first one is that this overscanning should be reported by the
connector I guess? but this is really TV specific, so we need one way
to let the user tell how the image is displayed on its side, and we
cannot really autodetect it, and this needs to be done at runtime so
that we can present some shiny interface to let it select which
overscan ratio works for him/her.
The second one is that we still need to expose the reduced modes to
userspace, and not only the displayed size, so that the applications
know what they must draw on. But I guess this could be adjusted by the
core too.
In order to work consistently, I think all planes should be adjusted
that way, so that relative coordinates are from the primary plane
origin, and not the display origin. But that could be adjusted too by
the core I guess.
The fourth one being the major one. Every time I raised the issue on
IRC, the answer basically was "we don't care about analog", so I'm a
bit pessimistic about whether dealing with this in the core would be
accepted, hence why I chose to deal with this at the driver level.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161018/64e682e0/attachment.sig>
^ permalink raw reply
* [PATCH 02/28] [v2] mtd: mtk: avoid warning in mtk_ecc_encode
From: RogerCC.Lin @ 2016-10-18 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018071948.0b7eef05@bbrezillon>
On Tue, 2016-10-18 at 07:19 +0200, Boris Brezillon wrote:
> On Tue, 18 Oct 2016 00:05:31 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > When building with -Wmaybe-uninitialized, gcc produces a silly false positive
> > warning for the mtk_ecc_encode function:
> >
> > drivers/mtd/nand/mtk_ecc.c: In function 'mtk_ecc_encode':
> > drivers/mtd/nand/mtk_ecc.c:402:15: error: 'val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > The function for some reason contains a double byte swap on big-endian
> > builds to get the OOB data into the correct order again, and is written
> > in a slightly confusing way.
> >
> > Using a simple memcpy32_fromio() to read the data simplifies it a lot
> > so it becomes more readable and produces no warning. However, the
> > output might not have 32-bit alignment, so we have to use another
> > memcpy to avoid taking alignment faults or writing beyond the end
> > of the array.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Jorge, RogerCC, can I have an Acked-by and/or Tested-by for this patch?
Tested, this patch is OK,
Tested-by: RogerCC Lin <rogercc.lin@mediatek.com>
>
> > ---
> > v2: move temporary buffer into struct mtk_ecc instead of having it
> > on the stack, as suggested by Boris Brezillon
> > ---
> > drivers/mtd/nand/mtk_ecc.c | 19 +++++++++----------
> > 1 file changed, 9 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/mtk_ecc.c b/drivers/mtd/nand/mtk_ecc.c
> > index d54f666..dbf2562 100644
> > --- a/drivers/mtd/nand/mtk_ecc.c
> > +++ b/drivers/mtd/nand/mtk_ecc.c
> > @@ -86,6 +86,8 @@ struct mtk_ecc {
> > struct completion done;
> > struct mutex lock;
> > u32 sectors;
> > +
> > + u8 eccdata[112];
> > };
> >
> > static inline void mtk_ecc_wait_idle(struct mtk_ecc *ecc,
> > @@ -366,9 +368,8 @@ int mtk_ecc_encode(struct mtk_ecc *ecc, struct mtk_ecc_config *config,
> > u8 *data, u32 bytes)
> > {
> > dma_addr_t addr;
> > - u8 *p;
> > - u32 len, i, val;
> > - int ret = 0;
> > + u32 len;
> > + int ret;
> >
> > addr = dma_map_single(ecc->dev, data, bytes, DMA_TO_DEVICE);
> > ret = dma_mapping_error(ecc->dev, addr);
> > @@ -393,14 +394,12 @@ int mtk_ecc_encode(struct mtk_ecc *ecc, struct mtk_ecc_config *config,
> >
> > /* Program ECC bytes to OOB: per sector oob = FDM + ECC + SPARE */
> > len = (config->strength * ECC_PARITY_BITS + 7) >> 3;
> > - p = data + bytes;
> >
> > - /* write the parity bytes generated by the ECC back to the OOB region */
> > - for (i = 0; i < len; i++) {
> > - if ((i % 4) == 0)
> > - val = readl(ecc->regs + ECC_ENCPAR(i / 4));
> > - p[i] = (val >> ((i % 4) * 8)) & 0xff;
> > - }
> > + /* write the parity bytes generated by the ECC back to temp buffer */
> > + __ioread32_copy(ecc->eccdata, ecc->regs + ECC_ENCPAR(0), round_up(len, 4));
> > +
> > + /* copy into possibly unaligned OOB region with actual length */
> > + memcpy(data + bytes, ecc->eccdata, len);
> > timeout:
> >
> > dma_unmap_single(ecc->dev, addr, bytes, DMA_TO_DEVICE);
>
^ permalink raw reply
* [PATCH] ARM: dts: realview: Extend PBX family memory description
From: Robin Murphy @ 2016-10-18 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476778873-12210-1-git-send-email-linus.walleij@linaro.org>
On 18/10/16 09:21, Linus Walleij wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> All three platforms sharing the later RealView Platform Baseboard memory
> map - PBX-A9, PB-A8 and PB11MPCore, provide 512MB of DDR SDRAM on the
> baseboard, of which the boot alias at 0x0 maps the first 256MB. Expand
> the size of the default memory node to reflect that, and describe the
> full memory regions in each board's DTS, but leave those commented by
> default to avoid breaking existing bootloaders.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC folks: I forgot to send this patch for ARM SoC earlier.
> As it is a small change I suggest you just apply it to the ARM
> SoC tree as I do not foresee any other RealView work in the near
> future. If you think it can go into v4.9 then put it in as a fix,
> else just push it to the next merge window.
> Robin: sorry for screwing up :(
No worries - it's gone back in the cupboard now anyway :)
Robin.
> ---
> arch/arm/boot/dts/arm-realview-pba8.dts | 8 ++++++++
> arch/arm/boot/dts/arm-realview-pbx-a9.dts | 9 +++++++++
> arch/arm/boot/dts/arm-realview-pbx.dtsi | 4 ++--
> 3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/arm-realview-pba8.dts b/arch/arm/boot/dts/arm-realview-pba8.dts
> index d3238c252b59..9f6c92b84f9f 100644
> --- a/arch/arm/boot/dts/arm-realview-pba8.dts
> +++ b/arch/arm/boot/dts/arm-realview-pba8.dts
> @@ -40,6 +40,14 @@
> };
> };
>
> + /*
> + * Using the full 512MB of RAM will require bootloader
> + * changes to not load the kernel to the alias at 0x0.
> + */
> + memory {
> + /*reg = <0x70000000 0x20000000>; /* 512 MiB baseboard DDR */
> + };
> +
> pmu: pmu at 0 {
> compatible = "arm,cortex-a8-pmu";
> interrupt-parent = <&intc>;
> diff --git a/arch/arm/boot/dts/arm-realview-pbx-a9.dts b/arch/arm/boot/dts/arm-realview-pbx-a9.dts
> index 90d00b407f85..9fef9188660a 100644
> --- a/arch/arm/boot/dts/arm-realview-pbx-a9.dts
> +++ b/arch/arm/boot/dts/arm-realview-pbx-a9.dts
> @@ -60,6 +60,15 @@
> };
> };
>
> + /*
> + * There is 1GB of RAM total, but using all of it will require
> + * bootloader changes to not load the kernel to the alias at 0x0.
> + */
> + memory {
> + /*reg = <0x20000000 0x20000000>, /* 512 MiB daughterboard DDR2 */
> + /* <0x70000000 0x20000000>; /* 512 MiB baseboard DDR */
> + };
> +
> L2: l2-cache {
> compatible = "arm,pl310-cache";
> reg = <0x1f002000 0x1000>;
> diff --git a/arch/arm/boot/dts/arm-realview-pbx.dtsi b/arch/arm/boot/dts/arm-realview-pbx.dtsi
> index aeb49c4bd773..8477f667d27c 100644
> --- a/arch/arm/boot/dts/arm-realview-pbx.dtsi
> +++ b/arch/arm/boot/dts/arm-realview-pbx.dtsi
> @@ -38,8 +38,8 @@
> };
>
> memory {
> - /* 128 MiB memory @ 0x0 */
> - reg = <0x00000000 0x08000000>;
> + /* 256 MiB alias of baseboard DDR @ 0x0 */
> + reg = <0x00000000 0x10000000>;
> };
>
> /* The voltage to the MMC card is hardwired at 3.3V */
>
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Mark Rutland @ 2016-10-18 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006161114.GH22012@rric.localdomain>
Hi Robert, Ard,
Sorry for the delay in getting to this; I've been travelling a lot
lately and in the meantime this managed to get buried in my inbox.
On Thu, Oct 06, 2016 at 06:11:14PM +0200, Robert Richter wrote:
> On 06.10.16 11:00:33, Ard Biesheuvel wrote:
> > On 6 October 2016 at 10:52, Robert Richter <rrichter@cavium.com> wrote:
> > > There is a memory setup problem on ThunderX systems with certain
> > > memory configurations. The symptom is
> > >
> > > kernel BUG at mm/page_alloc.c:1848!
> > >
> > > This happens for some configs with 64k page size enabled. The bug
> > > triggers for page zones with some pages in the zone not assigned to
> > > this particular zone. In my case some pages that are marked as nomap
> > > were not reassigned to the new zone of node 1, so those are still
> > > assigned to node 0.
> > >
> > > The reason for the mis-configuration is a change in pfn_valid() which
> > > reports pages marked nomap as invalid:
> > >
> > > 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
> >
> > These pages are owned by the firmware, which may map it with
> > attributes that conflict with the attributes we use for the linear
> > mapping. This means they should not be covered by the linear mapping.
> >
> > > This causes pages marked as nomap being no long reassigned to the new
> > > zone in memmap_init_zone() by calling __init_single_pfn().
Why do we have pages for a nomap region? Given the region shouldn't be
in the linear mapping, and isn't suitable for general allocation, I
don't believe it makes sense to have a struct page for any part of it.
Am I missing some reason that we require a struct page?
e.g. is it just easier to allocate an unused struct page than to carve
it out?
> > This sounds like the root cause of your issue. Could we not fix that instead?
>
> Yes, this is proposal b) from my last mail that would work too: I
> implemented an arm64 private early_pfn_valid() function that uses
> memblock_is_memory() to setup all pages of a zone. Though, I think
> this is the wrong way and thus I prefer this patch instead. I see
> serveral reasons for this:
>
> Inconsistent use of struct *page, it is initialized but never used
> again.
As above, I don't believe we should have a struct page to initialise in
the first place.
> Other archs only do a basic range check in pfn_valid(), the default
> implementation just returns if the whole section is valid. As I
> understand the code, if the mem range is not aligned to the section,
> then there will be pfn's in the section that don't have physical mem
> attached. The page is then just initialized, it's not marked reserved
> nor the refcount is non-zero. It is then simply not used. This is how
> no-map pages should be handled too.
>
> I think pfn_valid() is just a quick check if the pfn's struct *page
> can be used. There is a good description for this in include/linux/
> mmzone.h. So there can be memory holes that have a valid pfn.
I take it you mean the comment in the CONFIG_ARCH_HAS_HOLES_MEMORYMODEL
ifdef (line 1266 in v4.9-rc1)?
I'm not sufficiently acquainted with the memmap code to follow; I'll
need to dig into that a bit further.
> If the no-map memory needs special handling, then additional checks
> need to be added to the particular code (as in ioremap.c). It's imo
> wrong to (mis-)use pfn_valid for that.
>
> Variant b) involves generic mm code to fix it for arm64, this patch is
> an arm64 change only. This makes it harder to get a fix for it.
> (Though maybe only a problem of patch logistics.)
>
> > > Fixing this by restoring the old behavior of pfn_valid() to use
> > > memblock_is_memory().
> >
> > This is incorrect imo. In general, pfn_valid() means ordinary memory
> > covered by the linear mapping and the struct page array. Returning
> > reserved ranges that the kernel should not even touch only to please
> > the NUMA code seems like an inappropriate way to deal with this issue.
>
> As said above, it is not marked as reserved, it is treated like
> non-existing memory.
I think Ard was using "reserved" in the more general sense than the
Linux-specific meaning. NOMAP is distinct from the Linux concept of
"reserved" memory, but is "reserved" in some sense.
Memory with NOMAP is meant to be treated as non-existent for the purpose
of the linear mapping (and thus for the purpose of struct page).
> This has been observed for non-numa kernels too and can happen for
> each zone that is only partly initialized.
>
> I think the patch addresses your concerns. I can't see there the
> kernel uses memory marked as nomap in a wrong way.
I'll have to dig into this locally; I'm still not familiar enough with
this code to know what the right thing to do is.
Thanks,
Mark.
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Sudeep Holla @ 2016-10-18 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018100002.GA4347@xo-6d-61-c0.localdomain>
On 18/10/16 11:00, Pavel Machek wrote:
> Hi!
>
>>> b. in arm64, if some platform has its own suspend flow, couldn't it
>>> adopts arm/match-xxx to register its own global suspend method?
>>>
>>
>> No, PSCI is highly recommended.
>
> Relying on firmware for suspend on x86 was a great disaster, lets not repeat
> that mistake.
Could you be more elaborate on this ?
arm32 has better powermanagement than x86 ever will (see Nokia N900
> for example) -- feel free to copy that code from arm32.
OK are you suggesting that pull in all the low level assembly code that
are very platform specific in to the kernel ?
Sorry, no thanks. We don't want that in the kernel and IMO that's one of
the reason why many platforms lacked PM support in the upstream kernel
as they were too platform specific and hinders the progress towards
single kernel.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v10 11/11] ARM: multi_v7_defconfig: Enable STi and simple-card drivers.
From: Mark Brown @ 2016-10-18 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476783556-2501-12-git-send-email-peter.griffin@linaro.org>
On Tue, Oct 18, 2016 at 10:39:16AM +0100, Peter Griffin wrote:
> This patch enables the STi ALSA drivers found on STi platforms
> as well as the simple-card driver which is a dependency to have
> working sound.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> Cc: arnaud.pouliquen at st.com
> Cc: broonie at kernel.org
There's no need to keep CCing me on all these resends.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161018/457dbe22/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/2] MMC: meson: initial support for GXBB platforms
From: Ulf Hansson @ 2016-10-18 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914004314.682-2-khilman@baylibre.com>
[...]
> +static int meson_mmc_clk_set(struct meson_host *host, unsigned long clk_rate)
> +{
> + struct mmc_host *mmc = host->mmc;
> + int ret = 0;
> + u32 cfg;
> +
> + if (clk_rate) {
> + if (WARN_ON(clk_rate > mmc->f_max))
> + clk_rate = mmc->f_max;
> + else if (WARN_ON(clk_rate < mmc->f_min))
> + clk_rate = mmc->f_min;
> + }
> +
> + if (clk_rate == mmc->actual_clock)
> + return 0;
> +
> + /* stop clock */
> + cfg = readl(host->regs + SD_EMMC_CFG);
> + if (!(cfg & CFG_STOP_CLOCK)) {
> + cfg |= CFG_STOP_CLOCK;
> + writel(cfg, host->regs + SD_EMMC_CFG);
> + }
> +
> + dev_dbg(host->dev, "change clock rate %u -> %lu\n",
> + mmc->actual_clock, clk_rate);
> + ret = clk_set_rate(host->cfg_div_clk, clk_rate);
Shouldn't you check the error before proceeding?
> + if (clk_rate && clk_rate != clk_get_rate(host->cfg_div_clk))
> + dev_warn(host->dev, "divider requested rate %lu != actual rate %lu: ret=%d\n",
> + clk_rate, clk_get_rate(host->cfg_div_clk), ret);
> + else
> + mmc->actual_clock = clk_rate;
> +
> + /* (re)start clock, if non-zero */
> + if (clk_rate) {
> + cfg = readl(host->regs + SD_EMMC_CFG);
> + cfg &= ~CFG_STOP_CLOCK;
> + writel(cfg, host->regs + SD_EMMC_CFG);
> + }
> +
> + return ret;
> +}
> +
> +/*
> + * The SD/eMMC IP block has an internal mux and divider used for
> + * generating the MMC clock. Use the clock framework to create and
> + * manage these clocks.
> + */
> +static int meson_mmc_clk_init(struct meson_host *host)
> +{
> + struct clk_init_data init;
> + char clk_name[32];
> + int i, ret = 0;
> + const char *mux_parent_names[MUX_CLK_NUM_PARENTS];
> + unsigned int mux_parent_count = 0;
> + const char *clk_div_parents[1];
> + unsigned int f_min = UINT_MAX;
> + u32 clk_reg, cfg;
> +
> + /* get the mux parents */
> + for (i = 0; i < MUX_CLK_NUM_PARENTS; i++) {
> + char name[16];
> +
> + snprintf(name, sizeof(name), "clkin%d", i);
> + host->mux_parent[i] = devm_clk_get(host->dev, name);
> + if (IS_ERR(host->mux_parent[i])) {
> + ret = PTR_ERR(host->mux_parent[i]);
> + if (PTR_ERR(host->mux_parent[i]) != -EPROBE_DEFER)
> + dev_err(host->dev, "Missing clock %s\n", name);
> + host->mux_parent[i] = NULL;
> + return ret;
> + }
> +
> + host->mux_parent_rate[i] = clk_get_rate(host->mux_parent[i]);
> + mux_parent_names[i] = __clk_get_name(host->mux_parent[i]);
> + mux_parent_count++;
> + if (host->mux_parent_rate[i] < f_min)
> + f_min = host->mux_parent_rate[i];
> + }
> +
> + /* cacluate f_min based on input clocks, and max divider value */
> + if (f_min != UINT_MAX)
> + f_min = DIV_ROUND_UP(CLK_SRC_XTAL_RATE, CLK_DIV_MAX);
> + else
> + f_min = 4000000; /* default min: 400 MHz */
> + host->mmc->f_min = f_min;
> +
> + /* create the mux */
> + snprintf(clk_name, sizeof(clk_name), "%s#mux", dev_name(host->dev));
> + init.name = clk_name;
> + init.ops = &clk_mux_ops;
> + init.flags = 0;
> + init.parent_names = mux_parent_names;
> + init.num_parents = mux_parent_count;
> +
> + host->mux.reg = host->regs + SD_EMMC_CLOCK;
> + host->mux.shift = CLK_SRC_SHIFT;
> + host->mux.mask = CLK_SRC_MASK;
> + host->mux.flags = 0;
> + host->mux.table = NULL;
> + host->mux.hw.init = &init;
> +
> + host->mux_clk = devm_clk_register(host->dev, &host->mux.hw);
> + if (WARN_ON(IS_ERR(host->mux_clk)))
> + return PTR_ERR(host->mux_clk);
> +
> + /* create the divider */
> + snprintf(clk_name, sizeof(clk_name), "%s#div", dev_name(host->dev));
> + init.name = devm_kstrdup(host->dev, clk_name, GFP_KERNEL);
> + init.ops = &clk_divider_ops;
> + init.flags = CLK_SET_RATE_PARENT;
> + clk_div_parents[0] = __clk_get_name(host->mux_clk);
> + init.parent_names = clk_div_parents;
> + init.num_parents = ARRAY_SIZE(clk_div_parents);
> +
> + host->cfg_div.reg = host->regs + SD_EMMC_CLOCK;
> + host->cfg_div.shift = CLK_DIV_SHIFT;
> + host->cfg_div.width = CLK_DIV_WIDTH;
> + host->cfg_div.hw.init = &init;
> + host->cfg_div.flags = CLK_DIVIDER_ONE_BASED |
> + CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ALLOW_ZERO;
> +
> + host->cfg_div_clk = devm_clk_register(host->dev, &host->cfg_div.hw);
> + if (WARN_ON(PTR_ERR_OR_ZERO(host->cfg_div_clk)))
> + return PTR_ERR(host->cfg_div_clk);
> +
> + /* init SD_EMMC_CLOCK to sane defaults w/min clock rate */
> + clk_reg = 0;
> + clk_reg |= CLK_PHASE_180 << CLK_PHASE_SHIFT;
> + clk_reg |= CLK_SRC_XTAL << CLK_SRC_SHIFT;
> + clk_reg |= CLK_DIV_MAX << CLK_DIV_SHIFT;
> + clk_reg &= ~CLK_ALWAYS_ON;
> + writel(clk_reg, host->regs + SD_EMMC_CLOCK);
> +
> + /* Ensure clock starts in "auto" mode, not "always on" */
> + cfg = readl(host->regs + SD_EMMC_CFG);
> + cfg &= ~CFG_CLK_ALWAYS_ON;
> + cfg |= CFG_AUTO_CLK;
> + writel(cfg, host->regs + SD_EMMC_CFG);
> +
> + ret = clk_prepare_enable(host->cfg_div_clk);
> + if (!ret)
> + ret = meson_mmc_clk_set(host, f_min);
> +
In case of errors, I guess you should disable/unprepare the clock.
> + return ret;
> +}
> +
[...]
> +
> +static int meson_mmc_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + struct meson_host *host;
> + struct mmc_host *mmc;
> + int ret;
> +
> + mmc = mmc_alloc_host(sizeof(struct meson_host), &pdev->dev);
> + if (!mmc)
> + return -ENOMEM;
> + host = mmc_priv(mmc);
> + host->mmc = mmc;
> + host->dev = &pdev->dev;
> + dev_set_drvdata(&pdev->dev, host);
> +
> + spin_lock_init(&host->lock);
> +
> + host->core_clk = devm_clk_get(&pdev->dev, "core");
> + if (IS_ERR(host->core_clk)) {
> + ret = PTR_ERR(host->core_clk);
> + goto free_host;
> + }
> +
> + /* Get regulators and the supported OCR mask */
> + host->vqmmc_enabled = false;
> + ret = mmc_regulator_get_supply(mmc);
> + if (ret == -EPROBE_DEFER)
> + goto free_host;
In free_host you call clk_disable_unprepare(). You don't want to do
that unless you already called clk_prepare_enable().
So, I think you need another label to distinguish between these two cases.
> +
> + ret = mmc_of_parse(mmc);
> + if (ret) {
> + dev_warn(&pdev->dev, "error parsing DT: %d\n", ret);
> + goto free_host;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + host->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(host->regs)) {
> + ret = PTR_ERR(host->regs);
> + goto free_host;
> + }
> +
> + host->irq = platform_get_irq(pdev, 0);
> + if (host->irq == 0) {
> + dev_err(&pdev->dev, "failed to get interrupt resource.\n");
> + ret = -EINVAL;
> + goto free_host;
> + }
> +
> + ret = clk_prepare_enable(host->core_clk);
> + if (ret)
> + goto free_host;
> +
> + ret = meson_mmc_clk_init(host);
> + if (ret)
> + goto free_host;
> +
> + /* Stop execution */
> + writel(0, host->regs + SD_EMMC_START);
> +
> + /* clear, ack, enable all interrupts */
> + writel(0, host->regs + SD_EMMC_IRQ_EN);
> + writel(IRQ_EN_MASK, host->regs + SD_EMMC_STATUS);
> +
> + ret = devm_request_threaded_irq(&pdev->dev, host->irq,
> + meson_mmc_irq, meson_mmc_irq_thread,
> + IRQF_SHARED, DRIVER_NAME, host);
> + if (ret)
> + goto free_host;
Besides the earlier issue mentiond for the label free_host, here you
also need to consider yet another clock that has be been enabled in
meson_mmc_clk_init(). I assume you want to disable this clock in the
error path.
> +
> + /* data bounce buffer */
> + host->bounce_buf_size = SZ_512K;
> + host->bounce_buf =
> + dma_alloc_coherent(host->dev, host->bounce_buf_size,
> + &host->bounce_dma_addr, GFP_KERNEL);
> + if (host->bounce_buf == NULL) {
> + dev_err(host->dev, "Unable to map allocate DMA bounce buffer.\n");
> + ret = -ENOMEM;
> + goto free_host;
> + }
> +
> + mmc->ops = &meson_mmc_ops;
> + mmc_add_host(mmc);
> +
> + return 0;
> +
> +free_host:
> + dev_dbg(host->dev, "Failed to probe: ret=%d\n", ret);
No need to print this, already managed by driver core.
> + if (host->core_clk)
No need to check above, already done by the clock framework.
> + clk_disable_unprepare(host->core_clk);
> + mmc_free_host(mmc);
> + return ret;
> +}
> +
> +static int meson_mmc_remove(struct platform_device *pdev)
> +{
> + struct meson_host *host = dev_get_drvdata(&pdev->dev);
> +
> + if (WARN_ON(!host))
> + return 0;
> +
> + if (host->bounce_buf)
> + dma_free_coherent(host->dev, host->bounce_buf_size,
> + host->bounce_buf, host->bounce_dma_addr);
> +
> + if (host->cfg_div_clk)
No need to check this, aleady done by the clock framework.
> + clk_disable_unprepare(host->cfg_div_clk);
> +
> + if (host->core_clk)
Ditto.
> + clk_disable_unprepare(host->core_clk);
> +
> + mmc_free_host(host->mmc);
> + return 0;
> +}
> +
[...]
Besides the minor stuff pointed out above, this looks great to me!
Before you re-spin, please drop this series from your branch which is
being integrated into linux-next, as otherwise I can't pick it up.
Kind regards
Uffe
^ permalink raw reply
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Hans de Goede @ 2016-10-18 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67iQikSHcwS15VmSC6fNMVG9Zya9fz6C6b5+wW43rPZfw@mail.gmail.com>
Hi,
On 18-10-16 07:25, Chen-Yu Tsai wrote:
> On Wed, Oct 5, 2016 at 11:51 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> The i2c subsys does not load modules by compatible, only by
>> i2c-id, with e.g. a modalias of: "i2c:axp209".
>>
>> Populate the axp20x_i2c_id[] table with supported ids, so that
>> module auto-loading will work.
>>
>> Reported-by: Dennis Gilmore <dennis@ausil.us>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> Even though axp20x-i2c seems to be the only "DT only" i2c client,
> would it make sense to add DT-based module autoloading to the i2c
> core?
If it is not too invasive, then yes that would be a sensible addition IMHO.
Regards,
Hans
^ permalink raw reply
* [PATCH] ARM: dts: realview: Extend PBX family memory description
From: Russell King - ARM Linux @ 2016-10-18 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476778873-12210-1-git-send-email-linus.walleij@linaro.org>
On Tue, Oct 18, 2016 at 10:21:13AM +0200, Linus Walleij wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> All three platforms sharing the later RealView Platform Baseboard memory
> map - PBX-A9, PB-A8 and PB11MPCore, provide 512MB of DDR SDRAM on the
> baseboard, of which the boot alias at 0x0 maps the first 256MB. Expand
> the size of the default memory node to reflect that, and describe the
> full memory regions in each board's DTS, but leave those commented by
> default to avoid breaking existing bootloaders.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ARM SoC folks: I forgot to send this patch for ARM SoC earlier.
> As it is a small change I suggest you just apply it to the ARM
> SoC tree as I do not foresee any other RealView work in the near
> future. If you think it can go into v4.9 then put it in as a fix,
> else just push it to the next merge window.
> Robin: sorry for screwing up :(
Normally, memory nodes describe different regions of unique memory.
This is not unique memory, but is an alias of some already-described
memory.
The problem with adding the aliased memory addresses is that we end
up needing platform knowledge to reject the "other alias" from the
memory description, which really isn't good.
The only reason it works is that we reject memory nodes where the
physical address < PHYS_OFFSET. That works provided the alias is
below PHYS_OFFSET, but that isn't always the case.
So, I think it is completely wrong to describe the aliased memory
regions in DT.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 3/3] arm64: dts: Update Broadcom NS2 to generic IOMMU binding
From: Robin Murphy @ 2016-10-18 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <77abd968-f412-a118-5b19-5faf539f33be@gmail.com>
On 18/10/16 01:58, Florian Fainelli wrote:
> On 10/17/2016 05:13 AM, Robin Murphy wrote:
>> With the "mmu-masters" property now deprecated and optional, the
>> generic binding offers a more efficient way to specify no masters.
>>
>> CC: Ray Jui <rjui@broadcom.com>
>> CC: Scott Branden <sbranden@broadcom.com>
>> CC: Jon Mason <jonmason@broadcom.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> Applied, did you use get_maintainers.pl for this file? It did not land
> in bcm-kernel-feedback-list at broadcom.com and as such did not get picked
> by the patchwork instance behind..
Oops, sorry! I somehow managed to overlook that - I'll try paying closer
attention in future :)
Thanks,
Robin.
^ permalink raw reply
* [PATCH 0/3] PAN Fixes
From: James Morse @ 2016-10-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This series fixes two issues for PAN discovered by Vladimir and Tony:
* Patch 2 changes the cpu_enable_pan() to not only enable the automatic
PAN setting when return to the kernel from userspace, but also turn
it on right now. This covers the case where a pre-empted task may be
migrated to a new CPU that hasn't yet done a return-to-user.
* Patch 1 is a prerequisite which fixes the enable() calls to not use
an IPI, (details in the patch). This means we can modify PSTATE from
an enable call, which is broken today, but we don't actually depend
on it...
Patch 3 fixes a third issue where we lose the PSTATE value over cpu-idle,
this will be a problem in the same pre-empted task migrated to a
'new' CPU case above, and if we return from idle to a user task, (which
I believe suspend-to-ram does).
Patch 1 changes the prototype of all the enable calls, so can't be
backported. I will produce separate backports for v4.4.25 and v4.7.8.
Based on v4.9-rc1, with [0] applied locally to fix cpuhotplug. This
series can be retrieved from:
Thanks,
James
[0] https://www.spinics.net/lists/kernel/msg2357812.html
James Morse (3):
arm64: cpufeature: Schedule enable() calls instead of calling them via
IPI
arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call
arm64: suspend: Reconfigure PSTATE after resume from idle
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/exec.h | 3 +++
arch/arm64/include/asm/processor.h | 6 +++---
arch/arm64/kernel/cpu_errata.c | 3 ++-
arch/arm64/kernel/cpufeature.c | 10 +++++++++-
arch/arm64/kernel/process.c | 3 ++-
arch/arm64/kernel/suspend.c | 11 +++++++++++
arch/arm64/kernel/traps.c | 3 ++-
arch/arm64/mm/fault.c | 15 +++++++++++++--
9 files changed, 46 insertions(+), 10 deletions(-)
--
2.8.0.rc3
^ permalink raw reply
* [PATCH 1/3] arm64: cpufeature: Schedule enable() calls instead of calling them via IPI
From: James Morse @ 2016-10-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476786468-2173-1-git-send-email-james.morse@arm.com>
The enable() call for a cpufeature/errata is called using on_each_cpu().
This issues a cross-call IPI to get the work done. Implicitly, this
stashes the running PSTATE in SPSR when the CPU receives the IPI, and
restores it when we return. This means an enable() call can never modify
PSTATE.
To allow PAN to do this, change the on_each_cpu() call to use
stop_machine(). This schedules the work on each CPU which allows
us to modify PSTATE.
This involves changing the protype of all the enable() functions.
enable_cpu_capabilities() is called during boot and enables the feature
on all online CPUs. This path now uses stop_machine(). CPU features for
hotplug'd CPUs are enabled by verify_local_cpu_features() which only
acts on the local CPU, and can already modify the running PSTATE as it
is called from secondary_start_kernel().
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
---
The UAO enable call also suffers from this problem, but it is useless
and broken. After this patch it is merely useless, and will be removed,
by a later patch, (replaced with a comment describing what actually
happens).
This patch doesn't apply to linux-stable versions before v4.8 because
it conflicts with every feature introduced since v4.4. If you want this
in stable give me a kick and I will produce versions for v4.4.25 and
v4.7.8 (stable versions since v4.3 when PAN was introduced).
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/processor.h | 6 +++---
arch/arm64/kernel/cpu_errata.c | 3 ++-
arch/arm64/kernel/cpufeature.c | 10 +++++++++-
arch/arm64/kernel/traps.c | 3 ++-
arch/arm64/mm/fault.c | 6 ++++--
6 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 758d74fedfad..a27c3245ba21 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -94,7 +94,7 @@ struct arm64_cpu_capabilities {
u16 capability;
int def_scope; /* default scope */
bool (*matches)(const struct arm64_cpu_capabilities *caps, int scope);
- void (*enable)(void *); /* Called on all active CPUs */
+ int (*enable)(void *); /* Called on all active CPUs */
union {
struct { /* To be used for erratum handling only */
u32 midr_model;
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index df2e53d3a969..60e34824e18c 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -188,8 +188,8 @@ static inline void spin_lock_prefetch(const void *ptr)
#endif
-void cpu_enable_pan(void *__unused);
-void cpu_enable_uao(void *__unused);
-void cpu_enable_cache_maint_trap(void *__unused);
+int cpu_enable_pan(void *__unused);
+int cpu_enable_uao(void *__unused);
+int cpu_enable_cache_maint_trap(void *__unused);
#endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 0150394f4cab..b75e917aac46 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -39,10 +39,11 @@ has_mismatched_cache_line_size(const struct arm64_cpu_capabilities *entry,
(arm64_ftr_reg_ctrel0.sys_val & arm64_ftr_reg_ctrel0.strict_mask);
}
-static void cpu_enable_trap_ctr_access(void *__unused)
+static int cpu_enable_trap_ctr_access(void *__unused)
{
/* Clear SCTLR_EL1.UCT */
config_sctlr_el1(SCTLR_EL1_UCT, 0);
+ return 0;
}
#define MIDR_RANGE(model, min, max) \
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d577f263cc4a..c02504ea304b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -19,7 +19,9 @@
#define pr_fmt(fmt) "CPU features: " fmt
#include <linux/bsearch.h>
+#include <linux/cpumask.h>
#include <linux/sort.h>
+#include <linux/stop_machine.h>
#include <linux/types.h>
#include <asm/cpu.h>
#include <asm/cpufeature.h>
@@ -941,7 +943,13 @@ void __init enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
{
for (; caps->matches; caps++)
if (caps->enable && cpus_have_cap(caps->capability))
- on_each_cpu(caps->enable, NULL, true);
+ /*
+ * Use stop_machine() as it schedules the work allowing
+ * us to modify PSTATE, instead of on_each_cpu() which
+ * uses an IPI, giving us a PSTATE that disappears when
+ * we return.
+ */
+ stop_machine(caps->enable, NULL, cpu_online_mask);
}
/*
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 5ff020f8fb7f..e3a9f8da16e5 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -428,9 +428,10 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
force_signal_inject(SIGILL, ILL_ILLOPC, regs, 0);
}
-void cpu_enable_cache_maint_trap(void *__unused)
+int cpu_enable_cache_maint_trap(void *__unused)
{
config_sctlr_el1(SCTLR_EL1_UCI, 0);
+ return 0;
}
#define __user_cache_maint(insn, address, res) \
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 53d9159662fe..3e9ff9b0c78d 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -670,9 +670,10 @@ asmlinkage int __exception do_debug_exception(unsigned long addr,
NOKPROBE_SYMBOL(do_debug_exception);
#ifdef CONFIG_ARM64_PAN
-void cpu_enable_pan(void *__unused)
+int cpu_enable_pan(void *__unused)
{
config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+ return 0;
}
#endif /* CONFIG_ARM64_PAN */
@@ -683,8 +684,9 @@ void cpu_enable_pan(void *__unused)
* We need to enable the feature at runtime (instead of adding it to
* PSR_MODE_EL1h) as the feature may not be implemented by the cpu.
*/
-void cpu_enable_uao(void *__unused)
+int cpu_enable_uao(void *__unused)
{
asm(SET_PSTATE_UAO(1));
+ return 0;
}
#endif /* CONFIG_ARM64_UAO */
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH 2/3] arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call
From: James Morse @ 2016-10-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476786468-2173-1-git-send-email-james.morse@arm.com>
Commit 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access
Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1.
This means the PSTATE.PAN bit won't be set until the next return to the
kernel from userspace. On a preemptible kernel we may schedule work that
accesses userspace on a CPU before it has done this.
Now that cpufeature enable() calls are scheduled via stop_machine(), we
can set PSTATE.PAN from the cpu_enable_pan() call.
Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated
is not immediately discarded.
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
---
This patch depends on 'arm64: cpufeature: Schedule enable() calls instead
of calling them via IPI', which doesn't apply to linux-stable versions
before v4.8.
arch/arm64/mm/fault.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 3e9ff9b0c78d..f942ab6cc206 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -29,7 +29,9 @@
#include <linux/sched.h>
#include <linux/highmem.h>
#include <linux/perf_event.h>
+#include <linux/preempt.h>
+#include <asm/bug.h>
#include <asm/cpufeature.h>
#include <asm/exception.h>
#include <asm/debug-monitors.h>
@@ -672,7 +674,14 @@ NOKPROBE_SYMBOL(do_debug_exception);
#ifdef CONFIG_ARM64_PAN
int cpu_enable_pan(void *__unused)
{
+ /*
+ * We modify PSTATE. This won't work from irq context as the PSTATE
+ * is discared once we return from the exception.
+ */
+ WARN_ON_ONCE(in_interrupt());
+
config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+ asm(SET_PSTATE_PAN(1));
return 0;
}
#endif /* CONFIG_ARM64_PAN */
--
2.8.0.rc3
^ permalink raw reply related
* [PATCH 3/3] arm64: suspend: Reconfigure PSTATE after resume from idle
From: James Morse @ 2016-10-18 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476786468-2173-1-git-send-email-james.morse@arm.com>
The suspend/resume path in kernel/sleep.S, as used by cpu-idle, does not
save/restore PSTATE. As a result of this cpufeatures that were detected
and have bits in PSTATE get lost when we resume from idle.
UAO gets set appropriately on the next context switch. PAN will be
re-enabled next time we return from user-space, but on a preemptible
kernel we may run work accessing user space before this point.
Add code to re-enable theses two features in __cpu_suspend_exit().
We re-use uao_thread_switch() passing current.
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
This patch applies to linux-stable v4.7.8, but with some fuzz...
but 'git am' rejects it.
asm/exec.h is my best guess at the appropriate header file. Contradictions
welcome.
arch/arm64/include/asm/exec.h | 3 +++
arch/arm64/kernel/process.c | 3 ++-
arch/arm64/kernel/suspend.c | 11 +++++++++++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/exec.h b/arch/arm64/include/asm/exec.h
index db0563c23482..f7865dd9d868 100644
--- a/arch/arm64/include/asm/exec.h
+++ b/arch/arm64/include/asm/exec.h
@@ -18,6 +18,9 @@
#ifndef __ASM_EXEC_H
#define __ASM_EXEC_H
+#include <linux/sched.h>
+
extern unsigned long arch_align_stack(unsigned long sp);
+void uao_thread_switch(struct task_struct *next);
#endif /* __ASM_EXEC_H */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 27b2f1387df4..4f186c56c5eb 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -49,6 +49,7 @@
#include <asm/alternative.h>
#include <asm/compat.h>
#include <asm/cacheflush.h>
+#include <asm/exec.h>
#include <asm/fpsimd.h>
#include <asm/mmu_context.h>
#include <asm/processor.h>
@@ -301,7 +302,7 @@ static void tls_thread_switch(struct task_struct *next)
}
/* Restore the UAO state depending on next's addr_limit */
-static void uao_thread_switch(struct task_struct *next)
+void uao_thread_switch(struct task_struct *next)
{
if (IS_ENABLED(CONFIG_ARM64_UAO)) {
if (task_thread_info(next)->addr_limit == KERNEL_DS)
diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index ad734142070d..bb0cd787a9d3 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -1,8 +1,11 @@
#include <linux/ftrace.h>
#include <linux/percpu.h>
#include <linux/slab.h>
+#include <asm/alternative.h>
#include <asm/cacheflush.h>
+#include <asm/cpufeature.h>
#include <asm/debug-monitors.h>
+#include <asm/exec.h>
#include <asm/pgtable.h>
#include <asm/memory.h>
#include <asm/mmu_context.h>
@@ -50,6 +53,14 @@ void notrace __cpu_suspend_exit(void)
set_my_cpu_offset(per_cpu_offset(cpu));
/*
+ * PSTATE was not saved over suspend/resume, re-enable any detected
+ * features that might not have been set correctly.
+ */
+ asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,
+ CONFIG_ARM64_PAN));
+ uao_thread_switch(current);
+
+ /*
* Restore HW breakpoint registers to sane values
* before debug exceptions are possibly reenabled
* through local_dbg_restore.
--
2.8.0.rc3
^ permalink raw reply related
* how to enable suspend to ram for arm-64 bits
From: Lorenzo Pieralisi @ 2016-10-18 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018100002.GA4347@xo-6d-61-c0.localdomain>
On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
> Hi!
>
> > >b. in arm64, if some platform has its own suspend flow, couldn't it
> > >adopts arm/match-xxx to register its own global suspend method?
> > >
> >
> > No, PSCI is highly recommended.
>
> Relying on firmware for suspend on x86 was a great disaster, lets not
> repeat that mistake. arm32 has better powermanagement than x86 ever
> will (see Nokia N900 for example) -- feel free to copy that code from
> arm32.
Yes sure, feel free to copy my:
NACKed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
to all the resulting patches then. On ARM64 if he wants to implement
suspend-to-RAM his PSCI firmware will have to implement PSCI system
suspend method, end of this discussion.
By the way, why are you advising people on this subject ?
What do you know about the PSCI firmware interface to state what
you are saying above ?
Lorenzo
^ permalink raw reply
* [PATCH] ARM: dts: realview: Extend PBX family memory description
From: Robin Murphy @ 2016-10-18 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018102550.GM1041@n2100.armlinux.org.uk>
On 18/10/16 11:25, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 10:21:13AM +0200, Linus Walleij wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> All three platforms sharing the later RealView Platform Baseboard memory
>> map - PBX-A9, PB-A8 and PB11MPCore, provide 512MB of DDR SDRAM on the
>> baseboard, of which the boot alias at 0x0 maps the first 256MB. Expand
>> the size of the default memory node to reflect that, and describe the
>> full memory regions in each board's DTS, but leave those commented by
>> default to avoid breaking existing bootloaders.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ARM SoC folks: I forgot to send this patch for ARM SoC earlier.
>> As it is a small change I suggest you just apply it to the ARM
>> SoC tree as I do not foresee any other RealView work in the near
>> future. If you think it can go into v4.9 then put it in as a fix,
>> else just push it to the next merge window.
>> Robin: sorry for screwing up :(
>
> Normally, memory nodes describe different regions of unique memory.
> This is not unique memory, but is an alias of some already-described
> memory.
Well, really, this is _the_ memory, and the 256MB at 0 is the alias, but
only the separate PB11MPCore DTS has the luxury of being correct from
the off, thanks to the precedent of the QEMU PB-A8 model being popular
and expecting to use the low alias.
> The problem with adding the aliased memory addresses is that we end
> up needing platform knowledge to reject the "other alias" from the
> memory description, which really isn't good.
>
> The only reason it works is that we reject memory nodes where the
> physical address < PHYS_OFFSET. That works provided the alias is
> below PHYS_OFFSET, but that isn't always the case.
Look again ;) It works perfectly because whilst the information is in
the DTS for completeness, as-is it's not in the DTB that the kernel
gets. And if someone _does_ adjust their kernel load address and
uncomment the .dts node accordingly, the "reg" property from the .dtsi
node gets overridden, not added to, so it's still fine.
Robin.
>
> So, I think it is completely wrong to describe the aliased memory
> regions in DT.
>
^ permalink raw reply
* [PATCH] ARM: dts: mps2: remove skeleton.dtsi include and fix unit address warnings
From: Vladimir Murzin @ 2016-10-18 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8b698799-6c7a-d20a-6e54-ddd9eb329369@arm.com>
On 17/10/16 17:51, Sudeep Holla wrote:
>
>
> On 17/10/16 12:47, Vladimir Murzin wrote:
>> Removale of skeleton.dtsi allows us also to fix the following
>> warning from the dts compiler:
>> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>>
>> by adding proper unit addresses to the memory nodes.
>>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
>
> It's always better to cc device-tree list, anyways applied this to [1].
Thanks!
Vladimir
>
> --
> Regards,
> Sudeep
>
> [1] git.kernel.org/sudeep.holla/linux/h/vexpress-dt/for-next
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Mark Rutland @ 2016-10-18 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018100002.GA4347@xo-6d-61-c0.localdomain>
On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
> > >b. in arm64, if some platform has its own suspend flow, couldn't it
> > >adopts arm/match-xxx to register its own global suspend method?
> >
> > No, PSCI is highly recommended.
>
> Relying on firmware for suspend on x86 was a great disaster, lets not repeat
> that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
> for example) -- feel free to copy that code from arm32.
Quite frankly, copying hundreds of lines of board-specific code
(including assembly that won't compile) is unlikely to help.
So far arm64 requires well-defined, standard, reusable interfaces (e.g.
PSCI). That cleanly separates concerns (e.g. anyone can implement the
backend without mandatory changes to the kernel), and keeps things
maintainable.
ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
can use and build atop of. It's open source (three-clause BSD with DCO),
and accepts board ports. You can have a completely open stack,
regardless of whether part of that stack is firmware.
Thanks,
Mark.
^ permalink raw reply
* [PATCH V2 3/4] ACPI,PCI,IRQ: separate ISA penalty calculation
From: Bjorn Helgaas @ 2016-10-18 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467188859-28188-4-git-send-email-okaya@codeaurora.org>
Hi Sinan,
On Wed, Jun 29, 2016 at 04:27:37AM -0400, Sinan Kaya wrote:
> Since commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> the penalty values are calculated on the fly rather than boot time.
>
> This works fine for PCI interrupts but not so well for the ISA interrupts.
> Whether an ISA interrupt is in use or not information is not available
> inside the pci_link.c file. This information gets sent externally via
> acpi_penalize_isa_irq function. If active is true, then the IRQ is in use
> by ISA. Otherwise, IRQ is in use by PCI.
>
> Since the current code relies on PCI Link object for determination of
> penalties, we are factoring in the PCI penalty twice after
> acpi_penalize_isa_irq function is called.
I know this patch has already been merged, but I'm confused.
Can you be a little more specific about how we factor in the PCI
penalty twice? I think that when we enumerate an enabled link device,
we call acpi_penalize_isa_irq(x) in this path:
pnpacpi_allocated_resource
pnpacpi_add_irqresource
pcibios_penalize_isa_irq
acpi_penalize_isa_irq
acpi_isa_irq_penalty[x] = PIRQ_PENALTY_ISA_USED
And I see that acpi_irq_penalty_init() also adds in some penalty
(either "PIRQ_PENALTY_PCI_POSSIBLE / possible_count" or
PIRQ_PENALTY_PCI_POSSIBLE). And when we call acpi_irq_get_penalty(x),
we add in PIRQ_PENALTY_PCI_USING.
It doesn't seem right to me that we're adding both
PIRQ_PENALTY_ISA_USED and PIRQ_PENALTY_PCI_USING. Is that the problem
you're referring to?
> This change is limiting the newly added functionality to just PCI
> interrupts so that old behavior is still maintained.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/pci_link.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 714ba4d..8c08971 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -496,9 +496,6 @@ static int acpi_irq_get_penalty(int irq)
> {
> int penalty = 0;
>
> - if (irq < ACPI_MAX_ISA_IRQS)
> - penalty += acpi_isa_irq_penalty[irq];
> -
> /*
> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> * with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> @@ -513,6 +510,9 @@ static int acpi_irq_get_penalty(int irq)
> penalty += PIRQ_PENALTY_PCI_USING;
> }
>
> + if (irq < ACPI_MAX_ISA_IRQS)
> + return penalty + acpi_isa_irq_penalty[irq];
> +
> penalty += acpi_irq_pci_sharing_penalty(irq);
> return penalty;
I don't understand what's going on here.
acpi_irq_pci_sharing_penalty(X) basically tells us how many link
devices are already using IRQ X. This change makes it so we don't
consider that information if X < ACPI_MAX_ISA_IRQS.
Let's say we have several link devices that are initially disabled,
e.g.,
LNKA (IRQs 9 10 11)
LNKB (IRQs 9 10 11)
LNKC (IRQs 9 10 11)
When we enable these, I think we'll choose the same IRQ for all of
them because we no longer look@the other links to see how they're
configured.
> }
> --
> 1.8.2.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [v12, 0/8] Fix eSDHC host version register bug
From: Ulf Hansson @ 2016-10-18 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu@nxp.com>
On 21 September 2016 at 08:57, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> This patchset is used to fix a host version register bug in the T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 10 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only available
> method left now. This v11 patchset introduces the soc_device_match interface in
> soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used to
> register a soc device which contain soc version and revision information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++++++
> drivers/clk/clk-qoriq.c | 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257 +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++----
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h | 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig
> create mode 100644 drivers/soc/fsl/guts.c
> rename arch/powerpc/include/asm/mpc85xx.h => include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
>
This looks good to me! I am not sure which tree you want this to be
picked up through, but unless no other volunteers I can take it
through my mmc tree.
Although, before considering to apply, I need an ack from Scott/Arnd
for the guts driver in patch 5/8 and I need an ack from Greg for patch
7/8, where the soc_device_match() interface is added (seems like you
didn't add him on cc/to).
Kind regards
Uffe
^ permalink raw reply
* [PATCH 0/5] ARM: add module autoloading support for crypto modules
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
This series wires up the crypto modules that use the ARM 32-bit versions of
the ARMv8 Crypto Extensions to udev autoloading, by exposing the HWCAP2
feature bits via the CPU modalias. This is very similar to the arm64
implementation, with the notable exception that ARM has its CPU feature
definitions split across HWCAP and HWCAP2.
Given that the crypto feature bits are all exposed via HWCAP2, and considering
that there are currently no features exposed via HWCAP that are relevant to
udev module autoloading, exposing HWCAP2 only should be sufficient, at least
for now.
Note to Herbert: patches #2 - #5 all depend on #1, which requires an ack from
Russell, so please don't pull anything until #1 has been acked and/or merged.
Ard Biesheuvel (5):
ARM: wire up HWCAP2 feature bits to the CPU modalias
crypto: arm/aes-ce - enable module autoloading based on CPU feature
bits
crypto: arm/ghash-ce - enable module autoloading based on CPU feature
bits
crypto: arm/sha1-ce - enable module autoloading based on CPU feature
bits
crypto: arm/sha2-ce - enable module autoloading based on CPU feature
bits
arch/arm/Kconfig | 1 +
arch/arm/crypto/aes-ce-glue.c | 5 ++-
arch/arm/crypto/ghash-ce-glue.c | 6 ++--
arch/arm/crypto/sha1-ce-glue.c | 5 ++-
arch/arm/crypto/sha2-ce-glue.c | 5 ++-
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
6 files changed, 41 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/include/asm/cpufeature.h
--
2.7.4
^ permalink raw reply
* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2016-10-18 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476787939-21889-1-git-send-email-ard.biesheuvel@linaro.org>
Wire up the generic support for exposing CPU feature bits via the
modalias in /sys/device/system/cpu. This allows udev to automatically
load modules for things like crypto algorithms that are implemented
using optional instructions.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/Kconfig | 1 +
arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..1a0c6a486a9c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -21,6 +21,7 @@ config ARM
select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+ select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
select GENERIC_IDLE_POLL_SETUP
select GENERIC_IRQ_PROBE
diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
new file mode 100644
index 000000000000..19c3dddd901a
--- /dev/null
+++ b/arch/arm/include/asm/cpufeature.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_CPUFEATURE_H
+#define __ASM_CPUFEATURE_H
+
+#include <asm/hwcap.h>
+
+/*
+ * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
+ * of optional CPU features it defines, ARM's CPU capability bits have been
+ * divided across separate elf_hwcap and elf_hwcap2 variables, each of which
+ * covers a subset of the available CPU features.
+ *
+ * Currently, only a few of those are suitable for automatic module loading
+ * (which is the primary use case of this facility) and those happen to be all
+ * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
+ */
+#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap2))
+#define cpu_feature(x) ilog2(HWCAP2_ ## x)
+
+static inline bool cpu_have_feature(unsigned int num)
+{
+ return elf_hwcap2 & (1UL << num);
+}
+
+#endif
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox