[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0705031253140.8342@xplor.biophys.uni-duesseldorf.de>
Date: Thu, 3 May 2007 12:54:21 +0200 (CEST)
From: Michael Schmitz <schmitz@...l.biophys.uni-duesseldorf.de>
To: Christoph Hellwig <hch@...radead.org>
cc: Michael Schmitz <schmitz@...l.biophys.uni-duesseldorf.de>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-m68k@...r.kernel.org, linux-kernel@...r.kernel.org,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Michael Schmitz <schmitz@...ian.org>,
Roman Zippel <zippel@...ux-m68k.org>
Subject: Re: [patch 04/33] m68k: Atari keyboard and mouse support.
> > > What's the reason for splitting this up? Things would be a quite a bit
> > > simpler if all the code was directly in atakeyb.c.
> >
> > Simple: I assumed that keeping the input driver code with the other input
> > stuff was the Right Thing. I can move everything back to atakeyb.c if
> > that's preferred.
>
> I think keeping it all under arch/ makes more sense. drivers/input/
> makes a lot of sense where we have keyboard controllers that are used
> on various architectures with slightly different glue, or different
> controllers for the same busses. IF you have really totally architecture
> specific input devices that require intimate arch knowledge it probably
> makes more sense to keep them there.
The keyboard controller hardware is used nowhere else, so
arch/m68k/atari/atakeyb.c it'll be.
Michael
-
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