Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 2月, 2007 5 次提交
  3. 15 2月, 2007 2 次提交
    • T
      [PATCH] Scheduled removal of SA_xxx interrupt flags fixups · 38515e90
      由 Thomas Gleixner 提交于 
      The obsolete SA_xxx interrupt flags have been used despite the scheduled
removal.  Fixup the remaining users.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Wim Van Sebroeck <wim@iguana.be>
Cc: Roland Dreier <rolandd@cisco.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Greg KH <greg@kroah.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: James Simmons <jsimmons@infradead.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      38515e90
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      由 Tim Schmielau 提交于 
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there.  Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.

To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.

Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm.  I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  5. 12 2月, 2007 1 次提交
  7. 10 2月, 2007 2 次提交
  9. 08 2月, 2007 19 次提交
  11. 23 1月, 2007 1 次提交
  13. 06 1月, 2007 2 次提交
  15. 21 12月, 2006 7 次提交
    • T
      USB: u132-hcd/ftdi-elan: add support for Option GT 3G Quad card · 4b87361d
      由 Tony Olech 提交于 
      ELAN's U132 is a USB to CardBus OHCI controller adapter,
    designed specifically for CardBus 3G data cards to
    function in machines without a CardBus slot.
The "ftdi-elan" module is a USB client driver, that detects
    a supported CardBus OHCI controller plugged into the
    U132 adapter and thereafter provides the conduit for
    for access by the "u132-hcd" module.
The "u132-hcd" module is a (cut-down OHCI) host controller
    that supports a single OHCI function of the CardBus 
    card inserted into the U132 adapter.

The problem with the initial implementation is that when
the CardBus card inserted into the U132 adapter has multiple
functions (and a CardBus card can support up to 4 functions),
it was the first function that was arbitrarily choosen.

The first batch of 3G cards tested, like the Merlin Qualcomm
V620, have two functions each supporting a seperate USB OHCI
host controller, of which it was that first function that is
wired up to the 3G modem.

Then along comes the Vodafone Mobile Connect 3G/GPRS data card,
aka "Option GT 3G Quad" as printed on it's rear or "Option N.V.
GlobeTrotter Fusion Quad Lite" as read with "lspci -v". And it
has the meaningful functionality in the second CardBus function.

That presents a problem because it was the "ftdi-elan" module
alone that knows how to communicate to the embedded CardBus slot
and the "u132-hcd" module alone that knows how to access the
pcmcia configuration and CardBus accessible memory space. And
of course, the information about attached (internally hardwired)
devices is contained within USB configuration embedded somewhere
within the CardBus card.

If only the "u132-hcd" module probe() interface could return a
result code that propagated back to the instigating function
platform_device_register() then the "ftdi-elan" module could
try an alternative CardBus function.     However in spite of
the recent changes to the drivers/base/ routines that moved 
device_attach() from bus_add_device() to bus_attach_device()
both of those routines lose the "failed to attach" 0 result
code and thus the calling routine, namely device_add() is
incapable of propaging the "failed to attach" condition back
to platform_device_add() and consequently back to the caller
of platform_device_register()

Experiments show that patching bus_attach_device() to return
ENODEV fails with the kernel locking up very early during
boot. But, however, if the patch is restricted to calls from
platform_device_add() then it does seem to work.

Unfortunately, until the kernel's drivers/base is properly
modified to propagate -ENODEV back to the caller of
platform_device_register(), it is necessary to "fix" the
"ftdi-elan" module by importing knowledge from the 
"u132-hcd" module. This is the reason for the duplicated
functionality introduced in this patch.
Signed-off-by: NTony Olech <tony.olech@elandigitalsystems.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4b87361d
    • V
      USB: OHCI support for PNX8550 · 5151d040
      由 Vitaly Wool 提交于 
      OHCI HCD (Host Controller Driver) for USB. Bus Glue for PNX8550.
Signed-off-by: NVitaly Wool <vitalywool@gmail.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5151d040
    • T
      USB: ohci handles hardware faults during root port resets · 23d10a9e
      由 Takamasa Ohtake 提交于 
      I have found a problem where the root_port_reset() goes into an infinite
loop and stalls the kernel.

This happens when a hardware fault inside the machine occurs during a small
timing window.  In case of USB device connection, if a USB device responds to
hcd_submit_urb(), and later the controller fails before root_port_reset(),
root_port_reset() will loop infinitely because ohci_readl() will always
return "-1".  Such a failure can include ejecting a CardBus OHCI controller.

The probability of this problem is low, but it will increase if PnP type
usage is frequent.  The attached patch can solve this problem and I believe
that it is better to fix this problem.
Signed-off-by: NTakamasa Ohtake <ohtake-txa@necst.nec.co.jp>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      23d10a9e
    • A
      USB: ohci at91 warning fix · ee269d98
      由 Andrew Victor 提交于 
      Remove a warning about an unused variable in the OHCI bus glue for at91.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ee269d98
    • D
      USB: ohci whitespace/comment fixups · dd9048af
      由 David Brownell 提交于 
      This is an OHCI cleanup patch ... it removes a lot of erroneous whitespace
(space before tab, at end of line) as well as the obsolete inline changelog.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      dd9048af
    • A
      UHCI: module parameter to ignore overcurrent changes · 5f8364b7
      由 Alan Stern 提交于 
      Certain boards seem to like to issue false overcurrent notifications,
for example on ports that don't have anything connected to them.  This
looks like a hardware error, at the level of noise to those ports'
overcurrent input signals (or non-debounced VBUS comparators).  This
surfaces to users as truly massive amounts of syslog spam from khubd
(which is appropriate for real hardware problems, except for the
volume from multiple ports).

Using this new "ignore_oc" flag helps such systems work more sanely,
by preventing such indications from getting to khubd (and spamming
syslog).  The downside is of course that true overcurrent errors will
be masked; they'll appear as spontaneous disconnects, without the
diagnostics that will let users troubleshoot issues like
short-circuited cables.  In addition, controllers with no devices
attached will be forced to poll for new devices rather than relying on
interrupts, since each overcurrent event would generate a new
interrupt.

This patch (as826) is essentially a copy of David Brownell's ignore_oc
patch for ehci-hcd, ported to uhci-hcd.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5f8364b7
    • J
      USB: fix ohci.h over-use warnings · abc9404b
      由 Jeff Garzik 提交于 
      When u132-hcd is built, it includes local header ohci.h, which appears
to have been intended only for use by ohci-hcd.

This throws warnings about functions which are defined and not used.
The warnings thrown are because three small functions are implemented in
the header, but not declared 'inline', a rather strange affair.

Since these functions are small, let's go ahead and define them as
'inline', just like the inline functions surrounding them.  This makes
things more consistent, and kills the warnings.
Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      abc9404b
  17. 14 12月, 2006 1 次提交
    • R
      [PATCH] getting rid of all casts of k[cmz]alloc() calls · 5cbded58
      由 Robert P. J. Day 提交于 
      Run this:

	#!/bin/sh
	for f in $(grep -Erl "\([^\)]*\) *k[cmz]alloc" *) ; do
	  echo "De-casting $f..."
	  perl -pi -e "s/ ?= ?\([^\)]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f
	done

And then go through and reinstate those cases where code is casting pointers
to non-pointers.

And then drop a few hunks which conflicted with outstanding work.

Cc: Russell King <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Greg KH <greg@kroah.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Paul Fulghum <paulkf@microgate.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Karsten Keil <kkeil@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Ian Kent <raven@themaw.net>
Cc: Steven French <sfrench@us.ibm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cbded58