acpi_pci_allocate_irq() and acpi_pci_free_irq() are trivial and
only used once, so just open-code them.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Remove unused "irq" field, remove unnecessary struct,
rename "handle" to "link".
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

We don't need a struct containing a count and a list_head; a simple
list_head is sufficient.  The list iterators handle empty lists
fine.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This folds acpi_pci_irq_derive() into acpi_pci_irq_lookup() so it
can be easily used by both acpi_pci_irq_enable() and acpi_pci_irq_disable().
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

No functional change; this just uses the typical pattern of
PCI INTx swizzling done on other architectures.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This doesn't change anything functionally; it just changes tests
so we test for success instead of failure.  This makes the code
read more easily and allows us to remove the "!entry" in the while
loop condition.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

We currently pass a callback function (either acpi_pci_allocate_irq() or
acpi_pci_free_irq()) to acpi_pci_irq_lookup() and acpi_pci_irq_derive().

I think it's simpler to remove the callback and just have the enable/
disable functions make the calls directly.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Print one message (either "found" or "not found") for every _PRT
search.  And add pin information to the INTx swizzling debug.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

There's no reason to pass around segment, bus, and device independently
when we can just pass the pci_dev pointer, which carries all those
already.

The pci_dev contains an interrupt pin, too, but we still have to pass both
the pci_dev and the pin because when we use a bridge to derive an IRQ, we
need the pin from the downstream device, not the bridge.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Use the PCI INTx pin encoding (1=INTA, 2=INTB, etc) for _PRT quirks.
Then we can simply compare "entry->pin == quirk->pin".
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch changes pci_irq.c to always use PCI INTx pin encodings
instead of a mix of PCI and _PRT encodings.

The PCI INTx pin numbers from the PCI_INTERRUPT_PIN config register
are 0=device doesn't use interrupts, 1=INTA, ..., 4=INTD.  But the
_PRT table uses 0=INTA, ..., 3=INTD.

This patch converts the _PRT encoding to the PCI encoding immediately
when we add a _PRT entry to the global list.  All the rest of the
code can then use the PCI encoding consistently.

The point of this is to make the interrupt swizzling look the same
as on other architectures, so someday we can unify them.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This adds a helper function to convert INTx pin numbers from the _PRT
(0, 1, 2, 3) to the pin name ('A', 'B', 'C', 'D').
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The struct acpi_prt_entry is used only in pci_irq.c, so there's no
need for the declaration to be public.  This patch moves it into
pci_irq.c.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The interrupt numbers from _PRT entries are GSIs, not Linux IRQs.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

_PRT entries don't contain any useful PCI function information (the
function part of the PCI address is supposed to be 0xffff), and we
don't ever look at it, so this patch just removes the reference to
it.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Previously, acpi_pci_irq_add_prt() did all its own buffer management.
But now that we have ACPI_ALLOCATE_BUFFER, we no longer need to do
that management.  And we don't have to call acpi_get_irq_routing_table()
twice (once to learn the size of the buffer needed, and again to
actually get the table).
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Better to oops and learn about a bug than to silently cover it up.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Use the conventional format for PCI addresses (%04x:%02x:%02x.%d).
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_early_init() was changed to over-write the cmdline param,
making it really inconvenient to set debug flags at boot-time.

Also,
This sets the default level to "info", which is what all the ACPI
drivers use.  So to enable messages from drivers, you only have to
supply the "layer" (a.k.a. "component").  For non-"info" ACPI core
and ACPI interpreter messages, you have to supply both level and
layer masks, as before.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Part of the rfkill initialization was done whenever BT was on or not.  The
following patch checks for BT presence before registering the rfkill to
the input layer.  Some minor cleanups (> 80 char lines) were also added in
the process.

On Tue, Oct 28, 2008 at 10:10:37PM +0300, Andrey Borzenkov wrote:
[...]
> [   66.633036] toshiba_acpi: Toshiba Laptop ACPI Extras version 0.19
> [   66.633054] toshiba_acpi:     HCI method: \_SB_.VALD.GHCI
> [   66.637764] input: Toshiba RFKill Switch as /devices/virtual/input/input3
[...]
> [  113.920753] ------------[ cut here ]------------
> [  113.920828] kernel BUG at /home/bor/src/linux-git/net/rfkill/rfkill.c:347!
> [  113.920845] invalid opcode: 0000 [#1]
> [  113.920877] last sysfs file: /sys/devices/pci0000:00/0000:00:04.0/host0/target0:0:0/0:0:0:0/block/sda/size
> [  113.920900] Dumping ftrace buffer:
> [  113.920919]    (ftrace buffer empty)
> [  113.920933] Modules linked in: af_packet irnet ppp_generic slhc ircomm_tty ircomm binfmt_misc loop dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath dm_mod alim15x3 ide_core nvram toshiba cryptomgr aead crypto_blkcipher michael_mic crypto_algapi orinoco_cs orinoco hermes_dld hermes pcmcia firmware_class snd_ali5451 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device smsc_ircc2 snd_pcm_oss snd_pcm rtc_cmos irda snd_timer snd_mixer_oss rtc_core snd crc_ccitt yenta_socket rtc_lib rsrc_nonstatic i2c_ali1535 pcmcia_core pcspkr psmouse soundcore i2c_core evdev sr_mod snd_page_alloc alim1535_wdt cdrom fan sg video output toshiba_acpi rfkill thermal backlight ali_agp processor ac button input_polldev battery agpgart ohci_hcd usbcore reiserfs pata_ali libata sd_mod scsi_mod [last unloaded: scsi_wait_scan]
> [  113.921765]
> [  113.921785] Pid: 3272, comm: ipolldevd Not tainted (2.6.28-rc2-1avb #3) PORTEGE 4000
> [  113.921801] EIP: 0060:[<dfaa4683>] EFLAGS: 00010246 CPU: 0
> [  113.921854] EIP is at rfkill_force_state+0x53/0x90 [rfkill]
> [  113.921870] EAX: 00000000 EBX: 00000000 ECX: 00000003 EDX: 00000000
> [  113.921885] ESI: 00000000 EDI: ddd50300 EBP: d8d7af40 ESP: d8d7af24
> [  113.921900]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
> [  113.921918] Process ipolldevd (pid: 3272, ti=d8d7a000 task=d8d93c90 task.ti=d8d7a000)
> [  113.921933] Stack:
> [  113.921945]  d8d7af38 00000246 dfb029d8 dfb029c0 dfb029d8 dfb029c0 ddd50300 d8d7af5c
> [  113.922014]  dfb018e2 01000246 01000000 ddd50300 ddd50314 ddabb8a0 d8d7af68 dfb381c1
> [  113.922098]  00000000 d8d7afa4 c012ec0a 00000000 00000002 00000000 c012eba8 ddabb8c0
> [  113.922240] Call Trace:
> [  113.922240]  [<dfb018e2>] ? bt_poll_rfkill+0x5c/0x82 [toshiba_acpi]
> [  113.922240]  [<dfb381c1>] ? input_polled_device_work+0x11/0x40 [input_polldev]
> [  113.922240]  [<c012ec0a>] ? run_workqueue+0xea/0x1f0
> [  113.922240]  [<c012eba8>] ? run_workqueue+0x88/0x1f0
> [  113.922240]  [<dfb381b0>] ? input_polled_device_work+0x0/0x40 [input_polldev]
> [  113.922240]  [<c012f047>] ? worker_thread+0x87/0xf0
> [  113.922240]  [<c0132b00>] ? autoremove_wake_function+0x0/0x50
> [  113.922240]  [<c012efc0>] ? worker_thread+0x0/0xf0
> [  113.922240]  [<c013280f>] ? kthread+0x3f/0x80
> [  113.922240]  [<c01327d0>] ? kthread+0x0/0x80
> [  113.922240]  [<c01040d7>] ? kernel_thread_helper+0x7/0x10
> [  113.922240] Code: 43 54 89 73 54 39 c6 74 11 89 d9 ba 01 00 00 00 b8 40 68 aa df e8 3e 35 69 e0 89 f8 e8 77 fd 85 e0 31 c0 83 c4 10 5b 5e 5f 5d c3 <0f> 0b eb fe 89 f6 8d bc 27 00 00 00 00 be f4 4d aa df bb 5f 01
> [  113.922240] EIP: [<dfaa4683>] rfkill_force_state+0x53/0x90 [rfkill] SS:ESP 0068:d8d7af24
> [  113.924700] ---[ end trace 0e404eb40cadd5f0 ]---
Signed-off-by: NFrederik Deweerdt <frederik.deweerdt@gmail.com>
Tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Acked-by: NLen Brown <len.brown@intel.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Acked-by: NPhilip Langdale <philipl@overt.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 558073dd, along with
the failed try to fix the regression it caused ("ACPI: Fix ACPI battery
regression introduced by commit 558073"), which just made things worse.

Commit aaad0776 (that failed "Fix ACPI
battery regression") got the voltage conversion confused, and fixed the
problem with Rafael's battery monitor apparently just by mistake.

So revert them both, getting us back to the 2.6.27 state in this, and
let's revisit it when people understand what's going on.
Noted-by: NPaul Martin <pm@debian.org>
Requested-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: Len Brown <len.brown@intel.com>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 558073dd ("ACPI: battery: Convert
discharge energy rate to current properly") caused the battery subsystem
to report wrong values of the remaining time on battery power and the
time until fully charged on Toshiba Portege R500 (and presumably on
other boxes too).

Fix the issue by correcting the conversion from mW to mA.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

the toshiba ACPI driver will, in a failure case, free the rfkill state
before stopping the polling timer that would use this state. More interesting,
in the same failure case handling, it calls the exit function, which also
frees the rfkill state, but after stopping the polling.

If the race happens, a NULL pointer is passed to rfkill_force_state()
which then causes a nice dereference.

Fix the race by just not doing the too-early freeing of the rfkill state.

This appears to be the cause of a hot issue on kerneloops.org; while I
have no solid evidence of that this patch will fix the issue, the race
appears rather real.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Linux will continue to ignore OSI(Linux),
except for a white-list containing a few systems.

So delete the black-list,
and stop soliciting user-feedback on the console.
Signed-off-by: NLen Brown <len.brown@intel.com>

Revert "ACPI: don't enable control method power button as wakeup device when Fixed Power button is used"

This reverts commit faee816b.

http://bugzilla.kernel.org/show_bug.cgi?id=12091Signed-off-by: NLen Brown <len.brown@intel.com>

Some Apple boxes evidently require us to set SCI_EN on resume
directly, because if we don't do that, they hung somewhere in the
resume code path.  Moreover, on these boxes it is not sufficient to
use acpi_enable() to turn ACPI on during resume.  All of this is
against the ACPI specification which states that (1) the BIOS is
supposed to return from the S3 sleep state with ACPI enabled
(SCI_EN set) and (2) the SCI_EN bit is owned by the hardware and we
are not supposed to change it.

For this reason, blacklist the affected systems so that the SCI_EN
bit is set during resume on them.

[NOTE: Unconditional setting SCI_EN for all system on resume doesn't
 work, because it makes some other systems crash (that's to be
 expected).  Also, it is not entirely clear right now if all of the
 Apple boxes require this workaround.]

This patch fixes the recent regression tracked as
http://bugzilla.kernel.org/show_bug.cgi?id=12038Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NTino Keitel <tino.keitel@gmx.de>
Tested-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Now I know why I had strange "scheduling in atomic" problems:
acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC
: GFP_KERNEL)... which is (of course) broken.

There's no way to reliably tell if we need GFP_ATOMIC or not from
code, this one for example fails to detect spinlocks held.

Fortunately, allocation seems small enough to be done on stack.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Acked-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI battery interface reports its state either in mW or in mA, and
discharge rate in your case is reported in mW. power_supply interface
does not have such a parameter, so current_now parameter is used
for all cases. But in case of mW, reported discharge should
be converted into mA.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: NFerenc Wagner <wferi@niif.hu>
Signed-off-by: NLen Brown <len.brown@intel.com>

fix 2.6.28 EC interrupt storm regression
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit 0794469d: ("ACPI: struct device -
replace bus_id with dev_name(), dev_set_name()") introduced a bug by
testing 'dev_name(ldev)' instead of 'ldev->bus' for NULL when printing
out the bus information.

So if ldev->bus was NULL, we'd oops.
Reported-and-tested-by: NBruno Prmont <bonbons@linux-vserver.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This removes the acpi_irq_balance_set() interface from the PCI
interrupt link driver.

x86 used acpi_irq_balance_set() to tell the PCI interrupt link
driver to configure links to minimize IRQ sharing.  But the link
driver can easily figure out whether to turn on IRQ balancing
based on the IRQ model (PIC/IOAPIC/etc), so we can get rid of
that external interface.

It's better for the driver to figure this out at init-time.  If
we set it externally via the x86 code, the interface reduces
modularity, and we depend on the fact that acpi_process_madt()
happens before we process the kernel command line.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Referencies: http://bugzilla.kernel.org/show_bug.cgi?id=12004Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=11892Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Disabling gpe might interfere with gpe detection/handling,
thus producing "interrupt not handled" errors.
Ironically, disabling of GPE from interrupt context is already
under spinlock, so only userspace needs to start using it.
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Restart current transaction if we recieved unexpected GPEs instead
of needed ones.

http://bugzilla.kernel.org/show_bug.cgi?id=11896Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

There is a possibility that EC might break if next command is
issued within 1 us after write or burst-disable command.
Suggestd-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Make sure we can tell if the GPE storm workaround gets activated,
and avoid flooding the logs afterwards.

http://bugzilla.kernel.org/show_bug.cgi?id=11841
"plenty of line "ACPI: EC: non-query interrupt received,
 switching to interrupt mode" in dmesg"
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

With the better solution for EC interrupt storm issue,
there is no need to use msleep over udelay.

References:
	http://bugzilla.kernel.org/show_bug.cgi?id=11810
	http://bugzilla.kernel.org/show_bug.cgi?id=10724Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

If an ACPI graphics device supports backlight brightness functions (cmp. with
latest ACPI spec Appendix B), let the ACPI video driver control backlight and
switch backlight control off in vendor specific ACPI drivers (asus_acpi,
thinkpad_acpi, eeepc, fujitsu_laptop, msi_laptop, sony_laptop, acer-wmi).

Currently it is possible to load above drivers and let both poke on the
brightness HW registers, the video and vendor specific ACPI drivers -> bad.

This patch provides the basic support to check for BIOS capabilities before
driver loading time. Driver specific modifications are in separate follow up
patches.

"acpi_backlight=vendor"
	Prever vendor driver over ACPI driver for backlight.
"acpi_backlight=video" (default)
	Prever ACPI driver over vendor driver for backlight.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

This is a reimplemention of commit
0119509c
from Matthew Garrett <mjg59@srcf.ucam.org>

This patch got removed because of a regression: ThinkPads with a
Intel graphics card and an Integrated Graphics Device BIOS implementation
stopped working.
In fact, they only worked because the ACPI device of the discrete, the
wrong one, got used (via int10). So ACPI functions were poking on the wrong
hardware used which is a sever bug.
The next patch provides support for above ThinkPads to be able to
switch brightness via the legacy thinkpad_acpi driver and automatically
detect when to use it.

Original commit message from Matthew Garrett:
    Vendors often ship machines with a choice of integrated or discrete
    graphics, and use the same DSDT for both. As a result, the ACPI video
    module will locate devices that may not exist on this specific platform.
    Attempt to determine whether the device exists or not, and abort the
    device creation if it doesn't.

http://bugzilla.kernel.org/show_bug.cgi?id=9614Signed-off-by: NThomas Renninger <trenn@suse.de>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>