Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 04 1月, 2013 1 次提交
    • G
      X86: drivers: remove __dev* attributes. · a18e3690
      由 Greg Kroah-Hartman 提交于 
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitconst,
and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Daniel Drake <dsd@laptop.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a18e3690
  3. 23 6月, 2012 3 次提交
  5. 15 10月, 2011 1 次提交
  7. 12 5月, 2010 1 次提交
  9. 25 11月, 2009 5 次提交
  11. 29 8月, 2009 1 次提交
  13. 30 12月, 2008 1 次提交
  15. 27 4月, 2008 1 次提交
  17. 11 2月, 2008 2 次提交
  19. 11 10月, 2007 2 次提交
  21. 12 8月, 2007 2 次提交
  23. 13 2月, 2007 4 次提交
  25. 03 2月, 2007 2 次提交
  27. 24 12月, 2006 1 次提交
    • O
      [PATCH] arch/i386/pci/mmconfig.c tlb flush fix · 8d1c4819
      由 OGAWA Hirofumi 提交于 
      We use the fixmap for accessing pci config space in pci_mmcfg_read/write().
The problem is in pci_exp_set_dev_base(). It is caching a last
accessed address to avoid calling set_fixmap_nocache() whenever
pci_mmcfg_read/write() is used.

  static inline void pci_exp_set_dev_base(int bus, int devfn)
  {
	u32 dev_base = base | (bus << 20) | (devfn << 12);
	if (dev_base != mmcfg_last_accessed_device) {
		mmcfg_last_accessed_device = dev_base;
		set_fixmap_nocache(FIX_PCIE_MCFG, dev_base);
	}
  }

            cpu0                                        cpu1
  ---------------------------------------------------------------------------
    pci_mmcfg_read("device-A")
        pci_exp_set_dev_base()
            set_fixmap_nocache()
                                              pci_mmcfg_read("device-B")
                                                  pci_exp_set_dev_base()
                                                      set_fixmap_nocache()
    pci_mmcfg_read("device-B")
        pci_exp_set_dev_base()
            /* doesn't flush tlb */

But if cpus accessed the above order, the second pci_mmcfg_read() on
cpu0 doesn't flush the TLB, because "mmcfg_last_accessed_device" is
device-B.  So, second pci_mmcfg_read() on cpu0 accesses a device-A via
a previous TLB cache. This problem became the cause of several strange
behavior.

This patches fixes this situation by adds "mmcfg_last_accessed_cpu" check.

[ Alternatively, we could make a per-cpu mapping area or something. Not
  that it's probably worth it, but if we wanted to avoid all locking and
  instead just disable preemption, that would be the way to go. --Linus ]
Signed-off-by: NOGAWA Hirofumi <hogawa@miraclelinux.com>
Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8d1c4819
  29. 09 11月, 2006 1 次提交
  31. 01 10月, 2006 1 次提交
  33. 26 9月, 2006 3 次提交
  35. 19 9月, 2006 1 次提交
    • L
      Revert mmiocfg heuristics and blacklist changes · 79e453d4
      由 Linus Torvalds 提交于 
      This reverts commits 11012d41 and
40dd2d20, which allowed us to use the
MMIO accesses for PCI config cycles even without the area being marked
reserved in the e820 memory tables.

Those changes were needed for EFI-environment Intel macs, but broke some
newer Intel 965 boards, so for now it's better to revert to our old
2.6.17 behaviour and at least avoid introducing any new breakage.

Andi Kleen has a set of patches that work with both EFI and the broken
Intel 965 boards, which will be applied once they get wider testing.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      79e453d4
  37. 31 8月, 2006 2 次提交
    • A
      [PATCH] x86: Disable MMCONFIG on Intel SDV using DMI blacklist · 40dd2d20
      由 Andi Kleen 提交于 
      As a replacement for the earlier removal of the e820 MCFG check
we blacklist the Intel SDV with the original BIOS bug that
motivated that check. On those machines don't use MMCONFIG.

This also adds a new pci=mmconf parameter to override the blacklist.

Cc: Greg KH <gregkh@suse.de>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      40dd2d20
    • A
      [PATCH] x86: Revert e820 MCFG heuristics · 11012d41
      由 Andi Kleen 提交于 
      The check for the MCFG table being reserved in the e820 map was originally
added to detect a broken BIOS in a preproduction Intel SDV. However it also
breaks the Apple x86 Macs, which can't supply this properly, but need
a working MCFG. With this patch they wouldn't use the MCFG and not work.

After some discussion I think it's best to remove the heuristic again.
It also failed on some other boxes (although it didn't cause much
problems there because old style port access for PCI config space
still works as fallback), but the preproduction SDVs can just use
pci=nommcfg. Supporting production machines properly is more
important.

Edgar Hucek did all the debugging work.

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Edgar Hucek <hostmaster@ed-soft.at>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      11012d41
  39. 27 8月, 2006 1 次提交
  41. 22 6月, 2006 1 次提交
    • C
      [PATCH] PCI: fix issues with extended conf space when MMCONFIG disabled because of e820 · ead2bfeb
      由 Chuck Ebbert 提交于 
      On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote:

> Anyways I would say that if the BIOS can't get MCFG right then
> it's likely not been validated on that board and shouldn't be used.

According to Petr Vandrovec:

 ... "What is important (and checked) is address of MMCONFIG reported by MCFG
 table...  Unfortunately code does not bother with printing that address :-(

 "Another problem is that code has hardcoded that MMCONFIG area is 256MB large.
 Unfortunately for the code PCI specification allows any power of two between 2MB
 and 256MB if vendor knows that such amount of busses (from 2 to 128) will be
 sufficient for system.  With notebook it is quite possible that not full 8 bits
 are implemented for MMCONFIG bus number."

So here is a patch.  Unfortunately my system still fails the test because
it doesn't reserve any part of the MMCONFIG area, but this may fix others.

Booted on x86_64, only compiled on i386.  x86_64 still remaps the max area
(256MB) even though only 2MB is checked... but 2.6.16 had no check at all
so it is still better.

PCI: reduce size of x86 MMCONFIG reserved area check

1.  Print the address of the MMCONFIG area when the test for that area
    being reserved fails.

2.  Only check if the first 2MB is reserved, as that is the minimum.
Signed-off-by: NChuck Ebbert <76306.1226@compuserve.com>
Acked-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ead2bfeb
  43. 11 4月, 2006 1 次提交
  45. 10 4月, 2006 2 次提交