Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 1月, 2008 1 次提交
  3. 06 11月, 2007 1 次提交
  5. 13 10月, 2007 2 次提交
  7. 01 8月, 2007 1 次提交
  9. 09 5月, 2007 1 次提交
  11. 03 5月, 2007 2 次提交
  13. 28 4月, 2007 1 次提交
  15. 17 2月, 2007 1 次提交
  17. 08 2月, 2007 3 次提交
  19. 23 1月, 2007 1 次提交
  21. 21 12月, 2006 2 次提交
    • A
      PCI: Fix multiple problems with VIA hardware · 1597cacb
      由 Alan Cox 提交于 
      This patch is designed to fix:
- Disk eating corruptor on KT7 after resume from RAM
- VIA IRQ handling
- VIA fixups for bus lockups after resume from RAM

The core of this is to add a table of resume fixups run at resume time.
We need to do this for a variety of boards and features, but particularly
we need to do this to get various critical VIA fixups done on resume.

The second part of the problem is to handle VIA IRQ number rules which
are a bit odd and need special handling for PIC interrupts. Various
patches broke various boxes and while this one may not be perfect
(hopefully it is) it ensures the workaround is applied to the right
devices only.

From: Jean Delvare <khali@linux-fr.org>

Now that PCI quirks are replayed on software resume, we can safely
re-enable the Asus SMBus unhiding quirk even when software suspend support
is enabled.

[akpm@osdl.org: fix const warning]
Signed-off-by: NAlan Cox <alan@redhat.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1597cacb
    • R
      PCI: use /sys/bus/pci/drivers/<driver>/new_id first · 7461b60a
      由 Russell King 提交于 
      Unfortunately, the .../new_id feature does not work with the 8250_pci
driver.

The reason for this comes down to the way .../new_id is implemented.
When PCI tries to match a driver to a device, it checks the modules
static device ID tables _before_ checking the dynamic new_id tables.

When a driver is capable of matching by ID, and falls back to matching
by class (as 8250_pci does), this makes it absolutely impossible to
specify a board by ID, and as such the correct driver_data value to
use with it.

Let's say you have a serial board with vendor 0x1234 and device 0x5678.
It's class is set to PCI_CLASS_COMMUNICATION_SERIAL.

On boot, this card is matched to the 8250_pci driver, which tries to
probe it because it matched using the class entry.  The driver finds
that it is unable to automatically detect the correct settings to use,
so it returns -ENODEV.

You know that the information the driver needs is to match this card
using a device_data value of '7'.  So you echo 1234 5678 0 0 0 0 7
into new_id.

The kernel attempts to re-bind 8250_pci to this device.  However,
because it scans the PCI driver tables, it _again_ matches the class
entry which has the wrong device_data.  It fails.

End of story.  You can't support the card without rebuilding the
kernel (or writing a specific PCI probe module to support it.)

So, can we make new_id override the driver-internal PCI ID tables?
IOW, like this:


From: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7461b60a
  23. 02 12月, 2006 2 次提交
    • I
      PCI: switch pci_{enable,disable}_device() to be nestable · bae94d02
      由 Inaky Perez-Gonzalez 提交于 
      Changes the pci_{enable,disable}_device() functions to work in a
nested basis, so that eg, three calls to enable_device() require three
calls to disable_device().

The reason for this is to simplify PCI drivers for
multi-interface/capability devices. These are devices that cram more
than one interface in a single function. A relevant example of that is
the Wireless [USB] Host Controller Interface (similar to EHCI) [see
http://www.intel.com/technology/comms/wusb/whci.htm]. 

In these kind of devices, multiple interfaces are accessed through a
single bar and IRQ line. For that, the drivers map only the smallest
area of the bar to access their register banks and use shared IRQ
handlers. 

However, because the order at which those drivers load cannot be known
ahead of time, the sequence in which the calls to pci_enable_device()
and pci_disable_device() cannot be predicted. Thus:

1. driverA     starts     pci_enable_device()
2. driverB     starts     pci_enable_device()
3. driverA     shutdown   pci_disable_device()
4. driverB     shutdown   pci_disable_device()

between steps 3 and 4, driver B would loose access to it's device,
even if it didn't intend to.

By using this modification, the device won't be disabled until all the
callers to enable() have called disable().

This is implemented by replacing 'struct pci_dev->is_enabled' from a
bitfield to an atomic use count. Each caller to enable increments it,
each caller to disable decrements it. When the count increments from 0
to 1, __pci_enable_device() is called to actually enable the
device. When it drops to zero, pci_disable_device() actually does the
disabling.

We keep the backend __pci_enable_device() for pci_default_resume() to
use and also change the sysfs method implementation, so that userspace
enabling/disabling the device doesn't disable it one time too much.
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bae94d02
    • A
      pci: fix __pci_register_driver error handling · 50bf14b3
      由 Akinobu Mita 提交于 
      __pci_register_driver() error path forgot to unwind.
driver_unregister() needs to be called when pci_create_newid_file() failed.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      50bf14b3
  25. 28 10月, 2006 1 次提交
  27. 27 9月, 2006 2 次提交
    • A
      PCI: Multiprobe sanitizer · 50b00755
      由 Alan Cox 提交于 
      There are numerous drivers that can use multithreaded probing but having
some kind of global flag as the way to control this makes migration to
threaded probing hard and since it enables it everywhere and is almost
as likely to cause serious pain as holding a clog dance in a minefield.

If we have a pci_driver multithread_probe flag to inherit you can turn
it on for one driver at a time.

From playing so far however I think we need a different model at the
device layer which serializes until the called probe function says "ok
you can start another one now". That would need some kind of flag and
semaphore plus a helper function.

Anyway in the absence of that this is a starting point to usefully play
with this stuff
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      50b00755
    • G
      PCI: fix __must_check warnings · b19441af
      由 Greg Kroah-Hartman 提交于 
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b19441af
  29. 26 9月, 2006 3 次提交
  31. 27 8月, 2006 1 次提交
  33. 12 6月, 2006 1 次提交
  35. 15 4月, 2006 1 次提交
    • A
      [PATCH] pm: print name of failed suspend function · 02669492
      由 Andrew Morton 提交于 
      Print more diagnostic info to help identify the source of power management
suspend failures.

Example:

usb_hcd_pci_suspend(): pci_set_power_state+0x0/0x1af() returns -22
pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x11b() returns -22
suspend_device(): pci_device_suspend+0x0/0x34() returns -22

Work-in-progress.  It needs lots more suspend_report_result() calls sprinkled
everywhere.

Cc: Patrick Mochel <mochel@digitalimplant.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Nigel Cunningham <nigel@suspend2.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      02669492
  37. 24 3月, 2006 2 次提交
  39. 14 1月, 2006 1 次提交
  41. 05 1月, 2006 1 次提交
  43. 11 11月, 2005 2 次提交
  45. 07 11月, 2005 1 次提交
  47. 31 10月, 2005 1 次提交
    • T
      [PATCH] fix missing includes · 4e57b681
      由 Tim Schmielau 提交于 
      I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the number of indirect includes of sched.h
by ~300. Another ~400 pointless direct includes can be removed after
this disentangling (patch to follow later).
However, quite a few indirect includes need to be fixed up for this.

In order to feed the patches through -mm with as little disturbance as
possible, I've split out the fixes I accumulated up to now (complete for
i386 and x86_64, more archs to follow later) and post them before the real
patch.  This way this large part of the patch is kept simple with only
adding #includes, and all hunks are independent of each other.  So if any
hunk rejects or gets in the way of other patches, just drop it.  My scripts
will pick it up again in the next round.
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4e57b681
  49. 29 10月, 2005 2 次提交
  51. 09 9月, 2005 2 次提交
  53. 07 7月, 2005 1 次提交