On Fri, 15 Feb 2013 00:58:23 +0800, Haojian Zhuang
wrote:
> On 15 February 2013 00:50, Arnd Bergmann wrote:
> > On Thursday 14 February 2013, Haojian Zhuang wrote:
> >> On 14 February 2013 23:57, Arnd Bergmann wrote:
> >> > On Thursday 14 February 2013, Haojian Zhuang wrote:
> >> >> If you can
On Thu, 2013-02-14 at 16:33 +, Grant Likely wrote:
> On Thu, 14 Feb 2013 08:57:17 +0530, anish singh
> wrote:
> > On Thu, Feb 14, 2013 at 3:06 AM, Grant Likely
> > wrote:
> > > static int deferred_probe_initcall(void)
> > > {
> > > deferred_wq = create_singlethread_workqueue("defe
On Thu, 14 Feb 2013 15:57:18 +, Arnd Bergmann wrote:
> On Thursday 14 February 2013, Haojian Zhuang wrote:
> > If you can change it into code in below, it could work. Otherwise, it
> > always fails.
> > driver_deferred_probe_enable = true;
> > driver_deferred_probe_trigger();
>
On Thu, 14 Feb 2013 23:52:14 +0800, Haojian Zhuang
wrote:
> On 14 February 2013 05:36, Grant Likely wrote:
> > On Tue, 12 Feb 2013 10:52:10 +0800, Haojian Zhuang
> > wrote:
> >> On 12 February 2013 07:10, Andrew Morton wrote:
> >> > On Sun, 10 Feb 2013 00:57:57 +0800
> >> > Haojian Zhuang wr
On 15 February 2013 00:50, Arnd Bergmann wrote:
> On Thursday 14 February 2013, Haojian Zhuang wrote:
>> On 14 February 2013 23:57, Arnd Bergmann wrote:
>> > On Thursday 14 February 2013, Haojian Zhuang wrote:
>> >> If you can change it into code in below, it could work. Otherwise, it
>> >> alway
On Thursday 14 February 2013, Haojian Zhuang wrote:
> On 14 February 2013 23:57, Arnd Bergmann wrote:
> > On Thursday 14 February 2013, Haojian Zhuang wrote:
> >> If you can change it into code in below, it could work. Otherwise, it
> >> always fails.
> >> driver_deferred_probe_enable = tr
On Thu, 14 Feb 2013 08:57:17 +0530, anish singh
wrote:
> On Thu, Feb 14, 2013 at 3:06 AM, Grant Likely
> wrote:
> > static int deferred_probe_initcall(void)
> > {
> > deferred_wq = create_singlethread_workqueue("deferwq");
> > if (WARN_ON(!deferred_wq))
> > ret
On 14 February 2013 23:57, Arnd Bergmann wrote:
> On Thursday 14 February 2013, Haojian Zhuang wrote:
>> If you can change it into code in below, it could work. Otherwise, it
>> always fails.
>> driver_deferred_probe_enable = true;
>> driver_deferred_probe_trigger();
>> + defe
On Thursday 14 February 2013, Haojian Zhuang wrote:
> If you can change it into code in below, it could work. Otherwise, it
> always fails.
> driver_deferred_probe_enable = true;
> driver_deferred_probe_trigger();
> + deferred_probe_work_func(NULL);
> return 0;
>
> Bec
On 14 February 2013 05:36, Grant Likely wrote:
> On Tue, 12 Feb 2013 10:52:10 +0800, Haojian Zhuang
> wrote:
>> On 12 February 2013 07:10, Andrew Morton wrote:
>> > On Sun, 10 Feb 2013 00:57:57 +0800
>> > Haojian Zhuang wrote:
>> >
>> >> do_initcalls() could call all driver initialization code
On Thursday 14 February 2013, Russell King - ARM Linux wrote:
> In the general case, that remains true, but it's still not true for
> console drivers.
>
> The console should be initialised before it is attempted to be opened
> before passing control to userspace, which happens before the .init
> s
On Thu, Feb 14, 2013 at 09:56:36AM +, Arnd Bergmann wrote:
> I would put it this way: With the introduction of deferred probing, the
> rules for the use of __init sections have changed slightly for some
> corner cases. While normal device drivers can, as before, not call
> __init functions from
On Thursday 14 February 2013, anish singh wrote:
> Grant, Can you please explain me this problem?My understanding is below:
> If all the detection of devices with there respective driver is done before
> __init section is freed then we will not have the problem mentioned.
> However if the driver re
On Thu, Feb 14, 2013 at 3:06 AM, Grant Likely wrote:
> On Tue, 12 Feb 2013 10:52:10 +0800, Haojian Zhuang
> wrote:
>> On 12 February 2013 07:10, Andrew Morton wrote:
>> > On Sun, 10 Feb 2013 00:57:57 +0800
>> > Haojian Zhuang wrote:
>> >
>> >> do_initcalls() could call all driver initializatio
On Tue, 12 Feb 2013 10:52:10 +0800, Haojian Zhuang
wrote:
> On 12 February 2013 07:10, Andrew Morton wrote:
> > On Sun, 10 Feb 2013 00:57:57 +0800
> > Haojian Zhuang wrote:
> >
> >> do_initcalls() could call all driver initialization code in kernel_init
> >> thread. It means that probe() functi
On 12 February 2013 07:10, Andrew Morton wrote:
> On Sun, 10 Feb 2013 00:57:57 +0800
> Haojian Zhuang wrote:
>
>> do_initcalls() could call all driver initialization code in kernel_init
>> thread. It means that probe() function will be also called from that
>> time. After this, kernel could acces
On Sun, 10 Feb 2013 00:57:57 +0800
Haojian Zhuang wrote:
> do_initcalls() could call all driver initialization code in kernel_init
> thread. It means that probe() function will be also called from that
> time. After this, kernel could access console & release __init section
> in the same thread.
do_initcalls() could call all driver initialization code in kernel_init
thread. It means that probe() function will be also called from that
time. After this, kernel could access console & release __init section
in the same thread.
But if device probe fails and moves into deferred probe list, a ne
18 matches
Mail list logo