- 05 Nov, 2004 7 commits
-
-
Jean Delvare authored
This is a new I2C chip driver named lm63, which supports National Semiconductor's LM63 hardware monitoring chip. The LM63 is similar to the LM86 (which we do support through our lm90 driver) with additional monitoring and control of a single fan. It is obviously aimed at the CPU and high-end graphics adapters markets. This new driver is very similar in nature to the lm83 and lm90 driver so I don't have much to add. I developed the driver on a request from Hard Data Ltd. which are using Tyan S4882 boards where four LM63 chips are used (one for each CPU). Tyan provided remote access to a test system so that I could test my driver on real LM63 chips. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Arjan van de Ven authored
i2c-core.c has a few never used functions, patch below removes these dead functions. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Justin Thiessen authored
Signed off by: Justin Thiessen <jthiessen@penguincomputing.com Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Evgeniy Polyakov authored
Description: Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Evgeniy Polyakov authored
Description: Uses msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Evgeniy Polyakov authored
Description: Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Evgeniy Polyakov authored
Description: Use msleep_interruptible() instead of schedule_timeout() to guarantee the task delays as expected. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
- 22 Oct, 2004 25 commits
-
-
Eugene Surovegin authored
On Tue, Oct 19, 2004 at 10:21:08PM -0700, Eugene Surovegin wrote: [snip] > It looks like this change added race I tried to avoid here. > > This code is modeled after __wait_event_interruptible_timeout, where > "prepare_to_wait" is done _before_ checking completion status. This > change breaks this, e.g. if IRQ happens right after we check iic->sts, > but before calling msleep_interruptible(). In this case we'll sleep > much more than required (seconds instead of microseconds) > > Greg, if my analysis is correct, please rollback this change. > > Nishanth, I'd be nice if you CC'ed me with this patch, my e-mail is at > the top of that source file. Oh, well. I should have used wait_event_interruptible_timeout when I ported this driver to 2.6. This patch fixes recently introduced race and also cleans ups some 2.4-ism. Signed-off-by: Eugene Surovegin <ebs@ebshome.net> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Ben Dooks authored
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
-
Andrew Morton authored
.. broken by the rename. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
This didn't show up in my "allmodconfig" tests, because the console requires things to be built-in, not modules.
-
Chris Wright authored
Posix timers preallocate siqueue structures during timer creation and keep them for reuse. This allocation happens in user context with no locks held, however it's designated as an atomic allocation. Loosen this restriction, and while we're at it let's do a bit of code consolidation so signal sending uses same __sigqueue_alloc() helper. Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Nicolas Pitre authored
missing #include (and placement cleanup) Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Chris Wright authored
Lindent security/security.c. Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Chris Wright authored
Registering a security module can be a noisy operation, esp. when it retries registration with the primary module. Eliminate some noise, and distinguish the return values for register_security so a module can tell the difference between failure modes. Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Chris Wright authored
Rename security_scaffolding_startup() to security_init(). It always bothered me. Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Matthew Wilcox authored
trivial sound/parisc updates: - substream->dma_device was removed (Stuart Brady) - Fix module unloading (Stuart Brady) - Fixed the off-by-one in snd_card_harmony_rate_bits (Stuart Brady) - Harmony is a GSC device, not available on pure PCI machines (Matthew Wilcox) - Fixed module parameter descriptions for ALSA Harmony (Stuart Brady)
-
Jens Axboe authored
Currently they are in the generic setup, pretty confusing. This patch moves the io scheduler selection into a seperate menu under block devices. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
-
bk://kernel.bkbits.net/jgarzik/net-drivers-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://kernel.bkbits.net/jgarzik/libata-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Alexander Viro authored
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Alexander Viro authored
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Alexander Viro authored
annotated, ioremap() use simplified (it can deal with addresses that are not page-aligned just fine). Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Alexander Viro authored
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paul Mackerras authored
When the generic IRQ stuff went in, it seems that HARDIRQ_BITS got bumped from 9 (for ppc64) up to 12. Consequently, the PREEMPT_ACTIVE bit is now within HARDIRQ_MASK, and I get in_interrupt() falsely returning true when PREEMPT_ACTIVE is set, and thus a BUG_ON tripping in arch/ppc64/mm/tlb.c. The patch below fixes this by changing PREEMPT_ACTIVE to 0x10000000. I have changed the PREEMPT_ACTIVE definitions for each of the architectures that define CONFIG_GENERIC_HARDIRQS (i386, ppc, ppc64, x86_64) and fixed the comment in include/linux/hardirq.h. We could perhaps move the PREEMPT_ACTIVE definition to include/linux/hardirq.h - I don't know why it is still per-arch. Signed-off-by: Paul Mackerras <paulus@samba.org> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
This patch fixes build of arch/ppc/kernel/irc.c when CONFIG_TAU_INT is set. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
The current "generic" implementation of IRQ probing isn't well suited for ppc in it's current form, and causes issues with yenta_socket (and possibly others) on pmac laptops. We didn't have a probe implementation in the past, we probably don't need one anyway, so for now, the fix is to make this optional and enable it on x86 and x86_64 but not ppc and ppc64 (the 4 archs to use the generic IRQ code). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
This patch updates the G5 thermal control driver, the main change is support for the new "PowerMac7,3" type desktops including the dual 2.5Ghz with liquid cooling. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
This patch fixes a typo in the zImage boot wrapper (incorrect printf). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Matthew Dharm <mdharm@momenco.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Benjamin Herrenschmidt authored
This patch fixes a problem when allocating the TCE tables (iommu) during early boot on some non-LPAR machines with a lot of memory. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Paul Mackerras authored
This patch, from John Rose, is the counterpart of one recently forwarded by Greg KH. It has the same description, but isn't the same patch - this is the arch/ppc64 part of the change. As an unfortunate side effect of runtime addition/removal of PCI Host Bridges, the RPA DLPAR driver can no longer depend on the success of ioremap_explicit() (and therefore remap_page_range()) for the case of DLPAR adding an I/O Slot. Without addressing this, an attempt to add the first child slot of a newly added PHB will fail when __ioremap_explicit() determines the mappings for that range to already exist. For a little context, __ioremap_explicit() creates mappings for the range of a newly added slot. Here's why these calls will be expected to fail in some cases. Keep in mind that at boot-time, the PPC64 kernel calls ioremap() for the entire range spanned by each PHB. Consider the following scenarios of DLPAR-adding an I/O slot. 1) Just after boot, one removes an I/O slot. At this point the range associated with the parent PHB is fragmented, and the child range for the slot in question is iounmap()'ed. One then re-adds the slot, at which point remap_page_range()/ioremap_explicit() restores the mappings that were previously removed. 2) One adds a new PHB, at which point the ppc64-specific addition ioremaps the entire PHB range. One then performs a DLPAR-add of a child slot of that PHB. At this point, mappings already exist for the range of the slot to be added. So remap_page_range()/ioremap_explicit() will fail at this point. The problem is, there's not a good way to distinguish between cases 1 and 2 from the perspective of the DLPAR driver. Because of that, I believe the correct solution to be: - Removal of relevant error prints from iounmap_explicit(), which is only used for DLPAR. - Removal of error code checks from the RPA driver Here's the first of these. Signed-off-by: John Rose <johnrose@austin.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 21 Oct, 2004 8 commits
-
-
Jeff Garzik authored
into pobox.com:/garz/repo/libata-2.6
-
Jeff Garzik authored
into pobox.com:/garz/repo/net-drivers-2.6
-
Jeff Garzik authored
into pobox.com:/garz/repo/net-drivers-2.6
-
Jeff Garzik authored
into pobox.com:/garz/repo/net-drivers-2.6
-
Jeff Garzik authored
into pobox.com:/garz/repo/net-drivers-2.6
-
Jeff Garzik authored
into pobox.com:/garz/repo/net-drivers-2.6
-
Chris Wright authored
Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chris Wright authored
Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-