On Sat, Sep 22, 2012 at 06:49:19PM +0800, guanxue...@mprc.pku.edu.cn wrote:
> > On Sat, Sep 22, 2012 at 10:56:30AM +0800, guanxue...@mprc.pku.edu.cn
> > wrote:
> >> > Some of the boilerplate code can be eliminated by using this macro.
> >> The
> >> > driver was previously registered with an arch_in
> On Sat, Sep 22, 2012 at 10:56:30AM +0800, guanxue...@mprc.pku.edu.cn
> wrote:
>> > Some of the boilerplate code can be eliminated by using this macro.
>> The
>> > driver was previously registered with an arch_initcall(), so
>> technically
>> > this is no longer the same, but when the driver is mo
> On Sat, Sep 22, 2012 at 10:56:30AM +0800, guanxue...@mprc.pku.edu.cn
> wrote:
>> > Some of the boilerplate code can be eliminated by using this macro.
>> The
>> > driver was previously registered with an arch_initcall(), so
>> technically
>> > this is no longer the same, but when the driver is mo
On Sat, Sep 22, 2012 at 10:56:30AM +0800, guanxue...@mprc.pku.edu.cn wrote:
> > Some of the boilerplate code can be eliminated by using this macro. The
> > driver was previously registered with an arch_initcall(), so technically
> > this is no longer the same, but when the driver is moved to the PW
> Some of the boilerplate code can be eliminated by using this macro. The
> driver was previously registered with an arch_initcall(), so technically
> this is no longer the same, but when the driver is moved to the PWM
> framework, deferred probing will take care of any driver probe ordering
> issu
Some of the boilerplate code can be eliminated by using this macro. The
driver was previously registered with an arch_initcall(), so technically
this is no longer the same, but when the driver is moved to the PWM
framework, deferred probing will take care of any driver probe ordering
issues.
Signe
6 matches
Mail list logo