[tip:x86/urgent] MAINTAINERS: Add me as x86 VDSO submaintainer
Commit-ID: f0905c5a32ce6e9b743b4d9c70e53d1ce447852d Gitweb: http://git.kernel.org/tip/f0905c5a32ce6e9b743b4d9c70e53d1ce447852d Author: Andy Lutomirski AuthorDate: Fri, 12 Dec 2014 16:25:47 -0800 Committer: Ingo Molnar CommitDate: Sun, 14 Dec 2014 08:47:22 +0100 MAINTAINERS: Add me as x86 VDSO submaintainer Here goes... :) Signed-off-by: Andy Lutomirski Acked-by: Thomas Gleixner Link: http://lkml.kernel.org/r/1042001e502f8e0deb0edfeeac209b68378650cf.1418430292.git.l...@amacapital.net Signed-off-by: Ingo Molnar --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c444907..7a54fa8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10295,6 +10295,13 @@ L: linux-e...@vger.kernel.org S: Maintained F: arch/x86/kernel/cpu/mcheck/* +X86 VDSO +M: Andy Lutomirski +L: linux-kernel@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vdso +S: Maintained +F: arch/x86/vdso/ + XC2028/3028 TUNER DRIVER M: Mauro Carvalho Chehab L: linux-me...@vger.kernel.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: question about the luto-misc tree
On Dec 13, 2014 10:58 PM, "Stephen Rothwell" wrote: > > Hi Andy, > > The luto-misc tree seems to have a whole series of commits in it that > have just bee removed from the rcu tree ... You really have to be very > careful if you base your work on a tree that is regularly rebased. Hmm. They were there a couple days ago. Paul, what should I do about this? I only need the one NMI nesting change for the stuff in luto/next. > > I also wonder if the other commits in that tree are destined for > v3.19? If they are for v3.20, then they should not be in linux-next > until after v3.19-rc1 has been released. They're for 3.20. I'll drop the whole series from the next branch for now. --Andy > -- > Cheers, > Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible regression with commit 52221610d
On Tue, Nov 4, 2014 at 7:31 AM, Tim Kryger wrote:
> On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot wrote:
>> Hi Tim, thanks for your reply!
>>
>> On 11/04/2014 02:28 PM, Tim Kryger wrote:
>>>
>>> On Mon, Nov 3, 2014 at 7:05 PM, Alexandre Courbot
[..]
After bisecting I tracked commit 52221610dd84dc3e9196554f0292ca9e8ab3541d
("mmc: sdhci: Improve external VDD regulator support") as the one that
introduced this issue, which seems somehow surprising to me since it has
been around for a while and nobody else complained about this AFAICT.
After some hunting it seems like the recent Qualcomm platforms are
suffering from this as well.
[..]
> In a nutshell, the issue here is that the SDHCI spec demands that VMMC
> be supplied by the controller itself with the specific voltage
> configured using the SDHCI_POWER_CONTROL register but almost nobody
> does this. Many SoCs omit this capability from their controllers and
> instead rely upon external regulators. In such cases there isn't
> normally any need to update the voltage bits of the power control
> register. It sounds like you are saying this isn't true for the
> Tegra114.
Should one interpret your answer as that iff the SDHCI controller
actually follows the specification (and provides the power control)
then as of the introduction of 52221610dd vmmc should no longer be
used for specifying the supply of power to the controller?
Or simply; what is vmmc (in the code) supposed to represent?
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: question about the luto-misc tree
Hi Andy, The luto-misc tree seems to have a whole series of commits in it that have just bee removed from the rcu tree ... You really have to be very careful if you base your work on a tree that is regularly rebased. I also wonder if the other commits in that tree are destined for v3.19? If they are for v3.20, then they should not be in linux-next until after v3.19-rc1 has been released. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpJyjZCgZCbi.pgp Description: OpenPGP digital signature
[PATCH] media: stb0899_drv: use time_after()
To be future-proof and for better readability the time comparisons are
modified to use time_after() instead of plain, error-prone math.
Signed-off-by: Asaf Vertz
---
drivers/media/dvb-frontends/stb0899_drv.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/stb0899_drv.c
b/drivers/media/dvb-frontends/stb0899_drv.c
index 07cd5ea..cb024af 100644
--- a/drivers/media/dvb-frontends/stb0899_drv.c
+++ b/drivers/media/dvb-frontends/stb0899_drv.c
@@ -20,6 +20,7 @@
*/
#include
+#include
#include
#include
#include
@@ -691,7 +692,7 @@ static int stb0899_wait_diseqc_fifo_empty(struct
stb0899_state *state, int timeo
reg = stb0899_read_reg(state, STB0899_DISSTATUS);
if (!STB0899_GETFIELD(FIFOFULL, reg))
break;
- if ((jiffies - start) > timeout) {
+ if (time_after(jiffies, start + timeout)) {
dprintk(state->verbose, FE_ERROR, 1, "timed out !!");
return -ETIMEDOUT;
}
@@ -733,7 +734,7 @@ static int stb0899_wait_diseqc_rxidle(struct stb0899_state
*state, int timeout)
while (!STB0899_GETFIELD(RXEND, reg)) {
reg = stb0899_read_reg(state, STB0899_DISRX_ST0);
- if (jiffies - start > timeout) {
+ if (time_after(jiffies, start + timeout)) {
dprintk(state->verbose, FE_ERROR, 1, "timed out!!");
return -ETIMEDOUT;
}
@@ -782,7 +783,7 @@ static int stb0899_wait_diseqc_txidle(struct stb0899_state
*state, int timeout)
while (!STB0899_GETFIELD(TXIDLE, reg)) {
reg = stb0899_read_reg(state, STB0899_DISSTATUS);
- if (jiffies - start > timeout) {
+ if (time_after(jiffies, start + timeout)) {
dprintk(state->verbose, FE_ERROR, 1, "timed out!!");
return -ETIMEDOUT;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] BFS CPU scheduler v0.460 for linux-3.18
This is to announce a resync and update of the Brain Fuck Scheduler, version 0.460 for the latest stable linux kernel. The patch against linux-3.18(.x) is available here: http://ck.kolivas.org/patches/bfs/3.0/3.18/3.18-sched-bfs-460.patch A -ck branded linux-3.18-ck1 patch is available here: http://ck.kolivas.org/patches/3.0/3.18/3.18-ck1/ All patches available here: http://ck.kolivas.org/patches Code blog: http://ck-hack.blogspot.com Enjoy! お楽しみください -- -ck -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [CIFS] Fix signed/unsigned pointer warning
On Sat, Dec 13, 2014 at 9:20 PM, Steve French wrote: > Probably harmless patch - but I didn't notice the warning on x86 > kernel build (building on Fedora 21, gcc 4.9.2) Did you test x86 32-bit or 64-bit? In the generic do_div() implementation, only the former case has an explicit type check. FWIW I'm on 32-bit bit MIPS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [CIFS] Fix signed/unsigned pointer warning
Probably harmless patch - but I didn't notice the warning on x86
kernel build (building on Fedora 21, gcc 4.9.2)
On Fri, Dec 12, 2014 at 11:19 AM, Kevin Cernekee wrote:
> On Mon, Nov 10, 2014 at 1:09 PM, Kevin Cernekee wrote:
>> Commit 2ae83bf93882d1 ("[CIFS] Fix setting time before epoch (negative
>> time values)") changed "u64 t" to "s64 t", which makes do_div() complain
>> about a pointer signedness mismatch:
>>
>> CC fs/cifs/netmisc.o
>> In file included from ./arch/mips/include/asm/div64.h:12:0,
>> from include/linux/kernel.h:124,
>> from include/linux/list.h:8,
>> from include/linux/wait.h:6,
>> from include/linux/net.h:23,
>> from fs/cifs/netmisc.c:25:
>> fs/cifs/netmisc.c: In function ‘cifs_NTtimeToUnix’:
>> include/asm-generic/div64.h:43:28: warning: comparison of distinct
>> pointer types lacks a cast [enabled by default]
>> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
>> ^
>> fs/cifs/netmisc.c:941:22: note: in expansion of macro ‘do_div’
>>ts.tv_nsec = (long)do_div(t, 1000) * 100;
>>
>> Introduce a temporary "u64 abs_t" variable to fix this.
>>
>> Signed-off-by: Kevin Cernekee
>> ---
>> fs/cifs/netmisc.c | 12 +++-
>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>
>>
>> Note: this is compile-tested only (on a 32-bit build).
>>
>>
>> diff --git a/fs/cifs/netmisc.c b/fs/cifs/netmisc.c
>> index b333ff6..abae6dd 100644
>> --- a/fs/cifs/netmisc.c
>> +++ b/fs/cifs/netmisc.c
>> @@ -926,6 +926,7 @@ cifs_NTtimeToUnix(__le64 ntutc)
>>
>> /* Subtract the NTFS time offset, then convert to 1s intervals. */
>> s64 t = le64_to_cpu(ntutc) - NTFS_TIME_OFFSET;
>> + u64 abs_t;
>>
>> /*
>> * Unfortunately can not use normal 64 bit division on 32 bit arch,
>> but
>> @@ -933,13 +934,14 @@ cifs_NTtimeToUnix(__le64 ntutc)
>> * to special case them
>> */
>> if (t < 0) {
>> - t = -t;
>> - ts.tv_nsec = (long)(do_div(t, 1000) * 100);
>> + abs_t = -t;
>> + ts.tv_nsec = (long)(do_div(abs_t, 1000) * 100);
>> ts.tv_nsec = -ts.tv_nsec;
>> - ts.tv_sec = -t;
>> + ts.tv_sec = -abs_t;
>> } else {
>> - ts.tv_nsec = (long)do_div(t, 1000) * 100;
>> - ts.tv_sec = t;
>> + abs_t = t;
>> + ts.tv_nsec = (long)do_div(abs_t, 1000) * 100;
>> + ts.tv_sec = abs_t;
>> }
>>
>> return ts;
>> --
>> 2.1.1
>>
>
> Hi guys,
>
> I am still seeing this warning on Linus' head of tree. Do you think
> this is something we can pull in for 3.19?
>
> Thanks!
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.18+] Can't boot with commit bd809af1 ("x86: Enable PAT to use cache mode translation tables")
Hi,
My Linux virtual machine on (Windows) VMWare workstation 10 can't boot with
following commit.
commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2
Author: Juergen Gross
Date: Mon Nov 3 14:02:03 2014 +0100
x86: Enable PAT to use cache mode translation tables
Unfortunately I can't see any console log.
Reverting the commit fixes my boot issue. git bisect log follows,
$ git bisect log
git bisect start
# bad: [92a578b064d0227a3a7fbbdb9e29dbab7f8d400e] Merge tag 'pm+acpi-3.19-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 92a578b064d0227a3a7fbbdb9e29dbab7f8d400e
# good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d
# good: [6da314122ddc11936c6f054753bbb956a499d020] Merge tag 'dt-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 6da314122ddc11936c6f054753bbb956a499d020
# good: [482a3767e5087f6e6ad2486a6655aaa5f3d59301] exit: reparent: call
forget_original_parent() under tasklist_lock
git bisect good 482a3767e5087f6e6ad2486a6655aaa5f3d59301
# bad: [cbfe0de303a55ed96d8831c2d5f56f8131cd6612] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad cbfe0de303a55ed96d8831c2d5f56f8131cd6612
# bad: [a6b849578ef3e0b131b1ea4063473a4f935a65e9] Merge branch 'for-linus' of
git://git.samba.org/sfrench/cifs-2.6
git bisect bad a6b849578ef3e0b131b1ea4063473a4f935a65e9
# bad: [c9f861c77269bc9950c16c6404a9476062241671] Merge branch
'x86-ras-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad c9f861c77269bc9950c16c6404a9476062241671
# good: [773fed910d41e443e495a6bfa9ab1c2b7b13e012] Merge branches
'x86-platform-for-linus' and 'x86-uv-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 773fed910d41e443e495a6bfa9ab1c2b7b13e012
# good: [773fed910d41e443e495a6bfa9ab1c2b7b13e012] Merge branches
'x86-platform-for-linus' and 'x86-uv-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 773fed910d41e443e495a6bfa9ab1c2b7b13e012
# good: [f439c429c320981943f8b64b2a4049d946cb492b] x86: Support PAT bit in
pagetable dump for lower levels
git bisect good f439c429c320981943f8b64b2a4049d946cb492b
# good: [e3480271f59253cb60d030aa5e615bf00b731fea] x86, mce, severity: Extend
the the mce_severity mechanism to handle UCNA/DEFERRED error
git bisect good e3480271f59253cb60d030aa5e615bf00b731fea
# bad: [0dbcae884779fdf7e2239a97ac7488877f0693d9] x86: mm: Move PAT only
functions to mm/pat.c
git bisect bad 0dbcae884779fdf7e2239a97ac7488877f0693d9
# bad: [bd809af16e3ab1f8d55b3e2928c47c67e2a865d2] x86: Enable PAT to use cache
mode translation tables
git bisect bad bd809af16e3ab1f8d55b3e2928c47c67e2a865d2
# good: [f5b2831d654167d77da8afbef4d2584897b12d0c] x86: Respect PAT bit when
copying pte values between large and normal pages
git bisect good f5b2831d654167d77da8afbef4d2584897b12d0c
# first bad commit: [bd809af16e3ab1f8d55b3e2928c47c67e2a865d2] x86: Enable PAT
to use cache mode translation tables
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝
Re: [PATCH 2/2] ARM: omap5/dra7xx: Fix counter frequency drift for AM572x errata i856.
On Fri, Dec 12, 2014 at 05:08:56PM -0500, Lennart Sorensen wrote:
> Errata i856 for the AM572x (DRA7xx) points out that the 32.768KHz external
> crystal is not enabled at power up. Instead the CPU falls back to using
> an emulation for the 32KHz clock which is SYSCLK1/610. SYSCLK1 is usually
> 20MHz on boards so far (which gives an emulated frequency of 32.786KHz),
> but can also be 19.2 or 27MHz which result in much larger drift.
>
> Since this is used to drive the master counter at 32.768KHz * 375 /
> 2 = 6.144MHz, the emulated speed for 20MHz is of by 570ppm, or about 43
> seconds per day, and more than the 500ppm NTP is able to tolerate.
>
> Checking the CTRL_CORE_BOOTSTRAP register can determine if the CPU
> is using the real 32.768KHz crystal or the emulated SYSCLK1/610, and
> by known that the real counter frequency can be determined and used.
s/known/knowing/
and a comma after that.
> The real speed is then SYSCLK1 / 610 * 375 / 2 or SYSCLK1 * 75 / 244.
>
> Signed-off-by: Len Sorensen
> ---
> arch/arm/mach-omap2/timer.c | 120
> +++
> 1 file changed, 87 insertions(+), 33 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index fb0cb2b..f00e4b4 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -497,6 +497,7 @@ static void __init realtime_counter_init(void)
> static struct clk *sys_clk;
> unsigned long rate;
> unsigned int reg, num, den;
> + bool errata_i856_workaround = false;
>
> base = ioremap(REALTIME_COUNTER_BASE, SZ_32);
> if (!base) {
> @@ -510,39 +511,93 @@ static void __init realtime_counter_init(void)
> return;
> }
>
> + if (soc_is_dra7xx()) {
> + #define CTRL_CORE_BOOTSTRAP 0x4A0026C4
> + #define SPEEDSELECT_MASK 0x0300
> + void __iomem *corebase;
> + corebase = ioremap(CTRL_CORE_BOOTSTRAP, SZ_4);
> + if (!corebase)
> + pr_err("%s: ioremap failed\n", __func__);
> + else {
> + reg = readl_relaxed(corebase) & SPEEDSELECT_MASK;
> + iounmap(corebase);
> + /*
> + * Errata i856 says the 32.768KHz crystal does
> + * not start at power on, so the CPU falls back in
> + * an emulated 32KHz clock instead. This causes
> + * the master counter frequency to not be 6.144MHz
> + * This affects at least the AM572x 1.0 and
> + * 1.1 revisions.
> + *
> + * Of course any board built without a populated
> + * 32.768KHz crystal would also need this fix
> + * even if the CPU is fixed later.
> + *
> + * If the two speedselect bits are not 0, then the
> + * 32.768KHz clock driving the course counter that
s/course/coarse/
> + * corrects the fine counter every time it ticks is
> + * actually rate/610 rather than 32.768KHz and we
> + * should compensate to avoid the 570ppm (At 20MHz,
> + * much worse at other rates) too fast system time.
> + */
> + if (reg) {
> + errata_i856_workaround = true;
> + }
> + }
> + }
> +
> rate = clk_get_rate(sys_clk);
> - /* Numerator/denumerator values refer TRM Realtime Counter section */
> - switch (rate) {
> - case 1200:
> - num = 64;
> - den = 125;
> - break;
> - case 1300:
> - num = 768;
> - den = 1625;
> - break;
> - case 1920:
> - num = 8;
> - den = 25;
> - break;
> - case 2000:
> - num = 192;
> - den = 625;
> - break;
> - case 2600:
> - num = 384;
> - den = 1625;
> - break;
> - case 2700:
> - num = 256;
> - den = 1125;
> - break;
> - case 3840:
> - default:
> - /* Program it for 38.4 MHz */
> - num = 4;
> - den = 25;
> - break;
> + if (errata_i856_workaround) {
> + /*
> + * Realtime Counter frequency is not based on a real
> + * 32.768KHz time source, so calculate the real resulting
> + * frequency instead. It is not 6.144MHz in this case.
> + *
> + * The frequency is always rate / 610 + 375 / 2 which
> + * is rate * 244 / 75 and will fit in 32 bit for all rates.
> + *
> + * The multiplication has to be first to keep accuracy
> +
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 03:41:52PM -0500, Dave Jones wrote: > On Sat, Dec 13, 2014 at 10:04:08AM -0800, Paul E. McKenney wrote: > > On Sat, Dec 13, 2014 at 11:59:15AM -0500, Dave Jones wrote: > > > On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote: > > > > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote: > > > > > > > > > > Something that's still making me wonder if it's some kind of > hardware > > > > > problem is the non-deterministic nature of this bug. > > > > > > > > I'd expect it to be a race condition, though. Which can easily cause > > > > these kinds of issues, and the timing will be pretty random even if > > > > the load is very regular. > > > > > > > > And we know that the scheduler has an integer overflow under Sasha's > > > > loads, although I didn't hear anything from Ingo and friends about it. > > > > Ingo/Peter, you were cc'd on that report, where at least one of the > > > > multiplcations in wake_affine() ended up overflowing.. > > > > > > > > Some scheduler thing that overflows only under heavy load, and screws > > > > up scheduling could easily account for the RCU thread thing. I see it > > > > *less* easily accounting for DaveJ's case, though, because the > > > > watchdog is running at RT priority, and the scheduler would have to > > > > screw up much more to then not schedule an RT task, but.. > > > > > > > > I'm also not sure if the bug ever happens with preemption disabled. > > > > > > Bah, so I see some watchdog traces with preemption off, and that then > > > taints the kernel, and the fuzzing stops. I'll hack something up > > > so it ignores the taint and keeps going. All I really care about here > > > is the "machine hangs completely" case, which the trace below didn't > > > hit.. > > > > > > (back to fuzzing almost everything, not just lsetxattr btw) > > > > Hmmm... This one looks like the RCU grace-period kthread is getting > > starved: "idle=b4c/0/0". Is this running with the "dangerous" patch > > that sets these kthreads to RT priority? > > sorry, no. Ran out of time yesterday. I'll try and get to applying that > later this evening if I get chance. Whew!!! You had me worried there for a bit! ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 45/99] mm: unmapped page migration avoid unmap+remap overhead
On Sat, 13 Dec 2014, Davidlohr Bueso wrote: > On Fri, 2014-12-12 at 16:56 -0800, a...@linux-foundation.org wrote: > > From: Hugh Dickins > > Subject: mm: unmapped page migration avoid unmap+remap overhead > > > > Page migration's __unmap_and_move(), and rmap's try_to_unmap(), were > > created for use on pages almost certainly mapped into userspace. But > > nowadays compaction often applies them to unmapped page cache pages: which > > may exacerbate contention on i_mmap_rwsem quite unnecessarily, since > > try_to_unmap_file() makes no preliminary page_mapped() check. > > > > Now check page_mapped() in __unmap_and_move(); and avoid repeating the > > same overhead in rmap_walk_file() - don't remove_migration_ptes() when we > > never inserted any. > > > > (The PageAnon(page) comment blocks now look even sillier than before, but > > clean that up on some other occasion. And note in passing that > > try_to_unmap_one() does not use a migration entry when PageSwapCache, so > > remove_migration_ptes() will then not update that swap entry to newpage > > pte: not a big deal, but something else to clean up later.) > > > > Davidlohr remarked in "mm,fs: introduce helpers around the i_mmap_mutex" > > conversion to i_mmap_rwsem, that "The biggest winner of these changes is > > migration": a part of the reason might be all of that unnecessary taking > > of i_mmap_mutex in page migration; > > Yeah, this is making a lot of sense. > > > and it's rather a shame that I didn't > > get around to sending this patch in before his - this one is much less > > useful after Davidlohr's conversion to rwsem, but still good. > > Now that I have some free hardware, I did some testing to consider this > patch for some SLE kernels (which still has the i_mmap mutex), and it > sure relieves a lot of the overhead/contention. On a 60-core box with a > file server benchmark we increase throughput by up to 60-70%: > > new_fserver-61 21456.59 ( 0.00%)35875.59 ( 67.20%) > new_fserver-12122335.16 ( 0.00%)38037.28 ( 70.30%) > new_fserver-18123280.22 ( 0.00%)39518.54 ( 69.75%) > new_fserver-24123194.88 ( 0.00%)39065.85 ( 68.42%) > new_fserver-30123135.30 ( 0.00%)38464.88 ( 66.26%) > new_fserver-36122922.97 ( 0.00%)38115.74 ( 66.28%) > new_fserver-42122841.84 ( 0.00%)37859.06 ( 65.74%) > new_fserver-48122643.83 ( 0.00%)37751.59 ( 66.72%) > new_fserver-54122620.21 ( 0.00%)37036.09 ( 63.73%) > new_fserver-60122593.85 ( 0.00%)36959.11 ( 63.58%) > new_fserver-66122434.81 ( 0.00%)36629.28 ( 63.27%) > new_fserver-72122219.68 ( 0.00%)36128.16 ( 62.60%) > new_fserver-78122134.90 ( 0.00%)35893.50 ( 62.16%) > new_fserver-84121901.59 ( 0.00%)35826.33 ( 63.58%) > new_fserver-90121911.80 ( 0.00%)35285.66 ( 61.03%) > new_fserver-96121810.72 ( 0.00%)35253.62 ( 61.63%) > > Anyway, it's already picked up by Linus, but thought it would be nice to > have actual data. Wow, thanks a lot, Davidlohr: that's really helpful and interesting. I just did the patch as a source-inspection thing, and never got to measure anything. Well worth backporting, yes. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] [PATCH v2] staging: writeboost: Add dm-writeboost
Jianjian, > How about invalidating previous writes on same sector address? if > first write is stored in one 512KB log in SSD, later when user write > the same address, will writeboost invalid old write by updating meta > data header in place in that 512KB log? and other meta data like > superblock, will writeboost will update them in place? if writeboost > has those frequent random in-place updates, probably those benefits > except utilizing the faster sequential writes will be much discounted. In runtime, Writeboost has equivalent metadata on the memory as hash table. This makes not only cache lookup fast but also makes invalidation easy. Without this, Writeboost's speed is really discounted. Any logs on the cache device are never updated partially (it's too dangerous if we consider partial write failure). Durability is another benefit of log-structured caching. As for writing on superblock, it's really random. But, we don't need to update superblock every write but every seconds or so. To begin with, it's not logically essential so you can turn it off (that's the default). The option is for users much care for the resume time. > Even if writeboost write everything sequentially, probably SSD won't > be able to recognize that and do its own wear-leveling whatsoever. It > will be easier, since there is no need to move cold data, etc. > > Generally, SSDs vary a lot, IMHO, one certain optimization technique > may work for certain model, but may not work for others, since they > internal NAND Flash management algorithms can be very different. Yes, Thanks. I believe making the SSD-internal works easy can not only stabilize the performance but also reduce the possibility of being trapped by some bugs that the SSD provides such as petit freeze. - Akira On 12/14/14 11:46 AM, Jianjian Huo wrote: > On Sat, Dec 13, 2014 at 6:07 AM, Akira Hayakawa wrote: >> Hi, >> >> Jianjian, You really get a point at the fundamental design. >> >>> If I understand it correctly, the whole idea indeed is very simple, >>> the consumer/provider and circular buffer model. use SSD as a circular >>> write buffer, write flush thread stores incoming writes to this buffer >>> sequentially as provider, and writeback thread write those data logs >>> sequentially into backing device as consumer. >>> >>> If writeboost can do that without any random writes, then probably it >>> can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster >>> sequential read/write performance from SSD. That'll be awesome. >>> However, I saw every data log segment in its design has meta data >>> header, like dirty_bits, so I guess writeboost has to randomly write >>> those data headers of stored data logs in SSD; also, splitting all bio >>> into 4KB will hurt its ability to get max raw SSD throughput, modern >>> NAND Flash has pages much bigger than 4KB; so overall I think the >>> actual benefits writeboost gets from this design will be discounted. >> You understand *almost* correctly. >> >> Writeboost has two circular buffers, not one; RAM buffers and SSD. >> The incoming bio is split into 4KB chunks at the virtual make_request >> and are NOT directly remapped to the SSD. >> As you mentioned, if I designed so, many update on the metadata happens. >> That's really bad since SSD is very bad at small update. >> >> Actually, the 4KB bio is first stored in RAM buffer, which is 512KB large. >> There are (512-4)/4=127 4KB bio data stored in the RAM buffer and 4KB >> metadata >> section at the head is made after that. >> >> The RAM buffer is now called "log" and as you mentioned, flushed to the SSD >> as 512KB sequential write. This definitely maximizes throughput and lifetime. >> >> Unfortunately, this is not always the case because of barrier request >> handlings. >> But, when the writes is really heavy (e.g. massive dirty page writeback), >> Writeboost works as above. >> > How about invalidating previous writes on same sector address? if > first write is stored in one 512KB log in SSD, later when user write > the same address, will writeboost invalid old write by updating meta > data header in place in that 512KB log? and other meta data like > superblock, will writeboost will update them in place? if writeboost > has those frequent random in-place updates, probably those benefits > except utilizing the faster sequential writes will be much discounted. > >>> The good thing is that it seems writeboost doesn't use garbage >>> collection to clean old invalid logs, this will avoid the double >>> garage collection effect other caching module has, which essentially >>> both caching module and internal SSD will perform garbage collections >>> twice. >> Yes. And I believe SSDs can remove wear-leveling if I used it as fairly >> sequential. >> Am I right? Indeed, Writeboost is really SSD frinedly. >> > Even if writeboost write everything sequentially, probably SSD won't > be able to recognize that and do its own wear-leveling whatsoever. It > will be
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 05:35:17PM -0800, Linus Torvalds wrote: > On Sat, Dec 13, 2014 at 4:33 PM, Al Viro wrote: > > > > So does SMP - this_cpu_dec() relies on preemption being disabled. > > No. really. It very much does not. Not on x86, not elsewhere. It's > part of the whole point of "this_cpu_p()". They are preemption and > interrupt safe. > > It's the "__this_cpu_op()" ones that need external protection. Right you are - I really need to get some coffee... Sorry... FWIW, do we need to disable interrupts there? After all, mnt_want_write() and mnt_drop_write() shouldn't be done from interrupt context - they can happen via schedule_delayed_work(), but that's it... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: query on DWC3
Hi Paul,
As per my understanding, for BULK OUT we do queue a request with 512
bytes length since we do not
know the length of the transfer Host is going to send. For Control OUT
we know the length in wLength of
Setup packet, hence I assumed there is no difference in programming
model of Control IN and OUT.
Now it is clear for me. Thanks for the clarification :)
Sundeep
On Sun, Dec 14, 2014 at 5:21 AM, Paul Zimmerman
wrote:
>> From: linux-usb-ow...@vger.kernel.org
>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of sundeep subbaraya
>> Sent: Friday, December 12, 2014 9:13 PM
>>
>> Hi Felipe,
>>
>> In DWC3 driver, for three stage Control OUT transfer there is a check:
>>
>>else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
>>
>> && (dep->number == 0)) {.
>> }
>>
>> I understand that we check for alignment of sizes and if not we
>> prepare trb with maxpacket and enable interrupt on short packet. In
>> databook I could not find anything related to this, it talks only
>> about addresses should be aligned. In Control transfer programming
>> model there is no difference between Control OUT or IN transfer, if
>> three stage transfer - prepare trb with length wLength. Initially I
>> followed this and not able to receive data on EP0 OUT.:( .After adding
>> the above check it is working. Please help me to understand why we do
>> this?
>
> Hi Sundeep,
>
> Please see section 8.2.3.3 "Buffer Size Rules and Zero-Length Packets"
> in the databook:
>
> For OUT endpoints, the following rules apply:
>
> - The total size of a Buffer Descriptor must be a multiple of
> MaxPacketSize
>
> The wording may be a little confusing, it actually means that the size
> of the data buffer for OUT endpoints must be a multiple of MaxPacketSize.
> Section 8.2.5 states it more clearly:
>
> - An OUT transfer’s transfer size (Total TRB buffer allocation)
> must be a multiple of MaxPacketSize even if software is expecting
> a fixed non-multiple of MaxPacketSize transfer from the Host.
>
> This rule applies to all OUT endpoint types, including Control endpoints.
>
> --
> Paul
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 45/99] mm: unmapped page migration avoid unmap+remap overhead
On Fri, 2014-12-12 at 16:56 -0800, a...@linux-foundation.org wrote: > From: Hugh Dickins > Subject: mm: unmapped page migration avoid unmap+remap overhead > > Page migration's __unmap_and_move(), and rmap's try_to_unmap(), were > created for use on pages almost certainly mapped into userspace. But > nowadays compaction often applies them to unmapped page cache pages: which > may exacerbate contention on i_mmap_rwsem quite unnecessarily, since > try_to_unmap_file() makes no preliminary page_mapped() check. > > Now check page_mapped() in __unmap_and_move(); and avoid repeating the > same overhead in rmap_walk_file() - don't remove_migration_ptes() when we > never inserted any. > > (The PageAnon(page) comment blocks now look even sillier than before, but > clean that up on some other occasion. And note in passing that > try_to_unmap_one() does not use a migration entry when PageSwapCache, so > remove_migration_ptes() will then not update that swap entry to newpage > pte: not a big deal, but something else to clean up later.) > > Davidlohr remarked in "mm,fs: introduce helpers around the i_mmap_mutex" > conversion to i_mmap_rwsem, that "The biggest winner of these changes is > migration": a part of the reason might be all of that unnecessary taking > of i_mmap_mutex in page migration; Yeah, this is making a lot of sense. > and it's rather a shame that I didn't > get around to sending this patch in before his - this one is much less > useful after Davidlohr's conversion to rwsem, but still good. Now that I have some free hardware, I did some testing to consider this patch for some SLE kernels (which still has the i_mmap mutex), and it sure relieves a lot of the overhead/contention. On a 60-core box with a file server benchmark we increase throughput by up to 60-70%: new_fserver-61 21456.59 ( 0.00%)35875.59 ( 67.20%) new_fserver-12122335.16 ( 0.00%)38037.28 ( 70.30%) new_fserver-18123280.22 ( 0.00%)39518.54 ( 69.75%) new_fserver-24123194.88 ( 0.00%)39065.85 ( 68.42%) new_fserver-30123135.30 ( 0.00%)38464.88 ( 66.26%) new_fserver-36122922.97 ( 0.00%)38115.74 ( 66.28%) new_fserver-42122841.84 ( 0.00%)37859.06 ( 65.74%) new_fserver-48122643.83 ( 0.00%)37751.59 ( 66.72%) new_fserver-54122620.21 ( 0.00%)37036.09 ( 63.73%) new_fserver-60122593.85 ( 0.00%)36959.11 ( 63.58%) new_fserver-66122434.81 ( 0.00%)36629.28 ( 63.27%) new_fserver-72122219.68 ( 0.00%)36128.16 ( 62.60%) new_fserver-78122134.90 ( 0.00%)35893.50 ( 62.16%) new_fserver-84121901.59 ( 0.00%)35826.33 ( 63.58%) new_fserver-90121911.80 ( 0.00%)35285.66 ( 61.03%) new_fserver-96121810.72 ( 0.00%)35253.62 ( 61.63%) Anyway, it's already picked up by Linus, but thought it would be nice to have actual data. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] staging: writeboost: Add dm-writeboost
Hi, I've just measured how split affects. I think seqread can make the discussion solid so these are the cases of reading 6.4GB (64MB * 100) sequentially. HDD: 64MB read real 2m1.191s user 0m0.000s sys 0m0.470s Writeboost (HDD+SSD): 64MB read real 2m13.532s user 0m0.000s sys 0m28.740s The splitting actually affects to some extent (2m1 -> 2m13 is 10% loss). But not too big if we consider the typical workload is NOT seqreads (if so, the user shouldn't use SSD caching). Splitting bio into 4KB chunks makes the cache lookup and locking simple and this contributes to the performance of both write and read is the fact, don't miss it. Without this, especially, writes isn't so fast in Writeboost but rather loses its charms. Since simple and fast is the ideal for any softwares. I am really unwilling to change this fundamental design; splitting. But, an idea of selective splitting can be proposed for future enhancement. Add a layer so that a target can choose if it needs splitting or not may be interesting. I think Writeboost can bypass big writes/reads at the cost of duplicated cache lookup. Can DM-cache also benefit from this extension? Conceptually, it's like this before: bio -> ~map:bio->bio after: bio -> ~should_split:bio->bool -> ~map:bio->bio - Akira On 12/13/14 12:09 AM, Akira Hayakawa wrote: >> However, after looking at the current code, and using it I think it's >> a long, long way from being ready for production. As we've already >> discussed there are some very naive design decisions in there, such as >> copying every bio payload to another memory buffer, splitting all io >> down to 4k. Think about the cpu overhead and memory consumption! >> Think about how it will perform when memory is constrained and it >> can't allocate many of those rambufs! I'm sure more issues will be >> found if I read further. > These decisions are made based on measurement. They are not naive. > I am a man who dislikes performance optimization without measurement. > As a result, I regard things brought by the simplicity much important > than what's from other design decisions possible. > > About the CPU consumption, > the average CPU consumption while performing random write fio > with consumer level SSD is only 3% or so, > which is 5 times efficient than bcache per iops. > > With RAM-backed cache device, it reaches about 1.5GB/sec throughput. > Even in this case the CPU consumption is only 12%. > Please see this post, > http://www.redhat.com/archives/dm-devel/2014-February/msg0.html > > I don't think the CPU consumption is small enough to ignore. > > About the memory consumption, > you seem to misunderstand the fact. > The rambufs are not dynamically allocated but statically. > The default amount is 8MB and this is usually not to argue. > >> Mike raised the question of why you want this in the kernel so much? >> You'd find none of the distros would support it; so it doesn't widen >> your audience much. It's far better for you to maintain it outside of >> the kernel at this point. Any users will be bold, adventurous people, >> who will be quite capable of building a kernel module. > Some people deploy Writeboost in their daily use. > The sound of "log-structured" seems to easily attract storage guys' attention. > If this driver is merged into upstream, I think it gains many audience and > thus feedback. > When my driver was introduced by Phoronix before, it actually drew attentions. > They must wait for Writeboost become available in upstream. > http://www.phoronix.com/scan.php?page=news_item=MTQ1Mjg > >> I'm sorry to have disappointed you so, but if I let this go upstream >> it would mean a massive amount of support work for me, not to mention >> a damaged reputation for dm. > If you read the code further, you will find how simple the mechanism is. > Not to mention the code itself is. > > - Akira > > On 12/12/14 11:24 PM, Joe Thornber wrote: >> On Fri, Dec 12, 2014 at 09:42:15AM +0900, Akira Hayakawa wrote: >>> The SSD-caching should be log-structured. >> >> No argument there, and this is why I've supported you with >> dm-writeboost over the last couple of years. >> >> However, after looking at the current code, and using it I think it's >> a long, long way from being ready for production. As we've already >> discussed there are some very naive design decisions in there, such as >> copying every bio payload to another memory buffer, splitting all io >> down to 4k. Think about the cpu overhead and memory consumption! >> Think about how it will perform when memory is constrained and it >> can't allocate many of those rambufs! I'm sure more issues will be >> found if I read further. >> >> I'm sorry to have disappointed you so, but if I let this go upstream >> it would mean a massive amount of support work for me, not to mention >> a damaged reputation for dm. >> >> Mike raised the question of why you want this in the kernel so much? >> You'd find none of the distros would
Re: [dm-devel] [PATCH v2] staging: writeboost: Add dm-writeboost
On Sat, Dec 13, 2014 at 6:07 AM, Akira Hayakawa wrote: > Hi, > > Jianjian, You really get a point at the fundamental design. > >> If I understand it correctly, the whole idea indeed is very simple, >> the consumer/provider and circular buffer model. use SSD as a circular >> write buffer, write flush thread stores incoming writes to this buffer >> sequentially as provider, and writeback thread write those data logs >> sequentially into backing device as consumer. >> >> If writeboost can do that without any random writes, then probably it >> can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster >> sequential read/write performance from SSD. That'll be awesome. >> However, I saw every data log segment in its design has meta data >> header, like dirty_bits, so I guess writeboost has to randomly write >> those data headers of stored data logs in SSD; also, splitting all bio >> into 4KB will hurt its ability to get max raw SSD throughput, modern >> NAND Flash has pages much bigger than 4KB; so overall I think the >> actual benefits writeboost gets from this design will be discounted. > You understand *almost* correctly. > > Writeboost has two circular buffers, not one; RAM buffers and SSD. > The incoming bio is split into 4KB chunks at the virtual make_request > and are NOT directly remapped to the SSD. > As you mentioned, if I designed so, many update on the metadata happens. > That's really bad since SSD is very bad at small update. > > Actually, the 4KB bio is first stored in RAM buffer, which is 512KB large. > There are (512-4)/4=127 4KB bio data stored in the RAM buffer and 4KB metadata > section at the head is made after that. > > The RAM buffer is now called "log" and as you mentioned, flushed to the SSD > as 512KB sequential write. This definitely maximizes throughput and lifetime. > > Unfortunately, this is not always the case because of barrier request > handlings. > But, when the writes is really heavy (e.g. massive dirty page writeback), > Writeboost works as above. > How about invalidating previous writes on same sector address? if first write is stored in one 512KB log in SSD, later when user write the same address, will writeboost invalid old write by updating meta data header in place in that 512KB log? and other meta data like superblock, will writeboost will update them in place? if writeboost has those frequent random in-place updates, probably those benefits except utilizing the faster sequential writes will be much discounted. >> The good thing is that it seems writeboost doesn't use garbage >> collection to clean old invalid logs, this will avoid the double >> garage collection effect other caching module has, which essentially >> both caching module and internal SSD will perform garbage collections >> twice. > Yes. And I believe SSDs can remove wear-leveling if I used it as fairly > sequential. > Am I right? Indeed, Writeboost is really SSD frinedly. > Even if writeboost write everything sequentially, probably SSD won't be able to recognize that and do its own wear-leveling whatsoever. It will be easier, since there is no need to move cold data, etc. Generally, SSDs vary a lot, IMHO, one certain optimization technique may work for certain model, but may not work for others, since they internal NAND Flash management algorithms can be very different. >> And one question, how long will be data logs replay time during init, >> if SSD is almost full of dirty data logs? > Sorry, I don't have a data now but it's slow as you may imagine. > I will measure the time on later. > > The major reason is, it needs to read full 512KB segment to calculate > checksum to > know if the log isn't half written. > (Read 500GB SSD that performs 500MB/sec seqread spends 1000secs) > I think making the procedure done in parallel to exploit the full internal > parallelism > inside SSD may improve performance but it's just the matter of coefficient > down from 1 to 1/n. > Definitely, Writeboost isn't fit for a machine that needs reboot frequently > (e.g. desktop). > > There is a way to reduce the init time. We can dump "what is the latest log > written back" > on the superblock. This can skip readings that aren't essential. > > The corresponding code is replay_log_on_cache() function. Please read if you > are > interested. > > Thanks, > > - Akira > > On 12/13/14 3:45 PM, Jianjian Huo wrote: >> If I understand it correctly, the whole idea indeed is very simple, >> the consumer/provider and circular buffer model. use SSD as a circular >> write buffer, write flush thread stores incoming writes to this buffer >> sequentially as provider, and writeback thread write those data logs >> sequentially into backing device as consumer. >> >> If writeboost can do that without any random writes, then probably it >> can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster >> sequential read/write performance from SSD. That'll be awesome. >> However, I saw every data log segment in its design
charity message
Hello,this is Mr Paul N,i sent you an email on charity work but i am yet to hear fom you,do reply with this code CHA-2015 to my email address paulchar...@qq.com i Look forward to hearing from you this time,God bless Brother Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/3] i2c: add support for Cypress CYUSBS234 USB-I2C adapter
On Saturday 13 December 2014 05:17 PM, Muthu Mani wrote:
Adds support for USB-I2C interface of Cypress Semiconductor
CYUSBS234 USB-Serial Bridge controller.
The read/write operation is setup using vendor command through control endpoint
and actual data transfer happens through bulk in/out endpoints.
Details about the device can be found at:
http://www.cypress.com/?rID=84126
Signed-off-by: Muthu Mani
Signed-off-by: Rajaram Regupathy
---
Changes since v4:
* used interface number from interface pointer instead of separate member var
Changes since v3:
* corrected typo
Changes since v2:
* Retrieved the i2c transfer status using interrupt in endpoint
* Used kstrtol instead of manually parsing and scnprintf instead of sprintf
* Given i2c adapter device for dev_xxx
* cleaned up the code
Changes since v1:
* allocated memory on heap for usb transfer data
* Used DEVICE_ATTR_xx and friends and attribute groups
* Added the device files under i2c-adapter rather than platform device
drivers/i2c/busses/Kconfig | 12 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-cyusbs23x.c | 585 +
3 files changed, 598 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-cyusbs23x.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b4d135c..a9cd3e2 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -871,6 +871,18 @@ config I2C_RCAR
comment "External I2C/SMBus adapter drivers"
+config I2C_CYUSBS23X
+ tristate "CYUSBS23x I2C adapter"
+ depends on MFD_CYUSBS23X
+ help
+ Say yes if you would like to access Cypress CYUSBS23x I2C device.
+
+ This driver enables the I2C interface of CYUSBS23x USB Serial Bridge
+ controller.
+
+ This driver can also be built as a module. If so, the module will be
+ called i2c-cyusbs23x.
+
config I2C_DIOLAN_U2C
tristate "Diolan U2C-12 USB adapter"
depends on USB
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index cdac7f1..ad2b283 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -86,6 +86,7 @@ obj-$(CONFIG_I2C_XLR) += i2c-xlr.o
obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
# External I2C/SMBus adapter drivers
+obj-$(CONFIG_I2C_CYUSBS23X)+= i2c-cyusbs23x.o
obj-$(CONFIG_I2C_DIOLAN_U2C) += i2c-diolan-u2c.o
obj-$(CONFIG_I2C_DLN2) += i2c-dln2.o
obj-$(CONFIG_I2C_PARPORT) += i2c-parport.o
diff --git a/drivers/i2c/busses/i2c-cyusbs23x.c
b/drivers/i2c/busses/i2c-cyusbs23x.c
new file mode 100644
index 000..452c370
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cyusbs23x.c
@@ -0,0 +1,585 @@
+/*
+ * I2C subdriver for Cypress CYUSBS234 USB-Serial Bridge controller.
+ * Details about the device can be found at:
+ *http://www.cypress.com/?rID=84126
+ *
+ * Copyright (c) 2014 Cypress Semiconductor Corporation.
+ *
+ * Author:
+ * Rajaram Regupathy
+ *
+ * Additional contributors include:
+ * Muthu Mani
+ *
+ * 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.
+ */
+
+/*
+ * It exposes sysfs entries under the i2c adapter for getting the i2c transfer
+ * status, reset i2c read/write module, get/set nak and stop bits.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CY_I2C_MODE_READ 0
+#define CY_I2C_MODE_WRITE 1
+
+#define CY_I2C_XFER_STATUS_LEN 3
+
+struct cyusbs_i2c_config {
+ /* Frequency of operation. Only valid values are 100KHz and 400KHz */
+ u32 frequency;
+ u8 slave_addr;/* Slave address to be used when in slave mode */
+ u8 is_msb_first; /* Whether to transmit MSB first */
+ /*
+* Whether block is configured as a master:
+* 1 - The block functions as I2C master;
+* 0 - The block functions as I2C slave
+*/
+ u8 is_master;
+ u8 s_ignore; /* Ignore general call in slave mode */
+ /* Whether to stretch clock in case of no FIFO availability */
+ u8 clock_stretch;
+ /* Whether to loop back TX data to RX. Valid only for debug purposes */
+ u8 is_loopback;
+ u8 reserved[6]; /* Reserved for future use */
+} __packed;
+
+struct cyusbs_i2c {
+ struct i2c_adapter i2c_adapter;
+ struct cyusbs_i2c_config *i2c_config;
+ struct mutex lock;
+
+ bool is_stop_bit; /* set the stop bit for i2c transfer */
+ bool is_nak_bit; /* set the nak bit for i2c transfer */
+};
+
+#define to_cyusbs_i2c(a) container_of(a, struct cyusbs_i2c, i2c_adapter)
+
+static int cy_i2c_get_status(struct i2c_adapter *adapter, u8 *buf, u16 mode);
+static int cy_i2c_reset(struct i2c_adapter *adapter, u16 mode);
+
+static ssize_t
Re: [PATCH v5 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter
On Saturday 13 December 2014 05:17 PM, Muthu Mani wrote:
Adds support for USB-GPIO interface of Cypress Semiconductor
CYUSBS234 USB-Serial Bridge controller.
The GPIO get/set can be done through vendor command on control endpoint
for the configured gpios.
Details about the device can be found at:
http://www.cypress.com/?rID=84126
Signed-off-by: Muthu Mani
Signed-off-by: Rajaram Regupathy
(...)
+static int cy_gpio_get(struct gpio_chip *chip,
+ unsigned offset)
+{
+ int ret;
+ char *buf;
+ u16 wIndex, wValue;
+ struct cyusbs_gpio *gpio = to_cyusbs_gpio(chip);
+ struct cyusbs23x *cyusbs = gpio->cyusbs;
+
+ if (gpio->out_gpio & BIT(offset))
+ return !!(gpio->out_value & BIT(offset));
+
+ wValue = offset;
+ wIndex = 0;
+ buf = kmalloc(CY_GPIO_GET_LEN, GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
+
Using '!' operator is preferred!
if(!buf)
return -ENOMEM;
+ ret = usb_control_msg(cyusbs->usb_dev,
+ usb_rcvctrlpipe(cyusbs->usb_dev, 0),
+ CY_GPIO_GET_VALUE_CMD,
+ USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+ wValue, wIndex, buf, CY_GPIO_GET_LEN,
+ CY_USBS_CTRL_XFER_TIMEOUT);
+ if (ret == CY_GPIO_GET_LEN) {
+ dev_dbg(chip->dev, "%s: offset=%d %02X %02X\n",
+ __func__, offset, buf[0], buf[1]);
+ if (buf[0] == 0)
+ ret = !!buf[1];
+ else
+ ret = -EIO;
+ } else {
+ dev_err(chip->dev, "%s: offset=%d %d\n", __func__, offset, ret);
+ ret = -EIO;
+ }
+
+ kfree(buf);
+ return ret;
+}
+
+static void cy_gpio_set(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ int ret;
+ u16 wIndex, wValue;
+ struct cyusbs_gpio *gpio = to_cyusbs_gpio(chip);
+ struct cyusbs23x *cyusbs = gpio->cyusbs;
+
+ wValue = offset;
+ wIndex = value;
+
+ ret = usb_control_msg(cyusbs->usb_dev,
+ usb_sndctrlpipe(cyusbs->usb_dev, 0),
+ CY_GPIO_SET_VALUE_CMD,
+ USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+ wValue, wIndex, NULL, 0, CY_USBS_CTRL_XFER_TIMEOUT);
+ if (ret < 0)
+ dev_err(chip->dev, "error setting gpio %d: %d\n", offset, ret);
+ else {
+ if (value)
+ gpio->out_value |= BIT(offset);
+ else
+ gpio->out_value &= ~BIT(offset);
+ }
+}
+
Following Two functions returning an error code. Generally when control reached
to end of the function indicates that the function call is success.
Returning an error is not best way. On success every function will return a
success return code..
+static int cy_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+ u32 gpios;
+ struct cyusbs_gpio *gpio = to_cyusbs_gpio(chip);
+
+ gpios = gpio->out_gpio | gpio->in_gpio;
+ if (gpios & BIT(offset))
+ return 0;
+
+ return -ENODEV;
+}
+
+static int cy_gpio_get_direction(struct gpio_chip *chip,
+ unsigned offset)
+{
+ struct cyusbs_gpio *gpio = to_cyusbs_gpio(chip);
+
+ if (gpio->out_gpio & BIT(offset))
+ return GPIOF_DIR_OUT;
+ else if (gpio->in_gpio & BIT(offset))
+ return GPIOF_DIR_IN;
+
+ return -EIO;
+}
+
+static int cy_get_device_config(struct cyusbs23x *cyusbs, u8 *buf)
+{
+ int ret;
+
+ ret = usb_control_msg(cyusbs->usb_dev,
+ usb_sndctrlpipe(cyusbs->usb_dev, 0),
+ CY_DEV_ENABLE_CONFIG_READ_CMD,
+ USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ CY_USBS_READ_CONFIG, CY_USBS_ENABLE_READ, NULL, 0,
+ CY_USBS_CTRL_XFER_TIMEOUT);
+ if (ret) {
+ dev_err(>usb_dev->dev,
+ "%s: enable config read status %d\n", __func__, ret);
+ return -ENODEV;
+ }
+
+ ret = usb_control_msg(cyusbs->usb_dev,
+ usb_rcvctrlpipe(cyusbs->usb_dev, 0),
+ CY_DEV_READ_CONFIG_CMD,
+ USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+ 0, 0, buf, CY_DEVICE_CONFIG_SIZE,
+ CY_USBS_CTRL_XFER_TIMEOUT);
+ if (ret != CY_DEVICE_CONFIG_SIZE) {
+ dev_err(>usb_dev->dev,
+ "%s: read config status %d\n", __func__, ret);
+ return -ENODEV;
+ }
+
+ ret = usb_control_msg(cyusbs->usb_dev,
+ usb_sndctrlpipe(cyusbs->usb_dev, 0),
+ CY_DEV_ENABLE_CONFIG_READ_CMD,
+
Re: [dm-devel] [PATCH v2] staging: writeboost: Add dm-writeboost
Hi, > The major reason is, it needs to read full 512KB segment to calculate > checksum to > know if the log isn't half written. > (Read 500GB SSD that performs 500MB/sec seqread spends 1000secs) I've just measured how long the cache resuming is. I use 2GB SSD for the cache device. 512KB seqread over the cache device: 8.252sec (242MB/sec) Resume when all caches are dirty: 10.339sec Typically, if you use 128GB SSD it will be 5-10 minutes. As I predicted, resuming time is close to seqread. In other words, it's fully IO-bound. (If you read the code you will notice that it first searchs for the oldest log as the starting point. It's 4KB metadata reads but spends to some extent. The other 2 sec is thought to be spent by this) - Akira On 12/13/14 11:07 PM, Akira Hayakawa wrote: > Hi, > > Jianjian, You really get a point at the fundamental design. > >> If I understand it correctly, the whole idea indeed is very simple, >> the consumer/provider and circular buffer model. use SSD as a circular >> write buffer, write flush thread stores incoming writes to this buffer >> sequentially as provider, and writeback thread write those data logs >> sequentially into backing device as consumer. >> >> If writeboost can do that without any random writes, then probably it >> can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster >> sequential read/write performance from SSD. That'll be awesome. >> However, I saw every data log segment in its design has meta data >> header, like dirty_bits, so I guess writeboost has to randomly write >> those data headers of stored data logs in SSD; also, splitting all bio >> into 4KB will hurt its ability to get max raw SSD throughput, modern >> NAND Flash has pages much bigger than 4KB; so overall I think the >> actual benefits writeboost gets from this design will be discounted. > You understand *almost* correctly. > > Writeboost has two circular buffers, not one; RAM buffers and SSD. > The incoming bio is split into 4KB chunks at the virtual make_request > and are NOT directly remapped to the SSD. > As you mentioned, if I designed so, many update on the metadata happens. > That's really bad since SSD is very bad at small update. > > Actually, the 4KB bio is first stored in RAM buffer, which is 512KB large. > There are (512-4)/4=127 4KB bio data stored in the RAM buffer and 4KB metadata > section at the head is made after that. > > The RAM buffer is now called "log" and as you mentioned, flushed to the SSD > as 512KB sequential write. This definitely maximizes throughput and lifetime. > > Unfortunately, this is not always the case because of barrier request > handlings. > But, when the writes is really heavy (e.g. massive dirty page writeback), > Writeboost works as above. > >> The good thing is that it seems writeboost doesn't use garbage >> collection to clean old invalid logs, this will avoid the double >> garage collection effect other caching module has, which essentially >> both caching module and internal SSD will perform garbage collections >> twice. > Yes. And I believe SSDs can remove wear-leveling if I used it as fairly > sequential. > Am I right? Indeed, Writeboost is really SSD frinedly. > >> And one question, how long will be data logs replay time during init, >> if SSD is almost full of dirty data logs? > Sorry, I don't have a data now but it's slow as you may imagine. > I will measure the time on later. > > The major reason is, it needs to read full 512KB segment to calculate > checksum to > know if the log isn't half written. > (Read 500GB SSD that performs 500MB/sec seqread spends 1000secs) > I think making the procedure done in parallel to exploit the full internal > parallelism > inside SSD may improve performance but it's just the matter of coefficient > down from 1 to 1/n. > Definitely, Writeboost isn't fit for a machine that needs reboot frequently > (e.g. desktop). > > There is a way to reduce the init time. We can dump "what is the latest log > written back" > on the superblock. This can skip readings that aren't essential. > > The corresponding code is replay_log_on_cache() function. Please read if you > are > interested. > > Thanks, > > - Akira > > On 12/13/14 3:45 PM, Jianjian Huo wrote: >> If I understand it correctly, the whole idea indeed is very simple, >> the consumer/provider and circular buffer model. use SSD as a circular >> write buffer, write flush thread stores incoming writes to this buffer >> sequentially as provider, and writeback thread write those data logs >> sequentially into backing device as consumer. >> >> If writeboost can do that without any random writes, then probably it >> can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster >> sequential read/write performance from SSD. That'll be awesome. >> However, I saw every data log segment in its design has meta data >> header, like dirty_bits, so I guess writeboost has to randomly write >> those data headers of stored data logs in
[GIT PULL REQUEST] md updates for 3.19
hi Linus, please pull these three patches. I did have a largish set of locking changes queued, but late testing showed they weren't quite as stable as I thought and while I fixed what I found, I decided it safer to delay them a release ... particularly as I'll be AFK for a few weeks. So expect a larger batch next time :-) Thanks, NeilBrow The following changes since commit 3a18ca061311f2f1ee9c44012f89c7436d392117: Merge tag 'ext4_for_linus_urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2014-12-01 20:11:49 -0800) are available in the git repository at: git://neil.brown.name/md/ tags/md/3.19 for you to fetch changes up to f851b60db0fd83a10034c5cc9d9e58c758457b1c: md: Check MD_RECOVERY_RUNNING as well as ->sync_thread. (2014-12-11 10:02:10 +1100) Three fixes for md NeilBrown (2): md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants. md: Check MD_RECOVERY_RUNNING as well as ->sync_thread. kbuild test robot (1): md: fix semicolon.cocci warnings drivers/md/md.c| 38 +++--- drivers/md/raid5.c | 7 +-- 2 files changed, 32 insertions(+), 13 deletions(-) pgphLX3vuo2Yd.pgp Description: OpenPGP digital signature
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 4:33 PM, Al Viro wrote: > > So does SMP - this_cpu_dec() relies on preemption being disabled. No. really. It very much does not. Not on x86, not elsewhere. It's part of the whole point of "this_cpu_p()". They are preemption and interrupt safe. It's the "__this_cpu_op()" ones that need external protection. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression] 83f45fc turns machine's screen off
Hi Daniel, > On Mon, Nov 10, 2014 at 10:19 PM, Daniel Vetter > wrote: >> Adding relevant mailing lists. >> >> >> On Sat, Nov 8, 2014 at 7:34 PM, Emmanuel Benisty wrote: >>> Hi, >>> >>> The following commit permanently turns my screen off when x server is >>> started (i3 330M Ironlake): >>> >>> [83f45fc360c8e16a330474860ebda872d1384c8c] drm: Don't grab an fb >>> reference for the idr >>> >>> Reverting this commit fixed the issue. >> >> This is definitely unexpected. I think we need a bit more data to >> figure out what's going on here: >> - Please boot with drm.debug=0xe added to your kernel cmdline and grab >> the dmesg right after boot-up for both a working or broken kernel. > > Please see attached files. > >> - Are you using any special i915 cmdline options? > > Nope. Is there anything else I could provide to help fixing this issue? It's still in Linus' tree. Thanks in advance. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 04:14:58PM -0800, Linus Torvalds wrote:
> On Sat, Dec 13, 2014 at 3:47 PM, Al Viro wrote:
> >
> > static inline void mnt_dec_writers(struct mount *mnt)
> > {
> > #ifdef CONFIG_SMP
> > this_cpu_dec(mnt->mnt_pcp->mnt_writers);
> > #else
> > mnt->mnt_writers--;
> > #endif
> > }
> > It's load/modify/store, without any kind of atomicity; get preempted in the
> > middle of that sequence by another caller of mnt_dec_writers() and obvious
> > bad
> > things will happen...
>
> Ugh, yes ok, the UP case needs it for the actual counter itself. Ugh.
> What an ugly mess. I'd rather have the preemption disable where it is
> actually *needed*, in that function itself for the UP case (or just
> make it "atomic_t", which would likely be better still.
So does SMP - this_cpu_dec() relies on preemption being disabled. On x86
we might get away with that, what with having it compiled into decl %gs:const,
but on generic it turns into
*raw_cpu_ptr() -= 1;
and compiler has every right to turn it into
p = raw_cpu_ptr();
(*p)--;
again, with no locking. Lose the timeslice in the middle of that and you
are risking to get a different CPU when you are scheduled again, with
another process doing this_cpu_dec() on your old CPU. Have fun - two
non-atomic decrements of the same variable by different CPUs in parallel...
We really need preemtion disabled there, UP or no UP.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 3:47 PM, Al Viro wrote:
>
> static inline void mnt_dec_writers(struct mount *mnt)
> {
> #ifdef CONFIG_SMP
> this_cpu_dec(mnt->mnt_pcp->mnt_writers);
> #else
> mnt->mnt_writers--;
> #endif
> }
> It's load/modify/store, without any kind of atomicity; get preempted in the
> middle of that sequence by another caller of mnt_dec_writers() and obvious bad
> things will happen...
Ugh, yes ok, the UP case needs it for the actual counter itself. Ugh.
What an ugly mess. I'd rather have the preemption disable where it is
actually *needed*, in that function itself for the UP case (or just
make it "atomic_t", which would likely be better still.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: bluetooth: Add hci_h4p driver
Hi Pavel, >>> My notes say that Marcel wanted different filenames, but I'd need >>> advice exactly what filenames. I guess platform data supprort should >>> be removed altogether, rather than renamed. >> >> Yes, the platform support should go away. This should be purely based on DT. >> >> Can you also start using git format-patch so that patches get a diffstat. > > So the rest of filenames look ok? I have not looked at the patch or the filenames at all. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: query on DWC3
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of sundeep subbaraya
> Sent: Friday, December 12, 2014 9:13 PM
>
> Hi Felipe,
>
> In DWC3 driver, for three stage Control OUT transfer there is a check:
>
>else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
>
> && (dep->number == 0)) {.
> }
>
> I understand that we check for alignment of sizes and if not we
> prepare trb with maxpacket and enable interrupt on short packet. In
> databook I could not find anything related to this, it talks only
> about addresses should be aligned. In Control transfer programming
> model there is no difference between Control OUT or IN transfer, if
> three stage transfer - prepare trb with length wLength. Initially I
> followed this and not able to receive data on EP0 OUT.:( .After adding
> the above check it is working. Please help me to understand why we do
> this?
Hi Sundeep,
Please see section 8.2.3.3 "Buffer Size Rules and Zero-Length Packets"
in the databook:
For OUT endpoints, the following rules apply:
- The total size of a Buffer Descriptor must be a multiple of
MaxPacketSize
The wording may be a little confusing, it actually means that the size
of the data buffer for OUT endpoints must be a multiple of MaxPacketSize.
Section 8.2.5 states it more clearly:
- An OUT transfer’s transfer size (Total TRB buffer allocation)
must be a multiple of MaxPacketSize even if software is expecting
a fixed non-multiple of MaxPacketSize transfer from the Host.
This rule applies to all OUT endpoint types, including Control endpoints.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: bluetooth: Add hci_h4p driver
Hi! > > My notes say that Marcel wanted different filenames, but I'd need > > advice exactly what filenames. I guess platform data supprort should > > be removed altogether, rather than renamed. > > Yes, the platform support should go away. This should be purely based on DT. > > Can you also start using git format-patch so that patches get a diffstat. So the rest of filenames look ok? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 03:38:57PM -0800, Linus Torvalds wrote:
> On Sat, Dec 13, 2014 at 3:35 PM, Al Viro wrote:
> >
> > Er... There's much more direct reason - suppose we get a timer interrupt
> > right in the middle of mnt_drop_write(). And lost the timeslice.
>
> So?
>
> You didn't have preemption disabled in *between* the mnt_want_write()
> and mnt_drop_write(), there's absolutely no reason to have it inside
> of them.
>
> Nobody cares if you get preempted and go away for a while. It's
> exactly equivalent to sleeping while doing the write that the pair was
> protecting.
>
> Seriously, the preemption disable looks like just voodoo code. It
> doesn't protect anything, it doesn't fix anything, it doesn't change
> anything. All it does is disable preemption over a random sequence of
> code.
Huh? Sure, we can enable it after mnt_inc_writers() and disable just prior to
mnt_dec_writers(), but we absolutely *do* need it disabled during either.
Is that what you are talking about? If so, yes, we can do that.
But that applies only to __mnt_want_write() - __mnt_drop_write() is pure
mnt_dec_writers() and we can't call that one with preemption enabled.
Seriously, look at the mnt_dec_writers():
static inline void mnt_dec_writers(struct mount *mnt)
{
#ifdef CONFIG_SMP
this_cpu_dec(mnt->mnt_pcp->mnt_writers);
#else
mnt->mnt_writers--;
#endif
}
It's load/modify/store, without any kind of atomicity; get preempted in the
middle of that sequence by another caller of mnt_dec_writers() and obvious bad
things will happen...
Al, really confused by now...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 3:35 PM, Al Viro wrote: > > Er... There's much more direct reason - suppose we get a timer interrupt > right in the middle of mnt_drop_write(). And lost the timeslice. So? You didn't have preemption disabled in *between* the mnt_want_write() and mnt_drop_write(), there's absolutely no reason to have it inside of them. Nobody cares if you get preempted and go away for a while. It's exactly equivalent to sleeping while doing the write that the pair was protecting. Seriously, the preemption disable looks like just voodoo code. It doesn't protect anything, it doesn't fix anything, it doesn't change anything. All it does is disable preemption over a random sequence of code. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 02:59:43PM -0800, Linus Torvalds wrote: > Side note: I think I've found a real potential lockup bug in > fs/namespace.c, but afaik it could only trigger with the RT patches. > Except it won't with the RT patches, I guess. So it looks like you could > have:\ > > - mnt_make_readonly() sets that bit > - gets preempted with the RT patches > - we run mnt_want_write() on all CPU's, which disables preemption and > waits for the bit to be cleared > - nothing happens. > > This is clearly not what happens in your lockup, but it does seem to > be a potential issue for the RT kernel. > > Added Al and Thomas to the cc, for fs/namespace.c and RT kernel > respectively. Maybe the RT patches already fix this, I didn't actually > check. I agree that it's a thing to keep in mind on the RT side of things, but IMO it belongs in RT patches... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 03:09:59PM -0800, Linus Torvalds wrote: > On Sat, Dec 13, 2014 at 2:59 PM, Linus Torvalds > wrote: > > The generic code does that mnt_want_write/mnt_drop_write > > dance adound the call to setxattr, and that in turn does > > > > while (ACCESS_ONCE(mnt->mnt.mnt_flags) & MNT_WRITE_HOLD) > > cpu_relax(); > > > > with preemption explicitly disabled. > > Btw, I see no reason why mnt_want_write/mnt_drop_write disables > preemption. They don't care, they just care about the ordering of the > write counts and the MNT_WRITE_HOLD bit. It's the code that sets the > bit that should care, afaik. But maybe I'm missing something. Er... There's much more direct reason - suppose we get a timer interrupt right in the middle of mnt_drop_write(). And lost the timeslice. On UP we have mnt->mnt_writers--, with no locks held. On SMP we have this_cpu_dec() instead, also without any locks. You really don't want to lose the timeslice in the middle of either... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bluetooth: Add hci_h4p driver
Hi Pavel, > Add hci_h4p bluetooth driver to staging tree. This device is used > for example on Nokia N900 cell phone. > > Signed-off-by: Pavel Machek > Thanks-to: Sebastian Reichel > Thanks-to: Joe Perches > > --- > > > I'd prefer to resurect the driver in staging/ in order not to lose > history, but Marcel wanted to treat it as new submission, so I'm doing > that. that history is in linux.git now for all times. No need to repeat it. I rather not play around with that again. Lets get a minimal driver merged so we can give people something to improve. > > Firmware load was converted to hci_cmd_sync(). Unfortunately, the > firmware is needed after every open/close, so the setup mechanism does > not quite fit. (But code is now way cleaner). What is the reason for that? Does it mean that the device will always loose all its settings when powering it down. Do we know why that is that way and can we maybe change it? If there is no way around this, we can introduce a quirk that will always run hdev->setup. However if the device keeps forgetting all settings all the time, that means it will also keep forgetting its address. So that power on procedure will be wasting time. We would need to check if we can make it so that it only has unconfigured state once and then keeps remembering the address even if we have to re-program it every time. > Device tree bindings work for me, but they are not yet official and I > expect some more fun there. > > Hacks surrounding bluetooth address were removed; this results in > working driver with address that is probably not unique. Just set HCI_QUIRK_INVALID_BDADDR and let someone deal with that in userspace. You can use the btmgmt public-addr command for testing. In the end someone needs to write a small tool that users mgmt interface and listens for unconfigured controllers, reads the address from whatever storage it is, uses the Set Public Address command and that is it. On the kernel side you need to add hdev->set_bdaddr support. For the Broadcom based devices you can copy it from the btusb.c driver. > HCI_QUIRK_RESET_ON_CLOSE will need to be investigated some more. Why was that needed again? If the device loses power anyway, then that seems wasteful. Also the core changed to make sure it resets all settings on power down correctly. > My notes say that Marcel wanted different filenames, but I'd need > advice exactly what filenames. I guess platform data supprort should > be removed altogether, rather than renamed. Yes, the platform support should go away. This should be purely based on DT. Can you also start using git format-patch so that patches get a diffstat. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
Hi,
On Fri, Dec 12, 2014 at 11:24 PM, Kishon Vijay Abraham I wrote:
> hi,
>
> On Saturday 13 December 2014 05:49 AM, Doug Anderson wrote:
>> Yunzhi,
>>
>> On Fri, Dec 12, 2014 at 7:07 AM, Yunzhi Li wrote:
>>> This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
>>> currently this driver can support RK3288. The RK3288 SoC have
>>> three independent USB PHY IPs which are all configured through a
>>> set of registers located in the GRF (general register files)
>>> module.
>>>
>>> Signed-off-by: Yunzhi Li
>>>
>>> ---
>>>
>>> Changes in v7:
>>> - Accept Kishon's comments to use phandle args to find a phy
>>> struct directly and get rid of using a custom of_xlate
>>> function.
>>
>> I'm going to assume you didn't test this version, since it doesn't
>> work for me. At suspend time power is high and my printouts in the
>> powerup/powerdown code aren't called...
>>
>>
>>> + for_each_available_child_of_node(dev->of_node, child) {
>>> + rk_phy = devm_kzalloc(dev, sizeof(*rk_phy), GFP_KERNEL);
>>> + if (!rk_phy)
>>> + return -ENOMEM;
>>> +
>>> + if (of_property_read_u32(child, "reg", _offset)) {
>>> + dev_err(dev, "missing reg property in node %s\n",
>>> + child->name);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + rk_phy->reg_offset = reg_offset;
>>> + rk_phy->reg_base = grf;
>>> +
>>> + rk_phy->clk = of_clk_get_by_name(child, "phyclk");
>>> + if (IS_ERR(rk_phy->clk))
>>> + rk_phy->clk = NULL;
>>> +
>>> + rk_phy->phy = devm_phy_create(dev, child, );
>>> + if (IS_ERR(rk_phy->phy)) {
>>> + dev_err(dev, "failed to create PHY\n");
>>> + return PTR_ERR(rk_phy->phy);
>>> + }
>>> + phy_set_drvdata(rk_phy->phy, rk_phy);
>>> + }
>>> +
>>> + phy_provider = devm_of_phy_provider_register(dev,
>>> of_phy_simple_xlate);
>>
>> I think your bug is here. I think you now need to register 3 phy
>> providers, not just one.
>
> No there should be only one phy provider. It means the bug is elsewhere.
Ah. That's what I get for testing on a backported kernel. I bet it's
because I'm missing:
2a4c370 phy: core: Fix of_phy_provider_lookup to return PHY provider
for sub node
Hrm, that made things better, but I still only got one printout when I
expected 3 (one for each user of the PHY). I bet there are more picks
I need then... :-/ Ah, yup. When I pick the whole load of PHY
related stuff then I get all 3. :)
I'll do more testing when I have more time and post up a Tested-by, then...
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 2:59 PM, Linus Torvalds wrote: > The generic code does that mnt_want_write/mnt_drop_write > dance adound the call to setxattr, and that in turn does > > while (ACCESS_ONCE(mnt->mnt.mnt_flags) & MNT_WRITE_HOLD) > cpu_relax(); > > with preemption explicitly disabled. Btw, I see no reason why mnt_want_write/mnt_drop_write disables preemption. They don't care, they just care about the ordering of the write counts and the MNT_WRITE_HOLD bit. It's the code that sets the bit that should care, afaik. But maybe I'm missing something. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] vt: fix console lock vs. kernfs s_active lock order
Currently there is a lock order problem between the console lock and the
kernfs s_active lock of the console driver's bind sysfs entry. When
writing to the sysfs entry the lock order is first s_active then console
lock, when unregistering the console driver via
do_unregister_con_driver() the order is the opposite. See the below
bugzilla reference for one instance of a lockdep backtrace.
Fix this by unregistering the console driver from a deferred work, where
we can safely drop the console lock while unregistering the device and
corresponding sysfs entries (which in turn acquire s_active). Note that
we have to keep the console driver slot in the registered_con_driver
array reserved for the driver that's being unregistered until it's fully
removed. Otherwise a concurrent call to do_register_con_driver could
try to reuse the same slot and fail when registering the corresponding
device with a minor index that's still in use.
Note that the referenced bug report contains two dmesg logs with two
distinct lockdep reports: [1] is about a locking scenario involving
s_active, console_lock and the fb_notifier list lock, while [2] is
about a locking scenario involving only s_active and console_lock.
In [1] locking fb_notifier triggers the lockdep warning only because
of its dependence on console_lock, otherwise case [1] is the same
s_active<->console_lock dependency problem fixed by this patch.
Before this change we have the following locking scenarios involving
the 3 locks:
a) via do_unregister_framebuffer()->...->do_unregister_con_driver():
1. console lock 2. fb_notifier lock 3. s_active lock
b) for example via give_up_console()->do_unregister_con_driver():
1. console lock 2. s_active lock
c) via vt_bind()/vt_unbind():
1. s_active lock 2. console lock
Since c) is the console bind sysfs entry's write code path we can't
change the locking order there. We can only fix this issue by removing
s_active's dependence on the other two locks in a) and b). We can do
this only in the vt code which owns the corresponding sysfs entry, so
that after the change we have:
a) 1. console lock 2. fb_notifier lock
b) 1. console lock
c) 1. s_active lock 2. console lock
d) in the new con_driver_unregister_callback():
1. s_active lock
[1] https://bugs.freedesktop.org/attachment.cgi?id=87716
[2] https://bugs.freedesktop.org/attachment.cgi?id=107602
v2:
- get console_lock earlier in con_driver_unregister_callback(), so we
protect the following console driver field assignments there
- add code coment explaining the reason for deferring the sysfs entry
removal
- add a third paragraph to the commit message explaining why there are
two distinct lockdep reports and that this issue is independent of
fb/fbcon. (Peter Hurley)
v3:
- clarify further the third paragraph
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 61 -
1 file changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 5dd1880..c19333f 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -108,6 +108,7 @@
#define CON_DRIVER_FLAG_MODULE 1
#define CON_DRIVER_FLAG_INIT 2
#define CON_DRIVER_FLAG_ATTR 4
+#define CON_DRIVER_FLAG_ZOMBIE 8
struct con_driver {
const struct consw *con;
@@ -153,6 +154,7 @@ static int set_vesa_blanking(char __user *p);
static void set_cursor(struct vc_data *vc);
static void hide_cursor(struct vc_data *vc);
static void console_callback(struct work_struct *ignored);
+static void con_driver_unregister_callback(struct work_struct *ignored);
static void blank_screen_t(unsigned long dummy);
static void set_palette(struct vc_data *vc);
@@ -180,6 +182,7 @@ static int blankinterval = 10*60;
core_param(consoleblank, blankinterval, int, 0444);
static DECLARE_WORK(console_work, console_callback);
+static DECLARE_WORK(con_driver_unregister_work,
con_driver_unregister_callback);
/*
* fg_console is the current virtual console,
@@ -3597,7 +3600,8 @@ static int do_register_con_driver(const struct consw
*csw, int first, int last)
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
con_driver = _con_driver[i];
- if (con_driver->con == NULL) {
+ if (con_driver->con == NULL &&
+ !(con_driver->flag & CON_DRIVER_FLAG_ZOMBIE)) {
con_driver->con = csw;
con_driver->desc = desc;
con_driver->node = i;
@@ -3660,16 +3664,20 @@ int do_unregister_con_driver(const struct consw *csw)
if (con_driver->con == csw &&
con_driver->flag & CON_DRIVER_FLAG_MODULE) {
- vtconsole_deinit_device(con_driver);
- device_destroy(vtconsole_class,
- MKDEV(0, con_driver->node));
+ /*
+*
Re: frequent lockups in 3.18rc4
Side note: I think I've found a real potential lockup bug in fs/namespace.c, but afaik it could only trigger with the RT patches. I'm looking at what lxsetattr() does, since you had that lxsetattr-only lockup. I doubt it's really related to lxsetattr(), but whatever. The generic code does that mnt_want_write/mnt_drop_write dance adound the call to setxattr, and that in turn does while (ACCESS_ONCE(mnt->mnt.mnt_flags) & MNT_WRITE_HOLD) cpu_relax(); with preemption explicitly disabled. It's waitingo for mnt_make_readonly() to go away if it is racing with it. But mnt_make_readonly() doesn't actually explicitly disable preemption while it sets that MNT_WRITE_HOLD bit. Instead, it depends on lock_mount_hash() to disable preemption for it. Which it does, because it is a seq-writelock, which uses a spinlock, which will disable preemption. Except it won't with the RT patches, I guess. So it looks like you could have:\ - mnt_make_readonly() sets that bit - gets preempted with the RT patches - we run mnt_want_write() on all CPU's, which disables preemption and waits for the bit to be cleared - nothing happens. This is clearly not what happens in your lockup, but it does seem to be a potential issue for the RT kernel. Added Al and Thomas to the cc, for fs/namespace.c and RT kernel respectively. Maybe the RT patches already fix this, I didn't actually check. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] __uX types should not be neccessary in-kernel
For in-kernel use, uX types should be enough, no need to use __uX.
Signed-off-by: Pavel Machek
diff --git a/include/net/bluetooth/bluetooth.h
b/include/net/bluetooth/bluetooth.h
index 58695ff..a0f0154 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -58,8 +58,8 @@
#define BT_SECURITY4
struct bt_security {
- __u8 level;
- __u8 key_size;
+ u8 level;
+ u8 key_size;
};
#define BT_SECURITY_SDP0
#define BT_SECURITY_LOW1
@@ -76,7 +76,7 @@ struct bt_security {
#define BT_POWER 9
struct bt_power {
- __u8 force_active;
+ u8 force_active;
};
#define BT_POWER_FORCE_ACTIVE_OFF 0
#define BT_POWER_FORCE_ACTIVE_ON 1
@@ -110,7 +110,7 @@ struct bt_power {
#define BT_VOICE 11
struct bt_voice {
- __u16 setting;
+ u16 setting;
};
#define BT_VOICE_TRANSPARENT 0x0003
@@ -170,7 +170,7 @@ static inline const char *state_to_string(int state)
/* BD Address */
typedef struct {
- __u8 b[6];
+ u8 b[6];
} __packed bdaddr_t;
/* BD Address type */
@@ -178,7 +178,7 @@ typedef struct {
#define BDADDR_LE_PUBLIC 0x01
#define BDADDR_LE_RANDOM 0x02
-static inline bool bdaddr_type_is_valid(__u8 type)
+static inline bool bdaddr_type_is_valid(u8 type)
{
switch (type) {
case BDADDR_BREDR:
@@ -190,7 +190,7 @@ static inline bool bdaddr_type_is_valid(__u8 type)
return false;
}
-static inline bool bdaddr_type_is_le(__u8 type)
+static inline bool bdaddr_type_is_le(u8 type)
{
switch (type) {
case BDADDR_LE_PUBLIC:
@@ -260,15 +260,15 @@ struct sock *bt_accept_dequeue(struct sock *parent,
struct socket *newsock);
/* Skb helpers */
struct l2cap_ctrl {
- __u8sframe:1,
+ u8 sframe:1,
poll:1,
final:1,
fcs:1,
sar:2,
super:2;
- __u16 reqseq;
- __u16 txseq;
- __u8retries;
+ u16 reqseq;
+ u16 txseq;
+ u8 retries;
};
struct hci_dev;
@@ -282,11 +282,11 @@ struct hci_req_ctrl {
};
struct bt_skb_cb {
- __u8 pkt_type;
- __u8 incoming;
- __u16 opcode;
- __u16 expect;
- __u8 force_active;
+ u8 pkt_type;
+ u8 incoming;
+ u16 opcode;
+ u16 expect;
+ u8 force_active;
struct l2cap_chan *chan;
struct l2cap_ctrl control;
struct hci_req_ctrl req;
@@ -337,7 +337,7 @@ out:
return NULL;
}
-int bt_to_errno(__u16 code);
+int bt_to_errno(u16 code);
int hci_sock_init(void);
void hci_sock_cleanup(void);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 2:36 PM, Dave Jones wrote: > > Ok, I think we can rule out preemption. I just checked on it, and > found it wedged. Ok, one more. Mind checking what happens without CONFIG_DEBUG_PAGEALLOC? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bluetooth: Add hci_h4p driver
Add hci_h4p bluetooth driver to staging tree. This device is used
for example on Nokia N900 cell phone.
Signed-off-by: Pavel Machek
Thanks-to: Sebastian Reichel
Thanks-to: Joe Perches
---
I'd prefer to resurect the driver in staging/ in order not to lose
history, but Marcel wanted to treat it as new submission, so I'm doing
that.
Firmware load was converted to hci_cmd_sync(). Unfortunately, the
firmware is needed after every open/close, so the setup mechanism does
not quite fit. (But code is now way cleaner).
Device tree bindings work for me, but they are not yet official and I
expect some more fun there.
Hacks surrounding bluetooth address were removed; this results in
working driver with address that is probably not unique.
HCI_QUIRK_RESET_ON_CLOSE will need to be investigated some more.
My notes say that Marcel wanted different filenames, but I'd need
advice exactly what filenames. I guess platform data supprort should
be removed altogether, rather than renamed.
Thanks,
Pavel
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 4547dc2..0fc7d3a 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -243,4 +243,14 @@ config BT_WILINK
Say Y here to compile support for Texas Instrument's WiLink7 driver
into the kernel or say M to compile it as module (btwilink).
+config BT_NOKIA_H4P
+ tristate "HCI driver with H4 Nokia extensions"
+ depends on ARCH_OMAP
+ help
+ Bluetooth HCI driver with H4 extensions. This driver provides
+ support for H4+ Bluetooth chip with vendor-specific H4 extensions.
+
+ Say Y here to compile support for h4 extended devices into the kernel
+ or say M to compile it as module (btnokia_h4p).
+
endmenu
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9fe8a87..ec7074fe 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -31,4 +31,7 @@ hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o
hci_uart-$(CONFIG_BT_HCIUART_3WIRE)+= hci_h5.o
hci_uart-objs := $(hci_uart-y)
+obj-$(CONFIG_BT_NOKIA_H4P) += hci_h4p.o
+hci_h4p-objs := nokia_core.o nokia_fw.o nokia_uart.o
+
ccflags-y += -D__CHECK_ENDIAN__
new file mode 100644
index 000..6445a99
--- /dev/null
+++ b/drivers/bluetooth/hci_h4p.h
@@ -0,0 +1,234 @@
+/*
+ * This file is part of Nokia H4P bluetooth driver
+ *
+ * Copyright (C) 2005-2008 Nokia Corporation.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#ifndef __DRIVERS_BLUETOOTH_H4P_H
+#define __DRIVERS_BLUETOOTH_H4P_H
+
+#include
+#include
+#include
+
+#include
+
+#define UART_SYSC_OMAP_RESET 0x03
+#define UART_SYSS_RESETDONE0x01
+#define UART_OMAP_SCR_EMPTY_THR0x08
+#define UART_OMAP_SCR_WAKEUP 0x10
+#define UART_OMAP_SSR_WAKEUP 0x02
+#define UART_OMAP_SSR_TXFULL 0x01
+
+#define UART_OMAP_SYSC_IDLEMODE0x03
+#define UART_OMAP_SYSC_IDLEMASK(3 << UART_OMAP_SYSC_IDLEMODE)
+
+#define UART_OMAP_SYSC_FORCE_IDLE (0 << UART_OMAP_SYSC_IDLEMODE)
+#define UART_OMAP_SYSC_NO_IDLE (1 << UART_OMAP_SYSC_IDLEMODE)
+#define UART_OMAP_SYSC_SMART_IDLE (2 << UART_OMAP_SYSC_IDLEMODE)
+
+#define H4P_TRANSFER_MODE 1
+#define H4P_SCHED_TRANSFER_MODE2
+#define H4P_ACTIVE_MODE3
+
+struct h4p_info {
+ struct timer_list lazy_release;
+ struct hci_dev *hdev;
+ spinlock_t lock;
+
+ void __iomem *uart_base;
+ unsigned long uart_phys_base;
+ int irq;
+ struct device *dev;
+ u8 chip_type;
+ u8 bt_wakeup_gpio;
+ u8 host_wakeup_gpio;
+ u8 reset_gpio;
+ u8 reset_gpio_shared;
+ u8 bt_sysclk;
+ u8 man_id;
+ u8 ver_id;
+
+ struct sk_buff_head fw_queue;
+ struct sk_buff *alive_cmd_skb;
+ struct completion init_completion;
+ struct completion fw_completion;
+ struct completion test_completion;
+ int fw_error;
+ int init_error;
+
+ struct sk_buff_head txq;
+
+ struct sk_buff *rx_skb;
+ long rx_count;
+ unsigned long rx_state;
+ unsigned long garbage_bytes;
+
+ bdaddr_t bd_addr;
+ struct sk_buff_head *fw_q;
+
+ int pm_enabled;
+ int
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 11:59:15AM -0500, Dave Jones wrote: > On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote: > > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote: > > > > > > Something that's still making me wonder if it's some kind of hardware > > > problem is the non-deterministic nature of this bug. > > > > I'd expect it to be a race condition, though. Which can easily cause > > these kinds of issues, and the timing will be pretty random even if > > the load is very regular. > > > > And we know that the scheduler has an integer overflow under Sasha's > > loads, although I didn't hear anything from Ingo and friends about it. > > Ingo/Peter, you were cc'd on that report, where at least one of the > > multiplcations in wake_affine() ended up overflowing.. > > > > Some scheduler thing that overflows only under heavy load, and screws > > up scheduling could easily account for the RCU thread thing. I see it > > *less* easily accounting for DaveJ's case, though, because the > > watchdog is running at RT priority, and the scheduler would have to > > screw up much more to then not schedule an RT task, but.. > > > > I'm also not sure if the bug ever happens with preemption disabled. > > Bah, so I see some watchdog traces with preemption off, and that then > taints the kernel, and the fuzzing stops. I'll hack something up > so it ignores the taint and keeps going. All I really care about here > is the "machine hangs completely" case, which the trace below didn't > hit.. Ok, I think we can rule out preemption. I just checked on it, and found it wedged. Here's what I got over usb-serial. (tainting was from previous post). [76132.505590] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [trinity-c8:19387] [76132.506438] CPU: 3 PID: 19387 Comm: trinity-c8 Tainted: GW 3.18.0+ #102 [loadavg: 148.33 137.64 140.62 48/406 19489] [76132.507293] task: 880226a9ada0 ti: 8801aee08000 task.ti: 8801aee08000 [76132.508149] RIP: 0010:[] [] kernel_map_pages+0xbc/0x120 [76132.509022] RSP: :8801aee0ba08 EFLAGS: 0202 [76132.509889] RAX: 001407e0 RBX: RCX: 00140760 [76132.510760] RDX: 0202 RSI: 88000188 RDI: 0001 [76132.511636] RBP: 8801aee0ba68 R08: 8063 R09: 8800 [76132.512512] R10: R11: R12: 0001 [76132.513394] R13: R14: 01b5f000 R15: [76132.514269] FS: 7fb1263cc740() GS:88024460() knlGS: [76132.515152] CS: 0010 DS: ES: CR0: 80050033 [76132.516055] CR2: 0277dff8 CR3: 00023329 CR4: 001407e0 [76132.516957] DR0: 7f07ef05a000 DR1: 7fb7761bb000 DR2: [76132.517858] DR3: DR6: fffe0ff0 DR7: 0600 [76132.518757] Stack: [76132.519650] 880097a32000 8801aee0ba08 0003 [76132.520590] 00010001 00097a31 [76132.521530] 78052420 8802447d7348 0001 [76132.522447] Call Trace: [76132.523359] [] get_page_from_freelist+0x4a4/0xaa0 [76132.524281] [] __alloc_pages_nodemask+0x22e/0xb40 [76132.525205] [] ? local_clock+0x25/0x30 [76132.526135] [] ? __lock_acquire.isra.31+0x22c/0x9f0 [76132.527065] [] ? release_pages+0x1bd/0x270 [76132.528004] [] ? lock_release_holdtime.part.24+0xf/0x190 [76132.528944] [] alloc_pages_vma+0xee/0x1b0 [76132.529883] [] ? do_wp_page+0xca/0x770 [76132.530823] [] ? __might_sleep+0x1f/0x140 [76132.531770] [] do_wp_page+0xca/0x770 [76132.532705] [] handle_mm_fault+0x6cb/0xe90 [76132.533633] [] ? __do_page_fault+0x198/0x5c0 [76132.534561] [] __do_page_fault+0x1fc/0x5c0 [76132.535465] [] ? _raw_spin_unlock_irq+0x30/0x40 [76132.536372] [] ? finish_task_switch+0x7d/0x120 [76132.537269] [] ? finish_task_switch+0x3f/0x120 [76132.538154] [] ? __schedule+0x352/0x8c0 [76132.539043] [] ? trace_hardirqs_off_thunk+0x3a/0x3c [76132.539921] [] do_page_fault+0xc/0x10 [76132.540791] [] page_fault+0x22/0x30 [76132.541654] Code: 65 48 33 04 25 28 00 00 00 75 75 48 83 c4 50 5b 41 5c 5d c3 0f 1f 00 9c 5a fa 0f 20 e0 48 89 c1 80 e1 7f 0f 22 e1 0f 22 e0 52 9d cf 66 90 49 bc 00 00 00 00 00 88 ff ff 48 63 f6 49 01 fc 48 [76132.543541] sending NMI to other CPUs: [76132.544438] NMI backtrace for cpu 1 [76132.545300] CPU: 1 PID: 17326 Comm: trinity-c93 Tainted: GW 3.18.0+ #102 [loadavg: 148.33 137.64 140.62 48/406 19489] [76132.546193] task: 8800098b2da0 ti: 8801aec38000 task.ti: 8801aec38000 [76132.547085] RIP: 0010:[] [] __lock_acquire.isra.31+0x142/0x9f0 [76132.547987] RSP: 0018:8801aec3bd58 EFLAGS: 0082 [76132.548883] RAX: RBX: 8800098b2da0 RCX: 0002 [76132.549786] RDX: RSI:
Re: [CFT] Can I get some Tested-By's on this series?
sorry, I've only been back from the road the days... Two tries at compiling have failed (infrastructure problems, not your set), hoping to fire of another build tonight.On 12/10/14 16:48 Serge Hallyn wrote: Quoting Eric W. Biederman (ebied...@xmission.com): > > Will people please test these patches with their container project? > > These changes break container userspace (hopefully in a minimal way) if > I could have that confirmed by testing I would really appreciate it. I > really don't want to send out a bug fix that accidentally breaks > userspace again. > > The only issue sort of under discussion is if there is a better name for > /proc//setgroups, and the name of the file will not affect the > functionality of the patchset. > > With the code reviewed and written in simple obviously correct, easily > reviewable ways I am hoping/planning to send this to Linus ASAP. > > Eric Is there a git tree we can clone? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm pull waiting on other trees
On Thu, Dec 11, 2014 at 11:13 PM, Simon Horman wrote: > > If you give me a specific tag or commit id I can investigate further but > I'm assuming it is renesas-dt-du-for-v3.19 (0ee56d403549fd97d) then it has > been accepted by the by Arnd (CCed) and I believe he or one of the other > Arm SoC maintainers (also CCed) have a plan to submit it to Linus (most > likely as part of a larger pull-request). That commit is in my tree, and has been for a few days. The IOMMU tree was also merged yesterday, so hopefully everything drm needs is there now, Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] TTY: add support for "tty slave" devices.
On Sat, Dec 13, 2014 at 5:46 PM, Sebastian Reichel wrote: > Hi, > > On Fri, Dec 12, 2014 at 11:59:20AM +, Grant Likely wrote: >> [...] >> > --- a/Documentation/devicetree/bindings/serial/of-serial.txt >> > +++ b/Documentation/devicetree/bindings/serial/of-serial.txt >> > @@ -39,6 +39,10 @@ Optional properties: >> >driver is allowed to detect support for the capability even without this >> >property. >> > >> > +Optional child node: >> > +- a platform device listed as a child node will be probed and >> > + powered-on whenever the tty is in use (open). >> > + >> >> The biggest concern I have is what happens to nodes that already have >> child devices that /don't/ match this use case? It is possible that some >> UART nodes already have a child node used to store other data. There are >> two ways to handle this; 1) add a new bool property that indicates the >> child nodes are tty slave devices, or 2) Make each uart driver >> explicitly enable the feature so that driver authors can check if it is >> a problem for that device. I personally would suggest #1 because then it >> can be enabled in generic code. > > maybe simple depend on the compatible value? If the UART node has > child nodes to store other random data it should not have a > compatible value? That's not a given. It is entirely possible that drivers have used compatible in the child nodes. However, I may be stirring up trouble for nothing. We could enable it for all child nodes that have a compatible value, and then blacklist any parent nodes that want to use a different behaviour. If someone complains then we will fix it. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] kselftest-3.19-rc1
On Tue, Dec 9, 2014 at 11:42 AM, Shuah Khan wrote: > > Please pull the following kselftest updates for 3.19-rc1. Details > in the singed tag: Gaah. Why do you do this to me? > g...@gitolite.kernel.org:/pub/scm/linux/kernel/git/shuah/linux-kselftest > fixes That's the wrong format, but it's also the wrong branch name. What it *should* have said is git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/kselftest-3.19-rc1 which is actually publicly accessible, and has the right tag name. EXCEPT THAT'S WRONG TOO! The actual kselftest-3.19-rc1 tag doesn't point to the commits in fixes at all! It points to commit 0df1f2487d2f, which is my 3.18-rc3 commit. Please fix your script/workflow. I'm not pulling this mess. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: goldfish: Fix minor coding style
On Sat, Dec 13, 2014 at 07:07:05PM +, One Thousand Gnomes wrote: > > Pointless churn. It makes it less readable if anything, and it removes > the type safety as you are now checking against 0 not (void *)0 > > NAK > > Alan The type safety is an interesting point I was not aware of. Just in case, do you have something for me on your todo list? -- Cheers, Loïc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] vt: fix console lock vs. kernfs s_active lock order
Currently there is a lock order problem between the console lock and the
kernfs s_active lock of the console driver's bind sysfs entry. When
writing to the sysfs entry the lock order is first s_active then console
lock, when unregistering the console driver via
do_unregister_con_driver() the order is the opposite. See the below
bugzilla reference for one instance of a lockdep backtrace.
Fix this by unregistering the console driver from a deferred work, where
we can safely drop the console lock while unregistering the device and
corresponding sysfs entries (which in turn acquire s_active). Note that
we have to keep the console driver slot in the registered_con_driver
array reserved for the driver that's being unregistered until it's fully
removed. Otherwise a concurrent call to do_register_con_driver could
try to reuse the same slot and fail when registering the corresponding
device with a minor index that's still in use.
Note that the referenced bug report contains two dmesg logs with two
distinct lockdep reports: the first one [1] is about a locking scenario
involving s_active, console_lock and the fb_notifier list lock, while
the second [2] is about a locking scenario involving only s_active and
console_lock. In [1] locking fb_notifier triggers the lockdep warning
only because of its dependence on console_lock, otherwise case [1] is
the same s_active<->console_lock dependency problem fixed by this patch.
In other words the fb_notifier lock doesn't contribute to this locking
problem, we always acquire it before both s_active and console_lock.
Thus this locking problem is independent of the fb or fbcon code
(owning the fb_notifier lock) and is instead inherent in the vt code
creating the console bind sysfs entry (and so owning the s_active lock).
[1] https://bugs.freedesktop.org/attachment.cgi?id=87716
[2] https://bugs.freedesktop.org/attachment.cgi?id=107602
v2:
- get console_lock earlier in con_driver_unregister_callback(), so we
protect the following console driver field assignments there
- add code coment explaining the reason for deferring the sysfs entry
removal
- add a third paragraph to the commit message explaining why there are
two distinct lockdep reports and that this issue is independent of
fb/fbcon. (Peter Hurley)
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 61 -
1 file changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 5dd1880..c19333f 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -108,6 +108,7 @@
#define CON_DRIVER_FLAG_MODULE 1
#define CON_DRIVER_FLAG_INIT 2
#define CON_DRIVER_FLAG_ATTR 4
+#define CON_DRIVER_FLAG_ZOMBIE 8
struct con_driver {
const struct consw *con;
@@ -153,6 +154,7 @@ static int set_vesa_blanking(char __user *p);
static void set_cursor(struct vc_data *vc);
static void hide_cursor(struct vc_data *vc);
static void console_callback(struct work_struct *ignored);
+static void con_driver_unregister_callback(struct work_struct *ignored);
static void blank_screen_t(unsigned long dummy);
static void set_palette(struct vc_data *vc);
@@ -180,6 +182,7 @@ static int blankinterval = 10*60;
core_param(consoleblank, blankinterval, int, 0444);
static DECLARE_WORK(console_work, console_callback);
+static DECLARE_WORK(con_driver_unregister_work,
con_driver_unregister_callback);
/*
* fg_console is the current virtual console,
@@ -3597,7 +3600,8 @@ static int do_register_con_driver(const struct consw
*csw, int first, int last)
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
con_driver = _con_driver[i];
- if (con_driver->con == NULL) {
+ if (con_driver->con == NULL &&
+ !(con_driver->flag & CON_DRIVER_FLAG_ZOMBIE)) {
con_driver->con = csw;
con_driver->desc = desc;
con_driver->node = i;
@@ -3660,16 +3664,20 @@ int do_unregister_con_driver(const struct consw *csw)
if (con_driver->con == csw &&
con_driver->flag & CON_DRIVER_FLAG_MODULE) {
- vtconsole_deinit_device(con_driver);
- device_destroy(vtconsole_class,
- MKDEV(0, con_driver->node));
+ /*
+* Defer the removal of the sysfs entries since that
+* will acquire the kernfs s_active lock and we can't
+* acquire this lock while holding the console lock:
+* the unbind sysfs entry imposes already the opposite
+* order. Reset con already here to prevent any later
+* lookup to succeed and mark this slot as zombie, so
+* it won't get reused until we complete the removal
+
[PATCH v2 1/3] vt: fix check for system/busy console drivers when unregistering them
System console drivers (without the CON_DRIVER_FLAG_MODULE flag) and
busy drivers bound to a console (as reported by con_is_bound())
shouldn't be unregistered. The current code checks for the
CON_DRIVER_FLAG_INIT flag but this doesn't really correspond to either
of the above two conditions. CON_DRIVER_FLAG_INIT is set whenever its
associated console's con_startup() function is called, which first
happens when the console driver is registered (so before the console
gets bound) and gets cleared when the console gets unbound. The
purpose of this flag is to show if we need to call con_startup() on a
console before we use it.
Based on the above, do_unregister_con_driver() in its current form will
incorrectly allow unregistering a console driver only if it was never
bound, but will refuse to unregister one that was bound and later
unbound. It will also allow unregistering a system console driver.
Fix this by checking for CON_DRIVER_FLAG_MODULE to allow non-system
console drivers to unregister and prevent system console drivers from
unregistering. Rely on the existing con_is_bound() check earlier in the
function to refuse unregistering a busy console driver.
v2:
- reword the third paragraph to clarify how the fix works (Peter Hurley)
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index b33b00b..1862e89 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3660,7 +3660,7 @@ int do_unregister_con_driver(const struct consw *csw)
struct con_driver *con_driver = _con_driver[i];
if (con_driver->con == csw &&
- con_driver->flag & CON_DRIVER_FLAG_INIT) {
+ con_driver->flag & CON_DRIVER_FLAG_MODULE) {
vtconsole_deinit_device(con_driver);
device_destroy(vtconsole_class,
MKDEV(0, con_driver->node));
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: sysctl: use 'unsigned long' type for 'zero' variable
Hi,
On 12/04/2014 12:25 AM, Andrew Morton wrote:
On Wed, 03 Dec 2014 15:41:21 +0300 Andrey Ryabinin
wrote:
Use the 'unsigned long' type for 'zero' variable to fix this.
Changing type to 'unsigned long' shouldn't affect any other users
of this variable.
Reported-by: Dmitry Vyukov
Fixes: ed4d4902ebdd ("mm, hugetlb: remove hugetlb_zero and hugetlb_infinity")
Signed-off-by: Andrey Ryabinin
---
kernel/sysctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 15f2511..45c45c9 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -120,7 +120,7 @@ static int sixty = 60;
static int __maybe_unused neg_one = -1;
-static int zero;
+static unsigned long zero;
After some (useless) playing around (see the attached patch):
Using
>.extra1=zero,
for proc_doulongvec_minmax doesn't make any sense:
__do_proc_doulongvec_minmax() internally contains
if ((min && val < *min) || (max && val > *max))
continue;
What about just deleting the offending .extra1=zero line?
.extra1=NULL has the same effect as .extra1=
--
Manfred
>From 194e5d4758bb30531bad0907f06f3518002cd8b4 Mon Sep 17 00:00:00 2001
From: Manfred Spraul
Date: Sat, 13 Dec 2014 21:25:27 +0100
Subject: [PATCH] kernel/sysctl.c: Type safe macros
struct ctl_table is used for creating entries in e.g. /proc/sys/kernel.
The structure contains three void * entries and a function pointer, thus
there is the risk of incorrectly mixing types.
The patch create a macro that prevents accidential mixing, it enforces
that the type expected by the function pointer and the three void * are
all of the same type.
Notes:
- From my first impression, most proc entries mix types, and it works,
because (int)1 and (unsigned int)1 are identical.
Thus I'm not sure if this is the right approach.
- the code doesn't compile, it contains an intentional incompatible type
What do you think?
--
Manfred
---
kernel/sysctl.c | 113
1 file changed, 97 insertions(+), 16 deletions(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 15f2511..bc446a6 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -276,6 +276,101 @@ static int min_extfrag_threshold;
static int max_extfrag_threshold = 1000;
#endif
+/*
+ * Type safe macros for creating the sysctl table entries:
+ *
+ * TODO:
+ * - 1) It works.
+ * I.e. it complains when _dointvec is used to assign
+ * to an unsigned int. Unfortunately, this is very common:
+ * * _minmax is used, with min=0 and e.g. max=int_max.
+ * * the variable is actually used as a boolean, thus it doesn't matter
+ * if the user space interface returns -1 or 0x.
+ * * unsigned int zero is used as min
+ * * ...
+ * Thus most error messages would be false positives.
+ *
+ * - 2) The error message is difficult to understand
+ * error: initializer element is not constant
+ */
+
+#define ASSIGN_TYPE_SAFE(param, type) \
+__builtin_choose_expr(__builtin_types_compatible_p(typeof(param), type), \
+param, \
+/* The void expression results in a compile-time error \
+ when assigning the result to something. */ \
+((void)0) \
+)
+
+#define SYSCTL_BUILD_INT_ENTRY_MINMAX(name, entry, min_ptr, max_ptr) \
+ { \
+ .procname = (name), \
+ .data = ASSIGN_TYPE_SAFE(&(entry), int *), \
+ .maxlen = sizeof( (entry) ), \
+ .mode = 0644, \
+ .proc_handler = proc_dointvec_minmax, \
+ .extra1 = ASSIGN_TYPE_SAFE( (min_ptr), int *), \
+ .extra2 = ASSIGN_TYPE_SAFE( (max_ptr), int *) \
+ }
+
+#define SYSCTL_BUILD_ULONG_ENTRY_MINMAX(name, entry, min_ptr, max_ptr) \
+ { \
+ .procname = (name), \
+ .data = ASSIGN_TYPE_SAFE(&(entry), unsigned long *), \
+ .maxlen = sizeof( (entry) ), \
+ .mode = 0644, \
+ .proc_handler = proc_doulongvec_minmax, \
+ .extra1 = ASSIGN_TYPE_SAFE( (min_ptr), unsigned long *), \
+ .extra2 = ASSIGN_TYPE_SAFE( (max_ptr), unsigned long *) \
+ }
+
+#define SYSCTL_BUILD_ENTRY_MINMAX(name, entry, min_ptr, max_ptr) \
+ { \
+ .procname = (name), \
+ .data = &(entry), \
+ .maxlen = sizeof( (entry) ), \
+ .mode = 0644, \
+ .proc_handler = __builtin_choose_expr(__builtin_types_compatible_p(typeof( &(entry)), int *), \
+ proc_dointvec_minmax, \
+ __builtin_choose_expr(__builtin_types_compatible_p(typeof( &(entry)), unsigned long *), \
+ proc_doulongvec_minmax, \
+ ((void)0) ) ), \
+ .extra1 = ASSIGN_TYPE_SAFE( (min_ptr), typeof( &(entry) )), \
+ .extra2 = ASSIGN_TYPE_SAFE( (max_ptr), typeof( &(entry) )) \
+ }
+
+#define SYSCTL_BUILD_INT_ENTRY(name, entry) \
+ { \
+ .procname = (name), \
+ .data = ASSIGN_TYPE_SAFE( &(entry), int *), \
+ .maxlen = sizeof( (entry) ), \
+ .mode = 0644, \
+ .proc_handler = proc_dointvec, \
+ }
+
+#define SYSCTL_BUILD_ULONG_ENTRY(name, entry) \
+ { \
+ .procname = (name), \
+ .data =
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 10:04:08AM -0800, Paul E. McKenney wrote: > On Sat, Dec 13, 2014 at 11:59:15AM -0500, Dave Jones wrote: > > On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote: > > > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote: > > > > > > > > Something that's still making me wonder if it's some kind of hardware > > > > problem is the non-deterministic nature of this bug. > > > > > > I'd expect it to be a race condition, though. Which can easily cause > > > these kinds of issues, and the timing will be pretty random even if > > > the load is very regular. > > > > > > And we know that the scheduler has an integer overflow under Sasha's > > > loads, although I didn't hear anything from Ingo and friends about it. > > > Ingo/Peter, you were cc'd on that report, where at least one of the > > > multiplcations in wake_affine() ended up overflowing.. > > > > > > Some scheduler thing that overflows only under heavy load, and screws > > > up scheduling could easily account for the RCU thread thing. I see it > > > *less* easily accounting for DaveJ's case, though, because the > > > watchdog is running at RT priority, and the scheduler would have to > > > screw up much more to then not schedule an RT task, but.. > > > > > > I'm also not sure if the bug ever happens with preemption disabled. > > > > Bah, so I see some watchdog traces with preemption off, and that then > > taints the kernel, and the fuzzing stops. I'll hack something up > > so it ignores the taint and keeps going. All I really care about here > > is the "machine hangs completely" case, which the trace below didn't > > hit.. > > > > (back to fuzzing almost everything, not just lsetxattr btw) > > Hmmm... This one looks like the RCU grace-period kthread is getting > starved: "idle=b4c/0/0". Is this running with the "dangerous" patch > that sets these kthreads to RT priority? sorry, no. Ran out of time yesterday. I'll try and get to applying that later this evening if I get chance. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
Hello, On Thu, 11 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote: > >> [ 512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5 > > > > Above "#5" is same as previous oops. It means kernel > > is not updated. Or you updated only the IPVS modules after > > applying the both patches? > > I did it with make-kpkg --initrd linux_image which only rebuilt the modules, > correct. I can retry with make clean before building the package I just tested PASV and PORT with 3.12.33 including both patches (seq adj fix + ip_route_me_harder fix) and do not see any crashes in nf_ct_seqadj_set. If you still have problem with FTP send me more info offlist. > > You can also try without FTP tests to see if there > > are oopses in xfrm, so that we can close this topic and then > > to continue for the FTP problem on IPVS lists without > > bothering non-IPVS people. > > > > yeah, it seems that the xfrm issue is away. Thanks for the confirmation! Regards -- Julian Anastasov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Block driver updates for 3.19
Hi Linus, Below is the block driver pull request for 3.19, it sits on top of the core pull request submitted yesterday. It contains: - NVMe updates - The blk-mq conversion from Matias (and others) - A stack of NVMe bug fixes from the nvme tree, mostly from Keith. - Various bug fixes from me, fixing issues in both the blk-mq conversion and generic bugs. - Abort and CPU online fix from Sam. - Hot add/remove fix from Indraneel. - A couple of drbd fixes from the drbd team (Andreas, Lars, Philipp) - With the generic IO stat accounting from 3.19/core, converting md, bcache, and rsxx to use those. From Gu Zheng. - Boundary check for queue/irq mode for null_blk from Matias. Fixes cases where invalid values could be given, causing the device to hang. - The xen blkfront pull request, with two bug fixes from Vitaly. Please pull! git://git.kernel.dk/linux-block.git for-3.19/drivers Andreas Gruenbacher (2): drbd: Minor cleanups drbd: Only use drbd_msg_put_info() in drbd_nl.c Andreea-Cristina Bernat (1): nvme: Replace rcu_assign_pointer() with RCU_INIT_POINTER() Dan Carpenter (1): NVMe: blk_mq_alloc_request() returns error pointers Dan McLeran (2): NVMe: Change nvme_enable_ctrl to set EN and manage CC thru ctrl_config. NVMe: Add shutdown timeout as module parameter. Gu Zheng (4): md/bcache: use generic io stats accounting functions to simplify io stat accounting drbd: use generic io stats accounting functions to simplify io stat accounting md: use generic io stats accounting functions to simplify io stat accounting block/rsxx: use generic io stats accounting functions to simplify io stat accounting Indraneel M (1): NVMe: Fix FS mount issue (hot-remove followed by hot-add) Jens Axboe (13): Merge branch 'for-3.19/core' into for-3.19/drivers NVMe: replace blk_put_request() with blk_mq_free_request() NVMe: nvme_submit_async_admin_req() must use atomic rq allocation NVMe: enable IO stats by default Merge branch 'master' into for-3.19/drivers NVMe: make setup work for devices that don't do INTx NVMe: add ->exit_hctx() hook NVMe: fail pci initialization if the device doesn't have any BARs Merge branch 'for-3.19/core' into for-3.19/drivers NVMe: fix error return checking from blk_mq_alloc_request() Merge branch 'for-jens-3.19' of git://git.kernel.org/.../konrad/xen into for-3.19/drivers NVMe: fix retry/error logic in nvme_queue_rq() NVMe: fix race condition in nvme_submit_sync_cmd() Joe Perches (1): block: Use dma_zalloc_coherent Keith Busch (22): NVMe: Async event request NVMe: Mismatched host/device page size support NVMe: Handling devices incapable of I/O NVMe: Use pci_stop_and_remove_bus_device_locked() NVMe: Whitespace fixes NVMe: Skip orderly shutdown on failed devices NVMe: Call nvme_free_queue directly NVMe: Fix filesystem sync deadlock on removal NVMe: Reference count pci device NVMe: Remove duplicate compat SG_IO code NVMe: Fix SG_IO status values NVMe: Translate NVMe status to errno NVMe: Fix nvmeq waitqueue entry initialization NVMe: Add revalidate_disk callback NVMe: Passthrough IOCTL for IO commands NVMe: Updates for 1.1 spec NVMe: Fix device probe waiting on kthread NVMe: Clear QUEUE_FLAG_STACKABLE NVMe: Do not open disks that are being deleted NVMe: Do not over allocate for discard requests NVMe: Update module version major number NVMe: Fix command setup on IO retry Lars Ellenberg (2): drbd: fix resync throttling initialization drbd: merge_bvec_fn: properly remap bvm->bi_bdev Matias Bjorling (1): null_blk: boundary check queue_mode and irqmode Matias Bjørling (1): NVMe: Convert to blk-mq Matthew Wilcox (1): NVMe: Update list of status codes Philipp Reisner (3): drbd: fix race between role change and handshake drbd: Fix state change in case of connection timeout drbd: Remove an useless copy of kernel_setsockopt() Sam Bradshaw (2): NVMe: Correctly handle IOCTL_SUBMIT_IO when cpus > online queues NVMe: fix freeing of wrong request in abort path Vitaly Kuznetsov (2): xen/blkfront: improve protection against issuing unsupported REQ_FUA xen/blkfront: remove redundant flush_op kbuild test robot (1): NVMe: __nvme_submit_admin_cmd() can be static drivers/block/drbd/drbd_actlog.c |3 +- drivers/block/drbd/drbd_int.h | 39 +- drivers/block/drbd/drbd_main.c | 23 +- drivers/block/drbd/drbd_nl.c | 64 +- drivers/block/drbd/drbd_receiver.c |2 +- drivers/block/drbd/drbd_req.c | 25 +- drivers/block/drbd/drbd_state.c| 42 +- drivers/block/drbd/drbd_state.h|5 +
Re: [PATCHv6 2/3] kernel: add support for live patching
On Fri, Dec 12, 2014 at 05:58:19PM +0100, Miroslav Benes wrote:
>
> Hi,
>
> I think we are really close (or I hope so). I found few suspicious things
> or nitpicks though. They might have applied also to v5, but I didn't
> manage to look at that. Sorry about that.
>
> On Wed, 10 Dec 2014, Josh Poimboeuf wrote:
>
> > +/* klp_mutex must be held by caller */
> > +static bool klp_patch_is_registered(struct klp_patch *patch)
>
> Maybe klp_is_patch_registered is more appropriate name (consistent with
> other predicates in the file).
Ok.
> > +static int klp_disable_func(struct klp_func *func)
> > +{
> > + int ret;
> > +
> > + if (WARN_ON(func->state != KLP_ENABLED))
> > + return -EINVAL;
> > +
> > + if (WARN_ON(!func->old_addr))
> > + return -EINVAL;
> > +
> > + ret = unregister_ftrace_function(func->fops);
> > + if (ret) {
> > + pr_err("failed to unregister ftrace handler for function '%s'
> > (%d)\n",
> > + func->old_name, ret);
> > + return ret;
> > + }
> > +
> > + ret = ftrace_set_filter_ip(func->fops, func->old_addr, 1, 0);
> > + if (ret)
> > + pr_warn("function unregister succeeded but failed to clear the
> > filter\n");
> > +
> > + func->state = KLP_DISABLED;
> > +
> > + return 0;
> > +}
> > +
> > +static int klp_enable_func(struct klp_func *func)
> > +{
> > + int ret;
> > +
> > + if (WARN_ON(!func->old_addr))
> > + return -EINVAL;
> > +
> > + if (WARN_ON(func->state != KLP_DISABLED))
> > + return -EINVAL;
> > +
> > + ret = ftrace_set_filter_ip(func->fops, func->old_addr, 0, 0);
> > + if (ret) {
> > + pr_err("failed to set ftrace filter for function '%s' (%d)\n",
> > + func->old_name, ret);
> > + return ret;
> > + }
> > +
> > + ret = register_ftrace_function(func->fops);
> > + if (ret) {
> > + pr_err("failed to register ftrace handler for function '%s'
> > (%d)\n",
> > + func->old_name, ret);
> > + ftrace_set_filter_ip(func->fops, func->old_addr, 1, 0);
> > + } else {
> > + func->state = KLP_ENABLED;
> > + }
> > +
> > + return ret;
> > +}
>
> Just to be sure about our policy. We want to be stricter during enabling
> than in disabling process. Is that correct? Otherwise there is
> inconsistency in pr_* macros and return values. Also fops could be
> hypothetically registered back when ftrace_set_filter_ip fails in
> klp_disable_func. I just want to be sure that we didn't overlook
> anything...
The asymmetry in the enable/disable error handling is intentional. In
klp_disable_func(), a ftrace_set_filter_ip() failure isn't a fatal
condition because we've already unregistered the fops and thus removed
the patch.
> > +static int klp_init_func(struct klp_object *obj, struct klp_func *func)
> > +{
> > + struct ftrace_ops *ops;
> > + int ret;
> > +
> > + func->state = KLP_DISABLED;
> > +
> > + ops = kzalloc(sizeof(*ops), GFP_KERNEL);
> > + if (!ops)
> > + ret = -ENOMEM;
>
> There should be return -ENOMEM.
Agreed.
> > +static int klp_init_object(struct klp_patch *patch, struct klp_object *obj)
> > +{
> > + struct klp_func *func;
> > + int ret;
> > + const char *name;
> > +
> > + if (!obj->funcs)
> > + return -EINVAL;
> > +
> > + obj->state = KLP_DISABLED;
> > +
> > + klp_find_object_module(obj);
> > +
> > + name = klp_is_module(obj) ? obj->name : "vmlinux";
> > + obj->kobj = kobject_create_and_add(name, >kobj);
> > + if (!obj->kobj)
> > + return -ENOMEM;
> > +
> > + for (func = obj->funcs; func->old_name; func++) {
> > + ret = klp_init_func(obj, func);
> > + if (ret)
> > + goto free;
> > + }
> > +
> > + if (klp_is_object_loaded(obj)) {
> > + ret = klp_init_object_loaded(patch, obj);
> > + if (ret)
> > + goto free;
> > + }
> > +
> > + return 0;
> > +
> > +free:
> > + klp_free_funcs_limited(obj, func);
> > + return ret;
> > +}
>
> Shouldn't we call kobject_put(obj->kobj) in free branch? If I am not wrong
> it is not freed anywhere else. We free only already initialized functions
> and already initialized objects later in klp_init_patch, but not the
> kobject of the currently failing object.
Agreed.
> And that is everything. I like it, it has improved a lot. I hope that
> there are no other problems. I am getting blind looking at it all the
> time :)
Thanks! I'll send out the next patch set soon, maybe Monday.
--
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 0/5] ARM:sunxi:ps2 Added support for A10/A20 ps2 controller.
Hello Hans, Please find my comments inlined. On 12/13/14, Hans de Goede wrote: > Hi VishnuPatekar, > > The patch mangling for this set seems to have gone a bit wrong I'm afraid No, this time I've corrected it. Infact, last version of patch did not used the status bit error macros. > a lot of the patches have my fixup commit messages (which should have > disappeared when squashing in the patches), please replace those by proper > commit messages describing what the patch actually does. Yes, [PATCHv3 3/5] uses fixup. I'll correct it. > > Also the adding of the commented nodes for the lime2 seems to be gone > entirely > from the set, instead now only a comment about the conflict with the hdmi > pins is added, but it is above the i2c node instead of above a ps2 node. > Maxime's suggested that we should not add commented nodes specially when its trivial to apply. And just note saying ps20 pins conflict with HDMI. Should I remove the this comment as well? Or Put this note in start of DTS file? > Regards, > > Hans > > > On 12-12-14 19:25, VishnuPatekar wrote: >> v2 --> v3 >> 1. changed config to SERIO_SUN4I_PS2 from SERIO_SUNXI_PS2 >> 2. changed driver name to sun4i-ps2 from sunxi-ps2. >> 3. changed the function names to sun4i_ps2_*. >> 4. added locking in sun4i_ps2_open. >> 5. kept compatible "sun4i-a10-ps2" for A10 and A20, as A10 is earlier >> SOC. >> 6. corrected the style errors. >> 7. separated the dts patches. >> 8. removed commented ps2 notes from lime2 dts. >> 9. added note that ps2 pins confilt with hdmi. >> 10. corrected the interrupt property for A10. >> 11. moved dt-bindings to Documentation/devicetree/bindings/serio >> >> v1 --> v2: >> 1. added default n depends on ARCH_SUNXI || COMPILE_TEST in Kconfig. >> 2. handled errors and free resources on errors. >> 3. used BIT(x), DIV_ROUND_UP macros. >> 4. corrected style errors. >> 5. added support for A10 also, A10 and A2 have same properties of PS2 >> controller. >> 6. by default commented ps20 and ps21 nodes,as ps20 pins conflict with >> HDMI. >> 7. added compatible as allwinner,sun4i-a10-ps2. >> 8. corrected the possible race condition. >> >> >> VishnuPatekar (5): >>sunxi:dts-bindings:input:ps2 bindings for A10/A20 ps2. >>ARM:sunxi:drivers:input Add support for A10/A20 PS2 >>ARM: sunxi: dts: Add PS2 nodes to dtsi for A10 and A20 >>ARM: sunxi: dts: Add A10/A20 PS2 pin muxing options >>ARM: sunxi: dts: Add note ps2 pins conflict with hdmi >> >> .../bindings/serio/allwinner,sun4i-ps2.txt | 23 ++ >> arch/arm/boot/dts/sun4i-a10.dtsi | 31 ++ >> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts|6 +- >> arch/arm/boot/dts/sun7i-a20.dtsi | 32 ++ >> drivers/input/serio/Kconfig| 11 + >> drivers/input/serio/Makefile |1 + >> drivers/input/serio/sun4i-ps2.c| 362 >> >> 7 files changed, 465 insertions(+), 1 deletion(-) >> create mode 100644 >> Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt >> create mode 100644 drivers/input/serio/sun4i-ps2.c >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/2] Input: add regulator haptic driver
Hi Jaewon,
On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
> This patch adds support for haptic driver controlled by
> voltage of regulator. And this driver support for
> Force Feedback interface from input framework
>
> Signed-off-by: Jaewon Kim
> Signed-off-by: Hyunhee Kim
> Acked-by: Kyungmin Park
> Tested-by: Chanwoo Choi
> Reviewed-by: Chanwoo Choi
> Reviewed-by: Pankaj Dubey
> ---
> .../devicetree/bindings/input/regulator-haptic.txt | 21 ++
> drivers/input/misc/Kconfig | 11 +
> drivers/input/misc/Makefile|1 +
> drivers/input/misc/regulator-haptic.c | 259
>
> include/linux/input/regulator-haptic.h | 31 +++
> 5 files changed, 323 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/regulator-haptic.txt
> create mode 100644 drivers/input/misc/regulator-haptic.c
> create mode 100644 include/linux/input/regulator-haptic.h
>
> diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt
> b/Documentation/devicetree/bindings/input/regulator-haptic.txt
> new file mode 100644
> index 000..3ed1c7e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
> @@ -0,0 +1,21 @@
> +* Regulator Haptic Device Tree Bindings
> +
> +Required Properties:
> + - compatible : Should be "regulator-haptic"
> + - haptic-supply : Power supply to the haptic motor.
> + [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
> +
> + - max-microvolt : The maximum voltage value supplied to the haptic motor.
> + [The unit of the voltage is a micro]
> +
> + - min-microvolt : The minimum voltage value supplied to the haptic motor.
> + [The unit of the voltage is a micro]
> +
> +Example:
> +
> + haptics {
> + compatible = "regulator-haptic";
> + haptic-supply = <_regulator>;
> + max-microvolt = <270>;
> + min-microvolt = <110>;
> + };
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 23297ab..e5e556d 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -394,6 +394,17 @@ config INPUT_CM109
> To compile this driver as a module, choose M here: the module will be
> called cm109.
>
> +config INPUT_REGULATOR_HAPTIC
> + tristate "regulator haptics support"
> + select INPUT_FF_MEMLESS
> + help
> + This option enables device driver support for the haptic controlled
> + by regulator. This driver supports ff-memless interface
> + from input framework.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called regulator-haptic.
> +
> config INPUT_RETU_PWRBUTTON
> tristate "Retu Power button Driver"
> depends on MFD_RETU
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 19c7603..1f135af 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
> obj-$(CONFIG_INPUT_POWERMATE)+= powermate.o
> obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
> obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
> +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
> obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
> obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
> obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
> diff --git a/drivers/input/misc/regulator-haptic.c
> b/drivers/input/misc/regulator-haptic.c
> new file mode 100644
> index 000..2fa94bc
> --- /dev/null
> +++ b/drivers/input/misc/regulator-haptic.c
> @@ -0,0 +1,259 @@
> +/*
> + * Regulator haptic driver
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * Author: Jaewon Kim
> + * Author: Hyunhee Kim
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX_MAGNITUDE_SHIFT 16
> +
> +struct regulator_haptic {
> + struct device *dev;
> + struct input_dev *input_dev;
> + struct regulator *regulator;
> +
> + struct work_struct work;
> + struct mutex mutex;
> +
> + bool enabled;
> + bool suspend_state;
> + unsigned int max_volt;
> + unsigned int min_volt;
> + unsigned int intensity;
> + unsigned int magnitude;
> +};
> +
> +static void regulator_haptic_enable(struct regulator_haptic *haptic, bool
> state)
> +{
> + int error;
> +
> + if (haptic->enabled == state)
> + return;
> +
> + if (state)
> + error = regulator_enable(haptic->regulator);
> + else
> + error =
Re: [PATCH v2 1/4] pci: iProc: define Broadcom iProc PCIe binding
On Saturday 13 December 2014 11:05:52 Arend van Spriel wrote: > > Makes sense. I think that is what Hauke meant by "adding > additional support for registering to bcma". So the discovery info is a > piece of read-only memory in the chip. Its address is stored in the > chipcommon core register space. BCMA parses that memory blob resulting > in a list of cores which register address info. We could add DT support > in BCMA matching the compatible string and register a core for it. Ah, interesting idea. That would mirror what we do for drivers/amba, I like the idea. > However, apart from the discovery info a "discoverable ARM AXI" chip has > a register space per core that provides common procedures like > enable/disable, reset, core status, which are implemented in BCMA. I am > not seeing that register space in the DT examples so I guess this IP > block is not there for iProc chips. I wouldn't draw conclusions from the absence of some node. Maybe these registers are present but just not used by the original BSP. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: goldfish: Fix minor coding style
Loïc, On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote: > > Whose convention is this? I can't find any mention in > > Documention/CodingStyle. checkpatch.pl doesn't complain about them. > > And there are almost three thousand examples in staging which don't > > use this convention. > > > > linux-next$ grep -r "== NULL" drivers/staging/* | wc -l > > 2844 > > Hi Jeremiah, > > Thanks for your feedback. > > I have used checkpatch.pl with the --strict flag: > > $ ./scripts/checkpatch.pl --strict -f drivers/staging/goldfish/goldfish_nand.c > CHECK: Comparison to NULL could be written "!cps" > #51: FILE: drivers/staging/goldfish/goldfish_nand.c:51: > + if (cps == NULL) > > CHECK: Comparison to NULL could be written "!name" > #333: FILE: drivers/staging/goldfish/goldfish_nand.c:333: > + if (name == NULL) > > CHECK: Comparison to NULL could be written "!r" > #382: FILE: drivers/staging/goldfish/goldfish_nand.c:382: > + if (r == NULL) > > CHECK: Comparison to NULL could be written "!base" > #386: FILE: drivers/staging/goldfish/goldfish_nand.c:386: > + if (base == NULL) > > CHECK: Comparison to NULL could be written "!nand" > #402: FILE: drivers/staging/goldfish/goldfish_nand.c:402: > + if (nand == NULL) > > total: 0 errors, 0 warnings, 5 checks, 442 lines checked > > drivers/staging/goldfish/goldfish_nand.c has style problems, please review. > > I have also found another commit having the same purpose: > 7f376cd6dc1c9bfd14514c70765e6900a961c4b8 > > -- > Cheers, > Loïc It looks like you're right. I must say I am surprised. I had no idea checkpatch.pl could be even more pedantic than it already is :-) -- - Jeremiah Mahler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Input: gpio_keys - replace timer and workqueue with delayed workqueue
Hi Andy, On Wed, Dec 10, 2014 at 08:32:56PM +0200, Andy Shevchenko wrote: > On Sun, 2014-12-07 at 23:21 -0800, Dmitry Torokhov wrote: > > We do not need to roll our own implementation of delayed work now that we > > have proper implementation of mod_delayed_work. > > > > For interrupt-only driven buttons we retain the timer, but we rename > > it to release_timer to better reflect its purpose. > > At least it doesn't break the driver on Intel Medfield device. > > Tested-by: Andy Shevchenko Thank you for testing it. Assume it is for both patches, right? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: goldfish: Fix minor coding style
On Sat, 13 Dec 2014 17:29:26 +0100 Loic Pefferkorn wrote: > Hello, > > The convention for checking for NULL pointers is !ptr and not ptr == NULL. > This patch fixes such occurences in goldfish driver, it applies against > next-20141212 > > > Signed-off-by: Loic Pefferkorn Pointless churn. It makes it less readable if anything, and it removes the type safety as you are now checking against 0 not (void *)0 NAK Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] input: edt-ft5x06: fixed a macro coding style issue
On Tue, Dec 09, 2014 at 10:08:16AM +0200, Asaf Vertz wrote:
> Fixed a coding style error, macros with complex values should be
> enclosed in parentheses.
>
> Signed-off-by: Asaf Vertz
Applied, thank you.
> ---
> Changes in v2:
> - use do {...} while (0) instead of {...}
>
> drivers/input/touchscreen/edt-ft5x06.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c
> b/drivers/input/touchscreen/edt-ft5x06.c
> index ee3434f..d22ed56 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -850,9 +850,11 @@ static int edt_ft5x06_ts_identify(struct i2c_client
> *client,
> }
>
> #define EDT_ATTR_CHECKSET(name, reg) \
> +do { \
> if (pdata->name >= edt_ft5x06_attr_##name.limit_low && \
> pdata->name <= edt_ft5x06_attr_##name.limit_high) \
> - edt_ft5x06_register_write(tsdata, reg, pdata->name)
> + edt_ft5x06_register_write(tsdata, reg, pdata->name);\
> +} while (0)
>
> #define EDT_GET_PROP(name, reg) {\
> u32 val;\
> --
> 1.7.0.4
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: goldfish: Fix minor coding style
> Whose convention is this? I can't find any mention in > Documention/CodingStyle. checkpatch.pl doesn't complain about them. > And there are almost three thousand examples in staging which don't > use this convention. > > linux-next$ grep -r "== NULL" drivers/staging/* | wc -l > 2844 Hi Jeremiah, Thanks for your feedback. I have used checkpatch.pl with the --strict flag: $ ./scripts/checkpatch.pl --strict -f drivers/staging/goldfish/goldfish_nand.c CHECK: Comparison to NULL could be written "!cps" #51: FILE: drivers/staging/goldfish/goldfish_nand.c:51: + if (cps == NULL) CHECK: Comparison to NULL could be written "!name" #333: FILE: drivers/staging/goldfish/goldfish_nand.c:333: + if (name == NULL) CHECK: Comparison to NULL could be written "!r" #382: FILE: drivers/staging/goldfish/goldfish_nand.c:382: + if (r == NULL) CHECK: Comparison to NULL could be written "!base" #386: FILE: drivers/staging/goldfish/goldfish_nand.c:386: + if (base == NULL) CHECK: Comparison to NULL could be written "!nand" #402: FILE: drivers/staging/goldfish/goldfish_nand.c:402: + if (nand == NULL) total: 0 errors, 0 warnings, 5 checks, 442 lines checked drivers/staging/goldfish/goldfish_nand.c has style problems, please review. I have also found another commit having the same purpose: 7f376cd6dc1c9bfd14514c70765e6900a961c4b8 -- Cheers, Loïc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "perf top -g" leaking ~300MB per second.
On 12/13/14 8:26 AM, Arnaldo Carvalho de Melo wrote: The callchain code was done initially for 'report' and when I made 'top' reuse the hist_entry code allowing 'top' to collect callchains was too easy, but then we need to go thru the callchain/hists/hist_entry code to make sure that they don't leak, will try to do it... As I recall it is build up of the dead_threads list. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 10:53:35AM -0500, Sasha Levin wrote: > On 12/13/2014 03:30 AM, Ingo Molnar wrote: > >> > This is my no_hz related config: > >> > > >> > $ grep NO_HZ .config > >> > CONFIG_NO_HZ_COMMON=y > >> > # CONFIG_NO_HZ_IDLE is not set > >> > CONFIG_NO_HZ_FULL=y > >> > CONFIG_NO_HZ_FULL_ALL=y > > Just curious, if you disable NO_HZ_FULL_ALL, does the bug change? > > On 12/13/2014 07:08 AM, Paul E. McKenney wrote: > > Alternatively, your could boot with nohz_full=2-27 (or maybe even > > nohz_full=4-27). This will override CONFIG_NO_HZ_FULL_ALL=y and will > > provide two (or four with 4-27) housekeeping CPUs that are available to > > run things like RCU grace-period kthreads and RCU callback processing. > > This might allow RCU to get the CPU bandwidth it needs despite > > competition from your workload. > > I've tried both nohz_full=4-27 and disabling CONFIG_NO_HZ_FULL_ALL > altogether, but I'm still seeing the stall: And again looping in workqueues, despite the cond_resched_rcu_qs() there. And the reason for that is that cond_resched_rcu_qs() currently only provides quiescent states for tasks RCU. I will put together something that makes it work for other RCU flavors. Not that this is likely to do much about Dave Jones's lockup, but one thing at a time... Thanx, Paul > [ 725.670017] INFO: rcu_preempt detected stalls on CPUs/tasks: > [ 725.670017] 0: (11 ticks this GP) idle=bbd/142/0 > softirq=11529/11529 fqs=0 last_accelerate: 9d0e/a648, nonlazy_posted: 721357, > .. > [ 725.670017] (detected by 16, t=2102 jiffies, g=9857, c=9856, q=2581) > [ 725.670017] Task dump for CPU 0: > [ 725.670017] kworker/0:1 S 8800633abde8 13016 520 2 > 0x10080008 > [ 725.670017] b03027a8 880a70f24017 b043ef40 > 88005ffea310 > [ 725.670017] dfffe900 > 163bcdeb > [ 725.670017] 88006be15030 b1de6f58 ff10 > b0301237 > [ 725.670017] Call Trace: > [ 725.670017] [] ? retint_restore_args+0x13/0x13 > [ 725.670017] [] ? _raw_spin_unlock_irq+0x57/0x200 > [ 725.670017] [] ? _raw_spin_unlock_irq+0x23/0x200 > [ 725.670017] [] ? worker_thread+0x15b/0x1680 > [ 725.670017] [] ? __schedule+0xf6f/0x2fc0 > [ 725.670017] [] ? process_one_work+0x1650/0x1650 > [ 725.670017] [] ? kthread+0x1f2/0x2b0 > [ 725.670017] [] ? kthread_worker_fn+0x6a0/0x6a0 > [ 725.670017] [] ? ret_from_fork+0x7c/0xb0 > [ 725.670017] [] ? kthread_worker_fn+0x6a0/0x6a0 > > > Thanks, > Sasha > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Sat, Dec 13, 2014 at 11:59:15AM -0500, Dave Jones wrote: > On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote: > > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote: > > > > > > Something that's still making me wonder if it's some kind of hardware > > > problem is the non-deterministic nature of this bug. > > > > I'd expect it to be a race condition, though. Which can easily cause > > these kinds of issues, and the timing will be pretty random even if > > the load is very regular. > > > > And we know that the scheduler has an integer overflow under Sasha's > > loads, although I didn't hear anything from Ingo and friends about it. > > Ingo/Peter, you were cc'd on that report, where at least one of the > > multiplcations in wake_affine() ended up overflowing.. > > > > Some scheduler thing that overflows only under heavy load, and screws > > up scheduling could easily account for the RCU thread thing. I see it > > *less* easily accounting for DaveJ's case, though, because the > > watchdog is running at RT priority, and the scheduler would have to > > screw up much more to then not schedule an RT task, but.. > > > > I'm also not sure if the bug ever happens with preemption disabled. > > Bah, so I see some watchdog traces with preemption off, and that then > taints the kernel, and the fuzzing stops. I'll hack something up > so it ignores the taint and keeps going. All I really care about here > is the "machine hangs completely" case, which the trace below didn't > hit.. > > (back to fuzzing almost everything, not just lsetxattr btw) Hmmm... This one looks like the RCU grace-period kthread is getting starved: "idle=b4c/0/0". Is this running with the "dangerous" patch that sets these kthreads to RT priority? Thanx, Paul > [34917.468470] WARNING: CPU: 1 PID: 9226 at kernel/watchdog.c:317 > watchdog_overflow_callback+0x9c/0xd0() > [34917.468500] Watchdog detected hard LOCKUP on cpu 1 > [34917.468516] CPU: 1 PID: 9226 Comm: trinity-c107 Not tainted 3.18.0+ #102 > [34917.468542] [loadavg: 155.62 139.10 140.12 10/405 11756] > [34917.468559] 81a65d99 5606cf60 880244205b98 > 817c4f75 > [34917.468591] 810cd5a1 880244205bf0 880244205bd8 > 81077cb1 > [34917.468623] 880244205bd8 880243c55388 > 880244205d30 > [34917.468655] Call Trace: > [34917.468667][] dump_stack+0x4e/0x68 > [34917.468696] [] ? console_unlock+0x1f1/0x4e0 > [34917.468718] [] warn_slowpath_common+0x81/0xa0 > [34917.468740] [] warn_slowpath_fmt+0x55/0x70 > [34917.468761] [] ? __slab_alloc+0x3c4/0x58f > [34917.468783] [] ? restart_watchdog_hrtimer+0x60/0x60 > [34917.468806] [] watchdog_overflow_callback+0x9c/0xd0 > [34917.468830] [] __perf_event_overflow+0x9d/0x2a0 > [34917.468856] [] ? perf_event_update_userpage+0x103/0x180 > [34917.469785] [] ? perf_event_task_disable+0x90/0x90 > [34917.470705] [] perf_event_overflow+0x14/0x20 > [34917.471632] [] intel_pmu_handle_irq+0x1f9/0x3f0 > [34917.472553] [] perf_event_nmi_handler+0x2b/0x50 > [34917.473459] [] nmi_handle+0xc0/0x1b0 > [34917.474355] [] ? nmi_handle+0x5/0x1b0 > [34917.475245] [] default_do_nmi+0x4a/0x140 > [34917.476128] [] do_nmi+0xc0/0x100 > [34917.477012] [] end_repeat_nmi+0x1e/0x2e > [34917.477902] [] ? debug_check_no_obj_freed+0xe7/0x250 > [34917.478788] [] ? debug_check_no_obj_freed+0xe7/0x250 > [34917.479660] [] ? debug_check_no_obj_freed+0xe7/0x250 > [34917.480523] <> [] free_pages_prepare+0x1af/0x240 > [34917.481396] [] __free_pages_ok+0x21/0x100 > [34917.482270] [] free_compound_page+0x1b/0x20 > [34917.483144] [] __put_compound_page+0x23/0x30 > [34917.484022] [] put_compound_page+0x48/0x2e0 > [34917.484895] [] release_pages+0x239/0x270 > [34917.485768] [] free_pages_and_swap_cache+0x8d/0xa0 > [34917.486648] [] tlb_flush_mmu_free+0x34/0x60 > [34917.487530] [] unmap_single_vma+0x6d1/0x900 > [34917.488405] [] unmap_vmas+0x51/0xa0 > [34917.489277] [] exit_mmap+0xe5/0x1a0 > [34917.490143] [] mmput+0x6b/0x100 > [34917.490995] [] do_exit+0x29e/0xb60 > [34917.491823] [] do_group_exit+0x4c/0xc0 > [34917.492645] [] SyS_exit_group+0x14/0x20 > [34917.493462] [] tracesys_phase2+0xd4/0xd9 > [34917.494268] ---[ end trace c48441b18b6523a2 ]--- > [34917.495171] INFO: NMI handler (perf_event_nmi_handler) took too long to > run: 26.690 msecs > [34917.496031] perf interrupt took too long (211387 > 5000), lowering > kernel.perf_event_max_sample_rate to 25000 > [34967.056860] INFO: rcu_sched detected stalls on CPUs/tasks: > [34967.057898]1: (0 ticks this GP) idle=b4c/0/0 > softirq=2168971/2168971 > [34967.058900](detected by 2, t=6002 jiffies, g=1058044, c=1058043, > q=0) > [34967.059867] Task dump for CPU 1: > [34967.060827] swapper/1 R running task14576 0 1 > 0x0020 > [34967.061802] 000142b4be38 4a979bec19cdc3d2 e8003200
Re: [PATCH v5 1/2] soc: samsung: add exynos chipid driver support
On Fri, Dec 12, 2014 at 1:45 AM, Pankaj Dubey wrote:
> Hi Rob,
>
> On Thursday 11 December 2014 11:00 PM, Rob Herring wrote:
>>
>> On Thu, Dec 11, 2014 at 2:07 AM, Pankaj Dubey
>> wrote:
>>>
>>> Exynos SoCs have Chipid, for identification of product IDs
>>> and SoC revisions. This patch intendes to provide initialization
>>> code for all these functionalites.
[...]
>>> +static void __iomem *exynos_chipid_base;
>>> +
>>> +struct exynos_chipid_info exynos_soc_info;
>>> +EXPORT_SYMBOL(exynos_soc_info);
>>
>>
>> The soc_device already has similar data.Why is this needed? Is it
>> temporary for compatibility?
>
>
> struct soc_device_attribute can hold these two (product_id, and revision)
> but they are defined as char * in soc_device_atttribute, and I feel it's
> more specific for exposing via sysfs.
But what is exposed generically for sysfs should also be exposed
internally in the kernel generically.
> Also existing code in mach-exynos compares them via product_id/revision
> macros, so I can say to keep compatibility.
Perhaps you will have to change the users. Otherwise, I don't see the
point in moving this code as is. If there are a lot of users, then
having both old and new interface and moving them over one by one
would be okay. However, if this is widely used that is a problem in
itself.
>> For early use?
>
>
> Yes, partially correct. These parameters will be required in during early
> boot, from mach-exynos/platsmp.c, by that time probe of chipid would not
> have happened. But usage of this is not limited to early users, even
> mach-exynos/pm.c will use this later any point of time.
> Since there are early users I added "exynos_chipid_early_init" which will be
> called via mach-exynos.c at very early stage [1].
>
> [1]: https://lkml.org/lkml/2014/12/11/47
>
>
>> If for early use, then it
>> should not be exported.
>
>
> Other reason to make and expose this structure was we can see that other
> fields of chipid bank (other than product_id and revision, which is not part
> of this patch as of now) can be used by other driver such as ASV (which is
> not yet part of mainline but is there for every exynos SoC).
>
> I do not exported this in my PATCH v4 [2] of this, and instead provided
> exposed functions to directly access product_id and revision, but sometime
> in future when we will need other fields of chipid bank, we will end-up
> adding new exported function for each new field, so decided to expose this
> structure itself.
More on this below.
>>> +void __init exynos_chipid_early_init(struct device *dev)
>>> +{
>>> + struct device_node *np;
>>> + const struct of_device_id *match;
>>> +
>>> + if (exynos_chipid_base)
>>> + return;
>>> +
>>> + if (!dev)
>>> + np = of_find_matching_node_and_match(NULL,
>>> + of_exynos_chipid_ids, );
>>> + else
>>> + np = dev->of_node;
>>> +
>>> + if (!np)
>>> + panic("%s, failed to find chipid node\n", __func__);
>>
>>
>> Do you really want to halt booting here?
>
>
> Since some critical configuration are done in platsmp.c based on product_id
> and revision, I don't see any point moving ahead without it.
> Even if we allow to continue here it will crash or lead to system
> malfunction later during system boot for existing SoC support.
>
> Your console may not be up to
>>
>> see the panic anyway.
>
>
> I feel this we can still see via earlyprintk.
You can, yes. So when you don't boot getting no messages, you then
have to recompile to enable earlyprintk for exynos, load a new kernel,
and change your command line. That's not very good from a support
point of view. It would be better to boot while failing to boot
secondary cpus than not boot printing nothing. It is much better to
provide the warnings rather than have to debug why you are not
booting.
>>> +struct exynos_chipid_info {
>>> + u32 product_id;
>>> + u32 revision;
>>> +};
>>
>>
>> Exposing this struct kernel wide in an SOC specific way concerns me. I
>> would not like to see this done on every SOC family. That would become
>> a mess.
>>
>
> As of today chip-id can live up by exposing two APIs for getting product_id
> and revision, but in future when we need to access other fields we may end
> up adding new exported functions/extern functions. We had a discussion about
> it in Patch V4 [3].
Yes, but every SOC has an id and revision, so we should expose them in
a common way. For other fields, the mechanism to retrieve them should
probably be common, but the data could be custom.
Rob
>
> [3]: https://lkml.org/lkml/2014/12/10/748
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: goldfish: Fix minor coding style
Loic,
On Sat, Dec 13, 2014 at 05:29:26PM +0100, Loic Pefferkorn wrote:
> Hello,
>
> The convention for checking for NULL pointers is !ptr and not ptr == NULL.
> This patch fixes such occurences in goldfish driver, it applies against
> next-20141212
>
Whose convention is this? I can't find any mention in
Documention/CodingStyle. checkpatch.pl doesn't complain about them.
And there are almost three thousand examples in staging which don't
use this convention.
linux-next$ grep -r "== NULL" drivers/staging/* | wc -l
2844
>
> Signed-off-by: Loic Pefferkorn
> ---
> drivers/staging/goldfish/goldfish_audio.c | 8
> drivers/staging/goldfish/goldfish_nand.c | 10 +-
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/goldfish/goldfish_audio.c
> b/drivers/staging/goldfish/goldfish_audio.c
> index f200359..7ab034b 100644
> --- a/drivers/staging/goldfish/goldfish_audio.c
> +++ b/drivers/staging/goldfish/goldfish_audio.c
> @@ -273,19 +273,19 @@ static int goldfish_audio_probe(struct platform_device
> *pdev)
> dma_addr_t buf_addr;
>
> data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> - if (data == NULL)
> + if (!data)
> return -ENOMEM;
> spin_lock_init(>lock);
> init_waitqueue_head(>wait);
> platform_set_drvdata(pdev, data);
>
> r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (r == NULL) {
> + if (!r) {
> dev_err(>dev, "platform_get_resource failed\n");
> return -ENODEV;
> }
> data->reg_base = devm_ioremap(>dev, r->start, PAGE_SIZE);
> - if (data->reg_base == NULL)
> + if (!data->reg_base)
> return -ENOMEM;
>
[...]
--
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tpmdd-devel] [PATCH v10 0/8] TPM 2.0 support
On Fri, 12 Dec 2014, Jarkko Sakkinen wrote: > This patch set enables TPM2 protocol and provides drivers for FIFO and > CRB interfaces. This patch set does not export any sysfs attributes for > TPM 2.0 because existing sysfs attributes have three non-trivial issues: > > - They are associated with the platform device instead of character > device. > - They are are not trivial key-value pairs but contain text that is > not easily parsed by a computer. > - Raciness as described in > http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/ > > v2: > - Improved struct tpm_chip life-cycle by taking advantage of devres > API. > - Refined sysfs attributes as simple key-values thereby not repeating > mistakes in TPM1 sysfs attributes. > - Documented functions in tpm-chip.c and tpm2-cmd.c. > - Documented sysfs attributes. > > v3: > - Lots of fixes in calling order in device drivers (thanks to Jason > Gunthorpe for pointing these out!). > - Attach sysfs attributes to the misc device because it represents > TPM device to the user space. > > v4: > - Disable sysfs attibutes for TPM 2.0 for until we can sort out the > best approach for them. > - Fixed all the style issues found with checkpatch.pl. > > v5: > - missing EXPORT_SYMBOL_GPL() > - own class for TPM devices used for TPM 2.0 devices and onwards. > > v6: > - Non-racy initialization for sysfs attributes using struct device's > groups field. > - The class 'tpm' is used now for all TPM devices. For the first device > node major MISC_MAJOR and minor TPM_MINOR is used in order to retain > backwards compatability. > > v7: > - Release device number and free struct tpm_chip memory inside > tpm_dev_release callback. > - Moved code from tpm-interface.c and tpm_dev.c to tpm-chip.c. > > v8: > - Cleaned up unneeded cast from tpm_transmit_cmd(). > - Cleaned up redundant PPI_VERSION_LEN constant from tpm_ppi.c. > - Fixed tpm_tis to use tpm2_calc_ordinal_duration() for TPM2 devices. > - tpm_crb: in crb_recv, check that count can hold the TPM header at > minimum. > - tpm_crb: add enumerations for bit flags in start and cancel fields > of the control area. > - tpm_crb: use ioremap() for command and response buffer because > they might be anywhere. > - tpm_crb: use IO access functions for reading ioremapped buffers > because using direct pointers is not portable. > - tpm_crb: only apply ACPI start if start method reported by the > TPM2 ACPI table allows it. > - In tpm2_pcr_read() just calculate index and bit and get rid of > hacky loop. > - Do not add sysfs attributes for TPM 2.0 devices. > > v9: > - Fixed compilation issues in v8 (sorry for not using the correct > tree). > - Just do "return tpm_chip_register();" instead of copying return > value to a variable. > - Removed unused tpm2_startup(). > - In the CRB driver ACPI TPM2 table could contain platform specific > and therefore inequality test does not work. Fixed in this patch > set. > > v10: > - Fixed coccicheck and sparse errors and other reported style errors. > - Fixed build errors without CONFIG_ACPI. > - Fixed build error with CONFIG_OF. > - Added TPM_CHIP_FLAG_REGISTERED to mark successful tpm_chip_register(). > It is checked in the beginning of tpm_chip_unregister(), which is > called even when "attach" callback for a device fails because "detach" > callback is always called. > - Added TPM_CHIP_FLAG_PPI to mark successful PPI interface lookup because > in older TPM chips version string might be non-existent. > - Check TPM version from the 4th byte of STS register after requesting > the locality because otherwise the read will return bogus data. > - Some TPM chips just give 0xff as the 4th byte so using that for detecting > TPM family is unstable. Instead I chose the approach of using idempotent > TPM 2.x command to detect such case. > > Jarkko Sakkinen (8): > tpm: merge duplicate transmit_cmd() functions > tpm: two-phase chip management functions > tpm: fix raciness of PPI interface lookup > tpm: rename chip->dev to chip->pdev > tpm: device class for tpm > tpm: TPM 2.0 baseline support > tpm: TPM 2.0 CRB Interface > tpm: TPM 2.0 FIFO Interface > > Documentation/ABI/stable/sysfs-class-tpm | 22 +- > drivers/char/tpm/Kconfig | 9 + > drivers/char/tpm/Makefile| 3 +- > drivers/char/tpm/tpm-chip.c | 256 + > drivers/char/tpm/tpm-dev.c | 42 +-- > drivers/char/tpm/tpm-interface.c | 263 + > drivers/char/tpm/tpm-sysfs.c | 29 +- > drivers/char/tpm/tpm.h | 118 +- > drivers/char/tpm/tpm2-cmd.c | 617 > +++ > drivers/char/tpm/tpm_atmel.c | 25 +- > drivers/char/tpm/tpm_crb.c | 354 ++ > drivers/char/tpm/tpm_i2c_atmel.c | 55 +-- > drivers/char/tpm/tpm_i2c_infineon.c | 43 +-- >
Linux 2.6.32.65
I've just released Linux 2.6.32.65. This version addresses the following list of security issues : CVE-2013-2147 (was incorrectly fixed in 2.6.32.61), CVE-2014-3184, CVE-2014-3185, CVE-2014-3687, CVE-2014-3688, CVE-2014-4653, CVE-2014-4654, CVE-2014-4655, CVE-2014-4943, CVE-2014-6410, CVE-2014-7841, CVE-2014-8709, CVE-2014-8884, CVE-2014-9090 and fixes various other bugs (see details below). Special note: this version backports a new config entry CONFIG_X86_16BIT which defaults to Y (compatibility mode). It makes it possible to disable support for 16-bit applications (eg: dosemu/wine). Supporting such applications requires a workaround known as "ESPFIX" for a processor bug, which has been responsible for some of the last security issues affecting 2.6.32. Since the vast majority of users of 2.6.32 run it on servers where 16-bit support is totally pointless, it is strongly recommended to disable this option to stay safe and avoid upgrading again, should any other bug in this area be discovered in the future. The patch and changelog will appear soon at the following locations: https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.65.xz https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.65.gz https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ChangeLog-2.6.32.65 The updated 2.6.32.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-2.6.32.y http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-2.6.32.y The tree can be browsed on the gitweb interface: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?h=linux-2.6.32.y Testing status (build/boot, OK/FAIL, otherwise not tested) : ARCH | CONFIGURATION +--- | allmodconfig other-config x86_64 |build:OK boot:OK i386 |build:OK - Thanks to all participants. Willy - Documentation/x86/x86_64/mm.txt | 2 + Makefile | 2 +- arch/x86/Kconfig | 25 +++- arch/x86/include/asm/espfix.h| 16 +++ arch/x86/include/asm/irqflags.h | 2 +- arch/x86/include/asm/page_32_types.h | 1 - arch/x86/include/asm/page_64_types.h | 11 +- arch/x86/include/asm/pgtable_64_types.h | 2 + arch/x86/include/asm/setup.h | 2 + arch/x86/include/asm/uaccess.h | 1 - arch/x86/kernel/Makefile | 1 + arch/x86/kernel/dumpstack_64.c | 1 - arch/x86/kernel/entry_32.S | 17 ++- arch/x86/kernel/entry_64.S | 98 +-- arch/x86/kernel/espfix_64.c | 208 +++ arch/x86/kernel/ldt.c| 6 + arch/x86/kernel/paravirt_patch_64.c | 2 - arch/x86/kernel/smpboot.c| 7 ++ arch/x86/kernel/traps.c | 67 -- arch/x86/mm/dump_pagetables.c| 38 -- arch/x86/mm/extable.c| 31 - block/blk-core.c | 4 + block/blk-exec.c | 15 ++- drivers/block/cciss.c| 2 +- drivers/connector/cn_proc.c | 1 - drivers/md/raid5.c | 4 +- drivers/media/dvb/ttusb-dec/ttusbdecfe.c | 3 + drivers/net/pppol2tp.c | 4 +- drivers/usb/serial/whiteheat.c | 7 +- fs/udf/inode.c | 35 +++--- include/net/sctp/sctp.h | 5 + init/main.c | 4 + net/8021q/vlan_dev.c | 10 +- net/compat.c | 2 +- net/mac80211/tx.c| 2 +- net/sctp/associola.c | 2 + net/sctp/inqueue.c | 33 ++--- net/sctp/sm_make_chunk.c | 3 + net/sctp/sm_statefuns.c | 4 +- sound/core/control.c | 31 +++-- 40 files changed, 523 insertions(+), 188 deletions(-) Summary of changes from 2.6.32.64 to 2.6.32.65 == Andy Lutomirski (4): x86_64/entry/xen: Do not invoke espfix64 on Xen x86_64, traps: Stop using IST for #SS x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C x86_64, traps: Rework bad_iret Ben Hutchings (4): sctp: Fix double-free introduced by bad backport in 2.6.32.62 md/raid6: Fix misapplied backport in 2.6.32.64 cciss: Fix misapplied "cciss: fix info leak in cciss_ioctl32_passthru()" proc connector: Delete spurious memset in proc_exit_connector() Boris Ostrovsky (1): x86/espfix/xen: Fix allocation of pages for paravirt page tables Brian Gerst (1):
Re: Maintainer abuse
On Sat, Dec 13, 2014 at 01:52:31PM +, One Thousand Gnomes wrote: ... > It could then be integrated into git (if only so we can have a "git lost" > command to block annoying sources) All sounds nice and good but I'd be fine with people adhering to the one-week feedback gather rule and not sending patchsets during the merge window, for starters. I think those two will get us pretty far. > 2. Is X86 moving at a rate which needs some additional maintainers to > "maintain" the pending queue during merge windows and the like, and get > stuff into order for the maintainers proper ? Yep, no patches during the merge window should be a good start. The rest of the time x86 actually scales pretty fine IMO. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] TTY: add support for "tty slave" devices.
Hi, On Fri, Dec 12, 2014 at 11:59:20AM +, Grant Likely wrote: > [...] > > --- a/Documentation/devicetree/bindings/serial/of-serial.txt > > +++ b/Documentation/devicetree/bindings/serial/of-serial.txt > > @@ -39,6 +39,10 @@ Optional properties: > >driver is allowed to detect support for the capability even without this > >property. > > > > +Optional child node: > > +- a platform device listed as a child node will be probed and > > + powered-on whenever the tty is in use (open). > > + > > The biggest concern I have is what happens to nodes that already have > child devices that /don't/ match this use case? It is possible that some > UART nodes already have a child node used to store other data. There are > two ways to handle this; 1) add a new bool property that indicates the > child nodes are tty slave devices, or 2) Make each uart driver > explicitly enable the feature so that driver authors can check if it is > a problem for that device. I personally would suggest #1 because then it > can be enabled in generic code. maybe simple depend on the compatible value? If the UART node has child nodes to store other random data it should not have a compatible value? -- Sebastian signature.asc Description: Digital signature
Re: __hci_cmd_sync() not suitable for nokia h4p
Hi,
On Fri, Dec 12, 2014 at 01:14:53PM +0100, Pavel Machek wrote:
> > > I have created provisional device tree binding, and the driver still
> > > works.
> >
> > I don't have time to look at the code now, but I have some comments
> > regarding the binding.
>
> > >
> > > {
> > > +compatible = "brcm,uart,bcm2048";
> >
> > This does not look correct. The uart should not be overwritten. The
> > current h4p driver indeed implements a driver for the serial port,
> > but that's a) linux specific and does not belong in the DT and b)
> > should probably be changed in the mainline kernel.
>
> Yes, bettter solution is needed here. But see the code, I don't see
> how b) would be implemented.
I think it's probably a good idea to start from scratch. The h4p
driver in its current state does not fit to the current kernel's
style at all.
My suggestion would be to have a driver, which implements a hci_dev.
The driver would mostly look like the standard uart hci_dev driver,
but additionally handles the wakeup and reset gpios. Power
Management for the uart device is done via runtime pm, which is
supported by OMAP's uart driver.
Then there should be a second driver, which implements the h4
protocol extensions from Nokia as hci_uart_proto. It could be put
into something like drivers/bluetooth/hci_h4p.c and have support for
the additional packet types (namely H4_EVT_PKT, H4_NEG_PKT,
H4_ALIVE_PKT and H4_RADIO_PKT).
> > > interrupts-extended = < 73 _pmx_core OMAP3_UART2_RX>;
> > > pinctrl-names = "default";
> > > pinctrl-0 = <_pins>;
> > > + device {
> > > + compatible = "brcm,bcm2048";
> > > + uart = <>;
> >
> > You don't need a phandle to the parent device.
>
> Ok.
>
> > > + reset-gpios = < 27 GPIO_ACTIVE_HIGH>; /* want 91 */
> > > + host-wakeup-gpios = < 5 GPIO_ACTIVE_HIGH>; /* want 101
> > > */
> >
> > The host-wakeup should be mapped as irq, gpio2irq conversion
> > will happen ;)
>
> Why? It is accessed as gpio, too.
Ok. I only did a quick look and saw, that the gpio was converted to
irq.
> > > + chip-type = <3>;
> >
> > This should be set in the driver based on the compatible
> > value and not via DT data.
>
> Ok
>
> > > + clocks = <_fck>, <_ick>;
> > > + clock-names = "fck", "ick";
> >
> > These clocks you defined belong to the uart device and not to the
> > uart slave (bluetooth) device.
>
> Ok. Why are they only needed in the bluetooth case?
A quick guess (without a deeper look at the code) is, that the ttys
use hwmod provided clock information (which is available from the
kernel). btw, h4p not using hwmod would be another problem, if it is
ok to reimplement a full serial driver.
I guess the clock data should be added to the uart devices in DT,
though. This is btw. true for almost all omap internal devices
described in DT, since the clock data has only been available in DT
for 1 or 2 kernel releases.
> > > + bt-sysclk = <2>;
> >
> > I think this should be mapped cleanly in DT by adding a new clock
> > to the DTS file:
> >
> > vctcxo_clock: clock {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <3840>;
> > };
>
> No. It seems that this selects baud rate during the chip init. I guess
> I can just remove that one.
you can see, that its a descriptor for the speed of the bcm2048's
system clock.
(from h4p driver)
bt-sysclk = 1 => sysclk = 12000;
bt-sysclk = 2 => sysclk = 38400;
and incidentally there is a 38.4 MHz clock connected to the bcm2048
and the wl1251 in the N900 :)
> > Then the bluetooth device can reference its clock device:
> >
> > clocks = <_clock>;
> >
> > The same clock reference should be added to the wl1251 DT node :)
>
> Feel free to do that, but I don't see how this one helps...?
The clock is not enabled via the CPU, instead wl1251 and bcm2048
enable it themselfes, so it's not strictly needed. But it means,
that
a) DT represents the hardware correctly
b) one can acquire the sysclk speed from the referenced clock
[ using devm_clk_get() and clk_get_rate() ]
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH v2 00/16] nfsd/sunrpc: add support for a workqueue-based nfsd
On Sat, Dec 13, 2014 at 09:06:45AM -0500, Jeff Layton wrote: > On Fri, 12 Dec 2014 16:59:52 + > Al Viro wrote: > > > On Fri, Dec 12, 2014 at 06:54:08AM -0500, Jeff Layton wrote: > > > > > > Umm... I would be very surprised if it turned out to be a problem. > > > > nfsd really doesn't give a fuck about its cwd and root - not in the > > > > thread side of things. And (un)exporting is (a) not on a hot path > > > > and (b) not done from a kernel thread anyway. fh_to_dentry and friends > > > > doesn't care about root/cwd, etc. > > > > > > > > I don't see anything that could cause that kind of issues. > > > > > > I like the change overall -- it would certainly make my patch series > > > simpler, but what about pathwalking? We do take the fs->lock in > > > unlazy_walk. Is it possible we'd end up with more contention there? > > > > That would take a pathname lookup in kernel thread side of nfsd that > > * isn't single-component > > * isn't LOOKUP_ROOT one (i.e. vfs_path_lookup() or file_open_root()) > > and I would really hope we don't have such things. Any such a beast would > > allow probing the tree layout outside of what we export, to start with... > > > > AFAICS, we really don't have anything of that sort. Note that e.g. > > lookup_one_len() doesn't go anywhere near ->fs->lock... > > Ahh right. Ok, then I don't see any issue with this so far. Maybe worth > letting it stew in -next once -rc1 ships? Thanks! FWIW, right now I think that out of those 3 commits #1 (separating PID 1 from init_fs + making all kernel threads get umask 0) and #3 (assorted crapectomy in lustre, getting rid of odd games with fs_struct there) are OK for mainline, with #2 (removal of unshare_fs_struct()) being -next fodder, to see if we get anything like unexpected contention, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote: > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote: > > > > Something that's still making me wonder if it's some kind of hardware > > problem is the non-deterministic nature of this bug. > > I'd expect it to be a race condition, though. Which can easily cause > these kinds of issues, and the timing will be pretty random even if > the load is very regular. > > And we know that the scheduler has an integer overflow under Sasha's > loads, although I didn't hear anything from Ingo and friends about it. > Ingo/Peter, you were cc'd on that report, where at least one of the > multiplcations in wake_affine() ended up overflowing.. > > Some scheduler thing that overflows only under heavy load, and screws > up scheduling could easily account for the RCU thread thing. I see it > *less* easily accounting for DaveJ's case, though, because the > watchdog is running at RT priority, and the scheduler would have to > screw up much more to then not schedule an RT task, but.. > > I'm also not sure if the bug ever happens with preemption disabled. Bah, so I see some watchdog traces with preemption off, and that then taints the kernel, and the fuzzing stops. I'll hack something up so it ignores the taint and keeps going. All I really care about here is the "machine hangs completely" case, which the trace below didn't hit.. (back to fuzzing almost everything, not just lsetxattr btw) [34917.468470] WARNING: CPU: 1 PID: 9226 at kernel/watchdog.c:317 watchdog_overflow_callback+0x9c/0xd0() [34917.468500] Watchdog detected hard LOCKUP on cpu 1 [34917.468516] CPU: 1 PID: 9226 Comm: trinity-c107 Not tainted 3.18.0+ #102 [34917.468542] [loadavg: 155.62 139.10 140.12 10/405 11756] [34917.468559] 81a65d99 5606cf60 880244205b98 817c4f75 [34917.468591] 810cd5a1 880244205bf0 880244205bd8 81077cb1 [34917.468623] 880244205bd8 880243c55388 880244205d30 [34917.468655] Call Trace: [34917.468667][] dump_stack+0x4e/0x68 [34917.468696] [] ? console_unlock+0x1f1/0x4e0 [34917.468718] [] warn_slowpath_common+0x81/0xa0 [34917.468740] [] warn_slowpath_fmt+0x55/0x70 [34917.468761] [] ? __slab_alloc+0x3c4/0x58f [34917.468783] [] ? restart_watchdog_hrtimer+0x60/0x60 [34917.468806] [] watchdog_overflow_callback+0x9c/0xd0 [34917.468830] [] __perf_event_overflow+0x9d/0x2a0 [34917.468856] [] ? perf_event_update_userpage+0x103/0x180 [34917.469785] [] ? perf_event_task_disable+0x90/0x90 [34917.470705] [] perf_event_overflow+0x14/0x20 [34917.471632] [] intel_pmu_handle_irq+0x1f9/0x3f0 [34917.472553] [] perf_event_nmi_handler+0x2b/0x50 [34917.473459] [] nmi_handle+0xc0/0x1b0 [34917.474355] [] ? nmi_handle+0x5/0x1b0 [34917.475245] [] default_do_nmi+0x4a/0x140 [34917.476128] [] do_nmi+0xc0/0x100 [34917.477012] [] end_repeat_nmi+0x1e/0x2e [34917.477902] [] ? debug_check_no_obj_freed+0xe7/0x250 [34917.478788] [] ? debug_check_no_obj_freed+0xe7/0x250 [34917.479660] [] ? debug_check_no_obj_freed+0xe7/0x250 [34917.480523] <> [] free_pages_prepare+0x1af/0x240 [34917.481396] [] __free_pages_ok+0x21/0x100 [34917.482270] [] free_compound_page+0x1b/0x20 [34917.483144] [] __put_compound_page+0x23/0x30 [34917.484022] [] put_compound_page+0x48/0x2e0 [34917.484895] [] release_pages+0x239/0x270 [34917.485768] [] free_pages_and_swap_cache+0x8d/0xa0 [34917.486648] [] tlb_flush_mmu_free+0x34/0x60 [34917.487530] [] unmap_single_vma+0x6d1/0x900 [34917.488405] [] unmap_vmas+0x51/0xa0 [34917.489277] [] exit_mmap+0xe5/0x1a0 [34917.490143] [] mmput+0x6b/0x100 [34917.490995] [] do_exit+0x29e/0xb60 [34917.491823] [] do_group_exit+0x4c/0xc0 [34917.492645] [] SyS_exit_group+0x14/0x20 [34917.493462] [] tracesys_phase2+0xd4/0xd9 [34917.494268] ---[ end trace c48441b18b6523a2 ]--- [34917.495171] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 26.690 msecs [34917.496031] perf interrupt took too long (211387 > 5000), lowering kernel.perf_event_max_sample_rate to 25000 [34967.056860] INFO: rcu_sched detected stalls on CPUs/tasks: [34967.057898] 1: (0 ticks this GP) idle=b4c/0/0 softirq=2168971/2168971 [34967.058900] (detected by 2, t=6002 jiffies, g=1058044, c=1058043, q=0) [34967.059867] Task dump for CPU 1: [34967.060827] swapper/1 R running task14576 0 1 0x0020 [34967.061802] 000142b4be38 4a979bec19cdc3d2 e8003200 0003 [34967.062786] 81cb1b80 0001 880242b4be88 8165ff65 [34967.063759] 1fcecca713d2 81cb1ca0 81cb1b80 81d215b0 [34967.064721] Call Trace: [34967.065649] [] ? cpuidle_enter_state+0x55/0x190 [34967.066570] [] ? cpuidle_enter+0x17/0x20 [34967.067498] [] ? cpu_startup_entry+0x355/0x410 [34967.068425] [] ? start_secondary+0x1aa/0x230 [35027.731690] INFO: rcu_sched detected stalls on CPUs/tasks: [35027.732701] 1: (0 ticks this GP)
[PATCH RFC v3 1/2] PM / Domains: Extend API pm_genpd_dev_need_restore to use restore types
Instead of using bool to restore suspended devices initially, use flags
like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE.
The first two flags will be similar to the existing true/false functionality.
The third flag may be used to force restore of suspended devices
whenever their associated power domain is turned on.
Currently, PD power off function powers off all the associated unused
devices. The functionality added in this patch is similar to it.
This feature may be used for those devices which are always in ON state
if the PD associated with them is ON but may need local runtime resume
and suspend during PD On/Off. These devices (like clock) may not implement
complete pm_runtime calls such as pm_runtime_get/pm_runtime_put due to
subsystems interaction behaviour or any other reason.
The model works like,
DEV1 (Attaches itself with PD but no calls to pm_runtime_get and
/ pm_runtime_put. Its local runtime_suspend/resume is invoked via
/GPD_DEV_RESTORE_FORCE option)
/
PD -- DEV2 (Implements complete PM runtime and calls pm_runtime_get and
\ pm_runtime_put. This in turn invokes PD On/Off)
\
DEV3 (Similar to DEV1)
Signed-off-by: Amit Daniel Kachhap
---
This work is continuation of earlier work,
In V2: Completely removed notfiers and add support for huge clock list to be
suspended and restored. There was some issue in this as some clocks are
not exposed and are just initialised by bootloaders. This approach
required all of them to be exposed which is cumbersome. Also some
clock API's set_parent are disabling the original parent clocks
which is not required.
Link (https://lkml.org/lkml/2014/11/24/290)
In V1: Implemented PM Domain notfier such as PD_ON_PRE, PD_ON_POST
PD_OFF_PRE and PD_OFF_POST. This was not supported and other
options suggested. link
(http://www.spinics.net/lists/linux-samsung-soc/msg38442.html)
This work may also assist exynos iommu pm runtime posted earlier by Marek
http://lists.linaro.org/pipermail/linaro-mm-sig/2014-August/004099.html
drivers/base/power/domain.c | 40
include/linux/pm_domain.h | 15 +--
2 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 6a103a3..d955a05 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -49,6 +49,7 @@
static LIST_HEAD(gpd_list);
static DEFINE_MUTEX(gpd_list_lock);
+static void __pm_genpd_restore_devices(struct generic_pm_domain *genpd);
static struct generic_pm_domain *pm_genpd_lookup_name(const char *domain_name)
{
@@ -176,6 +177,8 @@ static int genpd_power_on(struct generic_pm_domain *genpd)
pr_warn("%s: Power-%s latency exceeded, new value %lld ns\n",
genpd->name, "on", elapsed_ns);
+ __pm_genpd_restore_devices(genpd);
+
return ret;
}
@@ -453,6 +456,24 @@ static void __pm_genpd_restore_device(struct
pm_domain_data *pdd,
}
/**
+ * __pm_genpd_restore_devices- Restore the pre-suspend state of all device
+ * according to the restore flag.
+ * @genpd: PM domain the device belongs to.
+ */
+static void __pm_genpd_restore_devices(struct generic_pm_domain *genpd)
+{
+ struct pm_domain_data *pdd;
+ struct generic_pm_domain_data *gpd_data;
+
+ /* Force restore the devices according to the restore flag */
+ list_for_each_entry(pdd, >dev_list, list_node) {
+ gpd_data = to_gpd_data(pdd);
+ if (gpd_data->force_restore == true)
+ __pm_genpd_restore_device(pdd, genpd);
+ }
+}
+
+/**
* genpd_abort_poweroff - Check if a PM domain power off should be aborted.
* @genpd: PM domain to check.
*
@@ -1469,6 +1490,7 @@ int __pm_genpd_add_device(struct generic_pm_domain
*genpd, struct device *dev,
gpd_data->base.dev = dev;
list_add_tail(_data->base.list_node, >dev_list);
gpd_data->need_restore = -1;
+ gpd_data->force_restore = false;
gpd_data->td.constraint_changed = true;
gpd_data->td.effective_constraint_ns = -1;
mutex_unlock(_data->lock);
@@ -1561,18 +1583,28 @@ int pm_genpd_remove_device(struct generic_pm_domain
*genpd,
/**
* pm_genpd_dev_need_restore - Set/unset the device's "need restore" flag.
* @dev: Device to set/unset the flag for.
- * @val: The new value of the device's "need restore" flag.
+ * @val: This can have values GPD_DEV_SUSPEND_INIT or GPD_DEV_RESTORE_INIT
+ * together with GPD_DEV_RESTORE_FORCE.
*/
-void pm_genpd_dev_need_restore(struct device *dev, bool val)
+void pm_genpd_dev_need_restore(struct device *dev, unsigned int val)
{
struct pm_subsys_data *psd;
+ struct generic_pm_domain_data *pdd;
unsigned long flags;
spin_lock_irqsave(>power.lock, flags);
psd = dev_to_psd(dev);
- if (psd
[PATCH RFC v3 2/2] clk: samsung: Add PM runtime support for clocks.
This patch adds PM runtime support for clocks associated with Power
Domain. The PM runtime suspend/resume handlers will be called when the
power domain associated with it, is turned on/off.
The registration of clocks happen in early initailisation. The probe
is later called to register the clock device with the power domain.
Signed-off-by: Amit Daniel Kachhap
---
drivers/clk/samsung/clk.c | 95 +++
drivers/clk/samsung/clk.h | 11 ++
2 files changed, 106 insertions(+)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index dd1f7c9..c517aa8 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -11,6 +11,10 @@
* clock framework for Samsung platforms.
*/
+#include
+#include
+#include
+#include
#include
#include "clk.h"
@@ -370,6 +374,93 @@ static void samsung_clk_sleep_init(void __iomem *reg_base,
unsigned long nr_rdump) {}
#endif
+static int samsung_cmu_runtime_suspend(struct device *dev)
+{
+ struct samsung_clock_pd_reg_cache *reg_cache;
+
+ reg_cache = dev_get_drvdata(dev);
+ samsung_clk_save(reg_cache->reg_base, reg_cache->rdump,
+ reg_cache->rd_num);
+ return 0;
+}
+
+static int samsung_cmu_runtime_resume(struct device *dev)
+{
+ struct samsung_clock_pd_reg_cache *reg_cache;
+
+ reg_cache = dev_get_drvdata(dev);
+ samsung_clk_restore(reg_cache->reg_base, reg_cache->rdump,
+ reg_cache->rd_num);
+ return 0;
+}
+
+#define MAX_CMU_DEVICE_MATCH 50
+static int samsung_cmu_count;
+static struct of_device_id samsung_cmu_match[MAX_CMU_DEVICE_MATCH];
+MODULE_DEVICE_TABLE(of, samsung_cmu_match);
+
+static void samsung_clk_pd_init(struct device_node *np, void __iomem *reg_base,
+ struct samsung_cmu_info *cmu)
+{
+ struct samsung_clock_pd_reg_cache *pd_reg_cache;
+ const char *name;
+
+ if (samsung_cmu_count == MAX_CMU_DEVICE_MATCH)
+ panic("Maximum clock device limit reached.\n");
+
+ if (of_property_read_string_index(np, "compatible", 0, ))
+ panic("Invalid DT node.\n");
+
+ pd_reg_cache = kzalloc(sizeof(struct samsung_clock_pd_reg_cache),
+ GFP_KERNEL);
+ if (!pd_reg_cache)
+ panic("Could not allocate register reg_cache.\n");
+
+ pd_reg_cache->rdump = samsung_clk_alloc_reg_dump(cmu->pd_clk_regs,
+ cmu->nr_pd_clk_regs);
+ if (!pd_reg_cache->rdump)
+ panic("Could not allocate register dump storage.\n");
+
+ pd_reg_cache->reg_base = reg_base;
+ pd_reg_cache->rd_num = cmu->nr_pd_clk_regs;
+
+ /* Fill up the compatible string and data */
+ samsung_cmu_match[samsung_cmu_count].data = pd_reg_cache;
+ strcpy(samsung_cmu_match[samsung_cmu_count].compatible, name);
+ samsung_cmu_count++;
+}
+
+static int __init samsung_cmu_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct of_device_id *match;
+
+ /* get the platform data */
+ match = (struct of_device_id *)of_match_node(samsung_cmu_match,
+ pdev->dev.of_node);
+ if (!match)
+ return 0;
+ platform_set_drvdata(pdev, (void *)match->data);
+ pm_runtime_enable(dev);
+ pm_genpd_dev_need_restore(dev,
+ GPD_DEV_RESTORE_FORCE | GPD_DEV_SUSPEND_INIT);
+ return 0;
+}
+
+static const struct dev_pm_ops samsung_cmu_pm_ops = {
+ SET_RUNTIME_PM_OPS(samsung_cmu_runtime_suspend,
+ samsung_cmu_runtime_resume, NULL)
+};
+
+static struct platform_driver samsung_cmu_driver = {
+ .driver = {
+ .name = "exynos-clk",
+ .of_match_table = samsung_cmu_match,
+ .pm = _cmu_pm_ops,
+ },
+ .probe = samsung_cmu_probe,
+};
+
/*
* Common function which registers plls, muxes, dividers and gates
* for each CMU. It also add CMU register list to register cache.
@@ -409,5 +500,9 @@ void __init samsung_cmu_register_one(struct device_node *np,
samsung_clk_sleep_init(reg_base, cmu->clk_regs,
cmu->nr_clk_regs);
+ if (cmu->pd_clk_regs)
+ samsung_clk_pd_init(np, reg_base, cmu);
+
samsung_clk_of_add_provider(np, ctx);
}
+module_platform_driver(samsung_cmu_driver);
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 3f471e9..c184ec1 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -331,6 +331,12 @@ struct samsung_clock_reg_cache {
unsigned int rd_num;
};
+struct samsung_clock_pd_reg_cache {
+ void __iomem *reg_base;
+ struct samsung_clk_reg_dump *rdump;
+ unsigned int rd_num;
+};
+
struct samsung_cmu_info {
/* list of pll clocks and respective count */
struct
[PATCH 4/4] workqueue: handle change in cpu-node relationship.
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes down, clear per-cpu pool's node attr.
2. When a cpu comes up, update per-cpu pool's node attr.
3. When a cpu comes up, update possinle node cpumask workqueue is using for
sched.
4. Detect the best node for unbound pool's cpumask using the latest info.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 67 ++
1 file changed, 53 insertions(+), 14 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 07b4eb5..259b3ba 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -266,7 +266,8 @@ struct workqueue_struct {
static struct kmem_cache *pwq_cache;
static cpumask_var_t *wq_numa_possible_cpumask;
- /* possible CPUs of each node */
+ /* possible CPUs of each node initialized with possible info at boot.
+ but modified at cpu hotplug to be adjusted to real info. */
static bool wq_disable_numa;
module_param_named(disable_numa, wq_disable_numa, bool, 0444);
@@ -3449,6 +3450,31 @@ static void put_unbound_pool(struct worker_pool *pool)
call_rcu_sched(>rcu, rcu_free_pool);
}
+/*
+ * detect best node for given cpumask.
+ */
+static int pool_detect_best_node(const struct cpumask *cpumask)
+{
+ int node, best, match, selected;
+ static struct cpumask andmask; /* we're under mutex */
+
+ /* Is any node okay ? */
+ if (!wq_numa_enabled ||
+ cpumask_subset(cpu_online_mask, cpumask))
+ return NUMA_NO_NODE;
+ best = 0;
+ selected = NUMA_NO_NODE;
+ /* select a node which contains the most cpu of cpumask */
+ for_each_node_state(node, N_ONLINE) {
+ cpumask_and(, cpumask, cpumask_of_node(node));
+ match = cpumask_weight();
+ if (match > best)
+ selected = node;
+ }
+ return selected;
+}
+
+
/**
* get_unbound_pool - get a worker_pool with the specified attributes
* @attrs: the attributes of the worker_pool to get
@@ -3467,7 +3493,6 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
{
u32 hash = wqattrs_hash(attrs);
struct worker_pool *pool;
- int node;
lockdep_assert_held(_pool_mutex);
@@ -3492,17 +3517,7 @@ static struct worker_pool *get_unbound_pool(const struct
workqueue_attrs *attrs)
* 'struct workqueue_attrs' comments for detail.
*/
pool->attrs->no_numa = false;
-
- /* if cpumask is contained inside a NUMA node, we belong to that node */
- if (wq_numa_enabled) {
- for_each_node(node) {
- if (cpumask_subset(pool->attrs->cpumask,
- wq_numa_possible_cpumask[node])) {
- pool->node = node;
- break;
- }
- }
- }
+ pool->node = pool_detect_best_node(pool->attrs->cpumask);
if (worker_pool_assign_id(pool) < 0)
goto fail;
@@ -4567,7 +4582,7 @@ static int workqueue_cpu_up_callback(struct
notifier_block *nfb,
int cpu = (unsigned long)hcpu;
struct worker_pool *pool;
struct workqueue_struct *wq;
- int pi;
+ int pi, node;
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_UP_PREPARE:
@@ -4583,6 +4598,16 @@ static int workqueue_cpu_up_callback(struct
notifier_block *nfb,
case CPU_ONLINE:
mutex_lock(_pool_mutex);
+ /* now cpu <-> node info is established, update the info. */
+ if (!wq_disable_numa) {
+ for_each_node_state(node, N_POSSIBLE)
+ cpumask_clear_cpu(cpu,
+ wq_numa_possible_cpumask[node]);
+ node = cpu_to_node(cpu);
+ cpumask_set_cpu(cpu, wq_numa_possible_cpumask[node]);
+ }
+ for_each_cpu_worker_pool(pool, cpu)
+ pool->node = cpu_to_node(cpu);
for_each_pool(pool, pi) {
mutex_lock(>attach_mutex);
@@ -4951,7 +4976,21 @@ void workqueue_register_numanode(int nid)
void workqueue_unregister_numanode(int nid)
{
struct workqueue_struct *wq;
+ const struct cpumask *nodecpumask;
+ struct worker_pool *pool;
+ int cpu;
+ /* at this point, cpu-to-node relationship is not lost */
+ nodecpumask = cpumask_of_node(nid);
+ for_each_cpu(cpu, nodecpumask) {
+ /*
+* pool is allcated at boot and assumed to be persistent,
+* we cannot free this.
+* Update to be NUMA_NO_NODE. This will be fixed at ONLINE
+
[PATCH 3/4] workqueue: remove per-node unbound pool when node goes offline.
remove node aware unbound pools if node goes offline.
scan unbound workqueue and remove numa affine pool when
a node goes offline.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 35f4f00..07b4eb5 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4921,11 +4921,40 @@ early_initcall(init_workqueues);
* cached pools per cpu should be freed at node unplug
*/
+/*
+ * Replace per-node pwq with dfl_pwq because this node disappers.
+ * The new pool will be set at CPU_ONLINE by wq_update_unbound_numa.
+ */
+static void wq_release_unbound_numa(struct workqueue_struct *wq, int nid)
+{
+ struct pool_workqueue *old_pwq = NULL;
+
+ if (!wq_numa_enabled || !(wq->flags & WQ_UNBOUND))
+ return;
+ mutex_lock(>mutex);
+ if (wq->unbound_attrs->no_numa)
+ goto out_unlock;
+ spin_lock_irq(>dfl_pwq->pool->lock);
+ get_pwq(wq->dfl_pwq);
+ spin_unlock_irq(>dfl_pwq->pool->lock);
+ old_pwq = numa_pwq_tbl_install(wq, nid, wq->dfl_pwq);
+out_unlock:
+ mutex_unlock(>mutex);
+ put_pwq_unlocked(old_pwq);
+ return;
+}
+
void workqueue_register_numanode(int nid)
{
}
void workqueue_unregister_numanode(int nid)
{
+ struct workqueue_struct *wq;
+
+ mutex_lock(_pool_mutex);
+ list_for_each_entry(wq, , list)
+ wq_release_unbound_numa(wq, nid);
+ mutex_unlock(_pool_mutex);
}
#endif
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] workqueue: fix bug when numa mapping is changed v2.
Yasuaki Ishimatsu hit a allocation failure bug when the numa mapping between CPU and node is changed. This was the last scene: SLUB: Unable to allocate memory on node 2 (gfp=0x80d0) cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min order: 0 node 0: slabs: 6172, objs: 259224, free: 245741 node 1: slabs: 3261, objs: 136962, free: 127656 I and Yasuaki have a host which has a feature of node hotplug, this is a fix by me. Tested several patterns of hotplug and I found no issue, now. Of course I read Lai's patch and Tejun's comment. I hope I could reflect them. 1/4 ... add node-hotplug event callback. 2/4 ... add a sanity check (for debug) 3/4 ... remove per-node unbound workqueue if node goes offline. 4/4 ... update per-cpu pool's information and cpumasks, node information based on the latest (cpu, node) information. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] workqueue: add warning if pool->node is offline
Add warning if pool->node is offline.
This patch was originaly made for debug.
I think add warning here can show what may happen.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f6cb357c..35f4f00 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -760,6 +760,15 @@ static bool too_many_workers(struct worker_pool *pool)
return nr_idle > 2 && (nr_idle - 2) * MAX_IDLE_WORKERS_RATIO >= nr_busy;
}
+/* Check pool->node */
+static int pool_to_node(struct worker_pool *pool)
+{
+ if (WARN_ON_ONCE(pool->node != NUMA_NO_NODE
+ && !node_online(pool->node)))
+ return NUMA_NO_NODE;
+ return pool->node;
+}
+
/*
* Wake up functions.
*/
@@ -1679,7 +1688,7 @@ static struct worker *create_worker(struct worker_pool
*pool)
if (id < 0)
goto fail;
- worker = alloc_worker(pool->node);
+ worker = alloc_worker(pool_to_node(pool));
if (!worker)
goto fail;
@@ -1692,7 +1701,8 @@ static struct worker *create_worker(struct worker_pool
*pool)
else
snprintf(id_buf, sizeof(id_buf), "u%d:%d", pool->id, id);
- worker->task = kthread_create_on_node(worker_thread, worker, pool->node,
+ worker->task = kthread_create_on_node(worker_thread, worker,
+ pool_to_node(pool),
"kworker/%s", id_buf);
if (IS_ERR(worker->task))
goto fail;
@@ -3651,7 +3661,7 @@ static struct pool_workqueue *alloc_unbound_pwq(struct
workqueue_struct *wq,
if (!pool)
return NULL;
- pwq = kmem_cache_alloc_node(pwq_cache, GFP_KERNEL, pool->node);
+ pwq = kmem_cache_alloc_node(pwq_cache, GFP_KERNEL, pool_to_node(pool));
if (!pwq) {
put_unbound_pool(pool);
return NULL;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] workqueue: add a hook for node hotplug
Subject: [PATCH 1/4] add callbackof node hotplug for workqueue.
Because workqueue is numa aware, it pool has node information.
And it should be maintained against node-hotplug.
When a node which exists at boot is unpluged, following error
is detected.
==
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
==
This is because pool->node points a stale node.
This patch adds callback function at node hotplug.
Signed-off-by: KAMEZAWA Hiroyuki node should be cleared and
+ * cached pools per cpu should be freed at node unplug
+ */
+
+void workqueue_register_numanode(int nid)
+{
+}
+
+void workqueue_unregister_numanode(int nid)
+{
+}
+#endif
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 1bf4807..504b071 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1162,7 +1162,8 @@ int try_online_node(int nid)
build_all_zonelists(NULL, NULL);
mutex_unlock(_mutex);
}
-
+ /* Now zonelist for the pgdat is ready */
+ workqueue_register_numanode(nid);
out:
mem_hotplug_done();
return ret;
@@ -1914,7 +1915,11 @@ static int check_and_unmap_cpu_on_node(pg_data_t *pgdat)
ret = check_cpu_on_node(pgdat);
if (ret)
return ret;
-
+ /*
+* There is no online cpu on the node and this node will go.
+* make workqueue to forget this node.
+*/
+ workqueue_unregister_numanode(pgdat->node_id);
/*
* the node will be offlined when we come here, so we can clear
* the cpu_to_node() now.
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
I started seeing this behavior somewhere around 3.16 with CONFIG_PREEMPT set. Setting CONFIG_PREEMPT off seems to help. And, yes, it happens on high load (compiling mozilla, xul) and using qemu chroot to compile mesa. I'm seeing a few persons bisecting already. If you want, I could start bisecting too, but 3.16 was unstable for me as I'm still on reiserfs. Jeff. On Sat, Dec 13, 2014 at 8:44 AM, Linus Torvalds wrote: > On Fri, Dec 12, 2014 at 4:34 PM, Sasha Levin wrote: >> >> Right, it's virtio-9p. However, virtio-9p acts merely as a proxy to an >> underlying >> tmpfs - so while it's slow, I don't think it's way slower than the average >> disk >> backed ext4. > > I was thinking more in the sense of "how much of the trouble is about > something like tmpfs eating tons of memory when trinity starts doing > random system calls on those files". > > I was also thinking that some of it might be filesystem-specific. We > already *did* see one trace where it was in the loop getting virtio > channel data. Maybe it's actually possible to overwhelm the 9p > filesystem exactly because the backing store is tmpfs, and basically > have a CPU 100% busy handling ring events from the virtual > filesystem.. > > But I'm just flailing.. > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: goldfish: Fix minor coding style
Hello,
The convention for checking for NULL pointers is !ptr and not ptr == NULL.
This patch fixes such occurences in goldfish driver, it applies against
next-20141212
Signed-off-by: Loic Pefferkorn
---
drivers/staging/goldfish/goldfish_audio.c | 8
drivers/staging/goldfish/goldfish_nand.c | 10 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/goldfish/goldfish_audio.c
b/drivers/staging/goldfish/goldfish_audio.c
index f200359..7ab034b 100644
--- a/drivers/staging/goldfish/goldfish_audio.c
+++ b/drivers/staging/goldfish/goldfish_audio.c
@@ -273,19 +273,19 @@ static int goldfish_audio_probe(struct platform_device
*pdev)
dma_addr_t buf_addr;
data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
- if (data == NULL)
+ if (!data)
return -ENOMEM;
spin_lock_init(>lock);
init_waitqueue_head(>wait);
platform_set_drvdata(pdev, data);
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (r == NULL) {
+ if (!r) {
dev_err(>dev, "platform_get_resource failed\n");
return -ENODEV;
}
data->reg_base = devm_ioremap(>dev, r->start, PAGE_SIZE);
- if (data->reg_base == NULL)
+ if (!data->reg_base)
return -ENOMEM;
data->irq = platform_get_irq(pdev, 0);
@@ -295,7 +295,7 @@ static int goldfish_audio_probe(struct platform_device
*pdev)
}
data->buffer_virt = dmam_alloc_coherent(>dev,
COMBINED_BUFFER_SIZE, _addr, GFP_KERNEL);
- if (data->buffer_virt == NULL) {
+ if (!data->buffer_virt) {
dev_err(>dev, "allocate buffer failed\n");
return -ENOMEM;
}
diff --git a/drivers/staging/goldfish/goldfish_nand.c
b/drivers/staging/goldfish/goldfish_nand.c
index d68f216..8e8e594 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -48,7 +48,7 @@ static u32 goldfish_nand_cmd_with_params(struct mtd_info *mtd,
struct cmd_params *cps = nand->cmd_params;
unsigned char __iomem *base = nand->base;
- if (cps == NULL)
+ if (!cps)
return -1;
switch (cmd) {
@@ -330,7 +330,7 @@ static int goldfish_nand_init_device(struct platform_device
*pdev,
mtd->priv = nand;
name = devm_kzalloc(>dev, name_len + 1, GFP_KERNEL);
- if (name == NULL)
+ if (!name)
return -ENOMEM;
mtd->name = name;
@@ -379,11 +379,11 @@ static int goldfish_nand_probe(struct platform_device
*pdev)
unsigned char __iomem *base;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (r == NULL)
+ if (!r)
return -ENODEV;
base = devm_ioremap(>dev, r->start, PAGE_SIZE);
- if (base == NULL)
+ if (!base)
return -ENOMEM;
version = readl(base + NAND_VERSION);
@@ -399,7 +399,7 @@ static int goldfish_nand_probe(struct platform_device *pdev)
nand = devm_kzalloc(>dev, sizeof(*nand) +
sizeof(struct mtd_info) * num_dev, GFP_KERNEL);
- if (nand == NULL)
+ if (!nand)
return -ENOMEM;
mutex_init(>lock);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 4/5] hwmon: ina2xx: make shunt resistance configurable at run-time
The shunt resistance can only be set via platform_data or device tree. This
isn't suitable for devices in which the shunt resistance can change/isn't
known at boot-time.
Add a sysfs attribute that allows to read and set the shunt resistance.
Signed-off-by: Bartosz Golaszewski
---
Documentation/hwmon/ina2xx | 5 +++--
drivers/hwmon/ina2xx.c | 48 --
2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index 4223c2d..320dd69 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -44,6 +44,7 @@ The INA226 monitors both a shunt voltage drop and bus supply
voltage.
The INA230 is a high or low side current shunt and power monitor with an I2C
interface. The INA230 monitors both a shunt voltage drop and bus supply
voltage.
-The shunt value in micro-ohms can be set via platform data or device tree.
-Please refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for
bindings
+The shunt value in micro-ohms can be set via platform data or device tree at
+compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
+refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
if the device tree is used.
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 3234e57..49537ea 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -115,6 +115,12 @@ static const struct ina2xx_config ina2xx_config[] = {
},
};
+static int ina2xx_calibrate(struct ina2xx_data *data)
+{
+ return i2c_smbus_write_word_swapped(data->client, INA2XX_CALIBRATION,
+ data->config->calibration_factor / data->rshunt);
+}
+
/*
* Initialize the configuration and calibration registers.
*/
@@ -133,8 +139,7 @@ static int ina2xx_init(struct ina2xx_data *data)
* Set current LSB to 1mA, shunt is in uOhms
* (equation 13 in datasheet).
*/
- return i2c_smbus_write_word_swapped(client, INA2XX_CALIBRATION,
- data->config->calibration_factor / data->rshunt);
+ return ina2xx_calibrate(data);
}
static int ina2xx_do_update(struct device *dev)
@@ -231,6 +236,9 @@ static int ina2xx_get_value(struct ina2xx_data *data, u8
reg)
/* signed register, LSB=1mA (selected), in mA */
val = (s16)data->regs[reg];
break;
+ case INA2XX_CALIBRATION:
+ val = data->config->calibration_factor / data->regs[reg];
+ break;
default:
/* programmer goofed */
WARN_ON_ONCE(1);
@@ -254,6 +262,36 @@ static ssize_t ina2xx_show_value(struct device *dev,
ina2xx_get_value(data, attr->index));
}
+static ssize_t ina2xx_set_shunt(struct device *dev,
+ struct device_attribute *da,
+ const char *buf, size_t count)
+{
+ struct ina2xx_data *data = ina2xx_update_device(dev);
+ unsigned long val;
+ int status;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ status = kstrtoul(buf, 10, );
+ if (status < 0)
+ return status;
+
+ if (val == 0 ||
+ /* Values greater than the calibration factor make no sense. */
+ val > data->config->calibration_factor)
+ return -EINVAL;
+
+ mutex_lock(>update_lock);
+ data->rshunt = val;
+ status = ina2xx_calibrate(data);
+ mutex_unlock(>update_lock);
+ if (status < 0)
+ return status;
+
+ return count;
+}
+
/* shunt voltage */
static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, ina2xx_show_value, NULL,
INA2XX_SHUNT_VOLTAGE);
@@ -270,12 +308,18 @@ static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO,
ina2xx_show_value, NULL,
static SENSOR_DEVICE_ATTR(power1_input, S_IRUGO, ina2xx_show_value, NULL,
INA2XX_POWER);
+/* shunt resistance */
+static SENSOR_DEVICE_ATTR(shunt_resistor, S_IRUGO | S_IWUSR,
+ ina2xx_show_value, ina2xx_set_shunt,
+ INA2XX_CALIBRATION);
+
/* pointers to created device attributes */
static struct attribute *ina2xx_attrs[] = {
_dev_attr_in0_input.dev_attr.attr,
_dev_attr_in1_input.dev_attr.attr,
_dev_attr_curr1_input.dev_attr.attr,
_dev_attr_power1_input.dev_attr.attr,
+ _dev_attr_shunt_resistor.dev_attr.attr,
NULL,
};
ATTRIBUTE_GROUPS(ina2xx);
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 3/5] hwmon: ina2xx: don't accept shunt values greater than the calibration factor
Shunt resistance values greater than the chip's calibration factor make no sense since the actual value written to the register equals: / Bail-out from ina2xx_probe() if the configured value is greater than the calibration factor. Signed-off-by: Bartosz Golaszewski --- drivers/hwmon/ina2xx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c index 39e017b..3234e57 100644 --- a/drivers/hwmon/ina2xx.c +++ b/drivers/hwmon/ina2xx.c @@ -313,7 +313,8 @@ static int ina2xx_probe(struct i2c_client *client, data->config = _config[data->kind]; data->client = client; - if (data->rshunt <= 0) + if (data->rshunt <= 0 || + data->rshunt > data->config->calibration_factor) return -ENODEV; ret = ina2xx_init(data); -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/5] hwmon: ina2xx: implement chip reinitialization and add new attributes
This series implements a mechanism to detect if the chip is in its POR state and reinitialize it if needed. It also extends the sysfs interface to make the driver configurable at run-time. The shunt_resistor attribute allows to change the shunt resistance value at run-time in cases where ina2xx used to do the measurement isn't integrated with the shunt. The avg_rate attribute allows to increase/decrease noise reduction. v7: - implemented a retry counter for the reinitialization procedure - using msleep() (since the sleep is > 20ms) instead of mdelay() when waiting for the chip update v6: https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg787390.html Bartosz Golaszewski (5): hwmon: ina2xx: reinitialize the chip in case it's been reset hwmon: ina2xx: remove a stray new line hwmon: ina2xx: don't accept shunt values greater than the calibration factor hwmon: ina2xx: make shunt resistance configurable at run-time hwmon: ina2xx: allow to change the averaging rate at run-time Documentation/hwmon/ina2xx | 8 +- drivers/hwmon/ina2xx.c | 304 +++-- 2 files changed, 269 insertions(+), 43 deletions(-) -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/5] hwmon: ina2xx: reinitialize the chip in case it's been reset
Chips from the ina family don't like to be uninitialized. In case the power
is cut-off and restored again the calibration register will be reset
to 0 and both the power and current registers will remain at 0.
Check the calibration register in ina2xx_update_device() and reinitialize
the chip if needed.
Signed-off-by: Bartosz Golaszewski
---
drivers/hwmon/ina2xx.c | 128 +++--
1 file changed, 91 insertions(+), 37 deletions(-)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index e01feba..ffbd60f 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
@@ -64,6 +65,9 @@
/* worst case is 68.10 ms (~14.6Hz, ina219) */
#define INA2XX_CONVERSION_RATE 15
+#define INA2XX_MAX_DELAY 69 /* worst case delay in ms */
+
+#define INA2XX_RSHUNT_DEFAULT 1
enum ina2xx_ids { ina219, ina226 };
@@ -81,6 +85,8 @@ struct ina2xx_data {
struct i2c_client *client;
const struct ina2xx_config *config;
+ long rshunt;
+
struct mutex update_lock;
bool valid;
unsigned long last_updated;
@@ -110,34 +116,96 @@ static const struct ina2xx_config ina2xx_config[] = {
},
};
-static struct ina2xx_data *ina2xx_update_device(struct device *dev)
+/*
+ * Initialize the configuration and calibration registers.
+ */
+static int ina2xx_init(struct ina2xx_data *data)
{
- struct ina2xx_data *data = dev_get_drvdata(dev);
struct i2c_client *client = data->client;
- struct ina2xx_data *ret = data;
+ int ret;
- mutex_lock(>update_lock);
+ /* device configuration */
+ ret = i2c_smbus_write_word_swapped(client, INA2XX_CONFIG,
+ data->config->config_default);
+ if (ret < 0)
+ return ret;
- if (time_after(jiffies, data->last_updated +
- HZ / INA2XX_CONVERSION_RATE) || !data->valid) {
+ /*
+* Set current LSB to 1mA, shunt is in uOhms
+* (equation 13 in datasheet).
+*/
+ return i2c_smbus_write_word_swapped(client, INA2XX_CALIBRATION,
+ data->config->calibration_factor / data->rshunt);
+}
- int i;
+static int ina2xx_do_update(struct device *dev)
+{
+ struct ina2xx_data *data = dev_get_drvdata(dev);
+ struct i2c_client *client = data->client;
+ int i, rv, retry;
- dev_dbg(>dev, "Starting ina2xx update\n");
+ dev_dbg(>dev, "Starting ina2xx update\n");
+ for (retry = 5; retry; retry--) {
/* Read all registers */
for (i = 0; i < data->config->registers; i++) {
- int rv = i2c_smbus_read_word_swapped(client, i);
- if (rv < 0) {
- ret = ERR_PTR(rv);
- goto abort;
- }
+ rv = i2c_smbus_read_word_swapped(client, i);
+ if (rv < 0)
+ return rv;
data->regs[i] = rv;
}
+
+ /*
+* If the current value in the calibration register is 0, the
+* power and current registers will also remain at 0. In case
+* the chip has been reset let's check the calibration
+* register and reinitialize if needed.
+*/
+ if (data->regs[INA2XX_CALIBRATION] == 0) {
+ dev_warn(dev, "chip not calibrated, reinitializing\n");
+
+ rv = ina2xx_init(data);
+ if (rv < 0)
+ return rv;
+
+ /*
+* Let's make sure the power and current registers
+* have been updated before trying again.
+*/
+ msleep(INA2XX_MAX_DELAY);
+ continue;
+ }
+
data->last_updated = jiffies;
data->valid = 1;
+
+ return 0;
}
-abort:
+
+ /*
+* If we're here then although all write operations succeeded, the
+* chip still returns 0 in the calibration register. Nothing more we
+* can do here.
+*/
+ dev_err(dev, "unable to reinitialize the chip\n");
+ return -ENODEV;
+}
+
+static struct ina2xx_data *ina2xx_update_device(struct device *dev)
+{
+ struct ina2xx_data *data = dev_get_drvdata(dev);
+ struct ina2xx_data *ret = data;
+ int rv;
+
+ mutex_lock(>update_lock);
+
+ if (time_after(jiffies, data->last_updated +
+ HZ / INA2XX_CONVERSION_RATE) || !data->valid) {
+ rv = ina2xx_do_update(dev);
+ if (rv < 0)
+ ret = ERR_PTR(rv);
+ }
[PATCH v7 5/5] hwmon: ina2xx: allow to change the averaging rate at run-time
The averaging rate of ina226 is hardcoded to 16 in the driver. Make it
modifiable at run-time via a new sysfs attribute.
While we're at it - add an additional variable to ina2xx_data, which holds
the current configuration settings - this way we'll be able to restore the
configuration in case of an unexpected chip reset.
Signed-off-by: Bartosz Golaszewski
---
Documentation/hwmon/ina2xx | 3 ++
drivers/hwmon/ina2xx.c | 132 +++--
2 files changed, 131 insertions(+), 4 deletions(-)
diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index 320dd69..a11256d 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -48,3 +48,6 @@ The shunt value in micro-ohms can be set via platform data or
device tree at
compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
if the device tree is used.
+
+The averaging rate of INA226 and INA230 can be changed via the avg_rate sysfs
+attribute. The available rates are: 1, 4, 16, 64, 128, 256, 512 and 1024.
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 49537ea..d6fccad 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -68,6 +68,15 @@
#define INA2XX_RSHUNT_DEFAULT 1
+/* bit masks for the averaging setting in the configuration register */
+#define INA226_AVG_RD_MASK 0x0E00
+#define INA226_AVG_WR_MASK 0xF1FF
+
+#define INA226_READ_AVG(reg) ((reg & INA226_AVG_RD_MASK) >> 9)
+
+/* common attrs, ina226 attrs and NULL */
+#define INA2XX_MAX_ATTRIBUTE_GROUPS3
+
enum ina2xx_ids { ina219, ina226 };
struct ina2xx_config {
@@ -85,12 +94,14 @@ struct ina2xx_data {
const struct ina2xx_config *config;
long rshunt;
+ u16 curr_config;
struct mutex update_lock;
bool valid;
unsigned long last_updated;
int kind;
+ const struct attribute_group *groups[INA2XX_MAX_ATTRIBUTE_GROUPS];
u16 regs[INA2XX_MAX_REGISTERS];
};
@@ -115,6 +126,38 @@ static const struct ina2xx_config ina2xx_config[] = {
},
};
+/*
+ * Available averaging rates for ina226. The indices correspond with
+ * the bit values expected by the chip (according to the ina226 datasheet,
+ * table 3 AVG bit settings, found at
+ * http://www.ti.com/lit/ds/symlink/ina226.pdf.
+ */
+static const int ina226_avg_tab[] = { 1, 4, 16, 64, 128, 256, 512, 1024 };
+
+static int ina226_avg_bits(int avg)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ina226_avg_tab); i++) {
+ if (avg == ina226_avg_tab[i])
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int ina226_avg_val(int bits)
+{
+ /*
+* Value read from the config register should be correct, but do check
+* the boundary just in case.
+*/
+ if (bits >= ARRAY_SIZE(ina226_avg_tab))
+ return -ENODEV;
+
+ return ina226_avg_tab[bits];
+}
+
static int ina2xx_calibrate(struct ina2xx_data *data)
{
return i2c_smbus_write_word_swapped(data->client, INA2XX_CALIBRATION,
@@ -131,7 +174,7 @@ static int ina2xx_init(struct ina2xx_data *data)
/* device configuration */
ret = i2c_smbus_write_word_swapped(client, INA2XX_CONFIG,
- data->config->config_default);
+ data->curr_config);
if (ret < 0)
return ret;
@@ -292,6 +335,66 @@ static ssize_t ina2xx_set_shunt(struct device *dev,
return count;
}
+static ssize_t ina226_show_avg(struct device *dev,
+ struct device_attribute *da, char *buf)
+{
+ struct ina2xx_data *data = ina2xx_update_device(dev);
+ int avg, i, written = 0;
+ const char *fmt;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ avg = ina226_avg_val(INA226_READ_AVG(data->regs[INA2XX_CONFIG]));
+ if (avg < 0)
+ return avg;
+
+ for (i = 0; i < ARRAY_SIZE(ina226_avg_tab); i++) {
+ if (avg == ina226_avg_tab[i])
+ fmt = "\t[%d]";
+ else
+ fmt = "\t%d";
+
+ written += snprintf(buf + written, PAGE_SIZE - written,
+ fmt, ina226_avg_tab[i]);
+ }
+ written += snprintf(buf + written, PAGE_SIZE - written, "\n");
+
+ return written;
+}
+
+static ssize_t ina226_set_avg(struct device *dev,
+ struct device_attribute *da,
+ const char *buf, size_t count)
+{
+ struct ina2xx_data *data = ina2xx_update_device(dev);
+ long val;
+ int status, avg;
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ status = kstrtol(buf, 10, );
+ if (status < 0)
+ return status;
+
+ avg =
[PATCH v7 2/5] hwmon: ina2xx: remove a stray new line
Signed-off-by: Bartosz Golaszewski --- drivers/hwmon/ina2xx.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c index ffbd60f..39e017b 100644 --- a/drivers/hwmon/ina2xx.c +++ b/drivers/hwmon/ina2xx.c @@ -52,7 +52,6 @@ #define INA226_ALERT_LIMIT 0x07 #define INA226_DIE_ID 0xFF - /* register count */ #define INA219_REGISTERS 6 #define INA226_REGISTERS 8 -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On 12/13/2014 03:30 AM, Ingo Molnar wrote: >> > This is my no_hz related config: >> > >> > $ grep NO_HZ .config >> > CONFIG_NO_HZ_COMMON=y >> > # CONFIG_NO_HZ_IDLE is not set >> > CONFIG_NO_HZ_FULL=y >> > CONFIG_NO_HZ_FULL_ALL=y > Just curious, if you disable NO_HZ_FULL_ALL, does the bug change? On 12/13/2014 07:08 AM, Paul E. McKenney wrote: > Alternatively, your could boot with nohz_full=2-27 (or maybe even > nohz_full=4-27). This will override CONFIG_NO_HZ_FULL_ALL=y and will > provide two (or four with 4-27) housekeeping CPUs that are available to > run things like RCU grace-period kthreads and RCU callback processing. > This might allow RCU to get the CPU bandwidth it needs despite > competition from your workload. I've tried both nohz_full=4-27 and disabling CONFIG_NO_HZ_FULL_ALL altogether, but I'm still seeing the stall: [ 725.670017] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 725.670017] 0: (11 ticks this GP) idle=bbd/142/0 softirq=11529/11529 fqs=0 last_accelerate: 9d0e/a648, nonlazy_posted: 721357, .. [ 725.670017] (detected by 16, t=2102 jiffies, g=9857, c=9856, q=2581) [ 725.670017] Task dump for CPU 0: [ 725.670017] kworker/0:1 S 8800633abde8 13016 520 2 0x10080008 [ 725.670017] b03027a8 880a70f24017 b043ef40 88005ffea310 [ 725.670017] dfffe900 163bcdeb [ 725.670017] 88006be15030 b1de6f58 ff10 b0301237 [ 725.670017] Call Trace: [ 725.670017] [] ? retint_restore_args+0x13/0x13 [ 725.670017] [] ? _raw_spin_unlock_irq+0x57/0x200 [ 725.670017] [] ? _raw_spin_unlock_irq+0x23/0x200 [ 725.670017] [] ? worker_thread+0x15b/0x1680 [ 725.670017] [] ? __schedule+0xf6f/0x2fc0 [ 725.670017] [] ? process_one_work+0x1650/0x1650 [ 725.670017] [] ? kthread+0x1f2/0x2b0 [ 725.670017] [] ? kthread_worker_fn+0x6a0/0x6a0 [ 725.670017] [] ? ret_from_fork+0x7c/0xb0 [ 725.670017] [] ? kthread_worker_fn+0x6a0/0x6a0 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
On 12/12/2014 05:45 PM, Andy Lutomirski wrote:
> I was thinking of this:
>
> + if (is_64bit_mm(mm)) {
> + vaddr_space_size = 1ULL << __VIRTUAL_MASK_SHIFT;
> + bd_entry_virt_space = vaddr_space_size / MPX_BD_NR_ENTRIES_64;
> + /*
> + * __VIRTUAL_MASK takes the 64-bit addressing hole
> + * in to accout. This is a noop on 32-bit.
> + */
> + addr &= __VIRTUAL_MASK;
> + return addr / bd_entry_virt_space;
> + } else {
> + vaddr_space_size = (1ULL << 32);
> + bd_entry_virt_space = vaddr_space_size / MPX_BD_NR_ENTRIES_32;
> + return addr / bd_entry_virt_space;
> + }
>
> Is there a scenario in which the return value ends up being insanely
> high? If so, does it matter?
Yes, it will be insanely high for a 32-bit process. The kernel could go
looking for the bounds directory entry at some bonkers virtual address
that makes no sense on 32-bit.
But, that bonkers address is still treated as coming from userspace.
The kernel will go and dereference it via a get_user(), fault, notice
the bad address and kill the process.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] ARM: mediatek: dts: Add bindings for watchdog
On 12/12/2014 06:50 AM, Matthias Brugger wrote:
Signed-off-by: Matthias Brugger
---
Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 13 +
1 file changed, 13 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
new file mode 100644
index 000..af9eb5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
@@ -0,0 +1,13 @@
+Mediatek SoCs Watchdog timer
+
+Required properties:
+
+- compatible : should be "mediatek,mt6589-wdt"
"mediatek" is undefined as vendor prefix in the current upstream code.
Is this vendor prefix coming in from another patch set ?
Guenter
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+wdt: watchdog@01000 {
+ compatible = "mediatek,mt6589-wdt";
+ reg = <0x1000 0x18>;
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] watchdog: Add driver for Mediatek watchdog
On 12/12/2014 06:50 AM, Matthias Brugger wrote:
This patch adds a driver for the Mediatek SoC integrated
watchdog. This driver supports watchdog and software reset
for mt65xx and mt81xx SoCs.
Signed-off-by: Matthias Brugger
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/mtk_wdt.c | 257 +
3 files changed, 268 insertions(+)
create mode 100644 drivers/watchdog/mtk_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d0107d4..fcbca1b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -505,6 +505,16 @@ config MESON_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called meson_wdt.
+config MEDIATEK_WATCHDOG
+ tristate "Mediatek SoCs watchdog support"
+ depends on ARCH_MEDIATEK
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the watchdog timer
+ in Mediatek SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called mtk_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index c569ec8..0d4821f 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_QCOM_WDT) += qcom-wdt.o
obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
+obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
new file mode 100644
index 000..5f75442
--- /dev/null
+++ b/drivers/watchdog/mtk_wdt.c
@@ -0,0 +1,257 @@
+/*
+ * Mediatek Watchdog Driver
+ *
+ * Copyright (C) 2014 Matthias Brugger
+ *
+ * Matthias Brugger
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Based on mtk_wdt.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define WDT_MAX_TIMEOUT31
+#define WDT_MIN_TIMEOUT1
+#define WDT_LENGTH_TIMEOUT(n) ((n) << 5)
+
+#define WDT_LENGTH 0x04
+#define WDT_LENGTH_KEY 0x8
+
+#define WDT_RST0x08
+#define WDT_RST_RELOAD 0x1971
+
+#define WDT_MODE 0x00
+#define WDT_MODE_EN(1 << 0)
+#define WDT_MODE_EXT_POL_LOW (0 << 1)
+#define WDT_MODE_EXT_POL_HIGH (1 << 1)
+#define WDT_MODE_EXRST_EN (1 << 2)
+#define WDT_MODE_IRQ_EN(1 << 3)
+#define WDT_MODE_AUTO_START(1 << 4)
+#define WDT_MODE_DUAL_EN (1 << 6)
+#define WDT_MODE_KEY 0x2200
+
+#define WDT_SWRST 0x14
+#define WDT_SWRST_KEY 0x1209
+
+#define DRV_NAME "mtk-wdt"
+#define DRV_VERSION"1.0"
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+static unsigned int timeout = WDT_MAX_TIMEOUT;
+
+struct mtk_wdt_dev {
+ struct watchdog_device wdt_dev;
+ void __iomem *wdt_base;
+ struct notifier_block restart_handler;
+};
+
+static int mtk_reset_handler(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+ struct mtk_wdt_dev *mtk_wdt = container_of(this,
+ struct mtk_wdt_dev,
+ restart_handler);
+ void __iomem *wdt_base = mtk_wdt->wdt_base;
+ u32 reg;
+
+ /* Reset system */
+ writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST);
+
+ while (1) {
+ mdelay(5);
+ writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST);
+ }
+ return NOTIFY_DONE;
+
Unnecessary empty line. See checkpatch --strict.
+}
+
+static int mtk_wdt_ping(struct watchdog_device *wdt_dev)
+{
+ struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
+ void __iomem *wdt_base = mtk_wdt->wdt_base;
+
+ iowrite32(WDT_RST_RELOAD, wdt_base + WDT_RST);
+
+ return 0;
+}
+
+static int mtk_wdt_set_timeout(struct watchdog_device *wdt_dev,
+ unsigned int timeout)
Continuation line alignment is off. See checkpatch --strict.
+{
+ struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
+ void __iomem *wdt_base = mtk_wdt->wdt_base;
+ u32 reg;
+
+
Re: "perf top -g" leaking ~300MB per second.
Em Sat, Dec 13, 2014 at 10:03:31AM +0100, Markus Trippelsdorf escreveu: > On 2014.12.13 at 09:48 +0100, Markus Trippelsdorf wrote: > > Running "perf top -g" built from current Linus tree apparently leaks > > ~300MB of memory every second an my machine. > > Hmm, this is a much older problem. I just noticed this the first time > today. > To reproduce: Compile some application in the background (make -j4 in my > case) and run "perf top -g". Perf will continue to accumulate memory > until the system starts to swap and the OOM killer eventually kicks in. Yeap, longstanding problem, try minimizing the problem using a lower frequency. The callchain code was done initially for 'report' and when I made 'top' reuse the hist_entry code allowing 'top' to collect callchains was too easy, but then we need to go thru the callchain/hists/hist_entry code to make sure that they don't leak, will try to do it... - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH net-next 1/1] net: Support for switch port configuration
Hi, all, Regarding preferring using netlink sockets versus ethtool IOCTLs for setting kernel network attributes from userspace, I fully agree with Marco. The netlink API is much more structured and much more geared towards this type of operation, than the IOCTL-based ethtool. Regards, Rami Rosen Software Engineer, Intel -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Varlese, Marco Sent: Friday, December 12, 2014 11:20 To: Roopa Prabhu; Jiri Pirko Cc: John Fastabend; net...@vger.kernel.org; step...@networkplumber.org; Fastabend, John R; sfel...@gmail.com; linux-kernel@vger.kernel.org Subject: RE: [RFC PATCH net-next 1/1] net: Support for switch port configuration > -Original Message- > From: Roopa Prabhu [mailto:ro...@cumulusnetworks.com] > Sent: Thursday, December 11, 2014 5:41 PM > To: Jiri Pirko > Cc: Varlese, Marco; John Fastabend; net...@vger.kernel.org; > step...@networkplumber.org; Fastabend, John R; sfel...@gmail.com; > linux-kernel@vger.kernel.org > Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port > configuration > > On 12/11/14, 8:56 AM, Jiri Pirko wrote: > > Thu, Dec 11, 2014 at 05:37:46PM CET, ro...@cumulusnetworks.com wrote: > >> On 12/11/14, 3:01 AM, Jiri Pirko wrote: > >>> Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varl...@intel.com wrote: > > -Original Message- > > From: John Fastabend [mailto:john.fastab...@gmail.com] > > Sent: Wednesday, December 10, 2014 5:04 PM > > To: Jiri Pirko > > Cc: Varlese, Marco; net...@vger.kernel.org; > > step...@networkplumber.org; Fastabend, John R; > > ro...@cumulusnetworks.com; sfel...@gmail.com; linux- > > ker...@vger.kernel.org > > Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch > > port configuration > > > > On 12/10/2014 08:50 AM, Jiri Pirko wrote: > >> Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varl...@intel.com > wrote: > >>> From: Marco Varlese > >>> > >>> Switch hardware offers a list of attributes that are > >>> configurable on a per port basis. > >>> This patch provides a mechanism to configure switch ports by > >>> adding an NDO for setting specific values to specific attributes. > >>> There will be a separate patch that extends iproute2 to call > >>> the new NDO. > >> What are these attributes? Can you give some examples. I'm > >> asking because there is a plan to pass generic attributes to > >> switch ports replacing current specific > >> ndo_switch_port_stp_update. In this case, bridge is setting that > >> attribute. > >> > >> Is there need to set something directly from userspace or does > >> it make rather sense to use involved bridge/ovs/bond ? I think > >> that both will be needed. > > +1 > > > > I think for many attributes it would be best to have both. The > > in kernel callers and netlink userspace can use the same driver ndo_ops. > > > > But then we don't _require_ any specific bridge/ovs/etc module. > > And we may have some attributes that are not specific to any > > existing software module. I'm guessing Marco has some examples > > of > these. > > > > [...] > > > > > > -- > > John Fastabend Intel Corporation > We do have a need to configure the attributes directly from > user-space > and I have identified the tool to do that in iproute2. > > An example of attributes are: > * enabling/disabling of learning of source addresses on a given > port (you can imagine the attribute called LEARNING for example); > * internal loopback control (i.e. LOOPBACK) which will control > how the flow of traffic behaves from the switch fabric towards an > egress port; > * flooding for broadcast/multicast/unicast type of packets (i.e. > BFLOODING, MFLOODING, UFLOODING); > > Some attributes would be of the type enabled/disabled while other > will > allow specific values to allow the user to configure different > behaviours of that feature on that particular port on that platform. > > One thing to mention - as John stated as well - there might be > some > attributes that are not specific to any software module but rather > have to do with the actual hardware/platform to configure. > > I hope this clarifies some points. > >>> It does. Makes sense. We need to expose this attr set/get for both > >>> in-kernel and userspace use cases. > >>> > >>> Please adjust you patch for this. Also, as a second patch, it > >>> would be great if you can convert ndo_switch_port_stp_update to > >>> this new > ndo. > >> Why are we exposing generic switch attribute get/set from userspace > >> ?. We already have specific attributes for learning/flooding which > >> can be extended further. > > Yes, but that is for PF_BRIDGE and bridge specific
Re: [PATCH 0/3] removing of some unused/unsupported dts entries
Silvio, Marc, On Sat, Dec 13, 2014 at 09:21:23AM +, Marc Zyngier wrote: > On Sat, Dec 13 2014 at 1:46:45 am GMT, Silvio Fricke > wrote: > > Hi Silvio, > > > I have found some dts entries which are not evaluated by the drivers. This > > patch remove this entries from the dts files. > > Jason has mentioned I should CC: Thomas, Marc and him self to this > > mails. > > As far as I can tell, this looks correct. A few key things though: > > - Please write decent commit logs. Indicate *why* you think these > properties can be removed (hint: not finding corresponding in the > drivers is not enough a reason, the binding itself matters). Right. The real issue is the state of these properties within the binding documentation. Linux isn't the only consumer of these dts files (*BSD, barebox, etc), so us not using them doesn't necessarily mean the property should be removed. The most important lesson (recently learned ;-) ) is to make sure all properties are accurately describing the *hardware*. Not Linux's implementation of talking to the hardware. That'll go a long way if the changelog discusses how property X is an implementation detail vice a hardware characteristic or feature. > - Cc the relevant platform maintainers. You're changing things that they > care about, basic courtesy is to keep them in the loop. True. In Silvio's defense, I just told him to Cc us to get the ball rolling. (I tend to dislike long discussions on chat mediums, I'd much rather they be in email. So I was definitely too succinct). For the record, you can use ./scripts/get_maintainer.pl on your patches to make sure you get most of the right people. In this case, that'll include the DT maintainers. You may want to run a get_maintainer.pl -f arch/arm/mach-$ARCH for each of the dts file you touch. Those maintainers usually wrangle the patches for their dts files. Unfortunately, not all of them have updated MAINTAINERS (mvebu) to include the dts file patterns. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] TTY: add support for "tty slave" devices.
On Fri, 12 Dec 2014 08:02:48 -0500 > Which brings up another point: why not do this in the runtime power > management; > ie, turn on the slave device when the master device is turned on? Sebastian > recently made the 8250 driver power-managed per access, which would enable > significant power savings over just leaving the slave device on the whole > time. That per access model only works on 8250 (in fact only on some 8250). On most devices if the UART is in low power you lose bytes send to it rather than then queuing up anywhere. It doesn't handle cases where you need to keep power on to different rules (for example there are cases where you do things like power the uart down after no bits have been received for 'n' millseconds). Right now if you look into Androidspace you'll find people doing this in userspace by having the sysfs node open and playing crazy games with sysfs, Android glue hacks and gpio poking via the gpio sysfs/gpio lib routines. Good example is some of the GPS and serial based sensor chips. The latency of tty open/close is unacceptable and risks losing bits so they keep the tty open and whack the power management by hand right now. The kind of thing many of them want is stuff like "hold power on until we see receive data, then keep it on until it shuts up for a bit" "assert gpio, send, receive, wait idle, drop gpio" "on GPIO interrupt wake uart, wait for data, when idle, power uart down" > >> 2) why is this tied to the tty core and not the serial core > >>if this is only for UART? > > > > Because the knowledge of "the device is being opened" or "the device is > > being > > closed" seems to exist in the tty core but not in the serial core. > > uart_open() = device file is being opened > uart_close() = device file is being released Only for a subset of uart type devices that use the uart layer. Quite a few don't, including all the USB ones, and the sd ones. > > I'm happy to move it to serial_core.c if that is preferred. > > I'll also move the open/close handling if you can point to where it should > > go. > > Yes, please. NAK - I certainly object to it being moved to uart. That's the wrong abstraction layer for this. It's a generic behaviour, it's a tty level behaviour without any uart specific properties. It should work for uarts that don't use the legacy serial_core code, uarts that do, uarts that use USB, uarts that are directly connected to things like sdio etc. That means it has to be tty layer. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
On 12/13/2014 03:27 AM, Ingo Molnar wrote: > > * Ingo Molnar wrote: > >> >> * Linus Torvalds wrote: >> >>> On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote: >>> Something that's still making me wonder if it's some kind of hardware problem is the non-deterministic nature of this bug. >>> >>> I'd expect it to be a race condition, though. Which can easily >>> cause these kinds of issues, and the timing will be pretty >>> random even if the load is very regular. >>> >>> And we know that the scheduler has an integer overflow under >>> Sasha's loads, although I didn't hear anything from Ingo and >>> friends about it. Ingo/Peter, you were cc'd on that report, >>> where at least one of the multiplcations in wake_affine() ended >>> up overflowing.. >> >> Just to make sure, is there any other wake_affine report other >> than the one in this thread? (I tried a wake_affine full text >> search on my inbox and didn't find anything that appeared >> relevant.) > > Found the report from Sasha: > > sched: odd values for effective load calculations > > right? Yup, that's the one. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] TTY: add support for "tty slave" devices.
> 2) why is this tied to the tty core and not the serial core >if this is only for UART? I'm a bit baffled why you would try and tie it to serial core given that serial core only covers a random subset of the uart drivers we have. If we have a USB connected device with USB gpio lines doing power management then it needs to be tied tty core. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
