* [PATCH 0/2] Uncompress debug for multiplatform
From: Shawn Guo @ 2013-01-28 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128141947.GA11626@S2101-09.ap.freescale.net>
Sorry, Russell. I meant to put your email address on To.
Shawn
On Mon, Jan 28, 2013 at 10:19:51PM +0800, Russell King wrote:
> On Thu, Jan 17, 2013 at 11:21:57PM +0800, Shawn Guo wrote:
> > It's not about running single zImage on multiple platforms with
> > uncompress debug output, but having uncompress debug work for platform
> > that DEBUG_LL is enabled for. But still it's better than nothing.
> >
> > Shawn Guo (2):
> > ARM: use Kconfig to select uncompress.h
> > ARM: use DEBUG_LL infrastructural for multiplatform uncompress debug
>
> Just put them into patch tracker as #7633 and #7634.
>
> Shawn
>
^ permalink raw reply
* [PATCH 14/15] samples/seccomp: be less stupid about cross compiling
From: Will Drewry @ 2013-01-28 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5j+mXCj-cy0Kww4DdeGKOW9qkrL1X92nVJ82Z5q2P8tGpw@mail.gmail.com>
On Tue, Jan 22, 2013 at 3:20 PM, Kees Cook <keescook@chromium.org> wrote:
> On Mon, Jan 21, 2013 at 9:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> The seccomp filters are currently built for the build
>> host, not for the machine that they are going to run
>> on, but they are also built for with the -m32 flag
>> if the kernel is built for a 32 bit machine, both
>> of which seems rather odd.
>>
>> It broke allyesconfig on my machine, which is x86-64, but
>> building for 32 bit ARM, with this error message:
>>
>> In file included from /usr/include/stdio.h:28:0,
>> from samples/seccomp/bpf-fancy.c:15:
>> /usr/include/features.h:324:26: fatal error: bits/predefs.h: No such file or directory
>>
>> because there are no 32 bit libc headers installed on
>> this machine. We should really be building all the
>> samples for the target machine rather than the build
>> host, but since the infrastructure for that appears
>> to be missing right now, let's be a little bit smarter
>> and not pass the '-m32' flag to the HOSTCC when cross-
>> compiling.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: James Morris <james.l.morris@oracle.com>
>
> I'm fine with this. Thanks!
>
> Acked-by: Kees Cook <keescook@chromium.org>
Thanks! This makes a lot of sense and maybe buys a bit more time to
figure out the best way to build these (all?) samples for the target.
Acked-by: Will Drewry <wad@chromium.org>
>
>> ---
>> samples/seccomp/Makefile | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
>> index bbbd276..7203e66 100644
>> --- a/samples/seccomp/Makefile
>> +++ b/samples/seccomp/Makefile
>> @@ -19,6 +19,7 @@ bpf-direct-objs := bpf-direct.o
>>
>> # Try to match the kernel target.
>> ifndef CONFIG_64BIT
>> +ifndef CROSS_COMPILE
>>
>> # s390 has -m31 flag to build 31 bit binaries
>> ifndef CONFIG_S390
>> @@ -35,6 +36,7 @@ HOSTLOADLIBES_bpf-direct += $(MFLAG)
>> HOSTLOADLIBES_bpf-fancy += $(MFLAG)
>> HOSTLOADLIBES_dropper += $(MFLAG)
>> endif
>> +endif
>>
>> # Tell kbuild to always build the programs
>> always := $(hostprogs-y)
>> --
>> 1.7.10.4
>>
>
>
>
> --
> Kees Cook
> Chrome OS Security
^ permalink raw reply
* [PATCH] arm: zynq: Add missing irqchip.h to common.c
From: Michal Simek @ 2013-01-28 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51068861.8060309@gmail.com>
Hi Rob,
2013/1/28 Rob Herring <robherring2@gmail.com>:
> On 01/28/2013 06:30 AM, Michal Simek wrote:
>> The patch: "ARM: use common irqchip_init for GIC init"
>> (sha1: 0529e315bbda5d502c93df2cfafba9bb337fbdf4)
>> should also add linux/irqchip.h header.
>>
>> Error message:
>> arch/arm/mach-zynq/common.c:99:14: error: 'irqchip_init'
>> undeclared here (not in a function)
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>
> FYI, there's already a patch posted for this:
>
> http://www.spinics.net/lists/arm-kernel/msg219556.html
Interesting that I am completely ignored in CC.
Anyway updated maintainer fragment hopefully resolve this.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [PATCH v2 01/16] ARM: introduce common set_auxcr/get_auxcr functions
From: Will Deacon @ 2013-01-28 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359008879-9015-2-git-send-email-nicolas.pitre@linaro.org>
On Thu, Jan 24, 2013 at 06:27:44AM +0000, Nicolas Pitre wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Move the private set_auxcr/get_auxcr functions from
> drivers/cpuidle/cpuidle-calxeda.c so they can be used across platforms.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Acked-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/include/asm/cp15.h | 14 ++++++++++++++
> drivers/cpuidle/cpuidle-calxeda.c | 14 --------------
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> index 5ef4d8015a..ef0094abf2 100644
> --- a/arch/arm/include/asm/cp15.h
> +++ b/arch/arm/include/asm/cp15.h
> @@ -59,6 +59,20 @@ static inline void set_cr(unsigned int val)
> isb();
> }
>
> +static inline unsigned int get_auxcr(void)
> +{
> + unsigned int val;
> + asm("mrc p15, 0, %0, c1, c0, 1 @ get AUXCR" : "=r" (val) : : "cc");
> + return val;
> +}
> +
> +static inline void set_auxcr(unsigned int val)
> +{
> + asm volatile("mcr p15, 0, %0, c1, c0, 1 @ set AUXCR"
> + : : "r" (val) : "cc");
> + isb();
> +}
Oh no! It's the return of the magic "cc" clobber! Could we have an extra
patch to remove those please (since this is just a move)?
Will
^ permalink raw reply
* OMAP baseline test results for v3.8-rc5
From: AnilKumar, Chimata @ 2013-01-28 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA94745@DBDE01.ent.ti.com>
On Mon, Jan 28, 2013 at 17:48:49, Mohammed, Afzal wrote:
> Hi Felipe,
>
> On Mon, Jan 28, 2013 at 17:46:35, Balbi, Felipe wrote:
>
> > didn't help :-s
>
> Hands up :(
Hi Felipe,
Could you please try with any of these options?
1. Change/add mem=512M (should be same value as u-boot printed RAM size) in your
bootargs?
Or
2. set fdt_high 0xffffffff (at u-boot prompt).
Thanks
AnilKumar
^ permalink raw reply
* [PATCH v2 02/16] ARM: b.L: secondary kernel entry code
From: Will Deacon @ 2013-01-28 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359008879-9015-3-git-send-email-nicolas.pitre@linaro.org>
Hi Nicolas,
On Thu, Jan 24, 2013 at 06:27:45AM +0000, Nicolas Pitre wrote:
> CPUs in a big.LITTLE systems have special needs when entering the kernel
> due to a hotplug event, or when resuming from a deep sleep mode.
>
> This is vectorized so multiple CPUs can enter the kernel in parallel
> without serialization.
>
> Only the basic structure is introduced here. This will be extended
> later.
>
> TODO: MPIDR based indexing should eventually be made runtime adjusted.
What's your plan for this TODO? Do you aim to merge the code first and add
that later? If so, maybe add a TODO comment in the code as well?
> diff --git a/arch/arm/common/bL_entry.c b/arch/arm/common/bL_entry.c
> new file mode 100644
> index 0000000000..4e1044612d
> --- /dev/null
> +++ b/arch/arm/common/bL_entry.c
> @@ -0,0 +1,29 @@
> +/*
> + * arch/arm/common/bL_entry.c -- big.LITTLE kernel re-entry point
> + *
> + * Created by: Nicolas Pitre, March 2012
> + * Copyright: (C) 2012-2013 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +
> +#include <asm/bL_entry.h>
Similarly with the naming... was there any consensus to replace bL_ with
something else? I personally find the capitalisation pretty jarring and at
odds with the rest of the kernel, but "bl" is branch-and-link so that's also
not much better.
> diff --git a/arch/arm/include/asm/bL_entry.h b/arch/arm/include/asm/bL_entry.h
> new file mode 100644
> index 0000000000..7525614243
> --- /dev/null
> +++ b/arch/arm/include/asm/bL_entry.h
> @@ -0,0 +1,35 @@
> +/*
> + * arch/arm/include/asm/bL_entry.h
> + *
> + * Created by: Nicolas Pitre, April 2012
> + * Copyright: (C) 2012-2013 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef BL_ENTRY_H
> +#define BL_ENTRY_H
> +
> +#define BL_MAX_CPUS_PER_CLUSTER 4
> +#define BL_MAX_CLUSTERS 2
Again, do you have any ideas/plans on how to remove these constant limits?
Cheers,
Will
^ permalink raw reply
* [v3 2/2] ARM: tegra: Skip scu_enable(scu_base) if not Cortex A9
From: Russell King - ARM Linux @ 2013-01-28 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128091855.9e89d6da79bf5a264449ea5e@nvidia.com>
On Mon, Jan 28, 2013 at 09:18:55AM +0200, Hiroshi Doyu wrote:
> Hi Russell,
>
> On Tue, 22 Jan 2013 18:04:46 +0100
> Olof Johansson <olof@lixom.net> wrote:
>
> > Since Russell had comments on it earlier, I'd like him to give a nod
> > that he's happy with it too.
>
> Is this ok for you?
>
> The original patch is:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/143552.html
Yes, this version is much better, thanks.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
^ permalink raw reply
* [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
From: Russell King - ARM Linux @ 2013-01-28 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51064687.5090605@epfl.ch>
On Mon, Jan 28, 2013 at 10:36:07AM +0100, Florian Vaussard wrote:
> Hello,
>
> Le 28/01/2013 09:45, Peter Ujfalusi a ?crit :
>> hi Thierry,
>>
>> On 01/26/2013 06:40 AM, Thierry Reding wrote:
>>>> +{
>>>> + return pwm->chip->can_sleep;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(pwm_cansleep);
>>>
>>> Would it make sense to check for NULL pointers here? I guess that
>>> passing NULL into the function could be considered a programming error
>>> and an oops would be okay, but in that case there's no point in making
>>> the function return an int. Also see my next comment.
>>
>> While it is unlikely to happen it is better to be safe, something like this
>> will do:
>>
>> return pwm ? pwm->chip->can_sleep : 0;
>>
>
> Ok. And what about:
>
> BUG_ON(pwm == NULL);
> return pwm->chip->can_sleep;
Let's get something straight.
1. Don't use BUG_ON() as some kind of willy nilly assert() replacement.
Linus refused to have assert() in the kernel because assert() gets not
only over-used, but also gets inappropriately used too.
_Only_ _ever_ use BUG_ON() if continuing is going to cause user
noticable data loss which is not reportable to userspace. In other
words, block device queue corruption or the like - where bringing the
system down is going to _save_ the system from itself.
Otherwise, return an error and/or use WARN_ON().
2. If you want a slow kernel, then by all means check your arguments to
your functions. While you're at it, why not check that strings which
are passed contain only the characters you expect them to? And, if
you're bothering to check against a NULL pointer, what about NULL+1
pointers which are also invalid? Why not invent some function to
ensure that the pointer is a valid kernel pointer. Maybe you'll have
to interate the vmalloc lists too - yay, more code to be executed!
That must be good!
In your example, if you're going to check that pwm is non-NULL, what
if pwm->chip is non-NULL? How far do you take this?
Or... just like most of the core kernel does, it does _not_ verify on
function entry that the pointer is "correct" unless it is explicitly
defined that the function may take a NULL pointer (like kfree()).
Everything else just goes right on and does the dereference - and if
the pointer was wrong, we hope that the MMU faults and we get a kernel
oops.
Have a read through the code in fs/ or kernel/ and see how many functions
you can spot in there which validate their pointers which aren't dealing
with data from userland.
You'll find almost no function checking that an inode pointer is not NULL.
Or a struct file pointer. Or a struct path pointer... etc.
Yet, you come to ARM code, and it seems "popular" that pointer arguments
need to be verified on every single function call. Why is this?
I don't know if Andrew would like to inject something here (I've added
him) on this subject...
^ permalink raw reply
* [PATCH 2/2] gpio: pca953x: use managed resources
From: Russell King - ARM Linux @ 2013-01-28 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaEH+hqOo6i+4Lz+T4B+oAvCj+v0Ycr576yV2fWN2VNvg@mail.gmail.com>
On Mon, Jan 28, 2013 at 11:17:48AM +0100, Linus Walleij wrote:
> On Fri, Jan 25, 2013 at 5:59 PM, Gregory CLEMENT
> <gregory.clement@free-electrons.com> wrote:
>
> > From: Linus Walleij <linus.walleij@linaro.org>
> >
> > Using the devm_* managed resources the pca driver can be simplified
> > and cut down on boilerplate code.
> >
> > [gcl: fixed a inccorect reference to a removed label, "goto fail_out"
> > became "return ret"]
>
> Oh now "gcl" means both Grant C. Likely and Gregory CLement :-)
I'd say gcl means Grant C. Likely. gc would be Gregory Clement.
Initials. :) Using anything else results in yet more many namespace
clashes.
Maybe we should switch to a numeric namespace instead? :)
^ permalink raw reply
* [PATCH v2 02/16] ARM: b.L: secondary kernel entry code
From: Nicolas Pitre @ 2013-01-28 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128144604.GC23470@mudshark.cambridge.arm.com>
On Mon, 28 Jan 2013, Will Deacon wrote:
> Hi Nicolas,
>
> On Thu, Jan 24, 2013 at 06:27:45AM +0000, Nicolas Pitre wrote:
> > CPUs in a big.LITTLE systems have special needs when entering the kernel
> > due to a hotplug event, or when resuming from a deep sleep mode.
> >
> > This is vectorized so multiple CPUs can enter the kernel in parallel
> > without serialization.
> >
> > Only the basic structure is introduced here. This will be extended
> > later.
> >
> > TODO: MPIDR based indexing should eventually be made runtime adjusted.
>
> What's your plan for this TODO? Do you aim to merge the code first and add
> that later? If so, maybe add a TODO comment in the code as well?
That should come later as this is probably going to be a non trivial
task. We might also decide that the current code is good enough for now
and it is likely to be the case for a few years.
> > diff --git a/arch/arm/common/bL_entry.c b/arch/arm/common/bL_entry.c
> > new file mode 100644
> > index 0000000000..4e1044612d
> > --- /dev/null
> > +++ b/arch/arm/common/bL_entry.c
> > @@ -0,0 +1,29 @@
> > +/*
> > + * arch/arm/common/bL_entry.c -- big.LITTLE kernel re-entry point
> > + *
> > + * Created by: Nicolas Pitre, March 2012
> > + * Copyright: (C) 2012-2013 Linaro Limited
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/init.h>
> > +
> > +#include <asm/bL_entry.h>
>
> Similarly with the naming... was there any consensus to replace bL_ with
> something else? I personally find the capitalisation pretty jarring and at
> odds with the rest of the kernel, but "bl" is branch-and-link so that's also
> not much better.
I really find the capitalisation incredibly nice and to the point.
There is no better way to unambiguously refer to "big.LITTLE" with a
2-letter prefix.
But as I said, the naming is something I want to change to make this
code appear more generic as there is nothing really b.L specific here.
That is a trivial change, once I'm settled on something.
> > diff --git a/arch/arm/include/asm/bL_entry.h b/arch/arm/include/asm/bL_entry.h
> > new file mode 100644
> > index 0000000000..7525614243
> > --- /dev/null
> > +++ b/arch/arm/include/asm/bL_entry.h
> > @@ -0,0 +1,35 @@
> > +/*
> > + * arch/arm/include/asm/bL_entry.h
> > + *
> > + * Created by: Nicolas Pitre, April 2012
> > + * Copyright: (C) 2012-2013 Linaro Limited
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#ifndef BL_ENTRY_H
> > +#define BL_ENTRY_H
> > +
> > +#define BL_MAX_CPUS_PER_CLUSTER 4
> > +#define BL_MAX_CLUSTERS 2
>
> Again, do you have any ideas/plans on how to remove these constant limits?
Not for the initial merge. Again, this should serve the systems to come
in the next few years just fine. That gives us plenty of time to
enhance this code with proper dynamic allocation.
Nicolas
^ permalink raw reply
* [PATCH 09/30] USB: ehci-omap: Use devm_request_and_ioremap()
From: Alan Stern @ 2013-01-28 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-10-git-send-email-rogerq@ti.com>
On Mon, 28 Jan 2013, Roger Quadros wrote:
> Make use of devm_request_and_ioremap() and correct comment.
Didn't a big patch come through recently converting all usages of
devm_request_and_ioremap() to another function (I forget the name) that
does its own error reporting and returns an ERR_PTR value?
(Checks the mailing list archive...) Ah, here it is:
http://marc.info/?l=linux-usb&m=135876311801537&w=2
And the new function is devm_ioremap_resource(). We should avoid
adding new usages of an old interface.
Alan Stern
^ permalink raw reply
* [PATCH 09/30] USB: ehci-omap: Use devm_request_and_ioremap()
From: Russell King - ARM Linux @ 2013-01-28 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1301281013010.1997-100000@iolanthe.rowland.org>
On Mon, Jan 28, 2013 at 10:17:33AM -0500, Alan Stern wrote:
> On Mon, 28 Jan 2013, Roger Quadros wrote:
>
> > Make use of devm_request_and_ioremap() and correct comment.
>
> Didn't a big patch come through recently converting all usages of
> devm_request_and_ioremap() to another function (I forget the name) that
> does its own error reporting and returns an ERR_PTR value?
>
> (Checks the mailing list archive...) Ah, here it is:
>
> http://marc.info/?l=linux-usb&m=135876311801537&w=2
>
> And the new function is devm_ioremap_resource(). We should avoid
> adding new usages of an old interface.
Maybe... if devm_ioremap_resource() was already in the kernel. The
problem at the moment is it isn't, and it'll probably be rather
horrid for everyone to deal with especially when it comes to testing.
^ permalink raw reply
* [PATCH v2 01/16] ARM: introduce common set_auxcr/get_auxcr functions
From: Nicolas Pitre @ 2013-01-28 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128143904.GB23470@mudshark.cambridge.arm.com>
On Mon, 28 Jan 2013, Will Deacon wrote:
> On Thu, Jan 24, 2013 at 06:27:44AM +0000, Nicolas Pitre wrote:
> > From: Rob Herring <rob.herring@calxeda.com>
> >
> > Move the private set_auxcr/get_auxcr functions from
> > drivers/cpuidle/cpuidle-calxeda.c so they can be used across platforms.
> >
> > Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Acked-by: Tony Lindgren <tony@atomide.com>
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > ---
> > arch/arm/include/asm/cp15.h | 14 ++++++++++++++
> > drivers/cpuidle/cpuidle-calxeda.c | 14 --------------
> > 2 files changed, 14 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/cp15.h b/arch/arm/include/asm/cp15.h
> > index 5ef4d8015a..ef0094abf2 100644
> > --- a/arch/arm/include/asm/cp15.h
> > +++ b/arch/arm/include/asm/cp15.h
> > @@ -59,6 +59,20 @@ static inline void set_cr(unsigned int val)
> > isb();
> > }
> >
> > +static inline unsigned int get_auxcr(void)
> > +{
> > + unsigned int val;
> > + asm("mrc p15, 0, %0, c1, c0, 1 @ get AUXCR" : "=r" (val) : : "cc");
> > + return val;
> > +}
> > +
> > +static inline void set_auxcr(unsigned int val)
> > +{
> > + asm volatile("mcr p15, 0, %0, c1, c0, 1 @ set AUXCR"
> > + : : "r" (val) : "cc");
> > + isb();
> > +}
>
> Oh no! It's the return of the magic "cc" clobber! Could we have an extra
> patch to remove those please (since this is just a move)?
I've removed the CC clobber from my copy of this patch.
Nicolas
^ permalink raw reply
* [PATCH] ARM: davinci: da850: add interrupt-parent property in soc node
From: Sekhar Nori @ 2013-01-28 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359112724-1217-1-git-send-email-prabhakar.lad@ti.com>
On 1/25/2013 4:48 PM, Prabhakar Lad wrote:
> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>
> This patch adds 'interrupt-parent' property in soc node, so that
> the child inherits this property, this avoids adding 'interrupt-parent'
> to each node.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Cc: davinci-linux-open-source at linux.davincidsp.com
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Heiko Schocher <hs@denx.de>
> ---
Looks good to me. Queuing for v3.9. BTW, we are moving the interrupt
parent property to soc node rather than adding it. So, I think a better
headline is "move interrupt-parent property to soc node". I change the
headline while committing.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 10/30] USB: ehci-omap: Use PHY APIs to get the PHY device and put it out of suspend
From: Alan Stern @ 2013-01-28 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-11-git-send-email-rogerq@ti.com>
On Mon, 28 Jan 2013, Roger Quadros wrote:
> For each port that is in PHY mode we obtain a PHY device using the USB PHY
> library and put it out of suspend.
>
> It is upto platform code to associate the PHY to the controller's
> port and it is upto the PHY driver to manage the PHY's resources.
"up to" is two words, not one.
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> drivers/usb/host/ehci-omap.c | 54 ++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 54 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
> index fd2f5450..a35e44e 100644
> --- a/drivers/usb/host/ehci-omap.c
> +++ b/drivers/usb/host/ehci-omap.c
> @@ -70,6 +70,11 @@ static const char hcd_name[] = "ehci-omap";
>
> /*-------------------------------------------------------------------------*/
>
> +struct omap_hcd {
> + struct usb_hcd *hcd;
This pointer is not needed any more.
> + struct usb_phy **phy; /* one PHY for each port */
> + int nports;
Is there a reasonable upper limit on the number of ports? If there is
you could just put a fixed-size array here.
> @@ -233,6 +240,39 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
> hcd->rsrc_len = resource_size(res);
> hcd->regs = regs;
>
> + omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
> + omap->nports = pdata->nports;
> + i = sizeof(struct usb_phy *) * omap->nports;
> + omap->phy = devm_kzalloc(&pdev->dev, i, GFP_KERNEL);
> + if (!omap->phy) {
> + dev_err(dev, "Memory allocation failed\n");
> + return -ENOMEM;
You have to put a "goto" here, not a "return". The hcd must be cleaned
up properly.
> @@ -295,11 +342,18 @@ static int ehci_hcd_omap_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> + struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
What's with the weird spacing in the first two declarations? This
isn't a typeset document where the paragraphs need to be fully
justified. :-)
> + int i;
>
> usb_remove_hcd(hcd);
> disable_put_regulator(dev->platform_data);
> usb_put_hcd(hcd);
This line must be moved down. When the hcd is deallocated, the
omap_hcd structure goes with it.
> + for (i = 0; i < omap->nports; i++) {
> + if (omap->phy[i])
> + usb_phy_shutdown(omap->phy[i]);
> + }
> +
Alan Stern
^ permalink raw reply
* [PATCH] ARM: at91: at91sam9x5: fix usart3 pinctrl name
From: Robert Nelson @ 2013-01-28 15:43 UTC (permalink / raw)
To: linux-arm-kernel
The renaming of pinctrl_uart3 to pinctrl_usart3 was missed in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9e3129e937e2f178d2a003ea45765e5e63e34665
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
---
arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
index 8ecca69..464e34f 100644
--- a/arch/arm/boot/dts/at91sam9x5.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5.dtsi
@@ -197,7 +197,7 @@
};
usart3 {
- pinctrl_uart3: usart3-0 {
+ pinctrl_usart3: usart3-0 {
atmel,pins =
<2 23 0x2 0x1 /* PC22 periph B with pullup */
2 23 0x2 0x0>; /* PC23 periph B */
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 1/3] pwm: Add pwm_cansleep() as exported API to users
From: Florian Vaussard @ 2013-01-28 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128150113.GL23505@n2100.arm.linux.org.uk>
Hello,
Le 28/01/2013 16:01, Russell King - ARM Linux a ?crit :
> On Mon, Jan 28, 2013 at 10:36:07AM +0100, Florian Vaussard wrote:
>> Hello,
>>
>> Le 28/01/2013 09:45, Peter Ujfalusi a ?crit :
>>> hi Thierry,
>>>
>>> On 01/26/2013 06:40 AM, Thierry Reding wrote:
>>>>> +{
>>>>> + return pwm->chip->can_sleep;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(pwm_cansleep);
>>>>
>>>> Would it make sense to check for NULL pointers here? I guess that
>>>> passing NULL into the function could be considered a programming error
>>>> and an oops would be okay, but in that case there's no point in making
>>>> the function return an int. Also see my next comment.
>>>
>>> While it is unlikely to happen it is better to be safe, something like this
>>> will do:
>>>
>>> return pwm ? pwm->chip->can_sleep : 0;
>>>
>>
>> Ok. And what about:
>>
>> BUG_ON(pwm == NULL);
>> return pwm->chip->can_sleep;
>
> Let's get something straight.
>
> 1. Don't use BUG_ON() as some kind of willy nilly assert() replacement.
> Linus refused to have assert() in the kernel because assert() gets not
> only over-used, but also gets inappropriately used too.
>
> _Only_ _ever_ use BUG_ON() if continuing is going to cause user
> noticable data loss which is not reportable to userspace. In other
> words, block device queue corruption or the like - where bringing the
> system down is going to _save_ the system from itself.
>
> Otherwise, return an error and/or use WARN_ON().
>
> 2. If you want a slow kernel, then by all means check your arguments to
> your functions. While you're at it, why not check that strings which
> are passed contain only the characters you expect them to? And, if
> you're bothering to check against a NULL pointer, what about NULL+1
> pointers which are also invalid? Why not invent some function to
> ensure that the pointer is a valid kernel pointer. Maybe you'll have
> to interate the vmalloc lists too - yay, more code to be executed!
> That must be good!
>
> In your example, if you're going to check that pwm is non-NULL, what
> if pwm->chip is non-NULL? How far do you take this?
>
> Or... just like most of the core kernel does, it does _not_ verify on
> function entry that the pointer is "correct" unless it is explicitly
> defined that the function may take a NULL pointer (like kfree()).
> Everything else just goes right on and does the dereference - and if
> the pointer was wrong, we hope that the MMU faults and we get a kernel
> oops.
>
> Have a read through the code in fs/ or kernel/ and see how many functions
> you can spot in there which validate their pointers which aren't dealing
> with data from userland.
>
> You'll find almost no function checking that an inode pointer is not NULL.
> Or a struct file pointer. Or a struct path pointer... etc.
>
> Yet, you come to ARM code, and it seems "popular" that pointer arguments
> need to be verified on every single function call. Why is this?
>
> I don't know if Andrew would like to inject something here (I've added
> him) on this subject...
>
The v3 does not contain the check.
Thank you,
Florian
^ permalink raw reply
* [PATCH] ARM: Dove: convert usb host controller to DT
From: Sebastian Hesselbarth @ 2013-01-28 15:54 UTC (permalink / raw)
To: linux-arm-kernel
With DT support for orion-ehci also convert Dove to it and
remove the legacy calls and clock aliases.
This patch is based on "ARM: Dove: split legacy and DT setup"
applied to mvebu/boards recently.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
arch/arm/boot/dts/dove.dtsi | 16 ++++++++++++++++
arch/arm/mach-dove/board-dt.c | 10 ----------
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 42eac1f..02769a8 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -154,6 +154,22 @@
status = "disabled";
};
+ ehci0: usb-host at 50000 {
+ compatible = "marvell,orion-ehci";
+ reg = <0x50000 0x1000>;
+ interrupts = <24>;
+ clocks = <&gate_clk 0>;
+ status = "okay";
+ };
+
+ ehci1: usb-host at 51000 {
+ compatible = "marvell,orion-ehci";
+ reg = <0x51000 0x1000>;
+ interrupts = <25>;
+ clocks = <&gate_clk 1>;
+ status = "okay";
+ };
+
sdio0: sdio at 92000 {
compatible = "marvell,dove-sdhci";
reg = <0x92000 0x100>;
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index 2310f55..ee11b31 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -34,14 +34,6 @@ static void __init dove_legacy_clk_init(void)
clkspec.np = np;
clkspec.args_count = 1;
- clkspec.args[0] = CLOCK_GATING_BIT_USB0;
- orion_clkdev_add(NULL, "orion-ehci.0",
- of_clk_get_from_provider(&clkspec));
-
- clkspec.args[0] = CLOCK_GATING_BIT_USB1;
- orion_clkdev_add(NULL, "orion-ehci.1",
- of_clk_get_from_provider(&clkspec));
-
clkspec.args[0] = CLOCK_GATING_BIT_GBE;
orion_clkdev_add(NULL, "mv643xx_eth_port.0",
of_clk_get_from_provider(&clkspec));
@@ -79,8 +71,6 @@ static void __init dove_dt_init(void)
/* Internal devices not ported to DT yet */
dove_ge00_init(&dove_dt_ge00_data);
- dove_ehci0_init();
- dove_ehci1_init();
dove_pcie_init(1, 1);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/2] Table lookup for mux clock type
From: Peter De Schrijver @ 2013-01-28 15:54 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds a table lookup feature to the mux clock type. This will
be used by the forthcoming Tegra114 clock implementation. Also instead of
a fixed field width, a mask is used. This is because Tegra114 has some muxes
where the parent selector is spread over several bitfields. The second patch
adapts the tegra periph clock implementation which uses struct clk_mux
directly.
Peter De Schrijver (2):
clk: add table lookup to mux
clk: tegra: adapt tegra periph clk to mux table/mask
drivers/clk/clk-mux.c | 51 ++++++++++++++++++++++++++++++++---------
drivers/clk/tegra/clk.h | 27 +++++++++++++++------
include/linux/clk-private.h | 3 +-
include/linux/clk-provider.h | 9 ++++++-
4 files changed, 69 insertions(+), 21 deletions(-)
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply
* [PATCH 1/2] clk: add table lookup to mux
From: Peter De Schrijver @ 2013-01-28 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359388467-32386-1-git-send-email-pdeschrijver@nvidia.com>
Add a table lookup feature to the mux clock. Also allow arbitrary masks
instead of the width. This will be used by some clocks on Tegra114.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
drivers/clk/clk-mux.c | 51 ++++++++++++++++++++++++++++++++---------
include/linux/clk-private.h | 3 +-
include/linux/clk-provider.h | 9 ++++++-
3 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 508c032..2c98744 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -32,6 +32,7 @@
static u8 clk_mux_get_parent(struct clk_hw *hw)
{
struct clk_mux *mux = to_clk_mux(hw);
+ int num_parents = __clk_get_num_parents(hw->clk);
u32 val;
/*
@@ -42,7 +43,17 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
* val = 0x4 really means "bit 2, index starts at bit 0"
*/
val = readl(mux->reg) >> mux->shift;
- val &= (1 << mux->width) - 1;
+ val &= mux->mask;
+
+ if (mux->table) {
+ int i;
+
+ for (i = 0; i < num_parents; i++)
+ if (mux->table[i] == val)
+ return i;
+ if (i == num_parents)
+ return -EINVAL;
+ }
if (val && (mux->flags & CLK_MUX_INDEX_BIT))
val = ffs(val) - 1;
@@ -50,7 +61,7 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
if (val && (mux->flags & CLK_MUX_INDEX_ONE))
val--;
- if (val >= __clk_get_num_parents(hw->clk))
+ if (val >= num_parents)
return -EINVAL;
return val;
@@ -62,17 +73,22 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
u32 val;
unsigned long flags = 0;
- if (mux->flags & CLK_MUX_INDEX_BIT)
- index = (1 << ffs(index));
+ if (mux->table)
+ index = mux->table[index];
+
+ else {
+ if (mux->flags & CLK_MUX_INDEX_BIT)
+ index = (1 << ffs(index));
- if (mux->flags & CLK_MUX_INDEX_ONE)
- index++;
+ if (mux->flags & CLK_MUX_INDEX_ONE)
+ index++;
+ }
if (mux->lock)
spin_lock_irqsave(mux->lock, flags);
val = readl(mux->reg);
- val &= ~(((1 << mux->width) - 1) << mux->shift);
+ val &= ~(mux->mask << mux->shift);
val |= index << mux->shift;
writel(val, mux->reg);
@@ -88,10 +104,10 @@ const struct clk_ops clk_mux_ops = {
};
EXPORT_SYMBOL_GPL(clk_mux_ops);
-struct clk *clk_register_mux(struct device *dev, const char *name,
+struct clk *clk_register_mux_table(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
- void __iomem *reg, u8 shift, u8 width,
- u8 clk_mux_flags, spinlock_t *lock)
+ void __iomem *reg, u8 shift, u32 mask,
+ u8 clk_mux_flags, u32 *table, spinlock_t *lock)
{
struct clk_mux *mux;
struct clk *clk;
@@ -113,9 +129,10 @@ struct clk *clk_register_mux(struct device *dev, const char *name,
/* struct clk_mux assignments */
mux->reg = reg;
mux->shift = shift;
- mux->width = width;
+ mux->mask = mask;
mux->flags = clk_mux_flags;
mux->lock = lock;
+ mux->table = table;
mux->hw.init = &init;
clk = clk_register(dev, &mux->hw);
@@ -125,3 +142,15 @@ struct clk *clk_register_mux(struct device *dev, const char *name,
return clk;
}
+
+struct clk *clk_register_mux(struct device *dev, const char *name,
+ const char **parent_names, u8 num_parents, unsigned long flags,
+ void __iomem *reg, u8 shift, u8 width,
+ u8 clk_mux_flags, spinlock_t *lock)
+{
+ u32 mask = BIT(width) - 1;
+
+ return clk_register_mux_table(dev, name, parent_names, num_parents,
+ flags, reg, shift, mask, clk_mux_flags,
+ NULL, lock);
+}
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 9c7f580..53d39c2 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -144,12 +144,13 @@ struct clk {
#define DEFINE_CLK_MUX(_name, _parent_names, _parents, _flags, \
_reg, _shift, _width, \
- _mux_flags, _lock) \
+ _mux_flags, _table, _lock) \
static struct clk _name; \
static struct clk_mux _name##_hw = { \
.hw = { \
.clk = &_name, \
}, \
+ .table = _table, \
.reg = _reg, \
.shift = _shift, \
.width = _width, \
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 4989b8a..87a59ff 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -287,8 +287,9 @@ struct clk *clk_register_divider_table(struct device *dev, const char *name,
struct clk_mux {
struct clk_hw hw;
void __iomem *reg;
+ u32 *table;
+ u32 mask;
u8 shift;
- u8 width;
u8 flags;
spinlock_t *lock;
};
@@ -297,11 +298,17 @@ struct clk_mux {
#define CLK_MUX_INDEX_BIT BIT(1)
extern const struct clk_ops clk_mux_ops;
+
struct clk *clk_register_mux(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
void __iomem *reg, u8 shift, u8 width,
u8 clk_mux_flags, spinlock_t *lock);
+struct clk *clk_register_mux_table(struct device *dev, const char *name,
+ const char **parent_names, u8 num_parents, unsigned long flags,
+ void __iomem *reg, u8 shift, u32 mask,
+ u8 clk_mux_flags, u32 *table, spinlock_t *lock);
+
/**
* struct clk_fixed_factor - fixed multiplier and divider clock
*
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* [PATCH 2/2] clk: tegra: adapt tegra periph clk to mux table/mask
From: Peter De Schrijver @ 2013-01-28 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359388467-32386-1-git-send-email-pdeschrijver@nvidia.com>
The tegra peripheral clock type uses struct clk_mux directly, so it needs to
be updated to handle the new mask and table fields. Also the macros need
to be updated
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
drivers/clk/tegra/clk.h | 27 +++++++++++++++++++--------
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 0744731..a09d7dc 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -355,15 +355,16 @@ struct clk *tegra_clk_register_periph_nodiv(const char *name,
struct tegra_clk_periph *periph, void __iomem *clk_base,
u32 offset);
-#define TEGRA_CLK_PERIPH(_mux_shift, _mux_width, _mux_flags, \
+#define TEGRA_CLK_PERIPH(_mux_shift, _mux_mask, _mux_flags, \
_div_shift, _div_width, _div_frac_width, \
_div_flags, _clk_num, _enb_refcnt, _regs, \
- _gate_flags) \
+ _gate_flags, _table) \
{ \
.mux = { \
.flags = _mux_flags, \
.shift = _mux_shift, \
- .width = _mux_width, \
+ .mask = _mux_mask, \
+ .table = _table, \
}, \
.divider = { \
.flags = _div_flags, \
@@ -393,26 +394,36 @@ struct tegra_periph_init_data {
const char *dev_id;
};
-#define TEGRA_INIT_DATA(_name, _con_id, _dev_id, _parent_names, _offset, \
- _mux_shift, _mux_width, _mux_flags, _div_shift, \
+#define TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parent_names, _offset,\
+ _mux_shift, _mux_mask, _mux_flags, _div_shift, \
_div_width, _div_frac_width, _div_flags, _regs, \
- _clk_num, _enb_refcnt, _gate_flags, _clk_id) \
+ _clk_num, _enb_refcnt, _gate_flags, _clk_id, _table) \
{ \
.name = _name, \
.clk_id = _clk_id, \
.parent_names = _parent_names, \
.num_parents = ARRAY_SIZE(_parent_names), \
- .periph = TEGRA_CLK_PERIPH(_mux_shift, _mux_width, \
+ .periph = TEGRA_CLK_PERIPH(_mux_shift, _mux_mask, \
_mux_flags, _div_shift, \
_div_width, _div_frac_width, \
_div_flags, _clk_num, \
_enb_refcnt, _regs, \
- _gate_flags), \
+ _gate_flags, _table), \
.offset = _offset, \
.con_id = _con_id, \
.dev_id = _dev_id, \
}
+#define TEGRA_INIT_DATA(_name, _con_id, _dev_id, _parent_names, _offset,\
+ _mux_shift, _mux_width, _mux_flags, _div_shift, \
+ _div_width, _div_frac_width, _div_flags, _regs, \
+ _clk_num, _enb_refcnt, _gate_flags, _clk_id) \
+ TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parent_names, _offset,\
+ _mux_shift, BIT(_mux_width) - 1, _mux_flags, \
+ _div_shift, _div_width, _div_frac_width, _div_flags, \
+ _regs, _clk_num, _enb_refcnt, _gate_flags, _clk_id,\
+ NULL)
+
/**
* struct clk_super_mux - super clock
*
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* [PATCH v2 10/30] USB: ehci-omap: Use PHY APIs to get the PHY device and put it out of suspend
From: Roger Quadros @ 2013-01-28 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1301281034060.1997-100000@iolanthe.rowland.org>
On 01/28/2013 05:40 PM, Alan Stern wrote:
> On Mon, 28 Jan 2013, Roger Quadros wrote:
>
>> For each port that is in PHY mode we obtain a PHY device using the USB PHY
>> library and put it out of suspend.
>>
>> It is upto platform code to associate the PHY to the controller's
>> port and it is upto the PHY driver to manage the PHY's resources.
>
> "up to" is two words, not one.
right :P
>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/usb/host/ehci-omap.c | 54 ++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 54 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
>> index fd2f5450..a35e44e 100644
>> --- a/drivers/usb/host/ehci-omap.c
>> +++ b/drivers/usb/host/ehci-omap.c
>> @@ -70,6 +70,11 @@ static const char hcd_name[] = "ehci-omap";
>>
>> /*-------------------------------------------------------------------------*/
>>
>> +struct omap_hcd {
>> + struct usb_hcd *hcd;
>
> This pointer is not needed any more.
>
OK.
>> + struct usb_phy **phy; /* one PHY for each port */
>> + int nports;
>
> Is there a reasonable upper limit on the number of ports? If there is
> you could just put a fixed-size array here.
For now there are only 3 which is defined in OMAP3_HS_USB_PORTS.
>
>> @@ -233,6 +240,39 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
>> hcd->rsrc_len = resource_size(res);
>> hcd->regs = regs;
>>
>> + omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
>> + omap->nports = pdata->nports;
>> + i = sizeof(struct usb_phy *) * omap->nports;
>> + omap->phy = devm_kzalloc(&pdev->dev, i, GFP_KERNEL);
>> + if (!omap->phy) {
>> + dev_err(dev, "Memory allocation failed\n");
>> + return -ENOMEM;
>
> You have to put a "goto" here, not a "return". The hcd must be cleaned
> up properly.
good catch!
>
>> @@ -295,11 +342,18 @@ static int ehci_hcd_omap_remove(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> struct usb_hcd *hcd = dev_get_drvdata(dev);
>> + struct omap_hcd *omap = (struct omap_hcd *)hcd_to_ehci(hcd)->priv;
>
> What's with the weird spacing in the first two declarations? This
> isn't a typeset document where the paragraphs need to be fully
> justified. :-)
Funny that it is all over the place ;). I'll fix it around whatever I touch.
>
>> + int i;
>>
>> usb_remove_hcd(hcd);
>> disable_put_regulator(dev->platform_data);
>> usb_put_hcd(hcd);
>
> This line must be moved down. When the hcd is deallocated, the
> omap_hcd structure goes with it.
Good one. Will fix.
>
>> + for (i = 0; i < omap->nports; i++) {
>> + if (omap->phy[i])
>> + usb_phy_shutdown(omap->phy[i]);
>> + }
>> +
>
regards,
-roger
^ permalink raw reply
* [PATCH V2] ARM: davinci: da850: add RTC DT entries
From: Sekhar Nori @ 2013-01-28 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359359268-9781-1-git-send-email-mrugesh.mk@ti.com>
Hi Mrugesh,
On 1/28/2013 1:17 PM, Mrugesh Katepallewar wrote:
> Add RTC DT entries in da850 dts file.
>
> Signed-off-by: Mrugesh Katepallewar <mrugesh.mk@ti.com>
> ---
> Applies on top of v3.8-rc4 of linus tree.
>
> This patch is depending on
> "ARM: davinci: da850: add interrupt-parent property in soc node"
> https://patchwork.kernel.org/patch/2044101/
> Tested on da850-evm device.
>
> Test Procedure:
> date 2013.01.28-10:00:00 (usage: date[YYYY.]MM.DD-hh:mm[:ss])
> hwclock -w
> reset board and check system time.
Queuing this for v3.9. The testing information above is useful and
should be part of the changelog. I moved it there while committing.
It will be nice to check the alarm functionality as well. Can you check
that and let me know that works as well?
Thanks,
Sekhar
^ permalink raw reply
* [GIT PULL V2 2/4] ARM: mvebu: drivers for v3.9
From: Jason Cooper @ 2013-01-28 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fw1la5h7.fsf@laptop.org>
On Mon, Jan 28, 2013 at 06:53:40AM -0500, Chris Ball wrote:
> Hi,
>
> On Mon, Jan 28 2013, Olof Johansson wrote:
> > I didn't see any acks by Chris Ball on these, he's usually pretty
> > responsive on code reviews so I just wanted to make sure he's OK with
> > us taking this through arm-soc, and aware of it.
> >
> > Looks like this whole branch could go through the mmc tree? The dtsi
> > updates from the last branch would still go through arm-soc.
>
> Thanks for the ping, would be good to take these via mmc-next so I've
> pushed the four new mvsdio patches there now:
>
> mmc: mvsdio: add pinctrl integration
> mmc: mvsdio: implement a Device Tree binding
> mmc: mvsdio: use slot-gpio for card detect gpio
> mmc: mvsdio: use slot-gpio infrastructure for write protect gpio
Thanks Chris, I'll redo these and depend on mmc-next at
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
thx,
Jason.
^ permalink raw reply
* [PATCH] ARM: davinci: da850: add interrupt-parent property in soc node
From: Prabhakar Lad @ 2013-01-28 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51069A3A.8090404@ti.com>
Sekhar,
On Mon, Jan 28, 2013 at 9:03 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On 1/25/2013 4:48 PM, Prabhakar Lad wrote:
>> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>>
>> This patch adds 'interrupt-parent' property in soc node, so that
>> the child inherits this property, this avoids adding 'interrupt-parent'
>> to each node.
>>
>> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Cc: davinci-linux-open-source at linux.davincidsp.com
>> Cc: devicetree-discuss at lists.ozlabs.org
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Heiko Schocher <hs@denx.de>
>> ---
>
> Looks good to me. Queuing for v3.9. BTW, we are moving the interrupt
> parent property to soc node rather than adding it. So, I think a better
> headline is "move interrupt-parent property to soc node". I change the
> headline while committing.
>
Thanks for fixing it.
Regards,
--Prabhakar
> Thanks,
> Sekhar
^ 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