02 Aug, 2008
1 commit
-
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=2More 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
27 Jul, 2008
3 commits
-
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 -
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 -
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
17 Jul, 2008
28 commits
-
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 -
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=375836Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
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 -
The ISAPNP spec recommends that independent options precede
dependent ones, but this is not actually required. The current
ISAPNP code incorrectly puts such trailing independent options
at the end of the last dependent option list.This patch fixes that bug by resetting the current option list
to the independent list when we see an "End Dependent Functions"
tag. PNPBIOS and PNPACPI handle this the same way.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
When building resource options, ISAPNP and PNPBIOS set the priority
to something like "0x100 | PNP_RES_PRIORITY_ACCEPTABLE", but we
immediately mask off the 0x100 again in pnp_build_option(), so that
bit looks superfluous.Thanks to Rene Herman for pointing this out.
Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
This patch adds an IORESOURCE_IRQ_OPTIONAL flag for use when
assigning resources to a device. If the flag is set and we are
unable to assign an IRQ to the device, we can leave the IRQ
disabled but allow the overall resource allocation to succeed.Some devices request an IRQ, but can run without an IRQ
(possibly with degraded performance). This flag lets us run
the device without the IRQ instead of just leaving the
device disabled.This is a reimplementation of this previous change by Rene
Herman :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b73a223661ed137c5d3d2635f954382e94f5a43I reimplemented this for two reasons:
- to prepare for converting all resource options into a single linked
list, as opposed to the per-resource-type lists we have now, and
- to preserve the order and number of resource options.In PNPBIOS and ACPI, we configure a device by giving firmware a
list of resource assignments. It is important that this list
has exactly the same number of resources, in the same order,
as the "template" list we got from the firmware in the first
place.The problem of a sound card MPU401 being left disabled for want of
an IRQ was reported by Uwe Bugla .Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
No functional change; just rename "data" to something more
descriptive.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
ACPI Extended Interrupt Descriptors can encode 32-bit interrupt
numbers, so an interrupt number may exceed the size of the bitmap
we use to track possible IRQ settings.To avoid corrupting memory, complain and ignore too-large interrupt
numbers.There's similar code in pnpacpi_parse_irq_option(), but I didn't
change that because the small IRQ descriptor can only encode
IRQs 0-15, which do not exceed bitmap size.In the future, we could handle IRQ numbers greater than PNP_IRQ_NR
by replacing the bitmap with a table or list.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
This patch moves all the option allocations (pnp_mem, pnp_port, etc)
into the pnp_register_{mem,port,irq,dma}_resource() functions. This
will make it easier to rework the option data structures.The non-trivial part of this patch is the IRQ handling. The backends
have to allocate a local pnp_irq_mask_t bitmap, populate it, and pass
a pointer to pnp_register_irq_resource().Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
pnp_assign_resources() is static and the only caller checks
pnp_can_configure() before calling it, so no need to do it
again.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
This patch doesn't change any behavior; it just makes the return
values more conventional.This changes pnp_assign_dma() from a void function to one that
returns an int, just like the other assignment functions. For
now, at least, pnp_assign_dma() always returns 0 (success), so
it appears to never fail, just like before.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
If the resource list is empty, say that explicitly. Previously,
it was confusing because often the heading was followed by zero
resource lines, then some "add resource" lines from auto-assignment,
so the "add" lines looked like current resources.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
When we fail to assign an I/O or MEM resource, include the min/max
in the debug output to help match it with the options.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
ACPI Address Space Descriptors can be up to 64 bits wide.
We should keep track of the whole thing when parsing resource
options, so this patch changes PNP port and mem option
fields from "unsigned short" and "unsigned int" to
"resource_size_t".Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
This adds a typedef for the IRQ bitmap, which should cause
no functional change, but will make it easier to pass a
pointer to a bitmap to pnp_register_irq_resource().Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
Nothing outside the PNP subsystem should need access to a
device's resource options, so this patch moves the option
structure declarations to a private header file.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
PNP previously defined PNP_PORT_FLAG_16BITADDR and PNP_PORT_FLAG_FIXED
in a private header file, but put those flags in struct resource.flags
fields. Better to make them IORESOURCE_IO_* flags like the existing
IRQ, DMA, and MEM flags.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
No functional change; just make a couple declarations
consistent with the rest of the file.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
As part of a heuristic to identify modem devices, 8250_pnp.c
checks to see whether a device can be configured at any of the
legacy COM port addresses.This patch moves the code that traverses the PNP "possible resource
options" from 8250_pnp.c to the PNP subsystem. This encapsulation
is important because a future patch will change the implementation
of those resource options.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
Rather than stepping through all IO resources, then stepping through
all MMIO resources, etc., we can just iterate over the resource list
once directly.This can change the order in /sys, e.g.,
# cat /sys/devices/pnp0/00:07/resources # OLD
state = active
io 0x3f8-0x3ff
irq 4# cat /sys/devices/pnp0/00:07/resources # NEW
state = active
irq 4
io 0x3f8-0x3ffThe old code artificially sorted resources by type; the new code
just lists them in the order we read them from the ISAPNP hardware
or the BIOS.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
We used to have a fixed-size resource table. If a device had
twenty resources when the table only had space for ten, we didn't
need ten warnings, so we added the ratelimit.Now that we can dynamically allocate new resources, we should
only get failures if the allocation fails. That should be
rare enough that we don't need to ratelimit the messages.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
When we parse a device's _CRS data (the current resource settings),
we should keep track of everything we find, even if it's currently
disabled or invalid.This is what we already do for ISAPNP and PNPBIOS, and it helps
keep things matched up when we subsequently re-encode resources.
For example, consider a device with (mem, irq0, irq1, io), where
irq0 is disabled. If we drop irq0 when parsing the _CRS, we will
mistakenly put irq1 in the irq0 slot when we encode resources
for an _SRS call.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.This patch replaces the table with a linked list of resources where
the entries are allocated on demand.This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resourcesReferences:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.Prior to this patch, the pnp_resource_table entries used the flags
like this:IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a deviceIORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative lengthAfter this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
This patch adds a "pnp_resource_type_name(struct resource *)" that
returns the string resource type. This will be used by the sysfs
"show resources" function and the debug resource dump function.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
Given a struct resource, this returns the type (IO, MEM, IRQ, DMA).
Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
We used pnp_resource.index to keep track of which ISAPNP configuration
register a resource should be written to. We needed this only to
handle the case where a register is disabled but a subsequent register
in the same set is enabled.Rather than explicitly maintaining the pnp_resource.index, this patch
adds a resource every time we read an ISAPNP configuration register
and marks the resource as IORESOURCE_DISABLED when appropriate. This
makes the position in the pnp_resource_table always correspond to the
config register index.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
In the debug resource dump, decode the flags and indicate when
a resource is disabled or has been automatically assigned.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
Get rid of a superfluous acpi_pm_device_sleep_state() parameter. The
only legitimate value of that parameter must be derived from the first
parameter, which is what all the callers already do. (However, this
does not address the fact that ACPI still doesn't set up those flags.)Signed-off-by: David Brownell
Signed-off-by: Andi Kleen
Acked-by: Pavel Machek
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Len Brown
12 Jun, 2008
3 commits
-
When configuring the resources of an ACPI device, we first evaluate _CRS
to get a template of resource descriptors, then fill in the specific
resource values we want, and finally evaluate _SRS to actually configure
the device.Some resources have optional fields, so the size of encoded descriptors
varies depending on the specific values. For example, IRQ descriptors can
be either two or three bytes long. The third byte contains triggering
information and can be omitted if the IRQ is edge-triggered and active
high.The BIOS often assumes that IRQ descriptors in the _SRS buffer use the
same format as those in the _CRS buffer, so this patch enforces that
constraint.The "Start Dependent Function" descriptor also has an optional byte, but
we don't currently encode those descriptors, so I didn't do anything for
those.I have tested this patch on a Toshiba Portege 4000. Without the patch,
parport_pc claims the parallel port only if I use "pnpacpi=off". This
patch makes it work with PNPACPI.This is an extension of a patch by Tom Jaeger:
http://bugzilla.kernel.org/show_bug.cgi?id=9487#c42References:
http://bugzilla.kernel.org/show_bug.cgi?id=5832 Enabling ACPI Plug and Play in kernels >2.6.9 kills Parallel support
http://bugzilla.kernel.org/show_bug.cgi?id=9487 buggy firmware expects four-byte IRQ resource descriptor (was: Serial port disappears after Suspend on Toshiba R25)
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1d5b285da1893b90507b081664ac27f1a8a3dc5b related ACPICA fixSigned-off-by: Bjorn Helgaas
Signed-off-by: Andrew Morton
Signed-off-by: Len Brown -
When we encode IRQ resources, we should use the "shareable" flag we got
from _PRS rather than guessing based on the IRQ trigger mode.This is based on a patch by Tom Jaeger:
http://bugzilla.kernel.org/show_bug.cgi?id=9487#c32Signed-off-by: Bjorn Helgaas
Signed-off-by: Andrew Morton
Signed-off-by: Len Brown -
When decoding IRQ trigger mode and polarity, it is not enough to mask by
IORESOURCE_BITS because there are now additional bits defined. For
example, if IORESOURCE_IRQ_SHAREABLE was set, we failed to set *triggering
and *polarity at all.I can't point to a failure that this patch fixes, but
bugs in this area have caused problems when resuming after
suspend, for example:http://bugzilla.kernel.org/show_bug.cgi?id=6316
http://bugzilla.kernel.org/show_bug.cgi?id=9487
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/152187This is based on a patch by Tom Jaeger:
http://bugzilla.kernel.org/show_bug.cgi?id=9487#c32[rene.herman@keyaccess.nl: fix comment]
Signed-off-by: Bjorn Helgaas
Signed-off-by: Andrew Morton
Signed-off-by: Len Brown
06 Jun, 2008
1 commit
-
We don't need to reserve "unset" resources. Trying to reserve
them results in messages like this, which are ugly but harmless:system 00:08: iomem range 0x0-0x0 could not be reserved
Future PNP patches will remove use of IORESOURCE_UNSET, but
we still need it for now.Signed-off-by: Bjorn Helgaas
Signed-off-by: Linus Torvalds
03 Jun, 2008
1 commit
-
Both the PNP/PCI conflict detection quirk and the PNP system
driver must use the same mechanism to mark resources as disabled.I think it's best to keep the resource and to keep the type bit
(IORESOURCE_MEM, etc), so that we match the list from firmware
as closely as possible.Fixes this regression from 2.6.25: http://lkml.org/lkml/2008/6/1/82
Signed-off-by: Bjorn Helgaas
Tested-by: Avuton Olrich
Signed-off-by: Linus Torvalds
16 May, 2008
1 commit
-
Everybody wants to pass it a function pointer, and in fact, that is what
you _must_ pass it for it to make sense (since it knows that ia64 and
ppc64 use descriptors for function pointers and fetches the actual
address from there).So don't make the argument be a 'unsigned long' and force everybody to
add a cast.Signed-off-by: Linus Torvalds
15 May, 2008
2 commits
-
Add a common hex array in hexdump.c so everyone can use it.
Add a common hi/lo helper to avoid the shifting masking that is
done to get the upper and lower nibbles of a byte value.Pull the pack_hex_byte helper from kgdb as it is opencoded many
places in the tree that will be consolidated.Signed-off-by: Harvey Harrison
Acked-by: Paul Mundt
Cc: Jason Wessel
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The AD181x and AZT230 chips don't support an IRQ-less MPU401 option but
work fine without one. This adds (priority functional) IRQ-less options
for each port option to help systems with few available IRQs.The AD1815 quirk can't use pnp_register_irq_resource() due to doubly
penalizing the IRQ. Also, while not a practical issue due to no IRQ
option being present for the dependents, this needs to add in front, not
back.Doesn't use pnp_register_port_resource() for symetry with above.
This does not delete the AD1815 independent option even though it should
be empty after the IRQ transfer due to AD1816 coming with an empty but
still present independent option by default.Was tested on AD1815, AD1816 and AZT2320. The ALSA snd-ad1818a driver
also support the AZT2002 ID for MPU401 but this doesn't as I was unable to
test it.Signed-off-by: Rene Herman
Tested-by: Uwe Bugla
Acked-by: Uwe Bugla
Acked-by: Bjorn Helgaas
Cc: Takashi Iwai
Cc: Len Brown
Signed-off-by: Linus Torvalds
