01 Jan, 2009
1 commit
-
Impact: CPU iterator bugfixes
Percpu areas are only allocated for possible cpus. In general, you
shouldn't access random cpu's percpu areas.Signed-off-by: Rusty Russell
Signed-off-by: Mike Travis
Acked-by: Ingo Molnar
Cc: Adam Belay
05 Nov, 2008
1 commit
-
Signed-off-by: Jianjun Kong
Signed-off-by: Linus Torvalds
23 Oct, 2008
3 commits
-
Conflicts:
MAINTAINERS
arch/x86/kernel/acpi/boot.c
arch/x86/kernel/acpi/sleep.c
drivers/acpi/Kconfig
drivers/pnp/Makefile
drivers/pnp/quirks.cSigned-off-by: Len Brown
-
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 combinationhttp://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
17 Oct, 2008
5 commits
-
I dunno how this missed Bjorn and his quest to use %pF in commit
c80cfb0406c01bb5da91bfe30f5cb1fd96831138 ("vsprintf: use new vsprintf
symbolic function pointer format"), but it did.So use %pF in the two remaining places that still tried to print out
function pointers by hand.Signed-off-by: Linus Torvalds
-
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (46 commits)
UIO: Fix mapping of logical and virtual memory
UIO: add automata sercos3 pci card support
UIO: Change driver name of uio_pdrv
UIO: Add alignment warnings for uio-mem
Driver core: add bus_sort_breadthfirst() function
NET: convert the phy_device file to use bus_find_device_by_name
kobject: Cleanup kobject_rename and !CONFIG_SYSFS
kobject: Fix kobject_rename and !CONFIG_SYSFS
sysfs: Make dir and name args to sysfs_notify() const
platform: add new device registration helper
sysfs: use ilookup5() instead of ilookup5_nowait()
PNP: create device attributes via default device attributes
Driver core: make bus_find_device_by_name() more robust
usb: turn dev_warn+WARN_ON combos into dev_WARN
debug: use dev_WARN() rather than WARN_ON() in device_pm_add()
debug: Introduce a dev_WARN() function
sysfs: fix deadlock
device model: Do a quickcheck for driver binding before doing an expensive check
Driver core: Fix cleanup in device_create_vargs().
Driver core: Clarify device cleanup.
... -
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 -
There's no point in printing some ancient version number forever.
Signed-off-by: Adrian Bunk
Acked-by: Rene Herman
Acked-by: Bjorn Helgaas
Acked-by: Adam M Belay
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This creates the attributes before the uevent is sent.
Signed-off-by: Drew Moseley
Acked-by: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
15 Oct, 2008
1 commit
-
Manual fixup of conflicts on:
arch/powerpc/include/asm/dcr-regs.h
drivers/net/ibm_newemac/core.h
11 Oct, 2008
8 commits
-
CONFIG_PNP_DEBUG is no longer used to turn on dev_dbg() in PNP,
since we have pnp_dbg() which can be enabled at boot-time, so
this patch removes the config option.Note that pnp_dock_event() checks "#ifdef DEBUG". But there's
never been a clear path for enabling that via configgery. It
happened that CONFIG_PNP_DEBUG enabled it after 1bd17e63a068db6,
but that was accidental and only in 2.6.26.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown -
pnp_dbg() is equivalent to dev_dbg() except that we can turn it
on at boot-time with the "pnp.debug" kernel parameter, so we don't
have to build a new kernel image.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown -
This adds the core function pnp_dbg() and a new config option to
enable it.The PNP core debugging messages can be enabled at boot-time with the
"pnp.debug" kernel parameter.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown -
Use scnprintf() to build up a buffer of PNP IDs to print. This
makes the printk atomic and helps get rid of an #ifdef.Also remove an "#ifdef DEBUG" from some debug functions. The
functions only produce debug output, so it's OK to run the
function and just have the output be dropped at the end.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown -
Use the '%pF' format to get rid of an "#ifdef DEBUG".
Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown -
There are only a few remaining uses of pnp_info(), so I just
converted them to printk and removed the pnp_err(), pnp_info(),
pnp_warn(), and pnp_dbg() wrappers.I also removed a couple debug messages that don't seem useful any
more ("driver registered", "driver unregistered", "driver attached").Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown -
Use dev_printk() when possible for more informative error messages.
Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown -
This patch just fixes indentation of a couple debug messages.
Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown
10 Oct, 2008
1 commit
-
We already did that a long time ago for pnp_system_init, but
pnpacpi_init and pnpbios_init remained as subsys_initcalls, and get
linked into the kernel before the arch-specific routines that finalize
the PCI resources (pci_subsys_init).This means that the PnP routines would either register their resources
before the PCI layer could, or would be unable to check whether a PCI
resource had already been registered. Both are problematic.I wanted to do this before 2.6.27, but every time we change something
like this, something breaks. That said, _every_ single time we trust
some firmware (like PnP tables) more than we trust the hardware itself
(like PCI probing), the problems have been worse.Signed-off-by: Linus Torvalds
23 Sep, 2008
1 commit
-
Now that arch/ppc is dead CONFIG_PPC_MERGE is always defined for all
powerpc platforms and we want to get rid of CONFIG_PPC_MERGE use
CONFIG_PPC instead.Signed-off-by: Kumar Gala
Acked-by: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Andrew Morton
Signed-off-by: Kumar Gala
25 Aug, 2008
1 commit
-
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=2b8de5f50e4a302b83ebcd5b0120621336d50bd6to fix this bug:
http://bugzilla.kernel.org/show_bug.cgi?id=6292However, 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
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
14 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