Re: [ 17/27] Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
On Fri, 2012-12-07 at 12:30 -0500, Joseph Salisbury wrote:
> On 12/07/2012 12:22 PM, Joseph Salisbury wrote:
> > On 12/06/2012 07:59 PM, Greg Kroah-Hartman wrote:
> >> 3.6-stable review patch. If anyone has any objections, please let me
> >> know.
> >>
> >> --
> >>
> >> From: Mike Galbraith
> >>
> >> commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 upstream.
> >>
> >> This reverts commit 800d4d30c8f20bd728e5741a3b77c4859a613f7c.
> >>
> >> Between commits 8323f26ce342 ("sched: Fix race in task_group()") and
> >> 800d4d30c8f2 ("sched, autogroup: Stop going ahead if autogroup is
> >> disabled"), autogroup is a wreck.
[...]
> > Hi Ben,
> >
> > Will you also be including this patch in v3.5 stable? It has been
> > tested and confirmed
> > to resolve http://bugs.launchpad.net/bugs/1034099
> >
> > Sincerely,
> >
> > Joe Salisbury
>
> Make that v3.2 stable. Sorry.
Yes, if there's no objection to it.
Ben.
--
Ben Hutchings
It is impossible to make anything foolproof because fools are so ingenious.
signature.asc
Description: This is a digitally signed message part
Re: [ 67/89] drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()
On Mon, 2012-12-03 at 15:35 +, Deucher, Alexander wrote: > > -Original Message- > > From: Josh Boyer [mailto:jwbo...@gmail.com] > > Sent: Monday, December 03, 2012 10:25 AM > > To: Ben Hutchings; Greg KH > > Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; akpm@linux- > > foundation.org; a...@lxorguk.ukuu.org.uk; Deucher, Alexander > > Subject: Re: [ 67/89] drm/radeon: properly track the crtc not_enabled case > > evergreen_mc_stop() > > > > On Mon, Dec 3, 2012 at 9:32 AM, Ben Hutchings > > wrote: > > > 3.2-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Alex Deucher > > > > > > commit 804cc4a0ad3a896ca295f771a28c6eb36ced7903 upstream. > > > > > > The save struct is not initialized previously so explicitly > > > mark the crtcs as not used when they are not in use. > > > > > > Signed-off-by: Alex Deucher > > > Signed-off-by: Ben Hutchings > > > > Hm. If this is needed in 3.2, presumably it's needed in 3.6 as well. I > > don't see it queued for 3.6.9, and the Cc: tag is there. > > > > Greg, Alex, was this just something that was missed, or am I wrong about > > it needing to go into 3.6? > > The original patches should go into 3.6 kernels as well: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4a15903db02026728d0cf2755c6fabae16b8db6a > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=62444b7462a2b98bc78d68736c03a7c4e66ba7e2 > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=804cc4a0ad3a896ca295f771a28c6eb36ced7903 > > I've been meaning to follow up on it, but I haven't had the time. Do > I need to send explicit patches to stable@vger or can I just ask the > above commits be cherrypicked to 3.6? It depends on whether they *can* be cleanly cherry-picked. You'll presumably want them applied to all of 3.4, 3.5 and 3.6. Ben. -- Ben Hutchings It is impossible to make anything foolproof because fools are so ingenious. signature.asc Description: This is a digitally signed message part
Re: [PATCH -stable 1/1] freezer: PF_FREEZER_NOSIG should be cleared along with PF_NOFREEZE
On Fri, 2012-12-07 at 15:49 +0100, Oleg Nesterov wrote: > This patch is only for pre-v3.3 stable trees which backported > b40a7959 "freezer: exec should clear PF_NOFREEZE along with PF_KTHREAD". > v3.3+ doesn't need this fix. [...] Thanks very much, I've added this to the queue for 3.2. However, in 3.2 PF_FORKNOEXEC is cleared by the binfmt code and not in fs/exec.c, and I left that as it is. Ben. -- Ben Hutchings It is impossible to make anything foolproof because fools are so ingenious. signature.asc Description: This is a digitally signed message part
Re: [BUG -next] cpufreq: cpufreq_governor.
On Sunday, December 09, 2012 09:17:04 PM Ilya Zykov wrote: > On 05.12.2012 22:53, Ilya Zykov wrote: > > What do I do wrong? > > > > After: modprobe cpufreq_ondemand > > I have: > > > > WARNING: Error inserting freq_table > > (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko): > > Unknown symbol in module, or unknown parameter (see dmesg) > > FATAL: Error inserting cpufreq_ondemand > > (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/cpufreq_ondemand.ko): > > Unknown symbol in module, or unknown parameter (see dmesg) > > > > dmesg: > > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > > __cpufreq_driver_getavg (err 0) > > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > > sysfs_create_group (err 0) > > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > > sysfs_remove_group (err 0) > > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > > __cpufreq_driver_target (err 0) > > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > > get_cpu_idle_time_us (err 0) > > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > > delayed_work_timer_fn (err 0) > > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > > get_cpu_iowait_time_us (err 0) > > > > cat /proc/kallsyms |grep freq_dr > > 814976e0 T __cpufreq_driver_target > > 814987e0 T __cpufreq_driver_getavg > > 81498850 T cpufreq_driver_target > > 81881650 r __ksymtab___cpufreq_driver_getavg > > 81881660 r __ksymtab___cpufreq_driver_target > > 81883b40 r __ksymtab_cpufreq_driver_target > > 81894290 r __kcrctab___cpufreq_driver_getavg > > 81894298 r __kcrctab___cpufreq_driver_target > > 81895508 r __kcrctab_cpufreq_driver_target > > 818b3080 r __kstrtab___cpufreq_driver_getavg > > 818b3098 r __kstrtab_cpufreq_driver_target > > 818b30ae r __kstrtab___cpufreq_driver_target > > 81e240c8 b cpufreq_driver_lock > > 81e240d0 b cpufreq_driver > > a0c42000 d acpi_cpufreq_driver [acpi_cpufreq] > > I managed to fix: > > git checkout 16642a2e7be23bb -- drivers/cpufreq > git checkout 250f6715a4112d668 -- include/linux/cpufreq.h Can you please send your .config? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] ACPI: Make acpi_bus_add() and acpi_bus_start() visibly different
From: Rafael J. Wysocki
The current ACPI namespace scanning code suggests that acpi_bus_add()
and acpi_bus_start() share some code. In fact, however, they are
completely different code paths, so refactor the code to make that
distinction visibly clear.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 57
1 file changed, 27 insertions(+), 30 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1626,28 +1626,22 @@ static acpi_status acpi_bus_check_add(ac
return AE_OK;
}
-static acpi_status acpi_bus_probe_start(acpi_handle handle, u32 lvl,
- void *context, void **not_used)
+static acpi_status acpi_bus_match_device(acpi_handle handle, u32 lvl,
+void *not_used, void **ret_not_used)
{
- struct acpi_bus_ops *ops = context;
struct acpi_device *device;
acpi_status status = AE_OK;
if (acpi_bus_get_device(handle, ))
return AE_CTRL_DEPTH;
- if (ops->acpi_op_add) {
- if (!acpi_match_device_ids(device, acpi_platform_device_ids)) {
- /* This is a known good platform device. */
- acpi_create_platform_device(device);
- } else {
- int ret = device_attach(>dev);
- acpi_hot_add_bind(device);
- if (ret)
- status = AE_CTRL_DEPTH;
- }
- } else if (ops->acpi_op_start) {
- if (ACPI_FAILURE(acpi_start_single_object(device)))
+ if (!acpi_match_device_ids(device, acpi_platform_device_ids)) {
+ /* This is a known good platform device. */
+ acpi_create_platform_device(device);
+ } else {
+ int ret = device_attach(>dev);
+ acpi_hot_add_bind(device);
+ if (ret)
status = AE_CTRL_DEPTH;
}
return status;
@@ -1670,7 +1664,7 @@ static int acpi_bus_scan(acpi_handle han
acpi_bus_check_add, NULL, ops, );
if (device)
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- acpi_bus_probe_start, NULL, ops, NULL);
+ acpi_bus_match_device, NULL, NULL, NULL);
else
ret = -ENODEV;
@@ -1697,31 +1691,34 @@ int
acpi_bus_add(struct acpi_device **child,
struct acpi_device *parent, acpi_handle handle, int type)
{
- struct acpi_bus_ops ops;
-
- memset(, 0, sizeof(ops));
- ops.acpi_op_add = 1;
+ struct acpi_bus_ops ops = { .acpi_op_add = 1, };
return acpi_bus_scan(handle, , child);
}
EXPORT_SYMBOL(acpi_bus_add);
-int acpi_bus_start(struct acpi_device *device)
+static acpi_status acpi_bus_start_device(acpi_handle handle, u32 lvl,
+void *not_used, void **ret_not_used)
{
- struct acpi_bus_ops ops;
- int result;
+ struct acpi_device *device;
+ acpi_status status;
- if (!device)
- return -EINVAL;
+ if (acpi_bus_get_device(handle, ))
+ return AE_CTRL_DEPTH;
- memset(, 0, sizeof(ops));
- ops.acpi_op_start = 1;
+ status = acpi_start_single_object(device);
+ return ACPI_SUCCESS(status) ? status : AE_CTRL_DEPTH;
+}
- result = acpi_bus_scan(device->handle, , NULL);
+int acpi_bus_start(struct acpi_device *device)
+{
+ if (!device)
+ return -EINVAL;
+ acpi_walk_namespace(ACPI_TYPE_ANY, device->handle, ACPI_UINT32_MAX,
+ acpi_bus_start_device, NULL, NULL, NULL);
acpi_update_all_gpes();
-
- return result;
+ return 0;
}
EXPORT_SYMBOL(acpi_bus_start);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] ACPI: Reduce the usage of struct acpi_bus_ops
From: Rafael J. Wysocki
Objects of type struct acpi_bus_ops are currently used to pass
information between different parts of the ACPI namespace scanning
code, sometimes in quite convoluted ways. It turns out that that
is not necessary in some cases, so simplify the code by reducing
the utilization of struct acpi_bus_ops objects where clearly
possible.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 39 +++
1 file changed, 15 insertions(+), 24 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1527,7 +1527,6 @@ end:
static void acpi_bus_add_power_resource(acpi_handle handle)
{
struct acpi_bus_ops ops = {
- .acpi_op_add = 1,
.acpi_op_start = 1,
.acpi_op_match = 1,
};
@@ -1581,7 +1580,6 @@ static int acpi_bus_type_and_status(acpi
static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl,
void *context, void **return_value)
{
- struct acpi_bus_ops *ops = context;
struct acpi_device *device = NULL;
int type;
unsigned long long sta;
@@ -1609,11 +1607,13 @@ static acpi_status acpi_bus_check_add(ac
* so, we needn't add it again, but we may still have to start it.
*/
acpi_bus_get_device(handle, );
- if (ops->acpi_op_add && !device) {
- struct acpi_bus_ops add_ops = *ops;
+ if (!device) {
+ struct acpi_bus_ops ops = {
+ .acpi_op_start = !!context,
+ .acpi_op_match = 0,
+ };
- add_ops.acpi_op_match = 0;
- acpi_add_single_object(, handle, type, sta, _ops);
+ acpi_add_single_object(, handle, type, sta, );
if (!device)
return AE_CTRL_DEPTH;
@@ -1647,21 +1647,21 @@ static acpi_status acpi_bus_match_device
return status;
}
-static int acpi_bus_scan(acpi_handle handle, struct acpi_bus_ops *ops,
+static int acpi_bus_scan(acpi_handle handle, bool start,
struct acpi_device **child)
{
void *device = NULL;
acpi_status status;
int ret = 0;
- status = acpi_bus_check_add(handle, 0, ops, );
+ status = acpi_bus_check_add(handle, 0, (void *)start, );
if (ACPI_FAILURE(status)) {
ret = -ENODEV;
goto out;
}
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- acpi_bus_check_add, NULL, ops, );
+ acpi_bus_check_add, NULL, (void *)start, );
if (device)
acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
acpi_bus_match_device, NULL, NULL, NULL);
@@ -1691,9 +1691,7 @@ int
acpi_bus_add(struct acpi_device **child,
struct acpi_device *parent, acpi_handle handle, int type)
{
- struct acpi_bus_ops ops = { .acpi_op_add = 1, };
-
- return acpi_bus_scan(handle, , child);
+ return acpi_bus_scan(handle, false, child);
}
EXPORT_SYMBOL(acpi_bus_add);
@@ -1781,12 +1779,10 @@ static int acpi_bus_scan_fixed(void)
{
int result = 0;
struct acpi_device *device = NULL;
- struct acpi_bus_ops ops;
-
- memset(, 0, sizeof(ops));
- ops.acpi_op_add = 1;
- ops.acpi_op_start = 1;
- ops.acpi_op_match = 1;
+ struct acpi_bus_ops ops = {
+ .acpi_op_start = 1,
+ .acpi_op_match = 1,
+ };
/*
* Enumerate all fixed-feature devices.
@@ -1812,11 +1808,6 @@ static int acpi_bus_scan_fixed(void)
int __init acpi_scan_init(void)
{
int result;
- struct acpi_bus_ops ops;
-
- memset(, 0, sizeof(ops));
- ops.acpi_op_add = 1;
- ops.acpi_op_start = 1;
result = bus_register(_bus_type);
if (result) {
@@ -1830,7 +1821,7 @@ int __init acpi_scan_init(void)
/*
* Enumerate devices in the ACPI namespace.
*/
- result = acpi_bus_scan(ACPI_ROOT_OBJECT, , _root);
+ result = acpi_bus_scan(ACPI_ROOT_OBJECT, true, _root);
if (!result)
result = acpi_bus_scan_fixed();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] ACPI: Change the ordering of PCI root bridge driver registrarion
From: Rafael J. Wysocki
Devices created by acpi_create_platform_device() sometimes may need
to be added to the device hierarchy as children of PCI bridges. For
this purpose, however, the struct pci_dev objects representing those
bridges need to exist before the platform devices in question are
added, but this is only possible if the PCI root bridge driver is
registered before the initial scanning of the ACPI namespace
(that driver's .add() routine creates the required struct pci_dev
objects).
For this reason, call acpi_pci_root_init() from acpi_scan_init()
before scanning the ACPI namespace for the first time instead of
running it from a separate subsys initcall. Since the previous patch
has changed the ACPI namespace scanning algorithm, this change does
not affect the PCI root bridge driver's functionality during boot.
It also makes the situation during boot more similar to the situation
during hot-plug (in which the PCI root bridge driver is always
present) and so it helps to reduce arbitary differences between
the hot-plug and boot PCI root bridge code.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/internal.h |1 +
drivers/acpi/pci_root.c |4 +---
drivers/acpi/scan.c |1 +
3 files changed, 3 insertions(+), 3 deletions(-)
Index: linux/drivers/acpi/internal.h
===
--- linux.orig/drivers/acpi/internal.h
+++ linux/drivers/acpi/internal.h
@@ -67,6 +67,7 @@ struct acpi_ec {
extern struct acpi_ec *first_ec;
+int acpi_pci_root_init(void);
int acpi_ec_init(void);
int acpi_ec_ecdt_probe(void);
int acpi_boot_ec_enable(void);
Index: linux/drivers/acpi/pci_root.c
===
--- linux.orig/drivers/acpi/pci_root.c
+++ linux/drivers/acpi/pci_root.c
@@ -674,7 +674,7 @@ static int acpi_pci_root_remove(struct a
return 0;
}
-static int __init acpi_pci_root_init(void)
+int __init acpi_pci_root_init(void)
{
acpi_hest_init();
@@ -687,5 +687,3 @@ static int __init acpi_pci_root_init(voi
return 0;
}
-
-subsys_initcall(acpi_pci_root_init);
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1828,6 +1828,7 @@ int __init acpi_scan_init(void)
}
acpi_power_init();
+ acpi_pci_root_init();
/*
* Enumerate devices in the ACPI namespace.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] ACPI: Change the ordering of acpi_bus_check_add()
From: Rafael J. Wysocki
If acpi_bus_check_add() is called for a handle already having an
existing struct acpi_device object attached, it is not necessary to
check the type and status of the device correspondig to it, so
change the ordering of acpi_bus_check_add() to avoid that.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1582,6 +1582,10 @@ static acpi_status acpi_bus_check_add(ac
acpi_status status;
int result;
+ acpi_bus_get_device(handle, );
+ if (device)
+ goto out;
+
result = acpi_bus_type_and_status(handle, , );
if (result)
return AE_OK;
@@ -1602,17 +1606,13 @@ static acpi_status acpi_bus_check_add(ac
* We may already have an acpi_device from a previous enumeration. If
* so, we needn't add it again, but we may still have to start it.
*/
- acpi_bus_get_device(handle, );
- if (!device) {
- acpi_add_single_object(, handle, type, sta,
- ACPI_BUS_ADD_BASIC);
- if (!device)
- return AE_CTRL_DEPTH;
+ acpi_add_single_object(, handle, type, sta, ACPI_BUS_ADD_BASIC);
+ if (!device)
+ return AE_CTRL_DEPTH;
- device->add_type = context ?
- ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH;
- }
+ device->add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH;
+ out:
if (!*return_value)
*return_value = device;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] ACPI: Change the ACPI namespace scanning code ordering
Hi, The following patches change the ordering of the ACPI namespace scanning code so that all struct acpi_device objects in the given scope are registered before ACPI drivers are probed against them. They also do some simplifications and clarifications of the code made possible by this main change. This is done for three basic reasons. First, we need the boot ACPI namespace scanning code to be as similar as reasonably possible to the hot-plug ACPI namespace scanning code. Second, the ordering of PCI devices enumeration versus ACPI-backed platform devices registration needs to be such that the PCI devices in the given scope are all registered first. Finally, when we start to actually manage ACPI device resources as appropriate (e.g. resolve resource conflicts properly) we'll need all struct acpi_device nodes to be registered before any "companion" physical nodes or ACPI drivers are bound to them. The patches have been tested on Toshiba Portege R500 without breaking stuff (I used some additional debug code to verify that the ordering of device discovery had not been modified by them), but if you see any problems with them regarding hot-plug, please let me know. [1/6] - Separate adding ACPI device objects from probing ACPI drivers. [2/6] - Change the ordering of PCI root bridge driver registration. [3/6] - Make acpi_bus_add() and acpi_bus_start() visibly different. [4/6] - Reduce the usage of struct acpi_bus_ops [5/6] - Replace struct acpi_bus_ops with an enum type [6/6] - Change the ordering of acpi_bus_check_add() to avoid unnecessary checks. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] ACPI: Separate adding ACPI device objects from probing ACPI drivers
From: Rafael J. Wysocki
Currently, as soon as an ACPI device node object (struct acpi_device)
is created, the driver core attempts to probe ACPI drivers against
it. That leads to some unpleasant side effects, like the fact that
the boot code path for ACPI namespace scanning is different from the
analogous hot-plug code path (during boot ACPI drivers are not
present when ACPI device node objects are registered, so they are
guaranteed not to be probed, which is not the case during hot-plug).
That, in turn, leads to unnecessary complications in the PCI
enumeration algorithm.
Reduce the differences between the boot and hot-plug cases by
splitting the ACPI namespace scanning for devices into two passes,
such that struct acpi_device objects are registerd in the first
patch without probing ACPI drivers and the drivers are probed
against them directly in the second pass. This way ACPI drivers
can assume that all of the ACPI device node objects in the given
scope will be registered when their .add() routines run and the
hot-plug case becomes the same as the boot case from their
perspective.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 96 +---
include/acpi/acpi_bus.h |1
2 files changed, 68 insertions(+), 29 deletions(-)
Index: linux/include/acpi/acpi_bus.h
===
--- linux.orig/include/acpi/acpi_bus.h
+++ linux/include/acpi/acpi_bus.h
@@ -98,6 +98,7 @@ typedef void (*acpi_op_notify) (struct a
struct acpi_bus_ops {
u32 acpi_op_add:1;
u32 acpi_op_start:1;
+ u32 acpi_op_match:1;
};
struct acpi_device_ops {
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -494,7 +494,8 @@ static int acpi_bus_match(struct device
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = to_acpi_driver(drv);
- return !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
+ return acpi_dev->bus_ops.acpi_op_match
+ && !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
}
static int acpi_device_uevent(struct device *dev, struct kobj_uevent_env *env)
@@ -1418,6 +1419,17 @@ static int acpi_bus_remove(struct acpi_d
return 0;
}
+/*
+ * acpi_hot_add_bind - Bind _ADR-based devices on hot-add.
+ * @device: ACPI device node to bind.
+ */
+static void acpi_hot_add_bind(struct acpi_device *device)
+{
+ if (device->flags.bus_address
+ && device->parent && device->parent->ops.bind)
+ device->parent->ops.bind(device);
+}
+
static int acpi_add_single_object(struct acpi_device **child,
acpi_handle handle, int type,
unsigned long long sta,
@@ -1490,13 +1502,8 @@ static int acpi_add_single_object(struct
result = acpi_device_register(device);
- /*
-* Bind _ADR-Based Devices when hot add
-*/
- if (device->flags.bus_address) {
- if (device->parent && device->parent->ops.bind)
- device->parent->ops.bind(device);
- }
+ if (device->bus_ops.acpi_op_match)
+ acpi_hot_add_bind(device);
end:
if (!result) {
@@ -1522,6 +1529,7 @@ static void acpi_bus_add_power_resource(
struct acpi_bus_ops ops = {
.acpi_op_add = 1,
.acpi_op_start = 1,
+ .acpi_op_match = 1,
};
struct acpi_device *device = NULL;
@@ -1574,9 +1582,9 @@ static acpi_status acpi_bus_check_add(ac
void *context, void **return_value)
{
struct acpi_bus_ops *ops = context;
+ struct acpi_device *device = NULL;
int type;
unsigned long long sta;
- struct acpi_device *device;
acpi_status status;
int result;
@@ -1600,48 +1608,77 @@ static acpi_status acpi_bus_check_add(ac
* We may already have an acpi_device from a previous enumeration. If
* so, we needn't add it again, but we may still have to start it.
*/
- device = NULL;
acpi_bus_get_device(handle, );
if (ops->acpi_op_add && !device) {
- acpi_add_single_object(, handle, type, sta, ops);
- /* Is the device a known good platform device? */
- if (device
- && !acpi_match_device_ids(device, acpi_platform_device_ids))
- acpi_create_platform_device(device);
- }
+ struct acpi_bus_ops add_ops = *ops;
- if (!device)
- return AE_CTRL_DEPTH;
-
- if (ops->acpi_op_start && !(ops->acpi_op_add)) {
- status = acpi_start_single_object(device);
- if (ACPI_FAILURE(status))
+ add_ops.acpi_op_match = 0;
+ acpi_add_single_object(,
[PATCH 5/6] ACPI: Replace struct acpi_bus_ops with enum type
From: Rafael J. Wysocki
Notice that one member of struct acpi_bus_ops, acpi_op_add, is not
used anywhere any more and the relationship between its remaining
members, acpi_op_match and acpi_op_start, is such that it doesn't
make sense to set the latter without setting the former at the same
time. Therefore, replace struct acpi_bus_ops with new a enum type,
enum acpi_bus_add_type, with three values, ACPI_BUS_ADD_BASIC,
ACPI_BUS_ADD_MATCH, ACPI_BUS_ADD_START, corresponding to
both acpi_op_match and acpi_op_start unset, acpi_op_match set and
acpi_op_start unset, and both acpi_op_match and acpi_op_start set,
respectively.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c | 35 ---
include/acpi/acpi_bus.h | 15 ---
2 files changed, 20 insertions(+), 30 deletions(-)
Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -494,7 +494,7 @@ static int acpi_bus_match(struct device
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = to_acpi_driver(drv);
- return acpi_dev->bus_ops.acpi_op_match
+ return acpi_dev->add_type >= ACPI_BUS_ADD_MATCH
&& !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
}
@@ -580,7 +580,7 @@ static int acpi_device_probe(struct devi
ret = acpi_bus_driver_init(acpi_dev, acpi_drv);
if (!ret) {
- if (acpi_dev->bus_ops.acpi_op_start)
+ if (acpi_dev->add_type == ACPI_BUS_ADD_START)
acpi_start_single_object(acpi_dev);
if (acpi_drv->ops.notify) {
@@ -1433,7 +1433,7 @@ static void acpi_hot_add_bind(struct acp
static int acpi_add_single_object(struct acpi_device **child,
acpi_handle handle, int type,
unsigned long long sta,
- struct acpi_bus_ops *ops)
+ enum acpi_bus_add_type add_type)
{
int result;
struct acpi_device *device;
@@ -1449,7 +1449,7 @@ static int acpi_add_single_object(struct
device->device_type = type;
device->handle = handle;
device->parent = acpi_bus_get_parent(handle);
- device->bus_ops = *ops; /* workround for not call .start */
+ device->add_type = add_type;
STRUCT_TO_INT(device->status) = sta;
acpi_device_get_busid(device);
@@ -1502,7 +1502,7 @@ static int acpi_add_single_object(struct
result = acpi_device_register(device);
- if (device->bus_ops.acpi_op_match)
+ if (device->add_type >= ACPI_BUS_ADD_MATCH)
acpi_hot_add_bind(device);
end:
@@ -1526,16 +1526,12 @@ end:
static void acpi_bus_add_power_resource(acpi_handle handle)
{
- struct acpi_bus_ops ops = {
- .acpi_op_start = 1,
- .acpi_op_match = 1,
- };
struct acpi_device *device = NULL;
acpi_bus_get_device(handle, );
if (!device)
acpi_add_single_object(, handle, ACPI_BUS_TYPE_POWER,
- ACPI_STA_DEFAULT, );
+ ACPI_STA_DEFAULT, ACPI_BUS_ADD_START);
}
static int acpi_bus_type_and_status(acpi_handle handle, int *type,
@@ -1608,16 +1604,13 @@ static acpi_status acpi_bus_check_add(ac
*/
acpi_bus_get_device(handle, );
if (!device) {
- struct acpi_bus_ops ops = {
- .acpi_op_start = !!context,
- .acpi_op_match = 0,
- };
-
- acpi_add_single_object(, handle, type, sta, );
+ acpi_add_single_object(, handle, type, sta,
+ ACPI_BUS_ADD_BASIC);
if (!device)
return AE_CTRL_DEPTH;
- device->bus_ops.acpi_op_match = 1;
+ device->add_type = context ?
+ ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH;
}
if (!*return_value)
@@ -1779,10 +1772,6 @@ static int acpi_bus_scan_fixed(void)
{
int result = 0;
struct acpi_device *device = NULL;
- struct acpi_bus_ops ops = {
- .acpi_op_start = 1,
- .acpi_op_match = 1,
- };
/*
* Enumerate all fixed-feature devices.
@@ -1791,7 +1780,7 @@ static int acpi_bus_scan_fixed(void)
result = acpi_add_single_object(, NULL,
ACPI_BUS_TYPE_POWER_BUTTON,
ACPI_STA_DEFAULT,
- );
+ ACPI_BUS_ADD_START);
device_init_wakeup(>dev, true);
}
@@ -1799,7 +1788,7 @@ static int acpi_bus_scan_fixed(void)
result
Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
On Sun, Dec 9, 2012 at 5:07 PM, Guenter Roeck wrote: > On Sun, Dec 09, 2012 at 11:03:19AM +, Alan Cox wrote: >> On Sun, 09 Dec 2012 01:58:19 -0800 >> anish kumar wrote: >> >> > On Fri, 2012-12-07 at 16:49 +, Alan Cox wrote: >> > > > I could imagine declaring the activity request buttons to be "input", >> > > > but for >> > > > presence detects it is a bit far fetched and would add too much >> > > > complexity. >> > > >> > > Android tries to address this with its switch class driver, but I'm not >> > > sure its actually got anything over making them input devices. >> > >> > Sorry for not understanding the context here.How the debounce sysfs >> > added by Guenter has anything to do with switch driver in android? >> >> The other more general option is to make the input layer do the debounce >> and make them all inputs rather than just relying on any gpio layer >> support. >> > The gpio pins I am dealing with are provided by an FPGA which is used on > various > boards. While the gpio access registers are always the same, the actual usage > is > board specific. This means I either need to write ugly code, or use the gpio > subsystem to provide access to the gpio pins. Ugly code is out of the > question, > which means I'll need gpio support. > > Anyway, I want to keep things simple, not add unnecessary complexity. Having > to > go through the input subsystem just to be able to support debounce on a couple > of input pins doesn't really sound simple. Guess I'll have to find another > solution if the patch is not accepted. Maybe I'll add a "debounce" property to > the gpio driver's of properties. I haven't looked deeply at the patch to give you an answer yet, but I'd recommend you go with the DT property approach anyway. The gpio sysfs interface is horribly designed and I'm not keen on adding new features to it. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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/5] asm-generic/mmu.h: Remove unused vmlist field from mm_context_t
On Tuesday 04 December 2012, Lars-Peter Clausen wrote:
> On 12/04/2012 12:54 AM, Arnd Bergmann wrote:
> > On Thursday 01 November 2012, Lars-Peter Clausen wrote:
> >> Nothing is using the vmlist field in mm_context_t anymore. It has been
> >> removed
> >> from the non-generic versions over 3 years ago 8feae1311 ("NOMMU: Make
> >> VMAs per
> >> MM as for MMU-mode linux").
> >>
> >> Signed-off-by: Lars-Peter Clausen
> >
> > Whole series:
> >
> > Acked-by: Arnd Bergmann
> >
> > Do you want to include the patches in a patch set of your own, or should I
> > put them
> > into the asm-generic tree?
> >
> > Arnd
>
> Hi Arnd,
>
> The plan was to let it go through the asm-generic tree.
Sorry for all the delay. I've applied it now.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kswapd craziness in 3.7
Dne 9.12.2012 02:01, Linus Torvalds napsal(a): On Sat, 8 Dec 2012, Zlatko Calusic wrote: Or sooner... in short: nothing's changed! On a 4GB RAM system, where applications use close to 2GB, kswapd likes to keep around 1GB free (unused), leaving only 1GB for page/buffer cache. If I force bigger page cache by reading a big file and thus use the unused 1GB of RAM, kswapd will soon (in a matter of minutes) evict those (or other) pages out and once again keep unused memory close to 1GB. Ok, guys, what was the reclaim or kswapd patch during the merge window that actually caused all of these insane problems? It seems it was more fundamentally buggered than the fifteen-million fixes for kswapd we have already picked up. (Ok, I may be exaggerating the number of patches, but it's starting to feel that way - I thought that 3.7 was going to be a calm and easy release, but the kswapd issues seem to just keep happening. We've been fighting the kswapd changes for a while now.) Trying to keep a gigabyte free (presumably because that way we have lots of high-order alloction pages) is ridiculous. Is it one of the compaction changes? Mel? Ideas? Very true It's just as simple a making dd if=/dev/zero of=/tmp/zero bs=1M count=0 seek=100 and now dd if=/tmp/zero of=/dev/null bs=1M and kswapd fights with dd for CPU time Zdenek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI
On 12/07/2012 04:14 PM, Theodore Ts'o wrote: On Fri, Dec 07, 2012 at 02:30:19PM -0500, Steven Rostedt wrote: How is this similar? By adding this bit, we removed incentive from a group of developers that have the means to fix the real issue at hand (the performance problem with ext4). Thus, it means that they have a work around that's good enough for them, but the rest of us suffer. That assumes that there **is** a way to claw back the performance loss, and Chris Mason has demonstrated the performance hit exists with xfs as well (950 MB/s vs. 400 MB/s; that's more than a factor of two). Sometimes, you have to make the engineering tradeoffs. That's why we're engineers, for goodness sakes. Sometimes, it's just not possible to square the circle. Keep in mind that no one has tried to retune or adjust XFS (or other file systems) for this workload. I don't believe that the technique of forcing people who need that performance to suffer in order to induce them to try to engineer a solution which may or may not exist is really the best or fairest way to go about things. The proposed solution will not ship in any enterprise distro. Google, I assume, would require some specific non-normal user access permission. That means that this solution will not be usable by the vast majority of users, so it is clear that we do need to work on fixing the performance at the root instead of plastering over the behaviour. ric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 v3 7/9] yield_to(), cpu-hotplug: Prevent offlining of other CPUs properly
On 12/10, Srivatsa S. Bhat wrote: > > On 12/10/2012 01:18 AM, Oleg Nesterov wrote: > >> - if (preempt && rq != p_rq) > >> + if (preempt && rq != p_rq && cpu_online(task_cpu(p))) > > > > Why do we need this change? > > > > Afaics, you could add BUG_ON(!cpu_online(...)) instead? > > > > I am just curious. > > > > Oh, I think that's a remnant of v1 (which needed readers to use > cpu_online_stable()). You're right, we don't need it. Ah OK, thanks. > Or we could put a > BUG_ON instead, like you suggested. IMHO it would be better to simply drop this chunk. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/49] Automatic NUMA Balancing v10
On Sun, Dec 09, 2012 at 08:36:31PM +, Mel Gorman wrote: > Either way, last night I applied a patch on top of latest tip/master to > remove the nr_cpus_allowed check so that numacore would be enabled again > and tested that. In some places it has indeed much improved. In others > it is still regressing badly and in two case, it's corrupting memory -- > specjbb when THP is enabled crashes when running for single or multiple > JVMs. It is likely that a zero page is being inserted due to a race with > migration and causes the JVM to throw a null pointer exception. Here is > the comparison on the rough off-chance you actually read it this time. Are you talking about huge zero page, right? I've fixed a race in huge zero page implementation recently[1]. Symptoms were similar -- SIGSEGV in JVM. The patch is in mmotm-2012-12-05-16-56 and later. [1] http://lkml.org/lkml/2012/11/30/279 -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
Damn, sorry for noise. I missed this part... On 12/10, Srivatsa S. Bhat wrote: > > On 12/10/2012 12:44 AM, Oleg Nesterov wrote: > > the latency. And I guess something like kick_all_cpus_sync() is "too heavy". > > I hadn't considered that. Thinking of it, I don't think it would help us.. > It won't get rid of the currently running preempt_disable() sections no? Sure. But (again, this is only my feeling so far) given that get_online_cpus_atomic() does cli/sti, this can help to implement ensure-the-readers-must-see-the-pending-writer. IOW this might help to implement sync-with-readers. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 12/07, Srivatsa S. Bhat wrote: > > 4. No deadlock possibilities > >Per-cpu locking is not the way to go if we want to have relaxed rules >for lock-ordering. Because, we can end up in circular-locking dependencies >as explained in https://lkml.org/lkml/2012/12/6/290 OK, but this assumes that, contrary to what Steven said, read-write-read deadlock is not possible when it comes to rwlock_t. So far I think this is true and we can't deadlock. Steven? However. If this is true, then compared to preempt_disable/stop_machine livelock is possible. Probably this is fine, we have the same problem with get_online_cpus(). But if we can accept this fact I feel we can simmplify this somehow... Can't prove, only feel ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New system call wanted: fdreopen
On Sun, Dec 09, 2012 at 01:37:33PM -0600, Chris Adams wrote: > Once upon a time, Tristan Wibberley said: > >A common idiom on Linux is to open a file and keep the fd open so that > >the underlying file can be unlinked from its directory. But if the file > >needs to be read from several different parts of the codebase then due to > >the file descriptor having exactly one read pointer those different parts > >must be synchronised which is a relatively difficult task. > > I think you can get similar behavior entirely in user space and in a > fashion portable to at least BSD systems. You could fork() (which would > create a separate FD in the child), pass the FD back to the parent over > a socket, and then have the child exit. ... and here's your well-earned F for UNIX101. fork() will *NOT* do anything of that sort. Not on anything starting at v1 - the bug you want to rely upon had been killed very early, possibly even before the migration from PDP-8 to PDP-11. Think how would something like (ls;ls) >/tmp/a work if you didn't have current file offset shared across fork(2). Parent doesn't do any IO here; both children inherit stdout from it when they are forked and write to said stdout. We want the output of the second not at the offset 0, obviously. That's *the* reason why we (every Unix out there) have a distinction between file descriptors and opened files. open() yields a new IO channel (aka opened file). It also creates a new descriptor and associates that channel with it. fork() does *not* create new opened files. It creates new descriptor table, populating it with additional references to opened files the parent had descriptors for. It's the same difference as between doing open() of the same file twice and doing open() + dup(). In fact, what you've described is a very obfuscated way to do dup(2) - SCM_RIGHTS descriptor passing will take a descriptor in sender, acquire an extra reference to opened file corresponding to it and store that reference in datagram. Recepient will allocate a new descriptor and associate it with the reference to opened file it has found in datagram. Seriously, this is as basic as it gets - understanding how redirects work and what file descriptors are really ought to be covered by any introductory course on Unix, let alone anything that touches descriptor-passing. Current IO offset is a property of opened file, not of a descriptor. What the original poster has described is clearly a new opened file instance associated with the same filesystem object. dup() or fork() will do nothing of that sort; not on Linux, not on *BSD, not on any Unix. open() on /proc//fd/ will, but it's Linux-specific. Whether it's a good idea or not, depends on the program in question, obviously. In any case, you don't need a new syscall for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 12/10, Srivatsa S. Bhat wrote: > > On 12/10/2012 12:44 AM, Oleg Nesterov wrote: > > > But yes, it is easy to blame somebody else's code ;) And I can't suggest > > something better at least right now. If I understand correctly, we can not > > use, say, synchronize_sched() in _cpu_down() path > > We can't sleep in that code.. so that's a no-go. But we can? Note that I meant _cpu_down(), not get_online_cpus_atomic() or take_cpu_down(). Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 7/9] yield_to(), cpu-hotplug: Prevent offlining of other CPUs properly
On 12/10/2012 01:18 AM, Oleg Nesterov wrote: > On 12/07, Srivatsa S. Bhat wrote: >> >> Once stop_machine() is gone from the CPU offline path, we won't be able to >> depend on local_irq_save() to prevent CPUs from going offline from under us. > > OK, I guess we need to avoid resched_task()->smp_send_reschedule() > after __cpu_disable() and before migrate_tasks(). > Yes. > But, whatever problem we have, > >> Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline, >> while invoking from atomic context. > > it should be solved, so... > >> -if (preempt && rq != p_rq) >> +if (preempt && rq != p_rq && cpu_online(task_cpu(p))) > > Why do we need this change? > > Afaics, you could add BUG_ON(!cpu_online(...)) instead? > > I am just curious. > Oh, I think that's a remnant of v1 (which needed readers to use cpu_online_stable()). You're right, we don't need it. Or we could put a BUG_ON instead, like you suggested. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New system call wanted: fdreopen
Once upon a time, Tristan Wibberley said: >A common idiom on Linux is to open a file and keep the fd open so that >the underlying file can be unlinked from its directory. But if the file >needs to be read from several different parts of the codebase then due to >the file descriptor having exactly one read pointer those different parts >must be synchronised which is a relatively difficult task. I think you can get similar behavior entirely in user space and in a fashion portable to at least BSD systems. You could fork() (which would create a separate FD in the child), pass the FD back to the parent over a socket, and then have the child exit. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 12/10/2012 12:44 AM, Oleg Nesterov wrote:
> On 12/07, Srivatsa S. Bhat wrote:
>>
>> Per-cpu counters can help solve the cache-line bouncing problem. So we
>> actually use the best of both: per-cpu counters (no-waiting) at the reader
>> side in the fast-path, and global rwlocks in the slowpath.
>>
>> [ Fastpath = no writer is active; Slowpath = a writer is active ]
>>
>> IOW, the hotplug readers just increment/decrement their per-cpu refcounts
>> when no writer is active.
>
> Plus LOCK and cli/sti. I do not pretend I really know how bad this is
> performance-wise though. And at first glance this look overcomplicated.
>
Hehe, I agree ;-) But I couldn't think of any other way to get rid of the
deadlock possibilities, other than using global rwlocks. So I designed a
way in which we can switch between per-cpu counters and global rwlocks
dynamically. Probably there is a smarter way to achieve what we want, dunno...
> But yes, it is easy to blame somebody else's code ;) And I can't suggest
> something better at least right now. If I understand correctly, we can not
> use, say, synchronize_sched() in _cpu_down() path
We can't sleep in that code.. so that's a no-go.
>, you also want to improve
> the latency. And I guess something like kick_all_cpus_sync() is "too heavy".
>
I hadn't considered that. Thinking of it, I don't think it would help us..
It won't get rid of the currently running preempt_disable() sections no?
> Also. After the quick reading this doesn't look correct, please see below.
>
>> +void get_online_cpus_atomic(void)
>> +{
>> +unsigned int cpu = smp_processor_id();
>> +unsigned long flags;
>> +
>> +preempt_disable();
>> +local_irq_save(flags);
>> +
>> +if (cpu_hotplug.active_writer == current)
>> +goto out;
>> +
>> +smp_rmb(); /* Paired with smp_wmb() in drop_writer_signal() */
>> +
>> +if (likely(!writer_active(cpu))) {
>
> WINDOW. Suppose that reader_active() == F.
>
>> +mark_reader_fastpath();
>> +goto out;
>
> Why take_cpu_down() can't do announce_cpu_offline_begin() + sync_all_readers()
> in between?
>
> Looks like we should increment the counter first, then check writer_active().
You are right, I missed the above race-conditions.
> And sync_atomic_reader() needs rmb between 2 atomic_read's.
>
OK.
>
> Or. Again, suppose that reader_active() == F. But is_new_writer() == T.
>
>> +if (is_new_writer(cpu)) {
>> +/*
>> + * ACK the writer's signal only if this is a fresh read-side
>> + * critical section, and not just an extension of a running
>> + * (nested) read-side critical section.
>> + */
>> +if (!reader_active(cpu)) {
>> +ack_writer_signal();
>
> What if take_cpu_down() does announce_cpu_offline_end() right before
> ack_writer_signal() ? In this case get_online_cpus_atomic() returns
> with writer_signal == -1. If nothing else this breaks the next
> raise_writer_signal().
>
Oh, yes, this one is wrong too! We need to mark ourselves as active
reader right in the beginning. And probably change the check to
"reader_nested()" or something like that.
Thanks a lot Oleg!
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 v3 7/9] yield_to(), cpu-hotplug: Prevent offlining of other CPUs properly
On 12/07, Srivatsa S. Bhat wrote: > > Once stop_machine() is gone from the CPU offline path, we won't be able to > depend on local_irq_save() to prevent CPUs from going offline from under us. OK, I guess we need to avoid resched_task()->smp_send_reschedule() after __cpu_disable() and before migrate_tasks(). But, whatever problem we have, > Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going offline, > while invoking from atomic context. it should be solved, so... > - if (preempt && rq != p_rq) > + if (preempt && rq != p_rq && cpu_online(task_cpu(p))) Why do we need this change? Afaics, you could add BUG_ON(!cpu_online(...)) instead? I am just curious. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v2 3/6] memcg: rework mem_cgroup_iter to use cgroup iterators
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> mem_cgroup_iter curently relies on css->id when walking down a group
> hierarchy tree. This is really awkward because the tree walk depends on
> the groups creation ordering. The only guarantee is that a parent node
> is visited before its children.
> Example
> 1) mkdir -p a a/d a/b/c
> 2) mkdir -a a/b/c a/d
> Will create the same trees but the tree walks will be different:
> 1) a, d, b, c
> 2) a, b, c, d
>
> 574bd9f7 (cgroup: implement generic child / descendant walk macros) has
> introduced generic cgroup tree walkers which provide either pre-order
> or post-order tree walk. This patch converts css->id based iteration
> to pre-order tree walk to keep the semantic with the original iterator
> where parent is always visited before its subtree.
>
> cgroup_for_each_descendant_pre suggests using post_create and
> pre_destroy for proper synchronization with groups addidition resp.
> removal. This implementation doesn't use those because a new memory
> cgroup is fully initialized in mem_cgroup_create and css reference
> counting enforces that the group is alive for both the last seen cgroup
> and the found one resp. it signals that the group is dead and it should
> be skipped.
>
> If the reclaim cookie is used we need to store the last visited group
> into the iterator so we have to be careful that it doesn't disappear in
> the mean time. Elevated reference count on the css keeps it alive even
> though the group have been removed (parked waiting for the last dput so
> that it can be freed).
>
> V2
> - use css_{get,put} for iter->last_visited rather than
> mem_cgroup_{get,put} because it is stronger wrt. cgroup life cycle
> - cgroup_next_descendant_pre expects NULL pos for the first iterartion
> otherwise it might loop endlessly for intermediate node without any
> children.
>
> Signed-off-by: Michal Hocko
> ---
> mm/memcontrol.c | 74
> ++-
> 1 file changed, 57 insertions(+), 17 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 1f5528d..6bcc97b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -144,8 +144,8 @@ struct mem_cgroup_stat_cpu {
> };
>
> struct mem_cgroup_reclaim_iter {
> - /* css_id of the last scanned hierarchy member */
> - int position;
> + /* last scanned hierarchy member with elevated css ref count */
> + struct mem_cgroup *last_visited;
> /* scan generation, increased every round-trip */
> unsigned int generation;
> /* lock to protect the position and generation */
> @@ -1066,7 +1066,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
>struct mem_cgroup_reclaim_cookie *reclaim)
> {
> struct mem_cgroup *memcg = NULL;
> - int id = 0;
> + struct mem_cgroup *last_visited = NULL;
>
> if (mem_cgroup_disabled())
> return NULL;
> @@ -1075,7 +1075,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> root = root_mem_cgroup;
>
> if (prev && !reclaim)
> - id = css_id(>css);
> + last_visited = prev;
>
> if (!root->use_hierarchy && root != root_mem_cgroup) {
> if (prev)
> @@ -1083,9 +1083,10 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> return root;
> }
>
> + rcu_read_lock();
> while (!memcg) {
> struct mem_cgroup_reclaim_iter *uninitialized_var(iter);
> - struct cgroup_subsys_state *css;
> + struct cgroup_subsys_state *css = NULL;
>
> if (reclaim) {
> int nid = zone_to_nid(reclaim->zone);
> @@ -1095,34 +1096,73 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> mz = mem_cgroup_zoneinfo(root, nid, zid);
> iter = >reclaim_iter[reclaim->priority];
> spin_lock(>iter_lock);
> + last_visited = iter->last_visited;
> if (prev && reclaim->generation != iter->generation) {
> + if (last_visited) {
> + css_put(_visited->css);
> + iter->last_visited = NULL;
> + }
> spin_unlock(>iter_lock);
> - goto out_css_put;
> + goto out_unlock;
> }
> - id = iter->position;
> }
>
> - rcu_read_lock();
> - css = css_get_next(_cgroup_subsys, id + 1, >css,
> );
> - if (css) {
> - if (css == >css || css_tryget(css))
> - memcg = mem_cgroup_from_css(css);
> - } else
> -
Hyper-V storvsc errors with large disk image
(I'm not subscribed, please CC me) Hi! When using huge (13TB) disk images (VHDX, dynamically expanding) with Hyper-V in Windows 8 Pro and running Linux as guest, I get errors and hangups when accessing the emulated HD. dmesg show the following message block looping: sd 2:0:0:0: [sda] Sense Key : No Sense [current] sd 2:0:0:0: [sda] Add. Sense: No additional sense information hv_storvsc vmbus_0_1: cmd 0x93 scsi status 0x2 srb status 0x6 I am using the System Rescue CD 3.1.2 alternative 64 bit kernel, uname -a says: 3.6.9-alt312-amd64 What I do i use parted to create a single partition and the run mkfs.ext4 /dev/sda1 on it. the mkfs.ext4 process goes into D+ state and the mentioned messages start appearing in the kernel log. Running Window 8 as guest on the same virtual machine works fine, HD access it without issues. Bug in the storsvc driver? Regards, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
On 12/09/2012 07:16 PM, Alexander Holler wrote: > Am 09.12.2012 17:40, schrieb Alexander Holler: >> Am 09.12.2012 13:55, schrieb Lars-Peter Clausen: >>> On 12/09/2012 01:21 PM, Alexander Holler wrote: This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does. Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub. It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering. >>> >>> I don't think we should register a IIO device for this. Just an RTC >>> device >>> should be fully sufficient. >>> >> >> You would have to implement all the used services hid-sensor-hub offers >> in the rtc-driver again. > > Besides that, time is part of the spec for HID sensors, which makes > sense. Making that available as a RTC to read/set the time is imho the > best to way support that. If you want a driver which doesn't use the HID > sensor hub framework (or iio), you would either have to define your own > standard or make sure it is interoperable with the HID sensor hub > framework, which might not be trivial. I agree with what you wrote above. It just doesn't make sense to register a IIO device for a RTC type device. Just rip out all the IIO related bits from the driver and it will be fine. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 12/07, Srivatsa S. Bhat wrote:
>
> Per-cpu counters can help solve the cache-line bouncing problem. So we
> actually use the best of both: per-cpu counters (no-waiting) at the reader
> side in the fast-path, and global rwlocks in the slowpath.
>
> [ Fastpath = no writer is active; Slowpath = a writer is active ]
>
> IOW, the hotplug readers just increment/decrement their per-cpu refcounts
> when no writer is active.
Plus LOCK and cli/sti. I do not pretend I really know how bad this is
performance-wise though. And at first glance this look overcomplicated.
But yes, it is easy to blame somebody else's code ;) And I can't suggest
something better at least right now. If I understand correctly, we can not
use, say, synchronize_sched() in _cpu_down() path, you also want to improve
the latency. And I guess something like kick_all_cpus_sync() is "too heavy".
Also. After the quick reading this doesn't look correct, please see below.
> +void get_online_cpus_atomic(void)
> +{
> + unsigned int cpu = smp_processor_id();
> + unsigned long flags;
> +
> + preempt_disable();
> + local_irq_save(flags);
> +
> + if (cpu_hotplug.active_writer == current)
> + goto out;
> +
> + smp_rmb(); /* Paired with smp_wmb() in drop_writer_signal() */
> +
> + if (likely(!writer_active(cpu))) {
WINDOW. Suppose that reader_active() == F.
> + mark_reader_fastpath();
> + goto out;
Why take_cpu_down() can't do announce_cpu_offline_begin() + sync_all_readers()
in between?
Looks like we should increment the counter first, then check writer_active().
And sync_atomic_reader() needs rmb between 2 atomic_read's.
Or. Again, suppose that reader_active() == F. But is_new_writer() == T.
> + if (is_new_writer(cpu)) {
> + /*
> + * ACK the writer's signal only if this is a fresh read-side
> + * critical section, and not just an extension of a running
> + * (nested) read-side critical section.
> + */
> + if (!reader_active(cpu)) {
> + ack_writer_signal();
What if take_cpu_down() does announce_cpu_offline_end() right before
ack_writer_signal() ? In this case get_online_cpus_atomic() returns
with writer_signal == -1. If nothing else this breaks the next
raise_writer_signal().
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Upstart 1.6.1 released
Oh, you need more testing with ARM Nexus 7 ? On Sun, Dec 9, 2012 at 8:28 PM, Anca Emanuel wrote: > Do will see this in Raring ? > And when ? > > On Fri, Dec 7, 2012 at 10:27 PM, James Hunt wrote: >> Summary of changes: >> >> * Improved re-exec performance. >> * Minor logger fixes for unflushed data. >> * Handle re-exec scenario when requested from within a chroot. >> * Minor serialisation data format change to handle chroots and >> user sessions. >> * Added extra re-exec tests including explicit upgrade tests reading >> from pre-prepared JSON data files. >> * Make jobs running within a chroot log their output within the chroot. >> * Added "Restart" D-Bus method. >> * Changed 'telinit u' to use "Restart" D-Bus method rather than >> sending SIGTERM to play nicely when busybox(1) is init. >> * Added "GetState" D-Bus method allowing current serialised internal state >> to be queried. >> >> Thanks to all the contributors, reviewers, testers and users! >> >> Download it from launchpad: https://launchpad.net/upstart >> >> Kind regards, >> >> James. >> -- >> James Hunt >> >> http://upstart.ubuntu.com/cookbook >> http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Upstart 1.6.1 released
Do will see this in Raring ? And when ? On Fri, Dec 7, 2012 at 10:27 PM, James Hunt wrote: > Summary of changes: > > * Improved re-exec performance. > * Minor logger fixes for unflushed data. > * Handle re-exec scenario when requested from within a chroot. > * Minor serialisation data format change to handle chroots and > user sessions. > * Added extra re-exec tests including explicit upgrade tests reading > from pre-prepared JSON data files. > * Make jobs running within a chroot log their output within the chroot. > * Added "Restart" D-Bus method. > * Changed 'telinit u' to use "Restart" D-Bus method rather than > sending SIGTERM to play nicely when busybox(1) is init. > * Added "GetState" D-Bus method allowing current serialised internal state > to be queried. > > Thanks to all the contributors, reviewers, testers and users! > > Download it from launchpad: https://launchpad.net/upstart > > Kind regards, > > James. > -- > James Hunt > > http://upstart.ubuntu.com/cookbook > http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] Allow 0ms deadline latency
On 2012-12-09 17:02, xtu4 wrote: > On 12/10/2012 12:01 AM, xtu4 wrote: >> Subject: [PATCH] Allow 0ms deadline latency, increase the read speed >> >> Signed-off-by: xiaobing tu >> --- >> block/deadline-iosched.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c >> index c644137..e502d6b 100644 >> --- a/block/deadline-iosched.c >> +++ b/block/deadline-iosched.c >> @@ -230,7 +230,7 @@ static inline int deadline_check_fifo(struct >> deadline_data *dd, int ddir) >>/* >> * rq is expired! >> */ >> - if (time_after(jiffies, rq_fifo_time(rq))) >> + if (time_after_eq(jiffies, rq_fifo_time(rq))) >>return 1; >> >> return 0; Looks fine, it allows FIFO behaviour for deadline as well. I have applied it. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
Am 09.12.2012 17:40, schrieb Alexander Holler: Am 09.12.2012 13:55, schrieb Lars-Peter Clausen: On 12/09/2012 01:21 PM, Alexander Holler wrote: This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does. Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub. It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering. I don't think we should register a IIO device for this. Just an RTC device should be fully sufficient. You would have to implement all the used services hid-sensor-hub offers in the rtc-driver again. Besides that, time is part of the spec for HID sensors, which makes sense. Making that available as a RTC to read/set the time is imho the best to way support that. If you want a driver which doesn't use the HID sensor hub framework (or iio), you would either have to define your own standard or make sure it is interoperable with the HID sensor hub framework, which might not be trivial. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] improve read ahead in kernel
On 12/09/12 07:57, xtu4 wrote:
>
> Subject: [PATCH] when system in low memory scenario, imaging there is a mp3
> play, or video play, we need to read mp3 or video file
> from memory to page cache,but when system lack of memory,
> page cache of mp3 or video file will be reclaimed.once read
> in memory, then reclaimed, it will cause audio or video
> glitch,and it will increase the io operation at the same
> time.
>
> Signed-off-by: xiaobing tu
What tree does this patch apply to?
It looks like most (or all) of the tabs in the source files have
been changed to spaces, which is Not Good.
Maybe some info in Documentation/email-clients.txt could help you.
> ---
> include/linux/mm_types.h |4
> mm/Kconfig |6 ++
> mm/filemap.c |4
> mm/readahead.c | 20 +---
> mm/vmscan.c | 10 --
> 5 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 5b42f1b..541864d 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -149,6 +149,10 @@ struct page {
> */
> void *shadow;
> #endif
> +#ifdef CONFIG_LOWMEMORY_READAHEAD
> +unsigned int ioprio;
> +#endif
> +
> }
> /*
> * If another subsystem starts using the double word pairing for atomic
> diff --git a/mm/Kconfig b/mm/Kconfig
> index e338407..dade8d3 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -140,6 +140,12 @@ config ARCH_DISCARD_MEMBLOCK
> config NO_BOOTMEM
> boolean
>
> +# improve readahead in low memory scenario
> +config LOWMEMORY_READAHEAD
> +bool "improve readahead in low memory scenario"
> +depends on (IA64 || X86)
Why this depends on?
I don't see anything that is arch-specific in the patch.
> +
> +
> # eventually, we can have this option just 'select SPARSEMEM'
> config MEMORY_HOTPLUG
> bool "Allow for memory hot-add"
> diff --git a/mm/filemap.c b/mm/filemap.c
> index a0701e6..e32efed8 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -129,6 +129,10 @@ void __delete_from_page_cache(struct page *page)
> page->mapping = NULL;
> /* Leave page->index set: truncation lookup relies upon it */
> mapping->nrpages--;
> +#ifdef CONFIG_LOWMEMORY_READAHEAD
> +page->ioprio = 0;
> +#endif
> +
> __dec_zone_page_state(page, NR_FILE_PAGES);
> if (PageSwapBacked(page))
> __dec_zone_page_state(page, NR_SHMEM);
> diff --git a/mm/readahead.c b/mm/readahead.c
> index cbcbb02..dd07cfe 100644
> --- a/mm/readahead.c
> +++ b/mm/readahead.c
> @@ -159,6 +159,11 @@ __do_page_cache_readahead(struct address_space *mapping,
> struct file *filp,
> int page_idx;
> int ret = 0;
> loff_t isize = i_size_read(inode);
> +#ifdef CONFIG_LOWMEMORY_READAHEAD
> +int class = 0;
> +if (p->io_context)
> +class = IOPRIO_PRIO_CLASS(p->io_context->ioprio);
> +#endif
>
> if (isize == 0)
> goto out;
> @@ -177,12 +182,21 @@ __do_page_cache_readahead(struct address_space
> *mapping, struct file *filp,
> rcu_read_lock();
> page = radix_tree_lookup(>page_tree, page_offset);
> rcu_read_unlock();
> -if (page)
> -continue;
> -
> +if (page){
> +#ifdef CONFIG_LOWMEMORY_READAHEAD
> +if (class == IOPRIO_CLASS_RT) {
> +page->ioprio = 1;
> +#endif
> +continue;
> +}
> page = page_cache_alloc_readahead(mapping);
> if (!page)
> break;
> +#ifdef CONFIG_LOWMEMORY_READAHEAD
> +if (class == IOPRIO_CLASS_RT) {
> +page->ioprio = 1;
> +#endif
> +
> page->index = page_offset;
> list_add(>lru, _pool);
> if (page_idx == nr_to_read - lookahead_size)
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 753a2dc..86e03aa 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -728,8 +728,14 @@ static enum page_references page_check_references(struct
> page *page,
> }
>
> /* Reclaim if clean, defer dirty pages to writeback */
> -if (referenced_page && !PageSwapBacked(page))
> -return PAGEREF_RECLAIM_CLEAN;
> +if (referenced_page && !PageSwapBacked(page)) {
> +#ifdef CONFIG_LOWMEMORY_READAHEAD
> +if (page->ioprio == 1) {
> +return PAGEREF_ACTIVATE;
> +} else
> +#endif
> +return PAGEREF_RECLAIM_CLEAN;
> +}
>
> return PAGEREF_RECLAIM;
> }
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] UAPI: Disintegrate arch/x86/include/asm
Ingo Molnar wrote: > arch/x86/include/asm/Kbuild | 7 ++ > arch/x86/include/asm/perf_regs.h | 33 - > arch/x86/include/asm/svm.h| 132 > +- > arch/x86/include/asm/vmx.h| 89 +-- > arch/x86/include/uapi/asm/Kbuild | 3 + > arch/x86/include/uapi/asm/perf_regs.h | 33 + > arch/x86/include/uapi/asm/svm.h | 132 > ++ > arch/x86/include/uapi/asm/vmx.h | 109 > 8 files changed, 289 insertions(+), 249 deletions(-) > > What are these changes - it seems perf and KVM related. Only in passing. The header files you indicated are marked as being exported to userspace in Kbuild - therefore they get disintegrated around __KERNEL__ conditionals just like all the other UAPI-relevant headers. > Is the latest version above 100% bug-free, with no known > problems whatsoever? It builds perf for me. No idea if perf works, I've never used it. I waved a branch including the patch on top of all my perf patches towards Arnaldo and others, but I don't know if they've tried it. I've also checked that x86_64 allyesconfig and i386 allmodconfig build and that an x86_64 kernel built with my test machine's usual config builds and boots. So, no known problems. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] scripts/tags.sh: Support compiled source
On Tue, Dec 04, 2012 at 03:04:33AM +0900, Joonsoo Kim wrote: > We usually have interst in compiled files only, > because they are strongly related to individual's work. > Current tags.sh can't select compiled files, so support it. > > We can use this functionality like below. > "make cscope O=. SRCARCH= COMPILED_SOURCE=compiled" > > It must be executed after building the kernel. > > Signed-off-by: Joonsoo Kim > --- > v2: change bash specific '[[]]' to 'case in' statement. > use COMPILED_SOURCE env var, instead of abusing SUBARCH Looks much better, I have only one minor nitpick: > + if [ "$COMPILED_SOURCE" = "compiled" ]; then > + all_compiled_sources Please change it to -n "$COMPILED_SOURCE", so that COMPILED_SOURCE=1 works as well. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] scripts/coccinelle/misc/semicolon.cocci: Add unneeded semicolon test
On Sat, Dec 8, 2012 at 4:39 PM, Joe Perches wrote:
> On Sat, 2012-12-08 at 16:13 -0200, Peter Senna Tschudin wrote:
>> On Sat, Dec 8, 2012 at 3:45 PM, Joe Perches wrote:
>> > On Sat, 2012-12-08 at 15:34 -0200, Peter Senna Tschudin wrote:
>> >> This semantic patch looks for semicolons that can be removed without
>> >> changing the semantics of the code. The confidence is moderate
>> >> because there are some false positives on cases like:
>> >>
>> >> b/drivers/mmc/host/cb710-mmc.c:589
>> >> break;
>> >> case MMC_POWER_UP:
>> >> default:
>> >> - /* ignore */;
>> >> }
>> > []
>> >> diff --git a/scripts/coccinelle/misc/semicolon.cocci
>> >> b/scripts/coccinelle/misc/semicolon.cocci
>> > []
>> >> +@r1@
>> >> +statement S;
>> >> +position p1;
>> >> +position p != {r_default.p, r_case.p};
>> >> +identifier label;
>> >> +@@
>> >> +(
>> >> +label:;
>> >> +|
>> >> +S@p1;@p
>> >> +)
>> >> +
>> >
>> > I believe this also fails on this case:
> []
>> > where gcc needs a semicolon after a label before a function exit.
>>
>> No it does not fail. This issue is switch/case specific. See how I've tested:
>
> Thanks Peter, I didn't notice the switch requirement.
>
> In this case, I'd suggest replacement of the
> nominally false positive ; with break;
I agree with you that the best is to replace ; with break; but I
prefer to not change the unneeded semicolon test semantic patch to add
breaks before ;. I can make other semantic patch for that. The point
is that adding break is more than detecting unneeded semicolons, so I
prefer to not mix the two.
But even with the moderate confidence this semantic patch seems to be
useful as new unneeded semicolons are being added to the Kernel.
>
> cheers, Joe
>
Thanks for your help!
Peter
--
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/2] scripts/tags.sh: Support subarch for ARM
On Tue, Dec 04, 2012 at 03:04:32AM +0900, Joonsoo Kim wrote:
> +elif [ "${SRCARCH}" = "arm" -a "${SUBARCH}" != "" ]; then
> + subarchdir=$(find ${tree}arch/$SRCARCH/ -name mach-* -type d -o \
> + -name plat-* -type d);
Please quote the patterns, otherwise the shell will expand them if you
have a file named mach-* or plat-* in the top-level directory.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] merge_config.sh: Add option to specify output dir
On Mon, Dec 03, 2012 at 09:05:26AM -0800, John Stultz wrote: > On 12/02/2012 11:36 PM, Zhangfei Gao wrote: >> Provide a -O option to specify dir to put generated .config >> Then merge_config.sh does not need to be copied to target dir, >> for easy re-usage in other script >> >> Signed-off-by: Zhangfei Gao >> Tested-by: Jon Medhurst (Tixy) > Acked-by: John Stultz Applied to kbuild.git#kconfig, thanks. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] drivers/video/vt8500lcdfb.c: use devm_ functions
From: Julia Lawall
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
The patch makes some other cleanups. First, the original code used
devm_kzalloc, but kfree. This would lead to a double free. The problem
was found using the following semantic match (http://coccinelle.lip6.fr/):
//
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x,...);
//
The error-handing code of devm_request_and_ioremap does not print any
warning message, because devm_request_and_ioremap does this.
The first call to dma_alloc_coherent is converted to its devm equivalent,
dmam_alloc_coherent. This implicitly introduces a call to
dmam_free_coherent, which was completly missing in the original code.
A semicolon is removed at the end of the error-handling code for the first
call to dma_alloc_coherent.
The block of code calling fb_alloc_cmap is moved below the block of code
calling vt8500lcd_set_par, so that the error-handing code of the call to
vt8500lcd_set_par can just return ret. This way there is only one block of
error-handling code that needs to call fb_dealloc_cmap, and so this is
moved up to the place where it is needed, eliminating the need for all
gotos and labels in the function. This was suggested by Tony Prisk.
The initializations of fbi and ret at the beginning of the function are not
necessary and are removed. The call platform_set_drvdata(pdev, NULL); at
the end of the function is also removed.
Signed-off-by: Julia Lawall
---
Only compiled. Not tested.
drivers/video/vt8500lcdfb.c | 107 +++-
1 file changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 9af8da7..fae2456 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -287,15 +287,11 @@ static int __devinit vt8500lcd_probe(struct
platform_device *pdev)
unsigned long fb_mem_len;
void *fb_mem_virt;
- ret = -ENOMEM;
- fbi = NULL;
-
fbi = devm_kzalloc(>dev, sizeof(struct vt8500lcd_info)
- + sizeof(u32) * 16, GFP_KERNEL);
+ + sizeof(u32) * 16, GFP_KERNEL);
if (!fbi) {
dev_err(>dev, "Failed to initialize framebuffer
device\n");
- ret = -ENOMEM;
- goto failed;
+ return -ENOMEM;
}
strcpy(fbi->fb.fix.id, "VT8500 LCD");
@@ -326,31 +322,15 @@ static int __devinit vt8500lcd_probe(struct
platform_device *pdev)
fbi->fb.pseudo_palette = addr;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(>dev, "no I/O memory resource defined\n");
- ret = -ENODEV;
- goto failed_fbi;
- }
- res = request_mem_region(res->start, resource_size(res), "vt8500lcd");
- if (res == NULL) {
- dev_err(>dev, "failed to request I/O memory\n");
- ret = -EBUSY;
- goto failed_fbi;
- }
-
- fbi->regbase = ioremap(res->start, resource_size(res));
- if (fbi->regbase == NULL) {
- dev_err(>dev, "failed to map I/O memory\n");
- ret = -EBUSY;
- goto failed_free_res;
- }
+ fbi->regbase = devm_request_and_ioremap(>dev, res);
+ if (fbi->regbase == NULL)
+ return -EBUSY;
np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
if (!np) {
pr_err("%s: No display description in Device Tree\n", __func__);
- ret = -EINVAL;
- goto failed_free_res;
+ return -EINVAL;
}
/*
@@ -369,54 +349,44 @@ static int __devinit vt8500lcd_probe(struct
platform_device *pdev)
ret |= of_property_read_u32(np, "bpp", );
if (ret) {
pr_err("%s: Unable to read display properties\n", __func__);
- goto failed_free_res;
+ return ret;
}
of_mode.vmode = FB_VMODE_NONINTERLACED;
/* try allocating the framebuffer */
fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
- fb_mem_virt = dma_alloc_coherent(>dev, fb_mem_len, _mem_phys,
+ fb_mem_virt = dmam_alloc_coherent(>dev, fb_mem_len, _mem_phys,
GFP_KERNEL);
if (!fb_mem_virt) {
pr_err("%s: Failed to allocate framebuffer\n", __func__);
return -ENOMEM;
- };
+ }
fbi->fb.fix.smem_start = fb_mem_phys;
fbi->fb.fix.smem_len= fb_mem_len;
fbi->fb.screen_base = fb_mem_virt;
fbi->palette_size = PAGE_ALIGN(512);
- fbi->palette_cpu= dma_alloc_coherent(>dev,
+ fbi->palette_cpu=
Re: New system call wanted: fdreopen
On Sun, 09 Dec 2012 11:27:46 -0500, Theodore Ts'o wrote: > On Sun, Dec 09, 2012 at 03:03:30PM +, Tristan Wibberley wrote: >> >> - /proc/self/fd/* does not solve this problem because the file might no ... > Actually, /proc/self/fd/* _will_ work. When you do a ls -l, it looks > like a symlink, but the files in /proc/self/fd (and /proc//fd more > generally) are magic. If you open files in /proc//fd/*, it will do > what you want. Oh! Cool! By reading how to solve this class of problem with google search results I couldn't find any indication that /proc/pid/fd/* worked differently than a symlink. Thanks for your quick reply. -- Tristan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG -next] cpufreq: cpufreq_governor.
On 05.12.2012 22:53, Ilya Zykov wrote: > What do I do wrong? > > After: modprobe cpufreq_ondemand > I have: > > WARNING: Error inserting freq_table > (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko): > Unknown symbol in module, or unknown parameter (see dmesg) > FATAL: Error inserting cpufreq_ondemand > (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/cpufreq_ondemand.ko): > Unknown symbol in module, or unknown parameter (see dmesg) > > dmesg: > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > __cpufreq_driver_getavg (err 0) > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > sysfs_create_group (err 0) > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > sysfs_remove_group (err 0) > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > __cpufreq_driver_target (err 0) > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > get_cpu_idle_time_us (err 0) > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > delayed_work_timer_fn (err 0) > Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol > get_cpu_iowait_time_us (err 0) > > cat /proc/kallsyms |grep freq_dr > 814976e0 T __cpufreq_driver_target > 814987e0 T __cpufreq_driver_getavg > 81498850 T cpufreq_driver_target > 81881650 r __ksymtab___cpufreq_driver_getavg > 81881660 r __ksymtab___cpufreq_driver_target > 81883b40 r __ksymtab_cpufreq_driver_target > 81894290 r __kcrctab___cpufreq_driver_getavg > 81894298 r __kcrctab___cpufreq_driver_target > 81895508 r __kcrctab_cpufreq_driver_target > 818b3080 r __kstrtab___cpufreq_driver_getavg > 818b3098 r __kstrtab_cpufreq_driver_target > 818b30ae r __kstrtab___cpufreq_driver_target > 81e240c8 b cpufreq_driver_lock > 81e240d0 b cpufreq_driver > a0c42000 d acpi_cpufreq_driver[acpi_cpufreq] I managed to fix: git checkout 16642a2e7be23bb -- drivers/cpufreq git checkout 250f6715a4112d668 -- include/linux/cpufreq.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] drivers/video/wm8505fb.c: use devm_ functions
From: Julia Lawall
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
The patch makes some other cleanups. First, the original code used
devm_kzalloc, but kfree. This would lead to a double free. The problem
was found using the following semantic match (http://coccinelle.lip6.fr/):
//
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x,...);
//
The error-handing code of devm_request_and_ioremap does not print any
warning message, because devm_request_and_ioremap does this.
The call to dma_alloc_coherent is converted to its devm equivalent,
dmam_alloc_coherent. This implicitly introduces a call to
dmam_free_coherent, which was completly missing in the original code.
A semicolon is removed at the end of the error-handling code for the call
to dma_alloc_coherent.
The block of code calling fb_alloc_cmap is moved below the block of code
calling wm8505fb_set_par, so that the error-handing code of the call to
wm8505fb_set_par can just return ret. This way there is only one block of
error-handling code that needs to call fb_dealloc_cmap, and so this is
moved up to the place where it is needed, eliminating the need for all
gotos and labels in the function. This was suggested by Tony Prisk.
The initializations of fbi and ret at the beginning of the function are not
necessary and are removed. The call platform_set_drvdata(pdev, NULL); at
the end of the function is also removed.
Signed-off-by: Julia Lawall
---
Only compiled. Not tested.
drivers/video/wm8505fb.c | 78 +++
1 file changed, 19 insertions(+), 59 deletions(-)
diff --git a/drivers/video/wm8505fb.c b/drivers/video/wm8505fb.c
index 77539c1..1c3ce2c 100644
--- a/drivers/video/wm8505fb.c
+++ b/drivers/video/wm8505fb.c
@@ -274,15 +274,11 @@ static int __devinit wm8505fb_probe(struct
platform_device *pdev)
unsigned long fb_mem_len;
void *fb_mem_virt;
- ret = -ENOMEM;
- fbi = NULL;
-
fbi = devm_kzalloc(>dev, sizeof(struct wm8505fb_info) +
sizeof(u32) * 16, GFP_KERNEL);
if (!fbi) {
dev_err(>dev, "Failed to initialize framebuffer
device\n");
- ret = -ENOMEM;
- goto failed;
+ return -ENOMEM;
}
strcpy(fbi->fb.fix.id, DRIVER_NAME);
@@ -308,31 +304,15 @@ static int __devinit wm8505fb_probe(struct
platform_device *pdev)
fbi->fb.pseudo_palette = addr;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(>dev, "no I/O memory resource defined\n");
- ret = -ENODEV;
- goto failed_fbi;
- }
-
- res = request_mem_region(res->start, resource_size(res), DRIVER_NAME);
- if (res == NULL) {
- dev_err(>dev, "failed to request I/O memory\n");
- ret = -EBUSY;
- goto failed_fbi;
- }
- fbi->regbase = ioremap(res->start, resource_size(res));
- if (fbi->regbase == NULL) {
- dev_err(>dev, "failed to map I/O memory\n");
- ret = -EBUSY;
- goto failed_free_res;
- }
+ fbi->regbase = devm_request_and_ioremap(>dev, res);
+ if (fbi->regbase == NULL)
+ return -EBUSY;
np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
if (!np) {
pr_err("%s: No display description in Device Tree\n", __func__);
- ret = -EINVAL;
- goto failed_free_res;
+ return -EINVAL;
}
/*
@@ -351,7 +331,7 @@ static int __devinit wm8505fb_probe(struct platform_device
*pdev)
ret |= of_property_read_u32(np, "bpp", );
if (ret) {
pr_err("%s: Unable to read display properties\n", __func__);
- goto failed_free_res;
+ return ret;
}
of_mode.vmode = FB_VMODE_NONINTERLACED;
@@ -365,12 +345,12 @@ static int __devinit wm8505fb_probe(struct
platform_device *pdev)
/* try allocating the framebuffer */
fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
- fb_mem_virt = dma_alloc_coherent(>dev, fb_mem_len, _mem_phys,
+ fb_mem_virt = dmam_alloc_coherent(>dev, fb_mem_len, _mem_phys,
GFP_KERNEL);
if (!fb_mem_virt) {
pr_err("%s: Failed to allocate framebuffer\n", __func__);
return -ENOMEM;
- };
+ }
fbi->fb.var.xres_virtual= of_mode.xres;
fbi->fb.var.yres_virtual= of_mode.yres * 2;
@@ -381,28 +361,29 @@ static int __devinit wm8505fb_probe(struct
platform_device *pdev)
fbi->fb.screen_base = fb_mem_virt;
fbi->fb.screen_size =
Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
On Sun, Dec 09, 2012 at 11:03:19AM +, Alan Cox wrote: > On Sun, 09 Dec 2012 01:58:19 -0800 > anish kumar wrote: > > > On Fri, 2012-12-07 at 16:49 +, Alan Cox wrote: > > > > I could imagine declaring the activity request buttons to be "input", > > > > but for > > > > presence detects it is a bit far fetched and would add too much > > > > complexity. > > > > > > Android tries to address this with its switch class driver, but I'm not > > > sure its actually got anything over making them input devices. > > > > Sorry for not understanding the context here.How the debounce sysfs > > added by Guenter has anything to do with switch driver in android? > > The other more general option is to make the input layer do the debounce > and make them all inputs rather than just relying on any gpio layer > support. > The gpio pins I am dealing with are provided by an FPGA which is used on various boards. While the gpio access registers are always the same, the actual usage is board specific. This means I either need to write ugly code, or use the gpio subsystem to provide access to the gpio pins. Ugly code is out of the question, which means I'll need gpio support. Anyway, I want to keep things simple, not add unnecessary complexity. Having to go through the input subsystem just to be able to support debounce on a couple of input pins doesn't really sound simple. Guess I'll have to find another solution if the patch is not accepted. Maybe I'll add a "debounce" property to the gpio driver's of properties. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau driver fails to build
On 23.11.2012 18:49, Paul Bolle wrote: > The puzzling part > is that ACPI_VIDEO will only be selected (ie, made into a 'y') if all > dependencies of that select statement are 'y' too. (Note that these > dependencies are identical to the dependencies of ACPI_VIDEO's config > entry. That can be no coincidence.) Well, you basically answered your question. If ACPI_VIDEO depends on anything that is 'm', then it cannot be set to 'y'. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 4/6] memcg: simplify mem_cgroup_iter
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> Current implementation of mem_cgroup_iter has to consider both css and
> memcg to find out whether no group has been found (css==NULL - aka the
> loop is completed) and that no memcg is associated with the found node
> (!memcg - aka css_tryget failed because the group is no longer alive).
> This leads to awkward tweaks like tests for css && !memcg to skip the
> current node.
>
> It will be much easier if we got rid off css variable altogether and
> only rely on memcg. In order to do that the iteration part has to skip
> dead nodes. This sounds natural to me and as a nice side effect we will
> get a simple invariant that memcg is always alive when non-NULL and all
> nodes have been visited otherwise.
>
> We could get rid of the surrounding while loop but keep it in for now to
> make review easier. It will go away in the following patch.
>
> Signed-off-by: Michal Hocko
> ---
> mm/memcontrol.c | 56
> +++
> 1 file changed, 27 insertions(+), 29 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 6bcc97b..d1bc0e8 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1086,7 +1086,6 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> rcu_read_lock();
> while (!memcg) {
> struct mem_cgroup_reclaim_iter *uninitialized_var(iter);
> - struct cgroup_subsys_state *css = NULL;
>
> if (reclaim) {
> int nid = zone_to_nid(reclaim->zone);
> @@ -1112,53 +,52 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> * explicit visit.
> */
> if (!last_visited) {
> - css = >css;
> + memcg = root;
> } else {
> struct cgroup *prev_cgroup, *next_cgroup;
>
> prev_cgroup = (last_visited == root) ? NULL
> : last_visited->css.cgroup;
> - next_cgroup = cgroup_next_descendant_pre(prev_cgroup,
> - root->css.cgroup);
> - if (next_cgroup)
> - css = cgroup_subsys_state(next_cgroup,
> - mem_cgroup_subsys_id);
> - }
> +skip_node:
> + next_cgroup = cgroup_next_descendant_pre(
> + prev_cgroup, root->css.cgroup);
>
> - /*
> -* Even if we found a group we have to make sure it is alive.
> -* css && !memcg means that the groups should be skipped and
> -* we should continue the tree walk.
> -* last_visited css is safe to use because it is protected by
> -* css_get and the tree walk is rcu safe.
> -*/
> - if (css == >css || (css && css_tryget(css)))
> - memcg = mem_cgroup_from_css(css);
> + /*
> +* Even if we found a group we have to make sure it is
> +* alive. css && !memcg means that the groups should
> be
> +* skipped and we should continue the tree walk.
> +* last_visited css is safe to use because it is
> +* protected by css_get and the tree walk is rcu safe.
> +*/
> + if (next_cgroup) {
> + struct mem_cgroup *mem = mem_cgroup_from_cont(
> + next_cgroup);
> + if (css_tryget(>css))
> + memcg = mem;
> + else {
> + prev_cgroup = next_cgroup;
I might be missing something here, but the comment says the
last_visited is safe to use but not the next_cgroup. What is
preventing it to be
removed ?
--Ying
> + goto skip_node;
> + }
> + }
> + }
>
> if (reclaim) {
> - struct mem_cgroup *curr = memcg;
> -
> if (last_visited)
> css_put(_visited->css);
>
> - if (css && !memcg)
> - curr = mem_cgroup_from_css(css);
> -
> /* make sure that the cached memcg is not removed */
> - if (curr)
> - css_get(>css);
> - iter->last_visited = curr;
> + if (memcg)
> + css_get(>css);
> + iter->last_visited = memcg;
>
> - if (!css)
> +
Re: [patch v2 3/6] memcg: rework mem_cgroup_iter to use cgroup iterators
On Mon, Nov 26, 2012 at 10:47 AM, Michal Hocko wrote:
> mem_cgroup_iter curently relies on css->id when walking down a group
> hierarchy tree. This is really awkward because the tree walk depends on
> the groups creation ordering. The only guarantee is that a parent node
> is visited before its children.
> Example
> 1) mkdir -p a a/d a/b/c
> 2) mkdir -a a/b/c a/d
> Will create the same trees but the tree walks will be different:
> 1) a, d, b, c
> 2) a, b, c, d
>
> 574bd9f7 (cgroup: implement generic child / descendant walk macros) has
> introduced generic cgroup tree walkers which provide either pre-order
> or post-order tree walk. This patch converts css->id based iteration
> to pre-order tree walk to keep the semantic with the original iterator
> where parent is always visited before its subtree.
>
> cgroup_for_each_descendant_pre suggests using post_create and
> pre_destroy for proper synchronization with groups addidition resp.
> removal. This implementation doesn't use those because a new memory
> cgroup is fully initialized in mem_cgroup_create and css reference
> counting enforces that the group is alive for both the last seen cgroup
> and the found one resp. it signals that the group is dead and it should
> be skipped.
>
> If the reclaim cookie is used we need to store the last visited group
> into the iterator so we have to be careful that it doesn't disappear in
> the mean time. Elevated reference count on the css keeps it alive even
> though the group have been removed (parked waiting for the last dput so
> that it can be freed).
>
> V2
> - use css_{get,put} for iter->last_visited rather than
> mem_cgroup_{get,put} because it is stronger wrt. cgroup life cycle
> - cgroup_next_descendant_pre expects NULL pos for the first iterartion
> otherwise it might loop endlessly for intermediate node without any
> children.
>
> Signed-off-by: Michal Hocko
> ---
> mm/memcontrol.c | 74
> ++-
> 1 file changed, 57 insertions(+), 17 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 1f5528d..6bcc97b 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -144,8 +144,8 @@ struct mem_cgroup_stat_cpu {
> };
>
> struct mem_cgroup_reclaim_iter {
> - /* css_id of the last scanned hierarchy member */
> - int position;
> + /* last scanned hierarchy member with elevated css ref count */
> + struct mem_cgroup *last_visited;
> /* scan generation, increased every round-trip */
> unsigned int generation;
> /* lock to protect the position and generation */
> @@ -1066,7 +1066,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
>struct mem_cgroup_reclaim_cookie *reclaim)
> {
> struct mem_cgroup *memcg = NULL;
> - int id = 0;
> + struct mem_cgroup *last_visited = NULL;
>
> if (mem_cgroup_disabled())
> return NULL;
> @@ -1075,7 +1075,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> root = root_mem_cgroup;
>
> if (prev && !reclaim)
> - id = css_id(>css);
> + last_visited = prev;
>
> if (!root->use_hierarchy && root != root_mem_cgroup) {
> if (prev)
> @@ -1083,9 +1083,10 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> return root;
> }
>
> + rcu_read_lock();
> while (!memcg) {
> struct mem_cgroup_reclaim_iter *uninitialized_var(iter);
> - struct cgroup_subsys_state *css;
> + struct cgroup_subsys_state *css = NULL;
>
> if (reclaim) {
> int nid = zone_to_nid(reclaim->zone);
> @@ -1095,34 +1096,73 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
> mz = mem_cgroup_zoneinfo(root, nid, zid);
> iter = >reclaim_iter[reclaim->priority];
> spin_lock(>iter_lock);
> + last_visited = iter->last_visited;
> if (prev && reclaim->generation != iter->generation) {
> + if (last_visited) {
> + css_put(_visited->css);
> + iter->last_visited = NULL;
> + }
> spin_unlock(>iter_lock);
> - goto out_css_put;
> + goto out_unlock;
> }
> - id = iter->position;
> }
>
> - rcu_read_lock();
> - css = css_get_next(_cgroup_subsys, id + 1, >css,
> );
> - if (css) {
> - if (css == >css || css_tryget(css))
> - memcg = mem_cgroup_from_css(css);
> - } else
> -
Re: [PATCH 1/5] kbuild: remove deprecated use of defined in timeconst.pl
On 18.11.2012 21:05, pefol...@verizon.net wrote: > From: Peter Foley > > Fix this warning by removing a unneeded use of defined An identical fix for this is in the -mm tree already. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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/5] kbuild: silence rule for extra_certificates
Added David and Rusty. On Sun, Nov 18, 2012 at 03:05:14PM -0500, pefol...@verizon.net wrote: > From: Peter Foley > > Silence the touch extra_certificates command > > Signed-off-by: Peter Foley I think we should tell the user that the default empty extra certificates list is being used, in case the user used a wrong filename or similar. How about this? Subject: MODSIGN: Fix kbuild output when using default extra_certificates Signed-off-by: Michal Marek diff --git a/kernel/Makefile b/kernel/Makefile index 0dfeca4..8c708e4 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -136,8 +136,12 @@ ifeq ($(CONFIG_MODULE_SIG),y) # # Pull the signing certificate and any extra certificates into the kernel # + +quiet_cmd_touch = TOUCH $@ + cmd_touch = touch $@ + extra_certificates: - touch $@ + $(call cmd,touch) kernel/modsign_pubkey.o: signing_key.x509 extra_certificates But I don't insist on the above, feel free to hide the command completely. Michal > --- > kernel/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/Makefile b/kernel/Makefile > index 86e3285..18a0b61 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -137,7 +137,7 @@ ifeq ($(CONFIG_MODULE_SIG),y) > # Pull the signing certificate and any extra certificates into the kernel > # > extra_certificates: > - touch $@ > + @touch $@ > > kernel/modsign_pubkey.o: signing_key.x509 extra_certificates > > -- > 1.8.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
Am 09.12.2012 13:55, schrieb Lars-Peter Clausen: On 12/09/2012 01:21 PM, Alexander Holler wrote: This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does. Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub. It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering. I don't think we should register a IIO device for this. Just an RTC device should be fully sufficient. You would have to implement all the used services hid-sensor-hub offers in the rtc-driver again. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] x86: add dummy rules to avoid 'nothing to be done' messages
Added x...@kernel.org Michal On 18.11.2012 21:05, pefol...@verizon.net wrote: > From: Peter Foley > > Add do-nothing rules to archheaders and archscripts targets to avoid > 'nothing to be done' messages. > > Signed-off-by: Peter Foley > --- > arch/x86/syscalls/Makefile | 1 + > arch/x86/tools/Makefile| 1 + > 2 files changed, 2 insertions(+) > > diff --git a/arch/x86/syscalls/Makefile b/arch/x86/syscalls/Makefile > index f325af2..b6c923a 100644 > --- a/arch/x86/syscalls/Makefile > +++ b/arch/x86/syscalls/Makefile > @@ -56,3 +56,4 @@ targets += $(uapisyshdr-y) $(syshdr-y) > > all: $(addprefix $(uapi)/,$(uapisyshdr-y)) > all: $(addprefix $(out)/,$(syshdr-y)) > + @: > diff --git a/arch/x86/tools/Makefile b/arch/x86/tools/Makefile > index bae601f..dce567c 100644 > --- a/arch/x86/tools/Makefile > +++ b/arch/x86/tools/Makefile > @@ -40,3 +40,4 @@ $(obj)/insn_sanity.o: $(srctree)/arch/x86/lib/insn.c > $(srctree)/arch/x86/lib/ina > HOST_EXTRACFLAGS += -I$(srctree)/tools/include > hostprogs-y += relocs > relocs: $(obj)/relocs > + @: > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] silence 'arch/x86/realmode/rm/realmode.bin' is up to date message
x...@kernel.org added. On 18.11.2012 21:05, pefol...@verizon.net wrote: > From: Peter Foley > > Since realmode.bin is in $(always) the recursive make from the realmode > directory does not need to specify a specific target. ... and the rm/ subdirectory is unconditionally visited by the Makefile already. > Remove the realmode.bin target to eliminate the 'up to date' > message. > > Signed-off-by: Peter Foley Acked-by: Michal Marek Michal > --- > arch/x86/realmode/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/realmode/Makefile b/arch/x86/realmode/Makefile > index 94f7fbe..08fe883 100644 > --- a/arch/x86/realmode/Makefile > +++ b/arch/x86/realmode/Makefile > @@ -15,4 +15,4 @@ obj-y += rmpiggy.o > $(obj)/rmpiggy.o: $(obj)/rm/realmode.bin > > $(obj)/rm/realmode.bin: FORCE > - $(Q)$(MAKE) $(build)=$(obj)/rm $@ > + $(Q)$(MAKE) $(build)=$(obj)/rm > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] add eboot.o and efi_stub_$(BITS).o to $(targets)
Added x...@kernel.org. On 18.11.2012 21:05, pefol...@verizon.net wrote: > From: Peter Foley > > eboot.o and efi_stub_$(BITS).o are not in $(targets) so they are rebuilt > every time make is invoked. Add them to $(targets) to prevent unnecessary > rebuilding of bzImage. > > Signed-off-by: Peter Foley Acked-by: Michal Marek BTW, it might be a good idea to split the $(targets) assignment into multiple lines. Michal > --- > arch/x86/boot/compressed/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/boot/compressed/Makefile > b/arch/x86/boot/compressed/Makefile > index 8a84501..9d7a898 100644 > --- a/arch/x86/boot/compressed/Makefile > +++ b/arch/x86/boot/compressed/Makefile > @@ -4,7 +4,7 @@ > # create a compressed vmlinux image from the original vmlinux > # > > -targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 > vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo head_$(BITS).o misc.o > string.o cmdline.o early_serial_console.o piggy.o > +targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 > vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo head_$(BITS).o misc.o > string.o cmdline.o early_serial_console.o piggy.o eboot.o efi_stub_$(BITS).o > > KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2 > KBUILD_CFLAGS += -fno-strict-aliasing -fPIC > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New system call wanted: fdreopen
On Sun, Dec 09, 2012 at 03:03:30PM +, Tristan Wibberley wrote: > > - /proc/self/fd/* does not solve this problem because the file might no > longer be available at the same place in the filesystem. In some > otherwise simple message passing or ReSTful IPC a different file will > be available at that path. Actually, /proc/self/fd/* _will_ work. When you do a ls -l, it looks like a symlink, but the files in /proc/self/fd (and /proc//fd more generally) are magic. If you open files in /proc//fd/*, it will do what you want. See for yourself: % cat > /tmp/foo.test foo bar ^Z % jobs -l # (and note the pid, hereafter ) % ls -l /proc//fd % mv /tmp/foo.test /tmp/foo2.test % ls -l /proc//fd # note that the symlink now points at /tmp/foo2.test % cat /proc//fd/1 # note that it works! % rm /tmp/foo2.test % ls -l /proc//fd # note that the symlink now has "(deleted)" at the end % cat /proc//fd/1 # note that it works! This is of course horribly Linux-specific, but so would be a new system call like your proposed fdrepon. Better yet, using /proc/self/fd/* will work *now*. You don't have to wait for a new system call in a future verison of the kernel to start shipping in new distributions. Regards, - 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/
Re: [PATCH] Allow 0ms deadline latency
re-send it On 12/10/2012 12:01 AM, xtu4 wrote: Subject: [PATCH] Allow 0ms deadline latency, increase the read speed Signed-off-by: xiaobing tu --- block/deadline-iosched.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c index c644137..e502d6b 100644 --- a/block/deadline-iosched.c +++ b/block/deadline-iosched.c @@ -230,7 +230,7 @@ static inline int deadline_check_fifo(struct deadline_data *dd, int ddir) /* * rq is expired! */ - if (time_after(jiffies, rq_fifo_time(rq))) + if (time_after_eq(jiffies, rq_fifo_time(rq))) 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/
[PATCH] Allow 0ms deadline latency
Subject: [PATCH] Allow 0ms deadline latency, increase the read speed Signed-off-by: xiaobing tu --- block/deadline-iosched.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/block/deadline-iosched.c b/block/deadline-iosched.c index c644137..e502d6b 100644 --- a/block/deadline-iosched.c +++ b/block/deadline-iosched.c @@ -230,7 +230,7 @@ static inline int deadline_check_fifo(struct deadline_data *dd, int ddir) /* * rq is expired! */ - if (time_after(jiffies, rq_fifo_time(rq))) + if (time_after_eq(jiffies, rq_fifo_time(rq))) return 1; return 0; -- 1.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] improve read ahead in kernel
Subject: [PATCH] when system in low memory scenario, imaging there is a mp3
play, or video play, we need to read mp3 or video file
from memory to page cache,but when system lack of memory,
page cache of mp3 or video file will be reclaimed.once read
in memory, then reclaimed, it will cause audio or video
glitch,and it will increase the io operation at the same
time.
Signed-off-by: xiaobing tu
---
include/linux/mm_types.h |4
mm/Kconfig |6 ++
mm/filemap.c |4
mm/readahead.c | 20 +---
mm/vmscan.c | 10 --
5 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 5b42f1b..541864d 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -149,6 +149,10 @@ struct page {
*/
void *shadow;
#endif
+#ifdef CONFIG_LOWMEMORY_READAHEAD
+unsigned int ioprio;
+#endif
+
}
/*
* If another subsystem starts using the double word pairing for atomic
diff --git a/mm/Kconfig b/mm/Kconfig
index e338407..dade8d3 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -140,6 +140,12 @@ config ARCH_DISCARD_MEMBLOCK
config NO_BOOTMEM
boolean
+# improve readahead in low memory scenario
+config LOWMEMORY_READAHEAD
+bool "improve readahead in low memory scenario"
+depends on (IA64 || X86)
+
+
# eventually, we can have this option just 'select SPARSEMEM'
config MEMORY_HOTPLUG
bool "Allow for memory hot-add"
diff --git a/mm/filemap.c b/mm/filemap.c
index a0701e6..e32efed8 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -129,6 +129,10 @@ void __delete_from_page_cache(struct page *page)
page->mapping = NULL;
/* Leave page->index set: truncation lookup relies upon it */
mapping->nrpages--;
+#ifdef CONFIG_LOWMEMORY_READAHEAD
+page->ioprio = 0;
+#endif
+
__dec_zone_page_state(page, NR_FILE_PAGES);
if (PageSwapBacked(page))
__dec_zone_page_state(page, NR_SHMEM);
diff --git a/mm/readahead.c b/mm/readahead.c
index cbcbb02..dd07cfe 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -159,6 +159,11 @@ __do_page_cache_readahead(struct address_space
*mapping, struct file *filp,
int page_idx;
int ret = 0;
loff_t isize = i_size_read(inode);
+#ifdef CONFIG_LOWMEMORY_READAHEAD
+int class = 0;
+if (p->io_context)
+class = IOPRIO_PRIO_CLASS(p->io_context->ioprio);
+#endif
if (isize == 0)
goto out;
@@ -177,12 +182,21 @@ __do_page_cache_readahead(struct address_space
*mapping, struct file *filp,
rcu_read_lock();
page = radix_tree_lookup(>page_tree, page_offset);
rcu_read_unlock();
-if (page)
-continue;
-
+if (page){
+#ifdef CONFIG_LOWMEMORY_READAHEAD
+if (class == IOPRIO_CLASS_RT) {
+page->ioprio = 1;
+#endif
+continue;
+}
page = page_cache_alloc_readahead(mapping);
if (!page)
break;
+#ifdef CONFIG_LOWMEMORY_READAHEAD
+if (class == IOPRIO_CLASS_RT) {
+page->ioprio = 1;
+#endif
+
page->index = page_offset;
list_add(>lru, _pool);
if (page_idx == nr_to_read - lookahead_size)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 753a2dc..86e03aa 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -728,8 +728,14 @@ static enum page_references
page_check_references(struct page *page,
}
/* Reclaim if clean, defer dirty pages to writeback */
-if (referenced_page && !PageSwapBacked(page))
-return PAGEREF_RECLAIM_CLEAN;
+if (referenced_page && !PageSwapBacked(page)) {
+#ifdef CONFIG_LOWMEMORY_READAHEAD
+if (page->ioprio == 1) {
+return PAGEREF_ACTIVATE;
+} else
+#endif
+return PAGEREF_RECLAIM_CLEAN;
+}
return PAGEREF_RECLAIM;
}
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] arch/x86/tools/gen-insn-attr-x86.awk: remove duplicate const
No, that would really be wrong - changing the type.
Masami Hiramatsu wrote:
>(2012/12/08 8:17), Cong Ding wrote:
>>> Patch description please?
>> there are 2 consts in the definition of one variable
>>
>
> Please put in an actual patch description. The first line
>(subject
> line) is a title; the patch should make sense without it.
sorry for that. so like this is fine?
>>>
>>> Well, except that typically you should explain which variable it is.
>>> Yes, it is obvious if you look at the patch, but you're making the
>>> reader spend a few more moments than necessary.
>>>
>>> Also, you should explain what the harm is -- if it breaks anything
>>> or is just a cosmetic issue.
>> sorry again for lacking of experience...
>> and I missed another same error, so send version 2.
>
>Ah, sorry for my mistake. I would like to make both the value
>pointed by the pointers and the pointers itself read-only.
>Thus the right way of the patch should be;
>
>- print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX + 1]"
>\
>+ print "const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX +
>1]" \
>
>Cong, could you update your patch? then I can Ack that.
>
>Thank you,
>
>>
>> - cong
>> ---
>> From 6cf729b913287a6fc06325ca75ccf0efff9274e8 Mon Sep 17 00:00:00
>2001
>> From: Cong Ding
>> Date: Fri, 7 Dec 2012 23:14:32 +
>> Subject: [PATCH] arch/x86/tools/gen-insn-attr-x86.awk: remove
>duplicate const
>>
>> fix the following sparse warning:
>> arch/x86/lib/inat-tables.c:1080:25: warning: duplicate const
>> arch/x86/lib/inat-tables.c:1095:25: warning: duplicate const
>> arch/x86/lib/inat-tables.c:1118:25: warning: duplicate const
>>
>> for variable inat_escape_tables, inat_group_tables, and
>inat_avx_tables
>>
>> Signed-off-by: Cong Ding
>> ---
>> arch/x86/tools/gen-insn-attr-x86.awk |6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
>b/arch/x86/tools/gen-insn-attr-x86.awk
>> index ddcf39b..987c7b2 100644
>> --- a/arch/x86/tools/gen-insn-attr-x86.awk
>> +++ b/arch/x86/tools/gen-insn-attr-x86.awk
>> @@ -356,7 +356,7 @@ END {
>> exit 1
>> # print escape opcode map's array
>> print "/* Escape opcode map array */"
>> -print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX +
>1]" \
>> +print "const insn_attr_t *inat_escape_tables[INAT_ESC_MAX + 1]" \
>>"[INAT_LSTPFX_MAX + 1] = {"
>> for (i = 0; i < geid; i++)
>> for (j = 0; j < max_lprefix; j++)
>> @@ -365,7 +365,7 @@ END {
>> print "};\n"
>> # print group opcode map's array
>> print "/* Group opcode map array */"
>> -print "const insn_attr_t const *inat_group_tables[INAT_GRP_MAX +
>1]"\
>> +print "const insn_attr_t *inat_group_tables[INAT_GRP_MAX + 1]"\
>>"[INAT_LSTPFX_MAX + 1] = {"
>> for (i = 0; i < ggid; i++)
>> for (j = 0; j < max_lprefix; j++)
>> @@ -374,7 +374,7 @@ END {
>> print "};\n"
>> # print AVX opcode map's array
>> print "/* AVX opcode map array */"
>> -print "const insn_attr_t const *inat_avx_tables[X86_VEX_M_MAX +
>1]"\
>> +print "const insn_attr_t *inat_avx_tables[X86_VEX_M_MAX + 1]"\
>>"[INAT_LSTPFX_MAX + 1] = {"
>> for (i = 0; i < gaid; i++)
>> for (j = 0; j < max_lprefix; j++)
>>
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: tps6507x: Convert to devm_kzalloc
Hi Axel, On Sun, Dec 09, 2012 at 08:25:55PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin > --- > drivers/mfd/tps6507x.c | 21 - > 1 file changed, 4 insertions(+), 17 deletions(-) Applied, many thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7] mfd: stmpe: Update DT support for stmpe driver
Hi Viresh, On Fri, Dec 07, 2012 at 08:29:37PM +0530, Viresh Kumar wrote: > From: Vipul Kumar Samar > > This patch extends existing DT support for stmpe devices. This updates: > - missing header files in stmpe.c > - stmpe_of_probe() with pwm, rotator and new bindings. > - Bindings are updated in binding document. > > Acked-by: Lee Jones > Acked-by: Linus Walleij > Signed-off-by: Vipul Kumar Samar > Signed-off-by: Viresh Kumar > --- > V6->V7: > - Minor grammer correction in stmpe.txt > - Removed comment over pdata->id = -1 Very good, patch applied to my for-next branch now. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: wm5102: Add readback of DSP status 3 register
Hi Mark, On Sun, Dec 02, 2012 at 02:14:56AM +0900, Mark Brown wrote: > Signed-off-by: Mark Brown > --- > drivers/mfd/wm5102-tables.c |2 ++ > include/linux/mfd/arizona/registers.h |1 + > 2 files changed, 3 insertions(+) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: arizona: Disable control interface reporting for WM5102 and WM5110
Hi Mark, On Wed, Dec 05, 2012 at 11:46:04AM +0900, Mark Brown wrote: > Rather than disabling the error reporting only for earlier revisions > unconditionally disable it. > > Signed-off-by: Mark Brown > --- > > This is a bug fix for later chip revisons. > > drivers/mfd/arizona-irq.c | 18 ++ > 1 file changed, 2 insertions(+), 16 deletions(-) Applied to my for-linus branch. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: arizona: Log if we fail to create the primary IRQ domain
Hi Mark, On Wed, Dec 05, 2012 at 11:46:26AM +0900, Mark Brown wrote: > This is the only thing in probe for which we don't log an error. > > Signed-off-by: Mark Brown > --- > drivers/mfd/arizona-irq.c |1 + > 1 file changed, 1 insertion(+) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: echo: remove unused variable
ping!
- cong
On Tue, Dec 04, 2012 at 01:21:44AM +, Cong Ding wrote:
> the variable j isn't used in the loop
>
> Signed-off-by: Cong Ding
> ---
> drivers/staging/echo/echo.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/echo/echo.c b/drivers/staging/echo/echo.c
> index ca87ce9..14dfd91 100644
> --- a/drivers/staging/echo/echo.c
> +++ b/drivers/staging/echo/echo.c
> @@ -119,7 +119,6 @@
> static inline void lms_adapt_bg(struct oslec_state *ec, int clean, int shift)
> {
> int i;
> - int j;
> int offset1;
> int offset2;
> int factor;
> @@ -142,7 +141,7 @@ static inline void lms_adapt_bg(struct oslec_state *ec,
> int clean, int shift)
>
> /* asm("st:"); */
> n = ec->taps;
> - for (i = 0, j = offset2; i < n; i++, j++) {
> + for (i = 0; i < n; i++) {
> exp = *phist++ * factor;
> ec->fir_taps16[1][i] += (int16_t) ((exp + (1 << 14)) >> 15);
> }
> --
> 1.7.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi:gdth.c: fix compilation warning
ping!
- cong
On Mon, Dec 03, 2012 at 10:19:09AM +, Cong Ding wrote:
> We do not allow old-style function definition. Always spell foo(void) if
> a function does not take any parameters.
>
> Signed-off-by: Cong Ding
> ---
> drivers/scsi/gdth.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
> index 5d72274..950c095 100644
> --- a/drivers/scsi/gdth.c
> +++ b/drivers/scsi/gdth.c
> @@ -204,7 +204,7 @@ static char strbuf[MAX_SERBUF+1];
> #else
> #define COM_BASE 0x3f8
> #endif
> -static void ser_init()
> +static void ser_init(void)
> {
> unsigned port=COM_BASE;
>
> --
> 1.7.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] kbuild: solve the DSO link change issue
Ping Michal, did you have any comments on this? - cong On Thu, Nov 29, 2012 at 05:21:28PM +, Cong Ding wrote: > when make menuconfig, it reports this error: > > /usr/bin/ld: scripts/kconfig/lxdialog/checklist.o: undefined reference to > symbol 'acs_map' > /usr/bin/ld: note: 'acs_map' is defined in DSO /lib64/libtinfo.so.5 so try > adding it to the linker command line > /lib64/libtinfo.so.5: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > > due to the DSO link change, we must explicitly link against every library > needed. > http://fedoraproject.org/wiki/UnderstandingDSOLinkChange > > Signed-off-by: Cong Ding > --- > scripts/kconfig/Makefile |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 3091794..ae339a1 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -215,6 +215,7 @@ HOSTCFLAGS_gconf.o= `pkg-config --cflags gtk+-2.0 > gmodule-2.0 libglade-2.0` \ >-Wno-missing-prototypes > > HOSTLOADLIBES_mconf = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags > $(HOSTCC)) > +HOSTLOADLIBES_mconf += -ltinfo > > HOSTLOADLIBES_nconf = -lmenu -lpanel -lncurses > $(obj)/qconf.o: $(obj)/.tmp_qtcheck > -- > 1.7.4.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New system call wanted: fdreopen
Hello,
I'd like to propose a system call called "fdreopen":
int fdreopen(int src_fd, int dst_fd, int flags);
I am willing to try implementing this system call given some suggestions
where to start and what locking to watch out for. I have given a brief of
the behaviour below, and a description of the class of problem that it
solves at the end.
Does anybody know any reasons why this system call would be impossible/
impractical or otherwise unacceptable?
Any improvements I should consider before trying to implement it?
Behaviour
=
This system call would be like dup3 except for these things:
- if dst_fd is -1 then the lowest available file descriptor is allocated
rather than returning EBADF as dup3 does.
- the new file descriptor points to a *new* entry in the file table much
as if the original file had been opened again via open or openat. This
means that two large independent libraries can seek and read without
synchronising even when they cannot open a file by its path.
- O_RDWR access can be reduced to O_RDONLY or O_WRONLY:
int src_fd = open("/file", O_RDWR | O_CLOEXEC);
new_fd = fdreopen(src_fd, -1, O_CLOEXEC | O_RDONLY);
- it would be async signal safe.
Why
===
A common idiom on Linux is to open a file and keep the fd open so that
the underlying file can be unlinked from its directory. But if the file
needs to be read from several different parts of the codebase then due to
the file descriptor having exactly one read pointer those different parts
must be synchronised which is a relatively difficult task.
I think that this new system call is required to achieve that neatly and
simply:
- dup does not solve this problem because it only allows the new file
descriptor to have its own flags (eg O_CLOEXEC).
- /proc/self/fd/* does not solve this problem because the file might no
longer be available at the same place in the filesystem. In some
otherwise simple message passing or ReSTful IPC a different file will
be available at that path.
I suspect that user space has been solving this problem with otherwise
unnecessary levels of either synchronisation or difficult to reproduce
occasional bugs.
--
Tristan Wibberley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Unbreak cleaning external module build directory
On 18.11.2012 16:01, Bart Van Assche wrote: > Avoid that "$(MAKE) -C $(KDIR) M=$(PWD) clean" triggers the following > error message when invoked from inside the Makefile of an external > kernel module: > > rm: cannot remove 'System.map': Permission denied > make[1]: *** [clean] Error 1 I just applied an earlier patch to fix this: https://patchwork.kernel.org/patch/1663011/ Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Do not remove vmlinux when cleaning external module
On Sat, Nov 10, 2012 at 01:59:21PM +0100, Romain Francoise wrote: > Pawel Moll writes: > > > Since commit 1f2bfbd00e466ff3489b2ca5cc75b1cccd14c123 "kbuild: > > link of vmlinux moved to a script" make clean with M= > > argument (so cleaning external module) removes vmlinux, > > System.map and couple of other files from the *main* kernel > > build directory! This not what was happening before and almost > > certainly not what one would expect. > > > This patch moves makes the clean target of the script called > > only when !KBUILD_EXTMOD. > > Thanks, I have the same problem and this patch fixes it. > > Michal, can you pick it up? It's not yet in kbuild.git, it seems. Sorry for the delay. I applied it to kbuild.git#kbuild now, with Cc: sta...@vger.kernel.org [v3.5+] Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] scripts/coccinelle/misc/warn.cocci: use WARN
On Sat, Nov 03, 2012 at 09:02:09PM +0100, Julia Lawall wrote: > From: Julia Lawall > > Use WARN(1,...) rather than printk followed by WARN(1). > > Signed-off-by: Julia Lawall > > --- > scripts/coccinelle/misc/warn.cocci | 109 > + Applied to kbuild.git#misc, thanks. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] mfd: tps80031: MFD_TPS80031 needs to select REGMAP_IRQ
Hi Axel, On Wed, Dec 05, 2012 at 09:19:48PM +0800, Axel Lin wrote: > This driver uses regmap_irq APIs, thus need to select REGMAP_IRQ. > IRQ_DOMAIN will be selected if select REGMAP_IRQ, thus remove it here. > > This fixes below build errors: > > drivers/built-in.o: In function `tps80031_remove': > drivers/mfd/tps80031.c:534: undefined reference to `regmap_del_irq_chip' > drivers/built-in.o: In function `tps80031_irq_init': > drivers/mfd/tps80031.c:305: undefined reference to `regmap_add_irq_chip' > drivers/built-in.o: In function `tps80031_probe': > drivers/mfd/tps80031.c:496: undefined reference to `regmap_irq_get_domain' > drivers/mfd/tps80031.c:512: undefined reference to `regmap_del_irq_chip' > make: *** [vmlinux] Error 1 > > Signed-off-by: Axel Lin > --- > drivers/mfd/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied as well, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: tps80031: Add terminating entry for tps80031_id_table
Hi Axel, On Wed, Dec 05, 2012 at 08:59:00PM +0800, Axel Lin wrote: > The i2c_device_id table is supposed to be zero-terminated. > > Signed-off-by: Axel Lin > --- > drivers/mfd/tps80031.c |1 + > 1 file changed, 1 insertion(+) Applied, thanks a lot. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [RFCv2][PATCH 1/3] create slow_virt_to_phys()
Copying more people. Is this approach good? The alternative would be to
allocate NR_CPUS sized arrays in KVM.
On Fri, Dec 07, 2012 at 04:30:23PM -0500, Dave Hansen wrote:
>
> This is necessary because __pa() does not work on some kinds of
> memory, like vmalloc() or the alloc_remap() areas on 32-bit
> NUMA systems. We have some functions to do conversions _like_
> this in the vmalloc() code (like vmalloc_to_page()), but they
> do not work on sizes other than 4k pages. We would potentially
> need to be able to handle all the page sizes that we use for
> the kernel linear mapping (4k, 2M, 1G).
>
> In practice, on 32-bit NUMA systems, the percpu areas get stuck
> in the alloc_remap() area. Any __pa() call on them will break
> and basically return garbage.
>
> This patch introduces a new function slow_virt_to_phys(), which
> walks the kernel page tables on x86 and should do precisely
> the same logical thing as __pa(), but actually work on a wider
> range of memory. It should work on the normal linear mapping,
> vmalloc(), kmap(), etc...
>
>
> Signed-off-by: Dave Hansen
> ---
>
> linux-2.6.git-dave/arch/x86/include/asm/pgtable_types.h |1
> linux-2.6.git-dave/arch/x86/mm/pageattr.c | 47
>
> 2 files changed, 48 insertions(+)
>
> diff -puN arch/x86/include/asm/pgtable_types.h~create-slow_virt_to_phys
> arch/x86/include/asm/pgtable_types.h
> ---
> linux-2.6.git/arch/x86/include/asm/pgtable_types.h~create-slow_virt_to_phys
> 2012-12-07 16:25:16.317592189 -0500
> +++ linux-2.6.git-dave/arch/x86/include/asm/pgtable_types.h 2012-12-07
> 16:25:16.321592224 -0500
> @@ -332,6 +332,7 @@ static inline void update_page_count(int
> * as a pte too.
> */
> extern pte_t *lookup_address(unsigned long address, unsigned int *level);
> +extern phys_addr_t slow_virt_to_phys(void *__address);
>
> #endif /* !__ASSEMBLY__ */
>
> diff -puN arch/x86/mm/pageattr.c~create-slow_virt_to_phys
> arch/x86/mm/pageattr.c
> --- linux-2.6.git/arch/x86/mm/pageattr.c~create-slow_virt_to_phys
> 2012-12-07 16:25:16.317592189 -0500
> +++ linux-2.6.git-dave/arch/x86/mm/pageattr.c 2012-12-07 16:28:20.675189758
> -0500
> @@ -364,6 +364,53 @@ pte_t *lookup_address(unsigned long addr
> EXPORT_SYMBOL_GPL(lookup_address);
>
> /*
> + * This is necessary because __pa() does not work on some
> + * kinds of memory, like vmalloc() or the alloc_remap()
> + * areas on 32-bit NUMA systems. The percpu areas can
> + * end up in this kind of memory, for instance.
> + *
> + * This could be optimized, but it is only intended to be
> + * used at inititalization time, and keeping it
> + * unoptimized should increase the testing coverage for
> + * the more obscure platforms.
> + */
> +phys_addr_t slow_virt_to_phys(void *__virt_addr)
> +{
> + unsigned long virt_addr = (unsigned long)__virt_addr;
> + phys_addr_t phys_addr;
> + unsigned long offset;
> + unsigned int level = -1;
> + unsigned long psize = 0;
> + unsigned long pmask = 0;
> + pte_t *pte;
> +
> + pte = lookup_address(virt_addr, );
> + BUG_ON(!pte);
> + switch (level) {
> + case PG_LEVEL_4K:
> + psize = PAGE_SIZE;
> + pmask = PAGE_MASK;
> + break;
> + case PG_LEVEL_2M:
> + psize = PMD_PAGE_SIZE;
> + pmask = PMD_PAGE_MASK;
> + break;
> +#ifdef CONFIG_X86_64
> + case PG_LEVEL_1G:
> + psize = PUD_PAGE_SIZE;
> + pmask = PUD_PAGE_MASK;
> + break;
> +#endif
> + default:
> + BUG();
> + }
> + offset = virt_addr & ~pmask;
> + phys_addr = pte_pfn(*pte) << PAGE_SHIFT;
> + return (phys_addr | offset);
> +}
> +EXPORT_SYMBOL_GPL(slow_virt_to_phys);
> +
> +/*
> * Set the new pmd in all the pgds we know about:
> */
> static void __set_pmd_pte(pte_t *kpte, unsigned long address, pte_t pte)
> _
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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.0-rc8 btrfs locking issue
On Wed, Dec 05, 2012 at 09:07:05AM -0700, Jim Schutt wrote:
> Hi,
>
> I'm hitting a btrfs locking issue with 3.7.0-rc8.
>
> The btrfs filesystem in question is backing a Ceph OSD
> under a heavy write load from many cephfs clients.
>
> I reported this issue a while ago:
> http://www.spinics.net/lists/linux-btrfs/msg19370.html
> when I was testing what I thought might be part of the
> 3.7 btrfs patch queue, using Josef Bacik's btrfs-next tree.
>
> I spent some time attempting to bisect the btrfs patch queue
> just before it was merged for 3.7, but got nowhere due to
> false negatives.
>
> I've just been able to get back to testing 3.7-rc, and found
> that I can still trigger the issue.
Hi Jim,
Could you please apply the following patch to test if it works?
(It's against 3.7-rc8.)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 3d3e2c1..100289b 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3346,7 +3346,8 @@ u64 btrfs_get_alloc_profile(struct btrfs_root
*root, int data)
if (data)
flags = BTRFS_BLOCK_GROUP_DATA;
- else if (root == root->fs_info->chunk_root)
+ else if (root == root->fs_info->chunk_root ||
+root == root->fs_info->dev_root)
flags = BTRFS_BLOCK_GROUP_SYSTEM;
else
flags = BTRFS_BLOCK_GROUP_METADATA;
@@ -3535,6 +3536,7 @@ static u64 get_system_chunk_thresh(struct
btrfs_root *root, u64 type)
num_dev = 1;/* DUP or single */
/* metadata for updaing devices and chunk tree */
+ num_dev = num_dev << 1
return btrfs_calc_trans_metadata_size(root, num_dev + 1);
}
@@ -4351,7 +4353,7 @@ static void init_global_block_rsv(struct
btrfs_fs_info *fs_info)
fs_info->extent_root->block_rsv = _info->global_block_rsv;
fs_info->csum_root->block_rsv = _info->global_block_rsv;
- fs_info->dev_root->block_rsv = _info->global_block_rsv;
+ fs_info->dev_root->block_rsv = _info->chunk_block_rsv;
fs_info->tree_root->block_rsv = _info->global_block_rsv;
fs_info->chunk_root->block_rsv = _info->chunk_block_rsv;
thanks,
liubo
>
> First I get this lockdep splat:
>
> [ 1184.201331] =
> [ 1184.206716] [ INFO: possible recursive locking detected ]
> [ 1184.212111] 3.7.0-rc8-00013-gdf2fc24 #438 Not tainted
> [ 1184.217156] -
> [ 1184.222544] ceph-osd/42177 is trying to acquire lock:
> [ 1184.227589] (_info->chunk_mutex){+.+...}, at: []
> do_chunk_alloc+0x183/0x340 [btrfs]
> [ 1184.237270]
> [ 1184.237270] but task is already holding lock:
> [ 1184.243114] (_info->chunk_mutex){+.+...}, at: []
> do_chunk_alloc+0x183/0x340 [btrfs]
> [ 1184.252786]
> [ 1184.252786] other info that might help us debug this:
> [ 1184.259303] Possible unsafe locking scenario:
> [ 1184.259303]
> [ 1184.265220]CPU0
> [ 1184.267680]
> [ 1184.270133] lock(_info->chunk_mutex);
> [ 1184.274276] lock(_info->chunk_mutex);
> [ 1184.278417]
> [ 1184.278417] *** DEADLOCK ***
> [ 1184.278417]
> [ 1184.284325] May be due to missing lock nesting notation
> [ 1184.284325]
> [ 1184.291099] 4 locks held by ceph-osd/42177:
> [ 1184.295277] #0: (sb_writers#7){.+.+.+}, at: []
> btrfs_file_aio_write+0x64/0x320 [btrfs]
> [ 1184.305103] #1: (>s_type->i_mutex_key#9){+.+.+.}, at:
> [] btrfs_file_aio_write+0x6e/0x320 [btrfs]
> [ 1184.316108] #2: (sb_internal){.+.+..}, at: []
> start_transaction+0x1c4/0x450 [btrfs]
> [ 1184.325632] #3: (_info->chunk_mutex){+.+...}, at:
> [] do_chunk_alloc+0x183/0x340 [btrfs]
> [ 1184.335761]
> [ 1184.335761] stack backtrace:
> [ 1184.340126] Pid: 42177, comm: ceph-osd Not tainted
> 3.7.0-rc8-00013-gdf2fc24 #438
> [ 1184.347508] Call Trace:
> [ 1184.349962] [] ? vprintk_emit+0x42a/0x4c0
> [ 1184.355619] [] print_deadlock_bug+0xe9/0x100
> [ 1184.361556] [] validate_chain+0x596/0x750
> [ 1184.367222] [] __lock_acquire+0x449/0x510
> [ 1184.372894] [] ? do_chunk_alloc+0x183/0x340 [btrfs]
> [ 1184.379417] [] lock_acquire+0xc9/0x120
> [ 1184.384855] [] ? do_chunk_alloc+0x183/0x340 [btrfs]
> [ 1184.391377] [] ? __lock_acquire+0x449/0x510
> [ 1184.397204] [] __mutex_lock_common+0x5d/0x3a0
> [ 1184.403221] [] ? do_chunk_alloc+0x183/0x340 [btrfs]
> [ 1184.409762] [] ? do_chunk_alloc+0x183/0x340 [btrfs]
> [ 1184.416323] [] ? do_chunk_alloc+0x179/0x340 [btrfs]
> [ 1184.422849] [] mutex_lock_nested+0x4a/0x60
> [ 1184.428640] [] do_chunk_alloc+0x183/0x340 [btrfs]
> [ 1184.435018] [] find_free_extent+0xa3c/0xb70 [btrfs]
> [ 1184.441555] [] ? btrfs_reduce_alloc_profile+0xa9/0x120
> [btrfs]
> [ 1184.449051] [] btrfs_reserve_extent+0x82/0x190 [btrfs]
> [ 1184.455843] [] btrfs_alloc_free_block+0x85/0x230 [btrfs]
> [ 1184.462828] [] __btrfs_cow_block+0x14a/0x4b0 [btrfs]
> [ 1184.469471] [] ? btrfs_set_lock_blocking_rw+0xe3/0x160
> [btrfs]
> [ 1184.476962] []
Re: [PATCH] Documentation: cgroup: update the index file
On Sat, Dec 08, 2012 at 03:02:36PM +0900, Namjae Jeon wrote: > From: Namjae Jeon > > There are new files added to cgroup documentation. Lets > update the index file listing all the remaining files > > Signed-off-by: Namjae Jeon > Signed-off-by: Amit Sahrawat Applied to cgroup/for-3.8 w/ minor patch subj/description update. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Expand CPU compiler options
On Sun, Dec 09, 2012 at 04:59:41AM -0800, John wrote: > My only confusion is why some of these are already included in the > linux kernel source today, for example CORE2. As I stated in my > previous email, the two 'new' ones I tested preform as-good-as or > better-than the CORE2 which is already included. Does my confusion > make sense? That's a good question. Hmm, next question :-). In any case, I've yet to see significant perf improvements to the kernel due to it being built with specific uarch -mtune settings. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Orion: Hoist bridge interrupt handling out of the timer
On 12/09/2012 09:30 AM, Andrew Lunn wrote: On Sat, Dec 08, 2012 at 07:57:48PM -0700, Jason Gunthorpe wrote: On Sat, Dec 08, 2012 at 12:26:24PM +0100, Andrew Lunn wrote: 1) It should have an IRQ domain, like the other IRQ chips we have. 2) It should have a DT binding, like the other IRQ chips we have. I was going to look at a DT binding for this as a follow on, since I'll want to bind to these interrupts. Are you OK with keeping this patch as is and seeing DT in a follow up, or as a series? It is already pretty big. Hi Jason A patch series is great. However, its not so good practice to add something on the first patch, and then move it somewhere else in the next. So i would suggest initializing the controller in kirkwood_irq_init(), etc as its added. Hi Andrew, Jason, first of all I have adjusted the Cc list a little bit: Gregory is missing, and I removed Mike and Olof as they might not be that interested in discussing mvebu internals. Please re-add if I am wrong. I have an irqchip driver for orion that I wrote some weeks ago. I can prepare a patch today. I will allow to have main irq controller by DT and I can also add a secondary irq controller for the bridge registers as chained irq handler. If I dig hard enough in my branches I will also find time-orion drivers, that are either "standalone" (i.e. orion only) or merged with time-mvebu. The main irq controller will be required for sure, but for the secondary irq controller we had a discussion long ago. IIRC Gregory proposed to have shared irqs handled by timer and watchdog, I was proposing chained irqs. For mvebu archs, IIRC, we have wrt to timer-related irqs: - Armada 370/XP with different irq handler and timer irq handling within timer registers. - Orion SoCs with Bridge irq registers for timer related stuff (timer0/1) - Kirkwood and Dove with watchdog timers (both with wdt irq in bridge irqs) - RTC in bridge irqs, but Dove with RTC connected to PMU irqs I think we should have patches for irqchip-orion first and then rethink if we want a standalone timer-orion or merge it with timer-mvebu. Having watchdog using irqs is kind of independent from this. ... 3) We then pass the timer interrupt via DT to the timer driver. 3) is not so simple, because we currently don't have a timer binding for Orion SoC. However, with this cleanup, we are much closer to being able to use the 370/XP timer code. Interesting.. The 370/XP is a more advanced version of the same timer IP, there are several registers that driver is touching that are not HW supported, at least on kirkwood. Yes, the 25MHz and the divider for example. I'm not 100% sure it will actually work, it will need a different compatibility string, and a bit of configuration based on that string, but i think it goes. If you compare the two different drivers, they are very similar. Back in the days when Gregory, Thomas, and I were looking into merged timer we agreed not to have an extra check on 25MHz support. If you put the property in the node, it will try to set the timer to fixed 25MHz. If you use the property on Orion timer, it will just break timer handling. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] Expand CPU compiler options
> Oh, maybe I wasn't clear - I wasn't talking about statistical > significance but rather about practical significance. OK. I will not argue with that :) > A minuscule speedup (a lot less than 1%) showing only in a *single* > workload so far and relevant only for a *very* *small* number of linux > users - only those who build their own kernels - is simply not worth > including in the kernel. My only confusion is why some of these are already included in the linux kernel source today, for example CORE2. As I stated in my previous email, the two 'new' ones I tested preform as-good-as or better-than the CORE2 which is already included. Does my confusion make sense? Thanks again for the consideration! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
On 12/09/2012 01:21 PM, Alexander Holler wrote:
> This driver makes the time from HID sensors (hubs) which are offering
> such available like any other RTC does.
>
> Currently the time can only be read. Setting the time must be done
> through sending a report, which currently isn't supported by
> hid-sensor-hub.
>
> It is necessary that all values like year, month etc, are send as
> 8bit values (1 byte each) and all of them in 1 report. Also the
> spec HUTRR39b doesn't define the range of the year field, we
> tread it as 0 - 99 because that's what most RTCs I know about are
> offering.
I don't think we should register a IIO device for this. Just an RTC device
should be fully sufficient.
>
> Signed-off-by: Alexander Holler
> ---
> drivers/iio/Kconfig|1 +
> drivers/iio/Makefile |1 +
> drivers/iio/time/Kconfig | 14 ++
> drivers/iio/time/Makefile |5 +
> drivers/iio/time/hid-sensor-time.c | 397
>
> 5 files changed, 418 insertions(+), 0 deletions(-)
> create mode 100644 drivers/iio/time/Kconfig
> create mode 100644 drivers/iio/time/Makefile
> create mode 100644 drivers/iio/time/hid-sensor-time.c
>
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index fc937ac..78fa3ff 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -63,5 +63,6 @@ source "drivers/iio/dac/Kconfig"
> source "drivers/iio/common/Kconfig"
> source "drivers/iio/gyro/Kconfig"
> source "drivers/iio/magnetometer/Kconfig"
> +source "drivers/iio/time/Kconfig"
>
> endif # IIO
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index 761f2b6..6a6da31 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -19,3 +19,4 @@ obj-y += dac/
> obj-y += common/
> obj-y += gyro/
> obj-y += magnetometer/
> +obj-y += time/
> diff --git a/drivers/iio/time/Kconfig b/drivers/iio/time/Kconfig
> new file mode 100644
> index 000..0ca4682
> --- /dev/null
> +++ b/drivers/iio/time/Kconfig
> @@ -0,0 +1,14 @@
> +#
> +# Time sensors
> +#
> +menu "Time sensors"
> +
> +config HID_SENSOR_TIME
> + depends on HID_SENSOR_HUB
> + select HID_SENSOR_IIO_COMMON
> + tristate "HID Time"
> + help
> + Say yes here to build support for the HID SENSOR Time.
> + This drivers makes such sensors available as RTCs.
> +
> +endmenu
> diff --git a/drivers/iio/time/Makefile b/drivers/iio/time/Makefile
> new file mode 100644
> index 000..705fe0d
> --- /dev/null
> +++ b/drivers/iio/time/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for industrial I/O Time sensor driver
> +#
> +
> +obj-$(CONFIG_HID_SENSOR_TIME) += hid-sensor-time.o
> diff --git a/drivers/iio/time/hid-sensor-time.c
> b/drivers/iio/time/hid-sensor-time.c
> new file mode 100644
> index 000..a5993d6
> --- /dev/null
> +++ b/drivers/iio/time/hid-sensor-time.c
> @@ -0,0 +1,397 @@
> +/*
> + * HID Sensor Time Driver
> + * Copyright (c) 2012, Alexander Holler.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 St - Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "../common/hid-sensors/hid-sensor-attributes.h"
> +
> +/* Format: HID-SENSOR-usage_id_in_hex */
> +/* Usage ID from spec for Time: 0x2000A0 */
> +#define DRIVER_NAME "HID-SENSOR-2000a0" /* must be lowercase */
> +
> +enum hid_time_channel {
> + CHANNEL_SCAN_INDEX_YEAR,
> + CHANNEL_SCAN_INDEX_MONTH,
> + CHANNEL_SCAN_INDEX_DAY,
> + CHANNEL_SCAN_INDEX_HOUR,
> + CHANNEL_SCAN_INDEX_MINUTE,
> + CHANNEL_SCAN_INDEX_SECOND,
> + TIME_RTC_CHANNEL_MAX,
> +};
> +
> +struct hid_time_state {
> + struct hid_sensor_hub_callbacks callbacks;
> + struct hid_sensor_iio_common common_attributes;
> + struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX];
> + struct rtc_time last_time;
> + spinlock_t lock_last_time;
> + struct completion comp_last_time;
> + struct rtc_time time_buf;
> + struct rtc_device *rtc;
> +};
> +
> +static const u32 hid_time_addresses[TIME_RTC_CHANNEL_MAX] = {
> + HID_USAGE_SENSOR_TIME_YEAR,
> + HID_USAGE_SENSOR_TIME_MONTH,
> + HID_USAGE_SENSOR_TIME_DAY,
> + HID_USAGE_SENSOR_TIME_HOUR,
> + HID_USAGE_SENSOR_TIME_MINUTE,
> + HID_USAGE_SENSOR_TIME_SECOND,
> +};
> +
> +/* Channel definitions */
>
Re: [PATCH] Expand CPU compiler options
On Sun, Dec 09, 2012 at 04:08:55AM -0800, John wrote: > While I agree that the differences as small - on the order of > ms - they are not insignificant nor are they in the noise of the > measurements. Oh, maybe I wasn't clear - I wasn't talking about statistical significance but rather about practical significance. A minuscule speedup (a lot less than 1%) showing only in a *single* workload so far and relevant only for a *very* *small* number of linux users - only those who build their own kernels - is simply not worth including in the kernel. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: tps6507x: Convert to devm_kzalloc
Signed-off-by: Axel Lin
---
drivers/mfd/tps6507x.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c
index 1b20349..409afa2 100644
--- a/drivers/mfd/tps6507x.c
+++ b/drivers/mfd/tps6507x.c
@@ -86,9 +86,9 @@ static int tps6507x_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct tps6507x_dev *tps6507x;
- int ret = 0;
- tps6507x = kzalloc(sizeof(struct tps6507x_dev), GFP_KERNEL);
+ tps6507x = devm_kzalloc(>dev, sizeof(struct tps6507x_dev),
+ GFP_KERNEL);
if (tps6507x == NULL)
return -ENOMEM;
@@ -98,19 +98,8 @@ static int tps6507x_i2c_probe(struct i2c_client *i2c,
tps6507x->read_dev = tps6507x_i2c_read_device;
tps6507x->write_dev = tps6507x_i2c_write_device;
- ret = mfd_add_devices(tps6507x->dev, -1,
- tps6507x_devs, ARRAY_SIZE(tps6507x_devs),
- NULL, 0, NULL);
-
- if (ret < 0)
- goto err;
-
- return ret;
-
-err:
- mfd_remove_devices(tps6507x->dev);
- kfree(tps6507x);
- return ret;
+ return mfd_add_devices(tps6507x->dev, -1, tps6507x_devs,
+ ARRAY_SIZE(tps6507x_devs), NULL, 0, NULL);
}
static int tps6507x_i2c_remove(struct i2c_client *i2c)
@@ -118,8 +107,6 @@ static int tps6507x_i2c_remove(struct i2c_client *i2c)
struct tps6507x_dev *tps6507x = i2c_get_clientdata(i2c);
mfd_remove_devices(tps6507x->dev);
- kfree(tps6507x);
-
return 0;
}
--
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 3/3] iio: add rtc-driver for HID sensors of type time
This driver makes the time from HID sensors (hubs) which are offering
such available like any other RTC does.
Currently the time can only be read. Setting the time must be done
through sending a report, which currently isn't supported by
hid-sensor-hub.
It is necessary that all values like year, month etc, are send as
8bit values (1 byte each) and all of them in 1 report. Also the
spec HUTRR39b doesn't define the range of the year field, we
tread it as 0 - 99 because that's what most RTCs I know about are
offering.
Signed-off-by: Alexander Holler
---
drivers/iio/Kconfig|1 +
drivers/iio/Makefile |1 +
drivers/iio/time/Kconfig | 14 ++
drivers/iio/time/Makefile |5 +
drivers/iio/time/hid-sensor-time.c | 397
5 files changed, 418 insertions(+), 0 deletions(-)
create mode 100644 drivers/iio/time/Kconfig
create mode 100644 drivers/iio/time/Makefile
create mode 100644 drivers/iio/time/hid-sensor-time.c
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index fc937ac..78fa3ff 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -63,5 +63,6 @@ source "drivers/iio/dac/Kconfig"
source "drivers/iio/common/Kconfig"
source "drivers/iio/gyro/Kconfig"
source "drivers/iio/magnetometer/Kconfig"
+source "drivers/iio/time/Kconfig"
endif # IIO
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 761f2b6..6a6da31 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -19,3 +19,4 @@ obj-y += dac/
obj-y += common/
obj-y += gyro/
obj-y += magnetometer/
+obj-y += time/
diff --git a/drivers/iio/time/Kconfig b/drivers/iio/time/Kconfig
new file mode 100644
index 000..0ca4682
--- /dev/null
+++ b/drivers/iio/time/Kconfig
@@ -0,0 +1,14 @@
+#
+# Time sensors
+#
+menu "Time sensors"
+
+config HID_SENSOR_TIME
+ depends on HID_SENSOR_HUB
+ select HID_SENSOR_IIO_COMMON
+ tristate "HID Time"
+ help
+ Say yes here to build support for the HID SENSOR Time.
+ This drivers makes such sensors available as RTCs.
+
+endmenu
diff --git a/drivers/iio/time/Makefile b/drivers/iio/time/Makefile
new file mode 100644
index 000..705fe0d
--- /dev/null
+++ b/drivers/iio/time/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for industrial I/O Time sensor driver
+#
+
+obj-$(CONFIG_HID_SENSOR_TIME) += hid-sensor-time.o
diff --git a/drivers/iio/time/hid-sensor-time.c
b/drivers/iio/time/hid-sensor-time.c
new file mode 100644
index 000..a5993d6
--- /dev/null
+++ b/drivers/iio/time/hid-sensor-time.c
@@ -0,0 +1,397 @@
+/*
+ * HID Sensor Time Driver
+ * Copyright (c) 2012, Alexander Holler.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 St - Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include "../common/hid-sensors/hid-sensor-attributes.h"
+
+/* Format: HID-SENSOR-usage_id_in_hex */
+/* Usage ID from spec for Time: 0x2000A0 */
+#define DRIVER_NAME "HID-SENSOR-2000a0" /* must be lowercase */
+
+enum hid_time_channel {
+ CHANNEL_SCAN_INDEX_YEAR,
+ CHANNEL_SCAN_INDEX_MONTH,
+ CHANNEL_SCAN_INDEX_DAY,
+ CHANNEL_SCAN_INDEX_HOUR,
+ CHANNEL_SCAN_INDEX_MINUTE,
+ CHANNEL_SCAN_INDEX_SECOND,
+ TIME_RTC_CHANNEL_MAX,
+};
+
+struct hid_time_state {
+ struct hid_sensor_hub_callbacks callbacks;
+ struct hid_sensor_iio_common common_attributes;
+ struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX];
+ struct rtc_time last_time;
+ spinlock_t lock_last_time;
+ struct completion comp_last_time;
+ struct rtc_time time_buf;
+ struct rtc_device *rtc;
+};
+
+static const u32 hid_time_addresses[TIME_RTC_CHANNEL_MAX] = {
+ HID_USAGE_SENSOR_TIME_YEAR,
+ HID_USAGE_SENSOR_TIME_MONTH,
+ HID_USAGE_SENSOR_TIME_DAY,
+ HID_USAGE_SENSOR_TIME_HOUR,
+ HID_USAGE_SENSOR_TIME_MINUTE,
+ HID_USAGE_SENSOR_TIME_SECOND,
+};
+
+/* Channel definitions */
+static const struct iio_chan_spec hid_time_channels[TIME_RTC_CHANNEL_MAX] = {
+ {
+ .info_mask = IIO_CHAN_INFO_RAW,
+ .scan_index = CHANNEL_SCAN_INDEX_YEAR,
+ .extend_name = "year",
+ }, {
+ .info_mask = IIO_CHAN_INFO_RAW,
+ .scan_index = CHANNEL_SCAN_INDEX_MONTH,
+ .extend_name = "month",
+
[PATCH 2/3] iio: Add Usage IDs for HID time sensors.
These are Usage IDs for the attributes year, month, day, hour, minute and second, needed to read HID time sensors. Signed-off-by: Alexander Holler --- include/linux/hid-sensor-ids.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h index 55f2773..6f24446 100644 --- a/include/linux/hid-sensor-ids.h +++ b/include/linux/hid-sensor-ids.h @@ -66,6 +66,15 @@ #define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS 0x200486 #define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS 0x200487 +/* Time (2000a0) */ +#define HID_USAGE_SENSOR_TIME 0x2000a0 +#define HID_USAGE_SENSOR_TIME_YEAR 0x200521 +#define HID_USAGE_SENSOR_TIME_MONTH0x200522 +#define HID_USAGE_SENSOR_TIME_DAY 0x200523 +#define HID_USAGE_SENSOR_TIME_HOUR 0x200525 +#define HID_USAGE_SENSOR_TIME_MINUTE 0x200526 +#define HID_USAGE_SENSOR_TIME_SECOND 0x200527 + /* Units */ #define HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED 0x00 #define HID_USAGE_SENSOR_UNITS_LUX 0x01 -- 1.7.8.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iio: hid-sensors: respect CONFIG_IIO_TRIGGER
Not much to say, without that change, hid-sensor-trigger will be always compiled if HID_SENSOR_IIO_COMMON is selected which fails if CONFIG_IIO_TRIGGER is not set because CONFIG_IIO_CONSUMERS_PER_TRIGGER will not be defined. Signed-off-by: Alexander Holler --- drivers/iio/accel/Kconfig |1 + drivers/iio/common/hid-sensors/Makefile |3 ++- drivers/iio/gyro/Kconfig|1 + drivers/iio/light/Kconfig |1 + drivers/iio/magnetometer/Kconfig|1 + 5 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig index b2510c4..b84b806 100644 --- a/drivers/iio/accel/Kconfig +++ b/drivers/iio/accel/Kconfig @@ -8,6 +8,7 @@ config HID_SENSOR_ACCEL_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Acelerometers 3D" help Say yes here to build support for the HID SENSOR diff --git a/drivers/iio/common/hid-sensors/Makefile b/drivers/iio/common/hid-sensors/Makefile index 1f463e0..22e7c5a 100644 --- a/drivers/iio/common/hid-sensors/Makefile +++ b/drivers/iio/common/hid-sensors/Makefile @@ -3,4 +3,5 @@ # obj-$(CONFIG_HID_SENSOR_IIO_COMMON) += hid-sensor-iio-common.o -hid-sensor-iio-common-y := hid-sensor-attributes.o hid-sensor-trigger.o +obj-$(CONFIG_HID_SENSOR_IIO_TRIGGER) += hid-sensor-trigger.o +hid-sensor-iio-common-y := hid-sensor-attributes.o diff --git a/drivers/iio/gyro/Kconfig b/drivers/iio/gyro/Kconfig index 21e27e2..bc9daff 100644 --- a/drivers/iio/gyro/Kconfig +++ b/drivers/iio/gyro/Kconfig @@ -8,6 +8,7 @@ config HID_SENSOR_GYRO_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Gyroscope 3D" help Say yes here to build support for the HID SENSOR diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig index 1763c9b..dbf80ab 100644 --- a/drivers/iio/light/Kconfig +++ b/drivers/iio/light/Kconfig @@ -47,6 +47,7 @@ config HID_SENSOR_ALS select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID ALS" help Say yes here to build support for the HID SENSOR diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig index c1f0cdd..ff11d68 100644 --- a/drivers/iio/magnetometer/Kconfig +++ b/drivers/iio/magnetometer/Kconfig @@ -8,6 +8,7 @@ config HID_SENSOR_MAGNETOMETER_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Magenetometer 3D" help Say yes here to build support for the HID SENSOR -- 1.7.8.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] iio: HID sensor time (as RTC)
Hello, the following 3 patches are neccessary to add a driver for (USB) HID sensors of type time (using hid-sensor-hub). The driver implements a RTC, so the time will be available like from any other RTC. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] Expand CPU compiler options
> Let's see, if I'm reading the log file correctly, the average values of > each test run differ by ~ 0.1 seconds tops. > > For example, i7-3770K generic build gives on average 69.41404 while > the more optimized version 69.33554. The diff between the two is even > less than 0.1 second. The other two machines' diff is a bit higher. And > from looking at your graphs, this is all eaten up by stddev so I'd say > there aren't any improvements from using a different uarch target - just > noise. AFAICT, at least. While I agree that the differences as small - on the order of ms - they are not insignificant nor are they in the noise of the measurements. 1) All the assumptions for ANOVA are met: *Data are normally distributed as show in the normal quantile plots. *The population variances are fairly equal (Levene and Barlett tests). 2) The ANOVA plots clearly show significance. *Pair-wise analysis by Tukey-Kramer shows significance at the 0.05 level for all CPUs compared. Below are the differences in median values: core2 +87.5 ms corei7-avx +79.7 ms core-avx-i+257.2 ms > In any case, these results are too marginal to warrant any code change > since they're basically disappearing in noise. Currently, the 'core2' optimization is included in as an option for a CPU Family. In the case of core-avx-i, I am showing an improvement of ~3x over that. And in the corei7-avx case, the improvement is approximately equal to it. I don't understand why these wouldn't be considered value-added since they preform at least as good as the option already included. Thank you for the consideration and suggestions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 -v2 3/4] perf: Add persistent event facilities
On Thu, Aug 16, 2012 at 06:12:35PM -0400, Steven Rostedt wrote:
> On Thu, 2012-08-16 at 19:45 +0200, Borislav Petkov wrote:
> >
> > -static void ring_buffer_put(struct ring_buffer *rb)
> > +void ring_buffer_put(struct ring_buffer *rb)
> > {
> > struct perf_event *event, *n;
> > unsigned long flags;
>
> I have to say that it is really unfortunate that we have two ring
> buffers in the kernel, called struct ring_buffer. One being global and
> one being local to events. And now we are exporting the name
> "ring_buffer_*" too! This is going to confuse the hell out of people.
>
> Perhaps this should have been called perf_buffer, as that is what it's
> used for.
How about we prepend all non-static stuff which is part of the perf ring
buffer with "perf_" ?
This way we'll have perf_ring_buffer_put() and the namespace is still
short enough and tells you exactly which buffer we're talking about.
Hmm?
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Incrementing module reference count
On Sat, Dec 08, 2012 at 11:17:31AM -0800, Aaron Williams wrote: > I got it working. I designed my solution to be generic so it's not > tied to just the at24 driver. I added a memory accessor module which > is basically a registry. The at24 driver registers with it and then > the Vitesse PHY driver calls it to gain access to the at24 driver. > Only when the Vitesse driver gets the memory accessor the reference > count for the at24 driver is incremented. Hmm, I'm not sure you even need an additional layer because there's also request_module(). And as long as your module is using at24, you won't need to increment its refcount, AFAICT. HTH. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] rtl8712: replace printk with better solutions
On Sun, 2012-12-09 at 10:15 +, Przemo Firszt wrote:
> Replace printk with netdev_printk helpers, dev_printk helpers or
> pr_err/warn/info if there is no device info available.
Here's a few trivial comments
> @@ -84,8 +83,8 @@ static u32 rtl871x_open_fw(struct _adapter *padapter, const
> u8 **ppmappedfw)
> const struct firmware **praw = >fw;
>
> if (padapter->fw->size > 20) {
> - printk(KERN_ERR "r8172u: Badfw->size of %d\n",
> -(int)padapter->fw->size);
> + dev_err(>pnetdev->dev, "r8172u: Badfw->size of %d\n",
> +(int)padapter->fw->size);
Please align arguments to the open parenthesis
like this:
dev_err(dev, format,
args);
If you are using checkpatch, add --strict to get the
script to tell you when the alignment isn't correct.
> diff --git a/drivers/staging/rtl8712/rtl8712_recv.c
> b/drivers/staging/rtl8712/rtl8712_recv.c
[]
> @@ -829,8 +826,7 @@ static int r871x_wx_set_pmkid(struct net_device *dev,
> strIssueBssid, ETH_ALEN)) {
> /* BSSID is matched, the same AP => rewrite
>* with new PMKID. */
> - printk(KERN_INFO "r8712u: r871x_wx_set_pmkid:"
> - " BSSID exists in the PMKList.\n");
> + netdev_info(dev, "r8712u: r871x_wx_set_pmkid:
> BSSID exists in the PMKList.\n");
when the format contains the function name, convert
it to use %s, ... __func__
Remove unnecessary trailing periods from the formats.
netdev_info(dev, "%s: BSSID exists in the
PMKList\n",
__func__);
> diff --git a/drivers/staging/rtl8712/usb_ops_linux.c
> b/drivers/staging/rtl8712/usb_ops_linux.c
[]
> @@ -243,8 +243,7 @@ static void r8712_usb_read_port_complete(struct urb *purb)
> (unsigned char *)precvbuf);
> break;
> case -EINPROGRESS:
> - printk(KERN_ERR "r8712u: ERROR: URB IS IN"
> -" PROGRESS!/n");
> + netdev_err(padapter->pnetdev, "ERROR: URB IS IN
> PROGRESS!/n");
newlines are \n not /n
> diff --git a/drivers/staging/rtl8712/xmit_linux.c
> b/drivers/staging/rtl8712/xmit_linux.c
[]
> @@ -134,8 +134,7 @@ int r8712_xmit_resource_alloc(struct _adapter *padapter,
> for (i = 0; i < 8; i++) {
> pxmitbuf->pxmit_urb[i] = usb_alloc_urb(0, GFP_KERNEL);
> if (pxmitbuf->pxmit_urb[i] == NULL) {
> - printk(KERN_ERR "r8712u: pxmitbuf->pxmit_urb[i]"
> - " == NULL");
> + netdev_err(padapter->pnetdev, "pxmitbuf->pxmit_urb[i]
> == NULL");
Make sure message formats are newline terminated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: autodetect USB HID sensor hubs.
It should not be necessary to add IDs for HID sensor hubs to lists
in hid-core.c and hid-sensor-hub.c. So instead of a whitelist,
autodetect such USB HID sensor hubs, based on a collection of type
physical inside a useage page of type sensor. If some sensor hubs
stil must be usable as raw devices, a blacklist might be created.
Signed-off-by: Alexander Holler
---
drivers/hid/hid-core.c | 11 ++-
drivers/hid/hid-sensor-hub.c | 32 +---
include/linux/hid-sensor-ids.h |1 -
include/linux/hid.h|2 ++
4 files changed, 13 insertions(+), 33 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f4109fd..7df5399 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -713,7 +713,12 @@ static int hid_scan_report(struct hid_device *hid)
hid_scan_usage(hid, u);
break;
}
- }
+ } else if (page == HID_UP_SENSOR &&
+ item.type == HID_ITEM_TYPE_MAIN &&
+ item.tag == HID_MAIN_ITEM_TAG_BEGIN_COLLECTION &&
+ (item_udata() & 0xff) == HID_COLLECTION_PHYSICAL &&
+ hid->bus == BUS_USB)
+ hid->group = HID_GROUP_SENSOR_HUB;
}
return 0;
@@ -1465,6 +1470,10 @@ EXPORT_SYMBOL_GPL(hid_disconnect);
* there is a proper autodetection and autoloading in place (based on presence
* of HID_DG_CONTACTID), so those devices don't need to be added to this list,
* as we are doing the right thing in hid_scan_usage().
+ *
+ * Autodetection for (USB) HID sensor hubs exists too. If a collection of type
+ * physical is found inside a usage page of type sensor, hid-sensor-hub will be
+ * used as a driver. See hid_scan_report().
*/
static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index d9d73e9..ca88ddc 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -82,23 +82,6 @@ struct hid_sensor_hub_callbacks_list {
void *priv;
};
-static int sensor_hub_check_for_sensor_page(struct hid_device *hdev)
-{
- int i;
- int ret = -EINVAL;
-
- for (i = 0; i < hdev->maxcollection; i++) {
- struct hid_collection *col = >collection[i];
- if (col->type == HID_COLLECTION_PHYSICAL &&
- (col->usage & HID_USAGE_PAGE) == HID_UP_SENSOR) {
- ret = 0;
- break;
- }
- }
-
- return ret;
-}
-
static struct hid_report *sensor_hub_report(int id, struct hid_device *hdev,
int dir)
{
@@ -524,10 +507,6 @@ static int sensor_hub_probe(struct hid_device *hdev,
hid_err(hdev, "parse failed\n");
goto err_free;
}
- if (sensor_hub_check_for_sensor_page(hdev) < 0) {
- hid_err(hdev, "sensor page not found\n");
- goto err_free;
- }
INIT_LIST_HEAD(>inputs);
ret = hid_hw_start(hdev, 0);
@@ -630,16 +609,7 @@ static void sensor_hub_remove(struct hid_device *hdev)
}
static const struct hid_device_id sensor_hub_devices[] = {
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8086,
- USB_DEVICE_ID_SENSOR_HUB_1020) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8087,
- USB_DEVICE_ID_SENSOR_HUB_1020) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8086,
- USB_DEVICE_ID_SENSOR_HUB_09FA) },
- { HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8087,
- USB_DEVICE_ID_SENSOR_HUB_09FA) },
- { HID_USB_DEVICE(USB_VENDOR_ID_STANTUM_STM,
- USB_DEVICE_ID_SENSOR_HUB_7014) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_SENSOR_HUB, HID_ANY_ID, HID_ANY_ID) },
{ }
};
MODULE_DEVICE_TABLE(hid, sensor_hub_devices);
diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
index ca8d7e9..55f2773 100644
--- a/include/linux/hid-sensor-ids.h
+++ b/include/linux/hid-sensor-ids.h
@@ -19,7 +19,6 @@
#ifndef _HID_SENSORS_IDS_H
#define _HID_SENSORS_IDS_H
-#define HID_UP_SENSOR 0x0020
#define HID_MAX_PHY_DEVICES0xFF
/* Accel 3D (200073) */
diff --git a/include/linux/hid.h b/include/linux/hid.h
index c076041..c5f6ec2 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -167,6 +167,7 @@ struct hid_item {
#define HID_UP_MSVENDOR0xff00
#define HID_UP_CUSTOM 0x00ff
#define HID_UP_LOGIVENDOR 0xffbc
+#define HID_UP_SENSOR 0x0020
#define HID_USAGE 0x
@@ -292,6 +293,7 @@ struct hid_item {
*/
Re: [PATCH 1/2] HID: autodetect HID sensor hubs.
Am 09.12.2012 02:12, schrieb Alexander Holler: > It should not be necessary to add IDs for HID sensor hubs to lists > in hid-core.c and hid-sensor-hub.c. So instead of a whitelist, > autodetect such sensor hubs, based on a collection of type > physical inside a useage page of type sensor. If some sensor hubs > stil must be usable as raw devices, a blacklist might be created. That patch didn't check if the device is a USB device and therfor blutooth hid sensor hubs wouldn't still be handled as raw devices. I send another patch 1/2 which checks the bus too. Patch 2/2 still should be applied. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86_32: Return actual stack when requesting sp from regs
Commit-ID: 6c8d8b3c69cef1330e0c5cbc2a8b9268024927a0
Gitweb: http://git.kernel.org/tip/6c8d8b3c69cef1330e0c5cbc2a8b9268024927a0
Author: Steven Rostedt
AuthorDate: Fri, 13 Jul 2012 15:44:14 -0400
Committer: Steven Rostedt
CommitDate: Mon, 19 Nov 2012 05:31:37 -0500
x86_32: Return actual stack when requesting sp from regs
As x86_32 traps do not save sp when taken in kernel mode, we need to
accommodate the sp when requesting to get the register.
This affects kprobes.
Before:
# echo 'p:ftrace sys_read+4 s=%sp' > /debug/tracing/kprobe_events
# echo 1 > /debug/tracing/events/kprobes/enable
# cat trace
sshd-1345 [000] d... 489.117168: ftrace: (sys_read+0x4/0x70)
s=b7e96768
sshd-1345 [000] d... 489.117191: ftrace: (sys_read+0x4/0x70)
s=b7e96768
cat-1447 [000] d... 489.117392: ftrace: (sys_read+0x4/0x70)
s=5a7
cat-1447 [001] d... 489.118023: ftrace: (sys_read+0x4/0x70)
s=b77ad05f
less-1448 [000] d... 489.118079: ftrace: (sys_read+0x4/0x70)
s=b7762e06
less-1448 [000] d... 489.118117: ftrace: (sys_read+0x4/0x70)
s=b7764970
After:
sshd-1352 [000] d... 362.348016: ftrace: (sys_read+0x4/0x70)
s=f3febfa8
sshd-1352 [000] d... 362.348048: ftrace: (sys_read+0x4/0x70)
s=f3febfa8
bash-1355 [001] d... 362.348081: ftrace: (sys_read+0x4/0x70)
s=f5075fa8
sshd-1352 [000] d... 362.348082: ftrace: (sys_read+0x4/0x70)
s=f3febfa8
sshd-1352 [000] d... 362.690950: ftrace: (sys_read+0x4/0x70)
s=f3febfa8
bash-1355 [001] d... 362.691033: ftrace: (sys_read+0x4/0x70)
s=f5075fa8
Link: http://lkml.kernel.org/r/1342208654.30075.22.ca...@gandalf.stny.rr.com
Reviewed-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt
---
arch/x86/include/asm/ptrace.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index dcfde52..2233713 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -246,6 +246,15 @@ static inline unsigned long regs_get_register(struct
pt_regs *regs,
{
if (unlikely(offset > MAX_REG_OFFSET))
return 0;
+#ifdef CONFIG_X86_32
+ /*
+* Traps from the kernel do not save sp and ss.
+* Use the helper function to retrieve sp.
+*/
+ if (offset == offsetof(struct pt_regs, sp) &&
+ regs->cs == __KERNEL_CS)
+ return kernel_stack_pointer(regs);
+#endif
return *(unsigned long *)((unsigned long)regs + offset);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ftrace: Clear bits properly in reset_iter_read( )
Commit-ID: 70f77b3f7ec010ff9624c1f2e39a81babc9e2429
Gitweb: http://git.kernel.org/tip/70f77b3f7ec010ff9624c1f2e39a81babc9e2429
Author: Dan Carpenter
AuthorDate: Sat, 9 Jun 2012 19:10:27 +0300
Committer: Steven Rostedt
CommitDate: Thu, 15 Nov 2012 16:10:17 -0500
ftrace: Clear bits properly in reset_iter_read()
There is a typo here where '&' is used instead of '|' and it turns the
statement into a noop. The original code is equivalent to:
iter->flags &= ~((1 << 2) & (1 << 4));
Link: http://lkml.kernel.org/r/20120609161027.GD6488@elgon.mountain
Cc: sta...@vger.kernel.org # all of them
Signed-off-by: Dan Carpenter
Signed-off-by: Steven Rostedt
---
kernel/trace/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 9dcf15d..51b7159 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2437,7 +2437,7 @@ static void reset_iter_read(struct ftrace_iterator *iter)
{
iter->pos = 0;
iter->func_pos = 0;
- iter->flags &= ~(FTRACE_ITER_PRINTALL & FTRACE_ITER_HASH);
+ iter->flags &= ~(FTRACE_ITER_PRINTALL | FTRACE_ITER_HASH);
}
static void *t_start(struct seq_file *m, loff_t *pos)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/core] tracing: Kill unused and puzzled sample code in ftrace.h
Commit-ID: 1c7d66732458dc187008e3f5b2f71e019e320fc2
Gitweb: http://git.kernel.org/tip/1c7d66732458dc187008e3f5b2f71e019e320fc2
Author: Shan Wei
AuthorDate: Sat, 3 Nov 2012 12:38:33 +0800
Committer: Steven Rostedt
CommitDate: Tue, 13 Nov 2012 15:51:21 -0500
tracing: Kill unused and puzzled sample code in ftrace.h
When doing per-cpu helper optimizing work, find that this code is so puzzled.
1. It's mark as comment text, maybe a sample function for guidelines
or a todo work.
2. But, this sample code is odd where struct perf_trace_buf is nonexistent.
commit ce71b9 delete struct perf_trace_buf definition.
Author: Frederic Weisbecker
Date: Sun Nov 22 05:26:55 2009 +0100
tracing: Use the perf recursion protection from trace event
Is it necessary to keep there?
just compile test.
Link: http://lkml.kernel.org/r/50949fc9.6050...@gmail.com
Signed-off-by: Shan Wei
Signed-off-by: Steven Rostedt
---
include/trace/ftrace.h | 73 --
1 file changed, 73 deletions(-)
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 698f2a8..40dc5e8 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -619,79 +619,6 @@ __attribute__((section("_ftrace_events"))) *__event_##call
= _##call
#include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
-/*
- * Define the insertion callback to perf events
- *
- * The job is very similar to ftrace_raw_event_ except that we don't
- * insert in the ring buffer but in a perf counter.
- *
- * static void ftrace_perf_(proto)
- * {
- * struct ftrace_data_offsets_ __maybe_unused __data_offsets;
- * struct ftrace_event_call *event_call = _;
- * extern void perf_tp_event(int, u64, u64, void *, int);
- * struct ftrace_raw_##call *entry;
- * struct perf_trace_buf *trace_buf;
- * u64 __addr = 0, __count = 1;
- * unsigned long irq_flags;
- * struct trace_entry *ent;
- * int __entry_size;
- * int __data_size;
- * int __cpu
- * int pc;
- *
- * pc = preempt_count();
- *
- * __data_size = ftrace_get_offsets_(&__data_offsets, args);
- *
- * // Below we want to get the aligned size by taking into account
- * // the u32 field that will later store the buffer size
- * __entry_size = ALIGN(__data_size + sizeof(*entry) + sizeof(u32),
- * sizeof(u64));
- * __entry_size -= sizeof(u32);
- *
- * // Protect the non nmi buffer
- * // This also protects the rcu read side
- * local_irq_save(irq_flags);
- * __cpu = smp_processor_id();
- *
- * if (in_nmi())
- * trace_buf = rcu_dereference_sched(perf_trace_buf_nmi);
- * else
- * trace_buf = rcu_dereference_sched(perf_trace_buf);
- *
- * if (!trace_buf)
- * goto end;
- *
- * trace_buf = per_cpu_ptr(trace_buf, __cpu);
- *
- * // Avoid recursion from perf that could mess up the buffer
- * if (trace_buf->recursion++)
- * goto end_recursion;
- *
- * raw_data = trace_buf->buf;
- *
- * // Make recursion update visible before entering perf_tp_event
- * // so that we protect from perf recursions.
- *
- * barrier();
- *
- * //zero dead bytes from alignment to avoid stack leak to userspace:
- * *(u64 *)(_data[__entry_size - sizeof(u64)]) = 0ULL;
- * entry = (struct ftrace_raw_ *)raw_data;
- * ent = >ent;
- * tracing_generic_entry_update(ent, irq_flags, pc);
- * ent->type = event_call->id;
- *
- * <- do some jobs with dynamic arrays
- *
- * <- affect our values
- *
- * perf_tp_event(event_call->id, __addr, __count, entry,
- * __entry_size); <- submit them to perf counter
- *
- * }
- */
#ifdef CONFIG_PERF_EVENTS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/core] tracing: Show raw time stamp on stats per cpu using counter or tsc mode for trace_clock
Commit-ID: 11043d8b125671a32253cddb0b05177be0e976f6
Gitweb: http://git.kernel.org/tip/11043d8b125671a32253cddb0b05177be0e976f6
Author: Yoshihiro YUNOMAE
AuthorDate: Tue, 13 Nov 2012 12:18:23 -0800
Committer: Steven Rostedt
CommitDate: Tue, 13 Nov 2012 15:49:11 -0500
tracing: Show raw time stamp on stats per cpu using counter or tsc mode for
trace_clock
Show raw time stamp values for stats per cpu if you choose counter or tsc mode
for trace_clock. Although a unit of tracing time stamp is nsec in local or
global mode,
the units in counter and TSC mode are tracing counter and cycles respectively.
Link:
http://lkml.kernel.org/r/1352837903-32191-3-git-send-email-dhsh...@google.com
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Signed-off-by: Yoshihiro YUNOMAE
Signed-off-by: David Sharp
Signed-off-by: Steven Rostedt
---
kernel/trace/trace.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d943e69..b69cc38 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -4388,13 +4388,24 @@ tracing_stats_read(struct file *filp, char __user *ubuf,
cnt = ring_buffer_bytes_cpu(tr->buffer, cpu);
trace_seq_printf(s, "bytes: %ld\n", cnt);
- t = ns2usecs(ring_buffer_oldest_event_ts(tr->buffer, cpu));
- usec_rem = do_div(t, USEC_PER_SEC);
- trace_seq_printf(s, "oldest event ts: %5llu.%06lu\n", t, usec_rem);
+ if (trace_clocks[trace_clock_id].in_ns) {
+ /* local or global for trace_clock */
+ t = ns2usecs(ring_buffer_oldest_event_ts(tr->buffer, cpu));
+ usec_rem = do_div(t, USEC_PER_SEC);
+ trace_seq_printf(s, "oldest event ts: %5llu.%06lu\n",
+ t, usec_rem);
+
+ t = ns2usecs(ring_buffer_time_stamp(tr->buffer, cpu));
+ usec_rem = do_div(t, USEC_PER_SEC);
+ trace_seq_printf(s, "now ts: %5llu.%06lu\n", t, usec_rem);
+ } else {
+ /* counter or tsc mode for trace_clock */
+ trace_seq_printf(s, "oldest event ts: %llu\n",
+ ring_buffer_oldest_event_ts(tr->buffer, cpu));
- t = ns2usecs(ring_buffer_time_stamp(tr->buffer, cpu));
- usec_rem = do_div(t, USEC_PER_SEC);
- trace_seq_printf(s, "now ts: %5llu.%06lu\n", t, usec_rem);
+ trace_seq_printf(s, "now ts: %llu\n",
+ ring_buffer_time_stamp(tr->buffer, cpu));
+ }
cnt = ring_buffer_dropped_events_cpu(tr->buffer, cpu);
trace_seq_printf(s, "dropped events: %ld\n", cnt);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/core] tracing: Format non-nanosec times from tsc clock without a decimal point.
Commit-ID: 8be0709f10e3dd5d7d07933ad61a9f18c4b93ca5
Gitweb: http://git.kernel.org/tip/8be0709f10e3dd5d7d07933ad61a9f18c4b93ca5
Author: David Sharp
AuthorDate: Tue, 13 Nov 2012 12:18:22 -0800
Committer: Steven Rostedt
CommitDate: Tue, 13 Nov 2012 15:48:40 -0500
tracing: Format non-nanosec times from tsc clock without a decimal point.
With the addition of the "tsc" clock, formatting timestamps to look like
fractional seconds is misleading. Mark clocks as either in nanoseconds or
not, and format non-nanosecond timestamps as decimal integers.
Tested:
$ cd /sys/kernel/debug/tracing/
$ cat trace_clock
[local] global tsc
$ echo sched_switch > set_event
$ echo 1 > tracing_on ; sleep 0.0005 ; echo 0 > tracing_on
$ cat trace
-0 [000] 6330.52: sched_switch: prev_comm=swapper
prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash next_pid=29964
next_prio=120
sleep-29964 [000] 6330.555628: sched_switch: prev_comm=bash
prev_pid=29964 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0
next_prio=120
...
$ echo 1 > options/latency-format
$ cat trace
-0 0 4104553247us+: sched_switch: prev_comm=swapper prev_pid=0
prev_prio=120 prev_state=R ==> next_comm=bash next_pid=29964 next_prio=120
sleep-29964 0 4104553322us+: sched_switch: prev_comm=bash prev_pid=29964
prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120
...
$ echo tsc > trace_clock
$ cat trace
$ echo 1 > tracing_on ; sleep 0.0005 ; echo 0 > tracing_on
$ echo 0 > options/latency-format
$ cat trace
-0 [000] 16490053398357: sched_switch: prev_comm=swapper
prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=bash next_pid=31128
next_prio=120
sleep-31128 [000] 16490053588518: sched_switch: prev_comm=bash
prev_pid=31128 prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0
next_prio=120
...
echo 1 > options/latency-format
$ cat trace
-0 0 91557653238+: sched_switch: prev_comm=swapper prev_pid=0
prev_prio=120 prev_state=R ==> next_comm=bash next_pid=31128 next_prio=120
sleep-31128 0 91557843399+: sched_switch: prev_comm=bash prev_pid=31128
prev_prio=120 prev_state=S ==> next_comm=swapper next_pid=0 next_prio=120
...
v2:
Move arch-specific bits out of generic code.
v4:
Fix x86_32 build due to 64-bit division.
Google-Bug-Id: 6980623
Link:
http://lkml.kernel.org/r/1352837903-32191-2-git-send-email-dhsh...@google.com
Cc: Masami Hiramatsu
Signed-off-by: David Sharp
Signed-off-by: Steven Rostedt
---
arch/x86/include/asm/trace_clock.h | 2 +-
include/linux/ftrace_event.h | 6 +++
kernel/trace/trace.c | 15 ++--
kernel/trace/trace.h | 4 --
kernel/trace/trace_output.c| 78 ++
5 files changed, 72 insertions(+), 33 deletions(-)
diff --git a/arch/x86/include/asm/trace_clock.h
b/arch/x86/include/asm/trace_clock.h
index 5c16527..beab86c 100644
--- a/arch/x86/include/asm/trace_clock.h
+++ b/arch/x86/include/asm/trace_clock.h
@@ -9,7 +9,7 @@
extern u64 notrace trace_clock_x86_tsc(void);
# define ARCH_TRACE_CLOCKS \
- { trace_clock_x86_tsc, "x86-tsc" },
+ { trace_clock_x86_tsc, "x86-tsc", .in_ns = 0 },
#else /* !CONFIG_X86_TSC */
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index b80c8dd..a3d4895 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -86,6 +86,12 @@ struct trace_iterator {
cpumask_var_t started;
};
+enum trace_iter_flags {
+ TRACE_FILE_LAT_FMT = 1,
+ TRACE_FILE_ANNOTATE = 2,
+ TRACE_FILE_TIME_IN_NS = 4,
+};
+
struct trace_event;
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 0d20620..d943e69 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -484,10 +484,11 @@ static const char *trace_options[] = {
static struct {
u64 (*func)(void);
const char *name;
+ int in_ns; /* is this clock in nanoseconds? */
} trace_clocks[] = {
- { trace_clock_local,"local" },
- { trace_clock_global, "global" },
- { trace_clock_counter, "counter" },
+ { trace_clock_local,"local",1 },
+ { trace_clock_global, "global", 1 },
+ { trace_clock_counter, "counter", 0 },
ARCH_TRACE_CLOCKS
};
@@ -2478,6 +2479,10 @@ __tracing_open(struct inode *inode, struct file *file)
if (ring_buffer_overruns(iter->tr->buffer))
iter->iter_flags |= TRACE_FILE_ANNOTATE;
+ /* Output in nanoseconds only if we are using a clock in nanoseconds. */
+ if (trace_clocks[trace_clock_id].in_ns)
+ iter->iter_flags |= TRACE_FILE_TIME_IN_NS;
+
/* stop the trace while dumping */
tracing_stop();
@@ -3339,6 +3344,10 @@ static int tracing_open_pipe(struct inode *inode, struct
file *filp)
if (trace_flags & TRACE_ITER_LATENCY_FMT)
[tip:perf/core] tracing,x86: Add a TSC trace_clock
Commit-ID: 8cbd9cc6254065c97c4bac42daa55ba1abe73a8e Gitweb: http://git.kernel.org/tip/8cbd9cc6254065c97c4bac42daa55ba1abe73a8e Author: David Sharp AuthorDate: Tue, 13 Nov 2012 12:18:21 -0800 Committer: Steven Rostedt CommitDate: Tue, 13 Nov 2012 15:48:27 -0500 tracing,x86: Add a TSC trace_clock In order to promote interoperability between userspace tracers and ftrace, add a trace_clock that reports raw TSC values which will then be recorded in the ring buffer. Userspace tracers that also record TSCs are then on exactly the same time base as the kernel and events can be unambiguously interlaced. Tested: Enabled a tracepoint and the "tsc" trace_clock and saw very large timestamp values. v2: Move arch-specific bits out of generic code. v3: Rename "x86-tsc", cleanups v7: Generic arch bits in Kbuild. Google-Bug-Id: 6980623 Link: http://lkml.kernel.org/r/1352837903-32191-1-git-send-email-dhsh...@google.com Acked-by: Ingo Molnar Cc: Masami Hiramatsu Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Signed-off-by: David Sharp Signed-off-by: Steven Rostedt --- arch/alpha/include/asm/Kbuild | 1 + arch/arm/include/asm/Kbuild| 1 + arch/arm64/include/asm/Kbuild | 1 + arch/avr32/include/asm/Kbuild | 1 + arch/blackfin/include/asm/Kbuild | 1 + arch/c6x/include/asm/Kbuild| 1 + arch/cris/include/asm/Kbuild | 1 + arch/frv/include/asm/Kbuild| 1 + arch/h8300/include/asm/Kbuild | 1 + arch/hexagon/include/asm/Kbuild| 1 + arch/ia64/include/asm/Kbuild | 1 + arch/m32r/include/asm/Kbuild | 1 + arch/m68k/include/asm/Kbuild | 1 + arch/microblaze/include/asm/Kbuild | 1 + arch/mips/include/asm/Kbuild | 1 + arch/mn10300/include/asm/Kbuild| 1 + arch/openrisc/include/asm/Kbuild | 1 + arch/parisc/include/asm/Kbuild | 1 + arch/powerpc/include/asm/Kbuild| 1 + arch/s390/include/asm/Kbuild | 1 + arch/score/include/asm/Kbuild | 1 + arch/sh/include/asm/Kbuild | 1 + arch/sparc/include/asm/Kbuild | 1 + arch/tile/include/asm/Kbuild | 1 + arch/um/include/asm/Kbuild | 1 + arch/unicore32/include/asm/Kbuild | 1 + arch/x86/include/asm/trace_clock.h | 20 arch/x86/kernel/Makefile | 1 + arch/x86/kernel/trace_clock.c | 21 + arch/xtensa/include/asm/Kbuild | 1 + include/asm-generic/trace_clock.h | 16 include/linux/trace_clock.h| 2 ++ kernel/trace/trace.c | 1 + 33 files changed, 88 insertions(+) diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild index 64ffc9e..dcfabb9 100644 --- a/arch/alpha/include/asm/Kbuild +++ b/arch/alpha/include/asm/Kbuild @@ -11,3 +11,4 @@ header-y += reg.h header-y += regdef.h header-y += sysinfo.h generic-y += exec.h +generic-y += trace_clock.h diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index f70ae17..514e398 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -31,5 +31,6 @@ generic-y += sockios.h generic-y += termbits.h generic-y += termios.h generic-y += timex.h +generic-y += trace_clock.h generic-y += types.h generic-y += unaligned.h diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index a581a22..6e9ca46 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -43,6 +43,7 @@ generic-y += swab.h generic-y += termbits.h generic-y += termios.h generic-y += topology.h +generic-y += trace_clock.h generic-y += types.h generic-y += unaligned.h generic-y += user.h diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild index 4807ded..4dd4f78 100644 --- a/arch/avr32/include/asm/Kbuild +++ b/arch/avr32/include/asm/Kbuild @@ -1,3 +1,4 @@ generic-y += clkdev.h generic-y += exec.h +generic-y += trace_clock.h diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild index 5a0625a..27d7075 100644 --- a/arch/blackfin/include/asm/Kbuild +++ b/arch/blackfin/include/asm/Kbuild @@ -38,6 +38,7 @@ generic-y += statfs.h generic-y += termbits.h generic-y += termios.h generic-y += topology.h +generic-y += trace_clock.h generic-y += types.h generic-y += ucontext.h generic-y += unaligned.h diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild index 112a496..eae7b59 100644 --- a/arch/c6x/include/asm/Kbuild +++ b/arch/c6x/include/asm/Kbuild @@ -49,6 +49,7 @@ generic-y += termbits.h generic-y += termios.h generic-y += tlbflush.h generic-y += topology.h +generic-y += trace_clock.h generic-y += types.h generic-y += ucontext.h generic-y += user.h diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild index 6d43a95..15a122c 100644 --- a/arch/cris/include/asm/Kbuild +++ b/arch/cris/include/asm/Kbuild @@ -11,3 +11,4 @@ header-y += sync_serial.h generic-y += clkdev.h generic-y += exec.h
Re: [PATCH] Expand CPU compiler options
On Sat, Dec 08, 2012 at 04:13:59AM -0800, John wrote: > I tested the attached patch written by André Ramnitz using three > different machines running a generic x86-64 kernel and an otherwise > identical kernel running with the optimized gcc options. > > Conclusion: There are small but real speed increases using a make > endpoint to running with this patch. > > Details: 1) Three test machines: Intel Xeon X3360, Intel i7-2620M, > Intel Core i7-3660K. > > 2) All ran the make benchmark (linked below) 35 times while booted > into a 'generic' kernel. Then all ran the same make benchmark > 35 times after booting into an optimized kernel. Below are the > optimizations chosen for each machine. 2a) X3360 = core2 2b) > i7-2620M = corei7-avx 2c) i7-3660K = core-avx-i 3) Analyzed > resulting distributions for statistical significance via ANOVA > plots that clearly show statistically significant albeit small > differences. > > Links to ANOVA plots: > http://s19.postimage.org/68urcofzn/corei7_avx.png > http://s19.postimage.org/ozwomuak3/core_avx_i.png > > http://s19.postimage.org/d0l6fj4z7/core2.png > > > References: > > Bash script that controls the > benchmark: https://github.com/graysky2/bin/blob/master/bench > Log file generated by script: > http://repo-ck.com/bench/compile_time_optimization.txt.gz Let's see, if I'm reading the log file correctly, the average values of each test run differ by ~ 0.1 seconds tops. For example, i7-3770K generic build gives on average 69.41404 while the more optimized version 69.33554. The diff between the two is even less than 0.1 second. The other two machines' diff is a bit higher. And from looking at your graphs, this is all eaten up by stddev so I'd say there aren't any improvements from using a different uarch target - just noise. AFAICT, at least. You could trace this same workload with perf as I told you originally to see whether there are some other uarch benefits, and have a more precise time measurement than using 'date' but I'm very sceptical. In any case, these results are too marginal to warrant any code change since they're basically disappearing in noise. Btw, you might look into what optimizations exactly went into those different compiler options - they might not be improving a lot, if at all, performance-wise but be adding support for new instructions, etc, etc, i.e. features which are not related to performance. And if that is the case, there's no need for those different uarch build targets in the kernel. Remember, the majority of linux kernels out there are generic-x86_64 builds. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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-rc8 boot failure due to recent workqueue-related patch
On Sat, Dec 08, 2012 at 04:50:21PM -0800, Linus Torvalds wrote: > > > On Sat, 8 Dec 2012, Mel Gorman wrote: > > > > Commit 8852aac2 (workqueue: mod_delayed_work_on() shouldn't queue timer on > > 0 delay) is causing the following boot failure for me. Found by bisection > > but no further analysis unfortunately until I get back home properly. > > I've added the relevant maintainers for megasas and SCSI in case it's > > somehow specific to that driver. > > This should be fixed by commit c1d390d8e612. The Megaraid SAS driver was > doing insane things, using a work-struct for delayed work, and casting > pointers around. It had happened to work for all the wrong reasons before, > the mod_delayed_work_on() changes just exposed how crazy that crap was. > Correct, it is fixed by commit c1d390d8e612. Sorry for the noise. -- Mel Gorman 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 1/5] rtl8712: code clean up
Clean some trivial formating problems in rtl8712 from staging tree. This patch
also changes the way preprocessor macros are defined to keep checkpatch.pl
quiet.
Signed-off-by: Przemo Firszt
---
drivers/staging/rtl8712/ieee80211.h| 2 +-
drivers/staging/rtl8712/rtl871x_cmd.h | 2 +-
drivers/staging/rtl8712/rtl871x_security.h | 6 +-
drivers/staging/rtl8712/sta_info.h | 2 +-
drivers/staging/rtl8712/wifi.h | 167 +
5 files changed, 79 insertions(+), 100 deletions(-)
diff --git a/drivers/staging/rtl8712/ieee80211.h
b/drivers/staging/rtl8712/ieee80211.h
index 21515c3..da4000e 100644
--- a/drivers/staging/rtl8712/ieee80211.h
+++ b/drivers/staging/rtl8712/ieee80211.h
@@ -777,7 +777,7 @@ extern inline int ieee80211_get_hdrlen(u16 fc)
struct registry_priv;
u8 *r8712_set_ie(u8 *pbuf, sint index, uint len, u8 *source, uint *frlen);
-u8 *r8712_get_ie(u8*pbuf, sint index, sint *len, sint limit);
+u8 *r8712_get_ie(u8 *pbuf, sint index, sint *len, sint limit);
unsigned char *r8712_get_wpa_ie(unsigned char *pie, int *rsn_ie_len, int
limit);
unsigned char *r8712_get_wpa2_ie(unsigned char *pie, int *rsn_ie_len,
int limit);
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.h
b/drivers/staging/rtl8712/rtl871x_cmd.h
index 9d93189..0ce79b1 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.h
+++ b/drivers/staging/rtl8712/rtl871x_cmd.h
@@ -749,7 +749,7 @@ u8 r8712_setopmode_cmd(struct _adapter *padapter,
u8 r8712_setdatarate_cmd(struct _adapter *padapter, u8 *rateset);
u8 r8712_set_chplan_cmd(struct _adapter *padapter, int chplan);
u8 r8712_setbasicrate_cmd(struct _adapter *padapter, u8 *rateset);
-u8 r8712_getrfreg_cmd(struct _adapter *padapter, u8 offset, u8 * pval);
+u8 r8712_getrfreg_cmd(struct _adapter *padapter, u8 offset, u8 *pval);
u8 r8712_setrfintfs_cmd(struct _adapter *padapter, u8 mode);
u8 r8712_setrfreg_cmd(struct _adapter *padapter, u8 offset, u32 val);
u8 r8712_setrttbl_cmd(struct _adapter *padapter,
diff --git a/drivers/staging/rtl8712/rtl871x_security.h
b/drivers/staging/rtl8712/rtl871x_security.h
index a13395f..c732aea 100644
--- a/drivers/staging/rtl8712/rtl871x_security.h
+++ b/drivers/staging/rtl8712/rtl871x_security.h
@@ -207,9 +207,9 @@ void seccalctkipmic(
u8 *Miccode,
u8 priority);
-void r8712_secmicsetkey(struct mic_data *pmicdata, u8 * key);
-void r8712_secmicappend(struct mic_data *pmicdata, u8 * src, u32 nBytes);
-void r8712_secgetmic(struct mic_data *pmicdata, u8 * dst);
+void r8712_secmicsetkey(struct mic_data *pmicdata, u8 *key);
+void r8712_secmicappend(struct mic_data *pmicdata, u8 *src, u32 nBytes);
+void r8712_secgetmic(struct mic_data *pmicdata, u8 *dst);
u32 r8712_aes_encrypt(struct _adapter *padapter, u8 *pxmitframe);
u32 r8712_tkip_encrypt(struct _adapter *padapter, u8 *pxmitframe);
void r8712_wep_encrypt(struct _adapter *padapter, u8 *pxmitframe);
diff --git a/drivers/staging/rtl8712/sta_info.h
b/drivers/staging/rtl8712/sta_info.h
index f8016e9..c4e0ef2 100644
--- a/drivers/staging/rtl8712/sta_info.h
+++ b/drivers/staging/rtl8712/sta_info.h
@@ -140,7 +140,7 @@ void r8712_free_all_stainfo(struct _adapter *padapter);
struct sta_info *r8712_get_stainfo(struct sta_priv *pstapriv, u8 *hwaddr);
void r8712_init_bcmc_stainfo(struct _adapter *padapter);
struct sta_info *r8712_get_bcmc_stainfo(struct _adapter *padapter);
-u8 r8712_access_ctrl(struct wlan_acl_pool *pacl_list, u8 * mac_addr);
+u8 r8712_access_ctrl(struct wlan_acl_pool *pacl_list, u8 *mac_addr);
#endif /* _STA_INFO_H_ */
diff --git a/drivers/staging/rtl8712/wifi.h b/drivers/staging/rtl8712/wifi.h
index 793443e..c08ed2a 100644
--- a/drivers/staging/rtl8712/wifi.h
+++ b/drivers/staging/rtl8712/wifi.h
@@ -159,99 +159,85 @@ enum WIFI_REG_DOMAIN {
#define _PRIVACY_ BIT(14)
#define _ORDER_BIT(15)
-#define SetToDs(pbuf) \
- do { \
- *(unsigned short *)(pbuf) |= cpu_to_le16(_TO_DS_); \
- } while (0)
+#define SetToDs(pbuf) ({ \
+ *(unsigned short *)(pbuf) |= cpu_to_le16(_TO_DS_); \
+})
#define GetToDs(pbuf) (((*(unsigned short *)(pbuf)) & \
le16_to_cpu(_TO_DS_)) != 0)
-#define ClearToDs(pbuf)\
- do { \
- *(unsigned short *)(pbuf) &= (~cpu_to_le16(_TO_DS_)); \
- } while (0)
+#define ClearToDs(pbuf)({ \
+ *(unsigned short *)(pbuf) &= (~cpu_to_le16(_TO_DS_)); \
+})
-#define SetFrDs(pbuf) \
- do { \
- *(unsigned short *)(pbuf) |= cpu_to_le16(_FROM_DS_); \
- } while (0)
+#define SetFrDs(pbuf) ({ \
+ *(unsigned short *)(pbuf) |= cpu_to_le16(_FROM_DS_); \
+})
#define GetFrDs(pbuf) (((*(unsigned short *)(pbuf)) & \
le16_to_cpu(_FROM_DS_)) != 0)
-#define ClearFrDs(pbuf)\
- do { \
- *(unsigned short *)(pbuf) &=
