* [PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops
From: Russell King - ARM Linux @ 2014-02-10 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210125307.GG20143@ulmo.nvidia.com>
On Mon, Feb 10, 2014 at 01:53:08PM +0100, Thierry Reding wrote:
> On Fri, Feb 07, 2014 at 04:55:00PM +0100, Jean-Francois Moine wrote:
> > Some simple components don't need to do any specific action on
> > bind to / unbind from a master component.
> >
> > This patch permits such components to omit the bind/unbind
> > operations.
> >
> > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> > ---
> > drivers/base/component.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/component.c b/drivers/base/component.c
> > index c53efe6..0a39d7a 100644
> > --- a/drivers/base/component.c
> > +++ b/drivers/base/component.c
> > @@ -225,7 +225,8 @@ static void component_unbind(struct component *component,
> > {
> > WARN_ON(!component->bound);
> >
> > - component->ops->unbind(component->dev, master->dev, data);
> > + if (component->ops)
> > + component->ops->unbind(component->dev, master->dev, data);
>
> This doesn't actually do what the commit message says. This makes
> component->ops optional, not component->ops->unbind().
>
> A more correct check would be:
>
> if (component->ops && component->ops->unbind)
>
> > component->bound = false;
> >
> > /* Release all resources claimed in the binding of this component */
> > @@ -274,7 +275,11 @@ static int component_bind(struct component *component, struct master *master,
> > dev_dbg(master->dev, "binding %s (ops %ps)\n",
> > dev_name(component->dev), component->ops);
> >
> > - ret = component->ops->bind(component->dev, master->dev, data);
> > + if (component->ops)
> > + ret = component->ops->bind(component->dev, master->dev, data);
>
> Same here.
I've NAK'd these patches already - I believe they're based on a
mis-understanding of how this should be used. I believe Jean-Francois
has only looked at the core, rather than looking at the imx-drm example
it was posted with in an attempt to understand it.
Omitting the component bind operations is absurd because it makes the
component code completely pointless, since there is then no way to
control the sequencing of driver initialisation - something which is
one of the primary reasons for this code existing in the first place.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] reset: Add generic GPIO reset driver.
From: Philipp Zabel @ 2014-02-10 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210125432.10683.86571.stgit@localhost>
Hi Martin,
Am Montag, den 10.02.2014, 13:54 +0100 schrieb Martin Fuzzey:
> This driver allows GPIO lines to be used as reset signals.
> It has two main use cases:
>
> 1) Allow drivers to reset their hardware via a GPIO line in a standard fashion
> as supplied by the reset framework.
> This allows adhoc driver code requesting GPIOs etc to be replaced with a
> single call to device_reset().
have you seen the patch at https://lkml.org/lkml/2014/1/8/190:
"reset: Add GPIO support to reset controller framework" ?
Adding a GPIO reset controller device node to the device tree is the
wrong approach for devices enumerated in the device tree. Those should
just declare their reset-gpios directly.
> 2) Allow hardware on discoverable busses to be rest via a GPIO line
> without driver modifications.
>
> Examples of the second use case include:
> * SDIO wifi modules
> * USB hub chips with a reset line
Now this is interesting. But if you export it to userspace anyway, why
not use the existing gpio sysfs API?
I think a proper solution should handle this in the kernel. For SDIO
wifi modules you usually have a powerdown line that can be implemented
as an rfkill switch.
regards
Philipp
^ permalink raw reply
* [PATCH] ASoC: fsl: fix pm support of machine drivers
From: Mark Brown @ 2014-02-10 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391836835-14892-1-git-send-email-shawn.guo@linaro.org>
On Sat, Feb 08, 2014 at 01:20:35PM +0800, Shawn Guo wrote:
> The commit 1abe729 (ASoC: fsl: Add missing pm to current machine
> drivers) enables pm support for a few IMX machine drivers. But it does
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/a54accae/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: shmobile: r8a7791: add Ether DT support
From: Sergei Shtylyov @ 2014-02-10 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F8CBFB.5060707@codethink.co.uk>
Hello.
On 10-02-2014 16:54, Ben Dooks wrote:
>> Define the generic R8A7791 part of the Ether device node.
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> ---
>> arch/arm/boot/dts/r8a7791.dtsi | 15 ++++++++++++++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>> Index: renesas/arch/arm/boot/dts/r8a7791.dtsi
>> ===================================================================
>> --- renesas.orig/arch/arm/boot/dts/r8a7791.dtsi
>> +++ renesas/arch/arm/boot/dts/r8a7791.dtsi
>> @@ -2,7 +2,8 @@
>> * Device Tree Source for the r8a7791 SoC
>> *
>> * Copyright (C) 2013 Renesas Electronics Corporation
>> - * Copyright (C) 2013 Renesas Solutions Corp.
>> + * Copyright (C) 2013-2014 Renesas Solutions Corp.
>> + * Copyright (C) 2014 Cogent Embedded Inc.
>> *
>> * This file is licensed under the terms of the GNU General Public License
>> * version 2. This program is licensed "as is" without any warranty of any
>> @@ -366,6 +367,18 @@
>> status = "disabled";
>> };
>>
>> + ether: ethernet at ee700000 {
>> + compatible = "renesas,ether-r8a7791";
>> + reg = <0 0xee700000 0 0x400>;
>> + interrupt-parent = <&gic>;
>> + interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&mstp8_clks R8A7791_CLK_ETHER>;
>> + phy-mode = "rmii";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
> Is the device only capable of doing RMII?
Yes.
WBR, Sergei
^ permalink raw reply
* [PATCH 14/28] Remove MACH_SMDKC210
From: Paul Bolle @ 2014-02-10 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210114154.GQ1757@sirena.org.uk>
On Mon, 2014-02-10 at 11:41 +0000, Mark Brown wrote:
> On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:
> Please fix whatever script you're using to generate your mails, it's
> generating corrupt headers.
I think Richard's mail didn't end up on lkml. But it's pretty clear what
it must have looked like.
> > config SND_SOC_SAMSUNG_SMDK_WM9713
> > tristate "SoC AC97 Audio support for SMDK with WM9713"
> > - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210)
> > + depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310)
>
> Like I said to Paul this isn't fixing the actual issue - think about why
> the symbol was there in the first place and why it was removed. There
> is a problem here but this would make it less likely that it would be
> properly fixed.
Would you mind going through this one step at a time, just to make sure
_I_ understand what it is that you'd like to see?
If so, to be absolutely sure we start from the same point: do you agree
that the above line now effectively reads
depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || false || false)
because there's neither a Kconfig symbol MACH_SMDKV310 nor a Kconfig
symbol MACH_SMDKC210?
Paul Bolle
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Fabrice Gasnier @ 2014-02-10 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F89522.6030302@codethink.co.uk>
On 02/10/2014 10:00 AM, Ben Dooks wrote:
> On 10/02/14 08:50, Fabrice Gasnier wrote:
>> On 02/07/2014 06:09 PM, Will Deacon wrote:
>>> On Fri, Feb 07, 2014 at 04:19:15PM +0000, Fabrice GASNIER wrote:
>>>> This patch adds imprecise abort enable/disable macros.
>>>> It also enables imprecise aborts when starting kernel.
>>>>
>>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
>>>> ---
>>>> arch/arm/include/asm/irqflags.h | 33
>>>> +++++++++++++++++++++++++++++++++
>>>> arch/arm/kernel/smp.c | 1 +
>>>> arch/arm/kernel/traps.c | 4 ++++
>>>> 3 files changed, 38 insertions(+)
>>>>
>>>> diff --git a/arch/arm/include/asm/irqflags.h
>>>> b/arch/arm/include/asm/irqflags.h
>>>> index 3b763d6..82e3834 100644
>>>> --- a/arch/arm/include/asm/irqflags.h
>>>> +++ b/arch/arm/include/asm/irqflags.h
>>>> @@ -51,6 +51,9 @@ static inline void arch_local_irq_disable(void)
>>>> #define local_fiq_enable() __asm__("cpsie f @ __stf" : : :
>>>> "memory", "cc")
>>>> #define local_fiq_disable() __asm__("cpsid f @ __clf" : : :
>>>> "memory", "cc")
>>>> +
>>>> +#define local_abt_enable() __asm__("cpsie a @ __sta" : : :
>>>> "memory", "cc")
>>>> +#define local_abt_disable() __asm__("cpsid a @ __cla" : : :
>>>> "memory", "cc")
>>>> #else
>>>> /*
>>>> @@ -130,6 +133,36 @@ static inline void arch_local_irq_disable(void)
>>>> : "memory", "cc"); \
>>>> })
>>>> +/*
>>>> + * Enable Aborts
>>>> + */
>>>> +#define local_abt_enable() \
>>>> + ({ \
>>>> + unsigned long temp; \
>>>> + __asm__ __volatile__( \
>>>> + "mrs %0, cpsr @ sta\n" \
>>>> +" bic %0, %0, %1\n" \
>>>> +" msr cpsr_c, %0" \
>>>> + : "=r" (temp) \
>>>> + : "r" (PSR_A_BIT) \
>>> Can you use "i" instead of a register for this constant?
>> Hi,
>>
>> Sure, I will change it in a future patch.
>>>
>>>> + : "memory", "cc"); \
>>> You don't need the "cc" clobber.
>> That surprises me: I think "orr" and "bic" instruction might change N
>> and Z bits, depending on the result.
>> So shouldn't "cc" be placed here ?
>> I also see that it is used in local_fiq_enable/disable macros just
>> above, that are similar:
>
> No, only if they have the S flag set on the instruction (ORRS,BICS)
>
>
Thank you for pointing that out!
^ permalink raw reply
* [PATCH] ARM: shmobile: r8a7778 dtsi: Remove duplicate i2c nodes
From: Geert Uytterhoeven @ 2014-02-10 13:42 UTC (permalink / raw)
To: linux-arm-kernel
"ARM: shmobile: r8a7778: add I2C support on DTSI" was applied twice:
commit ae4273ec7b25c8b9c895a4aae31f2fced980b7bf
commit 3acb51b9215bd99da403ecf8200f8425176b1926
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
arch/arm/boot/dts/r8a7778.dtsi | 40 ----------------------------------------
1 file changed, 40 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index ddb3bd7a8838..85c5b3b99f5e 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -203,46 +203,6 @@
status = "disabled";
};
- i2c0: i2c at ffc70000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
- reg = <0xffc70000 0x1000>;
- interrupt-parent = <&gic>;
- interrupts = <0 67 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
- i2c1: i2c at ffc71000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
- reg = <0xffc71000 0x1000>;
- interrupt-parent = <&gic>;
- interrupts = <0 78 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
- i2c2: i2c at ffc72000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
- reg = <0xffc72000 0x1000>;
- interrupt-parent = <&gic>;
- interrupts = <0 76 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
- i2c3: i2c at ffc73000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
- reg = <0xffc73000 0x1000>;
- interrupt-parent = <&gic>;
- interrupts = <0 77 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
hspi0: spi at fffc7000 {
compatible = "renesas,hspi";
reg = <0xfffc7000 0x18>;
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Fabrice Gasnier @ 2014-02-10 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210111710.GC17766@mudshark.cambridge.arm.com>
On 02/10/2014 12:17 PM, Will Deacon wrote:
> On Mon, Feb 10, 2014 at 08:50:16AM +0000, Fabrice Gasnier wrote:
>> On 02/07/2014 06:09 PM, Will Deacon wrote:
>>> On Fri, Feb 07, 2014 at 04:19:15PM +0000, Fabrice GASNIER wrote:
>>>> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
>>>> index 4636d56..ef15709 100644
>>>> --- a/arch/arm/kernel/traps.c
>>>> +++ b/arch/arm/kernel/traps.c
>>>> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
>>>>
>>>> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
>>>> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
>>>> +
>>>> + /* Enable imprecise aborts */
>>>> + local_abt_enable();
>>> Surely we want to enable this as early as possible? Now, putting this into
>>> head.S is ugly, as it duplicating it across all the proc*.S files, so why
>>> not setup_arch?
>> Sorry, I'm not sure to understand your last comment.
>> At least, I need it enabled before probing drivers (PCIe bus)
>> I've added imprecise abort enable code in traps.c, following Russel
>> King's advice, please see:
>> http://archive.arm.linux.org.uk/lurker/message/20140131.170827.d752a1cc.en.html
>> As abort bit is local to a cpu, i've also added it in smp.c, but this
>> may not be the right place ?
>>
>> Please elaborate,
> I was just suggesting that we move your local_abt_enable() call to
> setup_arch, since that's called before early_trap_init on the primary CPU.
Thanks for the clarification. Yes, maybe others would like to have it
enabled as you suggest.
My point is, it's good enough for such use case to do it in early_trap_init.
I'd prefer to follow Russel's first advice.
Fabrice
>
> Will
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Russell King - ARM Linux @ 2014-02-10 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210111710.GC17766@mudshark.cambridge.arm.com>
On Mon, Feb 10, 2014 at 11:17:10AM +0000, Will Deacon wrote:
> On Mon, Feb 10, 2014 at 08:50:16AM +0000, Fabrice Gasnier wrote:
> > On 02/07/2014 06:09 PM, Will Deacon wrote:
> > > On Fri, Feb 07, 2014 at 04:19:15PM +0000, Fabrice GASNIER wrote:
> > >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> > >> index 4636d56..ef15709 100644
> > >> --- a/arch/arm/kernel/traps.c
> > >> +++ b/arch/arm/kernel/traps.c
> > >> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
> > >>
> > >> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> > >> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> > >> +
> > >> + /* Enable imprecise aborts */
> > >> + local_abt_enable();
> > > Surely we want to enable this as early as possible? Now, putting this into
> > > head.S is ugly, as it duplicating it across all the proc*.S files, so why
> > > not setup_arch?
> > Sorry, I'm not sure to understand your last comment.
> > At least, I need it enabled before probing drivers (PCIe bus)
> > I've added imprecise abort enable code in traps.c, following Russel
> > King's advice, please see:
> > http://archive.arm.linux.org.uk/lurker/message/20140131.170827.d752a1cc.en.html
> > As abort bit is local to a cpu, i've also added it in smp.c, but this
> > may not be the right place ?
> >
> > Please elaborate,
>
> I was just suggesting that we move your local_abt_enable() call to
> setup_arch, since that's called before early_trap_init on the primary CPU.
Why would we want to enable aborts before we've setup the vectors page
to handle an abort? That's akin to enabling interrupts and hoping there
isn't one pending...
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Russell King - ARM Linux @ 2014-02-10 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140207170903.GT5976@mudshark.cambridge.arm.com>
On Fri, Feb 07, 2014 at 05:09:03PM +0000, Will Deacon wrote:
> On Fri, Feb 07, 2014 at 04:19:15PM +0000, Fabrice GASNIER wrote:
> > +#define local_abt_enable() \
> > + ({ \
> > + unsigned long temp; \
> > + __asm__ __volatile__( \
> > + "mrs %0, cpsr @ sta\n" \
> > +" bic %0, %0, %1\n" \
> > +" msr cpsr_c, %0" \
> > + : "=r" (temp) \
> > + : "r" (PSR_A_BIT) \
>
> Can you use "i" instead of a register for this constant?
As the PSR A bit isn't in bits 7-0, cpsr_c isn't what's required here.
It needs something different... that's why my previous patch for you
didn't work.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Will Deacon @ 2014-02-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210135659.GU26684@n2100.arm.linux.org.uk>
On Mon, Feb 10, 2014 at 01:56:59PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 10, 2014 at 11:17:10AM +0000, Will Deacon wrote:
> > On Mon, Feb 10, 2014 at 08:50:16AM +0000, Fabrice Gasnier wrote:
> > > On 02/07/2014 06:09 PM, Will Deacon wrote:
> > > > On Fri, Feb 07, 2014 at 04:19:15PM +0000, Fabrice GASNIER wrote:
> > > >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> > > >> index 4636d56..ef15709 100644
> > > >> --- a/arch/arm/kernel/traps.c
> > > >> +++ b/arch/arm/kernel/traps.c
> > > >> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
> > > >>
> > > >> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> > > >> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> > > >> +
> > > >> + /* Enable imprecise aborts */
> > > >> + local_abt_enable();
> > > > Surely we want to enable this as early as possible? Now, putting this into
> > > > head.S is ugly, as it duplicating it across all the proc*.S files, so why
> > > > not setup_arch?
> > > Sorry, I'm not sure to understand your last comment.
> > > At least, I need it enabled before probing drivers (PCIe bus)
> > > I've added imprecise abort enable code in traps.c, following Russel
> > > King's advice, please see:
> > > http://archive.arm.linux.org.uk/lurker/message/20140131.170827.d752a1cc.en.html
> > > As abort bit is local to a cpu, i've also added it in smp.c, but this
> > > may not be the right place ?
> > >
> > > Please elaborate,
> >
> > I was just suggesting that we move your local_abt_enable() call to
> > setup_arch, since that's called before early_trap_init on the primary CPU.
>
> Why would we want to enable aborts before we've setup the vectors page
> to handle an abort? That's akin to enabling interrupts and hoping there
> isn't one pending...
I figured we'd want to fall over as quickly as possible if the bootloader
had left a pending exception for us, but you're right in that it's not very
helpful if we can't print out a diagnostic.
Fabrice, please ignore my suggestion and keep the unmasking where it is.
Will
^ permalink raw reply
* [PATCH 14/28] Remove MACH_SMDKC210
From: Mark Brown @ 2014-02-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392039072.3585.15.camel@x220>
On Mon, Feb 10, 2014 at 02:31:12PM +0100, Paul Bolle wrote:
> On Mon, 2014-02-10 at 11:41 +0000, Mark Brown wrote:
> > On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:
> > Please fix whatever script you're using to generate your mails, it's
> > generating corrupt headers.
> I think Richard's mail didn't end up on lkml. But it's pretty clear what
> it must have looked like.
I can see what it looked like from my inbox, but my mail client can't
understand them at all and hence didn't think the mails were sent to me
and just ignored them when hitting reply.
> > > config SND_SOC_SAMSUNG_SMDK_WM9713
> > > tristate "SoC AC97 Audio support for SMDK with WM9713"
> > > - depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210)
> > > + depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310)
> >
> > Like I said to Paul this isn't fixing the actual issue - think about why
> > the symbol was there in the first place and why it was removed. There
> > is a problem here but this would make it less likely that it would be
> > properly fixed.
> Would you mind going through this one step at a time, just to make sure
> _I_ understand what it is that you'd like to see?
> If so, to be absolutely sure we start from the same point: do you agree
> that the above line now effectively reads
> depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || false || false)
> because there's neither a Kconfig symbol MACH_SMDKV310 nor a Kconfig
> symbol MACH_SMDKC210?
Yes, that's correct. Now, like I say think about what the symbol was
there for in the first place.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140210/17ff5e43/attachment.sig>
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Dave Martin @ 2014-02-10 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391789955-26927-2-git-send-email-fabrice.gasnier@st.com>
On Fri, Feb 07, 2014 at 05:19:15PM +0100, Fabrice GASNIER wrote:
> This patch adds imprecise abort enable/disable macros.
> It also enables imprecise aborts when starting kernel.
Relying on imprecise aborts for hardware probing would be considered bad
hardware and/or software design for ARM-specific stuff.
PCI is more generic though, so we may have to put up with this to some
extent. Can you point me to the affected probing code? I'm not very
familiar with that stuff...
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> arch/arm/include/asm/irqflags.h | 33 +++++++++++++++++++++++++++++++++
> arch/arm/kernel/smp.c | 1 +
> arch/arm/kernel/traps.c | 4 ++++
> 3 files changed, 38 insertions(+)
>
> diff --git a/arch/arm/include/asm/irqflags.h b/arch/arm/include/asm/irqflags.h
> index 3b763d6..82e3834 100644
> --- a/arch/arm/include/asm/irqflags.h
> +++ b/arch/arm/include/asm/irqflags.h
> @@ -51,6 +51,9 @@ static inline void arch_local_irq_disable(void)
>
> #define local_fiq_enable() __asm__("cpsie f @ __stf" : : : "memory", "cc")
> #define local_fiq_disable() __asm__("cpsid f @ __clf" : : : "memory", "cc")
> +
> +#define local_abt_enable() __asm__("cpsie a @ __sta" : : : "memory", "cc")
> +#define local_abt_disable() __asm__("cpsid a @ __cla" : : : "memory", "cc")
> #else
>
> /*
> @@ -130,6 +133,36 @@ static inline void arch_local_irq_disable(void)
> : "memory", "cc"); \
> })
>
> +/*
> + * Enable Aborts
> + */
> +#define local_abt_enable() \
> + ({ \
> + unsigned long temp; \
> + __asm__ __volatile__( \
> + "mrs %0, cpsr @ sta\n" \
> +" bic %0, %0, %1\n" \
> +" msr cpsr_c, %0" \
I suggest you use "cpsie/cpsid a" instead. This requires ARMv6, but the
CPSR.A bit only exists on ARMv6 and later anyway. Poking that bit
on earlier CPUs may cause unpredictable behaviour, so these macros
should be no-ops for v5 and earlier.
> + : "=r" (temp) \
> + : "r" (PSR_A_BIT) \
> + : "memory", "cc"); \
> + })
> +
> +/*
> + * Disable Aborts
> + */
> +#define local_abt_disable() \
> + ({ \
> + unsigned long temp; \
> + __asm__ __volatile__( \
> + "mrs %0, cpsr @ cla\n" \
> +" orr %0, %0, %1\n" \
> +" msr cpsr_c, %0" \
> + : "=r" (temp) \
> + : "r" (PSR_A_BIT) \
> + : "memory", "cc"); \
> + })
> +
> #endif
>
> /*
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index dc894ab..c2093cb 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -377,6 +377,7 @@ asmlinkage void secondary_start_kernel(void)
>
> local_irq_enable();
> local_fiq_enable();
> + local_abt_enable();
>
> /*
> * OK, it's off to the idle thread for us
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 4636d56..ef15709 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
>
> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> +
> + /* Enable imprecise aborts */
> + local_abt_enable();
It would be good to clean up why aborts are not being consistently
enabled on boot.
Really, they should be enabled, except for a brief window during
boot when the vectors are not mapped and the abort can't be dispatched.
Cheers
---Dave
^ permalink raw reply
* [alsa-devel] [PATCH 0/7] Audio support for Armada 370 DB
From: Thomas Petazzoni @ 2014-02-10 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391102051-5319-1-git-send-email-thomas.petazzoni@free-electrons.com>
Hello,
Any comments on the patch series? I'd like these to be included in
3.15, and so far I've only received one simple comment from Jason
Cooper regarding the defconfig changes, but no other comments.
Thanks a lot!
Thomas
On Thu, 30 Jan 2014 18:14:04 +0100, Thomas Petazzoni wrote:
> Hello,
>
> This series of patches enable audio support on the Marvell Armada 370
> Development Board. Since both the I2S controller on the SoC side and
> the I2C audio codec are already supported by the kernel, the amount of
> work is fairly limited.
>
> Also, since the DT bindings that allows to replace the ASoC board
> driver are still being ironed out, I'm proposing to add an old-style
> ASoC board driver for now.
>
> This set of patches only provide support for the analog output and
> input, I am waiting for the optical cable to arrive to get the digital
> input and output to work.
>
> Patches 1 to 3 are to be taken by the ASoC maintainer, while patches 4
> to 7 are to be taken by the mvebu maintainers.
>
> Note that the audio support for Armada 370 also needs a fix to the
> CS42L51, which is being discussed with the author of the change that
> apparently introduced the problem (see discussion at
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071916.html).
>
> Thanks,
>
> Thomas
>
> Thomas Petazzoni (7):
> sound: codec: add Device Tree binding to cs42l51
> sound: soc: enable Kirkwood driver for mvebu platforms
> sound: soc: add ASoC board driver for Armada 370 DB
> ARM: mvebu: add audio I2S controller to Armada 370 Device Tree
> ARM: mvebu: add I2C0 muxing option for Armada 370 SoC
> ARM: mvebu: add audio support to Armada 370 DB
> ARM: mvebu: enable audio options in mvebu_defconfig
>
> .../devicetree/bindings/i2c/trivial-devices.txt | 1 +
> .../devicetree/bindings/sound/mvebu-audio.txt | 1 +
> arch/arm/boot/dts/armada-370-db.dts | 46 +++++++
> arch/arm/boot/dts/armada-370.dtsi | 29 +++++
> arch/arm/configs/mvebu_defconfig | 5 +
> sound/soc/codecs/cs42l51.c | 7 +
> sound/soc/kirkwood/Kconfig | 10 +-
> sound/soc/kirkwood/Makefile | 2 +
> sound/soc/kirkwood/armada-370-db.c | 144 +++++++++++++++++++++
> sound/soc/kirkwood/kirkwood-i2s.c | 1 +
> 10 files changed, 245 insertions(+), 1 deletion(-)
> create mode 100644 sound/soc/kirkwood/armada-370-db.c
>
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 0/6] arm64: Add ftrace support
From: Kulkarni, Ganapatrao @ 2014-02-10 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391768336-5642-1-git-send-email-takahiro.akashi@linaro.org>
Looks OK to me.
Reviewed-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
regards,
Ganapat
________________________________________
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
Sent: Friday, February 7, 2014 3:48 PM
To: rostedt at goodmis.org; fweisbec at gmail.com; mingo at redhat.com; catalin.marinas at arm.com; will.deacon at arm.com; Kulkarni, Ganapatrao; tim.bird at sonymobile.com
Cc: arndb at arndb.de; linux-arm-kernel at lists.infradead.org; linaro-kernel at lists.linaro.org; linux-kernel at vger.kernel.org; patches at linaro.org; AKASHI Takahiro
Subject: [PATCH v3 0/6] arm64: Add ftrace support
This is my third version of patchset for ftrace support.
There was another implementation from Cavium network, but both of us agreed
to use my patchset as future base. He is supposed to review this code, too.
The only issue that I had some concern on was "fault protection" code
in prepare_ftrace_return(). With discussions with Steven and Tim (as author
of arm ftrace), I removed that code since I'm not quite sure about possibility
of "fault" occurrences in this function.
The code is tested on ARMv8 Fast Model with the following tracers & events:
function tracer with dynamic ftrace
function graph tracer with dynamic ftrace
syscall tracepoint
irqsoff & preemptirqsoff (which use CALLER_ADDRx)
and also verified with in-kernel tests, FTRACE_SELFTEST, FTRACE_STARTUP_TEST
and EVENT_TRACE_TEST_SYSCALLS.
Please be careful:
* elf.h on cross-build host must have AArch64 definitions, EM_AARCH64 and
R_AARCH64_ABS64, to compile recordmcount utility. See [4/6].
[4/6] also gets warnings from checkpatch, but they are based on the
original's coding style.
* This patch may conflict with my audit patch because both changes the same
location in syscall_trace(). I expect the functions are called in this
order:
On entry,
* tracehook_report_syscall(ENTER)
* trace_sys_enter()
* audit_syscall_entry()
On exit,
* audit_sysscall_exit()
* trace_sys_exit()
* tracehook_report_syscall(EXIT)
Changes from v1 to v2:
* splitted one patch into some pieces for easier review
(especially function tracer + dynamic ftrace + CALLER_ADDRx)
* put return_address() in a separate file
* renamed __mcount to _mcount (it was my mistake)
* changed stackframe handling to get parent's frame pointer
* removed ARCH_SUPPORTS_FTRACE_OPS
* switched to "hotpatch" interfaces from Huawai
* revised descriptions in comments
Changes from v2 to v3:
* optimized register usages in asm (by not saving x0, x1, and x2)
* removed "fault protection" code in prepare_ftrace_return()
* rewrote ftrace_modify_code() using "hotpatch" interfaces
* revised descriptions in comments
AKASHI Takahiro (6):
arm64: Add ftrace support
arm64: ftrace: Add dynamic ftrace support
arm64: ftrace: Add CALLER_ADDRx macros
ftrace: Add arm64 support to recordmcount
arm64: ftrace: Add system call tracepoint
arm64: Add 'notrace' attribute to unwind_frame() for ftrace
arch/arm64/Kconfig | 6 +
arch/arm64/include/asm/ftrace.h | 54 +++++++++
arch/arm64/include/asm/syscall.h | 1 +
arch/arm64/include/asm/unistd.h | 2 +
arch/arm64/kernel/Makefile | 9 +-
arch/arm64/kernel/arm64ksyms.c | 4 +
arch/arm64/kernel/entry-ftrace.S | 215 ++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/ftrace.c | 177 +++++++++++++++++++++++++++++
arch/arm64/kernel/ptrace.c | 5 +
arch/arm64/kernel/return_address.c | 55 +++++++++
arch/arm64/kernel/stacktrace.c | 2 +-
scripts/recordmcount.c | 4 +
scripts/recordmcount.pl | 5 +
13 files changed, 537 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/include/asm/ftrace.h
create mode 100644 arch/arm64/kernel/entry-ftrace.S
create mode 100644 arch/arm64/kernel/ftrace.c
create mode 100644 arch/arm64/kernel/return_address.c
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/5] arm64: barriers: make use of barrier options with explicit barriers
From: Will Deacon @ 2014-02-10 14:22 UTC (permalink / raw)
To: linux-arm-kernel
When calling our low-level barrier macros directly, we can often suffice
with more relaxed behaviour than the default "all accesses, full system"
option.
This patch updates the users of dsb() to specify the option which they
actually require.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/barrier.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/pgtable.h | 4 ++--
arch/arm64/include/asm/tlbflush.h | 14 +++++++-------
arch/arm64/kernel/process.c | 2 +-
arch/arm64/kvm/sys_regs.c | 4 ++--
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 409ca370cfe2..5c436e3457dd 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -27,7 +27,7 @@
#define isb() asm volatile("isb" : : : "memory")
#define dsb(opt) asm volatile("dsb sy" : : : "memory")
-#define mb() dsb()
+#define mb() dsb(sy)
#define rmb() asm volatile("dsb ld" : : : "memory")
#define wmb() asm volatile("dsb st" : : : "memory")
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index 889324981aa4..2a365a9e36c0 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -143,7 +143,7 @@ static inline void flush_cache_vmap(unsigned long start, unsigned long end)
* set_pte_at() called from vmap_pte_range() does not
* have a DSB after cleaning the cache line.
*/
- dsb();
+ dsb(ishst);
}
static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b524dcd17243..54aa68f61008 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -310,7 +310,7 @@ extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)
{
*pmdp = pmd;
- dsb();
+ dsb(ishst);
}
static inline void pmd_clear(pmd_t *pmdp)
@@ -340,7 +340,7 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
static inline void set_pud(pud_t *pudp, pud_t pud)
{
*pudp = pud;
- dsb();
+ dsb(ishst);
}
static inline void pud_clear(pud_t *pudp)
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index 8b482035cfc2..3083a08f9622 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -72,9 +72,9 @@ extern struct cpu_tlb_fns cpu_tlb;
*/
static inline void flush_tlb_all(void)
{
- dsb();
+ dsb(ishst);
asm("tlbi vmalle1is");
- dsb();
+ dsb(ish);
isb();
}
@@ -82,9 +82,9 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
{
unsigned long asid = (unsigned long)ASID(mm) << 48;
- dsb();
+ dsb(ishst);
asm("tlbi aside1is, %0" : : "r" (asid));
- dsb();
+ dsb(ish);
}
static inline void flush_tlb_page(struct vm_area_struct *vma,
@@ -93,9 +93,9 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long addr = uaddr >> 12 |
((unsigned long)ASID(vma->vm_mm) << 48);
- dsb();
+ dsb(ishst);
asm("tlbi vae1is, %0" : : "r" (addr));
- dsb();
+ dsb(ish);
}
/*
@@ -114,7 +114,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
* set_pte() does not have a DSB, so make sure that the page table
* write is visible.
*/
- dsb();
+ dsb(ishst);
}
#define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 1c0a9be2ffa8..8e78cb238376 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -294,7 +294,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
* Complete any pending TLB or cache maintenance on this CPU in case
* the thread migrates to a different CPU.
*/
- dsb();
+ dsb(ish);
/* the actual thread switch */
last = cpu_switch_to(prev, next);
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 02e9d09e1d80..bbaaabe8e899 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -70,13 +70,13 @@ static u32 get_ccsidr(u32 csselr)
static void do_dc_cisw(u32 val)
{
asm volatile("dc cisw, %x0" : : "r" (val));
- dsb();
+ dsb(ishst);
}
static void do_dc_csw(u32 val)
{
asm volatile("dc csw, %x0" : : "r" (val));
- dsb();
+ dsb(ishst);
}
/* See note@ARM ARM B1.14.4 */
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 2/5] irqchip: gic: use writel instead of dsb + writel_relaxed
From: Will Deacon @ 2014-02-10 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392042159-11603-1-git-send-email-will.deacon@arm.com>
When sending an SGI to another CPU, we require a DSB to ensure that
any pending stores to normal memory are made visible to the recipient
before the interrupt arrives.
Rather than use a vanilla dsb() (which will soon cause an assembly error
on arm64) before the writel_relaxed, we can instead use dsb(ishst),
since we just need to ensure that any pending normal writes are visible
within the inner-shareable domain before we poke the GIC.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
v1 => v2: Use dsb ishst instead of writel (which requires an L2 sync)
since the sync should already have been executed by the caller
if required. We *might* be able to relax this further to a dmb
but Catalin and I haven't got to the bottom of that yet.
Marc: I dropped your Ack, so could you take another look please?
drivers/irqchip/irq-gic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 341c6016812d..26ff83c455f3 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -663,7 +663,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
*/
- dsb();
+ dsb(ishst);
/* this always happens on GIC0 */
writel_relaxed(map << 16 | irq, gic_data_dist_base(&gic_data[0]) + GIC_DIST_SOFTINT);
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 3/5] iommu/arm-smmu: provide option to dsb macro when publishing tables
From: Will Deacon @ 2014-02-10 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392042159-11603-1-git-send-email-will.deacon@arm.com>
On coherent systems, publishing new page tables to the SMMU walker is
achieved with a dsb instruction. In fact, this can be a dsb(ishst) which
also provides the mandatory barrier option for arm64.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 8911850c9444..8f6fee54f3b1 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1417,7 +1417,7 @@ out_unlock:
/* Ensure new page tables are visible to the hardware walker */
if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK)
- dsb();
+ dsb(ishst);
return ret;
}
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 4/5] arm64: barriers: wire up new barrier options
From: Will Deacon @ 2014-02-10 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392042159-11603-1-git-send-email-will.deacon@arm.com>
Now that all callers of the barrier macros are updated to pass the
mandatory options, update the macros so the option is actually used.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/barrier.h | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 5c436e3457dd..71a42d6599fb 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -25,11 +25,12 @@
#define wfi() asm volatile("wfi" : : : "memory")
#define isb() asm volatile("isb" : : : "memory")
-#define dsb(opt) asm volatile("dsb sy" : : : "memory")
+#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
+#define dsb(opt) asm volatile("dsb " #opt : : : "memory")
#define mb() dsb(sy)
-#define rmb() asm volatile("dsb ld" : : : "memory")
-#define wmb() asm volatile("dsb st" : : : "memory")
+#define rmb() dsb(ld)
+#define wmb() dsb(st)
#ifndef CONFIG_SMP
#define smp_mb() barrier()
@@ -53,9 +54,9 @@ do { \
#else
-#define smp_mb() asm volatile("dmb ish" : : : "memory")
-#define smp_rmb() asm volatile("dmb ishld" : : : "memory")
-#define smp_wmb() asm volatile("dmb ishst" : : : "memory")
+#define smp_mb() dmb(ish)
+#define smp_rmb() dmb(ishld)
+#define smp_wmb() dmb(ishst)
#define smp_store_release(p, v) \
do { \
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 5/5] arm64: barriers: use barrier() instead of smp_mb() when !SMP
From: Will Deacon @ 2014-02-10 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392042159-11603-1-git-send-email-will.deacon@arm.com>
The recently introduced acquire/release accessors refer to smp_mb()
in the !CONFIG_SMP case. This is confusing when reading the code, so use
barrier() directly when we know we're UP.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/barrier.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 71a42d6599fb..709f1f6d6bbd 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -40,7 +40,7 @@
#define smp_store_release(p, v) \
do { \
compiletime_assert_atomic_type(*p); \
- smp_mb(); \
+ barrier(); \
ACCESS_ONCE(*p) = (v); \
} while (0)
@@ -48,7 +48,7 @@ do { \
({ \
typeof(*p) ___p1 = ACCESS_ONCE(*p); \
compiletime_assert_atomic_type(*p); \
- smp_mb(); \
+ barrier(); \
___p1; \
})
--
1.8.2.2
^ permalink raw reply related
* [PATCH v2 13/15] regulator/mfd: max14577: Export symbols for calculating charger current
From: Lee Jones @ 2014-02-10 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210115928.GF22773@lee--X1>
> > This patch prepares for changing the max14577 charger driver to allow
> > configuring battery-dependent settings from DTS.
> >
> > The patch moves from regulator driver to MFD core driver and exports:
> > - function for calculating register value for charger's current;
> > - table of limits for chargers (MAX14577, MAX77836).
> >
> > Previously they were used only by the max14577 regulator driver. In next
> > patch the charger driver will use them as well. Exporting them will
> > reduce unnecessary code duplication.
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > ---
> > drivers/mfd/max14577.c | 95 ++++++++++++++++++++++++++++++++++
> > drivers/regulator/max14577.c | 80 +++-------------------------
> > include/linux/mfd/max14577-private.h | 22 ++++----
> > include/linux/mfd/max14577.h | 23 ++++++++
> > 4 files changed, 135 insertions(+), 85 deletions(-)
>
> Applied, with Mark's Ack.
Whoops, jumping the gun there. We're still waiting on Acks aren't we.
Instead:
Acked-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops
From: Jean-Francois Moine @ 2014-02-10 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210131233.GT26684@n2100.arm.linux.org.uk>
On Mon, 10 Feb 2014 13:12:33 +0000
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> I've NAK'd these patches already - I believe they're based on a
> mis-understanding of how this should be used. I believe Jean-Francois
> has only looked at the core, rather than looking at the imx-drm example
> it was posted with in an attempt to understand it.
>
> Omitting the component bind operations is absurd because it makes the
> component code completely pointless, since there is then no way to
> control the sequencing of driver initialisation - something which is
> one of the primary reasons for this code existing in the first place.
I perfectly looked at your example and I use it now in my system.
You did not see what could be done with your component code. For
example, since november, I have not yet the clock probe_defer in the
mainline (http://www.spinics.net/lists/arm-kernel/msg306072.html), so,
there are 3 solutions:
- hope the patch will be some day in the mainline and, today, reboot
when the system does not start correctly,
- insert a delay in the tda998x and kirkwood probe sequences (delay
long enough to be sure the si5351 is started, or loop),
- use your component work.
In the last case, it is easy:
- the si5351 driver calls component_add (with empty ops: it has no
interest in the bind/unbind functions) when it is fully started (i.e.
registered - that was the subject of my patch),
- in the DRM driver, look for the si5351 as a clock in the DT (drm ->
encoder -> clock), and add it to the awaited components (CRTCs,
encoders..),
- in the audio subsystem, look for the si5351 as an external clock in
the DT (simple-card -> CPU DAI -> clock) and add it to the awaited
components (CPU and CODEC DAIs - yes, the S/PDIF CODEC should also be
a component with no bin/unbind ops).
Then, when the si5351 is registered, both master components video and
audio can safely run.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH] ARM: mm: add imprecise abort non-deadly handler
From: Dave Martin @ 2014-02-10 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391797214-17142-2-git-send-email-ben.dooks@codethink.co.uk>
On Fri, Feb 07, 2014 at 06:20:14PM +0000, Ben Dooks wrote:
> Given that imprecise aborts may be delivered after the action that
> caused them (or even for non-cpu related activities such as bridge
> faults from a bus-master) it is possible that the wrong process is
> terminated as a result.
>
> It is not know at this time in an SMP system which cores get notified
> of an imprecise external abort, we have yet to find the right details
> in the architecture reference manuals. This also means that killing
> the process is probably the wrong thing to do on reception of these aborts.
>
> Add a handler to take and print imprecise aborts and allow the process
> to continue. This should ensure that the abort is shown but not kill
> the process that was running on the cpu core at the time.
Not treating these as thread-specific faults seems correct, since we
never have a way to map these aborts back to the culprit ... except that
there is a likelihood the culprit is still running when the abort fires.
"Spurious" imprecise aborts pretty much always indicate a hardware error
or a nasty bug somewhere.
Another cause is badly implemented, buggy or malicious userspace software
being given more exotic mmaps that it is qualified to deal with
responsibly. That's a nasty bug in the distro maintainer / system
administrator / vendor.
So, I think this should be at least KERN_ERROR; maybe KERN_CRIT or above.
We must not encourage people to think that these aborts are somehow
benign.
If we really want people to fix their bugs, it may be worth considering
panic(), or doing this when some threshold is reached. This may be a
bit harsh though, at least without some threshold.
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/1] openfirmware: trivial: Standardise formatting of 'struct of_device_id' definition
From: Lee Jones @ 2014-02-10 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390489239-29001-1-git-send-email-lee.jones@linaro.org>
> It's commonly accepted that when defining a struct the '{' is appended
> onto the first line. This helps when searching for the definition using
> syntax similar to 'struct of_device_id {'.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> include/linux/mod_devicetable.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 45e9214..090e014 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -220,8 +220,7 @@ struct serio_device_id {
> /*
> * Struct used for matching a device
> */
> -struct of_device_id
> -{
> +struct of_device_id {
> char name[32];
> char type[32];
> char compatible[128];
Is anyone interested in this patch?
Or should is it okay to just take it through my tree?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [RFC PATCH] ARM: Add imprecise abort enable/disable macro
From: Dave Martin @ 2014-02-10 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210135659.GU26684@n2100.arm.linux.org.uk>
On Mon, Feb 10, 2014 at 01:56:59PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 10, 2014 at 11:17:10AM +0000, Will Deacon wrote:
> > On Mon, Feb 10, 2014 at 08:50:16AM +0000, Fabrice Gasnier wrote:
> > > On 02/07/2014 06:09 PM, Will Deacon wrote:
> > > > On Fri, Feb 07, 2014 at 04:19:15PM +0000, Fabrice GASNIER wrote:
> > > >> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> > > >> index 4636d56..ef15709 100644
> > > >> --- a/arch/arm/kernel/traps.c
> > > >> +++ b/arch/arm/kernel/traps.c
> > > >> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
> > > >>
> > > >> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> > > >> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> > > >> +
> > > >> + /* Enable imprecise aborts */
> > > >> + local_abt_enable();
> > > > Surely we want to enable this as early as possible? Now, putting this into
> > > > head.S is ugly, as it duplicating it across all the proc*.S files, so why
> > > > not setup_arch?
> > > Sorry, I'm not sure to understand your last comment.
> > > At least, I need it enabled before probing drivers (PCIe bus)
> > > I've added imprecise abort enable code in traps.c, following Russel
> > > King's advice, please see:
> > > http://archive.arm.linux.org.uk/lurker/message/20140131.170827.d752a1cc.en.html
> > > As abort bit is local to a cpu, i've also added it in smp.c, but this
> > > may not be the right place ?
> > >
> > > Please elaborate,
> >
> > I was just suggesting that we move your local_abt_enable() call to
> > setup_arch, since that's called before early_trap_init on the primary CPU.
>
> Why would we want to enable aborts before we've setup the vectors page
> to handle an abort? That's akin to enabling interrupts and hoping there
> isn't one pending...
Should we require CPSR.A to me masked in Booting, for all CPUs that have
it?
By definition, we cannot dispatch those exceptions for a while, until
some vectors have been set up; so it makes sense in the same way that
requiring CPSR.[IF] to be set makes sense.
The kernel should do its best to cope anyway, and immediately mask CPSR.A
on entry if it's a v6 or later kernel. safe_svcmode_maskall was
originally intended to do that, but it got watered down to cope with the
Zaurus issues, so it now looks like most code paths don't mask CPSR.A
there. I'm happy to take another look at it.
Cheers
---Dave
^ 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