Re: [PATCH] drivers/char/sonypi.c: fix ids member of structacpi_driver

[Mattia Dongili]

On Thu, Aug 02, 2007 at 09:50:18AM +0200, Thomas Renninger wrote:
> On Thu, 2007-08-02 at 15:40 +0900, Mattia Dongili wrote:
> > On Wed, Aug 01, 2007 at 05:15:34PM +0800, Eugene Teo wrote:
> > > ids member of struct acpi_driver is of type struct acpi_device_id, not a
> > > character array.
> > > 
> > > Signed-off-by: Eugene Teo <eugeneteo@xxxxxxxxx>
> > > ---
> > >  drivers/char/sonypi.c |    8 +++++++-
> > >  1 files changed, 7 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c
> > > index 73037a4..ac0aeb0 100644
> > > --- a/drivers/char/sonypi.c
> > > +++ b/drivers/char/sonypi.c
> > > @@ -1147,10 +1147,16 @@ static int sonypi_acpi_remove(struct acpi_device *device, int type)
> > >  	return 0;
> > >  }
> > >  
> > > +const static struct acpi_device_id sonypi_device_ids[] = {
> > > +	{"SNY6001", 0},
> > > +	{"", 0},
> > > +};
> > > +MODULE_DEVICE_TABLE(acpi, sonypi_device_ids);
> > 
> > how does it behave with the already existing id in sony-laptop?
> > I'd rather avoid the MODULE_DEVICE_TABLE for sonypi allowing sony-laptop
> > to take over automagically.
> 
> Yes, sounds reasonable.
> The patch is needed, but MODULE_DEVICE_TABLE should be ripped out.
> AFAIK sonypi and sony-laptop cannot coexist together. But sony-acpi
> should be preferred. If someone needs sonypi, he needs to blacklist
> sony-apci in modprobe.conf and load sonypi manually.

Yes, that's what I meant.

> Shouldn't sony-acpi replace sonypi on longterm or at least addtional
> "SNY6001" functionality be merged to sony-acpi? Having two drivers for
> the same device is not a good idea.

yep, sony-laptop will replace sonypi. It still has some problems but
development is progressing in sony-laptop, not sonypi.

Eugene, I'll import the patch without the MODULE_DEVICE_TABLE line.
cheers
-- 
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/