Re: sysfs change of input/event devices in 2.6.23rc breaks udev
On Mon, Sep 10, 2007 at 01:28:47AM -0400, Dmitry Torokhov wrote: > On Sunday 09 September 2007 19:03, Kay Sievers wrote: > > On 9/8/07, Anssi Hannula <[EMAIL PROTECTED]> wrote: > > > > > > However, the change that broke id_path of udev is that > > > /sys/class/input/event5/device is now a symlink to the inputX directory > > > instead of being the same as the device symlink in inputX directory, > > > i.e. to ../../../devices/platform/pcspkr in this case. > > > > > > Udev id_path uses that directory to construct the ID_PATH variable. > > > Should the sysfs structure be reverted or should udev be adapted to > > > handle traversing /device symlink twice? I think the former, as there > > > should be considerably more time to adapt udev for coming changes in > > > sysfs. > > > > Udev's path_id script is too dumb to follow the "device" link of > > stacked class devices in the CONFIG_SYSFS_DEPRECATED=y layout. Does > > this change fix it for you? > > > > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff_plain;h=b1ac36ff5e3756cefc79967a26280056da31bf6f > > > > Hmm, fixing udev is good but users will not get the change in time. I think we > need to adjust SYSFS_DEPRECATED code to produce old results. Something like > the > patch below. I wonder what Greg would think... Hm, I don't understand. Didn't the original conversion of the input layer by Kay not have this kind of problem? What did your changes do differently to cause this driver core change to be needed? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sysfs change of input/event devices in 2.6.23rc breaks udev
On Sunday 09 September 2007 19:03, Kay Sievers wrote:
> On 9/8/07, Anssi Hannula <[EMAIL PROTECTED]> wrote:
> >
> > However, the change that broke id_path of udev is that
> > /sys/class/input/event5/device is now a symlink to the inputX directory
> > instead of being the same as the device symlink in inputX directory,
> > i.e. to ../../../devices/platform/pcspkr in this case.
> >
> > Udev id_path uses that directory to construct the ID_PATH variable.
> > Should the sysfs structure be reverted or should udev be adapted to
> > handle traversing /device symlink twice? I think the former, as there
> > should be considerably more time to adapt udev for coming changes in sysfs.
>
> Udev's path_id script is too dumb to follow the "device" link of
> stacked class devices in the CONFIG_SYSFS_DEPRECATED=y layout. Does
> this change fix it for you?
>
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff_plain;h=b1ac36ff5e3756cefc79967a26280056da31bf6f
>
Hmm, fixing udev is good but users will not get the change in time. I think we
need to adjust SYSFS_DEPRECATED code to produce old results. Something like the
patch below. I wonder what Greg would think...
--
Dmitry
Driver core: fix deprectated sysfs structure for nested class devices
Nested class devices used to have 'device' symlink point to a real
(physical) device instead of a parent class device. When converting
subsystems to struct device we need to keep doing what class devices
did if CONFIG_SYSFS_DEPRECATED is Y, otherwise parts of udev break.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/base/core.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
Index: work/drivers/base/core.c
===
--- work.orig/drivers/base/core.c
+++ work/drivers/base/core.c
@@ -679,14 +679,26 @@ static int device_add_class_symlinks(str
goto out_subsys;
}
if (dev->parent) {
- error = sysfs_create_link(>kobj, >parent->kobj,
- "device");
- if (error)
- goto out_busid;
#ifdef CONFIG_SYSFS_DEPRECATED
{
- char * class_name = make_class_name(dev->class->name,
- >kobj);
+ struct device *parent = dev->parent;
+ char *class_name;
+
+ /*
+* In old sysfs stacked class devices had 'device'
+* link pointing to real device instead of parent
+*/
+ while (parent->class && !parent->bus && parent->parent)
+ parent = parent->parent;
+
+ error = sysfs_create_link(>kobj,
+ >kobj,
+ "device");
+ if (error)
+ goto out_busid;
+
+ class_name = make_class_name(dev->class->name,
+ >kobj);
if (class_name)
error = sysfs_create_link(>parent->kobj,
>kobj, class_name);
@@ -694,6 +706,11 @@ static int device_add_class_symlinks(str
if (error)
goto out_device;
}
+#else
+ error = sysfs_create_link(>kobj, >parent->kobj,
+ "device");
+ if (error)
+ goto out_busid;
#endif
}
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Union Mount: Readdir approaches
On Fri, Sep 07, 2007 at 01:54:18PM -0400, Erez Zadok wrote: > In message <[EMAIL PROTECTED]>, "Josef 'Jeff' Sipek" writes: > > On Fri, Sep 07, 2007 at 01:28:55PM +0530, Bharata B Rao wrote: > > > On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote: > > > > > > > > When the first readdir is issued: > > > > - call vfs_readdir for every underlying opened dir (file) object. > > > > - store every entry to either the hash table for the result or the > > > > whiteout, when the same-named entry didn't exist in the tables. > > > > - to improvement the performance, the allocated memory for the hash > > > > tables are managed in a pointer array. and the elements are > > > > concatinated logically by the pointer. > > > > - the pointer for the result-table, the version, and the currect jiffies > > > > are set to vdir, which is a cache in an inode. > > > > - all cache are copied to a member in a file object. > > > > - the index of the cache memory block and the offset in an array is > > > > handled as the seek position. > > > > > > Ok, interesting approach. So you define the seek behaviour on your > > directory cache rather than allowing the underlying filesystems to > > > interpret the seek. I guess we can do something similar with Union > > > Mounts also. > > > > Unless I missunderstood something, Unionfs uses the same approach. Even > > Unionfs's ODF branch does the same thing. The major difference is that we > > keep the cache in a file on a disk. > > Yup. > > Bharata, in the long run, storing a cache of the readdir state on disk, is > the best approach by far. Since you already spend the CPU and memory > resources to create a merged view, storing it on disk as a contiguous file > isn't that much more effort. That effort pays off later on esp. if the > directories don't change often: Erez, I agree that there are positives in storing the readdir state on disk, but ... > > - you get a compatible behavior with seekdir/telldir (no matter how > braindead that interface is :-) lseek problem can also be solved by defining the seek on the cached (in memory) readdir state. (similar to aufs) > > - for subsequent directory reading, your performance actually improves > because you don't have to repeat the duplicate elimination and whiteout > processing -- just read the cached file from disk as any other file. You > then benefit from traditional readahead, and from not having to cache the > entire contents of the readdir state file, so it falls under normal > paging/flushing policies. I guess, same performance benefits can be obtained if we leave the readdir state in memory for sometime. In the Approach 2 which I described in my original post, the readdir state was stored as part of the file structure and it remained there until the last close of the directory. > > Any policy which merges the readdir info and keeps it in memory indefinitely > is problematic -- you increase average memory pressure on the system over a > longer period of time; and when you purge your readdir state from memory, > you have to recreate it from scratch, re-consuming the same CPU/memory > resources. Yes, keeping the state in memory indefinitely is problematic. But we can always purge it under memory pressure. If it comes to that then it is a tradeoff between recreating the state after purging and having the state stored in a separate physical file system. Not related directly to readdir, but I had concerns about ODF: - Creating/Replicating the entire directory tree of the union. So you can potentially have a very large tree duplicated (ofcouse with zero length files, but still) in ODF. - Storing whiteouts in ODF might be a feasible solution for unionfs, but for union mount it looks like an overhead. You can afford to have an extra (whiteout) lookup into ODF from your unionfs lookup code, since you do all this from unionfs filesystems code. But doing anything similar with union mounts from VFS layer is going to look ugly. Regards, Bharata. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: In search of 10gbps cards/shootout in Linux?
On Sat, 8 Sep 2007, Justin Piszcz wrote: > There are various agencies/educational institutions doing testing but was > curious if anyone has 'found' a 10 gigabit card shootout measuring the > performance between 10 gigabit cards on the 2.6 kernel? Most of the > benchmarks are from the vendors themselves Intel/etc-- was wondering if > there were any vendor-independent benchmarks out there? > > Until switches come down in price, 10gbps will be most relegated to > business/research use and therefore such benchmarks probably will be hard > to come by but I thought I'd ask.. I haven't done any comparisons with other vendor offerings, but I can highly recommend the Myricom PCI-Express (8x) 10-GigE NICs. They only cost about $900 and can do full unidirectional 10-GigE line rate. And as a 10-GigE router, they can do full bidirectional 10-GigE line rate IP forwarding. Note the choice of system/motherboard/CPU is as important as the choice of NIC in achieving maximum performance. Sample nuttcp test: chance7 -> chance9 10-second TCP test: [EMAIL PROTECTED] ~]# nuttcp -w10m 192.168.88.16 11817.8125 MB / 10.00 sec = 9909.8073 Mbps 100 %TX 71 %RX The system specs are: Tyan Thunder K8WE S2895ANRF motherboard with Nvidia nForce Professional 2200+2050 chipset, 2 AMD Opteron 254 2.8 GHz CPUs, 4 GB PC3200 ECC REG-DDR 400 memory, and 2 PCI-Express x16 slots (2 buses). The systems are running a 2.6.20.7 kernel. Perhaps others can share their experiences with 10-GigE NICs. -Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Maple bus support for the Sega Dreamcast - keyboard support
Hi Adrian,
On Sunday 09 September 2007 16:57, Adrian McMenamin wrote:
>
> Add maple bus keyboard support to the kernel.
>
> Signed-off by Adrian McMenamin <[EMAIL PROTECTED]>
>
Couple of more things:
> +
> +extern int maple_driver_register(struct device_driver *drv);
> +
No externs in *.c files, please. Isn't this defined in maple.h which is
being included?
> +
> +static void dc_kbd_callback(struct mapleq *mq)
> +{
> + struct maple_device *mapledev = mq->dev;
> + struct dc_kbd *kbd = mapledev->private_data;
> + unsigned long *buf = mq->recvbuf;
I very much prefer an empty line between variables and the code.
> + if (!mutex_trylock(_keyb_mutex)) /* Can only be locked if
> already in cleanup */
> + return;
> + if (buf[1] == mapledev->function) {
> + memcpy(kbd->new, buf + 2, 8);
> + dc_scan_kbd(kbd);
> + }
> + mutex_unlock(_keyb_mutex);
> +}
> +
> +static int dc_kbd_connect(struct maple_device *dev)
> +{
> + int i, retval = 0;
> + struct dc_kbd *kbd;
> + if (!(dev->function & MAPLE_FUNC_KEYBOARD))
> + return -EINVAL;
> +
> + kbd = kzalloc(sizeof(struct dc_kbd), GFP_KERNEL);
> + if (unlikely(!kbd))
> + return -ENOMEM;
> +
> + dev->private_data = kbd;
> + kbd->dev = input_allocate_device();
> + if (!kbd->dev){
> + retval = -ENODEV;
> + goto cleanup_memory;
> + }
> +
> + for (i = 0; i < NR_SCANCODES; i++)
> + kbd->keycode[i] = dc_kbd_keycode[i];
memcpy?
> + kbd->dev->evbit[0] = BIT(EV_KEY) | BIT(EV_REP);
> + kbd->dev->keycodesize = sizeof (unsigned char);
> + kbd->dev->keycodemax = ARRAY_SIZE(kbd->keycode);
> + kbd->dev->keycode = kbd->keycode;
> +
> +
> + for (i = 0; i < 255; i++)
Are you sure it is 255 and not NR_SCANCODES?
> + set_bit(dc_kbd_keycode[i], kbd->dev->keybit);
> +
> + clear_bit(0, kbd->dev->keybit);
> +
> + kbd->dev->private = kbd;
Please use input_set_drvdata() here and input_get_drvdata() when
accessing it.
> +
> + kbd->dev->name = dev->product_name;
> + kbd->dev->id.bustype = BUS_HOST;
> +
maple_device appears to be fully integrated in sysfs, please add:
kbd->dev->dev.parent = >dev;
Btw, introducing a temp for kbd->dev should reduce generated code
somewhat.
> + retval = input_register_device(kbd->dev);
> + if (retval)
> + goto cleanup;
> + /* Maple polling is locked to VBLANK - which may be just 50/s */
> + maple_getcond_callback(dev, dc_kbd_callback, HZ/50,
> +MAPLE_FUNC_KEYBOARD);
> + return retval;
> +
> +cleanup:
> + input_free_device(kbd->dev);
> +cleanup_memory:
> + kfree(kbd);
> + return retval;
> +}
> +
> +static void dc_kbd_disconnect(struct maple_device *dev)
> +{
> + struct dc_kbd *kbd;
> + mutex_lock(_keyb_mutex);
> + kbd = dev->private_data;
> +
> + input_unregister_device(kbd->dev);
> + kfree(kbd);
> + mutex_unlock(_keyb_mutex);
> +}
> +
> +/* allow the keyboard to be used */
> +static int probe_maple_kbd(struct device *dev)
> +{
> + struct maple_device *mdev;
> + struct maple_driver *mdrv;
> + int proberes;
> +
> + mdev = to_maple_dev(dev);
> + mdrv = to_maple_driver(dev->driver);
> +
> + proberes = dc_kbd_connect(mdev);
> + if (unlikely(proberes))
> + return proberes;
> + mdev->driver = mdrv;
> + mdev->registered = 1;
> + return 0;
> +}
> +
> +static struct maple_driver dc_kbd_driver = {
> + .function = MAPLE_FUNC_KEYBOARD,
> + .connect = dc_kbd_connect,
> + .disconnect = dc_kbd_disconnect,
> + .drv = {
> + .name = "Dreamcast_keyboard",
> + .probe = probe_maple_kbd,
> + },
> +};
> +
> +static int __init dc_kbd_init(void)
> +{
> + int retval;
> + retval = maple_driver_register(_kbd_driver.drv);
> + if (retval)
> + return retval;
> + return 0;
"return maple_driver_register(_kbd_driver.drv);" is much shorter...
> +}
> +
> +static void __exit dc_kbd_exit(void)
> +{
> + driver_unregister(_kbd_driver.drv);
> +}
> +
> +module_init(dc_kbd_init);
> +module_exit(dc_kbd_exit);
If these are fixed you may add:
Acked-by: Dmitry Torokhov <[EMAIL PROTECTED]>
Thank you.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Union Mount: Readdir approaches
On Fri, Sep 07, 2007 at 01:39:41PM -0400, Josef 'Jeff' Sipek wrote: > On Fri, Sep 07, 2007 at 01:28:55PM +0530, Bharata B Rao wrote: > > On Fri, Sep 07, 2007 at 04:31:26PM +0900, [EMAIL PROTECTED] wrote: > > > > > > When the first readdir is issued: > > > - call vfs_readdir for every underlying opened dir (file) object. > > > - store every entry to either the hash table for the result or the > > > whiteout, when the same-named entry didn't exist in the tables. > > > - to improvement the performance, the allocated memory for the hash > > > tables are managed in a pointer array. and the elements are > > > concatinated logically by the pointer. > > > - the pointer for the result-table, the version, and the currect jiffies > > > are set to vdir, which is a cache in an inode. > > > - all cache are copied to a member in a file object. > > > - the index of the cache memory block and the offset in an array is > > > handled as the seek position. > > > > Ok, interesting approach. So you define the seek behaviour on your > > directory cache rather than allowing the underlying filesystems to > > interpret the seek. I guess we can do something similar with Union > > Mounts also. > > Unless I missunderstood something, Unionfs uses the same approach. Even But in the version of unionfs present in -mm, lseek on directories is still limited in functionality as it allows seeking to only the beginning and to the current position. > Unionfs's ODF branch does the same thing. The major difference is that we > keep the cache in a file on a disk. And as Erez explained, it is ODF which is allowing you to have a complete lseek behaviour. Regards, Bharata. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revised timerfd() interface
Hi Davide, >> This function is *not at all* equivalent to the "get" >> functionality of the previous APIs. The "get" functionality >> of POSIX timers (for example) returns a structure that contains >> the timer interval and the *time until the next expiration of >> the timer* (not the initial timer string, as your code above >> does). >> So come up with a reliable, race-free way of doing that in >> userspace. Then make it work for both CLOCK_MONOTONIC and >> CLOCK_REALTIME timers. (You'll certainly need to be making >> some additional system calls, by the way: at least some >> calls to clock_gettime().) > > No, I don't think I will. Since 1) it's so trivial it's not even > challenging Well, it seems to me that the proposed library wrapper code could start to get rather verbose by the time one adds in these changes (plus the mutexes). > 2) you know it can be done (I assume) Sorry -- I was probably speaking too rhetorically. In fact, it's not completely clear to me that it can (always) be done. For example, the answer depends on knowing the clockid. But what if the file descriptor has been handed off to some code that doesn't know the clock type (i.e., isn't accessing the fd via your suggested library)? Cheers, Michael > 3) it solves a non-case > made up to justify an API/kernel-code bloating. > But you don't need *my* signoff. Cook a working patch, make a case for it, > and gather support and signoffs. I won't be acking it because, as I said > many times, I think it's useless bloating. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] kernel/kexec.c: make code static
Hi Adrian, 2007/09/09 22:25:16 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote: >On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote: >>... >> Changes since 2.6.23-rc3-mm1: >>... >> +add-vmcoreinfo.patch >>... >> misc >>... > >This patch makes the following needlessly global code static: >- vmcoreinfo_data[] >- vmcoreinfo_size >- vmcoreinfo_append_str() The kernel compiling fails with your patch because architecture-specific function should access the above data/function: # make [snip] arch/ia64/kernel/machine_kexec.c: In function 'arch_crash_save_vmcoreinfo': arch/ia64/kernel/machine_kexec.c:134: error: implicit declaration of function 'SYMBOL' arch/ia64/kernel/machine_kexec.c:135: error: implicit declaration of function 'LENGTH' arch/ia64/kernel/machine_kexec.c:139: error: implicit declaration of function 'SIZE' arch/ia64/kernel/machine_kexec.c:139: error: 'node_memblk_s' undeclared (first use in this function) arch/ia64/kernel/machine_kexec.c:139: error: (Each undeclared identifier is reported only once arch/ia64/kernel/machine_kexec.c:139: error: for each function it appears in.) arch/ia64/kernel/machine_kexec.c:140: error: implicit declaration of function 'OFFSET' arch/ia64/kernel/machine_kexec.c:140: error: 'start_paddr' undeclared (first use in this function) arch/ia64/kernel/machine_kexec.c:141: error: 'size' undeclared (first use in this function) arch/ia64/kernel/machine_kexec.c:144: error: implicit declaration of function 'CONFIG' arch/ia64/kernel/machine_kexec.c:144: error: 'PGTABLE_3' undeclared (first use in this function) make[1]: *** [arch/ia64/kernel/machine_kexec.o] Error 1 make: *** [arch/ia64/kernel] Error 2 # Thanks Ken'ichi Ohmichi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH - RESUBMiT] Minor patch to pvr2 driver required for maple bus support on SEGA Dreamcast
On Wed, Sep 05, 2007 at 12:27:20AM +0100, Adrian McMenamin wrote:
> diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
> index 7d6c298..13de07f 100644
> --- a/drivers/video/pvr2fb.c
> +++ b/drivers/video/pvr2fb.c
> @@ -890,7 +890,7 @@ static int __init pvr2fb_dc_init(void)
> pvr2_fix.mmio_start = 0xa05f8000; /* registers start here */
> pvr2_fix.mmio_len = 0x2000;
>
> - if (request_irq(HW_EVENT_VSYNC, pvr2fb_interrupt, 0,
> + if (request_irq(HW_EVENT_VSYNC, pvr2fb_interrupt, IRQF_SHARED,
> "pvr2 VBL handler", fb_info)) {
> return -EBUSY;
> }
>
I'll apply it, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sysfs change of input/event devices in 2.6.23rc breaks udev
Kay Sievers wrote: > On 9/8/07, Anssi Hannula <[EMAIL PROTECTED]> wrote: >> There seem to be changes in sysfs input structure between 2.6.22 and >> 2.6.23-rc5 which cause some breakage. >> >> With 2.6.22: >> >> > # LC_ALL=C ls -l /sys/class/input/input4 >> > total 0 >> > drwxr-xr-x 2 root root0 Sep 8 12:51 capabilities/ >> > lrwxrwxrwx 1 root root0 Sep 8 19:48 device -> >> > ../../../devices/platform/pcspkr/ >> > drwxr-xr-x 2 root root0 Sep 8 12:51 event4/ >> > drwxr-xr-x 2 root root0 Sep 8 12:51 id/ >> > -r--r--r-- 1 root root 4096 Sep 8 19:48 modalias >> > -r--r--r-- 1 root root 4096 Sep 8 19:48 name >> > -r--r--r-- 1 root root 4096 Sep 8 19:48 phys >> > lrwxrwxrwx 1 root root0 Sep 8 19:48 subsystem -> >> > ../../../class/input/ >> > --w--- 1 root root 4096 Sep 8 19:48 uevent >> > -r--r--r-- 1 root root 4096 Sep 8 19:48 uniq >> >> > # ls -l /sys/class/input/event4 >> > lrwxrwxrwx 1 root root 0 Sep 8 19:48 /sys/class/input/event4 -> >> > ../../class/input/input4/event4/ >> > # ls -l /sys/class/input/event4/ >> > total 0 >> > -r--r--r-- 1 root root 4096 Sep 8 19:58 dev >> > lrwxrwxrwx 1 root root0 Sep 8 19:58 device -> >> > ../../../../devices/platform/pcspkr/ >> > lrwxrwxrwx 1 root root0 Sep 8 19:58 subsystem -> >> > ../../../../class/input/ >> > --w--- 1 root root 4096 Sep 8 19:58 uevent >> >> With 2.6.23-rc5: >> >> > # ls -l /sys/class/input/input5 >> > total 0 >> > drwxr-xr-x 2 root root0 Sep 8 19:47 capabilities/ >> > lrwxrwxrwx 1 root root0 Sep 8 19:03 device -> >> > ../../../devices/platform/pcspkr/ >> > drwxr-xr-x 2 root root0 Sep 8 19:47 id/ >> > lrwxrwxrwx 1 root root0 Sep 8 19:47 input:event5 -> >> > ../../../class/input/event5/ >> > -r--r--r-- 1 root root 4096 Sep 8 19:03 modalias >> > -r--r--r-- 1 root root 4096 Sep 8 19:03 name >> > -r--r--r-- 1 root root 4096 Sep 8 19:47 phys >> > drwxr-xr-x 2 root root0 Sep 8 19:47 power/ >> > lrwxrwxrwx 1 root root0 Sep 8 19:03 subsystem -> >> > ../../../class/input/ >> > -rw-r--r-- 1 root root 4096 Sep 8 19:03 uevent >> > -r--r--r-- 1 root root 4096 Sep 8 19:47 uniq >> >> > # ls -l /sys/class/input/event5 >> > total 0 >> > -r--r--r-- 1 root root 4096 Sep 8 19:03 dev >> > lrwxrwxrwx 1 root root0 Sep 8 19:03 device -> >> > ../../../class/input/input5/ >> > drwxr-xr-x 2 root root0 Sep 8 19:48 power/ >> > lrwxrwxrwx 1 root root0 Sep 8 19:03 subsystem -> >> > ../../../class/input/ >> > -rw-r--r-- 1 root root 4096 Sep 8 19:03 uevent >> >> There are a few changes. >> >> There is no longer: >> /sys/class/input/eventX => /sys/class/input/inputX/eventX >> instead there is: >> /sys/class/inputX/input:eventX => /sys/class/input/eventX >> Notice the added "input:". I don't know if any software depends on this, >> though. >> >> However, the change that broke id_path of udev is that >> /sys/class/input/event5/device is now a symlink to the inputX directory >> instead of being the same as the device symlink in inputX directory, >> i.e. to ../../../devices/platform/pcspkr in this case. >> >> Udev id_path uses that directory to construct the ID_PATH variable. >> Should the sysfs structure be reverted or should udev be adapted to >> handle traversing /device symlink twice? I think the former, as there >> should be considerably more time to adapt udev for coming changes in >> sysfs. > > Udev's path_id script is too dumb to follow the "device" link of > stacked class devices in the CONFIG_SYSFS_DEPRECATED=y layout. Does > this change fix it for you? > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff_plain;h=b1ac36ff5e3756cefc79967a26280056da31bf6f > This just delays the issue until we have 3 levels of indirection :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dynamically use the irqbalance
Hi, all.
I want to dynamically use irqbalance on X86 processor. My design is
like the following:
1) if we boot kernel with "noirqbalance", then irqbalance is always
disabled.
2) if we boot kernel without "noirqbalance", we can enable/disable
irqbalance in runtime.
I create a proc_fs entry /proc/sys/kernel/irqbalance
This symbol I adding is in file arch/i386/kernel/io_apic.c
/proc/sys/kernel/irqbalance = 0 /* disable irqbalance in runtime */
/proc/sys/kernel/irqbalance = 1 /* enable irqbalance in runtime */
The core function is like the following:
irqbalance_irq_flag = -1; /* this is the last time irqbalance used */
irqbalance_enable = 1; /* set it to enable by default */
static int balanced_irq(void *unused)
{
int i;
unsigned long prev_balance_time = jiffies;
long time_remaining = balanced_irq_interval;
daemonize("kirqd");
/* push everything to CPU 0 to give us a starting point. */
for (i = 0 ; i < NR_IRQS ; i++) {
irq_desc[i].pending_mask = cpumask_of_cpu(0);
set_pending_irq(i, cpumask_of_cpu(0));
}
for ( ; ; ) {
time_remaining = schedule_timeout_interruptible(time_remaining);
try_to_freeze();
if(irqbalance_enable) {
if (time_after(jiffies,
prev_balance_time+balanced_irq_interval)) {
preempt_disable();
do_irq_balance();
prev_balance_time = jiffies;
time_remaining = balanced_irq_interval;
preempt_enable();
irqbalance_irq_flag = 1;
}
} else if (irqbalance_irq_flag != 0) {
/* Is it SAFE to do so? */
for (i = 0 ; i < NR_IRQS ; i++)
set_pending_irq(i, cpumask_of_cpu(0));
irqbalance_irq_flag = 0;
}
}
return 0;
}
When we change /proc/sys/kernel/irqbalance from 1 to 0, I move all the
irqs to CPU#0, Is it safe to do so? or will lead to some very dangerous
thing?
Please help me to review my design, thanks in advance.
BTW: I can't join the linux-kernel maillist, for our mail server now has
some problems. If anyone replies my mail. Pls CC to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Union Mount: Readdir approaches
Matt Keenan: > This sounds like a good approach. How does aufs handle low memory > situations? Union mounts seem to be quite common on low memory embedded > systems. Is there a way for the VM to signal to aufs/the union > filesystem to trim its cache? Also on the memory consumption front I I also want to find the way to make this implementation to be smaller. Basically there is no such signal or message. The cache for entries will be discarded when the inode cache is shrinked or the file is closed (and the file object is destroyed), because it is in inode or file object. It is up to your system memory size or something when the inode cache is shrinked. Junjiro Okajima - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Union Mount: Readdir approaches
Hello Jeff, "Josef 'Jeff' Sipek": > Unless I missunderstood something, Unionfs uses the same approach. Even > Unionfs's ODF branch does the same thing. The major difference is that we > keep the cache in a file on a disk. The approach unionfs-2.1.2 took differs from mine. Major difference is, - in this approach, the cache in struct file is the completed virtual disk block for the dir. - readdir doesn't have to call vfs_readdir when the cache exists and is valid. simply calls filldir. - it supports SEEK_END. Junjiro Okajima - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unfamiliar notation
On Mon, Sep 10, 2007 at 03:20:15AM +0200, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > What's the deal with the underscore and the parentheses surrounding the > > call to menu_get_help? > > it is a macro from gettext, used to translate the string. Usually this > should only be used on string constants. Correct. And only in kconfig since this is the only piece of code supporting gettext in the kernel. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC]selinux: Improving SELinux read/write performance
On Thu, 06 Sep 2007 09:47:15 -0400
Stephen Smalley wrote:
> >
> > @@ -431,8 +432,10 @@ static int avc_latest_notif_update(int s
> > ret = -EAGAIN;
> > }
> > } else {
> > - if (seqno > avc_cache.latest_notif)
> > + if (seqno > avc_cache.latest_notif) {
> > avc_cache.latest_notif = seqno;
> > + policy_seqno = seqno;
> > + }
>
> I would have just provided an avc interface for obtaining the seqno,
> e.g.
> u32 avc_policy_seqno(void)
> {
> return avc_cache.latest_notif;
> }
Fixed.
>
> > }
> > spin_unlock_irqrestore(_lock, flag);
> >
> > diff -purN -X linux-2.6.22/Documentation/dontdiff
> > linux-2.6.22.orig/security/selinux/hooks.c
> > linux-2.6.22/security/selinux/hooks.c
> > --- linux-2.6.22.orig/security/selinux/hooks.c 2007-07-09
> > 08:32:17.0 +0900
> > +++ linux-2.6.22/security/selinux/hooks.c 2007-09-06 16:08:36.0
> > +0900
> > @@ -84,6 +84,7 @@
> > extern unsigned int policydb_loaded_version;
> > extern int selinux_nlmsg_lookup(u16 sclass, u16 nlmsg_type, u32 *perm);
> > extern int selinux_compat_net;
> > +extern u32 policy_seqno;
>
> I think that they frown upon extern declarations in .c files (versus
> in .h files), so we don't want to add more - we ultimately should clean
> up what we presently have.
Removed policy_seqno.
>
> >
> > #ifdef CONFIG_SECURITY_SELINUX_DEVELOP
> > int selinux_enforcing = 0;
> > @@ -220,6 +221,8 @@ static int file_alloc_security(struct fi
> >
> > fsec->file = file;
> > fsec->sid = tsec->sid;
> > + fsec->tsid = tsec->sid;
>
> I'm not sure why we need the separate field here, as fsec->sid already
> holds the allocating task SID and doesn't change.
I see.
removed fsec->tsid.
> > + fsec->pseqno = policy_seqno;
>
> Not sure that you want to set the seqno here versus from your new hook,
> as it could conceivably change in between.
Fixed, pseqno is set in selinux_dentry_open.
> > fsec->fown_sid = tsec->sid;
> > file->f_security = fsec;
> >
> > @@ -2458,7 +2461,7 @@ static int selinux_inode_listsecurity(st
> >
> > /* file security operations */
> >
> > -static int selinux_file_permission(struct file *file, int mask)
> > +static int do_selinux_file_permission(struct file *file, int mask)
>
> Might want to rename for clarity, e.g.
> selinux_revalidate_file_permission or
> selinux_file_permission_slow (slow path) or
> something similar.
Renamed to selinux_revalidate_file_permission.
>
> > {
> > int rc;
> > struct inode *inode = file->f_path.dentry->d_inode;
> > @@ -2480,6 +2483,43 @@ static int selinux_file_permission(struc
> > return selinux_netlbl_inode_permission(inode, mask);
> > }
> >
> > +static int selinux_file_permission(struct file *file, int mask)
> > +{
> > + struct inode *inode = file->f_path.dentry->d_inode;
> > + struct task_security_struct *tsec = current->security;
> > + struct file_security_struct *fsec = file->f_security;
> > + struct inode_security_struct *isec = inode->i_security;
> > +
> > + if (!mask) {
> > + /* No permission to check. Existence test. */
> > + return 0;
> > + }
> > +
> > + if (tsec->sid != fsec->tsid) {
> > + if (tsec->sid != fsec->sid) {
> > + struct vfsmount *mnt = file->f_path.mnt;
> > + struct dentry *dentry = file->f_path.dentry;
> > + struct avc_audit_data ad;
> > + int rc;
> > + AVC_AUDIT_DATA_INIT(, FS);
> > + ad.u.fs.mnt = mnt;
> > + ad.u.fs.dentry = dentry;
> > + rc = avc_has_perm(tsec->sid, fsec->sid,
> > + SECCLASS_FD,
> > + FD__USE,
> > + );
> > + if (rc)
> > + return rc;
> > + }
>
> Why inline the FD_USE check here given that you are falling back to the
> full function call anyway? I also don't see why you separate this from
> the rest of the comparison - I'd just make it something like:
> if (tsec->sid == fsec->sid && isec->sid == fsec->isid &&
> avc_seqno() == fsec->seqno)
> return selinux_netlbl_inode_permission(inode, mask);
> return selinux_revalidate_file_permission(file, mask);
Thanks, I missed that.
FD_USE check is called in file_permission..
Fixed like you pointed out.
> > static int selinux_file_alloc_security(struct file *file)
> > {
> > return file_alloc_security(file);
> > @@ -2715,6 +2755,16 @@ static int selinux_file_receive(struct f
> > return file_has_perm(current, file, file_to_av(file));
> > }
> >
> > +static int selinux_dentry_open(struct file *file, int flags)
> > +{
> > + struct file_security_struct *fsec;
> > + struct inode_security_struct *isec;
> > + fsec = file->f_security;
> > + isec =
Re: unfamiliar notation
In article <[EMAIL PROTECTED]> you wrote: > What's the deal with the underscore and the parentheses surrounding the > call to menu_get_help? it is a macro from gettext, used to translate the string. Usually this should only be used on string constants. Gruss Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tbench regression - Why process scheduler has impact on tbench and why small per-cpu slab (SLUB) cache creates the scenario?
On Sat, 2007-09-08 at 18:08 +1000, Nick Piggin wrote: > On Wednesday 05 September 2007 17:07, Christoph Lameter wrote: > > On Wed, 5 Sep 2007, Zhang, Yanmin wrote: > > > > slub_max_order=3 slub_min_objects=8 > > > > > > I tried this approach. The testing result showed 2.6.23-rc4 is about > > > 2.5% better than 2.6.22. It really resovles the issue. > > > > Note also that the configuration you tried is the way SLUB is configured > > in Andrew's tree. > > It still doesn't sound like it is competitive with SLAB at the same sizes. > What's the problem? Process scheduler and small SLUB per-cpu cache work together to create the tebnch regression. Pls. see the starting of the thread. -yanmin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RFC] Secure defaults (initial sysctl settings)
Allow for various sysctl settings to initially be set to more secure
defaults.
Why: While you can easily set these values at boot time with sysctl
(and most distros do).
-Its nice to be able to set their initial value.
-It also allows someone who is unfamiliar with all the security knobs
the kernel exposes to easily turn one on or off (or even read about
what it does).
-Another benefit is every time a new security feature comes out
(mmap_min_addr for example) you don't have to change the setting on
every server. Or heck even be totally unaware of it until you read
about it on months later.
While some options (syncookies comes to mind) might be better places
somewhere else...
Im more interested to see if anyone thinks this is a good idea.
I mainly did this because I wanted a way to turn on mmap_min_addr by default.
After which i thought hrm, what other sysctl settings do I regularly
change the default setting...
Also it *seems* like it might be nice to move other security related
(fstack-protector, seecomp) under Security.
What does everyone else think?
Oh and sorry about the gross use of Kconfig CONFIG_ defines, whats a
better way to do this? static inlines #ifdef CONFIG_XXX in the
headers?
Signed-off-by: Alex Hunsaker <[EMAIL PROTECTED]>
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 5b77bda..438eb1d 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -65,20 +65,24 @@
struct ipv4_devconf ipv4_devconf = {
.data = {
- [NET_IPV4_CONF_ACCEPT_REDIRECTS - 1] = 1,
- [NET_IPV4_CONF_SEND_REDIRECTS - 1] = 1,
+ [NET_IPV4_CONF_ACCEPT_REDIRECTS - 1] = CONFIG_IPV4_ACCEPT_REDIRECTS,
+ [NET_IPV4_CONF_SEND_REDIRECTS - 1] = CONFIG_IPV4_SEND_REDIRECTS,
[NET_IPV4_CONF_SECURE_REDIRECTS - 1] = 1,
[NET_IPV4_CONF_SHARED_MEDIA - 1] = 1,
+ [NET_IPV4_CONF_LOG_MARTIANS - 1] = CONFIG_IPV4_LOG_MARTIANS,
+ [NET_IPV4_CONF_RP_FILTER - 1] = CONFIG_IPV4_RP_FILTER,
},
};
static struct ipv4_devconf ipv4_devconf_dflt = {
.data = {
- [NET_IPV4_CONF_ACCEPT_REDIRECTS - 1] = 1,
- [NET_IPV4_CONF_SEND_REDIRECTS - 1] = 1,
+ [NET_IPV4_CONF_ACCEPT_REDIRECTS - 1] = CONFIG_IPV4_ACCEPT_REDIRECTS,
+ [NET_IPV4_CONF_SEND_REDIRECTS - 1] = CONFIG_IPV4_SEND_REDIRECTS,
[NET_IPV4_CONF_SECURE_REDIRECTS - 1] = 1,
[NET_IPV4_CONF_SHARED_MEDIA - 1] = 1,
- [NET_IPV4_CONF_ACCEPT_SOURCE_ROUTE - 1] = 1,
+ [NET_IPV4_CONF_ACCEPT_SOURCE_ROUTE - 1] =
CONFIG_IPV4_ACCEPT_SOURCE_ROUTE,
+ [NET_IPV4_CONF_LOG_MARTIANS - 1] = CONFIG_IPV4_LOG_MARTIANS,
+ [NET_IPV4_CONF_RP_FILTER - 1] = CONFIG_IPV4_RP_FILTER,
},
};
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index a12b08f..99e29e5 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -29,7 +29,7 @@
#include
#ifdef CONFIG_SYSCTL
-#define SYNC_INIT 0 /* let the user enable it */
+#define SYNC_INIT CONFIG_TCP_SYNCOOKIES_ON
#else
#define SYNC_INIT 1
#endif
diff --git a/security/Kconfig b/security/Kconfig
index 460e5c9..e469dd6 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -93,6 +93,8 @@ config SECURITY_ROOTPLUG
If you are unsure how to answer this question, answer N.
+source security/Kconfig.secure_defaults
+
source security/selinux/Kconfig
endmenu
diff --git a/security/Kconfig.secure_defaults b/security/Kconfig.secure_defaults
new file mode 100644
index 000..2b2199e
--- /dev/null
+++ b/security/Kconfig.secure_defaults
@@ -0,0 +1,92 @@
+config SECURITY_SECURE_DEFAULTS
+ tristate "Secure defaults"
+ depends on SECURITY
+ help
+ Allows tuning of various kernel knobs to be secure by default.
+ NOTE: all of these have equivalent sysctl options
+
+config SECURITY_MMAP_MIN_ADDR
+ int "default mmap min address"
+ help
+ Help prevent users from exploiting NULL dereferences in the
kernel which have
+ not been discovered yet.
+ range 0 65536
+ depends on SECURITY_SECURE_DEFAULTS
+ default "4096"
+
+
+config SECURITY_TCP_SYNCOOKIES
+ bool "Turn on syncookies by default"
+ help
+ Syncookies can help prevent syn-flood attacks
+ (see Documentation/networking/ip-sysctl.txt for more)
+ depends on SYN_COOKIES
+ depends on SECURITY_SECURE_DEFAULTS
+ default y
+
+config TCP_SYNCOOKIES_ON
+ int
+ default 1 if SECURITY_TCP_SYNCOOKIES
+ default 0
+
+config SECURITY_IPV4_NO_ACCEPT_REDIRECTS
+ bool "Don't accept IMCP redirects"
+ help
+ ICMP redirects can be used to set up MITM attacks and other nasties
+ depends on SECURITY_SECURE_DEFAULTS
+ default y
+
+config IPV4_ACCEPT_REDIRECTS
+ int
+ default 0 if SECURITY_IPV4_NO_ACCEPT_REDIRECTS
+ default 1
+
+config SECURITY_IPV4_NO_SEND_REDIRECTS
+ bool "Don't send IMCP redirects"
+ help
+ Usually only needed if this computer functions as a router of some sort.
+ depends on SECURITY_SECURE_DEFAULTS
+ default y
+
+config IPV4_SEND_REDIRECTS
+ int
+ default 0 if
Re: [-mm patch] unexport sys_{open,read}
On Sun, Sep 09, 2007 at 11:41:18PM +0100, Arjan van de Ven wrote: > On Mon, 10 Sep 2007 00:22:03 +0200 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Sun, Sep 09, 2007 at 02:59:40PM -0700, Andrew Morton wrote: > > > On Sun, 9 Sep 2007 21:39:20 +0100 Christoph Hellwig > > > <[EMAIL PROTECTED]> wrote: > > > > Adrian knows this, yet he habitually sends zero-warning > > > export-removal patches and I habitually ignore them. I guess we > > > must both enjoy this or something. > > > > You might rename EXPORT_UNUSED_SYMBOL to EXPORT_UNUSED_SYMBOL_ADRIAN > > because AFAIK I am still the only person who was ever dumb enough to > > use it after you wanted me to do so... > > > > Everyone else is allowed to always add, remove and change exports > > as he likes, but I should go through this special process. > > > > It makes no sense (except for keeping me busy) to treat some patches > > I send special while changes made by other people that break the > > modules API are still allowed. > > > > Andrew, please define API rules, IOW rules for addition, removal and > > changing of exported code, that are valid for *everyone* or go to > > hell with your EXPORT_UNUSED_SYMBOL. > > > Adrian, > > as much as I personally disagree with Andrew's policy here (esp for > these symbols, they have been deprecated for years now), it's trivial > to just follow his requirements and get this over with. >... Andrew wants a deprecation period for these symbols where the few users are most likely doing something wrong when using them, but if someone e.g. changes the IRQ API in a way that breaks most external modules no deprecation period is required. If the kernel should get some module API stability processes like EXPORT_UNUSED_SYMBOL() deprecation periods have to be made mandatory for *all* API changes and removals. But forcing EXPORT_UNUSED_SYMBOL on me while allowing other people to do bigger API changes without deprecation periods is not a policy, it's a personal offence. > Greetings, > Arjan van de Ven cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sysfs change of input/event devices in 2.6.23rc breaks udev
On 9/8/07, Anssi Hannula <[EMAIL PROTECTED]> wrote: > There seem to be changes in sysfs input structure between 2.6.22 and > 2.6.23-rc5 which cause some breakage. > > With 2.6.22: > > > # LC_ALL=C ls -l /sys/class/input/input4 > > total 0 > > drwxr-xr-x 2 root root0 Sep 8 12:51 capabilities/ > > lrwxrwxrwx 1 root root0 Sep 8 19:48 device -> > > ../../../devices/platform/pcspkr/ > > drwxr-xr-x 2 root root0 Sep 8 12:51 event4/ > > drwxr-xr-x 2 root root0 Sep 8 12:51 id/ > > -r--r--r-- 1 root root 4096 Sep 8 19:48 modalias > > -r--r--r-- 1 root root 4096 Sep 8 19:48 name > > -r--r--r-- 1 root root 4096 Sep 8 19:48 phys > > lrwxrwxrwx 1 root root0 Sep 8 19:48 subsystem -> ../../../class/input/ > > --w--- 1 root root 4096 Sep 8 19:48 uevent > > -r--r--r-- 1 root root 4096 Sep 8 19:48 uniq > > > # ls -l /sys/class/input/event4 > > lrwxrwxrwx 1 root root 0 Sep 8 19:48 /sys/class/input/event4 -> > > ../../class/input/input4/event4/ > > # ls -l /sys/class/input/event4/ > > total 0 > > -r--r--r-- 1 root root 4096 Sep 8 19:58 dev > > lrwxrwxrwx 1 root root0 Sep 8 19:58 device -> > > ../../../../devices/platform/pcspkr/ > > lrwxrwxrwx 1 root root0 Sep 8 19:58 subsystem -> > > ../../../../class/input/ > > --w--- 1 root root 4096 Sep 8 19:58 uevent > > With 2.6.23-rc5: > > > # ls -l /sys/class/input/input5 > > total 0 > > drwxr-xr-x 2 root root0 Sep 8 19:47 capabilities/ > > lrwxrwxrwx 1 root root0 Sep 8 19:03 device -> > > ../../../devices/platform/pcspkr/ > > drwxr-xr-x 2 root root0 Sep 8 19:47 id/ > > lrwxrwxrwx 1 root root0 Sep 8 19:47 input:event5 -> > > ../../../class/input/event5/ > > -r--r--r-- 1 root root 4096 Sep 8 19:03 modalias > > -r--r--r-- 1 root root 4096 Sep 8 19:03 name > > -r--r--r-- 1 root root 4096 Sep 8 19:47 phys > > drwxr-xr-x 2 root root0 Sep 8 19:47 power/ > > lrwxrwxrwx 1 root root0 Sep 8 19:03 subsystem -> ../../../class/input/ > > -rw-r--r-- 1 root root 4096 Sep 8 19:03 uevent > > -r--r--r-- 1 root root 4096 Sep 8 19:47 uniq > > > # ls -l /sys/class/input/event5 > > total 0 > > -r--r--r-- 1 root root 4096 Sep 8 19:03 dev > > lrwxrwxrwx 1 root root0 Sep 8 19:03 device -> > > ../../../class/input/input5/ > > drwxr-xr-x 2 root root0 Sep 8 19:48 power/ > > lrwxrwxrwx 1 root root0 Sep 8 19:03 subsystem -> ../../../class/input/ > > -rw-r--r-- 1 root root 4096 Sep 8 19:03 uevent > > There are a few changes. > > There is no longer: > /sys/class/input/eventX => /sys/class/input/inputX/eventX > instead there is: > /sys/class/inputX/input:eventX => /sys/class/input/eventX > Notice the added "input:". I don't know if any software depends on this, > though. > > However, the change that broke id_path of udev is that > /sys/class/input/event5/device is now a symlink to the inputX directory > instead of being the same as the device symlink in inputX directory, > i.e. to ../../../devices/platform/pcspkr in this case. > > Udev id_path uses that directory to construct the ID_PATH variable. > Should the sysfs structure be reverted or should udev be adapted to > handle traversing /device symlink twice? I think the former, as there > should be considerably more time to adapt udev for coming changes in sysfs. Udev's path_id script is too dumb to follow the "device" link of stacked class devices in the CONFIG_SYSFS_DEPRECATED=y layout. Does this change fix it for you? http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff_plain;h=b1ac36ff5e3756cefc79967a26280056da31bf6f Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unexport sys_{open,read}
On Mon, 10 Sep 2007 00:22:03 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sun, Sep 09, 2007 at 02:59:40PM -0700, Andrew Morton wrote: > > On Sun, 9 Sep 2007 21:39:20 +0100 Christoph Hellwig > > <[EMAIL PROTECTED]> wrote: > > Adrian knows this, yet he habitually sends zero-warning > > export-removal patches and I habitually ignore them. I guess we > > must both enjoy this or something. > > You might rename EXPORT_UNUSED_SYMBOL to EXPORT_UNUSED_SYMBOL_ADRIAN > because AFAIK I am still the only person who was ever dumb enough to > use it after you wanted me to do so... > > Everyone else is allowed to always add, remove and change exports > as he likes, but I should go through this special process. > > It makes no sense (except for keeping me busy) to treat some patches > I send special while changes made by other people that break the > modules API are still allowed. > > Andrew, please define API rules, IOW rules for addition, removal and > changing of exported code, that are valid for *everyone* or go to > hell with your EXPORT_UNUSED_SYMBOL. Adrian, as much as I personally disagree with Andrew's policy here (esp for these symbols, they have been deprecated for years now), it's trivial to just follow his requirements and get this over with. As for who cares.. I do care still, unused exports make the kernel bigger for everyone, and for the most cases, encourage incorrect APIs to be used by driver writers (they act as a trap; the symbols generally are not used by anything in the kernel because they're the wrong API to use for drivers; having them exported wrongly suggests to new driver writers that they are good things to use). I plan to do another run of finding all unused exports and just marking the lot as _UNUSED exports. (that's not the same as removing them quite yet, but at least it's a good warning for driver writers that they should think twice about the API to see if it's the right one to use) Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unexport sys_{open,read}
On Sun, Sep 09, 2007 at 02:59:40PM -0700, Andrew Morton wrote:
> On Sun, 9 Sep 2007 21:39:20 +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Sep 09, 2007 at 10:25:28PM +0200, Adrian Bunk wrote:
> > > sys_{open,read} can finally be unexported.
> >
> > Andrew, can you please put this in? Having these exports for syscalls
> > around
> > hsa been a long-time annoyance that can finally be fixed now.
>
> Sure. But I think it is better to give people some warning when we're
> planning on breaking out-of-tree things. I do occasionally receive reports
> of "hey, the X driver which I get from Y doesn't work any more". Often
> it's open-source stuff, too. I see no point in irritating our users more than
> we need to.
>
> If we're changing an API or removing a function then there's nothing we can
> do, but in the case where we're simply deleting an export, it's exceedingly
> easy for us to EXPORT_UNUSED_SYMBOL (and __deprecated_for_modules?) for a
> few months.
>
> Adrian knows this, yet he habitually sends zero-warning export-removal
> patches and I habitually ignore them. I guess we must both enjoy this or
> something.
You might rename EXPORT_UNUSED_SYMBOL to EXPORT_UNUSED_SYMBOL_ADRIAN
because AFAIK I am still the only person who was ever dumb enough to
use it after you wanted me to do so...
Everyone else is allowed to always add, remove and change exports
as he likes, but I should go through this special process.
It makes no sense (except for keeping me busy) to treat some patches I
send special while changes made by other people that break the modules
API are still allowed.
Andrew, please define API rules, IOW rules for addition, removal and
changing of exported code, that are valid for *everyone* or go to hell
with your EXPORT_UNUSED_SYMBOL.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
On 9/9/07, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Dan Williams wrote:
>
> > This routine implies that there is a piece of code somewhere that
> > wants to select which channels it can use. A similar effect can be
> > achieved by registering a dma_client with the dmaengine interface
> > ('dma_async_client_register'). Then when the client code makes a call
> > to 'dma_async_client_chan_request' it receives a 'dma_event_callback'
> > for each channel in the system. It will also be asynchronously
> > notified of channels entering and leaving the system. The goal is to
> > share a common infrastructure for channel management.
>
> Are you familiar with the "flat device tree" used for PowerPC systems? The
> "piece of code somewhere" is the device tree subsystem that parses the device
> tree, which is compiled from the .dts files in arch/powerpc/boot/dts.
>
> The FDT is how PowerPC systems specify hardware configuration. In the case of
> 85xx, the FDT contains entries for each DMA device (typically 2), and the
> entries contain sub-entries for each DMA channel as well as the address of the
> register sets for each channel.
>
Ahh, ok then this code is replacing what would normally be handled by
the PCI bus enumeration code, or the platform device registrations for
iop-adma in arch/arm/mach-iop13xx. Sorry for the noise with this
comment.
> --
> Timur Tabi
> Linux Kernel Developer @ Freescale
> -
Thanks,
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unexport sys_{open,read}
On Sun, 9 Sep 2007 21:39:20 +0100 Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 09, 2007 at 10:25:28PM +0200, Adrian Bunk wrote:
> > sys_{open,read} can finally be unexported.
>
> Andrew, can you please put this in? Having these exports for syscalls around
> hsa been a long-time annoyance that can finally be fixed now.
Sure. But I think it is better to give people some warning when we're
planning on breaking out-of-tree things. I do occasionally receive reports
of "hey, the X driver which I get from Y doesn't work any more". Often
it's open-source stuff, too. I see no point in irritating our users more than
we need to.
If we're changing an API or removing a function then there's nothing we can
do, but in the case where we're simply deleting an export, it's exceedingly
easy for us to EXPORT_UNUSED_SYMBOL (and __deprecated_for_modules?) for a
few months.
Adrian knows this, yet he habitually sends zero-warning export-removal
patches and I habitually ignore them. I guess we must both enjoy this or
something.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: USB and MMC device problems on Kernel 2.6.22
Hi! [EMAIL PROTECTED] пишет: Sorry for not clear about the kernel version, let me try again: I have an ARM hardware board works fine with USB and MMC on kernel 2.6.11. Now, I've just upgraded it to kernel 2.6.22. The modules seem loaded fine, please see following list, but neither USB nor MMC could detect devices when a USB stick or SD card was plugged in (I enabled module debug, but nothing printed out, no device node created in /dev). It seems some processes were not running, but I can see usbd and mmcd were running at following list, or what is missing? K22 $ ps PID Uid VmSize Stat Command 1 root268 S init 2 rootSW< [kthreadd] 3 rootSWN [ksoftirqd/0] 4 rootSW< [events/0] 5 rootSW< [khelper] 31 rootSW< [kblockd/0] 32 rootSW< [ksuspend_usbd] 35 rootSW< [khubd] 37 rootSW< [kseriod] 49 rootSW [pdflush] 50 rootSW [pdflush] 51 rootSW< [kswapd0] 52 rootSW< [aio/0] 638 rootSW< [kapmd] 670 rootSW< [mtdblockd] 693 rootSW< [s3c2410-spi.1] 710 rootSW< [kbd_queue/0] 746 rootSW< [kmmcd] 775 root644 S /bin/inetd -f 776 root404 S /bin/sh 790 root324 R ps But does anything show up in syslog? I understand that the devfs is no longer supported by the kernel 2.6.22, but should the modules still be able to detect the devices? I manually created nodes on /dev tree such as /dev/mmc /dev/scsi before building and downloading to the target. Any clues please? Please also make sure you've got decent udev running and properly configured. K22 $ lsmod Module Size Used by nls_utf81696 0 nls_iso8859_1 3936 0 nls_cp437 5600 0 nls_ascii 3936 0 vfat 10336 0 fat48028 1 vfat mmc_block 8580 0 s3c2410mci 6560 0 mmc_core 25876 2 mmc_block,s3c2410mci Thank you. Jim In the hope it helps. Regards, Vladimir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regarding sysfs/kobject separation
Greg KH wrote: >> * much more compact and flexible interface based on sysfs_dirent instead >> of kobject. > > Why? What would use this kind of interface? Why would you want to > create things in sysfs without a kobject? Compulsory 1:1 mapping between kobject (thus driver model) and sysfs has been a constant headache for more complex subsystems (e.g. SAS). The organization of internal implementation is directly visible to userland making it part of API which shouldn't change. For simpler drivers, this is fine but for others it's too strict a restriction - internal representation may have to change as implementation matures and the desired userland view might differ from internal representation for multiple reasons. I'm not saying automatic representation is bad. It's good enough for 90+% of cases and I'm not intending to change that but we still need flexibility. Another example would be libata. libata currently is a SCSI driver and as such its sysfs representation is tied to SCSI. However, it's planned to become an independent block driver and will thus have a separate sysfs bus and device representation. The problem is that such fundamental structure change takes time but libata still needs sysfs interface now. Features which require sysfs interface are currently being delayed or stuffed into SCSI sysfs interface, both of which are far from the optimal situation. Breaking the tight coupling between the driver model and sysfs representation is a way to achieve that. sysfs becomes an independent facility which the driver model uses and, where needed, drivers can override how it's used. Breaking the tight coupling also makes the design and implementation of driver model and sysfs more modular and simpler. Less pressing but still important is that the current interface is needlessly cumbersome. IMHO, it can be made much more intuitive for driver writers. More on this later. >> * Backward compatibility is fully maintained. All kobject based >> interface is reimplemented in terms of the new interface. > > This is a source level for the sysfs functions compatibility, right? Or > is this the userspace view of sysfs? If the later one, why would that > have changed? Yeap, it's compatible both ways. Keeping those intact has been of course the top priority. :-) >> * Plugged creation and batched error handling. Sysfs directories can be >> 'plugged' on creation such that it can be made visible atomically after >> all its subtrees are constructed. Also, the user doesn't have to check >> for failure at every step. For example, the user can do the following. >> >> dir = sysfs_add_dir(parent, "my_dir", SYSFS_PLUGGED | 0777); >> sysfs_add_file(dir, ...); >> ... >> dir2 = sysfs_add_dir(dir, ...); >> sysfs_add_link(dir, "link-to-dir2", dir2); >> ... >> if (sysfs_check_batch_error(dir) == 0) >> sysfs_unplug(dir); >> else >> sysfs_remove(dir); >> >> And all the nodes under and including @dir will show up atomically if >> all operations succeeded or removed without ever bothering userland. > > Is this really needed? We work on kobjects and attributes today, and we > can easily add and remove groups of attributes just fine. > >> * Automatic symlink handling. Symlink names can be formatted with the >> name of its target. e.g. if the symlink name is specified as >> "link-%1:%0" and points to "devices/mybus0/mydev0", its name becomes >> "link-mybus0-mydev0" && the symlink will be automatically renamed when >> the target node or one of its ancestor is moved or renamed. The symlink >> is also plugged and removed together with its target. So, once created, >> the user doesn't have to care about the symlink. sysfs will take care >> of it. > > This might be nice, it would take code out of kobject_move(), right? And the above two are efforts to make life easier for driver writers so that the overhead of using sysfs is minimal. Both features don't interfere with simple usages and when a driver writer wants to use them, they don't have to do anything special. They're just there. >> * Move uevent support over to sysfs and bridging the current users. >> This makes sense because sysfs hierarchy is all that userland can see >> and sysfs users which don't use kobject also needs uevent support. > > What sysfs users without kobjects? Why? Hopefully, it's explained now. It's part of breaking the tight coupling between internal driver implementation and userland representation. >> * Convert device model (drivers/base/*) over to the new sysfs_dirent >> based interface and make device/driver <-> sysfs association flexible. >> Automatic sysfs association is a good thing. In most cases, it makes >> sense and makes drivers simpler but it also needs to be flexible such >> that drivers with special needs can override how the device and driver >> are represented to userland. I think such flexibility can be achieved >> without too much
Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
Dan Williams wrote:
This routine implies that there is a piece of code somewhere that
wants to select which channels it can use. A similar effect can be
achieved by registering a dma_client with the dmaengine interface
('dma_async_client_register'). Then when the client code makes a call
to 'dma_async_client_chan_request' it receives a 'dma_event_callback'
for each channel in the system. It will also be asynchronously
notified of channels entering and leaving the system. The goal is to
share a common infrastructure for channel management.
Are you familiar with the "flat device tree" used for PowerPC systems? The
"piece of code somewhere" is the device tree subsystem that parses the device
tree, which is compiled from the .dts files in arch/powerpc/boot/dts.
The FDT is how PowerPC systems specify hardware configuration. In the case of
85xx, the FDT contains entries for each DMA device (typically 2), and the
entries contain sub-entries for each DMA channel as well as the address of the
register sets for each channel.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata & scsi suggestion for make menuconfig
On Sun, 2007-09-09 at 23:22 +0200, Andi Kleen wrote: > > The current setup expresses the dependencies as they exist -- OPTIONAL > > extras, and that is a problem once a year or so, when someone builds > > Disk support over SCSI/SATA is hardly an "optional extra". It's more the 99+% > case. Using that argument, there's an equal case for always requiring SCSI to be built for every kernel, since very few people can boot a system without a disk. However, the 1% case is the embedded flash booting community plus a few others, so we allow SCSI to be optional for our 1% who don't want it. At base, the Kconfig system is designed to give the greatest flexibility with the fewest foot shooting opportunities. However, we do tend to err on the side of flexibility if there's a conflict between the two design goals. > > their own kernel but must learn this fact anew. > > When it costs 1 people half an hour to learn and correct this it > wasted 5000 hours of previous livetime. > > Besides there is no good reason to have ever learned this imho. The process of becoming an expert in the kernel build system naturally involves making mistakes and learning from them, so this is probably time reasonably well spent. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend] Fix a lock problem in generic phy code
I already sent this patch on August, 31. I never got an answer, so here it
is again.
Lock debugging finds a problem in phy.c and phy_device.c:
[ 3.42] =
[ 3.42] [ INFO: inconsistent lock state ]
[ 3.42] 2.6.23-rc3-mm1 #21
[ 3.42] -
[ 3.42] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
[ 3.42] swapper/1 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 3.42] (>lock){-+..}, at: [] phy_timer+0x1c/0x4c8
[ 3.42] {softirq-on-W} state was registered at:
[ 3.42] [] lock_acquire+0x94/0xac
[ 3.42] [] _spin_lock+0x40/0x50
[ 3.42] [] phy_probe+0x40/0x88
[ 3.42] [] phy_attach+0xc8/0xfc
[ 3.42] [] phy_connect+0x1c/0x58
[ 3.42] [] macb_probe+0x4fc/0x5bc
[ 3.42] [] platform_drv_probe+0x20/0x24
[ 3.42] [] driver_probe_device+0xb0/0x1bc
[ 3.42] [] __driver_attach+0xe4/0xe8
[ 3.42] [] bus_for_each_dev+0x54/0x80
[ 3.42] [] driver_attach+0x20/0x28
[ 3.42] [] bus_add_driver+0x84/0x1e0
[ 3.42] [] driver_register+0x54/0x90
[ 3.42] [] platform_driver_register+0x6c/0x88
[ 3.42] [] macb_init+0x14/0x1c
[ 3.42] [] kernel_init+0x9c/0x2b4
[ 3.42] [] do_exit+0x0/0x8e8
[ 3.42] irq event stamp: 115025
[ 3.42] hardirqs last enabled at (115025): []
_spin_unlock_irq+0x30/0x60
[ 3.42] hardirqs last disabled at (115024): []
_spin_lock_irq+0x28/0x60
[ 3.42] softirqs last enabled at (114999): []
__do_softirq+0xfc/0x12c
[ 3.42] softirqs last disabled at (115022): []
irq_exit+0x68/0x7c
[ 3.42]
[ 3.42] other info that might help us debug this:
[ 3.42] no locks held by swapper/1.
[ 3.42]
[ 3.42] stack backtrace:
[ 3.42] [] (dump_stack+0x0/0x14) from []
(print_usage_bug+0x120/0x150)
[ 3.42] [] (print_usage_bug+0x0/0x150) from []
(mark_lock+0x574/0x6bc)
[ 3.42] [] (mark_lock+0x0/0x6bc) from []
(__lock_acquire+0x4d0/0x1198)
[ 3.42] [] (__lock_acquire+0x0/0x1198) from []
(lock_acquire+0x94/0xac)
[ 3.42] [] (lock_acquire+0x0/0xac) from []
(_spin_lock+0x40/0x50)
[ 3.42] [] (_spin_lock+0x0/0x50) from []
(phy_timer+0x1c/0x4c8)
[ 3.42] r5:c098a800 r4:0104
[ 3.42] [] (phy_timer+0x0/0x4c8) from []
(run_timer_softirq+0x1a0/0x218)
[ 3.42] r7:c081ddd0 r6:c0331e80 r5:c098aa50 r4:0104
[ 3.42] [] (run_timer_softirq+0x0/0x218) from []
(__do_softirq+0x94/0x12c)
[ 3.42] [] (__do_softirq+0x0/0x12c) from []
(irq_exit+0x68/0x7c)
[ 3.42] [] (irq_exit+0x0/0x7c) from []
(__exception_text_start+0x60/0x74)
[ 3.42] r4:0001
[ 3.42] [] (__exception_text_start+0x0/0x74) from []
(__irq_svc+0x48/0x74)
[ 3.42] Exception stack(0xc081de70 to 0xc081deb8)
[ 3.42] de60: c030b2a8 c081a800
6013 c081c000
[ 3.42] de80: c032db40 c081dee0 c032d758 c081dece 0012 c030b398
0034 c081df2c
[ 3.42] dea0: c081deb8 c081deb8 c003d6f0 c003d6f8 6013
[ 3.42] r7:0003 r6:0001 r5:fefff000 r4:
[ 3.42] [] (vprintk+0x0/0x474) from []
(printk+0x28/0x30)
[ 3.42] [] (printk+0x0/0x30) from []
(sock_register+0x64/0x84)
[ 3.42] r3:0001 r2:0002 r1:0001 r0:c02e4c88
[ 3.42] [] (sock_register+0x0/0x84) from []
(af_unix_init+0x40/0x88)
[ 3.42] r5: r4:
[ 3.42] [] (af_unix_init+0x0/0x88) from []
(kernel_init+0x9c/0x2b4)
[ 3.42] r4:
[ 3.42] [] (kernel_init+0x0/0x2b4) from []
(do_exit+0x0/0x8e8)
The following patch fixes it. Tested on an AT91SAM9263-EK board, kernel
2.6.23-rc4 and -rc3-mm1.
Signed-off-by: Hans J. Koch <[EMAIL PROTECTED]>
---
Index: linux-2.6.23-rc/drivers/net/phy/phy_device.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy_device.c 2007-08-31
14:07:47.0 +0200
+++ linux-2.6.23-rc/drivers/net/phy/phy_device.c2007-08-31
14:08:22.0 +0200
@@ -644,7 +644,7 @@
if (!(phydrv->flags & PHY_HAS_INTERRUPT))
phydev->irq = PHY_POLL;
- spin_lock(>lock);
+ spin_lock_bh(>lock);
/* Start out supporting everything. Eventually,
* a controller will attach, and may modify one
@@ -658,7 +658,7 @@
if (phydev->drv->probe)
err = phydev->drv->probe(phydev);
- spin_unlock(>lock);
+ spin_unlock_bh(>lock);
return err;
Index: linux-2.6.23-rc/drivers/net/phy/phy.c
===
--- linux-2.6.23-rc.orig/drivers/net/phy/phy.c 2007-08-31 14:15:20.0
+0200
+++ linux-2.6.23-rc/drivers/net/phy/phy.c 2007-08-31 14:15:43.0
+0200
@@ -755,7 +755,7 @@
*/
void phy_start(struct phy_device *phydev)
{
-
patch usb-sisusbvga-fix-bug-and-build-warnings.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled
Subject: USB: sisusbvga: Fix bug and build warnings
to my gregkh-2.6 tree. Its filename is
usb-sisusbvga-fix-bug-and-build-warnings.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From [EMAIL PROTECTED] Sun Sep 2 12:54:28 2007
From: Satyam Sharma <[EMAIL PROTECTED]>
Date: Mon, 3 Sep 2007 01:37:31 +0530 (IST)
Subject: USB: sisusbvga: Fix bug and build warnings
To: Linux Kernel Mailing List
Cc: Thomas Winischhofer <[EMAIL PROTECTED]>, Greg Kroah-Hartman <[EMAIL
PROTECTED]>, [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
drivers/usb/misc/sisusbvga/sisusb.c: In function usb_sisusb_init:
drivers/usb/misc/sisusbvga/sisusb.c:3321: warning: unused variable sisusb
drivers/usb/misc/sisusbvga/sisusb.c:3320: warning: unused variable retval
are trivially solved by getting rid of the unused variables.
drivers/usb/misc/sisusbvga/sisusb.c: In function sisusb_open
drivers/usb/misc/sisusbvga/sisusb.c:2444: warning: sisusb is used uninitialized
in this function
is a genuine bug (which will cause oops). We cannot use "sisusb" in
error path for (!interface), because sisusb will itself be derived
from "interface" later.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/misc/sisusbvga/sisusb.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -2440,10 +2440,8 @@ sisusb_open(struct inode *inode, struct
struct usb_interface *interface;
int subminor = iminor(inode);
- if (!(interface = usb_find_interface(_driver, subminor))) {
- dev_err(>sisusb_dev->dev, "Failed to find interface\n");
+ if (!(interface = usb_find_interface(_driver, subminor)))
return -ENODEV;
- }
if (!(sisusb = usb_get_intfdata(interface)))
return -ENODEV;
Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are
driver/sysfs-remove-first-pass-at-shadow-directory-support.patch
driver/sysfs-introduce-sysfs_rename_mutex.patch
driver/sysfs-cosmetic-changes-in-sysfs_lookup.patch
driver/sysfs-make-sysfs_add-remove_one-call-link-unlink_sibling-implictly.patch
driver/sysfs-make-sysfs_add_one-automatically-check-for-duplicate-entry.patch
driver/sysfs-make-sysfs_addrm_finish-return-void.patch
driver/sysfs-simplify-sysfs_rename_dir.patch
driver/sysfs-kill-sysfs_flag_removed.patch
driver/sysfs-remove-s_dentry.patch
driver/sysfs-fix-i_mutex-locking-in-sysfs_get_dentry.patch
driver/sysfs-in-sysfs_lookup-don-t-open-code-sysfs_find_dirent.patch
driver/sysfs-make-sysfs_mount-static.patch
driver/sysfs-move-all-of-inode-initialization-into-sysfs_init_inode.patch
driver/sysfs-remove-sysfs_instantiate.patch
driver/sysfs-rewrite-rename-in-terms-of-sysfs-dirents.patch
driver/sysfs-rewrite-sysfs_drop_dentry.patch
driver/sysfs-rewrite-sysfs_move_dir-in-terms-of-sysfs-dirents.patch
driver/sysfs-simplify-readdir.patch
driver/sysfs-simply-sysfs_get_dentry.patch
driver/sysfs-use-kill_anon_super.patch
usb/usb-drivers-usb-serial-bus.c-fix-incompatible-pointer-type-warning.patch
usb/usb-sisusbvga-fix-bug-and-build-warnings.patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sata & scsi suggestion for make menuconfig
> The current setup expresses the dependencies as they exist -- OPTIONAL > extras, and that is a problem once a year or so, when someone builds Disk support over SCSI/SATA is hardly an "optional extra". It's more the 99+% case. > their own kernel but must learn this fact anew. When it costs 1 people half an hour to learn and correct this it wasted 5000 hours of previous livetime. Besides there is no good reason to have ever learned this imho. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata & scsi suggestion for make menuconfig
Andi Kleen wrote: I can see where you're coming from, but logically, this is wrong. There's a huge slew of enterprise machines that only have DVD on SATA. ... and enterprise systems don't really care about a few KB more of code. In fact you definitely want to have SATA compiled in in case you need to recover the machine later when the SAN is down. On the other hand, all of these machines will have SCSI disk devices on various other transports, so no harm is done, it's just an inelegant solution. Do you know of a better one? Let's step back a moment and consider the actual scale and impact of the problem at hand. The vast majority of users are consumers of pre-compiled kernels, built by People With Clue(tm), who figured this stuff out as soon as it was introduced. The current setup expresses the dependencies as they exist -- OPTIONAL extras, and that is a problem once a year or so, when someone builds their own kernel but must learn this fact anew. There is simply no compelling need at all to change things from the current setup. Our Kconfig system is for people who already know the kernel, not Aunt Tillie. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 4/5] Hibernation: Correct definitions of some ioctls (rev. 2)
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Three ioctl numbers belonging to the hibernation userland interface,
SNAPSHOT_ATOMIC_SNAPSHOT, SNAPSHOT_SET_IMAGE_SIZE, SNAPSHOT_AVAIL_SWAP,
SNAPSHOT_GET_SWAP_PAGE, are defined in a wrong way (eg. not portable). Provide
new ioctl numbers for these ioctls and mark the existing ones as deprecated.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
Documentation/power/userland-swsusp.txt | 26 +-
kernel/power/power.h| 10 +-
kernel/power/user.c | 18 --
3 files changed, 34 insertions(+), 20 deletions(-)
Index: linux-2.6.23-rc5/kernel/power/power.h
===
--- linux-2.6.23-rc5.orig/kernel/power/power.h 2007-09-09 22:30:36.0
+0200
+++ linux-2.6.23-rc5/kernel/power/power.h 2007-09-09 22:36:10.0
+0200
@@ -149,12 +149,8 @@ struct resume_swap_area {
#define SNAPSHOT_IOC_MAGIC '3'
#define SNAPSHOT_FREEZE_IO(SNAPSHOT_IOC_MAGIC, 1)
#define SNAPSHOT_UNFREEZE _IO(SNAPSHOT_IOC_MAGIC, 2)
-#define SNAPSHOT_ATOMIC_SNAPSHOT _IOW(SNAPSHOT_IOC_MAGIC, 3, void *)
#define SNAPSHOT_ATOMIC_RESTORE_IO(SNAPSHOT_IOC_MAGIC, 4)
#define SNAPSHOT_FREE _IO(SNAPSHOT_IOC_MAGIC, 5)
-#define SNAPSHOT_SET_IMAGE_SIZE_IOW(SNAPSHOT_IOC_MAGIC, 6,
unsigned long)
-#define SNAPSHOT_AVAIL_SWAP_IOR(SNAPSHOT_IOC_MAGIC, 7, void *)
-#define SNAPSHOT_GET_SWAP_PAGE _IOR(SNAPSHOT_IOC_MAGIC, 8, void *)
#define SNAPSHOT_FREE_SWAP_PAGES _IO(SNAPSHOT_IOC_MAGIC, 9)
#define SNAPSHOT_S2RAM _IO(SNAPSHOT_IOC_MAGIC, 11)
#define SNAPSHOT_SET_SWAP_AREA _IOW(SNAPSHOT_IOC_MAGIC, 13, \
@@ -162,7 +158,11 @@ struct resume_swap_area {
#define SNAPSHOT_GET_IMAGE_SIZE_IOR(SNAPSHOT_IOC_MAGIC, 14,
loff_t)
#define SNAPSHOT_PLATFORM_SUPPORT _IO(SNAPSHOT_IOC_MAGIC, 15)
#define SNAPSHOT_POWER_OFF _IO(SNAPSHOT_IOC_MAGIC, 16)
-#define SNAPSHOT_IOC_MAXNR 16
+#define SNAPSHOT_CREATE_IMAGE _IOW(SNAPSHOT_IOC_MAGIC, 17, int)
+#define SNAPSHOT_PREF_IMAGE_SIZE _IO(SNAPSHOT_IOC_MAGIC, 18)
+#define SNAPSHOT_AVAIL_SWAP_SIZE _IOR(SNAPSHOT_IOC_MAGIC, 19, loff_t)
+#define SNAPSHOT_ALLOC_SWAP_PAGE _IOR(SNAPSHOT_IOC_MAGIC, 20, loff_t)
+#define SNAPSHOT_IOC_MAXNR 20
/* If unset, the snapshot device cannot be open. */
extern atomic_t snapshot_device_available;
Index: linux-2.6.23-rc5/kernel/power/user.c
===
--- linux-2.6.23-rc5.orig/kernel/power/user.c 2007-09-09 22:30:36.0
+0200
+++ linux-2.6.23-rc5/kernel/power/user.c2007-09-09 22:37:11.0
+0200
@@ -40,6 +40,16 @@
#define PMOPS_ENTER2
#define PMOPS_FINISH 3
+/*
+ * NOTE: The following ioctl definitions are wrong and have been replaced with
+ * correct ones. They are only preserved here for compatibility with existing
+ * userland utilities and will be removed in the future.
+ */
+#define SNAPSHOT_ATOMIC_SNAPSHOT _IOW(SNAPSHOT_IOC_MAGIC, 3, void *)
+#define SNAPSHOT_SET_IMAGE_SIZE_IOW(SNAPSHOT_IOC_MAGIC, 6,
unsigned long)
+#define SNAPSHOT_AVAIL_SWAP_IOR(SNAPSHOT_IOC_MAGIC, 7, void *)
+#define SNAPSHOT_GET_SWAP_PAGE _IOR(SNAPSHOT_IOC_MAGIC, 8, void *)
+
#define SNAPSHOT_MINOR 231
@@ -191,6 +201,7 @@ static int snapshot_ioctl(struct inode *
data->frozen = 0;
break;
+ case SNAPSHOT_CREATE_IMAGE:
case SNAPSHOT_ATOMIC_SNAPSHOT:
if (data->mode != O_RDONLY || !data->frozen || data->ready) {
error = -EPERM;
@@ -198,7 +209,7 @@ static int snapshot_ioctl(struct inode *
}
error = hibernation_snapshot(data->platform_support);
if (!error)
- error = put_user(in_suspend, (unsigned int __user
*)arg);
+ error = put_user(in_suspend, (int __user *)arg);
if (!error)
data->ready = 1;
break;
@@ -219,6 +230,7 @@ static int snapshot_ioctl(struct inode *
data->ready = 0;
break;
+ case SNAPSHOT_PREF_IMAGE_SIZE:
case SNAPSHOT_SET_IMAGE_SIZE:
image_size = arg;
break;
@@ -233,12 +245,14 @@ static int snapshot_ioctl(struct inode *
error = put_user(size, (loff_t __user *)arg);
break;
+ case SNAPSHOT_AVAIL_SWAP_SIZE:
case SNAPSHOT_AVAIL_SWAP:
size = count_swap_pages(data->swap, 1);
size <<= PAGE_SHIFT;
error = put_user(size, (loff_t __user *)arg);
break;
+ case SNAPSHOT_ALLOC_SWAP_PAGE:
case SNAPSHOT_GET_SWAP_PAGE:
if
Re: [PATCH] drivers/firmware: const-ify DMI API and internals
On Sun, Sep 09, 2007 at 10:24:42PM +0200, Sam Ravnborg wrote: > > > > > > I was just going to push it myself, but have no strong feelings on the > > > matter. > > > > Ok, you can push it, that's fine with me. Feel free to add my: > > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > > > if you want. > That should be "Acked-by:" since the patch does not pass via you but you > acknowledge it is OK by your Ack. Well, as I am the maintainer for that subsystem, and I did review the patch and it looks good, that is a bit more than just an "ack" :) But whatever you want, I'm not going to get technical here with "reviewed-by" and such right now... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 3/5] Hibernation: Mark SNAPSHOT_SET_SWAP_FILE ioctl as deprecated (rev. 2)
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Mark the SNAPSHOT_SET_SWAP_FILE ioctl belonging to the hibernation userland
interface as deprecated.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
Documentation/power/userland-swsusp.txt | 14 ++
kernel/power/power.h|1 -
kernel/power/user.c |9 +
3 files changed, 7 insertions(+), 17 deletions(-)
Index: linux-2.6.23-rc5/kernel/power/power.h
===
--- linux-2.6.23-rc5.orig/kernel/power/power.h 2007-09-09 22:30:21.0
+0200
+++ linux-2.6.23-rc5/kernel/power/power.h 2007-09-09 22:30:36.0
+0200
@@ -156,7 +156,6 @@ struct resume_swap_area {
#define SNAPSHOT_AVAIL_SWAP_IOR(SNAPSHOT_IOC_MAGIC, 7, void *)
#define SNAPSHOT_GET_SWAP_PAGE _IOR(SNAPSHOT_IOC_MAGIC, 8, void *)
#define SNAPSHOT_FREE_SWAP_PAGES _IO(SNAPSHOT_IOC_MAGIC, 9)
-#define SNAPSHOT_SET_SWAP_FILE _IOW(SNAPSHOT_IOC_MAGIC, 10, unsigned
int)
#define SNAPSHOT_S2RAM _IO(SNAPSHOT_IOC_MAGIC, 11)
#define SNAPSHOT_SET_SWAP_AREA _IOW(SNAPSHOT_IOC_MAGIC, 13, \
struct resume_swap_area)
Index: linux-2.6.23-rc5/kernel/power/user.c
===
--- linux-2.6.23-rc5.orig/kernel/power/user.c 2007-09-09 22:30:21.0
+0200
+++ linux-2.6.23-rc5/kernel/power/user.c2007-09-09 22:30:36.0
+0200
@@ -29,10 +29,11 @@
#include "power.h"
/*
- * NOTE: The SNAPSHOT_PMOPS ioctl is obsolete and will be removed in the
- * future. It is only preserved here for compatibility with existing userland
- * utilities.
+ * NOTE: The SNAPSHOT_SET_SWAP_FILE and SNAPSHOT_PMOPS ioctls are obsolete and
+ * will be removed in the future. They are only preserved here for
+ * compatibility with existing userland utilities.
*/
+#define SNAPSHOT_SET_SWAP_FILE _IOW(SNAPSHOT_IOC_MAGIC, 10, unsigned int)
#define SNAPSHOT_PMOPS _IOW(SNAPSHOT_IOC_MAGIC, 12, unsigned int)
#define PMOPS_PREPARE 1
@@ -260,7 +261,7 @@ static int snapshot_ioctl(struct inode *
free_all_swap_pages(data->swap);
break;
- case SNAPSHOT_SET_SWAP_FILE:
+ case SNAPSHOT_SET_SWAP_FILE: /* This ioctl is deprecated */
if (!swsusp_swap_in_use()) {
/*
* User space encodes device types as two-byte values,
Index: linux-2.6.23-rc5/Documentation/power/userland-swsusp.txt
===
--- linux-2.6.23-rc5.orig/Documentation/power/userland-swsusp.txt
2007-09-09 22:30:21.0 +0200
+++ linux-2.6.23-rc5/Documentation/power/userland-swsusp.txt2007-09-09
22:32:45.0 +0200
@@ -67,23 +67,13 @@ SNAPSHOT_GET_SWAP_PAGE - allocate a swap
SNAPSHOT_FREE_SWAP_PAGES - free all swap pages allocated with
SNAPSHOT_GET_SWAP_PAGE
-SNAPSHOT_SET_SWAP_FILE - set the resume partition (the last ioctl() argument
- should specify the device's major and minor numbers in the old
- two-byte format, as returned by the stat() function in the .st_rdev
- member of the stat structure)
-
SNAPSHOT_SET_SWAP_AREA - set the resume partition and the offset (in
units) from the beginning of the partition at which the swap header is
located (the last ioctl() argument should point to a struct
resume_swap_area, as defined in kernel/power/power.h, containing the
- resume device specification, as for the SNAPSHOT_SET_SWAP_FILE ioctl(),
- and the offset); for swap partitions the offset is always 0, but it is
- different to zero for swap files (please see
+ resume device specification and the offset); for swap partitions the
+ offset is always 0, but it is different from zero for swap files (see
Documentation/swsusp-and-swap-files.txt for details).
- The SNAPSHOT_SET_SWAP_AREA ioctl() is considered as a replacement for
- SNAPSHOT_SET_SWAP_FILE which is regarded as obsolete. It is
- recommended to always use this call, because the code to set the resume
- partition may be removed from future kernels
SNAPSHOT_PLATFORM_SUPPORT - enable/disable the hibernation platform support,
depending on the argument value (enable, if the argument is nonzero)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 5/5] Hibernation: Introduce exportable suspend ioctls header (rev. 2)
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Move the definitions of hibernation ioctls to a separate header file in
include/linux, which can be exported to the user space.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
Documentation/power/userland-swsusp.txt | 10 +-
include/linux/Kbuild|1 +
include/linux/suspend_ioctls.h | 32
kernel/power/power.h| 29 +
4 files changed, 39 insertions(+), 33 deletions(-)
Index: linux-2.6.23-rc5/include/linux/suspend_ioctls.h
===
--- /dev/null
+++ linux-2.6.23-rc5/include/linux/suspend_ioctls.h
@@ -0,0 +1,32 @@
+#ifndef _LINUX_SUSPEND_IOCTLS_H
+#define _LINUX_SUSPEND_IOCTLS_H
+
+/*
+ * This structure is used to pass the values needed for the identification
+ * of the resume swap area from a user space to the kernel via the
+ * SNAPSHOT_SET_SWAP_AREA ioctl
+ */
+struct resume_swap_area {
+ loff_t offset;
+ u_int32_t dev;
+} __attribute__((packed));
+
+#define SNAPSHOT_IOC_MAGIC '3'
+#define SNAPSHOT_FREEZE_IO(SNAPSHOT_IOC_MAGIC, 1)
+#define SNAPSHOT_UNFREEZE _IO(SNAPSHOT_IOC_MAGIC, 2)
+#define SNAPSHOT_ATOMIC_RESTORE_IO(SNAPSHOT_IOC_MAGIC, 4)
+#define SNAPSHOT_FREE _IO(SNAPSHOT_IOC_MAGIC, 5)
+#define SNAPSHOT_FREE_SWAP_PAGES _IO(SNAPSHOT_IOC_MAGIC, 9)
+#define SNAPSHOT_S2RAM _IO(SNAPSHOT_IOC_MAGIC, 11)
+#define SNAPSHOT_SET_SWAP_AREA _IOW(SNAPSHOT_IOC_MAGIC, 13, \
+ struct resume_swap_area)
+#define SNAPSHOT_GET_IMAGE_SIZE_IOR(SNAPSHOT_IOC_MAGIC, 14,
loff_t)
+#define SNAPSHOT_PLATFORM_SUPPORT _IO(SNAPSHOT_IOC_MAGIC, 15)
+#define SNAPSHOT_POWER_OFF _IO(SNAPSHOT_IOC_MAGIC, 16)
+#define SNAPSHOT_CREATE_IMAGE _IOW(SNAPSHOT_IOC_MAGIC, 17, int)
+#define SNAPSHOT_PREF_IMAGE_SIZE _IO(SNAPSHOT_IOC_MAGIC, 18)
+#define SNAPSHOT_AVAIL_SWAP_SIZE _IOR(SNAPSHOT_IOC_MAGIC, 19, loff_t)
+#define SNAPSHOT_ALLOC_SWAP_PAGE _IOR(SNAPSHOT_IOC_MAGIC, 20, loff_t)
+#define SNAPSHOT_IOC_MAXNR 20
+
+#endif /* _LINUX_SUSPEND_IOCTLS_H */
Index: linux-2.6.23-rc5/kernel/power/power.h
===
--- linux-2.6.23-rc5.orig/kernel/power/power.h
+++ linux-2.6.23-rc5/kernel/power/power.h
@@ -1,4 +1,5 @@
#include
+#include
#include
struct swsusp_info {
@@ -136,34 +137,6 @@ extern int snapshot_write_next(struct sn
extern void snapshot_write_finalize(struct snapshot_handle *handle);
extern int snapshot_image_loaded(struct snapshot_handle *handle);
-/*
- * This structure is used to pass the values needed for the identification
- * of the resume swap area from a user space to the kernel via the
- * SNAPSHOT_SET_SWAP_AREA ioctl
- */
-struct resume_swap_area {
- loff_t offset;
- u_int32_t dev;
-} __attribute__((packed));
-
-#define SNAPSHOT_IOC_MAGIC '3'
-#define SNAPSHOT_FREEZE_IO(SNAPSHOT_IOC_MAGIC, 1)
-#define SNAPSHOT_UNFREEZE _IO(SNAPSHOT_IOC_MAGIC, 2)
-#define SNAPSHOT_ATOMIC_RESTORE_IO(SNAPSHOT_IOC_MAGIC, 4)
-#define SNAPSHOT_FREE _IO(SNAPSHOT_IOC_MAGIC, 5)
-#define SNAPSHOT_FREE_SWAP_PAGES _IO(SNAPSHOT_IOC_MAGIC, 9)
-#define SNAPSHOT_S2RAM _IO(SNAPSHOT_IOC_MAGIC, 11)
-#define SNAPSHOT_SET_SWAP_AREA _IOW(SNAPSHOT_IOC_MAGIC, 13, \
- struct resume_swap_area)
-#define SNAPSHOT_GET_IMAGE_SIZE_IOR(SNAPSHOT_IOC_MAGIC, 14,
loff_t)
-#define SNAPSHOT_PLATFORM_SUPPORT _IO(SNAPSHOT_IOC_MAGIC, 15)
-#define SNAPSHOT_POWER_OFF _IO(SNAPSHOT_IOC_MAGIC, 16)
-#define SNAPSHOT_CREATE_IMAGE _IOW(SNAPSHOT_IOC_MAGIC, 17, int)
-#define SNAPSHOT_PREF_IMAGE_SIZE _IO(SNAPSHOT_IOC_MAGIC, 18)
-#define SNAPSHOT_AVAIL_SWAP_SIZE _IOR(SNAPSHOT_IOC_MAGIC, 19, loff_t)
-#define SNAPSHOT_ALLOC_SWAP_PAGE _IOR(SNAPSHOT_IOC_MAGIC, 20, loff_t)
-#define SNAPSHOT_IOC_MAXNR 20
-
/* If unset, the snapshot device cannot be open. */
extern atomic_t snapshot_device_available;
Index: linux-2.6.23-rc5/Documentation/power/userland-swsusp.txt
===
--- linux-2.6.23-rc5.orig/Documentation/power/userland-swsusp.txt
+++ linux-2.6.23-rc5/Documentation/power/userland-swsusp.txt
@@ -14,7 +14,7 @@ are going to develop your own suspend/re
The interface consists of a character device providing the open(),
release(), read(), and write() operations as well as several ioctl()
-commands defined in kernel/power/power.h. The major and minor
+commands defined in include/linux/suspend_ioctls.h . The major and minor
numbers of the device are, respectively, 10 and 231, and
[PATCH -mm 2/5] Hibernation: Rework platform support ioctls (rev. 2)
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Modify the hibernation userland interface by adding two new ioctls to it,
SNAPSHOT_PLATFORM_SUPPORT and SNAPSHOT_POWER_OFF, that can be used,
respectively, to switch the hibernation platform support on/off and to make the
kernel transition the system to the hibernation state (eg. ACPI S4) using the
platform (eg. ACPI) driver.
These ioctls are intended to replace the misdesigned SNAPSHOT_PMOPS ioctl,
which from now is regarded as obsolete and will be removed in the future.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
Documentation/power/userland-swsusp.txt | 24 ---
kernel/power/power.h|9 ++-
kernel/power/user.c | 39 +++-
3 files changed, 38 insertions(+), 34 deletions(-)
Index: linux-2.6.23-rc5/kernel/power/power.h
===
--- linux-2.6.23-rc5.orig/kernel/power/power.h 2007-09-02 12:04:26.0
+0200
+++ linux-2.6.23-rc5/kernel/power/power.h 2007-09-02 12:04:42.0
+0200
@@ -158,15 +158,12 @@ struct resume_swap_area {
#define SNAPSHOT_FREE_SWAP_PAGES _IO(SNAPSHOT_IOC_MAGIC, 9)
#define SNAPSHOT_SET_SWAP_FILE _IOW(SNAPSHOT_IOC_MAGIC, 10, unsigned
int)
#define SNAPSHOT_S2RAM _IO(SNAPSHOT_IOC_MAGIC, 11)
-#define SNAPSHOT_PMOPS _IOW(SNAPSHOT_IOC_MAGIC, 12, unsigned
int)
#define SNAPSHOT_SET_SWAP_AREA _IOW(SNAPSHOT_IOC_MAGIC, 13, \
struct resume_swap_area)
#define SNAPSHOT_GET_IMAGE_SIZE_IOR(SNAPSHOT_IOC_MAGIC, 14,
loff_t)
-#define SNAPSHOT_IOC_MAXNR 14
-
-#define PMOPS_PREPARE 1
-#define PMOPS_ENTER2
-#define PMOPS_FINISH 3
+#define SNAPSHOT_PLATFORM_SUPPORT _IO(SNAPSHOT_IOC_MAGIC, 15)
+#define SNAPSHOT_POWER_OFF _IO(SNAPSHOT_IOC_MAGIC, 16)
+#define SNAPSHOT_IOC_MAXNR 16
/* If unset, the snapshot device cannot be open. */
extern atomic_t snapshot_device_available;
Index: linux-2.6.23-rc5/kernel/power/user.c
===
--- linux-2.6.23-rc5.orig/kernel/power/user.c 2007-09-02 12:04:26.0
+0200
+++ linux-2.6.23-rc5/kernel/power/user.c2007-09-02 12:04:42.0
+0200
@@ -28,6 +28,18 @@
#include "power.h"
+/*
+ * NOTE: The SNAPSHOT_PMOPS ioctl is obsolete and will be removed in the
+ * future. It is only preserved here for compatibility with existing userland
+ * utilities.
+ */
+#define SNAPSHOT_PMOPS _IOW(SNAPSHOT_IOC_MAGIC, 12, unsigned int)
+
+#define PMOPS_PREPARE 1
+#define PMOPS_ENTER2
+#define PMOPS_FINISH 3
+
+
#define SNAPSHOT_MINOR 231
static struct snapshot_data {
@@ -36,7 +48,7 @@ static struct snapshot_data {
int mode;
char frozen;
char ready;
- char platform_suspend;
+ char platform_support;
} snapshot_state;
atomic_t snapshot_device_available = ATOMIC_INIT(1);
@@ -70,7 +82,7 @@ static int snapshot_open(struct inode *i
}
data->frozen = 0;
data->ready = 0;
- data->platform_suspend = 0;
+ data->platform_support = 0;
return 0;
}
@@ -183,7 +195,7 @@ static int snapshot_ioctl(struct inode *
error = -EPERM;
break;
}
- error = hibernation_snapshot(data->platform_suspend);
+ error = hibernation_snapshot(data->platform_support);
if (!error)
error = put_user(in_suspend, (unsigned int __user
*)arg);
if (!error)
@@ -197,7 +209,7 @@ static int snapshot_ioctl(struct inode *
error = -EPERM;
break;
}
- error = hibernation_restore(data->platform_suspend);
+ error = hibernation_restore(data->platform_support);
break;
case SNAPSHOT_FREE:
@@ -285,26 +297,33 @@ static int snapshot_ioctl(struct inode *
mutex_unlock(_mutex);
break;
- case SNAPSHOT_PMOPS:
+ case SNAPSHOT_PLATFORM_SUPPORT:
+ data->platform_support = !!arg;
+ break;
+
+ case SNAPSHOT_POWER_OFF:
+ if (data->platform_support)
+ error = hibernation_platform_enter();
+ break;
+
+ case SNAPSHOT_PMOPS: /* This ioctl is deprecated */
error = -EINVAL;
switch (arg) {
case PMOPS_PREPARE:
- data->platform_suspend = 1;
+ data->platform_support = 1;
error = 0;
break;
case PMOPS_ENTER:
- if (data->platform_suspend)
+ if (data->platform_support)
[PATCH -mm 0/5] Hibernation: Clean up userland interface (rev. 2)
Hi, This series of patches is intended to eliminate some design problems with the hibernation userland interface. It contains the following changes: * allow the user space utilities to get the size of the image via ioctl * introduce ioctls to be used instead of SNAPSHOT_PMOPS * mark the SNAPSHOT_SET_SWAP_FILE ioctl as deprecated * introduce new ioctl definitions to replace the wrongly defined ones * move the definitions of hibernation ioctls to a separate header file located in include/linux/ and export them to the user space The details are in the changelogs. Comments welcome. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 1/5] Hibernation: Introduce SNAPSHOT_GET_IMAGE_SIZE ioctl
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Add a new ioctl, SNAPSHOT_GET_IMAGE_SIZE, returning the size of the (just
created) hibernation image, to the hibernation userland interface.
This ioctl is necessary so that the userland utilities using the interface need
not access the hibernation image header, owned by the kernel, in order to obtain
the size of the image.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
Documentation/power/userland-swsusp.txt | 12 +---
kernel/power/power.h|4 +++-
kernel/power/snapshot.c |7 ++-
kernel/power/user.c | 18 ++
4 files changed, 28 insertions(+), 13 deletions(-)
Index: linux-2.6.23-rc5/kernel/power/power.h
===
--- linux-2.6.23-rc5.orig/kernel/power/power.h 2007-09-02 12:00:37.0
+0200
+++ linux-2.6.23-rc5/kernel/power/power.h 2007-09-02 12:04:26.0
+0200
@@ -130,6 +130,7 @@ struct snapshot_handle {
#define data_of(handle)((handle).buffer + (handle).buf_offset)
extern unsigned int snapshot_additional_pages(struct zone *zone);
+extern unsigned long snapshot_get_image_size(void);
extern int snapshot_read_next(struct snapshot_handle *handle, size_t count);
extern int snapshot_write_next(struct snapshot_handle *handle, size_t count);
extern void snapshot_write_finalize(struct snapshot_handle *handle);
@@ -160,7 +161,8 @@ struct resume_swap_area {
#define SNAPSHOT_PMOPS _IOW(SNAPSHOT_IOC_MAGIC, 12, unsigned
int)
#define SNAPSHOT_SET_SWAP_AREA _IOW(SNAPSHOT_IOC_MAGIC, 13, \
struct resume_swap_area)
-#define SNAPSHOT_IOC_MAXNR 13
+#define SNAPSHOT_GET_IMAGE_SIZE_IOR(SNAPSHOT_IOC_MAGIC, 14,
loff_t)
+#define SNAPSHOT_IOC_MAXNR 14
#define PMOPS_PREPARE 1
#define PMOPS_ENTER2
Index: linux-2.6.23-rc5/kernel/power/user.c
===
--- linux-2.6.23-rc5.orig/kernel/power/user.c 2007-09-02 00:39:24.0
+0200
+++ linux-2.6.23-rc5/kernel/power/user.c2007-09-02 12:04:26.0
+0200
@@ -133,7 +133,7 @@ static int snapshot_ioctl(struct inode *
{
int error = 0;
struct snapshot_data *data;
- loff_t avail;
+ loff_t size;
sector_t offset;
if (_IOC_TYPE(cmd) != SNAPSHOT_IOC_MAGIC)
@@ -210,10 +210,20 @@ static int snapshot_ioctl(struct inode *
image_size = arg;
break;
+ case SNAPSHOT_GET_IMAGE_SIZE:
+ if (!data->ready) {
+ error = -ENODATA;
+ break;
+ }
+ size = snapshot_get_image_size();
+ size <<= PAGE_SHIFT;
+ error = put_user(size, (loff_t __user *)arg);
+ break;
+
case SNAPSHOT_AVAIL_SWAP:
- avail = count_swap_pages(data->swap, 1);
- avail <<= PAGE_SHIFT;
- error = put_user(avail, (loff_t __user *)arg);
+ size = count_swap_pages(data->swap, 1);
+ size <<= PAGE_SHIFT;
+ error = put_user(size, (loff_t __user *)arg);
break;
case SNAPSHOT_GET_SWAP_PAGE:
Index: linux-2.6.23-rc5/kernel/power/snapshot.c
===
--- linux-2.6.23-rc5.orig/kernel/power/snapshot.c 2007-09-02
12:00:37.0 +0200
+++ linux-2.6.23-rc5/kernel/power/snapshot.c2007-09-02 12:04:26.0
+0200
@@ -1263,12 +1263,17 @@ static char *check_image_kernel(struct s
}
#endif /* CONFIG_ARCH_HIBERNATION_HEADER */
+unsigned long snapshot_get_image_size(void)
+{
+ return nr_copy_pages + nr_meta_pages + 1;
+}
+
static int init_header(struct swsusp_info *info)
{
memset(info, 0, sizeof(struct swsusp_info));
info->num_physpages = num_physpages;
info->image_pages = nr_copy_pages;
- info->pages = nr_copy_pages + nr_meta_pages + 1;
+ info->pages = snapshot_get_image_size();
info->size = info->pages;
info->size <<= PAGE_SHIFT;
return init_header_complete(info);
Index: linux-2.6.23-rc5/Documentation/power/userland-swsusp.txt
===
--- linux-2.6.23-rc5.orig/Documentation/power/userland-swsusp.txt
2007-08-29 23:51:50.0 +0200
+++ linux-2.6.23-rc5/Documentation/power/userland-swsusp.txt2007-09-02
12:04:26.0 +0200
@@ -54,6 +54,8 @@ SNAPSHOT_SET_IMAGE_SIZE - set the prefer
this number, but if it turns out to be impossible, the kernel will
create the smallest image possible)
+SNAPSHOT_GET_IMAGE_SIZE - return the actual size of the hibernation image
+
SNAPSHOT_AVAIL_SWAP - return the amount of available swap in bytes (the last
Re: [discuss] [patch 3/5] Use extended crashkernel command line on x86_64
Bernhard Walle <[EMAIL PROTECTED]> writes: > * Yinghai Lu <[EMAIL PROTECTED]> [2007-09-09 19:27]: >> > >> > +#ifdef CONFIG_KEXEC >> ... >> >> CONFIG_KEXEC or CONFIG_CRASH_DUMP? > > Good question. The crashkernel parameter was CONFIG_KEXEC before, and > I also wondered why, but I didn't change this because maybe there's > some reason I don't know. > > Vivek, do you know why this was CONFIG_KEXEC? Probably because you use it in the primary kernel you use it. The option reserves an area of memory for the kernel we switch to on panic or another kernel crash. Generally CONFIG_CRASH_DUMP seems to be about the options needed to read out the crash dump after the fact. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG]: circular locking depedency in videobuf code
Hi, I found a bug (circular lock dependency) in generic videobuf code: Suppose app has two threads, and one calls munmap() on a video buffer , and second calls VIDIOC_QBUF ioctl. (The actual app that does that is kdetv on exit) thread1: takes current->mm->mmap_sem, then takes q->lock thread2: takes q->lock then takes current->mm->mmap_sem Explanation: thread 1: munmap takes current->mm->mmap_sem,and calls videobuf_vm_close which tries to take q->lock thread2: videobuf_qbuf takes q->lock and calls q->ops->buf_prepare(q,buf,field), that is driver specific, but most(if not all) implementations call videobuf_iolock, that calls videobuf_dma_init_user, and that function takes current->mm->mmap_sem. Since buffer queue is the same, as well as current->mm, a deadlock can occur. It happens almost always on my system Since mm->mmap_sem for kdetv is down forever, commands like ps/top hang, and reboot doesn't work for same reason. I have FlyVideo2000 card (saa7130HL based), so saa7134 driver is used. It is a bit difficult for me to fix that bug, so can you help me? Maybe I should take current->mm->mmap_sem in beginning of videobuf_qbuf and release it immediately, is this a right way? Looking for your comments, Best regards, Maxim Levitsky PS: this is a call trace of both threads after the hang (with frame pointers enabled): <4>[18681.072790] kdetv D c1ef3900 0 8137 4821 <4>[18681.072794]df0b1ee4 00200046 0818 c1ef3900 0002 df0b1ecc 6f504f76 0cd3 <4>[18681.072801]df00e000 c1f3ed40 00200046 00d269ab 0001 000187f7 <4>[18681.072809]00ff 0818 f722f5dc 00200246 df00e000 df0b1f24 <4>[18681.072816] Call Trace: <4>[18681.072818] [] __mutex_lock_slowpath+0xf8/0x350 <4>[18681.072822] [] mutex_lock+0x1c/0x20 <4>[18681.072825] [] videobuf_vm_close+0x9d/0x140 [video_buf] <4>[18681.072835] [] remove_vma+0x2b/0x50 <4>[18681.072839] [] do_munmap+0x18a/0x1f0 <4>[18681.072843] [] sys_munmap+0x30/0x50 <4>[18681.072847] [] sysenter_past_esp+0x6b/0xb5 <4>[18681.072851] === <4>[18681.072853] kdetv D c1f45900 0 8139 4821 <4>[18681.072857]dc12fd08 00200046 0a18 c1f45900 0002 dc12fcf0 6f4ec99b 0cd3 <4>[18681.072864]c3e26d00 c1f90d40 0001 0002 00d269b4 0001 000144f6 <4>[18681.072872]00ff 0a18 0002 e48f0b34 c3e26d00 dc12fd30 <4>[18681.072879] Call Trace: <4>[18681.072881] [] rwsem_down_failed_common+0x75/0x190 <4>[18681.072885] [] rwsem_down_read_failed+0x1d/0x28 <4>[18681.072889] [] call_rwsem_down_read_failed+0x7/0xc <4>[18681.072894] [] videobuf_dma_init_user+0xb4/0x150 [video_buf] <4>[18681.072901] [] videobuf_iolock+0xd7/0xe0 [video_buf] <4>[18681.072907] [] buffer_prepare+0x1b2/0x200 [saa7134] <4>[18681.072919] [] videobuf_qbuf+0x20d/0x440 [video_buf] <4>[18681.072926] [] video_do_ioctl+0x562/0x1110 [saa7134] <4>[18681.072937] [] video_usercopy+0xda/0x250 [videodev] <4>[18681.072943] [] video_ioctl+0x1a/0x20 [saa7134] <4>[18681.072954] [] do_ioctl+0x6b/0x80 <4>[18681.072957] [] vfs_ioctl+0x57/0x290 <4>[18681.072961] [] sys_ioctl+0x39/0x60 <4>[18681.072964] [] sysenter_past_esp+0x6b/0xb5 <4>[18681.072969] === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Maple bus support for the Sega Dreamcast - keyboard support
On Sun, 9 Sep 2007 21:57:35 +0100 "Adrian McMenamin" <[EMAIL PROTECTED]> wrote: ok looks good to me; thanks a lot for converting to mutexes ;) Acked-by: Arjan van de Ven <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFSv4] 2.6.23-rc4 oops in nfs4_cb_recall...
> When accessing a directory inode from a single other client, NFSv4 > callbacks catastrophically failed [1] on the NFS server with > 2.6.23-rc4 (unpatched); clients are both 2.6.22 (Ubuntu Gutsy build). > Seems not easy to reproduce, since this kernel was running smoothly > for 7 days on the server. > > What information will help track this down, or is there a known > failure mechanism? I haven't seen that before. > I can map stack frames to source lines with objdump, if that helps. If it's still easy, it might help to figure out exactly where in xprt_reserve() it died, and why. If we've got some race that can lead to freeing the client while a callback is in progress, then perhaps this is on the first dereference of xprt? --b. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata & scsi suggestion for make menuconfig
> I can see where you're coming from, but logically, this is wrong. > There's a huge slew of enterprise machines that only have DVD on SATA. ... and enterprise systems don't really care about a few KB more of code. In fact you definitely want to have SATA compiled in in case you need to recover the machine later when the SAN is down. > On the other hand, all of these machines will have SCSI disk devices on > various other transports, so no harm is done, it's just an inelegant > solution. Do you know of a better one? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata & scsi suggestion for make menuconfig
On Sat, 2007-09-08 at 18:07 +0200, Andi Kleen wrote: > Folkert van Heusden <[EMAIL PROTECTED]> writes: > > > Hi, > > > > Maybe it is a nice enhancement for make menuconfig to more explicitly > > give a pop-up or so when someone selects for example a sata controller > > while no 'scsi-disk' support was selected? > > This has also bitten me one or two times. A reasonable way would > be to just select SD automatically for !EMBEDDED > > Here's a patch: > > -Andi > > Select BLK_DEV_SD for all SCSI/libata drivers > > This avoid a common user mistake. I can see where you're coming from, but logically, this is wrong. There's a huge slew of enterprise machines that only have DVD on SATA. On the other hand, all of these machines will have SCSI disk devices on various other transports, so no harm is done, it's just an inelegant solution. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Maple bus support for the Sega Dreamcast - keyboard support
On 09/09/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Sun, 9 Sep 2007 21:35:11 +0100
> "Adrian McMenamin" <[EMAIL PROTECTED]> wrote:
>
> I think this has a bug; mutex_trylock has the opposite return code as
> down_trylock (mutex follows the same convention as the spinlock
> trylock) so you probably need to add a ! here...
>
Quite right. Also explains the big fall in the keyboard's
responsiveness - though, to be honest, I don't see how it worked at
all.
Here's the correct patch.
Add maple bus keyboard support to the kernel.
Signed-off by Adrian McMenamin <[EMAIL PROTECTED]>
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index c97d5eb..056cc52 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -253,4 +253,14 @@ config KEYBOARD_GPIO
To compile this driver as a module, choose M here: the
module will be called gpio-keys.
+
+config KEYBOARD_MAPLE
+ tristate "Maple bus keyboard"
+ depends on SH_DREAMCAST && MAPLE
+ help
+ Say Y here if you have a Dreamcast console running Linux and have
+ a keyboard attached to its Maple bus.
+
+ To compile this driver as a module, choose M here: the
+ module will be called maple_keyb.
endif
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 28d211b..3f775ed 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_KEYBOARD_OMAP) += omap-keypad.o
obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keyboard.o
obj-$(CONFIG_KEYBOARD_AAED2000)+= aaed2000_kbd.o
obj-$(CONFIG_KEYBOARD_GPIO)+= gpio_keys.o
+obj-$(CONFIG_KEYBOARD_MAPLE) += maple_keyb.o
diff --git a/drivers/input/keyboard/maple_keyb.c
b/drivers/input/keyboard/maple_keyb.c
new file mode 100644
index 000..0e580c7
--- /dev/null
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -0,0 +1,234 @@
+/*
+ * SEGA Dreamcast keyboard driver
+ * Based on drivers/usb/usbkbd.c
+ * Copyright YAEGASHI Takeshi, 2001
+ * Porting to 2.6 Copyright Adrian McMenamin, 2007
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see the file COPYING, or write
+ * to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Very simple mutex to ensure proper cleanup */
+static DEFINE_MUTEX(maple_keyb_mutex);
+
+#define NR_SCANCODES 256
+
+MODULE_AUTHOR("YAEGASHI Takeshi, Adrian McMenamin");
+MODULE_DESCRIPTION("SEGA Dreamcast keyboard driver");
+MODULE_LICENSE("GPL");
+
+extern int maple_driver_register(struct device_driver *drv);
+
+const static unsigned char dc_kbd_keycode[NR_SCANCODES] = {
+ KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_A,
KEY_B, KEY_C, KEY_D,
+ KEY_E, KEY_F, KEY_G, KEY_H, KEY_I, KEY_J, KEY_K, KEY_L,
+ KEY_M, KEY_N, KEY_O, KEY_P, KEY_Q, KEY_R, KEY_S, KEY_T,
+ KEY_U, KEY_V, KEY_W, KEY_X, KEY_Y, KEY_Z, KEY_1, KEY_2,
+ KEY_3, KEY_4, KEY_5, KEY_6, KEY_7, KEY_8, KEY_9, KEY_0,
+ KEY_ENTER, KEY_ESC, KEY_BACKSPACE, KEY_TAB, KEY_SPACE, KEY_MINUS,
KEY_EQUAL, KEY_LEFTBRACE,
+ KEY_RIGHTBRACE, KEY_BACKSLASH, KEY_BACKSLASH, KEY_SEMICOLON,
KEY_APOSTROPHE, KEY_GRAVE, KEY_COMMA,
+ KEY_DOT, KEY_SLASH, KEY_CAPSLOCK, KEY_F1, KEY_F2, KEY_F3, KEY_F4,
KEY_F5, KEY_F6,
+ KEY_F7, KEY_F8, KEY_F9, KEY_F10, KEY_F11, KEY_F12, KEY_SYSRQ,
+ KEY_SCROLLLOCK, KEY_PAUSE, KEY_INSERT, KEY_HOME, KEY_PAGEUP, KEY_DELETE,
+ KEY_END, KEY_PAGEDOWN, KEY_RIGHT, KEY_LEFT, KEY_DOWN, KEY_UP,
+ KEY_NUMLOCK, KEY_KPSLASH, KEY_KPASTERISK, KEY_KPMINUS, KEY_KPPLUS,
KEY_KPENTER, KEY_KP1, KEY_KP2,
+ KEY_KP3, KEY_KP4, KEY_KP5, KEY_KP6, KEY_KP7, KEY_KP8, KEY_KP9,
KEY_KP0, KEY_KPDOT,
+ KEY_102ND, KEY_COMPOSE, KEY_POWER, KEY_KPEQUAL, KEY_F13, KEY_F14,
KEY_F15,
+ KEY_F16, KEY_F17, KEY_F18, KEY_F19, KEY_F20,
+ KEY_F21, KEY_F22, KEY_F23, KEY_F24, KEY_OPEN, KEY_HELP, KEY_PROPS,
KEY_FRONT,
+ KEY_STOP, KEY_AGAIN, KEY_UNDO, KEY_CUT, KEY_COPY, KEY_PASTE,
KEY_FIND, KEY_MUTE,
+ KEY_VOLUMEUP, KEY_VOLUMEDOWN, KEY_RESERVED, KEY_RESERVED,
KEY_RESERVED, KEY_KPCOMMA, KEY_RESERVED, KEY_RO, KEY_KATAKANAHIRAGANA
, KEY_YEN,
+ KEY_HENKAN, KEY_MUHENKAN, KEY_KPJPCOMMA, KEY_RESERVED, KEY_RESERVED,
KEY_RESERVED,
Re: [RFC][Intel-IOMMU] Fix for IOMMU early crash
Keshavamurthy, Anil S writes: > Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash > > Populating pci_bus->sysdata way early in the pci discovery phase > sets NON-NULL value to pci_dev->sysdata which breaks the assumption > in the Intel IOMMU driver and crashes the system. > > > In the drivers/pci/probe.c, pci_dev->sysdata gets a copy of > its pci_bus->sysdata which is not required as > the same can be obtained from pci_dev->bus->sysdata. More over > the left hand assignment of pci_dev->sysdata is never being used, Wrong. You needed to grep a bit more widely... > so their is no point is setting > pci_dev->sysdata = pci_bus->sysdata; > > This patch removes sysdata from pci_dev struct and creates a new > field called sys_data which is exclusively used > by IOMMU driver to keep its per device context pointer. This will break powerpc, because we use the pci_dev->sysdata field to point to a firmware device tree node. Please figure out another way to solve your problem. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PPC64 AT_IGNOREPPC question
Vitaly Mayatskikh writes: > include/asm-powerpc/elf.h:289 > > Why we need the second AT_IGNOREPPC entry here? > > There is a mm_struct->saved_auxv overflow on PPC64 with AT_VECTOR_SIZE > == 44 (may be on PPC32 too, not checked) when adding all entries to > it. I've removed the second AT_IGNOREPCC from ARCH_DLINFO to prevent > overflowing, checked it on IBM OpenPower 720 and a system (Fedora 7) is > going on as well. Have I missed some tricky thing? In the past, ppc32 kernels used to round up the address of the end of the environment pointers to a multiple of 16 before writing the aux vector, which meant that that was where userspace looked for it. When the rounding was removed in the kernel, we arranged to put in the two AT_IGNOREPPC entries so that old binaries would still be able to find the aux vector. I'll have to check when that change was done and decide whether we can now take out the AT_IGNOREPPC entries. If not it sounds like we need to expand AT_VECTOR_SIZE. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Maple bus support for the Sega Dreamcast - keyboard support
On Sun, 9 Sep 2007 21:35:11 +0100
"Adrian McMenamin" <[EMAIL PROTECTED]> wrote:
> On 09/09/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > On Sun, 9 Sep 2007 18:01:26 +0100
> > "Adrian McMenamin" <[EMAIL PROTECTED]> wrote:
> >
> > > This patch adds support for the SEGA Dreamcast keyboard.
> > >
> > > Following suggestions from the inout maintainer it has been
> > > somewhat rewritten since the previous posting
> > > (http://lkml.org/lkml/2007/9/4/168).
> >
> > Hi,
> >
> > this driver in general is quite clean as well; I have only one
> > suggestion for improvement. Right now you use a semaphore for
> > locking, while all you really use it for is mutex semantics, I
> > think it would be a good idea to convert the driver to use the
> > actual mutex primitive; this will buy you a lot of extra automatic
> > checking for bugs...
> >
> > Greetings,
> >Arjan van de Ven
> >
>
> OK... here's a redone patch:
> + unsigned long *buf = mq->recvbuf;
> + if (mutex_trylock(_keyb_mutex)) /* Can only be locked
> if already in cleanup */
> + return;
> + if (buf[1] == mapledev->function) {
>
I think this has a bug; mutex_trylock has the opposite return code as
down_trylock (mutex follows the same convention as the spinlock
trylock) so you probably need to add a ! here...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unexport raise_softirq_irqoff
On Sun, Sep 09, 2007 at 10:25:44PM +0200, Adrian Bunk wrote: > On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.23-rc3-mm1: > >... > > git-net.patch > >... > > git trees > >... > > raise_softirq_irqoff no longer has any modular user. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> This should probably go in through Dave's tree as it's removing this rather annoying user. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] unexport sys_{open,read}
On Sun, Sep 09, 2007 at 10:25:28PM +0200, Adrian Bunk wrote:
> sys_{open,read} can finally be unexported.
Andrew, can you please put this in? Having these exports for syscalls around
hsa been a long-time annoyance that can finally be fixed now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] powerpc: proper defconfig for crosscompiles
On Sun, Sep 09, 2007 at 08:21:17PM +0200, Adrian Bunk wrote: > The trick for finding the right defconfig is neat, but you forgot to > provide an i686_defconfig. ;-) > > More seriously, cross compiling the defconfig is often useful, e.g. for > testing the compilation of patches that touch multiple architectures, > and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is > non-empty. You should probably use ppc64_defconfig instead, since it's the "superset" config that will compile a multiplatform kernel. -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Maple bus support for the Sega Dreamcast - keyboard support
On 09/09/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Sun, 9 Sep 2007 18:01:26 +0100
> "Adrian McMenamin" <[EMAIL PROTECTED]> wrote:
>
> > This patch adds support for the SEGA Dreamcast keyboard.
> >
> > Following suggestions from the inout maintainer it has been somewhat
> > rewritten since the previous posting
> > (http://lkml.org/lkml/2007/9/4/168).
>
> Hi,
>
> this driver in general is quite clean as well; I have only one
> suggestion for improvement. Right now you use a semaphore for locking,
> while all you really use it for is mutex semantics, I think it would be
> a good idea to convert the driver to use the actual mutex primitive;
> this will buy you a lot of extra automatic checking for bugs...
>
> Greetings,
>Arjan van de Ven
>
OK... here's a redone patch:
Maple bus keyboard support for the SEGA Dreamcast.
Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index c97d5eb..056cc52 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -253,4 +253,14 @@ config KEYBOARD_GPIO
To compile this driver as a module, choose M here: the
module will be called gpio-keys.
+
+config KEYBOARD_MAPLE
+ tristate "Maple bus keyboard"
+ depends on SH_DREAMCAST && MAPLE
+ help
+ Say Y here if you have a Dreamcast console running Linux and have
+ a keyboard attached to its Maple bus.
+
+ To compile this driver as a module, choose M here: the
+ module will be called maple_keyb.
endif
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 28d211b..3f775ed 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_KEYBOARD_OMAP) += omap-keypad.o
obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keyboard.o
obj-$(CONFIG_KEYBOARD_AAED2000)+= aaed2000_kbd.o
obj-$(CONFIG_KEYBOARD_GPIO)+= gpio_keys.o
+obj-$(CONFIG_KEYBOARD_MAPLE) += maple_keyb.o
diff --git a/drivers/input/keyboard/maple_keyb.c
b/drivers/input/keyboard/maple_keyb.c
new file mode 100644
index 000..0334c60
--- /dev/null
+++ b/drivers/input/keyboard/maple_keyb.c
@@ -0,0 +1,234 @@
+/*
+ * SEGA Dreamcast keyboard driver
+ * Based on drivers/usb/usbkbd.c
+ * Copyright YAEGASHI Takeshi, 2001
+ * Porting to 2.6 Copyright Adrian McMenamin, 2007
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see the file COPYING, or write
+ * to the Free Software Foundation, Inc.,
+ * 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Very simple mutex to ensure proper cleanup */
+static DEFINE_MUTEX(maple_keyb_mutex);
+
+#define NR_SCANCODES 256
+
+MODULE_AUTHOR("YAEGASHI Takeshi, Adrian McMenamin");
+MODULE_DESCRIPTION("SEGA Dreamcast keyboard driver");
+MODULE_LICENSE("GPL");
+
+extern int maple_driver_register(struct device_driver *drv);
+
+const static unsigned char dc_kbd_keycode[NR_SCANCODES] = {
+ KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_RESERVED, KEY_A,
KEY_B, KEY_C, KEY_D,
+ KEY_E, KEY_F, KEY_G, KEY_H, KEY_I, KEY_J, KEY_K, KEY_L,
+ KEY_M, KEY_N, KEY_O, KEY_P, KEY_Q, KEY_R, KEY_S, KEY_T,
+ KEY_U, KEY_V, KEY_W, KEY_X, KEY_Y, KEY_Z, KEY_1, KEY_2,
+ KEY_3, KEY_4, KEY_5, KEY_6, KEY_7, KEY_8, KEY_9, KEY_0,
+ KEY_ENTER, KEY_ESC, KEY_BACKSPACE, KEY_TAB, KEY_SPACE, KEY_MINUS,
KEY_EQUAL, KEY_LEFTBRACE,
+ KEY_RIGHTBRACE, KEY_BACKSLASH, KEY_BACKSLASH, KEY_SEMICOLON,
KEY_APOSTROPHE, KEY_GRAVE, KEY_COMMA,
+ KEY_DOT, KEY_SLASH, KEY_CAPSLOCK, KEY_F1, KEY_F2, KEY_F3, KEY_F4,
KEY_F5, KEY_F6,
+ KEY_F7, KEY_F8, KEY_F9, KEY_F10, KEY_F11, KEY_F12, KEY_SYSRQ,
+ KEY_SCROLLLOCK, KEY_PAUSE, KEY_INSERT, KEY_HOME, KEY_PAGEUP, KEY_DELETE,
+ KEY_END, KEY_PAGEDOWN, KEY_RIGHT, KEY_LEFT, KEY_DOWN, KEY_UP,
+ KEY_NUMLOCK, KEY_KPSLASH, KEY_KPASTERISK, KEY_KPMINUS, KEY_KPPLUS,
KEY_KPENTER, KEY_KP1, KEY_KP2,
+ KEY_KP3, KEY_KP4, KEY_KP5, KEY_KP6, KEY_KP7, KEY_KP8, KEY_KP9,
KEY_KP0, KEY_KPDOT,
+ KEY_102ND, KEY_COMPOSE, KEY_POWER, KEY_KPEQUAL, KEY_F13, KEY_F14,
KEY_F15,
+ KEY_F16, KEY_F17, KEY_F18, KEY_F19, KEY_F20,
+ KEY_F21, KEY_F22, KEY_F23, KEY_F24, KEY_OPEN, KEY_HELP, KEY_PROPS,
KEY_FRONT,
+ KEY_STOP, KEY_AGAIN,
[-mm patch] make do_try_to_free_pages() static
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> +memory-controller-add-per-container-lru-and-reclaim-v7.patch
>...
> memory containment
>...
do_try_to_free_pages() can become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
23781fa6792c518c8581ceeaf08db251574e8430
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b34b29d..9104cf8 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1248,8 +1248,8 @@ static unsigned long shrink_zones(int priority, struct
zone **zones,
* holds filesystem locks which prevent writeout this might not work, and the
* allocation attempt will fail.
*/
-unsigned long do_try_to_free_pages(struct zone **zones, gfp_t gfp_mask,
- struct scan_control *sc)
+static unsigned long do_try_to_free_pages(struct zone **zones, gfp_t gfp_mask,
+ struct scan_control *sc)
{
int priority;
int ret = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] make sctp_addto_param() static
sctp_addto_param() can become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/net/sctp/structs.h |1
net/sctp/sm_make_chunk.c | 39 ++---
2 files changed, 20 insertions(+), 20 deletions(-)
38f8064114b9e89a6a911b2e3625a41cdb477bcd
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index c0d5848..ee4559b 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -726,7 +726,6 @@ int sctp_user_addto_chunk(struct sctp_chunk *chunk, int
off, int len,
struct iovec *data);
void sctp_chunk_free(struct sctp_chunk *);
void *sctp_addto_chunk(struct sctp_chunk *, int len, const void *data);
-void *sctp_addto_param(struct sctp_chunk *, int len, const void *data);
struct sctp_chunk *sctp_chunkify(struct sk_buff *,
const struct sctp_association *,
struct sock *);
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 79856c9..cf3b560 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -839,6 +839,26 @@ err_chunk:
return retval;
}
+/* Append bytes to the end of a parameter. Will panic if chunk is not big
+ * enough.
+ */
+static void *sctp_addto_param(struct sctp_chunk *chunk, int len,
+ const void *data)
+{
+ void *target;
+ int chunklen = ntohs(chunk->chunk_hdr->length);
+
+ target = skb_put(chunk->skb, len);
+
+ memcpy(target, data, len);
+
+ /* Adjust the chunk length field. */
+ chunk->chunk_hdr->length = htons(chunklen + len);
+ chunk->chunk_end = skb_tail_pointer(chunk->skb);
+
+ return target;
+}
+
/* Make an ABORT chunk with a PROTOCOL VIOLATION cause code. */
struct sctp_chunk *sctp_make_abort_violation(
const struct sctp_association *asoc,
@@ -1146,25 +1166,6 @@ void *sctp_addto_chunk(struct sctp_chunk *chunk, int
len, const void *data)
return target;
}
-/* Append bytes to the end of a parameter. Will panic if chunk is not big
- * enough.
- */
-void *sctp_addto_param(struct sctp_chunk *chunk, int len, const void *data)
-{
- void *target;
- int chunklen = ntohs(chunk->chunk_hdr->length);
-
- target = skb_put(chunk->skb, len);
-
- memcpy(target, data, len);
-
- /* Adjust the chunk length field. */
- chunk->chunk_hdr->length = htons(chunklen + len);
- chunk->chunk_end = skb_tail_pointer(chunk->skb);
-
- return target;
-}
-
/* Append bytes from user space to the end of a chunk. Will panic if
* chunk is not big enough.
* Returns a kernel err value.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] net/sctp/socket.c: make 3 variables static
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> git-net.patch
>...
> git trees
>...
This patch makes the following needlessly globalvariables static:
- sctp_memory_pressure
- sctp_memory_allocated
- sctp_sockets_allocated
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
3c211ad074038414ebc156b1abbc3df78dc60cb2
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 37e7306..f53545a 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -112,9 +112,9 @@ extern int sysctl_sctp_mem[3];
extern int sysctl_sctp_rmem[3];
extern int sysctl_sctp_wmem[3];
-int sctp_memory_pressure;
-atomic_t sctp_memory_allocated;
-atomic_t sctp_sockets_allocated;
+static int sctp_memory_pressure;
+static atomic_t sctp_memory_allocated;
+static atomic_t sctp_sockets_allocated;
static void sctp_enter_memory_pressure(void)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] make tcp_splice_data_recv() static
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> git-block.patch
>...
> git trees
>...
tcp_splice_data_recv() can become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
233aefd2a215430c16bd02eca06fb8a4b6079f7a
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 22576e4..6623796 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -515,8 +515,9 @@ static inline void tcp_push(struct sock *sk, int flags, int
mss_now,
}
}
-int tcp_splice_data_recv(read_descriptor_t *rd_desc, struct sk_buff *skb,
-unsigned int offset, size_t len)
+static int tcp_splice_data_recv(read_descriptor_t *rd_desc,
+ struct sk_buff *skb,
+ unsigned int offset, size_t len)
{
struct tcp_splice_state *tss = rd_desc->arg.data;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] unexport raise_softirq_irqoff
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> git-net.patch
>...
> git trees
>...
raise_softirq_irqoff no longer has any modular user.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
eff0407b63757cdd4164a0bdde0313e8f154b6dc
diff --git a/kernel/softirq.c b/kernel/softirq.c
index abae56c..ce38b56 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -335,8 +335,6 @@ inline fastcall void raise_softirq_irqoff(unsigned int nr)
wakeup_softirqd();
}
-EXPORT_SYMBOL(raise_softirq_irqoff);
-
void fastcall raise_softirq(unsigned int nr)
{
unsigned long flags;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] mm/memcontrol.c: clenups
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> +memory-controller-add-switch-to-control-what-type-of-pages-to-limit-v7.patch
>...
> memory containment
>...
This patch makes the following needlessly global functions static:
- lock_page_container()
- unlock_page_container()
- __mem_container_move_lists()
Additionally, there was no reason for the "mem_control_type" object.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
mm/memcontrol.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
b582cc510b6b0a182dc56025828e7a3c566b9724
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8162d98..49bf04f 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -91,7 +91,7 @@ enum {
MEM_CONTAINER_TYPE_CACHED,
MEM_CONTAINER_TYPE_ALL,
MEM_CONTAINER_TYPE_MAX,
-} mem_control_type;
+};
static struct mem_container init_mem_container;
@@ -156,18 +156,18 @@ struct page_container *page_get_page_container(struct
page *page)
(page->page_container & ~PAGE_CONTAINER_LOCK);
}
-void __always_inline lock_page_container(struct page *page)
+static void __always_inline lock_page_container(struct page *page)
{
bit_spin_lock(PAGE_CONTAINER_LOCK_BIT, >page_container);
VM_BUG_ON(!page_container_locked(page));
}
-void __always_inline unlock_page_container(struct page *page)
+static void __always_inline unlock_page_container(struct page *page)
{
bit_spin_unlock(PAGE_CONTAINER_LOCK_BIT, >page_container);
}
-void __mem_container_move_lists(struct page_container *pc, bool active)
+static void __mem_container_move_lists(struct page_container *pc, bool active)
{
if (active)
list_move(>lru, >mem_container->active_list);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] unexport snd_ctl_elem_{read,write}
snd_ctl_elem_{read,write} no longer have any modular users.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch has been sent on:
- 27 Aug 2007
sound/core/control.c |4
1 file changed, 4 deletions(-)
23e15051dde57c569e4c9aff1339aaf64185ea71
diff --git a/sound/core/control.c b/sound/core/control.c
index 396e98e..6144d8a 100644
--- a/sound/core/control.c
+++ b/sound/core/control.c
@@ -716,8 +716,6 @@ int snd_ctl_elem_read(struct snd_card *card, struct
snd_ctl_elem_value *control)
return result;
}
-EXPORT_SYMBOL(snd_ctl_elem_read);
-
static int snd_ctl_elem_read_user(struct snd_card *card,
struct snd_ctl_elem_value __user *_control)
{
@@ -781,8 +779,6 @@ int snd_ctl_elem_write(struct snd_card *card, struct
snd_ctl_file *file,
return result;
}
-EXPORT_SYMBOL(snd_ctl_elem_write);
-
static int snd_ctl_elem_write_user(struct snd_ctl_file *file,
struct snd_ctl_elem_value __user *_control)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] unexport sys_{open,read}
sys_{open,read} can finally be unexported.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch has been sent on:
- 27 Aug 2007
fs/open.c |1 -
fs/read_write.c |1 -
2 files changed, 2 deletions(-)
6f6884f9ee675f2e804c6c58ca46337f9765dd0d
diff --git a/fs/open.c b/fs/open.c
index 23f334d..c0814de 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1057,7 +1057,6 @@ asmlinkage long sys_open(const char __user *filename, int
flags, int mode)
prevent_tail_call(ret);
return ret;
}
-EXPORT_SYMBOL_GPL(sys_open);
asmlinkage long sys_openat(int dfd, const char __user *filename, int flags,
int mode)
diff --git a/fs/read_write.c b/fs/read_write.c
index 507ddff..d913d1e 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -370,7 +370,6 @@ asmlinkage ssize_t sys_read(unsigned int fd, char __user *
buf, size_t count)
return ret;
}
-EXPORT_SYMBOL_GPL(sys_read);
asmlinkage ssize_t sys_write(unsigned int fd, const char __user * buf, size_t
count)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] really unexport do_softirq
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> git-net.patch
>...
> git trees
>...
This hydra had more than one head...
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
arch/i386/kernel/irq.c|2 --
arch/powerpc/kernel/irq.c |1 -
arch/s390/kernel/irq.c|1 -
arch/sh/kernel/irq.c |1 -
arch/x86_64/kernel/irq.c |1 -
5 files changed, 6 deletions(-)
68791fe88172ac3c2dbb0fbbffb8befc7b59e3f7
diff --git a/arch/i386/kernel/irq.c b/arch/i386/kernel/irq.c
index a6b2c7e..de1601f 100644
--- a/arch/i386/kernel/irq.c
+++ b/arch/i386/kernel/irq.c
@@ -231,8 +231,6 @@ asmlinkage void do_softirq(void)
local_irq_restore(flags);
}
-
-EXPORT_SYMBOL(do_softirq);
#endif
/*
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index dfad0e4..65c2409 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -395,7 +395,6 @@ void do_softirq(void)
local_irq_restore(flags);
}
-EXPORT_SYMBOL(do_softirq);
/*
diff --git a/arch/s390/kernel/irq.c b/arch/s390/kernel/irq.c
index 8f0cbca..c36d812 100644
--- a/arch/s390/kernel/irq.c
+++ b/arch/s390/kernel/irq.c
@@ -95,7 +95,6 @@ asmlinkage void do_softirq(void)
local_irq_restore(flags);
}
-EXPORT_SYMBOL(do_softirq);
void init_irq_proc(void)
{
diff --git a/arch/sh/kernel/irq.c b/arch/sh/kernel/irq.c
index 0340498..4b49d03 100644
--- a/arch/sh/kernel/irq.c
+++ b/arch/sh/kernel/irq.c
@@ -245,7 +245,6 @@ asmlinkage void do_softirq(void)
local_irq_restore(flags);
}
-EXPORT_SYMBOL(do_softirq);
#endif
void __init init_IRQ(void)
diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
index 87423b7..3542f0c 100644
--- a/arch/x86_64/kernel/irq.c
+++ b/arch/x86_64/kernel/irq.c
@@ -236,4 +236,3 @@ asmlinkage void do_softirq(void)
}
local_irq_restore(flags);
}
-EXPORT_SYMBOL(do_softirq);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] kernel/kexec.c: make code static
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> +add-vmcoreinfo.patch
>...
> misc
>...
This patch makes the following needlessly global code static:
- vmcoreinfo_data[]
- vmcoreinfo_size
- vmcoreinfo_append_str()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/kexec.h | 14 ---
kernel/kexec.c| 52 +-
2 files changed, 32 insertions(+), 34 deletions(-)
e6dbb01497c12aa69b47914da4db1cfd23e9813e
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 99f2d6f..7cce357 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -123,21 +123,8 @@ int kexec_should_crash(struct task_struct *);
void crash_save_cpu(struct pt_regs *regs, int cpu);
void crash_save_vmcoreinfo(void);
void arch_crash_save_vmcoreinfo(void);
-void vmcoreinfo_append_str(const char *fmt, ...);
unsigned long paddr_vmcoreinfo_note(void);
-#define SYMBOL(name) \
- vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long))
-#define SIZE(name) \
- vmcoreinfo_append_str("SIZE(%s)=%d\n", #name, sizeof(struct name))
-#define OFFSET(name, field) \
- vmcoreinfo_append_str("OFFSET(%s.%s)=%d\n", #name, #field, \
- &(((struct name *)0)->field))
-#define LENGTH(name, value) \
- vmcoreinfo_append_str("LENGTH(%s)=%d\n", #name, value)
-#define CONFIG(name) \
- vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
-
extern struct kimage *kexec_image;
extern struct kimage *kexec_crash_image;
@@ -177,7 +164,6 @@ extern struct resource crashk_res;
typedef u32 note_buf_t[KEXEC_NOTE_BYTES/4];
extern note_buf_t *crash_notes;
extern u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
-extern unsigned int vmcoreinfo_size;
extern unsigned int vmcoreinfo_max_size;
diff --git a/kernel/kexec.c b/kernel/kexec.c
index af2c035..c84a387 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -36,9 +36,9 @@
note_buf_t* crash_notes;
/* vmcoreinfo stuff */
-unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
+static unsigned char vmcoreinfo_data[VMCOREINFO_BYTES];
u32 vmcoreinfo_note[VMCOREINFO_NOTE_SIZE/4];
-unsigned int vmcoreinfo_size = 0;
+static unsigned int vmcoreinfo_size = 0;
unsigned int vmcoreinfo_max_size = sizeof(vmcoreinfo_data);
/* Location of the reserved area for the crash kernel */
@@ -49,6 +49,36 @@ struct resource crashk_res = {
.flags = IORESOURCE_BUSY | IORESOURCE_MEM
};
+#define SYMBOL(name) \
+ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long))
+#define SIZE(name) \
+ vmcoreinfo_append_str("SIZE(%s)=%d\n", #name, sizeof(struct name))
+#define OFFSET(name, field) \
+ vmcoreinfo_append_str("OFFSET(%s.%s)=%d\n", #name, #field, \
+ &(((struct name *)0)->field))
+#define LENGTH(name, value) \
+ vmcoreinfo_append_str("LENGTH(%s)=%d\n", #name, value)
+#define CONFIG(name) \
+ vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
+
+static void vmcoreinfo_append_str(const char *fmt, ...)
+{
+ va_list args;
+ char buf[0x50];
+ int r;
+
+ va_start(args, fmt);
+ r = vsnprintf(buf, sizeof(buf), fmt, args);
+ va_end(args);
+
+ if (r + vmcoreinfo_size > vmcoreinfo_max_size)
+ r = vmcoreinfo_max_size - vmcoreinfo_size;
+
+ memcpy(_data[vmcoreinfo_size], buf, r);
+
+ vmcoreinfo_size += r;
+}
+
int kexec_should_crash(struct task_struct *p)
{
if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
@@ -1163,24 +1193,6 @@ void crash_save_vmcoreinfo(void)
final_note(buf);
}
-void vmcoreinfo_append_str(const char *fmt, ...)
-{
- va_list args;
- char buf[0x50];
- int r;
-
- va_start(args, fmt);
- r = vsnprintf(buf, sizeof(buf), fmt, args);
- va_end(args);
-
- if (r + vmcoreinfo_size > vmcoreinfo_max_size)
- r = vmcoreinfo_max_size - vmcoreinfo_size;
-
- memcpy(_data[vmcoreinfo_size], buf, r);
-
- vmcoreinfo_size += r;
-}
-
/*
* provide an empty default implementation here -- architecture
* code may override this
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] unexport noautodma
noautodma can now be unexported. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- This patch has been sent on: - 27 Aug 2007 957dc7601c050cb14a7afc842db0c2d62aaf3509 diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c index b3b5f00..5b09066 100644 --- a/drivers/ide/ide.c +++ b/drivers/ide/ide.c @@ -100,8 +100,6 @@ static int ide_scan_direction; /* THIS was formerly 2.2.x pci=reverse */ int noautodma = 0; -EXPORT_SYMBOL(noautodma); - #ifdef CONFIG_BLK_DEV_IDEACPI int ide_noacpi = 0; int ide_noacpitfs = 1; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] usb/serial/ch341.c: make 4 functions static
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> +gregkh-usb-usb-driver-for-ch341-usb-serial-adaptor.patch
>...
> USB tree updates
>...
This patch makes four needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/usb/serial/ch341.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
c7046a47d2d1dd5dc6a8fcc298b8c5f7497b3aaa
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index eb68106..6b252ce 100644
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -66,7 +66,8 @@ static int ch341_control_in(struct usb_device *dev,
return r;
}
-int ch341_set_baudrate(struct usb_device *dev, struct ch341_private *priv)
+static int ch341_set_baudrate(struct usb_device *dev,
+ struct ch341_private *priv)
{
short a, b;
int r;
@@ -108,14 +109,15 @@ int ch341_set_baudrate(struct usb_device *dev, struct
ch341_private *priv)
return r;
}
-int ch341_set_handshake(struct usb_device *dev, struct ch341_private *priv)
+static int ch341_set_handshake(struct usb_device *dev,
+ struct ch341_private *priv)
{
dbg("ch341_set_handshake(%d,%d)", priv->dtr, priv->rts);
return ch341_control_out(dev, 0xa4,
~((priv->dtr?1<<5:0)|(priv->rts?1<<6:0)), 0);
}
-int ch341_get_status(struct usb_device *dev)
+static int ch341_get_status(struct usb_device *dev)
{
char *buffer;
int r;
@@ -142,7 +144,7 @@ out:kfree(buffer);
/* --
*/
-int ch341_configure(struct usb_device *dev, struct ch341_private *priv)
+static int ch341_configure(struct usb_device *dev, struct ch341_private *priv)
{
char *buffer;
int r;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] make nfs_wb_page_priority() static
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> git-nfs.patch
>...
> git trees
>...
nfs_wb_page_priority() can now become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
fs/nfs/write.c |3 ++-
include/linux/nfs_fs.h |1 -
2 files changed, 2 insertions(+), 2 deletions(-)
30370f47093c3d812929d84a5a6be79ccb55a2b3
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 3e9e268..37953fd 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1424,7 +1424,8 @@ out:
return ret;
}
-int nfs_wb_page_priority(struct inode *inode, struct page *page, int how)
+static int nfs_wb_page_priority(struct inode *inode, struct page *page,
+ int how)
{
loff_t range_start = page_offset(page);
loff_t range_end = range_start + (loff_t)(PAGE_CACHE_SIZE - 1);
diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h
index f5414fc..e247a40 100644
--- a/include/linux/nfs_fs.h
+++ b/include/linux/nfs_fs.h
@@ -430,7 +430,6 @@ extern long nfs_sync_mapping_wait(struct address_space *,
struct writeback_contr
extern int nfs_wb_all(struct inode *inode);
extern int nfs_wb_nocommit(struct inode *inode);
extern int nfs_wb_page(struct inode *inode, struct page* page);
-extern int nfs_wb_page_priority(struct inode *inode, struct page* page, int
how);
extern int nfs_wb_page_cancel(struct inode *inode, struct page* page);
#if defined(CONFIG_NFS_V3) || defined(CONFIG_NFS_V4)
extern int nfs_commit_inode(struct inode *, int);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] drivers/dma/ioat_dma.c: make 3 functions static
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> +i-oat-add-support-for-msi-and-msi-x.patch
>...
> ioat tree
>...
This patch makes three needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/dma/ioat_dma.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
c633b44cd60648f456a11bb38fd9193ce4d6acdc
diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
index e4c3afe..66c5bb5 100644
--- a/drivers/dma/ioat_dma.c
+++ b/drivers/dma/ioat_dma.c
@@ -47,8 +47,8 @@
static void ioat_dma_start_null_desc(struct ioat_dma_chan *ioat_chan);
static void ioat_dma_memcpy_cleanup(struct ioat_dma_chan *ioat_chan);
-struct ioat_dma_chan *ioat_lookup_chan_by_index(struct ioatdma_device *device,
- int index)
+static struct ioat_dma_chan *ioat_lookup_chan_by_index(struct ioatdma_device
*device,
+ int index)
{
return device->idx[index];
}
@@ -716,7 +716,7 @@ MODULE_PARM_DESC(ioat_interrupt_style,
* ioat_dma_setup_interrupts - setup interrupt handler
* @device: ioat device
*/
-int ioat_dma_setup_interrupts(struct ioatdma_device *device)
+static int ioat_dma_setup_interrupts(struct ioatdma_device *device)
{
struct ioat_dma_chan *ioat_chan;
int err, i, j, msixcnt;
@@ -826,7 +826,7 @@ err_no_irq:
* ioat_dma_remove_interrupts - remove whatever interrupts were set
* @device: ioat device
*/
-void ioat_dma_remove_interrupts(struct ioatdma_device *device)
+static void ioat_dma_remove_interrupts(struct ioatdma_device *device)
{
struct ioat_dma_chan *ioat_chan;
int i;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] remove ide_get_error_location()
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.23-rc3-mm1:
>...
> git-block.patch
>...
> git trees
>...
ide_get_error_location() is no longer used.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/ide/ide-io.c | 35 ---
include/linux/ide.h |5 -
2 files changed, 40 deletions(-)
924249789a0c0d577c5c5bfa91f4e514b7ebde60
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index c1692d9..ec835e3 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -322,41 +322,6 @@ static void ide_complete_pm_request (ide_drive_t *drive,
struct request *rq)
spin_unlock_irqrestore(_lock, flags);
}
-/*
- * FIXME: probably move this somewhere else, name is bad too :)
- */
-u64 ide_get_error_location(ide_drive_t *drive, char *args)
-{
- u32 high, low;
- u8 hcyl, lcyl, sect;
- u64 sector;
-
- high = 0;
- hcyl = args[5];
- lcyl = args[4];
- sect = args[3];
-
- if (ide_id_has_flush_cache_ext(drive->id)) {
- low = (hcyl << 16) | (lcyl << 8) | sect;
- HWIF(drive)->OUTB(drive->ctl|0x80, IDE_CONTROL_REG);
- high = ide_read_24(drive);
- } else {
- u8 cur = HWIF(drive)->INB(IDE_SELECT_REG);
- if (cur & 0x40) {
- high = cur & 0xf;
- low = (hcyl << 16) | (lcyl << 8) | sect;
- } else {
- low = hcyl * drive->head * drive->sect;
- low += lcyl * drive->sect;
- low += sect - 1;
- }
- }
-
- sector = ((u64) high << 24) | low;
- return sector;
-}
-EXPORT_SYMBOL(ide_get_error_location);
-
/**
* ide_end_drive_cmd - end an explicit drive command
* @drive: command
diff --git a/include/linux/ide.h b/include/linux/ide.h
index 48871f9..65de5c3 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1088,11 +1088,6 @@ extern ide_startstop_t ide_do_reset (ide_drive_t *);
extern void ide_init_drive_cmd (struct request *rq);
/*
- * this function returns error location sector offset in case of a write error
- */
-extern u64 ide_get_error_location(ide_drive_t *, char *);
-
-/*
* "action" parameter type for ide_do_drive_cmd() below.
*/
typedef enum {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[-mm patch] alpha bitops.h must #include
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote: >... > Changes since 2.6.23-rc3-mm1: >... > +alpha-lock-bitops.patch >... > various stuff >... This patch fixes the following compile error: <-- snip --> ... CC arch/alpha/kernel/asm-offsets.s In file included from /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/bitops.h:17, from /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/kernel.h:15, from /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/linux/sched.h:50, from /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/arch/alpha/kernel/asm-offsets.c:9: include2/asm/bitops.h: In function 'clear_bit_unlock': include2/asm/bitops.h:75: error: implicit declaration of function 'smp_mb' make[2]: *** [arch/alpha/kernel/asm-offsets.s] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 6df784c9aa4ba1ff2062b63e733c645e8b1e5203 diff --git a/include/asm-alpha/bitops.h b/include/asm-alpha/bitops.h index ffec8a8..381b4f5 100644 --- a/include/asm-alpha/bitops.h +++ b/include/asm-alpha/bitops.h @@ -2,6 +2,7 @@ #define _ALPHA_BITOPS_H #include +#include /* * Copyright 1994, Linus Torvalds. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/firmware: const-ify DMI API and internals
> > > > I was just going to push it myself, but have no strong feelings on the > > matter. > > Ok, you can push it, that's fine with me. Feel free to add my: > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > if you want. That should be "Acked-by:" since the patch does not pass via you but you acknowledge it is OK by your Ack. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Patch Dreamcast AICA driver to handle Maple bus support
This patches the AICA sound driver for the Dreamcast to handle the
well known flakiness of the Dreamcast's G2 bus.
This is dependent on getting Maple bus support (see
http://lkml.org/lkml/2007/9/9/70) into the kernel.
Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
diff --git a/sound/sh/aica.c b/sound/sh/aica.c
index 7397865..a42c58f 100644
--- a/sound/sh/aica.c
+++ b/sound/sh/aica.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,7 +44,7 @@
#include
#include
#include
-#include
+#include
#include "aica.h"
MODULE_AUTHOR("Adrian McMenamin <[EMAIL PROTECTED]>");
@@ -218,6 +219,12 @@ static int aica_dma_transfer(int channels, int buffer_size,
period_offset = dreamcastcard->clicks;
period_offset %= (AICA_PERIOD_NUMBER / channels);
runtime = substream->runtime;
+ /* If maple dma is running, wait for it to finish */
+ do{ cpu_relax();}
+ while (!maple_dma_done());
+ /* Turn off the maple dma now */
+ ctrl_outl(0, MAPLE_ENABLE);
+ local_irq_disable();
for (q = 0; q < channels; q++) {
err = dma_xfer(AICA_DMA_CHANNEL,
(unsigned long) (runtime->dma_area +
@@ -232,6 +239,9 @@ static int aica_dma_transfer(int channels, int buffer_size,
break;
dma_wait_for_completion(AICA_DMA_CHANNEL);
}
+ /* restore maple dma */
+ local_irq_enable();
+ maplebus_init_hardware();
return err;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/firmware: const-ify DMI API and internals
On Sat, Sep 01, 2007 at 12:01:20PM -0400, Jeff Garzik wrote: > Greg KH wrote: >> On Sat, Sep 01, 2007 at 10:27:19AM -0400, Jeff Garzik wrote: >>> commit 457b6eb3bf3341d2e143518a0bb99ffbb8d754c4 >>> Author: Jeff Garzik <[EMAIL PROTECTED]> >>> Date: Sat Sep 1 10:16:45 2007 -0400 >>> >>> drivers/firmware: const-ify DMI API and internals >>> Three main sets of changes: >>> 1) dmi_get_system_info() return value should have been marked >>> const, >>>since callers should not be changing that data. >>> 2) const-ify DMI internals, since DMI firmware tables should, >>>whenever possible, be marked const to ensure we never ever write >>> to >>>that data area. >>> 3) const-ify DMI API, to enable marking tables const where >>> possible >>>in low-level drivers. >>> And if we're really lucky, this might enable some additional >>> optimizations on the part of the compiler. >>> The bulk of the changes are #2 and #3, which are interrelated. >>> #1 could >>> have been a separate patch, but it was so small compared to the >>> others, >>> it was easier to roll it into this changeset. >> Looks great to me, do you want me to take this through my driver tree? >> I'd be glad to do so. > > I was just going to push it myself, but have no strong feelings on the > matter. Ok, you can push it, that's fine with me. Feel free to add my: Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> if you want. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] disable PCIE 'Enable No Snoop' bit by default
On Thu, Sep 06, 2007 at 05:40:38AM -0700, David Miller wrote: > From: Matthew Wilcox <[EMAIL PROTECTED]> > Date: Thu, 6 Sep 2007 05:57:31 -0600 > > > I'm not sure your analysis is correct. Here's what my draft copy of > > the pcie 2.0 spec says: > > > > Enble No Snoop ? If this bit is Set, the Function is permitted to > > Set the No Snoop bit in the Requester Attributes of transactions it > > initiates that do not require hardware enforced cache coherency (see > > Section 2.2.6.5). Note that setting this bit to 1b should not cause > > a Function to Set the No Snoop attribute on all transactions that it > > initiates. Even when this bit is Set, a Function is only permitted > > to Set the No Snoop attribute on a transaction when it can guarantee > > that the address of the transaction is not stored in any cache in > > the system. This bit permitted to be hardwired to 0b if a Function > > would never Set the No Snoop attribute in transactions it initiates. > > Default value of this bit is 1b. > > > > That implies that devices are only allowed to set it when it's safe to > > do so ... and we don't need to turn it off. > > This is my understanding of this area of PCI-E as well, and I > also agree that therefore we should not turn this bit off. I agree. But Shaohua, do you see any problems that this patch fixes? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.23-rc4][reRESEND] irq: irq and pci_ids patch for Intel Tolapai
On Thu, Sep 06, 2007 at 10:24:54AM -0700, Gaston, Jason D wrote: > >-Original Message- > >From: Gaston, Jason D > >Sent: Thursday, August 30, 2007 8:34 PM > >To: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; linux- > >[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > >Gaston, Jason D > >Subject: [PATCH 2.6.23-rc4][reRESEND] irq: irq and pci_ids patch for > Intel > >Tolapai > > > >Resend with uppercase define. > > > >This updated patch adds the Intel Tolapai LPC and SMBus controller > DID's. > > > >Signed-off-by: Jason Gaston <[EMAIL PROTECTED]> > > > >--- linux-2.6.23-rc4/arch/i386/pci/irq.c.orig2007-08-27 > >18:32:35.0 -0700 > >+++ linux-2.6.23-rc4/arch/i386/pci/irq.c 2007-08-30 > 20:23:49.0 - > >0700 > >@@ -550,6 +550,7 @@ > > case PCI_DEVICE_ID_INTEL_ICH9_3: > > case PCI_DEVICE_ID_INTEL_ICH9_4: > > case PCI_DEVICE_ID_INTEL_ICH9_5: > >+case PCI_DEVICE_ID_INTEL_TOLAPAI_0: > > r->name = "PIIX/ICH"; > > r->get = pirq_piix_get; > > r->set = pirq_piix_set; > >--- linux-2.6.23-rc4/include/linux/pci_ids.h.orig2007-08-27 > >18:32:35.0 -0700 > >+++ linux-2.6.23-rc4/include/linux/pci_ids.h 2007-08-30 > >20:23:08.0 -0700 > >@@ -2293,6 +2293,8 @@ > > #define PCI_DEVICE_ID_INTEL_MCH_PC 0x3599 > > #define PCI_DEVICE_ID_INTEL_MCH_PC1 0x359a > > #define PCI_DEVICE_ID_INTEL_E7525_MCH 0x359e > >+#define PCI_DEVICE_ID_INTEL_TOLAPAI_0 0x5031 > >+#define PCI_DEVICE_ID_INTEL_TOLAPAI_1 0x5032 > > #define PCI_DEVICE_ID_INTEL_82371SB_0 0x7000 > > #define PCI_DEVICE_ID_INTEL_82371SB_1 0x7010 > > #define PCI_DEVICE_ID_INTEL_82371SB_2 0x7020 > > Greg, > > Is this patch acceptable? I need to get this in before the i2c-i801 > patch will be accepted. I've just applied it to my trees. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/pci/: possible cleanups
On Mon, Aug 27, 2007 at 11:28:22PM +0200, Adrian Bunk wrote: > This patch contains the following possible cleanups: > - make the following needlessly global function static: > - pci.c: pci_restore_bars() > - #if 0 the following unused global functions: > - rom.c: pci_map_rom_copy() > - rom.c: pci_remove_rom() > - remove the following unused EXPORT_SYMBOL's: > - pci-acpi.c: pci_osc_support_set > - proc.c: pci_proc_detach_bus > - remove the following unused EXPORT_SYMBOL_GPL's: > - bus.c: pci_walk_bus > - probe.c: pci_create_bus > - setup-res.c: pci_claim_resource Care to split this up into 4 different patches so as to make it easier for people in case they cause problems in the future? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ELAN U132 Host Controller Driver: convert scheduler_lock to mutex
On Fri, Sep 07, 2007 at 03:10:54PM +0200, Matthias Kaehlcke wrote: > A corrected version of the patch, the first one contained context > removed by the first patch of this serie This patch for some reason did not apply cleanly. Care to redo it after the next -mm releae that has your first patch in it (that looked fine.) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nozomi DTR/RTS
On Fri, Aug 24, 2007 at 12:02:40PM +0200, Eric Lammerts wrote: > Hi, > I noticed that DTR toggling doesn't work with the nozomi driver > (TIOCMBIS/TIOCMBIC ioctls have no effect). This is a nuisance because that > makes it hard to get the modem back in command mode. > > Attached patch adds a tty_ops->tiocmset function that makes it work. > > Should we also rip out the TIOCMBIS/TIOCMBIC handling in ntty_ioctl()? It > doesn't seem to be used anyway. > > Patch is against 2.6.23-rc3-mm1, but not tested with that. I tested it with > 2.6.18.4 and the pharscape.org driver. Thanks, I've updated the driver in -mm with these changes. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regarding sysfs/kobject separation
On Sun, Sep 02, 2007 at 10:40:58PM +0900, Tejun Heo wrote: > Hello, just a note to tell you guys what's going on. > > It's taking more time than I expected but it's near completion. I'm > testing things now. After that, they need to be split and documented. > It'll be a BIG change and due to other things including moronic military > reserve training, I'll probably be able to post it after next week. > Sorry about the delay but I think the result will be pretty good in the end. > > * Suicidal nodes don't need special treatment. If a file tries to > commit suicide, sysfs will detect the condition and deactivate and drain > the node except for the suiciding reference. > > * much more compact and flexible interface based on sysfs_dirent instead > of kobject. Why? What would use this kind of interface? Why would you want to create things in sysfs without a kobject? > * Backward compatibility is fully maintained. All kobject based > interface is reimplemented in terms of the new interface. This is a source level for the sysfs functions compatibility, right? Or is this the userspace view of sysfs? If the later one, why would that have changed? > * Plugged creation and batched error handling. Sysfs directories can be > 'plugged' on creation such that it can be made visible atomically after > all its subtrees are constructed. Also, the user doesn't have to check > for failure at every step. For example, the user can do the following. > > dir = sysfs_add_dir(parent, "my_dir", SYSFS_PLUGGED | 0777); > sysfs_add_file(dir, ...); > ... > dir2 = sysfs_add_dir(dir, ...); > sysfs_add_link(dir, "link-to-dir2", dir2); > ... > if (sysfs_check_batch_error(dir) == 0) > sysfs_unplug(dir); > else > sysfs_remove(dir); > > And all the nodes under and including @dir will show up atomically if > all operations succeeded or removed without ever bothering userland. Is this really needed? We work on kobjects and attributes today, and we can easily add and remove groups of attributes just fine. > * Automatic symlink handling. Symlink names can be formatted with the > name of its target. e.g. if the symlink name is specified as > "link-%1:%0" and points to "devices/mybus0/mydev0", its name becomes > "link-mybus0-mydev0" && the symlink will be automatically renamed when > the target node or one of its ancestor is moved or renamed. The symlink > is also plugged and removed together with its target. So, once created, > the user doesn't have to care about the symlink. sysfs will take care > of it. This might be nice, it would take code out of kobject_move(), right? > * I think most of the changes wouldn't hinder implementation of tagged > nodes. In fact, most of the new rename logic which handles symlink > rename together is taken from tagged node implementation, so with some > luck it should be easier to support tagged nodes. > > *** Future plans. > > * Move uevent support over to sysfs and bridging the current users. > This makes sense because sysfs hierarchy is all that userland can see > and sysfs users which don't use kobject also needs uevent support. What sysfs users without kobjects? Why? > * Convert device model (drivers/base/*) over to the new sysfs_dirent > based interface and make device/driver <-> sysfs association flexible. > Automatic sysfs association is a good thing. In most cases, it makes > sense and makes drivers simpler but it also needs to be flexible such > that drivers with special needs can override how the device and driver > are represented to userland. I think such flexibility can be achieved > without too much problem now that sysfs and kobject are separated. Hm, I'll have to wait to see the code to understand what you mean by this one :) thanks for all your work on sysfs so far, it is much nicer than it used to be. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/5] Use extended crashkernel command line on IA64
* Matthew Wilcox <[EMAIL PROTECTED]> [2007-09-09 15:01]:
> On Sun, Sep 09, 2007 at 10:39:18AM +0200, Bernhard Walle wrote:
> > Because the total amount of System RAM must be known when calling this
> > function, efi_memmap_init() is modified to return its comulated
>
> accumulated?
Yes, sorry.
> > total_memory variable in a pointer value. IMO that's better than making the
> > variable global.
>
> Why not make efi_memmap_init() return total_memory instead of void?
Good idea:
-
From: Bernhard Walle <[EMAIL PROTECTED]>
Subject: Use extended crashkernel command line on IA64
Cc: [EMAIL PROTECTED]
This patch adapts IA64 to use the generic parse_crashkernel() function
instead of its own parsing for the crashkernel command line.
Because the total amount of System RAM must be known when calling this
function, efi_memmap_init() is modified to return its accumulated
total_memory variable in a pointer value. IMO that's better than making the
variable global.
Also, the crashkernel handling is moved in an own function in
arch/ia64/kernel/setup.c to make the code more readable.
Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
---
arch/ia64/kernel/efi.c |4 +-
arch/ia64/kernel/setup.c | 88 +++--
include/asm-ia64/meminit.h |2 -
3 files changed, 50 insertions(+), 44 deletions(-)
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -967,7 +967,7 @@ find_memmap_space (void)
* to use. We can allocate partial granules only if the unavailable
* parts exist, and are WB.
*/
-void
+unsigned long
efi_memmap_init(unsigned long *s, unsigned long *e)
{
struct kern_memdesc *k, *prev = NULL;
@@ -1084,6 +1084,8 @@ efi_memmap_init(unsigned long *s, unsign
/* reserve the memory we are using for kern_memmap */
*s = (u64)kern_memmap;
*e = (u64)++k;
+
+ return total_memory;
}
void
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -208,6 +208,48 @@ static int __init register_memory(void)
__initcall(register_memory);
+
+#ifdef CONFIG_KEXEC
+static void setup_crashkernel(unsigned long total, int *n)
+{
+ unsigned long long base = 0, size = 0;
+ int ret;
+
+ ret = parse_crashkernel(boot_command_line, total,
+ , );
+ if (ret == 0 && size > 0) {
+ if (!base) {
+ sort_regions(rsvd_region, *n);
+ base = kdump_find_rsvd_region(size,
+ rsvd_region, *n);
+ }
+ if (base != ~0UL) {
+ printk(KERN_INFO "Reserving %ldMB of memory at %ldMB "
+ "for crashkernel (System RAM: %ldMB)\n",
+ (unsigned long)(size >> 20),
+ (unsigned long)(base >> 20),
+ (unsigned long)(total >> 20));
+ rsvd_region[*n].start =
+ (unsigned long)__va(base);
+ rsvd_region[*n].end =
+ (unsigned long)__va(base + size);
+ (*n)++;
+ crashk_res.start = base;
+ crashk_res.end = base + size - 1;
+ }
+ }
+ efi_memmap_res.start = ia64_boot_param->efi_memmap;
+ efi_memmap_res.end = efi_memmap_res.start +
+ ia64_boot_param->efi_memmap_size;
+ boot_param_res.start = __pa(ia64_boot_param);
+ boot_param_res.end = boot_param_res.start +
+ sizeof(*ia64_boot_param);
+}
+#else
+static inline void setup_crashkernel(unsigned long total, int *n)
+{}
+#endif
+
/**
* reserve_memory - setup reserved memory areas
*
@@ -219,6 +261,7 @@ void __init
reserve_memory (void)
{
int n = 0;
+ unsigned long total_memory = 0;
/*
* none of the entries in this table overlap
@@ -254,50 +297,11 @@ reserve_memory (void)
n++;
#endif
- efi_memmap_init(_region[n].start, _region[n].end);
+ total_memory = efi_memmap_init(_region[n].start,
_region[n].end);
n++;
-#ifdef CONFIG_KEXEC
- /* [EMAIL PROTECTED] specifies the size to reserve for a crash
-* kernel. If offset is 0, then it is determined automatically.
-* By reserving this memory we guarantee that linux never set's it
-* up as a DMA target.Useful for holding code to do something
-* appropriate after a kernel panic.
-*/
- {
- char *from = strstr(boot_command_line, "crashkernel=");
- unsigned long base, size;
- if (from) {
- size = memparse(from + 12, );
- if (*from == '@')
- base = memparse(from+1, );
- else
- base = 0;
- if (size)
Re: [PATCH] [Bug 8998] Mutex documentation is unclear about software interrupts, tasklets and timers in Linux 2.6.23-rc
On Sun, 9 Sep 2007 12:02:53 -0700 (PDT) Matti Linnanvuori <[EMAIL PROTECTED]> wrote: Hi, thank you for improving the documentation > diff -uprN linux-2.6.23/Documentation/mutex-design.txt > linux-2.6.23-patched/Documentation/mutex-design.txt --- > > > Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> > Acked-by: Arjan van de Ven <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [Bug 8998] Mutex documentation is unclear about software interrupts, tasklets and timers in Linux 2.6.23-rc
diff -uprN linux-2.6.23/Documentation/mutex-design.txt linux-2.6.23-patched/Documentation/mutex-design.txt --- linux-2.6.23/Documentation/mutex-design.txt2007-09-09 21:47:10.545275000 +0300 +++ linux-2.6.23-patched/Documentation/mutex-design.txt2007-09-09 21:48:17.935493000 +0300 @@ -90,7 +90,8 @@ of advantages of mutexes: * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized - * - mutexes may not be used in irq contexts + * - mutexes may not be used in hardware or software interrupt + * contexts such as tasklets and timers furthermore, there are also convenience features in the debugging code: diff -uprN linux-2.6.23/include/linux/mutex.h linux-2.6.23-patched/include/linux/mutex.h --- linux-2.6.23/include/linux/mutex.h2007-09-09 21:49:04.531143500 +0300 +++ linux-2.6.23-patched/include/linux/mutex.h2007-09-09 21:49:44.946525500 +0300 @@ -29,7 +29,8 @@ * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized - * - mutexes may not be used in irq contexts + * - mutexes may not be used in hardware or software interrupt + * contexts such as tasklets and timers * * These semantics are fully enforced when DEBUG_MUTEXES is * enabled. Furthermore, besides enforcing the above rules, the mutex Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> __ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] Express relocatability of kernel on x86_64 in documentation
On Sun, 09 Sep 2007 10:06:21 +0200 Bernhard Walle wrote: > This patch adapts the Documentation/kdump/kdump.txt file to express the fact > that the x86_64 kernel is now also relocatable. This makes i386 and x86_64 now > behave the same, simplifying the documentation. > > > Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> Hi, Can we also please reconcile the CRASH_DUMP Kconfig help text? I.e., it says The crash dump kernel must be compiled to a memory address not used by the main kernel or BIOS using PHYSICAL_START. but this ignores the use of RELOCATABLE, right? --- From: Randy Dunlap <[EMAIL PROTECTED]> Update help text for CONFIG_CRASH_DUMP. Fix typos in CONFIG_RELOCATABLE. Use tab + 2 spaces for indentation on all lines. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- arch/i386/Kconfig | 17 + arch/x86_64/Kconfig | 21 +++-- 2 files changed, 20 insertions(+), 18 deletions(-) --- linux-2.6.23-rc5-git1.orig/arch/i386/Kconfig +++ linux-2.6.23-rc5-git1/arch/i386/Kconfig @@ -820,12 +820,13 @@ config CRASH_DUMP depends on HIGHMEM help Generate crash dump after being started by kexec. - This should be normally only set in special crash dump kernels + This should be normally only set in special crash dump kernels which are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. The crash dump kernel must be compiled - to a memory address not used by the main kernel or BIOS using - PHYSICAL_START. + to a memory address not used by the main kernel or BIOS using + PHYSICAL_START, or it must be built as a relocatable image + (CONFIG_RELOCATABLE=y). For more details see Documentation/kdump/kdump.txt config PHYSICAL_START @@ -871,17 +872,17 @@ config PHYSICAL_START Don't change this unless you know what you are doing. config RELOCATABLE - bool "Build a relocatable kernel(EXPERIMENTAL)" + bool "Build a relocatable kernel (EXPERIMENTAL)" depends on EXPERIMENTAL help This builds a kernel image that retains relocation information - so it can be loaded someplace besides the default 1MB. + so it can be loaded someplace besides the default 1MB. The relocations tend to make the kernel binary about 10% larger, - but are discarded at runtime. + but are discarded at runtime. One use is for the kexec on panic case where the recovery kernel - must live at a different physical address than the primary - kernel. + must live at a different physical address than the primary + kernel. config PHYSICAL_ALIGN hex "Alignment value to which kernel should be aligned" --- linux-2.6.23-rc5-git1.orig/arch/x86_64/Kconfig +++ linux-2.6.23-rc5-git1/arch/x86_64/Kconfig @@ -575,17 +575,18 @@ config CRASH_DUMP bool "kernel crash dumps (EXPERIMENTAL)" depends on EXPERIMENTAL help - Generate crash dump after being started by kexec. - This should be normally only set in special crash dump kernels - which are loaded in the main kernel with kexec-tools into - a specially reserved region and then later executed after - a crash by kdump/kexec. The crash dump kernel must be compiled + Generate crash dump after being started by kexec. + This should be normally only set in special crash dump kernels + which are loaded in the main kernel with kexec-tools into + a specially reserved region and then later executed after + a crash by kdump/kexec. The crash dump kernel must be compiled to a memory address not used by the main kernel or BIOS using - PHYSICAL_START. - For more details see Documentation/kdump/kdump.txt + PHYSICAL_START, or it must be built as a relocatable image + (CONFIG_RELOCATABLE=y). + For more details see Documentation/kdump/kdump.txt config RELOCATABLE - bool "Build a relocatable kernel(EXPERIMENTAL)" + bool "Build a relocatable kernel (EXPERIMENTAL)" depends on EXPERIMENTAL help Builds a relocatable kernel. This enables loading and running @@ -596,8 +597,8 @@ config RELOCATABLE must live at a different physical address than the primary kernel. - Note: If CONFIG_RELOCATABLE=y, then kernel run from the address - it has been loaded at and compile time physical address + Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address + it has been loaded at and the compile time physical address (CONFIG_PHYSICAL_START) is ignored. config PHYSICAL_START - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]
Re: [discuss] [patch 3/5] Use extended crashkernel command line on x86_64
* Yinghai Lu <[EMAIL PROTECTED]> [2007-09-09 19:27]: > > > > +#ifdef CONFIG_KEXEC > ... > > CONFIG_KEXEC or CONFIG_CRASH_DUMP? Good question. The crashkernel parameter was CONFIG_KEXEC before, and I also wondered why, but I didn't change this because maybe there's some reason I don't know. Vivek, do you know why this was CONFIG_KEXEC? Thanks, Bernhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Maple bus support for the Sega Dreamcast
On Sun, 9 Sep 2007 19:36:52 +0100
"Adrian McMenamin" <[EMAIL PROTECTED]> wrote:
> Fair enough.
>
> > > +
> > > +void maple_add_packet(struct mapleq *mq)
> > > +{
> > > + list_add((struct list_head *) mq, _waitq);
> > > +}
> >
> > for example this list.. what makes sure that no 2 pieces of code
> > muck with it at the same time?
> >
> >
>
> Because everything is handled by one kernel thread on a uniprocessor
> machine.
hmmm still. Once you look at it from any other place... preempt etc
etc... it's sort of playing russian roulette with an empty gun, but
without checking that the gun is actually empty... at some point
someone may accidentally leave a bullet in ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checksyscalls.sh: ignore restart_syscall
On Sun, 9 Sep 2007, Sam Ravnborg wrote:
> On Sun, Sep 09, 2007 at 11:34:11AM +0200, Geert Uytterhoeven wrote:
> > checksyscalls.sh: ignore restart_syscall, which is not needed on m68k and
> > blackfin.
>
> If only these archs does not care then just stick that
> #define __IGNORE_...
> in the arch specifc unistd.h files.
> x86_64 and other do this already.
>
> Try:
> ls include/asm*/unistd.h | xargs grep IGNORE
Ah, thanks, I didn't know this trick was being used...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options
On Sun, 2007-09-09 at 15:46 +0200, Andi Kleen wrote: > Thanks. How about a fix for the other problem (ACPI_NUMA- PM) too? > I don't want to just hard-select it until I understand what happened between 2.6.22.6 and current git to make ACPI selectable without PM. Personally, I think ACPI should be independent of PM anyway (at least as it is displayed and selectable in the user interface. Obviously there may be functional relationships between them). There is a "C" in ACPI, after all, and some of that "C" doesn't really have anything to do with power management. James /\ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] powerpc: proper defconfig for crosscompiles
On Sun, Sep 09, 2007 at 08:21:17PM +0200, Adrian Bunk wrote: > The trick for finding the right defconfig is neat, but you forgot to > provide an i686_defconfig. ;-) > > More seriously, cross compiling the defconfig is often useful, e.g. for > testing the compilation of patches that touch multiple architectures, > and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is > non-empty. Thanks - much appreciated. Acked-by: Sam Ravnborg <[EMAIL PROTECTED]> Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Maple bus support for the Sega Dreamcast
On 09/09/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Sun, 9 Sep 2007 17:46:54 +0100
> "Adrian McMenamin" <[EMAIL PROTECTED]> wrote:
>
> > This patch adds support for Sega's proprietary Maple bus - which is
> > required to support the Dreamcast's peripherals.
>
>
> First of all, I'm a little concerned about the lack of locking that
> this driver seems to have; what guarantees the integrity of the lists
> used in the driver?
>
Could you explain what you think the issue is? The lists are only
handled by this driver and not anything else.
> Second, you have a lot of use of likely() and unlikely(); so much that I
> think it's wy overkill. The code it's in generally isn't hotpath, and gcc
> also does a pretty decent job without giving these hints in general.
>
>
>
Fair enough.
> > +
> > +void maple_add_packet(struct mapleq *mq)
> > +{
> > + list_add((struct list_head *) mq, _waitq);
> > +}
>
> for example this list.. what makes sure that no 2 pieces of code muck with it
> at the same time?
>
>
Because everything is handled by one kernel thread on a uniprocessor machine.
> > +static irqreturn_t maplebus_dma_interrupt(int irq, void *dev_id)
> > +{
> > + /* Load everything into the bottom half */
> > + schedule_work(_dma_process);
> > + return IRQ_HANDLED;
> > +}
>
> I wonder if you want to at least check if the work was really for you before
> returning IRQ_HANDLED
>
It's *always* for me - this is an end of DMA interrupt for the bus.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: tsc timer related problems/questions
On Sun, 9 Sep 2007 20:17:28 +0200 (CEST) Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Sep 9 2007 17:49, Arjan van de Ven wrote: > >> > >> Question: Why are only Intel CPUs considered as stable? Could > >> there be implemented a more sophisticated heuristic, that actually > >> does some tests for tsc stability? > > > >on AMD multi-socket systems, afaik the tsc is not synchronized > >between packages. On Intel the tsc is derived from the FSB which is > >shared between the packages. > > Also, the TSC is not necessarily constant wrt. CPU clock speed. > If your program stalls, the core may reduce frequency and hence > TSC values are not linear to time anymore. > that depends on the CPU generation; most current cpus have constant-rate tscs (at least constant wrt their own concept of time, but at least independent of cpu frequency)... it gets more iffy on idle; on deep idle the tsc tends to stop ;( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Maple bus support for the Sega Dreamcast - keyboard support
On Sun, 9 Sep 2007 18:01:26 +0100 "Adrian McMenamin" <[EMAIL PROTECTED]> wrote: > This patch adds support for the SEGA Dreamcast keyboard. > > Following suggestions from the inout maintainer it has been somewhat > rewritten since the previous posting > (http://lkml.org/lkml/2007/9/4/168). Hi, this driver in general is quite clean as well; I have only one suggestion for improvement. Right now you use a semaphore for locking, while all you really use it for is mutex semantics, I think it would be a good idea to convert the driver to use the actual mutex primitive; this will buy you a lot of extra automatic checking for bugs... Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Maple bus support for the Sega Dreamcast
On Sun, 9 Sep 2007 17:46:54 +0100
"Adrian McMenamin" <[EMAIL PROTECTED]> wrote:
> This patch adds support for Sega's proprietary Maple bus - which is
> required to support the Dreamcast's peripherals.
Hi,
in general the code looks clean; great job on that.
A few suggestions and comments to hopefully help this driver to become
even better:
First of all, I'm a little concerned about the lack of locking that
this driver seems to have; what guarantees the integrity of the lists
used in the driver?
Second, you have a lot of use of likely() and unlikely(); so much that I think
it's wy overkill. The code it's in generally isn't hotpath, and gcc also
does a pretty decent job without giving these hints in general.
> +
> +void maple_add_packet(struct mapleq *mq)
> +{
> + list_add((struct list_head *) mq, _waitq);
> +}
for example this list.. what makes sure that no 2 pieces of code muck with it
at the same time?
> +static struct maple_device *maple_alloc_dev(int port, int unit)
> +{
> + struct maple_device *dev;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (unlikely(!dev))
> + return NULL;
> +
> + dev->port = port;
> + dev->unit = unit;
> + dev->mq = maple_allocq(dev);
> +
> + if (unlikely(!dev->mq)) {
this unlikely isn't needed; gcc basically assumes that NULL pointer checks are
unlikely anyway...
> +
> +static int setup_maple_commands(struct device *device, void *ignored)
> +{
> + struct maple_device *maple_dev = to_maple_dev(device);
> +
> + if (likely(maple_dev->interval > 0)) {
> + if (likely(jiffies > maple_dev->when)) {
this is I think a small bug; it is for sure unsafe against jiffies wrapping...
please consider using the time_before() and time_after() helpers which will
make this comparison safe wrt jiffies wrapping. The same is true for all other
jiffies use in the driver...
> +static irqreturn_t maplebus_dma_interrupt(int irq, void *dev_id)
> +{
> + /* Load everything into the bottom half */
> + schedule_work(_dma_process);
> + return IRQ_HANDLED;
> +}
I wonder if you want to at least check if the work was really for you before
returning IRQ_HANDLED
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Sun, 9 Sep 2007 19:02:54 +0100 Denys Vlasenko <[EMAIL PROTECTED]> wrote: > Why is all this fixation on "volatile"? I don't think > people want "volatile" keyword per se, they want atomic_read() to > _always_ compile into an memory-accessing instruction, not register > access. and ... why is that? is there any valid, non-buggy code sequence that makes that a reasonable requirement? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] powerpc: proper defconfig for crosscompiles
The trick for finding the right defconfig is neat, but you forgot to provide an i686_defconfig. ;-) More seriously, cross compiling the defconfig is often useful, e.g. for testing the compilation of patches that touch multiple architectures, and this patch therefore chooses g5_defconfig if $(CROSS_COMPILE) is non-empty. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- 0b0e6e0e3a16f48348cb9c40ef1bb55ef42f92eb diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 2065138..a39bac4 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -35,7 +35,11 @@ endif export CROSS32CC CROSS32AS CROSS32LD CROSS32AR CROSS32OBJCOPY +ifeq ($(CROSS_COMPILE),) KBUILD_DEFCONFIG := $(shell uname -m)_defconfig +else +KBUILD_DEFCONFIG := g5_defconfig +endif ifeq ($(CONFIG_PPC64),y) OLDARCH:= ppc64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tsc timer related problems/questions
On Sep 9 2007 17:49, Arjan van de Ven wrote: >> >> Question: Why are only Intel CPUs considered as stable? Could there be >> implemented a more sophisticated heuristic, that actually does some >> tests for tsc stability? > >on AMD multi-socket systems, afaik the tsc is not synchronized between >packages. On Intel the tsc is derived from the FSB which is shared >between the packages. Also, the TSC is not necessarily constant wrt. CPU clock speed. If your program stalls, the core may reduce frequency and hence TSC values are not linear to time anymore. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
On Friday 17 August 2007 17:48, Linus Torvalds wrote: > > On Fri, 17 Aug 2007, Nick Piggin wrote: > > > > That's not obviously just taste to me. Not when the primitive has many > > (perhaps, the majority) of uses that do not require said barriers. And > > this is not solely about the code generation (which, as Paul says, is > > relatively minor even on x86). I prefer people to think explicitly > > about barriers in their lockless code. > > Indeed. > > I think the important issues are: > > - "volatile" itself is simply a badly/weakly defined issue. The semantics >of it as far as the compiler is concerned are really not very good, and >in practice tends to boil down to "I will generate so bad code that >nobody can accuse me of optimizing anything away". > > - "volatile" - regardless of how well or badly defined it is - is purely >a compiler thing. It has absolutely no meaning for the CPU itself, so >it at no point implies any CPU barriers. As a result, even if the >compiler generates crap code and doesn't re-order anything, there's >nothing that says what the CPU will do. > > - in other words, the *only* possible meaning for "volatile" is a purely >single-CPU meaning. And if you only have a single CPU involved in the >process, the "volatile" is by definition pointless (because even >without a volatile, the compiler is required to make the C code appear >consistent as far as a single CPU is concerned). > > So, let's take the example *buggy* code where we use "volatile" to wait > for other CPU's: > > atomic_set(, 0); > while (!atomic_read()) > /* nothing */; > > > which generates an endless loop if we don't have atomic_read() imply > volatile. > > The point here is that it's buggy whether the volatile is there or not! > Exactly because the user expects multi-processing behaviour, but > "volatile" doesn't actually give any real guarantees about it. Another CPU > may have done: > > external_ptr = kmalloc(..); > /* Setup is now complete, inform the waiter */ > atomic_inc(); > > but the fact is, since the other CPU isn't serialized in any way, the > "while-loop" (even in the presense of "volatile") doesn't actually work > right! Whatever the "atomic_read()" was waiting for may not have > completed, because we have no barriers! Why is all this fixation on "volatile"? I don't think people want "volatile" keyword per se, they want atomic_read() to _always_ compile into an memory-accessing instruction, not register access. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
On 9/7/07, Zhang Wei <[EMAIL PROTECTED]> wrote:
> The driver implements DMA engine API for Freescale MPC85xx DMA
> controller, which could be used for MEM<-->MEM, IO_ADDR<-->MEM
> and IO_ADDR<-->IO_ADDR data transfer.
> The driver supports the Basic mode of Freescale MPC85xx DMA controller.
> The MPC85xx processors supported include MPC8540/60, MPC8555, MPC8548,
> MPC8641 and so on.
> The support for MPC83xx(MPC8349, MPC8360) is experimental.
>
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
> ---
Greetings,
Please copy me on any updates to this driver, drivers/dma, or crypto/async_tx.
Below are a few review comments...
Regards,
Dan
> +/**
> + * fsl_dma_alloc_descriptor - Allocate descriptor from channel's DMA pool.
> + *
> + * Return - The descriptor allocated. NULL for failed.
> + */
> +static struct fsl_desc_sw *fsl_dma_alloc_descriptor(
> + struct fsl_dma_chan *fsl_chan,
> + gfp_t flags)
> +{
> + dma_addr_t pdesc;
> + struct fsl_desc_sw *desc_sw;
> +
> + desc_sw = dma_pool_alloc(fsl_chan->desc_pool, flags, );
> + if (desc_sw) {
> + memset(desc_sw, 0, sizeof(struct fsl_desc_sw));
> + dma_async_tx_descriptor_init(_sw->async_tx,
> + _chan->common);
> + desc_sw->async_tx.tx_set_src = fsl_dma_set_src;
> + desc_sw->async_tx.tx_set_dest = fsl_dma_set_dest;
> + desc_sw->async_tx.tx_submit = fsl_dma_tx_submit;
> + INIT_LIST_HEAD(_sw->async_tx.tx_list);
> + desc_sw->async_tx.phys = pdesc;
> + }
> +
> + return desc_sw;
> +}
I suggest pre-allocating the descriptors:
1/ It alleviates the need to initialize these async_tx fields which never change
2/ The GFP_ATOMIC allocation can be removed.
iop-adma gets by with one PAGE_SIZE buffer (128 descriptors).
[..]
> +static irqreturn_t fsl_dma_chan_do_interrupt(int irq, void *data)
> +{
> + struct fsl_dma_chan *fsl_chan = (struct fsl_dma_chan *)data;
> + dma_addr_t stat;
> +
> + stat = get_sr(fsl_chan);
> + dev_dbg(fsl_chan->device->dev, "event: channel %d, stat = 0x%x\n",
> + fsl_chan->id, stat);
> + set_sr(fsl_chan, stat); /* Clear the event register */
> +
> + stat &= ~(FSL_DMA_SR_CB | FSL_DMA_SR_CH);
> + if (!stat)
> + return IRQ_NONE;
> +
> + /* If the link descriptor segment transfer finishes,
> +* we will recycle the used descriptor.
> +*/
> + if (stat & FSL_DMA_SR_EOSI) {
> + dev_dbg(fsl_chan->device->dev, "event: End-of-segments
> INT\n");
> + dev_dbg(fsl_chan->device->dev, "event: clndar 0x%016llx, "
> + "nlndar 0x%016llx\n", (u64)get_cdar(fsl_chan),
> + (u64)get_ndar(fsl_chan));
> + stat &= ~FSL_DMA_SR_EOSI;
> + fsl_chan_ld_cleanup(fsl_chan, 1);
> + }
> +
> + /* If it current transfer is the end-of-transfer,
> +* we should clear the Channel Start bit for
> +* prepare next transfer.
> +*/
> + if (stat & (FSL_DMA_SR_EOLNI | FSL_DMA_SR_EOCDI)) {
> + dev_dbg(fsl_chan->device->dev, "event: End-of-link INT\n");
> + stat &= ~FSL_DMA_SR_EOLNI;
> + fsl_chan_xfer_ld_queue(fsl_chan);
> + }
> +
> + if (stat)
> + dev_dbg(fsl_chan->device->dev, "event: unhandled sr 0x%02x\n",
> + stat);
> +
> + dev_dbg(fsl_chan->device->dev, "event: Exit\n");
> + tasklet_hi_schedule(_tasklet);
> + return IRQ_HANDLED;
> +}
This driver implements locking and callbacks inconsistently with how
it is done in ioatdma and iop-adma. The big changes are that all
locks have been upgraded from 'spin_lock_bh' to 'spin_lock_irqsave',
and async_tx callbacks can happen in irq context. I would like to
keep everything in bottom-half context to lessen the restrictions on
what async_tx clients can perform in their callback routines. What
are the implications of moving 'fsl_chan_ld_cleanup' to the tasklet
and changing the 'tasklet_hi_schedule' to 'tasklet_schedule'?
[..]
> +static struct dma_chan *of_find_dma_chan_by_phandle(phandle phandle)
> +{
> + struct device_node *np;
> + struct dma_chan *chan;
> + struct fsl_dma_device *fdev;
> +
> + np = of_find_node_by_phandle(phandle);
> + if (!np || !of_device_is_compatible(np->parent, "fsl,dma"))
> + return NULL;
> +
> + fdev = dev_get_drvdata(_find_device_by_node(np->parent)->dev);
> +
> + list_for_each_entry(chan, >common.channels, device_node)
> + if (to_of_device(to_fsl_chan(chan)->chan_dev)->node == np)
> + return chan;
> + return NULL;
> +}
>
Re: [RFC][Intel-IOMMU] Fix for IOMMU early crash
On Mon, Sep 10, 2007 at 08:43:59AM -0700, Keshavamurthy, Anil S wrote: > On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote: > > On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote: > > > > > Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash > > > > This patch feels like a huge hack. See below. > > You seem to be jumping to conclusion without going in detail. The > pci_dev struct contains pointer to sysdata, which in turn points to > the copy of its parent's bus sysdata. So technically speaking we > can eliminate sysdata pointer from pci_dev struct which is what one > portion of this patch does. ... provided nothing relies on this relationship or the existence of the pci_dev's sysdata. Have you audited every architecture's use of the sysdata pointers? > > > This patch removes sysdata from pci_dev struct and creates a new > > > field called sys_data which is exclusively used by IOMMU driver to > > > keep its per device context pointer. > > > > Hmpf, why is this needed? with the pci_sysdata work that recently went > > into mainline we have a void *iommu member in pci_sysdata which should > > be all that's needed. Please elaborate if it's not enough for your > > needs. > I looked at your patch and it was not suitable because I need to > store iommu private pointer in pci_dev Could you elaborate on why you need this? I'm assuming it's for the per-device IOMMU page tables? > and not in the pci_bus. So I have added a new member sys_data in the > pci_dev struct. I can change the name from sys_dev to iomu_priv to > clear the confusion. Do let me know. Well, you should be able to just use the pci_dev's ->sysdata (that's what it's there for after all!) but you might need to make it point to a structure if it's shared, the same way we did with the bus's ->sysdata. I agree that just having it point to the bus's ->sysdata is not very useful *but* there may be code in the kernel that relies on it (Calgary did until very recently...) so it would have to be audited first. Cheers, Muli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/22] advansys: Eliminate prototypes
On Sun, Sep 09, 2007 at 11:29:34AM -0400, Jeff Garzik wrote: > What thoughts, if any, have been given to post-patch code arrangement, > besides eliminating prototypes? > This always struck me as a counterproductive exercise when taken by > itself. Eliminating prototypes saves me from an extra go round of the edit-compile testcycle when I change the signature of a function. It probably doesn't matter to you, but it adds a small amount of annoyance to my day. > Sure, prototypes were eliminated, but was code packed together > in an efficient way afterwards? Ideally hot path code should be close > together, ditto for various other things like error handling code. I tried to place functions close together that seemed like they were called together and called from each other. It's hard to know, of course, because GCC will make its own decisions about inlining, for example. At the end of the day, this is an NP problem. I remmber Nat writing grope and using simulated annealing to solve the problem. > Without further explanation or details about your post-patch analysis, > how do we even know the new code arrangement doesn't negatively impact > i-cache overall? We don't, but the new layout is more likely to be good than bad, given how I did the rearrangement (delete prototypes, try to compile. Move called function to before its first caller. Repeat). Plus, with all the other changes I'm making, there's a serious reduction in driver size. I haven't compared i-cache sizes specifically, but I'm mostly removing code, so it should be better. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [possible regression] 2.6.22 reiserfs/libata sporadically hangs on resume from hibernation
On Sunday 09 September 2007, Rafael J. Wysocki wrote: > On Sunday, 9 September 2007 16:00, Andrey Borzenkov wrote: > > On Sunday 01 July 2007, Rafael J. Wysocki wrote: > > > On Saturday, 30 June 2007 06:59, Andrey Borzenkov wrote: > > > > Since 2.6.18 I do not have suspend to RAM; now I am starting to lose > > > > suspend to disk :) > > > > > > > > Environment - vanilla kernel (2.6.22-rc6 currently + squashfs + > > > > single pata_ali patch to switch off DMA on CD-ROM), single root on > > > > reiserfs, libata with pata_ali driver. > > > > > > > > Until 2.6.22-rc I never had problems with hibernation. With 2.6.22-rc > > > > system hung at least once in every rcX. Up to rc6 those lockups were > > > > absolutely silent (black screen without reaction to any key). In rc6 > > > > I just got something different. After resume I got on screem: > > > > > > > > swsusp: Marking nosave pages: 0009f000-0010 > > > > swsusp: Basic memory bitmaps created > > > > swsusp: Basic memory bitmaps freed > > > > > > > > After that it just sits there doing nothing. Ther was brief sound of > > > > HDD but I suspect it was related more to power-on. System was > > > > responding to power-on button press: > > > > > > > > ACPI Error (event-0305): No installed handler for fixed event > > > > [0002 20070125] > > > > > > > > And SysRq was functioning. > > > > > > That probably means that there's a deadlock somewhere in there. > > > > > > > Unfortunately I do not have serial console so I > > > > copy manually stacks from several last screens of output; I have > > > > tried to make a photo but right now my kbluetooth is refusing to work > > > > at all so I cannot transfer them :( (but I suspect quality would be > > > > too bad anyway) > > > > > > > > laptop_mode D > > > > io_schedule+0xe/0x20 > > > > > > Looks suspicious to me. Can you identify what line of code this points > > > to? > > > > > > > sync_buffer+0x35/0x40 > > > > __wait_on_bit+0x45/0x70 > > > > out_of_line_wait_on_bit+0x6c/0x80 > > > > __wait_on_buffer+0x27/0x30 > > > > search_by_key+0x15e/0x1250 [reiserfs] > > > > reiserfs_read_locked_inode+0x64/0x570 [reiserfs] > > > > reiserfs_iget+0x7e/0xa0 [reiserfs] > > > > reiserfs_lookup+0xc7/0x120 [reiserfs] > > > > do_lookup+0x138/0x180 > > > > __link_path_walk+0x787/0xce0 > > > > link_path_walk+0x44/0xc0 > > > > path_walk+0x18/0x20 > > > > do_path_lookup_0x88/0x210 > > > > __path_lookupintent_open+0x4d/0x90 > > > > path_lookup_open+0x1f/0x30 > > > > open_exec+0x28/0xb0 > > > > do_execve+0x36/0x1d0 > > > > sys_execve+0x2e/0x80 > > > > sysenter_past_esp+0x5f/0x99 > > > > > > > > 90clock D > > > > __mutex_lock_slow_path+0xa1/0x290 > > > > mutex_lock+0x21/0x30 > > > > do_lookup+0xa1/0x180 > > > > __link_path_walk+0x44/0xc0 > > > > path_walk+0x18/0x20 > > > > do_path_lookup+0x78/0x210 > > > > __user_walk_fd+0x38/0x50 > > > > vfs_stat_fd+0x21/0x50 > > > > vfs_stat+0x11/0x20 > > > > sys_stat64+0x14/0x30 > > > > sysenter_past_esp+0x5f/0x99 > > > > > > > > alsactl D > > > > io_schedule+0xe/0x20 > > > > > > Same here. Hmm. > > > > > > > sync_page+0x35/0x40 > > > > __wait_on_bit_lock+0x3f/0x70 > > > > __lock_page+0x68/0x70 > > > > filemap_nopage+0x16c/0x300 > > > > __handle_mm_faul+0x1d7/0x610 > > > > do_page_fault+0x1d7/0x610 > > > > error_code+0x6a/0x70 > > > > padzero+0x1f/0x30 > > > > load_elf_binary+0x743/0x1ab0 > > > > search_binary_handler+0x7b/0x1f0 > > > > do_execve+0x137/0x1d0 > > > > sys_execve+0x2e/0x80 > > > > sysenter_past_esp+0x5f/0x90 > > > > > > > > After that I could remount, sync and reboot using SysRq (well, after > > > > reboot it still insisted on replaying insane number of transactions > > > > so may be it did *not* remount / ro after all). Before reboot there > > > > was brief output that resembled lockdep warnings, but it went too > > > > fast to be readable. > > > > > > > > usual stuff follows > > > > > > I see you're using CFQ as the default IO scheduler. Can you please > > > switch to AS and see if that changes anything? > > > > I just had the same lockup on resume using AS with 2.6.23-rc5. > > Hm. Does your root partition sit on reiserfs? yes - "single root on reiserfs" signature.asc Description: This is a digitally signed message part.
Re: broken ACPI NUMA config option
James C. Georgas wrote: On Sat, 2007-08-09 at 22:00 -0700, Randy Dunlap wrote: For example, you would only need to specify one "select" directive in X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system would then recursively walk up ACPI_NUMA's dependency hierarchy, turning on what it needed. That is highly desirable IMO. Not having that is one of the things that makes using 'select' "evil." Have you looked at the code and given any thought to implementing this? I'd like to take a run at it. The only issue I foresee is what to do about multiple OR dependencies. There are some kconfig options that depend on at least one of a set of specified dependencies. For example, is ARCH_SPARSEMEM_ENABLE selectable if only one of NUMA || EXPERIMENTAL is selected? So do we abort, select one, or select all dependencies? It's a logical OR, meaning one or more of them is enabled. I expect that there are some places that enabling all dependencies would very much be the wrong thing to do, and choosing only one is just a wild guess, so it looks like you would have to abort, with a helpful message. Maybe I'm misunderstanding the usage of || here though. I'm assuming inclusive OR. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
