lkml.org 
[lkml]   [2011]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Request for unicore32 architecture codes to merge into linux-next
Date


> -----Original Message-----
> From: linux-next-owner@vger.kernel.org [mailto:linux-next-owner@vger.kernel.org] On Behalf Of Paul Mundt
> Sent: Tuesday, January 18, 2011 5:11 PM
> To: Guan Xuetao
> Cc: sfr@canb.auug.org.au; 'Arnd Bergmann'; gregkh@suse.de; jbarnes@virtuousgeek.org; dmitry.torokhov@gmail.com; dtor@mail.ru;
> rubini@cvml.unipv.it; linux-arch@vger.kernel.org; linux-kernel@vger.kernel.org; linux-fbdev@vger.kernel.org; linux-
> next@vger.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
>
> On Tue, Jan 18, 2011 at 05:07:41PM +0800, Guan Xuetao wrote:
> > IMO, the whole architecture specific codes need to be merged first, and only some
> > necessary drivers are included under staging. Then, I could split the staging drivers
> > into corresponding mail-list, and then, additional drivers.
> > Otherwise, there are no architecture basic for drivers review.
> >
> That's of course fine so long as the driver changes are reasonably
> self-contained. The situation we want to avoid is that you end up with
> drivers that depend on some private infrastructure of API where not
> enough context is provided when the two are decoupled.
>
> In any event, the architecture bits are the most self-contained and have
> had the most review of anything in this series of patches, so it probably
> makes sense to work on getting those bits integrated and then dealing
> with the rest incrementally.
Then, I should:
1. merge reviewed arch dir and reviewed drivers (for now, i8042)
2. submit staging drivers to review
Am I right?

Thanks.
Guan Xuetao



\
 
 \ /
  Last update: 2011-01-18 10:37    [W:0.129 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site