Re: question about ruby's keyboard.c & keybdev.c

[Franz S. <Fra...@la...>]

On Samstag, 13. Juli 2002 16:40, Vojtech Pavlik wrote:
> On Sat, Jul 13, 2002 at 04:19:34PM +0200, Franz Sirl wrote:
> > > > Exactly. i8042.c has quite a few assumptions in it. It uses inb/out
> > > > instead of ioremap/readb/writeb, it assumes control and data register
> > > > are 4 addresses apart and it assumes no special sequences are
> > > > necessary to access these registers.
> > >
> > > Some time ago I thought about this when I looked at the sparc i8042
> > > driver. I tried a few things but I didn't come up with a solution.
> >
> > What do you all think about the appended patch? With the strategy in the
> > patch it should be possible to initialize and use i8042 chips on pretty
> > much every platform without code duplication.
> >
> > The patch compiles on PPC (and thus should on x86 too), but I can't test
> > it cause I don't have access to the affected embedded boards.
> >
> > If you like the approach, please apply it to the linux-input repo after
> > testing on x86.
>
> A couple thoughs:
>
> 1) We could as well go back to using the asm/ include way, that way
> we'd have less ifdefs, etc.

I don't think we would have many #ifdefs, hmm. With asm/ we would have 
duplication of the header all over the place with nearly no difference. I 
think in this case the maintainence burden is lower with the #ifdefs.

We could do it like that in i8042.c though:

#include "i8042.h"
#ifdef CONFIG_PPC
#include "i8042-ppc.h"
#endif
#ifndef I8042_HAVE_PLATFORM_INLINES
static inline ....
#endif

That would avoid the generic i8042-io.h header.

Or what about a local i8042.h and a i8042-arch.h in asm/?

Anyway, just massage the patch as you would like it (or tell me exactly what 
solution you want) and push it, I'll send you any missing PPC parts then.

> 2) Do we really want to do all the nasty probing needed on x86 to detect
> the presence of the AUX port, on every arch out there? Well, maybe it
> doesn't hurt ...

It didn't hurt so far with the pc_keyb.c driver, so I guess it's OK. But on 
the other hand it would be no problem to put the AUX probing into another 
inline routine that platforms can override.

Franz.