Re: linux-next: build failure after merge of the nfsd tree
On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? I was hoping I could consider the gss-proxy work committed at this point and pile any fixes on top, but... whatever works for you guys, I guess. --b. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-next-20130422] Bug in SLAB?
On Mon, 29 Apr 2013, Glauber Costa wrote: On 04/29/2013 06:59 PM, Christoph Lameter wrote: The code in kmalloc_index() creates a BUG() and preferentially should create a compile time failure when a number that is too big is passed to it. What is MAX_ORDER on the architecture? Returning NULL is fine, but kmalloc_index currently does not check for MAX_ORDER at all. Could easily add that and BUG() on it? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v3.9.0-rc8 : oops in tick_do_update_jiffies64+0xbc/0x110
On 29/04/13 16:41, Tony Lindgren wrote: * Mark Jackson mpfj-l...@newflow.co.uk [130429 01:38]: I've been experiencing several crashes all pointing exactly the same place in the same tick routine (see below). The exception stack trace at the end changes depending on when the oops occurs. I've had the oops occur maybe 6 times in the last 50 reboots. Any ideas ? Sounds like it might be an issue with the physical memory or the timings. It could also be related to the idle loop not restoring something right for deeper idle states that corrupts the memory. And that's why it would seem to appear while waking to a timer. I am suspecting a borderline CPU. We only have X AM3359 parts which are all pre-production. Maybe disable PM and run memtester to see if that runs reliably? I'll see if I can get it running on our platform. Thanks Mark J. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0
On Wed, Apr 24, 2013 at 08:16:37PM +0200, Sander Eikelenboom wrote: Friday, April 19, 2013, 4:44:01 PM, you wrote: Hey Jens, Please in your spare time (if there is such a thing at a conference) pull this branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10 .. snip.. Hi Konrad / Roger, I tried this pull on top of latest Linus latest linux-3.9 tree, but although it seems to boot and work fine at first, i seem to get trouble after running for about a day. Without this pull it runs fine for several days. .. snipp. [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0 [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ #1 [18496.049897] Call Trace: [18496.067674] [81100c51] warn_alloc_failed+0xf1/0x140 [18496.085453] [810b25ed] ? trace_hardirqs_on+0xd/0x10 [18496.102951] [810bdb24] ? on_each_cpu_mask+0x94/0xd0 [18496.120270] [811028af] __alloc_pages_nodemask+0x69f/0x960 [18496.137306] [8113a161] alloc_pages_current+0xb1/0x160 [18496.154051] [81100679] __get_free_pages+0x9/0x40 [18496.170579] [81142af4] __kmalloc+0x134/0x160 [18496.186921] [815832d0] xen_blkbk_probe+0x170/0x2f0 [18496.202963] [81474ce7] xenbus_dev_probe+0x77/0x130 [18496.218714] [8156a390] ? __driver_attach+0xa0/0xa0 [18496.234237] [8156a151] driver_probe_device+0x81/0x220 [18496.249605] [8198198c] ? klist_next+0x8c/0x110 [18496.264681] [8156a390] ? __driver_attach+0xa0/0xa0 [18496.279500] [8156a3db] __device_attach+0x4b/0x50 [18496.294138] [815684e8] bus_for_each_drv+0x68/0x90 [18496.308553] [8156a0c9] device_attach+0x89/0x90 [18496.322694] [81569258] bus_probe_device+0xa8/0xd0 [18496.336640] [81567c80] device_add+0x650/0x720 .. snip.. Jens, I don't know if you had pulled this git tree yet (I don't see it in your for-3.10/* branches). But if you have, Sander has found a bug (and Roger has a fix for it). Whether you would like to wait until v3.11 to pull it (and me sending the git pull around a month) is OK. Or pull it now and we will fix the bugs in the -rc's as they creep up. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (kvm)
On 04/29/13 02:17, Stephen Rothwell wrote: Hi all, Changes since 20130426: on x86_64: arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in this function) Oops, CONFIG_PCI is not enabled. Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.9.0-rc8 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_FHANDLE=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ALWAYS_USE_PERSISTENT_CLOCK=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_NAMESPACES is not set CONFIG_UIDGID_CONVERTED=y CONFIG_UIDGID_STRICT_TYPE_CHECKS=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set CONFIG_RD_LZMA=y CONFIG_RD_XZ=y # CONFIG_RD_LZO is not set CONFIG_RD_LZ4=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HOTPLUG=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_PCSPKR_PLATFORM is not set CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_SHMEM is not set # CONFIG_AIO is not set # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_DEBUG_PERF_USE_VMALLOC=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLUB_DEBUG is not set #
Re: [linux-next-20130422] Bug in SLAB?
On 04/29/2013 07:46 PM, Christoph Lameter wrote: On Mon, 29 Apr 2013, Glauber Costa wrote: On 04/29/2013 06:59 PM, Christoph Lameter wrote: The code in kmalloc_index() creates a BUG() and preferentially should create a compile time failure when a number that is too big is passed to it. What is MAX_ORDER on the architecture? Returning NULL is fine, but kmalloc_index currently does not check for MAX_ORDER at all. Could easily add that and BUG() on it? We could, but now I am intrigued by the fact that the patch I sent does not fix Tetsuo's problem. 8M should be well within MAX_ORDER -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] ptrace/x86: introduce ptrace_register_breakpoint()
On Thu, Apr 18, 2013 at 08:44:17PM +0200, Oleg Nesterov wrote: No functional changes, preparation. Extract the register breakpoint code from ptrace_get_debugreg() into the new/generic helper, ptrace_register_breakpoint(). It will have more users. The patch also adds another simple helper, ptrace_fill_bp_fields(), to factor out the arch_bp_generic_fields() logic in register/modify. Signed-off-by: Oleg Nesterov o...@redhat.com Acked-by: Frederic Weisbecker fweis...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] ptrace/x86: ptrace_write_dr7() should create bp if !disabled
On Thu, Apr 18, 2013 at 08:44:19PM +0200, Oleg Nesterov wrote: 24f1e32c hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf events introduced the minor regression. Before this commit PTRACE_POKEUSER DR7, enableDR0 PTRACE_POKEUSER DR0, address was perfectly valid, now PTRACE_POKEUSER(DR7) fails if DR0 was not previously initialized by PTRACE_POKEUSER(DR0). Change ptrace_write_dr7() to do ptrace_register_breakpoint(addr = 0) if !bp !disabled. This fixes watchpoint-zeroaddr from ptrace-tests, see https://bugzilla.redhat.com/show_bug.cgi?id=660204. Reported-by: Jan Kratochvil jan.kratoch...@redhat.com Signed-off-by: Oleg Nesterov o...@redhat.com Acked-by: Frederic Weisbecker fweis...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] ptrace/x86: cleanup ptrace_set_debugreg()
On Thu, Apr 18, 2013 at 08:44:22PM +0200, Oleg Nesterov wrote: ptrace_set_debugreg() is trivial but looks horrible. Kill the unnecessary goto's and return's to cleanup the code. This matches ptrace_get_debugreg() which also needs the trivial whitespace cleanups. Signed-off-by: Oleg Nesterov o...@redhat.com Acked-by: Frederic Weisbecker fweis...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [GIT PULL] hwmon changes for 3.10
On Mon, 29 Apr 2013 07:57:27 -0700, Guenter Roeck wrote: New drivers for NCT6775, NCT6776, NCT6779, and LM95234. Added support for LTC2974, LTC3883, LM25056, TMP431, TMP432, ADT7310, and ADT7320 to existing drivers. Various code cleanups and minor improvements. Guenter Roeck (47): This starts (or continues) being very impressive... Thanks a lot Guenter for all your work! -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next] proc_fs.h: fix build error when PROC_FS is not enabled
From: Randy Dunlap rdun...@infradead.org
Fix build error when CONFIG_PROC_FS is not enabled:
(remove duplicated line)
include/linux/proc_fs.h:58:20: error: redefinition of 'proc_set_size'
include/linux/proc_fs.h:51:20: note: previous definition of 'proc_set_size' was
here
Signed-off-by: Randy Dunlap rdun...@infradead.org
---
include/linux/proc_fs.h |1 -
1 file changed, 1 deletion(-)
--- linux-next-20130429.orig/include/linux/proc_fs.h
+++ linux-next-20130429/include/linux/proc_fs.h
@@ -55,7 +55,6 @@ static inline void *proc_get_parent_data
static inline struct proc_dir_entry *proc_create_data(const char *name,
umode_t mode, struct proc_dir_entry *parent,
const struct file_operations *proc_fops, void *data) { return NULL; }
-static inline void proc_set_size(struct proc_dir_entry *de, loff_t size) {}
static inline void proc_remove(struct proc_dir_entry *de) {}
static inline void remove_proc_entry(const char *name, struct proc_dir_entry
*parent) {}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next] tty.h: fix build errors when PROC_FS is not enabled
From: Randy Dunlap rdun...@infradead.org
Fix build error when CONFIG_PROC_FS is not enabled:
include/linux/tty.h: In function 'proc_tty_register_driver':
include/linux/tty.h:698:52: error: parameter name omitted
include/linux/tty.h: In function 'proc_tty_unregister_driver':
include/linux/tty.h:699:54: error: parameter name omitted
Signed-off-by: Randy Dunlap rdun...@infradead.org
---
include/linux/tty.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20130429.orig/include/linux/tty.h
+++ linux-next-20130429/include/linux/tty.h
@@ -695,8 +695,8 @@ do {
\
extern void proc_tty_register_driver(struct tty_driver *);
extern void proc_tty_unregister_driver(struct tty_driver *);
#else
-static inline void proc_tty_register_driver(struct tty_driver *) {}
-static inline void proc_tty_unregister_driver(struct tty_driver *) {}
+static inline void proc_tty_register_driver(struct tty_driver *d) {}
+static inline void proc_tty_unregister_driver(struct tty_driver *d) {}
#endif
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 00/14] drivers: mailbox: framework creation
Hi Jassi, On 04/26/2013 11:51 PM, Jassi Brar wrote: Hi Suman, On 26 April 2013 03:59, Suman Anna s-a...@ti.com wrote: On 04/25/2013 12:20 AM, Jassi Brar wrote: I never said no-buffering and I never said buffering should be in controller drivers. In fact I don't remember ever objecting to how buffering is done in TI's framework. A controller could service only 1 request at a time so lets give it just 1 at a time. Let the API handle the complexity of buffering. Alright, guess this got lost in translation :). I interpreted based on the fact that you wanted to get rid of the size field from the mailbox_msg definition. Do you have a different mechanism in mind for the buffering compared to the present one? Sure, a very simple but efficient one. I had started on pseudo code implementation the day I first replied, but now I have real code with the PL320 controller and the Highbank client converted to the API. All that I say features in the new design. Polishing and documentation will take just a few hours more. You could see end to end what I have been talking about. OK, I didn't think of a no RTR interrupt-based controller. I would thing that such a controller is very rudimentary. I wonder if there are any controllers like this out there. One of my controllers is like that :) I hope it does have a status register atleast, and not the neither report nor sense RTR type. BTW, TI's RX mechanism too seems broken for common API. Receiving every few bytes via 'notify' mechanism is very inefficient. Imagine a platform with no shared memory between co-processors and the local wants to diagnose the remote by asking critical data at least KBs in size. No shared memory between co-processors and a relatively slow wire transport is a bad architecture design to begin with. IMHO it's only about private memory. Even if the controller transfers, say, 10bytes/interrupt there could always be a requirement to read some 1MB region of remote's private memory. And the same logic implies that our TX too should be as fast as possible - the remote might need its 1MB firmware over the link. So let us just try to serve all designs rather than evaluate them :) So when API has nothing to do with received packet and the controller has to get rid of it asap so as to be able to receive the next, IMHO there should be short-circuit from controller to client via the API. No delay, no buffering of RX. The current TI design is based on the fact that we can get multiple messages on a single interrupt due to the h/w fifo and the driver takes care of the bottom-half. Leaving it to the client is putting a lot of faith in the client and doesn't scale to multiple clients. The client would have to perform mostly the same as the driver is doing - so this goes back to the base discussion point that we have - which is the lack of support for atomic_context receivers in the current code. I perceive this as an attribute of the controller/mailbox device itself rather than the client. Sorry, I don't understand the concern about faith. If the controller h/w absolutely can not tell the remote(sender) of a received packet (as seems to be your case), its driver shouldn't even try to demux the received messages. The client driver must know which remotes could send it a message and how to discern them on the platform. Some 'server' RX client is needed here. No demuxing, deliver the message to the different clients. It is a protocol agreement between the clients on what the message means. Think of this scenario akin to shared interrupts. If the controller could indeed map received packet onto remotes, then ideally the controller driver should declare one (RX only) channel for each such remote and demux packets onto them. In either case, 'notify' mechanism is not necessary. The notify mechanism was the top-half on the interrupt handling. The faith part is coming from the fact that you expect all the clients to do the equivalent of the bottom-half (which would mean some duplication in the different clients), the OMAP scenario is such that all the different link interrupts (both rx tx) are mapped onto a single physical interrupt. I think this may not be applicable to your usecase, wherein you probably expect a response back before proceeding. I agree that all remote-ends will not be able to cope up intermixed requests, but isn't this again a controller architecture dependent? I think it's more about remote's protocol implementation than controller's architecture. Right, I meant functional integration. If tomorrow TI's remote firmware introduces a new set of critical commands that may arrive only in a particular sequence, you'll find yourself sharing a ride on our dinghy :) And Andy already explained where we come from. This is almost always true when your remote is for offloading some h/w operations. regards Suman -- To unsubscribe from this list: send the line
Re: linux-next: build failure after merge of the nfsd tree
On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. I was hoping I could consider the gss-proxy work committed at this point and pile any fixes on top, but... whatever works for you guys, I guess. --b. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] block: Add new generic block device naming interface
Hey, On Mon, Apr 29, 2013 at 04:56:38PM +0200, Hannes Reinecke wrote: grub requires you to re-implement _every_ device naming scheme which is present in the kernel. Are you saying that it's just a limitation in grub? And no, you cannot use the kernel itself as grub is run _prior_ to the kernel. I don't get this part. While booting, it's all about the number BIOS assigned to disks. After boot, we might as well just do mknod /dev/grub-device-N if grub is picky about the names it accept. What am I missing here? As there is no common naming scheme for block devices each and every block device driver has implemented it own. So grub need to re-implement each and every device naming for these drivers. Sure, I heard that a couple times but nobody really explained why that's the case. Is it something fundamental or is it just an implementation artifact? Can't it be fixed from grub side? If not, why? The approach from Stephen would solve that. At the cost of losing per-driver semi-stable enumeration. I don't think we want to lose that in favor of working around an implementation detail in grub. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: Disable slot presence detection around bus reset
On Fri, 2013-04-26 at 13:49 -0600, Bjorn Helgaas wrote: On Wed, Apr 24, 2013 at 3:33 PM, Alex Williamson alex.william...@redhat.com wrote: On Thu, 2013-02-14 at 20:53 -0700, Alex Williamson wrote: On Thu, 2013-02-14 at 16:47 -0700, Bjorn Helgaas wrote: On Thu, Feb 14, 2013 at 11:37 AM, Alex Williamson alex.william...@redhat.com wrote: A bus reset can trigger a presence detection change and result in a suprise hotplug. This is generally not what we want to happen when trying to reset a device. Disable the presence detection control on on bridges around bus reset. This is a really interesting situation, and I'm not quite ready to sign up to the idea that this is really a problem and that if it is, this is the way we want to fix it. What would happen if we *did* handle this as a hotplug event, with a removal followed by an add? The scheme where pci_reset_function() does pci_save_state(dev); pci_dev_reset(dev); pci_restore_state(dev); makes me nervous. We're saving and restoring some of PCI config space around the reset, but there's no guarantee that we're preserving *all* the important state in config space because I think devices can have non-architected device-specific things in config space that we don't know how to save/restore. Devices also have internal state not exposed via config space. That state is lost during the reset but can't be restored by pci_restore_state(). So it seems like pci_reset_function() is pretending to do something it can't really do reliably. If we make it so a reset is always handled as a remove+add, then we'll use a more generic path, and we'll get all the stuff you expect when initializing a new device -- resource assignment, IRQ setup, quirks, etc. Quirks in particular seem like something we want, but don't currently get with pci_reset_function(). Oh, and the disable presence detect approach below only works for things below a PCIe bridge with native hotplug, right? I wonder what happens if we reset devices below a bridge using SHPC or acpiphp. Triggering a remove+add is not useful for the way we use it today. The users I'm aware of are KVM device assignment and VFIO, where we trigger it in an attempt to get the device to a known state so that we have some hope of repeatability. In those scenarios the reset is initiated by the driver. The interface isn't meant to guarantee the device is returned to an identical state as it was before reset. If it did, why would we call it? We want to get to a state as near to power on, but still with config programming, as we can. I know you don't want the identical state before the reset. But it would be good if it were the same state as when the PCI core first called the .probe() method. Well, to clarify, we do want the known PCI state of the device to be the same before and after reset, otherwise we risk PCI-core getting out of sync with the actual device state. What we want cleared is all of the device internal state, so I think we have to assume that users of this interface want that to be cleared or know how to restore it. PCI-core can't sign-up for restoring state that it's unaware of. What we have right now is the reset path doing *part* of the device initialization but not all of it. The exception I can think of is that we don't apply any quirks in the reset path. Maybe running those would be enough to get to the same state as when the PCI core first gave it to the driver. But it's going to be hard to really confirm that and to keep these paths in sync in the future. And quirks are currently entitled to assume that they run *before* a driver gets its mitts on the device, so there could be issues there. There probably aren't any quirks for the devices you're interested in, so my concerns seem sort of academic. But it would still be nice if the scheme didn't depend on the absence of quirks. I don't quite understand the value of running quirks in the reset path. The device is owned by a driver across this reset, so why would we want to get it back to the pre-.probe() state? That might be something we would want for a full device re-init between drivers, but that seems additional to a reset interface (ie. reset re-init). Being driver directed, having the reset initiate a remove is pretty near the last thing we want. That limits the scope of calling it to only when the driver can readily release the device. If we have the device attached to a guest or userspace driver, that's potentially a lot of setup and teardown and effectively extending a surprise removal all the way up the stack. Obviously a bus reset is a big hammer and we do exhaust all the little hammers of flr and pm reset before we try it, but in this case, we know the device that's going away and with all likelihood, it's coming right back at the same location. If we take the
Re: [PATCH 6/6] ptrace: PTRACE_DETACH should do flush_ptrace_hw_breakpoint(child)
On Thu, Apr 18, 2013 at 08:44:25PM +0200, Oleg Nesterov wrote:
Change ptrace_detach() to call flush_ptrace_hw_breakpoint(child).
This frees the slots for non-ptrace PERF_TYPE_BREAKPOINT users, and
this ensures that the tracee won't be killed by SIGTRAP triggered by
the active breakpoints.
Test-case:
unsigned long encode_dr7(int drnum, int enable, unsigned int type,
unsigned int len)
{
unsigned long dr7;
dr7 = ((len | type) 0xf)
(DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE);
if (enable)
dr7 |= (DR_GLOBAL_ENABLE (drnum * DR_ENABLE_SIZE));
return dr7;
}
int write_dr(int pid, int dr, unsigned long val)
{
return ptrace(PTRACE_POKEUSER, pid,
offsetof (struct user, u_debugreg[dr]),
val);
}
void func(void)
{
}
int main(void)
{
int pid, stat;
unsigned long dr7;
pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
kill(getpid(), SIGHUP);
func();
return 0x13;
}
assert(pid == waitpid(-1, stat, 0));
assert(WSTOPSIG(stat) == SIGHUP);
assert(write_dr(pid, 0, (long)func) == 0);
dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1);
assert(write_dr(pid, 7, dr7) == 0);
assert(ptrace(PTRACE_DETACH, pid, 0,0) == 0);
assert(pid == waitpid(-1, stat, 0));
assert(stat == 0x1300);
return 0;
}
Before this patch the child is killed after PTRACE_DETACH.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/ptrace.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 776ab3b..33752d9 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -467,6 +467,7 @@ static int ptrace_detach(struct task_struct *child,
unsigned int data)
/* Architecture-specific hardware disable .. */
ptrace_disable(child);
clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
+ flush_ptrace_hw_breakpoint(child);
So I assume the tracee is still guaranteed to be stopped at that time, right?
Or already
killed? But it can't be concurrently killed given the patch you did that
prevented that?
I'm just asking to make sure we can't have two concurrent calls to
flush_ptrace_hw_breakpoint()
at the same time.
Also it seems to be a regression since we brought the breakpoint/perf
infrastructure. But
backporting this patch prior to ptrace: ensure arch_ptrace/ptrace_request can
never race with SIGKILL
might be racy. Hmm...
Thanks.
write_lock_irq(tasklist_lock);
/*
--
1.5.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-3.10 xenwatch: page allocation failure: order:7, mode:0x10c0d0
Monday, April 29, 2013, 5:46:23 PM, you wrote: On Wed, Apr 24, 2013 at 08:16:37PM +0200, Sander Eikelenboom wrote: Friday, April 19, 2013, 4:44:01 PM, you wrote: Hey Jens, Please in your spare time (if there is such a thing at a conference) pull this branch: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.10 .. snip.. Hi Konrad / Roger, I tried this pull on top of latest Linus latest linux-3.9 tree, but although it seems to boot and work fine at first, i seem to get trouble after running for about a day. Without this pull it runs fine for several days. .. snipp. [18496.013743] xenwatch: page allocation failure: order:7, mode:0x10c0d0 [18496.031948] Pid: 54, comm: xenwatch Not tainted 3.9.0-rc8-20130424-jens+ #1 [18496.049897] Call Trace: [18496.067674] [81100c51] warn_alloc_failed+0xf1/0x140 [18496.085453] [810b25ed] ? trace_hardirqs_on+0xd/0x10 [18496.102951] [810bdb24] ? on_each_cpu_mask+0x94/0xd0 [18496.120270] [811028af] __alloc_pages_nodemask+0x69f/0x960 [18496.137306] [8113a161] alloc_pages_current+0xb1/0x160 [18496.154051] [81100679] __get_free_pages+0x9/0x40 [18496.170579] [81142af4] __kmalloc+0x134/0x160 [18496.186921] [815832d0] xen_blkbk_probe+0x170/0x2f0 [18496.202963] [81474ce7] xenbus_dev_probe+0x77/0x130 [18496.218714] [8156a390] ? __driver_attach+0xa0/0xa0 [18496.234237] [8156a151] driver_probe_device+0x81/0x220 [18496.249605] [8198198c] ? klist_next+0x8c/0x110 [18496.264681] [8156a390] ? __driver_attach+0xa0/0xa0 [18496.279500] [8156a3db] __device_attach+0x4b/0x50 [18496.294138] [815684e8] bus_for_each_drv+0x68/0x90 [18496.308553] [8156a0c9] device_attach+0x89/0x90 [18496.322694] [81569258] bus_probe_device+0xa8/0xd0 [18496.336640] [81567c80] device_add+0x650/0x720 .. snip.. Jens, I don't know if you had pulled this git tree yet (I don't see it in your for-3.10/* branches). But if you have, Sander has found a bug (and Roger has a fix for it). Whether you would like to wait until v3.11 to pull it (and me sending the git pull around a month) is OK. Or pull it now and we will fix the bugs in the -rc's as they creep up. Roger's fix seems to work for me .. -- Sander Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WRITE SAME failed. Manually zeroing with 3w-xxxx driver
Florian == Florian Westphal f...@strlen.de writes: Florian After update to 3.8 dmesg is spammed with: kernel: [ Florian 280.272094] 3w-: scsi8: Unknown scsi opcode: 0x41 kernel: [ Florian 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: Interesting. It looks like the 3ware handles this at the driver level instead of passing the command through to the disk and letting it fail. That in turn means that the logic we have in place to disable WS when the disk does not support it does not get triggered. The driver should really fill out the sense buffer in that case. Could you please test the patch below? Florian This goes on and on. The second question is what it is that's issuing these zeroouts at boot? Which filesystem are you using? What's your DM/MD config? -- Martin K. Petersen Oracle Linux Engineering 3w-: Create sense buffer for unsupported commands Make the driver return appropriate sense data when an unsupported operation is queued. This will cause the SCSI layer to stop issuing the offending command. Reported-by: Florian Westphal f...@strlen.de CC: adam radford aradf...@gmail.com Signed-off-by: Martin K. Petersen martin.peter...@oracle.com diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c index 56662ae..b9276d1 100644 --- a/drivers/scsi/3w-.c +++ b/drivers/scsi/3w-.c @@ -216,6 +216,7 @@ #include scsi/scsi_host.h #include scsi/scsi_tcq.h #include scsi/scsi_cmnd.h +#include scsi/scsi_eh.h #include 3w-.h /* Globals */ @@ -2009,7 +2010,8 @@ static int tw_scsi_queue_lck(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_c printk(KERN_NOTICE 3w-: scsi%d: Unknown scsi opcode: 0x%x\n, tw_dev-host-host_no, *command); tw_dev-state[request_id] = TW_S_COMPLETED; tw_state_request_finish(tw_dev, request_id); - SCpnt-result = (DID_BAD_TARGET 16); + SCpnt-result = (DRIVER_SENSE 24) | SAM_STAT_CHECK_CONDITION; + scsi_build_sense_buffer(1, SCpnt-sense_buffer, ILLEGAL_REQUEST, 0x20, 0); done(SCpnt); retval = 0; } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-next-20130422] Bug in SLAB?
Tetsuo Handa wrote:
Glauber Costa wrote:
If I am right, the following (untested) patch should solve the problem.
This patch did not help;
kmalloc(8 * 1024 * 1024, GFP_KERNEL)
still causes both
include/linux/slab_def.h:136: warning: array subscript is above array bounds
and
BUG: unable to handle kernel NULL pointer dereference at 0058
IP: [c10b9d76] kmem_cache_alloc+0x26/0xb0
.
I copied this patch (which modifies static __always_inline void *kmalloc_node
(size_t size, gfp_t flags, int node)) to static __always_inline void *kmalloc
(size_t size, gfp_t flags), but it didn't help.
test cases
volatile unsigned int size = 0;
void *ptr = kmalloc(size, GFP_KERNEL);
printk(kmalloc(0)=%p\n, ptr);
kfree(ptr);
for (size = 1; size = 256 * 1024 * 1024; size *= 2) {
ptr = kmalloc(size, GFP_KERNEL);
printk(kmalloc(%u)=%p\n, size, ptr);
kfree(ptr);
}
test cases
kmalloc(0)=0010
kmalloc(1)=de7eb840
kmalloc(2)=de7eb840
kmalloc(4)=de7eb840
kmalloc(8)=de7eb840
kmalloc(16)=de7eb840
kmalloc(32)=de7eb840
kmalloc(64)=de28ae40
kmalloc(128)=de5ba140
kmalloc(256)=de69e180
kmalloc(512)=dea14600
kmalloc(1024)=de522400
kmalloc(2048)=de1e4000
kmalloc(4096)=de9b3000
kmalloc(8192)=de24a000
kmalloc(16384)=de444000
kmalloc(32768)=de9b8000
kmalloc(65536)=dea2
kmalloc(131072)=de98
kmalloc(262144)=deb0
kmalloc(524288)=dea8
kmalloc(1048576)=de80
kmalloc(2097152)=dde0
kmalloc(4194304)=d580
kmalloc(8388608)= (null)
kmalloc(16777216)= (null)
Got BUG() at 32 * 1024 * 1024 bytes.
Kernel BUG at c10b9c9b [verbose debug info unavailable]
invalid opcode: [#1] SMP
There still seems to be a bug in the non-constant case.
Christoph Lameter wrote:
What is MAX_ORDER on the architecture?
In my environment (x86_32), the constants are
MAX_ORDER=11 PAGE_SHIFT=12 KMALLOC_SHIFT_HIGH=22 KMALLOC_MAX_SIZE=4194304
I don't know if any, but on an architecture with PAGE_SHIFT + MAX_ORDER 26,
static void init_node_lock_keys(int q)
{
int i;
if (slab_state UP)
return;
for (i = 1; i PAGE_SHIFT + MAX_ORDER; i++) {
struct kmem_cache_node *n;
struct kmem_cache *cache = kmalloc_caches[i];
looks like out of bounds access due to
#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) = 25 ? \
(MAX_ORDER + PAGE_SHIFT - 1) : 25)
and
struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1];
.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/6] Android Binder IPC Fixes
Hi all, Any feedback or comments on this patch set? Thanks, Serban On 12/04/13 13:25, Serban Constantinescu wrote: Hi all, This set of patches will clean-up and fix some of the issues that arise with the current binder interface when moving to a 64bit kernel. All these changes will not affect the existing 32bit Android interface and are meant to stand as the base for the 64bit binder compat layer(kernel or userpsace). The patch set has been successfully tested with a 64bit Linux userspace and 64bit binder unit-tests. This patch set has been successfully tested on 32bit platforms(ARMv7 VExpress) and 64bit platforms(ARMv8 RTSM) running a 32bit Android userspace and an in kernel binder compat layer. Changes for v3: 1: Dropped the patch that was replacing uint32_t types with unsigned int 2: Dropped the patch fixing the IOCTL types(since it has been added to Greg's staging tree) 3: Split one patch into two: 'modify binder_write_read' and '64bit changes' 4: Modified BINDER_SET_MAX_THREADS ioctl definition accordint to Arve's review 5: Modified the binder command IOCTL declarations according to Arve's review Changes for v2: 1: 1/7: Modified the commit message according to Greg's feedback; 2: 3/7: Merged with the patch fixing the printk format specifiers. Serban Constantinescu (6): staging: android: binder: modify struct binder_write_read to use size_t staging: android: binder: fix binder interface for 64bit compat layer staging: android: binder: fix BINDER_SET_MAX_THREADS declaration staging: android: binder: fix BC_FREE_BUFFER ioctl declaration staging: android: binder: fix alignment issues staging: android: binder: replace types with portable ones drivers/staging/android/binder.c | 40 - drivers/staging/android/binder.h | 46 +++--- 2 files changed, 43 insertions(+), 43 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (include/linux/proc_fs.h: proc_net_mkdir)
On 04/29/13 02:17, Stephen Rothwell wrote: Hi all, Changes since 20130426: when CONFIG_PROC_FS is not enabled: CC init/main.o In file included from init/main.c:16:0: include/linux/proc_fs.h: In function 'proc_net_mkdir': include/linux/proc_fs.h:69:2: error: implicit declaration of function 'proc_mkdir_data' [-Werror=implicit-function-declaration] include/linux/proc_fs.h:69:2: warning: return makes pointer from integer without a cast [enabled by default] -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pinmux: Add TB10x pinmux driver
Hello Linus,
On Fri, Apr 26, 2013 at 09:47:16AM +0200, Linus Walleij wrote:
On Thu, Apr 18, 2013 at 11:03 AM, Christian Ruppert
christian.rupp...@abilis.com wrote:
We would like to avoid the use of Linux pin numbers in the device tree.
Customers are used to physical pin numbers and exposing the logical
Linux-internal numbering scheme through the device tree would generate
quite some confusion. There are two reasons why we cannot align the two:
- Not all products supported by these drivers have the same pin outs.
- GPIO ranges must be consecutive in the Linux pin numbering space
which is generally not the case in physical pin numbering.
If you are talking about the pin numbers really, i.e. the number we
put into
struct pinctrl_pin_desc {
unsigned number; - this
const char *name;
};
Then are you aware that this is a sparse number space?
I.e. you can choose whatever number you want. You do not have
to offset numbers from zero or anything like that. You just
need to make sure the numbers do not overlap (no two pins
have the same number).
So if this is what you want to achieve, just use the same number
as in your datasheet in the pin number - problem solved.
The problem is that we must support several products which are basically
different packaging options of the same chip (or simplified versions
thereof). Not all of those products will have the same number of pins
and as a consequence, data sheet pin numbering will also be different.
The port names are going to remain the same for all products, however.
Some of the ports are just not going to be physically available in some
or the products. Sorry if that wasn't clear from my previous mail.
This may lead to some offsetting in your driver etc, and some
struggle do to that. Inspect drivers/pinctrl/pinctrl-abx500.c
for example. Here the datasheet offsets the pins from 1 rather
than from zero, so Patrice had to struggle when cross-mapping
these numbers, but it can surely be done.
This driver seems to avoid many of our problems by integrating both GPIO
and pinctrl driver in the same module. It would not be very difficult to
integrate our separate TB10x GPiO and pinctrl drivers in the same way:
The cross-calling would disappear and the GPIO-base specification could
also easily be removed from device tree. We would still use the named
pingroups scheme in device tree instead of Linux internal pin numbering,
however.
Is this the way to go? I was a bit reluctant from doing this since I'm
not a big fan of huge mega-drivers. Maybe in this particular case such a
driver may be justified?
[...]
I am well aware of the problem but I haven't found any documentation,
core functions or examples which solve this. The most elegant way would
be some core functionality allowing to define GPIO ranges by directly
querying the pin data base (or to preregister GPIO ranges in the pin
controller to which GPIO drivers can then attach). Is there something
like this I have missed?
The current preferred pattern is to have the GPIO portions register
the ranges referring to the pin controller pin numbers.
This is because it enables us to only use controller-local
number spaces in both cases.
Agree. The only place in the TB10x drivers where non-local number space
is required is when preparing the GPIO range. I am wondering if some
generic interface in the framework could help us avoid the driver
cross-calls.
As a side note, the same argument does not apply to gpio-base, btw, for
two reasons:
- Our customer documentation does not talk about a global GPIO
numbering scheme. In our products, GPIOs are organised in banks and
there is no risk of confusion.
This is the local numbering used when registering ranges from
the GPIOlib side referred to above.
- The Linux-internal GPIO numbering is already exposed to customers
through the /sys/class/gpio interface.
Yeah this sucks but we have to live with it forever.
That said, if we solve the cross-calling issue I can still move it to
the pin data base in the next patch set since you are right that there
is no real reason to make it user-configurable through DT.
I don't understand this.
Actually, I am thinking of removing the need of specifying gpio-base in
the device tree and assigning a constant gpio-base to each functional
GPIO pin group in pinctrl-tb10x.c. This would also enforce some
coherence in the GPIO numbering between different product variants which
is probably a very good thing. Again, the issue here is that the pin
data base is in the pinctrl driver and the GPIO range is registered in
the GPIO driver but if I integrate the drivers into the same module with
a shared pin data base this issue will disappear.
Perhaps this abilis,simple-default thing is intended to represent some
specific default configuration? If so, I don't think that's the right
way to go. Also, the DT binding should be as
Re: [PATCH V5 1/5] workqueues: Introduce new flag WQ_POWER_EFFICIENT for power oriented workqueues
Hello, On Mon, Apr 29, 2013 at 12:06:28PM +0530, Viresh Kumar wrote: Whatever you wrote above confused me even more :) Heh heh, confumageddon This is what i had in my mind until now. Its not about per-cpu workqueue. Lets take example of system_wq. It doesn't have WQ_UNBOUND flag set. Now if we call queue_work_on() with cpu x and sytem_wq, then work will execute on cpu x. If we call queue_work() then it will queue the work on local cpu. Yeap, !WQ_UNBOUND workqueues == per-cpu workqueues. At this time local cpu may be busy or idle (Atleast according to scheduler). We don't want a idle cpu (From schedulers perspective) to be used for running this work's handler due to two reasons. - idle cpu may be in WFI or deeper idle states and so we can avoid waking it up. I have no idea what WFI is but the physical CPU is already awake at that time. It can't be idle - it's running queue_work(). It could be running in lower freq tho, which each code piece doesn't really have much control over. - We will make idle cpu look busy and so other kernel stuff may be scheduled on it now. But we could have kept it idle for a long time. Hmmm... yeah, about the same thing I wrote, it's not really about not waking up the CPU right now physically but avoiding forcing the scheduler scheduling a pinned task on an otherwise quiescent CPU. This effectively allows the scheduler to migrate such work items towards a CPU which the scheduler considers to be better (in power or whatever) leading to noticeable powersave. And what timer are you talking about? I am not talking about deffered work only, but normal work too. Deferred work item == timer + work item. I might have wrongly phrased some part of my patch (maybe used workqueue instead of work), will fix that up. I think it'd be necessary to distinguish the physical CPU being idle and the scheduler considers it to be idle (no task to schedule on it) and explain how increasing the latter can lead to powersave. As it's currently written, it seemingly, to me anyway, suggests that the proposed change somehow avoids waking up actually idle CPU, which isn't the case as queue_work() *always* schedules on the local CPU. The local CPU can't be idle by definition. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v3] PCI, ACPI, hotplug: Fix BUS_CHECK event handle on root bridge
Hi Yinghai,
Reviewed-by: Jiang Liu jiang@huawei.com
Thanks!
On 04/26/2013 09:46 AM, Yinghai Lu wrote:
Gavin found that acpiphp does not handle hotplug anymore even after
now we have acpiphp built-in preparing for v3.10.
Bjorn analyzed bootlog, he found that
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
ACPI: PCI Root Bridge [PCI0] (domain [bus 00-3e])
\_SB_.PCI0:_OSC invalid UUID
acpiphp: Slot [1] registered
acpiphp: Slot [1-1] registered
acpi root: \_SB_.PCI0 notify handler is installed
_handle_hotplug_event_root: Bus check notify on \_SB_.PCI0
_handle_hotplug_event_root: Bus check notify on \_SB_.PCI0
And that means:
So we should be using acpiphp, which you do have built in statically,
and it found a couple slots. And we did get two bus check notifies on
\_SB_.PCI0, so we *should* be re-enumerating PCI bus :00. But it
looks like we're handling this as a host bridge hotplug event instead
of a PCI device hotplug. My guess is that
handle_root_bridge_insertion() does nothing because the PCI0 ACPI
device already exists, though I would expect to see the acpi device
exists... in your dmesg log if this were the case.
Also according to Rafael and Bjorn, it is perfect fine that we
should enumerate bus by sending event to root bridge after hotadd
device to slots under that root bridge or children bridges.
It turns out that it is regression caused by
| commit 668192b678201d2fff27c6cc76bb003c1ec4a52a
| Author: Yinghai Lu ying...@kernel.org
| Date: Mon Jan 21 13:20:48 2013 -0800
|
|PCI: acpiphp: Move host bridge hotplug to pci_root.c
We should check slots when BUS_CHECK is sent to root bridge acpi handle.
Restore the old behavoir by calling acpi_check_bridge and check_sub_bridge
in acpiphp.
Jiang Liu acctually have simimar patch but it forgets calling
acpi_check_bridge() for system that have slots on root bus directly.
That is still valid, as in QEMU we still have that slots on bus 0 at
least. But my first version patch wrongly check if root bridge exists
before check_sub_bridge for children bridges.
-v2: Don't check bridge for acpi_walk_namespace with check_sub_bridges.
also put back bridge reference.
-v3: More changelog and etc.
Reported-by: Gavin Guo tuffki...@gmail.com
Tested-by: Gavin Guo tuffki...@gmail.com
Signed-off-by: Yinghai Lu ying...@kernel.org
---
drivers/acpi/pci_root.c|2 ++
drivers/pci/hotplug/acpiphp_glue.c | 14 ++
include/linux/pci-acpi.h |2 ++
3 files changed, 18 insertions(+)
Index: linux-2.6/drivers/acpi/pci_root.c
===
--- linux-2.6.orig/drivers/acpi/pci_root.c
+++ linux-2.6/drivers/acpi/pci_root.c
@@ -643,6 +643,8 @@ static void _handle_hotplug_event_root(s
(char *)buffer.pointer);
if (!root)
handle_root_bridge_insertion(handle);
+ else
+ acpiphp_check_host_bridge(handle);
break;
Index: linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-2.6.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
@@ -950,6 +950,20 @@ check_sub_bridges(acpi_handle handle, u3
return AE_OK ;
}
+void acpiphp_check_host_bridge(acpi_handle handle)
+{
+ struct acpiphp_bridge *bridge;
+
+ bridge = acpiphp_handle_to_bridge(handle);
+ if (bridge) {
+ acpiphp_check_bridge(bridge);
+ put_bridge(bridge);
+ }
+
+ acpi_walk_namespace(ACPI_TYPE_DEVICE, handle,
+ ACPI_UINT32_MAX, check_sub_bridges, NULL, NULL, NULL);
+}
+
static void _handle_hotplug_event_bridge(struct work_struct *work)
{
struct acpiphp_bridge *bridge;
Index: linux-2.6/include/linux/pci-acpi.h
===
--- linux-2.6.orig/include/linux/pci-acpi.h
+++ linux-2.6/include/linux/pci-acpi.h
@@ -60,11 +60,13 @@ static inline void acpi_pci_slot_remove(
void acpiphp_init(void);
void acpiphp_enumerate_slots(struct pci_bus *bus, acpi_handle handle);
void acpiphp_remove_slots(struct pci_bus *bus);
+void acpiphp_check_host_bridge(acpi_handle handle);
#else
static inline void acpiphp_init(void) { }
static inline void acpiphp_enumerate_slots(struct pci_bus *bus,
acpi_handle handle) { }
static inline void acpiphp_remove_slots(struct pci_bus *bus) { }
+static inline void acpiphp_check_host_bridge(acpi_handle handle) { }
#endif
#else/* CONFIG_ACPI */
--
To unsubscribe from this list: send the line unsubscribe linux-pci in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[GIT PATCH] char/misc patches for 3.10-rc1
The following changes since commit 41ef2d5678d83af030125550329b6ae8b74618fa: Linux 3.9-rc7 (2013-04-14 17:45:16 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/char-misc-3.10-rc1 for you to fetch changes up to 0e27263926699fcbbd574cff4dd6920007a50e8a: Tools: hv: Fix a checkpatch warning (2013-04-24 09:02:36 -0700) Char / Misc driver update for 3.10-rc1 Here's the big char / misc driver update for 3.10-rc1 A number of various driver updates, the majority being new functionality in the MEI driver subsystem (it's now a subsystem, it started out just a single driver), extcon updates, memory updates, hyper-v updates, and a bunch of other small stuff that doesn't fit in any other tree. All of these have been in linux-next for a while Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Alexandru Gheorghiu (1): drivers: char: Use PTR_RET function Ambresh K (1): memory: emif: setup LP settings on freq update Arnd Bergmann (1): misc: mark spear13xx-pcie-gadget as broken Bill Nottingham (1): mei: reseting - resetting Charles Keepax (1): extcon: arizona: Check we report a valid impedance Chen Gang (1): drivers/misc: beautify code: chip-lux_calib is u16 which will never more than APDS_RANGE Damian Hobson-Garcia (1): drivers: uio: Fix UIO device registration failure Dan Carpenter (1): applicom: use correct array offset David Brown (10): fix: Use EXPORT_SYMBOL_GPL ssbi: Fix exit mismatch in remove function ssbi: Allow compilation as a module SSBI: Convert SSBI to device tree ssbi: Comment the use of udelay() ssbi: Use regular init level ssbi: Remove extraneous logging SSBI: Remove MSM_ prefix from SSBI drivers MAINTAINERS: add ssbi mfd: pm8921: Disable driver until it gets fixed Fabio Estevam (1): w1: mxc_w1: Convert to devm_ioremap_resource() Fabio Porcedda (3): drivers: memory: use module_platform_driver_probe() drivers: char: use module_platform_driver_probe() parport: amiga: use module_platform_driver_probe() Greg Kroah-Hartman (8): Merge tag 'arizona-extcon-asoc' of git://git.kernel.org/.../broonie/misc into char-misc-next Merge branch 'char-misc-linus' into char-misc-next Merge v3.9-rc5 into char-misc-next Merge tag 'extcon-arizona-v3.10' of git://git.kernel.org/.../broonie/misc into char-misc-next Merge tag 'extcon-for-3.10' of git://git.kernel.org/.../chanwoo/extcon into char-misc-next Merge 3.9-rc7 into char-misc-next Revert scsi: pcmcia: nsp_cs: remove module init/exit function prototypes Revert drivers/scsi: use module_pcmcia_driver() in pcmcia drivers Grygorii Strashko (1): memory: emif: errata i743: Prohibit usage of Power-Down mode Guenter Roeck (1): misc/vmw_vmci: Add dependency on CONFIG_NET H Hartley Sweeten (12): pcmcia/ds.h: introduce helper for pcmcia_driver module boilerplate drivers/ata: use module_pcmcia_driver() in pcmcia drivers drivers/bluetooth: use module_pcmcia_driver() in pcmcia drivers drivers/isdn: use module_pcmcia_driver() in pcmcia drivers drivers/mmc: use module_pcmcia_driver() in pcmcia drivers drivers/parport: use module_pcmcia_driver() in pcmcia drivers drivers/scsi: use module_pcmcia_driver() in pcmcia drivers drivers/tty: use module_pcmcia_driver() in pcmcia drivers drivers/usb: use module_pcmcia_driver() in pcmcia drivers sound/pcmcia: use module_pcmcia_driver() in pcmcia drivers drivers/net: use module_pcmcia_driver() in pcmcia drivers scsi: pcmcia: nsp_cs: remove module init/exit function prototypes Hiroshi Doyu (1): memory: tegra30: Fix build error w/o PM Jean-Francois Dagenais (2): w1: ds2408: make value read-back check a Kconfig option w1: ds2408: use ARRAY_SIZE instead of hard-coded number Jingoo Han (10): misc: arm-charlcd: use module_platform_driver_probe() misc: atmel_pwm: use module_platform_driver_probe() misc: ep93xx_pwm: use module_platform_driver_probe() misc: bh1780gli: add CONFIG_PM_SLEEP to suspend/resume functions misc: bh1770glc: add CONFIG_PM_SLEEP to suspend/resume functions misc: apds990x: add CONFIG_PM_SLEEP to suspend/resume functions misc: at25: use spi_get_drvdata() and spi_set_drvdata() misc: eeprom_93xx46: use spi_get_drvdata() and spi_set_drvdata() misc: lattice-ecp3-config: use spi_get_drvdata() extcon: max8997: use dev_err() instead of pr_err() Jiri Kosina (1): dummy-irq: introduce a dummy IRQ handler driver K. Y. Srinivasan (14): Drivers: hv: balloon: Do not request completion notification Drivers: hv: balloon: Execute balloon inflation in a
[GIT PATCH] TTY/Serial patches for 3.10-rc1
The following changes since commit 41ef2d5678d83af030125550329b6ae8b74618fa: Linux 3.9-rc7 (2013-04-14 17:45:16 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.10-rc1 for you to fetch changes up to 45efcb2d32d35f6509543e477568842d8467035d: tty/serial/sirf: fix MODULE_DEVICE_TABLE (2013-04-23 10:43:18 -0700) TTY/Serial driver update for 3.10-rc1 Here's the big tty/serial driver merge request for 3.10-rc1 Once again, Jiri has a number of TTY driver fixes and cleanups, and Peter Hurley came through with a bunch of ldisc fixes that resolve a number of reported issues. There are some other serial driver cleanups as well. All of these have been in the linux-next tree for a while. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Alexander Shiyan (2): serial: sccnxp: Do not override device name serial: sccnxp: Replace pdata.init/exit with regulator API Arnd Bergmann (4): tty: serial/samsung: prepare for common clock API tty: serial/samsung: make register definitions global tty: serial/samsung: fix modular build tty/serial/sirf: fix MODULE_DEVICE_TABLE Changlong Xie (1): tty: tty_vhangup_session can be static Chanho Min (2): ARM: PL011: Add support for Rx DMA buffer polling. amba-pl011: fix build error if CONFIG_DMA_ENGINE is not enabled Emilio López (1): serial: 8250_dw: add support for clk api Federico Vaga (1): serial_core.c: add put_device() after device_find_child() Greg Kroah-Hartman (4): Merge 3.9-rc3 into tty-next Revert USB: quatech2: only write to the tty if the port is open. Merge 3.9-rc5 into tty-next Merge 3.9-rc7 intp tty-next Heikki Krogerus (13): serial: 8250: Allow probe drivers to ignore tx_loadsz serial: of_serial: Handle fifo-size property serial: of_serial: Handle auto-flow-control property serial: 8250_dma: TX cleanup serial: 8250_dma: Fix RX handling serial: 8250_dma: Use dmaengine helpers to get the slave channels serial: 8250_dma: Provide default slave configuration parameters serial: 8250_dw: Enable runtime PM serial: 8250_dw: Support clk framework also with ACPI serial: 8250_dw: Let ACPI code extract the DMA client info serial: 8250_dw: Set port capabilities based on CPR register serial: 8250_dw: Convert to devm_ioremap() serial: 8250_dw: Fix the stub for dw8250_probe_acpi() Jingoo Han (2): TTY: amiserial, use module_platform_driver_probe() serial: max3100: use spi_get_drvdata() and spi_set_drvdata() Jiri Slaby (20): TTY: jsm, remove superfluous check TTY: synclink, remove superfluous check TTY: do not warn about setting speed via SPD_* TTY: msm_smd_tty, clean up activate/shutdown TTY: add tty_port_tty_wakeup helper TTY: quatech2, remove unneeded is_open TTY: add tty_port_tty_hangup helper TTY: serial/bfin_uart, unbreak build with KGDB enabled TTY: serial/msm_serial_hs, remove unused tty TTY: cleanup tty-hw_stopped uses crisv10: use flags from tty_port crisv10: stop returning info from handle_ser_rx_interrupt crisv10: remove unused members crisv10: use close delays from tty_port crisv10: use *_wait from tty_port crisv10: use counts from tty_port TTY: serial, stop accessing potential NULLs CAIF: fix tty-warned build error TTY: rocket, fix compilation warning TTY: pty, fix compilation warning Johan Hovold (10): TTY: clean up port shutdown TTY: wake up processes last at hangup TTY: fix DTR being raised on hang up TTY: fix DTR not being dropped on hang up TTY: clean up port drain-delay handling TTY: fix close of uninitialised ports TTY: synclink: fix DTR being raised on hang up TTY: synclink_gt: fix DTR being raised on hang up TTY: synclinkmp: fix DTR being raised on hang up TTY: ircomm: fix DTR being raised on hang up Jongsung Kim (1): ARM: PL011: add support for extended FIFO-size of PL011-r1p5 Karthik Manamcheri (1): serial: 8250: Make SERIAL_8250_RUNTIME_UARTS work correctly Lars-Peter Clausen (4): tty: max3100: Use dev_pm_ops tty: max310x: Use dev_pm_ops tty: mrst_max3110: Use dev_pm_ops tty: ifx6x60: Remove unused suspend/resume callbacks Liang Li (1): serial: pch_uart: add console poll support Michael Spang (2): serial: samsung: Restore IRQ mask during noirq resume serial: samsung: Avoid waiting forever for TX ready Paul Bolle (2): serial: sh-sci: remove obsolete Kconfig macros serial: 8250: remove a few lines of dead code Peter Hurley (39): pty: Remove redundant itty reset tty: Refactor session leader SIGHUP
[GIT PATCH] Driver core patches for 3.10-rc1
The following changes since commit 41ef2d5678d83af030125550329b6ae8b74618fa: Linux 3.9-rc7 (2013-04-14 17:45:16 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ tags/driver-core-3.10-rc1 for you to fetch changes up to 0d1d392f011b284bb4af0411b2d36e5d04e0f058: Merge 3.9-rc7 into driver-core-next (2013-04-14 18:37:05 -0700) Driver core update for 3.10-rc1 Here's the merge request for the driver core tree for 3.10-rc1 It's pretty small, just a number of driver core and sysfs updates and fixes, all of which have been in linux-next for a while now. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Arnd Bergmann (1): sysfs: fix crash_notes_size build warning Fabio Porcedda (3): driver core: warn that platform_driver_probe can not use deferred probing driver core: platform.c: fix checkpatch errors and warnings driver core: platform_device.h: fix checkpatch errors and warnings Felipe Balbi (1): base: core: WARN() about bogus permissions on device attributes Greg Kroah-Hartman (6): Merge 3.9-rc4 into driver-core-next rtmutex-tester: fix mode of sysfs files Merge v3.9-rc5 into driver-core-next devtmpfs: add base.h include driver core: handle user namespaces properly with the uid/gid devtmpfs change Merge 3.9-rc7 into driver-core-next Kay Sievers (1): driver core: add uid and gid to devtmpfs Maarten Lankhorst (1): sysfs: use atomic_inc_unless_negative in sysfs_get_active Michal Hocko (1): device: separate all subsys mutexes Ming Lei (3): sysfs: fix use after free in case of concurrent read/write and readdir sysfs: check if one entry has been removed before freeing driver core: devtmpfs: fix compile failure with CONFIG_UIDGID_STRICT_TYPE_CHECKS Ulf Hansson (1): PM / Runtime: Idle devices asynchronously after probe|release Zhang Yanfei (2): sysfs: Add crash_notes_size to export percpu note size Documentation: Add ABI entry for crash_notes and crash_notes_size Documentation/ABI/testing/sysfs-devices-system-cpu | 12 +++ block/genhd.c | 3 +- drivers/base/bus.c | 8 ++--- drivers/base/core.c| 26 +++--- drivers/base/cpu.c | 14 drivers/base/dd.c | 6 ++-- drivers/base/devtmpfs.c| 28 +-- drivers/base/platform.c| 24 +++-- drivers/usb/core/usb.c | 3 +- fs/sysfs/dir.c | 41 +++--- include/linux/device.h | 19 +- include/linux/platform_device.h| 25 +++-- kernel/rtmutex-tester.c| 4 +-- 13 files changed, 135 insertions(+), 78 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Placing ext3 journal on mtd device
On Mon, Apr 29, 2013 at 6:08 PM, d.soumya...@iitg.ernet.in wrote: Hi, In Ext3 performance can be improved by placing journal on SSD. I am able to place ext3 journal on an external device. Can you please help me placing ext3 journal on mtd device. *very* bad idea. -- Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (kconfig)
On 04/29/13 02:17, Stephen Rothwell wrote: Hi all, Changes since 20130426: make ARCH=x86_64 O=X64 xconfig GEN /local/lnx/next/linux-next-20130429/X64/Makefile HOSTCXX scripts/kconfig/qconf.o In file included from scripts/kconfig/expr.h:15:0, from scripts/kconfig/lkc.h:9, from scripts/kconfig/qconf.cc:46: scripts/kconfig/list.h: In function 'void list_del(list_head*)': scripts/kconfig/list.h:128:16: error: invalid conversion from 'void*' to 'list_head*' [-fpermissive] scripts/kconfig/list.h:129:16: error: invalid conversion from 'void*' to 'list_head*' [-fpermissive] make[2]: *** [scripts/kconfig/qconf.o] Error 1 -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [GIT PULL] hwmon changes for 3.10
On Mon, Apr 29, 2013 at 06:01:44PM +0200, Jean Delvare wrote: On Mon, 29 Apr 2013 07:57:27 -0700, Guenter Roeck wrote: New drivers for NCT6775, NCT6776, NCT6779, and LM95234. Added support for LTC2974, LTC3883, LM25056, TMP431, TMP432, ADT7310, and ADT7320 to existing drivers. Various code cleanups and minor improvements. Guenter Roeck (47): This starts (or continues) being very impressive... Thanks a lot Guenter for all your work! My pleasure ... Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WRITE SAME failed. Manually zeroing with 3w-xxxx driver
Martin K. Petersen martin.peter...@oracle.com wrote: Florian After update to 3.8 dmesg is spammed with: kernel: [ Florian 280.272094] 3w-: scsi8: Unknown scsi opcode: 0x41 kernel: [ Florian 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: Interesting. It looks like the 3ware handles this at the driver level instead of passing the command through to the disk and letting it fail. That in turn means that the logic we have in place to disable WS when the disk does not support it does not get triggered. The driver should really fill out the sense buffer in that case. Could you please test the patch below? Sure, I'll report back tomorrow. Thanks for the quick response, Florian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. GSS-Proxy patches are 1 year old and we've been delayed once already to accomodate the containers work, maybe it's time for your patches to be rebased on gssproxy ones ? :-) Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (kvm)
On Mon, Apr 29, 2013 at 08:52:56AM -0700, Randy Dunlap wrote: On 04/29/13 02:17, Stephen Rothwell wrote: Hi all, Changes since 20130426: on x86_64: arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in this function) Oops, CONFIG_PCI is not enabled. Alex, can you look at this please. Before kvm: Allow build-time configuration of KVM device assignment commit KVM depended on PCI to be enabled. Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.9.0-rc8 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set CONFIG_KERNEL_XZ=y # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_FHANDLE=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ALWAYS_USE_PERSISTENT_CLOCK=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_NAMESPACES is not set CONFIG_UIDGID_CONVERTED=y CONFIG_UIDGID_STRICT_TYPE_CHECKS=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set CONFIG_RD_LZMA=y CONFIG_RD_XZ=y # CONFIG_RD_LZO is not set CONFIG_RD_LZ4=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HOTPLUG=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_PCSPKR_PLATFORM is not set
[RFC PATCH 0/3] Obey mark_page_accessed hint given by filesystems
Andrew Perepechko reported a problem whereby pages are being prematurely evicted as the mark_page_accessed() hint is ignored for pages that are currently on a pagevec -- http://www.spinics.net/lists/linux-ext4/msg37340.html . Alexey Lyahkov and Robin Dong have also reported problems recently that could be due to hot pages reaching the end of the inactive list too quickly and be reclaimed. Rather than addressing this on a per-filesystem basis, this series aims to fix the mark_page_accessed() interface by deferring what LRU a page is added to pagevec drain time and allowing mark_page_accessed() to call SetPageActive on a pagevec page. This opens some important races that I think should be harmless but needs double checking. The races and the VM_BUG_ON checks that are removed are all described in patch 2. This series received only very light testing but it did not immediately blow up and a debugging patch confirmed that pages are now getting added to the active file LRU list that would previously have been added to the inactive list. fs/cachefiles/rdwr.c| 30 ++-- fs/nfs/dir.c| 7 ++ include/linux/pagevec.h | 34 +-- mm/swap.c | 61 - mm/vmscan.c | 3 --- 5 files changed, 40 insertions(+), 95 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/5] watchdog: dw_wdt: use devm_clk_get()
On Mon, Apr 29, 2013 at 06:15:26PM +0900, Jingoo Han wrote: Use devm_clk_get() to make cleanup paths more simple. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Guenter Roeck li...@roeck-us.net --- drivers/watchdog/dw_wdt.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c index 2037669..2e70fd0 100644 --- a/drivers/watchdog/dw_wdt.c +++ b/drivers/watchdog/dw_wdt.c @@ -305,13 +305,13 @@ static int dw_wdt_drv_probe(struct platform_device *pdev) if (IS_ERR(dw_wdt.regs)) return PTR_ERR(dw_wdt.regs); - dw_wdt.clk = clk_get(pdev-dev, NULL); + dw_wdt.clk = devm_clk_get(pdev-dev, NULL); if (IS_ERR(dw_wdt.clk)) return PTR_ERR(dw_wdt.clk); ret = clk_enable(dw_wdt.clk); if (ret) - goto out_put_clk; + return ret; spin_lock_init(dw_wdt.lock); @@ -327,8 +327,6 @@ static int dw_wdt_drv_probe(struct platform_device *pdev) out_disable_clk: clk_disable(dw_wdt.clk); -out_put_clk: - clk_put(dw_wdt.clk); return ret; } @@ -338,7 +336,6 @@ static int dw_wdt_drv_remove(struct platform_device *pdev) misc_deregister(dw_wdt_miscdev); clk_disable(dw_wdt.clk); - clk_put(dw_wdt.clk); return 0; } -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-watchdog in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] mm: pagevec: Defer deciding what LRU to add a page to until pagevec drain time
mark_page_accessed cannot activate an inactive page that is located on
an inactive LRU pagevec. Hints from filesystems may be ignored as a
result. In preparation for fixing that problem, this patch removes the
per-LRU pagevecs and leaves just one pagevec. The final LRU the page is
added to is deferred until the pagevec is drained.
This means that fewer pagevecs are available and potentially there is
greater contention on the LRU lock. However, this only applies in the case
where there is an almost perfect mix of file, anon, active and inactive
pages being added to the LRU. In practice I expect that we are adding
stream of pages of a particular time and that the changes in contention
will barely be measurable.
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/swap.c | 37 +
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index 8a529a0..80fbc37 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -36,7 +36,7 @@
/* How many pages do we try to swap or page in/out together? */
int page_cluster;
-static DEFINE_PER_CPU(struct pagevec[NR_LRU_LISTS], lru_add_pvecs);
+static DEFINE_PER_CPU(struct pagevec, lru_add_pvec);
static DEFINE_PER_CPU(struct pagevec, lru_rotate_pvecs);
static DEFINE_PER_CPU(struct pagevec, lru_deactivate_pvecs);
@@ -456,13 +456,18 @@ EXPORT_SYMBOL(mark_page_accessed);
*/
void __lru_cache_add(struct page *page, enum lru_list lru)
{
- struct pagevec *pvec = get_cpu_var(lru_add_pvecs)[lru];
+ struct pagevec *pvec = get_cpu_var(lru_add_pvec);
+
+ if (is_active_lru(lru))
+ SetPageActive(page);
+ else
+ ClearPageActive(page);
page_cache_get(page);
if (!pagevec_space(pvec))
__pagevec_lru_add(pvec, lru);
pagevec_add(pvec, page);
- put_cpu_var(lru_add_pvecs);
+ put_cpu_var(lru_add_pvec);
}
EXPORT_SYMBOL(__lru_cache_add);
@@ -475,13 +480,11 @@ void lru_cache_add_lru(struct page *page, enum lru_list
lru)
{
if (PageActive(page)) {
VM_BUG_ON(PageUnevictable(page));
- ClearPageActive(page);
} else if (PageUnevictable(page)) {
VM_BUG_ON(PageActive(page));
- ClearPageUnevictable(page);
}
- VM_BUG_ON(PageLRU(page) || PageActive(page) || PageUnevictable(page));
+ VM_BUG_ON(PageLRU(page));
__lru_cache_add(page, lru);
}
@@ -582,15 +585,10 @@ static void lru_deactivate_fn(struct page *page, struct
lruvec *lruvec,
*/
void lru_add_drain_cpu(int cpu)
{
- struct pagevec *pvecs = per_cpu(lru_add_pvecs, cpu);
- struct pagevec *pvec;
- int lru;
+ struct pagevec *pvec = per_cpu(lru_add_pvec, cpu);
- for_each_lru(lru) {
- pvec = pvecs[lru - LRU_BASE];
- if (pagevec_count(pvec))
- __pagevec_lru_add(pvec, lru);
- }
+ if (pagevec_count(pvec))
+ __pagevec_lru_add(pvec, NR_LRU_LISTS);
pvec = per_cpu(lru_rotate_pvecs, cpu);
if (pagevec_count(pvec)) {
@@ -789,17 +787,16 @@ void lru_add_page_tail(struct page *page, struct page
*page_tail,
static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec,
void *arg)
{
- enum lru_list lru = (enum lru_list)arg;
- int file = is_file_lru(lru);
- int active = is_active_lru(lru);
+ enum lru_list requested_lru = (enum lru_list)arg;
+ int file = page_is_file_cache(page);
+ int active = PageActive(page);
+ enum lru_list lru = page_lru(page);
- VM_BUG_ON(PageActive(page));
+ WARN_ON_ONCE(requested_lru NR_LRU_LISTS requested_lru != lru);
VM_BUG_ON(PageUnevictable(page));
VM_BUG_ON(PageLRU(page));
SetPageLRU(page);
- if (active)
- SetPageActive(page);
add_page_to_lru_list(page, lruvec, lru);
update_page_reclaim_stat(lruvec, file, active);
}
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mm: Ensure that mark_page_accessed moves pages to the active list
If a page is on a pagevec then it is !PageLRU and mark_page_accessed()
may fail to move a page to the active list as expected. Now that the
LRU is selected at LRU drain time, mark pages PageActive if they are
on a pagevec so it gets moved to the correct list at LRU drain time.
Using a debugging patch it was found that for a simple git checkout
based workload that pages were never added to the active file list in
practice but with this patch applied they are.
before after
LRU Add Active File 0 757121
LRU Add Active Anon2678833 2633924
LRU Add Inactive File 8821711 8085543
LRU Add Inactive Anon 183 200
The question to consider is if this is universally safe. If the page
was isolated for reclaim and there is a parallel mark_page_accessed()
then vmscan.c will get upset when it finds an isolated PageActive page.
Similarly a potential race exists between a per-cpu drain on a pagevec
list and an activation on a remote CPU.
lru_add_drain_cpu
__pagevec_lru_add
lru = page_lru(page);
mark_page_accessed
if (PageLRU(page))
activate_page
else
SetPageActive
SetPageLRU(page);
add_page_to_lru_list(page, lruvec, lru);
A PageActive page is now added to the inactivate list.
While this looks strange, I think it is sufficiently harmless that additional
barriers to address the case is not justified. Unfortunately, while I never
witnessed it myself, these parallel updates potentially trigger defensive
DEBUG_VM checks on PageActive and hence they are removed by this patch.
Signed-off-by: Mel Gorman mgor...@suse.de
---
mm/swap.c | 18 --
mm/vmscan.c | 3 ---
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index 80fbc37..2a10d08 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -437,8 +437,17 @@ void activate_page(struct page *page)
void mark_page_accessed(struct page *page)
{
if (!PageActive(page) !PageUnevictable(page)
- PageReferenced(page) PageLRU(page)) {
- activate_page(page);
+ PageReferenced(page)) {
+
+ /*
+* If the page is on the LRU, promote immediately. Otherwise,
+* assume the page is on a pagevec, mark it active and it'll
+* be moved to the active LRU on the next drain
+*/
+ if (PageLRU(page))
+ activate_page(page);
+ else
+ SetPageActive(page);
ClearPageReferenced(page);
} else if (!PageReferenced(page)) {
SetPageReferenced(page);
@@ -478,11 +487,8 @@ EXPORT_SYMBOL(__lru_cache_add);
*/
void lru_cache_add_lru(struct page *page, enum lru_list lru)
{
- if (PageActive(page)) {
+ if (PageActive(page))
VM_BUG_ON(PageUnevictable(page));
- } else if (PageUnevictable(page)) {
- VM_BUG_ON(PageActive(page));
- }
VM_BUG_ON(PageLRU(page));
__lru_cache_add(page, lru);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 88c5fed..751b897 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -704,7 +704,6 @@ static unsigned long shrink_page_list(struct list_head
*page_list,
if (!trylock_page(page))
goto keep;
- VM_BUG_ON(PageActive(page));
VM_BUG_ON(page_zone(page) != zone);
sc-nr_scanned++;
@@ -935,7 +934,6 @@ activate_locked:
/* Not a candidate for swapping, so reclaim swap space. */
if (PageSwapCache(page) vm_swap_full())
try_to_free_swap(page);
- VM_BUG_ON(PageActive(page));
SetPageActive(page);
pgactivate++;
keep_locked:
@@ -3488,7 +3486,6 @@ void check_move_unevictable_pages(struct page **pages,
int nr_pages)
if (page_evictable(page)) {
enum lru_list lru = page_lru_base_type(page);
- VM_BUG_ON(PageActive(page));
ClearPageUnevictable(page);
del_page_from_lru_list(page, lruvec, LRU_UNEVICTABLE);
add_page_to_lru_list(page, lruvec, lru);
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 2/5] watchdog: imx2_wdt: use devm_clk_get()
On Mon, Apr 29, 2013 at 06:15:53PM +0900, Jingoo Han wrote:
Use devm_clk_get() to make cleanup paths more simple.
Signed-off-by: Jingoo Han jg1@samsung.com
Reviewed-by: Guenter Roeck li...@roeck-us.net
---
drivers/watchdog/imx2_wdt.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index ff90882..0c2b075 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -266,7 +266,7 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
if (IS_ERR(imx2_wdt.base))
return PTR_ERR(imx2_wdt.base);
- imx2_wdt.clk = clk_get(pdev-dev, NULL);
+ imx2_wdt.clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(imx2_wdt.clk)) {
dev_err(pdev-dev, can't get Watchdog clock\n);
return PTR_ERR(imx2_wdt.clk);
@@ -291,7 +291,6 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
fail:
imx2_wdt_miscdev.parent = NULL;
- clk_put(imx2_wdt.clk);
return ret;
}
@@ -304,8 +303,7 @@ static int __exit imx2_wdt_remove(struct platform_device
*pdev)
dev_crit(imx2_wdt_miscdev.parent,
Device removed: Expect reboot!\n);
- } else
- clk_put(imx2_wdt.clk);
+ }
imx2_wdt_miscdev.parent = NULL;
return 0;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-watchdog in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] mm: Remove lru parameter from __pagevec_lru_add and remove parts of pagevec API
Now that the LRU to add a page to is decided at LRU-add time, remove the
misleading lru parameter from __pagevec_lru_add. A consequence of this is
that the pagevec_lru_add_file, pagevec_lru_add_anon and similar helpers
are misleading as the caller no longer has direct control over what LRU
the page is added to. Unused helpers are removed by this patch and existing
users of pagevec_lru_add_file() are converted to use lru_cache_add_file()
directly and use the per-cpu pagevecs instead of creating their own pagevec.
Signed-off-by: Mel Gorman mgor...@suse.de
---
fs/cachefiles/rdwr.c| 30 +++---
fs/nfs/dir.c| 7 ++-
include/linux/pagevec.h | 34 +-
mm/swap.c | 12
4 files changed, 14 insertions(+), 69 deletions(-)
diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c
index 4809922..d24c13e 100644
--- a/fs/cachefiles/rdwr.c
+++ b/fs/cachefiles/rdwr.c
@@ -12,6 +12,7 @@
#include linux/mount.h
#include linux/slab.h
#include linux/file.h
+#include linux/swap.h
#include internal.h
/*
@@ -227,8 +228,7 @@ static void cachefiles_read_copier(struct fscache_operation
*_op)
*/
static int cachefiles_read_backing_file_one(struct cachefiles_object *object,
struct fscache_retrieval *op,
- struct page *netpage,
- struct pagevec *pagevec)
+ struct page *netpage)
{
struct cachefiles_one_read *monitor;
struct address_space *bmapping;
@@ -237,8 +237,6 @@ static int cachefiles_read_backing_file_one(struct
cachefiles_object *object,
_enter();
- pagevec_reinit(pagevec);
-
_debug(read back %p{%lu,%d},
netpage, netpage-index, page_count(netpage));
@@ -283,9 +281,7 @@ installed_new_backing_page:
backpage = newpage;
newpage = NULL;
- page_cache_get(backpage);
- pagevec_add(pagevec, backpage);
- __pagevec_lru_add_file(pagevec);
+ lru_cache_add_file(backpage);
read_backing_page:
ret = bmapping-a_ops-readpage(NULL, backpage);
@@ -452,8 +448,7 @@ int cachefiles_read_or_alloc_page(struct fscache_retrieval
*op,
if (block) {
/* submit the apparently valid page to the backing fs to be
* read from disk */
- ret = cachefiles_read_backing_file_one(object, op, page,
- pagevec);
+ ret = cachefiles_read_backing_file_one(object, op, page);
} else if (cachefiles_has_space(cache, 0, 1) == 0) {
/* there's space in the cache we can use */
fscache_mark_page_cached(op, page);
@@ -482,14 +477,11 @@ static int cachefiles_read_backing_file(struct
cachefiles_object *object,
{
struct cachefiles_one_read *monitor = NULL;
struct address_space *bmapping = object-backer-d_inode-i_mapping;
- struct pagevec lru_pvec;
struct page *newpage = NULL, *netpage, *_n, *backpage = NULL;
int ret = 0;
_enter();
- pagevec_init(lru_pvec, 0);
-
list_for_each_entry_safe(netpage, _n, list, lru) {
list_del(netpage-lru);
@@ -534,9 +526,7 @@ static int cachefiles_read_backing_file(struct
cachefiles_object *object,
backpage = newpage;
newpage = NULL;
- page_cache_get(backpage);
- if (!pagevec_add(lru_pvec, backpage))
- __pagevec_lru_add_file(lru_pvec);
+ lru_cache_add_file(backpage);
reread_backing_page:
ret = bmapping-a_ops-readpage(NULL, backpage);
@@ -559,9 +549,7 @@ static int cachefiles_read_backing_file(struct
cachefiles_object *object,
goto nomem;
}
- page_cache_get(netpage);
- if (!pagevec_add(lru_pvec, netpage))
- __pagevec_lru_add_file(lru_pvec);
+ lru_cache_add_file(netpage);
/* install a monitor */
page_cache_get(netpage);
@@ -643,9 +631,7 @@ static int cachefiles_read_backing_file(struct
cachefiles_object *object,
fscache_mark_page_cached(op, netpage);
- page_cache_get(netpage);
- if (!pagevec_add(lru_pvec, netpage))
- __pagevec_lru_add_file(lru_pvec);
+ lru_cache_add_file(netpage);
/* the netpage is unlocked and marked up to date here */
fscache_end_io(op, netpage, 0);
@@ -661,8 +647,6 @@ static int cachefiles_read_backing_file(struct
cachefiles_object *object,
out:
/* tidy up */
- pagevec_lru_add_file(lru_pvec);
-
if (newpage)
page_cache_release(newpage);
if (netpage)
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
Re: [PATCH RESEND 4/5] watchdog: shwdt: use devm_clk_get()
On Mon, Apr 29, 2013 at 06:16:33PM +0900, Jingoo Han wrote:
Use devm_clk_get() to make cleanup paths more simple.
Signed-off-by: Jingoo Han jg1@samsung.com
Reviewed-by: Guenter Roeck li...@roeck-us.net
---
drivers/watchdog/shwdt.c | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/watchdog/shwdt.c b/drivers/watchdog/shwdt.c
index 6185af2..ea2154b 100644
--- a/drivers/watchdog/shwdt.c
+++ b/drivers/watchdog/shwdt.c
@@ -241,7 +241,7 @@ static int sh_wdt_probe(struct platform_device *pdev)
wdt-dev = pdev-dev;
- wdt-clk = clk_get(pdev-dev, NULL);
+ wdt-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(wdt-clk)) {
/*
* Clock framework support is optional, continue on
@@ -251,10 +251,8 @@ static int sh_wdt_probe(struct platform_device *pdev)
}
wdt-base = devm_ioremap_resource(wdt-dev, res);
- if (IS_ERR(wdt-base)) {
- rc = PTR_ERR(wdt-base);
- goto err;
- }
+ if (IS_ERR(wdt-base))
+ return PTR_ERR(wdt-base);
watchdog_set_nowayout(sh_wdt_dev, nowayout);
watchdog_set_drvdata(sh_wdt_dev, wdt);
@@ -277,7 +275,7 @@ static int sh_wdt_probe(struct platform_device *pdev)
rc = watchdog_register_device(sh_wdt_dev);
if (unlikely(rc)) {
dev_err(pdev-dev, Can't register watchdog (err=%d)\n, rc);
- goto err;
+ return rc;
}
init_timer(wdt-timer);
@@ -292,11 +290,6 @@ static int sh_wdt_probe(struct platform_device *pdev)
pm_runtime_enable(pdev-dev);
return 0;
-
-err:
- clk_put(wdt-clk);
-
- return rc;
}
static int sh_wdt_remove(struct platform_device *pdev)
@@ -308,7 +301,6 @@ static int sh_wdt_remove(struct platform_device *pdev)
watchdog_unregister_device(sh_wdt_dev);
pm_runtime_disable(pdev-dev);
- clk_put(wdt-clk);
return 0;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-watchdog in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/2] watchdog: s3c2410_wdt: use dev_err()/dev_info() instead of pr_err()/pr_info()
On Mon, Apr 29, 2013 at 06:26:12PM +0900, Jingoo Han wrote: dev_err()/dev_info() are more preferred than pr_err()/pr_info(). Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Guenter Roeck li...@roeck-us.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. I've now pulled the rpcsec_gss changes into the nfs-for-next. The main reason why they were not pulled in earlier was due to uncertainty what to do about the increase in AUTH_GSS upcall timed out. syslog warnings. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Apr 29, 2013, at 12:29 PM, Simo Sorce s...@redhat.com wrote: On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. GSS-Proxy patches are 1 year old and we've been delayed once already to accomodate the containers work, maybe it's time for your patches to be rebased on gssproxy ones ? :-) Don't sweat it. IMO this is a simple merge problem, unlike the containers work. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 2/2] watchdog: s3c2410_wdt: convert s3c2410wdt to dev_pm_ops
On Mon, Apr 29, 2013 at 06:26:41PM +0900, Jingoo Han wrote: Instead of using legacy suspend/resume methods, using newer dev_pm_ops structure allows better control over power management. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Guenter Roeck li...@roeck-us.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 3/5] watchdog: pnx4008_wdt: use devm_clk_get()
On Mon, Apr 29, 2013 at 06:16:14PM +0900, Jingoo Han wrote: Use devm_clk_get() to make cleanup paths more simple. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Guenter Roeck li...@roeck-us.net --- drivers/watchdog/pnx4008_wdt.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c index a3684a3..b30bd43 100644 --- a/drivers/watchdog/pnx4008_wdt.c +++ b/drivers/watchdog/pnx4008_wdt.c @@ -159,13 +159,13 @@ static int pnx4008_wdt_probe(struct platform_device *pdev) if (IS_ERR(wdt_base)) return PTR_ERR(wdt_base); - wdt_clk = clk_get(pdev-dev, NULL); + wdt_clk = devm_clk_get(pdev-dev, NULL); if (IS_ERR(wdt_clk)) return PTR_ERR(wdt_clk); ret = clk_enable(wdt_clk); if (ret) - goto out; + return ret; pnx4008_wdd.bootstatus = (readl(WDTIM_RES(wdt_base)) WDOG_RESET) ? WDIOF_CARDRESET : 0; @@ -186,8 +186,6 @@ static int pnx4008_wdt_probe(struct platform_device *pdev) disable_clk: clk_disable(wdt_clk); -out: - clk_put(wdt_clk); return ret; } @@ -196,7 +194,6 @@ static int pnx4008_wdt_remove(struct platform_device *pdev) watchdog_unregister_device(pnx4008_wdd); clk_disable(wdt_clk); - clk_put(wdt_clk); return 0; } -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-watchdog in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Placing ext3 journal on mtd device
Hi, In Ext3 performance can be improved by placing journal on SSD. I am able to place ext3 journal on an external device. Can you please help me placing ext3 journal on mtd device. Thanks in Advance! Soumyajit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 2/2] watchdog: wm831x_wdt: use devm_gpio_request_one()
On Mon, Apr 29, 2013 at 06:31:20PM +0900, Jingoo Han wrote: Use devm_gpio_request_one() to make cleanup paths simpler. Also, GPIOF_DIR_OUT | GPIOF_INIT_LOW is replaced with GPIOF_OUT_INIT_LOW. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Guenter Roeck li...@roeck-us.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] exofs： don't increase urilen if krealloc() fails
On 04/28/2013 04:46 AM, Zhao Hongjiang wrote:
Without the patch, edp-urilen is increased before krealloc(). If krealloc()
fails,
edp-urilen is too high. Fix that by only updating edp-urilen if krealloc()
is successful.
Signed-off-by: Zhao Hongjiang zhaohongji...@huawei.com
---
fs/exofs/sys.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/exofs/sys.c b/fs/exofs/sys.c
index 1b4f2f9..79b0a85 100644
--- a/fs/exofs/sys.c
+++ b/fs/exofs/sys.c
@@ -82,11 +82,11 @@ static ssize_t uri_store(struct exofs_dev *edp, const
char *buf, size_t len)
{
uint8_t *new_uri;
- edp-urilen = strlen(buf) + 1;
- new_uri = krealloc(edp-uri, edp-urilen, GFP_KERNEL);
+ new_uri = krealloc(edp-uri, strlen(buf) + 1, GFP_KERNEL);
if (new_uri == NULL)
return -ENOMEM;
edp-uri = new_uri;
+ edp-urilen = strlen(buf) + 1;
strncpy(edp-uri, buf, edp-urilen);
return edp-urilen;
}
-- 1.7.1
Thank you, will apply
Boaz
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (staging/gdm72xx)
On 04/29/13 02:17, Stephen Rothwell wrote: Hi all, Changes since 20130426: on x86_64: when CONFIG_MMC=m and CONFIG_WIMAX_GDM72XX_SDIO=y (because it is boolean, not tristate): gdm_sdio.c:(.text+0x147093): undefined reference to `sdio_claim_host' gdm_sdio.c:(.text+0x1470a2): undefined reference to `sdio_release_irq' gdm_sdio.c:(.text+0x1470b1): undefined reference to `sdio_disable_func' gdm_sdio.c:(.text+0x1470c0): undefined reference to `sdio_release_host' gdm_sdio.c:(.text+0x14725a): undefined reference to `sdio_claim_host' gdm_sdio.c:(.text+0x14728f): undefined reference to `sdio_memcpy_toio' gdm_sdio.c:(.text+0x1472fa): undefined reference to `sdio_memcpy_toio' gdm_sdio.c:(.text+0x147342): undefined reference to `sdio_release_host' gdm_sdio.c:(.text+0x1477b6): undefined reference to `sdio_readb' gdm_sdio.c:(.text+0x1477db): undefined reference to `sdio_writeb' gdm_sdio.c:(.text+0x1477f5): undefined reference to `sdio_memcpy_fromio' gdm_sdio.c:(.text+0x14795b): undefined reference to `sdio_memcpy_fromio' gdm_sdio.c:(.text+0x1479ba): undefined reference to `sdio_memcpy_fromio' gdm_sdio.c:(.text+0x147ba8): undefined reference to `sdio_writeb' gdm_sdio.c:(.text+0x147f45): undefined reference to `sdio_claim_host' gdm_sdio.c:(.text+0x147f54): undefined reference to `sdio_enable_func' gdm_sdio.c:(.text+0x147f6a): undefined reference to `sdio_claim_irq' gdm_sdio.c:(.text+0x148343): undefined reference to `sdio_writeb' gdm_sdio.c:(.text+0x148352): undefined reference to `sdio_release_host' sdio_boot.c:(.text+0x148543): undefined reference to `sdio_memcpy_toio' sdio_boot.c:(.text+0x1485b7): undefined reference to `sdio_readb' sdio_boot.c:(.text+0x14862c): undefined reference to `sdio_memcpy_fromio' sdio_boot.c:(.text+0x14867d): undefined reference to `sdio_writeb' sdio_boot.c:(.text+0x14869a): undefined reference to `sdio_writeb' gdm_sdio.c:(.init.text+0xa6bc): undefined reference to `sdio_register_driver' gdm_sdio.c:(.exit.text+0x23b6): undefined reference to `sdio_unregister_driver' -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 1/5] workqueues: Introduce new flag WQ_POWER_EFFICIENT for power oriented workqueues
On 29 April 2013 21:49, Tejun Heo t...@kernel.org wrote: On Mon, Apr 29, 2013 at 12:06:28PM +0530, Viresh Kumar wrote: Yeap, !WQ_UNBOUND workqueues == per-cpu workqueues. Sigh!! You were talking about thread per cpu here... Sorry for missing it earlier :( At this time local cpu may be busy or idle (Atleast according to scheduler). We don't want a idle cpu (From schedulers perspective) to be used for running this work's handler due to two reasons. - idle cpu may be in WFI or deeper idle states and so we can avoid waking it up. I have no idea what WFI is but the physical CPU is already awake at that time. It can't be idle - it's running queue_work(). It could be running in lower freq tho, which each code piece doesn't really have much control over. Stupid point. WFI: Wait for interrupt (low power mode of cpu). - We will make idle cpu look busy and so other kernel stuff may be scheduled on it now. But we could have kept it idle for a long time. Hmmm... yeah, about the same thing I wrote, it's not really about not waking up the CPU right now physically but avoiding forcing the scheduler scheduling a pinned task on an otherwise quiescent CPU. This effectively allows the scheduler to migrate such work items towards a CPU which the scheduler considers to be better (in power or whatever) leading to noticeable powersave. Correct. And what timer are you talking about? I am not talking about deffered work only, but normal work too. Deferred work item == timer + work item. Ya, i knew that :) I might have wrongly phrased some part of my patch (maybe used workqueue instead of work), will fix that up. I think it'd be necessary to distinguish the physical CPU being idle and the scheduler considers it to be idle (no task to schedule on it) and explain how increasing the latter can lead to powersave. As it's currently written, it seemingly, to me anyway, suggests that the proposed change somehow avoids waking up actually idle CPU, which isn't the case as queue_work() *always* schedules on the local CPU. The local CPU can't be idle by definition. Yes you are correct. I will fix it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/2] watchdog: mtx1-wdt: use devm_gpio_request_one()
On Mon, Apr 29, 2013 at 06:30:43PM +0900, Jingoo Han wrote:
Use devm_gpio_request_one() to make cleanup paths simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
This patch also addresses the missing gpio_free in the probe error path
(if the call to misc_register() fails).
Reviewed-by: Guenter Roeck li...@roeck-us.net
---
drivers/watchdog/mtx-1_wdt.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/mtx-1_wdt.c b/drivers/watchdog/mtx-1_wdt.c
index 14dab6f..b434111 100644
--- a/drivers/watchdog/mtx-1_wdt.c
+++ b/drivers/watchdog/mtx-1_wdt.c
@@ -209,7 +209,7 @@ static int mtx1_wdt_probe(struct platform_device *pdev)
int ret;
mtx1_wdt_device.gpio = pdev-resource[0].start;
- ret = gpio_request_one(mtx1_wdt_device.gpio,
+ ret = devm_gpio_request_one(pdev-dev, mtx1_wdt_device.gpio,
GPIOF_OUT_INIT_HIGH, mtx1-wdt);
if (ret 0) {
dev_err(pdev-dev, failed to request gpio);
@@ -241,7 +241,6 @@ static int mtx1_wdt_remove(struct platform_device *pdev)
wait_for_completion(mtx1_wdt_device.stop);
}
- gpio_free(mtx1_wdt_device.gpio);
misc_deregister(mtx1_wdt_misc);
return 0;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-watchdog in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] ptrace: PTRACE_DETACH should do flush_ptrace_hw_breakpoint(child)
On 04/29, Frederic Weisbecker wrote: On Thu, Apr 18, 2013 at 08:44:25PM +0200, Oleg Nesterov wrote: index 776ab3b..33752d9 100644 --- a/kernel/ptrace.c +++ b/kernel/ptrace.c @@ -467,6 +467,7 @@ static int ptrace_detach(struct task_struct *child, unsigned int data) /* Architecture-specific hardware disable .. */ ptrace_disable(child); clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE); + flush_ptrace_hw_breakpoint(child); So I assume the tracee is still guaranteed to be stopped at that time, right? Yes. This is only called by PTRACE_DETACH which requires the stopped tracee, like all ptrace requests except PTRACE_KILL/INTERRUPT. And only one thread (the tracer) can do this. But it can't be concurrently killed given the patch you did that prevented that? No, it can't. To clarify, the tracee can't run even if killed. And just in case... If the tracer exits and does the implicit detach, ptrace_detach() (and thus flush_ptrace_hw_breakpoint()) is not called, that would be wrong exactly because we can race with the tracee. Also it seems to be a regression since we brought the breakpoint/perf infrastructure. No, I think this (minor) problem is very old... At least, when I look at 2.6.26 code I do not see anything which coould clear db regs on detach. backporting this patch prior to ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL might be racy. Yes, unlikely this is possible or even makes sense, the problem is minor. Btw. perhaps flush_ptrace_hw_breakpoint() should also clear the virtual registers like thread.debugreg7 ? Even without this patch, flush_ is also called exec. Oleg. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (kvm)
Il 29/04/2013 18:31, Gleb Natapov ha scritto: arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in this function) Oops, CONFIG_PCI is not enabled. Alex, can you look at this please. Before kvm: Allow build-time configuration of KVM device assignment commit KVM depended on PCI to be enabled. KVM_CAP_IOMMU probably should depend on device assignment. It doesn't really belong in KVM at all, and is only there for device assignment. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Mon, 2013-04-29 at 12:37 -0400, Chuck Lever wrote: On Apr 29, 2013, at 12:29 PM, Simo Sorce s...@redhat.com wrote: On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. GSS-Proxy patches are 1 year old and we've been delayed once already to accomodate the containers work, maybe it's time for your patches to be rebased on gssproxy ones ? :-) Don't sweat it. IMO this is a simple merge problem, unlike the containers work. Glad to hear that. Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 00/14] drivers: mailbox: framework creation
Hi On 29 April 2013 21:30, Suman Anna s-a...@ti.com wrote: Hi Jassi, On 04/26/2013 11:51 PM, Jassi Brar wrote: OK, I didn't think of a no RTR interrupt-based controller. I would thing that such a controller is very rudimentary. I wonder if there are any controllers like this out there. One of my controllers is like that :) I hope it does have a status register atleast, and not the neither report nor sense RTR type. Actually the status is not set by the h/w, but the remote's firmware implementation makes sure it sets a marker in the status register after accepting data. So with some other firmware, we might not even have the status read facility and the client will have to solely run the TX ticker. If the controller h/w absolutely can not tell the remote(sender) of a received packet (as seems to be your case), its driver shouldn't even try to demux the received messages. The client driver must know which remotes could send it a message and how to discern them on the platform. Some 'server' RX client is needed here. No demuxing, deliver the message to the different clients. It is a protocol agreement between the clients on what the message means. Think of this scenario akin to shared interrupts. Please re-read. That's what I said - No demuxing by the controller driver :) The notify mechanism was the top-half on the interrupt handling. The faith part is coming from the fact that you expect all the clients to do the equivalent of the bottom-half (which would mean some duplication in the different clients), the OMAP scenario is such that all the different link interrupts (both rx tx) are mapped onto a single physical interrupt. I think this may not be applicable to your usecase, wherein you probably expect a response back before proceeding. Simply put - the RX by notifier method will fail should a client is speed critical. The api might provide it optionally, but direct handover should be the default option. Btw, I did put up an almost tested version of an API implementing most of the features we agree upon http://www.spinics.net/lists/kernel/msg1523873.html http://www.spinics.net/lists/kernel/msg1523874.html cheers. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/3] mailbox: pl320: Introduce common API driver
On 04/27/2013 01:14 PM, jassisinghb...@gmail.com wrote:
From: Jassi Brar jaswinder.si...@linaro.org
Convert the PL320 controller driver to work with the common
mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
to work with thee API. Drop the obsoleted driver pl320-ipc.c
I think the conversion is fine based on your API, but you have
eliminated the stand-alone Rx interrupt code in the conversion. I
searched for if anybody is registering these rx atomic notifiers in 3.9,
and didn't find any. Is this expected to stay like this or is it some
future functionality not yet added, but getting removed in this patch.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/cpufreq/highbank-cpufreq.c | 22 +++-
drivers/mailbox/Makefile |2 +-
drivers/mailbox/{pl320-ipc.c = pl320.c} | 194
--
include/linux/pl320-ipc.h| 17 ---
4 files changed, 125 insertions(+), 110 deletions(-)
rename drivers/mailbox/{pl320-ipc.c = pl320.c} (51%)
delete mode 100644 include/linux/pl320-ipc.h
diff --git a/drivers/cpufreq/highbank-cpufreq.c
b/drivers/cpufreq/highbank-cpufreq.c
index 3118b87..5c057e0 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
#include linux/cpu.h
#include linux/err.h
#include linux/of.h
-#include linux/pl320-ipc.h
+#include linux/mailbox_client.h
#include linux/platform_device.h
#define HB_CPUFREQ_CHANGE_NOTE 0x8001
@@ -29,8 +29,26 @@
static int hb_voltage_change(unsigned int freq)
{
u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq / 100};
+ struct ipc_client cl;
+ int ret = -ETIMEDOUT;
+ void *chan;
- return pl320_ipc_transmit(msg);
+ cl.rxcb = NULL;
+ cl.txcb = NULL;
+ cl.tx_block = true;
+ cl.tx_tout = 1000; /* 1 sec */
+ cl.cntlr_data = NULL;
+ cl.knows_txdone = false;
+ cl.chan_name = pl320:A9_to_M3;
+
+ chan = ipc_request_channel(cl);
+
+ if (ipc_send_message(chan, (void *)msg))
+ ret = msg[1]; /* PL320 updates buffer with FIFO after ACK */
+
+ ipc_free_channel(chan);
I think I understand why you have done this, but do you really want to
request and free every time in the highbank cpufreq driver?
regards
Suman
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (kvm)
On Mon, 2013-04-29 at 19:31 +0300, Gleb Natapov wrote: On Mon, Apr 29, 2013 at 08:52:56AM -0700, Randy Dunlap wrote: On 04/29/13 02:17, Stephen Rothwell wrote: Hi all, Changes since 20130426: on x86_64: arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in this function) Oops, CONFIG_PCI is not enabled. Alex, can you look at this please. Before kvm: Allow build-time configuration of KVM device assignment commit KVM depended on PCI to be enabled. Yep, patch coming... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dove: fix Dove cpu type from V7 to PJ4
On Sat, Mar 23, 2013 at 04:06:51PM +0100, Sebastian Hesselbarth wrote: The CPU used in Marvell Dove SoCs is a PJ4 Sheeva core. Using CONFIG_CPU_PJ4 instead of CONFIG_CPU_V7 will also allow to enable iWMMXt extensions on Dove. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Cc: Russell King li...@arm.linux.org.uk Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Sebastian, It looks as though Russell's fix for IWMMXT made it in. Please place this patch in Russell's patch tracker. If you don't have the original thread, Andrew Lunn gave this an Acked-by. Now me as well: Acked-by: Jason Cooper ja...@lakedaemon.net thx, Jason. diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 2c3bdce..4fc9bca 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -556,7 +556,7 @@ config ARCH_IXP4XX config ARCH_DOVE bool Marvell Dove select ARCH_REQUIRE_GPIOLIB - select CPU_V7 + select CPU_PJ4 select GENERIC_CLOCKEVENTS select MIGHT_HAVE_PCI select PINCTRL -- 1.7.10.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mm: pagevec: Defer deciding what LRU to add a page to until pagevec drain time
On 04/29/2013 12:31 PM, Mel Gorman wrote: mark_page_accessed cannot activate an inactive page that is located on an inactive LRU pagevec. Hints from filesystems may be ignored as a result. In preparation for fixing that problem, this patch removes the per-LRU pagevecs and leaves just one pagevec. The final LRU the page is added to is deferred until the pagevec is drained. This means that fewer pagevecs are available and potentially there is greater contention on the LRU lock. However, this only applies in the case where there is an almost perfect mix of file, anon, active and inactive pages being added to the LRU. In practice I expect that we are adding stream of pages of a particular time and that the changes in contention will barely be measurable. Signed-off-by: Mel Gorman mgor...@suse.de Acked-by: Rik van Riel r...@redhat.com -- All rights reversed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: i2c: adv7343: add OF support
Hi,
On 04/26/2013 03:18 PM, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the adv7343 driver.
+++ b/Documentation/devicetree/bindings/media/i2c/adv7343.txt
@@ -0,0 +1,69 @@
+* Analog Devices adv7343 video encoder
+
+The ADV7343 are high speed, digital-to-analog video encoders in a 64-lead
LQFP
+package. Six high speed, 3.3 V, 11-bit video DACs provide support for
composite
+(CVBS), S-Video (Y-C), and component (YPrPb/RGB) analog outputs in standard
+definition (SD), enhanced definition (ED), or high definition (HD) video
+formats.
+
+The ADV7343 have a 24-bit pixel input port that can be configured in a
variety
+of ways. SD video formats are supported over an SDR interface, and ED/HD
video
+formats are supported over SDR and DDR interfaces. Pixel data can be supplied
+in either the YCrCb or RGB color spaces.
+
+Required Properties :
+- compatible: Must be ad,adv7343-encoder
As Laurent pointed out, -encoder is probably not necessary, since
there is nothing else in the ADV7343 chip than the video encoder ?
+Optional Properties :
+- ad-adv7343-power-mode-sleep-mode: on enable the current consumption is
+reduced to micro ampere level. All DACs
and
+the internal PLL circuit are disabled.
Why this needs to be specified in the device tree ? How will the hardware
be switched over to normal state if this property is set ?
Couldn't it be a default state by the driver ? And how is it related to
ad-adv7343-power-mode-dac-? properties ?
As pointed out earlier, vendor name in the property names should be separated
with commas, rather than dashes.
+- ad-adv7343-power-mode-pll-ctrl: PLL and oversampling control. This control
+ allows internal PLL 1 circuit to be powered
+ down and the oversampling to beswitched
off.
+- ad-adv7343-power-mode-dac-1: power on/off DAC 1.
+- ad-adv7343-power-mode-dac-2: power on/off DAC 2.
+- ad-adv7343-power-mode-dac-3: power on/off DAC 3.
+- ad-adv7343-power-mode-dac-4: power on/off DAC 4.
+- ad-adv7343-power-mode-dac-5: power on/off DAC 5.
+- ad-adv7343-power-mode-dac-6: power on/off DAC 6.
Is this somehow related to actual wiring on a PCB ? It's also not really
explicit what value corresponds to which state.
+- ad-adv7343-sd-config-dac-out-1: Configure SD DAC Output 1.
+- ad-adv7343-sd-config-dac-out-2: Configure SD DAC Output 2.
What are valid values and their meaning ?
+Example:
+
+i2c0@1c22000 {
+ adv7343@2a {
+ compatible = ad,adv7343-encoder;
+ reg = 0x2a;
+
+ port {
+ adv7343_1: endpoint {
+ /* Active high (Defaults to false) */
+ ad-adv7343-power-mode-sleep-mode;
+ /* Active high (Defaults to false) */
Isn't it obvious that if property is not listed it will default to false ?
+ ad-adv7343-power-mode-pll-ctrl;
+ /* Active high (Defaults to false) */
+ ad-adv7343-power-mode-dac-1;
+ /* Active high (Defaults to false) */
+ ad-adv7343-power-mode-dac-2;
+ /* Active high (Defaults to false) */
+ ad-adv7343-power-mode-dac-3;
+ /* Active high (Defaults to false) */
+ ad-adv7343-power-mode-dac-4;
+ /* Active high (Defaults to false) */
+ ad-adv7343-power-mode-dac-5;
+ /* Active high (Defaults to false) */
+ ad-adv7343-power-mode-dac-6;
+ /* Active high (Defaults to false) */
+ ad-adv7343-sd-config-dac-out-1;
+ /* Active high (Defaults to false) */
+ ad-adv7343-sd-config-dac-out-2 = 0;
+ };
+ };
+ };
+ ...
+};
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index 469e262..eb12d1a 100644
+static void adv7343_get_pdata(struct i2c_client *client,
+ struct adv7343_state *decoder)
+{
+ if (!client-dev.platform_data client-dev.of_node) {
+ struct device_node *np;
+ struct adv7343_platform_data *pdata;
+
+ np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL);
+ if (!np)
+ return;
+
+ pdata = devm_kzalloc(client-dev,
+ sizeof(struct
Re: linux-next: Tree for Apr 29 (sound/soc)
On 04/29/13 02:17, Stephen Rothwell wrote: Hi all, Changes since 20130426: on i386: CONFIG_I2C=m sound/built-in.o: In function `snd_soc_codec_set_cache_io': (.text+0x1ebe4): undefined reference to `regmap_init_i2c' make[1]: *** [vmlinux] Error 1 -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kvm: KVM_CAP_IOMMU only available with device assignment
Fix build with CONFIG_PCI unset by linking KVM_CAP_IOMMU to device assignment config option. It has no purpose otherwise. Signed-off-by: Alex Williamson alex.william...@redhat.com --- arch/ia64/kvm/kvm-ia64.c |2 ++ arch/x86/kvm/x86.c |2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c index dcc5607..5b2dc0d 100644 --- a/arch/ia64/kvm/kvm-ia64.c +++ b/arch/ia64/kvm/kvm-ia64.c @@ -204,9 +204,11 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_COALESCED_MMIO: r = KVM_COALESCED_MMIO_PAGE_OFFSET; break; +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT case KVM_CAP_IOMMU: r = iommu_present(pci_bus_type); break; +#endif default: r = 0; } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 73e443f..f83a8e0 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2543,9 +2543,11 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_PV_MMU:/* obsolete */ r = 0; break; +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT case KVM_CAP_IOMMU: r = iommu_present(pci_bus_type); break; +#endif case KVM_CAP_MCE: r = KVM_MAX_MCE_BANKS; break; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/3] mailbox: pl320: Introduce common API driver
On 29 April 2013 22:14, Suman Anna s-a...@ti.com wrote:
On 04/27/2013 01:14 PM, jassisinghb...@gmail.com wrote:
From: Jassi Brar jaswinder.si...@linaro.org
Convert the PL320 controller driver to work with the common
mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
to work with thee API. Drop the obsoleted driver pl320-ipc.c
I think the conversion is fine based on your API, but you have
eliminated the stand-alone Rx interrupt code in the conversion. I
searched for if anybody is registering these rx atomic notifiers in 3.9,
and didn't find any. Is this expected to stay like this or is it some
future functionality not yet added, but getting removed in this patch.
Yeah, probably only some out-of-tree code needed that but that made my
life simpler :)
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/cpufreq/highbank-cpufreq.c | 22 +++-
drivers/mailbox/Makefile |2 +-
drivers/mailbox/{pl320-ipc.c = pl320.c} | 194
--
include/linux/pl320-ipc.h| 17 ---
4 files changed, 125 insertions(+), 110 deletions(-)
rename drivers/mailbox/{pl320-ipc.c = pl320.c} (51%)
delete mode 100644 include/linux/pl320-ipc.h
diff --git a/drivers/cpufreq/highbank-cpufreq.c
b/drivers/cpufreq/highbank-cpufreq.c
index 3118b87..5c057e0 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
#include linux/cpu.h
#include linux/err.h
#include linux/of.h
-#include linux/pl320-ipc.h
+#include linux/mailbox_client.h
#include linux/platform_device.h
#define HB_CPUFREQ_CHANGE_NOTE 0x8001
@@ -29,8 +29,26 @@
static int hb_voltage_change(unsigned int freq)
{
u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq / 100};
+ struct ipc_client cl;
+ int ret = -ETIMEDOUT;
+ void *chan;
- return pl320_ipc_transmit(msg);
+ cl.rxcb = NULL;
+ cl.txcb = NULL;
+ cl.tx_block = true;
+ cl.tx_tout = 1000; /* 1 sec */
+ cl.cntlr_data = NULL;
+ cl.knows_txdone = false;
+ cl.chan_name = pl320:A9_to_M3;
+
+ chan = ipc_request_channel(cl);
+
+ if (ipc_send_message(chan, (void *)msg))
+ ret = msg[1]; /* PL320 updates buffer with FIFO after ACK */
+
+ ipc_free_channel(chan);
I think I understand why you have done this, but do you really want to
request and free every time in the highbank cpufreq driver?
Exactly my aim - make the API light enough to enable the client to
use-and-throw. And also because the channel are exclusively assigned,
acquire a channel only for as long as you need it.
cheers.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kvm: KVM_CAP_IOMMU only available with device assignment
On 04/29/13 09:54, Alex Williamson wrote: Fix build with CONFIG_PCI unset by linking KVM_CAP_IOMMU to device assignment config option. It has no purpose otherwise. Signed-off-by: Alex Williamson alex.william...@redhat.com Reported-by: Randy Dunlap rdun...@infradead.org Acked-by: Randy Dunlap rdun...@infradead.org Thanks. --- arch/ia64/kvm/kvm-ia64.c |2 ++ arch/x86/kvm/x86.c |2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c index dcc5607..5b2dc0d 100644 --- a/arch/ia64/kvm/kvm-ia64.c +++ b/arch/ia64/kvm/kvm-ia64.c @@ -204,9 +204,11 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_COALESCED_MMIO: r = KVM_COALESCED_MMIO_PAGE_OFFSET; break; +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT case KVM_CAP_IOMMU: r = iommu_present(pci_bus_type); break; +#endif default: r = 0; } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 73e443f..f83a8e0 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2543,9 +2543,11 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_PV_MMU:/* obsolete */ r = 0; break; +#ifdef CONFIG_KVM_DEVICE_ASSIGNMENT case KVM_CAP_IOMMU: r = iommu_present(pci_bus_type); break; +#endif case KVM_CAP_MCE: r = KVM_MAX_MCE_BANKS; break; -- -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (kvm)
On Mon, 2013-04-29 at 18:46 +0200, Paolo Bonzini wrote: Il 29/04/2013 18:31, Gleb Natapov ha scritto: arch/x86/kvm/x86.c: In function 'kvm_dev_ioctl_check_extension': arch/x86/kvm/x86.c:2547:22: error: 'pci_bus_type' undeclared (first use in this function) Oops, CONFIG_PCI is not enabled. Alex, can you look at this please. Before kvm: Allow build-time configuration of KVM device assignment commit KVM depended on PCI to be enabled. KVM_CAP_IOMMU probably should depend on device assignment. It doesn't really belong in KVM at all, and is only there for device assignment. Yep, exactly. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Apr 29, 2013, at 12:21 PM, Trond Myklebust trond.mykleb...@fys.uio.no wrote: On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. I've now pulled the rpcsec_gss changes into the nfs-for-next. The main reason why they were not pulled in earlier was due to uncertainty what to do about the increase in AUTH_GSS upcall timed out. syslog warnings. Trond's nfs-for-next now has the new rpcauth_get_gssinfo() and rpcauth_get_pseudoflavor() APIs, which are replacements for direct calls into the GSS mech switch. These APIs are a little more generic, and more robust in the face of unloaded GSS kernel modules. Instead of gss_mech_get_by_OID(), I suspect you want rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy code. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/3] mailbox: pl320: Introduce common API driver
On 04/29/2013 11:57 AM, Jassi Brar wrote:
On 29 April 2013 22:14, Suman Anna s-a...@ti.com wrote:
On 04/27/2013 01:14 PM, jassisinghb...@gmail.com wrote:
From: Jassi Brar jaswinder.si...@linaro.org
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/cpufreq/highbank-cpufreq.c | 22 +++-
drivers/mailbox/Makefile |2 +-
drivers/mailbox/{pl320-ipc.c = pl320.c} | 194
--
include/linux/pl320-ipc.h| 17 ---
4 files changed, 125 insertions(+), 110 deletions(-)
rename drivers/mailbox/{pl320-ipc.c = pl320.c} (51%)
delete mode 100644 include/linux/pl320-ipc.h
diff --git a/drivers/cpufreq/highbank-cpufreq.c
b/drivers/cpufreq/highbank-cpufreq.c
index 3118b87..5c057e0 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
#include linux/cpu.h
#include linux/err.h
#include linux/of.h
-#include linux/pl320-ipc.h
+#include linux/mailbox_client.h
#include linux/platform_device.h
#define HB_CPUFREQ_CHANGE_NOTE 0x8001
@@ -29,8 +29,26 @@
static int hb_voltage_change(unsigned int freq)
{
u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq /
100};
+ struct ipc_client cl;
+ int ret = -ETIMEDOUT;
+ void *chan;
- return pl320_ipc_transmit(msg);
+ cl.rxcb = NULL;
+ cl.txcb = NULL;
+ cl.tx_block = true;
+ cl.tx_tout = 1000; /* 1 sec */
+ cl.cntlr_data = NULL;
+ cl.knows_txdone = false;
+ cl.chan_name = pl320:A9_to_M3;
+
+ chan = ipc_request_channel(cl);
+
+ if (ipc_send_message(chan, (void *)msg))
+ ret = msg[1]; /* PL320 updates buffer with FIFO after ACK */
+
+ ipc_free_channel(chan);
I think I understand why you have done this, but do you really want to
request and free every time in the highbank cpufreq driver?
Exactly my aim - make the API light enough to enable the client to
use-and-throw. And also because the channel are exclusively assigned,
acquire a channel only for as long as you need it.
Do you have any numbers on the performance impact? Our cpufreq
transition throughput is bad enough without adding additional delays.
--Mark Langsdorf
Calxeda, Inc.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] process cputimer is moving faster than its corresponding clock
On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote: (4/27/13 12:40 AM), Olivier Langlois wrote: Forbids the cputimer to drift ahead of its process clock by blocking its update when a tick occurs while a autoreaping task is currently in do_exit() between the call to release_task() and its final call to schedule(). Any task stats update after having called release_task() will be lost because they are added to the global process stats located in the signal struct from release_task(). Ideally, you should postpone the release_task() call after the final context switch to get all the stats added but this is more complex to achieve. In other words, this is slowing down the cputimer so it keep the same pace than the process clock but in fact, what should be done is to speed up the process clock by adding the missing stats to it. Signed-off-by: Olivier Langlois oliv...@trillion01.com --- kernel/sched/fair.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7a33e59..52d7b10 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -708,7 +708,15 @@ static void update_curr(struct cfs_rq *cfs_rq) trace_sched_stat_runtime(curtask, delta_exec, curr-vruntime); cpuacct_charge(curtask, delta_exec); - account_group_exec_runtime(curtask, delta_exec); + /* +* Do not update the cputimer if the task is already released by +* release_task(). +* +* it would preferable to defer the autoreap release_task +* after the last context switch but harder to do. +*/ + if (likely(curtask-sighand)) + account_group_exec_runtime(curtask, delta_exec); } I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code. I have no seen any issue in this accounting. glibc launch a helper thread to receive timer signal and will also create a new thread upon signal reception when a timer is created with sigev_notify = SIGEV_THREAD; please see: glibc-2.17/nptl/sysdeps/unix/sysv/linux/timer_create.c glibc-2.17/nptl/sysdeps/unix/sysv/linux/timer_routines.c Greetings, Olivier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] mm: Ensure that mark_page_accessed moves pages to the active list
On 04/29/2013 12:31 PM, Mel Gorman wrote: A PageActive page is now added to the inactivate list. While this looks strange, I think it is sufficiently harmless that additional barriers to address the case is not justified. Unfortunately, while I never witnessed it myself, these parallel updates potentially trigger defensive DEBUG_VM checks on PageActive and hence they are removed by this patch. Could this not cause issues with __page_cache_release, called from munmap, exit, truncate, etc.? Could the eventual skewing of active vs inactive numbers break page reclaim heuristics? I wonder if we would need to move to a scheme where the PG_active bit is always the authoritive one, and we never pass an overriding lru parameter to __pagevec_lru_add. Would memory ordering between SetPageLRU and testing for PageLRU be enough to then prevent the statistics from going off? -- All rights reversed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (many build errors when PROC_FS is not set -- part 1)
On 04/29/13 02:17, Stephen Rothwell wrote: Hi all, Changes since 20130426: Many build errors happen when CONFIG_PROC_FS is not enabled. This is not new -- I also saw it about 2 weeks ago but did not analyze or report it. use of PDE_DATA() (from linux/proc_fs.h): drivers/net/wireless/hostap/hostap_ap.c:85:2: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] fs/afs/proc.c:193:2: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] drivers/block/pktcdvd.c:2598:2: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] fs/ext4/super.c:1809:2: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] fs/ext4/mballoc.c:2263:9: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] fs/jbd2/journal.c:982:2: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] net/sunrpc/cache.c:1465:9: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] drivers/char/ipmi/ipmi_si_intf.c:2842:2: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] drivers/gpu/drm/drm_proc.c:66:9: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] net/can/proc.c:381:2: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] net/can/bcm.c:229:2: error: implicit declaration of function 'PDE_DATA' [-Werror=implicit-function-declaration] Al, would it make sense to have a stub for PDE_DATA() in linux/proc_fs.h when CONFIG_PROC_FS is not enabled? -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] process cputimer is moving faster than its corresponding clock
On Mon, 2013-04-29 at 02:25 -0400, KOSAKI Motohiro wrote:
(4/27/13 12:41 AM), Olivier Langlois wrote:
Add thread group delta to cpu timer sample when computing a timer
expiration.
This is mandatory to make sure that the posix cpu timer does not fire too
soon relative to the process cpu clock which do include the task group
delta.
test case to validate the patch is glibc-2.17/rt/tst-cputimer1.c
First, I could reproduce this issue. thanks. Second, actually, this issue is
not
cause by race. This just occur by timer initialization mistake. I'll show you
the smallest fix.
Great!
@@ -697,7 +755,8 @@ static int posix_cpu_timer_set(struct k_itimer *timer,
int flags,
if (CPUCLOCK_PERTHREAD(timer-it_clock)) {
cpu_clock_sample(timer-it_clock, p, val);
} else {
- cpu_timer_sample_group(timer-it_clock, p, val);
+ cpu_timer_sample_group(timer-it_clock, p, val,
+ CPUTIMER_NEED_DELTA);
POSIX says,
http://pubs.opengroup.org/onlinepubs/7908799/xsh/timer_gettime.html
If the argument ovalue is not NULL, the function timer_settime() stores,
in the location referenced by ovalue, a value representing the previous
amount of time before the timer would have expired or zero if the timer
was disarmed, together with the previous timer reload value. The members
of ovalue are subject to the resolution of the timer, and they are the
same values that would be returned by a timer_gettime() call at that point
in time.
^^
but your posix_cpu_timer_set() and posix_cpu_timer_get() are not consistent.
I'm worry
about this.
}
if (old) {
@@ -845,7 +904,8 @@ static void posix_cpu_timer_get(struct k_itimer *timer,
struct itimerspec *itp)
read_unlock(tasklist_lock);
goto dead;
} else {
- cpu_timer_sample_group(timer-it_clock, p, now);
+ cpu_timer_sample_group(timer-it_clock, p, now,
+ CPUTIMER_NO_DELTA);
clear_dead = (unlikely(p-exit_state)
thread_group_empty(p));
}
--
I have tried to minimize rq locks contention to strict minimum. If to
remain POSIX compliant, it is required to also use CPUTIMER_NEED_DELTA,
so be it. I have no objections.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: i2c: tvp514x: add OF support
Hi Laurent,
Thanks for the review.
On Mon, Apr 29, 2013 at 7:27 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Prabhakar,
Thank you for the patch. Please see below for a couple of comments. Most of
them apply to your adv7343 patch as well.
alright I'll fix for that patch as well.
On Friday 26 April 2013 16:53:50 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the tvp514x driver.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
---
RFC v1: https://patchwork.kernel.org/patch/2030061/
RFC v2: https://patchwork.kernel.org/patch/2061811/
Changes for current version from RFC v2:
1: Fixed review comments pointed by Sylwester.
.../devicetree/bindings/media/i2c/tvp514x.txt | 38 +++
drivers/media/i2c/tvp514x.c| 67 +++--
2 files changed, 98 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp514x.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt new file mode
100644
index 000..618640a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
@@ -0,0 +1,38 @@
+* Texas Instruments TVP514x video decoder
+
+The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
+digital video decoder that digitizes and decodes all popular baseband
+analog video formats into digital video component. The tvp514x decoder
+supports analog-to-digital (A/D) conversion of component RGB and YPbPr
+signals as well as A/D conversion and decoding of NTSC, PAL and SECAM
+composite and S-video into component YCbCr.
+
+Required Properties :
+- compatible: Must be ti,tvp514x-decoder
According to the code below, it must be one of
ti,tvp5146-decoder
ti,tvp5146m2-decoder
ti,tvp5147-decoder
ti,tvp5147m1-decoder
Couldn't you remove -decoder ?
yeah I missed to mention other compatible options, 'll remove
-decoder as well.
You should add a reference to the V4L2 DT bindings documentation to explain
what the port and endpoint nodes are for.
OK
+- hsync-active: HSYNC Polarity configuration for current interface.
+- vsync-active: VSYNC Polarity configuration for current interface.
+- pclk-sample: Clock polarity of the current interface.
s/current interface/endpoint/ ?
yeah endpoint.
+Example:
+
+i2c0@1c22000 {
+ ...
+ ...
+
+ tvp514x@5c {
+ compatible = ti,tvp514x-decoder;
+ reg = 0x5c;
+
+ port {
+ tvp514x_1: endpoint {
+ /* Active high (Defaults to 0) */
+ hsync-active = 1;
+ /* Active high (Defaults to 0) */
+ vsync-active = 1;
+ /* Active low (Defaults to 0) */
+ pclk-sample = 0;
+ };
+ };
+ };
+ ...
+};
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 887bd93..d37b85e 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -35,7 +35,9 @@
#include linux/videodev2.h
#include linux/module.h
#include linux/v4l2-mediabus.h
+#include linux/of_device.h
+#include media/v4l2-of.h
#include media/v4l2-async.h
#include media/v4l2-device.h
#include media/v4l2-common.h
@@ -1056,6 +1058,58 @@ static struct tvp514x_decoder tvp514x_dev = {
};
+#if defined(CONFIG_OF)
+static const struct of_device_id tvp514x_of_match[] = {
+ {.compatible = ti,tvp5146-decoder, },
+ {.compatible = ti,tvp5146m2-decoder, },
+ {.compatible = ti,tvp5147-decoder, },
+ {.compatible = ti,tvp5147m1-decoder, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tvp514x_of_match);
+
+static void tvp514x_get_pdata(struct i2c_client *client,
+ struct tvp514x_decoder *decoder)
+{
+ if (!client-dev.platform_data client-dev.of_node) {
+ struct device_node *endpoint;
+
+ endpoint = v4l2_of_get_next_endpoint(client-dev.of_node,
NULL);
+ if (endpoint) {
+ struct tvp514x_platform_data *pdata;
+ struct v4l2_of_endpoint bus_cfg;
+ unsigned int flags;
+
+
[GIT PULL] clk: changes for 3.10
The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.linaro.org/people/mturquette/linux.git tags/clk-for-linus-3.10 for you to fetch changes up to 1e435256d625c203660f0105f1155cd2af283051: clk: add clk_ignore_unused option to keep boot clocks on (2013-04-27 23:03:43 -0700) The common clock framework changes for 3.10 include many fixes for existing platforms, as well as adoption of the framework by new platforms and devices. Some long-needed fixes to the core framework are here as well as new features such as improved initialization of clocks from DT as well as framework reentrancy for nested clock operations. Axel Lin (1): clk: mvebu: Fix valid value range checking for cpu_freq_select Eduardo Valentin (1): documentation: clk: fix couple of misspelling Emilio López (7): clk: arm: sunxi: Add a new clock driver for sunxi SOCs arm: sunxi: Add useful information about sunxi clocks clk: sunxi: rename compatible strings clk: sunxi: Add support for AXI, AHB, APB0 and APB1 gates clk: sunxi: drop CLK_IGNORE_UNUSED clk: sunxi: drop an unnecesary kmalloc clk: sunxi: Unify oscillator clock Fabio Estevam (2): clk: mxs: Fix sparse warnings ARM: imx: adapt clk_busy_mux to new clk_mux struct Gregory CLEMENT (1): clk: add device tree fixed-factor-clock binding support James Hogan (1): clk: fix clk_mux::flags kerneldoc Jean-Francois Moine (1): clk: mvebu: Use common of_clk_init() function Lars-Peter Clausen (1): clk: Add axi-clkgen driver Maxime Coquelin (1): clk: ux500: Fix prcmu clocks registration Michal Simek (1): clk: zynq: Add missing zynq clk header Mike Turquette (5): clk: abstract locking out into helper functions clk: allow reentrant calls into the clk framework clk: composite: rename 'div' references to 'rate' clk: composite: allow fixed rates fixed dividers clk: ux500: fix mismatched types Olof Johansson (1): clk: add clk_ignore_unused option to keep boot clocks on Pawel Moll (1): clk: vexpress: Add separate SP810 driver Peter De Schrijver (1): clk: add table lookup to mux Prashant Gaikwad (1): clk: Add composite clock type Sachin Kamat (1): clk: Fix incorrect return type in clk.c Sebastian Hesselbarth (3): clk: add si5351 i2c common clock driver clk: export __clk_get_flags for modular clock providers clk: si5351: make clk-si5351 depend on CONFIG_OF Soren Brinkmann (2): clk: divider: Introduce CLK_DIVIDER_ALLOW_ZERO flag clk: Properly handle notifier return values Tony Prisk (1): clk: vt8500: Missing breaks in vtwm_pll_round_rate/_set_rate. Ulf Hansson (9): clk: Introduce optional is_prepared callback clk: Unprepare the unused prepared slow clocks at late init clk: Introduce optional unprepare_unused callback clk: ux500: Support is_prepared callback for clk-prcmu clk: Restructure code for __clk_reparent clk: Fixup errorhandling for clk_set_parent clk: Fixup locking issues for clk_set_parent clk: ux500: Add support for sysctrl clocks clk: ux500: abx500: Define clock tree for ab850x Vipul Kumar Samar (1): clk:SPEAr1340: Correct parent clock configuration Wei Yongjun (1): clk: prima2: fix return value check in sirfsoc_of_clk_init() Documentation/arm/sunxi/clocks.txt | 56 + Documentation/clk.txt | 15 +- .../devicetree/bindings/clock/axi-clkgen.txt | 22 + .../bindings/clock/fixed-factor-clock.txt | 24 + .../devicetree/bindings/clock/silabs,si5351.txt| 114 ++ Documentation/devicetree/bindings/clock/sunxi.txt | 151 ++ .../devicetree/bindings/vendor-prefixes.txt|1 + Documentation/kernel-parameters.txt|8 + arch/arm/mach-imx/clk-busy.c |2 +- arch/arm/mach-vexpress/v2m.c |8 +- drivers/clk/Kconfig| 18 + drivers/clk/Makefile |4 + drivers/clk/clk-axi-clkgen.c | 331 + drivers/clk/clk-composite.c| 210 +++ drivers/clk/clk-divider.c |5 +- drivers/clk/clk-fixed-factor.c | 36 + drivers/clk/clk-mux.c | 50 +- drivers/clk/clk-prima2.c |2 +- drivers/clk/clk-si5351.c | 1510 drivers/clk/clk-si5351.h | 155 ++ drivers/clk/clk-vt8500.c |2 + drivers/clk/clk-zynq.c |
Re: [PATCH v2 05/21] atm: he: use msleep instead of large udelay constants
From: Arnd Bergmann a...@arndb.de Date: Mon, 29 Apr 2013 15:13:26 +0200 From a0ddf082821b064cc2d6a9bb90861f9b81a559a5 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann a...@arndb.de Date: Thu, 14 Mar 2013 15:21:36 +0100 Subject: [PATCH] atm: he: use mdelay instead of large udelay constants ARM cannot handle udelay for more than 2 miliseconds, and it is rather bad style to block the cpu for 16ms anyway, so let's use msleep instead. Signed-off-by: Arnd Bergmann a...@arndb.de Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/3] mailbox: pl320: Introduce common API driver
On 29 April 2013 22:36, Mark Langsdorf mark.langsd...@calxeda.com wrote:
On 04/29/2013 11:57 AM, Jassi Brar wrote:
On 29 April 2013 22:14, Suman Anna s-a...@ti.com wrote:
On 04/27/2013 01:14 PM, jassisinghb...@gmail.com wrote:
From: Jassi Brar jaswinder.si...@linaro.org
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/cpufreq/highbank-cpufreq.c | 22 +++-
drivers/mailbox/Makefile |2 +-
drivers/mailbox/{pl320-ipc.c = pl320.c} | 194
--
include/linux/pl320-ipc.h| 17 ---
4 files changed, 125 insertions(+), 110 deletions(-)
rename drivers/mailbox/{pl320-ipc.c = pl320.c} (51%)
delete mode 100644 include/linux/pl320-ipc.h
diff --git a/drivers/cpufreq/highbank-cpufreq.c
b/drivers/cpufreq/highbank-cpufreq.c
index 3118b87..5c057e0 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
#include linux/cpu.h
#include linux/err.h
#include linux/of.h
-#include linux/pl320-ipc.h
+#include linux/mailbox_client.h
#include linux/platform_device.h
#define HB_CPUFREQ_CHANGE_NOTE 0x8001
@@ -29,8 +29,26 @@
static int hb_voltage_change(unsigned int freq)
{
u32 msg[HB_CPUFREQ_IPC_LEN] = {HB_CPUFREQ_CHANGE_NOTE, freq /
100};
+ struct ipc_client cl;
+ int ret = -ETIMEDOUT;
+ void *chan;
- return pl320_ipc_transmit(msg);
+ cl.rxcb = NULL;
+ cl.txcb = NULL;
+ cl.tx_block = true;
+ cl.tx_tout = 1000; /* 1 sec */
+ cl.cntlr_data = NULL;
+ cl.knows_txdone = false;
+ cl.chan_name = pl320:A9_to_M3;
+
+ chan = ipc_request_channel(cl);
+
+ if (ipc_send_message(chan, (void *)msg))
+ ret = msg[1]; /* PL320 updates buffer with FIFO after ACK */
+
+ ipc_free_channel(chan);
I think I understand why you have done this, but do you really want to
request and free every time in the highbank cpufreq driver?
Exactly my aim - make the API light enough to enable the client to
use-and-throw. And also because the channel are exclusively assigned,
acquire a channel only for as long as you need it.
Do you have any numbers on the performance impact? Our cpufreq
transition throughput is bad enough without adding additional delays.
Sorry no numbers.
However if you look closely you'll find for your usecase the message
directly reaches the controller and the reply from remote is directly
handed to your client driver. And since there is no context for
channel on your platform channel request/free shouldn't fail either
(or you could keep the channel allocated for the lifetime of the
client driver). So I would not expect any longer delays than the
original way.
Compared with TI's framework of RX-via-notifier you should be better
off with this API, imho.
cheers.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] process cputimer is moving faster than its corresponding clock
On Mon, 2013-04-29 at 02:45 +0200, Frederic Weisbecker wrote: 2013/4/27 Olivier Langlois oliv...@trillion01.com: Forbids the cputimer to drift ahead of its process clock by blocking its update when a tick occurs while a autoreaping task is currently in do_exit() between the call to release_task() and its final call to schedule(). Any task stats update after having called release_task() will be lost because they are added to the global process stats located in the signal struct from release_task(). Ideally, you should postpone the release_task() call after the final context switch to get all the stats added but this is more complex to achieve. In other words, this is slowing down the cputimer so it keep the same pace than the process clock but in fact, what should be done is to speed up the process clock by adding the missing stats to it. Signed-off-by: Olivier Langlois oliv...@trillion01.com Thanks. Could you please resend these three patches in a new mail thread to make reviews easier? Also it would be nice to propose a different subject for each individual patch. Each of which describing what the patch does in a few words. Thanks. Frederic, Ok. I will do it and keep the description brief. If someone inquire more details, I will make them refer back to specific post inside this thread to avoid unnecessary repetition. Is this cool? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: i2c: tvp7002: enable TVP7002 decoder for media controller based usage
Hi Laurent,
Thanks for the review.
On Mon, Apr 29, 2013 at 7:57 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Prabhakar,
Thank you for the patch.
On Friday 26 April 2013 13:35:35 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch enables tvp7002 decoder driver for media controller
based usage by adding v4l2_subdev_pad_ops operations support
for enum_mbus_code, set_pad_format, get_pad_format and media_entity_init()
on probe and media_entity_cleanup() on remove.
The device supports 1 output pad and no input pads.
We should actually define input pads, connected to connector entities, but
that's out of scope for this patch.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/i2c/tvp7002.c | 125 ++--
include/media/tvp7002.h |2 +
2 files changed, 122 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index 027809c..b212d41 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -424,6 +424,8 @@ struct tvp7002 {
int streaming;
const struct tvp7002_timings_definition *current_timings;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
};
/*
@@ -880,6 +882,93 @@ static const struct v4l2_ctrl_ops tvp7002_ctrl_ops = {
.s_ctrl = tvp7002_s_ctrl,
};
+/*
+ * tvp7002_enum_mbus_code() - Enum supported digital video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @code: pointer to subdev enum mbus code struct
+ *
+ * Enumerate supported digital video formats for pad.
+ */
+static int
+tvp7002_enum_mbus_code(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+struct v4l2_subdev_mbus_code_enum *code)
+{
+ /* Check pad index is valid */
+ if (code-pad != 0)
+ return -EINVAL;
That check is already performed in the subdev core, there's no need to
duplicate it here.
OK
+
+ /* Check requested format index is within range */
+ if (code-index != 0)
+ return -EINVAL;
+
+ code-code = V4L2_MBUS_FMT_YUYV10_1X20;
+
+ return 0;
+}
+
+/*
+ * tvp7002_set_pad_format() - set video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @fmt: pointer to subdev format struct
+ *
+ * set video format for pad.
+*/
+static int
+tvp7002_set_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+struct v4l2_subdev_format *fmt)
+{
+ struct tvp7002 *tvp7002 = to_tvp7002(sd);
+
+ /* Check pad index is valid */
+ if (fmt-pad != 0)
+ return -EINVAL;
Redundant check as well.
OK
+ if (fmt-format.field != tvp7002-current_timings-scanmode ||
+ fmt-format.code != V4L2_MBUS_FMT_YUYV10_1X20 ||
+ fmt-format.colorspace != tvp7002-current_timings-color_space ||
+ fmt-format.width != tvp7002-current_timings-timings.bt.width ||
+ fmt-format.height != tvp7002-current_timings-timings.bt.height)
+ return -EINVAL;
You shouldn't return an error, but fix the input parameters according to what
the device supports. As the format is fixed for a giving set of timings, the
.set_pad_format() handler should just perform the same operations as
.get_pad_format(). You could even define tvp7002_get_pad_format() only and use
it as a handler for both .get_pad_format() and .set_pad_format().
OK. So its the job back in the application end to see what format was set.
+ tvp7002-format = fmt-format;
+
+ return 0;
+}
+
+/*
+ * tvp7002_get_pad_format() - get video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @fmt: pointer to subdev format struct
+ *
+ * get video format for pad.
+ */
+static int
+tvp7002_get_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+struct v4l2_subdev_format *fmt)
+{
+ struct tvp7002 *tvp7002 = to_tvp7002(sd);
+
+ /* Check pad index is valid */
+ if (fmt-pad != 0)
+ return -EINVAL;
Redundant check.
Ok
+ if (fmt-which == V4L2_SUBDEV_FORMAT_ACTIVE) {
+ fmt-format = tvp7002-format;
+ return 0;
+ }
+
+ fmt-format.code = V4L2_MBUS_FMT_YUYV10_1X20;
+ fmt-format.width = tvp7002-current_timings-timings.bt.width;
+ fmt-format.height = tvp7002-current_timings-timings.bt.height;
+ fmt-format.field = tvp7002-current_timings-scanmode;
+ fmt-format.colorspace = tvp7002-current_timings-color_space;
+
+ return 0;
+}
+
/* V4L2 core operation handlers */
static const struct v4l2_subdev_core_ops tvp7002_core_ops = {
.g_chip_ident = tvp7002_g_chip_ident,
@@ -910,10 +999,18 @@ static const struct v4l2_subdev_video_ops
tvp7002_video_ops = {
Re: [PATCH] media: i2c: tvp7002: enable TVP7002 decoder for media controller based usage
Hi Prabhakar,
On Monday 29 April 2013 23:00:26 Prabhakar Lad wrote:
On Mon, Apr 29, 2013 at 7:57 PM, Laurent Pinchart wrote:
On Friday 26 April 2013 13:35:35 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch enables tvp7002 decoder driver for media controller
based usage by adding v4l2_subdev_pad_ops operations support
for enum_mbus_code, set_pad_format, get_pad_format and
media_entity_init()
on probe and media_entity_cleanup() on remove.
The device supports 1 output pad and no input pads.
We should actually define input pads, connected to connector entities, but
that's out of scope for this patch.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
[snip]
+/*
+ * tvp7002_set_pad_format() - set video format on pad
+ * @sd: pointer to standard V4L2 sub-device structure
+ * @fh: file handle for the subdev
+ * @fmt: pointer to subdev format struct
+ *
+ * set video format for pad.
+*/
+static int
+tvp7002_set_pad_format(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh,
+struct v4l2_subdev_format *fmt)
+{
+ struct tvp7002 *tvp7002 = to_tvp7002(sd);
+
+ /* Check pad index is valid */
+ if (fmt-pad != 0)
+ return -EINVAL;
Redundant check as well.
OK
+ if (fmt-format.field != tvp7002-current_timings-scanmode ||
+ fmt-format.code != V4L2_MBUS_FMT_YUYV10_1X20 ||
+ fmt-format.colorspace != tvp7002-current_timings-color_space
|| + fmt-format.width !=
tvp7002-current_timings-timings.bt.width || +
fmt-format.height != tvp7002-current_timings-timings.bt.height) +
return -EINVAL;
You shouldn't return an error, but fix the input parameters according to
what the device supports. As the format is fixed for a giving set of
timings, the .set_pad_format() handler should just perform the same
operations as .get_pad_format(). You could even define
tvp7002_get_pad_format() only and use it as a handler for both
.get_pad_format() and .set_pad_format().
OK. So its the job back in the application end to see what format was set.
That's right. The format ioctls work that way to negotiate formats with
userspace.
+ tvp7002-format = fmt-format;
+
+ return 0;
+}
[snip]
+/* media pad related operation handlers */
+static const struct v4l2_subdev_pad_ops tvp7002_pad_ops = {
+ .enum_mbus_code = tvp7002_enum_mbus_code,
+ .get_fmt = tvp7002_get_pad_format,
+ .set_fmt = tvp7002_set_pad_format,
We will need to define pad-aware DV timings operations.
I didn't get you this?
We will need to extend the pad operations (struct v4l2_subdev_pad_ops) with
operations to enumerate, get and set DV timings at the pad level.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Mon, 2013-04-29 at 13:04 -0400, Chuck Lever wrote: On Apr 29, 2013, at 12:21 PM, Trond Myklebust trond.mykleb...@fys.uio.no wrote: On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. I've now pulled the rpcsec_gss changes into the nfs-for-next. The main reason why they were not pulled in earlier was due to uncertainty what to do about the increase in AUTH_GSS upcall timed out. syslog warnings. Trond's nfs-for-next now has the new rpcauth_get_gssinfo() and rpcauth_get_pseudoflavor() APIs, which are replacements for direct calls into the GSS mech switch. These APIs are a little more generic, and more robust in the face of unloaded GSS kernel modules. Instead of gss_mech_get_by_OID(), I suspect you want rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy code. The simplest way would be to make it not static again. In my code we are using gss_mech_get_by_OID() instead of gss_mech_get_by_name() because we have a OID passed down from gssproxy. Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote: On Apr 29, 2013, at 12:21 PM, Trond Myklebust trond.mykleb...@fys.uio.no wrote: On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. I've now pulled the rpcsec_gss changes into the nfs-for-next. The main reason why they were not pulled in earlier was due to uncertainty what to do about the increase in AUTH_GSS upcall timed out. syslog warnings. Trond's nfs-for-next now has the new rpcauth_get_gssinfo() and rpcauth_get_pseudoflavor() APIs, which are replacements for direct calls into the GSS mech switch. These APIs are a little more generic, and more robust in the face of unloaded GSS kernel modules. Instead of gss_mech_get_by_OID(), I suspect you want rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy code. It's doing status = -EOPNOTSUPP; gm = gss_mech_get_by_OID(ud-mech_oid); if (!gm) goto out; status = -EINVAL; status = gss_import_sec_context(ud-out_handle.data, ud-out_handle.len, gm, rsci.mechctx, expiry, GFP_KERNEL); if (status) goto out; So we need a way to get from an OID and some mechanism-specific data to a context. Looks to me like we just want to re-export gss_mech_get_by_OID(). --b. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] process cputimer is moving faster than its corresponding clock
On Mon, 2013-04-29 at 13:10 -0400, Olivier Langlois wrote: On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote: (4/27/13 12:40 AM), Olivier Langlois wrote: Forbids the cputimer to drift ahead of its process clock by blocking its update when a tick occurs while a autoreaping task is currently in do_exit() between the call to release_task() and its final call to schedule(). Any task stats update after having called release_task() will be lost because they are added to the global process stats located in the signal struct from release_task(). Ideally, you should postpone the release_task() call after the final context switch to get all the stats added but this is more complex to achieve. In other words, this is slowing down the cputimer so it keep the same pace than the process clock but in fact, what should be done is to speed up the process clock by adding the missing stats to it. Signed-off-by: Olivier Langlois oliv...@trillion01.com --- kernel/sched/fair.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7a33e59..52d7b10 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -708,7 +708,15 @@ static void update_curr(struct cfs_rq *cfs_rq) trace_sched_stat_runtime(curtask, delta_exec, curr-vruntime); cpuacct_charge(curtask, delta_exec); - account_group_exec_runtime(curtask, delta_exec); + /* +* Do not update the cputimer if the task is already released by +* release_task(). +* +* it would preferable to defer the autoreap release_task +* after the last context switch but harder to do. +*/ + if (likely(curtask-sighand)) + account_group_exec_runtime(curtask, delta_exec); } I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code. I have no seen any issue in this accounting. glibc launch a helper thread to receive timer signal and will also create a new thread upon signal reception when a timer is created with sigev_notify = SIGEV_THREAD; please see: glibc-2.17/nptl/sysdeps/unix/sysv/linux/timer_create.c glibc-2.17/nptl/sysdeps/unix/sysv/linux/timer_routines.c One very easy way to see the problem is to add a printk statement inside update_gt_cputime() if (b-sum_exec_runtime a-sum_exec_runtime) a-sum_exec_runtime = b-sum_exec_runtime; else printk( KERN_DEBUG cputimer %llu, process clock %llu, diff %llu\n, a-sum_exec_runtime, b-sum_exec_runtime, a-sum_exec_runtime-b-sum_exec_runtime); Check the output with and without the fair.c modif when executing tst-cputimer1. As an extra bonus, this trace will show the spurious start/stop cputimer problem that I was trying to explain to Frederic. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 29 (kconfig)
Randy, All, On Mon, Apr 29, 2013 at 09:25:54AM -0700, Randy Dunlap wrote: make ARCH=x86_64 O=X64 xconfig GEN /local/lnx/next/linux-next-20130429/X64/Makefile HOSTCXX scripts/kconfig/qconf.o In file included from scripts/kconfig/expr.h:15:0, from scripts/kconfig/lkc.h:9, from scripts/kconfig/qconf.cc:46: scripts/kconfig/list.h: In function 'void list_del(list_head*)': scripts/kconfig/list.h:128:16: error: invalid conversion from 'void*' to 'list_head*' [-fpermissive] scripts/kconfig/list.h:129:16: error: invalid conversion from 'void*' to 'list_head*' [-fpermissive] make[2]: *** [scripts/kconfig/qconf.o] Error 1 Found the culprit: 9a69abf80edf2ea0dac058cab156879d29362788 is the first bad commit commit 9a69abf80edf2ea0dac058cab156879d29362788 Author: Benjamin Poirier bpoir...@suse.de Date: Tue Apr 16 10:07:23 2013 -0400 menuconfig: Add breadcrumbs navigation aid Displays a trail of the menu entries used to get to the current menu. Signed-off-by: Benjamin Poirier bpoir...@suse.de Tested-by: Yann E. MORIN yann.morin.1...@free.fr [yann.morin.1...@free.fr: small, trivial code re-ordering] Signed-off-by: Yann E. MORIN yann.morin.1...@free.fr I'll submit a fix in a moment. Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kernel-hardening] Re: [PATCH 3/6] x86: kaslr: return location from decompress_kernel
On Sun, Apr 28, 2013 at 6:25 PM, James Morris jmor...@namei.org wrote: On Fri, 26 Apr 2013, H. Peter Anvin wrote: + noaslr [X86] + Disable kernel base offset ASLR (Address Space + Layout Randomization) if built into the kernel. + noautogroup Disable scheduler automatic task group creation. nobats [PPC] Do not use BATs for mapping kernel lowmem Calling it nokaslr might be useful to note that it is specifically about the kernel. Agreed. Yeah, good call. I'll get this changed. Thanks! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Apr 29, 2013, at 1:38 PM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote: On Apr 29, 2013, at 12:21 PM, Trond Myklebust trond.mykleb...@fys.uio.no wrote: On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. I've now pulled the rpcsec_gss changes into the nfs-for-next. The main reason why they were not pulled in earlier was due to uncertainty what to do about the increase in AUTH_GSS upcall timed out. syslog warnings. Trond's nfs-for-next now has the new rpcauth_get_gssinfo() and rpcauth_get_pseudoflavor() APIs, which are replacements for direct calls into the GSS mech switch. These APIs are a little more generic, and more robust in the face of unloaded GSS kernel modules. Instead of gss_mech_get_by_OID(), I suspect you want rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy code. It's doing status = -EOPNOTSUPP; gm = gss_mech_get_by_OID(ud-mech_oid); if (!gm) goto out; status = -EINVAL; status = gss_import_sec_context(ud-out_handle.data, ud-out_handle.len, gm, rsci.mechctx, expiry, GFP_KERNEL); if (status) goto out; So we need a way to get from an OID and some mechanism-specific data to a context. Looks to me like we just want to re-export gss_mech_get_by_OID(). The reason for the new wrappers is to load the kernel modules properly before trying to discover the OID - mechanism mapping. Where are you calling it from? If it's from outside of the GSS module, how do you guarantee the rpc_gss_auth module is loaded? What if the GSS mechanism for that OID isn't loaded? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-next-20130422] Bug in SLAB?
On Tue, 30 Apr 2013, Tetsuo Handa wrote:
Glauber Costa wrote:
If I am right, the following (untested) patch should solve the problem.
This patch did not help;
kmalloc(8 * 1024 * 1024, GFP_KERNEL)
still causes both
include/linux/slab_def.h:136: warning: array subscript is above array bounds
and
BUG: unable to handle kernel NULL pointer dereference at 0058
IP: [c10b9d76] kmem_cache_alloc+0x26/0xb0
.
Christoph Lameter wrote:
What is MAX_ORDER on the architecture?
In my environment (x86_32), the constants are
MAX_ORDER=11 PAGE_SHIFT=12 KMALLOC_SHIFT_HIGH=22 KMALLOC_MAX_SIZE=4194304
Ok so the maximum allocation is 11+12=23 which is 8M. KMALLOC_MAX_SIZE
amd KMALLOC_SHIFT_HIGH are wrong.
Take the -1 off the constants under #ifdef CONFIG_SLAB in
include/linux/slab.h
Index: linux/include/linux/slab.h
===
--- linux.orig/include/linux/slab.h 2013-04-29 12:44:42.339011800 -0500
+++ linux/include/linux/slab.h 2013-04-29 12:48:11.446435859 -0500
@@ -176,8 +176,8 @@ struct kmem_cache {
* to do various tricks to work around compiler limitations in order to
* ensure proper constant folding.
*/
-#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) = 25 ? \
- (MAX_ORDER + PAGE_SHIFT - 1) : 25)
+#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) = 26 ? \
+ (MAX_ORDER + PAGE_SHIFT) : 26)
#define KMALLOC_SHIFT_MAX KMALLOC_SHIFT_HIGH
#define KMALLOC_SHIFT_LOW 5
#else
@@ -206,9 +206,9 @@ struct kmem_cache {
#define KMALLOC_MIN_SIZE (1 KMALLOC_SHIFT_LOW)
#endif
-extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1];
+extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH];
#ifdef CONFIG_ZONE_DMA
-extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1];
+extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH];
#endif
/*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] x86: kaslr: move CPU flags out of cpucheck
On Fri, Apr 26, 2013 at 3:14 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/26/2013 02:47 PM, H. Peter Anvin wrote:
On 04/26/2013 12:03 PM, Kees Cook wrote:
+
+static inline void cpuid(u32 id, u32 *a, u32 *b, u32 *c, u32 *d)
+{
+/* Handle x86_32 PIC using ebx. */
+asm volatile(movl %%ebx, %%edi \n\t
+ cpuid \n\t
+ xchgl %%edi, %%ebx\n\t
+: =a (*a),
+ =D (*b),
+ =c (*c),
+ =d (*d)
+: a (id)
+);
+}
Please don't constrain registers unnecessarily.
You can use =r there and let gcc assign whatever free register it pleases.
You can also limit that to only:
#if defined(__i386__) defined(__PIC__)
How is this for a beauty:
#if defined(__i386__) defined (__PIC__)
# define EBX_REG =r
#else
# define EBX_REG =b
#endif
asm volatile(.ifnc %%ebx,%3 ; movl %%ebx,%3 ; .endif ;
cpuid ;
.ifnc %%ebx,%3 ; xchgl %%ebx,%3 ; .endif
: =a (*a), =c (*c), =d (*d),
EBX_REG (*b)
: a (leaf), c (subleaf));
Oh, very nice on the ifnc and register define! Is the leaf/subleaf
stuff needed there? That piece doesn't make sense to me.
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/7] watchdog: at32ap700x_wdt: use devm_*() functions
On Mon, Apr 29, 2013 at 06:34:31PM +0900, Jingoo Han wrote:
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/watchdog/at32ap700x_wdt.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/at32ap700x_wdt.c
b/drivers/watchdog/at32ap700x_wdt.c
index 7a715e3..c4cb552 100644
--- a/drivers/watchdog/at32ap700x_wdt.c
+++ b/drivers/watchdog/at32ap700x_wdt.c
@@ -321,13 +321,14 @@ static int __init at32_wdt_probe(struct platform_device
*pdev)
return -ENXIO;
}
- wdt = kzalloc(sizeof(struct wdt_at32ap700x), GFP_KERNEL);
+ wdt = devm_kzalloc(pdev-dev, sizeof(struct wdt_at32ap700x),
+ GFP_KERNEL);
if (!wdt) {
dev_dbg(pdev-dev, no memory for wdt structure\n);
return -ENOMEM;
}
- wdt-regs = ioremap(regs-start, resource_size(regs));
+ wdt-regs = devm_ioremap(pdev-dev, regs-start, resource_size(regs));
if (!wdt-regs) {
ret = -ENOMEM;
dev_dbg(pdev-dev, could not map I/O memory\n);
@@ -342,7 +343,7 @@ static int __init at32_wdt_probe(struct platform_device
*pdev)
dev_info(pdev-dev, CPU must be reset with external
reset or POR due to silicon errata.\n);
ret = -EIO;
- goto err_iounmap;
+ goto err_free;
} else {
wdt-users = 0;
}
@@ -375,10 +376,7 @@ static int __init at32_wdt_probe(struct platform_device
*pdev)
err_register:
platform_set_drvdata(pdev, NULL);
-err_iounmap:
- iounmap(wdt-regs);
err_free:
- kfree(wdt);
wdt = NULL;
return ret;
}
@@ -391,8 +389,6 @@ static int __exit at32_wdt_remove(struct platform_device
*pdev)
at32_wdt_stop();
misc_deregister(wdt-miscdev);
- iounmap(wdt-regs);
- kfree(wdt);
wdt = NULL;
platform_set_drvdata(pdev, NULL);
}
err_free isn't really appropriate anymore as label,
and platform_set_drvdata(pdev, NULL) as well as the associated complexity
in at32_wdt_remove is not really needed, but especially the latter should
really be addressed in another patch, so
Acked-by: Guenter Roeck li...@roeck-us.net
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: i2c: tvp7002: enable TVP7002 decoder for media controller based usage
Hi Laurent,
On Mon, Apr 29, 2013 at 11:06 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Prabhakar,
On Monday 29 April 2013 23:00:26 Prabhakar Lad wrote:
On Mon, Apr 29, 2013 at 7:57 PM, Laurent Pinchart wrote:
On Friday 26 April 2013 13:35:35 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch enables tvp7002 decoder driver for media controller
based usage by adding v4l2_subdev_pad_ops operations support
for enum_mbus_code, set_pad_format, get_pad_format and
media_entity_init()
on probe and media_entity_cleanup() on remove.
The device supports 1 output pad and no input pads.
We should actually define input pads, connected to connector entities, but
that's out of scope for this patch.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
[snip]
+/* media pad related operation handlers */
+static const struct v4l2_subdev_pad_ops tvp7002_pad_ops = {
+ .enum_mbus_code = tvp7002_enum_mbus_code,
+ .get_fmt = tvp7002_get_pad_format,
+ .set_fmt = tvp7002_set_pad_format,
We will need to define pad-aware DV timings operations.
I didn't get you this?
We will need to extend the pad operations (struct v4l2_subdev_pad_ops) with
operations to enumerate, get and set DV timings at the pad level.
not sure if exposing get and set DV timings at the pad level would be a better
idea, timings for pad's would be the same always and anyways we get DV timings
on video node. I cant think of usecase where we require get and set DV
timings at the pad level.
Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 2/7] watchdog: bcm63xx_wdt: use devm_ioremap_nocache()
On Mon, Apr 29, 2013 at 06:34:57PM +0900, Jingoo Han wrote: Use devm_ioremap_nocache() to make cleanup paths simpler. Signed-off-by: Jingoo Han jg1@samsung.com Reviewed-by: Guenter Roeck li...@roeck-us.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] x86: kaslr: move CPU flags out of cpucheck
On Mon, Apr 29, 2013 at 10:49 AM, Kees Cook keesc...@chromium.org wrote:
On Fri, Apr 26, 2013 at 3:14 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/26/2013 02:47 PM, H. Peter Anvin wrote:
On 04/26/2013 12:03 PM, Kees Cook wrote:
+
+static inline void cpuid(u32 id, u32 *a, u32 *b, u32 *c, u32 *d)
+{
+/* Handle x86_32 PIC using ebx. */
+asm volatile(movl %%ebx, %%edi \n\t
+ cpuid \n\t
+ xchgl %%edi, %%ebx\n\t
+: =a (*a),
+ =D (*b),
+ =c (*c),
+ =d (*d)
+: a (id)
+);
+}
Please don't constrain registers unnecessarily.
You can use =r there and let gcc assign whatever free register it pleases.
You can also limit that to only:
#if defined(__i386__) defined(__PIC__)
How is this for a beauty:
#if defined(__i386__) defined (__PIC__)
# define EBX_REG =r
#else
# define EBX_REG =b
#endif
asm volatile(.ifnc %%ebx,%3 ; movl %%ebx,%3 ; .endif ;
cpuid ;
.ifnc %%ebx,%3 ; xchgl %%ebx,%3 ; .endif
: =a (*a), =c (*c), =d (*d),
EBX_REG (*b)
: a (leaf), c (subleaf));
Oh, very nice on the ifnc and register define! Is the leaf/subleaf
stuff needed there? That piece doesn't make sense to me.
Ah, nevermind, I just need the leaf bit for the cpuid input. Thanks!
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] posix-cpu-timers: fix wrong timer initialization
(4/29/13 6:36 AM), Peter Zijlstra wrote:
On Mon, Apr 29, 2013 at 02:26:02AM -0400, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently glibc's rt/tst-cputimer1 testcase is spradically fail because
a timer created by timer_create() may faire earlier than an argument.
There are two faults. 1) cpu_timer_sample_group() adds
task_delta_exec(current).
But it is definity silly idea especially when multi thread. cputimer should
be initialized by committed exec runtime. i.e. it should not be added
scheduler delta. 2) expire time should be current time + timeout. In the
other
words, expire calculation should take care scheduler delta.
I'm sorry, that completely fails to parse.
-/*
- * Lock/unlock the current runqueue - to extract task statistics:
- */
-extern unsigned long long task_delta_exec(struct task_struct *);
Yay.. this thing dying is good -- it did seem strange to compute the current
delta but not also read sum_exec_runtime under the same lock.
diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
index e56be4c..dc61bc3 100644
--- a/kernel/posix-cpu-timers.c
+++ b/kernel/posix-cpu-timers.c
@@ -203,12 +203,10 @@ posix_cpu_clock_set(const clockid_t which_clock, const
struct timespec *tp)
return error;
}
-
-/*
- * Sample a per-thread clock for the given task.
- */
-static int cpu_clock_sample(const clockid_t which_clock, struct task_struct
*p,
-union cpu_time_count *cpu)
+static int do_cpu_clock_sample(const clockid_t which_clock,
+ struct task_struct *p,
+ bool add_delta,
+ union cpu_time_count *cpu)
Would not thread_cputime() (to mirror thread_group_cputime()) be a better
name?
agreed.
Also, I would think both these functions would be a good place to insert a
comment explaining the difference between timer and clock.
agreed.
+static int cpu_clock_sample(const clockid_t which_clock, struct task_struct
*p,
+union cpu_time_count *cpu)
+{
+return do_cpu_clock_sample(which_clock, p, true, cpu);
+}
@@ -700,7 +707,7 @@ static int posix_cpu_timer_set(struct k_itimer *timer,
int flags,
* check if it's already passed. In short, we need a sample.
*/
if (CPUCLOCK_PERTHREAD(timer-it_clock)) {
-cpu_clock_sample(timer-it_clock, p, val);
+do_cpu_clock_sample(timer-it_clock, p, false, val);
} else {
cpu_timer_sample_group(timer-it_clock, p, val);
}
This would suggest:
static inline int cpu_timer_sample(const clockid_t which_clock, struct
task_struct *p, union cpu_time_count *cpu)
{
return do_cpu_clock_sample(which_clock, p, false, cpu);
}
That would preserve the: cpu_{timer,clock}_sample{,_group}() form.
Yeah, agreed.
And also, all timer function should use cpu_timer_sample() instead of
cpu_clock_sample().
check_thread_timers() uses p-se.sum_exec_runtime without delta. This is
consitency with
per-process timer. Thus, other functions (e.g. posix_cpu_timers_get) should
also use the
same.
@@ -749,7 +756,13 @@ static int posix_cpu_timer_set(struct k_itimer *timer,
int flags,
}
if (new_expires.sched != 0 !(flags TIMER_ABSTIME)) {
-cpu_time_add(timer-it_clock, new_expires, val);
+union cpu_time_count now;
+
+if (CPUCLOCK_PERTHREAD(timer-it_clock))
+cpu_clock_sample(timer-it_clock, p, now);
+else
+cpu_clock_sample_group(timer-it_clock, p, now);
This triggered a pattern match against earlier in this function; but they're
different now; timer vs clock. So nothing to merge...
Not different, I think.
Relative timeout need to calculate now + timeout by definition.
But which time is now?
Example, thread1 has 10ms sum_exec_runtime and 4ms delta and call
timer_settime(4ms).
Old code calculate an expire is 10+4=14. New one calculate 10+4+4=18.
Which expire is correct? When using old one, timer will fire just after
syscall. This
is posix violation.
In the other words,
sighandler(){
t1 = clock_gettime()
}
t0 = clock_gettime()
timer_settime(timeout);
... wait to fire
assert (t1 - t0 = timeout)
This pseudo code must be true. it is snippest what glibc rt/tst-cputimer1 test
and failed.
So I don't mind the code changes, although its still not entirely clear to me
what exact problem is fixed how; and thus the Changelog needs TLC.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] media: i2c: adv7343: add OF support
Hi Laurent,
Thanks for the review.
On Mon, Apr 29, 2013 at 7:32 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Prabhakar,
Thank you for the patch.
On Friday 26 April 2013 18:48:06 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the adv7343 driver.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
---
.../devicetree/bindings/media/i2c/adv7343.txt | 69 +
drivers/media/i2c/adv7343.c| 75 -
2 files changed, 142 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/adv7343.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7343.txt
b/Documentation/devicetree/bindings/media/i2c/adv7343.txt new file mode
100644
index 000..8426f8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7343.txt
@@ -0,0 +1,69 @@
+* Analog Devices adv7343 video encoder
+
+The ADV7343 are high speed, digital-to-analog video encoders in a 64-lead
LQFP +package. Six high speed, 3.3 V, 11-bit video DACs provide support for
composite +(CVBS), S-Video (Y-C), and component (YPrPb/RGB) analog outputs
in standard +definition (SD), enhanced definition (ED), or high definition
(HD) video +formats.
+
+The ADV7343 have a 24-bit pixel input port that can be configured in a
variety +of ways. SD video formats are supported over an SDR interface, and
ED/HD video +formats are supported over SDR and DDR interfaces. Pixel data
can be supplied +in either the YCrCb or RGB color spaces.
+
+Required Properties :
+- compatible: Must be ad,adv7343-encoder
+
+Optional Properties :
+- ad-adv7343-power-mode-sleep-mode: on enable the current consumption is
+reduced to micro ampere level. All DACs
+and the internal PLL circuit are
+disabled.
+- ad-adv7343-power-mode-pll-ctrl: PLL and oversampling control. This
+ control allows internal PLL 1 circuit to
+ be powered down and the oversampling to
+ be switched off.
+
+- ad-adv7343-power-mode-dac-1: power on/off DAC 1.
+- ad-adv7343-power-mode-dac-2: power on/off DAC 2.
+- ad-adv7343-power-mode-dac-3: power on/off DAC 3.
+- ad-adv7343-power-mode-dac-4: power on/off DAC 4.
+- ad-adv7343-power-mode-dac-5: power on/off DAC 5.
+- ad-adv7343-power-mode-dac-6: power on/off DAC 6.
+- ad-adv7343-sd-config-dac-out-1: Configure SD DAC Output 1.
+- ad-adv7343-sd-config-dac-out-2: Configure SD DAC Output 2.
s/ad-/ad,/
OK
Do all those properties really need to be specified at the endpoint level
instead of the device node level ?
Yes.
I'll let Hans comment on the individual properties, he knows more than I do
about DACs.
+Example:
+
+i2c0@1c22000 {
+ ...
+ ...
+
+ adv7343@2a {
+ compatible = ad,adv7343-encoder;
+ reg = 0x2a;
+
+ port {
+ adv7343_1: endpoint {
+ /* Active high (Defaults to false) */
Active high ?
:-) will fix it.
Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 3/7] watchdog: mv64x60_wdt: use devm_ioremap()
On Mon, Apr 29, 2013 at 06:35:15PM +0900, Jingoo Han wrote: Use devm_ioremap() to make cleanup paths simpler. Signed-off-by: Jingoo Han jg1@samsung.com This patch also addresses the missing call to iounmap() if the call to misc_register fails. Reviewed-by: Guenter Roeck li...@roeck-us.net --- drivers/watchdog/mv64x60_wdt.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/watchdog/mv64x60_wdt.c b/drivers/watchdog/mv64x60_wdt.c index c7fb878..e4cf980 100644 --- a/drivers/watchdog/mv64x60_wdt.c +++ b/drivers/watchdog/mv64x60_wdt.c @@ -276,7 +276,7 @@ static int mv64x60_wdt_probe(struct platform_device *dev) if (!r) return -ENODEV; - mv64x60_wdt_regs = ioremap(r-start, resource_size(r)); + mv64x60_wdt_regs = devm_ioremap(dev-dev, r-start, resource_size(r)); if (mv64x60_wdt_regs == NULL) return -ENOMEM; @@ -293,8 +293,6 @@ static int mv64x60_wdt_remove(struct platform_device *dev) mv64x60_wdt_handler_disable(); - iounmap(mv64x60_wdt_regs); - return 0; } -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-watchdog in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] process cputimer is moving faster than its corresponding clock
(4/29/13 1:10 PM), Olivier Langlois wrote: On Mon, 2013-04-29 at 01:06 -0400, KOSAKI Motohiro wrote: (4/27/13 12:40 AM), Olivier Langlois wrote: Forbids the cputimer to drift ahead of its process clock by blocking its update when a tick occurs while a autoreaping task is currently in do_exit() between the call to release_task() and its final call to schedule(). Any task stats update after having called release_task() will be lost because they are added to the global process stats located in the signal struct from release_task(). Ideally, you should postpone the release_task() call after the final context switch to get all the stats added but this is more complex to achieve. In other words, this is slowing down the cputimer so it keep the same pace than the process clock but in fact, what should be done is to speed up the process clock by adding the missing stats to it. Signed-off-by: Olivier Langlois oliv...@trillion01.com --- kernel/sched/fair.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7a33e59..52d7b10 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -708,7 +708,15 @@ static void update_curr(struct cfs_rq *cfs_rq) trace_sched_stat_runtime(curtask, delta_exec, curr-vruntime); cpuacct_charge(curtask, delta_exec); - account_group_exec_runtime(curtask, delta_exec); + /* +* Do not update the cputimer if the task is already released by +* release_task(). +* +* it would preferable to defer the autoreap release_task +* after the last context switch but harder to do. +*/ + if (likely(curtask-sighand)) + account_group_exec_runtime(curtask, delta_exec); } I'm confused. glibc's rt/tst-cputimer1 doesn't have thread exiting code. I have no seen any issue in this accounting. glibc launch a helper thread to receive timer signal and will also create a new thread upon signal reception when a timer is created with sigev_notify = SIGEV_THREAD; please see: glibc-2.17/nptl/sysdeps/unix/sysv/linux/timer_create.c glibc-2.17/nptl/sysdeps/unix/sysv/linux/timer_routines.c I know. I taled thread exiting. not thread creating. And, as far as I can see, only test sig1 can fail, not thr[12]. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Mon, 2013-04-29 at 13:47 -0400, Chuck Lever wrote: On Apr 29, 2013, at 1:38 PM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote: On Apr 29, 2013, at 12:21 PM, Trond Myklebust trond.mykleb...@fys.uio.no wrote: On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. I've now pulled the rpcsec_gss changes into the nfs-for-next. The main reason why they were not pulled in earlier was due to uncertainty what to do about the increase in AUTH_GSS upcall timed out. syslog warnings. Trond's nfs-for-next now has the new rpcauth_get_gssinfo() and rpcauth_get_pseudoflavor() APIs, which are replacements for direct calls into the GSS mech switch. These APIs are a little more generic, and more robust in the face of unloaded GSS kernel modules. Instead of gss_mech_get_by_OID(), I suspect you want rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy code. It's doing status = -EOPNOTSUPP; gm = gss_mech_get_by_OID(ud-mech_oid); if (!gm) goto out; status = -EINVAL; status = gss_import_sec_context(ud-out_handle.data, ud-out_handle.len, gm, rsci.mechctx, expiry, GFP_KERNEL); if (status) goto out; So we need a way to get from an OID and some mechanism-specific data to a context. Looks to me like we just want to re-export gss_mech_get_by_OID(). The reason for the new wrappers is to load the kernel modules properly before trying to discover the OID - mechanism mapping. Where are you calling it from? If it's from outside of the GSS module, how do you guarantee the rpc_gss_auth module is loaded? What if the GSS mechanism for that OID isn't loaded? Does gss_mech_get_by_name() do the loading ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X86 fpu registers in a signal handler's ucontext
Warlich, Christof christof.warl...@siemens.com writes: First, this link: http://valgrind.10908.n7.nabble.com/need-FPU-and-SSE-state-in-sigcontext-ucontext-td19844.html suggests that unlike the GPRs, the FP registers are _not_ restored after returnung from the signal handler. The FP registers are restored lazily, but the state for this is kept in the kernel. One easy way may be to catch the FPU exception too and clear from there? There can be some complications with different save formats too (XSAVE vs FXSAVE). So your solution may not be necessarily 100% portable to all systems. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the nfsd tree
On Mon, Apr 29, 2013 at 01:47:16PM -0400, Chuck Lever wrote: On Apr 29, 2013, at 1:38 PM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 01:04:01PM -0400, Chuck Lever wrote: On Apr 29, 2013, at 12:21 PM, Trond Myklebust trond.mykleb...@fys.uio.no wrote: On Mon, 2013-04-29 at 12:05 -0400, Chuck Lever wrote: On Apr 29, 2013, at 11:45 AM, J. Bruce Fields bfie...@fieldses.org wrote: On Mon, Apr 29, 2013 at 10:53:37AM -0400, Chuck Lever wrote: On Apr 28, 2013, at 9:24 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi J., After merging the nfsd tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/auth_gss/svcauth_gss.c: In function 'gss_proxy_save_rsc': net/sunrpc/auth_gss/svcauth_gss.c:1182:3: error: implicit declaration of function 'gss_mech_get_by_OID' [-Werror=implicit-function-declaration] Caused byc ommit 030d794bf498 (SUNRPC: Use gssproxy upcall for server RPCGSS authentication). gss_mech_get_by_OID() made static to net/sunrpc/auth_gss/gss_mech_switch.c by commit 9568c5e9a61d (SUNRPC: Introduce rpcauth_get_pseudoflavor()) in the nfs tree (part of the nfs tree that you did not merge). I don't know how to fix this, so I have used the nfsd tree from next-20130426 for today. Bruce, it might make sense for me to submit the three server-side RPC GSS patches, and then you can rebase the gssproxy work on top of those. Let me know how you would like to proceed. I'm happy to take those patches whenever you consider them ready. Would that fix the problem? Someone would need to modify the gssproxy patches to use the new interfaces. Also: it looks like 030d794bf498 SUNRPC: Introduce rpcauth_get_pseudoflavor() is in Trond's linux-next, but not his nfs-for-next. I'm not sure what that means--is it safe to rebase on top of *that*? That doesn't seem right to me. I've now pulled the rpcsec_gss changes into the nfs-for-next. The main reason why they were not pulled in earlier was due to uncertainty what to do about the increase in AUTH_GSS upcall timed out. syslog warnings. Trond's nfs-for-next now has the new rpcauth_get_gssinfo() and rpcauth_get_pseudoflavor() APIs, which are replacements for direct calls into the GSS mech switch. These APIs are a little more generic, and more robust in the face of unloaded GSS kernel modules. Instead of gss_mech_get_by_OID(), I suspect you want rpcauth_get_pseudoflavor(), but I haven't looked at the gssproxy code. It's doing status = -EOPNOTSUPP; gm = gss_mech_get_by_OID(ud-mech_oid); if (!gm) goto out; status = -EINVAL; status = gss_import_sec_context(ud-out_handle.data, ud-out_handle.len, gm, rsci.mechctx, expiry, GFP_KERNEL); if (status) goto out; So we need a way to get from an OID and some mechanism-specific data to a context. Looks to me like we just want to re-export gss_mech_get_by_OID(). The reason for the new wrappers is to load the kernel modules properly before trying to discover the OID - mechanism mapping. Where are you calling it from? If it's from outside of the GSS module, how do you guarantee the rpc_gss_auth module is loaded? What if the GSS mechanism for that OID isn't loaded? Sorry, I should have said just remove static from, not re-export--it's in the same module. So there should be no problem here, right? --b. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[pull request] Pull request for branch yem-kconfig-for-next
From: Yann E. MORIN yann.morin.1...@free.fr Michal, Please pull this fix to restore compilation of the qconf frontend. Regards, Yann E. MORIN. The following changes since commit 23a5dfdad22a574d19d7cc19b391f9ce0d3c2f21: Revert kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG (2013-04-26 23:21:59 +0200) are available in the git repository at: git://gitorious.org/linux-kconfig/linux-kconfig.git yem-kconfig-for-next for you to fetch changes up to 21ca352b71ca252e1933b1538fe89da8a04395c3: kconfig: fix lists definition for C++ (2013-04-29 19:55:56 +0200) Yann E. MORIN (1): kconfig: fix lists definition for C++ scripts/kconfig/list.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] kconfig: fix lists definition for C++
From: Yann E. MORIN yann.morin.1...@free.fr
The C++ compiler is more strict in that it refuses to assign
a void* to a struct list_head*.
Fix that by explicitly casting the poisonning constants.
(Tested with all 5 frontends, now.)
Reported-by: Randy Dunlap rdun...@infradead.org
Signed-off-by: Yann E. MORIN yann.morin.1...@free.fr
Cc: Randy Dunlap rdun...@infradead.org
Cc: Benjamin Poirier bpoir...@suse.de
---
scripts/kconfig/list.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/list.h b/scripts/kconfig/list.h
index ea1d581..685d80e 100644
--- a/scripts/kconfig/list.h
+++ b/scripts/kconfig/list.h
@@ -125,7 +125,7 @@ static inline void __list_del(struct list_head *prev,
struct list_head *next)
static inline void list_del(struct list_head *entry)
{
__list_del(entry-prev, entry-next);
- entry-next = LIST_POISON1;
- entry-prev = LIST_POISON2;
+ entry-next = (struct list_head*)LIST_POISON1;
+ entry-prev = (struct list_head*)LIST_POISON2;
}
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
