Re: [PATCH v2 1/2] Use kacpi_hotplug_wq to handle container hotplug event.
Hi Tang,
2012/10/24 15:05, Tang Chen wrote:
> As the comments in __acpi_os_execute() said:
>
> We can't run hotplug code in keventd_wq/kacpid_wq/kacpid_notify_wq
> because the hotplug code may call driver .remove() functions,
> which invoke flush_scheduled_work/acpi_os_wait_events_complete
> to flush these workqueues.
>
> we should keep the hotplug code in kacpi_hotplug_wq.
>
> But we have the following call series in kernel now:
> acpi_ev_queue_notify_request()
> |--> acpi_os_execute()
>|--> __acpi_os_execute(type, function, context, 0)
>
> The last parameter 0 makes the container_notify_cb() executed in
> kacpi_notify_wq or kacpid_wq. So, we need to put the real hotplug code
> into kacpi_hotplug_wq.
I cannot understand the purpose of the patch.
Is the patch a bug fix patch? If yes, what problem happens?
Thanks,
Yasuaki Ishimatsu
>
> Signed-off-by: Tang Chen
> ---
> drivers/acpi/container.c | 17 -
> 1 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
> index 69e2d6b..d300e03 100644
> --- a/drivers/acpi/container.c
> +++ b/drivers/acpi/container.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
> #define PREFIX "ACPI: "
>
> @@ -165,14 +166,21 @@ static int container_device_add(struct acpi_device
> **device, acpi_handle handle)
> return result;
> }
>
> -static void container_notify_cb(acpi_handle handle, u32 type, void *context)
> +static void __container_notify_cb(struct work_struct *work)
> {
> struct acpi_device *device = NULL;
> int result;
> int present;
> acpi_status status;
> + struct acpi_hp_work *hp_work;
> + acpi_handle handle;
> + u32 type;
> u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
>
> + hp_work = container_of(work, struct acpi_hp_work, work);
> + handle = hp_work->handle;
> + type = hp_work->type;
> +
> switch (type) {
> case ACPI_NOTIFY_BUS_CHECK:
> /* Fall through */
> @@ -224,6 +232,13 @@ static void container_notify_cb(acpi_handle handle, u32
> type, void *context)
> return;
> }
>
> +static void container_notify_cb(acpi_handle handle, u32 type,
> + void *context)
> +{
> + alloc_acpi_hp_work(handle, type, context,
> +__container_notify_cb);
> +}
> +
> static acpi_status
> container_walk_namespace_cb(acpi_handle handle,
> u32 lvl, void *context, void **rv)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: proposed perf_event_open() manpage
Hi Vince, Great work! On Tue, 23 Oct 2012 11:35:13 -0400 (EDT), Vince Weaver wrote: > Hello > > attached is a proposed manpage for the perf_event_open() system call. > > I'd appreciate any review or comments, especially for the parts marked > as FIXME or "[To be documented]" > > This system call has a complicated interface and I'm sure I've missed > or glossed over various important features, so your feedback is needed and > appreciated. > > The eventual goal is to have this included with the Linux man-pages > project. [snip] > .BI "int perf_event_open(struct perf_event_attr *" hw_event , hw_event? Looks unusual.. how about 'attr'? > .BI "pid_t " pid ", int " cpu ", int " group_fd , > .BI "unsigned long " flags ); > .fi [snip] > .SS Arguments > .P > The argument > .I pid > allows events to be attached to processes in various ways. > If > .I pid > is 0, measurements happen on the current task, if > .I pid > is greater than 0, the process indicated by > .I pid > is measured, and if > .I pid > is less than 0, all processes are counted. Is that true? Shouldn't pid be -1? > > The > .I cpu > argument allows measurements to be specific to a CPU. > If > .I cpu > is greater than or equal to 0, > measurements are restricted to the specified CPU; > if > .I cpu > is \-1, the events are measured on all CPUs. > .P > Note that the combination of > .IR pid " == \-1" > and > .IR cpu " == \-1" > is not valid. > .P > A > .IR pid " > 0" s/>/>=/ ? > and > .IR cpu " == \-1" > setting measures per-process and follows that process to whatever CPU the > process gets scheduled to. > Per-process events can be created by any user. > .P > A > .IR pid " == \-1" > and > .IR cpu " >= 0" > setting is per-CPU and measures all processes on the specified CPU. > Per-CPU events need the > .B CAP_SYS_ADMIN > capability. Or value of perf_event_paranoid is less than 1. > .TP > .RB "dynamic PMU" > Since Linux 2.6.39, > .BR perf_event_open() > can support multiple PMUs. > To enable this, a value exported by the kernel can be used in the > .I type > field to indicate which PMU to use. > The value to use can be found in the sysfs filesystem: > there is a subdirectory per PMU instance under > .IR /sys/devices . /sys/bus/event_source/devices will be the right place. > In each sub-directory there is a > .I type > file whose content is an integer that can be used in the > .I type > field. > For instance, > .I /sys/devices/cpu/type /sys/bus/event_source/devices/cpu/type > contains the value for the core CPU PMU, which is usually 4. > .RE > [snip] > .TP > .IR sample_period ", " sample_freq > A "sampling" counter is one that generates an interrupt > every N events, where N is given by > .IR sample_period . > A sampling counter has > .IR sample_period " > 0." How about adding this here: "When an (overflow) interrupt generated, requested data (sample) would be recorded." > The > .I sample_type > field controls what data is recorded on each interrupt. > > .I sample_freq > can be used if you wish to use frequency rather than period. > In this case you set the > .I freq > flag. > The kernel will adjust the sampling period > to try and achieve the desired rate. > The rate of adjustment is a > timer tick. Is that true? I thought it'd be adjusted whenever overflow occures. > > > .TP > .I "sample_type" > The various bits in this field specify which values to include > in the overflow packets. I guess the overflow packets here means samples. It'd be better if we use a consistent word for specifying a thing. > They will be recorded in a ring-buffer, > which is available to user-space using > .BR mmap (2). > The order in which the values are saved in the > overflow packets as documented in the MMAP Layout subsection below; > it is not the > .I "enum perf_event_sample_format" > order. > .RS > .TP > .B PERF_SAMPLE_IP > instruction pointer > .TP > .B PERF_SAMPLE_TID > thread id > .TP > .B PERF_SAMPLE_TIME > time > .TP > .B PERF_SAMPLE_ADDR > address > .TP > .B PERF_SAMPLE_READ > [To be documented] It's for an event group to sample leader only. Values of other members will be read when an interrupt occurred on the leader. Jiri is working on it. > .TP > .B PERF_SAMPLE_CALLCHAIN > [To be documented] callchain (or stack backtrace) > .TP > .B PERF_SAMPLE_ID > [To be documented] unique(?) id for the opened event. > .TP > .B PERF_SAMPLE_CPU > [To be documented] cpu number > .TP > .B PERF_SAMPLE_PERIOD > [To be documented] event count > .TP > .B PERF_SAMPLE_STREAM_ID > [To be documented] > .TP > .B PERF_SAMPLE_RAW > [To be documented] additional data - usually for tracepoint events > .TP > .BR PERF_SAMPLE_BRANCH_STACK " (Since Linux 3.4)" > [To be documented] requested branch stack - only supported on intel machines which has LBR feature(?). See branch_sample_type. > .RE [snip] > .SS /proc/sys/kernel/perf_event_paranoid > > The > .I /proc/sys/kernel/perf_event_paranoid > file can be set t
[BUGFIX 2/2] PCI/PM: Resume device before shutdown
Some actions during shutdown need device to be in D0 state, such as MSI shutdown etc, so resume device before shutdown. Signed-off-by: Huang Ying --- drivers/pci/pci-driver.c | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -398,6 +398,8 @@ static void pci_device_shutdown(struct d struct pci_dev *pci_dev = to_pci_dev(dev); struct pci_driver *drv = pci_dev->driver; + pm_runtime_resume(dev); + if (drv && drv->shutdown) drv->shutdown(pci_dev); pci_msi_shutdown(pci_dev); @@ -408,16 +410,6 @@ static void pci_device_shutdown(struct d * continue to do DMA */ pci_disable_device(pci_dev); - - /* -* Devices may be enabled to wake up by runtime PM, but they need not -* be supposed to wake up the system from its "power off" state (e.g. -* ACPI S5). Therefore disable wakeup for all devices that aren't -* supposed to wake up the system at this point. The state argument -* will be ignored by pci_enable_wake(). -*/ - if (!device_may_wakeup(dev)) - pci_enable_wake(pci_dev, PCI_UNKNOWN, false); } #ifdef CONFIG_PM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 04/18] slab: don't preemptively remove element from list in cache destroy
On Mon, Oct 22, 2012 at 11:40 AM, Glauber Costa wrote:
> On 10/19/2012 11:34 PM, Christoph Lameter wrote:
>> On Fri, 19 Oct 2012, Glauber Costa wrote:
>>
>>> I, however, see no reason why we need to do so, since we are now locked
>>> during the whole deletion (which wasn't necessarily true before). I
>>> propose a simplification in which we delete it only when there is no
>>> more going back, so we don't need to add it again.
>>
>> Ok lets hope that holding the lock does not cause issues.
>>
>> Acked-by: Christoph Lameter
>>
> BTW: One of the good things about this set, is that we are naturally
> exercising cache destruction a lot more than we did before. So if there
> is any problem, either with this or anything related to cache
> destruction, it should at least show up a lot more frequently. So far,
> this does not seem to cause any problems.
We no longer hold the mutex the whole time after. See commit 210ed9d
("mm, slab: release slab_mutex earlier in kmem_cache_destroy()") for
details.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] nfs: fix wrong object type in lockowner_slab
From: Yanchuan Nian
The object type in the cache of lockowner_slab is wrong, and it is better to
fix it.
Signed-off-by: Yanchuan Nian
---
fs/nfsd/nfs4state.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index cc894ed..1609eb2 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -2325,7 +2325,7 @@ nfsd4_init_slabs(void)
if (openowner_slab == NULL)
goto out_nomem;
lockowner_slab = kmem_cache_create("nfsd4_lockowners",
- sizeof(struct nfs4_openowner), 0, 0, NULL);
+ sizeof(struct nfs4_lockowner), 0, 0, NULL);
if (lockowner_slab == NULL)
goto out_nomem;
file_slab = kmem_cache_create("nfsd4_files",
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] firmware loader: introduce kernel parameter to customize fw search path
On Wed, Oct 24, 2012 at 1:42 PM, Greg Kroah-Hartman wrote: > Yes, but why? Let's not overdesign this, get the basics working and > then, if someone really needs it, we can add it. OK, I will remove the kernel parameter and related documentation, and just keep it as module parameter, sorry about that. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: + memory-hotplug-allocate-zones-pcp-before-onlining-pages.patch added to -mm tree
Hi, Andrew Morton
At 10/19/2012 06:31 AM, a...@linux-foundation.org Wrote:
> The patch titled
> Subject: memory-hotplug: allocate zone's pcp before onlining pages
> has been added to the -mm tree. Its filename is
> memory-hotplug-allocate-zones-pcp-before-onlining-pages.patch
I find a problem introduced by this patch, and the following is the fix:
Do I need to merge them into a single patch?
>From 705b8f7392adba8a36d8e89b5aef77d9a6a9042c Mon Sep 17 00:00:00 2001
From: Wen Congyang
Date: Wed, 24 Oct 2012 14:21:15 +0800
Subject: [PATCH] memory-hotplug: build zonelist if a zone is populated after
onlining pages
After "memory-hotplug: allocate zone's pcp before onlining pages", we
build zone list before onlining pages to allocate zone's pcp. But the
zone doesn't have pages before onlining pages, and the zone is not in
zonelist, so we still need to build zonelist after onlining pages.
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
---
mm/memory_hotplug.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 3656926..b82bccf 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -529,7 +529,9 @@ int __ref online_pages(unsigned long pfn, unsigned long
nr_pages)
zone->zone_pgdat->node_present_pages += onlined_pages;
if (onlined_pages) {
node_set_state(zone_to_nid(zone), N_HIGH_MEMORY);
- if (!need_zonelists_rebuild)
+ if (need_zonelists_rebuild)
+ build_all_zonelists(NULL, NULL);
+ else
zone_pcp_update(zone);
}
--
1.7.1
>
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a suitable mailing list as well
>c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> --
> From: Wen Congyang
> Subject: memory-hotplug: allocate zone's pcp before onlining pages
>
> We use __free_page() to put a page to buddy system when onlining pages.
> __free_page() will store NR_FREE_PAGES in zone's pcp.vm_stat_diff, so we
> should allocate zone's pcp before onlining pages, otherwise we will lose
> some free pages.
>
> Signed-off-by: Wen Congyang
> Cc: David Rientjes
> Cc: Jiang Liu
> Cc: Len Brown
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Christoph Lameter
> Cc: Minchan Kim
> Cc: KOSAKI Motohiro
> Cc: Yasuaki Ishimatsu
> Cc: Dave Hansen
> Cc: Mel Gorman
> Signed-off-by: Andrew Morton
> ---
>
> mm/memory_hotplug.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff -puN
> mm/memory_hotplug.c~memory-hotplug-allocate-zones-pcp-before-onlining-pages
> mm/memory_hotplug.c
> ---
> a/mm/memory_hotplug.c~memory-hotplug-allocate-zones-pcp-before-onlining-pages
> +++ a/mm/memory_hotplug.c
> @@ -505,12 +505,16 @@ int __ref online_pages(unsigned long pfn
>* So, zonelist must be updated after online.
>*/
> mutex_lock(&zonelists_mutex);
> - if (!populated_zone(zone))
> + if (!populated_zone(zone)) {
> need_zonelists_rebuild = 1;
> + build_all_zonelists(NULL, zone);
> + }
>
> ret = walk_system_ram_range(pfn, nr_pages, &onlined_pages,
> online_pages_range);
> if (ret) {
> + if (need_zonelists_rebuild)
> + zone_pcp_reset(zone);
> mutex_unlock(&zonelists_mutex);
> printk(KERN_DEBUG "online_pages [mem %#010llx-%#010llx]
> failed\n",
> (unsigned long long) pfn << PAGE_SHIFT,
> @@ -525,9 +529,7 @@ int __ref online_pages(unsigned long pfn
> zone->zone_pgdat->node_present_pages += onlined_pages;
> if (onlined_pages) {
> node_set_state(zone_to_nid(zone), N_HIGH_MEMORY);
> - if (need_zonelists_rebuild)
> - build_all_zonelists(NULL, zone);
> - else
> + if (!need_zonelists_rebuild)
> zone_pcp_update(zone);
> }
>
> _
>
> Patches currently in -mm which might be from we...@cn.fujitsu.com are
>
> cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved.patch
> cpu_hotplug-unmap-cpu2node-when-the-cpu-is-hotremoved-fix.patch
> acpi_memhotplugc-fix-memory-leak-when-memory-device-is-unbound-from-the-module-acpi_memhotplug.patch
> acpi_memhotplugc-free-memory-device-if-acpi_memory_enable_device-failed.patch
> acpi_memhotplugc-remove-memory-info-from-list-before-freeing-it.
[PATCH] Enable A20 using KBC for some MSI laptops to fix S3 resume
Some MSI laptop BIOSes are broken - INT 15h code uses port 92h to enable A20
line but resume code assumes that KBC was used.
The laptop will not resume from S3 otherwise but powers off after a while
and then powers on again stuck with a blank screen.
Fix it by enabling A20 using KBC. Affected laptop list and DMI data are from
bug reports at Ubuntu Launchpad.
Tested with EX600 and PR200.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=12878
Signed-off-by: Ondrej Zary
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1349,6 +1349,20 @@ static int __init dmi_ignore_irq0_timer_override(const
struct dmi_system_id *d)
}
/*
+ * Enable A20 line using KBC even if it's already enabled using other method.
+ * This is needed for some MSI laptops to resume from S3.
+ */
+static int __init a20_enable_kbc(const struct dmi_system_id *d)
+{
+ printk(KERN_NOTICE "%s detected: enabling A20 using KBC\n", d->ident);
+ outb(0xd1, 0x64); /* Command write */
+ outb(0xdf, 0x60); /* A20 on */
+ outb(0xff, 0x64); /* Null command, but UHCI wants it */
+
+ return 0;
+}
+
+/*
* If your system is blacklisted here, but you find that acpi=force
* works for you, please contact linux-a...@vger.kernel.org
*/
@@ -1423,6 +1437,60 @@ static struct dmi_system_id __initdata acpi_dmi_table[]
= {
DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"),
},
},
+ /*
+* Some MSI laptop BIOSes are broken - INT 15h code uses port 92h to
+* enable A20 line but resume code assumes that KBC was used.
+* The laptop will not resume from S3 otherwise but powers off
+* after a while and then powers on again stuck with a blank screen.
+*/
+ {
+.callback = a20_enable_kbc,
+.ident = "MSI EX600 Laptop",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International"),
+DMI_MATCH(DMI_PRODUCT_NAME, "MSI Notebook EX600"),
+},
+},
+ {
+.callback = a20_enable_kbc,
+.ident = "MSI EX700 Laptop",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International"),
+DMI_MATCH(DMI_PRODUCT_NAME, "EX700"),
+},
+},
+ {
+.callback = a20_enable_kbc,
+.ident = "MSI GX700 Laptop",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International"),
+DMI_MATCH(DMI_PRODUCT_NAME, "GX700"),
+},
+},
+ {
+.callback = a20_enable_kbc,
+.ident = "MSI VR201 Laptop",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International"),
+DMI_MATCH(DMI_PRODUCT_NAME, "MSI Notebook VR201"),
+},
+},
+ {
+.callback = a20_enable_kbc,
+.ident = "MSI VR601 Laptop",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International"),
+DMI_MATCH(DMI_PRODUCT_NAME, "MSI Notebook VR601"),
+},
+},
+ {
+.callback = a20_enable_kbc,
+.ident = "MSI PR200 Laptop",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Micro-Star International"),
+DMI_MATCH(DMI_PRODUCT_NAME, "MSI Notebook PR200"),
+},
+},
{}
};
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 01/18] move slabinfo processing to slab_common.c
On Fri, Oct 19, 2012 at 5:20 PM, Glauber Costa wrote: > This patch moves all the common machinery to slabinfo processing > to slab_common.c. We can do better by noticing that the output is > heavily common, and having the allocators to just provide finished > information about this. But after this first step, this can be done > easier. > > Signed-off-by: Glauber Costa > Acked-by: Christoph Lameter > CC: Pekka Enberg > CC: David Rientjes I've applied patches 1-3. Thanks, Glauber! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.7 RC1
On Tue, Oct 23, 2012 at 02:24:58PM +, KY Srinivasan wrote: > > > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Tuesday, October 23, 2012 1:47 AM > > To: KY Srinivasan > > Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > > jasow...@redhat.com > > Subject: Re: 3.7 RC1 > > > > On Mon, Oct 22, 2012 at 04:37:45PM -0700, K. Y. Srinivasan wrote: > > > > > > While testing 3.7 RC1 I discovered that invoking the function > > orderly_poweroff() > > > from an interrupt context will trigger an ASSERT(). This was not the case > > > till > > > recently. The comment preceding the orderly_poweroff() function claims > > > that > > this > > > function can be invoked from any context and in the current Hyper-V util > > > driver, > > > we support host-driven orderly shut down of the guest by invoking this > > > orderly_poweroff() function in the context of the message callback. This > > > code > > has > > > been working for a very long time and it is broken now. Is my assumption > > > that > > > orderly_poweroff() could be invoked from the interrupt context a wrong > > assumption? > > > > You can't call orderly_poweroff() from interrupt context. > > Thanks Dan; I am curious to understand the basis for your assertion. > As I noted earlier the documentation for this function clearly says it can > be called from any context. Furthermore, __orderly_poweroff(), the helper > function allocates memory with the GFP_ATOMIC flag set. Lastly, the behavior > of orderly_poweroff() has been such that this function could be called from > interrupt context > for a very long time and something has changed now. For what it is worth, > there are other users in > the kernel (in 3.7 RC1) that are invoking the orderly_poweroff() function > from interrupt > context other than the Hyper-V shutdown handler: fsl_hv_shutdown_isr() in > drivers/virt/fsl_hypervisor.c. > I suspect there are other users as well that have made this similar > assumption. > Aw crap. I was wrong. Sorry about that. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PWM: Add SPEAr PWM chip driver support
On 24 October 2012 11:21, Thierry Reding
wrote:
> On Mon, Oct 22, 2012 at 04:36:41PM +0530, Shiraz Hashim wrote:
>> + ret = pwmchip_add(&pc->chip);
>> + if (ret < 0) {
>> + dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = clk_prepare_enable(pc->clk);
>> + if (ret < 0)
>> + return pwmchip_remove(&pc->chip);
>
> I think in order to fix the potential race condition that Viresh
> mentioned we should move the clk_prepare_enable() before the
> pwmchip_add(), but don't forget to disable and unprepare the clock if
> pwmchip_add() fails.
>
> Actually, can't we make it a clk_prepare() only at this point and move
> the clk_enable() and clk_disable() into the if block below? In case the
> compatible value is not "st,spear1340-pwm" we don't need the clock
> enabled.
We should. I should have given this comment earlier.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv4] Input: keypad: Add smsc ece1099 keypad driver
Hi Sourav,
On Fri, Oct 05, 2012 at 12:56:26PM +0530, Sourav Poddar wrote:
> From: G, Manjunath Kondaiah
>
> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
> supports a keypad scan matrix of 23*8.This driver uses this
> device as a keypad driver.
>
> Tested on omap5430 evm with 3.6-rc6 custom kernel.
>
> Cc: Benoit Cousson
> Cc: Felipe Balbi
> Cc: Santosh Shilimkar
> Signed-off-by: G, Manjunath Kondaiah
> Signed-off-by: Sourav Poddar
> Acked-by: Felipe Balbi
> ---
> This patch was posted as a series initially
> http://www.spinics.net/lists/linux-omap/msg78772.html
>
> But the parent mfd driver has beeen already picked by mfd maintainer.
> So this patch can now posted as an standalone patch.
>
> v3->v4:
> Fix Dmitry's comments:
> - Error patch(input_free_device/input_unregister_device).
> - Few cleanups.
> - Included INPUT_MATRIXKMAP
> drivers/input/keyboard/Kconfig | 12 +
> drivers/input/keyboard/Makefile |1 +
> drivers/input/keyboard/smsc-ece1099-keypad.c | 303
> ++
> 3 files changed, 316 insertions(+), 0 deletions(-)
> create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index c50fa75..e370b03 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -593,6 +593,18 @@ config KEYBOARD_TWL4030
> To compile this driver as a module, choose M here: the
> module will be called twl4030_keypad.
>
> +config KEYBOARD_SMSC
> + tristate "SMSC ECE1099 keypad support"
> + depends on I2C
> + select INPUT_MATRIXKMAP
While I do not see hard dependencies in the driver itself, should we
also depend on MFD_SMSC?
> + help
> + Say Y here if your board use the smsc keypad controller
> + for omap5 defconfig. It's safe to say enable this
> + even on boards that don't use the keypad controller.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called smsc-ece1099-keypad.
> +
> config KEYBOARD_XTKBD
> tristate "XT keyboard"
> select SERIO
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 44e7600..0f2aa26 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X) +=
> tc3589x-keypad.o
> obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
> obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
> +obj-$(CONFIG_KEYBOARD_SMSC)+= smsc-ece1099-keypad.o
> obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
> obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
> diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c
> b/drivers/input/keyboard/smsc-ece1099-keypad.c
> new file mode 100644
> index 000..a4a0dfe
> --- /dev/null
> +++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
> @@ -0,0 +1,303 @@
> +/*
> + * SMSC_ECE1099 Keypad driver
> + *
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define KEYPRESS_TIME 200
> +
> +struct smsc_keypad {
> + struct smsc *smsc;
I do not see this being actually used.
> + struct matrix_keymap_data *keymap_data;
Does not seem to be used.
> + unsigned int last_key_state[16];
> + unsigned int last_col;
> + unsigned int last_key_ms[16];
> + unsigned short *keymap;
> + struct i2c_client *client;
> + struct input_dev *input;
> + int rows, cols;
> + int row_shift;
> + bool no_autorepeat;
> + unsignedirq;
I do not think you need to store irq if you are using managed resources.
> + struct device *dev;
> +};
> +
> +static void smsc_kp_scan(struct smsc_keypad *kp)
> +{
> + struct input_dev *input = kp->input;
> + int i, j;
> + int row, col;
> + int temp, code;
> + unsigned int new_state[16];
> + unsigned int bits_changed;
> + int this_ms;
> +
> + smsc_write(kp->dev, SMSC_KP_INT_MASK, 0x00);
> + smsc_write(kp->dev, SMSC_KP_INT_STAT, 0xFF);
> +
> + /* Scan for row and column */
> + for (i = 0; i < kp->cols; i++) {
> + smsc_write(kp->dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
> + /* Read Row Status */
> + smsc_read(kp->dev, SMSC_KP_IN, &temp);
> + if (temp == 0xFF)
> + continue;
> +
> + col = i;
> + fo
Re: [rfc 0/2] Introducing VmFlags field into smaps output
On Wed, Oct 24, 2012 at 12:32:54AM +0200, Peter Zijlstra wrote:
> On Wed, 2012-10-24 at 01:59 +0400, Cyrill Gorcunov wrote:
> > [ilog2(VM_WRITE)] = { {'w', 'r'} },
>
> since we're being awfully positive about crazy late night ideas, how
> about something like:
>
> #define MNEM(_VM, _mn) [ilog2(_VM)] = {(const char [2]){_mn}}
>
> MNEM(VM_WRITE, "wr"),
I see no reason why should not we :) I'll update.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] add some drop_caches documentation and info messsge
On Tue 23-10-12 16:45:46, Andrew Morton wrote: > On Fri, 12 Oct 2012 14:57:08 +0200 > Michal Hocko wrote: > > > Hi, > > I would like to resurrect the following Dave's patch. The last time it > > has been posted was here https://lkml.org/lkml/2010/9/16/250 and there > > didn't seem to be any strong opposition. > > Kosaki was worried about possible excessive logging when somebody drops > > caches too often (but then he claimed he didn't have a strong opinion > > on that) but I would say opposite. If somebody does that then I would > > really like to know that from the log when supporting a system because > > it almost for sure means that there is something fishy going on. It is > > also worth mentioning that only root can write drop caches so this is > > not an flooding attack vector. > > I am bringing that up again because this can be really helpful when > > chasing strange performance issues which (surprise surprise) turn out to > > be related to artificially dropped caches done because the admin thinks > > this would help... > > > > I have just refreshed the original patch on top of the current mm tree > > but I could live with KERN_INFO as well if people think that KERN_NOTICE > > is too hysterical. > > --- > > >From 1f4058be9b089bc9d43d71bc63989335d7637d8d Mon Sep 17 00:00:00 2001 > > From: Dave Hansen > > Date: Fri, 12 Oct 2012 14:30:54 +0200 > > Subject: [PATCH] add some drop_caches documentation and info messsge > > > > There is plenty of anecdotal evidence and a load of blog posts > > suggesting that using "drop_caches" periodically keeps your system > > running in "tip top shape". Perhaps adding some kernel > > documentation will increase the amount of accurate data on its use. > > > > If we are not shrinking caches effectively, then we have real bugs. > > Using drop_caches will simply mask the bugs and make them harder > > to find, but certainly does not fix them, nor is it an appropriate > > "workaround" to limit the size of the caches. > > > > It's a great debugging tool, and is really handy for doing things > > like repeatable benchmark runs. So, add a bit more documentation > > about it, and add a little KERN_NOTICE. It should help developers > > who are chasing down reclaim-related bugs. > > > > ... > > > > + printk(KERN_NOTICE "%s (%d): dropped kernel caches: %d\n", > > + current->comm, task_pid_nr(current), > > sysctl_drop_caches); > > urgh. Are we really sure we want to do this? The system operators who > are actually using this thing will hate us :( I have no problems with lowering the priority (how do you see KERN_INFO?) but shouldn't this message kick them that they are doing something wrong? Or if somebody uses that for "benchmarking" to have a clean table before start is this really that invasive? > More friendly alternatives might be: > > - Taint the kernel. But that will only become apparent with an oops > trace or similar. > > - Add a drop_caches counter and make that available in /proc/vmstat, > show_mem() output and perhaps other places. We would loose timing and originating process name in both cases which can be really helpful while debugging. It is fair to say that we could deduce the timing if we are collecting /proc/meminfo or /proc/vmstat already and we do collect them often but this is not the case all of the time and sometimes it is important to know _who_ is doing all this. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] x86: efi: Turn off efi_enabled after setup on mixed fw/kernel
When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.
This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991
Reported-by: Marko Kohtala
Reported-by: Maxim Kammerer
Signed-off-by: Olof Johansson
Cc: sta...@kernel.org # 3.4 - 3.6
Cc: Matthew Garrett
Cc: Maarten Lankhorst
---
v2: rebase due to context diffs, and simplified efi_is_native() logic.
arch/x86/kernel/setup.c | 11 +++
arch/x86/platform/efi/efi.c | 16 +---
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 468e98d..ea2c587 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1048,6 +1048,17 @@ void __init setup_arch(char **cmdline_p)
arch_init_ideal_nops();
register_refined_jiffies(CLOCK_TICK_RATE);
+
+#ifdef CONFIG_EFI
+ /* Once setup is done above, disable efi_enabled on mismatched
+* firmware/kernel archtectures since there is no support for
+* runtime services.
+*/
+ if (IS_ENABLED(CONFIG_X86_64) != efi_64bit) {
+ pr_info("efi: Setup done, disabling due to 32/64-bit
mismatch\n");
+ efi_enabled = 0;
+ }
+#endif
}
#ifdef CONFIG_X86_32
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index aded2a9..6e620f1 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -70,11 +70,15 @@ EXPORT_SYMBOL(efi);
struct efi_memory_map memmap;
bool efi_64bit;
-static bool efi_native;
static struct efi efi_phys __initdata;
static efi_system_table_t efi_systab __initdata;
+static inline bool efi_is_native(void)
+{
+ return IS_ENABLED(CONFIG_X86_64) == efi_64bit;
+}
+
static int __init setup_noefi(char *arg)
{
efi_enabled = 0;
@@ -432,7 +436,7 @@ void __init efi_free_boot_services(void)
{
void *p;
- if (!efi_native)
+ if (!efi_is_native())
return;
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
@@ -684,12 +688,10 @@ void __init efi_init(void)
return;
}
efi_phys.systab = (efi_system_table_t *)boot_params.efi_info.efi_systab;
- efi_native = !efi_64bit;
#else
efi_phys.systab = (efi_system_table_t *)
(boot_params.efi_info.efi_systab |
((__u64)boot_params.efi_info.efi_systab_hi<<32));
- efi_native = efi_64bit;
#endif
if (efi_systab_init(efi_phys.systab)) {
@@ -723,7 +725,7 @@ void __init efi_init(void)
* that doesn't match the kernel 32/64-bit mode.
*/
- if (!efi_native)
+ if (!efi_is_native())
pr_info("No EFI runtime due to 32/64-bit mismatch with
kernel\n");
else if (efi_runtime_init()) {
efi_enabled = 0;
@@ -735,7 +737,7 @@ void __init efi_init(void)
return;
}
#ifdef CONFIG_X86_32
- if (efi_native) {
+ if (efi_is_native()) {
x86_platform.get_wallclock = efi_get_time;
x86_platform.set_wallclock = efi_set_rtc_mmss;
}
@@ -834,7 +836,7 @@ void __init efi_enter_virtual_mode(void)
* non-native EFI
*/
- if (!efi_native) {
+ if (!efi_is_native()) {
efi_unmap_memmap();
return;
}
--
1.7.10.1.488.g05fbf7a
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
Hi Philippe, On 16/10/12 18:03, Philippe De Muyter wrote: On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote: On 09/10/12 19:07, Philippe De Muyter wrote: [CCing lkml, linux-ppc, netdev, linux-m68k] Hello kernel sources architects I have a working driver for the m54xx FEC ethernet driver that I would like to integrate in the kernel tree. Problems are that - this driver needs an associated DMA driver (provided by FreeScale) wich is not dma-engine enabled - they're are already many fec drivers in the kernel tree, and at least one, fec_mpc52xx.c, seems to be very similar (information below), to the one for the mcf54xx, except it uses a differently named associated DMA driver (BestComm/SmartDma/SDMA) which is also not dma-engine enabled, and even kept hidden in /arch/powerpc where it is inaccessible when compiling for m68k. The underlying DMA part from Freescale however seems similar to the one used in the m54xx. (again, see information below) So, now I am lost, what should I do ? The current state of my patches [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html] is pushing the freescale provided MCD_DMA dma driver to /drivers/dma, without adding the dma-engine compatibility layer, and adding the specific fec_m54xx ethernet driver to /drivers/net/ethernet/freescale Do you get any responses? I didn't see any... No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm to drivers/dma/bestcomm (except a private and useful one telling me how to set '-M' option as default for 'git format-patch'), but at least this simpler patch seems to be in a wait bucket at http://patchwork.ozlabs.org/project/linuxppc-dev/list/. Well, something useful then :-) Feel free to send me the m68k header file updates as a patch (or patches as appropriate), lets get those in now. They are worthwhile changes on their own. In light of no other other feedback you may want to push ahead then with your patches to put the DMA engine code in drivers/dma. That does seem like the right place to put it. The new fec driver code should go to the netdev list for review. Regards Greg Regards Philippe PS: -M as default for 'git format-patch': put [diff] renames = true in .git/config Regards Greg On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote: Hi Philippe, On 05/10/12 01:03, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote: On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote: My biggest concern is the amount of MCD/DMA support code. And it is all done quite differently to everything else in the kernel. We may get a bit of push back from kernel folk who look after DMA. Actually, there is already a similar code in arch/powerpc/sysdev/bestcomm (also from freescale, maybe an identical part, but I did not find any usable doc), but the powerpc folks kept that hidden in the arch/powerpc tree, instead of installing it in drivers/dma. The MCD DMA or DMA FEC code from freescale has a comment implying that this was first used in the MPC8220 part. And Montavista has a MPC8220 port, but I did not find it, so I do not know where they installed the MCD DMA driver. Ok, looks like there is a bit a variance in all this. I also began to read the mpc5200 user's guide parts about the fec and BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name) and they look very similar, but not identical, to their m54xx counterparts. It seems possible to make the fec_mpc52xx.c driver work for the m54xx but that needs at least: - moving some files or part of them from /arch/powerpc/sysdev and /arch/powerpc/include/asm to /drivers/dma and /include/linux, - renaming the fec_mpc52xx files to a more sensible name, - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h, - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA in mcf_52xx.c. An additional problem is that the freescale docs for powerpcs and for coldfires do not use the same mnemonics for the same registers. e.g. FEC registers offset MPC5200 MCF5484 == === === 000 FEC_ID n/a 004 IEVENT EIR 008 IMASK EIMR 010 R_DES_ACTIVEn/a 014 X_DES_ACTIVEn/a 024 ECNTRL ECR 040 MII_DATAMDATA 044 MII_SPEED MSCR 064 MIB_CONTROL MIBC 084 R_CNTRL RCR 088 R_HASH RHR 0C4 X_CNTRL TCR 0E4 PADDR1 PALR 0E8 PADDR2 PAHR 0EC OP_PAUSEOPD 118 IADDR1 IAUR 11C IADDR1 IALR 120 GADDR1 GAUR 124 GADDR2 GALR 144 X_WMRK FECTFWR 184 RFIFO_DATA FECRFDR 188 RFIF
[PATCH v3 net-next] r8169: enable ALDPS for power saving
Enable ALDPS function to save power when link down. Note that the
feature should be set after the other PHY settings. And the firmware
is necessary. Don't enable it without loading the firmware.
None of the firmware-free chipsets support ALDPS. Neither do the
RTL8168d/8111d.
For 8136 series, make sure the ALDPS is disabled before loading the
firmware. For 8168 series, the ALDPS would be disabled automatically
when loading firmware. You must not disable it directly.
Signed-off-by: Hayes Wang
---
drivers/net/ethernet/realtek/r8169.c | 56 +---
1 file changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index e7ff886..2317b8c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -687,6 +687,7 @@ enum features {
RTL_FEATURE_WOL = (1 << 0),
RTL_FEATURE_MSI = (1 << 1),
RTL_FEATURE_GMII= (1 << 2),
+ RTL_FEATURE_FW_LOADED = (1 << 3),
};
struct rtl8169_counters {
@@ -2394,8 +2395,10 @@ static void rtl_apply_firmware(struct rtl8169_private
*tp)
struct rtl_fw *rtl_fw = tp->rtl_fw;
/* TODO: release firmware once rtl_phy_write_fw signals failures. */
- if (!IS_ERR_OR_NULL(rtl_fw))
+ if (!IS_ERR_OR_NULL(rtl_fw)) {
rtl_phy_write_fw(tp, rtl_fw);
+ tp->features |= RTL_FEATURE_FW_LOADED;
+ }
}
static void rtl_apply_firmware_cond(struct rtl8169_private *tp, u8 reg, u16
val)
@@ -2406,6 +2409,31 @@ static void rtl_apply_firmware_cond(struct
rtl8169_private *tp, u8 reg, u16 val)
rtl_apply_firmware(tp);
}
+static void r810x_aldps_disable(struct rtl8169_private *tp)
+{
+ rtl_writephy(tp, 0x1f, 0x);
+ rtl_writephy(tp, 0x18, 0x0310);
+ msleep(100);
+}
+
+static void r810x_aldps_enable(struct rtl8169_private *tp)
+{
+ if (!(tp->features & RTL_FEATURE_FW_LOADED))
+ return;
+
+ rtl_writephy(tp, 0x1f, 0x);
+ rtl_writephy(tp, 0x18, 0x8310);
+}
+
+static void r8168_aldps_enable_1(struct rtl8169_private *tp)
+{
+ if (!(tp->features & RTL_FEATURE_FW_LOADED))
+ return;
+
+ rtl_writephy(tp, 0x1f, 0x);
+ rtl_w1w0_phy(tp, 0x15, 0x1000, 0x);
+}
+
static void rtl8169s_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -3178,6 +3206,8 @@ static void rtl8168e_2_hw_phy_config(struct
rtl8169_private *tp)
rtl_w1w0_phy(tp, 0x19, 0x, 0x0001);
rtl_w1w0_phy(tp, 0x10, 0x, 0x0400);
rtl_writephy(tp, 0x1f, 0x);
+
+ r8168_aldps_enable_1(tp);
}
static void rtl8168f_hw_phy_config(struct rtl8169_private *tp)
@@ -3250,6 +3280,8 @@ static void rtl8168f_1_hw_phy_config(struct
rtl8169_private *tp)
rtl_writephy(tp, 0x05, 0x8b85);
rtl_w1w0_phy(tp, 0x06, 0x4000, 0x);
rtl_writephy(tp, 0x1f, 0x);
+
+ r8168_aldps_enable_1(tp);
}
static void rtl8168f_2_hw_phy_config(struct rtl8169_private *tp)
@@ -3257,6 +3289,8 @@ static void rtl8168f_2_hw_phy_config(struct
rtl8169_private *tp)
rtl_apply_firmware(tp);
rtl8168f_hw_phy_config(tp);
+
+ r8168_aldps_enable_1(tp);
}
static void rtl8411_hw_phy_config(struct rtl8169_private *tp)
@@ -3354,6 +3388,8 @@ static void rtl8411_hw_phy_config(struct rtl8169_private
*tp)
rtl_w1w0_phy(tp, 0x19, 0x, 0x0001);
rtl_w1w0_phy(tp, 0x10, 0x, 0x0400);
rtl_writephy(tp, 0x1f, 0x);
+
+ r8168_aldps_enable_1(tp);
}
static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp)
@@ -3439,21 +3475,19 @@ static void rtl8105e_hw_phy_config(struct
rtl8169_private *tp)
};
/* Disable ALDPS before ram code */
- rtl_writephy(tp, 0x1f, 0x);
- rtl_writephy(tp, 0x18, 0x0310);
- msleep(100);
+ r810x_aldps_disable(tp);
rtl_apply_firmware(tp);
rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+
+ r810x_aldps_enable(tp);
}
static void rtl8402_hw_phy_config(struct rtl8169_private *tp)
{
/* Disable ALDPS before setting firmware */
- rtl_writephy(tp, 0x1f, 0x);
- rtl_writephy(tp, 0x18, 0x0310);
- msleep(20);
+ r810x_aldps_disable(tp);
rtl_apply_firmware(tp);
@@ -3463,6 +3497,8 @@ static void rtl8402_hw_phy_config(struct rtl8169_private
*tp)
rtl_writephy(tp, 0x10, 0x401f);
rtl_writephy(tp, 0x19, 0x7030);
rtl_writephy(tp, 0x1f, 0x);
+
+ r810x_aldps_enable(tp);
}
static void rtl8106e_hw_phy_config(struct rtl8169_private *tp)
@@ -3475,9 +3511,7 @@ static void rtl8106e_hw_phy_config(struct rtl8169_private
*tp)
};
/* Disable ALDPS before ram code */
- rtl_writephy(tp, 0x1f, 0x);
- rtl_writephy(tp, 0x18, 0x0310);
- msleep(100);
+ r810x_aldp
Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
Am 10/24/2012 0:23, schrieb Jeff King: > For the fold-on-rebase idea, I'd think you would want something similar, > like setting rebase.foldNotes to "foo" to say "refs/notes/foo contains > pseudo-headers that should be folded in like a signed-off-by". If you are rebasing anyway, you can already use interactive rebase's --autosquash option: # a late ACK came in: git commit --allow-empty -m'squash! tile: support GENERIC_ Acked-by: A U Thor ' git rebase -i --keep-empty --autosquash $forkpoint Requires git 1.7.11 for --keep-empty and requires to edit out the 'squash!...' headers when the editor appears during the rebase. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 116/193] drivers/ptp: remove CONFIG_EXPERIMENTAL
On Tue, Oct 23, 2012 at 01:03:09PM -0700, Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. > > CC: Richard Cochran > Signed-off-by: Kees Cook Acked-by: Richard Cochran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] staging/comedi: Use pr_ or dev_ printks in drivers/usbduxfast.c
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then
pr_info(... to printk(KERN_INFO ...
and added pr_fmt.
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/comedi/drivers/usbduxfast.c | 152 +--
1 file changed, 71 insertions(+), 81 deletions(-)
diff --git a/drivers/staging/comedi/drivers/usbduxfast.c
b/drivers/staging/comedi/drivers/usbduxfast.c
index 1154a7e..060d853dc 100644
--- a/drivers/staging/comedi/drivers/usbduxfast.c
+++ b/drivers/staging/comedi/drivers/usbduxfast.c
@@ -37,6 +37,8 @@
* udev coldplug problem
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -216,8 +218,9 @@ static int send_dux_commands(struct usbduxfastsub_s *udfs,
int cmd_type)
usb_sndbulkpipe(udfs->usbdev, CHANNELLISTEP),
udfs->dux_commands, SIZEOFDUXBUFFER, &nsent, 1);
if (tmp < 0)
- printk(KERN_ERR "comedi%d: could not transmit dux_commands to"
- "the usb-device, err=%d\n", udfs->comedidev->minor, tmp);
+ dev_err(&udfs->interface->dev,
+ "could not transmit dux_commands to the usb-device,
err=%d\n",
+ tmp);
return tmp;
}
@@ -252,7 +255,7 @@ static int usbduxfast_ai_stop(struct usbduxfastsub_s *udfs,
int do_unlink)
int ret = 0;
if (!udfs) {
- printk(KERN_ERR "comedi?: usbduxfast_ai_stop: udfs=NULL!\n");
+ pr_err("%s: udfs=NULL!\n", __func__);
return -EFAULT;
}
#ifdef CONFIG_COMEDI_DEBUG
@@ -284,7 +287,7 @@ static int usbduxfast_ai_cancel(struct comedi_device *dev,
#endif
udfs = dev->private;
if (!udfs) {
- printk(KERN_ERR "comedi: usbduxfast_ai_cancel: udfs=NULL\n");
+ dev_err(dev->class_dev, "%s: udfs=NULL\n", __func__);
return -EFAULT;
}
down(&udfs->sem);
@@ -313,22 +316,19 @@ static void usbduxfastsub_ai_Irq(struct urb *urb)
/* sanity checks - is the urb there? */
if (!urb) {
- printk(KERN_ERR "comedi_: usbduxfast_: ao int-handler called "
- "with urb=NULL!\n");
+ pr_err("ao int-handler called with urb=NULL!\n");
return;
}
/* the context variable points to the subdevice */
this_comedidev = urb->context;
if (!this_comedidev) {
- printk(KERN_ERR "comedi_: usbduxfast_: urb context is a NULL "
- "pointer!\n");
+ pr_err("urb context is a NULL pointer!\n");
return;
}
/* the private structure of the subdevice is usbduxfastsub_s */
udfs = this_comedidev->private;
if (!udfs) {
- printk(KERN_ERR "comedi_: usbduxfast_: private of comedi "
- "subdev is a NULL pointer!\n");
+ pr_err("private of comedi subdev is a NULL pointer!\n");
return;
}
/* are we running a command? */
@@ -427,8 +427,8 @@ static void usbduxfastsub_ai_Irq(struct urb *urb)
urb->status = 0;
err = usb_submit_urb(urb, GFP_ATOMIC);
if (err < 0) {
- printk(KERN_ERR "comedi%d: usbduxfast: urb resubm failed: %d",
- udfs->comedidev->minor, err);
+ dev_err(&urb->dev->dev,
+ "urb resubm failed: %d", err);
s->async->events |= COMEDI_CB_EOA;
s->async->events |= COMEDI_CB_ERROR;
comedi_event(udfs->comedidev, s);
@@ -477,8 +477,8 @@ static int usbduxfastsub_stop(struct usbduxfastsub_s *udfs)
local_transfer_buffer, 1, /* Length */
EZTIMEOUT); /* Timeout */
if (ret < 0) {
- printk(KERN_ERR "comedi_: usbduxfast: control msg failed "
- "(stop)\n");
+ dev_err(&udfs->interface->dev,
+ "control msg failed (stop)\n");
return ret;
}
@@ -512,7 +512,7 @@ static int usbduxfastsub_upload(struct usbduxfastsub_s
*udfs,
#endif
if (ret < 0) {
- printk(KERN_ERR "comedi_: usbduxfast: uppload failed\n");
+ dev_err(&udfs->interface->dev, "uppload failed\n");
return ret;
}
@@ -538,8 +538,8 @@ static int usbduxfastsub_submit_InURBs(struct
usbduxfastsub_s *udfs)
#endif
ret = usb_submit_urb(udfs->urbIn, GFP_ATOMIC);
if (ret) {
- printk(KERN_ERR "comedi_: usbduxfast: ai: usb_submit_urb error"
- " %d\n", ret);
+ dev_err(&udfs->interface->dev,
+ "ai: usb_submit_urb error %d\n", ret);
return ret;
Re: [PATCH] mtd: use the NAND_STATUS_FAIL to replace the hardcode
ping
On Mon, Oct 15, 2012 at 11:47 AM, Huang Shijie wrote:
> Use the NAND_STATUS_FAIL to replace the hardcode "0x01",
> which make the code more readable.
>
> Signed-off-by: Huang Shijie
> ---
> drivers/mtd/nand/nand_base.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index d5ece6e..4569174 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -899,7 +899,7 @@ static int __nand_unlock(struct mtd_info *mtd, loff_t ofs,
> /* Call wait ready function */
> status = chip->waitfunc(mtd, chip);
> /* See if device thinks it succeeded */
> - if (status & 0x01) {
> + if (status & NAND_STATUS_FAIL) {
> pr_debug("%s: error status = 0x%08x\n",
> __func__, status);
> ret = -EIO;
> @@ -1004,7 +1004,7 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs,
> uint64_t len)
> /* Call wait ready function */
> status = chip->waitfunc(mtd, chip);
> /* See if device thinks it succeeded */
> - if (status & 0x01) {
> + if (status & NAND_STATUS_FAIL) {
> pr_debug("%s: error status = 0x%08x\n",
> __func__, status);
> ret = -EIO;
> --
> 1.7.4.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] mtd: gpmi: remove unneccessary header
ping.
On Sun, Oct 14, 2012 at 1:03 AM, Huang Shijie wrote:
> The whole gpmi-nand driver has turned to pure devicetree supported.
> So the linux/mtd/gpmi-nand.h is not neccessary now. Just remove it,
> and move some macros to the gpmi-nand driver itself.
>
> Signed-off-by: Huang Shijie
> ---
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c |1 -
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c |7 +++-
> drivers/mtd/nand/gpmi-nand/gpmi-nand.h |1 -
> include/linux/mtd/gpmi-nand.h | 68
>
> 4 files changed, 6 insertions(+), 71 deletions(-)
> delete mode 100644 include/linux/mtd/gpmi-nand.h
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> index 3502acc..1585c5b 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> @@ -18,7 +18,6 @@
> * with this program; if not, write to the Free Software Foundation, Inc.,
> * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> */
> -#include
> #include
> #include
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index e2c56fc..d376198 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -33,6 +32,12 @@
> #include
> #include "gpmi-nand.h"
>
> +/* Resource names for the GPMI NAND driver. */
> +#define GPMI_NAND_GPMI_REGS_ADDR_RES_NAME "gpmi-nand"
> +#define GPMI_NAND_BCH_REGS_ADDR_RES_NAME "bch"
> +#define GPMI_NAND_BCH_INTERRUPT_RES_NAME "bch"
> +#define GPMI_NAND_DMA_INTERRUPT_RES_NAME "gpmi-dma"
> +
> /* add our owner bbt descriptor */
> static uint8_t scan_ff_pattern[] = { 0xff };
> static struct nand_bbt_descr gpmi_bbt_descr = {
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> index 7ac25c1..3d93a5e 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> @@ -130,7 +130,6 @@ struct gpmi_nand_data {
> /* System Interface */
> struct device *dev;
> struct platform_device *pdev;
> - struct gpmi_nand_platform_data *pdata;
>
> /* Resources */
> struct resourcesresources;
> diff --git a/include/linux/mtd/gpmi-nand.h b/include/linux/mtd/gpmi-nand.h
> deleted file mode 100644
> index ed3c4e0..000
> --- a/include/linux/mtd/gpmi-nand.h
> +++ /dev/null
> @@ -1,68 +0,0 @@
> -/*
> - * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License along
> - * with this program; if not, write to the Free Software Foundation, Inc.,
> - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> - */
> -
> -#ifndef __MACH_MXS_GPMI_NAND_H__
> -#define __MACH_MXS_GPMI_NAND_H__
> -
> -/* The size of the resources is fixed. */
> -#define GPMI_NAND_RES_SIZE 6
> -
> -/* Resource names for the GPMI NAND driver. */
> -#define GPMI_NAND_GPMI_REGS_ADDR_RES_NAME "gpmi-nand"
> -#define GPMI_NAND_GPMI_INTERRUPT_RES_NAME "GPMI NAND GPMI Interrupt"
> -#define GPMI_NAND_BCH_REGS_ADDR_RES_NAME "bch"
> -#define GPMI_NAND_BCH_INTERRUPT_RES_NAME "bch"
> -#define GPMI_NAND_DMA_CHANNELS_RES_NAME"GPMI NAND DMA Channels"
> -#define GPMI_NAND_DMA_INTERRUPT_RES_NAME "gpmi-dma"
> -
> -/**
> - * struct gpmi_nand_platform_data - GPMI NAND driver platform data.
> - *
> - * This structure communicates platform-specific information to the GPMI NAND
> - * driver that can't be expressed as resources.
> - *
> - * @platform_init: A pointer to a function the driver will call to
> - * initialize the platform (e.g., set up the pin
> mux).
> - * @min_prop_delay_in_ns:Minimum propagation delay of GPMI signals to and
> - * from the NAND Flash device, in nanoseconds.
> - * @max_prop_delay_in_ns:Maximum propagation delay of GPMI signals to and
> - * from the NAND Flash device, in nanoseconds.
> - * @max_chip_count: The maximum number of chips for which the driver
> - * should configure the hardware. This value most
> - * likely reflects the number of pins that are
> - * conn
[PATCH v3] Fix a hard coding style when determining if a device is a container.
"ACPI0004","PNP0A05" and "PNP0A06" are all defined in array
container_device_ids[], so use it, but not the hard coding style.
Also, introduce a new api is_container_device() to determine if a
device is a container device.
change log v2 -> v3:
1. change the is_container_device()'s return value type from int to bool.
Signed-off-by: Tang Chen
Signed-off-by: Yasuaki Ishimatsu
---
drivers/acpi/container.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 1f9f7d7..69e2d6b 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -92,6 +92,19 @@ static int is_device_present(acpi_handle handle)
return ((sta & ACPI_STA_DEVICE_PRESENT) == ACPI_STA_DEVICE_PRESENT);
}
+static bool is_container_device(const char *hid)
+{
+ const struct acpi_device_id *container_id;
+
+ for (container_id = container_device_ids;
+container_id->id[0]; container_id++) {
+ if (!strcmp((char *)container_id->id, hid))
+ return true;
+ }
+
+ return false;
+}
+
/***/
static int acpi_container_add(struct acpi_device *device)
{
@@ -232,10 +245,8 @@ container_walk_namespace_cb(acpi_handle handle,
goto end;
}
- if (strcmp(hid, "ACPI0004") && strcmp(hid, "PNP0A05") &&
- strcmp(hid, "PNP0A06")) {
+ if (!is_container_device(hid))
goto end;
- }
switch (*action) {
case INSTALL_NOTIFY_HANDLER:
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] KVM: x86: fix vcpu->mmio_fragments overflow
After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling),
the pieces of io data can be collected and write them to the guest memory
or MMIO together
Unfortunately, kvm splits the mmio access into 8 bytes and store them to
vcpu->mmio_fragments. If the guest uses "rep ins" to move large data, it
will cause vcpu->mmio_fragments overflow
The bug can be exposed by isapc (-M isapc):
[23154.818733] general protection fault: [#1] SMP DEBUG_PAGEALLOC
[ ..]
[23154.858083] Call Trace:
[23154.859874] [] kvm_get_cr8+0x1d/0x28 [kvm]
[23154.861677] [] kvm_arch_vcpu_ioctl_run+0xcda/0xe45 [kvm]
[23154.863604] [] ? kvm_arch_vcpu_load+0x17b/0x180 [kvm]
Actually, we can use one mmio_fragment to store a large mmio access then
split it when we pass the mmio-exit-info to userspace. After that, we only
need two entries to store mmio info for the cross-mmio pages access
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/x86.c | 60 ++
include/linux/kvm_host.h | 15 +--
2 files changed, 36 insertions(+), 39 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 8b90dd5..ec07cd3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3781,7 +3781,7 @@ static int write_exit_mmio(struct kvm_vcpu *vcpu, gpa_t
gpa,
{
struct kvm_mmio_fragment *frag = &vcpu->mmio_fragments[0];
- memcpy(vcpu->run->mmio.data, frag->data, frag->len);
+ memcpy(vcpu->run->mmio.data, frag->data, min(8u, frag->len));
return X86EMUL_CONTINUE;
}
@@ -3834,18 +3834,11 @@ mmio:
bytes -= handled;
val += handled;
- while (bytes) {
- unsigned now = min(bytes, 8U);
-
- frag = &vcpu->mmio_fragments[vcpu->mmio_nr_fragments++];
- frag->gpa = gpa;
- frag->data = val;
- frag->len = now;
-
- gpa += now;
- val += now;
- bytes -= now;
- }
+ WARN_ON(vcpu->mmio_nr_fragments >= KVM_MAX_MMIO_FRAGMENTS);
+ frag = &vcpu->mmio_fragments[vcpu->mmio_nr_fragments++];
+ frag->gpa = gpa;
+ frag->data = val;
+ frag->len = bytes;
return X86EMUL_CONTINUE;
}
@@ -3892,7 +3885,7 @@ int emulator_read_write(struct x86_emulate_ctxt *ctxt,
unsigned long addr,
vcpu->mmio_needed = 1;
vcpu->mmio_cur_fragment = 0;
- vcpu->run->mmio.len = vcpu->mmio_fragments[0].len;
+ vcpu->run->mmio.len = min(8u, vcpu->mmio_fragments[0].len);
vcpu->run->mmio.is_write = vcpu->mmio_is_write = ops->write;
vcpu->run->exit_reason = KVM_EXIT_MMIO;
vcpu->run->mmio.phys_addr = gpa;
@@ -5524,28 +5517,44 @@ static int complete_emulated_pio(struct kvm_vcpu *vcpu)
*
* read:
* for each fragment
- * write gpa, len
- * exit
- * copy data
+ * for each mmio piece in the fragment
+ * write gpa, len
+ * exit
+ * copy data
* execute insn
*
* write:
* for each fragment
- * write gpa, len
- * copy data
- * exit
+ * for each mmio piece in the fragment
+ * write gpa, len
+ * copy data
+ * exit
*/
static int complete_emulated_mmio(struct kvm_vcpu *vcpu)
{
struct kvm_run *run = vcpu->run;
struct kvm_mmio_fragment *frag;
+ unsigned len;
BUG_ON(!vcpu->mmio_needed);
/* Complete previous fragment */
- frag = &vcpu->mmio_fragments[vcpu->mmio_cur_fragment++];
+ frag = &vcpu->mmio_fragments[vcpu->mmio_cur_fragment];
+ len = min(8u, frag->len);
if (!vcpu->mmio_is_write)
- memcpy(frag->data, run->mmio.data, frag->len);
+ memcpy(frag->data, run->mmio.data, len);
+
+ if (frag->len <= 8) {
+ /* Switch to the next fragment. */
+ frag++;
+ vcpu->mmio_cur_fragment++;
+ } else {
+ /* Go forward to the next mmio piece. */
+ frag->data += len;
+ frag->gpa += len;
+ frag->len -= len;
+ }
+
if (vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments) {
vcpu->mmio_needed = 0;
if (vcpu->mmio_is_write)
@@ -5553,13 +5562,12 @@ static int complete_emulated_mmio(struct kvm_vcpu *vcpu)
vcpu->mmio_read_completed = 1;
return complete_emulated_io(vcpu);
}
- /* Initiate next fragment */
- ++frag;
+
run->exit_reason = KVM_EXIT_MMIO;
run->mmio.phys_addr = frag->gpa;
if (vcpu->mmio_is_write)
- memcpy(run->mmio.data, frag->data, frag->len);
- run->mmio.len = frag->len;
+ memcpy(run->mmio.data, frag->data, min(8u, frag->len));
+ run->mmio.len = min(8u, frag->len);
run->mmio.is_write = vcpu->mmio_is_write;
vcpu->arch.complete_userspace_io = complete_emulated_mmio;
return 0;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_hos
[PATCH v2 0/2] ACPI: container hot remove support.
Hi, The container hotplug handler container_notify_cb() didn't implement the hot-remove functionality. So, these 2 patches implement it like the following way: patch 1. Do not use kacpid_wq/kacpid_notify_wq to handle container hotplug event, use kacpi_hotplug_wq instead to avoid deadlock. Doing this is to reuse acpi_bus_hot_remove_device() in container hot-remove handling. patch 2. Introduce a new function container_device_remove() to handle ACPI_NOTIFY_EJECT_REQUEST event for container. change log v1 -> v2: 1. In patch1: Based on the lastest for-pci-split-pci-root-hp-2 branch from Lu Yinghai, use alloc_acpi_hp_work() to add container hotplug work into kacpi_hotplug_wq. 2. In patch2: Allocate ej_event after container is stopped, so that we don't need to kfree the ej_event if stopping container failed. This is based on Lu Yinghai's job. git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-split-pci-root-hp-2 Tang Chen (2): Use kacpi_hotplug_wq to handle container hotplug event. Improve container_notify_cb() to support container hot-remove. drivers/acpi/container.c | 75 +++-- 1 files changed, 65 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] Use kacpi_hotplug_wq to handle container hotplug event.
As the comments in __acpi_os_execute() said:
We can't run hotplug code in keventd_wq/kacpid_wq/kacpid_notify_wq
because the hotplug code may call driver .remove() functions,
which invoke flush_scheduled_work/acpi_os_wait_events_complete
to flush these workqueues.
we should keep the hotplug code in kacpi_hotplug_wq.
But we have the following call series in kernel now:
acpi_ev_queue_notify_request()
|--> acpi_os_execute()
|--> __acpi_os_execute(type, function, context, 0)
The last parameter 0 makes the container_notify_cb() executed in
kacpi_notify_wq or kacpid_wq. So, we need to put the real hotplug code
into kacpi_hotplug_wq.
Signed-off-by: Tang Chen
---
drivers/acpi/container.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 69e2d6b..d300e03 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#define PREFIX "ACPI: "
@@ -165,14 +166,21 @@ static int container_device_add(struct acpi_device
**device, acpi_handle handle)
return result;
}
-static void container_notify_cb(acpi_handle handle, u32 type, void *context)
+static void __container_notify_cb(struct work_struct *work)
{
struct acpi_device *device = NULL;
int result;
int present;
acpi_status status;
+ struct acpi_hp_work *hp_work;
+ acpi_handle handle;
+ u32 type;
u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
+ hp_work = container_of(work, struct acpi_hp_work, work);
+ handle = hp_work->handle;
+ type = hp_work->type;
+
switch (type) {
case ACPI_NOTIFY_BUS_CHECK:
/* Fall through */
@@ -224,6 +232,13 @@ static void container_notify_cb(acpi_handle handle, u32
type, void *context)
return;
}
+static void container_notify_cb(acpi_handle handle, u32 type,
+ void *context)
+{
+ alloc_acpi_hp_work(handle, type, context,
+ __container_notify_cb);
+}
+
static acpi_status
container_walk_namespace_cb(acpi_handle handle,
u32 lvl, void *context, void **rv)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpufreq: governors: remove redundant code
On 22 October 2012 14:16, Viresh Kumar wrote: > On 20 October 2012 01:42, Viresh Kumar wrote: >> Initially ondemand governor was written and then using its code conservative >> governor is written. It used a lot of code from ondemand governor, but copy >> of >> code was created instead of using the same routines from both governors. >> Which >> increased code redundancy, which is difficult to manage. >> >> This patch is an attempt to move common part of both the governors to >> cpufreq_governor.c file to come over above mentioned issues. >> >> This shouldn't change anything from functionality point of view. >> >> Signed-off-by: Viresh Kumar For everybody else, this patch is already pushed by Rafael in his linux-next branch. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] Improve container_notify_cb() to support container hot-remove.
This patch introduces a new function container_device_remove() to do
the container hot-remove job. It works like the following:
1. call acpi_bus_trim(device, 0) to stop the container device.
2. generate the KOBJ_OFFLINE uevent. (Did I do this correct ?)
3. call acpi_bus_hot_remove_device(), which will call acpi_bus_trim(device, 1)
to remove the container.
This patch is based on Lu Yinghai's work.
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-pci-split-pci-root-hp-2
Signed-off-by: Tang Chen
---
drivers/acpi/container.c | 58 ++---
1 files changed, 49 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index d300e03..9676578 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -166,6 +166,35 @@ static int container_device_add(struct acpi_device
**device, acpi_handle handle)
return result;
}
+static int container_device_remove(struct acpi_device *device)
+{
+ int ret;
+ struct acpi_eject_event *ej_event;
+
+ /* stop container device at first */
+ ret = acpi_bus_trim(device, 0);
+ printk(KERN_WARNING "acpi_bus_trim stop return %x\n", ret);
+ if (ret)
+ return ret;
+
+ /* event originated from ACPI eject notification */
+ device->flags.eject_pending = 1;
+
+ /* send the uevent before remove the device */
+ kobject_uevent(&device->dev.kobj, KOBJ_OFFLINE);
+
+ ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
+ if (!ej_event)
+ return -ENOMEM;
+
+ ej_event->device = device;
+ ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
+
+ acpi_bus_hot_remove_device(ej_event);
+
+ return 0;
+}
+
static void __container_notify_cb(struct work_struct *work)
{
struct acpi_device *device = NULL;
@@ -181,6 +210,9 @@ static void __container_notify_cb(struct work_struct *work)
handle = hp_work->handle;
type = hp_work->type;
+ present = is_device_present(handle);
+ status = acpi_bus_get_device(handle, &device);
+
switch (type) {
case ACPI_NOTIFY_BUS_CHECK:
/* Fall through */
@@ -189,13 +221,14 @@ static void __container_notify_cb(struct work_struct
*work)
(type == ACPI_NOTIFY_BUS_CHECK) ?
"ACPI_NOTIFY_BUS_CHECK" : "ACPI_NOTIFY_DEVICE_CHECK");
- present = is_device_present(handle);
- status = acpi_bus_get_device(handle, &device);
if (!present) {
if (ACPI_SUCCESS(status)) {
/* device exist and this is a remove request */
- device->flags.eject_pending = 1;
- kobject_uevent(&device->dev.kobj, KOBJ_OFFLINE);
+ result = container_device_remove(device);
+ if (result) {
+ printk(KERN_WARNING "Failed to remove
container\n");
+ break;
+ }
return;
}
break;
@@ -215,12 +248,19 @@ static void __container_notify_cb(struct work_struct
*work)
break;
case ACPI_NOTIFY_EJECT_REQUEST:
- if (!acpi_bus_get_device(handle, &device) && device) {
- device->flags.eject_pending = 1;
- kobject_uevent(&device->dev.kobj, KOBJ_OFFLINE);
- return;
+ printk(KERN_WARNING "Container driver received %s event\n",
+ "ACPI_NOTIFY_EJECT_REQUEST");
+
+ if (!present || ACPI_FAILURE(status) || !device)
+ break;
+
+ result = container_device_remove(device);
+ if (result) {
+ printk(KERN_WARNING "Failed to remove container\n");
+ break;
}
- break;
+
+ return;
default:
/* non-hotplug event; possibly handled by other handler */
--
1.7.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/
[tip:perf/urgent] perf tools: do not flush maps on COMM for perf report
Commit-ID: 9fdbf671ba7e8adb2cbb93d716232ebcab55f6bd
Gitweb: http://git.kernel.org/tip/9fdbf671ba7e8adb2cbb93d716232ebcab55f6bd
Author: Luigi Semenzato
AuthorDate: Tue, 21 Aug 2012 14:52:20 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 22 Oct 2012 13:55:53 -0200
perf tools: do not flush maps on COMM for perf report
This fixes a long-standing bug caused by the lack of separate COMM and EXEC
record types, which makes "perf report" lose track of symbols when a process
renames itself.
With this fix (suggested by Stephane Eranian), a COMM (rename) no longer
flushes the maps, which is the correct behavior. An EXEC also no longer
flushes the maps, but this doesn't matter because as new mappings are created
(for the executable and the libraries) the old mappings are automatically
removed. This is not by accident: the functionality is necessary because DLLs
can be explicitly loaded at any time with dlopen(), possibly on top of existing
text, so "perf report" handles correctly the clobbering of new mappings on top
of old ones.
An alternative patch (which I proposed earlier) would be to introduce a
separate PERF_RECORD_EXEC type, but it is a much larger change (about 300
lines) and is not necessary.
Signed-off-by: Luigi Semenzato
Tested-by: Stephane Eranian
Acked-by: Stephane Eranian
Cc: "Eric W. Biederman"
Cc: "Rafael J. Wysocki"
Cc: Alexander Viro
Cc: Andi Kleen
Cc: Andrew Morton
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: Lucas De Marchi
Cc: Namhyung Kim
Cc: Oleg Nesterov
Cc: Olof Johansson
Cc: Paul Gortmaker
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Robert Richter
Cc: Sonny Rao
Cc: Stephane Eranian
Cc: Stephen Wilson
Cc: Tejun Heo
Cc: Vasiliy Kulikov
Link:
http://lkml.kernel.org/r/1345585940-6497-1-git-send-email-semenz...@chromium.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/thread.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index fb4b7ea..8b3e593 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -39,7 +39,6 @@ int thread__set_comm(struct thread *self, const char *comm)
err = self->comm == NULL ? -ENOMEM : 0;
if (!err) {
self->comm_set = true;
- map_groups__flush(&self->mg);
}
return err;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:perf/urgent] perf help: Fix --help for builtins
Commit-ID: 670ab5d21c7e168c89a36fdd2c69fb7af63d35a1
Gitweb: http://git.kernel.org/tip/670ab5d21c7e168c89a36fdd2c69fb7af63d35a1
Author: Namhyung Kim
AuthorDate: Mon, 22 Oct 2012 16:12:23 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 22 Oct 2012 12:35:49 -0200
perf help: Fix --help for builtins
It seems that commit cc5848213329 ("perf help: Remove use of die and
handle errors") caused the problem - it changed the initial value of
'help_format' from HELP_FORMAT_MAN to HELP_FORMAT_NONE.
This broke the --help option for all builtins, that would produce no
output, while 'man perf-top' would work it MANPATH is properly setup.
Reported-by: Stephane Eranian
Signed-off-by: Namhyung Kim
Tested-by: David Ahern
Acked-by: David Ahern
Cc: David Ahern
Cc: Jiri Olsa
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/r/87r4orj7zc@sejong.aot.lge.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-help.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/perf/builtin-help.c b/tools/perf/builtin-help.c
index 411ee56..178b88a 100644
--- a/tools/perf/builtin-help.c
+++ b/tools/perf/builtin-help.c
@@ -414,7 +414,7 @@ static int show_html_page(const char *perf_cmd)
int cmd_help(int argc, const char **argv, const char *prefix __maybe_unused)
{
bool show_all = false;
- enum help_format help_format = HELP_FORMAT_NONE;
+ enum help_format help_format = HELP_FORMAT_MAN;
struct option builtin_help_options[] = {
OPT_BOOLEAN('a', "all", &show_all, "print all available commands"),
OPT_SET_UINT('m', "man", &help_format, "show man page",
HELP_FORMAT_MAN),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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:perf/urgent] perf trace: Check if sample raw_data field is set
Commit-ID: fc551f8d4427150da1ee7cbb0f53525c49ef4bca
Gitweb: http://git.kernel.org/tip/fc551f8d4427150da1ee7cbb0f53525c49ef4bca
Author: Arnaldo Carvalho de Melo
AuthorDate: Sat, 20 Oct 2012 13:08:46 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Sun, 21 Oct 2012 23:07:36 -0200
perf trace: Check if sample raw_data field is set
Sometimes we're segfaulting because we were expecting that the
perf_sample.raw_data field was set as requested, but in some cases
that needs further investigation, that field can be NULL, leading
to segfaults.
Make the tool more robust by checking that before calling any per event
handlers that may try to use that field.
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-g1fmodl6ys4lq8honbj1i...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-trace.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 83c6515..7aaee39 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -268,6 +268,13 @@ again:
if (evlist->threads->map[0] == -1 ||
evlist->threads->nr > 1)
printf("%d ", sample.tid);
+ if (sample.raw_data == NULL) {
+ printf("%s sample with no payload for tid: %d,
cpu %d, raw_size=%d, skipping...\n",
+ perf_evsel__name(evsel), sample.tid,
+ sample.cpu, sample.raw_size);
+ continue;
+ }
+
handler = evsel->handler.func;
handler(trace, evsel, &sample);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 031/193] arch/x86: remove CONFIG_EXPERIMENTAL
* Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. > > CC: Thomas Gleixner > CC: Ingo Molnar > CC: "H. Peter Anvin" > Signed-off-by: Kees Cook Acked-by: Ingo Molnar Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/urgent] perf trace: Validate syscall id before growing syscall table
Commit-ID: 3a531260a14631ae8d231279b8738884bf808e7b
Gitweb: http://git.kernel.org/tip/3a531260a14631ae8d231279b8738884bf808e7b
Author: Arnaldo Carvalho de Melo
AuthorDate: Sat, 20 Oct 2012 12:39:03 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Sun, 21 Oct 2012 23:07:36 -0200
perf trace: Validate syscall id before growing syscall table
In some cases the ID for a syscall read thru the raw_syscalls tracepoint
is bogus, still needs to be investigated why, but to make the tool more
robust first try to resolve the ID to a name via libaudit and if it
fails, don't grow the table.
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-0lsokw3xor7c4ijo45u6b...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-trace.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index dec8ced..83c6515 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -56,6 +56,10 @@ static int trace__read_syscall_info(struct trace *trace, int
id)
{
char tp_name[128];
struct syscall *sc;
+ const char *name = audit_syscall_to_name(id, trace->audit_machine);
+
+ if (name == NULL)
+ return -1;
if (id > trace->syscalls.max) {
struct syscall *nsyscalls = realloc(trace->syscalls.table, (id
+ 1) * sizeof(*sc));
@@ -75,11 +79,8 @@ static int trace__read_syscall_info(struct trace *trace, int
id)
}
sc = trace->syscalls.table + id;
- sc->name = audit_syscall_to_name(id, trace->audit_machine);
- if (sc->name == NULL)
- return -1;
-
- sc->fmt = syscall_fmt__find(sc->name);
+ sc->name = name;
+ sc->fmt = syscall_fmt__find(sc->name);
snprintf(tp_name, sizeof(tp_name), "sys_enter_%s", sc->name);
sc->tp_format = event_format__new("syscalls", tp_name);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE
* Linus Torvalds wrote: > On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote: > >> > >> It is spelled: > >> > >> git notes add -m SHA1 > > > > Cool! > > Don't use them for anything global. > > Use them for local codeflow, but don't expect them to be > distributed. It's a separate "flow", and while it *can* be > distributed, it's not going to be for the kernel, for example. > So no, don't start using this to ack things, because the acks > *will* get lost. I'd also add a small meta argument: that it would be actively wrong to *allow* 'belated' acks to be added. In practice acks are most useful *before* a commit gets created and they often have a mostly buerocratic role afterwards. So we should encourage timely acks (which actually help development), and accept ack-less patches as long as they are correct and create no problems. More utility, less buerocracy. Incorrect, ack-less patches causing problems will get all the flames they deserve. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] lp855x_bl: use generic PWM functions
On Mon, Oct 22, 2012 at 03:30:12PM -0700, Andrew Morton wrote: > On Fri, 19 Oct 2012 08:45:14 + > "Kim, Milo" wrote: > > > > Generally this looks good. Obviously you'll need to update any users of > > > this driver as well. It might make sense to include those changes in > > > this patch to avoid interim build failures. > > > > Thanks for your review. > > So far no usages for this driver in the mainline. > > I've tested it in my own development environment instead. > > > > > Other than that I have just one smaller comment below. > > > > > > > + pwm_config(lp->pwm, duty, period); > > > > + duty == 0 ? pwm_disable(lp->pwm) : pwm_enable(lp->pwm); > > > > > > This is really ugly and should be written explicitly: > > > > > > if (duty == 0) > > > pwm_disable(lp->pwm); > > > else > > > pwm_enable(lp->pwm); > > > > Oh, I prefer using '?' to if-sentence because it looks clear to me. > > But if it's difficult to read/understand, I'll fix it. > > I'd like to have others' opinion. > > > > Hey, it's better than > > (*(duty ? pwm_enable : pwm_disable))(lp->pwm); > > ! Indeed. Fortunately there don't seem to be overly many of those. Anyway, thanks for taking these patches. Thierry pgpum3VleL9dr.pgp Description: PGP signature
[PATCH V2 1/7] perf, x86: Reduce lbr_sel_map size
From: "Yan, Zheng"
The index of lbr_sel_map is bit value of perf branch_sample_type.
By using bit shift as index, we can reduce lbr_sel_map size.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 4 +++
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 50 ++
include/uapi/linux/perf_event.h| 42 +
3 files changed, 56 insertions(+), 40 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index d3b3bb7..ea6749a 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -412,6 +412,10 @@ struct x86_pmu {
struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr);
};
+enum {
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 31fe046..7d9ae5f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -61,10 +61,6 @@ enum {
#define LBR_FROM_FLAG_INTX (1ULL << 62)
#define LBR_FROM_FLAG_ABORT(1ULL << 61)
-#define for_each_branch_sample_type(x) \
- for ((x) = PERF_SAMPLE_BRANCH_USER; \
-(x) < PERF_SAMPLE_BRANCH_MAX; (x) <<= 1)
-
/*
* x86control flow change classification
* x86control flow changes include branches, interrupts, traps, faults
@@ -378,14 +374,14 @@ static int intel_pmu_setup_hw_lbr_filter(struct
perf_event *event)
{
struct hw_perf_event_extra *reg;
u64 br_type = event->attr.branch_sample_type;
- u64 mask = 0, m;
- u64 v;
+ u64 mask = 0, v;
+ int i;
- for_each_branch_sample_type(m) {
- if (!(br_type & m))
+ for (i = 0; i < PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE; i++) {
+ if (!(br_type & (1U << i)))
continue;
- v = x86_pmu.lbr_sel_map[m];
+ v = x86_pmu.lbr_sel_map[i];
if (v == LBR_NOT_SUPP)
return -EOPNOTSUPP;
@@ -631,33 +627,33 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
/*
* Map interface branch filters onto LBR filters
*/
-static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
- [PERF_SAMPLE_BRANCH_ANY]= LBR_ANY,
- [PERF_SAMPLE_BRANCH_USER] = LBR_USER,
- [PERF_SAMPLE_BRANCH_KERNEL] = LBR_KERNEL,
- [PERF_SAMPLE_BRANCH_HV] = LBR_IGN,
- [PERF_SAMPLE_BRANCH_ANY_RETURN] = LBR_RETURN | LBR_REL_JMP
- | LBR_IND_JMP | LBR_FAR,
+static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE] = {
+ [PERF_SAMPLE_BRANCH_ANY_SHIFT] = LBR_ANY,
+ [PERF_SAMPLE_BRANCH_USER_SHIFT] = LBR_USER,
+ [PERF_SAMPLE_BRANCH_KERNEL_SHIFT] = LBR_KERNEL,
+ [PERF_SAMPLE_BRANCH_HV_SHIFT] = LBR_IGN,
+ [PERF_SAMPLE_BRANCH_ANY_RETURN_SHIFT] = LBR_RETURN | LBR_REL_JMP
+ | LBR_IND_JMP | LBR_FAR,
/*
* NHM/WSM erratum: must include REL_JMP+IND_JMP to get CALL branches
*/
- [PERF_SAMPLE_BRANCH_ANY_CALL] =
+ [PERF_SAMPLE_BRANCH_ANY_CALL_SHIFT] =
LBR_REL_CALL | LBR_IND_CALL | LBR_REL_JMP | LBR_IND_JMP | LBR_FAR,
/*
* NHM/WSM erratum: must include IND_JMP to capture IND_CALL
*/
- [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL | LBR_IND_JMP,
+ [PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL | LBR_IND_JMP,
};
-static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
- [PERF_SAMPLE_BRANCH_ANY]= LBR_ANY,
- [PERF_SAMPLE_BRANCH_USER] = LBR_USER,
- [PERF_SAMPLE_BRANCH_KERNEL] = LBR_KERNEL,
- [PERF_SAMPLE_BRANCH_HV] = LBR_IGN,
- [PERF_SAMPLE_BRANCH_ANY_RETURN] = LBR_RETURN | LBR_FAR,
- [PERF_SAMPLE_BRANCH_ANY_CALL] = LBR_REL_CALL | LBR_IND_CALL
- | LBR_FAR,
- [PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL,
+static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE] = {
+ [PERF_SAMPLE_BRANCH_ANY_SHIFT] = LBR_ANY,
+ [PERF_SAMPLE_BRANCH_USER_SHIFT] = LBR_USER,
+ [PERF_SAMPLE_BRANCH_KERNEL_SHIFT] = LBR_KERNEL,
+ [PERF_SAMPLE_BRANCH_HV_SHIFT] = LBR_IGN,
+ [PERF_SAMPLE_BRANCH_ANY_RETURN_SHIFT] = LBR_RETURN | LBR_FAR,
+ [PERF_SAMPLE_BRANCH_ANY_CALL_SHIFT] = LBR_REL_CALL | LBR_IND_CALL
+ | LBR_FAR,
+ [PERF_SAMPLE_BRANCH_IND_CALL_SHIFT] = LBR_IND_CALL,
};
/* core */
diff --git a/include/uapi/linux/perf_event.h b/include/uap
[PATCH V2 0/7] perf, x86: Haswell LBR call stack support
From: "Yan, Zheng" Haswell has a new feature that utilizes the existing Last Branch Record facility to record call chains. When the feature is enabled, function call will be collected as normal, but as return instructions are executed the last captured branch record is popped from the on-chip LBR registers. The LBR call stack facility can help perf to get call chains of progam without frame pointer. The LBR call stack has following known limitations 1. Zero length calls are not filtered out by hardware 2. Exception handing such as setjmp/longjmp will have calls/returns not match 3. Pushing different return address onto the stack will have calls/returns not match The patch series depends on Andi's "perf PMU support for Haswel" patches --- Changes since v1 - not expose PERF_SAMPLE_BRANCH_CALL_STACK to user space - save/restore LBR stack on context switch for all sampling branch modes - reduce lbr_sel_map size -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/7] perf, x86: Introduce x86 special perf event context
From: "Yan, Zheng"
The x86 special perf event context is named x86_perf_event_context,
We can enlarge it later to store PMU special data.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 12
arch/x86/kernel/cpu/perf_event.h | 4
include/linux/perf_event.h | 5 +
kernel/events/core.c | 28 ++--
4 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 08e61a6..3361114 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1606,6 +1606,17 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
+{
+ struct perf_event_context *ctx;
+
+ ctx = kzalloc(sizeof(struct x86_perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+
+ return ctx;
+}
+
static ssize_t get_attr_rdpmc(struct device *cdev,
struct device_attribute *attr,
char *buf)
@@ -1695,6 +1706,7 @@ static struct pmu pmu = {
.event_idx = x86_pmu_event_idx,
.flush_branch_stack = x86_pmu_flush_branch_stack,
+ .event_context_alloc= x86_pmu_event_context_alloc,
};
void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index a555a2c..55ca981 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -419,6 +419,10 @@ enum {
PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
+struct x86_perf_event_context {
+ struct perf_event_context ctx;
+};
+
#define x86_add_quirk(func_) \
do { \
static struct x86_pmu_quirk __quirk __initdata = { \
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 7e6a4b6..2868fcf 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -264,6 +264,11 @@ struct pmu {
* flush branch stack on context-switches (needed in cpu-wide mode)
*/
void (*flush_branch_stack) (void);
+
+ /*
+* Allocate PMU special perf event context
+*/
+ void *(*event_context_alloc)(struct perf_event_context *parent_ctx);
};
/**
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 534810d..c886018 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2721,13 +2721,20 @@ static void __perf_event_init_context(struct
perf_event_context *ctx)
}
static struct perf_event_context *
-alloc_perf_context(struct pmu *pmu, struct task_struct *task)
+alloc_perf_context(struct pmu *pmu, struct task_struct *task,
+ struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
- ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
- if (!ctx)
- return NULL;
+ if (pmu->event_context_alloc) {
+ ctx = pmu->event_context_alloc(parent_ctx);
+ if (IS_ERR(ctx))
+ return ctx;
+ } else {
+ ctx = kzalloc(sizeof(struct perf_event_context), GFP_KERNEL);
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+ }
__perf_event_init_context(ctx);
if (task) {
@@ -2813,10 +2820,11 @@ retry:
++ctx->pin_count;
raw_spin_unlock_irqrestore(&ctx->lock, flags);
} else {
- ctx = alloc_perf_context(pmu, task);
- err = -ENOMEM;
- if (!ctx)
+ ctx = alloc_perf_context(pmu, task, NULL);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
goto errout;
+ }
err = 0;
mutex_lock(&task->perf_event_mutex);
@@ -7132,9 +7140,9 @@ inherit_task_group(struct perf_event *event, struct
task_struct *parent,
* child.
*/
- child_ctx = alloc_perf_context(event->pmu, child);
- if (!child_ctx)
- return -ENOMEM;
+ child_ctx = alloc_perf_context(event->pmu, child, parent_ctx);
+ if (IS_ERR(child_ctx))
+ return PTR_ERR(child_ctx);
child->perf_event_ctxp[ctxn] = child_ctx;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 5/7] perf, core: Pass perf_sample_data to perf_callchain()
From: "Yan, Zheng"
New Intel CPU can record call chains by using existing last branch
record facility. perf_callchain_user() can make use of the call
chains recorded by hardware in case of there is no frame pointer.
Signed-off-by: Yan, Zheng
---
arch/arm/kernel/perf_event.c | 4 ++--
arch/powerpc/perf/callchain.c| 4 ++--
arch/sparc/kernel/perf_event.c | 4 ++--
arch/x86/kernel/cpu/perf_event.c | 4 ++--
include/linux/perf_event.h | 3 ++-
kernel/events/callchain.c| 8 +---
kernel/events/core.c | 2 +-
kernel/events/internal.h | 3 ++-
8 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 93971b1..7cd3eba 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -567,8 +567,8 @@ user_backtrace(struct frame_tail __user *tail,
return buftail.fp - 1;
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct frame_tail __user *tail;
diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
index 74d1e78..b379ebc 100644
--- a/arch/powerpc/perf/callchain.c
+++ b/arch/powerpc/perf/callchain.c
@@ -482,8 +482,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
}
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
if (current_is_64bit())
perf_callchain_user_64(entry, regs);
diff --git a/arch/sparc/kernel/perf_event.c b/arch/sparc/kernel/perf_event.c
index 885a8af..6e9c62c 100644
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@ -1775,8 +1775,8 @@ static void perf_callchain_user_32(struct
perf_callchain_entry *entry,
} while (entry->nr < PERF_MAX_STACK_DEPTH);
}
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
perf_callchain_store(entry, regs->tpc);
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 119687d..8ae8044 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1839,8 +1839,8 @@ perf_callchain_user32(struct pt_regs *regs, struct
perf_callchain_entry *entry)
}
#endif
-void
-perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
+void perf_callchain_user(struct perf_callchain_entry *entry,
+struct pt_regs *regs, struct perf_sample_data *data)
{
struct stack_frame frame;
const void __user *fp;
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9151bdd..803b511 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -706,7 +706,8 @@ extern void perf_event_fork(struct task_struct *tsk);
/* Callchains */
DECLARE_PER_CPU(struct perf_callchain_entry, perf_callchain_entry);
-extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs);
+extern void perf_callchain_user(struct perf_callchain_entry *entry, struct
pt_regs *regs,
+ struct perf_sample_data *data);
extern void perf_callchain_kernel(struct perf_callchain_entry *entry, struct
pt_regs *regs);
static inline void perf_callchain_store(struct perf_callchain_entry *entry,
u64 ip)
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index c772061..bd7138a 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -30,7 +30,8 @@ __weak void perf_callchain_kernel(struct perf_callchain_entry
*entry,
}
__weak void perf_callchain_user(struct perf_callchain_entry *entry,
- struct pt_regs *regs)
+ struct pt_regs *regs,
+ struct perf_sample_data *data)
{
}
@@ -154,7 +155,8 @@ put_callchain_entry(int rctx)
}
struct perf_callchain_entry *
-perf_callchain(struct perf_event *event, struct pt_regs *regs)
+perf_callchain(struct perf_event *event, struct pt_regs *regs,
+ struct perf_sample_data *data)
{
int rctx;
struct perf_callchain_entry *entry;
@@ -195,7 +197,7 @@ perf_callchain(struct perf_event *event, struct pt_regs
*regs)
goto exit_put;
perf_callchain_store(entry, PERF_CONTEXT_USER);
- perf_callchain_user(entry, regs);
+ perf_callchain_user(entry, regs, data);
}
}
diff --git a/kernel/events/core.c b/kernel/events/core.c
[PATCH V2 6/7] perf, x86: Use LBR call stack to get user callchain
From: "Yan, Zheng"
Try enabling the LBR call stack feature if event request recording
callchain. Try utilizing the LBR call stack to get user callchain
in case of there is no frame pointer.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 126 +
arch/x86/kernel/cpu/perf_event.h | 7 ++
arch/x86/kernel/cpu/perf_event_intel.c | 20 ++---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 3 +
include/linux/perf_event.h | 6 ++
kernel/events/core.c | 11 ++-
6 files changed, 124 insertions(+), 49 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 8ae8044..3bf2100 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -398,35 +398,46 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip > precise)
return -EOPNOTSUPP;
- /*
-* check that PEBS LBR correction does not conflict with
-* whatever the user is asking with attr->branch_sample_type
-*/
- if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format
< 2) {
- u64 *br_type = &event->attr.branch_sample_type;
-
- if (has_branch_stack(event)) {
- if (!precise_br_compat(event))
- return -EOPNOTSUPP;
-
- /* branch_sample_type is compatible */
-
- } else {
- /*
-* user did not specify branch_sample_type
-*
-* For PEBS fixups, we capture all
-* the branches at the priv level of the
-* event.
-*/
- *br_type = PERF_SAMPLE_BRANCH_ANY;
-
- if (!event->attr.exclude_user)
- *br_type |= PERF_SAMPLE_BRANCH_USER;
-
- if (!event->attr.exclude_kernel)
- *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
- }
+ }
+ /*
+* check that PEBS LBR correction does not conflict with
+* whatever the user is asking with attr->branch_sample_type
+*/
+ if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format < 2) {
+ u64 *br_type = &event->attr.branch_sample_type;
+
+ if (has_branch_stack(event)) {
+ if (!precise_br_compat(event))
+ return -EOPNOTSUPP;
+
+ /* branch_sample_type is compatible */
+
+ } else {
+ /*
+* user did not specify branch_sample_type
+*
+* For PEBS fixups, we capture all
+* the branches at the priv level of the
+* event.
+*/
+ *br_type = PERF_SAMPLE_BRANCH_ANY;
+
+ if (!event->attr.exclude_user)
+ *br_type |= PERF_SAMPLE_BRANCH_USER;
+
+ if (!event->attr.exclude_kernel)
+ *br_type |= PERF_SAMPLE_BRANCH_KERNEL;
+ }
+ } else if (event->attr.sample_type & PERF_SAMPLE_CALLCHAIN) {
+ if (!has_branch_stack(event) && x86_pmu.attr_lbr_callstack) {
+ /*
+* user did not specify branch_sample_type,
+* try using the LBR call stack facility to
+* record call chains in the user space.
+*/
+ event->attr.branch_sample_type =
+ PERF_SAMPLE_BRANCH_USER |
+ PERF_SAMPLE_BRANCH_CALL_STACK;
}
}
@@ -1663,12 +1674,35 @@ static ssize_t set_attr_rdpmc(struct device *cdev,
return count;
}
+static ssize_t get_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr, char *buf)
+{
+ return snprintf(buf, 40, "%d\n", x86_pmu.attr_lbr_callstack);
+}
+
+static ssize_t set_attr_lbr_callstack(struct device *cdev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned long val = simple_strtoul(buf, NULL, 0);
+
+ if (x86_pmu.attr_lbr_callstack != !!val) {
+ if (val && !x86_pmu_has_lbr_callstack())
+ return -EOPNOTSUPP;
+ x86_pmu.attr_lbr_callstack = !!val;
+ }
+ return count;
+}
+
static DEVICE_AT
[PATCH V2 4/7] perf, x86: Save/resotre LBR stack during context switch
From: "Yan, Zheng"
When the LBR call stack is enabled, it is necessary to save/restore
the stack on context switch. The solution is saving/restoring the
stack to/from task's perf event context. If task has no perf event
context, just flush the stack on context switch.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.c | 18 +++--
arch/x86/kernel/cpu/perf_event.h | 13 +++-
arch/x86/kernel/cpu/perf_event_intel.c | 13 ++--
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 108 ++---
include/linux/perf_event.h | 6 +-
kernel/events/core.c | 64 ++---
6 files changed, 168 insertions(+), 54 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 3361114..119687d 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1606,6 +1606,13 @@ static int x86_pmu_event_idx(struct perf_event *event)
return idx + 1;
}
+static void x86_pmu_branch_stack_sched(struct perf_event_context *ctx,
+ bool sched_in)
+{
+ if (x86_pmu.branch_stack_sched)
+ x86_pmu.branch_stack_sched(ctx, sched_in);
+}
+
static void *x86_pmu_event_context_alloc(struct perf_event_context *parent_ctx)
{
struct perf_event_context *ctx;
@@ -1614,6 +1621,9 @@ static void *x86_pmu_event_context_alloc(struct
perf_event_context *parent_ctx)
if (!ctx)
return ERR_PTR(-ENOMEM);
+ if (parent_ctx)
+ intel_pmu_lbr_init_context(ctx, parent_ctx);
+
return ctx;
}
@@ -1673,12 +1683,6 @@ static const struct attribute_group
*x86_pmu_attr_groups[] = {
NULL,
};
-static void x86_pmu_flush_branch_stack(void)
-{
- if (x86_pmu.flush_branch_stack)
- x86_pmu.flush_branch_stack();
-}
-
void perf_check_microcode(void)
{
if (x86_pmu.check_microcode)
@@ -1705,7 +1709,7 @@ static struct pmu pmu = {
.commit_txn = x86_pmu_commit_txn,
.event_idx = x86_pmu_event_idx,
- .flush_branch_stack = x86_pmu_flush_branch_stack,
+ .branch_stack_sched = x86_pmu_branch_stack_sched,
.event_context_alloc= x86_pmu_event_context_alloc,
};
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 55ca981..bff282c 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -369,7 +369,6 @@ struct x86_pmu {
void(*cpu_dead)(int cpu);
void(*check_microcode)(void);
- void(*flush_branch_stack)(void);
/*
* Intel Arch Perfmon v2+
@@ -399,6 +398,8 @@ struct x86_pmu {
int lbr_nr;/* hardware stack size */
u64 lbr_sel_mask; /* LBR_SELECT valid bits */
const int *lbr_sel_map; /* lbr_select mappings */
+ void(*branch_stack_sched)(struct perf_event_context *ctx,
+ bool sched_in);
/*
* Extra registers for events
@@ -421,6 +422,12 @@ enum {
struct x86_perf_event_context {
struct perf_event_context ctx;
+
+ u64 lbr_from[MAX_LBR_ENTRIES];
+ u64 lbr_to[MAX_LBR_ENTRIES];
+ u64 lbr_stack_gen;
+ int lbr_callstack_users;
+ bool lbr_stack_saved;
};
#define x86_add_quirk(func_) \
@@ -622,8 +629,12 @@ void intel_pmu_pebs_disable_all(void);
void intel_ds_init(void);
+void intel_pmu_lbr_init_context(struct perf_event_context *child_ctx,
+ struct perf_event_context *parent_ctx);
void intel_pmu_lbr_reset(void);
+void intel_pmu_lbr_sched(struct perf_event_context *ctx, bool sched_in);
+
void intel_pmu_lbr_enable(struct perf_event *event);
void intel_pmu_lbr_disable(struct perf_event *event);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 727fd74..dc2282d 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -1807,16 +1807,11 @@ static void intel_pmu_cpu_dying(int cpu)
fini_debug_store_on_cpu(cpu);
}
-static void intel_pmu_flush_branch_stack(void)
+static void intel_pmu_branch_stack_sched(struct perf_event_context *ctx,
+bool sched_in)
{
- /*
-* Intel LBR does not tag entries with the
-* PID of the current task, then we need to
-* flush it on ctxsw
-* For now, we simply reset it
-*/
if (x86_pmu.lbr_nr)
- intel_pmu_lbr_reset();
+ intel_pmu_lbr_sched(ctx, sched_in);
}
PMU_FORMAT_ATTR(offcore_rsp, "config1:0-63");
@@ -1881,7 +1876,7 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_starting = intel_
[PATCH V2 2/7] perf, x86: Basic Haswell LBR call stack support
From: "Yan, Zheng"
The new HSW call stack feature provides a facility such that
unfiltered call data will be collected as normal, but as return
instructions are executed the last captured branch record is
popped from the LBR stack. Thus, branch information relative to
leaf functions will not be captured, while preserving the call
stack information of the main line execution path.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event.h | 7 ++-
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 89 ++
3 files changed, 74 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index ea6749a..a555a2c 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -413,7 +413,10 @@ struct x86_pmu {
};
enum {
- PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT = PERF_SAMPLE_BRANCH_MAX_SHIFT,
+ PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE,
+
+ PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
};
#define x86_add_quirk(func_) \
@@ -635,6 +638,8 @@ void intel_pmu_lbr_init_atom(void);
void intel_pmu_lbr_init_snb(void);
+void intel_pmu_lbr_init_hsw(void);
+
int intel_pmu_setup_lbr_filter(struct perf_event *event);
int p4_pmu_init(void);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 8d981c3..727fd74 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2353,7 +2353,7 @@ __init int intel_pmu_init(void)
memcpy(hw_cache_event_ids, snb_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
- intel_pmu_lbr_init_nhm();
+ intel_pmu_lbr_init_hsw();
x86_pmu.event_constraints = intel_hsw_event_constraints;
x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 7d9ae5f..9d35c54 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -31,6 +31,7 @@ enum {
#define LBR_IND_JMP_BIT6 /* do not capture indirect jumps */
#define LBR_REL_JMP_BIT7 /* do not capture relative jumps */
#define LBR_FAR_BIT8 /* do not capture far branches */
+#define LBR_CALL_STACK_BIT 9 /* enable call stack */
#define LBR_KERNEL (1 << LBR_KERNEL_BIT)
#define LBR_USER (1 << LBR_USER_BIT)
@@ -41,6 +42,7 @@ enum {
#define LBR_REL_JMP(1 << LBR_REL_JMP_BIT)
#define LBR_IND_JMP(1 << LBR_IND_JMP_BIT)
#define LBR_FAR(1 << LBR_FAR_BIT)
+#define LBR_CALL_STACK (1 << LBR_CALL_STACK_BIT)
#define LBR_PLM (LBR_KERNEL | LBR_USER)
@@ -66,24 +68,25 @@ enum {
* x86control flow changes include branches, interrupts, traps, faults
*/
enum {
- X86_BR_NONE = 0, /* unknown */
-
- X86_BR_USER = 1 << 0, /* branch target is user */
- X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
-
- X86_BR_CALL = 1 << 2, /* call */
- X86_BR_RET = 1 << 3, /* return */
- X86_BR_SYSCALL = 1 << 4, /* syscall */
- X86_BR_SYSRET = 1 << 5, /* syscall return */
- X86_BR_INT = 1 << 6, /* sw interrupt */
- X86_BR_IRET = 1 << 7, /* return from interrupt */
- X86_BR_JCC = 1 << 8, /* conditional */
- X86_BR_JMP = 1 << 9, /* jump */
- X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
- X86_BR_IND_CALL = 1 << 11,/* indirect calls */
- X86_BR_ABORT= 1 << 12,/* transaction abort */
- X86_BR_INTX = 1 << 13,/* in transaction */
- X86_BR_NOTX = 1 << 14,/* not in transaction */
+ X86_BR_NONE = 0, /* unknown */
+
+ X86_BR_USER = 1 << 0, /* branch target is user */
+ X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
+
+ X86_BR_CALL = 1 << 2, /* call */
+ X86_BR_RET = 1 << 3, /* return */
+ X86_BR_SYSCALL = 1 << 4, /* syscall */
+ X86_BR_SYSRET = 1 << 5, /* syscall return */
+ X86_BR_INT = 1 << 6, /* sw interrupt */
+ X86_BR_IRET = 1 << 7, /* return from interrupt */
+ X86_BR_JCC = 1 << 8, /* conditional */
+ X86_BR_JMP = 1 << 9, /* jump */
+ X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
+ X86_BR_IND_CALL = 1 << 11,/* indirect calls */
+ X86_BR_ABORT= 1 << 12,/* transaction abort */
+ X86_BR_INTX = 1 << 13,/* in transaction */
+ X86_BR_NOTX = 1 << 14,/* not in transaction */
[PATCH V2 7/7] perf, x86: Discard zero length call entries in LBR call stack
From: "Yan, Zheng"
Zero length calls may confuse the hardware and make the recorded
call stack incorrect. Try fixing the call stack by discarding
zero length call entries.
Signed-off-by: Yan, Zheng
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 4879904..012ddca 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -86,7 +86,8 @@ enum {
X86_BR_ABORT= 1 << 12,/* transaction abort */
X86_BR_INTX = 1 << 13,/* in transaction */
X86_BR_NOTX = 1 << 14,/* not in transaction */
- X86_BR_CALL_STACK = 1 << 15,/* call stack */
+ X86_BR_ZERO_CALL= 1 << 15,/* zero length call */
+ X86_BR_CALL_STACK = 1 << 16,/* call stack */
};
#define X86_BR_PLM (X86_BR_USER | X86_BR_KERNEL)
@@ -103,13 +104,15 @@ enum {
X86_BR_JMP |\
X86_BR_IRQ |\
X86_BR_ABORT|\
-X86_BR_IND_CALL)
+X86_BR_IND_CALL |\
+X86_BR_ZERO_CALL)
#define X86_BR_ALL (X86_BR_PLM | X86_BR_ANY)
#define X86_BR_ANY_CALL \
(X86_BR_CALL|\
X86_BR_IND_CALL|\
+X86_BR_ZERO_CALL |\
X86_BR_SYSCALL |\
X86_BR_IRQ |\
X86_BR_INT)
@@ -625,6 +628,12 @@ static int branch_type(unsigned long from, unsigned long
to, int abort)
ret = X86_BR_INT;
break;
case 0xe8: /* call near rel */
+ insn_get_immediate(&insn);
+ if (insn.immediate1.value == 0) {
+ /* zero length call */
+ ret = X86_BR_ZERO_CALL;
+ break;
+ }
case 0x9a: /* call far absolute */
ret = X86_BR_CALL;
break;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 1/2] r8169: enable ALDPS for power saving
Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
> > +static void r810x_aldps_disable(struct rtl8169_private *tp)
> > +{
> > + rtl_writephy(tp, 0x1f, 0x);
> > + rtl_writephy(tp, 0x18, 0x0310);
> > + msleep(100);
> > +}
>
> rtl8402_hw_phy_config used a msleep(20). Meguesses it won't
> hurt, right ?
No, it won't hurt. The delay make suer there is enough time to pause ALDPS.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next 1/2] r8169: enable ALDPS for power saving
Francois Romieu [mailto:rom...@fr.zoreil.com] [...] > It would be nice to state these things in the commit message, namely: > - ALDPS should never be enabled for the RTL8105e > - none of the firmware-free chipsets support ALDPS > - neither do the RTL8168d/8111d Excuse me. I don't understand why the RTL8105e shouldn't enable ALDPS. Best Regards, Hayes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PWM: Add SPEAr PWM chip driver support
On Mon, Oct 22, 2012 at 02:20:26PM +0200, Lars-Peter Clausen wrote:
> On 10/22/2012 09:55 AM, Thierry Reding wrote:
> > On Mon, Oct 22, 2012 at 11:51:11AM +0530, Viresh Kumar wrote:
> >> On 22 October 2012 11:36, Shiraz Hashim wrote:
> >>> On Mon, Oct 22, 2012 at 09:39:21AM +0530, viresh kumar wrote:
> On Mon, Oct 22, 2012 at 9:21 AM, Shiraz Hashim
> wrote:
> >>
> > +static int spear_pwm_remove(struct platform_device *pdev)
> > +{
> > + struct spear_pwm_chip *pc = platform_get_drvdata(pdev);
> > + int i;
> > +
> > + for (i = 0; i < NUM_PWM; i++) {
> > + struct pwm_device *pwm = &pc->chip.pwms[i];
> > +
> > + if (test_bit(PWMF_ENABLED, &pwm->flags)) {
> > + spear_pwm_writel(pc, i, PWMCR, 0);
> > + clk_disable(pc->clk);
> > + }
> > + }
> > +
> > + /* clk was prepared in probe, hence unprepare it here */
> > + clk_unprepare(pc->clk);
>
> I believe you need to remove the chip first and then do above to
> avoid any race conditions, that might occur.
> >>>
> >>> I am afraid, I would loose all chips and their related information
> >>> (PWMF_ENABLED) then.
> >>
> >> I have just checked core's code, and yes you are correct.
> >> Now i have another doubt :)
> >>
> >> Why shouldn't you do this instead:
> >>
> >>for (i = 0; i < NUM_PWM; i++)
> >> pwm_diable(&pc->chip.pwms[i]);
> >>
> >> And, why should we put above code in pwmchip_remove() instead, so that
> >> pwm drivers don't need to do all this?
> >>
> >> @Thierry: Your inputs are required here :)
> >
> > We could probably do that in the core. I've had some discussions about
> > this with Lars-Peter (Cc'ed) who also had doubts about how this is
> > currently handled.
> >
> > The problem is that the core driver code ignores errors from the
> > driver's .remove() callback, so actually returning the error of
> > pwmchip_remove() here isn't terribly useful. I had actually assumed
> > (without checking the code) that the device wouldn't be removed if an
> > error was returned, but that isn't true.
> >
> > IIRC Lars-Peter suggested that we do reference counting on PWM devices
> > so that they could stay around after the module is unloaded but return
> > errors (-ENODEV?) on all operations to make sure users are aware of them
> > disappearing.
> >
> > What you're proposing is different, however. If we put that code in the
> > core it will mean that once the module is unloaded, all PWM devices will
> > be disabled. There is currently code in the core that prevents the chip
> > from being removed if one or more PWM devices are busy. But as explained
> > above, with the current core code this return value isn't useful at all.
> >
> > This needs to be addressed, but I'm not quite sure how yet. Obviously it
> > cannot be solved in the core, because the PWM devices may be provided by
> > real hotpluggable devices, so just preventing the driver from being
> > removed won't help.
>
> In my opinion it would make sense to put this into the PWM core. Even if the
> device is still physically connected, e.g. because it is a on-SoC device, it
> should be stopped if the device is removed. You do not want the PWM device
> to continue to provide it's service (which is the PWM signal) after the
> device has been removed. This means this is something that needs to be
> implemented by every PWM driver.
Alright. Let's keep it in the driver for now and I'll remove it once I
get around to implementing the functionality in the core.
Thierry
pgpwZzldkQzR8.pgp
Description: PGP signature
[RESEND PATCH] module: Fix kallsyms to show the last symbol properly
This patch fixes a bug that the last symbol in the .symtab section of
kernel modules is not displayed with /proc/kallsyms. This happens
because the first symbol is processed twice before and inside the loop
without incrementing "src".
This bug exists since the following commit was introduced.
module: reduce symbol table for loaded modules (v2)
commit: 4a4962263f07d14660849ec134ee42b63e95ea9a
This patch is tested on 3.7-rc2 kernel with the simple test module by the
below steps, to check if all the core symbols appear in /proc/kallsyms.
[Test steps]
1. Compile the test module, like below.
(My compiler tends to put a function named with 18 charactors,
like zz, at the end of .symtab section.
I don't know why, though.)
# cat tp.c
#include
#include
void zz(void) {}
static int init_tp(void)
{
return 0;
}
static void exit_tp(void) {}
module_init(init_tp);
module_exit(exit_tp);
MODULE_LICENSE("GPL");
# cat Makefile
KERNEL_RELEASE=$(shell uname -r)
BUILDDIR := /lib/modules/$(KERNEL_RELEASE)/source
obj-m := tp.o
all:
$(MAKE) -C $(BUILDDIR) M=$(PWD) V=1 modules
clean:
$(MAKE) -C $(BUILDDIR) M=$(PWD) V=1 clean
# make
2. Check if the target symbol, zz in this case,
is located at the last entry.
# readelf -s tp.ko | tail
18: 002011 FUNCLOCAL DEFAULT2 exit_tp
19: 12 OBJECT LOCAL DEFAULT4 __mod_license15
20: 0 FILELOCAL DEFAULT ABS tp.mod.c
21: 000c 9 OBJECT LOCAL DEFAULT4 __module_depends
22: 001545 OBJECT LOCAL DEFAULT4 __mod_vermagic5
23: 600 OBJECT GLOBAL DEFAULT8 __this_module
24: 002011 FUNCGLOBAL DEFAULT2 cleanup_module
25: 001013 FUNCGLOBAL DEFAULT2 init_module
26: 0 NOTYPE GLOBAL DEFAULT UND mcount
27: 11 FUNCGLOBAL DEFAULT2 zz
3. Load the module.
# insmod tp.ko
4. Check if all the core symbols are shown /proc/kallsyms properly.
[Before my patch applied]
# grep "\[tp\]" /proc/kallsyms
a0135010 t init_tp [tp]
a0135020 t exit_tp [tp]
a0137000 d __this_module[tp]
a0135020 t cleanup_module [tp]
a0135010 t init_module [tp]
(The last entry, or zz, is not shown.)
[After my patch applied]
# grep "\[tp\]" /proc/kallsyms
a0135010 t init_tp [tp]
a0135020 t exit_tp [tp]
a0137000 d __this_module[tp]
a0135020 t cleanup_module [tp]
a0135010 t init_module [tp]
a0135000 t zz [tp]
(The last entry, or zz, is shown properly.)
Signed-off-by: Masaki Kimura
---
kernel/module.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/module.c b/kernel/module.c
index 6085f5e..1a48ffe 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2293,7 +2293,11 @@ static void layout_symtab(struct module *mod, struct
load_info *info)
src = (void *)info->hdr + symsect->sh_offset;
nsrc = symsect->sh_size / sizeof(*src);
- /* Compute total space required for the core symbols' strtab. */
+ /*
+* Compute total space required for the core symbols' strtab.
+* We start searching core symbols from the second entry.
+*/
+ src++;
for (ndst = i = strtab_size = 1; i < nsrc; ++i, ++src)
if (is_core_symbol(src, info->sechdrs, info->hdr->e_shnum)) {
strtab_size += strlen(&info->strtab[src->st_name]) + 1;
@@ -2334,6 +2338,8 @@ static void add_kallsyms(struct module *mod, const struct
load_info *info)
src = mod->symtab;
*dst = *src;
*s++ = 0;
+ /* We start searching core symbols from the second entry. */
+ src++;
for (ndst = i = 1; i < mod->num_symtab; ++i, ++src) {
if (!is_core_symbol(src, info->sechdrs, info->hdr->e_shnum))
continue;
--
1.7.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4] PWM: Add SPEAr PWM chip driver support
On Mon, Oct 22, 2012 at 04:36:41PM +0530, Shiraz Hashim wrote:
[...]
> +struct spear_pwm_chip {
> + void __iomem *mmio_base;
> + struct clk *clk;
> + struct pwm_chip chip;
My editor shows a tab between pwm_chip and chip. This should really be a
space.
> + ret = pwmchip_add(&pc->chip);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(pc->clk);
> + if (ret < 0)
> + return pwmchip_remove(&pc->chip);
I think in order to fix the potential race condition that Viresh
mentioned we should move the clk_prepare_enable() before the
pwmchip_add(), but don't forget to disable and unprepare the clock if
pwmchip_add() fails.
Actually, can't we make it a clk_prepare() only at this point and move
the clk_enable() and clk_disable() into the if block below? In case the
compatible value is not "st,spear1340-pwm" we don't need the clock
enabled.
> +
> + if (of_device_is_compatible(np, "st,spear1340-pwm")) {
> + /*
> + * Following enables PWM chip, channels would still be
> + * enabled individually through their control register
> + */
> + val = readl_relaxed(pc->mmio_base + PWMMCR);
> + val |= PWMMCR_PWM_ENABLE;
> + writel_relaxed(val, pc->mmio_base + PWMMCR);
> +
Oh, and a spurious newline here... =)
> + }
> +
> + /* only disable the clk and leave it prepared */
> + clk_disable(pc->clk);
This can go into the if block to match the clk_enable().
Thierry
pgpaMIyao45I9.pgp
Description: PGP signature
Re: [PATCH v5] posix timers: allocate timer id per process
* Eric Dumazet wrote: > On Wed, 2012-10-24 at 00:33 +0200, Thomas Gleixner wrote: > > On Tue, 23 Oct 2012, Eric Dumazet wrote: > > > > > On Tue, 2012-10-23 at 23:47 +0200, Thomas Gleixner wrote: > > > > > > > Not so good to me. > > > > > > > > > Signed-off-by: Eric Dumazet > > > > > > > > And that should be either an Acked-by or a Reviewed-by. You can't sign > > > > off on patches which have not been submitted or transported by you. > > > > > > I actually gave some input, provided a hash function, and so on. > > > > > > So this SOB was valid. I do that all the time. > > > > Not really. I recommend you to read the relevant file in Documentation > > which covers what can have your SOB. > > OK I did that again, and found this : > > The Signed-off-by: tag indicates that the signer was involved in the > development of the patch, or that he/she was in the patch's delivery > path. > > > And I was involved in the development of the patch. > > I understand you dont like it at all, so I'll remember not trying to > help anymore in this area. No, you are simply wrong and Linus would (rightfully) complain to *Thomas* if he added a SOB like that and pushed such a faulty commit to him. Linus has complained about such SOBs before and Thomas would be wrong to put them into commits. SOBs get added if you are the developer of the patch or if you are actually one of the 'hops' in the route of the patch that gets it to Thomas. SOBs don't get added over email like you did and what Thomas pointed out was simply a maintainer's job to point out. Adding credits for helping development get added via different tags, not via SOBs. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Replace the type check code with typecheck() in kfifo_in
Am Mittwoch, den 24.10.2012, 11:41 +0800 schrieb Wei Yang:
> In kfifo_in marco, one piece of code which is arounded by if(0) will check the
> type of __tmp->ptr_const and __buf. If they are different type, there will
> output a warning during compiling. This piece of code is not self explaining
> and a little bit hard to understand.
>
> Based on Andrew Morton's suggestion, this patch replace this with typecheck()
> which will be easy to understand.
>
> In the same file, there are several places with the same code style. This
> patch change them too.
>
> Signed-off-by: Wei Yang
> Reviewed-by: Andrew Morton
> Reviewed-by: richard -rw- weinberger
> ---
> include/linux/kfifo.h | 22 +-
> 1 files changed, 5 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
> index 10308c6..680c293 100644
> --- a/include/linux/kfifo.h
> +++ b/include/linux/kfifo.h
> @@ -390,10 +390,7 @@ __kfifo_int_must_check_helper( \
> unsigned int __ret; \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
> - __dummy = (typeof(__val))NULL; \
> - } \
> + typecheck(typeof(__tmp->ptr_const), __val); \
> if (__recsize) \
> __ret = __kfifo_in_r(__kfifo, __val, sizeof(*__val), \
> __recsize); \
> @@ -433,7 +430,7 @@ __kfifo_uint_must_check_helper( \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> if (0) \
> - __val = (typeof(__tmp->ptr))0; \
> + __val = (typeof(__tmp->ptr))NULL; \
> if (__recsize) \
> __ret = __kfifo_out_r(__kfifo, __val, sizeof(*__val), \
> __recsize); \
> @@ -512,10 +509,7 @@ __kfifo_uint_must_check_helper( \
> unsigned long __n = (n); \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
> - __dummy = (typeof(__buf))NULL; \
> - } \
> + typecheck(typeof(__tmp->ptr_const), __buf);\
> (__recsize) ?\
> __kfifo_in_r(__kfifo, __buf, __n, __recsize) : \
> __kfifo_in(__kfifo, __buf, __n); \
> @@ -565,10 +559,7 @@ __kfifo_uint_must_check_helper( \
> unsigned long __n = (n); \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr) __dummy = NULL; \
> - __buf = __dummy; \
> - } \
> + typecheck(typeof(__tmp->ptr), __buf); \
> (__recsize) ?\
> __kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
> __kfifo_out(__kfifo, __buf, __n); \
> @@ -777,10 +768,7 @@ __kfifo_uint_must_check_helper( \
> unsigned long __n = (n); \
> const size_t __recsize = sizeof(*__tmp->rectype); \
> struct __kfifo *__kfifo = &__tmp->kfifo; \
> - if (0) { \
> - typeof(__tmp->ptr) __dummy __attribute__ ((unused)) = NULL; \
> - __buf = __dummy; \
> - } \
> + typecheck(typeof(__tmp->ptr), __buf); \
> (__recsize) ? \
> __kfifo_out_peek_r(__kfifo, __buf, __n, __recsize) : \
> __kfifo_out_peek(__kfifo, __buf, __n); \
Acked-by: Stefani Seibold
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PWM: Add SPEAr PWM chip driver support
On Mon, Oct 22, 2012 at 07:25:45PM +0530, Viresh Kumar wrote:
> On 22 October 2012 16:36, Shiraz Hashim wrote:
> > Add support for PWM chips present on SPEAr platforms. These PWM
> > chips support 4 channel output with programmable duty cycle and
> > frequency.
> >
> > More details on these PWM chips can be obtained from relevant
> > chapter of reference manual, present at following[1] location.
> >
> > 1. http://www.st.com/internet/mcu/product/251211.jsp
> >
> > Cc: Thierry Reding
> > Signed-off-by: Shiraz Hashim
> > Signed-off-by: Viresh Kumar
> > Reviewed-by: Vipin Kumar
>
> Acked-by: Viresh Kumar
>
> > diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm/pwm-spear.c
> > +static int spear_pwm_probe(struct platform_device *pdev)
> > +{
>
> > + ret = pwmchip_add(&pc->chip);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
> > + return ret;
> > + }
>
> Sorry couldn't think of this complex situation earlier :(
>
> Can it happen that we get a request for a pwm here and its config or enable
> gets called...?
>
> If yes, then we must call clk_prepare() before doing pwmchip_add?? Otherwise
> you will see a crash :)
>
> @Thierry: Can this happen?
Yeah, it's very unlikely to happen, but it could. See my reply to the
patch.
Thierry
pgprkqPNAr0tc.pgp
Description: PGP signature
Re: [PATCH 2/2] firmware loader: introduce kernel parameter to customize fw search path
On Wed, Oct 24, 2012 at 11:31:16AM +0800, Ming Lei wrote: > On Wed, Oct 24, 2012 at 11:18 AM, Greg Kroah-Hartman > wrote: > > > > Ick, no, not another kernel boot parameter. I would prefer the /proc/ > > file solution instead, just like /proc/sys/kernel/hotplug is. > > OK, got it, but we could use the module parameter(firmware_class.path > via kernel command) to customize the search path too, couldn't we? Yes, but why? Let's not overdesign this, get the basics working and then, if someone really needs it, we can add it. 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 v3] pwm: vt8500: Update vt8500 PWM driver support
On Wed, Oct 24, 2012 at 04:46:58PM +1300, Tony Prisk wrote: > This patch updates pwm-vt8500.c to support devicetree probing and > make use of the common clock subsystem. > > A binding document describing the PWM controller found on > arch-vt8500 is also included. > > Signed-off-by: Tony Prisk > --- > v2/v3: > Fix errors/coding style as pointed out by Thierry Reding. > > .../devicetree/bindings/pwm/vt8500-pwm.txt | 17 > drivers/pwm/pwm-vt8500.c | 86 > ++-- > 2 files changed, 80 insertions(+), 23 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt Looking real good now. One last comment though and I think I'm ready to take this... > + err = clk_enable(vt8500->clk); > + if (err < 0) > + dev_err(chip->dev, "failed to enable clock\n"); > + return -EBUSY; > + }; Why do you return EBUSY instead of err? Thierry pgp6P4aMnBFoJ.pgp Description: PGP signature
Re: [RFC PATCH] gpiolib: add gpio get direction support
On Tue, Oct 23, 2012 at 1:06 PM, Mathias Nyman wrote: > [Me] >> Anyway, if the callback is only called internally in the GPIOlib >> why are you making the function public to the entire >> kernel > > Thought I'd do it the same was as gpio_direction_output() and > gpio_direction_input(), but if there is no need for getting the direction > outside gpiolob then it can be skipped. Main motivation was to get correct > direction values in debug and sysfs after boot. OK then keep them static til the day they are needed. > gpiolib currently uses cached values of gpio_direction_output/input() in > sysfs. If the .get_direction callback exists it is used to refresh the > cached values. OK! (I'm not yet familiar enough with gpiolib as you can see ...) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pidns: limit the nesting depth of pid namespaces
2012/10/24 Andrew Morton :
> On Fri, 12 Oct 2012 16:30:42 +0400
> Andrew Vagin wrote:
>
>> 'struct pid' is a "variable sized struct" - a header with an array
>> of upids at the end.
>>
>> A size of the array depends on a level (depth) of pid namespaces. Now
>> a level of pidns is not limited, so 'struct pid' can be more than one
>> page.
>>
>> Looks reasonable, that it should be less than a page. MAX_PIS_NS_LEVEL
>> is not calculated from PAGE_SIZE, because in this case it depends on
>> architectures, config options and it will be reduced, if someone adds a
>> new fields in struct pid or struct upid.
>>
>> I suggest to set MAX_PIS_NS_LEVEL = 32, because it saves ability to
>> expand "struct pid" and it's more than enough for all known for me
>> use-cases. When someone finds a reasonable use case, we can add a
>> config option or a sysctl parameter.
>>
>> In addition it will reduce effect of another problem, when we have many
>> nested namespaces and the oldest one starts dying. zap_pid_ns_processe
>> will be called for each namespace and find_vpid will be called for each
>> process in a namespace. find_vpid will be called minimum max_level^2 / 2
>> times. The reason of that is that when we found a bit in pidmap, we
>> can't determine this pidns is top for this process or it isn't.
>>
>> vpid is a heavy operation, so a fork bomb, which create many nested
>> namespace, can do a system inaccessible for a long time.
>>
>> --- a/kernel/pid_namespace.c
>> +++ b/kernel/pid_namespace.c
>> @@ -70,12 +70,18 @@ err_alloc:
>> return NULL;
>> }
>>
>> +/* MAX_PID_NS_LEVEL is needed for limiting size of 'struct pid' */
>> +#define MAX_PID_NS_LEVEL 32
>> +
>> static struct pid_namespace *create_pid_namespace(struct pid_namespace
>> *parent_pid_ns)
>> {
>> struct pid_namespace *ns;
>> unsigned int level = parent_pid_ns->level + 1;
>> int i, err = -ENOMEM;
>>
>> + if (level > MAX_PID_NS_LEVEL)
>> + goto out;
>> +
>> ns = kmem_cache_zalloc(pid_ns_cachep, GFP_KERNEL);
>> if (ns == NULL)
>> goto out;
>
> hm, OK. This will kind-of fix the free_pid_ns()-excessive-recursion
> issue which we already fixed by other means ;)
I caught both problems with help of an one program, which create many
nested namespaces. Actually this patch prevents another problem. A few
thousand nested namespaces is destroyed for more than one minutes and
in this period a system is inaccessible.
>
> I don't think this problem is serious enough to bother backporting into
> -stable but I guess we can/should do it in 3.7. Agree?
Yes.
>
> I think that returning -ENOMEM in response to an excessive nesting
> attempt is misleading - the system *didn't* run out of memory. EINVAL
> is better?
I chose ENOMEM by analogy with max_pid. When a new PID can not be
allocated, ENOMEM is returned too.
>
>
>
> From: Andrew Morton
> Subject: pidns-limit-the-nesting-depth-of-pid-namespaces-fix
>
> return -EINVAL in response to excessive nesting, not -ENOMEM
>
> Cc: "Eric W. Biederman"
> Cc: Andrew Vagin
> Cc: Cyrill Gorcunov
> Cc: Oleg Nesterov
> Cc: Pavel Emelyanov
> Signed-off-by: Andrew Morton
> ---
>
> kernel/pid_namespace.c |8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff -puN
> kernel/pid_namespace.c~pidns-limit-the-nesting-depth-of-pid-namespaces-fix
> kernel/pid_namespace.c
> ---
> a/kernel/pid_namespace.c~pidns-limit-the-nesting-depth-of-pid-namespaces-fix
> +++ a/kernel/pid_namespace.c
> @@ -78,11 +78,15 @@ static struct pid_namespace *create_pid_
> {
> struct pid_namespace *ns;
> unsigned int level = parent_pid_ns->level + 1;
> - int i, err = -ENOMEM;
> + int i;
> + int err;
>
> - if (level > MAX_PID_NS_LEVEL)
> + if (level > MAX_PID_NS_LEVEL) {
> + err = -EINVAL;
> goto out;
> + }
>
> + err = -ENOMEM;
> ns = kmem_cache_zalloc(pid_ns_cachep, GFP_KERNEL);
> if (ns == NULL)
> goto out;
> _
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] staging/sbe-2t3e3: Use netdev_ printks in main.c
On Wed, Oct 24, 2012 at 1:15 PM, Greg Kroah-Hartman wrote: > On Wed, Oct 24, 2012 at 12:05:28PM +0900, YAMANE Toshiaki wrote: >> fixed below checkpatch warning. >> - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then >> pr_err(... to printk(KERN_ERR ... >> >> Signed-off-by: YAMANE Toshiaki > > I never got the 3/3 patch in this series :( I know! # thanks, I will learn more ways to send patch -- Regards, YAMANE Toshiaki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 00/16 v2] f2fs: introduce flash-friendly file system
> On Wed, Oct 24, 2012 at 08:18:36AM +0900, Jaegeuk Kim wrote: > > > On Tue, Oct 23, 2012 at 11:26:59AM -0700, Greg KH wrote: > > > > On Tue, Oct 23, 2012 at 11:21:53AM +0900, Jaegeuk Kim wrote: > > > > > mkfs.f2fs > > > > > = > > > > > > > > > > The file system formatting tool, "mkfs.f2fs", is available from the > > > > > following > > > > > download page: > > > > > http://sourceforge.net/projects/f2fs-tools/ > > > > > > > > Is there a git tree of this tool somewhere, so I don't have to > > > > constantly suffer the sf.net download interface every time I want to get > > > > the latest version? > > > > > > Oh, and where do we report bugs for this tool? I just formatted a usb > > > stick with the mkfs.f2fs program, and it did not fully erase the old > > > filesystem that was on there (iso9660), so when I mounted it, it did so > > > in iso9660 mode, not f2fs mode. > > > > > > > Any suggestion for reporting bugs? > > Maybe via a mailing list? > > Mailing list is fine. > > > What version did you use? (1.1.0 is correct.) > > I used 1.1.0 > > > The reason we found was due to the 0'th block, so we fixed that in v1.1.0. > > Hm, that's what I used. I zeroed out the whole usb disk and tried again > and it worked then, I was trying to debug the kernel changes, not the > userspace tool, so I didn't spend much time on it :) > > But, if you do get a public git tree up, I will at the very least, > provide a patch to handle '-h' properly for mkfs, that should work... > Ok, thank you very much. > thanks, > > greg k-h --- Jaegeuk Kim Samsung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 00/16 v2] f2fs: introduce flash-friendly file system
> -Original Message- > From: 'Greg KH' [mailto:gre...@linuxfoundation.org] > Sent: Wednesday, October 24, 2012 12:01 PM > To: Jaegeuk Kim > Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; > v...@zeniv.linux.org.uk; > a...@arndb.de; ty...@mit.edu; chur@samsung.com; cm224@samsung.com; > jooyoung.hw...@samsung.com > Subject: Re: [PATCH 00/16 v2] f2fs: introduce flash-friendly file system > Importance: High > > On Wed, Oct 24, 2012 at 08:14:44AM +0900, Jaegeuk Kim wrote: > > > On Tue, Oct 23, 2012 at 11:21:53AM +0900, Jaegeuk Kim wrote: > > > > mkfs.f2fs > > > > = > > > > > > > > The file system formatting tool, "mkfs.f2fs", is available from the > > > > following > > > > download page: http://sourceforge.net/projects/f2fs-tools/ > > > > > > Is there a git tree of this tool somewhere, so I don't have to > > > constantly suffer the sf.net download interface every time I want to get > > > the latest version? > > > > I'd love to do like that. > > I've managed a git tree for tools in house only, due to the company secret. > > Would you suggest something for this? > > I can do managing the tree outside though. > > git.kernel.org can work, so can github, and also, you have a sf.net > project, why not use the git tree it provides you? Right now it is > empty. > Ok, I'll make a tree in sf.net. :) > thanks, > > greg k-h --- Jaegeuk Kim Samsung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Request for review] Revised delete_module(2) manual page
Hi Michael, On Sun, Oct 21, 2012 at 5:36 AM, Michael Kerrisk (man-pages) wrote: > Ping! > > Rusty (et al.) I'm pretty sure the new page text is okay, but I would > like someone knowledgeable to confirm. One more thing: > .SH "SEE ALSO" > .BR create_module (2), > .BR init_module (2), > .BR query_module (2), > .BR lsmod (8), > .BR rmmod (8) Shouldn't we remove the reference to query_module(2) and create_module(2)? They don't exist anymore (and I miss a bigger warning on their man pages). Last, I think there should be a ref here to modprobe (because of -r flag), not lsmod. The rest looks good. Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
On Tue, Oct 23, 2012 at 11:27:09PM -0500, Eric Sandeen wrote: > > Ok, fair enough. If the BBU is working, nobarrier is ok; I don't trust > journal_async_commit, but that doesn't mean this isn't a regression. Note that Toralf has reported almost exactly the same set of symptoms, but he's using an external USB stick --- and as far as I know he wasn't using nobarrier and/or the journal_async_commit. Toralf, can you confirm what, if any, mount options you were using when you saw it. I've been looking at this some more, and there's one other thing that the short circuit code does, which is neglects setting the JBD2_FLUSHED flag, which is used by the commit code to know when it needs to reset the s_start fields in the superblock when we make our next commit. However, this would only happen if the short circuit code is getting hit some time other than when the file system is getting unmounted --- and that's what Eric and I can't figure out how it might be happening. Journal flushes outside of an unmount does happen as part of online resizing, the FIBMAP ioctl, or when the file system is frozen. But it didn't sound like Toralf or Nix was using any of those features. (Toralf, Nix, please correct me if my assumptions here is wrong). So here's a replacement patch which essentially restores the effects of eeecef0af5e while still keeping the optimization and fixing the read/only testing issue which eeecef0af5e is trying to fix up. It also have a debugging printk that will trigger so we can perhaps have a better chance of figuring out what might be going on. Toralf, Nix, if you could try applying this patch (at the end of this message), and let me know how and when the WARN_ON triggers, and if it does, please send the empty_bug_workaround plus the WARN_ON(1) report. I know about the case where a file system is mounted and then immediately unmounted, but we don't think that's the problematic case. If you see any other cases where WARN_ON is triggering, it would be really good to know - Ted P.S. This is a list of all of the commits between v3.6.1 and v3.6.2 (there were no ext4-related changes between v3.6.2 and v3.6.3), and a quick analysis of the patch. The last commit, 14b4ed2, is the only one that I could see as potentially being problematic, which is why I've been pushing so hard on this one even though my original analysis doesn't seem to be correct, and Eric and I can't see how the change in 14b4ed2 could be causing the fs corruption. Online Defrag = 22a5672 ext4: online defrag is not supported for journaled files ba57d9e ext4: move_extent code cleanup No behavioral change unless e4defrag has been used. Online Resize = 5018ddd ext4: avoid duplicate writes of the backup bg descriptor blocks 256ae46 ext4: don't copy non-existent gdt blocks when resizing 416a688 ext4: ignore last group w/o enough space when resizing instead of BUG'ing No observable change unless online resizing (e2resize) has been used Other Commits = 92b7722 ext4: fix mtime update in nodelalloc mode Changes where we call file_update_time() 34414b2 ext4: fix fdatasync() for files with only i_size changes Forces the inode changes to be commited if only i_sync changes when fdatasync() is called. No changes except performance impact to fdatasync() and correctness after a system crash. 12ebdf0 ext4: always set i_op in ext4_mknod() Fixes a bug if CONFIG_EXT4_FS_XATTR is not defined; no change if CONFIG_EXT4_FS_XATTR is defined 2fdb112 ext4: fix crash when accessing /proc/mounts concurrently Remove an erroneous "static" for an function so it is allocated on the stack; fixes a bug if two processes cat /proc/mounts at the same time 1638f1f ext4: fix potential deadlock in ext4_nonda_switch() Fixes a circular lock dependency 14b4ed2 jbd2: don't write superblock when if its empty If journal->s_start is zero, we may not update journal->s_sequence when it might be needed. (But we at the moement we can't see how this could lead to the reported fs corruptions.) commit cb57108637e01ec2f02d9311cedc3013e96f25d4 Author: Theodore Ts'o Date: Wed Oct 24 01:01:41 2012 -0400 jbd2: fix a potential fs corrupting bug in jbd2_mark_journal_empty Fix a potential file system corrupting bug which was introduced by commit eeecef0af5ea4efd763c9554cf2bd80fc4a0efd3: jbd2: don't write superblock when if its empty. We should only skip writing the journal superblock if there is nothing to do --- not just when s_start is zero. This has caused users to report file system corruptions in ext4 that look like this: EXT4-fs error (device sdb3): ext4_mb_generate_buddy:741: group 436, 22902 clusters in bitmap, 22901 in gd JBD2: Spotted dirty metadata buffer (dev = sdb3, blocknr = 0). There's a risk of filesystem corruption in case of system crash. after the file system has been
[PATCH v2] staging/comedi: Use dev_ printks in drivers/vmk80xx.c
fixed below checkpatch warning.
- Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to
printk(KERN_INFO ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/comedi/drivers/vmk80xx.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/comedi/drivers/vmk80xx.c
b/drivers/staging/comedi/drivers/vmk80xx.c
index df277aa..3664907 100644
--- a/drivers/staging/comedi/drivers/vmk80xx.c
+++ b/drivers/staging/comedi/drivers/vmk80xx.c
@@ -1371,12 +1371,11 @@ static int vmk80xx_usb_probe(struct usb_interface *intf,
if (dev->board.model == VMK8061_MODEL) {
vmk80xx_read_eeprom(dev, IC3_VERSION);
- printk(KERN_INFO "comedi#: vmk80xx: %s\n", dev->fw.ic3_vers);
+ dev_info(&intf->dev, "%s\n", dev->fw.ic3_vers);
if (vmk80xx_check_data_link(dev)) {
vmk80xx_read_eeprom(dev, IC6_VERSION);
- printk(KERN_INFO "comedi#: vmk80xx: %s\n",
- dev->fw.ic6_vers);
+ dev_info(&intf->dev, "%s\n", dev->fw.ic6_vers);
} else {
dbgcm("comedi#: vmk80xx: no conn. to CPU\n");
}
@@ -1387,8 +1386,8 @@ static int vmk80xx_usb_probe(struct usb_interface *intf,
dev->probed = 1;
- printk(KERN_INFO "comedi#: vmk80xx: board #%d [%s] now attached\n",
- dev->count, dev->board.name);
+ dev_info(&intf->dev, "board #%d [%s] now attached\n",
+dev->count, dev->board.name);
mutex_unlock(&glb_mutex);
@@ -1422,8 +1421,8 @@ static void vmk80xx_usb_disconnect(struct usb_interface
*intf)
kfree(dev->usb_rx_buf);
kfree(dev->usb_tx_buf);
- printk(KERN_INFO "comedi#: vmk80xx: board #%d [%s] now detached\n",
- dev->count, dev->board.name);
+ dev_info(&intf->dev, "board #%d [%s] now detached\n",
+dev->count, dev->board.name);
up(&dev->limit_sem);
mutex_unlock(&glb_mutex);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dma-mapping: fix build warning in __dma_alloc()
Fix build warning in __dma_alloc() as below:
arch/arm/mm/dma-mapping.c: In function '__dma_alloc':
arch/arm/mm/dma-mapping.c:653:29: warning: 'page' may be used uninitialized in
this function [-Wuninitialized]
Signed-off-by: Jingoo Han
---
arch/arm/mm/dma-mapping.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 477a2d2..58bc3e4 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -610,7 +610,7 @@ static void *__dma_alloc(struct device *dev, size_t size,
dma_addr_t *handle,
gfp_t gfp, pgprot_t prot, bool is_coherent, const void
*caller)
{
u64 mask = get_coherent_dma_mask(dev);
- struct page *page;
+ struct page *page = NULL;
void *addr;
#ifdef CONFIG_DMA_API_DEBUG
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] DMA: PL330: Free memory allocated for peripheral channels
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> The allocated memory for peripheral channels is not being freed upon
> failure in probe and in module's remove funtion. It will lead to memory
> leakage. Hence free the allocated memory.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 2ebd4cd..10c6b6a 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2962,7 +2962,7 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> ret = dma_async_device_register(pd);
> if (ret) {
> dev_err(&adev->dev, "unable to register DMAC\n");
> - goto probe_err4;
> + goto probe_err5;
> }
>
> dev_info(&adev->dev,
> @@ -2975,6 +2975,8 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
>
> return 0;
>
> +probe_err5:
> + kfree(pdmac->peripherals);
> probe_err4:
> pl330_del(pi);
> probe_err3:
> @@ -3025,6 +3027,7 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> res = &adev->res;
> release_mem_region(res->start, resource_size(res));
>
> + kfree(pdmac->peripherals);
> kfree(pdmac);
>
> return 0;
This looks fine, but if you use devm_ functions then you dont need to do
all this.
Can you do that conversion instead?
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] Thermal: Add ST-Ericsson db8500 thermal dirver.
On 23 October 2012 02:51, Francesco Lavra wrote:
> On 10/22/2012 02:02 PM, Hongbo Zhang wrote:
> [...]
+static irqreturn_t prcmu_low_irq_handler(int irq, void *irq_data)
+{
+ struct db8500_thermal_zone *pzone = irq_data;
+ struct db8500_thsens_platform_data *ptrips;
+ unsigned long next_low, next_high;
+ unsigned int idx;
+
+ ptrips = pzone->trip_tab;
+ idx = pzone->cur_index;
+ if (unlikely(idx == 0))
+ /* Meaningless for thermal management, ignoring it */
+ return IRQ_HANDLED;
+
+ if (idx == 1) {
+ next_high = ptrips->trip_points[0].temp;
+ next_low = PRCMU_DEFAULT_LOW_TEMP;
+ } else {
+ next_high = ptrips->trip_points[idx-1].temp;
+ next_low = ptrips->trip_points[idx-2].temp;
+ }
+
+ pzone->cur_index -= 1;
+ pzone->cur_temp_pseudo = (next_high + next_low)/2;
+
+ prcmu_stop_temp_sense();
+ prcmu_config_hotmon((u8)(next_low/1000), (u8)(next_high/1000));
+ prcmu_start_temp_sense(PRCMU_DEFAULT_MEASURE_TIME);
+
+ pr_debug("PRCMU set max %ld, set min %ld\n", next_high, next_low);
+
+ pzone->trend = THERMAL_TREND_DROPPING;
+ schedule_work(&pzone->therm_work);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t prcmu_high_irq_handler(int irq, void *irq_data)
+{
+ struct db8500_thermal_zone *pzone = irq_data;
+ struct db8500_thsens_platform_data *ptrips;
+ unsigned long next_low, next_high;
+ unsigned int idx;
+
+ ptrips = pzone->trip_tab;
+ idx = pzone->cur_index;
+
+ if (idx < ptrips->num_trips - 1) {
+ next_high = ptrips->trip_points[idx+1].temp;
+ next_low = ptrips->trip_points[idx].temp;
+
+ pzone->cur_index += 1;
+ pzone->cur_temp_pseudo = (next_high + next_low)/2;
+
+ prcmu_stop_temp_sense();
+ prcmu_config_hotmon((u8)(next_low/1000),
(u8)(next_high/1000));
+ prcmu_start_temp_sense(PRCMU_DEFAULT_MEASURE_TIME);
+
+ pr_debug("PRCMU set max %ld, min %ld\n", next_high,
next_low);
+ }
+
+ if (idx == ptrips->num_trips - 1)
>>>
>>> } else if ()
>> There is no else condition here, because it it the highest critical
>> trip point, system will be shut down in thermal_work.
>> But I'd like to add some comments here to state this situation.
>
> I didn't mean adding a new else condition, what I meant is that if the
> first condition (idx < ptrips->num_trips - 1) is verified, then there is
> no need to check for the second condition (idx == ptrips->num_trips -
> 1). So I was thinking of changing the code to:
>
> if (idx < ptrips->num_trips - 1)
> ...
> else if (idx == ptrips->num_trips - 1)
> ...
>
> Sorry if I wasn't clear.
Got it, thanks.
>
>>>
+ pzone->cur_temp_pseudo = ptrips->trip_points[idx].temp + 1;
+
+ pzone->trend = THERMAL_TREND_RAISING;
+ schedule_work(&pzone->therm_work);
+
+ return IRQ_HANDLED;
+}
+
+static void db8500_thermal_work(struct work_struct *work)
+{
+ enum thermal_device_mode cur_mode;
+ struct db8500_thermal_zone *pzone;
+
+ pzone = container_of(work, struct db8500_thermal_zone, therm_work);
+
+ mutex_lock(&pzone->th_lock);
+ cur_mode = pzone->mode;
+ mutex_unlock(&pzone->th_lock);
+
+ if (cur_mode == THERMAL_DEVICE_DISABLED) {
+ pr_warn("Warning: thermal function disabled.\n");
+ return;
+ }
+
+ thermal_zone_device_update(pzone->therm_dev);
+ pr_debug("db8500_thermal_work finished.\n");
+}
+
+static int __devinit db8500_thermal_probe(struct platform_device *pdev)
+{
+ struct db8500_thermal_zone *pzone = NULL;
+ struct db8500_thsens_platform_data *ptrips;
+ int low_irq, high_irq, ret = 0;
+ unsigned long dft_low, dft_high;
+
+ pzone = devm_kzalloc(&pdev->dev,
+ sizeof(struct db8500_thermal_zone), GFP_KERNEL);
+ if (!pzone)
+ return -ENOMEM;
+
+ pzone->thsens_pdev = pdev;
+
+ low_irq = platform_get_irq_byname(pdev, "IRQ_HOTMON_LOW");
+ if (low_irq < 0) {
+ pr_err("Get IRQ_HOTMON_LOW failed.\n");
+ return low_irq;
+ }
+
+ ret = devm_request_threaded_irq(&pdev->dev, low_irq, NULL,
+ prcmu_low_irq_handler,
+ IRQF_NO_SUSPEND | IRQF_ONESHOT, "dbx500_temp_low", pzone);
+ if (ret < 0) {
+ pr_err("Failed to allocate tem
Re: [PATCH v2 4/4] DMA: PL330: unregister dma_device in module's remove function
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote: > unregister dma_device in module's remove function. > > Signed-off-by: Inderpal Singh > --- > drivers/dma/pl330.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c > index 4b7a34d..e7dc040 100644 > --- a/drivers/dma/pl330.c > +++ b/drivers/dma/pl330.c > @@ -3017,6 +3017,8 @@ static int __devexit pl330_remove(struct amba_device > *adev) > return -EBUSY; > } > > + dma_async_device_unregister(&pdmac->ddma); > + > amba_set_drvdata(adev, NULL); > > list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels, Ok with this one :) Tried applying but didn't work out. You would need to regenerate this one. Thanks -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Process Hang in __read_seqcount_begin
On Tue, 2012-10-23 at 17:15 -0700, Peter LaDow wrote:
> (Sorry for the subject change, but I wanted to try and pull in those
> who work on RT issues, and the subject didn't make that obvious.
> Please search for the same subject without the RT Linux trailing
> text.)
>
> Well, more information. Even with SMP enabled (and presumably the
> migrate_enable having calls to preempt_disable), we still got the
> lockup in iptables-restore. I did more digging, and it looks like the
> complete stack trace includes a call from iptables-restore (through
> setsockopt with IPT_SO_SET_ADD_COUNTERS). This seems to be a
> potential multiple writer case where the counters are updated through
> the syscall and the kernel is updating the counters as it filters
> packets.
>
> I think there might be a race on the update to xt_recseq.sequence,
> since the RT patches remove the spinlock in seqlock_t. Thus multiple
> writers can corrupt the sequence count.
> And I thought the SMP
> configuration would disable preemption when local_bh_disable() is
> called. And indeed, looking at the disassembly, I see
> preempt_disable() (though optimized, goes to add_preempt_count() ) is
> being called.
>
> Yet we still see the lockup in the get_counters() in iptables. Which,
> it seems, is because of some sort of problem with the sequence. It
> doesn't appear to be related to the preemption, and perhaps there is
> some other corruption of the sequence counter happening. But the only
> places I see it modified is in xt_write_recseq_begin and
> xt_write_recseq_end, which is only in the netfilter code
> (ip6_tables.c, ip_tables.c, and arp_tables.c). And every single call
> is preceeded by a call to local_bh_disable().
>
> This problem is a huge one for us. And so far I'm unable to track
> down how this is occurring.
>
> Any other tips? I presume this is the proper place for RT issues.
Hmm...
Could you try following patch ?
diff --git a/include/linux/netfilter/x_tables.h
b/include/linux/netfilter/x_tables.h
index 8d674a7..053f9e7 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -471,30 +471,24 @@ DECLARE_PER_CPU(seqcount_t, xt_recseq);
*
* Begin packet processing : all readers must wait the end
* 1) Must be called with preemption disabled
- * 2) softirqs must be disabled too (or we should use this_cpu_add())
* Returns :
* 1 if no recursion on this cpu
* 0 if recursion detected
*/
static inline unsigned int xt_write_recseq_begin(void)
{
- unsigned int addend;
-
+ unsigned int old, new;
+ seqcount_t *ptr = &__get_cpu_var(xt_recseq);
/*
* Low order bit of sequence is set if we already
* called xt_write_recseq_begin().
*/
- addend = (__this_cpu_read(xt_recseq.sequence) + 1) & 1;
-
- /*
-* This is kind of a write_seqcount_begin(), but addend is 0 or 1
-* We dont check addend value to avoid a test and conditional jump,
-* since addend is most likely 1
-*/
- __this_cpu_add(xt_recseq.sequence, addend);
- smp_wmb();
-
- return addend;
+ old = ptr->sequence;
+ new = old | 1;
+ /* Note : cmpxchg() is a memory barrier, we dont need smp_wmb() */
+ if (old != new && cmpxchg(&ptr->sequence, old, new) == old)
+ return 1;
+ return 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 3/4] DMA: PL330: Balance module remove function with probe
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> Since peripheral channel resources are not being allocated at probe,
> no need to flush the channels and free the resources in remove function.
> In case, the channel is in use by some client, return EBUSY.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index bf71ff7..4b7a34d 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -3009,18 +3009,21 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> if (!pdmac)
> return 0;
>
> + /* check if any client is using any channel */
> + list_for_each_entry(pch, &pdmac->ddma.channels,
> + chan.device_node) {
> +
> + if (pch->chan.client_count)
> + return -EBUSY;
> + }
> +
> while (!list_empty(&pdmac->desc_pool)) {
Did you get this code executed?
I think No.
The dmaengine holds the reference to channels, so if they are in use and
not freed by client your remove wont be called. So this check is
redundant
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
On 10/23/12 11:15 PM, Nix wrote: > On 24 Oct 2012, Eric Sandeen uttered the following: > >> On 10/23/12 3:57 PM, Nix wrote: >>> The only unusual thing about the filesystems on this machine are that >>> they have hardware RAID-5 (using the Areca driver), so I'm mounting with >>> 'nobarrier': >> >> I should have read more. :( More questions follow: >> >> * Does the Areca have a battery backed write cache? > > Yes (though I'm not powering off, just rebooting). Battery at 100% and > happy, though the lack of power-off means it's not actually getting > used, since the cache is obviously mains-backed as well. > >> * Are you crashing or rebooting cleanly? > > Rebooting cleanly, everything umounted happily including /home and /var. > >> * Do you see log recovery messages in the logs for this filesystem? > > My memory says yes, but nothing seems to be logged when this happens > (though with my logs on the first filesystem damaged by this, this is > rather hard to tell, they're all quite full of NULs by now). > > I'll double-reboot tomorrow via the faulty kernel and check, unless I > get asked not to in the interim. (And then double-reboot again to fsck > everything...) > >>> the full set of options for all my ext4 filesystems are: >>> >>> rw,nosuid,nodev,relatime,journal_checksum,journal_async_commit,nobarrier,quota, >>> usrquota,grpquota,commit=30,stripe=16,data=ordered,usrquota,grpquota >> >> ok journal_async_commit is off the reservation a bit; that's really not >> tested, and Jan had serious reservations about its safety. > > OK, well, I've been 'testing' it for years :) No problems until now. (If > anything, I was more concerned about journal_checksum. I thought that > had actually been implicated in corruption before now...) It had, but I fixed it AFAIK; OTOH, we turned it off by default after that episode. >> * Can you reproduce this w/o journal_async_commit? > > I can try! Ok, fair enough. If the BBU is working, nobarrier is ok; I don't trust journal_async_commit, but that doesn't mean this isn't a regression. Thanks for the answers... onward. :) -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] DMA: PL330: Change allocation method to properly free DMA descriptors
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> In probe, memory for multiple DMA descriptors were being allocated at once
> and then it was being split and added into DMA pool one by one. The address
> of this memory allocation is not being saved anywhere. To free this memory,
> the address is required. Initially the first node of the pool will be
> pointed by this address but as we use this pool the descs will shuffle and
> hence we will lose the track of the address.
>
> This patch does following:
>
> 1. Allocates DMA descs one by one and then adds them to pool so that all
>descs can be fetched and memory freed one by one. This way runtime
>added descs can also be freed.
> 2. Free DMA descs in case of error in probe and in module's remove function
For probe, again you have cleaner code by using devm_kzalloc.
On 1, if we use the devm_kzalloc then we don't need to allocate in
chunks right?
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c | 35 +--
> 1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 10c6b6a..bf71ff7 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2541,20 +2541,20 @@ static int add_desc(struct dma_pl330_dmac *pdmac,
> gfp_t flg, int count)
> if (!pdmac)
> return 0;
>
> - desc = kmalloc(count * sizeof(*desc), flg);
> - if (!desc)
> - return 0;
> + for (i = 0; i < count; i++) {
> + desc = kmalloc(sizeof(*desc), flg);
> + if (!desc)
> + break;
> + _init_desc(desc);
>
> - spin_lock_irqsave(&pdmac->pool_lock, flags);
> + spin_lock_irqsave(&pdmac->pool_lock, flags);
>
> - for (i = 0; i < count; i++) {
> - _init_desc(&desc[i]);
> - list_add_tail(&desc[i].node, &pdmac->desc_pool);
> - }
> + list_add_tail(&desc->node, &pdmac->desc_pool);
>
> - spin_unlock_irqrestore(&pdmac->pool_lock, flags);
> + spin_unlock_irqrestore(&pdmac->pool_lock, flags);
> + }
>
> - return count;
> + return i;
> }
>
> static struct dma_pl330_desc *
> @@ -2857,6 +2857,7 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> struct dma_pl330_platdata *pdat;
> struct dma_pl330_dmac *pdmac;
> struct dma_pl330_chan *pch;
> + struct dma_pl330_desc *desc;
> struct pl330_info *pi;
> struct dma_device *pd;
> struct resource *res;
> @@ -2978,6 +2979,12 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> probe_err5:
> kfree(pdmac->peripherals);
> probe_err4:
> + while (!list_empty(&pdmac->desc_pool)) {
> + desc = list_entry(pdmac->desc_pool.next,
> + struct dma_pl330_desc, node);
> + list_del(&desc->node);
> + kfree(desc);
> + }
> pl330_del(pi);
> probe_err3:
> free_irq(irq, pi);
> @@ -2994,6 +3001,7 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> {
> struct dma_pl330_dmac *pdmac = amba_get_drvdata(adev);
> struct dma_pl330_chan *pch, *_p;
> + struct dma_pl330_desc *desc;
> struct pl330_info *pi;
> struct resource *res;
> int irq;
> @@ -3015,6 +3023,13 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> pl330_free_chan_resources(&pch->chan);
> }
>
> + while (!list_empty(&pdmac->desc_pool)) {
> + desc = list_entry(pdmac->desc_pool.next,
> + struct dma_pl330_desc, node);
> + list_del(&desc->node);
> + kfree(desc);
> + }
> +
> pi = &pdmac->pif;
>
> pl330_del(pi);
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Oct 24
Hi all, Changes since 201201023: The wireless-next tree lost its conflicts. The pm tree gained a build failure for which I applied a patch. The tty tree gained a build failure for which I disabled a staging driver. The usb tree lost its build failure. The akpm tree still has its 2 build failures for which I reverted some commits. It also lost a patch that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 205 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (2d1f4c8 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) Merging kbuild-current/rc-fixes (b1e0d8b kbuild: Fix gcc -x syntax) Merging arm-current/fixes (b43b1ff Merge tag 'fixes-for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into fixes) Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp) Merging powerpc-merge/merge (83dac59 cpuidle/powerpc: Fix snooze state problem in the cpuidle design on pseries.) Merging sparc/master (43c422e apparmor: fix apparmor OOPS in audit_log_untrustedstring+0x1c/0x40) Merging net/master (37561f6 tcp: Reject invalid ack_seq to Fast Open sockets) Merging sound-current/for-linus (21b3de8 ALSA: als3000: check for the kzalloc return value) Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding is disabled) Merging wireless/master (290eddc Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (d28d388 firmware loader: sync firmware cache by async_synchronize_full_domain) Merging tty.current/tty-linus (6f0c058 Linux 3.7-rc2) Merging usb.current/usb-linus (3b6054d usb hub: send clear_tt_buffer_complete events when canceling TT clear work) Merging staging.current/staging-linus (b3ca610 staging: ramster: depends on NET) Merging char-misc.current/char-misc-linus (ddffeb8 Linux 3.7-rc1) Merging input-current/for-linus (0cc8d6a Merge branch 'next' into for-linus) Merging md-current/for-linus (72f36d5 md: refine reporting of resync/reshape delays.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (c9f97a2 crypto: x86/glue_helper - fix storing of new IV in CBC encryption) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging asm-generic/master (c37d615 Merge branch 'disintegrate-asm-generic' of git://git.infradead.org/users/dhowells/linux-h
Re: Apparent serious progressive ext4 data corruption bug in 3.6.3 (and other stable branches?)
On 24 Oct 2012, Eric Sandeen uttered the following: > On 10/23/12 3:57 PM, Nix wrote: >> The only unusual thing about the filesystems on this machine are that >> they have hardware RAID-5 (using the Areca driver), so I'm mounting with >> 'nobarrier': > > I should have read more. :( More questions follow: > > * Does the Areca have a battery backed write cache? Yes (though I'm not powering off, just rebooting). Battery at 100% and happy, though the lack of power-off means it's not actually getting used, since the cache is obviously mains-backed as well. > * Are you crashing or rebooting cleanly? Rebooting cleanly, everything umounted happily including /home and /var. > * Do you see log recovery messages in the logs for this filesystem? My memory says yes, but nothing seems to be logged when this happens (though with my logs on the first filesystem damaged by this, this is rather hard to tell, they're all quite full of NULs by now). I'll double-reboot tomorrow via the faulty kernel and check, unless I get asked not to in the interim. (And then double-reboot again to fsck everything...) >> the full set of options for all my ext4 filesystems are: >> >> rw,nosuid,nodev,relatime,journal_checksum,journal_async_commit,nobarrier,quota, >> usrquota,grpquota,commit=30,stripe=16,data=ordered,usrquota,grpquota > > ok journal_async_commit is off the reservation a bit; that's really not > tested, and Jan had serious reservations about its safety. OK, well, I've been 'testing' it for years :) No problems until now. (If anything, I was more concerned about journal_checksum. I thought that had actually been implicated in corruption before now...) > * Can you reproduce this w/o journal_async_commit? I can try! -- NULL && (void) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] staging/sbe-2t3e3: Use netdev_ printks in main.c
On Wed, Oct 24, 2012 at 12:05:28PM +0900, YAMANE Toshiaki wrote: > fixed below checkpatch warning. > - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then > pr_err(... to printk(KERN_ERR ... > > Signed-off-by: YAMANE Toshiaki I never got the 3/3 patch in this series :( 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] Staging: android: binder: Fixed multi-line strings
On Tue, Oct 23, 2012 at 03:13:38PM +0530, Anmol Sarma wrote: > >From 949ecac6fcd58ffa6d02f6761058dbcfb1c2ba42 Mon Sep 17 00:00:00 2001 > From: Anmol Sarma > Date: Tue, 23 Oct 2012 13:47:14 +0530 > Subject: [PATCH] Staging: android: binder: Strings cleanup > > Changed all user visible multi-line stings to single line. No you didn't: > @@ -420,12 +422,12 @@ static void binder_set_nice(long nice) > } > min_nice = 20 - current->signal->rlim[RLIMIT_NICE].rlim_cur; > binder_debug(BINDER_DEBUG_PRIORITY_CAP, > - "binder: %d: nice value %ld not allowed use " > + "%d: nice value %ld not allowed use " >"%ld instead\n", current->pid, nice, min_nice); That's a multi-line string :( And you sent 2 copies of this patch, why? Care to try again? 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: linux-next: build failure after merge of the final tree (pm tree related)
Yes. We already do the patch to fix the warning yesterday after get the
information from Fengguang's "0-DAY kernel build testing". But do not refresh
linux-next so quickly.
Thanks for the information and patch, Stephen!
-Youquan
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Wednesday, October 24, 2012 11:44 AM
To: Rafael J. Wysocki
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Song, Youquan;
Rik van Riel
Subject: linux-next: build failure after merge of the final tree (pm tree
related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from arch/powerpc/kernel/idle.c:27:0:
include/linux/tick.h: In function 'menu_hrtimer_cancel':
include/linux/tick.h:148:48: error: 'return' with a value, in function
returning void [-Werror]
Several of these :-(
Caused by commit 25d77b76d7ae ("cpuidle: Quickly notice prediction failure for
repeat mode") from the pm tree. This build has CONFIG_CPU_IDLE_GOV_MENU turned
off. For changes that are obviously affected by CONFIG options, please test
build with the CONFIG option on and off.
I have applied the following patch for today:
From: Stephen Rothwell
Date: Wed, 24 Oct 2012 14:40:47 +1100
Subject: [PATCH] cpuidle: fix up but return type for inline function
Fixes this error when CONFIG_CPU_IDLE_GOV_MENU is not enabled:
In file included from arch/powerpc/kernel/idle.c:27:0:
include/linux/tick.h: In function 'menu_hrtimer_cancel':
include/linux/tick.h:148:48: error: 'return' with a value, in function
returning void [-Werror]
Signed-off-by: Stephen Rothwell
---
include/linux/tick.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h index 8867424..40d123e
100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -145,7 +145,7 @@ static inline u64 get_cpu_iowait_time_us(int cpu, u64
*unused) { return -1; } # ifdef CONFIG_CPU_IDLE_GOV_MENU extern void
menu_hrtimer_cancel(void); # else -static inline void
menu_hrtimer_cancel(void) { return -1; }
+static inline void menu_hrtimer_cancel(void) { }
# endif /* CONFIG_CPU_IDLE_GOV_MENU */
#endif
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] pwm: vt8500: Update vt8500 PWM driver support
On Wed, 2012-10-24 at 00:14 +0200, Thierry Reding wrote:
> On Tue, Oct 23, 2012 at 07:10:24AM +1300, Tony Prisk wrote:
> [...]
> > @@ -87,6 +98,11 @@ static int vt8500_pwm_enable(struct pwm_chip *chip,
> > struct pwm_device *pwm)
> > {
> > struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
> >
> > + if (!clk_enable(vt8500->clk)) {
> > + dev_err(chip->dev, "failed to enable clock\n");
> > + return -EBUSY;
> > + };
> > +
>
> I don't think that works. The clock API returns 0 on success and a
> negative error code on failure. So this should rather be something like:
>
> err = clk_enable(vt8500->clk);
> if (err < 0) {
> dev_err(chip->dev, "failed to enable clock: %d\n", err);
> return err;
> }
>
> > @@ -123,6 +153,12 @@ static int __devinit pwm_probe(struct platform_device
> > *pdev)
> > chip->chip.ops = &vt8500_pwm_ops;
> > chip->chip.base = -1;
> > chip->chip.npwm = VT8500_NR_PWMS;
> > + chip->clk = devm_clk_get(&pdev->dev, NULL);
> > +
>
> The blank line should go above the call to devm_clk_get().
>
> > + if (IS_ERR_OR_NULL(chip->clk)) {
> > + dev_err(&pdev->dev, "clock source not specified\n");
> > + return PTR_ERR(chip->clk);
> > + }
> [...]
> > + if (!clk_prepare(chip->clk)) {
> > + dev_err(&pdev->dev, "failed to prepare clock\n");
> > + return -EBUSY;
> > + }
> > +
>
> Same comment here. I wonder how this code can work, since if the clock
> is properly prepared, then it will return 0, and the above will return
> -EBUSY.
>
> > ret = pwmchip_add(&chip->chip);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "failed to add pwmchip\n");
>
> Error messages can be considered prose, so this should be: "failed to
> add PWM chip".
>
> Thierry
I don't know why none of this caused a failure when boot tested. The
clock should have been disabled 'automagically' at bootup, and never
reenabled. *shrug* Fixed in new patch v3 (didn't notice there was
already a v3).
Regards
Tony P
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] pwm: vt8500: Update vt8500 PWM driver support
This patch updates pwm-vt8500.c to support devicetree probing and
make use of the common clock subsystem.
A binding document describing the PWM controller found on
arch-vt8500 is also included.
Signed-off-by: Tony Prisk
---
v2/v3:
Fix errors/coding style as pointed out by Thierry Reding.
.../devicetree/bindings/pwm/vt8500-pwm.txt | 17
drivers/pwm/pwm-vt8500.c | 86 ++--
2 files changed, 80 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
new file mode 100644
index 000..bcc6367
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -0,0 +1,17 @@
+VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
+
+Required properties:
+- compatible: should be "via,vt8500-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2. The first cell specifies the per-chip index
+ of the PWM to use and the second cell is the period in nanoseconds.
+- clocks: phandle to the PWM source clock
+
+Example:
+
+pwm1: pwm@d822 {
+ #pwm-cells = <2>;
+ compatible = "via,vt8500-pwm";
+ reg = <0xd822 0x1000>;
+ clocks = <&clkpwm>;
+};
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index ad14389..2ecd70f 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -1,7 +1,8 @@
/*
* drivers/pwm/pwm-vt8500.c
*
- * Copyright (C) 2010 Alexey Charkov
+ * Copyright (C) 2012 Tony Prisk
+ * Copyright (C) 2010 Alexey Charkov
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -21,14 +22,24 @@
#include
#include
#include
+#include
#include
-#define VT8500_NR_PWMS 4
+#include
+#include
+#include
+
+/*
+ * SoC architecture allocates register space for 4 PWMs but only
+ * 2 are currently implemented.
+ */
+#define VT8500_NR_PWMS 2
struct vt8500_chip {
struct pwm_chip chip;
void __iomem *base;
+ struct clk *clk;
};
#define to_vt8500_chip(chip) container_of(chip, struct vt8500_chip, chip)
@@ -52,7 +63,7 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, prescale, pv, dc;
- c = 2500/2; /* wild guess --- need to implement clocks */
+ c = clk_get_rate(vt8500->clk);
c = c * period_ns;
do_div(c, 10);
period_cycles = c;
@@ -85,8 +96,15 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ int err;
struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+ err = clk_enable(vt8500->clk);
+ if (err < 0)
+ dev_err(chip->dev, "failed to enable clock\n");
+ return -EBUSY;
+ };
+
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(5, vt8500->base + (pwm->hwpwm << 4));
return 0;
@@ -98,6 +116,8 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, struct
pwm_device *pwm)
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(0, vt8500->base + (pwm->hwpwm << 4));
+
+ clk_disable(vt8500->clk);
}
static struct pwm_ops vt8500_pwm_ops = {
@@ -107,12 +127,24 @@ static struct pwm_ops vt8500_pwm_ops = {
.owner = THIS_MODULE,
};
-static int __devinit pwm_probe(struct platform_device *pdev)
+static const struct of_device_id vt8500_pwm_dt_ids[] = {
+ { .compatible = "via,vt8500-pwm", },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vt8500_pwm_dt_ids);
+
+static int vt8500_pwm_probe(struct platform_device *pdev)
{
struct vt8500_chip *chip;
struct resource *r;
+ struct device_node *np = pdev->dev.of_node;
int ret;
+ if (!np) {
+ dev_err(&pdev->dev, "invalid devicetree node\n");
+ return -EINVAL;
+ }
+
chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
if (chip == NULL) {
dev_err(&pdev->dev, "failed to allocate memory\n");
@@ -124,6 +156,12 @@ static int __devinit pwm_probe(struct platform_device
*pdev)
chip->chip.base = -1;
chip->chip.npwm = VT8500_NR_PWMS;
+ chip->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR_OR_NULL(chip->clk)) {
+ dev_err(&pdev->dev, "clock source not specified\n");
+ return PTR_ERR(chip->clk);
+ }
+
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
dev_err(&pdev->dev, "no memory resource defined\n");
@@ -131,18 +169,26 @@ static int __devinit pwm_probe(struct platform_device
*pdev)
}
Re: process hangs on do_exit when oom happens
On Wed, Oct 24, 2012 at 1:43 AM, Balbir Singh wrote: > On Tue, Oct 23, 2012 at 3:45 PM, Michal Hocko wrote: >> On Tue 23-10-12 18:10:33, Qiang Gao wrote: >>> On Tue, Oct 23, 2012 at 5:50 PM, Michal Hocko wrote: >>> > On Tue 23-10-12 15:18:48, Qiang Gao wrote: >>> >> This process was moved to RT-priority queue when global oom-killer >>> >> happened to boost the recovery of the system.. >>> > >>> > Who did that? oom killer doesn't boost the priority (scheduling class) >>> > AFAIK. >>> > >>> >> but it wasn't get properily dealt with. I still have no idea why where >>> >> the problem is .. >>> > >>> > Well your configuration says that there is no runtime reserved for the >>> > group. >>> > Please refer to Documentation/scheduler/sched-rt-group.txt for more >>> > information. >>> > >> [...] >>> maybe this is not a upstream-kernel bug. the centos/redhat kernel >>> would boost the process to RT prio when the process was selected >>> by oom-killer. >> >> This still looks like your cpu controller is misconfigured. Even if the >> task is promoted to be realtime. > > > Precisely! You need to have rt bandwidth enabled for RT tasks to run, > as a workaround please give the groups some RT bandwidth and then work > out the migration to RT and what should be the defaults on the distro. > > Balbir see https://patchwork.kernel.org/patch/719411/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the final tree (pm tree related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from arch/powerpc/kernel/idle.c:27:0:
include/linux/tick.h: In function 'menu_hrtimer_cancel':
include/linux/tick.h:148:48: error: 'return' with a value, in function
returning void [-Werror]
Several of these :-(
Caused by commit 25d77b76d7ae ("cpuidle: Quickly notice prediction
failure for repeat mode") from the pm tree. This build has
CONFIG_CPU_IDLE_GOV_MENU turned off. For changes that are obviously
affected by CONFIG options, please test build with the CONFIG option on
and off.
I have applied the following patch for today:
From: Stephen Rothwell
Date: Wed, 24 Oct 2012 14:40:47 +1100
Subject: [PATCH] cpuidle: fix up but return type for inline function
Fixes this error when CONFIG_CPU_IDLE_GOV_MENU is not enabled:
In file included from arch/powerpc/kernel/idle.c:27:0:
include/linux/tick.h: In function 'menu_hrtimer_cancel':
include/linux/tick.h:148:48: error: 'return' with a value, in function
returning void [-Werror]
Signed-off-by: Stephen Rothwell
---
include/linux/tick.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/tick.h b/include/linux/tick.h
index 8867424..40d123e 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -145,7 +145,7 @@ static inline u64 get_cpu_iowait_time_us(int cpu, u64
*unused) { return -1; }
# ifdef CONFIG_CPU_IDLE_GOV_MENU
extern void menu_hrtimer_cancel(void);
# else
-static inline void menu_hrtimer_cancel(void) { return -1; }
+static inline void menu_hrtimer_cancel(void) { }
# endif /* CONFIG_CPU_IDLE_GOV_MENU */
#endif
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpE2R0cizhs0.pgp
Description: PGP signature
Re: [PATCH 2/5] ARM: tegra: dts: add slink controller dt entry
On Fri, 2012-10-19 at 09:56 -0600, Stephen Warren wrote:
> On 10/19/2012 03:10 AM, Laxman Dewangan wrote:
> > On Friday 19 October 2012 04:11 AM, Stephen Warren wrote:
> >> On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
> >>> Add slink controller details in the dts file of
> >>> Tegra20 and Tegra30.
> >>> diff --git a/arch/arm/boot/dts/tegra20.dtsi
> >>> b/arch/arm/boot/dts/tegra20.dtsi
> >>> +slink@7000d400 {
> >>> +compatible = "nvidia,tegra20-slink";
> >>> +reg =<0x7000d400 0x200>;
> >>> +interrupts =<0 59 0x04>;
> >>> +nvidia,dma-req-sel =<15>;
> >
>
> (Oh, you need a space before and after the = in all the lines above)
>
> >> I thought the common DT DMA bindings were going to be in 3.7, and hence
> >> we could just use them here rather than inventing another custom
> >> property for this purpose?
> >
> > Adding Vinod here.
> >
> > I looked the dma devicetree bingind document and did not found the
> > generic binding name. Howvere, for arm-pl330.txt, it is explained as ...
>
> That's not the generic bindings. I guess they didn't get merged then. I
> guess we can continue with custom bindings until they are.
Yes they are in topic topic/dmaengine_dt in my tree. Will be merged once
we sort out slave apis.
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Replace the type check code with typecheck() in kfifo_in
In kfifo_in marco, one piece of code which is arounded by if(0) will check the
type of __tmp->ptr_const and __buf. If they are different type, there will
output a warning during compiling. This piece of code is not self explaining
and a little bit hard to understand.
Based on Andrew Morton's suggestion, this patch replace this with typecheck()
which will be easy to understand.
In the same file, there are several places with the same code style. This
patch change them too.
Signed-off-by: Wei Yang
Reviewed-by: Andrew Morton
Reviewed-by: richard -rw- weinberger
---
include/linux/kfifo.h | 22 +-
1 files changed, 5 insertions(+), 17 deletions(-)
diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 10308c6..680c293 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -390,10 +390,7 @@ __kfifo_int_must_check_helper( \
unsigned int __ret; \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
- __dummy = (typeof(__val))NULL; \
- } \
+ typecheck(typeof(__tmp->ptr_const), __val); \
if (__recsize) \
__ret = __kfifo_in_r(__kfifo, __val, sizeof(*__val), \
__recsize); \
@@ -433,7 +430,7 @@ __kfifo_uint_must_check_helper( \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
if (0) \
- __val = (typeof(__tmp->ptr))0; \
+ __val = (typeof(__tmp->ptr))NULL; \
if (__recsize) \
__ret = __kfifo_out_r(__kfifo, __val, sizeof(*__val), \
__recsize); \
@@ -512,10 +509,7 @@ __kfifo_uint_must_check_helper( \
unsigned long __n = (n); \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr_const) __dummy __attribute__ ((unused)); \
- __dummy = (typeof(__buf))NULL; \
- } \
+ typecheck(typeof(__tmp->ptr_const), __buf);\
(__recsize) ?\
__kfifo_in_r(__kfifo, __buf, __n, __recsize) : \
__kfifo_in(__kfifo, __buf, __n); \
@@ -565,10 +559,7 @@ __kfifo_uint_must_check_helper( \
unsigned long __n = (n); \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr) __dummy = NULL; \
- __buf = __dummy; \
- } \
+ typecheck(typeof(__tmp->ptr), __buf); \
(__recsize) ?\
__kfifo_out_r(__kfifo, __buf, __n, __recsize) : \
__kfifo_out(__kfifo, __buf, __n); \
@@ -777,10 +768,7 @@ __kfifo_uint_must_check_helper( \
unsigned long __n = (n); \
const size_t __recsize = sizeof(*__tmp->rectype); \
struct __kfifo *__kfifo = &__tmp->kfifo; \
- if (0) { \
- typeof(__tmp->ptr) __dummy __attribute__ ((unused)) = NULL; \
- __buf = __dummy; \
- } \
+ typecheck(typeof(__tmp->ptr), __buf); \
(__recsize) ? \
__kfifo_out_peek_r(__kfifo, __buf, __n, __recsize) : \
__kfifo_out_peek(__kfifo, __buf, __n); \
--
1.7.5.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] dmaengine: imx-dma: fix missing unlock on error in imxdma_xfer_desc()
On Sun, 2012-10-21 at 19:58 +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Add the missing unlock on the error handling path in function
> imxdma_xfer_desc().
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/dma/imx-dma.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
> index f11b5b2..7d9554c 100644
> --- a/drivers/dma/imx-dma.c
> +++ b/drivers/dma/imx-dma.c
> @@ -474,8 +474,10 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
> slot = i;
> break;
> }
> - if (slot < 0)
> + if (slot < 0) {
> + spin_unlock_irqrestore(&imxdma->lock, flags);
> return -EBUSY;
> + }
>
> imxdma->slots_2d[slot].xsr = d->x;
> imxdma->slots_2d[slot].ysr = d->y;
>
>
> --
Thanks applied
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] firmware loader: introduce kernel parameter to customize fw search path
On Wed, Oct 24, 2012 at 11:18 AM, Greg Kroah-Hartman wrote: > > Ick, no, not another kernel boot parameter. I would prefer the /proc/ > file solution instead, just like /proc/sys/kernel/hotplug is. OK, got it, but we could use the module parameter(firmware_class.path via kernel command) to customize the search path too, couldn't we? > > But, that really wouldn't work for boot time, so, again just like > hotplug works, make it also a Kconfig option for those distros that > build their own kernels and keep their firmware in odd places, or don't > have a /lib/ directory, can override it easily. Sound like still a solution, :-) If you agree on module parameter, that might be more flexible, IMO Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 041/193] drivers/dma: remove CONFIG_EXPERIMENTAL
On Tue, 2012-10-23 at 13:01 -0700, Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. > > CC: Vinod Koul > CC: Dan Williams > Signed-off-by: Kees Cook > --- > drivers/dma/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > index 677cd6e..dc8f4d1 100644 > --- a/drivers/dma/Kconfig > +++ b/drivers/dma/Kconfig > @@ -51,7 +51,7 @@ config ASYNC_TX_ENABLE_CHANNEL_SWITCH > > config AMBA_PL08X > bool "ARM PrimeCell PL080 or PL081 support" > - depends on ARM_AMBA && EXPERIMENTAL > + depends on ARM_AMBA > select DMA_ENGINE > select DMA_VIRTUAL_CHANNELS > help Applied thanks -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/3] dmaengine: add dma_get_channel_caps()
On Tue, 2012-10-23 at 23:49 +0100, Grant Likely wrote:
> > +enum dmaengine_apis {
> > + DMAENGINE_MEMCPY= 0x0001,
> > + DMAENGINE_XOR = 0x0002,
> > + DMAENGINE_XOR_VAL = 0x0004,
> > + DMAENGINE_PQ= 0x0008,
> > + DMAENGINE_PQ_VAL= 0x0010,
> > + DMAENGINE_MEMSET= 0x0020,
> > + DMAENGINE_SLAVE = 0x0040,
> > + DMAENGINE_CYCLIC= 0x0080,
> > + DMAENGINE_INTERLEAVED = 0x0100,
> > + DMAENGINE_SG= 0x0200,
> > +};
>
> Actually, one more comment. Why the new enum? Why can't the
> dma_transaction_type enum be used directly along with dma_cap_mask_t?
Some of the capabilities above are not there in dma_caps_t like DMA_SG.
Also DMA_INTERRUPT and DMA_PRIVATE would not make much sense here.
BUT would help to keep things simpler if have one definition which
includes all.
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/3] dmaengine: add dma_get_channel_caps()
On Tue, 2012-10-23 at 15:54 -0700, Dan Williams wrote:
> > +struct dmaengine_chan_caps {
> > + enum dmaengine_apis ops;
> > + int seg_nr;
> > + int seg_len;
> > +};
>
> This makes sense for the potentially dynamic capability properties
> that get set after configuration, but why do we need the operation
> types here? They can be retrieved from the parent device.
I was thinking that each channel can have different capabilities.
You can assign one channel for mempcy operations exclusively and some
others for slave usage exclusively.
I believe some h/w do have such assignment so would help in doing that.
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] firmware loader: introduce kernel parameter to customize fw search path
On Wed, Oct 24, 2012 at 10:49:53AM +0800, Ming Lei wrote: > This patch introduces one kernel parameter of 'fw_path' to support > customizing firmware image search path, so that people can use its > own firmware path if the default built-in paths can't meet their demand[1]. > > [1], https://lkml.org/lkml/2012/10/11/337 > > Cc: Linus Torvalds > Signed-off-by: Ming Lei Ick, no, not another kernel boot parameter. I would prefer the /proc/ file solution instead, just like /proc/sys/kernel/hotplug is. But, that really wouldn't work for boot time, so, again just like hotplug works, make it also a Kconfig option for those distros that build their own kernels and keep their firmware in odd places, or don't have a /lib/ directory, can override it easily. 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] staging/comedi: Use dev_ printks in drivers/vmk80xx.c
On Tue, Oct 23, 2012 at 4:45 AM, Greg Kroah-Hartman wrote: > Note, when you resend please enumerate what version of the patch this > is, otherwise I can get very confused. Sorry, I am going to watch out for it from the next. -- Regards, YAMANE Toshiaki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] brw_mutex: big read-write mutex
On Fri, Oct 19, 2012 at 06:54:41PM -0400, Mikulas Patocka wrote: > > > On Fri, 19 Oct 2012, Peter Zijlstra wrote: > > > > Yes, I tried this approach - it involves doing LOCK instruction on read > > > lock, remembering the cpu and doing another LOCK instruction on read > > > unlock (which will hopefully be on the same CPU, so no cacheline bouncing > > > happens in the common case). It was slower than the approach without any > > > LOCK instructions (43.3 seconds seconds for the implementation with > > > per-cpu LOCKed access, 42.7 seconds for this implementation without > > > atomic > > > instruction; the benchmark involved doing 512-byte direct-io reads and > > > writes on a ramdisk with 8 processes on 8-core machine). > > > > So why is that a problem? Surely that's already tons better then what > > you've currently got. > > Percpu rw-semaphores do not improve performance at all. I put them there > to avoid performance regression, not to improve performance. > > All Linux kernels have a race condition - when you change block size of a > block device and you read or write the device at the same time, a crash > may happen. This bug is there since ever. Recently, this bug started to > cause major trouble - multiple high profile business sites report crashes > because of this race condition. > > You can fix this race by using a read lock around I/O paths and write lock > around block size changing, but normal rw semaphore cause cache line > bouncing when taken for read by multiple processors and I/O performance > degradation because of it is measurable. This doesn't sound like a new problem. Hasn't this global access, single modifier exclusion problem been solved before in the VFS? e.g. mnt_want_write()/mnt_make_readonly() Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS after deleting file on ext4 filesystem
On Tue, Oct 23, 2012 at 08:50:22PM -0400, Nick Bowler wrote: > Hi folks, > > I just saw an ext4 oops on one of my machines after a couple months of > uptime, on Linux 3.5.2. I doubt I will be able to reproduce the problem > easily so I'm just posting this in case anyone can tell what's going on. Fixed in v3.5.3 or later kernels. (Commit 2cd45bebc56a) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] staging/sbe-2t3e3: Use netdev_ printks in main.c
fixed below checkpatch warning. - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ... Signed-off-by: YAMANE Toshiaki --- drivers/staging/sbe-2t3e3/main.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/staging/sbe-2t3e3/main.c b/drivers/staging/sbe-2t3e3/main.c index f3dbef6..c8e0398 100644 --- a/drivers/staging/sbe-2t3e3/main.c +++ b/drivers/staging/sbe-2t3e3/main.c @@ -135,9 +135,10 @@ void t3e3_read_card_serial_number(struct channel *sc) for (i = 0; i < 3; i++) sc->ether.card_serial_number[i] = t3e3_eeprom_read_word(sc, 10 + i); - printk(KERN_INFO "SBE wanPMC-2T3E3 serial number: %04X%04X%04X\n", - sc->ether.card_serial_number[0], sc->ether.card_serial_number[1], - sc->ether.card_serial_number[2]); + netdev_info(sc->dev, "SBE wanPMC-2T3E3 serial number: %04X%04X%04X\n", + sc->ether.card_serial_number[0], + sc->ether.card_serial_number[1], + sc->ether.card_serial_number[2]); } /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] posix timers: allocate timer id per process
On Wed, 2012-10-24 at 00:33 +0200, Thomas Gleixner wrote: > On Tue, 23 Oct 2012, Eric Dumazet wrote: > > > On Tue, 2012-10-23 at 23:47 +0200, Thomas Gleixner wrote: > > > > > Not so good to me. > > > > > > > Signed-off-by: Eric Dumazet > > > > > > And that should be either an Acked-by or a Reviewed-by. You can't sign > > > off on patches which have not been submitted or transported by you. > > > > I actually gave some input, provided a hash function, and so on. > > > > So this SOB was valid. I do that all the time. > > Not really. I recommend you to read the relevant file in Documentation > which covers what can have your SOB. OK I did that again, and found this : The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. And I was involved in the development of the patch. I understand you dont like it at all, so I'll remember not trying to help anymore in this area. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/16 v2] f2fs: introduce flash-friendly file system
On Wed, Oct 24, 2012 at 08:18:36AM +0900, Jaegeuk Kim wrote: > > On Tue, Oct 23, 2012 at 11:26:59AM -0700, Greg KH wrote: > > > On Tue, Oct 23, 2012 at 11:21:53AM +0900, Jaegeuk Kim wrote: > > > > mkfs.f2fs > > > > = > > > > > > > > The file system formatting tool, "mkfs.f2fs", is available from the > > > > following > > > > download page: http://sourceforge.net/projects/f2fs-tools/ > > > > > > Is there a git tree of this tool somewhere, so I don't have to > > > constantly suffer the sf.net download interface every time I want to get > > > the latest version? > > > > Oh, and where do we report bugs for this tool? I just formatted a usb > > stick with the mkfs.f2fs program, and it did not fully erase the old > > filesystem that was on there (iso9660), so when I mounted it, it did so > > in iso9660 mode, not f2fs mode. > > > > Any suggestion for reporting bugs? > Maybe via a mailing list? Mailing list is fine. > What version did you use? (1.1.0 is correct.) I used 1.1.0 > The reason we found was due to the 0'th block, so we fixed that in v1.1.0. Hm, that's what I used. I zeroed out the whole usb disk and tried again and it worked then, I was trying to debug the kernel changes, not the userspace tool, so I didn't spend much time on it :) But, if you do get a public git tree up, I will at the very least, provide a patch to handle '-h' properly for mkfs, that should 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 00/16 v2] f2fs: introduce flash-friendly file system
On Wed, Oct 24, 2012 at 08:14:44AM +0900, Jaegeuk Kim wrote: > > On Tue, Oct 23, 2012 at 11:21:53AM +0900, Jaegeuk Kim wrote: > > > mkfs.f2fs > > > = > > > > > > The file system formatting tool, "mkfs.f2fs", is available from the > > > following > > > download page:http://sourceforge.net/projects/f2fs-tools/ > > > > Is there a git tree of this tool somewhere, so I don't have to > > constantly suffer the sf.net download interface every time I want to get > > the latest version? > > I'd love to do like that. > I've managed a git tree for tools in house only, due to the company secret. > Would you suggest something for this? > I can do managing the tree outside though. git.kernel.org can work, so can github, and also, you have a sf.net project, why not use the git tree it provides you? Right now it is empty. 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: usbview 2.0 release
On Tue, Oct 23, 2012 at 10:17:22AM +0530, Anil Nair wrote: > Hello Greg, > > > No, debugfs needs to be mounted at /sys/kernel/debug/ Is it not mounted > > that way for you? Perhaps it is mounted with root-only access (default > > for 3.7-rc1 and newer kernels)? > > Yes you are right i verified "/sys/kernel/debug" has root-only access. > The kernel version i am using is 3.0.0-26-generic(Default kernel > provided by ubuntu 11.10 amd64). > > > I should just port the thing to use libusb instead of debugfs, but > > that's a larger job for such a low-priority tool. > > If you don't mind i would like to give it a try, though most of the > terminologies i don't know but i would like to give it a try, just > guide me on way of doing it thats all. Look at how the lsusb tool walks the list of all USB devices in the system, using libusb, and port that code over to usbview, replacing the big "walk and parse the devices file" functionality. It shouldn't be that hard, if you run into any problems, please let me know. 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 2/3] staging/sbe-2t3e3: Use netdev_ or dev_ or pr_ printks in module.c
fixed below checkpatch warning.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
- WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then
pr_warn(... to printk(KERN_WARNING ...
and add pr_fmt.
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/sbe-2t3e3/module.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/sbe-2t3e3/module.c
b/drivers/staging/sbe-2t3e3/module.c
index 8adb178..8e1a043 100644
--- a/drivers/staging/sbe-2t3e3/module.c
+++ b/drivers/staging/sbe-2t3e3/module.c
@@ -10,6 +10,8 @@
* This code is based on a driver written by SBE Inc.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -66,7 +68,7 @@ static int __devinit t3e3_init_channel(struct channel
*channel, struct pci_dev *
dev = alloc_hdlcdev(channel);
if (!dev) {
- printk(KERN_ERR "SBE 2T3E3" ": Out of memory\n");
+ pr_err("Out of memory\n");
err = -ENOMEM;
goto free_regions;
}
@@ -96,7 +98,8 @@ static int __devinit t3e3_init_channel(struct channel
*channel, struct pci_dev *
err = request_irq(dev->irq, &t3e3_intr, IRQF_SHARED, dev->name, dev);
if (err) {
- printk(KERN_WARNING "%s: could not get irq: %d\n", dev->name,
dev->irq);
+ netdev_warn(channel->dev, "%s: could not get irq: %d\n",
+ dev->name, dev->irq);
goto unregister_dev;
}
@@ -144,7 +147,7 @@ static int __devinit t3e3_init_card(struct pci_dev *pdev,
const struct pci_devic
break; /* found the second channel */
if (!pdev1) {
- printk(KERN_ERR "SBE 2T3E3" ": Can't find the second
channel\n");
+ dev_err(&pdev->dev, "Can't find the second channel\n");
return -EFAULT;
}
channels = 2;
@@ -153,7 +156,7 @@ static int __devinit t3e3_init_card(struct pci_dev *pdev,
const struct pci_devic
card = kzalloc(sizeof(struct card) + channels * sizeof(struct channel),
GFP_KERNEL);
if (!card) {
- printk(KERN_ERR "SBE 2T3E3" ": Out of memory\n");
+ dev_err(&pdev->dev, "Out of memory\n");
return -ENOBUFS;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [Pv-drivers] 3.7-rc2 regression : file copied to CIFS-mounted directory corrupted
Hi,
--- Original Message ---
Sender : Eric Dumazet
Date : 2012-10-24 04:39 (GMT+09:00)
Title : Re: [Pv-drivers] 3.7-rc2 regression : file copied to CIFS-mounted
directory corrupted
On Tue, 2012-10-23 at 15:50 +0200, Eric Dumazet wrote:
> Only the skb head is handled in the code you copy/pasted.
>
> You need to generalize that to code in lines ~754
>
>
> Then, the number of estimated descriptors is bad :
>
> /* conservatively estimate # of descriptors to use */
> count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) +
> skb_shinfo(skb)->nr_frags + 1;
>
>
> Yes, you need a more precise estimation and vmxnet3_map_pkt() should
> eventually split too big frags.
raw patch would be :
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index ce9d4f2..0ae1bcc 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -744,28 +744,43 @@ vmxnet3_map_pkt(struct sk_buff *skb, struct
vmxnet3_tx_ctx *ctx,
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
const struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i];
+ u32 buf_size;
- tbi = tq->buf_info + tq->tx_ring.next2fill;
- tbi->map_type = VMXNET3_MAP_PAGE;
- tbi->dma_addr = skb_frag_dma_map(&adapter->pdev->dev, frag,
- 0, skb_frag_size(frag),
- DMA_TO_DEVICE);
+ buf_offset = 0;
+ len = skb_frag_size(frag);
+ while (len) {
+ tbi = tq->buf_info + tq->tx_ring.next2fill;
+ if (len < VMXNET3_MAX_TX_BUF_SIZE) {
+ buf_size = len;
+ dw2 |= len;
+ } else {
+ buf_size = VMXNET3_MAX_TX_BUF_SIZE;
+ /* spec says that for TxDesc.len, 0 == 2^14 */
+ }
+ tbi->map_type = VMXNET3_MAP_PAGE;
+ tbi->dma_addr = skb_frag_dma_map(&adapter->pdev->dev, frag,
+ buf_offset, buf_size,
+ DMA_TO_DEVICE);
- tbi->len = skb_frag_size(frag);
+ tbi->len = buf_size;
- gdesc = tq->tx_ring.base + tq->tx_ring.next2fill;
- BUG_ON(gdesc->txd.gen == tq->tx_ring.gen);
+ gdesc = tq->tx_ring.base + tq->tx_ring.next2fill;
+ BUG_ON(gdesc->txd.gen == tq->tx_ring.gen);
- gdesc->txd.addr = cpu_to_le64(tbi->dma_addr);
- gdesc->dword[2] = cpu_to_le32(dw2 | skb_frag_size(frag));
- gdesc->dword[3] = 0;
+ gdesc->txd.addr = cpu_to_le64(tbi->dma_addr);
+ gdesc->dword[2] = cpu_to_le32(dw2);
+ gdesc->dword[3] = 0;
- dev_dbg(&adapter->netdev->dev,
- "txd[%u]: 0x%llu %u %u\n",
- tq->tx_ring.next2fill, le64_to_cpu(gdesc->txd.addr),
- le32_to_cpu(gdesc->dword[2]), gdesc->dword[3]);
- vmxnet3_cmd_ring_adv_next2fill(&tq->tx_ring);
- dw2 = tq->tx_ring.gen << VMXNET3_TXD_GEN_SHIFT;
+ dev_dbg(&adapter->netdev->dev,
+ "txd[%u]: 0x%llu %u %u\n",
+ tq->tx_ring.next2fill, le64_to_cpu(gdesc->txd.addr),
+ le32_to_cpu(gdesc->dword[2]), gdesc->dword[3]);
+ vmxnet3_cmd_ring_adv_next2fill(&tq->tx_ring);
+ dw2 = tq->tx_ring.gen << VMXNET3_TXD_GEN_SHIFT;
+
+ len -= buf_size;
+ buf_offset += buf_size;
+ }
}
ctx->eop_txd = gdesc;
@@ -886,6 +901,18 @@ vmxnet3_prepare_tso(struct sk_buff *skb,
}
}
+static int txd_estimate(const struct sk_buff *skb)
+{
+ int count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) + 1;
+ int i;
+
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ const struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i];
+
+ count += VMXNET3_TXD_NEEDED(skb_frag_size(frag));
+ }
+ return count;
+}
/*
* Transmits a pkt thru a given tq
@@ -914,9 +941,7 @@ vmxnet3_tq_xmit(struct sk_buff *skb, struct
vmxnet3_tx_queue *tq,
union Vmxnet3_GenericDesc tempTxDesc;
#endif
- /* conservatively estimate # of descriptors to use */
- count = VMXNET3_TXD_NEEDED(skb_headlen(skb)) +
- skb_shinfo(skb)->nr_frags + 1;
+ count = txd_estimate(skb);
ctx.ipv4 = (vlan_get_protocol(skb) == cpu_to_be16(ETH_P_IP));
--- Original Message End ---
Hi, Eric,
your raw patch seemed to fix the issue. But after ~200 runs, copied file has
been corrupted again.
# cmp -l /home/local.bin /mnt/cifs/new.bin | awk '{printf "%08X %02X %02X\n",
$1, strtonum(0$2), strtonum(0$3)}' > diff.log
I compared the difference between source and copied file. Size of file is
45872732 bytes (= 0x2BBF65C).
Among them, 4096 (0x1000) bytes are different, from 0x2B96001 to 0x2B97000.
Instead of original data, 0x00 was copied in those area.
patch applied on top of 2d1f4c8e ("Merge branch 'drm-fixes' of
git://people.freedesktop.org/~airlied/linux").
Regards,
Jongman Heo.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: linux-next: build failure after merge of the tty tree
On Wed, Oct 24, 2012 at 01:28:27PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/staging/dgrp/dgrp_net_ops.c: In function 'dgrp_input':
> drivers/staging/dgrp/dgrp_net_ops.c:216:27: error: 'struct tty_struct' has no
> member named 'real_raw'
> drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
> member named 'read_cnt'
> drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
> member named 'read_cnt'
> drivers/staging/dgrp/dgrp_net_ops.c:261:30: error: 'struct tty_struct' has no
> member named 'real_raw'
> drivers/staging/dgrp/dgrp_net_ops.c:276:28: error: 'struct tty_struct' has no
> member named 'real_raw'
>
> Caused by commits 53c5ee2cfb4d ("TTY: move ldisc data from tty_struct:
> simple members") and ba2e68ac6157 ("TTY: move ldisc data from tty_struct:
> read_* and echo_* and canon_* stuff") interacting with commit
> 0b52b7497271 ("staging: Add dgrp driver for Digi Realport devices") now
> in Linus' tree.
>
> I disabled building of the dgrp driver for now using this merge fix patch:
>
> From: Stephen Rothwell
> Date: Wed, 24 Oct 2012 13:25:29 +1100
> Subject: [PATCH] staging: disable dgrp driver since it is broken by tty
> changes
>
> drivers/staging/dgrp/dgrp_net_ops.c: In function 'dgrp_input':
> drivers/staging/dgrp/dgrp_net_ops.c:216:27: error: 'struct tty_struct' has no
> member named 'real_raw'
> drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
> member named 'read_cnt'
> drivers/staging/dgrp/dgrp_net_ops.c:229:8: error: 'struct tty_struct' has no
> member named 'read_cnt'
> drivers/staging/dgrp/dgrp_net_ops.c:261:30: error: 'struct tty_struct' has no
> member named 'real_raw'
> drivers/staging/dgrp/dgrp_net_ops.c:276:28: error: 'struct tty_struct' has no
> member named 'real_raw'
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/staging/dgrp/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/dgrp/Kconfig b/drivers/staging/dgrp/Kconfig
> index 39f4bb6..7d378c2 100644
> --- a/drivers/staging/dgrp/Kconfig
> +++ b/drivers/staging/dgrp/Kconfig
> @@ -2,6 +2,7 @@ config DGRP
> tristate "Digi Realport driver"
> default n
> depends on SYSFS
> + depends on BROKEN
Thanks, that makes sense for now, hopefully Jiri will return from his
conference and fix this driver up.
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 2/2] firmware loader: introduce kernel parameter to customize fw search path
This patch introduces one kernel parameter of 'fw_path' to support
customizing firmware image search path, so that people can use its
own firmware path if the default built-in paths can't meet their demand[1].
[1], https://lkml.org/lkml/2012/10/11/337
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
Documentation/firmware_class/README |1 +
Documentation/kernel-parameters.txt |9 +
drivers/base/firmware_class.c | 24 ++--
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/Documentation/firmware_class/README
b/Documentation/firmware_class/README
index 815b711..af63ad3 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README
@@ -22,6 +22,7 @@
- calls request_firmware(&fw_entry, $FIRMWARE, device)
- kernel searchs the fimware image with name $FIRMWARE directly
in the below search path of root filesystem:
+ User customized search path by kernel parameter of 'fw_path'
"/lib/firmware/updates/" UTS_RELEASE,
"/lib/firmware/updates",
"/lib/firmware/" UTS_RELEASE,
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9776f06..d1125c5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -52,6 +52,7 @@ parameter is applicable:
EVM Extended Verification Module
FB The frame buffer device is enabled.
FTRACE Function tracing enabled.
+ FW The firmware loader is enabled.
GCOVGCOV profiling is enabled.
HW Appropriate hardware is enabled.
IA-64 IA-64 architecture is enabled.
@@ -843,6 +844,14 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Format: ,,,
See also Documentation/fault-injection/.
+ fw_path=[FW]
+ Customized firmware image search path for kernel
+ direct loading, which has higher priority than
+ built-in default search path.
+ Format: , length < 256
+ direcory path, such as /lib/firmware.
+ See Documentation/firmware_class/README.
+
floppy= [HW]
See Documentation/blockdev/floppy.txt.
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..e7db931 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -274,6 +274,17 @@ static const char *fw_path[] = {
"/lib/firmware"
};
+static char fw_path_para[256];
+static int __init customized_path(char *str)
+{
+ if (strlen(str) < 256)
+ strlcpy(fw_path_para, str, sizeof(fw_path_para));
+ return 1;
+}
+__setup("fw_path=", customized_path);
+module_param_string(path, fw_path_para, sizeof(fw_path_para), 0644);
+MODULE_PARM_DESC(path, "customized firmware image search path with a higher
priority than default path");
+
/* Don't inline this: 'struct kstat' is biggish */
static noinline long fw_file_size(struct file *file)
{
@@ -313,9 +324,18 @@ static bool fw_get_filesystem_firmware(struct firmware_buf
*buf)
bool success = false;
char *path = __getname();
- for (i = 0; i < ARRAY_SIZE(fw_path); i++) {
+ for (i = -1; i < ARRAY_SIZE(fw_path); i++) {
struct file *file;
- snprintf(path, PATH_MAX, "%s/%s", fw_path[i], buf->fw_id);
+
+ if (i < 0) {
+ if (!fw_path_para[0]) /* No customized path */
+ continue;
+ snprintf(path, PATH_MAX, "%s/%s", fw_path_para,
+buf->fw_id);
+ } else {
+ snprintf(path, PATH_MAX, "%s/%s", fw_path[i],
+buf->fw_id);
+ }
file = filp_open(path, O_RDONLY, 0);
if (IS_ERR(file))
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] firmware loader: document kernel direct loading
This patch adds description on recently introduced direct firmware
loading by Linus.
Cc: Linus Torvalds
Signed-off-by: Ming Lei
---
Documentation/firmware_class/README | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/Documentation/firmware_class/README
b/Documentation/firmware_class/README
index 7eceaff..815b711 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README
@@ -18,32 +18,40 @@
High level behavior (mixed):
- kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device)
-
- userspace:
+ 1), kernel(driver):
+ - calls request_firmware(&fw_entry, $FIRMWARE, device)
+ - kernel searchs the fimware image with name $FIRMWARE directly
+ in the below search path of root filesystem:
+ "/lib/firmware/updates/" UTS_RELEASE,
+ "/lib/firmware/updates",
+ "/lib/firmware/" UTS_RELEASE,
+ "/lib/firmware"
+ - If found, goto 7), else goto 2)
+
+ 2), userspace:
- /sys/class/firmware/xxx/{loading,data} appear.
- hotplug gets called with a firmware identifier in $FIRMWARE
and the usual hotplug environment.
- hotplug: echo 1 > /sys/class/firmware/xxx/loading
- kernel: Discard any previous partial load.
+ 3), kernel: Discard any previous partial load.
- userspace:
+ 4), userspace:
- hotplug: cat appropriate_firmware_image > \
/sys/class/firmware/xxx/data
- kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
+ 5), kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
comes in.
- userspace:
+ 6), userspace:
- hotplug: echo 0 > /sys/class/firmware/xxx/loading
- kernel: request_firmware() returns and the driver has the firmware
+ 7), kernel: request_firmware() returns and the driver has the firmware
image in fw_entry->{data,size}. If something went wrong
request_firmware() returns non-zero and fw_entry is set to
NULL.
- kernel(driver): Driver code calls release_firmware(fw_entry) releasing
+ 8), kernel(driver): Driver code calls release_firmware(fw_entry) releasing
the firmware image and any related resource.
High level behavior (driver code):
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/16] f2fs: add inode operations for special inodes
On Wed, Oct 17, 2012 at 12:50:11PM +, Arnd Bergmann wrote: > On Tuesday 16 October 2012, Jaegeuk Kim wrote: > > > IIRC, fs2fs uses 4k inodes, so IMO per-inode xattr tress with > > > internal storage before spilling to an external block is probably > > > the best approach to take... > > > > Yes, indeed this is the best approach to f2fs's xattr. > > Apart from giving fs hints, it is worth enough to optimize later. > > I've thought a bit more about how this could be represented efficiently > in 4KB nodes. This would require a significant change of the way you > represent inodes, but can improve a number of things at the same time. > > The idea is to replace the fixed area in the inode that contains block > pointers with an extensible TLV (type/length/value) list that can contain > multiple variable-length fields, like this. You've just re-invented inode forks... ;) > All TLVs together with the > fixed-length inode data can fill a 4KB block. > > The obvious types would be: > > * Direct file contents if the file is less than a block > * List of block pointers, as before, minimum 1, maximum until the end > of the block > * List of indirect pointers, now also a variable length, similar to the > list of block pointers > * List of double-indirect block pointers > * direct xattr: zero-terminated attribute name followed by contents > * indirect xattr: zero-terminated attribute name followed by up to > 16 block pointers to store a maximum of 64KB sized xattrs > > This could be extended later to cover additional types, e.g. a list > of erase block pointers, triple-indirect blocks or extents. An inode fork doesn't care about the data in it - it's just an independent block mapping index. i.e. inline, direct, indirect, double indirect. The data in the fork is managed externally to the format of the fork. e.g. XFS has two forks - one for storing data (file data, directory contents, etc) and the other for storing attributes. The main issue with supporting an arbitrary number of forks is space management of the inode literal area. e.g. one fork is in inline format (e.g. direct file contents) and then we add an attribute. The attribute won't fit inline, nor will an extent form fork header, so the inline data fork has to be converted to extent format before the xattr can be added. Now scale that problem up to an arbitrary number of forks > As a variation of this, it would also be nice to turn around the order > in which the pointers are walked, to optimize for space and for growing > files, rather than for reading the beginning of a file. With this, you > can represent a 9 KB file using a list of two block pointers, and 1KB > of direct data, all in the inode. When the user adds another byte, you > only need to rewrite the inode. Similarly, a 5 MB file would have a > single indirect node (covering block pointers for 4 MB), plus 256 > separate block pointers (covering the last megabyte), and a 5 GB file > can be represented using 1 double-indirect node and 256 indirect nodes, > and each of them can still be followed by direct "tail" data and > extended attributes. I'm not sure that the resultant code complexity is worth saving an extra block here and there. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
