Some fixes for compat ioctl
Subsystems (16)
PATCH 1/1 Some fixes for compat ioctl
While doing some compat_ioctl conversions I noticed a few issues in compat_sys_ioctl:
- It is not completely compatible to old ->ioctl because the traditional common ioctls are not checked before it. I added a check for those. The main advantage is that the handler now works the same as a traditional handler even when it returns -EINVAL
- The private socket ioctl check should only apply for sockets.
- There was a security hook missing. Drawback is that it uses the same hook now, and the LSM module cannot distingush between 32bit and 64bit clients. But it'll have to live with that for now.
fs/ioctl.c renamed from fs/ioctl.c-o +4 -0
@@ -78,6 +78,10 @@ } +/* +* When you add any new common ioctls to the switches above and below +* please update compat_sys_ioctl() too. +*/ asmlinkage long sys_ioctl (unsigned int fd,unsigned int cmd,unsigned long arg) {struct file * filp;
fs/compat.c renamed from fs/compat.c-o +43 -10
84 lines not on this page · raw message
Hi, Andi!
Quoting r. Andi Kleen ([email protected]) "[PATCH] Some fixes for compat ioctl":
Quoted 6 lines
While doing some
compat_ioctlconversions I noticed a few issues incompat_sys_ioctl:- It is not completely compatible to old ->ioctl because the traditional common ioctls are not checked before it.
How is this different from what we have for compat_sys_ioctl in 2.6.10? Or is this an old bug?
Quoted 2 lines
I added
a check for those.
Cant we just add them to fs/compat_ioctl.c instead, and be done?
Quoted 3 lines
The main advantage is that the handler
now works the same as a traditional handler even when it returns-EINVAL
We still need the conversion functions in fs/compat_ioctl.c, I think. If that is true, for some devices the handler only almost works if it returns -EINVAL, and maybe its best not to encourage this. I have another idea: maybe, lets move the unlocked_ioctl handler up so that it, too, is required to return -NOIOCTLCMD?
I would argue it also may improve ioctl performance by a small margin, since it is the unlocked_ioctl/compat_ioctl that do the "real" work.
I plan to send, separately, a patch that does this. Please comment.
Quoted 2 lines
- The private socket ioctl check should only apply for sockets.
Its an old issue, isnt it? And probably better split in a separate patch?
Quoted 3 lines
- There was a security hook missing. Drawback is that it uses the same hook now, and the LSM module cannot distingush between 32bit and 64bit clients. But it'll have to live with that for now.
It seems it is still missing for compat_ioctl. No? I am sending a patch to fix this separately.
MST
PATCH 1/5 compat_ioctl call seems to miss a security hook
In reply to Andi KleenAttached patch is against 2.6.11-rc1-bk5
Add a missing security hook for compatibility ioctl.
fs/compat.c +5 -0
@@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigneif (!filp) goto out; +/* RED-PEN how should LSM module know it's handling 32bit? */ + error =security_file_ioctl (filp, cmd, arg); +if (error) + goto out_fput; +if (filp->f_op && filp->f_op->compat_ioctl) { error = filp->f_op->compat_ioctl (filp, cmd, arg);if (error != -ENOIOCTLCMD )
Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
fs/compat.c asmlinkage long compat_sys_ioctl(unsigne · line 444
Quoted 12 lines · * Michael S. Tsirkin ([email protected]) wrote:
diff -rup
linux-2.6.10-orig/fs/compat.clinux-2.6.10-ioctl-sym/fs/compat.cfs/compat.c +5
-0@@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigneif (!filp) goto out; +/* RED-PEN how should LSM module know it's handling 32bit? */ + error =security_file_ioctl (filp, cmd, arg); +if (error) + goto out_fput; +
This is now called twice in the plain do_ioctl: case. A generic vfs handler could alleviate that.
===== fs/ioctl.c 1.15 vs edited =====
fs/ioctl.c +20 -13
@@ -77,21 +77,10 @@ static int file_ioctl(struct file *filp,return do_ioctl (filp, cmd, arg); } - -asmlinkage long sys_ioctl (unsigned int fd,unsigned int cmd,unsigned long arg) +int vfs_ioctl (struct file *filp,unsigned int fd,unsigned int cmd,unsigned long arg) { -struct file * filp;unsigned int flag; -int on, error = -EBADF ; -int fput_needed; - - filp =fget_light (fd, &fput_needed); -if (!filp) - goto out; - - error =security_file_ioctl (filp, cmd, arg); -if (error) - goto out_fput; +int on, error =0 ;switch (cmd) {case FIOCLEX :
@@ -157,6 +146,24 @@ asmlinkage long sys_ioctl(unsigned int f error =do_ioctl (filp, cmd, arg);break ; } +return error; +} + +asmlinkage long sys_ioctl (unsigned int fd,unsigned int cmd,unsigned long arg) +{ +struct file * filp; +int error = -EBADF ; +int fput_needed; + + filp =fget_light (fd, &fput_needed); +if (!filp) + goto out; + + error =security_file_ioctl (filp, cmd, arg); +if (error) + goto out_fput; + + error =vfs_ioctl (filp, fd, cmd, arg); out_fput:fput_light (filp, fput_needed); out:
===== fs/compat.c 1.48 vs edited =====
fs/compat.c +6 -1
@@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigneif (!filp) goto out; +/* RED-PEN how should LSM module know it's handling 32bit? */ + error =security_file_ioctl (filp, cmd, arg); +if (error) + goto out_fput; +if (filp->f_op && filp->f_op->compat_ioctl) { error = filp->f_op->compat_ioctl (filp, cmd, arg);if (error != -ENOIOCTLCMD )
@@ -477,7 +482,7 @@ asmlinkage long compat_sys_ioctl(unsigneup_read (&ioctl32_sem); do_ioctl: - error =sys_ioctl (fd, cmd, arg); + error =vfs_ioctl (filp, fd, cmd, arg); out_fput:fput_light (filp, fput_needed); out:
===== include/linux/fs.h 1.373 vs edited =====
include/linux/fs.h +2 -0
@@ -1564,6 +1564,8 @@ extern int vfs_stat(char __user *, strucextern int vfs_lstat (char __user *,struct kstat *);extern int vfs_fstat (unsigned int ,struct kstat *); +extern int vfs_ioctl (struct file *,unsigned int ,unsigned int ,unsigned long ); +extern struct file_system_type *get_fs_type (const char *name);extern struct super_block *get_super (struct block_device *);extern struct super_block *user_get_super (dev_t );
Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
Hello!
Quoting r. Chris Wright ([email protected]) "Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook":
Quoted 8 lines · * Michael S. Tsirkin ([email protected]) wrote:
Quoted 7 lines
diff -rup
linux-2.6.10-orig/fs/compat.clinux-2.6.10-ioctl-sym/fs/compat.cfs/compat.c +0
-0@@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigneif (!filp) goto out;
Quoted 8 lines
fs/compat.c asmlinkage long compat_sys_ioctl(unsigne · line 444
Quoted 5 lines
fs/compat.c +5
-0+/* RED-PEN how should LSM module know it's handling 32bit? */ + error =security_file_ioctl (filp, cmd, arg); +if (error) + goto out_fput; +This is now called twice in the plain
do_ioctl: case. A generic vfs handler could alleviate that.
I'm all for it, but the way the patch below works, we could end up calling ->ioctl or ->unlocked_ioctl from the compat syscall, and we dont want that.
MST
Quoted 88 lines
=====
fs/ioctl.c1.15 vs edited =====fs/ioctl.c +20
-13@@ -77,21 +77,10 @@ static int file_ioctl(struct file *filp,return do_ioctl (filp, cmd, arg); } - -asmlinkage long sys_ioctl (unsigned int fd,unsigned int cmd,unsigned long arg) +int vfs_ioctl (struct file *filp,unsigned int fd,unsigned int cmd,unsigned long arg) { -struct file * filp;unsigned int flag; -int on, error = -EBADF ; -int fput_needed; - - filp =fget_light (fd, &fput_needed); -if (!filp) - goto out; - - error =security_file_ioctl (filp, cmd, arg); -if (error) - goto out_fput; +int on, error =0 ;switch (cmd) {case FIOCLEX :@@ -157,6 +146,24 @@ asmlinkage long sys_ioctl(unsigned int f error =do_ioctl (filp, cmd, arg);break ; } +return error; +} + +asmlinkage long sys_ioctl (unsigned int fd,unsigned int cmd,unsigned long arg) +{ +struct file * filp; +int error = -EBADF ; +int fput_needed; + + filp =fget_light (fd, &fput_needed); +if (!filp) + goto out; + + error =security_file_ioctl (filp, cmd, arg); +if (error) + goto out_fput; + + error =vfs_ioctl (filp, fd, cmd, arg); out_fput:fput_light (filp, fput_needed); out:=====
fs/compat.c1.48 vs edited =====fs/compat.c +6
-1@@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigneif (!filp) goto out; +/* RED-PEN how should LSM module know it's handling 32bit? */ + error =security_file_ioctl (filp, cmd, arg); +if (error) + goto out_fput; +if (filp->f_op && filp->f_op->compat_ioctl) { error = filp->f_op->compat_ioctl (filp, cmd, arg);if (error != -ENOIOCTLCMD )@@ -477,7 +482,7 @@ asmlinkage long compat_sys_ioctl(unsigneup_read (&ioctl32_sem); do_ioctl: - error =sys_ioctl (fd, cmd, arg); + error =vfs_ioctl (filp, fd, cmd, arg); out_fput:fput_light (filp, fput_needed); out:=====
include/linux/fs.h1.373 vs edited =====include/linux/fs.h +2
-0@@ -1564,6 +1564,8 @@ extern int vfs_stat(char __user *, strucextern int vfs_lstat (char __user *,struct kstat *);extern int vfs_fstat (unsigned int ,struct kstat *); +extern int vfs_ioctl (struct file *,unsigned int ,unsigned int ,unsigned long ); +extern struct file_system_type *get_fs_type (const char *name);extern struct super_block *get_super (struct block_device *);extern struct super_block *user_get_super (dev_t );
Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
Quoted 3 lines · * Michael S. Tsirkin ([email protected]) wrote:
I'm all for it, but the way the patch below works, we could end up calling ->ioctl or ->unlocked_ioctl from the compat syscall, and we dont want that.
Hmm, I didn't actually change how those are called. So if it's an issue, then I don't think this patch introduces it.
thanks,
-chris
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
Quoting r. Chris Wright ([email protected]) "Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook":
Quoted 10 lines · * Michael S. Tsirkin ([email protected]) wrote:
Quoted 3 lines
I'm all for it, but the way the patch below works, we could end up calling ->ioctl or ->unlocked_ioctl from the compat syscall, and we dont want that.
Hmm, I didn't actually change how those are called. So if it's an issue, then I don't think this patch introduces it.
thanks,
-chris
Sorry, you are right, we go to do_ioctl only if there are no callbacks.
Patch looks good to go to me.
mst
Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
Quoted 11 lines · * Michael S. Tsirkin ([email protected]) wrote:
Quoting r. Chris Wright ([email protected]) "Re: [PATCH 1/5]
compat_ioctlcall seems to miss a security hook":Quoted 7 lines · * Michael S. Tsirkin ([email protected]) wrote:
Quoted 3 lines
I'm all for it, but the way the patch below works, we could end up calling ->ioctl or ->unlocked_ioctl from the compat syscall, and we dont want that.
Hmm, I didn't actually change how those are called. So if it's an issue, then I don't think this patch introduces it.
Sorry, you are right, we go to
do_ioctlonly if there are no callbacks.
I suppose there is one case (not introduced by the patch). Not sure if it's even a problem though:
t->cmd matches, yet NULL t->handler. This will fall-thru to the do_ioctl: case. I assume NULL handler is for case where no conversion is needed, so it's not a problem? At least some callers of register_ioctl32_conversion() pass NULL handler.
thanks,
-chris
Signature · 1 line
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
Quoting r. Chris Wright ([email protected])
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
I'm all for it, but the way the patch below works, we could end up calling ->ioctl or ->unlocked_ioctl from the compat syscall, and we dont want that.
Hmm, I didn't actually change how those are called. So if it's an issue, then I don't think this patch introduces it.
Sorry, you are right, we go to
do_ioctlonly if there are no callbacks.
Quoted 7 lines
I suppose there is one case (not introduced by the patch). Not sure if it's even a problem though:
t->cmdmatches, yet NULLt->handler. This will fall-thru to thedo_ioctl: case. I assume NULL handler is for case where no conversion is needed, so it's not a problem? At least some callers ofregister_ioctl32_conversion()pass NULL handler.
Yes, this is an by design, you put in a NULL handler to say: I dont need conversions, call my regular handlers. Some in-tree drivers do this.
MST
PATCH 2/5 socket ioctl fix (from Andi)
In reply to Andi KleenAttached patch is against 2.6.11-rc1-bk5.
It is split out from Andi's big patch.
It is really unchanged so I dont put a signed-off-by here.
SIOCDEVPRIVATE ioctl command only applies to socket descriptors.
fs/compat.c +2 -1
@@ -454,7 +460,8 @@ asmlinkage long compat_sys_ioctl(unsigne }up_read (&ioctl32_sem); -if (cmd >=SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE +15 )) { +if (S_ISSOCK (filp->f_dentry->d_inode->i_mode) && + cmd >=SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE +15 )) { error =siocdevprivate_ioctl (fd, cmd, arg); }else {static int count;
Re: [PATCH 2/5] socket ioctl fix (from Andi)
Quoted 12 lines · Michael S. Tsirkin
Attached patch is against 2.6.11-rc1-bk5.
It is split out from Andi's big patch.
It is really unchanged so I dont put a signed-off-by here.Signed-off-by Andi Kleen <[email protected]>SIOCDEVPRIVATE ioctl command only applies to socket descriptors.
diff -rup
linux-2.6.10-orig/fs/compat.clinux-2.6.10-ioctl-sym/fs/compat.c
fs/compat.c asmlinkage long compat_sys_ioctl(unsigne · line 465
Quoted 7 lines
fs/compat.c +2
-1@@ -454,7 +460,8 @@ asmlinkage long compat_sys_ioctl(unsigne }up_read (&ioctl32_sem); -if (cmd >=SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE +15 )) { +if (S_ISSOCK (filp->f_dentry->d_inode->i_mode) && + cmd >=SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE +15 )) { error =siocdevprivate_ioctl (fd, cmd, arg);
Maybe this should move into a new sock_compat_ioctl() instead?
Re: [PATCH 2/5] socket ioctl fix (from Andi)
Quoted 7 lines
fs/compat.c asmlinkage long compat_sys_ioctl(unsigne · line 465
Quoted 4 lines
fs/compat.c +2
-1-if (cmd >=SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE +15 )) { +if (S_ISSOCK (filp->f_dentry->d_inode->i_mode) && + cmd >=SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE +15 )) { error =siocdevprivate_ioctl (fd, cmd, arg);Maybe this should move into a new
sock_compat_ioctl()instead?
Seems like overkill for 3 lines of code.
-Andi
PATCH 3/5 make common ioctls apply for compat.
In reply to Andi KleenAttached patch is against 2.6.11-rc1-bk5
A piece is copied from Andi's patch, too. No idea if his SOB should be here too. Here it is just in case.
Make common ioctls apply for compat_ioctl.
fs/compat_ioctl.c +8 -0
@@ -3165,6 +3165,14 @@ static int do_ncp_setprivatedata(unsigne#endif #ifdef DECLARES +HANDLE_IOCTL(FIOCLEX,NULL) +HANDLE_IOCTL(FIONCLEX,NULL) +HANDLE_IOCTL(FIONBIO,NULL) +HANDLE_IOCTL(FIOASYNC,NULL) +HANDLE_IOCTL(FIOQSIZE,NULL) +HANDLE_IOCTL(FIBMAP,NULL) +HANDLE_IOCTL(FIGETBSZ,NULL) +HANDLE_IOCTL(FIONREAD,NULL) HANDLE_IOCTL(MEMREADOOB32, mtd_rw_oob) HANDLE_IOCTL(MEMWRITEOOB32, mtd_rw_oob)#ifdef CONFIG_NET
fs/ioctl.c +4 -1
@@ -77,7 +72,10 @@ static int file_ioctl(struct file *filp,return do_ioctl (filp, cmd, arg); } - +/* +* When you add any new common ioctls to the switches above and below +* please update compat_ioctl.c too. +*/ asmlinkage long sys_ioctl (unsigned int fd,unsigned int cmd,unsigned long arg) {struct file * filp;
PATCH 4/5 reminder comment about register_ioctl32_conversion
In reply to Andi KleenThis is just a split off from Andi's patch, so I didnt add my SOB here.
Since its too early to deprecate (un)register_ioctl32_conversion, add a comment for that time when we do.
fs/compat.c +1 -0
@@ -447,6 +452,7 @@ asmlinkage long compat_sys_ioctl(unsigne (!filp->f_op->ioctl && !filp->f_op->unlocked_ioctl)) goto do_ioctl; +/* When register_ioctl32_conversion is gone remove this lock! -AK */ down_read (&ioctl32_sem);for (t = ioctl32_hash_table[ioctl32_hash (cmd)]; t; t = t->next) {if (t->cmd == cmd)
PATCH 5/5 symmetry between compat_ioctl and unlocked_ioctl
In reply to Andi KleenMake unlocked_ioctl and compat_ioctl behave symmetrically - check them first thing, and always require returning ENOIOCTLCMD on error from unlocked_ioctl, same as we do for compat_ioctl. This also makes it possible to override *all* ioctl commands, and hopefully may enable some speed ups on the data path.
fs/ioctl.c +7 -6
@@ -24,12 +24,7 @@ static long do_ioctl(struct file *filp,if (!filp->f_op) goto out; -if (filp->f_op->unlocked_ioctl) { - error = filp->f_op->unlocked_ioctl (filp, cmd, arg); -if (error == -ENOIOCTLCMD ) - error = -EINVAL ; - goto out; - }else if (filp->f_op->ioctl) { +if (filp->f_op->ioctl) {lock_kernel (); error = filp->f_op->ioctl (filp->f_dentry->d_inode, filp, cmd, arg);
@@ -93,6 +91,12 @@ asmlinkage long sys_ioctl(unsigned int fif (error) goto out_fput; +if (filp->f_op && filp->f_op->unlocked_ioctl) { + error = filp->f_op->unlocked_ioctl (filp, cmd, arg); +if (error != -ENOIOCTLCMD ) + goto out_fput; + } +switch (cmd) {case FIOCLEX :set_close_on_exec (fd,1 );
2.6.11-rc2-mm1
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Changes since 2.6.11-rc1-mm2:
linus.patch
bk-acpi.patch
bk-agpgart.patch
bk-alsa.patch
bk-arm.patch
bk-cifs.patch
bk-driver-core.patch
bk-drm.patch
bk-drm-via.patch
bk-i2c.patch
bk-ide-dev.patch
bk-input.patch
bk-dtor-input.patch
bk-netdev.patch
bk-ntfs.patch
bk-scsi-rc-fixes.patch
bk-usb.patch
bk-xfs.patch
Latest versions of various bk trees
-acpi-build-fix-99.patch
-mips-default-mlock-limit-fix.patch
-shared_policy_replace-fix.patch -generic_file_buffered_write-handle-partial-dio.patch -cputimeh-seems-to-assume-hz==1000.patch -ppc32-fix-pmac-kernel-build-with-oprofile.patch -spinlocking-fixes.patch
-fix-config_agp-depencies.patch -ioctl-compatibility-for-tiocmiwait-and-tiocgicount.patch -cls_api-build-fix.patch -alsa-conversion-to-compat_ioctl-kconfig.patch -alsa-conversion-to-compat_ioctl-alsa-pcm-api.patch -alsa-conversion-to-compat_ioctl-alsa-apis.patch -ac97-audio-support-for-intel-ich7-2611-rc1.patch -alps-touchpad-detection-fix.patch
-scsi-ncr53c9x-fixes.patch
-uninline-mod_page_state.patch
-fix-audit-control-message-checks.patch -fix-audit-control-message-checks-tidy.patch -selinux-add-netlink-message-types-for-the-tc-action-code.patch -ppc32-update-cpu-state-save-restore.patch -ppc32-add-missing-prototype.patch -ppc32-system-platform_device-description-discovery-and-management.patch -ppc32-infrastructure-changes-to-mpc85xx-sub-arch-from-ocp-to-platform_device.patch -ppc32-convert-boards-from-using-ocp-to-platform_device.patch -ppc32-convert-gianfar-ethernet-driver-from-using-an-ocp-to-platform_device.patch -ppc32-remove-cli-sti-in-arch-ppc-4xx_io-serial_siccc.patch -ppc32-remove-cli-sti-in-arch-ppc-8xx_io-cs4218_tdmc.patch -ppc32-remove-cli-sti-in-arch-ppc-8xx_io-fecc.patch -ppc32-remove-cli-sti-in-arch-ppc-platforms-apus_setupc.patch -ppc32-remove-cli-sti-in-arch-ppc-platforms-pal4_setupc.patch -ppc32-remove-cli-sti-in-arch-ppc-syslib-m8xx_setupc.patch -ppc32-remove-cli-sti-in-arch-ppc-syslib-qspan_pcic.patch -ppc32-mpc8xx-tlb-miss-vs-tlb-error-fix.patch -ppc32-update_process_times-simplification.patch -ppc32-add-defconfigs-for-85xx-boards.patch -ppc64-remove-config_irq_all_cpus.patch -ppc64-pci-eeh-documentation.patch -ppc64-ppc-cleanup-pci-skipping.patch -ppc64-minimum-hashtable-size.patch -ppc64-remove-some-unused-iseries-functions.patch -fix-xenu-kernel-crash-in-dmi_iterate.patch -x86-use-cpumask_t-instead-of-unsigned-long.patch -i386-init_intel_cacheinfo-can-be-__init.patch -arch-i386-kernel-signalc-fix-err-test-twice.patch -fix-num_online_nodes-warning-on-numa-q.patch -x86_64-fix-cmp-with-interleaving.patch -x86_64-fix-flush-race-on-context-switch.patch -i386-x86-64-fix-smp-nmi-watchdog-race.patch -x86-64-fix-pud-typo-in-ioremap.patch -x86-64-fix-do_suspend_lowlevel.patch -x86-64-clean-up-cpuid-level-detection.patch -kprobes-x86_64-memory-allocation-changes.patch -h8-300-defconfig-update.patch
-h8-300-mm-update.patch -swsusp-remove-on2-algorithm-in-page-relocation.patch -driver-model-pass-pm_message_t-down-to-pci-drivers.patch -uml-provide-an-arch-specific-define-for-register-file-size.patch -uml-provide-some-initcall-definitions-for-userspace-code.patch -uml-provide-a-release-method-for-the-ubd-driver.patch -uml-allow-ubd-devices-to-provide-partial-end-blocks.patch -uml-change-for_each_cpu-to-for_each_online_cpu.patch -uml-eliminate-unhandled-sigprof-on-halt.patch -uml-fix-__pud_alloc-definition-to-match-the-declaration.patch -uml-fix-a-stack-corruption-crash.patch -uml-define-__have_arch_cmpxchg-on-x86.patch -file_tableexpand_files-code-cleanup.patch -file_tableexpand_files-code-cleanup-remove-debug.patch -minor-ext3-speedup.patch -move-read-only-and-immutable-checks-into-permission.patch -factor-out-common-code-around-follow_link-invocation.patch -radio-typhoon-use-correct-module_param-data-type.patch -avoid-sparse-warning-due-to-time-interpolator.patch -allow-all-architectures-to-set-config_debug_preempt.patch -binfmt_elf-allow-mips-to-overrid-e_flags.patch -remove-bogus-softirq_pending-usage-in-cris.patch -switch-frw-to-use-local_soft_irq_pending.patch -scripts-referencepl-treat-built-ino-as-conglomerate.patch -vgacon-fixes-to-help-font-restauration-in-x11.patch -use-official-unicodes-for-dec-vt-characters.patch -ext3-commit-superblock-before-panicking.patch -consolidate-arch-specific-resourceh-headers.patch -use-wno-pointer-sign-for-gcc-40.patch -fix-init_sighand-warning-on-mips.patch
-add-page_offset-to-mmh.patch
-minor-ipmi-driver-updates.patch
-completion-api-additions.patch -convert-xfs-to-unlocked_ioctl-and-compat_ioctl.patch -some-fixes-for-compat-ioctl.patch -convert-infiniband-mad-driver-to-compat-unlocked_ioctl.patch -support-compat_ioctl-for-block-devices.patch -convert-cciss-to-compat_ioctl.patch -add-compat_ioctl-to-frame-buffer-layer.patch -convert-sis-fb-driver-to-compat_ioctl.patch -convert-dv1394-driver-to-compat_ioctl.patch -convert-video1394-driver-to-compat_ioctl.patch -convert-amdtp-driver-to-compat_ioctl.patch -fat-kill-fatfs_symsc.patch -fat-merge-msdos_fs_isbh-into-msdos_fsh.patch -fat-is_badchar-is_replacechr-is_skipchar-cleanup.patch -fat-is_badchar-is_replacechr-is_skipchar-cleanup-cleanup.patch -fat-return-better-error-codes-from.patch -fat-manually-inline-shortname_info_to_lcase.patch -fat-use-vprintk-instead-of-snprintf-with-static.patch -fat-kill-unnecessary-kmap.patch -fat-fs-fat-cachec-make-__fat_access-static.patch -fat-lindent-fs-msdos-nameic.patch
-fat-lindent-fs-vfat-nameic.patch -fat-lindent-fs-vfat-nameic-fix.patch
-fat-fs-fat-cleanup.patch
-fat-reserved-clusters-cleanup.patch -fat-show-current-nls-config-even-if-its-default.patch -lock-initializer-cleanup-ppc.patch -lock-initializer-cleanup-m32r.patch -lock-initializer-cleanup-video.patch -lock-initializer-cleanup-ide.patch -lock-initializer-cleanup-sound.patch -lock-initializer-cleanup-sh.patch -lock-initializer-cleanup-ppc64.patch -lock-initializer-cleanup-security.patch -lock-initializer-cleanup-core.patch -lock-initializer-cleanup-media-drivers.patch -lock-initializer-cleanup-block-devices.patch -lock-initializer-cleanup-s390.patch -lock-initializer-cleanup-usermode.patch -lock-initializer-cleanup-scsi.patch -lock-initializer-cleanup-sparc.patch -lock-initializer-cleanup-v850.patch -lock-initializer-cleanup-i386.patch -lock-initializer-cleanup-drm.patch -lock-initializer-cleanup-firewire.patch -lock-initializer-cleanup-arm26.patch -lock-initializer-cleanup-m68k.patch -lock-initializer-cleanup-network-drivers.patch -lock-initializer-cleanup-mtd.patch -lock-initializer-cleanup-x86_64.patch -lock-initializer-cleanup-filesystems.patch -lock-initializer-cleanup-ia64.patch -lock-initializer-cleanup-raid.patch -lock-initializer-cleanup-isdn.patch -lock-initializer-cleanup-parisc.patch -lock-initializer-cleanup-sparc64.patch -lock-initializer-cleanup-arm.patch -lock-initializer-cleanup-misc-drivers.patch -lock-initializer-cleanup-alpha.patch -lock-initializer-cleanup-character-devices.patch -lock-initializer-cleanup-drivers-serial.patch -lock-initializer-cleanup-frv.patch
-typo-in-arch-x86_64-kconfig.patch
Merged
+dib3000mc-build-fix.patch
compile fix
+fbdev-screen-corruption-fix.patch
fbdev screen corruption fix
+mips-fixed-conflicting-types.patch
MIPS build fix
+bug-in-io_destroy-fs-aioc1248.patch
AIO fix
+oprofile-falling-back-on-timer-interrupt-mode.patch
opofile timer-mode fallback fix
+compat-ioctl-security-hook-fixup.patch
Restore missing security hook
-bk-acpi-revert-20041210.patch
Hopefully this is no longer needed
+hda_intel-fix.patch
ALSA build fix
+tpm_msc-build-fix.patch
+tpm_atmel-build-fix.patch
Fix Greg's stuff
+driver-model-more-pm_message_t-conversion.patch +driver-model-more-pci_choose_states-are-needed.patch
power management/driver model updates
+kbuild-no-redundant-srctree-in-tags-file.patch
`make tags' fix
+mm-oom-killer-tunable.patch +mm-keep-balance-between-different-classzones.patch +mm-fix-several-oom-killer-bugs.patch +mm-convert-memdie-to-an-atomic-thread-bitflag.patch +make-used_math-smp-safe.patch +mm-adjust-dirty-threshold-for-lowmem-only-mappings.patch +mm-truncate-smp-race-fix.patch
Various page allocator and oom killer fixes/updates
+simpler-topdown-mmap-layout-allocator.patch
Simplify the virtual address layout logic
+alloc_zeroed_user_highpage-to-fix-the-clear_user_highpage-issue.patch
Fix clear_user_highpage on architectures with funky caches
+smc91x-power-down-phy-on-suspend.patch
+e100-locking-up-netconsole.patch
net driver fixes
+ppc32-add-defconfigs-for-85xx-boards-updated.patch
ppc32 defconfig updates
+ppc32-allow-usage-of-gen550-on-platforms-that-do-not-define.patch +ppc32-missing-call-to-ioremap-in-pci_iomap.patch +ppc32-fix-pci2-io-space-mapping-on-cds.patch +ppc32-add-support-for-pegasos-machines.patch
ppc32 updates
+ppc64-limit-segment-tables-on-up-kernels.patch +ppc64-xmon-data-breakpoints-on-partitioned-systems.patch +ppc64-fix-in_be64-definition.patch +ppc64-clear-msr_ri-earlier-in-syscall-exit-path.patch +ppc64-replace-schedule_timeout-in-iseries_pci_reset.patch +ppc64-replace-schedule_timeout-in-pseries_cpu_die.patch +ppc64-replace-schedule_timeout-in-__cpu_up.patch +ppc64-replace-schedule_timeout-in-die.patch +ppc64-trivial-cleanup-eeh_region.patch +ppc64-sparse-fixes-for-cpu-feature-constants.patch +ppc64-use-kref-for-device_node-refcounting.patch +ppc64-allow-eeh-to-be-disabled.patch +ppc64-disable-some-boot-wrapper-debug.patch +ppc64-problem-disabling-sysvipc.patch +ppc64-enable-virtual-ethernet-and-virtual-scsi.patch
ppc64 updates
+x86-remove-unused-function.patch
cleanup
+x86_64-remove-centaur-mtrr-support.patch
+x86_64-remove-duplicated-includes.patch
+x86_64-enlarge-northbridge-numa-scan-mask.patch
+x86_64-remove-earlyprintk-help.patch
+x86_64-speed-up-suspend.patch
x86_64 update
+h8300-fix-warning.patch
+h8300-makefile-update.patch
H8/300 updates
+swsusp-comment-fix.patch
Fix a comment
+kill-softirq_pending-fix.patch
Remove softirq_pending()
+ext2-ext3-block-allocator-startup-fix.patch
Fix ext2/ext3 block allocator buglet
+ext3-quota-leak-fix.patch
Fix error-path quota leak
+ext3-fix-ea-in-inode-default-acl-creation.patch +ext2-ext3-acls-remove-the-number-of-acl-entries-limit.patch
EA/ACL fixes
+jbd-journal-overflow-fix.patch
+jbd-journal-overflow-fix-fixes.patch
+jbd-fix-against-journal-overflow.patch
+jbd-fix-against-journal-overflow-tidies.patch
+jbd-log-space-management-optimization.patch
Various JBD corner-case fixes
+i4l-new-hfc_usb-driver-version.patch
+i4l-hfc-4s-and-hfc-8s-driver.patch
i4l updates
+i810_audio-offset-lvi-from-civ-to-avoid-stalled-start.patch
Audio driver fix
+configurable-delay-before-mounting-root-device.patch
Add `delay=' boot option
+fs-mbcachec-remove-an-unused-wait-queue-variable.patch
Dead code
+device-mapper-fix-mirror-log-type-module-ref-count.patch +device-mapper-remove-unused-bs_bio_init.patch +device-mapper-add-presuspend-hook.patch +device-mapper-optionally-bypass-a-bdget.patch +device-mapper-fix-tb-stripe-data-corruption.patch
DM updates
+arm26-new-maintainer-of-archimedes-floppy-and-hard-disk-drivers.patch
MAINTAINERS update
+problems-disabling-sysctl.patch
Add sys32_sysctl stub
+genhd-rename-device_init.patch
Namespace cleanup
+fix-race-between-the-nmi-code-and-the-cmos-clock.patch
Fix race between concurrent accesses to the x86 CMOS chip
+infiniband-core-compat_ioctl-conversion-minor-fixes.patch +infiniband-mthca-more-arbel-mem-free-support.patch +infiniband-mthca-implement-modifying-port-attributes.patch +infiniband-core-fix-port-capability-enums-bit-order.patch +infiniband-mthca-dont-write-ecr-in-msi-x-mode.patch +infiniband-mthca-pass-full-process_mad-info-to-firmware.patch +infiniband-mthca-optimize-event-queue-handling.patch +infiniband-mthca-test-irq-routing-during-initialization.patch +infiniband-ipoib-remove-uses-of-yield.patch +infiniband-core-add-issm-userspace-support.patch +infiniband-mthca-clean-up-ioremap-request_region-usage.patch +infiniband-mthca-remove-x86-sse-pessimization.patch
infiniband updates
+random-pt4-create-new-rol32-ror32-bitops.patch +random-pt4-use-them-throughout-the-tree.patch +random-pt4-kill-the-sha-variants.patch +random-pt4-cleanup-sha-interface.patch +random-pt4-move-sha-code-to-lib.patch +random-pt4-replace-sha-with-faster-version.patch +random-pt4-replace-sha-with-faster-version-fix.patch +random-pt4-update-cryptolib-to-use-sha-fro-lib.patch +random-pt4-move-halfmd4-to-lib.patch +random-pt4-kill-duplicate-halfmd4-in-ext3-htree.patch +random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix.patch +random-pt4-simplify-and-shrink-syncookie-code.patch +random-pt4-move-syncookies-to-net.patch +random-pt4-move-other-tcp-ip-bits-to-net.patch
More random driver slash-and-burn
+posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch +posix-timers-high-resolution-cpu-clocks-for-posix-clock_-syscalls.patch +posix-timers-fix-posix-timers-signals-lock-order.patch +posix-timers-cpu-clock-support-for-posix-timers.patch +make-itimer_real-per-process.patch +make-itimer_prof-itimer_virtual-per-process.patch +make-rlimit_cpu-sigxcpu-per-process.patch
Bunch of timekeeping updates, including per-thread cpu clocks. Needs a patched glibc to test it.
+mips-fixed-ltt-build-errors.patch
+ltt-doesnt-build-on-x86_64.patch
Fix ltt-induced MIPS build errors
+nfsacl-protocol-extension-for-nfsv3.patch +nfsacl-return-enosys-for-rpc-programs-that-are-unavailable.patch +nfsacl-add-missing-eopnotsupp-=-nfs3err_notsupp-mapping-in-nfsd.patch +nfsacl-allow-multiple-programs-to-listen-on-the-same-port.patch +nfsacl-allow-multiple-programs-to-share-the-same-transport.patch +nfsacl-lazy-rpc-receive-buffer-allocation.patch +nfsacl-encode-and-decode-arbitrary-xdr-arrays.patch +nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix.patch +nfsacl-add-noacl-nfs-mount-option.patch +nfsacl-infrastructure-and-server-side-of-nfsacl.patch +nfsacl-solaris-nfsacl-workaround.patch +nfsacl-client-side-of-nfsacl.patch +nfsacl-acl-umask-handling-workaround-in-nfs-client.patch +nfsacl-cache-acls-on-the-nfs-client-side.patch
ACLs for ther NFS client.
-jbd-remove-livelock-avoidance.patch
Dropped - this optimisation was never right and I lost interest in it.
+sched-account-rt_tasks-as-iso_ticks.patch
SCHED_ISO fix
+videotext-ioctls-changed-to-use-_io-macros.patch
+video-arv-remove-casts.patch
+video-w9966-remove-casts.patch
+video-zr36120-remove-casts.patch
+v4l-video-buf-update.patch
+v4l2-tuner-api-update.patch
+v4l-tuner-update.patch
+v4l-add-tveeprom-module.patch
+v4l-tvaudio-update.patch
+v4l-bttv-ir-input-driver-update.patch
+v4l-bttv-update.patch
+v4l-saa7134-module.patch
v4l updates.
+crashdump-reserving-backup-region-for-kexec-based.patch
crashdump-via-kexec update
+fix-architecture-names-in-hugetlbpagetxt.patch
Documentation fix
+fuse-fix-llseek-on-device.patch
FUSE fix
+kernel-configsc-make-a-variable-static.patch +kernel-forkc-make-mm_cachep-static.patch +kernel-kallsymsc-make-some-code-static.patch +mm-page-writebackc-remove-an-unused-function.patch +mm-shmemc-make-a-struct-static.patch +make-loglevels-in-init-mainc-a-little-more-sane.patch +isicom-use-null-for-pointer.patch +remove-bouncing-email-address-of-hennus-bergman.patch +cirrusfbc-make-some-code-static.patch +matroxfb_basec-make-some-code-static.patch +asiliantfbc-make-some-code-static.patch +i386-apic-kconfig-cleanups.patch +security-seclvlc-make-some-code-static.patch +drivers-block-elevatorc-make-two-functions-static.patch +drivers-block-rdc-make-two-variables-static.patch +loopc-make-two-functions-static.patch +remove-bouncing-email-address-of-thomas-hood.patch +fs-adfs-dir_fc-remove-an-unused-function.patch +drivers-char-moxac-if-0-an-unused-function.patch
Little fixes.
number of patches in -mm: 534
number of changesets in external trees: 386
number of patches in -mm only: 517
total patches: 903
All 534 patches:
linus.patch
dib3000mc-build-fix.patch
dib3000mc build fix
fbdev-screen-corruption-fix.patch
fbdev: screen corruption fix
mips-fixed-conflicting-types.patch
mips: fixed conflicting types
bug-in-io_destroy-fs-aioc1248.patch
Fix BUG in io_destroy
oprofile-falling-back-on-timer-interrupt-mode.patch
oprofile: falling back on timer interrupt mode
compat-ioctl-security-hook-fixup.patch
compat ioctl security hook fixup
ia64-acpi-build-fix.patch
ia64 acpi build fix
ia64-config_apci_numa-fix.patch
ia64 CONFIG_APCI_NUMA fix
bk-acpi.patch
acpi-sleep-while-atomic-during-s3-resume-from-ram.patch
acpi: sleep-while-atomic during S3 resume from ram
acpi-report-errors-in-fanc.patch
ACPI: report errors in fan.c
acpi-flush-tlb-when-pagetable-changed.patch
acpi: flush TLB when pagetable changed
acpi-kfree-fix.patch
a
bk-agpgart.patch
bk-alsa.patch
hda_intel-fix.patch
hda_intel macro expansion fix
bk-arm.patch
bk-cifs.patch
bk-driver-core.patch
tpm_msc-build-fix.patch
tpm_msc-build-fix
tpm_atmel-build-fix.patch
tpm_atmel build fix
driver-model-more-pm_message_t-conversion.patch
driver model: more pm_message_t conversion
driver-model-more-pci_choose_states-are-needed.patch
driver model: more pci_choose_state()s are needed
bk-drm.patch
bk-drm-via.patch
bk-i2c.patch
bk-ide-dev.patch
ide-dev-build-fix.patch
ide-dev-build-fix
bk-input.patch
disable-sidewinder-debug-messages.patch
Disable Sidewinder debug messages
bk-dtor-input.patch
kbuild-no-redundant-srctree-in-tags-file.patch
kbuild: no redundant srctree in tags file
seagate-st3200822as-sata-disk-needs-to-be-in-sil_blacklist-as-well.patch
Seagate ST3200822AS SATA disk needs to be in sil_blacklist as well
bk-netdev.patch
bk-ntfs.patch
prevent-pci_name_bus-buffer-overflows.patch
prevent pci_name_bus() buffer overflows
maintainers-add-entry-for-qla2xxx-driver.patch
MAINTAINERS: add entry for qla2xxx driver.
bk-scsi-rc-fixes.patch
bk-usb.patch
bk-xfs.patch
mm.patch
add -mmN to EXTRAVERSION
fix-smm-failures-on-e750x-systems.patch
fix SMM failures on E750x systems
mm-oom-killer-tunable.patch
mm: oom-killer tunable
mm-keep-balance-between-different-classzones.patch
mm: rework lower-zone protection initialisation
mm-fix-several-oom-killer-bugs.patch
mm: fix several oom killer bugs
mm-convert-memdie-to-an-atomic-thread-bitflag.patch
mm: convert memdie to an atomic thread bitflag
make-used_math-smp-safe.patch
make used_math SMP-safe
mm-adjust-dirty-threshold-for-lowmem-only-mappings.patch
mm: adjust dirty threshold for lowmem-only mappings
mm-truncate-smp-race-fix.patch
mm: truncate SMP race fix
vm-pageout-throttling.patch
vm: pageout throttling
orphaned-pagecache-memleak-fix.patch
orphaned pagecache memleak fix
swapspace-layout-improvements.patch
swapspace-layout-improvements
simpler-topdown-mmap-layout-allocator.patch
simpler topdown mmap layout allocator
alloc_zeroed_user_highpage-to-fix-the-clear_user_highpage-issue.patch
alloc_zeroed_user_highpage() to fix the clear_user_highpage issue
make-tree_lock-an-rwlock.patch
make mapping->tree_lock an rwlock
must-fix.patch
must fix lists update
must fix list update
mustfix update
must-fix update
mustfix lists
pcnet32-79c976-with-fiber-optic.patch
pcnet32: 79c976 with fiber optic fix
add-omap-support-to-smc91x-ethernet-driver.patch
Add OMAP support to smc91x Ethernet driver
b44-bounce-buffer-fix.patch
b44 bounce buffering fix
netpoll-fix-napi-polling-race-on-smp.patch
netpoll: fix NAPI polling race on SMP
tun-tan-arp-monitor-support.patch
tun/tap ARP monitor support
atmel_cs-add-support-lg-lw2100n-wlan-pcmcia-card.patch
atmel_cs: Add support LG LW2100N WLAN PCMCIA card
smc91x-power-down-phy-on-suspend.patch
smc91x: power down PHY on suspend
e100-locking-up-netconsole.patch
e100 locking up netconsole.
ppc32-add-defconfigs-for-85xx-boards-updated.patch
ppc32: Add defconfigs for 85xx boards -- updated
ppc32-pmac-sleep-support-update.patch
ppc32: pmac sleep support update
add-try_acquire_console_sem.patch
Add try_acquire_console_sem
update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch
update aty128fb sleep/wakeup code for new powermac changes
radeonfb-massive-update-of-pm-code.patch
radeonfb: massive update of PM code
radeonfb-build-fix.patch
radeonfb-build-fix
ppc32-allow-usage-of-gen550-on-platforms-that-do-not-define.patch
ppc32: allow usage of gen550 on platforms that do not define SERIAL_PORT_DFNS
ppc32-missing-call-to-ioremap-in-pci_iomap.patch
ppc32: missing call to ioremap in pci_iomap()
ppc32-fix-pci2-io-space-mapping-on-cds.patch
ppc32: fix PCI2 IO space mapping on CDS
ppc32-add-support-for-pegasos-machines.patch
ppc32: Add support for Pegasos machines
ppc64-limit-segment-tables-on-up-kernels.patch
ppc64: limit segment tables on UP kernels
ppc64-xmon-data-breakpoints-on-partitioned-systems.patch
ppc64: xmon data breakpoints on partitioned systems
ppc64-fix-in_be64-definition.patch
ppc64: fix in_be64 definition
ppc64-clear-msr_ri-earlier-in-syscall-exit-path.patch
ppc64: clear MSR_RI earlier in syscall exit path
ppc64-replace-schedule_timeout-in-iseries_pci_reset.patch
ppc64: replace schedule_timeout in iSeries_pci_reset
ppc64-replace-schedule_timeout-in-pseries_cpu_die.patch
ppc64: replace schedule_timeout in pSeries_cpu_die
ppc64-replace-schedule_timeout-in-__cpu_up.patch
ppc64: replace schedule_timeout in __cpu_up
ppc64-replace-schedule_timeout-in-die.patch
ppc64: replace schedule_timeout in die
ppc64-trivial-cleanup-eeh_region.patch
ppc64: trivial cleanup: EEH_REGION
ppc64-sparse-fixes-for-cpu-feature-constants.patch
ppc64: sparse fixes for cpu feature constants
ppc64-use-kref-for-device_node-refcounting.patch
ppc64: use kref for device_node refcounting
ppc64-allow-eeh-to-be-disabled.patch
ppc64: allow EEH to be disabled
ppc64-disable-some-boot-wrapper-debug.patch
ppc64: disable some boot wrapper debug
ppc64-problem-disabling-sysvipc.patch
ppc64: problem disabling SYSVIPC
ppc64-enable-virtual-ethernet-and-virtual-scsi.patch
ppc64: enable virtual ethernet and virtual scsi
ppc64-reloc_hide.patch
agpgart-allow-multiple-backends-to-be-initialized.patch
agpgart: allow multiple backends to be initialized agpgart-allow-multiple-backends-to-be-initialized fix
agpgart: add bridge assignment missed in agp_allocate_memory x86_64 agp failure fix
agpgart-add-agp_find_bridge-function.patch
agpgart: add agp_find_bridge function
agpgart-allow-drivers-to-allocate-memory-local-to.patch
agpgart: allow drivers to allocate memory local to the bridge
drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch
drm: add support for new multiple agp bridge agpgart api
fb-add-support-for-new-multiple-agp-bridge-agpgart-api.patch
fb: add support for new multiple agp bridge agpgart api
agpgart-add-bridge-parameter-to-driver-functions.patch
agpgart: add bridge parameter to driver functions
superhyway-bus-support.patch
SuperHyway bus support
x86-no-interrupts-from-secondary-cpus-until-officially-online.patch
x86: no interrupts from secondary CPUs until officially online
x86-remove-unused-function.patch
x86: Remove unused function
x86_64-remove-centaur-mtrr-support.patch
x86_64: remove centaur mtrr support
x86_64-remove-duplicated-includes.patch
x86_64: remove duplicated includes
x86_64-enlarge-northbridge-numa-scan-mask.patch
x86_64: Enlarge northbridge numa scan mask
x86_64-remove-earlyprintk-help.patch
x86_64: Remove earlyprintk help
x86_64-speed-up-suspend.patch
x86_64: Speed up suspend
xen-vmm-4-add-ptep_establish_new-to-make-va-available.patch
Xen VMM #4: add ptep_establish_new to make va available
xen-vmm-4-return-code-for-arch_free_page.patch
Xen VMM #4: return code for arch_free_page
xen-vmm-4-return-code-for-arch_free_page-fix.patch
Get rid of arch_free_page() warning
xen-vmm-4-runtime-disable-of-vt-console.patch
Xen VMM #4: runtime disable of VT console
xen-vmm-4-has_arch_dev_mem.patch
Xen VMM #4: HAS_ARCH_DEV_MEM
xen-vmm-4-split-free_irq-into-teardown_irq.patch
Xen VMM #4: split free_irq into teardown_irq
h8300-fix-warning.patch
h8300: fix warning
h8300-makefile-update.patch
h8300: makefile update
swsusp-comment-fix.patch
swsusp: fix buggy comment
wacom-tablet-driver.patch
wacom tablet driver
force-feedback-support-for-uinput.patch
Force feedback support for uinput
kmap_atomic-takes-char.patch
kmap_atomic takes char*
kmap_atomic-takes-char-fix.patch
kmap_atomic-takes-char-fix
kmap_atomic-fallout.patch
kmap_atomic fallout
kunmap-fallout-more-fixes.patch
kunmap-fallout-more-fixes
make-sysrq-f-call-oom_kill.patch
make sysrq-F call oom_kill()
allow-admin-to-enable-only-some-of-the-magic-sysrq-functions.patch
Allow admin to enable only some of the Magic-Sysrq functions
sort-out-pci_rom_address_enable-vs-ioresource_rom_enable.patch
Sort out PCI_ROM_ADDRESS_ENABLE vs IORESOURCE_ROM_ENABLE
irqpoll.patch
irqpoll
poll-mini-optimisations.patch
poll: mini optimisations
mtrr-size-and-base-debug.patch
mtrr size-and-base debugging
cleanup-vc-array-access.patch
cleanup vc array access
remove-console_macrosh.patch
remove console_macros.h
merge-vt_struct-into-vc_data.patch
merge vt_struct into vc_data
kill-softirq_pending.patch
kill softirq_pending()
kill-softirq_pending-fix.patch
kill-softirq_pending fix
clean-up-uts_release-usage.patch
clean up UTS_RELEASE usage
3c59x-ethtool-provide-nic-specific-stats.patch
3c59x ethtool: provide NIC-specific stats
ext2-ext3-block-allocator-startup-fix.patch
ext2/ext3: block allocator startup fix
ext3-quota-leak-fix.patch
ext3: fix error-path quota leak
ext3-ea-no-lock-needed-when-freeing-inode.patch
ext3/ea: no lock needed when freeing inode
ext3-ea-set-the-ext3_feature_compat_ext_attr-for-in-inode-xattrs.patch
ext3/ea: set the EXT3_FEATURE_COMPAT_EXT_ATTR for in-inode xattrs
ext3-ea-documentation-fix.patch
ext3/ea: documentation fix
ext3-ea-fix-i_extra_isize-check.patch
ext3/ea: ix i_extra_isize check
ext3-ea-disallow-in-inode-attributes-for-reserved-inodes.patch
ext3/ea: disallow in-inode attributes for reserved inodes
ext3-fix-ea-in-inode-default-acl-creation.patch
ext3: fix ea-in-inode default ACL creation
ext2-ext3-acls-remove-the-number-of-acl-entries-limit.patch
ext2/ext3 ACLs: remove the number of acl entries limit
jbd-journal-overflow-fix.patch
JBD: journal overflow fix
jbd-journal-overflow-fix-fixes.patch
jbd-journal-overflow-fix-fixes
jbd-fix-against-journal-overflow.patch
JBD: fix against journal overflow
jbd-fix-against-journal-overflow-tidies.patch
jbd-fix-against-journal-overflow-tidies
jbd-log-space-management-optimization.patch
JBD: log space management optimization
i4l-new-hfc_usb-driver-version.patch
i4l: new hfc_usb driver version
i4l-hfc-4s-and-hfc-8s-driver.patch
i4l: HFC-4S and HFC-8S driver
i810_audio-offset-lvi-from-civ-to-avoid-stalled-start.patch
i810_audio: offset LVI from CIV to avoid stalled start
configurable-delay-before-mounting-root-device.patch
Configurable delay before mounting root device
fs-mbcachec-remove-an-unused-wait-queue-variable.patch
fs/mbcache.c: Remove an unused wait queue variable
device-mapper-fix-mirror-log-type-module-ref-count.patch
device-mapper: fix mirror log type module ref count
device-mapper-remove-unused-bs_bio_init.patch
device-mapper: remove unused bs_bio_init()
device-mapper-add-presuspend-hook.patch
device-mapper: Add presuspend hook
device-mapper-optionally-bypass-a-bdget.patch
device-mapper: optionally bypass a bdget
device-mapper-fix-tb-stripe-data-corruption.patch
device-mapper: fix TB stripe data corruption
arm26-new-maintainer-of-archimedes-floppy-and-hard-disk-drivers.patch
arm26: new maintainer of Archimedes floppy and hard disk drivers
problems-disabling-sysctl.patch
Problems disabling SYSCTL
genhd-rename-device_init.patch
genhd: rename device_init
fix-race-between-the-nmi-code-and-the-cmos-clock.patch
Fix race between the NMI code and the CMOS clock
infiniband-core-compat_ioctl-conversion-minor-fixes.patch
InfiniBand/core: compat_ioctl conversion minor fixes
infiniband-mthca-more-arbel-mem-free-support.patch
InfiniBand/mthca: more Arbel Mem-Free support
infiniband-mthca-implement-modifying-port-attributes.patch
InfiniBand/mthca: implement modifying port attributes
infiniband-core-fix-port-capability-enums-bit-order.patch
InfiniBand/core: fix port capability enums bit order
infiniband-mthca-dont-write-ecr-in-msi-x-mode.patch
InfiniBand/mthca: don't write ECR in MSI-X mode
infiniband-mthca-pass-full-process_mad-info-to-firmware.patch
InfiniBand/mthca: pass full process_mad info to firmware
infiniband-mthca-optimize-event-queue-handling.patch
InfiniBand/mthca: optimize event queue handling
infiniband-mthca-test-irq-routing-during-initialization.patch
InfiniBand/mthca: test IRQ routing during initialization
infiniband-ipoib-remove-uses-of-yield.patch
InfiniBand/ipoib: remove uses of yield()
infiniband-core-add-issm-userspace-support.patch
InfiniBand/core: add IsSM userspace support
infiniband-mthca-clean-up-ioremap-request_region-usage.patch
InfiniBand/mthca: clean up ioremap()/request_region() usage
infiniband-mthca-remove-x86-sse-pessimization.patch
InfiniBand/mthca: remove x86 SSE pessimization
random-pt2-cleanup-waitqueue-logic-fix-missed-wakeup.patch
random: cleanup waitqueue logic, fix missed wakeup
random-pt2-kill-pool-clearing.patch
random: kill pool clearing
random-pt2-combine-legacy-ioctls.patch
random: combine legacy ioctls
random-pt2-re-init-all-pools-on-zero.patch
random: re-init all pools on zero
random-pt2-simplify-initialization.patch
random: simplify initialization
random-pt2-kill-memsets-of-static-data.patch
random: kill memsets of static data
random-pt2-kill-dead-extract_state-struct.patch
random: kill dead extract_state struct
random-pt2-kill-22-compat-waitqueue-defs.patch
random: kill 2.2 compat waitqueue defs
random-pt2-kill-redundant-rotate_left-definitions.patch
random: kill redundant rotate_left definitions
random-pt2-kill-misnamed-log2.patch
random: kill misnamed log2
random-pt3-more-meaningful-pool-names.patch
random: More meaningful pool names
random-pt3-static-allocation-of-pools.patch
random: Static allocation of pools
random-pt3-static-sysctl-bits.patch
random: Static sysctl bits
random-pt3-catastrophic-reseed-checks.patch
random: Catastrophic reseed checks
random-pt3-entropy-reservation-accounting.patch
random: Entropy reservation accounting
random-pt3-reservation-flag-in-pool-struct.patch
random: Reservation flag in pool struct
random-pt3-reseed-pointer-in-pool-struct.patch
random: Reseed pointer in pool struct
random-pt3-break-up-extract_user.patch
random: Break up extract_user
random-pt3-remove-dead-md5-copy.patch
random: Remove dead MD5 copy
random-pt3-simplify-hash-folding.patch
random: Simplify hash folding
random-pt3-clean-up-hash-buffering.patch
random: Clean up hash buffering
random-pt3-remove-entropy-batching.patch
random: Remove entropy batching
random-pt4-create-new-rol32-ror32-bitops.patch
random: Create new rol32/ror32 bitops
random-pt4-use-them-throughout-the-tree.patch
random: Use them throughout the tree
random-pt4-kill-the-sha-variants.patch
random: Kill the SHA variants
random-pt4-cleanup-sha-interface.patch
random: Cleanup SHA interface
random-pt4-move-sha-code-to-lib.patch
random: Move SHA code to lib/
random-pt4-replace-sha-with-faster-version.patch
random: Replace SHA with faster version
random-pt4-replace-sha-with-faster-version-fix.patch
random-pt4-replace-sha-with-faster-version-fix
random-pt4-update-cryptolib-to-use-sha-fro-lib.patch
random: Update cryptolib to use SHA fro lib
random-pt4-move-halfmd4-to-lib.patch
random: Move halfmd4 to lib
random-pt4-kill-duplicate-halfmd4-in-ext3-htree.patch
random: Kill duplicate halfmd4 in ext3 htree
random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix.patch
random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix
random-pt4-simplify-and-shrink-syncookie-code.patch
random: Simplify and shrink syncookie code
random-pt4-move-syncookies-to-net.patch
random: Move syncookies to net/
random-pt4-move-other-tcp-ip-bits-to-net.patch
random: Move other tcp/ip bits to net/
speedup-proc-pid-maps.patch
Speed up /proc/pid/maps
speedup-proc-pid-maps-fix.patch
Speed up /proc/pid/maps fix
speedup-proc-pid-maps-fix-fix.patch
speedup-proc-pid-maps fix fix
speedup-proc-pid-maps-fix-fix-fix.patch
speedup /proc/<pid>/maps(4th version)
fix-loss-of-records-on-size-4096-in-proc-pid-maps.patch
fix loss of records on size > 4096 in proc/<pid>/maps
speedup-proc-pid-maps-fix-fix-fix-fix.patch
speedup-proc-pid-maps-fix-fix-fix fix
inotify.patch
inotify
posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
posix-timers: tidy up clock interfaces and consolidate dispatch logic
posix-timers-high-resolution-cpu-clocks-for-posix-clock_-syscalls.patch
posix-timers: high-resolution CPU clocks for POSIX clock_* syscalls
posix-timers-fix-posix-timers-signals-lock-order.patch
posix-timers: fix posix-timers signals lock order
posix-timers-cpu-clock-support-for-posix-timers.patch
posix-timers: CPU clock support for POSIX timers
make-itimer_real-per-process.patch
make ITIMER_REAL per-process
make-itimer_prof-itimer_virtual-per-process.patch
make ITIMER_PROF, ITIMER_VIRTUAL per-process
make-rlimit_cpu-sigxcpu-per-process.patch
make RLIMIT_CPU/SIGXCPU per-process
relayfs-doc.patch
relayfs: doc
relayfs-common-files.patch
relayfs: common files
relayfs-remove-klog-debugging-channel.patch
relayfs - remove klog debugging channel
relayfs-locking-lockless-implementation.patch
relayfs: locking/lockless implementation
relayfs-headers.patch
relayfs: headers
relayfs-remove-klog-debugging-channel-headers.patch
relayfs - remove klog debugging channel
ltt-core-implementation.patch
ltt: core implementation
ltt-core-headers.patch
ltt: core headers
mips-fixed-ltt-build-errors.patch
mips: fixed LTT build errors
ltt-kconfig-fix.patch
ltt kconfig fix
ltt-doesnt-build-on-x86_64.patch
ltt doesn't build on x86_64
ltt-kernel-events.patch
ltt: kernel/ events
ltt-kernel-events-tidy.patch
ltt-kernel-events tidy
ltt-kernel-events-build-fix.patch
ltt-kernel-events-build-fix
ltt-fs-events.patch
ltt: fs/ events
ltt-fs-events-tidy.patch
ltt-fs-events tidy
ltt-ipc-events.patch
ltt: ipc/ events
ltt-mm-events.patch
ltt: mm/ events
ltt-net-events.patch
ltt: net/ events
ltt-architecture-events.patch
ltt: architecture events
pcmcia-tcic-eleminate-deprecated-check_region.patch
pcmcia: tcic: eleminate deprecated check_region()
pcmcia-i82365-use-config_pnp-instead-of-__isapnp__.patch
pcmcia: i82365: use CONFIG_PNP instead of __ISAPNP__
pcmcia-i82092-fix-checking-of-return-value-from-request_region.patch
pcmcia: i82092: fix checking of return value from request_region
pcmcia-socket-acregion-are-unused.patch
pcmcia: socket->{a,c}region are unused
pcmcia-use-unsigned-long-for-io-port-address.patch
pcmcia: use unsigned long for IO port address
nfs-fix_vfsflock.patch
VFS: Fix structure initialization in locks_remove_flock()
nfs-flock.patch
NFS: Add emulation of BSD flock() in terms of POSIX locks on the server
nfsacl-protocol-extension-for-nfsv3.patch
NFSACL protocol extension for NFSv3: generalise qsort()
nfsacl-return-enosys-for-rpc-programs-that-are-unavailable.patch
nfsacl: return -ENOSYS for RPC programs that are unavailable
nfsacl-add-missing-eopnotsupp-=-nfs3err_notsupp-mapping-in-nfsd.patch
nfsacl: add missing -EOPNOTSUPP => NFS3ERR_NOTSUPP mapping in nfsd
nfsacl-allow-multiple-programs-to-listen-on-the-same-port.patch
nfsacl: allow multiple programs to listen on the same port
nfsacl-allow-multiple-programs-to-share-the-same-transport.patch
nfsacl: allow multiple programs to share the same transport
nfsacl-lazy-rpc-receive-buffer-allocation.patch
nfsacl: lazy RPC receive buffer allocation
nfsacl-encode-and-decode-arbitrary-xdr-arrays.patch
nfsacl: encode and decode arbitrary XDR arrays
nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix.patch
nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix
nfsacl-add-noacl-nfs-mount-option.patch
nfsacl: add noacl nfs mount option
nfsacl-infrastructure-and-server-side-of-nfsacl.patch
nfsacl: infrastructure and server side of nfsacl
nfsacl-solaris-nfsacl-workaround.patch
nfsacl: solaris nfsacl workaround
nfsacl-client-side-of-nfsacl.patch
nfsacl: client side of nfsacl
nfsacl-acl-umask-handling-workaround-in-nfs-client.patch
nfsacl: aCL umask handling workaround in nfs client
nfsacl-cache-acls-on-the-nfs-client-side.patch
nfsacl: cache acls on the nfs client side
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdbL warning fix
kgdb buffer overflow fix
kgdbL warning fix
kgdb: CONFIG_DEBUG_INFO fix
x86_64 fixes
correct kgdb.txt Documentation link (against 2.6.1-rc1-mm2)
kgdb: fix for recent gcc
kgdb warning fixes
THREAD_SIZE fixes for kgdb
Fix stack overflow test for non-8k stacks kgdb-ga.patch fix for i386 single-step into sysenter fix TRAP_BAD_SYSCALL_EXITS on i386
add TRAP_BAD_SYSCALL_EXITS config for i386 kgdb-is-incompatible-with-kprobes kgdb-ga-build-fix
kgdb-ga-fixes
kgdb-kill-off-highmem_start_page.patch
kgdb: kill off highmem_start_page
kgdboe-netpoll.patch
kgdb-over-ethernet via netpoll
kgdboe: fix configuration of MAC address
kgdb-x86_64-support.patch
kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
kgdb-x86_64-warning-fixes
kgdb-x86_64-fix
kgdb-x86_64-serial-fix
kprobes exception notifier fix
dev-mem-restriction-patch.patch
/dev/mem restriction patch
dev-mem-restriction-patch-allow-reads.patch
dev-mem-restriction-patch: allow reads
journal_add_journal_head-debug.patch
journal_add_journal_head-debug
list_del-debug.patch
list_del debug check
unplug-can-sleep.patch
unplug functions can sleep
firestream-warnings.patch
firestream warnings
perfctr-core.patch
perfctr: core
perfctr: remove bogus perfctr_sample_thread() calls
perfctr-i386.patch
perfctr: i386
perfctr-x86-core-updates.patch
perfctr x86 core updates
perfctr-x86-driver-updates.patch
perfctr x86 driver updates
perfctr-x86-driver-cleanup.patch
perfctr: x86 driver cleanup
perfctr-prescott-fix.patch
Prescott fix for perfctr
perfctr-x86-update-2.patch
perfctr x86 update 2
perfctr-x86_64.patch
perfctr: x86_64
perfctr-x86_64-core-updates.patch
perfctr x86_64 core updates
perfctr-ppc.patch
perfctr: PowerPC
perfctr-ppc32-driver-update.patch
perfctr: ppc32 driver update
perfctr-ppc32-mmcr0-handling-fixes.patch
perfctr ppc32 MMCR0 handling fixes
perfctr-ppc32-update.patch
perfctr ppc32 update
perfctr-ppc32-update-2.patch
perfctr ppc32 update
perfctr-virtualised-counters.patch
perfctr: virtualised counters
perfctr-remap_page_range-fix.patch
virtual-perfctr-illegal-sleep.patch
virtual perfctr illegal sleep
make-perfctr_virtual-default-in-kconfig-match-recommendation.patch
Make PERFCTR_VIRTUAL default in Kconfig match recommendation in help text
perfctr-ifdef-cleanup.patch
perfctr ifdef cleanup
perfctr-update-2-6-kconfig-related-updates.patch
perfctr: Kconfig-related updates
perfctr-virtual-updates.patch
perfctr virtual updates
perfctr-virtual-cleanup.patch
perfctr: virtual cleanup
perfctr-ppc32-preliminary-interrupt-support.patch
perfctr ppc32 preliminary interrupt support
perfctr-update-5-6-reduce-stack-usage.patch
perfctr: reduce stack usage
perfctr-interrupt-support-kconfig-fix.patch
perfctr interrupt_support Kconfig fix
perfctr-low-level-documentation.patch
perfctr low-level documentation
perfctr-inheritance-1-3-driver-updates.patch
perfctr inheritance: driver updates
perfctr-inheritance-2-3-kernel-updates.patch
perfctr inheritance: kernel updates
perfctr-inheritance-3-3-documentation-updates.patch
perfctr inheritance: documentation updates
perfctr-inheritance-locking-fix.patch
perfctr inheritance locking fix
perfctr-api-changes-first-step.patch
perfctr API changes: first step
perfctr-virtual-update.patch
perfctr virtual update
perfctr-x86-64-ia32-emulation-fix.patch
perfctr x86-64 ia32 emulation fix
perfctr-sysfs-update-1-4-core.patch
perfctr sysfs update: core
perfctr-sysfs-update.patch
Perfctr sysfs update
perfctr-sysfs-update-2-4-x86.patch
perfctr sysfs update: x86
perfctr-sysfs-update-3-4-x86-64.patch
perfctr sysfs update: x86-64
perfctr: syscall numbers in x86-64 ia32-emulation perfctr x86_64 native syscall numbers fix
perfctr-sysfs-update-4-4-ppc32.patch
perfctr sysfs update: ppc32
sched-fix-preemption-race-core-i386.patch
sched: fix preemption race (Core/i386)
sched-make-use-of-preempt_schedule_irq-ppc.patch
sched: make use of preempt_schedule_irq() (PPC)
sched-make-use-of-preempt_schedule_irq-arm.patch
sched: make use of preempt_schedule_irq (ARM)
sched-isochronous-class-for-unprivileged-soft-rt-scheduling.patch
sched: Isochronous class for unprivileged soft rt scheduling
sched-account-rt_tasks-as-iso_ticks.patch
sched: account rt_tasks as iso_ticks
add-do_proc_doulonglongvec_minmax-to-sysctl-functions.patch
Add do_proc_doulonglongvec_minmax to sysctl functions add-do_proc_doulonglongvec_minmax-to-sysctl-functions-fix add-do_proc_doulonglongvec_minmax-to-sysctl-functions fix 2
add-sysctl-interface-to-sched_domain-parameters.patch
Add sysctl interface to sched_domain parameters
videotext-ioctls-changed-to-use-_io-macros.patch
videotext: ioctls changed to use _IO macros
video-arv-remove-casts.patch
video/arv: remove casts
video-w9966-remove-casts.patch
video/w9966: remove casts
video-zr36120-remove-casts.patch
video/zr36120: remove casts
v4l-video-buf-update.patch
v4l: video-buf update
v4l2-tuner-api-update.patch
v4l2 tuner api update
v4l-tuner-update.patch
v4l: tuner update
v4l-add-tveeprom-module.patch
v4l: add tveeprom module.
v4l-tvaudio-update.patch
v4l: tvaudio update
v4l-bttv-ir-input-driver-update.patch
v4l: bttv IR input driver update
v4l-bttv-update.patch
v4l: bttv update
v4l-saa7134-module.patch
v4l: saa7134 module
allow-modular-ide-pnp.patch
allow modular ide-pnp
allow-x86_64-to-reenable-interrupts-on-contention.patch
Allow x86_64 to reenable interrupts on contention
i386-cpu-hotplug-updated-for-mm.patch
i386 CPU hotplug updated for -mm
ppc64-fix-cpu-hotplug.patch
ppc64: fix hotplug cpu
serialize-access-to-ide-devices.patch
serialize access to ide devices
disable-atykb-warning.patch
disable atykb "too many keys pressed" warning
export-file_ra_state_init-again.patch
Export file_ra_state_init() again
cachefs-filesystem.patch
CacheFS filesystem
numa-policies-for-file-mappings-mpol_mf_move-cachefs.patch
numa-policies-for-file-mappings-mpol_mf_move for cachefs
cachefs-release-search-records-lest-they-return-to-haunt-us.patch
CacheFS: release search records lest they return to haunt us
fix-64-bit-problems-in-cachefs.patch
Fix 64-bit problems in cachefs
cachefs-fixed-typos-that-cause-wrong-pointer-to-be-kunmapped.patch
cachefs: fixed typos that cause wrong pointer to be kunmapped
cachefs-return-the-right-error-upon-invalid-mount.patch
CacheFS: return the right error upon invalid mount
fix-cachefs-barrier-handling-and-other-kernel-discrepancies.patch
Fix CacheFS barrier handling and other kernel discrepancies
remove-error-from-linux-cachefsh.patch
Remove #error from linux/cachefs.h
cachefs-warning-fix-2.patch
cachefs warning fix 2
cachefs-linkage-fix-2.patch
cachefs linkage fix
cachefs-build-fix.patch
cachefs build fix
cachefs-documentation.patch
CacheFS documentation
add-page-becoming-writable-notification.patch
Add page becoming writable notification
add-page-becoming-writable-notification-fix.patch
do_wp_page_mk_pte_writable() fix
add-page-becoming-writable-notification-build-fix.patch
add-page-becoming-writable-notification build fix
provide-a-filesystem-specific-syncable-page-bit.patch
Provide a filesystem-specific sync'able page bit
provide-a-filesystem-specific-syncable-page-bit-fix.patch
provide-a-filesystem-specific-syncable-page-bit-fix
provide-a-filesystem-specific-syncable-page-bit-fix-2.patch
provide-a-filesystem-specific-syncable-page-bit-fix-2
make-afs-use-cachefs.patch
Make AFS use CacheFS
afs-cachefs-dependency-fix.patch
afs-cachefs-dependency-fix
split-general-cache-manager-from-cachefs.patch
Split general cache manager from CacheFS
turn-cachefs-into-a-cache-backend.patch
Turn CacheFS into a cache backend
rework-the-cachefs-documentation-to-reflect-fs-cache-split.patch
Rework the CacheFS documentation to reflect FS-Cache split
update-afs-client-to-reflect-cachefs-split.patch
Update AFS client to reflect CacheFS split
x86-rename-apic_mode_exint.patch
kexec: x86: rename APIC_MODE_EXINT
x86-local-apic-fix.patch
kexec: x86: local apic fix
x86_64-e820-64bit.patch
kexec: x86_64: e820 64bit fix
x86-i8259-shutdown.patch
kexec: x86: i8259 shutdown: disable interrupts
x86_64-i8259-shutdown.patch
kexec: x86_64: add i8259 shutdown method
x86-apic-virtwire-on-shutdown.patch
kexec: x86: resture apic virtual wire mode on shutdown
x86_64-apic-virtwire-on-shutdown.patch
kexec: x86_64: restore apic virtual wire mode on shutdown
vmlinux-fix-physical-addrs.patch
kexec: vmlinux: fix physical addresses
x86-vmlinux-fix-physical-addrs.patch
kexec: x86: vmlinux: fix physical addresses
x86_64-vmlinux-fix-physical-addrs.patch
kexec: x86_64: vmlinux: fix physical addresses
x86_64-entry64.patch
kexec: x86_64: add 64-bit entry
x86-config-kernel-start.patch
kexec: x86: add CONFIG_PYSICAL_START
x86_64-config-kernel-start.patch
kexec: x86_64: add CONFIG_PHYSICAL_START
kexec-kexec-generic.patch
kexec: add kexec syscalls
x86-machine_shutdown.patch
kexec: x86: factor out apic shutdown code
x86-kexec.patch
kexec: x86 kexec core
x86-crashkernel.patch
crashdump: x86 crashkernel option
x86_64-machine_shutdown.patch
kexec: x86_64: factor out apic shutdown code
x86_64-kexec.patch
kexec: x86_64 kexec implementation
x86_64-crashkernel.patch
crashdump: x86_64: crashkernel option
kexec-ppc-support.patch
kexec: kexec ppc support
x86-crash_shutdown-nmi-shootdown.patch
crashdump: x86: add NMI handler to capture other CPUs
x86-crash_shutdown-snapshot-registers.patch
kexec: x86: snapshot registers during crash shutdown
x86-crash_shutdown-apic-shutdown.patch
kexec: x86 shutdown APICs during crash_shutdown
crashdump-documentation.patch
crashdump: documentation
crashdump-memory-preserving-reboot-using-kexec.patch
crashdump: memory preserving reboot using kexec
crashdump-routines-for-copying-dump-pages.patch
crashdump: routines for copying dump pages
crashdump-elf-format-dump-file-access.patch
crashdump: elf format dump file access
crashdump-linear-raw-format-dump-file-access.patch
crashdump: linear raw format dump file access
crashdump-reserving-backup-region-for-kexec-based.patch
crashdump: reserving backup region for kexec based crashdumps.
new-bitmap-list-format-for-cpusets.patch
new bitmap list format (for cpusets)
cpusets-big-numa-cpu-and-memory-placement.patch
cpusets - big numa cpu and memory placement
cpusets-config_cpusets-depends-on-smp.patch
Cpusets: CONFIG_CPUSETS depends on SMP
cpusets-move-cpusets-above-embedded.patch
move CPUSETS above EMBEDDED
cpusets-fix-cpuset_get_dentry.patch
cpusets : fix cpuset_get_dentry()
cpusets-fix-race-in-cpuset_add_file.patch
cpusets: fix race in cpuset_add_file()
cpusets-remove-more-casts.patch
cpusets: remove more casts
cpusets-make-config_cpusets-the-default-in-sn2_defconfig.patch
cpusets: make CONFIG_CPUSETS the default in sn2_defconfig
cpusets-document-proc-status-allowed-fields.patch
cpusets: document proc status allowed fields
cpusets-dont-export-proc_cpuset_operations.patch
Cpusets - Dont export proc_cpuset_operations
cpusets-display-allowed-masks-in-proc-status.patch
cpusets: display allowed masks in proc status
cpusets-simplify-cpus_allowed-setting-in-attach.patch
cpusets: simplify cpus_allowed setting in attach
cpusets-remove-useless-validation-check.patch
cpusets: remove useless validation check
cpusets-tasks-file-simplify-format-fixes.patch
Cpusets tasks file: simplify format, fixes
cpusets-simplify-memory-generation.patch
Cpusets: simplify memory generation
cpusets-interoperate-with-hotplug-online-maps.patch
cpusets: interoperate with hotplug online maps
cpusets-alternative-fix-for-possible-race-in.patch
cpusets: alternative fix for possible race in cpuset_tasks_read()
cpusets-remove-casts.patch
cpusets: remove void* typecasts
reiser4-sb_sync_inodes.patch
reiser4: vfs: add super_operations.sync_inodes()
reiser4-allow-drop_inode-implementation.patch
reiser4: export vfs inode.c symbols
reiser4-truncate_inode_pages_range.patch
reiser4: vfs: add truncate_inode_pages_range()
reiser4-export-remove_from_page_cache.patch
reiser4: export pagecache add/remove functions to modules
reiser4-export-page_cache_readahead.patch
reiser4: export page_cache_readahead to modules
reiser4-reget-page-mapping.patch
reiser4: vfs: re-check page->mapping after calling try_to_release_page()
reiser4-rcu-barrier.patch
reiser4: add rcu_barrier() synchronization point
reiser4-export-inode_lock.patch
reiser4: export inode_lock to modules
reiser4-export-pagevec-funcs.patch
reiser4: export pagevec functions to modules
reiser4-export-radix_tree_preload.patch
reiser4: export radix_tree_preload() to modules
reiser4-export-find_get_pages.patch
reiser4-radix-tree-tag.patch
reiser4: add new radix tree tag
reiser4-radix_tree_lookup_slot.patch
reiser4: add radix_tree_lookup_slot()
reiser4-perthread-pages.patch
reiser4: per-thread page pools
reiser4-include-reiser4.patch
reiser4: add to build system
reiser4-doc.patch
reiser4: documentation
reiser4-only.patch
reiser4: main fs
reiser4-recover-read-performance.patch
reiser4: recover read performance
reiser4-export-find_get_pages_tag.patch
reiser4-export-find_get_pages_tag
reiser4-add-missing-context.patch
add-acpi-based-floppy-controller-enumeration.patch
Add ACPI-based floppy controller enumeration.
possible-dcache-bug-debugging-patch.patch
Possible dcache BUG: debugging patch
serial-add-support-for-non-standard-xtals-to-16c950-driver.patch
serial: add support for non-standard XTALs to 16c950 driver
add-support-for-possio-gcc-aka-pcmcia-siemens-mc45.patch
Add support for Possio GCC AKA PCMCIA Siemens MC45
generic-serial-cli-conversion.patch
generic-serial cli() conversion
specialix-io8-cli-conversion.patch
Specialix/IO8 cli() conversion
sx-cli-conversion.patch
SX cli() conversion
revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.patch
revert "allow OEM written modules to make calls to ia64 OEM SAL functions"
md-add-interface-for-userspace-monitoring-of-events.patch
md: add interface for userspace monitoring of events.
make-acpi_bus_register_driver-consistent-with-pci_register_driver-again.patch
make acpi_bus_register_driver() consistent with pci_register_driver()
remove-lock_section-from-x86_64-spin_lock-asm.patch
remove LOCK_SECTION from x86_64 spin_lock asm
kfree_skb-dump_stack.patch
kfree_skb-dump_stack
cancel_rearming_delayed_work.patch
cancel_rearming_delayed_work()
make cancel_rearming_delayed_workqueue static
ipvs-deadlock-fix.patch
ipvs deadlock fix
minimal-ide-disk-updates.patch
Minimal ide-disk updates
use-find_trylock_page-in-free_swap_and_cache-instead-of-hand-coding.patch
use find_trylock_page in free_swap_and_cache instead of hand coding
radeonfb-set-accelerator-id.patch
radeonfb: Set accelerator id
vesafb-change-return-error-id.patch
vesafb: Change return error id
intelfb-workaround-for-830m.patch
intelfb: Workaround for 830M
fbcon-save-blank-state-last.patch
fbcon: Save blank state last
backlight-fix-compile-error-if-config_fb-is-unset.patch
backlight: Fix compile error if CONFIG_FB is unset
matroxfb-fb_matrox_g-kconfig-changes.patch
matroxfb: FB_MATROX_G Kconfig changes
raid5-overlapping-read-hack.patch
raid5 overlapping read hack
include-type-information-as-module-info-where-possible.patch
Include type information as module info where possible
figure-out-who-is-inserting-bogus-modules.patch
Figure out who is inserting bogus modules
detect-atomic-counter-underflows.patch
detect atomic counter underflows
post-halloween-doc.patch
post halloween doc
fix-architecture-names-in-hugetlbpagetxt.patch
fix architecture names in hugetlbpage.txt
periodically-scan-redzone-entries-and-slab-control-structures.patch
periodically scan redzone entries and slab control structures
fuse-maintainers-kconfig-and-makefile-changes.patch
Subject: [PATCH 1/11] FUSE - MAINTAINERS, Kconfig and Makefile changes
fuse-core.patch
Subject: [PATCH 2/11] FUSE - core
fuse-device-functions.patch
Subject: [PATCH 3/11] FUSE - device functions
fuse-fix-llseek-on-device.patch
FUSE: fix llseek on device
fuse-make-two-functions-static.patch
fuse: make two functions static
fuse-fix-variable-with-confusing-name.patch
fuse: fix variable with confusing name
fuse-read-only-operations.patch
Subject: [PATCH 4/11] FUSE - read-only operations
fuse-read-write-operations.patch
Subject: [PATCH 5/11] FUSE - read-write operations
fuse-file-operations.patch
Subject: [PATCH 6/11] FUSE - file operations
fuse-mount-options.patch
Subject: [PATCH 7/11] FUSE - mount options
fuse-dont-check-against-zero-fsuid.patch
fuse: don't check against zero fsuid
fuse-remove-mount_max-and-user_allow_other-module-parameters.patch
fuse: remove mount_max and user_allow_other module parameters
fuse-extended-attribute-operations.patch
Subject: [PATCH 8/11] FUSE - extended attribute operations
fuse-readpages-operation.patch
Subject: [PATCH 9/11] FUSE - readpages operation
fuse-nfs-export.patch
Subject: [PATCH 10/11] FUSE - NFS export
fuse-direct-i-o.patch
Subject: [PATCH 11/11] FUSE - direct I/O
fuse-transfer-readdir-data-through-device.patch
fuse: transfer readdir data through device
ieee1394-adds-a-disable_irm-option-to-ieee1394ko.patch
ieee1394: add a disable_irm option to ieee1394.ko
cryptoapi-prepare-for-processing-multiple-buffers-at.patch
CryptoAPI: prepare for processing multiple buffers at a time
cryptoapi-update-padlock-to-process-multiple-blocks-at.patch
CryptoAPI: Update PadLock to process multiple blocks at once
update-email-address-of-andrea-arcangeli.patch
update email address of Andrea Arcangeli
compile-error-blackbird_load_firmware.patch
blackbird_load_firmware compile fix
i386-x86_64-apicc-make-two-functions-static.patch
i386/x86_64 apic.c: make two functions static
i386-cyrixc-make-a-function-static.patch
i386 cyrix.c: make a function static
mtrr-some-cleanups.patch
mtrr: some cleanups
i386-cpu-commonc-some-cleanups.patch
i386 cpu/common.c: some cleanups
i386-cpuidc-make-two-functions-static.patch
i386 cpuid.c: make two functions static
i386-efic-make-some-code-static.patch
i386 efi.c: make some code static
i386-x86_64-io_apicc-misc-cleanups.patch
i386/x86_64 io_apic.c: misc cleanups
i386-mpparsec-make-mp_processor_info-static.patch
i386 mpparse.c: make MP_processor_info static
i386-x86_64-msrc-make-two-functions-static.patch
i386/x86_64 msr.c: make two functions static
3w-abcdh-tw_device_extension-remove-an-unused-filed.patch
3w-abcd.h: TW_Device_Extension: remove an unused field
hpet-make-some-code-static.patch
hpet: make some code static
26-patch-i386-trapsc-make-a-function-static.patch
i386 traps.c: make a function static
i386-semaphorec-make-4-functions-static.patch
i386 semaphore.c: make 4 functions static
i386-rebootc-cleanups.patch
i386: reboot.c cleanups
kill-aux_device_present.patch
kill aux_device_present
i386-setupc-make-4-variables-static.patch
i386 setup.c: make 4 variables static
mostly-i386-mm-cleanup.patch
(mostly i386) mm cleanup
scsi-megaraid_mmc-make-some-code-static.patch
SCSI megaraid_mm.c: make some code static
update-email-address-of-benjamin-lahaise.patch
Update email address of Benjamin LaHaise
add-map_populate-sys_remap_file_pages-support-to-xfs.patch
add MAP_POPULATE/sys_remap_file_pages support to XFS
update-email-address-of-philip-blundell.patch
Update email address of Philip Blundell
mm-filemapc-make-a-function-static.patch
mm/filemap.c: make a function static
kernel-acctc-make-a-function-static.patch
kernel/acct.c: make a function static
kernel-auditc-make-some-functions-static.patch
kernel/audit.c: make some functions static
kernel-capabilityc-make-a-spinlock-static.patch
kernel/capability.c: make a spinlock static
mm-thrashc-make-a-variable-static.patch
mm/thrash.c: make a variable static
lib-kernel_lockc-make-kernel_sem-static.patch
lib/kernel_lock.c: make kernel_sem static
saa7146_vv_ksymsc-remove-two-unused-export_symbol_gpls.patch
saa7146_vv_ksyms.c: remove two unused EXPORT_SYMBOL_GPL's
fix-placement-of-static-inline-in-nfsdh.patch
fix placement of static inline in nfsd.h
drivers-block-umemc-make-two-functions-static.patch
drivers/block/umem.c: make two functions static
drivers-block-xdc-make-a-variable-static.patch
drivers/block/xd.c: make a variable static
kernel-configsc-make-a-variable-static.patch
kernel/configs.c: make a variable static
kernel-forkc-make-mm_cachep-static.patch
kernel/fork.c: make mm_cachep static
kernel-kallsymsc-make-some-code-static.patch
kernel/kallsyms.c: make some code static
mm-page-writebackc-remove-an-unused-function.patch
mm/page-writeback.c: remove an unused function
mm-shmemc-make-a-struct-static.patch
mm/shmem.c: make a struct static
misc-isapnp-cleanups.patch
misc ISAPNP cleanups
some-pnp-cleanups.patch
some PNP cleanups
if-0-cx88_risc_disasm.patch
#if 0 cx88_risc_disasm
make-loglevels-in-init-mainc-a-little-more-sane.patch
Make loglevels in init/main.c a little more sane.
isicom-use-null-for-pointer.patch
sparse: use NULL for pointer
remove-bouncing-email-address-of-hennus-bergman.patch
remove bouncing email address of Hennus Bergman
cirrusfbc-make-some-code-static.patch
cirrusfb.c: make some code static
matroxfb_basec-make-some-code-static.patch
matroxfb_base.c: make some code static
asiliantfbc-make-some-code-static.patch
asiliantfb.c: make some code static
i386-apic-kconfig-cleanups.patch
i386 APIC Kconfig cleanups
security-seclvlc-make-some-code-static.patch
security/seclvl.c: make some code static
drivers-block-elevatorc-make-two-functions-static.patch
drivers/block/elevator.c: make two functions static
drivers-block-rdc-make-two-variables-static.patch
drivers/block/rd.c: make two variables static
loopc-make-two-functions-static.patch
loop.c: make two functions static
remove-bouncing-email-address-of-thomas-hood.patch
remove bouncing email address of Thomas Hood
fs-adfs-dir_fc-remove-an-unused-function.patch
fs/adfs/dir_f.c: remove an unused function
drivers-char-moxac-if-0-an-unused-function.patch
drivers/char/moxa.c: #if 0 an unused function
Re: 2.6.11-rc2-mm1
Quoted 3 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
...
Before people start complaining it wouldn't apply:
s/rc1/rc2/g
cu
Adrian
Signature · 4 lines
"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 Seed2.6.11-rc2-mm1: v4l-saa7134-module compile error
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.11-rc1-mm2:
...
+v4l-saa7134-module.patchv4l updates.
...
This patch broke compilation with CONFIG_MODULES=n:
<-- snip -->
...
CC drivers/media/video/saa7134/saa7134-core.odrivers/media/video/saa7134/saa7134-core.c: In function `pending_call':drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function) drivers/media/video/saa7134/saa7134-core.c:234: error: (Each undeclared identifier is reported only once drivers/media/video/saa7134/saa7134-core.c:234: error: for each function it appears in.) drivers/media/video/saa7134/saa7134-core.c: In function `request_module_depend':drivers/media/video/saa7134/saa7134-core.c:251: error: dereferencing pointer to incomplete type drivers/media/video/saa7134/saa7134-core.c:252: error: MODULE_STATE_COMING' undeclared (first use in this function) drivers/media/video/saa7134/saa7134-core.c:259: error: MODULE_STATE_LIVE' undeclared (first use in this function) make[4]: *** [drivers/media/video/saa7134/saa7134-core.o] Error 1
<-- snip -->
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: v4l-saa7134-module compile error
Quoted 8 lines · Adrian Bunk
Quoted 2 lines · Andrew Morton
...
+v4l-saa7134-module.patchThis patch broke compilation with
CONFIG_MODULES=n:
drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function)
The patch below should fix this.
Gerd
drivers/media/video/saa7134/saa7134-core.c +9 -0
@@ -21,6 +21,7 @@* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include <linux/config.h> #include <linux/init.h> #include <linux/list.h> #include <linux/module.h>
@@ -225,6 +226,8 @@ static void dump_statusregs(struct saa71/* ----------------------------------------------------------- */ /* delayed request_module */ +#ifdef CONFIG_MODULES +static int need_empress;static int need_dvb;
@@ -265,6 +268,12 @@ static void request_module_depend(char * } } +#else + +static inline void request_module_depend (char *name,int *flag) {} + +#endif /* CONFIG_MODULES */ +/* ------------------------------------------------------------------ */ /* nr of (saa7134-)pages for the given buffer size */
Re: 2.6.11-rc2-mm1: v4l-saa7134-module compile error
Quoted 11 lines · Gerd Knorr
Quoted 8 lines · Adrian Bunk
Quoted 2 lines · Andrew Morton
...
+v4l-saa7134-module.patchThis patch broke compilation with
CONFIG_MODULES=n:
drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function)The patch below should fix this.
Not completely:
<-- snip -->
...
CC drivers/media/video/saa7134/saa7134-core.odrivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function) drivers/media/video/saa7134/saa7134-core.c:997: error: (Each undeclared identifier is reported only once drivers/media/video/saa7134/saa7134-core.c:997: error: for each function it appears in.) drivers/media/video/saa7134/saa7134-core.c:1000: error: `need_dvb' undeclared (first use in this function) make[4]: *** [drivers/media/video/saa7134/saa7134-core.o] Error 1
<-- snip -->
Quoted 2 lines
Gerd
...
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: v4l-saa7134-module compile error
Quoted 7 lines
Quoted 1 line
The patch below should fix this.
Not completely:
CC
drivers/media/video/saa7134/saa7134-core.odrivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function)
New version, this time using a #define, which should kill the reference to need_* as well ...
Gerd
drivers/media/video/saa7134/saa7134-core.c +9 -0
@@ -21,6 +21,7 @@* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ +#include <linux/config.h> #include <linux/init.h> #include <linux/list.h> #include <linux/module.h>
@@ -225,6 +226,8 @@ static void dump_statusregs(struct saa71/* ----------------------------------------------------------- */ /* delayed request_module */ +#ifdef CONFIG_MODULES +static int need_empress;static int need_dvb;
@@ -265,6 +268,12 @@ static void request_module_depend(char * } } +#else + +#define request_module_depend (name,flag) + +#endif /* CONFIG_MODULES */ +/* ------------------------------------------------------------------ */ /* nr of (saa7134-)pages for the given buffer size */
Re: 2.6.11-rc2-mm1: v4l-saa7134-module compile error
Quoted 10 lines · Gerd Knorr
Quoted 7 lines
Quoted 1 line
The patch below should fix this.
Not completely:
CC
drivers/media/video/saa7134/saa7134-core.odrivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function)New version, this time using a #define, which should kill the reference to need_* as well ...
I can confirm that this patch fixes the compilation.
Quoted 2 lines
Gerd
...
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 4 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
Hi Andrew,
X does not work anymore when using DRI on my Compaq Evo N600c (Radeon Mobility M6 LY). My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel modules.
Instead of the usual gdm window, I get a black or noisy screen (remaining image parts of last working session). The mouse pointer works. Sysrq works. But Caps-lock doesn't work. The machine pings but I can't ssh.
I don't know exactly what's happening. I don't see anything interesting in dmesg. Removing DRI from Xfree config (even if drm/radeon modules are loaded) makes X work again. Linus' 2.6.11-rc2 works fine.
.config and lspci attached.
Regards,
Brice
Re: 2.6.11-rc2-mm1
Quoted 11 lines · Brice Goglin
Quoted 5 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
Hi Andrew,
Quoted 8 lines
X does not work anymore when using DRI on my Compaq Evo N600c (Radeon Mobility M6 LY). My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel modules.
Instead of the usual gdm window, I get a black or noisy screen (remaining image parts of last working session). The mouse pointer works. Sysrq works. But Caps-lock doesn't work. The machine pings but I can't ssh.
I don't know exactly what's happening. I don't see anything interesting in dmesg.
Thanks to Benoit who found this at the end of dmesg:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Couldn't find an AGP VGA controller.
while Linus' 2.6.11-rc2 says:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
Regards,
Brice
Re: 2.6.11-rc2-mm1
Quoted 35 lines · On Mon, 24 Jan 2005 14:41:49 +0100 Brice Goglin <[email protected]>…
Quoted 16 lines · Brice Goglin
Quoted 5 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
Hi Andrew,
X does not work anymore when using DRI on my Compaq Evo N600c (Radeon Mobility M6 LY).
My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel modules.Quoted 8 lines
Instead of the usual gdm window, I get a black or noisy screen (remaining image parts of
last working session). The mouse pointer works. Sysrq works. But Caps-lock doesn't work.
The machine pings but I can't ssh.I don't know exactly what's happening. I don't see anything interesting in dmesg.
Thanks to Benoit who found this at the end of dmesg:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Couldn't find an AGP VGA controller.while Linus' 2.6.11-rc2 says:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
Quoted 7 lines
Regards,
Brice
-
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/
the same problem here.... with the nvidia-driver .....seems that AGP is totally brocken.
Jan 24 13:50:09 hal9000 agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. Jan 24 13:50:09 hal9000 agpgart: Couldn't find an AGP VGA controller.
Signature · 7 lines
----------------------------------------------------------------------------- "Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous." -----------------------------------------------------------------------------
Re: 2.6.11-rc2-mm1
In reply to Brice GoglinQuoted 4 lines · Brice Goglin
X does not work anymore when using DRI on my Compaq Evo N600c (Radeon Mobility M6 LY).
My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel modules.
My fault. I'm looking into it.
Drop the agpgart-bk update for now.
Dave
Re: 2.6.11-rc2-mm1
Quoted 8 lines · Dave Jones
Quoted 4 lines · Brice Goglin
X does not work anymore when using DRI on my Compaq Evo N600c (Radeon Mobility M6 LY).
My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel modules.My fault. I'm looking into it.
Drop the agpgart-bk update for now.
Here's the most obvious bug fixed. There still seems to be something wrong however. It only successfully boots 50% of the time for me, (it reboots when starting X otherwise), and when it does boot, I get a flood of ...
Warning: kfree_skb on hard IRQ cf7b5800
Warning: kfree_skb on hard IRQ cf7b5800
Warning: kfree_skb on hard IRQ cf7b5800
I think there may be some stupid memory corruptor bug in there still.
Dave
# This is a BitKeeper generated diff -Nru style patch. #
# ChangeSet
# 2005/01/24 15:37:57-05:00 [email protected]
# [AGPGART] Fix stupid thinko in device discovery.
#
# Should fix the 'cant find AGP VGA controller' warnings.
#
# Signed-off-by: Dave Jones <[email protected]>
drivers/char/agp/generic.c +1 -1
@@ -626,7 +626,7 @@u32 vga_agpstat;while (!cap_ptr) { - device =pci_get_class (PCI_CLASS_DISPLAY_VGA , device); + device =pci_get_class (PCI_CLASS_DISPLAY_VGA <<8 , device);if (!device) { printk (KERN_INFO PFX "Couldn't find an AGP VGA controller.\n");return 0 ;
Re: 2.6.11-rc2-mm1
Quoted 11 lines · Dave Jones
Here's the most obvious bug fixed. There still seems to be something wrong however. It only successfully boots 50% of the time for me, (it reboots when starting X otherwise), and when it does boot, I get a flood of ...
Warning:kfree_skbon hard IRQcf7b5800
Warning:kfree_skbon hard IRQcf7b5800
Warning:kfree_skbon hard IRQcf7b5800I think there may be some stupid memory corruptor bug in there still.
Dave
Thanks, your patch makes X work again with DRI. Actually, it successfully booted 100% of the time here. I tried 6 or 7 times without seeing any problem like yours. Let me know if you want me to try something special.
Brice
Re: 2.6.11-rc2-mm1
Quoted 9 lines · Brice Goglin
Quoted 8 lines · Dave Jones
Here's the most obvious bug fixed. There still seems to be something wrong however. It only successfully boots 50% of the time for me, (it reboots when starting X otherwise), and when it does boot, I get a flood of ...
Warning:kfree_skbon hard IRQcf7b5800
Warning:kfree_skbon hard IRQcf7b5800
Warning:kfree_skbon hard IRQcf7b5800
Quoted 6 lines
Quoted 1 line
I think there may be some stupid memory corruptor bug in there still.
Thanks, your patch makes X work again with DRI. Actually, it successfully booted 100% of the time here. I tried 6 or 7 times without seeing any problem like yours. Let me know if you want me to try something special.
It's quite remarkable that it works at all.
This is needed too on top of -mm1.
Dave
# This is a BitKeeper generated diff -Nru style patch. #
# ChangeSet
# 2005/01/25 14:27:39-05:00 [email protected]
# [AGPGART] Silly thinko in reserve bit masking.
#
# Stupid inversion meant we passed '0' to userspace, and madness
# ensued resulting in very funky visuals.
#
# Signed-off-by: Dave Jones <[email protected]>
#
drivers/char/agp/generic.c +2 -2
@@ -324,9 +324,9 @@ info->chipset = agp_bridge->type; info->device = agp_bridge->dev;if (check_bridge_mode (agp_bridge->dev)) - info->mode = agp_bridge->mode &AGP3_RESERVED_MASK ; + info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK ;else - info->mode = agp_bridge->mode &AGP2_RESERVED_MASK ; + info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK ; info->aper_base = agp_bridge->gart_bus_addr; info->aper_size =agp_return_size (); info->max_memory = agp_bridge->max_memory_agp;
Re: 2.6.11-rc2-mm1
Quoted 8 lines · Dave Jones
This is needed too on top of -mm1.
diff -Nru
a/drivers/char/agp/generic.cb/drivers/char/agp/generic.cdrivers/char/agp/generic.c +0
-0@@ -324,9 +324,9 @@ info->chipset = agp_bridge->type;
drivers/char/agp/generic.c line 332
Quoted 10 lines
drivers/char/agp/generic.c +2
-2info->device = agp_bridge->dev;if (check_bridge_mode (agp_bridge->dev)) - info->mode = agp_bridge->mode &AGP3_RESERVED_MASK ; + info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK ;else - info->mode = agp_bridge->mode &AGP2_RESERVED_MASK ; + info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK ; info->aper_base = agp_bridge->gart_bus_addr; info->aper_size =agp_return_size (); info->max_memory = agp_bridge->max_memory_agp;
Maybe that's not important, but on top of my -rc2-mm1, your patch looks like the one I attached to this mail.
Regards,
Brice
drivers/char/agp/generic.c +2 -2
@@ -328,9 +328,9 @@ info->chipset =SUPPORTED ; info->device = bridge->dev;if (check_bridge_mode (bridge->dev)) - info->mode = bridge->mode &AGP3_RESERVED_MASK ; + info->mode = bridge->mode & ~AGP3_RESERVED_MASK ;else - info->mode = bridge->mode &AGP2_RESERVED_MASK ; + info->mode = bridge->mode & ~AGP2_RESERVED_MASK ; info->mode = bridge->mode; info->aper_base = bridge->gart_bus_addr; info->aper_size =agp_return_size ();
Re: 2.6.11-rc2-mm1
Quoted 14 lines · Brice Goglin
Quoted 13 lines · Dave Jones
This is needed too on top of -mm1.
diff -Nru
a/drivers/char/agp/generic.cb/drivers/char/agp/generic.cdrivers/char/agp/generic.c +1
-2@@ -324,9 +324,9 @@ info->chipset = agp_bridge->type; info->device = agp_bridge->dev;if (check_bridge_mode (agp_bridge->dev)) - info->mode = agp_bridge->mode &AGP3_RESERVED_MASK ; + info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK ;else - info->mode = agp_bridge->mode &AGP2_RESERVED_MASK ;
Quoted 8 lines
drivers/char/agp/generic.c line 332
Quoted 5 lines
drivers/char/agp/generic.c +1
-0+ info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK ; info->aper_base = agp_bridge->gart_bus_addr; info->aper_size =agp_return_size (); info->max_memory = agp_bridge->max_memory_agp;Maybe that's not important, but on top of my -rc2-mm1, your patch looks like the one I attached to this mail.
Doh, yes. Your variant is needed with the multi-gart patches that are in -mm. The one I posted is what I just committed to agpgart-bk
Dave
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 1 line
+i4l-new-hfc_usb-driver-version.patch
this drivers wants:
- update for Documentation/CodingStyle
- conversion to proper pci API
Quoted 1 line
+posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
umm, this adds extreme obsfucation. Roland, please try to follow normal Linux style, thanks.
Re: 2.6.11-rc2-mm1
Quoted 5 lines · Christoph Hellwig
Quoted 2 lines
+posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
umm, this adds extreme obsfucation. Roland, please try to follow normal Linux style, thanks.
Best cc Roland - not everyone follows linux-kernel.
Re: 2.6.11-rc2-mm1
In reply to Christoph HellwigQuoted 5 lines · Christoph Hellwig
Quoted 1 line
+i4l-new-hfc_usb-driver-version.patch
this drivers wants:
- update for
Documentation/CodingStyle
agree, I only take the patch from chip manufacturer and
test compiling and working with my hardware and do not look at code style yet.
Quoted 1 line
- conversion to proper pci API
??? the driver is not PCI related at all
Signature · 3 lines
Karsten Keil SuSE Labs ISDN development
Re: 2.6.11-rc2-mm1
Quoted 3 lines · Karsten Keil
Quoted 1 line
- conversion to proper pci API
??? the driver is not PCI related at all
Sorry, this was actually a comment for i4l-hfc-4s-and-hfc-8s-driver.patch.
Re: 2.6.11-rc2-mm1
Quoted 7 lines · Christoph Hellwig
Quoted 3 lines · Karsten Keil
Quoted 1 line
- conversion to proper pci API
??? the driver is not PCI related at all
Sorry, this was actually a comment for i4l-hfc-4s-and-hfc-8s-driver.patch.
OK, in the meantime I assumed this too and informed the author about the problems, I think most things will be solved soon.
I can correct CodingStyle for hfc_usb.c too, this give ~30K bigger patch.
Thanks for the formal code checks, I forget them sometimes, if I get code from 3 party.
Signature · 3 lines
Karsten Keil SuSE Labs ISDN development
Re: 2.6.11-rc2-mm1
In reply to Karsten KeilQuoted 7 lines · Karsten Keil
Quoted 5 lines · Christoph Hellwig
Quoted 1 line
+i4l-new-hfc_usb-driver-version.patch
this drivers wants:
- update for
Documentation/CodingStyle
Quoted 7 lines
agree, I only take the patch from chip manufacturer and
test compiling and working with my hardware and do not look at code style yet.Quoted 1 line
- conversion to proper pci API
??? the driver is not PCI related at all
it seems that hch wanted to also mention this patch:
i4l-hfc-4s-and-hfc-8s-driver.patch
and it is indeed a very ugly one...
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 2 lines
inotify.patch
inotify
Haven't had time to look at the current implementation, but the in-kernel interface is still horrible as it duplicates the dnotify calls all over the place, using IN_FOO instead of DN_FOO. Please add a layer of notify_foo wrappers that calls into both.
Also ioctl is not an acceptable interface for adding new core functionality.
PATCH 1/1 generic notification layer
Quoted 4 lines · Christoph Hellwig
Haven't had time to look at the current implementation, but the in-kernel interface is still horrible as it duplicates the dnotify calls all over the place, using
IN_FOOinstead ofDN_FOO. Please add a layer ofnotify_foowrappers that calls into both.
Hi, Christoph!
I went ahead and wrote a generic notification layer, wrapping inotify, dnotify, and some related work behind nice, clean interfaces such as "fsnotify_move()".
The patch is a net gain of -125 lines ignoring the new <linux/fsnotify.h>, so it does remove a bit of code from fs/, which is nice.
Compile tested, but not yet booted. Find an interdiff below, so you can get an idea of the interfaces, at least.
If this is really an issue for you, I think that this should be a step in the right direction.
Best,
Robert Love
fs/attr.c +3 -60
@@ -10,8 +10,7 @@#include <linux/mm.h> #include <linux/string.h> #include <linux/smp_lock.h> -#include <linux/dnotify.h> -#include <linux/inotify.h> +#include <linux/fsnotify.h> #include <linux/fcntl.h> #include <linux/quotaops.h> #include <linux/security.h>
@@ -106,51 +105,6 @@ }EXPORT_SYMBOL (inode_setattr); -void setattr_mask (unsigned int ia_valid,int *dn_mask,u32 *in_mask) -{ -int dnmask; -u32 inmask; - - inmask =0 ; - dnmask =0 ; - -if (!dn_mask || !in_mask) { -return ; - } -if (ia_valid &ATTR_UID ) { - inmask |=IN_ATTRIB ; - dnmask |=DN_ATTRIB ; - } -if (ia_valid &ATTR_GID ) { - inmask |=IN_ATTRIB ; - dnmask |=DN_ATTRIB ; - } -if (ia_valid &ATTR_SIZE ) { - inmask |=IN_MODIFY ; - dnmask |=DN_MODIFY ; - } -/* both times implies a utime(s) call */ -if ((ia_valid & (ATTR_ATIME |ATTR_MTIME )) == (ATTR_ATIME |ATTR_MTIME )) { - inmask |=IN_ATTRIB ; - dnmask |=DN_ATTRIB ; - } -else if (ia_valid &ATTR_ATIME ) { - inmask |=IN_ACCESS ; - dnmask |=DN_ACCESS ; - } -else if (ia_valid &ATTR_MTIME ) { - inmask |=IN_MODIFY ; - dnmask |=DN_MODIFY ; - } -if (ia_valid &ATTR_MODE ) { - inmask |=IN_ATTRIB ; - dnmask |=DN_ATTRIB ; - } - - *in_mask = inmask; - *dn_mask = dnmask; -} -int notify_change (struct dentry * dentry,struct iattr * attr) {struct inode *inode = dentry->d_inode;
@@ -206,21 +160,10 @@ error =inode_setattr (inode, attr); } } -if (!error) { -int dn_mask; -u32 in_mask; -setattr_mask (ia_valid, &dn_mask, &in_mask); +if (!error) +fsnotify_change (dentry, ia_valid); -if (dn_mask) -dnotify_parent (dentry, dn_mask); -if (in_mask) { -inotify_inode_queue_event (dentry->d_inode, in_mask,0 , -NULL ); -inotify_dentry_parent_queue_event (dentry, in_mask,0 , - dentry->d_name.name); - } - }return error; }
fs/file_table.c +2 -5
@@ -16,7 +16,7 @@#include <linux/eventpoll.h> #include <linux/mount.h> #include <linux/cdev.h> -#include <linux/inotify.h> +#include <linux/fsnotify.h> /* sysctl tunables... */ struct files_stat_struct files_stat = {
@@ -121,12 +121,9 @@struct dentry *dentry = file->f_dentry;struct vfsmount *mnt = file->f_vfsmnt;struct inode *inode = dentry->d_inode; -u32 mask; - mask = (file->f_mode &FMODE_WRITE ) ?IN_CLOSE_WRITE :IN_CLOSE_NOWRITE ; -inotify_dentry_parent_queue_event (dentry, mask,0 , dentry->d_name.name); -inotify_inode_queue_event (inode, mask,0 ,NULL ); +fsnotify_close (dentry, inode, file->f_mode, dentry->d_name.name);might_sleep ();/*
fs/namei.c +15 -51
133 lines not on this page · raw message
fs/open.c +6 -7
@@ -10,8 +10,7 @@#include <linux/file.h> #include <linux/smp_lock.h> #include <linux/quotaops.h> -#include <linux/dnotify.h> -#include <linux/inotify.h> +#include <linux/fsnotify.h> #include <linux/module.h> #include <linux/slab.h> #include <linux/tty.h>
@@ -954,13 +953,13 @@ fd =get_unused_fd ();if (fd >=0 ) {struct file *f =filp_open (tmp, flags, mode); +struct dentry *dentry = f->f_dentry; + error =PTR_ERR (f);if (IS_ERR (f)) goto out_error; -inotify_inode_queue_event (f->f_dentry->d_inode, -IN_OPEN ,0 ,NULL ); -inotify_dentry_parent_queue_event (f->f_dentry,IN_OPEN , -0 , f->f_dentry->d_name.name); +fsnotify_open (dentry, dentry->d_inode, + dentry->d_name.name);fd_install (fd, f); } out:
@@ -1012,7 +1011,7 @@ retval = err; } -dnotify_flush (filp, id); +fsnotify_flush (filp, id);locks_remove_posix (filp, id);fput (filp);return retval;
fs/read_write.c +11 -18
@@ -10,8 +10,7 @@#include <linux/file.h> #include <linux/uio.h> #include <linux/smp_lock.h> -#include <linux/dnotify.h> -#include <linux/inotify.h> +#include <linux/fsnotify.h> #include <linux/security.h> #include <linux/module.h> #include <linux/syscalls.h>
@@ -219,11 +218,8 @@ ret =do_sync_read (file, buf, count, pos);if (ret >0 ) {struct dentry *dentry = file->f_dentry; -dnotify_parent (dentry,DN_ACCESS ); -inotify_dentry_parent_queue_event (dentry, -IN_ACCESS ,0 , dentry->d_name.name); -inotify_inode_queue_event (inode,IN_ACCESS ,0 , -NULL ); +fsnotify_access (dentry, inode, + dentry->d_name.name); } } }
@@ -269,11 +265,8 @@ ret =do_sync_write (file, buf, count, pos);if (ret >0 ) {struct dentry *dentry = file->f_dentry; -dnotify_parent (dentry,DN_MODIFY ); -inotify_dentry_parent_queue_event (dentry, -IN_MODIFY ,0 , dentry->d_name.name); -inotify_inode_queue_event (inode,IN_MODIFY ,0 , -NULL ); +fsnotify_modify (dentry, inode, + dentry->d_name.name); } } }
@@ -508,12 +501,12 @@kfree (iov);if ((ret + (type ==READ )) >0 ) {struct dentry *dentry = file->f_dentry; -dnotify_parent (dentry, (type ==READ ) ?DN_ACCESS :DN_MODIFY ); -inotify_dentry_parent_queue_event (dentry, - (type ==READ ) ?IN_ACCESS :IN_MODIFY ,0 , - dentry->d_name.name); -inotify_inode_queue_event (dentry->d_inode, - (type ==READ ) ?IN_ACCESS :IN_MODIFY ,0 ,NULL ); +struct inode *inode = dentry->d_inode; + +if (type ==READ ) +fsnotify_access (dentry, inode, dentry->d_name.name); +else +fsnotify_modify (dentry, inode, dentry->d_name.name); }return ret; }
fs/super.c +2 -3
@@ -37,9 +37,8 @@#include <linux/writeback.h> /* for the emergency remount stuff */ #include <linux/idr.h> #include <linux/kobject.h> +#include <linux/fsnotify.h> #include <asm/uaccess.h> -#include <linux/inotify.h> -void get_filesystem (struct file_system_type *fs);void put_filesystem (struct file_system_type *fs);
@@ -228,7 +227,7 @@if (root) { sb->s_root =NULL ; -inotify_super_block_umount (sb); +fsnotify_sb_umount (sb);shrink_dcache_parent (root);shrink_dcache_anon (&sb->s_anon);dput (root);
include/linux/inotify.h +0 -31
@@ -84,23 +84,6 @@extern void inotify_super_block_umount (struct super_block *);extern void inotify_inode_is_dead (struct inode *);extern __u32 inotify_get_cookie (void ); -extern __u32 setattr_mask_inotify (unsigned int ); - -/* this could be kstrdup if only we could add that to lib/string.c */ -static inline char *inotify_oldname_init (struct dentry *old_dentry) -{ -char *old_name; - - old_name =kmalloc (strlen (old_dentry->d_name.name) +1 ,GFP_KERNEL ); -if (old_name) -strcpy (old_name, old_dentry->d_name.name); -return old_name; -} - -static inline void inotify_oldname_free (const char *old_name) -{ -kfree (old_name); -}#else
@@ -124,25 +107,11 @@ { } -static inline char *inotify_oldname_init (struct dentry *old_dentry) -{ -return NULL ; -} -static inline __u32 inotify_get_cookie (void ) {return 0 ; } -static inline void inotify_oldname_free (const char *old_name) -{ -} - -static inline int setattr_mask_inotify (unsigned int ia_mask) -{ -return 0 ; -} -#endif /* CONFIG_INOTIFY */ #endif /* __KERNEL __ */
only in patch2:
unchanged:
fs/compat.c +9 -3
@@ -1192,9 +1192,15 @@ out:if (iov != iovstack)kfree (iov); -if ((ret + (type ==READ )) >0 ) -dnotify_parent (file->f_dentry, - (type ==READ ) ?DN_ACCESS :DN_MODIFY ); +if ((ret + (type ==READ )) >0 ) { +struct dentry *dentry = file->f_dentry; +if (type ==READ ) +fsnotify_access (dentry, dentry->d_inode, + dentry->d_name.name); +else +fsnotify_modify (dentry, dentry->d_inode, + dentry->d_name.name); + }return ret; }
only in patch2:
unchanged:
include/linux/fsnotify.h +225 -0
225 lines not on this page · raw message
Re: 2.6.11-rc2-mm1
In reply to Christoph HellwigQuoted 5 lines · Christoph Hellwig
Quoted 2 lines
inotify.patch
inotifyAlso ioctl is not an acceptable interface for adding new core functionality.
seconded. Robert?
Ingo
Re: 2.6.11-rc2-mm1
On Mon, 2005-02-07 at 12:57 +0100, Ingo Molnar wrote:
Hello, Ingo.
Quoted 4 lines
Quoted 2 lines
Also ioctl is not an acceptable interface for adding new core functionality.
seconded. Robert?
Well, I don't share the hatred for ioctl, at least compared to another type unsafe interface like write().
But John and I are open to doing whatever is the consensus. If there is an agreed alternative, and that is the requirement for merging, I'll do it.
I'd like to keep the user-space interface and simple, and absolutely want to keep the single file descriptor approach. How the fd is obtained is up for discussion.
Ingo, what do you prefer?
Best,
Robert Love
Re: 2.6.11-rc2-mm1
Quoted 6 lines · Robert Love
Well, I don't share the hatred for ioctl, at least compared to another type unsafe interface like
write().But John and I are open to doing whatever is the consensus. If there is an agreed alternative, and that is the requirement for merging, I'll do it.
Yes, if ioctl is unacceptable, then providing a write() interface is what we will do.
Quoted 4 lines
I'd like to keep the user-space interface and simple, and absolutely want to keep the single file descriptor approach. How the fd is obtained is up for discussion.
I would still like to keep the character device as the interface for getting the fd. I don't see what benefit could be gained by converting to a syscall based interface for getting the fd.
Signature · 1 line
John McCutchan <[email protected]>
PATCH 1/1 fix SuperIO compilation
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
...
Changes since 2.6.11-rc1-mm2:
...
bk-i2c.patch
...
Latest versions of various bk trees
...
This causes the following compile error:
<-- snip -->
...
LD drivers/superio/built-in.o
drivers/superio/sc_acb.o(.text+0x0): In function `sc_write_reg':
: multiple definition of sc_write_reg' drivers/superio/sc_gpio.o(.text+0x0): first defined here drivers/superio/sc_acb.o(.text+0x30): In function sc_read_reg':
: multiple definition of `sc_read_reg' drivers/superio/sc_gpio.o(.text+0x30): first defined here make[2]: *** [drivers/superio/built-in.o] Error 1
<-- snip -->
The trivial fix for these needlessly global functions is below.
BTW1: pin_test.c is added but completely unused.
BTW2: bk-i2c adds a whole bunch of unused SuperIO EXPORT_SYMBOL's.
Is usage for them expected very soon or shall I send a patch to remove them?
<-- snip -->
This patch makes needlessly global functions static fixing a compile error if both sc_acb.c and sc_gpio.c are compiled statically into the kernel.
---
drivers/superio/sc_acb.c | 4 ++-- drivers/superio/sc_gpio.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
drivers/superio/sc_acb.c renamed from drivers/superio/sc_acb.c.old +2 -2
@@ -48,13 +48,13 @@ .orig_ldev = NULL, }; -void sc_write_reg (struct sc_dev *dev,u8 reg,u8 val) +static void sc_write_reg (struct sc_dev *dev,u8 reg,u8 val) {outb (reg, dev->base_index);outb (val, dev->base_data); } -u8 sc_read_reg (struct sc_dev *dev,u8 reg) +static u8 sc_read_reg (struct sc_dev *dev,u8 reg) {u8 val;
drivers/superio/sc_gpio.c renamed from drivers/superio/sc_gpio.c.old +2 -2
@@ -50,13 +50,13 @@static void sc_gpio_write_event (void *data,int pin_number,u8 byte); -void sc_write_reg (struct sc_dev *dev,u8 reg,u8 val) +static void sc_write_reg (struct sc_dev *dev,u8 reg,u8 val) {outb (reg, dev->base_index);outb (val, dev->base_data); } -u8 sc_read_reg (struct sc_dev *dev,u8 reg) +static u8 sc_read_reg (struct sc_dev *dev,u8 reg) {u8 val;
Re: [-mm patch] fix SuperIO compilation
Quoted 10 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.11-rc1-mm2:
...
bk-i2c.patch
...
Latest versions of various bk trees
...This causes the following compile error:
Where's that code coming from anyone? Greg seems to be adding tons of not fully reviewed stuff lately..
Re: [-mm patch] fix SuperIO compilation
Quoted 10 lines · Christoph Hellwig
Quoted 9 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.11-rc1-mm2:
...
bk-i2c.patch
...
Latest versions of various bk trees
...
Quoted 4 lines
Quoted 1 line
This causes the following compile error:
Where's that code coming from anyone? Greg seems to be adding tons of not fully reviewed stuff lately..
That code was written by me.
Please provide full error output, since it is compiled successfully here.
Thank you.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [-mm patch] fix SuperIO compilation
Quoted 13 lines · Evgeniy Polyakov
Quoted 12 lines · Christoph Hellwig
Quoted 10 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.11-rc1-mm2:
...
bk-i2c.patch
...
Latest versions of various bk trees
...This causes the following compile error:
Quoted 8 lines
Quoted 2 lines
Where's that code coming from anyone? Greg seems to be adding tons of not fully reviewed stuff lately..
That code was written by me.
Please provide full error output, since it is compiled successfully here.Thank you.
Ok, I found following in the archive:
******************************************
Quoted 7 lines · Andrew Morton
...
Changes since 2.6.11-rc1-mm2:
...
bk-i2c.patch
...
Latest versions of various bk trees
...
This causes the following compile error:
<-- snip -->
...
LD drivers/superio/built-in.o
drivers/superio/sc_acb.o(.text+0x0): In function `sc_write_reg':
: multiple definition of sc_write_reg' drivers/superio/sc_gpio.o(.text+0x0): first defined here drivers/superio/sc_acb.o(.text+0x30): In function sc_read_reg':
: multiple definition of `sc_read_reg' drivers/superio/sc_gpio.o(.text+0x30): first defined here make[2]: *** [drivers/superio/built-in.o] Error 1
<-- snip -->
The trivial fix for these needlessly global functions is below.
BTW1: pin_test.c is added but completely unused.
BTW2: bk-i2c adds a whole bunch of unused SuperIO EXPORT_SYMBOL's.
Is usage for them expected very soon or shall I send a patch to remove them?
<-- snip -->
This patch makes needlessly global functions static fixing a compile error if both sc_acb.c and sc_gpio.c are compiled statically into the kernel.
*********************************
It is not Greg, but completely my fault and I agree with your changes. pin_test.c was added as example of how to use SuperIO subsystem, it is not supposed to be compiled, it is an example, probably it should live in Documentation/superio/example.c
Tahnk you for review.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
PATCH 1/1 superio: remove unneded exports and make some functions static.
Remove unneded exports and make some functions static.
diff -ru linux-2.6/drivers/superio.orig/sc_acb.clinux-2.6/drivers/superio/sc_acb.c
--- linux-2.6/drivers/superio.orig/sc_acb.c 2005-01-24
17:07:28.295779728 +0300
+++ linux-2.6/drivers/superio/sc_acb.c 2005-01-24 17:09:35.377460376
+0300
@@ -29,10 +29,10 @@
#include "sc.h"
#include "sc_acb.h"
-int sc_acb_activate(void *data);
-u8 sc_acb_read(void *data, int reg);
-void sc_acb_write(void *data, int reg, u8 byte);
-void sc_acb_control(void *data, int pin, u8 mask, u8 ctl); +static int sc_acb_activate(void *data);
+static u8 sc_acb_read(void *data, int reg);
+static void sc_acb_write(void *data, int reg, u8 byte); +static void sc_acb_control(void *data, int pin, u8 mask, u8 ctl);
static struct logical_dev ldev_acb = {
.name = "ACB",
@@ -48,13 +48,13 @@
.orig_ldev = NULL,
};
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val) +static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
{
outb(reg, dev->base_index);
outb(val, dev->base_data);
}
-u8 sc_read_reg(struct sc_dev *dev, u8 reg) +static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
{
u8 val;
@@ -64,7 +64,7 @@
return val;
}
-int sc_acb_activate(void *data)
+static int sc_acb_activate(void *data)
{
struct logical_dev *ldev = (struct logical_dev *)data; u8 val;
@@ -111,7 +111,7 @@
return 0;
}
-u8 sc_acb_read(void *data, int reg)
+static u8 sc_acb_read(void *data, int reg)
{
struct logical_dev *ldev = (struct logical_dev *)data; u8 val;
@@ -123,7 +123,7 @@
return val;
}
-void sc_acb_write(void *data, int reg, u8 byte) +static void sc_acb_write(void *data, int reg, u8 byte)
{
struct logical_dev *ldev = (struct logical_dev *)data;
@@ -132,7 +132,7 @@
outb(byte, ldev->base_addr + reg);
}
-void sc_acb_control(void *data, int pin, u8 mask, u8 ctl) +static void sc_acb_control(void *data, int pin, u8 mask, u8 ctl)
{
}
@@ -156,8 +156,3 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Evgeniy Polyakov <[email protected]>"); MODULE_DESCRIPTION("Driver for Access Bus logical device.");
-
-EXPORT_SYMBOL(sc_acb_activate); -EXPORT_SYMBOL(sc_acb_read); -EXPORT_SYMBOL(sc_acb_write); -EXPORT_SYMBOL(sc_acb_control);
diff -ru linux-2.6/drivers/superio.orig/sc_gpio.c linux-2.6/drivers/superio/sc_gpio.c
--- linux-2.6/drivers/superio.orig/sc_gpio.c 2005-01-24
17:07:28.305778208 +0300
+++ linux-2.6/drivers/superio/sc_gpio.c 2005-01-24 17:10:44.808905192
+0300
@@ -31,6 +31,14 @@
static struct gpio_pin gpin[SIO_GPIO_NPINS];
+static int sc_gpio_activate(void *);
+static u8 sc_gpio_read(void *, int);
+static void sc_gpio_write(void *, int, u8);
+static void sc_gpio_control(void *, int, u8, u8);
+static void sc_gpio_pin_select(void *, int);
+static irqreturn_t sc_gpio_interrupt(int, void *, struct pt_regs *); +
+
static struct logical_dev ldev_gpio = {
.name = "GPIO",
.index = SIO_LDN_GPIO,
@@ -50,13 +58,13 @@
static void sc_gpio_write_event(void *data, int pin_number, u8 byte);
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val) +static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
{
outb(reg, dev->base_index);
outb(val, dev->base_data);
}
-u8 sc_read_reg(struct sc_dev *dev, u8 reg) +static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
{
u8 val;
@@ -66,7 +74,7 @@
return val;
}
-irqreturn_t sc_gpio_interrupt(int irq, void *data, struct pt_regs * regs)
+static irqreturn_t sc_gpio_interrupt(int irq, void *data, struct pt_regs * regs)
{
struct logical_dev *ldev = (struct logical_dev *)data; static u8 r[4], e[2], s[2];
@@ -122,7 +130,7 @@
}
-void sc_gpio_pin_select(void *data, int pin_number) +static void sc_gpio_pin_select(void *data, int pin_number)
{
struct logical_dev *ldev = (struct logical_dev *)data; int port, pin;
@@ -136,7 +144,7 @@
sc_write_reg(ldev->pdev, SIO_GPIO_PINSEL, val);
}
-int sc_gpio_activate(void *data)
+static int sc_gpio_activate(void *data)
{
struct logical_dev *ldev = (struct logical_dev *)data; int i;
@@ -161,7 +169,7 @@
return 0;
}
-u8 sc_gpio_read(void *data, int pin_number)
+static u8 sc_gpio_read(void *data, int pin_number)
{
struct logical_dev *ldev = (struct logical_dev *)data; int port, pin;
@@ -222,7 +230,7 @@
outb(1<<pin, ldev->base_addr + reg+1);
}
-void sc_gpio_write(void *data, int pin_number, u8 byte) +static void sc_gpio_write(void *data, int pin_number, u8 byte)
{
struct logical_dev *ldev = (struct logical_dev *)data; int port, pin;
@@ -263,7 +271,7 @@
outb(val, ldev->base_addr + reg);
}
-void sc_gpio_control(void *data, int pin, u8 mask, u8 ctl) +static void sc_gpio_control(void *data, int pin, u8 mask, u8 ctl)
{
struct logical_dev *ldev = (struct logical_dev *)data; u8 cfg, ev;
@@ -302,9 +310,3 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Evgeniy Polyakov <[email protected]>"); MODULE_DESCRIPTION("Driver for GPIO logical device.");
-
-EXPORT_SYMBOL(sc_gpio_activate); -EXPORT_SYMBOL(sc_gpio_read); -EXPORT_SYMBOL(sc_gpio_write); -EXPORT_SYMBOL(sc_gpio_control); -EXPORT_SYMBOL(sc_gpio_pin_select);
diff -ru linux-2.6/drivers/superio.orig/sc_gpio.h linux-2.6/drivers/superio/sc_gpio.h
--- linux-2.6/drivers/superio.orig/sc_gpio.h 2005-01-24
17:07:28.305778208 +0300
+++ linux-2.6/drivers/superio/sc_gpio.h 2005-01-24 17:10:26.750650464
+0300
@@ -40,13 +40,6 @@
#define SIO_GPIO_CONF_EVENT_POLAR_RIS (1 << 5)
#define SIO_GPIO_CONF_DEBOUNCE (1 << 6)
-int sc_gpio_activate(void *);
-u8 sc_gpio_read(void *, int);
-void sc_gpio_write(void *, int, u8);
-void sc_gpio_control(void *, int, u8, u8);
-void sc_gpio_pin_select(void *, int);
-irqreturn_t sc_gpio_interrupt(int, void *, struct pt_regs *); -
struct gpio_pin
{
u8 state;
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Greg KH
AppliedRe: [1/1] superio: remove unneded exports and make some functions static.
Quoted 3 lines · Evgeniy Polyakov
Remove unneded exports and make some functions static.
Signed-off-by Evgeniy Polyakov <[email protected]>
Applied, thanks.
greg k-h
2.6.11-rc2-mm1: DVB compile error
In reply to Andrew MortonThe following compile error comes from Linus' tree:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o(.bss+0xd50e4): multiple definition of `debug' arch/i386/kernel/built-in.o(.text+0x2e4c): first defined here
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
The offender is in drivers/media/dvb/dibusb/dvb-dibusb-core.c:
"debug" is not a good name for a global variable...
cu
Adrian
Signature · 4 lines
"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 SeedRe: [linux-dvb-maintainer] 2.6.11-rc2-mm1: DVB compile error
Quoted 10 lines · Adrian Bunk
The following compile error comes from Linus' tree:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o(.bss+0xd50e4): multiple definition of `debug' arch/i386/kernel/built-in.o(.text+0x2e4c): first defined here
make: *** [.tmp_vmlinux1] Error 1
Quoted 6 lines
<-- snip -->
The offender is in
drivers/media/dvb/dibusb/dvb-dibusb-core.c:"debug" is not a good name for a global variable...
I've sorted this out with Patrick. The attached patch cleans up various aspects of dibusb module argument handling, so it's a bit larger than just renaming "debug".
Andrew, could you please make sure this patch and
dib3000mc-build-fix.patch (from rc2-mm1) will be
merged into Linus tree before 2.6.11? Or should I
submit it to Linus seperately?
Thanks,
Johannes
drivers/media/dvb/dibusb/dvb-dibusb-core.c +12 -6
@@ -27,17 +27,19 @@#include <linux/moduleparam.h> /* debug */ -#ifdef CONFIG_DVB_DIBCOM_DEBUG -int debug; -module_param (debug, int,0644 ); -MODULE_PARM_DESC (debug,"set debugging level (1=info,2=xfer,4=alotmore,8=ts,16=err,32=rc (|-able))." ); +int dvb_dibusb_debug; +module_param_named (debug, dvb_dibusb_debug, int,0644 ); +MODULE_PARM_DESC (debug,"set debugging level (1=info,2=xfer,4=alotmore,8=ts,16=err,32=rc (|-able))." +#ifndef CONFIG_DVB_DIBCOM_DEBUG +" (debugging is not enabled)" #endif +); -int pid_parse; +static int pid_parse;module_param (pid_parse, int,0644 );MODULE_PARM_DESC (pid_parse,"enable pid parsing (filtering) when running at USB2.0" ); -int rc_query_interval; +static int rc_query_interval;module_param (rc_query_interval, int,0644 );MODULE_PARM_DESC (rc_query_interval,"interval in msecs for remote control query (default: 100; min: 40)" );
@@ -410,6 +412,10 @@ static int dibusb_probe(struct usb_inter dib->udev = udev; dib->dibdev = dibdev; +/* store parameters to structures */ + dib->rc_query_interval = rc_query_interval; + dib->pid_parse = pid_parse; +usb_set_intfdata (intf, dib); ret =dibusb_init (dib);
drivers/media/dvb/dibusb/dvb-dibusb-remote.c +5 -5
@@ -143,7 +143,7 @@ static void dibusb_remote_query(void *daif we're busy. */ dibusb_read_remote_control (dib);schedule_delayed_work (&dib->rc_query_work, -msecs_to_jiffies (rc_query_interval)); +msecs_to_jiffies (dib->rc_query_interval)); }int dibusb_remote_init (struct usb_dibusb *dib)
@@ -171,11 +171,11 @@ int dibusb_remote_init(struct usb_dibusbINIT_WORK (&dib->rc_query_work, dibusb_remote_query, dib);/* Start the remote-control polling. */ -if (rc_query_interval <40 ) - rc_query_interval =100 ;/* default */ +if (dib->rc_query_interval <40 ) + dib->rc_query_interval =100 ;/* default */ -info ("schedule remote query interval to %d msecs." ,rc_query_interval); -schedule_delayed_work (&dib->rc_query_work,msecs_to_jiffies (rc_query_interval)); +info ("schedule remote query interval to %d msecs." ,dib->rc_query_interval); +schedule_delayed_work (&dib->rc_query_work,msecs_to_jiffies (dib->rc_query_interval)); dib->init_state |=DIBUSB_STATE_REMOTE ;
drivers/media/dvb/dibusb/dvb-dibusb-usb.c +9 -5
@@ -158,7 +158,7 @@ int dibusb_streaming(struct usb_dibusb *int dibusb_urb_init (struct usb_dibusb *dib) { -int ret,i,bufsize; +int ret,i,bufsize,def_pid_parse =1 ;/* * when reloading the driver w/o replugging the device
@@ -210,12 +210,14 @@ int dibusb_urb_init(struct usb_dibusb *d dib->init_state |=DIBUSB_STATE_URB_SUBMIT ; } - - dib->pid_parse =1 ; +/* dib->pid_parse here contains the value of the module parameter */ +/* decide if pid parsing can be deactivated: +* is possible (by speed) and wanted (by user) +*/ switch (dib->dibdev->dev_cl->id) {case DIBUSB2_0 : -if (dib->udev->speed ==USB_SPEED_HIGH && !pid_parse) { - dib->pid_parse =0 ; +if (dib->udev->speed ==USB_SPEED_HIGH && !dib->pid_parse) { + def_pid_parse =0 ;info ("running at HIGH speed, will deliver the complete TS." ); }else info ("will use pid_parsing." );
@@ -223,6 +225,8 @@ int dibusb_urb_init(struct usb_dibusb *ddefault :break ; } +/* from here on it contains the device and user decision */ + dib->pid_parse = def_pid_parse;return 0 ; }
drivers/media/dvb/dibusb/dvb-dibusb.h +9 -11
@@ -27,31 +27,26 @@/* debug */ #ifdef CONFIG_DVB_DIBCOM_DEBUG #define dprintk(level,args...) \ - do { if ((debug & level)) { printk(args); } } while (0) + do { if ((dvb_dibusb_debug & level)) { printk(args); } } while (0) -#define debug_dump (b,l) if (debug) {\ - int i; deb_xfer("%s: %d > ",__FUNCTION__,l); \ +#define debug_dump (b,l) {\ + int i; \ for (i = 0; i < l; i++) deb_xfer("%02x ", b[i]); \ deb_xfer("\n");\ } -/* module parameters - declared in -core.c */ -extern int debug; -#else #define dprintk(args...)#define debug_dump (b,l)#endif +extern int dvb_dibusb_debug; +/* Version information */ #define DRIVER_VERSION "0.3"#define DRIVER_DESC "Driver for DiBcom based USB Budget DVB-T device"#define DRIVER_AUTHOR "Patrick Boettcher, [email protected]" -/* module parameters - declared in -core.c */ -extern int pid_parse; -extern int rc_query_interval; - #define deb_info(args...) dprintk(0x01,args) #define deb_xfer(args...) dprintk(0x02,args) #define deb_alot(args...) dprintk(0x04,args)
@@ -162,7 +157,6 @@ struct usb_dibusb {int init_state;int feedcount; -int pid_parse;struct dib_fe_xfer_ops xfer_ops;struct dibusb_tuner *tuner;
@@ -196,6 +190,10 @@ struct usb_dibusb {struct input_dev rc_input_dev;struct work_struct rc_query_work;int rc_input_event; + +/* module parameters */ +int pid_parse; +int rc_query_interval; };/* commonly used functions in the separated files */
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonHi,
Quoted 5 lines · Andrew Morton
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
I introduced a stupid typo. The patch below should fix.
After completing rechecking and testing the patch I'll send you a rediffed version.
bye, Roman
drivers/char/vt.c +5 -3
@@ -212,6 +212,8 @@* Low-Level Functions */ +#define IS_FG (vc) ((vc)->vc_num == fg_console) +#ifdef VT_BUF_VRAM_ONLY #define DO_UPDATE (vc) 0#else
@@ -544,7 +546,7 @@static void set_cursor (struct vc_data *vc) { -if (!vc->vc_num != fg_console || console_blanked || +if (!IS_FG (vc) || console_blanked || vc->vc_mode ==KD_GRAPHICS )return ;if (vc->vc_deccm) {
@@ -1953,7 +1955,7 @@ charmask = himask ?0x1ff :0xff ;/* undraw cursor first */ -if (currcons == fg_console) +if (IS_FG (vc))hide_cursor (vc);while (!tty->stopped && count) {
@@ -2166,7 +2168,7 @@ goto quit;/* undraw cursor first */ -if (vc->vc_num == fg_console) +if (IS_FG (vc))hide_cursor (vc); start = (ushort *)vc->vc_pos;
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 1 line
bk-i2c.patch
This contains two new subsystems, both aren't exactly the nicest code on earth and one isn't even explained what it is. And both aren't really i2c-related.
Greg, any chance you could stop funneling new tasteless code in through the backdoor?
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 14 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Quoted 4 lines
Changes since 2.6.11-rc1-mm2:
bk-netdev.patch
Without the following patch, it doesn't compile with ip_conntrack and without ip_nat.
In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34:include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter manip' has incomplete type include/linux/netfilter_ipv4/ip_conntrack.h: In function ip_nat_initialized':include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function)
regards,
Benoit
include/linux/netfilter_ipv4/ip_conntrack.h +2 -0
@@ -301,6 +301,7 @@ struct ip_conntrack_stat#define CONNTRACK_STAT_INC (count) (__get_cpu_var(ip_conntrack_stat).count++) +#ifdef CONFIG_IP_NF_NAT_NEEDED static inline int ip_nat_initialized (struct ip_conntrack *conntrack,enum ip_nat_manip_type manip) {
@@ -308,5 +309,6 @@ static inline int ip_nat_initialized(strreturn test_bit (IPS_SRC_NAT_DONE_BIT , &conntrack->status);return test_bit (IPS_DST_NAT_DONE_BIT , &conntrack->status); } +#endif /* CONFIG_IP_NF_NAT_NEEDED */ #endif /* __KERNEL__ */ #endif /* _IP_CONNTRACK_H */
Re: 2.6.11-rc2-mm1 [compile fix]
In reply to Andrew MortonQuoted 7 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
Quoted 9 lines
Changes since 2.6.11-rc1-mm2:
[snip]
+kernel-forkc-make-mm_cachep-static.patch
Little fixes.
It breaks compilation with gcc-4.0
kernel/fork.c:1249: error: static declaration of ‘mm_cachep’ follows non-static declaration include/linux/slab.h:117: error: previous declaration of ‘mm_cachep’ was here make[1]: *** [kernel/fork.o] Error 1
make: *** [kernel] Error 2
include/linux/slab.h.new renamed from include/linux/slab.h +0 -1
@@ -114,7 +114,6 @@ extern int FASTCALL(kmem_ptr_validate(km /* System wide caches */ extern kmem_cache_t *vm_area_cachep; -extern kmem_cache_t *mm_cachep; extern kmem_cache_t *names_cachep; extern kmem_cache_t *files_cachep; extern kmem_cache_t *filp_cachep;
kernel/fork.c +18 -18
@@ -81,6 +81,24 @@ int nr_processes(void)static kmem_cache_t *task_struct_cachep;#endif +/* SLAB cache for signal_struct structures (tsk->signal) */ +kmem_cache_t *signal_cachep; + +/* SLAB cache for sighand_struct structures (tsk->sighand) */ +kmem_cache_t *sighand_cachep; + +/* SLAB cache for files_struct structures (tsk->files) */ +kmem_cache_t *files_cachep; + +/* SLAB cache for fs_struct structures (tsk->fs) */ +kmem_cache_t *fs_cachep; + +/* SLAB cache for vm_area_struct structures */ +kmem_cache_t *vm_area_cachep; + +/* SLAB cache for mm_struct structures (tsk->mm) */ +static kmem_cache_t *mm_cachep; +void free_task (struct task_struct *tsk) {free_thread_info (tsk->thread_info);
@@ -1230,24 +1248,6 @@ long do_fork(unsigned long clone_flags,return pid; } -/* SLAB cache for signal_struct structures (tsk->signal) */ -kmem_cache_t *signal_cachep; - -/* SLAB cache for sighand_struct structures (tsk->sighand) */ -kmem_cache_t *sighand_cachep; - -/* SLAB cache for files_struct structures (tsk->files) */ -kmem_cache_t *files_cachep; - -/* SLAB cache for fs_struct structures (tsk->fs) */ -kmem_cache_t *fs_cachep; - -/* SLAB cache for vm_area_struct structures */ -kmem_cache_t *vm_area_cachep; - -/* SLAB cache for mm_struct structures (tsk->mm) */ -static kmem_cache_t *mm_cachep; -void __init proc_caches_init (void ) { sighand_cachep = kmem_cache_create("sighand_cache",
Re: 2.6.11-rc2-mm1 [compile fix]
Quoted 17 lines · Benoit Boissinot
Quoted 7 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
Quoted 9 lines
Changes since 2.6.11-rc1-mm2:
[snip]
+kernel-forkc-make-mm_cachep-static.patch
Little fixes.
Quoted 7 lines
It breaks compilation with gcc-4.0
kernel/fork.c:1249: error: static declaration of ???mm_cachep??? follows non-static declarationinclude/linux/slab.h:117: error: previous declaration of ???mm_cachep??? was here make[1]: *** [kernel/fork.o] Error 1
make: *** [kernel] Error 2
...
Ups, yes, thanks. This was my fault.
cu
Adrian
Signature · 4 lines
"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 Seed2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Andrew MortonIt seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
Only one of them can be loaded in a time.
So what does exactly bother you?
Quoted 9 lines
cu
AdrianSignature · 4 lines
"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
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 8 lines · Evgeniy Polyakov
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
The Kconfig files allow building both modular at the same time.
Quoted 1 line
Only one of them can be loaded in a time.
You are assuming the module support was in able to correctly handle two modules with the same name...
Quoted 1 line
So what does exactly bother you?
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.11-rc2-mm1; fi
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 19 lines · On Mon, 24 Jan 2005 19:29:26 +0100 Adrian Bunk <[email protected]> wrote:
Quoted 8 lines · Evgeniy Polyakov
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
The
Kconfigfiles allow building both modular at the same time.Quoted 1 line
Only one of them can be loaded in a time.
You are assuming the module support was in able to correctly handle two modules with the same name...
Quoted 1 line
So what does exactly bother you?
Quoted 7 lines
if [ -r System.map ]; then
/sbin/depmod-ae -F System.map 2.6.11-rc2-mm1; fi
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_base
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_configure
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_shadow
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_base
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_configure
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_shadow
Sorry, I can not buy it.
Above symbols are defined in old scx200 driver, and I it is depmod who tries to get them from superio.
I definitely sure that it must be solved on the other layers.
But nevertheless, obviously it is much easier to change superio's scx200 name and I will do it.
Quoted 10 lines
cu
AdrianSignature · 4 lines
"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
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 30 lines · Evgeniy Polyakov
Quoted 19 lines · On Mon, 24 Jan 2005 19:29:26 +0100 Adrian Bunk <[email protected]> wrote:
Quoted 8 lines · Evgeniy Polyakov
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
The
Kconfigfiles allow building both modular at the same time.Quoted 1 line
Only one of them can be loaded in a time.
You are assuming the module support was in able to correctly handle two modules with the same name...
Quoted 1 line
So what does exactly bother you?
Quoted 7 lines
if [ -r System.map ]; then
/sbin/depmod-ae -F System.map 2.6.11-rc2-mm1; fi
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_base
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_configure
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_shadow
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_base
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_configure
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_shadow
Quoted 3 lines
Sorry, I can not buy it.
Above symbols are defined in old scx200 driver, and I it is depmod who tries to get them from superio.
More exactly, "make modules_install" does install only one of the two drivers.
Quoted 2 lines
I definitely sure that it must be solved on the other layers.
...
Two modules with the same name are simply a _very_ bad idea.
Even if they weren't allowed to be compiled at the same time, they should be named differently or it will cause much confusion for everyone (or don't you want to see from the output of "lsmod" which of the two modules is loaded?).
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 41 lines · On Mon, 24 Jan 2005 20:03:20 +0100 Adrian Bunk <[email protected]> wrote:
Quoted 30 lines · Evgeniy Polyakov
Quoted 19 lines · On Mon, 24 Jan 2005 19:29:26 +0100 Adrian Bunk <[email protected]> wrote:
Quoted 8 lines · Evgeniy Polyakov
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
The
Kconfigfiles allow building both modular at the same time.Quoted 1 line
Only one of them can be loaded in a time.
You are assuming the module support was in able to correctly handle two modules with the same name...
Quoted 1 line
So what does exactly bother you?
Quoted 7 lines
if [ -r System.map ]; then
/sbin/depmod-ae -F System.map 2.6.11-rc2-mm1; fi
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_base
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_configure
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.koneeds unknown symbolscx200_gpio_shadow
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_base
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_configure
WARNING:/lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.koneeds unknown symbolscx200_gpio_shadowQuoted 3 lines
Sorry, I can not buy it.
Above symbols are defined in old scx200 driver, and I it is depmod who tries to get them from superio.More exactly, "make
modules_install" does install only one of the two drivers.Quoted 2 lines
I definitely sure that it must be solved on the other layers.
...
Quoted 6 lines
Two modules with the same name are simply a _very_ bad idea.
Even if they weren't allowed to be compiled at the same time, they should be named differently or it will cause much confusion for everyone (or don't you want to see from the output of "lsmod" which of the two modules is loaded?).
I do not agree with you, Adrian, but I will not contend. As I say, noone protects against the same program names and there are mechnisms to differ modules by simply looking in lsmod output. Noone can damage systrem by loading "wrong" module.
So I still do not see problems here.
As I say I will change superio scx200 name since it is easier than flood about unmatched points of view.
I will send patch through Greg and Andrew later.
Thank you, Adrian, for your comments.
Quoted 9 lines
cu
AdrianSignature · 4 lines
"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
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Evgeniy PolyakovFrom: Evgeniy Polyakov <[email protected]>
Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
Quoted 12 lines
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
Only one of them can be loaded in a time.So what does exactly bother you?
lsmod in bugreports giving unspecific results, for example.
Kind regards,
Jurriaan
Signature · 5 lines
"So you believe." Jewel ATerafin shrugged. "I have more than belief, but I don't have a pressing need to convince you of anything." Michelle West - Sea of Sorrows. Debian (Unstable) GNU/Linux 2.6.10-mm1 2x6078 bogomips load 0.52
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 8 lines · On Mon, 24 Jan 2005 19:41:11 +0100 Jurriaan <[email protected]> wrote:
From: Evgeniy Polyakov <[email protected]>
Date: Mon, Jan 24, 2005 at 09:43:36PM +0300Quoted 6 lines
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
Quoted 7 lines
Quoted 6 lines
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
Only one of them can be loaded in a time.So what does exactly bother you?
lsmod in bugreports giving unspecific results, for example.
If you load scx200 from superio subsystem, then obviously you can not use old i2c/acb modules which require old scx200.
And vice versa.
One needs to load exactly what he wants.
Quoted 8 lines
Kind regards,
JurriaanSignature · 5 lines
"So you believe." Jewel ATerafin shrugged. "I have more than belief, but I don't have a pressing need to convince you of anything." Michelle West - Sea of Sorrows. Debian (Unstable) GNU/Linux 2.6.10-mm1 2x6078 bogomips load 0.52
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 17 lines · Evgeniy Polyakov
Quoted 14 lines · On Mon, 24 Jan 2005 19:41:11 +0100 Jurriaan <[email protected]> wrote:
From: Evgeniy Polyakov <[email protected]>
Date: Mon, Jan 24, 2005 at 09:43:36PM +0300Quoted 12 lines
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
Only one of them can be loaded in a time.So what does exactly bother you?
Quoted 7 lines
Quoted 1 line
lsmod in bugreports giving unspecific results, for example.
If you load scx200 from superio subsystem, then obviously you can not use old i2c/acb modules which require old scx200.
And vice versa.One needs to load exactly what he wants.
You did not understand what Jurriaan said:
Even if it was working, "lsmod" would not be able to tell which of the two modules was loaded.
This would cause much headache for many people.
Quoted 4 lines
Quoted 2 lines
Kind regards,
JurriaanEvgeniy Polyakov
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 24 lines · On Mon, 24 Jan 2005 20:05:46 +0100 Adrian Bunk <[email protected]> wrote:
Quoted 23 lines · Evgeniy Polyakov
Quoted 8 lines · On Mon, 24 Jan 2005 19:41:11 +0100 Jurriaan <[email protected]> wrote:
From: Evgeniy Polyakov <[email protected]>
Date: Mon, Jan 24, 2005 at 09:43:36PM +0300Quoted 6 lines
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
Quoted 7 lines
Quoted 6 lines
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
Only one of them can be loaded in a time.So what does exactly bother you?
lsmod in bugreports giving unspecific results, for example.
If you load scx200 from superio subsystem, then obviously you can not use old i2c/acb modules which require old scx200.
And vice versa.
Quoted 8 lines
Quoted 1 line
One needs to load exactly what he wants.
You did not understand what Jurriaan said:
Even if it was working, "lsmod" would not be able to tell which of the two modules was loaded.
This would cause much headache for many people.
Module is just a piece of code, or programm if someone may think. And there no problems when we type
$ ps and see only "aterm", if someone wants to know what exactly means "aterm", one can run ps axufw. And even with the case of lsmod: one can see that scx200 will or will not depend on superio, and that will explain everything.
Quoted 14 lines
Quoted 4 lines
Quoted 2 lines
Kind regards,
JurriaanEvgeniy Polyakov
cu
AdrianSignature · 4 lines
"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
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 37 lines · Evgeniy Polyakov
Quoted 24 lines · On Mon, 24 Jan 2005 20:05:46 +0100 Adrian Bunk <[email protected]> wrote:
Quoted 23 lines · Evgeniy Polyakov
Quoted 8 lines · On Mon, 24 Jan 2005 19:41:11 +0100 Jurriaan <[email protected]> wrote:
From: Evgeniy Polyakov <[email protected]>
Date: Mon, Jan 24, 2005 at 09:43:36PM +0300Quoted 6 lines
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
Quoted 7 lines
Quoted 6 lines
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
Only one of them can be loaded in a time.So what does exactly bother you?
lsmod in bugreports giving unspecific results, for example.
If you load scx200 from superio subsystem, then obviously you can not use old i2c/acb modules which require old scx200.
And vice versa.Quoted 8 lines
Quoted 1 line
One needs to load exactly what he wants.
You did not understand what Jurriaan said:
Even if it was working, "lsmod" would not be able to tell which of the two modules was loaded.
This would cause much headache for many people.
Quoted 8 lines
Module is just a piece of code, or programm if someone may think. And there no problems when we type
$ ps and see only "aterm", if someone wants to know what exactly means "aterm", one can run ps axufw. And even with the case of lsmod: one can see that scx200 will or will not depend on superio, and that will explain everything.
There are so many problems and ambiguites with having non-unique module names it is not even funny:
- when I modprobe scx200 what willI get?
- if I want to blacklist one of the modules (let's say hotplug) how do I do that?
- lsmod (with everything else compiled in, possible?) - which one is loadded?
...etc, etc...
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 16 lines · On Mon, 24 Jan 2005 14:32:19 -0500 Dmitry Torokhov <[email protected]>…
Quoted 16 lines
Quoted 14 lines
Quoted 7 lines
Quoted 1 line
lsmod in bugreports giving unspecific results, for example.
If you load scx200 from superio subsystem, then obviously you can not use old i2c/acb modules which require old scx200.
And vice versa.One needs to load exactly what he wants.
You did not understand what Jurriaan said:
Even if it was working, "lsmod" would not be able to tell which of the two modules was loaded.
This would cause much headache for many people.
Quoted 7 lines
Quoted 7 lines
Module is just a piece of code, or programm if someone may think. And there no problems when we type
$ ps and see only "aterm", if someone wants to know what exactly means "aterm", one can run ps axufw. And even with the case of lsmod: one can see that scx200 will or will not depend on superio, and that will explain everything.
Before I murdered in my bad, I want to say, that I agree that changing scx200 into scx is easier and probably better idea.
And I will do it(I am doing it right now),
Quoted 3 lines
There are so many problems and ambiguites with having non-unique module names it is not even funny:
- when I modprobe scx200 what willI get?
Sorry or answering with a question, but what will you run when typing aterm in your shell?
Is it simlink to xterm, or /bin/aterm, or /usr/local/bin/aterm? It depends on $PATH, with modprobe it depends on something else... Bug? Probably. Feature? Maybe. I do not complain.
Quoted 2 lines
- if I want to blacklist one of the modules (let's say hotplug) how do I do that?
When you want to run exact program, you type the whole path, no? Load exact modules with known-to-be-good pathes.
I can hack shell script over modprobe to warn if there are several modules with the same name, and ask exact path or something...
Quoted 1 line
- lsmod (with everything else compiled in, possible?) - which one is loadded?
/sbin/modinfo shows enough information about module to distingiush one from another.
Quoted 1 line
...etc, etc...
I understand your point of view, and can say, that the same module names are not very convenient and some times even confused, but it is not a cause to kill such idea and mark it as badly broken.
It is right thing, it just currently has some nitpicks, nothing more, noone complains that modules for different kernel versions have the same name, but different elf sections in it, it is of course different things, but they do have the same roots in common.
As I have beed told in private,
"what is technically possible, is not necessarily practically useful.", probably it is the essence.
Thank you for discussion.
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Evgeniy PolyakovQuoted 4 lines · Evgeniy Polyakov
On Mon, 24 Jan 2005 18:54:49 +0100
Adrian Bunk <[email protected]> wrote:
Quoted 8 lines
Quoted 1 line
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here. Only one of them can be loaded in a time.
So what does exactly bother you?
That I don't know how to select loading between modules with the same name. What's the trick?
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 9 lines · On Thu, 27 Jan 2005 10:19:51 -0500 Bill Davidsen <[email protected]> wrote:
Quoted 8 lines · Evgeniy Polyakov
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
Quoted 8 lines
Quoted 6 lines
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
Only one of them can be loaded in a time.So what does exactly bother you?
That I don't know how to select loading between modules with the same name. What's the trick?
Use full path.
Please see discussion in this thread related to module names.
Quoted 4 lines
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 16 lines · Evgeniy Polyakov
Quoted 13 lines · On Thu, 27 Jan 2005 10:19:51 -0500 Bill Davidsen <[email protected]> wrote:
Quoted 12 lines · Evgeniy Polyakov
Quoted 2 lines · On Mon, 24 Jan 2005 18:54:49 +0100 Adrian Bunk <[email protected]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced), so I do not see any problem here.
Only one of them can be loaded in a time.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
So what does exactly bother you?
That I don't know how to select loading between modules with the same name. What's the trick?
Use full path.
Please see discussion in this thread related to module names.
Ah-ha! I looked at the man page instead of the code. It's not obvious the "modulename" can be a full path, but the (possibly old) man page I have for modprobe.conf could be out of date. I'll go look at the code.
Thanks.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Adrian BunkQuoted 2 lines · Adrian Bunk
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
Did anyone review them?
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 5 lines · On Mon, 24 Jan 2005 20:33:53 +0000 Christoph Hellwig <[email protected]> wrote:
Quoted 2 lines · Adrian Bunk
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
Did anyone review them?
As I said it is completely my fault, I pressed on Greg, since patch several month laid after testing and people often asked about GPIO in various SuperIO chips.
Patches were sent into lm_sensors@ mail list some time ago and code itself did not meet any objections.
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Adrian BunkQuoted 2 lines · Adrian Bunk
It seems noone who reviewed the SuperIO patches noticed that there are now two modules "scx200" in the kernel...
Sorry about this. Andrew warning me about this bug, and I saw it myself with the depmod errors. I'll take Evgeniy's patch for my tree and it should show up in the next -mm release.
And as for the "these patches have never been reviewed" comments, that's why I put them in my tree, and have them show up in -mm. It's getting them a wider exposure and finding out these kinds of issues. So the process is working properly :)
thanks,
greg k-h
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 4 lines · Greg KH
And as for the "these patches have never been reviewed" comments, that's why I put them in my tree, and have them show up in -mm. It's getting them a wider exposure and finding out these kinds of issues. So the process is working properly :)
It would be a lot more productive to follow the normal rules, though. That is posting them on lkml as properly split up patches, and with proper descriptions of what they're doing.
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 9 lines · Christoph Hellwig
Quoted 4 lines · Greg KH
And as for the "these patches have never been reviewed" comments, that's why I put them in my tree, and have them show up in -mm. It's getting them a wider exposure and finding out these kinds of issues. So the process is working properly :)
It would be a lot more productive to follow the normal rules, though. That is posting them on lkml as properly split up patches, and with proper descriptions of what they're doing.
As previously mentioned, these patches have had that, on the sensors mailing list. Lots of review and comments went into them there, and the code was reworked quite a lot based on it.
Surely you don't want me to forward _every_ driver patch that I get to lkml first? :)
That's what all of the subsystem specific mailing lists are for...
thanks,
greg k-h
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 10 lines · Greg KH
Quoted 3 lines
It would be a lot more productive to follow the normal rules, though. That is posting them on lkml as properly split up patches, and with proper descriptions of what they're doing.
As previously mentioned, these patches have had that, on the sensors mailing list. Lots of review and comments went into them there, and the code was reworked quite a lot based on it.
Surely you don't want me to forward _every_ driver patch that I get to lkml first? :)
If you add completely new subsystems please send them to lkml first.
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Greg KHHi all,
Quoted 3 lines
As previously mentioned, these patches have had that, on the sensors mailing list. Lots of review and comments went into them there, and the code was reworked quite a lot based on it.
That's right, I did actually review Evgeniy's code some times ago, as can be seen here:
http://archives.andrew.net.au/lm-sensors/msg27817.html
I might however add the following:
1* This was 5 months ago. I'd expect Evgeniy's code to have significantly evolved since, so an additional review now would certainly be welcome.
2* I only reviewed the superio code. The acb part is completely new so I obviously couldn't comment on it back then, and I skipped the gpio part because I admittedly have no particular interest in this part.
3* Some of my objections have been ignored by Evgeniy. Among others, the choice of "sc" as a prefix for the superio stuff is definitely poor and has to be changed.
http://archives.andrew.net.au/lm-sensors/msg27847.html
I don't think that getting the whole stuff (superio, acb and gpio) merged at once is a good idea. Preferably we would merge superio alone first, then update the drivers that are already in the kernel and could make use of it (it87, w83627hf, pc87360 and smsc47m1, all of i2c/sensors fame, come to mind). This would help ensure that Evgeniy's interface choices were correct, and would additionally be a very good example of how this interface must be used. Then, and only then IMVHO, should the gpio and acb stuff be merged.
Before all this happens, I really would like Evgeniy to present an overall plan of his current superio implementation. Last time we discussed about this, we obviously had different views on the interface level that should be proposed by the superio core, as well as how chip-specific values should be handled (or, according to me, mostly not handled).
Please note that I am certainly not the most qualified of us all to review this code. What I can do is check whether I will be able to use the new superio interface in the sensor chip drivers I mentioned above, and that's about it. I am not familiar enough with kernel core architectures to decide whether Evgeniy's approach is correct or not. I am willing to help, but I can do so only within my own current skills.
Thanks,
Signature · 2 lines
Jean Delvare http://khali.linux-fr.org/
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 10 lines · On Tue, 25 Jan 2005 19:59:18 +0100 Jean Delvare <[email protected]> wrote:
Hi all,
Quoted 3 lines
As previously mentioned, these patches have had that, on the sensors mailing list. Lots of review and comments went into them there, and the code was reworked quite a lot based on it.
That's right, I did actually review Evgeniy's code some times ago, as can be seen here:
http://archives.andrew.net.au/lm-sensors/msg27817.html
Quoted 5 lines
I might however add the following:
1* This was 5 months ago. I'd expect Evgeniy's code to have significantly evolved since, so an additional review now would certainly be welcome.
superio core was not changed much, all related changes were posted into lm_sensors mail list and discussed.
Quoted 3 lines
2* I only reviewed the superio code. The acb part is completely new so I obviously couldn't comment on it back then, and I skipped the gpio part because I admittedly have no particular interest in this part.
acb and gpio are logical devices and are very simple.
It was design task to create such model, where each device is as simple as possible, and only handle low-level operations.
Quoted 5 lines
3* Some of my objections have been ignored by Evgeniy. Among others, the choice of "sc" as a prefix for the superio stuff is definitely poor and has to be changed.
Yep %)
SuperIO Control - is a good name, sio_ I've seen somewhere...
Quoted 9 lines
I don't think that getting the whole stuff (superio, acb and gpio) merged at once is a good idea. Preferably we would merge superio alone first, then update the drivers that are already in the kernel and could make use of it (it87, w83627hf, pc87360 and smsc47m1, all of i2c/sensors fame, come to mind). This would help ensure that Evgeniy's interface choices were correct, and would additionally be a very good example of how this interface must be used. Then, and only then IMVHO, should the gpio and acb stuff be merged.
Quoted 6 lines
Before all this happens, I really would like Evgeniy to present an overall plan of his current superio implementation. Last time we discussed about this, we obviously had different views on the interface level that should be proposed by the superio core, as well as how chip-specific values should be handled (or, according to me, mostly not handled).
GPIO and AccessBus are very simple devices, and I added them just because
1. people often asked exactly about GPIO
2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too, but noone never asked in any mail list about them, but I think it worth to implement.
Addind SuperIO itself does not have much sence that it can not be tested without at least one logical device, thus I added two.
Porting existing SuperIO devices to the new schema is a very good task, but I had only SC1100 processor and PC87366 chip, so I created and tested superio chip drivers for them.
Quoted 6 lines
Please note that I am certainly not the most qualified of us all to review this code. What I can do is check whether I will be able to use the new superio interface in the sensor chip drivers I mentioned above, and that's about it. I am not familiar enough with kernel core architectures to decide whether Evgeniy's approach is correct or not. I am willing to help, but I can do so only within my own current skills.
I always appreciate your comments, they are definitely right and helped me very much.
Thank you.
Quoted 4 lines
Thanks,
Signature · 2 lines
Jean Delvare http://khali.linux-fr.org/
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Hi Evgeniy & all,
Quoted 6 lines
Quoted 3 lines
1* This was 5 months ago. I'd expect Evgeniy's code to have significantly evolved since, so an additional review now would certainly be welcome.
superio core was not changed much, all related changes were posted into
lm_sensorsmail list and discussed.
Well, according to the mailing-list archives, which have a better memory than I do, I skipped at least one:
http://archives.andrew.net.au/lm-sensors/msg18655.html
So I suspect that this update at least was never reviewed by anyone (on the sensors list at least).
And while we are at it, this post by Andrew is certainly of interest too:
http://archives.andrew.net.au/lm-sensors/msg18749.html
Quoted 8 lines
Quoted 5 lines
3* Some of my objections have been ignored by Evgeniy. Among others, the choice of "sc" as a prefix for the superio stuff is definitely poor and has to be changed.
Yep %)
SuperIO Control - is a good name,sio_I've seen somewhere...
Sure, sio would be better, or even superio in whole. Anything that reminds "Super-I/O" is fine with me. sc doesn't.
Quoted 6 lines
GPIO and AccessBus are very simple devices, and I added them just because 1. people often asked exactly about GPIO
2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too, but noone never asked in any mail list about them, but I think it worth to implement.
Quoted 6 lines
Addind SuperIO itself does not have much sence that it can not be tested without at least one logical device, thus I added two.
Porting existing SuperIO devices to the new schema is a very good task, but I had only SC1100 processor and PC87366 chip, so I created and tested superio chip drivers for them.
The PC87366 has integrated sensors, some of which have to be connected whatever your configuration: voltage inputs 7 to 10 and third temperature channel. We have a driver for it in the kernel:drivers/i2c/chips/pc87360. So if you have such a chip, this is actually someone you can use as a test for your superio subsystem.
If you can provide a patch which adds your superio core driver and one which modifies the pc87360 driver to take make use of it, and only that, this would certainly be easier for everyone (and especially me) to review your superio code. Once this is in, incremental patches for the additional features should be easier for you to generate and for the rest of us to review.
Thanks,
Signature · 2 lines
Jean Delvare http://khali.linux-fr.org/
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 9 lines · On Tue, 25 Jan 2005 22:40:51 +0100 Jean Delvare <[email protected]> wrote:
Hi Evgeniy & all,
Quoted 6 lines
Quoted 3 lines
1* This was 5 months ago. I'd expect Evgeniy's code to have significantly evolved since, so an additional review now would certainly be welcome.
superio core was not changed much, all related changes were posted into
lm_sensorsmail list and discussed.
Quoted 7 lines
Well, according to the mailing-list archives, which have a better memory than I do, I skipped at least one:
http://archives.andrew.net.au/lm-sensors/msg18655.html
So I suspect that this update at least was never reviewed by anyone (on the sensors list at least).
I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects.
Quoted 4 lines
And while we are at it, this post by Andrew is certainly of interest too:
I believe he commented connector patch mostly - we had some very little private discussion that time about it.
I've posted connector patch several times to lkml - no answers except Alan Cox, thus noone objects but patch is very usefull.
Quoted 25 lines
Quoted 8 lines
Quoted 5 lines
3* Some of my objections have been ignored by Evgeniy. Among others, the choice of "sc" as a prefix for the superio stuff is definitely poor and has to be changed.
Yep %)
SuperIO Control - is a good name,sio_I've seen somewhere...Sure, sio would be better, or even superio in whole. Anything that reminds "Super-I/O" is fine with me. sc doesn't.
Quoted 6 lines
GPIO and AccessBus are very simple devices, and I added them just because 1. people often asked exactly about GPIO
2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too, but noone never asked in any mail list about them, but I think it worth to implement.Quoted 6 lines
Addind SuperIO itself does not have much sence that it can not be tested without at least one logical device, thus I added two.
Porting existing SuperIO devices to the new schema is a very good task, but I had only SC1100 processor and PC87366 chip, so I created and tested superio chip drivers for them.
Quoted 5 lines
The PC87366 has integrated sensors, some of which have to be connected whatever your configuration: voltage inputs 7 to 10 and third temperature channel. We have a driver for it in the kernel:
drivers/i2c/chips/pc87360. So if you have such a chip, this is actually someone you can use as a test for your superio subsystem.
Btw, they appeared almost the same time :)
Difference was about several days...
I have pc8736x logical devices in my TODO list, but they are currently preempted by acrypto, but I definitely will get it very soon.
Quoted 6 lines
If you can provide a patch which adds your superio core driver and one which modifies the pc87360 driver to take make use of it, and only that, this would certainly be easier for everyone (and especially me) to review your superio code. Once this is in, incremental patches for the additional features should be easier for you to generate and for the rest of us to review.
pc87360.c can not be used with superio as is, it requires big rewrite, since you implemented it as part of i2c core,
that is why I created parts that was not touched by your driver. Since GPIO can be used with w1 it had greater priority.
Your driver is part of i2c core, it just not supposed to be used in superio, although many hardware routings could be used.
I will use it as a base for other superio logical devices.
Quoted 4 lines
Thanks,
Signature · 2 lines
Jean Delvare http://khali.linux-fr.org/
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Hi Evgeniy,
Quoted 5 lines
Quoted 2 lines
So I suspect that this update at least was never reviewed by anyone (on the sensors list at least).
I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects.
Broken rule IMHO. This might be fine for your own projects, but doesn't work at all for the kernel. Silence might not mean that everyone agrees. Rather, it could mean that either people are just not interested at all, or they are too busy to review a whole new subsystem (or more) at the moment. Believe me, kernel folks are very, very busy.
Quoted 2 lines
I have pc8736x logical devices in my TODO list, but they are currently preempted by acrypto, but I definitely will get it very soon.
I don't think you get me. Your personal priorities are unimportant when you are asking for code review and merge into the main kernel tree. What matters is that parts are presented correctly and added in small chunks and in the right order, so as to minimize the time it takes to Greg and others to understand, review and accept it.
One year ago I learnt this the hard way myself. I realize how deep my misunderstanding of the situation was back then, and now praise Greg for the good lesson - however tough it was for me at that time - each time I now send a kernel patch the right way and get it accepted.
So, make yourself a favor and comply with what the kernel folks expect from you. They won't change for you.
Quoted 10 lines
Quoted 6 lines
If you can provide a patch which adds your superio core driver and one which modifies the pc87360 driver to take make use of it, and only that, this would certainly be easier for everyone (and especially me) to review your superio code. Once this is in, incremental patches for the additional features should be easier for you to generate and for the rest of us to review.
pc87360.ccan not be used with superio as is, it requires big rewrite, since you implemented it as part of i2c core,
that is why I created parts that was not touched by your driver.
Again, you clearly don't get it. The pc87360 driver does *not* require a big rewrite. Without even looking at your superio code again, I can tell that it is necessarily broken if every driver which accesses the superio address space at the moment needs a big rewrite.
The pc87360 driver only really uses the superio for hardware identification and then to get a couple configuration values (such as subdevice I/O addresses) at startup, and then leaves it alone forever. If we has a dedicated superio driver, it would need to provide an interface to read, and eventually write, these values, as a replacement for the savage direct accesses we do for now. Period. Anything else might be nice or useful for other logical devices (such as GPIOs) but is not strictly necessary at first.
I do not deny that these Super-I/O integrated sensors are not using the SMBus and as such do not truly belong to the i2c subsystem. It just happens that, for now and for historical reasons, the i2c subsystem is also where all hardware monitoring drivers are. That might (hopefully) change in the future, but this is a completely different problem. One thing at a time please.
Quoted 2 lines
Your driver is part of i2c core, it just not supposed to be used in superio, although many hardware routings could be used.
Again, some drivers in the i2c subsystem use ISA accesses; others need to poke a couple PCI configuration registers. We did not move these drivers to the ISA (is there even one?) or PCI subsystems. Before anything else, these drivers are hardware monitoring drivers, and such drivers belong - for now - to the i2c subsystem, until we can separate the i2c subsystem from the hardware monitoring function more clearly.
So, the pc87360, it87, smsc47m1 and w83627hf drivers are not going to move to the "superio subsystem", nor are they going to be rewritten for it. Superio chips are only a new way to access the subdevices. What we need for them is an extension of the request_region/release_region mechanism, because superios introduce a two-level addressing scheme. And this is about it.
Thanks,
--
Jean Delvare
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 5 lines · Jean Delvare
Hi Evgeniy,
Quoted 3 lines
Quoted 2 lines
So I suspect that this update at least was never reviewed by anyone (on the sensors list at least).
Quoted 8 lines
Quoted 2 lines
I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects.
Broken rule IMHO. This might be fine for your own projects, but doesn't work at all for the kernel. Silence might not mean that everyone agrees. Rather, it could mean that either people are just not interested at all, or they are too busy to review a whole new subsystem (or more) at the moment. Believe me, kernel folks are very, very busy.
Sigh.
I presented the code.
Several times in special mail list.
Only problem that it was not sent to lkml, where there are too many noise and flood. That is why while digging through it several years ago I decided to drop this mail list.
Quoted 9 lines
Quoted 2 lines
I have pc8736x logical devices in my TODO list, but they are currently preempted by acrypto, but I definitely will get it very soon.
I don't think you get me. Your personal priorities are unimportant when you are asking for code review and merge into the main kernel tree. What matters is that parts are presented correctly and added in small chunks and in the right order, so as to minimize the time it takes to Greg and others to understand, review and accept it.
Quoted 7 lines
One year ago I learnt this the hard way myself. I realize how deep my misunderstanding of the situation was back then, and now praise Greg for the good lesson - however tough it was for me at that time - each time I now send a kernel patch the right way and get it accepted.
So, make yourself a favor and comply with what the kernel folks expect from you. They won't change for you.
Mdee...
I do not understand you, what are you trying to say? Waht is wrong? I wrote the code.
I presented it.
I presented it again.
I presented it yeat another again.
First time people answered, then - not.
I ask for inclusion. It is included, and ohh now people recall, that they wanted to complain.
Ok, I want to listen what technical problems do you see?
Quoted 25 lines
Quoted 10 lines
Quoted 6 lines
If you can provide a patch which adds your superio core driver and one which modifies the pc87360 driver to take make use of it, and only that, this would certainly be easier for everyone (and especially me) to review your superio code. Once this is in, incremental patches for the additional features should be easier for you to generate and for the rest of us to review.
pc87360.ccan not be used with superio as is, it requires big rewrite, since you implemented it as part of i2c core,
that is why I created parts that was not touched by your driver.Again, you clearly don't get it. The pc87360 driver does *not* require a big rewrite. Without even looking at your superio code again, I can tell that it is necessarily broken if every driver which accesses the superio address space at the moment needs a big rewrite.
The pc87360 driver only really uses the superio for hardware identification and then to get a couple configuration values (such as subdevice I/O addresses) at startup, and then leaves it alone forever. If we has a dedicated superio driver, it would need to provide an interface to read, and eventually write, these values, as a replacement for the savage direct accesses we do for now. Period. Anything else might be nice or useful for other logical devices (such as GPIOs) but is not strictly necessary at first.
Quoted 6 lines
I do not deny that these Super-I/O integrated sensors are not using the SMBus and as such do not truly belong to the i2c subsystem. It just happens that, for now and for historical reasons, the i2c subsystem is also where all hardware monitoring drivers are. That might (hopefully) change in the future, but this is a completely different problem. One thing at a time please.
Sigh.
Jean, it looks like you forget how superio is designed.
Your pc87360 driver is all in one big piese of code, superio is splitted into absolutely separated modules - _one_ for superio chip, and _several_ for logical devices.
I need to split your driver into at least 5 parts - pc8736x initialisation(superio has it), i2c part(should be removed from superio code),
fan logical device(separate part), voltage monitor logical device (separate part)
and temperature monitor logical device(separate part).
They are just separate modules, it is design feature to use _the_ _same_,
for example, voltage monitor module with _any_ number of existent superio chips.
Quoted 10 lines
Quoted 2 lines
Your driver is part of i2c core, it just not supposed to be used in superio, although many hardware routings could be used.
Again, some drivers in the i2c subsystem use ISA accesses; others need to poke a couple PCI configuration registers. We did not move these drivers to the ISA (is there even one?) or PCI subsystems. Before anything else, these drivers are hardware monitoring drivers, and such drivers belong - for now - to the i2c subsystem, until we can separate the i2c subsystem from the hardware monitoring function more clearly.
Quoted 6 lines
So, the pc87360, it87, smsc47m1 and w83627hf drivers are not going to move to the "superio subsystem", nor are they going to be rewritten for it. Superio chips are only a new way to access the subdevices. What we need for them is an extension of the request_region/release_region mechanism, because superios introduce a two-level addressing scheme. And this is about it.
And that will end up having tons of duplicated code in each driver:
temp monitor in A, temp monitor in B and so on...
volt monitor in A, volt monitor in B and so on...
...
Jean, we already discussed it a bit in lm_sensors mail list AFAR...
Quoted 3 lines
Thanks,
--
Jean Delvare
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Hi Evgeniy,
Quoted 2 lines
I presented the code.
Several times in special mail list.
That's true. Except that the second time (at least) you didn't find anyone to review it. Also note that your patches are about superio, gpio and now access bus. The list is dedicated to hardware monitoring. This is no exact match, although it happens that some superio chips include hardware monitoring logical devices. So I reviewed the part I think I could help with, and skipped the rest (and I did tell the you, and the list, that I had).
Quoted 3 lines
Only problem that it was not sent to lkml, where there are too many noise and flood. That is why while digging through it several years ago I decided to drop this mail list.
I agree that there is a heavy traffic on LKML - I am not subscribed myself just because of that. However, when one introduces a completely new subsystem, it definitely needs review by folks that have way more knowledge about the kernel internals than I do - expecially about the (bus) driver model.
Quoted 7 lines
I do not understand you, what are you trying to say? Waht is wrong? I wrote the code.
I presented it.
I presented it again.
I presented it yeat another again.First time people answered, then - not.
OK, blame me for having a day job, a girlfriend and a family. Blame me for not having the necessary time and knowledge to review your code.
And then think about it again. Maybe you did not present it to the right person(s). Maybe you did not present it in the correct form. Maybe you didn't properly explain what problem you were trying to solve - and failed to catch people's attention because of that. And maybe you should not have ignored some of my comments - and others'. I would invite you to read your own recent posts to the LKML again. Most objections you have received about your code - some of which were so blantantly valid (several drivers with the same name is fine, no kidding) - you first denied that there were any problem, then grumbled, then accepted to change but just not to make any trouble - not because you were wrong. You are not going anywhere here with this attitude.
Sure, we, kernel developers as a whole, lack time to properly review all the code that is sent to us. Even me, and I probably receive one hundredth of what Greg, Andrew or Linus receive. And now what? That's the way it is and we (and you) have to live with it. If you want the situation to improve, you can volunteer to review some code. Andrew's broken-out directories and LKML are full of patches that need review. Or pick one subsystem and track the patches applied to it. Really, do not hesitate to help. You certainly will learn much about kernel code review by doing so, and your own submissions are likely to be significantly better thanks to that. My story exactly.
Quoted 2 lines
I ask for inclusion. It is included, and ohh now people recall, that they wanted to complain.
What other choice do they have at this point? Ignore or complain. I definitely prefer them to complain if they have a reason to - and the same would apply if it was my code and not yours.
Note that I don't blame Greg for pushing the code into Andrew's tree. This is what this tree is for, and now your patches got some exposure and you have objections to work on, to say the least. I also admit that some people here are being a little harsh, but I believe that each one of us is doing his/her best to improve the kernel. It just happens that our best isn't always as good as one would want.
Quoted 1 line
Ok, I want to listen what technical problems do you see?
As I explained before, I would like to see your superio subsystem integrate properly with existing drivers that need it before you attempt to add more functions on top of it. And I want a full documentation of your superio subsystem to be part of the patchset. It seems that most people here didn't get what you were doing and why you were doing it (at least I wasn't alone ;)), so obviously a complete documentation would be more than welcome - needed would in fact be the appropriate term.
Quoted 9 lines
Jean, it looks like you forget how superio is designed.
Your pc87360 driver is all in one big piese of code, superio is splitted into absolutely separated modules - _one_ for superio chip, and _several_ for logical devices.I need to split your driver into at least 5 parts - pc8736x initialisation(superio has it), i2c part(should be removed from superio code), fan logical device(separate part), voltage monitor logical device (separate part) and temperature monitor logical device (separate part).
The whole thing is a single driver because it achieves one goal. The fact that National Semiconductor decided to use three different logical devices for temperatures, voltages and fans is an implementation detail. This alone doesn't justify a split of the source code. The "superio chip" part is what you have been working on and I agree it was needed. And I agree that the superio access has to be moved from my pc87360 driver (and other similar drivers) to your superio driver.
You do not *have* to separate all the parts. One single driver can request several logical devices, and this is precisely what I want us to do here. I agree that it could make sense to separate the logical devices on a per device (and driver) basis, if it allows us to reuse the code more easily. It is however not a requirement, that I can see.
Quoted 3 lines
They are just separate modules, it is design feature to use _the_ _same_, for example, voltage monitor module with _any_ number of existent superio chips.
It isn't the first time you say that, and I have to say I don't much get where you want to go. The hardware monitoring logical devices are completely different between PC8736x, IT87xxF, W836x7(T)HF and 47M1xx superio devices, just like the various other hardware monitoring chips are different. There is no code to be shared here, so nothing is duplicated.
Maybe it is different with gpio or access bus? Is there some standard register organization among the various chip makers? I don't know these, so I cannot tell.
Quoted 3 lines
And that will end up having tons of duplicated code in each driver:
temp monitor in A, temp monitor in B and so on...
volt monitor in A, volt monitor in B and so on...
There is no logical device-based duplicated code in the superio hardware monitoring drivers at the moment, unless you see things I do not (if you do please let me know). The only thing that is duplicated accross the drivers is the superio accesses, agreed, and I am glad that your unified superio driver will put an end to this.
Quoted 1 line
Jean, we already discussed it a bit in
lm_sensorsmail list AFAR...
Yes, 5 months ago, and we did not exactly agree. And we obviously still do not agree.
Don't get me wrong, I am not saying that I don't want your code in the kernel. I am actually interested in it (the base superio part, in fact). All I am asking for is that you put some efforts in presenting your code correctly, splitting it the way it has to be, and getting it into the kernel step by step. You are not going to get any support from me by pretending that the superio hardware monitoring drivers need a full rewrite to accomodate with your unified superio driver - because I know it cannot be true. If you can provide a first patchset with core superio driver, documentation of it, and *minimum* updates of the pc87360 driver to make use of it, you can be sure I will review it with great care.
Thanks,
--
Jean Delvare
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 5 lines · Jean Delvare
Hi Evgeniy,
Quoted 2 lines
I presented the code.
Several times in special mail list.
Quoted 7 lines
That's true. Except that the second time (at least) you didn't find anyone to review it. Also note that your patches are about superio, gpio and now access bus. The list is dedicated to hardware monitoring. This is no exact match, although it happens that some superio chips include hardware monitoring logical devices. So I reviewed the part I think I could help with, and skipped the rest (and I did tell the you, and the list, that I had).
It is the most closest to the superio subsystem mail list, and all comments presented there about superio code were always right and
indeed usefull.
I believe I addressed them all(except function prefixes :) )
Quoted 9 lines
Quoted 3 lines
Only problem that it was not sent to lkml, where there are too many noise and flood. That is why while digging through it several years ago I decided to drop this mail list.
I agree that there is a heavy traffic on LKML - I am not subscribed myself just because of that. However, when one introduces a completely new subsystem, it definitely needs review by folks that have way more knowledge about the kernel internals than I do - expecially about the (bus) driver model.
A bit offtopic: the reason why we have such long discussion about superio
is not that it is new, and you can see it if you dig the archive from the
beginning.
Quoted 10 lines
Quoted 7 lines
I do not understand you, what are you trying to say? Waht is wrong? I wrote the code.
I presented it.
I presented it again.
I presented it yeat another again.First time people answered, then - not.
OK, blame me for having a day job, a girlfriend and a family. Blame me for not having the necessary time and knowledge to review your code.
:) You misunderstand me, sorry.
I absolutely did not want to blame anyone and
even did not have it in my thoughts :)
Quoted 11 lines
And then think about it again. Maybe you did not present it to the right person(s). Maybe you did not present it in the correct form. Maybe you didn't properly explain what problem you were trying to solve - and failed to catch people's attention because of that. And maybe you should not have ignored some of my comments - and others'. I would invite you to read your own recent posts to the LKML again. Most objections you have received about your code - some of which were so blantantly valid (several drivers with the same name is fine, no kidding) - you first denied that there were any problem, then grumbled, then accepted to change but just not to make any trouble - not because you were wrong. You are not going anywhere here with this attitude.
<not personal to you reasonings...>
Most objections are so small, that is can not be called problems. I will fix it soon.
And I still do not see any problems there, I just do not want to spend my time in such meaningless dispute about module names.
I'm not religious fanatic which will with foam at the mouth try to make it's word latest.
I prefer to do interesting things and it is much easier to change the module
name than try to convince army of opponents :)
Superio design as actually another isssue, although I still do not understand
why break well written working code just to what?
As I said, talk is cheap, if only discuss design notes, nothing can be created.
</not personal to you reasonings...>
Quoted 10 lines
Sure, we, kernel developers as a whole, lack time to properly review all the code that is sent to us. Even me, and I probably receive one hundredth of what Greg, Andrew or Linus receive. And now what? That's the way it is and we (and you) have to live with it. If you want the situation to improve, you can volunteer to review some code. Andrew's broken-out directories and LKML are full of patches that need review. Or pick one subsystem and track the patches applied to it. Really, do not hesitate to help. You certainly will learn much about kernel code review by doing so, and your own submissions are likely to be significantly better thanks to that. My story exactly.
And do I blame anyone?
Did I said that all you are fscking monsters that do not like my baby?
No, I presented the code and appreciate anyone's comments. Thank you.
Quoted 6 lines
Quoted 2 lines
I ask for inclusion. It is included, and ohh now people recall, that they wanted to complain.
What other choice do they have at this point? Ignore or complain. I definitely prefer them to complain if they have a reason to - and the same would apply if it was my code and not yours.
I do not say it to your personally, but in general:
Let's discuss the code, let's discuss the design, but do not try to say,
that code is bad just because one never see it before and it was just appeared here, and one do not understand something...
Most of the thread is not discussion...
Quoted 9 lines
Note that I don't blame Greg for pushing the code into Andrew's tree. This is what this tree is for, and now your patches got some exposure and you have objections to work on, to say the least. I also admit that some people here are being a little harsh, but I believe that each one of us is doing his/her best to improve the kernel. It just happens that our best isn't always as good as one would want.
Quoted 1 line
Ok, I want to listen what technical problems do you see?
Quoted 8 lines
As I explained before, I would like to see your superio subsystem integrate properly with existing drivers that need it before you attempt to add more functions on top of it. And I want a full documentation of your superio subsystem to be part of the patchset. It seems that most people here didn't get what you were doing and why you were doing it (at least I wasn't alone ;)), so obviously a complete documentation would be more than welcome - needed would in fact be the appropriate term.
Sure, I definitely will devote much time to document all pieces.
Quoted 19 lines
Quoted 10 lines
Jean, it looks like you forget how superio is designed.
Your pc87360 driver is all in one big piese of code, superio is splitted into absolutely separated modules - _one_ for superio chip, and _several_ for logical devices.I need to split your driver into at least 5 parts - pc8736x initialisation(superio has it), i2c part(should be removed from superio code), fan logical device(separate part), voltage monitor logical device (separate part) and temperature monitor logical device (separate part).
The whole thing is a single driver because it achieves one goal. The fact that National Semiconductor decided to use three different logical devices for temperatures, voltages and fans is an implementation detail. This alone doesn't justify a split of the source code. The "superio chip" part is what you have been working on and I agree it was needed. And I agree that the superio access has to be moved from my pc87360 driver (and other similar drivers) to your superio driver.
Quoted 5 lines
You do not *have* to separate all the parts. One single driver can request several logical devices, and this is precisely what I want us to do here. I agree that it could make sense to separate the logical devices on a per device (and driver) basis, if it allows us to reuse the code more easily. It is however not a requirement, that I can see.
I mean above that we need to separate them logically from superio access
and i2c part.
But it is really better to have each logical device driver be a separate module,
it is just easier to search and handle.
Quoted 11 lines
Quoted 3 lines
They are just separate modules, it is design feature to use _the_ _same_, for example, voltage monitor module with _any_ number of existent superio chips.
It isn't the first time you say that, and I have to say I don't much get where you want to go. The hardware monitoring logical devices are completely different between PC8736x, IT87xxF, W836x7(T)HF and 47M1xx superio devices, just like the various other hardware monitoring chips are different. There is no code to be shared here, so nothing is duplicated.
Quoted 3 lines
Maybe it is different with gpio or access bus? Is there some standard register organization among the various chip makers? I don't know these, so I cannot tell.
As I saw from different documentation - logical devices itself are the same.
And it is the same for superio standard.
For example sc1100 and pc87366 superio chips have the same logical inside,
although different logical device set.
Quoted 9 lines
Quoted 3 lines
And that will end up having tons of duplicated code in each driver:
temp monitor in A, temp monitor in B and so on...
volt monitor in A, volt monitor in B and so on...There is no logical device-based duplicated code in the superio hardware monitoring drivers at the moment, unless you see things I do not (if you do please let me know). The only thing that is duplicated accross the drivers is the superio accesses, agreed, and I am glad that your unified superio driver will put an end to this.
Not only access.
Logic inside superio chip is submitted to superio standard. I designed(at least tried to) superio subsistem
that it can handle all differencies using per device callbacks.
Quoted 5 lines
Quoted 1 line
Jean, we already discussed it a bit in
lm_sensorsmail list AFAR...Yes, 5 months ago, and we did not exactly agree. And we obviously still do not agree.
Quoted 10 lines
Don't get me wrong, I am not saying that I don't want your code in the kernel. I am actually interested in it (the base superio part, in fact). All I am asking for is that you put some efforts in presenting your code correctly, splitting it the way it has to be, and getting it into the kernel step by step. You are not going to get any support from me by pretending that the superio hardware monitoring drivers need a full rewrite to accomodate with your unified superio driver - because I know it cannot be true. If you can provide a first patchset with core superio driver, documentation of it, and *minimum* updates of the pc87360 driver to make use of it, you can be sure I will review it with great care.
I definitely will do it.
Just get me time :)
Thank you.
Quoted 3 lines
Thanks,
--
Jean Delvare
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
[Voluntarily skipping a large part of the discussion so as to stop wasting everyone's time and focus on the one technical point I am interested in.]
Hi Evgeniy,
Quoted 8 lines
As I saw from different documentation - logical devices itself are the same.
And it is the same for superio standard.
For example sc1100 and pc87366 superio chips have the same logical inside, although different logical device set.
Quoted 6 lines
(...)
Not only access.
Logic inside superio chip is submitted to superio standard. I designed(at least tried to) superio subsistem
that it can handle all differencies using per device callbacks.
I would like to ensure that we agree on what is common to all Super-I/O chips (as per Intel's LPC specification).
1* Super-I/O are accessed at I/O addresses 0x2e+0x2f or alternate addresses 0x4e+0x4f.
2* These addresses give access to a 256 byte addressing space.
3* Super-I/O chips are divided in logical devices, which can be selected by writing its id to 0x07. What each logical device does is not standardized (depends of the chip).
4* Range 0x00-0x2f is common to all logical devices, while range 0x30-0xff is logical-device specific.
5* Range 0x20-0x2f contains chip-wide identification and configuration registers. Definition of these registers is not standardized.
6* 0x31 controls the activation of each logical device, 0x60-0x63 its base address, 0x70-0x73 its interrupts. Definition of these registers is standardized.
7* Range 0xf0-0xff contains logical device-specific configuration registers. Definition of these registers is not standardized.
And that's about it. The way each logical device works (how registers are mapped from the base address) is completely chip-specific.
Do we agree on all this, or did I miss somthing? I would like to make sure that, when you refer to sharing as much code as possible between the various Super-I/O chips, you really mean the organization of logical devices within the Super-I/O (selection, retrieval of base address and interrupt configuration) and not the logical devices themselves.
Thanks,
Signature · 2 lines
Jean Delvare http://khali.linux-fr.org/
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 46 lines · On Wed, 26 Jan 2005 20:20:27 +0100 Jean Delvare <[email protected]> wrote:
[Voluntarily skipping a large part of the discussion so as to stop wasting everyone's time and focus on the one technical point I am interested in.]
Hi Evgeniy,
Quoted 8 lines
As I saw from different documentation - logical devices itself are the same.
And it is the same for superio standard.
For example sc1100 and pc87366 superio chips have the same logical inside, although different logical device set.
Quoted 6 lines
(...)
Not only access.
Logic inside superio chip is submitted to superio standard. I designed(at least tried to) superio subsistem
that it can handle all differencies using per device callbacks.I would like to ensure that we agree on what is common to all Super-I/O chips (as per Intel's LPC specification).
1* Super-I/O are accessed at I/O addresses 0x2e+0x2f or alternate addresses 0x4e+0x4f.
2* These addresses give access to a 256 byte addressing space.
3* Super-I/O chips are divided in logical devices, which can be selected by writing its id to
0x07. What each logical device does is not standardized (depends of the chip).4* Range 0x00-0x2f is common to all logical devices, while range 0x30-0xff is logical-device specific.
5* Range 0x20-0x2f contains chip-wide identification and configuration registers. Definition of these registers is not standardized.
6*
0x31controls the activation of each logical device, 0x60-0x63 its base address, 0x70-0x73 its interrupts. Definition of these registers is standardized.7* Range 0xf0-0xff contains logical device-specific configuration registers. Definition of these registers is not standardized.
Quoted 8 lines
And that's about it. The way each logical device works (how registers are mapped from the base address) is completely chip-specific.
Do we agree on all this, or did I miss somthing? I would like to make sure that, when you refer to sharing as much code as possible between the various Super-I/O chips, you really mean the organization of logical devices within the Super-I/O (selection, retrieval of base address and interrupt configuration) and not the logical devices themselves.
You are absolutely right, I just want to add following note:
Most of the logical devices inside superio chips has standardized access methods. One just need base address and index, that is all.
For such devices all infrastructure already exists in the provided superio core. One just need to provide one logical device driver for it(like sc_gpio.c).
But, sometimes it really can be the situation, when logical device is not obeyed to rules in the existing logical device driver(like GPIO in sc1100, which is not superio logical device but is fitted design quite well), for such cases there is also infrastructure in superio driver. For example scx.c - it has it's own private GPIO logical device, which is "cloned" from the "standard"(described in sc_gpio.c) logical device(clones actully have almost nothing in common).
Situation with device cloning is very unlikely according to various superio chips I saw and read datasheets.
Quoted 4 lines
Thanks,
Signature · 2 lines
Jean Delvare http://khali.linux-fr.org/
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Evgeniy PolyakovQuoted 2 lines · Evgeniy Polyakov
I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects.
That's simply not true. The amount of patches submitted is extremly huge and the reviewers don't have time to look at everythning.
If no one replies it simply means no one has looked at it in enough detail to comment yet.
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 9 lines · Christoph Hellwig
Quoted 2 lines · Evgeniy Polyakov
I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects.
That's simply not true. The amount of patches submitted is extremly huge and the reviewers don't have time to look at everythning.
If no one replies it simply means no one has looked at it in enough detail to comment yet.
That is why I resent it several times.
Then I asked for inclusion.
I never send it to lkml just because simple static/non static + module name
discussion in lkml already overflowed into more than 20 messages...
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 11 lines · Evgeniy Polyakov
Quoted 9 lines · Christoph Hellwig
Quoted 2 lines · Evgeniy Polyakov
I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects.
That's simply not true. The amount of patches submitted is extremly huge and the reviewers don't have time to look at everythning.
If no one replies it simply means no one has looked at it in enough detail to comment yet.
Quoted 6 lines
That is why I resent it several times.
Then I asked for inclusion.I never send it to lkml just because simple static/non static + module name
discussion in lkml already overflowed into more than 20 messages...
Well, not everyone is subscribed to lm_sensors mailing list but nonetheless are interested when a new subsystem is introduced into the kernel. There several established subsystems (network, USB, ide) whose maintainers people trust either because of the good track record or because it affects small number of people so the main discussion is kept on special lists. But even then most patches are presented on LKML when issues ironed out on special list.
With a new subsystem it is wise to present it to LKML so it gets wider coverage.
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 28 lines · Dmitry Torokhov
Quoted 11 lines · Evgeniy Polyakov
Quoted 9 lines · Christoph Hellwig
Quoted 2 lines · Evgeniy Polyakov
I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects.
That's simply not true. The amount of patches submitted is extremly huge and the reviewers don't have time to look at everythning.
If no one replies it simply means no one has looked at it in enough detail to comment yet.
Quoted 6 lines
That is why I resent it several times.
Then I asked for inclusion.I never send it to lkml just because simple static/non static + module name
discussion in lkml already overflowed into more than 20 messages...Well, not everyone is subscribed to
lm_sensorsmailing list but nonetheless are interested when a new subsystem is introduced into the kernel. There several established subsystems (network, USB, ide) whose maintainers people trust either because of the good track record or because it affects small number of people so the main discussion is kept on special lists. But even then most patches are presented on LKML when issues ironed out on special list.
Quoted 2 lines
With a new subsystem it is wise to present it to LKML so it gets wider coverage.
Khm-khm, if we will always wait untill everyone will comment the code or even initial
design, then nothing will be created at all.
Btw, where was comments about w1, kernel connector and acrypto? They were presented several times in lkml and all are completely new subsystems.
Should I stop developing just because I did not get comments?
Above discussion was not borned because it is new subsystem, btw...
Ok, I want to thank everyone for discussion.
I believe that new subsystem must be discussed in specific mail lists before
it goes mainstream, but not necessarily in lkml.
But if it really changes a lot of things, then of course it should be presented
in lkml.
Thank you.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 6 lines · Evgeniy Polyakov
...
Btw, where was comments about w1, kernel connector and acrypto? They were presented several times in lkml and all are completely new subsystems.
Should I stop developing just because I did not get comments?
...
I sent you comments regarding w1 two months ago regarding:
- the unneeded dscore -> ds9490r rename in the Makefile
- completely unused EXPORT_SYMBOL's (that seem to be still unused today)
Being honest, I have to admit that your reactions didn't sound as if you were waiting for comments.
Quoted 3 lines
Thank you.
Evgeniy Polyakov
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 8 lines · On Wed, 26 Jan 2005 19:19:41 +0100 Adrian Bunk <[email protected]> wrote:
Quoted 6 lines · Evgeniy Polyakov
...
Btw, where was comments about w1, kernel connector and acrypto? They were presented several times in lkml and all are completely new subsystems.
Should I stop developing just because I did not get comments?
...
Quoted 8 lines
I sent you comments regarding w1 two months ago regarding:
- the unneeded dscore -> ds9490r rename in theMakefile
- completely unused EXPORT_SYMBOL's (that seem to be still unused today)Being honest, I have to admit that your reactions didn't sound as if you were waiting for comments.
Quoted 1 line
Thank you.
I greatly appreciate your comments, and they were addressed.
Part of exported symbols are unexported, patch is just waiting to be sent, but I do not agree with dscore rename. I just do not understand it's advantage.
Quoted 9 lines
cu
AdrianSignature · 4 lines
"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
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 3 lines · Evgeniy Polyakov
...
I greatly appreciate your comments, and they were addressed. Part of exported symbols are unexported, patch is just waiting to be sent,
Ah, sorry. I only saw that the patch I sent two months ago still applies completely (except for an unrelated context change).
Quoted 1 line
but I do not agree with dscore rename. I just do not understand it's advantage.
It is only a small cosmetic thing:
If there's only one object file in a module, a renaming in the Makefile is superfluous - you can simply rename the source file
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 7 lines · Adrian Bunk
Quoted 3 lines · Evgeniy Polyakov
...
I greatly appreciate your comments, and they were addressed. Part of exported symbols are unexported, patch is just waiting to be sent,Ah, sorry. I only saw that the patch I sent two months ago still applies completely (except for an unrelated context change).
Patch is alredy sent, but probably it will not apper in the nearest -mm release.
Quoted 5 lines
Quoted 1 line
but I do not agree with dscore rename. I just do not understand it's advantage.
It is only a small cosmetic thing:
If there's only one object file in a module, a renaming in theMakefileis superfluous - you can simply rename the source file
Most of it's exports are preparation for EEPROM driver, which will require
some changes in w1 core(it needs to export additional callbacks).
I'm currently review DS device set to find any dependency upon ds2490 chip -
but it looks like there is no one, so it is alredy not core, but device driver
itlself.
I'm not too religious about it's name...
Quoted 3 lines
cu
Adrian
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Evgeniy PolyakovQuoted 11 lines · Evgeniy Polyakov
Quoted 9 lines · Christoph Hellwig
Quoted 2 lines · Evgeniy Polyakov
I have one rule - if noone answers that it means noone objects, or it is not interesting for anyone, and thus noone objects.
That's simply not true. The amount of patches submitted is extremly huge and the reviewers don't have time to look at everythning.
If no one replies it simply means no one has looked at it in enough detail to comment yet.
Quoted 6 lines
That is why I resent it several times.
Then I asked for inclusion.I never send it to lkml just because simple static/non static + module name
discussion in lkml already overflowed into more than 20 messages...
Your opinion on some things are different than the opinions of other people on some issues. That's normal.
Then a discussion arises.
That's normal and part of a review of some code. E.g. the "module name discussion" covered a real problem.
Be it 1 email or be it 100 emails - the main point is simply that all code in the kernel should be as good as possible and as near as possible to kernel standards.
The Linux kernel is a big project with _many_ people involved. I've also had people telling me that this or that I sent in a patch was nonsense. That's normal (and a criticism of your code is not meant as a personal insult) and leads to better code in the kernel.
Quoted 1 line
Evgeniy Polyakov
cu
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1: SuperIO scx200 breakage
In reply to Christoph HellwigQuoted 5 lines · Christoph Hellwig
That's simply not true. The amount of patches submitted is extremly huge and the reviewers don't have time to look at everythning.
If no one replies it simply means no one has looked at it in enough detail to comment yet.
How do people get to know this? Grape vines and crystal balls are inherently unreliable.
I think that if someone overlooks the patches when they're on the mailing lists and then complains when they're merged into the kernel, they have very little justification when trying to make it the patch submitters problem. It's clearly an overall failing of the community to have enough resources to review the patches before inclusion.
Frequently I end up with the situation where *NO* *ONE* seems interested in my patches and I throw them at Linus anyway after months have gone by. Maybe I'm just lucky that no one bothers to read my patches or everyone is implicitly exstatic with them. Nevertheless, I'm forced by the lack of response from LKML to follow precisely the same rule - no response implies people are happy. In reality, not doing so would mean I'd never get any patches merged which is unacceptable.
So, if the community has a problem with enough time to review patches, the community must get more (good) patch reviewers. We can't go around blaming the patch submitters for a community failing.
Signature · 4 lines
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial coreRe: 2.6.11-rc2-mm1: SuperIO scx200 breakage
Quoted 9 lines · Russell King
Quoted 5 lines · Christoph Hellwig
That's simply not true. The amount of patches submitted is extremly huge and the reviewers don't have time to look at everythning.
If no one replies it simply means no one has looked at it in enough detail to comment yet.
How do people get to know this? Grape vines and crystal balls are inherently unreliable.
If someone had looked and considered it good he'd have replied and said that. Simple ACK/NACK scheme - if neither returns consider it lost.
Quoted 3 lines
So, if the community has a problem with enough time to review patches, the community must get more (good) patch reviewers. We can't go around blaming the patch submitters for a community failing.
Absolutely. I think the major problem is that no one pays people for doing reviews so this is purely a spare-time job. And that spare time is limited due to real life issues for most people.
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 14 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Quoted 8 lines
Changes since 2.6.11-rc1-mm2:
[snip]
+matroxfb_basec-make-some-code-static.patch
Little fixes.
It breaks compilation with gcc-4.0
The patch below correct it.
regards,
Benoit
drivers/video/matrox/matroxfb_base.h +0 -1
@@ -764,7 +764,6 @@ void matroxfb_unregister_driver(struct m#define matroxfb_DAC_unlock_irqrestore (flags) spin_unlock_irqrestore(&ACCESS_FBINFO(lock.DAC),flags) extern void matroxfb_DAC_out(CPMINFO int reg, int val); extern int matroxfb_DAC_in(CPMINFO int reg); -extern struct list_head matroxfb_list;extern void matroxfb_var2my (struct fb_var_screeninfo * fvsi,struct my_timming * mt); extern int matroxfb_wait_for_sync(WPMINFO u_int32_t crtc); extern int matroxfb_enable_irq(WPMINFO int reenable);
Re: 2.6.11-rc2-mm1
Quoted 19 lines · Benoit Boissinot
Quoted 18 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Changes since 2.6.11-rc1-mm2:
[snip]
Quoted 7 lines
Quoted 4 lines
+matroxfb_basec-make-some-code-static.patch
Little fixes.
It breaks compilation with gcc-4.0
The patch below correct it.
This patch is correct, too.
I do grep for the symbols I'm making static, but it seems I have to sharpen my eyes...
Quoted 4 lines
regards,
Benoit
...
Sorry
Adrian
Signature · 4 lines
"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 SeedRe: 2.6.11-rc2-mm1 - fix a typo in nfs3proc.c
In reply to Andrew MortonQuoted 9 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Quoted 7 lines
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
+nfsacl-infrastructure-and-server-side-of-nfsacl.patch
ACLs for ther NFS client.
Patch below fix a typo.
fs/nfsd/nfs3proc.c +1 -1
@@ -813,7 +813,7 @@ struct svc_procedure nfsd_acl_procedurestruct svc_version nfsd_acl_version3 = { .vs_vers =3 , .vs_nproc =3 , - .vs_proc nfsd_acl_procedures3, + .vs_proc = nfsd_acl_procedures3, .vs_dispatch = nfsd_dispatch, .vs_xdrsize =NFS3_SVC_XDRSIZE , };
Re: 2.6.11-rc2-mm1 - compile fix
In reply to Andrew MortonQuoted 4 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
Quoted 9 lines
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
The patch below fixes the compilation of the tftp nat module
net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0):net/ipv4/netfilter/ip_nat_tftp.c:44: multiple definition of `ip_nat_tftp_hook' net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0):net/ipv4/netfilter/ip_conntrack_tftp.c:49: first defined here make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1
make[2]: *** [net/ipv4/netfilter] Error 2
make[1]: *** [net/ipv4] Error 2
make: *** [net] Error 2
include/linux/netfilter_ipv4/ip_conntrack_tftp.h +3 -3
@@ -13,8 +13,8 @@ struct tftphdr {#define TFTP_OPCODE_ACK 4#define TFTP_OPCODE_ERROR 5 -unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb, -enum ip_conntrack_info ctinfo, -struct ip_conntrack_expect *exp); +extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb, +enum ip_conntrack_info ctinfo, +struct ip_conntrack_expect *exp);#endif /* _IP_CT_TFTP */
PATCH 1/1 move common compat ioctls to hash
In reply to Andrew MortonHi!
The new ioctl code in fs/compat.c can be streamlined a little using the compat hash instead of an explicit switch statement.
The attached patch is against 2.6.11-rc2-bk2. Andi, could you please comment? Does this make sence?
fs/compat.c +5 -32
@@ -439,37 +439,10 @@ asmlinkage long compat_sys_ioctl(unsigneif (!filp) goto out; -/* -* To allow the compat_ioctl handlers to be self contained -* we need to check the common ioctls here first. -* Just handle them with the standard handlers below. -*/ -switch (cmd) { -case FIOCLEX : -case FIONCLEX : -case FIONBIO : -case FIOASYNC : -case FIOQSIZE : -break ; - -case FIBMAP : -case FIGETBSZ : -case FIONREAD : -if (S_ISREG (filp->f_dentry->d_inode->i_mode)) -break ; -/*FALL THROUGH*/ - -default : -if (filp->f_op && filp->f_op->compat_ioctl) { - error = filp->f_op->compat_ioctl (filp, cmd, arg); -if (error != -ENOIOCTLCMD ) - goto out_fput; - } - -if (!filp->f_op || - (!filp->f_op->ioctl && !filp->f_op->unlocked_ioctl)) - goto do_ioctl; -break ; +if (filp->f_op && filp->f_op->compat_ioctl) { + error = filp->f_op->compat_ioctl (filp, cmd, arg); +if (error != -ENOIOCTLCMD ) + goto out_fput; }/* When register_ioctl32_conversion is finally gone remove
@@ -509,7 +482,7 @@ asmlinkage long compat_sys_ioctl(unsigne }up_read (&ioctl32_sem); - do_ioctl: + error =sys_ioctl (fd, cmd, arg); out_fput:fput_light (filp, fput_needed);
fs/ioctl.c +1 -1
@@ -80,7 +80,7 @@ static int file_ioctl(struct file *filp,/* * When you add any new common ioctls to the switches above and below -* please update compat_sys_ioctl() too. +* please update compat_ioctl.h too. */ asmlinkage long sys_ioctl (unsigned int fd,unsigned int cmd,unsigned long arg) {
include/linux/compat_ioctl.h +9 -0
@@ -10,6 +10,15 @@#define ULONG_IOCTL (cmd) HANDLE_IOCTL((cmd),(ioctl_trans_handler_t)sys_ioctl)#endif +/* Common stuff */ +HANDLE_IOCTL(FIOCLEX) +HANDLE_IOCTL(FIONCLEX) +HANDLE_IOCTL(FIONBIO) +HANDLE_IOCTL(FIOASYNC) +HANDLE_IOCTL(FIOQSIZE) +HANDLE_IOCTL(FIBMAP) +HANDLE_IOCTL(FIGETBSZ) +HANDLE_IOCTL(FIONREAD) /* Big T */ COMPATIBLE_IOCTL(TCGETA) COMPATIBLE_IOCTL(TCSETA)
Signature · 1 line
I dont speak for Mellanox.
Re: [PATCH] move common compat ioctls to hash
Quoted 6 lines · Michael S. Tsirkin
Hi!
The new ioctl code infs/compat.ccan be streamlined a little using the compat hash instead of an explicit switch statement.The attached patch is against 2.6.11-rc2-bk2. Andi, could you please comment? Does this make sence?
Problem is that when a compat_ioctl handler returns -EINVAL instead of -ENOIOCTLCMD on unknown ioctl it won't check the common ones.
I fear this mistake would be common, that is why I put in the switch.
-Andi
Re: [PATCH] move common compat ioctls to hash
Quoting r. Andi Kleen <[email protected]>:
Quoted 10 lines
Subject: Re: [PATCH] move common compat ioctls to hash
Quoted 6 lines · Michael S. Tsirkin
Hi!
The new ioctl code infs/compat.ccan be streamlined a little using the compat hash instead of an explicit switch statement.The attached patch is against 2.6.11-rc2-bk2. Andi, could you please comment? Does this make sence?
Quoted 7 lines
Problem is that when a
compat_ioctlhandler returns-EINVALinstead of-ENOIOCTLCMDon unknown ioctl it won't check the common ones.I fear this mistake would be common, that is why I put in the switch.
-Andi
Still, many drivers still need the compat hash lookup to work properly, and these still require -ENOIOCTLCMD to work properly. So is it worth it wasting CPU cycles working around only part of the problem?
How about:
1. Adding a comment in fs.h
2. Changing unlocked_ioctl to behave in the same way as compat_ioctl (this will help since unlocked_ioctl will be well tested), something along the lines of my old patch below [its against 2.6.11-rc1-bk5].
As a bonus, I expect a small speedup in code using unlocked_ioctl (as well as compat_ioctl) for datapath things like usb transfers.
Andy, if this sounds convincing, let me know and I'll build a real patch.
MST
fs/ioctl.c +7 -6
@@ -24,12 +24,7 @@ static long do_ioctl(struct file *filp,if (!filp->f_op) goto out; -if (filp->f_op->unlocked_ioctl) { - error = filp->f_op->unlocked_ioctl (filp, cmd, arg); -if (error == -ENOIOCTLCMD ) - error = -EINVAL ; - goto out; - }else if (filp->f_op->ioctl) { +if (filp->f_op->ioctl) {lock_kernel (); error = filp->f_op->ioctl (filp->f_dentry->d_inode, filp, cmd, arg);
@@ -93,6 +91,12 @@ asmlinkage long sys_ioctl(unsigned int fif (error) goto out_fput; +if (filp->f_op && filp->f_op->unlocked_ioctl) { + error = filp->f_op->unlocked_ioctl (filp, cmd, arg); +if (error != -ENOIOCTLCMD ) + goto out_fput; + } +switch (cmd) {case FIOCLEX :set_close_on_exec (fd,1 );
Signature · 1 line
I dont speak for Mellanox.
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
In reply to Andrew MortonHi Andrew,
Quoted 2 lines · Andrew Morton
fuse-transfer-readdir-data-through-device.patch
fuse: transfer readdir data through device
It is great that this is fixed, don't remove it, but it does require the fuse libs to be updated at the same time, or opening dirs for listings will break like this:
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function not implemented)
As I personally like for my ls to keep on working, and I assume others will, too, I would appreciate it if you could add a warning to your announcements the following one or two weeks or so, so that people can remove this patch if they don't want to update their libs.
Thank you.
Sytse
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
Quoted 6 lines
Quoted 2 lines
fuse-transfer-readdir-data-through-device.patch
fuse: transfer readdir data through deviceIt is great that this is fixed, don't remove it, but it does require the fuse libs to be updated at the same time, or opening dirs for listings will break like this:
Quoted 8 lines
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)= -1 ENOSYS (Function not implemented)As I personally like for my ls to keep on working, and I assume others will, too, I would appreciate it if you could add a warning to your announcements the following one or two weeks or so, so that people can remove this patch if they don't want to update their libs.
This is my fault, sorry.
I promise, that there'll be no more backward incompatible changes (and if there will, a big warning about library dependency will be added :).
Thanks,
Miklos
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
In reply to Sytse WielingaQuoted 11 lines · Sytse Wielinga
Hi Andrew,
Quoted 2 lines · Andrew Morton
fuse-transfer-readdir-data-through-device.patch
fuse: transfer readdir data through deviceIt is great that this is fixed, don't remove it, but it does require the fuse libs to be updated at the same time, or opening dirs for listings will break like this:
Quoted 7 lines
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)= -1 ENOSYS (Function not implemented)As I personally like for my ls to keep on working, and I assume others will, too, I would appreciate it if you could add a warning to your announcements the following one or two weeks or so, so that people can remove this patch if they don't want to update their libs.
By any chance would this also break perl programs which readdir?
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
Quoted 8 lines · Bill Davidsen
Quoted 7 lines · Sytse Wielinga
It is great that this is fixed, don't remove it, but it does require the fuse libs to be updated at the same time, or opening dirs for listings will break like this:
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)= -1 ENOSYS (Function not implemented)
Quoted 6 lines
Quoted 4 lines
As I personally like for my ls to keep on working, and I assume others will, too, I would appreciate it if you could add a warning to your announcements the following one or two weeks or so, so that people can remove this patch if they don't want to update their libs.
By any chance would this also break perl programs which readdir?
Of course; I haven't tested it, but the actual ioctls aren't working anymore, so it's not even _possible_ to get them to work with this patch and an old version of the fuse libs, even with perl bindings, which go through the fuse libs anyway.
Sytse
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
As I personally like for my ls to keep on working, and I assume others will, too, I would appreciate it if you could add a warning to your announcements the following one or two weeks or so, so that people can remove this patch if they don't want to update their libs.
Quoted 6 lines
Quoted 1 line
By any chance would this also break perl programs which readdir?
Of course; I haven't tested it, but the actual ioctls aren't working anymore, so it's not even _possible_ to get them to work with this patch and an old version of the fuse libs, even with perl bindings, which go through the fuse libs anyway.
First, a little clarification: FUSE doesn't use ioctl() for communication between the kernel and userspace. It uses read() and write().
That aside, you are right, that this change breaks any kind of FUSE based filesystem. However the fix is trivial: install FUSE version 2.2-pre5 or later. The filesystems themselves don't need to be rebuilt, since the fix in the shared library will automatically get used.
Thanks,
Miklos
Re: 2.6.11-rc2-mm1: fuse patch needs new libs
In reply to Sytse WielingaQuoted 8 lines · Sytse Wielinga
Hi Andrew,
Quoted 2 lines · Andrew Morton
fuse-transfer-readdir-data-through-device.patch
fuse: transfer readdir data through deviceIt is great that this is fixed, don't remove it, but it does require the fuse libs to be updated at the same time, or opening dirs for listings will break like this:
fuse is a new feature, so we'll sort out all issues before it goes to mainline.
I'm sure once it's under review there will be a few more changes in the kernel <-> userland interface.
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 10 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Hi Andrew,
ACPI does not work anymore on my Compaq Evo N600c
(no thermal zone, no fan, no battery, ...).
It works great on Linus' 2.6.11-rc2, and (from what I remember) it was working on the last -mm releases I tried.
Here's a bunch of lines from dmesg.
.config and lspci attached.
Regards,
Brice
exresnte-0133 [24] ex_resolve_node_to_val: No object attached to node e7fcd548
dswexec-0446 [21] ds_exec_end_op : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C12A] (Node c15e5788), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C1A2._PSR] (Node c15ed8c8), AE_AML_NO_OPERAND
acpi_ac-0098 [12] acpi_ac_get_state : Error reading AC Adapter state
ACPI: Battery Slot [C19F] (battery absent)
ACPI: Battery Slot [C1A0] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [C1A3]
ACPI: Lid Switch [C1A4]
ACPI: Fan [C1F6] (off)
ACPI: Fan [C1F7] (off)
ACPI: Fan [C1F8] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
exresnte-0133 [31] ex_resolve_node_to_val: No object attached to node e7fcd548
dswexec-0446 [28] ds_exec_end_op : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C11A] (Node c15e5b48), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.C11A] (Node c15ef3c8), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.C1F1] (Node c15ef0c8), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP] (Node c15f05c8), AE_AML_NO_OPERAND
ACPI wakeup devices:
C052 C17E C185 C0A4 C0AA C19F C1A0 C1A3 C1A4
ACPI: (supports S0 S1 S3 S4 S4bios S5)
exresnte-0133 [26] ex_resolve_node_to_val: No object attached to node e7fcd548
dswexec-0446 [23] ds_exec_end_op : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C119] (Node c15e5b88), AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_GPE._L10] (Node c15f0248), AE_AML_NO_OPERAND
evgpe-0552: *** Error: AE_AML_NO_OPERAND while evaluating method [_L10] for GPE[ 0]
Re: 2.6.11-rc2-mm1 (AE_AML_NO_OPERAND)
Quoted 9 lines · Brice Goglin
Andrew Morton a écrit :
ACPI does not work anymore on my Compaq Evo N600c
(no thermal zone, no fan, no battery, ...).
It works great on Linus' 2.6.11-rc2, and (from what I remember) it was working on the last -mm releases I tried.Here's a bunch of lines from dmesg.
...
Quoted 38 lines
exresnte-0133 [24]
ex_resolve_node_to_val: No object attached to nodee7fcd548
dswexec-0446 [21]ds_exec_end_op: [Acquire]: Could not
resolve operands,AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed
[\_SB_.C03E.C053.C0D1.C12A] (Nodec15e5788),AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_SB_.C1A2._PSR]
(Nodec15ed8c8),AE_AML_NO_OPERAND
acpi_ac-0098 [12]acpi_ac_get_state: Error reading AC Adapter
state
ACPI: Battery Slot [C19F] (battery absent)
ACPI: Battery Slot [C1A0] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [C1A3]
ACPI: Lid Switch [C1A4]
ACPI: Fan [C1F6] (off)
ACPI: Fan [C1F7] (off)
ACPI: Fan [C1F8] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) exresnte-0133 [31]ex_resolve_node_to_val: No object attached to nodee7fcd548
dswexec-0446 [28]ds_exec_end_op: [Acquire]: Could not
resolve operands,AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed
[\_SB_.C03E.C053.C0D1.C11A] (Nodec15e5b48),AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.C11A] (Nodec15ef3c8),AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.C1F1] (Nodec15ef0c8),AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP]
(Nodec15f05c8),AE_AML_NO_OPERAND
ACPI wakeup devices:
C052 C17E C185 C0A4 C0AA C19F C1A0 C1A3 C1A4
ACPI: (supports S0 S1 S3 S4 S4bios S5)
exresnte-0133 [26]ex_resolve_node_to_val: No object attached to nodee7fcd548
Quoted 8 lines
dswexec-0446 [23]
ds_exec_end_op: [Acquire]: Could not
resolve operands,AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed
[\_SB_.C03E.C053.C0D1.C119] (Nodec15e5b88),AE_AML_NO_OPERAND
psparse-1138: *** Error: Method execution failed [\_GPE._L10] (Nodec15f0248),AE_AML_NO_OPERAND
evgpe-0552: *** Error:AE_AML_NO_OPERANDwhile evaluating method
[_L10] for GPE[ 0]
Please patch -Rp1 this file:
http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/bk-acpi.patch
to verify that the issue goes away when backing out the ACPI part of the latest mm patch.
We'll likely need your acpidmp output to bottom out on this. Please open a bug here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Category: AML-interpreter
and attach (don't paste) the output from acpidmp, available in /usr/sbin or in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
along with the complete dmesg -s64000 output of the failure case.
thanks,
-Len
Re: 2.6.11-rc2-mm1
In reply to Brice GoglinHi!
Quoted 6 lines
Quoted 5 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
Quoted 7 lines
Quoted 7 lines
- On my test box there is no flashing cursor on the vga console. Known bug,
please don't report it.Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately,
huge.
Heh, on my system, I get no cursor, and no letters, either (this is vga text console). I *can* see the backgrounds, for example if I run aumix I see colored blocks... Framebuffer does not seem to work, either.
Letters are present for a while during boot; not sure what makes them go away.
Quoted 4 lines
ACPI does not work anymore on my Compaq Evo N600c
(no thermal zone, no fan, no battery, ...).
It works great on Linus' 2.6.11-rc2, and (from what I remember) it was working on the last -mm releases I tried.
I'd test on N620c, but it is rather hard without video :-(.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Re: 2.6.11-rc2-mm1
Quoted 7 lines · Pavel Machek
Heh, on my system, I get no cursor, and no letters, either (this is vga text console). I *can* see the backgrounds, for example if I run aumix I see colored blocks... Framebuffer does not seem to work, either.
Letters are present for a while during boot; not sure what makes them go away.
I get the same thing, text disappairs after a second or something like that. Framebuffer has no effect.
Signature · 4 lines
Mvh / Best regards Espen Fjellvær Olsen [email protected] Norway
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonReview of the superio subsystem sneaked in through bk-i2c.patch:
drivers/superio/Kconfig new file +10 -0
@@ -0,0 +1,56 @@ +menu "SuperIO subsystem support" + +config SC_SUPERIO + tristate "SuperIO subsystem support" + depends on CONNECTOR + help + SuperIO subsystem support. + + This support is also available as a module. If so, the module + will be called superio.ko.
This doesn't mention what "SuperIO" is at all. Also please skip the .ko postfix for the module name as the intree Kconfigs do. The boilerplate has changed to:
To compile this driver as a module, choose M here: the module will be called <foo>.
drivers/superio/Makefile new file +3 -0
@@ -0,0 +1,11 @@ +# +# Makefile for the SuperIO subsystem. +#
Superflous.
+
+obj-$(CONFIG_SC_SUPERIO) += superio.o
+obj-$(CONFIG_SC_GPIO) += sc_gpio.o
+obj-$(CONFIG_SC_ACB) += sc_acb.o
+obj-$(CONFIG_SC_PC8736X) += pc8736x.o
+obj-$(CONFIG_SC_SCX200) += scx200.o
+
+superio-objs := sc.o chain.o sc_conn.o
please use superio-y += so new conditional objects can be added more easily.
drivers/superio/chain.c new file +2 -0
@@ -0,0 +1,52 @@ +/* +* chain.c
superfluos, the file name is obvious. (Dito for all other files)
+ *
+ * 2004 Copyright (c) Evgeniy Polyakov <[email protected]>
+ * All rights reserved.
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include <asm/atomic.h>
+#include <asm/types.h>
+
+#include <linux/list.h>
+#include <linux/slab.h>
always include <asm/*> after <linux/*> headers. Please use <linux/types.h> istead of <asm/types.h> always.
(comment applies to later files aswell)
+#include "chain.h"
+
+struct dev_chain *chain_alloc(void *ptr)
+{
+ struct dev_chain *ch;
+
+ ch = kmalloc(sizeof(struct dev_chain), GFP_ATOMIC);
+ if (!ch) {
+ printk(KERN_ERR "Failed to allocate new chain for %p.\n", ptr);
+ return NULL;
+ }
+
+ memset(ch, 0, sizeof(struct dev_chain));
+
+ ch->ptr = ptr;
+
+ return ch;
+}
+
+void chain_free(struct dev_chain *ch)
+{
+ memset(ch, 0, sizeof(struct dev_chain));
+ kfree(ch);
The memset completely defeats slab redzoning to catch bugs, don't do that.
Also what's the reason you can't simply put the list_head into struct logical_dev?
+static void pc8736x_fini(void)
+{
+ sc_del_sc_dev(&pc8736x_dev);
+
+ while (atomic_read(&pc8736x_dev.refcnt)) {
+ printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
+ pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+
+ if (current->flags & PF_FREEZE)
+ refrigerator(PF_FREEZE);
+
+ if (signal_pending(current))
+ flush_signals(current);
+ }
+}
And who gurantess this won't deadlock? Please use a dynamically allocated driver model device and it's refcounting, thanks.
+int sc_add_sc_dev(struct sc_dev *__sdev)
btw, what's the reason you use those ugly __ names for local variables all over?
+ while (atomic_read(&__sdev->refcnt)) {
+ printk(KERN_INFO "Waiting SuperIO chip %s to become free: refcnt=%d.\n",
+ __sdev->name, atomic_read(&__sdev->refcnt));
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(HZ);
+
+ if (current->flags & PF_FREEZE)
+ refrigerator(PF_FREEZE);
+
+ if (signal_pending(current))
+ flush_signals(current);
+ }
+}
Again as above.
+static void sc_deactivate_logical(struct sc_dev *dev, struct logical_dev *ldev) +{
+ printk(KERN_INFO "Deactivating logical device %s in SuperIO chip %s... ",
+ ldev->name, dev->name);
+
+ if (ldev->irq)
+ {
+ free_irq(ldev->irq, ldev);
+ ldev->irq = 0;
+ }
CodingStyle: if (ldev->irq) { (also in various other places)
+static int __devinit sc_init(void)
+{
+ printk(KERN_INFO "SuperIO driver is starting...\n");
+
+ return sc_register_callback();
+}
+
+static void __devexit sc_fini(void)
+{
+ sc_unregister_callback();
+ printk(KERN_INFO "SuperIO driver finished.\n");
+}
quite noise. Please only print messages when you find an actual device and not on unloading at all.
+ INIT_LIST_HEAD(&ldev_acb.ldev_entry);
+ spin_lock_init(&ldev_acb.lock);
these two can be initialized at compile time.
+#include "../superio/sc.h"
+#include "../superio/sc_gpio.h"
just include them normalluy, ok?
+static int scx200_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ private_base = pci_resource_start(pdev, 0);
+ printk(KERN_INFO "%s: GPIO base 0x%lx.\n", pci_name(pdev), private_base);
+
+ if (!request_region
+ (private_base, SCx200_GPIO_SIZE, "NatSemi SCx200 GPIO")) {
+ printk(KERN_ERR "%s: failed to request %d bytes I/O region for GPIOs.\n",
+ pci_name(pdev), SCx200_GPIO_SIZE);
+ return -EBUSY;
+ }
+
+ pci_set_drvdata(pdev, &private_base);
+ pci_enable_device(pdev);
pci_enable_device needs to be done first, and it returns and error that should be handled.
+ pci_unregister_driver(&scx200_pci_driver);
+ if (private_base)
+ release_region(private_base, SCx200_GPIO_SIZE);
this must happen in the ->remove callback.
drivers/superio/scx200.h new file +28 -0
@@ -0,0 +1,28 @@ +/* +* scx200.h +* +* 2004 Copyright (c) Evgeniy Polyakov <[email protected]> +* All rights reserved. +* +* 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, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +* +*/ + +#ifndef __SCX200_H +#define __SCX200_H + +#define SCx200_GPIO_SIZE 0x2c + +#endif /* __SCX200_H */
Yeah, right - a 30 line header for a single define that's used in a single source file..
Also your locking is broken. sdev_lock sometimes nests outside sdev->lock and sometimes inside. Similarly dev->chain_lock nests inside dev->lock sometimes and sometimes outside. You really need a locking hiearchy document and the lockign should probably be simplified a lot.
Re: 2.6.11-rc2-mm1
Quoted 1 line · Christoph Hellwig
Review of the superio subsystem sneaked in through bk-i2c.patch:
Hmm, "sneaked"... Good start, Christoph.
Quoted 15 lines
diff -Nru a/drivers/superio/Kconfig b/drivers/superio/Kconfig
drivers/superio/Kconfig new file +10
-0@@ -0,0 +1,56 @@ +menu "SuperIO subsystem support" + +config SC_SUPERIO + tristate "SuperIO subsystem support" + depends on CONNECTOR + help + SuperIO subsystem support. + + This support is also available as a module. If so, the module + will be called superio.ko.
Quoted 3 lines
This doesn't mention what "SuperIO" is at all. Also please skip the .ko postfix for the module name as the intree Kconfigs do. The boilerplate has changed to:
Ok.
Quoted 22 lines
To compile this driver as a module, choose M here: the module will be called <foo>.
diff -Nru a/drivers/superio/Makefile b/drivers/superio/Makefile
drivers/superio/Makefile new file +3
-0@@ -0,0 +1,11 @@ +# +# Makefile for the SuperIO subsystem. +#Superflous.
drivers/superio/Makefile new file +8
-0+ +obj-$(CONFIG_SC_SUPERIO) += superio.o +obj-$(CONFIG_SC_GPIO) += sc_gpio.o +obj-$(CONFIG_SC_ACB) += sc_acb.o +obj-$(CONFIG_SC_PC8736X) += pc8736x.o +obj-$(CONFIG_SC_SCX200) += scx200.o + +superio-objs := sc.o chain.o sc_conn.o
Quoted 1 line
please use superio-y += so new conditional objects can be added more easily.
They must be added in the same file and line to allow easy control. It is not directory like char/.
Quoted 35 lines
diff -Nru
a/drivers/superio/chain.cb/drivers/superio/chain.cdrivers/superio/chain.c new file +2
-0@@ -0,0 +1,52 @@ +/* +* chain.c superfluos, the file name is obvious. (Dito for all other files)
+ *
+ * 2004 Copyright (c) Evgeniy Polyakov <[email protected]>
+ * All rights reserved.
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */drivers/superio/chain.c new file +6
-0+ +#include <asm/atomic.h> +#include <asm/types.h> + +#include <linux/list.h> +#include <linux/slab.h>
Quoted 4 lines
always include <asm/*> after <linux/*> headers. Please use <
linux/types.h> istead of <asm/types.h> always.(comment applies to later files aswell)
Ok.
Quoted 24 lines
drivers/superio/chain.c new file +23
-0+#include "chain.h" + +struct dev_chain *chain_alloc (void *ptr) +{ +struct dev_chain *ch; + + ch =kmalloc (sizeof (struct dev_chain ),GFP_ATOMIC ); +if (!ch) { +printk (KERN_ERR "Failed to allocate new chain for %p.\n" , ptr); +return NULL ; + } + +memset (ch,0 ,sizeof (struct dev_chain )); + + ch->ptr = ptr; + +return ch; +} + +void chain_free (struct dev_chain *ch) +{ +memset (ch,0 ,sizeof (struct dev_chain )); +kfree (ch);
Quoted 2 lines
The memset completely defeats slab redzoning to catch bugs, don't do that.
What? Does following code also kills redzoning?
int *a;
a = kmalloc();
if (a)
{
memset(a, 0, sizeof(*a));
kfree(a);
}Consider size of the dev_chain structure...
Quoted 2 lines
Also what's the reason you can't simply put the
list_headinto structlogical_dev?
Because it is not just list_head, but special structure used for special pointer manipulations,
which you are obviously saw in sc.c
Quoted 19 lines
drivers/superio/chain.c new file +18
-0+static void pc8736x_fini (void ) +{ +sc_del_sc_dev (&pc8736x_dev); + +while (atomic_read (&pc8736x_dev.refcnt)) { +printk (KERN_INFO "Waiting for %s to became free: refcnt=%d.\n" , + pc8736x_dev.name,atomic_read (&pc8736x_dev.refcnt)); + +set_current_state (TASK_INTERRUPTIBLE ); +schedule_timeout (HZ ); + +if (current->flags &PF_FREEZE ) +refrigerator (PF_FREEZE ); + +if (signal_pending (current)) +flush_signals (current); + } +}
Quoted 2 lines
And who gurantess this won't deadlock? Please use a dynamically allocated driver model device and it's refcounting, thanks.
Sigh.
Christoph, please read the code before doing such comments. I very respect your review and opinion, but only until you respect others.
Quoted 31 lines
+int
sc_add_sc_dev(struct sc_dev *__sdev)btw, what's the reason you use those ugly __ names for local variables all over?
drivers/superio/chain.c new file +13
-0+while (atomic_read (&__sdev->refcnt)) { +printk (KERN_INFO "Waiting SuperIO chip %s to become free: refcnt=%d.\n" , + __sdev->name,atomic_read (&__sdev->refcnt)); +set_current_state (TASK_UNINTERRUPTIBLE ); +schedule_timeout (HZ ); + +if (current->flags &PF_FREEZE ) +refrigerator (PF_FREEZE ); + +if (signal_pending (current)) +flush_signals (current); + } +}Again as above.
drivers/superio/chain.c new file +10
-0+static void sc_deactivate_logical (struct sc_dev *dev,struct logical_dev *ldev) +{ +printk (KERN_INFO "Deactivating logical device %s in SuperIO chip %s... " , + ldev->name, dev->name); + +if (ldev->irq) + { +free_irq (ldev->irq, ldev); + ldev->irq =0 ; + }
Quoted 1 line
CodingStyle: if (
ldev->irq) { (also in various other places)
Yep.
Quoted 19 lines
drivers/superio/chain.c new file +12
-0+static int __devinit sc_init (void ) +{ +printk (KERN_INFO "SuperIO driver is starting...\n" ); + +return sc_register_callback (); +} + +static void __devexit sc_fini(void) +{ +sc_unregister_callback (); +printk (KERN_INFO "SuperIO driver finished.\n" ); +}quite noise. Please only print messages when you find an actual device and not on unloading at all.
drivers/superio/chain.c new file +2
-0+INIT_LIST_HEAD (&ldev_acb.ldev_entry); +spin_lock_init (&ldev_acb.lock);
Quoted 1 line
these two can be initialized at compile time.
Ok.
Quoted 4 lines
drivers/superio/chain.c new file +2
-0+#include "../superio/sc.h" +#include "../superio/sc_gpio.h" just include them normalluy, ok?
Sure.
Quoted 16 lines
drivers/superio/chain.c new file +15
-0+static int scx200_pci_probe (struct pci_dev *pdev, +const struct pci_device_id *ent) +{ + private_base =pci_resource_start (pdev,0 ); +printk (KERN_INFO "%s: GPIO base 0x%lx.\n" ,pci_name (pdev), private_base); + +if (!request_region + (private_base, SCx200_GPIO_SIZE,"NatSemi SCx200 GPIO" )) { +printk (KERN_ERR "%s: failed to request %d bytes I/O region for GPIOs.\n" , +pci_name (pdev), SCx200_GPIO_SIZE); +return -EBUSY ; + } + +pci_set_drvdata (pdev, &private_base); +pci_enable_device (pdev);
Quoted 2 lines
pci_enable_deviceneeds to be done first, and it returns and error that should be handled.
Yep, it can be a problem, thank you.
Quoted 39 lines
drivers/superio/chain.c new file +3
-0+pci_unregister_driver (&scx200_pci_driver); +if (private_base) +release_region (private_base, SCx200_GPIO_SIZE);this must happen in the ->remove callback.
diff -Nru
a/drivers/superio/scx200.hb/drivers/superio/scx200.hdrivers/superio/scx200.h new file +28
-0@@ -0,0 +1,28 @@ +/* +* scx200.h +* +* 2004 Copyright (c) Evgeniy Polyakov <[email protected]> +* All rights reserved. +* +* 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, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +* +*/ + +#ifndef __SCX200_H +#define __SCX200_H + +#define SCx200_GPIO_SIZE 0x2c + +#endif /* __SCX200_H */
Quoted 2 lines
Yeah, right - a 30 line header for a single define that's used in a single source file..
Christoph, do you know what SuperIO is?
I doubt...
It is a small chip, which can include various number of devices. SuperIO currently supports only GPIO and ACB, so this header only includes
one define. I do not have hardware(sc1100 based for example) that "exports"
other devices and which can be accessed from the outside of the board, so I did not add other defines.
But specially for you I can remove this file, will it satisfy you?
Quoted 5 lines
Also your locking is broken.
sdev_locksometimes nests outsidesdev->lockand sometimes inside. Similarlydev->chain_locknests insidedev->locksometimes and sometimes outside. You really need a locking hiearchy document and the lockign should probably be simplified a lot.
It is almost the same like after hand waving say that there is a wind.
Each lock protect it's own data, sometimes it happens when other data is locked,
sometimes not. Yes, probably interrupt handling can race, it requires more review,
I will take a look.
Below is part of the announce in lm_sensors@ which probably will throw light on your
claims.
************
Main goal was to be able to link any registered SuperIO chip with any number of registered logical devices. Next step is to add ability to communicate with SuperIO subsystem from userspace.
External kernel modules may access to logical devices using sc_{get,put}_ldev() and in similar way to SuperIO chip drivers - sc_{get,put}_sdev().
Driver writers shoud use sc_{add,del}_logical_dev() and sc_{add,del}_sc_dev() to accordingly add/remove logical devices and SuperIO chip drivers.
Any SuperIO chip driver must provite at least 2 functions:
->probe() and ->activate_one().
The former is called with different HW addresses and should return 0 if device was found there or negative error value.
The latter is called each time new logical device being added with pointer to it's logical device structure. It should return 0 if logical device was found to be active or negative error value.
Any logical device must provide 4 functions:
->activate() - it is used to activate logical device. ->read()/write() - what do you think, it is used to read and write from/to logical device registers.
->control() - it is used to control access to logical device. Actually it is private combination of ->read()/write() functions but is providede for convenience.
********************
Resume:
Cristoph, you rudely try to show that this code is badly broken. It is not.
It was tested as opposed to your claims, and works as expected.
To be more productive please next time be polite and respect others, or you will be just ignored no matter how strong your knowledges are.
Talk is cheap, show me the code, that is broken, and I will fix it.
Thank you.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 8 lines
Quoted 8 lines
(quoted diff) +7
-0+obj-$(CONFIG_SC_SUPERIO) += superio.o +obj-$(CONFIG_SC_GPIO) += sc_gpio.o +obj-$(CONFIG_SC_ACB) += sc_acb.o +obj-$(CONFIG_SC_PC8736X) += pc8736x.o +obj-$(CONFIG_SC_SCX200) += scx200.o + +superio-objs := sc.o chain.o sc_conn.o
Quoted 4 lines
Quoted 1 line
please use superio-y += so new conditional objects can be added more easily.
They must be added in the same file and line to allow easy control. It is not directory like char/.
Huh?
What I mean is you should write
superio-y += sc.o chain.o sc_conn.o
this allows adding things like
superio-$(CONFIG_FOO) += sc_foo.o
and is generally the canonical form since 2.6
Quoted 13 lines
Quoted 7 lines
(quoted diff) +4
-0+void chain_free(struct dev_chain *ch) +{ + memset(ch, 0, sizeof(struct dev_chain)); + kfree(ch);The memset completely defeats slab redzoning to catch bugs, don't do that.
What? Does following code also kills redzoning?
int *a;
a =kmalloc();
if (a)
Quoted 6 lines
{ memset(a, 0, sizeof(*a)); kfree(a); }Consider size of the
dev_chainstructure...
Sorry, didn't mean redzoning but poisoning in general, little brainfart on my side. The slab code can set freed objects to known patters so use after frees can be debugged easily, and by zeroing a structure before freeing we lose that.
Quoted 6 lines
Quoted 2 lines
Also what's the reason you can't simply put the
list_headinto structlogical_dev?Because it is not just
list_head, but special structure used for special pointer manipulations,
which you are obviously saw insc.c
No, I didn't see it. I see that the void pointer ptr in struct dev_chain always points to a struct sc_dev *, and I see we never change that pointer at run time. I might have missed something obvious, so maybe you could point me to it (or even better add a comment describing it)
Quoted 20 lines
Quoted 20 lines
(quoted diff) +18
-0+static void pc8736x_fini(void) +{ + sc_del_sc_dev(&pc8736x_dev); + + while (atomic_read(&pc8736x_dev.refcnt)) { + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n", + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt)); + + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(HZ); + + if (current->flags & PF_FREEZE) + refrigerator(PF_FREEZE); + + if (signal_pending(current)) + flush_signals(current); + } +}
Quoted 8 lines
Quoted 2 lines
And who gurantess this won't deadlock? Please use a dynamically allocated driver model device and it's refcounting, thanks.
Sigh.
Christoph, please read the code before doing such comments. I very respect your review and opinion, but only until you respect others.
The code above pretty much means you can keep rmmod stalled forever.
Also it seems to be the only code intree doing refrigerator() on anything but kernel thread. While I can't comment on swsusp internals it surely looks buggy to me.
Quoted 21 lines
Quoted 9 lines
drivers/superio/scx200.h new file +6
-0+#ifndef __SCX200_H +#define __SCX200_H + +#define SCx200_GPIO_SIZE 0x2c + +#endif /* __SCX200_H */ Yeah, right - a 30 line header for a single define that's used in a single source file..
Christoph, do you know what SuperIO is?
I doubt...It is a small chip, which can include various number of devices. SuperIO currently supports only GPIO and ACB, so this header only includes
one define. I do not have hardware(sc1100 based for example) that "exports"
other devices and which can be accessed from the outside of the board, so I did not add other defines.
Quoted 1 line
But specially for you I can remove this file, will it satisfy you?
I've just told you it looks extremly silly, you need to decide on your own whether it's worthwile.
Quoted 6 lines
Quoted 5 lines
Also your locking is broken.
sdev_locksometimes nests outsidesdev->lockand sometimes inside. Similarlydev->chain_locknests insidedev->locksometimes and sometimes outside. You really need a locking hiearchy document and the lockign should probably be simplified a lot.
Quoted 7 lines
It is almost the same like after hand waving say that there is a wind.
Each lock protect it's own data, sometimes it happens when other data is locked,
sometimes not. Yes, probably interrupt handling can race, it requires more review,
I will take a look.
The thing I mention is called lock order reversal, which means a deadlock in most cases. I don't have the time to actual walk through all codepathes to tell you whether it can really happen and where, but it's a really big warning sign.
Quoted 4 lines
Resume:
Cristoph, you rudely try to show that this code is badly broken. It is not.
It was tested as opposed to your claims, and works as expected.
I've seen tons of code that "works as expected" but still is buggy. That's why code needs to be both tested (with a workload as expected and other stress testing that shows it handles loads _not_ expected) and reviewed for errors that don't happen with a normal load or design problems.
Re: 2.6.11-rc2-mm1
Quoted 17 lines · Christoph Hellwig
Quoted 8 lines
Quoted 8 lines
(quoted diff) +7
-0+obj-$(CONFIG_SC_SUPERIO) += superio.o +obj-$(CONFIG_SC_GPIO) += sc_gpio.o +obj-$(CONFIG_SC_ACB) += sc_acb.o +obj-$(CONFIG_SC_PC8736X) += pc8736x.o +obj-$(CONFIG_SC_SCX200) += scx200.o + +superio-objs := sc.o chain.o sc_conn.oQuoted 4 lines
Quoted 1 line
please use superio-y += so new conditional objects can be added more easily.
They must be added in the same file and line to allow easy control. It is not directory like char/.
Huh?
What I mean is you should write
Quoted 7 lines
superio-y += sc.o chain.o sc_conn.o
this allows adding things like
superio-$(CONFIG_FOO) += sc_foo.o
and is generally the canonical form since 2.6
Yes, I understand you, but this is the case when it is not supposed to have external dependent features, they are already inside :) But who knows.
I think it is better to change.
Quoted 18 lines
Quoted 18 lines
Quoted 7 lines
(quoted diff) +4
-0+void chain_free(struct dev_chain *ch) +{ + memset(ch, 0, sizeof(struct dev_chain)); + kfree(ch);The memset completely defeats slab redzoning to catch bugs, don't do that.
What? Does following code also kills redzoning?
int *a;
a =kmalloc();
if (a){ memset(a, 0, sizeof(*a)); kfree(a); }
Quoted 6 lines
Quoted 1 line
Consider size of the
dev_chainstructure...Sorry, didn't mean redzoning but poisoning in general, little brainfart on my side. The slab code can set freed objects to known patters so use after frees can be debugged easily, and by zeroing a structure before freeing we lose that.
Zeroing can be found easily - the whole structure is NULL pointer, and will always panic if accessed(from running superio code), but redzoning is only happen on borders,
and can catch writes over the boards, which is rarely in this case.
Quoted 11 lines
Quoted 6 lines
Quoted 2 lines
Also what's the reason you can't simply put the
list_headinto structlogical_dev?Because it is not just
list_head, but special structure used for special pointer manipulations,
which you are obviously saw insc.cNo, I didn't see it. I see that the void pointer ptr in struct
dev_chainalways points to a structsc_dev*, and I see we never change that pointer at run time. I might have missed something obvious, so maybe you could point me to it (or even better add a comment describing it)
Each superio chip is registered with superio core without any devices. Each logical device is registered with superio core without any superio chip.
Then core checks if some chip is found in some superio device, and links
it to appropriate device.
So if board has several superio chips(like soekris board) and several logical devices in it, then we only have 2 superio small drivers, and several
logical device drivers, but not number_of_superio_chips*number_of_logical_devices drivers. Without dev_chain structure each logical device should have a separate list of
superio chips that owns it.
Above chain structure is a glue between superio core, logical devices and superio chips.
It is especially usefull in case of logical device cloning, when chip does not follow
the standart and place it somewhere else, but to allow access to it superio core
"clones" logical device and link them instead of the standart one.
Quoted 25 lines
Quoted 25 lines
Quoted 20 lines
(quoted diff) +18
-0+static void pc8736x_fini(void) +{ + sc_del_sc_dev(&pc8736x_dev); + + while (atomic_read(&pc8736x_dev.refcnt)) { + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n", + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt)); + + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(HZ); + + if (current->flags & PF_FREEZE) + refrigerator(PF_FREEZE); + + if (signal_pending(current)) + flush_signals(current); + } +}Quoted 2 lines
And who gurantess this won't deadlock? Please use a dynamically allocated driver model device and it's refcounting, thanks.
Sigh.
Quoted 5 lines
Quoted 3 lines
Christoph, please read the code before doing such comments. I very respect your review and opinion, but only until you respect others.
The code above pretty much means you can keep rmmod stalled forever.
Yes, and it is better than removing module whose structures are in use. SuperIO core is asynchronous in it's nature, one can use logical device through superio core and remove it's module on other CPU, above loop will
wait untill all reference counters are dropped.
Access to devices can be done not through ioctl or such mechanism which "locks" the module owner.
It is better than module_get() since with the latter variant we may end up
not removing device at all.
Quoted 44 lines
Also it seems to be the only code intree doing
refrigerator()on anything but kernel thread. While I can't comment on swsusp internals it surely looks buggy to me.Quoted 21 lines
Quoted 9 lines
drivers/superio/scx200.h new file +6
-0+#ifndef __SCX200_H +#define __SCX200_H + +#define SCx200_GPIO_SIZE 0x2c + +#endif /* __SCX200_H */ Yeah, right - a 30 line header for a single define that's used in a single source file..
Christoph, do you know what SuperIO is?
I doubt...It is a small chip, which can include various number of devices. SuperIO currently supports only GPIO and ACB, so this header only includes
one define. I do not have hardware(sc1100 based for example) that "exports"
other devices and which can be accessed from the outside of the board, so I did not add other defines.Quoted 1 line
But specially for you I can remove this file, will it satisfy you?
I've just told you it looks extremly silly, you need to decide on your own whether it's worthwile.
Quoted 6 lines
Quoted 5 lines
Also your locking is broken.
sdev_locksometimes nests outsidesdev->lockand sometimes inside. Similarlydev->chain_locknests insidedev->locksometimes and sometimes outside. You really need a locking hiearchy document and the lockign should probably be simplified a lot.Quoted 7 lines
It is almost the same like after hand waving say that there is a wind.
Each lock protect it's own data, sometimes it happens when other data is locked,
sometimes not. Yes, probably interrupt handling can race, it requires more review,
I will take a look.
Quoted 4 lines
The thing I mention is called lock order reversal, which means a deadlock in most cases. I don't have the time to actual walk through all codepathes to tell you whether it can really happen and where, but it's a really big warning sign.
No, it is not called lock order reversal.
There are no places like
lock a
lock b
unlock a
unlock b
and if they are, then I'm completely wrong.
What you see is only following:
place 1:
lock a
lock b
unlock b
lock c
unlock c
unlock a
place 2:
lock b
lock a
unlock a
lock c
unlock c
unlock b
It is done since manipulation with the chain pointer can be done from logical device structure and from superio chip structure, and this operations are absolutely the same in nature.
Quoted 10 lines
Quoted 4 lines
Resume:
Cristoph, you rudely try to show that this code is badly broken. It is not.
It was tested as opposed to your claims, and works as expected.I've seen tons of code that "works as expected" but still is buggy. That's why code needs to be both tested (with a workload as expected and other stress testing that shows it handles loads _not_ expected) and reviewed for errors that don't happen with a normal load or design problems.
Yes, you are right, of course.
That is why we write code, test and discuss(but not knock against each other) it.
I will send patch to address your comments soon, thank you.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 40 lines · Evgeniy Polyakov
Quoted 14 lines · Christoph Hellwig
Quoted 6 lines
Quoted 5 lines
Also your locking is broken.
sdev_locksometimes nests outsidesdev->lockand sometimes inside. Similarlydev->chain_locknests insidedev->locksometimes and sometimes outside. You really need a locking hiearchy document and the lockign should probably be simplified a lot.Quoted 7 lines
It is almost the same like after hand waving say that there is a wind.
Each lock protect it's own data, sometimes it happens when other data is locked,
sometimes not. Yes, probably interrupt handling can race, it requires more review,
I will take a look.Quoted 4 lines
The thing I mention is called lock order reversal, which means a deadlock in most cases. I don't have the time to actual walk through all codepathes to tell you whether it can really happen and where, but it's a really big warning sign.
No, it is not called lock order reversal.
There are no places like
lock a
lock b
unlock a
unlock band if they are, then I'm completely wrong.
What you see is only following:
place 1:
lock a
lock b
unlock b
lock c
unlock c
unlock a
Quoted 7 lines
place 2:
lock b
lock a
unlock a
lock c
unlock c
unlock b
Ugh, now think about that:
CPU0 CPU1
place1: place2:
lock a lock b
< guess what happens here :-) >
lock b lock a
... ...
Re: 2.6.11-rc2-mm1
Quoted 26 lines · Bartlomiej Zolnierkiewicz
Quoted 18 lines
There are no places like
lock a
lock b
unlock a
unlock band if they are, then I'm completely wrong.
What you see is only following:
place 1:
lock a
lock b
unlock b
lock c
unlock c
unlock aQuoted 7 lines
place 2:
lock b
lock a
unlock a
lock c
unlock c
unlock b
Quoted 8 lines
Ugh, now think about that:
CPU0 CPU1
place1: place2:
lock a lock b
< guess what happens here :-) >
lock b lock a
... ...
:) he-he, such place are in add and remove routings, and they can not be run simultaneously
in different CPUs.
And in other places they should go through the same lock(sdev or chain):
like
lock sdev_lock
lock chain
unclok chain
lock logic
unlock logic
unlock sdev_lock
lock sdev_lock
lock logic
unlock logic
lock chain
unclok chain
unlock sdev_lock
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 11 lines · Evgeniy Polyakov
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Ugh, now think about that:
CPU0 CPU1
place1: place2:
lock a lock b
< guess what happens here :-) >
lock b lock a
... ...
Quoted 3 lines
:) he-he, such place are in add and remove routings, and they can not be run simultaneously
in different CPUs.
Makes my toenails curl. Something fun I might write someday is a statical (dead-)lock checker. The design is very simple:
o Annotate code with the lock that could be taken.
o Whenever getting a lock B, write down something like "A->B" for every lock A we already have.
o Create a graph from the locking hierarchy obtained above.
o Look for cycles.
A cycle-free graph means that the code is deadlock-free. In the above, the graph surely has cycles. You could argue that the checker should be smarter, but then again - why should it? Is there a compelling reason why locking schemes as outlined above actually make the code better?
Jörn
Signature · 2 lines
It does not matter how slowly you go, so long as you do not stop. -- Confucius
Re: 2.6.11-rc2-mm1
Quoted 25 lines · On Tue, 25 Jan 2005 19:21:10 +0100 J_rn Engel <[email protected]>…
Quoted 11 lines · Evgeniy Polyakov
Quoted 8 lines · Bartlomiej Zolnierkiewicz
Ugh, now think about that:
CPU0 CPU1
place1: place2:
lock a lock b
< guess what happens here :-) >
lock b lock a
... ...Quoted 3 lines
:) he-he, such place are in add and remove routings, and they can not be run simultaneously
in different CPUs.Makes my toenails curl. Something fun I might write someday is a statical (dead-)lock checker. The design is very simple:
o Annotate code with the lock that could be taken.
o Whenever getting a lock B, write down something like "A->B" for every lock A we already have.
o Create a graph from the locking hierarchy obtained above.
o Look for cycles.
Quoted 5 lines
A cycle-free graph means that the code is deadlock-free. In the above, the graph surely has cycles. You could argue that the checker should be smarter, but then again - why should it? Is there a compelling reason why locking schemes as outlined above actually make the code better?
That will catch only simple cases - for the whole picture you need to run graph generator from all allowed code pathes, but that will require knowledge of the tested system, so it will not and actually can not be absolutely generic.
Quoted 5 lines
J_rnSignature · 2 lines
It does not matter how slowly you go, so long as you do not stop. -- Confucius
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1
Quoted 5 lines · Evgeniy Polyakov
That will catch only simple cases - for the whole picture you need to run graph generator from all allowed code pathes, but that will require knowledge of the tested system, so it will not and actually can not be absolutely generic.
Oh, we both agree on that, although we used different words. The design actually is as simple as outlined, the messy part is getting the complete call graph of the kernel in the first place.
I have a good deal of that part done, but the code is ugly and there are legal issues... but it shows that it's quite possible to do.
Jörn
Signature · 4 lines
My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. -- Edsger W. Dijkstra
Re: 2.6.11-rc2-mm1
In reply to Evgeniy PolyakovQuoted 8 lines · Evgeniy Polyakov
[...]
No, it is not called lock order reversal.There are no places like
lock a
lock b
unlock a
unlock b
This would be perfectly fine. The order of unlocking doesn't really matter. It is the actual locking that must be carried out on the same order everywhere to guarantee that there are no deadlocks.
Quoted 12 lines
and if they are, then I'm completely wrong.
What you see is only following:
place 1:
lock a
lock b
unlock b
lock c
unlock c
unlock a
Quoted 7 lines
place 2:
lock b
lock a
unlock a
lock c
unlock c
unlock b
I haven't look at the code yet, but this is a deadlock waiting to happen. "place 1" gets "lock a", then is interrupted and "place 2" gets "lock b". "place 2" waits forever for "lock a" and "place 1" waits forever for "lock b". Deadlock.
Signature · 4 lines
Paulo Marques - www.grupopie.com "A journey of a thousand miles begins with a single step." Lao-tzu, The Way of Lao-tzu
Re: 2.6.11-rc2-mm1
Quoted 10 lines · On Tue, 25 Jan 2005 15:36:57 +0000 Paulo Marques <[email protected]> wrote:
Quoted 8 lines · Evgeniy Polyakov
[...]
No, it is not called lock order reversal.There are no places like
lock a
lock b
unlock a
unlock b
Quoted 3 lines
This would be perfectly fine. The order of unlocking doesn't really matter. It is the actual locking that must be carried out on the same order everywhere to guarantee that there are no deadlocks.
It is bad style, and since unlocking changes the order someone may pass wrong locking.
Quoted 20 lines
Quoted 12 lines
and if they are, then I'm completely wrong.
What you see is only following:
place 1:
lock a
lock b
unlock b
lock c
unlock c
unlock aQuoted 7 lines
place 2:
lock b
lock a
unlock a
lock c
unlock c
unlock b
Quoted 4 lines
I haven't look at the code yet, but this is a deadlock waiting to happen. "place 1" gets "lock a", then is interrupted and "place 2" gets "lock b". "place 2" waits forever for "lock a" and "place 1" waits forever for "lock b". Deadlock.
As I said, that pathes are mutually exclusive - common pathes are guarded by one lock always.
Quoted 5 lines
Signature · 4 lines
Paulo Marques - www.grupopie.com "A journey of a thousand miles begins with a single step." Lao-tzu, The Way of Lao-tzu
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1
In reply to Evgeniy PolyakovQuoted 29 lines · Evgeniy Polyakov
Quoted 28 lines · Christoph Hellwig
Quoted 27 lines
Quoted 19 lines
(quoted diff) +18
-0+static void pc8736x_fini(void) +{ + sc_del_sc_dev(&pc8736x_dev); + + while (atomic_read(&pc8736x_dev.refcnt)) { + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n", + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt)); + + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(HZ); + + if (current->flags & PF_FREEZE) + refrigerator(PF_FREEZE); + + if (signal_pending(current)) + flush_signals(current); + } +}Quoted 2 lines
And who gurantess this won't deadlock? Please use a dynamically allocated driver model device and it's refcounting, thanks.
Sigh.
Christoph, please read the code before doing such comments. I very respect your review and opinion, but only until you respect others.
Quoted 6 lines
Quoted 1 line
The code above pretty much means you can keep rmmod stalled forever.
Yes, and it is better than removing module whose structures are in use. SuperIO core is asynchronous in it's nature, one can use logical device through superio core and remove it's module on other CPU, above loop will wait untill all reference counters are dropped.
I have a slightly different concern - the superio is a completely new subsystem and it should be integtrated with the driver model ("superio" bus?). Right now it looks like it is reimplementing most of the abstractions (device lists, driver lists, matching, probing). Moving to driver model significatntly affects lifetime rules for the objects, etc. etc. and will definitely not allow code such as above.
It would be nice it we get things right from the start.
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 38 lines · On Tue, 25 Jan 2005 11:11:42 -0500 Dmitry Torokhov <[email protected]>…
Quoted 29 lines · Evgeniy Polyakov
Quoted 28 lines · Christoph Hellwig
Quoted 27 lines
Quoted 19 lines
(quoted diff) +18
-0+static void pc8736x_fini(void) +{ + sc_del_sc_dev(&pc8736x_dev); + + while (atomic_read(&pc8736x_dev.refcnt)) { + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n", + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt)); + + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(HZ); + + if (current->flags & PF_FREEZE) + refrigerator(PF_FREEZE); + + if (signal_pending(current)) + flush_signals(current); + } +}Quoted 2 lines
And who gurantess this won't deadlock? Please use a dynamically allocated driver model device and it's refcounting, thanks.
Sigh.
Christoph, please read the code before doing such comments. I very respect your review and opinion, but only until you respect others.
Quoted 6 lines
Quoted 1 line
The code above pretty much means you can keep rmmod stalled forever.
Yes, and it is better than removing module whose structures are in use. SuperIO core is asynchronous in it's nature, one can use logical device through superio core and remove it's module on other CPU, above loop will wait untill all reference counters are dropped.
Quoted 8 lines
I have a slightly different concern - the superio is a completely new subsystem and it should be integtrated with the driver model ("superio" bus?). Right now it looks like it is reimplementing most of the abstractions (device lists, driver lists, matching, probing). Moving to driver model significatntly affects lifetime rules for the objects, etc. etc. and will definitely not allow code such as above.
It would be nice it we get things right from the start.
bus model is not good here - we need bus in each logical device and bus in each superio chip(or at least second case).
Each bus bus have some crosslinking to devices in other buses, and each new device
must be checked in each bus and probably added to each device...
It is not like I see it.
Consider folowing example:
each device from set A belongs to each device from set B. n <-> n, it is not the case when one bus can handle all features.
That is why I did not use driver model there. It is specific design feature, which is proven to work.
Quoted 2 lines
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1
Quoted 56 lines · Evgeniy Polyakov
Quoted 38 lines · On Tue, 25 Jan 2005 11:11:42 -0500 Dmitry Torokhov <[email protected]>…
Quoted 29 lines · Evgeniy Polyakov
Quoted 28 lines · Christoph Hellwig
Quoted 27 lines
Quoted 19 lines
(quoted diff) +18
-0+static void pc8736x_fini(void) +{ + sc_del_sc_dev(&pc8736x_dev); + + while (atomic_read(&pc8736x_dev.refcnt)) { + printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n", + pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt)); + + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(HZ); + + if (current->flags & PF_FREEZE) + refrigerator(PF_FREEZE); + + if (signal_pending(current)) + flush_signals(current); + } +}Quoted 2 lines
And who gurantess this won't deadlock? Please use a dynamically allocated driver model device and it's refcounting, thanks.
Sigh.
Christoph, please read the code before doing such comments. I very respect your review and opinion, but only until you respect others.
Quoted 6 lines
Quoted 1 line
The code above pretty much means you can keep rmmod stalled forever.
Yes, and it is better than removing module whose structures are in use. SuperIO core is asynchronous in it's nature, one can use logical device through superio core and remove it's module on other CPU, above loop will wait untill all reference counters are dropped.
Quoted 8 lines
I have a slightly different concern - the superio is a completely new subsystem and it should be integtrated with the driver model ("superio" bus?). Right now it looks like it is reimplementing most of the abstractions (device lists, driver lists, matching, probing). Moving to driver model significatntly affects lifetime rules for the objects, etc. etc. and will definitely not allow code such as above.
It would be nice it we get things right from the start.
bus model is not good here - we need bus in each logical device and bus in each superio chip(or at least second case).
Each bus bus have some crosslinking to devices in other buses, and each new device
must be checked in each bus and probably added to each device...
Quoted 9 lines
It is not like I see it.
Consider folowing example:
each device from set A belongs to each device from set B. n <-> n, it is not the case when one bus can handle all features.That is why I did not use driver model there. It is specific design feature, which is proven to work.
Ok, I briefly looked over the patches and that is what I understand (please correct me where I am wrong):
- you have superio chips which are containers providing set of interfaces;
- you have superio chip driver that detects superio chip and manages (enables/disables) individual interfaces.
- you have set of interface drivers (gpio, acb) that bind to individual superio interfaces and provide unified userspace interface that allows reading, writing and analog of ioctl.
So the question is why you can't have superio bus where superio chips register their individual interfaces as individual devices. gpio, acb, etc are drivers that bind to superio devices and create class devices gpio.
You could have:
sys
|-bus | |-superio | | |-devices | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0 | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1 | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2 | | |-drivers | | | |-gpio | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1 | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2 | | | |-acb | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0 | |-class | |-gpio | | |-gpio0 | | |-gpio1
gpioX have control and data attributes that allow reading and writing...
Am I missing something?
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 60 lines · Dmitry Torokhov
Quoted 15 lines
Quoted 8 lines
I have a slightly different concern - the superio is a completely new subsystem and it should be integtrated with the driver model ("superio" bus?). Right now it looks like it is reimplementing most of the abstractions (device lists, driver lists, matching, probing). Moving to driver model significatntly affects lifetime rules for the objects, etc. etc. and will definitely not allow code such as above.
It would be nice it we get things right from the start.
bus model is not good here - we need bus in each logical device and bus in each superio chip(or at least second case).
Each bus bus have some crosslinking to devices in other buses, and each new device
must be checked in each bus and probably added to each device...Quoted 9 lines
It is not like I see it.
Consider folowing example:
each device from set A belongs to each device from set B. n <-> n, it is not the case when one bus can handle all features.That is why I did not use driver model there. It is specific design feature, which is proven to work.
Ok, I briefly looked over the patches and that is what I understand (please correct me where I am wrong):
- you have superio chips which are containers providing set of interfaces;
- you have superio chip driver that detects superio chip and manages (enables/disables) individual interfaces.
- you have set of interface drivers (gpio, acb) that bind to individual superio interfaces and provide unified userspace interface that allows reading, writing and analog of ioctl.So the question is why you can't have superio bus where superio chips register their individual interfaces as individual devices. gpio, acb, etc are drivers that bind to superio devices and create class devices gpio.
You could have:
sys
|-bus | |-superio | | |-devices | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0 | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1 | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2 | | |-drivers | | | |-gpio | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1 | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2 | | | |-acb | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0 | |-class | |-gpio | | |-gpio0 | | |-gpio1
Quoted 3 lines
gpioX have control and data attributes that allow reading and writing...
Am I missing something?
You try to create n <-> 1 relation, but superio by design supposed to be n <-> n.
Above schema does not allow linking from each logical device to appropriate superio chips
or vice versa - sc chips do not have link to it's logical devices.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 62 lines · Evgeniy Polyakov
Quoted 60 lines · Dmitry Torokhov
Quoted 15 lines
Quoted 8 lines
I have a slightly different concern - the superio is a completely new subsystem and it should be integtrated with the driver model ("superio" bus?). Right now it looks like it is reimplementing most of the abstractions (device lists, driver lists, matching, probing). Moving to driver model significatntly affects lifetime rules for the objects, etc. etc. and will definitely not allow code such as above.
It would be nice it we get things right from the start.
bus model is not good here - we need bus in each logical device and bus in each superio chip(or at least second case).
Each bus bus have some crosslinking to devices in other buses, and each new device
must be checked in each bus and probably added to each device...Quoted 9 lines
It is not like I see it.
Consider folowing example:
each device from set A belongs to each device from set B. n <-> n, it is not the case when one bus can handle all features.That is why I did not use driver model there. It is specific design feature, which is proven to work.
Ok, I briefly looked over the patches and that is what I understand (please correct me where I am wrong):
- you have superio chips which are containers providing set of interfaces;
- you have superio chip driver that detects superio chip and manages (enables/disables) individual interfaces.
- you have set of interface drivers (gpio, acb) that bind to individual superio interfaces and provide unified userspace interface that allows reading, writing and analog of ioctl.So the question is why you can't have superio bus where superio chips register their individual interfaces as individual devices. gpio, acb, etc are drivers that bind to superio devices and create class devices gpio.
You could have:
sys
|-bus | |-superio | | |-devices | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0 | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1 | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2 | | |-drivers | | | |-gpio | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1 | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2 | | | |-acb | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0 | |-class | |-gpio | | |-gpio0 | | |-gpio1
Quoted 6 lines
Quoted 3 lines
gpioX have control and data attributes that allow reading and writing...
Am I missing something?
You try to create n <-> 1 relation, but superio by design supposed to be n <-> n.
What design? Hardware design or present implementation design?
Quoted 4 lines
Above schema does not allow linking from each logical device to appropriate superio chips
or vice versa - sc chips do not have link to it's logical devices.
sc chip does have a link to its logical devices - look at 0000:02:03.0 PCI device in the picture above - that your SuperIO chip with 2 interfaces. Interface, when bound to a superio driver creates gpio class device which in turn has link to physical device (here one of the SuperIO interfaces).
Yes, I am trying to do 1 - n relationship. I do not understand why logical device has to span across several physical devices. With the exception of device mapper/raid you don't have a logical device span several physical devices, with everything else there is a parent that has several children.
You have a PCI bus that has several PCI devices, one of them happens to be a IDE host controller with 2 channels connected to it. The other is your SuperIO chip with 2 GPIO pins and something else, and another SuperIO chip with 3 GIPO pins. Let's say you 1st chip monitors temperature in the case and the second interfaces wth some custom equipment measuring some thersholds in some chemical process. Are you saying that all 5 GPIO pins should be presented as one logical device that provides 5 outputs not related to each other? No, you have 5 distinct devices with similar interfaces providing 5 distinct reads. Userspace may chose to group them somehow, based on external information that kernel does not have, but that's it. Kernel only provides uniform interface.
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 64 lines · Dmitry Torokhov
Quoted 62 lines · Evgeniy Polyakov
Quoted 60 lines · Dmitry Torokhov
Quoted 15 lines
Quoted 8 lines
I have a slightly different concern - the superio is a completely new subsystem and it should be integtrated with the driver model ("superio" bus?). Right now it looks like it is reimplementing most of the abstractions (device lists, driver lists, matching, probing). Moving to driver model significatntly affects lifetime rules for the objects, etc. etc. and will definitely not allow code such as above.
It would be nice it we get things right from the start.
bus model is not good here - we need bus in each logical device and bus in each superio chip(or at least second case).
Each bus bus have some crosslinking to devices in other buses, and each new device
must be checked in each bus and probably added to each device...Quoted 9 lines
It is not like I see it.
Consider folowing example:
each device from set A belongs to each device from set B. n <-> n, it is not the case when one bus can handle all features.That is why I did not use driver model there. It is specific design feature, which is proven to work.
Ok, I briefly looked over the patches and that is what I understand (please correct me where I am wrong):
- you have superio chips which are containers providing set of interfaces;
- you have superio chip driver that detects superio chip and manages (enables/disables) individual interfaces.
- you have set of interface drivers (gpio, acb) that bind to individual superio interfaces and provide unified userspace interface that allows reading, writing and analog of ioctl.So the question is why you can't have superio bus where superio chips register their individual interfaces as individual devices. gpio, acb, etc are drivers that bind to superio devices and create class devices gpio.
You could have:
sys
|-bus | |-superio | | |-devices | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0 | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1 | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2 | | |-drivers | | | |-gpio | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1 | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2 | | | |-acb | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0 | |-class | |-gpio | | |-gpio0 | | |-gpio1
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
gpioX have control and data attributes that allow reading and writing...
Am I missing something?
You try to create n <-> 1 relation, but superio by design supposed to be n <-> n.
What design? Hardware design or present implementation design?
Hardware: each superio chip can have exactly the same logical devices like anyother(actually it is standard, which is not always followed). I mean not the same device
set, but logical devices itself - voltage monitors are the same for any standard superio chip.
So we have many chips with the same set of the similar hardware.
Reverse relation is created when we want to keep only number_od_superio_chips + number_of_logical_device number of drivers, but not it's multiplication.
Quoted 18 lines
Quoted 4 lines
Above schema does not allow linking from each logical device to appropriate superio chips
or vice versa - sc chips do not have link to it's logical devices.sc chip does have a link to its logical devices - look at 0000:02:03.0 PCI device in the picture above - that your SuperIO chip with 2 interfaces. Interface, when bound to a superio driver creates gpio class device which in turn has link to physical device (here one of the SuperIO interfaces).
Yes, I am trying to do 1 - n relationship. I do not understand why logical device has to span across several physical devices. With the exception of device mapper/raid you don't have a logical device span several physical devices, with everything else there is a parent that has several children.
Quoted 13 lines
You have a PCI bus that has several PCI devices, one of them happens to be a IDE host controller with 2 channels connected to it. The other is your SuperIO chip with 2 GPIO pins and something else, and another SuperIO chip with 3 GIPO pins. Let's say you 1st chip monitors temperature in the case and the second interfaces wth some custom equipment measuring some thersholds in some chemical process. Are you saying that all 5 GPIO pins should be presented as one logical device that provides 5 outputs not related to each other? No, you have 5 distinct devices with similar interfaces providing 5 distinct reads. Userspace may chose to group them somehow, based on external information that kernel does not have, but that's it. Kernel only provides uniform interface.
Each superio chip has the same logical devices inside. With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb
superio2 - voltage, temp, gpio, rtc, wdt, acb
superio3 - voltage, temp, gpio, rtc, wdt, acb
superio4 - voltage, temp, gpio, rtc, wdt, acb
Each logical device driver (for existing superio schema) is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 + 4*superio_chip_driver_size bytes
of the code.
With my - only 150*6 + 4*superio_chip_driver_size.
And not the code size is matter, but that fact, that changing one driver (for example add feature to more precise temperature conversation) will end up fixing huge amount of driver, but not the one file.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 9 lines · Evgeniy Polyakov
Each superio chip has the same logical devices inside. With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb superio3 - voltage, temp, gpio, rtc, wdt, acb superio4 - voltage, temp, gpio, rtc, wdt, acb
Quoted 5 lines
Each logical device driver (for existing superio schema) is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 + 4*superio_chip_driver_size bytes
of the code.
????? Let's count again, shall we? Suppose we have:
Quoted 2 lines
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x or whatever. So here, you have 2 drivers to manage chips. Plus you have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.
There is no need to many-to-many relationship. Each chip is bound to only one chip driver which registers several interfaces. Each interface is bound to only one interface driver. Interface driver is not chip specific, it knows how to run a specific interface (gpio, temp) and relies on chip driver to properly manage access to the hardware. Each combination of inetrface + interface driver produce one class_device (call it sio, serio, whatever). Class device provides unified view of the interface to the userspace.
What am I missing?
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 35 lines · Dmitry Torokhov
Quoted 9 lines · Evgeniy Polyakov
Each superio chip has the same logical devices inside. With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb superio3 - voltage, temp, gpio, rtc, wdt, acb superio4 - voltage, temp, gpio, rtc, wdt, acbQuoted 5 lines
Each logical device driver (for existing superio schema) is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 + 4*superio_chip_driver_size bytes
of the code.????? Let's count again, shall we? Suppose we have:
Quoted 2 lines
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x or whatever. So here, you have 2 drivers to manage chips. Plus you have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.There is no need to many-to-many relationship. Each chip is bound to only one chip driver which registers several interfaces. Each interface is bound to only one interface driver. Interface driver is not chip specific, it knows how to run a specific interface (gpio, temp) and relies on chip driver to properly manage access to the hardware. Each combination of inetrface + interface driver produce one
class_device(call it sio, serio, whatever). Class device provides unified view of the interface to the userspace.
Quoted 1 line
What am I missing?
Since each logical device does not know who use it, it can not be, for example, removed optimally.
You need to run through whole superio device set to find those one that has reference to logical device being removed.
And situation become much worse, when we have so called logical device clones -
it is virtual logical device that emulates standard one, but inside performs
in a different way. Clone creates inside superio device(for example such device
can live at different address).
When you do not have ldev->sc relation, you must traverse through each logical device
in each superio chip to find clones.
Thus you will need to traverse through each superio chip, then through each logical device it references, just to remove one logical device.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 36 lines · Evgeniy Polyakov
Quoted 35 lines · Dmitry Torokhov
Quoted 9 lines · Evgeniy Polyakov
Each superio chip has the same logical devices inside. With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb superio3 - voltage, temp, gpio, rtc, wdt, acb superio4 - voltage, temp, gpio, rtc, wdt, acbQuoted 5 lines
Each logical device driver (for existing superio schema) is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 + 4*superio_chip_driver_size bytes
of the code.????? Let's count again, shall we? Suppose we have:
Quoted 2 lines
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x or whatever. So here, you have 2 drivers to manage chips. Plus you have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.There is no need to many-to-many relationship. Each chip is bound to only one chip driver which registers several interfaces. Each interface is bound to only one interface driver. Interface driver is not chip specific, it knows how to run a specific interface (gpio, temp) and relies on chip driver to properly manage access to the hardware. Each combination of inetrface + interface driver produce one
class_device(call it sio, serio, whatever). Class device provides unified view of the interface to the userspace.
Quoted 6 lines
Quoted 1 line
What am I missing?
Since each logical device does not know who use it, it can not be, for example, removed optimally.
You need to run through whole superio device set to find those one that has reference to logical device being removed.
What do you mean by removing optimally? Consider teher 2 scenarios:
- you unload logical device driver which knows all the logical
devices (interfaces) it is bound to and it releases those devices.
- you unload chip driver which knows what logical devices it has registered and removes them. Logical devices in turn unbind themselves from the logical drivers thay are bound to (only one for each device and they have link).
Seems pretty clean to me.
Quoted 5 lines
And situation become much worse, when we have so called logical device clones -
it is virtual logical device that emulates standard one, but inside performs
in a different way. Clone creates inside superio device(for example such
Quoted 8 lines
device
can live at different address).
When you do not haveldev->screlation, you must traverse through each logical device
in each superio chip to find clones.
Thus you will need to traverse through each superio chip, then through each logical device it references, just to remove one logical device.
I am confused and need a concrete example. I would think that cases such as these should not require eny special handling, hardware access should be hidden from logical drivers by the chip driver. Or if only difference is the port address then it probably should be set by the chip driver as attribute of logical device.
Look at the serio system again. psmouse module knows how to talk to i8042-type ports. It does not rellay matter to it whther the port is on actual i8042 controller or somewhere else. What matters that it is PS/2 port and it supports writes and reads and that is it. How exactly read is performed (what port address, locking, etc) is of no concern to psmouse. The same I think should be happening here.
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 40 lines · Dmitry Torokhov
Quoted 38 lines · Evgeniy Polyakov
Quoted 36 lines · Dmitry Torokhov
Quoted 9 lines · Evgeniy Polyakov
Each superio chip has the same logical devices inside. With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb superio3 - voltage, temp, gpio, rtc, wdt, acb superio4 - voltage, temp, gpio, rtc, wdt, acbQuoted 5 lines
Each logical device driver (for existing superio schema) is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 + 4*superio_chip_driver_size bytes
of the code.????? Let's count again, shall we? Suppose we have:
Quoted 2 lines
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x or whatever. So here, you have 2 drivers to manage chips. Plus you have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.There is no need to many-to-many relationship. Each chip is bound to only one chip driver which registers several interfaces. Each interface is bound to only one interface driver. Interface driver is not chip specific, it knows how to run a specific interface (gpio, temp) and relies on chip driver to properly manage access to the hardware. Each combination of inetrface + interface driver produce one
class_device(call it sio, serio, whatever). Class device provides unified view of the interface to the userspace.What am I missing?
Quoted 8 lines
Quoted 4 lines
Since each logical device does not know who use it, it can not be, for example, removed optimally.
You need to run through whole superio device set to find those one that has reference to logical device being removed.What do you mean by removing optimally? Consider teher 2 scenarios:
- you unload logical device driver which knows all the logical
devices (interfaces) it is bound to and it releases those devices.
It does not know chip drivers, which reference it. We need to scan all superio chips to find that.
Quoted 5 lines
- you unload chip driver which knows what logical devices it has registered and removes them. Logical devices in turn unbind themselves from the logical drivers thay are bound to (only one for each device and they have link).
Seems pretty clean to me.
Yes, since there is sc->ldev relation.
Quoted 14 lines
Quoted 5 lines
And situation become much worse, when we have so called logical device clones -
it is virtual logical device that emulates standard one, but inside performs
in a different way. Clone creates inside superio device(for example suchQuoted 8 lines
device
can live at different address).
When you do not haveldev->screlation, you must traverse through each logical device
in each superio chip to find clones.
Thus you will need to traverse through each superio chip, then through each logical device it references, just to remove one logical device.
Quoted 5 lines
I am confused and need a concrete example. I would think that cases such as these should not require eny special handling, hardware access should be hidden from logical drivers by the chip driver. Or if only difference is the port address then it probably should be set by the chip driver as attribute of logical device.
Consider sc.c and GPIO logical device in SC1100 (scx driver).
/*
* SuperIO core is registering logical device.
* SuperIO chip knows where it must live.
* If logical device being registered lives at the different location
* (for example when it was registered for all devices,
* but has address(index) corresponding to only one SuperIO chip)
* then we will register new logical device with the same name
* but with the different location(index).
*
* It is called clone.
*/
Quoted 6 lines
Look at the serio system again. psmouse module knows how to talk to i8042-type ports. It does not rellay matter to it whther the port is on actual i8042 controller or somewhere else. What matters that it is PS/2 port and it supports writes and reads and that is it. How exactly read is performed (what port address, locking, etc) is of no concern to psmouse. The same I think should be happening here.
psmouse and sport are completely different example.
Consider you have mouse, that is shared between several users. Should it have reference to each user?
Consider directory that is bind-mounted, should it have reference to it's
original parent tree?
Consider page, that must be swapped, should it have access to all processes
that share it?
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 46 lines · Evgeniy Polyakov
Quoted 45 lines · Dmitry Torokhov
Quoted 42 lines · Evgeniy Polyakov
Quoted 35 lines · Dmitry Torokhov
Quoted 9 lines · Evgeniy Polyakov
Each superio chip has the same logical devices inside. With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb superio3 - voltage, temp, gpio, rtc, wdt, acb superio4 - voltage, temp, gpio, rtc, wdt, acbQuoted 5 lines
Each logical device driver (for existing superio schema) is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 + 4*superio_chip_driver_size bytes
of the code.????? Let's count again, shall we? Suppose we have:
Quoted 2 lines
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x or whatever. So here, you have 2 drivers to manage chips. Plus you have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.There is no need to many-to-many relationship. Each chip is bound to only one chip driver which registers several interfaces. Each interface is bound to only one interface driver. Interface driver is not chip specific, it knows how to run a specific interface (gpio, temp) and relies on chip driver to properly manage access to the hardware. Each combination of inetrface + interface driver produce one
class_device(call it sio, serio, whatever). Class device provides unified view of the interface to the userspace.Quoted 1 line
What am I missing?
Since each logical device does not know who use it, it can not be, for example, removed optimally.
You need to run through whole superio device set to find those one that has reference to logical device being removed.
Quoted 5 lines
Quoted 3 lines
What do you mean by removing optimally? Consider teher 2 scenarios:
- you unload logical device driver which knows all the logical
devices (interfaces) it is bound to and it releases those devices.It does not know chip drivers, which reference it.
Of course it does, every logical device has one parent. Individual GPIO pins are not spread across your motherboard. Every one of them lives on some chip. They can all be driven by the same driver but they are different devices. It is like all your IDE drives are driven by the same driver but (unless LVM which is diffrent layer comes to play) they are still different drives.
Quoted 32 lines
We need to scan all superio chips to find that.
Quoted 5 lines
- you unload chip driver which knows what logical devices it has registered and removes them. Logical devices in turn unbind themselves from the logical drivers thay are bound to (only one for each device and they have link).
Seems pretty clean to me.Yes, since there is
sc->ldevrelation.Quoted 14 lines
Quoted 5 lines
And situation become much worse, when we have so called logical device clones -
it is virtual logical device that emulates standard one, but inside performs
in a different way. Clone creates inside superio device(for example suchQuoted 8 lines
device
can live at different address).
When you do not haveldev->screlation, you must traverse through each logical device
in each superio chip to find clones.
Thus you will need to traverse through each superio chip, then through each logical device it references, just to remove one logical device.Quoted 5 lines
I am confused and need a concrete example. I would think that cases such as these should not require eny special handling, hardware access should be hidden from logical drivers by the chip driver. Or if only difference is the port address then it probably should be set by the chip driver as attribute of logical device.
Consider
sc.cand GPIO logical device in SC1100 (scx driver).
Quoted 12 lines
/*
* SuperIO core is registering logical device.
* SuperIO chip knows where it must live.
* If logical device being registered lives at the different location
* (for example when it was registered for all devices,
* but has address(index) corresponding to only one SuperIO chip)
* then we will register new logical device with the same name
* but with the different location(index).
*
* It is called clone.
*/
In this sense every device is a clone. Consider I have 2 EtherExpress cards in my box. They surely live at different addresses but PCI system does not mess with "clones". And network layer does not care whether both of them driven by e100 or one is e100 and the other is RTL.
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 52 lines · Dmitry Torokhov
Quoted 50 lines · Evgeniy Polyakov
Quoted 48 lines · Dmitry Torokhov
Quoted 36 lines · Evgeniy Polyakov
Quoted 35 lines · Dmitry Torokhov
Quoted 9 lines · Evgeniy Polyakov
Each superio chip has the same logical devices inside. With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb superio3 - voltage, temp, gpio, rtc, wdt, acb superio4 - voltage, temp, gpio, rtc, wdt, acbQuoted 5 lines
Each logical device driver (for existing superio schema) is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 + 4*superio_chip_driver_size bytes
of the code.????? Let's count again, shall we? Suppose we have:
Quoted 2 lines
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x or whatever. So here, you have 2 drivers to manage chips. Plus you have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.There is no need to many-to-many relationship. Each chip is bound to only one chip driver which registers several interfaces. Each interface is bound to only one interface driver. Interface driver is not chip specific, it knows how to run a specific interface (gpio, temp) and relies on chip driver to properly manage access to the hardware. Each combination of inetrface + interface driver produce one
class_device(call it sio, serio, whatever). Class device provides unified view of the interface to the userspace.Quoted 6 lines
Quoted 1 line
What am I missing?
Since each logical device does not know who use it, it can not be, for example, removed optimally.
You need to run through whole superio device set to find those one that has reference to logical device being removed.What do you mean by removing optimally? Consider teher 2 scenarios:
- you unload logical device driver which knows all the logical
devices (interfaces) it is bound to and it releases those devices.
Quoted 8 lines
Quoted 1 line
It does not know chip drivers, which reference it.
Of course it does, every logical device has one parent. Individual GPIO pins are not spread across your motherboard. Every one of them lives on some chip. They can all be driven by the same driver but they are different devices. It is like all your IDE drives are driven by the same driver but (unless LVM which is diffrent layer comes to play) they are still different drives.
No, there is no "parent".
Each logical device is "shared" between several superio chips. It is presented design.
More below.
Quoted 45 lines
Quoted 32 lines
We need to scan all superio chips to find that.
Quoted 5 lines
- you unload chip driver which knows what logical devices it has registered and removes them. Logical devices in turn unbind themselves from the logical drivers thay are bound to (only one for each device and they have link).
Seems pretty clean to me.Yes, since there is
sc->ldevrelation.Quoted 14 lines
Quoted 5 lines
And situation become much worse, when we have so called logical device clones -
it is virtual logical device that emulates standard one, but inside performs
in a different way. Clone creates inside superio device(for example suchQuoted 8 lines
device
can live at different address).
When you do not haveldev->screlation, you must traverse through each logical device
in each superio chip to find clones.
Thus you will need to traverse through each superio chip, then through each logical device it references, just to remove one logical device.Quoted 5 lines
I am confused and need a concrete example. I would think that cases such as these should not require eny special handling, hardware access should be hidden from logical drivers by the chip driver. Or if only difference is the port address then it probably should be set by the chip driver as attribute of logical device.
Consider
sc.cand GPIO logical device in SC1100 (scx driver).Quoted 12 lines
/*
* SuperIO core is registering logical device.
* SuperIO chip knows where it must live.
* If logical device being registered lives at the different location
* (for example when it was registered for all devices,
* but has address(index) corresponding to only one SuperIO chip)
* then we will register new logical device with the same name
* but with the different location(index).
*
* It is called clone.
*/
Quoted 5 lines
In this sense every device is a clone. Consider I have 2 EtherExpress cards in my box. They surely live at different addresses but PCI system does not mess with "clones". And network layer does not care whether both of them driven by e100 or one is e100 and the other is RTL.
It is not the same as two different devices on the bus.
Consider sc1100 - GPIO lives in PCI aperture, absolutely not where superio lives.
(And it is actully not logical device in this case, but it fits well into design).
You skipped my examples, but presented design is very convenient to the situation,
when you have two different sets of devices, or classes of devices, each of which
can have link to any device from the other set.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 62 lines · Evgeniy Polyakov
Quoted 52 lines · Dmitry Torokhov
Quoted 50 lines · Evgeniy Polyakov
Quoted 48 lines · Dmitry Torokhov
Quoted 36 lines · Evgeniy Polyakov
Quoted 35 lines · Dmitry Torokhov
Quoted 9 lines · Evgeniy Polyakov
Each superio chip has the same logical devices inside. With your approach we will have following schema:
bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb superio3 - voltage, temp, gpio, rtc, wdt, acb superio4 - voltage, temp, gpio, rtc, wdt, acbQuoted 5 lines
Each logical device driver (for existing superio schema) is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 + 4*superio_chip_driver_size bytes
of the code.????? Let's count again, shall we? Suppose we have:
Quoted 2 lines
superio1 - voltage, temp, gpio, rtc, wdt, acb superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x or whatever. So here, you have 2 drivers to manage chips. Plus you have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.There is no need to many-to-many relationship. Each chip is bound to only one chip driver which registers several interfaces. Each interface is bound to only one interface driver. Interface driver is not chip specific, it knows how to run a specific interface (gpio, temp) and relies on chip driver to properly manage access to the hardware. Each combination of inetrface + interface driver produce one
class_device(call it sio, serio, whatever). Class device provides unified view of the interface to the userspace.Quoted 6 lines
Quoted 1 line
What am I missing?
Since each logical device does not know who use it, it can not be, for example, removed optimally.
You need to run through whole superio device set to find those one that has reference to logical device being removed.What do you mean by removing optimally? Consider teher 2 scenarios:
- you unload logical device driver which knows all the logical
devices (interfaces) it is bound to and it releases those devices.Quoted 8 lines
Quoted 1 line
It does not know chip drivers, which reference it.
Of course it does, every logical device has one parent. Individual GPIO pins are not spread across your motherboard. Every one of them lives on some chip. They can all be driven by the same driver but they are different devices. It is like all your IDE drives are driven by the same driver but (unless LVM which is diffrent layer comes to play) they are still different drives.
Quoted 3 lines
No, there is no "parent".
Each logical device is "shared" between several superio chips. It is presented design.
Ok, I presume that userspace although you saying that logical device is "shared" between chips different GPIO pins still visible to userspace as separate entities (correct me if I am wrong). That means that you chose in your implementation not to abstract out individual parts of SuperIO container as individual devices and instead have several logical drivers bound directly to a same chip. And that is why you need n-m relationship and inability to fit to the driver model and potential issues with power management. Instead of this
/ <ldev>
<base-dev (PCI|ISA|other)> - <sdev> - <ldev>
\ <ldev>you need this
/<sdev> - <ldev>
<base-dev (PCI|ISA|other)> - <sdev> - <ldev>
\ <sdev> - <ldev>This will decouple chip drivers from the logical drivers.
I argue that present design is sub-optimal and will hurt in the long run.
Quoted 52 lines
Quoted 46 lines
Quoted 33 lines
We need to scan all superio chips to find that.
Quoted 5 lines
- you unload chip driver which knows what logical devices it has registered and removes them. Logical devices in turn unbind themselves from the logical drivers thay are bound to (only one for each device and they have link).
Seems pretty clean to me.Yes, since there is
sc->ldevrelation.Quoted 14 lines
Quoted 5 lines
And situation become much worse, when we have so called logical device clones -
it is virtual logical device that emulates standard one, but inside performs
in a different way. Clone creates inside superio device(for example suchQuoted 8 lines
device
can live at different address).
When you do not haveldev->screlation, you must traverse through each logical device
in each superio chip to find clones.
Thus you will need to traverse through each superio chip, then through each logical device it references, just to remove one logical device.Quoted 5 lines
I am confused and need a concrete example. I would think that cases such as these should not require eny special handling, hardware access should be hidden from logical drivers by the chip driver. Or if only difference is the port address then it probably should be set by the chip driver as attribute of logical device.
Consider
sc.cand GPIO logical device in SC1100 (scx driver).Quoted 12 lines
/*
* SuperIO core is registering logical device.
* SuperIO chip knows where it must live.
* If logical device being registered lives at the different location
* (for example when it was registered for all devices,
* but has address(index) corresponding to only one SuperIO chip)
* then we will register new logical device with the same name
* but with the different location(index).
*
* It is called clone.
*/Quoted 5 lines
In this sense every device is a clone. Consider I have 2 EtherExpress cards in my box. They surely live at different addresses but PCI system does not mess with "clones". And network layer does not care whether both of them driven by e100 or one is e100 and the other is RTL.
Quoted 6 lines
It is not the same as two different devices on the bus.
Consider sc1100 - GPIO lives in PCI aperture, absolutely not where superio lives.
(And it is actully not logical device in this case, but it fits well into design).
It does not matter where it "lives". The chip driver should not expose these details to interface driver. Although you said serio examples are not applicable here let's take another look there: i8042 and pcips2 modules. One provides serio ports that live in legacy IO space, the other is PCI-based. psmouse would not care less which one is behind the port it is bound to.
Quoted 6 lines
You skipped my examples, but presented design is very convenient to the situation,
when you have two different sets of devices, or classes of devices, each of which
can have link to any device from the other set.
They were from different domains so irrelevant.
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 22 lines · On Wed, 26 Jan 2005 13:26:38 -0500 Dmitry Torokhov <[email protected]>…
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
Since each logical device does not know who use it, it can not be, for example, removed optimally.
You need to run through whole superio device set to find those one that has reference to logical device being removed.What do you mean by removing optimally? Consider teher 2 scenarios:
- you unload logical device driver which knows all the logical
devices (interfaces) it is bound to and it releases those devices.Quoted 8 lines
Quoted 1 line
It does not know chip drivers, which reference it.
Of course it does, every logical device has one parent. Individual GPIO pins are not spread across your motherboard. Every one of them lives on some chip. They can all be driven by the same driver but they are different devices. It is like all your IDE drives are driven by the same driver but (unless LVM which is diffrent layer comes to play) they are still different drives.
Quoted 3 lines
No, there is no "parent".
Each logical device is "shared" between several superio chips. It is presented design.
Quoted 8 lines
Ok, I presume that userspace although you saying that logical device is "shared" between chips different GPIO pins still visible to userspace as separate entities (correct me if I am wrong). That means that you chose in your implementation not to abstract out individual parts of SuperIO container as individual devices and instead have several logical drivers bound directly to a same chip. And that is why you need n-m relationship and inability to fit to the driver model and potential issues with power management. Instead of this
Userspace has access to GPIO logical device by it's name and name of the superio chip it is connected to.
Quoted 6 lines
/ <ldev> <base-dev (PCI|ISA|other)> - <sdev> - <ldev> \ <ldev>you need this
Quoted 7 lines
/<sdev> - <ldev> <base-dev (PCI|ISA|other)> - <sdev> - <ldev> \ <sdev> - <ldev>This will decouple chip drivers from the logical drivers.
I argue that present design is sub-optimal and will hurt in the long run.
This picture is somewhat better presents superio design:
sdev sdev
|-----| |-----| ldev ldev ldev
Where |---| links are bidirectional.
Probably you are right, but I doubt :)
Quoted 58 lines
Quoted 51 lines
Quoted 45 lines
Quoted 32 lines
We need to scan all superio chips to find that.
Quoted 5 lines
- you unload chip driver which knows what logical devices it has registered and removes them. Logical devices in turn unbind themselves from the logical drivers thay are bound to (only one for each device and they have link).
Seems pretty clean to me.Yes, since there is
sc->ldevrelation.Quoted 14 lines
Quoted 5 lines
And situation become much worse, when we have so called logical device clones -
it is virtual logical device that emulates standard one, but inside performs
in a different way. Clone creates inside superio device(for example suchQuoted 8 lines
device
can live at different address).
When you do not haveldev->screlation, you must traverse through each logical device
in each superio chip to find clones.
Thus you will need to traverse through each superio chip, then through each logical device it references, just to remove one logical device.Quoted 5 lines
I am confused and need a concrete example. I would think that cases such as these should not require eny special handling, hardware access should be hidden from logical drivers by the chip driver. Or if only difference is the port address then it probably should be set by the chip driver as attribute of logical device.
Consider
sc.cand GPIO logical device in SC1100 (scx driver).Quoted 12 lines
/*
* SuperIO core is registering logical device.
* SuperIO chip knows where it must live.
* If logical device being registered lives at the different location
* (for example when it was registered for all devices,
* but has address(index) corresponding to only one SuperIO chip)
* then we will register new logical device with the same name
* but with the different location(index).
*
* It is called clone.
*/Quoted 5 lines
In this sense every device is a clone. Consider I have 2 EtherExpress cards in my box. They surely live at different addresses but PCI system does not mess with "clones". And network layer does not care whether both of them driven by e100 or one is e100 and the other is RTL.
Quoted 6 lines
It is not the same as two different devices on the bus.
Consider sc1100 - GPIO lives in PCI aperture, absolutely not where superio lives.
(And it is actully not logical device in this case, but it fits well into design).
Quoted 6 lines
It does not matter where it "lives". The chip driver should not expose these details to interface driver. Although you said serio examples are not applicable here let's take another look there: i8042 and pcips2 modules. One provides serio ports that live in legacy IO space, the other is PCI-based. psmouse would not care less which one is behind the port it is bound to.
Chip driver provides access methods to the attached logical devices. It probes and activates them, if appropriate module is loaded.
Your example again is not suitable for superio case.
With superio you have several identical logical devices, access to which is absolutely standard in second level(logic befind access), but in first one(physicall access) it can differ.
So here is the real example of superio usage:
userspace
|
superio core
......
GPIO
|----| |--|
pc87366 sc1100
|----| |---|WDT
Logical device GPIO is accessed by read/write methods, which only have pin number(it is not how this methods are exactly implemeted though) as parameter.
For example userspace accesses GPIO at sc1100 - it will be translated into read methods called from appropriate superio chip with appropriate parameters.
When we have multiple GPIO logical devices(each in it's own superio chip) it is more convenient to use just the same object.
I did not understand you from the beginning...
It can be turned into device model quite well, only individual objects should have backward references to allow easier manipulation with it's "owners". Your above schema with device model is quite right, just add invisible links from each device to/from it's "masters".
Quoted 3 lines
Signature · 2 lines
-- Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1
Quoted 27 lines · Evgeniy Polyakov
Chip driver provides access methods to the attached logical devices. It probes and activates them, if appropriate module is loaded.
Your example again is not suitable for superio case.
With superio you have several identical logical devices, access to which is absolutely standard in second level(logic befind access), but in first one(physicall access) it can differ.
So here is the real example of superio usage:
userspace | superio core ...... GPIO |----| |--| pc87366 sc1100 |----| |---|WDT
Logical device GPIO is accessed by read/write methods, which only have pin number(it is not how this methods are exactly implemeted though) as parameter.
Quoted 6 lines
For example userspace accesses GPIO at sc1100 - it will be translated into read methods called from appropriate superio chip with appropriate parameters.
When we have multiple GPIO logical devices(each in it's own superio chip) it is more convenient to use just the same object.
I take an exception to that. I think useroace is not concerned with topology and ownership of logical devices, the data is more important. I.e. you need to know that some pin respons to CPU temperature but you don't really care that it connected to it87 as opposed to some other chip. Therefore I think that ldev should translate to exactly the same underlying object. Consider the picture below:
GPIO0 GPIO1 GPIO2 GPIO3
| | | |
pc87266 sc1100 blah123
| |
WDT0 WDT1
This will allow:
- map every hardware piece (not entire chip, separate functions) to a device file to userspace can use standard read/write/select/poll if choses so.
- easily represent them in sysfs and also allow userspace access to individual bits through sysfs attributes.
- will not give headaches with poer management when half of device is powered down and half is active.
- provided that there are alternative interfaces outlined above superio can be decoupled from the connector.
I wonder if it should be called "gpio" bus as opposed to superio because only chips are "super", the bus consists of very simple devices and drivers.
Quoted 1 line
I did not understand you from the beginning...
We are getting there I believe ;)
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 49 lines · On Wed, 26 Jan 2005 15:22:52 -0500 Dmitry Torokhov <[email protected]>…
Quoted 27 lines · Evgeniy Polyakov
Chip driver provides access methods to the attached logical devices. It probes and activates them, if appropriate module is loaded.
Your example again is not suitable for superio case.
With superio you have several identical logical devices, access to which is absolutely standard in second level(logic befind access), but in first one(physicall access) it can differ.
So here is the real example of superio usage:
userspace | superio core ...... GPIO |----| |--| pc87366 sc1100 |----| |---|WDT
Logical device GPIO is accessed by read/write methods, which only have pin number(it is not how this methods are exactly implemeted though) as parameter.
Quoted 6 lines
For example userspace accesses GPIO at sc1100 - it will be translated into read methods called from appropriate superio chip with appropriate parameters.
When we have multiple GPIO logical devices(each in it's own superio chip) it is more convenient to use just the same object.
I take an exception to that. I think useroace is not concerned with topology and ownership of logical devices, the data is more important. I.e. you need to know that some pin respons to CPU temperature but you don't really care that it connected to it87 as opposed to some other chip. Therefore I think that ldev should translate to exactly the same underlying object. Consider the picture below:
GPIO0 GPIO1 GPIO2 GPIO3
| | | |
pc87266 sc1100 blah123
| |
WDT0 WDT1
Quoted 10 lines
This will allow:
- map every hardware piece (not entire chip, separate functions) to a device file to userspace can use standard read/write/select/poll if choses so.
- easily represent them in sysfs and also allow userspace access to individual bits through sysfs attributes.
- will not give headaches with poer management when half of device is powered down and half is active.
- provided that there are alternative interfaces outlined above superio can be decoupled from the connector.
With presented design we already have above links.
Each superio chip has a list of chain objects, each of which points to the connected logical device.
Logical device usage must be done using provided logical device methods (like read/write/control).
Quoted 1 line
From that point of view noone even knows, that above GPIO0 and GPIO1
(on the picture) are actually the same object(if they are not clones, but if they are, then picture becomes 100% real).
Quoted 3 lines
I wonder if it should be called "gpio" bus as opposed to superio because only chips are "super", the bus consists of very simple devices and drivers.
I can not agree that it is a bus.
Bus abstraction can be _only_ applied to hierarchy in the only one superio chip.
Quoted 6 lines
Quoted 1 line
I did not understand you from the beginning...
We are getting there I believe ;)
Signature · 1 line
Dmitry
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: 2.6.11-rc2-mm1
In reply to Evgeniy PolyakovQuoted 4 lines
Zeroing can be found easily - the whole structure is NULL pointer, and will always panic if accessed(from running superio code), but redzoning is only happen on borders,
and can catch writes over the boards, which is rarely in this case.
As I mentioned the redzoning was a brainfar on my side. Slab debug code memsets all code with an easily recognizable pattern (which 0 is _NOT_).
So this is totally useless, please don't do it - as all major subsystems don't do it either.
Quoted 4 lines
Each superio chip is registered with superio core without any devices. Each logical device is registered with superio core without any superio chip.
Quoted 8 lines
Then core checks if some chip is found in some superio device, and links
it to appropriate device.
So if board has several superio chips(like soekris board) and several logical devices in it, then we only have 2 superio small drivers, and several
logical device drivers, but not number_of_superio_chips*number_of_logical_devices drivers.
That's how just about any bus driver works so far.
Now somewhere else in the thread I read the a single logical device might belong to multiple superio devices. Which is kinda odd, but in that case it's indeed needed.
So please add a big comment explaining that properperty because it is extemly uncommon, and make 'ptr' in the chain structure typed instead of void *
Quoted 5 lines
Yes, and it is better than removing module whose structures are in use. SuperIO core is asynchronous in it's nature, one can use logical device through superio core and remove it's module on other CPU, above loop will
wait untill all reference counters are dropped.
General rule is: increment module reference count while the hardware is actually in use, and let device structures be allocated by the bus core so drivers can be freed with them still allocated. That's how the driver model and thus about every other subsystem works.
Re: 2.6.11-rc2-mm1
Quoted 10 lines · Christoph Hellwig
Quoted 4 lines
Zeroing can be found easily - the whole structure is NULL pointer, and will always panic if accessed(from running superio code), but redzoning is only happen on borders,
and can catch writes over the boards, which is rarely in this case.As I mentioned the redzoning was a brainfar on my side. Slab debug code memsets all code with an easily recognizable pattern (which 0 is _NOT_).
So this is totally useless, please don't do it - as all major subsystems don't do it either.
Ok, I do not insist.
Quoted 15 lines
Quoted 4 lines
Each superio chip is registered with superio core without any devices. Each logical device is registered with superio core without any superio chip.
Quoted 8 lines
Then core checks if some chip is found in some superio device, and links
it to appropriate device.
So if board has several superio chips(like soekris board) and several logical devices in it, then we only have 2 superio small drivers, and several
logical device drivers, but not number_of_superio_chips*number_of_logical_devices drivers.That's how just about any bus driver works so far.
Quoted 7 lines
Now somewhere else in the thread I read the a single logical device might belong to multiple superio devices. Which is kinda odd, but in that case it's indeed needed.
So please add a big comment explaining that properperty because it is extemly uncommon, and make 'ptr' in the chain structure typed instead of void *
Ok.
Quoted 10 lines
Quoted 5 lines
Yes, and it is better than removing module whose structures are in use. SuperIO core is asynchronous in it's nature, one can use logical device through superio core and remove it's module on other CPU, above loop will
wait untill all reference counters are dropped.General rule is: increment module reference count while the hardware is actually in use, and let device structures be allocated by the bus core so drivers can be freed with them still allocated. That's how the driver model and thus about every other subsystem works.
It is not general rule - network stack does not have such mechanism, which is
very good, I doubt each block device module increment it's module reference
when it catch a request...
It is internal structure that has reference counter, not module itself, and this
structure may be in use, when module is unloaded, thus unloading must wait,
untill all it's structures are freed.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
Quoted 12 lines · Evgeniy Polyakov
Quoted 10 lines · Christoph Hellwig
Quoted 5 lines
Yes, and it is better than removing module whose structures are in use. SuperIO core is asynchronous in it's nature, one can use logical device through superio core and remove it's module on other CPU, above loop will
wait untill all reference counters are dropped.General rule is: increment module reference count while the hardware is actually in use, and let device structures be allocated by the bus core so drivers can be freed with them still allocated. That's how the driver model and thus about every other subsystem works.
Quoted 11 lines
It is not general rule - network stack does not have such mechanism, which is
very good, I doubt each block device module increment it's module reference
when it catch a request...
It is internal structure that has reference counter, not module itself, and this
structure may be in use, when module is unloaded, thus unloading must wait,
untill all it's structures are freed.
No, it does not necessarily has to wait. You can unload driver at any time if you care to mark all its devices as "dead" and you have generic release function in a separate module that does not get unloaded until last registered device has been destroyed. Look for example at serio code. I think USB is about the same.
Signature · 1 line
Dmitry
Re: 2.6.11-rc2-mm1
Quoted 26 lines · Dmitry Torokhov
Quoted 12 lines · Evgeniy Polyakov
Quoted 10 lines · Christoph Hellwig
Quoted 5 lines
Yes, and it is better than removing module whose structures are in use. SuperIO core is asynchronous in it's nature, one can use logical device through superio core and remove it's module on other CPU, above loop will
wait untill all reference counters are dropped.General rule is: increment module reference count while the hardware is actually in use, and let device structures be allocated by the bus core so drivers can be freed with them still allocated. That's how the driver model and thus about every other subsystem works.
Quoted 11 lines
It is not general rule - network stack does not have such mechanism, which is
very good, I doubt each block device module increment it's module reference
when it catch a request...
It is internal structure that has reference counter, not module itself, and this
structure may be in use, when module is unloaded, thus unloading must wait,
untill all it's structures are freed.
Quoted 6 lines
No, it does not necessarily has to wait. You can unload driver at any time if you care to mark all its devices as "dead" and you have generic release function in a separate module that does not get unloaded until last registered device has been destroyed. Look for example at serio code. I think USB is about the same.
It is only because those structures can live outside the driver. Like skb can live without even any network driver loaded. Above case is similar, but structure is binded to the module, and can be
requested outside the world.
Consider as example network stack:netdev_wait_allrefs() waits until all references are gone, it is called
when device has NETREG_UNREGISTERING state.
Very clean example is virtual devices here(tunnels, vlan) - it is exactly the same
as logical/superio devices in superio core.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: 2.6.11-rc2-mm1
In reply to Christoph HellwigHi!
Quoted 18 lines
Review of the superio subsystem sneaked in through bk-i2c.patch:
diff -Nru a/drivers/superio/Kconfig b/drivers/superio/Kconfig
drivers/superio/Kconfig new file +10
-0@@ -0,0 +1,56 @@ +menu "SuperIO subsystem support" + +config SC_SUPERIO + tristate "SuperIO subsystem support" + depends on CONNECTOR + help + SuperIO subsystem support. + + This support is also available as a module. If so, the module + will be called superio.ko.
Quoted 6 lines
This doesn't mention what "SuperIO" is at all. Also please skip the .ko postfix for the module name as the intree Kconfigs do. The boilerplate has changed to:
To compile this driver as a module, choose M here: the module will be called <foo>.
Could we kill this boilerplate? Just explain modules in CONFIG_MODULE or something like that. Or making module name mandatory parameter for tristates, or something like that...
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Re: 2.6.11-rc2-mm1
In reply to Andrew Morton-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 1 line · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
This acpi_power_off issue ( http://lkml.org/lkml/2005/1/11/88 ) still happens.
Marcos Marado
- -- /* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFB9po4mNlq8m+oD34RAuoFAKDWkLvIwIdpf/6NBQWdtML41LLXcQCcDSWq yiRWlDpUaJrfrZR4iMKHcGY=
=nv2D
-----END PGP SIGNATURE-----
Re: 2.6.11-rc2-mm1
Quoted 2 lines · Marcos D. Marado Torres
This
acpi_power_offissue ( http://lkml.org/lkml/2005/1/11/88 ) still happens.
http://bugme.osdl.org/show_bug.cgi?id=4041
Look at that bug report (especially toward the bottom) for the latest information.
-Barry K. Nathan <[email protected]>
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 6 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Someone who sent you a patch needs to learn how to use grep(1). There are 18 patches listed by grep -l it_timer patches/*; giving up.
-- wli
drivers/char/mmtimer.c: In function `reschedule_periodic_timer':drivers/char/mmtimer.c:423: error: structure has no member named it_timer' drivers/char/mmtimer.c:429: error: structure has no member named it_timer' drivers/char/mmtimer.c:429: error: structure has no member named it_incr' drivers/char/mmtimer.c:435: error: structure has no member named it_timer' drivers/char/mmtimer.c: In function `mmtimer_interrupt':drivers/char/mmtimer.c:471: error: structure has no member named it_timer' drivers/char/mmtimer.c: In function mmtimer_tasklet':drivers/char/mmtimer.c:508: error: structure has no member named it_incr' drivers/char/mmtimer.c:516: error: structure has no member named it_timer' drivers/char/mmtimer.c: In function `sgi_timer_create':drivers/char/mmtimer.c:527: error: structure has no member named it_timer' drivers/char/mmtimer.c: In function sgi_timer_del':drivers/char/mmtimer.c:538: error: structure has no member named it_timer' drivers/char/mmtimer.c:539: error: structure has no member named it_timer' drivers/char/mmtimer.c:547: error: structure has no member named it_timer' drivers/char/mmtimer.c:548: error: structure has no member named it_timer' drivers/char/mmtimer.c: In function `sgi_timer_get':drivers/char/mmtimer.c:561: error: structure has no member named it_timer' drivers/char/mmtimer.c:569: error: structure has no member named it_incr' drivers/char/mmtimer.c:570: error: structure has no member named it_timer' drivers/char/mmtimer.c: In function sgi_timer_set':drivers/char/mmtimer.c:643: error: structure has no member named it_timer' drivers/char/mmtimer.c:644: error: structure has no member named it_timer' drivers/char/mmtimer.c:645: error: structure has no member named it_incr' drivers/char/mmtimer.c:646: error: structure has no member named it_timer' drivers/char/mmtimer.c:652: error: structure has no member named it_timer' drivers/char/mmtimer.c:655: error: structure has no member named it_timer' make[4]: *** [drivers/char/mmtimer.o] Error 1
make[3]: *** [drivers/char] Error 2
make[2]: *** [drivers] Error 2
make[2]: *** Waiting for unfinished jobs....
PATCH 1/1 ppc64: fix use kref for device_node refcounting
In reply to Andrew MortonQuoted 2 lines · Andrew Morton
ppc64-use-kref-for-device_node-refcounting.patch
ppc64: use kref fordevice_noderefcounting
This introduced an unbalanced get/put in of_add_node which would cause newly-added device nodes to be prematurely freed. Sorry for the screwup, a more rigorously tested fix follows.
---
arch/ppc64/kernel/prom.c renamed from arch/ppc64/kernel/prom.c~fix-kref-devnode +1 -0
@@ -1771,6 +1771,7 @@ int of_add_node(const char *path, struct np->properties = proplist;OF_MARK_DYNAMIC (np);kref_init (&np->kref); +of_node_get (np); np->parent =derive_parent (path);if (!np->parent) {kfree (np);
_
Re: 2.6.11-rc2-mm1
In reply to Andrew MortonQuoted 6 lines · Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
autofs has exploded far, far beyond complete nonfunctionality, where in prior 2.6.x it was not quite so blatantly a doorstop preventing all logins on the machine, and, in fact, multiuser mode altogether.
Whoever's responsible, prepare to be flamed to a crisp the likes of which has never been witnessed before by observers of solar probes, nor conceived of by the most visionary and imaginative of eschatologists.
-- wli
Re: 2.6.11-rc2-mm1
Quoted 5 lines · Andrew Morton
Quoted 5 lines
- Lots of updates and fixes all over the place.
- On my test box there is no flashing cursor on the vga console. Known bug, please don't report it.
Binary searching shows that the bug was introduced by cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
Quoted 6 lines · William Lee Irwin III
autofs has exploded far, far beyond complete nonfunctionality, where in prior 2.6.x it was not quite so blatantly a doorstop preventing all logins on the machine, and, in fact, multiuser mode altogether. Whoever's responsible, prepare to be flamed to a crisp the likes of which has never been witnessed before by observers of solar probes, nor conceived of by the most visionary and imaginative of eschatologists.
Looks like I just need to smack the hands of whoever blew away modutils. I worked around this properly, by fully demodularizing the kernel. Anyway, thus far ppc64 comes up clean with no patches, ia64 comes up clean with clameter's mmtimer patch. Other arches pending.
-- wli