can't seem to ignore a battery

can't seem to ignore a battery

[Paul Fox]

i'm hoping someone can explain why my rule containing an
"ignore_device" option for a power_supply device seems to be
ignored.  some sample output from udevadm test, and udevadm are
available here:  http://pastie.org/695548

(it may be that i simply have a gross misunderstanding about
how udev and its clients interact -- this is as deep as i've
ever delved here.)

background:  this is on the OLPC XO-1.5 laptop.  we have a legacy
battery driver that we need to keep running for a while, a) because
it provides some data that our power analysis scripts rely on,
and b) because we don't yet trust the DSDT code that drives the
ACPI driver.

because of the duplicate battery issue (see question #1 of the
g-p-m FAQ) i'd like hal and devkit to simply ignore the legacy
driver.  i can easily fix hal with an fdi snippet, but haven't
figured out how to do the same with devkit-power.  i assumed
using a udev "ignore_device" option would take care of it, but
that's where i'm having trouble.

paul
=---------------------
 paul fox, pgf@laptop.org

Re: can't seem to ignore a battery

[David Zeuthen]

Hey,

On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
> i'm hoping someone can explain why my rule containing an
> "ignore_device" option for a power_supply device seems to be
> ignored.  some sample output from udevadm test, and udevadm are
> available here:  http://pastie.org/695548

Like last_rule (which we covered a few weeks ago), things like
ignore_device probably needs to go (although I haven't thought much
about it and I don't know why it was added - probably a broken driver I
guess). Trying to hide or ignore events at the udev level is just wrong
on a number of levels.

> (it may be that i simply have a gross misunderstanding about
> how udev and its clients interact -- this is as deep as i've
> ever delved here.)
> 
> background:  this is on the OLPC XO-1.5 laptop.  we have a legacy
> battery driver that we need to keep running for a while, a) because
> it provides some data that our power analysis scripts rely on,
> and b) because we don't yet trust the DSDT code that drives the
> ACPI driver.
> 
> because of the duplicate battery issue (see question #1 of the
> g-p-m FAQ) i'd like hal and devkit to simply ignore the legacy
> driver.  i can easily fix hal with an fdi snippet, but haven't
> figured out how to do the same with devkit-power.  i assumed
> using a udev "ignore_device" option would take care of it, but
> that's where i'm having trouble.

You probably want a feature in DeviceKit-power so you can set the udev
property DKP_PRESENTATION_HIDE to 1 so the daemon can convey to users
(such as gnome-power-manager) that a given device should be ignored for
presentation and/or policy.

We have similar things in DeviceKit-disks (such as
DKD_PRESENTATION_HIDE) for this - see the DeviceKit-disks man page for
details. Talk to Richard (Cc'ed) about such a feature?

Thanks,
David

Re: can't seem to ignore a battery

[Richard Hughes]

2009/11/12 David Zeuthen <david@fubar.dk>:
> You probably want a feature in DeviceKit-power so you can set the udev
> property DKP_PRESENTATION_HIDE to 1 so the daemon can convey to users
> (such as gnome-power-manager) that a given device should be ignored for
> presentation and/or policy.

Sure, I would accept a patch for this in DeviceKit-power -- it would
probably be a couple of lines of code.

Richard.

Re: can't seem to ignore a battery

[Paul Fox]

david wrote:
 > Hey,
 > 
 > On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
 > > i'm hoping someone can explain why my rule containing an
 > > "ignore_device" option for a power_supply device seems to be
 > > ignored.  some sample output from udevadm test, and udevadm are
 > > available here:  http://pastie.org/695548
 > 
 > Like last_rule (which we covered a few weeks ago), things like
 > ignore_device probably needs to go (although I haven't thought much
 > about it and I don't know why it was added - probably a broken driver I
 > guess).

from the googling i did while trying to make it work, i'd say
that "ignore_device" seems to be used mostly in cases of broken 
devices that the user wants to pretend don't exist, or to suppress
the mounting of certain partitions that are of zero interest.

 > Trying to hide or ignore events at the udev level is just wrong
 > on a number of levels.

as i said, i don't know much about how udev and its clients are
supposed to interact, so i beg some patience:  i'd think that
quenching unwanted events at the source would be preferable to
having to convince every client to ignore them.  udev has the
ability to do lots of different things with an event.  why
wouldn't "do absolutely nothing" be an interesting option?
(my case seems like a perfect example:  while it might be
preferable to ignore the extra battery at each client, not all
clients currently have that capability.)

paul

 > 
 > > (it may be that i simply have a gross misunderstanding about
 > > how udev and its clients interact -- this is as deep as i've
 > > ever delved here.)
 > > 
 > > background:  this is on the OLPC XO-1.5 laptop.  we have a legacy
 > > battery driver that we need to keep running for a while, a) because
 > > it provides some data that our power analysis scripts rely on,
 > > and b) because we don't yet trust the DSDT code that drives the
 > > ACPI driver.
 > > 
 > > because of the duplicate battery issue (see question #1 of the
 > > g-p-m FAQ) i'd like hal and devkit to simply ignore the legacy
 > > driver.  i can easily fix hal with an fdi snippet, but haven't
 > > figured out how to do the same with devkit-power.  i assumed
 > > using a udev "ignore_device" option would take care of it, but
 > > that's where i'm having trouble.
 > 
 > You probably want a feature in DeviceKit-power so you can set the udev
 > property DKP_PRESENTATION_HIDE to 1 so the daemon can convey to users
 > (such as gnome-power-manager) that a given device should be ignored for
 > presentation and/or policy.
 > 
 > We have similar things in DeviceKit-disks (such as
 > DKD_PRESENTATION_HIDE) for this - see the DeviceKit-disks man page for
 > details. Talk to Richard (Cc'ed) about such a feature?
 > 
 > Thanks,
 > David
 > 

=---------------------
 paul fox, pgf@laptop.org

Re: can't seem to ignore a battery

[David Zeuthen]

On Thu, 2009-11-12 at 17:33 +0000, Richard Hughes wrote:
> 2009/11/12 David Zeuthen <david@fubar.dk>:
> > You probably want a feature in DeviceKit-power so you can set the udev
> > property DKP_PRESENTATION_HIDE to 1 so the daemon can convey to users
> > (such as gnome-power-manager) that a given device should be ignored for
> > presentation and/or policy.
> 
> Sure, I would accept a patch for this in DeviceKit-power -- it would
> probably be a couple of lines of code.

It would probably more than a couple of lines of code - what I was
trying to say was that you want a property on each device object that
e.g. gnome-power-manager can read. And then you need the policy agents
(e.g. g-p-m) use this information.

     David

Re: can't seem to ignore a battery

[Kay Sievers]

On Thu, Nov 12, 2009 at 17:50, David Zeuthen <david@fubar.dk> wrote:
> On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
>> i'm hoping someone can explain why my rule containing an
>> "ignore_device" option for a power_supply device seems to be
>> ignored.  some sample output from udevadm test, and udevadm are
>> available here:  http://pastie.org/695548
>
> Like last_rule (which we covered a few weeks ago), things like
> ignore_device probably needs to go (although I haven't thought much
> about it and I don't know why it was added - probably a broken driver I
> guess). Trying to hide or ignore events at the udev level is just wrong
> on a number of levels.

Yeah, that's the same issue as last_rule. It's really wrong to show
stuff in sysfs which gets enumerated, but to try to suppress such
events at device creation time. All we get from stuff like this is
that the real bugs will not get fixed properly. I'll go and remove
this option.

Kay

Re: can't seem to ignore a battery

[Paul Fox]

kay wrote:
 > On Thu, Nov 12, 2009 at 17:50, David Zeuthen <david@fubar.dk> wrote:
 > > On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
 > >> i'm hoping someone can explain why my rule containing an
 > >> "ignore_device" option for a power_supply device seems to be
 > >> ignored.  some sample output from udevadm test, and udevadm are
 > >> available here:  http://pastie.org/695548
 > >
 > > Like last_rule (which we covered a few weeks ago), things like
 > > ignore_device probably needs to go (although I haven't thought much
 > > about it and I don't know why it was added - probably a broken driver I
 > > guess). Trying to hide or ignore events at the udev level is just wrong
 > > on a number of levels.
 > 
 > Yeah, that's the same issue as last_rule. It's really wrong to show
 > stuff in sysfs which gets enumerated, but to try to suppress such
 > events at device creation time.

can someone point me at a thread that explains why being able to
configure one's system to ignore a device is so plainly wrong? 
i'm clearly missing something.

and, conversely, can someone perhaps tell me why the currently
documented (and clearly at least partially implemented) option
that should let me ignore a device doesn't seem to work?  (my
need for this feature is temporary -- hopefully by the time it's
deprecated in a released udev, similar functionality will have
been recreated (!) in devkit-power, or the XO's need will have
gone away.)

paul
=---------------------
 paul fox, pgf@laptop.org

Re: can't seem to ignore a battery

[Greg KH]

On Thu, Nov 12, 2009 at 09:44:34PM -0500, Paul Fox wrote:
> kay wrote:
>  > On Thu, Nov 12, 2009 at 17:50, David Zeuthen <david@fubar.dk> wrote:
>  > > On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
>  > >> i'm hoping someone can explain why my rule containing an
>  > >> "ignore_device" option for a power_supply device seems to be
>  > >> ignored. ??some sample output from udevadm test, and udevadm are
>  > >> available here: ??http://pastie.org/695548
>  > >
>  > > Like last_rule (which we covered a few weeks ago), things like
>  > > ignore_device probably needs to go (although I haven't thought much
>  > > about it and I don't know why it was added - probably a broken driver I
>  > > guess). Trying to hide or ignore events at the udev level is just wrong
>  > > on a number of levels.
>  > 
>  > Yeah, that's the same issue as last_rule. It's really wrong to show
>  > stuff in sysfs which gets enumerated, but to try to suppress such
>  > events at device creation time.
> 
> can someone point me at a thread that explains why being able to
> configure one's system to ignore a device is so plainly wrong? 
> i'm clearly missing something.

Why is your kernel exporting something that you are trying to ignore?
Just fix your kernel driver and it should be no problem, right?

thanks,

greg k-h

Re: can't seem to ignore a battery

[Kay Sievers]

On Fri, Nov 13, 2009 at 05:54, Greg KH <greg@kroah.com> wrote:
> On Thu, Nov 12, 2009 at 09:44:34PM -0500, Paul Fox wrote:
>> kay wrote:
>>  > On Thu, Nov 12, 2009 at 17:50, David Zeuthen <david@fubar.dk> wrote:
>>  > > On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
>>  > >> i'm hoping someone can explain why my rule containing an
>>  > >> "ignore_device" option for a power_supply device seems to be
>>  > >> ignored. ??some sample output from udevadm test, and udevadm are
>>  > >> available here: ??http://pastie.org/695548
>>  > >
>>  > > Like last_rule (which we covered a few weeks ago), things like
>>  > > ignore_device probably needs to go (although I haven't thought much
>>  > > about it and I don't know why it was added - probably a broken driver I
>>  > > guess). Trying to hide or ignore events at the udev level is just wrong
>>  > > on a number of levels.
>>  >
>>  > Yeah, that's the same issue as last_rule. It's really wrong to show
>>  > stuff in sysfs which gets enumerated, but to try to suppress such
>>  > events at device creation time.
>>
>> can someone point me at a thread that explains why being able to
>> configure one's system to ignore a device is so plainly wrong?
>> i'm clearly missing something.
>
> Why is your kernel exporting something that you are trying to ignore?
> Just fix your kernel driver and it should be no problem, right?

Exactly, we decided not to do this "abstraction game" anymore, and
force to fix the kernel where needed, or fix users to cope with such
things. As sysfs is the primary interface for many device-related
things, including many libudev users, sysfs enumeration will return
all devices in all cases, therefore there is not much point in
suppressing RUN instructions and hoping that this will hide stuff from
users.

"ignore_device" did only suppress the device node creation and RUN
instructions, libudev-events are always sent out unconditionally,
regardless of any rules. It's all from a time as udev was only
managing /dev files, and not all sorts of hotplug setups, today
"ignore_device" is just inconsistent, should not be used, and should
just be removed.

Thanks,
Kay

Re: can't seem to ignore a battery

[Paul Fox]

kay wrote:
 > On Fri, Nov 13, 2009 at 05:54, Greg KH <greg@kroah.com> wrote:
 > > On Thu, Nov 12, 2009 at 09:44:34PM -0500, Paul Fox wrote:
 > >> kay wrote:
 > >>  > On Thu, Nov 12, 2009 at 17:50, David Zeuthen <david@fubar.dk> wrote:
 > >>  > > On Thu, 2009-11-12 at 11:06 -0500, Paul Fox wrote:
 > >>  > >> i'm hoping someone can explain why my rule containing an
 > >>  > >> "ignore_device" option for a power_supply device seems to be
 > >>  > >> ignored. ??some sample output from udevadm test, and udevadm are
 > >>  > >> available here: ??http://pastie.org/695548
 > >>  > >
 > >>  > > Like last_rule (which we covered a few weeks ago), things like
 > >>  > > ignore_device probably needs to go (although I haven't thought much
 > >>  > > about it and I don't know why it was added - probably a broken driver I
 > >>  > > guess). Trying to hide or ignore events at the udev level is just wrong
 > >>  > > on a number of levels.
 > >>  >
 > >>  > Yeah, that's the same issue as last_rule. It's really wrong to show
 > >>  > stuff in sysfs which gets enumerated, but to try to suppress such
 > >>  > events at device creation time.
 > >>
 > >> can someone point me at a thread that explains why being able to
 > >> configure one's system to ignore a device is so plainly wrong?
 > >> i'm clearly missing something.
 > >
 > > Why is your kernel exporting something that you are trying to ignore?
 > > Just fix your kernel driver and it should be no problem, right?
 > 
 > Exactly, we decided not to do this "abstraction game" anymore, and
 > force to fix the kernel where needed, or fix users to cope with such
 > things. As sysfs is the primary interface for many device-related
 > things, including many libudev users, sysfs enumeration will return
 > all devices in all cases, therefore there is not much point in
 > suppressing RUN instructions and hoping that this will hide stuff from
 > users.
 > 
 > "ignore_device" did only suppress the device node creation and RUN
 > instructions, libudev-events are always sent out unconditionally,
 > regardless of any rules. It's all from a time as udev was only

thank you.  i guess this explains the behavior i'm seeing.  i assumed
that ignore_device would cause it to be truly ignored.

clearly we don't _want_ to have two battery drivers for the same
battery.  but neither driver by itself currently fills all of our
current needs, and, given our development schedule, building both
and having the UI layers ignore one of them seemed like the most
expedient, temporary, solution.  we'll have to look at this a
different way.

thanks,
paul

 > managing /dev files, and not all sorts of hotplug setups, today
 > "ignore_device" is just inconsistent, should not be used, and should
 > just be removed.
 > 
 > Thanks,
 > Kay

=---------------------
 paul fox, pgf@laptop.org

Re: can't seem to ignore a battery

[Justin Schoeman]

I am not subscribed to linux-hotplug, but am following this thread on 
the list archive.

This is exactly the problem I am having with my Huawei E220 modem.  (The 
modem has a usb cdrom device with the Windows drivers.) The cdrom 
emulation on the device is broken, so userland attempts to mount the 
device trigger a device reset.

The network operators don't care, because the device works under 
Windows, and that is all they support. So getting the firmware fixed is 
not an option.

The Linux kernel guys do not want to put work arounds for buggy hardware 
(just about every Huawei device type has broken the cdrom/scsi protocol 
in some obscure, but different way) into generic code.  They recommend 
that seeing as the bug is triggered from userspace, it must be fixed in 
userspace.

With HAL, it was a simple one-line fix, and the device was ignored by 
all applications, and everything worked perfectly. Doing the same in 
udev is proving very tricky.

If you can please advise on how to block this in udev, or the correct 
place to add the fix in the userland apps/scripts, I would appreciate it.

Thanks,
Justin

Re: can't seem to ignore a battery

[Greg KH]

On Fri, Nov 13, 2009 at 04:43:35PM +0200, Justin Schoeman wrote:
> I am not subscribed to linux-hotplug, but am following this thread on the 
> list archive.
>
> This is exactly the problem I am having with my Huawei E220 modem.  (The 
> modem has a usb cdrom device with the Windows drivers.) The cdrom emulation 
> on the device is broken, so userland attempts to mount the device trigger a 
> device reset.
>
> The network operators don't care, because the device works under Windows, 
> and that is all they support. So getting the firmware fixed is not an 
> option.

Not true, see the bug on the linux-usb mailing list.  There is a fix
from Huawei for this problem that resolves the issue.  You need to get
the firmware update from your mobile provider, Huawei can not provide it
directly.

So see, fixing firmware by the vendor can happen :)

thanks,

greg k-h

Re: can't seem to ignore a battery

[Greg KH]

On Fri, Nov 13, 2009 at 09:33:06AM -0500, Paul Fox wrote:
> clearly we don't _want_ to have two battery drivers for the same
> battery.  but neither driver by itself currently fills all of our
> current needs, and, given our development schedule, building both
> and having the UI layers ignore one of them seemed like the most
> expedient, temporary, solution.  we'll have to look at this a
> different way.

What specifically do you need done with your driver to get it fixed?
Perhaps if you ask for help with that, you might be able to get it done
for you :)

thanks,

greg k-h

Re: can't seem to ignore a battery

[Justin Schoeman]

Greg KH wrote:
> On Fri, Nov 13, 2009 at 04:43:35PM +0200, Justin Schoeman wrote:
>   
>> I am not subscribed to linux-hotplug, but am following this thread on the 
>> list archive.
>>
>> This is exactly the problem I am having with my Huawei E220 modem.  (The 
>> modem has a usb cdrom device with the Windows drivers.) The cdrom emulation 
>> on the device is broken, so userland attempts to mount the device trigger a 
>> device reset.
>>
>> The network operators don't care, because the device works under Windows, 
>> and that is all they support. So getting the firmware fixed is not an 
>> option.
>>     
>
> Not true, see the bug on the linux-usb mailing list.  There is a fix
> from Huawei for this problem that resolves the issue.  You need to get
> the firmware update from your mobile provider, Huawei can not provide it
> directly.
>
> So see, fixing firmware by the vendor can happen :)
>
> thanks,
>
> greg k-h
>   
Yes, and no.

Huawei has released an update, but our local network provider is showing 
absolutely no inclination to release an update.  I am currently running 
the Maxis firmware which works with the Linux kernel, but doesn't seem 
to get 7.2Mbps anymore - I think this may only be available with the 
'correct' firmware.

I have chatted to the tech support, and they say 'Sorry we only support 
Windows'.  As far as I know, they have no intention of releasing the update.

Thanks,
Justin

Re: can't seem to ignore a battery

[Greg KH]

On Fri, Nov 13, 2009 at 07:29:39PM +0200, Justin Schoeman wrote:
> Huawei has released an update, but our local network provider is showing 
> absolutely no inclination to release an update.  I am currently running the 
> Maxis firmware which works with the Linux kernel, but doesn't seem to get 
> 7.2Mbps anymore - I think this may only be available with the 'correct' 
> firmware.
>
> I have chatted to the tech support, and they say 'Sorry we only support 
> Windows'.  As far as I know, they have no intention of releasing the 
> update.

Sorry to hear this, you might want to dig around, the firmware is
floating around out there :)

thanks,

greg 'google is your friend' k-h

Re: can't seem to ignore a battery

[Justin Schoeman]

Greg KH wrote:
> On Fri, Nov 13, 2009 at 07:29:39PM +0200, Justin Schoeman wrote:
>   
>> Huawei has released an update, but our local network provider is showing 
>> absolutely no inclination to release an update.  I am currently running the 
>> Maxis firmware which works with the Linux kernel, but doesn't seem to get 
>> 7.2Mbps anymore - I think this may only be available with the 'correct' 
>> firmware.
>>
>> I have chatted to the tech support, and they say 'Sorry we only support 
>> Windows'.  As far as I know, they have no intention of releasing the 
>> update.
>>     
>
> Sorry to hear this, you might want to dig around, the firmware is
> floating around out there :)
>
> thanks,
>
> greg 'google is your friend' k-h
>   
As I said, I am running the updated firmware, but it does not have the 
operator specifc extensions for 7.2Mbps support.  We will only get this 
if our network operator ever releases an update.

Anyway, the point I was trying to make is that there are situations when 
you _really_ want to blacklist a device, and it seems to me that udevd 
is the ideal place to do it...

Thanks,
Justin

Re: can't seem to ignore a battery

[Paul Fox]

greg wrote:
 > On Fri, Nov 13, 2009 at 09:33:06AM -0500, Paul Fox wrote:
 > > clearly we don't _want_ to have two battery drivers for the same
 > > battery.  but neither driver by itself currently fills all of our
 > > current needs, and, given our development schedule, building both
 > > and having the UI layers ignore one of them seemed like the most
 > > expedient, temporary, solution.  we'll have to look at this a
 > > different way.
 > 
 > What specifically do you need done with your driver to get it fixed?
 > Perhaps if you ask for help with that, you might be able to get it done
 > for you :)


well, this probably isn't the right list.  but you asked.  :-)

the XO-1 didn't use ACPI under linux.  it did have some minimal
DSDT support in openfirmware to support Windows [1], in the form
of simple battery reporting.  for the XO-1.5, the decision was
made to fully support ACPI, so among other things, yours truly
has been enhancing our DSDT support to support the lid, the ebook
switch, etc, and trying to get the EC events tied in.  one of the
things still on the list is to make the battery support more
correct -- someone tried powertop on a 1.5 XO said it reported 35W
being used.  i don't think that sounds right. :-)  so work needs
to be done there.  if there are any DSDT experts in the house,
i'd love to hear from you, if only for fielding occasional
questions.

the CONFIG_POWER_SUPPLY-based battery driver we used on XO-1
still works fine on XO-1.5, and correctly reports our (accurate)
charge counter, and our (accurate) capacity level.  we need the
charge_counter value in particular, as it's used in all of our
power analysis scripts.  i confess i'm hazy on the details right
now, but the way our charge counting works isn't directly
translatable to the values that ACPI provides -- it's a frame of
reference issue, having to do with where or when "full" is
assumed to be.  richard smith and i have gone through it in the
past -- i just can't remember right now.  eventually we need to
figure out how to get the old values to come out of the new
driver, but this is why i was hoping i could get udev to ignore
the device -- we need it for some specific purposes, but don't
necessarily want most "normal" code to have to deal with it.

i'd actually be tempted to simply use the old battery driver
(i.e., turn off CONFIG_ACPI_BATTERY), but it would of course be
nice if things like powertop and g-p-m worked.  (g-p-m sees the
old driver, but tries to compute the capacity value from values
it doesn't provide, ignoring the capacity value we do provide.)

paul

[1] which, i would like to say for the record, contrary to almost
every news report you'll see, has almost _never_ been run in an
XO laptop deployment, and has _never_ been deployed directly by OLPC.
not that we're sensitive about this, or anything.
=---------------------
 paul fox, pgf@laptop.org

Re: can't seem to ignore a battery

[Greg KH]

On Fri, Nov 13, 2009 at 01:43:44PM -0500, Paul Fox wrote:
> well, this probably isn't the right list.  but you asked.  :-)
> 
> the XO-1 didn't use ACPI under linux.  it did have some minimal
> DSDT support in openfirmware to support Windows [1], in the form
> of simple battery reporting.  for the XO-1.5, the decision was
> made to fully support ACPI, so among other things, yours truly
> has been enhancing our DSDT support to support the lid, the ebook
> switch, etc, and trying to get the EC events tied in.  one of the
> things still on the list is to make the battery support more
> correct -- someone tried powertop on a 1.5 XO said it reported 35W
> being used.  i don't think that sounds right. :-)  so work needs
> to be done there.  if there are any DSDT experts in the house,
> i'd love to hear from you, if only for fielding occasional
> questions.
> 
> the CONFIG_POWER_SUPPLY-based battery driver we used on XO-1
> still works fine on XO-1.5, and correctly reports our (accurate)
> charge counter, and our (accurate) capacity level.  we need the
> charge_counter value in particular, as it's used in all of our
> power analysis scripts.  i confess i'm hazy on the details right
> now, but the way our charge counting works isn't directly
> translatable to the values that ACPI provides -- it's a frame of
> reference issue, having to do with where or when "full" is
> assumed to be.  richard smith and i have gone through it in the
> past -- i just can't remember right now.  eventually we need to
> figure out how to get the old values to come out of the new
> driver, but this is why i was hoping i could get udev to ignore
> the device -- we need it for some specific purposes, but don't
> necessarily want most "normal" code to have to deal with it.
> 
> i'd actually be tempted to simply use the old battery driver
> (i.e., turn off CONFIG_ACPI_BATTERY), but it would of course be
> nice if things like powertop and g-p-m worked.

Well as things will not work properly anyway, I would suggest this
option as well.  It's the easiest for you to do right now, and seems to
solve your root problems until you get your acpi code up and running
properly.

thanks,

greg k-h