Re: [PATCH 7/7] driver-core : convert semaphore to mutex in struct class
On Fri, Jan 18, 2008 at 03:48:02PM +0800, Dave Young wrote: > On Jan 18, 2008 3:38 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote: ... > > IMHO, it would be nice to get the real state of current lockdep > > problems here to figure out if there is any chance to do this right & > > without any warnings with current lockdep. If I got it right from > > earlier threads it might be impossible with USB, at least. > > I don't think so, usb doesn't be affected by struct class mutex, they > only use the lock of struct device. As I replied before, the lockdep > issue exist only between class_interface and class_device. OK, but I've meant possibility of changing their own semaphores later. > > So, since I think these nesting levels seem to be wrong in 7/7 patch, > > maybe it's better to exclude it from this patchset, and to try this as > > testing for some time. > > I may file the updated patch with more nesting changes and test it of > course. Actually I should have done it, thanks. ... > 1) Using CLASS_NORMAL/CLASS_PARENT/CLASS_CHILD will be enough. > or > 2) Simply add SINGLE_LEVEL_NESTING in class_device_add and other > class_device functions because it is the only possible nest-lock place > as I know. If SINGLE_LEVEL_NESTING is enough? (means 2 levels total) I think you should more care about real (logical) relations here, than what's enough to get rid of lockdep warnings. Since there are not so much of these changes, you can try both variants. I'll be glad to look at this - maybe I'll mangage to figure out BTW, what it's all about... Jarek P. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_32: remove the useless NR_syscalls macro
* Dmitri Vorobiev <[EMAIL PROTECTED]> wrote: > This is against current x86.git. > > The size of the system call table for 32-bit x86 kernels is obtained > by compile-time calculation of the sys_call_table array, not from the > value, which the NR_syscalls macro expands to. This trivial patch > removes the fossil macro. > > Manually tested by grepping the x86 files for the "NR_syscalls" > string. No relevant use cases found. > > Build-tested using allyesconfig, allnoconfig and a couple of > randconfig instances. All builds successfully finished. > > Runtime test performed using a stripped-down Debian-ish config. The > system booted successfully. thanks, applied. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: clean arch/[i386|x86_64] in make mrproper
On 01/17/2008 02:37 PM, Michael Opdenacker wrote: > > Proposed fix: add arch/i386 and arch/x86_84 to the list of > directories cleaned by "make mrproper" > > Cleaner solution: stop creating these symbolic links, but this > could cause issues with scripts still expecting bzImage in > arch/i386/boot/bzImage or in arch/x86_64/boot/bzImage. > > What do you think? I can submit another patch for the second > option. > > Michael. > > Signed-off-by: Michael Opdenacker <[EMAIL PROTECTED]> --- > linux-2.6.24-rc8-git1/Makefile2008-01-17 09:54:22.0 > +0100 +++ linux-2.6.24-rc8-git1-mrproper-x86/Makefile2008-01-17 > 10:49:19.0 +0100 @@ -1088,7 +1088,7 @@ .tmp_kallsyms* > .tmp_version .tmp_vmlinux* .tmp_System.map > > # Directories & files removed with 'make mrproper' -MRPROPER_DIRS > += include/config include2 usr/include +MRPROPER_DIRS += > include/config include2 usr/include arch/i386 arch/x86_64 > MRPROPER_FILES += .config .config.old include/asm .version > .old_version \ include/linux/autoconf.h include/linux/version.h > \ include/linux/utsrelease.h\ > The problem is still there in 2.6.24-rc8-git2. In my opinion, it's a significant bug in the kernel build system that "make mrproper" and "make distclean" don't remove all generated files. 2.6.24 shoudn't ship with this bug. What do you think? Cheers, Michael. -- Michael Opdenacker, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X86: fix typo PAT to X86_PAT
* Yinghai Lu <[EMAIL PROTECTED]> wrote: > config MTRR > bool "MTRR (Memory Type Range Register) support" > - depends on !PAT > + depends on !X86_PAT > ---help--- > On Intel P6 family processors (Pentium Pro, Pentium II and later) > the Memory Type Range Registers (MTRRs) may be used to control thanks. But, i think we should rather do the following: if X86_PAT is eanbled then /proc/mtrr should be read-only. There's no problem _looking_ at MTRR contents, as long as we do not try to modify them. Hm? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: remove redundant cpu_has_ definitions
* Kyle McMartin <[EMAIL PROTECTED]> wrote: > --- a/include/asm-x86/cpufeature.h > +++ b/include/asm-x86/cpufeature.h > @@ -195,21 +195,6 @@ > #undef cpu_has_centaur_mcr > #define cpu_has_centaur_mcr 0 > > -#undef cpu_has_pse > -#define cpu_has_pse 1 > - > -#undef cpu_has_pge > -#define cpu_has_pge 1 > - > -#undef cpu_has_xmm > -#define cpu_has_xmm 1 > - > -#undef cpu_has_xmm2 > -#define cpu_has_xmm2 1 > - > -#undef cpu_has_fxsr > -#define cpu_has_fxsr 1 > - thanks, applied. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc8-mm1 Build Failure at scripts/mkubooting/crc32.c
On Fri, Jan 18, 2008 at 11:44:34AM +0530, Kamalesh Babulal wrote: > Hi Andrew, > > The kernel build fails with following error message > > scripts/mkubootimg/crc32.c:15:18: error: zlib.h: No such file or directory > scripts/mkubootimg/crc32.c:77: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'crc_table' > scripts/mkubootimg/crc32.c:153: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'crc32' > make[2]: *** [scripts/mkubootimg/crc32.o] Error 1 > make[1]: *** [scripts/mkubootimg] Error 2 > make: *** [scripts] Error 2 > > The patch causing this build failure may be git-kbuild.patch. The mkubootimg patches in kbuild.git has been reverted - but that was after akpm merged kbuild.git. So it is fixed in next -mm. The workaround for now is to just remove the line containing "mkubootimg" in scripts/Makefile. (Assuming you do not need the uImage target). Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
