Re: [PATCH 1/3] clk: mux: Add regmap support for simple mux
2015-05-29 8:40 GMT+02:00 Sascha Hauer s.ha...@pengutronix.de:
On Thu, May 28, 2015 at 08:41:46PM +0200, Matthias Brugger wrote:
Some devices like SoCs from Mediatek need to use the clock muxes
through a regmap interface.
This patch adds regmap support for simple the simple multiplexer
clock code.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
drivers/clk/clk-mux.c| 103
++-
include/linux/clk-provider.h | 40 +
2 files changed, 132 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 1fa2a8d..c7c692a 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -29,6 +29,26 @@
#define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw)
+static void clk_mux_writel(struct clk_mux *mux, u32 val)
+{
+ if (mux-flags CLK_MUX_USE_REGMAP)
+ regmap_write(mux-regmap, mux-offset, val);
+ else
+ clk_writel(val, mux-reg);
+}
+
+static u32 clk_mux_readl(struct clk_mux *mux)
+{
+ u32 val;
+
+ if (mux-flags CLK_MUX_USE_REGMAP)
+ regmap_read(mux-regmap, mux-offset, val);
+ else
+ val = clk_readl(mux-reg);
+
+ return val;
+}
+
static u8 clk_mux_get_parent(struct clk_hw *hw)
{
struct clk_mux *mux = to_clk_mux(hw);
@@ -42,7 +62,10 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
* OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
* val = 0x4 really means bit 2, index starts at bit 0
*/
- val = clk_readl(mux-reg) mux-shift;
+
+ val = clk_mux_readl(mux);
+
+ val = mux-shift;
val = mux-mask;
if (mux-table) {
@@ -89,11 +112,11 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8
index)
if (mux-flags CLK_MUX_HIWORD_MASK) {
val = mux-mask (mux-shift + 16);
} else {
- val = clk_readl(mux-reg);
+ val = clk_mux_readl(mux);
val = ~(mux-mask mux-shift);
}
val |= index mux-shift;
- clk_writel(val, mux-reg);
+ clk_mux_writel(mux, val);
With regmap the register lock is inside the regmap, you must hold it
during read/modify/write operations which means you have to use
regmap_update_bits rather than regmap_read followed by regmap_write.
Fixed in next version.
Thanks for reviewing.
--
motzblog.wordpress.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 42/45] nfs: Add richacl support
Adding linux-api... On Fri, May 29, 2015 at 11:00 AM, Andreas Grünbacher andreas.gruenbac...@gmail.com wrote: 2015-05-29 15:15 GMT+02:00 Trond Myklebust trond.mykleb...@primarydata.com: [reply reordered] So having revisited the reasons why I chose the system.nfs4_acl interface when we did NFSv4 ACLs, I'm not sure we should implement system.richacl for the NFS client at all. Your assertion that when symbolic user@domain and group@domain names are used in the acl, user-space needs to perform ID mapping in the same way as the kernel is WRONG. User space needs do no such thing, and that was the whole point of the interface; to allow the user to specify ACLs in a format that is checked only on the _server_, and not on the client. That's only half true. Right now, user-space applications trying to copy permissions between an nfs mount and another file system will fail unless the application has explicitly been made nfs aware and supports the system.nfs4_acl attribute (as well as some other acl mechanism if the permissions go beyond the file mode). The same problem exists when trying to make sense of acls. It seems unreasonable to me to expect applications other than special file system maintenance tools to cater to such file system differences; there are just too many file systems out there for that to work. Instead, it would be better to use an interface that can be generalized across file systems. My point is that system.richacl is not such an interface. It can only ever work for local filesystems that understand and store local uids and gids. It has no support for the remote users/groups that are stored on your NFS/SMB server unless they happen to have a local mapping into uids and gids, and so the API is inappropriate to replace the existing NFSv4 acl API on the client. The problem is that you are 100% reliant on an accurate idmapper in order to convert the name@domain to a _correct_ uid/gid. It isn't sufficient to convert to just any valid uid/gid, because if your ACL tool is trying to edit the ACL, you can end up converting all those DENY modes for user 'johnny_rot...@blackhats.are.us' into DENY modes for user 'nobody'. ...and yes, libnfsidmap will happily convert all unknown user/groupnames into whatever uid/gid corresponds to 'nobody' without returning an error. That's indeed a problem, and I can think of two ways of addressing it: First, acl editors need to be careful about nobody entries; they need to be aware that nobody could actually stand for somebody else. (We could map unmappable users and groups to something else than nobody, but that might just shift the problem without improve anything.) What is the editor supposed to do about an entry it cannot even interpret, let alone store back to the server? Second, we could add support for passing through unmappable Who values as is. But that raises the problem of how to pass thtough and represent different kinds of identifiers: NFSv4 users user@domain and group@domain strings; smb users SIDs; maybe more. Now you have a mixture of some stuff that is being translated into local uid/gid format and therefore needs translating back when you're going to update the ACL, and some stuff that is not. What is the value of doing the mapping here? Trond -- 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 02/19] x86, fpu: Wrap get_xsave_addr() to make it safer
On 05/28/2015 06:05 PM, Andy Lutomirski wrote: I would propose that we take the opposite approach and just ban eagerfpu=off when MPX is enabled. We could then take the next step and default eagerfpu=on for everyone and, if nothing breaks, then just delete lazy mode entirely. No objections from me on this. It's definitely the simplest thing to do, and it's one less potential delta that enabling MPX could impose on someone, so it makes me happy on that front. -- 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 v10 11/12] x86, mm, pat: Refactor !pat_enabled handling
On Fri, 2015-05-29 at 17:13 +0200, Borislav Petkov wrote: On Fri, May 29, 2015 at 08:27:08AM -0600, Toshi Kani wrote: This simply preserves the original error check in the code. This error check makes sure that all CPUs have the PAT feature supported when PAT is enabled. This error can only happen when heterogeneous CPUs are installed/emulated on the system/guest. This check may be paranoid, but this cleanup is not meant to modify such an error check. No, this is a ridiculous attempt to justify crazy code. Please do it right. If the cleanup makes the code more insane than it is, then don't do it in the first place. Well, the change is based on this review comment. So, I am not sure what would be the right thing to do. I am not 100% certain that this check can be removed, either. https://lkml.org/lkml/2015/5/22/148 Can you consider the patch 10/12-11/12 as a separate patchset from the WT series? If that is OK, I will resubmit 10/12 (BUG-panic) and 11/12 (commit log update). That's not enough. 11/12 is a convoluted mess which needs splitting and more detailed explanations in the commit messages. So no. Read what I said: do the cleanup *first* , *then* add the new functionality. The WT patches shouldn't change all too much from what you have now. Also, 11/12 changes stuff which you add in 1/12. This churn is useless and shouldn't be there at all. So you should be able to do the cleanup first and have the WT stuff ontop just fine. OK, I will do the cleanup first and resubmit the patchset based on tip/master. Thanks, -Toshi -- 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 1/9] misc: sram: fix enabled clock leak on error path
Hi Vladimir, Am Freitag, den 29.05.2015, 14:31 +0300 schrieb Vladimir Zapolskiy: [...] res-start is of type phys_addr_t (well, resource_size_t) already. block-start/size and cur_start/size are just offsets added to it. I agree. I wonder if it wouldn't be more appropriate to use resource_size_t for the sram_reserve .start field. Assuming that the sram_reserve .start field represents only the difference of two res-start and this difference fits into u32 storage, it should be safe to keep it as is. In my opinion integer overflow case should not be considered or handled by the driver, so probably the best option would be just to drop phys_addr_t commit, since it attempts to solve a nonexistent problem. Please let me know your opinion, if it is fine with you, I'll remove use phys_addr_t instead of u32 for physical address commit and resend the series. Yes, that's fine with me. regards Philipp -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/6] edac, mce_amd_inj: Add capability to trigger apic interrupts
On Wed, May 27, 2015 at 02:03:36PM -0500, Aravind Gopalakrishnan wrote:
With this extension to the flags attribute, deferred error interrupts
and threshold interrupts can be triggered to test the apic interrupt
handler functionality for these type of errors
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
drivers/edac/mce_amd_inj.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/mce_amd_inj.c b/drivers/edac/mce_amd_inj.c
index daec4af..f1c1433 100644
--- a/drivers/edac/mce_amd_inj.c
+++ b/drivers/edac/mce_amd_inj.c
@@ -34,12 +34,16 @@ static u8 n_banks;
enum injection_type {
SW_INJ = 0, /* SW injection, simply decode the error */
HW_INJ, /* Trigger a #MC */
+ DFR_INT_INJ,/* Trigger Deferred error interrupt */
+ THR_INT_INJ,/* Trigger threshold interrupt */
N_INJ_TYPES,
};
static const char * const flags_options[] = {
[SW_INJ] = sw,
[HW_INJ] = hw,
+ [DFR_INT_INJ] = dfr,
+ [THR_INT_INJ] = thr,
NULL
};
@@ -191,6 +195,16 @@ static void trigger_mce(void *info)
asm volatile(int $18);
}
+static void trigger_dfr_int(void *info)
+{
+ asm volatile(int $244);
+}
+
+static void trigger_thr_int(void *info)
+{
+ asm volatile(int $249);
+}
Hardcoded naked numbers huh?
Guess what happens when someone changes DEFERRED_ERROR_VECTOR and
THRESHOLD_APIC_VECTOR.
+
static void do_inject(void)
{
u64 mcg_status = 0;
@@ -202,6 +216,20 @@ static void do_inject(void)
return;
}
+ if (inj_type == DFR_INT_INJ) {
+ /*
+ * Ensure necessary status bits for deferred errors:
+ * a. MCx_STATUS[Deferred] is set -
+ * This is to ensure the error will be handled by the
+ * interrupt handler
+ * b. unset MCx_STATUS[UC]
+ * As deferred errors are _not_ UC
+ */
+
+ i_mce.status |= MCI_STATUS_DEFERRED;
+ i_mce.status |= (i_mce.status ~MCI_STATUS_UC);
i_mce.status = ~MCI_STATUS_UC;
+ }
+
get_online_cpus();
if (!cpu_online(cpu))
goto err;
@@ -228,7 +256,12 @@ static void do_inject(void)
toggle_hw_mce_inject(cpu, false);
- smp_call_function_single(cpu, trigger_mce, NULL, 0);
+ if (inj_type == DFR_INT_INJ)
+ smp_call_function_single(cpu, trigger_dfr_int, NULL, 0);
+ else if (inj_type == THR_INT_INJ)
+ smp_call_function_single(cpu, trigger_thr_int, NULL, 0);
+ else
+ smp_call_function_single(cpu, trigger_mce, NULL, 0);
I guess a switch-case is kinda offering itself here...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
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] ALSA: aoa: convert bus code to use dev_groups
At Fri, 29 May 2015 17:49:06 +0200, Quentin Lambert wrote: On 28/05/2015 17:01, Takashi Iwai wrote: Also, it'd be better to move ATTRIBUTE_GROUPS(soundbus_dev) into soundbus/sysfs.c, and make it this global instead of soundbus_dev_attrs[]. Ok, I need to find a nice way to do that because ATTRIBUTE_GROUPS declares the structure as static. If it results in an ungly code, it's fine with the original code, too. But, maybe with a comment indicating that xxx_dev_attrs[] is defined in xxx.c. Since sound/aoa/soundbus/sysfs is small, a solution would be to merge sound/aoa/soundbus/sysfs.c and sound/aoa/soundus/core.c. Moreover all 172 other usages of the ATTRIBUTE_GROUPS macro define the struct attribute *xxx_attrs[] in the same file they assign the .dev_groups field. I'm not sure about this change as it seems way more important than adding a comment line as you suggested. Not important but more radical, I'd say. Should I send a patch merging these two files? I don't think it's worth. This is a fairly old hardware, thus the code isn't so actively used/maintained. Unless it looks too ugly, we shouldn't touch too many things just for refactoring. So, go for the way to have a minimum change. thanks, Takashi -- 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/
perf probe: segfault in 'perf probe /bin/bash array_*'
[root@ssdandy ~]# perf probe /bin/bash array_* Added new event: Segmentation fault (core dumped) [root@ssdandy ~]# This is with my perf/core branch. - Arnaldo -- 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 02/19] x86, fpu: Wrap get_xsave_addr() to make it safer
On Thu, May 28, 2015 at 06:05:33PM -0700, Andy Lutomirski wrote: I would propose that we take the opposite approach and just ban eagerfpu=off when MPX is enabled. We could then take the next step and default eagerfpu=on for everyone and, if nothing breaks, then just delete lazy mode entirely. I suspect we'd have to go back to Pentium 3 or earlier to find a CPU on which lazy mode is actually a good idea. Last time I checked (and ran some benchmarks) it was only a minute slowdown so I say we kill lazy mode if it means significant code complexity drop. Can I also emulate Greg here and suggest that Pentium 3 people should buy newer hw? They should think about the environment, if nothing else. :-P -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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/2] Drivers: hv: vmbus: use cpu_hotplug_enable/disable
-Original Message-
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
Sent: Thursday, May 21, 2015 9:22 AM
To: de...@linuxdriverproject.org
Cc: KY Srinivasan; Haiyang Zhang; linux-kernel@vger.kernel.org; Dexuan Cui;
Ingo Molnar; Paul E. McKenney; Rafael J. Wysocki; Peter Zijlstra; Thomas
Gleixner; Radim Krčmář
Subject: [PATCH v2 2/2] Drivers: hv: vmbus: use cpu_hotplug_enable/disable
Commit e513229b4c38 (Drivers: hv: vmbus: prevent cpu offlining on newer
hypervisors) was altering smp_ops.cpu_disable to prevent CPU offlining.
We can bo better by using cpu_hotplug_enable/disable functions instead of
such hard-coding.
Reported-by: Radim Krčmář rkrc...@redhat.com
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
This patch does not apply. Vitaly, could you rebase this on Greg's tree and
re-submit.
Regards,
K. Y
---
drivers/hv/vmbus_drv.c | 38 --
1 file changed, 4 insertions(+), 34 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index c85235e..e916ba2 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -763,38 +763,6 @@ static void vmbus_isr(void)
}
}
-#ifdef CONFIG_HOTPLUG_CPU
-static int hyperv_cpu_disable(void)
-{
- return -ENOSYS;
-}
-
-static void hv_cpu_hotplug_quirk(bool vmbus_loaded)
-{
- static void *previous_cpu_disable;
-
- /*
- * Offlining a CPU when running on newer hypervisors (WS2012R2,
Win8,
- * ...) is not supported at this moment as channel interrupts are
- * distributed across all of them.
- */
-
- if ((vmbus_proto_version == VERSION_WS2008) ||
- (vmbus_proto_version == VERSION_WIN7))
- return;
-
- if (vmbus_loaded) {
- previous_cpu_disable = smp_ops.cpu_disable;
- smp_ops.cpu_disable = hyperv_cpu_disable;
- pr_notice(CPU offlining is not supported by hypervisor\n);
- } else if (previous_cpu_disable)
- smp_ops.cpu_disable = previous_cpu_disable;
-}
-#else
-static void hv_cpu_hotplug_quirk(bool vmbus_loaded)
-{
-}
-#endif
/*
* vmbus_bus_init -Main vmbus driver initialization routine.
@@ -836,7 +804,8 @@ static int vmbus_bus_init(int irq)
if (ret)
goto err_alloc;
- hv_cpu_hotplug_quirk(true);
+ if (vmbus_proto_version VERSION_WIN7)
+ cpu_hotplug_disable();
/*
* Only register if the crash MSRs are available
@@ -1103,7 +1072,8 @@ static void __exit vmbus_exit(void)
for_each_online_cpu(cpu)
smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1);
acpi_bus_unregister_driver(vmbus_acpi_driver);
- hv_cpu_hotplug_quirk(false);
+ if (vmbus_proto_version VERSION_WIN7)
+ cpu_hotplug_enable();
vmbus_disconnect();
}
--
1.9.3
Re: linux-next: Tree for May 29 (drivers/power/twl4030_charger)
On 05/29/15 05:18, Stephen Rothwell wrote: Hi all, Changes since 20150528: on i386: when CONFIG_USB_SUPPORT is not enabled: ../drivers/power/twl4030_charger.c: In function 'twl4030_bci_probe': ../drivers/power/twl4030_charger.c:648:4: error: implicit declaration of function 'devm_usb_get_phy_by_node' [-Werror=implicit-function-declaration] bci-transceiver = devm_usb_get_phy_by_node( ^ ../drivers/power/twl4030_charger.c:648:21: warning: assignment makes pointer from integer without a cast [enabled by default] bci-transceiver = devm_usb_get_phy_by_node( ^ Should this driver depend on USB_SUPPORT? -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 0/3] x86/earlyprintk: setup serial earlyprintk as early as possible
On Thu, May 28, 2015 at 02:01:12PM +0600, Alexander Kuleshov wrote: 2015-05-27 18:51 GMT+06:00 Borislav Petkov b...@suse.de: Now, have you tested this on real hardware? Because your 0/n message said qemu but I don't think that's sufficient. If we're going to enable early_printk this early, we'd need it working on real hardware too. For that I'd suggest adding a 4th, test patch which issues a couple of numbered early_printk() lines which we could run on a bunch of machines to see whether it actually works. Thank you for suggestions. But how to do it? The patch already contains: if (console_loglevel = CONSOLE_LOGLEVEL_DEBUG) early_printk(Early printk is initialized\n); You can boot with ignore_loglevel to see that message. Provided ignore_loglevel is even parsed that early. But I've just noticesed that it does not print anything, because console_loglevel can be CONSOLE_LOGLEVEL_DEBUG only after parse_early_params too :) How to better be with it? To remove if clause and just leave early_printk or something else? Or you meant something else about patch for testing? Yes, I meant a testing patch which is used only for testing and which issues a bunch of early_printk() calls. But, before you do that, your patchset has more problems. Booting in qemu+kvm gives this: early console in setup code early console in decompress_kernel Decompressing Linux... Parsing ELF... done. Booting the kernel. [0.00] bootconsole [earlyser0] enabled [0.00] ERROR: earlyprintk= earlyser already used ^^ [0.00] Linux version 4.1.0-rc5+ (boris@pd) (gcc version 4.9.2 (Debian 4.9.2-10) ) #3 SMP PREEMPT Fri May 29 18:41:59 CEST 2015 [0.00] Command line: root=/dev/sda1 debug ignore_loglevel log_buf_len=16M earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0 ... [0.00] Console: colour VGA+ 80x25 [0.00] console [tty0] enabled [0.00] bootconsole [earlyser0] disabled [0.00] bootconsole [earlyser0] enabled [0.00] ERROR: earlyprintk= earlyser already used ... [0.00] per task-struct memory footprint: 2688 bytes [0.00] WARNING: lockdep init error! lock-(console_sem).lock was acquiredbefore lockdep_init [0.00] Call stack leading to lockdep invocation was: [0.00] [81013f0f] save_stack_trace+0x2f/0x50 [0.00] [810a364c] __lock_acquire+0xa2c/0xf00 [0.00] [810a440b] lock_acquire+0xdb/0x2b0 [0.00] [81676b33] _raw_spin_lock_irqsave+0x53/0x90 [0.00] [8109b146] down+0x16/0x50 [0.00] [810b4d49] console_lock+0x19/0x60 [0.00] [810b78e6] register_console+0x116/0x350 [0.00] [81c36162] setup_early_printk+0x165/0x467 [0.00] [81c364ba] setup_early_serial_console+0x56/0x58 [0.00] [81c24565] x86_64_start_kernel+0xce/0x110 [0.00] [] 0x [0.00] This last one shows that you'd need to look into lockdep first. It also shows that early boot order is pretty fragile so one has to be very careful when changing stuff there. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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] lockdep: Add missing space in error message
From: Borislav Petkov b...@suse.de
... to fix this:
WARNING: lockdep init error! lock-(console_sem).lock was acquiredbefore
lockdep_init
Signed-off-by: Borislav Petkov b...@suse.de
---
kernel/locking/lockdep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index a0831e1b99f4..041ac1add184 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4066,7 +4066,7 @@ void __init lockdep_info(void)
#ifdef CONFIG_DEBUG_LOCKDEP
if (lockdep_init_error) {
- printk(WARNING: lockdep init error! lock-%s was acquired
+ printk(WARNING: lockdep init error! lock-%s was acquired
before lockdep_init\n, lock_init_error);
printk(Call stack leading to lockdep invocation was:\n);
print_stack_trace(lockdep_init_trace, 0);
--
2.3.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/
Re: [PATCH] x86/xen: use schedule_timeout_interruptible()
On 05/29/2015 09:49 AM, Nicholas Mc Guire wrote:
API consolidation with coccinelle found:
./arch/x86/xen/smp.c:499:2-18:
consolidation with schedule_timeout_*() recommended
This is a 1:1 conversion of the current calls to an available helper
only - so only an API consolidation to improve readability.
Patch was compile tested with x86_64_defconfig +
CONFIG_HYPERVISOR_GUEST=y,CONFIG_PARAVIRT=y,CONFIG_XEN=y:
Patch is against 4.1-rc5 (localversion-next is -next-20150529)
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
arch/x86/xen/smp.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 8648438..6cbbfc8 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -494,10 +494,8 @@ static int xen_cpu_disable(void)
static void xen_cpu_die(unsigned int cpu)
{
- while (xen_pv_domain() HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu, NULL)) {
- __set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(HZ/10);
- }
+ while (xen_pv_domain() HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu, NULL))
+ schedule_timeout_uninterruptible(msecs_to_jiffies(100));
if (common_cpu_die(cpu) == 0) {
xen_smp_intr_free(cpu);
--
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 v4 01/11] block: make generic_make_request handle arbitrarily sized bios
On Fri, May 29 2015 at 3:05P -0400,
Ming Lin m...@kernel.org wrote:
On Wed, May 27, 2015 at 5:36 PM, Alasdair G Kergon a...@redhat.com wrote:
On Wed, May 27, 2015 at 04:42:44PM -0700, Ming Lin wrote:
Here are fio results of XFS on a DM stripped target with 2 SSDs + 1 HDD.
Does it make sense?
To stripe across devices with different characteristics?
Some suggestions.
Prepare 3 kernels.
O - Old kernel.
M - Old kernel with merge_bvec_fn disabled.
How to disable it?
Maybe just hack it as below?
void blk_queue_merge_bvec(struct request_queue *q, merge_bvec_fn *mbfn)
{
//q-merge_bvec_fn = mbfn;
}
Right, there isn't an existing way to disable it, you'd need a hack like
that.
--
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] zpool: add EXPORT_SYMBOL for functions
On Fri, May 29, 2015 at 11:09:32AM -0400, Dan Streetman wrote: Export the zpool functions that should be exported. Why? -- 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 5/6] Watchdog: introduce ARM SBSA watchdog driver
On 05/29/2015 09:32 AM, Fu Wei wrote: It is a SPI, every CPU can get it, But maybe I miss something, but please let me know if other CPU can not get the interrupt. There's only one watchdog device, so there's only one interrupt. I don't know which CPU will get the interrupt, but the watchdog is not a per-CPU device. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Add --show-total-period for perf annotate
Martin Liška mli...@suse.cz writes: Following patch sums samples that belong to a line in assembly language. What do you think about it, would it be acceptable solution? Basic patch looks good to me now. Thanks. The only ugly thing is the global variable, perhaps that could be cleaned up. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: add pinctrl_register_reason() to return proper error code
On Fri, 2015-05-29 at 08:30PM +0900, Masahiro Yamada wrote: The pinctrl_register() just returns NULL on error, so the callers can not know the exact reason of the failure. Some of the pinctrl drivers return -EINVAL, some -ENODEV, and some -ENOMEM on error of pinctrl_register() , although the error code might be different from the actual cause of the error. This new function, pinctrl_register_reason(), helps the drivers get and return the appropriate error code. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com Suggested-by: Arnd Bergmann a...@arndb.de Acked-by: Sören Brinkmann soren.brinkm...@xilinx.com Sören -- 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/
randconfig build error with next-20150529, in drivers/mmc/host/omap_hsmmc.c
Building with the attached random configuration file, warning: (USB_OTG_FSM FSL_USB2_OTG USB_MV_OTG) selects USB_OTG which has unmet direct dependencies (USB_SUPPORT USB PM) drivers/mmc/host/omap_hsmmc.c: In function ‘omap_hsmmc_configure_wake_irq’: drivers/mmc/host/omap_hsmmc.c:1663:8: error: implicit declaration of function ‘dev_pm_set_dedicated_wake_irq’ [-Werror=implicit-function-declaration] ret = dev_pm_set_dedicated_wake_irq(host-dev, host-wake_irq); ^ # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.1.0-rc5 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 # CONFIG_RCU_NOCB_CPU is not set # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_CGROUPS is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y # CONFIG_MULTIUSER is not set # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y # CONFIG_EVENTFD is not set CONFIG_BPF_SYSCALL=y # CONFIG_SHMEM is not set # CONFIG_AIO is not set CONFIG_ADVISE_SYSCALLS=y # CONFIG_USERFAULTFD is not set CONFIG_PCI_QUIRKS=y CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_DEBUG_PERF_USE_VMALLOC=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set
Re: [PATCH v2 0/6] GPIO support for BRCMSTB
On 28/05/15 19:14, Gregory Fong wrote: This patchset adds support for the GPIO controller (UPG GIO) used on Broadcom's various BRCMSTB SoCs (BCM7XXX and others). It uses the basic-mmio-gpio interface to try to reduce duplication of the base logic. For all existing hardware, this block hooked up to the BCM7120 L2 IRQ controller and so will require CONFIG_BCM7120_L2_IRQ=y. Unless there are objections, I will take patches 5 and 6 and apply them to soc/next. Reviewed-by: Florian Fainelli f.faine...@gmail.com Thanks! New in v2: - fix license mismatch as pointed out by Paul Bolle - move select ARCH_WANT_OPTIONAL_GPIOLIB to separate patch - change to have 32 lines per bank per Linus Walleij's comments - allow this controller to be used as a wakeup source - add default GPIO number for BRCMSTB The device tree bindings from v1 were merged to the GPIO tree, so this patchset only contains an addition to allow GPIOs to be used as a wakeup source (patch 3). The initial bindings from v1 can be found at https://lkml.org/lkml/2015/5/6/200 . Gregory Fong (6): gpio: Add GPIO support for Broadcom STB SoCs gpio: brcmstb: Add interrupt support dt-bindings: brcmstb-gpio: document properties for wakeup gpio: brcmstb: Allow GPIOs to be wakeup sources ARM: brcmstb: Select ARCH_WANT_OPTIONAL_GPIOLIB ARM: brcmstb: Add default gpio number .../devicetree/bindings/gpio/brcm,brcmstb-gpio.txt | 26 +- MAINTAINERS| 7 + arch/arm/Kconfig | 3 +- arch/arm/mach-bcm/Kconfig | 1 + drivers/gpio/Kconfig | 9 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-brcmstb.c| 581 + 7 files changed, 626 insertions(+), 2 deletions(-) create mode 100644 drivers/gpio/gpio-brcmstb.c -- Florian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia
On Thu, May 28, 2015 at 11:40:07PM +0200, Pali Rohár wrote:
On Thursday 28 May 2015 18:34:31 Felipe Balbi wrote:
On Thu, May 28, 2015 at 04:59:18PM +0200, Pali Rohár wrote:
On Thursday 28 May 2015 16:51:07 Krzysztof Opasiak wrote:
On 05/28/2015 04:31 PM, Pali Rohár wrote:
On Thursday 28 May 2015 16:27:44 Krzysztof Opasiak wrote:
On 05/28/2015 09:47 AM, Pali Rohár wrote:
On Saturday 31 January 2015 10:53:30 Pali Rohár wrote:
This patch adds removable mass storage support to g_nokia
gadget (for N900). It means that at runtime block device can
be exported or unexported. So it does not export anything by
default and thus allows to use MyDocs partition as before...
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
drivers/usb/gadget/legacy/Kconfig |1 +
drivers/usb/gadget/legacy/nokia.c | 102
- 2 files changed, 102
insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/Kconfig
b/drivers/usb/gadget/legacy/Kconfig index fd48ef3..36f6ba4
100644
--- a/drivers/usb/gadget/legacy/Kconfig
+++ b/drivers/usb/gadget/legacy/Kconfig
@@ -345,6 +345,7 @@ config USB_G_NOKIA
select USB_F_OBEX
select USB_F_PHONET
select USB_F_ECM
+ select USB_F_MASS_STORAGE
help
The Nokia composite gadget provides support for acm,
obex and phonet in only one composite gadget driver.
diff --git a/drivers/usb/gadget/legacy/nokia.c
b/drivers/usb/gadget/legacy/nokia.c index 9b8fd70..a09bb50
100644
--- a/drivers/usb/gadget/legacy/nokia.c
+++ b/drivers/usb/gadget/legacy/nokia.c
@@ -24,6 +24,7 @@
#include u_phonet.h
#include u_ecm.h
#include gadget_chips.h
+#include f_mass_storage.h
/* Defines */
@@ -34,6 +35,29 @@ USB_GADGET_COMPOSITE_OPTIONS();
USB_ETHERNET_MODULE_PARAMETERS();
+static struct fsg_module_parameters fsg_mod_data = {
+ .stall = 0,
+ .luns = 2,
+ .removable_count = 2,
+ .removable = { 1, 1, },
+};
+
+FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
+
+#ifdef CONFIG_USB_GADGET_DEBUG_FILES
+
+static unsigned int fsg_num_buffers =
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS; +
+#else
+
+/*
+ * Number of buffers we will use.
+ * 2 is usually enough for good buffering pipeline
+ */
+#define
fsg_num_buffers CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS +
+#endif /* CONFIG_USB_DEBUG */
+
#define NOKIA_VENDOR_ID 0x0421 /* Nokia */
#define NOKIA_PRODUCT_ID 0x01c8 /* Nokia Gadget */
@@ -94,6 +118,8 @@ static struct usb_function *f_obex1_cfg2;
static struct usb_function *f_obex2_cfg2;
static struct usb_function *f_phonet_cfg1;
static struct usb_function *f_phonet_cfg2;
+static struct usb_function *f_msg_cfg1;
+static struct usb_function *f_msg_cfg2;
static struct usb_configuration nokia_config_500ma_driver =
{
@@ -117,6 +143,7 @@ static struct usb_function_instance
*fi_ecm;
static struct usb_function_instance *fi_obex1;
static struct usb_function_instance *fi_obex2;
static struct usb_function_instance *fi_phonet;
+static struct usb_function_instance *fi_msg;
static int __init nokia_bind_config(struct
usb_configuration *c) {
@@ -125,6 +152,8 @@ static int __init
nokia_bind_config(struct usb_configuration *c)
struct usb_function *f_obex1 = NULL;
struct usb_function *f_ecm;
struct usb_function *f_obex2 = NULL;
+ struct usb_function *f_msg;
+ struct fsg_opts *fsg_opts;
int status = 0;
int obex1_stat = -1;
int obex2_stat = -1;
@@ -160,6 +189,12 @@ static int __init
nokia_bind_config(struct usb_configuration *c)
goto err_get_ecm;
}
+ f_msg = usb_get_function(fi_msg);
+ if (IS_ERR(f_msg)) {
+ status = PTR_ERR(f_msg);
+ goto err_get_msg;
+ }
+
if (!IS_ERR_OR_NULL(f_phonet)) {
phonet_stat = usb_add_function(c, f_phonet);
if (phonet_stat)
@@ -187,21 +222,36 @@ static int __init
nokia_bind_config(struct usb_configuration *c)
pr_debug(could not bind ecm config %d\n, status);
goto err_ecm;
}
+
+ fsg_opts = fsg_opts_from_func_inst(fi_msg);
+
+ status = fsg_common_run_thread(fsg_opts-common);
+ if (status)
+ goto err_msg;
+
+ status = usb_add_function(c, f_msg);
+ if (status)
+ goto err_msg;
+
if (c == nokia_config_500ma_driver) {
f_acm_cfg1 =
[PATCH v2 2/4] sparc: time: Replace update_persistent_clock() with CONFIG_RTC_SYSTOHC
From: Xunlei Pang pang.xun...@linaro.org
On Sparc systems, update_persistent_clock() uses RTC drivers to do
the job, it makes more sense to hand it over to CONFIG_RTC_SYSTOHC.
In the long run, all the update_persistent_clock() should migrate to
proper class RTC drivers if any and use CONFIG_RTC_SYSTOHC instead.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
arch/sparc/Kconfig | 2 +-
arch/sparc/kernel/time_32.c | 21 -
arch/sparc/kernel/time_64.c | 14 --
3 files changed, 1 insertion(+), 36 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index e49502a..56442d2 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -25,6 +25,7 @@ config SPARC
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select RTC_CLASS
select RTC_DRV_M48T59
+ select RTC_SYSTOHC
select HAVE_DMA_ATTRS
select HAVE_DMA_API_DEBUG
select HAVE_ARCH_JUMP_LABEL if SPARC64
@@ -35,7 +36,6 @@ config SPARC
select HAVE_BPF_JIT
select HAVE_DEBUG_BUGVERBOSE
select GENERIC_SMP_IDLE_THREAD
- select GENERIC_CMOS_UPDATE
select GENERIC_CLOCKEVENTS
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
diff --git a/arch/sparc/kernel/time_32.c b/arch/sparc/kernel/time_32.c
index 8caf45e..c9692f3 100644
--- a/arch/sparc/kernel/time_32.c
+++ b/arch/sparc/kernel/time_32.c
@@ -23,7 +23,6 @@
#include linux/mm.h
#include linux/interrupt.h
#include linux/time.h
-#include linux/rtc.h
#include linux/rtc/m48t59.h
#include linux/timex.h
#include linux/clocksource.h
@@ -65,8 +64,6 @@ DEFINE_PER_CPU(struct clock_event_device, sparc32_clockevent);
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL(rtc_lock);
-static int set_rtc_mmss(unsigned long);
-
unsigned long profile_pc(struct pt_regs *regs)
{
extern char __copy_user_begin[], __copy_user_end[];
@@ -87,11 +84,6 @@ EXPORT_SYMBOL(profile_pc);
volatile u32 __iomem *master_l10_counter;
-int update_persistent_clock(struct timespec now)
-{
- return set_rtc_mmss(now.tv_sec);
-}
-
irqreturn_t notrace timer_interrupt(int dummy, void *dev_id)
{
if (timer_cs_enabled) {
@@ -362,16 +354,3 @@ void __init time_init(void)
sbus_time_init();
}
-
-static int set_rtc_mmss(unsigned long secs)
-{
- struct rtc_device *rtc = rtc_class_open(rtc0);
- int err = -1;
-
- if (rtc) {
- err = rtc_set_mmss(rtc, secs);
- rtc_class_close(rtc);
- }
-
- return err;
-}
diff --git a/arch/sparc/kernel/time_64.c b/arch/sparc/kernel/time_64.c
index edbbeb1..2e6035c 100644
--- a/arch/sparc/kernel/time_64.c
+++ b/arch/sparc/kernel/time_64.c
@@ -28,7 +28,6 @@
#include linux/cpufreq.h
#include linux/percpu.h
#include linux/miscdevice.h
-#include linux/rtc.h
#include linux/rtc/m48t59.h
#include linux/kernel_stat.h
#include linux/clockchips.h
@@ -394,19 +393,6 @@ static struct sparc64_tick_ops hbtick_operations
__read_mostly = {
static unsigned long timer_ticks_per_nsec_quotient __read_mostly;
-int update_persistent_clock(struct timespec now)
-{
- struct rtc_device *rtc = rtc_class_open(rtc0);
- int err = -1;
-
- if (rtc) {
- err = rtc_set_mmss(rtc, now.tv_sec);
- rtc_class_close(rtc);
- }
-
- return err;
-}
-
unsigned long cmos_regs;
EXPORT_SYMBOL(cmos_regs);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH trivial] of/overlay: Grammar s/an negative/a negative/
On Thu, May 21, 2015 at 7:10 AM, Geert Uytterhoeven
geert+rene...@glider.be wrote:
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Applied, thanks.
Rob
---
drivers/of/overlay.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 9af4d8de91792cb3..8fb906d4cdecfa4f 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -442,7 +442,7 @@ static struct kset *ov_kset;
* of the overlay in a list. This list can be used to prevent
* illegal overlay removals.
*
- * Returns the id of the created overlay, or an negative error number
+ * Returns the id of the created overlay, or a negative error number
*/
int of_overlay_create(struct device_node *tree)
{
@@ -607,7 +607,7 @@ static int overlay_removal_is_ok(struct of_overlay *ov)
*
* Removes an overlay if it is permissible.
*
- * Returns 0 on success, or an negative error number
+ * Returns 0 on success, or a negative error number
*/
int of_overlay_destroy(int id)
{
@@ -656,7 +656,7 @@ EXPORT_SYMBOL_GPL(of_overlay_destroy);
*
* Removes all overlays from the system in the correct order.
*
- * Returns 0 on success, or an negative error number
+ * Returns 0 on success, or a negative error number
*/
int of_overlay_destroy_all(void)
{
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 42/45] nfs: Add richacl support
2015-05-29 15:15 GMT+02:00 Trond Myklebust trond.mykleb...@primarydata.com: [reply reordered] So having revisited the reasons why I chose the system.nfs4_acl interface when we did NFSv4 ACLs, I'm not sure we should implement system.richacl for the NFS client at all. Your assertion that when symbolic user@domain and group@domain names are used in the acl, user-space needs to perform ID mapping in the same way as the kernel is WRONG. User space needs do no such thing, and that was the whole point of the interface; to allow the user to specify ACLs in a format that is checked only on the _server_, and not on the client. That's only half true. Right now, user-space applications trying to copy permissions between an nfs mount and another file system will fail unless the application has explicitly been made nfs aware and supports the system.nfs4_acl attribute (as well as some other acl mechanism if the permissions go beyond the file mode). The same problem exists when trying to make sense of acls. It seems unreasonable to me to expect applications other than special file system maintenance tools to cater to such file system differences; there are just too many file systems out there for that to work. Instead, it would be better to use an interface that can be generalized across file systems. The problem is that you are 100% reliant on an accurate idmapper in order to convert the name@domain to a _correct_ uid/gid. It isn't sufficient to convert to just any valid uid/gid, because if your ACL tool is trying to edit the ACL, you can end up converting all those DENY modes for user 'johnny_rot...@blackhats.are.us' into DENY modes for user 'nobody'. ...and yes, libnfsidmap will happily convert all unknown user/groupnames into whatever uid/gid corresponds to 'nobody' without returning an error. That's indeed a problem, and I can think of two ways of addressing it: First, acl editors need to be careful about nobody entries; they need to be aware that nobody could actually stand for somebody else. (We could map unmappable users and groups to something else than nobody, but that might just shift the problem without improve anything.) Second, we could add support for passing through unmappable Who values as is. But that raises the problem of how to pass thtough and represent different kinds of identifiers: NFSv4 users user@domain and group@domain strings; smb users SIDs; maybe more. Thanks, Andreas -- 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] of/fdt: Make fdt blob input parameters of unflatten functions const
On Wed, May 13, 2015 at 9:33 AM, Geert Uytterhoeven
geert+rene...@glider.be wrote:
Operations to unflatten fdt blobs never modify the input blobs, hence
make them const. Now we no longer need to cast arbitrary const data to
void * when calling of_fdt_unflatten_tree().
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Applied, thanks.
Rob
---
drivers/of/fdt.c | 6 +++---
include/linux/of_fdt.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index caa6bc447165636f..5e83687c090f7ee2 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -168,7 +168,7 @@ static void *unflatten_dt_alloc(void **mem, unsigned long
size,
* @dad: Parent struct device_node
* @fpsize: Size of the node path up at the current depth.
*/
-static void * unflatten_dt_node(void *blob,
+static void * unflatten_dt_node(const void *blob,
void *mem,
int *poffset,
struct device_node *dad,
@@ -378,7 +378,7 @@ static void * unflatten_dt_node(void *blob,
* @dt_alloc: An allocator that provides a virtual address to memory
* for the resulting tree
*/
-static void __unflatten_device_tree(void *blob,
+static void __unflatten_device_tree(const void *blob,
struct device_node **mynodes,
void * (*dt_alloc)(u64 size, u64 align))
{
@@ -441,7 +441,7 @@ static void *kernel_tree_alloc(u64 size, u64 align)
* pointers of the nodes so the normal device-tree walking functions
* can be used.
*/
-void of_fdt_unflatten_tree(unsigned long *blob,
+void of_fdt_unflatten_tree(const unsigned long *blob,
struct device_node **mynodes)
{
__unflatten_device_tree(blob, mynodes, kernel_tree_alloc);
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 587ee507965d78a1..0cf217d404ce4660 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -37,7 +37,7 @@ extern bool of_fdt_is_big_endian(const void *blob,
unsigned long node);
extern int of_fdt_match(const void *blob, unsigned long node,
const char *const *compat);
-extern void of_fdt_unflatten_tree(unsigned long *blob,
+extern void of_fdt_unflatten_tree(const unsigned long *blob,
struct device_node **mynodes);
/* TBD: Temporary export of fdt globals - remove when code fully merged */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -rfc 4/4] locking/rtmutex: Support spin on owner (osq)
Btw, I just realized I had sent a stale patch where the osq was not
being initialized, fixed below. Thanks!
From: Davidlohr Bueso d...@stgolabs.net
Subject: [PATCH v2] locking/rtmutex: Support spin on owner (osq)
Similar to what we have in other locks, particularly regular mutexes, the
idea is that as long as the owner is running, there is a fair chance it'll
release the lock soon, and thus a task trying to acquire the rtmutex will
better off spinning instead of blocking immediately after the fastpath.
Conditions to stop spinning and enter the slowpath are simple:
(1) Upon need_resched()
(2) Current lock owner blocks
Spinning tasks performance is further enhanced by queuing in cancelable
mcs (osq). Because rtmutexes track the lock owner atomically, we can
extend the fastpath to continue polling on the lock owner via
cmpxchg(lock-owner, NULL, current).
This is a conservative approach, such that upon entering the slowpath,
we force all lock spinners (including future ones) to serialize on the
wait_lock as mark_rt_mutex_waiters() is called, unconditionally.
CPU0CPU1
optimistic_spin() (failed)
try_to_take_rt_mutex()
mark_rt_mutex_waiters()
optimistic_spin() (failed cmpxchg)
spin_lock(lock-wait_lock)
As such we check for RT_MUTEX_HAS_WAITERS bit0 (rt_mutex_has_waiters_fast()).
This allows priority boosting to take precedence over spinning, as otherwise
we could starve a higher priority queued-up task (ie: top waiter) if spinners
constantly steal the lock. Another alternative would be to stop spinning when
we should really wakeup a higher priority waiter, but of course we do not hold
the wait_lock, so that is racy.
Signed-off-by: Davidlohr Bueso dbu...@suse.de
---
Changes from v1:
- Fix Kconfig debug
- Init lock-osq in rt mutex initializer
include/linux/percpu-rwsem.h | 14 +
include/linux/rtmutex.h | 4 ++
kernel/Kconfig.locks | 4 ++
kernel/locking/rtmutex.c | 136 ++-
mm/vmscan.c | 14 ++---
5 files changed, 164 insertions(+), 8 deletions(-)
diff --git a/include/linux/percpu-rwsem.h b/include/linux/percpu-rwsem.h
index 266110d..05b4737 100644
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -45,6 +45,20 @@ static inline void percpu_down_read(struct
percpu_rw_semaphore *sem)
*/
}
+static inline bool percpu_down_read_trylock(struct percpu_rw_semaphore *sem)
+{
+ bool ret = false;
+
+ preempt_disable();
+ if (likely(rcu_sync_is_idle(sem-rss))) {
+ __this_cpu_inc(*sem-refcount);
+ ret = true;
+ rwsem_acquire_read(sem-rw_sem.dep_map, 0, 0, _RET_IP_);
+ }
+ preempt_enable();
+ return ret;
+}
+
static inline void percpu_up_read(struct percpu_rw_semaphore *sem)
{
/*
diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
index 1abba5c..b5e85ca 100644
--- a/include/linux/rtmutex.h
+++ b/include/linux/rtmutex.h
@@ -15,6 +15,7 @@
#include linux/linkage.h
#include linux/rbtree.h
#include linux/spinlock_types.h
+#include linux/osq_lock.h
extern int max_lock_depth; /* for sysctl */
@@ -31,6 +32,9 @@ struct rt_mutex {
struct rb_root waiters;
struct rb_node *waiters_leftmost;
struct task_struct *owner;
+#ifdef CONFIG_RT_MUTEX_SPIN_ON_OWNER
+ struct optimistic_spin_queue osq; /* Spinner MCS lock */
+#endif
#ifdef CONFIG_DEBUG_RT_MUTEXES
int save_state;
const char *name, *file;
diff --git a/kernel/Kconfig.locks b/kernel/Kconfig.locks
index ebdb004..8602871 100644
--- a/kernel/Kconfig.locks
+++ b/kernel/Kconfig.locks
@@ -227,6 +227,10 @@ config MUTEX_SPIN_ON_OWNER
def_bool y
depends on SMP !DEBUG_MUTEXES ARCH_SUPPORTS_ATOMIC_RMW
+config RT_MUTEX_SPIN_ON_OWNER
+ def_bool y
+ depends on SMP RT_MUTEXES !DEBUG_RT_MUTEXES
ARCH_SUPPORTS_ATOMIC_RMW
+
config RWSEM_SPIN_ON_OWNER
def_bool y
depends on SMP RWSEM_XCHGADD_ALGORITHM ARCH_SUPPORTS_ATOMIC_RMW
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 81aad32..c868bd4 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -63,6 +63,20 @@ static inline void clear_rt_mutex_waiters(struct rt_mutex
*lock)
((unsigned long)lock-owner ~RT_MUTEX_HAS_WAITERS);
}
+/*
+ * Lockless alternative to rt_mutex_has_waiters() as we do not need the
+ * wait_lock to check if we are in, for instance, a transitional state
+ * after calling mark_rt_mutex_waiters().
+ */
+static inline bool rt_mutex_has_waiters_fast(struct rt_mutex *lock)
+{
+ unsigned long val = (unsigned long)lock-owner;
+
+ if (!val)
+ return false;
+ return val RT_MUTEX_HAS_WAITERS;
+}
+
static void fixup_rt_mutex_waiters(struct
[PATCH] sound/oss: use schedule_timeout_interruptible()
API consolidation with coccinelle found:
./sound/oss/msnd_pinnacle.c:1292:2-18:
consolidation with schedule_timeout_*() recommended
This is a 1:1 conversion of the current calls to an available helper
only - so only an API consolidation to improve readability.
Patch was compile tested with x86_64_defconfig
Patch is against 4.1-rc5 (localversion-next is -next-20150529)
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
sound/oss/msnd_pinnacle.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/oss/msnd_pinnacle.c b/sound/oss/msnd_pinnacle.c
index a8ceef8..a8bb4a0 100644
--- a/sound/oss/msnd_pinnacle.c
+++ b/sound/oss/msnd_pinnacle.c
@@ -1288,8 +1288,7 @@ static int __init calibrate_adc(WORD srate)
~0x0001, dev.SMA + SMA_wCurrHostStatusFlags);
if (msnd_send_word(dev, 0, 0, HDEXAR_CAL_A_TO_D) == 0
chk_send_dsp_cmd(dev, HDEX_AUX_REQ) == 0) {
- __set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(HZ / 3);
+ schedule_timeout_interruptible(HZ / 3);
return 0;
}
printk(KERN_WARNING LOGNAME : ADC calibration failed\n);
--
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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Matthijs van Duin matthijsvand...@gmail.com [150528 18:37]: On 29 May 2015 at 02:58, Matthijs van Duin matthijsvand...@gmail.com wrote: It is only guaranteed to happen immediately (before the next instruction is executed) if the error occurs before the posting-point of the write. However, in that case the error is reported in-band to the cpu, resulting in a (synchronous) bus error which takes precedence over the out-of-band error irq (if any is signalled). OK, all this was actually assuming linux uses device-type mappings for device mappings, which was also the impression I got from build_mem_type_table() in arch/arm/mm/mmu.c (although it's a bit of a maze). A quick test however seems to imply otherwise: ~# ./bogus-dev-write Bus error So... linux actually uses strongly-ordered mappings? I really didn't expect that, given the performance implications (especially on a strictly in-order cpu like the Cortex-A8 which will really just sit there picking its nose until the write completes) and I think I recall having seen an OCP barrier being used somewhere in driver code... I believe some TI kernels use strongly-ordered mappings, mainline kernel does not. Which kernel version are you using? Well, in that case everything I said is technically still true, except the posting point is the peripheral itself. That also means the interconnect error reporting mechanism is not really useful for probing since you'll get a bus error before any error irq is delivered. Hmm if that's the case then yes we can't use the error irq. However, what I've seen so far is that we only get the bus error if the l3_* drivers are configured. I guess some more testing is needed. So I'd say you're back at having to trap that bus error using the exception handling mechanism, which I still suspect shouldn't be hard to do. And in that case it makes sense to do that in the bootloader to avoid adding any custom early boot code to Linux kernel. Or perhaps you could probe the device using a DMA access and combine that with the interconnect error reporting irq... ;-) Heh too many dependencies :) Tony -- 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: [PATCHv5 1/2] ARM: socfpga: support suspend to ram
On Fri, 29 May 2015, Dinh Nguyen wrote: On 5/28/15 4:19 PM, Alan Tull wrote: Add code that requests that the sdr controller go into self-refresh mode. This code is run from ocram. Suspend-to-RAM and EDAC support are mutually exclusive on SOCFPGA. If the EDAC is enabled, it will prevent the platform from going into suspend. Example of how to request to suspend to ram: $ echo enabled \ /sys/devices/soc/ffc02000.serial0/tty/ttyS0/power/wakeup $ echo -n mem /sys/power/state Signed-off-by: Alan Tull at...@opensource.altera.com Cc: Pavel Machek pa...@denx.de Cc: Arnd Bergmann a...@arndb.de Cc: Dinh Nguyen dingu...@opensource.altera.com Cc: Steffen Trumtrar s.trumt...@pengutronix.de --- v2: use Generic on-chip SRAM driver to allocate ocram rm fncpy_align since generic allocator handles alignment check __arm_ioremap_exec return code check for NULL pointers add a comment regarding sdram controller configuration v3: fix renamed #define propagate socfpga_setup_ocram_self_refresh error code v4: Kconfig: don't need to select GENERIC_ALLOCATER add CONFIG_SOCFPGA_SUSPEND make s2r and EDAC support mutually exclusive socfpga.c: add sdr_ctl_base_addr return error if ocram not available in device tree update copyright years v5: remove compile time dependency edac driver will prevent suspend don't configure scu standby mode; done in enable_scu(). fix comments about required sdram controller configuration --- arch/arm/mach-socfpga/Kconfig| 10 ++- arch/arm/mach-socfpga/Makefile |1 + arch/arm/mach-socfpga/core.h |6 +- arch/arm/mach-socfpga/pm.c | 149 ++ arch/arm/mach-socfpga/self-refresh.S | 136 +++ arch/arm/mach-socfpga/socfpga.c |6 +- drivers/edac/altera_edac.c | 20 + 7 files changed, 325 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-socfpga/pm.c create mode 100644 arch/arm/mach-socfpga/self-refresh.S Which branch are you basing this patch on? I got a trivial patch conflict in Kconfig when I applied to arm-soc/for-next and v4.1-rc5. Based on your socfpga_for_next_arria10 branch from git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git Also, I'm getting these sparse warnings: arch/arm/mach-socfpga/pm.c:86:25: warning: incorrect type in argument 1 (different address spaces) arch/arm/mach-socfpga/pm.c:86:25:expected void *noident arch/arm/mach-socfpga/pm.c:86:25:got void [noderef] asn:2*[assigned] suspend_ocram_base arch/arm/mach-socfpga/pm.c:108:52: warning: cast removes address space of expression Dinh It appears to want suspend_ocram_base to be void * instead of void __iomem *. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] clk: mux: Add regmap support for simple mux
2015-05-29 8:57 GMT+02:00 Joachim Eastwood manab...@gmail.com:
Hi Matthias,
On 28 May 2015 at 20:41, Matthias Brugger matthias@gmail.com wrote:
Some devices like SoCs from Mediatek need to use the clock muxes
through a regmap interface.
This patch adds regmap support for simple the simple multiplexer
clock code.
Nice to see regmap support. This something I would also like to see
added to the clk framework.
And if the approach is agreed upon I would like to see support on
gates and dividers also.
I totally agree.
+static void clk_mux_writel(struct clk_mux *mux, u32 val)
+{
+ if (mux-flags CLK_MUX_USE_REGMAP)
Assume you mean .
Sure, it's just luck that the patch didn't end up with a hanging
system when I tested it yesterday.
Fixed in next version.
+ regmap_write(mux-regmap, mux-offset, val);
+ else
+ clk_writel(val, mux-reg);
+}
+
+static u32 clk_mux_readl(struct clk_mux *mux)
+{
+ u32 val;
+
+ if (mux-flags CLK_MUX_USE_REGMAP)
And here.
Ditto.
+ regmap_read(mux-regmap, mux-offset, val);
+ else
+ val = clk_readl(mux-reg);
+
+ return val;
+}
+
[...]
@@ -409,7 +410,9 @@ void clk_unregister_divider(struct clk *clk);
struct clk_mux {
struct clk_hw hw;
void __iomem*reg;
+ struct regmap *regmap;
Since it not possible to have both iomem and regmap at the same time.
Could this be put in a union or does that make registration more
difficult?
It just adds a flag check to the registration.
I will add it in the next version.
Thanks for reviewing.
Matthias
--
motzblog.wordpress.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 v3 2/6] phy: Add Marvell USB 2.0 OTG 28nm PHY
Add driver for USB 28nm PHY found in Marvell PXA1928 SOC. Signed-off-by: Rob Herring r...@kernel.org Cc: Kishon Vijay Abraham I kis...@ti.com --- drivers/phy/Kconfig | 10 ++ drivers/phy/Makefile| 1 + drivers/phy/phy-pxa-28nm-usb2.c | 355 3 files changed, 366 insertions(+) create mode 100644 drivers/phy/phy-pxa-28nm-usb2.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index a53bd5b..71409a1 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -52,6 +52,16 @@ config PHY_EXYNOS_MIPI_VIDEO Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P and EXYNOS SoCs. +config PHY_PXA_28NM_USB2 + tristate Marvell USB 2.0 28nm PHY Driver + select GENERIC_PHY + help + Enable this to support Marvell USB 2.0 PHY driver for Marvell + SoC. This driver will do the PHY initialization and shutdown. + The PHY driver will be used by Marvell udc/ehci/otg driver. + + To compile this driver as a module, choose M here. + config PHY_MVEBU_SATA def_bool y depends on ARCH_DOVE || MACH_DOVE || MACH_KIRKWOOD diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index f126251..8524307 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+= phy-armada375-usb2.o obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o +obj-$(CONFIG_PHY_PXA_28NM_USB2)+= phy-pxa-28nm-usb2.o obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o obj-$(CONFIG_PHY_MIPHY28LP)+= phy-miphy28lp.o obj-$(CONFIG_PHY_MIPHY365X)+= phy-miphy365x.o diff --git a/drivers/phy/phy-pxa-28nm-usb2.c b/drivers/phy/phy-pxa-28nm-usb2.c new file mode 100644 index 000..37e9c8c --- /dev/null +++ b/drivers/phy/phy-pxa-28nm-usb2.c @@ -0,0 +1,355 @@ +/* + * Copyright (C) 2015 Linaro, Ltd. + * Rob Herring r...@kernel.org + * + * Based on vendor driver: + * Copyright (C) 2013 Marvell Inc. + * Author: Chao Xie xiechao.m...@gmail.com + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include linux/delay.h +#include linux/slab.h +#include linux/of.h +#include linux/of_device.h +#include linux/io.h +#include linux/err.h +#include linux/clk.h +#include linux/module.h +#include linux/platform_device.h +#include linux/phy/phy.h + +/* USB PXA1928 PHY mapping */ +#define PHY_28NM_PLL_REG0 0x0 +#define PHY_28NM_PLL_REG1 0x4 +#define PHY_28NM_CAL_REG 0x8 +#define PHY_28NM_TX_REG0 0x0c +#define PHY_28NM_TX_REG1 0x10 +#define PHY_28NM_RX_REG0 0x14 +#define PHY_28NM_RX_REG1 0x18 +#define PHY_28NM_DIG_REG0 0x1c +#define PHY_28NM_DIG_REG1 0x20 +#define PHY_28NM_TEST_REG0 0x24 +#define PHY_28NM_TEST_REG1 0x28 +#define PHY_28NM_MOC_REG 0x2c +#define PHY_28NM_PHY_RESERVE 0x30 +#define PHY_28NM_OTG_REG 0x34 +#define PHY_28NM_CHRG_DET 0x38 +#define PHY_28NM_CTRL_REG0 0xc4 +#define PHY_28NM_CTRL_REG1 0xc8 +#define PHY_28NM_CTRL_REG2 0xd4 +#define PHY_28NM_CTRL_REG3 0xdc + +/* PHY_28NM_PLL_REG0 */ +#define PHY_28NM_PLL_READY BIT(31) + +#define PHY_28NM_PLL_SELLPFR_SHIFT 28 +#define PHY_28NM_PLL_SELLPFR_MASK (0x3 28) + +#define PHY_28NM_PLL_FBDIV_SHIFT 16 +#define PHY_28NM_PLL_FBDIV_MASK(0x1ff 16) + +#define PHY_28NM_PLL_ICP_SHIFT 8 +#define PHY_28NM_PLL_ICP_MASK (0x7 8) + +#define PHY_28NM_PLL_REFDIV_SHIFT 0 +#define PHY_28NM_PLL_REFDIV_MASK 0x7f + +/* PHY_28NM_PLL_REG1 */ +#define PHY_28NM_PLL_PU_BY_REG BIT(1) + +#define PHY_28NM_PLL_PU_PLLBIT(0) + +/* PHY_28NM_CAL_REG */ +#define PHY_28NM_PLL_PLLCAL_DONE BIT(31) + +#define PHY_28NM_PLL_IMPCAL_DONE BIT(23) + +#define PHY_28NM_PLL_KVCO_SHIFT16 +#define PHY_28NM_PLL_KVCO_MASK (0x7 16) + +#define PHY_28NM_PLL_CAL12_SHIFT 20 +#define
[PATCH 1/3] Drivers: hv: vmbus: Use the vp_index map even for channels bound to CPU 0
Map target_cpu to target_vcpu using the mapping table. Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- drivers/hv/channel_mgmt.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index 1f1417d..c3eba37 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -406,7 +406,7 @@ static void init_vp_index(struct vmbus_channel *channel, const uuid_le *type_gui * channel, bind it to cpu 0. */ channel-target_cpu = 0; - channel-target_vp = 0; + channel-target_vp = hv_context.vp_index[0]; return; } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Drivers: hv: vmbus: Make VMBUS driver NUMA aware
Implement CPU affinity for channels based on NUMA topology. Also, allocate all channel specific memory from the appropriate NUMA node. K. Y. Srinivasan (3): Drivers: hv: vmbus: Use the vp_index map even for channels bound to CPU 0 Drivers: hv: vmbus: Implement NUMA aware CPU affinity for channels Drivers: hv: vmbus: Allocate ring buffer memory in NUMA aware fashion drivers/hv/channel.c | 14 +++- drivers/hv/channel_mgmt.c | 74 ++-- include/linux/hyperv.h|5 +++ 3 files changed, 61 insertions(+), 32 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch V1 2/3] x86, mce: Add infrastructure required to support LMCE
Initialization and handling for LMCE
- boot time option to disable LMCE for that boot instance
- Check for capability via IA32_MCG_CAP
- provide ability to enable/disable LMCE on demand.
See http://www.intel.com/sdm Volume 3 System Programming Guide, Chapter 15
for more information on MSR's and documentation on Local MCE.
Signed-off-by: Ashok Raj ashok@intel.com
---
Documentation/x86/x86_64/boot-options.txt | 3 ++
arch/x86/include/asm/mce.h| 5 +++
arch/x86/kernel/cpu/mcheck/mce.c | 3 ++
arch/x86/kernel/cpu/mcheck/mce_intel.c| 75 +++
4 files changed, 86 insertions(+)
diff --git a/Documentation/x86/x86_64/boot-options.txt
b/Documentation/x86/x86_64/boot-options.txt
index 5223479..79edee0 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -31,6 +31,9 @@ Machine check
(e.g. BIOS or hardware monitoring applications), conflicting
with OS's error handling, and you cannot deactivate the agent,
then this option will be a help.
+ mce=no_lmce
+ Do not opt-in to Local MCE delivery. Use legacy method
+ to broadcast MCE's.
mce=bootlog
Enable logging of machine checks left over from booting.
Disabled by default on AMD because some BIOS leave bogus ones.
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 677a408..8ba4d7a 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -109,6 +109,7 @@ struct mce_log {
struct mca_config {
bool dont_log_ce;
bool cmci_disabled;
+ bool lmce_disabled;
bool ignore_ce;
bool disabled;
bool ser;
@@ -173,12 +174,16 @@ void cmci_clear(void);
void cmci_reenable(void);
void cmci_rediscover(void);
void cmci_recheck(void);
+void lmce_clear(void);
+void lmce_enable(void);
#else
static inline void mce_intel_feature_init(struct cpuinfo_x86 *c) { }
static inline void cmci_clear(void) {}
static inline void cmci_reenable(void) {}
static inline void cmci_rediscover(void) {}
static inline void cmci_recheck(void) {}
+static inline void lmce_clear(void) {}
+static inline void lmce_enable(void) {}
#endif
#ifdef CONFIG_X86_MCE_AMD
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index e535533..d10aada 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1976,6 +1976,7 @@ void mce_disable_bank(int bank)
/*
* mce=off Disables machine check
* mce=no_cmci Disables CMCI
+ * mce=no_lmce Disables LMCE
* mce=dont_log_ce Clears corrected events silently, no log created for CEs.
* mce=ignore_ce Disables polling and CMCI, corrected events are not cleared.
* mce=TOLERANCELEVEL[,monarchtimeout] (number, see above)
@@ -1999,6 +2000,8 @@ static int __init mcheck_enable(char *str)
cfg-disabled = true;
else if (!strcmp(str, no_cmci))
cfg-cmci_disabled = true;
+ else if (!strcmp(str, no_lmce))
+ cfg-lmce_disabled = true;
else if (!strcmp(str, dont_log_ce))
cfg-dont_log_ce = true;
else if (!strcmp(str, ignore_ce))
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index b4a41cf..be3a5c6 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -70,6 +70,10 @@ enum {
static atomic_t cmci_storm_on_cpus;
+#define FEATURE_CONTROL_LMCE_BITS ((FEATURE_CONTROL_LOCKED) | \
+(FEATURE_CONTROL_LMCE_SUPPORT_ENABLED))
+#define MCG_CAP_LMCE_BITS ((MCG_SER_P) | (MCG_LMCE_P))
+
static int cmci_supported(int *banks)
{
u64 cap;
@@ -91,6 +95,34 @@ static int cmci_supported(int *banks)
return !!(cap MCG_CMCI_P);
}
+static bool lmce_supported(void)
+{
+ u64 cap, feature_ctl;
+ bool lmce_bios_support, retval;
+
+ if (mca_cfg.lmce_disabled)
+ return false;
+
+ rdmsrl(MSR_IA32_MCG_CAP, cap);
+ rdmsrl(MSR_IA32_FEATURE_CONTROL, feature_ctl);
+
+ /*
+* BIOS should indicate support for LMCE by setting
+* bit20 in IA32_FEATURE_CONTROL. without which touching
+* MCG_EXT_CTL will generate #GP fault.
+*/
+ lmce_bios_support = ((feature_ctl (FEATURE_CONTROL_LMCE_BITS)) ==
+ (FEATURE_CONTROL_LMCE_BITS));
+
+ /*
+* MCG_CAP should indicate both MCG_SER_P and MCG_LMCE_P
+*/
+ cap = ((cap MCG_CAP_LMCE_BITS) == (MCG_CAP_LMCE_BITS));
+ retval = (cap lmce_bios_support);
+
+ return retval;
+}
+
bool mce_intel_cmci_poll(void)
{
if (__this_cpu_read(cmci_storm_state) == CMCI_STORM_NONE)
@@ -405,6 +437,49 @@ static void intel_init_cmci(void)
cmci_recheck();
}
+static void __lmce_enable(void)
+{
+ u64 val;
+
+
Re: [PATCH] staging: me_daq: use schedule_timeout_interruptible()
On Fri, 29 May 2015, Ian Abbott wrote: On 29/05/15 16:58, Nicholas Mc Guire wrote: API consolidation with coccinelle found: ./drivers/staging/comedi/drivers/me_daq.c:177:1-17: consolidation with schedule_timeout_*() recommended This is a 1:1 conversion of the current calls to an available helper only - so only an API consolidation to improve readability. Patch was compile tested with x86_64_defconfig + CONFIG_STAGING=y, CONFIG_COMEDI=y, CONFIG_COMEDI_PCI_DRIVERS=y CONFIG_COMEDI_ME_DAQ=m Patch is against 4.1-rc5 (localversion-next is -next-20150529) Minor niggle: you don't really need to say what version the patch is against in the commit message, as the version will have changed by the time the patch is committed. It can be mentioned after the --- marker line if relevant, as the stuff after the --- line does not end up in the commit message. makes sense - will move that down for the other cleanups. thx! hofrat -- 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] Drivers: hv: vmbus: Allocate ring buffer memory in NUMA aware fashion
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
drivers/hv/channel.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 7a1c2db..603ce97 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -73,6 +73,7 @@ int vmbus_open(struct vmbus_channel *newchannel, u32
send_ringbuffer_size,
unsigned long flags;
int ret, err = 0;
unsigned long t;
+ struct page *page;
spin_lock_irqsave(newchannel-lock, flags);
if (newchannel-state == CHANNEL_OPEN_STATE) {
@@ -87,8 +88,17 @@ int vmbus_open(struct vmbus_channel *newchannel, u32
send_ringbuffer_size,
newchannel-channel_callback_context = context;
/* Allocate the ring buffer */
- out = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
- get_order(send_ringbuffer_size + recv_ringbuffer_size));
+ page = alloc_pages_node(cpu_to_node(newchannel-target_cpu),
+ GFP_KERNEL|__GFP_ZERO,
+ get_order(send_ringbuffer_size +
+ recv_ringbuffer_size));
+
+ if (!page)
+ out = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
+ get_order(send_ringbuffer_size +
+ recv_ringbuffer_size));
+ else
+ out = (void *)page_address(page);
if (!out) {
err = -ENOMEM;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Drivers: hv: vmbus: Implement NUMA aware CPU affinity for channels
Channels/sub-channels can be affinitized to VCPUs in the guest. Implement
this affinity in a way that is NUMA aware. The current protocol distributed
the primary channels uniformly across all available CPUs. The new protocol
is NUMA aware: primary channels are distributed across the available NUMA
nodes while the sub-channels within a primary channel are distributed amongst
CPUs within the NUMA node assigned to the primary channel.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
drivers/hv/channel_mgmt.c | 72 +++--
include/linux/hyperv.h|5 +++
2 files changed, 48 insertions(+), 29 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index c3eba37..4506a66 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -370,25 +370,27 @@ static const struct hv_vmbus_device_id hp_devs[] = {
/*
* We use this state to statically distribute the channel interrupt load.
*/
-static u32 next_vp;
+static int next_numa_node_id;
/*
* Starting with Win8, we can statically distribute the incoming
- * channel interrupt load by binding a channel to VCPU. We
- * implement here a simple round robin scheme for distributing
- * the interrupt load.
- * We will bind channels that are not performance critical to cpu 0 and
- * performance critical channels (IDE, SCSI and Network) will be uniformly
- * distributed across all available CPUs.
+ * channel interrupt load by binding a channel to VCPU.
+ * We do this in a hierarchical fashion:
+ * First distribute the primary channels across available NUMA nodes
+ * and then distribute the subchannels amongst the CPUs in the NUMA
+ * node assigned to the primary channel.
+ *
+ * For pre-win8 hosts or non-performance critical channels we assign the
+ * first CPU in the first NUMA node.
*/
static void init_vp_index(struct vmbus_channel *channel, const uuid_le
*type_guid)
{
u32 cur_cpu;
int i;
bool perf_chn = false;
- u32 max_cpus = num_online_cpus();
- struct vmbus_channel *primary = channel-primary_channel, *prev;
- unsigned long flags;
+ struct vmbus_channel *primary = channel-primary_channel;
+ int next_node;
+ struct cpumask available_mask;
for (i = IDE; i MAX_PERF_CHN; i++) {
if (!memcmp(type_guid-b, hp_devs[i].guid,
@@ -405,36 +407,48 @@ static void init_vp_index(struct vmbus_channel *channel,
const uuid_le *type_gui
* Also if the channel is not a performance critical
* channel, bind it to cpu 0.
*/
+ channel-numa_node = 0;
+ cpumask_set_cpu(0, channel-alloced_cpus_in_node);
channel-target_cpu = 0;
channel-target_vp = hv_context.vp_index[0];
return;
}
/*
-* Primary channels are distributed evenly across all vcpus we have.
-* When the host asks us to create subchannels it usually makes us
-* num_cpus-1 offers and we are supposed to distribute the work evenly
-* among the channel itself and all its subchannels. Make sure they are
-* all assigned to different vcpus.
+* We distribute primary channels evenly across all the available
+* NUMA nodes and within the assigned NUMA node we will assign the
+* first available CPU to the primary channel.
+* The sub-channels will be assigned to the CPUs available in the
+* NUMA node evenly.
*/
- if (!primary)
- cur_cpu = (++next_vp % max_cpus);
- else {
+ if (!primary) {
+ while (true) {
+ next_node = next_numa_node_id++;
+ if (next_node == nr_node_ids)
+ next_node = next_numa_node_id = 0;
+ if (cpumask_empty(cpumask_of_node(next_node)))
+ continue;
+ break;
+ }
+ channel-numa_node = next_node;
+ primary = channel;
+ }
+
+ if (cpumask_weight(primary-alloced_cpus_in_node) ==
+ cpumask_weight(cpumask_of_node(primary-numa_node))) {
/*
-* Let's assign the first subchannel of a channel to the
-* primary-target_cpu+1 and all the subsequent channels to
-* the prev-target_cpu+1.
+* We have cycled through all the CPUs in the node;
+* reset the alloced map.
*/
- spin_lock_irqsave(primary-lock, flags);
- if (primary-num_sc == 1)
- cur_cpu = (primary-target_cpu + 1) % max_cpus;
- else {
- prev = list_prev_entry(channel, sc_list);
- cur_cpu = (prev-target_cpu + 1) % max_cpus;
- }
- spin_unlock_irqrestore(primary-lock, flags);
+
Re: [PATCH 02/19] x86, fpu: Wrap get_xsave_addr() to make it safer
On 05/28/2015 01:41 AM, Ingo Molnar wrote: + union fpregs_state *xstate; + + if (!current-thread.fpu.fpstate_active) + return NULL; + /* + * fpu__save() takes the CPU's xstate registers + * and saves them off to the 'fpu memory buffer. + */ + fpu__save(current-thread.fpu); + xstate = current-thread.fpu.state; + + return get_xsave_addr(xstate-xsave, xsave_state); Small nit, this would become a lot shorter if you introduced a helper local variable: struct fpu *fpu = current-thread.fpu; But more importantly, for a generic get_xsave_field_ptr() API, fpu__save() is not enough: fpu__save() will only save FPU registers into memory if necessary (i.e. if the FPU is already in use), and if you call it on a task with no FPU state then it will still have an !fpu-fpstate_active FPU state after the call, with random, invalid data in the xsave area. But why does this matter? We just did a !fpu.fpstate_active check, so we can't have a !fpu.fpstate_active before or after the call. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v4 15/29] bpf tools: Add bpf.c/h for common bpf operations
On Wed, May 27, 2015 at 05:19:50AM +, Wang Nan wrote:
This patch introduces bpf.c and bpf.h, which hold common functions
issuing bpf syscall. The goal of these two files is to hide syscall
completly from user. Note that bpf.c and bpf.h only deal with kernel
interface. Things like structure of 'map' section in the ELF object is
not cared by of bpf.[ch].
We first introduce bpf_create_map().
Note that, since functions in bpf.[ch] are wrapper of sys_bpf, they
don't use OO style naming.
Signed-off-by: Wang Nan wangn...@huawei.com
---
tools/lib/bpf/Build | 2 +-
tools/lib/bpf/bpf.c | 56
+
tools/lib/bpf/bpf.h | 16 +++
3 files changed, 73 insertions(+), 1 deletion(-)
create mode 100644 tools/lib/bpf/bpf.c
create mode 100644 tools/lib/bpf/bpf.h
diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
index a316484..d874975 100644
--- a/tools/lib/bpf/Build
+++ b/tools/lib/bpf/Build
@@ -1 +1 @@
-libbpf-y := libbpf.o
+libbpf-y := libbpf.o bpf.o
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
new file mode 100644
index 000..7481923
--- /dev/null
+++ b/tools/lib/bpf/bpf.c
@@ -0,0 +1,56 @@
+/*
+ * common eBPF ELF operations.
+ *
+ * Copyright (C) 2013-2015 Alexei Starovoitov a...@kernel.org
+ * Copyright (C) 2015 Wang Nan wangn...@huawei.com
+ * Copyright (C) 2015 Huawei Inc.
+ */
+
+#include stdlib.h
+#include memory.h
+#include unistd.h
+#include asm/unistd.h
+#include linux/bpf.h
+#include bpf.h
+
+/* When building perf, unistd.h is override. __NR_bpf by ourself. */
+#if defined(__i386__)
+#ifndef __NR_bpf
+# define __NR_bpf 357
+#endif
+#endif
+
+#if defined(__x86_64__)
+#ifndef __NR_bpf
+# define __NR_bpf 321
+#endif
+#endif
+
+#if defined(__aarch64__)
+#ifndef __NR_bpf
+# define __NR_bpf 280
+#endif
+#endif
+
+#ifndef __NR_bpf
+# error __NR_bpf not defined. libbpf does not support your arch.
+#endif
Why not doing this way?
#ifndef __NR_bpf
# if defined(__i386__)
# define __NR_bpf 357
# elif defined(__x86_64)
# define __NR_bpf 321
# elif defined(__aarch64__)
# define __NR_bpf 280
# else
# error __NR_bpf not defined. libbpf does not support your arch.
# endif
#endif
Thanks,
Namhyung
+
+static int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr, unsigned int size)
+{
+ return syscall(__NR_bpf, cmd, attr, size);
+}
+
+int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
+int max_entries)
+{
+ union bpf_attr attr;
+ memset(attr, '\0', sizeof(attr));
+
+ attr.map_type = map_type;
+ attr.key_size = key_size;
+ attr.value_size = value_size;
+ attr.max_entries = max_entries;
+
+ return sys_bpf(BPF_MAP_CREATE, attr, sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
new file mode 100644
index 000..28f7942
--- /dev/null
+++ b/tools/lib/bpf/bpf.h
@@ -0,0 +1,16 @@
+/*
+ * common eBPF ELF operations.
+ *
+ * Copyright (C) 2013-2015 Alexei Starovoitov a...@kernel.org
+ * Copyright (C) 2015 Wang Nan wangn...@huawei.com
+ * Copyright (C) 2015 Huawei Inc.
+ */
+#ifndef __BPF_BPF_H
+#define __BPF_BPF_H
+
+#include linux/bpf.h
+
+int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
+int max_entries);
+
+#endif
--
1.8.3.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 v3 5/6] Watchdog: introduce ARM SBSA watchdog driver
On 05/29/2015 02:11 AM, Fu Wei wrote:
[ ... ]
+
+ status = sbsa_gwdt_cf_read(SBSA_GWDT_WCS, wdd);
+ if (status SBSA_GWDT_WCS_WS1) {
+ dev_warn(dev, System reset by WDT(WCS: %x, WCV: %llx)\n,
+status, sbsa_gwdt_get_wcv(wdd));
Does this message (specifically the WCS / WCV values) have any
useful meaning for the user ?
I think so, according to SBSA spec:
If WS0 is asserted and a timeout refresh occurs then the following must occur:
If the system is compliant to SBSA level 2 or higher the compare
value must retain its current value. This means that the compare value
records the time that WS1 is asserted.
So, I think WCV can log the time when system reset by WDT, that may
help user figure out the problem. but WCS can be delete I think.
How would that help ? It is just a number with no reference to anything.
Thanks,
Guenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Uses of Linux backports in the industry
On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult weig...@melag.de wrote: Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez: Actually, I really wonder why folks are sticking to ancient kernels on newer hardware. Enterprise distribution kernels. Or special kernels like PREEMPT_RT. Sometimes the vendor BSP is that horrid that a customer cannot afford to forward port it but wants recent stuff. So you need to backport... -- 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: [PATCH trivial] of: Grammar s/property exist/property exists/
On Mon, May 4, 2015 at 12:42 PM, Geert Uytterhoeven geert+rene...@glider.be wrote: Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be Applied, thanks. Rob --- include/linux/of.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/of.h b/include/linux/of.h index ddeaae6d2083b256..6ebcec335919efab 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -815,7 +815,7 @@ static inline int of_property_read_string_index(struct device_node *np, * @propname: name of the property to be searched. * * Search for a property in a device node. - * Returns true if the property exist false otherwise. + * Returns true if the property exists false otherwise. */ static inline bool of_property_read_bool(const struct device_node *np, const char *propname) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] zpool: add zpool_has_pool()
Add zpool_has_pool() function, indicating if the specified type of zpool
is available (i.e. zsmalloc or zbud). This allows checking if a pool is
available, without actually trying to allocate it, similar to
crypto_has_alg().
Signed-off-by: Dan Streetman ddstr...@ieee.org
---
include/linux/zpool.h | 2 ++
mm/zpool.c| 25 +
2 files changed, 27 insertions(+)
diff --git a/include/linux/zpool.h b/include/linux/zpool.h
index 56529b3..31b79e2 100644
--- a/include/linux/zpool.h
+++ b/include/linux/zpool.h
@@ -36,6 +36,8 @@ enum zpool_mapmode {
ZPOOL_MM_DEFAULT = ZPOOL_MM_RW
};
+bool zpool_has_pool(char *type);
+
struct zpool *zpool_create_pool(char *type, char *name,
gfp_t gfp, struct zpool_ops *ops);
diff --git a/mm/zpool.c b/mm/zpool.c
index 884659d..bff40ce 100644
--- a/mm/zpool.c
+++ b/mm/zpool.c
@@ -127,6 +127,31 @@ static void zpool_put_driver(struct zpool_driver *driver)
}
/**
+ * zpool_has_pool() - Check if the pool driver is available
+ * @type The type of the zpool to check (e.g. zbud, zsmalloc)
+ *
+ * This checks if the @type pool driver is available.
+ *
+ * Returns: true if @type pool is available, false if not
+ */
+bool zpool_has_pool(char *type)
+{
+ struct zpool_driver *driver = zpool_get_driver(type);
+
+ if (!driver) {
+ request_module(zpool-%s, type);
+ driver = zpool_get_driver(type);
+ }
+
+ if (!driver)
+ return false;
+
+ zpool_put_driver(driver);
+ return true;
+}
+EXPORT_SYMBOL(zpool_has_pool);
+
+/**
* zpool_create_pool() - Create a new zpool
* @type The type of the zpool to create (e.g. zbud, zsmalloc)
* @name The name of the zpool (e.g. zram0, zswap)
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Moving unseen/inactive MAINTAINER M: names and email addresses to CREDITS
On 05/28/2015 12:59 PM, Joe Perches wrote: On Wed, 2015-05-27 at 14:06 -0700, Andrew Morton wrote: On Wed, 27 May 2015 14:01:44 -0700 Joe Perches j...@perches.com wrote: There are about 950 unique M: names in MAINTAINERS. About 200 of those names haven't signed or authored a single commit in 3+ years. Any desire to shorten the MAINTAINERS entries and orphan or delete those sections that that seem to have a single apparently inactive maintainer? Maybe 25 of those M: entries are actually email exploder type uses that should likely stay listed. Yes, I suppose we should clean this up. At present we're misleading people about the likely outcome of their emails. And we're misleading people (like me) who see the email and think ok, someone's taking care of that. This is the list of maintainer names/sections that seem not to have signed, authored or acked a commit in 3 years. After some editing and additional grepping, I got 133 entries. The grep patterns I used are imperfect. For instance, the MAINTAINERS file has Hideaki Yoshifuji but he doesn't ever sign anything that way. His signature is Yoshifuji Hideaki. If anyone sees any obvious false-positives, please let me know. I'll send a private email to all these people and see if they want to be listed in the MAINTAINERS file and see what happens. Here is the list two ways, alphabetic by name and by section By Name: Riley Andrews riandr...@android.com ANDROID DRIVERS I just saw patches from Riley this morning for the binder driver. Riley took over as the binder maintainer when it moved out of staging earlier this year. Thanks, Laura -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] edac, mce_amd_inj: Add README file
On Wed, May 27, 2015 at 02:03:37PM -0500, Aravind Gopalakrishnan wrote:
Provides information about each file and the usages.
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
drivers/edac/mce_amd_inj.c | 68
+-
1 file changed, 61 insertions(+), 7 deletions(-)
diff --git a/drivers/edac/mce_amd_inj.c b/drivers/edac/mce_amd_inj.c
index f1c1433..ca5b29f 100644
--- a/drivers/edac/mce_amd_inj.c
+++ b/drivers/edac/mce_amd_inj.c
@@ -291,17 +291,71 @@ MCE_INJECT_GET(bank);
DEFINE_SIMPLE_ATTRIBUTE(bank_fops, inj_bank_get, inj_bank_set, %llu\n);
+static const char readme_msg[] =
+ \nDescription of the files and their usages:\n\n
+ status: Set a value to be programmed into MCx_STATUS(bank)\n
+ \t The status bits provide insight into the type of\n
+ \t error that caused the MCE.\n\n
+ misc: Set value of MCx_MISC(bank)\n
+ \t misc register provides auxiliary info about the error. This\n
+ \t register is typically used for error thresholding purpose and\n
+ \t validity of the register is indicated by MCx_STATUS[MiscV]\n\n
+ addr: Error address value to be written to MCx_ADDR(bank)\n
+ \t This register is used to log address information associated\n
+ \t with the error.\n\n
+ Note: See respective BKDGs for the exact bit definitions of the\n
+ \t above registers as they mirror the MCi_[STATUS | MISC | ADDR]\n
+ \t hardware registers.\n\n
+ bank: Specify the bank you want to inject the error into.\n
+ \t The number of banks in a processor varies and is family/model\n
+ \t dependent. So, a sanity check performed while writing.\n
+ \t Writing to this file will trigger a #MC or APIC interrupts or\n
+ \t invoke the error decoder routines for AMD processors. The value\n
+ \t in 'flags' file decides which of above actions is triggered.\n\n
+ flags: Write to this file to speficy the error injection policy.\n
+ \t Allowed values:\n
+ \t\t\sw\ - SW error injection, Only calls error decoder\n
+ \t\t\troutines to print error info in human readable format\n
+ \t\t\hw\ - HW error injection, Forces a #MC,\n
+ \t\t\tcauses exception handler to handle the error\n
+ \t\t\tif UC or poll handler catches it if CE\n
+ \t\t\tWarning: Might cause system panic if MCx_STATUS[PCC]\n
+ \t\t\tis set. For debug purposes, consider setting\n
+ \t\t\t/debugfs_mountpoint/mce/fake_panic\n
+ \t\t\dfr\ - Trigger APIC interrupt for Deferred error\n
+ \t\t\tError is handled by deferred error apic handler if\n
+ \t\t\tfeature is present in HW.\n
+ \t\t\thr\ - Trigger APIC interrupt for threshold error\n
+ \t\t\tError is handled by threshold apic handler\n\n
+ cpu:The cpu to inject the error on.\n\n
+;
This one needs to be split in two - the second one adding the readme file...
+static ssize_t
+inj_readme_read(struct file *filp, char __user *ubuf,
+size_t cnt, loff_t *ppos)
+{
+ return simple_read_from_buffer(ubuf, cnt, ppos,
+ readme_msg, strlen(readme_msg));
+}
+
+static const struct file_operations readme_fops = {
+ .read = inj_readme_read,
+};
+
static struct dfs_node {
char *name;
struct dentry *d;
const struct file_operations *fops;
+ umode_t perm;
} dfs_fls[] = {
- { .name = status, .fops = status_fops },
- { .name = misc, .fops = misc_fops },
- { .name = addr, .fops = addr_fops },
- { .name = bank, .fops = bank_fops },
- { .name = flags, .fops = flags_fops },
- { .name = cpu,.fops = extcpu_fops },
+ { .name = status, .fops = status_fops, S_IRUSR | S_IWUSR },
+ { .name = misc, .fops = misc_fops, S_IRUSR | S_IWUSR },
+ { .name = addr, .fops = addr_fops, S_IRUSR | S_IWUSR },
+ { .name = bank, .fops = bank_fops, S_IRUSR | S_IWUSR },
+ { .name = flags, .fops = flags_fops,S_IRUSR | S_IWUSR },
+ { .name = cpu,.fops = extcpu_fops, S_IRUSR | S_IWUSR },
+ { .name = README, .fops = readme_fops, S_IRUSR | S_IRGRP |
+ S_IROTH },
... and the first one adding perm to struct dfs_node.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v3 42/45] nfs: Add richacl support
2015-05-29 17:24 GMT+02:00 Trond Myklebust trond.mykleb...@primarydata.com: It seems unreasonable to me to expect applications other than special file system maintenance tools to cater to such file system differences; there are just too many file systems out there for that to work. Instead, it would be better to use an interface that can be generalized across file systems. My point is that system.richacl is not such an interface. It can only ever work for local filesystems that understand and store local uids and gids. It has no support for the remote users/groups that are stored on your NFS/SMB server unless they happen to have a local mapping into uids and gids, and so the API is inappropriate to replace the existing NFSv4 acl API on the client. That can be changed if we find a reasonable solution. The problem is that you are 100% reliant on an accurate idmapper in order to convert the name@domain to a _correct_ uid/gid. It isn't sufficient to convert to just any valid uid/gid, because if your ACL tool is trying to edit the ACL, you can end up converting all those DENY modes for user 'johnny_rot...@blackhats.are.us' into DENY modes for user 'nobody'. ...and yes, libnfsidmap will happily convert all unknown user/groupnames into whatever uid/gid corresponds to 'nobody' without returning an error. That's indeed a problem, and I can think of two ways of addressing it: First, acl editors need to be careful about nobody entries; they need to be aware that nobody could actually stand for somebody else. (We could map unmappable users and groups to something else than nobody, but that might just shift the problem without improve anything.) What is the editor supposed to do about an entry it cannot even interpret, let alone store back to the server? In the end, it will have to be a user decision what to do about such entries, the editor can warn the user and make it harder to make mistakes though. Second, we could add support for passing through unmappable Who values as is. But that raises the problem of how to pass thtough and represent different kinds of identifiers: NFSv4 users user@domain and group@domain strings; smb users SIDs; maybe more. Now you have a mixture of some stuff that is being translated into local uid/gid format and therefore needs translating back when you're going to update the ACL, and some stuff that is not. What is the value of doing the mapping here? If you don't translate, you cannot copy the permissions to another file system. In the ideal case, everything can be translated; where that fails, the user probably wants to know. Thanks, Andreas -- 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] perf build: Do not fail on missing Build file
Em Fri, May 29, 2015 at 05:42:58PM +0200, Jiri Olsa escreveu: Allow nesting into directories without Build file. Currently we force include of the Build file, which fails the build when the Build file is missing. We already support empty *-in.o' objects if there's nothing in the directory to be compiled, so we can just use it for missing Build file cases. Also adding this case under tests. Thanks, applied. - Arnaldo -- 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 3/3] clk: mediatek: Use regmap clk-mux for mt8135
The pericfg controller is used by various device drivers, so that it
is implemented via a regmap. In the actual clk implementation for
mt8135, some clk-mux use the traditional register approach which
acceses the register via iomem.
This patch changes the use from iomem to the needed regmap.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
drivers/clk/mediatek/clk-mt8135.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8135.c
b/drivers/clk/mediatek/clk-mt8135.c
index a63435b..bfb56c6 100644
--- a/drivers/clk/mediatek/clk-mt8135.c
+++ b/drivers/clk/mediatek/clk-mt8135.c
@@ -513,11 +513,11 @@ static const char * const uart_ck_sel_parents[]
__initconst = {
uart_sel,
};
-static const struct mtk_composite peri_clks[] __initconst = {
- MUX(CLK_PERI_UART0_SEL, uart0_ck_sel, uart_ck_sel_parents, 0x40c, 0,
1),
- MUX(CLK_PERI_UART1_SEL, uart1_ck_sel, uart_ck_sel_parents, 0x40c, 1,
1),
- MUX(CLK_PERI_UART2_SEL, uart2_ck_sel, uart_ck_sel_parents, 0x40c, 2,
1),
- MUX(CLK_PERI_UART3_SEL, uart3_ck_sel, uart_ck_sel_parents, 0x40c, 3,
1),
+static const struct mtk_regm_mux peri_clks[] __initconst = {
+ MUX_REGMAP(CLK_PERI_UART0_SEL, uart0_ck_sel, uart_ck_sel_parents,
0x40c, 0, 1),
+ MUX_REGMAP(CLK_PERI_UART1_SEL, uart1_ck_sel, uart_ck_sel_parents,
0x40c, 1, 1),
+ MUX_REGMAP(CLK_PERI_UART2_SEL, uart2_ck_sel, uart_ck_sel_parents,
0x40c, 2, 1),
+ MUX_REGMAP(CLK_PERI_UART3_SEL, uart3_ck_sel, uart_ck_sel_parents,
0x40c, 3, 1),
};
static void __init mtk_topckgen_init(struct device_node *node)
@@ -573,20 +573,13 @@ static void __init mtk_pericfg_init(struct device_node
*node)
{
struct clk_onecell_data *clk_data;
int r;
- void __iomem *base;
-
- base = of_iomap(node, 0);
- if (!base) {
- pr_err(%s(): ioremap failed\n, __func__);
- return;
- }
clk_data = mtk_alloc_clk_data(CLK_PERI_NR_CLK);
mtk_clk_register_gates(node, peri_gates, ARRAY_SIZE(peri_gates),
clk_data);
- mtk_clk_register_composites(peri_clks, ARRAY_SIZE(peri_clks), base,
- mt8135_clk_lock, clk_data);
+ mtk_clk_regm_register_mux(node, peri_clks, ARRAY_SIZE(peri_clks),
+ clk_data);
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
if (r)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] clk: mediatek: Add support for clk-mux using regmap
This patches adds support for the mediatek clocks to be able to register
and use a clk-mux wich relies on regmap.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
drivers/clk/mediatek/clk-mtk.c | 37 +
drivers/clk/mediatek/clk-mtk.h | 26 ++
2 files changed, 63 insertions(+)
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 18444ae..cf953a8 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -111,6 +111,43 @@ int mtk_clk_register_gates(struct device_node *node, const
struct mtk_gate *clks
return 0;
}
+int mtk_clk_regm_register_mux(struct device_node *node,
+ const struct mtk_regm_mux *clks, int num,
+ struct clk_onecell_data *clk_data)
+{
+ int i;
+ struct clk *clk;
+ struct regmap *regmap;
+
+ if (!clk_data)
+ return -ENOMEM;
+
+ regmap = syscon_node_to_regmap(node);
+ if (IS_ERR(regmap)) {
+ pr_err(Cannot find regmap for %s: %ld\n, node-full_name,
+ PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
+
+ for (i = 0; i num; i++) {
+ const struct mtk_regm_mux *mux = clks[i];
+
+ clk = clk_regm_register_mux(NULL, mux-name, mux-parent_names,
+ mux-num_parents, 0, regmap,
+ mux-mux_offset, mux-mux_shift,
+ mux-mux_width, mux-flags, NULL);
+ if (IS_ERR(clk)) {
+ pr_err(Failed to register clk mux %s: %ld\n,
+ mux-name, PTR_ERR(clk));
+ continue;
+ }
+
+ clk_data-clks[mux-id] = clk;
+ }
+
+ return 0;
+}
+
struct clk *mtk_clk_register_composite(const struct mtk_composite *mc,
void __iomem *base, spinlock_t *lock)
{
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 61035b9..3f41725 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -156,6 +156,32 @@ void __init mtk_clk_register_plls(struct device_node *node,
const struct mtk_pll_data *plls, int num_plls,
struct clk_onecell_data *clk_data);
+struct mtk_regm_mux {
+ int id;
+ const char *name;
+ const char * const *parent_names;
+ u8 num_parents;
+ unsigned flags;
+ uint32_t mux_offset;
+ uint32_t mux_shift;
+ uint32_t mux_width;
+};
+
+int __init mtk_clk_regm_register_mux(struct device_node *node,
+ const struct mtk_regm_mux *clks, int num,
+ struct clk_onecell_data *clk_data);
+
+#define MUX_REGMAP(_id, _name, _parents, _offset, _shift, _width) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_names = _parents, \
+ .num_parents = ARRAY_SIZE(_parents),\
+ .flags = CLK_SET_RATE_PARENT, \
+ .mux_offset = _offset, \
+ .mux_shift = _shift,\
+ .mux_width = _width,\
+ }
+
#ifdef CONFIG_RESET_CONTROLLER
void mtk_register_reset_controller(struct device_node *np,
unsigned int num_regs, int regofs);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] clk: mux: Add regmap support for simple mux
Some devices like SoCs from Mediatek need to use the clock muxes
through a regmap interface.
This patch adds regmap support for the simple multiplexer
clock code.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
drivers/clk/clk-mux.c| 134 ++-
include/linux/clk-provider.h | 44 +-
2 files changed, 162 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 1fa2a8d..6f75116 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -29,6 +29,43 @@
#define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw)
+static void clk_mux_writel(struct clk_mux *mux, u32 val)
+{
+ if (mux-flags CLK_MUX_USE_REGMAP)
+ regmap_write(mux-regmap, mux-offset, val);
+ else
+ clk_writel(val, mux-reg);
+}
+
+static u32 clk_mux_readl(struct clk_mux *mux)
+{
+ u32 val;
+
+ if (mux-flags CLK_MUX_USE_REGMAP)
+ regmap_read(mux-regmap, mux-offset, val);
+ else
+ val = clk_readl(mux-reg);
+
+ return val;
+}
+
+static int clk_mux_update_bits(struct clk_mux *mux, u32 mask, u32 val)
+{
+ unsigned int ret;
+
+ if (mux-flags CLK_MUX_USE_REGMAP) {
+ ret = regmap_update_bits(mux-regmap, mux-offset, mask, val);
+ } else {
+ ret = clk_readl(mux-reg);
+ ret = ~mask;
+ ret |= val;
+ clk_writel(ret, mux-reg);
+ ret = 0;
+ }
+
+ return ret;
+}
+
static u8 clk_mux_get_parent(struct clk_hw *hw)
{
struct clk_mux *mux = to_clk_mux(hw);
@@ -42,7 +79,10 @@ static u8 clk_mux_get_parent(struct clk_hw *hw)
* OTOH, pmd_trace_clk_mux_ck uses a separate bit for each clock, so
* val = 0x4 really means bit 2, index starts at bit 0
*/
- val = clk_readl(mux-reg) mux-shift;
+
+ val = clk_mux_readl(mux);
+
+ val = mux-shift;
val = mux-mask;
if (mux-table) {
@@ -71,6 +111,7 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
struct clk_mux *mux = to_clk_mux(hw);
u32 val;
unsigned long flags = 0;
+ int ret = 0;
if (mux-table)
index = mux-table[index];
@@ -88,17 +129,19 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
if (mux-flags CLK_MUX_HIWORD_MASK) {
val = mux-mask (mux-shift + 16);
+ val |= index mux-shift;
+ clk_mux_writel(mux, val);
} else {
- val = clk_readl(mux-reg);
- val = ~(mux-mask mux-shift);
+ u32 mask = mux-mask mux-shift;
+
+ val = index mux-shift;
+ ret = clk_mux_update_bits(mux, mask, val);
}
- val |= index mux-shift;
- clk_writel(val, mux-reg);
if (mux-lock)
spin_unlock_irqrestore(mux-lock, flags);
- return 0;
+ return ret;
}
const struct clk_ops clk_mux_ops = {
@@ -113,9 +156,10 @@ const struct clk_ops clk_mux_ro_ops = {
};
EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
-struct clk *clk_register_mux_table(struct device *dev, const char *name,
+struct clk *__clk_register_mux_table(struct device *dev, const char *name,
const char * const *parent_names, u8 num_parents, unsigned long
flags,
- void __iomem *reg, u8 shift, u32 mask,
+ void __iomem *reg, struct regmap *regmap,
+ u32 offset, u8 shift, u32 mask,
u8 clk_mux_flags, u32 *table, spinlock_t *lock)
{
struct clk_mux *mux;
@@ -148,7 +192,12 @@ struct clk *clk_register_mux_table(struct device *dev,
const char *name,
init.num_parents = num_parents;
/* struct clk_mux assignments */
- mux-reg = reg;
+ if (clk_mux_flags CLK_MUX_USE_REGMAP)
+ mux-regmap = regmap;
+ else
+ mux-reg = reg;
+
+ mux-offset = offset;
mux-shift = shift;
mux-mask = mask;
mux-flags = clk_mux_flags;
@@ -163,18 +212,40 @@ struct clk *clk_register_mux_table(struct device *dev,
const char *name,
return clk;
}
+
+struct clk *clk_register_mux_table(struct device *dev, const char *name,
+ const char * const *parent_names, u8 num_parents,
+ unsigned long flags, void __iomem *reg, u8 shift, u32 mask,
+ u8 clk_mux_flags, u32 *table, spinlock_t *lock)
+{
+ return __clk_register_mux_table(dev, name, parent_names, num_parents,
+ flags, reg, NULL, 0,
+ shift, mask, clk_mux_flags,
+ table, lock);
+}
EXPORT_SYMBOL_GPL(clk_register_mux_table);
-struct clk *clk_register_mux(struct device *dev, const char *name,
- const char * const *parent_names, u8 num_parents, unsigned long
flags,
-
[PATCH v2 0/3] clk: Add regmap support for clk mulitplexer
This patch set adds regmap support for the simple clock multiplexer. Regmap use, apart from a pointer to the regmap struct needs an offset value to know where in the regmap it has to read/write. We add both fields to struct clk_mux. The driver will distinguish between a clock which is based on regmap or not through a flag specified for the mux. The approach does not break the existing clock framework API but adds two new functions for registering regmap clocks. Unregistering the clocks is independent of the use of regmap or not, so that no new function was implemented. As an example user of the regmap clock multiplexer, it was implemented on the mt8135. When accepted it will also be applied to the other Mediatek SoCs. Other possible user are Qualcomm SoCs which up to now implement their own regmap based clock multiplexer. Any comments welcome. Changes for v2: - use regmap_update_bits instead of read-write - fix flag check - add union in struct clk_mux - fix typo in commit message Matthias Brugger (3): clk: mux: Add regmap support for simple mux clk: mediatek: Add support for clk-mux using regmap clk: mediatek: Use regmap clk-mux for mt8135 drivers/clk/clk-mux.c | 134 +- drivers/clk/mediatek/clk-mt8135.c | 21 ++ drivers/clk/mediatek/clk-mtk.c| 37 +++ drivers/clk/mediatek/clk-mtk.h| 26 include/linux/clk-provider.h | 44 - 5 files changed, 232 insertions(+), 30 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Moving unseen/inactive MAINTAINER M: names and email addresses to CREDITS
On Fri, 2015-05-29 at 08:38 -0700, Laura Abbott wrote: On 05/28/2015 12:59 PM, Joe Perches wrote: Here is the list two ways, alphabetic by name and by section By Name: Riley Andrews riandr...@android.com ANDROID DRIVERS I just saw patches from Riley this morning for the binder driver. Riley took over as the binder maintainer when it moved out of staging earlier this year. Thanks, I'll remove Riley from this list... -- 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 v3 6/6] usb: chipidea: add work-around for Marvell HSIC PHY startup
The Marvell 28nm HSIC PHY requires the port to be forced to HS mode after
the port power is applied. This is done using the test mode in the PORTSC
register.
As HSIC is always HS, this work-around should be safe to do with all HSIC
PHYs and has been tested on i.MX6S.
Signed-off-by: Rob Herring r...@kernel.org
Tested-by: Peter Chen peter.c...@freescale.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-...@vger.kernel.org
---
drivers/usb/chipidea/host.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 21fe1a3..6cf87b8 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -37,12 +37,14 @@ static int (*orig_bus_suspend)(struct usb_hcd *hcd);
struct ehci_ci_priv {
struct regulator *reg_vbus;
+ struct ci_hdrc *ci;
};
static int ehci_ci_portpower(struct usb_hcd *hcd, int portnum, bool enable)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct ehci_ci_priv *priv = (struct ehci_ci_priv *)ehci-priv;
+ struct ci_hdrc *ci = priv-ci;
struct device *dev = hcd-self.controller;
int ret = 0;
int port = HCS_N_PORTS(ehci-hcs_params);
@@ -64,6 +66,15 @@ static int ehci_ci_portpower(struct usb_hcd *hcd, int
portnum, bool enable)
return ret;
}
}
+
+ if (enable (ci-platdata-phy_mode == USBPHY_INTERFACE_MODE_HSIC)) {
+ /*
+* Marvell 28nm HSIC PHY requires forcing the port to HS mode.
+* As HSIC is always HS, this should be safe for others.
+*/
+ hw_port_test_set(ci, 5);
+ hw_port_test_set(ci, 0);
+ }
return 0;
};
@@ -112,6 +123,7 @@ static int host_start(struct ci_hdrc *ci)
priv = (struct ehci_ci_priv *)ehci-priv;
priv-reg_vbus = NULL;
+ priv-ci = ci;
if (ci-platdata-reg_vbus !ci_otg_is_fsm_mode(ci)) {
if (ci-platdata-flags CI_HDRC_TURN_VBUS_EARLY_ON) {
--
2.1.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 v3 5/6] usb: chipidea: allow multiple instances to use default ci_default_pdata
Currently, ci_default_pdata is common to all instances of the driver and
gets modified by the core driver code. This is bad if there are multiple
instances of the device with different settings such as the phy type. Fix
this by making a copy of the default platform_data.
Signed-off-by: Rob Herring r...@kernel.org
Cc: Peter Chen peter.c...@freescale.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-...@vger.kernel.org
---
drivers/usb/chipidea/ci_hdrc_usb2.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c
b/drivers/usb/chipidea/ci_hdrc_usb2.c
index 45844c9..9eae1a1 100644
--- a/drivers/usb/chipidea/ci_hdrc_usb2.c
+++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
@@ -25,7 +25,7 @@ struct ci_hdrc_usb2_priv {
struct clk *clk;
};
-static struct ci_hdrc_platform_data ci_default_pdata = {
+static const struct ci_hdrc_platform_data ci_default_pdata = {
.capoffset = DEF_CAPOFFSET,
.flags = CI_HDRC_DISABLE_STREAMING,
};
@@ -37,8 +37,10 @@ static int ci_hdrc_usb2_probe(struct platform_device *pdev)
struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(dev);
int ret;
- if (!ci_pdata)
- ci_pdata = ci_default_pdata;
+ if (!ci_pdata) {
+ ci_pdata = devm_kmalloc(dev, sizeof(*ci_pdata), GFP_KERNEL);
+ *ci_pdata = ci_default_pdata; /* struct copy */
+ }
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
--
2.1.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 v3 0/6] Marvell PXA1928 USB support
This series adds USB PHYs and EHCI host drivers for the Marvell PXA1928
SOC.
The OTG block is based on ChipIdea and works with the chipidea,usb2
compatible driver as is just by adding the PHY driver. Yay! After more
testing it turns out the EHCI host is also based on ChipIdea too. So
this version uses the ChipIdea driver for both. A couple of fixes are
needed to make the ChipIdea driver work with the PXA1928 EHCI host.
Rob
v3:
- Clarify FSL only binding properties.
- Add owner field to phy_ops.
- Restructure split between PHY init/power_on and power_off/exit.
- Fix PHY error path handling.
- drop unrelated change in ci_hdrc_usb2.c.
- Add Peter's tested-by.
v2:
- Use ChipIdea driver for EHCI host, dropping the Marvell specific EHCI
driver
- Consolidate ChipIdea bindings to single common doc.
- rename phy driver files to phy-pxa-28nm-{usb2,hsic}.c
- Simplified work-around for HSIC phy/controller handshake.
Rob Herring (6):
dt-bindings: Add Marvell PXA1928 USB and HSIC PHY bindings
phy: Add Marvell USB 2.0 OTG 28nm PHY
phy: add Marvell HSIC 28nm PHY
dt-bindings: Consolidate ChipIdea USB ci13xxx bindings
usb: chipidea: allow multiple instances to use default
ci_default_pdata
usb: chipidea: add work-around for Marvell HSIC PHY startup
.../devicetree/bindings/phy/pxa1928-usb-phy.txt| 18 ++
.../devicetree/bindings/usb/ci-hdrc-imx.txt| 35 --
.../devicetree/bindings/usb/ci-hdrc-qcom.txt | 17 -
.../devicetree/bindings/usb/ci-hdrc-usb2.txt | 22 +-
.../devicetree/bindings/usb/ci-hdrc-zevio.txt | 17 -
drivers/phy/Kconfig| 20 ++
drivers/phy/Makefile | 2 +
drivers/phy/phy-pxa-28nm-hsic.c| 220 +
drivers/phy/phy-pxa-28nm-usb2.c| 355 +
drivers/usb/chipidea/ci_hdrc_usb2.c| 8 +-
drivers/usb/chipidea/host.c| 12 +
11 files changed, 653 insertions(+), 73 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/pxa1928-usb-phy.txt
delete mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
delete mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
delete mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt
create mode 100644 drivers/phy/phy-pxa-28nm-hsic.c
create mode 100644 drivers/phy/phy-pxa-28nm-usb2.c
--
2.1.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] PM / Wakeirq: Fix typo in prototype for dev_pm_set_dedicated_wake_irq
Looks like I only built test the dev_pm_set_wake_irq and not the
dev_pm_set_dedicated_wake_irq case on x86.
Turns out there's a typo for the dev_pm_set_dedicated_wake_irq
prototype that causes a build error if CONFIG_COMPILE_TEST
and CONFIG_MMC_OMAP_HS are selected.
Cc: Stephen Rothwell s...@canb.auug.org.au
Cc: Ulf Hansson ulf.hans...@linaro.org
Reported-by: Jim Davis jim.ep...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
include/linux/pm_wakeirq.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/pm_wakeirq.h b/include/linux/pm_wakeirq.h
index 4046fa1..cd5b62d 100644
--- a/include/linux/pm_wakeirq.h
+++ b/include/linux/pm_wakeirq.h
@@ -30,8 +30,7 @@ static inline int dev_pm_set_wake_irq(struct device *dev, int
irq)
return 0;
}
-static inline int dev_pm_set_dedicated__wake_irq(struct device *dev,
-int irq)
+static inline int dev_pm_set_dedicated_wake_irq(struct device *dev, int irq)
{
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 12/12] drivers/block/pmem: Map NVDIMM with ioremap_wt()
On Fri, May 29, 2015 at 2:11 AM, Borislav Petkov b...@alien8.de wrote: On Wed, May 27, 2015 at 09:19:04AM -0600, Toshi Kani wrote: The pmem driver maps NVDIMM with ioremap_nocache() as we cannot write back the contents of the CPU caches in case of a crash. This patch changes to use ioremap_wt(), which provides uncached writes but cached reads, for improving read performance. Signed-off-by: Toshi Kani toshi.k...@hp.com --- drivers/block/pmem.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c index eabf4a8..095dfaa 100644 --- a/drivers/block/pmem.c +++ b/drivers/block/pmem.c @@ -139,11 +139,11 @@ static struct pmem_device *pmem_alloc(struct device *dev, struct resource *res) } /* - * Map the memory as non-cachable, as we can't write back the contents + * Map the memory as write-through, as we can't write back the contents * of the CPU caches in case of a crash. */ err = -ENOMEM; - pmem-virt_addr = ioremap_nocache(pmem-phys_addr, pmem-size); + pmem-virt_addr = ioremap_wt(pmem-phys_addr, pmem-size); if (!pmem-virt_addr) goto out_release_region; Dan, Ross, what about this one? ACK to pick it up as a temporary solution? I see that is_new_memtype_allowed() is updated to disallow some combinations, but the manual seems to imply any mixing of memory types is unsupported. Which worries me even in the current code where we have uncached mappings in the driver, and potentially cached DAX mappings handed out to userspace. A general quibble separate from this patch is that we don't have a way of knowing if ioremap() will reject or change our requested memory type. Shouldn't the driver be explicitly requesting a known valid type in advance? Lastly we now have the PMEM API patches from Ross out for review where he is assuming cached mappings with non-temporal writes: https://lists.01.org/pipermail/linux-nvdimm/2015-May/000929.html. This gives us WC semantics on writes which I believe has the nice property of reducing the number of write transactions to memory. Also, the numbers in the paper seem to be assuming DAX operation, but this ioremap_wt() is in the driver and typically behind a file system. Are the numbers relevant to that usage mode? -- 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] Doc: libata: Fix spelling typo found in libata.xml
On Fri, May 29, 2015 at 11:11:51PM +0900, Masanari Iida wrote: This patch fix a spelling typo found in libata.xml. It is because libata.xml is generated from comments in source, I have to fix it in libata-core.c Signed-off-by: Masanari Iida standby2...@gmail.com Applied to libata/for-4.2. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] s390/sclp: pass timeout as HZ independent value
On Fri, 29 May 2015, Heiko Carstens wrote: On Fri, May 29, 2015 at 04:16:46PM +0200, Nicholas Mc Guire wrote: On Fri, 29 May 2015, Michael Holzheu wrote: On Fri, 29 May 2015 13:49:36 +0200 Nicholas Mc Guire der.h...@hofr.at wrote: On Fri, 29 May 2015, Heiko Carstens wrote: On Fri, May 29, 2015 at 11:51:54AM +0200, Nicholas Mc Guire wrote: On Fri, 29 May 2015, Heiko Carstens wrote: Yes, the orginal code seems to be broken. Since I've no idea what the intended timeout value should be, let's simply ask Michael, who wrote this code eight years ago ;) While these lines get touched anyway, it would make sense to use schedule_timeout_interruptible() instead, and get rid of set_current_state(). Well that is not really equivalent schedule_timeout_interruptible() is doing __set_current_state not set_current_state so that would drop the mb() and no WRITE_ONCE() And how does that matter in this case? I do not know - did not look into it - in any case its not a 1:1 API consolidation that all I wanted to point out before changing anything. I agree, 1:1 consolidation is better here. But I would like to remove the SDIAS_SLEEP_TICKS define and just use HZ / 2 in schedule_timeout(). Could you please resend the updated patch? We will then add it to our tree. will do that. I was compile testing with x86_64-gcc-4.6.3-nolibc_s390x-linux.tar.bz2 https://www.kernel.org/pub/tools/crosstool/ but that fails for all of the available defconfigs in arch/s390/configs would you have a pointer to a toolchain that can be used for compile testing ? Just change processor type to IBM System z10, or manually edit .config, and change CONFIG_MARCH_ZEC12 to be disabled and CONFIG_MARCH_Z10 instead to yes. The same applies to CONFIG_MARCH_ZEC12_TUNE. However we will accept the patch also without compile test. yup - thats working - thanks ! thx! hofrat -- 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 1/4] NTP: rtc: Add CONFIG_RTC_SYSTOHC_DEVICE for NTP synchronization
From: Xunlei Pang pang.xun...@linaro.org
Currently, CONFIG_RTC_SYSTOHC uses CONFIG_RTC_HCTOSYS_DEVICE which
is originally used by CONFIG_RTC_HCTOSYS, but this rtc device has
some limiations, for example, it must be battery-backed, be able
to work with irq off and through system suspension, etc.
So add CONFIG_RTC_SYSTOHC_DEVICE used exclusively for CONFIG_RTC_SYSTOHC,
it is more lenient compared to CONFIG_RTC_HCTOSYS_DEVICE, and could
be assigned any available RTC in the system. Default value is rtc0.
After this patch, NTP will sync up rtc0 by default.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
drivers/rtc/Kconfig | 28 +++-
drivers/rtc/systohc.c | 2 +-
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 0fe4ad8..f429e9a 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -25,17 +25,9 @@ config RTC_HCTOSYS
the value read from a specified RTC device. This is useful to avoid
unnecessary fsck runs at boot time, and to network better.
-config RTC_SYSTOHC
- bool Set the RTC time based on NTP synchronization
- default y
- help
- If you say yes here, the system time (wall clock) will be stored
- in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11
- minutes if userspace reports synchronized NTP status.
-
config RTC_HCTOSYS_DEVICE
string RTC used to set the system time
- depends on RTC_HCTOSYS = y || RTC_SYSTOHC = y
+ depends on RTC_HCTOSYS = y
default rtc0
help
The RTC device that will be used to (re)initialize the system
@@ -56,6 +48,24 @@ config RTC_HCTOSYS_DEVICE
sleep states. Do not specify an RTC here unless it stays powered
during all this system's supported sleep states.
+config RTC_SYSTOHC
+ bool Set the RTC time based on NTP synchronization
+ default y
+ help
+ If you say yes here, the system time (wall clock) will be stored
+ in the RTC specified by RTC_HCTOSYS_DEVICE approximately every 11
+ minutes if userspace reports synchronized NTP status.
+
+config RTC_SYSTOHC_DEVICE
+ string RTC used to synchronize NTP adjustment
+ depends on RTC_SYSTOHC = y
+ default rtc0
+ help
+ The RTC device used for NTP synchronization. The main difference
+ between RTC_HCTOSYS_DEVICE and RTC_SYSTOHC_DEVICE is that this
+ one can sleep when setting time, because it runs in the workqueue
+ context.
+
config RTC_DEBUG
bool RTC debug support
help
diff --git a/drivers/rtc/systohc.c b/drivers/rtc/systohc.c
index 7728d5e..b4a68ff 100644
--- a/drivers/rtc/systohc.c
+++ b/drivers/rtc/systohc.c
@@ -31,7 +31,7 @@ int rtc_set_ntp_time(struct timespec64 now)
else
rtc_time64_to_tm(now.tv_sec + 1, tm);
- rtc = rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
+ rtc = rtc_class_open(CONFIG_RTC_SYSTOHC_DEVICE);
if (rtc) {
/* rtc_hctosys exclusively uses UTC, so we call set_time here,
* not set_mmss. */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] cris: time: Cleanup of persistent clock stuff
From: Xunlei Pang pang.xun...@linaro.org
- Remove update_persistent_clock(), as it does nothing now.
- Remove read_persistent_clock(), let it fall back to the weak version.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
arch/cris/Kconfig | 1 -
arch/cris/kernel/time.c | 25 -
2 files changed, 26 deletions(-)
diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig
index 0314e32..982d562 100644
--- a/arch/cris/Kconfig
+++ b/arch/cris/Kconfig
@@ -46,7 +46,6 @@ config CRIS
select ARCH_WANT_IPC_PARSE_VERSION
select GENERIC_IRQ_SHOW
select GENERIC_IOMAP
- select GENERIC_CMOS_UPDATE
select MODULES_USE_ELF_RELA
select CLONE_BACKWARDS2
select OLD_SIGSUSPEND
diff --git a/arch/cris/kernel/time.c b/arch/cris/kernel/time.c
index 7780d37..2dda6da 100644
--- a/arch/cris/kernel/time.c
+++ b/arch/cris/kernel/time.c
@@ -39,31 +39,6 @@
extern unsigned long loops_per_jiffy; /* init/main.c */
unsigned long loops_per_usec;
-int set_rtc_mmss(unsigned long nowtime)
-{
- D(printk(KERN_DEBUG set_rtc_mmss(%lu)\n, nowtime));
- return 0;
-}
-
-/* grab the time from the RTC chip */
-unsigned long get_cmos_time(void)
-{
- return 0;
-}
-
-
-int update_persistent_clock(struct timespec now)
-{
- return set_rtc_mmss(now.tv_sec);
-}
-
-void read_persistent_clock(struct timespec *ts)
-{
- ts-tv_sec = 0;
- ts-tv_nsec = 0;
-}
-
-
extern void cris_profile_sample(struct pt_regs* regs);
void
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: dts: mt8173: support arm64 cpuidle-dt
On Fri, May 29, 2015 at 08:01:46AM +0100, Howard Chen wrote:
This patch adds an idle-states node to describe the mt8173 idle states and
also adds references to the idle-states node in all CPU nodes.
Signed-off-by: Howard Chen howard.c...@linaro.org
---
You should have added a list of incremental changes (v1-v2-v3) here
otherwise there is no point in adding a patch version, we are not
supposed to remember what you have changed.
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 924fdb6..47e8d56 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -49,6 +49,8 @@
device_type = cpu;
compatible = arm,cortex-a53;
reg = 0x000;
+ enable-method = psci;
+ cpu-idle-states = CPU_SLEEP_0;
};
cpu1: cpu@1 {
@@ -56,6 +58,7 @@
compatible = arm,cortex-a53;
reg = 0x001;
enable-method = psci;
+ cpu-idle-states = CPU_SLEEP_0;
};
cpu2: cpu@100 {
@@ -63,6 +66,7 @@
compatible = arm,cortex-a57;
reg = 0x100;
enable-method = psci;
+ cpu-idle-states = CPU_SLEEP_0;
};
cpu3: cpu@101 {
@@ -70,6 +74,20 @@
compatible = arm,cortex-a57;
reg = 0x101;
enable-method = psci;
+ cpu-idle-states = CPU_SLEEP_0;
+ };
+
+ idle-states {
+ entry-method = arm,psci;
+
+ CPU_SLEEP_0: cpu-sleep-0 {
+ compatible = arm,idle-state;
UltraNit: please move local-timer-stop here to keep the property ordering
as in the bindings.
More importantly, IIRC the idle state was not local-timer-stop in v2,
what changed in the interim ? v1-v2 the cluster idle state disappeared,
now the local timer seems to stop when it was not before (and that is
the same HW), I hope things are settled now.
https://lkml.org/lkml/2015/4/7/76
+ arm,psci-suspend-param = 0x001;
Move this property as last on the list, let's keep the generic
properties first.
+ entry-latency-us = 639;
+ exit-latency-us = 680;
+ min-residency-us = 1088;
+ local-timer-stop;
+ };
};
};
I guess there is no hope of seeing the cluster state restored (?).
I would like some explanation regarding local-timer-stop change, apart
from that you can add:
Acked-by: Lorenzo Pieralisi lorenzo.pieral...@arm.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 0/2] spi: atmel: add support to FIFOs and the internal chip-select
This series of patches add support to features introduced by the Atmel sama5d2x SoC. Cyrille Pitchen (2): spi: atmel: add support for the internal chip-select of the spi controller spi: atmel: add support to FIFOs drivers/spi/spi-atmel.c | 276 1 file changed, 257 insertions(+), 19 deletions(-) -- 1.8.2.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 2/2] spi: atmel: add support to FIFOs
To enable the FIFO feature a atmel,fifo-size attribute with a strictly positive value must be added into the node of the device-tree describing the spi controller. When FIFOs are enabled, the RX one is forced to operate in SINGLE data mode because this driver configures the spi controller as a master. In master mode only, the Received Data Register has an additionnal Peripheral Chip Select field, which prevents us from reading more than a single data at each register access. Besides, the TX FIFO operates in MULTIPLE data mode. However, even when a 8bit data size is used, only two data by access could be written into the Transmit Data Register. Indeed the first data has to be written into the lowest 16 bits whereas the second data has to be written into the highest 16 bits of the TDR. When DMA transfers are used to send data, we don't rework the transmit buffer to cope with this hardware limitation: the additional copies required to prepare a new input buffer suited to both the DMA controller and the spi controller would waste all the benefit of the DMA transfer. Instead, the DMA controller is configured to write only one data at time into the TDR. In pio mode, two data are written in the TDR in a single access. Signed-off-by: Cyrille Pitchen cyrille.pitc...@atmel.com --- drivers/spi/spi-atmel.c | 239 ++-- 1 file changed, 229 insertions(+), 10 deletions(-) diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index aa7d202..47d04c3 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -41,6 +41,8 @@ #define SPI_CSR1 0x0034 #define SPI_CSR2 0x0038 #define SPI_CSR3 0x003c +#define SPI_FMR0x0040 +#define SPI_FLR0x0044 #define SPI_VERSION0x00fc #define SPI_RPR0x0100 #define SPI_RCR0x0104 @@ -62,6 +64,14 @@ #define SPI_SWRST_SIZE 1 #define SPI_LASTXFER_OFFSET24 #define SPI_LASTXFER_SIZE 1 +#define SPI_TXFCLR_OFFSET 16 +#define SPI_TXFCLR_SIZE1 +#define SPI_RXFCLR_OFFSET 17 +#define SPI_RXFCLR_SIZE1 +#define SPI_FIFOEN_OFFSET 30 +#define SPI_FIFOEN_SIZE1 +#define SPI_FIFODIS_OFFSET 31 +#define SPI_FIFODIS_SIZE 1 /* Bitfields in MR */ #define SPI_MSTR_OFFSET0 @@ -114,6 +124,22 @@ #define SPI_TXEMPTY_SIZE 1 #define SPI_SPIENS_OFFSET 16 #define SPI_SPIENS_SIZE1 +#define SPI_TXFEF_OFFSET 24 +#define SPI_TXFEF_SIZE 1 +#define SPI_TXFFF_OFFSET 25 +#define SPI_TXFFF_SIZE 1 +#define SPI_TXFTHF_OFFSET 26 +#define SPI_TXFTHF_SIZE1 +#define SPI_RXFEF_OFFSET 27 +#define SPI_RXFEF_SIZE 1 +#define SPI_RXFFF_OFFSET 28 +#define SPI_RXFFF_SIZE 1 +#define SPI_RXFTHF_OFFSET 29 +#define SPI_RXFTHF_SIZE1 +#define SPI_TXFPTEF_OFFSET 30 +#define SPI_TXFPTEF_SIZE 1 +#define SPI_RXFPTEF_OFFSET 31 +#define SPI_RXFPTEF_SIZE 1 /* Bitfields in CSR0 */ #define SPI_CPOL_OFFSET0 @@ -157,6 +183,22 @@ #define SPI_TXTDIS_OFFSET 9 #define SPI_TXTDIS_SIZE1 +/* Bitfields in FMR */ +#define SPI_TXRDYM_OFFSET 0 +#define SPI_TXRDYM_SIZE2 +#define SPI_RXRDYM_OFFSET 4 +#define SPI_RXRDYM_SIZE2 +#define SPI_TXFTHRES_OFFSET16 +#define SPI_TXFTHRES_SIZE 6 +#define SPI_RXFTHRES_OFFSET24 +#define SPI_RXFTHRES_SIZE 6 + +/* Bitfields in FLR */ +#define SPI_TXFL_OFFSET0 +#define SPI_TXFL_SIZE 6 +#define SPI_RXFL_OFFSET16 +#define SPI_RXFL_SIZE 6 + /* Constants for BITS */ #define SPI_BITS_8_BPT 0 #define SPI_BITS_9_BPT 1 @@ -167,6 +209,9 @@ #define SPI_BITS_14_BPT6 #define SPI_BITS_15_BPT7 #define SPI_BITS_16_BPT8 +#define
Re: [PATCH] of: Move OF flags to be visible even when !CONFIG_OF
On Sun, Apr 26, 2015 at 7:45 AM, Wolfram Sang w...@the-dreams.de wrote: On Fri, Apr 24, 2015 at 12:41:56PM +0300, Pantelis Antoniou wrote: We need those to be visible even when compiling with CONFIG_OF disabled, since even the empty of_node_*_flag() method use the flag. Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com Acked-by: Wolfram Sang wsa+rene...@sang-engineering.com Applied, thanks. Rob You should have mentioned that this is needed to get a bugfix for OF_DYNAMIC in i2c upstream! -- 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 v10 11/12] x86, mm, pat: Refactor !pat_enabled handling
On Fri, May 29, 2015 at 08:27:08AM -0600, Toshi Kani wrote: This simply preserves the original error check in the code. This error check makes sure that all CPUs have the PAT feature supported when PAT is enabled. This error can only happen when heterogeneous CPUs are installed/emulated on the system/guest. This check may be paranoid, but this cleanup is not meant to modify such an error check. No, this is a ridiculous attempt to justify crazy code. Please do it right. If the cleanup makes the code more insane than it is, then don't do it in the first place. Can you consider the patch 10/12-11/12 as a separate patchset from the WT series? If that is OK, I will resubmit 10/12 (BUG-panic) and 11/12 (commit log update). That's not enough. 11/12 is a convoluted mess which needs splitting and more detailed explanations in the commit messages. So no. Read what I said: do the cleanup *first* , *then* add the new functionality. The WT patches shouldn't change all too much from what you have now. Also, 11/12 changes stuff which you add in 1/12. This churn is useless and shouldn't be there at all. So you should be able to do the cleanup first and have the WT stuff ontop just fine. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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] perf tools: introduce arm64 support unwind test.
Em Fri, May 29, 2015 at 04:40:24PM +0200, Jiri Olsa escreveu: On Fri, May 29, 2015 at 10:32:55AM -0300, Arnaldo Carvalho de Melo wrote: Em Fri, May 29, 2015 at 11:21:19AM +0200, Jiri Olsa escreveu: On Thu, May 28, 2015 at 10:43:14AM -0300, Arnaldo Carvalho de Melo wrote: Em Thu, May 28, 2015 at 03:17:26PM +0800, Wangnan (F) escreveu: Ping? Jiri, Ack? yep, I've already ack-ed that.. should be on the lkml somewhere ;-) And from a quick look, isn't this better split in two pieces, i.e. the first wiring up ARM64 to libunwing, i.e. all those perf_regs.h files being added to tools/perf/arch/arm64/, and then a second patch, enabling the dwarf unwind 'perf test' entry to run on ARM64? I guess.. but the change is fairly small, so it did not occur to me as necessary.. :-) I felt mislead when looking at the subject, i.e. hey, a new test, testing unwind on arm64, no, it wasn't that, it introduces support for unwind on ARM64 by providing that regs mapping, then it _enables_ an existing test on arm64 :-\ still it's good news right? ;-) Whatever, I'll fix at least the cset log message and apply... - Arnaldo -- 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 1/4] ozwpan: Use proper check to prevent heap overflow
On Fri, May 29, 2015 at 2:36 PM, Frans Klaver franskla...@gmail.com wrote: I would say that it is because part of the expression has been placed inside parentheses: a - b + 1 == a - (b - 1) Guess it makes the decision logic slightly more readable. Yes, exactly this. It's so that the bounding check conditional prior looks identical to the actual subtraction, making it much easier to read and verify. -- 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 usb-gadget tree
On Fri, May 29, 2015 at 06:32:13PM +1000, Stephen Rothwell wrote:
Hi Felipe,
After merging the usb-gadget tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/module.h:17:0,
from drivers/usb/gadget/legacy/nokia.c:19:
drivers/usb/gadget/legacy/nokia.c: In function '__check_num_buffers':
drivers/usb/gadget/function/f_mass_storage.h:51:34: error: 'fsg_num_buffers'
undeclared (first use in this function)
module_param_named(num_buffers, fsg_num_buffers, uint, S_IRUGO);\
^
include/linux/moduleparam.h:387:68: note: in definition of macro
'__param_check'
static inline type __always_unused *__check_##name(void) { return(p); }
^
include/linux/moduleparam.h:145:2: note: in expansion of macro
'param_check_uint'
param_check_##type(name, (value)); \
^
drivers/usb/gadget/function/f_mass_storage.h:51:2: note: in expansion of
macro 'module_param_named'
module_param_named(num_buffers, fsg_num_buffers, uint, S_IRUGO);\
^
drivers/usb/gadget/legacy/nokia.c:45:1: note: in expansion of macro
'FSG_MODULE_PARAMETERS'
FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
^
drivers/usb/gadget/function/f_mass_storage.h:51:34: note: each undeclared
identifier is reported only once for each function it appears in
module_param_named(num_buffers, fsg_num_buffers, uint, S_IRUGO);\
^
include/linux/moduleparam.h:387:68: note: in definition of macro
'__param_check'
static inline type __always_unused *__check_##name(void) { return(p); }
^
include/linux/moduleparam.h:145:2: note: in expansion of macro
'param_check_uint'
param_check_##type(name, (value)); \
^
drivers/usb/gadget/function/f_mass_storage.h:51:2: note: in expansion of
macro 'module_param_named'
module_param_named(num_buffers, fsg_num_buffers, uint, S_IRUGO);\
^
drivers/usb/gadget/legacy/nokia.c:45:1: note: in expansion of macro
'FSG_MODULE_PARAMETERS'
FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
^
drivers/usb/gadget/legacy/nokia.c: At top level:
drivers/usb/gadget/function/f_mass_storage.h:51:34: error: 'fsg_num_buffers'
undeclared here (not in a function)
module_param_named(num_buffers, fsg_num_buffers, uint, S_IRUGO);\
^
include/linux/moduleparam.h:224:22: note: in definition of macro
'__module_param_call'
level, flags, { arg } }
^
include/linux/moduleparam.h:146:2: note: in expansion of macro
'module_param_cb'
module_param_cb(name, param_ops_##type, value, perm); \
^
drivers/usb/gadget/function/f_mass_storage.h:51:2: note: in expansion of
macro 'module_param_named'
module_param_named(num_buffers, fsg_num_buffers, uint, S_IRUGO);\
^
drivers/usb/gadget/legacy/nokia.c:45:1: note: in expansion of macro
'FSG_MODULE_PARAMETERS'
FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
^
Caused by commit e4f8ef7b0770 (usb: gadget: nokia: Add mass storage
driver to g_nokia).
I have used the usb-gadget tree from next-20150528 for today.
I'll drop that patch, thanks
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 1/4] ozwpan: Use proper check to prevent heap overflow
On Fri, May 29, 2015 at 2:41 PM, Dan Carpenter dan.carpen...@oracle.com wrote: Acked-by: Dan Carpenter dan.carpen...@oracle.com Acked for the rest of the set too? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/3] memcg: get rid of mm_struct::owner
On Fri 29-05-15 11:23:28, Tejun Heo wrote: Hello, On Fri, May 29, 2015 at 04:57:39PM +0200, Michal Hocko wrote: [...] OK so you creat a task A (leader) which clones several tasks Pn with CLONE_VM without CLONE_THREAD. Moving A around would control memcg membership while Pn could be moved around freely to control membership in other controllers (e.g. cpu to control shares). So it is something like moving threads separately. Sure, it'd behave clearly in certain cases but then again you'd have cases where how mm-owner changes isn't clear at all when seen from the userland. Sure. I am definitely _not_ advocating this use case! As said before, I consider it abuse. It is just fair to point out this is a user visible change IMO. e.g. When the original owner goes away, the assignment of the next owner is essentially arbitrary. That's what I meant by saying it was already a crapshoot. We should definitely document the change but this isn't likely to be an issue. CLONE_VM !CLONE_THREAD is an extreme corner case to begin with and even the behavior there wasn't all that clearly defined. That is the line of argumentation in my changelog ;) -- Michal Hocko SUSE Labs -- 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: [trivial PATCH] tps6507x.txt: Remove executable permission
On Thu, Apr 16, 2015 at 5:43 PM, Joe Perches j...@perches.com wrote: Documention text files shouldn't be executable. Signed-off-by: Joe Perches j...@perches.com Applied, thanks. Rob --- Documentation/devicetree/bindings/mfd/tps6507x.txt | 0 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/Documentation/devicetree/bindings/mfd/tps6507x.txt old mode 100755 new mode 100644 -- 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] perf tools: Make Ctrl-C stop processing on TUI
Em Fri, May 29, 2015 at 10:24:37AM -0300, Arnaldo Carvalho de Melo escreveu:
Em Fri, May 29, 2015 at 09:53:44PM +0900, Namhyung Kim escreveu:
It was inconvenient that perf cannot be quit with SIGINT during
processing samples on TUI especially for large data files.
This was because the first argument of SLang_init_tty(), abort_char,
being 0. The manual says it's the ascii value of the control
character that will be used to generate the interrupt signal [1].
Passing -1 means to use the default value (Ctrl-C).
However, after processing samples, Ctrl-C was used to in other cases as
well - like stepping back from annotate. So recover the original
behavior after processing.
Right, but the way this was implemented it is error prone, I think...
I.e. better would be to enclose whatever section of code we want to be
able to interrupt with control+C with something like:
ui__control_c_terminates(true);
process events, etc.
ui__control_c_terminates(false);
Applied anyway, this can be done later...
- Arnaldo
Or some more suitable name, couldn't think right now of any that would
reuse something well established...
The way you implemented it, as soon as we implement a new browser, we
will have to recall this detail to have Control+C working as it always
worked on tools/perf, i.e. not terminating it.
- Arnaldo
[1] http://jedsoft.org/slang/doc/html/cslang-6.html#ss6.1
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/ui/browsers/annotate.c | 4
tools/perf/ui/browsers/hists.c| 4
tools/perf/ui/tui/setup.c | 2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/ui/browsers/annotate.c
b/tools/perf/ui/browsers/annotate.c
index e5250eb2dd57..acb0e23b138e 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -838,6 +838,10 @@ int map_symbol__tui_annotate(struct map_symbol *ms,
struct perf_evsel *evsel,
int hist_entry__tui_annotate(struct hist_entry *he, struct perf_evsel
*evsel,
struct hist_browser_timer *hbt)
{
+ /* reset abort key so that it can get Ctrl-C as a key */
+ SLang_reset_tty();
+ SLang_init_tty(0, 0, 0);
+
return map_symbol__tui_annotate(he-ms, evsel, hbt);
}
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index f981cb8f0158..e64893f2fd7f 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1741,6 +1741,10 @@ static int perf_evsel__hists_browse(struct
perf_evsel *evsel, int nr_events,
if (browser == NULL)
return -1;
+ /* reset abort key so that it can get Ctrl-C as a key */
+ SLang_reset_tty();
+ SLang_init_tty(0, 0, 0);
+
if (min_pcnt) {
browser-min_pcnt = min_pcnt;
hist_browser__update_nr_entries(browser);
diff --git a/tools/perf/ui/tui/setup.c b/tools/perf/ui/tui/setup.c
index b77e1d771363..60d1f29b4b50 100644
--- a/tools/perf/ui/tui/setup.c
+++ b/tools/perf/ui/tui/setup.c
@@ -129,7 +129,7 @@ int ui__init(void)
err = SLsmg_init_smg();
if (err 0)
goto out;
- err = SLang_init_tty(0, 0, 0);
+ err = SLang_init_tty(-1, 0, 0);
if (err 0)
goto out;
--
2.4.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/2] clk: keystone: add support for post divider register for main pll
Main PLL controller has post divider bits in a separate register in
pll controller. Use the value from this register instead of fixed
divider when available.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
.../devicetree/bindings/clock/keystone-pll.txt | 8
drivers/clk/keystone/pll.c | 20 ++--
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt
b/Documentation/devicetree/bindings/clock/keystone-pll.txt
index 225990f..47570d2 100644
--- a/Documentation/devicetree/bindings/clock/keystone-pll.txt
+++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt
@@ -15,8 +15,8 @@ Required properties:
- compatible : shall be ti,keystone,main-pll-clock or ti,keystone,pll-clock
- clocks : parent clock phandle
- reg - pll control0 and pll multipler registers
-- reg-names : control and multiplier. The multiplier is applicable only for
- main pll clock
+- reg-names : control, multiplier and post-divider. The multiplier and
+ post-divider registers are applicable only for main pll clock
- fixed-postdiv : fixed post divider value. If absent, use clkod register bits
for postdiv
@@ -25,8 +25,8 @@ Example:
#clock-cells = 0;
compatible = ti,keystone,main-pll-clock;
clocks = refclksys;
- reg = 0x02620350 4, 0x02310110 4;
- reg-names = control, multiplier;
+ reg = 0x02620350 4, 0x02310110 4, 0x02310108 4;
+ reg-names = control, multiplier, post-divider;
fixed-postdiv = 2;
};
diff --git a/drivers/clk/keystone/pll.c b/drivers/clk/keystone/pll.c
index 0dd8a4b..4a375ea 100644
--- a/drivers/clk/keystone/pll.c
+++ b/drivers/clk/keystone/pll.c
@@ -37,7 +37,8 @@
* Main PLL or any other PLLs in the device such as ARM PLL, DDR PLL
* or PA PLL available on keystone2. These PLLs are controlled by
* this register. Main PLL is controlled by a PLL controller.
- * @pllm: PLL register map address
+ * @pllm: PLL register map address for multiplier bits
+ * @pllod: PLL register map address for post divider bits
* @pll_ctl0: PLL controller map address
* @pllm_lower_mask: multiplier lower mask
* @pllm_upper_mask: multiplier upper mask
@@ -53,6 +54,7 @@ struct clk_pll_data {
u32 phy_pllm;
u32 phy_pll_ctl0;
void __iomem *pllm;
+ void __iomem *pllod;
void __iomem *pll_ctl0;
u32 pllm_lower_mask;
u32 pllm_upper_mask;
@@ -102,7 +104,11 @@ static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
/* read post divider from od bits*/
postdiv = ((val pll_data-clkod_mask)
pll_data-clkod_shift) + 1;
- else
+ else if (pll_data-pllod) {
+ postdiv = readl(pll_data-pllod);
+ postdiv = ((postdiv pll_data-clkod_mask)
+ pll_data-clkod_shift) + 1;
+ } else
postdiv = pll_data-postdiv;
rate /= (prediv + 1);
@@ -172,12 +178,21 @@ static void __init _of_pll_clk_init(struct device_node
*node, bool pllctrl)
/* assume the PLL has output divider register bits */
pll_data-clkod_mask = CLKOD_MASK;
pll_data-clkod_shift = CLKOD_SHIFT;
+
+ /*
+* Check if there is an post-divider register. If not
+* assume od bits are part of control register.
+*/
+ i = of_property_match_string(node, reg-names,
+post-divider);
+ pll_data-pllod = of_iomap(node, i);
}
i = of_property_match_string(node, reg-names, control);
pll_data-pll_ctl0 = of_iomap(node, i);
if (!pll_data-pll_ctl0) {
pr_err(%s: ioremap failed\n, __func__);
+ iounmap(pll_data-pllod);
goto out;
}
@@ -193,6 +208,7 @@ static void __init _of_pll_clk_init(struct device_node
*node, bool pllctrl)
pll_data-pllm = of_iomap(node, i);
if (!pll_data-pllm) {
iounmap(pll_data-pll_ctl0);
+ iounmap(pll_data-pllod);
goto out;
}
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: dts: keystone: fix dt bindings to use post div register for mainpll
All of the keystone devices have a separate register to hold post
divider value for main pll clock. Currently the fixed-postdiv
value used for k2hk/l/e SoCs works by sheer luck as u-boot happens to
use a value of 2 for this. Now that we have fixed this in the pll
clock driver change the dt bindings for the same.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
arch/arm/boot/dts/k2e-clocks.dtsi | 5 ++---
arch/arm/boot/dts/k2hk-clocks.dtsi | 5 ++---
arch/arm/boot/dts/k2l-clocks.dtsi | 5 ++---
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/k2e-clocks.dtsi
b/arch/arm/boot/dts/k2e-clocks.dtsi
index 4773d6a..d56d68f 100644
--- a/arch/arm/boot/dts/k2e-clocks.dtsi
+++ b/arch/arm/boot/dts/k2e-clocks.dtsi
@@ -13,9 +13,8 @@ clocks {
#clock-cells = 0;
compatible = ti,keystone,main-pll-clock;
clocks = refclksys;
- reg = 0x02620350 4, 0x02310110 4;
- reg-names = control, multiplier;
- fixed-postdiv = 2;
+ reg = 0x02620350 4, 0x02310110 4, 0x02310108 4;
+ reg-names = control, multiplier, post-divider;
};
papllclk: papllclk@2620358 {
diff --git a/arch/arm/boot/dts/k2hk-clocks.dtsi
b/arch/arm/boot/dts/k2hk-clocks.dtsi
index d5adee3..af9b719 100644
--- a/arch/arm/boot/dts/k2hk-clocks.dtsi
+++ b/arch/arm/boot/dts/k2hk-clocks.dtsi
@@ -22,9 +22,8 @@ clocks {
#clock-cells = 0;
compatible = ti,keystone,main-pll-clock;
clocks = refclksys;
- reg = 0x02620350 4, 0x02310110 4;
- reg-names = control, multiplier;
- fixed-postdiv = 2;
+ reg = 0x02620350 4, 0x02310110 4, 0x02310108 4;
+ reg-names = control, multiplier, post-divider;
};
papllclk: papllclk@2620358 {
diff --git a/arch/arm/boot/dts/k2l-clocks.dtsi
b/arch/arm/boot/dts/k2l-clocks.dtsi
index eb1e3e2..ef8464b 100644
--- a/arch/arm/boot/dts/k2l-clocks.dtsi
+++ b/arch/arm/boot/dts/k2l-clocks.dtsi
@@ -22,9 +22,8 @@ clocks {
#clock-cells = 0;
compatible = ti,keystone,main-pll-clock;
clocks = refclksys;
- reg = 0x02620350 4, 0x02310110 4;
- reg-names = control, multiplier;
- fixed-postdiv = 2;
+ reg = 0x02620350 4, 0x02310110 4, 0x02310108 4;
+ reg-names = control, multiplier, post-divider;
};
papllclk: papllclk@2620358 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zpool: add EXPORT_SYMBOL for functions
On Fri, May 29, 2015 at 12:30 PM, Christoph Hellwig h...@infradead.org wrote: On Fri, May 29, 2015 at 11:36:05AM -0400, Dan Streetman wrote: because they are available for public use, per zpool.h? If, e.g., zram ever started using zpool, it would need them exported, wouldn't it? If you want to use it in ram export it in the same series as those changes, and explain what the exprots are for in your message body. I don't want to use it in zram. I wrote zpool, but neglected to export the functions. They should be exported though. What's your reasoning for not wanting them exported? -- 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] staging: me_daq: use schedule_timeout_interruptible()
On 29/05/15 16:58, Nicholas Mc Guire wrote:
API consolidation with coccinelle found:
./drivers/staging/comedi/drivers/me_daq.c:177:1-17:
consolidation with schedule_timeout_*() recommended
This is a 1:1 conversion of the current calls to an available helper
only - so only an API consolidation to improve readability.
Patch was compile tested with x86_64_defconfig + CONFIG_STAGING=y,
CONFIG_COMEDI=y, CONFIG_COMEDI_PCI_DRIVERS=y CONFIG_COMEDI_ME_DAQ=m
Patch is against 4.1-rc5 (localversion-next is -next-20150529)
Minor niggle: you don't really need to say what version the patch is
against in the commit message, as the version will have changed by the
time the patch is committed. It can be mentioned after the --- marker
line if relevant, as the stuff after the --- line does not end up in
the commit message.
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
drivers/staging/comedi/drivers/me_daq.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/me_daq.c
b/drivers/staging/comedi/drivers/me_daq.c
index d78e919..9ea1ba4 100644
--- a/drivers/staging/comedi/drivers/me_daq.c
+++ b/drivers/staging/comedi/drivers/me_daq.c
@@ -173,8 +173,7 @@ struct me_private_data {
static inline void sleep(unsigned sec)
{
- __set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(sec * HZ);
+ schedule_timeout_interruptible(sec * HZ);
}
static int me_dio_insn_config(struct comedi_device *dev,
The patch itself looks fine!
Reviewed-by: Ian Abbott abbo...@mev.co.uk
--
-=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk )=-
-=( Web: http://www.mev.co.uk/ )=-
--
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 V1 0/3] x86 Local Machine Check Exception (LMCE)
Historically machine checks on Intel X86 processors have been broadcast to all logical processors in the system. Upcoming CPUs will support an opt-in mechanism to request some machine checks delivered to a single logical processor experiencing the fault. For more details see Vol3, Chapter 15, Machine Check Architecture. Ashok Raj (3): x86, mce: Add LMCE definitions. x86, mce: Add infrastructure required to support LMCE x86, mce: Handling LMCE events Documentation/x86/x86_64/boot-options.txt | 3 ++ arch/x86/include/asm/mce.h| 10 arch/x86/include/uapi/asm/msr-index.h | 2 + arch/x86/kernel/cpu/mcheck/mce.c | 28 ++-- arch/x86/kernel/cpu/mcheck/mce_intel.c| 76 +++ 5 files changed, 116 insertions(+), 3 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch V1 3/3] x86, mce: Handling LMCE events
This patch has handling changes to do_machine_check() to process MCE
signaled as local MCE. Typically only recoverable errors (SRAR) type
error will be Signaled as LMCE. But architecture does not restrict to
only those errors.
When errors are signaled as LMCE, there is no need for the MCE handler to
perform rendezvous with other logical processors unlike earlier processors
that would broadcast machine check errors.
See http://www.intel.com/sdm Volume 3, Chapter 15 for more information
on MSR's and documentation on Local MCE.
Signed-off-by: Ashok Raj ashok@intel.com
---
arch/x86/kernel/cpu/mcheck/mce.c | 25 ++---
arch/x86/kernel/cpu/mcheck/mce_intel.c | 1 +
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index d10aada..c130391 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1047,6 +1047,7 @@ void do_machine_check(struct pt_regs *regs, long
error_code)
char *msg = Unknown;
u64 recover_paddr = ~0ull;
int flags = MF_ACTION_REQUIRED;
+ int lmce = 0;
prev_state = ist_enter(regs);
@@ -1074,11 +1075,19 @@ void do_machine_check(struct pt_regs *regs, long
error_code)
kill_it = 1;
/*
+* Check if this MCE is signaled to only this logical processor
+*/
+ if (m.mcgstatus MCG_STATUS_LMCES)
+ lmce = 1;
+ /*
* Go through all the banks in exclusion of the other CPUs.
* This way we don't report duplicated events on shared banks
* because the first one to see it will clear it.
+* If this is a Local MCE, then no need to perform rendezvous.
*/
- order = mce_start(no_way_out);
+ if (!lmce)
+ order = mce_start(no_way_out);
+
for (i = 0; i cfg-banks; i++) {
__clear_bit(i, toclear);
if (!test_bit(i, valid_banks))
@@ -1155,8 +1164,18 @@ void do_machine_check(struct pt_regs *regs, long
error_code)
* Do most of the synchronization with other CPUs.
* When there's any problem use only local no_way_out state.
*/
- if (mce_end(order) 0)
- no_way_out = worst = MCE_PANIC_SEVERITY;
+ if (!lmce) {
+ if (mce_end(order) 0)
+ no_way_out = worst = MCE_PANIC_SEVERITY;
+ } else {
+ /*
+* Local MCE skipped calling mce_reign()
+* If we found a fatal error, we need to panic here.
+*/
+if (worst = MCE_PANIC_SEVERITY mca_cfg.tolerant 3)
+ mce_panic(Machine check from unknown source,
+ NULL, NULL);
+ }
/*
* At insane tolerant levels we take no action. Otherwise
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index be3a5c6..73a2844 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -484,4 +484,5 @@ void mce_intel_feature_init(struct cpuinfo_x86 *c)
{
intel_init_thermal(c);
intel_init_cmci();
+ intel_init_lmce();
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch V1 1/3] x86, mce: Add LMCE definitions.
Add required definitions to support Local Machine Check Exceptions. See http://www.intel.com/sdm Volume 3, System Programming Guide, chapter 15 for more information on MSR's and documentation on Local MCE. Signed-off-by: Ashok Raj ashok@intel.com --- arch/x86/include/asm/mce.h| 5 + arch/x86/include/uapi/asm/msr-index.h | 2 ++ 2 files changed, 7 insertions(+) diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h index 1f5a86d..677a408 100644 --- a/arch/x86/include/asm/mce.h +++ b/arch/x86/include/asm/mce.h @@ -17,11 +17,16 @@ #define MCG_EXT_CNT(c) (((c) MCG_EXT_CNT_MASK) MCG_EXT_CNT_SHIFT) #define MCG_SER_P (1ULL24) /* MCA recovery/new status bits */ #define MCG_ELOG_P (1ULL26) /* Extended error log supported */ +#define MCG_LMCE_P (1ULL27) /* Local machine check supported */ /* MCG_STATUS register defines */ #define MCG_STATUS_RIPV (1ULL0) /* restart ip valid */ #define MCG_STATUS_EIPV (1ULL1) /* ip points to correct instruction */ #define MCG_STATUS_MCIP (1ULL2) /* machine check in progress */ +#define MCG_STATUS_LMCES (1ULL3) /* LMCE signaled */ + +/* MCG_EXT_CTL register defines */ +#define MCG_EXT_CTL_LMCE_EN (1ULL0) /* Enable LMCE */ /* MCi_STATUS register defines */ #define MCI_STATUS_VAL (1ULL63) /* valid error */ diff --git a/arch/x86/include/uapi/asm/msr-index.h b/arch/x86/include/uapi/asm/msr-index.h index c469490..e28d5a2 100644 --- a/arch/x86/include/uapi/asm/msr-index.h +++ b/arch/x86/include/uapi/asm/msr-index.h @@ -56,6 +56,7 @@ #define MSR_IA32_MCG_CAP 0x0179 #define MSR_IA32_MCG_STATUS0x017a #define MSR_IA32_MCG_CTL 0x017b +#define MSR_IA32_MCG_EXT_CTL 0x04d0 #define MSR_OFFCORE_RSP_0 0x01a6 #define MSR_OFFCORE_RSP_1 0x01a7 @@ -379,6 +380,7 @@ #define FEATURE_CONTROL_LOCKED (10) #define FEATURE_CONTROL_VMXON_ENABLED_INSIDE_SMX (11) #define FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX (12) +#define FEATURE_CONTROL_LMCE_SUPPORT_ENABLED (120) #define MSR_IA32_APICBASE 0x001b #define MSR_IA32_APICBASE_BSP (18) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] percpu system call: fast userspace percpu critical sections
There are some interesting things one could do with a similar system at
the kernel level.
If we had a table of IP ranges in the kernel that specify critical
sections with the restart points defined then the kernel could consult
that when preempting kernel threads and set the IP to the
restart point if the IP happened to be in one of the ranges.
If we had something like that then per cpu atomic sections would become
much simpler (avoid the preempt accounting and other preempt overhead
there?) and the per cpu atomic instructions would also be easier to
generalize for various architectures. Solves a lot of issues introduced by
preempt logic.
I think this could lead to a further simplification of allocator
fastpaths. Gets rid of a lot of strange code. Look at the simplification
of the fastpath due to the ability to be able to guarantee that a section
of code is executed without preemption.
mm/slubc::slab_alloc_node()
redo:
do {
tid = this_cpu_read(s-cpu_slab-tid);
c = raw_cpu_ptr(s-cpu_slab);
} while (IS_ENABLED(CONFIG_PREEMPT)
unlikely(tid != READ_ONCE(c-tid)));
barrier();
object = c-freelist;
page = c-page;
if (unlikely(!object || !node_match(page, node))) {
... slow path...
} else {
void *next_object = get_freepointer_safe(s, object);
if (unlikely(!this_cpu_cmpxchg_double(
s-cpu_slab-freelist, s-cpu_slab-tid,
object, tid,
next_object, next_tid(tid {
note_cmpxchg_failure(slab_alloc, s, tid);
goto redo;
}
}
-
Using the restart point system
-
start_critical_section:
restart_point:
c = this_cpu_ptr(s-cpu_slab);
object = c-freelist;
page = c-page;
if (!unlikely(!object || !node_match(page, node)) {
... slow path ...
} else {
void *next_object = get_freepointer_safe(s, object);
end_critical_section:
c-freelist = next_object;
}
--
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] staging: panel: use schedule_timeout_interruptible()
API consolidation with coccinelle found:
./drivers/staging/panel/panel.c:782:2-18:
consolidation with schedule_timeout_*() recommended
This is a 1:1 conversion with respect to schedule_timeout() to the
schedule_timeout_interruptible() helper only - so only an API
consolidation to improve readability. The timeout was being passed
as (ms * HZ + 999) / 1000 but that simply looks wrong - rather than
manual converting to jiffies, msecs_to_jiffies which handles all
corner-cases correctly, was used.
Patch was compile tested with x86_64_defconfig + CONFIG_STAGING=y,
CONFIG_PARPORT=m, CONFIG_PANEL=m
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
Patch is against 4.1-rc5 (localversion-next is -next-20150529)
not really clear what the intent of (ms * HZ + 999) / 1000 was - this
is HZ dependent and does not really make sense - the comment states
sleeps that many milliseconds so it probably simply should be
msecs_to_jiffies(ms) - but someone that knows the intention of this code
needs to check this.
drivers/staging/panel/panel.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
index 0046ee0..d670494 100644
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -775,12 +775,10 @@ static void pin_to_bits(int pin, unsigned char *d_val,
unsigned char *c_val)
/* sleeps that many milliseconds with a reschedule */
static void long_sleep(int ms)
{
- if (in_interrupt()) {
+ if (in_interrupt())
mdelay(ms);
- } else {
- __set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout((ms * HZ + 999) / 1000);
- }
+ else
+ schedule_timeout_interruptible(msecs_to_jiffies(ms));
}
/* send a serial byte to the LCD panel. The caller is responsible for locking
--
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/2] staging: dgnc: switch timeout to signed type
On Fri, 29 May 2015, Dan Carpenter wrote: On Fri, May 29, 2015 at 06:41:28PM +0200, Nicholas Mc Guire wrote: The schedule_timeout*() helpers take the timeout as signed long, as ch_close_delay in struct channel_t was not used for other purposes its type was switched to signed long and the declarations fixed up. Uh, we never pass it to schedule_timeout etc and even if we did how would that matter? It's either 250 or 0. What is the bug you are trying to fix and we can help you? static code checkers being unhappy with type mismatch automatic type conversion is ok if necessary but in this case it simply is not as the ch_close_delay is only being used in this one place so why not do it type clean ? I'll turn the question around - what reason would there be to go through type conversion if it is not needed ? thx! hofrat -- 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/7] net: dsa: ar8xxx: add regmap support
Alternatively, we could have something similar to what happens for the phy in the wireless subsystems. Wireless PHYs are not registered as net_device but they can still be listed, queried or configured through netlink. Just thinking out loud here. Thanks, Mathieu -Original Message- From: Andrew Lunn [mailto:and...@lunn.ch] Sent: Thursday, May 28, 2015 7:44 PM To: Florian Fainelli Cc: Mathieu Olivari; robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; da...@davemloft.net; li...@roeck-us.net; gang.chen.5...@gmail.com; j...@resnulli.us; lei...@staticky.com; f...@skynet.be; pavel.nakonec...@skitlab.ru; j...@perches.com; sfel...@gmail.com; n...@openwrt.org; juh...@openwrt.org; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; net...@vger.kernel.org Subject: Re: [PATCH 3/7] net: dsa: ar8xxx: add regmap support Fair enough, are there other global things besides counters that could deserve adding maybe some sort of global/master net_device to help query switch-wide information? This was discussed a while back. I like the current abstraction, all interfaces are real interfaces you can send and receive packets over. This pseudo interface cannot be used for packet transfer, which seems odd. Having access to registers for debugging, so debugfs seems like the best option to me. Andrew -- 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: [3.19.y-ckt stable] Linux 3.19.8-ckt1
diff --git a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
index a4873e5..e30e184 100644
--- a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt
@@ -38,7 +38,7 @@ dma_apbx: dma-apbx@80024000 {
80 81 68 69
70 71 72 73
74 75 76 77;
- interrupt-names = auart4-rx, aurat4-tx, spdif-tx, empty,
+ interrupt-names = auart4-rx, auart4-tx, spdif-tx, empty,
saif0, saif1, i2c0, i2c1,
auart0-rx, auart0-tx, auart1-rx, auart1-tx,
auart2-rx, auart2-tx, auart3-rx, auart3-tx;
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 176d4fe..c7e8f40 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3717,6 +3717,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
READ_CAPACITY_16 command);
f = NO_REPORT_OPCODES (don't use report opcodes
command, uas only);
+ g = MAX_SECTORS_240 (don't transfer more than
+ 240 sectors at a time, uas only);
h = CAPACITY_HEURISTICS (decrease the
reported device capacity by one
sector if the number is odd);
diff --git a/Makefile b/Makefile
index 110782b..8723390b6 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
VERSION = 3
PATCHLEVEL = 19
SUBLEVEL = 8
-EXTRAVERSION =
-NAME = Diseased Newt
+EXTRAVERSION = -ckt1
+NAME = Sedated Swine
# *DOCUMENTATION*
# To see a list of typical targets execute make help
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..bcc2f95 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -336,7 +336,7 @@
compatible = microchip,mcp7941x;
reg = 0x6f;
interrupt-parent = gic;
- interrupts = GIC_SPI 2 IRQ_TYPE_LEVEL_LOW; /* IRQ_SYS_1N */
+ interrupts = GIC_SPI 2 IRQ_TYPE_EDGE_RISING; /* IRQ_SYS_1N */
pinctrl-names = default;
pinctrl-0 = mcp79410_pins_default;
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 6f6b091..101c1ec 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -71,6 +71,10 @@
};
internal-regs {
+ rtc@10300 {
+ /* No crystal connected to the internal RTC */
+ status = disabled;
+ };
serial@12000 {
status = okay;
};
diff --git a/arch/arm/boot/dts/imx23-olinuxino.dts
b/arch/arm/boot/dts/imx23-olinuxino.dts
index 7e6eef2..8204539 100644
--- a/arch/arm/boot/dts/imx23-olinuxino.dts
+++ b/arch/arm/boot/dts/imx23-olinuxino.dts
@@ -12,6 +12,7 @@
*/
/dts-v1/;
+#include dt-bindings/gpio/gpio.h
#include imx23.dtsi
/ {
@@ -93,6 +94,7 @@
ahb@8008 {
usb0: usb@8008 {
+ dr_mode = host;
vbus-supply = reg_usb0_vbus;
status = okay;
};
@@ -122,7 +124,7 @@
user {
label = green;
- gpios = gpio2 1 1;
+ gpios = gpio2 1 GPIO_ACTIVE_HIGH;
};
};
};
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index e4d3aec..677f81d 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -428,6 +428,7 @@
pwm4: pwm@53fc8000 {
compatible = fsl,imx25-pwm, fsl,imx27-pwm;
+ #pwm-cells = 2;
reg = 0x53fc8000 0x4000;
clocks = clks 108, clks 52;
clock-names = ipg, per;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 47f68ac..5ed245a 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -900,7 +900,7 @@
80 81 68 69
70 71 72 73
74 75 76 77;
- interrupt-names = auart4-rx, aurat4-tx,
spdif-tx, empty,
+ interrupt-names = auart4-rx, auart4-tx,
spdif-tx,
[PATCH 10/16] ARM: at91/dt: at91sam9rlek: use stdout-path
Use stdout-path to specify the console and remove the console argument from
the kernel command line.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/boot/dts/at91sam9rlek.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9rlek.dts
b/arch/arm/boot/dts/at91sam9rlek.dts
index 724b9f54a60a..558c9f220bed 100644
--- a/arch/arm/boot/dts/at91sam9rlek.dts
+++ b/arch/arm/boot/dts/at91sam9rlek.dts
@@ -13,7 +13,8 @@
compatible = atmel,at91sam9rlek, atmel,at91sam9rl, atmel,at91sam9;
chosen {
- bootargs = console=ttyS0,115200 rootfstype=ubifs
root=ubi0:rootfs ubi.mtd=5 rw;
+ bootargs = rootfstype=ubifs root=ubi0:rootfs ubi.mtd=5 rw;
+ stdout-path = serial0:115200n8;
};
memory {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/16] ARM: at91/dt: at91sam9x5ek: use stdout-path
Use stdout-path to specify the console and remove the console argument from
the kernel command line.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/boot/dts/at91sam9x5ek.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index cc83a37a7311..d237c462dfc6 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -13,7 +13,8 @@
compatible = atmel,at91sam9x5ek, atmel,at91sam9x5, atmel,at91sam9;
chosen {
- bootargs = console=ttyS0,115200 root=/dev/mtdblock1 rw
rootfstype=ubifs ubi.mtd=1 root=ubi0:rootfs;
+ bootargs = root=/dev/mtdblock1 rw rootfstype=ubifs ubi.mtd=1
root=ubi0:rootfs;
+ stdout-path = serial0:115200n8;
};
ahb {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/16] ARM: at91/dt: at91sam9m10g45ek use stdout-path
Use stdout-path to specify the console and remove the console argument from
the kernel command line.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/boot/dts/at91sam9m10g45ek.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 33ce7ca2c404..1375d3362603 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -15,7 +15,8 @@
compatible = atmel,at91sam9m10g45ek, atmel,at91sam9g45,
atmel,at91sam9;
chosen {
- bootargs = mem=64M console=ttyS0,115200 root=/dev/mtdblock1 rw
rootfstype=jffs2;
+ bootargs = mem=64M root=/dev/mtdblock1 rw rootfstype=jffs2;
+ stdout-path = serial0:115200n8;
};
memory {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/16] ARM: at91/dt: sama5d3 xplained: use stdout-path
Use stdout-path to specify the console and remove the bootargs.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index 4799e88cdf5e..d81474e0bcd6 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -14,7 +14,7 @@
compatible = atmel,sama5d3-xplained, atmel,sama5d3, atmel,sama5;
chosen {
- bootargs = console=ttyS0,115200;
+ stdout-path = serial0:115200n8;
};
memory {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Uses of Linux backports in the industry
On Fri, May 29, 2015 at 10:36 AM, Theodore Ts'o ty...@mit.edu wrote: On Fri, May 29, 2015 at 05:01:00PM +0200, Richard Weinberger wrote: On Fri, May 29, 2015 at 4:53 PM, Enrico Weigelt, metux IT consult weig...@melag.de wrote: Am 29.05.2015 um 04:54 schrieb Luis R. Rodriguez: Just to clarify the original goal was to hear how folks use the Linux backports project out there in the industry for purposes of the paper being edited, hearing how folks might do their own backports is certainly useful but I am also in hopes they might consider using Linux backports for future work to help, well automatically backport Linux. Actually, I really wonder why folks are sticking to ancient kernels on newer hardware. Enterprise distribution kernels. Or special kernels like PREEMPT_RT. Sometimes the vendor BSP is that horrid that a customer cannot afford to forward port it but wants recent stuff. So you need to backport... Yep. The technique I used for the backporting ext4 encryption into the 3.10 android-common git tree in AOSP was to drop in the 3.18 versions of fs/ext4 and fs/jbd2 into the 3.10 tree (along with the associaed include files in include/linux and include/trace/events, of course), and then fix things up until they built correctly (using cherry-picks and in some cases, reverting some changes in the 3.18 version of fs/ext4). After I was sure the transplant of the 3.18 version of ext4 had taken correctly, with no test regressions, only then did I cherry-pick all of the ext4 encryption changes on top of 3.10. FWIW, if the Linux backports project started carrying ext4 into it, you'd likely have less work to do and we'd enable use of ext4 to be used on the range of supported kernels. The backport of ext4 encryption to the 3.18 version of android-common should be much easier. :-) Unfortunately, I also have to do a backport to the 3.14 android-common branch as well. sigh Yes, it's ugly, but there still are some SOC and drivers that aren't available on newer kernels. Basically, the handset vendors need to lean a lot harder on the SOC and other peripheral (cell radios, GPS, etc., etc.). :-( Yeah we dealt with a lot of those dependencies when backporting the regulator subsystem for Media drivers, it was hard but hey we did quite a bit of the work. Now that we have in-kernel integration support the options on what to backport should be easier [1]. [1] https://backports.wiki.kernel.org/index.php/Documentation/integration Luis -- 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 5/6] Watchdog: introduce ARM SBSA watchdog driver
Hi Timur On 29 May 2015 at 23:46, Timur Tabi ti...@codeaurora.org wrote: On 05/29/2015 09:32 AM, Fu Wei wrote: It is a SPI, every CPU can get it, But maybe I miss something, but please let me know if other CPU can not get the interrupt. There's only one watchdog device, so there's only one interrupt. I don't know which CPU will get the interrupt, but the watchdog is not a per-CPU device. OK, first of all, I know, there maybe only watchdog in the system, but the Interrupter is SPI, that means maybe some other device can also trigger the same Interrupter or maybe(in SMP) other CPU will handle it. If this interrupter is triggered, that means system has goes wrong, who knows what is wrong , I have to make sure that system get into that routine ,because of the WS0, if not I won't do panic. And in a interrupter routine , checking the Interrupter status register is right way to do. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- 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/2] f2fs: fix a deadlock for summary page lock vs. sentry_lock
In f2fs_gc: In f2fs_replace_block:
- lock_page(sum_page)
- check_valid_map()- mutex_lock(sentry_lock)
- mutex_lock(sentry_lock) - change_curseg()
- lock_page(sum_page)
This patch fixes the deadlock condition.
Signed-off-by: Jaegeuk Kim jaeg...@kernel.org
---
fs/f2fs/gc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 43354cb..e1e7361 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -750,6 +750,15 @@ static void do_garbage_collect(struct f2fs_sb_info *sbi,
unsigned int segno,
sum = page_address(sum_page);
+ /*
+* this is to avoid deadlock:
+* - lock_page(sum_page) - f2fs_replace_block
+* - check_valid_map()- mutex_lock(sentry_lock)
+* - mutex_lock(sentry_lock) - change_curseg()
+* - lock_page(sum_page)
+*/
+ unlock_page(sum_page);
+
switch (GET_SUM_TYPE((sum-footer))) {
case SUM_TYPE_NODE:
gc_node_segment(sbi, sum-entries, segno, gc_type);
@@ -763,7 +772,7 @@ static void do_garbage_collect(struct f2fs_sb_info *sbi,
unsigned int segno,
stat_inc_seg_count(sbi, GET_SUM_TYPE((sum-footer)), gc_type);
stat_inc_call_count(sbi-stat_info);
- f2fs_put_page(sum_page, 1);
+ f2fs_put_page(sum_page, 0);
}
int f2fs_gc(struct f2fs_sb_info *sbi)
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] f2fs crypto: clean up error handling in f2fs_fname_setup_filename
Sync with:
ext4 crypto: clean up error handling in ext4_fname_setup_filename
Signed-off-by: Jaegeuk Kim jaeg...@kernel.org
---
fs/f2fs/crypto_fname.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/fs/f2fs/crypto_fname.c b/fs/f2fs/crypto_fname.c
index 81852cc..ab377d4 100644
--- a/fs/f2fs/crypto_fname.c
+++ b/fs/f2fs/crypto_fname.c
@@ -392,15 +392,13 @@ int f2fs_fname_setup_filename(struct inode *dir, const
struct qstr *iname,
return ret;
ret = f2fs_fname_encrypt(dir, iname, fname-crypto_buf);
if (ret 0)
- goto out;
+ goto errout;
fname-disk_name.name = fname-crypto_buf.name;
fname-disk_name.len = fname-crypto_buf.len;
return 0;
}
- if (!lookup) {
- ret = -EACCES;
- goto out;
- }
+ if (!lookup)
+ return -EACCES;
/* We don't have the key and we are doing a lookup; decode the
* user-supplied name
@@ -408,19 +406,17 @@ int f2fs_fname_setup_filename(struct inode *dir, const
struct qstr *iname,
if (iname-name[0] == '_')
bigname = 1;
if ((bigname (iname-len != 33)) ||
- (!bigname (iname-len 43))) {
- ret = -ENOENT;
- }
+ (!bigname (iname-len 43)))
+ return -ENOENT;
+
fname-crypto_buf.name = kmalloc(32, GFP_KERNEL);
- if (fname-crypto_buf.name == NULL) {
- ret = -ENOMEM;
- goto out;
- }
+ if (fname-crypto_buf.name == NULL)
+ return -ENOMEM;
ret = digest_decode(iname-name + bigname, iname-len - bigname,
fname-crypto_buf.name);
if (ret 0) {
ret = -ENOENT;
- goto out;
+ goto errout;
}
fname-crypto_buf.len = ret;
if (bigname) {
@@ -430,7 +426,7 @@ int f2fs_fname_setup_filename(struct inode *dir, const
struct qstr *iname,
fname-disk_name.len = fname-crypto_buf.len;
}
return 0;
-out:
+errout:
f2fs_fname_crypto_free_buffer(fname-crypto_buf);
return ret;
}
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
* Tony Lindgren t...@atomide.com [150529 08:52]: * Matthijs van Duin matthijsvand...@gmail.com [150528 18:37]: On 29 May 2015 at 02:58, Matthijs van Duin matthijsvand...@gmail.com wrote: It is only guaranteed to happen immediately (before the next instruction is executed) if the error occurs before the posting-point of the write. However, in that case the error is reported in-band to the cpu, resulting in a (synchronous) bus error which takes precedence over the out-of-band error irq (if any is signalled). OK, all this was actually assuming linux uses device-type mappings for device mappings, which was also the impression I got from build_mem_type_table() in arch/arm/mm/mmu.c (although it's a bit of a maze). A quick test however seems to imply otherwise: ~# ./bogus-dev-write Bus error So... linux actually uses strongly-ordered mappings? I really didn't expect that, given the performance implications (especially on a strictly in-order cpu like the Cortex-A8 which will really just sit there picking its nose until the write completes) and I think I recall having seen an OCP barrier being used somewhere in driver code... I believe some TI kernels use strongly-ordered mappings, mainline kernel does not. Which kernel version are you using? Well, in that case everything I said is technically still true, except the posting point is the peripheral itself. That also means the interconnect error reporting mechanism is not really useful for probing since you'll get a bus error before any error irq is delivered. Hmm if that's the case then yes we can't use the error irq. However, what I've seen so far is that we only get the bus error if the l3_* drivers are configured. I guess some more testing is needed. So I'd say you're back at having to trap that bus error using the exception handling mechanism, which I still suspect shouldn't be hard to do. And in that case it makes sense to do that in the bootloader to avoid adding any custom early boot code to Linux kernel. Or perhaps you could probe the device using a DMA access and combine that with the interconnect error reporting irq... ;-) Heh too many dependencies :) If we can't use the l3 interrrupts, then something similar to commit fdf4850cb5b2 (ARM: BCM5301X: workaround suppress fault) might be doable too. Regards, Tony -- 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 v10 12/12] drivers/block/pmem: Map NVDIMM with ioremap_wt()
On Fri, May 29, 2015 at 8:03 AM, Toshi Kani toshi.k...@hp.com wrote: On Fri, 2015-05-29 at 07:43 -0700, Dan Williams wrote: On Fri, May 29, 2015 at 2:11 AM, Borislav Petkov b...@alien8.de wrote: On Wed, May 27, 2015 at 09:19:04AM -0600, Toshi Kani wrote: The pmem driver maps NVDIMM with ioremap_nocache() as we cannot write back the contents of the CPU caches in case of a crash. This patch changes to use ioremap_wt(), which provides uncached writes but cached reads, for improving read performance. Signed-off-by: Toshi Kani toshi.k...@hp.com --- drivers/block/pmem.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c index eabf4a8..095dfaa 100644 --- a/drivers/block/pmem.c +++ b/drivers/block/pmem.c @@ -139,11 +139,11 @@ static struct pmem_device *pmem_alloc(struct device *dev, struct resource *res) } /* - * Map the memory as non-cachable, as we can't write back the contents + * Map the memory as write-through, as we can't write back the contents * of the CPU caches in case of a crash. */ err = -ENOMEM; - pmem-virt_addr = ioremap_nocache(pmem-phys_addr, pmem-size); + pmem-virt_addr = ioremap_wt(pmem-phys_addr, pmem-size); if (!pmem-virt_addr) goto out_release_region; Dan, Ross, what about this one? ACK to pick it up as a temporary solution? I see that is_new_memtype_allowed() is updated to disallow some combinations, but the manual seems to imply any mixing of memory types is unsupported. Which worries me even in the current code where we have uncached mappings in the driver, and potentially cached DAX mappings handed out to userspace. is_new_memtype_allowed() is not to allow some combinations of mixing of memory types. When it is allowed, the requested type of ioremap_xxx() is changed to match with the existing map type, so that mixing of memory types does not happen. Yes, but now if the caller was expecting one memory type and gets another one that is something I think the driver would want to know. At a minimum I don't think we want to get emails about pmem driver performance problems when someone's platform is silently degrading WB to UC for example. DAX uses vm_insert_mixed(), which does not even check the existing map type to the physical address. Right, I think that's a problem... A general quibble separate from this patch is that we don't have a way of knowing if ioremap() will reject or change our requested memory type. Shouldn't the driver be explicitly requesting a known valid type in advance? I agree we need a solution here. Lastly we now have the PMEM API patches from Ross out for review where he is assuming cached mappings with non-temporal writes: https://lists.01.org/pipermail/linux-nvdimm/2015-May/000929.html. This gives us WC semantics on writes which I believe has the nice property of reducing the number of write transactions to memory. Also, the numbers in the paper seem to be assuming DAX operation, but this ioremap_wt() is in the driver and typically behind a file system. Are the numbers relevant to that usage mode? I have not looked into the Ross's changes yet, but they do not seem to replace the use of ioremap_nocache(). If his changes can use WB type reliably, yes, we do not need a temporary solution of using ioremap_wt() in this driver. Hmm, yes you're right, it seems those patches did not change the implementation to use ioremap_cache()... which happens to not be implemented on all architectures. I'll take a look. -- 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: [GIT PULL 00/14] perf/core improvements and fixes
* Arnaldo Carvalho de Melo a...@kernel.org wrote:
Hi Ingo,
Please consider applying,
- Arnaldo
The following changes since commit f1942b96b4b44c1ab0e0b82fef93ba7e1fada7af:
Merge tag 'perf-core-for-mingo' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
(2015-05-28 11:09:22 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-core-for-mingo
for you to fetch changes up to ed426915900db3c58c410b8b38f6ff0e46bf6c96:
perf tools: Make Ctrl-C stop processing on TUI (2015-05-29 12:49:00 -0300)
perf/core improvements and fixes:
User visible:
- Make Ctrl-C stop processing on TUI, allowing interrupting the load of big
perf.data files (Namhyung Kim)
- Fix 'perf annotate' -i option, which is currently ignored (Martin Liška)
- Add ARM64 perf_regs_load to support libunwind and enable testing (Wang Nan)
Infrastructure:
- Fix thread ref-counting in db-export (Adrian Hunter)
- Fix compiler warning about may be accessing uninitialized (Arnaldo Carvalho
de Melo)
- No need to have two lists for user and kernel DSOs, unify them (Arnaldo
Carvalho de Melo)
- Function namespace consistency fixups (Arnaldo Carvalho de Melo)
- Do not fail on missing Build file, fixing the build on MIPS (Jiri Olsa)
- Fix up syscall tests, making those tests pass on ARM64 (Riku Voipio)
- Fix 'function unused' warning in 'perf probe' (Wang Nan)
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
Adrian Hunter (1):
perf db-export: Fix thread ref-counting
Arnaldo Carvalho de Melo (5):
perf kmem: Fix compiler warning about may be accessing uninitialized
variable
perf machine: Adopt findnew_kernel method
perf machine: No need to have two DSOs lists
perf machine: Introduce machine__findnew_dso() method
perf machine: Fix up vdso methods names
Jiri Olsa (1):
perf build: Do not fail on missing Build file
Martin Liška (1):
perf annotate: Fix -i option, which is currently ignored.
Namhyung Kim (1):
perf tools: Make Ctrl-C stop processing on TUI
Riku Voipio (3):
perf tests: Switch from open to openat
perf tests: Aename open*.c to openat*.c
perf tests: Remove getpgrp from mmap-basic
Wang Nan (2):
perf probe: Fix 'function unused' warning
perf tools: Add ARM64 perf_regs_load to support libunwind and enable
testing
tools/build/Makefile.build | 2 +-
tools/build/tests/ex/Build | 1 +
tools/build/tests/ex/empty2/README | 2 +
tools/perf/arch/arm64/Build| 1 +
tools/perf/arch/arm64/include/perf_regs.h | 3 +
tools/perf/arch/arm64/tests/Build | 2 +
tools/perf/arch/arm64/tests/dwarf-unwind.c | 61
tools/perf/arch/arm64/tests/regs_load.S| 46 +++
tools/perf/builtin-annotate.c | 3 +-
tools/perf/builtin-kmem.c | 2 +-
tools/perf/tests/Build | 8 +--
tools/perf/tests/builtin-test.c| 14 ++---
tools/perf/tests/hists_common.c| 3 +-
tools/perf/tests/mmap-basic.c | 6 +-
...yscall-all-cpus.c = openat-syscall-all-cpus.c} | 12 ++--
...call-tp-fields.c = openat-syscall-tp-fields.c} | 6 +-
.../tests/{open-syscall.c = openat-syscall.c} | 14 ++---
tools/perf/tests/parse-events.c| 12 ++--
tools/perf/tests/tests.h | 8 +--
tools/perf/ui/browsers/annotate.c | 4 ++
tools/perf/ui/browsers/hists.c | 4 ++
tools/perf/ui/tui/setup.c | 2 +-
tools/perf/util/build-id.c | 59 ++-
tools/perf/util/db-export.c| 19 ---
tools/perf/util/dso.c | 6 +-
tools/perf/util/dso.h | 4 +-
tools/perf/util/header.c | 6 +-
tools/perf/util/machine.c | 46 ---
tools/perf/util/machine.h | 5 +-
tools/perf/util/map.c | 4 +-
tools/perf/util/probe-event.c | 66
+++---
tools/perf/util/symbol-elf.c | 6 +-
tools/perf/util/vdso.c | 24
tools/perf/util/vdso.h | 4 +-
34 files changed, 277 insertions(+), 188 deletions(-)
create mode 100644 tools/build/tests/ex/empty2/README
create mode 100644 tools/perf/arch/arm64/tests/Build
create mode 100644
Re: [PATCH 3/6] edac, mce_amd_inj: Modify flags attrigute to use string arguments
On 5/29/2015 8:49 AM, Borislav Petkov wrote:
On Wed, May 27, 2015 at 02:03:35PM -0500, Aravind Gopalakrishnan wrote:
+#define MAX_FLAG_OPT_SIZE 10
Why 10?
No specific reason. Just an arbitrary max value that we won't hit right
now or in the future.
This should be 2 and increased when another, longer injection type
string gets introduced.
Okay, I'll make it 2 here and will increase it to 3 in the next patch
when I introduce injection types for the interrupts.
- *val = m-inject_flags;
+ for (i = 0; i = N_INJ_TYPES; i++) {
+ inj_op = flags_options[i];
+ if (inj_op strncmp(inj_op, buf, cnt) == 0)
+ break;
+ }
What's wrong with:
for (i = 0; i N_INJ_TYPES; i++) {
if (!strncmp(flags_options[i], buf, strlen(flags_options[i]))) {
inj_type = i;
return 0;
}
}
return -EINVAL;
Hmm. That should work. Will simplify it in the next version.
I think I had a NULL in flags_options[] to denote the invalid option.
With your simplification, that can be removed. I'll make that change too.
And the 'cnt' value that I used won't be necessary. So, will remove that
from __set_inj() definition as well.
+static ssize_t flags_write(struct file *filp, const char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+ char buf[MAX_FLAG_OPT_SIZE + 1];
+ int err;
+ size_t ret;
+
+ ret = cnt;
You're assigning cnt to ret here...
+
+ if (cnt MAX_FLAG_OPT_SIZE)
+ cnt = MAX_FLAG_OPT_SIZE;
... but correcting cnt afterwards. The assignment should be *after* that
correction.
With the change to MAX_FLAG_OPT_SIZE to 2 (or 3 depending on the max
size), this check is
really an error check.
Shall I make err = -EINVAL by default and return that here if the
condition is not satisfied?
Thanks,
-Aravind.
--
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 v10 2/4] PCI: X-Gene: Add the APM X-Gene v1 PCIe MSI/MSIX termination driver
APM X-Gene v1 SoC supports its own implementation of MSI, which is
not compliant to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
This MSI block supports 2048 MSI termination ports coalesced into 16
physical HW IRQ lines and shared across all 5 PCIe ports.
As there are only 16 HW IRQs to serve 2048 MSI vectors, to support
set_affinity correctly for each MSI vectors, the 16 HW IRQs are statically
allocated to 8 X-Gene v1 cores (2 HW IRQs for each cores). To steer MSI
interrupt to target CPU, MSI vector is moved around these HW IRQs lines.
With this approach, the total MSI vectors this driver supports is reduced
to 256.
Signed-off-by: Duc Dang dhd...@apm.com
Signed-off-by: Tanmay Inamdar tinam...@apm.com
Reviewed-by: Marc Zyngier marc.zyng...@arm.com
---
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile| 1 +
drivers/pci/host/pci-xgene-msi.c | 595 +++
drivers/pci/host/pci-xgene.c | 21 ++
4 files changed, 627 insertions(+)
create mode 100644 drivers/pci/host/pci-xgene-msi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 1dfb567..a93fda8 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -89,11 +89,21 @@ config PCI_XGENE
depends on ARCH_XGENE
depends on OF
select PCIEPORTBUS
+ select PCI_MSI_IRQ_DOMAIN if PCI_MSI
help
Say Y here if you want internal PCI support on APM X-Gene SoC.
There are 5 internal PCIe ports available. Each port is GEN3 capable
and have varied lanes from x1 to x8.
+config PCI_XGENE_MSI
+ bool X-Gene v1 PCIe MSI feature
+ depends on PCI_XGENE PCI_MSI
+ default y
+ help
+ Say Y here if you want PCIE MSI support for APM X-Gene v1 SoC.
+ This MSI driver will provide MSI support for 5 PCIe ports of
+ APM X-Gene v1 SoC
+
config PCI_LAYERSCAPE
bool Freescale Layerscape PCIe controller
depends on OF ARM
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index f733b4e..1957431 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
+obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
new file mode 100644
index 000..378f272
--- /dev/null
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -0,0 +1,595 @@
+/*
+ * APM X-Gene MSI Driver
+ *
+ * Copyright (c) 2014, Applied Micro Circuits Corporation
+ * Author: Tanmay Inamdar tinam...@apm.com
+ *Duc Dang dhd...@apm.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include linux/cpu.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/msi.h
+#include linux/of_irq.h
+#include linux/irqchip/chained_irq.h
+#include linux/pci.h
+#include linux/platform_device.h
+#include linux/of_pci.h
+
+#define MSI_IR00x00
+#define MSI_INT0 0x80
+#define IDX_PER_GROUP 8
+#define IRQS_PER_IDX 16
+#define NR_HW_IRQS 16
+#define NR_MSI_VEC (IDX_PER_GROUP * IRQS_PER_IDX * NR_HW_IRQS)
+
+struct xgene_msi_group {
+ struct xgene_msi*msi;
+ int gic_irq;
+ u32 msi_grp;
+};
+
+struct xgene_msi {
+ struct device_node *node;
+ struct msi_controller mchip;
+ struct irq_domain *domain;
+ u64 msi_addr;
+ void __iomem*msi_regs;
+ unsigned long *bitmap;
+ struct mutexbitmap_lock;
+ struct xgene_msi_group *msi_groups;
+ int num_cpus;
+};
+
+/* Global data */
+static struct xgene_msi xgene_msi_ctrl;
+
+static struct irq_chip xgene_msi_top_irq_chip = {
+ .name = X-Gene1 MSI,
+ .irq_enable = pci_msi_unmask_irq,
+ .irq_disable= pci_msi_mask_irq,
+ .irq_mask = pci_msi_mask_irq,
+
[PATCH v10 3/4] arm64: dts: Add the device tree entry for the APM X-Gene PCIe MSI node
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
Signed-off-by: Duc Dang dhd...@apm.com
Signed-off-by: Tanmay Inamdar tinam...@apm.com
Reviewed-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm64/boot/dts/apm/apm-storm.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index c8d3e0e..d8f3a1c 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -374,6 +374,28 @@
};
};
+ msi: msi@7900 {
+ compatible = apm,xgene1-msi;
+ msi-controller;
+ reg = 0x00 0x7900 0x0 0x90;
+ interrupts = 0x0 0x10 0x4
+ 0x0 0x11 0x4
+ 0x0 0x12 0x4
+ 0x0 0x13 0x4
+ 0x0 0x14 0x4
+ 0x0 0x15 0x4
+ 0x0 0x16 0x4
+ 0x0 0x17 0x4
+ 0x0 0x18 0x4
+ 0x0 0x19 0x4
+ 0x0 0x1a 0x4
+ 0x0 0x1b 0x4
+ 0x0 0x1c 0x4
+ 0x0 0x1d 0x4
+ 0x0 0x1e 0x4
+ 0x0 0x1f 0x4;
+ };
+
pcie0: pcie@1f2b {
status = disabled;
device_type = pci;
@@ -395,6 +417,7 @@
0x0 0x0 0x0 0x4 gic 0x0 0xc5 0x1;
dma-coherent;
clocks = pcie0clk 0;
+ msi-parent = msi;
};
pcie1: pcie@1f2c {
@@ -418,6 +441,7 @@
0x0 0x0 0x0 0x4 gic 0x0 0xcb 0x1;
dma-coherent;
clocks = pcie1clk 0;
+ msi-parent = msi;
};
pcie2: pcie@1f2d {
@@ -441,6 +465,7 @@
0x0 0x0 0x0 0x4 gic 0x0 0xd1 0x1;
dma-coherent;
clocks = pcie2clk 0;
+ msi-parent = msi;
};
pcie3: pcie@1f50 {
@@ -464,6 +489,7 @@
0x0 0x0 0x0 0x4 gic 0x0 0xd7 0x1;
dma-coherent;
clocks = pcie3clk 0;
+ msi-parent = msi;
};
pcie4: pcie@1f51 {
@@ -487,6 +513,7 @@
0x0 0x0 0x0 0x4 gic 0x0 0xdd 0x1;
dma-coherent;
clocks = pcie4clk 0;
+ msi-parent = msi;
};
serial0: serial@1c02 {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
