10 Jun, 2011

1 commit


31 Mar, 2011

1 commit


27 Oct, 2010

1 commit

  • This is cleanup mostly, nothing urgent.
    I came up with it when looking at dynamic debug which can
    enable pr_debug messages at runtime or boot param
    for a specific module.

    Advantages:
    - Any pnp code can make use of the moduleparam.h interface, the modules
    will show up as pnp.param.
    - Passing pnp.ddebug as kernel boot param will enable all pnp debug messages
    with my previous patch and CONFIG_DYNAMIC_DEBUG enabled.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Len Brown

    Thomas Renninger
     

18 Oct, 2010

1 commit

  • The patch below updates broken web addresses in the kernel

    Signed-off-by: Justin P. Mattock
    Cc: Maciej W. Rozycki
    Cc: Geert Uytterhoeven
    Cc: Finn Thain
    Cc: Randy Dunlap
    Cc: Matt Turner
    Cc: Dimitry Torokhov
    Cc: Mike Frysinger
    Acked-by: Ben Pfaff
    Acked-by: Hans J. Koch
    Reviewed-by: Finn Thain
    Signed-off-by: Jiri Kosina

    Justin P. Mattock
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

16 Dec, 2009

1 commit

  • Convert code away from ->read_proc/->write_proc interfaces. Switch to
    proc_create()/proc_create_data() which make addition of proc entries
    reliable wrt NULL ->proc_fops, NULL ->data and so on.

    Problem with ->read_proc et al is described here commit
    786d7e1612f0b0adb6046f19b906609e4fe8b1ba "Fix rmmod/read/write races in
    /proc entries"

    Signed-off-by: Alexey Dobriyan
    Cc: Adam Belay
    Cc: Bjorn Helgaas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

04 Dec, 2009

1 commit

  • That is "success", "unknown", "through", "performance", "[re|un]mapping"
    , "access", "default", "reasonable", "[con]currently", "temperature"
    , "channel", "[un]used", "application", "example","hierarchy", "therefore"
    , "[over|under]flow", "contiguous", "threshold", "enough" and others.

    Signed-off-by: André Goddard Rosa
    Signed-off-by: Jiri Kosina

    André Goddard Rosa
     

10 Aug, 2009

1 commit


08 Aug, 2009

1 commit

  • GDT_ENTRY_INIT is static initializer of desc_struct.

    We already have similar macro GDT_ENTRY() but it's static
    initializer for u64 and it cannot be used for desc_struct.

    Signed-off-by: Akinobu Mita
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Akinobu Mita
     

20 Jul, 2009

1 commit

  • Rename set_base()/set_limit to set_desc_base()/set_desc_limit()
    and rewrite them in C. These are naturally introduced by the
    idea of get_desc_base()/get_desc_limit().

    The conversion actually found the bug in apm_32.c:
    bad_bios_desc is written at run-time, but it is defined const
    variable.

    Signed-off-by: Akinobu Mita
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Akinobu Mita
     

03 Apr, 2009

2 commits


01 Jan, 2009

1 commit


23 Oct, 2008

1 commit


15 Oct, 2008

1 commit


11 Oct, 2008

2 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

    Bjorn Helgaas
     
  • 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

    Bjorn Helgaas
     

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

    Linus Torvalds
     

23 Sep, 2008

1 commit


17 Jul, 2008

6 commits

  • 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

    Bjorn Helgaas
     
  • 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

    Bjorn Helgaas
     
  • 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

    Bjorn Helgaas
     
  • 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

    Bjorn Helgaas
     
  • 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

    Bjorn Helgaas
     
  • 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 resources

    References:

    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/110

    This 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 device

    IORESOURCE_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 length

    After 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

    Bjorn Helgaas
     

01 May, 2008

2 commits

  • next-20080430/drivers/pnp/pnpbios/rsparser.c:594: warning: format '%d' expects type 'int', but argument 4 has type 'resource_size_t'
    next-20080430/drivers/pnp/pnpbios/rsparser.c:605: warning: format '%d' expects type 'int', but argument 4 has type 'resource_size_t'

    [joe@perches.com: fix it]
    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Randy Dunlap
    Cc: Bjorn Helgaas
    Signed-off-by: Joe Perches

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     
  • * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (179 commits)
    ACPI: Fix acpi_processor_idle and idle= boot parameters interaction
    acpi: fix section mismatch warning in pnpacpi
    intel_menlo: fix build warning
    ACPI: Cleanup: Remove unneeded, multiple local dummy variables
    ACPI: video - fix permissions on some proc entries
    ACPI: video - properly handle errors when registering proc elements
    ACPI: video - do not store invalid entries in attached_array list
    ACPI: re-name acpi_pm_ops to acpi_suspend_ops
    ACER_WMI/ASUS_LAPTOP: fix build bug
    thinkpad_acpi: fix possible NULL pointer dereference if kstrdup failed
    ACPI: check a return value correctly in acpi_power_get_context()
    #if 0 acpi/bay.c:eject_removable_drive()
    eeepc-laptop: add hwmon fan control
    eeepc-laptop: add backlight
    eeepc-laptop: add base driver
    ACPI: thinkpad-acpi: bump up version to 0.20
    ACPI: thinkpad-acpi: fix selects in Kconfig
    ACPI: thinkpad-acpi: use a private workqueue
    ACPI: thinkpad-acpi: fluff really minor fix
    ACPI: thinkpad-acpi: use uppercase for "LED" on user documentation
    ...

    Fixed conflicts in drivers/acpi/video.c and drivers/misc/intel_menlow.c
    manually.

    Linus Torvalds
     

29 Apr, 2008

13 commits