linux-toradex.git/drivers/pnp, branch v2.6.27.12

pnp: make the resource type an unsigned long

2008-12-13T23:29:34+00:00

commit b563cf59c4d67da7d671788a9848416bfa4180ab upstream.

PnP encodes the resource type directly as its struct resource->flags value
which is an unsigned long.  Make it so...

Signed-off-by: Rene Herman 
Cc: "H. Peter Anvin" 
Acked-by: Bjorn Helgaas 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI : Load device driver according to the status of acpi device

2008-11-20T22:54:49+00:00

commit 39a0ad871000d2a016a4fa113a6e53d22aabf25d upstream.

According to ACPI spec when the status of some device is not present
but functional, the device is valid and the children of this device
should be enumerated. It means that the device should be added to
linux acpi device tree. But the device driver for this device should not
be loaded.
    The detailed info can be found in the section 6.3.7 of ACPI 3.0b spec.
    _STA may return bit 0 clear (not present) with bit 3 set (device is
functional). This case is used to indicate a valid device for which no
device driver should be loaded (for example, a bridge device.).
Children of this device may be present and valid. OS should continue
enumeration below a device whose _STA returns this bit combination

http://bugzilla.kernel.org/show_bug.cgi?id=3358

Signed-off-by: Zhao Yakui 
Signed-off-by: Li Shaohua 
Signed-off-by: Zhang Rui 
Signed-off-by: Andi Kleen 
Signed-off-by: Len Brown 
Cc: Holger Macht 
Signed-off-by: Greg Kroah-Hartman

PNPACPI: ignore the producer/consumer bit for extended IRQ descriptors

2008-08-25T10:04:44+00:00

The Extended Interrupt descriptor has a producer/consumer bit, but
it's not clear what that would mean, and existing BIOSes use the bit
inconsistently. This patch makes Linux PNPACPI ignore the bit.

The ACPI spec contains examples of PCI Interrupt Link devices marked
as ResourceProducers, but many BIOSes mark them as ResourceConsumers.

I also checked with a Windows contact, who said:

Windows uses only "resource consumer" when dealing with
interrupts. There's no useful way of looking at a resource
producer of interrupts.

... NT-based Windows largely infers the producer/consumer stuff
from the device type and ignores the bits in the namespace. This
was necessary because Windows 98 ignored them and early namespaces
contained random junk.

The reason I want to change this is because if PNPACPI devices exclude
ResourceProducer IRQ resources, we can't write PNP drivers for those
devices.

For example, on machines such as the the HP rx7620, rx7640, rx8620,
rx8640, and Superdome, HPET interrupts are ResourceProducers. The
HPET driver currently has to use acpi_bus_register_driver() and do its
own _CRS parsing, even though it requires absolutely no ACPI-specific
functionality.

It would be better if the HPET driver were a PNP driver and took
advantage of the _CRS parsing built into PNPACPI.

This producer/consumer check was originally added here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2b8de5f50e4a302b83ebcd5b0120621336d50bd6

to fix this bug:
http://bugzilla.kernel.org/show_bug.cgi?id=6292

However, the bug was related only to memory and I/O port resources,
where the distinction is sensible and important to Linux. Given that
the distinction is muddled for IRQ resources, I think it was a mistake
to add the check there.

Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen

PNP: fix formatting of dbg_pnp_show_resources() output

2008-08-01T19:46:41+00:00

Each resource should be printed on its own line, so start snprintf'ing
at the beginning of the buffer every time through the loop.

Also, use scnprintf() rather than snprintf() when building up the
buffer to print.  scnprintf() returns the number of characters actually
written into the buffer (not including the trailing NULL).

snprintf() returns the number of characters that *would be* written,
assuming everything would fit in the buffer.  That's nice if we want to
resize the buffer to make sure everything fits, but in this case, I
just want to keep from overflowing the buffer, and it's OK if the
output is truncated.

Using snprintf() meant that my "len" could grow to be more than the
the buffer size, which makes "sizeof(buf) - len" negative, which causes
this alarming WARN_ON:
    http://marc.info/?l=linux-kernel&m=121736480005656&w=2

More useful snprintf/scnprintf discussion:
    http://lwn.net/Articles/69419/

Signed-off-by: Bjorn Helgaas 
Reported-by: Pete Clements 
Cc: Rene Herman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

make pnp_add_card_id() static

2008-07-26T19:00:11+00:00

pnp_add_card_id() can now become static.

Signed-off-by: Adrian Bunk 
Cc: Bjorn Helgaas 
Cc: Rene Herman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

pnp: have quirk_system_pci_resources() include io resources

2008-07-26T19:00:02+00:00

quirk_system_pci_resources() disables a PnP mem resource that overlaps a
PCI BAR so as to not keep the PCI driver from claiming the resource.  Have
it do the same for io resources.

Here, ACPI claims ports that overlap with my soundcard causing the
soundcard driver to fail to load.  It's unknown why my ACPI BIOS claims
those ports; it did not use to but this is not a (kernel) regression.
Some odd BIOS reconfig triggered by temporarily removing the card seems to
have brought this on.

Signed-off-by: Rene Herman 
Acked-by: Bjorn Helgaas 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

pnp: set the pnp_card dma_mask for use by ISAPnP cards

2008-07-26T19:00:02+00:00

dma_alloc_coherent() on x86 currently takes a passed in NULL device
pointer to mean that it should allocate an ISA compatible (24-bit) buffer
which is a bit of a hack.

The ALSA ISA drivers are the main consumers of this but have a struct
device in fact readily available.

For the PnP drivers, the specific pnp_dev->dev device pointer is not
always available at the right time so for now we want to pass the
pnp_card->dev instead which is always available.  Set its dma_mask in
preparation for doing so.

This does not fix a current bug -- 2.6.26-rc1 stumbled over the NULL hack
in dma_alloc_coherent() but this has already been fixed in commit
4a367f3a9dbf2e7ffcee4702203479809236ee6e by Takashi Iwai.

Signed-off-by: Rene Herman 
Acked-by: Bjorn Helgaas 
Acked-by: Takashi Iwai 
Cc: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

PNPACPI: add support for HP vendor-specific CCSR descriptors

2008-07-16T21:27:07+00:00

The HP CCSR descriptor describes MMIO address space that should appear
as a MEM resource.  This patch adds support for parsing these descriptors
in the _CRS data.

The visible effect of this is that these MEM resources will appear
in /sys/devices/pnp0/.../resources, which means that "lspnp -v" will
report it, user applications can use this to locate device CSR space,
and kernel drivers can use the normal PNP resource accessors to
locate them.

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Len Brown 
Signed-off-by: Andi Kleen

PNP: avoid legacy IDE IRQs

2008-07-16T21:27:07+00:00

If an IDE controller is in compatibility mode, it expects to use
IRQs 14 and 15, so PNP should avoid them.

This patch should resolve this problem report:
  parallel driver grabs IRQ14 preventing legacy SFF ATA controller from working
  https://bugzilla.novell.com/show_bug.cgi?id=375836

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Len Brown 
Signed-off-by: Andi Kleen

PNP: convert resource options to single linked list

2008-07-16T21:27:07+00:00

ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.

PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device.  Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:

  dev
    independent options
      ind-io0  -> ind-io1  ...
      ind-mem0 -> ind-mem1 ...
      ...
    dependent option set 0
      dep0-io0  -> dep0-io1  ...
      dep0-mem0 -> dep0-mem1 ...
      ...
    dependent option set 1
      dep1-io0  -> dep1-io1  ...
      dep1-mem0 -> dep1-mem1 ...
      ...
    ...

This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers.  The OS can write the registers in arbitrary order much
like it writes PCI BARs.

However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order.  The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.

This patch replaces the independent and dependent lists with a single
list of options.  For example, a device might have possible resource
settings like this:

  dev
    options
      ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...

All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list.  Each entry
is tagged with an independent/dependent flag.  Dependent entries also
have a "set number" and an optional priority value.  All dependent
entries must be assigned from the same set.  For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.

Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones.  Using the example above, that resulted in a "desired
configuration" list like this:

  ind->io0 -> ind->io1 -> depN-io0 ...

instead of the list the firmware expects, which looks like this:

  ind->io0 -> depN-io0 -> ind-io1 ...

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Andi Kleen 
Acked-by: Rene Herman 
Signed-off-by: Len Brown