Eric Lee / smarc-fsl-linux-kernel

26 Sep, 2020

1 commit

09 Apr, 2019

1 commit

  • d75f773c8   treewide: Switch printk users from %pf and %pF to %ps and %pS, respectively ... Browse Code »

    %pF and %pf are functionally equivalent to %pS and %ps conversion
    specifiers. The former are deprecated, therefore switch the current users
    to use the preferred variant.

    The changes have been produced by the following command:

    git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \
    while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done

    And verifying the result.

    Link: http://lkml.kernel.org/r/20190325193229.23390-1-sakari.ailus@linux.intel.com
    Cc: Andy Shevchenko
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: sparclinux@vger.kernel.org
    Cc: linux-um@lists.infradead.org
    Cc: xen-devel@lists.xenproject.org
    Cc: linux-acpi@vger.kernel.org
    Cc: linux-pm@vger.kernel.org
    Cc: drbd-dev@lists.linbit.com
    Cc: linux-block@vger.kernel.org
    Cc: linux-mmc@vger.kernel.org
    Cc: linux-nvdimm@lists.01.org
    Cc: linux-pci@vger.kernel.org
    Cc: linux-scsi@vger.kernel.org
    Cc: linux-btrfs@vger.kernel.org
    Cc: linux-f2fs-devel@lists.sourceforge.net
    Cc: linux-mm@kvack.org
    Cc: ceph-devel@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Signed-off-by: Sakari Ailus
    Acked-by: David Sterba (for btrfs)
    Acked-by: Mike Rapoport (for mm/memblock.c)
    Acked-by: Bjorn Helgaas (for drivers/pci)
    Acked-by: Rafael J. Wysocki
    Signed-off-by: Petr Mladek

    Sakari Ailus
     

13 Dec, 2017

1 commit

  • 245fe15e4   PNP: remove unneeded kallsyms include ... Browse Code »

    The file was converted from print_fn_descriptor_symbol()
    to %pF some time ago (2e532d68a2b3e2aa {pci,pnp} quirks.c:
    don't use deprecated print_fn_descriptor_symbol()). kallsyms
    does not seem to be needed anymore.

    Signed-off-by: Sergey Senozhatsky
    Signed-off-by: Rafael J. Wysocki

    Sergey Senozhatsky
     

02 Nov, 2017

1 commit

  • b24413180   License cleanup: add SPDX GPL-2.0 license identifier to files with no license ... Browse Code »

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

03 Feb, 2016

1 commit

  • ed1f0eeeb   PNP: Add Haswell-ULT to Intel MCH size workaround ... Browse Code »

    Add device ID 0x0a04 for Haswell-ULT to the list of devices with MCH
    problems.

    From a Lenovo ThinkPad T440S:
    [ 0.188604] pnp: PnP ACPI init
    [ 0.189044] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
    [ 0.189048] system 00:00: [mem 0x000c0000-0x000c3fff] could not be reserved
    [ 0.189050] system 00:00: [mem 0x000c4000-0x000c7fff] could not be reserved
    [ 0.189052] system 00:00: [mem 0x000c8000-0x000cbfff] could not be reserved
    [ 0.189054] system 00:00: [mem 0x000cc000-0x000cffff] could not be reserved
    [ 0.189056] system 00:00: [mem 0x000d0000-0x000d3fff] has been reserved
    [ 0.189058] system 00:00: [mem 0x000d4000-0x000d7fff] has been reserved
    [ 0.189060] system 00:00: [mem 0x000d8000-0x000dbfff] has been reserved
    [ 0.189061] system 00:00: [mem 0x000dc000-0x000dffff] has been reserved
    [ 0.189063] system 00:00: [mem 0x000e0000-0x000e3fff] could not be reserved
    [ 0.189065] system 00:00: [mem 0x000e4000-0x000e7fff] could not be reserved
    [ 0.189067] system 00:00: [mem 0x000e8000-0x000ebfff] could not be reserved
    [ 0.189069] system 00:00: [mem 0x000ec000-0x000effff] could not be reserved
    [ 0.189071] system 00:00: [mem 0x000f0000-0x000fffff] could not be reserved
    [ 0.189073] system 00:00: [mem 0x00100000-0xdf9fffff] could not be reserved
    [ 0.189075] system 00:00: [mem 0xfec00000-0xfed3ffff] could not be reserved
    [ 0.189078] system 00:00: [mem 0xfed4c000-0xffffffff] could not be reserved
    [ 0.189082] system 00:00: Plug and Play ACPI device, IDs PNP0c01 (active)
    [ 0.189216] system 00:01: [io 0x1800-0x189f] could not be reserved
    [ 0.189220] system 00:01: [io 0x0800-0x087f] has been reserved
    [ 0.189222] system 00:01: [io 0x0880-0x08ff] has been reserved
    [ 0.189224] system 00:01: [io 0x0900-0x097f] has been reserved
    [ 0.189226] system 00:01: [io 0x0980-0x09ff] has been reserved
    [ 0.189229] system 00:01: [io 0x0a00-0x0a7f] has been reserved
    [ 0.189231] system 00:01: [io 0x0a80-0x0aff] has been reserved
    [ 0.189233] system 00:01: [io 0x0b00-0x0b7f] has been reserved
    [ 0.189235] system 00:01: [io 0x0b80-0x0bff] has been reserved
    [ 0.189238] system 00:01: [io 0x15e0-0x15ef] has been reserved
    [ 0.189240] system 00:01: [io 0x1600-0x167f] has been reserved
    [ 0.189242] system 00:01: [io 0x1640-0x165f] has been reserved
    [ 0.189246] system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
    [ 0.189249] system 00:01: [mem 0x00000000-0x00000fff] could not be reserved
    [ 0.189251] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved
    [ 0.189254] system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
    [ 0.189256] system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
    [ 0.189258] system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
    [ 0.189261] system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved
    [ 0.189264] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
    [....]
    [ 0.583653] resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
    [ 0.583654] ------------[ cut here ]------------
    [ 0.583660] WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2c5/0x380()
    [ 0.583661] Info: mapping multiple BARs. Your kernel is fine.
    [ 0.583662] Modules linked in:

    [ 0.583666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.3.3-303.fc23.x86_64 #1
    [ 0.583668] Hardware name: LENOVO 20AR001GXS/20AR001GXS, BIOS GJET86WW (2.36 ) 12/04/2015
    [ 0.583670] 0000000000000000 0000000014cf7e59 ffff880214a1baf8 ffffffff813a625f
    [ 0.583673] ffff880214a1bb40 ffff880214a1bb30 ffffffff810a07c2 00000000fed10000
    [ 0.583675] ffffc90000cb8000 0000000000006000 0000000000000000 ffff8800d6381040
    [ 0.583678] Call Trace:
    [ 0.583683] [] dump_stack+0x44/0x55
    [ 0.583686] [] warn_slowpath_common+0x82/0xc0
    [ 0.583688] [] warn_slowpath_fmt+0x5c/0x80
    [ 0.583692] [] ? iomem_map_sanity_check+0xba/0xd0
    [ 0.583695] [] __ioremap_caller+0x2c5/0x380
    [ 0.583698] [] ioremap_nocache+0x17/0x20
    [ 0.583701] [] snb_uncore_imc_init_box+0x79/0xb0
    [ 0.583705] [] uncore_pci_probe+0xd0/0x1b0
    [ 0.583707] [] local_pci_probe+0x45/0xa0
    [ 0.583710] [] pci_device_probe+0xfd/0x140
    [ 0.583713] [] driver_probe_device+0x222/0x480
    [ 0.583715] [] __driver_attach+0x84/0x90
    [ 0.583717] [] ? driver_probe_device+0x480/0x480
    [ 0.583720] [] bus_for_each_dev+0x6c/0xc0
    [ 0.583722] [] driver_attach+0x1e/0x20
    [ 0.583724] [] bus_add_driver+0x1eb/0x280
    [ 0.583727] [] ? uncore_cpu_setup+0x12/0x12
    [ 0.583729] [] driver_register+0x60/0xe0
    [ 0.583733] [] __pci_register_driver+0x4c/0x50
    [ 0.583736] [] intel_uncore_init+0xe2/0x2e6
    [ 0.583738] [] ? uncore_cpu_setup+0x12/0x12
    [ 0.583741] [] do_one_initcall+0xb3/0x200
    [ 0.583745] [] ? parse_args+0x1a0/0x4a0
    [ 0.583749] [] kernel_init_freeable+0x189/0x223
    [ 0.583752] [] ? rest_init+0x80/0x80
    [ 0.583754] [] kernel_init+0xe/0xe0
    [ 0.583758] [] ret_from_fork+0x3f/0x70
    [ 0.583760] [] ? rest_init+0x80/0x80
    [ 0.583765] ---[ end trace 077c426a39e018aa ]---

    00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 0b)
    Subsystem: Lenovo Device [17aa:220c]
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
    Kernel driver in use: hsw_uncore

    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1300955
    Tested-by:
    Signed-off-by: Josh Boyer
    Signed-off-by: Rafael J. Wysocki

    Josh Boyer
     

03 Jan, 2016

1 commit

  • a77060f07   PNP: Add Broadwell to Intel MCH size workaround ... Browse Code »

    Add device ID 0x1604 for Broadwell to commit cb171f7abb9a ("PNP:
    Work around BIOS defects in Intel MCH area reporting").

    >From a Lenovo ThinkPad T550:

    system 00:01: [io 0x1800-0x189f] could not be reserved
    system 00:01: [io 0x0800-0x087f] has been reserved
    system 00:01: [io 0x0880-0x08ff] has been reserved
    system 00:01: [io 0x0900-0x097f] has been reserved
    system 00:01: [io 0x0980-0x09ff] has been reserved
    system 00:01: [io 0x0a00-0x0a7f] has been reserved
    system 00:01: [io 0x0a80-0x0aff] has been reserved
    system 00:01: [io 0x0b00-0x0b7f] has been reserved
    system 00:01: [io 0x0b80-0x0bff] has been reserved
    system 00:01: [io 0x15e0-0x15ef] has been reserved
    system 00:01: [io 0x1600-0x167f] has been reserved
    system 00:01: [io 0x1640-0x165f] has been reserved
    system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved
    system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved
    system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved
    system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved
    system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved
    system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved
    system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
    [...]
    resource sanity check: requesting [mem 0xfed10000-0xfed15fff], which spans more than pnp 00:01 [mem 0xfed10000-0xfed13fff]
    ------------[ cut here ]------------
    WARNING: CPU: 2 PID: 1 at /build/linux-CrHvZ_/linux-4.2.6/arch/x86/mm/ioremap.c:198 __ioremap_caller+0x2ee/0x360()
    Info: mapping multiple BARs. Your kernel is fine.
    Modules linked in:
    CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.2.0-1-amd64 #1 Debian 4.2.6-1
    Hardware name: LENOVO 20CKCTO1WW/20CKCTO1WW, BIOS N11ET34W (1.10 ) 08/20/2015
    0000000000000000 ffffffff817e6868 ffffffff8154e2f6 ffff8802241efbf8
    ffffffff8106e5b1 ffffc90000e98000 0000000000006000 ffffc90000e98000
    0000000000006000 0000000000000000 ffffffff8106e62a ffffffff817e68c8
    Call Trace:
    [] ? dump_stack+0x40/0x50
    [] ? warn_slowpath_common+0x81/0xb0
    [] ? warn_slowpath_fmt+0x4a/0x50
    [] ? iomem_map_sanity_check+0xb3/0xc0
    [] ? __ioremap_caller+0x2ee/0x360
    [] ? snb_uncore_imc_init_box+0x66/0x90
    [] ? uncore_pci_probe+0xc8/0x1a0
    [] ? local_pci_probe+0x3f/0xa0
    [] ? pci_device_probe+0xc4/0x110
    [] ? driver_probe_device+0x1ee/0x450
    [] ? __driver_attach+0x7b/0x80
    [] ? driver_probe_device+0x450/0x450
    [] ? bus_for_each_dev+0x5a/0x90
    [] ? bus_add_driver+0x1f1/0x290
    [] ? uncore_cpu_setup+0xc/0xc
    [] ? driver_register+0x5f/0xe0
    [] ? intel_uncore_init+0xcc/0x2b0
    [] ? uncore_cpu_setup+0xc/0xc
    [] ? do_one_initcall+0xce/0x200
    [] ? parse_args+0x140/0x4e0
    [] ? kernel_init_freeable+0x162/0x1e8
    [] ? rest_init+0x80/0x80
    [] ? kernel_init+0xe/0xf0
    [] ? ret_from_fork+0x3f/0x70
    [] ? rest_init+0x80/0x80
    ---[ end trace 472e7959536abf12 ]---

    00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
    Subsystem: Lenovo Device 2223
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
    Kernel driver in use: bdw_uncore
    00: 86 80 04 16 06 00 90 20 09 00 00 06 00 00 00 00
    10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 23 22
    30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

    Signed-off-by: Christophe Le Roy
    Signed-off-by: Rafael J. Wysocki

    Christophe Le Roy
     

13 Mar, 2015

1 commit

  • f7834c092   PNP: Don't check for overlaps with unassigned PCI BARs ... Browse Code »

    After 0509ad5e1a7d ("PNP: disable PNP motherboard resources that overlap
    PCI BARs"), we disable and warn about PNP resources that overlap PCI BARs.
    But we assume that all PCI BARs are valid, which is incorrect, because a
    BAR may not have any space assigned to it. In that case, we will not
    enable the BAR, so no other resource can conflict with it.

    Ignore PCI BARs that are unassigned, as indicated by IORESOURCE_UNSET.

    Firmware often leaves PCI BARs unassigned, containing zero. Zero is a
    valid BAR value, so we can't just check for that, but the PCI core can set
    IORESOURCE_UNSET when it detects an unassigned BAR by other means. This
    should get rid of many of the annoying messages like this:

    pnp 00:00: disabling [io 0x0061] because it overlaps 0001:05:00.0 BAR 0 [io 0x0000-0x00ff]

    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki

    Bjorn Helgaas
     

30 Apr, 2014

1 commit

  • b3413afb4   PNP: Fix compile error in quirks.c ... Browse Code »

    Fix the compile error:

    drivers/pnp/quirks.c:393:2: error: implicit declaration of function 'pcibios_bus_to_resource'

    that occurs when building with CONFIG_PCI unset. The quirk is only
    relevent to Intel devices, so we could use "#if defined(CONFIG_X86) &&
    defined(CONFIG_PCI)" instead, but testing CONFIG_X86 is not strictly
    necessary.

    Fixes: cb171f7abb9a (PNP: Work around BIOS defects in Intel MCH area reporting)
    Reported-by: Randy Dunlap
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Rafael J. Wysocki

    Bjorn Helgaas
     

24 Apr, 2014

1 commit

  • cb171f7ab   PNP: Work around BIOS defects in Intel MCH area reporting ... Browse Code »

    Work around BIOSes that don't report the entire Intel MCH area.

    MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a
    PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts.
    Some BIOSes still report a PNP0C02 resource that is only 16KB, which means
    the rest of the MCH space is consumed but unreported.

    This can cause resource map sanity check warnings or (theoretically) a
    device conflict if we assigned the unreported space to another device.

    The Intel perf event uncore driver tripped over this when it claimed the
    MCH region:

    resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
    Info: mapping multiple BARs. Your kernel is fine.

    To prevent this, if we find a PNP0C02 resource that covers part of the MCH
    space, extend it to cover the entire space.

    References: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic
    Reported-and-tested-by: Borislav Petkov
    Signed-off-by: Bjorn Helgaas
    Acked-by: Borislav Petkov
    Acked-by: Stephane Eranian
    Signed-off-by: Rafael J. Wysocki

    Bjorn Helgaas
     

07 Jan, 2012

1 commit

  • eb31aae8c   PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB ... Browse Code »
    1

    Some Dell BIOSes have MCFG tables that don't report the entire
    MMCONFIG area claimed by the chipset. If we move PCI devices into
    that claimed-but-unreported area, they don't work.

    This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as
    needed to cover the entire area.

    Example problem scenario:

    BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved)
    Fam 10h mmconf [d0000000, dfffffff]
    PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000)
    pnp 00:0c: [mem 0xd0000000-0xd3ffffff]
    pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff]
    pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff]
    pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff]

    Reported-by: Lisa Salimbas
    Reported-by:
    Tested-by: dann frazier
    References: https://bugzilla.kernel.org/show_bug.cgi?id=31602
    References: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/647043
    References: https://bugzilla.redhat.com/show_bug.cgi?id=770308
    Cc: stable@kernel.org # 2.6.34+
    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

05 Nov, 2009

2 commits

  • c7dabef8a   vsprintf: use %pR, %pr instead of %pRt, %pRf ... Browse Code »

    Jesse accidentally applied v1 [1] of the patchset instead of v2 [2]. This
    is the diff between v1 and v2.

    The changes in this patch are:
    - tidied vsprintf stack buffer to shrink and compute size more
    accurately
    - use %pR for decoding and %pr for "raw" (with type and flags) instead
    of adding %pRt and %pRf

    [1] http://lkml.org/lkml/2009/10/6/491
    [2] http://lkml.org/lkml/2009/10/13/441

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     
  • 9a007b379   PNP: print resources consistently with %pRt ... Browse Code »

    This uses %pRt and %pRf to print additional resource information (type,
    size, prefetchability, etc.) consistently.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Jesse Barnes

    Bjorn Helgaas
     

23 Oct, 2008

1 commit

17 Oct, 2008

2 commits

11 Oct, 2008

2 commits

27 Jul, 2008

1 commit

  • 999ed65ad   pnp: have quirk_system_pci_resources() include io resources ... Browse Code »

    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

    Rene Herman
     

17 Jul, 2008

4 commits

  • 1f32ca31e   PNP: convert resource options to single linked list ... Browse Code »

    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
     
  • d5ebde6ef   PNP: support optional IRQ resources ... Browse Code »

    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=3b73a223661ed137c5d3d2635f954382e94f5a43

    I 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

    Bjorn Helgaas
     
  • 7aefff518   PNP: introduce pnp_irq_mask_t typedef ... Browse Code »

    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
     
  • aee3ad815   PNP: replace pnp_resource_table with dynamically allocated resources ... Browse Code »

    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
     

03 Jun, 2008

1 commit

  • 4b34fe156   PNP: mark resources that conflict with PCI devices "disabled" ... Browse Code »

    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

    Bjorn Helgaas
     

16 May, 2008

1 commit

  • a442ac512   Clean up 'print_fn_descriptor_symbol()' types ... Browse Code »

    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

    Linus Torvalds
     

15 May, 2008

2 commits

  • 3b73a2236   pnp: add ISAPnP MPU option quirks ... Browse Code »

    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

    Rene Herman
     
  • 726a7a3d1   pnp: clean up pnp_fixup_device() ... Browse Code »

    Make it look a bit more like pci_fixup_device/pci_do_fixups. Also print
    the PnP ID and delete the () from the "foo+0x0/0x1234()".

    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

    Rene Herman
     

29 Apr, 2008

2 commits

28 Apr, 2008

2 commits

13 Mar, 2008

2 commits

  • 0509ad5e1   PNP: disable PNP motherboard resources that overlap PCI BARs ... Browse Code »

    Some BIOSes have PNP motherboard devices with resources that
    partially overlap PCI BARs. The PNP system driver claims these
    motherboard resources, which prevents the normal PCI driver from
    requesting them later.

    This patch disables the PNP resources that conflict with PCI BARs
    so they won't be claimed by the PNP system driver.

    Of course, this only works if PCI devices have already been enumerated.
    Currently this is the case because PCI devices are discovered before
    any PNP init via this path:

    acpi_pci_root_init() -> acpi_pci_root_add() -> pci_acpi_scan_root() ->
    pci_scan_bus_parented() -> pci_scan_child_bus() -> ...

    Avuton Olrich tested this and confirmed that it fixes his ALSA sound
    card (see http://lkml.org/lkml/2008/1/27/168).

    References:
    https://bugzilla.redhat.com/show_bug.cgi?id=280641
    https://bugzilla.redhat.com/show_bug.cgi?id=313491
    http://lkml.org/lkml/2008/1/9/449
    http://thread.gmane.org/gmane.linux.acpi.devel/27312
    http://lkml.org/lkml/2008/1/27/168

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     
  • e0aca2330   PNP: revert Supermicro H8DCE motherboard quirk ... Browse Code »

    There are other systems with similar problems
    (http://lkml.org/lkml/2008/1/27/168), so we need a more
    generic quirk. Remove the Supermicro-specific one first.

    Signed-off-by: Bjorn Helgaas
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

07 Feb, 2008

1 commit

  • 445a1d3e2   PNP: disable Supermicro H8DCE motherboard resources that overlap SATA BARs ... Browse Code »

    Some Supermicro BIOSes describe a SATA PCI BAR as a motherboard resource.
    The PNP system driver claims motherboard resources, and this prevents the
    sata_nv driver from requesting it later.

    This patch disables the PNP0C01/PNP0C02 resources so they won't be claimed
    by the PNP system driver, so they'll available for sata_nv.

    This fixes the bugs below, where sata_nv detects only two out of four SATA
    drives. The signature includes dmesg lines similar to these:

    pnp: 00:09: iomem range 0xdfefc000-0xdfefcfff has been reserved
    pnp: 00:09: iomem range 0xdfefd000-0xdfefd3ff has been reserved
    pnp: 00:09: iomem range 0xdfefe000-0xdfefe3ff has been reserved

    PCI: Unable to reserve mem region #6:1000@dfefd000 for device 0000:80:07.0
    sata_nv: probe of 0000:80:07.0 failed with error -16
    PCI: Unable to reserve mem region #6:1000@dfefe000 for device 0000:80:08.0
    sata_nv: probe of 0000:80:08.0 failed with error -16

    References:
    https://bugzilla.redhat.com/show_bug.cgi?id=280641
    https://bugzilla.redhat.com/show_bug.cgi?id=313491
    http://lkml.org/lkml/2008/1/9/449
    http://thread.gmane.org/gmane.linux.acpi.devel/27312

    This is post-2.6.24 material.

    Signed-off-by: Bjorn Helgaas

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

    Bjorn Helgaas
     

17 Oct, 2007

1 commit

  • a05d07816   PNP: use dev_info(), dev_err(), etc in core ... Browse Code »

    If we have the struct pnp_dev available, we can use dev_info(), dev_err(),
    etc., to give a little more information and consistency.

    [akpm@linux-foundation.org: fix warning]
    Signed-off-by: Bjorn Helgaas
    Cc: Adam Belay
    Cc: Len Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

12 Sep, 2007

1 commit

  • b70ae1d9f   PNP: remove SMCf010 quirk ... Browse Code »

    If the quirk enables the SIR part of the SMCf010 device, the 8250 driver
    may claim it as a legacy ttyS device, which makes the legacy probe in the
    smsc-ircc2 driver fail.

    Signed-off-by: Bjorn Helgaas
    Cc: Andrey Borzenkov
    Cc: Michal Piotrowski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

27 Jul, 2007

2 commits

  • 07d4e9af1   PNP: fix up after Lindent ... Browse Code »

    These are manual fixups after running Lindent. No functional change.

    Signed-off-by: Bjorn Helgaas
    Cc: Len Brown
    Cc: Adam Belay
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     
  • 9dd78466c   PNP: Lindent all source files ... Browse Code »

    Run Lindent on all PNP source files.

    Produced by:

    $ quilt new pnp-lindent
    $ find drivers/pnp -name \*.[ch] | xargs quilt add
    $ quilt add include/linux/{pnp.h,pnpbios.h}
    $ scripts/Lindent drivers/pnp/*.c drivers/pnp/*/*.c include/linux/pnp*.h
    $ quilt refresh --sort

    Signed-off-by: Bjorn Helgaas
    Cc: Len Brown
    Cc: Adam Belay
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

07 Jul, 2007

1 commit

  • 41a531146   PNP SMCf010 quirk: work around Toshiba Portege 4000 ACPI issues ... Browse Code »

    When we enable the SMCf010 IR device, the Toshiba Portege 4000 BIOS claims
    the device is working, but it really isn't configured correctly. The BIOS
    *will* configure it, but only if we call _SRS after (1) reversing the order
    of the SIR and FIR I/O port regions and (2) changing the IRQ from
    active-high to active-low.

    This patch addresses the 2.6.22 regression:
    "no irda0 interface (2.6.21 was OK), smsc does not find chip"

    I tested this on a Portege 4000. The smsc-ircc2 driver correctly detects
    the device, and "irattach irda0 -s && irdadump" shows transmitted and
    received packets.

    Signed-off-by: Bjorn Helgaas
    Cc: Andrey Borzenkov
    Cc: Samuel Ortiz
    Cc: "Linus Walleij (LD/EAB)"
    Cc: Michal Piotrowski
    Cc: Adam Belay
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

29 Jun, 2007

1 commit

  • 172d0496c   PNP SMCf010 quirk: auto-config device if BIOS left it broken ... Browse Code »

    Some HP firmware leaves the SMCf010 IRDA device incompletely configured, or
    reports the wrong resources in _CRS. As a workaround, when we find such a
    device, try to auto-configure the device.

    This ignores the _CRS data, picks a config from _PRS, and runs _SRS to
    configure the device. This makes smsc-ircc2 work correctly with PNP
    resources (with no preconfiguration!) on all the machines I tested.

    I think Windows does something like this by default for all devices,
    so we should consider doing the same thing in Linux.

    This patch addresses part of the 2.6.22 regression:
    "no irda0 interface (2.6.21 was OK), smsc does not find chip"
    It fixes smsc-ircc2 PNP device detection on HP nc6000, nc6220, nw8000,
    nw8240, and possibly other machines.

    Signed-off-by: Bjorn Helgaas
    Cc: Samuel Ortiz
    Cc: "Linus Walleij (LD/EAB)"
    Cc: Andrey Borzenkov
    Cc: Michal Piotrowski
    Cc: Adam Belay
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

09 May, 2007

1 commit

  • a1e7e636f   PNP: workaround HP BIOS defect that leaves SMCF010 device partly enabled ... Browse Code »

    Some HP/Compaq firmware reports via ACPI that the SMCF010 IR device is
    enabled, but in fact, it leaves the device partly disabled.

    HP nw8240 BIOS 68DTV Ver. F.0F, released 9/15/2005 is one BIOS that has this
    problem.

    Signed-off-by: Bjorn Helgaas
    Cc: Keith Owens
    Cc: Len Brown
    Cc: Adam Belay
    Cc: Matthieu CASTET
    Cc: Jean Tourrilhes
    Cc: Matthew Garrett
    Cc: Ville Syrjala
    Cc: Russell King
    Cc: Samuel Ortiz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas