RE: [regression] cross core scheduling frequency drop bisected to 0c313cb20732
On 2106.04.09 20:45 Rafael J. Wysocki wrote: >On Sat, Apr 9, 2016 at 6:39 PM, Mike Galbraith wrote: >> >> Hm, setting gov=performance, and taking the average of 3 30 second >> interval PkgWatt samples as pipe-test runs.. >> >> 714KHz/28.03Ws = 25.46 >> 877KHz/30.28Ws = 28.96 >> >> ..for pipe-test, the tradeoff look a bit more like red than green. > > Well, fair enough, but that's just pipe-test, and what about the > people who don't see the performance gain and see the energy loss, > like Doug? Some numbers from my computer: Pipe-test (100 seconds): Kernel 4.6-rc2 gov=powersave: Stock: 3.86 uSecs/loop and 3148.05 Joules Reverted: 3.34 uSecs/loop and 3567.43 Joules Reverted is 13% faster at a cost of 13% more energy. Idle stats (done separately and for 20e6 loops) State k46rc2-ps (sec) k46rc2-rev-ps(sec) 0.000.014.09 1.0038.68 0.00 2.000.460.27 3.000.010.00 4.00464.23 380.23 total 503.38 384.60 Kernel 4.6-rc2 gov=performance: Stock: 3.89 uSecs/loop and 3154.72 Joules Reverted: 3.25 uSecs/loop and 3445.90 Joules Reverted is 16% faster at a cost of 9% more energy. Idle stats (done separately and for 20e6 loops) State k46rc2-pf (sec) k46rc2-rev-pf (sec) 0.000.001.43 1.0038.89 0.04 2.002.080.03 3.000.010.01 4.00463.05 381.54 total 504.03 383.05 9 incremental kernel compiles, with no changes: (the reference test from last cycle): (2000 seconds turbostat package energy sample time): There is no detectable consistent change in compile times: Kernel 4.6-rc2 gov=powersave: Stock: 48557 Joules Reverted: 65439 Joules Reverted costs 34% more energy. (note: this result is unusually high. There are variations test to test) Kernel 4.6-rc2 gov=performance: Stock: 49965 Joules Reverted: 59232 Joules Reverted costs 19% more energy. (note: never tested gov=performance before) Idle stats not re-done (we had several samples last cycle). > Essentially, this trades performance gains in somewhat special > workloads for increased energy consumption in idle. Those workloads > need not be run by everybody, but idle is. > > That said I applied the patch you're complaining about mostly because > the commit that introduced the change in question in 4.5 claimed that > it wouldn't affect idle power on systems with reasonably fast C1, but > that didn't pass the reality test. I'm not totally against restoring > that change, but it would need to be based on very solid evidence. ... Doug
[PULL REQUEST] i2c for 4.6
Linus, some bugfixes from I2C: * fix a uevent triggered boot problem by removing a useless debug print * fix sysfs-attributes of the new i2c-demux-pinctrl driver to follow standard kernel behaviour * fix a potential division-by-zero error (needed two takes) Please pull. Wolfram The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to caf280800aaf73f0796d1bb3fa0f6576c858: i2c: jz4780: really prevent potential division by zero (2016-04-09 08:36:44 +0200) Ben Hutchings (1): i2c: mux: demux-pinctrl: Clean up sysfs attributes Wolfram Sang (5): i2c: prevent endless uevent loop with CONFIG_I2C_DEBUG_CORE i2c: mux: demux-pinctrl: Update docs to new sysfs-attributes i2c: jz4780: prevent potential division by zero Revert "i2c: jz4780: prevent potential division by zero" i2c: jz4780: really prevent potential division by zero .../ABI/testing/sysfs-platform-i2c-demux-pinctrl | 29 +++- drivers/i2c/busses/i2c-jz4780.c| 7 +++- drivers/i2c/i2c-core.c | 10 ++ drivers/i2c/muxes/i2c-demux-pinctrl.c | 39 -- 4 files changed, 49 insertions(+), 36 deletions(-) signature.asc Description: PGP signature
[PATCHv2] wlcore: spi: add wl18xx support
Add support for using with both wl12xx and wl18xx.
- all wilink family needs special init command for entering wspi mode.
extra clock cycles should be sent after the spi init command while the
cs pin is high.
- switch to controling the cs pin from the spi driver for achieveing the
above.
- the selected cs gpio is read from the spi device-tree node using the
cs-gpios field and setup as a gpio.
- See the example below for specifying the cs gpio using the cs-gpios entry
&spi0 {
...
cs-gpios = <&gpio0 5 0>;
...
wlcore: wlcore@0 {
compatible = "ti,wl1835";
...
...
};
};
Signed-off-by: Eyal Reizer
---
v1 -> v2: update device tree bindings documentation
.../bindings/net/wireless/ti,wlcore,spi.txt| 50 +-
drivers/net/wireless/ti/wlcore/spi.c | 176 +---
2 files changed, 200 insertions(+), 26 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..912ab0c 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,31 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
document describes the binding for the SPI connected chip.
Required properties:
-- compatible : Should be "ti,wl1271"
+- compatible : Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
- reg : Chip select address of device
- spi-max-frequency : Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
- interrupt-parent, interrupts :
Should contain parameters for 1 interrupt line.
Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip
+- cs-gpios :GPIO pin used as the spi chip select
Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
- clock-xtal : boolean, clock is generated from XTAL
- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,10 +33,16 @@ Optional properties:
Examples:
+For wl12xx family:
&spi1 {
- wl1271@1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+ cs-gpios = <&gpio0 5 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ wlcore: wlcore@0 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
clock-xtal;
@@ -34,3 +52,21 @@ Examples:
vwlan-supply = <&vwlan_fixed>;
};
};
+
+For wl18xx family:
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ cs-gpios = <&gpio0 5 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ wlcore: wlcore@0 {
+ compatible = "ti,wl1835";
+ vwlan-supply = <&wlan_en_reg>;
+ spi-max-frequency = <4800>;
+ reg = <0>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+ };
+};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c
b/drivers/net/wireless/ti/wlcore/spi.c
index 020ac1a..fb48a0d 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "wlcore.h"
#include "wl12xx_80211.h"
@@ -70,16 +71,30 @@
#define WSPI_MAX_CHUNK_SIZE4092
/*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
*/
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
/* Maximum number of SPI write chunks */
#define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
+struct wilink_familiy_data {
+ char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+ .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+ .name = "wl12xx",
+};
+
struc
Re: [PATCH 1/2] ARM: exynos_defconfig: Enable CPUFreq governors as modules
On Fri, Apr 08, 2016 at 03:02:09PM -0400, Javier Martinez Canillas wrote: > Currently only the ondemand and performance CPUFreq policy governors are > enabled in the Exynos defconfig. But the other governors are also useful > for some cases, enable them to allow users change the default if needed. > > The options are enabled as module to keep the kernel image size minimal. > > Signed-off-by: Javier Martinez Canillas > --- > > arch/arm/configs/exynos_defconfig | 4 > 1 file changed, 4 insertions(+) Hi, Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 2/2] ARM: multi_v7_defconfig: Enable CPUFreq governors as modules
On Fri, Apr 08, 2016 at 03:02:10PM -0400, Javier Martinez Canillas wrote: > Currently only the ondemand and performance CPUFreq policy governors are > enabled in multi_v7 defconfig. But the other governors are also useful > for some cases, enable them to allow users change the default if needed. > > The options are enabled as module to keep the kernel image size minimal. > > Signed-off-by: Javier Martinez Canillas > > --- > > arch/arm/configs/multi_v7_defconfig | 4 > 1 file changed, 4 insertions(+) Hi, Makes sense for me. If there are no objections I can take it through samsung-soc tree along with exynos_defconfig change. Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks
On 2016/04/09 at 21:29, Peter Zijlstra wrote: > On Sat, Apr 09, 2016 at 11:25:39AM +0800, Xunlei Pang wrote: > >>> In any case, I just realized we do not in fact provide this guarantee >>> (of pointing to a blocked task) that needs a bit more work. >> Current patch calls rt_mutex_adjust_prio() before wake_up_q() the >> wakee, at that moment the wakee has been removed by >> rt_mutex_slowunlock()->mark_wakeup_next_waiter(), from current's >> pi_waiters, rt_mutex_adjust_prio() won't see this wakee, so I think >> this should not be problem. > No, any wakeup after mark_wakeup_next_waiter() will make the task run. > And since we must always consider spurious wakeups, we cannot rely on us > (eg. our wake_up_q call) being the one and only. > > Therefore it is possible and the only thing that stands between us and > doom is the fact that the wake_q stuff holds a task reference. > > But we cannot guarantee that the task we have a pointer to is in fact > blocked. Does that really matters? the pointer is accessed on behalf of current, and current will call rt_mutex_adjust_prio() very soon to update the right pointer. Also the pointer is used to update current's deadline/runtime, we can restore these params in rt_mutex_setprio() for deboost cases. I just checked current code, it did nothing to restore current's deadline/runtime when deboosting, maybe we can leave this job to future deadline bandwidth inheritance? Regards, Xunlei
Re: [PATCH 2/2] tty: Remove stale parameter comment
On 04/10/2016, 05:36 AM, Peter Hurley wrote:
> noctty was removed as a parameter by commit 216513411937586
It is actually 11e1d4aa4da.
> ("tty: Consolidate noctty check in tty_open()").
>
> Signed-off-by: Peter Hurley
> ---
> drivers/tty/tty_io.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 3cdd63b..50979be 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -1960,7 +1960,6 @@ static struct tty_struct *tty_open_current_tty(dev_t
> device, struct file *filp)
> * tty_lookup_driver - lookup a tty driver for a given device file
> * @device: device number
> * @filp: file pointer to tty
> - * @noctty: set if the device should not become a controlling tty
> * @index: index for the device in the @return driver
> * @return: driver for this inode (with increased refcount)
> *
>
--
js
suse labs
Re: [PATCH 1/2] mfd: max77693: Allow building as a module
On Fri, Apr 08, 2016 at 08:17:21AM +0100, Lee Jones wrote: > > Yes, this can be taken as is. Only second patch (changing defconfig) > > depends on this. I can take the second patch through samsung tree but > > that would require a tag/branch with this... which looks like an > > overkill. So maybe you would take both? > > If I take the defconfig patch without a tag, there will almost > certainly be merge conflicts. Other solutions include; delaying the > defconfig patch for one cycle or trying to get it in post -rc1. Let's wait for next cycle then. Anyway Javier added module-capability to some other drivers as well so we can change all them at once. Best regards, Krzysztof
[PATCH kernel.org] change 3.12 EOL
From: Jiri Slaby Since SLE12-SP1 is based upon 3.12 and its EOL is in 2017, move the EOL of 3.12 to 2017 too. Signed-off-by: Jiri Slaby --- content/releases.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/releases.rst b/content/releases.rst index 28ebf47834..14494a64cd 100644 --- a/content/releases.rst +++ b/content/releases.rst @@ -44,7 +44,7 @@ Longterm 4.1 Sasha Levin 2015-06-21 Sep, 2017 3.18 Sasha Levin 2014-12-07 Jan, 2017 3.14 Greg Kroah-Hartman 2014-03-30 Aug, 2016 -3.12 Jiri Slaby 2013-11-03 2016 +3.12 Jiri Slaby 2013-11-03 Jan, 2017 3.10 Greg Kroah-Hartman 2013-06-30 End of 2015 3.4 Li Zefan 2012-05-20 Sep, 2016 3.2 Ben Hutchings2012-01-04 May, 2018 -- 2.8.1
Re: [PATCH 2/2] asus-laptop: remove unused variable
On Sat, Apr 09, 2016 at 08:21:21PM -0700, Darren Hart wrote:
> On Thu, Apr 07, 2016 at 11:20:01PM +0300, Giedrius Statkevičius wrote:
> > `out' was assigned value but it was never used so remove it
> >
> > Signed-off-by: Giedrius Statkevičius
> > ---
> > drivers/platform/x86/asus-laptop.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/platform/x86/asus-laptop.c
> > b/drivers/platform/x86/asus-laptop.c
> > index d86d42e..39ddcee 100644
> > --- a/drivers/platform/x86/asus-laptop.c
> > +++ b/drivers/platform/x86/asus-laptop.c
> > @@ -946,11 +946,8 @@ static ssize_t sysfs_acpi_set(struct asus_laptop *asus,
> > const char *method)
> > {
> > int rv, value;
> > - int out = 0;
> >
> > rv = parse_arg(buf, count, &value);
> > - if (rv > 0)
> > - out = value ? 1 : 0;
> >
> > if (write_acpi_int(asus->handle, method, value))
>
> out is indeed unused, however the rv > 0 condition is relevant as <=0 will
> pass
> value uninitialized to write_acpi_int.
That's indeed a problem. Somehow I missed that :( Should I make a v2 to include
another patch that checks for rv < 0 or send it as an independent one?
[GIT PULL] MMC fixes for v.4.6 rc3
Hi Linus, Here are a couple of mmc fixes intended for v4.6 rc3 (or rc4 as I guess it's late for rc3). It's based on v4.6 rc1. Details are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.6-rc1 for you to fetch changes up to 01d6b2a40a0fa73c90e05b1033f181a51fec9292: mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers (2016-04-05 12:14:09 +0200) MMC host: - sdhci: Fix regression setting power on Trats2 board - sdhci-pci: Add support and PCI IDs for more Broxton host controllers Adrian Hunter (2): mmc: sdhci: Fix regression setting power on Trats2 board mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers drivers/mmc/host/sdhci-pci-core.c | 25 + drivers/mmc/host/sdhci-pci.h | 3 +++ drivers/mmc/host/sdhci-pxav3.c| 22 ++ drivers/mmc/host/sdhci.c | 39 ++- drivers/mmc/host/sdhci.h | 4 5 files changed, 84 insertions(+), 9 deletions(-)
Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732
On Sun, 2016-04-10 at 05:44 +0200, Rafael J. Wysocki wrote:
> On Sat, Apr 9, 2016 at 6:39 PM, Mike Galbraith <
> umgwanakikb...@gmail.com> wrote:
> >
> > Hm, setting gov=performance, and taking the average of 3 30 second
> > interval PkgWatt samples as pipe-test runs..
> >
> > 714KHz/28.03Ws = 25.46
> > 877KHz/30.28Ws = 28.96
> >
> > ..for pipe-test, the tradeoff look a bit more like red than green.
>
> Well, fair enough, but that's just pipe-test, and what about the
> people who don't see the performance gain and see the energy loss,
> like Doug?
Perhaps Doug sees increased power because he's not throttling no_hz,
whereas I am, so he burns more power getting _to_ idle? Dunno, maybe
he'll try the attached. If it's a general case energy loser, so be it,
numbers talk, bs walks and all that ;-)
> Essentially, this trades performance gains in somewhat special
> workloads for increased energy consumption in idle. Those workloads
> need not be run by everybody, but idle is.
Cross core scheduling is routine business, we do truckloads of that for
good reason, and lots of stuff does wakeups at high frequency.
> That said I applied the patch you're complaining about mostly because
> the commit that introduced the change in question in 4.5 claimed that
> it wouldn't affect idle power on systems with reasonably fast C1, but
> that didn't pass the reality test. I'm not totally against restoring
> that change, but it would need to be based on very solid evidence.
Understood. My box seems to be saying we can hug the trees hardest by
telling the CPU get work done as quickly as possible, but I don't have
much experience at tree hugging measurement. Performance wise, tasks
talking via localhost is definitely not special.
tbench 1 2 4 8
base 752 1283 2250 3362
select_idle_sibling() off
735 1344 2080 2884
delta .977 1.047 .924 .857
select_idle_sibling() on, 0c313cb20732 reverted
816 1317 2240 3388
delta 1.085 1.026 .995 1.007 vs base
delta 1.110 .979 1.076 1.174 vs off
(^hm)
-Mikesched: ratelimit nohz
Entering nohz code on every micro-idle is too expensive to bear.
Signed-off-by: Mike Galbraith
---
include/linux/sched.h|5 +
kernel/sched/core.c |8
kernel/time/tick-sched.c |2 +-
3 files changed, 14 insertions(+), 1 deletion(-)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2286,6 +2286,11 @@ static inline int set_cpus_allowed_ptr(s
#ifdef CONFIG_NO_HZ_COMMON
void calc_load_enter_idle(void);
void calc_load_exit_idle(void);
+#ifdef CONFIG_SMP
+extern int sched_needs_cpu(int cpu);
+#else
+static inline int sched_needs_cpu(int cpu) { return 0; }
+#endif
#else
static inline void calc_load_enter_idle(void) { }
static inline void calc_load_exit_idle(void) { }
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -577,6 +577,14 @@ static inline bool got_nohz_idle_kick(vo
return false;
}
+int sched_needs_cpu(int cpu)
+{
+ if (tick_nohz_full_cpu(cpu))
+ return 0;
+
+ return cpu_rq(cpu)->avg_idle < sysctl_sched_migration_cost;
+}
+
#else /* CONFIG_NO_HZ_COMMON */
static inline bool got_nohz_idle_kick(void)
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -676,7 +676,7 @@ static ktime_t tick_nohz_stop_sched_tick
} while (read_seqretry(&jiffies_lock, seq));
ts->last_jiffies = basejiff;
- if (rcu_needs_cpu(basemono, &next_rcu) ||
+ if (sched_needs_cpu(cpu) || rcu_needs_cpu(basemono, &next_rcu) ||
arch_needs_cpu() || irq_work_needs_cpu()) {
next_tick = basemono + TICK_NSEC;
} else {
Re: sched: tweak select_idle_sibling to look for idle threads
On Sat, 2016-04-09 at 15:05 -0400, Chris Mason wrote: > This does preserve the existing logic to prefer idle cores over idle > CPU threads, and includes some tests to try and avoid the idle scan when we're > actually better off sharing a non-idle CPU with someone else. My box says the "oh nevermind" checks aren't selective enough, tbench dropped 4% at clients=cores, and 2% at clients=threads. > Benchmarks in production show overall capacity going up between 2-5% > depending on the metric. Latency rules all loads certainly exist, and clearly want some love, but the bigger the socket, and the more threads/core, the more that traverse is gonna hurt the others, so seems either we need a better filter, or a (yeah yeah, yet another damn) tweakable. Oh, and bounce_to_target() seems an odd way to say full_traverse. -Mike
Re: [PATCH] staging: wilc1000: rework comments in wilc_sdio.c
Hi Mohammed, On Sun, Apr 10, 2016 at 5:11 AM, wrote: > From: Mohammed Billoo > > Remove unnecessary comments (highlighting sections of functions), make > multiline comments into single line comments, and ensure that multiline > comments adhere to coding style. You need to add a signed-off-by line here. > --- > drivers/staging/wilc1000/wilc_sdio.c | 136 > --- > 1 file changed, 31 insertions(+), 105 deletions(-) > Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
[PATCH] thunderbolt: Fix double free of drom buffer
If tb_drom_read fails sw->drom is freed but not set to NULL. sw->drom is then freed again in the error path of sw_switch_alloc. The bug can be triggered by unplugging a thunderbolt device shortly after it is detected by the thunderbolt driver. Signed-off-by: Andreas Noever Cc: Lukas Wunner Cc: sta...@vger.kernel.org --- drivers/thunderbolt/eeprom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c index 0dde34e..545c60c 100644 --- a/drivers/thunderbolt/eeprom.c +++ b/drivers/thunderbolt/eeprom.c @@ -444,6 +444,7 @@ int tb_drom_read(struct tb_switch *sw) return tb_drom_parse_entries(sw); err: kfree(sw->drom); + sw->drom = NULL; return -EIO; } -- 2.8.0
Re: [PATCH] fujitsu-laptop: Support radio LED
Hi Darren Thanks for the ping. On Sat, Apr 09, 2016 at 07:30:20PM -0700, Darren Hart wrote: > On Thu, Mar 24, 2016 at 10:05:14PM +1030, Jonathan Woithe wrote: > > This is a quick reply with preliminary information. I'll follow up in the > > next few days with further details. > > > > On Tue, Mar 22, 2016 at 02:30:51PM +0100, Micha?? K??pie?? wrote: > > > > > As for detecting whether the LED is present on a given machine, I had > > > > > to > > > > > resort to educated guesswork. I assumed this LED is present on all > > > > > devices which have a radio toggle button instead of a slider. My > > > > > Lifebook E744 holds 0x01010001 in BTNI. By comparing the bits and > > > > > buttons with those of a Lifebook E8420 (BTNI=0x000F0101, has a > > > > > slider), > > > > > I put my money on bit 24 as the indicator of the radio toggle button > > > > > being present. > > > > > > > > The other question is how consistent the bit layout is across all > > > > devices > > > > which might make use of this driver. The set of potential devices spans > > > > nearly 10 years, and in many ways it would be surprising if the bit > > > > definitions were kept the same over that time. Testing would be the > > > > only > > > > way to get a feeling for that. > > > > > > My thoughts exactly. > > > > > > > If you could let me know how you went about > > > > acquiring the values on your machine I could try the exact same steps > > > > on the > > > > S7020 to see what we get. > > > > > > The BTNI value is printed to the kernel log buffer by > > > acpi_fujitsu_hotkey_add(), so all it takes to retrieve it is: > > > > > > dmesg | grep BTNI > > > > Here's what's reported by the S7020: > > > > fujitsu_laptop: BTNI: [0xf0001] > > > > The S7020 doesn't have any LEDs. It also has a physical slider to enable RF > > and an "RF enabled" indicator in the LCD panel. The LCD indicator is under > > hardware control; software cannot influence it. > > > > Clearly bit 24 is *not* set on the S7020. Using this bit as a test for the > > button's presence therefore should not cause trouble for the S7020 and > > probably other similar models from that time. Obviously we don't have > > access to every single model, but the apparent consistency back to the S7020 > > is encouraging. > > > > > > > While it's not essential, it would be nice to initialize soft rfkill > > > > > state of all radio transmitters to the value of RFSW upon boot. > > > > > > > > I think this would only be necessary for those machines with the RF > > > > button > > > > in place of the hard slider switch, right? > > > > > > Yes. On the E8420 I tested, moving the slider switch to "off" position > > > caused the Bluetooth device to be removed from the system altogether > > > while iwlwifi reacted by hard-blocking phy0. > > > > I haven't noticed anything that dramatic on the S7020, but anything's > > possible. > > Jonathan, Micha??, > > Where are we with this? The above reads as "Doesn't appear to break existing > systems on hand". Jonathan, are you happy with this patch? Sorry, I got caught up over the last couple of weeks with other tasks and have not yet managed to confirm the lack of regressions on the S7020. It was on my list for this coming week though. My comments quoted above were theoretical rather than based on an actual test. The patch appears fairly innoculous given that BTNI bit 24 is not set on the S7020 but for completeness I would prefer to give it a run on the S7020 before we merge the patch. I will make an effort to fit this in over the next couple of days. > Micha??, do you have plans for a v2? I wasn't clear on this myself. I suspect, given the lack of a v2 in the time since the last discussion, that there is no v2 planned at this stage and I will proceed with my testing accordingly. Regards jonathan
Re: [PATCH v2] iio: potentiometer: add driver for Maxim Integrated DS1803
On 09/04/16 12:12, Slawomir Stepien wrote:
> On Apr 08, 2016 23:27, Slawomir Stepien wrote:
>> +static int ds1803_read_raw(struct iio_dev *indio_dev,
>> +struct iio_chan_spec const *chan,
>> +int *val, int *val2, long mask)
>> +{
>> +struct ds1803_data *data = iio_priv(indio_dev);
>> +int pot = chan->channel;
>> +int ret;
>> +u16 result;
>> +
>> +switch (mask) {
>> +case IIO_CHAN_INFO_RAW:
>> +ret = i2c_master_recv(data->client, (char *)&result,
>> +indio_dev->num_channels);
>> +if (ret < 0)
>> +return ret;
>> +
>> +/* Get bits for given pot */
>> +*val = (pot == 0 ? result & 0xff : result >> 8);
>> +return IIO_VAL_INT;
>> +
>> +case IIO_CHAN_INFO_SCALE:
>> +*val = 1000 * data->cfg->kohms;
>> +*val2 = DS1803_MAX_POS;
>> +return IIO_VAL_FRACTIONAL;
>> +}
>> +
>> +return -EINVAL;
>> +}
>
> Or maybe this is more clean?
>
> static int ds1803_read_raw(struct iio_dev *indio_dev,
> struct iio_chan_spec const *chan,
> int *val, int *val2, long mask)
> {
> struct ds1803_data *data = iio_priv(indio_dev);
> int pot = chan->channel;
> int ret;
> unsigned char result[indio_dev->num_channels];
I'd use u8 to make it of an explicit size but otherwise this is indeed
a little bit cleaner.
>
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> ret = i2c_master_recv(data->client, result,
> indio_dev->num_channels);
> if (ret < 0)
> return ret;
>
> *val = result[pot];
> return IIO_VAL_INT;
>
> case IIO_CHAN_INFO_SCALE:
> *val = 1000 * data->cfg->kohms;
> *val2 = DS1803_MAX_POS;
> return IIO_VAL_FRACTIONAL;
> }
>
> return -EINVAL;
> }
>
> What do you think?
>
Re: [PATCH v2] iio: potentiometer: add driver for Maxim Integrated DS1803
On 08/04/16 22:27, Slawomir Stepien wrote:
> The following functions are supported:
> - write, read potentiometer value
> - potentiometer scale
>
> Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1803.pdf
>
> Signed-off-by: Slawomir Stepien
Looks good to me, but as you pointed out a slight cleanup I'll wait for v3
before taking this one.
> ---
> Changes since v1:
> - Removed unnecessary include file
> - Use i2c_master_recv() in place of i2c_smbus_read_word_swapped()
> - On raw write make sure val2 is zero
> - Use ARRAY_SIZE when possible
>
> .../bindings/iio/potentiometer/ds1803.txt | 21 +++
> drivers/iio/potentiometer/Kconfig | 10 ++
> drivers/iio/potentiometer/Makefile | 1 +
> drivers/iio/potentiometer/ds1803.c | 174
> +
> 4 files changed, 206 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
> create mode 100644 drivers/iio/potentiometer/ds1803.c
>
> diff --git a/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
> b/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
> new file mode 100644
> index 000..df77bf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
> @@ -0,0 +1,21 @@
> +* Maxim Integrated DS1803 digital potentiometer driver
> +
> +The node for this driver must be a child node of a I2C controller, hence
> +all mandatory properties for your controller must be specified. See
> directory:
> +
> +Documentation/devicetree/bindings/i2c
> +
> +for more details.
> +
> +Required properties:
> + - compatible: Must be one of the following, depending on the
> + model:
> + "maxim,ds1803-010",
> + "maxim,ds1803-050",
> + "maxim,ds1803-100"
> +
> +Example:
> +ds1803: ds1803@1 {
> + reg = <0x28>;
> + compatible = "maxim,ds1803-010";
> +};
> diff --git a/drivers/iio/potentiometer/Kconfig
> b/drivers/iio/potentiometer/Kconfig
> index 7ea069b..6acb238 100644
> --- a/drivers/iio/potentiometer/Kconfig
> +++ b/drivers/iio/potentiometer/Kconfig
> @@ -5,6 +5,16 @@
>
> menu "Digital potentiometers"
>
> +config DS1803
> + tristate "Maxim Integrated DS1803 Digital Potentiometer driver"
> + depends on I2C
> + help
> + Say yes here to build support for the Maxim Integrated DS1803
> + digital potentiomenter chip.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ds1803.
> +
> config MCP4131
> tristate "Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X Digital
> Potentiometer driver"
> depends on SPI
> diff --git a/drivers/iio/potentiometer/Makefile
> b/drivers/iio/potentiometer/Makefile
> index 91a80f8..6007faa 100644
> --- a/drivers/iio/potentiometer/Makefile
> +++ b/drivers/iio/potentiometer/Makefile
> @@ -3,6 +3,7 @@
> #
>
> # When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_DS1803) += ds1803.o
> obj-$(CONFIG_MCP4131) += mcp4131.o
> obj-$(CONFIG_MCP4531) += mcp4531.o
> obj-$(CONFIG_TPL0102) += tpl0102.o
> diff --git a/drivers/iio/potentiometer/ds1803.c
> b/drivers/iio/potentiometer/ds1803.c
> new file mode 100644
> index 000..cfa4cc1
> --- /dev/null
> +++ b/drivers/iio/potentiometer/ds1803.c
> @@ -0,0 +1,174 @@
> +/*
> + * Maxim Integrated DS1803 digital potentiometer driver
> + * Copyright (c) 2016 Slawomir Stepien
> + *
> + * Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1803.pdf
> + *
> + * DEVID #Wipers #Positions Resistor Opts (kOhm)i2c address
> + * ds18032 256 10, 50, 100 0101xxx
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DS1803_MAX_POS 255
> +#define DS1803_WRITE(chan) (0xa8 | ((chan) + 1))
> +
> +enum ds1803_type {
> + DS1803_010,
> + DS1803_050,
> + DS1803_100,
> +};
> +
> +struct ds1803_cfg {
> + int kohms;
> +};
> +
> +static const struct ds1803_cfg ds1803_cfg[] = {
> + [DS1803_010] = { .kohms = 10, },
> + [DS1803_050] = { .kohms = 50, },
> + [DS1803_100] = { .kohms = 100, },
> +};
> +
> +struct ds1803_data {
> + struct i2c_client *client;
> + const struct ds1803_cfg *cfg;
> +};
> +
> +#define DS1803_CHANNEL(ch) { \
> + .type = IIO_RESISTANCE, \
> + .indexed = 1, \
> + .output = 1,\
> + .channel = (ch),\
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .
[PATCH v3] iio: potentiometer: add driver for Maxim Integrated DS1803
The following functions are supported:
- write, read potentiometer value
- potentiometer scale
Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1803.pdf
Signed-off-by: Slawomir Stepien
---
Changes since v2:
- Use array of u8 as a result type for i2c_master_recv() call
Changes since v1:
- Removed unnecessary include file
- Use i2c_master_recv() in place of i2c_smbus_read_word_swapped()
- On raw write make sure val2 is zero
- Use ARRAY_SIZE when possible
.../bindings/iio/potentiometer/ds1803.txt | 21 +++
drivers/iio/potentiometer/Kconfig | 10 ++
drivers/iio/potentiometer/Makefile | 1 +
drivers/iio/potentiometer/ds1803.c | 173 +
4 files changed, 205 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
create mode 100644 drivers/iio/potentiometer/ds1803.c
diff --git a/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
b/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
new file mode 100644
index 000..df77bf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
@@ -0,0 +1,21 @@
+* Maxim Integrated DS1803 digital potentiometer driver
+
+The node for this driver must be a child node of a I2C controller, hence
+all mandatory properties for your controller must be specified. See directory:
+
+Documentation/devicetree/bindings/i2c
+
+for more details.
+
+Required properties:
+ - compatible: Must be one of the following, depending on the
+ model:
+ "maxim,ds1803-010",
+ "maxim,ds1803-050",
+ "maxim,ds1803-100"
+
+Example:
+ds1803: ds1803@1 {
+ reg = <0x28>;
+ compatible = "maxim,ds1803-010";
+};
diff --git a/drivers/iio/potentiometer/Kconfig
b/drivers/iio/potentiometer/Kconfig
index 7ea069b..6acb238 100644
--- a/drivers/iio/potentiometer/Kconfig
+++ b/drivers/iio/potentiometer/Kconfig
@@ -5,6 +5,16 @@
menu "Digital potentiometers"
+config DS1803
+ tristate "Maxim Integrated DS1803 Digital Potentiometer driver"
+ depends on I2C
+ help
+ Say yes here to build support for the Maxim Integrated DS1803
+ digital potentiomenter chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ds1803.
+
config MCP4131
tristate "Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X Digital
Potentiometer driver"
depends on SPI
diff --git a/drivers/iio/potentiometer/Makefile
b/drivers/iio/potentiometer/Makefile
index 91a80f8..6007faa 100644
--- a/drivers/iio/potentiometer/Makefile
+++ b/drivers/iio/potentiometer/Makefile
@@ -3,6 +3,7 @@
#
# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_DS1803) += ds1803.o
obj-$(CONFIG_MCP4131) += mcp4131.o
obj-$(CONFIG_MCP4531) += mcp4531.o
obj-$(CONFIG_TPL0102) += tpl0102.o
diff --git a/drivers/iio/potentiometer/ds1803.c
b/drivers/iio/potentiometer/ds1803.c
new file mode 100644
index 000..fb9e2a3
--- /dev/null
+++ b/drivers/iio/potentiometer/ds1803.c
@@ -0,0 +1,173 @@
+/*
+ * Maxim Integrated DS1803 digital potentiometer driver
+ * Copyright (c) 2016 Slawomir Stepien
+ *
+ * Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1803.pdf
+ *
+ * DEVID #Wipers #Positions Resistor Opts (kOhm)i2c address
+ * ds1803 2 256 10, 50, 100 0101xxx
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DS1803_MAX_POS 255
+#define DS1803_WRITE(chan) (0xa8 | ((chan) + 1))
+
+enum ds1803_type {
+ DS1803_010,
+ DS1803_050,
+ DS1803_100,
+};
+
+struct ds1803_cfg {
+ int kohms;
+};
+
+static const struct ds1803_cfg ds1803_cfg[] = {
+ [DS1803_010] = { .kohms = 10, },
+ [DS1803_050] = { .kohms = 50, },
+ [DS1803_100] = { .kohms = 100, },
+};
+
+struct ds1803_data {
+ struct i2c_client *client;
+ const struct ds1803_cfg *cfg;
+};
+
+#define DS1803_CHANNEL(ch) { \
+ .type = IIO_RESISTANCE, \
+ .indexed = 1, \
+ .output = 1,\
+ .channel = (ch),\
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+static const struct iio_chan_spec ds1803_channels[] = {
+ DS1803_CHANNEL(0),
+ DS1803_CHANNEL(1),
+};
+
+static int ds1803_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+
Re: [PATCH v2] iio: max5487: Add support for Maxim digital potentiometers
On 09/04/16 09:24, Cristina Moraru wrote:
> Add implementation for Maxim MAX5487, MAX5488, MAX5489
> digital potentiometers.
>
> Datasheet:
> http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf
>
> Signed-off-by: Cristina Moraru
> CC: Daniel Baluta
Looks pretty good. A few nitpicks + a somewhat theoretical race condition
in the remove function due to use of devm_iio_device_register.
Rule of thumb is you can't use this unless you have no remove function at all.
(less obviously than normal in this case though!)
Jonathan
> ---
> Changes since v1:
> Fix spacing
> Eliminate max5487_cfg struct
> Add kohms as driver data
> drivers/iio/potentiometer/Kconfig | 11 +++
> drivers/iio/potentiometer/Makefile | 1 +
> drivers/iio/potentiometer/max5487.c | 169
>
> 3 files changed, 181 insertions(+)
> create mode 100644 drivers/iio/potentiometer/max5487.c
>
> diff --git a/drivers/iio/potentiometer/Kconfig
> b/drivers/iio/potentiometer/Kconfig
> index fd75db7..242c62d 100644
> --- a/drivers/iio/potentiometer/Kconfig
> +++ b/drivers/iio/potentiometer/Kconfig
> @@ -5,6 +5,17 @@
>
> menu "Digital potentiometers"
>
> +config MAX5487
> +tristate "Maxim MAX5487/MAX5488/MAX5489 Digital Potentiometer
> driver"
> +depends on SPI
> +help
> + Say yes here to build support for the Maxim
> + MAX5487, MAX5488, MAX5489 digital potentiomenter
> + chips.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called max5487.
> +
> config MCP4531
> tristate "Microchip MCP45xx/MCP46xx Digital Potentiometer driver"
> depends on I2C
> diff --git a/drivers/iio/potentiometer/Makefile
> b/drivers/iio/potentiometer/Makefile
> index 8afe492..bc2dfd8 100644
> --- a/drivers/iio/potentiometer/Makefile
> +++ b/drivers/iio/potentiometer/Makefile
> @@ -3,4 +3,5 @@
> #
>
> # When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_MAX5487) += max5487.o
> obj-$(CONFIG_MCP4531) += mcp4531.o
> diff --git a/drivers/iio/potentiometer/max5487.c
> b/drivers/iio/potentiometer/max5487.c
> new file mode 100644
> index 000..fa455b8
> --- /dev/null
> +++ b/drivers/iio/potentiometer/max5487.c
> @@ -0,0 +1,169 @@
> +/*
> + * max5487.c - Support for MAX5487, MAX5488, MAX5489 digital potentiometers
> + *
> + * Copyright (C) Cristina-Gabriela Moraru
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define MAX5487_DRV_NAME "max5487"
This is one of my pet hates ;) Why have this in a define at the top
of the driver if it is used in only one place - and that place is where
I would expect to look to see what that the driver is called.
Still I don't care that much if you want to leave it here. Just being fussy.
> +
> +#define MAX5487_WRITE_WIPER_A0x01
> +#define MAX5487_WRITE_WIPER_B0x02
> +
> +/* copy both wiper regs to NV regs */
> +#define MAX5487_COPY_AB_TO_NV0x23
> +/* copy both NV regs to wiper regs */
> +#define MAX5487_COPY_NV_TO_AB0x33
> +
> +#define MAX5487_MAX_POS 255
> +
> +struct max5487_data {
> + struct regmap *regmap;
> + int kohms;
> +};
> +
> +#define MAX5487_CHANNEL(ch, addr) { \
> + .type = IIO_RESISTANCE, \
> + .indexed = 1, \
> + .output = 1,\
> + .channel = ch, \
> + .address = addr,\
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> +}
> +
> +static const struct iio_chan_spec max5487_channels[] = {
> + MAX5487_CHANNEL(0, MAX5487_WRITE_WIPER_A),
> + MAX5487_CHANNEL(1, MAX5487_WRITE_WIPER_B),
> +};
> +
> +static int max5487_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct max5487_data *data = iio_priv(indio_dev);
> +
> + if (mask != IIO_CHAN_INFO_SCALE)
> + return -EINVAL;
> +
> + *val = 1000 * data->kohms;
> + *val2 = MAX5487_MAX_POS;
Blank line here marginally preferred.
> + return IIO_VAL_FRACTIONAL;
> +}
> +
> +static int max5487_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct max5487_data *data = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (val < 0
[PATCH] ath9k: remove duplicate assignment of variable ah
From: Colin Ian King
ah is written twice with the same value, remove one of the
redundant assignments to ah.
Signed-off-by: Colin Ian King
---
drivers/net/wireless/ath/ath9k/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index 77ace8d..fb702c4 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -477,7 +477,7 @@ static void ath9k_eeprom_request_cb(const struct firmware
*eeprom_blob,
static int ath9k_eeprom_request(struct ath_softc *sc, const char *name)
{
struct ath9k_eeprom_ctx ec;
- struct ath_hw *ah = ah = sc->sc_ah;
+ struct ath_hw *ah = sc->sc_ah;
int err;
/* try to load the EEPROM content asynchronously */
--
2.7.4
Re: [PATCH v3] iio: potentiometer: add driver for Maxim Integrated DS1803
On 10/04/16 12:23, Slawomir Stepien wrote:
> The following functions are supported:
> - write, read potentiometer value
> - potentiometer scale
>
> Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1803.pdf
>
> Signed-off-by: Slawomir Stepien
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes since v2:
> - Use array of u8 as a result type for i2c_master_recv() call
>
> Changes since v1:
> - Removed unnecessary include file
> - Use i2c_master_recv() in place of i2c_smbus_read_word_swapped()
> - On raw write make sure val2 is zero
> - Use ARRAY_SIZE when possible
>
> .../bindings/iio/potentiometer/ds1803.txt | 21 +++
> drivers/iio/potentiometer/Kconfig | 10 ++
> drivers/iio/potentiometer/Makefile | 1 +
> drivers/iio/potentiometer/ds1803.c | 173
> +
> 4 files changed, 205 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
> create mode 100644 drivers/iio/potentiometer/ds1803.c
>
> diff --git a/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
> b/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
> new file mode 100644
> index 000..df77bf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/potentiometer/ds1803.txt
> @@ -0,0 +1,21 @@
> +* Maxim Integrated DS1803 digital potentiometer driver
> +
> +The node for this driver must be a child node of a I2C controller, hence
> +all mandatory properties for your controller must be specified. See
> directory:
> +
> +Documentation/devicetree/bindings/i2c
> +
> +for more details.
> +
> +Required properties:
> + - compatible: Must be one of the following, depending on the
> + model:
> + "maxim,ds1803-010",
> + "maxim,ds1803-050",
> + "maxim,ds1803-100"
> +
> +Example:
> +ds1803: ds1803@1 {
> + reg = <0x28>;
> + compatible = "maxim,ds1803-010";
> +};
> diff --git a/drivers/iio/potentiometer/Kconfig
> b/drivers/iio/potentiometer/Kconfig
> index 7ea069b..6acb238 100644
> --- a/drivers/iio/potentiometer/Kconfig
> +++ b/drivers/iio/potentiometer/Kconfig
> @@ -5,6 +5,16 @@
>
> menu "Digital potentiometers"
>
> +config DS1803
> + tristate "Maxim Integrated DS1803 Digital Potentiometer driver"
> + depends on I2C
> + help
> + Say yes here to build support for the Maxim Integrated DS1803
> + digital potentiomenter chip.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ds1803.
> +
> config MCP4131
> tristate "Microchip MCP413X/414X/415X/416X/423X/424X/425X/426X Digital
> Potentiometer driver"
> depends on SPI
> diff --git a/drivers/iio/potentiometer/Makefile
> b/drivers/iio/potentiometer/Makefile
> index 91a80f8..6007faa 100644
> --- a/drivers/iio/potentiometer/Makefile
> +++ b/drivers/iio/potentiometer/Makefile
> @@ -3,6 +3,7 @@
> #
>
> # When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_DS1803) += ds1803.o
> obj-$(CONFIG_MCP4131) += mcp4131.o
> obj-$(CONFIG_MCP4531) += mcp4531.o
> obj-$(CONFIG_TPL0102) += tpl0102.o
> diff --git a/drivers/iio/potentiometer/ds1803.c
> b/drivers/iio/potentiometer/ds1803.c
> new file mode 100644
> index 000..fb9e2a3
> --- /dev/null
> +++ b/drivers/iio/potentiometer/ds1803.c
> @@ -0,0 +1,173 @@
> +/*
> + * Maxim Integrated DS1803 digital potentiometer driver
> + * Copyright (c) 2016 Slawomir Stepien
> + *
> + * Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1803.pdf
> + *
> + * DEVID #Wipers #Positions Resistor Opts (kOhm)i2c address
> + * ds18032 256 10, 50, 100 0101xxx
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DS1803_MAX_POS 255
> +#define DS1803_WRITE(chan) (0xa8 | ((chan) + 1))
> +
> +enum ds1803_type {
> + DS1803_010,
> + DS1803_050,
> + DS1803_100,
> +};
> +
> +struct ds1803_cfg {
> + int kohms;
> +};
> +
> +static const struct ds1803_cfg ds1803_cfg[] = {
> + [DS1803_010] = { .kohms = 10, },
> + [DS1803_050] = { .kohms = 50, },
> + [DS1803_100] = { .kohms = 100, },
> +};
> +
> +struct ds1803_data {
> + struct i2c_client *client;
> + const struct ds1803_cfg *cfg;
> +};
> +
> +#define DS1803_CHANNEL(ch) { \
> + .type = IIO_RESISTANCE, \
> + .indexed = 1, \
> + .output = 1,\
> + .channel = (ch
Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
Hi! > > > wl1251 does not support AP mode, so there is no firmware for it in > > > the tree. > > > > > > Regards, > > > Yaniv > > > > Hi Yaniv! I read on some TI whitepaper, that wl1251 hardware supports > > some Soft-AP mode. So I expect that either special FW is needed for it > > or somehow it is possible to use current released. Do you have any > > information about it? > > Hi Pali, > This must be some typo, the device does not support Soft-AP. > More than that, wl1251 family is not officially supported via the mainline > Linux. > For Soft-AP, and other new features based on Linux you should use WiLink8 > chip family. Too late for that, we already have the devices, and they were manufactured quite long time ago. Is it "hardware can't do AP", "firmware can't do AP" or "current drivers do not support AP"? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH 1/1] iio: adc: Add driver for the TI INA3221 Triple Current/Voltage Monitor
On 08/04/16 19:19, Andrew F. Davis wrote: > The INA3221 is a three-channel, high-side current and bus voltage monitor > with an I2C and SMBUS compatible interface. > > Signed-off-by: Andrew F. Davis Hi Andrew, My immediate thought on this one is whether it would be better off in hwmon. I'm not convinced either way from a quick glance at the data sheet, but the question needs to be addressed. It's not exactly a clean fit for the IIO ABI either at the moment though I think some elements of that could be easily sorted out. The key think in my mind is to look at what is actually being measured rather than assume all the external components will be as the datasheet assumes them to be... + where do the alert lines actually go? Jonathan > --- > .../ABI/testing/sysfs-bus-iio-adc-ina3221 | 23 ++ > drivers/iio/adc/Kconfig| 7 + > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/ina3221.c | 417 > + > 4 files changed, 448 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 > create mode 100644 drivers/iio/adc/ina3221.c > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 > b/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 > new file mode 100644 > index 000..bbe4f8c > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 > @@ -0,0 +1,23 @@ > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_shunt_(raw|scale) > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_bus_(raw|scale) > +Date:April 2016 > +KernelVersion: 4.7 > +Contact: Andrew F. Davis > +Description: > + Shunt and Bus voltage for each channel. Units etc need specifying or at least a reference to the main in_voltageY_raw docs etc. These are really completely separate measurements be it differential measurements where the + on one is the - on the other (second is really a unipolar measurement as it's relative to 0). I wonder if we are better off supporting them as such so define this device as having the channels. in_voltage1-voltage0_raw (shunt voltage 1) in_voltage0_raw (bus voltage 1) in_voltage3-voltage2_raw (shunt voltage 2) in_voltage2_raw (bus voltage 2) in_voltage5-voltage4_raw (shunt voltage 3) in_voltage4_raw That I think reflects the actual measuring options, without applying assumptions on what is connected to them. Yes the datasheet says you should put a shunt between the first two connections and the load between the second connection and the 0 volt line, but I can't see anything preventing this being used differently... > + > +What: > /sys/bus/iio/devices/iio:deviceX/shunt_integration_time[_available] > +What: > /sys/bus/iio/devices/iio:deviceX/bus_integration_time[_available] > +Date:April 2016 > +KernelVersion: 4.7 > +Contact: Andrew F. Davis > +Description: > + Shunt and Bus integration time for each channel. I'd keep these tightly associated with the channels as then they become standard abi elements, just for channels with extended names. > + > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_shunt_critical_(raw|scale) > +What: > /sys/bus/iio/devices/iio:deviceX/in_voltageY_shunt_warning_(raw|scale) > +Date:April 2016 > +KernelVersion: 4.7 > +Contact: Andrew F. Davis > +Description: > + Shunt voltage critical and warning trigger levels. This is why I think this may really belong in hwmon. The way you currently have this done is a bodge on the relevant IIO interfaces. If there is good reason to look at multiple equivalent event types on a given channel in IIO we can look at adding that support to the core. This is a lot more common in explicit hardware monitoring chips than in more general ADCs. Also I see nothing in the driver that is actually detecting if these conditions have been passed? If that is assumed to be a problem for external hardware then it should be clearly documented as such. > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index af4aea7..d713c9c 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -232,6 +232,13 @@ config IMX7D_ADC > This driver can also be built as a module. If so, the module will be > called imx7d_adc. > > +config INA3221 > + tristate "Texas Instruments INA3221 Triple Power Monitor" > + depends on I2C > + select REGMAP_I2C > + help > + Say yes here to build support for TI INA3221 Triple Power Monitor. Need more detail here really. Something about what it provides and the name of the module would be conventional. > + > config LP8788_ADC > tristate "LP8788 ADC driver" > depends on MFD_LP8788 > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > index 0cb7921..eebe0c6 1
Re: sched: tweak select_idle_sibling to look for idle threads
On Sun, Apr 10, 2016 at 12:04:21PM +0200, Mike Galbraith wrote: > On Sat, 2016-04-09 at 15:05 -0400, Chris Mason wrote: > > > This does preserve the existing logic to prefer idle cores over idle > > CPU threads, and includes some tests to try and avoid the idle scan when > > we're > > actually better off sharing a non-idle CPU with someone else. > > My box says the "oh nevermind" checks aren't selective enough, tbench > dropped 4% at clients=cores, and 2% at clients=threads. I knew this part would need more experimentation, so I kept v1 as simple as possible. On my box, tbench clients=cores is 5% faster, clients=threads is 4% faster. bounce_to_target() is a small version of task_hot(), I did get more accurate decisions by using the full task_hot(), so I can try that again. I'm testing on one of these: Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz, which has two sockets and 10 cores per socket. What are you testing with? If it's two sockets or less I may be able to find one to reproduce with. > > > Benchmarks in production show overall capacity going up between 2-5% > > depending on the metric. > > Latency rules all loads certainly exist, and clearly want some love, > but the bigger the socket, and the more threads/core, the more that > traverse is gonna hurt the others, so seems either we need a better > filter, or a (yeah yeah, yet another damn) tweakable. > > Oh, and bounce_to_target() seems an odd way to say full_traverse. Sure, I can rename it. -chris
Re: [PATCH v2] iio: max5487: Add support for Maxim digital potentiometers
Hi Cristina,
On 9 April 2016 at 10:24, Cristina Moraru wrote:
> Add implementation for Maxim MAX5487, MAX5488, MAX5489
> digital potentiometers.
>
> Datasheet:
> http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf
>
> Signed-off-by: Cristina Moraru
> CC: Daniel Baluta
> ---
...
> +static int max5487_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct max5487_data *data = iio_priv(indio_dev);
> +
> + if (mask != IIO_CHAN_INFO_SCALE)
> + return -EINVAL;
> +
> + *val = 1000 * data->kohms;
> + *val2 = MAX5487_MAX_POS;
Newline before return.
> + return IIO_VAL_FRACTIONAL;
> +}
> +
> +static int max5487_write_raw(struct iio_dev *indio_dev,
> +struct iio_chan_spec const *chan,
> +int val, int val2, long mask)
> +{
> + struct max5487_data *data = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (val < 0 || val > MAX5487_MAX_POS)
> + return -EINVAL;
> + return regmap_write(data->regmap, chan->address, val);
> + default:
> + return -EINVAL;
> + }
> + return -EINVAL;
To be consistent with your max5487_read_raw() function you could do a:
if (mask != IIO_CHAN_INFO_RAW)
return -EINVAL;
> +static const struct iio_info max5487_info = {
> + .read_raw = &max5487_read_raw,
> + .write_raw = &max5487_write_raw,
Address operator should be unnecessary on functions.
> + data->regmap = devm_regmap_init_spi(spi, &max5487_regmap_config);
> + if (IS_ERR(data->regmap))
> + return PTR_ERR(data->regmap);
Nothing wrong with using regmap here, but since you are only using
simple regmap_write()'s you might as well have used spi_write()
directly. I am not telling you to switch, but I don't see the point of
using regmap here.
Which reminds me; for regmap you need to select REGMAP_SPI in your
Kconfig entry.
regards,
Joachim Eastwood
Re: sched: tweak select_idle_sibling to look for idle threads
On Sun, 2016-04-10 at 08:35 -0400, Chris Mason wrote: > What are you testing with? If it's two sockets or less I may be able to > find one to reproduce with. i4790 desktop box. -Mike
Re: [PATCH v2] iio: max5487: Add support for Maxim digital potentiometers
On 10 April 2016 at 14:47, Joachim Eastwood wrote:
> Hi Cristina,
>
> On 9 April 2016 at 10:24, Cristina Moraru wrote:
>> Add implementation for Maxim MAX5487, MAX5488, MAX5489
>> digital potentiometers.
>>
>> Datasheet:
>> http://datasheets.maximintegrated.com/en/ds/MAX5487-MAX5489.pdf
>>
>> Signed-off-by: Cristina Moraru
>> CC: Daniel Baluta
>> ---
> ...
>> +static int max5487_read_raw(struct iio_dev *indio_dev,
>> + struct iio_chan_spec const *chan,
>> + int *val, int *val2, long mask)
>> +{
>> + struct max5487_data *data = iio_priv(indio_dev);
>> +
>> + if (mask != IIO_CHAN_INFO_SCALE)
>> + return -EINVAL;
>> +
>> + *val = 1000 * data->kohms;
>> + *val2 = MAX5487_MAX_POS;
>
> Newline before return.
>
>> + return IIO_VAL_FRACTIONAL;
>> +}
>> +
>> +static int max5487_write_raw(struct iio_dev *indio_dev,
>> +struct iio_chan_spec const *chan,
>> +int val, int val2, long mask)
>> +{
>> + struct max5487_data *data = iio_priv(indio_dev);
>> +
>> + switch (mask) {
>> + case IIO_CHAN_INFO_RAW:
>> + if (val < 0 || val > MAX5487_MAX_POS)
>> + return -EINVAL;
>> + return regmap_write(data->regmap, chan->address, val);
>> + default:
>> + return -EINVAL;
>> + }
>> + return -EINVAL;
>
> To be consistent with your max5487_read_raw() function you could do a:
>if (mask != IIO_CHAN_INFO_RAW)
>return -EINVAL;
>
>
>> +static const struct iio_info max5487_info = {
>> + .read_raw = &max5487_read_raw,
>> + .write_raw = &max5487_write_raw,
>
> Address operator should be unnecessary on functions.
>
>
>> + data->regmap = devm_regmap_init_spi(spi, &max5487_regmap_config);
>> + if (IS_ERR(data->regmap))
>> + return PTR_ERR(data->regmap);
>
> Nothing wrong with using regmap here, but since you are only using
> simple regmap_write()'s you might as well have used spi_write()
> directly. I am not telling you to switch, but I don't see the point of
> using regmap here.
Looking again: it seem that spi.h doesn't have a function that do
write(cmd, data) which regmap does. So I guess that is one reason for
using regmap. But it wouldn't be hard to create a write(cmd,
data)-function for spi either. Just wrap spi_write() and have a local
buf var. I am a bit surprised that spi.h doesn't have such a function
as it should be quite a common pattern for spi chips.
>
> Which reminds me; for regmap you need to select REGMAP_SPI in your
> Kconfig entry.
>
>
> regards,
> Joachim Eastwood
Re: [PATCH 1/5] max44000: Initial commit
On 07/04/16 20:48, Peter Meerwald-Stadler wrote:
>
>> This just adds support for reporting illuminance with default settings.
>>
>> All default registers are written on probe because the device otherwise
>> lacks a reset function.
>
> comments below
Mostly fine, but a few corners need cleaning up.
Also, I'm not keep on the brute force write everything. The driver should
cope with any values in those registers and deal with refreshing the
cache etc so that it can do so. Writing a bunch of defaults is rather a
brittle approach.
Jonathan
>
>> Signed-off-by: Crestez Dan Leonard
>> ---
>> drivers/iio/light/Kconfig| 11 ++
>> drivers/iio/light/Makefile | 1 +
>> drivers/iio/light/max44000.c | 295
>> +++
>> 3 files changed, 307 insertions(+)
>> create mode 100644 drivers/iio/light/max44000.c
>>
>> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
>> index cfd3df8..42c15c1 100644
>> --- a/drivers/iio/light/Kconfig
>> +++ b/drivers/iio/light/Kconfig
>> @@ -320,4 +320,15 @@ config VCNL4000
>> To compile this driver as a module, choose M here: the
>> module will be called vcnl4000.
>>
>> +config MAX44000
>> +tristate "MAX44000 Ambient and Infrared Proximity Sensor"
>> +depends on I2C
>> +select REGMAP_I2C
>> +help
>> + Say Y here if you want to build support for Maxim Integrated's
>> + MAX44000 ambient and infrared proximity sensor device.
>> +
>> + To compile this driver as a module, choose M here:
>> + the module will be called max44000.
>> +
>> endmenu
>> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
>> index b2c3105..14b2f36 100644
>> --- a/drivers/iio/light/Makefile
>> +++ b/drivers/iio/light/Makefile
>> @@ -30,3 +30,4 @@ obj-$(CONFIG_TCS3472) += tcs3472.o
>> obj-$(CONFIG_TSL4531) += tsl4531.o
>> obj-$(CONFIG_US5182D) += us5182d.o
>> obj-$(CONFIG_VCNL4000) += vcnl4000.o
>> +obj-$(CONFIG_MAX44000) += max44000.o
>
> alphabetical order please
>
>> diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c
>> new file mode 100644
>> index 000..7c12153
>> --- /dev/null
>> +++ b/drivers/iio/light/max44000.c
>> @@ -0,0 +1,295 @@
>> +/*
>> + * MAX44000 Ambient and Infrared Proximity Sensor
>> + *
>> + * Copyright (c) 2016, Intel Corporation.
>> + *
>> + * This file is subject to the terms and conditions of version 2 of
>> + * the GNU General Public License. See the file COPYING in the main
>> + * directory of this archive for more details.
>> + *
>> + * Data sheet: https://datasheets.maximintegrated.com/en/ds/MAX44000.pdf
>> + *
>> + * 7-bit I2C slave address 0x4a
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define MAX44000_DRV_NAME "max44000"
>> +
>> +/* Registers in datasheet order */
>> +#define MAX44000_REG_STATUS 0x00
>> +#define MAX44000_REG_CFG_MAIN 0x01
>> +#define MAX44000_REG_CFG_RX 0x02
>> +#define MAX44000_REG_CFG_TX 0x03
>> +#define MAX44000_REG_ALS_DATA_HI0x04
>> +#define MAX44000_REG_ALS_DATA_LO0x05
>> +#define MAX44000_REG_PRX_DATA 0x16
>> +#define MAX44000_REG_ALS_UPTHR_HI 0x06
>> +#define MAX44000_REG_ALS_UPTHR_LO 0x07
>> +#define MAX44000_REG_ALS_LOTHR_HI 0x08
>> +#define MAX44000_REG_ALS_LOTHR_LO 0x09
>> +#define MAX44000_REG_PST0x0a
>> +#define MAX44000_REG_PRX_IND0x0b
>> +#define MAX44000_REG_PRX_THR0x0c
>> +#define MAX44000_REG_TRIM_GAIN_GREEN0x0f
>> +#define MAX44000_REG_TRIM_GAIN_IR 0x10
>> +
>> +#define MAX44000_ALSDATA_OVERFLOW 0x4000
>> +
>> +#define MAX44000_REGMASK_READABLE 0x419fff
>> +#define MAX44000_REGMASK_WRITEABLE 0x019fce
>> +#define MAX44000_REGMASK_VOLATILE 0x400031
These are horrible! Do it as a switch over the relevant
registers in the functions below... Much easier to read / debug.
>> +
>> +struct max44000_data {
>> +struct mutex lock;
>> +struct i2c_client *client;
This client pointer isn't used outside probe and remove where it is easily
available anyway. Hence don't keep a copy in here.
>> +struct regmap *regmap;
>> +};
>> +
>> +/* Default scale is set to the minimum of 0.03125 or 1 / (1 << 5) lux */
>> +#define MAX44000_ALS_TO_LUX_DEFAULT_FRACTION_LOG2 5
>> +
>> +static const struct iio_chan_spec max44000_channels[] = {
>> +{
>> +.type = IIO_LIGHT,
>> +.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
>> +.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
>> +},
>> +};
>> +
>> +static inline int max44000_read_alsval(struct max44000_data *data)
>
> drop inline, let the compiler figure out if inlining is beneficial
>
>> +{
>> +u16 regval;
>> +int ret;
>> +
>> +regval = 0;
>
> needed?
>
>> +ret = regmap_bulk_read(data->regmap, MAX44000_REG_
[PATCH 02/17] staging: lustre: clio: incorrect assertions in 'enable-invariants'
From: Niu Yawei
Fixed several incorrect assumptions in 'enable-invariants'.
Signed-off-by: Niu Yawei
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3521
Reviewed-on: http://review.whamcloud.com/6832
Reviewed-by: Bobi Jam
Reviewed-by: Jinshan Xiong
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/obdclass/cl_page.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/cl_page.c
b/drivers/staging/lustre/lustre/obdclass/cl_page.c
index 8df39ce..03aab85 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_page.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_page.c
@@ -498,7 +498,7 @@ void cl_page_disown0(const struct lu_env *env,
state = pg->cp_state;
PINVRNT(env, pg, state == CPS_OWNED || state == CPS_FREEING);
- PINVRNT(env, pg, cl_page_invariant(pg));
+ PINVRNT(env, pg, cl_page_invariant(pg) || state == CPS_FREEING);
cl_page_owner_clear(pg);
if (state == CPS_OWNED)
@@ -670,7 +670,8 @@ EXPORT_SYMBOL(cl_page_unassume);
void cl_page_disown(const struct lu_env *env,
struct cl_io *io, struct cl_page *pg)
{
- PINVRNT(env, pg, cl_page_is_owned(pg, io));
+ PINVRNT(env, pg, cl_page_is_owned(pg, io) ||
+ pg->cp_state == CPS_FREEING);
io = cl_io_top(io);
cl_page_disown0(env, io, pg);
--
1.7.1
[PATCH 09/17] staging: lustre: ptlrpc: return a meaningful status from ptlrpcd_init()
From: Swapnil Pimpale
This patch has the following:
1) Fix for the return value from ptlrpcd_init(). It will now return a
correct status instead of returning zero always.
2) ptlrpcd_addref() should not increment ptlrpcd_users on error.
3) Added code in a mdc_setup() and mgc_setup() to test the return
value of ptlrpcd_addref() and return on error.
Signed-off-by: Swapnil Pimpale
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3808
Reviewed-on: http://review.whamcloud.com/7522
Reviewed-by: John L. Hammond
Reviewed-by: Andreas Dilger
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/mdc/mdc_request.c |9 ++---
drivers/staging/lustre/lustre/mgc/mgc_request.c |5 -
drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c |5 -
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c
b/drivers/staging/lustre/lustre/mdc/mdc_request.c
index a089237..97f8669 100644
--- a/drivers/staging/lustre/lustre/mdc/mdc_request.c
+++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c
@@ -2314,12 +2314,14 @@ static int mdc_setup(struct obd_device *obd, struct
lustre_cfg *cfg)
return -ENOMEM;
mdc_init_rpc_lock(cli->cl_rpc_lock);
- ptlrpcd_addref();
+ rc = ptlrpcd_addref();
+ if (rc < 0)
+ goto err_rpc_lock;
cli->cl_close_lock = kzalloc(sizeof(*cli->cl_close_lock), GFP_NOFS);
if (!cli->cl_close_lock) {
rc = -ENOMEM;
- goto err_rpc_lock;
+ goto err_ptlrpcd_decref;
}
mdc_init_rpc_lock(cli->cl_close_lock);
@@ -2345,9 +2347,10 @@ static int mdc_setup(struct obd_device *obd, struct
lustre_cfg *cfg)
err_close_lock:
kfree(cli->cl_close_lock);
+err_ptlrpcd_decref:
+ ptlrpcd_decref();
err_rpc_lock:
kfree(cli->cl_rpc_lock);
- ptlrpcd_decref();
return rc;
}
diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index b7dc872..3f5f884 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -734,7 +734,9 @@ static int mgc_setup(struct obd_device *obd, struct
lustre_cfg *lcfg)
struct task_struct *task;
int rc;
- ptlrpcd_addref();
+ rc = ptlrpcd_addref();
+ if (rc < 0)
+ goto err_noref;
rc = client_obd_setup(obd, lcfg);
if (rc)
@@ -773,6 +775,7 @@ err_cleanup:
client_obd_cleanup(obd);
err_decref:
ptlrpcd_decref();
+err_noref:
return rc;
}
diff --git a/drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c
b/drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c
index dbc3376..76a355a 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c
@@ -909,8 +909,11 @@ int ptlrpcd_addref(void)
int rc = 0;
mutex_lock(&ptlrpcd_mutex);
- if (++ptlrpcd_users == 1)
+ if (++ptlrpcd_users == 1) {
rc = ptlrpcd_init();
+ if (rc < 0)
+ ptlrpcd_users--;
+ }
mutex_unlock(&ptlrpcd_mutex);
return rc;
}
--
1.7.1
[PATCH 03/17] staging: lustre: ldlm: Fix a race during FLock handling
From: Bruno Faccini
Protect against race where lock could have been just destroyed
due to overlap, in ldlm_process_flock_lock().
Easy reproducer is BULL's NFS Locktests in pthread mode.
(http://nfsv4.bullopensource.org/tools/tests/locktest.php)
Signed-off-by: Bruno Faccini
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1126
Reviewed-on: http://review.whamcloud.com/7134
Reviewed-by: Oleg Drokin
Reviewed-by: John L. Hammond
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/ldlm/ldlm_flock.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
index 3f97e1c..5102d78 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c
@@ -520,11 +520,6 @@ ldlm_flock_completion_ast(struct ldlm_lock *lock, __u64
flags, void *data)
granted:
OBD_FAIL_TIMEOUT(OBD_FAIL_LDLM_CP_CB_WAIT, 10);
- if (lock->l_flags & LDLM_FL_DESTROYED) {
- LDLM_DEBUG(lock, "client-side enqueue waking up: destroyed");
- return 0;
- }
-
if (lock->l_flags & LDLM_FL_FAILED) {
LDLM_DEBUG(lock, "client-side enqueue waking up: failed");
return -EIO;
@@ -534,6 +529,16 @@ granted:
lock_res_and_lock(lock);
+ /*
+* Protect against race where lock could have been just destroyed
+* due to overlap in ldlm_process_flock_lock().
+*/
+ if (lock->l_flags & LDLM_FL_DESTROYED) {
+ unlock_res_and_lock(lock);
+ LDLM_DEBUG(lock, "client-side enqueue waking up: destroyed");
+ return 0;
+ }
+
/* ldlm_lock_enqueue() has already placed lock on the granted list. */
list_del_init(&lock->l_res_link);
--
1.7.1
[PATCH 11/17] staging: lustre: osc: osc_extent_wait() shouldn't be interruptible
From: Jinshan Xiong Otherwise it will hit the assertion at cl_lock.c: cl_lock.c:1967:discard_cb()) ASSERTION( (!(page->cp_type == CPT_CACHEABLE) || (!PageWriteback(cl_page_vmpage(env, page ) failed: This is because in osc_lock_flush() we have to make sure the IO is finished before discarding the pages. Signed-off-by: Jinshan Xiong Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2779 Reviewed-on: http://review.whamcloud.com/5419 Reviewed-by: Bobi Jam Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- drivers/staging/lustre/lustre/osc/osc_cache.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c b/drivers/staging/lustre/lustre/osc/osc_cache.c index 846be76..a341160 100644 --- a/drivers/staging/lustre/lustre/osc/osc_cache.c +++ b/drivers/staging/lustre/lustre/osc/osc_cache.c @@ -965,7 +965,7 @@ static int osc_extent_wait(const struct lu_env *env, struct osc_extent *ext, "%s: wait ext to %d timedout, recovery in progress?\n", osc_export(obj)->exp_obd->obd_name, state); - lwi = LWI_INTR(LWI_ON_SIGNAL_NOOP, NULL); + lwi = LWI_INTR(NULL, NULL); rc = l_wait_event(ext->oe_waitq, extent_wait_cb(ext, state), &lwi); } -- 1.7.1
[PATCH 14/17] staging: lustre: lov: return minimal FIEMAP for released files
From: Bruno Faccini
Since st_blocks = NULL is returned for released files, FIEMAP
should at least return a minimal mapping to make users aware
that file contains data but it is not immediately available.
This will make coreutils and tools such tar happy and have
them presume file is sparse.
Also, add a new test_228 in sanity-hsm to verify it works
for "[cp,tar] --sparse" commands.
Also fix a LBUG ("lov_fiemap()) ASSERTION( fm_local ) failed")
likely to occur when no-object/ENOMEM conditions and also now
when released.
Signed-off-by: Bruno Faccini
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3864
Reviewed-on: http://review.whamcloud.com/7584
Reviewed-by: Andreas Dilger
Reviewed-by: Aurelien Degremont
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/lov/lov_obd.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lov/lov_obd.c
b/drivers/staging/lustre/lustre/lov/lov_obd.c
index 1a9e3e8..9b72671 100644
--- a/drivers/staging/lustre/lustre/lov/lov_obd.c
+++ b/drivers/staging/lustre/lustre/lov/lov_obd.c
@@ -1733,6 +1733,27 @@ static int lov_fiemap(struct lov_obd *lov, __u32 keylen,
void *key,
unsigned int buffer_size = FIEMAP_BUFFER_SIZE;
if (!lsm_has_objects(lsm)) {
+ if (lsm && lsm_is_released(lsm) && (fm_key->fiemap.fm_start <
+ fm_key->oa.o_size)) {
+ /*
+* released file, return a minimal FIEMAP if
+* request fits in file-size.
+*/
+ fiemap->fm_mapped_extents = 1;
+ fiemap->fm_extents[0].fe_logical =
+ fm_key->fiemap.fm_start;
+ if (fm_key->fiemap.fm_start + fm_key->fiemap.fm_length <
+ fm_key->oa.o_size) {
+ fiemap->fm_extents[0].fe_length =
+ fm_key->fiemap.fm_length;
+ } else {
+ fiemap->fm_extents[0].fe_length =
+ fm_key->oa.o_size -
fm_key->fiemap.fm_start;
+ fiemap->fm_extents[0].fe_flags |=
+ (FIEMAP_EXTENT_UNKNOWN |
+FIEMAP_EXTENT_LAST);
+ }
+ }
rc = 0;
goto out;
}
--
1.7.1
[PATCH 00/17] staging : lustre : rest of missing patches from 2.5.0 release
This is the last collection of missing fixes present in the Lustre 2.5.0 release. Once these are merged the upstream client will be equal to the pre-2.6 lustre version since the major of clio cleanups from that time frame have already landed. Andrew Perepechko (3): staging: lustre: llite: variable rename in namei.c staging: lustre: llite: speedup in unlink/rmdir staging: lustre: lprocfs: implement log2 using bitops Andriy Skulysh (1): staging: lustre: lov: Don't wait for active target with OBD_STATFS_NODELAY Bobi Jam (1): staging: lustre: obd: MDT mount fails on MDS w/o MGS on it Bruno Faccini (3): staging: lustre: ldlm: Fix a race during FLock handling staging: lustre: ldlm: refine LU-2665 patch for POSIX compliance staging: lustre: lov: return minimal FIEMAP for released files Jeff Mahoney (1): staging: lustre: lloop: Fix build failure on ppc64 Jinshan Xiong (3): staging: lustre: llite: error setting max_cache_mb at mount time staging: lustre: llite: Truncate to restore file staging: lustre: osc: osc_extent_wait() shouldn't be interruptible John L. Hammond (2): staging: lustre: hsm: permission checks for HSM ioctl operations staging: lustre: hsm: don't use real suppgid Niu Yawei (1): staging: lustre: clio: incorrect assertions in 'enable-invariants' Sebastien Buisson (1): staging: lustre: osc: fix race issues thanks to oap_lock Swapnil Pimpale (1): staging: lustre: ptlrpc: return a meaningful status from ptlrpcd_init() drivers/staging/lustre/lustre/ldlm/ldlm_flock.c| 15 +++-- drivers/staging/lustre/lustre/llite/dir.c |3 + drivers/staging/lustre/lustre/llite/file.c |5 +- .../staging/lustre/lustre/llite/llite_internal.h |2 +- drivers/staging/lustre/lustre/llite/llite_lib.c| 60 +-- drivers/staging/lustre/lustre/llite/lloop.c|3 - drivers/staging/lustre/lustre/llite/lproc_llite.c |4 +- drivers/staging/lustre/lustre/llite/namei.c| 65 ++-- drivers/staging/lustre/lustre/llite/vvp_io.c |5 +- drivers/staging/lustre/lustre/lov/lov_obd.c| 21 ++ drivers/staging/lustre/lustre/lov/lov_request.c|7 ++- drivers/staging/lustre/lustre/mdc/mdc_locks.c |4 +- drivers/staging/lustre/lustre/mdc/mdc_request.c| 17 +++-- drivers/staging/lustre/lustre/mgc/mgc_request.c|5 +- drivers/staging/lustre/lustre/obdclass/cl_page.c |5 +- .../lustre/lustre/obdclass/lprocfs_status.c|6 +- drivers/staging/lustre/lustre/obdclass/obd_mount.c | 13 +++-- drivers/staging/lustre/lustre/osc/osc_cache.c | 10 +++- drivers/staging/lustre/lustre/osc/osc_io.c |2 + drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c |5 +- 20 files changed, 155 insertions(+), 102 deletions(-)
[PATCH 17/17] staging: lustre: hsm: don't use real suppgid
From: John L. Hammond In the MDC HSM handlers that do not pack a real suppgid, use -1 rather than 0 for the suppgid in mdt_body. Signed-off-by: John L. Hammond Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3866 Reviewed-on: http://review.whamcloud.com/7565 Reviewed-by: Aurelien Degremont Reviewed-by: Faccini Bruno Reviewed-by: Jinshan Xiong Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- drivers/staging/lustre/lustre/mdc/mdc_request.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/lustre/lustre/mdc/mdc_request.c b/drivers/staging/lustre/lustre/mdc/mdc_request.c index 97f8669..513290f 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_request.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_request.c @@ -1169,7 +1169,7 @@ static int mdc_ioc_hsm_progress(struct obd_export *exp, goto out; } - mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); + mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, -1, 0); /* Copy hsm_progress struct */ req_hpk = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_PROGRESS); @@ -1203,7 +1203,7 @@ static int mdc_ioc_hsm_ct_register(struct obd_import *imp, __u32 archives) goto out; } - mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); + mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, -1, 0); /* Copy hsm_progress struct */ archive_mask = req_capsule_client_get(&req->rq_pill, @@ -1278,7 +1278,7 @@ static int mdc_ioc_hsm_ct_unregister(struct obd_import *imp) goto out; } - mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); + mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, -1, 0); ptlrpc_request_set_replen(req); @@ -1395,7 +1395,7 @@ static int mdc_ioc_hsm_request(struct obd_export *exp, return rc; } - mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, 0, 0); + mdc_pack_body(req, NULL, OBD_MD_FLRMTPERM, 0, -1, 0); /* Copy hsm_request struct */ req_hr = req_capsule_client_get(&req->rq_pill, &RMF_MDS_HSM_REQUEST); -- 1.7.1
[PATCH 15/17] staging: lustre: lov: Don't wait for active target with OBD_STATFS_NODELAY
From: Andriy Skulysh
Patch for LU-631 which was landed before the upstream merge broke
OBD_STATFS_NODELAY behaviour. It adds unnecessary delay while
running df command with inactive OSTs. We shouldn't try to recover
connection to OST in this case.
Signed-off-by: Andriy Skulysh
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4010
Reviewed-on: http://review.whamcloud.com/7762
Reviewed-by: Andreas Dilger
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/lov/lov_request.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lov/lov_request.c
b/drivers/staging/lustre/lustre/lov/lov_request.c
index 7178a02..475ca2f 100644
--- a/drivers/staging/lustre/lustre/lov/lov_request.c
+++ b/drivers/staging/lustre/lustre/lov/lov_request.c
@@ -716,12 +716,15 @@ int lov_prep_statfs_set(struct obd_device *obd, struct
obd_info *oinfo,
struct lov_request *req;
if (!lov->lov_tgts[i] ||
- (!lov_check_and_wait_active(lov, i) &&
-(oinfo->oi_flags & OBD_STATFS_NODELAY))) {
+ (oinfo->oi_flags & OBD_STATFS_NODELAY &&
+!lov->lov_tgts[i]->ltd_active)) {
CDEBUG(D_HA, "lov idx %d inactive\n", i);
continue;
}
+ if (!lov->lov_tgts[i]->ltd_active)
+ lov_check_and_wait_active(lov, i);
+
/* skip targets that have been explicitly disabled by the
* administrator
*/
--
1.7.1
[PATCH 12/17] staging: lustre: lprocfs: implement log2 using bitops
From: Andrew Perepechko
This patch implements log2 using fls.
Signed-off-by: Andrew Perepechko
Reviewed-by: Alexander Boyko
Reviewed-by: alexander_zarochent...@xyratex.com
Reviewed-by: Vitaly Fertman
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3496
Xyratex-bug-id: MRP-999
Reviewed-on: http://review.whamcloud.com/6757
Reviewed-by: John L. Hammond
Reviewed-by: Bob Glossman
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
.../lustre/lustre/obdclass/lprocfs_status.c|6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
index d93f42f..172fc91 100644
--- a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
+++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
@@ -1471,10 +1471,10 @@ EXPORT_SYMBOL(lprocfs_oh_tally);
void lprocfs_oh_tally_log2(struct obd_histogram *oh, unsigned int value)
{
- unsigned int val;
+ unsigned int val = 0;
- for (val = 0; ((1 << val) < value) && (val <= OBD_HIST_MAX); val++)
- ;
+ if (likely(value != 0))
+ val = min(fls(value - 1), OBD_HIST_MAX);
lprocfs_oh_tally(oh, val);
}
--
1.7.1
[PATCH 16/17] staging: lustre: hsm: permission checks for HSM ioctl operations
From: John L. Hammond In the LL_IOC_HSM_CT_START case of ll_dir_ioctl() require CAP_SYS_ADMIN, since the local handler for this ioctl may modify the global KUC table. Signed-off-by: John L. Hammond Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3866 Reviewed-on: http://review.whamcloud.com/7565 Reviewed-by: Aurelien Degremont Reviewed-by: Faccini Bruno Reviewed-by: Jinshan Xiong Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- drivers/staging/lustre/lustre/llite/dir.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/dir.c b/drivers/staging/lustre/lustre/llite/dir.c index 45bdf8f..94f3800 100644 --- a/drivers/staging/lustre/lustre/llite/dir.c +++ b/drivers/staging/lustre/lustre/llite/dir.c @@ -1844,6 +1844,9 @@ out_quotactl: return rc; } case LL_IOC_HSM_CT_START: + if (!capable(CFS_CAP_SYS_ADMIN)) + return -EPERM; + rc = copy_and_ioctl(cmd, sbi->ll_md_exp, (void __user *)arg, sizeof(struct lustre_kernelcomm)); return rc; -- 1.7.1
[PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64
From: Jeff Mahoney On ppc64 with 64k pages, we get a build failure in lloop: drivers/staging/lustre/lustre/llite/lloop.c:527:2: note: in expansion of macro 'CLASSERT' CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); There's no need to change the queue's logical block size. Even if it could accept a 64k value, that would result in any file system on top of it needing to also use 64k blocks. It'd be safe to set it to 4k, but there's no actual need for it. It's not used to split requests except for WRITE_SAME, which lloop doesn't implement anyway. Signed-off-by: Jeff Mahoney Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000 Reviewed-on: http://review.whamcloud.com/7745 Reviewed-by: Jinshan Xiong Reviewed-by: Minh Diep Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- drivers/staging/lustre/lustre/llite/lloop.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/staging/lustre/lustre/llite/lloop.c b/drivers/staging/lustre/lustre/llite/lloop.c index b725fc1..f396753 100644 --- a/drivers/staging/lustre/lustre/llite/lloop.c +++ b/drivers/staging/lustre/lustre/llite/lloop.c @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct file *unused, lo->lo_queue->queuedata = lo; /* queue parameters */ - CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); - blk_queue_logical_block_size(lo->lo_queue, -(unsigned short)PAGE_CACHE_SIZE); blk_queue_max_hw_sectors(lo->lo_queue, LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9)); blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS); -- 1.7.1
Re: [PATCH 2/5] max44000: Initial support for proximity reading
On 07/04/16 17:21, Crestez Dan Leonard wrote:
> The proximity sensor relies on sending pulses to an external IR led and
> it is disabled by default on powerup. The driver will enable it with a
> default power setting.
>
> Signed-off-by: Crestez Dan Leonard
One trivial point inline...
> ---
> drivers/iio/light/max44000.c | 61
>
> 1 file changed, 61 insertions(+)
>
> diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c
> index 7c12153..10a0fe8 100644
> --- a/drivers/iio/light/max44000.c
> +++ b/drivers/iio/light/max44000.c
> @@ -41,6 +41,23 @@
> #define MAX44000_REG_TRIM_GAIN_GREEN 0x0f
> #define MAX44000_REG_TRIM_GAIN_IR0x10
>
> +/* REG_CFG bits */
> +#define MAX44000_CFG_ALSINTE 0x01
> +#define MAX44000_CFG_PRXINTE 0x02
> +#define MAX44000_CFG_MASK0x1c
> +#define MAX44000_CFG_MODE_SHUTDOWN 0x00
> +#define MAX44000_CFG_MODE_ALS_GIR0x04
> +#define MAX44000_CFG_MODE_ALS_G 0x08
> +#define MAX44000_CFG_MODE_ALS_IR 0x0c
> +#define MAX44000_CFG_MODE_ALS_PRX0x10
> +#define MAX44000_CFG_MODE_PRX0x14
> +#define MAX44000_CFG_TRIM0x20
> +
> +/* REG_TX bits */
> +#define MAX44000_LED_CURRENT_MASK0xf
> +#define MAX44000_LED_CURRENT_MAX 11
> +#define MAX44000_LED_CURRENT_DEFAULT 6
> +
> #define MAX44000_ALSDATA_OVERFLOW0x4000
>
> #define MAX44000_REGMASK_READABLE0x419fff
> @@ -60,6 +77,12 @@ static const struct iio_chan_spec max44000_channels[] = {
> {
> .type = IIO_LIGHT,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_INT_TIME),
> + },
> + {
> + .type = IIO_PROXIMITY,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> },
> };
> @@ -90,11 +113,23 @@ static inline int max44000_read_alsval(struct
> max44000_data *data)
> return regval;
> }
>
> +static inline int max44000_write_led_current_raw(struct max44000_data *data,
> int val)
> +{
> + /* Maybe we should clamp the value instead? */
> + if (val < 0 || val > MAX44000_LED_CURRENT_MAX)
> + return -ERANGE;
> + if (val >= 8)
> + val += 4;
> + return regmap_write_bits(data->regmap, MAX44000_REG_CFG_TX,
> + MAX44000_LED_CURRENT_MASK, val);
> +}
> +
> static int max44000_read_raw(struct iio_dev *indio_dev,
>struct iio_chan_spec const *chan,
>int *val, int *val2, long mask)
> {
> struct max44000_data *data = iio_priv(indio_dev);
> + unsigned int regval;
> int ret;
>
> switch (mask) {
> @@ -109,6 +144,15 @@ static int max44000_read_raw(struct iio_dev *indio_dev,
> *val = ret;
> return IIO_VAL_INT;
>
> + case IIO_PROXIMITY:
> + mutex_lock(&data->lock);
> + ret = regmap_read(data->regmap, MAX44000_REG_PRX_DATA,
> ®val);
> + mutex_unlock(&data->lock);
> + if (ret < 0)
> + return ret;
> + *val = regval;
> + return IIO_VAL_INT;
> +
> default:
> return -EINVAL;
> }
> @@ -244,6 +288,23 @@ static int max44000_probe(struct i2c_client *client,
> return ret;
> }
>
> + /* By default the LED pulse used for the proximity sensor is disabled.
Please run checkpatch.pl on these. It would probably have complained about
the multiline comment syntax here.
> + * Set a middle value so that we get some sort of valid data by default.
> + */
> + ret = max44000_write_led_current_raw(data,
> MAX44000_LED_CURRENT_DEFAULT);
> + if (ret < 0) {
> + dev_err(&data->client->dev, "failed to write init config:
> %d\n", ret);
> + return ret;
> + }
> +
> + /* By default set in ALS_PRX mode which allows easy reading of both
> values. */
> + reg = MAX44000_CFG_TRIM | MAX44000_CFG_MODE_ALS_PRX;
> + ret = regmap_write(data->regmap, MAX44000_REG_CFG_MAIN, reg);
> + if (ret < 0) {
> + dev_err(&data->client->dev, "failed to write init config:
> %d\n", ret);
> + return ret;
> + }
> +
> return iio_device_register(indio_dev);
> }
>
>
[PATCH 10/17] staging: lustre: llite: Truncate to restore file
From: Jinshan Xiong
Truncate up is safe so it won't trigger restore.
Copy optimization for truncate down - only copy the part under
truncate length. If a file is truncated to zero usually it'll be
followed by write so I choose to restore the file and set correct
stripe information.
Signed-off-by: Jinshan Xiong
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3817
Reviewed-on: http://review.whamcloud.com/7505
Reviewed-by: jacques-Charles Lafoucriere
Reviewed-by: Henri Doreau
Reviewed-by: Aurelien Degremont
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/file.c |5 +-
.../staging/lustre/lustre/llite/llite_internal.h |2 +-
drivers/staging/lustre/lustre/llite/llite_lib.c| 60 +--
drivers/staging/lustre/lustre/llite/vvp_io.c |5 +-
4 files changed, 35 insertions(+), 37 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/file.c
b/drivers/staging/lustre/lustre/llite/file.c
index 9b553d2..24fa24b 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -3621,7 +3621,7 @@ again:
/**
* This function send a restore request to the MDT
*/
-int ll_layout_restore(struct inode *inode)
+int ll_layout_restore(struct inode *inode, loff_t offset, __u64 length)
{
struct hsm_user_request *hur;
int len, rc;
@@ -3637,7 +3637,8 @@ int ll_layout_restore(struct inode *inode)
hur->hur_request.hr_flags = 0;
memcpy(&hur->hur_user_item[0].hui_fid, &ll_i2info(inode)->lli_fid,
sizeof(hur->hur_user_item[0].hui_fid));
- hur->hur_user_item[0].hui_extent.length = -1;
+ hur->hur_user_item[0].hui_extent.offset = offset;
+ hur->hur_user_item[0].hui_extent.length = length;
hur->hur_request.hr_itemcount = 1;
rc = obd_iocontrol(LL_IOC_HSM_REQUEST, ll_i2sbi(inode)->ll_md_exp,
len, hur, NULL);
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index d67c8c0..bb582f1 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -1377,7 +1377,7 @@ enum {
int ll_layout_conf(struct inode *inode, const struct cl_object_conf *conf);
int ll_layout_refresh(struct inode *inode, __u32 *gen);
-int ll_layout_restore(struct inode *inode);
+int ll_layout_restore(struct inode *inode, loff_t start, __u64 length);
int ll_xattr_init(void);
void ll_xattr_fini(void);
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 9571742..49bfbbd 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -1266,14 +1266,6 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr
*attr, bool hsm_import)
LTIME_S(attr->ia_mtime), LTIME_S(attr->ia_ctime),
(s64)ktime_get_real_seconds());
- /* If we are changing file size, file content is modified, flag it. */
- if (attr->ia_valid & ATTR_SIZE) {
- attr->ia_valid |= MDS_OPEN_OWNEROVERRIDE;
- spin_lock(&lli->lli_lock);
- lli->lli_flags |= LLIF_DATA_MODIFIED;
- spin_unlock(&lli->lli_lock);
- }
-
/* We always do an MDS RPC, even if we're only changing the size;
* only the MDS knows whether truncate() should fail with -ETXTBUSY
*/
@@ -1285,13 +1277,6 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr
*attr, bool hsm_import)
if (!S_ISDIR(inode->i_mode))
inode_unlock(inode);
- memcpy(&op_data->op_attr, attr, sizeof(*attr));
-
- /* Open epoch for truncate. */
- if (exp_connect_som(ll_i2mdexp(inode)) &&
- (attr->ia_valid & (ATTR_SIZE | ATTR_MTIME | ATTR_MTIME_SET)))
- op_data->op_flags = MF_EPOCH_OPEN;
-
/* truncate on a released file must failed with -ENODATA,
* so size must not be set on MDS for released file
* but other attributes must be set
@@ -1305,29 +1290,40 @@ int ll_setattr_raw(struct dentry *dentry, struct iattr
*attr, bool hsm_import)
if (lsm && lsm->lsm_pattern & LOV_PATTERN_F_RELEASED)
file_is_released = true;
ccc_inode_lsm_put(inode, lsm);
+
+ if (!hsm_import && attr->ia_valid & ATTR_SIZE) {
+ if (file_is_released) {
+ rc = ll_layout_restore(inode, 0, attr->ia_size);
+ if (rc < 0)
+ goto out;
+
+ file_is_released = false;
+ ll_layout_refresh(inode, &gen);
+ }
+
+ /*
+* If we are changing file size, file c
[PATCH 04/17] staging: lustre: ldlm: refine LU-2665 patch for POSIX compliance
From: Bruno Faccini Follow-on to patch introduced to fix LU-2665 ticket (Gerrit Change at http://review.whamcloud.com/6415 with Change-Id: I8faa331712abeadee46eabe111ee1c23a05840d5). Original patch introduced regressions against POSIX test suite (fcntl.18/fcntl.35 tests in LSB-VSX POSIX test suite at http://www.opengroup.org/testing/linux-test/lsb-vsx.html), so the idea is to only resend F_UNLCKs to have both LU-2665 bug and POSIX test suite happy. Signed-off-by: Bruno Faccini Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3701 Reviewed-on: http://review.whamcloud.com/7453 Reviewed-by: Bobi Jam Reviewed-by: Oleg Drokin Signed-off-by: James Simmons --- drivers/staging/lustre/lustre/mdc/mdc_locks.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/staging/lustre/lustre/mdc/mdc_locks.c b/drivers/staging/lustre/lustre/mdc/mdc_locks.c index 958a164..01b6d77 100644 --- a/drivers/staging/lustre/lustre/mdc/mdc_locks.c +++ b/drivers/staging/lustre/lustre/mdc/mdc_locks.c @@ -869,7 +869,9 @@ resend: * (explicits or automatically generated by Kernel to clean * current FLocks upon exit) that can't be trashed */ - if ((rc == -EINTR) || (rc == -ETIMEDOUT)) + if (((rc == -EINTR) || (rc == -ETIMEDOUT)) && + (einfo->ei_type == LDLM_FLOCK) && + (einfo->ei_mode == LCK_NL)) goto resend; return rc; } -- 1.7.1
[PATCH 07/17] staging: lustre: llite: error setting max_cache_mb at mount time
From: Jinshan Xiong
The root cause is that when max_cache_mb conf parameter is applied,
the client isn't connected to the OST yet so that sbi->ll_dt_exp is
NULL. However, it's not necessary to shrink the cache memory in this
case so success should be returned.
Signed-off-by: Jinshan Xiong
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3676
Reviewed-on: http://review.whamcloud.com/7194
Reviewed-by: Andreas Dilger
Reviewed-by: Bobi Jam
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/lproc_llite.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/lproc_llite.c
b/drivers/staging/lustre/lustre/llite/lproc_llite.c
index 091144f..6947913 100644
--- a/drivers/staging/lustre/lustre/llite/lproc_llite.c
+++ b/drivers/staging/lustre/lustre/llite/lproc_llite.c
@@ -461,8 +461,8 @@ static ssize_t ll_max_cached_mb_seq_write(struct file *file,
break;
if (!sbi->ll_dt_exp) { /* being initialized */
- rc = -ENODEV;
- break;
+ rc = 0;
+ goto out;
}
/* difficult - have to ask OSCs to drop LRU slots. */
--
1.7.1
Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources
On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li wrote:
> Currently the optional IPC resources prevent telemetry driver from
> probing if these resources are not in ACPI table. This patch decouples
> telemetry driver from these optional resources, so that telemetry driver
> has dependency only on the necessary ACPI resources.
Darren, I have comments as well.
>
> Signed-off-by: Aubrey Li
> ---
> drivers/platform/x86/intel_pmc_ipc.c | 48
> +++-
> drivers/platform/x86/intel_punit_ipc.c | 48
> +---
> 2 files changed, 54 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/platform/x86/intel_pmc_ipc.c
> b/drivers/platform/x86/intel_pmc_ipc.c
> index 092519e..29d9c02 100644
> --- a/drivers/platform/x86/intel_pmc_ipc.c
> +++ b/drivers/platform/x86/intel_pmc_ipc.c
> @@ -686,8 +686,8 @@ static int ipc_plat_get_res(struct platform_device *pdev)
> ipcdev.acpi_io_size = size;
> dev_info(&pdev->dev, "io res: %pR\n", res);
>
> - /* This is index 0 to cover BIOS data register */
> punit_res = punit_res_array;
> + /* This is index 0 to cover BIOS data register */
> res = platform_get_resource(pdev, IORESOURCE_MEM,
> PLAT_RESOURCE_BIOS_DATA_INDEX);
> if (!res) {
> @@ -697,55 +697,51 @@ static int ipc_plat_get_res(struct platform_device
> *pdev)
> *punit_res = *res;
> dev_info(&pdev->dev, "punit BIOS data res: %pR\n", res);
>
> + /* This is index 1 to cover BIOS interface register */
> res = platform_get_resource(pdev, IORESOURCE_MEM,
> PLAT_RESOURCE_BIOS_IFACE_INDEX);
> if (!res) {
> dev_err(&pdev->dev, "Failed to get res of punit BIOS
> iface\n");
> return -ENXIO;
> }
> - /* This is index 1 to cover BIOS interface register */
> *++punit_res = *res;
> dev_info(&pdev->dev, "punit BIOS interface res: %pR\n", res);
>
> + /* This is index 2 to cover ISP data register, optional */
All above looks like a commentary fixes (except an additional
'optional' word in one case). Can you do this separately?
> res = platform_get_resource(pdev, IORESOURCE_MEM,
> PLAT_RESOURCE_ISP_DATA_INDEX);
> - if (!res) {
> - dev_err(&pdev->dev, "Failed to get res of punit ISP data\n");
> - return -ENXIO;
> + ++punit_res;
> + if (res) {
> + *punit_res = *res;
> + dev_info(&pdev->dev, "punit ISP data res: %pR\n", res);
Okay, what if you re-arrange this to some helper first
int …_assign_res(*pdev, index, *punit_res)
{
struct resource res;
res = platform_get_resource(pdev, …, index);
if (!res)
return -ERRNO;
*punit_res = *res;
dev_dbg(%pR);
return 0;
}
In this patch you move to optional by
dev_err -> dev_warn
and use
if (ret)
dev_warn( "…skip optional resource…" );
instead of
if (ret) {
dev_err();
return ret;
}
> }
> - /* This is index 2 to cover ISP data register */
> - *++punit_res = *res;
> - dev_info(&pdev->dev, "punit ISP data res: %pR\n", res);
>
> + /* This is index 3 to cover ISP interface register, optional */
> res = platform_get_resource(pdev, IORESOURCE_MEM,
> PLAT_RESOURCE_ISP_IFACE_INDEX);
> - if (!res) {
> - dev_err(&pdev->dev, "Failed to get res of punit ISP iface\n");
> - return -ENXIO;
> + ++punit_res;
> + if (res) {
> + *punit_res = *res;
> + dev_info(&pdev->dev, "punit ISP interface res: %pR\n", res);
> }
> - /* This is index 3 to cover ISP interface register */
> - *++punit_res = *res;
> - dev_info(&pdev->dev, "punit ISP interface res: %pR\n", res);
>
> + /* This is index 4 to cover GTD data register, optional */
> res = platform_get_resource(pdev, IORESOURCE_MEM,
> PLAT_RESOURCE_GTD_DATA_INDEX);
> - if (!res) {
> - dev_err(&pdev->dev, "Failed to get res of punit GTD data\n");
> - return -ENXIO;
> + ++punit_res;
> + if (res) {
> + *punit_res = *res;
> + dev_info(&pdev->dev, "punit GTD data res: %pR\n", res);
> }
> - /* This is index 4 to cover GTD data register */
> - *++punit_res = *res;
> - dev_info(&pdev->dev, "punit GTD data res: %pR\n", res);
>
> + /* This is index 5 to cover GTD interface register, optional */
> res = platform_get_resource(pdev, IORESOURCE_MEM,
> PLAT_RESOURCE_GTD_IFACE_INDEX);
> - if (!res) {
> - dev_err(&pdev->dev, "Failed to get res of punit GTD iface\n");
> - return -ENXIO;
> + ++punit_res;
> + if (res) {
> + *punit_res = *res;
> +
Re: [PATCH 3/5] max44000: Support controlling LED current output
On 07/04/16 17:21, Crestez Dan Leonard wrote:
> This is exposed as an output channel with "led" as an extend_name.
>
> Other sensors also have support for controlling an external LED. It's
> not clear that simply exposing an undecorated output channel is the
> correct approach.
Agreed that this is less than ideal. Other suggestions welcome.
It gets complicated as some devices have multiple LEDs and they aren't
necessarily directly associated with a particular sensor.
>
> Signed-off-by: Crestez Dan Leonard
> ---
> drivers/iio/light/max44000.c | 53
>
> 1 file changed, 53 insertions(+)
>
> diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c
> index 10a0fe8..1dc10b9 100644
> --- a/drivers/iio/light/max44000.c
> +++ b/drivers/iio/light/max44000.c
> @@ -85,6 +85,13 @@ static const struct iio_chan_spec max44000_channels[] = {
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> },
> + {
> + .type = IIO_CURRENT,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE),
> + .extend_name = "led",
> + .output = 1,
> + },
> };
>
> static inline int max44000_read_alsval(struct max44000_data *data)
> @@ -124,6 +131,20 @@ static inline int max44000_write_led_current_raw(struct
> max44000_data *data, int
>MAX44000_LED_CURRENT_MASK, val);
> }
>
> +static inline int max44000_read_led_current_raw(struct max44000_data *data)
> +{
> + unsigned int regval;
> + int ret;
> +
> + ret = regmap_read(data->regmap, MAX44000_REG_CFG_TX, ®val);
> + if (ret < 0)
> + return ret;
> + regval &= MAX44000_LED_CURRENT_MASK;
> + if (regval >= 8)
> + regval -= 4;
> + return regval;
> +}
> +
> static int max44000_read_raw(struct iio_dev *indio_dev,
>struct iio_chan_spec const *chan,
>int *val, int *val2, long mask)
> @@ -153,12 +174,26 @@ static int max44000_read_raw(struct iio_dev *indio_dev,
> *val = regval;
> return IIO_VAL_INT;
>
> + case IIO_CURRENT:
> + mutex_lock(&data->lock);
> + ret = max44000_read_led_current_raw(data);
> + mutex_unlock(&data->lock);
> + if (ret < 0)
> + return ret;
> + *val = ret;
> + return IIO_VAL_INT;
> +
> default:
> return -EINVAL;
> }
>
> case IIO_CHAN_INFO_SCALE:
> switch (chan->type) {
> + case IIO_CURRENT:
> + /* Output register is in 10s of miliamps */
> + *val = 10;
> + return IIO_VAL_INT;
> +
> case IIO_LIGHT:
> *val = 1;
> *val2 = MAX44000_ALS_TO_LUX_DEFAULT_FRACTION_LOG2;
> @@ -173,9 +208,27 @@ static int max44000_read_raw(struct iio_dev *indio_dev,
> }
> }
>
> +static int max44000_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct max44000_data *data = iio_priv(indio_dev);
> + int ret;
> +
> + if (mask == IIO_CHAN_INFO_RAW && chan->type == IIO_CURRENT) {
> + mutex_lock(&data->lock);
> + ret = max44000_write_led_current_raw(data, val);
> + mutex_unlock(&data->lock);
> + return ret;
> + }
> +
> + return -EINVAL;
> +}
> +
> static const struct iio_info max44000_info = {
> .driver_module = THIS_MODULE,
> .read_raw = max44000_read_raw,
> + .write_raw = max44000_write_raw,
> };
>
> static bool max44000_readable_reg(struct device *dev, unsigned int reg)
>
[PATCH 01/17] staging: lustre: osc: fix race issues thanks to oap_lock
From: Sebastien Buisson
Fix 'data race condition' defects found by Coverity version 6.5.0:
Data race condition (MISSING_LOCK)
Accessing variable without holding lock. Elsewhere,
this variable is accessed with lock held.
This patch is dedicated to code fragments involving oap_lock.
Signed-off-by: Sebastien Buisson
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2744
Reviewed-on: http://review.whamcloud.com/6572
Reviewed-by: Oleg Drokin
Reviewed-by: Andreas Dilger
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/osc/osc_cache.c |8
drivers/staging/lustre/lustre/osc/osc_io.c|2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/lustre/lustre/osc/osc_cache.c
b/drivers/staging/lustre/lustre/osc/osc_cache.c
index 956d57b..846be76 100644
--- a/drivers/staging/lustre/lustre/osc/osc_cache.c
+++ b/drivers/staging/lustre/lustre/osc/osc_cache.c
@@ -1147,7 +1147,9 @@ static int osc_extent_make_ready(const struct lu_env *env,
last->oap_count = osc_refresh_count(env, last, OBD_BRW_WRITE);
LASSERT(last->oap_count > 0);
LASSERT(last->oap_page_off + last->oap_count <=
PAGE_CACHE_SIZE);
+ spin_lock(&last->oap_lock);
last->oap_async_flags |= ASYNC_COUNT_STABLE;
+ spin_unlock(&last->oap_lock);
}
/* for the rest of pages, we don't need to call osf_refresh_count()
@@ -1156,7 +1158,9 @@ static int osc_extent_make_ready(const struct lu_env *env,
list_for_each_entry(oap, &ext->oe_pages, oap_pending_item) {
if (!(oap->oap_async_flags & ASYNC_COUNT_STABLE)) {
oap->oap_count = PAGE_CACHE_SIZE - oap->oap_page_off;
+ spin_lock(&last->oap_lock);
oap->oap_async_flags |= ASYNC_COUNT_STABLE;
+ spin_unlock(&last->oap_lock);
}
}
@@ -2350,6 +2354,10 @@ int osc_queue_async_io(const struct lu_env *env, struct
cl_io *io,
oap->oap_cmd = cmd;
oap->oap_page_off = ops->ops_from;
oap->oap_count = ops->ops_to - ops->ops_from;
+ /*
+* No need to hold a lock here,
+* since this page is not in any list yet.
+*/
oap->oap_async_flags = 0;
oap->oap_brw_flags = brw_flags;
diff --git a/drivers/staging/lustre/lustre/osc/osc_io.c
b/drivers/staging/lustre/lustre/osc/osc_io.c
index cf7743d..0f50465 100644
--- a/drivers/staging/lustre/lustre/osc/osc_io.c
+++ b/drivers/staging/lustre/lustre/osc/osc_io.c
@@ -168,8 +168,10 @@ static int osc_io_submit(const struct lu_env *env,
}
cl_page_list_move(qout, qin, page);
+ spin_lock(&oap->oap_lock);
oap->oap_async_flags = ASYNC_URGENT|ASYNC_READY;
oap->oap_async_flags |= ASYNC_COUNT_STABLE;
+ spin_unlock(&oap->oap_lock);
osc_page_submit(env, opg, crt, brw_flags);
list_add_tail(&oap->oap_pending_item, &list);
--
1.7.1
[PATCH 05/17] staging: lustre: llite: variable rename in namei.c
From: Andrew Perepechko
With the patch 6648 a fee variables were renamed. We do these
renames in broken out patch to the fix obvious.
Signed-off-by: Andrew Perepechko
Reviewed-by: Alexander Boyko
Reviewed-by: Vitaly Fertman
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3473
Xyratex-bug-id: MRP-1027
Reviewed-on: http://review.whamcloud.com/6648
Reviewed-by: Fan Yong
Reviewed-by: Andreas Dilger
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/namei.c | 52 +-
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/namei.c
b/drivers/staging/lustre/lustre/llite/namei.c
index f8f98e4..6445bc1 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -927,23 +927,23 @@ out:
* is any lock existing. They will recycle dentries and inodes based upon locks
* too. b=20433
*/
-static int ll_unlink(struct inode *dir, struct dentry *dentry)
+static int ll_unlink(struct inode *dir, struct dentry *dchild)
{
struct ptlrpc_request *request = NULL;
struct md_op_data *op_data;
int rc;
CDEBUG(D_VFSTRACE, "VFS Op:name=%pd,dir=%lu/%u(%p)\n",
- dentry, dir->i_ino, dir->i_generation, dir);
+ dchild, dir->i_ino, dir->i_generation, dir);
op_data = ll_prep_md_op_data(NULL, dir, NULL,
-dentry->d_name.name,
-dentry->d_name.len,
+dchild->d_name.name,
+dchild->d_name.len,
0, LUSTRE_OPC_ANY, NULL);
if (IS_ERR(op_data))
return PTR_ERR(op_data);
- ll_get_child_fid(dentry, &op_data->op_fid3);
+ ll_get_child_fid(dchild, &op_data->op_fid3);
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
ll_finish_md_op_data(op_data);
@@ -977,23 +977,23 @@ static int ll_mkdir(struct inode *dir, struct dentry
*dentry, umode_t mode)
return err;
}
-static int ll_rmdir(struct inode *dir, struct dentry *dentry)
+static int ll_rmdir(struct inode *dir, struct dentry *dchild)
{
struct ptlrpc_request *request = NULL;
struct md_op_data *op_data;
int rc;
CDEBUG(D_VFSTRACE, "VFS Op:name=%pd,dir=%lu/%u(%p)\n",
- dentry, dir->i_ino, dir->i_generation, dir);
+ dchild, dir->i_ino, dir->i_generation, dir);
op_data = ll_prep_md_op_data(NULL, dir, NULL,
-dentry->d_name.name,
-dentry->d_name.len,
+dchild->d_name.name,
+dchild->d_name.len,
S_IFDIR, LUSTRE_OPC_ANY, NULL);
if (IS_ERR(op_data))
return PTR_ERR(op_data);
- ll_get_child_fid(dentry, &op_data->op_fid3);
+ ll_get_child_fid(dchild, &op_data->op_fid3);
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
ll_finish_md_op_data(op_data);
@@ -1056,42 +1056,42 @@ out:
return err;
}
-static int ll_rename(struct inode *old_dir, struct dentry *old_dentry,
-struct inode *new_dir, struct dentry *new_dentry)
+static int ll_rename(struct inode *src, struct dentry *src_dchild,
+struct inode *tgt, struct dentry *tgt_dchild)
{
struct ptlrpc_request *request = NULL;
- struct ll_sb_info *sbi = ll_i2sbi(old_dir);
+ struct ll_sb_info *sbi = ll_i2sbi(src);
struct md_op_data *op_data;
int err;
CDEBUG(D_VFSTRACE,
"VFS
Op:oldname=%pd,src_dir=%lu/%u(%p),newname=%pd,tgt_dir=%lu/%u(%p)\n",
- old_dentry, old_dir->i_ino, old_dir->i_generation, old_dir,
- new_dentry, new_dir->i_ino, new_dir->i_generation, new_dir);
+ src_dchild, src->i_ino, src->i_generation, src,
+ tgt_dchild, tgt->i_ino, tgt->i_generation, tgt);
- op_data = ll_prep_md_op_data(NULL, old_dir, new_dir, NULL, 0, 0,
+ op_data = ll_prep_md_op_data(NULL, src, tgt, NULL, 0, 0,
LUSTRE_OPC_ANY, NULL);
if (IS_ERR(op_data))
return PTR_ERR(op_data);
- ll_get_child_fid(old_dentry, &op_data->op_fid3);
- ll_get_child_fid(new_dentry, &op_data->op_fid4);
+ ll_get_child_fid(src_dchild, &op_data->op_fid3);
+ ll_get_child_fid(tgt_dchild, &op_data->op_fid4);
err = md_rename(sbi->ll_md_exp, op_data,
- old_dentry->d_name.name,
- old_dentry->d_name.len,
- new_dentry->d_name.name,
- new_dentry->d_name.len, &request);
+ src_d
[PATCH 06/17] staging: lustre: llite: speedup in unlink/rmdir
From: Andrew Perepechko
Assume dchild argument is fully initialized in ->unlink and
->rmdir callbacks, so additional lookup for ELC is not needed.
Signed-off-by: Andrew Perepechko
Reviewed-by: Alexander Boyko
Reviewed-by: Vitaly Fertman
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3473
Xyratex-bug-id: MRP-1027
Reviewed-on: http://review.whamcloud.com/6648
Reviewed-by: Fan Yong
Reviewed-by: Andreas Dilger
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/llite/namei.c | 21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/namei.c
b/drivers/staging/lustre/lustre/llite/namei.c
index 6445bc1..7e4247a 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -845,12 +845,6 @@ static int ll_create_nd(struct inode *dir, struct dentry
*dentry,
return rc;
}
-static inline void ll_get_child_fid(struct dentry *child, struct lu_fid *fid)
-{
- if (d_really_is_positive(child))
- *fid = *ll_inode2fid(d_inode(child));
-}
-
int ll_objects_destroy(struct ptlrpc_request *request, struct inode *dir)
{
struct mdt_body *body;
@@ -943,7 +937,9 @@ static int ll_unlink(struct inode *dir, struct dentry
*dchild)
if (IS_ERR(op_data))
return PTR_ERR(op_data);
- ll_get_child_fid(dchild, &op_data->op_fid3);
+ if (dchild && dchild->d_inode)
+ op_data->op_fid3 = *ll_inode2fid(dchild->d_inode);
+
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
ll_finish_md_op_data(op_data);
@@ -993,7 +989,9 @@ static int ll_rmdir(struct inode *dir, struct dentry
*dchild)
if (IS_ERR(op_data))
return PTR_ERR(op_data);
- ll_get_child_fid(dchild, &op_data->op_fid3);
+ if (dchild && dchild->d_inode)
+ op_data->op_fid3 = *ll_inode2fid(dchild->d_inode);
+
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
ll_finish_md_op_data(op_data);
@@ -1074,8 +1072,11 @@ static int ll_rename(struct inode *src, struct dentry
*src_dchild,
if (IS_ERR(op_data))
return PTR_ERR(op_data);
- ll_get_child_fid(src_dchild, &op_data->op_fid3);
- ll_get_child_fid(tgt_dchild, &op_data->op_fid4);
+ if (src_dchild && src_dchild->d_inode)
+ op_data->op_fid3 = *ll_inode2fid(src_dchild->d_inode);
+ if (tgt_dchild && tgt_dchild->d_inode)
+ op_data->op_fid4 = *ll_inode2fid(tgt_dchild->d_inode);
+
err = md_rename(sbi->ll_md_exp, op_data,
src_dchild->d_name.name,
src_dchild->d_name.len,
--
1.7.1
[PATCH 08/17] staging: lustre: obd: MDT mount fails on MDS w/o MGS on it
From: Bobi Jam
If we specify multiple --mgsnode for a MDT, when we start MDS upon
it while MGS is no the other node, the MGC import connection will
always select the local nid (which is one of the candidate mgsnode)
since it think its the closest connection.
This patch treats further --mgsnode nids as failover nids, so that
multiple import connections are added for the MGC import.
Signed-off-by: Bobi Jam
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3829
Reviewed-on: http://review.whamcloud.com/7509
Reviewed-by: Liang Zhen
Reviewed-by: Lai Siyao
Reviewed-by: Oleg Drokin
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/obdclass/obd_mount.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/obd_mount.c
b/drivers/staging/lustre/lustre/obdclass/obd_mount.c
index d3e28a3..9474aa9 100644
--- a/drivers/staging/lustre/lustre/obdclass/obd_mount.c
+++ b/drivers/staging/lustre/lustre/obdclass/obd_mount.c
@@ -307,7 +307,8 @@ int lustre_start_mgc(struct super_block *sb)
while (class_parse_nid(ptr, &nid, &ptr) == 0) {
rc = do_lcfg(mgcname, nid,
LCFG_ADD_UUID, niduuid, NULL, NULL, NULL);
- i++;
+ if (!rc)
+ i++;
/* Stop at the first failover nid */
if (*ptr == ':')
break;
@@ -345,16 +346,18 @@ int lustre_start_mgc(struct super_block *sb)
sprintf(niduuid, "%s_%x", mgcname, i);
j = 0;
while (class_parse_nid_quiet(ptr, &nid, &ptr) == 0) {
- j++;
- rc = do_lcfg(mgcname, nid,
-LCFG_ADD_UUID, niduuid, NULL, NULL, NULL);
+ rc = do_lcfg(mgcname, nid, LCFG_ADD_UUID, niduuid,
+NULL, NULL, NULL);
+ if (!rc)
+ ++j;
if (*ptr == ':')
break;
}
if (j > 0) {
rc = do_lcfg(mgcname, 0, LCFG_ADD_CONN,
niduuid, NULL, NULL, NULL);
- i++;
+ if (!rc)
+ i++;
} else {
/* at ":/fsname" */
break;
--
1.7.1
Re: [PATCH 4/5] max44000: Expose ambient sensor scaling
On 07/04/16 17:21, Crestez Dan Leonard wrote:
> This patch exposes ALSTIM as illuminance_integration_time and ALSPGA as
> illuminance_scale.
>
> Changing ALSTIM also changes the number of bits available in the data
> register.
Hmm.. This usually means we have oversampling going on rather than straight
integration time control - though it could be actually turning on or off
steps in the ADC pipeline...
> This is handled inside raw value reading because:
> * It's very easy to shift a few bits
> * It allows SCALE and INT_TIME to be completely independent controls
> * Buffer support requires constant scan_type.realbits per-channel
Agreed, this is the easiest way to handle this sort of thing.
This looks good to me (few trivial bits I picked up on inline).
>
> Signed-off-by: Crestez Dan Leonard
> ---
> drivers/iio/light/max44000.c | 163
> +--
> 1 file changed, 159 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c
> index 1dc10b9..e479c53 100644
> --- a/drivers/iio/light/max44000.c
> +++ b/drivers/iio/light/max44000.c
> @@ -53,6 +53,12 @@
> #define MAX44000_CFG_MODE_PRX0x14
> #define MAX44000_CFG_TRIM0x20
>
> +/* REG_RX bits */
> +#define MAX44000_CFG_RX_ALSTIM_MASK 0x0c
> +#define MAX44000_CFG_RX_ALSTIM_SHIFT 2
> +#define MAX44000_CFG_RX_ALSPGA_MASK 0x03
> +#define MAX44000_CFG_RX_ALSPGA_SHIFT 0
> +
> /* REG_TX bits */
> #define MAX44000_LED_CURRENT_MASK0xf
> #define MAX44000_LED_CURRENT_MAX 11
> @@ -73,6 +79,50 @@ struct max44000_data {
> /* Default scale is set to the minimum of 0.03125 or 1 / (1 << 5) lux */
> #define MAX44000_ALS_TO_LUX_DEFAULT_FRACTION_LOG2 5
>
> +/* Scale can be multiplied by up to 128x via ALSPGA for measurement gain */
> +static const int max44000_alspga_shift[] = {0, 2, 4, 7};
> +#define MAX44000_ALSPGA_MAX_SHIFT 7
> +
> +/* Scale can be multiplied by up to 64x via ALSTIM because of lost resolution
Another multiline comment issue. Please check all the patches..
> + *
> + * This scaling factor is hidden from userspace and instead accounted for
> when
> + * reading raw values from the device.
> + *
> + * This makes it possible to cleanly expose ALSPGA as IIO_CHAN_INFO_SCALE and
> + * ALSTIM as IIO_CHAN_INFO_INT_TIME without the values affecting each other.
> + *
> + * Hanlding this internally is also required for buffer support because the
handling.
> + * channel's scan_type can't be modified dynamically.
> + */
> +static const int max44000_alstim_shift[] = {0, 2, 4, 6};
> +#define MAX44000_ALSTIM_SHIFT(alstim) (2 * (alstim))
> +
> +/* Available integration times with pretty manual alignment: */
> +static const int max44000_int_time_avail_ns_array[] = {
> +1,
> + 2500,
> + 625,
> + 1562500,
> +};
> +static const char max44000_int_time_avail_str[] =
> + "0.100 "
> + "0.025 "
> + "0.00625 "
> + "0.001625";
> +
> +/* Available scales (internal to ulux) with pretty manual alignment: */
> +static const int max44000_scale_avail_ulux_array[] = {
> + 31250,
> +125000,
> +50,
> + 400,
> +};
> +static const char max44000_scale_avail_str[] =
> + "0.03125 "
> + "0.125 "
> + "0.5 "
> + "4";
> +
> static const struct iio_chan_spec max44000_channels[] = {
> {
> .type = IIO_LIGHT,
> @@ -94,15 +144,54 @@ static const struct iio_chan_spec max44000_channels[] = {
> },
> };
>
> +static inline int max44000_read_alstim(struct max44000_data *data)
> +{
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(data->regmap, MAX44000_REG_CFG_RX, &val);
> + if (ret < 0)
> + return ret;
> + return (val & MAX44000_CFG_RX_ALSTIM_MASK) >>
> MAX44000_CFG_RX_ALSTIM_SHIFT;
> +}
> +
> +static inline int max44000_write_alstim(struct max44000_data *data, int val)
> +{
> + return regmap_write_bits(data->regmap, MAX44000_REG_CFG_RX,
> + MAX44000_CFG_RX_ALSTIM_MASK,
> + val << MAX44000_CFG_RX_ALSTIM_SHIFT);
> +}
> +
> +static inline int max44000_read_alspga(struct max44000_data *data)
> +{
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(data->regmap, MAX44000_REG_CFG_RX, &val);
> + if (ret < 0)
> + return ret;
> + return (val & MAX44000_CFG_RX_ALSPGA_MASK) >>
> MAX44000_CFG_RX_ALSPGA_SHIFT;
> +}
> +
> +static inline int max44000_write_alspga(struct max44000_data *data, int val)
> +{
> + return regmap_write_bits(data->regmap, MAX44000_REG_CFG_RX,
> + MAX44000_CFG_RX_ALSPGA_MASK,
> + val << MAX44000_CFG_RX_ALSPGA_SHIFT);
> +}
> +
> static inline int max44000_read_alsval(struct max44000_data *data)
> {
> u16 regval;
> - int ret;
> + int alstim, ret;
>
> regval = 0;
> ret = regmap_bulk_read(data->re
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64
This patch was shown not to work. I just haven't removed it from opensuse yet. -Jeff -- Jeff Mahoney (apologies for the top post -- from my mobile) > On Apr 10, 2016, at 9:13 AM, James Simmons wrote: > > From: Jeff Mahoney > > On ppc64 with 64k pages, we get a build failure in lloop: > > drivers/staging/lustre/lustre/llite/lloop.c:527:2: > note: in expansion of macro 'CLASSERT' > CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > > There's no need to change the queue's logical block size. Even if it could > accept a 64k value, that would result in any file system on top of it > needing to also use 64k blocks. It'd be safe to set it to 4k, but there's > no actual need for it. It's not used to split requests except for WRITE_SAME, > which lloop doesn't implement anyway. > > Signed-off-by: Jeff Mahoney > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000 > Reviewed-on: http://review.whamcloud.com/7745 > Reviewed-by: Jinshan Xiong > Reviewed-by: Minh Diep > Reviewed-by: Oleg Drokin > Signed-off-by: James Simmons > --- > drivers/staging/lustre/lustre/llite/lloop.c |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/lustre/lustre/llite/lloop.c > b/drivers/staging/lustre/lustre/llite/lloop.c > index b725fc1..f396753 100644 > --- a/drivers/staging/lustre/lustre/llite/lloop.c > +++ b/drivers/staging/lustre/lustre/llite/lloop.c > @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct > file *unused, >lo->lo_queue->queuedata = lo; > >/* queue parameters */ > -CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > -blk_queue_logical_block_size(lo->lo_queue, > - (unsigned short)PAGE_CACHE_SIZE); >blk_queue_max_hw_sectors(lo->lo_queue, > LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9)); >blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS); > -- > 1.7.1 > >
Re: [PATCH 5/5] max44000: Initial triggered buffer support
On 07/04/16 17:21, Crestez Dan Leonard wrote:
> Signed-off-by: Crestez Dan Leonard
> ---
> drivers/iio/light/max44000.c | 63
>
> 1 file changed, 63 insertions(+)
>
> diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c
> index e479c53..7b1f8bc 100644
> --- a/drivers/iio/light/max44000.c
> +++ b/drivers/iio/light/max44000.c
> @@ -19,6 +19,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
>
> #define MAX44000_DRV_NAME"max44000"
> @@ -123,24 +126,41 @@ static const char max44000_scale_avail_str[] =
> "0.5 "
>"4";
>
> +#define MAX44000_SCAN_INDEX_ALS 0
> +#define MAX44000_SCAN_INDEX_PRX 1
> +
> static const struct iio_chan_spec max44000_channels[] = {
> {
> .type = IIO_LIGHT,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |
> BIT(IIO_CHAN_INFO_INT_TIME),
> + .scan_index = MAX44000_SCAN_INDEX_ALS,
> + .scan_type = {
> + .sign = 'u',
> + .realbits = 14,
> + .storagebits= 16,
> + }
> },
> {
> .type = IIO_PROXIMITY,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> + .scan_index = MAX44000_SCAN_INDEX_PRX,
> + .scan_type = {
> + .sign = 'u',
> + .realbits = 8,
> + .storagebits= 8,
> + }
> },
> + IIO_CHAN_SOFT_TIMESTAMP(2),
> {
> .type = IIO_CURRENT,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> BIT(IIO_CHAN_INFO_SCALE),
> .extend_name = "led",
> .output = 1,
> + .scan_index = -1,
> },
> };
>
> @@ -456,6 +476,42 @@ static int max44000_force_write_defaults(struct
> max44000_data *data)
> return 0;
> }
>
> +static irqreturn_t max44000_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct max44000_data *data = iio_priv(indio_dev);
> + u16 buf[indio_dev->scan_bytes / 2];
Autobuilder is moaning about this + you shouldn't directly access scan_bytes
at all from a driver. Here just make sure it's big enough to take anything
that might
show up (which isn't terribly big ;)
> + u8 *pos = (u8 *)buf;
> + unsigned int regval;
> + int ret;
> +
> + mutex_lock(&data->lock);
> + if (*indio_dev->active_scan_mask & (1 << MAX44000_SCAN_INDEX_ALS)) {
> + ret = max44000_read_alsval(data);
> + if (ret < 0)
> + goto out_unlock;
> + *((u16 *)pos) = ret;
> + pos += 2;
> + }
> + if (*indio_dev->active_scan_mask & (1 << MAX44000_SCAN_INDEX_PRX)) {
> + ret = regmap_read(data->regmap, MAX44000_REG_PRX_DATA, ®val);
> + if (ret < 0)
> + goto out_unlock;
> + *pos = regval;
> + }
> + mutex_unlock(&data->lock);
> +
> + iio_push_to_buffers_with_timestamp(indio_dev, buf, iio_get_time_ns());
> + iio_trigger_notify_done(indio_dev->trig);
> + return IRQ_HANDLED;
> +
> +out_unlock:
> + mutex_unlock(&data->lock);
> + iio_trigger_notify_done(indio_dev->trig);
> + return IRQ_HANDLED;
> +}
> +
> static int max44000_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -513,6 +569,12 @@ static int max44000_probe(struct i2c_client *client,
> return ret;
> }
>
> + ret = iio_triggered_buffer_setup(indio_dev, NULL,
> max44000_trigger_handler, NULL);
> + if (ret < 0) {
> + dev_err(&client->dev, "iio triggered buffer setup failed\n");
> + return ret;
> + }
> +
> return iio_device_register(indio_dev);
> }
>
> @@ -521,6 +583,7 @@ static int max44000_remove(struct i2c_client *client)
> struct iio_dev *indio_dev = i2c_get_clientdata(client);
>
> iio_device_unregister(indio_dev);
> + iio_triggered_buffer_cleanup(indio_dev);
> return 0;
> }
>
>
Re: [PATCH v2 06/14] USB: ch341: reinitialize chip on reconfiguration
Grigori Goronzy wrote: > Changing the LCR register after initialization does not seem to be > reliable on all chips (particularly not on CH341A). Restructure > initialization and configuration to always reinit the chip on > configuration changes instead and pass the LCR register value directly > to the initialization command. > +++ b/drivers/usb/serial/ch341.c > @@ -155,9 +157,7 @@ static int ch341_set_baudrate(struct usb_device *dev, > a = (factor & 0xff00) | divisor; > b = factor & 0xff; > > - r = ch341_control_out(dev, 0x9a, 0x1312, a); > - if (!r) > - r = ch341_control_out(dev, 0x9a, 0x0f2c, b); > + r = ch341_control_out(dev, CH341_SERIAL_INIT, 0x9c | (ctrl << 8) , a | > 0x80); The variable b is no longer used, so it is no longer necessary to compute the lower eight bits of the factor. Regards, Clemens
Re: [PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device
On 07/04/16 06:33, Marek Szyprowski wrote: > Hello, > > On 2016-04-06 22:33, Alison Schofield wrote: >> On Wed, Apr 06, 2016 at 09:03:00AM +0200, Marek Szyprowski wrote: >>> Hello, >>> >>> On 2016-04-06 07:15, Alison Schofield wrote: Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to retrieve device info. Patch created using Coccinelle plus manual edits. Signed-off-by: Alison Schofield >>> This patch changes the struct device which is used by the driver to report >>> errors. The driver used correctly the struct device associated with its >>> device tree node, while after the patch it will use device which is >>> associated with PMU regmap, which is a different device. PMU regmap is there >>> only to enable/disable the ADC block and it is not the regmap used to access >>> registers of the ADC device. >>> >>> I would prefer to drop this patch. >> Thanks Marek! Please check my understanding. Driver is not carrying >> a duplicate struct device. The regmap in exynos_adc is *not* this >> devices regmap. It belongs to the PMU, (power mgmt unit?) > > Exactly. > >> It seemed excessive to carry around a struct device just for the >> dev_err messages, but, we need that struct to extract the correct >> iio_dev struct. Without a regmap belonging to this actual device, >> no efficiencies can be gained in exynos, and the patch will be >> dropped from set v2. > > Thanks. > >> Now I need to be able to recognize such cases elsewhere. I'm going >> back though other patches in this set looking for that, but I'm not >> so sure I would recognize it. >> >> Jonathan & all, Any hints on the rule of regmap? > > You may check how the regmap is initialized. When it is retrieved by > phandle from device tree, then you might be almost sure that it refers > to the different device. True enough. Most simple devices that stand alone should be fine for this sort of cleanup as the regmap is typically initiated directly for them. Jonathan > > Best regards
Re: [PATCH] platform:x86 decouple telemetry driver from the optional IPC resources
On 2016/4/10 21:17, Andy Shevchenko wrote:
> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li wrote:
>> Currently the optional IPC resources prevent telemetry driver from
>> probing if these resources are not in ACPI table. This patch decouples
>> telemetry driver from these optional resources, so that telemetry driver
>> has dependency only on the necessary ACPI resources.
>
> Darren, I have comments as well.
>
>>
>> Signed-off-by: Aubrey Li
>> ---
>> drivers/platform/x86/intel_pmc_ipc.c | 48
>> +++-
>> drivers/platform/x86/intel_punit_ipc.c | 48
>> +---
>> 2 files changed, 54 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/platform/x86/intel_pmc_ipc.c
>> b/drivers/platform/x86/intel_pmc_ipc.c
>> index 092519e..29d9c02 100644
>> --- a/drivers/platform/x86/intel_pmc_ipc.c
>> +++ b/drivers/platform/x86/intel_pmc_ipc.c
>> @@ -686,8 +686,8 @@ static int ipc_plat_get_res(struct platform_device *pdev)
>> ipcdev.acpi_io_size = size;
>> dev_info(&pdev->dev, "io res: %pR\n", res);
>>
>> - /* This is index 0 to cover BIOS data register */
>> punit_res = punit_res_array;
>> + /* This is index 0 to cover BIOS data register */
>> res = platform_get_resource(pdev, IORESOURCE_MEM,
>> PLAT_RESOURCE_BIOS_DATA_INDEX);
>> if (!res) {
>> @@ -697,55 +697,51 @@ static int ipc_plat_get_res(struct platform_device
>> *pdev)
>> *punit_res = *res;
>> dev_info(&pdev->dev, "punit BIOS data res: %pR\n", res);
>>
>> + /* This is index 1 to cover BIOS interface register */
>> res = platform_get_resource(pdev, IORESOURCE_MEM,
>> PLAT_RESOURCE_BIOS_IFACE_INDEX);
>> if (!res) {
>> dev_err(&pdev->dev, "Failed to get res of punit BIOS
>> iface\n");
>> return -ENXIO;
>> }
>> - /* This is index 1 to cover BIOS interface register */
>> *++punit_res = *res;
>> dev_info(&pdev->dev, "punit BIOS interface res: %pR\n", res);
>>
>> + /* This is index 2 to cover ISP data register, optional */
>
> All above looks like a commentary fixes (except an additional
> 'optional' word in one case). Can you do this separately?
I don't think it's necessary.
>
>
>> res = platform_get_resource(pdev, IORESOURCE_MEM,
>> PLAT_RESOURCE_ISP_DATA_INDEX);
>> - if (!res) {
>> - dev_err(&pdev->dev, "Failed to get res of punit ISP data\n");
>> - return -ENXIO;
>> + ++punit_res;
>> + if (res) {
>> + *punit_res = *res;
>> + dev_info(&pdev->dev, "punit ISP data res: %pR\n", res);
>
> Okay, what if you re-arrange this to some helper first
>
Thanks for the idea, but I don't like a helper here, did you see
anything harmful of the current implementation?
> int …_assign_res(*pdev, index, *punit_res)
> {
> struct resource res;
> res = platform_get_resource(pdev, …, index);
> if (!res)
> return -ERRNO;
> *punit_res = *res;
> dev_dbg(%pR);
> return 0;
> }
>
> In this patch you move to optional by
> dev_err -> dev_warn
>
> and use
>
> if (ret)
> dev_warn( "…skip optional resource…" );
>
> instead of
> if (ret) {
> dev_err();
> return ret;
> }
>
>> }
>> - /* This is index 2 to cover ISP data register */
>> - *++punit_res = *res;
>> - dev_info(&pdev->dev, "punit ISP data res: %pR\n", res);
>>
>> + /* This is index 3 to cover ISP interface register, optional */
>> res = platform_get_resource(pdev, IORESOURCE_MEM,
>> PLAT_RESOURCE_ISP_IFACE_INDEX);
>> - if (!res) {
>> - dev_err(&pdev->dev, "Failed to get res of punit ISP
>> iface\n");
>> - return -ENXIO;
>> + ++punit_res;
>> + if (res) {
>> + *punit_res = *res;
>> + dev_info(&pdev->dev, "punit ISP interface res: %pR\n", res);
>> }
>> - /* This is index 3 to cover ISP interface register */
>> - *++punit_res = *res;
>> - dev_info(&pdev->dev, "punit ISP interface res: %pR\n", res);
>>
>> + /* This is index 4 to cover GTD data register, optional */
>> res = platform_get_resource(pdev, IORESOURCE_MEM,
>> PLAT_RESOURCE_GTD_DATA_INDEX);
>> - if (!res) {
>> - dev_err(&pdev->dev, "Failed to get res of punit GTD data\n");
>> - return -ENXIO;
>> + ++punit_res;
>> + if (res) {
>> + *punit_res = *res;
>> + dev_info(&pdev->dev, "punit GTD data res: %pR\n", res);
>> }
>> - /* This is index 4 to cover GTD data register */
>> - *++punit_res = *res;
>> - dev_info(&pdev->dev, "punit GTD data res: %pR\n", res);
>>
>> + /* This is index 5 to cover GTD interface register, optional */
>>
Re: [PATCH] nvme/host: Add missing blk_integrity tag_size + flags assignments
Looks fine, Reviewed-by: Sagi Grimberg
Re: [PATCH 5/9] iio: accel: mma7455: use regmap to retrieve struct device
On 06/04/16 08:35, Joachim Eastwood wrote:
> Hi Alison,
>
> On 6 April 2016 at 07:18, Alison Schofield wrote:
>> Driver includes struct regmap and struct device in its global data.
>> Remove the struct device and use regmap API to retrieve device info.
>>
>> Patch created using Coccinelle plus manual edits.
>>
>> Signed-off-by: Alison Schofield
>> ---
>> drivers/iio/accel/mma7455_core.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iio/accel/mma7455_core.c
>> b/drivers/iio/accel/mma7455_core.c
>> index c633cc2..c902f54 100644
>> --- a/drivers/iio/accel/mma7455_core.c
>> +++ b/drivers/iio/accel/mma7455_core.c
>> @@ -55,11 +55,11 @@
>>
>> struct mma7455_data {
>> struct regmap *regmap;
>> - struct device *dev;
>> };
>>
>> static int mma7455_drdy(struct mma7455_data *mma7455)
>> {
>> + struct device *dev = regmap_get_device(mma7455->regmap);
>
> ah, nice!
>
> Acked-by: Joachim Eastwood
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it.
This one is a fairly standard case and can be easily chased through to
see that the device pointer is the same one either way.
I'm going to let the rest sit a little longer to see if we get more
feedback on them
Jonathan
>
>
> regards,
> Joachim Eastwood
> --
> 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
>
Re: [PATCH 2/9] iio: adc: qcom-spmi-iadc: use regmap to retrieve struct device
On 06/04/16 06:16, Alison Schofield wrote:
> Driver includes struct regmap and struct device in its global data.
> Remove the struct device and use regmap API to retrieve device info.
>
> Patch created using Coccinelle plus manual edits.
>
> Signed-off-by: Alison Schofield
This has the same issue as the exynos driver - in that the regmap belongs
to the parent, not this device.
> ---
> drivers/iio/adc/qcom-spmi-iadc.c | 32 +---
> 1 file changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-iadc.c
> b/drivers/iio/adc/qcom-spmi-iadc.c
> index fabd24e..f69a057 100644
> --- a/drivers/iio/adc/qcom-spmi-iadc.c
> +++ b/drivers/iio/adc/qcom-spmi-iadc.c
> @@ -102,7 +102,6 @@
> /**
> * struct iadc_chip - IADC Current ADC device structure.
> * @regmap: regmap for register read/write.
> - * @dev: This device pointer.
> * @base: base offset for the ADC peripheral.
> * @rsense: Values of the internal and external sense resister in micro Ohms.
> * @poll_eoc: Poll for end of conversion instead of waiting for IRQ.
> @@ -113,7 +112,6 @@
> */
> struct iadc_chip {
> struct regmap *regmap;
> - struct device *dev;
> u16 base;
> boolpoll_eoc;
> u32 rsense[2];
> @@ -170,6 +168,7 @@ static int iadc_set_state(struct iadc_chip *iadc, bool
> state)
>
> static void iadc_status_show(struct iadc_chip *iadc)
> {
> + struct device *dev = regmap_get_device(iadc->regmap);
> u8 mode, sta1, chan, dig, en, req;
> int ret;
>
> @@ -197,7 +196,7 @@ static void iadc_status_show(struct iadc_chip *iadc)
> if (ret < 0)
> return;
>
> - dev_err(iadc->dev,
> + dev_err(dev,
> "mode:%02x en:%02x chan:%02x dig:%02x req:%02x sta1:%02x\n",
> mode, en, chan, dig, req, sta1);
> }
> @@ -284,6 +283,7 @@ static int iadc_read_result(struct iadc_chip *iadc, u16
> *data)
>
> static int iadc_do_conversion(struct iadc_chip *iadc, int chan, u16 *data)
> {
> + struct device *dev = regmap_get_device(iadc->regmap);
> unsigned int wait;
> int ret;
>
> @@ -310,7 +310,7 @@ static int iadc_do_conversion(struct iadc_chip *iadc, int
> chan, u16 *data)
> exit:
> iadc_set_state(iadc, false);
> if (ret < 0)
> - dev_err(iadc->dev, "conversion failed\n");
> + dev_err(dev, "conversion failed\n");
>
> return ret;
> }
> @@ -320,6 +320,7 @@ static int iadc_read_raw(struct iio_dev *indio_dev,
>int *val, int *val2, long mask)
> {
> struct iadc_chip *iadc = iio_priv(indio_dev);
> + struct device *dev = regmap_get_device(iadc->regmap);
> s32 isense_ua, vsense_uv;
> u16 adc_raw, vsense_raw;
> int ret;
> @@ -339,7 +340,7 @@ static int iadc_read_raw(struct iio_dev *indio_dev,
>
> isense_ua = vsense_uv / iadc->rsense[chan->channel];
>
> - dev_dbg(iadc->dev, "off %d gain %d adc %d %duV I %duA\n",
> + dev_dbg(dev, "off %d gain %d adc %d %duV I %duA\n",
> iadc->offset[chan->channel], iadc->gain,
> adc_raw, vsense_uv, isense_ua);
>
> @@ -370,6 +371,7 @@ static irqreturn_t iadc_isr(int irq, void *dev_id)
>
> static int iadc_update_offset(struct iadc_chip *iadc)
> {
> + struct device *dev = regmap_get_device(iadc->regmap);
> int ret;
>
> ret = iadc_do_conversion(iadc, IADC_GAIN_17P857MV, &iadc->gain);
> @@ -382,7 +384,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
> return ret;
>
> if (iadc->gain == iadc->offset[IADC_INT_RSENSE]) {
> - dev_err(iadc->dev, "error: internal offset == gain %d\n",
> + dev_err(dev, "error: internal offset == gain %d\n",
> iadc->gain);
> return -EINVAL;
> }
> @@ -393,8 +395,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
> return ret;
>
> if (iadc->gain == iadc->offset[IADC_EXT_RSENSE]) {
> - dev_err(iadc->dev, "error: external offset == gain %d\n",
> - iadc->gain);
> + dev_err(dev, "error: external offset == gain %d\n", iadc->gain);
> return -EINVAL;
> }
>
> @@ -403,6 +404,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
>
> static int iadc_version_check(struct iadc_chip *iadc)
> {
> + struct device *dev = regmap_get_device(iadc->regmap);
> u8 val;
> int ret;
>
> @@ -411,7 +413,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
> return ret;
>
> if (val < IADC_PERPH_TYPE_ADC) {
> - dev_err(iadc->dev, "%d is not ADC\n", val);
> + dev_err(dev, "%d is not ADC\n", val);
> return -EINVAL;
> }
>
> @@ -420,7 +422,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
> return ret;
>
> if (val < IADC
Re: [PATCH 3/9] iio: adc: qcom-spmi-vadc: use regmap to retrieve struct device
On 06/04/16 06:17, Alison Schofield wrote:
> Driver includes struct regmap and struct device in its global data.
> Remove the struct device and use regmap API to retrieve device info.
>
> Patch created using Coccinelle plus manual edits.
>
> Signed-off-by: Alison Schofield
Another one where the regmap belongs to the wrong device... (parent)
> ---
> drivers/iio/adc/qcom-spmi-vadc.c | 37 -
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-vadc.c
> b/drivers/iio/adc/qcom-spmi-vadc.c
> index c2babe5..9e7aeca 100644
> --- a/drivers/iio/adc/qcom-spmi-vadc.c
> +++ b/drivers/iio/adc/qcom-spmi-vadc.c
> @@ -161,7 +161,6 @@ struct vadc_channel_prop {
> /**
> * struct vadc_priv - VADC private structure.
> * @regmap: pointer to struct regmap.
> - * @dev: pointer to struct device.
> * @base: base address for the ADC peripheral.
> * @nchannels: number of VADC channels.
> * @chan_props: array of VADC channel properties.
> @@ -174,7 +173,6 @@ struct vadc_channel_prop {
> */
> struct vadc_priv {
> struct regmap*regmap;
> - struct device*dev;
> u16 base;
> unsigned int nchannels;
> struct vadc_channel_prop *chan_props;
> @@ -236,6 +234,7 @@ static int vadc_set_state(struct vadc_priv *vadc, bool
> state)
>
> static void vadc_show_status(struct vadc_priv *vadc)
> {
> + struct device *dev = regmap_get_device(vadc->regmap);
> u8 mode, sta1, chan, dig, en, req;
> int ret;
>
> @@ -263,7 +262,7 @@ static void vadc_show_status(struct vadc_priv *vadc)
> if (ret)
> return;
>
> - dev_err(vadc->dev,
> + dev_err(dev,
> "mode:%02x en:%02x chan:%02x dig:%02x req:%02x sta1:%02x\n",
> mode, en, chan, dig, req, sta1);
> }
> @@ -350,13 +349,14 @@ static int vadc_read_result(struct vadc_priv *vadc, u16
> *data)
> static struct vadc_channel_prop *vadc_get_channel(struct vadc_priv *vadc,
> unsigned int num)
> {
> + struct device *dev = regmap_get_device(vadc->regmap);
> unsigned int i;
>
> for (i = 0; i < vadc->nchannels; i++)
> if (vadc->chan_props[i].channel == num)
> return &vadc->chan_props[i];
>
> - dev_dbg(vadc->dev, "no such channel %02x\n", num);
> + dev_dbg(dev, "no such channel %02x\n", num);
>
> return NULL;
> }
> @@ -364,6 +364,7 @@ static struct vadc_channel_prop *vadc_get_channel(struct
> vadc_priv *vadc,
> static int vadc_do_conversion(struct vadc_priv *vadc,
> struct vadc_channel_prop *prop, u16 *data)
> {
> + struct device *dev = regmap_get_device(vadc->regmap);
> unsigned int timeout;
> int ret;
>
> @@ -406,7 +407,7 @@ static int vadc_do_conversion(struct vadc_priv *vadc,
> err_disable:
> vadc_set_state(vadc, false);
> if (ret)
> - dev_err(vadc->dev, "conversion failed\n");
> + dev_err(dev, "conversion failed\n");
> unlock:
> mutex_unlock(&vadc->lock);
> return ret;
> @@ -414,6 +415,7 @@ unlock:
>
> static int vadc_measure_ref_points(struct vadc_priv *vadc)
> {
> + struct device *dev = regmap_get_device(vadc->regmap);
> struct vadc_channel_prop *prop;
> u16 read_1, read_2;
> int ret;
> @@ -463,7 +465,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
> vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2;
> err:
> if (ret)
> - dev_err(vadc->dev, "measure reference points failed\n");
> + dev_err(dev, "measure reference points failed\n");
>
> return ret;
> }
> @@ -814,6 +816,7 @@ static int vadc_get_dt_channel_data(struct device *dev,
>
> static int vadc_get_dt_data(struct vadc_priv *vadc, struct device_node *node)
> {
> + struct device *dev = regmap_get_device(vadc->regmap);
> const struct vadc_channels *vadc_chan;
> struct iio_chan_spec *iio_chan;
> struct vadc_channel_prop prop;
> @@ -825,12 +828,12 @@ static int vadc_get_dt_data(struct vadc_priv *vadc,
> struct device_node *node)
> if (!vadc->nchannels)
> return -EINVAL;
>
> - vadc->iio_chans = devm_kcalloc(vadc->dev, vadc->nchannels,
> + vadc->iio_chans = devm_kcalloc(dev, vadc->nchannels,
> sizeof(*vadc->iio_chans), GFP_KERNEL);
> if (!vadc->iio_chans)
> return -ENOMEM;
>
> - vadc->chan_props = devm_kcalloc(vadc->dev, vadc->nchannels,
> + vadc->chan_props = devm_kcalloc(dev, vadc->nchannels,
> sizeof(*vadc->chan_props), GFP_KERNEL);
> if (!vadc->chan_props)
> return -ENOMEM;
> @@ -838,7 +841,7 @@ static int vadc_get_dt_data(struct vadc_priv *vadc,
> struct device_node *node)
> iio_chan = vadc->iio_chans;
>
> for_each_av
Re: [PATCH v2] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()
On 06/04/16 22:06, Lars-Peter Clausen wrote:
> On 04/06/2016 06:11 AM, Alison Schofield wrote:
>> Replace the code that guarantees the device stays in direct mode with
>> iio_device_{claim|release}_direct_mode() which does same.
>>
>> Signed-off-by: Alison Schofield
>
> Looks good, thanks.
>
> Acked-by: Lars-Peter Clausen
>
Applied to the togreg branch of iio.git - thanks.
Jonathan
>> ---
>> Changed in v2:
>> - removed improper application of claim/release from intr handler
>> - updated changelog
>>
>> drivers/staging/iio/adc/ad7606_core.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/iio/adc/ad7606_core.c
>> b/drivers/staging/iio/adc/ad7606_core.c
>> index 6dbc811..f79ee61 100644
>> --- a/drivers/staging/iio/adc/ad7606_core.c
>> +++ b/drivers/staging/iio/adc/ad7606_core.c
>> @@ -88,12 +88,12 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
>>
>> switch (m) {
>> case IIO_CHAN_INFO_RAW:
>> -mutex_lock(&indio_dev->mlock);
>> -if (iio_buffer_enabled(indio_dev))
>> -ret = -EBUSY;
>> -else
>> -ret = ad7606_scan_direct(indio_dev, chan->address);
>> -mutex_unlock(&indio_dev->mlock);
>> +ret = iio_device_claim_direct_mode(indio_dev);
>> +if (ret)
>> +return ret;
>> +
>> +ret = ad7606_scan_direct(indio_dev, chan->address);
>> +iio_device_release_direct_mode(indio_dev);
>>
>> if (ret < 0)
>> return ret;
>>
>
Re: [PATCH] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()
On 06/04/16 19:06, Lars-Peter Clausen wrote:
> On 04/03/2016 11:09 AM, Jonathan Cameron wrote:
>> On 01/04/16 17:53, Alison Schofield wrote:
>>> Two instances are moved to the new claim/release API:
>>>
>>> In the first instance, the driver was using mlock followed by
>>> iio_buffer_enabled(). Replace that code with the new API to guarantee
>>> the device stays in direct mode. There is no change in driver behavior.
>>>
>>> In the second instance, the driver was not using mlock to hold the
>>> device in direct mode, but should have been. Here we introduce the
>>> new API to guarantee direct mode. This is a change in driver behavior.
>>>
>>> Signed-off-by: Alison Schofield
>>> ---
>>> drivers/staging/iio/adc/ad7606_core.c | 15 ---
>>> 1 file changed, 8 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/staging/iio/adc/ad7606_core.c
> b/drivers/staging/iio/adc/ad7606_core.c
>>> index 6dbc811..f914b8d 100644
>>> --- a/drivers/staging/iio/adc/ad7606_core.c
>>> +++ b/drivers/staging/iio/adc/ad7606_core.c
>>> @@ -88,12 +88,12 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
>>>
>>> switch (m) {
>>> case IIO_CHAN_INFO_RAW:
>>> - mutex_lock(&indio_dev->mlock);
>>> - if (iio_buffer_enabled(indio_dev))
>>> - ret = -EBUSY;
>>> - else
>>> - ret = ad7606_scan_direct(indio_dev, chan->address);
>>> - mutex_unlock(&indio_dev->mlock);
>>> + ret = iio_device_claim_direct_mode(indio_dev);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = ad7606_scan_direct(indio_dev, chan->address);
>>> + iio_device_release_direct_mode(indio_dev);
>>>
>>> if (ret < 0)
>>> return ret;
>>> @@ -411,8 +411,9 @@ static irqreturn_t ad7606_interrupt(int irq, void
> *dev_id)
>>> struct iio_dev *indio_dev = dev_id;
>>> struct ad7606_state *st = iio_priv(indio_dev);
>>>
>>> - if (iio_buffer_enabled(indio_dev)) {
>>> + if (!iio_device_claim_direct_mode(indio_dev)) {
>>> schedule_work(&st->poll_work);
>>> + iio_device_release_direct_mode(indio_dev);
>> Unfortunately this won't work. That interrupt is still in traditional non
>> threaded form. This will take a mutex in a top half interrupt handler
>> where a sleep cannot occur.
>>
>> I'm just wondering how expensive it would be to fix this by moving that over
>> to a threaded handler. In the poll_work case (buffer) it would be cleaner
> to do
>> so. I'm really confused what the intended interrupt handler
>> is in here. I 'think' the sequence is:
>>
>> Trigger fires the convst pin whether in top half or the bottom half of
>> a threaded interrupt, but not both - I guess this works, if it is rather
>> 'unusual'.
>>
>> We then get a interrupt to indicate that it has finished conversion and that
>> filters through to actually fill the buffer via a traditional top half /
>> bottom half interrupt handler.
>>
>> So if we were to convert that to a threaded interrupt (with no top half / non
>> threaded part), we could drop the schedule_work and just call
>> ad7606_poll_bh_to_ring from the thread handler.
>>
>> In the direct read case I doubt we care about the delay in dropping to a
>> thread prior to signalling the data is ready.
>>
>> Can't think why this driver is still in staging :)
>
> Yeah, we should leave this driver out from the conversion for now. The whole
> convst pin handling need a major rework. It shouldn't really be in the
> driver and usually you wouldn't want to use to use a GPIO and software timer
> since that gives you way to much jitter for good results. You'd probably use
> something like a PWM.
Agreed, you would normally move this into hardware, but we'd still need to allow
for the possibility of it being software triggered - even if ugly.
Anyhow, lets park this for now.
J
>
>>
>> Lars, any interest from Analog in getting this one cleaned up? Also
>> do you have any test hardware, if we mess around with this interrupt
>> handling?
>
> I have the hardware somewhere in some storage bay, but just converting this
> over to threaded interrupt handling is not really a solution. So, if you
> want to get rid of the iio_buffer_enabled() in the interrupt handler a
> simple solution is to register preenable and postdisable callbacks where you
> set a flag in the driver struct to indicate that it is in buffered mode or
> not.
>
[PATCH trivial] include : linux: hugetlb: Clean up code
From: Chen Gang
Macro HUGETLBFS_SB is clearer enough, so one statement is clearer than
3 lines statements.
Remove redundant return statements for non-return functions, which can
save lines, at least.
Signed-off-by: Chen Gang
---
include/linux/hugetlb.h| 4 +---
include/linux/hugetlb_cgroup.h | 4
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 0f735ea..c26d463 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -353,9 +353,7 @@ extern unsigned int default_hstate_idx;
static inline struct hstate *hstate_inode(struct inode *i)
{
- struct hugetlbfs_sb_info *hsb;
- hsb = HUGETLBFS_SB(i->i_sb);
- return hsb->hstate;
+ return HUGETLBFS_SB(i->i_sb)->hstate;
}
static inline struct hstate *hstate_file(struct file *f)
diff --git a/include/linux/hugetlb_cgroup.h b/include/linux/hugetlb_cgroup.h
index 24154c2..063962f 100644
--- a/include/linux/hugetlb_cgroup.h
+++ b/include/linux/hugetlb_cgroup.h
@@ -93,20 +93,17 @@ hugetlb_cgroup_commit_charge(int idx, unsigned long
nr_pages,
struct hugetlb_cgroup *h_cg,
struct page *page)
{
- return;
}
static inline void
hugetlb_cgroup_uncharge_page(int idx, unsigned long nr_pages, struct page
*page)
{
- return;
}
static inline void
hugetlb_cgroup_uncharge_cgroup(int idx, unsigned long nr_pages,
struct hugetlb_cgroup *h_cg)
{
- return;
}
static inline void hugetlb_cgroup_file_init(void)
@@ -116,7 +113,6 @@ static inline void hugetlb_cgroup_file_init(void)
static inline void hugetlb_cgroup_migrate(struct page *oldhpage,
struct page *newhpage)
{
- return;
}
#endif /* CONFIG_MEM_RES_CTLR_HUGETLB */
--
1.9.3
[PATCH] include/linux/hugetlb.h: Use bool instead of int for hugepage_migration_supported()
From: Chen Gang
It is used as a pure bool function within kernel source wide.
Signed-off-by: Chen Gang
---
include/linux/hugetlb.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index e44c578..0f735ea 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -454,12 +454,12 @@ static inline pgoff_t basepage_index(struct page *page)
extern void dissolve_free_huge_pages(unsigned long start_pfn,
unsigned long end_pfn);
-static inline int hugepage_migration_supported(struct hstate *h)
+static inline bool hugepage_migration_supported(struct hstate *h)
{
#ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
return huge_page_shift(h) == PMD_SHIFT;
#else
- return 0;
+ return false;
#endif
}
@@ -521,7 +521,7 @@ static inline pgoff_t basepage_index(struct page *page)
return page->index;
}
#define dissolve_free_huge_pages(s, e) do {} while (0)
-#define hugepage_migration_supported(h)0
+#define hugepage_migration_supported(h)false
static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
struct mm_struct *mm, pte_t *pte)
--
1.9.3
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64
> This patch was shown not to work. I just haven't removed it from opensuse yet. Its been running in our production tree as well for some time. Guess that change is a noop. In any case we have been discussing redoing the lloop driver anyways. Just need to find the cycles. > -- > Jeff Mahoney > (apologies for the top post -- from my mobile) > > > On Apr 10, 2016, at 9:13 AM, James Simmons wrote: > > > > From: Jeff Mahoney > > > > On ppc64 with 64k pages, we get a build failure in lloop: > > > > drivers/staging/lustre/lustre/llite/lloop.c:527:2: > > note: in expansion of macro 'CLASSERT' > > CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > > > > There's no need to change the queue's logical block size. Even if it could > > accept a 64k value, that would result in any file system on top of it > > needing to also use 64k blocks. It'd be safe to set it to 4k, but there's > > no actual need for it. It's not used to split requests except for > > WRITE_SAME, > > which lloop doesn't implement anyway. > > > > Signed-off-by: Jeff Mahoney > > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4000 > > Reviewed-on: http://review.whamcloud.com/7745 > > Reviewed-by: Jinshan Xiong > > Reviewed-by: Minh Diep > > Reviewed-by: Oleg Drokin > > Signed-off-by: James Simmons > > --- > > drivers/staging/lustre/lustre/llite/lloop.c |3 --- > > 1 files changed, 0 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/staging/lustre/lustre/llite/lloop.c > > b/drivers/staging/lustre/lustre/llite/lloop.c > > index b725fc1..f396753 100644 > > --- a/drivers/staging/lustre/lustre/llite/lloop.c > > +++ b/drivers/staging/lustre/lustre/llite/lloop.c > > @@ -525,9 +525,6 @@ static int loop_set_fd(struct lloop_device *lo, struct > > file *unused, > >lo->lo_queue->queuedata = lo; > > > >/* queue parameters */ > > -CLASSERT(PAGE_CACHE_SIZE < (1 << (sizeof(unsigned short) * 8))); > > -blk_queue_logical_block_size(lo->lo_queue, > > - (unsigned short)PAGE_CACHE_SIZE); > >blk_queue_max_hw_sectors(lo->lo_queue, > > LLOOP_MAX_SEGMENTS << (PAGE_CACHE_SHIFT - 9)); > >blk_queue_max_segments(lo->lo_queue, LLOOP_MAX_SEGMENTS); > > -- > > 1.7.1 > > > > > >
Re: [PATCH 1/3] iio: core: Add devm_ APIs for iio_channel_{get,release}
On 06/04/16 15:58, Laxman Dewangan wrote:
> Hi Daniel,
>
>
> On Wednesday 06 April 2016 07:19 PM, Daniel Baluta wrote:
>> On Wed, Apr 6, 2016 at 1:31 PM, Laxman Dewangan wrote:
>>> Some of kernel driver uses the IIO framework to get the sensor
>>> value via ADC or IIO HW driver. The client driver get iio channel
>>> by iio_channel_get() and release it by calling iio_channel_release().
>>>
>>> Add resource managed version (devm_*) of these APIs so that if client
>>> calls the devm_iio_channel_get() then it need not to release it explicitly,
>>> it can be done by managed device framework when driver get un-binded.
>>>
>>> This reduces the code in error path and also need of .remove callback in
>>> some cases.
>>>
>> Please provide at least one example of code that uses this API.
>
> Most of client for this APIs are in other subsystem.
> When I was working on the patch
> [PATCH 2/2] thermal: generic-adc: Add ADC based thermal sensor driver
>
> if I have devm_iio_channel_get() then I can get .remove callback at all.
>
> I did not use this new APIs in my patch because they are in different
> subsystem.
It's actually worse than that having taken a quick look at the generic-adc
thermal patch
you reference above.
(perhaps worth cc'ing linux-iio for next version of that).
Without this devm function set you have a race in remove in which I think you
can
get attempts to access the channels after they have been released...
> +
> + gti->tz_dev = devm_thermal_zone_of_sensor_register(&pdev->dev, 0,
> + gti, &gadc_thermal_ops);
> + if (IS_ERR(gti->tz_dev)) {
> + ret = PTR_ERR(gti->tz_dev);
> + dev_err(&pdev->dev, "Thermal zone sensor register failed: %d\n",
> + ret);
> + goto sensor_fail;
> + }
This will get cleaned up in remove 'after' the iio_channels are released.
Hence you have a race in which they can probably be accessed after release
(unless some magic is going on that I've missed).
> +
> + return 0;
> +
> +sensor_fail:
> + iio_channel_release(gti->channel);
> + return ret;
> +}
> +
> +static int gadc_thermal_remove(struct platform_device *pdev)
> +{
> + struct gadc_thermal_info *gti = platform_get_drvdata(pdev);
> +
> + iio_channel_release(gti->channel);
> +
> + return 0;
> +}
> +
>
>
>
Re: [RFC PATCH 0/3] restartable sequences v2: fast user-space percpu critical sections
- On Apr 8, 2016, at 5:25 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Apr 8, 2016 at 10:46 AM, Mathieu Desnoyers
> wrote:
>>
>> By the way, the debugger can always decide to single-step through the
>> first iteration of the rseq, and then after it loops, decide to skip
>> single-stepping until the exit points are reached.
>
> A _human_ debugger may decide to do that yes.
>
> But the the debugger _program_ may not be that smart. For example,
> let's say that you - as a human - set a few watchpoints. The debugger
> will use hardware breakpoints for the first few, but in more complex
> cases the debugger will actually say "oops, no more hw breakpoints,
> I'll just start single-stepping instead".
>
> The human operator may not even be aware that the debugger has gone
> into that slower mode. Normally it's just slower. But you'd want it to
> be _only_ slower, not "oops, the program no longer makes any forward
> progress at all, because a library that the user didn't even know or
> care about - and never sees, because the single-stepping is all
> internal = happened to use a code sequence that doesn't work under
> single-stepping".
Which is why I'm proposing to extend gdb to support this automatically,
without requiring interaction or knowledge from the user.
The idea is to let gdb detect entry points into those restartable
critical sections as it single-steps through the program. It would
know about all rseq c.s. exit points too, so it can track whether
it has single-stepped over an entire rseq c.s. and thus caused a
restart. At that point, it can put the breakpoint at each exit point
associated with the entry point, thus skipping single-step of the
second iteration of the critical section.
I think this could be achieved by populating a section that contains
information about entry and exit points of those critical sections
in the rseq_{start,finish,abort} functions. Those sections would end
up in the app/lib ELF binary, may not have to be necessarily loaded
into program's memory.
Does it make sense to try it out, or am I missing something obvious ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Re: [PATCH 1/3] iio: core: Add devm_ APIs for iio_channel_{get,release}
On 06/04/16 11:31, Laxman Dewangan wrote:
> Some of kernel driver uses the IIO framework to get the sensor
> value via ADC or IIO HW driver. The client driver get iio channel
> by iio_channel_get() and release it by calling iio_channel_release().
>
> Add resource managed version (devm_*) of these APIs so that if client
> calls the devm_iio_channel_get() then it need not to release it explicitly,
> it can be done by managed device framework when driver get un-binded.
>
> This reduces the code in error path and also need of .remove callback in
> some cases.
>
> Signed-off-by: Laxman Dewangan
I'm fine with this - but would like it to sit for a few more days to see
if it gets any other feedback.
> ---
> drivers/iio/inkern.c | 48
>
> include/linux/iio/consumer.h | 27 +
> 2 files changed, 75 insertions(+)
>
> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> index 734a004..18e623f 100644
> --- a/drivers/iio/inkern.c
> +++ b/drivers/iio/inkern.c
> @@ -356,6 +356,54 @@ void iio_channel_release(struct iio_channel *channel)
> }
> EXPORT_SYMBOL_GPL(iio_channel_release);
>
> +static void devm_iio_channel_free(struct device *dev, void *res)
> +{
> + struct iio_channel *channel = *(struct iio_channel **)res;
> +
> + iio_channel_release(channel);
> +}
> +
> +static int devm_iio_channel_match(struct device *dev, void *res, void *data)
> +{
> + struct iio_channel **r = res;
> +
> + if (!r || !*r) {
> + WARN_ON(!r || !*r);
> + return 0;
> + }
> +
> + return *r == data;
> +}
> +
> +struct iio_channel *devm_iio_channel_get(struct device *dev,
> + const char *channel_name)
> +{
> + struct iio_channel **ptr, *channel;
> +
> + ptr = devres_alloc(devm_iio_channel_free, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return ERR_PTR(-ENOMEM);
> +
> + channel = iio_channel_get(dev, channel_name);
> + if (IS_ERR(channel)) {
> + devres_free(ptr);
> + return channel;
> + }
> +
> + *ptr = channel;
> + devres_add(dev, ptr);
> +
> + return channel;
> +}
> +EXPORT_SYMBOL_GPL(devm_iio_channel_get);
> +
> +void devm_iio_channel_release(struct device *dev, struct iio_channel
> *channel)
> +{
> + WARN_ON(devres_release(dev, devm_iio_channel_free,
> +devm_iio_channel_match, channel));
> +}
> +EXPORT_SYMBOL_GPL(devm_iio_channel_release);
> +
> struct iio_channel *iio_channel_get_all(struct device *dev)
> {
> const char *name;
> diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
> index fad5867..e1e033d 100644
> --- a/include/linux/iio/consumer.h
> +++ b/include/linux/iio/consumer.h
> @@ -49,6 +49,33 @@ struct iio_channel *iio_channel_get(struct device *dev,
> void iio_channel_release(struct iio_channel *chan);
>
> /**
> + * devm_iio_channel_get() - Resource managed version of iio_channel_get().
> + * @dev: Pointer to consumer device. Device name must match
> + * the name of the device as provided in the iio_map
> + * with which the desired provider to consumer mapping
> + * was registered.
> + * @consumer_channel:Unique name to identify the channel on the
> consumer
> + * side. This typically describes the channels use within
> + * the consumer. E.g. 'battery_voltage'
> + *
> + * Returns a pointer to negative errno if it is not able to get the iio
> channel
> + * otherwise returns valid pointer for iio channel.
> + *
> + * The allocated iio channel is automatically released when the device is
> + * unbound.
> + */
> +struct iio_channel *devm_iio_channel_get(struct device *dev,
> + const char *consumer_channel);
> +/**
> + * devm_iio_channel_release() - Resource managed version of
> + * iio_channel_release().
> + * @dev: Pointer to consumer device for which resource
> + * is allocared.
> + * @chan:The channel to be released.
> + */
> +void devm_iio_channel_release(struct device *dev, struct iio_channel *chan);
> +
> +/**
> * iio_channel_get_all() - get all channels associated with a client
> * @dev: Pointer to consumer device.
> *
>
Re: [PATCH v6 08/24] iio: imu: inv_mpu6050: convert to use an explicit i2c mux core
On 03/04/16 12:51, Peter Rosin wrote:
> On 2016-04-03 12:51, Jonathan Cameron wrote:
>> On 03/04/16 09:52, Peter Rosin wrote:
>>> From: Peter Rosin
>>>
>>> Allocate an explicit i2c mux core to handle parent and child adapters
>>> etc. Update the select/deselect ops to be in terms of the i2c mux core
>>> instead of the child adapter.
>>>
>>> Signed-off-by: Peter Rosin
>> I'm mostly fine with this (though one unrelated change seems to have snuck
>> in). However, I'm not set up to test it - hence other than fixing the change
>> you can have my ack, but ideal would be a tested by from someone with
>> relevant hardware... However, it looks to be a fairly mechanical change so
>> if no one is currently setup to test it, then don't let it hold up the
>> series too long!
>>
>> Acked-by: Jonathan Cameron
>
> Thanks for your acks!
>
>> Jonathan
>>> ---
>>> drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c | 2 +-
>>> drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 1 -
>>> drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 32
>>> +-
>>> drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 3 ++-
>>> 4 files changed, 17 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
>>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
>>> index 2771106fd650..f62b8bd9ad7e 100644
>>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
>>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
>>> @@ -183,7 +183,7 @@ int inv_mpu_acpi_create_mux_client(struct i2c_client
>>> *client)
>>> } else
>>> return 0; /* no secondary addr, which is OK */
>>> }
>>> - st->mux_client = i2c_new_device(st->mux_adapter, &info);
>>> + st->mux_client = i2c_new_device(st->muxc->adapter[0], &info);
>>> if (!st->mux_client)
>>> return -ENODEV;
>>> }
>>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>>> index d192953e9a38..0c2bded2b5b7 100644
>>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
>>> @@ -23,7 +23,6 @@
>>> #include
>>> #include
>>> #include
>>> -#include
>>> #include
>>> #include "inv_mpu_iio.h"
>>>
>>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>>> index f581256d9d4c..0d429d788106 100644
>>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>>> @@ -15,7 +15,6 @@
>>> #include
>>> #include
>>> #include
>>> -#include
>>> #include
>>> #include
>>> #include "inv_mpu_iio.h"
>>> @@ -52,10 +51,9 @@ static int inv_mpu6050_write_reg_unlocked(struct
>>> i2c_client *client,
>>> return 0;
>>> }
>>>
>>> -static int inv_mpu6050_select_bypass(struct i2c_adapter *adap, void
>>> *mux_priv,
>>> -u32 chan_id)
>>> +static int inv_mpu6050_select_bypass(struct i2c_mux_core *muxc, u32
>>> chan_id)
>>> {
>>> - struct i2c_client *client = mux_priv;
>>> + struct i2c_client *client = i2c_mux_priv(muxc);
>>> struct iio_dev *indio_dev = dev_get_drvdata(&client->dev);
>
> Here, the existing code uses drv_get_drvdata to get from i2c_client to
> iio_dev...
>
>>> struct inv_mpu6050_state *st = iio_priv(indio_dev);
>>> int ret = 0;
>>> @@ -84,10 +82,9 @@ write_error:
>>> return ret;
>>> }
>>>
>>> -static int inv_mpu6050_deselect_bypass(struct i2c_adapter *adap,
>>> - void *mux_priv, u32 chan_id)
>>> +static int inv_mpu6050_deselect_bypass(struct i2c_mux_core *muxc, u32
>>> chan_id)
>>> {
>>> - struct i2c_client *client = mux_priv;
>>> + struct i2c_client *client = i2c_mux_priv(muxc);
>>> struct iio_dev *indio_dev = dev_get_drvdata(&client->dev);
>
> ...and here too...
>
>>> struct inv_mpu6050_state *st = iio_priv(indio_dev);
>>>
>>> @@ -136,16 +133,15 @@ static int inv_mpu_probe(struct i2c_client *client,
>>> return result;
>>>
>>> st = iio_priv(dev_get_drvdata(&client->dev));
>>> - st->mux_adapter = i2c_add_mux_adapter(client->adapter,
>>> - &client->dev,
>>> - client,
>>> - 0, 0, 0,
>>> - inv_mpu6050_select_bypass,
>>> - inv_mpu6050_deselect_bypass);
>>> - if (!st->mux_adapter) {
>>> - result = -ENODEV;
>>> + st->muxc = i2c_mux_one_adapter(client->adapter, &client->dev, 0, 0,
>>> + 0, 0, 0,
>>> + inv_mpu6050_select_bypass,
>>> + inv_mpu6050_deselect_bypass);
>>> + if (IS_ERR(st->muxc)) {
>>> + result = PTR_ERR(st->muxc);
>>> goto out_unreg_device;
>>> }
>>> + st->muxc->priv = client;
>>>
>>>
Re: [PATCH] powerpc: introduce {cmp}xchg for u8 and u16
On 2016年04月08日 15:47, Peter Zijlstra wrote:
> On Fri, Apr 08, 2016 at 02:41:46PM +0800, Pan Xinhui wrote:
>> From: pan xinhui
>>
>> Implement xchg{u8,u16}{local,relaxed}, and
>> cmpxchg{u8,u16}{,local,acquire,relaxed}.
>>
>> Atomic operation on 8-bit and 16-bit data type is supported from power7
>
> And yes I see nothing P7 specific here, this implementation is for
> everything PPC64 afaict, no?
>
Hello Peter,
No, it's not for every ppc. So yes, I need add #ifdef here. Thanks for
pointing it out.
We might need a new config option and let it depend on POWER7/POWER8_CPU or
even POWER9...
> Also, note that you don't need explicit 8/16 bit atomics to implement
> these. Its fine to use 32bit atomics and only modify half the word.
>
That is true. But I am a little worried about the performance. It will forbid
any other tasks to touch the other half word during the load/reserve, right?
I am working on the qspinlock implementation on PPC.
Your and Waiman's patches are so nice. :)
> Also, you might want to invest in some CPP to reduce the endless
> repetition.
>
Will do that. thanks for your tips.
thanks
xinhui
> Other than that, no objections :-)
>
Re: [PATCH] iio: ak8975: fix maybe-uninitialized warning
On 05/04/16 14:03, Richard Leitner wrote: > If i2c_device_id *id is NULL and acpi_match_device returns NULL too, > then chipset may be unitialized when accessing &ak_def_array[chipset] in > ak8975_probe. Therefore initialize chipset to AK_MAX_TYPE, which will > return an error when not changed. > > This patch fixes the following maybe-uninitialized warning: > > drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’: > drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used > uninitialized in this function [-Wmaybe-uninitialized] > data->def = &ak_def_array[chipset]; > > Signed-off-by: Richard Leitner Applied to the fixes-togreg branch of iio.git and marked fo stable. > --- > drivers/iio/magnetometer/ak8975.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/magnetometer/ak8975.c > b/drivers/iio/magnetometer/ak8975.c index 9c5c9ef..82783dc 100644 > --- a/drivers/iio/magnetometer/ak8975.c > +++ b/drivers/iio/magnetometer/ak8975.c > @@ -732,7 +732,7 @@ static int ak8975_probe(struct i2c_client *client, > int eoc_gpio; > int err; > const char *name = NULL; > - enum asahi_compass_chipset chipset; > + enum asahi_compass_chipset chipset = AK_MAX_TYPE; > > /* Grab and set up the supplied GPIO. */ > if (client->dev.platform_data) >
Re: [PATCH v2 1/2] ti-adc081c: Add support for adc101c* and adc121c*
On 04/04/16 19:21, Crestez Dan Leonard wrote:
> These chips has an almost identical interface but a deal with a
> different number of value bits. Datasheet links for comparison:
>
> * http://www.ti.com/lit/ds/symlink/adc081c021.pdf
> * http://www.ti.com/lit/ds/symlink/adc101c021.pdf
> * http://www.ti.com/lit/ds/symlink/adc121c021.pdf
>
> Signed-off-by: Crestez Dan Leonard
A trivial little request inline to move over to an array of structures
describing the different parts and use an enum indexing that instead of
pointers in the
i2c_device_id tables.
Otherwise looks good.
> ---
> drivers/iio/adc/Kconfig | 6 +++---
> drivers/iio/adc/ti-adc081c.c | 42 ++
> 2 files changed, 41 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 9ddcd5d..a2d0db5 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -378,11 +378,11 @@ config ROCKCHIP_SARADC
> module will be called rockchip_saradc.
>
> config TI_ADC081C
> - tristate "Texas Instruments ADC081C021/027"
> + tristate "Texas Instruments ADC081C/ADC101C/ADC121C family"
> depends on I2C
> help
> - If you say yes here you get support for Texas Instruments ADC081C021
> - and ADC081C027 ADC chips.
> + If you say yes here you get support for Texas Instruments ADC081C,
> + ADC101C and ADC121C ADC chips.
>
> This driver can also be built as a module. If so, the module will be
> called ti-adc081c.
> diff --git a/drivers/iio/adc/ti-adc081c.c b/drivers/iio/adc/ti-adc081c.c
> index ecbc121..3b3c656 100644
> --- a/drivers/iio/adc/ti-adc081c.c
> +++ b/drivers/iio/adc/ti-adc081c.c
> @@ -1,9 +1,21 @@
> /*
> + * TI ADC081C/ADC101C/ADC121C 8/10/12-bit ADC driver
> + *
> * Copyright (C) 2012 Avionic Design GmbH
> + * Copyright (C) 2016 Intel
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> * published by the Free Software Foundation.
> + *
> + * Datasheets:
> + * http://www.ti.com/lit/ds/symlink/adc081c021.pdf
> + * http://www.ti.com/lit/ds/symlink/adc101c021.pdf
> + * http://www.ti.com/lit/ds/symlink/adc121c021.pdf
> + *
> + * The devices have a very similar interface and differ mostly in the number
> of
> + * bits handled. For the 8-bit and 10-bit models the least-significant 4 or 2
> + * bits of value registers are reserved.
> */
>
> #include
> @@ -17,6 +29,9 @@
> struct adc081c {
> struct i2c_client *i2c;
> struct regulator *ref;
> +
> + /* 8, 10 or 12 */
> + int bits;
> };
>
> #define REG_CONV_RES 0x00
> @@ -34,7 +49,7 @@ static int adc081c_read_raw(struct iio_dev *iio,
> if (err < 0)
> return err;
>
> - *value = (err >> 4) & 0xff;
> + *value = (err & 0xFFF) >> (12 - adc->bits);
> return IIO_VAL_INT;
>
> case IIO_CHAN_INFO_SCALE:
> @@ -43,7 +58,7 @@ static int adc081c_read_raw(struct iio_dev *iio,
> return err;
>
> *value = err / 1000;
> - *shift = 8;
> + *shift = adc->bits;
>
> return IIO_VAL_FRACTIONAL_LOG2;
>
> @@ -60,6 +75,19 @@ static const struct iio_chan_spec adc081c_channel = {
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> };
>
> +struct adcxx1c_model {
> + int bits;
> +};
> +
> +#define DEFINE_ADCxx1C_MODEL(_name, _bits) \
> + static const struct adcxx1c_model _name ## _model = { \
> + .bits = (_bits),\
> + }
> +
> +DEFINE_ADCxx1C_MODEL(adc081c, 8);
> +DEFINE_ADCxx1C_MODEL(adc101c, 10);
> +DEFINE_ADCxx1C_MODEL(adc121c, 12);
As suggested below, I'd prefer these were elements of an array of such
structures
as it tends to lead to cleaner / more obvious code in my view.
> +
> static const struct iio_info adc081c_info = {
> .read_raw = adc081c_read_raw,
> .driver_module = THIS_MODULE,
> @@ -70,6 +98,7 @@ static int adc081c_probe(struct i2c_client *client,
> {
> struct iio_dev *iio;
> struct adc081c *adc;
> + struct adcxx1c_model *model = (struct adcxx1c_model*)id->driver_data;
> int err;
>
> if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_WORD_DATA))
> @@ -81,6 +110,7 @@ static int adc081c_probe(struct i2c_client *client,
>
> adc = iio_priv(iio);
> adc->i2c = client;
> + adc->bits = model->bits;
>
> adc->ref = devm_regulator_get(&client->dev, "vref");
> if (IS_ERR(adc->ref))
> @@ -124,7 +154,9 @@ static int adc081c_remove(struct i2c_client *client)
> }
>
> static const struct i2c_device_id adc081c_id[] = {
> - { "adc081c", 0 },
> + { "adc081c", (long)&adc081c_model },
> + { "adc101c", (long)&adc101c_model },
> + { "adc121c", (long)&adc121c_model },
Re: [PATCH v2 2/2] ti-adc081c: Initial triggered buffer support
On 04/04/16 19:21, Crestez Dan Leonard wrote:
> Using this requires software triggers like CONFIG_IIO_HRTIMER_TRIGGER.
>
> The device can be configured to do internal periodic sampling but does not
> offer some sort of interrupt on data ready. Interrupts can only trigger when
> values get out of a specific range.
>
> Signed-off-by: Crestez Dan Leonard
basically fine, but just use a fixed size allocation for your buffer in the
trigger handler.
> ---
> drivers/iio/adc/ti-adc081c.c | 63
> +---
> 1 file changed, 54 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/adc/ti-adc081c.c b/drivers/iio/adc/ti-adc081c.c
> index 3b3c656..d024df2 100644
> --- a/drivers/iio/adc/ti-adc081c.c
> +++ b/drivers/iio/adc/ti-adc081c.c
> @@ -24,6 +24,9 @@
> #include
>
> #include
> +#include
> +#include
> +#include
> #include
>
> struct adc081c {
> @@ -69,18 +72,31 @@ static int adc081c_read_raw(struct iio_dev *iio,
> return -EINVAL;
> }
>
> -static const struct iio_chan_spec adc081c_channel = {
> - .type = IIO_VOLTAGE,
> - .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
> - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> -};
> +#define ADCxx1C_CHAN(_bits) {\
> + .type = IIO_VOLTAGE,\
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .scan_type = { \
> + .sign = 'u',\
> + .realbits = (_bits),\
> + .storagebits = 16, \
> + .shift = 12 - (_bits), \
> + .endianness = IIO_CPU, \
> + }, \
> +}
>
> struct adcxx1c_model {
> + const struct iio_chan_spec* channels;
> int bits;
> };
>
> #define DEFINE_ADCxx1C_MODEL(_name, _bits) \
> + static const struct iio_chan_spec _name ## _channels[] = { \
> + ADCxx1C_CHAN((_bits)), \
> + IIO_CHAN_SOFT_TIMESTAMP(1), \
> + }; \
> static const struct adcxx1c_model _name ## _model = { \
> + .channels = _name ## _channels, \
> .bits = (_bits),\
> }
>
> @@ -88,11 +104,31 @@ DEFINE_ADCxx1C_MODEL(adc081c, 8);
> DEFINE_ADCxx1C_MODEL(adc101c, 10);
> DEFINE_ADCxx1C_MODEL(adc121c, 12);
>
> +#define ADC081C_NUM_CHANNELS 2
> +
> static const struct iio_info adc081c_info = {
> .read_raw = adc081c_read_raw,
> .driver_module = THIS_MODULE,
> };
>
> +static irqreturn_t adc081c_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct adc081c *data = iio_priv(indio_dev);
> + u16 buf[indio_dev->scan_bytes / 2];
Just use a fixed size that is beig enough for whatever you may
get. Here you need room for a word + an aligned 8 byte timestamp
so 16 bytes, or 8 u16s. It's not variable so don't let the compiler think
it is.
Also you shouldn't be accessing indio_dev->scan_bytes directly in a driver.
A long time back we spent a while pulling that idiom out of drivers as it
was causing a lot more trouble than the convenience was worth (can't
actually recall why now though!)
> + int ret;
> +
> + ret = i2c_smbus_read_word_swapped(data->i2c, REG_CONV_RES);
> + if (ret < 0)
> + goto out;
> + buf[0] = ret;
> + iio_push_to_buffers_with_timestamp(indio_dev, buf, iio_get_time_ns());
> +out:
> + iio_trigger_notify_done(indio_dev->trig);
> + return IRQ_HANDLED;
> +}
> +
> static int adc081c_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
> {
> @@ -125,18 +161,26 @@ static int adc081c_probe(struct i2c_client *client,
> iio->modes = INDIO_DIRECT_MODE;
> iio->info = &adc081c_info;
>
> - iio->channels = &adc081c_channel;
> - iio->num_channels = 1;
> + iio->channels = model->channels;
> + iio->num_channels = ADC081C_NUM_CHANNELS;
I'm not sure the define adds anything here! Kind of obvious what 2 means
anyway -
rather than it being a magic number :)
> +
> + err = iio_triggered_buffer_setup(iio, NULL, adc081c_trigger_handler,
> NULL);
> + if (err < 0) {
> + dev_err(&client->dev, "iio triggered buffer setup failed\n");
> + goto err_regulator_disable;
> + }
>
> err = iio_device_register(iio);
> if (err < 0)
> - goto regulator_disable;
> + goto err_buffer_cleanup;
>
> i2c_set_cli
Re: [PATCH v3] iio: imu: Add initial support for Bosch BMI160
On 06/04/16 15:58, Daniel Baluta wrote: > BMI160 is an Inertial Measurement Unit (IMU) which provides acceleration > and angular rate measurement. It also offers a secondary I2C interface > for connecting a magnetometer sensor (usually BMM160). > > Current driver offers support for accelerometer and gyroscope readings > via sysfs or via buffer interface using an external trigger (e.g. > hrtimer). Data is retrieved from IMU via I2C or SPI interface. > > Datasheet is at: > http://www.mouser.com/ds/2/783/BST-BMI160-DS000-07-786474.pdf > > Signed-off-by: Daniel Baluta I'm still a little unconvinced abou the data handling in the trigger_handler. Sample should be __le16 I think which would make it all rather more obvious. Jonathan > --- > Changes since v2: > * include to fix compile errors reported by > Kbuild test robot > > Changes since v1: > * addressed comments from Jonathan and Peter > * fixed Kconfig spelling > * shared bmi160_regmap_config between i2c and spi modules > * clarify timeouts unit (useconds) > * use sizeof(_le16) consistently > * 1 -> true > * clarify documentation references to datasheet > > drivers/iio/imu/Kconfig | 2 + > drivers/iio/imu/Makefile | 1 + > drivers/iio/imu/bmi160/Kconfig | 32 ++ > drivers/iio/imu/bmi160/Makefile | 6 + > drivers/iio/imu/bmi160/bmi160.h | 10 + > drivers/iio/imu/bmi160/bmi160_core.c | 594 > +++ > drivers/iio/imu/bmi160/bmi160_i2c.c | 72 + > drivers/iio/imu/bmi160/bmi160_spi.c | 63 > 8 files changed, 780 insertions(+) > create mode 100644 drivers/iio/imu/bmi160/Kconfig > create mode 100644 drivers/iio/imu/bmi160/Makefile > create mode 100644 drivers/iio/imu/bmi160/bmi160.h > create mode 100644 drivers/iio/imu/bmi160/bmi160_core.c > create mode 100644 drivers/iio/imu/bmi160/bmi160_i2c.c > create mode 100644 drivers/iio/imu/bmi160/bmi160_spi.c > > diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig > index 5e610f7..1f1ad41 100644 > --- a/drivers/iio/imu/Kconfig > +++ b/drivers/iio/imu/Kconfig > @@ -25,6 +25,8 @@ config ADIS16480 > Say yes here to build support for Analog Devices ADIS16375, ADIS16480, > ADIS16485, ADIS16488 inertial sensors. > > +source "drivers/iio/imu/bmi160/Kconfig" > + > config KMX61 > tristate "Kionix KMX61 6-axis accelerometer and magnetometer" > depends on I2C > diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile > index e1e6e3d..c71bcd3 100644 > --- a/drivers/iio/imu/Makefile > +++ b/drivers/iio/imu/Makefile > @@ -13,6 +13,7 @@ adis_lib-$(CONFIG_IIO_ADIS_LIB_BUFFER) += adis_trigger.o > adis_lib-$(CONFIG_IIO_ADIS_LIB_BUFFER) += adis_buffer.o > obj-$(CONFIG_IIO_ADIS_LIB) += adis_lib.o > > +obj-y += bmi160/ > obj-y += inv_mpu6050/ > > obj-$(CONFIG_KMX61) += kmx61.o > diff --git a/drivers/iio/imu/bmi160/Kconfig b/drivers/iio/imu/bmi160/Kconfig > new file mode 100644 > index 000..005c17c > --- /dev/null > +++ b/drivers/iio/imu/bmi160/Kconfig > @@ -0,0 +1,32 @@ > +# > +# BMI160 IMU driver > +# > + > +config BMI160 > + tristate > + select IIO_BUFFER > + select IIO_TRIGGERED_BUFFER > + > +config BMI160_I2C > + tristate "Bosch BMI160 I2C driver" > + depends on I2C > + select BMI160 > + select REGMAP_I2C > + help > + If you say yes here you get support for BMI160 IMU on I2C with > + accelerometer, gyroscope and external BMG160 magnetometer. > + > + This driver can also be built as a module. If so, the module will be > + called bmi160_i2c. > + > +config BMI160_SPI > + tristate "Bosch BMI160 SPI driver" > + depends on SPI > + select BMI160 > + select REGMAP_SPI > + help > + If you say yes here you get support for BMI160 IMU on SPI with > + accelerometer, gyroscope and external BMG160 magnetometer. > + > + This driver can also be built as a module. If so, the module will be > + called bmi160_spi. > diff --git a/drivers/iio/imu/bmi160/Makefile b/drivers/iio/imu/bmi160/Makefile > new file mode 100644 > index 000..10365e4 > --- /dev/null > +++ b/drivers/iio/imu/bmi160/Makefile > @@ -0,0 +1,6 @@ > +# > +# Makefile for Bosch BMI160 IMU > +# > +obj-$(CONFIG_BMI160) += bmi160_core.o > +obj-$(CONFIG_BMI160_I2C) += bmi160_i2c.o > +obj-$(CONFIG_BMI160_SPI) += bmi160_spi.o > diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h > new file mode 100644 > index 000..d2ae6ed > --- /dev/null > +++ b/drivers/iio/imu/bmi160/bmi160.h > @@ -0,0 +1,10 @@ > +#ifndef BMI160_H_ > +#define BMI160_H_ > + > +extern const struct regmap_config bmi160_regmap_config; > + > +int bmi160_core_probe(struct device *dev, struct regmap *regmap, > + const char *name, bool use_spi); > +void bmi160_core_remove(struct device *dev); > + > +#endif /* BMI160_H_ */ > diff --git a/drivers/iio/imu/b
Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly
> The lloop driver should be removed entirely - use the loop driver > instead. I talked with Andreas last week at our annual Lustre users group meeting about this. The reason I was told for existance is that some users were using files on a Lustre file system with the loop back device. The performance was really bad at the time so a lloop was developed to overcome those limitations. Its been a long time so perhaps its time to look at the default loop driver again to see if can perform now. If it doesn't we will go the route of reworking the lloop driver in the spirit of the cryptoloop device.
Re: [PATCH v2 27/30] iio: use parity32 in adxrs450
On 06/04/16 11:16, zengzhao...@163.com wrote: > From: Zhaoxiu Zeng > > Signed-off-by: Zhaoxiu Zeng Applied to the togreg branch of iio.git as you seem to have addressed Lars' comments. Thanks, Jonathan > --- > drivers/iio/gyro/adxrs450.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/gyro/adxrs450.c b/drivers/iio/gyro/adxrs450.c > index a330d42..307f55b 100644 > --- a/drivers/iio/gyro/adxrs450.c > +++ b/drivers/iio/gyro/adxrs450.c > @@ -109,7 +109,7 @@ static int adxrs450_spi_read_reg_16(struct iio_dev > *indio_dev, > mutex_lock(&st->buf_lock); > tx = ADXRS450_READ_DATA | (reg_address << 17); > > - if (!(hweight32(tx) & 1)) > + if (!parity32(tx)) > tx |= ADXRS450_P; > > st->tx = cpu_to_be32(tx); > @@ -145,7 +145,7 @@ static int adxrs450_spi_write_reg_16(struct iio_dev > *indio_dev, > mutex_lock(&st->buf_lock); > tx = ADXRS450_WRITE_DATA | (reg_address << 17) | (val << 1); > > - if (!(hweight32(tx) & 1)) > + if (!parity32(tx)) > tx |= ADXRS450_P; > > st->tx = cpu_to_be32(tx); >
Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly
On Sun, Apr 10, 2016 at 03:37:42PM +0100, James Simmons wrote: > > > The lloop driver should be removed entirely - use the loop driver > > instead. > > I talked with Andreas last week at our annual Lustre users group meeting > about this. The reason I was told for existance is that some users were > using files on a Lustre file system with the loop back device. The > performance was really bad at the time so a lloop was developed to > overcome those limitations. Its been a long time so perhaps its time > to look at the default loop driver again to see if can perform now. If > it doesn't we will go the route of reworking the lloop driver in the > spirit of the cryptoloop device. The loop driver now supports using AIO/DIO on any file systems that implements ->read_iter and ->write_iter. If lustre doesn't support those or doesn't have proper performance using them it should be addressed in the file system. Note that the dio mode in the loop device is not the default and you need to manually enabled it, keep that in mind when testing.
Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732
On Sun, 2016-04-10 at 11:35 +0200, Mike Galbraith wrote: > On Sun, 2016-04-10 at 05:44 +0200, Rafael J. Wysocki wrote: > > On Sat, Apr 9, 2016 at 6:39 PM, Mike Galbraith < > > umgwanakikb...@gmail.com> wrote: > > > > > > Hm, setting gov=performance, and taking the average of 3 30 second > > > interval PkgWatt samples as pipe-test runs.. > > > > > > 714KHz/28.03Ws = 25.46 > > > 877KHz/30.28Ws = 28.96 > > > > > > ..for pipe-test, the tradeoff look a bit more like red than green. > > > > Well, fair enough, but that's just pipe-test, and what about the > > people who don't see the performance gain and see the energy loss, > > like Doug? > > Perhaps Doug sees increased power because he's not throttling no_hz, > whereas I am, so he burns more power getting _to_ idle? Dunno, maybe > he'll try the attached. If it's a general case energy loser, so be it, > numbers talk, bs walks and all that ;-) And here are the rest of my numbers.. > tbench 1 2 4 8 > base 752 1283 2250 3362 > > select_idle_sibling() off > 735 1344 2080 2884 > delta .977 1.047 .924 .857 > > select_idle_sibling() on, 0c313cb20732 reverted > 816 1317 2240 3388 > delta 1.085 1.026 .995 1.007 vs base > delta 1.110 .979 1.076 1.174 vs off >(^hm) tbench 2 turboboost off base 1215 1.00 1215/32.24=37.68 revert1252 1.03 1252/35.82=34.95=loser tbench 2 throughput hm is apparently a turboboost oddity, and.. tbench (turboboost back on) power 1 2 4 8 base 23.88 37.41 54.64 62.25 revert 31.25 42.53 55.11 62.66 MB/s/Ws1 2 4 8 base 31.49 34.29 41.17 54.00 revert 26.11 30.96 40.64 54.06 ..while single pipe-test pair said green/green, tbench numbers say throughput green, but energy efficiency red across the board. -Mike
Re: [PATCH] nvme/host: Add missing blk_integrity tag_size + flags assignments
Does NVMe really force ATO=1? Sorry, didn't have much time to spend with that part of the spec.
Re: [PATCH v2 27/30] iio: use parity32 in adxrs450
On 04/10/2016 04:37 PM, Jonathan Cameron wrote: > On 06/04/16 11:16, zengzhao...@163.com wrote: >> From: Zhaoxiu Zeng >> >> Signed-off-by: Zhaoxiu Zeng > Applied to the togreg branch of iio.git as you seem to have addressed > Lars' comments. The whole series needs to go through the same tree since the new functions are introduced in the beginning.
Re: [PATCH v2 27/30] iio: use parity32 in adxrs450
On 10/04/16 15:41, Lars-Peter Clausen wrote: > On 04/10/2016 04:37 PM, Jonathan Cameron wrote: >> On 06/04/16 11:16, zengzhao...@163.com wrote: >>> From: Zhaoxiu Zeng >>> >>> Signed-off-by: Zhaoxiu Zeng >> Applied to the togreg branch of iio.git as you seem to have addressed >> Lars' comments. > > The whole series needs to go through the same tree since the new functions > are introduced in the beginning. Yeah, I just realized that when my build test failed! Acked-by: Jonathan Cameron > > -- > 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 >
Re: [PATCH v2 27/30] iio: use parity32 in adxrs450
On 10/04/16 16:13, Jonathan Cameron wrote: > On 10/04/16 15:41, Lars-Peter Clausen wrote: >> On 04/10/2016 04:37 PM, Jonathan Cameron wrote: >>> On 06/04/16 11:16, zengzhao...@163.com wrote: From: Zhaoxiu Zeng Signed-off-by: Zhaoxiu Zeng >>> Applied to the togreg branch of iio.git as you seem to have addressed >>> Lars' comments. >> >> The whole series needs to go through the same tree since the new functions >> are introduced in the beginning. > Yeah, I just realized that when my build test failed! > > Acked-by: Jonathan Cameron Backed out of the togreg branch of iio.git... oops and thanks Lars! >> >> -- >> 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-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH 1/1] iio: adc: Add driver for the TI INA3221 Triple Current/Voltage Monitor
On 04/10/2016 04:57 AM, Jonathan Cameron wrote: On 08/04/16 19:19, Andrew F. Davis wrote: The INA3221 is a three-channel, high-side current and bus voltage monitor with an I2C and SMBUS compatible interface. Signed-off-by: Andrew F. Davis Hi Andrew, My immediate thought on this one is whether it would be better off in hwmon. I'm not convinced either way from a quick glance at the data sheet, but the question needs to be addressed. It looks like a typical hardware monitoring device to me. It's not exactly a clean fit for the IIO ABI either at the moment though I think some elements of that could be easily sorted out. The key think in my mind is to look at what is actually being measured rather than assume all the external components will be as the datasheet assumes them to be... + where do the alert lines actually go? In a typical application they would connect to interrupts or to gpio pins. They could also trigger some direct action, such as turning on a fan, though that is unlikely nowadays. The 'critical' pin might sometimes trigger a system reset. Some more comments inline. Guenter Jonathan --- .../ABI/testing/sysfs-bus-iio-adc-ina3221 | 23 ++ drivers/iio/adc/Kconfig| 7 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ina3221.c | 417 + 4 files changed, 448 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 create mode 100644 drivers/iio/adc/ina3221.c diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 b/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 new file mode 100644 index 000..bbe4f8c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ina3221 @@ -0,0 +1,23 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_shunt_(raw|scale) +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_bus_(raw|scale) +Date: April 2016 +KernelVersion: 4.7 +Contact: Andrew F. Davis +Description: + Shunt and Bus voltage for each channel. Units etc need specifying or at least a reference to the main in_voltageY_raw docs etc. These are really completely separate measurements be it differential measurements where the + on one is the - on the other (second is really a unipolar measurement as it's relative to 0). I wonder if we are better off supporting them as such so define this device as having the channels. in_voltage1-voltage0_raw (shunt voltage 1) in_voltage0_raw (bus voltage 1) in_voltage3-voltage2_raw (shunt voltage 2) in_voltage2_raw (bus voltage 2) in_voltage5-voltage4_raw (shunt voltage 3) in_voltage4_raw That I think reflects the actual measuring options, without applying assumptions on what is connected to them. Yes the datasheet says you should put a shunt between the first two connections and the load between the second connection and the 0 volt line, but I can't see anything preventing this being used differently... Shunt voltage (or voltage difference) has a LSB of 40uV. Using it for anything else but current measurement doesn't really make much sense. I would report it not as voltage but as current, but that is from my filtered hwmon point of view, so maybe it doesn't really apply here. + +What: /sys/bus/iio/devices/iio:deviceX/shunt_integration_time[_available] +What: /sys/bus/iio/devices/iio:deviceX/bus_integration_time[_available] +Date: April 2016 +KernelVersion: 4.7 +Contact: Andrew F. Davis +Description: + Shunt and Bus integration time for each channel. I'd keep these tightly associated with the channels as then they become standard abi elements, just for channels with extended names. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_shunt_critical_(raw|scale) +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_shunt_warning_(raw|scale) +Date: April 2016 +KernelVersion: 4.7 +Contact: Andrew F. Davis +Description: + Shunt voltage critical and warning trigger levels. This is why I think this may really belong in hwmon. The way you currently have this done is a bodge on the relevant IIO interfaces. If there is good reason to look at multiple equivalent event types on a given channel in IIO we can look at adding that support to the core. This is a lot more common in explicit hardware monitoring chips than in more general ADCs. Also I see nothing in the driver that is actually detecting if these conditions have been passed? If that is assumed to be a problem for external hardware then it should be clearly documented as such. diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index af4aea7..d713c9c 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -232,6 +232,13 @@ config IMX7D_ADC This driver can also be built as a module. If so, the module will be called imx7d_adc. +config INA3
[RFC] proc: meminfo: Replace kB with KiB in output
Hi! I was helping somebody write some documentation about meminfo and I started explaining that memory values are mostly multiples of 1024 and that binary prefixes are preferred. The output of /proc/meminfo is hardcoded to be in 'kB' which should mean 1000 bytes (one kilobytes). But judging by the definition of the K() macro it is based on page size which is a multiple of 1024. So the values are actually kibibytes (KiB). Therefore we got stuck with writing the documentation because there is a discrepancy between the output and the code. If I am mistaken, please correct me and ignore the rest of the message. I know there is a big debate about using binary prefixes versus using the de facto definitions based on powers of 10. The technically correct usage in this case would be KiB but I am thinking that nobody changed this because it might break things. Therefore I am writing this email with the main purpose of finding out what is the reason what the output is as it is. Is it because changing it would break userspace tools that read /proc/meminfo ? Or is it because the technical correctness of the binary prefix side in the debate lost? Or just because nobody bothered fixing this? If the last reason is the answer I would like to take the first step in addressing it with this RFC. Thank you!
[PATCH] proc: meminfo: Replace kB with KiB in output
Current values are based on multiples of 1024 (powers of 2) which means that the values in meminfo are not kilobytes (1000 bytes) but kibibytes (1024 bytes). The correct prefix for that would be 'Ki' so the output should be 'KiB'. Signed-off-by: Alexandru Juncu --- fs/proc/meminfo.c | 90 +++ 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c index 8372046..5f0015e 100644 --- a/fs/proc/meminfo.c +++ b/fs/proc/meminfo.c @@ -33,7 +33,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v) int lru; /* - * display in kilobytes. + * display in kibibytes. */ #define K(x) ((x) << (PAGE_SHIFT - 10)) si_meminfo(&i); @@ -54,61 +54,61 @@ static int meminfo_proc_show(struct seq_file *m, void *v) * Tagged format, for easy grepping and expansion. */ seq_printf(m, - "MemTotal: %8lu kB\n" - "MemFree:%8lu kB\n" - "MemAvailable: %8lu kB\n" - "Buffers:%8lu kB\n" - "Cached: %8lu kB\n" - "SwapCached: %8lu kB\n" - "Active: %8lu kB\n" - "Inactive: %8lu kB\n" - "Active(anon): %8lu kB\n" - "Inactive(anon): %8lu kB\n" - "Active(file): %8lu kB\n" - "Inactive(file): %8lu kB\n" - "Unevictable:%8lu kB\n" - "Mlocked:%8lu kB\n" + "MemTotal: %8lu KiB\n" + "MemFree:%8lu KiB\n" + "MemAvailable: %8lu KiB\n" + "Buffers:%8lu KiB\n" + "Cached: %8lu KiB\n" + "SwapCached: %8lu KiB\n" + "Active: %8lu KiB\n" + "Inactive: %8lu KiB\n" + "Active(anon): %8lu KiB\n" + "Inactive(anon): %8lu KiB\n" + "Active(file): %8lu KiB\n" + "Inactive(file): %8lu KiB\n" + "Unevictable:%8lu KiB\n" + "Mlocked:%8lu KiB\n" #ifdef CONFIG_HIGHMEM - "HighTotal: %8lu kB\n" - "HighFree: %8lu kB\n" - "LowTotal: %8lu kB\n" - "LowFree:%8lu kB\n" + "HighTotal: %8lu KiB\n" + "HighFree: %8lu KiB\n" + "LowTotal: %8lu KiB\n" + "LowFree:%8lu KiB\n" #endif #ifndef CONFIG_MMU - "MmapCopy: %8lu kB\n" + "MmapCopy: %8lu KiB\n" #endif - "SwapTotal: %8lu kB\n" - "SwapFree: %8lu kB\n" - "Dirty: %8lu kB\n" - "Writeback: %8lu kB\n" - "AnonPages: %8lu kB\n" - "Mapped: %8lu kB\n" - "Shmem: %8lu kB\n" - "Slab: %8lu kB\n" - "SReclaimable: %8lu kB\n" - "SUnreclaim: %8lu kB\n" - "KernelStack:%8lu kB\n" - "PageTables: %8lu kB\n" + "SwapTotal: %8lu KiB\n" + "SwapFree: %8lu KiB\n" + "Dirty: %8lu KiB\n" + "Writeback: %8lu KiB\n" + "AnonPages: %8lu KiB\n" + "Mapped: %8lu KiB\n" + "Shmem: %8lu KiB\n" + "Slab: %8lu KiB\n" + "SReclaimable: %8lu KiB\n" + "SUnreclaim: %8lu KiB\n" + "KernelStack:%8lu KiB\n" + "PageTables: %8lu KiB\n" #ifdef CONFIG_QUICKLIST - "Quicklists: %8lu kB\n" + "Quicklists: %8lu KiB\n" #endif - "NFS_Unstable: %8lu kB\n" - "Bounce: %8lu kB\n" - "WritebackTmp: %8lu kB\n" - "CommitLimit:%8lu kB\n" - "Committed_AS: %8lu kB\n" - "VmallocTotal: %8lu kB\n" - "VmallocUsed:%8lu kB\n" - "VmallocChunk: %8lu kB\n" + "NFS_Unstable: %8lu KiB\n" + "Bounce: %8lu KiB\n" + "WritebackTmp: %8lu KiB\n" + "CommitLimit:%8lu KiB\n" + "Committed_AS: %8lu KiB\n" + "VmallocTotal: %8lu KiB\n" + "VmallocUsed:%8lu KiB\n" + "VmallocChunk: %8lu KiB\n" #ifdef CONFIG_MEMORY_FAILURE - "HardwareCorrupted: %5lu kB\n" + "HardwareCorrupted: %5lu KiB\n" #endif #ifdef CONFIG_TRANSPARENT_HUGEPAGE - "AnonHugePages: %8lu kB\n" + "AnonHugePages: %8lu KiB\n" #endif #ifdef CONFIG_CMA - "CmaTotal: %8lu kB\n" - "CmaFree:%8lu kB\n" + "CmaTotal: %8lu KiB\n" +
Re: [PATCH v3 13/19] drm: sun4i: Add DT bindings documentation
Hi Rob, On Tue, Mar 29, 2016 at 01:50:35PM -0500, Rob Herring wrote: > On Tue, Mar 29, 2016 at 12:33:14PM +0200, Maxime Ripard wrote: > > Hi Rob, > > > > On Fri, Mar 25, 2016 at 09:11:18AM -0500, Rob Herring wrote: > > > On Wed, Mar 23, 2016 at 05:38:36PM +0100, Maxime Ripard wrote: > > > > The display pipeline of the Allwinner A10 is involving several loosely > > > > coupled components. > > > > > > > > Add a documentation for the bindings. > > > > > > > > Signed-off-by: Maxime Ripard > > > > --- > > > > .../bindings/display/sunxi/sun4i-drm.txt | 254 > > > > + > > > > 1 file changed, 254 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > new file mode 100644 > > > > index ..378edb919eae > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > @@ -0,0 +1,254 @@ > > > > +Allwinner A10 Display Pipeline > > > > +== > > > > + > > > > +The Allwinner A10 Display pipeline is composed of several components > > > > +that are going to be documented below: > > > > + > > > > +TV Encoder > > > > +-- > > > > + > > > > +The TV Encoder supports the composite and VGA output. It is one end of > > > > +the pipeline. > > > > + > > > > +Required properties: > > > > + - compatible: value should be "allwinner,sun4i-a10-tv-encoder". > > > > + - reg: base address and size of memory-mapped region > > > > + - clocks: the clocks driving the TV encoder > > > > + - resets: phandle to the reset controller driving the encoder > > > > + > > > > +- ports: A ports node with endpoint definitions as defined in > > > > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > > > > + first port should be the input endpoint. > > > > + > > > > +TCON > > > > + > > > > + > > > > +The TCON acts as a timing controller for RGB, LVDS and TV interfaces. > > > > + > > > > +Required properties: > > > > + - compatible: value should be "allwinner,sun5i-a13-tcon". > > > > + - reg: base address and size of memory-mapped region > > > > + - interrupts: interrupt associated to this IP > > > > + - clocks: phandles to the clocks feeding the TCON. Three are needed: > > > > + - 'ahb': the interface clocks > > > > + - 'tcon-ch0': The clock driving the TCON channel 0 > > > > + - 'tcon-ch1': The clock driving the TCON channel 1 > > > > + - resets: phandles to the reset controllers driving the encoder > > > > + - "lcd": the reset line for the TCON channel 0 > > > > + > > > > + - clock-names: the clock names mentioned above > > > > + - reset-names: the reset names mentioned above > > > > + - clock-output-names: Name of the pixel clock created > > > > + > > > > +- ports: A ports node with endpoint definitions as defined in > > > > + Documentation/devicetree/bindings/media/video-interfaces.txt. The > > > > + first port should be the input endpoint, the second one the output > > > > > > The example shows 2 output endpoints. Your diagram shows up to 4 > > > outputs. The number should be how ever many could coexist in a given h/w > > > design. In other words, I'm assuming all 4 can't be used simultaneously, > > > but can all 4 be wired up in a h/w design and switched in s/w? > > > > > > Just be clear on the numbering. > > > > Yes, each TCON has two channels, the first one being usable for > > RGB/LVDS, the second one for TV/VGA. HDMI is basically implemented > > using an in-SoC RGB-to-HDMI bridge, so it would use the first channel > > as well. > > So I think you should have 2 ports (1 per channel) and then 2 endpoints > for 1st (RGB/LVDS/ExtBridge and HDMI) and 1 endpoint (TV/VGA) for 2nd > port. Yes, that makes sense. > > I don't see how a particular design could use several devices on the > > first channel, because they would share the same timings, and I don't > > really see how it would work out. > > > > > > + > > > > +Endpoints optional property: > > > > + - allwinner,panel: boolean to indicate that the endpoint is a panel > > > > > > This can be determined by the endpoint not being TV Encoder (or HDMI). > > > > It wouldn't really scale if you start to consider the bridges > > too. Then, you would have to duplicate and maintain a list of all the > > bridges supported in Linux and a list of all the panels supported in > > Linux, and try to match that to see if it's a panel, a bridge or an > > element of our pipeline. > > So my concern is that no one else has needed this, so why do you? Based > on the above, you know that a panel is always connected to port 0, > endpoint 0. If it is an external bridge instead, then that can be > determined when the bridge driver is bound. Indeed, I'll try to use the panel and bridge API to retrieve the panel and bridges
Re: [PATCH v3 01/19] clk: composite: Add unregister function
Hi Stephen, Mike, On Wed, Mar 23, 2016 at 05:38:24PM +0100, Maxime Ripard wrote: > The composite clock didn't have any unregistration function, which forced > us to use clk_unregister directly on it. > > While it was already not great from an API point of view, it also meant > that we were leaking the clk_composite structure allocated in > clk_register_composite. > > Add a clk_unregister_composite function to fix this. > > Signed-off-by: Maxime Ripard Any comment on this one ? (and the other clock patches) Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64
On Sun, Apr 10, 2016 at 03:04:51PM +0100, James Simmons wrote: > > > This patch was shown not to work. I just haven't removed it from opensuse > > yet. > > Its been running in our production tree as well for some time. Guess that > change is a noop. In any case we have been discussing redoing the lloop > driver anyways. Just need to find the cycles. Why do you need this driver? I know Christoph has pointed out many times that it should just be dropped as it's not needed. And should I drop this patch from the series? thanks, greg k-h
Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732
On Sat, 2016-04-09 at 14:31 +0200, Rafael J. Wysocki wrote: > On Sat, Apr 9, 2016 at 1:07 PM, Peter Zijlstra > wrote: > > On Fri, Apr 08, 2016 at 10:59:59PM +0200, Rafael J. Wysocki wrote: > > > On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote: > > > > On Fri, 2016-04-08 at 08:45 +0200, Peter Zijlstra wrote: > > > > > > > > > Cute, I thought you used governor=performance for your runs? > > > > > > > > I do, and those numbers are with it thus set. > > > > > > Well, this is a trade-off. > > > > > > 4.5 introduced a power regression here so this one goes back to > > > the previous > > > state of things. > > > > Just for my elucidation; how can gov=performance have a 'power' > > regression? > > Because of what is used as the "default" idle state most of the time. > > C1 was used before 4.5 and that changed to polling in 4.5. Should the default idle state not then be governor dependent? When I set gov=performance, I'm expecting box to go just as fast as it can go without melting. Does polling risk CPU -> lava conversion? -Mike
Re: [PATCH 1/2] char: PC rtc: replace blacklist with whitelist
Arnd, On 02/03/2016 at 11:22:04 +0100, Geert Uytterhoeven wrote : > On Wed, Mar 2, 2016 at 10:48 AM, Arnd Bergmann wrote: > > Every new architecture has to add itself to the growing list of those > > that do not support the legacy PC RTC driver. > > > > This replaces the long list of architectures that don't support it > > with a shorter list of those that do. > > > > The list is taken from those architectures that have a non-empty > > asm/mc146818rtc.h header file and were not explicitly blacklisted. > > M68K was blacklisted... > > > Signed-off-by: Arnd Bergmann > > --- > > drivers/char/Kconfig | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig > > index a043107da2af..9716bc36495a 100644 > > --- a/drivers/char/Kconfig > > +++ b/drivers/char/Kconfig > > @@ -279,8 +279,7 @@ if RTC_LIB=n > > > > config RTC > > tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)" > > - depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV \ > > - && !ARM && !SUPERH && !S390 && !AVR32 && !BLACKFIN > > && !UML > > + depends on ALPHA || M32R || M68K || MIPS || MN10300 || PPC || X86 > > ... so please drop it here. > Do you plan to resend that one? -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Re: [PATCH 13/17] staging: lustre: lloop: Fix build failure on ppc64
> > > This patch was shown not to work. I just haven't removed it from opensuse > > > yet. > > > > Its been running in our production tree as well for some time. Guess that > > change is a noop. In any case we have been discussing redoing the lloop > > driver anyways. Just need to find the cycles. > > Why do you need this driver? I know Christoph has pointed out many > times that it should just be dropped as it's not needed. Please don't drop this driver just yet. The reason we kept it was for the DIO support that the loop back device lacked earlier. We need to do some testing to make sure the loop can completely replace this driver. > And should I drop this patch from the series? Yes since it is a noop. No other patches are dependent on it.
Re: [PATCH 08/27] staging: lustre: avoid to use bio->bi_vcnt directly
> On Sun, Apr 10, 2016 at 03:37:42PM +0100, James Simmons wrote: > > > > > The lloop driver should be removed entirely - use the loop driver > > > instead. > > > > I talked with Andreas last week at our annual Lustre users group meeting > > about this. The reason I was told for existance is that some users were > > using files on a Lustre file system with the loop back device. The > > performance was really bad at the time so a lloop was developed to > > overcome those limitations. Its been a long time so perhaps its time > > to look at the default loop driver again to see if can perform now. If > > it doesn't we will go the route of reworking the lloop driver in the > > spirit of the cryptoloop device. > > The loop driver now supports using AIO/DIO on any file systems that > implements ->read_iter and ->write_iter. If lustre doesn't support > those or doesn't have proper performance using them it should be > addressed in the file system. > > Note that the dio mode in the loop device is not the default and you > need to manually enabled it, keep that in mind when testing. This is excellent news. The only sad thing is that most lustre users are running distros that use kernels before the AIO/DIO enhancements were landed :-( We will have to keep a copy around for those guys. But first I need to test the performance of the loop back driver this week before this can be dropped.
Commit 'sched/cpuacct: Split usage accounting into user_usage and sys_usage' causing crashes
Hi, your commit 'sched/cpuacct: Split usage accounting into user_usage and sys_usage' in -next causes crashes with several of my qemu tests (mac99, q3beige). Reverting the patch fixes the problem. Details and complete logs are available at http://kerneltests.org/builders/qemu-ppc-next The scripts are published at https://github.com/groeck/linux-build-test/tree/master/rootfs/ppc Crash log and bisect log are attached. Guenter --- Crash log: [ ... ] ftrace: allocating 20986 entries in 62 pages Unable to handle kernel paging request for data at address 0x0084 Faulting instruction address: 0xc0067188 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT PowerMac Modules linked in: CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.6.0-rc2-next-20160408-yocto-standard #1 task: c78d0e00 ti: c78e8000 task.ti: c78e8000 NIP: c0067188 LR: c005c0d0 CTR: c005cf84 REGS: c78e9da0 TRAP: 0300 Not tainted (4.6.0-rc2-next-20160408-yocto-standard) MSR: 1032 CR: 82040002 XER: DAR: 0084 DSISR: 4000 GPR00: c005c0d0 c78e9e50 c78d0e00 c78d0e00 000a25f0 0037ecae GPR08: 0027ecae 2208 c004decc GPR16: GPR24: 0001 c78d0e00 c0918580 c78d0e30 c78d0e00 000a25f0 NIP [c0067188] cpuacct_charge+0x2c/0x90 LR [c005c0d0] update_curr+0x110/0x250 Call Trace: [c78e9e70] [c005c0d0] update_curr+0x110/0x250 [c78e9ea0] [c005d048] dequeue_task_fair+0xc4/0x27c [c78e9ed0] [c06c67d4] __schedule+0x338/0x770 [c78e9f00] [c06c6c54] schedule+0x48/0xb8 [c78e9f10] [c004e070] kthreadd+0x1a4/0x1dc [c78e9f40] [c0010540] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 4bd0 7c0802a6 90010004 6000 9421ffe0 7c0802a6 bf810010 90010024 81230cb4 7c7d1b78 7cdf3378 7cbe2b78 <83890084> 4800fbfd 813d047c 6b9c4000 ---[ end trace dc8fa200cb88537f ]--- --- bisect: # bad: [6e5921edae25005c5c25a79bb2ff5335650c1b66] Add linux-next specific files # for 20160408 # good: [9735a22799b9214d17d3c231fe377fc852f042e9] Linux 4.6-rc2 git bisect start 'HEAD' 'v4.6-rc2' # good: [e61201ac50d9599aef64e8885d6bfa5b35d574d7] Merge remote-tracking branch # 'mac80211-next/master' git bisect good e61201ac50d9599aef64e8885d6bfa5b35d574d7 # bad: [5c4015574ec4d63b7d3a9efbd8b77f90bcac88be] Merge remote-tracking branch # 'usb-chipidea-next/ci-for-usb-next' git bisect bad 5c4015574ec4d63b7d3a9efbd8b77f90bcac88be # good: [35fda07ad91c8d46253f6dd262800a747adcede9] Merge remote-tracking branch # 'sound-asoc/for-next' git bisect good 35fda07ad91c8d46253f6dd262800a747adcede9 # good: [a2089aa1dcd0a33b8eb67d8db0e07f859b986e04] Merge remote-tracking branch # 'spi/for-next' git bisect good a2089aa1dcd0a33b8eb67d8db0e07f859b986e04 # bad: [129f0d75057f9e78ad70e3e01f6c9edbc7de553c] Merge remote-tracking branch # 'irqchip/irqchip/for-next' git bisect bad 129f0d75057f9e78ad70e3e01f6c9edbc7de553c # bad: [9338637e6e2256ac26ac75391dc1349fb492d7c6] Merge branch 'x86/asm' git bisect bad 9338637e6e2256ac26ac75391dc1349fb492d7c6 # good: [66d219014a4ee47ad4ca2b9db5fe6547353e2a56] perf/x86/intel/pt: Move # transaction start/stop to PMU start/stop callbacks git bisect good 66d219014a4ee47ad4ca2b9db5fe6547353e2a56 # good: [5367d2a3279cd7aa40535efa526fe936ec24528d] Merge branch 'mm/urgent' git bisect good 5367d2a3279cd7aa40535efa526fe936ec24528d # bad: [2b8c41daba327c633228169e8bd8ec067ab443f8] sched/fair: Initiate a new # task's util avg to a bounded value git bisect bad 2b8c41daba327c633228169e8bd8ec067ab443f8 # bad: [d02c071183e1c01a76811c878c8a52322201f81f] sched/fair: Reset # nr_balance_failed after active balancing git bisect bad d02c071183e1c01a76811c878c8a52322201f81f # bad: [d740037fac7052e49450f6fa1454f1144a103b55] sched/cpuacct: Split usage # accounting into user_usage and sys_usage git bisect bad d740037fac7052e49450f6fa1454f1144a103b55 # good: [5ca3726af7f66a8cc71ce4414cfeb86deb784491] sched/cpuacct: Show all # possible CPUs in cpuacct output git bisect good 5ca3726af7f66a8cc71ce4414cfeb86deb784491 # first bad commit: [d740037fac7052e49450f6fa1454f1144a103b55] sched/cpuacct: # Split usage accounting into user_usage and sys_usage
[PATCH] Bluetooth: Deinline large functions
Fastest existing Bluetooth standard's top speed is 2.4 MB/s.
It is way off from being CPU limited, no need to squeeze
last few cycles by excessive inlining.
This patch delinlines the following functions:
hci_conn_hash_lookup_handle: 345 bytes, 39 calls
hci_conn_hash_lookup_ba: 372 bytes, 36 calls
hci_conn_hash_lookup_le: 382 bytes, 8 calls
hci_conn_hash_lookup_state: 356 bytes, 3 calls
hci_lookup_le_connect: 378 bytes, 7 calls
hci_conn_drop: 186 bytes, 30 calls
hci_connect_cfm: 121 bytes, 15 calls
hci_disconn_cfm: 121 bytes, 2 calls
hci_auth_cfm: 156 bytes, 2 calls
hci_encrypt_cfm: 156 bytes, 3 calls
Size reduction is about 40k:
text data bss dec hex filename
95943139 20860256 35991552 152794947 91b7743 vmlinux_before
95903714 20860256 35991552 152755522 91add42 vmlinux
Signed-off-by: Denys Vlasenko
CC: Johan Hedberg
CC: linux-blueto...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
include/net/bluetooth/hci_core.h | 219 +++
net/bluetooth/hci_core.c | 211 +
2 files changed, 227 insertions(+), 203 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index d4f82ed..0cd798e 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -761,108 +761,20 @@ static inline __u8 hci_conn_lookup_type(struct hci_dev
*hdev, __u16 handle)
return type;
}
-static inline struct hci_conn *hci_conn_hash_lookup_handle(struct hci_dev
*hdev,
- __u16 handle)
-{
- struct hci_conn_hash *h = &hdev->conn_hash;
- struct hci_conn *c;
-
- rcu_read_lock();
-
- list_for_each_entry_rcu(c, &h->list, list) {
- if (c->handle == handle) {
- rcu_read_unlock();
- return c;
- }
- }
- rcu_read_unlock();
-
- return NULL;
-}
-
-static inline struct hci_conn *hci_conn_hash_lookup_ba(struct hci_dev *hdev,
- __u8 type, bdaddr_t *ba)
-{
- struct hci_conn_hash *h = &hdev->conn_hash;
- struct hci_conn *c;
-
- rcu_read_lock();
-
- list_for_each_entry_rcu(c, &h->list, list) {
- if (c->type == type && !bacmp(&c->dst, ba)) {
- rcu_read_unlock();
- return c;
- }
- }
-
- rcu_read_unlock();
-
- return NULL;
-}
-
-static inline struct hci_conn *hci_conn_hash_lookup_le(struct hci_dev *hdev,
- bdaddr_t *ba,
- __u8 ba_type)
-{
- struct hci_conn_hash *h = &hdev->conn_hash;
- struct hci_conn *c;
+struct hci_conn *hci_conn_hash_lookup_handle(struct hci_dev *hdev,
+ __u16 handle);
- rcu_read_lock();
-
- list_for_each_entry_rcu(c, &h->list, list) {
- if (c->type != LE_LINK)
- continue;
-
- if (ba_type == c->dst_type && !bacmp(&c->dst, ba)) {
- rcu_read_unlock();
- return c;
- }
- }
-
- rcu_read_unlock();
-
- return NULL;
-}
-
-static inline struct hci_conn *hci_conn_hash_lookup_state(struct hci_dev *hdev,
- __u8 type, __u16 state)
-{
- struct hci_conn_hash *h = &hdev->conn_hash;
- struct hci_conn *c;
-
- rcu_read_lock();
-
- list_for_each_entry_rcu(c, &h->list, list) {
- if (c->type == type && c->state == state) {
- rcu_read_unlock();
- return c;
- }
- }
-
- rcu_read_unlock();
-
- return NULL;
-}
-
-static inline struct hci_conn *hci_lookup_le_connect(struct hci_dev *hdev)
-{
- struct hci_conn_hash *h = &hdev->conn_hash;
- struct hci_conn *c;
-
- rcu_read_lock();
+struct hci_conn *hci_conn_hash_lookup_ba(struct hci_dev *hdev,
+ __u8 type, bdaddr_t *ba);
- list_for_each_entry_rcu(c, &h->list, list) {
- if (c->type == LE_LINK && c->state == BT_CONNECT &&
- !test_bit(HCI_CONN_SCANNING, &c->flags)) {
- rcu_read_unlock();
- return c;
- }
- }
+struct hci_conn *hci_conn_hash_lookup_le(struct hci_dev *hdev,
+ bdaddr_t *ba,
+ __u8 ba_type);
- rcu_read_unlock();
+struct hci_conn *hci_conn_hash_lookup_state(struct hci_dev *hdev,
+ __u8 type, __u16 state);
- return NULL;
-}
+struct hci_conn *hci_lookup_le_connect(struct hci_dev *hdev);
int hci_disconnect(struct
Re: [PATCH v5 0/2] power: reset: support for Atmel alternative Shutdown Controller
Hi, On Wed, Mar 16, 2016 at 02:19:48PM +0100, Nicolas Ferre wrote: > This is a series to add driver for a new Atmel Shutdown Controller. This new > IP > is extensible and some features will be added later (see the TODO section). > Its extensible nature led to write a new binding so that wake-up sources can > be > described easily. Thanks, queued. -- Sebastian signature.asc Description: PGP signature
Re: [patch] power/max8925: freeing wrong variable
Hi, On Fri, Mar 18, 2016 at 08:40:16AM +0300, Dan Carpenter wrote: > We were freeing "info->battery" instead of "info->usb", which leads to > an OOps and a resource leak. > > The labels were wonky, "out_battery" did release the battery but out_usb > did not release usb. I was introducing a call to free usb so it sort > conflicted with existing misleading name. I renamed them. > > Signed-off-by: Dan Carpenter Thanks, queued. -- Sebastian signature.asc Description: PGP signature
Re: [patch] power: ipaq-micro-battery: freeing the wrong variable
Hi, On Fri, Mar 18, 2016 at 12:00:51PM +0300, Dan Carpenter wrote: > We accidentally free "micro_ac_power" which is an error pointer and it > leads to an oops. We intended to free "micro_batt_power". Thanks, queued. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] sbs-battery: fix power status when battery charging near dry
Hi, On Wed, Apr 06, 2016 at 10:32:25AM +0800, YH Huang wrote: > POWER_SUPPLY_STATUS_NOT_CHARGING is used for AC connected, but > battery not charging (e.g. because battery temperature is out > of acceptable range). > > When battery is charging near dry and BATTERY_FULL_DISCHARGED is set, > it is wrong to set as POWER_SUPPLY_STATUS_NOT_CHARGING. > Just use BATTERY_DISCHARGING to decide the power supply status is > discharging or charging. Thanks, queued. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] Bluetooth: Deinline large functions
On Sun, 2016-04-10 at 18:24 +0200, Denys Vlasenko wrote: > Fastest existing Bluetooth standard's top speed is 2.4 MB/s. > It is way off from being CPU limited, no need to squeeze > last few cycles by excessive inlining. > > This patch delinlines the following functions: > > hci_conn_hash_lookup_handle: 345 bytes, 39 calls > hci_conn_hash_lookup_ba: 372 bytes, 36 calls > hci_conn_hash_lookup_le: 382 bytes, 8 calls > hci_conn_hash_lookup_state: 356 bytes, 3 calls > hci_lookup_le_connect: 378 bytes, 7 calls > hci_conn_drop: 186 bytes, 30 calls > hci_connect_cfm: 121 bytes, 15 calls > hci_disconn_cfm: 121 bytes, 2 calls > hci_auth_cfm: 156 bytes, 2 calls > hci_encrypt_cfm: 156 bytes, 3 calls > > Size reduction is about 40k: > > text data bss dec hex filename > 95943139 20860256 35991552 152794947 91b7743 vmlinux_before > 95903714 20860256 35991552 152755522 91add42 vmlinux Hello Denys While removing unnecessary inlines is generally a good thing, for extremely low power embedded systems like a coin-battery operated bicycle computer or a heart rate monitor, this might cause a throughput reduction. Also, the size decrease for a defconfig should be quite a bit smaller than this. Can you please also show the size decrease when done with a defconfig with bluetooth support? And for these types of patches in general, please add a defconfig size reduction to the commit message. This is an x86-64 defconfig with bluetooth with and without this patch: $ size vmlinux.defconfig.* text data bss dec hex filename 102144144313816 1097728 15625958 ee6ee6 vmlinux.defconfig.new 102240144313816 1097728 15635558 ee9466 vmlinux.defconfig.old ~10k total
Schönen Tag
Schönen Tag Dies ist die Santander Consumer Finance, wir Darlehen Zinssatz von 2% für beide Unternehmen Darlehen und persönliche Darlehen bieten für Ihr Projekt und die individuellen Bedürfnisse Füllen Sie das Formular aus, wenn interessiert Vollständiger Name: Geschlecht: Land: Erforderliche Kreditbetrag : Dauer: Zweck des Darlehens: Eine schnelle Reaktion ist erforderlich Mit freundlichen Grüßen Antonio Jefferson
