[tip:x86/urgent] perf/x86/intel: Mark MEM_LOAD_UOPS_MISS_RETIRED as precise on SNB
Commit-ID: 9d8e3f9693245415db0b7c58551a91fa9fd1f9c7
Gitweb: http://git.kernel.org/tip/9d8e3f9693245415db0b7c58551a91fa9fd1f9c7
Author: Stephane Eranian
AuthorDate: Fri, 13 Sep 2013 13:16:46 -0700
Committer: Ingo Molnar
CommitDate: Sat, 14 Sep 2013 08:00:18 +0200
perf/x86/intel: Mark MEM_LOAD_UOPS_MISS_RETIRED as precise on SNB
On Intel SNB (SNB, SNB-EP), the event MEM_LOAD_UOPS_MISS_RETIRED
supports PEBS. It was missing for the SNB PEBS event constraint
table thereby preventing any measurement with PEBS for it.
This patch adds the event to the PEBS table for SNB.
WARNING: it should be noted that this event like a few others
are subject to the erratum BT241 for Xeon E5 (SNB-EP). As such,
the event may undercount when used with PEBS unless the
workaround is implemented. But without this patch and just the
workaround, the kernel would not allow precise sampling on this
event. BT241 is documented in:
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-family-spec-update.pdf
Signed-off-by: Stephane Eranian
Cc: pet...@infradead.org
Cc: a...@linux.intel.com
Cc: zheng.z@intel.com
Link: http://lkml.kernel.org/r/20130913201646.ga23...@google.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/perf_event_intel_ds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 3065c57..4ab70ac 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -558,6 +558,7 @@ struct event_constraint intel_snb_pebs_event_constraints[]
= {
INTEL_EVENT_CONSTRAINT(0xd0, 0xf),/* MEM_UOP_RETIRED.* */
INTEL_EVENT_CONSTRAINT(0xd1, 0xf),/* MEM_LOAD_UOPS_RETIRED.* */
INTEL_EVENT_CONSTRAINT(0xd2, 0xf),/*
MEM_LOAD_UOPS_LLC_HIT_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0xd3, 0xf),/*
MEM_LOAD_UOPS_LLC_MISS_RETIRED.* */
INTEL_UEVENT_CONSTRAINT(0x02d4, 0xf), /*
MEM_LOAD_UOPS_MISC_RETIRED.LLC_MISS */
EVENT_CONSTRAINT_END
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/urgent] x86/intel/lpss: Add pin control support to Intel low power subsystem
Commit-ID: 0f531431d3de88efb4234d6c0ce22089ec035a38 Gitweb: http://git.kernel.org/tip/0f531431d3de88efb4234d6c0ce22089ec035a38 Author: Mathias Nyman AuthorDate: Fri, 13 Sep 2013 17:02:29 +0300 Committer: Ingo Molnar CommitDate: Sat, 14 Sep 2013 08:06:28 +0200 x86/intel/lpss: Add pin control support to Intel low power subsystem x86 chips with LPSS (low power subsystem) such as Lynxpoint and Baytrail have SoC like peripheral support and controllable pins. At the moment, Baytrail needs the pinctrl-baytrail driver to let peripherals control their gpio resources, but more pincontrol functions such as pin muxing and grouping are possible to add later. Signed-off-by: Mathias Nyman Reviewed-by: Mika Westerberg Cc: Rafael J. Wysocki Link: http://lkml.kernel.org/r/1379080949-21734-1-git-send-email-mathias.ny...@linux.intel.com Signed-off-by: Ingo Molnar --- arch/x86/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b32ebf9..4d5843d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -482,11 +482,12 @@ config X86_INTEL_LPSS bool "Intel Low Power Subsystem Support" depends on ACPI select COMMON_CLK + select PINCTRL ---help--- Select to build support for Intel Low Power Subsystem such as found on Intel Lynxpoint PCH. Selecting this option enables - things like clock tree (common clock framework) which are needed - by the LPSS peripheral drivers. + things like clock tree (common clock framework) and pincontrol + which are needed by the LPSS peripheral drivers. config X86_RDC321X bool "RDC R-321x SoC" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 alt 4/4] pinctrl: at91: rework debounce configuration
Hello Stephen,
Le 14/09/2013 00:40, Stephen Warren a écrit :
On 09/13/2013 01:53 AM, Boris BREZILLON wrote:
AT91 SoCs do not support per pin debounce time configuration.
Instead you have to configure a debounce time which will be used for all
pins of a given bank (PIOA, PIOB, ...).
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+Optional properties for iomux controller:
+- atmel,default-debounce-div: array of debounce divisors (one divisor per bank)
+ which describes the debounce timing in use for all pins of a given bank
+ configured with the DEBOUNCE option (see the following description).
+ Debounce timing is obtained with this formula:
+ Tdebounce = 2 * (debouncediv + 1) / Fslowclk
+ with Fslowclk = 32KHz
+
Required properties for pin configuration node:
- atmel,pins: 4 integers array, represents a group of pins mux and config
setting. The format is atmel,pins = .
@@ -91,7 +99,6 @@ DEGLITCH (1 << 2): indicate this pin need deglitch.
PULL_DOWN (1 << 3): indicate this pin need a pull down.
DIS_SCHMIT(1 << 4): indicate this pin need to disable schmit trigger.
DEBOUNCE (1 << 16): indicate this pin need debounce.
-DEBOUNCE_VAL (0x3fff << 17): debounce val.
This change would break the DT ABI since it removes a feature that's
already present.
I missed this point in my cons list.
This won't be an issue for in kernel DT definitions (nobody is currently
using the
DEBOUCE option), but may be for out-of-tree DT definitions.
I suppose it's still up to the Atmel maintainers to decide whether this
is appropriate, or whether the impact to out-of-tree DT files would be
problematic.
Assuming the DT ABI can be broken, I think I'd prefer to do so, rather
than take "non-alt" patch 4/4, since a per-pin DEBOUNCE_VAL clearly
doesn't correctly model the HW, assuming the patch description is
correct. I don't think arguments re: the generic pinconf debounce
property hold; if the Linux-specific/internal generic property doesn't
apply, the DT binding should not be bent to adjust to it, but should
rather still represent the HW itself.
What about the last point in my list: "reconfigure debounce after startup" ?
Here is an example that may be problematic:
Let's say you have one device using multiple configuration of pins
("default", "xxx", "yyy").
The "default" config needs a particular debounce time on a given pin and
the "xxx" and "yyy"
configs need different debounce time on the same pin.
How would you solve this with this patch approach ?
Best Regards,
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: dev->of_node overwrite can cause device loading with different driver
On Fri, Sep 13, 2013 at 10:10:46AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Sep 13, 2013 at 05:53:31PM +0200, Markus Pargmann wrote:
> > Hi,
> >
> > I ran into a serious problem with overwriting device of_node property as
> > it is done in many drivers for ARM. If probing fails in such a
> > situation, the device could be loaded with a different driver.
> >
> > This is an example situation, based on balbi's tag usb-for-v3.12:
> >
> >
> > File drivers/usb/musb/musb_dsps.c:
> >
> > static int dsps_musb_init(struct musb *musb)
> > {
> > ...
> > musb->xceiv = devm_usb_get_phy_by_phandle(dev, "phys", 0);
> > if (IS_ERR(musb->xceiv))
> > return PTR_ERR(musb->xceiv); <-- This can return -EPROBE_DEFER
> > ...
> > }
> > ...
> > static int dsps_create_musb_pdev(struct dsps_glue *glue,
> > struct platform_device *parent)
> > {
> > ...
> > /* allocate the child platform device */
> > musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);
> > if (!musb) {
> > dev_err(dev, "failed to allocate musb device\n");
> > return -ENOMEM;
> > }
> >
> > musb->dev.parent= dev;
> > musb->dev.dma_mask = &musb_dmamask;
> > musb->dev.coherent_dma_mask = musb_dmamask;
> > musb->dev.of_node = of_node_get(dn); <-- Overwrites the
> > device of_node
> > ...
> > ret = platform_device_add(musb);
> > ...
> > }
> > static int dsps_probe(struct platform_device *pdev)
> > {
> > ...
> > ret = dsps_create_musb_pdev(glue, pdev);
> > ...
> > }
> >
> >
> > File drivers/usb/musb/musb_core.c:
> >
> > static int
> > musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
> > {
> > ...
> > status = musb_platform_init(musb); <-- This calls dsps_musb_init
> > if (status < 0)
> > goto fail1;
> > ...
> > return status;
> >
> > }
> > static int musb_probe(struct platform_device *pdev)
> > {
> > ...
> > return musb_init_controller(dev, irq, base);
> > }
> >
> >
> >
> > musb_dsps is a glue driver that creates a core device in the probe
> > function and assigns it's own of_node to the new device.
> > Starting at the platform_device_add call, this is the function call
> > tree:
> >
> > platform_device_add()
> >
> > ...
> >
> > device_attach() in drivers/base/dd.c, which iterates through a list of
> > drivers, calls __device_attach() on each of them. The list contains both
> > drivers, musb_dsps and musb_core. This is where this example splits into
> > two cases:
> >
> > 1. We find the first matching driver, musb_dsps:
> >
> > __device_attach()
> > platform_match() /* for the musb_core, detecting a match. */
> > driver_probe_device()
> > really_probe()
> > musb_probe() is called, which returns -EPROBE_DEFER
> >
> > /* really_probe drops the return value and makes some cleanups
> > */
> >
> > 2. The error code does not reach the driver list iteration loop. It
> > is not supposed to do so because the drivercore tries to find another
> > matching driver. Now it tries the musb_dsps driver:
> >
> > __device_attach()
> > platform_match()
> > /* succeeds again, because the device has the
> >of_node from its parent which claims that this
> >is a musb_dsps device. */
> > driver_probe_device()
> > really_probe()
> > dsps_probe() ... /* from here on it starts from the
> > beginning. */
> >
> > This recursion continued until the kernel had no memory left. This is a
> > special situation but there are many drivers that overwrite the of_node
> > property in their probe function. So they can actually match with a
> > different driver on the second or third probe attempt.
>
> Ok, so what do you suggest we do for stuff like this? Fix up the musb
> driver? Or something else?
I think there are three options to solve this:
1. Break out of the driver list iteration loop as soon as a driver probe
function fails. This way there is no possibility for another driver
to be probed with a device struct that was changed by the first
driver. But it would remove the support to fall back to
another driver for a device. I am not aware of any device that is
supported by multiple drivers.
2. We could restore the device struct completely or partially (only
of_node) after a probe failure. This would avoid driver probes with
unclean device structs, but introduces some overhead.
3. We could fix up all drivers that change the of_node. But there are
ARM DT frameworks that require a device struct as parameter instead
of a device_node parameter (e.g. soc-generic-dmaengine-pcm). So a
drive
[PATCH] argv_split: Return NULL if argument contains no non-whitespace.
>From 210f917f3b535bc0d4dcbb20ca4395709e913104 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 14 Sep 2013 16:24:07 +0900
Subject: [PATCH] argv_split: Return NULL if argument contains no non-whitespace.
I tried
# echo '|' > /proc/sys/kernel/core_pattern
and got
BUG: unable to handle kernel NULL pointer dereference at (null)
upon core dump because helper_argv[0] == NULL at
helper_argv = argv_split(GFP_KERNEL, cn.corename, NULL);
call_usermodehelper_setup(helper_argv[0], ...);
if cn.corename == "".
How to check this bug:
# echo '|' > /proc/sys/kernel/core_pattern
$ echo 'int main(int argc, char *argv[]) { return *(char *) 0; }' | gcc -x c
- -o die
$ ulimit -c unlimited
$ ./die
This bug seems to exist since 2.6.19 (the version which core dump to pipe was
added). Depending on kernel version and config, some side effect might follow
immediately after this oops (e.g. kernel panic with 2.6.32-358.18.1.el6).
Assuming that nobody is expecting that argv_split() returns an array with
argv[0] == NULL, this patch fixes this bug by changing argv_split() to return
NULL if argument contains no non-whitespace.
Signed-off-by: Tetsuo Handa
---
lib/argv_split.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/lib/argv_split.c b/lib/argv_split.c
index e927ed0..5b828d9 100644
--- a/lib/argv_split.c
+++ b/lib/argv_split.c
@@ -50,7 +50,7 @@ EXPORT_SYMBOL(argv_free);
* quote processing is performed. Multiple whitespace characters are
* considered to be a single argument separator. The returned array
* is always NULL-terminated. Returns NULL on memory allocation
- * failure.
+ * failure or @str being empty or @str containing only white-space.
*
* The source string at `str' may be undergoing concurrent alteration via
* userspace sysctl activity (at least). The argv_split() implementation
@@ -68,6 +68,10 @@ char **argv_split(gfp_t gfp, const char *str, int *argcp)
return NULL;
argc = count_argc(argv_str);
+ if (!argc) {
+ kfree(argv_str);
+ return NULL;
+ }
argv = kmalloc(sizeof(*argv) * (argc + 2), gfp);
if (!argv) {
kfree(argv_str);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 211/228] cpufreq: tegra: remove calls to cpufreq_notify_transition()
On Sat, Sep 14, 2013 at 09:39:31AM +0530, Viresh Kumar wrote: > On 14 September 2013 04:22, Stephen Warren wrote: > > I wonder if this series is bisectable? Perhaps I should just go and read > > the rest of the series, but I presume there's a patch somewhere else > > that adds those two cpufreq_notify_transition() to the cpufreq core. > > Either that happens before this patch (in which case listeners will get > > two notifications each time; perhaps that is safe?), or after this patch > > (in which case with just this patch applied, no notifications will be > > sent until a later patch! > > Hmm.. Good Catch.. > > So, yes git bisect would be compilable but not runnable.. As we are > already serialized notifications and so two PRE notifications will > generate a crash.. > > But I don't want to get all that in a single patch as that would be: > > 40 files changed, 192 insertions(+), 623 deletions(-) > > And that would be hard to review it.. > > Any suggestions? > It reminds me time of removing CONFIG_HOTPLUG and following __dev* attributes. At least stats for 48c68c4 "Drivers: video: remove __dev* attributes" is: 135 files changed, 1017 insertions(+), 1129 deletions(-) Maybe coccinelle script, which maintainers could run it on their trees, would help? Vladimir > > Aside from that, all the Tegra-specific patches in this series, > > Acked-by: Stephen Warren > > Thanks.. > > ___ > linaro-kernel mailing list > linaro-ker...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: si570: Add a driver for SI570 oscillators
On 09/13/2013 07:26 PM, Sören Brinkmann wrote: On Fri, Sep 13, 2013 at 10:00:05AM -0700, Guenter Roeck wrote: On Thu, Sep 12, 2013 at 05:55:37PM -0700, Soren Brinkmann wrote: Add a driver for SILabs 570, 571, 598, 599 programmable oscillators. The devices generate low-jitter clock signals and are reprogrammable via an I2C interface. Cc: Guenter Roeck Signed-off-by: Soren Brinkmann --- [...] diff --git a/drivers/clk/clk-si570.c b/drivers/clk/clk-si570.c new file mode 100644 index 000..960d689 --- /dev/null +++ b/drivers/clk/clk-si570.c @@ -0,0 +1,546 @@ [...] + match = of_match_node(clk_si570_of_match, client->dev.of_node); + if (!match) + return -EINVAL; Seems unusual. Is this really needed ? It precludes the driver from being used in a non-devicetree environment, for example. I would guess that there is a match if client->dev.of_node is set. Otherwise, this code would be needed in every driver supporting devicetree, and I don't recall seeing that. + ddata = match->data; + You should be able to get this information (ie the pointer to si570_device_data) from id->driver_data. That would be more consistent with other i2c devices. I think I copied this approach from the other clk-si... driver. I'll do some research on your suggestion and change it. Could you point me to an example for your proposal? Soeren, I sent a patch for the match removal in clk-si5351 [1]. Mike must have missed it, I will resend soon. You can take that as "an example for the proposal" above. Sebastian [1] https://lkml.org/lkml/2013/9/3/484 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ptp: measure the time offset between PHC and system clock
This patch add a method into testptp.c to measure the time offset
between phc and system clock through the ioctl PTP_SYS_OFFSET.
Signed-off-by: Dong Zhu
---
Documentation/ptp/testptp.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
index f59ded0..72bb030 100644
--- a/Documentation/ptp/testptp.c
+++ b/Documentation/ptp/testptp.c
@@ -112,6 +112,7 @@ static void usage(char *progname)
" -f val adjust the ptp clock frequency by 'val' ppb\n"
" -g get the ptp clock time\n"
" -h prints this message\n"
+ " -k val measure the time offset between PHC and system
clock\n"
" -p val enable output with a period of 'val' nanoseconds\n"
" -P val enable or disable (val=1|0) the system clock PPS\n"
" -s set the ptp clock time from the system time\n"
@@ -133,8 +134,12 @@ int main(int argc, char *argv[])
struct itimerspec timeout;
struct sigevent sigevent;
+ struct ptp_clock_time *pct;
+ struct ptp_sys_offset *sysoff;
+
+
char *progname;
- int c, cnt, fd;
+ int i, c, cnt, fd;
char *device = DEVICE;
clockid_t clkid;
@@ -144,6 +149,8 @@ int main(int argc, char *argv[])
int extts = 0;
int gettime = 0;
int oneshot = 0;
+ int offset = 0;
+ int n_samples = 0;
int periodic = 0;
int perout = -1;
int pps = -1;
@@ -151,7 +158,7 @@ int main(int argc, char *argv[])
progname = strrchr(argv[0], '/');
progname = progname ? 1+progname : argv[0];
- while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
+ while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) {
switch (c) {
case 'a':
oneshot = atoi(optarg);
@@ -174,6 +181,10 @@ int main(int argc, char *argv[])
case 'g':
gettime = 1;
break;
+ case 'k':
+ offset = 1;
+ n_samples = atoi(optarg);
+ break;
case 'p':
perout = atoi(optarg);
break;
@@ -376,6 +387,31 @@ int main(int argc, char *argv[])
}
}
+ if (offset) {
+ sysoff = calloc(1, sizeof(*sysoff));
+ if (!sysoff) {
+ perror("calloc");
+ return -1;
+ }
+ sysoff->n_samples = n_samples;
+
+ if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
+ perror("PTP_SYS_OFFSET");
+ else
+ puts("time offset between PHC and
+system clock request okay");
+
+ pct = &sysoff->ts[0];
+ for (i = 0; i < sysoff->n_samples; i++, pct++) {
+ printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
+ pct++;
+ printf("phctime: %ld.%ld\n\n", pct->sec, pct->nsec);
+ }
+ printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
+
+ free(sysoff);
+ }
+
close(fd);
return 0;
}
--
1.7.11.7
--
Best Regards,
Dong Zhu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tools/perf: add new option --ignore-vmlinux for perf top
Running "perf top" on a machine with possibly invalid or non-matching
vmlinux at the various places results in no symbol resolving despite
/proc/kallsyms being present and valid.
Add a new option --ignore-vmlinux to explicitly indicate that we do
not want to use these kernels and just use what we have (kallsyms).
Signed-off-by: Willy Tarreau
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
---
Hey guys, I found that I'm still regularly rebasing this patch
on new kernels. It would be nice if it could be merged, as it
causes some burden on some production machines which have old
vmlinux files at several places that we don't always want to
risk removing just for running perf top.
tools/perf/builtin-top.c | 2 ++
tools/perf/util/symbol.c | 4 ++--
tools/perf/util/symbol.h | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index e06c4f8..6e7fef7 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1067,6 +1067,8 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
"list of cpus to monitor"),
OPT_STRING('k', "vmlinux", &symbol_conf.vmlinux_name,
"file", "vmlinux pathname"),
+ OPT_BOOLEAN(0, "ignore-vmlinux", &symbol_conf.ignore_vmlinux,
+ "don't load vmlinux even if found"),
OPT_BOOLEAN('K', "hide_kernel_symbols", &top.hide_kernel_symbols,
"hide kernel symbols"),
OPT_UINTEGER('m', "mmap-pages", &opts->mmap_pages,
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index d5528e1..7eab65a 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -968,7 +968,7 @@ static int dso__load_kernel_sym(struct dso *dso, struct map
*map,
goto do_kallsyms;
}
- if (symbol_conf.vmlinux_name != NULL) {
+ if (!symbol_conf.ignore_vmlinux && symbol_conf.vmlinux_name != NULL) {
err = dso__load_vmlinux(dso, map,
symbol_conf.vmlinux_name, filter);
if (err > 0) {
@@ -980,7 +980,7 @@ static int dso__load_kernel_sym(struct dso *dso, struct map
*map,
return err;
}
- if (vmlinux_path != NULL) {
+ if (!symbol_conf.ignore_vmlinux && vmlinux_path != NULL) {
err = dso__load_vmlinux_path(dso, map, filter);
if (err > 0)
goto out_fixup;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 5f720dc..3346d09 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -85,6 +85,7 @@ struct symbol_conf {
unsigned short priv_size;
unsigned short nr_events;
booltry_vmlinux_path,
+ ignore_vmlinux,
show_kernel_path,
use_modules,
sort_by_name,
--
1.7.12.2.21.g234cd45.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [RFC v2] seqcount: Add lockdep functionality to seqcount/seqlock structures
On 2013/9/14 8:19, John Stultz wrote: > Currently seqlocks and seqcounts don't support lockdep. > > After running across a seqcount related deadlock in the timekeeping > code, I used a less-refined and more focused varient of this patch > to narrow down the cause of the issue. > > This is a first-pass attempt to properly enable lockdep functionality > on seqlocks and seqcounts. > > Since seqcounts are used in the vdso gettimeofday code, I've provided > lockdep accessors. > > I've also handled one cases where there were nested seqlock writers > and there may be more edge cases. > > Comments and feedback would be appreciated! > Could you describe how seqlocks/seqcounts can lead to deadlock in the changelog? > Cc: Mathieu Desnoyers > Cc: Li Zefan > Cc: Steven Rostedt > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Thomas Gleixner > Signed-off-by: John Stultz > --- > v2: > * Update to new simplified lockdep.h > * vdso accessor simplifications > * removed needless preempt_disable > * removed unneeded ifdefs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [RFC] cpuset: Fix potential deadlock w/ set_mems_allowed
Cc Mel, who added seqcount to cpuset.
On 2013/9/14 8:19, John Stultz wrote:
> After adding lockdep support to seqlock/seqcount structures,
> I started seeing the following warning:
>
> [1.070907] ==
> [1.072015] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
> [1.073181] 3.11.0+ #67 Not tainted
> [1.073801] --
> [1.074882] kworker/u4:2/708 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> [1.076088] (&p->mems_allowed_seq){+.+...}, at: []
> new_slab+0x5f/0x280
> [1.077572]
> [1.077572] and this task is already holding:
> [1.078593] (&(&q->__queue_lock)->rlock){..-...}, at:
> [] blk_execute_rq_nowait+0x53/0xf0
> [1.080042] which would create a new lock dependency:
> [1.080042] (&(&q->__queue_lock)->rlock){..-...} ->
> (&p->mems_allowed_seq){+.+...}
> [1.080042]
> [1.080042] but this new dependency connects a SOFTIRQ-irq-safe lock:
> [1.080042] (&(&q->__queue_lock)->rlock){..-...}
> [1.080042] ... which became SOFTIRQ-irq-safe at:
> [1.080042] [] __lock_acquire+0x5b9/0x1db0
> [1.080042] [] lock_acquire+0x95/0x130
> [1.080042] [] _raw_spin_lock+0x41/0x80
> [1.080042] [] scsi_device_unbusy+0x7e/0xd0
> [1.080042] [] scsi_finish_command+0x32/0xf0
> [1.080042] [] scsi_softirq_done+0xa1/0x130
> [1.080042] [] blk_done_softirq+0x73/0x90
> [1.080042] [] __do_softirq+0x110/0x2f0
> [1.080042] [] run_ksoftirqd+0x2d/0x60
> [1.080042] [] smpboot_thread_fn+0x156/0x1e0
> [1.080042] [] kthread+0xd6/0xe0
> [1.080042] [] ret_from_fork+0x7c/0xb0
> [1.080042]
> [1.080042] to a SOFTIRQ-irq-unsafe lock:
> [1.080042] (&p->mems_allowed_seq){+.+...}
> [1.080042] ... which became SOFTIRQ-irq-unsafe at:
> [1.080042] ... [] __lock_acquire+0x613/0x1db0
> [1.080042] [] lock_acquire+0x95/0x130
> [1.080042] [] kthreadd+0x82/0x180
> [1.080042] [] ret_from_fork+0x7c/0xb0
> [1.080042]
> [1.080042] other info that might help us debug this:
> [1.080042]
> [1.080042] Possible interrupt unsafe locking scenario:
> [1.080042]
> [1.080042]CPU0CPU1
> [1.080042]
> [1.080042] lock(&p->mems_allowed_seq);
> [1.080042]local_irq_disable();
> [1.080042]
> lock(&(&q->__queue_lock)->rlock);
> [1.080042]lock(&p->mems_allowed_seq);
> [1.080042]
> [1.080042] lock(&(&q->__queue_lock)->rlock);
> [1.080042]
> [1.080042] *** DEADLOCK ***
>
> The issue stems from the kthreadd() function calling set_mems_allowed
> with irqs enabled. While its possibly unlikely for the actual deadlock
> to trigger, a fix is fairly simple: disable irqs before taking the
> mems_allowed_seq lock.
>
Now I get it. I'm fine with this change.
Acked-by: Li Zefan
> Let me know if you have any other suggestions or alternative fixes you'd
> prefer.
>
> Cc: Li Zefan
> Cc: Mathieu Desnoyers
> Cc: Steven Rostedt
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Signed-off-by: John Stultz
> ---
> include/linux/cpuset.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
> index cc1b01c..3fe661f 100644
> --- a/include/linux/cpuset.h
> +++ b/include/linux/cpuset.h
> @@ -110,10 +110,14 @@ static inline bool put_mems_allowed(unsigned int seq)
>
> static inline void set_mems_allowed(nodemask_t nodemask)
> {
> + unsigned long flags;
> +
> task_lock(current);
> + local_irq_save(flags);
> write_seqcount_begin(¤t->mems_allowed_seq);
> current->mems_allowed = nodemask;
> write_seqcount_end(¤t->mems_allowed_seq);
> + local_irq_restore(flags);
> task_unlock(current);
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Btrfs
On Fri, Sep 13, 2013 at 04:58:36PM +0100, Russell King wrote: > On Fri, Sep 13, 2013 at 11:38:15AM -0400, Josh Boyer wrote: > > On Fri, Sep 13, 2013 at 11:06 AM, Josh Boyer wrote: > > > On Fri, Sep 13, 2013 at 8:15 AM, Russell King > > > wrote: > > >> On Fri, Sep 13, 2013 at 07:53:21AM -0400, Josh Boyer wrote: > > >>> I'm not an ARM expert, so I don't know if ARM should use the > > >>> asm-generic implementations, or just use __get_user/__put_user in all > > >>> cases. I've CC'd rmk. > > >> > > >> Why do we have uaccess-unaligned.h ? Normally, these kinds of things > > >> are spawned by architectures which have problems with unaligned accesses, > > >> ARM being one of them, but afaik we've never need this. > > >> > > >> With the kernel-side trapping of unaligned accesses on older hardware, > > >> we've always dealt with the normal accessor faulting. > > >> > > >> From what I can tell in the git history, these unaligned put_user and > > >> get_user have existed all the way back to the dawn of git use. > > >> > > >> Can someone enlighten me why we have them? > > > > I somehow fail at email and dropped Russell from CC on accident. Sigh. > > You're not the first to do that recently. I'm beginning to think it's > something someone has written into email clients to make them do in order > to piss me off. I mean, it's _hard_ to do - you have to manually edit the > recipients list to just drop one person. You configured your mail client to generate a "Mail-Followup-To:" header field which actively asks other mail clients to remove you from replies. So you only get what you ask for... ;) I think the mutt "metoo" variable will change that, but I don't know for sure. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 069/228] cpufreq: kirkwood: Use generic cpufreq routines
On Fri, Sep 13, 2013 at 06:30:15PM +0530, Viresh Kumar wrote: > Most of the CPUFreq drivers do similar things in .exit() and .verify() > routines > and .attr. So its better if we have generic routines for them which can be > used > by cpufreq drivers then. > > This patch uses these generic routines for this driver. > > Cc: Andrew Lunn > Signed-off-by: Viresh Kumar > --- > drivers/cpufreq/kirkwood-cpufreq.c | 22 +++--- > 1 file changed, 3 insertions(+), 19 deletions(-) Hi Viresh You can add: Tested-by: Andrew Lunn to [PATCH 069/228] cpufreq: kirkwood: Use generic cpufreq routines [PATCH 107/228] cpufreq: kirkwood: don't initialize part of policy that is set by core [PATCH 161/228] cpufreq: kirkwood: Convert to light weight ->target_index() routine [PATCH 195/228] cpufreq: kirkwood: remove calls to cpufreq_notify_transition() It does however require the patch: http://www.spinics.net/lists/arm-kernel/msg273378.html but this is not because of this patch series, it was already broken. Thanks Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Sunday 08 September 2013 09:43:29 Pali Rohár wrote:
> Here is new version (v4) of omap secure part patch:
>
> Other secure functions omap_smc1() and omap_smc2() calling
> instruction smc #0 but Nokia RX-51 board needs to call smc #1
> for PPA access.
>
> Signed-off-by: Ivaylo Dimitrov
> Signed-off-by: Pali Rohár
> ---
> diff --git a/arch/arm/mach-omap2/omap-secure.h
> b/arch/arm/mach-omap2/omap-secure.h index 0e72917..c4586f4
> 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -51,6 +51,7 @@
> extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32
> nargs, u32 arg1, u32 arg2, u32 arg3, u32 arg4);
> extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
> +extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32
> pargs); extern phys_addr_t
> omap_secure_ram_mempool_base(void); extern int
> omap_secure_ram_reserve_memblock(void);
>
> diff --git a/arch/arm/mach-omap2/omap-smc.S
> b/arch/arm/mach-omap2/omap-smc.S index f6441c1..fd90125
> 100644
> --- a/arch/arm/mach-omap2/omap-smc.S
> +++ b/arch/arm/mach-omap2/omap-smc.S
> @@ -1,9 +1,11 @@
> /*
> - * OMAP44xx secure APIs file.
> + * OMAP34xx and OMAP44xx secure APIs file.
> *
> * Copyright (C) 2010 Texas Instruments, Inc.
> * Written by Santosh Shilimkar
> *
> + * Copyright (C) 2012 Ivaylo Dimitrov
> + * Copyright (C) 2013 Pali Rohár
> *
> * This program is free software,you can redistribute it
> and/or modify * it under the terms of the GNU General Public
> License version 2 as @@ -54,6 +56,23 @@ ENTRY(omap_smc2)
> ldmfd sp!, {r4-r12, pc}
> ENDPROC(omap_smc2)
>
> +/**
> + * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag,
> u32 pargs) + * Low level common routine for secure HAL and
> PPA APIs via smc #1 + * r0 - @service_id: Secure Service ID
> + * r1 - @process_id: Process ID
> + * r2 - @flag: Flag to indicate the criticality of operation
> + * r3 - @pargs: Physical address of parameter list
> + */
> +ENTRY(omap_smc3)
> + stmfd sp!, {r4-r11, lr}
> + mov r12, r0 @ Copy the secure service ID
> + mov r6, #0xff @ Indicate new Task call
> + dsb @ Memory Barrier (not sure if needed, copied
> from
> omap_smc2) + smc #1 @ Call PPA service
> + ldmfd sp!, {r4-r11, pc}
> +ENDPROC(omap_smc3)
> +
> ENTRY(omap_modify_auxcoreboot0)
> stmfd sp!, {r1-r12, lr}
> ldr r12, =0x104
Dave, it is ok now?
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 0/4] Add support for charging battery in Nokia RX-51
On Sunday 08 September 2013 10:50:35 Pali Rohár wrote: > This patch series finally bringing support for charging > battery on Nokia N900 (RX-51) without any proprietary Nokia > bits in userspace. > > Pali Rohár (4): > usb: musb: Call atomic_notifier_call_chain when status is > changed power: isp1704_charger: Fix driver to work with > changes introduced in v3.5 > power: isp1704_charger: Add callback function set_current > RX-51: Add platform function and data for bq24150a charger > > arch/arm/mach-omap2/board-rx51-peripherals.c | 56 > +- drivers/power/isp1704_charger.c | > 107 ++ drivers/usb/musb/omap2430.c >|3 + drivers/usb/phy/phy-twl4030-usb.c >|2 + include/linux/power/isp1704_charger.h > |1 + 5 files changed, 117 insertions(+), 52 deletions(-) Hello, can you review this patch series? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[GIT PULL] S+core Architecture : fix bugs for compiling and support necessary functions
Hi Linus, Please pull these updates for S+core architecture. These updates include updating information of maintainers, fix some trivial errors, and add a necessary function for supporting ipv6. The following changes since commit bdbdfdef5766c2a60185e946df242f1bc0d37c09 Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (Fri Sep 13 10:58:41 2013 -0700) on git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git For you to fetch changes up to 969f99168b9dff2f6cc07cdf14255178d4397c4f g...@github.com:sctscore/official-linux.git tags/branch-linus-20130914 Best, Lennox Wu --- Summary these commits: 1. Fix some trivial errors for successfully compiling the latest version Linux kernel. 2. Provide necessary function for support IPV6. 3. Update the information of maintainers. Lennox Wu (8): score : Update the information of Score maintainers score : Implement the function csum_ipv6_magic score : arch/score/kernel/entry.S: fix wrong instructions score : arch/score/kernel/process.c : fix some typos score : Modify the MAKEFILE of Score MAINTAINERS |4 +- arch/score/Kconfig|4 ++ arch/score/Makefile |4 +- arch/score/include/asm/checksum.h | 93 - arch/score/include/asm/io.h |1 - arch/score/include/asm/pgalloc.h |2 +- arch/score/kernel/entry.S |4 +- arch/score/kernel/process.c |4 +- 8 files changed, 64 insertions(+), 52 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Grant Donation
My wife and i won £148.6 Million Pounds last year, and we have done lot of charity donation, so we decide to give 1.5 Million Pounds each to 5 lucky people, lucky for you, your email, was given to us by Google management as one of our lucky precipitants. For verification process see below Please read the article - http://www.bbc.co.uk/news/uk-england-19254228 Send Name, Country, Age, Occupation and Phone Number for details Congratulations & Happy Celebrations in Advance, Gillian and Adrian Bayford Email: gillian.adrianbayfor...@rogers.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/
Grant Donation
My wife and i won £148.6 Million Pounds last year, and we have done lot of charity donation, so we decide to give 1.5 Million Pounds each to 5 lucky people, lucky for you, your email, was given to us by Google management as one of our lucky precipitants. For verification process see below Please read the article - http://www.bbc.co.uk/news/uk-england-19254228 Send Name, Country, Age, Occupation and Phone Number for details Congratulations & Happy Celebrations in Advance, Gillian and Adrian Bayford Email: gillian.adrianbayfor...@rogers.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 net 0/3] SLCAN/SLIP fixes and performance
On 09/13/2013 07:37 PM, Andre Naujoks wrote: > Hi Dave, > > these are some loosely related patches, that fix an ancient locking problem in > the slip and slcan drivers, add general ASCII-HEX to bin functions for > uppercase ASCII, fix the handling of CAN RTR frames in the slcan driver Can you get an Acked-by for the ASCII-HEX functions from the appropriate maintainer? > and increase the performance for the slcan driver. > > As these patches mainly contain fixes for the slip/slcan drivers that require > a tty layer fix included in 3.11, I would suggest to get the patches in via > the net tree for the 3.12 cycle. They should apply properly on the latest net > and mainline tree. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [patch 0/7] improve memcg oom killer robustness v2
> CC: "Andrew Morton" , "Michal Hocko" > , "David Rientjes" , "KAMEZAWA Hiroyuki" > , "KOSAKI Motohiro" > , linux...@kvack.org, > cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, > linux-kernel@vger.kernel.org >On Wed, Sep 11, 2013 at 09:41:18PM +0200, azurIt wrote: >> >On Wed, Sep 11, 2013 at 08:54:48PM +0200, azurIt wrote: >> >> >On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote: >> >> >> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote: >> >> >> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote: >> >> >> >> >> >On Tue, Sep 10, 2013 at 09:32:53PM +0200, azurIt wrote: >> >> >> >> >> >> Here is full kernel log between 6:00 and 7:59: >> >> >> >> >> >> http://watchdog.sk/lkml/kern6.log >> >> >> >> >> > >> >> >> >> >> >Wow, your apaches are like the hydra. Whenever one is OOM >> >> >> >> >> >killed, >> >> >> >> >> >more show up! >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Yeah, it's supposed to do this ;) >> >> >> > >> >> >> >How are you expecting the machine to recover from an OOM situation, >> >> >> >though? I guess I don't really understand what these machines are >> >> >> >doing. But if you are overloading them like crazy, isn't that the >> >> >> >expected outcome? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> There's no global OOM, server has enough of memory. OOM is occuring >> >> >> only in cgroups (customers who simply don't want to pay for more >> >> >> memory). >> >> > >> >> >Yes, sure, but when the cgroups are thrashing, they use the disk and >> >> >CPU to the point where the overall system is affected. >> >> >> >> >> >> >> >> >> >> Didn't know that there is a disk usage because of this, i never noticed >> >> anything yet. >> > >> >You said there was heavy IO going on...? >> >> >> >> Yes, there usually was a big IO but it was related to that >> deadlocking bug in kernel (or i assume it was). I never saw a big IO >> in normal conditions even when there were lots of OOM in >> cgroups. I'm even not using swap because of this so i was assuming >> that lacks of memory is not doing any additional IO (or am i >> wrong?). And if you mean that last problem with IO from Monday, i >> don't exactly know what happens but it's really long time when we >> had so big problem with IO that it disables also root login on >> console. > >The deadlocking problem should be separate from this. > >Even without swap, the binaries and libraries of the running tasks can >get reclaimed (and immediately faulted back from disk, i.e thrashing). > >Usually the OOM killer should kick in before tasks cannibalize each >other like that. > >The patch you were using did in fact have the side effect of widening >the window between tasks entering heavy reclaim and the OOM killer >kicking in, so it could explain the IO worsening while fixing the dead >lock problem. > >That followup patch tries to narrow this window by quite a bit and >tries to stop concurrent reclaim when the group is already OOM. Johannes, the problem happened again, twice, but i have little more info than before. Here is the first occurence, this night between 5:15 and 5:25: - this time i kept opened terminal from other server to this problematic one with htop running - when server went down i opened it and saw one process of one user running at the top and taking 97% of CPU (cgroup 1304) - everything was stucked so that htop didn't help me much - luckily, my new 'load check' script, which i was mentioning before, was able to kill apache and everything went to normal (success with it's very first version, wow ;) ) - i checked some other logs and everything seems to point to cgroup 1304, also kernel log at 5:14-15 is showing hard OOM in that cgroup: http://watchdog.sk/lkml/kern7.log Second time it happend between 12:01 and 12:09 but it was in the middle of the day so i'm not attaching any logs (there will be lots of other junk so it will be harded to read something from it). It was related to different cgroup than in first time. azur -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 10/38] Documentation: dt: iio: Add binding for LPS001WP
added devicetree list cc.
On 09/10/13 13:49, Lee Jones wrote:
> LPS001WP is a Pressure and Temperature sensor.
>
> Signed-off-by: Lee Jones
> ---
> .../devicetree/bindings/iio/pressure/lps001wp.txt | 21
> +
> 1 file changed, 21 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/pressure/lps001wp.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/pressure/lps001wp.txt
> b/Documentation/devicetree/bindings/iio/pressure/lps001wp.txt
> new file mode 100644
> index 000..3294a65c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/pressure/lps001wp.txt
> @@ -0,0 +1,21 @@
> +* STMicroelectronics Pressure Sensor
> +
> +Required properties:
> + - compatible: Should be "st,lps001wp_press"
> + - reg: The I2C address of the sensor
> +
> +Optional properties:
> + - vdd-supply: Phandle to the Vdd supply regulator
> + - vddio-supply: Phandle to the Vdd-IO supply regulator
> +
> +Example:
> +
> +i2c@80128000 {
> +lps001wp@5c {
> +compatible = "st,lps001wp_press";
> +reg = <0x5c>;
> +
> +vdd-supply = <&ab8500_ldo_aux1_reg>;
> +vddio-supply = <&db8500_vsmps2_reg>;
> +};
> +};
> -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe
> linux-iio" 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 11/38] Documentation: dt: iio: Add binding for LSM303DLH
add devicetree list cc
On 09/10/13 13:49, Lee Jones wrote:
> LSM303DLH is a Accelerometer Sensor
>
> Signed-off-by: Lee Jones
> ---
> .../devicetree/bindings/iio/accel/lsm303dlh.txt | 21
> +
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/lsm303dlh.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/lsm303dlh.txt
> b/Documentation/devicetree/bindings/iio/accel/lsm303dlh.txt
> new file mode 100644
> index 000..bb59363
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/lsm303dlh.txt
> @@ -0,0 +1,21 @@
> +* STMicroelectronics Accelerometer Sensor
> +
> +Required properties:
> + - compatible: Should be "st,lsm303dlh_accel"
> + - reg: The I2C address of the sensor
> +
> +Optional properties:
> + - vdd-supply: Phandle to the Vdd supply regulator
> + - vddio-supply: Phandle to the Vdd-IO supply regulator
> +
> +Example:
> +
> +i2c@80128000 {
> + lsm303dlh_accel@19 {
> + compatible = "st,lsm303dlh_accel";
> + reg = <0x19>;
> +
> + vdd-supply = <&ab8500_ldo_aux1_reg>;
> + vddio-supply = <&db8500_vsmps2_reg>;
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/38] Documentation: dt: iio: Add binding for LSM303DLH
Add devicetree list cc.
On 09/10/13 13:49, Lee Jones wrote:
> LSM303DLH is a Magnetometer Sensor
>
> Signed-off-by: Lee Jones
> ---
> .../bindings/iio/magnetometer/lsm303dlh.txt | 21
> +
> 1 file changed, 21 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/magnetometer/lsm303dlh.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/magnetometer/lsm303dlh.txt
> b/Documentation/devicetree/bindings/iio/magnetometer/lsm303dlh.txt
> new file mode 100644
> index 000..5938369
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/magnetometer/lsm303dlh.txt
> @@ -0,0 +1,21 @@
> +* STMicroelectronics Magnetometer Sensor
> +
> +Required properties:
> + - compatible: Should be "st,lsm303dlh_magn"
> + - reg: The I2C address of the sensor
> +
> +Optional properties:
> + - vdd-supply: Phandle to the Vdd supply regulator
> + - vddio-supply: Phandle to the Vdd-IO supply regulator
> +
> +Example:
> +
> +i2c@80128000 {
> + lsm303dlh_magn@1e {
> + compatible = "st,lsm303dlh_magn";
> + reg = <0x1e>;
> +
> + vdd-supply = <&ab8500_ldo_aux1_reg>;
> + vddio-supply = <&db8500_vsmps2_reg>;
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/38] Documentation: dt: iio: Add binding for L3G4200D
Add devicetree list cc
On 09/10/13 13:49, Lee Jones wrote:
> L3G4200D is a Gyroscope Sensor
>
> Signed-off-by: Lee Jones
> ---
> .../devicetree/bindings/iio/gyro/l3g4200d.txt | 21
> +
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/gyro/l3g4200d.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/gyro/l3g4200d.txt
> b/Documentation/devicetree/bindings/iio/gyro/l3g4200d.txt
> new file mode 100644
> index 000..29baf9d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/gyro/l3g4200d.txt
> @@ -0,0 +1,21 @@
> +* STMicroelectronics Gyroscope Sensor
> +
> +Required properties:
> + - compatible: Should be "st,l3g4200d_gyro"
> + - reg: The I2C address of the sensor
> +
> +Optional properties:
> + - vdd-supply: Phandle to the Vdd supply regulator
> + - vddio-supply: Phandle to the Vdd-IO supply regulator
> +
> +Example:
> +
> +i2c@80128000 {
> + l3g4200d_gyro@68 {
> + compatible = "st,l3g4200d_gyro";
> + reg = <0x68>;
> +
> + vdd-supply = <&ab8500_ldo_aux1_reg>;
> + vddio-supply = <&db8500_vsmps2_reg>;
> + };
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Grant Donation
My wife and i won £148.6 Million Pounds last year, and we have done lot of charity donation, so we decide to give 1.5 Million Pounds each to 5 lucky people, lucky for you, your email, was given to us by Google management as one of our lucky precipitants. For verification process see below Please read the article - http://www.bbc.co.uk/news/uk-england-19254228 Send Name, Country, Age, Occupation and Phone Number for details Congratulations & Happy Celebrations in Advance, Gillian and Adrian Bayford Email: gillian.adrianbayfor...@rogers.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 14/38] iio: accel: st: Append _accel to accelerator sensor device names
On 09/10/13 13:49, Lee Jones wrote: > Some of ST's sensors are appended with their sensor type and some > are not. For consistency we're extending the same naming convention > throughout. > > Signed-off-by: Lee Jones Honestly I don't care either way on these, but consistency would definitely be good so applied to the togreg branch of iio.git Thanks, > --- > drivers/iio/accel/st_accel.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h > index c387763..d8d22e5 100644 > --- a/drivers/iio/accel/st_accel.h > +++ b/drivers/iio/accel/st_accel.h > @@ -15,11 +15,11 @@ > #include > > #define LSM303DLHC_ACCEL_DEV_NAME"lsm303dlhc_accel" > -#define LIS3DH_ACCEL_DEV_NAME"lis3dh" > +#define LIS3DH_ACCEL_DEV_NAME"lis3dh_accel" > #define LSM330D_ACCEL_DEV_NAME "lsm330d_accel" > #define LSM330DL_ACCEL_DEV_NAME "lsm330dl_accel" > #define LSM330DLC_ACCEL_DEV_NAME "lsm330dlc_accel" > -#define LIS331DLH_ACCEL_DEV_NAME "lis331dlh" > +#define LIS331DLH_ACCEL_DEV_NAME "lis331dlh_accel" > #define LSM303DL_ACCEL_DEV_NAME "lsm303dl_accel" > #define LSM303DLH_ACCEL_DEV_NAME "lsm303dlh_accel" > #define LSM303DLM_ACCEL_DEV_NAME "lsm303dlm_accel" > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: proc hidepid=2 and SGID programs
On Tue, Sep 10, 2013 at 01:30 -0700, Christian Kujau wrote: > On Sun, 8 Sep 2013 at 23:42, Eric W. Biederman wrote: > > I don't have a clue why anyone would want to hide processes, and make > > their own lives more difficult. > > Oh, there are plenty of usescases, I'm sure. And I for one am thankful > that this process hiding option made it into the kernel. Or, to answer in > another way: why would anyone want to see other peoples processes? The point is that quite many information about other user processes which can be obtained from procfs can be used in side channel attacks directed to either confidentiality or even privilege escalation. > > The check with hidepid is can you ptrace the process. I expect there > > is something with those sgid processes that keeps you from ptracing > > them. > > Indeed, I cannot strace the process. Right. > But still, I wonder if this is > intended behaviour. Yes. If you think such side channel attacks are something you don't care, just turn hidepid off. That's why it is an option. If you want to turn it off for some users, use gid=XXX. -- Vasily Kulikov http://www.openwall.com - bringing security into open computing environments -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 0/3] SLCAN/SLIP fixes and performance
On 14.09.2013 12:45, Marc Kleine-Budde wrote: On 09/13/2013 07:37 PM, Andre Naujoks wrote: Hi Dave, these are some loosely related patches, that fix an ancient locking problem in the slip and slcan drivers, add general ASCII-HEX to bin functions for uppercase ASCII, fix the handling of CAN RTR frames in the slcan driver Can you get an Acked-by for the ASCII-HEX functions from the appropriate maintainer? The patch went out to the maintainers I got from the get_maintainer.pl script. Is there anything else I can or should do to get an Ack from them? Regards Andre and increase the performance for the slcan driver. As these patches mainly contain fixes for the slip/slcan drivers that require a tty layer fix included in 3.11, I would suggest to get the patches in via the net tree for the 3.12 cycle. They should apply properly on the latest net and mainline tree. Marc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/38] iio: accel: st: Append _accel to accelerator sensor device names
On 09/14/13 13:14, Jonathan Cameron wrote: > On 09/10/13 13:49, Lee Jones wrote: >> Some of ST's sensors are appended with their sensor type and some >> are not. For consistency we're extending the same naming convention >> throughout. >> >> Signed-off-by: Lee Jones > Honestly I don't care either way on these, but consistency would definitely > be good so applied to the togreg branch of iio.git > > Thanks, Actually change of plan. I'm going to hold off on these as this an ABI change. Iritating though having these as completely inconsistent is, changing this will change device identification from userspace which is not a good idea. Sorry Lee, but we really shouldn't do this. I should have picked up on this in the original driver reviews but that's hindsight for you. >> --- >> drivers/iio/accel/st_accel.h | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h >> index c387763..d8d22e5 100644 >> --- a/drivers/iio/accel/st_accel.h >> +++ b/drivers/iio/accel/st_accel.h >> @@ -15,11 +15,11 @@ >> #include >> >> #define LSM303DLHC_ACCEL_DEV_NAME "lsm303dlhc_accel" >> -#define LIS3DH_ACCEL_DEV_NAME "lis3dh" >> +#define LIS3DH_ACCEL_DEV_NAME "lis3dh_accel" >> #define LSM330D_ACCEL_DEV_NAME "lsm330d_accel" >> #define LSM330DL_ACCEL_DEV_NAME "lsm330dl_accel" >> #define LSM330DLC_ACCEL_DEV_NAME"lsm330dlc_accel" >> -#define LIS331DLH_ACCEL_DEV_NAME"lis331dlh" >> +#define LIS331DLH_ACCEL_DEV_NAME"lis331dlh_accel" >> #define LSM303DL_ACCEL_DEV_NAME "lsm303dl_accel" >> #define LSM303DLH_ACCEL_DEV_NAME"lsm303dlh_accel" >> #define LSM303DLM_ACCEL_DEV_NAME"lsm303dlm_accel" >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" 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: 3.10.5: rcu_sched detected stalls on CPUs/tasks
Hello again, On Mon, Sep 09, 2013 at 03:27:51PM -0700, Paul E. McKenney wrote: > Several people helped track down another source of spurious stall > warnings on large systems, please see below for the patch. [...] > > > rcu: Reject memory-order-induced stall-warning false positives I run this patch on top of 3.10.11 vanilla since Wednesday, so far without any further stalls, on light to heavy loads. Works smooth as pie. Tested-by: Jochen Striepe Have a nice weekend and a big thank you, Jochen. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] trace: show more and exactly help information about snapshot
On Sat, 14 Sep 2013 12:59:16 +0800
Wang YanQing wrote:
> Actually, they both are correct:
>
> default:
> if (tr->allocated_snapshot) {
> if (iter->cpu_file == RING_BUFFER_ALL_CPUS)
> tracing_reset_online_cpus(&tr->max_buffer);
> else
> tracing_reset(&tr->max_buffer, iter->cpu_file);
> }
> break;
> }
>
> It does nothing if it isn't allocated.
>
> Perhaps we need it to say "(but does not allocate or free)"
>
> -- Steve
>
> Signed-off-by: Wang YanQing
> ---
> I think "Clears and frees" are reasonable, and
> "Clears and allocates are not so reasonable, so
> we don't need to say not allocate. But it is help
> information, so make it more clearer is also acceptable. :)
I'm getting ready to go to Linux Con / Linux Plumbers. I wont be able to
get to this before, and may not be able to get to it while I'm there.
As the original is technically correct, I'll put this into my 3.13
queue.
Thanks,
-- Steve
>
> kernel/trace/trace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 7974ba2..d5f7c4d 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -2760,7 +2760,7 @@ static void show_snapshot_main_help(struct seq_file *m)
> seq_printf(m, "# echo 0 > snapshot : Clears and frees snapshot
> buffer\n");
> seq_printf(m, "# echo 1 > snapshot : Allocates snapshot buffer, if not
> already allocated.\n");
> seq_printf(m, "# Takes a snapshot of the main
> buffer.\n");
> - seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does
> not allocate)\n");
> + seq_printf(m, "# echo 2 > snapshot : Clears snapshot buffer (but does
> not allocate or free)\n");
> seq_printf(m, "# (Doesn't have to be '2' works
> with any number that\n");
> seq_printf(m, "# is not a '0' or '1')\n");
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] Add cpuconfig nodes in dts for smp configure.
Hi Fan,
On Thu, Sep 12, 2013 at 02:51:25PM +0800, Fan Rong wrote:
> Signed-off-by: Fan Rong
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 999ff45..bfedcb2 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -20,13 +20,13 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> - cpu@0 {
> + cpu0: cpu@0 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0>;
> };
>
> - cpu@1 {
> + cpu1: cpu@1 {
Both these changes don't seem really needed, are they?
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <1>;
> @@ -167,6 +167,11 @@
> #size-cells = <1>;
> ranges;
>
> + cc: cpuconfig@01c25c00 {
> + compatible = "allwinner,sun7i-cc";
Please use the sun7i-a20 prefix, and I'd prefer cpu-config instead of
"cc".
Thanks for working on this!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH 3/4] Add physical count arch timer support for clocksource in ARMv7.
Hi Marc, Fan, On Fri, Sep 13, 2013 at 10:30:49AM +0100, Marc Zyngier wrote: > On 13/09/13 09:49, cinifr wrote: > > On 13 September 2013 00:39, Marc Zyngier wrote: > > I am wondering what is the principle between kernel and bootload? > > What should be done in bootloader and what should be done in kernel? > > As you said, If kernel boot from hyp, Kernel can set CNTVOFF to zero > > directly, does we add the code to set CNTVOFF in kernel? But, if > > kernel boot from PL1 NS=0, Does kernel need to switch hyp mode to > > set CNTVOFF and return PL1 NS=0 mode? Or,kernel dont care it because > > kernel believe bootloader have set CNTVOFF before? > > In an ideal world, the bootloader should set CNTVOFF to zero. The fact > that the kernel does it too when booted in HYP mode is to preserve > itself from from broken bootloaders. > > CNTVOFF can only be setup from either HYP or Secure Monitor mode with > SCR.NS == 1, so if you run your kernel in secure mode, it is always best > to do it in the bootloader. What would happen exactly if a kernel expects CNTVOFF to be set to 0, and that your bootloader don't set it? From what you're saying, it's will be set by the kernel if it's booted in hypervisor mode, but what if it's not? The ARM documentation says that the CNTVOFF register will hold an undefined value, how would that affect the kernel? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH 1/3] arm: kvm: clamp NR_VCPUS to MAX_VCPUS
Signed-off-by: Andrew Jones --- arch/arm/kvm/arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c index 741f66a2edbd7..9ebf8ac3a12ff 100644 --- a/arch/arm/kvm/arm.c +++ b/arch/arm/kvm/arm.c @@ -201,7 +201,7 @@ int kvm_dev_ioctl_check_extension(long ext) r = 1; break; case KVM_CAP_NR_VCPUS: - r = num_online_cpus(); + r = min(num_online_cpus(), KVM_MAX_VCPUS); break; case KVM_CAP_MAX_VCPUS: r = KVM_MAX_VCPUS; -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] aarch64: kvm: introduce CONFIG_KVM_MAX_VCPUS
Take CONFIG_KVM_MAX_VCPUS from arm32, but set the default to 8. Signed-off-by: Andrew Jones --- arch/arm64/include/asm/kvm_host.h | 7 ++- arch/arm64/kvm/Kconfig| 11 +++ 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 0859a4ddd1e7d..d1af8c49a5ca4 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -26,7 +26,12 @@ #include #include -#define KVM_MAX_VCPUS 4 +#if defined(CONFIG_KVM_MAX_VCPUS) +#define KVM_MAX_VCPUS CONFIG_KVM_MAX_VCPUS +#else +#define KVM_MAX_VCPUS 0 +#endif + #define KVM_USER_MEM_SLOTS 32 #define KVM_PRIVATE_MEM_SLOTS 4 #define KVM_COALESCED_MMIO_PAGE_OFFSET 1 diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 21e90820bd23c..c9924b02e84f7 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -35,6 +35,17 @@ config KVM_ARM_HOST ---help--- Provides host support for ARM processors. +config KVM_MAX_VCPUS + int "Number maximum supported virtual CPUs per VM" + depends on KVM_ARM_HOST + default 8 + help + Static number of max supported virtual CPUs per VM. + + The default is set to the highest number of vcpus that + current hardware supports. Set to a lower number to save + some resources. Set to a higher number to test scalability. + config KVM_ARM_VGIC bool depends on KVM_ARM_HOST && OF -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] KVM_MAX_VCPUS related changes
Andrew Jones (3): arm: kvm: clamp NR_VCPUS to MAX_VCPUS arm32: kvm: rename CONFIG_KVM_ARM_MAX_VCPUS aarch64: kvm: introduce CONFIG_KVM_MAX_VCPUS arch/arm/include/asm/kvm_host.h | 4 ++-- arch/arm/kvm/Kconfig | 8 arch/arm/kvm/arm.c| 2 +- arch/arm64/include/asm/kvm_host.h | 7 ++- arch/arm64/kvm/Kconfig| 11 +++ 5 files changed, 24 insertions(+), 8 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] arm32: kvm: rename CONFIG_KVM_ARM_MAX_VCPUS
Drop the _ARM_ part of the name. We can then introduce a config option like this to aarch64 and other arches using the same name - allowing grep to show them all. Also update the help text to describe the option more completely. Signed-off-by: Andrew Jones --- arch/arm/include/asm/kvm_host.h | 4 ++-- arch/arm/kvm/Kconfig| 8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index 7d22517d80711..c614d3eb176c6 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@ -25,8 +25,8 @@ #include #include -#if defined(CONFIG_KVM_ARM_MAX_VCPUS) -#define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS +#if defined(CONFIG_KVM_MAX_VCPUS) +#define KVM_MAX_VCPUS CONFIG_KVM_MAX_VCPUS #else #define KVM_MAX_VCPUS 0 #endif diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig index ebf5015508b52..de63bfccb3eb5 100644 --- a/arch/arm/kvm/Kconfig +++ b/arch/arm/kvm/Kconfig @@ -40,16 +40,16 @@ config KVM_ARM_HOST ---help--- Provides host support for ARM processors. -config KVM_ARM_MAX_VCPUS +config KVM_MAX_VCPUS int "Number maximum supported virtual CPUs per VM" depends on KVM_ARM_HOST default 4 help Static number of max supported virtual CPUs per VM. - If you choose a high number, the vcpu structures will be quite - large, so only choose a reasonable number that you expect to - actually use. + The default is set to the highest number of vcpus that + current hardware supports. Set to a lower number to save + some resources. Set to a higher number to test scalability. config KVM_ARM_VGIC bool "KVM support for Virtual GIC" -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arm: kvm: clamp NR_VCPUS to MAX_VCPUS
Am 14.09.2013 um 07:10 schrieb Andrew Jones : > Signed-off-by: Andrew Jones > --- > arch/arm/kvm/arm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c > index 741f66a2edbd7..9ebf8ac3a12ff 100644 > --- a/arch/arm/kvm/arm.c > +++ b/arch/arm/kvm/arm.c > @@ -201,7 +201,7 @@ int kvm_dev_ioctl_check_extension(long ext) >r = 1; >break; >case KVM_CAP_NR_VCPUS: > -r = num_online_cpus(); > +r = min(num_online_cpus(), KVM_MAX_VCPUS); Is there any real reason to prohibit overcommit? Alex >break; >case KVM_CAP_MAX_VCPUS: >r = KVM_MAX_VCPUS; > -- > 1.8.1.4 > > ___ > kvmarm mailing list > kvm...@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: dev->of_node overwrite can cause device loading with different driver
On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote: > > Ok, so what do you suggest we do for stuff like this? Fix up the musb > > driver? Or something else? > > I think there are three options to solve this: > > 1. Break out of the driver list iteration loop as soon as a driver probe >function fails. This way there is no possibility for another driver >to be probed with a device struct that was changed by the first >driver. But it would remove the support to fall back to >another driver for a device. I am not aware of any device that is >supported by multiple drivers. No, that's not ok, lots of drivers say "I support all devices, send them to me!" and then fail their probe function when they realize they don't really support a specific device that was sent to them. So that wouldn't work at all, as you would break all of those situations. > 2. We could restore the device struct completely or partially (only >of_node) after a probe failure. This would avoid driver probes with >unclean device structs, but introduces some overhead. Overhead isn't an issue here, this is not "performance critical" code paths. But it would be messy. > 3. We could fix up all drivers that change the of_node. But there are >ARM DT frameworks that require a device struct as parameter instead >of a device_node parameter (e.g. soc-generic-dmaengine-pcm). So a >driver core, initialized by a glue driver with DT bindings, has to >set dev->of_node to use those frameworks. I think it is strange to >have such DT framework interfaces if a driver is not supposed to >overwrite dev->of_node permanently. How about any driver that does muck with this structure, restore it properly if their probe() function fails? Yes, you show that this is going to be tricky in some places (i.e. musb), but it makes sense that the burden of fixing this issue would rest on them, as they are the ones causing this problem, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Input: gpio_keys - wakeup_trigger
Hi Benson, On Friday 13 of September 2013 14:52:40 Benson Leung wrote: > Allow wakeup_trigger to be defined per gpio button. Currently, all > gpio buttons are set up as IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING. > It may be more appropriate to only wake the system on one edge, for > example if the gpio is for a Lid Switch. > > Signed-off-by: Benson Leung > --- > .../devicetree/bindings/gpio/gpio_keys.txt | 7 +++ > drivers/input/keyboard/gpio_keys.c | 23 > -- include/linux/gpio_keys.h > | 3 +++ > 3 files changed, 31 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio_keys.txt > b/Documentation/devicetree/bindings/gpio/gpio_keys.txt index > 5c2c021..243f569 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio_keys.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio_keys.txt > @@ -20,6 +20,13 @@ Optional subnode-properties: > - debounce-interval: Debouncing interval time in milliseconds. > If not specified defaults to 5. > - gpio-key,wakeup: Boolean, button can wake-up the system. > + - gpio-key,wakeup-trigger : Specifies the type of wakeup behavior. > + <1> == Rising Edge Trigger > + <2> == Falling Edge Trigger > + <3> == Both Rising and Falling Edge Trigger > + <4> == Level High Trigger > + <8> == Level Low Trigger > + If not specified, defaults to <3> == Both Rising and Falling. I don't like two things in this patch. First is that this looks completely like a configuration option, not hardware description, so it's not something that should be put into DT. Especially that users might want to use another wake-up trigger depending on their use cases. I'd rather see this as a sysfs entry. Another thing is that this driver assumes that key events are indicated by edges on the GPIO line, so I don't think level trigger setting make any sense here. I'd rather allow three settings here (through a sysfs knob) - key down, key up, key down or up. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [RFC] x86: kvm: remove KVM_SOFT_MAX_VCPUS
This patch removes KVM_SOFT_MAX_VCPUS and uses num_online_cpus() for KVM_CAP_NR_VCPUS instead, as ARM does. While the API doc simply says KVM_CAP_NR_VCPUS should return the recommended maximum number of vcpus, it has been returning KVM_SOFT_MAX_VCPUS, which was defined as the maximum tested number of vcpus. As that concept could be distro-specific, this patch uses the other recommended maximum, the number of physical cpus, as we never recommend configuring a guest that has more vcpus than the host has pcpus. Of course a guest can always still be configured with up to KVM_CAP_MAX_VCPUS though anyway. I've put RFC on this patch because I'm not sure if there are any gotchas lurking with this change. The change now means hosts no longer return the same number for KVM_CAP_NR_VCPUS, and that number is likely going to generally be quite a bit less than what KVM_SOFT_MAX_VCPUS was (160). I can't think of anything other than generating more warnings[1] from qemu with guests that configure more vcpus than pcpus though. [1] Actually, until 972fc544b6034a in uq/master is merged there won't be any warnings either. Signed-off-by: Andrew Jones --- arch/x86/include/asm/kvm_host.h | 1 - arch/x86/kvm/x86.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index c76ff74a98f2e..9236c63315a9b 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -32,7 +32,6 @@ #include #define KVM_MAX_VCPUS 255 -#define KVM_SOFT_MAX_VCPUS 160 #define KVM_USER_MEM_SLOTS 125 /* memory slots that are not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 3 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e5ca72a5cdb6d..d9d3e2ed68ee9 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2604,7 +2604,7 @@ int kvm_dev_ioctl_check_extension(long ext) r = !kvm_x86_ops->cpu_has_accelerated_tpr(); break; case KVM_CAP_NR_VCPUS: - r = KVM_SOFT_MAX_VCPUS; + r = min(num_online_cpus(), KVM_MAX_VCPUS); break; case KVM_CAP_MAX_VCPUS: r = KVM_MAX_VCPUS; -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: kvm: introduce CONFIG_KVM_MAX_VCPUS
Take CONFIG_KVM_MAX_VCPUS from arm32, but set the default to 255. Signed-off-by: Andrew Jones --- arch/x86/include/asm/kvm_host.h | 5 +++-- arch/x86/kvm/Kconfig| 10 ++ 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index c76ff74a98f2e..e7e9b523a8f7e 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -31,8 +31,9 @@ #include #include -#define KVM_MAX_VCPUS 255 -#define KVM_SOFT_MAX_VCPUS 160 +#define KVM_MAX_VCPUS CONFIG_KVM_MAX_VCPUS +#define KVM_SOFT_MAX_VCPUS min(160, KVM_MAX_VCPUS) + #define KVM_USER_MEM_SLOTS 125 /* memory slots that are not exposed to userspace */ #define KVM_PRIVATE_MEM_SLOTS 3 diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index a47a3e54b964b..e9532c33527ee 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -52,6 +52,16 @@ config KVM If unsure, say N. +config KVM_MAX_VCPUS + int "Number maximum supported virtual CPUs per VM" + depends on KVM + default 255 + help + Static number of max supported virtual CPUs per VM. + + Set to a lower number to save some resources. Set to a higher + number to test scalability. + config KVM_INTEL tristate "KVM for Intel processors support" depends on KVM -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arm: kvm: clamp NR_VCPUS to MAX_VCPUS
On 2013-09-14 13:14, Alexander Graf wrote: Am 14.09.2013 um 07:10 schrieb Andrew Jones : Signed-off-by: Andrew Jones --- arch/arm/kvm/arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c index 741f66a2edbd7..9ebf8ac3a12ff 100644 --- a/arch/arm/kvm/arm.c +++ b/arch/arm/kvm/arm.c @@ -201,7 +201,7 @@ int kvm_dev_ioctl_check_extension(long ext) r = 1; break; case KVM_CAP_NR_VCPUS: -r = num_online_cpus(); +r = min(num_online_cpus(), KVM_MAX_VCPUS); Is there any real reason to prohibit overcommit? I don't think this affects overcommit. This is the "recommended" limit, and you can still go up to KVM_MAX_CPUS. M. -- Fast, cheap, reliable. Pick two. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: scripts/config: fix variable substitution command
Hi,
The ChangeLog from [1] says:
Commit 229455bc02b87f7128f190c4491b4ce38648 accidentally changed
the separator between sed `s' command and its parameters from ':' to
'/'.
Revert this change.
Reported-and-tested-by: Linus Walleij
Signed-off-by: Clement Chauplannaz
Signed-off-by: Michal Marek
*** Bad commit reference: 229455bc02b87f7128f190c4491b4ce38648 ***
(Linus-tree)
To quote [2] and see its EXAMPLE:
"If you want to refer to a specific commit, don't just refer to the
SHA-1 ID of the commit. Please also include the oneline summary of
the commit, to make it easier for reviewers to know what it is about.
Example:
Commit e21d2170f36602ae2708 ("video: remove unnecessary
platform_set_drvdata()") removed the unnecessary
platform_set_drvdata(), but left the variable "dev" unused,
delete it."
That's why the commit-id without the subject-line is no good help.
It does not help anyone when you reference a local GIT or linux-kbuild
GIT related commit-id.
So, can you point me/us to the correct commit with subject, please?!
Is this patch even "CC: stable"?
Thanks.
Regards,
- Sedat -
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=86eb781889ec31f6421b86ab252ea609d456322d
[2]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n112
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arm: kvm: clamp NR_VCPUS to MAX_VCPUS
On Sat, Sep 14, 2013 at 07:14:02AM -0500, Alexander Graf wrote: > > > Am 14.09.2013 um 07:10 schrieb Andrew Jones : > > > Signed-off-by: Andrew Jones > > --- > > arch/arm/kvm/arm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c > > index 741f66a2edbd7..9ebf8ac3a12ff 100644 > > --- a/arch/arm/kvm/arm.c > > +++ b/arch/arm/kvm/arm.c > > @@ -201,7 +201,7 @@ int kvm_dev_ioctl_check_extension(long ext) > >r = 1; > >break; > >case KVM_CAP_NR_VCPUS: > > -r = num_online_cpus(); > > +r = min(num_online_cpus(), KVM_MAX_VCPUS); > > Is there any real reason to prohibit overcommit? This doesn't prohibit it. Users can attempt to configure anything they'd like, but only selections KVM_MAX_VCPUS and below will work. drew > > Alex > > >break; > >case KVM_CAP_MAX_VCPUS: > >r = KVM_MAX_VCPUS; > > -- > > 1.8.1.4 > > > > ___ > > kvmarm mailing list > > kvm...@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Business proposal.
Dear friend, My name is Mr. Ego Kadima. I am working with one of the prime banks here in Burkina Faso. Here in this bank existed a dormant account for many years, which belong to one of our late foreign customer. When I discovered that there had been neither deposits nor withdrawals from this account for this long period, I decided to carry out a system investigation and discovered that none of the family member or relations of the late person are aware of this account, which means nobody will come to take it. The amount in this account stands at $2.3Million (Two Million Three Hundred Thousand USA Dollars). I want a foreign account where the bank will transfer this fund. I will front you in the bank as the Next of Kin to the late customer and back you up with relevant information. What the bank need is proof and information about the late customer which I will assist you on. This is a genuine, risk free and legal business transaction. All details shall be sent to you once I hear from you. The information as contained herein be accorded the necessary attention, urgency as well as the secrecy it deserves. If you are really sure of your integrity, trustworthy and confidentiality, reply back to me urgently. Best regards, Mr. Ego Kadima. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.0.96
I'm announcing the release of the 3.0.96 kernel. All users of the 3.0 kernel series must upgrade. The updated 3.0.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.0.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 +- arch/m32r/boot/compressed/Makefile |6 +++--- arch/m32r/boot/compressed/misc.c | 12 +++- arch/s390/kvm/kvm-s390.c | 17 +++-- drivers/net/tun.c |6 -- drivers/parisc/iommu-helpers.h |2 ++ drivers/pci/Makefile |1 + include/linux/icmpv6.h |2 ++ include/linux/ipv6.h |1 + net/bridge/br_multicast.c |3 ++- net/core/sysctl_net_core.c |7 ++- net/ipv4/fib_trie.c|5 + net/ipv4/tcp_cubic.c | 12 +++- net/ipv6/addrconf.c| 10 -- net/ipv6/icmp.c| 10 +- net/ipv6/ip6_fib.c | 16 net/ipv6/ndisc.c | 16 +--- net/ipv6/reassembly.c |5 + net/sched/sch_htb.c|2 +- net/tipc/eth_media.c | 15 ++- 20 files changed, 106 insertions(+), 44 deletions(-) Cong Wang (1): PARISC: include in drivers/parisc/iommu-helpers.h Dan Carpenter (1): tun: signedness bug in tun_get_user() Daniel Borkmann (1): net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay Dominik Dingel (1): KVM: s390: move kvm_guest_enter,exit closer to sie Eric Dumazet (3): fib_trie: remove potential out of bound access tcp: cubic: fix overflow error in bictcp_update() tcp: cubic: fix bug in bictcp_acked() Geert Uytterhoeven (3): m32r: consistently use "suffix-$(...)" m32r: add memcpy() for CONFIG_KERNEL_GZIP=y m32r: make memset() global for CONFIG_KERNEL_BZIP2=y Greg Kroah-Hartman (1): Linux 3.0.96 Hannes Frederic Sowa (3): ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match ipv6: remove max_addresses check from ipv6_create_tempaddr ipv6: drop packets with multiple fragmentation headers Jiri Bohac (1): ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO Paul Gortmaker (1): pci: frv architecture needs generic setup-bus infrastructure Roman Gushchin (1): net: check net.core.somaxconn sysctl values Thomas Graf (1): ipv6: Don't depend on per socket memory for neighbour discovery messages Ying Xue (1): tipc: fix lockdep warning during bearer initialization stephen hemminger (1): htb: fix sign extension bug signature.asc Description: Digital signature
Re: Linux 3.0.96
diff --git a/Makefile b/Makefile
index 58ce3d7..e2a73eb 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 95
+SUBLEVEL = 96
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/m32r/boot/compressed/Makefile
b/arch/m32r/boot/compressed/Makefile
index 177716b..01729c2 100644
--- a/arch/m32r/boot/compressed/Makefile
+++ b/arch/m32r/boot/compressed/Makefile
@@ -43,9 +43,9 @@ endif
OBJCOPYFLAGS += -R .empty_zero_page
-suffix_$(CONFIG_KERNEL_GZIP) = gz
-suffix_$(CONFIG_KERNEL_BZIP2) = bz2
-suffix_$(CONFIG_KERNEL_LZMA) = lzma
+suffix-$(CONFIG_KERNEL_GZIP) = gz
+suffix-$(CONFIG_KERNEL_BZIP2) = bz2
+suffix-$(CONFIG_KERNEL_LZMA) = lzma
$(obj)/piggy.o: $(obj)/vmlinux.scr $(obj)/vmlinux.bin.$(suffix-y) FORCE
$(call if_changed,ld)
diff --git a/arch/m32r/boot/compressed/misc.c b/arch/m32r/boot/compressed/misc.c
index 370d608..28a0952 100644
--- a/arch/m32r/boot/compressed/misc.c
+++ b/arch/m32r/boot/compressed/misc.c
@@ -28,7 +28,7 @@ static unsigned long free_mem_ptr;
static unsigned long free_mem_end_ptr;
#ifdef CONFIG_KERNEL_BZIP2
-static void *memset(void *s, int c, size_t n)
+void *memset(void *s, int c, size_t n)
{
char *ss = s;
@@ -39,6 +39,16 @@ static void *memset(void *s, int c, size_t n)
#endif
#ifdef CONFIG_KERNEL_GZIP
+void *memcpy(void *dest, const void *src, size_t n)
+{
+ char *d = dest;
+ const char *s = src;
+ while (n--)
+ *d++ = *s++;
+
+ return dest;
+}
+
#define BOOT_HEAP_SIZE 0x1
#include "../../../../lib/decompress_inflate.c"
#endif
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index f9804b7..1e88eef 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -445,6 +445,8 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
static void __vcpu_run(struct kvm_vcpu *vcpu)
{
+ int rc;
+
memcpy(&vcpu->arch.sie_block->gg14, &vcpu->arch.guest_gprs[14], 16);
if (need_resched())
@@ -455,21 +457,24 @@ static void __vcpu_run(struct kvm_vcpu *vcpu)
kvm_s390_deliver_pending_interrupts(vcpu);
+ VCPU_EVENT(vcpu, 6, "entering sie flags %x",
+ atomic_read(&vcpu->arch.sie_block->cpuflags));
+
vcpu->arch.sie_block->icptcode = 0;
local_irq_disable();
kvm_guest_enter();
local_irq_enable();
- VCPU_EVENT(vcpu, 6, "entering sie flags %x",
- atomic_read(&vcpu->arch.sie_block->cpuflags));
- if (sie64a(vcpu->arch.sie_block, vcpu->arch.guest_gprs)) {
+ rc = sie64a(vcpu->arch.sie_block, vcpu->arch.guest_gprs);
+ local_irq_disable();
+ kvm_guest_exit();
+ local_irq_enable();
+
+ if (rc) {
VCPU_EVENT(vcpu, 3, "%s", "fault in sie instruction");
kvm_s390_inject_program_int(vcpu, PGM_ADDRESSING);
}
VCPU_EVENT(vcpu, 6, "exit sie icptcode %d",
vcpu->arch.sie_block->icptcode);
- local_irq_disable();
- kvm_guest_exit();
- local_irq_enable();
memcpy(&vcpu->arch.guest_gprs[14], &vcpu->arch.sie_block->gg14, 16);
}
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 28c5c6a..476b2ed 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -614,8 +614,9 @@ static __inline__ ssize_t tun_get_user(struct tun_struct
*tun,
int offset = 0;
if (!(tun->flags & TUN_NO_PI)) {
- if ((len -= sizeof(pi)) > count)
+ if (len < sizeof(pi))
return -EINVAL;
+ len -= sizeof(pi);
if (memcpy_fromiovecend((void *)&pi, iv, 0, sizeof(pi)))
return -EFAULT;
@@ -623,8 +624,9 @@ static __inline__ ssize_t tun_get_user(struct tun_struct
*tun,
}
if (tun->flags & TUN_VNET_HDR) {
- if ((len -= tun->vnet_hdr_sz) > count)
+ if (len < tun->vnet_hdr_sz)
return -EINVAL;
+ len -= tun->vnet_hdr_sz;
if (memcpy_fromiovecend((void *)&gso, iv, offset, sizeof(gso)))
return -EFAULT;
diff --git a/drivers/parisc/iommu-helpers.h b/drivers/parisc/iommu-helpers.h
index a9c46cc..8c33491 100644
--- a/drivers/parisc/iommu-helpers.h
+++ b/drivers/parisc/iommu-helpers.h
@@ -1,3 +1,5 @@
+#include
+
/**
* iommu_fill_pdir - Insert coalesced scatter/gather chunks into the I/O Pdir.
* @ioc: The I/O Controller.
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 094308e..9eff33b 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_UNICORE32) += setup-bus.o setup-irq.o
obj-$(CONFIG_PARISC) += setup-bus.o
obj-$(CONFIG_SUPERH) += setup-bus.o setup-irq.o
obj-$(CONFIG_PPC) += setup-bus.o
+obj-$(CONFIG_FRV) += setup-bus.o
obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
obj-$(CONFIG_X86_VISWS) += setup-irq.o
obj-$(CONFIG_MN10300) += setup-bus.o
diff --git a/
Re: Linux 3.4.62
diff --git a/Makefile b/Makefile
index bc4dd5b..3f23cb7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 4
-SUBLEVEL = 61
+SUBLEVEL = 62
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/arch/m32r/boot/compressed/Makefile
b/arch/m32r/boot/compressed/Makefile
index 177716b..01729c2 100644
--- a/arch/m32r/boot/compressed/Makefile
+++ b/arch/m32r/boot/compressed/Makefile
@@ -43,9 +43,9 @@ endif
OBJCOPYFLAGS += -R .empty_zero_page
-suffix_$(CONFIG_KERNEL_GZIP) = gz
-suffix_$(CONFIG_KERNEL_BZIP2) = bz2
-suffix_$(CONFIG_KERNEL_LZMA) = lzma
+suffix-$(CONFIG_KERNEL_GZIP) = gz
+suffix-$(CONFIG_KERNEL_BZIP2) = bz2
+suffix-$(CONFIG_KERNEL_LZMA) = lzma
$(obj)/piggy.o: $(obj)/vmlinux.scr $(obj)/vmlinux.bin.$(suffix-y) FORCE
$(call if_changed,ld)
diff --git a/arch/m32r/boot/compressed/misc.c b/arch/m32r/boot/compressed/misc.c
index 370d608..28a0952 100644
--- a/arch/m32r/boot/compressed/misc.c
+++ b/arch/m32r/boot/compressed/misc.c
@@ -28,7 +28,7 @@ static unsigned long free_mem_ptr;
static unsigned long free_mem_end_ptr;
#ifdef CONFIG_KERNEL_BZIP2
-static void *memset(void *s, int c, size_t n)
+void *memset(void *s, int c, size_t n)
{
char *ss = s;
@@ -39,6 +39,16 @@ static void *memset(void *s, int c, size_t n)
#endif
#ifdef CONFIG_KERNEL_GZIP
+void *memcpy(void *dest, const void *src, size_t n)
+{
+ char *d = dest;
+ const char *s = src;
+ while (n--)
+ *d++ = *s++;
+
+ return dest;
+}
+
#define BOOT_HEAP_SIZE 0x1
#include "../../../../lib/decompress_inflate.c"
#endif
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 8c45818..8375622 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3737,10 +3737,6 @@ static int decode_operand(struct x86_emulate_ctxt *ctxt,
struct operand *op,
break;
case OpMem8:
ctxt->memop.bytes = 1;
- if (ctxt->memop.type == OP_REG) {
- ctxt->memop.addr.reg = decode_register(ctxt,
ctxt->modrm_rm, 1);
- fetch_register_operand(&ctxt->memop);
- }
goto mem_common;
case OpMem16:
ctxt->memop.bytes = 2;
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d9f8358..80103bb 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3750,11 +3750,17 @@ static int bond_neigh_init(struct neighbour *n)
* The bonding ndo_neigh_setup is called at init time beofre any
* slave exists. So we must declare proxy setup function which will
* be used at run time to resolve the actual slave neigh param setup.
+ *
+ * It's also called by master devices (such as vlans) to setup their
+ * underlying devices. In that case - do nothing, we're already set up from
+ * our init.
*/
static int bond_neigh_setup(struct net_device *dev,
struct neigh_parms *parms)
{
- parms->neigh_setup = bond_neigh_init;
+ /* modify only our neigh_parms */
+ if (parms->dev == dev)
+ parms->neigh_setup = bond_neigh_init;
return 0;
}
diff --git a/drivers/net/ethernet/realtek/8139cp.c
b/drivers/net/ethernet/realtek/8139cp.c
index 2205db7..1b44047 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -524,6 +524,7 @@ rx_status_loop:
PCI_DMA_FROMDEVICE);
if (dma_mapping_error(&cp->pdev->dev, new_mapping)) {
dev->stats.rx_dropped++;
+ kfree_skb(new_skb);
goto rx_next;
}
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 5151f06..77ce8b2 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -642,6 +642,28 @@ static int macvtap_skb_to_vnet_hdr(const struct sk_buff
*skb,
return 0;
}
+static unsigned long iov_pages(const struct iovec *iv, int offset,
+ unsigned long nr_segs)
+{
+ unsigned long seg, base;
+ int pages = 0, len, size;
+
+ while (nr_segs && (offset >= iv->iov_len)) {
+ offset -= iv->iov_len;
+ ++iv;
+ --nr_segs;
+ }
+
+ for (seg = 0; seg < nr_segs; seg++) {
+ base = (unsigned long)iv[seg].iov_base + offset;
+ len = iv[seg].iov_len - offset;
+ size = ((base & ~PAGE_MASK) + len + ~PAGE_MASK) >> PAGE_SHIFT;
+ pages += size;
+ offset = 0;
+ }
+
+ return pages;
+}
/* Get packet from user space buffer */
static ssize_t macvtap_get_user(struct macvtap_queue *q, struct msghdr *m,
@@ -688,31 +710,15 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q,
struct msghdr *m,
if (unlikely(count > UIO_MAXIOV))
goto err;
- if (m && m->msg_control &
Linux 3.4.62
I'm announcing the release of the 3.4.62 kernel. All users of the 3.4 kernel series must upgrade. The updated 3.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 - arch/m32r/boot/compressed/Makefile|6 +-- arch/m32r/boot/compressed/misc.c | 12 ++ arch/x86/kvm/emulate.c|4 -- drivers/net/bonding/bond_main.c |8 +++- drivers/net/ethernet/realtek/8139cp.c |1 drivers/net/macvtap.c | 62 -- drivers/net/tun.c |6 ++- drivers/vhost/vhost.c |1 include/linux/icmpv6.h|2 + include/linux/ipv6.h |1 net/bridge/br_multicast.c |3 + net/core/neighbour.c | 10 +++-- net/core/sysctl_net_core.c|7 +++ net/ipv4/fib_trie.c |5 -- net/ipv4/tcp_cubic.c | 12 +++--- net/ipv6/addrconf.c | 10 ++--- net/ipv6/icmp.c | 10 - net/ipv6/ip6_fib.c| 16 ++-- net/ipv6/ndisc.c | 16 net/ipv6/reassembly.c |5 ++ net/ipv6/tcp_ipv6.c |2 - net/sched/sch_htb.c |2 - net/tipc/eth_media.c | 15 +++- 24 files changed, 145 insertions(+), 73 deletions(-) Dan Carpenter (1): tun: signedness bug in tun_get_user() Daniel Borkmann (2): net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv Dave Jones (1): 8139cp: Fix skb leak in rx_status_loop failure path. Eric Dumazet (3): fib_trie: remove potential out of bound access tcp: cubic: fix overflow error in bictcp_update() tcp: cubic: fix bug in bictcp_acked() Geert Uytterhoeven (3): m32r: consistently use "suffix-$(...)" m32r: add memcpy() for CONFIG_KERNEL_GZIP=y m32r: make memset() global for CONFIG_KERNEL_BZIP2=y Greg Kroah-Hartman (2): Revert "KVM: X86 emulator: fix source operand decoding for 8bit mov[zs]x instructions" Linux 3.4.62 Hannes Frederic Sowa (3): ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match ipv6: remove max_addresses check from ipv6_create_tempaddr ipv6: drop packets with multiple fragmentation headers Jason Wang (2): vhost: zerocopy: poll vq in zerocopy callback macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS Jiri Bohac (1): ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO Roman Gushchin (1): net: check net.core.somaxconn sysctl values Thomas Graf (1): ipv6: Don't depend on per socket memory for neighbour discovery messages Veaceslav Falico (2): neighbour: populate neigh_parms on alloc before calling ndo_neigh_setup bonding: modify only neigh_parms owned by us Ying Xue (1): tipc: fix lockdep warning during bearer initialization stephen hemminger (1): htb: fix sign extension bug signature.asc Description: Digital signature
Linux 3.10.12
I'm announcing the release of the 3.10.12 kernel.
All users of the 3.10 kernel series must upgrade.
The updated 3.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.10.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
Makefile|2
arch/arm/boot/dts/at91sam9260.dtsi | 10
arch/x86/include/asm/xor_avx.h |4 -
drivers/net/bonding/bond_main.c |8 ++-
drivers/net/ethernet/broadcom/tg3.c | 18 ++-
drivers/net/ethernet/emulex/benet/be_main.c |2
drivers/net/ethernet/marvell/mvneta.c | 13 +
drivers/net/ethernet/realtek/8139cp.c |1
drivers/net/ethernet/sfc/filter.c |2
drivers/net/macvlan.c |4 +
drivers/net/tun.c |6 +-
drivers/net/usb/cdc_mbim.c |4 +
drivers/net/vxlan.c |2
drivers/net/wireless/mwifiex/main.c | 14 -
drivers/rtc/rtc-max77686.c |4 -
drivers/vhost/net.c |9 ++-
include/linux/ipv6.h|1
include/net/genetlink.h | 20 +++-
include/net/ip_tunnels.h| 14 -
include/net/sch_generic.h |9 +++
include/uapi/linux/icmpv6.h |2
include/uapi/linux/pkt_sched.h | 10 +++-
net/bridge/br_fdb.c | 10 ++--
net/bridge/br_multicast.c |5 +-
net/bridge/br_netlink.c |4 -
net/bridge/br_vlan.c|4 -
net/core/flow_dissector.c | 11 +---
net/core/neighbour.c| 10 ++--
net/core/rtnetlink.c|4 -
net/core/sysctl_net_core.c |6 ++
net/ipv4/devinet.c |4 +
net/ipv4/fib_trie.c |5 --
net/ipv4/ip_gre.c |2
net/ipv4/ip_tunnel.c|2
net/ipv4/raw.c |3 -
net/ipv4/tcp.c |7 ++
net/ipv4/tcp_cubic.c| 12 ++---
net/ipv4/tcp_input.c|9 ++-
net/ipv4/tcp_output.c |4 +
net/ipv6/addrconf.c | 10 +---
net/ipv6/addrlabel.c| 48 +---
net/ipv6/icmp.c | 10 +++-
net/ipv6/ip6_fib.c | 16 +-
net/ipv6/ndisc.c| 14 +++--
net/ipv6/reassembly.c |5 ++
net/ipv6/tcp_ipv6.c |2
net/netlink/genetlink.c | 67 ++--
net/packet/af_packet.c |2
net/sched/sch_api.c | 41 +
net/sched/sch_generic.c |1
net/sched/sch_htb.c | 15 +-
net/tipc/socket.c |4 -
52 files changed, 345 insertions(+), 151 deletions(-)
Andrew Vagin (2):
tcp: initialize rcv_tstamp for restored sockets
tcp: don't apply tsoffset if rcv_tsecr is zero
Andrey Vagin (1):
tcp: set timestamps for restored skb-s
Asbjoern Sloth Toennesen (1):
rtnetlink: rtnl_bridge_getlink: Call nlmsg_find_attr() with ifinfomsg
header
Ben Hutchings (1):
sfc: Fix lookup of default RX MAC filters when steered using ethtool
Bing Zhao (1):
mwifiex: do not create AP and P2P interfaces upon driver loading
Chris Clark (1):
ipv4: sendto/hdrincl: don't use destination address found in header
Dan Carpenter (1):
tun: signedness bug in tun_get_user()
Daniel Borkmann (3):
net: rtm_to_ifaddr: free ifa if ifa_cacheinfo processing fails
net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay
net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv
Dave Jones (1):
8139cp: Fix skb leak in rx_status_loop failure path.
Eric Dumazet (4):
fib_trie: remove potential out of bound access
tcp: cubic: fix overflow error in bictcp_update()
tcp: cubic: fix bug in bictcp_acked()
net: revert 8728c544a9c ("net: dev_pick_tx() fix")
Erik Hugne (1):
tipc: set sk_err correctly when connection fails
Greg Kroah-Hartman (1):
Linux 3.10.12
Hannes Frederic Sowa (4):
ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match
ipv6: remove max_addresses check from ipv6_create_tempaddr
ipv6: drop packets with multiple fragmentation headers
ipv6: fix null pointer dereference in __ip6addrl
Linux 3.11.1
I'm announcing the release of the 3.11.1 kernel. All users of the 3.11 kernel series must upgrade. The updated 3.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.11.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/hwmon/k10temp |1 + Makefile |2 +- arch/x86/include/asm/xor_avx.h|4 ++-- drivers/acpi/ec.c |4 drivers/hv/channel_mgmt.c | 14 +++--- drivers/hwmon/Kconfig |4 ++-- drivers/hwmon/k10temp.c |3 ++- drivers/misc/hpilo.c |4 ++-- drivers/misc/mei/hw-me.c |9 +++-- drivers/net/wireless/mwifiex/main.c | 14 -- drivers/rtc/rtc-max77686.c|4 ++-- drivers/staging/imx-drm/imx-drm-core.c|1 + drivers/target/iscsi/iscsi_target.c | 17 ++--- drivers/target/iscsi/iscsi_target_login.c |9 - drivers/target/target_core_spc.c |9 ++--- drivers/target/target_core_transport.c| 11 +++ drivers/usb/gadget/f_acm.c|1 + sound/soc/fsl/Kconfig |4 ++-- sound/soc/fsl/imx-pcm.h |4 ++-- 19 files changed, 63 insertions(+), 56 deletions(-) Bing Zhao (1): mwifiex: do not create AP and P2P interfaces upon driver loading Fabio Estevam (2): ASoC: fsl: Fix module build imx-drm: imx-drm-core: Export imx_drm_encoder_get_mux_id Graham Williams (1): usb: acm gadget: Null termintate strings table Greg Kroah-Hartman (1): Linux 3.11.1 John Haxby (1): crypto: xor - Check for osxsave as well as avx in crypto/xor K. Y. Srinivasan (1): Drivers: hv: vmbus: Fix a bug in the handling of channel offers Lan Tianyu (1): ACPI / EC: Add ASUSTEK L4R to quirk list in order to validate ECDT Mark Rusk (1): drivers/misc/hpilo: Correct panic when an AUX iLO is detected Nicholas Bellinger (5): target: Fix trailing ASCII space usage in INQUIRY vendor+model iscsi-target: Fix ImmediateData=Yes failure regression in >= v3.10 iscsi-target: Fix iscsit_transport reference leak during NP thread reset iscsi-target: Fix potential NULL pointer in solicited NOPOUT reject target: Fix se_cmd->state_list leak regression during WRITE failure Sangjung Woo (1): drivers/rtc/rtc-max77686.c: Fix wrong register Tomas Winkler (1): mei: me: fix hardware reset flow Wei Hu (1): hwmon: (k10temp) Add support for Fam16h (Kabini) signature.asc Description: Digital signature
Re: Linux 3.10.12
diff --git a/Makefile b/Makefile
index 595076d..afe001e 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 10
-SUBLEVEL = 11
+SUBLEVEL = 12
EXTRAVERSION =
NAME = TOSSUG Baby Fish
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index 84c4bef..43a18f7 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -340,6 +340,14 @@
};
};
+ i2c_gpio0 {
+ pinctrl_i2c_gpio0: i2c_gpio0-0 {
+ atmel,pins =
+ <0 23 0x0 0x3 /* PA23
gpio I2C_SDA pin */
+0 24 0x0 0x3>; /* PA24
gpio I2C_SCL pin */
+ };
+ };
+
pioA: gpio@f400 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xf400 0x200>;
@@ -592,6 +600,8 @@
i2c-gpio,delay-us = <2>;/* ~100 kHz */
#address-cells = <1>;
#size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c_gpio0>;
status = "disabled";
};
};
diff --git a/arch/x86/include/asm/xor_avx.h b/arch/x86/include/asm/xor_avx.h
index 7ea79c5..492b298 100644
--- a/arch/x86/include/asm/xor_avx.h
+++ b/arch/x86/include/asm/xor_avx.h
@@ -167,12 +167,12 @@ static struct xor_block_template xor_block_avx = {
#define AVX_XOR_SPEED \
do { \
- if (cpu_has_avx) \
+ if (cpu_has_avx && cpu_has_osxsave) \
xor_speed(&xor_block_avx); \
} while (0)
#define AVX_SELECT(FASTEST) \
- (cpu_has_avx ? &xor_block_avx : FASTEST)
+ (cpu_has_avx && cpu_has_osxsave ? &xor_block_avx : FASTEST)
#else
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index f975696..666cf3a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3770,11 +3770,17 @@ static int bond_neigh_init(struct neighbour *n)
* The bonding ndo_neigh_setup is called at init time beofre any
* slave exists. So we must declare proxy setup function which will
* be used at run time to resolve the actual slave neigh param setup.
+ *
+ * It's also called by master devices (such as vlans) to setup their
+ * underlying devices. In that case - do nothing, we're already set up from
+ * our init.
*/
static int bond_neigh_setup(struct net_device *dev,
struct neigh_parms *parms)
{
- parms->neigh_setup = bond_neigh_init;
+ /* modify only our neigh_parms */
+ if (parms->dev == dev)
+ parms->neigh_setup = bond_neigh_init;
return 0;
}
diff --git a/drivers/net/ethernet/broadcom/tg3.c
b/drivers/net/ethernet/broadcom/tg3.c
index a13463e..0877a05 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -3003,6 +3003,19 @@ static bool tg3_phy_power_bug(struct tg3 *tp)
return false;
}
+static bool tg3_phy_led_bug(struct tg3 *tp)
+{
+ switch (tg3_asic_rev(tp)) {
+ case ASIC_REV_5719:
+ if ((tp->phy_flags & TG3_PHYFLG_MII_SERDES) &&
+ !tp->pci_fn)
+ return true;
+ return false;
+ }
+
+ return false;
+}
+
static void tg3_power_down_phy(struct tg3 *tp, bool do_low_power)
{
u32 val;
@@ -3050,8 +3063,9 @@ static void tg3_power_down_phy(struct tg3 *tp, bool
do_low_power)
}
return;
} else if (do_low_power) {
- tg3_writephy(tp, MII_TG3_EXT_CTRL,
-MII_TG3_EXT_CTRL_FORCE_LED_OFF);
+ if (!tg3_phy_led_bug(tp))
+ tg3_writephy(tp, MII_TG3_EXT_CTRL,
+MII_TG3_EXT_CTRL_FORCE_LED_OFF);
val = MII_TG3_AUXCTL_PCTL_100TX_LPWR |
MII_TG3_AUXCTL_PCTL_SPR_ISOLATE |
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
b/drivers/net/ethernet/emulex/benet/be_main.c
index 6e43426..7371626 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -2561,8 +2561,8 @@ static int be_close(struct net_device *netdev)
/* Wait for all pending tx completions to arrive so that
* all tx skbs are freed.
*/
- be_tx_compl_clean(adapter);
netif_tx_disable(netdev);
+ be_tx_compl_clean(adapter);
be_rx_qs_destroy(adapter);
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell/mvneta.c
index c966785..254f255 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/
Re: Linux 3.11.1
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp
index 90956b6..4dfdc8f 100644
--- a/Documentation/hwmon/k10temp
+++ b/Documentation/hwmon/k10temp
@@ -12,6 +12,7 @@ Supported chips:
* AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
* AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity"
+* AMD Family 16h processors: "Kabini"
Prefix: 'k10temp'
Addresses scanned: PCI space
diff --git a/Makefile b/Makefile
index fe8204b..efd2396 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 11
-SUBLEVEL = 0
+SUBLEVEL = 1
EXTRAVERSION =
NAME = Linux for Workgroups
diff --git a/arch/x86/include/asm/xor_avx.h b/arch/x86/include/asm/xor_avx.h
index 7ea79c5..492b298 100644
--- a/arch/x86/include/asm/xor_avx.h
+++ b/arch/x86/include/asm/xor_avx.h
@@ -167,12 +167,12 @@ static struct xor_block_template xor_block_avx = {
#define AVX_XOR_SPEED \
do { \
- if (cpu_has_avx) \
+ if (cpu_has_avx && cpu_has_osxsave) \
xor_speed(&xor_block_avx); \
} while (0)
#define AVX_SELECT(FASTEST) \
- (cpu_has_avx ? &xor_block_avx : FASTEST)
+ (cpu_has_avx && cpu_has_osxsave ? &xor_block_avx : FASTEST)
#else
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 80403c1..45af90a 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -987,6 +987,10 @@ static struct dmi_system_id __initdata ec_dmi_table[] = {
ec_skip_dsdt_scan, "HP Folio 13", {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13"),}, NULL},
+ {
+ ec_validate_ecdt, "ASUS hardware", {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL},
{},
};
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 0df7590..461f47b 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -262,6 +262,13 @@ static void vmbus_process_offer(struct work_struct *work)
}
/*
+* This state is used to indicate a successful open
+* so that when we do close the channel normally, we
+* can cleanup properly
+*/
+ newchannel->state = CHANNEL_OPEN_STATE;
+
+ /*
* Start the process of binding this offer to the driver
* We need to set the DeviceObject field before calling
* vmbus_child_dev_add()
@@ -287,13 +294,6 @@ static void vmbus_process_offer(struct work_struct *work)
kfree(newchannel->device_obj);
free_channel(newchannel);
- } else {
- /*
-* This state is used to indicate a successful open
-* so that when we do close the channel normally, we
-* can cleanup properly
-*/
- newchannel->state = CHANNEL_OPEN_STATE;
}
}
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index e989f7f..1e27838 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -296,8 +296,8 @@ config SENSORS_K10TEMP
If you say yes here you get support for the temperature
sensor(s) inside your CPU. Supported are later revisions of
the AMD Family 10h and all revisions of the AMD Family 11h,
- 12h (Llano), 14h (Brazos) and 15h (Bulldozer/Trinity)
- microarchitectures.
+ 12h (Llano), 14h (Brazos), 15h (Bulldozer/Trinity) and
+ 16h (Kabini) microarchitectures.
This driver can also be built as a module. If so, the module
will be called k10temp.
diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index e3b037c..e633856 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -1,5 +1,5 @@
/*
- * k10temp.c - AMD Family 10h/11h/12h/14h/15h processor hardware monitoring
+ * k10temp.c - AMD Family 10h/11h/12h/14h/15h/16h processor hardware monitoring
*
* Copyright (c) 2009 Clemens Ladisch
*
@@ -211,6 +211,7 @@ static DEFINE_PCI_DEVICE_TABLE(k10temp_id_table) = {
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M10H_F3) },
+ { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F3) },
{}
};
MODULE_DEVICE_TABLE(pci, k10temp_id_table);
diff --git a/drivers/misc/hpilo.c b/drivers/misc/hpilo.c
index 621c7a3..b83e3ca 100644
--- a/drivers/misc/hpilo.c
+++ b/drivers/misc/hpilo.c
@@ -759,7 +759,7 @@ static int ilo_probe(struct pci_dev *pdev,
/* Ignore subsystem_device = 0x1979 (set by BIOS) */
if (pdev->subsystem_device == 0x1979)
- goto out;
+ return 0;
if (max_ccb > MAX_CCB)
max_ccb = MAX_CCB;
@@ -899,7 +899,7 @@ static void __exit ilo_exit(void)
class_destroy(ilo_class);
}
-MODULE_VERSION("1.4");
+MODULE_VERSION("1.4.1");
MODULE_ALIAS(ILO
Re: scripts/config: fix variable substitution command
2013/9/14 Sedat Dilek :
> Hi,
>
> The ChangeLog from [1] says:
>
> Commit 229455bc02b87f7128f190c4491b4ce38648 accidentally changed
> the separator between sed `s' command and its parameters from ':' to
> '/'.
> Revert this change.
>
> Reported-and-tested-by: Linus Walleij
> Signed-off-by: Clement Chauplannaz
> Signed-off-by: Michal Marek
>
> *** Bad commit reference: 229455bc02b87f7128f190c4491b4ce38648 ***
> (Linus-tree)
>
> To quote [2] and see its EXAMPLE:
>
> "If you want to refer to a specific commit, don't just refer to the
> SHA-1 ID of the commit. Please also include the oneline summary of
> the commit, to make it easier for reviewers to know what it is about.
>
> Example:
>
> Commit e21d2170f36602ae2708 ("video: remove unnecessary
> platform_set_drvdata()") removed the unnecessary
> platform_set_drvdata(), but left the variable "dev" unused,
> delete it."
>
> That's why the commit-id without the subject-line is no good help.
> It does not help anyone when you reference a local GIT or linux-kbuild
> GIT related commit-id.
>
> So, can you point me/us to the correct commit with subject, please?!
> Is this patch even "CC: stable"?
>
> Thanks.
>
> Regards,
> - Sedat -
>
>
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=86eb781889ec31f6421b86ab252ea609d456322d
> [2]
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n112
Hi Sedat,
My apologies for that mistake. The initial commit, as present in Linus tree, is:
83e8b90e1d2cc5ff5d2443f2486c2d786a4997ce - scripts/config: use sed's
POSIX interface
Thus, the commit message for this patch should read:
scripts/config: fix variable substitution command
Commit 83e8b90e1d2cc5ff5d2443f2486c2d786a4997ce ("scripts/config: use sed's
POSIX interface") accidentally changed the separator between sed `s' command
and its parameters from ':' to '/'.
Revert this change.
Reported-and-tested-by: Linus Walleij
Signed-off-by: Clement Chauplannaz
Signed-off-by: Michal Marek
Regards,
Clement
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ptp: measure the time offset between PHC and system clock
On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote:
> This patch add a method into testptp.c to measure the time offset
> between phc and system clock through the ioctl PTP_SYS_OFFSET.
>
This is a nice addition to the testptp program. I do have a few
comments, below.
First off, the subject line should mention testptp. How about this?
[PATCH] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program
> Signed-off-by: Dong Zhu
> ---
> Documentation/ptp/testptp.c | 40 ++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
> index f59ded0..72bb030 100644
> --- a/Documentation/ptp/testptp.c
> +++ b/Documentation/ptp/testptp.c
> @@ -112,6 +112,7 @@ static void usage(char *progname)
> " -f val adjust the ptp clock frequency by 'val' ppb\n"
> " -g get the ptp clock time\n"
> " -h prints this message\n"
> + " -k val measure the time offset between PHC and system
> clock\n"
The help message should tell the user what 'val' is.
> " -p val enable output with a period of 'val' nanoseconds\n"
> " -P val enable or disable (val=1|0) the system clock PPS\n"
> " -s set the ptp clock time from the system time\n"
> @@ -133,8 +134,12 @@ int main(int argc, char *argv[])
> struct itimerspec timeout;
> struct sigevent sigevent;
>
> + struct ptp_clock_time *pct;
> + struct ptp_sys_offset *sysoff;
> +
> +
> char *progname;
> - int c, cnt, fd;
> + int i, c, cnt, fd;
>
> char *device = DEVICE;
> clockid_t clkid;
> @@ -144,6 +149,8 @@ int main(int argc, char *argv[])
> int extts = 0;
> int gettime = 0;
> int oneshot = 0;
> + int offset = 0;
> + int n_samples = 0;
> int periodic = 0;
> int perout = -1;
> int pps = -1;
> @@ -151,7 +158,7 @@ int main(int argc, char *argv[])
>
> progname = strrchr(argv[0], '/');
> progname = progname ? 1+progname : argv[0];
> - while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
> + while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) {
> switch (c) {
> case 'a':
> oneshot = atoi(optarg);
> @@ -174,6 +181,10 @@ int main(int argc, char *argv[])
> case 'g':
> gettime = 1;
> break;
> + case 'k':
> + offset = 1;
> + n_samples = atoi(optarg);
> + break;
> case 'p':
> perout = atoi(optarg);
> break;
> @@ -376,6 +387,31 @@ int main(int argc, char *argv[])
> }
> }
>
> + if (offset) {
> + sysoff = calloc(1, sizeof(*sysoff));
> + if (!sysoff) {
> + perror("calloc");
> + return -1;
> + }
> + sysoff->n_samples = n_samples;
> +
> + if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
> + perror("PTP_SYS_OFFSET");
> + else
> + puts("time offset between PHC and
> + system clock request okay");
> +
> + pct = &sysoff->ts[0];
> + for (i = 0; i < sysoff->n_samples; i++, pct++) {
> + printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
> + pct++;
> + printf("phctime: %ld.%ld\n\n", pct->sec, pct->nsec);
I think the output would look nicer with only one newline. After all,
each measurement is a {sys,phc,sys} triplet and not a {sys,phc} pair.
> + }
> + printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
> +
> + free(sysoff);
> + }
> +
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: scripts/config: fix variable substitution command
On Sat, Sep 14, 2013 at 4:21 PM, Clément Chauplannaz wrote:
> 2013/9/14 Sedat Dilek :
>> Hi,
>>
>> The ChangeLog from [1] says:
>>
>> Commit 229455bc02b87f7128f190c4491b4ce38648 accidentally changed
>> the separator between sed `s' command and its parameters from ':' to
>> '/'.
>> Revert this change.
>>
>> Reported-and-tested-by: Linus Walleij
>> Signed-off-by: Clement Chauplannaz
>> Signed-off-by: Michal Marek
>>
>> *** Bad commit reference: 229455bc02b87f7128f190c4491b4ce38648 ***
>> (Linus-tree)
>>
>> To quote [2] and see its EXAMPLE:
>>
>> "If you want to refer to a specific commit, don't just refer to the
>> SHA-1 ID of the commit. Please also include the oneline summary of
>> the commit, to make it easier for reviewers to know what it is about.
>>
>> Example:
>>
>> Commit e21d2170f36602ae2708 ("video: remove unnecessary
>> platform_set_drvdata()") removed the unnecessary
>> platform_set_drvdata(), but left the variable "dev" unused,
>> delete it."
>>
>> That's why the commit-id without the subject-line is no good help.
>> It does not help anyone when you reference a local GIT or linux-kbuild
>> GIT related commit-id.
>>
>> So, can you point me/us to the correct commit with subject, please?!
>> Is this patch even "CC: stable"?
>>
>> Thanks.
>>
>> Regards,
>> - Sedat -
>>
>>
>> [1]
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=86eb781889ec31f6421b86ab252ea609d456322d
>> [2]
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n112
>
>
> Hi Sedat,
>
> My apologies for that mistake. The initial commit, as present in Linus tree,
> is:
> 83e8b90e1d2cc5ff5d2443f2486c2d786a4997ce - scripts/config: use sed's
> POSIX interface
>
> Thus, the commit message for this patch should read:
> scripts/config: fix variable substitution command
>
> Commit 83e8b90e1d2cc5ff5d2443f2486c2d786a4997ce ("scripts/config: use sed's
> POSIX interface") accidentally changed the separator between sed `s' command
> and its parameters from ':' to '/'.
>
> Revert this change.
>
> Reported-and-tested-by: Linus Walleij
> Signed-off-by: Clement Chauplannaz
> Signed-off-by: Michal Marek
>
What means "pending" [1]?
Pending in sense of "we are working on it" or in the sense of
"exists-but-not-published".
I did not found a hint on the offline linux-kbuild ML.
BTW, the GIT repo of Yann is not browsable (which is sh*t for checking
commits quickl, I don't want to be forced to checkout).
- Sedat -
[1] http://marc.info/?l=linux-kbuild&m=137907590807755&w=2
[2] https://www.gitorious.org/linux-kconfig/linux-kconfig/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: char: misc: 'misc_deregister()' changed the 'mutex_unlock' logic upon an error
From: Elad Wexler
This change improves code readability & is less error-prone.
For example: case adding more error paths one should remember to call
'mutex_unlock'
Signed-off-by: Elad Wexler
---
drivers/char/misc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index 190d442..dd91726 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -193,8 +193,8 @@ int misc_register(struct miscdevice * misc)
if (misc->minor == MISC_DYNAMIC_MINOR) {
int i = find_first_zero_bit(misc_minors, DYNAMIC_MINORS);
if (i >= DYNAMIC_MINORS) {
- mutex_unlock(&misc_mtx);
- return -EBUSY;
+ err = -EBUSY;
+ goto out;
}
misc->minor = DYNAMIC_MINORS - i - 1;
set_bit(i, misc_minors);
@@ -203,8 +203,8 @@ int misc_register(struct miscdevice * misc)
list_for_each_entry(c, &misc_list, list) {
if (c->minor == misc->minor) {
- mutex_unlock(&misc_mtx);
- return -EBUSY;
+ err = -EBUSY;
+ goto out;
}
}
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: Fix task_h_load calculation
Patch a003a2 (sched: Consider runnable load average in move_tasks())
sets all top-level cfs_rqs' h_load to rq->avg.load_avg_contrib, which is
always 0. This mistype leads to all tasks having weight 0 when load
balancing in a cpu-cgroup enabled setup. There obviously should be sum
of weights of all runnable tasks there instead. Fix it.
Signed-off-by: Vladimir Davydov
---
kernel/sched/fair.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9b3fe1c..13abc29 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4242,7 +4242,7 @@ static void update_cfs_rq_h_load(struct cfs_rq *cfs_rq)
}
if (!se) {
- cfs_rq->h_load = rq->avg.load_avg_contrib;
+ cfs_rq->h_load = cfs_rq->runnable_load_avg;
cfs_rq->last_h_load_update = now;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ptp: add the PTP_SYS_OFFSET ioctl to the testptp program clock
On Sat, Sep 14, 2013 at 04:31:46PM +0200, Richard Cochran wrote:
> On Sat, Sep 14, 2013 at 04:03:06PM +0800, Dong Zhu wrote:
> > This patch add a method into testptp.c to measure the time offset
> > between phc and system clock through the ioctl PTP_SYS_OFFSET.
> >
>
> This is a nice addition to the testptp program. I do have a few
> comments, below.
>
Thanks very much for your comments, I have modified the patch as below,
Cuold you have a look at it again ? Any comments would be appreciated.
>From 655b45785a85599d5fff5eb3b8d9b49b72f2991f Mon Sep 17 00:00:00 2001
From: Dong Zhu
Date: Sat, 14 Sep 2013 23:32:14 +0800
This patch add a method into testptp.c to measure the time offset
between phc and system clock through the ioctl PTP_SYS_OFFSET.
Signed-off-by: Dong Zhu
---
Documentation/ptp/testptp.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
index f59ded0..8acdc70 100644
--- a/Documentation/ptp/testptp.c
+++ b/Documentation/ptp/testptp.c
@@ -112,6 +112,8 @@ static void usage(char *progname)
" -f val adjust the ptp clock frequency by 'val' ppb\n"
" -g get the ptp clock time\n"
" -h prints this message\n"
+ " -k val measure the time offset between phc and system
clock "
+ "for 'val' times (Maximum 25)\n"
" -p val enable output with a period of 'val' nanoseconds\n"
" -P val enable or disable (val=1|0) the system clock PPS\n"
" -s set the ptp clock time from the system time\n"
@@ -133,8 +135,12 @@ int main(int argc, char *argv[])
struct itimerspec timeout;
struct sigevent sigevent;
+ struct ptp_clock_time *pct;
+ struct ptp_sys_offset *sysoff;
+
+
char *progname;
- int c, cnt, fd;
+ int i, c, cnt, fd;
char *device = DEVICE;
clockid_t clkid;
@@ -144,6 +150,8 @@ int main(int argc, char *argv[])
int extts = 0;
int gettime = 0;
int oneshot = 0;
+ int offset = 0;
+ int n_samples = 0;
int periodic = 0;
int perout = -1;
int pps = -1;
@@ -151,7 +159,7 @@ int main(int argc, char *argv[])
progname = strrchr(argv[0], '/');
progname = progname ? 1+progname : argv[0];
- while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
+ while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) {
switch (c) {
case 'a':
oneshot = atoi(optarg);
@@ -174,6 +182,10 @@ int main(int argc, char *argv[])
case 'g':
gettime = 1;
break;
+ case 'k':
+ offset = 1;
+ n_samples = atoi(optarg);
+ break;
case 'p':
perout = atoi(optarg);
break;
@@ -376,6 +388,30 @@ int main(int argc, char *argv[])
}
}
+ if (offset) {
+ sysoff = calloc(1, sizeof(*sysoff));
+ if (!sysoff) {
+ perror("calloc");
+ return -1;
+ }
+ sysoff->n_samples = n_samples;
+
+ if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
+ perror("PTP_SYS_OFFSET");
+ else
+ puts("phc and system clock time offset request okay");
+
+ pct = &sysoff->ts[0];
+ for (i = 0; i < sysoff->n_samples; i++, pct++) {
+ printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
+ pct++;
+ printf("phctime: %ld.%ld\n", pct->sec, pct->nsec);
+ }
+ printf("system time: %ld.%ld\n", pct->sec, pct->nsec);
+
+ free(sysoff);
+ }
+
close(fd);
return 0;
}
--
1.7.11.7
--
Best Regards,
Dong Zhu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 18/38] iio: sensors-core: st: Allow full-scale to be an optional feature
On 09/10/13 13:49, Lee Jones wrote:
> Some chips either don't support it or fail to provide adequate documentation,
> so sometimes it's impossible to enable the feature even if it is supported.
>
> Signed-off-by: Lee Jones
Applied to the togreg branch of iio.git
Thanks
> ---
> drivers/iio/common/st_sensors/st_sensors_core.c | 11 +++
> drivers/iio/pressure/st_pressure_core.c | 6 --
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c
> b/drivers/iio/common/st_sensors/st_sensors_core.c
> index 965ee22..eb261a5 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
> @@ -235,10 +235,13 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev,
> if (err < 0)
> goto init_error;
>
> - err = st_sensors_set_fullscale(indio_dev,
> - sdata->current_fullscale->num);
> - if (err < 0)
> - goto init_error;
> + if (sdata->current_fullscale) {
> + err = st_sensors_set_fullscale(indio_dev,
> +sdata->current_fullscale->num);
> + if (err < 0)
> + goto init_error;
> + } else
> + dev_info(&indio_dev->dev, "Full-scale not possible\n");
>
> err = st_sensors_set_odr(indio_dev, sdata->odr);
> if (err < 0)
> diff --git a/drivers/iio/pressure/st_pressure_core.c
> b/drivers/iio/pressure/st_pressure_core.c
> index ceebd3c..16cfbc5 100644
> --- a/drivers/iio/pressure/st_pressure_core.c
> +++ b/drivers/iio/pressure/st_pressure_core.c
> @@ -226,8 +226,10 @@ int st_press_common_probe(struct iio_dev *indio_dev,
> indio_dev->channels = pdata->sensor->ch;
> indio_dev->num_channels = ARRAY_SIZE(st_press_channels);
>
> - pdata->current_fullscale = (struct st_sensor_fullscale_avl *)
> - &pdata->sensor->fs.fs_avl[0];
> + if (pdata->sensor->fs.addr != 0)
> + pdata->current_fullscale = (struct st_sensor_fullscale_avl *)
> + &pdata->sensor->fs.fs_avl[0];
> +
> pdata->odr = pdata->sensor->odr.odr_avl[0].hz;
>
> if (!plat_data)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] argv_split: Return NULL if argument contains no non-whitespace.
On 09/14, Tetsuo Handa wrote:
>
> # echo '|' > /proc/sys/kernel/core_pattern
>
> and got
>
> BUG: unable to handle kernel NULL pointer dereference at (null)
Hmm. This was fixed by 264b83c07a8 "usermodehelper: check
subprocess_info->path != NULL".
But then this check was removed by 7f57cfa4e2a "usermodehelper:
kill the sub_info->path[0] check".
Note that the changelog says "do_execve(NULL) is safe" and I certainly
tested this case when I sent the patch...
Now it is crashes in path_openat() because pathname->name is NULL.
Something was changed, perhaps or (I'm afraid) I misread that code and
my testing was wrong. do_filp_open/etc were changed to accept
"struct filename *" a long ago.
> upon core dump because helper_argv[0] == NULL at
>
> helper_argv = argv_split(GFP_KERNEL, cn.corename, NULL);
> call_usermodehelper_setup(helper_argv[0], ...);
Are you sure? See above.
> --- a/lib/argv_split.c
> +++ b/lib/argv_split.c
> @@ -50,7 +50,7 @@ EXPORT_SYMBOL(argv_free);
> * quote processing is performed. Multiple whitespace characters are
> * considered to be a single argument separator. The returned array
> * is always NULL-terminated. Returns NULL on memory allocation
> - * failure.
> + * failure or @str being empty or @str containing only white-space.
> *
> * The source string at `str' may be undergoing concurrent alteration via
> * userspace sysctl activity (at least). The argv_split() implementation
> @@ -68,6 +68,10 @@ char **argv_split(gfp_t gfp, const char *str, int *argcp)
> return NULL;
>
> argc = count_argc(argv_str);
> + if (!argc) {
> + kfree(argv_str);
> + return NULL;
> + }
Yes, this is what 264b83c07a8 suggested... But I am not sure, if nothing
else pr_warn("failed to allocate memory") from do_coredump() doesn't look
nice in this case.
Perhaps
--- x/kernel/kmod.c
+++ x/kernel/kmod.c
@@ -571,6 +571,9 @@ int call_usermodehelper_exec(struct subp
DECLARE_COMPLETION_ONSTACK(done);
int retval = 0;
+ if (!sub_info->path)
+ return -EXXX;
+
helper_lock();
if (!khelper_wq || usermodehelper_disabled) {
retval = -EBUSY;
?
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 19/38] iio: sensors-core: st: Support sensors which don't have a Data Ready pin
On 09/10/13 13:49, Lee Jones wrote:
> Not all ST's sensors support data ready, so let's make the declaration
> of one conditional.
>
> Signed-off-by: Lee Jones
Hi Lee,
This one doesn't actually build:
CC [M] drivers/iio/common/st_sensors/st_sensors_core.o
drivers/iio/common/st_sensors/st_sensors_core.c: In function
'st_sensors_set_drdy_int_pin':
drivers/iio/common/st_sensors/st_sensors_core.c:211:4: error: 'err' undeclared
(first use in this function)
drivers/iio/common/st_sensors/st_sensors_core.c:211:4: note: each undeclared
identifier is reported only once for each
function it appears in
drivers/iio/common/st_sensors/st_sensors_core.c:228:3: error: label
'init_error' used but not defined
make[4]: *** [drivers/iio/common/st_sensors/st_sensors_core.o] Error 1
The following patch gets rid of these lines so I'm guessing you reorganised
your patch
series then didn't check buildling them in the new order.
Please fix this up before reposting the remainder of the series.
> ---
> drivers/iio/common/st_sensors/st_sensors_core.c | 24 +++-
> drivers/iio/pressure/st_pressure_core.c | 3 ++-
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c
> b/drivers/iio/common/st_sensors/st_sensors_core.c
> index eb261a5..b86cad2 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
> @@ -198,14 +198,11 @@ int st_sensors_set_axis_enable(struct iio_dev
> *indio_dev, u8 axis_enable)
> }
> EXPORT_SYMBOL(st_sensors_set_axis_enable);
>
> -int st_sensors_init_sensor(struct iio_dev *indio_dev,
> - struct st_sensors_platform_data *pdata)
> +int st_sensors_set_drdy_int_pin(struct iio_dev *indio_dev,
> + struct st_sensors_platform_data *pdata)
> {
> - int err;
> struct st_sensor_data *sdata = iio_priv(indio_dev);
>
> - mutex_init(&sdata->tb.buf_lock);
> -
> switch (pdata->drdy_int_pin) {
> case 1:
> if (sdata->sensor->drdy_irq.mask_int1 == 0) {
> @@ -231,6 +228,20 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev,
> goto init_error;
> }
>
> + return 0;
> +}
> +
> +int st_sensors_init_sensor(struct iio_dev *indio_dev,
> + struct st_sensors_platform_data *pdata)
> +{
> + int err = 0;
> + struct st_sensor_data *sdata = iio_priv(indio_dev);
> +
> + mutex_init(&sdata->tb.buf_lock);
> +
> + if (pdata)
> + err = st_sensors_set_drdy_int_pin(indio_dev, pdata);
> +
> err = st_sensors_set_enable(indio_dev, false);
> if (err < 0)
> goto init_error;
> @@ -266,6 +277,9 @@ int st_sensors_set_dataready_irq(struct iio_dev
> *indio_dev, bool enable)
> u8 drdy_mask;
> struct st_sensor_data *sdata = iio_priv(indio_dev);
>
> + if (!sdata->sensor->drdy_irq.addr)
> + return 0;
> +
> /* Enable/Disable the interrupt generator 1. */
> if (sdata->sensor->drdy_irq.ig1.en_addr > 0) {
> err = st_sensors_write_data_with_mask(indio_dev,
> diff --git a/drivers/iio/pressure/st_pressure_core.c
> b/drivers/iio/pressure/st_pressure_core.c
> index 16cfbc5..279aafd 100644
> --- a/drivers/iio/pressure/st_pressure_core.c
> +++ b/drivers/iio/pressure/st_pressure_core.c
> @@ -232,7 +232,8 @@ int st_press_common_probe(struct iio_dev *indio_dev,
>
> pdata->odr = pdata->sensor->odr.odr_avl[0].hz;
>
> - if (!plat_data)
> + /* Some devices don't support a data ready pin. */
> + if (!plat_data && pdata->sensor->drdy_irq.addr)
> plat_data =
> (struct st_sensors_platform_data *)&default_press_pdata;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 20/38] iio: sensors-core: st: Clean-up error handling in st_sensors_init_sensor()
On 09/10/13 13:49, Lee Jones wrote:
> Strip out all those unnecessary gotos and just return the error right away.
>
> Aids to simplicity and reduces code.
>
> Signed-off-by: Lee Jones
This is fine except in that it is intertwined with the previous patch.
> ---
> drivers/iio/common/st_sensors/st_sensors_core.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c
> b/drivers/iio/common/st_sensors/st_sensors_core.c
> index b86cad2..8c4c54c 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
> @@ -208,8 +208,7 @@ int st_sensors_set_drdy_int_pin(struct iio_dev *indio_dev,
> if (sdata->sensor->drdy_irq.mask_int1 == 0) {
> dev_err(&indio_dev->dev,
> "DRDY on INT1 not available.\n");
> - err = -EINVAL;
> - goto init_error;
> + return -EINVAL;
> }
> sdata->drdy_int_pin = 1;
> break;
> @@ -217,15 +216,13 @@ int st_sensors_set_drdy_int_pin(struct iio_dev
> *indio_dev,
> if (sdata->sensor->drdy_irq.mask_int2 == 0) {
> dev_err(&indio_dev->dev,
> "DRDY on INT2 not available.\n");
> - err = -EINVAL;
> - goto init_error;
> + return -EINVAL;
> }
> sdata->drdy_int_pin = 2;
> break;
> default:
> dev_err(&indio_dev->dev, "DRDY on pdata not valid.\n");
> - err = -EINVAL;
> - goto init_error;
> + return -EINVAL;
> }
>
> return 0;
> @@ -244,29 +241,28 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev,
>
> err = st_sensors_set_enable(indio_dev, false);
> if (err < 0)
> - goto init_error;
> + return err;
>
> if (sdata->current_fullscale) {
> err = st_sensors_set_fullscale(indio_dev,
> sdata->current_fullscale->num);
> if (err < 0)
> - goto init_error;
> + return err;
> } else
> dev_info(&indio_dev->dev, "Full-scale not possible\n");
>
> err = st_sensors_set_odr(indio_dev, sdata->odr);
> if (err < 0)
> - goto init_error;
> + return err;
>
> /* set BDU */
> err = st_sensors_write_data_with_mask(indio_dev,
> sdata->sensor->bdu.addr, sdata->sensor->bdu.mask, true);
> if (err < 0)
> - goto init_error;
> + return err;
>
> err = st_sensors_set_axis_enable(indio_dev, ST_SENSORS_ENABLE_ALL_AXIS);
>
> -init_error:
> return err;
> }
> EXPORT_SYMBOL(st_sensors_init_sensor);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: numa: adjust hinting fault record if page is migrated
On 09/14/2013 07:53 AM, Hillf Danton wrote: > After page A on source node is migrated to page B on target node, hinting > fault is recorded on the target node for B. On the source node there is > another record for A, since a two-stage filter is used when migrating pages. > > Page A is no longer used after migration, so we have to erase its record. What kind of performance changes have you observed with this patch? What benchmarks have you run, and on what kind of systems? -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 21/38] iio: sensors-core: st: Clean-up error handling in st_sensors_read_axis_data()
On 09/10/13 13:49, Lee Jones wrote:
> Gets rid of those unnecessary gotos.
Unfortunately it introduced a bug whilst it is at it. Sometimes
those gotos are necessary and the 'right' way to do things.
>
> Signed-off-by: Lee Jones
> ---
> drivers/iio/common/st_sensors/st_sensors_core.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c
> b/drivers/iio/common/st_sensors/st_sensors_core.c
> index 8c4c54c..148f0e5 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
> @@ -331,26 +331,23 @@ static int st_sensors_read_axis_data(struct iio_dev
> *indio_dev,
> unsigned int byte_for_channel = ch->scan_type.storagebits >> 3;
>
> outdata = kmalloc(byte_for_channel, GFP_KERNEL);
> - if (!outdata) {
> - err = -EINVAL;
> - goto st_sensors_read_axis_data_error;
> - }
> + if (!outdata)
> + return -ENOMEM;
I agree this change makes complete sense.
>
> err = sdata->tf->read_multiple_byte(&sdata->tb, sdata->dev,
> ch->address, byte_for_channel,
> outdata, sdata->multiread_bit);
> - if (err < 0)
> - goto st_sensors_free_memory;
> + if (err < 0) {
> + kfree(outdata);
> + return err;
> + }
I don't like this change as
>
> if (byte_for_channel == 2)
> *data = (s16)get_unaligned_le16(outdata);
> else if (byte_for_channel == 3)
> *data = (s32)st_sensors_get_unaligned_le24(outdata);
>
> -st_sensors_free_memory:
> - kfree(outdata);
you now don't free out data in the case of no error. This is precisely the case
where a goto is the correct way to handle things as the free need to occur
whether
or not the error occurs.
> -st_sensors_read_axis_data_error:
> - return err;
> + return 0;
> }
>
> int st_sensors_read_info_raw(struct iio_dev *indio_dev,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 22/38] iio: sensors-core: st: Clean-up error handling in st_sensors_read_info_raw()
On 09/10/13 13:49, Lee Jones wrote:
> Saving a few lines of code.
>
> Signed-off-by: Lee Jones
Applied to the togreg branch of iio.git.
To my mind the key thing here is that the error paths were previous
inconsistent in that all but the last one went via a separate cleanup path
whereas the last one went straight through.
Now they are consistent and that is more important than saving a few lines of
code.
Thanks,
> ---
> drivers/iio/common/st_sensors/st_sensors_core.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c
> b/drivers/iio/common/st_sensors/st_sensors_core.c
> index 148f0e5..25d4c7e 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
> @@ -359,28 +359,25 @@ int st_sensors_read_info_raw(struct iio_dev *indio_dev,
> mutex_lock(&indio_dev->mlock);
> if (indio_dev->currentmode == INDIO_BUFFER_TRIGGERED) {
> err = -EBUSY;
> - goto read_error;
> + goto out;
> } else {
> err = st_sensors_set_enable(indio_dev, true);
> if (err < 0)
> - goto read_error;
> + goto out;
>
> msleep((sdata->sensor->bootime * 1000) / sdata->odr);
> err = st_sensors_read_axis_data(indio_dev, ch, val);
> if (err < 0)
> - goto read_error;
> + goto out;
>
> *val = *val >> ch->scan_type.shift;
>
> err = st_sensors_set_enable(indio_dev, false);
> }
> +out:
> mutex_unlock(&indio_dev->mlock);
>
> return err;
> -
> -read_error:
> - mutex_unlock(&indio_dev->mlock);
> - return err;
> }
> EXPORT_SYMBOL(st_sensors_read_info_raw);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 18/38] iio: sensors-core: st: Allow full-scale to be an optional feature
On 09/14/13 17:45, Jonathan Cameron wrote:
> On 09/10/13 13:49, Lee Jones wrote:
>> Some chips either don't support it or fail to provide adequate documentation,
>> so sometimes it's impossible to enable the feature even if it is supported.
>>
>> Signed-off-by: Lee Jones
> Applied to the togreg branch of iio.git
>
Note that Denis Acked this in v1 and it hasn't changed substantially that I can
see.
Hence you should have added that ack to this reposting. I nearly missed it.
> Thanks
>> ---
>> drivers/iio/common/st_sensors/st_sensors_core.c | 11 +++
>> drivers/iio/pressure/st_pressure_core.c | 6 --
>> 2 files changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c
>> b/drivers/iio/common/st_sensors/st_sensors_core.c
>> index 965ee22..eb261a5 100644
>> --- a/drivers/iio/common/st_sensors/st_sensors_core.c
>> +++ b/drivers/iio/common/st_sensors/st_sensors_core.c
>> @@ -235,10 +235,13 @@ int st_sensors_init_sensor(struct iio_dev *indio_dev,
>> if (err < 0)
>> goto init_error;
>>
>> -err = st_sensors_set_fullscale(indio_dev,
>> -sdata->current_fullscale->num);
>> -if (err < 0)
>> -goto init_error;
>> +if (sdata->current_fullscale) {
>> +err = st_sensors_set_fullscale(indio_dev,
>> + sdata->current_fullscale->num);
>> +if (err < 0)
>> +goto init_error;
>> +} else
>> +dev_info(&indio_dev->dev, "Full-scale not possible\n");
>>
>> err = st_sensors_set_odr(indio_dev, sdata->odr);
>> if (err < 0)
>> diff --git a/drivers/iio/pressure/st_pressure_core.c
>> b/drivers/iio/pressure/st_pressure_core.c
>> index ceebd3c..16cfbc5 100644
>> --- a/drivers/iio/pressure/st_pressure_core.c
>> +++ b/drivers/iio/pressure/st_pressure_core.c
>> @@ -226,8 +226,10 @@ int st_press_common_probe(struct iio_dev *indio_dev,
>> indio_dev->channels = pdata->sensor->ch;
>> indio_dev->num_channels = ARRAY_SIZE(st_press_channels);
>>
>> -pdata->current_fullscale = (struct st_sensor_fullscale_avl *)
>> -&pdata->sensor->fs.fs_avl[0];
>> +if (pdata->sensor->fs.addr != 0)
>> +pdata->current_fullscale = (struct st_sensor_fullscale_avl *)
>> +&pdata->sensor->fs.fs_avl[0];
>> +
>> pdata->odr = pdata->sensor->odr.odr_avl[0].hz;
>>
>> if (!plat_data)
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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 23/38] iio: pressure-core: st: Describe LPS331AP defines by name
On 09/10/13 13:49, Lee Jones wrote:
> They're currently named *_1_*, for 'Sensor 1', but the code will be much
> more readable if we use the naming convention *_LPS331AP_* instead.
>
> Signed-off-by: Lee Jones
Very happy to see this patch. The _1_ stuff should never have gotten through
the initial review of the driver (oops). Even in cases where it might be shared
by multiple devices, it is better to have it named after one choice.
Anyhow, applied to the togreg branch of iio.git
Thanks
> ---
> drivers/iio/pressure/st_pressure_core.c | 94
> -
> 1 file changed, 46 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/iio/pressure/st_pressure_core.c
> b/drivers/iio/pressure/st_pressure_core.c
> index 279aafd..2ee4bcd 100644
> --- a/drivers/iio/pressure/st_pressure_core.c
> +++ b/drivers/iio/pressure/st_pressure_core.c
> @@ -36,94 +36,92 @@
>ST_PRESS_LSB_PER_CELSIUS)
> #define ST_PRESS_NUMBER_DATA_CHANNELS1
>
> -/* DEFAULT VALUE FOR SENSORS */
> -#define ST_PRESS_DEFAULT_OUT_XL_ADDR 0x28
> -#define ST_TEMP_DEFAULT_OUT_L_ADDR 0x2b
> -
> /* FULLSCALE */
> #define ST_PRESS_FS_AVL_1260MB 1260
>
> -/* CUSTOM VALUES FOR SENSOR 1 */
> -#define ST_PRESS_1_WAI_EXP 0xbb
> -#define ST_PRESS_1_ODR_ADDR 0x20
> -#define ST_PRESS_1_ODR_MASK 0x70
> -#define ST_PRESS_1_ODR_AVL_1HZ_VAL 0x01
> -#define ST_PRESS_1_ODR_AVL_7HZ_VAL 0x05
> -#define ST_PRESS_1_ODR_AVL_13HZ_VAL 0x06
> -#define ST_PRESS_1_ODR_AVL_25HZ_VAL 0x07
> -#define ST_PRESS_1_PW_ADDR 0x20
> -#define ST_PRESS_1_PW_MASK 0x80
> -#define ST_PRESS_1_FS_ADDR 0x23
> -#define ST_PRESS_1_FS_MASK 0x30
> -#define ST_PRESS_1_FS_AVL_1260_VAL 0x00
> -#define ST_PRESS_1_FS_AVL_1260_GAIN ST_PRESS_KPASCAL_NANO_SCALE
> -#define ST_PRESS_1_FS_AVL_TEMP_GAIN ST_PRESS_CELSIUS_NANO_SCALE
> -#define ST_PRESS_1_BDU_ADDR 0x20
> -#define ST_PRESS_1_BDU_MASK 0x04
> -#define ST_PRESS_1_DRDY_IRQ_ADDR 0x22
> -#define ST_PRESS_1_DRDY_IRQ_INT1_MASK0x04
> -#define ST_PRESS_1_DRDY_IRQ_INT2_MASK0x20
> -#define ST_PRESS_1_MULTIREAD_BIT true
> -#define ST_PRESS_1_TEMP_OFFSET 42500
> +/* CUSTOM VALUES FOR LPS331AP SENSOR */
> +#define ST_PRESS_LPS331AP_WAI_EXP0xbb
> +#define ST_PRESS_LPS331AP_ODR_ADDR 0x20
> +#define ST_PRESS_LPS331AP_ODR_MASK 0x70
> +#define ST_PRESS_LPS331AP_ODR_AVL_1HZ_VAL0x01
> +#define ST_PRESS_LPS331AP_ODR_AVL_7HZ_VAL0x05
> +#define ST_PRESS_LPS331AP_ODR_AVL_13HZ_VAL 0x06
> +#define ST_PRESS_LPS331AP_ODR_AVL_25HZ_VAL 0x07
> +#define ST_PRESS_LPS331AP_PW_ADDR0x20
> +#define ST_PRESS_LPS331AP_PW_MASK0x80
> +#define ST_PRESS_LPS331AP_FS_ADDR0x23
> +#define ST_PRESS_LPS331AP_FS_MASK0x30
> +#define ST_PRESS_LPS331AP_FS_AVL_1260_VAL0x00
> +#define ST_PRESS_LPS331AP_FS_AVL_1260_GAIN ST_PRESS_KPASCAL_NANO_SCALE
> +#define ST_PRESS_LPS331AP_FS_AVL_TEMP_GAIN ST_PRESS_CELSIUS_NANO_SCALE
> +#define ST_PRESS_LPS331AP_BDU_ADDR 0x20
> +#define ST_PRESS_LPS331AP_BDU_MASK 0x04
> +#define ST_PRESS_LPS331AP_DRDY_IRQ_ADDR 0x22
> +#define ST_PRESS_LPS331AP_DRDY_IRQ_INT1_MASK 0x04
> +#define ST_PRESS_LPS331AP_DRDY_IRQ_INT2_MASK 0x20
> +#define ST_PRESS_LPS331AP_MULTIREAD_BIT true
> +#define ST_PRESS_LPS331AP_TEMP_OFFSET42500
> +#define ST_PRESS_LPS331AP_OUT_XL_ADDR0x28
> +#define ST_TEMP_LPS331AP_OUT_L_ADDR 0x2b
>
> static const struct iio_chan_spec st_press_channels[] = {
> ST_SENSORS_LSM_CHANNELS(IIO_PRESSURE,
> BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
> ST_SENSORS_SCAN_X, 0, IIO_NO_MOD, 'u', IIO_LE, 24, 24,
> - ST_PRESS_DEFAULT_OUT_XL_ADDR),
> + ST_PRESS_LPS331AP_OUT_XL_ADDR),
> ST_SENSORS_LSM_CHANNELS(IIO_TEMP,
> BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE) |
> BIT(IIO_CHAN_INFO_OFFSET),
> -1, 0, IIO_NO_MOD, 's', IIO_LE, 16, 16,
> - ST_TEMP_DEFAULT_OUT_L_ADDR),
> + ST_TEMP_LPS331AP_OUT_L_ADDR),
> IIO_CHAN_SOFT_TIMESTAMP(1)
> };
>
> static const struct st_sensors st_press_sensors[] = {
> {
> - .wai = ST_PRESS_1_WAI_EXP,
> + .wai = ST_PRESS_LPS331AP_WAI_EXP,
> .sensors_supported = {
> [0] = LPS331AP_PRESS_DEV_NAME,
> },
> .ch = (struct iio_chan_spec *)st_press_channels,
> .odr = {
> - .addr
Re: [PATCH] kthread: Make kthread_create() killable.
Add lkml.
On 09/13, Tetsuo Handa wrote:
>
> This patch makes kthread_create() killable,
Probably makes sense...
> @@ -255,36 +266,59 @@ struct task_struct *kthread_create_on_node(int
> (*threadfn)(void *data),
> const char namefmt[],
> ...)
> {
> - struct kthread_create_info create;
> -
> - create.threadfn = threadfn;
> - create.data = data;
> - create.node = node;
> - init_completion(&create.done);
> + struct task_struct *task;
> + struct kthread_create_info *create = kmalloc(sizeof(*create),
> + GFP_KERNEL);
> +
> + if (!create)
> + return ERR_PTR(-ENOMEM);
> + create->threadfn = threadfn;
> + create->data = data;
> + create->node = node;
> + create->owner = (void *) 1;
> + init_completion(&create->done);
>
> spin_lock(&kthread_create_lock);
> - list_add_tail(&create.list, &kthread_create_list);
> + list_add_tail(&create->list, &kthread_create_list);
> spin_unlock(&kthread_create_lock);
>
> wake_up_process(kthreadd_task);
> - wait_for_completion(&create.done);
> -
> - if (!IS_ERR(create.result)) {
> + /*
> + * Wait for completion in killable state, for I might be chosen by
> + * the OOM killer while kthreadd is trying to allocate memory for
> + * new kernel thread.
> + */
> + if (unlikely(wait_for_completion_killable(&create->done))) {
> + /*
> + * If I was SIGKILLed before kthreadd (or new kernel thread)
> + * calls complete(), leave the cleanup of this structure to
> + * that thread.
> + */
> + if (xchg(&create->owner, NULL))
> + return ERR_PTR(-ENOMEM);
I am wondering if this can be simplified...
At least you can move create->done from kthread_create_info to the
stack, and turn create->owner into the pointer to that completion.
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 24/38] iio: pressure-core: st: Expand and rename LPS331AP's channel descriptor
On 09/10/13 13:49, Lee Jones wrote:
> Due to the MACRO used, the task of reading, understanding and maintaining
> the LPS331AP's channel descriptor is substantially difficult. This patch
> is based on the view that it's better to have easy to read, maintainable
> code than to save a few lines here and there. For that reason we're
> expanding the array so initialisation is completed in full.
>
> Signed-off-by: Lee Jones
Agreed that in this case it is clearer not to use a macro. When you have lots
of repeats (e.g. an adc with 16 channels) they can make sense, but here as
you say a few extra lines of code make it much easier to follow.
My only slight addition here would be to drop the IIO_NO_MOD and modified=0 bits
on the basis those are both the obvious defaults (and happen to be equal to 0).
Perhaps worth leaving them in this case as it makes the patch more obviously
correct.
Applied to the togreg branch of iio.git
Thanks,
Jonathan
> ---
> drivers/iio/pressure/st_pressure_core.c | 45
> +
> 1 file changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/iio/pressure/st_pressure_core.c
> b/drivers/iio/pressure/st_pressure_core.c
> index 2ee4bcd..60c2ee4 100644
> --- a/drivers/iio/pressure/st_pressure_core.c
> +++ b/drivers/iio/pressure/st_pressure_core.c
> @@ -64,16 +64,39 @@
> #define ST_PRESS_LPS331AP_OUT_XL_ADDR0x28
> #define ST_TEMP_LPS331AP_OUT_L_ADDR 0x2b
>
> -static const struct iio_chan_spec st_press_channels[] = {
> - ST_SENSORS_LSM_CHANNELS(IIO_PRESSURE,
> +static const struct iio_chan_spec st_press_lps331ap_channels[] = {
> + {
> + .type = IIO_PRESSURE,
> + .channel2 = IIO_NO_MOD,
> + .address = ST_PRESS_LPS331AP_OUT_XL_ADDR,
> + .scan_index = ST_SENSORS_SCAN_X,
> + .scan_type = {
> + .sign = 'u',
> + .realbits = 24,
> + .storagebits = 24,
> + .endianness = IIO_LE,
> + },
> + .info_mask_separate =
> BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
> - ST_SENSORS_SCAN_X, 0, IIO_NO_MOD, 'u', IIO_LE, 24, 24,
> - ST_PRESS_LPS331AP_OUT_XL_ADDR),
> - ST_SENSORS_LSM_CHANNELS(IIO_TEMP,
> - BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE) |
> - BIT(IIO_CHAN_INFO_OFFSET),
> - -1, 0, IIO_NO_MOD, 's', IIO_LE, 16, 16,
> - ST_TEMP_LPS331AP_OUT_L_ADDR),
> + .modified = 0,
> + },
> + {
> + .type = IIO_TEMP,
> + .channel2 = IIO_NO_MOD,
> + .address = ST_TEMP_LPS331AP_OUT_L_ADDR,
> + .scan_index = -1,
> + .scan_type = {
> + .sign = 'u',
> + .realbits = 16,
> + .storagebits = 16,
> + .endianness = IIO_LE,
> + },
> + .info_mask_separate =
> + BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> + .modified = 0,
> + },
> IIO_CHAN_SOFT_TIMESTAMP(1)
> };
>
> @@ -83,7 +106,7 @@ static const struct st_sensors st_press_sensors[] = {
> .sensors_supported = {
> [0] = LPS331AP_PRESS_DEV_NAME,
> },
> - .ch = (struct iio_chan_spec *)st_press_channels,
> + .ch = (struct iio_chan_spec *)st_press_lps331ap_channels,
> .odr = {
> .addr = ST_PRESS_LPS331AP_ODR_ADDR,
> .mask = ST_PRESS_LPS331AP_ODR_MASK,
> @@ -222,7 +245,7 @@ int st_press_common_probe(struct iio_dev *indio_dev,
> pdata->num_data_channels = ST_PRESS_NUMBER_DATA_CHANNELS;
> pdata->multiread_bit = pdata->sensor->multi_read_bit;
> indio_dev->channels = pdata->sensor->ch;
> - indio_dev->num_channels = ARRAY_SIZE(st_press_channels);
> + indio_dev->num_channels = ARRAY_SIZE(st_press_lps331ap_channels);
>
> if (pdata->sensor->fs.addr != 0)
> pdata->current_fullscale = (struct st_sensor_fullscale_avl *)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf session: Add option to copy events when queueing
On Fri, Sep 06, 2013 at 01:37:01PM -0600, David Ahern wrote:
> When processing events the session code has an ordered samples queue which is
> used to time-sort events coming in across multiple mmaps. At a later point in
> time samples on the queue are flushed up to some timestamp at which point the
> event is actually processed.
>
> When analyzing events live (ie., record/analysis path in the same command)
> there is a race that leads to corrupted events and parse errors which cause
> perf to terminate. The problem is that when the event is placed in the ordered
> samples queue it is only a reference to the event which is really sitting in
> the mmap buffer. Even though the event is queued for later processing the mmap
> tail pointer is updated which indicates to the kernel that the event has been
> processed. The race is flushing the event from the queue before it gets
> overwritten by some other event. For commands trying to process events live
> (versus just writing to a file) and processing a high rate of events this
> leads
> to parse failures and perf terminates.
>
> Examples hitting this problem are 'perf kvm stat live', especially with nested
> VMs which generate 100,000+ traces per second, and a command processing
> scheduling events with a high rate of context switching -- e.g., running
> 'perf bench sched pipe'.
>
> This patch offers live commands an option to copy the event when it is placed
> in
> the ordered samples queue.
>
> Signed-off-by: David Ahern
> Cc: Frederic Weisbecker
> Cc: Ingo Molnar
> Cc: Jiri Olsa
> Cc: Mike Galbraith
> Cc: Namhyung Kim
> Cc: Peter Zijlstra
> Cc: Stephane Eranian
> ---
> tools/perf/util/session.c | 17 ++---
> tools/perf/util/session.h |1 +
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index 1b185ca..71f16db 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -483,6 +483,8 @@ static void perf_session_free_sample_buffers(struct
> perf_session *session)
>
> sq = list_entry(os->to_free.next, struct sample_queue, list);
> list_del(&sq->list);
> + if (session->copy_on_queue)
> + free(sq->event);
> free(sq);
> }
> }
> @@ -513,11 +515,15 @@ static int flush_sample_queue(struct perf_session *s,
> break;
>
> ret = perf_evlist__parse_sample(s->evlist, iter->event,
> &sample);
> - if (ret)
> + if (ret) {
> pr_err("Can't parse sample, err = %d\n", ret);
> - else {
> + if (s->copy_on_queue)
> + free(iter->event);
> + } else {
> ret = perf_session_deliver_event(s, iter->event,
> &sample, tool,
>iter->file_offset);
> + if (s->copy_on_queue)
> + free(iter->event);
> if (ret)
> return ret;
> }
> @@ -676,7 +682,12 @@ int perf_session_queue_event(struct perf_session *s,
> union perf_event *event,
>
> new->timestamp = timestamp;
> new->file_offset = file_offset;
> - new->event = event;
> +
> + if (s->copy_on_queue) {
> + new->event = malloc(event->header.size);
> + memcpy(new->event, event, event->header.size);
> + } else
> + new->event = event;
>
> __queue_event(new, s);
>
> diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
> index 3aa75fb..4adfcbb 100644
> --- a/tools/perf/util/session.h
> +++ b/tools/perf/util/session.h
> @@ -38,6 +38,7 @@ struct perf_session {
> boolfd_pipe;
> boolrepipe;
> struct ordered_samples ordered_samples;
> + boolcopy_on_queue;
So do you think it should stay optional? This looks like a global problem, I
mean
the event can be unmapped anytime for any builtin tool mapping it, right?
Also we already allocate the sample list node (struct sample_queue) from
os->sample
buffer. ie: we have our own allocator there.
Probably we should reuse that and include the copied event space in "struct
sample_queue"?
Also looking at it now, it seems we have a bug on the existing code:
if (!list_empty(sc)) {
new = list_entry(sc->next, struct sample_queue, list);
list_del(&new->list);
} else if (os->sample_buffer) {
new = os->sample_buffer + os->sample_buffer_idx;
if (++os->sample_buffer_idx == MAX_SAMPLE_BUFFER)
os->sample_buffer = NULL;
} else {
os->sample_buffer = malloc(MAX_SAMPLE_BUFFER * sizeof(*new));
if (!os->sample_buffer)
return -ENOMEM;
list_
Re: [PATCH 25/38] iio: pressure-core: st: Allow for number of channels to vary
On 09/10/13 13:49, Lee Jones wrote:
> At the moment the number of channels specified is dictated by the first
> sensor supported by the driver. As we add support for more sensors this
> is likely to vary. Instead of using the ARRAY_SIZE() of the LPS331AP's
> channel specifier we'll use a new adaptable 'struct st_sensors' element
> instead.
>
> Signed-off-by: Lee Jones
Applied with Denis ack (again it should have been here)
> ---
> drivers/iio/pressure/st_pressure_core.c | 3 ++-
> include/linux/iio/common/st_sensors.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/pressure/st_pressure_core.c
> b/drivers/iio/pressure/st_pressure_core.c
> index 60c2ee4..3abada2 100644
> --- a/drivers/iio/pressure/st_pressure_core.c
> +++ b/drivers/iio/pressure/st_pressure_core.c
> @@ -107,6 +107,7 @@ static const struct st_sensors st_press_sensors[] = {
> [0] = LPS331AP_PRESS_DEV_NAME,
> },
> .ch = (struct iio_chan_spec *)st_press_lps331ap_channels,
> + .num_ch = ARRAY_SIZE(st_press_lps331ap_channels),
> .odr = {
> .addr = ST_PRESS_LPS331AP_ODR_ADDR,
> .mask = ST_PRESS_LPS331AP_ODR_MASK,
> @@ -245,7 +246,7 @@ int st_press_common_probe(struct iio_dev *indio_dev,
> pdata->num_data_channels = ST_PRESS_NUMBER_DATA_CHANNELS;
> pdata->multiread_bit = pdata->sensor->multi_read_bit;
> indio_dev->channels = pdata->sensor->ch;
> - indio_dev->num_channels = ARRAY_SIZE(st_press_lps331ap_channels);
> + indio_dev->num_channels = pdata->sensor->num_ch;
>
> if (pdata->sensor->fs.addr != 0)
> pdata->current_fullscale = (struct st_sensor_fullscale_avl *)
> diff --git a/include/linux/iio/common/st_sensors.h
> b/include/linux/iio/common/st_sensors.h
> index e51f654..e732fda 100644
> --- a/include/linux/iio/common/st_sensors.h
> +++ b/include/linux/iio/common/st_sensors.h
> @@ -184,6 +184,7 @@ struct st_sensors {
> u8 wai;
> char sensors_supported[ST_SENSORS_MAX_4WAI][ST_SENSORS_MAX_NAME];
> struct iio_chan_spec *ch;
> + int num_ch;
> struct st_sensor_odr odr;
> struct st_sensor_power pw;
> struct st_sensor_axis enable_axis;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 26/38] iio: pressure-core: st: Clean-up probe() function
On 09/11/13 08:19, Lee Jones wrote:
>>> err = st_sensors_init_sensor(indio_dev, plat_data);
>>> if (err < 0)
>>> - goto st_press_common_probe_error;
>>> + return err;
>>>
>>> - if (pdata->get_irq_data_ready(indio_dev) > 0) {
>>> + if (irq > 0) {
>>> err = st_press_allocate_ring(indio_dev);
>>> if (err < 0)
>>> - goto st_press_common_probe_error;
>>> + return err;
>>>
>>> err = st_sensors_allocate_trigger(indio_dev,
>>> - ST_PRESS_TRIGGER_OPS);
>>> + ST_PRESS_TRIGGER_OPS);
>>> if (err < 0)
>>> goto st_press_probe_trigger_error;
>>> }
>>>
>>> err = iio_device_register(indio_dev);
>>> - if (err)
>>
>> This bit of handling is confusing. I would much rather see the if IRQ at the
>> goto. Here the first thought is why is it not an error if there is no IRQ!
>
> I certainly see your point. But surely anyone would see after a second
> or two that we're returning err and not 0 in this case, so the error
> would still be returned, we're not ignoring it. Adding this extra
> comparison saves several lines of code.
>
> If you think it's 'too' confusing, I'll revert the change.
>
> Or perhaps a comment:
>
> /* Only deallocate_[trigger|ring] if they were allocated. */
> or
> /* Only deallocate_[trigger|ring] if we have an IRQ line. */
> or
> /* If no IRQ was specified, just return the error. */
>
Revert the change. Whilst not complex to follow it is non obvious to save only
a couple of lines. Adding a comment would take almost as much space as just
doing
it the 'easy way'.
>>> + if (err && irq > 0)
>>> goto st_press_device_register_error;
>>>
>>> return err;
>>>
>>> st_press_device_register_error:
>>> - if (pdata->get_irq_data_ready(indio_dev) > 0)
>>> - st_sensors_deallocate_trigger(indio_dev);
>>> + st_sensors_deallocate_trigger(indio_dev);
>>> st_press_probe_trigger_error:
>>> - if (pdata->get_irq_data_ready(indio_dev) > 0)
>>> - st_press_deallocate_ring(indio_dev);
>>> -st_press_common_probe_error:
>>> + st_press_deallocate_ring(indio_dev);
>>> +
>>> return err;
>>> }
>>> EXPORT_SYMBOL(st_press_common_probe);
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 28/38] iio: pressure: st: Add support for new LPS001WP pressure sensor
On 09/10/13 13:49, Lee Jones wrote:
> Here we use existing practices to introduce support for another
> pressure/temperature sensor, the LPS001WP.
>
> Signed-off-by: Lee Jones
Looks fine to me, will pick this up when the precursors are all sorted.
> ---
> drivers/iio/pressure/st_pressure.h | 1 +
> drivers/iio/pressure/st_pressure_core.c | 84
> +
> drivers/iio/pressure/st_pressure_i2c.c | 1 +
> 3 files changed, 86 insertions(+)
>
> diff --git a/drivers/iio/pressure/st_pressure.h
> b/drivers/iio/pressure/st_pressure.h
> index f1bebce..36b1cc6 100644
> --- a/drivers/iio/pressure/st_pressure.h
> +++ b/drivers/iio/pressure/st_pressure.h
> @@ -15,6 +15,7 @@
> #include
>
> #define LPS331AP_PRESS_DEV_NAME "lps331ap_press"
> +#define LPS001WP_PRESS_DEV_NAME "lps001wp_press"
>
> /**
> * struct st_sensors_platform_data - default press platform data
> diff --git a/drivers/iio/pressure/st_pressure_core.c
> b/drivers/iio/pressure/st_pressure_core.c
> index 34b3fb1..b42614a 100644
> --- a/drivers/iio/pressure/st_pressure_core.c
> +++ b/drivers/iio/pressure/st_pressure_core.c
> @@ -64,6 +64,21 @@
> #define ST_PRESS_LPS331AP_OUT_XL_ADDR0x28
> #define ST_TEMP_LPS331AP_OUT_L_ADDR 0x2b
>
> +/* CUSTOM VALUES FOR LPS001WP SENSOR */
> +#define ST_PRESS_LPS001WP_WAI_EXP0xba
> +#define ST_PRESS_LPS001WP_ODR_ADDR 0x20
> +#define ST_PRESS_LPS001WP_ODR_MASK 0x30
> +#define ST_PRESS_LPS001WP_ODR_AVL_1HZ_VAL0x01
> +#define ST_PRESS_LPS001WP_ODR_AVL_7HZ_VAL0x02
> +#define ST_PRESS_LPS001WP_ODR_AVL_13HZ_VAL 0x03
> +#define ST_PRESS_LPS001WP_PW_ADDR0x20
> +#define ST_PRESS_LPS001WP_PW_MASK0x40
> +#define ST_PRESS_LPS001WP_BDU_ADDR 0x20
> +#define ST_PRESS_LPS001WP_BDU_MASK 0x04
> +#define ST_PRESS_LPS001WP_MULTIREAD_BIT true
> +#define ST_PRESS_LPS001WP_OUT_L_ADDR 0x28
> +#define ST_TEMP_LPS001WP_OUT_L_ADDR 0x2a
> +
> static const struct iio_chan_spec st_press_lps331ap_channels[] = {
> {
> .type = IIO_PRESSURE,
> @@ -100,6 +115,40 @@ static const struct iio_chan_spec
> st_press_lps331ap_channels[] = {
> IIO_CHAN_SOFT_TIMESTAMP(1)
> };
>
> +static const struct iio_chan_spec st_press_lps001wp_channels[] = {
> + {
> + .type = IIO_PRESSURE,
> + .channel2 = IIO_NO_MOD,
> + .address = ST_PRESS_LPS001WP_OUT_L_ADDR,
> + .scan_index = ST_SENSORS_SCAN_X,
> + .scan_type = {
> + .sign = 'u',
> + .realbits = 16,
> + .storagebits = 16,
> + .endianness = IIO_LE,
> + },
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .modified = 0,
> + },
> + {
> + .type = IIO_TEMP,
> + .channel2 = IIO_NO_MOD,
> + .address = ST_TEMP_LPS001WP_OUT_L_ADDR,
> + .scan_index = -1,
> + .scan_type = {
> + .sign = 'u',
> + .realbits = 16,
> + .storagebits = 16,
> + .endianness = IIO_LE,
> + },
> + .info_mask_separate =
> + BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> + .modified = 0,
> + },
> + IIO_CHAN_SOFT_TIMESTAMP(1)
> +};
> +
> static const struct st_sensors st_press_sensors[] = {
> {
> .wai = ST_PRESS_LPS331AP_WAI_EXP,
> @@ -148,6 +197,41 @@ static const struct st_sensors st_press_sensors[] = {
> .multi_read_bit = ST_PRESS_LPS331AP_MULTIREAD_BIT,
> .bootime = 2,
> },
> + {
> + .wai = ST_PRESS_LPS001WP_WAI_EXP,
> + .sensors_supported = {
> + [0] = LPS001WP_PRESS_DEV_NAME,
> + },
> + .ch = (struct iio_chan_spec *)st_press_lps001wp_channels,
> + .num_ch = ARRAY_SIZE(st_press_lps001wp_channels),
> + .odr = {
> + .addr = ST_PRESS_LPS001WP_ODR_ADDR,
> + .mask = ST_PRESS_LPS001WP_ODR_MASK,
> + .odr_avl = {
> + { 1, ST_PRESS_LPS001WP_ODR_AVL_1HZ_VAL, },
> + { 7, ST_PRESS_LPS001WP_ODR_AVL_7HZ_VAL, },
> + { 13, ST_PRESS_LPS001WP_ODR_AVL_13HZ_VAL, },
> + },
> + },
> + .pw = {
> + .addr = ST_PRESS_LPS001WP_PW_ADDR,
> + .mask = ST_PRESS_LPS001WP_PW_MASK,
> + .value_on = ST_SENSORS_DEFAULT_POWER_ON_VALUE,
> + .value_off = ST_SENSORS_DEFAULT_POWER_OFF_VALUE,
> + },
> + .fs = {
> + .addr = 0,
> + },
> + .bdu = {
> +
Re: [PATCH 29/38] iio: pressure-core: st: Provide support for the Vdd power supply
On 09/10/13 13:49, Lee Jones wrote:
> The power to some of the sensors are controlled by regulators. In most
> cases these are 'always on', but if not they will fail to work until
> the regulator is enabled using the relevant APIs. This patch allows for
> the Vdd power supply to be specified by either platform data or Device
> Tree.
>
> Signed-off-by: Lee Jones
Fine, will pick up with the rest. This optional regulator stuff is nice as
it gets around the annoying platform specific callbacks that tend to do stuff
like this.
If anyone is bored, I suspect there are quite a few cases where this makes sense
in other IIO drivers!
> ---
> drivers/iio/pressure/st_pressure_core.c | 28
> include/linux/iio/common/st_sensors.h | 3 +++
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/iio/pressure/st_pressure_core.c
> b/drivers/iio/pressure/st_pressure_core.c
> index b42614a..d52b487 100644
> --- a/drivers/iio/pressure/st_pressure_core.c
> +++ b/drivers/iio/pressure/st_pressure_core.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -313,6 +314,29 @@ static const struct iio_trigger_ops st_press_trigger_ops
> = {
> #define ST_PRESS_TRIGGER_OPS NULL
> #endif
>
> +void st_press_power_enable(struct iio_dev *indio_dev)
> +{
> + struct st_sensor_data *pdata = iio_priv(indio_dev);
> + int err;
> +
> + /* Regulators not mandatory, but if requested we should enable it. */
> + pdata->vdd = devm_regulator_get_optional(&indio_dev->dev, "vdd");
> + if (!IS_ERR(pdata->vdd)) {
> + err = regulator_enable(pdata->vdd);
> + if (err != 0)
> + dev_warn(&indio_dev->dev,
> + "Failed to enable specified Vdd supply\n");
> + }
> +}
> +
> +void st_press_power_disable(struct iio_dev *indio_dev)
> +{
> + struct st_sensor_data *pdata = iio_priv(indio_dev);
> +
> + if (!IS_ERR(pdata->vdd))
> + regulator_disable(pdata->vdd);
> +}
> +
> int st_press_common_probe(struct iio_dev *indio_dev,
> struct st_sensors_platform_data *plat_data)
> {
> @@ -323,6 +347,8 @@ int st_press_common_probe(struct iio_dev *indio_dev,
> indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->info = &press_info;
>
> + st_press_power_enable(indio_dev);
> +
> err = st_sensors_check_device_support(indio_dev,
> ARRAY_SIZE(st_press_sensors),
> st_press_sensors);
> @@ -382,6 +408,8 @@ void st_press_common_remove(struct iio_dev *indio_dev)
> {
> struct st_sensor_data *pdata = iio_priv(indio_dev);
>
> + st_press_power_disable(indio_dev);
> +
> iio_device_unregister(indio_dev);
> if (pdata->get_irq_data_ready(indio_dev) > 0) {
> st_sensors_deallocate_trigger(indio_dev);
> diff --git a/include/linux/iio/common/st_sensors.h
> b/include/linux/iio/common/st_sensors.h
> index e732fda..968b84e 100644
> --- a/include/linux/iio/common/st_sensors.h
> +++ b/include/linux/iio/common/st_sensors.h
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -201,6 +202,7 @@ struct st_sensors {
> * @trig: The trigger in use by the core driver.
> * @sensor: Pointer to the current sensor struct in use.
> * @current_fullscale: Maximum range of measure by the sensor.
> + * @vdd: Pointer to sensor's Vdd power supply
> * @enabled: Status of the sensor (false->off, true->on).
> * @multiread_bit: Use or not particular bit for [I2C/SPI] multiread.
> * @buffer_data: Data used by buffer part.
> @@ -216,6 +218,7 @@ struct st_sensor_data {
> struct iio_trigger *trig;
> struct st_sensors *sensor;
> struct st_sensor_fullscale_avl *current_fullscale;
> + struct regulator *vdd;
>
> bool enabled;
> bool multiread_bit;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 31/38] iio: accel-core: st: Clean up error handling in probe()
On 09/10/13 13:49, Lee Jones wrote:
> Reduce the amount of those unnecessary goto calls, as in most cases
> we can simply return immediately. We also only call for the IRQ number
> once and use that value throughout.
>
> Signed-off-by: Lee Jones
...
> - if (adata->get_irq_data_ready(indio_dev) > 0) {
> + if (irq > 0) {
> err = st_accel_allocate_ring(indio_dev);
> if (err < 0)
> - goto st_accel_common_probe_error;
> + return err;
>
> err = st_sensors_allocate_trigger(indio_dev,
>ST_ACCEL_TRIGGER_OPS);
> @@ -492,18 +493,16 @@ int st_accel_common_probe(struct iio_dev *indio_dev,
> }
>
> err = iio_device_register(indio_dev);
> - if (err)
> + if (err && irq > 0)
> goto st_accel_device_register_error;
This is the same structure I moaned about earlier. Again, put the if (irq > 0)
in the error handling
not here.
>
> return err;
>
> st_accel_device_register_error:
> - if (adata->get_irq_data_ready(indio_dev) > 0)
> - st_sensors_deallocate_trigger(indio_dev);
> + st_sensors_deallocate_trigger(indio_dev);
> st_accel_probe_trigger_error:
> - if (adata->get_irq_data_ready(indio_dev) > 0)
> - st_accel_deallocate_ring(indio_dev);
> -st_accel_common_probe_error:
> + st_accel_deallocate_ring(indio_dev);
> +
> return err;
> }
> EXPORT_SYMBOL(st_accel_common_probe);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 alt 4/4] pinctrl: at91: rework debounce configuration
On 09:53 Fri 13 Sep , Boris BREZILLON wrote:
> AT91 SoCs do not support per pin debounce time configuration.
> Instead you have to configure a debounce time which will be used for all
> pins of a given bank (PIOA, PIOB, ...).
>
> Signed-off-by: Boris BREZILLON
> ---
> .../bindings/pinctrl/atmel,at91-pinctrl.txt|9 ++-
> drivers/pinctrl/pinctrl-at91.c | 79
>
> include/dt-bindings/pinctrl/at91.h |1 -
> 3 files changed, 73 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> index cf7c7bc..8a4cdeb 100644
> --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> @@ -78,6 +78,14 @@ PA31 TXD4
>
> => 0xffc00c3b
>
> +Optional properties for iomux controller:
> +- atmel,default-debounce-div: array of debounce divisors (one divisor per
> bank)
> + which describes the debounce timing in use for all pins of a given bank
> + configured with the DEBOUNCE option (see the following description).
> + Debounce timing is obtained with this formula:
> + Tdebounce = 2 * (debouncediv + 1) / Fslowclk
> + with Fslowclk = 32KHz
I known that I put the div in the original binding
but maybe we should just put the debounce timing in the DT and calculate the
div in C
> +
> Required properties for pin configuration node:
> - atmel,pins: 4 integers array, represents a group of pins mux and config
>setting. The format is atmel,pins = .
> @@ -91,7 +99,6 @@ DEGLITCH(1 << 2): indicate this pin need deglitch.
> PULL_DOWN(1 << 3): indicate this pin need a pull down.
> DIS_SCHMIT (1 << 4): indicate this pin need to disable schmit trigger.
> DEBOUNCE (1 << 16): indicate this pin need debounce.
> -DEBOUNCE_VAL (0x3fff << 17): debounce val.
>
> NOTE:
> Some requirements for using atmel,at91rm9200-pinctrl binding:
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index ac9dbea..2903758 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -62,8 +62,6 @@ static int gpio_banks;
> #define PULL_DOWN(1 << 3)
> #define DIS_SCHMIT (1 << 4)
> #define DEBOUNCE (1 << 16)
> -#define DEBOUNCE_VAL_SHIFT 17
> -#define DEBOUNCE_VAL (0x3fff << DEBOUNCE_VAL_SHIFT)
>
> /**
> * struct at91_pmx_func - describes AT91 pinmux functions
> @@ -145,8 +143,10 @@ struct at91_pinctrl_mux_ops {
> void (*mux_D_periph)(void __iomem *pio, unsigned mask);
> bool (*get_deglitch)(void __iomem *pio, unsigned pin);
> void (*set_deglitch)(void __iomem *pio, unsigned mask, bool is_on);
> - bool (*get_debounce)(void __iomem *pio, unsigned pin, u32 *div);
> - void (*set_debounce)(void __iomem *pio, unsigned mask, bool is_on, u32
> div);
> + bool (*get_debounce)(void __iomem *pio, unsigned pin);
> + void (*set_debounce)(void __iomem *pio, unsigned mask, bool is_on);
> + u32 (*get_debounce_div)(void __iomem *pio);
> + void (*set_debounce_div)(void __iomem *pio, u32 div);
why do you split it?
if it's just get if on or not put NULL to div but do not add more function
pointer
> bool (*get_pulldown)(void __iomem *pio, unsigned pin);
> void (*set_pulldown)(void __iomem *pio, unsigned mask, bool is_on);
> bool (*get_schmitt_trig)(void __iomem *pio, unsigned pin);
> @@ -432,25 +432,32 @@ static void at91_mux_pio3_set_deglitch(void __iomem
> *pio, unsigned mask, bool is
> at91_mux_set_deglitch(pio, mask, is_on);
> }
>
> -static bool at91_mux_pio3_get_debounce(void __iomem *pio, unsigned pin, u32
> *div)
> +static bool at91_mux_pio3_get_debounce(void __iomem *pio, unsigned pin)
> {
> - *div = __raw_readl(pio + PIO_SCDR);
> -
> return ((__raw_readl(pio + PIO_IFSR) >> pin) & 0x1) &&
> ((__raw_readl(pio + PIO_IFSCSR) >> pin) & 0x1);
> }
>
> static void at91_mux_pio3_set_debounce(void __iomem *pio, unsigned mask,
> - bool is_on, u32 div)
> + bool is_on)
> {
> if (is_on) {
> __raw_writel(mask, pio + PIO_IFSCER);
> - __raw_writel(div & PIO_SCDR_DIV, pio + PIO_SCDR);
> __raw_writel(mask, pio + PIO_IFER);
> } else
> __raw_writel(mask, pio + PIO_IFSCDR);
> }
>
> +static u32 at91_mux_pio3_get_debounce_div(void __iomem *pio)
> +{
> + return __raw_readl(pio + PIO_SCDR) & PIO_SCDR_DIV;
> +}
> +
> +static void at91_mux_pio3_set_debounce_div(void __iomem *pio, u32 div)
> +{
> + __raw_writel(div & PIO_SCDR_DIV, pio + PIO_SCDR);
> +}
> +
> static bool at91_mux_pio3_get_pulldown(void __iomem *pio, unsigned pin)
> {
> return !((__raw_readl(pio + PIO_PPDSR) >> pin) & 0x1);
> @@ -490,6 +497,8 @@ static struct at91_pinctrl_mux_ops at91sam9x5_ops = {
>
Re: [PATCH] doc: fix some typos
On 09/13/13 20:49, Xishi Qiu wrote: > diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt > index 0cfb00f..ca278d5 100644 > --- a/Documentation/kprobes.txt > +++ b/Documentation/kprobes.txt > @@ -92,7 +92,7 @@ stack contents as the probed function. When it is done, > the handler > calls jprobe_return(), which traps again to restore the original stack > contents and processor state and switch to the probed function. > > -By convention, the callee owns its arguments, so gcc may produce code Are you sure about that? It looks correct to me (before the patch). > +By convention, the caller owns its arguments, so gcc may produce code > that unexpectedly modifies that portion of the stack. This is why > Kprobes saves a copy of the stack and restores it after the jprobe > handler has run. Up to MAX_STACK_SIZE bytes are copied -- e.g., > -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 32/38] iio: accel-core: st: Move LSM303DLH into correct group
On 09/10/13 13:49, Lee Jones wrote:
> The LSM303DLH's WAI (WhoAmI) is 0x33, meaning it should be enabled by
> Accel Sensor group one. For the device to probe without error, we'll
> need to ensure it's registered with the correct WAI.
>
> Signed-off-by: Lee Jones
You clearly have a better datasheet than I have as for that part it doesn't
even claim to
have the relevant register to read a who am I from.
Now that datasheet does list odr values as 50, 100, 400 1000 which would put it
where it originally
was in these tables.
http://www.st.com/web/en/resource/technical/document/datasheet/CD00260288.pdf
I haven't checked other elements...
I'm confused but suspect we may need another type entry to deal with this one.
> ---
> drivers/iio/accel/st_accel_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/accel/st_accel_core.c
> b/drivers/iio/accel/st_accel_core.c
> index ea62291..03a2b6b 100644
> --- a/drivers/iio/accel/st_accel_core.c
> +++ b/drivers/iio/accel/st_accel_core.c
> @@ -170,6 +170,7 @@ static const struct st_sensors st_accel_sensors[] = {
> [2] = LSM330D_ACCEL_DEV_NAME,
> [3] = LSM330DL_ACCEL_DEV_NAME,
> [4] = LSM330DLC_ACCEL_DEV_NAME,
> + [5] = LSM303DLH_ACCEL_DEV_NAME,
> },
> .ch = (struct iio_chan_spec *)st_accel_12bit_channels,
> .odr = {
> @@ -238,8 +239,7 @@ static const struct st_sensors st_accel_sensors[] = {
> .sensors_supported = {
> [0] = LIS331DLH_ACCEL_DEV_NAME,
> [1] = LSM303DL_ACCEL_DEV_NAME,
> - [2] = LSM303DLH_ACCEL_DEV_NAME,
> - [3] = LSM303DLM_ACCEL_DEV_NAME,
> + [2] = LSM303DLM_ACCEL_DEV_NAME,
> },
> .ch = (struct iio_chan_spec *)st_accel_12bit_channels,
> .odr = {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 38/38] iio: magn-core: st: Provide support for the LSM303DLH
On 09/10/13 13:49, Lee Jones wrote:
> Trivial patch adding the LSM303DLH to the list of already supported
> Magnetometer Sensors.
>
> Signed-off-by: Lee Jones
err.
> index 12e7e79..b2e2917 100644
> --- a/drivers/iio/magnetometer/st_magn_core.c
> +++ b/drivers/iio/magnetometer/st_magn_core.c
> @@ -151,7 +151,8 @@ static const struct st_sensors st_magn_sensors[] = {
> .wai = ST_MAGN_1_WAI_EXP,
> .sensors_supported = {
> [0] = LSM303DLHC_MAGN_DEV_NAME,
> - [1] = LSM303DLM_MAGN_DEV_NAME,
> + [1] = LSM303DLH_MAGN_DEV_NAME,
> + [0] = LSM303DLM_MAGN_DEV_NAME,
[2]?
> },
> .ch = (struct iio_chan_spec *)st_magn_16bit_channels,
> .odr = {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] pinctrl: at91: fix typos
On 09:45 Fri 13 Sep , Boris BREZILLON wrote:
> Fix AT91_PINCTRL_DEBOUNCE_VAL dt macro typo.
> Fix at91_pinctrl_mux_ops callback typos.
>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD
> Signed-off-by: Boris BREZILLON
> ---
> drivers/pinctrl/pinctrl-at91.c |6 +++---
> include/dt-bindings/pinctrl/at91.h |2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index 19afb9a..50b555a 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -144,11 +144,11 @@ struct at91_pinctrl_mux_ops {
> void (*mux_C_periph)(void __iomem *pio, unsigned mask);
> void (*mux_D_periph)(void __iomem *pio, unsigned mask);
> bool (*get_deglitch)(void __iomem *pio, unsigned pin);
> - void (*set_deglitch)(void __iomem *pio, unsigned mask, bool in_on);
> + void (*set_deglitch)(void __iomem *pio, unsigned mask, bool is_on);
> bool (*get_debounce)(void __iomem *pio, unsigned pin, u32 *div);
> - void (*set_debounce)(void __iomem *pio, unsigned mask, bool in_on, u32
> div);
> + void (*set_debounce)(void __iomem *pio, unsigned mask, bool is_on, u32
> div);
> bool (*get_pulldown)(void __iomem *pio, unsigned pin);
> - void (*set_pulldown)(void __iomem *pio, unsigned mask, bool in_on);
> + void (*set_pulldown)(void __iomem *pio, unsigned mask, bool is_on);
> bool (*get_schmitt_trig)(void __iomem *pio, unsigned pin);
> void (*disable_schmitt_trig)(void __iomem *pio, unsigned mask);
> /* irq */
> diff --git a/include/dt-bindings/pinctrl/at91.h
> b/include/dt-bindings/pinctrl/at91.h
> index d7988b4..0fee6ff 100644
> --- a/include/dt-bindings/pinctrl/at91.h
> +++ b/include/dt-bindings/pinctrl/at91.h
> @@ -16,7 +16,7 @@
> #define AT91_PINCTRL_PULL_DOWN (1 << 3)
> #define AT91_PINCTRL_DIS_SCHMIT (1 << 4)
> #define AT91_PINCTRL_DEBOUNCE(1 << 16)
> -#define AT91_PINCTRL_DEBOUNCE_VA(x) (x << 17)
> +#define AT91_PINCTRL_DEBOUNCE_VAL(x) (x << 17)
>
> #define AT91_PINCTRL_PULL_UP_DEGLITCH(AT91_PINCTRL_PULL_UP |
> AT91_PINCTRL_DEGLITCH)
>
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v5 0/9] liblockdep: userspace lockdep
On 09/12/2013 02:01 PM, Ingo Molnar wrote: On 07/08/2013 04:39 AM, Ingo Molnar wrote: PeterZ is in favor as well so I'll apply them after the merge window, for v3.12. Hi Ingo, Do you intend to send liblockdep in this merge window as planned? If Peter agrees with them and picks them up then the next merge window would be fine I guess. I thought that Peter acked it, and the plan was to push it through the locking tree for 3.12? Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: access efi variables
On 09/14/13 00:37, H. Peter Anvin wrote: On 09/13/2013 08:37 AM, Arend van Spriel wrote: I need to obtain a uefi variable so I went looking at the API in include/linux/efi.h. I found the following definition: But according to the specs the variable I need to obtain is 2k bytes. Should I expect trouble :-p efivarfs doesn't have those limitations. Thanks, Peter Looking into efivarfs it seems to use the functions that I looked at in efi.h so I guess I am misinterpreting the 1024 bytes limitation in the comment (either that or you are mistaken ;-) ). I need to access the variable from within a device driver so using efivarfs does not feel like the way to go here. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 alt 4/4] pinctrl: at91: rework debounce configuration
On 16:40 Fri 13 Sep , Stephen Warren wrote: > On 09/13/2013 01:53 AM, Boris BREZILLON wrote: > > AT91 SoCs do not support per pin debounce time configuration. > > Instead you have to configure a debounce time which will be used for all > > pins of a given bank (PIOA, PIOB, ...). > > > diff --git > > a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt > > b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt > > > +Optional properties for iomux controller: > > +- atmel,default-debounce-div: array of debounce divisors (one divisor per > > bank) > > + which describes the debounce timing in use for all pins of a given bank > > + configured with the DEBOUNCE option (see the following description). > > + Debounce timing is obtained with this formula: > > + Tdebounce = 2 * (debouncediv + 1) / Fslowclk > > + with Fslowclk = 32KHz > > + > > Required properties for pin configuration node: > > - atmel,pins: 4 integers array, represents a group of pins mux and config > >setting. The format is atmel,pins = > CONFIG>. > > @@ -91,7 +99,6 @@ DEGLITCH (1 << 2): indicate this pin need deglitch. > > PULL_DOWN (1 << 3): indicate this pin need a pull down. > > DIS_SCHMIT (1 << 4): indicate this pin need to disable schmit trigger. > > DEBOUNCE (1 << 16): indicate this pin need debounce. > > -DEBOUNCE_VAL (0x3fff << 17): debounce val. > > This change would break the DT ABI since it removes a feature that's > already present. > > I suppose it's still up to the Atmel maintainers to decide whether this > is appropriate, or whether the impact to out-of-tree DT files would be > problematic. I does ask Boris to break the DT ABI as anyway no one use it and the current ABI is wrong and as this is the new SoC the impact of out-of-tree board is limited if ever Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/11] hwmon: (jc42) Convert to use devm_hwmon_device_register_with_groups
Signed-off-by: Guenter Roeck
---
drivers/hwmon/jc42.c | 61 +-
1 file changed, 25 insertions(+), 36 deletions(-)
diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c
index 4a58f13..f362cea 100644
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -163,7 +163,7 @@ static struct jc42_chips jc42_chips[] = {
/* Each client has this additional data */
struct jc42_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
struct mutexupdate_lock;/* protect register access */
boolextended; /* true if extended range supported */
boolvalid;
@@ -193,21 +193,21 @@ MODULE_DEVICE_TABLE(i2c, jc42_id);
static int jc42_suspend(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct jc42_data *data = i2c_get_clientdata(client);
+ struct jc42_data *data = dev_get_drvdata(dev);
data->config |= JC42_CFG_SHUTDOWN;
- i2c_smbus_write_word_swapped(client, JC42_REG_CONFIG, data->config);
+ i2c_smbus_write_word_swapped(data->client, JC42_REG_CONFIG,
+data->config);
return 0;
}
static int jc42_resume(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct jc42_data *data = i2c_get_clientdata(client);
+ struct jc42_data *data = dev_get_drvdata(dev);
data->config &= ~JC42_CFG_SHUTDOWN;
- i2c_smbus_write_word_swapped(client, JC42_REG_CONFIG, data->config);
+ i2c_smbus_write_word_swapped(data->client, JC42_REG_CONFIG,
+data->config);
return 0;
}
@@ -317,15 +317,14 @@ static ssize_t set_##value(struct device *dev,
\
struct device_attribute *attr, \
const char *buf, size_t count) \
{ \
- struct i2c_client *client = to_i2c_client(dev); \
- struct jc42_data *data = i2c_get_clientdata(client);\
+ struct jc42_data *data = dev_get_drvdata(dev); \
int err, ret = count; \
long val; \
- if (kstrtol(buf, 10, &val) < 0) \
+ if (kstrtol(buf, 10, &val) < 0) \
return -EINVAL; \
mutex_lock(&data->update_lock); \
data->value = jc42_temp_to_reg(val, data->extended);\
- err = i2c_smbus_write_word_swapped(client, reg, data->value); \
+ err = i2c_smbus_write_word_swapped(data->client, reg, data->value); \
if (err < 0)\
ret = err; \
mutex_unlock(&data->update_lock); \
@@ -344,8 +343,7 @@ static ssize_t set_temp_crit_hyst(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct jc42_data *data = i2c_get_clientdata(client);
+ struct jc42_data *data = dev_get_drvdata(dev);
unsigned long val;
int diff, hyst;
int err;
@@ -368,7 +366,7 @@ static ssize_t set_temp_crit_hyst(struct device *dev,
mutex_lock(&data->update_lock);
data->config = (data->config & ~JC42_CFG_HYST_MASK)
| (hyst << JC42_CFG_HYST_SHIFT);
- err = i2c_smbus_write_word_swapped(client, JC42_REG_CONFIG,
+ err = i2c_smbus_write_word_swapped(data->client, JC42_REG_CONFIG,
data->config);
if (err < 0)
ret = err;
@@ -430,8 +428,7 @@ static umode_t jc42_attribute_mode(struct kobject *kobj,
struct attribute *attr, int index)
{
struct device *dev = container_of(kobj, struct device, kobj);
- struct i2c_client *client = to_i2c_client(dev);
- struct jc42_data *data = i2c_get_clientdata(client);
+ struct jc42_data *data = dev_get_drvdata(dev);
unsigned int config = data->config;
bool readonly;
@@ -452,6 +449,7 @@ static const struct attribute_group jc42_group = {
.attrs = jc42_attributes,
.is_visible = jc42_attribute_mode,
};
+__ATTRIBUTE_GROUPS(jc42);
/* Return 0 if detection is successful, -ENODEV otherwise */
static int jc42_detect(struct i2c_client *client, struct i2c_board_info *info)
@@ -487,14 +485,16 @@ static int jc42_detect(struct i2c_client *client, struct
i2c_board_info *info)
static int jc42_probe(struct i2c_client *client, const st
[PATCH 09/11] hwmon: (ina209) Convert to use devm_hwmon_device_register_with_groups
Also use new macro ATTRIBUTE_GROUPS to declare attribute groups.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/ina209.c | 46 ++
1 file changed, 18 insertions(+), 28 deletions(-)
diff --git a/drivers/hwmon/ina209.c b/drivers/hwmon/ina209.c
index c6fdd5b..5378fde 100644
--- a/drivers/hwmon/ina209.c
+++ b/drivers/hwmon/ina209.c
@@ -63,7 +63,7 @@
#define INA209_SHUNT_DEFAULT 1 /* uOhm */
struct ina209_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
struct mutex update_lock;
bool valid;
@@ -78,8 +78,8 @@ struct ina209_data {
static struct ina209_data *ina209_update_device(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct ina209_data *data = i2c_get_clientdata(client);
+ struct ina209_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
struct ina209_data *ret = data;
s32 val;
int i;
@@ -234,7 +234,6 @@ static ssize_t ina209_set_interval(struct device *dev,
struct device_attribute *da,
const char *buf, size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
struct ina209_data *data = ina209_update_device(dev);
long val;
u16 regval;
@@ -250,7 +249,8 @@ static ssize_t ina209_set_interval(struct device *dev,
mutex_lock(&data->update_lock);
regval = ina209_reg_from_interval(data->regs[INA209_CONFIGURATION],
val);
- i2c_smbus_write_word_swapped(client, INA209_CONFIGURATION, regval);
+ i2c_smbus_write_word_swapped(data->client, INA209_CONFIGURATION,
+regval);
data->regs[INA209_CONFIGURATION] = regval;
data->update_interval = ina209_interval_from_reg(regval);
mutex_unlock(&data->update_lock);
@@ -260,8 +260,7 @@ static ssize_t ina209_set_interval(struct device *dev,
static ssize_t ina209_show_interval(struct device *dev,
struct device_attribute *da, char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct ina209_data *data = i2c_get_clientdata(client);
+ struct ina209_data *data = dev_get_drvdata(dev);
return snprintf(buf, PAGE_SIZE, "%d\n", data->update_interval);
}
@@ -285,9 +284,9 @@ static ssize_t ina209_reset_history(struct device *dev,
const char *buf,
size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct ina209_data *data = i2c_get_clientdata(client);
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
+ struct ina209_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
u32 mask = attr->index;
long val;
int i, ret;
@@ -312,7 +311,6 @@ static ssize_t ina209_set_value(struct device *dev,
const char *buf,
size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
struct ina209_data *data = ina209_update_device(dev);
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
int reg = attr->index;
@@ -332,7 +330,7 @@ static ssize_t ina209_set_value(struct device *dev,
count = ret;
goto abort;
}
- i2c_smbus_write_word_swapped(client, reg, ret);
+ i2c_smbus_write_word_swapped(data->client, reg, ret);
data->regs[reg] = ret;
abort:
mutex_unlock(&data->update_lock);
@@ -457,7 +455,7 @@ static SENSOR_DEVICE_ATTR(update_interval, S_IRUGO |
S_IWUSR,
* Finally, construct an array of pointers to members of the above objects,
* as required for sysfs_create_group()
*/
-static struct attribute *ina209_attributes[] = {
+static struct attribute *ina209_attrs[] = {
&sensor_dev_attr_in0_input.dev_attr.attr,
&sensor_dev_attr_in0_input_highest.dev_attr.attr,
&sensor_dev_attr_in0_input_lowest.dev_attr.attr,
@@ -498,10 +496,7 @@ static struct attribute *ina209_attributes[] = {
NULL,
};
-
-static const struct attribute_group ina209_group = {
- .attrs = ina209_attributes,
-};
+ATTRIBUTE_GROUPS(ina209);
static void ina209_restore_conf(struct i2c_client *client,
struct ina209_data *data)
@@ -565,6 +560,7 @@ static int ina209_probe(struct i2c_client *client,
{
struct i2c_adapter *adapter = client->adapter;
struct ina209_data *data;
+ struct device *hwmon_dev;
int ret;
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA))
@@ -575,27 +571,23 @@ static int ina209_probe(struct i2c_client *client,
return -ENOMEM;
i2c_set_clientdata(client, data);
+ data->client = client;
mutex_ini
[PATCH 07/11] hwmon: (tmp401) Convert to use devm_hwmon_device_register_with_groups
Signed-off-by: Guenter Roeck
---
drivers/hwmon/tmp401.c | 89 +++-
1 file changed, 28 insertions(+), 61 deletions(-)
diff --git a/drivers/hwmon/tmp401.c b/drivers/hwmon/tmp401.c
index dfe6d95..49bd122 100644
--- a/drivers/hwmon/tmp401.c
+++ b/drivers/hwmon/tmp401.c
@@ -155,7 +155,8 @@ MODULE_DEVICE_TABLE(i2c, tmp401_id);
*/
struct tmp401_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
+ const struct attribute_group *groups[3];
struct mutex update_lock;
char valid; /* zero until following fields are valid */
unsigned long last_updated; /* in jiffies */
@@ -231,8 +232,8 @@ static int tmp401_update_device_reg16(struct i2c_client
*client,
static struct tmp401_data *tmp401_update_device(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct tmp401_data *data = i2c_get_clientdata(client);
+ struct tmp401_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
struct tmp401_data *ret = data;
int i, val;
unsigned long next_update;
@@ -350,8 +351,8 @@ static ssize_t store_temp(struct device *dev, struct
device_attribute *devattr,
{
int nr = to_sensor_dev_attr_2(devattr)->nr;
int index = to_sensor_dev_attr_2(devattr)->index;
- struct i2c_client *client = to_i2c_client(dev);
- struct tmp401_data *data = tmp401_update_device(dev);
+ struct tmp401_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
long val;
u16 reg;
u8 regaddr;
@@ -405,7 +406,7 @@ static ssize_t store_temp_crit_hyst(struct device *dev,
struct device_attribute
val = clamp_val(val, temp - 255000, temp);
reg = ((temp - val) + 500) / 1000;
- i2c_smbus_write_byte_data(to_i2c_client(dev), TMP401_TEMP_CRIT_HYST,
+ i2c_smbus_write_byte_data(data->client, TMP401_TEMP_CRIT_HYST,
reg);
data->temp_crit_hyst = reg;
@@ -423,8 +424,8 @@ static ssize_t store_temp_crit_hyst(struct device *dev,
struct device_attribute
static ssize_t reset_temp_history(struct device *dev,
struct device_attribute *devattr, const char *buf, size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct tmp401_data *data = i2c_get_clientdata(client);
+ struct tmp401_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
long val;
if (kstrtol(buf, 10, &val))
@@ -447,8 +448,7 @@ static ssize_t reset_temp_history(struct device *dev,
static ssize_t show_update_interval(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct tmp401_data *data = i2c_get_clientdata(client);
+ struct tmp401_data *data = dev_get_drvdata(dev);
return sprintf(buf, "%u\n", data->update_interval);
}
@@ -457,8 +457,8 @@ static ssize_t set_update_interval(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct tmp401_data *data = i2c_get_clientdata(client);
+ struct tmp401_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
unsigned long val;
int err, rate;
@@ -616,10 +616,10 @@ static const struct attribute_group tmp432_group = {
* Begin non sysfs callback code (aka Real code)
*/
-static void tmp401_init_client(struct i2c_client *client)
+static void tmp401_init_client(struct tmp401_data *data,
+ struct i2c_client *client)
{
int config, config_orig;
- struct tmp401_data *data = i2c_get_clientdata(client);
/* Set the conversion rate to 2 Hz */
i2c_smbus_write_byte_data(client, TMP401_CONVERSION_RATE_WRITE, 5);
@@ -705,77 +705,45 @@ static int tmp401_detect(struct i2c_client *client,
return 0;
}
-static int tmp401_remove(struct i2c_client *client)
-{
- struct device *dev = &client->dev;
- struct tmp401_data *data = i2c_get_clientdata(client);
-
- if (data->hwmon_dev)
- hwmon_device_unregister(data->hwmon_dev);
-
- sysfs_remove_group(&dev->kobj, &tmp401_group);
-
- if (data->kind == tmp411)
- sysfs_remove_group(&dev->kobj, &tmp411_group);
-
- if (data->kind == tmp432)
- sysfs_remove_group(&dev->kobj, &tmp432_group);
-
- return 0;
-}
-
static int tmp401_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ const char *names[] = { "TMP401", "TMP411", "TMP431", "TMP432" };
struct device *dev = &client->dev;
- int err;
+ struct device *hwmon_dev;
struct tmp401_data *data;
-
[PATCH v3 01/11] hwmon: (ds1621) Convert to use devm_hwmon_device_register_with_groups
Also use new macro __ATTRIBUTE_GROUPS to declare attribute groups.
Signed-off-by: Guenter Roeck
---
v3: Use __ATTRIBUTE_GROUPS
drivers/hwmon/ds1621.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/hwmon/ds1621.c b/drivers/hwmon/ds1621.c
index 595f4ef..5e398c9 100644
--- a/drivers/hwmon/ds1621.c
+++ b/drivers/hwmon/ds1621.c
@@ -354,11 +354,7 @@ static const struct attribute_group ds1621_group = {
.attrs = ds1621_attributes,
.is_visible = ds1621_attribute_visible
};
-
-static const struct attribute_group *ds1621_groups[] = {
- &ds1621_group,
- NULL
-};
+__ATTRIBUTE_GROUPS(ds1621);
static int ds1621_probe(struct i2c_client *client,
const struct i2c_device_id *id)
@@ -379,23 +375,12 @@ static int ds1621_probe(struct i2c_client *client,
/* Initialize the DS1621 chip */
ds1621_init_client(data, client);
- hwmon_dev = hwmon_device_register_with_groups(&client->dev,
- client->name, data,
- ds1621_groups);
+ hwmon_dev = devm_hwmon_device_register_with_groups(&client->dev,
+ client->name, data,
+ ds1621_groups);
if (IS_ERR(hwmon_dev))
return PTR_ERR(hwmon_dev);
- i2c_set_clientdata(client, hwmon_dev);
-
- return 0;
-}
-
-static int ds1621_remove(struct i2c_client *client)
-{
- struct device *hwmon_dev = i2c_get_clientdata(client);
-
- hwmon_device_unregister(hwmon_dev);
-
return 0;
}
@@ -416,7 +401,6 @@ static struct i2c_driver ds1621_driver = {
.name = "ds1621",
},
.probe = ds1621_probe,
- .remove = ds1621_remove,
.id_table = ds1621_id,
};
--
1.7.9.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/11] hwmon: (lm95234) Convert to use devm_hwmon_device_register_with_groups
Also use new macro ATTRIBUTE_GROUPS to declare attribute groups.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/lm95234.c | 137 +--
1 file changed, 50 insertions(+), 87 deletions(-)
diff --git a/drivers/hwmon/lm95234.c b/drivers/hwmon/lm95234.c
index 307c9ea..cf87507 100644
--- a/drivers/hwmon/lm95234.c
+++ b/drivers/hwmon/lm95234.c
@@ -57,7 +57,7 @@ static const unsigned short normal_i2c[] = { 0x18, 0x4d,
0x4e, I2C_CLIENT_END };
/* Client data (each client gets its own) */
struct lm95234_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
struct mutex update_lock;
unsigned long last_updated, interval; /* in jiffies */
bool valid; /* false until following fields are valid */
@@ -114,9 +114,9 @@ static u16 update_intervals[] = { 143, 364, 1000, 2500 };
/* Fill value cache. Must be called with update lock held. */
-static int lm95234_fill_cache(struct i2c_client *client)
+static int lm95234_fill_cache(struct lm95234_data *data,
+ struct i2c_client *client)
{
- struct lm95234_data *data = i2c_get_clientdata(client);
int i, ret;
ret = i2c_smbus_read_byte_data(client, LM95234_REG_CONVRATE);
@@ -157,9 +157,9 @@ static int lm95234_fill_cache(struct i2c_client *client)
return 0;
}
-static int lm95234_update_device(struct i2c_client *client,
-struct lm95234_data *data)
+static int lm95234_update_device(struct lm95234_data *data)
{
+ struct i2c_client *client = data->client;
int ret;
mutex_lock(&data->update_lock);
@@ -169,7 +169,7 @@ static int lm95234_update_device(struct i2c_client *client,
int i;
if (!data->valid) {
- ret = lm95234_fill_cache(client);
+ ret = lm95234_fill_cache(data, client);
if (ret < 0)
goto abort;
}
@@ -209,10 +209,9 @@ abort:
static ssize_t show_temp(struct device *dev, struct device_attribute *attr,
char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct lm95234_data *data = i2c_get_clientdata(client);
+ struct lm95234_data *data = dev_get_drvdata(dev);
int index = to_sensor_dev_attr(attr)->index;
- int ret = lm95234_update_device(client, data);
+ int ret = lm95234_update_device(data);
if (ret)
return ret;
@@ -224,10 +223,9 @@ static ssize_t show_temp(struct device *dev, struct
device_attribute *attr,
static ssize_t show_alarm(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct lm95234_data *data = i2c_get_clientdata(client);
+ struct lm95234_data *data = dev_get_drvdata(dev);
u32 mask = to_sensor_dev_attr(attr)->index;
- int ret = lm95234_update_device(client, data);
+ int ret = lm95234_update_device(data);
if (ret)
return ret;
@@ -238,10 +236,9 @@ static ssize_t show_alarm(struct device *dev,
static ssize_t show_type(struct device *dev, struct device_attribute *attr,
char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct lm95234_data *data = i2c_get_clientdata(client);
+ struct lm95234_data *data = dev_get_drvdata(dev);
u8 mask = to_sensor_dev_attr(attr)->index;
- int ret = lm95234_update_device(client, data);
+ int ret = lm95234_update_device(data);
if (ret)
return ret;
@@ -252,11 +249,10 @@ static ssize_t show_type(struct device *dev, struct
device_attribute *attr,
static ssize_t set_type(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct lm95234_data *data = i2c_get_clientdata(client);
+ struct lm95234_data *data = dev_get_drvdata(dev);
unsigned long val;
u8 mask = to_sensor_dev_attr(attr)->index;
- int ret = lm95234_update_device(client, data);
+ int ret = lm95234_update_device(data);
if (ret)
return ret;
@@ -274,7 +270,7 @@ static ssize_t set_type(struct device *dev, struct
device_attribute *attr,
else
data->sensor_type &= ~mask;
data->valid = false;
- i2c_smbus_write_byte_data(client, LM95234_REG_REM_MODEL,
+ i2c_smbus_write_byte_data(data->client, LM95234_REG_REM_MODEL,
data->sensor_type);
mutex_unlock(&data->update_lock);
@@ -284,10 +280,9 @@ static ssize_t set_type(struct device *dev, struct
device_attribute *attr,
static ssize_t show_tcrit2(struct device *dev, struct device_attribute *attr,
char *buf)
{
- struct
[PATCH 10/11] hwmon: (ltc4261) Convert to use devm_hwmon_device_register_with_groups
Also use new macro ATTRIBUTE_GROUPS to declare attribute groups.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/ltc4261.c | 55 ++-
1 file changed, 16 insertions(+), 39 deletions(-)
diff --git a/drivers/hwmon/ltc4261.c b/drivers/hwmon/ltc4261.c
index 487da58..6c50db9 100644
--- a/drivers/hwmon/ltc4261.c
+++ b/drivers/hwmon/ltc4261.c
@@ -55,7 +55,7 @@
#define FAULT_OC (1<<2)
struct ltc4261_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
struct mutex update_lock;
bool valid;
@@ -67,8 +67,8 @@ struct ltc4261_data {
static struct ltc4261_data *ltc4261_update_device(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct ltc4261_data *data = i2c_get_clientdata(client);
+ struct ltc4261_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
struct ltc4261_data *ret = data;
mutex_lock(&data->update_lock);
@@ -150,7 +150,6 @@ static ssize_t ltc4261_show_bool(struct device *dev,
struct device_attribute *da, char *buf)
{
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
- struct i2c_client *client = to_i2c_client(dev);
struct ltc4261_data *data = ltc4261_update_device(dev);
u8 fault;
@@ -159,7 +158,7 @@ static ssize_t ltc4261_show_bool(struct device *dev,
fault = data->regs[LTC4261_FAULT] & attr->index;
if (fault) /* Clear reported faults in chip register */
- i2c_smbus_write_byte_data(client, LTC4261_FAULT, ~fault);
+ i2c_smbus_write_byte_data(data->client, LTC4261_FAULT, ~fault);
return snprintf(buf, PAGE_SIZE, "%d\n", fault ? 1 : 0);
}
@@ -197,7 +196,7 @@ static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO,
ltc4261_show_value, NULL,
static SENSOR_DEVICE_ATTR(curr1_max_alarm, S_IRUGO, ltc4261_show_bool, NULL,
FAULT_OC);
-static struct attribute *ltc4261_attributes[] = {
+static struct attribute *ltc4261_attrs[] = {
&sensor_dev_attr_in1_input.dev_attr.attr,
&sensor_dev_attr_in1_min_alarm.dev_attr.attr,
&sensor_dev_attr_in1_max_alarm.dev_attr.attr,
@@ -210,60 +209,39 @@ static struct attribute *ltc4261_attributes[] = {
NULL,
};
-
-static const struct attribute_group ltc4261_group = {
- .attrs = ltc4261_attributes,
-};
+ATTRIBUTE_GROUPS(ltc4261);
static int ltc4261_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct i2c_adapter *adapter = client->adapter;
+ struct device *dev = &client->dev;
struct ltc4261_data *data;
- int ret;
+ struct device *hwmon_dev;
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -ENODEV;
if (i2c_smbus_read_byte_data(client, LTC4261_STATUS) < 0) {
- dev_err(&client->dev, "Failed to read status register\n");
+ dev_err(dev, "Failed to read status register\n");
return -ENODEV;
}
- data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
- i2c_set_clientdata(client, data);
+ data->client = client;
mutex_init(&data->update_lock);
/* Clear faults */
i2c_smbus_write_byte_data(client, LTC4261_FAULT, 0x00);
- /* Register sysfs hooks */
- ret = sysfs_create_group(&client->dev.kobj, hwmon_dev = hwmon_device_register(&client->dev);
- if (IS_ERR(data->hwmon_dev)) {
- ret = PTR_ERR(data->hwmon_dev);
- goto out_hwmon_device_register;
- }
-
- return 0;
-
-out_hwmon_device_register:
- sysfs_remove_group(&client->dev.kobj, hwmon_dev);
- sysfs_remove_group(&client->dev.kobj, name,
+ data,
+ ltc4261_groups);
+ if (IS_ERR(hwmon_dev))
+ return PTR_ERR(hwmon_dev);
return 0;
}
@@ -281,7 +259,6 @@ static struct i2c_driver ltc4261_driver = {
.name = "ltc4261",
},
.probe = ltc4261_probe,
- .remove = ltc4261_remove,
.id_table = ltc4261_id,
};
--
1.7.9.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
[PATCH 03/11] hwmon: (lm73) Convert to use devm_hwmon_device_register_with_groups
Also introduce new variable dev pointing to client->dev in the probe
function, and use new macro ATTRIBUTE_GROUPS to declare attribute groups.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/lm73.c | 70 --
1 file changed, 22 insertions(+), 48 deletions(-)
diff --git a/drivers/hwmon/lm73.c b/drivers/hwmon/lm73.c
index 9bde964..9653bb8 100644
--- a/drivers/hwmon/lm73.c
+++ b/drivers/hwmon/lm73.c
@@ -55,7 +55,7 @@ static const unsigned short lm73_convrates[] = {
};
struct lm73_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
struct mutex lock;
u8 ctrl;/* control register value */
};
@@ -66,7 +66,7 @@ static ssize_t set_temp(struct device *dev, struct
device_attribute *da,
const char *buf, size_t count)
{
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
- struct i2c_client *client = to_i2c_client(dev);
+ struct lm73_data *data = dev_get_drvdata(dev);
long temp;
short value;
s32 err;
@@ -77,7 +77,7 @@ static ssize_t set_temp(struct device *dev, struct
device_attribute *da,
/* Write value */
value = clamp_val(temp / 250, LM73_TEMP_MIN, LM73_TEMP_MAX) << 5;
- err = i2c_smbus_write_word_swapped(client, attr->index, value);
+ err = i2c_smbus_write_word_swapped(data->client, attr->index, value);
return (err < 0) ? err : count;
}
@@ -85,10 +85,10 @@ static ssize_t show_temp(struct device *dev, struct
device_attribute *da,
char *buf)
{
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
- struct i2c_client *client = to_i2c_client(dev);
+ struct lm73_data *data = dev_get_drvdata(dev);
int temp;
- s32 err = i2c_smbus_read_word_swapped(client, attr->index);
+ s32 err = i2c_smbus_read_word_swapped(data->client, attr->index);
if (err < 0)
return err;
@@ -101,8 +101,7 @@ static ssize_t show_temp(struct device *dev, struct
device_attribute *da,
static ssize_t set_convrate(struct device *dev, struct device_attribute *da,
const char *buf, size_t count)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct lm73_data *data = i2c_get_clientdata(client);
+ struct lm73_data *data = dev_get_drvdata(dev);
unsigned long convrate;
s32 err;
int res = 0;
@@ -124,7 +123,8 @@ static ssize_t set_convrate(struct device *dev, struct
device_attribute *da,
mutex_lock(&data->lock);
data->ctrl &= LM73_CTRL_TO_MASK;
data->ctrl |= res << LM73_CTRL_RES_SHIFT;
- err = i2c_smbus_write_byte_data(client, LM73_REG_CTRL, data->ctrl);
+ err = i2c_smbus_write_byte_data(data->client, LM73_REG_CTRL,
+ data->ctrl);
mutex_unlock(&data->lock);
if (err < 0)
@@ -136,8 +136,7 @@ static ssize_t set_convrate(struct device *dev, struct
device_attribute *da,
static ssize_t show_convrate(struct device *dev, struct device_attribute *da,
char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct lm73_data *data = i2c_get_clientdata(client);
+ struct lm73_data *data = dev_get_drvdata(dev);
int res;
res = (data->ctrl & LM73_CTRL_RES_MASK) >> LM73_CTRL_RES_SHIFT;
@@ -147,13 +146,12 @@ static ssize_t show_convrate(struct device *dev, struct
device_attribute *da,
static ssize_t show_maxmin_alarm(struct device *dev,
struct device_attribute *da, char *buf)
{
- struct i2c_client *client = to_i2c_client(dev);
struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
- struct lm73_data *data = i2c_get_clientdata(client);
+ struct lm73_data *data = dev_get_drvdata(dev);
s32 ctrl;
mutex_lock(&data->lock);
- ctrl = i2c_smbus_read_byte_data(client, LM73_REG_CTRL);
+ ctrl = i2c_smbus_read_byte_data(data->client, LM73_REG_CTRL);
if (ctrl < 0)
goto abort;
data->ctrl = ctrl;
@@ -183,7 +181,7 @@ static SENSOR_DEVICE_ATTR(temp1_max_alarm, S_IRUGO,
static SENSOR_DEVICE_ATTR(temp1_min_alarm, S_IRUGO,
show_maxmin_alarm, NULL, LM73_CTRL_LO_SHIFT);
-static struct attribute *lm73_attributes[] = {
+static struct attribute *lm73_attrs[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp1_max.dev_attr.attr,
&sensor_dev_attr_temp1_min.dev_attr.attr,
@@ -192,10 +190,7 @@ static struct attribute *lm73_attributes[] = {
&sensor_dev_attr_temp1_min_alarm.dev_attr.attr,
NULL
};
-
-static const struct attribute_group lm73_group = {
- .attrs = lm73_attributes,
-};
+ATTRIBUTE_GROUPS(lm73);
/*---*/
@@ -204,16 +199,16 @@ st
[PATCH 06/11] hwmon: (ina2xx) Convert to use devm_hwmon_device_register_with_groups
Also introduce dev variable in probe function to simplify access
to client->dev, and use new macro ATTRIBUTE_GROUPS to declare
attribute groups.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/ina2xx.c | 64
1 file changed, 21 insertions(+), 43 deletions(-)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 70a39a8..93d26e8 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -78,7 +78,7 @@ struct ina2xx_config {
};
struct ina2xx_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
const struct ina2xx_config *config;
struct mutex update_lock;
@@ -112,8 +112,8 @@ static const struct ina2xx_config ina2xx_config[] = {
static struct ina2xx_data *ina2xx_update_device(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct ina2xx_data *data = i2c_get_clientdata(client);
+ struct ina2xx_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
struct ina2xx_data *ret = data;
mutex_lock(&data->update_lock);
@@ -203,41 +203,39 @@ static SENSOR_DEVICE_ATTR(power1_input, S_IRUGO,
ina2xx_show_value, NULL,
INA2XX_POWER);
/* pointers to created device attributes */
-static struct attribute *ina2xx_attributes[] = {
+static struct attribute *ina2xx_attrs[] = {
&sensor_dev_attr_in0_input.dev_attr.attr,
&sensor_dev_attr_in1_input.dev_attr.attr,
&sensor_dev_attr_curr1_input.dev_attr.attr,
&sensor_dev_attr_power1_input.dev_attr.attr,
NULL,
};
-
-static const struct attribute_group ina2xx_group = {
- .attrs = ina2xx_attributes,
-};
+ATTRIBUTE_GROUPS(ina2xx);
static int ina2xx_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct i2c_adapter *adapter = client->adapter;
- struct ina2xx_data *data;
struct ina2xx_platform_data *pdata;
- int ret;
- u32 val;
+ struct device *dev = &client->dev;
+ struct ina2xx_data *data;
+ struct device *hwmon_dev;
long shunt = 1; /* default shunt value 10mOhms */
+ u32 val;
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA))
return -ENODEV;
- data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
- if (dev_get_platdata(&client->dev)) {
- pdata = dev_get_platdata(&client->dev);
+ if (dev_get_platdata(dev)) {
+ pdata = dev_get_platdata(dev);
shunt = pdata->shunt_uohms;
- } else if (!of_property_read_u32(client->dev.of_node,
- "shunt-resistor", &val)) {
- shunt = val;
+ } else if (!of_property_read_u32(dev->of_node,
+"shunt-resistor", &val)) {
+ shunt = val;
}
if (shunt <= 0)
@@ -255,37 +253,18 @@ static int ina2xx_probe(struct i2c_client *client,
i2c_smbus_write_word_swapped(client, INA2XX_CALIBRATION,
data->config->calibration_factor / shunt);
- i2c_set_clientdata(client, data);
+ data->client = client;
mutex_init(&data->update_lock);
- ret = sysfs_create_group(&client->dev.kobj, &ina2xx_group);
- if (ret)
- return ret;
-
- data->hwmon_dev = hwmon_device_register(&client->dev);
- if (IS_ERR(data->hwmon_dev)) {
- ret = PTR_ERR(data->hwmon_dev);
- goto out_err_hwmon;
- }
+ hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
+ data, ina2xx_groups);
+ if (IS_ERR(hwmon_dev))
+ return PTR_ERR(hwmon_dev);
- dev_info(&client->dev, "power monitor %s (Rshunt = %li uOhm)\n",
+ dev_info(dev, "power monitor %s (Rshunt = %li uOhm)\n",
id->name, shunt);
return 0;
-
-out_err_hwmon:
- sysfs_remove_group(&client->dev.kobj, &ina2xx_group);
- return ret;
-}
-
-static int ina2xx_remove(struct i2c_client *client)
-{
- struct ina2xx_data *data = i2c_get_clientdata(client);
-
- hwmon_device_unregister(data->hwmon_dev);
- sysfs_remove_group(&client->dev.kobj, &ina2xx_group);
-
- return 0;
}
static const struct i2c_device_id ina2xx_id[] = {
@@ -302,7 +281,6 @@ static struct i2c_driver ina2xx_driver = {
.name = "ina2xx",
},
.probe = ina2xx_probe,
- .remove = ina2xx_remove,
.id_table = ina2xx_id,
};
--
1.7.9.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
[PATCH 05/11] hwmon: (max16065) Convert to use devm_hwmon_device_register_with_groups
Modify code to use is_visible to determine if an attribute should be created
or not, then use devm_hwmon_device_register_with_groups to create the hwmon
device and all attributes in one operation.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/max16065.c | 124 +++---
1 file changed, 52 insertions(+), 72 deletions(-)
diff --git a/drivers/hwmon/max16065.c b/drivers/hwmon/max16065.c
index 2fa2c02..d4efc79 100644
--- a/drivers/hwmon/max16065.c
+++ b/drivers/hwmon/max16065.c
@@ -83,7 +83,8 @@ static const bool max16065_have_current[] = {
struct max16065_data {
enum chips type;
- struct device *hwmon_dev;
+ struct i2c_client *client;
+ const struct attribute_group *groups[4];
struct mutex update_lock;
bool valid;
unsigned long last_updated; /* in jiffies */
@@ -144,8 +145,8 @@ static int max16065_read_adc(struct i2c_client *client, int
reg)
static struct max16065_data *max16065_update_device(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct max16065_data *data = i2c_get_clientdata(client);
+ struct max16065_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
mutex_lock(&data->update_lock);
if (time_after(jiffies, data->last_updated + HZ) || !data->valid) {
@@ -186,7 +187,7 @@ static ssize_t max16065_show_alarm(struct device *dev,
val &= (1 << attr2->index);
if (val)
- i2c_smbus_write_byte_data(to_i2c_client(dev),
+ i2c_smbus_write_byte_data(data->client,
MAX16065_FAULT(attr2->nr), val);
return snprintf(buf, PAGE_SIZE, "%d\n", !!val);
@@ -223,8 +224,7 @@ static ssize_t max16065_set_limit(struct device *dev,
const char *buf, size_t count)
{
struct sensor_device_attribute_2 *attr2 = to_sensor_dev_attr_2(da);
- struct i2c_client *client = to_i2c_client(dev);
- struct max16065_data *data = i2c_get_clientdata(client);
+ struct max16065_data *data = dev_get_drvdata(dev);
unsigned long val;
int err;
int limit;
@@ -238,7 +238,7 @@ static ssize_t max16065_set_limit(struct device *dev,
mutex_lock(&data->update_lock);
data->limit[attr2->nr][attr2->index]
= LIMIT_TO_MV(limit, data->range[attr2->index]);
- i2c_smbus_write_byte_data(client,
+ i2c_smbus_write_byte_data(data->client,
MAX16065_LIMIT(attr2->nr, attr2->index),
limit);
mutex_unlock(&data->update_lock);
@@ -250,8 +250,7 @@ static ssize_t max16065_show_limit(struct device *dev,
struct device_attribute *da, char *buf)
{
struct sensor_device_attribute_2 *attr2 = to_sensor_dev_attr_2(da);
- struct i2c_client *client = to_i2c_client(dev);
- struct max16065_data *data = i2c_get_clientdata(client);
+ struct max16065_data *data = dev_get_drvdata(dev);
return snprintf(buf, PAGE_SIZE, "%d\n",
data->limit[attr2->nr][attr2->index]);
@@ -516,8 +515,32 @@ static struct attribute *max16065_max_attributes[] = {
NULL
};
+static umode_t max16065_basic_is_visible(struct kobject *kobj,
+struct attribute *a, int n)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct max16065_data *data = dev_get_drvdata(dev);
+ int index = n / 4;
+
+ if (index >= data->num_adc || !data->range[index])
+ return 0;
+ return a->mode;
+}
+
+static umode_t max16065_secondary_is_visible(struct kobject *kobj,
+struct attribute *a, int index)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct max16065_data *data = dev_get_drvdata(dev);
+
+ if (index >= data->num_adc)
+ return 0;
+ return a->mode;
+}
+
static const struct attribute_group max16065_basic_group = {
.attrs = max16065_basic_attributes,
+ .is_visible = max16065_basic_is_visible,
};
static const struct attribute_group max16065_current_group = {
@@ -526,38 +549,35 @@ static const struct attribute_group
max16065_current_group = {
static const struct attribute_group max16065_min_group = {
.attrs = max16065_min_attributes,
+ .is_visible = max16065_secondary_is_visible,
};
static const struct attribute_group max16065_max_group = {
.attrs = max16065_max_attributes,
+ .is_visible = max16065_secondary_is_visible,
};
-static void max16065_cleanup(struct i2c_client *client)
-{
- sysfs_remove_group(&client->dev.kobj, &max16065_max_group);
- sysfs_remove_group(&client->dev.kobj, &max16065_min_group);
- sysfs_remove_group(&client->dev.kobj, &max16065_current_group);
- sysfs_remov
[PATCH 04/11] hwmon: (max6697) Convert to use devm_hwmon_device_register_with_groups
Signed-off-by: Guenter Roeck
---
drivers/hwmon/max6697.c | 54 +++
1 file changed, 17 insertions(+), 37 deletions(-)
diff --git a/drivers/hwmon/max6697.c b/drivers/hwmon/max6697.c
index a41b5f3..0af910a 100644
--- a/drivers/hwmon/max6697.c
+++ b/drivers/hwmon/max6697.c
@@ -77,7 +77,7 @@ struct max6697_chip_data {
};
struct max6697_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
enum chips type;
const struct max6697_chip_data *chip;
@@ -181,8 +181,8 @@ static const struct max6697_chip_data max6697_chip_data[] =
{
static struct max6697_data *max6697_update_device(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct max6697_data *data = i2c_get_clientdata(client);
+ struct max6697_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
struct max6697_data *ret = data;
int val;
int i;
@@ -303,8 +303,7 @@ static ssize_t set_temp(struct device *dev,
{
int nr = to_sensor_dev_attr_2(devattr)->nr;
int index = to_sensor_dev_attr_2(devattr)->index;
- struct i2c_client *client = to_i2c_client(dev);
- struct max6697_data *data = i2c_get_clientdata(client);
+ struct max6697_data *data = dev_get_drvdata(dev);
long temp;
int ret;
@@ -316,7 +315,7 @@ static ssize_t set_temp(struct device *dev,
temp = DIV_ROUND_CLOSEST(temp, 1000) + data->temp_offset;
temp = clamp_val(temp, 0, data->type == max6581 ? 255 : 127);
data->temp[nr][index] = temp;
- ret = i2c_smbus_write_byte_data(client,
+ ret = i2c_smbus_write_byte_data(data->client,
index == 2 ? MAX6697_REG_MAX[nr]
: MAX6697_REG_CRIT[nr],
temp);
@@ -405,8 +404,7 @@ static umode_t max6697_is_visible(struct kobject *kobj,
struct attribute *attr,
int index)
{
struct device *dev = container_of(kobj, struct device, kobj);
- struct i2c_client *client = to_i2c_client(dev);
- struct max6697_data *data = i2c_get_clientdata(client);
+ struct max6697_data *data = dev_get_drvdata(dev);
const struct max6697_chip_data *chip = data->chip;
int channel = index / 6;/* channel number */
int nr = index % 6; /* attribute index within channel */
@@ -489,6 +487,7 @@ static struct attribute *max6697_attributes[] = {
static const struct attribute_group max6697_group = {
.attrs = max6697_attributes, .is_visible = max6697_is_visible,
};
+__ATTRIBUTE_GROUPS(max6697);
static void max6697_get_config_of(struct device_node *node,
struct max6697_platform_data *pdata)
@@ -525,9 +524,9 @@ static void max6697_get_config_of(struct device_node *node,
}
}
-static int max6697_init_chip(struct i2c_client *client)
+static int max6697_init_chip(struct max6697_data *data,
+struct i2c_client *client)
{
- struct max6697_data *data = i2c_get_clientdata(client);
struct max6697_platform_data *pdata = dev_get_platdata(&client->dev);
struct max6697_platform_data p;
const struct max6697_chip_data *chip = data->chip;
@@ -625,6 +624,7 @@ static int max6697_probe(struct i2c_client *client,
struct i2c_adapter *adapter = client->adapter;
struct device *dev = &client->dev;
struct max6697_data *data;
+ struct device *hwmon_dev;
int err;
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
@@ -636,37 +636,18 @@ static int max6697_probe(struct i2c_client *client,
data->type = id->driver_data;
data->chip = &max6697_chip_data[data->type];
-
- i2c_set_clientdata(client, data);
+ data->client = client;
mutex_init(&data->update_lock);
- err = max6697_init_chip(client);
+ err = max6697_init_chip(data, client);
if (err)
return err;
- err = sysfs_create_group(&client->dev.kobj, &max6697_group);
- if (err)
- return err;
-
- data->hwmon_dev = hwmon_device_register(dev);
- if (IS_ERR(data->hwmon_dev)) {
- err = PTR_ERR(data->hwmon_dev);
- goto error;
- }
-
- return 0;
-
-error:
- sysfs_remove_group(&client->dev.kobj, &max6697_group);
- return err;
-}
-
-static int max6697_remove(struct i2c_client *client)
-{
- struct max6697_data *data = i2c_get_clientdata(client);
-
- hwmon_device_unregister(data->hwmon_dev);
- sysfs_remove_group(&client->dev.kobj, &max6697_group);
+ hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
+ data,
+ max6697_
[PATCH 00/11] Convert more drivers to use devm_hwmon_device_register_with_groups
The jc42 driver is compile tested only. All other patches were tested with real hardware. The patches apply on top of the previously submitted patches introducing hwmon_device_register_with_groups and devm_hwmon_device_register_with_groups. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/11] hwmon: (max6642) Convert to use devm_hwmon_device_register_with_groups
Also rename new_client variable to client and introduce
new variable dev pointing to client->dev in the probe function,
and use new macro ATTRIBUTE_GROUPS to declare attribute groups.
Signed-off-by: Guenter Roeck
---
drivers/hwmon/max6642.c | 72 ---
1 file changed, 24 insertions(+), 48 deletions(-)
diff --git a/drivers/hwmon/max6642.c b/drivers/hwmon/max6642.c
index 57d58cd..3d61f8d 100644
--- a/drivers/hwmon/max6642.c
+++ b/drivers/hwmon/max6642.c
@@ -87,7 +87,7 @@ static int temp_to_reg(int val)
*/
struct max6642_data {
- struct device *hwmon_dev;
+ struct i2c_client *client;
struct mutex update_lock;
bool valid; /* zero until following fields are valid */
unsigned long last_updated; /* in jiffies */
@@ -102,10 +102,10 @@ struct max6642_data {
* Real code
*/
-static void max6642_init_client(struct i2c_client *client)
+static void max6642_init_client(struct max6642_data *data,
+ struct i2c_client *client)
{
u8 config;
- struct max6642_data *data = i2c_get_clientdata(client);
/*
* Start the conversions.
@@ -168,14 +168,14 @@ static int max6642_detect(struct i2c_client *client,
static struct max6642_data *max6642_update_device(struct device *dev)
{
- struct i2c_client *client = to_i2c_client(dev);
- struct max6642_data *data = i2c_get_clientdata(client);
+ struct max6642_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
u16 val, tmp;
mutex_lock(&data->update_lock);
if (time_after(jiffies, data->last_updated + HZ) || !data->valid) {
- dev_dbg(&client->dev, "Updating max6642 data.\n");
+ dev_dbg(dev, "Updating max6642 data.\n");
val = i2c_smbus_read_byte_data(client,
MAX6642_REG_R_LOCAL_TEMPL);
tmp = (val >> 6) & 3;
@@ -209,8 +209,8 @@ static struct max6642_data *max6642_update_device(struct
device *dev)
static ssize_t show_temp_max10(struct device *dev,
struct device_attribute *dev_attr, char *buf)
{
- struct max6642_data *data = max6642_update_device(dev);
struct sensor_device_attribute *attr = to_sensor_dev_attr(dev_attr);
+ struct max6642_data *data = max6642_update_device(dev);
return sprintf(buf, "%d\n",
temp_from_reg10(data->temp_input[attr->index]));
@@ -219,8 +219,8 @@ static ssize_t show_temp_max10(struct device *dev,
static ssize_t show_temp_max(struct device *dev, struct device_attribute *attr,
char *buf)
{
- struct max6642_data *data = max6642_update_device(dev);
struct sensor_device_attribute_2 *attr2 = to_sensor_dev_attr_2(attr);
+ struct max6642_data *data = max6642_update_device(dev);
return sprintf(buf, "%d\n", temp_from_reg(data->temp_high[attr2->nr]));
}
@@ -228,11 +228,10 @@ static ssize_t show_temp_max(struct device *dev, struct
device_attribute *attr,
static ssize_t set_temp_max(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
+ struct sensor_device_attribute_2 *attr2 = to_sensor_dev_attr_2(attr);
+ struct max6642_data *data = dev_get_drvdata(dev);
unsigned long val;
int err;
- struct i2c_client *client = to_i2c_client(dev);
- struct max6642_data *data = i2c_get_clientdata(client);
- struct sensor_device_attribute_2 *attr2 = to_sensor_dev_attr_2(attr);
err = kstrtoul(buf, 10, &val);
if (err < 0)
@@ -240,7 +239,7 @@ static ssize_t set_temp_max(struct device *dev, struct
device_attribute *attr,
mutex_lock(&data->update_lock);
data->temp_high[attr2->nr] = clamp_val(temp_to_reg(val), 0, 255);
- i2c_smbus_write_byte_data(client, attr2->index,
+ i2c_smbus_write_byte_data(data->client, attr2->index,
data->temp_high[attr2->nr]);
mutex_unlock(&data->update_lock);
return count;
@@ -264,7 +263,7 @@ static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_alarm,
NULL, 2);
static SENSOR_DEVICE_ATTR(temp1_max_alarm, S_IRUGO, show_alarm, NULL, 6);
static SENSOR_DEVICE_ATTR(temp2_max_alarm, S_IRUGO, show_alarm, NULL, 4);
-static struct attribute *max6642_attributes[] = {
+static struct attribute *max6642_attrs[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp2_input.dev_attr.attr,
&sensor_dev_attr_temp1_max.dev_attr.attr,
@@ -275,52 +274,30 @@ static struct attribute *max6642_attributes[] = {
&sensor_dev_attr_temp2_max_alarm.dev_attr.attr,
NULL
};
+ATTRIBUTE_GROUPS(max6642);
-static const struct attribute_group max6642_group = {
- .attrs = max6642_attributes,
-};
-
-static int max6642_probe(struct i2c_client *new_client,
+static int max66
Re: [RFC PATCH 2/4] pinctrl: at91: fix sam9x5 debounce/deglitch functions
On 09:47 Fri 13 Sep , Boris BREZILLON wrote:
> Replace at91_mux_get_deglitch with at91_mux_pio3_get_deglitch when using
> sam9x5 (pio3) IP.
> at91_mux_get_deglitch only test the activation of the "Input Filter" which
> may be overloaded by the activation of the "Input Filter Slow Clock" to use
> the input filter as a debounce filter instead of a deglitch filter.
>
> Fix at91_mux_pio3_get_debounce to test the activation of the Input Filter
> before testing the activation of the debounce filter (Input Filter Slow
> Clock depends on Input Filter).
>
> Fix at91_mux_pio3_set_debounce function to avoid disabling the deglitch
> filter ("Input Filter") when debounce filter is disabled.
>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD
> Signed-off-by: Boris BREZILLON
> ---
> drivers/pinctrl/pinctrl-at91.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index 50b555a..6624bce 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -417,6 +417,14 @@ static void at91_mux_set_deglitch(void __iomem *pio,
> unsigned mask, bool is_on)
> __raw_writel(mask, pio + (is_on ? PIO_IFER : PIO_IFDR));
> }
>
> +static bool at91_mux_pio3_get_deglitch(void __iomem *pio, unsigned pin)
> +{
> + if ((__raw_readl(pio + PIO_IFSR) >> pin) & 0x1)
> + return !((__raw_readl(pio + PIO_IFSCSR) >> pin) & 0x1);
> +
> + return false;
> +}
> +
> static void at91_mux_pio3_set_deglitch(void __iomem *pio, unsigned mask,
> bool is_on)
> {
> if (is_on)
> @@ -428,7 +436,8 @@ static bool at91_mux_pio3_get_debounce(void __iomem *pio,
> unsigned pin, u32 *div
> {
> *div = __raw_readl(pio + PIO_SCDR);
>
> - return (__raw_readl(pio + PIO_IFSCSR) >> pin) & 0x1;
> + return ((__raw_readl(pio + PIO_IFSR) >> pin) & 0x1) &&
> +((__raw_readl(pio + PIO_IFSCSR) >> pin) & 0x1);
> }
>
> static void at91_mux_pio3_set_debounce(void __iomem *pio, unsigned mask,
> @@ -438,9 +447,8 @@ static void at91_mux_pio3_set_debounce(void __iomem *pio,
> unsigned mask,
> __raw_writel(mask, pio + PIO_IFSCER);
> __raw_writel(div & PIO_SCDR_DIV, pio + PIO_SCDR);
> __raw_writel(mask, pio + PIO_IFER);
> - } else {
> - __raw_writel(mask, pio + PIO_IFDR);
> - }
> + } else
> + __raw_writel(mask, pio + PIO_IFSCDR);
> }
>
> static bool at91_mux_pio3_get_pulldown(void __iomem *pio, unsigned pin)
> @@ -478,7 +486,7 @@ static struct at91_pinctrl_mux_ops at91sam9x5_ops = {
> .mux_B_periph = at91_mux_pio3_set_B_periph,
> .mux_C_periph = at91_mux_pio3_set_C_periph,
> .mux_D_periph = at91_mux_pio3_set_D_periph,
> - .get_deglitch = at91_mux_get_deglitch,
> + .get_deglitch = at91_mux_pio3_get_deglitch,
> .set_deglitch = at91_mux_pio3_set_deglitch,
> .get_debounce = at91_mux_pio3_get_debounce,
> .set_debounce = at91_mux_pio3_set_debounce,
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf session: Add option to copy events when queueing
On 9/14/13 10:16 AM, Frederic Weisbecker wrote:
@@ -676,7 +682,12 @@ int perf_session_queue_event(struct perf_session *s, union
perf_event *event,
new->timestamp = timestamp;
new->file_offset = file_offset;
- new->event = event;
+
+ if (s->copy_on_queue) {
+ new->event = malloc(event->header.size);
+ memcpy(new->event, event, event->header.size);
+ } else
+ new->event = event;
---8<---
So do you think it should stay optional? This looks like a global problem, I
mean
the event can be unmapped anytime for any builtin tool mapping it, right?
Yes. I could make it the default behavior; just overhead in doing that
(malloc/copy for each event).
Also we already allocate the sample list node (struct sample_queue) from
os->sample
buffer. ie: we have our own allocator there.
Probably we should reuse that and include the copied event space in "struct
sample_queue"?
Right, that's where I put the malloc and copy - I kept the relevant
change above. I take it you are thinking of something different but I am
not following you. You definitely do NOT want to change struct
sample_queue to include an event - like this:
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 51f5edf..866944a 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -491,7 +491,7 @@ static perf_event__swap_op perf_event__swap_ops[] = {
struct sample_queue {
u64 timestamp;
u64 file_offset;
- union perf_event*event;
+ union perf_eventevent;
struct list_headlist;
};
size of event is determined by mmap_event (mmap2_event in latest code)
which is > 4096 because of the filename argument. Including the event
directly in sample_queue would balloon memory usage (learned this the
hard way!).
Also looking at it now, it seems we have a bug on the existing code:
if (!list_empty(sc)) {
new = list_entry(sc->next, struct sample_queue, list);
list_del(&new->list);
} else if (os->sample_buffer) {
new = os->sample_buffer + os->sample_buffer_idx;
if (++os->sample_buffer_idx == MAX_SAMPLE_BUFFER)
os->sample_buffer = NULL;
} else {
os->sample_buffer = malloc(MAX_SAMPLE_BUFFER * sizeof(*new));
if (!os->sample_buffer)
return -ENOMEM;
list_add(&os->sample_buffer->list, &os->to_free);
os->sample_buffer_idx = 2;
new = os->sample_buffer + 1;
}
If we actually run out of buffer rooms, we should realloc right after and not
wait for the next entry, otherwise we loose an event:
if (!list_empty(sc)) {
new = list_entry(sc->next, struct sample_queue, list);
list_del(&new->list);
} else {
if (os->sample_buffer) {
new = os->sample_buffer + os->sample_buffer_idx;
if (++os->sample_buffer_idx == MAX_SAMPLE_BUFFER)
os->sample_buffer = NULL;
}
if (!os->sample_buffer) {
os->sample_buffer = malloc(MAX_SAMPLE_BUFFER *
sizeof(*new));
if (!os->sample_buffer)
return -ENOMEM;
list_add(&os->sample_buffer->list, &os->to_free);
os->sample_buffer_idx = 2;
new = os->sample_buffer + 1;
}
Although the mirrored os->sample_buffer condition check is a bit ugly and
should move to
a function. But the idea is there.
Ok. That should be a separate patch. Are you going to submit that one?
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: audit looks unmaintained? [was: Re: [PATCH 11/12] pid: rewrite task helper functions avoiding task->pid and task->tgid]
On 09/13, Steve Grubb wrote: > > On Sunday, September 08, 2013 05:54:35 PM Oleg Nesterov wrote: > > > > Then why audit_alloc() doesn't set TIF_SYSCALL_AUDIT unconditionally? > > The code I'm looking at does right at the end of the function. The code I'm looking at does right at the end too ;) but it also returns at the start if audit_filter_task() returns AUDIT_DISABLED. > > And I do not understand "when context == NULL" above. Say, > > audit_syscall_entry() does nothing if !audit_context, and nobody except > > copy_process() does audit_alloc(). So why do we need to trigger the audit's > > paths if it is NULL? > > Because if you enter the audit framework, framework? TIF_SYSCALL_AUDIT has only meaning in entry.S, we need it to ensure that the audited task can't miss audit_syscall_*(). > that means auditing has been turned > on at some point in the past, and could be turned back on at some point in the > future. And this will change nothing, afaics (wrt TIF_SYSCALL_AUDIT). 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/
