BUG: sleeping function called from invalid context

BUG: sleeping function called from invalid context

[Amit Virdi]

Hi

I'm testing the driver, based on Linux Kernel 2.6.37, for DICE's Fast 
IrDA controller device. I'm using IrCOMM as the upper IrDA layer and 
using PPP over it.

While testing, I'm getting the following backtrace repeatedly:

=====================================
BUG: sleeping function called from invalid context at 
/data/csd_sw/spear/drives_os/amitvi/spear/kernel/linux-2.6/kernel/mutex.c:85
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Backtrace:
[<c0030b48>] (dump_backtrace+0x0/0x110) from [<c0030c8c>] 
(dump_stack+0x18/0x1c)
  r6:00000000 r5:c725a038 r4:c042c000
[<c0030c74>] (dump_stack+0x0/0x1c) from [<c003b8b4>] 
(__might_sleep+0xc8/0xe8)
[<c003b7ec>] (__might_sleep+0x0/0xe8) from [<c0332bec>] 
(mutex_lock+0x24/0x44)
  r4:c725a038
[<c0332bc8>] (mutex_lock+0x0/0x44) from [<c019f348>] 
(tty_unthrottle+0x1c/0x64)
  r4:c725a000
[<c019f32c>] (tty_unthrottle+0x0/0x64) from [<c0225b08>] 
(ppp_asynctty_receive+0x484/0x4a4)
  r5:c7816000 r4:c726a180
[<c0225684>] (ppp_asynctty_receive+0x0/0x4a4) from [<c030f944>] 
(ircomm_tty_data_indication+0x138/0x184)
[<c030f80c>] (ircomm_tty_data_indication+0x0/0x184) from [<c030c8e8>] 
(ircomm_data_indication+0x7c/0xb4)
  r6:c7011300 r5:c726a900 r4:c7011300
[<c030c86c>] (ircomm_data_indication+0x0/0xb4) from [<c030d31c>] 
(ircomm_process_data+0x110/0x160)
  r5:c726a900 r4:c7011300
[<c030d20c>] (ircomm_process_data+0x0/0x160) from [<c030d6e0>] 
(ircomm_state_conn+0x60/0xec)
  r7:00000000 r6:00000000 r5:c726a900 r4:c7011300
[<c030d680>] (ircomm_state_conn+0x0/0xec) from [<c030d664>] 
(ircomm_do_event+0x6c/0x88)
  r6:c726a900 r5:00000009 r4:00000003
[<c030d5f8>] (ircomm_do_event+0x0/0x88) from [<c030e850>] 
(ircomm_ttp_data_indication+0xbc/0xf4)
  r7:00000002 r6:00000000 r5:c726a900 r4:c7011300
[<c030e794>] (ircomm_ttp_data_indication+0x0/0xf4) from [<c03048c0>] 
(irttp_do_data_indication+0x44/0x8c)
  r5:c726a900 r4:c79f3200
[<c030487c>] (irttp_do_data_indication+0x0/0x8c) from [<c03049b4>] 
(irttp_run_rx_queue+0xac/0x318)
  r6:c726a900 r5:00000000 r4:c79f3200
[<c0304908>] (irttp_run_rx_queue+0x0/0x318) from [<c0306194>] 
(irttp_data_indication+0x90/0xac)
[<c0306104>] (irttp_data_indication+0x0/0xac) from [<c02f8158>] 
(irlmp_data_indication+0x5c/0x60)
  r7:c726a900 r6:c7120022 r5:c71cb300 r4:c726a900
[<c02f80fc>] (irlmp_data_indication+0x0/0x60) from [<c02fad20>] 
(irlmp_link_data_indication+0x2fc/0x35c)
  r5:c72c2280 r4:c71cb300
[<c02faa24>] (irlmp_link_data_indication+0x0/0x35c) from [<c02fc0d4>] 
(irlap_data_indication+0x38/0x3c)
[<c02fc09c>] (irlap_data_indication+0x0/0x3c) from [<c02ff434>] 
(irlap_state_nrm_s+0x208/0x7e0)
  r6:c7214400 r5:00000001 r4:00000010
[<c02ff22c>] (irlap_state_nrm_s+0x0/0x7e0) from [<c02fced8>] 
(irlap_do_event+0x84/0x17c)
[<c02fce54>] (irlap_do_event+0x0/0x17c) from [<c02ffeb0>] 
(irlap_driver_rcv+0x178/0xc34)
  r8:c7214400 r7:c726a900 r6:c78e7800 r5:00000001 r4:00000000
[<c02ffd38>] (irlap_driver_rcv+0x0/0xc34) from [<c0287a3c>] 
(__netif_receive_skb+0x348/0x39c)
  r8:00000000 r7:00001700 r6:c78e7800 r5:c05ee8c4 r4:c726a900
[<c02876f4>] (__netif_receive_skb+0x0/0x39c) from [<c028aec4>] 
(process_backlog+0x8c/0x154)
[<c028ae38>] (process_backlog+0x0/0x154) from [<c028aff8>] 
(net_rx_action+0x6c/0x188)
[<c028af8c>] (net_rx_action+0x0/0x188) from [<c0046f94>] 
(__do_softirq+0x84/0x118)
[<c0046f10>] (__do_softirq+0x0/0x118) from [<c00472a8>] (irq_exit+0x44/0x4c)
[<c0047264>] (irq_exit+0x0/0x4c) from [<c002c080>] (asm_do_IRQ+0x80/0xa0)
[<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb50>] (__irq_svc+0x30/0x80)
Exception stack(0xc042df40 to 0xc042df88)
df40: 00000000 0005317f 0005217f 60000013 c042c000 c042fcdc c046418c 
c042fcd0
df60: 0002661c 41069265 00026580 c042df94 600000d3 c042df88 c002e694 
c002e6a0
df80: 60000013 ffffffff
  r5:f1100000 r4:ffffffff
[<c002e670>] (default_idle+0x0/0x34) from [<c002e458>] (cpu_idle+0x60/0xa4)
[<c002e3f8>] (cpu_idle+0x0/0xa4) from [<c032d5c4>] (rest_init+0x5c/0x74)
  r6:c0027e60 r5:c046415c r4:c0488aa4
[<c032d568>] (rest_init+0x0/0x74) from [<c0008a8c>] 
(start_kernel+0x278/0x2e0)
[<c0008814>] (start_kernel+0x0/0x2e0) from [<00008034>] (0x8034)
=====================================

On analysis, I found that this is due to the change introduced in 
tty_ioctl.c where the termios mutex is taken to protect against parallel 
throttle/unthrottle. Probably IrCOMM stack code wasn't tested before 
merging this patch.

Please suggest what should be done with the IrCOMM protocol stack code 
to resolve this problem?

Thanks
~Amit Virdi

BUG: sleeping function called from invalid context

[Alan Cox]

> On analysis, I found that this is due to the change introduced in 
> tty_ioctl.c where the termios mutex is taken to protect against
> parallel throttle/unthrottle. Probably IrCOMM stack code wasn't
> tested before merging this patch.
> 
> Please suggest what should be done with the IrCOMM protocol stack
> code to resolve this problem?

It looks like the comments are wrong 

        /*
         * Just give it over to the line discipline. There is no need to
         * involve the flip buffers, since we are not running in an
        interrupt
         * handler
         */


appears to be completely untrue

I suspect it just needs to use the tty_flip_buffer functions properly
instead of trying to do clever shortcuts


	tty_insert_flip_string(self->tty, skb->data, skb->len);
	tty_flip_buffer_push(self->tty);

BUG: sleeping function called from invalid context

[Peter Rusko]

Hi all,

While trying to use the LRADC and touchscreen functionality on imx28,
I've run into this problem:

udevd[523]: starting version 171
BUG: sleeping function called from invalid context at kernel/mutex.c:271
in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
no locks held by udevd/523.
irq event stamp: 956
hardirqs last  enabled at (956): [<c032e56c>] 
_raw_write_unlock_irqrestore+0x3c/0x68
hardirqs last disabled at (955): [<c032e6ec>] 
_raw_write_lock_irqsave+0x1c/0x58
softirqs last  enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
[<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>] 
(mutex_lock_nested+0x24/0x31c)
[<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>] 
(clk_enable+0x20/0x48)
[<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>] 
(pl011_console_write+0x20/0x78)
[<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>] 
(__call_console_drivers+0x84/0x9c)
[<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>] 
(console_unlock+0xfc/0x1ec)
[<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>] 
(vprintk+0x3b0/0x440)
[<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
[<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
[<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>] 
(do_sync_write+0x98/0xd4)
[<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>] 
(vfs_write+0xc8/0x138)
[<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
[<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>] 
(ret_fast_syscall+0x0/0x38)

It seems that the printk calls cause the problem (it's not just with 
udev, seems to have the problem with all printk calls). The touchscreen
works perfectly and I'd like to submit a patch which supports it, but I
keep getting the same messages. What can cause the problem, why is it an
atomic context within the udevd?

Regards,
-- 
Rusk? P?ter
Fejleszt?m?rn?k

Prolan Zrt. / Prolan Co.
Hungary 2011 Budakal?sz, Szentendrei ?t 1-3.
Tel./Phone: +36 20 954 3118
Fax: +36 26 540 420
E-mail: rusko.peter at prolan.hu
Web: www.prolan.hu
Timezone:CET

BUG: sleeping function called from invalid context

[Fabio Estevam]

Peter,

On Wed, Nov 23, 2011 at 9:36 AM, Peter Rusko <rusko.peter@prolan.hu> wrote:
> Hi all,
>
> While trying to use the LRADC and touchscreen functionality on imx28,
> I've run into this problem:
>
> udevd[523]: starting version 171
> BUG: sleeping function called from invalid context at kernel/mutex.c:271
> in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
> no locks held by udevd/523.
> irq event stamp: 956
> hardirqs last ?enabled at (956): [<c032e56c>]
> _raw_write_unlock_irqrestore+0x3c/0x68
> hardirqs last disabled at (955): [<c032e6ec>]
> _raw_write_lock_irqsave+0x1c/0x58
> softirqs last ?enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
> softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
> [<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>]
> (mutex_lock_nested+0x24/0x31c)
> [<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>]
> (clk_enable+0x20/0x48)
> [<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>]
> (pl011_console_write+0x20/0x78)
> [<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>]
> (__call_console_drivers+0x84/0x9c)
> [<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>]
> (console_unlock+0xfc/0x1ec)
> [<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>]
> (vprintk+0x3b0/0x440)
> [<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
> [<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
> [<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>]
> (do_sync_write+0x98/0xd4)
> [<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>]
> (vfs_write+0xc8/0x138)
> [<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
> [<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>]
> (ret_fast_syscall+0x0/0x38)
>
> It seems that the printk calls cause the problem (it's not just with udev,
> seems to have the problem with all printk calls). The touchscreen
> works perfectly and I'd like to submit a patch which supports it, but I
> keep getting the same messages. What can cause the problem, why is it an
> atomic context within the udevd?

Looks like the same error I faced before:
http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

Regards,

Fabio Estevam

BUG: sleeping function called from invalid context

[Fabio Estevam]

On Wed, Nov 23, 2011 at 10:44 AM, Fabio Estevam <festevam@gmail.com> wrote:

> Looks like the same error I faced before:
> http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2

Also, can you please try Sascha's imx-features branch?
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=shortlog;h=refs/heads/imx-features

It contains a patch series from Richard Zhao that introduces
clk_prepare that may possibly help with this issue.

BUG: sleeping function called from invalid context

[Uwe Kleine-König]

Hello,

On Wed, Nov 23, 2011 at 10:44:50AM -0200, Fabio Estevam wrote:
> On Wed, Nov 23, 2011 at 9:36 AM, Peter Rusko <rusko.peter@prolan.hu> wrote:
> > While trying to use the LRADC and touchscreen functionality on imx28,
> > I've run into this problem:
> >
> > udevd[523]: starting version 171
> > BUG: sleeping function called from invalid context at kernel/mutex.c:271
> > in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
> > no locks held by udevd/523.
> > irq event stamp: 956
> > hardirqs last ?enabled at (956): [<c032e56c>]
> > _raw_write_unlock_irqrestore+0x3c/0x68
> > hardirqs last disabled at (955): [<c032e6ec>]
> > _raw_write_lock_irqsave+0x1c/0x58
> > softirqs last ?enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
> > softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
> > [<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>]
> > (mutex_lock_nested+0x24/0x31c)
> > [<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>]
> > (clk_enable+0x20/0x48)
> > [<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>]
> > (pl011_console_write+0x20/0x78)
> > [<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>]
> > (__call_console_drivers+0x84/0x9c)
> > [<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>]
> > (console_unlock+0xfc/0x1ec)
> > [<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>]
> > (vprintk+0x3b0/0x440)
> > [<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
> > [<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
> > [<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>]
> > (do_sync_write+0x98/0xd4)
> > [<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>]
> > (vfs_write+0xc8/0x138)
> > [<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
> > [<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>]
> > (ret_fast_syscall+0x0/0x38)
> >
> > It seems that the printk calls cause the problem (it's not just with udev,
> > seems to have the problem with all printk calls). The touchscreen
> > works perfectly and I'd like to submit a patch which supports it, but I
> > keep getting the same messages. What can cause the problem, why is it an
> > atomic context within the udevd?
> 
> Looks like the same error I faced before:
> http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2
which resulted in some concerns about locking correctness. On i.MX28 we
usually use

	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746

(though this patch wasn't accepted either. The right fix is to convert
mxs to the upcoming clk framework, which didn't land into mainline yet.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

BUG: sleeping function called from invalid context

[Russell King - ARM Linux]

On Wed, Nov 23, 2011 at 07:36:40PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Wed, Nov 23, 2011 at 10:44:50AM -0200, Fabio Estevam wrote:
> > Looks like the same error I faced before:
> > http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2
> which resulted in some concerns about locking correctness. On i.MX28 we
> usually use
> 
> 	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746
> 
> (though this patch wasn't accepted either. The right fix is to convert
> mxs to the upcoming clk framework, which didn't land into mainline yet.)

Irrespective of the clk framework.  If you convert to the clk_prepare()
methodology, then you fix this bug.  You can do this as a two-step thing.
First, convert _all_ your drivers to issue the correct clk_prepare() and
clk_unprepare() calls at the appropriate time.  Once that's all done,
convert your clk API implementation to doing the sleeping parts of your
existing clk_enable() in clk_prepare() and leave the non-sleeping parts
in clk_enable().  (Ditto for clk_disable() vs clk_unprepare().)

You'll need to do most of the driver work _before_ the clk framework
lands, because it becomes mandatory for your drivers to call clk_prepare()
with that.

Plus, on the implementation side, you'll already have done the work to
separate the two for the clk framework, which in theory should mean that
its easier to convert.

So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
today - the clk framework is totally irrelevant as far as this goes.

BUG: sleeping function called from invalid context

[Shawn Guo]

Hi Peter,

You can go ahead to submit your LRADC/Touch patches, and I will find
some time to get this fixed following Russell's suggestion.

Regards,
Shawn

On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2011 at 07:36:40PM +0100, Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > On Wed, Nov 23, 2011 at 10:44:50AM -0200, Fabio Estevam wrote:
> > > Looks like the same error I faced before:
> > > http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2
> > which resulted in some concerns about locking correctness. On i.MX28 we
> > usually use
> > 
> > 	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746
> > 
> > (though this patch wasn't accepted either. The right fix is to convert
> > mxs to the upcoming clk framework, which didn't land into mainline yet.)
> 
> Irrespective of the clk framework.  If you convert to the clk_prepare()
> methodology, then you fix this bug.  You can do this as a two-step thing.
> First, convert _all_ your drivers to issue the correct clk_prepare() and
> clk_unprepare() calls at the appropriate time.  Once that's all done,
> convert your clk API implementation to doing the sleeping parts of your
> existing clk_enable() in clk_prepare() and leave the non-sleeping parts
> in clk_enable().  (Ditto for clk_disable() vs clk_unprepare().)
> 
> You'll need to do most of the driver work _before_ the clk framework
> lands, because it becomes mandatory for your drivers to call clk_prepare()
> with that.
> 
> Plus, on the implementation side, you'll already have done the work to
> separate the two for the clk framework, which in theory should mean that
> its easier to convert.
> 
> So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> today - the clk framework is totally irrelevant as far as this goes.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

BUG: sleeping function called from invalid context

[Uwe Kleine-König]

On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2011 at 07:36:40PM +0100, Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > On Wed, Nov 23, 2011 at 10:44:50AM -0200, Fabio Estevam wrote:
> > > Looks like the same error I faced before:
> > > http://marc.info/?l=linux-arm-kernel&m=131914543319956&w=2
> > which resulted in some concerns about locking correctness. On i.MX28 we
> > usually use
> > 
> > 	http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744/focus=100746
> > 
> > (though this patch wasn't accepted either. The right fix is to convert
> > mxs to the upcoming clk framework, which didn't land into mainline yet.)
> 
> Irrespective of the clk framework.  If you convert to the clk_prepare()
> methodology, then you fix this bug.  You can do this as a two-step thing.
Yeah, OK, I should have said:

	The right fix is to make clk_enable atomic on mxs which back
	then was agreed to be done when converting to the new clk
	framework.

> [..]
>
> So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> today - the clk framework is totally irrelevant as far as this goes.
I think doing the clk_prepare seperation and converting to the clk
framework in one step will be easier.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

BUG: sleeping function called from invalid context

[Russell King - ARM Linux]

On Thu, Nov 24, 2011 at 08:14:06AM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> > So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> > today - the clk framework is totally irrelevant as far as this goes.
> I think doing the clk_prepare seperation and converting to the clk
> framework in one step will be easier.

>From a point of view of being able to separate the changes so there isn't
a flag day, you're wrong.  clk_prepare() is already present in the kernel
as dummy functions, and all you need to do at this point is arrange for
the drivers to make the appropriate calls.  There's no need to write one
line of code behind clk_prepare() at the current time.

If you then want to provide a clk_prepare() implementation, then you need
to select CONFIG_HAVE_CLK_PREPARE to prevent the dummy function being
used.

BUG: sleeping function called from invalid context

[Uwe Kleine-König]

On Thu, Nov 24, 2011 at 09:01:41AM +0000, Russell King - ARM Linux wrote:
> On Thu, Nov 24, 2011 at 08:14:06AM +0100, Uwe Kleine-K?nig wrote:
> > On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> > > So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> > > today - the clk framework is totally irrelevant as far as this goes.
> > I think doing the clk_prepare seperation and converting to the clk
> > framework in one step will be easier.
> 
> From a point of view of being able to separate the changes so there isn't
> a flag day, you're wrong.  clk_prepare() is already present in the kernel
> as dummy functions, and all you need to do at this point is arrange for
> the drivers to make the appropriate calls.  There's no need to write one
> line of code behind clk_prepare() at the current time.
Yeah, but adding clk_prepare to the serial driver doesn't help me to get
rid of the BUG reported in this thread without giving it some meaning in
the platform, right?
 
> If you then want to provide a clk_prepare() implementation, then you need
> to select CONFIG_HAVE_CLK_PREPARE to prevent the dummy function being
> used.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

BUG: sleeping function called from invalid context

[Russell King - ARM Linux]

On Thu, Nov 24, 2011 at 10:05:14AM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Nov 24, 2011 at 09:01:41AM +0000, Russell King - ARM Linux wrote:
> > On Thu, Nov 24, 2011 at 08:14:06AM +0100, Uwe Kleine-K?nig wrote:
> > > On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> > > > So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> > > > today - the clk framework is totally irrelevant as far as this goes.
> > > I think doing the clk_prepare seperation and converting to the clk
> > > framework in one step will be easier.
> > 
> > From a point of view of being able to separate the changes so there isn't
> > a flag day, you're wrong.  clk_prepare() is already present in the kernel
> > as dummy functions, and all you need to do at this point is arrange for
> > the drivers to make the appropriate calls.  There's no need to write one
> > line of code behind clk_prepare() at the current time.
> Yeah, but adding clk_prepare to the serial driver doesn't help me to get
> rid of the BUG reported in this thread without giving it some meaning in
> the platform, right?

So, let's be honest about why this bug isn't being fixed then.  Your
attitude to this problem is ignore it and to do nothing, rather than
trying to fix it via a perfectly good transition path provided for
you.

Okay, now we can see clearly why the bug is still there.  Thanks.

Given such an attitude, remind me why I should care whether iMX breaks
while we do the consolidation and cleanup work to core code, such as
the recent restart changes.

BUG: sleeping function called from invalid context

[Uwe Kleine-König]

On Thu, Nov 24, 2011 at 10:29:09AM +0000, Russell King - ARM Linux wrote:
> On Thu, Nov 24, 2011 at 10:05:14AM +0100, Uwe Kleine-K?nig wrote:
> > On Thu, Nov 24, 2011 at 09:01:41AM +0000, Russell King - ARM Linux wrote:
> > > On Thu, Nov 24, 2011 at 08:14:06AM +0100, Uwe Kleine-K?nig wrote:
> > > > On Wed, Nov 23, 2011 at 10:51:24PM +0000, Russell King - ARM Linux wrote:
> > > > > So really, there's no excuse not to fix this for the imx/mxwhatever SoCs
> > > > > today - the clk framework is totally irrelevant as far as this goes.
> > > > I think doing the clk_prepare seperation and converting to the clk
> > > > framework in one step will be easier.
> > > 
> > > From a point of view of being able to separate the changes so there isn't
> > > a flag day, you're wrong.  clk_prepare() is already present in the kernel
> > > as dummy functions, and all you need to do at this point is arrange for
> > > the drivers to make the appropriate calls.  There's no need to write one
> > > line of code behind clk_prepare() at the current time.
> > Yeah, but adding clk_prepare to the serial driver doesn't help me to get
> > rid of the BUG reported in this thread without giving it some meaning in
> > the platform, right?
Note that I wrote that in reply to you saying "There's no need to write
one line of code behind clk_prepare() at the current time.".

> So, let's be honest about why this bug isn't being fixed then.  Your
> attitude to this problem is ignore it and to do nothing, rather than
> trying to fix it via a perfectly good transition path provided for
> you.
I don't think the mxs clock code needs a transition. I guess it will be
mostly reimplemented when the clk framework is settled. And I consider
it quite normal to live with code that is not optimal because there are
bigger changes in the queue that would make fixing the current code
useless. 
 
> Okay, now we can see clearly why the bug is still there.  Thanks.
> 
> Given such an attitude, remind me why I should care whether iMX breaks
> while we do the consolidation and cleanup work to core code, such as
> the recent restart changes.
There are several active contributors to i.MX that invest much time to
adapt i.MX to the current changes. Be it Shawn who does much DT stuff,
Sascha who proposed things for the clk framework or Richard who
converted i.MX5x to the the latest clk framework patches. That's why you
should care. And that is independant of me not doing much for i.MX
during the last few cycles.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |