- 21 Nov, 2003 1 commit
-
-
Dave Jones authored
The FSB guessing screwed up sometimes. If cpu_mhz was greater than the guess we returned zero.
-
- 17 Nov, 2003 1 commit
-
-
Dave Jones authored
Remove dupes by using a webpage instead of flooding me with lots of similar emails.
-
- 10 Nov, 2003 2 commits
-
-
Dave Jones authored
From Dominik Brodowski
-
Dave Jones authored
As the powernow-k8 driver uses the ->target and not the ->setpolicy callback, cpufreq_policy->policy is always zero. Checking for it in the powernow-k8 driver always returned "false". So we can easily remove this invalid check (and the #warning added to denote this). From Dominik Brodowski
-
- 27 Oct, 2003 1 commit
-
-
Dave Jones authored
From: Youichi Aso <aso@granite.phys.s.u-tokyo.ac.jp>
-
- 24 Oct, 2003 5 commits
-
-
Knut Petersen authored
This is a bugfix for setkeycode() in /drivers/char/keyboard.c. If we change a keycode the corresponding bit should be cleared if and only if this keycode is not defined any longer. I believe that this also was intended with the original code, but the implementation is faulty. First off all the first three changed lines are obviously erroneus: oldkey == truekey is false or true, you do not need to inclose this in a for(). I believe the author intended INPUT_KEYCODE(dev,i) == oldkey. But fixing this alone is not enough. If somebody wants to interchange the definition of two keys A and B, the normal way is to use two setkeycode calls: setkeycode (scancode A, keycode B); setkeycode (scancode B, keycode A); The old code does a clearbit(oldkey ..) call even in situations where two keys have the same definition, and this situation arises commonly in the situation mentioned above. Both errors are fixed with this patch.
-
Knut Petersen authored
If somebody uses keyboard scancode set 3 it is necessary to explicitly program the keyboard to send make/break codes for all keys and to set autorepeat for all keys. This is critical for some people. One example is the LK461/46W series of keyboards from Digital Equipment Corporations. These are VMS keyboards that are also usable on a normal PC. These keyboards support Scancode Set 2, but for some keys this support is screwed up -- some function keys (e.g. F18/F20) report the same scancode sequence combined with both alt and shift keys. Scancode Set 3 works perfectly if all keys are programmed to give make/break codes. A lot of keyboards manufactured by Cherry only make/break for some (not all!) modifyer keys in scancode set 3 without this fix.
-
bk://kernel.bkbits.net/gregkh/linux/usb-2.6Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
bk://kernel.bkbits.net/davem/sparc-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Linus Torvalds authored
This fixes resource conflicts due to IO decode that doesn't show up with a normal PCI probe (we do similar quirks for most other chipsets). Without it, the kernel doesn't know about some magic IO decodes for the chips.
-
- 23 Oct, 2003 24 commits
-
-
David S. Miller authored
into nuts.ninka.net:/disk1/davem/BK/sparc-2.5
-
David S. Miller authored
-
David Brownell authored
This resolves a bug that was recently reported to me by someone enumerating a USB 1.1 modem through a high speed hub. I'm a bit surprised we never saw it before; I think cache/dma timings must usually be strongly in our favor. The problem was that the HC was still using the old ep0 maxpacket value, so when it received an 18 byte device descriptor it would report a packet overrun and enumeration would fail. The fix is straightforward: invalidate the HC's old endpoint state when we change the full speed maxpacket size. (And eventually, we can remove EHCI and OHCI code coping with usbcore not doing this.)
-
Greg Kroah-Hartman authored
into kroah.com:/home/greg/linux/BK/usb-2.6
-
David Brownell authored
This fixes a problem that showed in usb-storage (osdl bugme 1310) and could have shown in other drivers that used usb_reset_device() when they already held dev->serialize: a self-deadlock with some devices. There are some drivers that should likely change so that they grab this lock themselves, since they don't call this during probe() when the lock is already held. The lock protects against config changes by other tasks, which is currently quite rate.
-
Alan Stern authored
An earlier patch caused trouble because it effectively removed the US_FL_FIX_INQUIRY flag for devices with release number higher than 0x5009. This one might cause problems because it explicitly goes against the immediately preceding comment in unusual_devs.h. That comment says that these Casio digital cameras claim to use the CBI transport when in fact they only use CB. However, there have been two reports in the last few weeks from people getting the "unneeded SubClass and Protocol" log messages. One of them was using a device with release number 0x1000, right at the start of the range. The other had a device with release number 0x5010, just beyond the end of the current range. Maybe Casio is marketing two different devices with different behaviors but having the same Vendor, Product, and Release values -- I don't know.
-
Carsten Busse authored
its for the Jenoptik JD 5200 z3 Digicam, to enable it to work as a simple storage device more or less i took the values for the 0x0d96 vendor in the 2.6.0-test7 usb-storage and mixed them with my device id, which seems to work quite well tested with 2.4.22 kernel
-
Ian Abbott authored
Patch by me (Ian Abbott). Removed aliases of FTDI_VID define for consistency. Renamed FTDI_PERLE_PID to FTDI_PERLE_ULTRAPORT_PID. Removed Matrix Orbital and Perle Systems devices from the 8U232AM device table (but left them in the FT232BM device table) as they are known to be FT232BM devices.
-
Ian Abbott authored
Scott Allen's patch to add vid/pid support for Perle Systems UltraPort USB serial converter, merged up with minor whitespace changes by myself (Ian Abbott).
-
David Brownell authored
Please merge this patch. I've had two success reports from it. Putback comment can be: Fixes some long-standing cdc-acm bugs including: - Oopsing - Probe messages not so excessive - Makes /proc/bus/usb/devices show both interface claims - Now cdc_acm won't hotplug for Ethernet devices (or RNDIS)
-
David T. Hollis authored
* ax8817x_set_multicast - use address of dev->data, not contents * ax8817x_write_async_cmd - free request and urb if submit fails
-
Arnaldo Carvalho de Melo authored
I'm doing an audit wrt copy_to_user leaking info to userspace, started with drivers/usb, please apply.
-
bk://kernel.bkbits.net/lord/xfs-2.6Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
ssh://lord@kernel.bkbits.net/xfs-2.6Stephen Lord authored
into jen.americas.sgi.com:/src/lord/bitkeeper/xfs-2.6
-
Stephen Lord authored
SGI Modid: 2.5.x-xfs:slinx:160507a
-
Glen Overby authored
algorithm in it. The old algorithm appeared to look for the first place to put a new data block, and thus a new freespace block (this is where the 'foundindex' variable came from). However, new space in a directory is always added at the lowest file offset as determined by the extent list. So this stuff is never used. I completely ripped out the reminants of the old algorithm, and (again) moved the freespace block add code inside the conditional where a data block is added. SGI Modid: 2.5.x-xfs:slinx:159751a
-
Nathan Scott authored
[XFS] Use an xfs_ino_t to hold the result of inode extraction from a handle, not a possibly 32-bit number SGI Modid: 2.5.x-xfs:slinx:159943a
-
Nathan Scott authored
SGI Modid: 2.5.x-xfs:slinx:159997a
-
bk://linux-scsi.bkbits.net/scsi-bugfixes-2.6Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Mark Haverkamp authored
If you have a 4gig or greater system, some versions of aacraid firmware have problems if you set HostPhysMemPages >= 0x100000. This can potentially cause data corruption. If you have 4gig or greater memory, this patch sets the HostPhysMemPages to something that the firmware can deal with.
-
Pat LaVarre authored
I propose the 2.6.0-test8 two-line patch below to teach SG_SET_RESERVED_SIZE to reject a negative size, rather than oops-ing.
-
Mike Anderson authored
This patch removes the delay in calling device_del on the sdev struct device during a surprise removal event. Reference counting functions for sd's scsi_disk structure where also added to fix issues of unregistering when a sd is open. I have tested this patch using scsi_debug with differnt combinations of adds / removes. I mounted both partitioned and un-partitioned sd disks, remove the host, and then did a umount. The ref count debug output shows the objects staying in place prior to the umount and cleaning up once the umount is called. This patch fixes an issue with a delayed call of device_del on the sdev_gendev struct device. - Remove the delayed call to device_del. - Add kobject to sd scsi_disk structure. - Add release function for scsi_disk kobject. - Add get / put functions for scsi_disk and calls to these functions. drivers/scsi/scsi.c | 4 -- drivers/scsi/scsi_sysfs.c | 3 -- drivers/scsi/sd.c | 63 ++++++++++++++++++++++++++++++++++++++++------ 3 files changed, 57 insertions(+), 13 deletions(-)
-
Linus Torvalds authored
Apparently some laptops (Compaq EVO N620c for one) have something hidden at IO port range 0x1000, and the 2.4.x default of allocating IO starting at 0x4000 is safer.
-
Stephen Lord authored
into kernel.bkbits.net:/home/lord/xfs-2.6
-
- 22 Oct, 2003 6 commits
-
-
David S. Miller authored
-
Linus Torvalds authored
It's incorrect for any user of the non-synchronizing irq_disable_nosync(). Cset exclude: torvalds@home.osdl.org|ChangeSet|20031013020955|28777
-
http://lia64.bkbits.net/to-linus-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Alex Williamson authored
I stumbled on a couple trivial bugs in ia64 numa/discontig support. The first just sets the default number of nodes to something reasonable for a generic kernel, otherwise it's really easy to start walking over your initdata (more error checking should probably be added). The second fixes a memcpy to a physical address.
-
Arun Sharma authored
Without this patch, if a signal handler tried to access TLS data (via %gs), things break, because the GS descriptor is zero. To be compatible with i386, we shouldn't be touching the segment descriptors before getting into signal handlers.
-
ssh://lord@kernel.bkbits.net/xfs-2.6Stephen Lord authored
into jen.americas.sgi.com:/src/lord/bitkeeper/xfs-2.6
-