* [PATCH] ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP)
From: Arnaud Ebalard @ 2014-01-20 20:14 UTC (permalink / raw)
To: linux-arm-kernel
The following appears during compilation for an Armada 370 target
because 'irq_controller_lock' is used only when CONFIG_SMP is enabled:
drivers/irqchip/irq-armada-370-xp.c:62:8: warning: 'irq_controller_lock' defined but not used [-Wunused-variable]
Fix that warning by protecting declaration via an #ifdef.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
---
drivers/irqchip/irq-armada-370-xp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 433cc8568dec..499c5070f841 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -59,7 +59,9 @@
#define PCI_MSI_DOORBELL_END (32)
#define PCI_MSI_DOORBELL_MASK 0xFFFF0000
+#ifdef CONFIG_SMP
static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+#endif
static void __iomem *per_cpu_int_base;
static void __iomem *main_int_base;
--
1.8.5.2
^ permalink raw reply related
* [PATCH] ARM: pxa: Add dummy backlight power supply on Mitac Mio A701
From: Robert Jarzmik @ 2014-01-20 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87txd8vka8.fsf@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> Hi Arnd,
>
> I cannot reach Haojian, and my platform is currently screen-broken without
> Thierry's patch (see [1] and [2]). I'm trying to have it since -rc6, with no luck.
>
> Could you handle it in arm-soc fixes for -rc9 (if it happens) please ?
>
> Cheers.
>
> --
> Robert
OK, so my platform is broken in 3.13, so be it.
What now ? Do you have a backup for such cases ?
--
Robert
^ permalink raw reply
* [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early
From: Nishanth Menon @ 2014-01-20 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGa+x863_MQ22h+U=KtK++3aG2F_X4x57Xtfe16GYXKNiaWX4A@mail.gmail.com>
Move all OMAP4 PM errata initializations to centralized location in
omap4_pm_init_early. This allows for users to utilize the erratas
in various submodules as needed.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Reported by Tony here: https://patchwork.kernel.org/patch/3084521/
Reproduced with .config: http://slexy.org/view/s2EEdvTGXV on next-20140120 tag (based on omap2plus_defconfig)
Applies on v3.13 tag and on next-20140120
Tested to boot on next-20140120 along with https://patchwork.kernel.org/patch/3084521/
on PandaBoard-ES with multi_v7_defconfig: http://slexy.org/view/s27n0BWrPf
arch/arm/mach-omap2/common.h | 6 ++++++
arch/arm/mach-omap2/io.c | 1 +
arch/arm/mach-omap2/omap-smp.c | 6 +-----
arch/arm/mach-omap2/pm44xx.c | 15 +++++++++++++++
4 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 3adaa1d..a6aae30 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -62,11 +62,17 @@ static inline int omap3_pm_init(void)
#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
int omap4_pm_init(void);
+int omap4_pm_init_early(void);
#else
static inline int omap4_pm_init(void)
{
return 0;
}
+
+static inline int omap4_pm_init_early(void)
+{
+ return 0;
+}
#endif
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 47381fd..d408b15 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -641,6 +641,7 @@ void __init omap4430_init_early(void)
omap_cm_base_init();
omap4xxx_check_revision();
omap4xxx_check_features();
+ omap4_pm_init_early();
omap44xx_prm_init();
omap44xx_voltagedomains_init();
omap44xx_powerdomains_init();
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 75e95d4..17550aa 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -39,8 +39,6 @@
#define OMAP5_CORE_COUNT 0x2
-u16 pm44xx_errata;
-
/* SCU base address */
static void __iomem *scu_base;
@@ -217,10 +215,8 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
if (scu_base)
scu_enable(scu_base);
- if (cpu_is_omap446x()) {
+ if (cpu_is_omap446x())
startup_addr = omap4460_secondary_startup;
- pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
- }
/*
* Write the address of secondary startup routine into the
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 82f06989..eefb30c 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -24,6 +24,8 @@
#include "powerdomain.h"
#include "pm.h"
+u16 pm44xx_errata;
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -199,6 +201,19 @@ static inline int omap4_init_static_deps(void)
}
/**
+ * omap4_pm_init_early - Does early initialization necessary for OMAP4+ devices
+ *
+ * Initializes basic stuff for power management functionality.
+ */
+int __init omap4_pm_init_early(void)
+{
+ if (cpu_is_omap446x())
+ pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
+
+ return 0;
+}
+
+/**
* omap4_pm_init - Init routine for OMAP4+ devices
*
* Initializes all powerdomain and clockdomain target states
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] ARM: mvebu: DT boards for v3.14 (incr #6)
From: Jason Cooper @ 2014-01-20 20:01 UTC (permalink / raw)
To: linux-arm-kernel
All,
I had a few boards that came in late in the cycle. I was holding on to
them for the next round, but after Olof's comment this morning:
Re: [PATCH 0/2] DT updates for Hummingboard and new Cubox-i
http://www.spinics.net/lists/arm-kernel/msg301777.html
I figured I'd send them off. As usual, they've been in -next for a
while. Also, this is an incremental request from tags/mvebu-dt-3.14-5
to tags/mvebu-dt-3.14-6 on the mvebu/dt branch.
If this is going to be ok for the forseeable future, I'll do a separate
branch for new boards next time around.
thx,
Jason.
The following changes since commit 2cc64b5655da65bbb6a760a722b5ab1f53f92cf7:
ARM: Kirkwood: DT board setup for LaPlug (2013-12-25 02:03:52 +0000)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-3.14-6
for you to fetch changes up to 57d647cf8d32f52a505bc51c34f8074f06f00b03:
ARM: Kirkwood: Add DT description of QNAP 419 (2014-01-14 00:46:44 +0000)
----------------------------------------------------------------
mvebu DT changes for v3.14 (incremental #6)
- kirkwood
- add board Excito Bubba B3
- add board QNAP 419
----------------------------------------------------------------
Andrew Lunn (2):
ARM: Kirkwood: Add support for Excito Bubba B3
ARM: Kirkwood: Add DT description of QNAP 419
arch/arm/boot/dts/Makefile | 7 +-
arch/arm/boot/dts/kirkwood-b3.dts | 204 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/kirkwood-ts419-6281.dts | 20 +++
arch/arm/boot/dts/kirkwood-ts419-6282.dts | 32 +++++
arch/arm/boot/dts/kirkwood-ts419.dtsi | 75 +++++++++++
5 files changed, 336 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/kirkwood-b3.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6281.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ts419-6282.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ts419.dtsi
^ permalink raw reply
* [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions
From: Nicolas Pitre @ 2014-01-20 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8G+oSFWhVxbjPuj+Vn8Tk9E-g6og-fFjGdKsbmheHz-A@mail.gmail.com>
On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> On 20 January 2014 19:55, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> >
> >> On 20 January 2014 19:17, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> > On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> >> >> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
> >> >> whole value, not just the bits whose meaning was known to glibc at the
> >> >> time.
> >> >> So if desired, a program can interpret AT_HWCAP itself.
> >> >>
> >> >> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
> >> >> getauxval() on an older libc.
> >> >
> >> > I agree. And I don't dispute the bit placement choice either.
> >> >
> >> > Still, an old glibc calling getauxval(AT_HWCAP) should already be
> >> > prepared to receive and rightfully ignore those bits it didn't know the
> >> > meaning of at the time. So "preserving some future extensions in HWCAP
> >> > for older glibc" as a justification makes little sense to me... unless
> >> > I'm missing something?
> >> >
> >> > Even if applications interpret those bits themselves, supposing they
> >> > still need to be linked against an old glibc, then why would
> >> > yet-to-be-defined future extensions be more important to be signaled
> >> > using the lower 32 bits than the extensions you propose? That is what I
> >> > don't get.
> >> >
> >>
> >> In the general case, you are quite right.
> >>
> >> In this particular case, the extensions for which I am adding the
> >> feature bits are not supported on any hardware currently known or
> >> supported by the ARM port. At this time, the only known CPUs
> >> supporting these extensions are ARMv8 CPUs executing in 32-bit
> >> compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
> >> execution state using previously unallocated opcodes)
> >
> > So?
> >
> >> So the only reason (currently) for adding these feature bits to the
> >> ARM port is to align with the ARMv8 32-bit compat mode so that a
> >> 32-bit userland requires no knowledge about whether its 32-bit
> >> execution environment is hosted by an ARM or an arm64 kernel. In the
> >> future, ARMv8 32-bit only CPUs may well turn up that support these
> >> extensions as well.
> >
> > I agree with all you've said so far. But that doesn't answer my
> > question.
> >
> > And my unanswered question isn't that important either.
> >
>
> Quoting Russell:
>
> On 18 December 2013 12:42, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > The point is that they'll never appear on an ARMv7 implementation because
> > they're not part of the ARMv7 architecture. I see no point in needlessly
> > polluting ARM32 with ARM64 stuff - in exactly the same way that you see
> > no point in polluting ARM64 with ARM32 stuff.
> >
> > So, frankly, find a different way to this. We don't need to needlessly
> > waste HWCAP bits on ARM32.
>
> So my idea was to use HWCAP2 bits instead ...
The introduction of HWCAP2 on ARM32 could be seen as ARM64 pollution
just as well.
But someone connected with ARM Ltd said that 32-bit-only ARMv8
implementations are likely to show up. Therefore Russell's argument
can't hold as ARM32 support won't stop with ARMv7.
Still, Russell also remarked that the bits you added took a significant
portion of the remaining HWCAP bits, which you fixed by adding HWCAP2 to
ARM32.
So far so good.
You also decided to put the new crypto bits into HWCAP2. I have no
actual objection with that either.
What makes me wonder is Catalin's affirmation about putting those new
bits into HWCAP2 making future extensions possible with old glibc
versions that don't have knowledge about HWCAP2. That is what I don't
get the pertinence of.
Nicolas
^ permalink raw reply
* [PATCH -next] mtd: nuc900_nand: remove redundant return value check of platform_get_resource()
From: Brian Norris @ 2014-01-20 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001401cf0c04$691d63d0$3b582b70$%han@samsung.com>
On Wed, Jan 08, 2014 at 08:58:49AM +0900, Jingoo Han wrote:
> On Tuesday, January 07, 2014 10:39 PM, Wei Yongjun wrote:
> >
> > From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> >
> > Remove unneeded error handling on the result of a call
> > to platform_get_resource() when the value is passed to
> > devm_ioremap_resource().
> >
> > Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Pushed to l2-mtd.git. Thanks!
Brian
^ permalink raw reply
* [PATCH v4 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
From: Sherman Yin @ 2014-01-20 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYAANtY=9QtDnYNZLSrF09nTWUH4nK5oJ7mzznS+_=bHA@mail.gmail.com>
On 14-01-20 12:16 AM, Linus Walleij wrote:
> On Sat, Jan 18, 2014 at 3:56 AM, Matt Porter <mporter@linaro.org> wrote:
>
>> I wonder if Linus would accept a rename at this point (too late for 3.14
>> presumably, but for 3.15) of s/capri/bcm281xx throughout, bcm11351 for
>> the compatible string, as we have for the machine compatible, and also
>> BCM281XX for the Kconfig option.
>
> Yes, if there is some consensus that this is what we want to do.
>
> I can certainly merge that during the 3.14-rc phase for that matter.
Hi Linus,
I'll confirm the new name with Matt before sending out another patch.
Which would work better for you - a) a set of patches replacing my
previous ones, b) a set of patches on top of my previous ones, c) a
single patch on top of my previous ones? d) something else?
Thanks,
Sherman
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Olof Johansson @ 2014-01-20 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5A=tdzq8SW7P-D_Lxd6Ptjqkk+bKn29T2ggOZar=r4X+A@mail.gmail.com>
On Mon, Jan 20, 2014 at 11:14 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Jan 20, 2014 at 1:56 AM, Olof Johansson <olof@lixom.net> wrote:
>
>> +Card power and reset control:
>> +The following properties can be specified for cases where the MMC
>> +peripheral needs additional reset, regulator and clock lines. It is for
>> +example common for WiFi/BT adapters to have these separate from the main
>> +MMC bus:
>> + - card-reset-gpios: Specify GPIOs for card reset (reset active low)
>
> Wouldn't it be better not to assume that the card reset is always
> active low and read the GPIO_ACTIVE_xxx flags instead?
That's actually what the code does, I need to update the text. Thanks
for spotting it.
-Olof
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Fabio Estevam @ 2014-01-20 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390190215-22700-2-git-send-email-olof@lixom.net>
On Mon, Jan 20, 2014 at 1:56 AM, Olof Johansson <olof@lixom.net> wrote:
> +Card power and reset control:
> +The following properties can be specified for cases where the MMC
> +peripheral needs additional reset, regulator and clock lines. It is for
> +example common for WiFi/BT adapters to have these separate from the main
> +MMC bus:
> + - card-reset-gpios: Specify GPIOs for card reset (reset active low)
Wouldn't it be better not to assume that the card reset is always
active low and read the GPIO_ACTIVE_xxx flags instead?
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Olof Johansson @ 2014-01-20 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFoywt_LcWXdWJCWMU8-GT2vLW27eiuF0WEyjHJV+96HpA@mail.gmail.com>
On Mon, Jan 20, 2014 at 09:44:23AM +0100, Ulf Hansson wrote:
> On 20 January 2014 04:56, Olof Johansson <olof@lixom.net> wrote:
> > This patch enables support for power-on sequencing of SDIO peripherals through DT.
> >
> > In general, it's quite common that wifi modules and other similar
> > peripherals have several signals in addition to the SDIO interface that
> > needs wiggling before the module will power on. It's common to have a
> > reference clock, one or several power rails and one or several lines
> > for reset/enable type functions.
> >
> > The binding as written today introduces a number of reset gpios,
> > a regulator and a clock specifier. The code will handle up to 2 gpio
> > reset lines, but it's trivial to increase to more than that if needed
> > at some point.
> >
> > Implementation-wise, the MMC core has been changed to handle this during
> > host power up, before the host interface is powered on. I have not yet
> > implemented the power-down side, I wanted people to have a chance for
> > reporting back w.r.t. issues (or comments on the bindings) first.
> >
> > I have not tested the regulator portion, since the system and module
> > I'm working on doesn't need one (Samsung Chromebook with Marvell
> > 8797-based wifi). Testing of those portions (and reporting back) would
> > be appreciated.
> >
> > Signed-off-by: Olof Johansson <olof@lixom.net>
> > ---
> > Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++
> > drivers/mmc/core/core.c | 42 +++++++++++++++++++++++++
> > drivers/mmc/core/host.c | 30 +++++++++++++++++-
> > include/linux/mmc/host.h | 5 +++
> > 4 files changed, 87 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
> > index 458b57f..962e0ee 100644
> > --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> > @@ -5,6 +5,8 @@ these definitions.
> > Interpreted by the OF core:
> > - reg: Registers location and length.
> > - interrupts: Interrupts used by the MMC controller.
> > +- clocks: Clocks needed for the host controller, if any.
> > +- clock-names: Goes with clocks above.
> >
> > Card detection:
> > If no property below is supplied, host native card detect is used.
> > @@ -30,6 +32,15 @@ Optional properties:
> > - cap-sdio-irq: enable SDIO IRQ signalling on this interface
> > - full-pwr-cycle: full power cycle of the card is supported
> >
> > +Card power and reset control:
> > +The following properties can be specified for cases where the MMC
> > +peripheral needs additional reset, regulator and clock lines. It is for
> > +example common for WiFi/BT adapters to have these separate from the main
> > +MMC bus:
> > + - card-reset-gpios: Specify GPIOs for card reset (reset active low)
> > + - card-external-vcc-supply: Regulator to drive (independent) card VCC
> > + - clock with name "card_ext_clock": External clock provided to the card
> > +
> > *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
> > polarity properties, we have to fix the meaning of the "normal" and "inverted"
> > line levels. We choose to follow the SDHCI standard, which specifies both those
> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> > index 098374b..c43e6c8 100644
> > --- a/drivers/mmc/core/core.c
> > +++ b/drivers/mmc/core/core.c
> > @@ -13,11 +13,13 @@
> > #include <linux/module.h>
> > #include <linux/init.h>
> > #include <linux/interrupt.h>
> > +#include <linux/clk.h>
> > #include <linux/completion.h>
> > #include <linux/device.h>
> > #include <linux/delay.h>
> > #include <linux/pagemap.h>
> > #include <linux/err.h>
> > +#include <linux/gpio.h>
> > #include <linux/leds.h>
> > #include <linux/scatterlist.h>
> > #include <linux/log2.h>
> > @@ -1519,6 +1521,43 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned int drv_type)
> > mmc_host_clk_release(host);
> > }
> >
> > +static void mmc_card_power_up(struct mmc_host *host)
> > +{
> > + int i;
> > + struct gpio_desc **gds = host->card_reset_gpios;
> > +
> > + for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
> > + if (gds[i]) {
> > + dev_dbg(host->parent, "Asserting reset line %d", i);
> > + gpiod_set_value(gds[i], 1);
> > + }
> > + }
> > +
> > + if (host->card_regulator) {
> > + dev_dbg(host->parent, "Enabling external regulator");
> > + if (regulator_enable(host->card_regulator))
> > + dev_err(host->parent, "Failed to enable external regulator");
> > + }
> > +
> > + if (host->card_clk) {
> > + dev_dbg(host->parent, "Enabling external clock");
> > + clk_prepare_enable(host->card_clk);
> > + }
> > +
> > + /* 2ms delay to let clocks and power settle */
> > + mmc_delay(20);
> > +
> > + for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
> > + if (gds[i]) {
> > + dev_dbg(host->parent, "Deasserting reset line %d", i);
> > + gpiod_set_value(gds[i], 0);
> > + }
> > + }
> > +
> > + /* 2ms delay to after reset release */
> > + mmc_delay(20);
> > +}
> > +
> > /*
> > * Apply power to the MMC stack. This is a two-stage process.
> > * First, we enable power to the card without the clock running.
> > @@ -1535,6 +1574,9 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
> > if (host->ios.power_mode == MMC_POWER_ON)
> > return;
> >
> > + /* Power up the card/module first, if needed */
> > + mmc_card_power_up(host);
> > +
> > mmc_host_clk_hold(host);
> >
> > host->ios.vdd = fls(ocr) - 1;
> > diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> > index 49bc403..e6b850b 100644
> > --- a/drivers/mmc/core/host.c
> > +++ b/drivers/mmc/core/host.c
> > @@ -12,14 +12,18 @@
> > * MMC host class device management
> > */
> >
> > +#include <linux/kernel.h>
> > +#include <linux/clk.h>
> > #include <linux/device.h>
> > #include <linux/err.h>
> > +#include <linux/gpio/consumer.h>
> > #include <linux/idr.h>
> > #include <linux/of.h>
> > #include <linux/of_gpio.h>
> > #include <linux/pagemap.h>
> > #include <linux/export.h>
> > #include <linux/leds.h>
> > +#include <linux/regulator/consumer.h>
> > #include <linux/slab.h>
> > #include <linux/suspend.h>
> >
> > @@ -312,7 +316,7 @@ int mmc_of_parse(struct mmc_host *host)
> > u32 bus_width;
> > bool explicit_inv_wp, gpio_inv_wp = false;
> > enum of_gpio_flags flags;
> > - int len, ret, gpio;
> > + int i, len, ret, gpio;
> >
> > if (!host->parent || !host->parent->of_node)
> > return 0;
> > @@ -415,6 +419,30 @@ int mmc_of_parse(struct mmc_host *host)
> > if (explicit_inv_wp ^ gpio_inv_wp)
> > host->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
> >
> > + /* Parse card power/reset/clock control */
>
> I would like us to prevent to open up for confusion with the "eMMC hw
> reset" when adding this. Unless we are able to combine them in some
> way?
>
> Could we maybe add some more comments about in what scenarios this DT
> property would be useful?
Ok, can do. How about something like:
/*
* Some cards need separate power/reset/clock control from the main
* MMC/SDIO bus. Parse the description of those controls so we can
* power on the card before the host controller.
*/
> > + if (of_find_property(np, "card-reset-gpios", NULL)) {
> > + struct gpio_desc *gpd;
> > + for (i = 0; i < ARRAY_SIZE(host->card_reset_gpios); i++) {
> > + gpd = devm_gpiod_get_index(host->parent, "card-reset", i);
> > + if (IS_ERR(gpd))
> > + break;
> > + gpiod_direction_output(gpd, 0);
> > + host->card_reset_gpios[i] = gpd;
> > + }
> > +
> > + gpd = devm_gpiod_get_index(host->parent, "card-reset", ARRAY_SIZE(host->card_reset_gpios));
> > + if (!IS_ERR(gpd)) {
> > + dev_warn(host->parent, "More reset gpios than we can handle");
> > + gpiod_put(gpd);
> > + }
> > + }
> > +
> > + host->card_clk = of_clk_get_by_name(np, "card_ext_clock");
>
> of_clk_get_by_name relies on COMMON_CLK, is that really what you want here?
>
> > + if (IS_ERR(host->card_clk))
> > + host->card_clk = NULL;
> > +
> > + host->card_regulator = regulator_get(host->parent, "card-external-vcc");
>
> Is the above regulator related to host->ocr_avail mask? Could the
> above regulator be replaced by vmmc?
I have to admit that I don't know MMC as well as I could, but OCR seems to be
something that's between the driver/controller/device, not related to external
power control in this case?
> At the moment host drivers uses mmc_regulator_get_supply(), which
> fetches regulators called "vmmc" and "vqmmc". It is also common to
> have these defined in DT like "vmmc-supply". This has not been
> properly documented for most host cases, and we should fix that. I
> also think it would make sense to include these in the documentation
> for the common mmc bindings, instead of host specific bindings.
Hm, I had been of the impression that the vmmc stuff is to control
power/voltage on the signal lines, not for external card power. Still, even in
that case there's need for the reset line handling and clock control.
I'll take a look and see if there's a way to handle that in a properly
sequenced way and still use the same regulator.
-Olof
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Arnd Bergmann @ 2014-01-20 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgMnvFAFiO_K4U5n08Tj+ZPWh656D=vgaQOyYbVCyvSDg@mail.gmail.com>
On Monday 20 January 2014 11:04:26 Olof Johansson wrote:
>
> I'd expect most usage of this to be through gpios, since we're talking
> about external independent modules here. I would prefer not to bring
> in the reset controller stuff here -- it just adds another layer of
> abstraction that seems unnecessary.
>
> I would prefer if the reset framework was contained to only be the
> on-chip SoC IP block resets, etc, as originally intended.
Ok, fair enough.
Arnd
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Olof Johansson @ 2014-01-20 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401201958.57997.arnd@arndb.de>
On Mon, Jan 20, 2014 at 10:58 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 20 January 2014, Olof Johansson wrote:
>>
>> +Card power and reset control:
>> +The following properties can be specified for cases where the MMC
>> +peripheral needs additional reset, regulator and clock lines. It is for
>> +example common for WiFi/BT adapters to have these separate from the main
>> +MMC bus:
>> + - card-reset-gpios: Specify GPIOs for card reset (reset active low)
>> + - card-external-vcc-supply: Regulator to drive (independent) card VCC
>> + - clock with name "card_ext_clock": External clock provided to the card
>
> I wonder whether the reset line should use the generic reset controller binding
> rather than the gpio binding. There has been a recent discussion about a
> gpio-reset driver, which should generalize this at the reset level, and
> it would make it possible to use reset controllers that are not gpio driven.
> In general, any gpio can be used as a reset, but not every reset line can
> be a gpio. I don't know whether anyone would use an internal reset-controller
> for an external SDIO chip though, so maybe your approach is sufficient.
I'd expect most usage of this to be through gpios, since we're talking
about external independent modules here. I would prefer not to bring
in the reset controller stuff here -- it just adds another layer of
abstraction that seems unnecessary.
I would prefer if the reset framework was contained to only be the
on-chip SoC IP block resets, etc, as originally intended.
-Olof
^ permalink raw reply
* [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions
From: Ard Biesheuvel @ 2014-01-20 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401201351120.1652@knanqh.ubzr>
On 20 January 2014 19:55, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
>
>> On 20 January 2014 19:17, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
>> >> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
>> >> whole value, not just the bits whose meaning was known to glibc at the
>> >> time.
>> >> So if desired, a program can interpret AT_HWCAP itself.
>> >>
>> >> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
>> >> getauxval() on an older libc.
>> >
>> > I agree. And I don't dispute the bit placement choice either.
>> >
>> > Still, an old glibc calling getauxval(AT_HWCAP) should already be
>> > prepared to receive and rightfully ignore those bits it didn't know the
>> > meaning of at the time. So "preserving some future extensions in HWCAP
>> > for older glibc" as a justification makes little sense to me... unless
>> > I'm missing something?
>> >
>> > Even if applications interpret those bits themselves, supposing they
>> > still need to be linked against an old glibc, then why would
>> > yet-to-be-defined future extensions be more important to be signaled
>> > using the lower 32 bits than the extensions you propose? That is what I
>> > don't get.
>> >
>>
>> In the general case, you are quite right.
>>
>> In this particular case, the extensions for which I am adding the
>> feature bits are not supported on any hardware currently known or
>> supported by the ARM port. At this time, the only known CPUs
>> supporting these extensions are ARMv8 CPUs executing in 32-bit
>> compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
>> execution state using previously unallocated opcodes)
>
> So?
>
>> So the only reason (currently) for adding these feature bits to the
>> ARM port is to align with the ARMv8 32-bit compat mode so that a
>> 32-bit userland requires no knowledge about whether its 32-bit
>> execution environment is hosted by an ARM or an arm64 kernel. In the
>> future, ARMv8 32-bit only CPUs may well turn up that support these
>> extensions as well.
>
> I agree with all you've said so far. But that doesn't answer my
> question.
>
> And my unanswered question isn't that important either.
>
Quoting Russell:
On 18 December 2013 12:42, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> The point is that they'll never appear on an ARMv7 implementation because
> they're not part of the ARMv7 architecture. I see no point in needlessly
> polluting ARM32 with ARM64 stuff - in exactly the same way that you see
> no point in polluting ARM64 with ARM32 stuff.
>
> So, frankly, find a different way to this. We don't need to needlessly
> waste HWCAP bits on ARM32.
So my idea was to use HWCAP2 bits instead ...
--
Ard.
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Arnd Bergmann @ 2014-01-20 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390190215-22700-2-git-send-email-olof@lixom.net>
On Monday 20 January 2014, Olof Johansson wrote:
>
> +Card power and reset control:
> +The following properties can be specified for cases where the MMC
> +peripheral needs additional reset, regulator and clock lines. It is for
> +example common for WiFi/BT adapters to have these separate from the main
> +MMC bus:
> + - card-reset-gpios: Specify GPIOs for card reset (reset active low)
> + - card-external-vcc-supply: Regulator to drive (independent) card VCC
> + - clock with name "card_ext_clock": External clock provided to the card
I wonder whether the reset line should use the generic reset controller binding
rather than the gpio binding. There has been a recent discussion about a
gpio-reset driver, which should generalize this at the reset level, and
it would make it possible to use reset controllers that are not gpio driven.
In general, any gpio can be used as a reset, but not every reset line can
be a gpio. I don't know whether anyone would use an internal reset-controller
for an external SDIO chip though, so maybe your approach is sufficient.
Arnd
^ permalink raw reply
* [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions
From: Nicolas Pitre @ 2014-01-20 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8JEaVZDiOEegUeYfWbAMMH0ddgcWaTjFBpjXzoiKRoQg@mail.gmail.com>
On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> On 20 January 2014 19:17, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> >> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
> >> whole value, not just the bits whose meaning was known to glibc at the
> >> time.
> >> So if desired, a program can interpret AT_HWCAP itself.
> >>
> >> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
> >> getauxval() on an older libc.
> >
> > I agree. And I don't dispute the bit placement choice either.
> >
> > Still, an old glibc calling getauxval(AT_HWCAP) should already be
> > prepared to receive and rightfully ignore those bits it didn't know the
> > meaning of at the time. So "preserving some future extensions in HWCAP
> > for older glibc" as a justification makes little sense to me... unless
> > I'm missing something?
> >
> > Even if applications interpret those bits themselves, supposing they
> > still need to be linked against an old glibc, then why would
> > yet-to-be-defined future extensions be more important to be signaled
> > using the lower 32 bits than the extensions you propose? That is what I
> > don't get.
> >
>
> In the general case, you are quite right.
>
> In this particular case, the extensions for which I am adding the
> feature bits are not supported on any hardware currently known or
> supported by the ARM port. At this time, the only known CPUs
> supporting these extensions are ARMv8 CPUs executing in 32-bit
> compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
> execution state using previously unallocated opcodes)
So?
> So the only reason (currently) for adding these feature bits to the
> ARM port is to align with the ARMv8 32-bit compat mode so that a
> 32-bit userland requires no knowledge about whether its 32-bit
> execution environment is hosted by an ARM or an arm64 kernel. In the
> future, ARMv8 32-bit only CPUs may well turn up that support these
> extensions as well.
I agree with all you've said so far. But that doesn't answer my
question.
And my unanswered question isn't that important either.
Nicolas
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Fabio Estevam @ 2014-01-20 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120171621.GG15937@n2100.arm.linux.org.uk>
On Mon, Jan 20, 2014 at 3:16 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Not as far as I can see. fixed-clock appears to have two properies:
>
> clock-frequency
> clock-output-names
>
> and nothing else. See of_fixed_clk_setup in drivers/clk/clk-fixed-rate.c.
> You'll also find that the documentation in this file says this about it:
Looks like Documentation/devicetree/bindings/clock/fixed-clock.txt is
misleading then:
"Optional properties:
- gpios : From common gpio binding; gpio connection to clock enable pin."
Regards,
Fabio Estevam
^ permalink raw reply
* Deadlock in do_page_fault() on ARM (old kernel)
From: Michal Hocko @ 2014-01-20 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120101509.GA2626@dhcp22.suse.cz>
On Mon 20-01-14 11:15:09, Michal Hocko wrote:
> On Wed 15-01-14 20:13:04, Alan Ott wrote:
> [...]
> > 2. __copy_to_user_memcpy() takes a read lock (down_read()) on
>
> This looks like a bug. copy_to_user_* shouldn't take mmap_sem at all
> Check the might_fault annotation used in generic code. Arm version of
> copy_to_user* doesn't seem to use the annotation and I do not see a good
> reason for that.
OK, so I have looked at the implementation of __copy_to_user_memcpy and
it drops the semaphore before it does __put_user to fault memory in. It
then reacquires the lock to make sure that the pte doesn't vanish during
memcpy. It holds pte lock to ensure that.
The mmap_sem reacquire happens with pte lock held though and this smells
like a deadlock situation because the page fault takes mmap_sem first
and only then takes ptl. I am not sure this is exactly what happens in
your case though because you seem to have tasks blocked on the mmap_sem
already.
> > mm->mmap_sem. While that lock is held, __copy_to_user_memcpy() can
> > generate a page fault, causing do_page_fault() to get called, which
> > will also try to get a read lock (down_read()) on mm->mmap_sem.
> > Multiple read locks can be taken on an rw_semaphore, but deadlock
> > will occur if another thread tries to get a write lock
> > (down_write()) in between. For example:
> > Task 1: Task 2:
> > down_read(sem)
> > down_write(sem) <-- Goes to sleep
> > down_read(sem) <-- Goes to sleep
> >
> > There is a thread from 2005[3] which seems to discuss the same
> > concept of recursive rw_semaphores, but for futexes.
> >
> > Other comments:
> > 1. My analysis of this probably wrong. Otherwise it seems many
> > others would have the same problem, and they don't seem to. I'm
> > hoping this email will help to correct my understanding.
> > 2. I looked through the git logs for recent (since 2.6.37 time
> > frame) and nothing else jumped out at me as being an obvious fix for
> > this situation.
> >
> > Thanks for any insight you can give,
> >
> > Alan.
> >
> > [1] http://www.signal11.us/~alan/show-all-tasks-deadlock.txt
> >
> > [2] Some websites/bugtrackers mention this commit with a similar
> > issue, but I'm not entirely sure how it's related:
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8878a539ff19a43cf3729e7562cd528f490246ae
> >
> > This one seems obviously related, but has no effect on my system:
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=435a7ef52db7d86e67a009b36cac1457f8972391
> >
> > [3] http://thread.gmane.org/gmane.linux.kernel/280900
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Michal Hocko
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v4 1/1] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Brian Norris @ 2014-01-20 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389346564-24243-1-git-send-email-nsekhar@ti.com>
Hi Sekhar,
Sorry, I do have one complaint about this patch.
On Fri, Jan 10, 2014 at 03:06:04PM +0530, Sekhar Nori wrote:
> --- a/arch/arm/mach-davinci/aemif.c
> +++ b/arch/arm/mach-davinci/aemif.c
> @@ -130,4 +136,82 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
>
> return 0;
> }
> -EXPORT_SYMBOL(davinci_aemif_setup_timing);
> +
> +/**
> + * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
> + * @pdev - link to platform device to setup settings for
> + *
> + * This function does not use any locking while programming the AEMIF
> + * because it is expected that there is only one user of a given
> + * chip-select.
> + *
> + * Returns 0 on success, else negative errno.
> + */
> +int davinci_aemif_setup(struct platform_device *pdev)
> +{
> + struct davinci_nand_pdata *pdata = dev_get_platdata(&pdev->dev);
> + uint32_t val;
> + unsigned long clkrate;
> + struct resource *res;
> + void __iomem *base;
> + struct clk *clk;
> + int ret = 0;
> +
> + clk = clk_get(&pdev->dev, "aemif");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + dev_dbg(&pdev->dev, "unable to get AEMIF clock, err %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + dev_dbg(&pdev->dev, "unable to enable AEMIF clock, err %d\n",
> + ret);
> + return ret;
coccinelle gives a warning for this:
arch/arm/mach-davinci/aemif.c:171:2-8: ERROR: missing clk_put; clk_get on line 160 and execution via conditional on line 168 [coccinelle]
You need a clk_put() on the error path for clk_prepare_enable. For
instance, you can add a label below and replace this 'return ret' with
'goto err_put'.
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res) {
> + dev_err(&pdev->dev, "cannot get IORESOURCE_MEM\n");
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + base = ioremap(res->start, resource_size(res));
> + if (!base) {
> + dev_err(&pdev->dev, "ioremap failed for resource %pR\n", res);
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + /*
> + * Setup Async configuration register in case we did not boot
> + * from NAND and so bootloader did not bother to set it up.
> + */
> + val = davinci_aemif_readl(base, A1CR_OFFSET + pdev->id * 4);
> + /*
> + * Extended Wait is not valid and Select Strobe mode is not
> + * used
> + */
> + val &= ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
> + if (pdata->options & NAND_BUSWIDTH_16)
> + val |= 0x1;
> +
> + davinci_aemif_writel(base, A1CR_OFFSET + pdev->id * 4, val);
> +
> + clkrate = clk_get_rate(clk);
> +
> + if (pdata->timing)
> + ret = davinci_aemif_setup_timing(pdata->timing, base, pdev->id,
> + clkrate);
> +
> + if (ret < 0)
> + dev_dbg(&pdev->dev, "NAND timing values setup fail\n");
> +
> + iounmap(base);
> +err:
> + clk_disable_unprepare(clk);
Then the label could be here:
err_put:
> + clk_put(clk);
> + return ret;
> +}
Brian
^ permalink raw reply
* [PATCH] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Arnd Bergmann @ 2014-01-20 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+mB=1+mrWAzBCxdMEji2MDRzHajmnxuWtz7iu96ML0DuAB3RQ@mail.gmail.com>
On Monday 20 January 2014, Srikanth Thokala wrote:
> >
> >> > * data width should be a property of the slave driver that is configured
> >> > through dma_slave_config(), unless you can have dma engines that only
> >> > support certain a width.
> >>
> >> Yes, this VDMA engine soft IP support only certain widths, which is
> >> configurable during IP synthesis.
> >
> > But what is this property used for in that case? Surely you can't
> > connect a slave device to a dmaengine if the bus width doesn't match.
> > You probably have a point here, but I don't understand it yet.
>
> There is a Data-Realignment Engine (DRE) in the IP which is only available for
> data width setting of 64-bits and less. So, we use the data-width DT parameter
> to verify this condition and we update alignment shift accordingly.
Ok, I have to admit I didn't understand all of that, but you clearly
know what you are talking about here, so I assume you are correct.
Arnd
^ permalink raw reply
* [PATCH 06/20] ARM64 / ACPI: Introduce some PCI functions when PCI is enabled
From: Arnd Bergmann @ 2014-01-20 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD2F23.2010109@linaro.org>
On Monday 20 January 2014, Hanjun Guo wrote:
> >> acpi_register_ioapic()/acpi_unregister_ioapic() will be used for IOAPIC
> >> hotplug and GIC distributor is something like IOAPIC on x86, so I think
> >> these two functions can be reserved for future use.
> > But GIC is not hotplugged, is it? It still sounds x86 specific to me.
>
> Well, if we want to do physical CPU hotplug on ARM/ARM64 (maybe years
> later?),
> then GIC add/remove is needed because we have to remove GIC
> on the SoC too when we remove the physical CPU.
In general, I recommend not planning for the future in kernel code when you
don't know what is going to happen. It's always easy enough to change
things once you get there, as long as no stable ABI is involved.
I just looked at the caller of these functions, and found a self-contained
PCI driver in drivers/pci/ioapic.c, which uses two sepate PCI classes for
ioapic and ioxapic. I think it's a safe assumption to say that even if we
get ARM CPU+GIC hotplug, that would not use the same ioapic driver. This
driver is currently marked X86-only, and that should probably stay this way,
so you won't need the hooks.
Arnd
^ permalink raw reply
* [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions
From: Ard Biesheuvel @ 2014-01-20 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401201307300.1652@knanqh.ubzr>
On 20 January 2014 19:17, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
>
>> On 20 January 2014 18:44, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > On Mon, 20 Jan 2014, Catalin Marinas wrote:
>> >
>> >> On Mon, Dec 23, 2013 at 02:06:27PM +0000, Ard Biesheuvel wrote:
>> >> > This series is a followup to the patch that was recently merged by Catalin that
>> >> > allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
>> >> > discover whether the current CPU has any of those capabilities.
>> >> >
>> >> > Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
>> >> > was recently added to the kernel and glibc (2.18). It extends the feature bit
>> >> > space to 64 bits (on 32-bit architectures)
>> >> >
>> >> > Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
>> >> > mode for 64-bit architectures.
>> >> >
>> >> > Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
>> >> >
>> >> > Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
>> >> > because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
>> >> > so there should be agreement about the meaning of feature bits, even if the ARM
>> >> > kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R).
>> >>
>> >> It looks a bit strange to start filling HWCAP2 before HWCAP is full but
>> >> I guess we want to preserve some future extensions in HWCAP for older
>> >> glibc.
>> >
>> > How could older glibc possibly care about future extensions?
>> >
>>
>> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
>> whole value, not just the bits whose meaning was known to glibc at the
>> time.
>> So if desired, a program can interpret AT_HWCAP itself.
>>
>> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
>> getauxval() on an older libc.
>
> I agree. And I don't dispute the bit placement choice either.
>
> Still, an old glibc calling getauxval(AT_HWCAP) should already be
> prepared to receive and rightfully ignore those bits it didn't know the
> meaning of at the time. So "preserving some future extensions in HWCAP
> for older glibc" as a justification makes little sense to me... unless
> I'm missing something?
>
> Even if applications interpret those bits themselves, supposing they
> still need to be linked against an old glibc, then why would
> yet-to-be-defined future extensions be more important to be signaled
> using the lower 32 bits than the extensions you propose? That is what I
> don't get.
>
In the general case, you are quite right.
In this particular case, the extensions for which I am adding the
feature bits are not supported on any hardware currently known or
supported by the ARM port. At this time, the only known CPUs
supporting these extensions are ARMv8 CPUs executing in 32-bit
compatibility mode (i.e., ARMv8 defines instructions for the 32-bit
execution state using previously unallocated opcodes)
So the only reason (currently) for adding these feature bits to the
ARM port is to align with the ARMv8 32-bit compat mode so that a
32-bit userland requires no knowledge about whether its 32-bit
execution environment is hosted by an ARM or an arm64 kernel. In the
future, ARMv8 32-bit only CPUs may well turn up that support these
extensions as well.
--
Ard.
^ permalink raw reply
* [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions
From: Nicolas Pitre @ 2014-01-20 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8jqctGFsyccg6_VGkZ6ogf8BD_kq1rsRQrc+cw7pk+qA@mail.gmail.com>
On Mon, 20 Jan 2014, Ard Biesheuvel wrote:
> On 20 January 2014 18:44, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Mon, 20 Jan 2014, Catalin Marinas wrote:
> >
> >> On Mon, Dec 23, 2013 at 02:06:27PM +0000, Ard Biesheuvel wrote:
> >> > This series is a followup to the patch that was recently merged by Catalin that
> >> > allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
> >> > discover whether the current CPU has any of those capabilities.
> >> >
> >> > Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
> >> > was recently added to the kernel and glibc (2.18). It extends the feature bit
> >> > space to 64 bits (on 32-bit architectures)
> >> >
> >> > Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
> >> > mode for 64-bit architectures.
> >> >
> >> > Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
> >> >
> >> > Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
> >> > because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
> >> > so there should be agreement about the meaning of feature bits, even if the ARM
> >> > kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R).
> >>
> >> It looks a bit strange to start filling HWCAP2 before HWCAP is full but
> >> I guess we want to preserve some future extensions in HWCAP for older
> >> glibc.
> >
> > How could older glibc possibly care about future extensions?
> >
>
> Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
> whole value, not just the bits whose meaning was known to glibc at the
> time.
> So if desired, a program can interpret AT_HWCAP itself.
>
> AT_HWCAP2 is completely new, so you won't be able to retrieve it using
> getauxval() on an older libc.
I agree. And I don't dispute the bit placement choice either.
Still, an old glibc calling getauxval(AT_HWCAP) should already be
prepared to receive and rightfully ignore those bits it didn't know the
meaning of at the time. So "preserving some future extensions in HWCAP
for older glibc" as a justification makes little sense to me... unless
I'm missing something?
Even if applications interpret those bits themselves, supposing they
still need to be linked against an old glibc, then why would
yet-to-be-defined future extensions be more important to be signaled
using the lower 32 bits than the extensions you propose? That is what I
don't get.
Nicolas
^ permalink raw reply
* [PATCH v2 0/5] arm64: advertise availability of CRC and crypto instructions
From: Ard Biesheuvel @ 2014-01-20 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401201242480.1652@knanqh.ubzr>
On 20 January 2014 18:44, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Mon, 20 Jan 2014, Catalin Marinas wrote:
>
>> On Mon, Dec 23, 2013 at 02:06:27PM +0000, Ard Biesheuvel wrote:
>> > This series is a followup to the patch that was recently merged by Catalin that
>> > allocates hwcaps bits for CRC and Crypto Extensions instructions so userland can
>> > discover whether the current CPU has any of those capabilities.
>> >
>> > Patch #1 enables ARM support for the ELF_HWCAP2/AT_HWCAP2 ELF auxv entry that
>> > was recently added to the kernel and glibc (2.18). It extends the feature bit
>> > space to 64 bits (on 32-bit architectures)
>> >
>> > Patch #2 adds generic support for ELF_HWCAP2/AT_HWCAP2 to the 32-bit ELF compat
>> > mode for 64-bit architectures.
>> >
>> > Patch #3 adds support for ELF_HWCAP2/AT_HWCAP2 to arm64's 32-bit ELF compat mode
>> >
>> > Patch #4 allocates the HWCAP2 bits in the arch/arm tree. This is necessary
>> > because 32-bit ARM binaries can execute both under ARM and under arm64 kernels,
>> > so there should be agreement about the meaning of feature bits, even if the ARM
>> > kernel has no support yet for ARMv8 32-bit only hardware (such as ARMv8-R).
>>
>> It looks a bit strange to start filling HWCAP2 before HWCAP is full but
>> I guess we want to preserve some future extensions in HWCAP for older
>> glibc.
>
> How could older glibc possibly care about future extensions?
>
Calling getauxval(AT_HWCAP) on an outdated libc.so will give you the
whole value, not just the bits whose meaning was known to glibc at the
time.
So if desired, a program can interpret AT_HWCAP itself.
AT_HWCAP2 is completely new, so you won't be able to retrieve it using
getauxval() on an older libc.
--
Ard.
^ permalink raw reply
* [PATCHv13 27/40] ARM: dts: omap3 clock data
From: Sebastian Reichel @ 2014-01-20 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389276051-1326-28-git-send-email-t-kristo@ti.com>
Hi,
I just found some time to update my SSI driver adding DT clock
support. It works, but I wonder if the alias of the ssi clocks
can be changed to something like the following:
/* omap3430es1-clocks.dtsi */
ssi_ick: ssi_ick_3430es1 {};
ssi_ssr_fck: ssi_ssr_fck_3430es1 {};
ssi_sst_fck: ssi_sst_fck_3430es1 {};
/* omap36xx-omap3430es2plus-clocks.dtsi */
ssi_ick: ssi_ick_3430es2 {};
ssi_ssr_fck: ssi_ssr_fck_3430es2 {};
ssi_sst_fck: ssi_sst_fck_3430es2 {};
With this change I can reference the ssi clocks in omap3.dtsi
instead of creating files for omap3430es1 and omap3430es2+.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140120/d029b721/attachment.sig>
^ permalink raw reply
* [GIT PULL] arm64 patches for 3.14-rc1
From: Catalin Marinas @ 2014-01-20 17:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the arm64 patches below. Thanks.
The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:
Linux 3.13-rc4 (2013-12-15 12:31:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream
for you to fetch changes up to 883c057367014d20a14b5054e4eb0d81ce3bea5c:
arm64: fix typo in entry.S (2014-01-13 13:55:13 +0000)
----------------------------------------------------------------
- CPU suspend support on top of PSCI (firmware Power State Coordination
Interface)
- Jump label support
- CMA can now be enabled on arm64
- HWCAP bits for crypto and CRC32 extensions
- Optimised percpu using tpidr_el1 register
- Code cleanup
----------------------------------------------------------------
Ard Biesheuvel (1):
arm64: drop redundant macros from read_cpuid()
Catalin Marinas (1):
Merge tag 'arm64-suspend' of git://linux-arm.org/linux-2.6-lp into upstream
Geoff Levand (1):
arm64: Remove unused __data_loc variable
Jiang Liu (7):
arm64: introduce basic aarch64 instruction decoding helpers
arm64: introduce interfaces to hotpatch kernel and module code
arm64: move encode_insn_immediate() from module.c to insn.c
arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions
arm64, jump label: detect %c support for ARM64
arm64, jump label: optimize jump label implementation
jump_label: use defined macros instead of hard-coding for better readability
Konstantin Khlebnikov (2):
ARM64: check stack pointer in get_wchan
ARM64: fix framepointer check in unwind_frame
Laura Abbott (3):
arm64: Correct virt_addr_valid
arm64: Warn on NULL device structure for dma APIs
arm64: Enable CMA
Liviu Dudau (1):
arm64: Remove outdated comment
Lorenzo Pieralisi (13):
arm64: kernel: add MPIDR_EL1 accessors macros
arm64: kernel: build MPIDR_EL1 hash function data structure
arm64: kernel: suspend/resume registers save/restore
arm64: kernel: cpu_{suspend/resume} implementation
arm64: kernel: implement fpsimd CPU PM notifier
arm: kvm: implement CPU PM notifier
arm64: kernel: refactor code to install/uninstall breakpoints
arm64: kernel: implement HW breakpoints CPU PM notifier
arm64: enable generic clockevent broadcast
arm64: kernel: add CPU idle call
arm64: kernel: add PM build infrastructure
arm64: add CPU power management menu/entries
arm64: kernel: restore HW breakpoint registers in cpu_suspend
Mark Brown (1):
arm64: dts: Reduce size of virtio block device for foundation model
Mark Hambleton (2):
arm64: dts: Add a virtio disk to the RTSM motherboard
arm64: cmpxchg: update macros to prevent warnings
Mark Rutland (1):
arm64: vmlinux.lds.S: drop redundant .comment
Neil Zhang (1):
arm64: fix typo in entry.S
Sandeepa Prabhu (1):
arm64: support single-step and breakpoint handler hooks
Steve Capper (1):
arm64: Add hwcaps for crypto and CRC32 extensions.
Vinayak Kale (2):
genirq: Add an accessor for IRQ_PER_CPU flag
arm64: perf: add support for percpu pmu interrupt
Will Deacon (5):
arm64: percpu: implement optimised pcpu access using tpidr_el1
arm64: use generic strnlen_user and strncpy_from_user functions
arm64: futex: ensure .fixup entries are sufficiently aligned
arm64: dcache: select DCACHE_WORD_ACCESS for little-endian CPUs
arm64: kconfig: select HAVE_EFFICIENT_UNALIGNED_ACCESS
arch/arm/kvm/arm.c | 30 +++
arch/arm64/Kconfig | 27 +++
arch/arm64/boot/dts/foundation-v8.dts | 2 +-
arch/arm64/boot/dts/rtsm_ve-motherboard.dtsi | 6 +
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64/include/asm/cmpxchg.h | 28 ++-
arch/arm64/include/asm/cpu_ops.h | 6 +
arch/arm64/include/asm/cputype.h | 28 +--
arch/arm64/include/asm/debug-monitors.h | 21 ++
arch/arm64/include/asm/dma-contiguous.h | 29 +++
arch/arm64/include/asm/futex.h | 1 +
arch/arm64/include/asm/hardirq.h | 2 +-
arch/arm64/include/asm/insn.h | 108 ++++++++++
arch/arm64/include/asm/jump_label.h | 52 +++++
arch/arm64/include/asm/memory.h | 3 +-
arch/arm64/include/asm/percpu.h | 41 ++++
arch/arm64/include/asm/proc-fns.h | 3 +
arch/arm64/include/asm/smp_plat.h | 13 ++
arch/arm64/include/asm/suspend.h | 27 +++
arch/arm64/include/asm/uaccess.h | 25 +--
arch/arm64/include/asm/word-at-a-time.h | 94 +++++++++
arch/arm64/include/uapi/asm/hwcap.h | 6 +-
arch/arm64/kernel/Makefile | 4 +-
arch/arm64/kernel/arm64ksyms.c | 5 +-
arch/arm64/kernel/asm-offsets.c | 11 +
arch/arm64/kernel/debug-monitors.c | 88 +++++++-
arch/arm64/kernel/entry.S | 4 +-
arch/arm64/kernel/fpsimd.c | 36 ++++
arch/arm64/kernel/head.S | 10 -
arch/arm64/kernel/hw_breakpoint.c | 203 ++++++++++++------
arch/arm64/kernel/insn.c | 304 +++++++++++++++++++++++++++
arch/arm64/kernel/jump_label.c | 58 +++++
arch/arm64/kernel/module.c | 157 +++++---------
arch/arm64/kernel/perf_event.c | 108 +++++++---
arch/arm64/kernel/process.c | 14 +-
arch/arm64/kernel/setup.c | 122 ++++++++++-
arch/arm64/kernel/sleep.S | 184 ++++++++++++++++
arch/arm64/kernel/smp.c | 23 +-
arch/arm64/kernel/stacktrace.c | 2 +-
arch/arm64/kernel/suspend.c | 132 ++++++++++++
arch/arm64/kernel/vmlinux.lds.S | 3 -
arch/arm64/lib/Makefile | 8 +-
arch/arm64/lib/strncpy_from_user.S | 50 -----
arch/arm64/lib/strnlen_user.S | 47 -----
arch/arm64/mm/dma-mapping.c | 35 ++-
arch/arm64/mm/init.c | 3 +
arch/arm64/mm/proc.S | 69 ++++++
include/linux/irqdesc.h | 8 +
include/linux/jump_label.h | 19 +-
scripts/gcc-goto.sh | 2 +-
50 files changed, 1859 insertions(+), 403 deletions(-)
create mode 100644 arch/arm64/include/asm/dma-contiguous.h
create mode 100644 arch/arm64/include/asm/insn.h
create mode 100644 arch/arm64/include/asm/jump_label.h
create mode 100644 arch/arm64/include/asm/percpu.h
create mode 100644 arch/arm64/include/asm/suspend.h
create mode 100644 arch/arm64/include/asm/word-at-a-time.h
create mode 100644 arch/arm64/kernel/insn.c
create mode 100644 arch/arm64/kernel/jump_label.c
create mode 100644 arch/arm64/kernel/sleep.S
create mode 100644 arch/arm64/kernel/suspend.c
delete mode 100644 arch/arm64/lib/strncpy_from_user.S
delete mode 100644 arch/arm64/lib/strnlen_user.S
--
Catalin
^ 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