Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 7月, 2008 3 次提交
  3. 28 7月, 2008 4 次提交
  5. 22 7月, 2008 1 次提交
    • A
      sysdev: Pass the attribute to the low level sysdev show/store function · 4a0b2b4d
      由 Andi Kleen 提交于 
      This allow to dynamically generate attributes and share show/store
functions between attributes. Right now most attributes are generated
by special macros and lots of duplicated code. With the attribute
passed it's instead possible to attach some data to the attribute
and then use that in shared low level functions to do different things.

I need this for the dynamically generated bank attributes in the x86
machine check code, but it'll allow some further cleanups.

I converted all users in tree to the new show/store prototype. It's a single
huge patch to avoid unbisectable sections.

Runtime tested: x86-32, x86-64
Compiled only: ia64, powerpc
Not compile tested/only grep converted: sh, arm, avr32
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4a0b2b4d
  7. 28 6月, 2008 1 次提交
    • A
      PCI: remove unused arch pcibios_update_resource() functions · 0aea5313
      由 Adrian Bunk 提交于 
      Russell King did the following back in 2003:

<--  snip  -->

    [PCI] pci-9: Kill per-architecture pcibios_update_resource()

    Kill pcibios_update_resource(), replacing it with pci_update_resource().
    pci_update_resource() uses pcibios_resource_to_bus() to convert a
    resource to a device BAR - the transformation should be exactly the
    same as the transformation used for the PCI bridges.

    pci_update_resource "knows" about 64-bit BARs, but doesn't attempt to
    set the high 32-bits to anything non-zero - currently no architecture
    attempts to do something different.  If anyone cares, please fix; I'm
    going to reflect current behaviour for the time being.

    Ivan pointed out the following architectures need to examine their
    pcibios_update_resource() implementation - they should make sure that
    this new implementation does the right thing.  #warning's have been
    added where appropriate.

        ia64
        mips
        mips64

    This cset also includes a fix for the problem reported by AKPM where
    64-bit arch compilers complain about the resource mask being placed
    in a u32.

<--  snip  -->

This patch removes the unused pcibios_update_resource() functions the
kernel gained since, from FRV, m68k, mips & sh architectures.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Acked-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0aea5313
  9. 22 5月, 2008 1 次提交
  11. 29 4月, 2008 1 次提交
  13. 21 4月, 2008 1 次提交
    • G
      PCI: remove initial bios sort of PCI devices on x86 · 1ba6ab11
      由 Greg Kroah-Hartman 提交于 
      We currently keep 2 lists of PCI devices in the system, one in the
driver core, and one all on its own.  This second list is sorted at boot
time, in "BIOS" order, to try to remain compatible with older kernels
(2.2 and earlier days).  There was also a "nosort" option to turn this
sorting off, to remain compatible with even older kernel versions, but
that just ends up being what we have been doing from 2.5 days...

Unfortunately, the second list of devices is not really ever used to 
determine the probing order of PCI devices or drivers[1].  That is done
using the driver core list instead.  This change happened back in the
early 2.5 days.

Relying on BIOS ording for the binding of drivers to specific device
names is problematic for many reasons, and userspace tools like udev
exist to properly name devices in a persistant manner if that is needed,
no reliance on the BIOS is needed.

Matt Domsch and others at Dell noticed this back in 2006, and added a
boot option to sort the PCI device lists (both of them) in a
breadth-first manner to help remain compatible with the 2.4 order, if
needed for any reason.  This option is not going away, as some systems
rely on them.

This patch removes the sorting of the internal PCI device list in "BIOS"
mode, as it's not needed at all anymore, and hasn't for many years.
I've also removed the PCI flags for this from some other arches that for
some reason defined them, but never used them.

This should not change the ordering of any drivers or device probing.

[1] The old-style pci_get_device and pci_find_device() still used this
sorting order, but there are very few drivers that use these functions,
as they are deprecated for use in this manner.  If for some reason, a
driver rely on the order and uses these functions, the breadth-first
boot option will resolve any problem.

Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1ba6ab11
  15. 27 2月, 2008 1 次提交
  17. 26 2月, 2008 2 次提交
  19. 14 2月, 2008 3 次提交
  21. 02 2月, 2008 1 次提交
  23. 28 1月, 2008 8 次提交
  25. 25 1月, 2008 1 次提交
  27. 30 11月, 2007 2 次提交
  29. 07 11月, 2007 1 次提交
    • P
      sh: Kill off the remaining ST40 cruft. · f9669187
      由 Paul Mundt 提交于 
      The ST40 stuff in-tree hasn't built for some time, and hasn't been
updated for over 3 years. ST maintains their own out-of-tree changes
and rebases occasionally, and that's ultimately where all of the ST40
users go anyways.

In order for the ST40 code to be brought up to date most of the stuff
removed in this changeset would have to be rewritten anyways, so there's
very little benefit in keeping the remnants around either.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      f9669187
  31. 30 10月, 2007 1 次提交
  33. 17 10月, 2007 1 次提交
  35. 24 9月, 2007 1 次提交
  37. 21 9月, 2007 6 次提交