Linus Walleij | 1 Sep 01:01 2012

Re: [PATCH 1/2] gpio: mc9s08dz60: Fix build error if I2C=m

On Wed, Aug 29, 2012 at 3:35 AM, Axel Lin <axel.lin <at> gmail.com> wrote:

> Make GPIO_MC9S08DZ60 depend on I2C=y, this fixes below build error:
>
>   LD      init/built-in.o
> drivers/built-in.o: In function `mc9s08dz60_get_value':
> clk-fixed-factor.c:(.text+0x7214): undefined reference to `i2c_smbus_read_byte_data'
> drivers/built-in.o: In function `mc9s08dz60_set':
> clk-fixed-factor.c:(.text+0x727c): undefined reference to `i2c_smbus_read_byte_data'
> clk-fixed-factor.c:(.text+0x72bc): undefined reference to `i2c_smbus_write_byte_data'
> drivers/built-in.o: In function `mc9s08dz60_i2c_driver_init':
> clk-fixed-factor.c:(.init.text+0x290): undefined reference to `i2c_register_driver'
> drivers/built-in.o: In function `mc9s08dz60_i2c_driver_exit':
> clk-fixed-factor.c:(.exit.text+0x2c): undefined reference to `i2c_del_driver'
> make: *** [vmlinux] Error 1
>
> Signed-off-by: Axel Lin <axel.lin <at> gmail.com>

Patch applied.

Freescale folks: yell if you disagree.

Thanks!
Linus Walleij
Picon

rcu_bh stalls on 3.2.28

Just got one of these:

kernel: INFO: rcu_bh detected stall on CPU 2 (t=0 jiffies)
kernel: Pid: 0, comm: swapper/2 Not tainted 3.2.28+ #2
kernel: Call Trace:
kernel: <IRQ>  [<ffffffff810d1609>] __rcu_pending+0x159/0x400
kernel: [<ffffffff810d20bb>] rcu_check_callbacks+0x9b/0x120
kernel: [<ffffffff81089673>] update_process_times+0x43/0x80
kernel: [<ffffffff810a836f>] tick_sched_timer+0x5f/0xb0
kernel: [<ffffffff8109c097>] __run_hrtimer.isra.30+0x57/0x100
kernel: [<ffffffff8109c8f5>] hrtimer_interrupt+0xe5/0x220
kernel: [<ffffffff8104ce14>] smp_apic_timer_interrupt+0x64/0xa0
kernel: [<ffffffff8159b5cb>] apic_timer_interrupt+0x6b/0x70
kernel: <EOI>  [<ffffffff81315645>] ? intel_idle+0xe5/0x140
kernel: [<ffffffff81315623>] ? intel_idle+0xc3/0x140
kernel: [<ffffffff814420ee>] cpuidle_idle_call+0x8e/0xf0
kernel: [<ffffffff81032425>] cpu_idle+0xa5/0x110
kernel: [<ffffffff8158a9ac>] start_secondary+0x1e5/0x1ec

There are previous reports of these weird rcu_bh stalls with t=0 in the 3.2
and 3.3 branches as well:

https://lkml.org/lkml/2012/2/18/34
http://lkml.org/lkml/2012/3/28/175

another data point:
https://bugzilla.redhat.com/show_bug.cgi?id=806610

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
(Continue reading)

Linus Walleij | 1 Sep 01:05 2012

Re: [PATCH 2/2] gpio: mc9s08dz60: Use devm_kzalloc API

On Wed, Aug 29, 2012 at 3:36 AM, Axel Lin <axel.lin <at> gmail.com> wrote:

> Signed-off-by: Axel Lin <axel.lin <at> gmail.com>
> ---
>  drivers/gpio/gpio-mc9s08dz60.c |   21 +++------------------
>  1 file changed, 3 insertions(+), 18 deletions(-)

Patch applied to devel.

Freescale folks, if you prefer to take this into your tree tell me
and I'll take it out.

If you want to explicitly ACK all new Freescale patches,
consider updating MAINTAINERS for this driver.

Yours,
Linus Walleij
Linus Walleij | 1 Sep 01:06 2012

Re: [PATCH] gpio: Remove broken mark for da9052 gpio driver

On Wed, Aug 29, 2012 at 8:57 AM, Axel Lin <axel.lin <at> gmail.com> wrote:

> The fix for MFD part is merged so remove the broken mark for da9052 gpio driver.
>
> Signed-off-by: Axel Lin <axel.lin <at> gmail.com>

OK I trust you on this, patch applied.

Yours,
Linus Walleij
Linus Walleij | 1 Sep 01:14 2012

Re: [PATCH] gpio:clk: preparation for switch to common clock framework

On Thu, Aug 30, 2012 at 8:03 PM, Murali Karicheri <m-karicheri2 <at> ti.com> wrote:

> As a first step towards migrating davinci platforms to use common clock
> framework, replace all instances of clk_enable() with clk_prepare_enable()
> and clk_disable() with clk_disable_unprepare(). Until the platform is
> switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
> adds a might_sleep() call and would work without any issues.
>
> This will make it easy later to switch to common clk based implementation
> of clk driver from DaVinci specific driver.
>
> Signed-off-by: Murali Karicheri <m-karicheri2 <at> ti.com>

OK the patch is so obviously correct so I just applied it, DaVinci folks,
scream if you still don't want it for some reason...

Yours,
Linus Walleij
Linus Walleij | 1 Sep 01:19 2012

Re: [PATCH] gpio: em: Fix checking return value of irq_alloc_descs

On Tue, Aug 28, 2012 at 1:30 PM, Axel Lin <axel.lin <at> gmail.com> wrote:

> irq_alloc_descs() returns negative error code on failure.
>
> Signed-off-by: Axel Lin <axel.lin <at> gmail.com>

Applied with Magnus' ACK.

Yours,
Linus Walleij
Dmitry Torokhov | 1 Sep 01:22 2012
Picon

Re: [PATCH v2] drivers/tty: Folding Android's keyreset driver in sysRQ

On Fri, Aug 31, 2012 at 04:57:04PM -0600, Mathieu Poirier wrote:
> On 12-08-31 04:41 PM, Dmitry Torokhov wrote:
> > On Fri, Aug 31, 2012 at 11:02:27PM +0100, Alan Cox wrote:
> >>>> Why do we need to involve a platform device and not use, for example, a module
> >>>> parameter, that could be set up from userspace?
> >>>
> >>> The platform device comes from the original design and was included to
> >>> minimise the amount of changes in code that make use of the current
> >>> keyreset driver.
> >>
> >> The platform device is IMHO the right answer. In this class of devices
> >> the stuff is compiled in, the userspace is Android, there are no modules
> >> and there is no reason for it to be configurable.
> > 
> > It does not matter if it is built in or not, /sys/module/XXX/parameters
> > is still there, and while havig it in kernel is "easy" you could as
> > easily stuff needed data into a sysfs attribute during booting.
> > 
> > And we should be able to get this from DT even without the platform
> > device (this was the next step, wasn't it?).
> 
> Correct - my hope was to get the main functionality accepted before
> adding DT support.  Do you think the lack of DT support is a blocker for
> acceptance ?  Please confirm.
> 

No, lack of DT is not a blocker, but I am unconvinced that we need
platform device.

Thanks,
(Continue reading)

Linus Walleij | 1 Sep 01:27 2012

Re: [rtc-linux] [PATCH 1/1] drivers/rtc/rtc-ab8500.c: Revoke Device Tree enablement

On Fri, Aug 31, 2012 at 1:08 PM, Lee Jones <lee.jones <at> linaro.org> wrote:
> On Tue, Aug 14, 2012 at 10:32:02AM +0200, Linus Walleij wrote:
>> On Thu, Aug 9, 2012 at 5:57 PM, Lee Jones <lee.jones <at> linaro.org> wrote:
>>
>> > All AB8500 devices are now registered via MFD core, so Device Tree
>> > capability is no longer required for probing. Here we pull the DT
>> > match table to ensure we're no longer probed during Device Tree
>> > start-up.
>> >
>> > CC: Alessandro Zummo <a.zummo <at> towertech.it>
>> > CC: rtc-linux <at> googlegroups.com
>> > Signed-off-by: Lee Jones <lee.jones <at> linaro.org>
>>
>> Acked-by: Linus Walleij <linus.walleij <at> linaro.org>
>
> I'm guessing we still need Alessandro's Ack?

Well, usually we have Andrew Morton merging patches for RTC, so
put him on CC.

If I was the MFD maintainer I'd just merge this though, it's quite
obvious.

Sam: do you agree?

Yours,
Linus Walleij
Linus Walleij | 1 Sep 01:28 2012

Re: [rtc-linux] [PATCH 1/1] drivers/rtc/rtc-ab8500.c: Revoke Device Tree enablement

On Sat, Sep 1, 2012 at 1:27 AM, Linus Walleij <linus.walleij <at> linaro.org> wrote:
> On Fri, Aug 31, 2012 at 1:08 PM, Lee Jones <lee.jones <at> linaro.org> wrote:
>> On Tue, Aug 14, 2012 at 10:32:02AM +0200, Linus Walleij wrote:
>>> On Thu, Aug 9, 2012 at 5:57 PM, Lee Jones <lee.jones <at> linaro.org> wrote:
>>>
>>> > All AB8500 devices are now registered via MFD core, so Device Tree
>>> > capability is no longer required for probing. Here we pull the DT
>>> > match table to ensure we're no longer probed during Device Tree
>>> > start-up.
>>> >
>>> > CC: Alessandro Zummo <a.zummo <at> towertech.it>
>>> > CC: rtc-linux <at> googlegroups.com
>>> > Signed-off-by: Lee Jones <lee.jones <at> linaro.org>
>>>
>>> Acked-by: Linus Walleij <linus.walleij <at> linaro.org>
>>
>> I'm guessing we still need Alessandro's Ack?
>
> Well, usually we have Andrew Morton merging patches for RTC, so
> put him on CC.
>
> If I was the MFD maintainer I'd just merge this though, it's quite
> obvious.
>
> Sam: do you agree?

Or wait, Sam was not on the To: line...

Yours,
Linus Walleij
(Continue reading)

Linus Walleij | 1 Sep 01:32 2012

Re: [PATCH 0/4] clk: Support for smp_twd clock for ux500

On Fri, Aug 31, 2012 at 2:21 PM, Ulf Hansson <ulf.hansson <at> stericsson.com> wrote:

> From: Ulf Hansson <ulf.hansson <at> linaro.org>
>
> To implement support for the smp_twd clock for ux500 several steps
> was needed. This patchseries has also proposed some new changes in the
> common clock core, which the ux500 smp_twd clock definition are
> relying on.

This is a great series,
Acked-by: Linus Walleij <linus.walleij <at> linaro.org>
For the ux500 parts.

Mike it'd be great if you could merge this once you have the semantics
of [1/4] sorted out with Ulf.

Yours,
Linus Walleij

Gmane