trivial iomem annotations + memset() replaced with memset_io() in a
place that deals with ioremapped area.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Convert 8250_hp300 to use serial8250_register_port() and
serial8250_unregister_port().
Tested by Kars de Jong, 4/4/2005.
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
tg3_restart_ints() is called to re-enable interrupts after tg3_poll()
has finished all the work. It calls tg3_cond_int() to force an interrupt
if the status block updated bit is set. The updated bit will be set if
there is a new status block update sometime during tg3_poll() and it can
be very often. The worst part is that even if all the work has been
processed, the updated bit remains set and an interrupt will be forced
unnecessarily.
The fix is to call tg3_has_work() instead to determine if new work is
posted before forcing an interrupt. The way to force an interrupt is
also changed to use "coalesce_now" instead of "SETINT". The former is
generally a safer way to force the interrupt.
Also deleted the first parameter to tg3_has_work() which is unused.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch refreshes the hw rx producer in tg3_rx() so that additional
work posted by the hardware can be processed.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes a bug that causes tg3_has_work() to always return 1.
rx work is determined by comparing tp->rx_rcb_ptr with the current hw
producer index. The hw producer index is modulo the ring size, but tp-
>rx_rcb_ptr is a free running counter that goes up beyond the ring size.
After the ring wraps around once, tg3_has_work() will always return 1.
The fix is to always do modulo arithmetic on tp->rx_rcb_ptr.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The following is an update of the patch I sent yesterday
(3/9/05) incorporating suggestions from Christoph Hellwig and
Andreas Schwab. It allows Altix and Altix-like systems to
handle environmental events generated by the system controllers,
and should apply on top of Jack Steiner's patch of 3/1/05 ("New
chipset support for SN platform") and Mark Goodwin's patch of
3/8/05 ("Altix SN topology support for new chipsets and pci
topology").
Signed-off-by: Greg Howard <ghoward@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This patch is to provide CX port infrastructure for SGI TIO-based
h/w. Also a 'core services' driver for SGI FPGA-based h/w.
Signed-off-by: Bruce Losure <blosure@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This enables the sun linux logo to be selected on sparc32.
Signed-off-by: Bob Breuer <breuerr@mc.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Using the same logic as the other framebuffer fixes committed in 2.6.11,
this is a set of fixes to make TCX functional on the console again. Adds
the tcx_pan_display function, sets the
all->info.var.{red,green,blue}.length values to 8, and runs fb_set_cmap.
Also looks for the correct SUNW,tcx prom value.
This patch just slipped through the cracks.
Originally by: Georg Chini <georg.chini@triaton-webhosting.com>
Signed-off-by: Tom 'spot' Callaway <tcallawa@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Minor cleanups for sparc specific drivers (sunbmac, sunqe, sunlance,
sunhme, esp) so that they have a full module version definition that is
consistent with other upstream drivers.
Signed-off-by: Tom 'spot' Callaway <tcallawa@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
From: Panagiotis Issaris <takis@lumumba.luc.ac.be>
In the ENI155P device driver in six possible failure cases the requested
irq is not being released.
In three of the above possible failure cases additionally there seems to
be a memory leak.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replacing the open coded equivalents and making ax25 look more like
a linux network protocol, i.e. more similar to inet.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
void * __iomem foo is not a pointer to iomem - it's an iomem variable
containing void *. A pile of such guys in arch/sparc64/kernel/time.c,
drivers/sbus/char/rtc.c and include/asm-sparc64/mostek.h turned into
intended void __iomem *.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
(!ARCH_S390 && !M68K && !IA64 && !UML) is obviously always true on ARM.
Intended behaviour for ARM is "absent unless we are on RiscPC or
EBSA285". So what we want is added && !ARM in the first term - without
it the last part (|| ARCH_RPC || ARCH_EBSA285, that is) doesn't do
anything.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Missing include, breaks at least on arm.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
All boards dealt with by I2C_MPC are 32bit. Moreover, driver simply
won't build on ppc64 - it uses ppc32-only types all over the place.
Dependency fixed - it's PPC32, not PPC.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Somebody forgot that | has higher priority than ?:. As the result,
allocation is done with bogus flags - instead of GFP_ATOMIC + possibly
GFP_DMA we always get GFP_DMA and no GFP_ATOMIC.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
when stealing code from ati_remote for a GPL-driver of my usbradio (because of
its neat usb int transfers) I found out, that the inbuf is freed twice.
I don't have the ati-remote, so I don't know it is a problem at all, but it
looks strange to me anyway. Also I don't know if it has been fixed already in
newer kernel versions.
From: Patrick Boettcher <patrick.boettcher@desy.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is a somewhat more comprehensive fix for the problem of devices
like the newer Zaurii ... or in this case some Motorola cell phones.
To recap, the problem's root cause is that these devices aren't using
standard USB class specifications for their network links, and so far
we've had to add lots of device-specific driver entries. The vendor
fix abuses the CDC MDLM descriptors (they _could_ have conformed to
the spec, but didn't) and defines a "Belcarra firmware" pseudo-class.
This patch recognizes that pseudo-class by the GUIDs in those descriptors,
and handles the devices that just use the Zaurus framing.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Modify the ASIX USB Ethernet code to make use of the new status
infrastructure in usbnet.
Additionally, add a link_reset() handler to the struct usbnet
structure to provide a generic means for a driver to perform link
reset tasks such as a determining link speed and setting
device flags accordingly.
Signed-off-by: David Hollis <dhollis@davehollis.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The patch below adjusts the MODALIAS generated by the usb hotplug
function to match the proposed change to scripts/mod/file2alias.c.
Signed-off-by: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Phil Dibowitz wrote:
> 1. You're adding product IDs 1202, 1203, 1204, and 1205. 1203 was
> already there, but you remove it, OK, but 1205 is already there, so
> you'll need to fix that.
I was not removing 1203, it's just the extension of the bcd range. You are
right about 1205, as I wrote, it was a patch against 2.6.11.7. Attached is
a patch against 2.6.12-rc2.
> 2. I'm OK with the full bcd range if Apple is changing it on firmware
> revs... fine, but it's bcd, not hex... 0x9999 =)
I just copied from other entries. There're a lot 0xffffs in unusual_dev.h,
so I assumed it is correct. I changed it to 0x9999.
> 3. It's rather obnoxious to take the original submitter's credit away.
I didn't remove it, I changed it to "based on...". Because I changed
something (the range) in his entry, I thought it is the best to take the
responsibility but keep the origin. Anyway, in the new patch I did it in a
different way.
> 4. Your /proc/bus/usb/devices shows 1204, but I see no evidence 1202 is
> really an iPod.
I don't have an old iPod mini, but you find a lot of evidence here:
http://www.google.com/search?q=0x1202+ipod
Especially this one:
http://www.qbik.ch/usb/devices/showdescr.php?id=2737
> It also looks like 1205's entry is getting mangled, but I haven't
> attempted to apply the patch, so I'm not sure.
No, the patch was ok, but I agree it looks strange. It's not very
readable, because I cannot tell diff to work blockwise instead of
linewise. Because of the similarity of the entries, diff splits and merges
them. Anyway, the new patch "looks" better. ;-)
Signed-off-by: Sven Anderson <sven-linux@anderson.de>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We were forgetting to call sunsu_change_speed(). The reason
that replugging in the mouse cable "fixes things" is that
causes a BREAK interrupt which in turn caused a call to
sunsu_change_speed() which would get the chip setup properly.
Signed-off-by: David S. Miller <davem@davemloft.net>
Provide support for drivers/char/rtc.c ioctls in the
Mostek rtc driver as well as the Sparc specific RTCGET
and RTCSET.
This allows userspace to be much less messy. Currently
util-linux and other spots jump through hoops trying
various ioctl variants until it hits the right one whatever
driver actually being used supports.
Eventually all of this should move over to the genrtc.c
driver, but not today...
While we are here, fix up the register types for sparse.
Thanks to Frans Pop for helping point out this issue.
Signed-off-by: David S. Miller <davem@davemloft.net>
Add MSI test for chips that support MSI. If MSI test fails, it will
switch back to INTx mode and will print a message asking the user to
report the failure.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix a bug in tg3_set_eeprom() when the length is less than 4 and the
offset is not 4-byte aligned.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support for the NVRAM lock-out feature for TPM in 5752. If lock-out
is enabled, certain NVRAM registers cannot be written to.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add bit definitions for the new GPIO3 in 5752. GPIO3 must be driven as
output when it is unused.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The 5752 A0 chip ID is wrong in hardware. The simplest way to workaround
it is to change it to the correct value in tp->pci_chip_rev_id. This
way, it is easier to check for the ASIC_REV_5752 in the rest of the
driver.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix tg3_set_power_state to drive GPIOs properly based on the
TG3_FLAG_EEPROM_WRITE_PROTECT flag. Some delays are also added after D0
and D3 power state changes.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Setup proper GPIO settings in tp->grc_local_ctrl before calling
tg3_set_power() state in tg3_get_invariants() and after chip reset.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Split the 1st half of tg3_phy_probe() into tg3_get_eeprom_hw_cfg() so
that the TG3_FLAG_EEPROM_WRITE_PROT can be determined before calling
tg3_set_power_state() in tg3_get_invariants(). This will allow
tg3_set_power_state() to drive the GPIOs correctly based on the config.
information in eeprom.
On the 5752, there are no pull-up resistors on the GPIO pins and it is
necessary to drive the unused GPIOs as output.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some minor 5752 fixes mostly for correctness and add 5752 PHY ID.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace existing ASIC_REV_5752 definition with ASIC_REV_5752_A0,
and add definition for ASIC_REV_5752_A1. Then, add ASIC_REV_5752_A1
to check for setting TG3_FLG2_5750_PLUS in tg3_get_invariants.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use check of TG3_FLG2_5750_PLUS in tg3_get_invariants to set
TG3_FLG2_5705_PLUS flag.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Rewrite checks in tg3_get_invariants to use TG3_FLG2_5705_PLUS and
TG3_FLG2_5750_PLUS flags.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Rewrite of a couple of troublesome multi-way if statements to use
TG3_FLG2_5705_PLUS flag.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace a number of two-way if statements checking for 5750, and/or
5752 to reference the newly-defined TG3_FLG2_5750_PLUS flag instead.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Define TG3_FLG2_5750_PLUS flag and set it in tg3_get_invariants for
ASIC_REV_5750 or ASIC_REV_5752.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Replace a number of three-way if statements checking for 5705, 5750,
and 5752 to reference the equivalent TG3_FLG2_5705_PLUS flag instead.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add proper entry for bcm5752 PCI ID to pci_ids.h, and use it in tg3.
I did this separately in case patches like this (i.e. new PCI IDs)
need to come from more "official" sources.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add hard-coded definition of bcm5752 PCI ID to tg3_pci_tbl.
Next patch will change entry to use pci_ids.h-based definition.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add ASIC_REV_5752 definition.
Track-down all references to ASIC_REV_5750 and mirror them with
references to the newly defined ASIC_REV_5752.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix non-legacy multichannel ISO receive, broken by Parag Wardukar's
allocation fix. Multichannel ISO receive still sucks; it should be possible
to use both legacy and non-legacy modes at the same time, but with this
patch, things are no worse than they were in 2.6.11 and allocation is
still done at the correct time.
Signed-off-by: Jody McIntyre <scjody@steamballoon.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- Print the correct value in the DBGMSG in dma_rcv_tasklet().
See OHCI 1.1 section 8.7, page 103 ff.
- Print tlabels as %d everywhere.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@steamballoon.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We do not longer use DLT_LINUX_SLL for activ/pass filters but
DLT_PPP_WITHDIRECTION witch need 1 as outbound flag.
Signed-off-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
My version of gcc doesn't warn about this error (declaration in the
middle of a set of statements).
The fix is simple (this also corrects return code; for init functions it
should be zero or error).
I can't use list.h, since sk_buff doesn't have a list_head but instead
has two struct sk_buff pointers, and I want to avoid any extra memory
allocation.
send outgoing packets in order
Signed-off-by: Ed L. Cashin <ecashin@coraid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kobject_add() and kobject_del() don't emit hotplug events anymore.
We need to do it ourselves now.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kobject_add() and kobject_del() don't emit hotplug events anymore. Do it
ourselves if we are finished populating the device directory.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kobject_add() and kobject_del() don't emit hotplug events anymore. Do it
ourselves if we are finished populating the device directory.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
platform_add_devices can be used from within modules, so it should be
exported. This can for example happen if you have hotpluggable firmware in
an FPGA on a system on chip processor; in our case the FPGA is probed for
devices and the FPGA base code registers the devices it has found with the
kernel.
(akpm: I think this is reasonable from a licensing POV: it's unlikely that
anyone would be interested in merging such specialised modules into mainline,
and it's a GPL export).
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:
> The current implementation of the firmware class breaks a fundamental
> assumption in udevd: that the physical device can be initialised fully
> prior to executing the next event for that device.
Here we add a TIMEOUT value to the hotplug environment of the firmware
requesting event. I will adapt udevd not to wait for anything else, if
it finds a TIMEOUT key.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.
As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here comes a small cleanup patch for the via686a driver. I noticed the
following two non-fatal problems:
1* The device parent is explicitely set, but it's not needed because the
i2c core will do as the client is registered.
2* snprintf is used where strlcpy would suffice.
Fixing them brings the via686a driver in line with what other similar
drivers do.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
