This affects of course only the "soft shutdown" case, e.g. "modprobe -r
firewire-sbp2", while it doesn't matter for hot unplug.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
This currently only affects one bridge in the hardwired blacklist.
I don't own one of those, hence haven't tested it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
cleanup after "firewire: support S100B...S400B and link slower than PHY"
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Use a speed probe to determine the speed over 1394b buses and of nodes
which report a link speed less than their PHY speed.
Log the effective maximum speed of newly created nodes in dmesg.
Also, read the config ROM (except bus info block) at the maximum speed
rather than S100. This isn't a real optimization though because we
still only use quadlet read requests for the entire ROM.
The patch also adds support for S1600 and S3200, although such hardware
does not exist yet.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Table-based gap count optimization cannot be used if 1394b repeater PHYs
are present. But it does work with 1394b leaf nodes.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
cleanup after support of single-buffer requests was dropped
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Kristian Hoegsberg <krh@redhat.com>
Based on patch "the scheduled removal of RAW1394_REQ_ISO_{SEND,LISTEN}"
from Adrian Bunk, November 20 2006.
This patch also removes the underlying facilities in ohci1394 and
disables them in pcilynx. That is, hpsb_host_driver.devctl() and
hpsb_host_driver.transmit_packet() are no longer used for iso reception
and transmission.
Since video1394 and dv1394 only work with ohci1394 and raw1394's rawiso
interface has never been implemented in pcilynx, pcilynx is now no
longer useful for isochronous applications.
raw1394 will still handle the request types but will complete the
requests with errors that indicate API version conflicts.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This is upwards compatible, except that integer values other than 0 or 1
are no longer accepted. But values like "Y", "N", "no", "nnoooh!" work
now.
Also, improve a comment on the serialize_io parameter and make the
ORB_SET_EXCLUSIVE macro ultra-safe.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Association of a host device with a node on NUMA machines optimizes
allocations of skbs given from the networking stack to eth1394.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
After ieee1394 was converted away from class_device like the networking
subsystem was already in 2.6.21, eth1394's device may point to the
fw-host device as its parent again like in 2.6.20.
This affects userspace tools which examine the sysfs representation of
eth1394's device.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Remove the global nodemgr_serialize mutex which enclosed most of the
host thread event loop. This allows for parallelism between several
host adapter cards.
Properly serialize the driver hooks .update(), .suspend(), .resume(),
and .remove() by means of device->sem. These hooks can be called from
outside the host threads' contexts.
Get() and put() the device.driver when calling its hooks.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Here is a straightforward conversion to "struct device". The "struct
class_device" will be removed from the kernel.
It seems to work fine for me with and without CONFIG_SYSFS_DEPRECATED
set.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
I was told that only i386 aligns 64 bit integers at 4 bytes boundaries
while all other architectures (32 bit architectures with 64 bit
siblings) align it on 8 bytes boundaries.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Pointed out by Arnd Bergmann: PPC32 aligns this at 64bit, IA32 packs
it. A kernel-wide available __compat_u64 which is 4-byte aligned on
AMD64 and IA64 would be nicer though.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Add compat_ioctl. Although all structures are more or less same,
raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted
padding in the middle. I did not add any translation for ioctls passing array
of integers around as integers seem to have same size (32 bits) on all
architectures supported by Linux.
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Acked-by: Dan Dennedy <dan@dennedy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
* write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not
care, but some (arm registration) did, and anyway it looks bad if request for
writing 52 bytes returns 56. And returning sizeof anything in 'int' is not
good as well. So all functions now return '0' instead of
sizeof(struct raw1394_request) on success, and write() itself provides correct
return value (it just returns value it was asked to write on success as raw1394
does not do any partial writes at all).
* Related to this was problem that write() could have returned 0 when kernel
state would become corrupted and moved to different state than
opened/initialized/connected. Now it returns -EBADFD which seemed appropriate.
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Acked-by: Dan Dennedy <dan@dennedy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
read() always failed with -EFAULT. This was happening due to
raw1394_compat_read copying data to wrong location - access_ok always
failed as 'r' is kernel address, not user. Whole function just tried to
copy data from 'r' to 'r', which is not good.
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Acked-by: Dan Dennedy <dan@dennedy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
Backport short cables support from pata_via.c.
This patch should allow UDMA > 2 modes on Acer Ferrari 3400.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Backport short cables support from pata_sis.c.
This patch allows UDMA > 2 modes on ASUS A6K.
Thanks to testing this patch goes out to Jiri Stavinoha.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Backport short cables support from pata_ali.c and while at it cleanup
existing cable detection code.
This patch should allow UDMA > 2 modes on HP Pavilion N5430 and Fujitsu P2000.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Backport short cables support from ata_piix.c.
This patch should allow UDMA > 2 modes on:
- Acer 5602WLMi
- Acer 3682WLMi
- Asus W5F
- Acer Aspire 2023WLMi
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
This patch allows users to override both host and device side cable detection
with "ideX=ata66" kernel parameter. Thanks to this it should be now possible
to use UDMA > 2 modes on systems (laptops mainly) which use short 40-pin cable
instead of 80-pin one.
Next patches add automatic detection of some systems using short cables.
Changes:
* Rename hwif->udma_four to hwif->cbl and make it u8.
* Convert all existing users accordingly (use ATA_CBL_* defines while at it).
* Add ATA_CBL_PATA40_SHORT support to ide-iops.c:eighty_ninty_three().
* Use ATA_CBL_PATA40_SHORT for "ideX=ata66" kernel parameter.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Reviewed-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
ide-timing.h:
* remove handling of DMA modes from ide_find_best_mode() and rename it to
ide_find_best_pio_mode()
* drop no longer needed "map" argument from ide_find_best_pio_mode()
and delete needless ->id check
* remove no longer needed XFER_SWDMA and XFER_UDMA* defines
au1xxx-ide.c:
* use ide_max_dma_mode() instead of ide_find_best_mode()
* remove needless CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA #ifdef
amd74xx.c:
* store UDMA masks in amd_ide_chip[] and while at it make "base" field
to be u8 instead of unsigned long
* convert the driver to use UDMA masks from amd_ide_chip[]
* use ide_max_dma_mode() and ide_find_best_pio_mode() instead
of ide_find_best_mode()
* delete stale comment from amd74xx_ide_dma_check()
* remove no longer needed AMD_UDMA* defines
via82cxxx.c:
* remove unused DISPLAY_VIA_TIMINGS define
* store UDMA masks in via_isa_bridges[] and while at it make "flags" field
to be u8 instead of u16
* convert the driver to use UDMA masks from via_isa_bridges[]
* use ide_max_dma_mode() and ide_find_best_pio_mode() instead
of ide_find_best_mode()
* remove no longer needed VIA_UDMA* defines
pmac.c:
* use ide_max_dma_mode() instead of ide_find_best_mode()
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Reviewed-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
This patch replaces an array size calculation in drivers/ide/legacy/hd.c
that was done using sizeof with the ARRAY_SIZE macro.
Tested by compilation on an i386 box using "allyesconfig".
Diffed against Linus' git-tree.
Signed-off-by: Andi Drebes <lists-receive@programmierforen.de>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Delete the unnecessary macro ARY_LEN and use ARRAY_SIZE directly.
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
This removes the support to treat "ALL" as a wildcard for
firmware revision. This is made a separate patch, as it will
break out-of-tree ide drivers that feed its own table that uses
"ALL" as the wildcard to ide_in_drive_list().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Earlier, the matching of (model,rev) in ide-dma black/white list
handling was to consider "ALL" in the table to match any
revision. This makes NULL to be also an accepted wildcard, and
changes the entries of tables in ide-dma.c to use NULL.
The code still accepts "ALL" as the wildcard, in order to keep
any out-of-tree ide driver that feeds its own table that uses
"ALL" as the wildcard to ide_in_drive_list() function from
breaking.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
There's no reason to have the speedproc() method wrapper for the two quite
different chip families, so just get rid of it.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The IDE driver uses a semaphore as mutex.
Use the mutex API instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
--
Get rid of the init_dma() method (which had no particular reason to exist) by
folding it into the init_hwif() method. While at it, also perform some cleanup
in the latter method:
- get rid of the useless clearing of hwif->autodma;
- fold the serialization code into one 'if' statement;
- fold setting the drives' 'autotune' and 'autodma' fields into the single
statements...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Rework init_setup_aec6x80() so that it won't rewrite the constant name strings
anymore -- in order to do this:
- in aec62xx_init_one(), pass a local copy of 'struct pci_device_id' down the
call chain;
- change the names for in aec62xx_chipsets[] to default to AEC-6280[R];
- override the 'name' field in init_setup_aec6x80() only if bit 4 of the DMA
status register is set.
While at it, also change the 'udma_mask' field for AEC-6x80R chips in this
function and remove the code doing the same from the init_hwif() method...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Fix two minor issues with PCI0646 chip reporting in the init_chipset() method:
"IRQ workaround enabled" message printed out not only for revision 0x01 and
"CMD646: chipset revision" printed twice (by IDE core and the driver itself).
Also, remove empty/pointless switch cases for the chips other than PCI0646,
duplicate write to the MRDMODE register when enabling interrupts and MEMORY
READ LINE cycles, and needless/misplaced initialization of the timing registers
in this method.
Switch to reading only the PCI revision ID register itself, not the whole 32
bits at its address in init_chipset() and init_hwif() methods; in addition,
get rid of the useless clearing of hwif->autodma and perform some cosmetic
style changes in the latter method.
Refactor ata66_cmd64x() by moving all the code into the 'switch' statement,
renaming/adding variables, and fixing the coding style.
While at it, finally get rid of the meaningless aliasing register #define's...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Simplify UltraDMA mode filtering in the driver:
- make use of the newly introduced 'udma_mask' field of 'ide_pci_device_t' to
set the correct hwif->ultra_mask, modifying init_setup_hpt366() to select
the correct mask based on the chip revision;
- replace 'max_mode' field of the 'struct hpt_info' with 'max_ultra' specifying
the maximum UltraDMA mode allowed;
- rewrite hpt3xx_udma_filter() to differ the filters based on the 'chip_type'
field, and only use it for HPT366 and HPT370[A] where it's really necessary.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The IDE driver uses a semaphore as mutex.
Use the mutex API instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Since ide_dma_timeout() method's result is discarded, make it return 'void'.
While at it, drop 'ide_' from the method's name, drop the '__' prefix from
the default method's name, and do some cleanups in this method driver-wise:
- in ide-dma.c, au1xxx-ide.c, and pdc202xx_old.c, define/use 'hwif' variable;
- in au1xxx-ide.c, get rid of commented out printk();
- in sl82c105.c, get rid of unnecessary variables.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Since ide_dma_lostirq() method's result is discarded, make it return 'void'.
While at it, rename the method to dma_lost_irq(), drop the '__' prefix from the
default method's name, and do some cleanups in this method driver-wise:
- in aec62xx.c, rename the method in accordance with other drivers, and get rid
of unnecessary variables there;
- in pdc202xx_old.c, define/use 'hwif' variable;
- in sgiioc4.c, rearrange the code to call the resetproc() method directly.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Switch the driver to always program DMA/PIO timings and set device transfer
mode instead of trusting BIOS on CSB6 controllers (libata pata_serverworks.c
driver is also doing things this way and there were no problems reported so
far). While doing conversion I noticed that the old code had many issues:
* the code was assuming that hwif->dma_status is always valid
(which obviously isn't true if hwif->dma_base == NULL)
* value of "(ultra_timing >> (4*unit)) & ~(0xF0)" expression wasn't checked
to fit into udma_modes[5]
* code validating DMA timings didn't validate corresponding PIO timings
* extra CSB5 PIO register wasn't validated et all
* hwif->ide_dma_off_quietly() is always called before ide_set_dma() (which in
turn calls hwif->speedproc() method - svwks_tune_chipset() in this case)
so the code depending on DMA capable bit of DMA status to be set was never
executed (=> the code was never validating DMA timings despite actually
enabling DMA if the PIO timings were OK!)
* on resume driver dependend entirely on BIOS to restore timings and set
transfer mode on the device
While at it:
There is no need to read PIO/MWDMA timings now so don't do it.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
There are some devices (for example Dell Multimedia Keyboard SK-8135) that have
a volume control knob which generates relative events instead of absolute.
hid-input maps them to ABS_VOLUME. HUT pages don't restrict volume to absolute
values.
Adding REL_VOLUME doesn't seem feasible, nothing knows how to handle it. This
patch translates relative ABS_VOLUME events into appropriate number of series
of VOLUME_UP or VOLUME_DOWN events respectively, so that userspace sees the
correct values in the end.
kernel.org bugzilla 5233
Reported-by: Jochen Eisinger <jochen@penguin-breeder.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This keyboard has wireless mouse which has left, middle, right buttons and
2-dimensional scrolling wheel. Unfornetuly, this wheel reports side scrolling
events and 11 or 12 button events at the same time.
I've wrote a patch to fix this mapping. I'm not sure if this mapping is proper
for buttons, because , for example, there is no entry for "burn cd" in input.h.
The patch also supress 11 and 12 button events from mouse when you scroll the
wheel left and right. With this patch, only side scrolling events are
reported. (This mouse has only 4 buttons and 2D wheel. There is no such
buttons like 11 and 12.)
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When setting the autocentering of PID devices, PID_DIRECTION_ENABLE is not
being explicitely set to 1. This results in autocentering working only on the
vertical axis when this field is preset to 0.
Fix that by setting it explicitely to 1 when preparing the set_effect report
for autocentering spring effect.
Signed-off-by: Diogo Kastrup <dk@bighost.com.br>
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Lately there have been quite a lot of bug reports against broken devices
which require us to fix their report descriptor in the runtime, before it
is passed to the HID parser. Those devices have eaten quite an amount of
our quirks space, which isn't particularly necessary - the quirks are not
needed after the report descriptor is parsed, and they just consume bits.
Therefore this patch separates the quirks for report descriptor fixup, and
moves their handling into separate code. The quirks are then forgotten as
soon as the report descriptor has been parsed.
Module parameter 'rdesc_quirks' is introduced to be able to modify these
quirks in runtime in a similar way to 'quirks' parameter for ordinary HID
quirks.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Devices manufactured by NCR have userspace hiddev-based drivers,
which do all the necessary device querying by themselves. The devices
must not be queried directly by the generic HID driver, as reported by
NCR engineers.
Cc: Petr Ostadal <postadal@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Petalynx Maxter remote control [1] 0x18b1/0x0037 emits 0xfa and 0xfc from
consumer page (reserved in HUT 1.12) for back and more keys. It also emits
a few usages from LOGIVENDOR page, which need adding.
Also, this device has broken report descriptor - the reported maximum is too
low - it doesn't contain the range for 'back' and 'more' keys, so we need to
bump it up before the report descriptor is being parsed.
Besides all this, it also requires NOGET quirk.
This patch does so.
[1] http://www.elmak.pl/index.php?option=com_phpshop&page=shop.browse&category_id=14&ext=opis&lang=en
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When comparing usb vs ps2 / testing the keycodes generated for the easy access
keys on my trust (microsoft compatible) keyboard. I noticed the search key
generated the keycode for find when connected through USB. This lead me to
check the consumer page mappings in hid-input.c . And it turns out the the
mapping for ID 0x221 deviates from the HUT standard document:
http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
Currently it is incorrectly mapped to find, whereas it should be mapped to
search. I also added missing bindings for ID 0x21f, the real find and for
0x222, goto.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch provides support for the Gameron dual psx adaptor. The
modification is to add the quirk HID_QUIRK_MULTI_INPUT for this
specific USB device.
Signed-off-by: Julien Eyries <jeyries@yahoo.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch (as914) replaces a call to flush_scheduled_work() with
cancel_work_sync(), in order to help avoid potential deadlocks.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Make a "menuconfig" out of the Kconfig objects "menu, ..., endmenu",
so that the user can disable all the options in that menu at once
instead of having to disable each option separately.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Microsoft SideWinder GameVoice driver is a trivial device with a few buttons
(0x09 HID usage) and an audio connector, which just forwards the audio input
into oridinary sound card present in the computer.
Despite this fact, the only interface of this device reports itself as a
Telephony/Headset type of HID device. This is apparently incorrect - the device
itself doesn't provide any audio/telephony functionality. This is achieved in
userland application which only needs to receive the button events from the HID
driver.
This patch establishes a new quirk which forces hid-input to claim a device it
will otherwise leave untouched.
Reported-by: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Chicony KU-0418 (aka Saitek PZ08AU gaming keyboard) has a separate
"tactical pad" with 11 non-functional buttons - they generate usage
codes from 0xff00 (MSVENDOR) usage page. Special case handling for
this keyboard added, so no later clash with MSVENDOR mappings is going
to occur.
Pointed out in bugzilla #7352
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There have been many reports recently about broken HID devices, the
diagnosis of which required users to recompile their kernels in order
to be able to provide debugging output needed for coding a quirk for
a particular device.
This patch makes CONFIG_HID_DEBUG default y if !EMBEDDED and makes it
possible to control debugging output produced by HID code by supplying
'debug=1' module parameter.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Changes to last version:
- spelling fix
- cleaned up probe code
Thomas.
Ethernet driver for EISA only SNI RM200/RM400 machines
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Changes to last version:
- use netdev_alloc_skb
- make init_rx_bufs just fail and not panic, if skb alloc fails
- don/t free_irq, if request_irq failed
Thomas.
Extracted chip specific code out of lasi_82596.c and placed into a lib82596.c
to make it usable for other 82596 drivers
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
It was mistakenly set to interrupt on the second packet instead of first, causing
some interesting latency behaviour.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
It does not really make sense to update the RX config register
before the mac filtering registers.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Merged from Realtek's r8169-6.001 driver.
I have added some locking to protect against the arp monitoring
timer in the bonding driver. Accessing the configuration registers
is otherwise performed under RTNL locking.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
It does not cost much and it will ease the identification of (so far)
unknown devices.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Align the IP header when the chipset can DMA at any location (plain 0x8169).
Otherwise (0x8136/0x8168) obey the constraint imposed by the hardware.
This patch complements the previous alignment rework done for copybreak.
Original idea from Philip Craig <philipc@snapgear.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Philip Craig <philipc@snapgear.com>
Cc: Mike Isely <isely@pobox.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
No functionnal change:
- trim the old history log
- whitespace/indent/case police
- unsigned int where signedness does not matter
- removal of obsolete assert
- needless cast from void * (dev_instance)
- remove dead code once related to power management
- use netdev_alloc_skb.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
It has been documented as deprecated:
- in MODULE_PARM_DESC since may 2005 ;
- at the top of the source file and in printk since june 2004.
Good bye.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
The rx copybreak part is straightforward.
The align field in struct rtl_cfg_info is related to the alignment
requirements of the DMA operation. Its value is set at 2 to limit the
scale of possible regression but my old v1.21 8169 datasheet claims a
8 bytes requirements (which never appeared in the driver, of course)
and the 8101/8168 go with a plain 8 bytes alignment.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
This one includes:
- more tweaks to rtl_hw_start_8168
- a work around for a Rx FiFO overflow issue on the 8168Bb
- rtl8169_{intr_mask/napi_event} are replaced with per-device fields,
namely tp->{intr/napi}_event
- rtl_cfg_info is converted to C99 for readability but the values are
not changed for the 8169/8110 and the 8101
Includes ChipCmd fix from Bernhard Walle <bwalle@suse.de> (2007/02/24).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
- new identifier for the 8110SCe
- the PCI latency timer is set unconditionally. This part is identical
in Realtek's r8168 (8.001.00) and r8101 (1.001.00)
- initialization of the cache line size register is for the 8169s only
- more magic in rtl_hw_start_8169
- it is not possible to factor out the setting of the the irq event mask
with the 8168 and the 8101 any more. Pushed it into the hw_start handler.
- rtl_set_rx_tx_config_registers() and write to the ChipCmd register are
issued identically for the whole 8169/8110 family: the 8110SCd/8110SCe
are handled the same way
- work around for AMD platform.
Some registers definitions in Realtek's driver are let aside for later.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Same thing as the previous change for rtl_hw_start_8168.
The 8101 related code in rtl_hw_start_8169 (see RTL_GIGA_MAC_VER_13)
goes away.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
rtl_hw_start_8168 inherits the content of rtl_hw_start_8169 minus
the code which depends on RTL_GIGA_MAC_VER_XY (XY != {11/12}).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
They aim to limit the amount of moved code when the hw_start
handler gets more specialized.
No functional change.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Rationale: rtl8169_hw_start will not help maintaining an unified
driver for different chipsets but people at Realtek are probably
too polite to say it distinctly.
Let's add the hook and keep hw_start handler unchanged.
As can be seen from the content of rtl8169_pci_tbl, the RTL_CFG_1
entry in rtl_cfg_info was unused. I recycled it for the 0x8168.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
- pci_dma_sync_single_for_cpu is not needed for a single large packet
- remove the function pointer to help gcc optimizing the inline
pci_dma functions.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
It hasn't "summed" anything in over 7 years, and it's
just a straight mempcy ala skb_copy_to_linear_data()
so just get rid of it.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
The former style suggests a modulo arithmetic misuse but
the expression should never be < 0. Even if it does, the
driver will simply loop longer than expected (not that
the remaining parts of the system will necessarily
appreciate it...).
Let's warn the user when something goes wrong and try
to go over it.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Use netdev_alloc_skb and remove the useless sk_buff * argument of
rtl8169_alloc_rx_skb.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
New version because of new chip support.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Enable support for Yukon EX chipset (88e8071).
Most of changes are related to new commands to chip for transmit,
and change in status and checksumming.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The General Purpose I/O register is yet another hardware workaround
catchall. Enable workaround that vendor driver does to stay
but for bug compatiable.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Catch-22: On Yukon EX (88E8071) need to have internal clocks enabled
before reading chip id. It is harmless on other chips.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This register is more of a test and control register on Yukon2.
So rename it to Q_TEST and give some bit definitions.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Need to setup more PCI control control registers are on Yukon EX.
Some of these also exist on Yukon EC-U as well.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
On Yukon EX reading some of the undocumented places in the
memory space will cause a hang. Since they don't provide useful
information, just skip the reserved areas.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The transmit frame tail bit is stranglely misnamed as
"no checksum". Fix the name to what it should be:
"transmit frame tail". No functional change,
just a name change.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Put the enable and disable routines next to one-another,
as this makes verifying thier symmetry that much easier.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
When entering the netdev poll routine, empty out the RX
chain first, before cleaning up the TX chain. This should
help avoid RX buffer overflows.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Invalidate a pointer as its pci_unmap'ed; this is a bit of
paranoia to make sure hardware doesn't continue trying to
DMA to it.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Crazy device problems are hard to debug, when one does not have
good trace info. This patch makes a major enhancement to the
device dump routine.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
