- 13 6月, 2006 23 次提交
-
-
由 Ben Collins 提交于
We only support x86 and ppc, due to the use of bus_to_virt() and friends. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Replace occurrences of the magic value ~(u64)0 for invalid CSR address spaces by a named constant for better readability. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
The proper designator of an invalid CSR address is ~(u64)0, not (u64)0. Use the correct value in initialization and deregistration. Also, scsi_id->sbp2_lun does not need to be initialized twice. (scsi_id was kzalloc'd.) Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
I've been experimenting to track down the cause of suspend/resume problems on my Compaq Presario X1050 laptop: http://bugzilla.kernel.org/show_bug.cgi?id=6075 Essentially the ACPI Embedded Controller and keyboard controller would get into a bizarre, confused state after resume. I found that unloading the ohci1394 module before suspend and reloading it after resume made the problem go away. Diffing the dmesg output from resume, with and without the module loaded, I found that with the module loaded I was missing these: PM: Writing back config space on device 0000:02:00.0 at offset 1. (Was 2100080, writing 2100007) PM: Writing back config space on device 0000:02:00.0 at offset 3. (Was 0, writing 8008) PM: Writing back config space on device 0000:02:00.0 at offset 4. (Was 0, writing 90200000) PM: Writing back config space on device 0000:02:00.0 at offset 5. (Was 1, writing 2401) PM: Writing back config space on device 0000:02:00.0 at offset f. (Was 20000100, writing 2000010a) The default PCI driver performs the pci_restore_state when no driver is loaded for the device. When the ohci1394 driver is loaded, it is supposed to do this, however it appears not to do so. I created the patch below and tested it, and it appears to resolve the suspend problems I was having with the module loaded. I only added in the pci_save_state and pci_restore_state - however, though I know little of this hardware, surely the driver should really be doing more than this when suspending and resuming? Currently it does almost nothing, what if there are commands in progress, etc? Signed-off-by: NRobert Hancock <hancockr@shaw.ca> Cc: Jody McIntyre <scjody@modernduck.com> Cc: Ben Collins <bcollins@debian.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
It seems to have worked without the attribute during all the years just because sizes of all struct members are multiples of 32 bits. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
It appears I will not get it fixed overnight. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
If sbp2 is forced to move data via ARM handler, the maximum packet size allowed for S800 transfers exceeds ohci1394's buffer size on platforms where PAGE_SIZE is 4096. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Being able to switch physical DMA on and off at run time would be a nice feature but a PITA to support by highlevel drivers and userspace apps. Therefore allow it only to be set when the driver is being loaded. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
This patch supplies the API extension introduced by patch "ieee1394: extend lowlevel API for address range properties" with proper addresses. Like in patch ''ohci1394, sbp2: fix "scsi_add_device failed" with PL-3507 based devices'', 1 TeraByte is chosen as physical upper bound. This leaves a window for the middle address range. This choice is only relevant for adapters which actually have a programmable pysical upper bound register. (Only ALi and Fujitsu adapters are known for this. Most adapters have a fixed bound at 4 GB.) The middle address range is suitable for posted writes. AFAIK, PCILynx does not support physical DMA nor posted writes, therefore no equivalent change in the pcilynx driver is necessary. There is also a driver for GP2Lynx, although not in mainline Linux. I assume this hardware does not support these OHCI features either. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Host adapter hardware imposes certain restrictions and features on address ranges. Instead of hard-wire such ranges into the ieee1394 core or even into protocol drivers, let lowlevel drivers specify these ranges via struct hpsb_host. Patch "ohci1394: set address range properties" must be applied too, else hpsb_allocate_and_register_addrspace() won't work properly. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Since this is useful information, promote it from a debug macro to a regular log message. The message appears only if the user set exclusive_login=0, therefore won't clutter the logs in normal use. Also update the comment on exclusive_login. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NJody McIntyre <scjody@modernduck.com> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
This code became ineffective a few Linux releases ago and is not required anyway. Note from Christoph Hellwig: scsi_cmnd.request_buffer is always a scatterlist these days. Checking random bites into it and then mangling the data in sbp2_check_sbp2_response will cause really bad memory corruption when you're not lucky enough to have the check not trigger by luck. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Since broadcast transactions are already complete when the request has been sent, the same transaction label can be reused all over again, see IEEE 1394 7.3.2.5 and 6.2.4.3. Therefore we can reduce the footprint of struct hpsb_host by the size of one struct hpsb_tlabel_pool. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Add support for the following types of hardware: + nodes that have a link speed < PHY speed + 1394b PHYs that are less than S800 capable + 1394b/1394a adapter cable between two 1394b PHYs Also, S1600 and S3200 are now supported if IEEE1394_SPEED_MAX is raised. A probing function is added to nodemgr's config ROM fetching routine which adjusts the allowable speed if an access problem was encountered. Pros and Cons of the approach: + minimum code footprint to support this less widely used hardware + nearly no overhead for unaffected hardware - ineffective before nodemgr began to read the ROM of affected nodes - ineffective if ieee1394 is loaded with disable_nodemgr=1 The speed map CSRs which are published to the bus are not touched by the patch. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Cc: Hakan Ardo <hakan@debian.org> Cc: Calculex <linux@calculex.com> Cc: Robert J. Kosinski <robk@cmcherald.com> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
This patch modifies the ohci1394.c file to enable and manage the "cycle too long" interrupt. If this interrupt occurs, the "LinkControl.CycleMaster" bit of the host controller is reseted. This implies, that the host controller does not send "cycle start" packet anymore freezing then the isochronous communication. The management of the interrupt added by the patch is that when the interrupt occurs, the OHCI irq handler prints a kernel log warning and then sets the "LinkControl.CycleMaster" bit again resuming the isochronous communication. Signed-off-by: NJean-Baptiste Mur <jeanbaptiste@maunakeatech.com> Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: NArjan van de Ven <arjan@infradead.org> Signed-off-by: NIngo Molnar <mingo@elte.hu> Cc: Ben Collins <bcollins@debian.org> Cc: Jody McIntyre <scjody@modernduck.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
The workarounds are not required for DViCO Momobay FX-3A and AFAIR not for Momobay CX-2. These contain an TSB42AA9A but feature the same firmware_revision value as the older DViCO Momobay CX-1. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
spotted by Adrian Bunk. Also remove some superfluous comments. Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
when attempting to find the 'last' part of the dma region continue the search from where we left off, instead of starting the search over. Signed-off-by: NJim Westfall <jwestfall@surrealistic.net> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
由 Ben Collins 提交于
When working with multiple cameras and intensive applications, our logs get flooded with video1394 information which isn't of much interest. Any objections to demoting these messages to debug messages? Signed-off-by: NDaniel Drake <dsd@gentoo.org> Signed-off-by: NBen Collins <bcollins@ubuntu.com>
-
- 12 6月, 2006 5 次提交
-
-
由 Paul Mackerras 提交于
People have been reporting that PPP connections over ptys, such as used with PPTP, will hang randomly when transferring large amounts of data, for instance in http://bugzilla.kernel.org/show_bug.cgi?id=6530. I have managed to reproduce the problem, and the patch below fixes the actual cause. The problem is not in fact in ppp_async.c but in n_tty.c. What happens is that when pptp reads from the pty, we call read_chan() in drivers/char/n_tty.c on the master side of the pty. That copies all the characters out of its buffer to userspace and then calls check_unthrottle(), which calls the pty unthrottle routine, which calls tty_wakeup on the slave side, which calls ppp_asynctty_wakeup, which calls tasklet_schedule. So far so good. Since we are in process context, the tasklet runs immediately and calls ppp_async_process(), which calls ppp_async_push, which calls the tty->driver->write function to send some more output. However, tty->driver->write() returns zero, because the master tty->receive_room is still zero. We haven't returned from check_unthrottle() yet, and read_chan() only updates tty->receive_room _after_ calling check_unthrottle. That means that the driver->write call in ppp_async_process() returns 0. That would be fine if we were going to get a subsequent wakeup call, but we aren't (we just had it, and the buffer is now empty). The solution is for n_tty.c to update tty->receive_room _before_ calling the driver unthrottle routine. The patch below does this. With this patch I was able to transfer a 900MB file over a PPTP connection (taking about 25 minutes), whereas without the patch the connection would always stall in under a minute. Signed-off-by: NPaul Mackerras <paulus@samba.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Mark Lord 提交于
Bug fix: mv_eng_timeout() calls mv_err_intr() without first grabbing the host lock, which can lead to all sorts of interesting scenarios. This whole error-handling portion of sata_mv is nasty (and will get fixed for the new EH stuff), but for now this patch will help keep it on life-support. Signed-off-by: NMark Lord <liml@rtr.ca> Signed-off-by: NJeff Garzik <jeff@garzik.org>
-
由 Yu, Luming 提交于
According to Intel ICH spec, there are several rules that Base Address should be programmed before IOSE (PCICMD register ) enabled. For example ICH7: 12.1.3 SATA : the base address register for the bus master register should be programmed before this bit is set. 11.1.3: PCICMD (USB): The base address register for USB should be programmed before this bit is set. .... To make sure kernel code follow this rule , and prevent unnecessary confusion. I proposal this patch. Signed-off-by: NLuming Yu <luming.yu@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Dave Jones 提交于
At least one laptop blew up on resume from suspend with a black screen due to a lack of this patch. By only writing back config space that is different, we minimise the possibility of accidents like this. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Jean Delvare 提交于
We currently don't handle errors properly when resuming a PCI device: * In pci_default_resume() we capture the error code returned by pci_enable_device() but don't pass it up to the caller. Introduced by commit 95a62965 * In pci_resume_device(), the errors possibly returned by the driver's .resume method or by the generic pci_default_resume() function are ignored. This patch fixes both issues. Signed-off-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 11 6月, 2006 3 次提交
-
-
由 Milton Miller 提交于
From: Milton Miller <miltonm@bga.com> The add_preferred_console call in rtas_console.c was not causing the console to be selected. It turns out that the add_preferred_console was being called after the hvc_console driver was registered. It only works when it is called before the console driver is registered. Reorder hvc_console.o after the hvc_console drivers to allow the selection during console_initcall processing. Signed-off-by: NMilton Miller <miltonm@bga.com> Signed-off-by: NAnton Blanchard <anton@samba.org> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Markus Lidel 提交于
From: Markus Lidel <Markus.Lidel@shadowconnect.com> - Fixed locking of struct i2o_exec_wait in Executive-OSM - Removed LCT Notify in i2o_exec_probe() which caused freeing memory and accessing freed memory during first enumeration of I2O devices - Added missing locking in i2o_exec_lct_notify() - removed put_device() of I2O controller in i2o_iop_remove() which caused the controller structure get freed to early - Fixed size of mempool in i2o_iop_alloc() - Fixed access to freed memory in i2o_msg_get() See http://bugzilla.kernel.org/show_bug.cgi?id=6561Signed-off-by: NMarkus Lidel <Markus.Lidel@shadowconnect.com> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Andrew Morton 提交于
From: Andrew Morton <akpm@osdl.org> Work around the oops reported in http://bugzilla.kernel.org/show_bug.cgi?id=6478. Thanks to Ralf Hildebrandt <ralf.hildebrandt@charite.de> for testing and reporting. Acked-by: NDave Jones <davej@codemonkey.org.uk> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 6月, 2006 2 次提交
-
-
由 Tom "spot" Callaway 提交于
Signed-off-by: NTom "spot" Callaway <tcallawa@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Get rid of all the SUN_570X logic and instead: 1) Make sure MEMARB_ENABLE is set when we probe the SRAM for config information. If that is off we will get timeouts. 2) Always try to sync with the firmware, if there is no firmware running do not treat it as an error and instead just report it the first time we notice this condition. 3) If there is no valid SRAM signature, assume the device is onboard by setting TG3_FLAG_EEPROM_WRITE_PROT. Update driver version and release date. With help from Michael Chan and Fabio Massimo Di Nitto. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 09 6月, 2006 3 次提交
-
-
由 Malcom Parsons 提交于
From: Malcom Parsons <malcolm.parsons@gmail.com> When scrolling up in SCROLL_PAN_REDRAW mode with a large limited scroll region, the bottom few lines have to be redrawn. Without this patch, the wrong text is drawn into these lines, corrupting the display. Observed in 2.6.14 when running an IRC client in the Nintendo DS linux port. I haven't tested if scrolling down has the same problem. Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Auke Kok 提交于
It was brought to our attention that the prefetches break e1000 traffic on xscale/arm architectures. Remove them for now. We'll let them stay in mm for a while, or find a better solution to enable. Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
-
由 Auke Kok 提交于
New code added in 2.6.17 caused setup_irq to print a warning when running ethtool -t eth0 offline. This test marks the request_irq call made by this test as a "probe" to see if the interrupt is shared or not. Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
-
- 06 6月, 2006 4 次提交
-
-
由 Florin Malita 提交于
skb_clone() may fail, we should check the result. Coverity CID: 1215. Signed-off-by: NFlorin Malita <fmalita@gmail.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Matt Mackall 提交于
From: Matt Mackall <mpm@selenic.com> netconsole is being wrong here. If it wasn't enabled there's no error. Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Andrew Morton 提交于
From: Andrew Morton <akpm@osdl.org> drivers/rtc/rtc-m48t86.c: In function `m48t86_rtc_read_time': drivers/rtc/rtc-m48t86.c:51: error: structure has no member named `ia64_mv' drivers/rtc/rtc-m48t86.c:55: error: structure has no member named `ia64_mv' drivers/rtc/rtc-m48t86.c:56: error: structure has no member named `ia64_mv' drivers/rtc/rtc-m48t86.c:57: error: structure has no member named `ia64_mv' drivers/rtc/rtc-m48t86.c:58: error: structure has no member named `ia64_mv' drivers/rtc/rtc-m48t86.c:60: error: structure has no member named `ia64_mv' readb() and writeb() are macros on ia64. Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Rune Torgersen 提交于
From: "Rune Torgersen" <runet@innovsys.com> Fix an endian issue in the sil24 driver. Signed-off-by: NRune Torgersen <runet@innovsys.com> Acked-by: NJeff Garzik <jeff@garzik.org> Cc: Tejun Heo <htejun@gmail.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-