[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <01b501cbb6ef$3299f2a0$97cdd7e0$@mprc.pku.edu.cn>
Date: Tue, 18 Jan 2011 17:07:41 +0800
From: "Guan Xuetao" <guanxuetao@...c.pku.edu.cn>
To: "'Paul Mundt'" <lethal@...ux-sh.org>
Cc: <sfr@...b.auug.org.au>, "'Arnd Bergmann'" <arnd@...db.de>,
<gregkh@...e.de>, <jbarnes@...tuousgeek.org>,
<dmitry.torokhov@...il.com>, <dtor@...l.ru>,
<rubini@...l.unipv.it>, <linux-arch@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-fbdev@...r.kernel.org>,
<linux-next@...r.kernel.org>
Subject: RE: Request for unicore32 architecture codes to merge into linux-next
> -----Original Message-----
> From: Paul Mundt [mailto:lethal@...ux-sh.org]
> Sent: Tuesday, January 18, 2011 12:33 PM
> To: Guan Xuetao
> Cc: sfr@...b.auug.org.au; Arnd Bergmann; gregkh@...e.de; jbarnes@...tuousgeek.org; dmitry.torokhov@...il.com; dtor@...l.ru;
> rubini@...l.unipv.it; linux-arch@...r.kernel.org; linux-kernel@...r.kernel.org; linux-fbdev@...r.kernel.org; linux-
> next@...r.kernel.org
> Subject: Re: Request for unicore32 architecture codes to merge into linux-next
>
> On Sun, Jan 16, 2011 at 01:00:31AM +0800, Guan Xuetao wrote:
> > drivers/staging/puv3/Kconfig | 125 ++
> > drivers/staging/puv3/Makefile | 22 +
> > drivers/staging/puv3/TODO | 7 +
> > drivers/staging/puv3/i8042-ucio.h | 89 ++
> > drivers/staging/puv3/puv3-atkbd.h | 43 +
> > drivers/staging/puv3/puv3_ac97.c | 369 +++++
> > drivers/staging/puv3/puv3_i2c.c | 309 ++++
> > drivers/staging/puv3/puv3_pcm.c | 435 ++++++
> > drivers/staging/puv3/puv3_pcm.h | 28 +
> > drivers/staging/puv3/puv3_umal.c | 2069 +++++++++++++++++++++++++
> > drivers/staging/puv3/puv3_unifb.c | 965 ++++++++++++
>
> Staging is not a shortcut around having things reviewed or broken out
> logically. It's of course fine to merge the bulk of things in one go for
> when a new architecture is going on, but logically disparate parts still
> need to be broken out and sent to the proper places for review. It's
> obvious you haven't done this for any of the non-arch bits and hiding
> things under staging is not going to make this step any less necessary.
>
> If you want your framebuffer driver reviewed, then split it out and
> submit it to the linux-fbdev list for review. Once that's had a going
> over and been Acked then of course it can be merged through whatever tree
> you like, and there's even a good chance that you don't need to bother
> with staging at all.
>
> Using staging as a review circumvention measure however is just not going
> to fly.
I understand.
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.
Thanks
Guan Xuetao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists