Re: ftrace/kprobes: Warning when insmod two modules
Steven Rostedt rost...@goodmis.org writes: On Mon, 24 Mar 2014 20:26:05 +0900 Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote: Thank you for reporting with this pretty backtrace :) Steven, I think this is not the kprobe bug but ftrace (and perhaps, module). Looks to be more of a module issue than a ftrace issue. If the ftrace can set loading module text read only before the module subsystem expected, I think it should be protected by the module subsystem itself (e.g. set_all_modules_text_ro(rw) skips the modules which is MODULE_STATE_COMING) Does this patch fix it? In-review-off-by: Steven Rostedt rost...@goodmis.org Sorry, was on paternity leave. I'm always nervous about adding more states, since every place which examines the state has to be audited. We set the mod-state to MOD_STATE_COMING in complete_formation; why don't we set NX there instead? It also makes more sense to set NX before we hit parse_args() which can execute code in the module. In fact, we should probably call the notifier there too, so people can breakpoint/tracepoint/etc parameter calls. Of course, this means that we set NX before the notifier; does anything break? Subject: module: set nx before marking module MODULE_STATE_COMING. This prevents a WARN_ON() where ftrace calls set_all_modules_text_ro() which races with the module setting its own set_section_ro_nx(). It also means we're NX protected before we call parse_args(), which can execute module code. This means that the notifiers will be called on a module which is already NX, so that may cause problems. Signed-off-by: Rusty Russell ru...@rustcorp.com.au diff --git a/kernel/module.c b/kernel/module.c index 11869408f79b..83a437e5d429 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -3023,21 +3023,6 @@ static int do_init_module(struct module *mod) */ current-flags = ~PF_USED_ASYNC; - blocking_notifier_call_chain(module_notify_list, - MODULE_STATE_COMING, mod); - - /* Set RO and NX regions for core */ - set_section_ro_nx(mod-module_core, - mod-core_text_size, - mod-core_ro_size, - mod-core_size); - - /* Set RO and NX regions for init */ - set_section_ro_nx(mod-module_init, - mod-init_text_size, - mod-init_ro_size, - mod-init_size); - do_mod_ctors(mod); /* Start the module */ if (mod-init != NULL) @@ -3168,9 +3153,26 @@ static int complete_formation(struct module *mod, struct load_info *info) /* This relies on module_mutex for list integrity. */ module_bug_finalize(info-hdr, info-sechdrs, mod); + /* Set RO and NX regions for core */ + set_section_ro_nx(mod-module_core, + mod-core_text_size, + mod-core_ro_size, + mod-core_size); + + /* Set RO and NX regions for init */ + set_section_ro_nx(mod-module_init, + mod-init_text_size, + mod-init_ro_size, + mod-init_size); + /* Mark state as coming so strong_try_module_get() ignores us, * but kallsyms etc. can see us. */ mod-state = MODULE_STATE_COMING; + mutex_unlock(module_mutex); + + blocking_notifier_call_chain(module_notify_list, +MODULE_STATE_COMING, mod); + return 0; out: mutex_unlock(module_mutex); -- 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 0/9] Avoid world-writable sysfs files.
This adds checking for world-writable sysfs files, after cleaning up all the users. This check has been in module sysfs params since 2006. If you have a reason for being world-writable, please tell me now! Rusty Russell (9): drivers/mtd/devices/docg3.c: avoid world-writable sysfs files. drivers/video/fbdev/sm501fb.c: avoid world-writable sysfs files. drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files. drivers/scsi/pm8001/pm8001_ctl.c: avoid world-writable sysfs files. drivers/regulator/virtual: avoid world-writable sysfs files. drivers/staging/speakup/: avoid world-writable sysfs files. drivers/hid/hid-picolcd_fb: avoid world-writable sysfs files. samples/kobject/: avoid world-writable sysfs files. sysfs: disallow world-writable files. drivers/hid/hid-lg4ff.c | 2 +- drivers/hid/hid-picolcd_fb.c | 2 +- drivers/mtd/devices/docg3.c | 4 +-- drivers/regulator/virtual.c | 10 +++--- drivers/scsi/pm8001/pm8001_ctl.c | 2 +- drivers/staging/speakup/kobjects.c | 60 drivers/staging/speakup/speakup_acntpc.c | 14 drivers/staging/speakup/speakup_acntsa.c | 14 drivers/staging/speakup/speakup_apollo.c | 16 - drivers/staging/speakup/speakup_audptr.c | 16 - drivers/staging/speakup/speakup_bns.c| 14 drivers/staging/speakup/speakup_decext.c | 16 - drivers/staging/speakup/speakup_decpc.c | 16 - drivers/staging/speakup/speakup_dectlk.c | 16 - drivers/staging/speakup/speakup_dtlk.c | 20 +-- drivers/staging/speakup/speakup_dummy.c | 14 drivers/staging/speakup/speakup_keypc.c | 10 +++--- drivers/staging/speakup/speakup_ltlk.c | 20 +-- drivers/staging/speakup/speakup_soft.c | 22 ++-- drivers/staging/speakup/speakup_spkout.c | 16 - drivers/staging/speakup/speakup_txprt.c | 14 drivers/video/fbdev/sm501fb.c| 2 +- include/linux/kernel.h | 2 ++ samples/kobject/kobject-example.c| 7 ++-- samples/kobject/kset-example.c | 7 ++-- 25 files changed, 170 insertions(+), 166 deletions(-) -- 1.8.3.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/
[PATCH 3/9] drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time
check that sysfs files aren't world-writable.
Cc: Simon Wood si...@mungewell.org
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/hid/hid-lg4ff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 24883b4d1a49..cc2bd2022198 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -52,7 +52,7 @@ static void hid_lg4ff_set_range_g25(struct hid_device *hid,
u16 range);
static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute
*attr, char *buf);
static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute
*attr, const char *buf, size_t count);
-static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IRWXO, lg4ff_range_show,
lg4ff_range_store);
+static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IROTH, lg4ff_range_show,
lg4ff_range_store);
struct lg4ff_device_entry {
__u32 product_id;
--
1.8.3.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/
[PATCH 9/9] sysfs: disallow world-writable files.
This check was introduced in 2006 by Alexey Dobriyan (9774a1f54f173)
for module parameters; we removed it when we unified the check into
VERIFY_OCTAL_PERMISSIONS() as sysfs didn't have the same requirement.
Now all those users are fixed, reintroduce it.
Cc: Alexey Dobriyan adobri...@gmail.com
Cc: Dave Jones da...@redhat.com
Cc: Joe Perches j...@perches.com
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
include/linux/kernel.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c52907a6d8b..43e1c6a9683e 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -849,5 +849,7 @@ static inline void ftrace_dump(enum ftrace_dump_mode
oops_dump_mode) { }
/* User perms = group perms = other perms */ \
BUILD_BUG_ON_ZERO(((perms) 6) (((perms) 3) 7)) + \
BUILD_BUG_ON_ZEROperms) 3) 7) ((perms) 7)) + \
+/* Other writable? Generally considered a bad idea. */\
+BUILD_BUG_ON_ZERO((perms) 2) + \
(perms))
#endif
--
1.8.3.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/
Re: [PATCH V2 14/19] tick-sched: add comment about 'idle_active' in tick_nohz_idle_exit()
On Tuesday 22 April 2014 04:50 AM, Frederic Weisbecker wrote: It's still over-detailed. Much of the above is easily deduced after common review. OTOH I proposed to summarize there: https://lkml.org/lkml/2014/4/11/334 The below disambiguates it a bit further. Hmm.. Something broke for sure in my repo. I do remember updating this patch with your comments and something went wrong while playing with patches. Sorry for that. Fixed my repo now. Now it's eventually getting as big as your comment ;-) /* * ts-idle_active drives the idle time which typically elapses in the idle loop * but breaks on IRQs interrupting idle loop. * * Hence ts-idle_active can be 1 here if we exit the idle loop without the help of * an IRQ. OTOH it can be 0 on idle exit if a wake up IPI pulled the CPU out of * the idle loop. Since we know that we'll be exiting the idle task after the wake * up IPI, all the pending idle sleep time is flushed on irq entry and no more is * accounted further thanks to the need_resched() check on irq_exit(). */ @Thomas: Please consider this patch instead: Author: Viresh Kumar viresh.ku...@linaro.org Date: Mon Apr 21 15:25:10 2014 +0530 tick-sched: add comment about 'idle_active' in tick_nohz_idle_exit() The sequence of calls for dynticks CPUs is a bit confusing. Add a comment in tick_nohz_idle_exit() to mention it clearly. All information required is in commit and this conversation with Frederic. https://lkml.org/lkml/2014/4/10/355 Suggested-by: Frederic Weisbecker fweis...@gmail.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- kernel/time/tick-sched.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 71f64ee..b2f024f 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -922,6 +922,17 @@ void tick_nohz_idle_exit(void) ts-inidle = 0; + /* +* ts-idle_active drives the idle time which typically elapses in the +* idle loop but breaks on IRQs interrupting idle loop. +* +* Hence ts-idle_active can be 1 here if we exit the idle loop without +* the help of an IRQ. OTOH it can be 0 on idle exit if a wake up IPI +* pulled the CPU out of the idle loop. Since we know that we'll be +* exiting the idle task after the wake up IPI, all the pending idle +* sleep time is flushed on irq entry and no more is accounted further +* thanks to the need_resched() check on irq_exit(). +*/ if (ts-idle_active || ts-tick_stopped) now = ktime_get(); -- 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 2/7] of: introduce of_dma_get_range() helper
On 04/19/2014 09:32 AM, Santosh Shilimkar wrote:
From: Grygorii Strashko grygorii.stras...@ti.com
[..]
+ * Look in bottom up direction for the first dma-range property
+ * and parse it.
+ * dma-ranges format:
+ * DMA addr (dma_addr) : naddr cells
+ * CPU addr (phys_addr_t) : pna cells
+ * size: nsize cells
+ *
+ * It returns -ENODEV if dma-ranges property was not found
+ * for this device in DT.
+ */
+extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size)
+{
+ struct device_node *node = np;
+ const u32 *ranges = NULL;
+ int len, naddr, nsize, pna;
+ int ret = 0;
+
+ if (!node)
+ return -EINVAL;
+
+ while (1) {
+ naddr = of_n_addr_cells(node);
+ nsize = of_n_size_cells(node);
+ node = of_get_next_parent(node);
+ if (!node)
+ break;
+
+ ranges = of_get_property(node, dma-ranges, len);
+
+ /* Ignore empty ranges, they imply no translation required */
+ if (ranges len 0)
+ break;
+
+ /*
+ * At least empty ranges has to be defined for parent node if
+ * DMA is supported
+ */
+ if (!ranges)
+ break;
+ }
+
+ if (!ranges) {
+ pr_debug(%s: no dma-ranges found for node(%s)\n,
+ __func__, np-full_name);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ len /= sizeof(u32);
+
+ pna = of_n_addr_cells(node);
+
+ /* dma-ranges format:
+ * DMA addr : naddr cells
+ * CPU addr : pna cells
+ * size : nsize cells
+ */
+ *dma_addr = of_read_number(ranges, naddr);
+ *paddr = of_translate_dma_address(np, ranges);
I am probably missing something but I'm wondering the need for a
translate step here instead of doing something like:
*paddr = of_read_number(ranges + naddr, pna);
Perhaps there is a need to do a translate step of the DMA Address in
dma-ranges all the way to the parent, which can be different from the
CPU Address (second address in dma-ranges).
in which case the format of dma-ranges after parsing looks like
DMA-Addr Translate(DMA-Addr) Size
to the caller, and not, DMA-Addr CPU-Addr Size
But for keystone if something like the following is used,
dma-ranges = 0x8000 0x8 0x 0x8000;
Then, the above fragment I proposed would return 0x8 0x which is
sufficient?
thanks,
-Joel
+ if (*paddr == OF_BAD_ADDR) {
+ pr_err(%s: translation of DMA address(%pad) to CPU address
failed node(%s)\n,
+__func__, dma_addr, np-full_name);
+ ret = -EINVAL;
+ }
+
+ *size = of_read_number(ranges + naddr + pna, nsize);
+
+ pr_debug(dma_addr(%pad) cpu_addr(%pa) size(%pa)\n,
+ dma_addr, paddr, size);
+
+out:
+ of_node_put(node);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_dma_get_range);
#endif /* CONFIG_OF_ADDRESS */
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 05cb4a9..ba7d3dc 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
struct device *parent);
+extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size);
#else
static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
@@ -80,6 +82,12 @@ static inline int of_platform_populate(struct device_node
*root,
{
return -ENODEV;
}
+
+static inline int of_dma_get_range(struct device_node *np, dma_addr_t
*dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size)
+{
+ return -ENODEV;
+}
#endif
#endif /* _LINUX_OF_PLATFORM_H */
--
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] Kbuild, lto: Avoid reported warning with strtoul
On 21 April 2014 22:20, Andi Kleen a...@linux.intel.com wrote: Hmm that's odd. I guess could assign it to a dummy variable That produces this: scripts/mod/modpost.c: In function ‘remove_dot’: scripts/mod/modpost.c:1708:16: warning: variable ‘ignore’ set but not used [-Wunused-but-set-variable] or use viro's variant. It looks fine but can't test if works exactly the same way as current implementation. -- 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 0/4] ipc/shm.c: increase the limits for SHMMAX, SHMALL
On 04/21/2014 07:25 PM, Davidlohr Bueso wrote: On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: Hi all, the increase of SHMMAX/SHMALL is now a 4 patch series. I don't have ideas how to improve it further. Manfred, is there any difference between this set and the one you sent a couple of days ago? a) I updated the comments. b) the initial set used TASK_SIZE, not I switch to ULONG_MAX-(1L24) - Using 0 as a magic value for infinity is even worse, because right now 0 means 0, i.e. fail all allocations. Sorry but I don't quite get this. Using 0 eliminates the need for all these patches, no? I mean overflows have existed since forever, and taking this route would naturally solve the problem. 0 allocations are a no no anyways. No. The patches are required to handle e.g. shmget(,ULONG_MAX,): Right now, shmget(,ULONG_MAX,) results in a 0-byte segment. The risk of using 0 is that it reverses the current behavior: Up to now, # sysctl kernel.shmall=0 disables allocations. If we define 0 a infinity, then the same configuration would allow unlimited allocations. -- Manfred -- 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/4] sysctl: allow for strict write position handling
On Mon, Apr 21, 2014 at 3:45 PM, Andrew Morton a...@linux-foundation.org wrote: On Thu, 17 Apr 2014 17:16:22 -0700 Kees Cook keesc...@chromium.org wrote: When writing to a sysctl string, each write, regardless of VFS position, begins writing the string from the start. This means the contents of the last write to the sysctl controls the string contents instead of the first: open(/proc/sys/kernel/modprobe, O_WRONLY) = 1 write(1, ..., 4096) = 4096 write(1, /bin/true, 9)= 9 close(1)= 0 $ cat /proc/sys/kernel/modprobe /bin/true Expected behaviour would be to have the sysctl be ... capped at maxlen (in this case KMOD_PATH_LEN: 256), instead of truncating to the contents of the second write. Similarly, multiple short writes would not append to the sysctl. This provides CONFIG_PROC_SYSCTL_STRICT_WRITES as a way to make this behavior act in a less surprising manner for strings, and disallows non-zero file position when writing numeric sysctls (similar to what is already done when reading from non-zero file positions). Adding a Kconfig knob to alter the behavior of procfs writes creeps me out. I wonder why. - I doubt if many people have a sufficient amount of control over their entire systems to be able to confidently set CONFIG_PROC_SYSCTL_STRICT_WRITES. - Software will be shipped which runs OK with one setting but breaks with the other setting. So what to do? I think we can *detect* this situation easily enough. So some options are a) change the behaviour and add code which detects when userspace is doing a write whose behaviour is now altered. Print a warning. Or b) leave the behaviour as-is. Add a detector which tells people hey, your userspace is probably broken - please fix. Wait N years. Then alter the behaviour as in a). In either case the detector should display current-comm, the procfs pathname and the contents of the write, to aid people in hunting down and fixing their userspace. How about a tri-state sysctl (har har control sysctl behavior with a sysctl) that defaults (1) to existing behavior (to not break anything) with a warning. Mode 2 uses new behavior, and mode 0 uses existing behavior without a warning? Then we can wait N years and switch the default to 2? -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] locks: rename file-private locks to file-description locks
On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote: Am 21.04.2014 21:55, schrieb Jeff Layton: On Mon, 21 Apr 2014 21:39:12 +0200 Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: On 04/21/2014 08:46 PM, Rich Felker wrote: On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote: On 04/21/2014 06:10 PM, Rich Felker wrote: I'm well aware of that. The problem is that the proposed API is using the two-letter abbreviation FD, which ALWAYS means file descriptor and NEVER means file description (in existing usage) to mean file description. That's what's wrong. So, can you *please* answer this question: what do you call (i.e., what everyday technical language term do use for) the thing that sits between a file descriptor and an i-node? (Please don't say 'struct file' -- that is not is an implementation detail, and does not qualify as the kind of term that I could use when documenting this feature in man pages.) Open file description. Oh! I didn't realize we agreed :-). POSIX uses (or invented, I am not sure which) the term file description for a good reason: it is unambiguous, and therefore precise. I do agree that there's a risk of confusion between 'open file descriptor and 'and file description'--it's the same kind of risk as between English terms such as 'arbitrator' and 'arbitration' (and any number of other examples), and as language speakers we deal with this every day. There's not a problem when the full word is used. On the other hand, if you use arb as an abbreviation for arbitration in a context where it was already universally understood as meaning arbitrator, that would be a big problem. Likewise the problem here isn't that open file description is a bad term. It's that using FD to mean [open] file description is utterly confusing, even moreso than just making up a new completely random word. Ohh -- I had thought you a problem not just with FD but also (open) file description. 2) The new API constants (F_SETLKP, F_SETLKPW, F_GETLKP) have names that are visually very close to the traditional POSIX lock names (F_SETLK, F_SETLKW, F_GETLK). That's an accident waiting to happen when someone mistypes in code and/or misses such a misttyping when reading code. That really must be fixed. I agree, but I don't think making it worse is a solution. I don't agree that it's making it worse. The real problem here is that people use no good unambiguous term for the thing between a file descriptor and an inode. POSIX provides us with a solution that may not seem perfect, but it is unambiguous, and I think it might feel more comfortable if we used it often enough. I would like to see it used more too, and in particular, I think it belongs in the documentation for these new locking interfaces. But that still doesn't answer the question of what to call them (the macros) unless you want: F_OPEN_FILE_DESCRIPTION_GETLK F_OPEN_FILE_DESCRIPTION_SETLK F_OPEN_FILE_DESCRIPTION_SETLKW Or just 'F_OFD_*'? Perhaps OP (for open-private, i.e. private to the particular open) would be a sensible choice; OTOH people are likely to misread it as OPeration. The general principle I have in mind though is that it might be nice to highlight the word open in open file description (Fair enough.) since it (1) contrasts with file descriptor, despite file descriptors also dealing with open files, and (2) contrasts well with legacy fcntl locks, which are (this is the whole bug) associated with the underlying file and not the open file description. Makes sense to me. (We are in more agreement that I realized.) Cheers, Michael So the motion is to call them open file description locks and change the macros to read *_OFD_*. Does anyone object? Works fine for me... And works for me. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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 mmc tree
On Tue, April 22, 2014, Stephen Rothwell wrote: Hi Chris, After merging the mmc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/net/wireless/rsi/rsi_91x_sdio.c: In function 'rsi_reset_card': drivers/net/wireless/rsi/rsi_91x_sdio.c:288:20: error: 'MMC_STATE_HIGHSPEED' undeclared (first use in this function) card-state = ~MMC_STATE_HIGHSPEED; ^ drivers/net/wireless/rsi/rsi_91x_sdio.c:288:20: note: each undeclared identifier is reported only once for each function it appears in drivers/net/wireless/rsi/rsi_91x_sdio.c:299:4: error: implicit declaration of function 'mmc_card_set_highspeed' [-Werror=implicit-function-declaration] mmc_card_set_highspeed(card); ^ drivers/net/wireless/rsi/rsi_91x_sdio.c:306:2: error: implicit declaration of function 'mmc_card_highspeed' [-Werror=implicit-function-declaration] if (mmc_card_highspeed(card)) ^ Caused by commit 395784826a81 (mmc: drop the speed mode of card's state). I have used the version of the mmc tree from next-20140417 for today. I didn't detect usage out of mmc-sub for that. Let me fix and send a patch. Thanks, Seungwon Jeon -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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 2/2] dt: platform driver: Fill the resources before probe and defer if needed
* Tony Lindgren t...@atomide.com [140421 20:06]:
* Tony Lindgren t...@atomide.com [140421 13:26]:
* Rob Herring robherri...@gmail.com [140421 12:01]:
Something like this is what you had in mind?
...
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -400,6 +400,26 @@ int of_irq_to_resource(struct device_node *dev, int
index, struct resource *r)
EXPORT_SYMBOL_GPL(of_irq_to_resource);
/**
+ * of_irq_get - Decode a node's IRQ and return it as a Linux irq number
+ * @dev: pointer to device tree node
+ * @index: zero-based index of the irq
+ *
+ * Returns Linux irq number on success, or -EPROBE_DEFER if the irq
domain
+ * is not yet created.
+ *
+ */
+int of_irq_get(struct device_node *dev, int index)
+{
+ int irq = irq_of_parse_and_map(dev, index);
+
+ if (!irq of_find_irq_domain(dev, index) == NULL)
+ return -EPROBE_DEFER;
+
+ return irq;
+}
Yeah something like that. That might also work as a pretty
minimal fix as long as we fix the known broken drivers to use
platform_get_irq().
Actually, the above code for of_irq_get() won't help as we're still
calling irq_of_parse_and_map() before we should. So the nasty warnings
are still there if the irqdomain is not yet found.
OK so to fix the warning part of the problem we first need to not
try to map uninitialized irqdomains and then downgrade the current
warning to a dev_dbg.
So looks like the current minimal fix to my original problem the
first patch from Jean-Jacques in this series, and the following patch.
This works for drivers that currently do of_irq_parse_and_map(),
then your patch is also needed to make things work properly with
platform_get_irq().
8 --
From: Tony Lindgren t...@atomide.com
Date: Mon, 21 Apr 2014 19:33:43 -0700
Subject: [PATCH] of/platform: Fix no irq domain found errors when populating
interrupts
Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:
irq: no irq domain found for /ocp/pinmux@48002030 !
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171
of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically, so
let's fix up the issue by populating the interrupt resources at the
driver probe time instead.
Let's fix the problem by using of_find_irq_domain() recently introduced
by Jean-Jacques Hiblot jjhib...@traphandler.com. This way we can
avoid calling irq_of_parse_and_map() unnecesssarily with incomplete
data.
And then we also need to accept the fact that some irqdomains do not
exist that early on, and only get initialized later on. So we can
make the current WARN_ON into just into a pr_debug().
Note that this patch only solves the problem for drivers that are
currently doing of_irq_parse_and_map(). A follow-up patch is needed
to make platform_get_irq() to work without relying on the populated
resources.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -425,13 +425,17 @@ int of_irq_count(struct device_node *dev)
int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
int nr_irqs)
{
- int i;
+ int i, found = 0;
- for (i = 0; i nr_irqs; i++, res++)
+ for (i = 0; i nr_irqs; i++, res++) {
+ if (!of_find_irq_domain(dev, i))
+ continue;
if (!of_irq_to_resource(dev, i, res))
break;
+ found++;
+ }
- return i;
+ return found;
}
EXPORT_SYMBOL_GPL(of_irq_to_resource_table);
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -168,7 +168,9 @@ struct platform_device *of_device_alloc(struct device_node
*np,
rc = of_address_to_resource(np, i, res);
WARN_ON(rc);
}
- WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+ if (of_irq_to_resource_table(np, res, num_irq) != num_irq)
+ pr_debug(not all legacy IRQ resources mapped for %s\n,
+np-name);
}
dev-dev.of_node = of_node_get(np);
--
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: kaslr relocation incompitable with kernel loaded high
On Mon, Apr 21, 2014 at 8:16 PM, WANG Chao chaow...@redhat.com wrote:
On 04/21/14 at 11:01am, Kees Cook wrote:
On Mon, Apr 21, 2014 at 10:56 AM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao chaow...@redhat.com wrote:
Hi, Kees
When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded
high, it doesn't boot.
I reserved 128M memory at high with kernel cmdline
crashkernel=128M,high crashkernel=0,low, and for which I got:
[0.00] Reserving 128MB of memory at 6896MB for crashkernel
(System RAM: 6013MB)
Then I load kdump kernel into the reserved memory region, using a local
modified kexec-tools which is passing e820 in boot_params.
The e820 map of system RAM passed to 2nd kernel:
E820 memmap (of RAM):
1000-0009e3ff (1)
0001af00-0001b6f5dfff (1)
0001b6fff400-0001b6ff (1)
In which, 2nd kernel is loaded at 0x1b500.
After triggerred a system crash, 2nd kernel doesn't boot even with
nokaslr cmdline:
# echo c /proc/sysrq-trigger
[..]
I'm in purgatory
early console in decompress_kernel
KASLR disabled...
Decompressing Linux... Parsing ELF... Performing relocations...
32-bit relocation outside of kernel!
Interesting, when kernel get at early console in decompress_kernel
kernel already in 64 bit...
what does it mean 32-bit relocation outside of kernel ?
why 32-bit is involved ?
The 64-bit kernel has both 64 and 32 bit relocations (there are two
tables at the end of the kernel image). The error means that the
resulting relocation is believed to be outside the kernel image:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/compressed/misc.c#n283
Which means there is likely something wrong with this calculation in
your situation:
/*
* Calculate the delta between where vmlinux was linked to load
* and where it was actually loaded.
*/
delta = min_addr - LOAD_PHYSICAL_ADDR;
Probably.
Please check attached that patch that will solve nokaslr.
Somehow I got KASLR could not find suitable E820 region...
so i only have No relocation needed
will check that later.
---
arch/x86/boot/compressed/misc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/x86/boot/compressed/misc.c
===
--- linux-2.6.orig/arch/x86/boot/compressed/misc.c
+++ linux-2.6/arch/x86/boot/compressed/misc.c
@@ -235,8 +235,9 @@ static void error(char *x)
asm(hlt);
}
-#if CONFIG_X86_NEED_RELOCS
-static void handle_relocations(void *output, unsigned long output_len)
+#ifdef CONFIG_X86_NEED_RELOCS
+static void handle_relocations(void *output_orig, void *output,
+ unsigned long output_len)
{
int *reloc;
unsigned long delta, map, ptr;
@@ -247,7 +248,7 @@ static void handle_relocations(void *out
* Calculate the delta between where vmlinux was linked to load
* and where it was actually loaded.
*/
- delta = min_addr - LOAD_PHYSICAL_ADDR;
+ delta = min_addr - (unsigned long)output_orig;
if (!delta) {
debug_putstr(No relocation needed... );
return;
@@ -304,7 +305,8 @@ static void handle_relocations(void *out
#endif
}
#else
-static inline void handle_relocations(void *output, unsigned long output_len)
+static inline void handle_relocations(void *output_orig, void *output,
+ unsigned long output_len)
{ }
#endif
@@ -365,6 +367,8 @@ asmlinkage void *decompress_kernel(void
unsigned char *output,
unsigned long output_len)
{
+ unsigned char *output_orig = output;
+
real_mode = rmode;
sanitize_boot_params(real_mode);
@@ -417,7 +421,7 @@ asmlinkage void *decompress_kernel(void
debug_putstr(... );
decompress(input_data, input_len, NULL, NULL, output, NULL, error);
parse_elf(output);
- handle_relocations(output, output_len);
+ handle_relocations(output_orig, output, output_len);
debug_putstr(done.\nBooting the kernel.\n);
return output;
}
Re: [tip:locking/core] arch,avr32: Convert smp_mb__*()
* Hans-Christian Egtvedt egtv...@samfundet.no wrote: Around Fri 18 Apr 2014 06:05:23 -0700 or thereabout, tip-bot for Peter Zijlstra wrote: Commit-ID: 710adaa913169d7183cdf0de41c2a349101ff615 Gitweb: http://git.kernel.org/tip/710adaa913169d7183cdf0de41c2a349101ff615 Author: Peter Zijlstra pet...@infradead.org AuthorDate: Thu, 13 Mar 2014 19:00:37 +0100 Committer: Ingo Molnar mi...@kernel.org CommitDate: Fri, 18 Apr 2014 11:40:33 +0200 arch,avr32: Convert smp_mb__*() AVR32's mb() implementation is a compiler barrier(), therefore it all doesn't matter, fully rely on whatever asm-generic/barrier.h generates. Thanks for cleaning, would this go in through some tip-tree? Or would you prefer if I added it to my for-linus branch? Yeah, the plan would be for this to go via the locking tree (tip:locking/core), for v3.16 - together with similar patches for other architectures. Thanks, Ingo -- 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] cpufreq: Make linux...@vger.kernel.org official mailing list
There have been confusion all the time about which mailing list to follow for cpufreq activities, linux...@vger.kernel.org or cpuf...@vger.kernel.org. As Maintainers always wanted people to send patches to linux...@vger.kernel.org and kernel source asked them to use cpuf...@vger.kernel.org. Lets make linux...@vger.kernel.org the official mailing list for cpufreq stuff and remove all references of cpuf...@vger.kernel.org from kernel source. Later, we can remove the list as well from vger.kernel.org. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- Documentation/ABI/testing/sysfs-devices-system-cpu | 4 ++-- Documentation/cpu-freq/index.txt | 4 ++-- MAINTAINERS | 2 -- drivers/cpufreq/speedstep-centrino.c | 2 +- tools/power/cpupower/Makefile| 2 +- tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c | 2 +- 6 files changed, 7 insertions(+), 9 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index d5a0d33..acb9bfc 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -128,7 +128,7 @@ Description:Discover cpuidle policy and mechanism What: /sys/devices/system/cpu/cpu#/cpufreq/* Date: pre-git history -Contact: cpuf...@vger.kernel.org +Contact: linux...@vger.kernel.org Description: Discover and change clock speed of CPUs Clock scaling allows you to change the clock speed of the @@ -146,7 +146,7 @@ Description:Discover and change clock speed of CPUs What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus Date: June 2013 -Contact: cpuf...@vger.kernel.org +Contact: linux...@vger.kernel.org Description: Discover CPUs in the same CPU frequency coordination domain freqdomain_cpus is the list of CPUs (online+offline) that share diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt index 3d0b915..dc024ab 100644 --- a/Documentation/cpu-freq/index.txt +++ b/Documentation/cpu-freq/index.txt @@ -35,8 +35,8 @@ Mailing List There is a CPU frequency changing CVS commit and general list where you can report bugs, problems or submit patches. To post a message, -send an email to cpuf...@vger.kernel.org, to subscribe go to -http://vger.kernel.org/vger-lists.html#cpufreq and follow the +send an email to linux...@vger.kernel.org, to subscribe go to +http://vger.kernel.org/vger-lists.html#linux-pm and follow the instructions there. Links diff --git a/MAINTAINERS b/MAINTAINERS index 6dc67b1..88b60d9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2415,7 +2415,6 @@ F:drivers/net/ethernet/ti/cpmac.c CPU FREQUENCY DRIVERS M: Rafael J. Wysocki r...@rjwysocki.net M: Viresh Kumar viresh.ku...@linaro.org -L: cpuf...@vger.kernel.org L: linux...@vger.kernel.org S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git @@ -2426,7 +2425,6 @@ F:include/linux/cpufreq.h CPU FREQUENCY DRIVERS - ARM BIG LITTLE M: Viresh Kumar viresh.ku...@linaro.org M: Sudeep Holla sudeep.ho...@arm.com -L: cpuf...@vger.kernel.org L: linux...@vger.kernel.org W: http://www.arm.com/products/processors/technologies/biglittleprocessing.php S: Maintained diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speedstep-centrino.c index 6723f03..7d4a315 100644 --- a/drivers/cpufreq/speedstep-centrino.c +++ b/drivers/cpufreq/speedstep-centrino.c @@ -28,7 +28,7 @@ #include asm/cpu_device_id.h #define PFXspeedstep-centrino: -#define MAINTAINER cpuf...@vger.kernel.org +#define MAINTAINER linux...@vger.kernel.org #define INTEL_MSR_RANGE(0x) diff --git a/tools/power/cpupower/Makefile b/tools/power/cpupower/Makefile index cbfec92..3651db7 100644 --- a/tools/power/cpupower/Makefile +++ b/tools/power/cpupower/Makefile @@ -62,7 +62,7 @@ LIB_MAJ= 0.0.0 LIB_MIN= 0 PACKAGE = cpupower -PACKAGE_BUGREPORT =cpuf...@vger.kernel.org +PACKAGE_BUGREPORT =linux...@vger.kernel.org LANGUAGES =de fr it cs pt diff --git a/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c b/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c index 0f10b81..5224ee5 100644 --- a/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c +++ b/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c @@ -18,7 +18,7 @@ * 5.) if the third value, diff_pmtmr, changes between 2. and 4., the * TSC-based delay routine on the Linux kernel does not correctly * handle the cpufreq transition. Please report this to - * cpuf...@vger.kernel.org + * linux...@vger.kernel.org */ #include linux/kernel.h --
[PATCH RESEND] fs/bio.c: remove nr_segs (unused function parameter)
nr_segs is no longer used in bio_alloc_map_data since
c8db444820a1e3 (block: Don't save/copy bvec array anymore)
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Fabian Frederick f...@skynet.be
---
fs/bio.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/bio.c b/fs/bio.c
index 6f0362b..bd39c5b 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -1011,8 +1011,7 @@ static void bio_set_map_data(struct bio_map_data *bmd,
struct bio *bio,
bio-bi_private = bmd;
}
-static struct bio_map_data *bio_alloc_map_data(int nr_segs,
- unsigned int iov_count,
+static struct bio_map_data *bio_alloc_map_data(unsigned int iov_count,
gfp_t gfp_mask)
{
if (iov_count UIO_MAXIOV)
@@ -1154,7 +1153,7 @@ struct bio *bio_copy_user_iov(struct request_queue *q,
if (offset)
nr_pages++;
- bmd = bio_alloc_map_data(nr_pages, iov_count, gfp_mask);
+ bmd = bio_alloc_map_data(iov_count, gfp_mask);
if (!bmd)
return ERR_PTR(-ENOMEM);
--
1.8.4.5
--
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] mbcache: LLVMLinux: Remove double calculation from mbcache
From: Mark Charlebois charl...@gmail.com The call to __builtin_log2 presumes there is a double log2(double x) function defined in the kernel. The call to hash_log is a call to hash_64 which is defined in include/linux/hash.h static __always_inline u64 hash_64(u64 val, unsigned int bits) That means that __builtin_log2(NR_BG_LOCKS) is converting NR_BG_LOCKS to a double and returning a double and then that is converted to an unsigned int. Using ilog2 is much more appropriate and efficient. Another side effect of using __builtin_log2 is that is uses __aeabi_* functions for ARM that require linking with libgcc.a. Author: Mark Charlebois charl...@gmail.com Signed-off-by: Mark Charlebois charl...@gmail.com Signed-off-by: Behan Webster beh...@converseincode.com --- fs/mbcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/mbcache.c b/fs/mbcache.c index bf166e3..2c0752b 100644 --- a/fs/mbcache.c +++ b/fs/mbcache.c @@ -93,7 +93,7 @@ #define MB_CACHE_WRITER ((unsigned short)~0U 1) -#define MB_CACHE_ENTRY_LOCK_BITS __builtin_log2(NR_BG_LOCKS) +#define MB_CACHE_ENTRY_LOCK_BITS ilog2(NR_BG_LOCKS) #defineMB_CACHE_ENTRY_LOCK_INDEX(ce) \ (hash_long((unsigned long)ce, MB_CACHE_ENTRY_LOCK_BITS)) -- 1.8.3.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/
[PATCH RESEND] FS: Remove bs paramater in biovec_create_pool
bs is no longer used in biovec_create_pool
since 9f060e2231ca96
(block: Convert integrity to bvec_alloc_bs())
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Fabian Frederick f...@skynet.be
---
fs/bio-integrity.c | 2 +-
fs/bio.c| 4 ++--
include/linux/bio.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/bio-integrity.c b/fs/bio-integrity.c
index 1c2ce0c..9e24106 100644
--- a/fs/bio-integrity.c
+++ b/fs/bio-integrity.c
@@ -617,7 +617,7 @@ int bioset_integrity_create(struct bio_set *bs, int
pool_size)
if (!bs-bio_integrity_pool)
return -1;
- bs-bvec_integrity_pool = biovec_create_pool(bs, pool_size);
+ bs-bvec_integrity_pool = biovec_create_pool(pool_size);
if (!bs-bvec_integrity_pool) {
mempool_destroy(bs-bio_integrity_pool);
return -1;
diff --git a/fs/bio.c b/fs/bio.c
index 6f0362b..13a4fab 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -1859,7 +1859,7 @@ EXPORT_SYMBOL_GPL(bio_trim);
* create memory pools for biovec's in a bio_set.
* use the global biovec slabs created for general use.
*/
-mempool_t *biovec_create_pool(struct bio_set *bs, int pool_entries)
+mempool_t *biovec_create_pool(int pool_entries)
{
struct biovec_slab *bp = bvec_slabs + BIOVEC_MAX_IDX;
@@ -1922,7 +1922,7 @@ struct bio_set *bioset_create(unsigned int pool_size,
unsigned int front_pad)
if (!bs-bio_pool)
goto bad;
- bs-bvec_pool = biovec_create_pool(bs, pool_size);
+ bs-bvec_pool = biovec_create_pool(pool_size);
if (!bs-bvec_pool)
goto bad;
diff --git a/include/linux/bio.h b/include/linux/bio.h
index bba5508..5a64576 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -333,7 +333,7 @@ static inline struct bio *bio_next_split(struct bio *bio,
int sectors,
extern struct bio_set *bioset_create(unsigned int, unsigned int);
extern void bioset_free(struct bio_set *);
-extern mempool_t *biovec_create_pool(struct bio_set *bs, int pool_entries);
+extern mempool_t *biovec_create_pool(int pool_entries);
extern struct bio *bio_alloc_bioset(gfp_t, int, struct bio_set *);
extern void bio_put(struct bio *);
--
1.8.4.5
--
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/
[Bugfix] sched: fix possible invalid memory access caused by CPU hot-addition
When calling kzalloc_node(size, flags, node), we should first check
whether node is onlined, otherwise it may cause invalid memory access
as below.
[ 3663.324476] BUG: unable to handle kernel paging request at 1f08
[ 3663.332348] IP: [81172219] __alloc_pages_nodemask+0xb9/0x2d0
[ 3663.339719] PGD 82fe10067 PUD 82ebef067 PMD 0
[ 3663.344773] Oops: [#1] SMP
[ 3663.348455] Modules linked in: shpchp gpio_ich x86_pkg_temp_thermal
intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper
cryptd microcode joydev sb_edac edac_core lpc_ich ipmi_si tpm_tis
ipmi_msghandler ioatdma wmi acpi_pad mac_hid lp parport ixgbe isci mpt2sas dca
ahci ptp libsas libahci raid_class pps_core scsi_transport_sas mdio hid_generic
usbhid hid
[ 3663.394393] CPU: 61 PID: 2416 Comm: cron Tainted: GW3.14.0-rc5+
#21
[ 3663.402643] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRIVTIN1.86B.0047.F03.1403031049 03/03/2014
[ 3663.414299] task: 88082fe54b00 ti: 880845fba000 task.ti:
880845fba000
[ 3663.422741] RIP: 0010:[81172219] [81172219]
__alloc_pages_nodemask+0xb9/0x2d0
[ 3663.432857] RSP: 0018:880845fbbcd0 EFLAGS: 00010246
[ 3663.439265] RAX: 1f00 RBX: RCX:
[ 3663.447291] RDX: RSI: 0a8d RDI: 81a8d950
[ 3663.455318] RBP: 880845fbbd58 R08: 880823293400 R09: 0001
[ 3663.463345] R10: 0001 R11: R12: 002052d0
[ 3663.471363] R13: 880854c07600 R14: 0002 R15:
[ 3663.479389] FS: 7f2e8b99e800() GS:88105a40()
knlGS:
[ 3663.488514] CS: 0010 DS: ES: CR0: 80050033
[ 3663.495018] CR2: 1f08 CR3: 0008237b1000 CR4: 001407e0
[ 3663.503476] Stack:
[ 3663.505757] 811bd74d 880854c01d98 880854c01df0
880854c01dd0
[ 3663.514167] 0003208ca420 00075a5d84d0 88082fe54b00
811bb35f
[ 3663.522567] 880854c07600 0003 1f00
880845fbbd48
[ 3663.530976] Call Trace:
[ 3663.533753] [811bd74d] ? deactivate_slab+0x41d/0x4f0
[ 3663.540421] [811bb35f] ? new_slab+0x3f/0x2d0
[ 3663.546307] [811bb3c5] new_slab+0xa5/0x2d0
[ 3663.552001] [81768c97] __slab_alloc+0x35d/0x54a
[ 3663.558185] [810a4845] ? local_clock+0x25/0x30
[ 3663.564686] [8177a34c] ? __do_page_fault+0x4ec/0x5e0
[ 3663.571356] [810b0054] ? alloc_fair_sched_group+0xc4/0x190
[ 3663.578609] [810c77f1] ? __raw_spin_lock_init+0x21/0x60
[ 3663.585570] [811be476] kmem_cache_alloc_node_trace+0xa6/0x1d0
[ 3663.593112] [810b0054] ? alloc_fair_sched_group+0xc4/0x190
[ 3663.600363] [810b0054] alloc_fair_sched_group+0xc4/0x190
[ 3663.607423] [810a359f] sched_create_group+0x3f/0x80
[ 3663.613994] [810b611f] sched_autogroup_create_attach+0x3f/0x1b0
[ 3663.621732] [8108258a] sys_setsid+0xea/0x110
[ 3663.628020] [8177f42d] system_call_fastpath+0x1a/0x1f
[ 3663.634780] Code: 00 44 89 e7 e8 b9 f8 f4 ff 41 f6 c4 10 74 18 31 d2 be 8d
0a 00 00 48 c7 c7 50 d9 a8 81 e8 70 6a f2 ff e8 db dd 5f 00 48 8b 45 c8 48 83
78 08 00 0f 84 b5 01 00 00 48 83 c0 08 44 89 75 c0 4d 89
[ 3663.657032] RIP [81172219] __alloc_pages_nodemask+0xb9/0x2d0
[ 3663.664491] RSP 880845fbbcd0
[ 3663.668429] CR2: 1f08
[ 3663.672659] ---[ end trace df13f08ed9de18ad ]---
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
kernel/sched/fair.c | 12 +++-
kernel/sched/rt.c | 11 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7e9bd0b1fa9e..1c093d213b0f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7485,7 +7485,7 @@ int alloc_fair_sched_group(struct task_group *tg, struct
task_group *parent)
{
struct cfs_rq *cfs_rq;
struct sched_entity *se;
- int i;
+ int i, nid;
tg-cfs_rq = kzalloc(sizeof(cfs_rq) * nr_cpu_ids, GFP_KERNEL);
if (!tg-cfs_rq)
@@ -7499,13 +7499,15 @@ int alloc_fair_sched_group(struct task_group *tg,
struct task_group *parent)
init_cfs_bandwidth(tg_cfs_bandwidth(tg));
for_each_possible_cpu(i) {
- cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
- GFP_KERNEL, cpu_to_node(i));
+ nid = cpu_to_node(i);
+ if (nid != NUMA_NO_NODE !node_online(nid))
+ nid = NUMA_NO_NODE;
+
+ cfs_rq = kzalloc_node(sizeof(struct cfs_rq), GFP_KERNEL, nid);
if (!cfs_rq)
goto err;
- se = kzalloc_node(sizeof(struct sched_entity),
- GFP_KERNEL, cpu_to_node(i));
[PATCH RESEND] fs/aio.c: Remove ctx parameter in kiocb_cancel
ctx is no longer used in kiocb_cancel since
57282d8fd74407 (aio: Kill ki_users)
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Fabian Frederick f...@skynet.be
---
fs/aio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 12a3de0e..b92fdee 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -472,7 +472,7 @@ void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn
*cancel)
}
EXPORT_SYMBOL(kiocb_set_cancel_fn);
-static int kiocb_cancel(struct kioctx *ctx, struct kiocb *kiocb)
+static int kiocb_cancel(struct kiocb *kiocb)
{
kiocb_cancel_fn *old, *cancel;
@@ -529,7 +529,7 @@ static void free_ioctx_users(struct percpu_ref *ref)
struct kiocb, ki_list);
list_del_init(req-ki_list);
- kiocb_cancel(ctx, req);
+ kiocb_cancel(req);
}
spin_unlock_irq(ctx-ctx_lock);
@@ -1559,7 +1559,7 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, struct
iocb __user *, iocb,
kiocb = lookup_kiocb(ctx, iocb, key);
if (kiocb)
- ret = kiocb_cancel(ctx, kiocb);
+ ret = kiocb_cancel(kiocb);
else
ret = -EINVAL;
--
--
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] blk-cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
block/blk-cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index e4a4145..941bbc8 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -912,6 +912,7 @@ struct cgroup_subsys blkio_cgrp_subsys = {
.css_free = blkcg_css_free,
.can_attach = blkcg_can_attach,
.base_cftypes = blkcg_files,
+ .early_init = 0,
};
EXPORT_SYMBOL_GPL(blkio_cgrp_subsys);
--
2.0.0-rc0
--
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] cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
kernel/cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 559f822..f23cb67 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -5325,5 +5325,6 @@ struct cgroup_subsys debug_cgrp_subsys = {
.css_alloc = debug_css_alloc,
.css_free = debug_css_free,
.base_cftypes = debug_files,
+ .early_init = 0,
};
#endif /* CONFIG_CGROUP_DEBUG */
--
2.0.0-rc0
--
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] perf-event/cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
kernel/events/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f83a71a..b3a8916 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8062,5 +8062,6 @@ struct cgroup_subsys perf_event_cgrp_subsys = {
.css_free = perf_cgroup_css_free,
.exit = perf_cgroup_exit,
.attach = perf_cgroup_attach,
+ .early_init = 0,
};
#endif /* CONFIG_CGROUP_PERF */
--
2.0.0-rc0
--
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: kaslr relocation incompitable with kernel loaded high
On 04/21/14 at 09:58pm, Yinghai Lu wrote:
On Mon, Apr 21, 2014 at 8:16 PM, WANG Chao chaow...@redhat.com wrote:
On 04/21/14 at 11:01am, Kees Cook wrote:
On Mon, Apr 21, 2014 at 10:56 AM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao chaow...@redhat.com wrote:
Hi, Kees
When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded
high, it doesn't boot.
I reserved 128M memory at high with kernel cmdline
crashkernel=128M,high crashkernel=0,low, and for which I got:
[0.00] Reserving 128MB of memory at 6896MB for crashkernel
(System RAM: 6013MB)
Then I load kdump kernel into the reserved memory region, using a local
modified kexec-tools which is passing e820 in boot_params.
The e820 map of system RAM passed to 2nd kernel:
E820 memmap (of RAM):
1000-0009e3ff (1)
0001af00-0001b6f5dfff (1)
0001b6fff400-0001b6ff (1)
In which, 2nd kernel is loaded at 0x1b500.
After triggerred a system crash, 2nd kernel doesn't boot even with
nokaslr cmdline:
# echo c /proc/sysrq-trigger
[..]
I'm in purgatory
early console in decompress_kernel
KASLR disabled...
Decompressing Linux... Parsing ELF... Performing relocations...
32-bit relocation outside of kernel!
Interesting, when kernel get at early console in decompress_kernel
kernel already in 64 bit...
what does it mean 32-bit relocation outside of kernel ?
why 32-bit is involved ?
The 64-bit kernel has both 64 and 32 bit relocations (there are two
tables at the end of the kernel image). The error means that the
resulting relocation is believed to be outside the kernel image:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/compressed/misc.c#n283
Which means there is likely something wrong with this calculation in
your situation:
/*
* Calculate the delta between where vmlinux was linked to load
* and where it was actually loaded.
*/
delta = min_addr - LOAD_PHYSICAL_ADDR;
Probably.
Please check attached that patch that will solve nokaslr.
Somehow I got KASLR could not find suitable E820 region...
so i only have No relocation needed
I think it makes sense. If output from choose_kernel_location() doesn't
change (output == output_orig), we shouldn't call relocation code.
There are two situations that makes output == output_orig:
- nokaslr case
- KASLR could not find suitable E820 region case.
will check that later.
---
arch/x86/boot/compressed/misc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/x86/boot/compressed/misc.c
===
--- linux-2.6.orig/arch/x86/boot/compressed/misc.c
+++ linux-2.6/arch/x86/boot/compressed/misc.c
@@ -235,8 +235,9 @@ static void error(char *x)
asm(hlt);
}
-#if CONFIG_X86_NEED_RELOCS
-static void handle_relocations(void *output, unsigned long output_len)
+#ifdef CONFIG_X86_NEED_RELOCS
+static void handle_relocations(void *output_orig, void *output,
+unsigned long output_len)
{
int *reloc;
unsigned long delta, map, ptr;
@@ -247,7 +248,7 @@ static void handle_relocations(void *out
* Calculate the delta between where vmlinux was linked to load
* and where it was actually loaded.
*/
- delta = min_addr - LOAD_PHYSICAL_ADDR;
+ delta = min_addr - (unsigned long)output_orig;
if (!delta) {
debug_putstr(No relocation needed... );
return;
@@ -304,7 +305,8 @@ static void handle_relocations(void *out
#endif
}
#else
-static inline void handle_relocations(void *output, unsigned long output_len)
+static inline void handle_relocations(void *output_orig, void *output,
+ unsigned long output_len)
{ }
#endif
@@ -365,6 +367,8 @@ asmlinkage void *decompress_kernel(void
unsigned char *output,
unsigned long output_len)
{
+ unsigned char *output_orig = output;
+
real_mode = rmode;
sanitize_boot_params(real_mode);
@@ -417,7 +421,7 @@ asmlinkage void *decompress_kernel(void
debug_putstr(... );
decompress(input_data, input_len, NULL, NULL, output, NULL, error);
parse_elf(output);
- handle_relocations(output, output_len);
+ handle_relocations(output_orig, output, output_len);
debug_putstr(done.\nBooting the kernel.\n);
return output;
}
Thanks for the patch, it works for me :)
I also have a draft patch with the same idea as Yinghai. But I take a
slightly different approach:
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 1768461..7f392a8 100644
--- a/arch/x86/boot/compressed/misc.c
+++
[PATCH] hugetlb_cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
mm/hugetlb_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 595d7fd..b5368f8 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -405,4 +405,5 @@ struct cgroup_subsys hugetlb_cgrp_subsys = {
.css_alloc = hugetlb_cgroup_css_alloc,
.css_offline= hugetlb_cgroup_css_offline,
.css_free = hugetlb_cgroup_css_free,
+ .early_init = 0,
};
--
2.0.0-rc0
--
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: ftrace/kprobes: Warning when insmod two modules
(2014/04/22 12:51), Rusty Russell wrote: Steven Rostedt rost...@goodmis.org writes: On Mon, 24 Mar 2014 20:26:05 +0900 Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote: Thank you for reporting with this pretty backtrace :) Steven, I think this is not the kprobe bug but ftrace (and perhaps, module). Looks to be more of a module issue than a ftrace issue. If the ftrace can set loading module text read only before the module subsystem expected, I think it should be protected by the module subsystem itself (e.g. set_all_modules_text_ro(rw) skips the modules which is MODULE_STATE_COMING) Does this patch fix it? In-review-off-by: Steven Rostedt rost...@goodmis.org Sorry, was on paternity leave. I'm always nervous about adding more states, since every place which examines the state has to be audited. We set the mod-state to MOD_STATE_COMING in complete_formation; why don't we set NX there instead? It also makes more sense to set NX before we hit parse_args() which can execute code in the module. In fact, we should probably call the notifier there too, so people can breakpoint/tracepoint/etc parameter calls. Of course, this means that we set NX before the notifier; does anything break? This does not work. ftrace_process_locs() is called from the notifier, and it tries to change its text like this. load_module blocking_notifier_call_chain ftrace_module_notify_enter ftrace_init_module ftrace_process_locs sort ftrace_swap_ips But the text is already RO, so it causes panic. We need to call notifier before setting it RO. Or should we unset RO temporarily in ftrace_process_locs()? Thanks, Takao Indoh Subject: module: set nx before marking module MODULE_STATE_COMING. This prevents a WARN_ON() where ftrace calls set_all_modules_text_ro() which races with the module setting its own set_section_ro_nx(). It also means we're NX protected before we call parse_args(), which can execute module code. This means that the notifiers will be called on a module which is already NX, so that may cause problems. Signed-off-by: Rusty Russell ru...@rustcorp.com.au diff --git a/kernel/module.c b/kernel/module.c index 11869408f79b..83a437e5d429 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -3023,21 +3023,6 @@ static int do_init_module(struct module *mod) */ current-flags = ~PF_USED_ASYNC; - blocking_notifier_call_chain(module_notify_list, - MODULE_STATE_COMING, mod); - - /* Set RO and NX regions for core */ - set_section_ro_nx(mod-module_core, - mod-core_text_size, - mod-core_ro_size, - mod-core_size); - - /* Set RO and NX regions for init */ - set_section_ro_nx(mod-module_init, - mod-init_text_size, - mod-init_ro_size, - mod-init_size); - do_mod_ctors(mod); /* Start the module */ if (mod-init != NULL) @@ -3168,9 +3153,26 @@ static int complete_formation(struct module *mod, struct load_info *info) /* This relies on module_mutex for list integrity. */ module_bug_finalize(info-hdr, info-sechdrs, mod); + /* Set RO and NX regions for core */ + set_section_ro_nx(mod-module_core, + mod-core_text_size, + mod-core_ro_size, + mod-core_size); + + /* Set RO and NX regions for init */ + set_section_ro_nx(mod-module_init, + mod-init_text_size, + mod-init_ro_size, + mod-init_size); + /* Mark state as coming so strong_try_module_get() ignores us, * but kallsyms etc. can see us. */ mod-state = MODULE_STATE_COMING; + mutex_unlock(module_mutex); + + blocking_notifier_call_chain(module_notify_list, + MODULE_STATE_COMING, mod); + return 0; out: mutex_unlock(module_mutex); -- 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] netclassid_cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
net/core/netclassid_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/netclassid_cgroup.c b/net/core/netclassid_cgroup.c
index 22931e1..1b07dca 100644
--- a/net/core/netclassid_cgroup.c
+++ b/net/core/netclassid_cgroup.c
@@ -108,4 +108,5 @@ struct cgroup_subsys net_cls_cgrp_subsys = {
.css_free = cgrp_css_free,
.attach = cgrp_attach,
.base_cftypes = ss_files,
+ .early_init = 0,
};
--
2.0.0-rc0
--
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] netprio_cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
net/core/netprio_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 13ddd68..fc21035 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -250,6 +250,7 @@ struct cgroup_subsys net_prio_cgrp_subsys = {
.css_free = cgrp_css_free,
.attach = net_prio_attach,
.base_cftypes = ss_files,
+ .early_init = 0,
};
static int netprio_device_event(struct notifier_block *unused,
--
2.0.0-rc0
--
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] device_cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
security/device_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 8365909..dd9614f 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -688,6 +688,7 @@ struct cgroup_subsys devices_cgrp_subsys = {
.css_online = devcgroup_online,
.css_offline = devcgroup_offline,
.base_cftypes = dev_cgroup_files,
+ .early_init = 0,
};
/**
--
2.0.0-rc0
--
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/
[f2fs-dev][PATCH 1/2] f2fs: handle inline data independently in f2fs_bmap
We'd better handle inline data case independently in f2fs_bmap().
It can reduce our handling time in f2fs_bmap().
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 6b89b25..150c12a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1058,6 +1058,11 @@ static int f2fs_set_data_page_dirty(struct page *page)
static sector_t f2fs_bmap(struct address_space *mapping, sector_t block)
{
+ struct inode *inode = mapping-host;
+
+ if (f2fs_has_inline_data(inode))
+ return 0;
+
return generic_block_bmap(mapping, block, get_data_block);
}
--
1.7.9.5
--
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/
[f2fs-dev][PATCH 2/2] f2fs: introduce f2fs_seek_block to support SEEK_{DATA,HOLE} in llseek
In This patch we introduce f2fs_seek_block to support SEEK_{DATA,HOLE} of
lseek(2).
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/f2fs.h |6
fs/f2fs/file.c | 96 +++-
2 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 97da71d..b1d6699 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1074,6 +1074,12 @@ static inline void f2fs_stop_checkpoint(struct
f2fs_sb_info *sbi)
((is_inode_flag_set(F2FS_I(i), FI_ACL_MODE)) ? \
(F2FS_I(i)-i_acl_mode) : ((i)-i_mode))
+/* get offset of first page in next direct node */
+#define PGOFS_OF_NEXT_DNODE(pgofs, fi) \
+ ((pgofs ADDRS_PER_INODE(fi)) ? ADDRS_PER_INODE(fi) : \
+ (pgofs - ADDRS_PER_INODE(fi) + 2 * ADDRS_PER_BLOCK - 1) / \
+ ADDRS_PER_BLOCK * ADDRS_PER_BLOCK + ADDRS_PER_INODE(fi))
+
/*
* file.c
*/
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 60e7d54..da1c3b7 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -194,6 +194,100 @@ out:
return ret;
}
+static loff_t f2fs_seek_block(struct file *file, loff_t offset, int whence)
+{
+ struct inode *inode = file-f_mapping-host;
+ loff_t maxbytes = inode-i_sb-s_maxbytes;
+ struct dnode_of_data dn;
+ pgoff_t pgofs, end_offset, end;
+ loff_t data_ofs = 0, isize;
+ int err = 0;
+
+ mutex_lock(inode-i_mutex);
+
+ isize = i_size_read(inode);
+ if (offset = isize)
+ goto fail;
+
+ /* handle inline data case */
+ if (f2fs_has_inline_data(inode)) {
+ if (whence == SEEK_HOLE)
+ data_ofs = isize;
+ goto found;
+ }
+
+ pgofs = (pgoff_t)(offset PAGE_CACHE_SHIFT);
+ end = (pgoff_t)(isize PAGE_CACHE_SHIFT);
+
+ while (pgofs end) {
+ set_new_dnode(dn, inode, NULL, NULL, 0);
+ err = get_dnode_of_data(dn, pgofs, LOOKUP_NODE_RA);
+ if (err err != -ENOENT) {
+ goto fail;
+ } else if (err == -ENOENT) {
+ /* direct node is not exist */
+ if (whence == SEEK_DATA) {
+ pgofs = PGOFS_OF_NEXT_DNODE(pgofs,
+ F2FS_I(inode));
+ continue;
+ } else {
+ data_ofs = pgofs PAGE_CACHE_SHIFT;
+ goto found;
+ }
+ }
+
+ end_offset = IS_INODE(dn.node_page) ?
+ ADDRS_PER_INODE(F2FS_I(inode)) : ADDRS_PER_BLOCK;
+
+ /* find data/hole in dnode block */
+ for (; dn.ofs_in_node end_offset; dn.ofs_in_node++, pgofs++) {
+ block_t blkaddr;
+ blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
+
+ if ((whence == SEEK_DATA blkaddr != NULL_ADDR) ||
+ (whence == SEEK_HOLE blkaddr == NULL_ADDR)) {
+ f2fs_put_dnode(dn);
+ data_ofs = pgofs PAGE_CACHE_SHIFT;
+ goto found;
+ }
+ }
+ f2fs_put_dnode(dn);
+ }
+
+ data_ofs = pgofs PAGE_CACHE_SHIFT;
+ if (data_ofs isize) {
+ if (whence == SEEK_DATA)
+ goto fail;
+ else
+ data_ofs = isize;
+ }
+found:
+ mutex_unlock(inode-i_mutex);
+ return vfs_setpos(file, data_ofs, maxbytes);
+fail:
+ mutex_unlock(inode-i_mutex);
+ return -ENXIO;
+}
+
+static loff_t f2fs_llseek(struct file *file, loff_t offset, int whence)
+{
+ struct inode *inode = file-f_mapping-host;
+ loff_t maxbytes = inode-i_sb-s_maxbytes;
+
+ switch (whence) {
+ case SEEK_SET:
+ case SEEK_CUR:
+ case SEEK_END:
+ return generic_file_llseek_size(file, offset, whence,
+ maxbytes, i_size_read(inode));
+ case SEEK_DATA:
+ case SEEK_HOLE:
+ return f2fs_seek_block(file, offset, whence);
+ }
+
+ return -EINVAL;
+}
+
static int f2fs_file_mmap(struct file *file, struct vm_area_struct *vma)
{
file_accessed(file);
@@ -678,7 +772,7 @@ long f2fs_compat_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
#endif
const struct file_operations f2fs_file_operations = {
- .llseek = generic_file_llseek,
+ .llseek = f2fs_llseek,
.read = do_sync_read,
.write = do_sync_write,
.aio_read = generic_file_aio_read,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
[PATCH] x86: LLVMLinux: Wrap -mno-80387 with cc-option
From: Behan Webster beh...@converseincode.com Wrap -mno-80387 gcc options with cc-option so they don't break clang. Signed-off-by: Behan Webster beh...@converseincode.com --- arch/x86/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index d1b7c37..ce6ad7e 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -83,7 +83,9 @@ else KBUILD_CFLAGS += -m64 # Don't autogenerate traditional x87, MMX or SSE instructions -KBUILD_CFLAGS += -mno-mmx -mno-sse -mno-80387 -mno-fp-ret-in-387 +KBUILD_CFLAGS += -mno-mmx -mno-sse +KBUILD_CFLAGS += $(call cc-option,-mno-80387) +KBUILD_CFLAGS += $(call cc-option,-mno-fp-ret-in-387) # Use -mpreferred-stack-boundary=3 if supported. KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3) -- 1.8.3.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/
[PATCH] cgroup: use uninitialized_var() for may-be uninitialized variable
To suppress this warning:
warning: ‘err’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
int err;
^
Use the uninitialized_var() to decalre err. It also serves to be good
documetation.
Signed-off-by: Jianyu Zhan nasa4...@gmail.com
---
kernel/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 24675f5..930569c 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4144,7 +4144,7 @@ static int create_css(struct cgroup *cgrp, struct
cgroup_subsys *ss)
{
struct cgroup *parent = cgrp-parent;
struct cgroup_subsys_state *css;
- int err;
+ int uninitialized_var(err);
lockdep_assert_held(cgroup_mutex);
--
2.0.0-rc0
--
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/
min() and max() have warning: comparison of distinct pointer types lacks a cast
Hi all Have these warning messages when compiling kernel. Anyone know what's wrong? Regards. In file included from mm/readahead.c:10:0: mm/readahead.c: In function 'max_sane_readahead': include/linux/kernel.h:713:17: warning: comparison of distinct pointer types lacks a cast [enabled by default] (void) (_min1 == _min2); \ ^ mm/readahead.c:242:9: note: in expansion of macro 'min' return min(nr, MAX_READAHEAD); ^ --- mm/rmap.c:1279:22: note: in expansion of macro 'min' #define CLUSTER_SIZE min(32*PAGE_SIZE, PMD_SIZE) ^ mm/rmap.c:1280:25: note: in expansion of macro 'CLUSTER_SIZE' #define CLUSTER_MASK (~(CLUSTER_SIZE - 1)) ^ mm/rmap.c:1298:39: note: in expansion of macro 'CLUSTER_MASK' address = (vma-vm_start + cursor) CLUSTER_MASK; ^ -- 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: Ext4: deadlock occurs when running fsstress and ENOSPC errors are seen.
Hi Darrick,
Thanks for the reply, sorry for responding late.
On Wed, Apr 16, 2014 at 11:16 PM, Darrick J. Wong
darrick.w...@oracle.com wrote:
On Wed, Apr 16, 2014 at 01:21:34PM +0530, Amit Sahrawat wrote:
Sorry Ted, if it caused the confusion.
There were actually 2 parts to the problem, the logs in the first mail
were from the original situation – where in there were many block
groups and error prints also showed that.
EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1493, 0
clusters in bitmap, 58339 in gd
EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1000, 0
clusters in bitmap, 3 in gd
EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1425, 0
clusters in bitmap, 1 in gd
JBD2: Spotted dirty metadata buffer (dev = sda1, blocknr = 0). There's
a risk of filesystem corruption in case of system crash.
JBD2: Spotted dirty metadata buffer (dev = sda1, blocknr = 0). There's
a risk of filesystem corruption in case of system crash.
1)Original case – when the disk got corrupted and we only had the
logs and the hung task messages. But not the HDD on which issue was
observed.
2)In order to reproduce the problem as was coming through the logs
(which highlighted the problem in the bitmap corruption). To minimize
the environment and make a proper case, we created a smaller partition
size and with only 2 groups. And intentionally corrupted the group 1
(our intention was just to replicate the error scenario).
I'm assuming that the original broken fs simply had a corrupt block bitmap,
and
that the dd thing was just to simulate that corruption in a testing
environment?
Yes, we did so in order to replicate the error scenario.
3)After corruption we used ‘fsstress’ - we got the similar problem
as was coming the original logs. – We shared our analysis after this
point for looping in the writepages part the free blocks mismatch.
Hm. I tried it with 3.15-rc1 and didn't see any hangs. Corrupt bitmaps shut
down allocations from the block group and the FS continues, as expected.
We are using kernel version 3.8, so cannot switch to 3.15-rc1. It is a
limitation currently.
4)We came across ‘Darrick’ patches(in which it also mentioned about
how to corrupt to reproduce the problem) and applied on our
environment. It solved the initial problem about the looping in
writepages, but now we got hangs at other places.
There are hundreds of Darrick patches ... to which one are you referring? :)
(What was the subject line?)
ext4: error out if verifying the block bitmap fails
ext4: fix type declaration of ext4_validate_block_bitmap
ext4: mark block group as corrupt on block bitmap error
ext4: mark block group as corrupt on inode bitmap error
ext4: mark group corrupt on group descriptor checksum
ext4: don't count free clusters from a corrupt block group
So, the patches helps in marking the block group as corrupt and avoids
further allocation. But when we consider the normal write path using
write_begin. Since, there is mismatch between the free cluster count
from the group descriptor and the bitmap. In that case it marks the
pages dirty by copying dirty but later it get ENOSPC from the
writepages when it actually does the allocation.
So, our doubt is if we are marking the block group as corrupt, we
should also subtract the block group count from the
s_freeclusters_counter. This will make sure we have the valid
freecluster count and error ‘ENOSPC’ can be returned from the
write_begin, instead of propagating such paths till the writepages.
We made change like this:
@@ -737,14 +737,18 @@ void ext4_mb_generate_buddy(struct super_block *sb,
grp-bb_fragments = fragments;
if (free != grp-bb_free) {
+ struct ext4_sb_info *sbi = EXT4_SB(sb);
ext4_grp_locked_error(sb, group, 0, 0,
%u clusters in bitmap, %u in gd;
block bitmap corrupt.,
free, grp-bb_free);
/*
* If we intend to continue, we consider group descriptor
* corrupt and update bb_free using bitmap value
*/
+ percpu_counter_sub(sbi-s_freeclusters_counter, grp-bb_free);
grp-bb_free = free;
set_bit(EXT4_GROUP_INFO_BBITMAP_CORRUPT_BIT, grp-bb_state);
}
mb_set_largest_free_order(sb, grp);
Is this the correct method? Or are missing something in this? Please
share your opinion.
Using ‘tune2fs’ is not a viable solution in our case, we can only
provide the solution via. the kernel changes. So, we made the changes
as shared earlier.
Would it help if you could set errors=remount-ro in mke2fs?
Sorry, we cannot reformat or use tune2fs to change the ‘errors’ value.
--D
So the question isn't how the file system got corrupted, but that
you'd prefer that the system recovers without hanging after this
Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display
On Mon, Apr 21, 2014 at 10:34 PM, Ken Moffat zarniwh...@ntlworld.com wrote:
On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote:
[ resending, somehow lkml dropped out of the Cc. ]
On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote:
On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote:
Ken,
You might want to try reverting:
commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef
Author: Alex Deucher alexdeuc...@gmail.com
Date: Mon Apr 7 10:33:46 2014 -0400
drm/radeon/dp: switch to the common i2c over aux code
Provides a nice cleanup in radeon.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Christian König christian.koe...@amd.com
This fixed a similar problem here (see the drm pull thread for rc1)
Thanks
Ed Tomlinson
Tried reverting that from rc2, but it didn't help. Thanks anyway.
Well, I *believed* I had created a patch for that commit, and
reverted it from -rc2 with patch -R. But I've now bisected through
drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection
pointed to that same commit, so I guess I did something wrong.
There were a couple of other issues along the way (mounting nfs
hung on one commit, startx hung on several of the commits, but I've
marked those as good because I had a display, even if the system
was not usable).
I've now gone back to linus' tree that I cloned a few hours ago,
i.e.
commit c089b229dfdd09d59a11d8bc2344bf8196d575ce
Merge: 9ac03675010a 0565103d1adb
Author: Linus Torvalds torva...@linux-foundation.org
Date: Mon Apr 21 10:05:35 2014 -0700
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
created a branch, and *definitely* reverted
379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that
branch. And this version works fine.
So belatedly I see that I seem to have the same problem as Ed. Or
at least that the same commit is causing both our problems.
Alex - do you need any more information from me to help with this ?
The attached patch should fix it.
Thanks,
Alex
From 9cd764fd57bb2a4e5f618d0f8a64c8154a820688 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Tue, 22 Apr 2014 01:49:28 -0400
Subject: [PATCH] drm/radeon/aux: fix hpd assignment for aux bus
The hpd (hot plug detect) pin assignment got lost
in the conversion to to the common i2c over aux
code. Without this information, aux transactions
do not work properly. Fixes DP failures.
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/atombios_dp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index 1593652..bc0119f 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -209,6 +209,7 @@ void radeon_dp_aux_init(struct radeon_connector *radeon_connector)
{
int ret;
+ radeon_connector-ddc_bus-rec.hpd = radeon_connector-hpd.hpd;
radeon_connector-ddc_bus-aux.dev = radeon_connector-base.kdev;
radeon_connector-ddc_bus-aux.transfer = radeon_dp_aux_transfer;
ret = drm_dp_aux_register_i2c_bus(radeon_connector-ddc_bus-aux);
--
1.7.11.7
Re: [PATCH 3/3] cpufreq: ppc: Fix handling of non-existent clocks
On 17 April 2014 15:23, Geert Uytterhoeven wrote: > If the clock doesn't exist, clk_get_rate() returns -EINVAL You clk_get_rate() isn't written well then, it should return zero. @Mike: I didn't see this clearly mentioned in clk.h, should we fix that? >, which becomes > a large number (freq is u32), failing the "freq < min_cpufreq" test. > Explicitly test for "(u32)-EINVAL" to fix this. That's a bad check. We should have done this instead: (s32)freq < 0; but that would be true for high values of clock. And that's why clk_get_rate() must return zero for errors. > Update the comment, and fix a grammer issue while we're at it. > > Signed-off-by: Geert Uytterhoeven > --- > drivers/cpufreq/ppc-corenet-cpufreq.c |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c > b/drivers/cpufreq/ppc-corenet-cpufreq.c > index 53881d78a931..7027eab814ce 100644 > --- a/drivers/cpufreq/ppc-corenet-cpufreq.c > +++ b/drivers/cpufreq/ppc-corenet-cpufreq.c > @@ -179,10 +179,11 @@ static int corenet_cpufreq_cpu_init(struct > cpufreq_policy *policy) > clk = of_clk_get(data->parent, i); > freq = clk_get_rate(clk); > /* > -* the clock is valid if its frequency is not masked > -* and large than minimum allowed frequency. > +* the clock is valid if it exists, its frequency is not > +* masked, and larger than minimum allowed frequency. > */ > - if (freq < min_cpufreq || (mask & (1 << i))) > + if (freq == (u32)-EINVAL || freq < min_cpufreq || > + (mask & (1 << i))) > table[i].frequency = CPUFREQ_ENTRY_INVALID; > else > table[i].frequency = freq / 1000; > -- > 1.7.9.5 > -- 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 v2 02/10] drm/nouveau/bar/nvc0: support chips without BAR3
Adapt the NVC0 BAR driver to make it able to support chips that do not
expose a BAR3. When this happens, BAR1 is then used for USERD mapping
and the BAR alloc() functions is disabled, making GPU objects unable
to rely on BAR for data access and falling back to PRAMIN.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 114 +
1 file changed, 59 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
index 3f30db62e656..ca8139b9ab27 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c
@@ -30,14 +30,16 @@
#include "priv.h"
+struct nvc0_bar_priv_vm {
+ struct nouveau_gpuobj *mem;
+ struct nouveau_gpuobj *pgd;
+ struct nouveau_vm *vm;
+};
+
struct nvc0_bar_priv {
struct nouveau_bar base;
spinlock_t lock;
- struct {
- struct nouveau_gpuobj *mem;
- struct nouveau_gpuobj *pgd;
- struct nouveau_vm *vm;
- } bar[2];
+ struct nvc0_bar_priv_vm bar[2];
};
static int
@@ -79,87 +81,87 @@ nvc0_bar_unmap(struct nouveau_bar *bar, struct nouveau_vma
*vma)
}
static int
-nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
- struct nouveau_oclass *oclass, void *data, u32 size,
- struct nouveau_object **pobject)
+nvc0_bar_init_vm(struct nvc0_bar_priv *priv, struct nvc0_bar_priv_vm *bar_vm,
+int bar_nr)
{
- struct nouveau_device *device = nv_device(parent);
- struct nvc0_bar_priv *priv;
- struct nouveau_gpuobj *mem;
+ struct nouveau_device *device = nv_device(>base);
struct nouveau_vm *vm;
+ resource_size_t bar_len;
int ret;
- ret = nouveau_bar_create(parent, engine, oclass, );
- *pobject = nv_object(priv);
- if (ret)
- return ret;
-
- /* BAR3 */
ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x1000, 0, 0,
- >bar[0].mem);
- mem = priv->bar[0].mem;
+ _vm->mem);
if (ret)
return ret;
ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x8000, 0, 0,
- >bar[0].pgd);
+ _vm->pgd);
if (ret)
return ret;
- ret = nouveau_vm_new(device, 0, nv_device_resource_len(device, 3), 0,
);
+ bar_len = nv_device_resource_len(device, bar_nr);
+
+ ret = nouveau_vm_new(device, 0, bar_len, 0, );
if (ret)
return ret;
atomic_inc(>engref[NVDEV_SUBDEV_BAR]);
- ret = nouveau_gpuobj_new(nv_object(priv), NULL,
-(nv_device_resource_len(device, 3) >> 12) * 8,
-0x1000, NVOBJ_FLAG_ZERO_ALLOC,
->pgt[0].obj[0]);
- vm->pgt[0].refcount[0] = 1;
- if (ret)
- return ret;
+ /*
+* Bootstrap page table lookup.
+*/
+ if (bar_nr == 3) {
+ ret = nouveau_gpuobj_new(nv_object(priv), NULL,
+(bar_len >> 12) * 8, 0x1000,
+NVOBJ_FLAG_ZERO_ALLOC,
+ >pgt[0].obj[0]);
+ vm->pgt[0].refcount[0] = 1;
+ if (ret)
+ return ret;
+ }
- ret = nouveau_vm_ref(vm, >bar[0].vm, priv->bar[0].pgd);
+ ret = nouveau_vm_ref(vm, _vm->vm, bar_vm->pgd);
nouveau_vm_ref(NULL, , NULL);
if (ret)
return ret;
- nv_wo32(mem, 0x0200, lower_32_bits(priv->bar[0].pgd->addr));
- nv_wo32(mem, 0x0204, upper_32_bits(priv->bar[0].pgd->addr));
- nv_wo32(mem, 0x0208, lower_32_bits(nv_device_resource_len(device, 3) -
1));
- nv_wo32(mem, 0x020c, upper_32_bits(nv_device_resource_len(device, 3) -
1));
+ nv_wo32(bar_vm->mem, 0x0200, lower_32_bits(bar_vm->pgd->addr));
+ nv_wo32(bar_vm->mem, 0x0204, upper_32_bits(bar_vm->pgd->addr));
+ nv_wo32(bar_vm->mem, 0x0208, lower_32_bits(bar_len - 1));
+ nv_wo32(bar_vm->mem, 0x020c, upper_32_bits(bar_len - 1));
- /* BAR1 */
- ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x1000, 0, 0,
- >bar[1].mem);
- mem = priv->bar[1].mem;
- if (ret)
- return ret;
+ return 0;
+}
- ret = nouveau_gpuobj_new(nv_object(priv), NULL, 0x8000, 0, 0,
- >bar[1].pgd);
- if (ret)
- return ret;
+static int
+nvc0_bar_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+ struct nouveau_oclass *oclass, void *data, u32 size,
+ struct nouveau_object **pobject)
+{
+ struct nouveau_device *device = nv_device(parent);
[PATCH v2 00/10] drm/nouveau: support for GK20A, cont'd
Hi everyone, Way overdue v2 of the final patches that enable basic GK20A support. Hopefully all the issues raised with v1 have been addressed. Changes since v1: - Use gk20a clock driver by Ben instead of twiddling nv04's - Name new classes after gk20a instead of nvea - Addressed comments about BAR initialization code factorization - Removed non-essential code which only purpose was to avoid warnings - Use nv_wait in ibus driver Alexandre Courbot (10): drm/nouveau/bar: only ioremap BAR3 if it exists drm/nouveau/bar/nvc0: support chips without BAR3 drm/nouveau/ibus: add GK20A support drm/nouveau/fb: add GK20A support drm/nouveau/fifo: add GK20A support drm/nouveau/graph: enable when using external firmware drm/nouveau/graph: pad firmware code at load time drm/nouveau/graph: add GK20A support drm/nouveau: support GK20A in nouveau_accel_init() drm/nouveau: support for probing GK20A drivers/gpu/drm/nouveau/Makefile | 6 + drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20 +++ drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c | 35 + drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h| 1 + .../gpu/drm/nouveau/core/engine/graph/ctxgk20a.c | 53 +++ .../gpu/drm/nouveau/core/engine/graph/ctxnvc0.h| 9 ++ .../gpu/drm/nouveau/core/engine/graph/ctxnve4.c| 14 +- drivers/gpu/drm/nouveau/core/engine/graph/gk20a.c | 47 ++ drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 13 +- drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h | 2 + drivers/gpu/drm/nouveau/core/engine/graph/nve4.c | 4 +- drivers/gpu/drm/nouveau/core/include/engine/fifo.h | 1 + .../gpu/drm/nouveau/core/include/engine/graph.h| 1 + drivers/gpu/drm/nouveau/core/include/subdev/fb.h | 1 + drivers/gpu/drm/nouveau/core/include/subdev/ibus.h | 1 + drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 6 +- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 114 +++--- drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c | 56 +++ drivers/gpu/drm/nouveau/core/subdev/fb/priv.h | 1 + drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c | 168 + drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c | 103 + drivers/gpu/drm/nouveau/nouveau_drm.c | 5 + 22 files changed, 592 insertions(+), 69 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/ctxgk20a.c create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/gk20a.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c -- 1.9.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/
[PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()
Skip the creation of a software channel for GK20A as software methods
are not yet supported.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ddd83756b9a2..5b46148ffd32 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -208,6 +208,10 @@ nouveau_accel_init(struct nouveau_drm *drm)
return;
}
+ /* Need to figure out how to handle sw for gk20a */
+ if (device->chipset == 0xea)
+ goto skip_sw_init;
+
ret = nouveau_object_new(nv_object(drm), NVDRM_CHAN, NVDRM_NVSW,
nouveau_abi16_swclass(drm), NULL, 0, );
if (ret == 0) {
@@ -234,6 +238,7 @@ nouveau_accel_init(struct nouveau_drm *drm)
return;
}
+skip_sw_init:
if (device->card_type < NV_C0) {
ret = nouveau_gpuobj_new(drm->device, NULL, 32, 0, 0,
>notify);
--
1.9.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/
[PATCH v2 06/10] drm/nouveau/graph: enable when using external firmware
nvc0_graph_ctor() would only let the graphics engine be enabled if its
oclass has a proper microcode linked to it. This prevents GR from being
enabled at all on chips that rely exclusively on external firmware, even
though such a use-case is valid.
Relax the conditions enabling the GR engine to also include the case
where an external firmware has also been loaded.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
index f3c7329da0a0..e5b75f189988 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
@@ -1259,10 +1259,13 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct
nouveau_object *engine,
struct nvc0_graph_oclass *oclass = (void *)bclass;
struct nouveau_device *device = nv_device(parent);
struct nvc0_graph_priv *priv;
+ bool use_ext_fw, enable;
int ret, i;
- ret = nouveau_graph_create(parent, engine, bclass,
- (oclass->fecs.ucode != NULL), );
+ use_ext_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW", false);
+ enable = use_ext_fw || oclass->fecs.ucode != NULL;
+
+ ret = nouveau_graph_create(parent, engine, bclass, enable, );
*pobject = nv_object(priv);
if (ret)
return ret;
@@ -1272,7 +1275,7 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct
nouveau_object *engine,
priv->base.units = nvc0_graph_units;
- if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", false)) {
+ if (use_ext_fw) {
nv_info(priv, "using external firmware\n");
if (nvc0_graph_ctor_fw(priv, "fuc409c", >fuc409c) ||
nvc0_graph_ctor_fw(priv, "fuc409d", >fuc409d) ||
--
1.9.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/
[PATCH v2 04/10] drm/nouveau/fb: add GK20A support
Add a simple FB device for GK20A, as well as a RAM implementation based
on contiguous DMA memory allocations suitable for chips that use system
memory as video RAM.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile | 2 +
drivers/gpu/drm/nouveau/core/include/subdev/fb.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c| 56
drivers/gpu/drm/nouveau/core/subdev/fb/priv.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c | 168 ++
5 files changed, 228 insertions(+)
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/fb/ramgk20a.c
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index bc5fb24630e6..34fef246e779 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -102,6 +102,7 @@ nouveau-y += core/subdev/fb/nvaa.o
nouveau-y += core/subdev/fb/nvaf.o
nouveau-y += core/subdev/fb/nvc0.o
nouveau-y += core/subdev/fb/nve0.o
+nouveau-y += core/subdev/fb/gk20a.o
nouveau-y += core/subdev/fb/gm107.o
nouveau-y += core/subdev/fb/ramnv04.o
nouveau-y += core/subdev/fb/ramnv10.o
@@ -117,6 +118,7 @@ nouveau-y += core/subdev/fb/ramnva3.o
nouveau-y += core/subdev/fb/ramnvaa.o
nouveau-y += core/subdev/fb/ramnvc0.o
nouveau-y += core/subdev/fb/ramnve0.o
+nouveau-y += core/subdev/fb/ramgk20a.o
nouveau-y += core/subdev/fb/ramgm107.o
nouveau-y += core/subdev/fb/sddr3.o
nouveau-y += core/subdev/fb/gddr5.o
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
b/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
index 58c7ccdebb01..871e73914b24 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/fb.h
@@ -105,6 +105,7 @@ extern struct nouveau_oclass *nvaa_fb_oclass;
extern struct nouveau_oclass *nvaf_fb_oclass;
extern struct nouveau_oclass *nvc0_fb_oclass;
extern struct nouveau_oclass *nve0_fb_oclass;
+extern struct nouveau_oclass *gk20a_fb_oclass;
extern struct nouveau_oclass *gm107_fb_oclass;
#include
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c
b/drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c
new file mode 100644
index ..a16024a74771
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/gk20a.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "nvc0.h"
+
+struct gk20a_fb_priv {
+ struct nouveau_fb base;
+};
+
+static int
+gk20a_fb_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+struct nouveau_oclass *oclass, void *data, u32 size,
+struct nouveau_object **pobject)
+{
+ struct gk20a_fb_priv *priv;
+ int ret;
+
+ ret = nouveau_fb_create(parent, engine, oclass, );
+ *pobject = nv_object(priv);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+struct nouveau_oclass *
+gk20a_fb_oclass = &(struct nouveau_fb_impl) {
+ .base.handle = NV_SUBDEV(FB, 0xea),
+ .base.ofuncs = &(struct nouveau_ofuncs) {
+ .ctor = gk20a_fb_ctor,
+ .dtor = _nouveau_fb_dtor,
+ .init = _nouveau_fb_init,
+ .fini = _nouveau_fb_fini,
+ },
+ .memtype = nvc0_fb_memtype_valid,
+ .ram = _ram_oclass,
+}.base;
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
b/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
index da74c889aed4..82273f832e42 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/priv.h
@@ -32,6 +32,7 @@ extern struct nouveau_oclass nva3_ram_oclass;
extern struct nouveau_oclass nvaa_ram_oclass;
extern struct nouveau_oclass nvc0_ram_oclass;
extern struct nouveau_oclass nve0_ram_oclass;
+extern struct nouveau_oclass gk20a_ram_oclass;
extern struct
[PATCH v2 08/10] drm/nouveau/graph: add GK20A support
Add a GR device for GK20A based on NVE4, with the correct classes
definitions (GK20A's 3D class is 0xa297).
Most of the NVE4 code can be used on GK20A, so make relevant bits of
NVE4 available to other chips as well.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile | 2 +
.../gpu/drm/nouveau/core/engine/graph/ctxgk20a.c | 53 ++
.../gpu/drm/nouveau/core/engine/graph/ctxnvc0.h| 9
.../gpu/drm/nouveau/core/engine/graph/ctxnve4.c| 14 +++---
drivers/gpu/drm/nouveau/core/engine/graph/gk20a.c | 47 +++
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h | 2 +
drivers/gpu/drm/nouveau/core/engine/graph/nve4.c | 4 +-
.../gpu/drm/nouveau/core/include/engine/graph.h| 1 +
8 files changed, 123 insertions(+), 9 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/ctxgk20a.c
create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/gk20a.c
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index e6fe53bab593..1aaa2ef577d9 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -259,6 +259,7 @@ nouveau-y += core/engine/graph/ctxnvc8.o
nouveau-y += core/engine/graph/ctxnvd7.o
nouveau-y += core/engine/graph/ctxnvd9.o
nouveau-y += core/engine/graph/ctxnve4.o
+nouveau-y += core/engine/graph/ctxgk20a.o
nouveau-y += core/engine/graph/ctxnvf0.o
nouveau-y += core/engine/graph/ctxnv108.o
nouveau-y += core/engine/graph/ctxgm107.o
@@ -279,6 +280,7 @@ nouveau-y += core/engine/graph/nvc8.o
nouveau-y += core/engine/graph/nvd7.o
nouveau-y += core/engine/graph/nvd9.o
nouveau-y += core/engine/graph/nve4.o
+nouveau-y += core/engine/graph/gk20a.o
nouveau-y += core/engine/graph/nvf0.o
nouveau-y += core/engine/graph/nv108.o
nouveau-y += core/engine/graph/gm107.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxgk20a.c
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxgk20a.c
new file mode 100644
index ..224ee0287ab7
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxgk20a.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "ctxnvc0.h"
+
+static const struct nvc0_graph_pack
+gk20a_grctx_pack_mthd[] = {
+ { nve4_grctx_init_a097_0, 0xa297 },
+ { nvc0_grctx_init_902d_0, 0x902d },
+ {}
+};
+
+struct nouveau_oclass *
+gk20a_grctx_oclass = &(struct nvc0_grctx_oclass) {
+ .base.handle = NV_ENGCTX(GR, 0xea),
+ .base.ofuncs = &(struct nouveau_ofuncs) {
+ .ctor = nvc0_graph_context_ctor,
+ .dtor = nvc0_graph_context_dtor,
+ .init = _nouveau_graph_context_init,
+ .fini = _nouveau_graph_context_fini,
+ .rd32 = _nouveau_graph_context_rd32,
+ .wr32 = _nouveau_graph_context_wr32,
+ },
+ .main = nve4_grctx_generate_main,
+ .mods = nve4_grctx_generate_mods,
+ .unkn = nve4_grctx_generate_unkn,
+ .hub = nve4_grctx_pack_hub,
+ .gpc = nve4_grctx_pack_gpc,
+ .zcull = nvc0_grctx_pack_zcull,
+ .tpc = nve4_grctx_pack_tpc,
+ .ppc = nve4_grctx_pack_ppc,
+ .icmd = nve4_grctx_pack_icmd,
+ .mthd = gk20a_grctx_pack_mthd,
+}.base;
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.h
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.h
index 9c815d1f99ef..8da8b627b9d0 100644
--- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.h
+++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.h
@@ -69,7 +69,9 @@ extern struct nouveau_oclass *nvd7_grctx_oclass;
extern struct nouveau_oclass *nvd9_grctx_oclass;
extern struct nouveau_oclass *nve4_grctx_oclass;
+extern struct nouveau_oclass *gk20a_grctx_oclass;
void nve4_grctx_generate_main(struct nvc0_graph_priv *, struct nvc0_grctx *);
+void
[PATCH v2 10/10] drm/nouveau: support for probing GK20A
Set the correct subdev/engine classes when GK20A (0xea) is probed. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c index 9784cbf8a9d2..b014928286d6 100644 --- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c +++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c @@ -156,6 +156,26 @@ nve0_identify(struct nouveau_device *device) device->oclass[NVDEV_ENGINE_PPP] = _ppp_oclass; device->oclass[NVDEV_ENGINE_PERFMON] = _perfmon_oclass; break; + case 0xea: + device->cname = "GK20A"; + device->oclass[NVDEV_SUBDEV_MC ] = nvc3_mc_oclass; + device->oclass[NVDEV_SUBDEV_BUS] = nvc0_bus_oclass; + device->oclass[NVDEV_SUBDEV_TIMER ] = _timer_oclass; + device->oclass[NVDEV_SUBDEV_FB ] = gk20a_fb_oclass; + device->oclass[NVDEV_SUBDEV_IBUS ] = _ibus_oclass; + device->oclass[NVDEV_SUBDEV_INSTMEM] = nv50_instmem_oclass; + device->oclass[NVDEV_SUBDEV_VM ] = _vmmgr_oclass; + device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass; + device->oclass[NVDEV_ENGINE_DMAOBJ ] = _dmaeng_oclass; + device->oclass[NVDEV_ENGINE_FIFO ] = gk20a_fifo_oclass; + /* TODO will need an implementation for this at some point... */ +#if 0 + device->oclass[NVDEV_ENGINE_SW ] = nvc0_software_oclass; +#endif + device->oclass[NVDEV_ENGINE_GR ] = gk20a_graph_oclass; + device->oclass[NVDEV_ENGINE_COPY2 ] = _copy2_oclass; + device->oclass[NVDEV_ENGINE_PERFMON] = _perfmon_oclass; + break; case 0xf0: device->cname = "GK110"; device->oclass[NVDEV_SUBDEV_VBIOS ] = _bios_oclass; -- 1.9.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/
Re: [PATCH 1/2] cpufreq: exynos: Use dev_err/info function instead of pr_err/info
On 18 April 2014 07:50, Chanwoo Choi wrote:
> This patch uses dev_err/info function to show accurate log message with
> device name
> instead of pr_err/info function.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
> drivers/cpufreq/exynos-cpufreq.c | 21 -
> drivers/cpufreq/exynos-cpufreq.h | 1 +
> 2 files changed, 13 insertions(+), 9 deletions(-)
This still looks fine even if we don't take the new driver ?
Acked-by: Viresh Kumar
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index f99cfe2..8b4bb4a 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -49,6 +49,7 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
> struct cpufreq_policy *policy = cpufreq_cpu_get(0);
> unsigned int arm_volt, safe_arm_volt = 0;
> unsigned int mpll_freq_khz = exynos_info->mpll_freq_khz;
> + struct device *dev = exynos_info->dev;
> unsigned int old_freq;
> int index, old_index;
> int ret = 0;
> @@ -90,8 +91,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
> /* Firstly, voltage up to increase frequency */
> ret = regulator_set_voltage(arm_regulator, arm_volt,
> arm_volt);
> if (ret) {
> - pr_err("%s: failed to set cpu voltage to %d\n",
> - __func__, arm_volt);
> + dev_err(dev, "failed to set cpu voltage to %d\n",
> + arm_volt);
> return ret;
> }
> }
> @@ -100,8 +101,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
> ret = regulator_set_voltage(arm_regulator, safe_arm_volt,
> safe_arm_volt);
> if (ret) {
> - pr_err("%s: failed to set cpu voltage to %d\n",
> - __func__, safe_arm_volt);
> + dev_err(dev, "failed to set cpu voltage to %d\n",
> + safe_arm_volt);
> return ret;
> }
> }
> @@ -115,8 +116,8 @@ static int exynos_cpufreq_scale(unsigned int target_freq)
> ret = regulator_set_voltage(arm_regulator, arm_volt,
> arm_volt);
> if (ret) {
> - pr_err("%s: failed to set cpu voltage to %d\n",
> - __func__, arm_volt);
> + dev_err(dev, "failed to set cpu voltage to %d\n",
> + arm_volt);
> goto out;
> }
> }
> @@ -163,6 +164,8 @@ static int exynos_cpufreq_probe(struct platform_device
> *pdev)
> if (!exynos_info)
> return -ENOMEM;
>
> + exynos_info->dev = >dev;
> +
> if (soc_is_exynos4210())
> ret = exynos4210_cpufreq_init(exynos_info);
> else if (soc_is_exynos4212() || soc_is_exynos4412())
> @@ -176,13 +179,13 @@ static int exynos_cpufreq_probe(struct platform_device
> *pdev)
> goto err_vdd_arm;
>
> if (exynos_info->set_freq == NULL) {
> - pr_err("%s: No set_freq function (ERR)\n", __func__);
> + dev_err(>dev, "No set_freq function (ERR)\n");
> goto err_vdd_arm;
> }
>
> arm_regulator = regulator_get(NULL, "vdd_arm");
> if (IS_ERR(arm_regulator)) {
> - pr_err("%s: failed to get resource vdd_arm\n", __func__);
> + dev_err(>dev, "failed to get resource vdd_arm\n");
> goto err_vdd_arm;
> }
>
> @@ -192,7 +195,7 @@ static int exynos_cpufreq_probe(struct platform_device
> *pdev)
> if (!cpufreq_register_driver(_driver))
> return 0;
>
> - pr_err("%s: failed to register cpufreq driver\n", __func__);
> + dev_err(>dev, "failed to register cpufreq driver\n");
> regulator_put(arm_regulator);
> err_vdd_arm:
> kfree(exynos_info);
> diff --git a/drivers/cpufreq/exynos-cpufreq.h
> b/drivers/cpufreq/exynos-cpufreq.h
> index 3ddade8..b72ff10 100644
> --- a/drivers/cpufreq/exynos-cpufreq.h
> +++ b/drivers/cpufreq/exynos-cpufreq.h
> @@ -34,6 +34,7 @@ struct apll_freq {
> };
>
> struct exynos_dvfs_info {
> + struct device *dev;
> unsigned long mpll_freq_khz;
> unsigned intpll_safe_idx;
> struct clk *cpu_clk;
> --
> 1.8.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/
[PATCH v2 07/10] drm/nouveau/graph: pad firmware code at load time
Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will fail to run from non-prepadded firmware files. Signed-off-by: Alexandre Courbot Reviewed-by: Thierry Reding --- drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c index e5b75f189988..013475c62986 100644 --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c @@ -894,6 +894,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 fuc_base, nv_wr32(priv, fuc_base + 0x0188, i >> 6); nv_wr32(priv, fuc_base + 0x0184, code->data[i]); } + + /* code must be padded to 0x40 bytes */ + for (; i & 0x3f; i++) + nv_wr32(priv, fuc_base + 0x0184, 0); } static void -- 1.9.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/
[PATCH v2 03/10] drm/nouveau/ibus: add GK20A support
Add support for initializing the priv ring of GK20A. This is done by the
BIOS on desktop GPUs, but needs to be done by hand on Tegra.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/include/subdev/ibus.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c | 103 +
3 files changed, 105 insertions(+)
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index b7d216264775..bc5fb24630e6 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -136,6 +136,7 @@ nouveau-y += core/subdev/i2c/nv94.o
nouveau-y += core/subdev/i2c/nvd0.o
nouveau-y += core/subdev/ibus/nvc0.o
nouveau-y += core/subdev/ibus/nve0.o
+nouveau-y += core/subdev/ibus/gk20a.o
nouveau-y += core/subdev/instmem/base.o
nouveau-y += core/subdev/instmem/nv04.o
nouveau-y += core/subdev/instmem/nv40.o
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/ibus.h
b/drivers/gpu/drm/nouveau/core/include/subdev/ibus.h
index 88814f159d89..31df634c0fdc 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/ibus.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/ibus.h
@@ -30,5 +30,6 @@ nouveau_ibus(void *obj)
extern struct nouveau_oclass nvc0_ibus_oclass;
extern struct nouveau_oclass nve0_ibus_oclass;
+extern struct nouveau_oclass gk20a_ibus_oclass;
#endif
diff --git a/drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c
b/drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c
new file mode 100644
index ..245f0ebaa6af
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/subdev/ibus/gk20a.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+
+struct gk20a_ibus_priv {
+ struct nouveau_ibus base;
+};
+
+static void
+gk20a_ibus_init_priv_ring(struct gk20a_ibus_priv *priv)
+{
+ nv_mask(priv, 0x137250, 0x3f, 0);
+
+ nv_mask(priv, 0x000200, 0x20, 0);
+ usleep_range(20, 30);
+ nv_mask(priv, 0x000200, 0x20, 0x20);
+
+ nv_wr32(priv, 0x12004c, 0x4);
+ nv_wr32(priv, 0x122204, 0x2);
+ nv_rd32(priv, 0x122204);
+}
+
+static void
+gk20a_ibus_intr(struct nouveau_subdev *subdev)
+{
+ struct gk20a_ibus_priv *priv = (void *)subdev;
+ u32 status0 = nv_rd32(priv, 0x120058);
+
+ if (status0 & 0x7) {
+ nv_debug(priv, "resetting priv ring\n");
+ gk20a_ibus_init_priv_ring(priv);
+ }
+
+ /* Acknowledge interrupt */
+ nv_mask(priv, 0x12004c, 0x2, 0x2);
+
+ if (!nv_wait(subdev, 0x12004c, 0x3f, 0x00))
+ nv_warn(priv, "timeout waiting for ringmaster ack\n");
+}
+
+static int
+gk20a_ibus_init(struct nouveau_object *object)
+{
+ struct gk20a_ibus_priv *priv = (void *)object;
+ int ret;
+
+ ret = _nouveau_ibus_init(object);
+ if (ret)
+ return ret;
+
+ gk20a_ibus_init_priv_ring(priv);
+
+ return 0;
+}
+
+static int
+gk20a_ibus_ctor(struct nouveau_object *parent, struct nouveau_object *engine,
+ struct nouveau_oclass *oclass, void *data, u32 size,
+ struct nouveau_object **pobject)
+{
+ struct gk20a_ibus_priv *priv;
+ int ret;
+
+ ret = nouveau_ibus_create(parent, engine, oclass, );
+ *pobject = nv_object(priv);
+ if (ret)
+ return ret;
+
+ nv_subdev(priv)->intr = gk20a_ibus_intr;
+ return 0;
+}
+
+struct nouveau_oclass
+gk20a_ibus_oclass = {
+ .handle = NV_SUBDEV(IBUS, 0xea),
+ .ofuncs = &(struct nouveau_ofuncs) {
+ .ctor = gk20a_ibus_ctor,
+ .dtor = _nouveau_ibus_dtor,
+ .init = gk20a_ibus_init,
+ .fini = _nouveau_ibus_fini,
+ },
+};
--
1.9.2
--
To unsubscribe from
[PATCH v2 05/10] drm/nouveau/fifo: add GK20A support
GK20A's FIFO is compatible with NVE0, but only features 128 channels and
1 runlist.
Signed-off-by: Alexandre Courbot
Reviewed-by: Thierry Reding
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c | 35 ++
drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h| 1 +
drivers/gpu/drm/nouveau/core/include/engine/fifo.h | 1 +
4 files changed, 38 insertions(+)
create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index 34fef246e779..e6fe53bab593 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -248,6 +248,7 @@ nouveau-y += core/engine/fifo/nv50.o
nouveau-y += core/engine/fifo/nv84.o
nouveau-y += core/engine/fifo/nvc0.o
nouveau-y += core/engine/fifo/nve0.o
+nouveau-y += core/engine/fifo/gk20a.o
nouveau-y += core/engine/fifo/nv108.o
nouveau-y += core/engine/graph/ctxnv40.o
nouveau-y += core/engine/graph/ctxnv50.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c
b/drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c
new file mode 100644
index ..327456eae963
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/core/engine/fifo/gk20a.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include "nve0.h"
+
+struct nouveau_oclass *
+gk20a_fifo_oclass = &(struct nve0_fifo_impl) {
+ .base.handle = NV_ENGINE(FIFO, 0xea),
+ .base.ofuncs = &(struct nouveau_ofuncs) {
+ .ctor = nve0_fifo_ctor,
+ .dtor = nve0_fifo_dtor,
+ .init = nve0_fifo_init,
+ .fini = nve0_fifo_fini,
+ },
+ .channels = 128,
+}.base;
diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
b/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
index 014344ebee66..e96b32bb1bbc 100644
--- a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
+++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
@@ -8,6 +8,7 @@ int nve0_fifo_ctor(struct nouveau_object *, struct
nouveau_object *,
struct nouveau_object **);
void nve0_fifo_dtor(struct nouveau_object *);
int nve0_fifo_init(struct nouveau_object *);
+int nve0_fifo_fini(struct nouveau_object *, bool);
struct nve0_fifo_impl {
struct nouveau_oclass base;
diff --git a/drivers/gpu/drm/nouveau/core/include/engine/fifo.h
b/drivers/gpu/drm/nouveau/core/include/engine/fifo.h
index 26b6b2bb1112..b639eb2c74ff 100644
--- a/drivers/gpu/drm/nouveau/core/include/engine/fifo.h
+++ b/drivers/gpu/drm/nouveau/core/include/engine/fifo.h
@@ -109,6 +109,7 @@ extern struct nouveau_oclass *nv50_fifo_oclass;
extern struct nouveau_oclass *nv84_fifo_oclass;
extern struct nouveau_oclass *nvc0_fifo_oclass;
extern struct nouveau_oclass *nve0_fifo_oclass;
+extern struct nouveau_oclass *gk20a_fifo_oclass;
extern struct nouveau_oclass *nv108_fifo_oclass;
void nv04_fifo_intr(struct nouveau_subdev *);
--
1.9.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/
[PATCH v2 01/10] drm/nouveau/bar: only ioremap BAR3 if it exists
Some chips that use system memory exclusively (e.g. GK20A) do not expose 2 BAR regions. For them only BAR1 exists, and it should be used for USERD mapping. Do not map BAR3 if its resource does not exist. Signed-off-by: Alexandre Courbot Reviewed-by: Thierry Reding --- drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c index bdf594116f3f..73b1ed20c8d5 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c @@ -118,8 +118,10 @@ nouveau_bar_create_(struct nouveau_object *parent, if (ret) return ret; - bar->iomem = ioremap(nv_device_resource_start(device, 3), -nv_device_resource_len(device, 3)); + if (nv_device_resource_len(device, 3) != 0) + bar->iomem = ioremap(nv_device_resource_start(device, 3), +nv_device_resource_len(device, 3)); + return 0; } -- 1.9.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/
Re: [PATCH 1/2] ARM: SAMSUNG: remove gpio flags in dev-backlight
On Thu, Apr 10, 2014 at 11:14 PM, Alexandre Courbot wrote: > On Thu, Apr 10, 2014 at 6:51 PM, Jingoo Han wrote: >> On Thursday, April 10, 2014 1:17 PM, Alexandre Courbot wrote: >>> >>> Ping, can I have the Samsung folks review and ,aybe even merge this >>> patch? enable_gpio_flags is never used in any code, is replaced by >>> gpiod, and we would like to remove it altogether from pwm_bl. Thanks! >> >> OK, I see. It looks good. >> >> As far as I know, 'enable_gpio_flags' has not been being used >> for Samsung platform. So, there will be no side effect, >> if 'enable_gpio_flags' is removed from 'arch/arm/plat-samsung' >> directory. >> >> Reviewed-by: Jingoo Han > > Great, thanks. Ben, Kukjin, could we have your Acked-by? > > Thierry, if the Samsung maintainers are ok with it, and 2/2 of this > series is also ok for you (you merged the same for simple-panel > already), can you take both into your tree? Last call - could we have a Acked-by from Ben or Kukjin and merge this through Thierry's tree? Otherwise I will just have to drop this series, which would be sad. -- 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] mm/swap: cleanup *lru_cache_add* functions
On 04/21/2014 12:02 PM, Jianyu Zhan wrote: > Hi, Yanfei, > > On Mon, Apr 21, 2014 at 9:00 AM, Zhang Yanfei > wrote: >> What should be exported? >> >> lru_cache_add() >> lru_cache_add_anon() >> lru_cache_add_file() >> >> It seems you only export lru_cache_add_file() in the patch. > > Right, lru_cache_add_anon() is only used by VM code, so it should not > be exported. > > lru_cache_add_file() and lru_cache_add() are supposed to be used by > vfs ans fs code. > > But now only lru_cache_add_file() is used by CIFS and FUSE, which > both could be > built as module, so it must be exported; and lru_cache_add() has now > no module users, > so as Rik suggests, it is unexported too. > OK. So The sentence in the patch log confused me: [ However, lru_cache_add() is supposed to be used by vfs, or whatever others, but it is not exported.] otherwise, Reviewed-by: Zhang Yanfei Thanks. -- Thanks. Zhang Yanfei -- 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] pinctrl-baytrail: fix for irq descriptor conflict on ASUS T100TA
On 2014/4/20 23:28, Adam Williamson wrote: > On Sun, 2014-04-20 at 20:08 +0800, Jin, Yao wrote: >> For the issue that touch screen doesn't work, could you check power >> state of LPSS devices? For example: >> >> cd /sys/bus/acpi/devices >> grep -H . */power_state >> >> If they are D3cold, it should be the reason why touch screen doesn't >> work. That's another issue, unrelated to this gpio patch. > > The touch screen worked fine with kernel 3.14, and Benjamin looked at > debug output from the attempt to load the touchscreen driver when > diagnosing the problem, he's not just guessing. I am building a kernel > without your patch to confirm that fixes it. > I tried the clean kernel 3.14 with the boot option "nomodeset text" on Dell Venue 11 Pro (If without "nomodeset",my ubuntu is being "black screen", but that should be another i915 issue). After system starup, I executed the "startx" to launch the xwindow. In xwindow, the touchscreen work. I tried the kernel 3.14 again with my gpio patch applied, the result was the same, the touchscreen work. I also check the DSDT table of Dell Venue 11 Pro by searching the keyword "Interrupt", I can't find any clue for the irq conflict. I'm sorry I don't have a Dell Venue 8 for testing, but I guess it's similar to Dell Venue 11 Pro. -- 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/
[sched,rcu] 9234566d3a3: +1.6% will-it-scale.scalability, +1302.6% time.involuntary_context_switches
Hi Paul,
we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
torture.2014.04.18a
commit 9234566d3a36c0aead8852e3c2ca94cd8ebfe219 ("sched,rcu: Make cond_resched()
report RCU quiescent states")
Comparison 1 - parent commit of 9234566d3a36c0aead8852e3c2ca94cd8ebfe219 vs
9234566d3a36c0aead8852e3c2ca94cd8ebfe219
e119454e74a852f 9234566d3a36c0aead8852e3c
--- -
1035948 ~ 0% +1.6%1052990 ~ 0% TOTAL will-it-scale.per_thread_ops
1271322 ~ 0% +1.8%1294004 ~ 0% TOTAL will-it-scale.per_process_ops
0.63 ~ 0% -5.2% 0.60 ~ 0% TOTAL will-it-scale.scalability
22470 ~ 2% +1302.6% 315168 ~ 2% TOTAL
time.involuntary_context_switches
84265 ~ 5% +1047.1% 966581 ~ 1% TOTAL interrupts.IWI
1828 ~44%+189.6% 5295 ~13% TOTAL
time.voluntary_context_switches
5337 ~ 1% +82.1% 9720 ~ 1% TOTAL vmstat.system.cs
118599 ~ 0% -30.4% 82545 ~ 0% TOTAL
interrupts.0:IO-APIC-edge.timer
224021 ~ 4% +34.7% 301858 ~ 2% TOTAL interrupts.RES
25148 ~ 0% +7.0% 26917 ~ 0% TOTAL vmstat.system.in
7063439 ~ 0% -5.2%6694536 ~ 0% TOTAL interrupts.LOC
188866 ~ 0% -3.1% 183008 ~ 0% TOTAL interrupts.NMI
188866 ~ 0% -3.1% 183008 ~ 0% TOTAL interrupts.PMI
3720 ~ 0% -1.5% 3665 ~ 0% TOTAL time.system_time
1215 ~ 0% -1.4% 1198 ~ 0% TOTAL
time.percent_of_cpu_this_job_got
Comparison 2 - b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 vs
9234566d3a36c0aead8852e3c2ca94cd8ebfe219
Fengguang has reported stats changes about
b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 to you days ago.
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2014.04.14a
commit b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 ("sched,rcu: Make cond_resched()
report RCU quiescent states")
Let's have a compare here.
b84c4e08143c98d 9234566d3a36c0aead8852e3c
--- -
809309 ~ 0% -2.6% 788400 ~ 0% TOTAL will-it-scale.per_process_ops
0.61 ~ 0% -1.9% 0.60 ~ 0% TOTAL will-it-scale.scalability
434080 ~ 0% -1.5% 427643 ~ 0% TOTAL will-it-scale.per_thread_ops
4 ~11% +1.2e+05% 5249 ~ 2% TOTAL interrupts.IWI
607 ~ 7% +28.0%778 ~14% TOTAL
interrupts.47:PCI-MSI-edge.eth0
12349 ~ 2% -14.6% 10548 ~ 1% TOTAL
interrupts.0:IO-APIC-edge.timer
3078 ~ 3% +20.9% 3722 ~ 6% TOTAL interrupts.RES
Comparison 3 - parent commit of b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 vs
b84c4e08143c98dad4b4d139f08db0b98b0d3ec4
Duplicated with Fengguang's report. Help you to see these info in a page :)
ad86a04266f9b49 b84c4e08143c98dad4b4d139f
--- -
676264 ~ 0% +3.3% 698461 ~ 0% TOTAL will-it-scale.per_thread_ops
1174547 ~ 0% +3.0%1209307 ~ 0% TOTAL will-it-scale.per_process_ops
1.67 ~ 0% -2.3% 1.63 ~ 0% TOTAL will-it-scale.scalability
10522 ~ 2%+921.2% 107463 ~ 1% TOTAL
time.involuntary_context_switches
77671 ~ 3% +67.0% 129688 ~ 3% TOTAL interrupts.RES
99502 ~ 0% -27.8% 71813 ~ 0% TOTAL
interrupts.0:IO-APIC-edge.timer
2554 ~ 0% +49.1% 3809 ~ 1% TOTAL vmstat.system.cs
11524 ~ 0% -2.3% 11259 ~ 0% TOTAL vmstat.system.in
213 ~ 0% -4.3%204 ~ 0% TOTAL time.system_time
74 ~ 0% -4.1% 71 ~ 0% TOTAL
time.percent_of_cpu_this_job_got
3495099 ~ 0% -3.1%3387173 ~ 0% TOTAL interrupts.LOC
Thanks,
Jet
./runtest.py open2 32 1 4 6 8
Re: [PATCH 1/1] net: Add rtnl_lock for netif_device_attach/detach
The comment is trying to explain why add a lock here.
On 04/19/2014 03:01 AM, Sergei Shtylyov wrote:
Hello.
On 04/16/2014 11:08 AM, Li, Zhen-Hua wrote:
From: "Li, Zhen-Hua"
As netif_running is called in netif_device_attach/detach. There
should be
rtnl_lock/unlock called, to avoid dev stat change during
netif_device_attach
and detach being called.
I checked NIC some drivers, some of them have
netif_device_attach/detach
called between rtnl_lock/unlock, while some drivers do not.
This patch is tring to find a generic way to fix this for all NIC
drivers.
Signed-off-by: Li, Zhen-Hua
---
net/core/dev.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 5b3042e..795bbc5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2190,10 +2190,19 @@ EXPORT_SYMBOL(__dev_kfree_skb_any);
*/
void netif_device_detach(struct net_device *dev)
{
+/**
Hm, why kernel-doc style comment here?
+ * As netif_running is called , rtnl_lock and unlock are needed to
+ * avoid __LINK_STATE_START bit changes during this function call.
+ */
+int need_unlock;
+
+need_unlock = rtnl_trylock();
if (test_and_clear_bit(__LINK_STATE_PRESENT, >state) &&
netif_running(dev)) {
netif_tx_stop_all_queues(dev);
}
+if (need_unlock)
+rtnl_unlock();
}
EXPORT_SYMBOL(netif_device_detach);
@@ -2205,11 +2214,20 @@ EXPORT_SYMBOL(netif_device_detach);
*/
void netif_device_attach(struct net_device *dev)
{
+/**
... and here?
+ * As netif_running is called , rtnl_lock and unlock are needed to
+ * avoid __LINK_STATE_START bit changes during this function call.
+ */
WBR, Sergei
--
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] PM / suspend: Make cpuidle work in the "freeze" state
On 04/21/2014 03:13 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The "freeze" system sleep state introduced by commit 7e73c5ae6e79
> (PM: Introduce suspend state PM_SUSPEND_FREEZE) requires cpuidle
> to be functional when freeze_enter() is executed to work correctly
> (that is, to be able to save any more energy than runtime idle),
> but that is impossible after commit 8651f97bd951d (PM / cpuidle:
> System resume hang fix with cpuidle) which caused cpuidle to be
> paused in dpm_suspend_noirq() and resumed in dpm_resume_noirq().
>
> To avoid that problem, add cpuidle_resume() and cpuidle_pause()
> to the beginning and the end of freeze_enter(), respectively.
>
> Reported-by: Zhang Rui
> Signed-off-by: Rafael J. Wysocki
> ---
> kernel/power/suspend.c |3 +++
> 1 file changed, 3 insertions(+)
>
> Index: linux-pm/kernel/power/suspend.c
> ===
> --- linux-pm.orig/kernel/power/suspend.c
> +++ linux-pm/kernel/power/suspend.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -53,7 +54,9 @@ static void freeze_begin(void)
>
> static void freeze_enter(void)
> {
> + cpuidle_resume();
> wait_event(suspend_freeze_wait_head, suspend_freeze_wake);
> + cpuidle_pause();
> }
>
> void freeze_wake(void)
>
Reviewed-by: Preeti U Murthy
--
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 V7 1/1] drivers/gpio: Altera soft IP GPIO driver and devicetree binding
On Isn, 2014-04-07 at 12:11 -0500, Josh Cartwright wrote:
> On Mon, Apr 07, 2014 at 04:00:43PM +0800, Tien Hock Loh wrote:
> > On Wed, Mar 19, 2014 at 6:09 PM, Tien Hock Loh wrote:
> > > On Fri, Mar 7, 2014 at 11:14 PM, Josh Cartwright
> > > wrote:
> > >> On Mon, Mar 03, 2014 at 06:27:43PM +0800, th...@altera.com wrote:
> > >>> From: Tien Hock Loh
> [..]
> > >>> + altera_gc->mapped_irq = irq_of_parse_and_map(node, 0);
> > >>>
> > >>
> > >> platform_get_irq(pdev, 0);
> > >>
> > > OK.
> > >
> >
> > platform_get_irq doesn't create the irq mapping which is needed by the
> > driver. Since this driver is targeted at using of, should I be using
> > irq_of_parse_and_map or should I still redo the codes with
> > platform_get_irq and irq_create_mapping? I think the latter would be
> > introducing code redundancy. Please advice.
>
> Yes, it is technically true that platform_get_irq() doesn't do the
> mapping directly, but that's because the mapping is setup earlier, when
> of_device_alloc() (drivers/of/platform.c) allocates resources for your
> platform device.
>
> Calling irq_of_parse_and_map() should be unnecessary.
I checked and tried running the without irq_create_mapping but it seems
the mapping is not done. What I've seen other GPIO driver is doing is to
create the mapping during the gpio_to_irq call. However Linus suggested
we are avoiding that route, thus the use of irq_of_parse_and_map.
Do you agree with my findings?
>
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply e-mail,
and delete the message and any attachments. Thank you.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 1/2] cpufreq: exynos: Use dev_err/info function instead of pr_err/info
On 04/21/2014 03:05 PM, Viresh Kumar wrote: > On 18 April 2014 07:50, Chanwoo Choi wrote: >> This patch uses dev_err/info function to show accurate log message with >> device name >> instead of pr_err/info function. >> >> Signed-off-by: Chanwoo Choi >> Acked-by: Kyungmin Park >> --- >> drivers/cpufreq/exynos-cpufreq.c | 21 - >> drivers/cpufreq/exynos-cpufreq.h | 1 + >> 2 files changed, 13 insertions(+), 9 deletions(-) > > This still looks fine even if we don't take the new driver ? > > Acked-by: Viresh Kumar Thanks for your review. Best regards, Chanwoo Choi -- 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/
Estimado E-mail del usuario;
Estimado E-mail del usuario; Se ha superado 23.432 Repositorio para el conjunto buzón Servicios Web / Administrador, y habrás problemas al enviar y recepción de correo, mientras que volver a verificar. Debe actualizar haciendo clic en enlace de abajo y complete la información para verificar su cuenta. http://webmailadmin.jimdo.com/ Por favor, haga clic en el siguiente enlace para actualizar la bandeja de entrada. ¡Atención! De no hacerlo, tendrá acceso limitado a su buzón de correo. Si no actualiza su cuenta dentro de los tres días posteriores a la actualización aviso, su cuenta será cerrada permanentemente. -- 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: inotify, new idea?
On Mon, Apr 21, 2014 at 12:22 AM, Richard Weinberger wrote: > On Fri, Apr 18, 2014 at 6:15 AM, Michael Kerrisk > wrote: >> On Thu, Apr 17, 2014 at 11:28 PM, Lennart Sorensen >> wrote: >>> On Thu, Apr 17, 2014 at 11:00:37PM +0200, Jos Huisken wrote: I was trying to maintain a local and remote directory in sync with lsync, using inotify. I happen to have >4M files and >400k directories... running over /proc/sys/fs/inotify/max_user_watches >>> >>> Would fanotify perhaps be a better interface to use? >> >> (One of us is misunderstanding fanotify; it might be me.) >> >> Did you look at fanotify closely? I don't think it could be used for >> this task -- does not notify linka dn unlink events, difficult to set >> up recursive monitoring, etc. > > Does recursive monitoring even work with inotify? > Last time I've tried it did failed as soon I did a mkdir -p a/b/c/d because > mkdir() raced against the thread which installes the new watches. As I understand it, you have to program to deal with the races (rescan directories after adding watches). I recently did a lot of work updating the inotify(7) man page to discuss all the issues that I know of, and their remedies. If I missed anything, I'd appreciate a note on it, so that it can be added. See http://man7.org/linux/man-pages/man7/inotify.7.html#NOTES Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/ -- 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 v7] fs: FAT: Add support for DOS 1.x formatted volumes
Conrad Meyer writes:
> +/*
> + * A deserialized copy of the on-disk structure laid out in struct
> + * fat_boot_sector.
> + */
> +struct fat_bios_param_block {
> + u16 fat_sector_size;
> + u8 fat_sec_per_clus;
> + u16 fat_reserved;
> + u8 fat_fats;
> + u16 fat_dir_entries;
> + u16 fat_sectors;
> + u16 fat_fat_length;
> + u32 fat_total_sect;
> +
> + u8 fat16_state;
> + u32 fat16_vol_id;
> +
> + u32 fat32_length;
> + u32 fat32_root_cluster;
> + u16 fat32_info_sector;
> + u8 fat32_state;
> + u32 fat32_vol_id;
> +
> +};
Looks good. But nobody use this structure except fat_fill_inode(). So,
please move this into inode.c.
With above last change,
Acked-by: OGAWA Hirofumi
Thanks.
--
OGAWA Hirofumi
--
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/
[libata/ahci] 8a4aeec8d2d: +138.4% perf-stat.dTLB-store-misses, +37.2% perf-stat.dTLB-load-misses
HI Dan,
we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata for-next
commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd ("libata/ahci: accommodate tag
ordered controllers")
2cf532f5e67c0cf 8a4aeec8d2d6a3edeffbdfae4
--- -
88694337 ~39%+138.4% 2.115e+08 ~46% TOTAL perf-stat.dTLB-store-misses
217057 ~ 0% -31.3% 149221 ~ 3% TOTAL
interrupts.46:PCI-MSI-edge.ahci
6.995e+08 ~20% +37.2% 9.598e+08 ~25% TOTAL perf-stat.dTLB-load-misses
110302 ~ 0% -28.9% 78402 ~ 2% TOTAL interrupts.CAL
3.168e+08 ~ 9% +14.5% 3.627e+08 ~10% TOTAL
perf-stat.L1-dcache-prefetches
2.553e+09 ~12% +26.5% 3.228e+09 ~11% TOTAL perf-stat.LLC-loads
5.815e+08 ~ 6% +27.3% 7.403e+08 ~11% TOTAL perf-stat.LLC-stores
3.662e+09 ~11% +22.9% 4.501e+09 ~10% TOTAL
perf-stat.L1-dcache-load-misses
2.155e+10 ~ 1% +8.3% 2.333e+10 ~ 1% TOTAL
perf-stat.L1-dcache-store-misses
3.619e+10 ~ 1% +5.9% 3.832e+10 ~ 2% TOTAL perf-stat.cache-references
1.605e+10 ~ 1% +4.3% 1.674e+10 ~ 1% TOTAL
perf-stat.L1-icache-load-misses
239691 ~ 7% -8.4% 219537 ~ 1% TOTAL interrupts.RES
3483 ~ 0% -5.4% 3297 ~ 0% TOTAL vmstat.system.in
2.748e+08 ~ 1% +4.3% 2.865e+08 ~ 0% TOTAL perf-stat.cache-misses
98935369 ~ 0% +4.9% 1.038e+08 ~ 0% TOTAL perf-stat.LLC-store-misses
699 ~ 1% -3.7%673 ~ 1% TOTAL iostat.sda.w_await
698 ~ 1% -3.7%672 ~ 1% TOTAL iostat.sda.await
203893 ~ 0% +3.7% 211474 ~ 0% TOTAL iostat.sda.wkB/s
203972 ~ 0% +3.7% 211488 ~ 0% TOTAL vmstat.io.bo
618082 ~ 4% -4.6% 589619 ~ 1% TOTAL perf-stat.context-switches
1.432e+12 ~ 1% +3.0% 1.475e+12 ~ 0% TOTAL perf-stat.L1-icache-loads
3.35e+11 ~ 0% +3.2% 3.456e+11 ~ 0% TOTAL perf-stat.L1-dcache-stores
1.486e+12 ~ 0% +2.8% 1.527e+12 ~ 0% TOTAL perf-stat.iTLB-loads
3.006e+11 ~ 0% +2.6% 3.084e+11 ~ 0% TOTAL
perf-stat.branch-instructions
1.793e+12 ~ 0% +2.8% 1.843e+12 ~ 0% TOTAL perf-stat.cpu-cycles
3.352e+11 ~ 1% +2.9% 3.451e+11 ~ 0% TOTAL perf-stat.dTLB-stores
2.994e+11 ~ 1% +3.1% 3.087e+11 ~ 0% TOTAL perf-stat.branch-loads
1.49e+12 ~ 0% +2.9% 1.533e+12 ~ 0% TOTAL perf-stat.instructions
5.48e+11 ~ 0% +2.8% 5.633e+11 ~ 0% TOTAL perf-stat.dTLB-loads
2.028e+11 ~ 1% +2.9% 2.086e+11 ~ 1% TOTAL perf-stat.bus-cycles
5.484e+11 ~ 0% +2.9% 5.644e+11 ~ 0% TOTAL perf-stat.L1-dcache-loads
1.829e+12 ~ 0% +2.7% 1.877e+12 ~ 1% TOTAL perf-stat.ref-cycles
Legend:
~XX%- stddev percent
[+-]XX% - change percent
Attach full stats changes entries for reference.
Thanks,
Jet
mkfs -t ext4 -q /dev/sda1
echo 1 > /sys/kernel/debug/tracing/events/writeback/balance_dirty_pages/enable
echo 1 > /sys/kernel/debug/tracing/events/writeback/bdi_dirty_ratelimit/enable
echo 1 > /sys/kernel/debug/tracing/events/writeback/global_dirty_state/enable
echo 1 >
/sys/kernel/debug/tracing/events/writeback/writeback_single_inode/enable
mount -t ext4 /dev/sda1 /fs/sda1
dd if=/dev/zero of=/fs/sda1/zero-1 status=none &
sleep 600
killall -9 dd
2cf532f5e67c0cf 8a4aeec8d2d6a3edeffbdfae4
--- -
1.23 ~ 8% -30.0% 0.86 ~15% bay/micro/dd-write/1HDD-cfq-ext4-1dd
1.23 ~ 8% -30.0% 0.86 ~15% TOTAL
perf-profile.cpu-cycles.jbd2_journal_add_journal_head.jbd2_journal_get_write_access.__ext4_journal_get_write_access.ext4_reserve_inode_write.ext4_mark_inode_dirty
2cf532f5e67c0cf 8a4aeec8d2d6a3edeffbdfae4
--- -
56347 ~ 0% -26.3% 41535 ~ 5% bay/micro/dd-write/1HDD-cfq-ext4-1dd
56543 ~ 0% -32.9% 37934 ~ 0% bay/micro/dd-write/1HDD-cfq-xfs-1dd
112890 ~ 0% -29.6% 79469 ~ 2% TOTAL softirqs.BLOCK
2cf532f5e67c0cf 8a4aeec8d2d6a3edeffbdfae4
--- -
0.95 ~12% -26.0% 0.70 ~ 7% bay/micro/dd-write/1HDD-cfq-ext4-1dd
0.95 ~12% -26.0% 0.70 ~ 7% TOTAL
perf-profile.cpu-cycles.jbd2_journal_put_journal_head.__ext4_handle_dirty_metadata.ext4_mark_iloc_dirty.ext4_mark_inode_dirty.ext4_dirty_inode
2cf532f5e67c0cf 8a4aeec8d2d6a3edeffbdfae4
--- -
0.95 ~ 5% -18.2% 0.77 ~24% bay/micro/dd-write/1HDD-cfq-ext4-1dd
0.95 ~ 5% -18.2% 0.77 ~24% TOTAL
perf-profile.cpu-cycles.generic_file_aio_write.ext4_file_write.do_sync_write.vfs_write.sys_write
2cf532f5e67c0cf 8a4aeec8d2d6a3edeffbdfae4
--- -
2468 ~ 3% +19.5% 2949 ~ 6% bay/micro/dd-write/1HDD-cfq-ext4-1dd
2468 ~ 3% +19.5% 2949 ~ 6% TOTAL
proc-vmstat.kswapd_high_wmark_hit_quickly
2cf532f5e67c0cf
[no subject]
unsubscribe linux-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/
[PATCH] Documentation/memcg: warn about incomplete kmemcg state
Kmemcg is currently under development and lacks some important features. In particular, it does not have support of kmem reclaim on memory pressure inside cgroup, which practically makes it unusable in real life. Let's warn about it in both Kconfig and Documentation to prevent complaints arising. Signed-off-by: Vladimir Davydov --- Documentation/cgroups/memory.txt |5 + init/Kconfig |6 ++ 2 files changed, 11 insertions(+) diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 2622115276aa..af3cdfa3c07a 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -270,6 +270,11 @@ When oom event notifier is registered, event will be delivered. 2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM) +WARNING: Current implementation lacks reclaim support. That means allocation +attempts will fail when close to the limit even if there are plenty of +kmem available for reclaim. That makes this option unusable in real +life so DO NOT SELECT IT unless for development purposes. + With the Kernel memory extension, the Memory Controller is able to limit the amount of kernel memory used by the system. Kernel memory is fundamentally different than user memory, since it can't be swapped out, which makes it diff --git a/init/Kconfig b/init/Kconfig index 427ba60d638f..4d6e645c8ad4 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -993,6 +993,12 @@ config MEMCG_KMEM the kmem extension can use it to guarantee that no group of processes will ever exhaust kernel resources alone. + WARNING: Current implementation lacks reclaim support. That means + allocation attempts will fail when close to the limit even if there + are plenty of kmem available for reclaim. That makes this option + unusable in real life so DO NOT SELECT IT unless for development + purposes. + config CGROUP_HUGETLB bool "HugeTLB Resource Controller for Control Groups" depends on RESOURCE_COUNTERS && HUGETLB_PAGE -- 1.7.10.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 2/6] m68k: call find_vma with the mmap_sem held in sys_cacheflush()
Hi David,
On Mon, Apr 21, 2014 at 12:28 AM, Davidlohr Bueso wrote:
> On Sun, 2014-04-20 at 10:04 +0200, Geert Uytterhoeven wrote:
>> On Sun, Apr 20, 2014 at 4:26 AM, Davidlohr Bueso wrote:
>> > Performing vma lookups without taking the mm->mmap_sem is asking
>> > for trouble. While doing the search, the vma in question can be
>> > modified or even removed before returning to the caller. Take the
>> > lock (shared) in order to avoid races while iterating through
>> > the vmacache and/or rbtree.
>>
>> Thanks for your patch!
>>
>> > This patch is completely *untested*.
>> >
>> > Signed-off-by: Davidlohr Bueso
>> > Cc: Geert Uytterhoeven
>> > Cc: linux-m...@lists.linux-m68k.org
>> > ---
>> > arch/m68k/kernel/sys_m68k.c | 18 --
>> > 1 file changed, 12 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/arch/m68k/kernel/sys_m68k.c b/arch/m68k/kernel/sys_m68k.c
>> > index 3a480b3..d2263a0 100644
>> > --- a/arch/m68k/kernel/sys_m68k.c
>> > +++ b/arch/m68k/kernel/sys_m68k.c
>> > @@ -376,7 +376,6 @@ cache_flush_060 (unsigned long addr, int scope, int
>> > cache, unsigned long len)
>> > asmlinkage int
>> > sys_cacheflush (unsigned long addr, int scope, int cache, unsigned long
>> > len)
>> > {
>> > - struct vm_area_struct *vma;
>> > int ret = -EINVAL;
>> >
>> > if (scope < FLUSH_SCOPE_LINE || scope > FLUSH_SCOPE_ALL ||
>> > @@ -389,16 +388,23 @@ sys_cacheflush (unsigned long addr, int scope, int
>> > cache, unsigned long len)
>> > if (!capable(CAP_SYS_ADMIN))
>> > goto out;
>> > } else {
>> > + struct vm_area_struct *vma;
>> > + bool invalid;
>> > +
>> > + /* Check for overflow. */
>> > + if (addr + len < addr)
>> > + goto out;
>> > +
>> > /*
>> > * Verify that the specified address region actually
>> > belongs
>> > * to this process.
>> > */
>> > - vma = find_vma (current->mm, addr);
>> > ret = -EINVAL;
>> > - /* Check for overflow. */
>> > - if (addr + len < addr)
>> > - goto out;
>> > - if (vma == NULL || addr < vma->vm_start || addr + len >
>> > vma->vm_end)
>> > + down_read(>mm->mmap_sem);
>> > + vma = find_vma(current->mm, addr);
>> > + invalid = !vma || addr < vma->vm_start || addr + len >
>> > vma->vm_end;
>> > + up_read(>mm->mmap_sem);
>> > + if (invalid)
>> > goto out;
>> > }
>>
>> Shouldn't the up_read() be moved to the end of the function?
>> The vma may still be modified or destroyed between the call to find_vma(),
>> and the actual cache flush?
>
> I don't think so. afaict the vma is only searched to check upon validity
> for the address being passed. Once the sem is dropped, the call doesn't
> do absolutely anything else with the returned vma.
The function indeed doesn't do anything anymore with the vma itself, but
it does do something with the addr/len pair, which may no longer match
with the vma if it changes after the up_read(). I.e. the address may no longer
be valid when the cache is actually flushed.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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/3] cpufreq: ppc: Fix handling of non-existent clocks
Hi Viresh,
On Mon, Apr 21, 2014 at 8:01 AM, Viresh Kumar wrote:
> On 17 April 2014 15:23, Geert Uytterhoeven wrote:
>> If the clock doesn't exist, clk_get_rate() returns -EINVAL
>
> You clk_get_rate() isn't written well then, it should return zero.
You're right, thanks!
Once again I looked at the wrong clk_get_rate() implementation :-(
These non-CCF variants should die soon...
So the original code was correct: if the clock is not valid, freq == 0,
and thus "freq < min_cpufreq" is true.
> @Mike: I didn't see this clearly mentioned in clk.h, should we fix
> that?
>
>>, which becomes
>> a large number (freq is u32), failing the "freq < min_cpufreq" test.
>> Explicitly test for "(u32)-EINVAL" to fix this.
>
> That's a bad check. We should have done this instead:
>
> (s32)freq < 0; but that would be true for high values of clock. And that's
> why clk_get_rate() must return zero for errors.
>
>> Update the comment, and fix a grammer issue while we're at it.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> drivers/cpufreq/ppc-corenet-cpufreq.c |7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
>> b/drivers/cpufreq/ppc-corenet-cpufreq.c
>> index 53881d78a931..7027eab814ce 100644
>> --- a/drivers/cpufreq/ppc-corenet-cpufreq.c
>> +++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
>> @@ -179,10 +179,11 @@ static int corenet_cpufreq_cpu_init(struct
>> cpufreq_policy *policy)
>> clk = of_clk_get(data->parent, i);
>> freq = clk_get_rate(clk);
>> /*
>> -* the clock is valid if its frequency is not masked
>> -* and large than minimum allowed frequency.
>> +* the clock is valid if it exists, its frequency is not
>> +* masked, and larger than minimum allowed frequency.
>> */
>> - if (freq < min_cpufreq || (mask & (1 << i)))
>> + if (freq == (u32)-EINVAL || freq < min_cpufreq ||
>> + (mask & (1 << i)))
>> table[i].frequency = CPUFREQ_ENTRY_INVALID;
>> else
>> table[i].frequency = freq / 1000;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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] scripts/tags.sh: ignore code of user space tools
User space code in tools/ often reuses names of kernel constructions,
this confuses navigation in the normal kernel code. Let's fix this mess.
Signed-off-by: Konstantin Khlebnikov
---
scripts/tags.sh |3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/tags.sh b/scripts/tags.sh
index f2c5b00..7f506e0 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -25,6 +25,9 @@ else
tree=${srctree}/
fi
+# ignore userspace tools
+ignore="$ignore ( -path ${tree}tools ) -prune -o"
+
# Find all available archs
find_all_archs()
{
--
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 0/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support
Changes in V2: - Add big-endian support. - Add using pr_err instead of BUG_ON. - Add more detail comment message of FTM. - Add DT binding documentation. - Remove some header files and macros not useful. Xiubo Li (3): clocksource: ftm: Add FlexTimer Module (FTM) Timer devicetree Documentation ARM: dts: vf610: Add Freescale FlexTimer Module timer node. clocksource: Add Freescale FlexTimer Module (FTM) timer support .../devicetree/bindings/timer/fsl,ftm-timer.txt| 31 ++ arch/arm/boot/dts/vf610.dtsi | 12 + drivers/clocksource/Kconfig| 5 + drivers/clocksource/Makefile | 1 + drivers/clocksource/fsl_ftm_timer.c| 344 + 5 files changed, 393 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt create mode 100644 drivers/clocksource/fsl_ftm_timer.c -- 1.8.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 3/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support
The Freescale FlexTimer Module time reference is a 16-bit counter
that can be used as an unsigned or signed increase counter.
CNTIN defines the starting value of the count and MOD defines the
final value of the count. The value of CNTIN is loaded into the FTM
counter, and the counter increments until the value of MOD is reached,
at which point the counter is reloaded with the value of CNTIN. That's
also when an overflow interrupt will be generated.
Here using the 'evt' prefix or postfix as clock event device and
the 'src' as clock source device.
Signed-off-by: Xiubo Li
Cc: Shawn Guo
Cc: Jingchang Lu
---
drivers/clocksource/Kconfig | 5 +
drivers/clocksource/Makefile| 1 +
drivers/clocksource/fsl_ftm_timer.c | 344
3 files changed, 350 insertions(+)
create mode 100644 drivers/clocksource/fsl_ftm_timer.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cd6950f..28321c5 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -136,6 +136,11 @@ config CLKSRC_SAMSUNG_PWM
for all devicetree enabled platforms. This driver will be
needed only on systems that do not have the Exynos MCT available.
+config FSL_FTM_TIMER
+ bool
+ help
+ Support for Freescale FlexTimer Module (FTM) timer.
+
config VF_PIT_TIMER
bool
help
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index c7ca50a..ce0a967 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_CADENCE_TTC_TIMER) += cadence_ttc_timer.o
obj-$(CONFIG_CLKSRC_EFM32) += time-efm32.o
obj-$(CONFIG_CLKSRC_EXYNOS_MCT)+= exynos_mct.o
obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
+obj-$(CONFIG_FSL_FTM_TIMER)+= fsl_ftm_timer.o
obj-$(CONFIG_VF_PIT_TIMER) += vf_pit_timer.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
diff --git a/drivers/clocksource/fsl_ftm_timer.c
b/drivers/clocksource/fsl_ftm_timer.c
new file mode 100644
index 000..33de144
--- /dev/null
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -0,0 +1,344 @@
+/*
+ * Freescale FlexTimer Module (FTM) timer driver.
+ *
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FTM_SC 0x00
+#define FTM_SC_CLK_SHIFT 3
+#define FTM_SC_CLK_MASK(0x3 << FTM_SC_CLK_SHIFT)
+#define FTM_SC_CLK(c) ((c) << FTM_SC_CLK_SHIFT)
+#define FTM_SC_PS_MASK 0x7
+#define FTM_SC_TOIEBIT(6)
+#define FTM_SC_TOF BIT(7)
+
+#define FTM_CNT0x04
+#define FTM_MOD0x08
+#define FTM_CNTIN 0x4C
+
+static void __iomem *clksrc_base;
+static void __iomem *clkevt_base;
+static unsigned long peroidic_cyc;
+static unsigned long ps;
+bool big_endian;
+
+static inline u32 ftm_readl(void __iomem *addr)
+{
+ if (big_endian)
+ return ioread32be(addr);
+ else
+ return ioread32(addr);
+}
+
+static inline void ftm_writel(u32 val, void __iomem *addr)
+{
+ if (big_endian)
+ iowrite32be(val, addr);
+ else
+ iowrite32(val, addr);
+}
+
+static inline void ftm_counter_enable(void __iomem *base)
+{
+ u32 val;
+
+ /* select and enable counter clock source */
+ val = ftm_readl(base + FTM_SC);
+ val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+ val |= ps | FTM_SC_CLK(1);
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_counter_disable(void __iomem *base)
+{
+ u32 val;
+
+ /* disable counter clock source */
+ val = ftm_readl(base + FTM_SC);
+ val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_acknowledge(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val &= ~FTM_SC_TOF;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_enable(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val |= FTM_SC_TOIE;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_disable(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val |= FTM_SC_TOIE;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_reset_counter(void __iomem *base)
+{
+ /*
+* The CNT register contains the FTM counter value.
+* Reset clears the CNT register. Writing any value to COUNT
+* updates the counter with its initial value, CNTIN.
+*/
+ ftm_writel(0x00, base +
[PATCH 1/3] clocksource: ftm: Add FlexTimer Module (FTM) Timer devicetree Documentation
The FTM binding could be used on Vybrid and LS1+, add a binding
document for it.
Signed-off-by: Xiubo Li
Cc: Shawn Guo
Cc: Jingchang Lu
---
.../devicetree/bindings/timer/fsl,ftm-timer.txt| 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
new file mode 100644
index 000..aa8c402
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
@@ -0,0 +1,31 @@
+Freescale FlexTimer Module (FTM) Timer
+
+Required properties:
+
+- compatible : should be "fsl,ftm-timer"
+- reg : Specifies base physical address and size of the register sets for the
+ clock event device and clock source device.
+- interrupts : Should be the clock event device interrupt.
+- clocks : The clocks provided by the SoC to drive the timer, must contain an
+ entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ o "ftm-evt"
+ o "ftm-src"
+ o "ftm-evt-counter-en"
+ o "ftm-src-counter-en"
+- big-endian: One boolean property, the big endian mode will be in use if it is
+ present, or the little endian mode will be in use for all the device
registers.
+
+Example:
+ftm: ftm@400b8000 {
+ compatible = "fsl,ftm-timer";
+ reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
+ interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "ftm-evt", "ftm-src",
+ "ftm-evt-counter-en", "ftm-src-counter-en";
+ clocks = < VF610_CLK_FTM2>,
+ < VF610_CLK_FTM3>,
+ < VF610_CLK_FTM2_EXT_FIX_EN>,
+ < VF610_CLK_FTM3_EXT_FIX_EN>;
+ big-endian;
+};
--
1.8.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] ARM: dts: vf610: Add Freescale FlexTimer Module timer node.
Signed-off-by: Xiubo Li
Cc: Shawn Guo
Cc: Jingchang Lu
---
arch/arm/boot/dts/vf610.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 107e2c0..7e30bb1 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -281,6 +281,18 @@
status = "disabled";
};
+ ftm: ftm@400b8000 {
+ compatible = "fsl,ftm-timer";
+ reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
+ interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "ftm-evt", "ftm-src",
+ "ftm-evt-counter-en",
"ftm-src-counter-en";
+ clocks = < VF610_CLK_FTM2>,
+ < VF610_CLK_FTM3>,
+ < VF610_CLK_FTM2_EXT_FIX_EN>,
+ < VF610_CLK_FTM3_EXT_FIX_EN>;
+ };
+
fec0: ethernet@400d {
compatible = "fsl,mvf600-fec";
reg = <0x400d 0x1000>;
--
1.8.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/
[PATCHv2 1/3] clocksource: ftm: Add FlexTimer Module (FTM) Timer devicetree Documentation
The FTM binding could be used on Vybrid and LS1+, add a binding
document for it.
Signed-off-by: Xiubo Li
Cc: Shawn Guo
Cc: Jingchang Lu
---
.../devicetree/bindings/timer/fsl,ftm-timer.txt| 31 ++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
new file mode 100644
index 000..aa8c402
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
@@ -0,0 +1,31 @@
+Freescale FlexTimer Module (FTM) Timer
+
+Required properties:
+
+- compatible : should be "fsl,ftm-timer"
+- reg : Specifies base physical address and size of the register sets for the
+ clock event device and clock source device.
+- interrupts : Should be the clock event device interrupt.
+- clocks : The clocks provided by the SoC to drive the timer, must contain an
+ entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+ o "ftm-evt"
+ o "ftm-src"
+ o "ftm-evt-counter-en"
+ o "ftm-src-counter-en"
+- big-endian: One boolean property, the big endian mode will be in use if it is
+ present, or the little endian mode will be in use for all the device
registers.
+
+Example:
+ftm: ftm@400b8000 {
+ compatible = "fsl,ftm-timer";
+ reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
+ interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "ftm-evt", "ftm-src",
+ "ftm-evt-counter-en", "ftm-src-counter-en";
+ clocks = < VF610_CLK_FTM2>,
+ < VF610_CLK_FTM3>,
+ < VF610_CLK_FTM2_EXT_FIX_EN>,
+ < VF610_CLK_FTM3_EXT_FIX_EN>;
+ big-endian;
+};
--
1.8.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/
[PATCHv2 0/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support
Changes in V2: - Add big-endian support. - Add using pr_err instead of BUG_ON. - Add more detail comment message of FTM. - Add DT binding documentation. - Remove some header files and macros not useful. Xiubo Li (3): clocksource: ftm: Add FlexTimer Module (FTM) Timer devicetree Documentation ARM: dts: vf610: Add Freescale FlexTimer Module timer node. clocksource: Add Freescale FlexTimer Module (FTM) timer support .../devicetree/bindings/timer/fsl,ftm-timer.txt| 31 ++ arch/arm/boot/dts/vf610.dtsi | 12 + drivers/clocksource/Kconfig| 5 + drivers/clocksource/Makefile | 1 + drivers/clocksource/fsl_ftm_timer.c| 344 + 5 files changed, 393 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt create mode 100644 drivers/clocksource/fsl_ftm_timer.c -- 1.8.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/
[PATCHv2 3/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support
The Freescale FlexTimer Module time reference is a 16-bit counter
that can be used as an unsigned or signed increase counter.
CNTIN defines the starting value of the count and MOD defines the
final value of the count. The value of CNTIN is loaded into the FTM
counter, and the counter increments until the value of MOD is reached,
at which point the counter is reloaded with the value of CNTIN. That's
also when an overflow interrupt will be generated.
Here using the 'evt' prefix or postfix as clock event device and
the 'src' as clock source device.
Signed-off-by: Xiubo Li
Cc: Shawn Guo
Cc: Jingchang Lu
---
drivers/clocksource/Kconfig | 5 +
drivers/clocksource/Makefile| 1 +
drivers/clocksource/fsl_ftm_timer.c | 344
3 files changed, 350 insertions(+)
create mode 100644 drivers/clocksource/fsl_ftm_timer.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cd6950f..28321c5 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -136,6 +136,11 @@ config CLKSRC_SAMSUNG_PWM
for all devicetree enabled platforms. This driver will be
needed only on systems that do not have the Exynos MCT available.
+config FSL_FTM_TIMER
+ bool
+ help
+ Support for Freescale FlexTimer Module (FTM) timer.
+
config VF_PIT_TIMER
bool
help
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index c7ca50a..ce0a967 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_CADENCE_TTC_TIMER) += cadence_ttc_timer.o
obj-$(CONFIG_CLKSRC_EFM32) += time-efm32.o
obj-$(CONFIG_CLKSRC_EXYNOS_MCT)+= exynos_mct.o
obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
+obj-$(CONFIG_FSL_FTM_TIMER)+= fsl_ftm_timer.o
obj-$(CONFIG_VF_PIT_TIMER) += vf_pit_timer.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
diff --git a/drivers/clocksource/fsl_ftm_timer.c
b/drivers/clocksource/fsl_ftm_timer.c
new file mode 100644
index 000..33de144
--- /dev/null
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -0,0 +1,344 @@
+/*
+ * Freescale FlexTimer Module (FTM) timer driver.
+ *
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FTM_SC 0x00
+#define FTM_SC_CLK_SHIFT 3
+#define FTM_SC_CLK_MASK(0x3 << FTM_SC_CLK_SHIFT)
+#define FTM_SC_CLK(c) ((c) << FTM_SC_CLK_SHIFT)
+#define FTM_SC_PS_MASK 0x7
+#define FTM_SC_TOIEBIT(6)
+#define FTM_SC_TOF BIT(7)
+
+#define FTM_CNT0x04
+#define FTM_MOD0x08
+#define FTM_CNTIN 0x4C
+
+static void __iomem *clksrc_base;
+static void __iomem *clkevt_base;
+static unsigned long peroidic_cyc;
+static unsigned long ps;
+bool big_endian;
+
+static inline u32 ftm_readl(void __iomem *addr)
+{
+ if (big_endian)
+ return ioread32be(addr);
+ else
+ return ioread32(addr);
+}
+
+static inline void ftm_writel(u32 val, void __iomem *addr)
+{
+ if (big_endian)
+ iowrite32be(val, addr);
+ else
+ iowrite32(val, addr);
+}
+
+static inline void ftm_counter_enable(void __iomem *base)
+{
+ u32 val;
+
+ /* select and enable counter clock source */
+ val = ftm_readl(base + FTM_SC);
+ val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+ val |= ps | FTM_SC_CLK(1);
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_counter_disable(void __iomem *base)
+{
+ u32 val;
+
+ /* disable counter clock source */
+ val = ftm_readl(base + FTM_SC);
+ val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_acknowledge(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val &= ~FTM_SC_TOF;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_enable(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val |= FTM_SC_TOIE;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_disable(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val |= FTM_SC_TOIE;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_reset_counter(void __iomem *base)
+{
+ /*
+* The CNT register contains the FTM counter value.
+* Reset clears the CNT register. Writing any value to COUNT
+* updates the counter with its initial value, CNTIN.
+*/
+ ftm_writel(0x00, base +
[PATCHv2 2/3] ARM: dts: vf610: Add Freescale FlexTimer Module timer node.
Signed-off-by: Xiubo Li
Cc: Shawn Guo
Cc: Jingchang Lu
---
arch/arm/boot/dts/vf610.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 107e2c0..7e30bb1 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -281,6 +281,18 @@
status = "disabled";
};
+ ftm: ftm@400b8000 {
+ compatible = "fsl,ftm-timer";
+ reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
+ interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "ftm-evt", "ftm-src",
+ "ftm-evt-counter-en",
"ftm-src-counter-en";
+ clocks = < VF610_CLK_FTM2>,
+ < VF610_CLK_FTM3>,
+ < VF610_CLK_FTM2_EXT_FIX_EN>,
+ < VF610_CLK_FTM3_EXT_FIX_EN>;
+ };
+
fec0: ethernet@400d {
compatible = "fsl,mvf600-fec";
reg = <0x400d 0x1000>;
--
1.8.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 0/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support
@All, Please ignore this patch series, I just forgot the V2 tag, I have resent a New one. Thanks, BRs Xiubo > -Original Message- > From: Xiubo Li [mailto:li.xi...@freescale.com] > Sent: Monday, April 21, 2014 3:20 PM > To: daniel.lezc...@linaro.org; t...@linutronix.de; shawn@linaro.org; Jin > Zhengxiong-R64188; Wang Dongsheng-B40534; Lu Jingchang-B35083 > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Xiubo Li- > B47053 > Subject: [PATCH 0/3] clocksource: Add Freescale FlexTimer Module (FTM) timer > support > > > Changes in V2: > - Add big-endian support. > - Add using pr_err instead of BUG_ON. > - Add more detail comment message of FTM. > - Add DT binding documentation. > - Remove some header files and macros not useful. > > > > Xiubo Li (3): > clocksource: ftm: Add FlexTimer Module (FTM) Timer devicetree > Documentation > ARM: dts: vf610: Add Freescale FlexTimer Module timer node. > clocksource: Add Freescale FlexTimer Module (FTM) timer support > > .../devicetree/bindings/timer/fsl,ftm-timer.txt| 31 ++ > arch/arm/boot/dts/vf610.dtsi | 12 + > drivers/clocksource/Kconfig| 5 + > drivers/clocksource/Makefile | 1 + > drivers/clocksource/fsl_ftm_timer.c| 344 > + > 5 files changed, 393 insertions(+) > create mode 100644 Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt > create mode 100644 drivers/clocksource/fsl_ftm_timer.c > > -- > 1.8.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 06/15] m68k: add renameat2 syscall
Hi Miklos,
On Fri, Apr 11, 2014 at 12:25 PM, Miklos Szeredi wrote:
> --- a/arch/m68k/kernel/syscalltable.S
> +++ b/arch/m68k/kernel/syscalltable.S
> @@ -371,4 +371,5 @@ ENTRY(sys_call_table)
> .long sys_finit_module
> .long sys_sched_setattr
> .long sys_sched_getattr /* 350 */
> + .long sys_sched_renameat2
"sys_renameat2", please.
Sorry for not noticing before I threw it at the compiler.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 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 12/12] cgroup: implement dynamic subtree controller enable/disable on the default hierarchy
On 04/19/2014 02:11 AM, Tejun Heo wrote: Hello, On Thu, Apr 17, 2014 at 11:33:50PM +0530, Raghavendra KT wrote: On Tue, Apr 15, 2014 at 3:07 AM, Tejun Heo wrote: I undertsand that with the above parsing we could do echo "-blkio +blkio" > cgroup.subtree_control and honor last enable/disable. Yeah, and the behavior is described in the following document. Hello Tejun, Thanks for the kind reply. The document has helped me a lot while reviewing,testing the unified hierarchy code. http://lkml.kernel.org/g/20140416145248.gd1...@htj.dyndns.org It confused me while testing. do you think we should return -EINVAL in such case? Hmmm... I think whatever comes later wins is a pretty clear and easy rule, no? Very much correct. and if there is a feeling to check multiple entry later I would happy to update the code. -- 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 00/28] nios2 Linux kernel port
On 14/4/21 1:31 PM, H. Peter Anvin wrote: > On 04/20/2014 10:23 PM, Ley Foon Tan wrote: >> On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann wrote: >>> On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? >>> >>> No, unfortunately not. With my rule that every architecture that gets >>> added needs to clean up asm-generic some more, to make it easier to add >>> the next one, we should probably do for nios2. >>> >>> Arnd >> >> Can you give me the documentation on this new guidance and point me >> any architecture have implemented this? >> Thanks. >> > > We implemented it in the x32 ABI for x86. In generic code this is keyed > by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of > compat, so it should be easier. > > See this thread including the discussion about time_t: > > https://lkml.org/lkml/2011/8/26/415 > > -hpa I'm not sure why we need CONFIG_USE_64BIT_TIME? We don't have any 32-on-64 problems. My understanding of what Arnd meant, was to clean up asm-generic/posix_types.h such that for example, time_t should be defined as a 'long long' type, which should be 64-bit almost everywhere. At least AFAIK, that should work for all current asm-generic users. Thanks, Chung-Lin -- 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: Locking issues in "mmc: rtsx: add support for pre_req and post_req"
Hi Peter,
I'm considering not using spinlock to get it work and will resend the
patch later.
Thank you.
Best Regards.
micky
On 04/19/2014 07:13 AM, Peter Wu wrote:
So, I reverted c42deffd5b53c9e583d83c7964854ede2f12410d ("mmc: rtsx: add
support for pre_req and post_req") on top of v3.15-rc1-49-g10ec34f and the
hang issue went away.
There is something that is possibly problematic. All three tasklets (cmd,
data, finish) try to spinlock on host->lock. According to the tasklets
documentation[1], they always run at interrupts (i.e., at any time, possibly
right after tasklet_schedule if I got this right?).
These tasklets however do get scheduled *under* the host->lock which will
cause a deadlock. This proposed patch ("mmc: rtsx: fix possible circular
locking dependency") fixes the issue for sd_isr_done_transfer, but there are
others:
1. sd_request_timeout:
125 spin_lock_irqsave(>lock, flags);
...
139 out:
140 tasklet_schedule(>finish_tasklet); // <--
141 spin_unlock_irqrestore(>lock, flags);
2. sd_get_rsp (cmd_tasklet!):
429 spin_lock_irqsave(>lock, flags);
...
506 tasklet_schedule(>finish_tasklet); // <--
507 spin_unlock_irqrestore(>lock, flags);
3. sd_finish_multi_rw (data_tasklet!):
657 spin_lock_irqsave(>lock, flags);
...
684 tasklet_schedule(>finish_tasklet); // <--
685 spin_unlock_irqrestore(>lock, flags);
4. sdmmc_request:
921 mutex_lock(>pcr_mutex);
922 spin_lock_irqsave(>lock, flags);
...
967 tasklet_schedule(>finish_tasklet); // <--
968 spin_unlock_irqrestore(>lock, flags);
5. rtsx_pci_sdmmc_drv_remove:
1526 spin_lock_irqsave(>lock, flags);
1527 if (host->mrq) {
...
1541 tasklet_schedule(>finish_tasklet); // <--
1542 }
1543 spin_unlock_irqrestore(>lock, flags);
1544
1545 del_timer_sync(>timer);
1546 tasklet_kill(>cmd_tasklet);
1547 tasklet_kill(>data_tasklet);
1548 tasklet_kill(>finish_tasklet); // <--
pcr_mutex (un)locking:
- gets locked in sdmmc_request
- gets unlocked in sd_finish_request (finish_tasklet).
- gets locked/unlocked in sdmmc_set_ios
- gets locked/unlocked in sdmmc_get_ro
- gets locked/unlocked in sdmmc_get_cd
- gets locked/unlocked in sdmmc_switch_voltage
- gets locked/unlocked in sdmmc_execute_tuning
finish_tasklet (sd_finish_request()) gets scheduled in:
- sd_request_timeout (under host->lock; called on timer expiration)
- error path of sd_send_cmd
- get_rsp (cmd_tasklet; under host->lock)
- error path of sd_start_multi_rw (after mod timer)
- sd_finish_multi_rw (under host->lock)
- sdmmc_request (under host->lock in error path; without host->lock
elsewhere)
- rtsx_pci_sdmmc_drv_remove (under host->lock)
sd_request_timeout (timer) related:
- deleted in sd_finish_request under host->lock (also assumes pcr_mutex)
- sd_send_cmd (timer set with 100ms timeout, not called in error path)
- sd_start_multi_rw (timeout set to 10 HZ, called before error path is
checked in which finish_tasklet gets scheduled)
Note: sd_request_timeout claims+releases host->lock.
If I understand it correctly, host->lock is responsible for protecting the
realtek_pci_sdmmc structure. Why is tasklet_schedule() on the same lock?
Shouldn't the above five tasklet_schedule calls be moved outside the lock?
Will it be problematic if the same tasklet gets executed multiple times (if
that is possible?).
Does it really need that much locking? dw_mmc.c also implements pre_req, but
uses tasklets without needing to lock anything.
Kind regards,
Peter
[1]: http://www.makelinux.net/ldd3/chp-7-sect-5
On Friday 18 April 2014 16:00:53 Peter Wu wrote:
On Wednesday 16 April 2014 09:38:44 micky_ch...@realsil.com.cn wrote:
From: Micky Ching
To avoid dead lock, we need make sure host->lock is always acquire
before pcr->lock. But in irq handler, we acquired pcr->lock in rtsx mfd
driver, and sd_isr_done_transfer() is called during pcr->lock already
acquired. Since in sd_isr_done_transfer() the only work we do is schdule
tasklet, the cmd_tasklet and data_tasklet never conflict, so it is safe
to remove spin_lock() here.
Signed-off-by: Micky Ching
---
drivers/mmc/host/rtsx_pci_sdmmc.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
This patch came from
https://lkml.kernel.org/r/534de1d7.3000...@realsil.com.cn ("Re:
rtsx_pci_sdmmc lockdep splat").
With v3.15-rc1-49-g10ec34f, I have a hung machine when inserting a SD card.
lockdep was not enabled for the kernel, I have not bisected yet.
This patch on top of that kernel version does not help (tested by
rmmod rtsx_pci_sdmmc and insmod the patched one).
Console (as typed over from a picture, sorry for any typos):
WARNING: CPU: 1 PID: 0 at kernel/locking/mutex.c:698
DEBUG_LOCKS_WARN_ON(in_interrupt())
Modules linked in: ...
CPU: 1 PID: 0 Comm: swapper/1 Not
Re: 3.14 regression: huge latency in read/select on tun
On 20.04.2014 18:31, Eric Dumazet wrote:> On Sat, 2014-04-19 at 22:13
+0200, Ortwin Glück wrote:
>> On 03.04.2014 15:50, Eric Dumazet wrote:
>>
>> I finally found time to bisect this:
>>
>> commit 53d6471cef17262d3ad1c7ce8982a234244f68ec
>> Author: Vlad Yasevich
>> Date: Thu Mar 27 17:26:18 2014 -0400
>>
>> net: Account for all vlan headers in skb_mac_gso_segment
>
> Hmm.. probably already solved by commit
> 1e785f48d29a09b6cf96db7b49b6320dada332e1
> ("net: Start with correct mac_len in skb_network_protocol")
Indeed that fixes it. I have cherry picked that onto 3.14 and it works.
That means 1e785f48 should be applied to stable 3.13.y and 3.14.y too.
Thanks,
Ortwin
--
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: inotify, new idea?
Am 21.04.2014 09:24, schrieb Michael Kerrisk: >> Does recursive monitoring even work with inotify? >> Last time I've tried it did failed as soon I did a mkdir -p a/b/c/d because >> mkdir() raced against the thread which installes the new watches. > > As I understand it, you have to program to deal with the races (rescan > directories after adding watches). I recently did a lot of work > updating the inotify(7) man page to discuss all the issues that I know > of, and their remedies. If I missed anything, I'd appreciate a note on > it, so that it can be added. See > http://man7.org/linux/man-pages/man7/inotify.7.html#NOTES I'm aware of the rescan hack, but in my case it does not help because my program must not miss any event. Currently I'm using a fuse overlay filesystem to log everything. Not perfect but works... :-) 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: rtsx_pci_sdmmc lockdep splat
Hi Borislav
Thank you for test the patch. It seems we can't use tasklet here due to
mutex_lock.
And the spinlock may removed, I'm prepare to resend a different patch later.
Best Regards.
micky
On 04/20/2014 08:20 PM, Borislav Petkov wrote:
Hi,
On Wed, Apr 16, 2014 at 09:50:15AM +0800, micky wrote:
From: Micky Ching
To avoid dead lock, we need make sure host->lock is always acquire
before pcr->lock. But in irq handler, we acquired pcr->lock in rtsx mfd
driver, and sd_isr_done_transfer() is called during pcr->lock already
acquired. Since in sd_isr_done_transfer() the only work we do is schdule
tasklet, the cmd_tasklet and data_tasklet never conflict, so it is safe
to remove spin_lock() here.
Signed-off-by: Micky Ching
---
drivers/mmc/host/rtsx_pci_sdmmc.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 453e1d4..40695e0 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -108,12 +108,10 @@ static void sd_isr_done_transfer(struct platform_device
*pdev)
{
struct realtek_pci_sdmmc *host = platform_get_drvdata(pdev);
- spin_lock(>lock);
if (host->cmd)
tasklet_schedule(>cmd_tasklet);
- if (host->data)
+ else if (host->data)
tasklet_schedule(>data_tasklet);
- spin_unlock(>lock);
}
static void sd_request_timeout(unsigned long host_addr)
--
Patch wouldn't apply against rc1, so I had to add it by hand, diff
below.
---
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 5fb994f9a653..d1d65c0d8d2e 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -109,12 +109,10 @@ static void sd_isr_done_transfer(struct platform_device
*pdev)
{
struct realtek_pci_sdmmc *host = platform_get_drvdata(pdev);
- spin_lock(>lock);
if (host->cmd)
tasklet_schedule(>cmd_tasklet);
- if (host->data)
+ else if (host->data)
tasklet_schedule(>data_tasklet);
- spin_unlock(>lock);
}
static void sd_request_timeout(unsigned long host_addr)
--
Still needs more love:
[ 95.112797] rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sdmmc_get_cd: RTSX_BIPR =
0x0001
[ 95.115700] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz
[ 95.118040] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 21 width 0 timing 0
[ 95.122504] rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sdmmc_switch_voltage:
signal_voltage = 0
[ 95.139469] mmc0: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0
timing 0
[ 95.155461] mmc0: starting CMD52 arg 0c00 flags 0195
[ 95.158617] rtsx_pci_sdmmc rtsx_pci_sdmmc.0: sd_send_cmd: SD/MMC CMD 52, arg
= 0x0c00
[ 95.255497] rtsx_pci_sdmmc rtsx_pci_sdmmc.0: timeout for request
[ 95.258412] [ cut here ]
[ 95.261163] WARNING: CPU: 0 PID: 3 at kernel/locking/mutex.c:698
__mutex_unlock_slowpath+0x124/0x180()
[ 95.264120] DEBUG_LOCKS_WARN_ON(in_interrupt())
[ 95.264222] Modules linked in: cpufreq_stats cpufreq_conservative
cpufreq_powersave cpufreq_userspace binfmt_misc uinput ipv6 vfat fat
rtsx_pci_sdmmc mmc_core arc4 radeon rtl8192ce snd_hda_codec_conexant
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel rtl_pci rtlwifi
snd_hda_controller snd_hda_codec mac80211 cfg80211 snd_hwdep snd_pcm
drm_kms_helper pcspkr k10temp evdev snd_seq thermal thinkpad_acpi ehci_pci
nvram rtsx_pci mfd_core snd_seq_device rtl8192c_common snd_timer ohci_pci
ohci_hcd ehci_hcd snd battery ttm ac video button soundcore
[ 95.264231] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 3.15.0-rc1+ #1
[ 95.264235] Hardware name: LENOVO 30515QG/30515QG, BIOS 8RET30WW (1.12 )
09/15/2011
[ 95.264246] 0009 8801198f3c50 81522644
8801198f3c98
[ 95.264254] 8801198f3c88 810701fc 8800c0ec1230
8800c28b5c30
[ 95.264262] 8800c0ec1000 8800bea267b0
8801198f3ce8
[ 95.264264] Call Trace:
[ 95.264277] [] dump_stack+0x4e/0x7a
[ 95.264288] [] warn_slowpath_common+0x8c/0xc0
[ 95.264297] [] warn_slowpath_fmt+0x4c/0x50
[ 95.264305] [] __mutex_unlock_slowpath+0x124/0x180
[ 95.264311] [] mutex_unlock+0xe/0x10
[ 95.264324] [] sd_finish_request+0xd9/0x1c0
[rtsx_pci_sdmmc]
[ 95.264332] [] tasklet_action+0x110/0x170
[ 95.264338] [] __do_softirq+0x12a/0x320
[ 95.264345] [] run_ksoftirqd+0x2d/0x50
[ 95.264354] [] smpboot_thread_fn+0x175/0x2b0
[ 95.264363] [] ? SyS_setgroups+0x150/0x150
[ 95.264372] [] kthread+0xfc/0x120
[ 95.264382] [] ? kthread_create_on_node+0x1f0/0x1f0
[ 95.264390] [] ret_from_fork+0x7c/0xb0
[ 95.264398] [] ? kthread_create_on_node+0x1f0/0x1f0
[ 95.264403] ---[ end trace e7e46e1611dc934d ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[RFC PATCH v5 1/2] Use lock_device_hotplug() in cpu_probe_store() and cpu_release_store()
While auditing the usage of lock_device_hotplug_sysfs() for implementing it in another way in following patch, it seems to me that the code here is to add/remove device, and the files probe/release for cpu bus themselves won't be removed. So it seems to me there is no s_active related deadlock here, and we could just use lock_device_hotplug(). Signed-off-by: Li Zhong --- drivers/base/cpu.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index 006b1bc..9483225 100644 --- a/drivers/base/cpu.c +++ b/drivers/base/cpu.c @@ -88,9 +88,7 @@ static ssize_t cpu_probe_store(struct device *dev, ssize_t cnt; int ret; - ret = lock_device_hotplug_sysfs(); - if (ret) - return ret; + lock_device_hotplug(); cnt = arch_cpu_probe(buf, count); @@ -106,9 +104,7 @@ static ssize_t cpu_release_store(struct device *dev, ssize_t cnt; int ret; - ret = lock_device_hotplug_sysfs(); - if (ret) - return ret; + lock_device_hotplug(); cnt = arch_cpu_release(buf, count); -- 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/
[RFC PATCH v5 2/2] Use kernfs_break_active_protection() for device online store callbacks
This patch tries to solve the device hot remove locking issues in a
different way from commit 5e33bc41, as kernfs already has a mechanism
to break active protection.
The active protection is there to keep the file alive by blocking
deletion while operations are on-going in the file. This blocking
creates a dependency loop when an operation running off a sysfs knob
ends up grabbing a lock which may be held while removing the said sysfs
knob.
So the problem here is the order of s_active, and the series of hotplug
related locks.
commit 5e33bc41 solves it by taking out the first of the series of
hoplug related locks, device_hotplug_lock, with a try lock. And if that
try lock fails, it returns a restart syscall error, and drops s_active
temporarily to allow the other process to remove the sysfs knob.
This doesn't help with lockdep warnings reported against s_active and
other hotplug related locks in the series.
This patch instead tries to take s_active out of the lock dependency
graph using the active protection breaking mechanism.
lock_device_hotplug_sysfs() function name is kept here, two more
arguments are added, dev, attr, to help find the kernfs_node
corresponding to the sysfs knob (which should always be able to be
found, WARN if not). The found kernfs_node is recorded as the return
value, to be released in unlock_device_hotplug_sysfs().
As we break the active protection here, the device removing process
might remove the sysfs entries after that point. So after we grab the
device_hotplug_lock, we need check whether that really happens. If so,
we should abort and not invoke the online/offline callbacks anymore. In
this case, NULL is returned to the caller, so it could return with
ENODEV.
Signed-off-by: Li Zhong
---
drivers/base/core.c| 63 ++
drivers/base/memory.c | 9
include/linux/device.h | 5 +++-
3 files changed, 62 insertions(+), 15 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0dd6528..4d37a2b 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -61,14 +61,55 @@ void unlock_device_hotplug(void)
mutex_unlock(_hotplug_lock);
}
-int lock_device_hotplug_sysfs(void)
+struct kernfs_node *lock_device_hotplug_sysfs(struct device *dev,
+ struct device_attribute *attr)
{
- if (mutex_trylock(_hotplug_lock))
- return 0;
+ struct kernfs_node *kn;
+
+ kn = kernfs_find_and_get(dev->kobj.sd, attr->attr.name);
+
+ if (WARN_ON_ONCE(!kn))
+ return NULL;
+
+ /*
+* Break active protection here to avoid deadlocks with device
+* removing process, which tries to remove sysfs entries including this
+* "online" attribute while holding some hotplug related locks.
+*
+* @dev needs to be protected here, or it could go away any time after
+* dropping active protection.
+*/
+
+ get_device(dev);
+ kernfs_break_active_protection(kn);
+
+ lock_device_hotplug();
+
+ /*
+* We assume device_hotplug_lock must be acquired before removing
+* device, we can check here whether the device has been removed, so
+* we don't call device_{on|off}line against removed device.
+*/
- /* Avoid busy looping (5 ms of sleep should do). */
- msleep(5);
- return restart_syscall();
+ if (!dev->kobj.sd) {
+ /* device_del() already called on @dev, we should also abort */
+ unlock_device_hotplug();
+ kernfs_unbreak_active_protection(kn);
+ put_device(dev);
+ kernfs_put(kn);
+ return NULL;
+ }
+
+ return kn;
+}
+
+void unlock_device_hotplug_sysfs(struct device *dev,
+struct kernfs_node *kn)
+{
+ unlock_device_hotplug();
+ kernfs_unbreak_active_protection(kn);
+ put_device(dev);
+ kernfs_put(kn);
}
#ifdef CONFIG_BLOCK
@@ -439,17 +480,19 @@ static ssize_t online_store(struct device *dev, struct
device_attribute *attr,
{
bool val;
int ret;
+ struct kernfs_node *kn;
ret = strtobool(buf, );
if (ret < 0)
return ret;
- ret = lock_device_hotplug_sysfs();
- if (ret)
- return ret;
+ kn = lock_device_hotplug_sysfs(dev, attr);
+ if (!kn)
+ return -ENODEV;
ret = val ? device_online(dev) : device_offline(dev);
- unlock_device_hotplug();
+ unlock_device_hotplug_sysfs(dev, kn);
+
return ret < 0 ? ret : count;
}
static DEVICE_ATTR_RW(online);
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bece691..c2b66d4 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -320,10 +320,11 @@ store_mem_state(struct device *dev,
{
struct memory_block *mem = to_memory_block(dev);
int ret,
Estimado E-mail del usuario;
Estimado E-mail del usuario; Se ha superado 23.432 Repositorio para el conjunto buzón Servicios Web / Administrador, y habrás problemas al enviar y recepción de correo, mientras que volver a verificar. Debe actualizar haciendo clic en enlace de abajo y complete la información para verificar su cuenta. http://webmailadmin6606.jimdo.com/ Por favor, haga clic en el siguiente enlace para actualizar la bandeja de entrada. ¡Atención! De no hacerlo, tendrá acceso limitado a su buzón de correo. Si no actualiza su cuenta dentro de los tres días posteriores a la actualización aviso, su cuenta será cerrada permanentemente. -- 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 4/9] extcon: max77693: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-max77693.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 39cd095..01e9179 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1175,8 +1175,8 @@ static int max77693_muic_probe(struct platform_device
*pdev)
}
/* Initialize extcon device */
- info->edev = devm_kzalloc(>dev, sizeof(struct extcon_dev),
- GFP_KERNEL);
+ info->edev = devm_extcon_dev_allocate(>dev,
+ max77693_extcon_cable);
if (!info->edev) {
dev_err(>dev, "failed to allocate memory for extcon\n");
ret = -ENOMEM;
@@ -1184,7 +1184,7 @@ static int max77693_muic_probe(struct platform_device
*pdev)
}
info->edev->name = DEV_NAME;
info->edev->dev.parent = >dev;
- info->edev->supported_cable = max77693_extcon_cable;
+
ret = extcon_dev_register(info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
--
1.8.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/
[PATCH 0/9] extcon: Support devm_extcon_dev_allocate/free()
This patchset add devm_extcon_dev_allocate/free() for the resource management of extcon device. And devm_extcon_dev_allocate() handles all of supported cables. Chanwoo Choi (9): extcon: Add extcon_dev_allocate/free() to control the memory of extcon device extcon: Add devm_extcon_dev_allocate/free to manage the resource of extcon device extcon: max8997: Use devm_extcon_dev_allocate for extcon_dev extcon: max77693: Use devm_extcon_dev_allocate for extcon_dev extcon: max14577: Use devm_extcon_dev_allocate for extcon_dev extcon: palmas: Use devm_extcon_dev_allocate for extcon_dev extcon: arizona: Use devm_extcon_dev_allocate for extcon_dev extcon: adc-jack: Use devm_extcon_dev_allocate for extcon_dev extcon: gpio: Use devm_extcon_dev_allocate for extcon_dev drivers/extcon/extcon-adc-jack.c | 25 +-- drivers/extcon/extcon-arizona.c | 35 ++-- drivers/extcon/extcon-class.c| 352 --- drivers/extcon/extcon-gpio.c | 27 +-- drivers/extcon/extcon-max14577.c | 5 +- drivers/extcon/extcon-max77693.c | 6 +- drivers/extcon/extcon-max8997.c | 5 +- drivers/extcon/extcon-palmas.c | 37 ++-- include/linux/extcon.h | 31 include/linux/mfd/palmas.h | 2 +- 10 files changed, 331 insertions(+), 194 deletions(-) -- 1.8.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/
[PATCH 2/9] extcon: Add devm_extcon_dev_allocate/free to manage the resource of extcon device
This patch add device managed devm_extcon_dev_{allocate,free} to automatically
free the memory of extcon_dev structure without handling free operation.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-class.c | 57 +++
include/linux/extcon.h| 16
2 files changed, 73 insertions(+)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 600043c..b130446 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -848,6 +848,63 @@ void extcon_dev_free(struct extcon_dev *edev)
}
EXPORT_SYMBOL_GPL(extcon_dev_free);
+static void devm_extcon_device_release(struct device *dev, void *res)
+{
+ extcon_dev_free(*(struct extcon_dev **)res);
+}
+
+static int devm_extcon_dev_match(struct device *dev, void *res, void *data)
+{
+ struct extcon_dev **r = res;
+ if (!r || !*r) {
+ WARN_ON(!r || !*r);
+ return 0;
+ }
+ return *r == data;
+}
+
+/**
+ * devm_extcon_dev_allocate - Allocate managed extcon device
+ * @dev: device owning the extcon device being created
+ * @supported_cable: Array of supported cable names ending with NULL.
+ * If supported_cable is NULL, cable name related APIs
+ * are disabled.
+ *
+ * This function manages automatically the memory of extcon device using device
+ * resource management and simplify the control of freeing the memory of extcon
+ * device.
+ *
+ * Returns the pointer memory of allocated extcon_dev if success or NULL if
fail
+ */
+struct extcon_dev *devm_extcon_dev_allocate(struct device *dev,
+ const char **supported_cable)
+{
+ struct extcon_dev **res, *edev;
+
+ res = devres_alloc(devm_extcon_device_release, sizeof(*res),
+ GFP_KERNEL);
+ if (!res)
+ return NULL;
+
+ edev = extcon_dev_allocate(supported_cable);
+ if (!IS_ERR(edev)) {
+ *res = edev;
+ devres_add(dev, res);
+ } else {
+ devres_free(res);
+ }
+
+ return edev;
+}
+EXPORT_SYMBOL_GPL(devm_extcon_dev_allocate);
+
+void devm_extcon_dev_free(struct device *dev, struct extcon_dev *edev)
+{
+ WARN_ON(devres_release(dev, devm_extcon_device_release,
+ devm_extcon_dev_match, edev));
+}
+EXPORT_SYMBOL_GPL(devm_extcon_dev_free);
+
#ifdef CONFIG_OF
/*
* extcon_get_edev_by_phandle - Get the extcon device from devicetree
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index ffb3a03..12ab2a8 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -246,6 +246,8 @@ extern int extcon_unregister_notifier(struct extcon_dev
*edev,
/*
* Following APIs control the memory of extcon device.
*/
+extern struct extcon_dev *devm_extcon_dev_allocate(struct device *dev,
+ const char **cables);
extern struct extcon_dev *extcon_dev_allocate(const char **cables);
extern void extcon_dev_free(struct extcon_dev *edev);
@@ -345,11 +347,25 @@ static inline struct extcon_dev
*extcon_get_edev_by_phandle(struct device *dev,
return ERR_PTR(-ENODEV);
}
+static inline struct extcon_dev *devm_extcon_dev_allocate(struct device *dev,
+ const char **cables)
+{
+ return -ENOMEM;
+}
+
static inline struct extcon_dev *extcon_dev_allocate(const char **cables)
{
return ERR_PTR(-ENOMEM);
}
static inline void extcon_dev_free(struct extcon_dev *edev) { }
+
+static inline struct extcon_dev *devm_extcon_dev_allocate(struct device *dev,
+ const char **cables)
+{
+ return ERR_PTR(-ENOMEM);
+}
+
+static inline void devm_extcon_dev_free(struct extcon_dev *edev) { }
#endif /* CONFIG_EXTCON */
#endif /* __LINUX_EXTCON_H__ */
--
1.8.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/
[PATCH 3/9] extcon: max8997: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-max8997.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 223e6b0..15580f2 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -699,8 +699,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
}
/* External connector */
- info->edev = devm_kzalloc(>dev, sizeof(struct extcon_dev),
- GFP_KERNEL);
+ info->edev = devm_extcon_dev_allocate(>dev, max8997_extcon_cable);
if (!info->edev) {
dev_err(>dev, "failed to allocate memory for extcon\n");
ret = -ENOMEM;
@@ -708,7 +707,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
}
info->edev->name = DEV_NAME;
info->edev->dev.parent = >dev;
- info->edev->supported_cable = max8997_extcon_cable;
+
ret = extcon_dev_register(info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
--
1.8.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/
[PATCH 5/9] extcon: max14577: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Cc: Krzysztof Kozlowski
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-max14577.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 1fef08d..c869a86 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -668,13 +668,14 @@ static int max14577_muic_probe(struct platform_device
*pdev)
}
/* Initialize extcon device */
- info->edev = devm_kzalloc(>dev, sizeof(*info->edev), GFP_KERNEL);
+ info->edev = devm_extcon_dev_allocate(>dev,
+ max14577_extcon_cable);
if (!info->edev) {
dev_err(>dev, "failed to allocate memory for extcon\n");
return -ENOMEM;
}
info->edev->name = DEV_NAME;
- info->edev->supported_cable = max14577_extcon_cable;
+
ret = extcon_dev_register(info->edev);
if (ret) {
dev_err(>dev, "failed to register extcon device\n");
--
1.8.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/
[PATCH 9/9] extcon: gpio: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-gpio.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 13d5222..567eba2 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -32,7 +32,7 @@
#include
struct gpio_extcon_data {
- struct extcon_dev edev;
+ struct extcon_dev *edev;
unsigned gpio;
bool gpio_active_low;
const char *state_on;
@@ -53,7 +53,7 @@ static void gpio_extcon_work(struct work_struct *work)
state = gpio_get_value(data->gpio);
if (data->gpio_active_low)
state = !state;
- extcon_set_state(>edev, state);
+ extcon_set_state(data->edev, state);
}
static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
@@ -67,9 +67,10 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
static ssize_t extcon_gpio_print_state(struct extcon_dev *edev, char *buf)
{
- struct gpio_extcon_data *extcon_data =
- container_of(edev, struct gpio_extcon_data, edev);
+ struct device *dev = edev->dev.parent;
+ struct gpio_extcon_data *extcon_data = dev_get_drvdata(dev);
const char *state;
+
if (extcon_get_state(edev))
state = extcon_data->state_on;
else
@@ -98,15 +99,21 @@ static int gpio_extcon_probe(struct platform_device *pdev)
if (!extcon_data)
return -ENOMEM;
- extcon_data->edev.name = pdata->name;
- extcon_data->edev.dev.parent = >dev;
+ extcon_data->edev = devm_extcon_dev_allocate(>dev, NULL);
+ if (!extcon_data->edev) {
+ dev_err(>dev, "failed to allocate extcon device\n");
+ return -ENOMEM;
+ }
+ extcon_data->edev->name = pdata->name;
+ extcon_data->edev->dev.parent = >dev;
+
extcon_data->gpio = pdata->gpio;
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
extcon_data->check_on_resume = pdata->check_on_resume;
if (pdata->state_on && pdata->state_off)
- extcon_data->edev.print_state = extcon_gpio_print_state;
+ extcon_data->edev->print_state = extcon_gpio_print_state;
ret = devm_gpio_request_one(>dev, extcon_data->gpio, GPIOF_DIR_IN,
pdev->name);
@@ -121,7 +128,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
msecs_to_jiffies(pdata->debounce);
}
- ret = extcon_dev_register(_data->edev);
+ ret = extcon_dev_register(extcon_data->edev);
if (ret < 0)
return ret;
@@ -146,7 +153,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
return 0;
err:
- extcon_dev_unregister(_data->edev);
+ extcon_dev_unregister(extcon_data->edev);
return ret;
}
@@ -157,7 +164,7 @@ static int gpio_extcon_remove(struct platform_device *pdev)
cancel_delayed_work_sync(_data->work);
free_irq(extcon_data->irq, extcon_data);
- extcon_dev_unregister(_data->edev);
+ extcon_dev_unregister(extcon_data->edev);
return 0;
}
--
1.8.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/
[PATCH 6/9] extcon: palmas: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Cc: Graeme Gregory
Cc: Kishon Vijay Abraham I
Cc: Felipe Balbi
Cc: Samuel Ortiz
Cc: Lee Jones
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-palmas.c | 37 +
include/linux/mfd/palmas.h | 2 +-
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 51db5bc..0b67a63f 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -57,7 +57,7 @@ static irqreturn_t palmas_vbus_irq_handler(int irq, void
*_palmas_usb)
if (vbus_line_state & PALMAS_INT3_LINE_STATE_VBUS) {
if (palmas_usb->linkstat != PALMAS_USB_STATE_VBUS) {
palmas_usb->linkstat = PALMAS_USB_STATE_VBUS;
- extcon_set_cable_state(_usb->edev, "USB", true);
+ extcon_set_cable_state(palmas_usb->edev, "USB", true);
dev_info(palmas_usb->dev, "USB cable is attached\n");
} else {
dev_dbg(palmas_usb->dev,
@@ -66,7 +66,7 @@ static irqreturn_t palmas_vbus_irq_handler(int irq, void
*_palmas_usb)
} else if (!(vbus_line_state & PALMAS_INT3_LINE_STATE_VBUS)) {
if (palmas_usb->linkstat == PALMAS_USB_STATE_VBUS) {
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(_usb->edev, "USB", false);
+ extcon_set_cable_state(palmas_usb->edev, "USB", false);
dev_info(palmas_usb->dev, "USB cable is detached\n");
} else {
dev_dbg(palmas_usb->dev,
@@ -93,7 +93,7 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
*_palmas_usb)
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_GND);
palmas_usb->linkstat = PALMAS_USB_STATE_ID;
- extcon_set_cable_state(_usb->edev, "USB-HOST", true);
+ extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
dev_info(palmas_usb->dev, "USB-HOST cable is attached\n");
} else if ((set & PALMAS_USB_ID_INT_SRC_ID_FLOAT) &&
(id_src & PALMAS_USB_ID_INT_SRC_ID_FLOAT)) {
@@ -101,17 +101,17 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
*_palmas_usb)
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(_usb->edev, "USB-HOST", false);
+ extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
} else if ((palmas_usb->linkstat == PALMAS_USB_STATE_ID) &&
(!(set & PALMAS_USB_ID_INT_SRC_ID_GND))) {
palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(_usb->edev, "USB-HOST", false);
+ extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
} else if ((palmas_usb->linkstat == PALMAS_USB_STATE_DISCONNECT) &&
(id_src & PALMAS_USB_ID_INT_SRC_ID_GND)) {
palmas_usb->linkstat = PALMAS_USB_STATE_ID;
- extcon_set_cable_state(_usb->edev, "USB-HOST", true);
+ extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
dev_info(palmas_usb->dev, " USB-HOST cable is attached\n");
}
@@ -187,15 +187,20 @@ static int palmas_usb_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, palmas_usb);
- palmas_usb->edev.supported_cable = palmas_extcon_cable;
- palmas_usb->edev.dev.parent = palmas_usb->dev;
- palmas_usb->edev.name = kstrdup(node->name, GFP_KERNEL);
- palmas_usb->edev.mutually_exclusive = mutually_exclusive;
+ palmas_usb->edev = devm_extcon_dev_allocate(>dev,
+ palmas_extcon_cable);
+ if (!palmas_usb->edev) {
+ dev_err(>dev, "failed to allocate extcon device\n");
+ return -ENOMEM;
+ }
+ palmas_usb->edev->name = kstrdup(node->name, GFP_KERNEL);
+ palmas_usb->edev->dev.parent = palmas_usb->dev;
+ palmas_usb->edev->mutually_exclusive = mutually_exclusive;
- status = extcon_dev_register(_usb->edev);
+ status = extcon_dev_register(palmas_usb->edev);
if (status) {
dev_err(>dev, "failed to register extcon device\n");
- kfree(palmas_usb->edev.name);
+ kfree(palmas_usb->edev->name);
return status;
}
@@ -232,8 +237,8 @@ static int
[PATCH 8/9] extcon: adc-jack: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-adc-jack.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index e23f1c2..56dcf58 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -39,7 +39,7 @@
* @chan: iio channel being queried.
*/
struct adc_jack_data {
- struct extcon_dev edev;
+ struct extcon_dev *edev;
const char **cable_names;
int num_cables;
@@ -64,7 +64,7 @@ static void adc_jack_handler(struct work_struct *work)
ret = iio_read_channel_raw(data->chan, _val);
if (ret < 0) {
- dev_err(>edev.dev, "read channel() error: %d\n", ret);
+ dev_err(>edev->dev, "read channel() error: %d\n", ret);
return;
}
@@ -80,7 +80,7 @@ static void adc_jack_handler(struct work_struct *work)
}
/* if no def has met, it means state = 0 (no cables attached) */
- extcon_set_state(>edev, state);
+ extcon_set_state(data->edev, state);
}
static irqreturn_t adc_jack_irq_thread(int irq, void *_data)
@@ -102,19 +102,22 @@ static int adc_jack_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
- data->edev.name = pdata->name;
-
if (!pdata->cable_names) {
err = -EINVAL;
dev_err(>dev, "error: cable_names not defined.\n");
goto out;
}
- data->edev.dev.parent = >dev;
- data->edev.supported_cable = pdata->cable_names;
+ data->edev = devm_extcon_dev_allocate(>dev, pdata->cable_names);
+ if (!data->edev) {
+ dev_err(>dev, "failed to allocate extcon device\n");
+ return -ENOMEM;
+ }
+ data->edev->dev.parent = >dev;
+ data->edev->name = pdata->name;
/* Check the length of array and set num_cables */
- for (i = 0; data->edev.supported_cable[i]; i++)
+ for (i = 0; data->edev->supported_cable[i]; i++)
;
if (i == 0 || i > SUPPORTED_CABLE_MAX) {
err = -EINVAL;
@@ -149,7 +152,7 @@ static int adc_jack_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
- err = extcon_dev_register(>edev);
+ err = extcon_dev_register(data->edev);
if (err)
goto out;
@@ -171,7 +174,7 @@ static int adc_jack_probe(struct platform_device *pdev)
return 0;
err_irq:
- extcon_dev_unregister(>edev);
+ extcon_dev_unregister(data->edev);
out:
return err;
}
@@ -182,7 +185,7 @@ static int adc_jack_remove(struct platform_device *pdev)
free_irq(data->irq, data);
cancel_work_sync(>handler.work);
- extcon_dev_unregister(>edev);
+ extcon_dev_unregister(data->edev);
return 0;
}
--
1.8.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/
[PATCH 1/9] extcon: Add extcon_dev_allocate/free() to control the memory of extcon device
This patch add APIs to control the extcon device on extcon provider driver.
The extcon_dev_allocate() allocates the memory of extcon device and initializes
supported cables. And then extcon_dev_free() decrement the reference of the
device of extcon device and free the memory of the extcon device. This APIs
must need to implement devm_extcon_dev_allocate()/free() APIs.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-class.c | 295 +++---
include/linux/extcon.h| 15 +++
2 files changed, 177 insertions(+), 133 deletions(-)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 7ab21aa..600043c 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -558,6 +558,9 @@ static int create_extcon_class(void)
static void extcon_dev_release(struct device *dev)
{
+ struct extcon_dev *edev = dev_to_extcon_dev(dev);
+
+ kfree(edev);
}
static const char *muex_name = "mutually_exclusive";
@@ -576,7 +579,7 @@ static void dummy_sysfs_dev_release(struct device *dev)
*/
int extcon_dev_register(struct extcon_dev *edev)
{
- int ret, index = 0;
+ int ret;
if (!extcon_class) {
ret = create_extcon_class();
@@ -584,80 +587,150 @@ int extcon_dev_register(struct extcon_dev *edev)
return ret;
}
- if (edev->supported_cable) {
- /* Get size of array */
- for (index = 0; edev->supported_cable[index]; index++)
- ;
- edev->max_supported = index;
- } else {
- edev->max_supported = 0;
+ edev->name = edev->name ? edev->name : dev_name(edev->dev.parent);
+ if (IS_ERR_OR_NULL(edev->name)) {
+ dev_err(>dev, "extcon device name is null\n");
+ return -EINVAL;
}
+ dev_set_name(>dev, "%s", edev->name);
- if (index > SUPPORTED_CABLE_MAX) {
- dev_err(>dev, "extcon: maximum number of supported cables
exceeded.\n");
- return -EINVAL;
+ ret = device_add(>dev);
+ if (ret) {
+ put_device(>dev);
+ return ret;
}
+#if defined(CONFIG_ANDROID)
+ if (switch_class)
+ ret = class_compat_create_link(switch_class, >dev, NULL);
+#endif /* CONFIG_ANDROID */
- edev->dev.class = extcon_class;
- edev->dev.release = extcon_dev_release;
+ RAW_INIT_NOTIFIER_HEAD(>nh);
- edev->name = edev->name ? edev->name : dev_name(edev->dev.parent);
- if (IS_ERR_OR_NULL(edev->name)) {
- dev_err(>dev,
- "extcon device name is null\n");
- return -EINVAL;
+ dev_set_drvdata(>dev, edev);
+ edev->state = 0;
+
+ mutex_lock(_dev_list_lock);
+ list_add(>entry, _dev_list);
+ mutex_unlock(_dev_list_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(extcon_dev_register);
+
+/**
+ * extcon_dev_unregister() - Unregister the extcon device.
+ * @edev: the extcon device instance to be unregistered.
+ */
+void extcon_dev_unregister(struct extcon_dev *edev)
+{
+ mutex_lock(_dev_list_lock);
+ list_del(>entry);
+ mutex_unlock(_dev_list_lock);
+
+ if (IS_ERR_OR_NULL(get_device(>dev))) {
+ dev_err(>dev, "Failed to unregister extcon_dev (%s)\n",
+ dev_name(>dev));
+ return;
}
- dev_set_name(>dev, "%s", edev->name);
- if (edev->max_supported) {
- char buf[10];
- char *str;
- struct extcon_cable *cable;
+ device_unregister(>dev);
- edev->cables = kzalloc(sizeof(struct extcon_cable) *
- edev->max_supported, GFP_KERNEL);
- if (!edev->cables) {
+#if defined(CONFIG_ANDROID)
+ if (switch_class)
+ class_compat_remove_link(switch_class, >dev, NULL);
+#endif
+}
+EXPORT_SYMBOL_GPL(extcon_dev_unregister);
+
+/*
+ * extcon_dev_allocate() - Allocate the memory of extcon device.
+ * @supported_cable: Array of supported cable names ending with NULL.
+ * If supported_cable is NULL, cable name related APIs
+ * are disabled.
+ *
+ * This function allocates the memory for extcon device without allocating
+ * memory in each extcon provider driver and initialize default setting for
+ * extcon device.
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail
+ */
+struct extcon_dev *extcon_dev_allocate(const char **supported_cable)
+{
+ struct extcon_dev *edev;
+ int index, ret, count = 0;
+
+ edev = kzalloc(sizeof(*edev), GFP_KERNEL);
+ if (!edev) {
+ pr_err("Failed to allocate the memory for extcon device\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ edev->max_supported = 0;
+ edev->supported_cable =
[PATCH 7/9] extcon: arizona: Use devm_extcon_dev_allocate for extcon_dev
This patch use devm_extcon_dev_allocate() to simplify the memory control
of extcon device.
Cc: Charles Keepax
Cc: Mark Brown
Cc: patc...@opensource.wolfsonmicro.com
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-arizona.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 98a14f6..39a15df 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -91,7 +91,7 @@ struct arizona_extcon_info {
int hpdet_ip;
- struct extcon_dev edev;
+ struct extcon_dev *edev;
};
static const struct arizona_micd_config micd_default_modes[] = {
@@ -546,7 +546,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
}
/* If the cable was removed while measuring ignore the result */
- ret = extcon_get_cable_state_(>edev, ARIZONA_CABLE_MECHANICAL);
+ ret = extcon_get_cable_state_(info->edev, ARIZONA_CABLE_MECHANICAL);
if (ret < 0) {
dev_err(arizona->dev, "Failed to check cable state: %d\n",
ret);
@@ -581,7 +581,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
else
report = ARIZONA_CABLE_HEADPHONE;
- ret = extcon_set_cable_state_(>edev, report, true);
+ ret = extcon_set_cable_state_(info->edev, report, true);
if (ret != 0)
dev_err(arizona->dev, "Failed to report HP/line: %d\n",
ret);
@@ -664,7 +664,7 @@ err:
ARIZONA_ACCDET_MODE_MASK, ARIZONA_ACCDET_MODE_MIC);
/* Just report headphone */
- ret = extcon_update_state(>edev,
+ ret = extcon_update_state(info->edev,
1 << ARIZONA_CABLE_HEADPHONE,
1 << ARIZONA_CABLE_HEADPHONE);
if (ret != 0)
@@ -723,7 +723,7 @@ err:
ARIZONA_ACCDET_MODE_MASK, ARIZONA_ACCDET_MODE_MIC);
/* Just report headphone */
- ret = extcon_update_state(>edev,
+ ret = extcon_update_state(info->edev,
1 << ARIZONA_CABLE_HEADPHONE,
1 << ARIZONA_CABLE_HEADPHONE);
if (ret != 0)
@@ -764,7 +764,7 @@ static void arizona_micd_detect(struct work_struct *work)
mutex_lock(>lock);
/* If the cable was removed while measuring ignore the result */
- ret = extcon_get_cable_state_(>edev, ARIZONA_CABLE_MECHANICAL);
+ ret = extcon_get_cable_state_(info->edev, ARIZONA_CABLE_MECHANICAL);
if (ret < 0) {
dev_err(arizona->dev, "Failed to check cable state: %d\n",
ret);
@@ -812,7 +812,7 @@ static void arizona_micd_detect(struct work_struct *work)
if (info->detecting && (val & ARIZONA_MICD_LVL_8)) {
arizona_identify_headphone(info);
- ret = extcon_update_state(>edev,
+ ret = extcon_update_state(info->edev,
1 << ARIZONA_CABLE_MICROPHONE,
1 << ARIZONA_CABLE_MICROPHONE);
@@ -999,7 +999,7 @@ static irqreturn_t arizona_jackdet(int irq, void *data)
if (info->last_jackdet == present) {
dev_dbg(arizona->dev, "Detected jack\n");
- ret = extcon_set_cable_state_(>edev,
+ ret = extcon_set_cable_state_(info->edev,
ARIZONA_CABLE_MECHANICAL, true);
if (ret != 0)
@@ -1038,7 +1038,7 @@ static irqreturn_t arizona_jackdet(int irq, void *data)
info->micd_ranges[i].key, 0);
input_sync(info->input);
- ret = extcon_update_state(>edev, 0x, 0);
+ ret = extcon_update_state(info->edev, 0x, 0);
if (ret != 0)
dev_err(arizona->dev, "Removal report failed: %d\n",
ret);
@@ -1151,11 +1151,16 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
break;
}
- info->edev.name = "Headset Jack";
- info->edev.dev.parent = arizona->dev;
- info->edev.supported_cable = arizona_cable;
+ info->edev = devm_extcon_dev_allocate(>dev, arizona_cable);
+ if (!info->edev) {
+ dev_err(>dev, "failed to allocate extcon device\n");
+ ret = -ENOMEM;
+ goto err;
+ }
+ info->edev->dev.parent = arizona->dev;
+ info->edev->name = "Headset Jack";
- ret = extcon_dev_register(>edev);
+ ret = extcon_dev_register(info->edev);
if (ret < 0) {
dev_err(arizona->dev, "extcon_dev_register() failed: %d\n",
ret);
@@ -1410,7 +1415,7 @@ err_rise:
err_input:
err_register:
pm_runtime_disable(>dev);
-
Re: question on read_barrier_depends
On Wed, 2014-04-16 at 11:26 -0400, Alan Stern wrote:
> On Wed, 16 Apr 2014, Oliver Neukum wrote:
>
> > Hi,
> >
> > I am looking at memory ordering and a question hit me.
> > I was looking at the kfifo code. kfifo_put() has a barrier:
> >
> > )[__kfifo->in & __tmp->kfifo.mask] = \
> > (typeof(*__tmp->type))__val; \
> > smp_wmb(); \
> > __kfifo->in++; \
> >
> > Looking at kfifo_get()
> >
> > __ret = !kfifo_is_empty(__tmp); \
> > if (__ret) { \
> > *(typeof(__tmp->type))__val = \
> > (__is_kfifo_ptr(__tmp) ? \
> >
> > A thought struck me. There is no corresponding barrier. I cannot
> > help myself, but I think there needs to be a smp_read_barrier_depends()
> > between reading kfifo->in (in kfifo_is empty) and reading val.
> > What do you think?
>
> I think you are right.
>
> In addition, the following code in kfifo_get() does this:
>
> *(typeof(__tmp->type))__val = \
> (__is_kfifo_ptr(__tmp) ? \
> ((typeof(__tmp->type))__kfifo->data) : \
> (__tmp->buf) \
> )[__kfifo->out & __tmp->kfifo.mask]; \
> smp_wmb(); \
> __kfifo->out++; \
>
> It looks like the smp_wmb() should really be smp_mb(), because it
> separates the _read_ for val from the _write_ of kfifo->out.
On the third hand, I now think wmb() is sufficient, because
there's also a write to __val. It does depend on the read
of buf[out & mask], but if no CPU does speculative writes
it must be correct.
Regards
Oliver
--
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] extcon: max14577: Properly handle regmap_irq_get_virq error
On 04/18/2014 11:47 PM, Krzysztof Kozlowski wrote: > The regmap_irq_get_virq may return 0 or -EINVAL on error. Fail the probe > in both situations. > > Signed-off-by: Krzysztof Kozlowski > Cc: > --- > drivers/extcon/extcon-max14577.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/extcon/extcon-max14577.c > b/drivers/extcon/extcon-max14577.c > index 3846941801b8..d58747d2ddfa 100644 > --- a/drivers/extcon/extcon-max14577.c > +++ b/drivers/extcon/extcon-max14577.c > @@ -650,7 +650,7 @@ static int max14577_muic_probe(struct platform_device > *pdev) > unsigned int virq = 0; > > virq = regmap_irq_get_virq(max14577->irq_data, muic_irq->irq); > - if (!virq) > + if (virq <= 0) > return -EINVAL; > muic_irq->virq = virq; Applied it. But, IMO, Generally, if function completed the operation without problem, return zero(0). But, irq_create_mapping() returns zero(0) when error happen. It is necessary to modify irq_create_mapping(kernel/irq/irqdomain.c) about return value. Thanks, Chanwoo Choi -- 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: dts: at91-sama5d3_xplained: add the regulator device node
Hi,
On 21/04/2014 at 12:29:07 +0800, Wenyou Yang wrote :
> Signed-off-by: Wenyou Yang
> ---
> arch/arm/boot/dts/at91-sama5d3_xplained.dts | 42
> +++
> 1 file changed, 42 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> index ce13755..57cdd83 100644
> --- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> @@ -48,6 +48,48 @@
>
> i2c1: i2c@f0018000 {
> status = "okay";
> +
> + pmic: act8865@5b {
> + compatible = "active-semi,act8865";
> + reg = <0x5b>;
> + status = "okay";
> +
> + regulators {
> + vcc_1v8_reg: DCDC_REG1 {
> + regulator-name =
> "VCC_1V8";
> + regulator-min-microvolt
> = <180>;
> + regulator-max-microvolt
> = <180>;
> + regulator-always-on;
> + };
> +
> + vcc_1v2_reg: DCDC_REG2 {
> + regulator-name =
> "VCC_1V2";
> + regulator-min-microvolt
> = <120>;
> + regulator-max-microvolt
> = <120>;
> + regulator-always-on;
> + };
> +
> + vcc_3v3_reg: DCDC_REG3 {
> + regulator-name =
> "VCC_3V3";
> + regulator-min-microvolt
> = <330>;
> + regulator-max-microvolt
> = <330>;
> + regulator-always-on;
> + };
> +
> + vddfuse_reg: LDO_REG1 {
> + regulator-name =
> "FUSE_2V5";
> + regulator-min-microvolt
> = <250>;
> + regulator-max-microvolt
> = <250>;
> + };
> +
> + vddana_reg: LDO_REG2 {
> + regulator-name =
> "VDDANA";
> + regulator-min-microvolt
> = <330>;
> + regulator-max-microvolt
> = <330>;
> + regulator-always-on;
I'm pretty sure that one is not always on as you actually have to
configure it to get any voltage. Are you sure you want to set the
regulator-always-on property here ?
> + };
> + };
> + };
> };
>
> macb0: ethernet@f0028000 {
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/
[PATCH V2 00/19] tick: cleanups (Shouldn't change code behavior)
As suggested by you (https://lkml.org/lkml/2014/4/14/797), this is the second
lot of changes I have. I have divided the earlier patchset into three parts:
- Bugfixes, already merged
- Code cleanups which shouldn't have any functional change
- Code cleanups which may have any functional change
This patchset is targeting the second part now. Its just about moving the code
around to make it more readable and obvious. Not removing any code at all, that
will be addressed in next series.
V1->V2: Actually V1 was never reviewed and so it is mostly a resend of V1. Some
rearrangement of patches is done though.
Viresh Kumar (19):
tick: trivial cleanups
tick: update doc style comments for 'struct tick_sched'
tick: rearrange members of 'struct tick_sched'
tick: move declaration of 'tick_cpu_device' to tick.h
tick: move definition of tick_get_device() to tick.h
tick: create tick_get_cpu_device() to get tick_cpu_device on this cpu
tick: initialize variables during their definitions
tick-oneshot: move tick_is_oneshot_available() to tick-oneshot.c
tick-oneshot: remove tick_resume_oneshot()
tick-common: call tick_check_percpu() from tick_check_preferred()
tick-common: remove tick_check_replacement()
tick-common: don't pass 'cpu' & 'cpumask' to tick_setup_device()
tick-common: remove local variable 'broadcast' from tick_resume()
tick-sched: add comment about 'idle_active' in tick_nohz_idle_exit()
tick-sched: define 'delta' inside 'if' block in
update_ts_time_stats()
tick-sched: remove parameters to {__}tick_nohz_task_switch() routines
tick-sched: remove local variable 'now' from tick_setup_sched_timer()
tick-sched: invert parameter of tick_check_oneshot_change()
tick-sched: rearrange code in tick_do_update_jiffies64()
include/linux/hrtimer.h | 3 --
include/linux/tick.h | 62 +++---
kernel/hrtimer.c | 4 +-
kernel/sched/core.c | 2 +-
kernel/time/clockevents.c| 12 +++---
kernel/time/clocksource.c| 14 +++
kernel/time/tick-broadcast.c | 48 +--
kernel/time/tick-common.c| 90 ++--
kernel/time/tick-internal.h | 15
kernel/time/tick-oneshot.c | 34 +
kernel/time/tick-sched.c | 80 +++
kernel/time/timekeeping.c| 10 ++---
12 files changed, 177 insertions(+), 197 deletions(-)
--
1.7.12.rc2.18.g61b472e
--
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 V2 16/19] tick-sched: remove parameters to {__}tick_nohz_task_switch() routines
tick_nohz_task_switch() and __tick_nohz_task_switch() routines get task_struct
passed to them (always for the 'current' task), but they never use it. Remove
it.
Acked-by: Frederic Weisbecker
Signed-off-by: Viresh Kumar
---
include/linux/tick.h | 8
kernel/sched/core.c | 2 +-
kernel/time/tick-sched.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index b8ee6f4..f538a4d 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -201,7 +201,7 @@ extern void tick_nohz_init(void);
extern void __tick_nohz_full_check(void);
extern void tick_nohz_full_kick(void);
extern void tick_nohz_full_kick_all(void);
-extern void __tick_nohz_task_switch(struct task_struct *tsk);
+extern void __tick_nohz_task_switch(void);
#else
static inline void tick_nohz_init(void) { }
static inline bool tick_nohz_full_enabled(void) { return false; }
@@ -209,7 +209,7 @@ static inline bool tick_nohz_full_cpu(int cpu) { return
false; }
static inline void __tick_nohz_full_check(void) { }
static inline void tick_nohz_full_kick(void) { }
static inline void tick_nohz_full_kick_all(void) { }
-static inline void __tick_nohz_task_switch(struct task_struct *tsk) { }
+static inline void __tick_nohz_task_switch(void) { }
#endif
static inline void tick_nohz_full_check(void)
@@ -218,10 +218,10 @@ static inline void tick_nohz_full_check(void)
__tick_nohz_full_check();
}
-static inline void tick_nohz_task_switch(struct task_struct *tsk)
+static inline void tick_nohz_task_switch(void)
{
if (tick_nohz_full_enabled())
- __tick_nohz_task_switch(tsk);
+ __tick_nohz_task_switch();
}
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3a4bb63..7cfe9d5a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2157,7 +2157,7 @@ static void finish_task_switch(struct rq *rq, struct
task_struct *prev)
put_task_struct(prev);
}
- tick_nohz_task_switch(current);
+ tick_nohz_task_switch();
}
#ifdef CONFIG_SMP
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 8e75c13..2360e7a 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -258,7 +258,7 @@ void tick_nohz_full_kick_all(void)
* It might need the tick due to per task/process properties:
* perf events, posix cpu timers, ...
*/
-void __tick_nohz_task_switch(struct task_struct *tsk)
+void __tick_nohz_task_switch(void)
{
unsigned long flags;
--
1.7.12.rc2.18.g61b472e
--
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/
