FIX ME in mc146818rtc.h
Hey Ralf and other Mips developers , I was wondering about the fix me in this file and how you want to fix this. Cheers Nick -- 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/
FIX ME in pgtable.h
There is a fix me message I am hitting with cscope on line 317 of this file about #define kern_addr_valid(addr) (1) not being correct. I am wondering what value this should be set to. Thanks for the advice so I can remove this fix me from the kernel. Cheers Nick -- 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: perf tools: Call graph from Intel BTS
On 11/07/2014 6:36 p.m., Peter Zijlstra wrote: On Fri, Jul 11, 2014 at 05:36:41PM +0300, Adrian Hunter wrote: Alexander Shishkin is working on the Intel PT driver for perf and has included a driver for Intel BTS. I have taken that and There is already a BTS driver, although I've not used it ever, since there's no useful tool for it. One way would be to use that, and migrate to PT data later. Currently that driver does not allow kernel tracing. Last time I tried it with that restriction removed, it would lose data on larger workloads. Generally, any loss of data ruins the call graph. For me it does not make sense to try to support it, since I am primarily trying to pave the way for the Intel PT driver. -- 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: perf tools: Call graph from Intel BTS
On 11/07/2014 6:18 p.m., Arnaldo Carvalho de Melo wrote: Em Fri, Jul 11, 2014 at 05:36:41PM +0300, Adrian Hunter escreveu: There are many perf tools patches and it would be helpful to start considering how to get them into mainline. Many need to wait for the driver, but others could be taken sooner. We can go on looking at each of the patches to see which ones can be cherry picked, i.e. the ones that are fixes and not related to the work you're doing, like: commit 244c87b15b124914827f3ce28d8e70c8d147c9d0 Author: Adrian Hunter Date: Wed Jun 11 09:33:17 2014 +0300 perf tools: Fix the value used for unknown pids The value used for unknown pids cannot be zero because that is used by the "idle" task. Use -1 instead. Also handle the unknown pid case when creating map groups. Note that, threads with an unknown pid should not occur because fork (or synthesized) events precede the thread's existence. Signed-off-by: Adrian Hunter But then one by one they need to be reviewed to check if the changes were made to the whole tools/perf/ tree and if perhaps something new came along since you changed some assumption, like 0 meaning unknown thread, in the above patch: [acme@ssdandy linux]$ find tools -name "*.[ch]" | xargs grep machine__findnew_thread | grep 0 tools/perf/util/session.c: thread = machine__findnew_thread(>machines.host, 0, 0); That's the idle thread. tools/perf/tests/thread-mg-share.c: leader = machine__findnew_thread(machine, 0, 0); tools/perf/tests/thread-mg-share.c: t1 = machine__findnew_thread(machine, 0, 1); tools/perf/tests/thread-mg-share.c: t2 = machine__findnew_thread(machine, 0, 2); tools/perf/tests/thread-mg-share.c: t3 = machine__findnew_thread(machine, 0, 3); Those are valid pids for that test. [acme@ssdandy linux]$ So I think that one way to reduce the size of that branch is to do just that: start fresh from tip/perf/core, and go cherry picking those patches, making sure that they take into account the whole current tools/perf/ tree, then ask for this patch to be pulled. You could then rebase the old branch on top of the resulting branch once it is merged upstream, rinse repeat. Sounds good, thanks! It is currently based on tip/perf/core from a few days ago, so the current patches should be mostly ok. I will make a selection and check them again. -- 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/
Sh Builds that are failing
Hey Andrew and other maintainers , There seem to be a few failing def config builds with the sh architecture. I will post the failing builds and the log of errors leading up to these builds. Cheers Nick Still failing Builds for sh 1. rsk7203_defconfig 2. se7206_defconfig 3. allmodconfig for sh 4. allyesconfig for sh rsk7203_defconfig Description: Binary data se7206_defconfig Description: Binary data allmodconfig Description: Binary data allyesconfig Description: Binary data
Re: [for-next][PATCH 04/21] ftrace: Optimize function graph to be called directly
On Fri, 11 Jul 2014 23:36:10 -0400 Steven Rostedt wrote: > I'll worked on getting arm to be called directly too. Can you test that > patch as well? I'll reply to this email with that one. Here's that patch: -- Steve >From ff9ee792640d802415eaedf0e8d41992c898d2a9 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Fri, 11 Jul 2014 23:28:11 -0400 Subject: [PATCH] ARM: ftrace: Allow function graph tracer to have its own trampoline The ftrace infrastructure now allows the function graph tracer trampoline to be called directly instead of having to first go through the function tracer trampoline. But in order for this to work, the function graph tracer must be dependent from the function tracer trampoline. Currently in ARM, the function graph tracer does not save registers as it depends on the function tracer trampoline to do so. By adding a ftrace_graph_tramp_caller function that saves the regs then does the function graph tracing work, this can be used as the trampoline for function graph tracing. Link: http://lkml.kernel.org/r/53bed155.9040...@nvidia.com Reported-by: Tuomas Tynkkynen Signed-off-by: Steven Rostedt --- arch/arm/include/asm/ftrace.h | 5 + arch/arm/kernel/entry-common.S | 7 +++ 2 files changed, 12 insertions(+) diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h index 39eb16b..6af3929 100644 --- a/arch/arm/include/asm/ftrace.h +++ b/arch/arm/include/asm/ftrace.h @@ -54,6 +54,11 @@ extern inline void *return_address(unsigned int level) #define ftrace_return_address(n) return_address(n) +#ifdef CONFIG_FUNCTION_GRAPH_TRACER +extern void ftrace_graph_tramp_caller(void); +#define FTRACE_GRAPH_TRAMP_ADDR ((unsigned long)ftrace_graph_tramp_caller) +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */ + #endif /* ifndef __ASSEMBLY__ */ #endif /* _ASM_ARM_FTRACE */ diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S index 7139d4a..0199167 100644 --- a/arch/arm/kernel/entry-common.S +++ b/arch/arm/kernel/entry-common.S @@ -314,6 +314,13 @@ ENDPROC(ftrace_caller) #endif #ifdef CONFIG_FUNCTION_GRAPH_TRACER +ENTRY(ftrace_graph_tramp_caller) +UNWIND(.fnstart) + mcount_enter + __ftrace_graph_caller +UNWIND(.fnend) +ENDPROC(ftrace_graph_tramp_caller) + ENTRY(ftrace_graph_caller) UNWIND(.fnstart) __ftrace_graph_caller -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [for-next][PATCH 04/21] ftrace: Optimize function graph to be called directly
On Thu, 10 Jul 2014 20:45:57 +0300 Tuomas Tynkkynen wrote: > > > > This commit (79922b8) breaks the function graph tracer on today's -next. > This is on an ARM Tegra board. Can you test this patch. It makes the default operation of calling the function graph tracer trampoline directly being disabled. It is now up to the arch to define FTRACE_GRAPH_TRAMP_ADDR that can be used to call directly. If it is not set, the old method of calling the function tracer first is used. I'll worked on getting arm to be called directly too. Can you test that patch as well? I'll reply to this email with that one. Thanks! -- Steve >From 641e0d82e5be65adac6449f62d68d83012b780d9 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Fri, 11 Jul 2014 14:39:10 -0400 Subject: [PATCH] ftrace: Allow archs to specify if they need a separate function graph trampoline Currently if an arch supports function graph tracing, the core code will just assign the function graph trampoline to the function graph addr that gets called. But as the old method for function graph tracing always calls the function trampoline first and that calls the function graph trampoline, some archs may have the function graph trampoline dependent on operations that were done in the function trampoline. This causes function graph tracer to break on those archs. Instead of having the default be to set the function graph ftrace_ops to the function graph trampoline, have it instead just set it to zero which will keep it from jumping to a trampoline that is not set up to be jumped directly too. Link: http://lkml.kernel.org/r/53bed155.9040...@nvidia.com Reported-by: Tuomas Tynkkynen Signed-off-by: Steven Rostedt --- include/linux/ftrace.h | 10 ++ kernel/trace/ftrace.c | 6 -- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h index 11e18fd..4807a39 100644 --- a/include/linux/ftrace.h +++ b/include/linux/ftrace.h @@ -453,6 +453,16 @@ void ftrace_modify_all_code(int command); #endif #endif +/* + * If an arch would like functions that are only traced + * by the function graph tracer to jump directly to its own + * trampoline, then they can define FTRACE_GRAPH_TRAMP_ADDR + * to be that address to jump to. + */ +#ifndef FTRACE_GRAPH_TRAMP_ADDR +#define FTRACE_GRAPH_TRAMP_ADDR ((unsigned long) 0) +#endif + #ifdef CONFIG_FUNCTION_GRAPH_TRACER extern void ftrace_graph_caller(void); extern int ftrace_enable_ftrace_graph_caller(void); diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 45aac1a..c52d37d 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -5366,7 +5366,8 @@ int register_ftrace_graph(trace_func_graph_ret_t retfunc, #ifdef CONFIG_DYNAMIC_FTRACE /* Optimize function graph calling (if implemented by arch) */ - global_ops.trampoline = FTRACE_GRAPH_ADDR; + if (FTRACE_GRAPH_TRAMP_ADDR) + global_ops.trampoline = FTRACE_GRAPH_TRAMP_ADDR; #endif ret = ftrace_startup(_ops, FTRACE_START_FUNC_RET); @@ -5390,7 +5391,8 @@ void unregister_ftrace_graph(void) ftrace_shutdown(_ops, FTRACE_STOP_FUNC_RET); global_ops.flags &= ~FTRACE_OPS_FL_STUB; #ifdef CONFIG_DYNAMIC_FTRACE - global_ops.trampoline = 0; + if (FTRACE_GRAPH_TRAMP_ADDR) + global_ops.trampoline = 0; #endif unregister_pm_notifier(_suspend_notifier); unregister_trace_sched_switch(ftrace_graph_probe_sched_switch, NULL); -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: mpt2sas stuck installing
> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Joe Lawrence ... > In your crash stack trace, the scsi error handler has issued a host > reset, but then crashed in mpt2sas_base_get_iocstate. Reading through > _scsih_shutdown, I don't believe that the mpt2sas .shutdown path takes > any precaution before heading down mpt2sas_base_detach to free adapter > resources. The ordinary .remove path looks similar, though it does > call sas_remove_host before freeing resources, *then* scsi_remove_host > and scsi_host_put. > > I wonder if this ordering needs to be reversed (and added to > _scsih_shutdown) to properly de-register from the SCSI midlayer prior > to removing the controller instance. > > Regards, > > -- Joe Nagalakshmi was working on an mpt3sas patch for the scsi-mq tree to do just that. I don't recall if the patch has made it into the scsi-mq tree yet. Apparently it's also needed for non-mq and mpt2sas. It is making this change: > sas_remove_host(shost); > + scsi_remove_host(shost); > mpt3sas_base_detach(ioc); > list_del(>list); > - scsi_remove_host(shost); > scsi_host_put(shost); We are making a similar change in hpsa. Doing so led to a general protection fault, which unveiled that we also needed to change cancel_delayed_work() calls to cancel_delayed_work_sync() to ensure there are no worker functions still active after the scsi_host structure is unregistered. -- 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: Fwd: Fwd: Allyesconfig for powerpc still Failing
>> > Guenter Roeck wrote on Mon, Jul 7, 2014 at 11:07 PM >> > I submitted a patch to work around this problem a couple of weeks ago [1]. >> > Unfortunately, with this patch applied, allyesconfig still fails with >> > relocation errors, but at least the above message is gone, and >> > allmodconfig passes. >> > >> > Maybe we can convince Ben to accept the patch ... >> > >> > Thanks, >> > Guenter >> > >> > --- >> > [1] https://lkml.org/lkml/2014/6/30/607 >> > >> > Hey Guenter, >> > Would you mind sending me the patch that fixes these errors. >> > I would like to test it before sending in to Ben. >> > Cheers Nick >> > >> >> Hi Nick, >> >> Just follow the link above, select 'forward', and follow the directions. >> You'll get the patch per e-mail. >> >> Alternative: >> >> wget "http://download.gmane.org/gmane.linux.kernel/1736036/1736037; >> >> The patch will be in a file named '1736037'. >> >> I copied the list for others, in case the 'how to download a patch' >> question comes up again. >> >> Guenter >> >> Guenter, >> Your patch works for me in building the powerpc allyesconfig. >> This is one news, I am going to send this patch to Ben. >> Cheers Nick >> -- >> 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/ > > Powerpc allyesconfig seems to be succeeding as of me pulling upstream today. On the other hand I get one randconfig build to succeed and the second fails. I will attach my log of the failing build. Cheers Nick randconfig2 Description: Binary data
Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 07/10/2014 11:19 PM, Viresh Kumar wrote: Please make sure you take care of these issues: - suspend/resume - hotplug - module insert/remove Ok, I was just at the current code. Does cpufreq_unregister_driver() even really work correctly as it stands? It doesn't even seem to stop any of the governors/policies before it just set the cpufreq_driver pointer to NULL. So, technically my v2 patch doesn't even make anything worse when it comes to unregistering the cpufreq driver. Similar issues for unregister_governor too! -Saravana -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Friday, July 11, 2014 5:54 AM > To: h...@infradead.org > Cc: James Bottomley; KY Srinivasan; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; a...@canonical.com; sta...@vger.kernel.org; > linux-s...@vger.kernel.org; oher...@suse.com; jasow...@redhat.com > Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16 > > > "hch" == hch@infradead org writes: > > (Back from vacation: Bear with me while I'm catching up on two weeks of > linux-scsi stuff...) > > hch> I think the problem is a differnet one. If we have the logical > hch> provisioning EVPD it configures what method to use, but if we don't > hch> have one we simply check for a max unmap blocks field, and if > hch> that's not present use WRITE SAME. > > Yeah, that was done to accommodate the devices out there that predate the > LBP VPD. There sadly are several still. And it's hard to motivate people to > update their storage array firmware even when updates are readily available. > > hch> The patch checks the no_write_same flag before doing that, for > hch> which we also have to do the write_same setup before the discard > hch> setup in sd_revalidate_disk. > > The no_write_same was introduced to disable the REQ_WRITE_SAME use > case where we have no INQUIRY/READ CAPACITY/VPD flags to key off of to > determine whether it is safe to send the commands. > > no_write_same does not preclude the REQ_DISCARD variants of > WRITE_SAME. Those are gated by the discard heuristics exclusively. > > So first of all I'd like to know whether it's a WRITE SAME(16) or a WRITE > SAME(16) with the UNMAP bit set that's coming down. > > hch> Ky: does hyperv support UNMAP? If so any idea why it doesn't set > hch> the maximum unmap block count field in the EVPD? > > We shouldn't be sending down WRITE SAME(16) with the UNMAP bit set > unless the device sets LBPME=1 in the READ CAPACITY(16) response. > > So what does the storsvc report as its thin provisioning capabilities? Given that our current Host (ws2012 r2) advertises SPC-2 compliance, Linux does not even query this page. We support UNMAP. We just prototyped a host where we advertised SPC-3 compliance and Linux queries the EVPD page and does not use WRITE_SAME_16 K. Y -- 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/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
> -Original Message-
> From: h...@infradead.org [mailto:h...@infradead.org]
> Sent: Thursday, July 10, 2014 11:32 PM
> To: James Bottomley
> Cc: KY Srinivasan; linux-kernel@vger.kernel.org; m...@mkp.net;
> h...@infradead.org; de...@linuxdriverproject.org; a...@canonical.com;
> sta...@vger.kernel.org; linux-s...@vger.kernel.org; oher...@suse.com;
> jasow...@redhat.com
> Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16
>
> On Wed, Jul 09, 2014 at 10:27:24PM +, James Bottomley wrote:
> > If we fix it at source, why would there be any need to filter? That's
> > the reason the no_write_same flag was introduced. If we can find and
> > fix the bug, it can go back into the stable trees as a bug fix, hence
> > nothing should ever emit write_same(10 or 16) and additional driver
> > code is redundant (and counter productive, since if this ever breaks
> > again you're our best canary).
> >
> > This looks like it might be the problem but Martin should confirm (I
> > think the problem comes to us from the RC16 code which unconditionally
> > sets WS16).
>
> I think the problem is a differnet one. If we have the logical provisioning
> EVPD it configures what method to use, but if we don't have one we simply
> check for a max unmap blocks field, and if that's not present use WRITE
> SAME.
>
> The patch checks the no_write_same flag before doing that, for which we
> also have to do the write_same setup before the discard setup in
> sd_revalidate_disk.
>
> Ky: does hyperv support UNMAP? If so any idea why it doesn't set the
> maximum unmap block count field in the EVPD?
Windows hosts do support UNMAP and set the field in the EVPD. However, since
the host
advertises SPC-2 compliance, Linux does not even query the VPD page.
>
> If we want to enable UNMAP in this case I'd prefer a blacklist entry than
> trying UNMAP despite the device not advertising it.
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index ba756b1..fbccfd2
> 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -2614,9 +2614,10 @@ static void sd_read_block_limits(struct scsi_disk
> *sdkp)
>
> if (sdkp->max_unmap_blocks)
> sd_config_discard(sdkp, SD_LBP_UNMAP);
> - else
> + else if (!sdkp->device->no_write_same)
> sd_config_discard(sdkp, SD_LBP_WS16);
> -
> + else
> + sd_config_discard(sdkp, SD_LBP_DISABLE);
> } else {/* LBP VPD page tells us what to use */
>
> if (sdkp->lbpu && sdkp->max_unmap_blocks) @@ -
> 2766,6 +2767,7 @@ static int sd_revalidate_disk(struct gendisk *disk)
>*/
> if (sdkp->media_present) {
> sd_read_capacity(sdkp, buffer);
> + sd_read_write_same(sdkp, buffer);
>
> if (sd_try_extended_inquiry(sdp)) {
> sd_read_block_provisioning(sdkp);
> @@ -2776,7 +2778,6 @@ static int sd_revalidate_disk(struct gendisk *disk)
> sd_read_write_protect_flag(sdkp, buffer);
> sd_read_cache_type(sdkp, buffer);
> sd_read_app_tag_own(sdkp, buffer);
> - sd_read_write_same(sdkp, buffer);
> }
>
> sdkp->first_scan = 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: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 07/11/2014 03:52 AM, Viresh Kumar wrote:
Just responding to one comment. The one about policy->cpu.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
static int cpufreq_add_dev_symlink(struct cpufreq_policy *policy)
{
- unsigned int j;
+ unsigned int j, first_cpu = cpumask_first(policy->related_cpus);
int ret = 0;
- for_each_cpu(j, policy->cpus) {
+ for_each_cpu(j, policy->related_cpus) {
struct device *cpu_dev;
- if (j == policy->cpu)
+ if (j == first_cpu)
why?
The first CPU is a cluster always own the real nodes.
What I meant was, why not use policy->cpu?
+static int cpufreq_add_dev_interface(struct cpufreq_policy *policy)
{
struct freq_attr **drv_attr;
+ struct device *dev;
int ret = 0;
+ dev = get_cpu_device(cpumask_first(policy->related_cpus));
+ if (!dev)
+ return -EINVAL;
+
Why?
I'm just always adding the real nodes to the first CPU in a cluster
independent of which CPU gets added first. Makes it easier to know which
ones to symlink. See comment next to policy->cpu for full context.
Yeah, and that is the order in which CPUs will boot and cpufreq_add_dev()
will be called. So, isn't policy->cpu the right CPU always?
No, the "first" cpu in a cluster doesn't need to be the first one to be
added. An example is 2x2 cluster system where the system is booted with
max cpus = 2 and then cpu3 could be onlined first by userspace.
- if (has_target()) {
+ cpus = cpumask_weight(policy->cpus);
+ policy->cpu = cpumask_first(policy->cpus);
why update it at all? Also, as per your logic what if cpus == 0?
Yeah, I didn't write it this way at first. But the governors are making
the assumption that policy->cpu is always an online CPU. So, they try to
Are you sure? I had a quick look and failed to see that..
queue work there and use data structs of that CPU (even if they free it in
the STOP event since it went offline).
So, it queues work on all policy->cpus, not policy->cpu.
And the data structures
are just allocated with a CPU number, its fine if its offline.
And where are we freeing that stuff in STOP ?
Sorry if I am really really tired and couldn't read it correctly.
Yeah, it is pretty convolution. But pretty much anywhere in the gov code
where policy->cpu is used could cause this. The specific crash I hit was
in this code:
static void od_dbs_timer(struct work_struct *work)
{
struct od_cpu_dbs_info_s *dbs_info =
container_of(work, struct od_cpu_dbs_info_s, cdbs.work.work);
unsigned int cpu = dbs_info->cdbs.cur_policy->cpu;
=== CPU is policy->cpu here.
struct od_cpu_dbs_info_s *core_dbs_info = _cpu(od_cpu_dbs_info,
cpu);
=== Picks the per CPU struct of an offline CPU
mutex_lock(_dbs_info->cdbs.timer_mutex);
=== Dies trying to lock a destroyed mutex
Another option is to leave policy->cpu unchanged and then fix all the
governors. But this patch would get even more complicated. So, we can
leave this as is, or fix that up in a separate patch.
Since we are simplifying it here, I think we should NOT change policy->cpu
at all. It will make life simple (probably).
I agree, but then I would have to fix up the governors. In the interest
of keeping this patch small. I'll continue with what I'm doing and fix
it up in another patch.
-Saravana
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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] serial: imx: Fix build breakage
On 07/11/14 19:16, Greg Kroah-Hartman wrote: > On Fri, Jul 11, 2014 at 07:00:48PM -0700, Randy Dunlap wrote: >> On 07/11/14 17:42, Greg Kroah-Hartman wrote: >>> On Thu, Jul 10, 2014 at 10:36:46PM -0400, Peter Hurley wrote: Fix breakage introduced by commit c557d392fbf5badd693ea1946a4317c87a26a716, 'serial: Test for no tx data on tx restart'. Signed-off-by: Peter Hurley >>> >>> You forgot a "Reported-by:" tag. >>> >>> I'll go add it... >> >> It's not clear to me that Peter forgot it. > > Why? Stephen pointed out the problem, in a public place, so I gave him > credit for it. SubmittingPatches does not give you permission to do that, but Stephen just did so. -- ~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] reformat_with_checkpatch: Add automation to checkpatch
On Fri, Jul 11, 2014 at 06:40:16PM -0700, Joe Perches wrote: > On Fri, 2014-07-11 at 18:34 -0700, Greg KH wrote: > > On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote: > > > A simple script to run checkpatch --fix for various types of > > > of cleanups. > > > > > > This script is useful primarily for staging. > > > > > > This reformats code to a more CodingStyle conforming style, > > > compiles it, verifies that the object code hasn't changed, > > > and git commits it too. > > > > And 'git commits' it? > > The thought I had was to made it easier to > submit "my first kernel patch" correctly. > like that tuxradar article you wrote a few > years ago. > > http://www.tuxradar.com/content/newbies-guide-hacking-linux-kernel Yeah, but it's good for people to actually understand the change they are making, and edit it themselves. Or at least I think so, but I know others don't, so I don't mind this script. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86_64,signal: Remove 'fs' and 'gs' from sigcontext
Our current handling of fs/vs is really weird. The best may very well be to explicitly save and restore both fs and he as part of Andi's patchset to support wrxsbase. On July 11, 2014 7:21:54 PM PDT, Linus Torvalds wrote: >On Fri, Jul 11, 2014 at 9:29 AM, Andy Lutomirski >wrote: >> As far as I can tell, these fields have been set to zero on save and >> ignored on restore since Linux was imported into git. Rename them >> '__pad1' and '__pad2' to avoid confusion and to allow them to be >> recycled some day. > >Shouldn't we actually try to save/restore gs/fs properly? Admittedly, >changing them in the signal handler would be insane, but still.. See >our context switching code with the whole segment selector vs base >save/restore code. Hmm? > >Linus -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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] x86_64,signal: Remove 'fs' and 'gs' from sigcontext
On Fri, Jul 11, 2014 at 9:29 AM, Andy Lutomirski wrote: > As far as I can tell, these fields have been set to zero on save and > ignored on restore since Linux was imported into git. Rename them > '__pad1' and '__pad2' to avoid confusion and to allow them to be > recycled some day. Shouldn't we actually try to save/restore gs/fs properly? Admittedly, changing them in the signal handler would be insane, but still.. See our context switching code with the whole segment selector vs base save/restore code. Hmm? Linus -- 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] checkpatch: Remove unnecessary + after {8,8}
On Fri, Jul 11, 2014 at 07:09:30PM -0700, Joe Perches wrote: > There's a useless "+" use that needs to be removed as perl 5.20 > emits a "Useless use of greediness modifier '+'" message each > time it's hit. > > Reported-by: Greg KH > Signed-off-by: Joe Perches > --- > On Fri, 2014-07-11 at 19:05 -0700, Greg KH wrote: > > Ok, with linux-next I get the same thing: > > Thanks Greg. Very nice, thanks for this: Tested-by: Greg Kroah-Hartman -- 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] serial: imx: Fix build breakage
On Fri, Jul 11, 2014 at 07:00:48PM -0700, Randy Dunlap wrote: > On 07/11/14 17:42, Greg Kroah-Hartman wrote: > > On Thu, Jul 10, 2014 at 10:36:46PM -0400, Peter Hurley wrote: > >> Fix breakage introduced by > >> commit c557d392fbf5badd693ea1946a4317c87a26a716, > >> 'serial: Test for no tx data on tx restart'. > >> > >> Signed-off-by: Peter Hurley > > > > You forgot a "Reported-by:" tag. > > > > I'll go add it... > > It's not clear to me that Peter forgot it. Why? Stephen pointed out the problem, in a public place, so I gave him credit for it. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4] Add support for flag status register on Micron chips.
Hi Graham, On Tue, Apr 29, 2014 at 10:29:51AM -0500, Graham Moore wrote: > Some new Micron flash chips require reading the flag > status register to determine when operations have completed. > > Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also > require reading the status register before reading the flag status register. > > This patch adds support for the flag status register in the n25q512ax3 and > n25q00 > Micron QSPI flash chips. > > Signed-off-by: Graham Moore > --- > V4: > Do not set nor->wait_till_ready if driver has already set it. > V3: > Rebase to l2-mtd spinor branch. > V2: > Remove leading underscore in function names. > Remove type cast in dev_err call and use the proper format > specifier instead. Sorry for the delay... pushed to l2-mtd.git. Thanks! Brian -- 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] reformat_with_checkpatch: Add automation to checkpatch
On Fri, Jul 11, 2014 at 06:57:24PM -0700, Joe Perches wrote: > On Fri, 2014-07-11 at 18:53 -0700, Greg KH wrote: > > On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote: > > > A simple script to run checkpatch --fix for various types of > > > of cleanups. > [] > > Anyway, try running this script on > > drivers/staging/lustre/lnet/lnet/acceptor.c to see how this build fails. > > lustre doesn't use "normal" kernel makefiles. Well, it does, it just has a: subdir-ccflags-y := -I$(src)/include/ line in drivers/staging/lustre/Makefile that messes up making .o files in subdirectories. I'll go fix that include file mess up now to be able to remove that line so the the .o file building will work. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86_64,signal: Remove 'fs' and 'gs' from sigcontext
On 07/11/2014 11:39 AM, Andy Lutomirski wrote: > On Fri, Jul 11, 2014 at 11:12 AM, Andi Kleen wrote: >>> diff --git a/arch/x86/include/uapi/asm/sigcontext.h >>> b/arch/x86/include/uapi/asm/sigcontext.h >>> index 076b11f..df9908b 100644 >>> --- a/arch/x86/include/uapi/asm/sigcontext.h >>> +++ b/arch/x86/include/uapi/asm/sigcontext.h >> >> I don't think renaming fields in uapi/asm is acceptable. These >> are likely used by user programs and you'll break compiles. > > Hmm. That's a fair point. On the other hand, any user code that uses > these fields explicitly may already be broken, since the current names > of these fields rather strongly imply that they do something. > > Is there any clear policy on minor API breaks in the UAPI headers that > don't affect ABI? > There really isn't, and this *definitely* a boundary case: as you state, it is very likely that anyone currently using them are doing so incorrectly, but it does induce potential source-level breakage. Linus, do you have any guidance here? -hpa -- 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] serial: imx: Fix build breakage
Hi Randy, On Fri, 11 Jul 2014 19:00:48 -0700 Randy Dunlap wrote: > > It's not clear to me that Peter forgot it. > Someone else brought this up -- it seems to me that > Documentation/SubmittingPatches is a little too strong about needing > permission to use Reported-by: > > If this patch fixes a problem reported by somebody else, consider adding a > Reported-by: tag to credit the reporter for their contribution. Please > note that this tag should not be added without the reporter's permission, > especially if the problem was not reported in a public forum. That said, > if we diligently credit our bug reporters, they will, hopefully, be > inspired to help us again in the future. > > > Sure, if a problem was reported privately, then we need to have permission > to use Reported-by, but if it was reported in a public forum, that should be > implicit permission (IMHO). > > eh? Yes, indeed. Just to be clear, I hereby give my permission for the addition of Reported-by: tags with my email address for anything I report publically or privately. :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
[PATCH] checkpatch: Remove unnecessary + after {8,8}
There's a useless "+" use that needs to be removed as perl 5.20
emits a "Useless use of greediness modifier '+'" message each
time it's hit.
Reported-by: Greg KH
Signed-off-by: Joe Perches
---
On Fri, 2014-07-11 at 19:05 -0700, Greg KH wrote:
> Ok, with linux-next I get the same thing:
Thanks Greg.
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d5ac001..370a974 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2376,7 +2376,7 @@ sub process {
"please, no space before tabs\n" . $herevet) &&
$fix) {
while ($fixed[$fixlinenr] =~
- s/(^\+.*) {8,8}+\t/$1\t\t/) {}
+ s/(^\+.*) {8,8}\t/$1\t\t/) {}
while ($fixed[$fixlinenr] =~
s/(^\+.*) +\t/$1\t/) {}
}
--
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] Add support for flag status register on Micron chips.
Hi guys,
Sorry to revisit this way late, and sorry for not paying as much
attention initially. I'm prepped to merge v4, but some of the
conversation matches what I was just thinking.
On Mon, Apr 28, 2014 at 07:06:17AM +0200, Marek Vasut wrote:
> On Saturday, April 26, 2014 at 05:10:13 AM, Huang Shijie wrote:
> > On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote:
> > > > > > the drivers may fills this hook itself, so the code should like
> > > > > > this:
> > > > > >--
> > > > > >
> > > > > > if ((info->flags & USE_FSR) &&
> > > > > >
> > > > > > nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > > > > >
> > > > > > nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > > > >
> > > > > >--
> > > > >
> > > > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and
> > > > > the driver compete for a function pointer here ? I guess one should
> > > > > have precedence in some way then ... and also, they should be two
> > > > > different pointers, where the subsystem decides which to use.
> > > >
> > > > the subsystem do not decides which one to use, the driver decides which
> > > > one to use.
> > > >
> > > > If driver has its own @wait_till_ready , it means the driver knows the
> > > > feature, and has implemented it in its own @wait_till_ready.
> > > >
> > > > If the driver does not fill any wait_till_ready, it means the driver
> > > > will use the default @wait_till_ready. We can treat the
> > > > spi_nor_wait_till_fsr_ready as a default hook too.
> > >
> > > I see the driver overwriting a hook previously set by the subsystem. This
> >
> > not sure ;)
> >
> > The driver set the hooks before the subsystem set these hooks.
> >
> > If the driver has already set the @wait_till_ready hook before it calls
> > the spi_nor_scan, the subsystem will not set the hook anymore.
> >
> > Please see the spi_nor_check().
>
> Two things competing over the same pointer looks misdesigned to me. I will
> need
> to dig into this one more time ...
Yes, that is misdesigned. And looking at nand_base for examples is not
foolproof; it has quite a bit of legacy and workarounds. It'd be best to
get the design right for spi-nor.
The subsystem code should not require a function pointer for FSR vs.
non-FSR -- all devices should be able to use the same function. We just
need to stash some flash-ID-related data (i.e., a flags field) in the
spi_nor struct. On the plus side, we can avoid the code duplication
between spi_nor_wait_till_fsr_ready() and spi_nor_wait_till_ready().
I think the wait_till_ready pointer should be reserved for the driver,
as a hardware-specific "wait" function.
This still leaves the question of whether the SPI NOR core should assume
that any driver's 'wait_till_ready' function (if present) actually
implements all necessary waits (FSR vs. non-FSR, for instance). I'd
argue that's a maintenance burden, and that the subsystem should still
do a sanity check that the status register is correct. After all, that's
what the ->{read,write}_reg() functions are useful for. But perhaps
there is some performance argument for avoiding the (potentially
redundant) register checks?
Anyway, I've tested v4, and I plan to merge it soon. Patches can be sent
on top. (I may even cook up my own.)
Regards,
Brian
--
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] x86_64,signal: Remove 'fs' and 'gs' from sigcontext
On 07/11/2014 09:29 AM, Andy Lutomirski wrote:
> diff --git a/arch/x86/include/uapi/asm/sigcontext.h
> b/arch/x86/include/uapi/asm/sigcontext.h
> index 076b11f..df9908b 100644
> --- a/arch/x86/include/uapi/asm/sigcontext.h
> +++ b/arch/x86/include/uapi/asm/sigcontext.h
> @@ -177,8 +177,8 @@ struct sigcontext {
> __u64 rip;
> __u64 eflags; /* RFLAGS */
> __u16 cs;
> - __u16 gs;
> - __u16 fs;
> + __u16 __pad2; /* Was called gs, but was always zero. */
> + __u16 __pad1; /* Was called fs, but was always zero. */
> __u16 ss;
> __u64 err;
> __u64 trapno;
I'm just wondering if this is likely to cause compile error in existing
code. I guess worst case we can just revert this patch...
-hpa
--
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] reformat_with_checkpatch: Add automation to checkpatch
On Fri, Jul 11, 2014 at 07:01:14PM -0700, Greg KH wrote:
> On Fri, Jul 11, 2014 at 06:46:52PM -0700, Joe Perches wrote:
> > On Fri, 2014-07-11 at 18:39 -0700, Greg KH wrote:
> > > On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote:
> > > > A simple script to run checkpatch --fix for various types of
> > > > of cleanups.
> > ]
> > > drivers/staging/lustre/include/linux/lnet/api.h has no obvious style
> > > problems and is ready for submission.
> > > file: description:
> > > types:
> > > Useless use of greediness modifier '+' in regex; marked by <-- HERE in
> > > m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
> > []
> > > drivers/staging/lustre/include/linux/lnet/api.h has no obvious style
> > > problems and is ready for submission.
> > []
> > > Is that expected?
> >
> > No, I haven't seen that.
> >
> > Can you tell me what git tree you're working on?
>
> My staging-next branch of staging.git on git.kernel.org
>
> > Also, can you use the scripts/checkpatch from -next
> > tag next-20140711
>
> that will take a bit to checkout, I'll do that afterward.
>
> > My system has:
> >
> > $ perl --version
> >
> > This is perl 5, version 18, subversion 2 (v5.18.2) built for
> > i686-linux-gnu-thread-multi-64int
> > (with 41 registered patches, see perl -V for more detail)
>
> I think this started showing up for me for perl 5.20. Let me go
> checkout linux-next and see if that fixes anything or not...
Ok, with linux-next I get the same thing:
~/linux/tmp/linux-next $ ./scripts/checkpatch.pl -f --strict
drivers/staging/lustre/include/linux/lnet/api.h --types=c99_comments
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2358.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: C99_COMMENTS
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
--
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] serial: imx: Fix build breakage
On 07/11/14 17:42, Greg Kroah-Hartman wrote: > On Thu, Jul 10, 2014 at 10:36:46PM -0400, Peter Hurley wrote: >> Fix breakage introduced by >> commit c557d392fbf5badd693ea1946a4317c87a26a716, >> 'serial: Test for no tx data on tx restart'. >> >> Signed-off-by: Peter Hurley > > You forgot a "Reported-by:" tag. > > I'll go add it... It's not clear to me that Peter forgot it. Someone else brought this up -- it seems to me that Documentation/SubmittingPatches is a little too strong about needing permission to use Reported-by: If this patch fixes a problem reported by somebody else, consider adding a Reported-by: tag to credit the reporter for their contribution. Please note that this tag should not be added without the reporter's permission, especially if the problem was not reported in a public forum. That said, if we diligently credit our bug reporters, they will, hopefully, be inspired to help us again in the future. Sure, if a problem was reported privately, then we need to have permission to use Reported-by, but if it was reported in a public forum, that should be implicit permission (IMHO). eh? -- ~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] reformat_with_checkpatch: Add automation to checkpatch
On Fri, Jul 11, 2014 at 06:46:52PM -0700, Joe Perches wrote:
> On Fri, 2014-07-11 at 18:39 -0700, Greg KH wrote:
> > On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote:
> > > A simple script to run checkpatch --fix for various types of
> > > of cleanups.
> ]
> > drivers/staging/lustre/include/linux/lnet/api.h has no obvious style
> > problems and is ready for submission.
> > file: description:
> > types:
> > Useless use of greediness modifier '+' in regex; marked by <-- HERE in
> > m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
> []
> > drivers/staging/lustre/include/linux/lnet/api.h has no obvious style
> > problems and is ready for submission.
> []
> > Is that expected?
>
> No, I haven't seen that.
>
> Can you tell me what git tree you're working on?
My staging-next branch of staging.git on git.kernel.org
> Also, can you use the scripts/checkpatch from -next
> tag next-20140711
that will take a bit to checkout, I'll do that afterward.
> My system has:
>
> $ perl --version
>
> This is perl 5, version 18, subversion 2 (v5.18.2) built for
> i686-linux-gnu-thread-multi-64int
> (with 41 registered patches, see perl -V for more detail)
I think this started showing up for me for perl 5.20. Let me go
checkout linux-next and see if that fixes anything or not...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] pinctrl: Device tree bindings for Qualcomm pm8xxx gpio block
On 07/10/14 02:53, Linus Walleij wrote: > On Wed, Jul 9, 2014 at 11:18 PM, Bjorn Andersson wrote: >> On Wed, Jul 9, 2014 at 1:53 AM, Linus Walleij >> wrote: >>> On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson >>> wrote: >>> >>> +- function: >>> + Usage: optional >>> + Value type: >>> + Definition: Specify the alternative function to be configured for >>> the >>> + specified pins. Valid values are: >>> + "normal", >>> + "paired", >>> + "func1", >>> + "func2", >>> + "dtest1", >>> + "dtest2", >>> + "dtest3", >>> + "dtest4" >>> These are a bit ambigous, why doesn't the driver present functions that >>> are more specific than "func1", "func2"? Or "dtest1"? >> I agree, unfortunately I have only seen traces of the actual function matrix; >> for pm8xxx I have no documentation and for pm8x41 they are only listed as >> func[1-2] and dtest[1-4]. >> >> Maybe if someone at Qualcomm could release such a list we could provide a >> proper table instead. > I guess Stephen Boyd can help us. (?) Ok. "normal" is pretty much gpio mode, i.e. don't mux anything. "paired" is where we take the output of the gpio next to it and loop it back into this gpio (and vice versa). So gpio1 is paired with gpio2, gpio 3 is paired with gpio 4, etc. This allows us to make level translators by choosing different supply voltages for the paired gpios. "func1" and "func2" are used for muxing things internally. "dtest" is used to mux specific things out for testing purposes, not really used in any end-products but still useful while debugging. I can provide the function to pin mapping if necessary. There are lots of pmics. > +- bias-pull-up: + Usage: optional + Value type: (optional) + Definition: The specified pins should be configued as pull up. An + optional argument can be used to configure the strength. + Valid values are; as defined in + : + 1: 30uA (PM8XXX_GPIO_PULL_UP_30) + 2: 1.5uA(PM8XXX_GPIO_PULL_UP_1P5) + 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) + 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) >>> Hm, I don't know of the internal kernel API or so, but I'm thinking that >>> for the DT bindings, this definition should be generic in >>> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt >>> and put in SI units like uA. >> Totally agree with you; and this is already specified in pinctrl-binding.txt >> as >> being Ohm. >> >> So I first did a spin with the strength as a separate property, but as that >> because the only part that pinconf-generic didn't parse for me I merged it >> and >> wanted your comment on it. > Yeah. And thinking of it how can it be uA? It has to be Ohms... it's a > pull > up resistor thing after all. I suspect the uA value is just something like the > maximum current drawn through the pullup given a certain voltage? > >>> So I would prefer: >>> >>> bias-pull-up = <30>; >>> >> Yeah, but that's the easy one ;) >> >> How do you say 1.5 or 31.5 and how do you differ that from 1.5 + 30 boot? > It needs to be set using Ohms. > >>> for 30 uA. Maybe we want nA even? I'm uncertain about the proper granularity >>> here :-/ >>> >>> Magic enumerators 1,2,3,4 doesn't seem so good, that seems more like it's >>> trying to match the magic value that is to be poked into a register or >>> something like that. >> The stuff going into the hardware is a value 0-3 for pull up; so these values >> are "only" an enum with the additional benefit of saying "bias-pull-up;" >> results in 30uA pull up which is the most commonly used form (hence being >> optional). > What is the nominal voltage of these pins? GIven that you can figure > out the Ohms. And I suspect it to be something very close to N times > the resistance of a depleted transistor in this technology. I believe the nominal voltage changes depending on which supply you choose (power-source in this document). Basically the gpio can be connected to different regulators on the pmic so you can choose different voltages, i.e. 1.8V, 3.0V, 3.3V etc. Furthermore, some of the regulators you can choose have variable voltage, although it may not be variable enough to have much effect on this. So it would seem that the pull-up resistance would be directly affected by which power-source is chosen. Maybe we just shouldn't use the generic properties for this? BTW, I see that power-source has made a comeback. What are the units? Is that in mV? If it is I'm slightly concerned that we're not accurately describing the hardware in cases where the voltage can actually be different. And I worry about
Re: [PATCH] reformat_with_checkpatch: Add automation to checkpatch
On Fri, 2014-07-11 at 18:53 -0700, Greg KH wrote: > On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote: > > A simple script to run checkpatch --fix for various types of > > of cleanups. [] > Anyway, try running this script on > drivers/staging/lustre/lnet/lnet/acceptor.c to see how this build fails. lustre doesn't use "normal" kernel makefiles. I supposed that the entire staging/lustre/ path could be built for every change, but for most of staging, and nearly all of the rest of the kernel tree, using: make file.o works. I know there can be many enhancements to the reformat script, but I think a minimally acceptable version is a decent start. So, thanks for trying it out. And keep the complaints coming. cheers, Joe -- 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] reformat_with_checkpatch: Add automation to checkpatch
On Fri, 2014-07-11 at 18:43 -0700, Greg KH wrote: > On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote: > > A simple script to run checkpatch --fix for various types of > > of cleanups. [] > If I pick drivers/staging/lustre/include/linux/lnet/types.h, then I get: > > staging: lnet: checkpatch cleanup: whitespace neatening > > and no 'types.h' here, is that intentional? If so, why? Yes, it's how it's written. It uses just the directory name, not any basename($file) It can be changed if that's what's desired. > And this is fun, I'm going to let this rip on the lustre code... It doesn't autocommit, it does show the various changes it makes and asks you to accept them. I suppose that could be automated with something better than "yes", but I didn't want it to be completely automatic. -- 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] reformat_with_checkpatch: Add automation to checkpatch
On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote:
> A simple script to run checkpatch --fix for various types of
> of cleanups.
>
> This script is useful primarily for staging.
>
> This reformats code to a more CodingStyle conforming style,
> compiles it, verifies that the object code hasn't changed,
> and git commits it too.
>
> You must have the necessary development tools, git, and a
> recent git tree. Ideally use Greg KH's staging-next, which
> can be retrieved via these commands:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> git checkout staging-next
>
> To use this script try a sequence of commands like:
>
> cd
> git checkout -b
> make allyesconfig
> mkdir patches
> ./scripts/reformat_with_checkpatch.sh drivers/staging//*.[ch]
> git format-patch --cover-letter -o patches/ staging-next
> git send-email patches/
>
> Signed-off-by: Joe Perches
> ---
> scripts/reformat_with_checkpatch.sh | 141
>
> 1 file changed, 141 insertions(+)
> create mode 100755 scripts/reformat_with_checkpatch.sh
>
> diff --git a/scripts/reformat_with_checkpatch.sh
> b/scripts/reformat_with_checkpatch.sh
> new file mode 100755
> index 000..5415a8e
> --- /dev/null
> +++ b/scripts/reformat_with_checkpatch.sh
> @@ -0,0 +1,141 @@
> +#!/bin/bash
> +# (c) 2014, Joe Perches
> +#
> +# Automate checkpatch modifications and git commits to
> +# neaten code that doesn't conform to CodingStyle.
> +# Useful primarily for files in drivers/staging
> +#
> +# Licensed under the terms of the GNU GPL License version 2
> +
> +declare -ar whitespace_types=( \
> +
> 'whitespace_neatening:spacing,space_before_tab,pointer_location,trailing_whitespace,bracket_space'
>\
> +'remove_spaces_before_tabs:space_before_tab' \
> +'fix_label_positions:indented_label' \
> +'align_arguments_to_parenthesis:parenthesis_alignment' \
> +)
> +
> +declare -ar changecode_types=( \
> +
> 'fix_brace_positions:open_brace,braces,else_after_brace,while_after_brace'
>\
> +'fix_blank_lines:line_spacing' \
> +'use_standard_attributes:prefer_packed,prefer_aligned' \
> +'remove_unnecessary_externs:avoid_externs' \
> +'update_c90_comment_style:c99_comments' \
> +)
> +
> +checkpatch_update ()
> +{
> +file=$1
> +
> +desc=$(echo $2 | cut -f1 -d: | sed 's/_/ /g')
> +types=$(echo $2 | cut -f2- -d:)
> +
> +echo "file: <$file> description: <$desc> types:<$types>"
> +
> +./scripts/checkpatch.pl --file --fix-inplace --strict --types="$types"
> $file
> +
> +checkpatch_fixes=$file.diff
> +git diff --stat -p --exit-code $file > $checkpatch_fixes
> +if [ $? == 0 ] ; then
> + rm -f $checkpatch_fixes
> + return
> +fi
> +
> +basename=$(basename $file)
> +if [ "${basename##*.}" == "c" ] ; then
> +
> + git checkout $file
> + obj="$(echo $file | sed 's/\.c$/\.o/')"
> + if [ -e $obj ] ; then
> + rm -f $obj
> + fi
> +
> + echo "Compiling original version..."
> +
> + ${CROSS_COMPILE}make $obj
This fails for when a cflags option is set (like an include path). Now,
I could argue that having an include path override in a kernel Makefile
is a bug, but well, it's staging...
Anyway, try running this script on
drivers/staging/lustre/lnet/lnet/acceptor.c to see how this build fails.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reformat_with_checkpatch: Add automation to checkpatch
On Fri, 2014-07-11 at 18:39 -0700, Greg KH wrote:
> On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote:
> > A simple script to run checkpatch --fix for various types of
> > of cleanups.
]
> drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
> and is ready for submission.
> file: description: c90 comment style> types:
> Useless use of greediness modifier '+' in regex; marked by <-- HERE in
> m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
[]
> drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
> and is ready for submission.
[]
> Is that expected?
No, I haven't seen that.
Can you tell me what git tree you're working on?
Also, can you use the scripts/checkpatch from -next
tag next-20140711
My system has:
$ perl --version
This is perl 5, version 18, subversion 2 (v5.18.2) built for
i686-linux-gnu-thread-multi-64int
(with 41 registered patches, see perl -V for more detail)
Copyright 1987-2013, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
and using that:
$ ./scripts/checkpatch.pl -f --strict
drivers/staging/lustre/include/linux/lnet/api.h --types=c99_comments
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: C99_COMMENTS
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
--
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] reformat_with_checkpatch: Add automation to checkpatch
On Fri, 2014-07-11 at 18:34 -0700, Greg KH wrote: > On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote: > > A simple script to run checkpatch --fix for various types of > > of cleanups. > > > > This script is useful primarily for staging. > > > > This reformats code to a more CodingStyle conforming style, > > compiles it, verifies that the object code hasn't changed, > > and git commits it too. > > And 'git commits' it? The thought I had was to made it easier to submit "my first kernel patch" correctly. like that tuxradar article you wrote a few years ago. http://www.tuxradar.com/content/newbies-guide-hacking-linux-kernel > Heh, I should just run this myself to clean up > staging and beat everyone else to it... At least for the whitespace noise, you could but I hope it'll encourage a few more people to try kernel patching instead. > I know some people already have private versions of these things, might > as well make it public for all to abuse :) And I hope they can improve it too as it's just a brainless little script. -- 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 tip/core/rcu 11/17] rcu: Bind grace-period kthreads to non-NO_HZ_FULL CPUs
On Fri, Jul 11, 2014 at 10:45:05PM +0200, Frederic Weisbecker wrote: > On Fri, Jul 11, 2014 at 01:35:13PM -0700, Paul E. McKenney wrote: > > On Fri, Jul 11, 2014 at 09:11:15PM +0200, Frederic Weisbecker wrote: > > > On Fri, Jul 11, 2014 at 02:05:08PM -0500, Christoph Lameter wrote: > > > > On Fri, 11 Jul 2014, Frederic Weisbecker wrote: > > > > > > > > > > That would imply that all no-nohz processors are housekeeping? So > > > > > > all > > > > > > processors with a tick are housekeeping? > > > > > > > > > > Well, now that I think about it again, I would really like to keep > > > > > housekeeping > > > > > to CPU 0 when nohz_full= is passed. > > > > > > > > Yeah. > > > > > > > > > > Could we make that set configurable? Ideally I'd like to have the > > > > > > ability > > > > > > restrict the housekeeping to one processor. > > > > > > > > > > Ah, I'm curious about your usecase. But I think we can do that. And > > > > > we should. > > > > > > > > The use case is pretty straightforward because we are trying to keep as > > > > much OS noise as possible off most processors. Processor 0 is the > > > > sacrificial lamb that will be used for all OS processing and hopefully > > > > all > > > > high latency operations will occur there. Processors 1-X have a tick but > > > > we still try to keep latencies sane. And then there is X-Y where tick is > > > > off. > > > > > > Ok. I don't entirely get why you need 1-X but I can easily imagine some > > > non-latency-critical > > > stuff running there. > > > > > > Paul proposed "housekeeping=". If we ever go there, I'd rather vote for > > > "sacrifical_lamb=" > > > > Given Christoph's desire for only one housekeeping CPU, I guess the > > counting version makes the most sense, so that "housekeeping=N" designates > > the first N non-nohz CPUs in numerical order as housekeeping CPUs. > > If there are fewer than N non-nohz CPUs, you get a splat at boot time > > and your request is capped at the number of non-nohz CPUs. > > > > Seem reasonable? > > I wonder if it's wouldn't be rather reasonable to affine housekeeping to all > non-nohz-full CPUs > by default and then people who want finergrained housekeeping can affine > manually kthreads from userspace. > > That implies to bind without PF_NO_SETAFFINIT but that's easy enough to do. Works for me! Thanx, Paul -- 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] reformat_with_checkpatch: Add automation to checkpatch
On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote:
> A simple script to run checkpatch --fix for various types of
> of cleanups.
>
> This script is useful primarily for staging.
>
> This reformats code to a more CodingStyle conforming style,
> compiles it, verifies that the object code hasn't changed,
> and git commits it too.
>
> You must have the necessary development tools, git, and a
> recent git tree. Ideally use Greg KH's staging-next, which
> can be retrieved via these commands:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> git checkout staging-next
>
> To use this script try a sequence of commands like:
>
> cd
> git checkout -b
> make allyesconfig
> mkdir patches
> ./scripts/reformat_with_checkpatch.sh drivers/staging//*.[ch]
> git format-patch --cover-letter -o patches/ staging-next
> git send-email patches/
>
> Signed-off-by: Joe Perches
> ---
> scripts/reformat_with_checkpatch.sh | 141
>
> 1 file changed, 141 insertions(+)
> create mode 100755 scripts/reformat_with_checkpatch.sh
>
> diff --git a/scripts/reformat_with_checkpatch.sh
> b/scripts/reformat_with_checkpatch.sh
> new file mode 100755
> index 000..5415a8e
> --- /dev/null
> +++ b/scripts/reformat_with_checkpatch.sh
> @@ -0,0 +1,141 @@
> +#!/bin/bash
> +# (c) 2014, Joe Perches
> +#
> +# Automate checkpatch modifications and git commits to
> +# neaten code that doesn't conform to CodingStyle.
> +# Useful primarily for files in drivers/staging
> +#
> +# Licensed under the terms of the GNU GPL License version 2
> +
> +declare -ar whitespace_types=( \
> +
> 'whitespace_neatening:spacing,space_before_tab,pointer_location,trailing_whitespace,bracket_space'
>\
> +'remove_spaces_before_tabs:space_before_tab' \
> +'fix_label_positions:indented_label' \
> +'align_arguments_to_parenthesis:parenthesis_alignment' \
> +)
> +
> +declare -ar changecode_types=( \
> +
> 'fix_brace_positions:open_brace,braces,else_after_brace,while_after_brace'
>\
> +'fix_blank_lines:line_spacing' \
> +'use_standard_attributes:prefer_packed,prefer_aligned' \
> +'remove_unnecessary_externs:avoid_externs' \
> +'update_c90_comment_style:c99_comments' \
> +)
> +
> +checkpatch_update ()
> +{
> +file=$1
> +
> +desc=$(echo $2 | cut -f1 -d: | sed 's/_/ /g')
> +types=$(echo $2 | cut -f2- -d:)
> +
> +echo "file: <$file> description: <$desc> types:<$types>"
> +
> +./scripts/checkpatch.pl --file --fix-inplace --strict --types="$types"
> $file
> +
> +checkpatch_fixes=$file.diff
> +git diff --stat -p --exit-code $file > $checkpatch_fixes
> +if [ $? == 0 ] ; then
> + rm -f $checkpatch_fixes
> + return
> +fi
> +
> +basename=$(basename $file)
> +if [ "${basename##*.}" == "c" ] ; then
> +
> + git checkout $file
> + obj="$(echo $file | sed 's/\.c$/\.o/')"
> + if [ -e $obj ] ; then
> + rm -f $obj
> + fi
> +
> + echo "Compiling original version..."
> +
> + ${CROSS_COMPILE}make $obj
> +
> + ${CROSS_COMPILE}objdump -D $obj | \
> + sed "s/^[[:space:]]\+[0-9a-f]\+//" > $obj.old
> +
> + patch -p1 < $checkpatch_fixes
> +
> + echo "Compiling modified version..."
> +
> + ${CROSS_COMPILE}make $obj
> +
> + ${CROSS_COMPILE}objdump -D $obj | \
> + sed "s/^[[:space:]]\+[0-9a-f]\+//" > $obj.new
> +
> + echo "Comparing objects..."
> + diff -Nurd $obj.new $obj.old
> + if [ $? -ne 0 ] ; then
> + echo "Object differences exist! - Verify changes before commit!"
> + read -s -p "Press the 'enter' key to continue: "
> + else
> + echo "No object differences found"
> + fi
> + rm -f $obj.old
> + rm -f $obj.new
> +fi
> +
> +echo "running checkpatch on possible checkpatch fixes..."
> +
> +./scripts/checkpatch.pl --no-summary --no-signoff $checkpatch_fixes
> +rm -f $checkpatch_fixes
> +
> +echo "Verify checkpatch output and make any necessary changes"
> +echo "Edit '$file' if appropriate"
> +read -s -p "Press the 'enter' key to continue: "
> +
> +commit_log_file=$(mktemp git_commit.XX)
> +
> +if [ -e $commit_log_file ] ; then
> + rm -f $commit_log_file
> +fi
> +
> +if [[ $file =~ ^drivers/staging/ ]] ; then
> + echo -n "staging: " >> $commit_log_file
> +fi
> +echo "$(basename $(dirname $file)): checkpatch cleanup: $desc" >>
> $commit_log_file
If I pick drivers/staging/lustre/include/linux/lnet/types.h, then I get:
staging: lnet: checkpatch cleanup: whitespace neatening
and no 'types.h' here, is that intentional? If so, why?
And this is fun, I'm going to let this rip on the lustre code...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Re: [PATCH] reformat_with_checkpatch: Add automation to checkpatch
On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote:
> A simple script to run checkpatch --fix for various types of
> of cleanups.
>
> This script is useful primarily for staging.
>
> This reformats code to a more CodingStyle conforming style,
> compiles it, verifies that the object code hasn't changed,
> and git commits it too.
>
> You must have the necessary development tools, git, and a
> recent git tree. Ideally use Greg KH's staging-next, which
> can be retrieved via these commands:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> git checkout staging-next
>
> To use this script try a sequence of commands like:
>
> cd
> git checkout -b
> make allyesconfig
> mkdir patches
> ./scripts/reformat_with_checkpatch.sh drivers/staging//*.[ch]
> git format-patch --cover-letter -o patches/ staging-next
> git send-email patches/
>
> Signed-off-by: Joe Perches
> ---
> scripts/reformat_with_checkpatch.sh | 141
>
> 1 file changed, 141 insertions(+)
> create mode 100755 scripts/reformat_with_checkpatch.sh
No --help option?
How do I run this thing?
I ran it on a file that had no problems and got a mess, all I think due
to something odd in checkpatch itself right now:
$ ./scripts/checkpatch.pl --file
drivers/staging/lustre/include/linux/lnet/api.h
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 220 lines checked
What's with that 'Useless use..." error? perl 5.20 in use, is that the issue?
Anyway, running this script on the file gave me this:
$ ./reformat_with_checkpatch drivers/staging/lustre/include/linux/lnet/api.h
file: description:
types:
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: BRACKET_SPACE POINTER_LOCATION SPACE_BEFORE_TAB
SPACING TRAILING_WHITESPACE
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
file: description: types:
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: SPACE_BEFORE_TAB
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
file: description: types:
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: INDENTED_LABEL
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
file: description: types:
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: PARENTHESIS_ALIGNMENT
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
file: description: types:
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: BRACES ELSE_AFTER_BRACE OPEN_BRACE WHILE_AFTER_BRACE
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
file: description: types:
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: LINE_SPACING
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
file: description: types:
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: PREFER_ALIGNED PREFER_PACKED
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
file: description: types:
Useless use of greediness modifier '+' in regex; marked by <-- HERE in
m/(^\+.*) {8,8}+ <-- HERE \t/ at ./scripts/checkpatch.pl line 2217.
total: 0 errors, 0 warnings, 0 checks, 220 lines checked
NOTE: Used message types: AVOID_EXTERNS
drivers/staging/lustre/include/linux/lnet/api.h has no obvious style problems
and is ready for submission.
file: description: types:
Useless use of greediness modifier '+' in
Re: [PATCH 2/2] arch/x86/xen: Silence compiler warnings
. snip ..
> > > Please loot at arch/x86/xen/enlighten.c:xen_check_mwait() and
> > > arch/x86/xen/enlighten.c:xen_boot_params_init_edd() (probably
> > > there are more stuff like that around). As I can see this is fairly
> > > common solution and probably compiler cope with it quite well.
> > >
> >
> > Those are some examples of some rather bad examples.
>
> What is wrong with them?
#ifdef should not be in C files. It is making the code a bit of a mess.
>
> > The way that is preferred in the Linux code is to have the ifdef in headers.
> >
> > See
> > http://lxr.free-electrons.com/source/arch/x86/include/asm/xen/swiotlb-xen.h
> > Or
> > http://lxr.free-electrons.com/source/arch/x86/include/asm/xen/pci.h
> >
> > You can create a similar file there and for the 32 bit implementation just
> > make an empty static function.
> >
> > The 64 bit implementation has to be somewhere. Can it be in the Xen EFI
> > file which is only compiled on 64 bit platforms?
>
> OK, this (putting declaration/definition in *.h file) makes sens if you
> declare/define functions which must be called from different places.
Right.
> However, xen_efi_init() is called only once in arch/x86/xen/enlighten.c.
And the vga (see arch/x86/xen/vga.c) is also called only once.
> Of course, I could define this function here in similar way like it is done
> in above headers but it take a bit more place. However, if you wish why not.
I was thinking something along this (not compile tested):
>From 436461a33cf93eed2cd96774bfca78fb08930de1 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk
Date: Fri, 11 Jul 2014 22:30:33 -0400
Subject: [PATCH] Like this.
---
arch/x86/xen/Makefile|1 +
arch/x86/xen/efi.c | 22 ++
arch/x86/xen/enlighten.c | 23 +--
arch/x86/xen/xen-ops.h |8
4 files changed, 32 insertions(+), 22 deletions(-)
create mode 100644 arch/x86/xen/efi.c
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index b187df5..aa045ad 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
obj-$(CONFIG_XEN_DOM0) += apic.o vga.o
obj-$(CONFIG_SWIOTLB_XEN) += pci-swiotlb-xen.o
+obj-$(CONFIG_XEN_EFI) += efi.c
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
new file mode 100644
index 000..0b751d9
--- /dev/null
+++ b/arch/x86/xen/efi.c
@@ -0,0 +1,22 @@
+/* Need some headers. */
+
+extern efi_system_table_t __init *xen_efi_probe(void);
+
+void __init xen_efi_init(void)
+{
+ efi_system_table_t *efi_systab_xen;
+
+ efi_systab_xen = xen_efi_probe();
+
+ if (!efi_systab_xen)
+ return;
+
+ strncpy((char *)_params.efi_info.efi_loader_signature, "Xen",
+ sizeof(boot_params.efi_info.efi_loader_signature));
+ boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
+ boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >>
32);
+
+ set_bit(EFI_BOOT, );
+ set_bit(EFI_NO_DIRECT, );
+ set_bit(EFI_64BIT, );
+}
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index abd8013..2d71db3 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -152,15 +152,6 @@ struct shared_info *HYPERVISOR_shared_info =
_dummy_shared_info;
*/
static int have_vcpu_info_placement = 1;
-#ifdef CONFIG_XEN_EFI
-extern efi_system_table_t __init *xen_efi_probe(void);
-#else
-static efi_system_table_t __init *xen_efi_probe(void)
-{
- return NULL;
-}
-#endif
-
struct tls_descs {
struct desc_struct desc[3];
};
@@ -1581,7 +1572,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
{
struct physdev_set_iopl set_iopl;
int rc;
- efi_system_table_t *efi_systab_xen;
if (!xen_start_info)
return;
@@ -1777,18 +1767,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
xen_setup_runstate_info(0);
- efi_systab_xen = xen_efi_probe();
-
- if (efi_systab_xen) {
- strncpy((char *)_params.efi_info.efi_loader_signature,
"Xen",
-
sizeof(boot_params.efi_info.efi_loader_signature));
- boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
- boot_params.efi_info.efi_systab_hi =
(__u32)(__pa(efi_systab_xen) >> 32);
-
- set_bit(EFI_BOOT, );
- set_bit(EFI_NO_DIRECT, );
- set_bit(EFI_64BIT, );
- }
+ xen_efi_init();
/* Start the world */
#ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index 12a884d..0908dec 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -127,4 +127,12 @@ __visible void xen_adjust_exception_frame(void);
extern int xen_panic_handler_init(void);
void xen_pvh_secondary_vcpu_init(int cpu);
+
+#ifdef CONFIG_X86_64
+void __init
Re: [PATCH] reformat_with_checkpatch: Add automation to checkpatch
On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote: > A simple script to run checkpatch --fix for various types of > of cleanups. > > This script is useful primarily for staging. > > This reformats code to a more CodingStyle conforming style, > compiles it, verifies that the object code hasn't changed, > and git commits it too. And 'git commits' it? Heh, I should just run this myself to clean up staging and beat everyone else to it... I know some people already have private versions of these things, might as well make it public for all to abuse :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH char-misc-next v3 2/8] misc: mic: add a bus driver for virtual MIC devices
On Fri, Jul 11, 2014 at 06:27:20PM -0700, Greg Kroah-Hartman wrote: > On Fri, Jul 11, 2014 at 02:04:20PM -0700, Sudeep Dutt wrote: > > This MIC virtual bus driver takes the responsibility of creating all > > the virtual devices connected to the PCIe device on the host and the > > platform device on the card. The MIC bus hardware operations provide > > a way to abstract certain hardware details from the base physical devices. > > Examples of devices added on the MIC virtual bus include host DMA and card > > DMA. > > This abstraction enables using a common DMA driver on host and card. > > > > Reviewed-by: Ashutosh Dixit > > Reviewed-by: Nikhil Rao > > Signed-off-by: Sudeep Dutt > > Signed-off-by: Siva Yerramreddy > > --- > > drivers/misc/mic/Kconfig | 17 > > drivers/misc/mic/Makefile | 1 + > > drivers/misc/mic/bus/Makefile | 5 + > > drivers/misc/mic/bus/mic_bus.c | 218 > > + > > include/linux/mic_bus.h| 110 + > > 5 files changed, 351 insertions(+) > > create mode 100644 drivers/misc/mic/bus/Makefile > > create mode 100644 drivers/misc/mic/bus/mic_bus.c > > create mode 100644 include/linux/mic_bus.h > > Looks good, but no addition to scripts/mod/file2alias.c to allow > autoloading of mic_bus drivers? > > I'll take patches 1 and 2 here, as I need some acks from the DMA people > on patch 3. And I took 4-8 as well, as they seemed independant from patch 3. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH char-misc-next v3 2/8] misc: mic: add a bus driver for virtual MIC devices
On Fri, Jul 11, 2014 at 02:04:20PM -0700, Sudeep Dutt wrote: > This MIC virtual bus driver takes the responsibility of creating all > the virtual devices connected to the PCIe device on the host and the > platform device on the card. The MIC bus hardware operations provide > a way to abstract certain hardware details from the base physical devices. > Examples of devices added on the MIC virtual bus include host DMA and card > DMA. > This abstraction enables using a common DMA driver on host and card. > > Reviewed-by: Ashutosh Dixit > Reviewed-by: Nikhil Rao > Signed-off-by: Sudeep Dutt > Signed-off-by: Siva Yerramreddy > --- > drivers/misc/mic/Kconfig | 17 > drivers/misc/mic/Makefile | 1 + > drivers/misc/mic/bus/Makefile | 5 + > drivers/misc/mic/bus/mic_bus.c | 218 > + > include/linux/mic_bus.h| 110 + > 5 files changed, 351 insertions(+) > create mode 100644 drivers/misc/mic/bus/Makefile > create mode 100644 drivers/misc/mic/bus/mic_bus.c > create mode 100644 include/linux/mic_bus.h Looks good, but no addition to scripts/mod/file2alias.c to allow autoloading of mic_bus drivers? I'll take patches 1 and 2 here, as I need some acks from the DMA people on patch 3. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pinctrl: qcom: Make muxing of gpio function explicit
Instead of relying on pinmux->disable(), make the gpio function an
explicit function for all pins that supports it.
Signed-off-by: Bjorn Andersson
---
This fixes the regression that was introduced by removing the disable function
from the pinmux ops. I was exploiting the disable function to put the gpio pins
"back" into gpio state and this was apparently not the right way to do things.
.../bindings/pinctrl/qcom,apq8064-pinctrl.txt | 2 +-
.../bindings/pinctrl/qcom,ipq8064-pinctrl.txt | 2 +-
.../bindings/pinctrl/qcom,msm8960-pinctrl.txt | 4 +--
.../bindings/pinctrl/qcom,msm8974-pinctrl.txt | 2 +-
drivers/pinctrl/qcom/pinctrl-apq8064.c | 19 +-
drivers/pinctrl/qcom/pinctrl-ipq8064.c | 17 +++-
drivers/pinctrl/qcom/pinctrl-msm8960.c | 30 +-
drivers/pinctrl/qcom/pinctrl-msm8x74.c | 29 -
8 files changed, 96 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
index 7181f92..0211c6d 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
@@ -46,7 +46,7 @@ Valid values for pins are:
gpio0-gpio89
Valid values for function are:
- cam_mclk, codec_mic_i2s, codec_spkr_i2s, gsbi1, gsbi2, gsbi3, gsbi4,
+ cam_mclk, codec_mic_i2s, codec_spkr_i2s, gpio, gsbi1, gsbi2, gsbi3, gsbi4,
gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6,
gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1,
gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm,
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
index e0d35a4..e33e4dc 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
@@ -51,7 +51,7 @@ Valid values for qcom,pins are:
Valid values for function are:
- mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gsbi1, gsbi2, gsbi4, gsbi5,
+ mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gpio, gsbi1, gsbi2, gsbi4, gsbi5,
gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi7, nss_spi, sdc1,
spdif, nand, tsif1, tsif2, usb_fs_n, usb_fs, usb2_hsic, rgmii2, sata,
pcie1_rst, pcie1_prsnt, pcie1_pwren_n, pcie1_pwren, pcie1_pwrflt,
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
index 7dece8d..93b7de9 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
@@ -83,7 +83,7 @@ to specify in a pin configuration subnode:
sdc3_data
- function:
- Usage: optional
+ Usage: required
Value type:
Definition: Specify the alternative function to be configured for the
specified pins. Functions are only valid for gpio pins.
@@ -92,7 +92,7 @@ to specify in a pin configuration subnode:
codec_mic_i2s, codec_spkr_i2s, ext_gps, fm, gps_blanking,
gps_pps_in, gps_pps_out, gp_clk_0a, gp_clk_0b, gp_clk_1a,
gp_clk_1b, gp_clk_2a, gp_clk_2b, gp_mn, gp_pdm_0a,
- gp_pdm_0b, gp_pdm_1a, gp_pdm_1b, gp_pdm_2a, gp_pdm_2b,
+ gp_pdm_0b, gp_pdm_1a, gp_pdm_1b, gp_pdm_2a, gp_pdm_2b, gpio,
gsbi1, gsbi1_spi_cs1_n, gsbi1_spi_cs2a_n, gsbi1_spi_cs2b_n,
gsbi1_spi_cs3_n, gsbi2, gsbi2_spi_cs1_n, gsbi2_spi_cs2_n,
gsbi2_spi_cs3_n, gsbi3, gsbi4, gsbi4_3d_cam_i2c_l,
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
index 73262b5..d2ea80d 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
@@ -70,7 +70,7 @@ Valid values for function are:
cam_mckl0, cam_mclk1, cam_mclk2, cam_mclk3, mdp_vsync, hdmi_cec, hdmi_ddc,
hdmi_hpd, edp_hpd, gp_pdm0, gp_pdm1, gp_pdm2, gp_pdm3, gp0_clk, gp1_clk,
gp_mn, tsif1, tsif2, hsic, grfc, audio_ref_clk, qua_mi2s, pri_mi2s,
spkr_mi2s,
- ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus
+ ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus, gpio
(Note that this is not yet the complete list of functions)
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8064.c
b/drivers/pinctrl/qcom/pinctrl-apq8064.c
index 519f788..feb6f15 100644
--- a/drivers/pinctrl/qcom/pinctrl-apq8064.c
+++ b/drivers/pinctrl/qcom/pinctrl-apq8064.c
@@ -230,7 +230,7 @@ static const unsigned int sdc3_data_pins[] = { 95 };
.pins = gpio##id##_pins,
[PATCH] reformat_with_checkpatch: Add automation to checkpatch
A simple script to run checkpatch --fix for various types of
of cleanups.
This script is useful primarily for staging.
This reformats code to a more CodingStyle conforming style,
compiles it, verifies that the object code hasn't changed,
and git commits it too.
You must have the necessary development tools, git, and a
recent git tree. Ideally use Greg KH's staging-next, which
can be retrieved via these commands:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
git checkout staging-next
To use this script try a sequence of commands like:
cd
git checkout -b
make allyesconfig
mkdir patches
./scripts/reformat_with_checkpatch.sh drivers/staging//*.[ch]
git format-patch --cover-letter -o patches/ staging-next
git send-email patches/
Signed-off-by: Joe Perches
---
scripts/reformat_with_checkpatch.sh | 141
1 file changed, 141 insertions(+)
create mode 100755 scripts/reformat_with_checkpatch.sh
diff --git a/scripts/reformat_with_checkpatch.sh
b/scripts/reformat_with_checkpatch.sh
new file mode 100755
index 000..5415a8e
--- /dev/null
+++ b/scripts/reformat_with_checkpatch.sh
@@ -0,0 +1,141 @@
+#!/bin/bash
+# (c) 2014, Joe Perches
+#
+# Automate checkpatch modifications and git commits to
+# neaten code that doesn't conform to CodingStyle.
+# Useful primarily for files in drivers/staging
+#
+# Licensed under the terms of the GNU GPL License version 2
+
+declare -ar whitespace_types=( \
+
'whitespace_neatening:spacing,space_before_tab,pointer_location,trailing_whitespace,bracket_space'
\
+'remove_spaces_before_tabs:space_before_tab' \
+'fix_label_positions:indented_label' \
+'align_arguments_to_parenthesis:parenthesis_alignment' \
+)
+
+declare -ar changecode_types=( \
+'fix_brace_positions:open_brace,braces,else_after_brace,while_after_brace'
\
+'fix_blank_lines:line_spacing' \
+'use_standard_attributes:prefer_packed,prefer_aligned' \
+'remove_unnecessary_externs:avoid_externs' \
+'update_c90_comment_style:c99_comments'\
+)
+
+checkpatch_update ()
+{
+file=$1
+
+desc=$(echo $2 | cut -f1 -d: | sed 's/_/ /g')
+types=$(echo $2 | cut -f2- -d:)
+
+echo "file: <$file> description: <$desc> types:<$types>"
+
+./scripts/checkpatch.pl --file --fix-inplace --strict --types="$types"
$file
+
+checkpatch_fixes=$file.diff
+git diff --stat -p --exit-code $file > $checkpatch_fixes
+if [ $? == 0 ] ; then
+ rm -f $checkpatch_fixes
+ return
+fi
+
+basename=$(basename $file)
+if [ "${basename##*.}" == "c" ] ; then
+
+ git checkout $file
+ obj="$(echo $file | sed 's/\.c$/\.o/')"
+ if [ -e $obj ] ; then
+ rm -f $obj
+ fi
+
+ echo "Compiling original version..."
+
+ ${CROSS_COMPILE}make $obj
+
+ ${CROSS_COMPILE}objdump -D $obj | \
+ sed "s/^[[:space:]]\+[0-9a-f]\+//" > $obj.old
+
+ patch -p1 < $checkpatch_fixes
+
+ echo "Compiling modified version..."
+
+ ${CROSS_COMPILE}make $obj
+
+ ${CROSS_COMPILE}objdump -D $obj | \
+ sed "s/^[[:space:]]\+[0-9a-f]\+//" > $obj.new
+
+ echo "Comparing objects..."
+ diff -Nurd $obj.new $obj.old
+ if [ $? -ne 0 ] ; then
+ echo "Object differences exist! - Verify changes before commit!"
+ read -s -p "Press the 'enter' key to continue: "
+ else
+ echo "No object differences found"
+ fi
+ rm -f $obj.old
+ rm -f $obj.new
+fi
+
+echo "running checkpatch on possible checkpatch fixes..."
+
+./scripts/checkpatch.pl --no-summary --no-signoff $checkpatch_fixes
+rm -f $checkpatch_fixes
+
+echo "Verify checkpatch output and make any necessary changes"
+echo "Edit '$file' if appropriate"
+read -s -p "Press the 'enter' key to continue: "
+
+commit_log_file=$(mktemp git_commit.XX)
+
+if [ -e $commit_log_file ] ; then
+ rm -f $commit_log_file
+fi
+
+if [[ $file =~ ^drivers/staging/ ]] ; then
+ echo -n "staging: " >> $commit_log_file
+fi
+echo "$(basename $(dirname $file)): checkpatch cleanup: $desc" >>
$commit_log_file
+echo "" >> $commit_log_file
+git diff --exit-code -w $file > /dev/null
+if [ $? == 0 ] ; then
+ echo "whitespace changes only - git diff -w shows no difference" >>
$commit_log_file
+fi
+
+git diff $file | cat
+
+echo "Ready to commit - First verify all diffs and make any necessary
changes"
+echo ""
+read -r -p "Would you like to commit these changes : " response
+response=${response,,}
+if [[ $response =~ ^(yes|y|)$ ]] ; then
+ git commit -s -F $commit_log_file -e $file
+else
+ git checkout $file
+fi
+
+rm -f $commit_log_file
+}
+
+which git > /dev/null
+if [ $? -ne 0 ] || [ ! -e .git ] ;
Re: linux-next: build failure after merge of the tty.current tree
Hi Peter, On Fri, 11 Jul 2014 11:06:56 -0400 Peter Hurley wrote: > > Sorry about that. I don't have a full cross-compiler setup for > build testing. Looks like that's something I'm going to have to add. see https://www.kernel.org/pub/tools/crosstool/ These are only good for building the kernel (no libc). You don't necessarily need to build the whole kernel but often just building the particular drivers is enough. Especially if they are directly modified ... -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [RFC/PATCH -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector.
On 07/09/2014 04:00 AM, Andrey Ryabinin wrote:
>
> Address sanitizer dedicates 1/8 of the low memory to the shadow memory and
> uses direct
> mapping with a scale and offset to translate a memory address to its
> corresponding
> shadow address.
>
> Here is function to translate address to corresponding shadow address:
>
> unsigned long kasan_mem_to_shadow(unsigned long addr)
> {
> return ((addr) >> KASAN_SHADOW_SCALE_SHIFT)
>+ kasan_shadow_start - (PAGE_OFFSET >>
> KASAN_SHADOW_SCALE_SHIFT);
> }
>
> where KASAN_SHADOW_SCALE_SHIFT = 3.
>
How does that work when memory is sparsely populated?
-hpa
--
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] drivers/base: redundant return value settings in try_to_bring_up_master()
On Tue, Jun 17, 2014 at 04:25:31PM +0800, Liu Ying wrote: > Remove redundant return value settings 'ret = 0;' in the function > try_to_bring_up_master(), since it has already been set to zero. > > Signed-off-by: Liu Ying > --- > drivers/base/component.c |2 -- > 1 file changed, 2 deletions(-) This patch no longer applies to my tree, are you sure it's still needed? If so, please refresh and resend. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: devres: update list of supported calls
On Thu, Jul 10, 2014 at 04:17:26PM -0700, Randy Dunlap wrote: > On 07/07/2014 01:10 AM, Cristian Stoica wrote: > > Signed-off-by: Cristian Stoica > > Greg, do you want this patch? > > > --- > > Documentation/driver-model/devres.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/driver-model/devres.txt > > b/Documentation/driver-model/devres.txt > > index 1525e30..7a48896 100644 > > --- a/Documentation/driver-model/devres.txt > > +++ b/Documentation/driver-model/devres.txt > > @@ -234,6 +234,7 @@ certainly invest a bit more effort into libata core > > layer). > >- > > > > MEM > > + devm_kmalloc() > >devm_kzalloc() > >devm_kfree() > >devm_kmemdup() It's already in my tree in another form, so it doesn't make sense for me to take it again... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arch/x86/xen: Silence compiler warnings
On Fri, Jul 11, 2014 at 08:14:51PM -0400, Konrad Rzeszutek Wilk wrote:
>
> On Jul 11, 2014 7:45 PM, Daniel Kiper wrote:
> >
> > On Fri, Jul 11, 2014 at 04:32:27PM -0400, Boris Ostrovsky wrote:
> > > On 07/11/2014 04:10 PM, Daniel Kiper wrote:
> > > >On Fri, Jul 11, 2014 at 04:03:46PM -0400, Boris Ostrovsky wrote:
> > > >>On 07/11/2014 03:54 PM, Daniel Kiper wrote:
> > > >>>Compiler complains in the following way when x86 32-bit kernel
> > > >>>with Xen support is build:
> > > >>>
> > > >>> CC arch/x86/xen/enlighten.o
> > > >>>arch/x86/xen/enlighten.c: In function ‘xen_start_kernel’:
> > > >>>arch/x86/xen/enlighten.c:1726:3: warning: right shift count >= width
> > > >>>of type [enabled by default]
> > > >>>
> > > >>>Such line contains following EFI initialization code:
> > > >>>
> > > >>>boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >>
> > > >>>32);
> > > >>>
> > > >>>There is no issue if x86 64-bit kernel is build. However, 32-bit case
> > > >>>generate warning (even if that code will not be executed because Xen
> > > >>>does not work on 32-bit EFI platforms) due to __pa() returning
> > > >>>unsigned long
> > > >>>type which has 32-bits width. So move whole EFI initialization stuff
> > > >>>to separate function and build its body conditionally to avoid above
> > > >>>mentioned warning on x86 32-bit architecture.
> > > >>>
> > > >>>Signed-off-by: Daniel Kiper
> > > >>>---
> > > >>> arch/x86/xen/enlighten.c | 35 ++-
> > > >>> 1 file changed, 22 insertions(+), 13 deletions(-)
> > > >>>
> > > >>>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > > >>>index bc89647..6abec74 100644
> > > >>>--- a/arch/x86/xen/enlighten.c
> > > >>>+++ b/arch/x86/xen/enlighten.c
> > > >>>@@ -1516,12 +1516,32 @@ static void __init
> > > >>>xen_pvh_early_guest_init(void)
> > > >>> #endif
> > > >>> }
> > > >>>+static void __init xen_efi_init(void)
> > > >>>+{
> > > >>>+#ifdef CONFIG_XEN_EFI
> > > >>>+ efi_system_table_t *efi_systab_xen;
> > > >>>+
> > > >>>+ efi_systab_xen = xen_efi_probe();
> > > >>>+
> > > >>>+ if (efi_systab_xen == NULL)
> > > >>>+ return;
> > > >>>+
> > > >>>+ strncpy((char *)_params.efi_info.efi_loader_signature, "Xen",
> > > >>>+ sizeof(boot_params.efi_info.efi_loader_signature));
> > > >>>+ boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> > > >>>+ boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >>
> > > >>>32);
> > > >>>+
> > > >>>+ set_bit(EFI_BOOT, );
> > > >>>+ set_bit(EFI_PARAVIRT, );
> > > >>>+ set_bit(EFI_64BIT, );
> > > >>>+#endif
> > > >>>+}
> > > >>>+
> > > >>> /* First C function to be called on Xen boot */
> > > >>> asmlinkage __visible void __init xen_start_kernel(void)
> > > >>> {
> > > >>> struct physdev_set_iopl set_iopl;
> > > >>> int rc;
> > > >>>- efi_system_table_t *efi_systab_xen;
> > > >>> if (!xen_start_info)
> > > >>> return;
> > > >>>@@ -1717,18 +1737,7 @@ asmlinkage __visible void __init
> > > >>>xen_start_kernel(void)
> > > >>> xen_setup_runstate_info(0);
> > > >>>- efi_systab_xen = xen_efi_probe();
> > > >>>-
> > > >>>- if (efi_systab_xen) {
> > > >>>- strncpy((char *)_params.efi_info.efi_loader_signature, "Xen",
> > > >>>- sizeof(boot_params.efi_info.efi_loader_signature));
> > > >>>- boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> > > >>>- boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >>
> > > >>>32);
> > > >>>-
> > > >>>- set_bit(EFI_BOOT, );
> > > >>>- set_bit(EFI_PARAVIRT, );
> > > >>>- set_bit(EFI_64BIT, );
> > > >>>- }
> > > >>>+ xen_efi_init();
> > > >>I'd put ifdef CONFIG_XEN_EFI around the call instead of having it
> > > >>inside the routine.
> > > >Well, I thought about that a bit and I prefer function like Konrad.
> > > >Could you agree with him which solution do you (as maintainers) prefer?
> > > >
> > >
> > > I am not arguing against having a separate routine. All I am saying
> > > is that calling xen_efi_init() when CONFIG_XEN_EFI is not defined
> > > doesn't look logical. It will also add an unnecessary call (although
> >
> > Ahh... I misunderstood you. However, your proposal, as below:
> >
> > #ifdef CONFIG_XEN_EFI
> > xen_efi_init();
> > #endif
> >
> > does not solve the problem because this vulnerable shift will be still
> > visible for compiler during x86 32-bit kernel build.
> >
> > > compiler may optimize it out).
> >
> > Please loot at arch/x86/xen/enlighten.c:xen_check_mwait() and
> > arch/x86/xen/enlighten.c:xen_boot_params_init_edd() (probably
> > there are more stuff like that around). As I can see this is fairly
> > common solution and probably compiler cope with it quite well.
> >
>
> Those are some examples of some rather bad examples.
What is wrong with them?
> The way that is preferred in the Linux code is to have the ifdef in headers.
>
> See
> http://lxr.free-electrons.com/source/arch/x86/include/asm/xen/swiotlb-xen.h
> Or
>
Re: [PATCH] tty: kgdb_nmi: Convert kgdb_nmi_tty_enabled into a module parameter
On Fri, Jul 11, 2014 at 01:30:11PM +0100, Daniel Thompson wrote: > At present it is not possible to boot with the ttyNMI0 console treating > character input normally. To use the console requires that kdb be > entered and the nmi_console command be used to enable the console (or if > only kgdb is present then gdb must directly manipulate the value of > kgdb_nmi_tty_enabled). > > Introducing a module parameter makes the console much more usable. > > Signed-off-by: Daniel Thompson > Cc: Greg Kroah-Hartman > Cc: Jiri Slaby > Cc: linux-ser...@vger.kernel.org > --- > drivers/tty/serial/kgdb_nmi.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/tty/serial/kgdb_nmi.c b/drivers/tty/serial/kgdb_nmi.c > index cfadf29..9361d69 100644 > --- a/drivers/tty/serial/kgdb_nmi.c > +++ b/drivers/tty/serial/kgdb_nmi.c > @@ -43,6 +43,11 @@ module_param_named(magic, kgdb_nmi_magic, charp, 0600); > MODULE_PARM_DESC(magic, "magic sequence to enter NMI debugger (default > $3#33)"); > > static bool kgdb_nmi_tty_enabled; > +module_param_named(tty, kgdb_nmi_tty_enabled, bool, 0600); > +MODULE_PARM_DESC(tty, "if set to false (default), characters received from " > + "the UART will be passed exclusively to the knock " > + "detector; when set to true characters will be passed " > + "both to the knock detector and to the TTY layer"); Module options suck rocks through straws. Isn't there _any_ other way to determine this "dynamically"? How will someone know to set this option? Yeah, there are other options in this module, but please, why add more? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] serial: imx: Fix build breakage
On Thu, Jul 10, 2014 at 10:36:46PM -0400, Peter Hurley wrote: > Fix breakage introduced by > commit c557d392fbf5badd693ea1946a4317c87a26a716, > 'serial: Test for no tx data on tx restart'. > > Signed-off-by: Peter Hurley You forgot a "Reported-by:" tag. I'll go add it... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of locking srbm_gfx_cntl register
>-Original Message-
>From: Bridgman, John
>Sent: Friday, July 11, 2014 1:48 PM
>To: 'Jerome Glisse'; Oded Gabbay
>Cc: David Airlie; Deucher, Alexander; linux-kernel@vger.kernel.org; dri-
>de...@lists.freedesktop.org; Lewycky, Andrew; Joerg Roedel; Gabbay, Oded;
>Koenig, Christian
>Subject: RE: [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of locking
>srbm_gfx_cntl register
>
>Checking... we shouldn't need to call the lock from kfd any more.We should
>be able to do any required locking in radeon kgd code.
Confirmed. The locking functions are removed from the interface in commit 82 :
[PATCH 82/83] drm/radeon: Remove lock functions from kfd2kgd interface
There is an elegant symmetry there, but yeah we need to find a way to make this
less awkward to review without screwing up all the work you've done so far.
It's not obvious how to do that though. I looked at squashing into a smaller
number of big commits earlier on but unless we completely rip the code out and
recreate from scratch I don't see anything better than :
- a few foundation commits
- a big code dump that covers everything up to ~patch 54 (with 71 squashed in)
- remaining commits squashed a bit to combine fixes with initial code
Is that what you had in mind when you said ~10 big commits ? Our feeling was
that the need to skip over the original scheduler would make it more like "one
really big commit and 10-20 smaller ones", and I think we all felt that the
"big code dump" required to skip over the original scheduler would be a
non-starter.
I guess there is another option, and maybe that's what you had in mind --
breaking the "big code dump" into smaller commits would be possible if we were
willing to not have working code until we got to the equivalent of ~patch 54
(+71) when all the new scheduler bits were in. Maybe that would still be an
improvement ?
Thanks,
JB
>
>>-Original Message-
>>From: Jerome Glisse [mailto:j.gli...@gmail.com]
>>Sent: Friday, July 11, 2014 12:35 PM
>>To: Oded Gabbay
>>Cc: David Airlie; Deucher, Alexander; linux-kernel@vger.kernel.org;
>>dri- de...@lists.freedesktop.org; Bridgman, John; Lewycky, Andrew;
>>Joerg Roedel; Gabbay, Oded; Koenig, Christian
>>Subject: Re: [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of
>>locking srbm_gfx_cntl register
>>
>>On Fri, Jul 11, 2014 at 12:50:07AM +0300, Oded Gabbay wrote:
>>> This patch adds a new interface to kfd2kgd_calls structure, which
>>> allows the kfd to lock and unlock the srbm_gfx_cntl register
>>
>>Why does kfd needs to lock this register if kfd can not access any of
>>those register ? This sounds broken to me, exposing a driver internal
>>mutex to another driver is not something i am fan of.
>>
>>Cheers,
>>Jérôme
>>
>>>
>>> Signed-off-by: Oded Gabbay
>>> ---
>>> drivers/gpu/drm/radeon/radeon_kfd.c | 20
>>> include/linux/radeon_kfd.h | 4
>>> 2 files changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c
>>> b/drivers/gpu/drm/radeon/radeon_kfd.c
>>> index 66ee36b..594020e 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
>>> @@ -43,6 +43,10 @@ static void unkmap_mem(struct kgd_dev *kgd,
>struct
>>> kgd_mem *mem);
>>>
>>> static uint64_t get_vmem_size(struct kgd_dev *kgd);
>>>
>>> +static void lock_srbm_gfx_cntl(struct kgd_dev *kgd); static void
>>> +unlock_srbm_gfx_cntl(struct kgd_dev *kgd);
>>> +
>>> +
>>> static const struct kfd2kgd_calls kfd2kgd = {
>>> .allocate_mem = allocate_mem,
>>> .free_mem = free_mem,
>>> @@ -51,6 +55,8 @@ static const struct kfd2kgd_calls kfd2kgd = {
>>> .kmap_mem = kmap_mem,
>>> .unkmap_mem = unkmap_mem,
>>> .get_vmem_size = get_vmem_size,
>>> + .lock_srbm_gfx_cntl = lock_srbm_gfx_cntl,
>>> + .unlock_srbm_gfx_cntl = unlock_srbm_gfx_cntl,
>>> };
>>>
>>> static const struct kgd2kfd_calls *kgd2kfd; @@ -233,3 +239,17 @@
>>> static uint64_t get_vmem_size(struct kgd_dev *kgd)
>>>
>>> return rdev->mc.real_vram_size;
>>> }
>>> +
>>> +static void lock_srbm_gfx_cntl(struct kgd_dev *kgd) {
>>> + struct radeon_device *rdev = (struct radeon_device *)kgd;
>>> +
>>> + mutex_lock(>srbm_mutex);
>>> +}
>>> +
>>> +static void unlock_srbm_gfx_cntl(struct kgd_dev *kgd) {
>>> + struct radeon_device *rdev = (struct radeon_device *)kgd;
>>> +
>>> + mutex_unlock(>srbm_mutex);
>>> +}
>>> diff --git a/include/linux/radeon_kfd.h b/include/linux/radeon_kfd.h
>>> index c7997d4..40b691c 100644
>>> --- a/include/linux/radeon_kfd.h
>>> +++ b/include/linux/radeon_kfd.h
>>> @@ -81,6 +81,10 @@ struct kfd2kgd_calls {
>>> void (*unkmap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem);
>>>
>>> uint64_t (*get_vmem_size)(struct kgd_dev *kgd);
>>> +
>>> + /* SRBM_GFX_CNTL mutex */
>>> + void (*lock_srbm_gfx_cntl)(struct kgd_dev *kgd);
>>> + void (*unlock_srbm_gfx_cntl)(struct kgd_dev *kgd);
>>> };
>>>
>>> bool kgd2kfd_init(unsigned interface_version,
>>> --
>>> 1.9.1
>>>
--
Recall: [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of locking srbm_gfx_cntl register
Bridgman, John would like to recall the message, "[PATCH 07/83] drm/radeon: Add kfd-->kgd interface of locking srbm_gfx_cntl register".-- 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 07/83] drm/radeon: Add kfd-->kgd interface of locking srbm_gfx_cntl register
Confirmed. The locking functions are removed from the interface in commit 82 :
[PATCH 82/83] drm/radeon: Remove lock functions from kfd2kgd interface
There is an elegant symmetry there, but yeah we need to find a way to make this
less awkward to review without screwing up all the work you've done so far.
It's not obvious how to do that though. I looked at squashing into a smaller
number of big commits earlier on but unless we completely rip the code out and
recreate from scratch I don't see anything better than :
- a few foundation commits
- a big code dump that covers everything up to ~patch 54 (with 71 squashed in)
- remaining commits squashed a bit to combine fixes with initial code
Is that what you had in mind when you said ~10 big commits ? Our feeling was
that the need to skip over the original scheduler would make it more like "one
really big commit and 10-20 smaller ones", and I think we all felt that the
"big code dump" required to skip over the original scheduler would be a
non-starter.
I guess there is another option, and maybe that's what you had in mind --
breaking the "big code dump" into smaller commits would be possible if we were
willing to not have working code until we got to the equivalent of ~patch 54
(+71) when all the new scheduler bits were in. Maybe that would still be an
improvement ?
Thanks,
JB
>-Original Message-
>From: Bridgman, John
>Sent: Friday, July 11, 2014 1:48 PM
>To: 'Jerome Glisse'; Oded Gabbay
>Cc: David Airlie; Deucher, Alexander; linux-kernel@vger.kernel.org; dri-
>de...@lists.freedesktop.org; Lewycky, Andrew; Joerg Roedel; Gabbay, Oded;
>Koenig, Christian
>Subject: RE: [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of locking
>srbm_gfx_cntl register
>
>Checking... we shouldn't need to call the lock from kfd any more.We should
>be able to do any required locking in radeon kgd code.
>
>>-Original Message-
>>From: Jerome Glisse [mailto:j.gli...@gmail.com]
>>Sent: Friday, July 11, 2014 12:35 PM
>>To: Oded Gabbay
>>Cc: David Airlie; Deucher, Alexander; linux-kernel@vger.kernel.org;
>>dri- de...@lists.freedesktop.org; Bridgman, John; Lewycky, Andrew;
>>Joerg Roedel; Gabbay, Oded; Koenig, Christian
>>Subject: Re: [PATCH 07/83] drm/radeon: Add kfd-->kgd interface of
>>locking srbm_gfx_cntl register
>>
>>On Fri, Jul 11, 2014 at 12:50:07AM +0300, Oded Gabbay wrote:
>>> This patch adds a new interface to kfd2kgd_calls structure, which
>>> allows the kfd to lock and unlock the srbm_gfx_cntl register
>>
>>Why does kfd needs to lock this register if kfd can not access any of
>>those register ? This sounds broken to me, exposing a driver internal
>>mutex to another driver is not something i am fan of.
>>
>>Cheers,
>>Jérôme
>>
>>>
>>> Signed-off-by: Oded Gabbay
>>> ---
>>> drivers/gpu/drm/radeon/radeon_kfd.c | 20
>>> include/linux/radeon_kfd.h | 4
>>> 2 files changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c
>>> b/drivers/gpu/drm/radeon/radeon_kfd.c
>>> index 66ee36b..594020e 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
>>> @@ -43,6 +43,10 @@ static void unkmap_mem(struct kgd_dev *kgd,
>struct
>>> kgd_mem *mem);
>>>
>>> static uint64_t get_vmem_size(struct kgd_dev *kgd);
>>>
>>> +static void lock_srbm_gfx_cntl(struct kgd_dev *kgd); static void
>>> +unlock_srbm_gfx_cntl(struct kgd_dev *kgd);
>>> +
>>> +
>>> static const struct kfd2kgd_calls kfd2kgd = {
>>> .allocate_mem = allocate_mem,
>>> .free_mem = free_mem,
>>> @@ -51,6 +55,8 @@ static const struct kfd2kgd_calls kfd2kgd = {
>>> .kmap_mem = kmap_mem,
>>> .unkmap_mem = unkmap_mem,
>>> .get_vmem_size = get_vmem_size,
>>> + .lock_srbm_gfx_cntl = lock_srbm_gfx_cntl,
>>> + .unlock_srbm_gfx_cntl = unlock_srbm_gfx_cntl,
>>> };
>>>
>>> static const struct kgd2kfd_calls *kgd2kfd; @@ -233,3 +239,17 @@
>>> static uint64_t get_vmem_size(struct kgd_dev *kgd)
>>>
>>> return rdev->mc.real_vram_size;
>>> }
>>> +
>>> +static void lock_srbm_gfx_cntl(struct kgd_dev *kgd) {
>>> + struct radeon_device *rdev = (struct radeon_device *)kgd;
>>> +
>>> + mutex_lock(>srbm_mutex);
>>> +}
>>> +
>>> +static void unlock_srbm_gfx_cntl(struct kgd_dev *kgd) {
>>> + struct radeon_device *rdev = (struct radeon_device *)kgd;
>>> +
>>> + mutex_unlock(>srbm_mutex);
>>> +}
>>> diff --git a/include/linux/radeon_kfd.h b/include/linux/radeon_kfd.h
>>> index c7997d4..40b691c 100644
>>> --- a/include/linux/radeon_kfd.h
>>> +++ b/include/linux/radeon_kfd.h
>>> @@ -81,6 +81,10 @@ struct kfd2kgd_calls {
>>> void (*unkmap_mem)(struct kgd_dev *kgd, struct kgd_mem *mem);
>>>
>>> uint64_t (*get_vmem_size)(struct kgd_dev *kgd);
>>> +
>>> + /* SRBM_GFX_CNTL mutex */
>>> + void (*lock_srbm_gfx_cntl)(struct kgd_dev *kgd);
>>> + void (*unlock_srbm_gfx_cntl)(struct kgd_dev *kgd);
>>> };
>>>
>>> bool kgd2kfd_init(unsigned interface_version,
>>> --
>>> 1.9.1
>>>
--
To
Re: [PATCH v3] drivers/staging/comedi/drivers/ni_atmio16d.c: remove pointless condition
On Fri, Jul 11, 2014 at 03:39:48PM +0100, Ian Abbott wrote: > On 2014-07-11 15:38, Ian Abbott wrote: > >From: Andrey Utkin > > > >From: Andrey Utkin > > Dammit! Greg, do you want to sort that out or should I have another go? Heh, no worries, I can fix it up, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/cleanups] x86: Simplify __HAVE_ARCH_CMPXCHG tests
Commit-ID: b08ee5f7e4135d64b8edd769367f8964a725122e
Gitweb: http://git.kernel.org/tip/b08ee5f7e4135d64b8edd769367f8964a725122e
Author: Borislav Petkov
AuthorDate: Fri, 11 Jul 2014 12:43:38 +0200
Committer: H. Peter Anvin
CommitDate: Fri, 11 Jul 2014 17:28:51 -0700
x86: Simplify __HAVE_ARCH_CMPXCHG tests
Both the 32-bit and 64-bit cmpxchg.h header define __HAVE_ARCH_CMPXCHG
and there's ifdeffery which checks it. But since both bitness define it,
we can just as well move it up to the main cmpxchg header and simpify a
bit of code in doing that.
Signed-off-by: Borislav Petkov
Link: http://lkml.kernel.org/r/20140711104338.gb17...@pd.tnic
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/cmpxchg.h | 4 ++--
arch/x86/include/asm/cmpxchg_32.h | 2 --
arch/x86/include/asm/cmpxchg_64.h | 2 --
arch/x86/include/asm/mc146818rtc.h | 2 +-
arch/x86/include/asm/mutex_32.h| 16 ++--
arch/x86/kernel/acpi/boot.c| 4
6 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/arch/x86/include/asm/cmpxchg.h b/arch/x86/include/asm/cmpxchg.h
index d47786a..99c105d7 100644
--- a/arch/x86/include/asm/cmpxchg.h
+++ b/arch/x86/include/asm/cmpxchg.h
@@ -4,6 +4,8 @@
#include
#include /* Provides LOCK_PREFIX */
+#define __HAVE_ARCH_CMPXCHG 1
+
/*
* Non-existant functions to indicate usage errors at link time
* (or compile-time if the compiler implements __compiletime_error().
@@ -143,7 +145,6 @@ extern void __add_wrong_size(void)
# include
#endif
-#ifdef __HAVE_ARCH_CMPXCHG
#define cmpxchg(ptr, old, new) \
__cmpxchg(ptr, old, new, sizeof(*(ptr)))
@@ -152,7 +153,6 @@ extern void __add_wrong_size(void)
#define cmpxchg_local(ptr, old, new) \
__cmpxchg_local(ptr, old, new, sizeof(*(ptr)))
-#endif
/*
* xadd() adds "inc" to "*ptr" and atomically returns the previous
diff --git a/arch/x86/include/asm/cmpxchg_32.h
b/arch/x86/include/asm/cmpxchg_32.h
index f8bf2ee..f7e1429 100644
--- a/arch/x86/include/asm/cmpxchg_32.h
+++ b/arch/x86/include/asm/cmpxchg_32.h
@@ -34,8 +34,6 @@ static inline void set_64bit(volatile u64 *ptr, u64 value)
: "memory");
}
-#define __HAVE_ARCH_CMPXCHG 1
-
#ifdef CONFIG_X86_CMPXCHG64
#define cmpxchg64(ptr, o, n) \
((__typeof__(*(ptr)))__cmpxchg64((ptr), (unsigned long long)(o), \
diff --git a/arch/x86/include/asm/cmpxchg_64.h
b/arch/x86/include/asm/cmpxchg_64.h
index 614be87..1af9469 100644
--- a/arch/x86/include/asm/cmpxchg_64.h
+++ b/arch/x86/include/asm/cmpxchg_64.h
@@ -6,8 +6,6 @@ static inline void set_64bit(volatile u64 *ptr, u64 val)
*ptr = val;
}
-#define __HAVE_ARCH_CMPXCHG 1
-
#define cmpxchg64(ptr, o, n) \
({ \
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
diff --git a/arch/x86/include/asm/mc146818rtc.h
b/arch/x86/include/asm/mc146818rtc.h
index a55c7ef..0f555cc 100644
--- a/arch/x86/include/asm/mc146818rtc.h
+++ b/arch/x86/include/asm/mc146818rtc.h
@@ -13,7 +13,7 @@
#define RTC_ALWAYS_BCD 1 /* RTC operates in binary mode */
#endif
-#if defined(CONFIG_X86_32) && defined(__HAVE_ARCH_CMPXCHG)
+#if defined(CONFIG_X86_32)
/*
* This lock provides nmi access to the CMOS/RTC registers. It has some
* special properties. It is owned by a CPU and stores the index register
diff --git a/arch/x86/include/asm/mutex_32.h b/arch/x86/include/asm/mutex_32.h
index 0208c3c..85e6cda 100644
--- a/arch/x86/include/asm/mutex_32.h
+++ b/arch/x86/include/asm/mutex_32.h
@@ -100,23 +100,11 @@ do {
\
static inline int __mutex_fastpath_trylock(atomic_t *count,
int (*fail_fn)(atomic_t *))
{
- /*
-* We have two variants here. The cmpxchg based one is the best one
-* because it never induce a false contention state. It is included
-* here because architectures using the inc/dec algorithms over the
-* xchg ones are much more likely to support cmpxchg natively.
-*
-* If not we fall back to the spinlock based variant - that is
-* just as efficient (and simpler) as a 'destructive' probing of
-* the mutex state would be.
-*/
-#ifdef __HAVE_ARCH_CMPXCHG
+ /* cmpxchg because it never induces a false contention state. */
if (likely(atomic_cmpxchg(count, 1, 0) == 1))
return 1;
+
return 0;
-#else
- return fail_fn(count);
-#endif
}
#endif /* _ASM_X86_MUTEX_32_H */
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 86281ff..a531f65 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -74,10 +74,6 @@ int acpi_fix_pin2_polarity __initdata;
static u64
Re: [PATCH v3+1 5/5] ARM: DT: STi: STiH416: Add DT node for MiPHY365x
Hello.
On 07/11/2014 03:54 PM, Lee Jones wrote:
The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
devices. It has 2 ports which it can use for either; both SATA, both
PCIe or one of each in any configuration.
Acked-by: Mark Rutland
Acked-by: Alexandre Torgue
Signed-off-by: Lee Jones
diff --git a/arch/arm/boot/dts/stih416-b2020.dts
b/arch/arm/boot/dts/stih416-b2020.dts
index 4e2df66..c3c2ac6 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -12,4 +12,16 @@
/ {
model = "STiH416 B2020";
compatible = "st,stih416-b2020", "st,stih416";
+
+ soc {
+ miphy365x_phy: miphy365x@fe382000 {
+ phy_port0: port@fe382000 {
I don't understand why are you creating the duplicate labels; doesn't
'dtc' complain about them? You could instead refer to them as:
_phy {
};
+ st,sata-gen = <3>;
+ };
+
+ phy_port1: port@fe38a000 {
+ st,pcie-tx-pol-inv;
+ };
+ };
+ };
};
[...]
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index 84758d7..2b98a0a 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -9,6 +9,8 @@
#include "stih41x.dtsi"
#include "stih416-clock.dtsi"
#include "stih416-pinctrl.dtsi"
+
+#include
#include
#include
/ {
@@ -236,5 +238,25 @@
resets = < STIH416_KEYSCAN_POWERDOWN>,
< STIH416_KEYSCAN_SOFTRESET>;
};
+
+ miphy365x_phy: miphy365x@fe382000 {
The ePAPR standard [1] says:
The name of a node should be somewhat generic, reflecting the function of the
device and not its precise programming model.
+ compatible = "st,miphy365x-phy";
+ st,syscfg = <_rear>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ phy_port0: port@fe382000 {
+ #phy-cells = <1>;
If these are PHY devices, they should be named "phy", not "port".
+ reg = <0xfe382000 0x100>, <0xfe394000 0x100>,
<0x824 0x4>;
+ reg-names = "sata", "pcie", "syscfg";
+ };
+
+ phy_port1: port@fe38a000 {
+ #phy-cells = <1>;
+ reg = <0xfe38a000 0x100>, <0xfe804000 0x100>,
<0x828 0x4>;
+ reg-names = "sata", "pcie", "syscfg";
+ };
+ };
};
};
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform
Hi Greg, On Sat, Jul 12, 2014 at 8:04 AM, Greg KH wrote: > On Sat, Jul 12, 2014 at 07:32:34AM +0800, Gavin Guo wrote: >> Hi all, >> >> On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo wrote: >> > Hi Sarah and Mathias, >> > >> > As the discussion in >> > http://comments.gmane.org/gmane.linux.usb.general/107011, >> > I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk >> > can't work in SuperSpeed after several times of hotplug. After doing some >> > experiments and bisection, I found the bug is caused by >> > 41e7e056cdc662f704fa9262e5c6e213b4ab45dd (USB: Allow USB 3.0 ports to be >> > disabled.). And the bug can be fixed by not executing the >> > hub_usb3_port_disable() function. I also found that the port status is >> > already in RxDetect before setting the port to Disabled in >> > hub_usb3_port_disable() function. So, there are 2 ways to fix the bug: >> > >> > 1) Check if the Vendor/Device id is [1022:7814] at the beginning of >> > hub_usb3_port_disable() function. If yes, return without executing the >> > remaining code. >> > >> > 2) Check if the port status is already in RxDetect, if yes, return without >> > executing the remaining code. >> > >> > The second method seems more reasonable, so the patch is the implementation >> > of the second one. But it will affect more platforms and I don't know if >> > there'll be any negative result. Otherwise, if the first one is correct, >> > I can reimplement a new one. >> > >> > I'm appreciated if you can give me some advice, or if there is any thing I >> > missed. >> > >> > Thanks, >> > Gavin >> > >> > Gavin Guo (1): >> > usb: Check if port status is equal to RxDetect >> > >> > drivers/usb/core/hub.c | 19 +++ >> > 1 file changed, 19 insertions(+) >> > >> > -- >> > 2.0.0 >> > >> >> Add Greg k-h to the list. > > Why? Mathias can handle this just fine, right? > > And I read all linux-usb@vger email anyway... > > greg k-h I'm sorry if there is any misunderstanding. Because the code is under drivers/usb/core/hub.c, I found that in MAINTAINERS you are the maintainer of drivers/usb/*. so I think it's better to let you know the change. Thanks, Gavin Guo -- 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/
[tip:x86/vdso] x86, vdso: Get rid of the fake section mechanism
Commit-ID: da861e18ecccb5c126b9eb95ff720ce082a46286
Gitweb: http://git.kernel.org/tip/da861e18ecccb5c126b9eb95ff720ce082a46286
Author: Andy Lutomirski
AuthorDate: Thu, 10 Jul 2014 18:13:16 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 11 Jul 2014 16:58:07 -0700
x86, vdso: Get rid of the fake section mechanism
Now that we can tolerate extra things dangling off the end of the
vdso image, we can strip the vdso the old fashioned way rather than
using an overcomplicated custom stripping algorithm.
This is a partial reversion of:
6f121e5 x86, vdso: Reimplement vdso.so preparation in build-time C
Signed-off-by: Andy Lutomirski
Link:
http://lkml.kernel.org/r/50e01ed6dcc0575d20afd782f9fe98d5ee3e2d8a.1405040914.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin
---
arch/x86/vdso/Makefile| 16 +--
arch/x86/vdso/vdso-fakesections.c | 21
arch/x86/vdso/vdso2c.c| 116 +-
arch/x86/vdso/vdso2c.h| 202 +-
4 files changed, 126 insertions(+), 229 deletions(-)
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index 61b04fe..5a4affe 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -10,7 +10,7 @@ VDSO32-$(CONFIG_X86_32) := y
VDSO32-$(CONFIG_COMPAT):= y
# files to link into the vdso
-vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vdso-fakesections.o
+vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
# files to link into kernel
obj-y += vma.o
@@ -37,7 +37,8 @@ vdso_img_sodbg := $(vdso_img-y:%=vdso%.so.dbg)
obj-y += $(vdso_img_objs)
targets += $(vdso_img_cfiles)
targets += $(vdso_img_sodbg)
-.SECONDARY: $(vdso_img-y:%=$(obj)/vdso-image-%.c)
+.SECONDARY: $(vdso_img-y:%=$(obj)/vdso-image-%.c) \
+ $(vdso_img-y:%=$(obj)/vdso%.so)
export CPPFLAGS_vdso.lds += -P -C
@@ -54,10 +55,10 @@ hostprogs-y += vdso2c
quiet_cmd_vdso2c = VDSO2C $@
define cmd_vdso2c
- $(obj)/vdso2c $< $@
+ $(obj)/vdso2c $< $(<:%.dbg=%) $@
endef
-$(obj)/vdso-image-%.c: $(obj)/vdso%.so.dbg $(obj)/vdso2c FORCE
+$(obj)/vdso-image-%.c: $(obj)/vdso%.so.dbg $(obj)/vdso%.so $(obj)/vdso2c FORCE
$(call if_changed,vdso2c)
#
@@ -113,6 +114,10 @@ $(obj)/%-x32.o: $(obj)/%.o FORCE
targets += vdsox32.lds $(vobjx32s-y)
+$(obj)/%.so: OBJCOPYFLAGS := -S
+$(obj)/%.so: $(obj)/%.so.dbg
+ $(call if_changed,objcopy)
+
$(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s) FORCE
$(call if_changed,vdso)
@@ -134,7 +139,7 @@ override obj-dirs = $(dir $(obj)) $(obj)/vdso32/
targets += vdso32/vdso32.lds
targets += vdso32/note.o vdso32/vclock_gettime.o $(vdso32.so-y:%=vdso32/%.o)
-targets += vdso32/vclock_gettime.o vdso32/vdso-fakesections.o
+targets += vdso32/vclock_gettime.o
$(obj)/vdso32.o: $(vdso32-images:%=$(obj)/%)
@@ -156,7 +161,6 @@ $(vdso32-images:%=$(obj)/%.dbg): KBUILD_CFLAGS =
$(KBUILD_CFLAGS_32)
$(vdso32-images:%=$(obj)/%.dbg): $(obj)/vdso32-%.so.dbg: FORCE \
$(obj)/vdso32/vdso32.lds \
$(obj)/vdso32/vclock_gettime.o \
-$(obj)/vdso32/vdso-fakesections.o \
$(obj)/vdso32/note.o \
$(obj)/vdso32/%.o
$(call if_changed,vdso)
diff --git a/arch/x86/vdso/vdso-fakesections.c
b/arch/x86/vdso/vdso-fakesections.c
deleted file mode 100644
index aa5fbfa..000
--- a/arch/x86/vdso/vdso-fakesections.c
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Copyright 2014 Andy Lutomirski
- * Subject to the GNU Public License, v.2
- *
- * String table for loadable section headers. See vdso2c.h for why
- * this exists.
- */
-
-const char fake_shstrtab[] __attribute__((section(".fake_shstrtab"))) =
- ".hash\0"
- ".dynsym\0"
- ".dynstr\0"
- ".gnu.version\0"
- ".gnu.version_d\0"
- ".dynamic\0"
- ".rodata\0"
- ".fake_shstrtab\0" /* Yay, self-referential code. */
- ".note\0"
- ".eh_frame_hdr\0"
- ".eh_frame\0"
- ".text";
diff --git a/arch/x86/vdso/vdso2c.c b/arch/x86/vdso/vdso2c.c
index 22c54d0..8627db2 100644
--- a/arch/x86/vdso/vdso2c.c
+++ b/arch/x86/vdso/vdso2c.c
@@ -1,3 +1,53 @@
+/*
+ * vdso2c - A vdso image preparation tool
+ * Copyright (c) 2014 Andy Lutomirski and others
+ * Licensed under the GPL v2
+ *
+ * vdso2c requires stripped and unstripped input. It would be trivial
+ * to fully strip the input in here, but, for reasons described below,
+ * we need to write a section table. Doing this is more or less
+ * equivalent to dropping all non-allocatable sections, but it's
+ * easier to let objcopy handle that instead of doing it ourselves.
+ * If we ever need to do something fancier than what objcopy provides,
+ * it would be straightforward to add here.
+ *
+ * We're keep a section table for a few reasons:
+ *
+ * The Go runtime had a couple of bugs: it
Re: [patch 47/55] hangcheck-timer: Use ktime_get_raw_ns()
On Fri, Jul 11, 2014 at 01:45:08PM -, Thomas Gleixner wrote: > Use the nanoseconds based interface instead of converting timespecs. > > Signed-off-by: Thomas Gleixner > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman Acked-by: Greg Kroah-Hartman -- 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/
[tip:x86/vdso] x86, vdso: Move the vvar area before the vdso text
Commit-ID: e6577a7ce99a506b587bcd1d2cd803cb45119557
Gitweb: http://git.kernel.org/tip/e6577a7ce99a506b587bcd1d2cd803cb45119557
Author: Andy Lutomirski
AuthorDate: Thu, 10 Jul 2014 18:13:15 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 11 Jul 2014 16:57:51 -0700
x86, vdso: Move the vvar area before the vdso text
Putting the vvar area after the vdso text is rather complicated: it
only works of the total length of the vdso text mapping is known at
vdso link time, and the linker doesn't allow symbol addresses to
depend on the sizes of non-allocatable data after the PT_LOAD
segment.
Moving the vvar area before the vdso text will allow is to safely
map non-allocatable data after the vdso text, which is a nice
simplification.
Signed-off-by: Andy Lutomirski
Link:
http://lkml.kernel.org/r/156c78c0d93144ff1055a66493783b9e56813983.1405040914.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/vdso.h | 18 -
arch/x86/vdso/vdso-layout.lds.S | 44 ++---
arch/x86/vdso/vdso2c.c | 12 ++-
arch/x86/vdso/vdso2c.h | 25 ++-
arch/x86/vdso/vma.c | 20 ++-
5 files changed, 62 insertions(+), 57 deletions(-)
diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index 30be253..8021bd2 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -18,15 +18,15 @@ struct vdso_image {
unsigned long alt, alt_len;
- unsigned long sym_end_mapping; /* Total size of the mapping */
-
- unsigned long sym_vvar_page;
- unsigned long sym_hpet_page;
- unsigned long sym_VDSO32_NOTE_MASK;
- unsigned long sym___kernel_sigreturn;
- unsigned long sym___kernel_rt_sigreturn;
- unsigned long sym___kernel_vsyscall;
- unsigned long sym_VDSO32_SYSENTER_RETURN;
+ long sym_vvar_start; /* Negative offset to the vvar area */
+
+ long sym_vvar_page;
+ long sym_hpet_page;
+ long sym_VDSO32_NOTE_MASK;
+ long sym___kernel_sigreturn;
+ long sym___kernel_rt_sigreturn;
+ long sym___kernel_vsyscall;
+ long sym_VDSO32_SYSENTER_RETURN;
};
#ifdef CONFIG_X86_64
diff --git a/arch/x86/vdso/vdso-layout.lds.S b/arch/x86/vdso/vdso-layout.lds.S
index 9197544..de2c921 100644
--- a/arch/x86/vdso/vdso-layout.lds.S
+++ b/arch/x86/vdso/vdso-layout.lds.S
@@ -18,6 +18,25 @@
SECTIONS
{
+ /*
+* User/kernel shared data is before the vDSO. This may be a little
+* uglier than putting it after the vDSO, but it avoids issues with
+* non-allocatable things that dangle past the end of the PT_LOAD
+* segment.
+*/
+
+ vvar_start = . - 2 * PAGE_SIZE;
+ vvar_page = vvar_start;
+
+ /* Place all vvars at the offsets in asm/vvar.h. */
+#define EMIT_VVAR(name, offset) vvar_ ## name = vvar_page + offset;
+#define __VVAR_KERNEL_LDS
+#include
+#undef __VVAR_KERNEL_LDS
+#undef EMIT_VVAR
+
+ hpet_page = vvar_start + PAGE_SIZE;
+
. = SIZEOF_HEADERS;
.hash : { *(.hash) } :text
@@ -74,31 +93,6 @@ SECTIONS
.altinstructions: { *(.altinstructions) } :text
.altinstr_replacement : { *(.altinstr_replacement) } :text
- /*
-* The remainder of the vDSO consists of special pages that are
-* shared between the kernel and userspace. It needs to be at the
-* end so that it doesn't overlap the mapping of the actual
-* vDSO image.
-*/
-
- . = ALIGN(PAGE_SIZE);
- vvar_page = .;
-
- /* Place all vvars at the offsets in asm/vvar.h. */
-#define EMIT_VVAR(name, offset) vvar_ ## name = vvar_page + offset;
-#define __VVAR_KERNEL_LDS
-#include
-#undef __VVAR_KERNEL_LDS
-#undef EMIT_VVAR
-
- . = vvar_page + PAGE_SIZE;
-
- hpet_page = .;
- . = . + PAGE_SIZE;
-
- . = ALIGN(PAGE_SIZE);
- end_mapping = .;
-
/DISCARD/ : {
*(.discard)
*(.discard.*)
diff --git a/arch/x86/vdso/vdso2c.c b/arch/x86/vdso/vdso2c.c
index 238dbe82..22c54d0 100644
--- a/arch/x86/vdso/vdso2c.c
+++ b/arch/x86/vdso/vdso2c.c
@@ -20,9 +20,9 @@ const char *outfilename;
/* Symbols that we need in vdso2c. */
enum {
+ sym_vvar_start,
sym_vvar_page,
sym_hpet_page,
- sym_end_mapping,
sym_VDSO_FAKE_SECTION_TABLE_START,
sym_VDSO_FAKE_SECTION_TABLE_END,
};
@@ -38,9 +38,9 @@ struct vdso_sym {
};
struct vdso_sym required_syms[] = {
+ [sym_vvar_start] = {"vvar_start", true},
[sym_vvar_page] = {"vvar_page", true},
[sym_hpet_page] = {"hpet_page", true},
- [sym_end_mapping] = {"end_mapping", true},
[sym_VDSO_FAKE_SECTION_TABLE_START] = {
"VDSO_FAKE_SECTION_TABLE_START", false
},
@@ -96,9 +96,11 @@ extern void bad_put_le(void);
#define NSYMS
Re: [patch 36/55] misc: ioc4: Use ktime_get_ns()
On Fri, Jul 11, 2014 at 01:44:52PM -, Thomas Gleixner wrote: > Replace the ever recurring: > ts = ktime_get_ts(); > ns = timespec_to_ns(); > with > ns = ktime_get_ns(); > > Signed-off-by: Thomas Gleixner > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman Acked-off-by: Greg Kroah-Hartman -- 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] arch/x86/xen: Silence compiler warnings
On Jul 11, 2014 7:45 PM, Daniel Kiper wrote:
>
> On Fri, Jul 11, 2014 at 04:32:27PM -0400, Boris Ostrovsky wrote:
> > On 07/11/2014 04:10 PM, Daniel Kiper wrote:
> > >On Fri, Jul 11, 2014 at 04:03:46PM -0400, Boris Ostrovsky wrote:
> > >>On 07/11/2014 03:54 PM, Daniel Kiper wrote:
> > >>>Compiler complains in the following way when x86 32-bit kernel
> > >>>with Xen support is build:
> > >>>
> > >>> CC arch/x86/xen/enlighten.o
> > >>>arch/x86/xen/enlighten.c: In function ‘xen_start_kernel’:
> > >>>arch/x86/xen/enlighten.c:1726:3: warning: right shift count >= width of
> > >>>type [enabled by default]
> > >>>
> > >>>Such line contains following EFI initialization code:
> > >>>
> > >>>boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >>
> > >>>32);
> > >>>
> > >>>There is no issue if x86 64-bit kernel is build. However, 32-bit case
> > >>>generate warning (even if that code will not be executed because Xen
> > >>>does not work on 32-bit EFI platforms) due to __pa() returning unsigned
> > >>>long
> > >>>type which has 32-bits width. So move whole EFI initialization stuff
> > >>>to separate function and build its body conditionally to avoid above
> > >>>mentioned warning on x86 32-bit architecture.
> > >>>
> > >>>Signed-off-by: Daniel Kiper
> > >>>---
> > >>> arch/x86/xen/enlighten.c | 35 ++-
> > >>> 1 file changed, 22 insertions(+), 13 deletions(-)
> > >>>
> > >>>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > >>>index bc89647..6abec74 100644
> > >>>--- a/arch/x86/xen/enlighten.c
> > >>>+++ b/arch/x86/xen/enlighten.c
> > >>>@@ -1516,12 +1516,32 @@ static void __init
> > >>>xen_pvh_early_guest_init(void)
> > >>> #endif
> > >>> }
> > >>>+static void __init xen_efi_init(void)
> > >>>+{
> > >>>+#ifdef CONFIG_XEN_EFI
> > >>>+ efi_system_table_t *efi_systab_xen;
> > >>>+
> > >>>+ efi_systab_xen = xen_efi_probe();
> > >>>+
> > >>>+ if (efi_systab_xen == NULL)
> > >>>+ return;
> > >>>+
> > >>>+ strncpy((char *)_params.efi_info.efi_loader_signature, "Xen",
> > >>>+ sizeof(boot_params.efi_info.efi_loader_signature));
> > >>>+ boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> > >>>+ boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >>
> > >>>32);
> > >>>+
> > >>>+ set_bit(EFI_BOOT, );
> > >>>+ set_bit(EFI_PARAVIRT, );
> > >>>+ set_bit(EFI_64BIT, );
> > >>>+#endif
> > >>>+}
> > >>>+
> > >>> /* First C function to be called on Xen boot */
> > >>> asmlinkage __visible void __init xen_start_kernel(void)
> > >>> {
> > >>> struct physdev_set_iopl set_iopl;
> > >>> int rc;
> > >>>- efi_system_table_t *efi_systab_xen;
> > >>> if (!xen_start_info)
> > >>> return;
> > >>>@@ -1717,18 +1737,7 @@ asmlinkage __visible void __init
> > >>>xen_start_kernel(void)
> > >>> xen_setup_runstate_info(0);
> > >>>- efi_systab_xen = xen_efi_probe();
> > >>>-
> > >>>- if (efi_systab_xen) {
> > >>>- strncpy((char *)_params.efi_info.efi_loader_signature, "Xen",
> > >>>- sizeof(boot_params.efi_info.efi_loader_signature));
> > >>>- boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> > >>>- boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >>
> > >>>32);
> > >>>-
> > >>>- set_bit(EFI_BOOT, );
> > >>>- set_bit(EFI_PARAVIRT, );
> > >>>- set_bit(EFI_64BIT, );
> > >>>- }
> > >>>+ xen_efi_init();
> > >>I'd put ifdef CONFIG_XEN_EFI around the call instead of having it
> > >>inside the routine.
> > >Well, I thought about that a bit and I prefer function like Konrad.
> > >Could you agree with him which solution do you (as maintainers) prefer?
> > >
> >
> > I am not arguing against having a separate routine. All I am saying
> > is that calling xen_efi_init() when CONFIG_XEN_EFI is not defined
> > doesn't look logical. It will also add an unnecessary call (although
>
> Ahh... I misunderstood you. However, your proposal, as below:
>
> #ifdef CONFIG_XEN_EFI
> xen_efi_init();
> #endif
>
> does not solve the problem because this vulnerable shift will be still
> visible for compiler during x86 32-bit kernel build.
>
> > compiler may optimize it out).
>
> Please loot at arch/x86/xen/enlighten.c:xen_check_mwait() and
> arch/x86/xen/enlighten.c:xen_boot_params_init_edd() (probably
> there are more stuff like that around). As I can see this is fairly
> common solution and probably compiler cope with it quite well.
>
Those are some examples of some rather bad examples.
The way that is preferred in the Linux code is to have the ifdef in headers.
See
http://lxr.free-electrons.com/source/arch/x86/include/asm/xen/swiotlb-xen.h
Or
http://lxr.free-electrons.com/source/arch/x86/include/asm/xen/pci.h
You can create a similar file there and for the 32 bit implementation just make
an empty static function.
The 64 bit implementation has to be somewhere. Can it be in the Xen EFI file
which is only compiled on 64 bit
Re: [PATCH 1/6] x86-mce: Modify CMCI poll interval to adjust for small check_interval values.
On Fri, Jul 11, 2014 at 1:22 PM, Borislav Petkov wrote: > On Fri, Jul 11, 2014 at 11:56:11AM -0700, Havard Skinnemoen wrote: >> > * max number of CMCIs per second a system can sustain fine, i.e. the 100 >> > above >> >> What's the definition of "fine"? 1% performance hit? 10%? How can we >> make that decision without knowing how hard the users are pushing >> their systems? > > Those are definitely unchartered territories we're moving into so yes, > answering that won't be easy. > > Let's try it: if the anount of time we spend per second in the CMCI > handler becomes higher than the amount of time we spend polling for that > same second, then we might just as well poll and save us the interrupt > load. > > So, for example, say for 10ms poll rate and single poll duration of > 2ms, if time spent in CMCI exceeds 200ms for that second, we switch to > polling. Hypothetical numbers, of course. 200ms per second means we're using 20% of that CPU. I'd say that's definitely too much. But I like the general approach. > Can we measure it on every system? Probably not. So we need to > approximate it somehow. > >> >> > * total polling duration during storm, i.e. the 1 second above >> > >> > and if those are chosen generously for every system out there, then we >> > don't need to dynamically adjust the polling interval. >> >> I'm not sure how we can be generous when there's a tradeoff involved. >> If we make the interval "generously low", we end up hurting >> performance. if we make it "generously high", we'll lose information. > > Yeah, by "generous" I meant, choose values which fit all. But I realize > now that this is a dumb idea. Maybe we could measure it on each system, > read the TSC on CMCI entry and exit and thus get an average CMCI > duration... Sounds interesting. Some things that may need some more thought: 1. What percentage of CPU is OK to use before we consider it a storm? 2. How do we map that number to polling mode, where we may not see all the errors? If we get it wrong, we may end up bouncing at a very high rate. 3. If we go for a fixed polling rate, how do we make sure it doesn't require more CPU than what we determined in (1)? Havard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/2] irqchip: GIC: check and clear GIC interupt active status
For this version of GIC codes, kernel assumes that all the interrupt status of GIC is inactive. So the kernel does not check this when booting. This is no problem on must sitations. But when kdump is deplayed. And a panic occurs when a interrupt is being handled (may be PPI and SPI). We have no chance to write relative bit to GICC_EOIR. So this interrupt remains active. And GIC will not deliver this type interrupt to cpu interface. And the capture kernel may fail to boot becase of lacking of certain interrupt (such as timer interupt). I glanced over the GIC Architecture Specification, but did not find a simple way to deactive state of all interrupts. For GICv1, I can only deal with one abnormal interrupt state one time. For GICv2, I can deactive 32 one time. So guys, Do you know a better way to do that? Liu Hua (2): irqchip: gic: introduce ICPIDR2 register interface irqchip: GIC: introduce method to deactive interupts drivers/irqchip/irq-gic.c | 57 + include/linux/irqchip/arm-gic.h | 1 + 2 files changed, 58 insertions(+) -- 1.9.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] i2c: piix4: Continue probing for auxiliary SMBus without main
Some BIOS may only allow access to the AMD auxiliary SMBus - reserving
the main SMBus for system functions only. Probing should continue even
if the main bus is not available so at least the auxiliary can be added.
Signed-off-by: Daniel M. Weeks
---
This patch may warrant some discussion. I ran across this problem on an
AMD Hudson board where the main SMBus is hard-wired for debugging but
the auxiliary bus is exposed for expansion. Either purposefully or
because the BIOS is a little broken, loading this module used to result
in an ACPI conflict for the main bus and neither was usable. With the
patch I'm able to use the auxiliary bus regardless of the conflict on
the main bus. I'm not 100% convinced it's the correct fix - someone with
more ACPI experience than me is going to need to review this.
drivers/i2c/busses/i2c-piix4.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index a6f54ba..d4bac64 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -628,14 +628,16 @@ static int piix4_probe(struct pci_dev *dev, const struct
pci_device_id *id)
else
retval = piix4_setup(dev, id);
- /* If no main SMBus found, give up */
- if (retval < 0)
- return retval;
-
- /* Try to register main SMBus adapter, give up if we can't */
- retval = piix4_add_adapter(dev, retval, _main_adapter);
- if (retval < 0)
- return retval;
+ /* If no main SMBus found, do not give up
+* some BIOS purposely only expose aux bus */
+ if (retval < 0) {
+ dev_info(>dev, "No main SMBus; checking auxiliary\n");
+ } else {
+ /* Try to register main SMBus adapter, give up if we can't */
+ retval = piix4_add_adapter(dev, retval, _main_adapter);
+ if (retval < 0)
+ return retval;
+ }
/* Check for auxiliary SMBus on some AMD chipsets */
retval = -ENODEV;
--
Daniel M. Weeks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf, x86: Widen Haswell OFFCORE mask
From: Andi Kleen
Haswell supports more bits in the offcore_rsp_* MSRs than Sandy
Bridge. Previously the Haswell code was using the Sandy Bridge
extra register definitions, which prevented users from setting
all of these bits. This in term did not allow to set some valid
SNOOP_* bits, among others.
I allowed all bits the CPU does not #GP on. This is ok because
it's protected by a model check.
Add a new extra_regs table for Haswell and use. Except for the
widened mask it is identical to Sandy Bridge.
Signed-off-by: Andi Kleen
---
arch/x86/kernel/cpu/perf_event_intel.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index adb02aa..5d41e2b 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -189,6 +189,14 @@ static struct extra_reg intel_snbep_extra_regs[]
__read_mostly = {
EVENT_EXTRA_END
};
+static struct extra_reg intel_hsw_extra_regs[] __read_mostly = {
+ /* must define OFFCORE_RSP_X first, see intel_fixup_er() */
+ INTEL_UEVENT_EXTRA_REG(0x01b7, MSR_OFFCORE_RSP_0, 0x3f8fffull,
RSP_0),
+ INTEL_UEVENT_EXTRA_REG(0x01bb, MSR_OFFCORE_RSP_1, 0x3f8fffull,
RSP_1),
+ INTEL_UEVENT_PEBS_LDLAT_EXTRA_REG(0x01cd),
+ EVENT_EXTRA_END
+};
+
EVENT_ATTR_STR(mem-loads, mem_ld_nhm,
"event=0x0b,umask=0x10,ldlat=3");
EVENT_ATTR_STR(mem-loads, mem_ld_snb, "event=0xcd,umask=0x1,ldlat=3");
EVENT_ATTR_STR(mem-stores, mem_st_snb, "event=0xcd,umask=0x2");
@@ -2504,7 +2512,7 @@ __init int intel_pmu_init(void)
x86_pmu.event_constraints = intel_hsw_event_constraints;
x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
- x86_pmu.extra_regs = intel_snb_extra_regs;
+ x86_pmu.extra_regs = intel_hsw_extra_regs;
x86_pmu.pebs_aliases = intel_pebs_aliases_snb;
/* all extra regs are per-cpu when HT is on */
x86_pmu.er_flags |= ERF_HAS_RSP_1;
--
1.9.3
--
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 04/11] perf, tools: Allow events with dot
From: Andi Kleen
The Intel events use a dot to separate event name and unit mask.
Allow dot in names in the scanner, and remove special handling
of dot as EOF. Also remove the hack in jevents to replace dot
with underscore. This way dotted events can be specified
directly by the user.
I'm not fully sure this change to the scanner is correct
(what was the dot special case good for?), but I haven't
found anything that breaks with it so far at least.
Acked-by: Namhyung Kim
Signed-off-by: Andi Kleen
---
tools/perf/util/parse-events.l | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 3432995..709fa3b 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -81,7 +81,7 @@ num_dec [0-9]+
num_hex0x[a-fA-F0-9]+
num_raw_hex[a-fA-F0-9]+
name [a-zA-Z_*?][a-zA-Z0-9_*?]*
-name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?]*
+name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?.]*
/* If you add a modifier you need to update check_modifier() */
modifier_event [ukhpGHSD]+
modifier_bp[rwx]{1,3}
@@ -119,7 +119,6 @@ modifier_bp [rwx]{1,3}
return PE_EVENT_NAME;
}
-. |
<>{
BEGIN(INITIAL); yyless(0);
}
--
1.9.3
--
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 03/11] perf, tools, list: Update perf list to output descriptions
From: Andi Kleen
Add support to perf list to print aliases with descriptions.
Support word wrapping for descriptions.
Fix up the sorting code to put aliases with descriptions
last.
Signed-off-by: Andi Kleen
---
tools/perf/util/pmu.c | 84 +--
1 file changed, 68 insertions(+), 16 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index f9c7046..baec090 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -737,11 +737,51 @@ static char *format_alias_or(char *buf, int len, struct
perf_pmu *pmu,
return buf;
}
-static int cmp_string(const void *a, const void *b)
+struct pair {
+ char *name;
+ char *desc;
+};
+
+static int cmp_pair(const void *a, const void *b)
+{
+ const struct pair *as = a;
+ const struct pair *bs = b;
+
+ /* Put downloaded event list last */
+ if (!!as->desc != !!bs->desc)
+ return !!as->desc - !!bs->desc;
+ return strcmp(as->name, bs->name);
+}
+
+static void wordwrap(char *s, int start, int max, int corr)
+{
+ int column = start;
+ int n;
+
+ while (*s) {
+ int wlen = strcspn(s, " \t");
+
+ if (column + wlen >= max && column > start) {
+ printf("\n%*s", start, "");
+ column = start + corr;
+ }
+ n = printf("%s%.*s", column > start ? " " : "", wlen, s);
+ if (n <= 0)
+ break;
+ s += wlen;
+ column += n;
+ while (isspace(*s))
+ s++;
+ }
+}
+
+static int get_columns(void)
{
- const char * const *as = a;
- const char * const *bs = b;
- return strcmp(*as, *bs);
+ /*
+* Should ask the terminal with TIOCGWINSZ here, but we
+* need the original fd before the pager.
+*/
+ return 79;
}
void print_pmu_events(const char *event_glob, bool name_only)
@@ -751,21 +791,24 @@ void print_pmu_events(const char *event_glob, bool
name_only)
char buf[1024];
int printed = 0;
int len, j;
- char **aliases;
+ struct pair *aliases;
+ int numdesc = 0;
+ int columns = get_columns();
pmu = NULL;
len = 0;
while ((pmu = perf_pmu__scan(pmu)) != NULL)
list_for_each_entry(alias, >aliases, list)
len++;
- aliases = malloc(sizeof(char *) * len);
+ aliases = malloc(sizeof(struct pair) * len);
if (!aliases)
return;
pmu = NULL;
j = 0;
while ((pmu = perf_pmu__scan(pmu)) != NULL)
list_for_each_entry(alias, >aliases, list) {
- char *name = format_alias(buf, sizeof(buf), pmu, alias);
+ char *name = alias->desc ? alias->name :
+ format_alias(buf, sizeof(buf), pmu, alias);
bool is_cpu = !strcmp(pmu->name, "cpu");
if (event_glob != NULL &&
@@ -773,22 +816,31 @@ void print_pmu_events(const char *event_glob, bool
name_only)
(!is_cpu && strglobmatch(alias->name,
event_glob
continue;
- aliases[j] = name;
- if (is_cpu && !name_only)
- aliases[j] = format_alias_or(buf, sizeof(buf),
- pmu, alias);
- aliases[j] = strdup(aliases[j]);
+ aliases[j].name = name;
+ if (is_cpu && !name_only && !alias->desc)
+ aliases[j].name = format_alias_or(buf,
+ sizeof(buf),
+ pmu, alias);
+ aliases[j].name = strdup(aliases[j].name);
+ aliases[j].desc = alias->desc;
j++;
}
len = j;
- qsort(aliases, len, sizeof(char *), cmp_string);
+ qsort(aliases, len, sizeof(struct pair), cmp_pair);
for (j = 0; j < len; j++) {
if (name_only) {
- printf("%s ", aliases[j]);
+ printf("%s ", aliases[j].name);
continue;
}
- printf(" %-50s [Kernel PMU event]\n", aliases[j]);
- zfree([j]);
+ if (aliases[j].desc) {
+ if (numdesc++ == 0 && printed)
+ printf("\n");
+ printf(" %-50s [", aliases[j].name);
+ wordwrap(aliases[j].desc, 53, columns, 1);
+ printf("]\n");
+ } else
+
[PATCH 08/11] perf, tools: Query terminal width and use in perf list
From: Andi Kleen
Automatically adapt the now wider and word wrapped perf list
output to wider terminals. This requires querying the terminal
before the auto pager takes over, and exporting this
information from the pager subsystem.
Acked-by: Namhyung Kim
Signed-off-by: Andi Kleen
---
tools/perf/util/cache.h | 1 +
tools/perf/util/pager.c | 15 +++
tools/perf/util/pmu.c | 12 ++--
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index 7b176dd..07527d6 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -31,6 +31,7 @@ extern void setup_pager(void);
extern const char *pager_program;
extern int pager_in_use(void);
extern int pager_use_color;
+int pager_get_columns(void);
char *alias_lookup(const char *alias);
int split_cmdline(char *cmdline, const char ***argv);
diff --git a/tools/perf/util/pager.c b/tools/perf/util/pager.c
index 31ee02d..9761202 100644
--- a/tools/perf/util/pager.c
+++ b/tools/perf/util/pager.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include "sigchain.h"
+#include
/*
* This is split up from the rest of git so that we can do
@@ -8,6 +9,7 @@
*/
static int spawned_pager;
+static int pager_columns;
static void pager_preexec(void)
{
@@ -47,9 +49,12 @@ static void wait_for_pager_signal(int signo)
void setup_pager(void)
{
const char *pager = getenv("PERF_PAGER");
+ struct winsize sz;
if (!isatty(1))
return;
+ if (ioctl(1, TIOCGWINSZ, ) == 0)
+ pager_columns = sz.ws_col;
if (!pager) {
if (!pager_program)
perf_config(perf_default_config, NULL);
@@ -98,3 +103,13 @@ int pager_in_use(void)
env = getenv("PERF_PAGER_IN_USE");
return env ? perf_config_bool("PERF_PAGER_IN_USE", env) : 0;
}
+
+int pager_get_columns(void)
+{
+ char *s;
+
+ s = getenv("COLUMNS");
+ if (s)
+ return atoi(s);
+ return (pager_columns ? pager_columns : 80) - 2;
+}
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index fa21319..8714f9a 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -9,6 +9,7 @@
#include "pmu.h"
#include "parse-events.h"
#include "cpumap.h"
+#include "cache.h"
#include "jevents.h"
const char *json_file;
@@ -789,15 +790,6 @@ static void wordwrap(char *s, int start, int max, int corr)
}
}
-static int get_columns(void)
-{
- /*
-* Should ask the terminal with TIOCGWINSZ here, but we
-* need the original fd before the pager.
-*/
- return 79;
-}
-
void print_pmu_events(const char *event_glob, bool name_only)
{
struct perf_pmu *pmu;
@@ -807,7 +799,7 @@ void print_pmu_events(const char *event_glob, bool
name_only)
int len, j;
struct pair *aliases;
int numdesc = 0;
- int columns = get_columns();
+ int columns = pager_get_columns();
pmu = NULL;
len = 0;
--
1.9.3
--
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: Add support for full Intel event lists v7
All feedback addressed. Hopefully ready for merge now. [v2: Review feedback addressed and some minor improvements] [v3: More review feedback addressed and handle test failures better. Ported to latest tip/core.] [v4: Addressed Namhyung's feedback] [v5: Rebase to latest tree. Minor description update.] [v6: Rebase. Add acked by from Namhyung and address feedback. Some minor fixes. Should be good to go now I hope. The period patch was dropped, as that is already handled. I added an extra patch for a --quiet argument for perf list] [v7: Address Jiri's feedback. Various changes and some patches were split. perf download uses curl now instead of wget.] perf has high level events which are useful in many cases. However there are some tuning situations where low level events in the CPU are needed. Traditionally this required specifying the event in raw form (very awkward) or using non standard frontends like ocperf or patching in libpfm. Intel CPUs can have very large event files (Haswell has ~336 core events, much more if you add uncore or all the offcore combinations), which is too large to describe through the kernel interface. It would require tying up significant amounts of unswappable memory for this. oprofile always had separate event list files that were maintained by the CPU vendors. The oprofile events were shipped with the tool. The Intel events get updated regularly, for example to add references to the specification updates or add new events. Unfortunately oprofile usually did not keep up with these updates, so the events in oprofile were often out of date. In addition it ties up quite a bit of disk space, mostly for CPUs you don't have. This patch kit implements another mechanism that avoids these problems. Intel releases the event lists for CPUs in a standardized JSON format on a download server. I implemented an automatic downloader to get the event file for the current CPU. The events are stored in ~/.cache/pmu-events. Then perf adds a parser that converts the JSON format into perf event aliases, which then can be used directly as any other perf event. The parsing is done using a simple existing JSON library. The events are still abstracted for perf, but the abstraction mechanism is through the downloaded file instead of through the kernel. The JSON format and perf parser has some minor Intelisms, but they are simple and small and optional. It's easy to extend, so it would be possible to use it for other CPUs too, add different pmu attributes, and add new download sites to the downloader tool. Currently only core events are supported, uncore may come at a later point. No kernel changes, all code in perf user tools only. Some of the parser files are partially shared with separate event parser library and are thus 2-clause BSD licensed. Patches also available from git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/json Example output: % perf download Downloading models file Downloading readme.txt Downloading events file % perf list ... br_inst_exec.all_branches [Speculative and retired branches] br_inst_exec.all_conditional [Speculative and retired macro-conditional branches] br_inst_exec.all_direct_jmp[Speculative and retired macro-unconditional branches excluding calls and indirects] ... 333 more new events ... % perf stat -e br_inst_exec.all_direct_jmp true Performance counter stats for 'true': 6,817 cpu/br_inst_exec.all_direct_jmp/ 0.003503212 seconds time elapsed One nice feature is that a pointer to the specification update is now included in the description, which will hopefully clear up many problems: % perf list ... mem_load_uops_l3_hit_retired.xsnp_hit [Retired load uops which data sources were L3 and cross-core snoop hits in on-pkg core cache. Supports address when precise. Spec update: HSM26, HSM30 (Precise event)] ... -Andi -- 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] perf, x86: Revamp PEBS event selection
From: Andi Kleen
The basic idea is that it does not make sense to list all PEBS
events individually. The list is very long, sometimes outdated
and the hardware doesn't need it. If an event does not support
PEBS it will just not count, there is no security issue.
This vastly simplifies the PEBS event selection. It also
speeds up the scheduling because the scheduler doesn't
have to walk as many constraints.
Bugs fixed:
- We do not allow setting forbidden flags with PEBS anymore
(SDM 18.9.4), except for the special cycle event.
This is done using a new constraint macro that also
matches on the event flags.
- We now allow DataLA on all Haswell events, not just
a small subset. In general all PEBS events that tag memory
accesses support DataLA on Haswell. Otherwise the reported
address is just zero. This allows address profiling
on vastly more events.
- We did not allow all PEBS events on Haswell:
We were missing some valid subevents in d1-d2 (MEM_LOAD_UOPS_RETIRED.*,
MEM_LOAD_UOPS_RETIRED_L3_HIT_RETIRED.*)
This includes the changes proposed by Stephane earlier and obsoletes
his patchkit (except for some changes on pre Sandy Bridge/Silvermont
CPUs)
I only did Sandy Bridge and Silvermont and later so far, mostly because these
are the parts I could directly confirm the hardware behavior with hardware
architects. Also I do not believe the older CPUs have any
missing events in their PEBS list, so there's no pressing
need to change them.
I did not implement the flag proposed by Peter to allow
setting forbidden flags. If really needed this could
be implemented on to of this patch.
Cc: eran...@google.com
v2: Fix broken store events on SNB/IVB (Stephane Eranian)
v3: More fixes. Rename some arguments (Stephane Eranian)
Update description.
Signed-off-by: Andi Kleen
---
arch/x86/include/asm/perf_event.h | 8 +++
arch/x86/kernel/cpu/perf_event.h | 18 +--
arch/x86/kernel/cpu/perf_event_intel_ds.c | 88 +++
3 files changed, 39 insertions(+), 75 deletions(-)
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index 8249df4..8dfc9fd 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -51,6 +51,14 @@
ARCH_PERFMON_EVENTSEL_EDGE | \
ARCH_PERFMON_EVENTSEL_INV | \
ARCH_PERFMON_EVENTSEL_CMASK)
+#define X86_ALL_EVENT_FLAGS\
+ (ARCH_PERFMON_EVENTSEL_EDGE | \
+ARCH_PERFMON_EVENTSEL_INV |\
+ARCH_PERFMON_EVENTSEL_CMASK | \
+ARCH_PERFMON_EVENTSEL_ANY |\
+ARCH_PERFMON_EVENTSEL_PIN_CONTROL |\
+HSW_IN_TX |\
+HSW_IN_TX_CHECKPOINTED)
#define AMD64_RAW_EVENT_MASK \
(X86_RAW_EVENT_MASK | \
AMD64_EVENTSEL_EVENT)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index a22a34e9..8f32af0 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -262,16 +262,24 @@ struct cpu_hw_events {
EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK)
#define INTEL_PLD_CONSTRAINT(c, n) \
- __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \
+ __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_LDLAT)
#define INTEL_PST_CONSTRAINT(c, n) \
- __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \
+ __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST)
-/* DataLA version of store sampling without extra enable bit. */
-#define INTEL_PST_HSW_CONSTRAINT(c, n) \
- __EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \
+/* Event constraint, but match on all event flags too. */
+#define INTEL_FLAGS_EVENT_CONSTRAINT(c, n) \
+ EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS)
+
+/* Check only flags, but allow all event/umask */
+#define INTEL_ALL_EVENT_CONSTRAINT(code, n)\
+ EVENT_CONSTRAINT(code, n, X86_ALL_EVENT_FLAGS)
+
+/* Same as above, but enable DataLA */
+#define INTEL_ALL_EVENT_CONSTRAINT_DATALA(code, n) \
+ __EVENT_CONSTRAINT(code, n, X86_ALL_EVENT_FLAGS, \
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST_HSW)
/*
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 980970c..64b4be9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -567,28 +567,10 @@ struct event_constraint
intel_atom_pebs_event_constraints[] = {
};
struct event_constraint intel_slm_pebs_event_constraints[] = {
- INTEL_UEVENT_CONSTRAINT(0x0103, 0x1), /* REHABQ.LD_BLOCK_ST_FORWARD_PS
*/
- INTEL_UEVENT_CONSTRAINT(0x0803, 0x1), /* REHABQ.LD_SPLITS_PS */
- INTEL_UEVENT_CONSTRAINT(0x0204, 0x1), /*
[PATCH 2/2] perf, x86: Don't mark DataLA addresses as store
From: Andi Kleen Haswell supports reporting the data address for a range of PEBS events, including: UOPS_RETIRED.ALL MEM_UOPS_RETIRED.STLB_MISS_LOADS MEM_UOPS_RETIRED.STLB_MISS_STORES MEM_UOPS_RETIRED.LOCK_LOADS MEM_UOPS_RETIRED.SPLIT_LOADS MEM_UOPS_RETIRED.SPLIT_STORES MEM_UOPS_RETIRED.ALL_LOADS MEM_UOPS_RETIRED.ALL_STORES MEM_LOAD_UOPS_RETIRED.L1_HIT MEM_LOAD_UOPS_RETIRED.L2_HIT MEM_LOAD_UOPS_RETIRED.L3_HIT MEM_LOAD_UOPS_RETIRED.L1_MISS MEM_LOAD_UOPS_RETIRED.L2_MISS MEM_LOAD_UOPS_RETIRED.L3_MISS MEM_LOAD_UOPS_RETIRED.HIT_LFB MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_MISS MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_HIT MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_HITM MEM_LOAD_UOPS_L3_HIT_RETIRED.XSNP_NONE MEM_LOAD_UOPS_L3_MISS_RETIRED.LOCAL_DRAM This facility was already enabled earlier with the original Haswell perf changes. However these addresses were always reports as stores by perf, which is wrong, as they could be loads too. The hardware does not distinguish loads and stores for these instructions, so there's no (cheap) way for the profiler to find out. Change the type to PERF_MEM_OP_NA instead. Signed-off-by: Andi Kleen --- arch/x86/kernel/cpu/perf_event_intel_ds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c b/arch/x86/kernel/cpu/perf_event_intel_ds.c index 64b4be9..13baa7c 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_ds.c +++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c @@ -114,7 +114,7 @@ static u64 precise_store_data_hsw(struct perf_event *event, u64 status) u64 cfg = event->hw.config & INTEL_ARCH_EVENT_MASK; dse.val = 0; - dse.mem_op = PERF_MEM_OP_STORE; + dse.mem_op = PERF_MEM_OP_NA; dse.mem_lvl = PERF_MEM_LVL_NA; /* -- 1.9.3 -- 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 07/11] perf, tools: Add perf download to download event files
From: Andi Kleen Add a downloader to automatically download the right files from a download site. This is implemented as a script calling curl, similar to perf archive. The perf driver automatically calls the right binary. The downloader is extensible, but currently only implements an Intel event download. It would be straightforward to add other sites too for other vendors. The downloaded event files are put into ~/.cache/pmu-events, where the builtin event parser in util/* can find them automatically. v2: Use ~/.cache v3: Check for wget. Some cleanups. v4: Improve manpage. v5: Due to popular demand use curl instead of wget. Acked-by: Namhyung Kim Signed-off-by: Andi Kleen --- tools/perf/Documentation/perf-download.txt | 31 tools/perf/Documentation/perf-list.txt | 12 ++- tools/perf/Makefile.perf | 5 ++- tools/perf/perf-download.sh| 57 ++ 4 files changed, 103 insertions(+), 2 deletions(-) create mode 100644 tools/perf/Documentation/perf-download.txt create mode 100755 tools/perf/perf-download.sh diff --git a/tools/perf/Documentation/perf-download.txt b/tools/perf/Documentation/perf-download.txt new file mode 100644 index 000..9e5b28e --- /dev/null +++ b/tools/perf/Documentation/perf-download.txt @@ -0,0 +1,31 @@ +perf-download(1) +=== + +NAME + +perf-download - Download event files for current CPU. + +SYNOPSIS + +[verse] +'perf download' [vendor-family-model] + +DESCRIPTION +--- +This command automatically downloads the event list for the current CPU and +stores them in $XDG_CACHE_HOME/pmu-events (or $HOME/.cache/pmu-events). +The other tools automatically look for them there. The CPU can be also +specified at the command line. + +The downloading is done using http through wget, which needs +to be installed. When behind a firewall the proxies +may also need to be set up using "export https_proxy=" + +The user should regularly call this to download updated event lists +for the current CPU. + +Note the downloaded files are stored per user, so if perf is +used as both normal user and with sudo the event files may +also need to be moved to root's home directory with +sudo mkdir /root/.cache ; sud cp -r ~/.cache/pmu-events /root/.cache +after downloading. diff --git a/tools/perf/Documentation/perf-list.txt b/tools/perf/Documentation/perf-list.txt index da03992..d241b5c 100644 --- a/tools/perf/Documentation/perf-list.txt +++ b/tools/perf/Documentation/perf-list.txt @@ -63,6 +63,16 @@ Sampling). Examples to use IBS: perf record -a -e r076:p ... # same as -e cpu-cycles:p perf record -a -e r0C1:p ... # use ibs op counting micro-ops +PER CPU EVENT LISTS +--- + +For some CPUs (particularly modern Intel CPUs) "perf download" can +download additional CPU specific event definitions, which then +become visible in perf list and available in the other perf tools. + +This obsoletes the raw event description method described below +for most cases. + RAW HARDWARE EVENT DESCRIPTOR - Even when an event is not available in a symbolic form within perf right now, @@ -125,6 +135,6 @@ types specified. SEE ALSO linkperf:perf-stat[1], linkperf:perf-top[1], -linkperf:perf-record[1], +linkperf:perf-record[1], linkperf:perf-download[1], http://www.intel.com/Assets/PDF/manual/253669.pdf[Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide], http://support.amd.com/us/Processor_TechDocs/24593_APM_v2.pdf[AMD64 Architecture Programmer’s Manual Volume 2: System Programming] diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 0016d1a..0600425 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -126,6 +126,7 @@ PYRF_OBJS = SCRIPT_SH = SCRIPT_SH += perf-archive.sh +SCRIPT_SH += perf-download.sh grep-libs = $(filter -l%,$(1)) strip-libs = $(filter-out -l%,$(1)) @@ -877,6 +878,8 @@ install-bin: all install-gtk $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(perfexec_instdir_SQ)' $(call QUIET_INSTALL, perf-archive) \ $(INSTALL) $(OUTPUT)perf-archive -t '$(DESTDIR_SQ)$(perfexec_instdir_SQ)' + $(call QUIET_INSTALL, perf-download) \ + $(INSTALL) $(OUTPUT)perf-download -t '$(DESTDIR_SQ)$(perfexec_instdir_SQ)' ifndef NO_LIBPERL $(call QUIET_INSTALL, perl-scripts) \ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(perfexec_instdir_SQ)/scripts/perl/Perf-Trace-Util/lib/Perf/Trace'; \ @@ -922,7 +925,7 @@ config-clean: @$(MAKE) -C config/feature-checks clean >/dev/null clean: $(LIBTRACEEVENT)-clean $(LIBAPIKFS)-clean config-clean - $(call QUIET_CLEAN, core-objs) $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) $(LIB_FILE) $(OUTPUT)perf-archive $(OUTPUT)perf.o $(LANG_BINDINGS) $(GTK_OBJS) + $(call QUIET_CLEAN, core-objs) $(RM) $(LIB_OBJS) $(BUILTIN_OBJS)
[PATCH 06/11] perf, tools: Automatically look for event file name for cpu
From: Andi Kleen
When no JSON event file is specified automatically look
for a suitable file in ~/.cache/pmu-events. A "perf download" can
automatically add files there for the current CPUs.
This does not include the actual event files with perf,
but they can be automatically downloaded instead
(implemented in the next patch)
This has the advantage that the events can be always uptodate,
because they are freshly downloaded. In oprofile we always
had problems with out of date or incomplete events files.
The event file format is per architecture, but can be
extended for other architectures.
v2: Supports XDG_CACHE_HOME and defaults to ~/.cache/pmu-events
v3: Minor updates and handle EVENTMAP.
v4: Unify with header.c. Now uses CPUID directly.
Acked-by: Namhyung Kim
Signed-off-by: Andi Kleen
---
tools/perf/arch/x86/util/header.c | 19 ---
tools/perf/util/jevents.c | 40 +++
tools/perf/util/jevents.h | 1 +
tools/perf/util/pmu.c | 2 +-
4 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/tools/perf/arch/x86/util/header.c
b/tools/perf/arch/x86/util/header.c
index 146d12a..76e0ece 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -5,6 +5,7 @@
#include
#include "../../util/header.h"
+#include "../../util/jevents.h"
static inline void
cpuid(unsigned int op, unsigned int *a, unsigned int *b, unsigned int *c,
@@ -19,8 +20,8 @@ cpuid(unsigned int op, unsigned int *a, unsigned int *b,
unsigned int *c,
: "a" (op));
}
-int
-get_cpuid(char *buffer, size_t sz)
+static int
+__get_cpuid(char *buffer, size_t sz, const char *fmt)
{
unsigned int a, b, c, d, lvl;
int family = -1, model = -1, step = -1;
@@ -48,7 +49,7 @@ get_cpuid(char *buffer, size_t sz)
if (family >= 0x6)
model += ((a >> 16) & 0xf) << 4;
}
- nb = scnprintf(buffer, sz, "%s,%u,%u,%u$", vendor, family, model, step);
+ nb = scnprintf(buffer, sz, fmt, vendor, family, model, step);
/* look for end marker to ensure the entire data fit */
if (strchr(buffer, '$')) {
@@ -57,3 +58,15 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
}
+
+int get_cpuid(char *buffer, size_t sz)
+{
+ return __get_cpuid(buffer, sz, "%s,%u,%u,%u$");
+}
+
+char *get_cpu_str(void)
+{
+ char *buf = malloc(128);
+ __get_cpuid(buf, 128, "%s-%d-%X-core");
+ return buf;
+}
diff --git a/tools/perf/util/jevents.c b/tools/perf/util/jevents.c
index a23f57f..418502a 100644
--- a/tools/perf/util/jevents.c
+++ b/tools/perf/util/jevents.c
@@ -38,6 +38,44 @@
#include "json.h"
#include "jevents.h"
+__attribute__((weak)) char *get_cpu_str(void)
+{
+ return NULL;
+}
+
+static const char *json_default_name(void)
+{
+ char *cache;
+ char *idstr = get_cpu_str();
+ char *res = NULL;
+ char *home = NULL;
+ char *emap;
+
+ emap = getenv("EVENTMAP");
+ if (emap) {
+ if (access(emap, R_OK) == 0)
+ return emap;
+ if (asprintf(, "%s-core", emap) < 0)
+ return NULL;
+ }
+
+ cache = getenv("XDG_CACHE_HOME");
+ if (!cache) {
+ home = getenv("HOME");
+ if (!home || asprintf(, "%s/.cache", home) < 0)
+ goto out;
+ }
+ if (cache && idstr)
+ res = mkpath("%s/pmu-events/%s.json",
+cache,
+idstr);
+ if (home)
+ free(cache);
+out:
+ free(idstr);
+ return res;
+}
+
static void addfield(char *map, char **dst, const char *sep,
const char *a, jsmntok_t *bt)
{
@@ -170,6 +208,8 @@ int json_events(const char *fn,
int i, j, len;
char *map;
+ if (!fn)
+ fn = json_default_name();
tokens = parse_json(fn, , , );
if (!tokens)
return -EIO;
diff --git a/tools/perf/util/jevents.h b/tools/perf/util/jevents.h
index fbc4549..86a94dd 100644
--- a/tools/perf/util/jevents.h
+++ b/tools/perf/util/jevents.h
@@ -4,5 +4,6 @@
int json_events(const char *fn,
int (*func)(void *data, char *name, char *event, char *desc),
void *data);
+char *get_cpu_str(void);
#endif
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 9f154af..fa21319 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -433,7 +433,7 @@ static struct perf_pmu *pmu_lookup(const char *name)
if (pmu_aliases(name, ))
return NULL;
- if (!strcmp(name, "cpu") && json_file)
+ if (!strcmp(name, "cpu"))
json_events(json_file, add_alias, );
if (pmu_type(name, ))
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH 11/11] perf, tools: Add a --no-desc flag to perf list
From: Andi Kleen
Add a --no-desc flag to perf list to not print the event descriptions
that were earlier added for JSON events. This may be useful to
get a less crowded listing.
It's still default to print descriptions as that is the more useful
default for most users.
Before:
% perf list
...
baclears.any [Counts the total number
when the front end is
resteered, mainly when
the BPU cannot provide a
correct prediction and
this is corrected by other
branch handling
mechanisms at the front end]
br_inst_exec.all_branches [Speculative and retired
branches]
After:
% perf list --no-desc
...
baclears.any [Kernel PMU event]
br_inst_exec.all_branches [Kernel PMU event]
v2: Rename --quiet to --no-desc. Add option to man page.
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-list.txt | 5 -
tools/perf/builtin-list.c | 14 +-
tools/perf/util/parse-events.c | 4 ++--
tools/perf/util/parse-events.h | 2 +-
tools/perf/util/pmu.c | 4 ++--
tools/perf/util/pmu.h | 2 +-
6 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/tools/perf/Documentation/perf-list.txt
b/tools/perf/Documentation/perf-list.txt
index d241b5c..7a6b25d 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -8,7 +8,7 @@ perf-list - List all symbolic event types
SYNOPSIS
[verse]
-'perf list' [hw|sw|cache|tracepoint|pmu|event_glob]
+'perf list' [--no-desc] [hw|sw|cache|tracepoint|pmu|event_glob]
DESCRIPTION
---
@@ -23,6 +23,9 @@ automatically downloaded with perf download.
The JSON event file can be also specified with the EVENTMAP environment
variable.
+--no-desc::
+Don't print descriptions.
+
[[EVENT_MODIFIERS]] EVENT MODIFIERS
---
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 086c96f..68752a1 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -16,16 +16,20 @@
#include "util/pmu.h"
#include "util/parse-options.h"
+static bool desc_flag = true;
+
int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
{
int i;
const struct option list_options[] = {
OPT_STRING(0, "events-file", _file, "json file",
"Read event json file"),
+ OPT_BOOLEAN('d', "desc", _flag,
+ "Print extra event descriptions. --no-desc to not
print."),
OPT_END()
};
const char * const list_usage[] = {
- "perf list [hw|sw|cache|tracepoint|pmu|event_glob]",
+ "perf list [--events-file FILE] [--no-desc]
[hw|sw|cache|tracepoint|pmu|event_glob]",
NULL
};
@@ -35,7 +39,7 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
setup_pager();
if (argc == 0) {
- print_events(NULL, false);
+ print_events(NULL, false, !desc_flag);
return 0;
}
@@ -54,15 +58,15 @@ int cmd_list(int argc, const char **argv, const char
*prefix __maybe_unused)
strcmp(argv[i], "hwcache") == 0)
print_hwcache_events(NULL, false);
else if (strcmp(argv[i], "pmu") == 0)
- print_pmu_events(NULL, false);
+ print_pmu_events(NULL, false, !desc_flag);
else if (strcmp(argv[i], "--raw-dump") == 0)
- print_events(NULL, true);
+ print_events(NULL, true, !desc_flag);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
if (sep == NULL) {
- print_events(argv[i], false);
+ print_events(argv[i], false, !desc_flag);
continue;
}
sep_idx = sep - argv[i];
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 1e15df1..e2badf3 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1231,7 +1231,7 @@ static void print_symbol_events(const char *event_glob,
unsigned type,
/*
* Print the help text for the event symbols:
*/
-void print_events(const char *event_glob, bool name_only)
+void print_events(const char *event_glob, bool name_only, bool quiet)
{
if (!name_only) {
printf("\n");
@@ -1246,7 +1246,7 @@ void print_events(const char *event_glob, bool name_only)
print_hwcache_events(event_glob, name_only);
[PATCH 05/11] perf, tools: Add support for reading JSON event files
From: Andi Kleen
Add a parser for Intel style JSON event files. This allows
to use an Intel event list directly with perf. The Intel
event lists can be quite large and are too big to store
in unswappable kernel memory.
The parser code knows how to convert the JSON fields
to perf fields. The conversion code is straight forward.
It knows (very little) Intel specific information, and can be easily
extended to handle fields for other CPUs.
The parser code is partially shared with an independent parsing
library, which is 2-clause BSD licenced. To avoid any conflicts I marked
those files as BSD licenced too. As part of perf they become GPLv2.
The events are handled using the existing alias machinery.
We output the BriefDescription in perf list.
Right now the json file can be specified as an argument
to perf stat/record/list. Followon patches will automate this.
JSON files look like this:
[
{
"EventCode": "0x00",
"UMask": "0x01",
"EventName": "INST_RETIRED.ANY",
"BriefDescription": "Instructions retired from execution.",
"PublicDescription": "Instructions retired from execution.",
"Counter": "Fixed counter 1",
"CounterHTOff": "Fixed counter 1",
"SampleAfterValue": "203",
"MSRIndex": "0",
"MSRValue": "0",
"TakenAlone": "0",
"CounterMask": "0",
"Invert": "0",
"AnyThread": "0",
"EdgeDetect": "0",
"PEBS": "0",
"PRECISE_STORE": "0",
"Errata": "null",
"Offcore": "0"
}
]
v2: Address review feedback. Rename option to --event-files
v3: Add JSON example
v4: Update manpages.
v5: Don't remove dot in fixname. Fix compile error. Add include
protection. Comment realloc.
Acked-by: Namhyung Kim
Signed-off-by: Andi Kleen
---
tools/perf/Documentation/perf-list.txt | 12 +-
tools/perf/Documentation/perf-record.txt | 8 +-
tools/perf/Documentation/perf-stat.txt | 8 +-
tools/perf/Makefile.perf | 2 +
tools/perf/builtin-list.c| 2 +
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-stat.c| 2 +
tools/perf/util/jevents.c| 246 +++
tools/perf/util/jevents.h| 8 +
tools/perf/util/pmu.c| 14 ++
tools/perf/util/pmu.h| 2 +
11 files changed, 303 insertions(+), 4 deletions(-)
create mode 100644 tools/perf/util/jevents.c
create mode 100644 tools/perf/util/jevents.h
diff --git a/tools/perf/Documentation/perf-list.txt
b/tools/perf/Documentation/perf-list.txt
index 6fce6a6..da03992 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -15,8 +15,16 @@ DESCRIPTION
This command displays the symbolic event types which can be selected in the
various perf commands with the -e option.
-[[EVENT_MODIFIERS]]
-EVENT MODIFIERS
+OPTIONS
+---
+--events-file=::
+Specify JSON event list file to use for parsing events. Files can be
+automatically downloaded with perf download.
+The JSON event file can be also specified with the EVENTMAP environment
+variable.
+
+
+[[EVENT_MODIFIERS]] EVENT MODIFIERS
---
Events can optionally have a modifer by appending a colon and one or
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index d460049..62c27fc 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -214,6 +214,12 @@ if combined with -a or -C options.
After starting the program, wait msecs before measuring. This is useful to
filter out the startup phase of the program, which is often very different.
+--events-file=::
+Specify JSON event list file to use for parsing events. Must be specified
+before the -e option. Files can be automatically downloaded with perf download.
+The JSON event file can be also specified with the EVENTMAP environment
+variable.
+
SEE ALSO
-linkperf:perf-stat[1], linkperf:perf-list[1]
+linkperf:perf-stat[1], linkperf:perf-list[1], linkperf:perf-download[1]
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 29ee857..cd9b62f 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -142,6 +142,12 @@ filter out the startup phase of the program, which is
often very different.
Print statistics of transactional execution if supported.
+--events-file=::
+Specify JSON event list file to use for parsing events. Must be specified
before
+the -e option. Files can be automatically downloaded with perf download.
+The JSON event file can be also specified with the EVENTMAP environment
+variable.
+
EXAMPLES
@@ -162,4 +168,4 @@ $ perf stat -- make -j
SEE ALSO
-linkperf:perf-top[1], linkperf:perf-list[1]
+linkperf:perf-top[1], linkperf:perf-list[1], linkperf:perf-download[1]
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 1cd32c5..0016d1a 100644
---
[PATCH 10/11] perf, tools, test: Add test case for alias and JSON parsing
From: Andi Kleen
Add a simple test case to perf test that runs perf download and parses
all the available events, including json events.
This needs adding an all event iterator to pmu.c
v2: Rename identifiers
v3: Only iterate cpu pmu to avoid bogus errors.
Move pmu iterator to extra patch
Acked-by: Namhyung Kim
Signed-off-by: Andi Kleen
---
tools/perf/Makefile.perf| 1 +
tools/perf/tests/builtin-test.c | 4
tools/perf/tests/tests.h| 1 +
3 files changed, 6 insertions(+)
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 0600425..6adb37f 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -419,6 +419,7 @@ endif
LIB_OBJS += $(OUTPUT)tests/code-reading.o
LIB_OBJS += $(OUTPUT)tests/sample-parsing.o
LIB_OBJS += $(OUTPUT)tests/parse-no-sample-id-all.o
+LIB_OBJS += $(OUTPUT)tests/aliases.o
ifndef NO_DWARF_UNWIND
ifeq ($(ARCH),$(filter $(ARCH),x86 arm))
LIB_OBJS += $(OUTPUT)tests/dwarf-unwind.o
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 6f8b01b..bb37ac2 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -154,6 +154,10 @@ static struct test {
.func = test__hists_cumulate,
},
{
+ .desc = "Test parsing JSON aliases",
+ .func = test__aliases,
+ },
+ {
.func = NULL,
},
};
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index ed64790..ab92ad9 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -48,6 +48,7 @@ int test__mmap_thread_lookup(void);
int test__thread_mg_share(void);
int test__hists_output(void);
int test__hists_cumulate(void);
+int test__aliases(void);
#if defined(__x86_64__) || defined(__i386__) || defined(__arm__)
#ifdef HAVE_DWARF_UNWIND_SUPPORT
--
1.9.3
--
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 09/11] perf, tools: Add a new pmu interface to iterate over all events
From: Andi Kleen
With calling a callback. To be used in test code added in the next
patch.
Signed-off-by: Andi Kleen
---
tools/perf/util/pmu.c | 18 ++
tools/perf/util/pmu.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 8714f9a..397e400 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -869,3 +869,21 @@ bool pmu_have_event(const char *pname, const char *name)
}
return false;
}
+
+int pmu_iterate_events(int (*func)(const char *pmu, const char *name))
+{
+ int ret = 0;
+ struct perf_pmu *pmu;
+ struct perf_pmu_alias *alias;
+
+ perf_pmu__find("cpu"); /* Load PMUs */
+ pmu = NULL;
+ while ((pmu = perf_pmu__scan(pmu)) != NULL) {
+ list_for_each_entry(alias, >aliases, list) {
+ ret = func(pmu->name, alias->name);
+ if (ret != 0)
+ break;
+ }
+ }
+ return ret;
+}
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 583d21e..87a1da4 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -47,5 +47,7 @@ bool pmu_have_event(const char *pname, const char *name);
int perf_pmu__test(void);
+int pmu_iterate_events(int (*func)(const char *, const char *name));
+
extern const char *json_file;
#endif /* __PMU_H */
--
1.9.3
--
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 01/11] perf, tools: Add jsmn `jasmine' JSON parser
From: Andi Kleen
I need a JSON parser. This adds the simplest JSON
parser I could find -- Serge Zaitsev's jsmn `jasmine' --
to the perf library. I merely converted it to (mostly)
Linux style and added support for non 0 terminated input.
The parser is quite straight forward and does not
copy any data, just returns tokens with offsets
into the input buffer. So it's relatively efficient
and simple to use.
The code is not fully checkpatch clean, but I didn't
want to completely fork the upstream code.
Original source: http://zserge.bitbucket.org/jsmn.html
In addition I added a simple wrapper that mmaps a json
file and provides some straight forward access functions.
Used in follow-on patches to parse event files.
v2: Address review feedback.
v3: Minor checkpatch fixes.
Acked-by: Namhyung Kim
Signed-off-by: Andi Kleen
---
tools/perf/Makefile.perf | 4 +
tools/perf/util/jsmn.c | 313 +++
tools/perf/util/jsmn.h | 67 ++
tools/perf/util/json.c | 155 +++
tools/perf/util/json.h | 13 ++
5 files changed, 552 insertions(+)
create mode 100644 tools/perf/util/jsmn.c
create mode 100644 tools/perf/util/jsmn.h
create mode 100644 tools/perf/util/json.c
create mode 100644 tools/perf/util/json.h
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 9670a16..1cd32c5 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -300,6 +300,8 @@ LIB_H += ui/progress.h
LIB_H += ui/util.h
LIB_H += ui/ui.h
LIB_H += util/data.h
+LIB_H += util/jsmn.h
+LIB_H += util/json.h
LIB_OBJS += $(OUTPUT)util/abspath.o
LIB_OBJS += $(OUTPUT)util/alias.o
@@ -373,6 +375,8 @@ LIB_OBJS += $(OUTPUT)util/stat.o
LIB_OBJS += $(OUTPUT)util/record.o
LIB_OBJS += $(OUTPUT)util/srcline.o
LIB_OBJS += $(OUTPUT)util/data.o
+LIB_OBJS += $(OUTPUT)util/jsmn.o
+LIB_OBJS += $(OUTPUT)util/json.o
LIB_OBJS += $(OUTPUT)ui/setup.o
LIB_OBJS += $(OUTPUT)ui/helpline.o
diff --git a/tools/perf/util/jsmn.c b/tools/perf/util/jsmn.c
new file mode 100644
index 000..11d1fa1
--- /dev/null
+++ b/tools/perf/util/jsmn.c
@@ -0,0 +1,313 @@
+/*
+ * Copyright (c) 2010 Serge A. Zaitsev
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Slightly modified by AK to not assume 0 terminated input.
+ */
+
+#include
+#include "jsmn.h"
+
+/*
+ * Allocates a fresh unused token from the token pool.
+ */
+static jsmntok_t *jsmn_alloc_token(jsmn_parser *parser,
+ jsmntok_t *tokens, size_t num_tokens)
+{
+ jsmntok_t *tok;
+
+ if ((unsigned)parser->toknext >= num_tokens)
+ return NULL;
+ tok = [parser->toknext++];
+ tok->start = tok->end = -1;
+ tok->size = 0;
+ return tok;
+}
+
+/*
+ * Fills token type and boundaries.
+ */
+static void jsmn_fill_token(jsmntok_t *token, jsmntype_t type,
+ int start, int end)
+{
+ token->type = type;
+ token->start = start;
+ token->end = end;
+ token->size = 0;
+}
+
+/*
+ * Fills next available token with JSON primitive.
+ */
+static jsmnerr_t jsmn_parse_primitive(jsmn_parser *parser, const char *js,
+ size_t len,
+ jsmntok_t *tokens, size_t num_tokens)
+{
+ jsmntok_t *token;
+ int start;
+
+ start = parser->pos;
+
+ for (; parser->pos < len; parser->pos++) {
+ switch (js[parser->pos]) {
+#ifndef JSMN_STRICT
+ /*
+* In strict mode primitive must be followed by ","
+* or "}" or "]"
+*/
+ case ':':
+#endif
+ case '\t':
+ case '\r':
+ case '\n':
+ case ' ':
+ case ',':
+ case ']':
+ case '}':
+ goto found;
+ default:
+ break;
+
Re: [PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform
On Sat, Jul 12, 2014 at 07:32:34AM +0800, Gavin Guo wrote: > Hi all, > > On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo wrote: > > Hi Sarah and Mathias, > > > > As the discussion in > > http://comments.gmane.org/gmane.linux.usb.general/107011, > > I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk > > can't work in SuperSpeed after several times of hotplug. After doing some > > experiments and bisection, I found the bug is caused by > > 41e7e056cdc662f704fa9262e5c6e213b4ab45dd (USB: Allow USB 3.0 ports to be > > disabled.). And the bug can be fixed by not executing the > > hub_usb3_port_disable() function. I also found that the port status is > > already in RxDetect before setting the port to Disabled in > > hub_usb3_port_disable() function. So, there are 2 ways to fix the bug: > > > > 1) Check if the Vendor/Device id is [1022:7814] at the beginning of > > hub_usb3_port_disable() function. If yes, return without executing the > > remaining code. > > > > 2) Check if the port status is already in RxDetect, if yes, return without > > executing the remaining code. > > > > The second method seems more reasonable, so the patch is the implementation > > of the second one. But it will affect more platforms and I don't know if > > there'll be any negative result. Otherwise, if the first one is correct, > > I can reimplement a new one. > > > > I'm appreciated if you can give me some advice, or if there is any thing I > > missed. > > > > Thanks, > > Gavin > > > > Gavin Guo (1): > > usb: Check if port status is equal to RxDetect > > > > drivers/usb/core/hub.c | 19 +++ > > 1 file changed, 19 insertions(+) > > > > -- > > 2.0.0 > > > > Add Greg k-h to the list. Why? Mathias can handle this just fine, right? And I read all linux-usb@vger email anyway... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/11] perf, tools: Add support for text descriptions of events and alias add
From: Andi Kleen
Change pmu.c to allow descriptions of events and add interfaces
to add aliases at runtime from another file. To be used by jevents in
a followon patch
Acked-by: Namhyung Kim
v2: Move perf list changes to other patch.
Signed-off-by: Andi Kleen
---
tools/perf/util/pmu.c | 43 ++-
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 7a811eb..f9c7046 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -14,6 +14,7 @@
struct perf_pmu_alias {
char *name;
+ char *desc;
struct list_head terms;
struct list_head list;
char unit[UNIT_MAX_LEN+1];
@@ -171,17 +172,12 @@ error:
return -1;
}
-static int perf_pmu__new_alias(struct list_head *list, char *dir, char *name,
FILE *file)
+static int __perf_pmu__new_alias(struct list_head *list, char *name,
+char *dir, char *desc, char *val)
{
struct perf_pmu_alias *alias;
- char buf[256];
int ret;
- ret = fread(buf, 1, sizeof(buf), file);
- if (ret == 0)
- return -EINVAL;
- buf[ret] = 0;
-
alias = malloc(sizeof(*alias));
if (!alias)
return -ENOMEM;
@@ -190,24 +186,45 @@ static int perf_pmu__new_alias(struct list_head *list,
char *dir, char *name, FI
alias->scale = 1.0;
alias->unit[0] = '\0';
- ret = parse_events_terms(>terms, buf);
+ ret = parse_events_terms(>terms, val);
if (ret) {
+ pr_err("Cannot parse alias %s: %d\n", val, ret);
free(alias);
return ret;
}
alias->name = strdup(name);
- /*
-* load unit name and scale if available
-*/
- perf_pmu__parse_unit(alias, dir, name);
- perf_pmu__parse_scale(alias, dir, name);
+ if (dir) {
+ /*
+* load unit name and scale if available
+*/
+ perf_pmu__parse_unit(alias, dir, name);
+ perf_pmu__parse_scale(alias, dir, name);
+ }
+
+ alias->desc = desc ? strdup(desc) : NULL;
list_add_tail(>list, list);
return 0;
}
+static int perf_pmu__new_alias(struct list_head *list,
+ char *dir,
+ char *name,
+ FILE *file)
+{
+ char buf[256];
+ int ret;
+
+ ret = fread(buf, 1, sizeof(buf), file);
+ if (ret == 0)
+ return -EINVAL;
+ buf[ret] = 0;
+
+ return __perf_pmu__new_alias(list, name, dir, NULL, buf);
+}
+
/*
* Process all the sysfs attributes located under the directory
* specified in 'dir' parameter.
--
1.9.3
--
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 V1 00/30] Enable memoryless node on x86 platforms
On 07/11/2014 01:20 PM, Andi Kleen wrote: > Greg KH writes: > >> On Fri, Jul 11, 2014 at 10:29:56AM +0200, Peter Zijlstra wrote: >>> On Fri, Jul 11, 2014 at 03:37:17PM +0800, Jiang Liu wrote: Any comments are welcomed! >>> >>> Why would anybody _ever_ have a memoryless node? That's ridiculous. >> >> I'm with Peter here, why would this be a situation that we should even >> support? Are there machines out there shipping like this? > > We've always had memory nodes. > > A classic case in the old days was a two socket system where someone > didn't populate any DIMMs on the second socket. > > There are other cases too. > Yes, like a node controller-based system where the system can be populated with either memory cards or CPU cards, for example. Now you can have both memoryless nodes and memory-only nodes... Memory-only nodes also happen in real life. In some cases they are done by permanently putting low-frequency CPUs to sleep for their memory controllers. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/2] irqchip: GIC: introduce ICPIDR2 register interface
Peripheral ID2 Register provides a four-bit architecturally-defined architecture revision field. So we can identify the GIC verison from this register. It is useful sometimes. Signed-off-by: Liu Hua --- include/linux/irqchip/arm-gic.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h index 45e2d8c..872a562 100644 --- a/include/linux/irqchip/arm-gic.h +++ b/include/linux/irqchip/arm-gic.h @@ -38,6 +38,7 @@ #define GIC_DIST_SOFTINT 0xf00 #define GIC_DIST_SGI_PENDING_CLEAR 0xf10 #define GIC_DIST_SGI_PENDING_SET 0xf20 +#define GIC_DIST_ICPIDR2 0xfe8 #define GICH_HCR 0x0 #define GICH_VTR 0x4 -- 1.9.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/1] rcutorture: set executable bit and drop bash from Usage
This patch is on top of the previous changes. Set the executable bit on test scripts config2frag.sh and kvm.sh Since #!/bin/bash is set in all the scripts, drop it from the usage line as the scripts can be invoked directly. Signed-off-by: Pranith Kumar --- tools/testing/selftests/rcutorture/bin/config2frag.sh | 2 +- tools/testing/selftests/rcutorture/bin/configcheck.sh | 2 +- tools/testing/selftests/rcutorture/bin/configinit.sh | 2 +- tools/testing/selftests/rcutorture/bin/kvm-build.sh| 2 +- tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh | 2 +- tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh | 2 +- tools/testing/selftests/rcutorture/bin/kvm-recheck.sh | 2 +- tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 2 +- tools/testing/selftests/rcutorture/bin/kvm.sh | 2 +- tools/testing/selftests/rcutorture/bin/parse-build.sh | 3 +-- tools/testing/selftests/rcutorture/bin/parse-console.sh| 3 +-- tools/testing/selftests/rcutorture/bin/parse-torture.sh| 3 +-- 12 files changed, 12 insertions(+), 15 deletions(-) mode change 100644 => 100755 tools/testing/selftests/rcutorture/bin/config2frag.sh mode change 100644 => 100755 tools/testing/selftests/rcutorture/bin/kvm.sh diff --git a/tools/testing/selftests/rcutorture/bin/config2frag.sh b/tools/testing/selftests/rcutorture/bin/config2frag.sh old mode 100644 new mode 100755 index 4e394ef..56f51ae --- a/tools/testing/selftests/rcutorture/bin/config2frag.sh +++ b/tools/testing/selftests/rcutorture/bin/config2frag.sh @@ -1,5 +1,5 @@ #!/bin/bash -# Usage: bash config2frag.sh < .config > configfrag +# Usage: config2frag.sh < .config > configfrag # # Converts the "# CONFIG_XXX is not set" to "CONFIG_XXX=n" so that the # resulting file becomes a legitimate Kconfig fragment. diff --git a/tools/testing/selftests/rcutorture/bin/configcheck.sh b/tools/testing/selftests/rcutorture/bin/configcheck.sh index 6173ed5..eee31e2 100755 --- a/tools/testing/selftests/rcutorture/bin/configcheck.sh +++ b/tools/testing/selftests/rcutorture/bin/configcheck.sh @@ -1,5 +1,5 @@ #!/bin/bash -# Usage: bash configcheck.sh .config .config-template +# Usage: configcheck.sh .config .config-template # # 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 diff --git a/tools/testing/selftests/rcutorture/bin/configinit.sh b/tools/testing/selftests/rcutorture/bin/configinit.sh index d8f7418..15f1a17 100755 --- a/tools/testing/selftests/rcutorture/bin/configinit.sh +++ b/tools/testing/selftests/rcutorture/bin/configinit.sh @@ -1,6 +1,6 @@ #!/bin/bash # -# bash configinit.sh config-spec-file [ build output dir ] +# Usage: configinit.sh config-spec-file [ build output dir ] # # Create a .config file from the spec file. Run from the kernel source tree. # Exits with 0 if all went well, with 1 if all went well but the config diff --git a/tools/testing/selftests/rcutorture/bin/kvm-build.sh b/tools/testing/selftests/rcutorture/bin/kvm-build.sh index e4bfb91..00cb0db 100755 --- a/tools/testing/selftests/rcutorture/bin/kvm-build.sh +++ b/tools/testing/selftests/rcutorture/bin/kvm-build.sh @@ -2,7 +2,7 @@ # # Build a kvm-ready Linux kernel from the tree in the current directory. # -# Usage: bash kvm-build.sh config-template build-dir more-configs +# Usage: kvm-build.sh config-template build-dir more-configs # # 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 diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh index 30cbb63..43f7640 100755 --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh +++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh @@ -2,7 +2,7 @@ # # Analyze a given results directory for locktorture progress. # -# Usage: bash kvm-recheck-lock.sh resdir +# Usage: kvm-recheck-lock.sh resdir # # 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 diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh b/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh index 6e94a5e..d6cc07f 100755 --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh +++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh @@ -2,7 +2,7 @@ # # Analyze a given results directory for rcutorture progress. # -# Usage: bash kvm-recheck-rcu.sh resdir +# Usage: kvm-recheck-rcu.sh resdir # # 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 diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh b/tools/testing/selftests/rcutorture/bin/kvm-recheck.sh index 3482b3f..4f5b20f 100755 ---
Re: [PATCH 2/2] arch/x86/xen: Silence compiler warnings
On Fri, Jul 11, 2014 at 04:32:27PM -0400, Boris Ostrovsky wrote:
> On 07/11/2014 04:10 PM, Daniel Kiper wrote:
> >On Fri, Jul 11, 2014 at 04:03:46PM -0400, Boris Ostrovsky wrote:
> >>On 07/11/2014 03:54 PM, Daniel Kiper wrote:
> >>>Compiler complains in the following way when x86 32-bit kernel
> >>>with Xen support is build:
> >>>
> >>> CC arch/x86/xen/enlighten.o
> >>>arch/x86/xen/enlighten.c: In function ‘xen_start_kernel’:
> >>>arch/x86/xen/enlighten.c:1726:3: warning: right shift count >= width of
> >>>type [enabled by default]
> >>>
> >>>Such line contains following EFI initialization code:
> >>>
> >>>boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);
> >>>
> >>>There is no issue if x86 64-bit kernel is build. However, 32-bit case
> >>>generate warning (even if that code will not be executed because Xen
> >>>does not work on 32-bit EFI platforms) due to __pa() returning unsigned
> >>>long
> >>>type which has 32-bits width. So move whole EFI initialization stuff
> >>>to separate function and build its body conditionally to avoid above
> >>>mentioned warning on x86 32-bit architecture.
> >>>
> >>>Signed-off-by: Daniel Kiper
> >>>---
> >>> arch/x86/xen/enlighten.c | 35 ++-
> >>> 1 file changed, 22 insertions(+), 13 deletions(-)
> >>>
> >>>diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >>>index bc89647..6abec74 100644
> >>>--- a/arch/x86/xen/enlighten.c
> >>>+++ b/arch/x86/xen/enlighten.c
> >>>@@ -1516,12 +1516,32 @@ static void __init xen_pvh_early_guest_init(void)
> >>> #endif
> >>> }
> >>>+static void __init xen_efi_init(void)
> >>>+{
> >>>+#ifdef CONFIG_XEN_EFI
> >>>+ efi_system_table_t *efi_systab_xen;
> >>>+
> >>>+ efi_systab_xen = xen_efi_probe();
> >>>+
> >>>+ if (efi_systab_xen == NULL)
> >>>+ return;
> >>>+
> >>>+ strncpy((char *)_params.efi_info.efi_loader_signature, "Xen",
> >>>+ sizeof(boot_params.efi_info.efi_loader_signature));
> >>>+ boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> >>>+ boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >>
> >>>32);
> >>>+
> >>>+ set_bit(EFI_BOOT, );
> >>>+ set_bit(EFI_PARAVIRT, );
> >>>+ set_bit(EFI_64BIT, );
> >>>+#endif
> >>>+}
> >>>+
> >>> /* First C function to be called on Xen boot */
> >>> asmlinkage __visible void __init xen_start_kernel(void)
> >>> {
> >>> struct physdev_set_iopl set_iopl;
> >>> int rc;
> >>>- efi_system_table_t *efi_systab_xen;
> >>> if (!xen_start_info)
> >>> return;
> >>>@@ -1717,18 +1737,7 @@ asmlinkage __visible void __init
> >>>xen_start_kernel(void)
> >>> xen_setup_runstate_info(0);
> >>>- efi_systab_xen = xen_efi_probe();
> >>>-
> >>>- if (efi_systab_xen) {
> >>>- strncpy((char *)_params.efi_info.efi_loader_signature,
> >>>"Xen",
> >>>-
> >>>sizeof(boot_params.efi_info.efi_loader_signature));
> >>>- boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
> >>>- boot_params.efi_info.efi_systab_hi =
> >>>(__u32)(__pa(efi_systab_xen) >> 32);
> >>>-
> >>>- set_bit(EFI_BOOT, );
> >>>- set_bit(EFI_PARAVIRT, );
> >>>- set_bit(EFI_64BIT, );
> >>>- }
> >>>+ xen_efi_init();
> >>I'd put ifdef CONFIG_XEN_EFI around the call instead of having it
> >>inside the routine.
> >Well, I thought about that a bit and I prefer function like Konrad.
> >Could you agree with him which solution do you (as maintainers) prefer?
> >
>
> I am not arguing against having a separate routine. All I am saying
> is that calling xen_efi_init() when CONFIG_XEN_EFI is not defined
> doesn't look logical. It will also add an unnecessary call (although
Ahh... I misunderstood you. However, your proposal, as below:
#ifdef CONFIG_XEN_EFI
xen_efi_init();
#endif
does not solve the problem because this vulnerable shift will be still
visible for compiler during x86 32-bit kernel build.
> compiler may optimize it out).
Please loot at arch/x86/xen/enlighten.c:xen_check_mwait() and
arch/x86/xen/enlighten.c:xen_boot_params_init_edd() (probably
there are more stuff like that around). As I can see this is fairly
common solution and probably compiler cope with it quite well.
Have a nice weekend,
Daniel
--
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] HID: i2c-hid: call the hid driver's suspend and resume callbacks
Currently, the i2c-hid driver does not call the suspend, resume, and
reset_resume callbacks in the hid_driver struct when those events occur.
This means that HID drivers for i2c-hid devices will not be able to execute
commands which may be needed during suspend or resume. One example is when a
touchpad using the hid-multitouch driver gets reset by i2c-hid coming out of
resume. Since the reset_resume callback never gets called the device is never
put back into the correct input mode. This patch calls the suspend and resume
callbacks and tries to duplicate the functionality of the usb-hid driver.
Signed-off-by: Andrew Duggan
Signed-off-by: Vincent Huang
---
Hi Benjamin,
This is the patch which Vincent and I came up with to fix the behavior which we
were seeing with touchpads not being operational after resuming. We only use
the reset_resume callback since i2c_hid_resume is always doing a hardware reset
and it doesn't seem like there is a condition in which the standard resume
callback would be appropriate. Also, is a full hardware reset always needed
when resuming?
drivers/hid/i2c-hid/i2c-hid.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 21aafc8..747d544 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -1054,21 +1054,29 @@ static int i2c_hid_remove(struct i2c_client *client)
static int i2c_hid_suspend(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_hid *ihid = i2c_get_clientdata(client);
+ struct hid_device *hid = ihid->hid;
+ int ret = 0;
disable_irq(client->irq);
if (device_may_wakeup(>dev))
enable_irq_wake(client->irq);
+ if (hid->driver && hid->driver->suspend)
+ ret = hid->driver->suspend(hid, PMSG_SUSPEND);
+
/* Save some power */
i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
- return 0;
+ return ret;
}
static int i2c_hid_resume(struct device *dev)
{
int ret;
struct i2c_client *client = to_i2c_client(dev);
+ struct i2c_hid *ihid = i2c_get_clientdata(client);
+ struct hid_device *hid = ihid->hid;
enable_irq(client->irq);
ret = i2c_hid_hwreset(client);
@@ -1078,6 +1086,11 @@ static int i2c_hid_resume(struct device *dev)
if (device_may_wakeup(>dev))
disable_irq_wake(client->irq);
+ if (hid->driver && hid->driver->reset_resume) {
+ ret = hid->driver->reset_resume(hid);
+ return ret;
+ }
+
return 0;
}
#endif
--
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] kernel:dma : fix coding style errors
Fixed coding style errors.
Signed-off-by: Ionut Alexa
---
kernel/dma.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/dma.c b/kernel/dma.c
index 6c6262f..ae9ba17 100644
--- a/kernel/dma.c
+++ b/kernel/dma.c
@@ -66,7 +66,7 @@ static struct dma_chan dma_chan_busy[MAX_DMA_CHANNELS] = {
* @dmanr: DMA channel number
* @device_id: reserving device ID string, used in /proc/dma
*/
-int request_dma(unsigned int dmanr, const char * device_id)
+int request_dma(unsigned int dmanr, const char *device_id)
{
if (dmanr >= MAX_DMA_CHANNELS)
return -EINVAL;
@@ -87,12 +87,12 @@ int request_dma(unsigned int dmanr, const char * device_id)
void free_dma(unsigned int dmanr)
{
if (dmanr >= MAX_DMA_CHANNELS) {
- printk(KERN_WARNING "Trying to free DMA%d\n", dmanr);
+ pr_warn("Trying to free DMA%d\n", dmanr);
return;
}
if (xchg(_chan_busy[dmanr].lock, 0) == 0) {
- printk(KERN_WARNING "Trying to free free DMA%d\n", dmanr);
+ pr_warn("Trying to free free DMA%d\n", dmanr);
return;
}
@@ -152,9 +152,10 @@ static int __init proc_dma_init(void)
return 0;
}
-__initcall(proc_dma_init);
+device_initcall(proc_dma_init);
#endif
EXPORT_SYMBOL(request_dma);
EXPORT_SYMBOL(free_dma);
EXPORT_SYMBOL(dma_spin_lock);
+
--
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 1/1] rcutorture: use bash shell for all the test scripts
On Fri, Jul 11, 2014 at 7:23 PM, wrote: > On Fri, Jul 11, 2014 at 05:31:27PM -0400, Pranith Kumar wrote: >> Some of the scripts encode a default /bin/sh shell. On systems which use >> dash as >> default shell, these scripts fail as they are bash scripts. I encountered >> this >> while testing the sprintf() changes on a Debian system where dash is the >> default >> shell. >> >> This commit changes all such uses to use bash explicitly. > > Good catch. > > Since these all have #! lines, can you please set the executable bit on > any that don't have it set (looks like just config2frag.sh and kvm.sh), > and then change the Usage lines to drop the shell entirely and just > invoke the program directly? OK. I will send that as a separate patch. > >> Signed-off-by: Pranith Kumar > > With the above changed (perhaps in a separate patch): > Reviewed-by: Josh Triplett > >> tools/testing/selftests/rcutorture/bin/config2frag.sh | 4 ++-- >> tools/testing/selftests/rcutorture/bin/configcheck.sh | 4 ++-- >> tools/testing/selftests/rcutorture/bin/configinit.sh | 4 ++-- >> tools/testing/selftests/rcutorture/bin/kvm-build.sh| 2 +- >> tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh | 2 +- >> tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh | 2 +- >> tools/testing/selftests/rcutorture/bin/kvm-recheck.sh | 2 +- >> tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 2 +- >> tools/testing/selftests/rcutorture/bin/kvm.sh | 2 +- >> tools/testing/selftests/rcutorture/bin/parse-build.sh | 4 ++-- >> tools/testing/selftests/rcutorture/bin/parse-console.sh| 4 ++-- >> tools/testing/selftests/rcutorture/bin/parse-torture.sh| 4 ++-- >> 12 files changed, 18 insertions(+), 18 deletions(-) >> >> diff --git a/tools/testing/selftests/rcutorture/bin/config2frag.sh >> b/tools/testing/selftests/rcutorture/bin/config2frag.sh >> index 9f9ffcd..4e394ef 100644 >> --- a/tools/testing/selftests/rcutorture/bin/config2frag.sh >> +++ b/tools/testing/selftests/rcutorture/bin/config2frag.sh >> @@ -1,5 +1,5 @@ >> -#!/bin/sh >> -# Usage: sh config2frag.sh < .config > configfrag >> +#!/bin/bash >> +# Usage: bash config2frag.sh < .config > configfrag >> # >> # Converts the "# CONFIG_XXX is not set" to "CONFIG_XXX=n" so that the >> # resulting file becomes a legitimate Kconfig fragment. >> diff --git a/tools/testing/selftests/rcutorture/bin/configcheck.sh >> b/tools/testing/selftests/rcutorture/bin/configcheck.sh >> index d686537..6173ed5 100755 >> --- a/tools/testing/selftests/rcutorture/bin/configcheck.sh >> +++ b/tools/testing/selftests/rcutorture/bin/configcheck.sh >> @@ -1,5 +1,5 @@ >> -#!/bin/sh >> -# Usage: sh configcheck.sh .config .config-template >> +#!/bin/bash >> +# Usage: bash configcheck.sh .config .config-template >> # >> # 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 >> diff --git a/tools/testing/selftests/rcutorture/bin/configinit.sh >> b/tools/testing/selftests/rcutorture/bin/configinit.sh >> index 9c3f3d3..d8f7418 100755 >> --- a/tools/testing/selftests/rcutorture/bin/configinit.sh >> +++ b/tools/testing/selftests/rcutorture/bin/configinit.sh >> @@ -1,6 +1,6 @@ >> -#!/bin/sh >> +#!/bin/bash >> # >> -# sh configinit.sh config-spec-file [ build output dir ] >> +# bash configinit.sh config-spec-file [ build output dir ] >> # >> # Create a .config file from the spec file. Run from the kernel source >> tree. >> # Exits with 0 if all went well, with 1 if all went well but the config >> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-build.sh >> b/tools/testing/selftests/rcutorture/bin/kvm-build.sh >> index 7c1e56b..e4bfb91 100755 >> --- a/tools/testing/selftests/rcutorture/bin/kvm-build.sh >> +++ b/tools/testing/selftests/rcutorture/bin/kvm-build.sh >> @@ -2,7 +2,7 @@ >> # >> # Build a kvm-ready Linux kernel from the tree in the current directory. >> # >> -# Usage: sh kvm-build.sh config-template build-dir more-configs >> +# Usage: bash kvm-build.sh config-template build-dir more-configs >> # >> # 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 >> diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh >> b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh >> index 7f1ff1a..30cbb63 100755 >> --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh >> +++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh >> @@ -2,7 +2,7 @@ >> # >> # Analyze a given results directory for locktorture progress. >> # >> -# Usage: sh kvm-recheck-lock.sh resdir >> +# Usage: bash kvm-recheck-lock.sh resdir >> # >> # 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 >> diff --git
Re: 3.15-rc: regression in suspend
On Fri, 11 Jul 2014, Pavel Machek wrote: > > > > Ok, so I have set up machines for ktest / autobisect, and found out > > > > that > > > > 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun, > > > > anyway... > > > > > > I am still seeing the problem with 3.16-rc2. > > > > I'm confused now. Is the bisect result > > > > commit 773875bfb6737982903c42d1ee88cf60af80089c > > Author: Daniel Vetter > > Date: Mon Jan 27 10:00:30 2014 +0100 > > > > drm/i915: Don't set the 8to6 dither flag when not scaling > > > > now the culprit or not? Or do we have 2 different bugs at hand here? > > Three different issues, it seems. Two ring initialization problems, > one went away in 3.16 (for me), second did not (suspend for jikos), > third -- trivial issue with 8to6 dither. That's correct assesment. The ring initialization failure I reported is still there. -- Jiri Kosina 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: [PATCH 1/1] usb: Check if port status is equal to RxDetect
Hi all,
On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo wrote:
> When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
> [1022:7814], the second hotplugging will experience the USB 3.0 pen
> drive is recognized as high-speed device. After bisecting the kernel,
> I found the commit number 41e7e056cdc662f704fa9262e5c6e213b4ab45dd
> (USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
> some experiments, the bug can be fixed by avoiding executing the function
> hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
> XHCI Controlleris [1022:7814] is already in RxDetect
> (I tried printing out the port status before setting to Disabled state),
> it's reasonable to check the port status before really executing
> hub_usb3_port_disable().
>
> Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.)
> Signed-off-by: Gavin Guo
> ---
> drivers/usb/core/hub.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 21b99b4..e02ab62 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -889,6 +889,25 @@ static int hub_usb3_port_disable(struct usb_hub *hub,
> int port1)
> if (!hub_is_superspeed(hub->hdev))
> return -EINVAL;
>
> + ret = hub_port_status(hub, port1, , );
> + if (ret < 0)
> + return ret;
> +
> + /*
> +* USB controller Advanced Micro Devices,
> +* Inc. [AMD] FCH USB XHCI Controller [1022:7814] will have spurious
> result
> +* making the following usb 3.0 device hotplugging route to the 2.0
> root hub
> +* and recognized as high-speed device if we set the usb 3.0 port
> link state
> +* to Disabled. Since it's already in USB_SS_PORT_LS_RX_DETECT
> state, we
> +* check the state here to avoid the bug.
> +*/
> + if ((portstatus & USB_PORT_STAT_LINK_STATE) ==
> + USB_SS_PORT_LS_RX_DETECT) {
> + dev_dbg(>ports[port1 - 1]->dev,
> +"The link state is already in
> USB_SS_PORT_LS_RX_DETECT\n");
> + return ret;
> + }
> +
> ret = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_SS_DISABLED);
> if (ret)
> return ret;
> --
> 2.0.0
>
Add Greg k-h to the 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/
Re: [PATCH] xen: Introduce 'xen_nopv' to disable PV extensions for HVM guests.
On Jul 11, 2014 7:14 PM, "H. Peter Anvin" wrote:
>
> On 07/11/2014 04:09 PM, Konrad Rzeszutek Wilk wrote:
> >
> > On Jul 11, 2014 6:52 PM, "H. Peter Anvin" wrote:
> >>
> >> On 07/11/2014 12:53 PM, kon...@kernel.org wrote:
> >>>
> >>> diff --git a/Documentation/kernel-parameters.txt
> >>> b/Documentation/kernel-parameters.txt
> >>> index c1b9aa8..5dcfa6e 100644
> >>> --- a/Documentation/kernel-parameters.txt
> >>> +++ b/Documentation/kernel-parameters.txt
> >>> @@ -3691,6 +3691,10 @@ bytes respectively. Such letter suffixes can also
> >>> be entirely omitted.
> >>> Disables the ticketlock slowpath using Xen PV
> >>> optimizations.
> >>>
> >>> + xen_nopv [X86,XEN]
> >>> + Disables the PV optimizations forcing the guest to run
> >>> + as generic HVM guest with no PV drivers.
> >>> +
> >>> xirc2ps_cs= [NET,PCMCIA]
> >>> Format:
> >>>
> >>>,[,[,[,]]]
> >>>
> >>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> >>> index ffb101e..eb82239 100644
> >>> --- a/arch/x86/xen/enlighten.c
> >>> +++ b/arch/x86/xen/enlighten.c
> >>> @@ -1826,8 +1826,19 @@ static void __init xen_hvm_guest_init(void)
> >>> xen_hvm_init_mmu_ops();
> >>> }
> >>>
> >>> +static bool xen_nopv = false;
> >>> +static __init int xen_parse_nopv(char *arg)
> >>> +{
> >>> + xen_nopv = true;
> >>> + return 0;
> >>> +}
> >>> +early_param("xen_nopv", xen_parse_nopv);
> >>> +
> >>> static uint32_t __init xen_hvm_platform(void)
> >>> {
> >>> + if (xen_nopv)
> >>> + return 0;
> >>> +
> >>> if (xen_pv_domain())
> >>> return 0;
> >>>
> >>> @@ -1836,6 +1847,8 @@ static uint32_t __init xen_hvm_platform(void)
> >>>
> >>> bool xen_hvm_need_lapic(void)
> >>> {
> >>> + if (xen_nopv)
> >>> + return false;
> >>> if (xen_pv_domain())
> >>> return false;
> >>> if (!xen_hvm_domain())
> >>>
> >>
> >> Any reason to not simply let xen_pv_domain() return false here?
> >
> > It does return false already.
> >
> > Did you mean to collapse them together?
>
> OK, I'm confused. The description of the option makes it look like it
> could disable things associated with PV domains, but it looks like it
> actually disables things having to do with HVM domains...
>
Thank you for pointing that out. I will update the documentation to be more
clear and specific. It is as you surmised only for HVM guest.
The a
> -hpa
>
Re: [PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform
Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo wrote: > Hi Sarah and Mathias, > > As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011, > I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk > can't work in SuperSpeed after several times of hotplug. After doing some > experiments and bisection, I found the bug is caused by > 41e7e056cdc662f704fa9262e5c6e213b4ab45dd (USB: Allow USB 3.0 ports to be > disabled.). And the bug can be fixed by not executing the > hub_usb3_port_disable() function. I also found that the port status is > already in RxDetect before setting the port to Disabled in > hub_usb3_port_disable() function. So, there are 2 ways to fix the bug: > > 1) Check if the Vendor/Device id is [1022:7814] at the beginning of > hub_usb3_port_disable() function. If yes, return without executing the > remaining code. > > 2) Check if the port status is already in RxDetect, if yes, return without > executing the remaining code. > > The second method seems more reasonable, so the patch is the implementation > of the second one. But it will affect more platforms and I don't know if > there'll be any negative result. Otherwise, if the first one is correct, > I can reimplement a new one. > > I'm appreciated if you can give me some advice, or if there is any thing I > missed. > > Thanks, > Gavin > > Gavin Guo (1): > usb: Check if port status is equal to RxDetect > > drivers/usb/core/hub.c | 19 +++ > 1 file changed, 19 insertions(+) > > -- > 2.0.0 > Add Greg k-h to the 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/
Re: [PATCH 1/1] rcutorture: use bash shell for all the test scripts
On Fri, Jul 11, 2014 at 05:31:27PM -0400, Pranith Kumar wrote: > Some of the scripts encode a default /bin/sh shell. On systems which use dash > as > default shell, these scripts fail as they are bash scripts. I encountered this > while testing the sprintf() changes on a Debian system where dash is the > default > shell. > > This commit changes all such uses to use bash explicitly. Good catch. Since these all have #! lines, can you please set the executable bit on any that don't have it set (looks like just config2frag.sh and kvm.sh), and then change the Usage lines to drop the shell entirely and just invoke the program directly? > Signed-off-by: Pranith Kumar With the above changed (perhaps in a separate patch): Reviewed-by: Josh Triplett > tools/testing/selftests/rcutorture/bin/config2frag.sh | 4 ++-- > tools/testing/selftests/rcutorture/bin/configcheck.sh | 4 ++-- > tools/testing/selftests/rcutorture/bin/configinit.sh | 4 ++-- > tools/testing/selftests/rcutorture/bin/kvm-build.sh| 2 +- > tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm-recheck.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm-test-1-run.sh | 2 +- > tools/testing/selftests/rcutorture/bin/kvm.sh | 2 +- > tools/testing/selftests/rcutorture/bin/parse-build.sh | 4 ++-- > tools/testing/selftests/rcutorture/bin/parse-console.sh| 4 ++-- > tools/testing/selftests/rcutorture/bin/parse-torture.sh| 4 ++-- > 12 files changed, 18 insertions(+), 18 deletions(-) > > diff --git a/tools/testing/selftests/rcutorture/bin/config2frag.sh > b/tools/testing/selftests/rcutorture/bin/config2frag.sh > index 9f9ffcd..4e394ef 100644 > --- a/tools/testing/selftests/rcutorture/bin/config2frag.sh > +++ b/tools/testing/selftests/rcutorture/bin/config2frag.sh > @@ -1,5 +1,5 @@ > -#!/bin/sh > -# Usage: sh config2frag.sh < .config > configfrag > +#!/bin/bash > +# Usage: bash config2frag.sh < .config > configfrag > # > # Converts the "# CONFIG_XXX is not set" to "CONFIG_XXX=n" so that the > # resulting file becomes a legitimate Kconfig fragment. > diff --git a/tools/testing/selftests/rcutorture/bin/configcheck.sh > b/tools/testing/selftests/rcutorture/bin/configcheck.sh > index d686537..6173ed5 100755 > --- a/tools/testing/selftests/rcutorture/bin/configcheck.sh > +++ b/tools/testing/selftests/rcutorture/bin/configcheck.sh > @@ -1,5 +1,5 @@ > -#!/bin/sh > -# Usage: sh configcheck.sh .config .config-template > +#!/bin/bash > +# Usage: bash configcheck.sh .config .config-template > # > # 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 > diff --git a/tools/testing/selftests/rcutorture/bin/configinit.sh > b/tools/testing/selftests/rcutorture/bin/configinit.sh > index 9c3f3d3..d8f7418 100755 > --- a/tools/testing/selftests/rcutorture/bin/configinit.sh > +++ b/tools/testing/selftests/rcutorture/bin/configinit.sh > @@ -1,6 +1,6 @@ > -#!/bin/sh > +#!/bin/bash > # > -# sh configinit.sh config-spec-file [ build output dir ] > +# bash configinit.sh config-spec-file [ build output dir ] > # > # Create a .config file from the spec file. Run from the kernel source tree. > # Exits with 0 if all went well, with 1 if all went well but the config > diff --git a/tools/testing/selftests/rcutorture/bin/kvm-build.sh > b/tools/testing/selftests/rcutorture/bin/kvm-build.sh > index 7c1e56b..e4bfb91 100755 > --- a/tools/testing/selftests/rcutorture/bin/kvm-build.sh > +++ b/tools/testing/selftests/rcutorture/bin/kvm-build.sh > @@ -2,7 +2,7 @@ > # > # Build a kvm-ready Linux kernel from the tree in the current directory. > # > -# Usage: sh kvm-build.sh config-template build-dir more-configs > +# Usage: bash kvm-build.sh config-template build-dir more-configs > # > # 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 > diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh > b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh > index 7f1ff1a..30cbb63 100755 > --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh > +++ b/tools/testing/selftests/rcutorture/bin/kvm-recheck-lock.sh > @@ -2,7 +2,7 @@ > # > # Analyze a given results directory for locktorture progress. > # > -# Usage: sh kvm-recheck-lock.sh resdir > +# Usage: bash kvm-recheck-lock.sh resdir > # > # 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 > diff --git a/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh > b/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh > index 307c4b9..6e94a5e 100755 > --- a/tools/testing/selftests/rcutorture/bin/kvm-recheck-rcu.sh > +++
Re: [PATCHv2 0/5] OMAP Mailbox framework adoption & DT support
On 11 July 2014 15:04, Suman Anna wrote: > Hi, > > This is a refresh of the OMAP Mailbox framework adoption & DT support > series [1], to work with the revised OMAP mailbox DT/hwmod cleanup > series [2]. > > The series has one less patch than the previous series, with the patch > "mailbox/omap: add a custom of_xlate function" squashed into the OMAP > mailbox framework adaptation patch. The first 3 patches deal with the > OMAP DT bindings and parse support like previous series, and the last > 2 patches deal with the mailbox framework adaptation. The testing is > also done with the updated v8 version of mailbox framework [3] from > Jassi Brar, no changes are required for the v7 to v8 update. > > The AM335 PM suspend series [4] which relies on this series also does > not require any changes. May I ask what branch this series is based upon? I tried a number of branches (3.16-rcX, 3.15, linux-next), and the series won't apply to any of them (other than patch 1/5, which does apply fine, but that also contains no code). Thanks, -Markus -- 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] xen: Introduce 'xen_nopv' to disable PV extensions for HVM guests.
On 07/11/2014 04:09 PM, Konrad Rzeszutek Wilk wrote:
>
> On Jul 11, 2014 6:52 PM, "H. Peter Anvin" wrote:
>>
>> On 07/11/2014 12:53 PM, kon...@kernel.org wrote:
>>>
>>> diff --git a/Documentation/kernel-parameters.txt
>>> b/Documentation/kernel-parameters.txt
>>> index c1b9aa8..5dcfa6e 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -3691,6 +3691,10 @@ bytes respectively. Such letter suffixes can also be
>>> entirely omitted.
>>> Disables the ticketlock slowpath using Xen PV
>>> optimizations.
>>>
>>> + xen_nopv [X86,XEN]
>>> + Disables the PV optimizations forcing the guest to run
>>> + as generic HVM guest with no PV drivers.
>>> +
>>> xirc2ps_cs= [NET,PCMCIA]
>>> Format:
>>>
>>> ,[,[,[,]]]
>>>
>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>>> index ffb101e..eb82239 100644
>>> --- a/arch/x86/xen/enlighten.c
>>> +++ b/arch/x86/xen/enlighten.c
>>> @@ -1826,8 +1826,19 @@ static void __init xen_hvm_guest_init(void)
>>> xen_hvm_init_mmu_ops();
>>> }
>>>
>>> +static bool xen_nopv = false;
>>> +static __init int xen_parse_nopv(char *arg)
>>> +{
>>> + xen_nopv = true;
>>> + return 0;
>>> +}
>>> +early_param("xen_nopv", xen_parse_nopv);
>>> +
>>> static uint32_t __init xen_hvm_platform(void)
>>> {
>>> + if (xen_nopv)
>>> + return 0;
>>> +
>>> if (xen_pv_domain())
>>> return 0;
>>>
>>> @@ -1836,6 +1847,8 @@ static uint32_t __init xen_hvm_platform(void)
>>>
>>> bool xen_hvm_need_lapic(void)
>>> {
>>> + if (xen_nopv)
>>> + return false;
>>> if (xen_pv_domain())
>>> return false;
>>> if (!xen_hvm_domain())
>>>
>>
>> Any reason to not simply let xen_pv_domain() return false here?
>
> It does return false already.
>
> Did you mean to collapse them together?
OK, I'm confused. The description of the option makes it look like it
could disable things associated with PV domains, but it looks like it
actually disables things having to do with HVM domains...
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] [RFC] seccomp: give BPF x32 bit when restoring x32 filter
On Jul 11, 2014 3:48 PM, "Kees Cook" wrote: > > On Fri, Jul 11, 2014 at 12:36 PM, Paul Moore wrote: > > Anyway, getting back to the idea I mentioned earlier ... as many of you may > > know, Kees (added to the CC line) is working on some seccomp filter > > improvements which will result in a new seccomp syscall. Perhaps one way > > forward is to preserve everything as it is currently with the prctl() > > interface, but with the new seccomp() based interface we fixup x32 and use > > the > > new AUDIT_ARCH_X32 token? It might result in a bit of ugliness in some of > > the > > kernel, but I don't think it would be too bad, and I think it would address > > both our concerns. > > Adding AUDIT_ARCH_X32: yes please. (On that note, the comment "/* Both > x32 and x86_64 are considered "64-bit". */" should be changed...) > I admit I'm not convinced that the current situation is really wrong. The "audit arch" uniquely defines a mapping between the actual syscall and nr and the regs. The natural way to convert between seccomp_data and the syscall entry and regs is completely correct. For things like ARM OABI, the situation is different: OABI and EABI really do work differently wrt the interpretation of the syscall regs. This isn't the case for x32. Of course, the audit code screws this up completely, but audit is disabled for x32. My upcoming seccomp patchset will clean it up a little. IMO there's no actual audit ABI to preserve for x32, because that code has never been anything other than terminally fvcked. --Andy -- 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] xen: Introduce 'xen_nopv' to disable PV extensions for HVM guests.
On Jul 11, 2014 6:52 PM, "H. Peter Anvin" wrote:
>
> On 07/11/2014 12:53 PM, kon...@kernel.org wrote:
> >
> > diff --git a/Documentation/kernel-parameters.txt
> > b/Documentation/kernel-parameters.txt
> > index c1b9aa8..5dcfa6e 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -3691,6 +3691,10 @@ bytes respectively. Such letter suffixes can also be
> > entirely omitted.
> > Disables the ticketlock slowpath using Xen PV
> > optimizations.
> >
> > + xen_nopv [X86,XEN]
> > + Disables the PV optimizations forcing the guest to run
> > + as generic HVM guest with no PV drivers.
> > +
> > xirc2ps_cs= [NET,PCMCIA]
> > Format:
> >
> >,[,[,[,]]]
> >
> > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > index ffb101e..eb82239 100644
> > --- a/arch/x86/xen/enlighten.c
> > +++ b/arch/x86/xen/enlighten.c
> > @@ -1826,8 +1826,19 @@ static void __init xen_hvm_guest_init(void)
> > xen_hvm_init_mmu_ops();
> > }
> >
> > +static bool xen_nopv = false;
> > +static __init int xen_parse_nopv(char *arg)
> > +{
> > + xen_nopv = true;
> > + return 0;
> > +}
> > +early_param("xen_nopv", xen_parse_nopv);
> > +
> > static uint32_t __init xen_hvm_platform(void)
> > {
> > + if (xen_nopv)
> > + return 0;
> > +
> > if (xen_pv_domain())
> > return 0;
> >
> > @@ -1836,6 +1847,8 @@ static uint32_t __init xen_hvm_platform(void)
> >
> > bool xen_hvm_need_lapic(void)
> > {
> > + if (xen_nopv)
> > + return false;
> > if (xen_pv_domain())
> > return false;
> > if (!xen_hvm_domain())
> >
>
> Any reason to not simply let xen_pv_domain() return false here?
It does return false already.
Did you mean to collapse them together?
>
> Also, the latter seems a bit odd?
>
> -hpa
>
Re: [PATCH 2/3] [RFC] seccomp: give BPF x32 bit when restoring x32 filter
On Fri, Jul 11, 2014 at 3:55 PM, H. Peter Anvin wrote: > It includes the X32 bit. If the uapi for __NR_* includes the x32 bit, then that's what seccomp filters must be seeing. Building seccomp filters is documented to use the __NR_* values. -Kees > > On July 11, 2014 3:52:42 PM PDT, Kees Cook wrote: >>On Fri, Jul 11, 2014 at 3:48 PM, Kees Cook >>wrote: >>> On Fri, Jul 11, 2014 at 12:36 PM, Paul Moore >>wrote: Anyway, getting back to the idea I mentioned earlier ... as many of >>you may know, Kees (added to the CC line) is working on some seccomp filter improvements which will result in a new seccomp syscall. Perhaps >>one way forward is to preserve everything as it is currently with the >>prctl() interface, but with the new seccomp() based interface we fixup x32 >>and use the new AUDIT_ARCH_X32 token? It might result in a bit of ugliness in >>some of the kernel, but I don't think it would be too bad, and I think it would >>address both our concerns. >>> >>> Adding AUDIT_ARCH_X32: yes please. (On that note, the comment "/* >>Both >>> x32 and x86_64 are considered "64-bit". */" should be changed...) >>> >>> Just so I understand: currently x86_64 and x32 both present as >>> AUDIT_ARCH_X86_64. The x32 syscalls are seen as in a different range >>> (due to the set high bit). >>> >>> The seccomp used in Chrome, Chrome OS, and vsftpd should all only do >>> whitelisting by both arch and syscall, so adding AUDIT_ARCH_X32 >>> without setting __X32_SYSCALL_BIT would be totally fine (it would >>> catch the arch instead of the syscall). This sounds similar to how >>> libseccomp is doing things, so these should be fine. >> >>I should clarify: seccomp expects to find whatever is sent as the >>syscall nr... as in the __NR_read used like this: >> >>BPF_STMT(BPF_LD+BPF_W+BPF_ABS, >>offsetof(struct seccomp_data, nr)), >>BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_read, 0, 1), >>BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_KILL), >>BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW), >> >>Are there native x32 users yet? What does __NR_read resolve to via the >>uapi on a native x32 userspace? >> >>-Kees >> >>> The only project I know of doing blacklisting is lxc, and Eric's >>> example looks a lot like a discussion I saw with lxc and init_module. >>> :) So it sounds like we can get this right there. >>> >>> I'd like to avoid carrying a delta on filter logic based on the prctl >>> vs syscall entry. Can we find any userspace filters being used that a >>> "correct" fix would break? (If so, then yes, we'll need to do this >>> proposed "via prctl or via syscall?" change.) >>> >>> -Kees >>> >>> -- >>> Kees Cook >>> Chrome OS Security > > -- > Sent from my mobile phone. Please pardon brevity and lack of formatting. -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] [RFC] seccomp: give BPF x32 bit when restoring x32 filter
It includes the X32 bit. On July 11, 2014 3:52:42 PM PDT, Kees Cook wrote: >On Fri, Jul 11, 2014 at 3:48 PM, Kees Cook >wrote: >> On Fri, Jul 11, 2014 at 12:36 PM, Paul Moore >wrote: >>> Anyway, getting back to the idea I mentioned earlier ... as many of >you may >>> know, Kees (added to the CC line) is working on some seccomp filter >>> improvements which will result in a new seccomp syscall. Perhaps >one way >>> forward is to preserve everything as it is currently with the >prctl() >>> interface, but with the new seccomp() based interface we fixup x32 >and use the >>> new AUDIT_ARCH_X32 token? It might result in a bit of ugliness in >some of the >>> kernel, but I don't think it would be too bad, and I think it would >address >>> both our concerns. >> >> Adding AUDIT_ARCH_X32: yes please. (On that note, the comment "/* >Both >> x32 and x86_64 are considered "64-bit". */" should be changed...) >> >> Just so I understand: currently x86_64 and x32 both present as >> AUDIT_ARCH_X86_64. The x32 syscalls are seen as in a different range >> (due to the set high bit). >> >> The seccomp used in Chrome, Chrome OS, and vsftpd should all only do >> whitelisting by both arch and syscall, so adding AUDIT_ARCH_X32 >> without setting __X32_SYSCALL_BIT would be totally fine (it would >> catch the arch instead of the syscall). This sounds similar to how >> libseccomp is doing things, so these should be fine. > >I should clarify: seccomp expects to find whatever is sent as the >syscall nr... as in the __NR_read used like this: > >BPF_STMT(BPF_LD+BPF_W+BPF_ABS, >offsetof(struct seccomp_data, nr)), >BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_read, 0, 1), >BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_KILL), >BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW), > >Are there native x32 users yet? What does __NR_read resolve to via the >uapi on a native x32 userspace? > >-Kees > >> The only project I know of doing blacklisting is lxc, and Eric's >> example looks a lot like a discussion I saw with lxc and init_module. >> :) So it sounds like we can get this right there. >> >> I'd like to avoid carrying a delta on filter logic based on the prctl >> vs syscall entry. Can we find any userspace filters being used that a >> "correct" fix would break? (If so, then yes, we'll need to do this >> proposed "via prctl or via syscall?" change.) >> >> -Kees >> >> -- >> Kees Cook >> Chrome OS Security -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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/
