- 09 Mar, 2005 17 commits
-
-
Kay Sievers authored
On Tue, Feb 15, 2005 at 09:53:44PM +0100, Kay Sievers wrote: > Add a "bus" symlink to the class and block devices, just like the "driver" > and "device" links. This may be a huge speed gain for e.g. udev to determine > the bus value of a device, as we currently need to do a brute-force scan in > /sys/bus/* to find this value. Hmm, while playing around with it, I think we should create the "bus" link on the physical device on not on the class device. Also the current "driver" link at the class device should be removed, cause class devices don't have a driver. Block devices never had this misleading symlink. From the class device we point with the "device" link to the physical device, and only the physical device should have the "driver" and the "bus" link, as it represents the real relationship. Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mike Waychison authored
Get rid of semaphore abuse by converting device_driver->unload_sem semaphore to device_driver->unloaded completion. This should get rid of any confusion as well as save a few bytes in the process. Signed-off-by:
Mike Waychison <michael.waychison@sun.com> Signed-off-by:
-
Kay Sievers authored
Signed-off-by:
-
Kay Sievers authored
Signed-off-by:
-
Kay Sievers authored
Signed-off-by:
-
Kay Sievers authored
Signed-off-by:
Greg Kroah-Hartman <greg@kroah.com>
-
Kay Sievers authored
Signed-off-by:
-
Kay Sievers authored
Move the creation of the sysfs "dev" file of a class device into the driver core. The struct class_device contains a dev_t value now. If set, the driver core will create the "dev" file containing the major/minor numbers automatically. Signed-off-by:
-
Russell King authored
Separate platform device name from platform device number such that names ending with numbers aren't confusing. Signed-off-by:
Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Dominik Brodowski authored
Even though these 2.4. interfaces are already gone in Dave Jones' cpufreq bitkeeper tree, here's a patch which properly announces it in Documentation/feature-removal-schedule.txt: Add meaningful content concerning the removal of deprecated interfaces to the cpufreq core. Signed-off-by:
Dominik Brodowski <linux@brodo.de> Signed-off-by:
-
Randy Dunlap authored
Add 2.4.x cpufreq /proc and sysctl interface removal to the feature-removal-schedule. Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
-
Arjan van de Ven authored
kobject_get_path and kobject_rename are only used by the sysfs core code and not aren't really driver-ish code. Remove the unused exports Signed-off-by:
Arjan van de Ven <arjan@infradead.org> Signed-off-by:
-
Matthew Wilcox authored
- Move the bits_wide parameter from txn_alloc_data to txn_alloc_irq. It's too late by the time it hits txn_alloc_data(), we can only panic. In txn_alloc_irq, we can fail the allocation and continue. - Also fix a bug where we'd only allow up to half the interrupts to be allocated. Not a problem for iosapic machines, but might have sucked on a really big GSC-based machine. - Add missing irq_enter() / irq_exit() - Allow interrupt processing to be interrupted by the timer tick so we actually account hard interrupts. Also speed up the handling of CPU interrupts by not masking with cpu_eiem again. - Remove sufficiently obsolete DEBUG_IRQ code - Remove limit on times around the loop. If we exit the loop while interrupts are still pending, we'll only be re-interrupted as soon as we exit the function. - Remove unnecessary includes Signed-off-by:
Matthew Wilcox <willy@parisc-linux.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Matthew Wilcox authored
Fix "make configcheck | fgrep 'not needed' | fgrep parisc" Signed-off-by:
Grant Grundler <grundler@parisc-linux.org> Signed-off-by:
-
Matthew Wilcox authored
- The entire silence buffer is now being filled, instead of just 1/8th of it. - The silence buffer is now prepared during initialisation of the driver. - snd_pcm_format_size() is missing from the ALSA headers: using snd_pcm_format_physical_width() instead. Signed-off-by:
Stuart Brady <sdbrady@ntlworld.com> Signed-off-by:
-
Matthew Wilcox authored
- Missing UL on large integers - 0/NULL confusion - __user annotations - C99-style array elements Signed-off-by:
Randolph Chung <tausq@parisc-linux.org> Signed-off-by:
-
Matthew Wilcox authored
- Convert ldil/ldo to using the load32 macro. Signed-Off-By:
Kyle McMartin <kyle@parisc-linux.org> - loop on signal delivery like other archs - unify VM initialization code for 32/64-bit Signed-off-by:
-
- 08 Mar, 2005 23 commits
-
-
bk://kernel.bkbits.net/gregkh/linux/usb-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://bk.arm.linux.org.uk/linux-2.6-serialLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Russell King authored
Resolve a problem where a Sony Ericsson GC79 Cardbus device was not being correctly resumed across a S3 suspend, as reported by Hendrik Hoeth. Signed-off-by: -
vandrove@cz.rmk.(none) authored
Patch from Petr Vandrovec XScale detection needs access to Interrupt Enable Register on UART. But this register shares position with high byte clock divisor, and previous detection steps were leaving clock divisor and not IER selected, causing misdetection of all 16550A chips as XScale. Fix this by disabling access to clock divisor at the end of previous detection step, so chip is in same mode after each detection step. Signed-off-by: Petr Vandrovec
-
bk://bk.arm.linux.org.uk/linux-2.6-rmkLinus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Tony Lindgren authored
Patch from Tony Lindgren This patch adds support for 32k timer on OMAP 16xx, and 64-bit sched clock to the MPU timer. This is an update version of ARM patch 2337/1. The 32k timer modulo code has been left out, and the dynamic tick (VST) timer will be submitted in a separate patch. Signed-off-by: Tony Lindgren Signed-off-by: Russell King
-
Russell King authored
Oops, it broke. Glue the bits back together, replacing yrs with tm->tm_year + 1900. I will not merge untested changes into Linus' tree. I will not merge untested changes into Linus' tree. I will not merge untested changes into Linus' tree. I will not ... Signed-off-by: -
Richard Purdie authored
Patch from Richard Purdie Sharp SCOOP: Devices with multiple scoop interfaces are now available so: * add support for mutliple device support to the driver * Update corgi, collie and poodle to share the scoop device structure so a device can be selected in drivers * Update drivers to use the device structures Signed-off-by: Richard Purdie Signed-off-by: Russell King
-
Lennert Buytenhek authored
Patch from Lennert Buytenhek Another round of ixp2000 typo fixes. Signed-off-by: Lennert Buytenhek Signed-off-by: Russell King
-
Ben Dooks authored
Patch from Ben Dooks Add the Acer N30 machine, from Christer Weinigel Signed-off-by: Christer Weinigel Signed-off-by: Ben Dooks Signed-off-by: Russell King
-
Greg Kroah-Hartman authored
into suse.de:/home/greg/linux/BK/usb-2.6
-
bk://gkernel.bkbits.net/net-drivers-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Jeff Garzik authored
into pobox.com:/garz/repo/net-drivers-2.6
-
Paul Mackerras authored
This patch is from Nathan Lynch <ntl@pobox.com>. Use static inlines instead of #defines for stub functions when CONFIG_EEH=n, to eliminate "statement with no effect" warnings with some toolchains. Signed-off-by:
Nathan Lynch <ntl@pobox.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Paul Mackerras authored
This patch is from Nathan Lynch <ntl@pobox.com>. When offlining a cpu, any device interrupts which are bound to the cpu have their affinity forcibly reset to all cpus (the default). However, the value in /proc/irq/XXX/smp_affinity remains unchanged. Since we're doing this while all the other cpus are stopped, it should be safe to just call desc->handler->set_affinity and manually update the irq_affinity array. Signed-off-by:
-
Paul Mackerras authored
This patch is from Nathan Lynch <ntl@pobox.com>. Seeing this very occasionally during cpu hotplug testing: Badness in slb_flush_and_rebolt at arch/ppc64/mm/slb.c:52 Call Trace: [c0000000ef0efbe0] [c0000000000127a0] .__switch_to+0xa4/0xf0 (unreliable) [c0000000ef0efc80] [c000000000050178] .idle_task_exit+0xbc/0x15c [c0000000ef0efd10] [c00000000000d108] .cpu_die+0x18/0x68 [c0000000ef0efd90] [c00000000001023c] .dedicated_idle+0x1fc/0x254 [c0000000ef0efe80] [c00000000000fc80] .cpu_idle+0x3c/0x54 [c0000000ef0eff00] [c00000000003aa90] .start_secondary+0x108/0x148 [c0000000ef0eff90] [c00000000000bd28] .enable_64b_mode+0x0/0x28 idle_task_exit can result in a call to slb_flush_and_rebolt, which must not be called with interrupts enabled. Make the call with interrupts disabled. Signed-off-by:
-
Paul Mackerras authored
This patch is from John Rose <johnrose@austin.ibm.com> This patch changes the RPA PCI Hotplug and DLPAR modules to use more conventional error values for return codes. The goal is to make failure conditions obvious in the wrapper functions and in the caller code. Signed-off-by:
John Rose <johnrose@austin.ibm.com> Signed-off-by:
-
Paul Mackerras authored
This patch is from John Rose <johnrose@austin.ibm.com> This patch changes the rtas wrapper functions in rtas.c to map RTAS failure codes to conventional error values. The goal is to make failure conditions obvious in the wrapper functions and in the caller code. Signed-off-by:
-
Stephen Rothwell authored
This patch "inverts" the PPC64 dma mapping routines so that the pci_ and vio_ ... routines are implemented in terms of the dma_ ... routines (the vio_ routines disappear anyway as noone uses them directly any more). The most noticable change after this patch is applied will be that the flags passed to dma_alloc_coherent will now be honoured (whereas they were previously silently ignored since we used to just call pci_alloc_consistent). Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Andrea Arcangeli authored
Now that we cleaned up the guard page handling in vmalloc, we have to remove the p-PAGE_SIZE hack that was put in there for the original guard page handling. This also removes some spurious tab. Signed-off-by:
Andrea Arcangeli <andrea@suse.de> Signed-off-by:
-
Roland McGrath authored
While looking into the issues Jeremy had with the RLIMIT_SIGPENDING limit, it occurred to me that the normal setting of this limit is bizarrely low. The initial hard limit setting (MAX_SIGPENDING) was taken from the old max_queued_signals parameter, which was for the entire system in aggregate. But even as a per-user limit, the 1024 value is incongruously low for this. On my machine, RLIMIT_NPROC allows me 8192 processes, but only 1024 queued signals, i.e. fewer even than one pending signal in each process. (To me, this really puts in doubt the sensibility of using a per-user limit for this rather than a per-process one, i.e. counted in sighand_struct or signal_struct, which could have a much smaller reasonable value. I don't recall the rationale for making this new limit per-user in the first place.) This patch sets the default RLIMIT_SIGPENDING limit at boot time, using the calculation that decides the default RLIMIT_NPROC limit. This uses the same value for those two limits, which I think is still pretty conservative on the RLIMIT_SIGPENDING value. Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Roland McGrath authored
Jeremy mentioned the aggravation of not being able to tell when your processes are using up signal queue entries and hitting the RLIMIT_SIGPENDING limit. This patch adds a line to /proc/PID/status showing how many queue items are in use, and allowed, for your uid. I can certainly see the appeal of having a display of the number of queued items specific to each process, and even the items within the process broken down per signal number. However, those are not things that are directly counted, and ascertaining them requires iterating through the queue. This patch instead gives what can be readily determined in constant time using the accounting already done. I'm not sure something more complex is warranted just to facilitate one particular debugging need. With this, you can see quickly that this particular problem has come up. Then examination of each process's SigPnd/ShdPnd lines ought to give you an indication of which processes have any queued RT signals sitting around for a long time, and you can then attack those programs directly, though there is no way after the fact to determine how many queued signals with the same number a given process has (short of killing it and seeing the usage drop). Note you may still have a mystery if the leaking programs are not leaving pending RT signals queued, but rather preallocating queue items via timer_create. That usage is not readily apparent in any /proc information. Signed-off-by:
-
Roland McGrath authored
I can read POSIX to say that the siginfo_t data must be available when `kill' was used, as well. This patch makes it allocate the siginfo_t, even when that exceeds {RLIMIT_SIGPENDING}, for any non-RT signal (< SIGRTMIN) not sent by sigqueue (actually, any signal that couldn't have been faked by a sigqueue call). Of course, in an extreme memory shortage situation, you are SOL and violate POSIX a little before you die horribly from being out of memory anyway. The LEGACY_QUEUE logic already ensures that, for non-RT signals, at most one is ever on the queue. So there really is no risk at all of unbounded resource consumption; the usage can reach {RLIMIT_SIGPENDING} + 31, is all. It's already the case that the limit can be exceeded by (in theory) up to {RLIMIT_NPROC}-1 in race conditions because the bump and the limit check are not atomic. (Obviously you can only get anywhere near that many with assloads of preemption, but exceeding it by a few is not too unlikely.) This patch also fixes that accounting so that it should not be possible to exceed {RLIMIT_SIGPENDING} + SIGRTMIN-1 queue items per user in races. Signed-off-by:
-
